Qué indica realmente un punto y coma en el código de tiempo
Cuando el último tramo del código de tiempo pasa de dos puntos a punto y coma, normalmente está avisando que “esta cadena se muestra con escritura de drop frame”. Lo que resuelve es el desvío prolongado entre la cuenta de fotogramas y el reloj de pared en ciertas frecuencias de fotogramas fraccionarias. Pero al recibir un archivo de entrega, el punto y coma solo sirve como aviso: por sí solo no prueba que la posición de fotograma ya esté convertida con la regla de drop frame. El marcador de visualización y el algoritmo de conteo se verifican por separado.
El punto y coma le dice que “esta cadena quiere expresar una escritura de drop frame”, no le dice de forma automática que “estas posiciones de fotograma ya se calcularon con la regla de drop frame”.
Por qué existe una escritura de conteo con drop frame
En una frecuencia fraccionaria como 29.97, la cantidad de fotogramas que avanza cada segundo real no coincide del todo con el ritmo que resultaría de numerar el código de tiempo con un 30 entero. Si la numeración siguiera siempre números de fotograma consecutivos sin compensar nada, la lectura del código de tiempo se va quedando detrás del reloj de pared.
Según el cálculo por fórmula, un conteo consecutivo como el de 29.97 acumula del orden de un minuto y medio por día. Por eso el conteo con drop frame no bota fotogramas reales del video: salta algunos números dentro de la numeración del código de tiempo, siguiendo una regla, para volver a acercar el reloj mostrado al tiempo efectivamente transcurrido.
La convención de texto más común escribe el separador del último tramo como punto y coma, por ejemplo 01:00:00;00. Ese símbolo es útil, porque quien recibe reconoce de un vistazo que el archivo está expresando una escritura de drop frame. Aun así, el símbolo sigue siendo una parte de la cadena.
El marcador de visualización y la conversión de la posición de fotograma son dos cosas
El cálculo real de drop frame tiene que ejecutar la regla de salto al convertir entre número de fotograma y hora, minuto, segundo y fotograma. Cambiar simplemente el último : por ; solo modifica la apariencia, y no cambia la posición de fotograma que representaba aquella secuencia de números.
En las rutas de entrega vigentes de SlateX existen los dos comportamientos. Cuando falta la posición de salida y el software tiene que calcular el punto de salida a partir del punto de entrada y de la duración, sí se ejecuta la aritmética de drop frame. Sobre una cadena de código de tiempo de entrada o de salida que ya existía, en cambio, solo se cambia el separador del último tramo a punto y coma, sin ninguna conversión de la posición de fotograma.
Esta es la frontera dura del texto: al ver ;, se puede saber que la capa de entrega marcó esa cadena como escritura de drop frame; pero solo con ese símbolo no se decide si esos números salieron antes de un conteo con drop frame.
Las dos tolerancias de “cerca de 29.97” no son el mismo número
El lado en tiempo real usa una tolerancia de 0.013 al reducir la tasa nominal de la cámara a la tasa base, y el lado de la exportación usa una tolerancia de 0.02 al decidir por valor numérico si hay drop frame: las dos decisiones miran objetos distintos y el número de tolerancia tampoco es el mismo. Eso significa que un valor de frecuencia que esté en el borde puede acabar clasificado de forma distinta en cada una de las dos lógicas.
Esta diferencia no debe envolverse como un detalle de implementación que a quien recibe no concierne. Mientras cambie por qué camino de visualización o de cálculo opta el código de tiempo, lo que toca en la aceptación es poner juntos el FPS real del archivo, la cadena de código de tiempo y el material.
Tampoco puede igualarse “el valor se aproxima a cierta frecuencia común” con “toda la cadena ya adoptó la misma regla de conteo”. Si el punto de decisión es distinto, la conclusión también puede serlo.
Lo que quien recibe tiene que verificar es cómo un material real cuadra con su código de tiempo, y no solo cómo se ve el separador.
La visualización en tiempo real de la app y el archivo de entrega no son la misma representación
La cadena en tiempo real de SlateX saca hoy códigos de tiempo solo con dos puntos, sin ninguna representación con punto y coma. Dicho de otro modo: la cadena en vivo que se ve en pantalla durante el rodaje y el punto y coma que puede aparecer en el archivo de entrega pertenecen a dos etapas con reglas de representación distintas.
El camino en vivo avanza la cuenta con el valor fraccionario cuando la frecuencia es fraccionaria, y después pasa la cantidad de fotogramas a cadena usando la frecuencia entera; él mismo no tiene ninguna representación de salto de números con drop frame. Por eso, si el archivo de entrega aparece después con un punto y coma, no puede retrocederse desde ahí que la visualización en vivo del set ya trabajaba con la misma regla.
Al recibir, hay que separar esas dos capas: de dónde sale la cadena original del registro del set, si hubo un recálculo al entregar, si el separador solo fue reemplazado y si el cotejo final con el material se sostiene. Falta uno de esos puntos y el punto y coma no puede tomarse como conclusión de aceptación.
Cómo se verifica en la práctica un código de tiempo con punto y coma
Mire primero si el FPS de esa fila concuerda con el material y con el registro del set, después elija un fragmento localizable del material y compárelo con el punto de entrada y el tiempo transcurrido reales. Si la posición de salida del archivo está calculada por el software, hace falta confirmar aparte si pasó por la regla de conteo correspondiente.
Cuando el punto de entrada o de salida sea una cadena que ya existía, no se quede en si lleva o no punto y coma. Quien recibe debe verificar que las posiciones de fotograma cuadren con el material. Una cadena a la que solo se le cambió el símbolo puede parecer visualmente un código de tiempo de drop frame correcto, y aun así sus números pueden venir de otro tipo de conteo.
Así que el punto y coma sirve bien como aviso de “acá conviene revisar el criterio de drop frame”, y no como etiqueta de “esta fila ya quedó verificada”.
FAQ
Si el último tramo del código de tiempo lleva punto y coma, ¿ya se puede confirmar que se calculó con drop frame?
No. El punto y coma puede ser solo un marcador de la capa de visualización. En las rutas de entrega de hoy, sobre una cadena de código de tiempo existente puede reemplazarse únicamente el separador del último tramo, sin recalcular la posición de fotograma.
¿Drop frame quiere decir que se borraron fotogramas reales del video?
No es el sentido que se discute acá. El conteo con drop frame ajusta la regla de numeración del código de tiempo, para compensar el desvío prolongado entre la numeración consecutiva y el reloj de pared cuando la frecuencia es fraccionaria.
¿Por qué un mismo valor de frecuencia puede juzgarse distinto en dos lógicas?
Porque hoy las dos tolerancias de “cerca de 29.97” valen 0.013 y 0.02. Un valor en el borde puede caer en ramas distintas, así que quien recibe debe verificar el archivo real y el material.
¿El código de tiempo en vivo de la pantalla también usa punto y coma?
La cadena en tiempo actual saca cadenas solo con dos puntos, sin representación con punto y coma. El punto y coma del archivo de entrega pertenece a la representación de otra etapa, y no permite inferir que el camino en vivo usó el mismo conteo con drop frame.
Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.