How this instrument works
Video and film are stored as a running count of individual frames, but nobody reads a timeline in raw frame numbers — the industry-standard SMPTE timecode format breaks that count into hours, minutes, seconds and frames (HH:MM:SS:FF), matching how a clock face reads. Converting between the two means repeatedly dividing the frame count by the frame rate, in whole-number chunks: how many whole hours' worth of frames fit, then how many whole minutes' worth of what's left, and so on down to the frames remaining.
The final FF field is the trickiest part to reason about by hand, because it isn't a fraction of a second — it's a count of individual frames, and it always resets to zero at the frame rate itself. At 30 fps, frame 29 is the last frame of a second and frame 30 rolls over into the next second as 00; at 24 fps, film rate, that rollover happens at frame 23 instead. Get the frame rate wrong and every downstream timecode is wrong too, even though the underlying frame count never changed.
This conversion runs constantly behind the scenes in video editing — every marker, in-point, out-point and rendered frame count an NLE reports gets translated to and from timecode using exactly this floor-division chain, defined by the SMPTE 12M timecode standard.
- Enter Total frame count — the raw frame number from your NLE, script, or a frame-accurate log.
- Enter Frame rate (fps) — match the project's actual rate: 24 for film, 25 for PAL, 29.97 or 30 for NTSC-family video.
- Read Hours (HH), Minutes (MM), Seconds (SS) and Frames (FF) together as a single HH:MM:SS:FF timecode.
- Double-check the frame rate before trusting the result — the same frame count decodes to a different timecode at 24 fps than it does at 30 fps.
Worked example — frame 2,715 at 30 fps
Enter 2715 for total frame count and 30 for frame rate — perhaps a marker your NLE reports simply as 'frame 2715' on a 30 fps timeline. Dividing by fps x 3600 = 108,000 gives zero whole hours, so Hours reads 0.
The remaining 2,715 frames divide by fps x 60 = 1,800 to give 1 whole minute, leaving 915 frames; those divide by 30 to give 30 whole seconds, leaving a final 15 frames. Reading the four outputs together, Hours, Minutes, Seconds and Frames give the timecode 00:01:30:15 — exactly 1 minute, 30 seconds and 15 frames into the timeline.
Questions
How do I convert a frame count to timecode?
Divide repeatedly by the frame rate: whole hours come from dividing the total frame count by fps x 3600, then the remaining frames divide by fps x 60 for whole minutes, and so on down to seconds and the frames left over. 2,715 frames at 30 fps works out to 00:01:30:15 by that same chain.
Why does the same frame count give a different timecode at different rates?
Because timecode counts frames per second, and a 'second' contains a different number of frames depending on the rate. Frame 2,715 lands at 00:01:30:15 on a 30 fps timeline but decodes to a different HH:MM:SS:FF entirely at 24 fps or 25 fps, because each second absorbs fewer or more frames before rolling over.
What does the FF field actually mean?
FF is a count of individual frames within the current second, not a fraction of a second or a decimal. It always runs from 0 up to one less than the frame rate — 0 through 29 at 30 fps, 0 through 23 at 24 fps — then resets to 00 as the seconds field increments.
Why would I ever need to convert frames to timecode by hand?
Some tools, scripts and render logs report positions as a raw frame number rather than a timecode, especially frame-accurate compositing and VFX pipelines. Converting that number back into HH:MM:SS:FF makes it possible to find the same point on a timeline in an NLE, which almost always displays and searches by timecode instead of frame count.
Is this the same as SMPTE timecode?
Yes. The HH:MM:SS:FF format and the floor-division method used to reach it are defined by the SMPTE 12M timecode standard, the same convention used across professional video editing, broadcast and post-production, regardless of which software or hardware is doing the counting.