SMPTE timecode

(A logic value 0 is expressed by a high-to-low transition, a logic value 1 by low-to-high transition at the midpoint of a period). SMPTE timecode is presented in hour:minute:second:frame format and is typically represented in 32 bits using binary-coded decimal. There are also drop-frame and color framing flags and three extra binary group flag bits used for defining the use of the user bits. The formats of other varieties of SMPTE timecode are derived from that of the linear timecode. More complex timecodes such as vertical interval timecode can also include extra information in a variety of encodings. Sub-second timecode time values are expressed in terms of frames. Common supported frame rates include: • 23.98 (24 ÷ 1.001) frame/s (North American HDTV), sometimes also more precisely specified as 23.976. • 24 frame/s (film, ATSC, 2K, 4K, 6K) • 25 frame/s (PAL (Europe, Uruguay, Argentina, Australia), SECAM, DVB, ATSC) • 29.97 (30 ÷ 1.001) frame/s (NTSC American System (U.S., Canada, Mexico, Colombia, et al.), ATSC, PAL-M (Brazil)) • 30 frame/s (ATSC) In general, SMPTE timecode frame rate information is implicit, known from the rate of arrival of the timecode from the medium. It may also be specified in other metadata encoded in the medium. The interpretation of several bits, including the color framing and drop frame bits, depends on the underlying data rate. In particular, the drop frame bit is only valid for 29.97 and 30 frame/s == 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 with more arbitrary reference. After making a series of recordings, recorded timecodes typically consist of discontinuous segments. For systems using real-time video and audio signals, timecode frames start at or around the vertical sync of a video frame, so it is not possible to know the linear timecode of the current frame until the frame has already gone by. Practical real-time timecode decoders use a "flywheel" algorithm follows the ascending sequence of timecodes, and infer the time of the current frame from that, something which is also useful to skip over bit errors or dropouts in the timecode stream. However, this requires a series of good timecodes to establish the ascending sequence in the first place, and thus a boundary between discontinuous timecode ranges cannot be determined by this algorithm until several subsequent frames have passed. This restriction does not apply to systems that can access both previous and subsequent timecodes to establish a particular frame's timecode. Modern non-linear editing systems are not subject to any of these restrictions, because their video streams are contained within compressed data streams, with timecode information held as metadata. == Drop-frame timecode ==

Drop-frame timecode originates from a compromise introduced when color NTSC video was invented. The NTSC designers wanted to retain compatibility with existing monochrome televisions. To minimize subcarrier visibility on a monochrome receiver it was necessary to make the color subcarrier an odd multiple of half the line scan frequency; the multiple originally chosen was 495. With a 30 Hz frame rate the line scan frequency is (30 × 525) = 15750 Hz. So the subcarrier frequency would have been  × 15750 = 3.898125 MHz. This was the subcarrier frequency originally chosen, but tests showed that on some monochrome receivers an interference pattern caused by the beat between the color subcarrier and the 4.5 MHz sound intercarrier could be seen. The visibility of this pattern could be greatly reduced by lowering the subcarrier frequency multiple to 455 (thus increasing the beat frequency from approximately 600 kHz to approximately 920 kHz) and by making the beat frequency also equal to an odd multiple of half the line scan frequency. This latter change could have been achieved by raising the sound intercarrier by 0.1% to 4.5045 MHz, but the designers, concerned that this might cause problems with some existing receivers, decided instead to reduce the color subcarrier frequency, and thus both the line scan frequency and the frame rate, by 0.1% instead. Thus the NTSC color subcarrier ended up as 3.579 MHz ( MHz), the line scan frequency as 15. kHz ( MHz) and the frame rate 29. Hz ( Hz). The altered frame rate meant that an hour of timecode at a nominal frame rate of 29.97 frame/s was longer than an hour of wall-clock time by 3.6 seconds (for 29.97 non-drop timecode of 01:00:00:00 drop-frame timecode is 01:00:03;18 and for non-drop 00:59:56:12 drop-frame is 01:00:00;00), leading to an error of almost a minute and a half over a day. To correct this, drop-frame SMPTE timecode was invented. In spite of what the name implies, no video frames are dropped or skipped when using drop-frame timecode. Rather, some of the timecodes are dropped. In order to make an hour of timecode match an hour on the clock, drop-frame timecode skips frame numbers 0 and 1 of the first second of every minute, except when the number of minutes is divisible by ten. This causes timecode to skip 18 frames each ten minutes (18,000 frames @ 30 frame/s) and almost perfectly compensates for the difference in rate (but still accumulates 1 frame every 9 hours 15 minutes). For example, the sequence when frame counts are dropped: :01:08:59:28 :01:08:59:29 :01:09:00:02 :01:09:00:03 For each tenth minute :01:09:59:28 :01:09:59:29 :01:10:00:00 :01:10:00:01 While non-drop timecode is displayed with colons separating the digit pairs—"HH:MM:SS:FF"—drop-frame is usually represented with a semicolon (;) or period (.) as the divider between all the digit pairs—HH;MM;SS;FF, HH.MM.SS.FF—or just between the seconds and frames—HH:MM:SS;FF or HH:MM:SS.FF. Drop-frame timecode is typically abbreviated as DF and non-drop as NDF. Bit 10 of the SMPTE timecode frame is designated the Drop Frame Flag, and when set indicates that the timecode should obey drop the frame rules. == Color framing and timecode ==

Bit 11 of the SMPTE timecode frame was designated as the Color Frame Flag, which can be used to indicate that the timecode was aligned with the material's color frame sequence so that analog composite video editing equipment could make sure to edit only on appropriate color frame sequence boundaries in order to prevent picture corruption. Specific definitions of this timing relationship were defined for both NTSC and PAL colour standards. With the advent of digital timebase correctors, the composite video subcarrier could be regenerated at any phase relationship and color frame sequence mismatch ceased to be an obstacle to editing. The introduction of digital video removed the subcarrier entirely, eliminating the concept of a color frame sequence in video, rendering the Color Frame Flag obsolete and making it only of historical interest for archive material. == Studio operations and master clocks ==

In television 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, using either network time or GPS. Studios usually operate multiple clocks and automatically switch over if one fails. == Music production ==

Longitudinal SMPTE timecode is widely used to synchronize music. A frame rate of 30 frame/s is often used for audio in America, Japan, and other countries that rely on a 60 Hz mains frequency and used the NTSC television standard. The European Broadcasting Union standard frame rate of 25 frame/s is used throughout Europe, Australia and wherever the mains frequency is 50 Hz and the PAL or SECAM analog television standards were used. == Variants ==

Timecode may be attached to a recording medium in a number of different ways. • Linear timecode, a.k.a. longitudinal timecode (LTC): suitable to be recorded on an audio channel, or carried by audio wires for distribution within a studio to synchronize recorders and cameras. To read LTC, the recording must be moving, meaning that LTC is useless when the recording is stationary or nearly stationary. This shortcoming led to the development of VITC. • Vertical interval timecode, (VITC, pronounced "vit-see"): recorded into the vertical blanking interval of the video signal on each frame of video. The advantage of VITC is that, since it is a part of the playback video, it can be read when the tape is stationary. • AES-EBU embedded timecode, SMPTE timecode embedded in an AES3 digital audio connection. • control track longitudinal timecode (CTL timecode): SMPTE timecode embedded in the control track of a videotape. • Visible time code, a.k.a. burnt-in timecode and BITC (pronounced "bit-see") - the numbers are burnt into the video image so that humans can easily read the time code. Videotapes that are duplicated with these time code numbers burnt-in to the video are known as window dubs. • Film labels, such as Keykode. ==History==

There were several iterations of timecode in the late 1960s (EECO, DaVinci, Seimens, etc.). The version adopted by SMPTE was developed by Leo O'Donnell while he was working for the National Film Board of Canada. O'Donnell's version referenced time of day and used an 80-bit word that was derived from rocket telemetry. There were several patents issued on this version (US3877799, for example). Since that time, several changes have been made by SMPTE to keep up with technology, including extensions to accommodate high frame rate material. ==See also==