Caption Conversion Guide
Convert EBU-STL to SCC
This is the Europe-to-North-America delivery, and it is defined by a single hard fact: STL runs at 25 fps and SCC exists only at 29.97 fps. Everything else about the conversion is manageable. That one thing has to be a genuine conform, and it is routinely done wrong.
Can you convert an EBU-STL file to SCC?
Yes, for Latin-script content, with a mandatory frame rate conform. STL runs at 25 fps and SCC only at 29.97 fps, so every timecode must be recalculated rather than relabelled. Files using a Cyrillic, Greek, Arabic or Hebrew character table cannot convert, because CEA-608 has no code points for them.
What changes when you convert EBU-STL to SCC
STL and SCC are direct counterparts — European and North American broadcast caption deliverables from roughly the same era — so the mapping is more natural than it first appears. The frame rate and the character table are the two hard edges.
| Property | In the EBU-STL | In the SCC | Result |
|---|---|---|---|
| Frame rate | 25 fps, declared in the header | 29.97 fps only | A real conform is mandatory. There is no field in SCC to relabel |
| Text encoding | One character table per file | CEA-608 character set | Latin tables convert. Cyrillic, Greek, Arabic and Hebrew cannot |
| Timing | Explicit in and out timecodes | Start only, cleared by an erase command | Out times become erase commands in the byte stream |
| Vertical position | Teletext row number | Row 1 to 15 on the 608 grid | Teletext offers more rows than 608. Positions compress |
| Horizontal position | Justification: left, centre, right | Column indent on a 32-column grid | Justification becomes a column position |
| Colour | Teletext palette, set by control codes | Seven 608 colours | The palettes overlap closely. Most colours survive |
| Line length | Teletext line, with control codes consuming cells | 32 characters maximum | Different arithmetic on each side. Re-check every line, do not assume |
| Italics | Signalled in the text field | 608 italic attribute | Survives, though rendering depends on the source display standard |
| Display standard | Open subtitles or teletext level 1 or 2 | Not applicable | Open-subtitle STL carries less placement data to bring across |
| Programme metadata | Title, episode, translator in the header | None | Discarded. SCC has no metadata fields |
Before you start: check the header, not the filename
STL stores its own frame rate and character table in the header block, which is more than PAC does. The catch is that those fields are only as trustworthy as the tool that wrote them.
- The declared frame rate, verified against picture. The header says 25 or 30 fps. Confirm it by spot-checking subtitles against the master before conforming.
- The character table. If it is anything other than Latin, stop — the conversion cannot represent the text and you need a different target format.
- Whether the conform is a pulldown or a re-time. A 25 to 29.97 fps change can be a speed change or a straight re-conform depending on how the picture was handled. They produce different results.
- The display standard. Teletext STL carries row placement; open-subtitle STL may carry less, which changes how much positioning there is to preserve.
- The target drop frame setting. North American broadcast material is usually drop frame. The delivery spec will state it.
How to convert EBU-STL to SCC
The conform is the step everything else depends on, and it has to be driven by how the picture was converted, not by arithmetic alone.
-
Read the STL header
Confirm the declared frame rate, the character table and the display standard before opening the subtitles. These three fields determine whether the conversion is possible at all. -
Confirm the character table is Latin
If the file declares Cyrillic, Greek, Arabic or Hebrew, stop here. CEA-608 cannot represent those scripts and no conversion setting will change that. -
Open the STL and verify the text
Check that accented characters render correctly. A mis-declared character table produces plausible but wrong text. -
Establish how the picture was converted
Find out whether the 25 to 29.97 change was a speed change or a re-conformed edit. This determines whether the subtitles need scaling or re-timing against the new master. -
Conform the timing
Apply the conform that matches the picture treatment, then spot-check subtitles at the head, middle and tail of the programme against the 29.97 master. -
Re-check line lengths
Teletext line length and the 608 32-character limit are not the same measurement. Review every line rather than assuming lines that fitted before still fit. -
Map placement onto the 608 grid
Teletext offers more rows than the 15 available in 608. Review any subtitle deliberately placed away from the default position. -
Set the channel and drop frame mode, then export
Assign the caption service, normally CC1, set drop frame to match the master, and export with correct parity and separators. -
QC against picture
Play back against the 29.97 master, checking the tail of the programme as carefully as the head. Conform errors accumulate.
What breaks, and how to catch it
The failure signature of this conversion is a file that is perfect for the first act and wrong by the third.
- A relabelled frame rate. Changing a header field is not a conform. Nothing moves, and the subtitles slip roughly one second every twelve minutes against the new master.
- The wrong conform type. A speed change and a re-time produce different timings from the same source. Applying the wrong one starts in sync and ends badly out.
- A non-Latin character table. The text cannot be represented in 608. Characters are dropped or blocked, and the failure is total rather than partial.
- Line length assumptions. Teletext control codes occupy character cells, so a line that fits on air in teletext may not fit in 32 characters, and vice versa.
- Compressed row placement. Teletext has more rows than the 608 grid. Subtitles raised to clear graphics can land back over them after the remap.
When not to convert EBU-STL to SCC
The frame rate constraint is the reason to consider a different target, and it usually points at one specific alternative.
- The spec allows MCC. MCC declares its own frame rate, so a 25 fps caption file can be delivered without any conform at all. This removes the single biggest risk in the job.
- The character table is not Latin. Convert to IMSC or WebVTT instead, both of which are Unicode-based.
- The destination is streaming. Converting STL to IMSC preserves positioning and styling that 608 discards.
- The picture has not been converted yet. Conform the subtitles against the finished 29.97 master, not against an assumption of what it will be.
If the delivery spec is ambiguous about 608 versus 708, the MCC reference covers what each carries and why MCC is usually the safer answer for non-29.97 source material.
EBU-STL to SCC questions
Specific questions about this conversion. For the formats themselves, see the EBU-STL and SCC references below.
Because the frame rate was relabelled rather than conformed. STL runs at 25 fps and SCC at 29.97 fps, and SCC has no frame rate field — only a timecode separator indicating drop frame or non-drop. If the subtitle timings were not recalculated, every event stays where it was and slips progressively. Spot-check the last reel, where the error is largest.
Mostly. The teletext palette and the seven CEA-608 colours overlap closely, so a converter can usually find a direct match rather than an approximation. Where it matters is speaker identification: if a programme uses more distinct colours than 608 offers, two speakers can end up sharing one colour and the distinction is lost.
It is discarded. The STL header carries programme title, episode number, translator name and reel information, and SCC has no metadata fields at all — it is a header line and byte pairs. Keep the original STL if that information matters for your archive, because it cannot be recovered from the SCC.
If the specification permits it, yes. MCC declares its own frame rate, so a 25 fps source can be delivered at 25 fps with no conform and therefore no opportunity for drift. SCC forces 29.97 fps, which means the conform is mandatory and becomes the riskiest step in the job.
No. This is a hard limit rather than a quality trade-off. CEA-608 defines code points for Latin characters and a set of accented Latin extensions, and nothing else. Convert to IMSC, TTML or WebVTT instead, all of which are Unicode-based and will carry the script intact.
Conform it, do not relabel it
Closed Caption Creator conforms between 25 and 29.97 fps against picture, remaps teletext rows onto the 608 grid, and writes valid SCC with correct parity and separators.
Or deliver MCC at the source rate and skip the conform entirely.