Convertire TTML in LRC
Oppure incollare il testo dei sottotitoli
Cosa cambia questa conversione
5 elementi vengono scartati o richiedono una decisione
- Temporizzazione
gli orari di fine dei blocchi (il formato di uscita registra solo quando un blocco inizia)
- Stile
tutto lo stile (grassetto, corsivo, colore, contorno, ombra)
- Posizionamento
il posizionamento sullo schermo (ogni blocco torna alla posizione predefinita)
- Precisione
la precisione della temporizzazione — l’orologio dell’uscita è più grossolano, quindi ogni timestamp è arrotondato al 10 ms più vicino
- Contenuto specifico del formato
il contenuto che il formato di partenza tiene fuori dai suoi blocchi (blocchi non-cue, testo di intestazione, impostazioni per blocco, eventi commentati) — il formato di destinazione non ha un posto per esso
Questo elenco deriva dalla matrice delle capacità di questi due formati, non dal particolare file caricato. Un file specifico può perdere di più se usa caratteristiche che il formato consente ma la matrice non modella.
LRC è un formato per versi cantati: un timestamp tra parentesi quadre e il testo, senza un momento di fine perché la riga dura fino alla successiva. Un documento TTML porta invece `begin` ed `end` per ogni `<p>`, e in più l’intestazione con gli stili.
La conversione è la più perdente delle dodici direzioni del TTML. Le fini non hanno dove andare; gli stili di `<styling>` e le regioni di `<layout>` non hanno un campo; e il TTML arriva al millisecondo mentre il LRC scrive i centesimi (`[00:04.12]`), quindi ogni timecode viene arrotondato ai 10 ms più vicini. Restano il testo e l’ordine.
Si perdono temporizzazione, formattazione, posizionamento, precisione e contenuti specifici del formato. Un `<p>` su due righe diventa due righe con lo stesso timestamp, che è il modo in cui il LRC dice che stanno insieme. Tutto avviene nel browser; più file arrivano in un unico ZIP.
Esempi
Un file TTML tipico, convertito in LRC
Ingresso
<?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>
Uscita
[00:01.00]Hello there.
[00:03.50]How are you?
[00:03.50]Fine, thanks.
In questa conversione si perdono la temporizzazione, la formattazione, il posizionamento, la precisione e i contenuti specifici del formato. Tutto il resto resta identico, riga per riga.
La stessa conversione su un input difficile
Ingresso
<?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>
Uscita
[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.
È il tipo di danno che i file reali hanno davvero: namespace fuori posto, entità non dichiarate, elementi vuoti. Confrontandolo con l’esempio ordinato qui sopra si vede che cosa il parser perdona.
Domande frequenti
Che ne è del tempo di fine di ogni paragrafo TTML?
LRC registra solo quando una riga comincia: un lettore la tiene su finché non parte la successiva, quindi la fine non ha un campo dove stare. Ogni `end` viene eliminato e ogni `begin` resta al suo posto.
Perché i timecode si sono spostati passando da TTML a LRC?
Il TTML arriva al millisecondo (`00:00:04.126`) e il LRC scrive i centesimi (`[00:04.12]`), quindi ogni tempo viene arrotondato ai 10 ms più vicini: 4,126 secondi esce come 4,13. Nulla viene allungato o riordinato e nessun cue si muove di più di 5 ms, ma è un punto in cui la conversione perde esattezza.
Che ne è dello stile TTML quando il file diventa LRC?
Niente: il colore di `tts:color`, il peso di `tts:fontWeight` e la famiglia di `tts:fontFamily` non hanno un campo nel LRC. Il testo resta e la formattazione no, perché il formato di destinazione non sa esprimerla.
Che ne è delle regioni `<layout>` del TTML?
Spariscono: il LRC non ha un modo per dire dove deve stare una riga, quindi `tts:origin` ed `tts:extent` e i riferimenti `region=` non hanno destinazione. Il verso si legge, la posizione sullo schermo no.
Che aspetto ha l’output quando TTML diventa LRC?
Ha l’aspetto del LRC: nessun numero di cue, ogni riga porta il proprio timestamp tra parentesi quadre e non c’è intestazione. Ogni cue TTML diventa un cue LRC, nello stesso ordine e con lo stesso testo.
Come esce in LRC un paragrafo TTML su due righe?
Come due righe con lo stesso timestamp, che è il modo in cui il LRC dice «queste due stanno insieme». L’accoppiamento resta: le due righe appartengono ancora a un solo sottotitolo nell’output LRC.
Che cosa si perde dell’intestazione TTML?
Il `<metadata>`, la dichiarazione XML, i namespace e gli attributi che né il LRC né il modello comune sanno rappresentare. Il rapporto li conta come contenuto specifico del formato invece di lasciarli sparire senza dirlo.
I cue mantengono l’ordine nell’output LRC?
Sì, e vengono ordinati per tempo di inizio lungo la strada: prima i più antichi, come si aspetta ogni formato di questo sito. Se il documento TTML elencava i paragrafi fuori sequenza, il LRC li rimette in ordine.
Posso riconvertire il LRC in TTML?
Sì, e ha un elenco suo: convertire LRC in TTML perde la temporizzazione. Quell’elenco è diverso da quello qui sopra perché i due formati conservano cose diverse: il LRC non ha fini, quindi non può restituirle.
L’output LRC conserva la codifica del documento TTML?
No: l’output è UTF-8, con fine riga Unix e senza BOM, qualunque codifica dichiarasse il documento TTML. Ciò che esce è sempre lo stesso LRC in UTF-8.