Convertir SRT a SBV

El SBV es el formato de subtítulos propio de Google, el que produce el editor de subtítulos de YouTube y el que ofrece su herramienta de descarga junto al SubRip y al WebVTT. Prácticamente nada fuera de ese ecosistema lo escribe y muy poco lo lee, lo que lo convierte en un formato estrecho con una única casa clara.

Y lo primero que hay que decir es que YouTube acepta SubRip. Si el objetivo es poner subtítulos a un vídeo, subir el SRT que ya tienes son menos pasos y menos ocasiones de introducir un fallo. Esta conversión se gana el sitio cuando lo que pide SBV es otra cosa distinta del formulario de subida, y de eso trata el apartado siguiente.

El más común es un archivo histórico. Un canal que lleva años subtitulando, o una productora que gestiona varios, acumula cientos de ficheros en el formato que exportaba el editor, y un capítulo nuevo que llega en SRT es la excepción rara. Convertirlo para que entre mantiene un solo directorio en un solo formato, que vale más que ahorrarse un paso.

El segundo son las herramientas propias. Como el SBV no tiene cabecera, ni numeración, ni estilos, una línea suya es trivial de analizar: dos marcas de tiempo y una coma. Los scripts, las hojas de cálculo y los controles de calidad escritos alrededor de la exportación del editor dan por hecha esa forma, y darles un SRT con su numeración y su flecha significa cambiar la herramienta en lugar del archivo.

Tres cosas, todas estructurales y ninguna semántica. El número de subtítulo en su propia línea desaparece. La flecha entre las dos marcas de tiempo se convierte en una coma. Y las marcas de tiempo se reescriben con la convención del SBV en lugar de la del SubRip. El texto, los saltos de línea dentro de él y los tiempos al milisegundo quedan intactos.

Por eso esta conversión es exacta donde importa. Los dos formatos guardan lo mismo —un inicio, un final y unas palabras— y solo discrepan en puntuación y ceremonia. No hay nada que aproximar, redondear ni descartar, cosa que no puede decirse de la mayoría de los pares de este sitio.

El SubRip escribe la hora con dos dígitos: `00:04:12,500`. El SBV la escribe con los que necesite: `0:04:12.500`. Ese cero de más es la diferencia entre un archivo que YouTube acepta y uno que rechaza, y es la razón por la que renombrar un SRT a `.sbv` no le ha funcionado nunca a nadie.

Los milisegundos son la otra mitad. El SubRip los separa con una coma y el SBV con un punto, que es exactamente la misma discrepancia que el WebVTT tiene con el SubRip y en el mismo sentido. Aquí se escriben los dos bien, tres dígitos de milisegundos detrás de un punto, así que el archivo está bien formado en el momento en que se descarga. Para un lector hispanohablante conviene subrayarlo: ese punto no es un decimal, es un separador de campo, y no cambia según la configuración regional.

El SubRip numera cada subtítulo desde uno, y el número forma parte del formato antes que de la cortesía: un analizador estricto lo espera. El SBV no tiene numeración de ninguna clase: una línea de tiempos, una o dos líneas de texto, una línea en blanco, y empieza la siguiente entrada.

Los números se leen del SRT y sencillamente no se escriben. Eso no es una pérdida, porque nada en el SBV ni en YouTube se refiere a ellos, y dejarlos sería peor que quitarlos: un número suelto encima de una línea de tiempos se lee como texto de subtítulo para un analizador que no lo esperaba, y el dígito acaba apareciendo en pantalla.

El SBV lleva una hora de entrada, una de salida y palabras. Ni cursiva, ni negrita, ni color, ni posición, ni forma de marcar quién habla. Es más simple incluso que el SubRip, que al menos tiene una convención de cursiva que la mayoría de los reproductores respeta.

El texto de cada subtítulo se copia literalmente, así que cualquier etiqueta entre ángulos que hubiera en el origen sobrevive al SBV como caracteres normales, y YouTube los mostrará. Una pista que se apoye en la cursiva para el monólogo interior o para el texto en pantalla necesita que esas etiquetas se quiten antes de convertir, y que el significado se vuelva a expresar con palabras o con puntuación. Quítalas en el SRT y no en el SBV, para que el archivo maestro siga siendo el limpio.

Este es el punto donde el formato duele de verdad en español. El subtitulado para personas sordas que se practica en España asigna un color distinto a cada personaje principal y coloca el subtítulo bajo quien habla cuando hace falta desambiguar, además de describir entre paréntesis los sonidos y la música relevantes. De esas tres cosas, el SBV no puede expresar ninguna de las dos primeras.

La consecuencia es concreta: si tu SRT ya venía de un flujo de trabajo accesible, la conversión conserva el texto y las descripciones entre paréntesis o corchetes, y pierde toda distinción por color o por posición que existiera. Los corchetes son la convención que llena ese hueco y funciona en cualquier formato sin estilos, incluido este; el color, no. Para una entrega que tenga que cumplir un requisito de accesibilidad por contrato, el SBV no es el formato final, y conviene saberlo antes de firmar la entrega.

Los saltos de línea dentro de un subtítulo sobreviven a la conversión como saltos de línea reales, que es lo que el SBV espera: el texto ocupa dos líneas entre la de tiempos y la línea en blanco. No hay nada que escapar y nada se une.

La atribución de quién habla es el hueco. No existe ninguna construcción para ella, así que la convención es un nombre y dos puntos escritos dentro del texto, o un guion al principio de la intervención de cada persona, como ha hecho siempre el subtitulado de televisión. Si tu SRT ya usaba una de esas dos, cruza sin tocarse; si distinguía a dos personajes por color, esa información no existe en ninguno de los dos formatos y hay que reescribirla con palabras.

La salida se escribe en UTF-8, que es lo que YouTube espera y lo que hace que las tildes, las eñes y los signos de apertura sobrevivan a la subida. El SubRip no tiene forma de declarar su propia codificación, así que la conversión es un buen momento para zanjar la cuestión en vez de dejarla a una suposición.

Cuando una subida se rechaza después de una ronda de edición a mano, la causa es casi siempre una de tres: una marca de tiempo que ha recuperado el cero o la coma, una línea en blanco entre entradas que ha desaparecido, o el archivo guardado en una codificación regional por un editor que la usa por defecto —el Bloc de notas antiguo era el sospechoso habitual—. El mensaje de error de YouTube no distingue entre las tres, así que revisa las tres.

El SubRip le da a un analizador tres señales de que empieza un subtítulo nuevo: una línea en blanco, un número solo y una línea de tiempos con una flecha. Puede perder una y las otras dos siguen funcionando. El SBV tiene exactamente una señal, la línea en blanco entre entradas, y una línea de tiempos se reconoce solo por ser la primera de un bloque y contener una coma.

Eso convierte la línea en blanco en algo estructural, cosa que en el SubRip no es. Si quitas una editando —cosa fácil al fusionar dos subtítulos y ordenar después—, las dos entradas se funden en un solo bloque cuya segunda línea de tiempos se lee como texto. YouTube o rechazará el archivo o mostrará una marca de tiempo en pantalla, y ninguno de los dos resultados señala hacia la línea que falta. Al corregir un SBV a mano, trata las líneas en blanco como estructura y no como espacio sobrante.

El SRT se analiza y el SBV se escribe dentro de tu navegador, con JavaScript escrito a mano y sin ninguna biblioteca externa. No se sube nada, no hay cuenta y no hay recuento: puedes desconectar la red y la conversión termina igual, que es la comprobación de diez segundos.

En subtítulos eso no es un detalle abstracto. Un archivo de subtítulos contiene el guion completo de un vídeo que muchas veces todavía no se ha publicado: un anuncio bajo embargo, una entrevista con fecha de emisión, un curso de pago. Entregar ese texto a un servidor ajeno a cambio de un cambio de puntuación es un intercambio malo que se hace por costumbre.

El SubRip es lo que manejan bien todos los editores de subtítulos, lo que leen todos los reproductores y lo que acepta casi cualquier plataforma. El SBV no se lee prácticamente en ningún sitio fuera de YouTube y no lleva nada que el SubRip no lleve. Como archivo de trabajo no tiene ninguna ventaja, y como formato de conservación ata unos subtítulos a las herramientas de una sola empresa.

La organización que sobrevive al contacto con un flujo real es corregir y ajustar tiempos en SRT, guardar ese archivo, y convertir en el momento en que un destino concreto pide otra cosa. Dos copias mantenidas a mano de los mismos subtítulos se separan la primera vez que alguien arregla una errata en la que tenía abierta, y ninguno de los dos archivos registra cuál de ellos es ahora el correcto.