Non-Drop in Drop-Frame 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 30 fps Non-Drop in 29,97 fps Drop-Frame um. Datei ablegen, Lauf starten, und Anfang und Ende jedes Blocks kommen in der anderen Schreibweise zurück. Text, Blocknummern, Reihenfolge und Zeilenumbrüche gehören der Datei und bleiben genau, wie sie waren.
Die beiden Schreibweisen stellen dieselbe Uhr unterschiedlich dar, und eine Datei muss in der Schreibweise sein, die der Rest der Verarbeitung verwendet. Drop-Frame zählt 30 Ziffern pro Sekunde, überspringt aber jede Minute außer jeder zehnten zwei davon; so bleibt es an der Wanduhr, während Non-Drop langsam hinter ihr zurückbleibt. Nach einer Stunde liegen beide 3,6 s auseinander: 01:00:00,000 unter Non-Drop ist 01:00:03,600 unter Drop-Frame. Dieser Abstand ist kein Rundungsfehler und wird nicht weggerundet – er wächst mit dem Programm und erreicht nach zehn Stunden 36 s.
In der ersten Minute einer Stunde bewegt sich nichts, weil dort keine Ziffer übersprungen wird und beide Schreibweisen diesen Abschnitt gleich darstellen. Das gilt für Uhren, die bereits auf einem 30-fps-Rasterpunkt liegen – 00:00:02,000 ist eine –; eine Uhr zwischen zwei Rasterpunkten wird auf den nächsten gezogen, um bis zu 17 ms. Das Rasten auf das Einzelbildraster geschieht überall in der Datei; innerhalb der ersten Minute ist es das Einzige, was sich bewegt. Die Zeiten einer Untertiteldatei stammen meist aus einem bildgenauen Werkzeug und liegen schon auf dem Raster, deshalb kommt dieser Abschnitt oft byteweise unverändert zurück.
Keines der hier gelesenen Untertitelformate hat ein Feld, das festhält, in welcher Schreibweise eine Uhr gemeint ist – SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON und CSV schreiben alle nur eine Zeit. Diese Seite ändert also die Zahlen; welche Schreibweise sie bedeuten, bleibt eine Eigenschaft der eigenen Verarbeitung, genau wie vor der Ankunft der Datei. Was nicht in der Datei steht, lässt sich nicht hineinschreiben, und so zu tun als ob, wäre schlechter, als es zu sagen.
Das ist keine Bildratenkonvertierung. Eine Datei für 25-fps-Video wird hier nicht neu getaktet, und nichts wird gegen ein Video gestreckt oder gestaucht: Die Abstände der Zeiten bleiben, nur ihre Schreibweise ändert sich. Wer die andere Aufgabe braucht – eine Untertiteldatei, deren Abstände einer anderen Bildrate folgen –, findet dafür eine eigene Seite. Hochgeladen wird ebenfalls nichts: Die Datei wird im Browser-Tab gelesen und geschrieben, Material, das den Rechner nicht verlassen darf, bleibt auf ihm.
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:05:00,333 --> 00:05:02,333
The room is dark.
2
00:10:00,600 --> 00:10:03,600
A cold night.
Die beiden Blöcke wandern nicht gleich weit, und das ist die ganze Operation: Nach fünf Minuten hat Drop-Frame zehn Ziffern übersprungen, die Uhr liest also 333 ms später; nach zehn Minuten sind achtzehn übersprungen, also 600 ms später. Text und Blocknummern gehören der Datei – nur die beiden Uhrwerte pro Block werden neu geschrieben.
Dieselbe Datei nach einer Stunde
Eingabe
1
01:00:00,000 --> 01:00:03,000
An hour into the programme.
Ausgabe
1
01:00:03,600 --> 01:00:06,600
An hour into the programme.
Nach einer Stunde liegen die beiden Schreibweisen 3,6 s auseinander, das sind 108 übersprungene Ziffern. An dieser Zahl lässt sich die Seite prüfen: Die erste Zeile der Ausgabe muss genau 3600 ms nach der ersten Zeile der Eingabe liegen. Beide Kanten des Blocks wandern, deshalb behält er seine Länge.
Ein Block innerhalb der ersten Minute
Eingabe
1
00:00:02,000 --> 00:00:04,000
Nothing to re-label yet.
2
00:05:00,000 --> 00:05:02,000
This one does move.
Ausgabe
1
00:00:02,000 --> 00:00:04,000
Nothing to re-label yet.
2
00:05:00,333 --> 00:05:02,333
This one does move.
Der erste Block kommt byteweise unverändert zurück, der zweite wandert, im selben Lauf. In der ersten Minute einer Stunde wird keine Ziffer übersprungen, deshalb schreiben beide Schreibweisen diese sechzig Sekunden gleich – und 00:00:02,000 liegt bereits auf einem 30-fps-Rasterpunkt, ändert sich also nicht. Eine Uhr zwischen zwei Rasterpunkten würde stattdessen um bis zu 17 ms auf den nächsten gezogen, mit demselben Rasten, das die Seite überall anwendet. Ein unveränderter Block neben einem verschobenen ist hier das erwartete Ergebnis, kein halb fertiger Lauf.
Häufige Fragen
Was unterscheidet Drop-Frame von Non-Drop-Frame-Timecode?
Beide zählen 30 Ziffern pro Sekunde, aber 29,97 fps liefern keine 30 Einzelbilder pro Sekunde, sondern etwa 29,97; eine Uhr mit 30 Ziffern pro Sekunde verliert daher langsam Boden gegen die Echtzeit. Drop-Frame behebt das, indem es am Anfang jeder Minute außer jeder zehnten zwei Ziffern überspringt: Die Ziffern fallen weg, die Einzelbilder nicht. Non-Drop behält jede Ziffer und driftet. Aufgeschrieben sehen beide wie dieselbe Art Zahl aus; gegen dasselbe Einzelbild gelesen liegen sie nach einer Stunde 3,6 s auseinander, und der Abstand wächst mit der Laufzeit.
Warum kommt ein Block nach einer Stunde 3,6 Sekunden später heraus?
Weil 3,6 s der Betrag ist, den eine Stunde übersprungener Ziffern ergibt: zwei Ziffern pro Minute in 54 von 60 Minuten, bei 33,37 ms pro Ziffer, also 108 Ziffern oder 3600 ms pro Stunde. Die Seite fügt keine Verzögerung hinzu – sie schreibt dieselben Einzelbilder in der anderen Schreibweise, und diese liest an dieser Stelle des Programms später. Ein Block bei 01:00:00,000 geht hinein, 01:00:03,600 kommt heraus; beide Kanten wandern, deshalb behält der Block seine Länge auf die Millisekunde.
Warum bleibt die erste Minute der Datei unverändert?
Weil während der ersten Minute einer Stunde keine Ziffer übersprungen wird, Drop-Frame und Non-Drop diesen Abschnitt also gleich schreiben – 00:00:02,000 bedeutet unter beiden 60 Einzelbilder, und 60 Einzelbilder werden in beiden Schreibweisen gleich notiert. Die Drift beginnt an der ersten Minutengrenze und wächst dann. Eine zweite Sache kann eine Zeit in diesem Abschnitt bewegen: Das Einlesen rastet auf den nächsten 30-fps-Rasterpunkt, ein Wert zwischen zwei Rasterpunkten wie 00:00:02,010 kommt daher als 00:00:02,000 zurück. Zeiten aus einem bildgenauen Werkzeug liegen schon auf dem Raster und bewegen sich nicht.
Welche Richtung ist die richtige – Non-Drop zu Drop-Frame oder umgekehrt?
Das hängt davon ab, wovon die Timecodes in der Datei gelesen wurden. Stammen die Zeiten aus einem Player oder Schnittprogramm mit Non-Drop und arbeitet die Zielumgebung in Drop-Frame, ist diese Seite richtig. Wurde die Datei gegen ein Drop-Frame-Display gestanzt und erwartet das Werkzeug danach Non-Drop, gehört sie auf die Gegenseite, die die Uhren mit denselben 3,6 s pro Stunde in die andere Richtung bewegt. Eine schnelle Probe: die Datei hier laufen lassen und einen Block vergleichen – liest die Ausgabe später als die Eingabe, war diese Richtung die benötigte.
Ändert diese Seite die Bildrate meiner Untertitel?
Nein. Nichts wird skaliert und nichts gestreckt: Ein Block, der zwei Sekunden lang war, bleibt zwei Sekunden lang, und die Abstände zwischen den Blöcken bleiben gleich, weil jeder Block um einen Betrag wandert, der von seiner Position abhängt, nicht von einem Verhältnis. Eine Datei für 25-fps-Video wird hier auch nicht auf 29,97 umgerechnet – das Feld für die Bildrate existiert, weil MicroDVD seine Zeiten als Einzelbildnummern speichert und ohne sie nicht gelesen werden kann. Die Abstände einer Datei auf eine andere Bildrate zu bringen, ist eine andere Operation mit eigener Seite.
Steht in der Datei, dass ihre Timecodes jetzt Drop-Frame sind?
Nein, und keines der hier gelesenen Formate könnte das: SRT, WebVTT, ASS, SSA, SBV, SAMI, MicroDVD, TTML, JSON und CSV speichern eine Zeit und nichts über ihre Zählweise. Das galt bereits für die abgelegte Datei. Die Seite ändert also die Zahlen, und welche Schreibweise sie bedeuten, bleibt das, was die eigene Verarbeitung sagt – dieselbe Anordnung wie vorher, jetzt mit passenden Zahlen. Hat ein nachgelagertes Werkzeug eine Drop-Frame-Einstellung, liest diese Einstellung die Werte.