SBV in SMI umwandeln
Oder Untertiteltext einfügen
Was diese Konvertierung ändert
In diese Richtung geht nichts verloren — jedes Merkmal des Quellformats hat im Zielformat einen Platz.
Diese Liste stammt aus der Fähigkeitsmatrix für diese beiden Formate, nicht aus der konkreten Datei, die Sie geladen haben. Eine bestimmte Datei kann mehr verlieren, wenn sie Merkmale nutzt, die das Format erlaubt, die Matrix aber nicht modelliert.
Diese Seite konvertiert SBV nach SMI. Datei hineinziehen oder Text einfügen — zurück kommt die SAMI-Fassung. Die Konvertierung läuft vollständig im Browser, ohne Upload und ohne Konto.
In dieser Richtung geht nichts verloren. SAMI kann alles ausdrücken, was SBV enthält: Zeitachse, Zeilenumbrüche und Text kommen vollständig an, und weil SBV keine Stile und keine Positionierung kennt, fehlt auch nichts. Die Ausgabe bringt den SAMI-Kopf mit einem `<STYLE>`-Block und je einem `<SYNC Start=…>` pro Block mit.
Eine Datei ist kein Problem, eine ganze Staffel auch nicht: Die Warteschlange arbeitet sie der Reihe nach ab, und die Ergebnisse kommen gemeinsam als eine ZIP-Datei.
Beispiele
Eine typische SBV-Datei, nach SMI konvertiert
Eingabe
0:00:01.000,0:00:03.500
The quick brown fox.
0:00:04.000,0:00:06.250
Jumps over the lazy dog.
0:00:07.000,0:00:09.000
Two lines here.
And a second one.
Ausgabe
<SAMI>
<HEAD>
<STYLE TYPE="text/css">
<!--
P { text-align: center; font-family: Arial, sans-serif; }
-->
</STYLE>
</HEAD>
<BODY>
<SYNC Start=1000>
<P>The quick brown fox.
<SYNC Start=3500>
<P>
<SYNC Start=4000>
<P>Jumps over the lazy dog.
<SYNC Start=6250>
<P>
<SYNC Start=7000>
<P>Two lines here.<br>And a second one.
<SYNC Start=9000>
<P>
</BODY>
</SAMI>
Hier geht nichts verloren: beide Seiten Zeile für Zeile vergleichen.
Dieselbe Konvertierung mit einer unordentlichen Eingabe
Eingabe
0:00:02.000,0:00:04.000
Carriage-return line endings.
0:00:06.000,0:00:08.000
Indented timecode, no final newline.Ausgabe
<SAMI>
<HEAD>
<STYLE TYPE="text/css">
<!--
P { text-align: center; font-family: Arial, sans-serif; }
-->
</STYLE>
</HEAD>
<BODY>
<SYNC Start=2000>
<P>Carriage-return line endings.
<SYNC Start=4000>
<P>
<SYNC Start=6000>
<P>Indented timecode, no final newline.
<SYNC Start=8000>
<P>
</BODY>
</SAMI>
So sehen echte Schäden aus — gemischte Zeilenenden, verirrte Leerzeichen, leere Felder. Im Vergleich zum sauberen Beispiel oben wird sichtbar, was der Parser verzeiht.
Häufige Fragen
Wie sieht die Ausgabe aus, wenn SBV zu SMI wird?
Wie SAMI: Der SBV-Block wird zu `<SYNC Start=…>` mit dem Text in einem `<P>` darunter. Weil SAMI einen Block durch den nächsten ersetzt, schließt ein `<P> ` jeden Block ab; Blocknummern gibt es keine, SBV hatte auch keine.
Bleiben die SBV-Zeiten in der SMI-Datei exakt?
Ja, auf die Millisekunde — feiner geht keines der beiden Formate. SBV schreibt einen Zeitpunkt als `0:00:04.126`, SMI denselben als `Start=4126`; nichts wird gerundet oder verschoben, und ein Block, der 2,9 Sekunden sichtbar war, bleibt es.
Wie kommt ein zweizeiliger SBV-Block in SMI an?
Als zwei Zeilen mit `<br>` dazwischen — so schreibt SAMI einen harten Zeilenumbruch innerhalb eines `<P>`-Elements. Die beiden SBV-Zeilen bleiben ein Untertitel.
Behalten SBV-Blöcke in der SMI-Ausgabe ihre Reihenfolge?
Ja, und sie werden unterwegs nach Startzeit sortiert — der früheste zuerst. War die SBV-Datei ungeordnet, stellt SMI die Reihenfolge wieder her; das ändert die Struktur, nicht den Inhalt.
Lässt sich SMI wieder nach SBV konvertieren?
Ja, und das ist die verlustbehaftete Richtung: Stile, Positionierung und formatspezifische Konstruktionen haben in SBV keinen Platz. In dieser Richtung geht nichts verloren, der Preis entsteht erst auf dem Rückweg.
Behält die SMI-Ausgabe die Zeichenkodierung der SBV-Datei?
Nein — die Ausgabe ist UTF-8 mit Unix-Zeilenenden und ohne Byte-Order-Mark, unabhängig von der SBV-Datei. UTF-16 oder eine Windows-Einzelbyte-Kodierung wird beim Einlesen dekodiert; was herauskommt, ist immer dieselbe UTF-8-SAMI-Datei.