Timecode ↔ Wall-Clock Calculator

Time-of-day timecode, jam sync, and why the clock and the counter disagree

Most cameras can burn two very different kinds of timecode into their metadata: record-run timecode, which starts at zero (or an arbitrary offset) the moment you hit record on each clip, and time-of-day (TOD) timecode, which is set to track the actual clock — 09:14:32:11 means "9:14am and change," continuously, whether or not the camera is rolling. Multi-camera shoots, sports, live events, and any production syncing picture to a separate sound recorder almost always jam every camera and recorder to time-of-day timecode at the top of the day, because it turns "what time did that take happen" into a readable number instead of a lookup problem.

Jam sync is the act of setting a device's internal timecode generator to match a reference clock at a specific moment — typically 00:00:00:00 at midnight, or the current wall-clock time read off a master clock or timecode slate. From that instant forward, the device's TC generator free-runs on its own crystal, counting up in lockstep with the wall clock — in theory. In practice, at fractional frame rates, it doesn't stay in lockstep, and the size of the gap is entirely predictable.

Why 29.97 NDF drifts

Non-drop-frame (NDF) timecode at 29.97 fps still labels exactly 30 frames per counted second, but the video itself actually plays at 30000/1001 ≈ 29.97002997 frames per second — 0.1% slower than a true 30. That 0.1% (the ratio 30/29.97 = 1.001, or equivalently 1000/1001 the other way) means every "second" the NDF counter claims to have passed is actually 1.001 real seconds. The counter doesn't skip anything and never lies about frame count — it just labels real time slightly optimistically.

Worked example. Say a camera jammed to midnight rolls all day and its NDF timecode reads exactly 01:00:00:00 — one hour of labels. The real elapsed time since jam is:

3600 s (label-elapsed) × 1.001 = 3603.6 s

That's 1 hour, 0 minutes and 3.6 seconds of actual time, so the wall clock reads 01:00:03.6, not 01:00:00. The TC counter is 3.6 seconds behind the wall clock — it reads an earlier time than the clock actually shows at that instant. Run the same camera for a full 24-hour shoot day and the label-to-real gap compounds linearly: 24 × 3.6 s = 86.4 seconds — the timecode counter ends the day nearly a minute and a half behind real time. On a continuity log built off burned-in TC, that's enough to make "matches call sheet time" checks fail by the afternoon.

This tool always computes the conversion the correct way — real elapsed seconds = label-elapsed seconds × 1.001, going the other direction by dividing by 1.001 — never the rounded shortcut of multiplying or dividing by 0.999, because over a full shoot day that rounding error itself becomes visible.

Why drop-frame exists, and its residual

Drop-frame (DF) timecode fixes almost all of this by skipping frame numbers 00 and 01 at the start of every minute except each tenth minute (00, 10, 20, 30, 40, 50) — no video frames are discarded, only the numbers assigned to them. That renumbering removes 108 labels per hour, which is close enough to the 3.6-second/hour NDF drift that drop-frame timecode tracks the wall clock to within about 3.6 milliseconds per hour — roughly 86 milliseconds over a 24-hour day. For virtually every practical production purpose, drop-frame timecode is the wall clock; the residual only matters to broadcast engineers timing a program to the frame over very long durations.

Re-jamming at lunch

Even with the right scheme selected, timecode generators run on a physical crystal oscillator, and no two crystals — even in the same camera model — run at exactly the same rate. That crystal drift is separate from, and additive to, the 0.1% NDF/DF label math above, and it accumulates all day. That's why productions re-jam every camera and sound recorder to a master clock at lunch (and sometimes again before the last setup): it resets the crystal drift to zero without touching the label scheme, keeping multi-device sync tight for the rest of the day.

Drift by rate

Use the direction toggle above to go either way: enter a timecode reading to find the real wall-clock moment it corresponds to, or enter a wall-clock time to find what a jammed camera's counter should read at that instant. Integer rates (24, 25, 30) never drift — the tool says so explicitly rather than showing a silent 0.000.

1. Enter a time-of-day timecode, or a wall-clock time if you want the conversion the other way.

2. Set the frame rate and drop-frame or non-drop; the clock faces show what the counter claims next to the actual time.

3. Use the drift figure to decide when to re-jam, and see it over a full program on the DF vs NDF drift chart.