Por qué una misma tasa de fotogramas guarda una tasa de conteo y una base de visualización
Una misma opción de tasa de fotogramas trae aquí dos números a la vez, pero el trabajo que cada uno de ellos asume es distinto. Uno es la tasa de conteo con la que el reloj de pared se convierte en número de fotogramas, y puede llevar decimales; el otro es la base de visualización, un número entero, con el que se convierten entre sí la cadena del código de tiempo y el recuento de fotogramas.
Ver 29.97 y, aun así, escribir el código de tiempo en grupos de 30 no es mezclar dos tasas de fotogramas: la tasa de conteo y la base de visualización están haciendo dos cosas distintas.
Por qué una sola tasa de fotogramas conserva dos conjuntos de números
En un ajuste como 29.97, la tasa de conteo responde a «cuántos fotogramas hay que avanzar una vez que el reloj de pared ha recorrido un tiempo», y la base de visualización responde a «cómo se reparten esos fotogramas en los campos de hora, minuto, segundo y fotograma». La primera admite decimales porque es la medida del transcurso del tiempo; la segunda tiene que ser entera porque es la base de agrupamiento de los dígitos del fotograma. Reducir los dos a un solo número equivale a tratar la velocidad de avance y la regla de numeración de la cadena como si fueran la misma cosa.
23.976 tiene la misma estructura: el avance usa la tasa de conteo con decimales y la conversión a cadena usa una base de visualización entera. En ajustes enteros como 24, 25 o 30 no existe esa diferencia, porque la tasa de conteo y la base de visualización coinciden. Lo que importa aquí no es qué número es más «real», sino que los dos conjuntos de números sirven a cálculos distintos.
Cómo dos números que no coinciden se acumulan hasta formar una diferencia de tiempo
En estos ajustes no enteros la tasa de conteo va aproximadamente una milésima por debajo de la base de visualización, así que el ritmo con que se numeran los códigos de tiempo no coincide con la velocidad de avance del reloj de pared. Con 29.97 junto a 30, o 23.976 junto a 24, la cadena sigue agrupándose por la base de visualización entera, pero el avance real usa la tasa de conteo más lenta. El resultado no es que de vez en cuando falte un número, sino que esa misma diferencia se acumula de forma continua.
Con este criterio el código de tiempo va quedándose cada vez más atrás respecto al reloj de pared, en un orden de magnitud de segundos por hora. Aplicado ese ritmo, el retraso es de unos 3.6 segundos por hora, y el mismo ritmo llevado a 24 horas da 86.4 segundos, es decir, el orden de minuto y medio. Esa diferencia no puede borrarse alegando que los números «se parecen», porque surge precisamente de que los dos conjuntos de números tengan funciones separadas.
En un ajuste no entero lo importante no es que el 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 tasa guardada en el registro de cámara vuelve a una tasa base
Cuando la tasa de fotogramas que guarda el registro de una cámara es un valor rodado a alta velocidad, por encima de una tasa base, el cálculo prueba los divisores uno a 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. Esa tolerancia pequeña existe para que los valores de alta velocidad próximos puedan volver a su base sin mezclar los ajustes normales vecinos.
Por ejemplo, 24 y 23.976 se llevan 0.024, así que la tolerancia tiene que ser más pequeña que esa distancia para que 24 siga siendo 24 y no sea absorbido por 23.976. Contar el material de alta velocidad por su tasa base es un modo de hacer frecuente en el sector, pero eso no equivale a decir que sea el único camino que el receptor deba adoptar. El receptor sigue teniendo que cotejar la etiqueta de tasa de fotogramas contra el archivo de entrega real y contra sus propios registros de medios.
Por qué este conteo en tiempo real sigue siendo NDF
En el camino en tiempo real de los ajustes no enteros los números de fotograma crecen de forma continua y no recuperan el retraso del reloj de pared saltándose ciertos números, de modo que aquí se trata de un conteo NDF, es decir, sin salto de fotogramas. NDF describe cómo se numeran los fotogramas en tiempo real, no está declarando que toda la cadena de entrega, del rodaje al final, use la misma regla de visualización. Leer «no se saltan números» como «el código de tiempo alcanzará al reloj de pared» dice justo lo contrario: la diferencia acumulada de antes sigue ahí.
El lado de exportación tiene además su propia decisión sobre la visualización con salto de fotogramas, y esa escritura con punto y coma aparece hoy solo en las columnas de código de tiempo de ALE y CSV (el cuerpo de la tabla del informe diario en PDF no tiene columna de código de tiempo), así que el criterio del camino en tiempo real y del lado de exportación no coinciden. De aquí no puede deducirse que la aplicación tenga una capacidad de código de tiempo con salto de fotogramas que atraviese desde el rodaje hasta la entrega, ni puede escribirse 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é dice de verdad un punto y coma en el código de tiempo», en lugar de inferir el resultado de la exportación directamente desde el NDF del camino en tiempo real.
Por qué en la entrega hay que mirar además etiquetas y separadores
La etiqueta de tasa de fotogramas indica al receptor qué velocidad declara esa fila del archivo de entrega, y el separador del código de tiempo refleja qué escritura de visualización usó el lado de exportación. Ninguno de los dos datos sustituye la verificación del registro de origen, sobre todo cuando las decisiones del camino en tiempo real y de la exportación no están unificadas. Cuando haya que rastrear de dónde viene el valor de una columna, puede trabajarse columna por columna con «¿De dónde sale el valor de cada columna del ALE?», en vez de limitarse a mirar si el código de tiempo resulta familiar.
Por tanto, el receptor debe verificar por su cuenta la etiqueta de tasa de fotogramas y el separador del código de tiempo del archivo de entrega, y juzgarlos junto con el registro del rodaje y la información del lado de los medios. La tasa de conteo se ocupa del avance, la base de visualización de la conversión a cadenas y el lado de exportación decide 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 contradictorias.
FAQ
¿Por qué con 29.97 sigue apareciendo el número 30?
29.97 es la tasa de conteo y 30 es la base de visualización; cada una se usa para avanzar los fotogramas y para dividir la cadena del código de tiempo. Que aparezcan juntas es un reparto de tareas de cálculo, no un cambio momentáneo de un ajuste de tasa de fotogramas a otro.
¿23.976 usa la misma estructura de dos números?
Sí: 23.976 avanza con una tasa de conteo con decimales y la conversión a cadena del código de tiempo usa una base de visualización entera. La tasa de conteo va aproximadamente una milésima por debajo de la base de visualización, así que el código de tiempo se rezaga poco a poco respecto al reloj de pared.
¿El NDF del camino en tiempo real significa que la exportación también se escriba en NDF?
No puede deducirse así. El camino en tiempo real es un conteo NDF que no salta números de fotograma, mientras que el lado de exportación tiene su propia decisión de visualización con salto de fotogramas, de modo que el criterio de punta a punta no coincide.
¿Qué debe verificar al final el receptor?
El receptor debe verificar por su cuenta la etiqueta de tasa de fotogramas y el separador del código de tiempo del archivo de entrega y cotejarlos con el registro del rodaje y con la información de los medios. Con un solo número o un solo tipo de separador no puede darse la cadena completa por verificada.
Axiom One LLC — SlateX. Las cifras de arriba son a fecha de 2026-09-24.