TTML naar LRC
Of plak ondertiteltekst
Wat deze conversie verandert
5 dingen vervallen of vragen om een beslissing
- Timing
de eindtijden van blokken (het uitvoerformaat legt alleen vast wanneer een blok begint)
- Opmaak
alle opmaak (vet, cursief, kleur, contour, schaduw)
- Positionering
positionering op het scherm (elk blok keert terug naar de standaardpositie)
- Nauwkeurigheid
tijdprecisie — de klok van de uitvoer is grover, dus elke tijdstempel wordt afgerond op de dichtstbijzijnde 10 ms
- 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 TTML om naar LRC. Van elk blok blijft alleen het beginmoment over, want LRC kent geen eindtijden: een songtekstspeler laat een regel staan tot de volgende begint. De tijden worden daarbij van milliseconden naar honderdsten teruggebracht.
Daarmee verdwijnt meer dan alleen de eindtijden. LRC heeft geen opmaak, geen positionering en geen plek voor de TTML-head met zijn styling- en layout-tabellen; al die dingen staan in het verliesoverzicht. Wat overblijft zijn de woorden en de momenten waarop ze beginnen.
Een blok van twee regels wordt in LRC twee regels met hetzelfde tijdstempel; zo zegt het formaat dat ze bij elkaar horen. De omzetting draait in je browser, zonder upload; de hele reeks komt als één ZIP terug.
Voorbeelden
Een gewoon TTML-bestand, omgezet naar LRC
Invoer
<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling" xml:lang="en">
<head>
<styling>
<style xml:id="s1" tts:color="#FFFF00" tts:fontWeight="bold"/>
</styling>
<layout>
<region xml:id="bottom" tts:origin="10% 80%" tts:extent="80% 20%"/>
</layout>
</head>
<body>
<div>
<p begin="00:00:01.000" end="00:00:03.500" region="bottom" style="s1">Hello <span tts:fontStyle="italic">there</span>.</p>
<p begin="00:00:03.500" end="00:00:06.000" region="bottom">How are you?<br/>Fine, thanks.</p>
</div>
</body>
</tt>
Uitvoer
[00:01.00]Hello there.
[00:03.50]How are you?
[00:03.50]Fine, thanks.
Hier gaan timing, opmaak, positionering, precisie en formaateigen inhoud verloren: alleen beginmomenten en woorden blijven over. De tekst zelf blijft gelijk.
Dezelfde omzetting op een weerbarstige invoer
Invoer
<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling"
xmlns:ttp="http://www.w3.org/ns/ttml#parameter"
ttp:frameRate="25" xml:lang="en">
<body>
<div>
<p begin="1.5s" dur="2s">Loaded from an offset and a duration.</p>
<p begin="4s" end="00:00:06.50">A coarser clock spelling.</p>
<p begin="00:00:07:00" end="00:00:08:12">Frames, at 25fps.</p>
<p begin="9s"><span tts:color="#FF0000">Half-open</span> and Tom & Jerry.</p>
</div>
</body>
</tt>
Uitvoer
[00:01.50]Loaded from an offset and a duration.
[00:04.00]A coarser clock spelling.
[00:07.00]Frames, at 25fps.
[00:09.00]Half-open and Tom & Jerry.
Dit is het soort schade dat echte bestanden hebben: gemengde regeleinden, losse spaties, een p-element zonder eigen eindtijd. Vergelijk het met het nette voorbeeld hierboven.
Veelgestelde vragen
Wat gebeurt er met de eindtijd van elk TTML-blok?
Die verdwijnt: LRC kent alleen beginmomenten en laat een regel staan tot de volgende begint. Een eindtijd zou daar niets aan toevoegen, dus de beginmomenten van het TTML-bestand blijven ongewijzigd en de eindtijden worden weggelaten.
Wat gebeurt er met vet, cursief en kleur van TTML naar LRC?
LRC bewaart geen enkele vorm van opmaak, dus alles gaat weg: een span met een kleur binnen een p, of een benoemde stijl uit de styling-tabel waarnaar die p verwijst — niets ervan heeft een plek, en elke regel wordt als platte tekst geschreven. De woorden zelf blijven onaangeroerd.
Wat gebeurt er met de plaats op het scherm van TTML naar LRC?
LRC kan niet zeggen waar een ondertitel wordt getekend, dus de region- en style-verwijzingen op een p verdwijnen en elk blok valt terug op de standaardpositie die de speler kiest — bij de meeste spelers onderaan, gecentreerd.
Waarom zijn de tijdstippen van TTML naar LRC verschoven?
LRC bewaart tijd als [00:04.12], in honderdsten van een seconde, terwijl TTML 00:00:04.126 schrijft. Elke tijd wordt daarom op 10 ms afgerond: 4,126 seconden wordt 4,13. Niets wordt uitgerekt of herschikt en geen blok verschuift meer dan 5 ms.
Wat gebeurt er met de TTML-proloog, de styling- en layout-tabellen in LRC?
Die verdwijnen. TTML bewaart uiterlijk en plaatsing in de head: de XML-declaratie, de styling-tabel met benoemde stijlen, de layout-tabel met benoemde regio’s, metadata en de verwijzingen daarop. LRC kent cues, geen document, dus niets uit die head heeft een plek. Opmaak binnen een p-element is ook hier te veel gevraagd: LRC schrijft alles als platte tekst.
Hoe ziet de LRC-uitvoer eruit als TTML daar naartoe gaat?
Als LRC: geen cue-nummers en geen kop, maar per regel een tijdstempel tussen vierkante haken en de tekst. Elk TTML-blok wordt één LRC-regel, in dezelfde volgorde.
Hoe komt een TTML-blok van twee regels in LRC terecht?
Als twee regels met hetzelfde tijdstempel, wat in LRC betekent dat ze bij elkaar horen. De twee regels van het TTML-blok blijven zo één ondertitelblok.
Blijft de volgorde van TTML-blokken in LRC gelijk?
Ja, de regels komen op starttijd te staan, vroegste eerst. Een TTML-bestand dat de blokken door elkaar had, wordt hier rechtgezet; de tekst zelf blijft ongewijzigd.
Kan ik LRC weer naar TTML omzetten?
Ja, met een eigen lijst: LRC naar TTML verliest timing. Die lijst is niet dezelfde als hierboven, omdat beide formaten andere gegevens bewaren.
Blijft de tekencodering van het TTML-bestand in LRC behouden?
Nee, de uitvoer is UTF-8 met Unix-regeleinden en zonder byteordemarkering, wat het TTML-bestand ook gebruikte. Een UTF-16-bestand of een Windows-codering wordt bij het inlezen omgezet; de LRC-uitvoer is altijd gelijk.