Vídeo y subtítulos · Kit de herramientas de subtítulos
Códigos de tiempo de subtítulos comparados: SRT comas, VTT puntos y fotogramas SMPTE
· Antecedentes
subtítulos códigos de tiempo velocidad de fotogramas
Tres formas de escribir el tiempo aparecen en el trabajo de subtítulos: HH:MM:SS,mmm de SRT, HH:MM:SS.mmm de WebVTT y HH:MM:SS:FF de SMPTE. Esta publicación explica qué significa cada uno, cómo convierten y dónde fallan las conversiones.
El mismo momento escrito de tres maneras: un recorrido rápido por los códigos de tiempo que un editor encuentra en un proyecto
Un proyecto puede entregarse a un editor en el mismo instante escrito de tres maneras. El archivo de subtítulos utiliza horas, minutos, segundos y una coma antes de los milisegundos. El archivo de título web utiliza un punto en la misma posición. La lista de decisiones de edición utiliza un número de fotograma en lugar de una fracción. Los tres nombran el mismo momento, y sólo uno de ellos puede leerse sin saber nada más del material.
Ese último punto es el que importa. Dos de estas notaciones son absolutas y una no, y las conversiones entre ellas fallan de una manera específica cuando se pasa por alto la diferencia.
Milisegundos con coma: SRT: un hábito decimal europeo que se convirtió en una regla de formato
SRT escribe horas, minutos, segundos, una coma y exactamente tres dígitos de milisegundos. La coma es un separador decimal en la convención europea y se convirtió en una regla de formato por uso más que por especificación, ya que SubRip no tenía un documento de estándares para solucionarlo. Nada en el valor es europeo; sólo lo es la puntuación.
El analizador aquí lee milisegundos rellenando los dígitos que encuentra a la derecha hasta tres, por lo que una marca de tiempo que termina en un solo dígito se lee como cientos de milisegundos en lugar de unidades. Esto es importante porque los archivos escritos a mano o con un convertidor no siempre proporcionan tres dígitos, y leer un solo dígito final como unidades colocaría la señal casi un segundo antes.
Milisegundos con un punto: WebVTT: el mismo valor, diferente separador y por qué es importante para los analizadores
WebVTT escribe el mismo valor con un punto y permite que el campo de horas se omita por completo, por lo que es válido un formulario de dos campos donde SRT espera tres. Para un analizador, estas son gramáticas genuinamente diferentes, razón por la cual un archivo puede ser rechazado solo por puntuación a pesar de que todos los números que contiene sean correctos.
Los archivos reales mezclan los dos constantemente, por lo que el analizador acepta cualquiera de los separadores independientemente del formato que dice tener el archivo. Esa tolerancia se aplica únicamente a la entrada. En la salida, el separador se elige por el formato de destino, una coma para SRT y un punto para WebVTT, por lo que un archivo convertido es canónico en lugar de una copia de cualquier irregularidad que haya llegado.
Fotogramas: código de tiempo SMPTE — HH:MM:SS:FF, su dependencia de la velocidad de fotogramas y la complicación de la eliminación de fotogramas
El código de tiempo SMPTE reemplaza la parte fraccionaria con un número de fotograma, que proporciona horas, minutos, segundos y fotogramas. A diferencia de los otros dos, no se puede interpretar solo: el fotograma doce es un instante diferente a veinticinco fotogramas por segundo que a treinta, por lo que un código de tiempo basado en fotogramas sin una velocidad declarada es incompleto y no meramente ambiguo.
Drop-frame añade una segunda complicación. El material a 29.97 fotogramas por segundo se cuenta como si fueran treinta y, para mantener el conteo alineado con el reloj, se omiten dos números de fotograma al comienzo de la mayoría de los minutos, quedando exento cada décimo minuto. Los fotogramas no se caen; Sólo las etiquetas lo son. Un código de tiempo de eliminación de fotogramas es una convención de conteo, y tratarlo como un conteo de fotogramas simple produce un error que crece a lo largo del programa.
Conversión de fotogramas a milisegundos: la aritmética y el redondeo que produce errores pequeños pero reales
La conversión de fotogramas a milisegundos es una división por la velocidad de fotogramas y el redondeo es donde entran los pequeños errores. Un índice de fotogramas dividido por la velocidad y multiplicado por mil rara vez equivale a un milisegundo completo, y el resultado debe redondearse para poder almacenarse. Las señales internas se mantienen como milisegundos completos contados desde cero, por lo que cada conversión a esa representación se redondea una vez.
Una ronda es inofensiva. El error a tener en cuenta es la conversión repetida: un archivo tomado de fotogramas a milisegundos, retroceder a fotogramas a una velocidad diferente y avanzar nuevamente acumula un redondeo cada vez, y esos errores no se cancelan. Convierta una vez desde la fuente autorizada en lugar de pasar un archivo a través de varias herramientas.
Ejemplo resuelto: una señal a 25 fps y a 29.97 drop-frame: convertir ambos a milisegundos y comparar
Tome una señal en un minuto, treinta segundos y doce fotogramas. A veinticinco fotogramas por segundo, doce fotogramas son doce veinticinco quintos de segundo, que son exactamente cuatrocientos ochenta milisegundos, por lo que el instante es noventa mil cuatrocientos ochenta milisegundos.
En 29.97 drop-frame la misma etiqueta es un instante diferente. Cuente los fotogramas: noventa segundos a los treinta nominales dan dos mil setecientos, más doce, menos las dos etiquetas eliminadas en el primer minuto, que son dos mil setecientos diez fotogramas. Divida por la tasa real de treinta mil entre mil uno y el instante es aproximadamente noventa mil cuatrocientos veinticuatro milisegundos. Los dos códigos de tiempo parecen casi idénticos y difieren en aproximadamente cincuenta y seis milisegundos, lo cual es lo suficientemente pequeño como para sobrevivir a la revisión y lo suficientemente grande como para ser visible en una señal ajustada.
Lo que esto no cubre: horas posteriores a 99, tiempos negativos y código de tiempo en metadatos del contenedor
Esto cubre las notaciones de código de tiempo que lleva un archivo de subtítulos. No cubre campos de horas más allá de noventa y nueve, que algunos sistemas utilizan para la identificación de carretes en lugar del tiempo transcurrido, y no cubre tiempos negativos, que ningún formato de subtítulo puede expresar; un cambio que produciría uno se fija en cero.
El código de tiempo almacenado en los metadatos del contenedor también está fuera del alcance. Un archivo de vídeo puede llevar un código de tiempo de inicio que compensa todo lo que contiene, por lo que un archivo de subtítulos que es correcto según el programa puede aparecer incorrecto en el archivo, y ningún examen de las marcas de tiempo de los subtítulos revelará eso.
Conclusión: sepa qué reloj está leyendo: cómo el Subtitle Toolkit convierte exactamente entre los códigos de tiempo SRT y WebVTT
Sepa qué reloj está leyendo. Una coma y un punto tienen el mismo valor escrito para diferentes analizadores, y la conversión entre ellos debería cambiar la puntuación y nada más. Un recuento de fotogramas es un tipo diferente de número, que no tiene sentido sin su velocidad y es engañoso cuando la velocidad es de caída de fotogramas.
Convierta entre SRT y WebVTT con el kit de herramientas y compare una marca de tiempo antes y después: el separador debería cambiar y los dígitos no. Si un número se movió, el archivo pasó por un paso basado en cuadros en algún lugar, y esa es la conversión a examinar.