The .scc file opens as hex pairs, not captions
SCC caption file shows hex codes instead of text
Seen in: Any text editor, YouTube, Premiere Pro
What is actually wrong
An SCC file is not text with a strange encoding; it is a transcript of the bytes a broadcast caption encoder sends to line 21 of an NTSC signal, two bytes per frame, written as hex. Control codes for pop-on, roll-up, colour and position are mixed with the character codes. Without a CEA-608 decoder the file is unreadable, and only a handful of applications include one.
Fix it here: SCC to SRT
Drop the file. It is detected and converted in your browser; nothing is uploaded. Free to start, no signup.
Convert a file now
Conversions …
Drop EDL, SRT, VTT, .prtranscript, or transcript files
Any caption, transcript or timeline file: CutConvert picks the converter and shows what survives · up to 100 KB per file
The fix, step by step
Confirm it is SCC
The first line reads Scenarist_SCC V1.0. Each following line is a timecode and a run of four-digit hex groups.
Decode to SRT
Drop the file here. The decoder walks the byte stream, applies the control codes, and writes each displayed caption as a cue with the timing at which it was shown and cleared.
Use the SRT
Import it into Premiere, Resolve, Final Cut or YouTube, or send it out for translation as Word or CSV.
Why it looks like this
Scenarist_SCC V1.0
00:00:01;02 9420 9420 94ae 94ae 9452 9452 c8e5 ecec ef2c 2077 ef72 ec64 2e80 942c 942c 942f 942fEach four-character group is two bytes, and each byte is either a printable character with odd parity or half of a control code. 9420 is "resume caption loading" (start a pop-on caption), 94ae clears the buffer, 9452 positions the cursor on row 15, the character pairs spell Hello, world., 942c erases the displayed caption and 942f flips the loaded caption onto the screen. The timecode at the start of the line is where that stream of bytes begins, at 29.97 fps drop-frame, and the bytes play out two per frame from there.
So the caption’s real on-screen time is not the timecode on the line. It is the time the 942f (end of caption) byte pair reaches the decoder, which can be a second or more later than the line’s timecode on a long caption. A decoder has to count frames through the stream to get it right, which is why hand-reading an SCC is not practical.
What the decoder does
The SCC to SRT converter on this site is a full CEA-608 decoder: it handles pop-on, roll-up (2, 3 and 4 rows) and paint-on captions, the special-character and extended-character sets for accented letters, italics and underline toggles, and mid-row colour codes. It computes the display and clear times by counting frames at 29.97 and writes each caption as an SRT cue with millisecond timing. Its output was verified against a reference decoder during development.
What SRT cannot carry: row positioning and colour. The text and timing are kept; placement is dropped, because SRT has no field for it. If you need positioning to survive, SCC to CSV writes the row and column per caption for inspection.
The other direction
SRT to SCC on this site encodes broadcast-ready pop-on captions with drop-frame timing, for deliveries that specify SCC. The decode-then-re-encode round trip is how a caption house checks a file before delivery.
The SCC is decoded in your browser. Nothing is uploaded.
FAQ
- Can I read an SCC in a text editor?
- Only the timecodes. The captions are hex byte pairs that need a CEA-608 decoder to become text.
- Is the timing accurate after decoding?
- Yes. The decoder counts frames through the byte stream at 29.97 fps, so each cue gets the moment the caption was actually displayed and cleared, not the line’s start timecode.
- Do italics and colours survive?
- Italics are kept as SRT tags. Colours and row positions are dropped because SRT has no representation for them.