Konwerter napisów TTML na LRC
Albo wklej tekst napisów
Co zmienia ta konwersja
5 rzeczy zostaje pominiętych albo wymaga decyzji
- Czasy
czasy końca bloków (format docelowy zapisuje tylko, kiedy blok się zaczyna)
- Formatowanie
całe formatowanie (pogrubienie, kursywa, kolor, obrys, cień)
- Pozycjonowanie
pozycjonowanie na ekranie (każdy blok wraca do domyślnego położenia)
- Dokładność
dokładność czasów — zegar wyniku jest grubszy, więc każdy znacznik czasu jest zaokrąglany do najbliższych 10 ms
- Treści specyficzne dla formatu
treść, którą format źródłowy trzyma poza blokami (bloki niebędące napisami, tekst nagłówka, ustawienia pojedynczych bloków, zakomentowane zdarzenia) — format docelowy nie ma dla niej miejsca
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.
Ta strona konwertuje TTML na LRC. Wrzuć plik albo wklej tekst, a dostaniesz z powrotem wersję LRC. Konwersja odbywa się w całości w Twojej przeglądarce — nic nie jest wysyłane i nie potrzebujesz konta.
Te dwa formaty nie przechowują tego samego, a różnica nie jest kosmetyczna: czasy, styl, pozycjonowanie, precyzja i konstrukcje charakterystyczne dla formatu nie mają gdzie się podziać w LRC. Powyższa lista wynika z tego, co potrafi wyrazić każdy z formatów, a nie z zawartości Twojego pliku — więc odpowiedź jest taka sama, zanim cokolwiek wczytasz.
Jeden plik to żaden problem, podobnie cały sezon: kolejka przetwarza je po kolei, a wyniki pobierasz razem w jednym archiwum ZIP.
Przykłady
Typowy plik TTML po konwersji do LRC
Wejście
<?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>
Wynik
[00:01.00]Hello there.
[00:03.50]How are you?
[00:03.50]Fine, thanks.
W tym wyniku przepada: czasy, styl, pozycjonowanie, precyzja i konstrukcje charakterystyczne dla formatu. Reszta zgadza się linia w linię.
Ta sama konwersja na trudniejszym pliku
Wejście
<?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>
Wynik
[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.
To typowe uszkodzenia prawdziwych plików — mieszane końce wierszy, zbłąkane spacje, puste pola. Porównaj z uporządkowanym przykładem powyżej, żeby zobaczyć, co parser wybacza.
Częste pytania
Co dzieje się z czasem zakończenia bloku TTML przy konwersji na LRC?
LRC zapisuje tylko moment rozpoczęcia linii — odtwarzacz tekstu trzyma ją do następnej, więc koniec byłby zbędny. Każdy `end` z TTML zostaje odrzucony, a każdy `begin` pozostaje bez zmian.
Co dzieje się z pogrubieniem, kursywą i kolorem przy przejściu z TTML do LRC?
LRC nie przechowuje żadnego stylu, więc wszystko znika: zarówno `<span tts:color="…">` wewnątrz akapitu, jak i styl nazwany z tabeli `<styling>`. Każda linia jest zapisana jako czysty tekst, a same słowa pozostają nietknięte.
Co dzieje się z pozycją napisu przy konwersji TTML na LRC?
LRC nie potrafi wskazać miejsca na ekranie, więc `region` i `style` z `<p>` znikają, a każdy blok wraca do domyślnego położenia odtwarzacza — zwykle na dół kadru, pośrodku.
Dlaczego czasy zmieniają się przy konwersji TTML na LRC?
LRC zapisuje czas jako `[00:04.12]`, a TTML jako `00:00:04.126` — setne zamiast tysięcznych. Każdy znacznik jest zaokrąglany do 10 ms: 4,126 s daje 4,13 s. Przesunięcie nie przekracza 5 ms, ale to jedyne miejsce, gdzie ta konwersja traci precyzję.
Co dzieje się z prologiem TTML oraz tabelami `<styling>` i `<layout>` w LRC?
Nie mają gdzie trafić, więc przepadają: deklaracja XML, style nazwane, regiony i metadane nie mieszczą się w formacie `[mm:ss.xx]tekst`. Nacisk zapisany w akapicie jest równie bezradny — LRC nie ma żadnego znacznika formatowania, więc `<span tts:fontStyle="italic">` zostaje tylko słowami.
Jak wygląda plik LRC powstały z TTML?
Każda linia ma własny znacznik w nawiasach, np. `[00:04.50]`, a nagłówek `[ti:…]` pojawia się tylko wtedy, gdy dokument ma tytuł. Każdy blok TTML daje jedną lub więcej linii LRC, w tej samej kolejności i z tym samym tekstem.
Jak dwuwierszowy blok TTML wychodzi w LRC?
Jako dwie linie z tym samym znacznikiem czasu — tak LRC mówi, że należą do siebie. Para zostaje zachowana, a odtwarzacz pokazuje obie linie jednocześnie.
Czy LRC zachowuje kolejność bloków TTML?
Tak, po sortowaniu po czasie rozpoczęcia. Linie idą od najwcześniejszej, więc plik TTML z zaburzoną kolejnością zostanie uporządkowany; to zmiana struktury, nie treści.
Czy da się wrócić z LRC do TTML?
Tak, ale ten kierunek ma własną listę strat: konwersja LRC na TTML traci czasy zakończenia, bo LRC ich nie zapisuje. Lista różni się od powyższej, ponieważ oba formaty przechowują inne rzeczy.
Czy LRC zachowuje kodowanie pliku TTML?
Nie, wynik jest w UTF-8 z końcami LF i bez BOM. Kodowanie źródła jest rozpoznawane i konwertowane przy wczytaniu, o czym mówi panel wyniku; plik LRC ma już zawsze stałe kodowanie.