Qué dice de verdad un punto y coma en el código de tiempo
Cuando el último tramo de un código de tiempo pasa de dos puntos a punto y coma, normalmente está avisando de que «esa cadena se muestra con notación de salto de fotogramas». Lo que aborda es el desvío de largo recorrido entre el conteo de fotogramas y el reloj humano en ciertas tasas de fotogramas fraccionarias. Pero al recibir un archivo de entrega, el punto y coma solo sirve como aviso, y por sí solo no prueba que la posición de fotogramas ya se haya convertido con la regla de salto de fotogramas. La notación de visualización y el algoritmo de conteo hay que comprobarlos por separado.
El punto y coma dice «esta cadena quiere expresar la escritura con salto de fotogramas»; no dice automáticamente «esta posición de fotogramas ya está calculada con la regla de salto».
Por qué existe un conteo con salto de fotogramas
Una tasa de fotogramas fraccionaria como 29.97 no avanza al mismo ritmo que una numeración de código de tiempo construida sobre el entero 30. Si se muestra una secuencia continua de números enteros de fotograma sin ninguna compensación, la lectura del código de tiempo se va quedando atrás respecto al reloj de pared.
Calculando con la fórmula, un conteo continuo como 29.97 acumula cada día un desvío del orden de un minuto y medio. Por eso el conteo con salto de fotogramas no elimina fotogramas de vídeo reales: omite ciertos números dentro de la numeración del código de tiempo según una regla, para volver a acercar el reloj mostrado al tiempo realmente transcurrido.
La convención de texto habitual escribe el separador del último tramo como punto y coma, por ejemplo 01:00:00;00. Ese símbolo resulta útil porque permite al receptor reconocer de un vistazo que el archivo está expresando una notación de salto de fotogramas. Pero el símbolo sigue siendo una parte de la cadena.
La notación visible y la conversión de la posición de fotogramas son dos cosas
El cálculo real del salto de fotogramas exige ejecutar la regla de omisión al convertir entre el número de fotograma y los campos de hora, minuto, segundo y fotograma. Cambiar simplemente el último : por un ; solo altera la apariencia, y no modifica la posición de fotogramas que expresaban aquellos números.
En los caminos de entrega actuales de SlateX existen las dos conductas. Cuando falta la posición de salida y el programa tiene que calcularla a partir del punto de entrada y de la duración, se ejecuta la aritmética real de salto de fotogramas. Las cadenas de punto de entrada o de salida que ya existen, en cambio, solo ven sustituido su separador del último tramo por un punto y coma, sin ninguna conversión de la posición de fotogramas.
Ahí está la frontera dura de este artículo: al ver un ; puede saberse que la capa de entrega ha marcado esa cadena como escritura con salto de fotogramas; pero solo con ese símbolo no puede juzgarse si esos números se obtuvieron antes aplicando la regla de salto.
Las dos tolerancias de «cerca de 29.97» no son la misma
El lado en tiempo real usa una tolerancia de 0.013 al convertir la tasa nominal de la cámara en la tasa base, y el lado de exportación usa una tolerancia de 0.02 al decidir por valor numérico si hay salto de fotogramas: las dos comprobaciones miran objetos distintos y no comparten el mismo número. Eso significa que una tasa de fotogramas situada en el borde puede acabar clasificada de manera distinta en cada lógica.
Esta diferencia no debe empaquetarse como un detalle de implementación que al receptor no le concierne. Mientras afecte a la ruta de visualización o de cálculo que sigue un código de tiempo, en la aceptación hay que comprobar juntos el FPS real del archivo, la cadena del código de tiempo y el material.
Igualmente, no puede equipararse «el valor numérico se acerca a una tasa de fotogramas conocida» con «toda la cadena ya aplica la misma regla de conteo». Si cambia el punto por el que entra el juicio, puede cambiar la conclusión.
Lo que el receptor tiene que verificar es cómo encaja un material real con su código de tiempo, no solo qué forma tiene el separador.
La visualización en tiempo real de la aplicación y el archivo de entrega no son la misma representación
La cadena en tiempo real de SlateX emite hoy códigos de tiempo con todos los separadores de dos puntos, y no produce ninguna representación con punto y coma. Es decir, la cadena en tiempo real que se ve en pantalla durante el rodaje y el punto y coma que puede aparecer en un archivo de entrega pertenecen a reglas de representación de dos fases distintas.
El camino en tiempo real avanza el conteo con el valor fraccionario cuando la tasa lo es, y luego convierte los fotogramas en una cadena usando una tasa entera; él no tiene ninguna representación de omisión con salto de fotogramas. Por eso, que un archivo de entrega acabe llevando punto y coma no autoriza a deducir a la inversa que la visualización en tiempo real del rodaje ya funcionaba con la misma regla.
Al recibir hay que separar esas dos capas: de dónde sale la cadena original registrada en el rodaje, si en la entrega se ha recalculado algo, si el separador solo se ha sustituido, y si la correspondencia con el material final se sostiene. Falte lo que falte de esa lista, el punto y coma no puede tomarse como una conclusión de aceptación.
Cómo comprobar de verdad un código de tiempo con punto y coma
Mire primero si el FPS de esa fila coincide con el material y con el registro del rodaje, elija después un material localizable y compare su punto de entrada real con el tiempo transcurrido. Si la posición de salida del archivo la ha calculado el programa, hay que confirmar aparte si pasó por la regla de conteo correspondiente.
Si el punto de entrada o de salida es una cadena que ya existía, no basta con mirar si lleva punto y coma. El receptor debe verificar que la posición de fotogramas encaja con el material. Una cadena a la que solo se le ha cambiado el símbolo puede parecer visualmente un código de tiempo con salto perfectamente correcto, y que sus números sigan viniendo de otro modo de conteo.
Por eso el punto y coma encaja como aviso de «aquí hay que comprobar el criterio de salto de fotogramas», y no como etiqueta de «esta cadena ya está verificada».
FAQ
¿Si el último tramo del código de tiempo lleva punto y coma, puede confirmarse que se calculó con la regla de salto?
No. El punto y coma puede ser solo un símbolo de la capa de visualización. En el camino de entrega actual, una cadena de código de tiempo ya existente puede recibir únicamente la sustitución del separador del último tramo, sin recalcular la posición de fotogramas.
¿El salto de fotogramas elimina fotogramas de vídeo reales?
No en el sentido del que aquí se trata. El conteo con salto ajusta la regla de numeración del código de tiempo, para compensar en tasas fraccionarias el desvío de largo recorrido entre la numeración continua y el reloj de pared.
¿Por qué una misma tasa de fotogramas puede juzgarse de dos maneras?
Porque las dos tolerancias actuales de «cerca de 29.97» son 0.013 y 0.02. Un valor en el borde puede caer en ramas distintas, así que el receptor debe comprobar el archivo y el material reales.
¿El código de tiempo en tiempo real de la pantalla de la aplicación también usa punto y coma?
Hoy la cadena en tiempo real emite cadenas con todos los dos puntos y no produce ninguna representación con punto y coma. El punto y coma de un archivo de entrega pertenece a otra fase de la representación, y no permite deducir a la inversa que el camino en tiempo real use el mismo conteo con salto.
Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.