One situation that arises often is the need to lock a digital audio system to a "wild" time code source that is not referenced to either word clock or video. In the picture below, the HDR24/96 is locked to LTC that has been recorded onto one track of an analog multitrack tape machine.
In this example, the tape machine and the HDR24/96 will not stay in sync with each other. Even though there is no sample clock in the multitrack machine, the net effect of the tape machine servo control mechanism and the LTC generator that originally striped tape is that of a sample clock with a slightly different tolerance than the HDR24/96 sample clock. The problem of synchronizing to wild time code sources can be dealt with in several different ways.
Just like a sample clock can be resolved to video, the sample clock can also be resolved to time code through a simple mathematical relationship. For example, if your HDR24/96 is set to a 48 kHz Sample Rate and a 30 fps Time Code Frame Rate, the relationship is governed by the following formula:
(48,000 samples/sec) / (30 frames/second) = 1600 samples/frame
For more on Frame Rate see Timecode Pull-up/Pull-down.
This relationship says that for every 1600 samples that tick on the sample clock, 1 frame ticks on the time code display. Some digital audio devices will resolve their sample clocks to time code; the HDR24/96 does not. To make this setup work, an external device like the Aardvark Timesync II is needed to generate a resolved word clock from LTC.
Another common setup is to use a transport synchronizer that is genlocked to video. In this scenario, the synchronizer reads time code from the multitrack and regulates the speed of the tape transport so that the time code coming off the tape is resolved to the video signal. The synchronizer works just like the cruise control mechanism on your car: it monitors the tape's playback speed and regulates the capstan motor to keep the tape moving at a constant speed. A typical setup using a synchronizer looks like this:
It is important to note that MTC should not be used when resolving sample clock to time code; LTC is the preferred choice. This is because the LTC signal has much greater timing resolution than MTC.
LTC is a continuous signal that has a timing resolution of 80 subframes per frame, effectively producing 2400 "ticks" per second for 30 fps time code (20 samples per subframe at 48 kHz). On the other hand, MTC is a non-continuous computer data signal that is sent out in "packets" 4 times per frame. The timing of these packets is often jittery and irregular due to the nature of the hardware that generates MTC. Resolving to MTC produces a jittery sample clock that degrades the performance of any A/D and D/A converters that are slaved to it.
Another important point to note is that because MTC is sent in ¼-frame packets, it is not possible to achieve positional synchronization that is as tight as LTC. Whereas some devices may not get much better than ¼-frame accuracy using MTC, some devices like the HDR24/96 are able to achieve sample-accurate positional lock using LTC. This is because LTC acts very much like a clock signal and LTC reader hardware can accurately latch on to the edge of an LTC subframe. The bottom line is, when resolving to timecode and faced with a choice between LTC or MTC, always choose LTC. However, if you are not resolving your sample rate to timecode, MTC is more than adequate.
SMPTE LTC is an analog signal that can be distributed through any path and recorded onto any medium that you would normally use to distribute and record analog audio. The HDR24/96 supports two standard SMPTE LTC levels: -10dBV and +4dBu. The standard level for recording LTC onto analog tape is –10 dBV. This insures that the signal is hot enough to be decoded by the LTC reader, but not so hot to cause excessive crosstalk on adjacent tracks.
Always record SMPTE onto an edge track and if you project allows, leave the adjacent track unused. This "guard" track will guarantee that no SMPTE crosstalk will be heard on the closest audio track. Be sure to defeat noise reduction on the SMPTE track, as this will distort the signal. The +4 dBu level is typically used when distributing SMPTE between devices. The SMPTE output level on the HDR24/96 can be set to either –10 or +4 operation from the Sync Setup window. The HDR24/96 can lock to incoming time code at levels within the range of –25 dBV to + 15 dBu.
When time code is recorded onto analog tape, the signal quality is slightly degraded. Some devices may not be able to read SMPTE from third or fourth generation copies, especially if care was not taken during the transfer process. In practice this happens often. You can generally suspect either a SMPTE level or quality problem when the slave device stops and starts frequently, or simply will not lock to SMPTE at all. You can use a small mixer or line distribution amplifier to change the level of the time code signal going to or coming from a device. Be sure to defeat the EQ when you do this.
You can use a SMPTE regenerator to correct problems with signal quality. These devices are designed to read distorted or otherwise poorly reproduced time code and either clean up the quality of the original (called reshaping) or generate an entirely new SMPTE signal (called regenerating). It is a good idea when copying analog tapes (or even digital tapes through an analog signal path) to reshape or regenerate time code going to the copy. The picture below illustrates the use of both types of devices.
There are times you may want to offset the position of two devices with respect to each other, but still keep them synchronized to each other. For example, you may have a tape containing audio that starts at 18:22:12:00, but you want to record this material to your HDR24/96 starting at 1:00:00:00. In the HDR24/96, you can set the Time Code Offset parameter to offset the position of the HDR24/96 transport with respect to incoming time code according to the following rule:
Time Code In + Time Code Offset = Transport Position
Offsets can be either negative or positive. The above problem is solved by using a negative offset of 17:22:12:00 such that:
18:22:12:00+ (-17:22:12:00) = 1:00:00:00
In the HDR24/96 time code output always follows the transport position. Nearly every time code-capable device supports Time Code Offsets.
Similar to the Time Code Offset in the HDR24/96 is the Song Offset. The Song Offset determines what time code time corresponds to the downbeat of the first measure in Bars|Beats|Ticks display mode. Instead of affecting the time code input, the Song Offset affects only the display. Using the same example, a Song Offset of 18:22:12:00 corresponds to BBT 1:1:000. Some devices do not support display-only offsets like the HDR24/96 Song Offset.