Caption Conversion Guide
Convert IMSC to SCC
This is the streaming-to-broadcast direction, and it is a reduction at every level. IMSC carries arbitrary colours, percentage-based regions and full Unicode; SCC carries seven colours, a 32 by 15 character grid and a Latin character set. One IMSC variant cannot make the trip at all.
Can you convert an IMSC file to SCC?
Text-profile IMSC converts to SCC with significant reductions: arbitrary colours become seven, regions snap to a character grid, and the output must be 29.97 fps. Image-profile IMSC cannot convert, because it carries subtitles as bitmaps with no text in the file to extract.
What changes when you convert IMSC to SCC
IMSC was designed to express far more than 608 can represent, so most rows below describe a reduction rather than a translation. Check the profile before anything else.
| Property | In the IMSC | In the SCC | Result |
|---|---|---|---|
| Profile | Text profile or image profile | Text only | Image-profile files have no text to convert. OCR is the only route |
| Text encoding | Unicode | CEA-608 character set | Latin script converts. Other scripts have no code points |
| Frame rate | Depends on the declared time base | 29.97 fps only | Read the time base rather than assuming; conform if it differs |
| Timing | Explicit begin and end | Start only, cleared by erase commands | End times become erase commands |
| Positioning | Named regions as percentages of the frame | 32 by 15 character grid | Percentages snap to grid cells. Review anything deliberately placed |
| Simultaneous regions | Multiple regions on screen at once | One caption area | Simultaneous subtitles flatten into a sequence |
| Colour | Arbitrary colours with opacity | Seven colours, opaque | Reduced to the nearest of seven |
| Font and size | Requested by the document | Decided by the decoder | Discarded entirely |
| Forced-display signalling | An explicit attribute | No equivalent | Lost. Forced subtitles become ordinary captions |
| Ruby and text combination | Available in IMSC 1.1 | Not supported | Discarded |
Before you start: check the profile and the time base
Two things in the document header determine whether this conversion is possible and whether the timing will be right. Both are read rather than assumed.
- The profile declaration. If the body contains image elements rather than text, this is an image-profile file and there is no text to convert. Ask the supplier for a text-profile version.
- The declared time base. IMSC can express time as media offsets, clock time or SMPTE timecode. Reading one as another shifts everything.
- The script. Non-Latin content cannot be represented in CEA-608, regardless of profile.
- Whether forced subtitles are in the file. The forced-display signal has no 608 equivalent, so those events need handling deliberately rather than silently becoming captions.
- Whether the layout uses simultaneous regions. If it does, decide the reading order before a converter picks one for you.
How to convert IMSC to SCC
The reductions are unavoidable, so the work is deciding how they happen rather than whether they do.
-
Confirm the file is text profile
Open the XML and check whether the body contains text or image elements. An image-profile file cannot be converted without optical character recognition. -
Read the time base and frame rate
Find the declared time base in the document header. If it is SMPTE, use the frame rate the file states; if it is media or clock time, get the rate from the master. -
Check the script
Verify the content is Latin script. Cyrillic, Greek, Arabic, Hebrew and CJK cannot be represented in CEA-608. -
Review the region layout
Identify which regions are used and whether any subtitles appear simultaneously in different regions. Decide how those should flatten. -
Map regions onto the 608 grid
Convert percentage-based positions to grid rows and columns, then review any subtitle deliberately placed to avoid on-screen graphics. -
Handle forced subtitles explicitly
Decide whether forced events belong in the SCC at all, since the distinction between forced and optional cannot be carried. -
Conform the frame rate to 29.97 fps
Apply a real conform if the source rate differs, then spot-check timing against picture across the whole programme. -
Export as SCC and QC
Set the caption channel and drop frame mode, export with correct parity, and check line lengths, placement and reading speed against picture.
What breaks, and how to catch it
This conversion loses information by design. The problems are the losses nobody decided on.
- An image-profile source. There is no text in the file. A converter may produce an empty or near-empty SCC without a clear error. Check the profile first.
- A misread time base. Media offsets read as SMPTE timecode, or the reverse, shift every subtitle. The file will look internally consistent and be entirely wrong.
- Flattened simultaneous regions. Subtitles that appeared side by side become a sequence, which can reorder dialogue that was never meant to be read in order.
- Lost forced subtitles. Forced events become ordinary captions, so foreign dialogue that should always display now depends on captions being switched on.
- Collapsed speaker colours. Arbitrary colours reduce to seven. Two speakers distinguished by colour can end up sharing one.
When not to convert IMSC to SCC
Given how much is lost, it is worth confirming that a 608 deliverable is genuinely required.
- The file is image profile. Request a text-profile version rather than running OCR. OCR output needs full human correction and the timing is the only reliable part.
- The content is not Latin script. CEA-608 cannot represent it. There is no partial result.
- The master is not 29.97 fps. MCC avoids the conform and carries more styling in its 708 layer.
- Forced subtitles are load-bearing. If a programme depends on forced foreign-dialogue subtitles, SCC cannot express the distinction and a burnt-in or 708 approach may be required.
The IMSC format reference covers the profile differences and what each version adds.
IMSC to SCC questions
Specific questions about this conversion. For the formats themselves, see the IMSC and SCC references below.
Most likely because the source is an image-profile IMSC. That profile carries subtitles as PNG bitmaps rather than characters, so there is no text in the document for a converter to read. Open the XML and look at the body: image elements rather than text confirm it. Ask the supplier for a text-profile version.
The distinction is lost. IMSC signals forced display with an explicit attribute so that foreign-dialogue subtitles appear whether or not captions are enabled. CEA-608 has no equivalent, so forced events become ordinary captions. Decide deliberately whether they belong in the SCC at all, rather than letting a converter merge them in silently.
They snap to the nearest cell on the 32 by 15 character grid. For a subtitle at the bottom centre of frame the result is accurate enough to be invisible. For anything deliberately placed — raised above a lower third, moved to avoid on-screen text — check the output against picture, because grid resolution is much coarser than percentages.
Some of it. The 708 layer in an MCC supports a wider colour palette, font styling and window-based positioning, so more of the IMSC design survives than in a 608-only SCC. Two caveats: consumer decoders let viewers override caption appearance, and the file still cannot carry non-Latin scripts reliably.
Only in that IMSC 1.1 files may use features — ruby annotation, text combination, HDR signalling — that have no CEA-608 equivalent and are simply dropped. The core conversion is the same for 1.0 and 1.1. What matters far more than the version is the profile: text converts, image does not.
Decide the reductions, do not inherit them
Closed Caption Creator maps IMSC regions onto the 608 grid with the result visible against picture, so placement and colour decisions are yours rather than a converter's defaults.
Conform the frame rate properly, and produce the matching MCC when the spec allows something better than 608.