Timecode Conversion: Frames, Seconds, and SMPTE
The same moment is 61.5 seconds in a subtitle tool, 00:01:01:12 in an editor, and frame 1537 in a render script. Get the conversion wrong by half a frame and everyone sees it.
Three ways to write one timestamp
Seconds are the universal language: one decimal number every tool accepts, and what SRT/VTT subtitle files actually store. SMPTE timecode is HH:MM:SS:FF - the last field counts frames - used by cameras and editors because it is frame-exact. Frame numbers are a plain integer counted from frame 0, favored by scripts and render queues.
Frame rate is the conversion hinge: frames divided by frame rate gives seconds; the fractional seconds times frame rate gives the frame field. SMPTE expands its first three fields at base 60 into seconds, then handles frames.
The 29.97 drop-frame story
When color TV arrived, the 30 fps line scan of black-and-white broadcasts interfered with the color signal, so engineers slowed the rate to 30/1.001, about 29.97. Side effect: counting HH:MM:SS:FF at 29.97 drifts behind real time by roughly 1.8 frames per minute - about 108 frames per hour.
Drop-frame timecode compensates by skipping numbers - frames 00 and 01 are skipped each minute (except every tenth minute). Only the labels are skipped, never actual frames. So 00:01:00:00 is not 60 seconds in non-drop timecode but essentially is in drop-frame. Mixing the two schemes on a long film guarantees sync errors.
Where conversions bite in practice
Subtitle timing: SRT stores seconds. Round-tripping through an editor running at 25 fps accumulates rounding drift, and long subtitles visibly slide by half a frame. Keep seconds as the intermediate format end to end; convert to SMPTE only for final frame checks.
Pasting timecode across apps: one tool may run 29.97 DF and the other 29.97 NDF - identical-looking strings, different moments. Confirm the source frame rate and DF/NDF property before converting; a codec inspection tool reports both.