Time and Synchronziation

9.1.1 Timecode Background

‘Timecode’, or more correctly, time and control codes, are used wherever there is need for synchronisation between multiple machines, such as audio multitrack tape recorders, computer sequencers, digital audio workstations, and video tape machines.

These codes were originally developed by broadcasters to assign every video frame a time address, allowing frame-accurate video editing. Hence the standards have come from the European Broadcast Union (EBU) and the Society of Motion Picture and Television Engineers (SMPTE). Europe uses a video frame rate of 25 frames per second (fps), practically derived from its mains electricity supply at 50Hz, whereas the USA and Japan have used a frame rate of 30 fps, derived again from their mains, in this case 60Hz. Historically, the film community has used a picture frame rate of 24 fps. Timecode is typically applied to enable identification of the location in time of any piece of recorded audio or video material by a dedicated reading device. As timecode is physically recorded with the programme, its relationship to that programme is fixed, and can be used as an accurate reference, based upon the 24 hour clock, as follows:

                        hours (0 to 23) : minutes (0 to 59) : seconds (0 to 59) : frames (0 to 23/24/29)

The largest value of timecode is 23:59:59:24 for 25 fps, and 23:59:59:29 for 30 fps. Hence, a time-of-day value of 3:54pm plus 22 seconds and 8 frames would appear: 15:54:22:08

9.1.2 Timecode Formats

There are several electrical/coding standards used in timecode systems, each of these able to carry any of the standards (EBU, SMPTE or FILM): Longitudinal Time Code (LTC), Vertical Interval Time Code (VITC), MIDI Time Code (MTC), and Serial Control (most commonly the Sony P2/9-pin protocol).

LTC is the most frequently used format in sound synchronisation, in the form of an audio-frequency signal stored on a single track of a recorder. Basically, it is a square wave, frequency modulated within each half-wavelength (termed ‘Manchester code’) to represent either a 0 or a 1. The result is a binary digital bitstream, though the recording and playback of this waveform may be in the analogue domain. Each frame consists of 80 bits of equal duration, representing time values, extra user data and timecode format information. A further synchronising section of the frame allows the timecode reader to determine the frame boundary. This ‘sync word’ differs when played backwards, enabling the reader to detect reverse direction. The digital nature of the coding produces a robust signal which is not affected by phase reversal.

LTC carrying the SMPTE standard timecode has a lowest fundamental frequency of 1.2kHz, produced by a sequence of zero values, whilst LTC carrying the EBU standard timecode generates a lowest fundamental frequency of 1kHz. As a result, these can be reproduced at a range of replay speeds, without the need for special wide-bandwidth electronics. Most readers can process timecode between 1/10th and 10-times playspeed.

VITC (pronounced vit-see) is a video frequency signal placed on two spare lines within each video frame, information never seen on a consumer TV (unless misadjusted). VITC essentially provides the same information as LTC, though additionally it may be read in still-frame mode (while the tape is stationary).

MTC is utilised by MIDI controlled equipment, and is merely an extension of that technology. A serial digital interface sends specially flagged timecode data at 31.25 kBaud, generally to synchronise a computer-based sequencing/hard-disk recording program.

The Sony P2 protocol uses the RS422 electrical interface, also transmitting timecode data across a serial digital link.

9.1.3 Timecode Frame Rates

There is often some confusion regarding which frame rates exist and where, and their proper application: Phase Alternating Line (PAL, 625 lines per frame) television, as seen in Europe, has always been 25 video fps. Traditionally, film has been 24 picture fps, and the original monochrome (525 lines per frame) television, as seen in the USA, was 30 video fps. In order to include colour information in its latter broadcasts, the National Television Standards Committee (NTSC) had to change the frame rate of its video to 29.97 fps. All monochrome broadcasts now run at this rate, being treated as colour transmissions with no colour information.

As a video stream cannot consist of incomplete frames, this new frame rate does not imply that the 30th frame belonging to each second is truncated by the first frame of the next second, but that 30 full frames take slightly longer to pass than one true second. Therefore, the remaining frame fraction (required to complete the 30th frame), is contained in the following true second. In other words, a frame rate of 29.97 represents the running speed of video/timecode with a ‘frame count’ of 30.

This change in video frame rate introduced a problem with respect to the display of elapsed time. LTC (having a frame count of 30 and locked to the video frame rate) recorded with Colour NTSC results in each timecode frame being synchronised to a video frame. However, when this recording is replayed (at the 29.97 frame rate) the full 30 frames take 1.001 seconds to complete, therefore the synchronous timecode no longer represents the true running time, and consequently gives a value that’s slower by about 0.1%.

If this was left uncorrected, the error in displayed time would lead to a significant difference between real time and timecode over long periods (approximately 3.6 seconds per hour). To achieve long term running-time accuracy with a timecode frame rate of 29.97 fps, 108 timecode frame values per hour have to be discarded, allowing the timecode to ‘catch up’ with real time. In order to spread this adjustment equally over each hour, two frames are omitted from the start of each minute, except the multiples of ten (ie. all minutes except 10, 20, 30, 40, 50, and 60 or 0). In fact a miniscule long-term error remains, approximately 75 milliseconds accruing over 24 hours, but this is considered to be within acceptable tolerances. So, this ‘drop frame’ timecode (notated 29.97 DF) counts from 0 to 29 frames, but excludes some frame values in order to keep the running time accurate.

For some audio-only editing, such as CD mastering, true 30 fps timecode (30 NDF) can be used, but for NTSC broadcast programming, drop frame 29.97 fps timecode (29.97 DF) is used.

In situations where the timecode is labelled 29.97 NDF, the 29.97 refers to the NTSC video frame rate, and the NDF reveals that the timecode is deliberately contiguous and does not drop any frames. This is used for non-broadcast editing, where running time is not so vital, and sequential frame numbering is important. When this is replayed at 29.97 fps, the displayed elapsed time will be 0.1% longer than the actual elapsed time, as the timecode is incrementing at a slower rate than the true elapsed time.

Similarly, where the timecode is stated as 30 DF, the frame rate is 30 per second, but as some frame values are being omitted, the elapsed time indicated by the timecode will be 0.1% shorter than the actual elapsed time. Hence it is only ever used to correct previous errors in timing.

Frame Type	Coding Type	FPS	Display	Applications
24	EBU/SMPTE	24	Real-time	Film worldwide
25	EBU	25(PAL)	Real-time	Video, audio and film for broadcast in PAL territories
29.97 DF	Drop frame SMPTE	29.97(NTSC)	Real-time	Video & audio edit, preferred for broadcast in NTSC territories
29.97 NDF	Non-drop SMPTE	29.97(NTSC)	0.1% less than real-time	Video & audio edit, preferred for non-broadcast in NTSC territories
30 DF	Drop frame SMPTE	30	0.1% more than real-time	Non-standard, used to correct speed problems
30 NDF	Non-drop SMPTE	30	Real-time	Audio(CD mastering), film (DTS, SDDS) and HDTV in NTSC territories

9.1.4 Other Syncronisation Methods

Other technologies exist which can be used for the acurate syncronisation of application timelines. Ardour includes support for Jack Transport. This is a sample acurate syncronisation system that can be used between applications on the same computer or via a network connection between multiple computers.