Timecode drift: causes and fixes — why jammed devices stop agreeing
Every device was jammed at call. The 9 a.m. takes sync frame-perfectly. The 4 p.m. takes are two frames out, and tomorrow’s will be worse. Nothing is broken: from the moment a jam-sync ends, every device free-runs on its own crystal, and no two crystals run at the same speed. Here is how fast real hardware drifts, what makes it drift faster, how to measure it in the edit — and how to keep it from ever reaching the timeline.
The symptom: sync that decays over the shooting day
Timecode drift has a recognisable shape in post. Within a single take the sync looks fine — or very nearly fine. But the offset between devices changes from take to take, growing steadily with time of day: spot-on at call, half a frame by mid-morning, a frame and a half after lunch, two or three frames by wrap. Each clip needs its own correction, and the corrections form a straight line if you plot them against the time each take was rolled.
That shape distinguishes drift from its two look-alikes. A bad jam produces one constant offset on every take from a device, all day — wrong by the same amount at 9 a.m. and at 6 p.m. A frame rate mismatch produces drift within every take, at exactly 0.1% (1 ms per second) — a much steeper slope than any healthy crystal, and one worth ruling out first via the frame rate mismatch guide. True oscillator drift sits in between: too slow to see inside most takes, fast enough to walk visibly across a day.
The mechanism: parts per million, in real frames
A jam-sync copies a time value into a device, then disconnects. What it cannot copy is the rate at which the device counts onward — that comes from the device’s own quartz oscillator, and quartz accuracy is specified in parts per million (ppm). One ppm means one microsecond of error per second. It sounds negligible; it compounds:
- 1 ppm = 3.6 ms per hour = 86.4 ms per day — a touch over two frames a day at 25 fps.
- ±5 ppm (a decent camera spec): ~0.45 frames per hour — a full frame roughly every two and a quarter hours, ten frames by the same time tomorrow.
- ±25 ppm (consumer-grade clocks): a frame every ~27 minutes, over two seconds per day.
- ±0.2 ppm (temperature-compensated oscillators — TCXO — in dedicated sync boxes): under half a frame per day. This is the entire engineering case for dedicated timecode generators: not better time, better timekeeping.
For scale: lip-sync becomes noticeable at roughly 40 ms — one frame at 25 fps — and a frame rate mismatch is 1,000 ppm. Two jammed cameras drifting in opposite directions add their errors, so a ±5 ppm A-camera against a ±5 ppm sound recorder can be a frame apart within a couple of hours of the jam.
What makes a crystal drift faster
Initial tolerance. The ppm rating on the datasheet is where the oscillator starts, not where it stays. Two units of the same model sit at different points inside the tolerance band, which is why one camera body “holds timecode well” and its twin does not.
Temperature — the big operational variable. Quartz frequency follows a temperature curve. A camera body heating up over an hour of recording, a recorder in a sun-baked bag, a winter exterior at −5 °C — each moves the oscillator along that curve, and the drift rate changes through the day. This is why drift measured in the morning does not reliably predict the afternoon, and why the practical answer on temperature-extreme days is a shorter re-jam interval rather than cleverer arithmetic. TCXOs exist precisely to flatten this curve.
Power cycles. Many cameras keep timecode on a clock that does not survive a battery swap or an auto-power-save nap. The device comes back with its jam quietly gone — sometimes continuing from a stale internal clock, offset by however long it was dark. A jam is not a setting; it is volatile state, and it dies more easily than most menus admit.
Aging. Crystals slowly change frequency over months and years. It matters far less than temperature on any given day, but it is why a sync box’s calibration — and a camera’s TC accuracy — are not lifetime constants.
Measuring it: the head/tail method, one division
Diagnosis takes two measurements and a division, done on any long take (an interview is ideal):
- Head: align picture and sound on a transient near the start — a clap, a plosive, a door. Note the residual offset.
- Tail: find a transient near the end of the same take and measure the offset there.
- Divide the offset growth by the take’s duration. 40 ms grown over a 40-minute take is 40 / 2,400,000 ≈ 17 ppm: oscillator drift, a middling camera clock doing what middling camera clocks do. 2,400 ms over the same take is exactly 0.1%: a pulldown mismatch, not drift — different cause, different fix.
Then look across takes: plot each clip’s sync offset against its time of day. A straight line through the jam time confirms free-running drift and even tells you the combined ppm of the pair. A flat line at a constant offset is a bad jam. A step change mid-day is a power cycle or an unlogged re-jam — and the takes before and after the step need different corrections.
The fixes on set
Re-jam on a cadence, not on faith. Every 4–6 hours as a baseline — in practice: at call, at lunch, and once mid-afternoon. Halve the interval in temperature extremes. Always re-jam after any battery swap or power cycle, because some devices lose the jam silently. The LTC guide covers what jamming actually does at the signal level.
Put the good clock on every device. A TCXO-equipped sync box per camera and recorder, all jammed from one master, turns the whole day into sub-frame territory — the boxes hold each other to under half a frame per day, and re-jamming becomes belt-and-braces rather than life support. Feeding LTC continuously into an audio track goes one step further: the timecode is then recorded evidence in the file, immune to what the camera’s internal clock does afterwards.
Log the master. When two devices disagree in post, someone has to decide which clock was right. A one-line note — “jammed all from recorder, 07:40, 13:05, 16:30” — settles in seconds what waveform archaeology settles in hours.
The fixes in post
Drift that already made it into the rushes is repairable, because it is systematic:
- Per-clip offset, not per-day offset. The core adjustment is a slip: each clip pair gets its own measured offset. Timecode gets you to the nearest frame; the residual — both the sub-frame remainder and the accumulated drift — is best found by waveform matching per clip rather than by trusting one morning measurement all day.
- Premiere Pro: sync by timecode first, then refine per clip — select the video and audio clips and use Synchronize with Audio as the criterion, or slip the audio manually against a transient. Avoid applying one global track offset to a whole day’s material; the 4 p.m. clips will thank you.
- DaVinci Resolve: Auto Sync Audio based on waveform handles the per-clip residual; for multicam, fix any suspect clips before building the multicam clip, since the angle sync assumes offsets are stable — the Resolve multicam guide covers refining angles the automatic pass got wrong.
- Within-take drift. At sane ppm levels a take has to be long before drift inside it exceeds a frame — roughly 90 minutes at 17 ppm. For very long takes (ceremonies, conferences), measure head and tail, and apply the tiny constant speed correction the division gives you, once, rather than chopping the take into re-synced chunks.
Fail modes that keep drift alive
- “We jammed at call.” The single most common cause of afternoon drift is a morning jam trusted for ten hours. The jam was fine; the plan was not.
- The invisible power cycle. Auto-power-save on mirrorless bodies quietly resets the TC clock; the operator never saw the camera turn off. If a device can nap, assume its jam is gone when it wakes.
- Drop-frame confusion masquerading as drift. At 29.97 fps, a DF/NDF mixup grows at 3.6 seconds per hour — three orders of magnitude faster than crystal drift, and diagnosable from the semicolon in the timecode display.
- The mismatch mistaken for drift. Anything measuring near 1,000 ppm is a frame rate or sample rate mismatch. Re-jamming will not fix it, and speed-conforming will not fix genuine drift — the division decides which problem you have.
- One box left off the jam round. The B-camera that was swapping cards at 13:05 misses the lunch re-jam and spends the afternoon on its morning clock. Cadence only works if it covers every device, every round.
Where Launchr Post fits
Launchr Post syncs a shoot day by timecode first, then refines every clip pair against the audio waveforms — which is exactly the per-clip correction drift demands. Because each clip’s measured offset is recorded in the sync report, a day’s drift is visible as the straight line it is: you can see which device walked, how fast, and when the re-jams happened, instead of discovering it one bad take at a time. Everything runs locally on your Mac, and the original files are never touched.
See your drift before you cut
Drop a shoot day into Launchr Post and read the sync report: per-clip offsets, sync confidence, and drift called out by name. It syncs, sorts and transcribes — then hands your editor the whole package.