DF/NDF Subtitle Timecode Converter

Why drop-frame exists (the short version)

NTSC color video doesn't run at an even 30 frames per second — it runs at 30000/1001 ≈ 29.97 fps. If you label every frame with a plain 30-per-second counter (non-drop timecode, NDF), the label falls behind real elapsed time by 0.1%: after an hour of real time, NDF timecode reads 3.6 seconds short of the wall clock. Drop-frame timecode (DF) corrects this without touching a single frame of picture — it renumbers, it doesn't delete. DF skips frame labels ;00 and ;01 at the start of every minute except each tenth minute (00, 10, 20, 30, 40, 50), removing 108 labels per hour and holding DF within about 3.6 milliseconds of the wall clock — roughly a thousand times tighter than NDF. At 59.94 fps the same 0.1% slowdown applies, but each second nominally holds 60 labels instead of 30, so the skip doubles: DF at 59.94 drops ;00, ;01, ;02 and ;03 in every non-tenth minute, 216 labels per hour.

Where this actually wrecks subtitle timing

A subtitle file (SRT, VTT, or a caption track authored inside an NLE) carries timecodes or millisecond offsets that assume one counting scheme. If that file gets conformed against a master timed with the other scheme, every cue is technically "correct" against its own numbers and subtly wrong against the picture. Because the two schemes only diverge by 0.1% of elapsed time, the error doesn't show up as an obvious jump cut — it creeps in at roughly 2 frames of drift per minute of program, so a 10-minute segment can end up nearly half a second out, and a full-length program can drift a couple of seconds by the credits. Early in the show it's invisible; by the third act, dialogue and text have visibly separated. This is exactly the kind of error that survives an in-house spot-check and gets caught (or missed) at delivery QC — the fix is knowing which scheme your source uses before you retime against a new master, not after a client flags drifting captions.

Spotting which scheme a file or master uses

The most reliable tell is the separator: drop-frame timecode is written with a semicolon before the frame field (01:00:00;00), non-drop with a colon (01:00:00:00). If a vendor delivery note, EDL, or burned-in timecode window uses semicolons, treat it as DF. Absent that, check the NLE sequence settings — Premiere, Resolve and Avid all expose a drop-frame toggle on the timeline's frame-rate setting, and it's usually set to match house delivery standard (DF for NTSC broadcast masters, NDF for web/short-form). When in doubt, convert both ways and compare the result against a known reference point in the program (a slate, a burn-in, or a black frame with printed timecode).

Worked example: converting an hour mark

Take 01:00:00:00 NDF at 29.97 fps. First, convert the label to an absolute frame position: (1×3600 + 0×60 + 0) × 30 + 0 = 108,000 frames. That position falls after 6 complete ten-minute DF blocks — 6 × 17,982 valid DF labels = 107,892 — leaving 108 labels into the 7th block. Because that block's first minute (minute 00, divisible by ten) isn't a drop minute, those 108 labels count straight through at 30 labels per second: 108 ÷ 30 = 3 seconds, remainder 18 frames. Result: 01:00:03;18 DF — the same real frame, a different label, now 3 seconds and 18 frames "ahead" in its own numbering because it has skipped 108 non-existent labels to get there.

Why SRT files mostly dodge this — until they don't

SRT and WebVTT store cue times in hours:minutes:seconds,milliseconds, not frame-accurate SMPTE timecode — there's no DF/NDF ambiguity in the file itself, because milliseconds don't drop labels. The problem only appears the moment those millisecond cues get conformed to a frame-accurate timeline: an editor pulling SRT cues into a DF-timed broadcast master, or a QC pass that converts millisecond timestamps to SMPTE timecode for a delivery spec, has to pick a scheme — and picking wrong reintroduces the same creeping drift a frame-based file would have shipped with from the start.

NDF's drift ratio is identical at both rates because it comes purely from the 1000/1001 slowdown, independent of how many nominal labels a second holds.

1. Paste one timecode or a whole list, one per line.

2. Declare whether the list is currently labeled DF or NDF, and choose 29.97 or 59.94 fps - invalid drop-frame labels are rejected line by line.

3. Copy the relabeled timecodes with their drift annotations, then check cue spacing with the Subtitle 2-Frame Gap Calculator.