SMPTE timecode in, SMPTE timecode out - frame-accurate math at every delivery rate, mixed freely with plain durations.
Timecode math is base-60 with a frame twist: frames roll over at the frame rate, not at 60. One wrong carry and your EDL is off. TCalc parses HH:MM:SS:FF natively - write the frame rate as a suffix (f24, f25, f29.97, f59.94) and every operation stays frame-accurate.
The Film layout below has timecode keys ready; results format back as SMPTE, or as plain time when that reads better.
A timecode reads HH:MM:SS:FF, and the frame field is the part that breaks ordinary calculators. At 24 fps the frame counter runs 00 to 23 and then rolls the second; at 25 fps it runs to 24; at 30 fps it runs to 29. Adding 15 frames to 01:00:00:20 gives 01:00:01:11 at 24 fps but 01:00:01:05 at 30 fps. The same expression has different answers depending on a project setting, which is exactly why doing it in your head at 2am produces conform errors.
Write the frame rate into the value and the ambiguity disappears. A suffix such as f24 or f30 pins the rate for that term, so mixed-rate arithmetic stays honest instead of silently assuming the project default.
Mixing timecode with plain durations while keeping frame precision.
90 frames at 24 fps is three and three-quarter seconds, not 0.9 of anything.
Backing a five-second slate off a running timecode.
Deliverable specs are written in mixed units. A broadcaster will ask for a programme of 44:30 with a five-second slate, bars and tone at a fixed duration, and a hard out. Building that timeline means adding durations expressed in minutes and seconds to durations expressed in frames, then reading the result back as a timecode so it can be typed into the deliverable sheet.
The reverse question - how many frames is this - comes up whenever you hand work to VFX or conform. Frame counts are the lingua franca there, and the conversion depends on the rate, so it pays to state it explicitly rather than assume.
Programme duration expressed as a frame count at 24 fps for a VFX handover.
A typical feature length in frames at 24 fps.
Programme start at the one-hour mark, plus runtime, plus slate.
The most expensive mistakes in an edit suite are unit mistakes, not arithmetic mistakes. A duration copied from a 25 fps timeline into a 24 fps sequence looks correct to the eye and is wrong by one frame per second - four seconds of drift across a feature. Because a bare timecode carries no rate, it cannot warn you.
Keeping the rate attached to each value means a mixed-rate expression either resolves correctly or is visibly mixed, and the output format selector then lets you read the same underlying result as 24 fps timecode, 30 fps timecode, a raw frame count or plain hours and minutes without recomputing anything.
Add a clip to a sequence - carry across seconds, minutes, and the hour.
Runtime between two program marks.
Exactly one frame at 30 fps - the borrow is correct.
Split two hours of footage into three equal review blocks.
Add field by field from the right, carrying frames at the frame rate and seconds/minutes at 60. At 24 fps, 00:59:30:00 + 00:01:15:12 = 01:00:45:12. In TCalc you type both values with an f24 suffix and the carry is handled.
Any rate you spell out: f23.976, f24, f25, f29.97, f30, f50, f59.94, f60 and more, plus a configurable default so a bare HH:MM:SS:FF follows your project. The NTSC rates are handled as the exact rationals 24000/1001 and 30000/1001. Drop-frame and pull-down live on the dedicated timecode calculator.
Yes - timecode is a duration under the hood. Add a 90-minute runtime to a timecode and format the result back as SMPTE at your frame rate.