Caption Conversion Guide
Convert MCC to SCC
This is the least destructive conversion in North American captioning and the one most often assumed to be trivial. The 608 data inside an MCC transfers byte for byte. What you have to decide is which service to read and what to do if the file is not 29.97 fps.
Can you convert an MCC file to SCC without losing captions?
The 608 layer transfers exactly, because an MCC already contains EIA-608 data. What is lost is everything outside it: the CEA-708 services and their richer styling. The one hard constraint is frame rate — SCC exists only at 29.97 fps, so any other rate must be conformed first.
What changes when you convert MCC to SCC
MCC is a superset of SCC. Almost every row below is a case of the target simply having nowhere to put something the source carried, rather than a lossy translation.
| Property | In the MCC | In the SCC | Result |
|---|---|---|---|
| 608 caption data | Carried inside caption distribution packets | The same 608 byte stream | Transfers exactly. This is the lossless part |
| 708 services | One or more numbered services | Not supported | Discarded entirely |
| Frame rate | Declared in the header: 23.976 to 60 fps | 29.97 fps only | Anything other than 29.97 requires a conform before export |
| Drop frame | Signalled explicitly in the header | Implied by the timecode separator | Must be carried across correctly or the file drifts |
| 708 styling | Wider colour palette, fonts, pen size, edge effects | Seven colours, italics, underline | Reduced to what 608 expresses |
| Positioning | 608 grid plus 708 windows | 608 character grid only | The 608 grid positions transfer. Window layouts are discarded |
| Multiple languages | 608 channels plus separate 708 services | 608 channels only | A second language survives only if it is on a 608 channel |
| File metadata | Creation program, date, unique identifier | None | Discarded |
| Compression | Shorthand codes for repeated byte runs | Literal byte pairs | Expanded on export. The SCC will be larger |
Before you start: two decisions the file cannot make for you
An MCC can carry several caption services at different frame rates of the same programme. Converting without choosing deliberately produces a technically valid file with the wrong content in it.
- Which caption service to extract. A file may hold a 608 channel and multiple 708 services. English and Spanish commonly live in the same file.
- The declared frame rate. Read it from the header. If it is not 29.97 fps, a conform is required and should be planned rather than discovered at export.
- Whether the delivery actually needs SCC. If the spec accepts MCC, converting removes capability for no benefit.
- The drop frame status. MCC signals it explicitly; SCC implies it from the timecode separator. The value has to survive the translation.
- Whether a 708 service carries content the 608 layer does not. Some files caption more thoroughly in 708. Check before discarding it.
How to convert MCC to SCC
Most of the work is verification rather than conversion, because the caption data itself needs no translation.
-
Read the MCC header
Note the declared frame rate and drop frame status. These determine whether a conform is needed and what separator the SCC should use. -
List the caption services in the file
Identify which 608 channels and 708 services are populated, and confirm which one the delivery specification asks for. -
Compare the 608 and 708 content
Check that the 608 layer is complete. Occasionally a file is captioned more thoroughly in 708, in which case extracting 608 loses content rather than just styling. -
Conform the frame rate if required
If the MCC is not 29.97 fps, conform the timing against picture before exporting. SCC has no frame rate field to carry an alternative. -
Select the caption channel to export
Choose the 608 channel that matches the delivery, normally CC1 for the primary language. -
Export as SCC
Write the file with correct odd parity and a timecode separator matching the drop frame status from the MCC header. -
QC against picture
Confirm placement and timing, and verify that the caption style — pop-on, roll-up or paint-on — matches the original.
What breaks, and how to catch it
Because the caption data itself is preserved, every failure here is a selection or timing error rather than a corruption.
- Extracting the wrong service. The output is a perfectly valid SCC containing the wrong language or an incomplete caption pass. Always confirm which service the spec names.
- An unconformed frame rate. An MCC at 23.976 or 25 fps exported as SCC without a conform produces immediate and growing drift.
- A lost drop frame flag. MCC states it, SCC implies it. If the separator does not match the source, the file drifts by roughly 3.6 seconds per hour.
- Discarding a richer 708 pass. Where 708 carries more complete captioning than 608, the SCC is missing content, not just styling. Compare before exporting.
- Assuming positioning survives. 608 grid positions transfer, but 708 window layouts do not. A file that relied on windows will place differently.
When not to convert MCC to SCC
This conversion removes capability. It is worth confirming that something actually requires it.
- The delivery spec accepts MCC. Then deliver MCC. It carries everything SCC does plus 708 services and any frame rate.
- The master is not 29.97 fps. Converting forces a conform that MCC would let you avoid entirely.
- The programme relies on 708 features. If styling, window positioning or a second language service is carrying meaning, SCC cannot hold it.
- The destination is streaming. IMSC is the appropriate target and preserves far more than either 608 format.
The MCC format reference covers what the 708 layer adds and when it is worth keeping.
MCC to SCC questions
Specific questions about this conversion. For the formats themselves, see the MCC and SCC references below.
For the 608 caption data, yes — an MCC already contains EIA-608 bytes, so extracting them returns the same data unchanged. It is not lossless for the file as a whole. The 708 services, their styling, the file metadata and any window-based positioning are all discarded, because SCC has nowhere to put them.
Whichever the delivery specification names, which for a primary-language North American deliverable is almost always the 608 channel CC1. Check what the file actually contains first: an MCC can carry several 708 services alongside the 608 channels, and a second language such as Spanish frequently lives in the same file.
It has to be conformed before export, because SCC supports no other rate. That is a genuine re-timing of every caption event against picture, not a header change. If the specification allows MCC as the deliverable, the better answer is usually to skip the conversion and deliver the MCC at its native rate.
MCC uses shorthand codes in place of long runs of repeated bytes, which are extremely common in caption streams. SCC writes those bytes out literally. The expansion is expected and does not indicate a problem — the caption content is identical.
No. SCC is defined as a carrier for EIA-608 data and has no concept of 708 services. If the 708 layer matters, the deliverable has to be MCC or the caption data has to be embedded in the video itself. Converting to SCC and back does not recover them.
Extract the right service, at the right rate
Closed Caption Creator reads every caption service in an MCC, lets you choose which to export, and conforms the frame rate against picture when SCC forces 29.97.
Or keep the MCC as your caption master and generate SCC only when a client asks for it.