Timecode, frame rate, and caption sync

Your cues look perfect in the NLE — then on YouTube the last line finishes early, or on a web player every third cue hiccups. Often the root cause is not the words; it is a mismatch between the timeline you authored against and the timeline the published video actually uses.

Drop-frame vs non-drop NTSC

At 23.976 / 29.97 / 59.94 fractional rates, broadcast timecode uses drop-frame (DF) notation to keep clock time aligned with wall clocks over long programs. If your captions were authored as non-drop (NDF) but the program is treated as DF downstream (or vice versa), cumulative drift shows up late in the file — not on cue one.

XML and TTML timing

TTML and some broadcast exports embed a frame rate or tick rate inside the document. If that metadata does not match the rendered video frame rate, players map media milliseconds incorrectly. See TTML and DFXP for when XML timing metadata matters more than a simple SRT block list.

Export checklist before upload

• Confirm sequence frame rate matches the file you will upload (re-wrap vs transcode).
• Re-export captions after a conform pass that changes duration or adds handles at head/tail.
• Avoid mixing time-of-day timecode with program-relative cues unless the receiver expects it.
• If a host re-encodes to a constant frame rate, re-verify first and last cues after processing.

Reading speed still matters

Drift is one failure mode; another is correct timestamps with unreadable density. Pair this note with reading speed and line length so you are not chasing a frame-rate bug when the issue is CPS.

Run timing diagnostics through CaptionPass to catch overlapping cues and impossible durations before they become player glitches.