Video e sottotitoli · Toolkit sottotitoli
Codici temporali dei sottotitoli a confronto: SRT virgole, VTT punti e SMPTE fotogrammi
· Sfondo
sottotitoli codici temporali frame-rate
Tre modi di scrivere l'ora vengono visualizzati nel lavoro dei sottotitoli: HH:MM:SS,mmm di SRT, HH:MM:SS.mmm di WebVTT e HH:MM:SS:FF di SMPTE. Questo post spiega cosa significa ciascuno, come convertono e dove le conversioni vanno storte.
Lo stesso momento scritto in tre modi: un rapido tour dei codici temporali che un editor incontra in un progetto
Un progetto può consegnare a un editore lo stesso istante scritto in tre modi. Il file dei sottotitoli utilizza ore, minuti, secondi e una virgola prima dei millisecondi. Il file dei sottotitoli web utilizza un punto nella stessa posizione. L'elenco delle decisioni di modifica utilizza un numero di fotogramma anziché una frazione. Tutti e tre nominano lo stesso momento e solo uno di essi può essere letto senza sapere altro del materiale.
Quest’ultimo punto è quello che conta. Due di queste notazioni sono assolute e una no, e le conversioni tra di esse falliscono in modo specifico quando la differenza viene trascurata.
Millisecondi con una virgola: SRT — un'abitudine decimale europea diventata una regola di formato
SRT scrive ore, minuti, secondi, una virgola ed esattamente tre cifre di millisecondi. La virgola è un separatore decimale nella convenzione europea, ed è diventata una regola di formato per uso piuttosto che per specifica, poiché SubRip non aveva documenti standard per risolverlo. Niente nel valore è europeo; solo la punteggiatura lo è.
Il parser qui legge i millisecondi riempiendo qualunque cifra trovi a destra fino a tre, quindi un timestamp che termina con una singola cifra viene letto come centinaia di millisecondi anziché come unità. Ciò è importante perché i file scritti a mano o da un convertitore sciolto non sempre forniscono tre cifre e leggere una singola cifra finale come unità posizionerebbe l'indicazione quasi un secondo in anticipo.
Millisecondi con un punto: WebVTT: lo stesso valore, separatore diverso e perché è importante per i parser
WebVTT scrive lo stesso valore con un punto e consente di omettere completamente il campo delle ore, quindi un modulo a due campi è valido dove SRT ne prevede tre. Per un parser queste sono grammatiche veramente diverse, motivo per cui un file può essere rifiutato solo per la punteggiatura nonostante ogni numero in esso contenuto sia corretto.
I file reali mescolano costantemente i due, quindi il parser accetta entrambi i separatori indipendentemente dal formato che il file afferma di essere. Tale tolleranza è solo sull'input. In output il separatore viene scelto dal formato di destinazione, una virgola per SRT e un punto per WebVTT, quindi un file convertito è canonico piuttosto che una copia di qualunque irregolarità arrivata.
Fotogrammi: SMPTE timecode — HH:MM:SS:FF, la sua dipendenza dal frame rate e la complicazione del drop-frame
Il timecode SMPTE sostituisce la parte frazionaria con un numero di fotogramma, fornendo ore, minuti, secondi e fotogrammi. A differenza degli altri due, non può essere interpretato da solo: il fotogramma dodici è un istante diverso a venticinque fotogrammi al secondo rispetto a trenta, quindi un codice temporale basato sui fotogrammi senza una velocità dichiarata è incompleto piuttosto che semplicemente ambiguo.
Il drop frame aggiunge una seconda complicazione. Il materiale a 29.97 fotogrammi al secondo viene conteggiato come se fosse trenta e per mantenere il conteggio allineato con l'orologio vengono saltati due numeri di fotogrammi all'inizio della maggior parte dei minuti, escludendo ogni decimo minuto. I fotogrammi non vengono eliminati; solo le etichette lo sono. Un timecode drop-frame è una convenzione di conteggio e trattarlo come un semplice conteggio di frame produce un errore che cresce attraverso il programma.
Conversione di fotogrammi in millisecondi: l'aritmetica e l'arrotondamento che produce errori piccoli ma reali
La conversione dei fotogrammi in millisecondi è una divisione per la frequenza dei fotogrammi e l'arrotondamento è il punto in cui entrano i piccoli errori. Un indice di frame diviso per la velocità e moltiplicato per mille raramente arriva a un millisecondo intero e il risultato deve essere arrotondato per essere archiviato. Internamente i segnali vengono mantenuti come millisecondi interi contati da zero, quindi ogni conversione in quella rappresentazione viene eseguita una volta.
Un arrotondamento è innocuo. L'errore a cui prestare attenzione è la conversione ripetuta: un file portato da fotogrammi a millisecondi, di nuovo a fotogrammi a una velocità diversa e inoltrato di nuovo accumula ogni volta un arrotondamento e tali errori non si annullano. Converti una volta dalla fonte autorevole anziché passare un file attraverso diversi strumenti.
Esempio elaborato: un segnale a 25 fps e a 29.97 drop-frame: conversione di entrambi in millisecondi e confronto
Prendi uno spunto a un minuto e trenta secondi e dodici fotogrammi. A venticinque fotogrammi al secondo, dodici fotogrammi equivalgono a dodici venticinquesimi di secondo, ovvero esattamente quattrocentottanta millisecondi, quindi l'istante è novantamilaquattrocentottanta millisecondi.
Nel 29.97 drop-frame la stessa etichetta è un istante diverso. Contare i fotogrammi: novanta secondi al valore nominale trenta danno duemilasettecento, più dodici, meno le due etichette lasciate cadere al primo minuto, che fa duemilasettecentodieci fotogrammi. Dividi per il tasso reale di trentamila su milleuno e l'istante sarà di circa novantamilaquattrocentoventiquattro millisecondi. I due codici temporali sembrano quasi identici e differiscono di circa cinquantasei millisecondi, che è abbastanza piccolo da sopravvivere alla revisione e abbastanza grande da essere visibile in un attimo.
Cosa non copre: ore oltre 99, tempi negativi e codice temporale nei metadati del contenitore
Questo copre le notazioni del codice temporale trasportate da un file di sottotitoli. Non copre i campi delle ore oltre novantanove, che alcuni sistemi utilizzano per l'identificazione delle bobine anziché il tempo trascorso, e non copre i tempi negativi, che nessuno dei due formati di sottotitoli può esprimere; uno spostamento che ne produrrebbe uno è bloccato a zero.
Anche il timecode archiviato nei metadati del contenitore non rientra nell'ambito. Un file video può contenere un codice temporale iniziale che compensa tutto al suo interno, quindi un file di sottotitoli corretto rispetto al programma può apparire sbagliato rispetto al file e nessun esame dei timestamp dei sottotitoli lo rivelerà.
Conclusione: scopri quale orologio stai leggendo: come il Subtitle Toolkit converte esattamente i codici temporali SRT e WebVTT
Scopri quale orologio stai leggendo. Una virgola e un punto hanno lo stesso valore scritto per parser diversi e la conversione tra loro dovrebbe cambiare la punteggiatura e nient'altro. Il conteggio dei fotogrammi è un tipo diverso di numero, privo di significato senza la sua velocità e fuorviante quando la velocità è di tipo drop-frame.
Converti tra SRT e WebVTT con il toolkit e confronta un timestamp prima e dopo: il separatore dovrebbe cambiare e le cifre no. Se un numero è stato spostato, il file ha attraversato da qualche parte un passaggio basato su frame e questa è la conversione da esaminare.