Caption Format Reference
SCC File Format (.scc)
Scenarist Closed Captions is the default closed caption deliverable across North American broadcast and post. This page covers what an SCC file can carry, what it cannot, and exactly what changes when you convert one to or from another format.
What can an SCC file be converted to?
An SCC file can be converted to any timed-text format that accepts 29.97 fps timing, including SRT, WebVTT, TTML, IMSC, MCC, EBU-STL and PAC. MCC is the only lossless target, because it preserves the original EIA-608 byte stream. Every other target discards or reinterprets SCC's control codes.
SCC at a glance
SCC is a plain text file, but it is not a list of subtitles. It is a frame-accurate instruction stream for a caption decoder, which is why it behaves differently from every text-based subtitle format you have used.
| Property | Value |
|---|---|
| Full name | Scenarist Closed Captions |
| Extension | .scc |
| Caption standard | EIA-608 / CEA-608 (line 21) |
| File encoding | Plain text ASCII; every data byte carries odd parity |
| Frame rate | 29.97 fps only, drop frame or non-drop frame |
| Timing model | Start only. There is no duration or end-time field |
| Caption grid | 32 columns by 15 rows |
| Styling | Italics, underline, and seven text colours |
| Caption channels | CC1 to CC4, plus text services |
| Governing spec | US decoder requirements published at 47 CFR 15.119 |
| Closed Caption Creator | Read and write |
For the byte-level walkthrough — control codes, odd parity, and why every command appears twice — see what is an SCC file.
What SCC can and cannot carry
Most conversion problems are not bugs. They are a format being asked to hold something it has no field for. This table is the short version of what fits inside EIA-608.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | Upper and lower case |
| Italics | Yes | Set per row or mid-row |
| Underline | Yes | Set per row or mid-row |
| Text colour | Yes | Seven colours only: white, green, blue, cyan, red, yellow, magenta |
| Positioning | Yes | Row and column on the 32 by 15 grid, not pixel coordinates |
| Pop-on, roll-up, paint-on | Yes | Declared by control code, not by a style attribute |
| Accented Latin characters | Partial | Extended character sets cover common Spanish, French, Portuguese and German characters |
| Non-Latin scripts | No | No Cyrillic, Greek, Arabic, Hebrew or CJK. There is no code point for them in 608 |
| Fonts and text size | No | Appearance is decided by the decoder, not the file |
| Explicit end times | No | A caption stays on screen until a later erase command clears it |
| Frame rates other than 29.97 | No | Material at 25 or 23.976 fps must be conformed before export |
| Two languages in one file | Yes | Typically English on CC1 and Spanish on CC3 |
Who asks for SCC files?
SCC outlived the DVD authoring tools it was built for because the underlying 608 standard is stable, freely published, and still what North American playout expects.
- US broadcast playout and network deliverable specs, where a 608 sidecar is the accepted form of a caption file.
- Cable and satellite distribution falling under FCC captioning obligations.
- DVD and Blu-ray authoring, the format's original purpose.
- Media asset management and transcoding systems that embed 608 data into a mezzanine file.
- Post houses conforming a programme to a US network specification after an international edit.
If your delivery target is streaming rather than broadcast, you are more likely to be asked for IMSC or TTML. If it is European broadcast, it will usually be EBU-STL.
How do I open an SCC file?
You can open an SCC file in any text editor, but you will not see captions. You will see a header line, timecodes, and rows of hexadecimal byte pairs. The words are in there, encoded as 608 character bytes with a parity bit set on each one.
To read the captions you need something that decodes the byte stream back into text, timing and placement. That means a caption editor, a QC tool, or a converter — not Notepad.
Avoid hand-editing the hex. Every byte carries odd parity, so typing a plain ASCII value into the payload produces a byte the decoder treats as corrupt, and most decoders render corrupt bytes as a solid block on screen.
Converting SCC to another format
Converting out of SCC means decoding a control-code stream into discrete cues with start and end times. The text always survives. Everything the 608 control codes were doing may not.
| Convert SCC to | What survives | What to watch for |
|---|---|---|
| MCC | Everything | The only lossless target. The 608 byte stream is preserved and 708 services can be added alongside it. |
| SRT | Text and line breaks | Colour, placement and channel data are dropped. Italics survive only as <i> tags, which is a convention rather than part of the SRT specification. |
| WebVTT | Text, italics, approximate placement | The character grid becomes percentage-based cue settings. Colours have to move to CSS classes the player may not load. |
| TTML / IMSC / DFXP | Text, styling, placement | Requires a region and style model. Grid rows become regions, so review the layout rather than assuming a clean map. |
| EBU-STL | Text and colour | STL is a 25 fps format. The events must be re-timed, not relabelled, or the file drifts against picture. |
| PAC | Text, colour, placement | PAC is a subtitle format with its own code pages. Latin-script content maps cleanly; timing must be conformed to the target rate. |
| Cavena 890 | Text and placement | Another rate-specific broadcast format. Conform the timing first, then export. |
| SAMI | Text and basic styling | Legacy format. Styling moves into CSS classes in the file header. |
Converting another format to SCC
Converting into SCC is the harder direction. The converter has to re-encode your captions as 608 control codes, and where the source has no equivalent data it has to choose a default on your behalf.
| Convert to SCC from | What carries over | What the conversion has to decide |
|---|---|---|
| MCC | Everything | Extract the 608 service and discard the 708 services. Lossless when the MCC was built from 608 in the first place. |
| SRT | Text only | Placement, line wrapping to 32 characters, and a 29.97 fps timing base. SRT supplies none of these. |
| WebVTT | Text, italics, rough placement | Cue settings snap to the character grid, and CSS colours must reduce to the seven 608 colours. |
| TTML / IMSC / DFXP | Text, styling, placement | Fonts, sizes and arbitrary colours collapse. Region layouts must be mapped onto 15 rows. |
| EBU-STL | Text and colour | A 25 to 29.97 fps conform is mandatory. Teletext colours map onto the 608 palette. |
| PAC | Text, colour, placement | PAC code pages carry Arabic, Hebrew, Cyrillic and Greek, none of which exist in 608. Latin-script PAC converts cleanly; other scripts do not convert at all. |
| Cheetah CAP | Text and placement | Confirm which CAP variant you have. The binary and ASCII forms are different files with the same extension. |
| Transcript (DOCX, TXT, CSV) | Text only | Everything else. A transcript has no timing, so the captions have to be timed before an SCC 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 SCC deliveries go wrong
Four failures account for most rejected SCC files.
- The wrong timecode separator. A colon means non-drop frame and a semicolon means drop frame. Swapping them drifts the captions by roughly 3.6 seconds per hour.
- Broken parity. Usually the result of hand-editing the hex payload. The decoder draws a solid block where the corrupt byte was.
- A relabelled frame rate. Changing the separator is not a conform. The events themselves have to be re-timed.
- Exceeding the 608 data rate. Only two bytes per frame are available, and every control code is sent twice. Dense dialogue arrives late or gets truncated.
Each of these is covered in detail, with example bytes, in the SCC format deep dive. For delivery checks across formats, see how to QC closed captioning and subtitles.
SCC conversion questions
Common questions about moving captions into and out of the Scenarist Closed Caption format.
Nothing is lost, because an SRT file carries almost nothing to lose. The risk runs the other way: SRT has no positioning, no colour and no channel data, so the conversion has to invent them. A converter places every caption at a default row, re-wraps lines to 32 characters, and rebases the timing to 29.97 fps. Review the placement before delivery.
Approximately. SCC positions text on a fixed 32 by 15 character grid, while WebVTT positions cues as percentages of the video frame using line and position cue settings. A converter maps one to the other, so captions land in roughly the right place, but a caption tucked around a lower third will not be pixel-identical to the 608 original.
Only MCC, and only when the MCC was built from 608 data in the first place. MCC carries the original EIA-608 byte stream alongside CEA-708 services, so extracting 608 back out to SCC returns the same bytes. Every other source format has to be re-encoded into 608 control codes, which involves decisions a converter makes on your behalf.
Because SCC has no frame rate field to change. The format is 29.97 fps only, and the sole timing hint in the file is the timecode separator: a colon for non-drop frame, a semicolon for drop frame. If a tool relabels the separator instead of re-timing the caption events, the text stays where it was and drifts against the video by roughly 3.6 seconds per hour.
Yes. EIA-608 defines four caption channels, CC1 to CC4. A common North American deliverable carries English on CC1 and Spanish on CC3. Both live in the same SCC file and the viewer's decoder selects the channel. Most players and web platforms only surface CC1, so a second channel is often invisible outside broadcast playout.
YouTube accepts SCC uploads and decodes them. Most HTML5 web players do not, because browsers expect WebVTT. If your captions are destined for a website, convert SCC to WebVTT and keep the SCC as the broadcast deliverable. Converting once and delivering both files is normal practice.
Open, edit and deliver SCC without touching hex
Closed Caption Creator decodes EIA-608 byte pairs into an editable timeline, then writes a valid SCC back out with correct parity, separators and channel assignment.
Convert between SCC and 30+ other caption and subtitle formats, conform frame rates, and QC the result before it goes to playout.