Frecuencias de fotogramas, código de tiempo y el drop-frame que no descarta nada

Fotogramas = duración × frecuencia, hasta que la frecuencia es 29,97

Para una frecuencia entera la aritmética es cerrada y exacta. A 24 fotogramas por segundo un minuto son 1440 fotogramas y una hora 86 400. A 25, un minuto son 1500 y una hora 90 000. A 30, un minuto son 1800 y una hora 108 000. Toda duración corresponde a un número entero de fotogramas, todo recuento de fotogramas corresponde a una duración, y una etiqueta de código de tiempo que cuenta horas, minutos, segundos y fotogramas no es más que un cambio de base del número de fotograma.

A 29,97 el cierre se rompe. Un segundo contiene 29,97002997 fotogramas, un minuto 1798,202 y una hora 107 892,108. No hay un número entero de fotogramas en una hora, así que ningún esquema de etiquetado que cuente treinta fotogramas por segundo puede mantenerse alineado con un reloj. Cada herramienta de la cadena tiene entonces que decidir qué hacer con el desajuste, y las distintas respuestas a esa pregunta son todo el asunto del código de tiempo.

Conviene aprender de inmediato una convención de notación, porque carga con toda la distinción. El código de tiempo non-drop se escribe con dos puntos en todas partes: 01:00:00:00. El drop-frame sustituye el último separador por un punto y coma: 01:00:00;00. Si ves un punto y coma estás mirando un recuento drop-frame, y si una herramienta informa de una duración y tus notas de otra, el separador es lo primero que hay que comprobar.

De dónde viene 29,97

El número es el residuo de un problema de compatibilidad resuelto en 1953. La televisión monocroma del sistema de 525 líneas iba a exactamente 30 fotogramas por segundo, con una frecuencia de línea de 15 750 Hz y una portadora de sonido 4,5 MHz por encima de la de imagen. Al añadir el color, la información de crominancia tenía que ir en una subportadora dentro del canal existente y debía entrelazarse con el espectro de luminancia en lugar de batir visiblemente contra él. Esa restricción fijó la subportadora en un múltiplo impar de la mitad de la frecuencia de línea — concretamente 455/2 veces.

Quedaba el problema de la portadora de sonido. A la frecuencia de línea original, la razón entre la portadora de sonido de 4,5 MHz y la frecuencia de línea era 2855/7, o sea 407,857 — no un entero, así que la nueva subportadora de color habría batido de forma audible contra el sonido. Multiplicar esa razón por 1001/1000 la lleva a 408,265, lo bastante cerca como para que el organismo de normalización redefiniera en cambio la frecuencia de línea de modo que la portadora de sonido cayera exactamente en el armónico 286. Toda la maniobra es ésa: mantener la portadora de sonido en 4,5 MHz, declararla armónico 286 y dejar que la frecuencia de línea baje a 4 500 000 ÷ 286 = 15 734,2657 Hz.

De ahí la frecuencia de fotogramas se sigue mecánicamente. Divide la frecuencia de línea entre las 525 líneas de un fotograma: 15 734,2657 ÷ 525 = 29,970029970 fotogramas por segundo. La identidad con 30000/1001 es exacta y no aproximada, y la factorización muestra por qué — 286 × 525 = 150 150, que es 150 × 1001, así que 4 500 000 ÷ 150 150 se reduce a 30 000 ÷ 1 001. La subportadora de color cae en 455/2 × 15 734,2657 = 3,579545 MHz, la cifra impresa en todos los cristales NTSC jamás fabricados. El mismo factor 1000/1001 se propaga a 23,976 = 24000/1001 y 59,94 = 60000/1001, y por eso esos números viajan juntos.

El código de tiempo non-drop deriva 3,6 segundos por hora

El código de tiempo non-drop hace lo ingenuo: etiqueta cada fotograma en secuencia y hace girar el campo de segundos cada treinta fotogramas, sin importar cuánto tardan realmente treinta fotogramas. Como un fotograma dura 1001/30000 de segundo en vez de 1/30, la etiqueta se retrasa respecto al reloj, y el tamaño de ese error se calcula fácil en cualquiera de las dos direcciones.

Empieza por las etiquetas. Una hora de código de tiempo non-drop son 108 000 etiquetas de fotograma, porque 60 × 60 × 30 = 108 000. Esos 108 000 fotogramas duran cada uno 1001/30000 de segundo, así que juntos ocupan 108 000 × 1001 ÷ 30 000 = 3603,600000 segundos. Una cinta que marca exactamente una hora de código non-drop lleva rodando una hora y 3,6 segundos.

Empieza ahora por el reloj. En una hora de tiempo real la cámara ha producido 3600 × 30000 ÷ 1001 = 107 892,108 fotogramas, así que el contador ha avanzado 107 892 fotogramas enteros. Divide entre 30 etiquetas por segundo y son 3596,400000 segundos de etiqueta — la pantalla marca 00:59:56:12 cuando el reloj de pared dice una hora. Las dos derivaciones concuerdan: la discrepancia son 108 000 − 107 892 = 108 fotogramas, y 108 ÷ 30 = 3,6 segundos. Retén ese 108. Es el número en torno al cual está construido todo el esquema drop-frame.

La deriva se acumula linealmente y se vuelve alarmante rápido. En la marca de los treinta minutos el non-drop ya va 1,8 segundos desfasado. A las diez horas, 36 segundos. Para una emisora que monta un programa con una duración de franja fija, eso no es un detalle de redondeo; es la diferencia entre encajar en el enlace de red y quedarse cortado a mitad de frase.

El drop-frame descarta etiquetas, no fotogramas — demostrado contando

El nombre es la peor terminología de toda la posproducción. El código de tiempo drop-frame no descarta imagen alguna. Cada fotograma que grabó la cámara está presente en el archivo, se reproduce y queda disponible para montar. Lo que se descarta son dos entradas del esquema de numeración al inicio de casi todos los minutos — etiquetas que sencillamente nunca se emiten, igual que un edificio sin decimotercera planta no ha perdido un piso.

La regla, tal como está escrita en la norma SMPTE de código de tiempo, es corta. Al inicio de cada minuto, salta los números de fotograma 00 y 01, de modo que el minuto empieza en el fotograma 02 — salvo cuando el número de minuto es múltiplo de diez, en cuyo caso no se salta ninguno y el minuto empieza en 00 como siempre. Así, a 00:00:59;29 le sigue 00:01:00;02, y las etiquetas 00:01:00;00 y 00:01:00;01 nunca existen. Pero a 00:09:59;29 le sigue 00:10:00;00, porque el minuto 10 está exento.

Ahora cuenta, en vez de afirmar. Haz avanzar un contador fotograma a fotograma desde 00:00:00;00, aplicando esa regla en cada frontera de minuto, y detente cuando la pantalla vuelva a marcar 01:00:00;00. El recorrido emite 107 892 fotogramas y salta 108 números de fotograma. Ese recuento de saltos no es coincidencia y no hace falta consultarlo: una hora tiene 60 minutos, seis de los cuales están exentos porque 0, 10, 20, 30, 40 y 50 son múltiplos de diez, dejando 54 minutos que descartan dos números cada uno, y 54 × 2 = 108. La conversión en forma cerrada usada dentro del software de montaje — fotogramas = 108000h + 1800m + 30s + f − 2 × (minutosTotales − parteEntera(minutosTotales ÷ 10)) — devuelve 107 892 para la misma etiqueta, coincidiendo exactamente con el recorrido.

Compara eso con la sección anterior y el diseño se vuelve obvio. El non-drop pierde exactamente 108 fotogramas por hora frente al reloj. El drop-frame salta exactamente 108 etiquetas por hora. Esos dos 108 son el mismo 108, elegido por esa razón, y por eso una hora drop-frame cae sobre el reloj de pared mientras una hora non-drop cae 3,6 segundos tarde. El esquema es una corrección de tipo calendario, estructuralmente idéntica a la regla de los años bisiestos: un pequeño ajuste periódico con una excepción periódica, dimensionado para cancelar un error acumulativo conocido.

La corrección es muy buena, y no exacta

Suele decirse que el drop-frame hace que el código de tiempo coincida exactamente con el reloj de pared. El recuento muestra lo contrario, y conviene enunciar la discrepancia porque es de esas cosas que asoman una vez al año en una instalación de larga duración. Una hora de tiempo real contiene 107 892,108 fotogramas, no 107 892. El drop-frame aporta 107 892 etiquetas por hora, así que le faltan 0,1078921 de fotograma — una fracción que no puede saltar, porque las etiquetas vienen en números enteros.

Convierte esa fracción a tiempo y son 0,003600 segundos, así que una hora drop-frame ocupa 3599,996400 segundos de tiempo real en vez de 3600. El drop-frame adelanta 3,6 milisegundos por hora — en dirección opuesta al error que corrige, y mil veces menor. En un día son 0,0864 segundos, en un mes unos 2,6 segundos y en un año 31,5 segundos. Para montar, para franjas de emisión, para cualquier cosa medida en fotogramas, esto es irrelevante. Para una instalación que hace funcionar un generador de código de tiempo de forma continua como referencia de casa frente a un reloj atómico, es justo el tipo de divergencia lenta que acaba notándose y diagnosticándose mal.

Lo que importa es la comparación. El drop-frame reduce el error en un factor de mil: de 3,6 segundos por hora a 3,6 milisegundos por hora. Seguir el error acumulado a intervalos aclara la forma — a los diez minutos el drop-frame va 0,6 milisegundos desfasado; a los treinta, 1,8; a la hora, 3,6; a las diez horas, 36 milisegundos. El non-drop en los mismos tramos va desfasado 1,8 segundos a los treinta minutos, 3,6 segundos a la hora y 36 segundos a las diez horas. El esquema nunca pretendió ser perfecto; se diseñó para ser lo bastante bueno como para que ningún programa perdiera su franja.

23,976, el pulldown y la aceleración PAL

El cine va a 24 fotogramas por segundo y el sistema de vídeo de 525 líneas va a 30, así que pasar cine a vídeo requiere cinco fotogramas de vídeo por cada cuatro de cine — 24 × 5/4 = 30 exactamente. El mecanismo es el pulldown 2:3, a veces escrito 3:2. Toma cuatro fotogramas de cine A, B, C, D y repártelos en diez campos de vídeo: A recibe dos campos, B tres, C dos, D tres, sumando 2 + 3 + 2 + 3 = 10 campos, es decir cinco fotogramas de vídeo entrelazados. Dos de esos cinco fotogramas son compuestos de fotogramas de cine distintos, y por eso el material convertido se ve algo entrecortado y por eso quitar el pulldown antes de montar es práctica estándar.

Eso funciona cuando el sistema de vídeo va a 30. Va a 29,97, así que el cine tiene que ralentizarse primero por el mismo factor 1000/1001, de 24 a 24 000 ÷ 1 001 = 23,976023976 fotogramas por segundo. Ése es todo el origen de 23,976: es 24 ralentizado lo justo para caber en un mundo de 29,97. La ralentización es pequeña pero real — una bobina de cien minutos pasada a 23,976 dura 100,1 minutos, seis segundos más que a 24 — y el audio grabado a 24 debe ralentizarse por el mismo factor o se desincronizará esos seis segundos a lo largo de la bobina.

El mundo de 625 líneas tomó una ruta más tosca. Con el vídeo a 25 y el cine a 24, el transfer más fácil es sencillamente pasar el cine un fotograma por segundo más rápido y usar un fotograma de vídeo por fotograma de cine. El cambio de velocidad es 25/24 = 1,041667, un aumento del 4,1667 por ciento — redondeado normalmente al conocido cuatro por ciento, aunque el sexto extra importa a lo largo de un largometraje. Una película de 120 minutos dura 115,2 minutos, 288 segundos menos. El audio sube de tono en la misma razón: 12 × log2(25/24) = 0,7067 de semitono, o 70,67 cents, lo bastante cerca de un cuarto de tono para ser audible por quien conozca la partitura. Los transfers modernos suelen corregir el tono digitalmente y dejan la duración acortada.

Montar el sonido a imagen

El sonido se muestrea y la imagen se encuadra, y ambos sólo encajan limpiamente cuando el número de muestras en un fotograma es entero. A 48 kHz la aritmética es amable para la mayoría de frecuencias: 24 fotogramas por segundo dan exactamente 2000 muestras por fotograma, 25 dan 1920, 30 dan 1600. La grata sorpresa es 23,976, que da 48 000 × 1001 ÷ 24 000 = 2002 muestras por fotograma, también entero — una de las razones por las que 23,976 y 48 kHz forman una pareja tan cómoda.

29,97 es el incómodo. A 48 kHz un fotograma contiene 48 000 × 1001 ÷ 30 000 = 1601,6 muestras, que no es entero, así que ninguna frontera de fotograma cae en una frontera de muestra. El patrón se cierra tras cinco fotogramas: 5 × 1601,6 = 8008 muestras exactamente. Ese ciclo de cinco fotogramas es la unidad práctica para todo lo que deba ser exacto a la muestra frente a imagen a 29,97, y 59,94 lo hereda — 800,8 muestras por fotograma, entero tras los mismos cinco fotogramas con 4004 muestras. A 44,1 kHz la situación es mucho peor: 1471,47 muestras por fotograma, y el patrón no se cierra hasta pasados 100 fotogramas. Ésa es una razón concreta por la que la posproducción va a 48 kHz y no a 44,1.

La regla práctica que sale de todo esto es corta. Fija la frecuencia del proyecto antes de importar nada, haz que el audio vaya a 48 kHz y haz que cada punto de corte sea una frontera de fotograma en vez de un desplazamiento de muestra, para no tener que razonar nunca sobre el ciclo de cinco fotogramas a 29,97. Cuando llegue material a otra frecuencia, conformalo deliberadamente con un pull-up o pull-down explícito de 1000/1001 en vez de dejar que una línea de tiempo lo reinterprete en silencio — un desajuste de ese factor deriva un fotograma cada unos 33 segundos, lo que se lee como un error de sincronía que empeora despacio y es uno de los fallos peor diagnosticados de la posproducción.

Preguntas frecuentes

¿El código de tiempo drop-frame pierde imagen?

No. Ni un fotograma. El drop-frame cambia sólo las etiquetas adjuntas a los fotogramas, nunca los fotogramas en sí, y éste es el malentendido más persistente de toda la posproducción. Un programa de una hora en drop-frame contiene 107 892 fotogramas, y uno de una hora en non-drop contiene 108 000 — pero son duraciones distintas, no el mismo metraje con partes quitadas. La hora drop-frame dura de verdad una hora de reloj; la hora non-drop dura una hora y 3,6 segundos. Ambas contienen todos los fotogramas rodados. La analogía útil es el edificio sin decimotercera planta: la numeración salta un valor, el edificio tiene los mismos pisos y no se ha desalojado a nadie. Si conviertes un proyecto de non-drop a drop-frame en un editor, la imagen queda intacta — sólo cambian los números mostrados en la línea de tiempo, y cualquier nota escrita como valor de código de tiempo apuntará ahora a un sitio algo distinto. Ése es el peligro real, y por eso los recuentos de fotogramas, y no las cadenas de código de tiempo, son la moneda segura para intercambiar puntos de montaje entre sistemas.

¿Debo usar drop-frame o non-drop?

Usa drop-frame siempre que la duración deba coincidir con un reloj, y non-drop cuando no. La emisión es el caso más claro para drop-frame: un programa montado a una franja de 60 minutos en código non-drop durará en realidad 3603,6 segundos y se pasará del enlace en 3,6 segundos, suficiente para quedar cortado. La publicidad es igual, ya que un spot se vende por duración. El drop-frame te deja dentro de 3,6 milisegundos por hora, algo que a ningún sistema de programación le importa. El non-drop es preferible allí donde la etiqueta es un índice y no una duración: entregas de efectos visuales, másteres de archivo, copiones, todo aquello en que un plano se identifica por un valor de código de tiempo y la coherencia de la numeración importa más que el acuerdo con un reloj. El non-drop tiene la ventaja de que toda operación aritmética sobre él es simple y nunca falta ninguna etiqueta, lo que elimina toda una clase de errores de desfase de uno cuando los scripts analizan código de tiempo. Dos notas prácticas. El drop-frame sólo existe a 29,97 y 59,94; carece de sentido a 24, 25 o 23,976, y una herramienta que lo ofrezca ahí está confundida. Y elijas lo que elijas, fíjalo una vez al crear el proyecto y no lo cambies a mitad, porque toda nota que alguien haya escrito queda mal.

¿Por qué mi editor rechaza 00:01:00;00 como código de tiempo inválido?

Porque en drop-frame esa etiqueta realmente no existe. La regla salta los números de fotograma 00 y 01 al inicio de cada minuto cuyo número no sea múltiplo de diez, así que el minuto uno empieza en 00:01:00;02. Las etiquetas 00:01:00;00 y 00:01:00;01 nunca se asignan a ningún fotograma, y un editor que las aceptara tendría que inventar un fotograma al que adjuntarlas. Lo mismo ocurre en los minutos 2 a 9, 11 a 19, y así — 54 minutos por hora, dos etiquetas cada uno, 108 etiquetas por hora que sencillamente no forman parte del sistema de conteo. Los minutos 0, 10, 20, 30, 40 y 50 están exentos, así que 00:10:00;00 es perfectamente válido, igual que 00:00:00;00. Si un script o una hoja de cálculo genera valores de código de tiempo aritméticamente y se los pasa a un editor, éste es el fallo que encontrará, y el arreglo es convertir a través de números de fotograma en vez de manipular la cadena: calcula el índice de fotograma, aplica la conversión en forma cerrada y formatea el resultado. Generar etiquetas incrementando campos de texto producirá valores que ningún fotograma drop-frame lleva.

¿Cuántos fotogramas son un spot de 30 segundos a 29,97?

Depende de si los treinta segundos son segundos de reloj o segundos de código de tiempo, y confundir ambos es como se rechazan los spots. Treinta segundos de tiempo real a 29,97 son 30 × 30000 ÷ 1001 = 899,101 fotogramas, así que el corte más largo en fotogramas enteros que cabe en treinta segundos son 899 fotogramas, con una duración de 29,9966 segundos. Treinta segundos de etiquetas de código de tiempo — una duración escrita 00:00:30;00 — son 900 fotogramas, porque el minuto cero no descarta nada, y 900 fotogramas duran en realidad 900 × 1001 ÷ 30 000 = 30,03 segundos. Eso son 30 milisegundos de más, algo que muchas especificaciones de emisión rechazan. El hábito seguro es entregar contra un recuento de fotogramas acordado por escrito y no contra una duración en segundos, y 899 fotogramas es la respuesta convencional para un spot de treinta segundos a 29,97. El mismo cuidado vale en otras duraciones: un spot de 60 segundos son 1798 fotogramas y no 1800, y uno de 15 segundos son 449 y no 450. Si una especificación de entrega indica segundos, pregunta si se refiere a tiempo de reloj o a duración de código de tiempo antes de renderizar, porque ambos difieren exactamente en un fotograma cada treinta segundos y ningún reexport los reconciliará.

¿Por qué mi audio se desincroniza en un clip largo?

Casi siempre un desajuste 1000/1001 en algún punto de la cadena. Si la imagen se reproduce a 23,976 mientras el audio se grabó suponiendo 24, o la imagen va a 29,97 mientras una línea de tiempo cree que es 30, ambos corren a razones que difieren en ese factor y se separan a un ritmo predecible: un fotograma cada unos 33 segundos, seis segundos a lo largo de una bobina de cien minutos. La firma es inconfundible — la sincronía es perfecta al principio, visiblemente mala al final, y el error crece linealmente, lo que lo distingue de un desfase fijo causado por un punto de inicio mal etiquetado. El arreglo es conformar el audio explícitamente con un pull-up o pull-down de 1000/1001 en vez de empujar clips a mano, porque un desplazamiento manual corrige un punto y deja la pendiente intacta. Conviene comprobar dos causas afines antes de recurrir al pulldown. El material transferido desde un origen a 25 fps correrá un 4,1667 por ciento rápido o lento, una divergencia mucho mayor y más veloz, alrededor de un fotograma cada 24. Y las grabadoras cuyos relojes no están enganchados a una referencia común derivan por su cuenta, típicamente unos pocos fotogramas por hora, lo que ningún arreglo aritmético reparará — eso se resuelve alimentando el mismo word clock o referencia de código de tiempo a todos los aparatos antes de la toma.