Timecode

The only way to consistently log and capture a clip frame-accurately is to have some means of uniquely specifying each frame. Timecode serves this purpose: an address for each frame given in hours, minutes, seconds, and frames. Timecode values are shown in the format HH:MM:SS:FF and range from 00:00:00:00 to 23:59:59:FF, where FF is the highest frame number for that format: 23 for 24 fps media, 24 for PAL-rate video, and 29 for NTSC-rate video (all numbers are zero-based, so 30 frames are counted from 0 to 29). Negative timecodes aren't used.

Tip

If you try to capture a clip too close to 00:00:00:00, the deck will want to back up into "yesterday's timecode." Once the deck (or the controller) thinks it has backed up before 00:00:00:00, it'll see its timecode as being around 24 hours, and it will try to rewind 24 hours further. That's why you should always set your first capture point at least as far into the tape as the pre-roll amount of the deck.

Timecode Formats

Timecode was originally added onto video formats not designed for it, so timecode had to "piggyback" on tape in a compatible way. Longitudinal timecode (LTC) masquerades as an audio signal (actually a 1-volt peak-to-peak square wave; not a very nice audio signal) and is recorded to tape like a linear audio track. (Some early VTR conversions used an existing audio track for LTC.) LTC readers and generators access this signal through a BNC connection (or, sometimes, an XLR), converting the square wave signal to and from a timecode number.

LTC can be read at normal play speeds easily enough, but fast or slow play can be problematic, and it's not readable at all unless the tape is moving. Vertical interval timecode (VITC) was invented to circumvent that problem; it's recorded as a series of light and dark pulses in the video signal just above the active picture, in the vertical blanking area. VITC requires readers and generators built into the video equipment itself, or offboard processors that are able to interpret the information from the video signal itself. VITC can be retrieved whenever a video image is displayed, even in pause mode, but it isn't accessible whenever the tape is unthreaded, as in fast-forward and rewind modes.

LTC and VITC readers and generators are common in older editing systems, but nowadays most editors get their timecode through a serial control port connection or over FireWire. Many professional analog VTRs record both VITC and LTC and read back VITC when the tape is threaded, falling back on LTC for high-speed shuttle modes.

The Society of Motion Picture and Television Engineers (SMPTE) and the European Broadcasting Union (EBU) have standardized the way LTC and VITC are recorded, as well as the interfaces used to retrieve them from tape, hence the terms "SMPTE timecode" and "SMPTE/EBU timecode."

Digital formats (and Video8 / Hi8) use their own digital implementations of timecode, which appear to the outside world as if they were LTC or VITC. Many digital decks are able to synthesize a SMPTE-standard LTC signal and insert regenerated VITC into their video outputs, so the exact format of the timecode on tape is of no importance except to the VTRs themselves. These timecodes aren't "SMPTE timecode" strictly speaking, but the distinction is irrelevant as far as operations are concerned.

Note

All digital VTRs record timecode, but not all analog ones do. Three-quarter inch, VHS, S-VHS, Video8, and Hi8 tapes especially may or may not have timecode on them. If you have the appropriate VTR, you may be able to write timecode onto such tapes, or you might want to dub the tapes onto a digital format for editing use.

Dropframe Timecode

PAL-rate video has a timebase of 25 Hz, and when 25 frames per second are counted, the running time shown by timecode exactly matches clock time. But in the NTSC world, counting 30 frames per second when the timebase is really 29.97 Hz results in a drift of over 3 seconds per hour, and timecode disagrees with clock time. That's not a big dealunless you're running a TV station and need to keep schedules on track.

Dropframe timecode compensates for the drift by dropping certain timecode values, so that the timecode time catches up with clock time and stays roughly in sync. (Think of the dropped frame numbers like "leap frames" in reverse.) The formula is quite simple: timecode frame numbers 00 and 01 are dropped from the counting sequence at the start of every minute not divisible by 10. Thus the timecode sequence crossing the first minute boundary is as follows:

00:00:00;28

00:00:00;29

00:00:01;02

00:00:01;03

Those two dropped frame numbers are sufficient for timecode time to catch up to clock time.

To distinguish dropframe (DF) timecode from non-dropframe (NDF) timecode, the final colon is usually replaced with a semicolon.

Note that no actual video frames are dropped when using dropframe timecode. The timecode sequence drops numbers, but you're still getting all the frames you should. This is an important distinction sometimes lost on nervous commercial producers, who pay big rates to get their spots on the air and want to get every frame they're paying for.

PAL-rate shows and clips always use NDF timecode, of course. 24p material, even using a 23.98 Hz timebase, almost always uses NDF TC.

Film has its own versions of timecode, most notably edge codes and key numbers. See Appendix A in Cinema Tools Help for details.

More Info

Tube: The Invention of Television, by David E. Fisher and Marshall Jon Fisher, is perhaps the most entertainingly readable narrative of how we've gotten into this mess.