VTT naar SMI
Of plak ondertiteltekst
Wat deze conversie verandert
1 ding vervalt of vraagt om een beslissing
- Formaatspecifieke inhoud
inhoud die het bronformaat buiten zijn blokken bewaart (blokken die geen ondertitel zijn, koptekst, instellingen per blok, uitgecommentarieerde gebeurtenissen) — het doelformaat heeft er geen plek voor
Deze lijst komt uit de capaciteitenmatrix voor deze twee formaten, niet uit het bestand dat je hebt geladen. Een specifiek bestand kan meer verliezen wanneer het kenmerken gebruikt die het formaat toestaat maar de matrix niet modelleert.
Deze pagina zet WebVTT om naar SAMI (SMI), het formaat dat Windows Media Player gebruikte. De vorm verschilt nogal: geen cue-nummers en geen tijdstempelregel, maar een reeks SYNC-tags met de tekst in een P-element eronder. Omdat een SYNC vervangt wat op het scherm stond, schrijft de omzetter na elke cue ook een leeg P-blok dat het scherm weer vrijmaakt, en bovenin komt een STYLE-blok met de basisregel voor P.
Tijden en tekst komen heel over. WebVTT schrijft een moment als 00:00:04.126 en SMI schrijft hetzelfde moment als Start=4126; niets wordt afgerond of verschoven. Inline-tags zoals <i> blijven in de tekst staan, en een cue met twee regels krijgt een <br> ertussen.
Wat niet meekan, is de documentlaag van WebVTT: de kop, de NOTE-, STYLE- en REGION-blokken en de instellingen align:start of position:10%. SMI heeft zijn eigen STYLE-blok, maar dat is een vaste CSS-regel van de omzetter, geen overname van het jouwe. Het verliesoverzicht noemt het, en de omzetting draait in je browser.
Voorbeelden
Een typisch VTT-bestand, omgezet naar SMI
Invoer
WEBVTT
intro
00:00:01.000 --> 00:00:04.000
Hello there.
00:00:04.500 --> 00:00:08.000 align:start position:10%
Second line with <i>italics</i>.
Uitvoer
<SAMI>
<HEAD>
<STYLE TYPE="text/css">
<!--
P { text-align: center; font-family: Arial, sans-serif; }
-->
</STYLE>
</HEAD>
<BODY>
<SYNC Start=1000>
<P>Hello there.
<SYNC Start=4000>
<P>
<SYNC Start=4500>
<P>Second line with <i>italics</i>.
<SYNC Start=8000>
<P>
</BODY>
</SAMI>
In deze uitvoer verloren: formaateigen inhoud. Al het andere komt regel voor regel overeen.
Dezelfde omzetting op een rommelige invoer
Invoer
a stray comment line
cue-id-1
00:00:01.000 --> 00:00:02.000
No header, two lines before the timecode.
Uitvoer
<SAMI>
<HEAD>
<STYLE TYPE="text/css">
<!--
P { text-align: center; font-family: Arial, sans-serif; }
-->
</STYLE>
</HEAD>
<BODY>
<SYNC Start=1000>
<P>No header, two lines before the timecode.
<SYNC Start=2000>
<P>
</BODY>
</SAMI>
Zo zien echte bestanden eruit — gemengde regeleinden, losse spaties, lege velden. Vergelijk met het nette voorbeeld hierboven om te zien wat de parser vergeeft.
Veelgestelde vragen
Wat gebeurt er met de NOTE-, STYLE- en REGION-blokken van VTT in SMI?
Die vallen weg. Een WebVTT-bestand kan een kop, opmerkingen, een stylesheet, regio-definities en cue-instellingen zoals align of position dragen, en SMI heeft daar geen plek voor: het bewaart cues, geen document. De cues zelf, tekst en tijden, komen heel over. Het STYLE-blok in de SMI-uitvoer is een vaste CSS-regel van de omzetter, geen overname van het jouwe.
Hoe ziet de SMI-uitvoer eruit als VTT wordt omgezet?
Als SAMI: een HEAD met een STYLE-blok, dan een BODY met per cue een SYNC-tag en een P-element met de tekst, en direct daarna een leeg P-blok dat het scherm vrijmaakt. Er zijn geen cue-nummers en geen tijdstempelregels zoals in VTT.
Zijn de VTT-tijden exact in het SMI-bestand?
Ja, tot op de milliseconde — fijner gaat geen van beide formaten. VTT schrijft een moment als 00:00:04.126 en SMI schrijft hetzelfde moment als Start=4126; niets wordt afgerond of verschoven, en een cue die 2,9 seconden in beeld was, blijft dat.
Hoe komt een VTT-blok van twee regels in SMI terecht?
Als twee regels met een <br> ertussen, de manier waarop SAMI een harde regeleinde schrijft. Het paar blijft bij elkaar: de twee VTT-regels horen in de SMI-uitvoer nog steeds bij één ondertitel.
Blijft de volgorde van VTT-blokken bewaard in SMI?
Ja, en ze worden onderweg op begintijd gesorteerd — vroegste eerst, zoals een speler ze leest. Had je VTT-bestand een andere volgorde, dan zet de SMI-uitvoer de blokken terug in de juiste; dat is een structurele wijziging, geen inhoudelijke.
Kan ik de SMI daarna weer naar VTT omzetten?
Ja, en dat is de verliesrijke richting: SMI naar VTT moet de documentlaag van SAMI — zijn STYLE-blok en de SYNC-structuur — vertalen naar iets wat WebVTT uitdrukt, en niet alles heeft een tegenhanger. Deze kant op gaat alleen de documentlaag van VTT verloren.
Behoudt de SMI-uitvoer de tekencodering van het VTT-bestand?
Nee — de uitvoer is UTF-8, met Unix-regeleinden en zonder byte-order mark, wat het VTT-bestand ook gebruikte. Een bestand in UTF-16 of een Windows-eenbytecodering wordt bij het inlezen gedecodeerd; wat eruit komt is altijd dezelfde UTF-8-SMI.