Multicam Sync Offset Calculator

Why two cameras never agree on timecode

Timecode only means the same thing on two cameras if it was set the same way. In practice it almost never is. Cameras running free-run timecode keep counting from whatever value they were jammed to, even when the camera is off — cameras running rec-run only advance timecode while actively recording, so the counter falls behind real time every time the operator stops and starts. Even two free-run cameras jammed from the same master clock at the start of the day will drift apart by a few frames over several hours unless they're re-jammed, because internal clocks are never perfectly matched. And plenty of cameras — consumer bodies, action cams, phones used as B-cam — have no timecode input at all and simply start counting from 00:00:00:00 the moment you hit record. None of that is a problem as long as you know the relationship between the cameras' clocks at one shared instant. That's what this calculator solves.

The clap, slate or flash: a shared instant in two clocks

A clapperboard, a camera flash, or any sharp audio/visual cue that every camera captures at the same real-world moment gives you a common reference point. Read each camera's timecode at that exact frame — the clap closing, the flash's first bright frame — and you have two labels that both describe the same instant. The difference between those two labels, converted correctly, is the offset: a fixed number of frames you can add to any timecode from Camera A to get the matching timecode on Camera B, for as long as neither camera's clock drifts (which, over the length of a single roll, it essentially doesn't).

Worked example

At 25 fps, Camera A reads 01:00:10:00 at the clap and Camera B reads 14:23:05:12 at the same clap. Converting each to an absolute frame count: A = (1×3600 + 0×60 + 10) × 25 = 90,250 frames. B = (14×3600 + 23×60 + 5) × 25 + 12 = 1,294,637 frames. The offset is B − A = 1,204,387 frames, which converts back to +13:22:55:12 — Camera B is running just over 13 hours, 22 minutes ahead of Camera A's clock, which is exactly what you'd expect from two cameras jammed to their own internal clocks on different days. To find what Camera B read when Camera A showed 01:05:00:00: convert to frames (97,500), add the offset (1,301,887), convert back — 14:27:55:12. That's the whole method; everything else on this page is that same arithmetic run automatically.

Why drop-frame needs frame counts, not digit subtraction

When either camera is running 29.97 or 59.94 drop-frame, you cannot subtract the printed digits field by field — DF labels skip numbers, so two labels that look four frames apart on paper can be only two real frames apart. Example: 00:00:59;28 and 00:01:00;02 are consecutive-minute DF labels. Naive digit subtraction (treating ;FF like an ordinary base-30 counter and borrowing across the semicolon) says 4 frames elapsed. But ;00 and ;01 don't exist in that minute — the real sequence is ;28 → ;29 → ;02, which is 2 frames, not 4. The fix is the standard SMPTE drop-frame algorithm: convert every DF label to an absolute frame index using the 17,982-frames-per-10-minutes / 1,798-frames-per-dropped-minute constants (doubled to 35,964 and 3,596 at 59.94), do the arithmetic on those integers, then relabel. This calculator always routes offset and query math through absolute frame counts for exactly that reason — it's the only way DF math comes out right.

Where this fits in your NLE

Premiere Pro's Synchronize clip command and Resolve's "Sync using Timecode" both assume every clip's timecode already agrees, and when it doesn't, they silently misalign or refuse. Compute the offset here first, then either use the NLE's offset field (Premiere lets you type a manual offset on import; Resolve's Change Clip Offset does the same) or manually shift one camera's TC track to match. When there's no usable timecode at all — a phone B-cam, a GoPro, a run-and-gun setup — the fallback is audio-waveform sync (PluralEyes-style, or the NLE's built-in audio sync), which lines up clips by their soundtracks instead of their labels; it works without any TC agreement but needs a shared, distinct audio event on every source.

Overnight shoots and the midnight wrap

A query result that lands before 00:00:00:00 or past 23:59:59 on a 24-hour clock wraps around modulo 24 hours — normal behavior for time-of-day timecode on an overnight shoot — but this calculator always flags it with an explicit "crossed midnight" badge rather than wrapping silently, because a silent wrap looks identical to a plain calculation error and will send you hunting for a bug that isn't there.

1. Find one moment both cameras caught — a clap, slate or flash — and note the timecode each camera shows on that frame.

2. Enter both timecodes and the frame rate to get the signed offset, in frames and as a timecode.

3. Use the built-in converter to translate any A-camera timecode to B-camera, or do longer timecode math in the Timecode Calculator.