Caption Conversion Guide
Convert SCC to MCC
This conversion loses nothing. The 608 byte stream from the SCC goes into the MCC unchanged, which makes it one of the few genuinely safe conversions in captioning. The interesting part is what you choose to add.
Can you convert an SCC file to MCC?
Yes, and the 608 caption data transfers exactly, because MCC carries the same EIA-608 bytes inside caption distribution packets. The only real decision is whether to generate a CEA-708 service alongside the 608 layer, and what frame rate to declare in the header.
What changes when you convert SCC to MCC
MCC is a superset of SCC, so nothing in this direction is a reduction. Every row below is either an exact transfer or a field you are now able to fill in.
| Property | In the SCC | In the MCC | Result |
|---|---|---|---|
| 608 caption data | The whole file | Carried inside caption distribution packets | Transfers exactly, byte for byte |
| Frame rate | 29.97 fps, implied | Declared explicitly in the header | Stays 29.97 unless you are also conforming |
| Drop frame | Implied by the timecode separator | Signalled explicitly | Read from the separator and written as a header value |
| 708 services | None | Supported, numbered | Optional. Generated from the 608 content if you want them |
| 708 styling | Not applicable | Wider palette, fonts, pen size, edge effects | Available, but only if a 708 service is generated |
| Positioning | 608 character grid | 608 grid, plus 708 windows | The 608 grid transfers. Windows are new if 708 is generated |
| Caption channels | CC1 to CC4 | The same channels, preserved | Transfers |
| File metadata | None | Creation program, date, unique identifier | Written by the exporting tool |
| File size | Literal byte pairs | Shorthand codes for repeated runs | The MCC will be smaller |
Before you start: one decision worth making deliberately
The conversion itself is mechanical. Whether to generate a 708 service is a judgement call that depends on the delivery and on how much you trust downstream decoders.
- Whether the delivery spec requires 708. Some North American specs name 708 services explicitly. Others accept 608 alone carried in an MCC container.
- Whether you are also changing frame rate. MCC can declare any supported rate, so this is the moment a conform becomes possible if the programme needs one.
- The drop frame status of the source. Read it from the SCC's timecode separator, because MCC states it explicitly rather than implying it.
- Which caption channels are populated. If the SCC carries a second language on CC3, decide whether it also becomes a separate 708 service.
- Whether generated 708 styling is wanted at all. A 708 service derived from 608 content adds no information; it adds a second representation of the same captions.
How to convert SCC to MCC
Short, because the caption data needs no translation. The steps are about declaring correctly what the SCC only implied.
-
Open the SCC and note the timecode separator
A colon means non-drop frame and a semicolon means drop frame. This value has to be written explicitly into the MCC header. -
Identify the populated caption channels
Check whether the file carries content on CC1 alone or on additional channels such as CC3 for a second language. -
Decide whether to generate a 708 service
If the delivery specification requires 708, generate it from the 608 content. If not, an MCC carrying 608 alone is a valid and simpler deliverable. -
Set the frame rate to declare
Normally 29.97 fps, matching the source. If you are conforming the programme to another rate, do that here rather than after export. -
Export as MCC
Write the file with the frame rate and drop frame status declared explicitly in the header. -
Verify the round trip
Export an SCC back out of the MCC and compare it against the original. The 608 bytes should be identical, which confirms nothing was altered in the container change.
What breaks, and how to catch it
There is little to break here, which is exactly why the few failure modes get missed.
- A lost drop frame flag. SCC implies drop frame from a punctuation mark and MCC states it as a value. If that translation is wrong, the file drifts by roughly 3.6 seconds per hour.
- An incorrectly declared frame rate. MCC declares its own rate and nothing forces it to match the master. Declaring 29.97 for a 23.976 programme drifts from the first minute.
- Generated 708 that adds nothing. A 708 service derived from 608 content carries the same captions with no additional information. If the spec does not ask for it, it is complexity without benefit.
- Dropped secondary channels. If the SCC carries Spanish on CC3, confirm the channel survived the conversion rather than only checking CC1.
When not to convert SCC to MCC
This is a safe conversion, so the exceptions are about whether it is useful rather than whether it works.
- The delivery spec names SCC. Then deliver SCC. MCC's advantages are irrelevant if the receiving system expects a 608 sidecar.
- You expect 708 styling to change how captions look on air. It generally will not. Consumer decoders let viewers override caption appearance, and those settings usually win.
- The destination is streaming or the web. IMSC or WebVTT is the appropriate target, not another broadcast container.
The MCC format reference covers what the 708 layer genuinely adds and where its limits are.
SCC to MCC questions
Specific questions about this conversion. For the formats themselves, see the SCC and MCC references below.
Only if you ask for them. The conversion itself carries the 608 data into an MCC container, and an MCC holding 608 alone is perfectly valid. A 708 service can be generated from the same content, but it is a second representation of captions you already have rather than new information. Generate it when the delivery spec requires 708, not by default.
Not from the 608 layer, which is byte-identical. If you generate a 708 service, it can request a wider colour palette, specific fonts and edge effects — but consumer decoders let viewers set their own caption appearance, and those preferences generally override what the file asks for. Treat 708 styling as an improved default, not a guaranteed look.
Yes, and this is the practical reason to move to MCC. SCC is fixed at 29.97 fps while MCC declares its own rate, so converting is the point at which a programme can be conformed to 23.976, 25 or 59.94 fps. Conform the timing deliberately as part of the export rather than declaring a rate the events were not timed against.
Export an SCC back out of the new MCC and compare it against the original file. The byte pairs should match exactly. This round trip takes a minute and is the most direct evidence that the container change altered nothing, which is worth having on a deliverable that will go to playout.
Because MCC substitutes shorthand codes for long runs of repeated bytes, and caption streams contain a great many of those — padding and doubled control codes in particular. The caption content is identical; only the representation is more compact. File size is not a useful indicator of caption completeness in either format.
Same captions, more delivery options
Closed Caption Creator writes MCC with the 608 layer intact, optional 708 services, and the frame rate and drop frame status declared explicitly rather than implied.
Round-trip back to SCC to prove nothing changed, and conform to another frame rate in the same step if the programme needs it.