Konwerter napisów LRC na TTML
Albo wklej tekst napisów
Opcje
Używane, gdy źródło nie ma czasów końca (zwykły tekst, LRC). Oś czasu w wyniku jest tu generowana, a nie konwertowana, więc dostajesz dokładnie tę liczbę.
Co zmienia ta konwersja
1 rzecz zostaje pominięta albo wymaga decyzji
- Czasy
czasy końca bloków — źródło ich nie zapisuje, więc czasy w wyniku zostaną wygenerowane, a nie skonwertowane
Ta lista pochodzi z macierzy możliwości tych dwóch formatów, a nie z konkretnego wczytanego pliku. Konkretny plik może stracić więcej, jeśli używa cech, które format dopuszcza, ale macierz ich nie modeluje.
TTML to format XML: każdy napis jest elementem `p` z atrybutami `begin` i `end`, osadzonym w `body`. LRC dostarcza tylko czas rozpoczęcia, więc parser wylicza koniec z początku następnego wiersza, a ostatniemu wierszowi nadaje długość z pola pod obszarem pliku.
Wspólny znacznik w LRC oznacza wiersze, które należą do jednego napisu — najczęściej oryginał i tłumaczenie. W TTML zostają one jednym elementem `p`, a `<br/>` rozdziela linie. Dokument dostaje deklarację XML i przestrzeń nazw TTML, więc jest poprawnym plikiem XML, a nie tylko tekstem z tagami.
Tytuł i wykonawca z nagłówka LRC nie mają w TTML standardowego odpowiednika, więc trafiają do raportu jako strata zamiast być doklejane do treści. Przesunięcie pozostaje zachowane bez zastosowania. Wszystko dzieje się w przeglądarce.
Przykłady
Typowy plik LRC po konwersji na TTML
Wejście
[ti:Sample Song]
[ar:Some Artist]
[length:00:41.00]
[offset:+250]
[00:12.00]First line of the song.
[00:15.30]Second line.
[00:15.30]Second line, translated.
[00:18.00]
[00:21.50]Final line.Wynik
<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling">
<body>
<p begin="00:00:12.000" end="00:00:15.300">First line of the song.</p>
<p begin="00:00:15.300" end="00:00:18.000">Second line.<br/>Second line, translated.</p>
<p begin="00:00:18.000" end="00:00:21.500"></p>
<p begin="00:00:21.500" end="00:00:23.500">Final line.</p> </body>
</tt>
W tym wyniku ginie timing: elementy p dostały końce wyliczone z następnych wierszy LRC.
Ta sama konwersja na nierównym pliku wejściowym
Wejście
[ar:Some Artist]
[0:05.5]Leading zero omitted, one decimal.
[00:07]Second with no centiseconds.
[00:03.00]Out of order.
[00:07.00][00:09.00]Repeated chorus line.
[00:12.00]Wynik
<?xml version="1.0" encoding="UTF-8"?>
<tt xmlns="http://www.w3.org/ns/ttml" xmlns:tts="http://www.w3.org/ns/ttml#styling">
<body>
<p begin="00:00:03.000" end="00:00:05.500">Out of order.</p>
<p begin="00:00:05.500" end="00:00:07.000">Leading zero omitted, one decimal.</p>
<p begin="00:00:07.000" end="00:00:09.000">Second with no centiseconds.<br/>Repeated chorus line.</p>
<p begin="00:00:09.000" end="00:00:12.000">Repeated chorus line.</p>
<p begin="00:00:12.000" end="00:00:14.000"></p> </body>
</tt>
Takie uszkodzenia ma wiele prawdziwych plików: mieszane końce wierszy, zbłąkane spacje, puste pola. Porównaj to z czystym przykładem powyżej, żeby zobaczyć, co parser wybacza.
Częste pytania
Skąd element p w TTML bierze koniec wiersza LRC?
Z początku kolejnego wiersza, bo LRC nie zapisuje końców. TTML wymaga obu atrybutów — `begin` i `end` — więc bez tej reguły nie dałoby się zbudować poprawnego elementu. Ostatni wiersz nie ma następcy i dostaje długość ustawioną na stronie, co raport wyraźnie odnotowuje.
Jak wygląda TTML powstały z pliku LRC?
Zaczyna się deklaracją `<?xml version="1.0" encoding="UTF-8"?>`, potem jest element `tt` z przestrzeniami nazw, a w nim `body` i elementy `p`. Każdy `p` ma atrybuty `begin` i `end` oraz tekst w środku. Numery bloków nie występują — kolejność wynika z czasów.
Jak dwuwierszowy blok LRC wychodzi w TTML?
Jako jeden element `p` z dwiema liniami rozdzielonymi `<br/>`. TTML używa tego pustego elementu do twardego złamania wiersza, więc para z LRC nie rozpada się na dwa napisy. Odtwarzacz wyświetli obie linie razem, w jednym przedziale czasu.
Czy kolejność bloków LRC jest zachowana w TTML?
Tak, po sortowaniu rosnąco według początku. TTML przechowuje elementy `p` w `body`, a odtwarzacze i walidatory oczekują porządku chronologicznego. Plik źródłowy z wierszami poza kolejnością zostanie uporządkowany — to celowa normalizacja struktury, nie zmiana treści.
Co ginie przy powrocie z TTML do LRC?
Timing, style, pozycjonowanie, precyzja oraz konstrukcje specyficzne dla TTML, takie jak metadane dokumentu i regiony. LRC nie ma na nie miejsca i nie zapisuje końców. Zostaje tekst oraz początki wierszy, więc powrót nie odtworzy układu ani wyglądu.
Jakie kodowanie ma TTML powstały z LRC?
Plik jest zapisany w UTF-8, z końcami wierszy LF i bez BOM, co dodatkowo potwierdza deklaracja XML. Wejście w UTF-16 albo w kodowaniu jednobajtowym Windows jest dekodowane przed parsowaniem. Deklaracja w wyniku zawsze mówi UTF-8.