Drop-Frame in Non-Drop umrechnen
Oder Untertiteltext einfügen
Optionen
30-fps-Non-Drop und 29,97-Drop-Frame schreiben dieselbe Uhr unterschiedlich, und dieses Feld wählt, in welche Richtung die Datei gelesen und in welche sie zurückgeschrieben wird. Ein Block eine Stunde weiter liest sich unter dem einen als 01:00:00,000 und unter dem anderen als 01:00:03,600 — die beiden liegen 3,6 Sekunden pro Stunde auseinander, kein Rundungsfehler. Der Titel der Seite nennt eine Richtung, und dieses Feld bietet nur diese an, die Datei, die Sie bekommen, ist also die, um die es auf der Seite geht. Am Text ändert sich nichts: kein Block wird gegen das Video neu getaktet, keine Bildrate wird umgerechnet, und ein Block innerhalb der ersten Minute einer Stunde kommt genau so zurück, wie er hineinging, weil dort kein Bildlabel verworfen wird.
In welcher Bildrate die Zeitangaben gezählt werden. Auf den Formatseiten ist das, was MicroDVD braucht, denn es speichert Zeitangaben als Bildnummern. Auf den Bildraten-Seiten ist es die Rate, gegen die die Datei getaktet wurde — die Fassung, für die die Untertitel erstellt wurden —, und das zweite Feld der Seite nimmt die Rate des Videos auf, mit dem Sie sie verwenden wollen. 23,976, 24, 25, 29,97, 30, 50, 59,94 und 60 sind die üblichen. Ein falscher Wert verschiebt die gesamte Zeitachse, und auf den Bildraten-Seiten verschiebt er sie um einen Faktor statt um einen festen Betrag.
Diese Seite benennt jeden Timecode einer Untertiteldatei von 29,97 fps Drop-Frame in 30 fps Non-Drop um. Der Betrag, um den die Uhr dabei zurückgeht, wächst mit dem Programm: In der ersten Minute einer Stunde bleibt er null, nach fünf Minuten sind es 333 ms, nach einer Stunde 3,6 s und nach zehn Stunden 36 s. Text, Blocknummern, Reihenfolge und Zeilenumbrüche gehören der Datei und kommen unverändert heraus.
Gedacht ist die Seite für Dateien, die gegen ein Drop-Frame-Display oder einen Drop-Frame-Rekorder gestanzt wurden – bei 29,97-Material der Normalfall, weil Drop-Frame an der Wanduhr bleibt. Alles danach liest die Uhren jedoch als Non-Drop. So gelesen ist jeder Timecode um einen wachsenden Betrag zu groß, und die Untertitel erscheinen zu früh: nach einer halben Stunde um 1,8 s, und der Fehler wächst bis zum Dateiende weiter. Deshalb ist die Reparatur keine Verschiebung um einen festen Wert, sondern eine Umbenennung an jedem Zeitstempel, deren Größe von der Position des Blocks abhängt.
Beim Einlesen wird jede Uhr auf das nächste 30-fps-Einzelbild gerastet, und im Drop-Frame fehlen zwei dieser Rasterpunkte. Drop-Frame überspringt am Anfang jeder Minute die Ziffern ;00 und ;01, außer bei jeder zehnten Minute: Es zählt 00:00:59;28, 00:00:59;29 und springt dann auf 00:01:00;02. Ein eingehendes 00:01:00,000 benennt damit einen Zeitpunkt, den diese Schreibweise nicht darstellen kann; es wird auf 00:00:59,933 zurückgezogen, 67 ms früher. Das ist eine echte Grenze der Arithmetik und keine Toleranz, und die Seite nennt sie, statt sie zu glätten: Über zwei Stunden sind es 216 solcher Werte.
Ein Block, der nach dem Rasten kürzer als ein Einzelbild ist, lässt sich gar nicht schreiben, weil seine beiden Kanten auf demselben Rasterpunkt landen und ein Block mit gleichem Anfang und Ende kein Block ist. Solche Blöcke werden verworfen und im Verlustbericht über dem Arbeitsbereich gezählt, nicht stillschweigend auf ein Einzelbild gestreckt. In der Praxis betrifft das nur Material, das Einzelbild für Einzelbild geschnitten wurde; die Seite verlässt sich aber nicht darauf, dass das selten ist – sie meldet die Anzahl, und eine Datei ohne solche Blöcke meldet nichts.
Nichts wird hochgeladen. Die Datei wird im Browser-Tab gelesen und neu geschrieben und verlässt den Rechner nicht; das zählt hier aus demselben Grund wie auf jeder anderen Seite: Material, das einer Vertraulichkeitspflicht unterliegt, gehört nicht zu einem Konvertierungsdienst.
Beispiele
Eine Datei nach fünf Minuten
Eingabe
1
00:05:00,000 --> 00:05:02,000
The room is dark.
2
00:10:00,000 --> 00:10:03,000
A cold night.
Ausgabe
1
00:04:59,667 --> 00:05:01,667
The room is dark.
2
00:09:59,400 --> 00:10:02,400
A cold night.
Die Korrektur ist keine einzige Zahl für die ganze Datei: Nach fünf Minuten geht die Uhr um 333 ms zurück, nach zehn Minuten um 600 ms, weil Drop-Frame bis zum ersten Block zehn und bis zum zweiten achtzehn Ziffern übersprungen hat. Jeder Block behält seine Länge auf die Millisekunde, denn beide Kanten wandern gleich weit – das ist eine Umbenennung, keine Verschiebung.
Dieselbe Korrektur nach einer Stunde
Eingabe
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Ausgabe
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
Nach einer Stunde ist Drop-Frames 01:00:03,600 das, was Non-Drop 01:00:00,000 nennt: 108 übersprungene Ziffern, 3600 ms. An dieser Zahl lässt sich die Seite prüfen – die erste Zeile der Ausgabe muss genau 3600 ms vor der ersten Zeile der Eingabe liegen, und eine Datei von einem Drop-Frame-Rekorder landet auf der vollen Stunde.
Ein Block innerhalb der ersten Minute
Eingabe
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:05:00,000 --> 00:05:02,000
This one does move.
Ausgabe
1
00:00:04,000 --> 00:00:06,000
Still early in the file.
2
00:04:59,667 --> 00:05:01,667
This one does move.
In der ersten Minute einer Stunde wird keine Ziffer übersprungen, deshalb schreiben beide Schreibweisen diese sechzig Sekunden gleich, und der erste Block bleibt unangetastet. Der zweite Block bei fünf Minuten wandert. Ein unveränderter Block neben einem verschobenen ist für diese Datei das richtige Ergebnis und kein hängender Lauf – die Korrektur ist am Anfang einer Stunde null und wächst ab der ersten Minutengrenze.
Häufige Fragen
Warum erscheinen die Untertitel nach der Drop-Frame-Umrechnung früher statt später?
Weil die Uhren in der Datei größer waren als die Zeitpunkte, die sie benennen. Non-Drop zählt 30 Ziffern pro Sekunde, als ob 29,97 fps 30 Einzelbilder pro Sekunde lieferten, und läuft daher langsam der Echtzeit voraus; Drop-Frame überspringt zwei Ziffern pro Minute, um mitzuhalten. Eine Uhr, die von einem Drop-Frame-Rekorder stammt und als Non-Drop gelesen wird, zeigt also über den richtigen Zeitpunkt hinaus, und die Korrektur zieht diesen Überschuss ab: 333 ms nach fünf Minuten, 3600 ms nach einer Stunde, 36000 ms nach zehn Stunden. In der ersten Minute einer Stunde ist der Betrag null, deshalb ist die kleinste Korrektur die an der ersten Minutengrenze, und keine Uhr rutscht unter 00:00:00.
Was passiert mit einem Drop-Frame-Timecode, den Non-Drop nicht schreiben kann?
Er wird auf die letzte Ziffer zurückgezogen, die sich schreiben lässt. In jeder überspringenden Minute fehlen die Ziffern ;00 und ;01, deshalb sind 00:01:00,000 und 00:01:00,010 keine Uhren, die diese Schreibweise anzeigen kann: Sie landen auf 00:00:59,933, 67 ms früher. Das ist die einzige Stelle auf dieser Seite, an der die Ausgabe keine exakte Umbenennung ist, und sie ist begrenzt – zwei Ziffern pro überspringender Minute, 216 Werte über zwei Stunden –, deshalb nennt die Seite sie hier, statt sie erst im Vergleich sichtbar werden zu lassen.
Kann durch die Umrechnung ein Untertitelblock verschwinden?
Nur ein Block, der kürzer als ein Einzelbild ist, also 33,37 ms. Zwei Dinge können einen Block auf ein einziges Einzelbild schieben: das beschriebene Rasten, bei dem ein Zehn-Millisekunden-Block wie 00:01:00,000 bis 00:01:00,010 an beiden Kanten auf 00:00:59,933 gezogen wird, und ein Block, der schon bei der Ankunft kürzer als ein Einzelbild war. Ein Block mit gleichem Anfang und Ende lässt sich nicht schreiben, deshalb wird er verworfen, und seine Anzahl erscheint im Verlustbericht über dem Arbeitsbereich. Eine Datei ohne solche Blöcke meldet nichts, und das ist der Normalfall.
Ändert sich außer den Timecodes noch etwas in der Datei?
Nein. Blocknummern, ihre Reihenfolge, der Text jeder Zeile, die harten Zeilenumbrüche innerhalb eines Blocks und die Gesamtzahl der Blöcke gehören der Datei und bleiben, wie sie waren. Die Seite schreibt pro Block dieselben zwei Zahlen in der anderen Schreibweise. Sie vermerkt auch nirgends, dass die Uhren jetzt Non-Drop sind, weil keines der hier gelesenen Formate – SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON, CSV – ein Feld dafür hat und die abgelegte Datei es ebenfalls nicht sagte.
Welche Bildrate gehört in das Feld für die Bildrate?
Jede Rate, die das Material tatsächlich hat; sie beeinflusst diese Umrechnung nicht. 30 und 29,97 im Namen der Seite bezeichnen die Zählweise des Timecode-Strings, nicht die Bildrate des Videos, deshalb wird hier nichts mit der eingegebenen Zahl skaliert. Das Feld ist nur nötig, weil MicroDVD seine Zeiten als Einzelbildnummern speichert und ohne bekannte Bildrate nicht gelesen werden kann.
Ist die Rückumrechnung auf der Gegenseite verlustfrei?
Ja, byteweise, solange kein Timecode in die Klasse fiel, die Drop-Frame nicht schreiben kann. Die beiden Seiten sind dieselbe Arithmetik in entgegengesetzter Richtung: Diese zieht einen wachsenden Betrag ab, die andere addiert ihn wieder, und die Beträge richten sich nach der Position jedes Blocks, nicht nach einem festen Offset. Die Ausnahme ist der Rastfall – aus 00:01:00,000 wurde 00:00:59,933, und daraus wird wieder 00:00:59,933 –, und das ist die einzige Zeitstempelklasse, für die das Paar keinen Rundlauf bildet.