Convertir SBV a VTT

El vídeo se mueve por algún motivo concreto: una plataforma de formación que quiere el archivo, un sitio que prefiere no incrustar a un tercero, un cliente cuyas normas de marca descartan el reproductor de YouTube, o una grabación que no debería estar en una plataforma pública. El vídeo se transcodifica y se sube sin dificultad. Los subtítulos son la parte que deja de funcionar.

SBV es el formato propio de Google y prácticamente nada fuera de YouTube lo lee, empezando por los navegadores. El vídeo de HTML admite subtítulos a través del elemento track y acepta WebVTT y poco más, así que un archivo que funcionaba perfectamente en la plataforma de donde salió produce un menú de subtítulos vacío en la página a la que llegó.

Un archivo WebVTT tiene que empezar con la palabra WEBVTT en su primera línea, antes que nada. No es documentación ni es opcional: un analizador que no la encuentra rechaza el archivo sin seguir leyendo. SBV no tiene ningún concepto de cabecera; su primera línea es ya la primera línea de tiempos.

Así que aquí no hay nada que adaptar, hay algo que añadir. La conversión escribe la cabecera y una línea en blanco, y después las intervenciones. Esta es la diferencia que hace imposible resolverlo renombrando el archivo, y es también la que más se olvida cuando alguien lo intenta a mano, porque es la única parte del formato de destino que no tiene ninguna correspondencia en el de origen.

SBV pone los dos tiempos en una línea separados por una coma. WebVTT los pone en una línea separados por una flecha, y escribe las horas con dos dígitos. Los milisegundos ya van con tres cifras detrás de un punto en los dos formatos, así que esa mitad del sello de tiempo pasa sin tocarse.

Los valores en sí son exactos. Todo se maneja en milisegundos enteros durante la conversión, así que una intervención que empezaba en 0:04:12.500 empieza en 00:04:12.500. No se redondea, no se ajusta y no se desplaza nada: los dos formatos miden lo mismo con la misma resolución y solo discrepan en cómo se escribe.

La representación intermedia por la que pasan todos los subtítulos de este sitio guarda tres cosas por intervención: cuándo empieza, cuándo acaba y el texto. Todo lo que no quepa en esa forma se pierde por construcción, no por descuido, y decirlo así evita medias promesas.

En esta dirección concreta eso no cuesta nada, y por eso el par está marcado como sin pérdida. Un SBV no lleva estilos, ni posiciones, ni identificadores de intervención, ni nada más que tiempos y texto, así que sale de la conversión todo lo que entró. Donde esa limitación duele es en los formatos que sí llevan más cosas, y esas son otras páginas.

Buena parte de los SBV que circulan son transcripciones automáticas y no subtítulos redactados, y la conversión no mejora ni una palabra. En español eso se nota en sitios muy concretos y muy repetitivos. No hay puntuación, o la hay a medias. No aparecen los signos de apertura de interrogación y exclamación, que en un subtítulo de dos líneas son justamente lo que avisa al espectador de que la frase es una pregunta.

Después están los homófonos, que el reconocedor resuelve por probabilidad y no por sentido: haya y halla, tuvo y tubo, a ver y haber, sino y si no. Y los nombres propios, los topónimos y el vocabulario técnico, que son exactamente las palabras que sostienen el significado de la frase. Un repaso completo de una transcripción automática en español lleva más o menos un tercio del tiempo del vídeo.

Para los sitios del sector público español, el Real Decreto 1112/2018 traspone la directiva europea de accesibilidad y remite a la norma EN 301 549, que exige subtítulos en el contenido audiovisual pregrabado. La misma exigencia alcanza cada vez a más empresas por vía contractual, y en buena parte de Latinoamérica hay normativas equivalentes en marcha.

Una transcripción automática sin revisar no cumple eso, y el motivo no es solo la tasa de acierto. Un subtítulo accesible tiene que incluir información que no es habla: quién habla cuando no se le ve, cuándo entra la música, un ruido relevante fuera de plano. Un reconocedor no produce nada de eso, porque solo oye palabras. Convertir el archivo es el primer paso del trabajo, no el trabajo.

Cada intervención de WebVTT puede llevar ajustes escritos detrás del tiempo final: una posición vertical, una alineación horizontal, una posición y un tamaño. SBV no tiene nada de esto, así que el archivo convertido llega sin ningún ajuste y todo se sitúa abajo en el centro.

Añadirlos es la primera mejora que merece la pena en un reproductor propio. La parte baja del cuadro es donde el reproductor dibuja sus controles y donde el realizador pone los rótulos, así que un subtítulo que se superpone a cualquiera de las dos cosas es la queja más habitual del vídeo autoalojado. Dos palabras en la línea de tiempos lo mueven durante esos segundos, y ninguna cantidad de CSS consigue lo mismo.

SBV no tiene ninguna construcción para atribuir una línea a quien la dice, así que los archivos que lo necesitan usan una convención: el nombre y dos puntos, o una raya al principio de la línea de cada interlocutor, como ha hecho siempre el subtitulado de televisión en español. Esos caracteres se copian tal cual al WebVTT y aparecerán en pantalla exactamente como estén escritos.

WebVTT tiene un mecanismo propio: una etiqueta que nombra a quien habla, que el navegador puede pintar de un color distinto por interlocutor y que un lector de pantalla puede anunciar como atribución en vez de leerla como texto. Convertir la convención en etiquetas es un buscar y reemplazar, y es de las pocas tareas manuales sobre un archivo convertido que se pagan solas en una auditoría de accesibilidad.

Un archivo WebVTT que se pide desde un origen distinto al de la página se rechaza si la respuesta no trae las cabeceras adecuadas, y el rechazo es silencioso: el vídeo se reproduce, el menú de subtítulos está vacío y la consola no dice nada. Es el fallo más caro del subtitulado autoalojado, porque se parece a todas las demás causas a la vez.

Servir el .vtt desde el mismo origen que el HTML elimina la familia entera de problemas, que es buena razón para guardar los subtítulos junto a la página y no en un dominio de recursos aparte. El otro descuido silencioso es el tipo de contenido: un WebVTT debe servirse como `text/vtt`, y una configuración que caiga en un tipo genérico le da al navegador motivos para ignorarlo. Abrir la URL del .vtt directamente en una pestaña resuelve las dos dudas de golpe.

Si el vídeo sigue estando también en YouTube, ahora hay dos archivos de subtítulos. Empiezan idénticos y se separan la primera vez que alguien corrige una errata en el que tenía abierto, y ninguno de los dos guarda constancia de cuál es el bueno a partir de ese momento.

Elige uno como maestro y genera el otro. Editar en YouTube y volver a descargar funciona si las correcciones son raras y la plataforma es donde ya trabaja tu equipo. Editar el WebVTT y subirlo a YouTube —que acepta WebVTT directamente— es mejor si tu sitio es la casa principal, porque entonces el archivo que mantienes es el que lleva la colocación y las etiquetas de voz, y esas son justo las que una descarga desde YouTube tiraría a la basura.

El atributo que indica la clase de pista tiene más valores que subtítulos y subtítulos para sordos, y todos usan la misma sintaxis WebVTT que ya tienes. Los capítulos producen una lista navegable de secciones en los reproductores que la soportan. Las descripciones llevan audiodescripción en texto para lectores de pantalla. Los metadatos llevan intervenciones cronometradas que no se muestran nunca y a las que JavaScript puede reaccionar según avanza la reproducción.

Ese último es la base de las transcripciones interactivas, las diapositivas sincronizadas y las anotaciones cronometradas, y conviene conocerlo justamente en un reproductor propio, porque la plataforma que has dejado atrás traía esas prestaciones y tu página no. Un segundo archivo de capítulos cuesta unas pocas líneas y le da a una grabación larga lo que el espectador quiere de verdad: poder saltar a la parte por la que vino.

Merece la pena preguntárselo, porque un reproductor de YouTube incrustado trae consigo su pista de subtítulos, su renderizado, su cambio de idioma y su comportamiento de accesibilidad sin coste ninguno. Si el motivo para mudarse es estético, incrustar da menos trabajo y tiene menos maneras de fallar.

Los motivos que sí se sostienen son los de control y privacidad: material que no debería estar en una plataforma pública, un reproductor sin rastreo de terceros, un sitio que tiene que funcionar donde YouTube está bloqueado, o unos subtítulos que necesitan una colocación que la plataforma no hace. Cuando se da alguno, autoalojar es lo correcto y esta conversión es su primer paso. Y como el archivo se analiza y se reescribe dentro de tu navegador, ni siquiera el guion de un vídeo aún sin publicar sale de tu equipo para convertirse.