Caption Conversion Guide
Convert SCC to EBU-STL
The North-America-to-Europe delivery. Two things make it more work than it looks: SCC has no end times, so every out timecode has to be derived, and STL has a header full of metadata fields that the SCC cannot supply.
Can you convert an SCC file to EBU-STL?
Yes. The text, colour and placement map onto teletext cleanly, but three things must be supplied that the SCC does not contain: a 25 fps timing base via a real conform, an out timecode for every subtitle derived from the erase commands, and the programme metadata that fills the STL header.
What changes when you convert SCC to EBU-STL
608 and teletext are close cousins in capability, so the content maps well. The friction is structural: SCC is a byte stream with no end times and no metadata, and STL is a fixed-block format that wants both.
| Property | In the SCC | In the EBU-STL | Result |
|---|---|---|---|
| Frame rate | 29.97 fps only | 25 fps, declared in the header | A real conform is mandatory in this direction too |
| End times | None. Captions clear on an erase command | Explicit out timecode per subtitle | Every out time must be derived from the erase commands |
| Text | CEA-608 character set | One character table per file | Latin content maps directly. Select the Latin table |
| Vertical position | Row 1 to 15 on the 608 grid | Teletext row number | Maps directly. Teletext has more rows available |
| Horizontal position | Column indent on a 32-column grid | Justification: left, centre, right | Column positions become a justification value. Precision is lost |
| Colour | Seven 608 colours | Teletext palette | The palettes overlap closely. Colours survive |
| Italics | 608 italic attribute | Signalled in the text field | Survives |
| Caption style | Pop-on, roll-up, paint-on | Subtitle in and out | Roll-up becomes discrete subtitles. The scrolling behaviour is lost |
| Programme metadata | None | Title, episode, translator, reel fields | Has to be supplied by you. The SCC cannot provide it |
| Display standard | Not applicable | Open subtitles or teletext level 1 or 2 | A choice you make, driven by the delivery spec |
Before you start: what the SCC cannot give you
An SCC is a stream of caption commands and nothing else. Everything an STL header expects has to come from the delivery paperwork.
- The programme metadata. Title, episode number, translator and reel information all live in the STL header and have no source in the SCC.
- The display standard. Open subtitles or teletext level 1 or 2. The delivery specification will state which, and it affects how much placement data is meaningful.
- The target language code. The STL header carries a single language field, which the SCC does not supply.
- How the picture was converted to 25 fps. A speed change and a re-conformed edit need different subtitle treatments.
- The maximum line length the client expects. Teletext control codes consume character cells, so a 32-character 608 line does not automatically fit.
How to convert SCC to EBU-STL
Deriving the out times is the step that determines caption quality, and it is worth reviewing rather than accepting a default.
-
Open the SCC and confirm the caption channel
Identify which 608 channel carries the content you need, normally CC1, and check whether a second language is present on CC3. -
Derive out timecodes
Every erase command becomes a subtitle out time. Review the result, because captions left on screen through a long pause will produce very long durations. -
Establish how the picture reached 25 fps
Determine whether the conversion was a speed change or a re-conform. This decides whether subtitles are scaled or re-timed. -
Conform the timing to 25 fps
Recalculate every in and out timecode. Spot-check against the 25 fps master at the head, middle and tail. -
Map the 608 grid onto teletext rows
Convert row and column positions to teletext rows and justification. Review anything placed away from the default position. -
Select the character table and display standard
Choose the Latin character table and set the display standard the delivery specification requires. -
Fill in the header metadata
Enter programme title, episode, translator, language and reel information from the delivery paperwork. -
Re-check line lengths
Teletext control codes occupy character cells. Verify that lines which fitted in 32 characters still fit on air. -
Export and QC against picture
Write the STL, then play it back against the 25 fps master checking placement, timing and reading speed.
What breaks, and how to catch it
Two of these produce a file that passes technical validation and fails on air.
- Naive out times. Deriving every out time as the next caption's in time leaves subtitles on screen through pauses. Review the longest durations in the file.
- An unconformed frame rate. Relabelling 29.97 as 25 does not move anything. Drift is immediate and grows across the programme.
- Empty header fields. An STL with no programme title or language code will often be rejected on ingest, even though the subtitles are correct.
- Line overflow from control codes. Colour changes consume cells on a teletext line. A 32-character line with two colour changes can overflow.
- Lost roll-up behaviour. 608 roll-up captions become discrete subtitles. For live-originated material this changes the on-screen rhythm noticeably.
When not to convert SCC to EBU-STL
STL is the right target for European broadcast playout and a poor one for anything else.
- The delivery is European streaming. IMSC or EBU-TT-D is what modern OTT specs name, and both preserve far more.
- The content is not Latin script. Neither format handles that well from a 608 source, and the source could not have carried it anyway.
- The material was live-captioned as roll-up. Converting to discrete subtitles changes the presentation substantially. Discuss it with the client first.
- You do not have the programme metadata. An STL with empty header fields is likely to fail ingest. Get the paperwork before exporting.
The EBU-STL format reference covers the header fields and what each one is for.
SCC to EBU-STL questions
Specific questions about this conversion. For the formats themselves, see the SCC and EBU-STL references below.
They are derived from the erase commands in the byte stream. A caption stays on screen until an erase command clears it, so that command's timecode becomes the out time. The result needs review: where a caption was left up through a long pause, the derived duration can be far longer than a subtitle reading-speed spec allows.
Programme title, episode number, translator name, language code and reel information, among others. None of this exists anywhere in an SCC, which is a caption command stream with no metadata concept. It has to be entered from the delivery paperwork, and an STL with empty header fields is frequently rejected at ingest.
Closely. Both palettes are built around the same small set of saturated colours, so a converter can usually find a direct match rather than approximating. This is one of the few properties in this conversion that survives without a decision being made on your behalf.
They become discrete subtitles with in and out times. The words survive; the scrolling behaviour does not, because teletext subtitling does not present captions that way. For live-originated material this is a visible change in rhythm, and it is worth flagging to the client rather than delivering it as a surprise.
Arithmetically yes, procedurally no. What matters is how the picture was converted, and the answer differs by project: a speed change scales every timecode, while a re-conformed edit needs the subtitles re-timed against the new master. Ask how the video was handled before deciding which to apply.
Derive the out times, fill in the header
Closed Caption Creator derives subtitle out times from 608 erase commands with the durations visible for review, conforms 29.97 to 25 fps, and writes a complete STL header.
Preview teletext spacing against picture before export so line overflow is caught before ingest, not after.