Caption Format Reference
Cavena 890 File Format (.890)
Cavena 890 is the native subtitle format of the Cavena subtitling systems used across Nordic and European broadcast. It is binary, frame-based and row-positioned, and like most broadcast subtitle formats it stores text through a character table rather than as Unicode.
What can a Cavena 890 file be converted to?
A Cavena 890 file converts to SRT, WebVTT, TTML, IMSC, EBU-STL and PAC, keeping text and timing throughout and placement in the formats that support it. Conversion to SCC works only for Latin-script content and requires a frame rate conform.
Cavena 890 at a glance
890 sits in the same family of considerations as EBU-STL and PAC: a binary broadcast format where the frame rate and the character table are the two settings that determine whether a conversion succeeds.
| Property | Value |
|---|---|
| Common name | Cavena 890, after the file extension |
| Extension | .890 |
| Origin | Cavena subtitling systems |
| Specification | Proprietary |
| File structure | Binary |
| Timing | Frame-based, with in and out times per subtitle |
| Character support | Character-table based, covering Latin and non-Latin scripts |
| Positioning | Row-based vertical placement with horizontal alignment |
| Typical region | Nordic and European broadcast and subtitling |
| Current status | In active use, and common in archive material |
| Closed Caption Creator | Read and write |
For a side-by-side against the other European broadcast subtitle formats, see EBU-STL and PAC.
What Cavena 890 can and cannot carry
890 carries roughly what EBU-STL carries. The important limits are the same ones: text is decoded through a character table, and timing is counted in frames at a rate the file does not necessarily announce.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | Decoded through the file's character table |
| Explicit in and out times | Yes | Both stored per subtitle |
| Row positioning | Yes | Vertical placement by row |
| Horizontal alignment | Yes | Left, centred or right |
| Italics | Yes | As a subtitle attribute |
| Non-Latin scripts | Yes | Through the appropriate character table |
| Mixed scripts in one file | No | The character table applies to the whole file |
| Frame-based timing | Yes | Counted in frames rather than milliseconds |
| Embedded frame rate | Partial | Confirm the rate against the master rather than assuming |
| Two languages in one file | Partial | Depends on how the originating system was configured |
| Fonts and text size | No | Appearance is decided by the rendering or burn-in system |
Who asks for Cavena 890 files?
890 is a working and delivery format inside the Cavena ecosystem, which remains widely deployed in Northern Europe.
- Nordic broadcasters and the subtitling houses that supply them.
- European facilities running Cavena subtitling and playout systems.
- Archive material from those operations, often as the only surviving subtitle asset.
- Localisation vendors exchanging work with a Cavena-based client.
For a delivery outside that ecosystem, the file usually becomes EBU-STL for European broadcast, IMSC for streaming, or SRT for general use.
How do I open a Cavena 890 file?
890 is binary, so a text editor shows unreadable bytes with occasional readable fragments. There is no plain-text header announcing the format the way SCC or WebVTT do.
Opening it properly requires a tool that understands the structure and applies the correct character table. As with PAC, the failure mode is not an error message — it is text that decodes into something plausible-looking and wrong.
If you receive an 890 without knowing its language or the frame rate of the master, ask before converting. Both affect the output and neither can be reliably inferred from the file alone.
Converting Cavena 890 to another format
Converting out of 890 is reliable once the character table and frame rate are right. The two European sibling formats are the easiest targets; the North American ones require more compromise.
| Convert Cavena 890 to | What survives | What to watch for |
|---|---|---|
| EBU-STL | Text, placement, alignment | The closest match. Both are row-positioned, frame-based and character-table driven. |
| PAC | Text, placement, alignment | Also a close sibling. Confirm the target code page covers the script. |
| TTML / IMSC | Text, placement, styling | The best target for non-Latin content, because UTF-8 removes the character table problem. |
| WebVTT | Text, approximate placement | Rows become percentages of the frame. UTF-8 output means every script survives. |
| SRT | Text and line breaks | Placement and alignment are discarded. Save as UTF-8 so the decoded script is not mangled again. |
| SCC | Latin text and approximate placement | Latin-script content only, and a conform to 29.97 fps is required. |
| MCC | Latin text, placement | Same script limit as SCC, but the frame rate can match the master rather than being forced. |
Converting another format to Cavena 890
Converting into 890 means committing to a character table and a frame rate, neither of which a Unicode, millisecond-based source file will have supplied.
| Convert to Cavena 890 from | What carries over | What the conversion has to decide |
|---|---|---|
| EBU-STL | Text, placement, alignment | Character table mapping, which is usually direct when the scripts match. |
| PAC | Text, placement, alignment | Code page to character table mapping, and confirming the frame rate is consistent. |
| SRT | Text | A character table, a frame rate, row placement and alignment. |
| WebVTT | Text and approximate placement | Percentage cue settings become rows, and a character table must be chosen. |
| TTML / IMSC | Text, placement | Which character table covers the content. A UTF-8 source can hold characters no single table can. |
| SCC | Text and placement | A frame rate conform, and a mapping from the 608 grid onto rows. |
Closed Caption Creator reads and writes every format in both tables. See the full file format support list, or the conversion API and CLI for batch workflows.
Where Cavena 890 conversions go wrong
The failures mirror PAC's, because the underlying design decisions are the same.
- The wrong character table. Non-Latin content decoded with a Latin table produces structurally valid nonsense that no downstream tool will flag.
- An assumed frame rate. Frame-based timing without a confirmed rate drifts progressively against picture, and the error grows across the programme.
- Converting non-Latin content to SCC. CEA-608 has no code points for Cyrillic, Greek, Arabic or Hebrew, so the text cannot be represented at all.
- Dropping UTF-8 on the way out. Decoding the character table correctly and then writing a legacy-encoded SRT undoes the work entirely.
For handling scripts across a multilingual delivery, see translating subtitles for broadcast.
Cavena 890 conversion questions
Common questions about opening and converting Cavena 890 subtitle files.
It is a subtitle file produced by Cavena subtitling systems, widely used in Nordic and European broadcast. The file is binary, stores in and out timecodes in frames, and positions subtitles by row. Text is stored through a character table rather than as Unicode, which is why the language has to be known before the file can be read correctly.
Yes. Text and timing convert cleanly, and frame-based timecodes become milliseconds. What is discarded is row placement and alignment, since SRT has no positioning. Write the output as UTF-8 — having decoded the character table correctly, saving in a legacy encoding puts the text straight back into the state you just fixed.
Treat it as something to confirm rather than something to read. Timing is counted in frames, so the rate determines where every subtitle lands, and an assumption that is wrong by even a small margin produces drift that grows across the programme. Get the rate from the master or the delivery paperwork before converting.
Yes, through its character tables, which is one reason the format has stayed in use for multilingual European work. The constraint is that the table applies to the whole file, so a title mixing scripts needs one file per language. Converting to a Unicode-based target such as IMSC or WebVTT removes that limitation permanently.
Only for Latin-script content, and only with a frame rate conform. SCC carries CEA-608 data, which has no code points for Cyrillic, Greek, Arabic or Hebrew, so non-Latin subtitles cannot be represented at all. SCC is also fixed at 29.97 fps, so an 890 timed against a 25 fps master has to be re-timed rather than relabelled.
Because the wrong character table was applied when the file was read. The bytes are being decoded against the wrong script, which produces output that looks like text but is not. Re-open the file specifying the correct source language rather than attempting to repair the characters afterwards, which cannot recover the original.
Read 890 correctly, deliver anywhere
Closed Caption Creator reads and writes Cavena 890 with explicit character table selection, so non-Latin content survives the conversion intact.
Convert to EBU-STL, IMSC, WebVTT or SRT with placement preserved, and conform frame rates on the way.