Untertitel mit Ende vor dem Start finden
Oder Untertiteltext einfügen
Optionen
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.
Ein Block, der vor seinem Start endet, ist ein Zeitcode, der nicht wahr sein kann: 00:00:03,000 --> 00:00:03,000 oder schlimmer, ein Ende vor dem Start. Diese Seite meldet Dateien, die einen solchen enthielten, gezählt aus den Reparaturen, die der Leser vornehmen musste, weil ein Zeitcode dieser Form gar nicht im Speicher gehalten werden kann und ersetzt wird, bevor irgendetwas anderes geschieht. Zurück kommt ein Bericht, nie eine veränderte Datei.
Deshalb beginnt der Bericht mit dem, was beim Lesen verloren ging, und zeigt erst danach den Befund. Ein Block, dessen Ende nicht nach dem Start liegt, bekommt eine Millisekunde, damit der Rest der Datei überhaupt gelesen, angezeigt und exportiert werden kann; die Zahl dieser Reparaturen steht im Berichtskopf, und der Befund darunter nennt einen Fehler ohne Blocknummer, weil die Reparaturen beim Lesen gezählt und nicht in einer Liste geführt werden. Beide Zeilen beschreiben denselben kaputten Zeitcode von zwei Seiten, deshalb gehören sie in denselben Bericht und nicht in zwei.
Die Falle, um die diese Seite herum geschrieben werden musste, ist, dass ein legitimer Ein-Millisekunden-Block genauso aussieht wie ein reparierter. Die Prüfung sieht deshalb gar nicht auf Dauern – sie sieht auf das Reparaturprotokoll –, und ein Block, der wirklich eine Millisekunde dauert, bleibt unbeanstandet. Eine negative Dauer und eine Dauer von null sind derselbe Defekt und werden zusammen gezählt. Zwei Formate werden gar nicht angenommen, und ausnahmsweise ist der Grund auf beiden Seiten derselbe: LRC leitet jede Endzeit aus dem folgenden Zeitstempel ab, ein Paar kann dort also nie rückwärts herauskommen, und reiner Text hat überhaupt keine Blockzeiten. Beides zu prüfen würde einen sauberen Bericht über ein Feld erzeugen, das das Format nicht hat – die einzige Art von Antwort, die schlimmer ist als keine Antwort.
Beispiele
Ein Block ohne Dauer
Untertitel
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,000
I was working late.
Was der Bericht findet
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Ein Ende gleich dem Start. Der Leser gibt dem Block eine Millisekunde, damit die Datei überhaupt gehalten werden kann, zeichnet die Reparatur auf, und der Bericht druckt beide Hälften: die Verlustzeile im Kopf und einen Fehler darunter. Die Reparatur ist der Beleg; die Millisekunde ist nur die Form, die der Beleg annimmt.
Ein Block, der wirklich eine Millisekunde dauert
Untertitel
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,001
I was working late.
Was der Bericht findet
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
Von Hand als Ein-Millisekunden-Block geschrieben und nicht gemeldet. Diese Entscheidung prägt die Prüfung: Ein reparierter Block ohne Dauer kommt ebenfalls als eine Millisekunde heraus; eine Regel, die hier kurze Dauern meldete, würde jede Datei mit kaputtem Zeitcode als Datei voller unmöglich kurzer Blöcke bezeichnen.
Das Ende liegt vor dem Start
Untertitel
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:05,000 --> 00:00:02,000
I was working late.
Was der Bericht findet
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Fünf Sekunden auf zwei Sekunden: derselbe Defekt wie der Fall ohne Dauer, von derselben Regel gezählt und identisch gemeldet. In der Datei wird nichts umgeschrieben – die reparierten Zeiten existieren in der Lesekopie, damit der Rest verarbeitet werden kann, und sie sind keine angebotene Korrektur.
Häufige Fragen
Was gilt als Block, der vor seinem Start endet?
Eine Endzeit, die nicht später als die Startzeit ist: entweder gleich, wie 00:00:03,000 bis 00:00:03,000, oder früher, wie 00:00:05,000 bis 00:00:02,000. Beides ist derselbe Defekt und wird zusammen gezählt, und beides wird aus der Reparatur des Lesers gezählt und nicht aus dem Block, weil ein Zeitcode dieser Form nicht im Speicher gehalten werden kann.
Warum nennt der Bericht die betroffenen Blöcke nicht?
Weil diese Reparaturen beim Lesen der Datei gezählt und nicht in einer Liste gesammelt werden. Der Bericht gibt die Zahl – ein Fehler, ein Eintrag in der Verlustzeile des Kopfes –, und die beiden Hälften sind derselbe Sachverhalt aus Sicht des Kopfes und der Befunde. Wer den genauen Block braucht, sucht in der Datei nach seiner Zeitcodefolge und nicht nach einer Blocknummer.
Ist ein Block, der eine Millisekunde dauert, ein Problem?
Hier nicht, und das ist Absicht. Ein von Hand geschriebener Ein-Millisekunden-Block ist zulässig und wird nicht gemeldet; gemeldet wird ein Zeitcode, der repariert werden musste und danach zufällig als eine Millisekunde gespeichert ist. Dauern statt Reparaturen zu prüfen würde jede Datei mit einem Block ohne Dauer als Datei voller unmöglich kurzer Blöcke melden, und das wäre zweimal der falsche Befund.
Repariert diese Seite die gefundenen Zeitcodes?
Nein. Die reparierten Zeiten existieren nur im Browser, damit der Rest der Datei gelesen und berichtet werden kann. Die Datei, die Sie heruntergeladen oder hereingezogen haben, ist unverändert, und die reparierte Fassung lässt sich von dieser Seite nicht speichern – einen kaputten Zeitcode zu ersetzen ist ein Vorgang mit einer Untertiteldatei als Ergebnis, keine Prüfung.
Welche Untertitelformate lassen sich auf Blöcke mit Ende vor dem Start prüfen?
Zehn der zwölf: SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON und CSV. Zwei fehlen, und keines ist ein Versehen. LRC speichert eine Zeit pro Zeile, und der Leser leitet jedes Ende aus dem nächsten Zeitstempel ab, ein Paar kann dort also nie rückwärts liegen – die Prüfung würde ein Feld beurteilen, das das Format nicht hat. Reiner Text hat gar keine Blockzeiten. Wenn Ihre Datei in einem der beiden vorliegt, konvertieren Sie sie zuerst.
Woher kommen solche kaputten Zeitcodes?
Fast immer erzeugt, nicht getippt. Eine Bildratenumrechnung, die in die falsche Richtung rundet; ein zweimal auf denselben Block angewandter Versatz; ein Tabellenexport, in dem die Endspalte leer blieb und als null gelesen wurde; und ein Untertitel, der aus einer Timed-Text-Datei mit einer Marke ohne Dauer extrahiert wurde.
Lassen sich mehrere Dateien in einem Lauf prüfen?
Ja. Legen Sie beliebig viele ab, und sie werden nacheinander gelesen, jede erzeugt ihren eigenen Bericht, und die Berichte laden zusammen als ZIP-Archiv herunter. Die Warteschlange zeigt den Fortschritt pro Datei, der Lauf lässt sich unterbrechen, und keine Datei wird zu irgendeinem Zeitpunkt hochgeladen.