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.
In SlateX handoffs these two conventions sit in different cells. An in-point or out-point string already on the record takes one of two paths: a reading captured by the recording chain is re-rendered into a valid drop-frame address, because changing only the separator would produce values like ;00 or ;01 that SMPTE does not define; a reading the supervisor copied off the camera or a panel is left digit for digit, with only the final separator changed to a semicolon. When the source is undeclared we do not guess: the digits stay untouched and the reconcile sheet names the missing declaration as TC_SOURCE_UNDECLARED. Duration is the frame-accurate span between the two readings, and it carries semicolons on rows declaring DF.
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.
A value near 29.97 does not declare drop-frame
A frame rate close to 29.97 is not, by itself, proof that the whole chain uses one counting convention. Edge values deserve particular care: what the screen shows and what the handoff file writes can land in different classifications. What you can check is what the cell finally says, and whether the row’s actual FPS, timecode string, and media line up.
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
The live timecode shown on screen is a colon-separated string with no semicolon. What appears live in the app and what may later appear in a handoff file therefore come from different representation rules.
A semicolon appearing later in a delivered file cannot be used to infer that the live display already followed the same counting rule.
Receiving should keep those layers separate: which string was read on screen, which string the handoff writes, whether only the separator changed on an existing string, and whether the final media positions actually line up. 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. The out-point is a transcription, so the check there is whether one exists at all; the span in Duration is the calculated value, so review it against the two readings and the counting rule they were read with.
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 a delivered file, 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 land differently?
The screen display and the handoff file belong to two different stages, so a value on the edge can land differently. Verify the actual file and media, and read what the cell finally says.
Does the live timecode shown in the app use semicolons too?
The live timecode shown on screen is a colon-separated string. A semicolon in a delivered file belongs to a different stage and cannot prove that the live display used the same counting method.
Axiom One LLC — SlateX