Por qué una misma frecuencia de fotogramas guarda una tasa de conteo y una base de visualización

Una misma opción de frecuencia de fotogramas trae aquí dos números a la vez, pero el trabajo que cumple cada uno es distinto. Uno es la tasa de conteo con la que el tiempo del reloj de pared se convierte en cantidad de fotogramas, y puede ser decimal; el otro es la base de visualización, que tiene que ser entera, y sirve para pasar de una cadena de código de tiempo a un número de fotogramas y a la inversa.

Ver 29.97 y aun así escribir el código de tiempo con agrupaciones de 30 fotogramas no es mezclar dos frecuencias de fotogramas: son la tasa de conteo y la base de visualización haciendo dos cosas distintas.

Por qué una sola opción de frecuencia conserva dos números

En un valor como 29.97, la tasa de conteo responde a “pasó tal cantidad de tiempo de reloj de pared, ¿cuántos fotogramas hay que avanzar?”, y la base de visualización responde a “¿cómo se corta esa cantidad de fotogramas en las posiciones de hora, minuto, segundo y fotograma de la cadena?”. La primera admite decimales porque es la escala con la que corre el tiempo; la segunda tiene que ser un entero porque es la base con la que se agrupa la posición de fotogramas del código de tiempo. Unir los dos en un solo número equivale a confundir la velocidad con la que corre el tiempo y la regla de numeración de la cadena.

23.976 tiene la misma estructura: para avanzar se usa la tasa de conteo decimal y para convertir la cadena se usa una base de visualización entera. En valores enteros como 24, 25 y 30 esa capa de diferencia no existe, porque la tasa de conteo y la base de visualización son iguales. Lo que se discute aquí no es cuál de los dos números es más “real”, sino que cada uno atiende a un cálculo distinto.

Cómo la diferencia entre los dos números se acumula hasta volverse desfase

En estas opciones no enteras la tasa de conteo es aproximadamente una milésima parte más lenta que la base de visualización, así que el ritmo de la numeración del código de tiempo no coincide con la velocidad a la que avanza el reloj de pared. Con 29.97 acompañado de 30, o 23.976 acompañado de 24, la cadena se sigue agrupando por la base de visualización entera mientras el avance real usa la tasa de conteo más lenta. El resultado no es que de vez en cuando falte una numeración, sino que la misma diferencia se va acumulando.

Bajo este criterio el código de tiempo se queda cada vez más atrás del reloj de pared, en un orden de magnitud de segundos por hora. A ese ritmo el retraso es de unos 3.6 segundos por hora; el mismo ritmo multiplicado por 24 horas da 86.4 segundos, que es la marca del minuto y medio. Ese desfase no se puede dar por cancelado alegando que los dos números “se parecen”, porque sale justamente de que las dos funciones estén repartidas entre dos valores.

Lo importante de una opción no entera no es que su decimal se parezca a un entero, sino que la tasa de conteo decide la velocidad de avance, la base de visualización decide la estructura de la numeración, y la diferencia entre las dos se acumula con el tiempo.

Cómo la frecuencia de un registro de cámara se reduce a la tasa base

Cuando la frecuencia de fotogramas que guarda una cámara es un valor elevado por encima de la tasa base, la lógica de conversión prueba divisores uno por uno y compara cada resultado con las tasas base disponibles. El primer candidato que cae dentro de una tolerancia muy pequeña se toma como tasa base; si ningún candidato acierta, se retrocede a 24. Aquí se usa una tolerancia pequeña para que los valores elevados cercanos puedan volver a su base correspondiente sin que se mezclen las opciones normales vecinas.

Por ejemplo, 24 y 23.976 se llevan 0.024, así que la tolerancia tiene que ser más corta que esa distancia para que 24 siga siendo 24 y no sea absorbido por 23.976. Contar el material grabado a una tasa elevada con su tasa base es una práctica común del sector, pero eso no significa que sea el único camino que la parte receptora deba adoptar. Quien recibe debe seguir verificando la etiqueta de frecuencia de fotogramas contra el archivo de entrega real y contra sus propios registros de medios.

Por qué este conteo en vivo sigue siendo NDF

En el camino en vivo de las opciones no enteras los números de fotograma avanzan de forma continua, y no se recuperan horas del reloj de pared saltándose algunos números de fotograma, así que aquí se trata de un conteo sin pérdida de fotogramas, es decir NDF. NDF describe cómo se numera el camino en vivo, no declara que el camino de entrega de punta a punta use la misma regla de visualización. Leer “no se saltan números” como “el código de tiempo alcanza al reloj de pared” es justo al contrario: el desfase acumulado del que se habló antes sigue estando ahí.

El lado de la exportación tiene su propia decisión sobre la visualización con pérdida de fotogramas, y por ahora esa escritura con punto y coma solo aparece en las columnas de código de tiempo del ALE y del CSV (el cuerpo de tabla del informe diario en PDF no tiene columna de código de tiempo), así que el criterio del camino en vivo y el del lado de la exportación no coinciden. De aquí no se puede concluir que la app tenga una capacidad de código de tiempo con pérdida de fotogramas que atraviese el set y la entrega, ni escribir que el código de tiempo esté sincronizado con el reloj de pared. Sobre el significado del punto y coma en un archivo de entrega conviene ver aparte “Qué indica realmente un punto y coma en el código de tiempo”, en lugar de deducir el resultado de la exportación a partir del NDF del camino en vivo.

Por qué en la entrega todavía hay que mirar la etiqueta y el separador

La etiqueta de frecuencia de fotogramas dice a qué velocidad afirma correr esa fila del archivo de entrega, y el separador del código de tiempo refleja qué escritura de visualización usó el lado de la exportación. Ninguno de los dos sustituye la verificación del registro de origen, sobre todo cuando las reglas del camino en vivo y del lado de la exportación no son unificadas. Cuando hace falta rastrear de dónde viene el valor de una columna, se puede revisar columna por columna junto con “De dónde viene el valor de cada columna del ALE”, en vez de mirar solo si el código de tiempo se ve familiar.

Por eso, quien recibe debe verificar por su cuenta la etiqueta de frecuencia de fotogramas y el separador del código de tiempo que trae el archivo de entrega, y ponerlos junto con el registro del set y con la información del lado de los medios para juzgarlos. La tasa de conteo se encarga del avance, la base de visualización se encarga de convertir cadenas y conteos de fotogramas, y el lado de la exportación decide aparte la forma de visualización: esas tres capas no deben sustituirse entre sí. Una vez separadas las capas, ver 29.97 y 30 al mismo tiempo deja de ser dos respuestas que se contradicen.

FAQ

¿Por qué se ve el número 30 si la frecuencia es 29.97?

29.97 es la tasa de conteo y 30 es la base de visualización; una se usa para avanzar la cuenta de fotogramas y la otra para armar la cadena del código de tiempo. Que las dos aparezcan juntas es un reparto del cálculo, no que una opción se cambie temporalmente por otra opción.

¿23.976 usa también la estructura de dos números?

Sí. 23.976 avanza con una tasa de conteo decimal y la conversión de la cadena del código de tiempo usa una base de visualización entera. La tasa de conteo es aproximadamente una milésima parte más lenta que la base de visualización, así que el código de tiempo se va quedando detrás del reloj de pared.

¿El NDF del camino en vivo significa que la exportación también se escribe en NDF?

No se puede deducir así. El camino en vivo es un conteo NDF que no salta números de fotograma, mientras el lado de la exportación tiene su propia decisión de visualización con pérdida de fotogramas, así que los criterios de punta a punta no son unificados.

¿Qué debe verificar al final quien recibe?

Quien recibe debe verificar por su cuenta la etiqueta de frecuencia de fotogramas y el separador del código de tiempo del archivo de entrega, y compararlos con el registro del set y con la información de los medios. Con un solo número o con un solo tipo de separador no se puede dar por verificada toda la cadena del código de tiempo.

Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.