SMPTE time code

Timecodes are added to film, video or audio material, and have also been adapted to synchronize music. They provide a time reference for editing, synchronisation and identification. Timecode is a form of media metadata. The invention of timecode made modern videotape editing[?] possible, and led eventually to the creation of non-linear editor[?] systems.

Basic concepts

SMPTE timecodes contains binary coded decimal hour:minute:second:frame identification and 32 bits for use by users. There are also drop-frame and colour framing flags and three extra 'binary group flag' bits used for defining the use of the user bits. The formats of other forms SMPTE timecodes are derived from that of the longitudinal timecode.

Time code can have any of a number of frame rates: common ones are

• 24 fps (film)
• 25 fps (PAL colour television)
• 30/1.001 fps (NTSC color television)
• 30 fps (American black-and-white television) (almost obsolete)

In general, SMPTE timecode frame rate information is implicit, known from the rate of arrival of the timecode from the medium, or other metadata encoded in the medium. The interpretation of several bits, including the "colour framing" and "drop frame" bits, depends on the underlying data rate. In particlular, the drop frame bit is only valid for a nominal frame rate of 30 fps: see below for details.

More complex timecodes such as Vertical interval timecode can also include extra information in a variety of encodings.

Discontinuous timecode, and flywheel processing

Timecodes are generated as a continuous stream of sequential data values. In some applications 'wall clock' time is used, in others the time encoded is a notional time. After making a series of recordings, or after crude editing, recorded timecodes may consist of discontinuous segments.

Note that in general you cannot know the current frame's LTC until the frame's already gone by to let you read it, and it's too late to make the edit. Practical systems watch the ascending sequence of the timecode, and infer the current frame's time for that.

As timecodes in analog systems are prone to bit-errors and drop-outs, most timecode processing devices check for internal consistency in the sequence of timecode values, and use simple error correction schemes to correct for short error bursts. As a result, the boundary between discontinuous timecode ranges cannot be determined exactly until several frames of code have been read after the timecode boundary.

For this reason, most videotape editing attempts to keep the timecode of the recorded material continuous, so that multiple edits may be repeatedly over-recorded onto the same piece of videotape.

Although it would be possible in all-digital systems to eliminate the flywheel algorithm by adding a frame delay to allow the timecode to be decoded prior to the processing of the frame, this is not done in most practical systems as:

• it introduces an unnecessary frame delay in the signal processing path
• there is still a need to compensate for timecode errors in signals derived from analog video or audio systems.

Drop frame timecode

Drop frame timecode is a compromise invented when color NTSC video was invented. Basically, the NTSC redesigners wanted to retain compatibility with exisiting monochrome TVs. Unfortunately, the 30Hz color subcarrier would absorb common-phase noise from the 60Hz line. Rather than adjust the audio or chroma subcarriers, they adjusted everything else, including the frame rate, which was set to 30/1.001 Hz.

This meant that an "hour of timecode" at a nominal frame rate of 30 fps was shorter than an hour of wall-clock time by 3.59 seconds, leading to an error of almost a minute and a half over a day. This caused people to make unnecessary mistakes in the studio.

To correct this, drop frame SMPTE timecode drops frame numbers 0 and 1 of the first second of every minute, and includes them when the number of minutes is divisible by ten. This almost perfectly compensates for the difference in rate, leaving a residual timing error of roughly 86.4 microsconds per day, an error of only 0.001 ppm. Note: only timecode frame numbers are dropped. Video frames continue in sequence.

Drop-frame timecode is not used at any frame rate other than 30/1.001 Hz.

Colour framing and timecode

to be written

Studio operations and master clocks

In studio operations, longitudinal timecode is generated by the studio master sync generator, and distributed from a central point. Central sync generators usually derive their timing from an atomic clock, either using network time, or GPS. Studios usually maintain two or three clocks, and automatically switch over if one fails.

A recent development is to mount small GPS-synchronized SMPTE timecode generators on each camera, which eliminates the distribution network for portable set-ups and shooting on location.

Longitudinal SMPTE timecode is widely used to synchronise music. The frame rate used for audio sync is arbitrary, and can be chosen to suit the needs of the production. A frame rate of 24 fps is popular because it reduces synchronisation problems with 48 kHz digital audio. SMPTE timecodes are often time code not specified by SMPTE.

Timecode media

The timecode has three media:

• Longitudinal - suitable to be recorded on an audio channel, or by audio wires. This is how it is distributed within a studio to synchronise recorders and cameras.
• Vertical Interval Time Code (VITC, pronounced "vitsee") recorded directly on video.
• Film labels, such as Keykode

Longitudinal timecode data format

The basic format is an 80-bit code that gives the time of day to the second, and the frame number within the second.

The bits of the longitudinal SMPTE code:

0..3: Frame units

4..7: user-bits field 1

8..9: Frame tens

10: 1=drop frame format (frame 0 and 1 omitted from first second of each minute, but included when minutes divides by ten; approximates 29.97FPS)

11: 1="color frame", i.e. the time code is intentionally synchronised with a color TV field sequence.

12..15: user-bits field 2

16..19: seconds units

20..23: user bits field 3

24..26: second tens

27: Bi-phase mark-correction bit; set or cleared so every 80-bit word has an even number of zeros. This can be used to assure that there is no net current flow in the time code system. It also allows a technician to read the bi-phase coding timing with an oscilloscope, without the signal inverting itself continually. Modern equipment regenerates the time code to a fixed timing in the video vertical interval, so this is far less needed than before.

28..31: user bits field 4

32..35: minutes unit digit

36..39: user bits field 5

40..42: minutes tens digit

43: binary group flag bit (with bit 59, 43,59 = 00 = no format for user bits, 10 = eight bit format, 01, 11 are unassigned and reserved.

44..47: user bits field 6

48..51: hours units

52..55: user bits field 7

56..57: hours tens

58: unused, reserved, should transmit zero and ignore on receive for compatibility

59: binary group flag bit (see bit 43 for encoding)

60..63: user bits field 8

64..79: sync word, should be 0011 1111 1111 1101

There are thirty-two bits of user data. These are usually used for a reel number and date. They can be anything at all, as long as bits 43 and 59 are set to zero.

The bits are encoded as "biphase". A zero bit has a single transition at the start of the bit period. A one bit has two transitions, at the beginning and middle of the period. This encoding is self-clocking.

Longitudinal SMPTE timecode should be played back at a middle-level when recorded on an audio track. Too high or too low will both cause distortion.

History

Longitudinal and vertical-interval timecodes were invented by EECO, an electronics company that developed video recorders, and later video production systems. EECO assigned its intellectual property to permit public use.

References:

• 'Timecode: A user's guide, second edition' by John Ratcliff, [Focal Press]
• 'A Technical Introduction to Digital Video' by Charles Poynton

See also:

• Linear timecode
• Vertical interval timecode
• Burnt-in timecode
• MIDI timecode
• AES-EBU embedded timecode[?]