Caption Format Reference
MCC File Format (.mcc)
MCC is what SCC would be if it had been designed after HD. It carries the same EIA-608 data, adds CEA-708 services alongside it, and drops the single hardest constraint in North American captioning: SCC's fixed 29.97 fps.
What is the difference between an MCC and an SCC file?
Both carry North American closed captions, but SCC holds EIA-608 data at 29.97 fps only. MCC wraps both 608 and CEA-708 services and declares its own frame rate, so it works at 23.976, 25, 50 and 59.94 fps as well. MCC is the superset.
MCC at a glance
MCC is a text file, like SCC, but the payload is a caption distribution packet stream rather than raw 608 byte pairs. That extra layer is what lets one file carry several caption services at once.
| Property | Value |
|---|---|
| Full name | MacCaption Closed Caption file |
| Extension | .mcc |
| Origin | Telestream MacCaption and CaptionMaker |
| Caption standards | EIA-608 and CEA-708, carried together |
| File encoding | Plain text, with a declared version header |
| Frame rate | Declared in the file. 23.976, 24, 25, 29.97, 30, 50, 59.94 and 60 fps |
| Drop frame | Signalled explicitly rather than inferred from a separator |
| Timing model | Start only, as with SCC. Captions clear on an erase command |
| Caption services | 608 channels plus multiple 708 services in one file |
| Compression | Shorthand codes stand in for repeated byte runs, keeping files small |
| Metadata | Creation program, creation date and a unique identifier |
| Closed Caption Creator | Read and write |
For the 608 side of the picture in byte-level detail, see what is an SCC file. For getting caption data into the video itself, see embedding 608 and 708 captions.
What MCC can and cannot carry
Everything SCC can do, MCC can do. The additions are the 708 services, the frame rate flexibility, and a much larger styling vocabulary that downstream decoders honour to varying degrees.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | 608 and 708 services carried side by side |
| Multiple frame rates | Yes | The rate is declared in the file rather than fixed |
| Italics and underline | Yes | In both the 608 and 708 layers |
| Text colour | Yes | Seven colours in the 608 layer, a much wider palette in 708 |
| Background and edge styling | Yes | 708 supports background opacity and character edge effects |
| Fonts and text size | Partial | 708 signals font style and pen size, but the viewer's decoder settings usually win |
| Positioning | Yes | A character grid in 608, and windows in 708 |
| Multiple languages | Yes | Separate 608 channels and separate 708 services in the same file |
| Non-Latin scripts | Partial | 708 supports a wider character set than 608, but decoder coverage is inconsistent |
| Explicit end times | No | Captions clear on an erase command, exactly as in SCC |
| Roll-up, pop-on, paint-on | Yes | Declared by control code |
| Programme metadata | Yes | Creation program, date and unique identifier in the header |
Who asks for MCC files?
MCC turns up wherever SCC's frame rate limit becomes a problem, which in practice means anything shot or finished outside 29.97.
- North American broadcast deliverables at frame rates SCC cannot express, such as 23.976 or 59.94 fps.
- Deliveries that require CEA-708 services rather than 608 alone.
- Titles carrying English and Spanish caption services in a single file.
- Transcode and MAM systems embedding caption data into a mezzanine or playout file.
- Post houses standardising on one caption master and generating SCC from it when a client asks.
If the delivery spec names 29.97 fps and 608 only, SCC is simpler and equally acceptable. If it is a European delivery, EBU-STL applies instead.
How do I open an MCC file?
An MCC opens in a text editor and, like SCC, shows a header and rows of hexadecimal rather than readable captions. Unlike SCC, the header is genuinely informative: it declares the format version, the frame rate and the drop frame status in plain text.
That header is worth reading before anything else, because the frame rate it declares is the single most important piece of information in the file and the one most often assumed incorrectly.
Decoding the captions themselves requires a tool that understands caption distribution packets. The compression shorthand in the payload also means the hex is not a one-to-one map of transmitted bytes, so counting characters by eye does not work.
Converting MCC to another format
Converting out of MCC starts with a decision the format forces on you and SCC does not: which caption service to read. A file may carry a 608 channel and several 708 services with different content.
| Convert MCC to | What survives | What to watch for |
|---|---|---|
| SCC | The 608 layer, exactly | Lossless in this direction when the MCC carries 608. The 708 services are discarded, and the file must be 29.97 fps or be conformed first. |
| SRT | Text and line breaks | Colour, placement and service data are dropped, and end times have to be derived from erase commands. |
| WebVTT | Text, italics, approximate placement | Grid and window positions become percentages. 708 colours reduce to CSS classes the player may not render. |
| TTML / IMSC | Text, styling, placement | The richest target. 708 windows map onto regions reasonably well, but review the result rather than assuming. |
| EBU-STL | Text and colour | A frame rate conform unless the MCC is already 25 fps, plus a mapping onto teletext rows. |
| PAC | Text, colour, placement | Latin-script content converts cleanly. A code page has to be chosen for the target. |
| Embedded video | Everything | The native destination. 608 and 708 data can be written into a MOV, MXF or MP4 with match-source support. |
Converting another format to MCC
Converting into MCC is the same problem as converting into SCC, with two extra decisions: which frame rate to declare, and whether to populate 708 services as well as 608.
| Convert to MCC from | What carries over | What the conversion has to decide |
|---|---|---|
| SCC | The 608 data, exactly | Whether to generate 708 services from the 608 content, and confirming the declared rate stays 29.97 fps. |
| SRT | Text and line breaks | Placement, line wrapping, a frame rate, and a timing base. SRT supplies none of them. |
| WebVTT | Text, italics, rough placement | How percentage cue settings map onto a character grid or 708 windows. |
| TTML / IMSC | Text, styling, placement | Which styling to preserve in 708 and which to flatten for the 608 layer, since both are written from one source. |
| EBU-STL | Text and colour | A frame rate for the target, and whether teletext rows should map to the 608 grid or to 708 windows. |
| PAC | Latin text, colour, placement | Non-Latin scripts cannot be represented in 608 and are unreliable in 708. Check the script before starting. |
| Transcript (DOCX, TXT, CSV) | Text | Everything else. Captions have to be timed before an MCC can exist. |
Closed Caption Creator reads and writes every format in both tables. See the full file format support list, or the conversion API and CLI for batch workflows.
Where MCC deliveries go wrong
MCC removes SCC's frame rate problem and replaces it with a frame rate decision, which is an improvement only if someone makes the decision deliberately.
- A declared rate that does not match the master. MCC states its own frame rate, so nothing forces it to agree with the video. A 23.976 fps master delivered with a 29.97 fps MCC drifts from the first minute.
- Reading the wrong service. A file can carry a 608 channel and several 708 services with different languages. Converting without specifying which one produces the right file with the wrong content.
- Assuming 708 styling will survive to air. Consumer decoders let viewers override caption appearance. Colour and font choices in 708 are requests, not guarantees.
- Treating MCC to SCC as a simple rename. It is a real conversion. The 708 services are discarded and the file has to be at 29.97 fps, which may require a conform.
For QC across caption deliverables, see QC best practices for broadcast captioning.
MCC conversion questions
Common questions about moving captions into and out of the MacCaption MCC format.
Usually both. MCC wraps caption distribution packets, and those packets can carry an EIA-608 channel and one or more CEA-708 services together. That is why extracting SCC from an MCC is lossless: the 608 data is already there, unmodified. A 708-only MCC is possible but uncommon in broadcast deliverables.
Yes, and this is the main practical reason to choose MCC over SCC. The frame rate is declared in the file header rather than fixed by the format, so 23.976, 24, 25, 30, 50, 59.94 and 60 fps are all available. Drop frame status is signalled explicitly rather than implied by a timecode separator.
The 608 content converts exactly, because it is already 608 data. What you lose is everything outside that layer: the 708 services and their richer styling. The other constraint is frame rate — SCC exists only at 29.97 fps, so an MCC at any other rate has to be conformed before the SCC can be valid.
Several, using separate caption services. The 608 layer offers channels in the way SCC does, and 708 allows multiple numbered services alongside them. A typical North American deliverable carries English and Spanish. Whether a viewer can reach the second one depends on the playout chain and the receiving decoder.
Because MCC uses shorthand codes in place of long runs of repeated bytes, which are extremely common in caption streams. The file is a compressed representation rather than a literal frame-by-frame dump, so file size is not a useful indication of how much caption content is present.
No, and you should not design around it. CEA-708 defines fonts, sizes, background opacity and edge effects, but consumer decoders let viewers set their own caption appearance, and those settings generally override what the file requests. Treat 708 styling as a preference that improves the default, not as a guaranteed look.
One caption master, every frame rate
Closed Caption Creator reads and writes MCC with 608 and 708 services intact, and generates SCC, IMSC, WebVTT and SRT from the same project.
Conform between frame rates properly, choose which service to export, and QC the result before delivery.