SRT naar LRC
Of plak ondertiteltekst
Wat deze conversie verandert
2 dingen vervallen of vragen om een beslissing
- Timing
de eindtijden van blokken (het uitvoerformaat legt alleen vast wanneer een blok begint)
- Nauwkeurigheid
tijdprecisie — de klok van de uitvoer is grover, dus elke tijdstempel wordt afgerond op de dichtstbijzijnde 10 ms
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 LRC. Sleep een bestand erin — of plak de tekst — en je krijgt de LRC-versie terug. De omzetting draait volledig in je browser, dus niets wordt geüpload en je hebt geen account nodig.
Deze twee formaten bewaren niet dezelfde dingen, en het verschil is niet cosmetisch: timing en precisie hebben in LRC geen plek. De lijst hierboven komt uit wat beide formaten elk kunnen uitdrukken, niet uit jouw bestand, dus het antwoord is hetzelfde voordat je iets laadt.
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 LRC
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
[00:01.00]Hello there.
[00:03.50]Whispering now.
[00:03.50]And a second line.
[00:06.00]Bold statement.
In deze uitvoer verloren: timing en precisie. Al het andere komt regel voor regel overeen.
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
[00:01.00]Bold and italic.
[00:03.50]
[00:08.00]Last one.
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 SRT-blok in LRC?
LRC legt vast wanneer een regel begint en niets anders — een songtekstspeler houdt een regel in beeld tot de volgende begint, dus een eindtijd zou overbodig zijn. Elk eind valt weg en elke SRT-start blijft onaangeroerd.
Waarom verschuiven de tijdstempels van SRT naar LRC?
LRC bewaart tijd als [00:04.12] waar SRT 00:00:04,126 bewaart — een honderdste tegen een duizendste — dus elke tijdcode wordt op de dichtstbijzijnde 10 ms afgerond: 00:00:04,126 wordt 4,13 seconden. Niets wordt uitgerekt of herordend en geen blok 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.
Hoe ziet de LRC-uitvoer eruit als SRT wordt omgezet?
Als LRC: geen bloknummers, maar elke regel draagt zijn eigen tijdstempel tussen vierkante haken. Elk SRT-blok wordt één LRC-regel, in dezelfde volgorde, met dezelfde tekst.
Hoe komt een SRT-blok van twee regels in LRC terecht?
Als twee regels met dezelfde tijdstempel, de manier waarop LRC zegt dat die twee bij elkaar horen. Het paar blijft bij elkaar — de twee SRT-regels horen in de LRC-uitvoer nog steeds bij één ondertitel, en een speler toont ze samen.
Blijft de volgorde van SRT-blokken bewaard in LRC?
Ja, en ze worden onderweg op begintijd gesorteerd — vroegste eerst, zoals elk formaat hier ze verwacht. Stond je SRT-bestand niet in tijdsorde, dan zet de LRC-uitvoer de regels terug in de juiste; dat is een structurele wijziging, geen inhoudelijke, en ze is bewust.
Kan ik de LRC daarna weer naar SRT omzetten?
Ja, en die richting heeft zijn eigen lijst: LRC naar SRT verliest timing, omdat LRC geen eindtijden bewaart en de omzetter ze dus moet verzinnen. Die lijst verschilt van de lijst hierboven.
Behoudt de LRC-uitvoer de tekencodering van het SRT-bestand?
Nee — de uitvoer is UTF-8, met Unix-regeleinden en zonder byte-order mark, ongeacht wat het SRT-bestand gebruikte. Een bestand in UTF-16 of een Windows-eenbytecodering wordt bij het inlezen gedecodeerd; wat eruit komt is altijd dezelfde UTF-8-LRC.