Convertire SRT in SBV

SBV è il formato sottotitoli proprio di Google, prodotto dall'editor sottotitoli di YouTube dal 2008 e offerto dal suo strumento di download accanto a SubRip e WebVTT. Praticamente nulla fuori da quell'ecosistema lo scrive e ben poco lo legge, il che lo rende il formato più stretto di questo gruppo e quello con la casa singola più chiara.

Il punto da fare prima di ogni altra cosa è che YouTube accetta SubRip. Se l'obiettivo sono i sottotitoli su un video, caricare l'SRT già in possesso richiede meno passaggi e meno occasioni di introdurre un difetto. Questa conversione si guadagna il suo posto quando qualcosa di diverso dal modulo di caricamento vuole SBV, e la sezione successiva nomina cosa di solito è.

Il caso comune è un archivio. Un canale che fa sottotitoli da anni, o un'agenzia che ne gestisce diversi, tende ad avere centinaia di file in qualunque formato l'editor abbia esportato, e un nuovo episodio che arriva come SRT è l'eccezione. Convertirlo mantiene una directory in un unico formato, il che vale più che risparmiare un passaggio di conversione.

Il secondo è lo strumentario. Poiché SBV non ha intestazione, numerazione né stile, una sua riga è banalmente analizzabile: due timestamp e una virgola. Script, fogli di calcolo e strumenti di controllo qualità costruiti attorno all'esportazione dell'editor tendono a presumere esattamente quella forma, e consegnare loro un SRT con la sua numerazione e la sua freccia significa cambiare lo strumento invece del file.

Il terzo, e quello che la gente menziona meno, è che l'editor sottotitoli è genuinamente migliore di un file di testo per il lavoro di sincronizzazione. Correggere le parole è più veloce offline; correggere dove inizia un sottotitolo è più veloce contro una forma d'onda e un video che si può scorrere. Un team che fa il passaggio di redazione in un documento e il passaggio di sincronizzazione nell'editor ha bisogno che il file si muova in entrambe le direzioni, e SBV è il formato che parla quel lato del flusso di lavoro.

Tre cose, tutte strutturali piuttosto che semantiche. Il numero della battuta sulla propria riga sparisce. La freccia tra i due timestamp diventa una virgola. E i timestamp stessi vengono riscritti nella convenzione SBV invece che in quella SubRip. Il testo, le interruzioni di riga al suo interno e i tempi al millisecondo restano intoccati.

Ecco perché questa conversione è esatta dove conta. Entrambi i formati contengono la stessa cosa — un inizio, una fine e alcune parole — e sono in disaccordo solo su punteggiatura e cerimonia. Nulla deve essere approssimato, arrotondato o scartato, cosa non vera per la maggior parte delle coppie su questo sito.

SubRip scrive l'ora con due cifre: 00:04:12,500. SBV la scrive con tante cifre quante ne servono: 0:04:12.500. Quello zero iniziale singolo è la differenza tra un file che YouTube accetta e uno che rifiuta, ed è il motivo per cui rinominare un SRT in .sbv non ha mai funzionato per nessuno.

I millisecondi sono l'altra metà. SubRip li separa con una virgola e SBV con un punto, lo stesso disaccordo che WebVTT ha con SubRip e nella stessa direzione. Entrambi vengono scritti correttamente qui, tre cifre di millisecondi dopo un punto, quindi il file è ben formato nel momento in cui viene scaricato.

SubRip numera ogni battuta da uno, e il numero è parte del formato piuttosto che una cortesia — un parser rigoroso lo richiede. SBV non ha alcuna numerazione: una riga temporale, una o due righe di testo, una riga vuota, e inizia la voce successiva.

I numeri vengono letti dall'SRT e poi semplicemente non scritti. Non è una perdita, perché nulla in SBV o in YouTube vi fa riferimento, e lasciarli sarebbe peggio che scartarli: un numero vagante sopra una riga temporale si legge come testo del sottotitolo per un parser che non se lo aspettava, e il sottotitolo appare sullo schermo come una cifra.

SBV porta un inizio, una fine e parole. Nessun corsivo, nessun grassetto, nessun colore, nessun posizionamento, nessun modo di segnare chi parla. È più semplice persino di SubRip, che almeno ha una convenzione per il corsivo che la maggior parte dei lettori rispetta.

Il testo delle battute viene copiato letteralmente, quindi qualsiasi tag tra parentesi angolari nella sorgente sopravvive nell'SBV come caratteri letterali, e YouTube lo mostrerà. Una traccia che si appoggia al corsivo per il monologo interiore o per il testo su schermo ha bisogno che quei tag vengano rimossi prima della conversione, e il significato reso di nuovo in parole o punteggiatura se contava. Si rimuovono nell'SRT invece che nell'SBV, così il file master resta quello pulito.

Le parentesi quadre sono la convenzione che colma il vuoto, ed è quella su cui i sottotitoli per trasmissione si sono stabiliti da tempo: una nota tra parentesi per un suono, un parlante o un pezzo di contesto che il dialogo non porta. Costa caratteri sullo schermo, motivo per cui un formato con stile lo evita, ed è compresa da ogni spettatore senza bisogno di spiegazioni. Per qualsiasi cosa debba sopravvivere a un formato senza alcuno stile, vale più di un corsivo che nessuno vedrà.

Le interruzioni di riga dentro un sottotitolo sopravvivono alla conversione come vere interruzioni di riga, ciò che SBV si aspetta: il testo occupa semplicemente due righe tra la riga temporale e la riga vuota. Nulla ha bisogno di escape e nulla viene unito.

L'attribuzione del parlante è il vuoto. Non c'è un costrutto per essa, quindi la convenzione è un nome e due punti digitati nel testo, o un trattino all'inizio della riga di ogni parlante come fanno da sempre i sottotitoli per trasmissione. Se il proprio SRT usava già una convenzione vocale, passa invariata; se si affidava al colore per distinguere due parlanti, quell'informazione non esiste in nessuno dei due formati e deve essere riscritta come parole.

L'output viene scritto come UTF-8, ciò che YouTube si aspetta e ciò che fa sopravvivere al caricamento caratteri accentati e scritture non latine. SubRip non ha modo di dichiarare la propria codifica, quindi la conversione è un momento ragionevole per risolvere la questione invece di lasciarla a un'ipotesi.

Quando un caricamento viene respinto dopo un giro di modifiche a mano, la causa è quasi sempre una di tre cose: un timestamp che ha acquisito zero iniziale o una virgola, una riga vuota tra voci che è scomparsa, o il file salvato in una codifica regionale da un editor che ne usa una per impostazione predefinita. Il messaggio di errore di YouTube non è abbastanza specifico da distinguerle, quindi si controllano tutte e tre.

SubRip dà a un parser tre segnali che un nuovo sottotitolo è iniziato: una riga vuota, un numero da solo, e una riga temporale con una freccia dentro. Se se ne perde uno gli altri due funzionano ancora. SBV ha esattamente un segnale, la riga vuota tra le voci, e una riga temporale viene riconosciuta solo essendo la prima riga di un blocco e contenendo una virgola.

Ciò rende la riga vuota portante in un modo che non è in SubRip. Rimuoverne una durante la modifica — facile da fare unendo due sottotitoli e riordinando dopo — trasforma le due voci in un unico blocco la cui seconda riga temporale viene letta come testo del sottotitolo. YouTube rifiuterà il file o mostrerà un timestamp sullo schermo, e nessuno dei due esiti indica la riga mancante. Quando si corregge un SBV a mano, si trattano le righe vuote come struttura invece che come spazio bianco.

SubRip è ciò che ogni editor di sottotitoli gestisce bene, ciò che ogni lettore legge e ciò che quasi ogni piattaforma accetta. SBV non si legge praticamente da nessuna parte fuori da YouTube e non porta nulla che SubRip non abbia. Come file di lavoro non ha vantaggi, e come formato d'archivio lega un insieme di sottotitoli agli strumenti di un'unica azienda.

La disposizione che sopravvive al contatto con un flusso di lavoro reale è correggere e sincronizzare in SRT, tenere quel file, e convertire nel momento in cui una destinazione particolare chiede qualcos'altro. Due copie mantenute a mano delle stesse tracce sottotitoli divergono la prima volta che qualcuno corregge un refuso in una sola delle due che aveva aperto, e nulla in nessuno dei due file registra quale sia ora quella giusta.