SCC vs MCC vs EBU-STL: which caption format does your delivery need?

Your delivery spec says "closed caption file required" — and your editor exports SRT. Which format does the spec actually mean? The short answer: US SD/legacy and iTunes-style specs mean SCC, US HD file-based delivery means MCC, and European broadcasters mean EBU-STL. All three carry the same captions; they differ in encoding, frame-rate assumptions, and which side of the Atlantic wrote the spec. This guide is the decision table — what each format is, how to tell which one you're being asked for, and how to produce any of them from the SRT you already have: SRT to SCC, SRT to MCC, or SRT to STL.

The three formats at a glance

How to tell which one your spec wants

Read the delivery document for these signals, in order:

1. An explicit extension — .scc, .mcc, or .stl settles it immediately.
2. A caption standard number — "CEA-608" or "line 21" means SCC; "CEA-708," "DTVCC," or "VANC" means MCC.
3. A tool name — "Scenarist" means SCC; "MacCaption" or "CaptionMaker" means MCC.
4. Geography — a European broadcaster, or any mention of "EBU" or teletext page numbers (like "page 888"), means EBU-STL.
5. Frame rate — a 25 fps deliverable is almost certainly European, pointing to STL; 29.97 points to the American formats.

When a US spec accepts "SCC or MCC," send SCC — it's smaller, simpler, and every ingest system reads it. When in doubt, ask the delivery coordinator; nobody minds that email, and everybody minds a rejected deliverable.

What actually differs under the hood

SCC is the rawest of the three: CEA-608 caption bytes as hex pairs, one pair per NTSC frame, exactly as they'd be broadcast on line 21 of an analog signal. It's locked to 29.97 fps and to the 608 character set — fine for English, workable for Spanish and French, limiting beyond that. Full SCC explainer here.

MCC wraps caption data in the CEA-708 Caption Distribution Packets that HD broadcast servers ingest: one checksummed ancillary packet per video frame, at any standard frame rate. In practice the captions ride the 608 compatibility track inside those packets, so SCC and MCC usually carry identical caption content in different envelopes. The per-frame packets are why MCC files run to megabytes. Full MCC explainer here.

EBU-STL is the odd one out: a binary format with a fixed 1024-byte header and 128-byte subtitle blocks, built for European teletext and open subtitling at 25 fps. It has the best character support of the three — the ISO 6937 model covers the full Latin repertoire including ü, ß, and ç — which matters for the multilingual European market it serves. Full EBU-STL explainer here.

Two things none of them are: subtitle interchange formats (that's SRT's job — human-readable, millisecond-timed, understood everywhere), and interchangeable with each other by renaming. Each requires real encoding.

Converting between them

Since all three formats reduce to the same thing — timed caption text — SRT is the natural hub. From one SRT you can produce all three deliverables:

• SRT to SCC — CC1 pop-on captions, drop-frame 29.97 timecode
• SRT to MCC — spec-complete, checksummed caption distribution packets
• SRT to STL — STL25.01 with proper ISO 6937 accents

And each decodes back for editing, translation, or web use: SCC to SRT, MCC to SRT, STL to SRT. CutConvert's decoders are verified against reference implementations — Comcast caption-inspector's decodes for SCC and MCC (760 of 760 captions matched across three real broadcast files), and IRT's published conversion pipeline for STL (63 of 63 cues, frame-exact).

FAQ

Are SCC, MCC, and STL interchangeable? No. They usually carry the same caption text, but the encodings are unrelated — hex 608 pairs, CEA-708 ancillary packets, and binary ISO 6937 blocks respectively. Renaming the extension never works; converting between them means decoding one format and encoding another.

My US spec says "closed captions" with no format — which do I send? Ask if possible. Failing that: SD or iTunes-style delivery almost always means SCC; HD file-based delivery increasingly means MCC. SCC is the safer default when the spec accepts either.

Which format should I use for Netflix or streaming platforms? Generally none of these — major streamers ask for TTML/IMSC subtitle files (Netflix) or platform-specific formats. SCC/MCC/STL are broadcast and archive deliverable formats; check the platform's current delivery spec.

Can one SRT produce all three formats? Yes — that's the practical workflow: master your subtitles as SRT, then encode whichever deliverable each spec requires. The caption text and timing stay identical; only the envelope changes.

Why does my 25 fps project need STL instead of SCC? SCC is structurally locked to 29.97 fps NTSC — it cannot represent 25 fps timing. European 25 fps deliverables use EBU-STL, which was designed for exactly that.

Do accented characters survive in all three formats? Best in EBU-STL (full Latin ISO 6937: ü, ß, é, ç and more). SCC and MCC use the CEA-608 character set — good coverage for Spanish and French, but smart quotes, em dashes, and some accented capitals get transliterated.