29.97 fps vs 30 fps

29.97 fps is not 30 fps rounded, and it is not a close-enough approximation. It is exactly 30000/1001 frames per second — a deliberate, tiny rate change with a specific engineering cause, and a specific, measurable cost in drift against real time. Here is the exact arithmetic, where the ratio came from, and a converter for working with both.

Frame rate

Timecode

Frame number

Timecode A

Operation

Frame count

The short answer

	30 fps	29.97 fps
Exact value	30/1 (exactly 30)	30000/1001
As a decimal	30.000000…	29.970029970…
Frames per real hour	108,000	107,892
Has a drop-frame variant	No	Yes

The two rates differ by a factor of exactly 1000/1001, about 0.1%. That sounds negligible, and for a single frame it is — the difference between one 30 fps frame and one 29.97 fps frame is roughly 33 microseconds. Over an hour it is 3.6 seconds, which is where it starts to matter for anything measuring duration or staying synchronised to a clock.

Where 29.97 came from

Black-and-white NTSC television, standardised in the United States in 1941, ran at a clean 30 frames per second, itself derived from the 60 Hz frequency of American mains power. When color was added in 1953, engineers needed to fit a new color subcarrier signal into the existing broadcast channel without it beating against, and visibly interfering with, the sound carrier frequency that was already fixed relative to the original 30 fps frame rate.

The solution adopted was to slow the whole signal down by a factor of exactly 1000/1001. That single, small adjustment moved the frame rate from a clean 30 to 30000/1001 ≈ 29.97 fps, and moved the color subcarrier frequency to a value that no longer produced visible interference with the sound carrier. It was a pragmatic fix for 1950s broadcast hardware, not a rate anyone would have chosen from first principles — and because so much equipment, standards, and archived material were built around it in the decades since, it persisted long after the analog broadcast chain that made it necessary was replaced by digital transmission. The same 1000/1001 factor applied to a 60 fps nominal rate gives 59.94 fps, used for high-frame-rate NTSC-family formats.

It is worth being precise about what did and did not change. The picture itself — resolution, scan pattern, the black-and-white portion of the signal — was untouched. What moved was the timing of the whole frame cadence, by one part in a thousand, so that the newly added color information could share the channel without visible beat-frequency artifacts against the sound carrier. Existing black-and-white receivers kept working exactly as before because a one-part-in-a-thousand change to the frame rate is not something the human eye or a 1950s receiver's circuitry would register as a fault. That is the whole engineering trade: an imperceptible timing shift in exchange for compatible color broadcast on the existing infrastructure — and the timecode arithmetic on this page is the permanent, exactly-quantifiable receipt for that decision, seventy years later.

For the fuller technical history, see the NTSC article on Wikipedia, which covers the color-subcarrier engineering in more detail, and the SMPTE timecode article for how drop-frame timecode was subsequently defined to correct for it.

The drift, worked out

Take one real hour — 3,600 seconds. At the true rate of 30000/1001 frames per second, that is:

3600 × 30000/1001 = 108,000,000/1001 ≈ 107,892.11 frames

A non-drop-frame clock counting nominal 30 fps only ever produces whole numbers of frames per whole number of seconds, so after exactly 107,892 real frames the non-drop-frame label reads:

107,892 frames ÷ 30 = 3,596.4 nominal seconds = 00:59:56:12

Compare that to the 3,600 real seconds that actually elapsed: the clock reads 3.6 seconds behind real time. That 3.6-second figure is exactly the one-part-in-a-thousand ratio applied to one hour: 3600 × (1 − 1000/1001) = 3600/1001 ≈ 3.5964 seconds, which rounds to the commonly quoted 3.6.

Drop-frame timecode corrects this by skipping frame numbers at the rate derived in the drop-frame guide, so that the same 107,892 real frames read as 01:00:00;00 instead of 00:59:56;12 — within a fraction of a frame of the true elapsed hour, rather than 108 frames (3.6 seconds) adrift.

Where this causes real bugs

The 0.1% difference is small enough that it is routinely ignored right up until a calculation depends on it, at which point the failure is usually silent rather than an error message:

Duration math done as frameCount / 30. Perfectly correct for true 30 fps material, quietly wrong by 0.1% for anything actually at 29.97 — the computed duration reads shorter than the real playback time, by 3.6 seconds per hour of material.
Scheduling a broadcast slot against timecode. A one-hour programme block built from non-drop-frame 29.97 timecode that assumes the clock tracks a real wall clock will finish 3.6 seconds later than the schedule expects — small on its own, but it compounds across a full broadcast day of consecutive programmes.
Camera or NLE metadata reporting the wrong rate. Some cameras label their true 29.97 capture as “30 fps” in file metadata for simplicity, which is harmless for playback but produces a wrong answer the moment another tool trusts that label for a real-time calculation instead of reading the frame data directly.
Mixing 29.97 and true 30 fps clips on one timeline without a plan. Both nominally count “30 frames per second”, so an editing system that is not explicit about which is which can conform the wrong one, producing a program that is very slightly the wrong length without any single frame looking obviously broken.

Why the fraction matters in code, not just on paper

Storing 29.97 as the literal floating-point number 29.97 introduces a second, unrelated source of error on top of the real one: 29.97 cannot be represented exactly in binary floating point, so a program that multiplies by it accumulates tiny rounding errors on every calculation, distinct from the genuine NTSC drift being discussed here. Representing the rate as the exact integer fraction 30000/1001 instead avoids that second error completely — every calculation in this tool uses the fraction, and divides only at the point where a real-world number of seconds is displayed, which is exactly where the tool’s cross-checked reference values (see how the arithmetic was verified) came from matching to the fraction of a millisecond rather than drifting further with every added hour.

Which one applies to your footage

Cinema and most narrative streaming delivery commonly use 24 fps, or 23.976 (24/1.001) when the content needs to sit comfortably on NTSC-legacy equipment or alongside 29.97 material.
Broadcast television in NTSC-legacy territories (North America, Japan, parts of Latin America) commonly uses 29.97, with drop-frame required for many delivery specifications specifically because of the drift problem above.
PAL/SECAM-legacy territories (much of Europe, Africa, Asia, Australia) use the exact integer 25 fps, which has no fractional drift and therefore no drop-frame concept at all.
Web-first and streaming-native video increasingly defaults to a clean 30 or 60 fps, sidestepping the NTSC legacy rates entirely where no broadcast delivery requirement forces the issue.

If you are not sure which your footage actually is, check the project or sequence settings rather than guessing from the separator alone — see the drop-frame guide's FAQ for why the semicolon-versus-colon convention is a useful hint but not a guarantee.

Worked examples

1. The exact decimal value

30000 ÷ 1001 = 29.970029970029970…, repeating. It is never exactly 29.97 as written — that decimal is a convenient rounding, and every calculation in this tool uses the exact fraction 30000/1001 rather than the rounded 29.97, which is why the results above match published references to the fraction of a frame.

2. One hour at both rates, compared directly

Select 30 fps above and enter 01:00:00:00: frame 108,000. Switch to 29.97 fps NDF and enter the same timecode: also frame 108,000 — the nominal arithmetic is identical for NDF at both rates. The difference only appears on the Timecode ↔ Real Time tab: at true 30 fps, 108,000 frames is exactly 3,600.000 real seconds; at true 29.97, the same 108,000 frames is 3,603.6 real seconds — the material actually took 3.6 seconds longer to play than a plain-30 clock would suggest.

3. 59.94, the high-frame-rate sibling

Select 59.94 fps DF and enter 01:00:00;00: frame 215,784. The same 1000/1001 ratio applies at double the nominal rate, so the drop count doubles too — four frame numbers per non-exempt minute instead of two — to correct for a drift that is, per frame, identical to the 29.97 case.

4. Reinterpreting frame 108,000 at the true 29.97 rate

On the Rate Conversion tab, set From to 30 fps and To to 29.97 fps NDF, and enter 01:00:00:00. The reinterpreted timecode is identical — 01:00:00:00 — because the nominal frame-counting arithmetic is the same integer division at both rates. What differs, shown alongside it, is the real elapsed time each rate actually represents for that same frame count: exactly one hour at 30 fps, 3,603.6 seconds at 29.97.

5. A 30-minute broadcast slot

A programme delivered to fill exactly a 30-minute broadcast slot, with a common convention of holding the actual content to 00:28:30:00 or thereabouts to leave room for local station breaks. Enter that on the Timecode ↔ Frame tab at 29.97 fps NDF: frame 51,300. Now check the Timecode ↔ Real Time tab: the literal reading of 28 minutes 30 seconds is extremely close to the true elapsed time, because the drift at this length (well under a minute of nominal timecode) is a small fraction of a second — not yet the kind of error that matters for a single programme, but exactly the error that becomes visible once dozens of such programmes run back to back across a broadcast day.

6. A duration that quietly assumes the wrong rate

On the Arithmetic tab at 29.97 fps NDF, choose Duration between two and enter 00:00:00:00 and 01:00:00:00. The duration in frames is 108,000, correctly. But if that duration is then treated as “one real hour” by a script or spreadsheet that assumes 30 fps exactly, it is wrong by 3.6 seconds — a small error that compounds across many such durations in a long-form schedule or a batch delivery report.

Frequently asked questions

Is 29.97 fps just 30 fps rounded down?

No — it is an exact ratio, 30000/1001, not an approximation or a rounding of 30. Written as a decimal it is 29.970029970029970… repeating, which is why every serious tool represents it as the fraction 30000/1001 internally rather than as the rounded decimal 29.97.

Why isn't 29.97 fps just written as 30/1.001?

It is the same value; 30/1.001 and 30000/1001 are algebraically identical. 30000/1001 is preferred in technical contexts because both numerator and denominator are integers, which avoids floating-point rounding error entirely — dividing two exact integers on a computer is exact, whereas 1.001 cannot be represented exactly in binary floating point.

Does the 1000/1001 ratio affect audio sample rates too?

It can, in specific pulldown and conform scenarios where audio must stay locked to a video track that was slowed by the 1000/1001 factor — audio for material transferred from 24 fps film to 23.976 fps video, for instance, is sometimes pulled down by the same ratio to stay in sync. It has nothing to do with color subcarrier engineering directly; it is a downstream consequence of keeping audio and picture at the same relative speed.

If I export a 30 fps timeline at 29.97, will it look different?

Not to the eye over a short clip — the frame rates differ by about one part in a thousand, well below what a viewer perceives directly. What changes is duration and sync over length: a timeline built and timed against one rate but rendered at the other will run very slightly long or short, and anything keyed to a real-time clock (captions, live graphics, broadcast automation) can drift measurably over a long programme.

Does 59.94 fps have the same origin as 29.97?

Yes — 59.94 is exactly 60000/1001, the same 1000/1001 ratio applied to a 60 fps nominal rate, used for high-frame-rate NTSC-family formats. It carries the identical drift problem and the identical drop-frame fix, just with four frame numbers skipped per non-exempt minute instead of two.

More on timecode

See all the tools on this site →