Word Clock vs Timecode in Live Production: Sync the Right Thing

TL;DR — Word clock keeps digital-audio samples running at the same rate and phase relationship. Timecode labels moments on a timeline so playback, recording, lighting, or video systems can locate and follow show time. Neither replaces the other. A production may need one, both, or neither. Define the clock and timecode domains separately, including format, connector, source, followers, conversion, holdover, test, and fallback.

Table of contents

1. Define the two synchronization jobs
2. Decide which domain the show needs
3. Build and test the sync handoff
4. Document the production sync plan
5. FAQ

Define the two synchronization jobs

Word clock is a timing reference used to coordinate digital-audio sampling. It helps devices agree when samples occur. Depending on the system, clock may travel on a dedicated connection, be recovered from a digital-audio signal, or be distributed by a network synchronization protocol.

Timecode identifies positions on a production timeline using hours, minutes, seconds, and frames. Linear timecode (LTC) can travel as an audio-like signal; other systems carry time information through different protocols. Timecode tells a device where the production is, not how to sample its audio.

A system showing the same sample rate can still have the wrong clock relationship. Systems showing the same timecode number can still disagree about frame rate, drop-frame convention, start time, or transport state. Labels are not proof of lock.

Decide which domain the show needs

Use an audio clock for synchronous digital paths

When digital devices exchange audio without asynchronous sample-rate conversion, choose one valid clock architecture. Identify the leader or master, each follower, termination where relevant, and any external reference. Networked audio may use Precision Time Protocol rather than a dedicated word-clock cable; document the actual mechanism instead of using “word clock” as a generic label.

Avoid loops and competing leaders. A console locked to a network while feeding an external clock back into that same network can create an unstable design if ownership is unclear. Keep one authoritative reference per synchronous domain unless the manufacturer's approved redundancy design says otherwise.

Use timecode for a shared show timeline

Timecode is useful when departments must follow a common timeline: redundant playback, multitrack recording, lighting cues, video servers, captions, or show control. Agree on frame rate, drop-frame or non-drop-frame convention where applicable, start time, run mode, pause behavior, and whether a receiving device merely displays time or is expected to chase it.

Timecode alone does not guarantee sample-accurate audio alignment. Two recorders can stamp matching timecode while their sample clocks slowly differ. Long-form recording or playback workflows may require both positional timecode and a shared or appropriately converted audio reference.

Keep control protocols separate

MIDI Time Code, MIDI Show Control, OSC, GPIO, and proprietary cue protocols can carry time or commands, but they solve different problems. A “GO” message can trigger a cue without continuous timecode. Timecode can provide position without commanding play. Write the exact protocol and behavior rather than calling every show-control link “sync.”

The playback tracks rider guide covers outputs, cues, redundant systems, and operator ownership. The video and projection rider guide covers signal and playback handoffs across departments.

Build and test the sync handoff

1. List every participant. Include primary and backup playback, consoles, recorders, interfaces, video servers, lighting desks, converters, and show-control devices.
2. Separate the domains. Draw audio clock, timecode, audio transport, and control as different lines.
3. Choose each source. Name the audio clock leader and the timecode generator; do not write only “house sync.”
4. Define formats. Record sample rate and clock transport; record timecode frame rate, convention, level, connector, and start time.
5. Configure followers. Confirm each device reports the intended source and a stable lock or chase state.
6. Run a known sequence. Record a slate or cue with a visible and audible reference, then compare destinations.
7. Test duration. Run long enough to reveal drift, not merely a ten-second lock indication.
8. Break the primary path. Observe mute, holdover, free-run, switchover, and recovery behavior.
9. Restart in show order. Prove that power cycling and application relaunch do not silently select internal clock or a default frame rate.
10. Save evidence. Record device states, offsets, owners, acceptance criteria, and the fallback procedure.

Failure clues

Common mistakes

• using “sync” without naming whether it means samples, position, transport, or cues;
• assuming LTC is an audio sample clock because it travels on an audio connector;
• specifying a frame rate without drop/non-drop convention or start time;
• setting more than one preferred clock leader without an approved election plan;
• forgetting network clock status because no BNC word-clock cable is present;
• checking a lock icon but never recording a long test;
• feeding timecode into a channel that reaches the PA, stream, or monitors;
• omitting the backup generator, free-run behavior, and restart order.

Document the production sync plan

The exact values must come from the show's video, broadcast, recording, and playback requirements. Do not copy a familiar frame rate or clock topology from another production. When separate systems require separate domains, show the converter or distribution boundary and who is allowed to change it.

Sync handoff checklist

• Audio clock, timecode, transport, and cue control are drawn separately.
• Every source and follower is named.
• Sample rate, clock transport, frame rate, convention, and start time are explicit.
• Distribution, isolation, termination, conversion, and offsets are recorded.
• A long end-to-end test passed on primary and backup paths.
• Loss, holdover, free-run, restart, and recovery behavior are known.
• Owners and manual fallback are visible to every department.

FAQ

What is the difference between word clock and timecode?

Word clock coordinates when digital-audio samples occur. Timecode labels positions on a production timeline. Word clock supports clean synchronous audio; timecode lets devices locate or follow show time. They are independent references.

Do you need word clock and timecode together?

Sometimes. A long-form multitrack or playback system may use an audio clock to prevent sample drift and timecode to align the recording or cues with the show timeline. A simple console system may need only its internal or network audio clock and no timecode.

Can timecode synchronize digital audio devices?

Timecode can align positions and timestamps, but it is not normally the sampling reference. Devices exchanging synchronous digital audio still need a valid audio clock relationship or asynchronous sample-rate conversion.

What frame rate should live timecode use?

Use the rate required by the production's video, broadcast, playback, or post workflow. Confirm the exact rate, drop/non-drop convention where relevant, start time, and offsets with every department. There is no universal live-show value.

What happens when word clock is lost?

Behavior depends on the device and architecture. A follower may mute, click, report unlock, switch reference, or free-run. Test the actual system and document the audible result, switchover time, recovery method, and authorized backup.

Keep every sync domain visible

Build and share the current Rider with Techrider.live, map the audio-clock and timecode handoffs beside their devices, and invite playback, audio, video, lighting, and recording owners to edit the same Rider. Save the tested state and inspect history so a changed rate, frame setting, or source cannot hide behind the single word “sync.”