Was ein Semikolon im Timecode tatsächlich besagt
Wird das letzte Trennzeichen eines Timecodes vom Doppelpunkt zum Semikolon, ist das meist der Hinweis: „Diese Timecode-Kette zeigt eine Drop-Frame-Schreibweise.“ Gemeint ist das Problem, dass die Framezählung bei einigen gebrochenen Bildraten über die Zeit von der mitlaufenden Uhrzeit abwegt. Beim Empfang einer Übergabedatei gilt jedoch, dass das Semikolon nur ein Hinweis ist und für sich nicht belegt, dass die Framepositionen nach der Drop-Frame-Regel umgerechnet wurden. Anzeigzeichen und Zählalgorithmus sind getrennt zu prüfen.
Das Semikolon sagt, dass diese Zeichenkette eine Drop-Frame-Schreibweise ausdrücken will; es sagt nicht automatisch, dass diese Framepositionen nach der Drop-Frame-Regel gerechnet wurden.
Warum es eine Drop-Frame-Zählweise gibt
Bei einer gebrochenen Bildrate wie 29.97 weicht die Zahl der Frames, die in einer Realzeitsekunde tatsächlich fortgeschrieben werden, in ihrem Tempo von dem Rhythmus ab, der entsteht, wenn mit der ganzen Zahl 30 nummeriert wird. Würde fortlaufend mit aufsteigenden ganzen Frame-Nummern ohne Ausgleich angezeigt, käme die Timecode-Lesung allmählich hinter die Realzeit zurück.
Nach der Formel gerechnet kommt eine fortlaufende Zählung bei 29.97 auf die Größenordnung von etwa einer Minute und einer halben Minute pro Tag. Die Drop-Frame-Zählung wirft deshalb nicht etwa Videoframes weg; sie überspringt innerhalb der Timecode-Nummerierung nach einer Regel bestimmte Nummern, damit Anzeigeuhr und verstrichene Zeit wieder zusammenfinden.
Die übliche Textvereinbarung schreibt das Trennzeichen des letzten Segments als Semikolon, etwa 01:00:00;00. Dieses Zeichen ist nützlich, weil die Empfängerseite auf einen Blick erkennt, dass die Datei gerade eine Drop-Frame-Schreibweise ausdrückt. Trotzdem bleibt es ein Teil der Zeichenkette.
Anzeigzeichen und Umrechnung der Framepositionen sind zwei Dinge
Eine echte Drop-Frame-Rechnung führt die Übersprungregel aus, sooft zwischen Frame-Nummer und Stunden, Minuten, Sekunden und Frames umgerechnet wird. Wird lediglich der letzte : durch ; ersetzt, ändert sich nur das Aussehen, nicht aber die Frameposition, die diese Ziffernfolge zuvor dargestellt hat.
In den aktuellen Übergabewegen von SlateX kommen beide Verhaltensweisen vor. Fehlt eine Endposition und muss die Software den Outpunkt aus Startzeitcode und Dauer rechnen, läuft die tatsächliche Drop-Frame-Rechnung. Eine bereits vorhandene Start- oder Outpunkt-Zeichenkette dagegen bekommt nur das Trennzeichen des letzten Segments auf Semikolon gesetzt, ohne jede Umrechnung der Framepositionen.
Das ist die harte Grenze dieses Beitrags: Ein ; sagt, dass die Übergabeschicht diese Zeichenkette als Drop-Frame-Schreibweise gekennzeichnet hat. Aus dem Zeichen allein lässt sich nicht lesen, ob diese Ziffern zuvor mit der Drop-Frame-Regel entstanden sind.
Zwei Prüfungen auf „nahe bei 29.97“ verwenden verschiedene Toleranzen
Die Live-Seite rechnet die Nennrate einer Kamera auf eine Basisrate zurück und verwendet dabei die Toleranz 0.013; die Exportseite prüft numerisch, ob Drop-Frame vorliegt, und verwendet dabei die Toleranz 0.02 – die beiden prüfen verschiedene Objekte, und es ist auch nicht derselbe Zahlenwert. Ein Bildratenwert an der Grenze kann in den beiden Logiken deshalb unterschiedlich eingeordnet werden.
Ein solcher Unterschied sollte nicht als Implementierungsdetail verpackt werden, das die Empfängerseite nichts angeht. Solange er verändert, welchen Anzeige- oder Rechnungsweg ein Timecode nimmt, gehört er bei der Abnahme zusammen mit der tatsächlichen FPS-Angabe der Datei, den Timecode-Zeichenketten und dem Material geprüft.
Ebenso darf aus „der Zahlenwert liegt nahe bei einer üblichen Bildrate“ nicht geschlossen werden, dass die gesamte Kette bereits dieselbe Zählregel verwendet. Unterschiedliche Prüfeingänge können zu unterschiedlichen Ergebnissen führen.
Die Empfängerseite prüft, wie ein tatsächliches Material auf einen Timecode sitzt, und nicht nur, wie ein Trennzeichen aussieht.
Live-Anzeige der App und Übergabedatei sind nicht dieselbe Darstellung
Die Live-Kette von SlateX gibt derzeit durchgehend Timecodes mit Doppelpunkten aus und erzeugt keine Semikolon-Darstellung. Die Zeichenkette, die am Set auf dem Bildschirm live zu sehen ist, und ein Semikolon in einer Übergabedatei folgen also zwei verschiedenen Darstellungsregeln zweier Stadien.
Die Live-Kette führt die Zählung bei einer gebrochenen Bildrate nach dem gebrochenen Wert fort und rechnet die Framezahl dann mit einer ganzzahligen Bildrate in eine Zeichenkette; eine Drop-Frame-Überspringschreibweise hat sie für sich nicht. Aus einem Semikolon, das später in der Übergabedatei auftaucht, lässt sich deshalb nicht zurücklesen, dass die Live-Anzeige am Set schon nach derselben Regel gearbeitet hat.
Beim Empfang sind beide Ebenen zu trennen: Woher der rohe String der Aufzeichnung vom Set kommt, ob bei der Übergabe neu gerechnet wurde, ob nur das Trennzeichen ersetzt wurde, und ob das Material am Ende wirklich sitzt. Fehlt eine dieser Angaben, darf das Semikolon nicht als Abnahmeergebnis gelesen werden.
Wie eine Timecode mit Semikolon tatsächlich geprüft wird
Zuerst wird geprüft, ob die FPS dieser Zeile zu Material und Aufzeichnung vom Set passt; danach wird ein ortbares Material genommen und gegen den tatsächlichen Startpunkt und die verstrichene Zeit gehalten. Ist die Endposition in der Datei von der Software gerechnet, ist gesondert zu bestätigen, ob sie den passenden Zählweg durchlaufen hat.
Handelt es sich bei Start- oder Outpunkt um eine vorhandene Zeichenkette, genügt es nicht zu sehen, ob ein Semikolon daran ist. Die Empfängerseite prüft die Framepositionen selbst gegen das Material. Eine Zeichenkette, bei der nur das Zeichen getauscht wurde, kann optisch einer korrekten Drop-Frame-Timecode sehr ähnlich sehen, und ihre Ziffern stammen trotzdem aus einer anderen Zählart.
Das Semikolon taugt damit als Hinweis „hier ist die Drop-Frame-Handhabung zu prüfen“ und nicht als Kennzeichen „diese Zeile ist geprüft“.
FAQ
Sichert ein Semikolon im letzten Segment, dass nach der Drop-Frame-Regel gerechnet wurde?
Nein. Das Semikolon kann nur ein Zeichen der Anzeigeseite sein. Auf dem aktuellen Übergabeweg wird an einer vorhandenen Timecode-Zeichenkette möglicherweise nur das letzte Trennzeichen ersetzt, ohne die Framepositionen neu zu rechnen.
Wirft die Drop-Frame-Zählung tatsächliche Videoframes weg?
Das meint dieser Zusammenhang nicht. Die Drop-Frame-Zählung verändert die Nummerierungsregel des Timecodes, um die dauernde Abweichung zwischen fortlaufender Nummer und Realzeit bei einer gebrochenen Bildrate auszugleichen.
Warum kann derselbe Bildratenwert in zwei Logiken anders beurteilt werden?
Weil die beiden Toleranzen für „nahe bei 29.97“ derzeit 0.013 und 0.02 sind. Ein Wert an der Grenze kann in einen anderen Zweig fallen, weshalb die Empfängerseite die tatsächliche Datei und ihr Material prüft.
Nutzt die Live-Timecode auf dem Bildschirm der App auch ein Semikolon?
Die aktuelle Live-Kette gibt Zeichenketten mit durchgehend Doppelpunkten aus und erzeugt keine Semikolon-Darstellung. Ein Semikolon in der Übergabedatei gehört zu einer anderen Stufe und lässt nicht darauf zurückkommen, dass die Live-Kette dieselbe Drop-Frame-Zählung verwendete.
Axiom One LLC — SlateX. Die obigen Zahlen Stand 2026-09-24.