Caption Conversion Guide
Convert Cavena 890 to SRT
This is the conversion people reach for when they have been handed a .890 file and simply need to read it. It is straightforward with two caveats, one of which surprises people: you still need to know the frame rate, even though SRT does not have one.
Can you convert a Cavena 890 file to SRT?
Yes. Text and timing convert cleanly, and row placement and colour are discarded because SRT cannot hold them. Two inputs are required: the file's character table, so the text decodes correctly, and the source frame rate, because 890 counts frames and SRT counts milliseconds.
What changes when you convert Cavena 890 to SRT
890 is a broadcast subtitle format and SRT is a lowest-common-denominator interchange format, so this conversion is a deliberate simplification. The text and the timing are what you are keeping.
| Property | In the Cavena 890 | In the SRT | Result |
|---|---|---|---|
| Text encoding | Character-table based | Undeclared, UTF-8 by convention | Decode with the right table, then write UTF-8 or the work is undone |
| Non-Latin scripts | Supported via character tables | Supported when the file is UTF-8 | Survives, provided the output encoding is set correctly |
| Timing | Frame counts | Milliseconds | Frames convert to milliseconds. This needs the source frame rate |
| Frame rate | Confirm against the master | None. SRT is frame-rate agnostic | Still required, as the divisor for the frame-to-millisecond conversion |
| End times | Explicit out timecode | Explicit end time | Transfers directly |
| Vertical position | Row placement | None | Discarded |
| Horizontal position | Alignment | None | Discarded |
| Colour | Subtitle colours | None in the specification | Discarded. Font tags are a convention some players ignore |
| Italics | Per subtitle | <i> tag by convention | Usually survives, though it is not part of any SRT specification |
| Line breaks | As authored | As authored | Preserved exactly |
Before you start: why the frame rate still matters
SRT has no frame rate field, which leads people to assume the source rate is irrelevant. It is not. Frames only become milliseconds if you know how many frames there are per second.
- The source frame rate. An 890 stores frame counts. Converting a frame count to a millisecond value requires dividing by the rate, so an incorrect rate produces proportionally wrong timings.
- The character table. The file's text bytes decode against a table. Applied wrongly, the output is legible nonsense.
- The output encoding. Write UTF-8. Decoding the character table correctly and then saving in a legacy encoding puts the text straight back where it started.
- Whether placement matters to you. If it does, SRT is the wrong target and WebVTT or IMSC is the right one.
- Whether the file is one language or several. One SRT holds one language.
How to convert Cavena 890 to SRT
Two settings on the way in, one on the way out. Everything else is mechanical.
-
Confirm the source language
Get the language from the supplier or the delivery paperwork so the correct character table can be applied. -
Open the 890 with that character table
Load the file specifying the language. Read several subtitles from across the programme and confirm the text is genuinely correct. -
Establish the source frame rate
Check against the master. This is the divisor that turns frame counts into millisecond timings, so an error here scales every timecode. -
Verify the timing against picture
Spot-check subtitles at the head, middle and tail of the programme to confirm the frame rate assumption. -
Export as SRT with UTF-8 encoding
Write the file explicitly as UTF-8 without a byte order mark. Row placement and colour are dropped at this point. -
Open the result and check the characters
Confirm accented and non-Latin characters survived into the output. This is where a wrong encoding setting shows up.
What breaks, and how to catch it
Two encoding steps and one arithmetic step. All three fail quietly.
- The wrong character table on input. Text decodes into structurally valid nonsense. Read a few subtitles containing accented characters before converting the whole file.
- A legacy encoding on output. Decoding correctly and then saving as Windows-1252 re-breaks the text. Always write UTF-8.
- An assumed frame rate. Frame counts divided by the wrong rate produce timings that are proportionally wrong — correct at zero and increasingly off across the programme.
- Silently lost placement. Row and alignment data is discarded without warning. If subtitles were positioned to avoid on-screen text, that intent is gone.
- Colour carrying meaning. Where colour identified speakers, the SRT loses the distinction entirely and the dialogue can become ambiguous.
When not to convert Cavena 890 to SRT
SRT is the right target when you want portability and readability, and the wrong one when the subtitles were doing more than carrying words.
- Placement matters. WebVTT keeps positioning as cue settings and is barely more complex.
- Colour identifies speakers. WebVTT or IMSC can carry it. SRT cannot, reliably.
- The destination is European broadcast. EBU-STL is the delivery format and preserves nearly everything the 890 held.
- The destination is a streaming platform. IMSC keeps placement, styling and full Unicode text.
The Cavena 890 format reference covers what the format carries and where else it can go.
Cavena 890 to SRT questions
Specific questions about this conversion. For the formats themselves, see the Cavena 890 and SRT references below.
Because the 890 does. It stores subtitle timings as frame counts, and turning a frame count into a millisecond value means dividing by the frames per second. Use the wrong rate and every timing is scaled wrongly: correct at the start of the programme and increasingly out as it runs. SRT being frame-rate agnostic is what makes the conversion one-way, not what makes the rate irrelevant.
One of two encoding steps went wrong. Either the 890 was read with the wrong character table, in which case the text was never correct, or it was read correctly and then written in a legacy encoding rather than UTF-8. Check the output first, since fixing the export is trivial; if the text is wrong in the editor before export, the character table is the problem.
No. SRT has no positioning field of any kind, so row placement and alignment are discarded silently. This matters more than it sounds on broadcast material, where subtitles are routinely raised to clear lower thirds and on-screen text. If placement is carrying information, convert to WebVTT instead — it is barely more work and keeps the positions.
Yes, unlike converting to SCC. SRT saved as UTF-8 holds any script, so the constraint that makes 890 to SCC impossible does not apply here. The requirement is that both encoding steps are right: read the 890 with the correct character table, and write the SRT explicitly as UTF-8.
Usually, if the subtitles are going anywhere near a video player. WebVTT is a specified format with a required header and mandatory UTF-8, which removes the encoding ambiguity entirely, and it keeps positioning as cue settings. SRT is the better choice only when something downstream specifically requires it.
Read it, then take it anywhere
Closed Caption Creator reads Cavena 890 with explicit character table selection and writes UTF-8 output, so non-Latin text survives both encoding steps.
Or export WebVTT instead and keep the subtitle positions the 890 was carrying.