Detectar fin anterior al inicio
O pega el texto de los subtítulos
Opciones
La velocidad de fotogramas con la que se cuentan los tiempos. En las páginas de formato es lo que necesita MicroDVD, porque guarda los tiempos como números de fotograma. En las páginas de velocidad de fotogramas es la velocidad con la que se cronometró el archivo (la versión para la que se hicieron los subtítulos), y el segundo recuadro de la página toma la velocidad del video con el que vas a usarlos. 23,976, 24, 25, 29,97, 30, 50, 59,94 y 60 son las habituales. Equivocarla desplaza toda la línea de tiempo, y en las páginas de velocidad de fotogramas la desplaza por una proporción en lugar de por una cantidad fija.
Un bloque que termina antes de empezar es un código de tiempo que no puede ser cierto: 00:00:03,000 --> 00:00:03,000 o, peor, un fin anterior a su inicio. Esta página informa de los archivos que contenían uno, contando a partir de las reparaciones que tuvo que hacer el lector, porque un código de tiempo con esa forma no se puede sostener en memoria y se sustituye por uno real antes de que ocurra cualquier otra cosa. Lo que vuelve es un informe, nunca un archivo modificado.
Por eso el informe empieza por lo que se perdió durante la lectura y solo después muestra el hallazgo. Un bloque cuyo fin no es posterior a su inicio recibe un milisegundo, para que el resto del archivo se pueda leer, previsualizar y exportar; el recuento de esas reparaciones está en la cabecera del informe, y el hallazgo de debajo dice un error sin número de bloque, porque las reparaciones se cuentan mientras se lee y no se guardan en una lista. Las dos líneas describen el mismo código de tiempo roto desde dos lados, y por eso pertenecen al mismo informe y no a dos.
La trampa con la que hubo que escribir esta página es que un bloque legítimo de un milisegundo parece exactamente uno reparado. Así que la comprobación no mira las duraciones: mira el registro de reparaciones, y un bloque que realmente dura un milisegundo queda fuera. Una duración negativa y una de longitud cero son el mismo defecto y se cuentan juntas. Dos formatos no se aceptan, y por una vez el motivo es el mismo en ambos lados: LRC deriva cada fin de la marca siguiente, así que un par ahí no puede salir al revés, y el texto plano no tiene tiempos de bloque. Comprobar cualquiera de los dos produciría un informe limpio sobre un campo que el formato no tiene, que es la única clase de respuesta peor que ninguna respuesta.
Ejemplos
Un bloque sin duración
Subtítulos
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,000
I was working late.
Qué encuentra el informe
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
Un fin igual a su inicio. El lector da al bloque un milisegundo para que el archivo se pueda sostener, registra la reparación y el informe imprime ambas mitades: la línea de pérdida en la cabecera y un error debajo. La reparación es la evidencia; el milisegundo es solo la forma que toma la evidencia.
Un bloque que dura realmente un milisegundo
Subtítulos
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:03,000 --> 00:00:03,001
I was working late.
Qué encuentra el informe
Cues ending before they start — Nothing found
Cues 2
Checks run 1
Lost while reading Nothing
Escrito a mano como bloque de un milisegundo y no reportado. Esa decisión es la que da forma a la comprobación: un bloque de longitud cero reparado también sale como un milisegundo, así que una regla que marcara duraciones cortas aquí llamaría archivo lleno de bloques imposibles a cualquier archivo con un código de tiempo roto.
El fin es anterior al inicio
Subtítulos
1
00:00:01,000 --> 00:00:02,000
Where were you?
2
00:00:05,000 --> 00:00:02,000
I was working late.
Qué encuentra el informe
Cues ending before they start — 1 found
Lost while reading: Timing × 1
Severity Cues Start End Measured
Error — — — 1 items
De cinco segundos a dos segundos: el mismo defecto que el caso de longitud cero, contado por la misma regla e informado de forma idéntica. No se reescribe nada del archivo: los tiempos reparados existen en la copia del lector para que el resto del archivo se pueda procesar, y no son una corrección que ofrezca esta página.
Preguntas frecuentes
¿Qué cuenta como un bloque que termina antes de empezar?
Un tiempo de fin que no es posterior al de inicio: igual a él, como en 00:00:03,000 a 00:00:03,000, o anterior, como en 00:00:05,000 a 00:00:02,000. Los dos son el mismo defecto y se cuentan juntos, y ambos se cuentan a partir de la reparación que hace el lector y no del bloque, porque un código de tiempo con esa forma no se puede sostener en memoria.
¿Por qué el informe de tiempos invertidos no nombra los bloques implicados?
Porque esas reparaciones se cuentan mientras se lee el archivo y no se recogen en una lista. El informe da el recuento —un error, un elemento en la línea de pérdida de la cabecera— y las dos mitades son el mismo hecho visto desde la cabecera y desde los hallazgos. Si necesitas el bloque exacto, busca en el archivo sus códigos de tiempo y no un número de bloque.
¿Es un problema un bloque que dura un milisegundo?
Aquí no, y es deliberado. Un bloque de un milisegundo escrito a mano es legal y no se reporta; lo que se reporta es un código de tiempo que hubo que reparar, que después queda guardado como un milisegundo. Comprobar duraciones en lugar de reparaciones marcaría todo archivo con un bloque de longitud cero como un archivo lleno de bloques imposibles, que es el hallazgo equivocado por partida doble.
¿Esta página corrige los códigos de tiempo que encuentra?
No. Los tiempos reparados existen solo dentro del navegador para que el resto del archivo se pueda leer e informar. El archivo que descargaste o arrastraste no cambia, y no hay forma de guardar la versión reparada desde esta página: sustituir un código de tiempo roto es una operación cuyo producto es un archivo de subtítulos, no una comprobación.
¿Qué formatos de subtítulos se pueden revisar en busca de bloques que acaban antes de empezar?
Diez de los doce: SRT, WebVTT, ASS, SSA, SBV, SMI, MicroDVD, TTML, JSON y CSV. Faltan dos y ninguna ausencia es un descuido. LRC guarda un tiempo por línea y el lector deriva cada fin de la marca siguiente, así que un par ahí nunca puede ir al revés: la comprobación juzgaría un campo que el formato no tiene. El texto plano no tiene tiempos de bloque. Si tu archivo está en uno de esos dos, conviértelo primero.
¿Estos códigos de tiempo rotos vienen de algún sitio en particular?
Casi siempre se producen en lugar de escribirse. Una conversión de velocidad de fotogramas que redondea mal, un desplazamiento aplicado dos veces al mismo bloque, una exportación de hoja de cálculo en la que la columna de fin quedó vacía y se leyó como cero, o un subtítulo extraído de un archivo de texto cronometrado con una marca que no tenía duración desde el principio.
¿Se pueden revisar varios archivos en una sola ejecución?
Sí. Puedes soltar tantos como quieras y se leen uno tras otro, cada uno con su informe, y los informes se descargan juntos en un zip. La cola muestra el progreso por archivo, la ejecución se puede cancelar a medias y no se sube ningún archivo en ningún momento.