Drop Frame Time Code Explained

Origional Black and white television was invented in the US by a man named Philo T. Farnsworth, however, Britain implemented the first standard, 25 frames with 405 lines. The US followed soon with 30 frames per second and 525 lines. Color television standards, needed to be compatible with the black and white standards. For color broadcasts, there needed to be two extra video components combined with the monochrome signal. This was accomplished by modulating the additional sub carrier waves. Due to some interference between the line frequency and carrier frequencies they needed to increase the frame period of the color standard in the US by 0.1% (1000/1001) thus giving us the 29.97 frame rate (which is actually 30*1000/1001=29.97002997002997…).

In order to compensate for the slightly slower rate they came up with a special frame count sequence called drop frame counting. Drop Frame count sequence drops or skips 2 frame counts at the beginning of every minute. Frames 0 and 1 of the first second of every minute are skipped. So, a typical count sequence would go something like this…01:01:59:28, 01:01:59:29, 01:02:00:02, 01:02:00:03…

This is not so bad, unfortunately, this technique over compensates for the slower frame rate. To compensate for the over compensation, frames are NOT skipped on every tenth minute (minute is exactly divisible by 10). For example, the previous rule would cause the following count…01:19:59:28, 01:19:59:29, 01:20:00:02, 01:20:00:03…however, since the new minute (20) is exactly divisible by 10 the frames are not skipped and the count is normal…01:19:59:28, 01:19:59:29, 01:20:00:00, 01:20:00:01. As we will see later, even the corrected compensation is not perfect.

So, in review, there are two differences between 29.97 drop frame code and 30 non drop frame code. First the frame rate is different by about .1%. Secondly, to make up for the drift that occurs due to the rate difference, the count sequence is different due to the dropped frames. The result is an offset between clock time and the current time code count. The offset or error cycles in a predictable way about +/- 1.8 frames or so (see below). You can see that the cycle repeats itself each ten minutes.

The Following Chart Illustrates, over a 10 minute period, what goes on…

During each minute the count drops behind clock time about 1.8 frames. (since there are fewer frames per second)

At the minute cross over boundary 2 frames are skipped putting the count ahead about .2 frames

This .2 frame per minute over correction yields a 2.02 frame drift over a ten-minute period.

To compensate for the 10-minute drift of just over 2 frames the normal 2 frame drop does not occur on the ten-minute crossover. This reduces the amount of drift to about .02 frames ahead over 10 minutes.

Zooming out a bit we see the error drifting up and the 6 corrections per hour (every tenth minute). Due to the combination of the natural rate difference and the double over compensation, there ends up being a 3.8 frame (+/- 1.8) error window that drifts upward at the rate of about .1 frames per hour. (IE the count getting further ahead of the clock by .1 frames per hour with an error deviation of +/-1.8 frames.

Zooming out once more, the .1 frames per hour drift and the 3.6 frame error window can be seen over a 24 hr period. The worst case offset occurs near 24 hours.

This 4.5 frame difference means that for about ½ of a frame there could be a maximum 5 frame difference between Count and Clock Time. The first occurrence of a 5 frame offset occurs at 20:28:59.28.

This table lists the different offset values used in the above tables with greater accuracy. The equations are also shown.

	Frames
Every Second the Count sequence falls behind (30-30*1000/1001)	0.02997003
If we did not correct, Every Minute the count would be behind by (AboveValue*60)	1.798201798
But Every minute we Drop 2 frames so the count only gets ahead by (2-AboveValue)	0.201798202
So then every ten minutes we would be ahead (without correction) (AboveValue*10)	2.017982018
To Correct for this we don’t drop the 2 frames on the ten-minute boundary. This means that every ten minutes the count only drifts ahead (AboveValue-2)	0.017982018
So every hour we drift ahead (AboveValue*6)	0.107892108
After 24 Hrs the count is only ahead by about (AboveValue*24)	2.589410589

Another way to look at the overall error….

Frames in 24 Hrs at a rate of 29.97 fps	2589410.589
Frames in 24 Hrs at a rate of 30 fps	2592000
Difference between 30 and 29.97	-2589.41
Extra Frames Per Hour we must drop to compensate (AboveValue/24)	107.892
The Drop Frame Count sequence actually Drops 108 per hour	108
Over 24 Hrs we have a discrepancy of (108-107.892)*24	2.589411

Rates and Counts

There are 4 frame Rates that a system must deal with. 24, 25, 29.97 and 30 frames per second. The Following tables show the frame rates and corresponding total frames in 24 hrs.

Rate	Total Frames
24	2073600
25	2160000
29.97002997	2589410.589
30	2592000

In addition, there are 4 different count sequences that are used, 24, 25, 30 drop Frame and 30. The following chart shows the relationship between these count sequences and the total number of counts from 0 to 23:59:59.xx hrs

Of the 16 combinations of frame rates and count sequences, only 6 are used as shown below.

Rate/Count	Referred to as
24/24	24
25/25	25
29.97/30 Drop	29.97 drop
30/30	30
29.97/30	29.97 non drop
30/30 drop	30 drop

24,25 and 30 Non Drop are true rates in that the Time Code and the frame ( or clock time) remain true. 29.97 drop, 30 drop and 29.97 non drop are not true rates. As seen above, 29.97 drop attempts to remain as true as possible but time code and clock time can be out of sync, at times, as much as 5 frames.

30 drop and 29.97 non-drop are required to properly track video that was striped with one count sequence and played at the incorrect rate. In order to play in sync with picture, the system needs to know what rate and count we are receiving.