Caption Format Reference
PAC File Format (.pac)
PAC is the working format of the subtitling houses. It is binary, code-page based, and built for multilingual work — which makes it excellent at carrying Arabic, Hebrew and Cyrillic, and makes it the single most common source of destroyed text in a badly configured conversion.
What can a PAC file be converted to?
PAC converts to SRT, WebVTT, TTML, IMSC and EBU-STL with its text, placement and colour largely intact, provided the source code page is identified correctly. Conversion to SCC or MCC works only for Latin-script content, because CEA-608 has no code points for other scripts.
PAC at a glance
PAC is a proprietary format from Screen Subtitling Systems rather than a published standard, so tools differ slightly in what they read. The consistent parts are the ones that matter: frame-based timing, row positioning, and a code page that governs how the text bytes decode.
| Property | Value |
|---|---|
| Common name | PAC, after the Screen Systems Poliscript subtitle file |
| Extension | .pac |
| Specification | Proprietary to Screen Subtitling Systems |
| File structure | Binary |
| Timing | Frame-based, with an in and out timecode per subtitle |
| Frame rate | Not reliably stored in the file. The rate has to be supplied by the operator |
| Character support | Code-page based, covering Latin, Cyrillic, Greek, Arabic, Hebrew and others |
| Reading direction | Left-to-right and right-to-left |
| Positioning | Row number with horizontal alignment |
| Styling | Colour and italics |
| Related variant | .fpc, a companion format from the same family |
| Closed Caption Creator | Read and write |
For a side-by-side of what each format holds, see the full file format support list.
What PAC can and cannot carry
PAC's capability set is close to EBU-STL's, with one significant addition: it was designed from the start for multilingual subtitling, including right-to-left scripts.
| Capability | Supported | Notes |
|---|---|---|
| Dialogue text | Yes | Decoded through the file's code page |
| Explicit in and out times | Yes | Both timecodes stored per subtitle |
| Row positioning | Yes | Vertical placement by row number |
| Horizontal alignment | Yes | Left, centred or right |
| Text colour | Yes | A palette of subtitle colours |
| Italics | Yes | Per subtitle or within a line |
| Right-to-left scripts | Yes | Arabic and Hebrew are first-class, not an afterthought |
| Cyrillic and Greek | Yes | Through the appropriate code page |
| Mixed scripts in one file | No | The code page is a file-level setting |
| Embedded frame rate | No | The rate must be known from the delivery paperwork or the master |
| Two languages in one file | No | One language per file |
| Fonts and text size | No | Appearance is decided by the rendering or burn-in system |
Who asks for PAC files?
PAC is rarely a final deliverable. It is what subtitling houses work in and exchange, particularly on multilingual titles where the alternatives cannot hold the script.
- Subtitling and localisation houses, as a working and interchange format.
- Multilingual projects covering Arabic, Hebrew, Greek or Cyrillic territories.
- Screen Subtitling Systems workflows and the tools built around them.
- Archive material from European and Middle Eastern subtitling operations.
- Vendors delivering into broadcast chains that convert PAC to a playout format on receipt.
The delivery format at the end of the chain is usually EBU-STL in Europe, SCC or MCC in North America, and IMSC for streaming.
How do I open a PAC file?
PAC is binary, so a text editor shows unreadable bytes with occasional fragments of Latin text. There is no header line to identify it the way SCC or WebVTT announce themselves.
Opening it properly means using a tool that can apply the right code page. This is the step that goes wrong: the same bytes produce legitimate-looking but completely incorrect text if the wrong language is assumed, so a file can appear to have opened successfully when it has not.
If you receive a PAC without knowing its language or frame rate, ask before converting. Both are operator settings rather than fields in the file, and guessing either one produces a plausible-looking result that fails downstream.
Converting PAC to another format
Converting out of PAC is reliable once the code page is correct. Almost every failure people attribute to the conversion is actually a decoding decision made before the conversion started.
| Convert PAC to | What survives | What to watch for |
|---|---|---|
| EBU-STL | Text, colour, placement | The closest sibling. Code pages map to character tables, and both formats are row-positioned and frame-based. |
| TTML / IMSC | Text, colour, placement | The best target for multilingual content, because UTF-8 removes the code page problem entirely. |
| WebVTT | Text, colour, approximate placement | Rows become percentages and colours become CSS classes. UTF-8 output means non-Latin scripts survive. |
| SRT | Text and line breaks | Colour and placement are discarded. Save as UTF-8 or the script you just decoded correctly will be mangled again. |
| SCC | Latin text, colour, approximate placement | Latin-script content only. Arabic, Hebrew, Cyrillic and Greek have no representation in CEA-608 and cannot convert. |
| MCC | Latin text, colour, placement | Same script limitation as SCC, but a wider choice of frame rates avoids an unnecessary conform. |
| Burnt-in video | Text, colour, placement | Font selection matters for non-Latin scripts. Check shaping and joining behaviour on Arabic before committing to a render. |
Converting another format to PAC
Converting into PAC means choosing a code page and a frame rate. Neither can be inferred from a source file that stores text as UTF-8 and timing in milliseconds.
| Convert to PAC from | What carries over | What the conversion has to decide |
|---|---|---|
| EBU-STL | Text, colour, placement | Character table to code page mapping, which is usually direct when the scripts match. |
| SRT | Text | A code page, a frame rate, row placement and alignment. SRT supplies none of them. |
| WebVTT | Text and approximate placement | A code page for the target language, plus mapping percentage cue settings onto rows. |
| TTML / IMSC | Text, colour, placement | Which code page covers the content. UTF-8 sources can contain characters no single PAC code page can hold. |
| SCC | Text, colour, placement | A 29.97 fps to target-rate conform, and a mapping from the 608 grid to PAC rows. |
| Transcript (DOCX, TXT, CSV) | Text | Everything. Timing, placement, colour and code page all have to be established. |
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 PAC conversions go wrong
PAC is unusually good at producing wrong output that looks like right output, which is why these four are worth checking every time.
- The wrong code page. The most common and most damaging failure. Decoding Arabic as Latin produces text that is structurally valid and completely meaningless, and no downstream tool will flag it.
- An assumed frame rate. PAC does not reliably carry its own rate. Assuming 25 fps for a 23.976 fps title puts every subtitle progressively out against picture.
- Converting non-Latin content to SCC. There is no partial success here. CEA-608 has no code points for Arabic, Hebrew, Cyrillic or Greek, so the conversion cannot represent the text at all.
- Losing UTF-8 on the way out. Decoding the code page correctly and then writing an SRT in a legacy encoding undoes the work. Write UTF-8 on every text-based output.
For handling scripts and reading direction across a delivery, see translating subtitles for broadcast.
PAC conversion questions
Common questions about moving subtitles into and out of the PAC format.
Because the wrong code page was applied. PAC stores text as bytes whose meaning depends on a code page that is an operator setting rather than a reliable field in the file. Applied incorrectly, Arabic or Cyrillic content decodes into legitimate-looking Latin nonsense. Re-open the file specifying the correct source language rather than trying to repair the text afterwards.
Only for Latin-script content. SCC carries CEA-608 data, and CEA-608 has no code points for Arabic, Hebrew, Cyrillic, Greek or CJK. English, Spanish, French and Portuguese PAC files convert cleanly. Anything else has to go to a Unicode-based target such as IMSC, TTML or WebVTT instead.
Whatever the master was. The format stores timecodes in frames but does not reliably record the rate they were counted at, so it has to come from the delivery paperwork or the video itself. This is why a PAC that plays correctly in one facility can drift in another: the same file, a different assumption.
They are companion formats from the same Screen Subtitling family, and tools that read one usually read the other. Treat the extension as an indication of which variant you have rather than a difference in what the subtitles can carry. If a tool refuses one, try opening it as the other before assuming the file is damaged.
No. SRT has no positioning field, so row and alignment data is discarded along with colour. On multilingual work this matters more than it first appears, because right-to-left content often relies on alignment to read correctly. Convert to WebVTT, TTML or IMSC if placement has to survive.
Yes, and it is one of the reasons the format is still in use. PAC was built for multilingual subtitling and handles right-to-left scripts as a first-class case rather than an extension. The constraint is that one file holds one code page, so a title mixing Arabic and Cyrillic needs separate files per language.
Decode PAC correctly, then take it anywhere
Closed Caption Creator reads PAC with explicit code page selection, so Arabic, Hebrew, Cyrillic and Greek content survives the trip instead of arriving as nonsense.
Convert to EBU-STL, IMSC, WebVTT or SRT with placement intact, and conform frame rates properly on the way.