By Chris Pirazzi.

This document explains the four meanings of "timecode," and refers you to SGI software that helps you manipulate these forms of timecode where relevant.

1. Timecode as a Numbering Scheme

Whenever you format a description of time as "hours:minutes:seconds:frames," you are using a numbering scheme referred to as timecode. This scheme may show up in a wide variety of places (GUIs, libraries, serial protocols, etc.), but in all cases the numbering scheme is the same. As with everything else in video, the numbering scheme comes with its own set of video-related idiosyncrasies: SGI software represents timecode using the DMtimecode C typedef from /usr/include/dmedia/dm_timecode.h:
typedef struct {
   int hour;
   int minute;
   int second;
   int frame;
   int tc_type;
} DMtimecode;
The tc_type field (discussed in tc_type(3dm)) tells you the signal type (whether 24 or 29 is the maximum "frame" value), and whether the timecode is drop-frame. You pretty much always want to use one of these values for tc_type: SGI provides several very handy routines in libdmedia to let you perform interval calculations on timecodes and convert them to and from strings, seconds since midnight, or frames since midnight. Check out dmTCAddFrames(3dm), dmTCAddTC(3dm), dmTCFramesBetween(3dm), dmTCFramesPerDay(3dm), dmTCFromSeconds(3dm), dmTCFromString(3dm), dmTCToSeconds(3dm), and dmTCToString(3dm).

Drop-Frame Timecode

Above we told you that the "frames" field of 60000/1001 field per second video ranged from 00 to 29. This is true, but there is a catch. The 60000/1001 field rate tells us that there are 30000/1001 frames per second, but having 30 possible values for "frames" implies 30 frames per second. As a result, the timecode does not accurately reflect hours, minutes, seconds, and frames of real time!

For example, say you're capturing NTSC video, and you assign each incoming frame a timecode which is one frame higher than that of the previous frame. Say you start this process with timecode 00:00:00:00 and stop when you get to timecode 01:00:00:00. You recorded one hour of video, right? Wrong. You recorded 60*60*30 frames at 30000/1001 frames per second, which is 1 hour and 1.001 frames of material. If you are trying to produce a clip of an exact length (for insertion into other material or synchronization with an audio track, for example), you must often be aware of the distinction.

If you never need to take large differences between timecodes and interpret them as real-time (for example, if all your material is very short), then these disparities might not matter. Using all 30 values of the "frame" field like any sane person would is called "non-drop-frame timecode."

However, if you have long material, you may need to use "drop-frame 525/29.97 timecode." This is a numbering scheme where "frames" still goes between 0 and 29, but where you purposely skip a certain, standard set of hours:minutes:seconds:frames combinations. You skip the first two frame numbers (0,1) at the start of each minute, except minutes 0, 10, 20, 30, 40, and 50. No video data is dropped: you merely assign timecodes that sometimes increment by more than one frame to subsequent frames of video data.

Drop-frame 525/29.97 timecode gives you an average of 29.97 frames per second. This is imperfect (29.97 is not equal to 30000/1001), but it is a lot closer than 30. Drop-frame 525/29.97 timecode will give you an error of two frames per day, compared to 24 for non-drop-frame timecode. Studios take it as part of their regular operating procedure to reset their timecode generators occasionally, and to never trust timecode intervals longer than about 12 hours.

625/29.97 is another kind of drop-frame timecode used only for M-PAL (an NTSC-rate video signal based on PAL encoding, used in Brazil). The standard set of frames to drop is different than with "drop-frame 525/29.97 timecode" (the resulting rate is still 29.97). But no current SGI device supports M-PAL.

For the specifics of exactly which frames are dropped in a given, drop-frame code (and why), check out the Ratcliff book cited below.

2. Timecode as a Data Stamp in a Computer

One common computer application of timecode is as a stamp on particular frames in a movie file. The SGI movie file format and the Quicktime format offer the ability to associate each image in the file with a timecode. Sometimes these timecodes are synthesized by the computer, and sometimes they were captured along with the source material. These timecodes are often used as markers so that edited or processed material can be later correlated with material edited or processed on another machine.

3. Timecode as a Signal over a Wire

There are several types of over-the-wire electrical timecode signals. These signals are used as clocks by which one master device can drive the input or output of data by other slave devices. Each "tick" of the clock consists of a unique signal which represents---you guessed it---a timecode. This section is not about timecode that is written on a tape; on-tape timecode will be described in the next section.

Some of the more important over-the-wire timecode signals are:

4. Timecode as a Signal on a Tape

When a deck reports its current position (its current timecode) to its controller or responds to a command to edit-in or edit-out at a certain position (timecode), it needs a reliable way to determine just where that tape position is. Decks use on-tape timecode signals for this. Often part of configuring a computer deck control setup consists of telling the deck which on-tape timecode source to use for making its transport and edit decisions.

Some video tape formats include extra tracks for the storage of timecode. Sometimes, timecode is stored on audio tracks of video tapes. This on-tape timecode signal often mimics an over-the-wire timecode signal, as is the case for LTC. Sometimes the on-tape format is totally proprietary, as with Hi8's RC time code track; in these cases there is often a deck option to translate the proprietary on-tape signal to and from a standard over-the-wire timecode signal. In addition, almost any deck is capable of storing and retrieving VITC since it is part of the video signal, and LTC can be stored on any audio track.

Some of the new consumer-level deck control protocols function on decks that do not store unique per-frame timecodes with each frame (or field). Therefore these systems have limited accuracy for deck control applications.

Fields, Dominance, and Timecode Signals

Timecode signals such as LTC or VITC are recorded along with video. Video is composed of fields, but codewords in these timecode signal formats contain an hh:mm:ss:ff timecode in frames. Someone needs to decide when to increment to the next timecode: after an F1 field or after an F2 field. ANSI/SMPTE 12M-1986 specifies that both timecode signals increment after an F2 field. See Definitions: F1/F2, Interleave, Field Dominance, and More for more information about this and for some caveats about how this relates to field dominance.

I Want More Info

As usual, the specs are the best place to go.

Get yourself a copy of ANSI/SMPTE 12M-1986 for information on LTC, VITC, and drop-frame 525/29.97 timecode.

"Time Code: A User's Guide" by Ratcliff (Oxford: Focal Press, 1993) provides excellent details and history on 525-, 625-line, and film timecodes. It has a good bibliography which points to other relevant standards documents. There is a more up-to-date version than the 1993 edition, so look for that.