Why One Frame Rate Needs a Counting Rate and a Display Base
A single frame-rate option carries two numbers here, but the two numbers do different jobs. One is the counting rate used to advance wall-clock time into frames and may be fractional; the other is the integer display base used for timecode-string and frame-count conversion.
Seeing 29.97 while timecode is grouped on a base of 30 does not mean two frame rates have been mixed together; the counting rate and display base are doing different work.
Why one frame-rate option keeps two numbers
For 29.97, the counting rate answers how many frames advance with wall-clock time, while the display base answers how those frames split into timecode fields. The former may be fractional because it sets pace, while the latter is an integer because it groups the frame field. Treating them as one number would confuse elapsed-time pacing with string numbering.
The same structure applies to 23.976: advancement uses the fractional counting rate, while string conversion uses an integer display base. At 24, 25, and 30, the two values are the same. The distinction is not which number is more “real,” but which calculation each performs.
How two mismatched numbers accumulate into a time difference
These fractional settings run the counting rate about one part in a thousand below the display base, so timecode numbering does not advance at the wall-clock pace. With 29.97 paired with 30, or 23.976 paired with 24, strings use the integer base while advancement uses the slower rate. The difference therefore accumulates continuously rather than appearing as an occasional missing label.
Under this scheme, timecode runs progressively slower than the wall clock, on the scale of seconds per hour. At that pace the drift is about 3.6 seconds per hour, and the same rate applied across 24 hours gives 86.4 seconds, roughly a minute and a half. That difference cannot be dismissed merely because the two rate numbers look close, because it is created by assigning them different jobs.
The important fact about a fractional setting is not that its decimal resembles an integer; the counting rate sets the pace, the display base sets the numbering structure, and the difference accumulates over time.
How a frame rate stored on a camera record is reduced to a base rate
When the frame rate stored on a camera record is an overcranked value above a base rate, the logic tries divisors in sequence and compares each result with the base rates. The first candidate inside a very small tolerance becomes the base rate; if none matches, the fallback is 24. The small tolerance lets elevated rates reduce to a base rate without merging neighboring normal settings.
For example, 24 and 23.976 differ by 0.024, so the tolerance must be smaller than that gap if 24 is to remain 24 rather than being absorbed into 23.976. Counting elevated frame rates by a base rate is a common industry practice, but it is not a claim that every receiving workflow must use that same treatment. The receiver should still verify the frame-rate label against the actual handoff and its own media records.
Why the live count is still NDF
In the live path for fractional settings, frame numbers advance continuously without skipping selected labels, so this is non-drop-frame counting, or NDF. NDF describes live numbering; it does not declare that delivery uses the same display rule end to end. “No skipped frame numbers” does not mean timecode catches the wall clock, because the accumulated difference remains.
The export side has a separate decision for drop-frame display, and that semicolon notation currently appears only in the ALE and CSV timecode columns (the daily-report PDF has no timecode column), so the live path and export display are not end-to-end consistent. That does not justify describing the app as having a drop-frame timecode capability spanning capture through delivery, and it does not justify describing timecode as synchronized to wall-clock time. For the meaning of a semicolon in a delivered value, refer to What a Semicolon in Timecode Actually Tells You rather than inferring export behavior from the live NDF count.
Why delivery still requires checking labels and separators
The frame-rate label states the rate claimed by a handoff row, while the separator reflects export-side display notation. Neither replaces source verification when the live and export rules are not unified. For an ALE value’s origin, Where Each ALE Column Comes From provides field-by-field context instead of relying on a familiar-looking timecode string.
The receiver should therefore verify the frame-rate label and timecode separator in the handoff and compare them with the on-set record and media information. The counting rate advances frames, the display base converts strings and frame counts, and the export side separately chooses display notation; those layers should not be substituted for one another. Once those layers are kept separate, seeing 29.97 and 30 in the same workflow is no longer two contradictory answers.
FAQ
Why can 30 appear when the rate is 29.97?
29.97 is the counting rate and 30 is the display base, so they are used for frame advancement and timecode-string grouping respectively. Their simultaneous presence is a division of calculation duties, not a temporary switch from one frame-rate setting to another.
Does 23.976 use the same two-number structure?
Yes, 23.976 advances with a fractional counting rate while timecode-string conversion uses an integer display base. The counting rate runs about one part in a thousand below the display base, so timecode falls progressively behind wall-clock time.
Does NDF in the live path mean the export is also written as NDF?
That conclusion does not follow. The live path uses NDF counting without skipped frame labels, while the export side has a separate drop-frame display decision, so the end-to-end conventions are not unified.
What should the receiver verify at the end?
The receiver should verify the frame-rate label and timecode separator in the handoff against the on-set record and media information. A single rate number or separator is not enough to treat the entire timecode chain as already verified.
Axiom One LLC — SlateX. Figures current as of 24 September 2026.