Convertire TTML in SRT
Oppure incollare il testo dei sottotitoli
Cosa cambia questa conversione
3 elementi vengono scartati o richiedono una decisione
- Stile
tutto lo stile (grassetto, corsivo, colore, contorno, ombra)
- Posizionamento
il posizionamento sullo schermo (ogni blocco torna alla posizione predefinita)
- 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.
SRT è il formato che tutti i lettori leggono: un numero, una riga con i due tempi e poi il testo. Un documento TTML porta gli stessi due momenti in attributi `begin` ed `end`, ma al millisecondo e dentro una struttura XML con intestazione, stili e regioni.
Gli orari passano senza arrotondamenti, perché entrambi i formati contano il millisecondo. Non passa nient’altro dell’intestazione: gli stili di `<styling>`, le regioni di `<layout>`, il `<metadata>` e i namespace non hanno un campo nell’SRT. Si perdono formattazione, posizionamento e contenuti specifici del formato.
Un `<p>` con un corsivo interno perde il corsivo, perché l’SRT conserva il testo e non l’enfasi. Un `<p>` su due righe resta un solo cue, con le due righe una sotto l’altra. La conversione avviene nel browser; più file insieme arrivano in un unico ZIP.
Esempi
Un file TTML tipico, convertito in SRT
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
1
00:00:01,000 --> 00:00:03,500
Hello <i>there</i>.
2
00:00:03,500 --> 00:00:06,000
How are you?
Fine, thanks.
In questa conversione si perdono la formattazione, il posizionamento 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
1
00:00:01,500 --> 00:00:03,500
Loaded from an offset and a duration.
2
00:00:04,000 --> 00:00:06,500
A coarser clock spelling.
3
00:00:07,000 --> 00:00:08,480
Frames, at 25fps.
4
00:00:09,000 --> 00:00:11,000
<font color="#FF0000">Half-open</font> and Tom & Jerry.
Namespace spaiati, entità non dichiarate e paragrafi vuoti: il file è sporco ma legale, e il confronto con l’esempio ordinato mostra fin dove arriva la tolleranza del parser.
Domande frequenti
Che aspetto ha l’output quando TTML diventa SRT?
Ha l’aspetto dell’SRT: un numero progressivo, una riga con i due tempi e poi il testo, per ogni cue. Ogni elemento `<p>` diventa un cue SRT, nello stesso ordine e con lo stesso testo.
I millisecondi del TTML arrivano intatti nell’SRT?
Sì: entrambi i formati contano il millisecondo, quindi `00:00:04.126` diventa `00:00:04,126` senza arrotondamenti e senza spostamenti. È una delle poche cose che questa direzione non perde.
Che ne è dello stile TTML quando il file diventa SRT?
Niente: il colore di `tts:color`, il peso di `tts:fontWeight` e la famiglia di `tts:fontFamily` non hanno un campo nell’SRT. Il testo resta e la formattazione no, ed è la perdita che si nota di più guardando il risultato.
Che ne è delle regioni `<layout>` quando il documento TTML diventa SRT?
Spariscono: l’SRT non ha un modo per dire dove deve stare un cue, quindi `tts:origin` ed `tts:extent` e i riferimenti `region=` non hanno destinazione. Il testo si legge, la posizione sullo schermo no.
Come esce in SRT un paragrafo TTML con una parola in corsivo?
Come testo semplice: il `<span tts:fontStyle="italic">` interno al `<p>` viene sciolto e la parola resta, senza il marcatore che la distingueva. L’SRT conserva le parole, non l’enfasi.
Come esce in SRT un paragrafo TTML su due righe?
Come due righe, una sotto l’altra. L’accoppiamento resta: le due righe appartengono ancora a un solo sottotitolo nell’output SRT, e il lettore le mostra insieme.
Che cosa si perde dell’intestazione TTML nella conversione in SRT?
Il `<metadata>`, la dichiarazione XML, i namespace e gli attributi che l’SRT non prevede. Il rapporto li conta come contenuto specifico del formato invece di lasciarli sparire senza dirlo.
I cue mantengono l’ordine nell’output SRT?
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, l’SRT li rimette in ordine.
L’output SRT 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 SRT in UTF-8.