Usually written DF or NDF.

Most of the time, we use time code so that an event can be easily located on a given medium (tape, disk, etc...). Thanks to its' unique adress, in HH:MM:SS:FF, any "frame" of a recording can be precisely identified, be it just audio or video (picture+audio).

In those cases, we don't really care if a snare drum impact occurs at exactly 00 Hours 03 Minutes 42 Seconds and 19 Frames since the beginning of the song. What's important here is that the snare drum is located at a precise adress, enabling the sound engineer to synchronise things to this particular event : trigger a sample, open a noise-gate, line-up another sound on that snare drum, etc...

Now, when a TV station is broadcasting a movie and, say, a commercial break must occur at a specific moment since the beginning of the movie, that moment must be precise down to the second, even down to the frame. But, the SMPTE time code can ony increment in whole frame values.

If the movie is in black & white, everything's fine :

At each new frame (lasting 1/30th of a sec.), the Time Code increments 1/30th of a sec.

If the movie is in color, the time code indication drifts as time goes by, regarding the position of the event it is supposed to represent since the beginning of the movie because :

At each new frame (now lasting a little more than 1/30th of a sec.), the Time Code still increments by a whole 1/30th (there is no other way for him to increment). He is slowly dragging behind real time.

This drift according to real time is annoying for numerous applications where American or Japanese (60 Hz) color video systems are used.

To eradicate the problem, the SMPTE has found an incrementation method for the numbers in the time code, called Drop Frame (DF). Hang on to your socks, the fun is about to begin :

Every minute, the time code increments by 3 frames instead of one. Example :

.................
01:23:59:27
01:23:59:28
01:23:59:29
01:24:00:02	<-- the TC counter jumps (drops) the adresses 01:24:00:00 and 01:24:00:01
01:24:00:03
01:24:00:04
.................

By doing that the Time Code jumps forward according to real time (that's what we're looking for, remember, otherwise the TC's dragging behind)... But now it's drifting slowly AHEAD !!!

Bummer !!!

OK... Let's think.... mmmmmhhmhhh.... Got it !

Let's go back to the normal incrementation every ten minutes !!! Example :

.................
01:29:59:27
01:29:59:28
01:29:59:29
01:30:00:00	<-- we just got to "30" minutes, the incrementation is normal. The same thing would happen when the minute number hits "00", "10", "20", "40" and "50".
01:30:00:01
01:30:00:02
.................

To sum it up, each hour, there are 54 minutes where something weird happens, and 6 minutes where everything is perfectly normal.

A good synchroniser is capable of handling any format of Time Code, be it 24, 25, 30 ou 29,97 frames/sec, and be it DF or NDF.

I insist on the fact that in a studio that uses time code only for syncing two tape recorders, for example, or to drive a mixer's automation, or to trigger samples.... without any video signal whatsoever in the project : we don't care about real time issues. What's important is that every event has its' own unique TC adress.

On the other hand, if you work for picture in a 60 Hz country, directly or indirectly, you'd better work at 29,97 DF. Sooner or later, your work is going to be confronted to the bizarre frame rate of 60 Hz color video, and you might as well use a real time TC format, which is generally expected in such work.

Hey ! You people reading this from anywhere other than North America or Japan (& the United Arab Emirates) !!! This doens't concern you. Your mains frequency is 50 Hz !!!!!!!!!!

No panic, then, your video frame rate is always 25 f/s, and there has never been a need for a DF system. We always work in NDF, to such an extent that we don't even bother saying so ! We always speak in terms of a "25 f/s time code", never "25 NDF" (and even less, except if you've gone insane, 25 DF !!!).

SUMMARY :

There are three main Time Code formats in the world, but we've seen that the SMPTE format supports several variations, which gives us a total of 6 formats. Or is it 5........

Film :	24 f/s		For motion picture. Obviously NDF, you don't even have to mention it.
EBU :	25 f/s		For television in 50 Hz mains countries. Obviously NDF, you don't even have to mention it.
SMPTE :	30 f/s	NDF	real-time, B&W 60 Hz video
	30 f/s	DF	Completely moronic ! Would you turn something that was perfectly real-time into something that's not ?!?!
	29,97 f/s	NDF	non-real-time, color 60 Hz video
	29,97 f/s	DF	real-time, color 60 Hz video

30 DF being absurd, there are only 5 Time Code formats left (several software programs, to make pretend they're professional, offer to run at 30 DF in their sync menus !!!).