🎬 Captioning & SubtitlesOctober 3, 20266 min read

SCC vs MCC vs SMPTE-TT: which caption file for broadcast or streaming?

Q: Can I convert directly from SCC to SMPTE-TT?

Yes. CCExtractor can decode an SCC and output SMPTE-TT via --out=smptett . Alternatively, first convert SCC to SRT with CCExtractor ( --out=srt ), then use SeConv to export to SMPTE-TT2052 . The two-step route gives you a chance to edit and QC the text in Subtitle Edit before the final export.

💡 SCC (Scenarist Closed Captions) carries CEA-608 bytes: Latin characters only, 32 columns and 15 rows, used for US broadcast. MCC (MacCaption) wraps both 608 and 708 VANC data in one envelope. SMPTE-TT (SMPTE ST 2052-1) is a TTML XML file for streaming and OTT delivery. For broadcast, deliver SCC. For streaming or 708-class delivery, deliver SMPTE-TT. SCC cannot encode Chinese, Vietnamese, Japanese, or any other CJK text.

Key takeaways

SCC is 608-only: Latin characters, 32-column grid, 15 rows. Produce it with seconv.exe in.srt ScenaristClosedCaptions --fps 29.97 --output-folder out --overwrite. Always verify the decode with caption-inspector.
MCC wraps both 608 and 708 service layers in a MacCaption envelope. Open-source MCC export (Subtitle Edit) has a broken 708 service layer in my testing: caption-inspector cannot decode the 708 data. Do not use it for 708 delivery.
SMPTE-TT (ST 2052-1) is the right format for streaming and OTT 708-class delivery: seconv.exe in.srt SMPTE-TT2052 --output-folder out --overwrite. It uses Unicode and carries full XML styling.
Always QC-decode a finished SCC or MCC with caption-inspector before delivery: docker run --rm -v <dir>:/data nebulabroadcast/caption-inspector -o /data /data/out.scc.
SCC cannot carry CJK text. English closed captions are delivered as SCC; other languages are delivered as separate subtitle tracks (SRT, SMPTE-TT), never as a second 608 stream.

What are SCC, MCC, and SMPTE-TT - and which goes where?

These three formats all carry synchronized caption or subtitle data, but they sit at very different layers of the broadcast and streaming stack. The primary keyword for this article is "SCC vs MCC vs SMPTE-TT caption formats," and the confusion usually starts because broadcasters and streaming platforms each have their own preferred container, with different tools required to produce each one correctly.

SCC (Scenarist Closed Captions) is the classic broadcast container for CEA-608 captions. It holds raw two-byte pairs that a 608 decoder reads line by line. Its character set is limited to Latin-1 plus a small set of extended characters defined in the CTA-608 standard. Every US broadcast deliverable I have worked on over the past several years has started with an SCC at 29.97 drop-frame timecode.

MCC (MacCaption) is a proprietary envelope format from Telestream that compresses VANC (Vertical Ancillary Data). It can carry both CEA-608 bytes in a 608 compatibility layer and CEA-708 data in a separate service layer - in theory. In practice, the 708 service layer in MCC is the weak point of open-source tooling, and the honest advice is to avoid hand-built MCC for 708 delivery.

SMPTE-TT (SMPTE ST 2052-1) is a TTML profile designed for professional interchange and OTT delivery. It is a well-formed XML file using the W3C TTML namespace, with an optional SMPTE-specific extension namespace. Streaming platforms increasingly ask for TTML or its IMSC 1.x subset rather than SCC.

Here is the decision table I use when a new deliverable spec arrives:

Format	Standard	Carries	Character set	Typical target	Production tool
SCC	CTA-608 (EIA-608)	608 caption bytes only	Latin-1 + CTA-608 extended	US broadcast, cable, network affiliates	SeConv `ScenaristClosedCaptions`
MCC	MacCaption proprietary	608 + optional 708 VANC	608 layer: Latin; 708 layer: Unicode	Legacy broadcast (608 + 708 in one file)	CCExtractor `--out=mcc`
SMPTE-TT	SMPTE ST 2052-1 (TTML)	Timed text + XML styling	Unicode (any language)	Streaming, OTT, 708-class delivery	SeConv `SMPTE-TT2052`
SRT / WebVTT	De-facto / W3C	Timed plain text	Unicode	Web video, YouTube, catch-up platforms	SeConv `SubRip` / `WebVTT`

Why is SCC still the standard broadcast deliverable?

SCC has survived as the broadcast deliverable for one reason: every hardware decoder in every TV and set-top box in North America knows how to read CEA-608 bytes. Broadcasters embed those bytes in the VANC data of their video signal, and every receiving device at every step understands the format. Changing that installed base requires a coordinated industry decision that has not happened.

The practical implication: when a US post house or broadcast affiliate sends me a caption spec sheet, it almost always asks for an SCC at 29.97 drop-frame. The timing format is HH;MM;SS;FF with semicolons, which indicates drop-frame, as opposed to the colons used in non-drop timecode. SeConv with --fps 29.97 produces drop-frame SCC output by default, which is correct for NTSC broadcast.

What does a SMPTE-TT file actually look like?

SMPTE-TT is XML, so the structure is visible and editable without a proprietary tool. Here is a minimal but complete SMPTE-TT document based on the ST 2052-1 schema:

<?xml version="1.0" encoding="UTF-8"?>
<tt xml:lang="en"
    xmlns="http://www.w3.org/ns/ttml"
    xmlns:tts="http://www.w3.org/ns/ttml#styling"
    xmlns:ttm="http://www.w3.org/ns/ttml#metadata"
    xmlns:smpte="http://www.smpte-ra.org/schemas/2052-1/2010/smpte-tt">
  <head>
    <metadata>
      <ttm:title>Feature Film Captions</ttm:title>
    </metadata>
    <styling>
      <style xml:id="s1"
             tts:fontFamily="proportionalSansSerif"
             tts:fontSize="100%"
             tts:color="white"
             tts:backgroundColor="transparent"
             tts:textAlign="center"/>
    </styling>
    <layout>
      <region xml:id="r1"
              tts:origin="10% 80%"
              tts:extent="80% 15%"
              tts:displayAlign="after"/>
    </layout>
  </head>
  <body>
    <div>
      <p begin="00:00:01.000" end="00:00:04.000" style="s1" region="r1">
        First caption event.
      </p>
      <p begin="00:00:05.000" end="00:00:08.000" style="s1" region="r1">
        Second caption event.
      </p>
    </div>
  </body>
</tt>

Key fields to know:

xml:lang="en": the BCP 47 language tag for the document. Change to vi for Vietnamese or zh-Hans for Simplified Chinese.
xmlns:smpte=...: the SMPTE ST 2052-1 extension namespace. Only needed if you use SMPTE-specific elements such as smpte:backgroundImage. For plain text delivery, the base TTML namespaces are sufficient.
tts:origin and tts:extent: percentage-based positioning. Netflix TTML requirements mandate percentage values; never use pixel values in a SMPTE-TT file destined for a platform.
begin and end on <p>: wall-clock time in HH:MM:SS.mmm format. SMPTE-TT also supports SMPTE timecode format if declared in the <tt> element via ttp:frameRate.

In practice, I do not hand-write SMPTE-TT. I author the caption file in Subtitle Edit, QC it there for CPS and timing, and then export via SeConv.

How do I produce each format from the command line?

All three broadcast and streaming formats are reachable from a source SRT using SeConv or CCExtractor. These are the commands I run:

# SCC for broadcast (CEA-608, drop-frame 29.97)
seconv.exe in.srt ScenaristClosedCaptions --fps 29.97 --output-folder out --overwrite

# SMPTE-TT for streaming and 708-class delivery
seconv.exe in.srt SMPTE-TT2052 --output-folder out --overwrite

# MCC from a source video with embedded captions (CCExtractor)
ccextractor input.mp4 --out=mcc -o output.mcc

# QC-decode the finished SCC
docker run --rm -v C:/captions:/data nebulabroadcast/caption-inspector ^
  -o /data /data/output.scc

SeConv format name notes:

ScenaristClosedCaptions: produces a .scc file. Always pass --fps 29.97 for NTSC broadcast; set to 25 for PAL.
SMPTE-TT2052: produces a .ttml or .xml file. No FPS flag is needed; timing uses wall-clock milliseconds by default.
--overwrite: prevents SeConv from silently skipping a file that already exists in the output folder. I always add it.
The CCExtractor --out=mcc flag is verified against CCExtractor 0.96.5 --help output on this machine.

The MCC trap: why I deliver SMPTE-TT for 708 instead

In my own testing, the MCC export from Subtitle Edit produced a file where caption-inspector could not decode the 708 service layer: the output showed only the 608 compatibility data. Open-source tools, including CCExtractor's --out=mcc flag, can wrap 608-only content in an MCC envelope, but a real CEA-708 native service with its own fonts, windows, and positioning is beyond what the current free toolchain reliably delivers.

My working rule: if the spec asks for a "708 file," I deliver a SMPTE-TT (ST 2052-1) XML file and note this in my delivery notes. SMPTE-TT carries Unicode text with positioning and styling that matches the intent of 708 delivery for streaming and OTT targets. For a broadcast spec that specifically requires a native MCC with a working 708 service layer, that requires commercial software such as Telestream MacCaption, and I say so upfront rather than delivering something that looks correct but fails the QC decode.

What you can do yourself vs when a specialist is worth it

For most creator and web-streaming work, the path is straightforward: produce an SRT in Subtitle Edit, export to SMPTE-TT or WebVTT with SeConv, and the streaming platform handles the rest. CCExtractor can extract 608 bytes already in a video and convert them to SCC or SRT. Caption-inspector via Docker is free and gives a trustworthy decode check for any SCC or MCC you receive or produce.

The point where a specialist or commercial tool earns its place:

Broadcast SCC at scale: SCC files have a hard 29.97 drop-frame timing requirement. Any frame-rate mismatch shifts every caption downstream. If your source timing is non-drop or 23.976, the conversion needs a careful frame-rate check, not a one-click export.
Native CEA-708 MCC: open-source MCC export does not reliably produce a decodable 708 service layer. Commercial tools are the standard for this, and I say so rather than deliver a file that fails QC.
CVAA and FCC compliance: US internet video under the CVAA requires captions that meet four quality benchmarks: accuracy, synchronicity, completeness, and placement. Compliance records may require a verified caption file. My caption QC service covers how I document and verify this.
Non-English subtitle tracks: I deliver Vietnamese and other language subtitles as separate SMPTE-TT or SRT tracks, not as a second SCC stream. SCC is a Latin-only format and Vietnamese diacritics cannot be encoded in it.

FAQ

Can I convert directly from SCC to SMPTE-TT?

Yes. CCExtractor can decode an SCC and output SMPTE-TT via --out=smptett. Alternatively, first convert SCC to SRT with CCExtractor (--out=srt), then use SeConv to export to SMPTE-TT2052. The two-step route gives you a chance to edit and QC the text in Subtitle Edit before the final export.

Does SMPTE-TT support Vietnamese or Chinese text?

Yes. SMPTE-TT is UTF-8 XML and uses Unicode for all text content. You can include Vietnamese diacritics, Chinese characters, or any other Unicode script in the <p> elements. Set xml:lang on the root <tt> element to the correct BCP 47 tag: vi for Vietnamese, zh-Hans for Simplified Chinese.

What is the difference between SMPTE-TT and IMSC?

IMSC (Internet Media Subtitles and Captions, W3C TTML-IMSC) is a constrained profile of TTML2 for streaming delivery. SMPTE-TT (ST 2052-1) is also a TTML profile, adding a SMPTE-specific namespace for features like image backgrounds. IMSC 1.x incorporates SMPTE-TT extensions for its image profile. A document valid for SMPTE-TT delivery is usually also valid TTML2 and compatible with IMSC requirements when position values use percentages.

How do I know if my SCC file uses drop-frame or non-drop timecode?

Open the SCC file in a text editor and look at the first timestamp. Drop-frame uses semicolons as the last separator: 00;00;01;00. Non-drop uses colons: 00:00:01:00. For NTSC broadcast at 29.97 fps, the timecode must be drop-frame. SeConv with --fps 29.97 produces drop-frame SCC output by default.

Do I need to deliver both an SCC and a SMPTE-TT for the same program?

It depends on the delivery spec. Some streamers and broadcast groups request both: an SCC for the legacy broadcast feed and a SMPTE-TT for the streaming platform. Read the spec before starting production. Re-timing from non-drop to drop-frame after the fact adds a step that is easy to get wrong, so clarify the requirement early.

Official Sources

W3C TTML2 Specification - document structure, namespaces, and element definitions for TTML. Verified Oct 2026.
W3C IMSC 1.3 (TTML-IMSC) - constrained TTML profile for streaming; SMPTE ST 2052-1 namespace confirmed in Appendix I.4. Verified Oct 2026.
Netflix Timed Text Style Guide - General Requirements - percentage-based positioning requirement for TTML delivery. Verified Oct 2026.
CCExtractor (GitHub) - output formats including --out=scc, --out=mcc, and --out=smptett verified via --help (version 0.96.5 on this machine). Verified Oct 2026.
Subtitle Edit / SeConv (nikse.dk) - format names ScenaristClosedCaptions and SMPTE-TT2052 verified via batch converter on this machine. Verified Oct 2026.

Written by Dao Huy (Lucas), Vietnamese translator & localization specialist (EN · ZH · FR → Vietnamese). See translation services →