Drop-frame Timecode

- solution to the 29.97 Frames Per Second problem -

It's a weird, weird thing, this 29.97 number.  The source of so much confusion.

The original television system was Black and White and it used exactly 30 fps.  When color systems were developed, they were modeled after B&W, but the frame rate had to be changed ever so slightly, to exactly 29.97 fps, so that the color signal would synchronize properly with the sound signal.

	Going from 30 to 29.97 reduces the frame rate by 1/1000 exactly
	Color TV frame rate = 999/1000 x Monochrome TV frame rate

NTSC adopted the new rate 30 years ago, and from that point on, it applied to both color and monochrome sets.

see:    http://www.adobe.com/support/techguides/premiere/time_and_framesize/main.html 

Why 29.97 fps is a Problem

Unfortunately, this has placed all the modern video hardware/software manufacturers in a difficult situation.  They could no longer report the elapsed time as before, where they used frames to run the clock  .  .  .  or maybe they could (we will get to that later).   The frame rate no longer fit nice and evenly on a per minute basis.  The number of frames per minute was no longer a whole number.

The SMTPE tackled the problem.  If they continued to run the clock from the frames and number them consecutively as before - then the first second of elapsed time, the frames would be numbered 1 through 30, and the timeline would report 1 second has elapsed.  But only 29.97 seconds has elapsed, therefore, the 30th frame would go a bit beyond the 1 second mark.  The reported time would lag behind the actual time.  The following diagram shows the effect, exaggerated:

29.97 fps vs Time

Reported Time - allow Lag, and Periodically Correct

Believe it or not - they decided to do just that - continue to run the clock from the frames and use 30 fps for reporting the time !!  There just was no way that they could report time in such an archaic manner, with long decimals or complex fractions.  They decided to do two things:

	accept the fact that the reported time will lag behind the actual time
	devise a scheme of periodic corrections

 The clock of all television and video editing systems - both drop frame and non-drop frame, runs along at the same rate as the frames - at 29.97 cycles per sec.  They report the elapsed time as if it was 30 fps - until the periodic corrections are made !!

With the old frame rate, there were exactly 1800 frames per minute, now there were 1798.2  -  if they continued to number the frames from 1 to 30 for each second, and 1 to 1800 for each minute - then the frame numbers would never, ever coincide with an exact number of minutes.  They had to figure out a way to fudge the numbers to fit - a new timecode had to be developed - but first, they set down a few guidelines:

	the new timecode cannot change the actual elapsed time or frame rate
	the new timecode must account for each and every frame
	the new timecode can change how the frames are numbered
	the new timecode can misreport elapsed time, but must be periodically corrected so that there are instances where it is synchronized with the actual time

So they had to periodically synch the time.  They needed to find a number of minutes that contained an even number of frames for both 30 and 29.97 fps  -  that turned out to be 10 minutes (600 seconds):

- at 30.00 fps there are 18000 frames every 10 minutes
- at 29.97 fps there are 17982 frames every 10 minutes
The new frame rate has 18 less frames every 10 minutes - or 1.8 less frames every minute

They needed to periodically correct the difference by dropping frames.  Let's diverge for a second and discuss this confusing term:

Frames are never really dropped or added - but the way they are numbered is manipulated.

The new frame rate has less frames - so why would we drop frames, errr, I mean frame numbers?  Shouldn't we be adding frame numbers ??  YES !!  The term dropped frames is flat out wrong.  In reality, we add frame numbers !!    The process skips two frames in the numbering (frames 0 and 1, as you will see) - and when you skip numbers, you are advancing ahead - not dropping behind.  

To advance ahead, we skip frame numbers, which some view as dropping frame numbers.  This is understandable, but wrong - when we skip 2 frame numbers, we are not dropping them.  We are still reporting that they have occurred !!  In fact, we are now reporting more frames than have actually occurred, so we are adding frames - not dropping them!!  

So always remember - dropped frames is nothing more than skipped frame numbers, and it has the effect of adding frames to the count !!  Dropped Frames means added frames.  For sanity sake, we will continue to use the universal term, dropped frames - but you need to know what it actually means.

For the periodic corrections, they needed to drop 18 frames for every 10 minutes of time.  Sounds easy - just drop 1.8 frames each minute.  But no - it must be an exact number of frames, since there is no such thing as a partial frame.  

To address this new frame rate (which is now 30 years old), the SMPTE came up with a standard known as Drop-Frame timecode.  Actually, they addressed four frame rates:  30, 29.97, 25 and 24 fps.  We will only talk about the 29.97 rate.

They defined both drop frame and non-drop frame formats.  Again, drop-frame timecode only skips frame numbers  -  no actual frames are dropped !!!  Therefore with both drop-frame and non-drop-frame, the actual frames run along at 29.97 fps.  Drop-frame does not change the frame rate !!  It's just a numbering trick that synchronizes the frame count.

They would use the 10 minute cycle, since 29.97 has an exact number of frames every 10 minutes.   They also stuck with 1-minute intervals for performing the corrections.  10 minutes of video at 30 fps contains 18000 frames.  With 29.97 fps they needed to drop 1/1000 of that, which is exactly 18 frames, or 1.8 frames a minute.  But again - we can't drop a fraction of a frame.  

The Drop Frame Solution

Exactly two frames are dropped each minute for the first 9 minutes, and no frames are dropped the 10th minute - repeat this continually, and you will drop 18 frames every 10 minutes !! 

For minutes 1-9, the two frames are dropped by skipping frame numbers 0 and 1.  So the count begins at frame 2 for those minutes.

Now of course, the actual time and frames do not work this way - so drop-frame is definitely fudging numbers, and Video Editors that use drop-frame, always display slightly incorrect time, except at those exact instants when each 10-minute cycle has completed, and everything is synchronized.

The display on the timeline shows the time and the frame numbers - using the format:    h;mm;ss;ff.  (hours;min;sec;frames).  When you import an NTSC 29.97 fps video clip, it does run at 29.97 fps in Premiere.  Each tick mark on the timeline represents a single frame at 29.97 fps.  So the drop-frame timecode does not change the frame rate !!!  But the timeline assumes that 30 frames = 1 second for it's display of time.  So although each tick mark does represent exactly 1/29.97 seconds - it is reported as 1/30th of a second, which lags behind the actual time.  No worries - this is periodically corrected.

The 10-minute cycle can be described with 3 continuously repeated steps:

1)  Continuous Lag (constantly occurs) - the display counts seconds using the old 30 fps model.  Since actual is 29.97, this means the display is continually lagging the actual.  If we did not skip frames numbers, the system will report 1 second when 30 frames have elapsed - but 1 second occurs earlier, when 29.97 frames have elapsed.  To be correct the display exactly, after 30 frames it should say 1.001001001 sec, not 1 second.  Therefore, the display is always getting further and further behind in time, each minute we are behind by 1.8 frames.  

2)  Over-Corrections (minutes 1-9, 11-19, etc) - to correct this 2 frames are dropped at the beginning of minutes 1, 2, 3,  . . . 9.  Again, dropping frames does not move the time backward  -  it  moves the time forward !!  When it reaches 1 minute, the first frame count, instead of 0 - says 2.  Therefore, it has adjusted for the lag, and moved the display forward.  Since the exact correction is 1.8 frames, and we correct by 2 frames - each of these are over-corrections by .2 frames.  The total over-correction is 9 x .2 = 1.8 frames, which means at the end of the ninth frame, we are reporting 1.8 frames ahead of actual time.

3)  Correction of the nine Over-Corrections (minutes 0, 10, 20, etc.) - during the 10th minute, we correct for all the overcorrections, by allowing the continuous lag to run.  No frames are dropped, and a lag of 1.8 frames occurs.  This fixes all the previous nine over-corrections (each over-correction is .2 frames, for a total of 1.8 frames).  

Wild stuff !!  Here we detail these 3 steps:

As you can see, the time shown is always incorrect - except at those exact 10-minute intervals.

Look at the diagram below.  The offset in time caused by dropping frames has been purposefully exaggerated to show the effect.  Remember By dropping 2 frames every minute for the first 9 minutes 

Non-Drop Frame:  each minute, 29.97 fps x 60 sec/min = 1798.2  frames occur
                                        so the actual rate is 1798.2 fpm  or  1 min per 1798.2 frames

Drop-Frame for the fist 9 minutes:   we count 1798 frames
                                        the time it takes for 1798 frames is:    1798 frames x 1 min/1798.2 frames = .9998887 minutes

So we are continually losing time during the first 9 minutes, as we count only 1798 frames, when they are actually 1798.2 frames.  We are getting further and further behind the actual time.  But the 10th minute corrects this by counting 30 frames.  Of course, only 29.97 frames have actually occurred during the final minute - so the 30 frames takes a bit more than a minute:

using DropFrame for the 10th minute:  we count 1800 frames
                                         the time it takes for 1800 frames is:    1800 frames x 1 min/1798.2 frames = 1.001001 minutes

No we add the time taken with our drop-frame counting.  (9 x .9998887) + (1 x 1.001001) = 10 minutes  !!!

In summary, the method works as follows:

• No frames are dropped at minutes 00, 10, 20, etc.

• 2 frames are dropped at minutes 1,2,3 . .9, then 11,12,13 . .19, etc.

Display of Time within Video Editors

Many editors, including Adobe Premiere represent both non-drop and drop-frame timecode as follows:

This is almost identical to display of standard time, except that the last number is "frames" instead of hundredths of a second.

How far off is the Displayed Time ??

Remember that all frames are counted, no matter what timecode you use, but drop-frame systems fudge the numbers:

	They do not display the correct time (except once every 10 minutes)
	They account for every frame but do not display the correct number of frames since they skip numbers (except once every 10 minutes where they show the correct time and frame number of 0) - this is the only time they display the correct frame number !!

Drop-frame displays of time are continually getting behind, then getting ahead from the over-corrections, and then synchronizing every 10 minutes.  Since this is only a speck in time where the display is correct - basically you can say that the displayed time is never correct.

Luckily it is off by such a tiny fraction that it is insignificant.  

How much it is off varies continually.  So there are certain times when the displayed time is off more than others times.  For example, at 0 minutes, Premiere starts counting frames normally at 30 fps, and it does not make a correction until 1 minute is reached, where it then drops the count of frame 0 and frame 1.  So, as the first minute progresses from 0 secs to 60 secs, the frame count is accurate, but the displayed time is farther and farther away from the truth.  Just before 1 minute is displayed, the count is OFF by 1.8 frames (remember, the time is displayed using frames for the last digits, where 30 frames = 1 sec).

The largest amount of display time error is just before the corrections are made.

Example of Display Inaccuracy

We will take an instant in time of a video clip, and calculate the actual elapsed time.  The displayed time may:

• lag if it is just before a correction occurs

• be ahead if it is just after a correction.  Remember that all the corrections (dropped frames) cause time to be advanced, and they over-correct since they advance by 2 frames instead of the actual lag of 1.8 frames.

For our example, we will use the displayed time of    0;34;14;23  

This is 3 hours, 34 minutes, and 14 seconds into the clip, and the frame number is 23, which corresponds to approximately 23/30 of a one second.  We will calculate the actual time that has elapsed.  It should be less than what Premiere is showing us, since for the last 4;14;23 we are dropping 2 frames per minute, which is a bit aggressive (there are actually 1.8 frames that need to be dropped per minute) and relies on the 10th minute, where we drop no frames - to catch up.  The first 30 minutes will be exact, since for every 10 minutes, the drop frame time = non-drop frame time.  But for the last 4;14;23 there is no 10th minute, and no catch-up :

• every 10 minutes the times are fully synched (drop-frame time = actual, no-drop frame time)

• therefore, 0 hours and 30 minutes have truly elapsed - but the partial 10-minute cycle of 4;14;23 must be converted to real time

• therefore, 4 minutes, 14 sec, 23 frames needs to be converted to real time - we will add up all frames and multiply by the real time per frame

• for each of the minutes 1 through 4, two frames are dropped (frames 0 and 1 are dropped).  So for the 4 minutes, we count 1798 frames each - for the 14 seconds we have count 30 frames each - and we have counted 23 frames at the end

• frames = (4x1798) + (14x30) + 23 = 7635

• actual frames per minute - convert 29.97 fps to 1798.2 fpm

• actual elapsed time =  7632 frames x 1/1798.2 min per frame = 4.244244 . . . repeating  minutes  = 4 min and 14.65 secs = 4 min, 14 sec, 19.6 frames

• Total elapsed time - adding back the 30 minutes, and rounding off, the actual elapsed time is 0;34;14;20, which is 3 seconds less than what the timeline shows !!!  The timeline is ahead of actual.

Therefore, when showing time using drop-frame, you are showing very slightly more time that has actually occurred.  However, it all is synchronized when the 10 minute occurs, and all frames are counted.

If Premiere dropped the exactly number of frames (1.8 per minute) then the time would be exact at the beginning of each minute (1-9).  But Premiere is dropping 2 frames per minute for the first 9 minutes.  Right after each 2-frame correction (for displayed minutes 1-9), Premiere has counted 1798 frames for each displayed minute  -  but there are actually 1798.2 frames per minute.  So after correction, Premiere says that 1 minute has elapsed when less than a minute has actually elapsed.

So the display of 0;34;14;23 is 3 frames ahead of the actual 0;34;14;20.  

This difference is so small that it is insignificant !!!

The Premiere Timeline

There are no dropped frames at the beginning of the clip, from 0;00;00;00 up to 0;00;59;29.  This is minute 0, which is the same as minute 10, 20, etc - for those particular minutes, no frames are dropped.

The first two frames for minutes 1,2,3, . . . 9, are dropped.  This advances the reported time by 2 frames.

The timeline is drop-frame, and therefore does not show you the actual elapsed time of the clip !!  For example, the two diagrams show the timecode for a video clip at the beginning of 8 minutes, where 2 frames are dropped  -  and at the beginning of 10 minutes, where no frames are dropped :

Dropped Frames 0, 1 for Minute 8 - Count starts at Frame 2

No Dropped Frames for Minute 10 - Count starts at Frame 2

Should I choose Non-Drop or Drop Frame within Premiere's Settings ??

You can change this in the Project/Project Settings/General . . . Time Display

	For broadcast NTSC video, choose 30 fps Drop-Frame Timecode if that was the time display used by the original video
	For video to be played back from the Web or CD-ROM, choose 30 fps Non Drop-Frame Timecode.

Why did they Change It to 29.97 ??

The Myth

- mentioned only because this is shown from several sources:

Max resolution is dependent on the frequency (bandwidth) of the chroma signal, which is 3.579454 Mhz:

They assumed that there are approx 455 vertical lines, or pixels across in one Horizontal line:

    Horiz Scan Freq = 3.579545 Mhz X (2/455) = 15734 Hhz 

There are 525 horizontal scan lines:

    Vert Scan Freq = Horiz Scan Freq X ( 2/525) = 59.94 Hhz or 29.97003 frame rate.

Frame Rate is dependent on the Vertical Scan frequency

There are 2 fields scanned for a total of 525 lines.  

At 59.94 Mhz Field Rate, Frame Rate 1/2 x Field Rate = 1/2 x 59.94 = 29.97 fps

The Truth

Monochrome television used to run at exactly 30fps (or 60 fields per second) - it was easy to sync to AC power. However, once the color subcarrier was added for color television the frame rate changed to 29.97 fps so that frame rate and the subcarrier were in synch.

The rate was moved to 29.97 Hz to maintain 4.5 MHz between the visual 4.3 MHz carrier and the audio carriers.  This reduces the interference between the color subcarrier and the sound subcarrier, whose frequency was fixed by the use of fixed demodulators in some receivers, rather than the more common intercarrier demodulators used for many decades now. The field rate was dropped by exactly 0.1001001 . . . repeating . . .%.  This is rounded off to 0.1%

Therefore the new rate is 30/1.001 = 29.97 fps