lurkertech.com → Lurker's Guide → Timecode

Timecode

By Chris Pirazzi. Thanks to Bill Fancher for correction to my drop-frame error calculations.

The word timecode has several different, but related, meanings in different domains. This document helps you understand the complete picture.

Table of Contents

• 1. Timecode as a Numbering Scheme
  • Drop-Frame Timecode
• 2. Timecode as a Data Stamp in a Computer
• 3. Timecode as a Signal over a Wire
• 4. Timecode as a Signal on a Tape
• Fields, Dominance, and Timecode Signals
• I Want More Info

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:

• "hours" ranges from 00 to 23
• "minutes" ranges from 00 to 59
• "seconds" ranges from 00 to 59
• "frames" depends:
  • for 25-frame- or 50-field-per-second systems such as PAL, 00 to 24.
  • for 30M-frame- or 60M-field-per-second systems such as NTSC, 00 to 29.
    30M timecode can be "non-drop-frame," or "drop-frame." See Drop-Frame Timecode below for more on this important detail.
• "midnight" is timecode 00:00:00:00

Manipulating timecode mathematically in software is very tricky because there are so many cases. It's best if you can find a trusted library to:

• add and subtract timecodes
• convert timecodes to and from integer counts of "frames since midnight"

If you end up coding it yourself, test it well and make it open source!

Drop-Frame Timecode

Above we told you that the "frames" field of 60M field per second video ranges from 00 to 29. This is true, but there is a catch. The 60M field rate tells us that there are 30M (30/1.001) 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 counted up 60*60*30=180,000 frames of timecode, but each frame is 1.001/30 seconds long, so that works out to:

60*60*30 timecode frames * ((1.001/30) seconds/video frame)
= 3603.6 seconds
= 1 hour 3.6 seconds


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 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 timecode gives you an average of 29.97 frames per second. This is imperfect (29.97 is not equal to 30/1.001), but it is a lot closer than 30. Consider the error after a 24-hour period:

In 24 hours we get:

(24*60*60 sec/day)*(30/1.001 frames/sec)
= 2,589,410.589... frames/day
= D


actual video frames.

Non-drop-frame timecode is 30 frames/second. If it ticks D times, it reads:

D / (24*60*60*30)
= 0.99900... days
= 1 day minus 2,589 frames
= 1 day minus 1 minute 26 seconds 9 frames


An error of more than 1 minute!

Drop-frame timecode is 29.97 frames/second. If it ticks D times, it reads:

D / (24*60*60*29.97)
= 1.000001... days
= 1 day plus 2.59... frames


An error of about 2.59 frames.

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.

For completeness, we should mention that there is another kind of drop-frame timecode, used only in M-PAL countries like Brazil (M-PAL is a system based on PAL color encoding but with the evil 60M field rate of NTSC). In M-PAL drop frame (also called 625/29.97 drop frame, to distinguish it from the "regular" 525/29.97 drop frame), the standard set of frames to drop is different. The resulting average rate is still 29.97 though. M-PAL almost never comes up in any software or hardware though, so we will not discuss it further here.

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. QuickTime, OSF, AAF, and other formats 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:

• LTC - Longitudinal Time Code

  LTC, sometimes ambiguously referred to as SMPTE time code, is a self-clocking signal defined separately for 60M-frame-per-second and 50M-frame-per-second signals. The signal occupies its own channel and resembles an audio signal in voltage and bandwidth. LTC is the most common choice for situations where you want to slave one machine's transport to that of another machine (in the sense that both machines will be on the same frame, not in the sense that the signals on both machines will be genlocked). In a LTC signal, there is one codeword for each video frame. The corresponding video signal is present on some other wire. The codeword contains a timecode, 32 "user bits" (see VITC below), and some other useful information (such as whether or not the timecode in the codeword is drop-frame). In some audio and MIDI applications, LTC is useful even though there is no video signal.

  On a computer, you don't need special hardware to parse LTC. You can plug it into an audio input and parse it in software, although as it's tricky handling all the various corner cases and bad-signal cases, I'd recommend using a tested library.

• VITC - Vertical Interval Time Code

  VITC timecode is a standardized part of a video signal. The code itself occupies some lines in the vertical blanking interval of each field of the video signal (not normally visible on monitors). Each VITC codeword contains a timecode, 32 "user bits" as with LTC, an F1/F2 field indicator, and some other useful information (such as whether the timecode in the codeword is drop-frame). People use the user bits to store information such as reel and shot number. This information can be used to help index footage after it is shot. Under the right circumstances (not always trivial), the original VITC that is recorded with footage can even "tag along" with that footage as it is edited, allowing one to produce an edit list or track assets given a final prototype edit.

  As with LTC, you don't have to have a special hardware box to decode LTC. Many video input devices can pull in the video lines containing VITC along with the picture, and you can parse it in software. Again it's tricky handling all the noise and sampling issues so be ready for lots of testing, or buy something you trust.

• D-VITC - Digital Vertical Interval Time Code

  VITC was so useful that when the video industry switched over to digital electrical signals and their corresponding tape formats, they defined an ancillary protocol whereby you could shove a full VITC codeword (including timecode, user bits, etc.) into the video raster in digital form.

  This form is even easier for a computer to read, assuming that your video input device is able to pull out the horizontal and vertical ancillary regions for you.

• MIDI Time Code

  In the audio world, production studios often need to synchronize the transports of computers with the transports of multitrack audio tape recorders and dedicated MIDI sequencers. Sometimes LTC is used for this, and sometimes MIDI time code is the clock signal of choice. MIDI time code is part of the standard MIDI protocol, which is carried over a serial link that is also called MIDI (in recent years, MIDI has gotten an upgrade to faster links, but the timecode idea remains). Computers generally connect to MIDI via a MIDI dongle that connects to the game port (not serious) or USB port (serious).

  You can use your platform's MIDI library to send and receive MIDI timecode just like any other MIDI control message.

• AES / ADAT / ... Digital Audio Streams

  Another common timecode signal in the audio world, especially in production studio situations not involving MIDI sequencers, is (silent) AES digital audio. The AES standard allows one to embed timecodes in the audio signal, so this is often perfect for multitrack tape decks with digital inputs. Same goes for ADAT and several newer standards that can carry more audio channels at once.

4. Timecode as a Signal on a Tape

Believe it or not, tape decks (VTRs) are still in use for both video exchange and editing in production studios today, and even the digital devices replacing them must sometimes emulate VTR behavior (e.g. its deck control protocols) in order to fit into the existing studio infrastructure.

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 All About Video Fields 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, 1999) provides excellent details and history on analog and digital 525-, 625-line, and film timecodes. It has a good bibliography which points to other relevant standards documents.