Video e sottotitoli · Toolkit sottotitoli
Perché i tag vaganti in un file di sottotitoli possono interrompere il caricamento di una didascalia sulla piattaforma
· Perché è importante
sottotitoli elaborazione del testo webvtt
Le piattaforme analizzano i caricamenti dei sottotitoli in modo rigoroso e spesso silenzioso. Questo post spiega i motivi più comuni per cui un file di sottotitoli viene rifiutato o viene visualizzato in modo strano, perché i tag e i codici di formattazione sono i soliti colpevoli e come un file pulito e standard evita il problema.
Il caricamento è stato accettato e le didascalie mostrano tag letterali: il silenzioso fallimento di un file sporco
Il risultato peggiore non è il rifiuto. Un caricamento rifiutato ti dice che qualcosa non va mentre stai ancora guardando il modulo. Il risultato comune è l'accettazione seguita da didascalie che mostrano il proprio markup agli spettatori, perché il controllo del caricamento e il percorso di rendering sono parti software diverse che pongono domande diverse.
Il controllo del caricamento di solito chiede se il file viene analizzato in segnali. Il rendering chiede cosa fare con il contenuto di ogni segnale e un parser che ignora un tag sconosciuto lo disegna come testo. Entrambi i passaggi hanno fatto ciò per cui erano stati progettati.
Cosa accettano effettivamente le piattaforme: SRT semplice e WebVTT con struttura prevedibile e poca tolleranza per gli extra
Ciò che le piattaforme accettano è più limitato di ciò che gli strumenti emettono. In pratica ciò significa semplice SRT o WebVTT con una forma prevedibile: blocchi separati da righe vuote, una riga di timecode, righe di testo e poco altro. La tolleranza per gli extra è bassa e, cosa ancora più importante, non documentata, quindi il presupposto sicuro è che qualsiasi cosa oltre quella forma sia un rischio piuttosto che una caratteristica.
Questo non è conservatorismo fine a se stesso. Una piattaforma che accettasse markup arbitrari dovrebbe decidere come renderli coerenti su client web, mobili e televisivi, il che rappresenta un impegno molto più grande che accettare un file di sottotitoli.
I soliti colpevoli: tag tipo HTML, codici stile ASS, distinte materiali, terminazioni di riga miste e segnali vuoti
I colpevoli ricorrenti sono pochi. I tag tra parentesi angolari per il corsivo, le voci degli oratori e le classi cue sopravvivono alla conversione dai formati che li supportano. I codici di override delimitati da parentesi graffe arrivano dai formati SubStation e non significano nulla al di fuori di essi. Un contrassegno dell'ordine dei byte all'inizio del file si attacca al primo numero di indice. Terminazioni di riga miste dalla divisione dei blocchi di interruzione della modifica multipiattaforma. I segnali il cui testo è diventato vuoto dopo la rimozione del markup rimangono come spazi vuoti con timestamp.
Nessuno di questi è esotico. Sono il normale risultato di una catena di conversione in cui ogni passaggio era individualmente ragionevole, motivo per cui appaiono in file che appaiono bene in un editor.
Perché una piattaforma tollera ciò che un'altra rifiuta: parser diversi dietro moduli di caricamento simili
Piattaforme diverse tollerano sottoinsiemi diversi e questo è ciò che rende difficile la diagnosi del guasto. Lo stesso file può essere caricato in modo pulito ed eseguito correttamente su un servizio, caricato ed eseguito il rendering del markup su un secondo ed essere rifiutato da un terzo, senza alcun messaggio di errore che indichi la causa effettiva. Il file non è cambiato tra i tentativi; tre parser non erano d'accordo.
Trattare una piattaforma come riferimento è quindi un istinto sbagliato. Un file che funziona sul servizio più permissivo non ti dice nulla sugli altri, e il parser più rigoroso è quello che definisce se un file è portabile.
Esempio pratico: un file, tre caricamenti: come lo stesso disordine si presenta in modo diverso e scompare dopo la pulizia
Prendiamo un'esportazione che trasporta un codice di override della parte superiore del fotogramma su sessanta cue, tag di enfasi su quaranta e un contrassegno dell'ordine dei byte. Caricato su tre servizi potrebbe essere accettato ovunque. Nella prima i tag vengono onorati e il codice di override viene disegnato letteralmente. Nel secondo appaiono entrambi come testo. Alla terza il segno costa la prima battuta, che semplicemente non appare mai, e nessuno se ne accorge perché la riga di apertura è solitamente un titolo.
La pulizia una volta rimuove tutte e tre le classi alla fonte. I tag delle parentesi angolari e i codici delle parentesi graffe vengono sostituiti, lo spazio bianco lasciato viene collassato, i segnali svuotati dalle rimozioni vengono eliminati anziché emessi come spazi vuoti con timestamp e il file viene riscritto con i segnali rinumerati in modo contiguo da uno. Lo stesso output va quindi a tutti e tre i servizi.
Ciò che questo non copre: guide di stile specifiche della piattaforma, limiti di caratteri per riga e didascalie integrate
Ciò riguarda la portabilità strutturale, non la conformità editoriale. Le guide di stile della piattaforma sulla lunghezza della riga, il numero massimo di caratteri, il posizionamento delle etichette degli altoparlanti e la gestione degli effetti sonori sono requisiti separati che un file pulito non soddisfa automaticamente. Un file di sottotitoli strutturalmente perfetto può comunque violare una guida di stile.
I sottotitoli incorporati sono un meccanismo completamente diverso. Il testo visualizzato nei fotogrammi video non è un file di didascalie, non può essere disattivato e non è influenzato da quanto descritto qui.
Conclusione: pulisci una volta, carica ovunque: come le funzionalità di pulizia e conversione di Subtitle Toolkit producono un file compatibile con la piattaforma
Pulisci una volta e carica lo stesso file ovunque. L'alternativa, mantenendo un'esportazione separata per piattaforma, moltiplica il numero di file che possono non essere sincronizzati con il master e non rimuove il disordine sottostante da nessuno di essi.
Esegui insieme la pulizia e la conversione, quindi leggi i problemi segnalati prima del caricamento anziché dopo. I problemi chiamano i segnali in base al numero, che è la differenza tra sapere che un file ha un problema e sapere quale riga guardare.