Vídeo y subtítulos · Kit de herramientas de subtítulos
Cómo un navegador analiza un archivo SRT: bloques, índices, códigos de tiempo y texto
· Cómo funciona
subtítulos inicio formatos de archivo
SRT parece trivial hasta que te encuentras con archivos reales. Esta publicación explica cómo un analizador divide bloques, lee índices y códigos de tiempo, maneja texto de varias líneas y se recupera de los bloques con formato incorrecto que contienen los archivos del mundo real.
El archivo "se ve bien", pero faltan la mitad de las pistas: cómo un formato de apariencia indulgente oculta expectativas estrictas
SRT no tiene cuerpo de especificación, ni registro MIME ni validador que se envíe con los jugadores. En cambio, lo que existe es una forma con la que la mayoría del software está de acuerdo: un número, una línea de código de tiempo, una o más líneas de texto y luego una línea en blanco. Debido a que la forma es convencional en lugar de especificada, dos archivos pueden verse correctos en un editor de texto mientras solo se carga uno de ellos, y el fallo suele ser silencioso. Un jugador que no puede leer una señal tiende a omitirla en lugar de informarla, por lo que un archivo con un bloque roto se reproduce con un espacio en lugar de un error.
Por lo tanto, un analizador tiene dos trabajos que van en direcciones opuestas. Tiene que aceptar las variaciones que contienen los archivos reales, porque los archivos son producidos por servicios de transcripción, edición manual y convertidores de formato, cada uno de los cuales hace suposiciones diferentes. También tiene que rechazar lecturas que indiquen una señal en el momento equivocado, porque una marca de tiempo silenciosamente incorrecta es peor que una falla informada.
División en bloques: líneas en blanco como separadores y el problema con los espacios en blanco perdidos y CRLF
La división se produce en líneas en blanco, no en los números de índice. El analizador normaliza primero los finales de línea, reemplazando tanto el par CRLF como un CR solitario con una sola nueva línea, porque un archivo creado en Windows y editado en Unix puede contener ambos. Luego se divide en una serie de dos o más líneas nuevas, recorta cada bloque resultante y descarta los vacíos. Ese orden es importante: dividir antes de normalizar dejaría un retorno de carro perdido al final de una línea de código de tiempo, y el código de tiempo no coincidiría.
Se elimina una marca de orden de bytes antes de todo esto. Una lista de materiales UTF-8 al inicio de un archivo son tres bytes que un analizador ingenuo ve como parte del primer número de índice, lo cual es suficiente para hacer que la primera señal sea ilegible mientras se analizan todas las señales posteriores. Los espacios finales en una línea separadora que de otro modo estaría en blanco son manejados por el recorte, por lo que un archivo cuyas líneas en blanco contienen un espacio aún se divide correctamente.
La línea de índice: por qué los números a menudo son incorrectos, están duplicados o faltan y por qué los analizadores no deberían confiar en ellos
El número de índice se lee y luego se ignora. Los archivos reales numeran pistas desde cero, reinician la numeración después de una combinación, duplican un número después de una edición manual u omiten la línea por completo cuando un convertidor escribió el archivo. Confiar en esos números significa heredar cada una de esas fallas, por lo que el analizador asigna su propio número secuencial, contando las señales que ha construido con éxito hasta ahora.
Esa elección también explica por qué el analizador nunca requiere que la línea de índice esté presente. Localiza la línea del código de tiempo buscando en el bloque la primera línea que contiene la flecha, en lugar de asumir que el código de tiempo es la segunda línea. Un bloque sin línea de índice se analiza normalmente, y un bloque con dos líneas perdidas antes del código de tiempo aún se analiza, porque la posición no es lo que identifica el código de tiempo.
La línea del código de tiempo — HH:MM:SS,mmm --> HH:MM:SS,mmm, variaciones toleradas y las que rompen a los jugadores
La línea del código de tiempo se compara con una única expresión regular y las tolerancias que contiene son deliberadas. Las horas son opcionales, porque WebVTT permite una lectura de dos campos y los convertidores la emiten. Se acepta una coma o un punto como separador de milisegundos independientemente del formato que diga tener el archivo, porque los separadores mixtos son lo suficientemente comunes como para rechazarlos haría fallar más archivos buenos que malos. Los dígitos fraccionarios se rellenan a la derecha, por lo que una señal que termina en un solo dígito se lee como cientos de milisegundos en lugar de unidades.
Se rechazan dos lecturas. Un campo de minutos o segundos superior a cincuenta y nueve se rechaza en lugar de llevarse, porque noventa segundos no es una lectura de reloj y normalmente indica un archivo corrupto o mal convertido; normalizarlo silenciosamente movería la señal. Una línea cuyo inicio o final no se puede analizar produce un problema grabado que nombra el texto infractor y la forma esperada, y el bloque se omite en lugar de adivinarse.
Líneas de texto: señales de varias líneas, etiquetas de formato y dónde termina realmente un bloque
Todo lo que está después de la línea del código de tiempo es el texto de referencia, unido nuevamente con nuevas líneas. No hay límite de líneas ni intento de reflujo, por lo que una señal de tres líneas sobrevive como tres líneas. Esta es la razón por la que la línea en blanco soporta carga: es lo único que le dice al analizador que el texto ha terminado, razón por la cual una cue cuyo propio texto contiene una línea en blanco se leerá como dos bloques y se informará que la segunda mitad no tiene código de tiempo.
Las configuraciones de cue están separadas de la marca de tiempo de finalización por una serie de dos o más espacios. WebVTT permite que las directivas de posicionamiento, como la alineación y la ubicación de la línea, sigan la hora de finalización en la misma línea, por lo que el analizador las divide antes de que se analice la marca de tiempo y las mantiene junto a la señal. Un único espacio no es un separador, lo que evita que una línea de código de tiempo simplemente desordenada pierda su hora de finalización.
Ejemplo resuelto: analizar un archivo de cinco señales con dos fallas deliberadas: qué recupera un analizador robusto y qué marca
Tome un archivo de cinco bloques en el que al bloque tres se le dañó la línea de código de tiempo para leer 00:01:75,000 --> 00:01:78,000, y el bloque cuatro perdió su línea de código de tiempo por completo durante una operación de copiar y pegar. El analizador lee los bloques uno y dos normalmente y los numera uno y dos. El bloque tres coincide con la forma de un código de tiempo pero lleva un campo de segundos de setenta y cinco, por lo que se rechaza y se registra como una marca de tiempo incorrecta que nombra la línea que no pudo leer.
El bloque cuatro no contiene ninguna flecha, por lo que se registra como sin marca de tiempo, citando los primeros cuarenta caracteres del bloque para que la línea se pueda encontrar en el archivo original. El bloque cinco analiza y se convierte en la pista tres, no en la pista cinco, porque la numeración cuenta las pistas exitosas. El resultado son tres señales utilizables y dos quejas específicas y localizadas, en lugar de una excepción en la primera falla y ninguna información sobre la segunda.
Lo que esto no cubre: ASS/SSA estilo, códigos de posicionamiento y texto que no sea subtítulo volcado en SRT
Esto describe SRT y las partes de WebVTT que comparten su forma de señal. No cubre ASS y SSA, que incluyen un encabezado de script, definiciones de estilo y referencias de estilo por evento, y que no se pueden leer dividiéndolos en líneas en blanco. El tiempo de karaoke, los comandos de dibujo y las etiquetas de anulación en línea que utilizan esos formatos están fuera de lo que modela un analizador de código de tiempo y señal.
Tampoco repara texto. Una transcripción pegada en un archivo sin códigos de tiempo produce una lista de bloques que no tienen marca de tiempo, que se informa con precisión pero no se puede convertir en subtítulos sin información de tiempo que no está presente. Las fallas de codificación son una preocupación separada: un archivo decodificado con el conjunto de caracteres incorrecto se analiza en pistas perfectamente válidas cuyo texto es incorrecto, y ninguna verificación estructural lo detectará.
Conclusión: analice con indulgencia, escriba estrictamente: cómo el Subtitle Toolkit lee SRT desordenado y escribe uno limpio
La regla de trabajo es analizar con indulgencia y escribir estrictamente. Al ingresar, acepte horas opcionales, ya sea separador, líneas de índice faltantes, finales de línea mixtos y una marca de orden de bytes inicial, y registre cada falla como un problema localizado en lugar de descartar la primera, para que un archivo se pueda arreglar en una sola pasada. Al salir, emite una forma canónica.
Eso es lo que hace Subtitle Toolkit cuando convierte. Las señales se renumeran a partir de una y se mantienen contiguas, las marcas de tiempo se vuelven a emitir con una coma para SRT y un punto para WebVTT, y el archivo que regresa tiene la forma que los jugadores esperan, independientemente de cuán irregular haya sido la entrada. Pegue un archivo que un reproductor rechazó en el convertidor y lea primero los problemas informados; nombran la señal y citan la línea, lo que suele ser suficiente para encontrar la falla en el original.