Magazine Archive

Home -> Magazines -> Issues -> Articles in this issue -> View

Using Timecodes (Part 4)

Tying It All Together

Article from Sound On Sound, May 1986

Part 4: Francis Rumsey ties up the loose ends of his series on the synchronisation of audio tracks to video, with a rundown of what to look for when buying a synchroniser system.

Having described a number of the necessary concepts in the first three parts of this series, it is to be hoped that you will now have the facility to understand the problems involved in creating a practical synchroniser system for locking audio and video machines together. This month's instalment should give potential buyers some guidelines on what to look out for, and the types of system available.


We've already seen that synchronisation splits itself broadly into two fields (no pun intended): those of audio/audio lock and audio/video lock, within which many subsections lie. It is also worth pointing out that the same systems may serve both purposes equally well as long as the software in the synchroniser has been carefully planned.

For simple applications it is quite possible that the only requirement will be for chase-lock ie. the slave transport following the master transport wherever it goes, maintaining the two timecodes in the closest correlation possible. This is about the nearest to a 'black-box' approach that we can get, and would immediately run up against limitations in use, such as the need to insert a time offset between the two transports, or the need to 'unlock' the slave at times. Immediately that any user-intervention is required, the need for some form of control panel arises, and thereafter the decision as to whether it is sensible for the control panel to be mounted on the chase synchroniser or on a separate unit ie. a controller. As soon as a separate controller is created there come all the decisions as to "how many chasers will it control?", "how much information shall we display?", and "how many buttons can we fit onto the front panel?".


This is one of the hardest factors to decide upon, and it is very easy to be fooled into thinking that more buttons means more flexibility, whereas this will often just serve to confuse the operator: it's the old story of being jack-of-all-trades but master of none!

From my own experience, "the less controls the better" seems to be a good maxim: in other words, try to decide what your primary application will be and pick a synchroniser which appears to do that job well. Bear in mind that perhaps not everyone who will use the system in the studio will understand the finer points of computer programming, so look for packages that avoid too many double or even triple-function keys! Likewise, make sure that the function of a control is easily explained by its labelling, using words which are not able to be misconstrued: for example, SYNC could be interpreted as 'lock', 'calculate offset' or 'mark sync point', whereas LOCK means what it says.

Obviously, the more machines that are to be controlled, the more controls could be needed by the user, but it is surprising what a good balance between informative display and restricted keyboard can achieve. In a multi-machine system it is rare that the operator will want to address all the machines with differing commands at the same time, so some form of common but assignable key sequence would be best.

A numerical keyboard will be almost inescapable if the operator wishes to be able to enter timecode offsets between machines, although many people would like to be able to eliminate the need to deal with numbers entirely in post-production situations. Eliminating involvement with numbers is not as hard as it might seem (although it is common for video operators to feel quite lost if they can't see timecode offsets and multiple counters incrementing all over the place), and many people would prefer to work without having to refer to every cue point, take or offset by a timecode number. It is perhaps preferable for the controller to take care of the logging internally and present the current situation in a more readily understood form to the user. After all, a large proportion of film work is done with no reference to numbers because people are good at using their ears and eyes to tell when something is right: we shouldn't be trapped into thinking that because timecode is the means of locking machines together, that we ought to present it to the operator.


A control which calculates the offset automatically is a useful tool where the point at which two sources should coincide can be cued up manually, such as the clapperboard on a film, or the start of a sound effect with the relevant point on a picture. Having manually cued the tape transports to the right place, the offset can be stored in memory and used to maintain the transports at that distance in a locked situation. This feature often goes by the name of mark sync.

Offset trim controls can be used to 'nudge' the slave either forwards or backwards in relation to the master by small amounts (perhaps less than a film frame) while the machines are locked in play mode. This will allow lip-sync adjustments and other such fine-trim operations.


In post-production sound applications, loops may be set up which can repeat themselves in order for overdubs of speech to be made. Some synchronisers provide comprehensive facilities for programming the parameters of the loop, which will be things like: Pre-Roll Start, Pre-Roll Time, Loop Begin, Record Drop-in Point, Record Dropout Point, Loop Finish, Post-Roll. These facilities could be useful in the sound studio for setting up a section of music requiring overdub rehearsals.

A good synchroniser will allow you to capture these points 'on the fly', which means that you can hit a button as the relevant point passes on the tape, and it will be stored under that timecode reading in the memory. It should also allow 'dummy-runs' or previews without actually recording.


For complex sound dubbing operations it may be useful to be able to store a number of loops in the memory, so that you can return to a particular section at a later occasion. This is a bit like a sophisticated tape autolocator which stores more than just the locate point. Certain synchronisers have memory for a hundred or more 'takes', although this might exceed most people's requirements.


One incredibly useful 'hidden' function of most synchronisers is the ability to store the timecode locations of the start and end of reels of tape, because the synchroniser will subsequently prevent the user from inadvertently spooling off the end of a reel: a very easy thing to do if you forget that you'd left a twelve hour offset in when the machines have now got the same timecode as each other! The advantage of this feature will be even more appreciated if the tape machines are situated in another room.


Commonly available synchronisers can be found in two principal forms: those in which the synchroniser part is located with the tape machine, being connected via a serial link to a controller (eg. Studer TLS 4000 system), and those in which the machine interface, synchroniser and control are all integrated (eg. Q-Lock 3.10). Figure 1 illustrates the different system configurations.

Figure 1. Typical Synchroniser Systems

System 1 uses modular synchronisers located with the tape machines, having the advantage that the combination may be used locally, without the controller, as a chase package in its own right with whatever facilities might be provided on the modular control panel. If this were a regular use for the synchroniser then it might pay to have quite a comprehensive control panel actually on the unit with the tape machine, whereas a minimal control panel would be better if a centralised system were desired. Expansion of such a system is limited only by the complexity of any controller, in its ability to address a large number of synchronisers.

System 2 is a semi-integral system, where the machine interfaces and synchronisation hardware are mounted in a rack unit, to be connected via either parallel or serial cables to the tape machines, there being no intelligent interface at the tape machine end. A control panel may be remotely sited from the card cage, although this may be just a box of switches and display. Its expansion capabilities are generally limited by the number of cards which may be contained within the rack, although it may be possible to 'daisy-chain' two rack units together.


If you're trying out a synchroniser package with a view to buying one, then here are areas where some systems fail to come up to the mark.

Check that it's possible to control all the transport functions from the tape machine's own front panel. By this, I mean that even if the synchroniser has its own Stop, Play functions etc. It is worth checking that the slaves can be made to follow and lock up if the commands are initiated at the master machine instead of at the controller. Some synchronisers are very selfish and like to do all the talking themselves!

See how closely the slaves follow the master when you shuttle the master tape backwards and forwards: it's surprising how many synchronisers allow the master to get a long way ahead before they decide to catch up, which only means that you have to wait a long time for all the slaves to re-locate when you put the master into play mode again. A good synchroniser will use the tape machine's variable speed shuttle if it has one, which allows it to maintain a close relationship to the master when doing a lot of back and forth work. Poor synchronisers tend to toggle between forward and rewind (even if the tape machine can shuttle) which means that you are ahead one moment and behind the next.

Check the offset 'window' inside which the synchroniser will decide to go into play mode from shuttle. If the slave is catching up with the master at a wind speed, it will get within a given distance from the master timecode and go into play thereafter varying the capstan speed to perform the fine lock. This window is usually a second or two long, and if it is too large the slave will take a long time to lock after going into play.

If it is just a 'chasing' pair of machines, linked only by master timecode, check how long the slave takes to stop after the master stops. It is sometimes difficult for the synchroniser to differentiate between timecode drop-outs and the master having stopped! If the slave takes more than a second to stop it will take a lot longer to re-lock when play is re-selected.

Look out for useful features like external relay closures for controlling mixing console mutes, cartridge effects machines etc, because these will allow you to tie up a much more professional system. It may, for instance, let you mute the console output during lock-up or turn on a red light when recording, and systems vary as to the flexibility which they allow in assigning closures to timecode locations.

If looping memories are provided, see what happens when the power is switched off: do they disappear?

Can you control one of the slaves locally while another is locked to the master? You may find this useful for cueing up effects on a machine which is not involved in the current locked take (only relevant in multi-machine systems).

What happens when you lose timecode on one of the machines? Does the synchroniser go haywire, try to re-lock, hold its last speed, alter the offset or flash red lights at you?

Try stopping a slave while locked to the master and see what happens.

I could go on for hours, but it might get boring. The world of audio/video synchronisation is plagued with pitfalls, even for the experienced user, so this article has by no means covered them all. If you remember one thing it ought to be that everyone's application is going to be very different, so a particular synchroniser system which suits one person down to the ground might well be the very worst thing for another.

Series - "Using Timecodes"

Read the next part in this series:

All parts in this series:

Part 1 | Part 2 | Part 3 | Part 4 (Viewing) | Part 5

More with this topic

Browse by Topic:


Previous Article in this issue

Sampling: The 30dB Rule

Next article in this issue

C-Lab Supertrack

Publisher: Sound On Sound - SOS Publications Ltd.
The contents of this magazine are re-published here with the kind permission of SOS Publications Ltd.

The current copyright owner/s of this content may differ from the originally published copyright notice.
More details on copyright ownership...


Sound On Sound - May 1986

Donated by: Gavin Livingstone




Using Timecodes

Part 1 | Part 2 | Part 3 | Part 4 (Viewing) | Part 5

Feature by Francis Rumsey

Previous article in this issue:

> Sampling: The 30dB Rule

Next article in this issue:

> C-Lab Supertrack

Help Support The Things You Love

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!

Donations for May 2024
Issues donated this month: 0

New issues that have been donated or scanned for us this month.

Funds donated this month: £24.00

All donations and support are gratefully appreciated - thank you.

Magazines Needed - Can You Help?

Do you have any of these magazine issues?

> See all issues we need

If so, and you can donate, lend or scan them to help complete our archive, please get in touch via the Contribute page - thanks!

Please Contribute to mu:zines by supplying magazines, scanning or donating funds. Thanks!

Monetary donations go towards site running costs, and the occasional coffee for me if there's anything left over!

Small Print

Terms of usePrivacy