# How is 29.97 timecode generated over a full day without frame errors?

A quick primer:
American television was originally broadcast at 30 frames per second. In order to accommodate color information without losing backward-compatibility with B&W televisions, the framerate was slowed by a factor of 1000/1001, to approximately 29.97 FPS.

29.97 footage was still labeled as 30 FPS; however, the difference in framerate caused the timecode to be off by a minute-and-a-half per day, causing sync issues for broadcasters. To counteract this, "dropframe" timecode was developed. At 30 FPS, there are 18000 frames per ten minutes; at 29.97 exactly, there are 17982 frames per ten minutes. To account for the eighteen-frame difference, we "skip" two frames on every minute not divisible by 10. For example:

``````30 FPS
00:00:59:29 + 1 frame = 00:01:00:00
00:04:59:29 + 1 frame = 00:05:00:00
00:09:59:29 + 1 frame = 00:10:00:00

29.97 FPS, dropframe
00:00:59;29 + 1 frame = 00:01:00;02
00:04:59;29 + 1 frame = 00:05:00;02
00:09:59;29 + 1 frame = 00:10:00;00
``````

The question:
The math works out at exactly 29.97, but the framerate is slightly faster -- 30*(1000/1001) works out to 29.97002997002... The difference is negligible for any single piece of footage; the error here only works about to about two-and-a-half frames per twenty-four hours. But how does a master sync generator account for these extra frames? There's no labeling scheme for them, and midnight will not occur on a clean frame.

• Interesting. Certainly, apps like FFmpeg don't account for the discrepancy. And the impression from search suggests neither do most other s/w or appliances.
– Gyan
Feb 29, 2016 at 19:02

As per the Broadcast Engineer's Reference Book, p. 203

This correction will match DF time to real time to within approximately 2.6 frames per day; to eliminate the residual error the timecode generator can be reset each midnight.

So, apparently nothing.

As far as the "extra" frames, Charles Poynton says,

If a timecode sequence is to be maintained longer than 24 hours, timecode should be jammed daily to reference clock time at an innocuous moment. No standard recommends when this should take place; however, the usual technique is to insert duplicate timecode numbers 00:00:00;00 and 00:00:00;01. Editing equipment treats the duplicate codes as a timecode interruption.

• This (very helpfully!) explains how the error is removed each day, but doesn't explain how the "extra" frames are handled. Mar 4, 2016 at 16:43
• I'm assuming they aren't handled. If they were, there would be no residual error to reset.
– Gyan
Mar 4, 2016 at 17:23
• I don't mean "handled" as in "corrected"; I agree the error needs to be reset after every 24-hour periods. That said, 29.97 dropframe gives us 2,589,407 frame labels for a given 24-hour period, but the actual framerate requires labels for 2,589,409.6 frames -- unless the reset includes ignoring two frames each night, which seems to introduce a new sync issue. Mar 4, 2016 at 20:06
• @ErikD. What issues do you see here, and where would they arise? Is there anything in your experience that indicates that this causes real-world problems, and for whom? Mar 4, 2016 at 22:40
• @JimMack I'm dealing with a CMS that stores timecode values as millisecond offsets from midnight. Assuming I'm using time-of-day timecode, I'm frame-inaccurate for any footage captured after about 2pm if I'm calculating at exactly 29.97 fps. If I use the correct 30 fps * (1000/1001), I have two and a half unlabelable frames for footage spanning midnight. Mar 6, 2016 at 2:16

The information so far: you're acquiring video content continuously at exactly 29.97 with no breaks ever, forever. Plus A) each video frame must have a unique label and B) these labels must always exactly match true time of day, within a small epsilon that averages to zero.

Given those conditions, there's no solution using only standard video sync and time code. You must compromise / customize something.

Some possibilities are:

1 - Resynchronize TC to TOD at every break in recording. I know we assumed no breaks, but no recording medium has infinite length. Scheduled breaks or resync points might be possible.

2 - Jam the TCG to TOD every "n" hours and live with the consequences.

3 - Store both the mSec-exact TOD and the TC (or the accumulated delta) in the CMS, and use them both on retrieval of a given frame. Couple this with a reset to 0 whenever possible.

4 - Use the user bits of the TC to encode the mSec-exact TOD, instead of storing it in the CMS database. However, the delta won't survive dubbing / editing.

5 - Similar to what @Mulvya suggests, customize the TC generation to not drop three normally-skipped frame labels each day. That would change the drift from -2.589 frames/day to +0.411 fr/day. This can be further corrected by skipping one of the not-drops every 2 days, making the average error term -0.02 fr/day, etc. You can continue this to any desired accuracy. This is only possible if your TC doesn't have to be used outside your own context. "Normal" systems for editing etc won't understand it.