SRT naar SMI
Of plak ondertiteltekst
Wat deze conversie verandert
In deze richting gaat niets verloren — elk kenmerk van het bronformaat heeft in het doelformaat een plek.
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 SRT om naar SMI. Sleep een bestand erin — of plak de tekst — en je krijgt de SMI-versie terug. De omzetting draait volledig in je browser, dus niets wordt geüpload en je hebt geen account nodig.
In deze richting gaat niets verloren. Elke eigenschap die SRT kan uitdrukken heeft een equivalent in SMI, dus de uitvoer is dezelfde ondertitels in een ander omhulsel — de tijdlijn, de regeleinden en de tekst overleven allemaal. Dat geldt voor elk SRT-bestand, ook voor een dat elke functie van het formaat gebruikt.
Eén bestand is prima, en een heel seizoen ook: de wachtrij werkt ze in volgorde af en de resultaten komen samen als één ZIP binnen.
Voorbeelden
Een typisch SRT-bestand, omgezet naar SMI
Invoer
1
00:00:01,000 --> 00:00:03,500
Hello there.
2
00:00:03,500 --> 00:00:06,000
<i>Whispering</i> now.
And a second line.
3
00:00:06,000 --> 00:00:09,250
<b>Bold</b> statement.
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=3500>
<P>
<SYNC Start=3500>
<P><i>Whispering</i> now.<br>And a second line.
<SYNC Start=6000>
<P>
<SYNC Start=6000>
<P><b>Bold</b> statement.
<SYNC Start=9250>
<P>
</BODY>
</SAMI>
Hier gaat niets verloren: vergelijk beide kanten regel voor regel.
Dezelfde omzetting op een rommelige invoer
Invoer
1
0:00:01,00 --> 0:00:03,500
<B>Bold</B> and <I>italic</I>.
2
00:00:03,500 --> 00:00:06,000
3
00:00:08,000 --> 00:00:09,000
Last one.
Uitvoer
<SAMI>
<HEAD>
<STYLE TYPE="text/css">
<!--
P { text-align: center; font-family: Arial, sans-serif; }
-->
</STYLE>
</HEAD>
<BODY>
<SYNC Start=1000>
<P><b>Bold</b> and <i>italic</i>.
<SYNC Start=3500>
<P>
<SYNC Start=3500>
<SYNC Start=6000>
<P>
<SYNC Start=8000>
<P>Last one.
<SYNC Start=9000>
<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
Hoe ziet de SMI-uitvoer eruit als SRT wordt omgezet?
Als SMI: geen bloknummers en geen tijdstempelregel — elk blok is een <SYNC Start=…>-tag met de tekst in een <P> eronder, en omdat een SYNC vervangt wat op het scherm stond, volgt direct daarna een <P> -blok dat het scherm weer leegmaakt. Bovenin staat een <STYLE TYPE="text/css">-blok met de basisregel voor <P>.
Zijn de SRT-tijden exact in het SMI-bestand?
Ja, tot op de milliseconde — fijner gaat geen van beide formaten. SRT schrijft een moment als 00:00:04,126 en SMI schrijft hetzelfde moment als Start=4126; niets wordt afgerond of verschoven, en een blok dat 2,9 seconden in beeld was, blijft dat.
Hoe komt een SRT-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 SRT-regels horen in de SMI-uitvoer nog steeds bij één ondertitel, en een speler toont ze samen.
Blijft de volgorde van SRT-blokken bewaard in SMI?
Ja, en ze worden onderweg op begintijd gesorteerd — vroegste eerst, zoals spelers ze lezen. Had je SRT-bestand een andere volgorde, dan zet de SMI-uitvoer de blokken terug in de juiste; dat is een wijziging aan de structuur, niet aan de inhoud.
Kan ik de SMI daarna weer naar SRT omzetten?
Ja, en dat is de verliesrijke richting: opmaak, positionering en formaateigen inhoud hebben in SRT geen plek. Deze kant op gaat niets verloren, dus die prijs betaal je alleen als je teruggaat.
Behoudt de SMI-uitvoer de tekencodering van het SRT-bestand?
Nee — de uitvoer is UTF-8, met Unix-regeleinden en zonder byte-order mark, wat het SRT-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.