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

Question

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.

Answer 1

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.

Answer 2

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.