CEA-608, SCC and EBU-STL: broadcast caption formats explained

Two file formats keep turning up wherever a caption workflow touches broadcast or OTT delivery: SCC, the plain-text file built to carry CEA-608 line-21 captions, and EBU-STL, the binary subtitle exchange format the EBU published in 1991. Both predate most of the tools people now use to open them, and neither has been retired.

The EBU has said so directly. Its 2017 mapping spec, EBU Tech 3360 ("EBU-TT, Part 2 — Mapping EBU STL (Tech 3264) to EBU-TT Subtitle Files"), opens by noting that "the EBU STL subtitle file format (EBU Tech 3264) is currently widely used as an archiving and exchange format." Rather than deprecate STL, the EBU published a formal mapping from it to EBU-TT: a bridge, not a replacement notice.

This guide covers what each format actually contains: how a CEA-608 caption is structured before it ever becomes an SCC file, and what sits inside the GSI and TTI blocks of an STL. CueForge reads and writes both, along with TTML/IMSC, Apple’s iTT, MacCaption MCC and EBU-TT-D, and converts any of them to editable SRT or VTT.

Convert SCC or EBU-STL to SRT (Pro · 7-day free trial) →

CEA-608 and the SCC file that carries it

CEA-608 (originally EIA-608, now formalized as ANSI/CTA-608, "Line 21 Data Services") defines caption data historically carried in line 21 of an analog NTSC signal, and later digitized the same way inside SDI. No single body owns the whole stack end to end: SMPTE’s EG 43 and the W3C Text Tracks Community Group each describe pieces of it, and SCC itself is a de facto file format with no publishing standards body behind it at all. That is an unusual amount of infrastructure to run on a format nobody formally owns.

A 608 stream carries four caption services, two per video field: CC1 through CC4. CC1 is the primary synchronous caption service and normally carries the main-language captions. CC3 is the secondary synchronous caption service; using it for a second language is FCC convention rather than anything in the service’s name, and some broadcasters route that second language through CC2 instead, because older decoders in the field never implemented CC3 support.

Captions display in one of three modes. Pop-on assembles a caption in an off-screen buffer and swaps it onto the picture all at once, on an End of Caption command. It’s the standard choice for prerecorded programming, since a viewer never sees a caption build line by line. Roll-up scrolls two, three or four rows upward as new lines arrive, the look most live news captioning has. Paint-on writes characters to the screen as they are received, with no off-screen buffering step at all. Underneath all three, the decoder holds two 32-column by 15-row character memories, but the displayed-while-composing swap is pop-on’s mechanism specifically: roll-up and paint-on write into the displayed memory directly.

Every data byte in a 608 stream carries odd parity, so a decoder can flag a corrupted byte on sight. That parity check, plus the state machine needed to unwind pop-on, roll-up and paint-on into clean cue in/out times, is what turns a raw 608 byte stream into something an SRT or VTT file can represent. It’s exactly what CueForge’s SCC codec does under the hood.

An SCC file itself is plain text. A Scenarist SCC file opens with a literal header line, "Scenarist_SCC V1.0", followed by one data line per caption event: an SMPTE timecode, then a run of space-separated four-digit hex words, each one a raw pair of 608 bytes. The separator in that timecode carries real information: a colon means non-drop-frame, a semicolon means drop-frame, and both run on NTSC’s 30000/1001 (≈29.97 fps) timebase. Drop-frame does not discard any video frames; it skips two frame numbers at the start of every minute except every tenth one, so the frame count catches back up with real clock time.

CEA-708, the digital ATSC captioning standard, carries CEA-608 data inside itself for exactly this kind of backward compatibility: a 708-capable decoder can fall back to the embedded 608 stream when native 708 caption data is not present, which is why line-21-era captions still show up correctly on a modern digital set.

The MacCaption MCC file (.mcc) is the text container that carries a CEA-708 stream for HD broadcast delivery, with the backward-compatible CEA-608 field-1 track packed alongside it. CueForge reads and writes MCC as a Pro feature. It runs on the 29.97 fps drop-frame timebase only — the same NTSC timebase SCC uses — and carries italics, underline and the CEA-608 caption colours over a Latin-1 character set, so it holds Latin-script captions rather than Arabic or other non-Latin text.

CueForge reads SCC files as a Pro feature and converts them straight to SRT: convert SCC to SRT.

EBU-STL: the 1991 exchange format

EBU-STL traces back to a single document: EBU Tech 3264-E, "Specification of the EBU Subtitling data exchange format," published in February 1991. The spec is explicit about its original medium: subtitle exchange on a 1.44 MB 3.5-inch floppy disk, formatted for an IBM PC/XT/AT running MS/PC-DOS 3.3, with the file extension .STL. The extension and the internal structure have not changed since; only the floppy disk is gone.

Structurally, an STL file is one 1024-byte GSI (General Subtitle Information) block followed by a sequence of 128-byte TTI (Text and Timing Information) blocks. The GSI’s first 448 bytes are EBU-specified fields, among them the Disk Format Code and the Character Code Table selection, and the remaining 576 bytes are left user-definable.

Text encoding is chosen per file from five Character Code Tables named in the GSI: CCT 00 is Latin, based on ISO 6937/2-1983; CCT 01 through 04 pair Latin with Cyrillic, Arabic, Greek or Hebrew, via ISO 8859-5, -6, -7 and -8 respectively. Separately, the GSI block’s own descriptive text fields (programme title and similar metadata, not the subtitle text) use an MS/PC-DOS code page (437, 850, 860, 863 or 865), chosen by its own Code Page Number field, a different encoding entirely from whichever CCT the subtitle text uses.

CCT 00 is worth understanding in detail, because it is the source of a specific, recurring bug: it is ISO 6937, not Latin-1, and ISO 6937 orders its diacritics backwards from how a person reads them. The non-spacing diacritical marks sit in the byte stream before the base letter they modify, not after: the two-byte sequence 0xC1 0x61 decodes to à, accent byte first, base letter second. Run an STL text field through a tool that assumes Latin-1 and every accented character comes out garbled, because ISO 6937 simply does not store bytes in reading order. CueForge’s decoder maps each diacritic byte to its Unicode combining mark, appends it after the base letter, and normalizes the result to NFC; encoding reverses the process, decomposing the text to NFD and mapping the combining mark back to the prefix byte.

Timing lives in the TTI block: Time Code In and Time Code Out are each four binary bytes, hours/minutes/seconds/frames. The valid frame range depends on the GSI’s Disk Format Code: 0 through 24 under STL25.01 (25 fps), or 0 through 29 under STL30.01 (30 fps). The GSI separately carries the programme’s own start timecode.

A subtitle whose text will not fit in one TTI block’s 112-byte text field spills into an Extension Block Number (EBN) chain: additional TTI blocks carrying the overflow text, with only the first block of the chain holding the actual timing and position bytes. A chain can run up to 256 blocks, and 0xFF in the EBN field marks the last block (or the only one, for a subtitle short enough to need no chaining). CueForge writes these chains itself rather than truncating long subtitle text, and preserves the GSI block verbatim through a round trip.

One more GSI field is worth knowing: the Display Standard Code, which distinguishes open subtitling from Level-1 or Level-2 teletext presentation. It tells a receiving system how the subtitle is meant to be shown, not just what it says.

CueForge reads EBU-STL as a Pro feature and converts it straight to SRT: convert EBU-STL to SRT.

Converting out of (and into) these formats

CueForge never converts one broadcast format directly into another. Every import parses into the same canonical model first: integer-millisecond timing, plus structured spans for italics, bold, underline and colour. Every export serializes back out of that same model. A round trip through CueForge is content-identical, not byte-identical: the timing, text and styling all survive, but the container bytes do not come back unchanged, because they were never meant to.

What survives the trip out of SCC or STL: cue text, start/end timing down to the millisecond even though both source formats express time in frames, italics and underline, and CEA-608’s caption colours, which CueForge carries into SRT as <font color> tags — a widely supported SRT extension rather than part of the bare format, so a strictly plain-text player can ignore them. STL’s justification code maps onto line alignment in targets that can express it, like VTT; SRT has no positioning syntax at all, so alignment drops there. What does not survive: STL’s vertical position is kept only as raw round-trip data, so an STL re-export gets it back but no other export format reads it; an SCC file carries a single video field’s byte pairs, so it holds at most that field’s two services — CC1 and CC2, with CC3 and CC4 living in field two, conventionally delivered as a separate file — and CueForge decodes the primary CC1 service; and the difference between pop-on, roll-up and paint-on, how a caption was revealed on screen, is not something SRT/VTT’s static start/end cue model can represent at all. The converted file keeps the same words at the same times; it just cannot keep the reveal style, because the target format was never built with that concept.

The same parse-then-serialize path handles TTML/IMSC and Apple’s iTT, both XML timed-text formats rather than line-21 or binary-block ones, but squarely in the same broadcast/OTT-delivery bucket. Converting straight to editable SRT: convert TTML to SRT and convert iTT to SRT follow the same path as the SCC and STL converters above: Pro reads the file (7-day free trial), the SRT export itself is free, and a folder of them can run as one batch in your browser.

CueForge also reads and writes EBU-TT-D (EBU Tech 3380), an XML distribution profile the EBU defines for subtitle delivery over IP. Unlike MCC’s Latin-1 range, EBU-TT-D carries the full Unicode set, including Arabic and other right-to-left scripts, and it expresses italics, bold, underline, colour and text positioning. The delivery direction works the same way: build or repair a subtitle as SRT, then export it as broadcast-ready captions — convert SRT to MCC or convert SRT to EBU-TT-D. MCC exports on the 29.97 fps drop-frame timebase with Latin-script text; EBU-TT-D exports the full Unicode range. Both writing paths are a Pro feature, and reading the SRT source stays free.

Check for free, deliver with Pro

Reading SCC, EBU-STL, TTML/IMSC, iTT, MCC or EBU-TT-D into the CueForge studio is a Pro feature, with a 7-day free trial. Parsing a binary STL block structure or a raw 608 byte stream is not something the free tier does. Once a file is open, though, the QC checks run exactly the same as for any other subtitle format: line length, reading speed, cue duration, timing gaps, overlaps and duplicate cues, all free, no account, no file limit.

That split, check for free once a file is open, pay for the format support that gets it open, is the same posture CueForge takes everywhere. See the Netflix guide for what CueForge checks a subtitle file against once it is loaded, and see FCC caption requirements for the regulatory quality standards these broadcast formats exist to help meet in the first place. Pro is $99/year or $12/month, with a 7-day free trial.

Browse every subtitle converter · Edit subtitles in the browser · Open the CueForge studio