Frame rates and Broadcast outputs

All the 608-standard caption file specifications (which includes the .scc file) were created with the assumption that the framerate is 29.97 fps (this spec is independent from CaptionSync). It is possible to create these files with other framerates, but please note that we cannot predict how your application software will use them because such files are outside the original specs. In particular, the 23.976 fps rate is tricky: both 23.976 and 24.0 fps videos use the same type of time code (SMPTE 24), as there is no standard time code format for 23.976 fps.

Also note that we disregard the framerate of the input media -- timing information is generated based on "clock time" and then offset according to the offset timecode. The resulting timing data is then cast into the framerate you requested for your output as per the SMTPE specs. This allows us to generate multiple output framerates regardless of what input media you upload.

Background:

In black and white TV, the standard was 30 fps, and it used a timecode called "SMPTE 30". Each frame count represented 1 tick of the clock or 1/30th of a second. After 108,000 frames, the clock would read 01:00:00:00 so everything was in sync. When color TV was introduced, the framerate was slowed by 0.1% to 29.97 fps, or 107,892 frames per hour. But the clock tick still represents 1/30th of a second. This means that after 107,892 frames have gone by, the "clock time" will be 3.6 seconds out of sync with the frame counter. 

To deal with this, SMPTE released two specs for counting frames: Drop-frame which skips a frame number every once in a while to keep the frame count time in sync with the clock time, and Non-Drop Frame which basically specifies that a frame time of 108,000 frames (01:00:00:00) is equal to 3603.6 seconds (01:00:03.6) in clock time. To create this 29.97 Drop Frame spec, SMPTE had to precisely define which frame numbers are skipped (dropped) so that all systems will skip the same frame numbers.

It is for this reason that you must match a Drop-Frame caption file to Drop-Frame media (or NDF captions to NDF media) -- otherwise the captions will drift at a rate of 3.6 sec per hour.

These days, "film frame rates", or 24 fps (using SMPTE 24 as the time code), are being used. If your framerate is truly 24 fps, then everything will work fine. When you use SMPTE 24 time code with a 23.976fps video, it does not sync with the clock time. The 23.976 fps represents the same 0.1% slowdown in framerate that 29.97 fps is to SMPTE 30. If you have a caption time code that reads "01:00:00:00" and you have a 23.976fps video, then the authoring or encoding software must know that the real clock time for the caption is 3603.6 seconds.

So, did SMPTE come out with a 23.976 Drop-Frame time code, like they did for 29.97 fps? No! In other words, there is no standard for "23.976 time code".  Without a standard, we have to use SMPTE 24 time code for both 24 fps video (where it syncs with the clock, like drop frame), and also for 23.976 fps video (where it doesn't sync with the clock, like non-drop frame).

Because there is no spec for 23.976 DF (which would define exactly which frames are dropped), the most reasonable assumption is to create the 23.976 fps .scc files in the same manner that NDF files are created (with the frame count not matching clock time). This is how our .24p.scc files work (and any of the other .24p.xxx files). While this is reasonable, there is no guarantee that whatever system these files are being loaded into will make the same assumption. It is possible that your system will simply assume the .scc file is 29.97 fps (this was, after all, how the .scc was originally spec'ed), or it may try to interpret the time code as clock time (as if it were a DF time code). We simply cannot predict how the receiving application will interpret these files as there is no spec to guide us in this regard.

Our advice:

So our advice is to try to not use .scc formats for non-standard framerates. The .scc file was simply not spec'd for anything other than 29.97 fps. The proper solution here is to use clock-based time codes for these applications (eg: DFXP or WebVTT are good choices).

If you really need to use .scc files, make sure you understand that the software may not correctly interpret non-29.97 fps .scc files. If you opt to use a format like the 24p output, and experience caption drift, then you could try the 'pure' 24.scc format. While this is technically incorrect, it will behave much like a 23.976 DF file (if there was such a format), and it may resolve the drift problem.