Caption Conversion Guide
Convert CAP to SCC
Converting a .cap file to SCC is usually easy. Working out what the .cap file actually is, is not. At least three unrelated caption formats share the extension, and no amount of renaming will make one tool read another's file.
Can you convert a .cap file to SCC?
Yes, once you know which format the file is. Cheetah, NCI and Videotron Lambda all use the .cap extension and are unrelated. All three are 608-era North American formats, so their text, colour and placement map cleanly onto SCC after the variant is identified.
What changes when you convert CAP to SCC
These are all contemporaries of SCC, built for the same line 21 delivery target, so the conversion is one of the gentlest in captioning. The table below describes the common ground; specifics vary a little by variant.
| Property | In the CAP | In the SCC | Result |
|---|---|---|---|
| Format identity | Cheetah, NCI or Videotron Lambda | Scenarist Closed Captions | Must be identified before anything else works |
| Caption standard | 608-era North American | EIA-608 | Direct mapping. Nothing conceptual is lost |
| Text | Upper and lower case Latin | CEA-608 character set | Transfers cleanly |
| Frame rate | Often implied by the originating system | 29.97 fps only | Confirm the source rate; it is usually 29.97 already |
| Vertical position | Row placement on a 608-style grid | Row 1 to 15 | Direct mapping |
| Horizontal position | Column placement | Column on a 32-column grid | Direct mapping |
| Colour | 608 palette | Seven 608 colours | Transfers exactly |
| Italics and underline | 608 text attributes | 608 text attributes | Transfers exactly |
| Caption style | Pop-on and roll-up | Pop-on, roll-up, paint-on | Transfers, declared by control code |
| End times | Varies by variant | Erase commands | Where the source has explicit out times, they become erase commands |
Before you start: identify the file
Everything else in this job is routine. This step is the one that goes wrong, and it goes wrong silently when a tool half-reads a file it does not actually support.
- Open it in a text editor first. Readable timecodes and caption text mean a plain-text variant such as Cheetah ASCII. Unreadable bytes mean a binary variant.
- Ask where the file came from. Knowing a facility ran Cheetah, or that the asset came off a Lambda system, removes the guesswork entirely.
- Try each candidate in a tool that supports all of them. The correct variant produces sensible text and timecodes. An incorrect one errors or produces obvious nonsense.
- Confirm the frame rate. Several variants imply the rate from the originating system rather than storing it. For North American material it is usually 29.97 fps already.
- Check whether a batch is homogeneous. A folder of
.capfiles may contain more than one variant.
How to convert CAP to SCC
Identification first, conversion second. Reversing that order is how a migration produces a folder of plausible-looking but wrong SCC files.
-
Open the file in a text editor
Determine whether the contents are readable text or binary bytes. This narrows the candidates immediately. -
Identify the variant
Try opening the file as Cheetah binary, Cheetah ASCII, NCI or Videotron Lambda in a tool that supports all four. The correct one produces coherent captions and timecodes. -
Verify the captions read correctly
Check text, timing and placement on a handful of captions spread across the programme, not just the first few. -
Confirm the frame rate against picture
Spot-check the captions against the master. North American source material is usually 29.97 fps, but confirm rather than assume. -
Conform the timing if needed
If the source is not 29.97 fps, conform before export. SCC supports no other rate. -
Set the channel and drop frame mode
Assign the caption service, normally CC1, and set the drop frame status to match the master's timecode. -
Export as SCC
Write the file with correct odd parity and the standard header. -
QC against picture
Confirm placement, caption style and reading speed, then compare against the original to make sure nothing was dropped in the migration.
What breaks, and how to catch it
The conversion itself rarely fails. The identification does, and it fails quietly.
- Misidentifying the variant. A tool that partially parses the wrong format can produce captions that look reasonable but have wrong timings or missing events. Compare caption counts against the source.
- Renaming instead of converting. Changing
.capto.sccsatisfies a filename check and nothing else. The contents are unchanged and no decoder will read them. - Batch-converting a mixed folder. One Lambda file in a folder of Cheetah files will fail or convert to nonsense without stopping the batch. Identify before batching.
- An assumed frame rate. Where the rate is implied by the originating system rather than stored, an incorrect assumption produces drift that grows across the programme.
- Dropped caption events. Partial parsing can silently skip events it does not understand. Compare the number of captions in the source and the output.
When not to convert CAP to SCC
SCC is the natural target for this material, so the exceptions are narrow.
- The master is not 29.97 fps. MCC declares its own rate and avoids the conform.
- The destination is streaming. Convert to IMSC instead, which preserves placement and styling that will matter more on an OTT platform.
- The destination is the web. WebVTT is what browsers expect, and the grid positions map onto cue settings reasonably well.
- You cannot identify the variant with confidence. Converting a file you have not positively identified produces output nobody can trust. Go back to the supplier.
The CAP format reference covers each variant and how to tell them apart.
CAP to SCC questions
Specific questions about this conversion. For the formats themselves, see the CAP and SCC references below.
Open it in a text editor. If you can read timecodes and caption text, it is a plain-text variant such as Cheetah ASCII. If it is unreadable bytes, it is binary, and you need to try opening it as each candidate in a tool that supports Cheetah, NCI and Videotron Lambda. Asking the supplier which system produced it is faster than testing.
No. The extension describes nothing about the contents. An SCC file has a specific header line and a specific hexadecimal structure, and a CAP file has neither. Renaming will get the file past a workflow that checks filenames and then fail at the first tool that actually reads it.
Very little, because these are contemporaries built for the same delivery target. Text, colour, row and column placement, italics and caption style all have direct equivalents in CEA-608. The main risks are not losses in translation but errors upstream: misidentifying the variant, or assuming the wrong frame rate.
Only if every file in it is the same variant, which is worth verifying rather than assuming for an archive that accumulated over years. A mixed folder will produce a mixture of correct files, failures and silent nonsense. Sort by variant first, then batch each group.
Compare the caption count between the source and the output, then spot-check timing at the head, middle and tail. Partial parsing is the specific risk with legacy formats: a tool that half-understands a variant can skip events it does not recognise without reporting an error.
Identify it, then migrate the whole archive
Closed Caption Creator reads Cheetah binary and ASCII, NCI and Videotron Lambda files, so identification is a matter of trying each rather than hunting for four different tools.
Batch the archive through the API once the variants are sorted, and QC the output against the originals.