How to Trace and Fix Lip-Sync Drift in a Studio Chain

Start with a measured offset, not an impression

Most sync complaints begin with someone saying that a presenter looks slightly late. That is a useful signal, but it is not a measurement, and fixes made on impressions tend to drift back within a week. Before touching any delay setting, capture the problem in numbers. Record a short clip at the output end of the chain that contains a clear sharp event: a clapperboard, a hand clap in shot, or a test signal with a flash and a beep generated together.

Open that recording in an editor with a frame-accurate timeline and a waveform view. Mark the frame where the picture changes and the sample where the sound begins, then note the gap in milliseconds and in frames. Write down the frame rate as well, because an offset of two frames means something different at 25 frames per second than at 50. Repeat the capture three times, since a figure that changes between takes points to a variable-latency device rather than a fixed delay.

• Use a flash-and-beep source or a clapperboard in shot
• Record at the output, not only at the camera
• Note the offset in milliseconds and in frames
• Capture at least three takes and compare them

Map every device between source and output

Once you have a number, draw the signal path on a single sheet. Include everything the picture and the sound touch: cameras, camera control units, routers, vision mixer, frame synchronisers, format converters, multiviewers that feed the programme, embedders and de-embedders, the audio console, any digital audio network, and the final encoder or playout device. Draw video and audio as two separate lines so the places where they diverge are obvious.

Next to each box, record its processing delay if the manufacturer publishes one, and mark it as unverified if you only have a nominal figure. Video devices usually add delay in whole frames, while audio devices add it in samples or small fractions of a millisecond. That difference is why audio so often arrives early: the picture has been through a scaler and a synchroniser, and the sound has taken the short route straight through the console.

• Draw audio and video as two separate lines
• Mark each device's delay as published or unverified
• Look first at scalers, converters and synchronisers

Isolate the stage that adds the delay

With the map in front of you, test the chain in sections rather than end to end. Inject your flash-and-beep source as close to the camera as you can, then record at the first point after a major video stage, such as the vision mixer output. Compare the offset there with the figure at the final output. If it jumps between two points, the device or devices between them hold the problem, and you can narrow further by moving the recording point one box at a time.

Be careful with monitoring paths. A confidence monitor may be delayed more than the programme feed, and an engineer judging sync by eye on that monitor will correct a fault that does not exist on air. Always measure on the signal that actually leaves the building. Where a device offers several processing modes, note which mode was active during the test, because a low-latency setting can remove a frame or more of delay.

Apply the correction at one place only

The temptation is to nudge delay in several devices until it looks right. Resist it. Choose one point in the chain, normally the audio console or a dedicated audio delay on the embedder, and apply the whole correction there. A single compensation point is easy to explain to the next engineer and easy to reverse if the signal path changes. Several small corrections spread across the chain will eventually be undone one at a time by someone who does not know they exist.

Set the delay to match the measured offset, then repeat the original capture and confirm the gap has closed to within the tolerance your broadcaster or platform expects. Commonly that means well inside one frame, but check your own delivery specification rather than relying on a general figure. If the offset now varies from take to take, you have found a second, variable source and the test sections need repeating.

• Pick one compensation point for the whole chain
• Re-measure after the change, using the same method
• Compare the result with your delivery specification

Check the sources that change from show to show

A chain that is in sync on a quiet Tuesday can fall out on a busy Friday, because the inputs are not always the same. Remote contributors arrive over links with their own buffers. Playback servers may output at a different frame rate or with different latency to live cameras. A guest's wireless microphone and a hard-wired presenter microphone can differ by a few milliseconds even before the console. Each of these is worth a line in your documentation with its own measured offset.

Where an input is known to differ, give it its own delay on the console input channel rather than changing the master correction. That keeps the main path trustworthy and makes the exception visible. For remote links, measure at the start of each session if the link type allows it, since the buffer size negotiated by the connection can change from one booking to the next.

• Measure remote links at the start of each session
• Give inputs with different latency their own channel delay

Document the fix so it survives staff changes

The measurement is only half the work. A fix that lives in one engineer's memory is lost at the next rota change. Write a one-page record for the chain: the signal map, the measured offsets before and after, the single compensation point and its value, the test source used, and the date and name of whoever carried it out. Keep it where the control room team can find it, and attach the capture files if storage allows.

Add a short re-check routine to the records: the same flash-and-beep test run after any change to routing, firmware, frame rate or encoder settings. Those are the moments when sync most often moves without anyone noticing. A five-minute test after each change costs far less than an on-air complaint, and it gives you a running history of how the chain behaves over time.

• Record the map, offsets, compensation point and test source
• Re-run the test after routing, firmware or format changes

Lip-sync trouble feels vague until it is measured, and then it usually turns out to be one or two devices adding whole frames of video delay. Capture an offset, map the chain, isolate the stage, correct in one place and write it down. Do that and the next engineer inherits a documented system instead of a rumour. If a chain resists this method, an audit by a second pair of ears often finds what familiarity hides.