Please consider a donation to the Higher Intellect project. See or the Donate to Higher Intellect page for more info.


From Higher Intellect Vintage Wiki
Jump to navigation Jump to search

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:

  • "hours" ranges from 00 to 23
  • "minutes" ranges from 00 to 59
  • "seconds" ranges from 00 to 59
  • "frames" depends:
    • for 625-line, 50-field-per-second signals such as PAL, 00 to 24.
    • for 525-line, 60000/1001-field-per-second signals such as NTSC, 00 to 29.
      525-line timecode can be "non-drop-frame," or "525/29.97 drop-frame." See Drop-Frame Timecode below for more on this important detail.
  • "midnight" is timecode 00:00:00:00

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:

  • DM_TC_30_ND: non-drop-frame 525-line (NTSC, digital 525)
  • DM_TC_2997_4FIELD_DROP: 525/29.97 drop-frame 525-line (NTSC, digital 525)
  • DM_TC_25_ND: PAL, digital 625 (which are always non-drop (M-PAL not supported))

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:

  • LTC - Longitudinal Time Code

    LTC, sometimes ambiguously referred to as SMPTE time code, is a self-clocking signal defined separately for 525- and 625-line 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.

    SGI ships a LTC parser in libdmedia (see dmLTC(3dm)) which you can use to parse a LTC waveform out of an audio stream. Click here for sample code: ltc.c

  • VITC - Vertical Interval Time Code

    VITC timecode is a standardized part of a 525- or 625-line 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.

    SGI ships a VITC parser in libdmedia (see dmVITC(3dm)) which you can use to parse a VITC image out of a pixel buffer. Click here for sample code: vitc.c

  • 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. SGI machines connect to MIDI via a MIDI dongle that connects to the serial port of the SGI machine.

    You can use the SGI MIDI library to send and receive MIDI time code messages.

  • AES 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 very same signal generated by Indigo, Indy, Indigo2, Onyx, Onyx2, Challenge, Origin and Octane systems. The AES standard allows one to embed timecodes in the audio signal, so this is often perfect for multitrack tape decks with digital inputs. SGI may add AL support in the future to let you input and output the subcode bits.

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.

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.