Convertir ASS a SBV

Advanced SubStation Alpha existe para controlar la apariencia. Estilos con nombre que fijan tipografía, cuerpo, contorno y sombra; anulaciones línea a línea de color y posición; rotación, animación, sincronía de karaoke y dibujos vectoriales. Un fansub o una charla bien subtitulada usan casi todo eso, y perderlo al convertir parece culpa de la conversión.

No lo es. YouTube dibuja los subtítulos con su propia tipografía y ofrece al espectador un panel para cambiar la fuente, el tamaño, el color, la opacidad del fondo y el estilo del borde. Lo que un archivo subido diga sobre apariencia se descarta al ingerirlo, en cualquiera de los formatos que acepta. Así que la pregunta que esta página puede responder no es cómo conservar el estilo —no lo conserva nadie— sino qué hacer con las partes del archivo que llevaban significado y no adorno.

La norma española de subtitulado para personas sordas descansa sobre cosas que SBV no puede escribir. Asigna un color a cada personaje para que se sepa quién habla; coloca los efectos sonoros arriba a la derecha; fija la posición del diálogo abajo y centrada, salvo cuando hay que apartarse de un rótulo. Un archivo ASS es el sitio natural donde se materializa todo eso.

Al convertirlo a SBV desaparecen los tres mecanismos a la vez, y la consecuencia no es estética. Un diálogo entre tres personas que se distinguía por color pasa a ser una sucesión de líneas blancas indistinguibles, y una didascalia de sonido que estaba arriba baja a competir con el habla. Si el archivo se hizo para cumplir la norma, el destino correcto no es YouTube con un archivo de subtítulos: es una copia con los subtítulos incrustados, o una plataforma que respete el posicionamiento.

Las partes que llevan significado son los carteles: el nombre de un local, un mensaje en la pantalla de un móvil, un título de capítulo, la traducción de un rótulo colocada junto a lo que traduce. En el archivo ASS cada uno está posicionado con precisión, a menudo con un estilo que imita el original, y cronometrado para aparecer mientras además hay diálogo.

Tras la conversión son líneas de subtítulo corrientes al pie del cuadro, y como se solapan en el tiempo con el diálogo, la plataforma las apila. Una escena con dos personas hablando bajo un letrero se convierte en tres líneas peleando por la misma franja de imagen, sin que el espectador pueda distinguir qué es habla y qué es un aviso traducido. Con un puñado de carteles queda desordenado; con un archivo muy tipografiado, ilegible.

Es la respuesta estándar y la correcta para cualquier archivo donde la tipografía esté haciendo trabajo. Se renderiza el ASS dentro del vídeo durante la codificación, con su estilo, su posición y su animación exactamente como los pensó quien lo hizo, y se sube ese vídeo.

Después se convierte solo el diálogo a SBV y se sube como pista de subtítulos, de modo que el vídeo conserva texto buscable, accesible y traducible automáticamente. Borra las líneas de cartel del ASS antes de convertir, o del SBV después; los dos son texto plano y los dos son rápidos de editar. Esa combinación te da la tipografía para la que se hizo el archivo y la accesibilidad que aporta una pista de subtítulos, algo que ningún archivo único consigue en esta plataforma.

Tres cosas: el texto, su división en líneas y sus tiempos. El diálogo llega como caracteres normales, los saltos duros escritos con la marca de nueva línea se convierten en saltos reales que la plataforma muestra en dos renglones, y el espacio indivisible se convierte en un espacio corriente.

Todo lo demás se descarta: el nombre del estilo al que cada línea se refería, la capa, los márgenes, el campo de efecto, el nombre del personaje y cada anulación entre llaves. El SBV no tiene campo para ninguna de esas cosas, que es exactamente por lo que es un formato tan cómodo de editar a mano: una entrada son unos tiempos y unas palabras, y no hay nada más dentro que se pueda romper.

Una línea de diálogo en ASS empieza a menudo con un bloque de instrucciones entre llaves —una posición, un color, un fundido, una animación— y puede llevar más a media línea. Se eliminan antes de escribir el SBV, así que lo que recibes es la frase y no la frase precedida de código.

Es el comportamiento correcto y esconde una consecuencia que conviene conocer. La sincronía de karaoke se expresa como una etiqueta delante de cada sílaba, de modo que una letra escrita como sucesión de sílabas cronometradas se colapsa en una línea entera que aparece de golpe. Las palabras están todas; el efecto que justificaba cronometrarlas, no. Para un vídeo musical eso es una pérdida real y la incrustación descrita más arriba es la única forma de conservarlo.

ASS sabe dibujar formas: una etiqueta cambia el campo de texto a un lenguaje de coordenadas, y lo que sigue es un trazado. Los tipógrafos lo usan para máscaras, para fondos detrás de un cartel y para flechas.

Al quitar las etiquetas desaparece el cambio de modo y quedan las coordenadas, así que esas líneas llegan al SBV como subtítulos formados por letras sueltas y cifras. Se identifican a simple vista y conviene borrarlas antes de subir el archivo, porque de lo contrario un espectador con los subtítulos activados verá una ráfaga de números. Buscar en el archivo convertido las líneas que empiezan por una letra suelta seguida de un dígito localiza casi todas.

La sección de eventos de un ASS contiene dos clases de línea: las de diálogo y las de comentario. Solo se leen las primeras, de modo que las notas de trabajo, las traducciones alternativas, los carteles desactivados y los recordatorios del tipógrafo no llegan a convertirse nunca en subtítulos.

Merece la pena saberlo en las dos direcciones. Significa que un archivo que en Aegisub parece lleno puede producir menos entradas de las esperadas, porque una parte estaba comentada: si el número te cuadra bajo, eso es lo primero que hay que mirar. Y significa que el archivo puede llevar notas con total seguridad, que es una de las razones por las que un proyecto vivo se guarda en ASS y no en otra cosa.

La sección de eventos declara su propio orden de columnas en una línea de formato, y los archivos difieren de verdad: el orden es convencional y no fijo, y las herramientas que generan ASS de forma automática no siempre siguen la convención. El lector toma las posiciones de inicio, fin y texto de esa declaración en lugar de contar campos.

El texto es siempre el último y puede contener comas, así que solo se separan los campos anteriores a él. Una línea de diálogo con una enumeración dentro sobrevive con sus comas intactas, cosa que un analizador ingenuo destrozaría. En la práctica eso hace que los archivos de Aegisub, los de las herramientas automáticas de subtitulado y los extraídos de un contenedor se lean todos igual.

ASS anota el tiempo en centésimas de segundo y SBV en milésimas. Cada marca gana por tanto un dígito final que siempre es cero, sin que ningún tiempo se desplace: es un cambio de precisión y no de valor. El lector rellena esa cifra en lugar de suponerla, que es la diferencia entre leer «,50» como medio segundo o como cincuenta milésimas.

Los dos formatos dejan la hora sin relleno, así que una entrada de la primera hora empieza igual en ambos. La diferencia real está en la disposición: ASS escribe los tiempos como campos dentro de un registro de diálogo, mientras que SBV pone los dos valores separados por una coma en su propia línea y el texto debajo. El orden de las entradas sigue al archivo y no al reloj, cosa que importa en un archivo tipografiado, porque los carteles y el diálogo suelen ir intercalados fuera de orden cronológico y así se quedan.

Todo lo que hacía que el archivo mereciera el trabajo vive en el origen, y nada de ello se puede recuperar desde los subtítulos. Así que regenera el SBV cada vez que cambie la traducción en lugar de editar los dos, porque en un mes habrán divergido.

Si los subtítulos se corrigen dentro del estudio de la plataforma, descarga el SBV corregido y traslada esos cambios de texto al ASS. Es una molestia menor que la alternativa, que es tener dos versiones de la misma traducción y no saber cuál es la buena.

La conversión es JavaScript corriente ejecutándose aquí mismo: no se sube nada, no se descarga ningún motor de conversión, no hay cuenta ni cupo diario, y la pestaña de red durante una conversión es la manera de comprobarlo en lugar de creerlo.

Para lo que suele pasar por esta página eso importa más de lo que parece. Una traducción sin publicar, el subtitulado de una entrevista bajo embargo o el trabajo de un equipo de fansub antes de sacarlo son archivos con los que la gente tiene cuidado, y aquí no hay de qué tenerlo. El límite es de 100 MB por archivo, cifra que un subtítulo no alcanza jamás, y de cien archivos por lote.