The-Bart-The
commented
4 years ago 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.
In raising this issue, I confirm the following:
My familiarity with the project is as follows:
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-timingbranch of my fork. It still needs some work though, particularly when collisions occur.