VTT naar LRC
Of plak ondertiteltekst
Wat deze conversie verandert
4 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)
- 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 WebVTT om naar LRC, het formaat dat songtekstspelers lezen. LRC bewaart per regel wanneer hij begint, en niets anders: geen eindtijd, geen documentlaag. Elke VTT-cue wordt dus één regel met een tijdstempel tussen vierkante haken, in de volgorde waarin de cues staan.
Dat kost drie dingen. De eindtijden verdwijnen, omdat een songtekstspeler een regel in beeld houdt tot de volgende begint. De tijd wordt in centiseconden bewaard, dus 00:00:04.500 wordt 4,50 seconden en een cue kan hooguit 5 ms verschuiven. En alle opmaak valt weg: een <i> of <b> in de tekst, of een regel uit het STYLE-blok, heeft in LRC geen plek — elke regel wordt platte tekst.
Daar komt de documentlaag van WebVTT bij: de kop, de NOTE-, STYLE- en REGION-blokken en de instellingen zoals align:start of position:10% hebben in LRC geen equivalent. Het verliesoverzicht noemt ze voordat je iets laadt, en de omzetting zelf draait lokaal in je browser.
Voorbeelden
Een typisch VTT-bestand, omgezet naar LRC
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
[00:01.00]Hello there.
[00:04.50]Second line with italics.
In deze uitvoer verloren: timing, styling, precisie en 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
[00:01.00]No header, two lines before the timecode.
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 eindtijd van elk VTT-blok in LRC?
Die valt weg. LRC legt alleen vast wanneer een regel begint; een songtekstspeler laat hem staan tot de volgende regel komt, dus een eindtijd zou overbodig zijn. De begintijd van elke VTT-cue blijft behouden.
Wat gebeurt er met vet, cursief en kleur van VTT naar LRC?
LRC bewaart geen opmaak van welke soort dan ook, dus alles gaat eruit: een <b> of <i> in de cuetekst, of een regel in het STYLE-blok van het bestand. Niets ervan heeft een plek, en elke regel wordt als platte tekst geschreven. De woorden zelf blijven onaangeroerd.
Waarom zijn de tijdstempels van VTT naar LRC verschoven?
LRC bewaart tijd als [00:04.50] waar VTT 00:00:04.500 bewaart — een honderdste tegen een duizendste — dus elke tijdcode wordt op de dichtstbijzijnde 10 ms afgerond. Niets wordt uitgerekt of herordend en geen cue verschuift meer dan 5 ms, maar bij het uitlijnen tegen een ander bestand is dit de enige plek waar de omzetting niet meer exact is.
Wat gebeurt er met de NOTE-, STYLE- en REGION-blokken van VTT in LRC?
Die vallen weg. Een WebVTT-bestand kan een kop, opmerkingen, een stylesheet, regio-definities en cue-instellingen zoals align of position dragen, en LRC heeft daar geen plek voor: het bewaart regels met een tijd, geen document. De cues zelf, tekst en begintijden, komen heel over.
Hoe ziet de LRC-uitvoer eruit als VTT wordt omgezet?
Als LRC: geen cue-nummers en geen tijdstempelregel — elke regel draagt zijn eigen tijdstempel tussen vierkante haken, gevolgd door de tekst. Elke VTT-cue wordt één LRC-regel, in dezelfde volgorde, met dezelfde woorden.
Hoe komt een VTT-blok van twee regels in LRC terecht?
Als twee regels met dezelfde tijdstempel, de manier waarop LRC zegt dat ze bij elkaar horen. Het paar blijft bij elkaar: de twee VTT-regels horen in de LRC-uitvoer nog steeds bij één ondertitel, en een speler toont ze samen.
Blijft de volgorde van VTT-blokken bewaard in LRC?
Ja, en ze worden onderweg op begintijd gesorteerd — vroegste eerst, zoals een songtekstspeler ze verwacht. Stond je VTT-bestand niet in tijdsorde, dan zet de LRC-uitvoer de regels terug in de juiste; dat is een structurele wijziging, geen inhoudelijke.
Kan ik de LRC daarna weer naar VTT omzetten?
Ja, maar die richting moet de eindtijden verzinnen die LRC nooit heeft bewaard, en dat staat als verlies in het overzicht van die pagina. De documentlaag van WebVTT — kop, NOTE, STYLE, REGION en cue-instellingen — komt ook niet terug.
Behoudt de LRC-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-LRC.