Timecode & Sync

Introduction

No two crystals in the world run at exactly the same speed, so no two machines started together stay together. That is the whole reason this subject exists, and everything in this book is a consequence of it.

Timecode is an address. It says where we are on a timeline, as a number every machine can read: hours, minutes, seconds, frames. Give every device the same address stream and they can all agree on the moment, which is what lets a lighting cue punch on a beat four minutes into a song, and a video roll stay with audio that lives in a different machine, and six cameras stamp the same instant for an editor.

It is also a subject with an unusual property: a small number of facts explain almost all of it, and most people in this trade know those facts half-way. Everybody has heard of drop frame; very few can state the rule. Everybody knows 29.97 is odd; fewer know what the oddness costs per hour, or that there is a number for it. This book states the rules, with the figures, from the document that defines them.

And it covers the part that actually loses shows, which is not theory but distribution, verification and the backup plan. A show that is locked and unverified is a show that is going to find out in front of an audience.

How to Use This Book

Read it in order the first time. It builds: why sync exists, what a frame is, how to read the numbers, the flavours, how it is carried, how it is distributed, the other sync that timecode is not, and then the machines — servers, consoles — and finally troubleshooting and the show day itself.

The last two chapters are the ones to come back to. Troubleshooting is arranged by symptom so it can be used under pressure, and the show day playbook is a sequence you can follow with a radio in your other hand.

Keep a notebook

For every show you lock, write down five things: the frame rate, drop or non-drop, what generated the code, what chased it, and any offset you had to dial in. Offsets especially — the same venue with the same processing chain will want the same offset next year, and the number in your notebook is twenty minutes of rehearsal you get back.

A note on the words

This subject has more loose vocabulary than most. "Sync" means two completely different things — position and frequency — and the book keeps them apart deliberately, calling them timecode and reference. "Lock" is used for a device successfully chasing incoming code and also for genlock, so the book says which. Master and slave are still the common words on a show floor for the generating and following devices, and the book uses source and follower where it can be clear without being confusing. And "house sync" means a facility's distributed reference, not its timecode.

A note on safety

Timecode is the one topic in this series where a number being wrong is directly a safety matter rather than a quality matter. A timecode track can fire pyrotechnics, release automation, and move flown and rigged scenery carrying real load above people's heads. A cue that lands three seconds early does so at full speed and with no warning to anybody standing in the wrong place.

So the rule in this book is absolute and it is not a style preference: anything that moves, burns or carries load gets a human in the loop and a way to stop it that does not pass through the timecode chain. Timecode triggers lights and video. It does not get sole authority over anything that can hurt somebody. Where a show does run automation to code, that is a decision made by the people qualified to make it, with interlocks and a stop, and nothing in this book qualifies you to make it.

Two smaller ones. An audio cue fired at the wrong moment or the wrong level is a hearing risk for anybody in in-ears, so verify levels before you verify timing. And the physical work is the usual AV mix of mains power inside racks and ladder access to equipment positions.

Why Sync Exists

Two crystals, two speeds, and a gap that grows. Everything in this book follows from that, and the first thing to get straight is that there are two different problems hiding behind the word sync.

The problem timecode was invented to solve

Two machines, one show

Press play on two decks at the same instant. Come back in twenty minutes and they will not agree. Not because someone made a mistake — because no two clocks in the world run at exactly the same speed.

Every playback device has an internal oscillator, a crystal that vibrates at a fixed rate and tells the machine when the next frame is due. Crystals are precise but not identical. One might run a hair fast, another a hair slow. Over a few seconds you will never notice. Over the length of a keynote, that hair becomes a visible gap between the video and the audio, or a light cue that fires after the moment it was supposed to punctuate.

This is drift, and it is the single problem timecode exists to solve.

What 'in sync' actually means

There are two different things people mean when they say sync, and mixing them up is where most beginners get stuck.

Positional sync answers where are we? — what moment in the show are we at right now. That is timecode's job. It is an address, like a street number on a timeline.

Frequency sync answers how fast are we going? — are all machines advancing at exactly the same rate. That is genlock's job, and it is a completely separate signal.

You can have one without the other, and lots of real-world problems come from having only one when you needed both. "Genlock & Reference" goes deep on this. For now, hold the distinction: timecode says where, reference says how fast.

Where you meet it on a real show

Timecode shows up any time the show has to hit a mark that a human cannot reliably hit by hand:

• A music performance where lighting has to punch on the beat for four straight minutes
• A video roll where audio lives in the console and picture lives in a media server
• Multi-camera record where every camera must stamp the same moment identically for the editor
• Pyro, automation, or anything where a late cue is a safety issue, not just an aesthetic one
• Broadcast, where the truck, the venue, and the network all have to agree on what 10:00:00:00 means

If the show can be called live by an operator with a headset and a cue light, you may not need timecode at all. Knowing when not to use it is part of the skill.

Master and slave, chase and free-run

Every timecode system has exactly one master — the device generating the numbers. Everyone else is a slave, or in modern language, a device that chases.

A chasing device is not running its own show. It watches the incoming numbers, compares them to where it currently is, and constantly nudges itself to match. When it matches, it reports locked. When it cannot see timecode, it either stops, or freewheels on its own clock and hopes.

The two questions, and which one timecode answers

Hold the distinction this chapter has just drawn, because the rest of the book depends on it and because getting it wrong is the single commonest conceptual error in this subject.

Timecode answers where are we. It is an address, delivered as a number, and a device that reads it knows what moment the show is at. It does not make that device run at the right speed; it only tells it where it should be, repeatedly, so it can correct itself.

Reference answers how fast are we going. It is a heartbeat, not an address, and it makes machines advance in step. It carries no information about position at all.

The practical consequence is that the two faults look different and are fixed differently. A position problem shows up as something being in the wrong place — a cue early, a video starting at the wrong moment — and the fix is timecode or an offset. A frequency problem shows up as something that starts right and goes wrong slowly, or as a visible disturbance when cutting between sources, and no amount of timecode fixes it. If you can classify a complaint into one of those two in the first thirty seconds, you have done most of the diagnosis.

The most common rookie mistake on a show floor is having two masters. Two devices both generating, both convinced they are in charge, and nothing locks. One master. Always.

How to do it

1. Ask what has to hit a mark that a human with a headset could not reliably hit.
2. If the honest answer is nothing, say so; a called show may need no timecode at all.
3. List every device that must agree on position, and what each will do with the code.
4. Ask separately whether anything needs to run at the same rate, which is a different question.
5. Identify which single device will generate the code, and what it takes its own timing from.
6. Write down the frame rate and whether it is drop or non-drop, before anything else.

What goes wrong

Practice it

For the last show you worked on, or the next one.

Frames & Frame Rates

A frame is a unit of time before it is a picture. Once that lands, the whole business of 29.97 stops being a curiosity and becomes arithmetic you can do — and the arithmetic has numbers, which this chapter gives you.

Why 29.97 exists and why it still bites people

A frame is a unit of time

Video is a series of still pictures shown fast enough that your eye reads motion. The frame rate is how many of those pictures happen per second, written as fps.

For timecode purposes, stop thinking of a frame as a picture and start thinking of it as the smallest unit of time the system can address. At 30 fps, a frame is one thirtieth of a second — about 33 milliseconds. You cannot ask a timecode system to fire a cue at any finer resolution than that. If you need to be tighter, you need a faster frame rate.

The rates you will actually meet

• 24 — film. Cinema origin, still used for filmic content.
• 23.98 — 24 slowed by 0.1%. The dominant rate for scripted and commercial content in North America.
• 25 — PAL regions. Europe, most of Asia, Australia, Africa. Clean and simple.
• 29.97 — NTSC video. North America broadcast and a huge amount of corporate content.
• 30 — true 30. Common in audio-led and non-broadcast live work.
• 50 / 59.94 / 60 — high frame rate. Sports, gaming, LED content, anything where motion smoothness matters.

The 0.1% problem: where 29.97 came from

This is history, but it is history that is still on your patch panel today, so it is worth two minutes.

Black and white television in North America ran at exactly 30 frames per second. When colour was added in the 1950s, engineers had to squeeze the colour information into the existing signal without breaking every television already in people's homes. The fix was to slow the frame rate by exactly one tenth of one per cent, which moved the colour subcarrier into a slot where it would not interfere with the audio.

30 minus 0.1% is 29.97. The same slowdown applied elsewhere gives you 23.98 from 24, and 59.94 from 60.

So a rate invented as a compatibility hack in 1953 is still the reason your media server and your console disagree in 2026. That is the industry we work in.

What the 0.1% actually costs you

A machine running at 29.97 fps is running slightly slower than real time. Over one hour of wall-clock time it falls behind by about 3.6 seconds.

That number matters. If your show is an hour long and your timecode counts in whole 30-frame seconds while the video actually plays at 29.97, by the end of the show your numbers and reality are three and a half seconds apart. In broadcast, where a programme has to be exactly 58:30, that is a catastrophe. "Reading Timecode" covers the fix: drop frame.

The practical takeaway right now: 29.97 and 30 are not the same rate, and treating them as interchangeable is a slow-motion failure. Everything on the show must agree on one rate. Not almost. Exactly.

Integer vs fractional, in one line

24, 25, 30, 50, 60 are integer rates — whole numbers, no weirdness.

23.98, 29.97, 59.94 are fractional (also called pull-down) rates — the integer rate slowed by 0.1%. These are where drop frame, drift, and most of your troubleshooting live.

Pulldown, and being handed the wrong rate

Sooner or later somebody hands you 23.98 material for a 59.94 show, or 24 fps film for a 25 fps broadcast, and asks whether that is a problem. It is a solved problem with a name, and the Recommendation that defines timecode includes the conversions as annexes, which tells you how routine it is.

Going from 23.98 to 59.94 is the classic: the frames are distributed unevenly across the faster rate, in a repeating pattern, so that 24 frames occupy the same wall-clock second as 60 fields. The result plays at the right duration and has a characteristic unevenness of motion that people who look at pictures for a living can see immediately.

Going from 24 to 25 is the other common one, and it is usually done by simply running the material four per cent fast, which changes the duration and the audio pitch unless the audio is corrected separately. That is why a film that runs 100 minutes in a cinema runs 96 on European television.

What matters for a timecode job is narrower than the picture engineering: when material has been converted, its timecode and its content may no longer have the relationship the editor assumed, and the number on the server is not necessarily the number on the file. Ask what rate the material was shot at, what rate it was converted to, and what rate its timecode counts in — because those can be three different answers.

The frame rates timecode is defined for, and what fractional costs

From ITU-R BT.1366-3, the Recommendation that defines timecode and whose Part 1 replaces the older BR.780. The rates in the first group are what Part 1 covers; the second group is Part 3, added for high frame rate production. The error figures are the Recommendation's own.

Two things are worth taking from this table. First, the direction of the error reverses: counting 30 on a 29.97 signal means the timecode LAGS the clock by 3.6 seconds an hour, and with drop frame applied the residual error LEADS the clock by about 86 milliseconds a day. Neither is a fault; both are specified. Second, the exception list — minutes 00, 10, 20, 30, 40 and 50 — is the part of this subject most often half-known. Six minutes an hour do not drop frames, which is what makes the arithmetic come out, and being able to say that sentence out loud is a reliable way to end an argument on a show floor.

How to do it

1. Ask what rate the show runs at, and get it from the video source rather than the brief.
2. Establish whether it is integer or fractional, because that decides everything else.
3. If it is fractional, establish drop or non-drop and write it down.
4. Ask what rate every piece of supplied material was shot at.
5. Ask what rate each piece has been converted to, if any.
6. Ask what rate each file's timecode counts in, which may differ again.
7. Set every device to the agreed rate before testing anything.

What goes wrong

Practice it

On paper, then on a generator if you have one.

Reading Timecode

Four fields, one piece of punctuation, and two conventions that are not laws. Reading a timecode display correctly is a thirty-second skill that prevents a whole category of wasted afternoon.

HH:MM:SS:FF, drop frame, and the punctuation that matters

The four fields

Timecode is written as four pairs of digits: HH:MM:SS:FF — hours, minutes, seconds, frames.

Hours run 00 to 23. Minutes and seconds run 00 to 59. Frames run 00 up to one less than the frame rate: at 30 fps the frames field goes 00 to 29, then rolls the seconds field and starts again at 00.

So 01:23:45:18 reads as one hour, twenty-three minutes, forty-five seconds and eighteen frames. At 30 fps, eighteen frames is a bit over half a second.

Hour numbering is a convention, not a law

The hours field rarely means 'time of day'. It is used as a labelling system, and knowing the common conventions makes you look like you have done this before:

• 00:00:00:00 — simple, but the midnight rollover sits right at the start. Avoid on anything that might run backwards or pre-roll.
• 01:00:00:00 — the most common start for a single programme. Gives you a full hour of pre-roll headroom below it.
• 10:00:00:00 — broadcast convention, often with the hour field indicating reel or segment number.
• Time-of-day — the generator is set to actual clock time. Standard on multi-camera shoots so everything stamps identically and the editor can sync by clock.

Drop frame: the fix for the 0.1%

"Frames & Frame Rates" established that 29.97 falls 3.6 seconds behind per hour. Drop frame timecode corrects this by skipping numbers.

Here is the part everyone misunderstands, so read it twice: drop frame does not drop any video frames. Not one. Every picture you shot still plays. What gets dropped is the label — certain frame numbers are simply never used, the way some buildings have no thirteenth floor. The floor is there. The number is skipped.

The rule: at the start of every minute, skip frame numbers 00 and 01 — except on minutes divisible by ten.

So the count goes 00:00:59:29 then jumps straight to 00:01:00:02. But at the ten-minute mark, 00:09:59:29 goes to 00:10:00:00 normally.

Skip 2 frames per minute, 54 times per hour, and you have removed 108 frames. At 29.97 fps that is 3.6 seconds. The error is cancelled and the timecode now matches wall clock time to within a frame.

Non-drop, and how to tell them apart at a glance

Non-drop frame counts every number in order with no skipping. It is simpler, and it is correct for frame-accurate editing where you care about counting frames rather than matching clock time. Its cost is that it slowly loses touch with real time.

The punctuation tells you which one you are looking at:

• Non-drop uses colons everywhere: 01:00:00:00
• Drop frame uses a semicolon or period before the frames field: 01:00:00;00

That single character is the difference between a show that lands and a show that is three seconds off. Learn to look for it.

When to use which

• Drop frame — anything where duration must match real time. Broadcast, timed segments, anything handed to a network.
• Non-drop — live events, corporate, post workflows, anywhere frame counting matters more than clock accuracy.
• 25 fps, 24 fps, integer rates — drop frame does not exist and is not needed. There is no 0.1% error to correct.

What the display is not telling you

A timecode display shows four numbers and, if you are lucky, one character that tells you the counting mode. What it does not show you is almost as important, and it is worth listing because each omission has cost somebody a show.

It does not show the rate. A display reading 01:00:00:00 looks identical at 25, 29.97 and 30 fps. Two devices can both display the same number, both report locked, and be counting at different rates — and the only symptom will be a slow divergence that looks like a reference problem.

It does not show whether the code is real time or a label. The Recommendation is explicit that in some applications timecode is simply a label identifying frames and does not indicate time of day at all, and in others it is referenced to a real clock. There is a flag in the signal that says which, and almost no display shows it.

It does not show the binary groups — the thirty-two bits of user data riding alongside the numbers, which may carry a date, a reel number or camera metadata. That has its own chapter.

And it does not show freewheel. A device that has lost incoming code and is continuing on its own last known position looks exactly like a device that is locked, which is the single most dangerous display in this subject and the reason the troubleshooting chapter starts where it does.

So the habit to build: when somebody tells you the timecode is fine because the number is right, ask what rate, whether it is drop, whether the source is actually still present, and how they know.

The only wrong answer is a show where half the gear is drop and half is non-drop. Pick one. Write it on the schematic.

How to do it

1. Read the four fields and say the number out loud, including the mode.
2. Look at the punctuation before the frames field to get drop or non-drop.
3. Establish the rate from the device's settings, because the display will not tell you.
4. Confirm the device is receiving code rather than freewheeling.
5. Check the hour against the show's convention, since hour numbering is only a convention.
6. Compare two devices' displays against each other at the same instant, not in turn.

What goes wrong

Practice it

With any two devices that display timecode.

Flavors of Timecode

Same numbers, different delivery. Each flavour has a cable, a failure mode and a reason it exists, and the one you will meet most is the one that is secretly audio.

LTC, VITC, MTC, embedded, and network

Same numbers, different delivery

Timecode is a concept: hours, minutes, seconds, frames. How those numbers physically travel from one box to another is a separate question, and there are several answers. Knowing which flavour you are dealing with tells you what cable to pull and what can go wrong.

LTC — Linear Timecode

The one you will use most in live events. LTC encodes the timecode as an audio signal — a harsh, buzzing, modem-like tone. Because it is just audio, it travels on anything audio travels on: XLR, TRS, a spare channel on a multicore, a Dante stream, even a track on a playback file.

That is its superpower. Every audio device on the planet can carry it, split it, and route it. You can patch it like any other signal.

The catches:

• It is audio, so it is subject to audio problems — level, ground loops, hum, compression. Never run LTC through EQ, compression, or anything with automatic gain.
• It becomes unreadable at very slow speeds or when stopped, because there is no waveform to decode when nothing is moving.
• Level matters, though less than people expect. Too hot and it clips into garbage. Far too quiet and the reader loses lock. Around -3 to 0 dBu (roughly 1.1 to 1.5 volts peak-to-peak, inside the specified preferred range) is a safe target for most gear.

Never send LTC to a speaker. It is loud, ugly, and it will make the room hate you.

VITC — Vertical Interval Timecode

VITC hides the timecode inside the video signal itself, in the blanking lines above the visible picture. Its advantage over LTC is that it is readable when the picture is paused or jogging slowly, because the number is attached to each individual frame rather than encoded in motion.

You will meet it in broadcast and post environments and on SDI infrastructure. In live events it is less common than LTC, but it turns up any time video and timecode share a path.

MTC — MIDI Timecode

MTC carries timecode over MIDI. It is what connects the audio world — DAWs, QLab, show control software — to everything else. If a piece of software says it can chase timecode, MTC is frequently how.

Its limitation is resolution: MTC transmits in quarter-frame messages, so a full timecode address takes eight messages to assemble, meaning two frames of latency built in. For most cue triggering that is invisible. For anything requiring sample-accurate audio alignment, it is not the tool.

Embedded and network timecode

Embedded / ATC — timecode carried as ancillary data inside an SDI stream. Clean, no extra cable, standard in professional video infrastructure.

Art-Net timecode and sACN — timecode over the lighting network. Lets a console distribute or receive timecode across the same Ethernet already running the rig. Convenient, but it inherits every risk of the network it rides on: switch config, broadcast storms, VLAN mistakes.

PTP (Precision Time Protocol) — the direction the industry is moving. In an ST 2110 or Dante environment, PTP distributes an extremely accurate clock across the network, and timecode rides along with it. "Genlock & Reference" covers the clock side properly.

Choosing

In a live events rack today the default answer is LTC on XLR from a hardware generator, because it is simple, visible, patchable, and every technician in the room understands it. The other flavours exist to solve specific problems — use them when you have that problem, not because they sound more modern.

Past that default, the flavour is chosen for you by what the devices have sockets for, and the job is to get from what the source produces to what each destination accepts with as few conversions as possible.

The reason to minimise conversions is that each one is a box, and each box is a power supply, a setting and a thing to fail. A chain that goes generator to LTC to MIDI to a console has two conversions in it; one that goes generator to LTC to the console directly has none. On a show floor that difference is real.

Where conversions are unavoidable, know which direction loses information. LTC and VITC carry the same time address and the same binary group data, and the Recommendation specifies how to transfer binary group data in both directions — so that conversion is lossless in principle. MIDI timecode delivers the position in quarter-frame pieces, which means it cannot resolve to a single frame at the moment of delivery the way LTC can, so a system that needs exact frame accuracy wants LTC rather than MTC where it has the choice.

One practical rule above all: establish what the DESTINATION needs before you choose what the source produces. A generator that can emit three flavours at once is common, and picking the right one per destination is free; discovering at the venue that your console wanted MIDI and you brought XLR is not.

How to do it

1. List every destination and the timecode input each one actually has.
2. List what your source can produce, and how many outputs of each kind.
3. Draw the shortest path from source to each destination.
4. Count the conversions on each path and remove any you can.
5. For each remaining conversion, identify the box and who owns it.
6. Pack a spare for every conversion box, because they are small and they fail.

What goes wrong

Practice it

For a real or imagined show with four destinations.

Embedded Timecode and Timecode over IP

On a video job the timecode is usually already there, riding invisibly inside the picture, and on a modern IP plant it has become a stream of its own. Both are places people do not think to look.

Ancillary timecode, inside the SDI

A serial digital video signal has space in it that carries no picture — the ancillary data space — and a great deal rides there: captions, audio metadata, aspect ratio signalling, and timecode. Timecode carried that way is called ancillary timecode, and the Recommendation that defines timecode devotes a whole part to how it is packetised and where in the signal it is placed.

The practical consequence for a show technician is simple and frequently useful: if you have an SDI feed from a camera or a server, you very probably already have its timecode, with no extra cable. A router, a monitor or a recorder downstream can read it out. Equally, a device that re-processes the video — a scaler, a converter, a switcher — may silently strip the ancillary data, which is why timecode that was present at the source is absent at the destination with no cable having been unplugged.

Two details from the specification are worth carrying. The packet should be transmitted at least once per frame, which is what makes it usable as a position reference. And it carries both the time address and the same flags and binary groups that the standalone forms carry, so nothing is lost by embedding — the information is identical, only the delivery differs.

Where it goes wrong is in the chain. An embedded-timecode fault is almost never the timecode: it is a device in the middle that does not pass ancillary data, or passes it only in some of its outputs, or re-generates it from its own clock. Finding that device is the job, and it is done by reading the timecode at each stage rather than at the end.

One of the Recommendation's own observations is worth repeating here, because it gets missed: the packet carries a payload type, which says whether the time address inside came from LTC or from VITC. A chain can therefore be carrying both, and a device may read the one you did not mean.

Timecode as its own stream

On an ST 2110 plant, video, audio and data are separate essences, each with its own multicast address. Timecode is data, so it travels as its own stream — and that catches people out, because a receiver subscribed to video and audio has subscribed to no timecode at all.

The carriage is specified by an RTP payload format for ancillary data, which is the same ancillary data that rode in SDI, now in packets. That continuity is the useful thing to understand: a plant moving from SDI to IP has not changed what timecode IS, only the envelope it arrives in, and the same payload-type distinction between LTC-sourced and VITC-sourced addresses carries over.

The specification also provides for the ancillary data stream to be GROUPED with the media streams it belongs to, which is how a receiver knows that this timecode goes with that video rather than with some other feed on the same network. On a plant carrying many sources this grouping is not decoration — it is what makes the timecode attributable.

So the three questions on an IP plant are: is there a timecode essence at all, is this receiver subscribed to it, and is it grouped with the right video. All three are answered in the session description, which is a text file you can read — and which is therefore the fastest place to settle an argument.

Saying which clock you are referenced to

There is a second, subtler thing that moved onto the network, and it is the one this chapter exists to name. In an SDI facility, what your reference was came from a cable: it was house sync, it came from that box, and everybody knew. On an IP plant the equivalent statement has to be made in the stream's own description, and there is a specification for exactly that.

Two different clocks get declared and the distinction matters. The timestamp reference clock is the thing the stream's timestamps are measured against — in practice PTP, identified specifically enough that a receiver can tell whether it is following the same one. The media clock is how the receiver advances through the media itself, and it can be declared as generated independently, as directly referenced to the reference clock, or as taken from another stream.

That vocabulary maps exactly onto this book's opening distinction, and that is why it belongs here: the reference clock is frequency sync, declared; the media clock is how a device advances. Two streams declaring different reference clocks will not stay in step however good the network is, and a receiver that reads the declaration can say so rather than drifting silently.

The specification also provides for stating whether a clock is traceable — locked to a global time source such as GPS rather than merely to a local master. For a facility exchanging material with the outside world that distinction is the difference between agreeing with everybody and agreeing only with yourself, and it is the networked descendant of the old question about what your house sync was locked to.

What the IP specifications provide for, and the question each answers

From RFC 8331, the RTP payload format for ancillary data, and RFC 7273, RTP clock source signalling. Both are short and free. The right-hand column is the question each part answers on a job, because that is how a show technician needs to hold them.

The row to act on is the grouping one, because it is the difference between timecode that is attributable and timecode that merely exists on the network. And the reference-clock rows are the networked version of the oldest question in this book: two streams declaring different reference clocks will not stay in step, and now that declaration is written down in a file rather than implied by which cable somebody plugged in. That is an improvement, and only if somebody reads it.

How to do it

1. On SDI, read the embedded timecode at the source before assuming it is absent.
2. Read it again after every device that touches the video, to find what strips it.
3. Establish whether the payload came from LTC or VITC, since a chain may carry both.
4. On an IP plant, find the session description and read it rather than guessing.
5. Confirm a timecode essence exists and that your receiver is subscribed to it.
6. Confirm the timecode essence is grouped with the video you think it belongs to.
7. Confirm every stream declares the same timestamp reference clock.
8. Archive the session description, because comparing it later is the fastest diagnosis there is.

What goes wrong

Practice it

On any SDI or IP video chain you can reach.

Distribution

Distribution is the part that actually fails. The code was fine when it left, and somewhere between the generator and the thirty-first device it stopped being fine — and the reasons are a short list with numbers attached.

Getting clean timecode to every device that needs it

One generator, many destinations

The architecture of a timecode system is simple and it never changes: one master generator, feeding a distribution stage, feeding every device that needs to chase.

The distribution stage is the part beginners skip, and it is the part that causes the most trouble.

Why you cannot just daisy-chain

It is tempting to take LTC out of the generator, into device one, out of device one's thru, into device two, and so on. Sometimes it works. Often it does not, and here is why.

Every time a signal passes through a device, it can be degraded — level changes, impedance mismatches, added noise, slight waveform distortion. LTC is a square-ish wave, and its readability depends on those sharp edges surviving. Four devices down a chain, the edges have rounded off and the last box cannot lock.

Worse, in a daisy chain, one device failing kills everything downstream of it. Someone unplugs box two to move it, and boxes three through six all lose timecode mid-show.

The fix is a distribution amplifier — one input, many isolated outputs, each buffered and at full level. Star topology, not chain. Every device gets a direct, clean feed from a single point.

Regen, reshape, and jam sync

Three words that get used loosely and mean different things:

• Reshape (or refresh) — the device cleans up the incoming waveform's edges and passes it along. The numbers are unchanged; the signal is just made healthy again. Good for long cable runs.
• Regenerate (regen) — the device reads the incoming timecode, then generates a brand new, perfectly clean signal at that value. This is stronger than reshaping because the output is built fresh rather than repaired.
• Jam sync — the device reads incoming timecode, matches its internal generator to it, and then can carry on running on its own if the source disappears. Standard practice on multi-camera shoots: jam every camera to the master in the morning and re-jam at every break, because once the source is unplugged each camera is running on its own crystal, and crystals drift.

Freewheel

Freewheel is the setting that decides what a chasing device does when timecode momentarily disappears — a bump on a connector, a dropout, someone brushing a cable.

With freewheel set to zero, the device drops lock instantly and the cue stops. With freewheel set to, say, two seconds, the device keeps running on its own clock for two seconds, and if timecode returns within that window it seamlessly re-locks and the audience never knows.

Set it too long and a genuinely dead source keeps the device running blind for far too long. A couple of seconds is a sensible default for live work.

Cabling and grounding

• Use proper balanced audio cable for LTC. It is audio; treat it like audio.
• Keep LTC runs away from dimmer feeds, motor cable and anything else that radiates noise.
• Ground loops are the number one cause of unstable LTC. If timecode is intermittent and you have already checked levels, suspect grounding. An isolation transformer on the LTC line fixes a remarkable number of ghost problems.
• Label every timecode cable at both ends. On strike, in the dark, at 1am, you will thank yourself.

The figures a timecode line runs on

Because LTC is audio, people reach for audio instincts, and most of those instincts are right. But timecode has specified figures of its own, and knowing three of them turns an argument into a measurement.

The level is the first. A timecode output is specified for a preferred 1 to 2 volts peak-to-peak, with an allowable range from 0.5 up to 4.5 volts. That range is wide, which is deliberate and useful: the biphase-mark coding the signal uses carries its clock in its own transitions and has no DC component, so it tolerates a great deal of level variation. It is also why a timecode line that is merely quiet usually still works, and why "it must be a level problem" is so often wrong.

The connector is the second, and it settles a recurring question. The preferred connector for balanced timecode is a 3-pin XLR — male for outputs, female for inputs, pin 1 ground and pins 2 and 3 carrying the signal, exactly like audio. For unbalanced it is BNC. So timecode on an XLR is not an improvisation; it is the specified arrangement, which is worth knowing when somebody insists it should be on BNC.

The third is what actually breaks it: distortion and timing. Any combination of overshoot, undershoot and tilt is limited to 5 per cent of the waveform's peak-to-peak amplitude, and the time between clock transitions must not vary by more than 1 per cent of the average clock period. Those are the numbers that processing violates. Run timecode through a compressor, a noise gate, an EQ, a wireless link or anything with latency, and the waveform is no longer the waveform — level intact, shape ruined. That is the single commonest way a timecode line that measures fine refuses to lock.

The LTC interface, by the numbers

Figures from Section 6 of ITU-R BT.1366-3, the Recommendation that defines timecode. These are the specified characteristics of a linear timecode interface, which is to say the numbers your line is supposed to meet rather than ones a manufacturer chose.

The last row explains the other three. Biphase mark encodes a one as an extra transition in the middle of the bit cell and a zero as no extra transition, which means the clock is recoverable from the signal itself, the waveform has no DC component, and polarity does not matter — so a reversed cable is harmless and a wide level range is tolerable. What it cannot survive is anything that moves the transitions, because the transitions ARE the information. That is the whole reason the 1 per cent timing figure matters more than the amplitude figures, and the reason timecode must never pass through processing intended for programme audio.

How to do it

1. Nominate one generator as the single source for the whole show.
2. Count the destinations and get a distribution amplifier with enough outputs.
3. Give every destination its own output from the distribution stage, not a split from a neighbour.
4. Keep timecode out of every processing path -- no EQ, no dynamics, no wireless, no delay.
5. Set the generator output level into the preferred range and record what you set.
6. Decide deliberately where regeneration happens, and where it does not.
7. Decide the freewheel setting on every device that has one, and write it down.
8. Label every timecode cable at both ends, because it looks exactly like audio.

What goes wrong

Practice it

With a generator, a distribution amplifier and a scope or a meter if you have one.

Genlock & Reference

The other sync. Timecode says where, reference says how fast, and a show with only the first will start correctly and come apart slowly. This is the chapter where the book's opening distinction earns its keep.

The other sync — and why timecode alone is not enough

Two different jobs

Back to "Why Sync Exists"'s distinction, now in full.

Timecode tells devices WHERE they are. An address. A label on a moment.

Reference — genlock — tells devices HOW FAST to advance and exactly WHEN each frame begins. It is a heartbeat, not an address. It carries no numbers at all.

A system can be perfectly timecode-locked and still be visually broken, because every machine agrees on the address but each starts its frames at a slightly different instant. Switch between two such sources and you get a glitch, a roll, or a dropped frame at the transition.

Black burst and tri-level sync

Black burst (also called house sync or composite sync) is the legacy standard: an analogue video signal containing sync pulses and no picture. Distributed on BNC, standard-definition in origin, still everywhere in the world.

Tri-level sync is the high-definition equivalent, used for HD and above. Same job, different waveform.

A sync generator (or master clock) produces the reference, and it is distributed exactly like timecode — through a DA, star topology, one feed per device. Many facilities feed both timecode and reference from the same master clock unit, which is a good idea: one source of truth for both jobs.

When do you actually need genlock?

Not every show. Be honest about this:

• You need it when video sources are switched or mixed live — a switcher cutting between cameras and playback needs every input frame-aligned or cuts will glitch.
• You need it for multi-camera shoots where sources will be intercut.
• You need it for LED processing and blending where multiple processors must present frames at the same instant, or you get tearing across the seam.
• You probably do not need it for a single playback machine feeding a single screen with nothing to align to.

The tell that you needed it and did not have it: intermittent glitching at cuts, tearing across a screen seam, or a frame occasionally repeating or dropping on a source.

PTP and the networked future

In IP-based video (SMPTE ST 2110) and networked audio (Dante, AES67), reference is distributed as PTP — Precision Time Protocol, defined in IEEE 1588.

Instead of a dedicated coax carrying pulses, a grandmaster clock on the network distributes extremely accurate time to every device, which each derive their own frame timing from it. Accuracy is in the sub-microsecond range.

PTP replaces black burst in modern IP facilities, and it can carry timecode as well — collapsing both jobs onto one network. It is where the industry is going. It also means your sync now depends on switch configuration, so PTP-aware switches and correct boundary clock settings become a sync issue, not just an IT issue.

The mental model

Picture an orchestra. Timecode is the bar number everyone is reading in the score. Genlock is the conductor's beat keeping every player moving at the same speed and landing on the downbeat together.

Asking for reference, and what to ask for

On most live-event shows nobody asks for reference and nothing goes wrong, because the devices that matter are chasing timecode and correcting themselves continuously. On a video-critical show the question becomes real, and knowing how to ask is most of it.

Ask three things. First: is there a house reference at all, and what generates it? In a broadcast facility the answer is a sync pulse generator and somebody can point at it. In a hotel ballroom the answer is usually no, and that is fine as long as everybody knows.

Second: what is that reference locked to? A facility reference locked to a global time source agrees with the outside world; one running free agrees only with itself. That matters the moment material has to be exchanged with somebody else, and it is the question behind the networked notion of a traceable clock.

Third: which of my devices actually needs it? Usually a short list — cameras that will be cut between, a switcher, anything doing a genuine video mix. A media server playing out to its own screen does not need house reference to look right; it needs timecode to be in the right place. Being able to separate those two lists is what stops a reference conversation becoming an argument about budget.

And on an IP plant the same three questions survive, in different words. The reference is PTP, the grandmaster is the sync pulse generator, the question of what it is locked to is whether it is traceable, and the question of which devices need it is answered by which streams declare it. The vocabulary changed; the questions did not.

Know the bar number but ignore the conductor and you are in the right place playing at the wrong speed. Follow the conductor without knowing the bar and you are perfectly in time playing the wrong section. A real show needs both.

How to do it

1. Ask whether a house reference exists and what generates it.
2. Ask what that reference is locked to, and whether it is traceable to global time.
3. List which of your devices genuinely need frequency reference, and why each does.
4. List which only need timecode, which is usually the longer list.
5. For each device that needs reference, confirm it has an input and a cable to it.
6. On an IP plant, confirm every relevant stream declares the same reference clock.
7. Verify by cutting between two referenced sources and watching the transition.

What goes wrong

Practice it

On any system with two or more video sources.

The Bits Beyond the Numbers

Every timecode frame carries thirty-two bits of user data alongside the address, and a set of flags saying what the address means. Most people in this trade have no idea either exists, which is why both are worth a chapter.

The flags, and what the signal says about itself

A timecode word is not only four numbers. Alongside the address sit flag bits, and each one answers a question that a display does not show you.

The drop frame flag says which counting mode is in use. It exists only in 29.97 and 59.94 systems, and the Recommendation is explicit that in non-drop mode it is set to zero. So the counting mode is carried in the signal itself, not merely implied by the punctuation on a display — which means a device can read it and tell you, and a well-built chain never has to guess.

The colour frame flag exists in the older 525/59.94 and 625/50 systems and identifies the colour frame sequence. It is a legacy concern and you will rarely act on it, but recognising the name stops it being mysterious when a piece of equipment exposes it.

The binary group flags — three of them — say what the user data means, which is the subject of the next section. The crucial one of the combinations says whether the time address is referenced to an external clock or is simply a label identifying frames. That is a real distinction with real consequences: code that claims to be clock time and code that is only a label look identical on a display, and the signal itself knows which it is.

There is also a flag whose meaning depends on the delivery method — a field mark in the vertical-interval form, a polarity correction bit in the linear form — which exists so that the biphase coding can be made polarity-insensitive. That is the mechanism behind a useful practical fact from the distribution chapter: a reversed timecode cable does not matter.

The binary groups, and the data riding alongside

Eight binary groups of four bits each give thirty-two bits per frame of space that the time address does not use. It is called user data or user bits, and it is one of the genuinely underused facilities in this trade.

What goes in there is signalled by the binary group flags. One combination means the character set is unspecified, in which case all thirty-two bits may be assigned without restriction — which is how proprietary systems put whatever they like in there. Another means the groups carry an eight-bit character set conforming to the ISO standards, in which case four characters can be encoded, each occupying two groups. Several combinations are reserved.

In practice, the commonest real use is a date. A camera or generator stamping the date into the user bits means every frame of a recording carries not just the time of day but the day, which solves a real problem for anybody logging a multi-day shoot where the timecode hour rolls over at midnight. Reel numbers, camera identifiers and scene metadata are the other common uses.

Why it matters to you rather than to a post-production house: if a client reports that their footage has lost its date, or that two cameras' material cannot be told apart, the user bits are where that information was supposed to be, and a generator or camera setting is where it got turned off. Knowing the facility exists turns a mystery into a settings check.

Above sixty frames a second

Ordinary timecode cannot count a 120 fps show, and the reason is arithmetic: the frames field has two digits and the scheme was defined for rates up to 60. High frame rate production needed a different answer, and the Recommendation's third part is it.

The approach is the super-frame: rather than inventing a three-digit frames field, the scheme groups several high-rate frames into one conventional frame period and identifies which of them a given frame is, using additional frame identifier bits. So a 120 fps signal is counted as a 30 fps address plus a sub-frame identifier, and formats are defined for frame counts of 72, 96, 100 and 120, with a drop-frame variant for 120 where the underlying rate is fractional.

The practical consequence is that high frame rate timecode is carried as ancillary data rather than as a conventional LTC line, which is why the previous chapter on embedded timecode matters more as rates rise. If somebody hands you a 120 fps job, the timecode question is a video question rather than an audio one.

And it is a video question of a particular size. The interfaces that carry these rates are specified in ITU-R BT.2077, which defines serial digital interfaces for UHDTV at frame frequencies up to 120 Hz — in four parts, over multi-link 10-gigabit optical interfaces and single- and multi-link 6, 12 and 24-gigabit electrical and optical ones, with single-fiber operation at 26.73 and 100 gigabits for the rates above 60 Hz. Those are the numbers that tell you what kind of job it is: a high-frame-rate timecode question arrives attached to infrastructure most live-event crews never touch, and the right first response is to establish who owns that infrastructure.

You may never work on one. It is here for two reasons: so that a reader meeting the words super-frame or sub-frame knows what they mean, and because it illustrates something about this whole subject — timecode is a 1970s design that has been extended rather than replaced, every extension is backwards compatible, and that is both why it still works everywhere and why it has so many corners.

How to do it

1. Find a device or software that can display flags and user bits, not just the address.
2. Read the drop frame flag and confirm it agrees with the display punctuation.
3. Read the binary group flags and establish whether the address claims to be clock time.
4. Read the user bits and see whether anything is in them.
5. If a date is expected, confirm the generator or camera is set to stamp one.
6. Record what the chain carries, so a later absence is noticeable.

What goes wrong

Practice it

With any device that can show more than the time address.

Media Servers

Chasing on a media server is the commonest timecode job in live events, and nearly all of it comes down to three settings and one number that saves shows.

Chase, offset, and timeline triggering

What chasing looks like inside a server

A media server with a timeline — disguise, Watchout, Resolume, Pandoras Box, QLab — can be told to stop running its own clock and instead follow incoming timecode.

Once armed, the server watches the numbers arrive, finds the matching position on its timeline, and jumps there. From then on it stays glued, constantly making tiny corrections. On screen you will see a lock indicator, the incoming code, and usually a drift or error readout.

Reading the lock indicator is a skill. A server that says it is receiving timecode is not necessarily locked to it. Receiving means numbers are arriving. Locked means the server has matched position and is holding. Check for locked, every time, before you walk away.

Offset: the number that saves shows

Content almost never starts at the same timecode as the show. The track might be delivered starting at 00:00:00:00 while the show timeline places it at 01:14:30:00.

Offset is the fixed amount added to or subtracted from incoming timecode before the server uses it. Set the offset correctly and the content lands exactly where it belongs without re-rendering anything.

The maths is straightforward: offset = show position − content position. Get the sign backwards and your content lands twice the offset away from where it belongs — with the example above, nearly two and a half hours out — which is a memorable way to learn.

Offset also handles processing latency. If your LED processing chain adds three frames, and audio arrives with no delay, a three-frame offset on video pulls the picture back into alignment with the sound.

Frame rate agreement

This is the most common media server timecode failure and it is entirely preventable.

The server's project frame rate, the content frame rate, and the incoming timecode frame rate must all match. A server set to 30 fps receiving 29.97 will appear to lock and then slowly, quietly drift — the worst kind of failure, because it looks fine in rehearsal and falls apart by the end of the show.

Check all three before doors. Write the rate on the schematic. Say it out loud in the production meeting.

Triggering vs chasing

Two distinct ways to use timecode with a server, and picking the right one matters:

• Chasing — the server continuously follows timecode position. Best when content must stay locked frame-for-frame to a track for its whole duration.
• Triggering — a specific timecode value fires a cue, and the cue then plays on the server's own clock. Best for discrete events: start this clip, fire this look, go to black.

Chasing is more robust against a late start but relies on continuous clean timecode. Triggering only needs timecode to be valid at the trigger instant, but a missed trigger means the cue simply never happens.

Practical setup order

• Set the project frame rate first, before importing anything.
• Confirm incoming timecode rate matches, on the server's own display.
• Set the offset and verify with a rehearsal, not with arithmetic alone.
• Set freewheel to ride short dropouts.
• Decide and document what happens if timecode dies mid-show — hold, freewheel, or stop.
• Rehearse that failure once. It costs five minutes and it is the difference between a recovery and a disaster.

The order to set it up in

There is a correct order and taking it out of order wastes rehearsal time, because each step depends on the one before and a fault introduced early looks like a fault in a later step.

Frame rate first, on both the server and the generator, before anything is connected. Two devices disagreeing about rate will appear to lock and then misbehave in a way that looks like everything else.

Then get the code into the server and confirm the server SEES it, before asking it to chase anything. A server displaying incoming timecode is a different thing from a server chasing it, and confirming the first in isolation separates a cabling problem from a configuration one.

Then enable chase on one timeline and watch it follow. One timeline, not the show. If it follows, the chain works and everything after this is content.

Then dial the offset, which is the next section, and then — only then — run the actual show content. Jumping straight to running the show means a fault could be in any of four places at once.

Offset, and why it is the number to write down

Offset is a single field that shifts the server's idea of where the timecode points, and it is the answer to the complaint everybody has: the video is slightly late, or slightly early, against the audio or against the lights.

It is needed because real chains have delay in them that the timecode knows nothing about. A video path through a scaler, a switcher and a long cable run arrives later than the code did. A projector adds its own processing delay. An audio path through a console and a delay tower arrives later still. Timecode delivers position perfectly and then each path adds its own lateness, and the offset is how you compensate.

The practical method is to find it by ear and eye in rehearsal, adjust a frame or two at a time, and then — the part people skip — write it down. The same venue with the same processing chain will want the same offset next year. The number in your notebook is twenty minutes of rehearsal you do not have to spend again, and it is the single most useful entry in a timecode notebook.

One caution worth stating: an offset compensates for a CONSTANT delay. If the amount of lateness changes during the show, an offset is the wrong tool and you are looking at a frequency problem or a processing path that is not deterministic. Fix that rather than chasing it with offsets.

How to do it

1. Set the frame rate on the generator and the server, matching exactly, before connecting.
2. Connect the code and confirm the server displays it, without asking it to chase.
3. Enable chase on one simple timeline and confirm it follows.
4. Check it follows from a standing start, from mid-timeline, and after a jump.
5. Dial the offset in rehearsal, a frame or two at a time, against the real output.
6. Write the offset down, with the venue and the signal path it applies to.
7. Confirm what the server does when the code stops, and whether that is what you want.
8. Only now load and run the real show content.

What goes wrong

Practice it

With a generator and a server.

Lighting & Show Control

The other half of every locked show. A lighting console running a timecode track is doing something subtly different from a server chasing one, and the difference is where the backup plan comes from.

Timecode tracks, cue triggering, and backup plans

Timecode on a lighting console

Consoles like grandMA, ETC Eos, Hog and Chamsys all accept timecode and let you attach cues to specific timecode values. The workflow is broadly the same across platforms:

• Create a timecode pool object or show-control event list.
• Select the source — LTC input, MIDI, or Art-Net timecode.
• Put the desk into record, run the track, and hit each cue live as you hear it. The desk stamps the timecode value of every press.
• Stop recording, then edit the stamped values to clean them up. This is where the show is actually built.

That record pass is the standard method and it is worth being deliberate about: hit slightly late on purpose and nudge earlier in the edit, since your reaction time is a known constant you can subtract.

Editing the timecode track

Once recorded, every cue is a row with a timecode value you can change. The craft here is:

• Nudging — moving a cue a frame or two earlier so it feels on the beat rather than behind it. Lighting that fires exactly on the transient often reads as late, because lights have their own physical response time.
• Mechanical latency — a moving light needs time to get there, an LED par does not. Different fixture types may need different lead times for the same visual moment.
• Grouping — several cues at the same instant should share an identical value, not values a frame apart.

MSC and OSC

MSC — MIDI Show Control is a command protocol, not a timecode protocol. Rather than saying 'it is now 01:14:22:06', it says 'GO cue 42 on list 3'. It is how one device commands another directly.

OSC — Open Sound Control does a similar job over a network, with a flexible addressing scheme. It is common between QLab, media servers, consoles and custom systems.

The distinction to hold: timecode is a continuous position; MSC and OSC are discrete commands. Many shows use both — timecode to keep a musical section locked, MSC or OSC for one-off events triggered by a human.

The backup plan — non-negotiable

Any show on timecode must be able to run without it. This is not pessimism, it is professionalism.

• Every timecode-triggered cue must also exist as a manual GO the operator can hit.
• The operator must be able to disarm timecode instantly — one button, known before doors, not hunted for during a failure.
• Rehearse the failure at least once. Pull the timecode cable during a rehearsal pass and have the operator take the show manually.
• Agree the language on comms in advance. 'Timecode is down, going manual' is clear. Silence followed by improvisation is not.

Chasing against triggering, and why consoles are different

A media server chasing timecode is continuously adjusting its position to match: it is following, and if the code jumps, it jumps. A lighting console running a timecode track is usually TRIGGERING: each cue has a time stamped against it, and when the incoming code passes that time the cue fires.

That distinction decides the failure modes, and it is worth holding clearly.

A chasing device that loses code stops, or freewheels, or holds — and when code returns it jumps to wherever the code now says. Dramatic, obvious, recoverable.

A triggering device that loses code simply stops firing cues. Nothing looks broken. The lights are still on, the console is still running, and the next cue silently does not happen. That is a much more dangerous failure because it is invisible until a moment that should have changed does not.

Worse, a triggering device that receives a code JUMP may fire every cue it skipped over in rapid succession, or none of them, depending on the console and its settings. Both of those are memorable in front of an audience, and which yours does is something to find out at a desk rather than in a show.

Hence the rule the backup plan above states and this book will restate: the operator keeps a manual way to run the show, knows where they are in it, and is watching. Timecode on a lighting console is an assistant, not a replacement.

The best timecode operators are the ones who can drop out of it so smoothly the room never knows.

How to do it

1. Agree the frame rate and drop mode with whoever generates the code, in writing.
2. Confirm the console sees incoming code and displays it before building any track.
3. Build the track in rehearsal against the real content, not against a stopwatch.
4. Find out what your console does when code stops, and what it does on a jump.
5. Set it to the behaviour you want, and test both cases deliberately.
6. Keep every cue runnable by hand, in order, with the operator able to see where they are.
7. Rehearse the manual fallback at least once, with the code deliberately removed.
8. Write down the frame rate, the mode and the offset on the console's own notes.

What goes wrong

Practice it

On a console you can get access to, off show.

Troubleshooting

This chapter is arranged by symptom so it can be used under pressure. The one thing to carry into it is the order: work from the source outward, and never start at the device that is complaining.

Every common failure and how to find it fast

Work from the source outward

Timecode faults feel mysterious until you impose an order on them. Always work the same direction: generator → distribution → cable → device input → device settings.

Most people start at the device because that is where the symptom is visible. That is why most people take twenty minutes to find a fault that takes three.

Nothing locks at all

• Is the generator actually running? Generating and outputting are two different states on many units.
• Level. LTC clipping, or far too quiet. Meter it. Aim around −3 to 0 dBu.
• Two masters. Somebody else is also generating. Only one wins, and often neither does.
• Wrong input selected on the receiving device. Astonishingly common.
• Frame rate mismatch between what is sent and what the device expects.

Locks, then drifts

This is the frame rate family of faults, and it is almost always 29.97 vs 30.

The signature is unmistakable: perfect at the top of the show, visibly off by the end. If something locks and then slowly wanders, stop looking at cables. Check that the generator rate, the device rate, the project rate and the content rate are all the same number.

Second suspect: drop frame vs non-drop mismatch. Same rate, different counting, so positions diverge in a stepped rather than smooth way.

Intermittent dropouts

• Ground loop — the classic. Try an isolation transformer on the LTC line.
• Cable routed next to noise — dimmers, motors, power runs.
• Daisy chain — someone moved a box mid-chain and killed everything downstream.
• Freewheel set to zero — the system is fine, but every tiny dropout drops lock instead of riding through.
• Network congestion, if you are on Art-Net or PTP.

Jitter

Jitter is the timecode arriving unevenly — the numbers are correct but their timing wobbles. Cues fire a frame early, then a frame late. Usual causes: long unbuffered cable runs, too many devices chained, poor quality conversion, or a network with no QoS.

The fix is almost always the distribution stage: regenerate the timecode, shorten the path, use a proper DA.

Midnight rollover

At 23:59:59:29 the timecode wraps to 00:00:00:00. Any device counting through that boundary can behave unpredictably, and any cue list crossing it can misfire.

This is exactly why shows start at hour 01 or hour 10 rather than 00 — it keeps the rollover far away from anything you care about, and leaves headroom below the start for pre-roll and negative offsets.

Fast field checklist

• One generator running, one only
• Rate matches everywhere — say the number out loud
• Drop / non-drop matches everywhere
• LTC level metered and correct
• Star distribution, no daisy chains
• Every device says locked, not just receiving
• Offsets verified by rehearsal, not arithmetic
• Freewheel set sensibly, around two seconds
• Manual backup tested

Three questions before you touch anything

Under pressure the temptation is to start adjusting the device that is misbehaving, which is almost always the wrong end. Three questions first, each of which eliminates a large part of the problem.

Is anything else affected? One device failing and five fine means the fault is in that device or its branch. All six failing means it is the source or the distribution. That single question halves the problem and costs ten seconds.

Is code actually arriving, or is this freewheel? A device holding on freewheel looks locked. Removing the source deliberately and watching for a reaction is the only way to know, and it is worth doing before any other test because a wrong answer here invalidates everything after it.

Did anything change? Rate, mode, a cable moved, a device swapped, a setting touched, a piece of processing patched in. Timecode chains are stable; they do not develop faults spontaneously. Something changed, and finding out what is usually faster than diagnosing from first principles.

Then work outward from the source: generator, distribution, conversion, cable, device. At each stage ask whether the code is good HERE, and you will walk to the fault rather than guessing at it.

How to do it

1. Ask whether anything else is affected, and write down what still works.
2. Remove the source deliberately and confirm the complaining device notices.
3. Ask what changed since it last worked.
4. Verify code at the generator output.
5. Verify it after the distribution stage.
6. Verify it after any conversion box.
7. Verify it at the far end of the cable, at the device's input.
8. Change one thing at a time and put back anything that did not help.
9. When you find it, write it down, because this fault repeats.

What goes wrong

Practice it

On a bench chain, with somebody else introducing the fault.

Show Day Playbook

Everything in this book, in the order the day happens. This chapter is written to be used with a radio in your other hand, which is why it is mostly lists.

Prep, verify, communicate, and know when to bail

Before you leave the shop

• Confirm the show frame rate in writing with production. Not a hallway conversation. It goes on the schematic.
• Confirm drop frame or non-drop, and the start hour.
• Pack a spare generator. They are small and a dead one ends your day.
• Pack an isolation transformer for LTC. It weighs nothing and it solves the single most common intermittent fault.
• Pack more labelled short XLRs than you think you need.

On site — the build

• Set the generator first, before anyone asks for timecode. Rate, drop mode, start hour.
• Build the distribution star. One DA feeding isolated outputs to each device.
• Label every cable at both ends as you run it, not afterwards.
• Bring devices up one at a time and confirm locked on each before moving to the next. Bringing everything up at once means diagnosing everything at once.

The verification pass

Do not accept 'it looks fine'. Verify actively:

• Read the timecode on every device and confirm the numbers match each other, not just that numbers exist.
• Run a real pass of content and watch for drift over at least several minutes. A thirty-second test proves nothing about a rate mismatch.
• Verify offsets by watching content land, not by trusting arithmetic.
• Pull the timecode cable once, deliberately, and watch how each device behaves. Learn the failure before it is real.

Talking about timecode on comms

Clear language prevents half the problems. Use the words everyone knows:

• 'Timecode is running' — the generator is outputting.
• 'I'm locked' — my device has matched and is holding.
• 'I'm receiving but not locked' — signal present, not usable. This is a precise and very useful thing to say.
• 'Going manual' — I have dropped out of timecode and am running by hand.
• 'Standing by to re-arm' — ready to rejoin timecode at the next safe moment.

Never say 'it's not working'. Say what is and is not happening.

When to bail out

Judgement, not rules. But these are good defaults:

• Bail immediately if timecode is unstable and the show is live. A wobbling system is worse than no system. Go manual, stabilise, rejoin at a break.
• Bail before doors if you cannot prove lock across a full-length pass. Do not gamble on 'it was fine in the short test'.
• Do not bail for a single brief dropout that freewheel rode through cleanly. That is the system working as designed.

The mark of an experienced operator is not that their timecode never fails. It is that when it does, the room never finds out.

The one-page summary

• Timecode says WHERE. Reference says HOW FAST. You often need both.
• One master. Always one.
• Rate must match everywhere — and 29.97 is not 30.
• Semicolon means drop frame. Check it every time.
• Star distribution through a DA, never a daisy chain.
• Locked is not the same as receiving.
• Offset = show position minus content position.
• Every cue needs a manual backup, and you have rehearsed using it.

Glossary

How to do it

1. At the shop, set the generator's rate and mode and label every timecode cable.
2. At the shop, confirm one of every conversion box works and pack a spare of each.
3. On site, nominate the generator and confirm what it is referenced to.
4. On site, build the distribution so every destination has its own output.
5. Keep every timecode path clear of audio processing, and check it did not get patched.
6. Bring up one device at a time and confirm each sees code before asking it to chase.
7. Dial and record every offset against the real output path.
8. Run the verification pass with every device live at once.
9. Remove the code deliberately and confirm every device does what you intend.
10. Rehearse the manual fallback once, with the operator finding their place.
11. Write the rate, mode, offsets and generator identity somewhere the crew can read.

What goes wrong

Practice it

Before your next locked show.

Where to Go Next

Timecode touches more of this trade than almost any other single subject, which makes it a good place to have been. The obvious next steps are the two halves of what it synchronises: IP Video Engineering for the video essence and how timing is reconstructed at the far end, and the audio titles in this series for sample clock, which is a different and stricter problem than position.

If the network chapters here were the unfamiliar part, AV Networking Intermediate and AV-over-IP & Network Design cover the infrastructure that PTP and timecode essences ride on, including how a grandmaster is chosen and why a flat topology is kinder to clock.

The first ninety days

Lock something small, on purpose, with a generator and two devices on a bench, and then break it deliberately. Remove the code. Set one device to the wrong rate. Patch an EQ into the line. Jump the code past a cue. Each of those takes two minutes and teaches you a fault signature you will otherwise learn in front of an audience.

Then start the notebook: rate, mode, generator, chaser, offset, one line per show. Offsets especially. A technician who can walk into a venue and say "we ran four frames here last year" is a technician people ask for.

Where this leads

Timecode is a specialism that quietly makes you the person called when a show will not lock, which on large events is a reliably well-paid position. Beyond that it leads into broadcast engineering, show control and systems integration — all three of which are built on the distinction this book opened with, between where we are and how fast we are going.

What the gear actually looks like

Every device named in this book, in one place. Recognition is the whole point of Chapter 4 — use this page to attach a picture to each name before you meet it on a dock at six in the morning.

Audio

Dynamic microphone

Condenser microphone

Wireless handheld

Radio rack

Mixing console

Stage box / snake

Power amplifier

Main loudspeaker

Subwoofer

Stage monitor wedge

In-ear monitors

DI box

Video

Camera

Video switcher

Scaler / processor

Projector

LED wall panel

Confidence monitor

Lighting & control

Conventional fixture

Moving-head fixture

Lighting console

Dimmer

Show controller

Media server

Networking & infrastructure

Network switch

Patch bay

Equipment rack

Power distribution

Cable tester

A properly coiled cable

Connectors, close up

XLR

TRS / TS ¼-inch

SDI on BNC

HDMI

Cat5e / Cat6 (RJ45)

Fiber optic

DMX (5-pin XLR)

AC power — not signal