[BUG] SCC caption loading times are inaccurate #545

New Issue

claunia · 2026-01-29T16:47:09Z

claunia commented

2026-01-29 16:47:09 +00:00

Originally created by @kdrag0n on GitHub (Jan 30, 2020).

In raising this issue, I confirm the following:

I have read and understood the contributors guide.
I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present.
I have checked that the issue I'm posting isn't already reported.
I have checked that the issue I'm porting isn't already solved and no duplicates exist in closed issues and in opened issues
I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion.
I have used the latest available version of CCExtractor to verify this issue exists.

My familiarity with the project is as follows:

I have used CCExtractor just a couple of times.

Video links (replace text below with your links)

The example files sent in #1120 are a good place to start.

Additional information

SCC is basically a format for storing raw EIA-608 data. The way I implemented timings in # uses a simplified method which assumes that there is no time needed for transmission, and everything is played from a file by a video player. All captions are "sent" starting at the time they're supposed to be shown, and we send EOC-ENM at the end of them to commit them to the screen. Each caption can be represented in only one line of SCC.

This works well in most cases and reduces the complexity of our SCC implementation significantly. However, over the wire, EIA-608 can only transmit two bytes of data per frame, and the NTSC standard operates at 29.97 FPS. Each control code takes two bytes, and captions can easily take much more space. This means that in order to be compliant with the standard, we need to account for the "bandwidth" available and start loading each caption ahead-of-time while making sure to allow enough time for all of the caption data to be transmitted before attempting to display it with the RCL-EOC-ENM sequence. EOC is the control code that actually displays the caption, so this sequence also needs to be sent one frame ahead-of-time to make the timing frame-perfect. Collisions between captions also need to be handled gracefully (e.g. by shifting ) as they are very much possible — especially with longer ones.

A reliable and convenient way to check this is by uploading SCC files to YouTube using the "import subtitles/CCs" feature, which enforces timing checks strictly as if it were broadcasting the data to TVs. Resources (documentation and examples) are readily available from the comments in #1120.

I've already implemented the majority of this in the the scc-accurate-timing branch of my fork. It still needs some work though, particularly when collisions occur.

Originally created by @kdrag0n on GitHub (Jan 30, 2020). **In raising this issue, I confirm the following:** - [x] I have read and understood the [contributors guide](https://github.com/CCExtractor/ccextractor/blob/master/.github/CONTRIBUTING.md). - [x] I have checked that the bug-fix I am reporting can be replicated, or that the feature I am suggesting isn't already present. - [x] I have checked that the issue I'm posting isn't already reported. - [x] I have checked that the issue I'm porting isn't already solved and no duplicates exist in [closed issues](https://github.com/CCExtractor/ccextractor/issues?q=is%3Aissue+is%3Aclosed) and in [opened issues](https://github.com/CCExtractor/ccextractor/issues) - [x] I have checked the pull requests tab for existing solutions/implementations to my issue/suggestion. - [x] I have used the latest available version of CCExtractor to verify this issue exists. **My familiarity with the project is as follows:** - [x] I have used CCExtractor just a couple of times. **Video links (replace text below with your links)** The example files sent in #1120 are a good place to start. **Additional information** SCC is basically a format for storing raw EIA-608 data. The way I implemented timings in # uses a simplified method which assumes that there is no time needed for transmission, and everything is played from a file by a video player. All captions are "sent" starting at the time they're supposed to be shown, and we send EOC-ENM at the end of them to commit them to the screen. Each caption can be represented in only one line of SCC. This works well in most cases and reduces the complexity of our SCC implementation significantly. However, over the wire, EIA-608 can only transmit two bytes of data per frame, and the NTSC standard operates at 29.97 FPS. Each control code takes two bytes, and captions can easily take much more space. This means that in order to be compliant with the standard, we need to account for the "bandwidth" available and start loading each caption ahead-of-time while making sure to allow enough time for all of the caption data to be transmitted *before* attempting to display it with the RCL-EOC-ENM sequence. EOC is the control code that actually displays the caption, so this sequence also needs to be sent one frame ahead-of-time to make the timing frame-perfect. Collisions between captions also need to be handled gracefully (e.g. by shifting ) as they are very much possible — especially with longer ones. A reliable and convenient way to check this is by uploading SCC files to YouTube using the "import subtitles/CCs" feature, which enforces timing checks strictly as if it were broadcasting the data to TVs. Resources (documentation and examples) are readily available from the comments in #1120. I've already implemented the majority of this in the the [`scc-accurate-timing` branch](https://github.com/kdrag0n/ccextractor/commits/scc-accurate-timing) of my fork. It still needs some work though, particularly when collisions occur.

claunia added the difficulty: medium label 2026-01-29 16:47:10 +00:00

claunia closed this issue

2026-01-29 16:47:10 +00:00

claunia commented

2026-01-29 16:47:10 +00:00

@The-Bart-The commented on GitHub (Mar 22, 2020):

A reliable and convenient way to check this is by uploading SCC files to YouTube using the "import subtitles/CCs" feature, which enforces timing checks strictly as if it were broadcasting the data to TVs. Resources (documentation and examples) are readily available from the comments in #1120.

I made a thing.

I've been using a Windows batch file I wrote. Just place it with the tools in your SCC_TOOLS folder, (I assume you have one) and drag & drop a *.scc or a *.ccd file onto it. It'll make a copy of your file and use ccasdi.exe on it to convert to the other format to determine if it's valid. And back again. And tries converting to *.raw for good measure (scc2raw.exe).

ccasdi.exe will stop at the first error and report its timecode and line number.

I wrote it years ago to keep looping through as I corrected the errors (made by Subtitle Edit) manually, one-by-one.

I hope you find it useful, and thanks again for everything.

@The-Bart-The commented on GitHub (Mar 22, 2020): > A reliable and convenient way to check this is by uploading SCC files to YouTube using the "import subtitles/CCs" feature, which enforces timing checks strictly as if it were broadcasting the data to TVs. Resources (documentation and examples) are readily available from the comments in #1120. I made a thing. I've been using [a Windows batch file](https://www.dropbox.com/s/memujuoq3wj8e7d/sccIntegrityTester.bat?dl=1) I wrote. Just place it with the tools in your SCC_TOOLS folder, (I assume you have one) and drag & drop a *.scc or a *.ccd file onto it. It'll make a copy of your file and use ccasdi.exe on it to convert to the other format to determine if it's valid. And back again. And tries converting to *.raw for good measure (scc2raw.exe). ccasdi.exe will stop at the first error and report its timecode and line number. I wrote it years ago to keep looping through as I corrected the errors (made by Subtitle Edit) manually, one-by-one. I hope you find it useful, and thanks again for everything.

claunia commented

2026-01-29 16:47:11 +00:00

@cfsmp3 commented on GitHub (Jan 3, 2026):

Closing since https://github.com/CCExtractor/ccextractor/pull/1971 was merged.

@cfsmp3 commented on GitHub (Jan 3, 2026): Closing since https://github.com/CCExtractor/ccextractor/pull/1971 was merged.

claunia referenced this issue

2026-01-29 17:16:06 +00:00

[PR #545] [MERGED] Added configurable curl post url #1377

claunia referenced this issue

2026-01-29 17:16:07 +00:00

[PR #545] Added configurable curl post url #1380

Sign in to join this conversation.