Timecode is how video professionals name a moment — hours:minutes:seconds:frames, written 01:24:12:07 — and frame rate is how many of those frames pass each second. This is the review-side version of that fundamentals topic: what the numbers mean, why "29.97" has a semicolon version, and the practical question reviewers actually hit — why the timecode your editor quotes and the time your client's review link shows don't always match.
Reading SMPTE timecode
The format is HH:MM:SS:FF — the last number counts frames within the second, so at 24 fps the counter runs 00–23 and resets. The separators carry meaning: colons (01;24;12;07 uses semicolons instead) mark drop-frame timecode, colons mark non-drop. Drop-frame exists because color television's 29.97 fps is really 30 frames minus a bit, and plain 30-frame counting drifts 3.6 seconds behind wall clock every hour; drop-frame timecode periodically skips frame numbers (never actual frames) so the count keeps pace with the clock. It's formally defined only at 29.97 and 59.94. At 23.976 fps there is no drop-frame option — the timecode simply counts 24 numbers per second and runs slowly against wall clock, which is normal and expected.
Common frame rates and where they come from
| Rate | Where you meet it | Review-round note |
|---|---|---|
| 23.976 / 24 | Film look, streaming, cinema | "23.98" is the same rate; TC runs slow vs wall clock by design |
| 25 | PAL regions, European broadcast | 24 fps content played at 25 runs ~4% fast (the old "PAL speed-up") — audible pitch shift on music |
| 29.97 (DF/NDF) | NTSC broadcast | DF for broadcast deliverables; NDF drifts 3.6 s/hr — quote TC the way the spec says |
| 30 | Web, screen recordings | No drift; simple counting |
| 50 / 60 | Sports, live, smooth-motion work | Timestamp precision doubles — great for fast-action notes |
Why your NLE timecode and the review link disagree
Three ordinary reasons, none of them a bug:
- Different displays: many review players show MM:SS or MM:SS.mmm by default, not SMPTE frames — your editor quotes 01:24:12:07, the client's player says 1:24. Both are "correct"; the round just needs one convention. If exact frames matter (graphics, lip-sync), burn a visible timecode into the review export — the recipes are the Premiere burn-in and FCP burn-in tips.
- Review exports are re-encoded and sometimes trimmed: a slate removed for the review file shifts every downstream time by the slate's length; a variable-frame-rate screen recording can drift seconds by the end. Match by content ("the moment the door closes"), not by absolute number, when the export isn't a straight re-render.
- Proxies and rate conversions: if the review file was conformed from proxies or retimed (the proxy workflow explains the playback side), timestamps can shift by a frame or two at cut points — frame-stepping on the review page settles it.
The round-rule that prevents the whole argument: one time convention per project, stated in the kickoff (SMPTE from the timeline, or player MM:SS), and burned-in timecode whenever frame precision is the deliverable — this is the same discipline as the timestamped vs frame-accurate distinction, and the glossary siblings (frame-accurate review, full glossary) carry the neighboring definitions.
FAQ
What does timecode like 01:24:12:07 mean?
Hours:minutes:seconds:frames — one hour, twenty-four minutes, twelve seconds, and the seventh frame of that second. The frame count resets at the project's frame rate, so the same string means a slightly different instant at 24 vs 60 fps.
What's the difference between drop-frame and non-drop timecode?
Drop-frame periodically skips frame numbers (never frames) so the count matches wall clock at 29.97 fps, where plain counting drifts 3.6 seconds per hour; non-drop lets it drift. Colons vs semicolons in the timecode string tell you which you're looking at.
Why does 23.976 fps timecode not match the clock?
Because 23.976 is really 24 frames minus a bit for NTSC compatibility, and there's no drop-frame mechanism defined at that rate — the timecode just counts 24 numbers per second and runs slow against wall clock. It's expected behavior, not an error.
Should reviewers quote player time or timecode?
Whichever convention the project picked, stated once at kickoff. Default: the player's own timestamp is fine for story notes; burn visible timecode into the review export when frame precision matters, so every note lands on a number both sides can see.