Using Timecodes (Part 2)
Timecode Synchronisation With Video
Part 2 of our series finds Francis Rumsey exploring timecode standards and the use of timecode with video.
Last month we looked at some basic do's and don'ts of recording and replaying timecode, as well as defining some terms which are commonplace when talking about synchronisation. We also discussed some aspects of locking audio machines together. So, by way of contrast, here's a look at how timecode relates to video.
Too many people fall into the well-known trap of referring to all timecode as SMPTE. Amongst professional users there are some sad stories (albeit amusing ones!) about clients who insisted until they were blue in the face that SMPTE timecode must be put down on the audio tapes, only to come angrily running back when they subsequently discovered that these tapes would not lock to their master video, which had been of the EBU standard. In order that you are not the subject of just such a tale, read, learn and inwardly digest the following:
This side of the Atlantic (the European side), most countries operate their television stations and broadcast to the PAL standard. It is a video standard which defines how the picture is made up, and the method of transmission, recording etc. But to us, the only really important fact is that the picture is running at a rate of twenty-five complete frames every second (25fps). Any timecode accompanying a PAL recording must be of the EBU standard, which runs also at twenty-five frames per second, otherwise any controlling equipment will not be able to reconcile the difference between code and picture.
Although there are a number of different forms of PAL used in different countries (often referred to by suffixes like PAL-M, PAL-I, PAL-D etc), these do not affect the frame rate and so can be ignored for synchronisation purposes. France and some of its colonies use the SECAM system instead of PAL, and this refers to a different method of encoding the colour information in the video picture, but this does not affect the frame rate either, so EBU code can also be used.
America and Japan work with the NTSC video standard, which runs at almost thirty frames per second, and this is where all the confusion arises. When black and white programmes were broadcast in the USA they ran at exactly thirty frames per second, and a sub-carrier was fixed at a certain frequency to carry the sound. Problems arose when they tried to introduce colour transmissions because, unfortunately, the harmonics of the colour information landed just in the wrong place and caused mutual interference with the sound. Because the frequency of the sound had to remain fixed in order to maintain compatibility with monochrome receivers, the only solution was to alter the frame rate very slightly in order to shift the harmonics so that they didn't interfere. The result of this was a frame rate of 29.97Hz for the NTSC format, so that old thirty frame receivers could still lock to it and pick up the sound.
Of course, this left the timecode chaps with something to think about: how could they adjust the timecode to have a fraction less than thirty frames per second? The answer was that they couldn't, and that drop-frame SMPTE code was introduced, which takes basic thirty frame timecode and drops two frames at the start of each minute except for every tenth minute: a method which preserves the longterm integrity of code to picture, but is always slightly out in the short term. You can probably imagine the headaches which this can cause synchroniser designers, who have to take this into account when writing software to work with drop-frame code. So what are we left with: EBU code which runs at 25fps and is used with PAL video, SMPTE code which runs at 30fps and is hardly ever used (except in digital audio), SMPTE drop-frame which is used universally with NTSC video, and a fourth standard for FILM which runs at 24fps, and can be used for locking audio to film shot at 24f ps.
This question often arises when tapes are being interchanged between countries who use different standards, or where mistakes have been made, such as the example which I cited at the beginning. The answer is NO, but there are ways of getting around the problem, and they usually involve the regeneration of timecode: so if you don't have the time or facility for this then make sure you always record the right sort of code, and specify to any third party which type you expect to see.
If you end up with, say, a video tape having EBU code and an audio tape with SMPTE drop-frame, then it will be virtually impossible to synchronise them directly. One or other tape must be re-striped, but this cannot be done by simply recording code of the new standard from a free-running timecode generator, because even the smallest difference in long-term speed stability of the generator will result in a gradual shift in real-time between the old code and the new, resulting in loss of lip-sync after a number of minutes. For these reasons, some form of reference must be employed to lock the generator so that it doesn't drift.
Genlock or house-sync (as it's often called) is used throughout video facilities to provide a common reference which can synchronise all the equipment, so that problems such as those already mentioned are avoided. The reference is distributed from a sync-pulse generator which has a very stable output and which is consequently very expensive; nevertheless, it is a vital part of a television system because it ensures that the video outputs of all the VTRs are synchronised: in other words, that all the picture frames begin and end together. If this did not happen then it would be impossible to mix pictures together, or to edit between one machine and another, as each machine's output would be randomly related to the others (see Figure 1).
Analogue audio tape recorders have not needed to be genlocked in the past, because the output is not divided up into frames, but now that timecode is being used in audio there are good reasons to consider adding this feature.
If a tape has to be re-striped to another standard then a reference must be derived from the old timecode. For the moment, we will confine ourselves to the re-striping of audiotapes, as it is more likely that these will be wrong, and easier than re-striping videotapes. Some manufacturers make a box which will derive a reference pulse at one frame rate from timecode running at another rate. Unfortunately, these boxes will not actually regenerate code, but can be used in conjunction with some generators to produce code at the new rate which is referenced to the old one.
Looking at Figure 2, you can see that timecode is fed into the 'black-box' which produces a reference pulse to lock the generator, which in turn lays down the new code on the tape. One criterion for this operation is that there is a spare track available on the tape.
Most VTRs (videotape recorders) use a control track of some sort, which is a linear, audio-style track along one edge of the tape, having a pulse sequence recorded on it at the frame rate or some multiple. This is used internally in the VTR to synchronise itself so that the head drum and linear tape speed are maintained to track the recorded scans on tape, but it is also of use to the synchroniser which can use the control track pulses in place of timecode at non-play speeds to measure the passage of tape. It is usually possible to access the CTL pulses at the VTR's parallel remote port, and these can be counted (in conjunction with a direction status) to determine how far the tape has travelled in a fast rewind or slow motion mode, when the timecode reader cannot read properly.
VITC is used on some professional VTRs as well as LTC (longitudinal timecode), and it is LTC which we have been discussing until now, because it is the only type which can be recorded on audio tracks.
A recorded video picture has what is known as a vertical interval: the period when the spot that scans the TV screen is returning to the top left from the bottom right of the picture. In this very brief period, some extra information can be recorded and transmitted, and it is here that things like CEEFAX data are placed. VITC is recorded here on two lines, and is actually a part of the recorded video, which means that it can be picked up whenever a picture is available. The great advantage of VITC is that it can be used even when the tape is stopped in freeze-frame mode, where LTC is useless because it is recorded as an audio signal.
It is most important not to confuse VITC with 'burned-in' code. Burned-in timecode is used to imprint the current timecode value on the picture, so that producers and editors can see exactly where they are on screen without having to look at a separate timecode reader. Some readers can do this job themselves, allowing the operator to determine the size and position of the time code readout numbers (eg. 10:06:27:15) on the picture. The master recording would not normally have timecode burned in, as it cannot be removed afterwards for transmission, so the burn-in would be done just before the TV monitor (Figure 3). Often, timecode is burned in to working copies of the video master for editorial purposes.
As you are probably aware, VTRs come in all shapes and sizes. Most professional VTRs, like C-format and hi-band U-matics, have a dedicated timecode track which has a wideband output (see last month) and which can be read at all speeds.
Lo-band U-matics, used a lot in audio post-production work, have two audiotracks, one of which must be used for timecode because no dedicated track is available. This cannot be read during fast-wind speeds, so CTL sync pulses must be used. The audio tracks on both hi and lo-band U-matics are in the same physical place, so it would be possible to pick up the code from a lo-band tape played back on a hi-band machine, but not vice versa (the picture would be monochrome).
This brief discourse on timecode in relation to video has been necessary before going on next month to look at the synchronisation of audio to video, and the editing of audio using timecode.
Feature by Francis Rumsey
mu:zines is the result of thousands of hours of effort, and will require many thousands more going forward to reach our goals of getting all this content online.
If you value this resource, you can support this project - it really helps!