Convertire SBV in VTT

Il video si sposta per una ragione: una piattaforma corsi che vuole il file, un sito che non vuole un embed di terze parti, un cliente le cui linee guida di marca escludono un lettore YouTube, una registrazione che non dovrebbe stare su una piattaforma pubblica. Il video transcodifica e carica senza difficoltà. I sottotitoli sono la parte che smette di funzionare.

SBV è il formato proprio di Google e praticamente nulla fuori da YouTube lo legge, tantomeno un browser. Il video HTML prende i sottotitoli tramite un elemento track e accetta solo WebVTT, quindi un file sottotitoli che funzionava perfettamente sulla piattaforma d’origine produce un menu sottotitoli vuoto sulla pagina dove si è spostato.

Un file WebVTT deve iniziare con la parola WEBVTT sulla propria prima riga, prima di qualunque altra cosa. Non è documentazione ed è obbligatoria: un parser che non la trova rifiuta il file senza leggere oltre. SBV non ha alcuna costruzione di intestazione — la prima riga del file è la prima riga di temporizzazione.

Quindi non c’è nulla da adattare, solo qualcosa da aggiungere. Il convertitore scrive l’intestazione e una riga vuota, poi i cue. È la differenza che rende impossibile rinominare e che un approccio di modifica a mano sbaglia più spesso, perché è l’unica parte del formato senza controparte nella sorgente.

SBV mette entrambi i tempi su una riga separati da una virgola. WebVTT li mette su una riga separati da una freccia, con le ore riempite a due cifre. Entrambi i formati già scrivono tre cifre di millisecondi dopo un punto, quindi quella metà del timestamp passa invariata.

I tempi stessi sono esatti. Ogni valore è tenuto in millisecondi durante la conversione, quindi un sottotitolo iniziato a 0:04:12.500 nell’SBV inizia a 00:04:12.500 nel VTT. Nulla è arrotondato o spostato, e non c’è perdita di precisione in nessuna direzione — i due formati misurano la stessa cosa alla stessa risoluzione e differiscono solo nell’ortografia.

Gran parte dei file SBV sono trascrizioni automatiche piuttosto che sottotitoli redatti, e la conversione non migliora le parole. Il riconoscimento vocale è affidabile sul linguaggio conversazionale ordinario e inaffidabile su nomi propri, luoghi, nomi di prodotto, acronimi e vocabolario tecnico — cioè proprio le parole che portano il senso.

Conta di più una volta che il video è sul vostro sito. Per enti pubblici e un numero crescente di aziende, i sottotitoli su video preregistrato sono un requisito legale sotto la legislazione sull’accessibilità piuttosto che una cortesia, e una trascrizione automatica non verificata non lo soddisfa.

Ogni cue WebVTT può portare impostazioni dopo il suo timestamp finale: un’impostazione line che lo sposta verticalmente, align che lo sposta orizzontalmente, position e size. SBV non ha nulla di tutto ciò, quindi il file convertito arriva senza impostazioni e tutto siede in fondo.

Aggiungerle è il primo miglioramento degno su un lettore self-hosted. Il fondo del fotogramma è dove un lettore disegna i propri controlli e dove i produttori video mettono didascalie in basso, quindi un sottotitolo che si sovrappone a uno dei due è la lamentela più comune sul video self-hosted.

SBV non ha alcuna costruzione per attribuire una riga a un parlante, quindi i file sottotitoli che ne hanno bisogno usano una convenzione: un nome e due punti, o un trattino all’inizio della riga di ogni parlante. Quei caratteri vengono copiati nel WebVTT alla lettera, e appariranno a schermo esattamente come digitati.

WebVTT ha un meccanismo proprio per questo — un tag voce che nomina il parlante, che un browser può stilizzare diversamente per parlante e che uno screen reader può annunciare come attribuzione piuttosto che come testo. Convertire la convenzione digitata in tag voce è un cerca-e-sostituisci.

Un file WebVTT recuperato da un’origine diversa dalla pagina viene rifiutato a meno che la risposta non porti le intestazioni cross-origin corrette, e il rifiuto è silenzioso. Il video riproduce, il menu sottotitoli è vuoto, e nulla in console dice perché. È il fallimento singolarmente più costoso nel sottotitolaggio self-hosted.

Servire il .vtt dalla stessa origine dell’HTML evita l’intera classe di problema. Se devono vivere altrove, sia le intestazioni cross-origin sia l’attributo crossorigin sull’elemento video devono essere giusti, e testarlo in un browser è l’unico modo per saperlo.

Se il video resta su YouTube oltre che sul vostro sito, ora ci sono due file sottotitoli. Iniziano identici e divergono la prima volta che qualcuno corregge un refuso in uno dei due, e nulla in nessuno dei due file registra quale sia ora corretto.

Scegliete un master e generate l’altro. Modificare su YouTube e riscaricare funziona se le correzioni sono rare. Modificare il WebVTT e caricarlo su YouTube — che accetta WebVTT direttamente — è meglio se il sito è la casa primaria, perché il file che mantenete ha allora posizionamento e tag voce.

Vale la pena chiederselo, perché un lettore YouTube incorporato porta con sé la propria traccia sottotitoli, il proprio rendering, il cambio lingua e il comportamento di accessibilità senza costo. Se la ragione dello spostamento è presentazionale piuttosto che sostanziale, incorporare è meno lavoro.

Le ragioni che reggono sono quelle su controllo e privacy: materiale che non dovrebbe stare su una piattaforma pubblica, un lettore senza tracciamento di terze parti, un sito che deve funzionare dove YouTube è bloccato, o una traccia che richiede posizionamento che la piattaforma non farà.