Caption Conversion Guide
Convert PAC to SCC
This is one of the most common conversions in subtitling and one of the easiest to get subtly wrong. Two settings decide whether it succeeds — the PAC's code page and the master's frame rate — and neither of them is reliably stored in the file you were sent.
Can you convert a PAC file to SCC?
Yes, for Latin-script content. PAC's text, colour and row placement all map onto CEA-608, but the timing has to be conformed to 29.97 fps and the file's code page identified first. Arabic, Hebrew, Cyrillic and Greek PAC files cannot convert, because CEA-608 has no code points for those scripts.
What changes when you convert PAC to SCC
PAC and SCC were designed for different jobs: PAC for multilingual subtitling, SCC for North American line 21 captioning. Most properties have an equivalent on both sides. The three that do not are where deliveries fail.
| Property | In the PAC | In the SCC | Result |
|---|---|---|---|
| Text encoding | Code-page bytes, one page per file | CEA-608 character set with odd parity | Latin script converts. Other scripts have no code points and cannot be represented |
| Reading direction | Left-to-right and right-to-left | Left-to-right only | Right-to-left content cannot convert at all |
| Frame rate | Not stored in the file | 29.97 fps only | You have to supply the source rate before anything else is valid |
| Timing | Frame counts at the master's rate | Frames at 29.97 fps | Must be conformed. Relabelling produces progressive drift |
| End times | Explicit out timecode per subtitle | No duration field | Each out time becomes an erase command in the byte stream |
| Vertical position | Row number | Row 1 to 15 on the 608 grid | Maps directly, but the available row counts differ. Check the top and bottom rows |
| Horizontal position | Left, centred or right alignment | Column indent on a 32-column grid | Alignment becomes a column position. Centring is approximate |
| Colour | Subtitle colour palette | Seven 608 colours | Reduced to the nearest available colour |
| Italics | Per subtitle or within a line | 608 italic attribute | Survives intact |
| Line length | Set by the rendering system | 32 characters maximum | Longer lines are re-wrapped, which changes the line breaks a translator chose |
Before you start: two things the file will not tell you
PAC stores neither its language nor its frame rate in a way you can rely on. Both have to come from the delivery paperwork, the master, or the supplier. Guessing either one produces output that looks correct and is not.
- The source language and code page. This determines how the text bytes decode. Applied wrongly, the output is legible nonsense that no automated check will catch.
- The frame rate of the master the PAC was timed against. Usually 25 fps for European material or 23.976 fps for a film-originated title. This drives the conform.
- Whether the SCC should be drop frame or non-drop. Broadcast material is usually drop frame; material built in post is often non-drop. The delivery spec will say.
- Which caption channel the deliverable expects. CC1 in almost every case, unless a second language is being carried on CC3.
- Whether the spec permits re-wrapping. Some clients treat translator line breaks as fixed, which constrains what a 32-character limit can do.
How to convert PAC to SCC
The order matters. Decoding and conforming both have to happen before the export, because neither can be corrected afterwards without starting again.
-
Identify the PAC's language
Confirm the source language with the supplier or the delivery paperwork before opening the file. This determines the code page and cannot be reliably inferred from the bytes. -
Open the PAC with that code page selected
Load the file specifying the source language rather than accepting a default. Read a few subtitles to confirm the text is genuinely correct, not merely readable. -
Check the timing against picture
Load the master and spot-check subtitles at the start, middle and end of the programme. This confirms the frame rate assumption before you build on it. -
Conform the timing to 29.97 fps
Apply a real conform that recalculates every in and out timecode. Do not simply relabel the rate; SCC has no frame rate field to change. -
Review line lengths against the 32-character limit
Find every line that exceeds 32 characters and decide whether to re-wrap or re-edit. Automatic re-wrapping will move the break points a translator chose. -
Set the caption channel and drop frame mode
Assign the caption service, normally CC1, and set drop frame or non-drop to match the delivery specification and the master's timecode. -
Export as SCC
Write the file with correct odd parity and the standard header. Confirm the timecode separator matches the drop frame setting you chose. -
QC the output against picture
Play the SCC back against the video and check placement over lower thirds and on-screen text, plus reading speed at the densest passages.
What breaks, and how to catch it
Each of these produces a file that opens successfully. None of them raises an error in the conversion.
- Non-Latin text. Characters with no 608 equivalent are dropped or rendered as blocks. Check a subtitle containing accented characters before converting the whole file, not after.
- A wrong frame rate assumption. Drift grows across the programme, so the first few minutes look fine. Always spot-check the last reel, not just the head.
- Lines over 32 characters. Automatic re-wrapping silently changes where lines break. On translated content this can split a phrase in a way that reads badly on screen.
- Drop frame and non-drop confusion. The timecode separator is the only signal. A mismatch drifts by roughly 3.6 seconds per hour, which passes a spot-check at the head and fails at the tail.
- Row collisions. PAC rows and the 608 grid do not have identical extents. A subtitle deliberately raised to clear a lower third can land back over it.
When not to convert PAC to SCC
Sometimes the honest answer is that SCC is the wrong target and the conversion should not be attempted at all.
- The PAC is Arabic, Hebrew, Cyrillic, Greek or CJK. This is not a quality compromise, it is impossible. CEA-608 has no code points for these scripts.
- The master is not 29.97 fps and the spec allows an alternative. Converting to MCC instead avoids the conform entirely, because MCC declares its own frame rate.
- The delivery is European. EBU-STL is the expected format and preserves far more of what the PAC carries.
- The delivery is streaming rather than broadcast. IMSC keeps positioning, styling and full Unicode text.
- The line breaks are contractually fixed. If the client will not accept re-wrapping, the 32-character limit may make a compliant SCC impossible without re-editing the translation.
If you are unsure which deliverable the spec actually requires, the caption format reference covers what each format carries and who asks for it.
PAC to SCC questions
Specific questions about this conversion. For the formats themselves, see the PAC and SCC references below.
Yes, and it is the single most important input. PAC stores text as code-page bytes rather than Unicode, so the same bytes decode to different characters depending on which language is assumed. Get it wrong and you produce structurally valid text that means nothing, with no error and nothing downstream to catch it. Confirm the language with the supplier rather than inferring it.
29.97 fps, because that is the only rate SCC supports. The real question is what rate the PAC was timed at, since that determines the conform. European material is usually 25 fps and film-originated material is often 23.976 fps. The SCC then needs a drop frame or non-drop separator matching the master's timecode.
Approximately. PAC positions subtitles by row with a horizontal alignment; SCC positions them on a 32 by 15 character grid with a column indent. The mapping is direct enough that subtitles land in the right region of the frame, but the row extents differ between the two formats. Check any subtitle that was deliberately raised to clear on-screen text.
They reduce to the seven colours CEA-608 supports: white, green, blue, cyan, red, yellow and magenta. A converter picks the nearest match. This matters when colour is carrying meaning rather than decoration — speaker identification in particular — because two distinct speaker colours can collapse onto the same 608 colour.
Yes, provided every file in the batch shares the same code page and the same source frame rate. Mixed batches are where this goes wrong: one Cyrillic file in a folder of Latin ones will convert to nonsense without failing. Group by language and rate before batching, or run them through an API that takes the code page as an explicit parameter.
Decode it right, conform it properly
Closed Caption Creator reads PAC with explicit code page selection, conforms frame rates against picture, and writes valid SCC with correct parity and separators.
Batch the whole folder through the API when the language and rate are consistent, and QC every output before delivery.