Caption Conversion Guide
Convert PAC to EBU-STL
The standard European delivery route: work authored in a subtitling house, delivered to broadcast playout. These are the two most similar formats in the set, so very little is lost. What the conversion needs is information the PAC does not contain.
Can you convert a PAC file to EBU-STL?
Yes, and it is one of the cleanest conversions available. Text, colour, row placement and alignment all have direct equivalents. Three things must be supplied: the PAC's code page, the frame rate the subtitles were timed at, and the programme metadata that fills the STL header.
What changes when you convert PAC to EBU-STL
Both formats were built for the same job: European subtitling with row-based placement, colour, and a character set selected per file. The mapping is close to one-to-one.
| Property | In the PAC | In the EBU-STL | Result |
|---|---|---|---|
| Text encoding | Code page, one per file | Character table, one per file | Direct equivalent. Map the code page to the matching table |
| Non-Latin scripts | Cyrillic, Greek, Arabic, Hebrew | Cyrillic, Greek, Arabic, Hebrew | Both support them. Confirm the target table matches |
| Reading direction | Left-to-right and right-to-left | Depends on the character table | Right-to-left survives where the table supports it |
| Frame rate | Not stored in the file | 25 or 30 fps, declared in the header | You have to supply the source rate. Usually 25 already |
| Timing | Explicit in and out timecodes in frames | Explicit in and out timecodes in frames | Transfers directly when the rates match |
| Vertical position | Row number | Teletext row number | Direct mapping |
| Horizontal position | Left, centred, right alignment | Justification | Direct mapping |
| Colour | Subtitle colour palette | Teletext palette | Close mapping. Verify against the delivery spec |
| Italics | Per subtitle or inline | Signalled in the text field | Survives |
| Programme metadata | None | Title, episode, translator, reel fields | Has to be supplied from the delivery paperwork |
| Line length | Set by the rendering system | Teletext line, control codes consume cells | Re-check. Colour changes take up character cells |
Before you start: three inputs from outside the file
The subtitles themselves need almost no work. Everything that can go wrong here comes from information the PAC does not carry.
- The PAC's code page. Confirm the source language with the supplier. Applied wrongly, the text decodes into plausible nonsense and the STL preserves it faithfully.
- The frame rate the PAC was timed at. Usually 25 fps for European work, but PAC does not record it, so confirm rather than assume.
- The programme metadata. Title, episode number, translator name, language code and reel information all live in the STL header and have no source in the PAC.
- The display standard the client expects. Open subtitles or teletext level 1 or 2. This affects how the placement data is used downstream.
- The maximum line length in the delivery spec. Teletext control codes occupy cells, so a line that rendered fine from PAC may overflow on air.
How to convert PAC to EBU-STL
Decode correctly, confirm the rate, then fill in what the STL header needs. The subtitle content largely takes care of itself.
-
Confirm the source language and code page
Get this from the supplier or the delivery paperwork. It determines how every text byte decodes. -
Open the PAC with that code page and verify the text
Read subtitles from several points in the programme and confirm accented or non-Latin characters are genuinely correct. -
Establish the source frame rate
Spot-check timing against the master. European material is usually 25 fps, which matches STL's native rate and avoids any conform. -
Select the matching character table
Choose the STL character table corresponding to the PAC's code page. Latin to Latin, Cyrillic to Cyrillic, and so on. -
Conform the timing if the rates differ
If the PAC was timed at 23.976 fps against a film master, conform to 25 fps before export. -
Map rows and alignment
PAC rows become teletext rows and alignment becomes justification. Review anything placed away from the default. -
Fill in the STL header metadata
Enter programme title, episode, translator, language code and reel information from the delivery paperwork. -
Check line lengths and export
Verify lines fit the teletext line including control code overhead, then write the STL and QC against picture.
What breaks, and how to catch it
Two of these are silent, and both originate before the conversion rather than during it.
- The wrong code page. Decoded incorrectly, the text becomes structurally valid nonsense, and the STL stores it faithfully. Nothing downstream will flag it.
- A mismatched character table. Decoding correctly and then writing to the wrong STL table undoes the work. Latin content in a Cyrillic table is just as broken as the reverse.
- An assumed frame rate. PAC does not record its rate. If the source was 23.976 and you assume 25, the subtitles drift progressively.
- Empty header fields. An STL with no programme title or language code is frequently rejected at ingest even when the subtitles are correct.
- Line overflow from control codes. Colour changes consume character cells on a teletext line, so a line that looked fine in the PAC can overflow on air.
When not to convert PAC to EBU-STL
STL is the right target for European playout. Other destinations want something else.
- The delivery is streaming. IMSC preserves everything and removes the character table limit entirely.
- The delivery is North American broadcast. Convert PAC to SCC instead, and note the script limitation.
- The content mixes scripts. Neither format can hold two scripts in one file. Use IMSC or split the delivery by language.
- You do not have the programme metadata. Get the paperwork first, because an STL with empty header fields usually fails ingest.
The PAC and EBU-STL references cover what each format carries in detail.
PAC to EBU-STL questions
Specific questions about this conversion. For the formats themselves, see the PAC and EBU-STL references below.
Closely, because both formats solved the same problem the same way: one script per file, selected by a file-level setting. Latin maps to Latin, Cyrillic to Cyrillic, Arabic to Arabic. The requirement is that both ends are set correctly — decoding a PAC properly and then writing it into the wrong STL table is just as destructive as decoding it wrongly in the first place.
Yes, where the STL character table supports the script. Both formats were built with multilingual European and Middle Eastern subtitling in mind, so Arabic and Hebrew are handled rather than bolted on. Verify the rendering in your target system, because how right-to-left text is presented can vary between playout chains.
25 fps for European broadcast, which is what STL is normally delivered at. The question that actually needs answering is what rate the PAC was timed at, since PAC does not record it. European subtitling work is usually already 25 fps, in which case no conform is needed at all — but confirm against picture rather than assuming.
Most often because the header metadata is incomplete. The STL header carries programme title, episode number, translator, language code and reel information, and many ingest systems validate those fields. A PAC supplies none of them, so they have to be entered from the delivery paperwork before export.
They can. Teletext control codes occupy character cells on the line, so a colour change or a positioning command eats into the space available for text. A line that fitted comfortably when rendered from PAC may overflow once those codes are counted. Preview teletext spacing before export rather than discovering it at QC.
Map the code page, fill the header
Closed Caption Creator reads PAC with explicit code page selection, writes the matching STL character table, and gives you the full header to complete before export.
Preview teletext spacing against picture so line overflow is caught before ingest.