What a Semicolon in Timecode Actually Tells You
When the final separator in a timecode changes from a colon to a semicolon, it usually signals drop-frame notation. That notation exists to keep timecode numbering closer to elapsed clock time at certain fractional frame rates. During receiving, however, the semicolon is a cue, not proof that the frame numbers were converted with drop-frame arithmetic. Display notation and counting behavior have to be checked separately.
A semicolon says “this string is being presented as drop-frame notation.” It does not automatically say “these frame numbers were calculated by drop-frame rules.”
Why drop-frame counting exists
At a fractional rate such as 29.97, the real frame progression and a timecode display numbered with a nominal integer rate of 30 do not move at exactly the same pace. If frame numbers simply continue without compensation, the displayed timecode gradually falls behind wall-clock time.
By arithmetic, that continuous 29.97 count accumulates roughly a minute and a half of difference over a day. Drop-frame counting does not remove video frames. It skips selected timecode numbers according to a rule so the displayed clock stays closer to elapsed time.
A common text convention uses a semicolon in the final separator, for example 01:00:00;00. That is a useful visual signal, but it remains part of the string representation.
Display notation and frame conversion are separate operations
Real drop-frame arithmetic has to apply the number-skipping rule while converting between frame counts and hours, minutes, seconds, and frames. Replacing the final : with ; changes appearance only; it does not change the frame position represented by the existing digits.
Both behaviors exist in the current SlateX delivery path. When an end position is missing and the app has to calculate one from start and duration, that calculation uses actual drop-frame arithmetic, and it applies when the row's frame rate falls into the drop-frame test. Existing start or end strings, however, can be given a semicolon by changing the display separator without recalculating the frame numbers.
That is the hard boundary: a ; can tell the receiver that the delivery layer labeled the string with drop-frame notation, but the character alone cannot prove how the digits were originally calculated.
Two “near 29.97” tests use different tolerances
Two different decisions use two different tolerances: the live side maps a nominal rate onto a base rate with a 0.013 tolerance, while the export side decides drop-frame from the numeric rate with a 0.02 tolerance. A value near the edge can therefore be classified differently by the two paths.
This is not merely cosmetic when the classification changes how a timecode is displayed or calculated. During receiving, compare the file’s actual FPS, the timecode string, and the media rather than treating a near-match to a familiar rate as proof that the entire chain used one counting convention.
Different decision points can produce different conclusions, so a rate that looks close enough in one part of the system should not be assumed to carry the same meaning everywhere.
The receiver needs to prove that a real media position matches the timecode, not merely that the separator looks right.
Live display and delivered notation are different layers
SlateX’s current live timecode path outputs colon-separated strings. It does not produce a semicolon representation. What appears live in the app and what may later appear in a handoff file therefore come from different representation rules.
The live path advances its count using the fractional rate and converts frames to a string using the nominal integer frame count. It does not perform drop-frame number skipping. A semicolon added during export cannot be used to infer that the live display already followed the same counting rule.
Receiving should keep those layers separate: where did the original timecode string come from, was a delivered end value recalculated, was only the separator changed, and does the final value actually line up with the media? Missing any of those checks makes the semicolon insufficient as an acceptance result.
How to verify a timecode that contains a semicolon
Start by checking whether the row’s FPS agrees with the media and on-set record. Then choose a piece of media whose position can be verified and compare the actual in point and elapsed duration. If the delivered end value was calculated, check that derived result separately.
For an existing start or end string, do not stop at the semicolon. Verify whether the frame position itself lands on the expected media frame. A string whose separator was changed can look like proper drop-frame notation while its digits still come from a different counting convention.
Treat the semicolon as a prompt to check the drop-frame interpretation, not as a label saying the verification is complete.
FAQ
Does a semicolon prove that the timecode was calculated with drop-frame rules?
No. It can be a display-layer marker. In the current delivery path, an existing timecode string may have only its final separator changed without its frame numbers being recalculated.
Does drop-frame counting remove actual video frames?
No in this context. It adjusts timecode numbering so a fractional frame rate can stay closer to elapsed clock time; it does not delete picture frames.
Why can the same frame-rate value be classified differently in two places?
The current “near 29.97” tests use tolerances of 0.013 and 0.02. A value near a boundary can therefore enter different branches, which is why the receiver should verify the actual file and media.
Does the live timecode shown in the app use semicolons too?
The current live path produces colon-separated strings and does not generate semicolon notation. A semicolon in a delivered file belongs to a different stage and cannot prove that the live path used the same counting method.
Axiom One LLC — SlateX. Figures current as of 24 September 2026.