Postproduccion de audio para video . El Sincro , por José Luis Díaz

Una solución a un problema de post-producción de sonido de largometrajes en el mundo PAL

por José Luis Díaz
tomado de  http://www.jldiaz.com.ar

Aclaración

Este artículo fué escrito en 2005.¿Cuál era la realidad operativa de nuestra industria en aquel entonces?La inmensa mayoría de las películas eran editadas en AVID. Prácticamente nadie lo hacía en Final Cut Pro.

El sonido directo era grabado en Dateras y llegaba al Avid con Time Code de 25fps. El Asistente de Edición digitalizaba el sonido directo en el Avid en tiempo real reproduciéndolo en una datera con TC.

Cuando la película estaba terminada de editar, desde ese Avid se sacaba una lista de corte que era usada por el cortador de negativo para cortar el positivo. Así se conformaba un Acto con 200 ó 300 tomas pegadas con cinta adhesiva transparente.


Ese Rollo era luego transferido a una señal PAL de Standard Definition. El transporte del transfer era movido a 24 fps pero como la salida de video de dicho transfer era PAL, la imagen era una señal PAL de 25fps. Un Segundo seguía siendo un Segundo, sólo que ese Segundo era subdividido en porciones de tiempo diferente.

Esto provocaba que hubiese frames duplicados. Uno cada Segundo.

Bueno, este artículo fué escrito en ese momento tecnológico.

Ahora, al releerlo, me asombra la cantidad de softwares, procedimientos y soportes que hemos cambiado en tan poco tiempo.Pese que el artículo habla de una realidad diferente de la actual, los conceptos que se exponen aquí siguen siendo válidos.

Introducción

Este método resuelve un problema de falta de sincro perfecto, evidenciado en los actuales procesos de postproducción de sonido desde el digital cut o el transfer de positivo, hasta la copia final, incluyendo las versiones VHS y DVD.

Esta propuesta metodológica no involucra cambios radicales en el flujo o en el modo de trabajar. Pero si ofrece certezas de sincros repetibles y exactos.

• Los Síntomas del Problema.
• La Historia del Problema.
• La Solución.
• Implementación Operativa de la Solución (Primera y Segunda parte).
• El Mundo AVI.
• Organizando el Delivery.
• Conclusiones.
• Apéndice I: La Sala de Transfer y la Imagen que Digitalizamos.
• Apéndice II: Una Introducción a QuickTime.
• Apéndice III: Comentarios sobre Cinema Tools.

1. Los Síntomas del Problema

Los que trabajamos en la etapa de postproducción de sonido de largometrajes permanentemente nos enfrentamos con un problema:

Inconsistencia de sincronismo entre el sonido y la imagen durante el proceso de postproducción, incluyendo a la copia final.

¿Como se manifiesta en los hechos esta afirmación?

Para comenzar, al recibir la exportación OMF de sonido que el editor de imagen nos facilita, vemos que casi ningún clip de sonido tiene sincro clavado. A menudo los sonidos están fuera de sincro hasta un cuadro y a veces hasta dos cuadros.

Los extremos, comienzos y finales del sonido que importamos casi nunca están en el comienzo/final exacto de los fotogramas.

Estos sound clips, sound files o regiones (en el lenguaje de Pro Tools - clips o eventos para Nuendo) no se encuentran en lugares “redondos”, sino que comienzan y terminan en algún punto “dentro” del frame sin coincidir con la grilla de nuestra Time Line. Sabemos, sin embargo, que el editor de imagen no ha cortado el sonido en una ubicación diferente de los bordes de los frames de imagen.

Por lo tanto esas exportaciones OMF de sonido deberían coincidir perfectamente con la grilla de frames en nuestras estaciones de trabajo.

Sin embargo, esto no sucede.

Luego, al comenzar nuestra tarea vemos que en varias oportunidades nos cuesta
sincronizar algunas tomas. Por ejemplo, si colocamos en sincro clavado la primera letra “P” o “B” de un texto, algunos otros parlamentos de la misma toma no están con sincro exacto.

Además, si en alguna oportunidad, luego de ajustar los sincros de los sonidos de un acto, se nos da un nuevo transfer del mismo positivo, notaremos que el trabajo hecho con respecto a la exactitud del sincronismo se ha corrompido.


En este nuevo transfer muchos de los cambios de secuencias están corridos un frame. La mayoría de los lugares donde habíamos colocado sonidos precisos, no están donde los habíamos colocado. Algunos sí, pero más de la mitad se encuentran un cuadro corrido.
Todo esto sin que haya habido cambio alguno en el positivo.

Por otra parte, al ver la copia fílmica final encontramos que las decisiones de sincro, ahora lucen equivocadas. Algunos diálogos están claramente fuera de sincro y puestos a mirar en detalle, la sensación es persistente a lo largo de toda la película.

Podríamos atribuir a que esto se debió a que el software editor de imagen habría entregado listas de corte de negativo defectuosas o a que el cortador de negativo cometió algún error. Pero comprobaremos que esto no es así.

Por lo descripto y como enunciamos, sólo vemos inconsistencias de sincronismo entre el sonido y la imagen durante el proceso de postproducción y hasta la copia final inclusive.

No está demás decir que son muchos los procesos involucrados en esta etapa, edición de directo, doblaje, foley, armado de efectos sonoros, etc. y mucho el trabajo invertido en dichas tareas para terminar con un resultado no buscado.

Los que somos suficientemente viejos como para haber llegado a editar sonido en moviolas no recordamos haber lidiado con estos problemas de sincronismo.
Lo que se veía en la moviola era lo que se veía en la sala de mezcla y en la sala de estreno.

¿Qué ha pasado desde entonces?

¿Qué cambió?

2. La Historia del Problema.

 

Este inconveniente comenzó con la introducción de las estaciones de edición no lineal de imagen y de sonido.

A fin de poder trabajar el audio de una película con estas tecnologías, se proveyó a los editores de sonido de una imagen del film transferida sobre un soporte de video. Era la tecnología que se disponía en ese momento, que arrancó esta práctica y que sigue igual hasta hoy.

En el mundo PAL se utiliza un método por el cual la máquina de transfer de imagen mueve al positivo (o negativo) fílmico a una velocidad de 24 fps, colocando las imágenes obtenidas sobre una señal de video PAL, es decir, de 25 fps.

Cualquier persona sabe que 24 no es igual a 25.

Así que, ¿Cómo resuelve la máquina de transfer el problema de distribuir 24 frames fílmicos en 25 frames de video?

La respuestra es, agregando un fotograma extra por segundo.

Este fotograma extra se produce duplicando un campo de video cada 12 cuadros.
El sistema duplica un campo del fotograma 12 y otro campo del fotograma 24 de cada segundo (ver Apendice I).

Recordemos que cada fotograma de video PAL se compone de dos campos (video fields):

- El primero contiene las líneas de barrido impares (1, 3, 5, ...).
- El segundo campo contiene las líneas de barrido pares (2, 4, 6, ...).

Si cada cuadro de video se compone de dos campos, la máquina de transfer convertirá, por segundo, los 24 fotogramas fílmicos iniciales en 48 campos y agregará 2 campos más
.

Así, la cantidad total de campos por segundo será 48 + 1 + 1 = 50.
Y en términos de cuadros por segundo, la cifra será 24 + 1 = 25.

Pero este manipuleo de la imagen juega con el momento en que es presentado cada cuadro, pues los fotogramas de video van “adelantándose” (ver Apéndice I) a los fílmicos (y al sonido) hasta que el error temporal se resetea.

Esto explica porqué vemos que NO todas las consonantes “P” o “B” dentro de una misma toma parecen estar en sincro. Y esto, sin que nadie haya hecho ningún corte en la imagen o en el sonido. Dependerá entonces de como caigan esas consonantes en la cadencia del error temporal. En algunas el error podrá ser 0, en otras podrán estar hasta un fotograma desplazado.

Pero nunca será exacto.

Esto, como ya vimos, complica todas las tareas de edición de sonido durante el extenso proceso de un largometraje.

- ¿Por qué suceden todos estos problemas?

Porque hemos roto la relación Uno a Uno (One to One) entre la imagen con la que trabajamos en la postproducción y el negativo fílmico.

Hemos roto la correspondencia directa fotograma a fotograma, con el agravante de la no repetitividad del error.

Pensando en términos generales, si las películas se filman a 24 fps en todo el mundo, aquí, en España, en USA, o en Líbano y se proyectan a 24 fps en todo el mundo, en Brasil, Filipinas o Mongolia, etc. ¿Por que motivo postproducimos a 25 fps?

Porque, como dijimos, a partir de la llegada de las editoras virtuales no había otra manera de llevarles la imagen a los postproductores de sonido, ya que el formato más cercano, barato y disponible en ese momento era el video PAL.

- La pregunta que surge es ¿Habrá alguna manera de usar los mismos materiales, las mismas máquinas, los mismos reproductores, pero de una manera tal que nos permitan regresar a la confiabilidad del viejo “One to One”?

La respuesta es, Sí la hay.

3. La Solución

La respuesta a este problema es que volvamos a tener la misma cantidad de fotogramas que tiene el negativo y reproducirlos a la misma velocidad a la que fueron expuestos y la que serán reproducidos.

La solución propuesta se basa en manipular ciertas propiedades de los archivos QuickTime, que es una tecnología disponible en este momento.

Para adentrarnos en esta metodología primero debemos definir qué es QuickTime (ver Apéndice II).

Groseramente se podría decir que un archivo QuickTime es una bolsa de datos y una receta que explica cómo reproducirlos.
Los datos en cuestión pueden ser fotogramas de imagen, audio, texto, notas MIDI, gráficos, etc.
La receta explica a qué velocidad deben ser reproducidos esos datos, en qué momento deben aparecer y desaparecer, entre otras muchísimas cosas más.

Si pudiéramos tener todos los fotogramas del positivo (o negativo) en esa bolsa, sin que ninguno de ellos esté duplicado, y pedirle a QuickTime que los reproduzca a 24 cuadros por segundo, estaríamos en la misma condición “One to One” que teníamos en la época de las moviolas.
Es decir, tendríamos el mismo número de fotogramas, la misma velocidad de fotogramas por segundo con que se registraron y la misma velocidad de fotogramas por segundo a la que serán reproducidos en la sala de cine.

El problema es que aunque le digamos a la máquina de transfer “marchá a 24 fps” no hay ningún formato de video estándar cuya cadencia de fotogramas sea 24.
La velocidad del formato PAL es 25 cuadros por segundo (con 50 campos por segundo) y la del formato NTSC es 29,97 cuadros por segundo (con 59,94 campos por segundo).
El único formato de video que realmente corre a 24 fps es el High Definition 24p.
Pero si en lugar de pedir un transfer de video estándar lo pedimos High Definition, ¿en qué soporte recibiríamos este video? ¿Acaso tenemos un player High Definition 24p en nuestros estudios?

Así que, la pregunta es: ¿Cómo lograrlo?

Veamos:

Lo primero a conseguir, será convertir exactamente la misma cantidad de fotogramas fílmicos en fotogramas de video. Con la tecnología corriente la manera más fácil (y única) de obtener este objetivo, es mover el mecanismo del transporte de la máquina de transfer a 25 fps (y no a 24 fps), y colocar esta señal en formato de video PAL.¹

A esta velocidad, cada fotograma fílmico tiene su hermano gemelo de video.
Obtenemos así la relación “One to One”.
Esta será una cadencia de video PAL ordinaria, común y corriente. Sin ningún campo o frame duplicado. Y podemos digitalizarla y convertirla en un archivo QuickTime de 25fps común y corriente.
Sólo tenemos un problema: la imagen resultante es un 4,16666667% más veloz que como fue filmada y que como será reproducida.

En este punto necesitamos decirle a QuickTime ... “Reproducí más lentamente cada uno de estos fotogramas que tenés en esta bolsa. Exactamente un 4,16666667% más lento”.

O dicho de otro modo ... “Cada fotograma de esta bolsa nació con una receta de reproducción según la cual cada cuadro debía ser mostrado durante 1/25 de segundo (40 milisegundos). Pues bien, quisiera que modifiques dicha receta y hagas que la duración de cada fotograma sea de 1/24 de segundo (41,6666667 milisegundos), que era la duración de estos fotogramas cuando fueron filmados y que será su duración cuando sea proyectados en un cine”.

Si pudiéramos cambiar ese dato en la receta restableceríamos la relación firme y buscada del Uno a Uno, del “One to One”.

¹ Esto no es nuevo. El mundo de la publicidad en los paises PAL trabaja de esta manera. Se filma, se transfiere, se edita, se mezcla y se reproduce a 25 fps.

4. Implementación Operativa de la Solución
Primera parte

¿Cómo podemos establecer este diálogo con QuickTime?

La herramienta que lo permite es el programa Cinema Tools de Apple.
Este es un software compañero de Final Cut Pro. Con Cinema Tools el camino para convertir una película QuickTime de 25 fps a 24 fps es simple y veloz.
Veamos como hacerlo: Una vez abierto el programa debemos ir a File > Open Clip, y navegar hasta seleccionar la película. Luego de ello se abrirá una ventana con la película seleccionada y algunos botones.

Si cliqueamos en el botón “Clip Analysis...” una ventana con toda la información relevante se abrirá ante nosotros.

Demos “OK” y cliquéemos en el botón “Conform...”

Esta nueva ventana nos informará que el frame rate de esta película es efectivamente 25 fps, tal como salió de la sala de transfer. Si cliqueamos y mantenemos presionado el botón del mouse sobre 25.0 luego de “Conform to:”, veremos las opciones de conversión de frame rate que ofrece este programa.

Elijamos 24.0 y apretemos el botón “Conform”. Este proceso tardará unos 2 o 3 segundos. A su término, si volvemos a cliquear en la opción de “Clip Analysis...” verificaremos como cambiaron los datos relevantes.

Así comprobamos que:

• En primer lugar, se informa que el frame rate es ahora 24 fps, cuando antes era 25 fps.
• En segundo lugar, la duración ahora es 1 minuto, 2 segundos con 14 frames, cuando antes era 1 minuto, 0 segundos, 2 frames, que es lo que debería durar si la película original se reprodujera a 24 fps. Es decir, un 4,1666666667 % más lento que el original.
• En tercer lugar, si comparamos los promedios de demanda de ancho de banda (average data rate) de ambas versiones, veremos que sus valores han cambiado proporcionadamente. Mientras la original de 25 fps era de 599 KB por segundo, la de 24 fps es de 575 KB por segundo. O sea que una película de 24 fps reales será un poco menos demandante de consumo de ancho de banda interno de nuestra CPU que otra de 25 fps. Mejor para nuestro ProTools.

Verifiquemos ahora la cantidad de fotogramas. Primero la original a 25 fps.
Dijimos que duraba un minuto y 2 fotogramas.

(25 fotogramas x 60 segundos = 1500 fotogramas) + (2 fotogramas)

1500 fotogramas
+ 2 fotogramas
1502 fotogramas

Ahora hagamos las cuentas de la versión conformada a 24 fps. Dijimos que duraba 00:01:02:14.

(24 fotog. x 60 seg. = 1440 fotog.) + (24 fotog. x 2 seg. = 48 f.) + (14 f.)

1440 fotogramas
+ 48 fotogramas
+ 14 fotogramas
1502 fotogramas

Es decir que este procedimiento garantiza que la cantidad de fotogramas sea la misma independientemente de a qué velocidad se los reproduzca (@25 o @24 fps).

Comprobemos ahora si la duración total de la nueva película es correcta usando una calculadora de Time Code.
La abrimos, seleccionamos Film y en Frames tipeamos 1502.

Al dar Enter le estaremos pidiendo que nos muestre la duración de una película que contenga esa cantidad de fotogramas cuando se mueve a 25 fps.

Correctamente nos dice el valor que duraba la película QuickTime original, cuando al hacer play lo hacía a 25 fps.
Luego le pedimos que nos muestre la duración de una película que contenga esa misma cantidad de fotogramas (1502) pero moviéndose a 24 fps.

Esa (00:01:02:14) fue la duración de la versión procesada con Cinema Tools.

Podemos decir entonces y con toda seguridad, que hemos satisfecho las necesidades del “One to One”.

Segunda parte

- ¿En que altera nuestra manera de trabajar una imagen así, a 24fps?

En muy poco.
Hablemos de la herramienta que casi todos los sonidistas usamos, ProTools.
Bastará cambiar en la ventana Session Set Up (Command + 2) el Time Code Rate desde nuestro estándar 25 a 24fps. De este modo, los bordes de los fotogramas del video (convertidos ahora a 24 fps) coincidirán con la grilla del Time Code de la ventana de edición. No hace falta un reproductor especial de esta clase de películas QuickTime @24 fps. El mismo reproductor estándar QuickTime entiende esta receta, sabe qué hacer con esos fotogramas y puede hacerlo. Dicho de otro modo, a QuickTime le da lo mismo reproducir una película a 24 o a 25 fps, por la misma razón que le dá lo mismo hacerlo a 29.97 o a 30 fps. Para el programa reproductor se está hablando del mismo grado de dificultad.

Otra virtud de este cambio:

Ahora, los sonidos importados desde las islas de edición off line caerán en los bordes exactos de la imagen a 24 fps.
¿Por qué? Porque la Time Line de los programas editores de imagen que se usan en largometrajes (Avid Film Composer, Final Cut Pro, etc) es de 24 fps. O sea que sus exportaciones tienen todas las propiedades de esa regla de medición de tiempo.

¿Y qué pasa con la mezcla?

Pues, no mucho.
En el caso de las salas de mezcla que trabajan con imágenes que salen desde una placa de video instalada dentro de la CPU de la computadora habrá que ir a la ventana Session Set Up del ProTools de la sala de mezcla y cambiar el Time Code Rate de 25 a 24 fps. Casi todos los proyectores de video y la totalidad de los proyectores de data (VGA, etc) se llevarán bien con esta señal.

Las salas de mezcla internacionales equipadas con proyectores de película y no de video, usan una interfase para convertir los pulsos de cuadratura bifase del proyector al formato de TC al gusto del ingeniero de la sala. Se trata de cambiar seteos muy simples para que en lugar de correr un TC de 25 fps corra un TC de 24 fps por las venas del estudio. Todas las consolas de mezcla aceptan, para atender a su automatización, todos los formatos de time code.
Es decir, no se hacen unas consolas para Europa y otras para USA. Son las mismas. Es un simple cambio de seteo.

Pero incluso hay muchas que siempre trabajaron distribuyendo un TC de 24 fps. Es el caso de Cine Arte de Madrid. Cuando uno llegaba a mezclar a esa sala lo primero que cambiábamos en el ProTools reproductor de nuestros tracks era el Time Code Rate de la sesión desde nuestros originales 25 a los 24 fps estándar de Cine Arte. Ellos tienen la sala configurada con ese estándar. De todas maneras, en la hipótesis de que hubiese una sala de mezcla que no aceptase otro TC que no sea el de 25 fps, pues bien, sin ningún esfuerzo cambiaríamos nuestro Time Code Rate de nuestros 24 a sus 25 fps y listo. Pro Tools se sincronizará contra 25 fps en lugar de hacerlo contra 24 fps. Pro Tools seguirá reproduciendo la misma cantidad de samples por segundo. No se acelerará ni se ralentará.

Queda pendiente otro ítem, el Time Code en pantalla:

Vamos a ver. La principal utilidad de la ventana quemada de Time Code en pantalla en una imagen transferida a video es la de verificar que durante el proceso de digitalización la placa de video no se haya “comido” algún cuadro.
Raro, pero no imposible.
La sala de transfer suele quemar una ventana de Time Code en la parte alta del fotograma.

¿Qué formato de Time Code?
De 25 fps, claro.

Con el método propuesto, al someter dicha imagen al estiramiento de tiempo via Cinema Tools el Time Code quemado y convertido en parte de la señal de video dentro de cada fotograma será también, obviamente, “estirado”.
Entonces tendríamos una película a 24 fps con una ventana quemada que tiene un TC equivocado.

Como el procedimiento es sincronizar la película QuickTime contra la Time Line, de modo tal que el TC de la ventana quemada de la imagen coincida con el Time Code de la Time Line del ProTools, luego del primer segundo dejarán de coincidir. Después de los primeros 24 fotogramas se irán diferenciando a razón de un cuadro por segundo acumulado a partir del principio de la película.

¿Existe alguna información, señal o data que pueda acompañar a cada fotograma en forma independiente a su velocidad de reproducción, que nos identifique inequívocamente cada fotograma y que comprendan tanto el operador como el equipo editor de sonido?

Sí. Pies y Fotogramas, “Feets and Frames” (F&F).

F&F es estándar en países como USA. Lo era también en el proceso del Print Master de Dolby Digital antes de la llegada del equipo DMU. Eran feets and frames la información que pedía la PC de Dolby para saber donde estaba el primer fotograma del acto y donde el último. Así se podía hacer el Pull Up que adhiere los primeros sonidos del siguiente acto al final del anterior de modo de minimizar las molestias en los cambios de actos. Y, obviamente, también es estándar en todos los pasos internos de los laboratorios de imagen.

Otros indicios de su estandarización es que ProTools lo incluye como opción en sus contadores, que la cola numerada con la que iniciamos cada acto tiene exactamente 12 pies + 00 frames y que el beep está exactamente en el pie 9 + 00 frames a partir del Start.

Pero, un momento, ¿dónde debe comenzar el conteo de F&F?
El 0000 Feet + 00 Frame debe estar en el Start de la cola numerada de modo tal que a los 9 Pies + 00 Fotogramas esté el Beep y que a los 12 Feets + 00 Frames esté el primer fotograma del acto.
Pero si pedimos a la sala de transfer “quémen F&F en lugar de Time Code”.
¿Como procedemos en el ProTools?

Es más fácil de explicar en la versión 6.4 (y superiores) de ProTools, pero también es realizable en las anteriores.

En PT 6.4 (o superior) debemos setear en el pull down menu Windows > Show Session Setup, el Feet + Frame Ratio en 24 fps. En la Edit Window, uno de los dos contadores (el Main o el Sub) debemos pasarlo a Feets + Frames y el otro dejarlo en Time Code. ¿Por qué? Porque a veces debemos hacer preguntas al editor de imagen, como algo que no entendemos y que está en tal Time Code. ¿Qué Time Code le diremos? El mismo que él tiene en su Time Line. ¡Pues su Time Line es de 24 fps! ¡Y no de 25 fps!

Sigamos. A continuación sincronizamos el primer fotograma de imagen del acto contra la hora que identifica el número de acto (la hora 01:00:00:00 es el primer cuadro del Acto 1 y así sucesivamente). Luego retrocedemos 8 segundos, 00 frames. Ahí debe estar la palabra Start en la cola numerada.
Porque 8 segundos exactos (12 pies con 00 frames en 35mm) es la duración desde el Start hasta el primer fotograma del acto (FFOA, First Frame Of Action).

Dejando el cursor en ese lugar, debemos ir al pull down menu Setups > Redefine Current Feet + Frames Position...
Una ventana aparecerá. En el campo de Feet + Frames tipeémos 0.
Y demos OK.

A partir de ahora el contador seteado en Feets + Frames está sincronizado con la ventana quemada de nuestro QuickTime. Debemos ir al último fotograma del acto para verificar si coinciden entre sí los Feets + Frames en ventana quemada del QuickTime con el contador en Feets + Frames del ProTools. Si no coinciden, durante el proceso de digitalización de la imagen uno o más frames han sido “comidos”.

Si para definir una posición dentro de la película nos es más cómodo, por costumbre o por alguna otra razón, seguir trabajando con la estructura visual y nemotécnica de TC, lo podemos seguir haciendo y así el display de F&F debería ser el contador secundario, o Sub, que solo será usado para chequear que ningún frame haya sido elidido durante la digitalización. Usaremos entonces el Main y el Big Counter en TC (de 24 fps).

En el caso de versiones 5.x.x de ProTools, la manera de decirle al programa que queremos que el contador de F&F comience a contar desde 0000 Feets + 00 Frames a partir de un lugar dado de la Time Line, es decirle que ahí está la Session Start Time. En el caso del Acto 1 deberemos iniciar la sesión en 00:59:52:00. En el caso del Acto 2 será en 01:59:52:00. La Session Start Time se setea en Windows > Show Session Setup.

Un posible encordio en las versiones 5.x.x sucederá si la película tiene algún fotograma antes del Start. Dado que ProTools no dejará que nada vaya a parar en su Time Line antes del tiempo marcado en su Session Start Up.
Habría pues que cortar toda imagen anterior al fotograma con la palabra Start.

Esto solo es necesario en las versiones 5.x.x.
Las sessiones iniciadas en versiones 5.x.x con este seteo de contadores son 100% compatibles con las versiones 6.x.x. Las sesiones iniciadas en versiones 6.x.x son 100% compatibles con 5.x.x en la medida que la imagen no tenga ningún fotograma anterior al Start.

Ahora surge una pregunta.

¿Se podría aprovechar este método en las películas en las que no se hace transfer de positivo para la postproducción de sonido?

Sí.

En los casos en que la edición de imagen se haya realizado en un equipo Avid Film Composer, a la hora de hacer el Digital Cut para nuestro trabajo, el Avid pregunta al operador, “¿A qué velocidad reproduzco la Time Line abierta: a Film Rate (24 fps) o a Video Rate (25 fps)?”
Los únicos Digital Cuts que hemos conocido cuando se trataba de un proyecto cinematográfico estándar eran los salidos a Film Rate. En esos casos, es el Avid el que duplica un frame cada segundo cuando se lo setea así. Tenemos aquí los mismos encordios que si se hubiese hecho un transfer a 24 cuadros por segundo sobre una señal PAL y que estamos tratando de superar.

En cambio en la otra opción, Video Rate, Avid reproducirá las imágenes de su Time Line a la misma velocidad que las digitalizó: a 25 fps.
Porque recuerden que la única manera que tiene Avid y cualquier otra editora virtual de imagen, de poder expulsar una lista de corte sana para los cortadores de negativo es saber clara e inequívocamente como se llama cada uno de los fotogramas involucrados en su Time Line.
Avid también necesita, y por eso utiliza, la dichosa relación “One to One”.
En su caso lo logra a partir de recibir transfers hechos a 25 fps del negativo diario de rodaje. Al hacer play duplica un frame por segundo para que esas imagenes se vean “aceptablemente” sincrónicas con el sonido directo (al que no modifica su velocidad) porque su Time Line es de 24fps.

Si recibiéramos un Digital Cut a Video Rate sería para nosotros exactamente igual que si recibiésemos el tipo de transfer que estamos proponiendo en este método. O sea, una vez digitalizado el Digital Cut (a Video Rate) y cambiada la receta de reproducción (los headers del QuickTime) por Cinema Tools, estaríamos en la deseada, y tan largamente explicada aquí, condición “One to One”.

El abordaje de Final Cut Pro (FCP) a este problema es diferente.
FCP también necesita, al igual que Avid, mantener una relación One to One con el negativo de imagen para poder garantizar que sus listas de corte sean fieles. Pero FCP no duplica un fotograma por segundo (como lo hace Avid) sinó que estira la duración de cada frame en un 4.16666667% (de 1/25 del transfer a 1/24 de segundo). De modo tal que la Time Line de un proyecto de largometraje en FCP tiene 24 fotogramas por segundo (igual que Avid).

FCP es capaz de exportar un QuickTime a 24 fps directamente desde su Time Line sin necesidad de procesar nada con Cinema Tools. O sea que si el editor del largometraje al que vamos a hacer el sonido edita con FCP, le podremos pedir que nos exporte en formato QuickTime y a 24 fps los “Digital Cut” de los actos del largo, ya que estos tendrán una relación “One to One” con el negativo que la Time Line refiere y con la lista de corte de negativo.

Finalmente, sería bueno que la sala de transfer nos queme una pequeña ventana en alguna esquina superior con la leyenda “Acto 1”, “Acto 2”, etc., a todo lo largo de cada acto. Decimos que sería bueno, ya que al solicitarle a la sala de transfer nos queme la información de F&F y no la de TC, no tendríamos más la hora del TC como recordatorio del acto en que estamos trabajando. Cosa que sigue siendo útil.

¿Que sucederá con los sincros cuando una película posproducida con imágenes a 24fps se distribuya en VHS y en DVD?

Vamos a ver. Para hacer duplicación VHS se parte de un Master PAL. Un Master PAL es un transfer de negativo o Dup moviendose a 25fps sobre formato de video PAL. Como ya se explicó, este transfer generará tantos fotogramas de video como tenga el film original. No tendrá fotogramas duplicados. Este transfer será exactamente igual a los transfers de trabajo que nos direron para hacer la postproducción de sonido.
Ergo, el sincro será en un 100% igual que la cópia final, que el que vimos en la sala de mezcla, que el que vimos en nuestro ProTools.

¿Qué pasará con la distribución en DVD?

En Argentina, para hacer duplicación de DVD se parte de un Master NTSC.
Hay tres maneras de lograr este transfer: 1) por transcodificación desde Master PAL, 2) por transfer de negativo o Dup a señal de video NTSC y 3) por medio de reproducir un Master Hi Definition 24p a 23.976fps y hacer una downconversion desde los 1080 lineas a las 625 del PAL.

Si el camino que elije el productor es por transcodificación desde Master PAL el resultado final será semejante al obtenido en la distribución VHS. El mismo porcentaje de aceleración del programa sonoro que hicimos para VHS será el que tengamos que hacer para entregar el sonido al creador del DVD.

Si el productor elige hacer transfer NTSC o downconvert desde el Master 24p, el negativo o Dup se moverá a 23.976fps en la máquina de transfer. Es decir, la imagen estará un 0,1% más lenta que la velocidad a la que fué filmada y a la que el sonido fué grabado, editado y mezclado. Bastará con que nosotros ralentemos el programa un 0,1% para que todos los sincros que batallamos durante la post de sonido se conserven en un 100%.

5. El Mundo AVI

Una de las cosas que hace interesante a la idea de posproducir el sonido de un largometraje con películas a 24 fps es que este concepto no es restrictivo exclusivamente al mundo QuickTime. También en el mundo AVI lo podremos aplicar. No será entonces con Cinema Tools sino con otras herramientas que se podrá cambiar el frame rate de un archivo AVI.

Pero, ¿Qué es AVI?

El Audio Video Interleaved (AVI), el cual fue definido por Microsoft al principio de los años 90, es el formato más común de data de video y audio en las PC's. Su organización interna es muy semejante a la de QuickTime, al menos a nuestros ojos de usuarios. AVI es el nombre del container de las “Películas” en el mundo de las PC's. Aunque con nombres diferentes, sus partes funcionan de modo muy similar. Lo que en QuickTime se llama Atoms, en AVI se llama Tags, por ejemplo.

Pues bien, hemos encontrado varios programas freeware que hacen lo que necesitamos. Al menos dos de ellos parecen haber sido creados para nuestra necesidad: cambiar los Tags específicos de las “Películas” AVI para que las que han nacido a 25 fps sean reproducidas a 24 fps. Es decir, estos programas modifican el Tag que define la duración de reproducción de cada fotograma de la película de los iniciales 40 milisegundos (1/25 de segundo a 25 fps) a los 41,66666667 milisegundos ( 1/24 de segundo) para que su velocidad sea 24 fps.

El primero de esos programas se llama AVI Frate (AVI Frame Rate Changer v 1.10). Es el más simple de todos y se puede bajar:

http://www.doom9.org/software.htm

Una vez alli hay que cliquear en Download y buscar el link “full software link”, allí y dentro de la subcategoría “AVI Editing Tools”, se encontrará el AVI Frate v1.10 (solo pesa 138KB).

O desde:

http://www.free-codecs.com/download/AVI_Frame_Rate_Changer.htm

El segundo se llama AVI Frame Rate Adjust v 1.00 (pesa solo 60KB) y se consigue ingresando a:

http://www.afterdawn.com/guides/archive/how_to_fix_avi_sync_problems.cfm

Veamos cómo trabajar con el “AVI Frate”:

Abrimos el programa. Una ventana muy pequeña y sencilla aparecerá.
Cliqueamos sobre el ícono de la carpeta, lo cual nos permitirá navegar hasta encontrar la película que queremos procesar.

Para abrir archivos

1- Abrimos el programa

2- Buscamos el archivo que queremos procesar.

Una vez seleccionado y abierto el archivo AVI, automáticamente, en el campo “Current Frame Rate”, nos dirá el frame rate del mismo, es decir 25 fps.

3- Abrimos el archivo.

En el único campo editable de la ventanita cliqueamos y buscamos la cifra 24.
Liberamos allí el mouse, y damos “Apply”.

4- Elegimos el nuevo frame rate.

5- Damos Apply.

Una nueva ventanita nos dirá que un nuevo frame rate será aplicado al archivo. Demos “OK”.

6- Cliqueamos en OK para finalizar la operación.

¡Listo!

De aquí en más este archivo será visto por programas como Adobe Premiere Pro, Nuendo, Sonar, etc., como de 24 fps.

Veamos, ahora, cómo trabaja el “AVI Frame Rate Adjust”:

Al abrir el programa se desplegará la siguiente pantalla.

1- Abrimos el programa.

Deberemos cliquear en el botón “Open” superior para abrir el archivo AVI.

2- Buscamos el archivo.

Abrimos el archivo y nos aparecerá la información sobre sus propiedades actuales.

3- Propiedades del archivo.

Una vez abierto el archivo tipeamos, en el único campo editable, el de “fps”, el nuevo frame rate que queremos aplicar. En este caso, es de 24 cuadros por segundo.

4- Nuevo frame rate tipeado.

Ahora damos “Save” y con ello efectuamos el cambio. Se modificará la duración de la película en modo proporcional a la nueva velocidad.

5- Nueva información de las propiedades del archivo.

Cabe destacar que este último programa subdivide el segundo en milisegundos. Asi, los 80 milisegundos de la duración inicial de 00:01:00:080 a 25 fps de duración deben leerse como dos fotogramas. Pues a 25 fps cada fotograma dura 40 milisegundos. Lo mismo vale para el resultado final a 24 fps.

6. Organizando el Delivery

Por todo lo expuesto surge que la forma más eficiente de recibir las imágenes de las películas para realizar la posproduciion de sonido, es dentro de un container QuickTime y recibiendo dichos QuickTimes en soporte CD o DVD. El copiado a nuestro disco rígido sucede a velocidades muy superiores al tiempo real desde el soporte de video.

A su vez, ya vimos que el cambio de variables en la receta de reproducción es instantáneo y no destructivo.
Además, las posibilidades de errores involucrados en las mudanzas de datos de un soporte a otro, son inexistentes.
El costo del soporte (CD o DVD) es bajo.

En contraste, hay muchas más posibilidades de problemas mecánicos en soportes de video: U-Matics, Beta SP, VHS, DV, etc...

Los soportes de video están muy expuestos a la suciedad, al desgaste, a diferencias de ajustes entre el grabador y nuestro equipo reproductor, etc.
Su costo es importante.
Los transportes de video son costosos como lo es también su mantenimiento.

Por otra parte, permanentemente surgen nuevos formatos de soporte (por supuesto totalmente incompatibles entre sí) o de tipo de señal de video (24p es un buen ejemplo). Seguir invirtiendo en equipos de reproducción de video pasa a ser innecesario para desarrolllar nuestros trabajo.

7. Conclusiones

El método expuesto permite:

a) Garantizar la consistencia de los sincros decididos durante la postproducción de sonido hasta las cópias fílmicas finales. Esta consistencia alcanza a todas las variantes de distribución: VHS o DVD, PAL, NTSC o 24p.

b) Mantener en un 100% el mismo sincro a través de cualquier nuevo transfer de la misma imagen.

c) Cambiar los headers fácil y rápidamente. Esto es seguro, reversible y no destructivo.

d) Implementar una ventana con la información de Feet + Frames que facilita traducir el FFOA (First Frame Of Action), y el LFOI (Last Frame Of Image) que pide el procesador de Dolby cuando hacemos el Print Master de Dolby Digital, y controlar la no pérdida de fotogramas durante la digitalización.

e) Obtener el beneficio del delivery de la imagen transferida de los actos de los largometrajes sobre soportes de CD o DVD, y dentro del container QuickTime. Esto es beneficioso tanto en lo económico, y en la velocidad de la ingesta de estos datos (por suceder a menos que el tiempo real), como por su flexibilidad, ya que no necesitamos tener en nuestros estudios transportes de media de cada nuevo formato que emerja.

APÉNDICE I: La Sala de Transfer y la Imagen que Digitalizamos

Este Apéndice pretende explicar dos cosas:

a) ¿Qué sucede en la máquina de transfer cuando le pedimos que coloque en un tren de señales de video PAL las imágenes residentes en un positivo (o negativo) movidas a 24 fps? Y...

b) ¿Qué pasa cuando digitalizamos esta cadencia de video?

Como decíamos en el cuerpo principal de este artículo, la máquina de transfer duplica un campo de video cada 12 cuadros.
En la figura se muestran alineados un segundo de fotogramas fílmicos (24 frames) nombrados desde el foto “A” hasta el “X”. Debajo están mostrados los fotogramas de video que salen de la máquina de transfer.

Nota: el sub-índice indica el número de campo.
₁ indica el campo impar y ₂ el par.

Al ordenarle a la máquina de transfer que queremos que su output de video sea PAL, no tendrá otro remedio que dividir el segundo en 25 segmentos. Dado que las imágenes fílmicas en ese período de tiempo son 24, duplica, como ya dijimos, un campo del fotograma “L” y otro del fotograma “X” (esos campos están señalados en color celeste y bajo el nombre de Campos Extras).

Supongamos que pudieramos tener, una al lado de la otra, dos máquinas reproductoras mecanicamente sincrónicas entre sí: Una máquina reproduciría los fotogramas fílmicos y la otra, los fotogramas de video. Al avanzar cuadro a cuadro, claramente veríamos como los fotogramas de video se adelantan² a los fílmicos.

² El término “adelantar” no es exacto. Obviamente, la máquina de transfer no puede adivinar que fotograma fílmico viene a continuación. No sabe si será un paisaje, una soga de ahorcar sobre un patíbulo, o un primer plano del protagonista. Por lo tanto, los fotogramas fílmicos no pueden adelantarse. Lo que sucede es que el transfer tiene un buffer en el que guarda un campo de video PAL (20 miliseg.) liberándolo en el tiempo según la necesidad que le plantea el standard de video PAL. Por otra parte, el tren de TC es retrasado en esa cantidad de tiempo. Como resultado, al dibujar, con un inicio simultáneo, los dos chorros de fotogramas (el fílmico y el de video) se observa el adelantamiento mencionado.

A medida que avanzamos en el tiempo observamos una mayor diferencia o error temporal. Al llegar al fotograma de video compuesto por los campos L₁ y L₂ la máquina de transfer duplica el campo par L₂. Así, el fotograma de video número 13, se compone de un campo L₂ y un M₁. Con esta acción el error temporal se reseteó a cero, ya que en el momento en que comienza el fotograma fílmico “M” hay un campo de video que lo está mostrando, el M₁. Pero a partir de aquí, el error temporal nuevamente comienza a crecer. Al duplicar el campo L₂, la máquina de transfer empujó hacia atrás en el tiempo la llegada del primer campo de video que se refiere al fotograma fílmico “M”.
Dicho en otros términos, la máquina de transfer retrasó en el tiempo al campo M₁ hasta dejarlo en sincro.

Habíamos llegado entonces hasta el fotograma de video compuesto por los campos L₂ y M₁. Durante el próximo medio segundo los fotogramas de video se compondrán de un campo que corresponderá al fotograma fílmico anterior y otro campo que corresponderá al fotograma en curso. Así, hasta que el último fotograma de video de ese segundo, se compondrá de los dos campos pares correspondientes al fotograma fílmico “X”. Hasta aquí, el máximo error temporal que el transfer generará es de medio fotograma. No se trata de un error fijo, sino que el adelanto de la señal de video respecto de su original fílmico es continuamente variable entre 0 milisegundos (perfecto sincro), en los fotogramas de video A₁A₂ y L₂M₁, y 20 milisegundos (medio cuadro @25 fps), en los fotogramas de video L₁L₂ y X₂X₂.

Los cassettes U-Matic, Beta SP, VHS o DV que recibimos de la sala de transfer contienen esta cadencia y estos errores temporales. Pero al digitalizar esta cadencia agregamos otra imprecisión: Casi todos nosotros, como casi todos los editores no lineales de imagen, digitalizamos un campo por fotograma de video y no los dos. Esto se hace para no sobrecargar el ancho de banda de los buses internos de la CPU's de nuestra Digital Audio Workstation. Si solo digitalizamos uno de los dos campos se reduce a la mitad la demanda de ancho de banda interna exigida para este destino. Es un gran beneficio. Por otra parte, durante la primera mitad de cada segundo, el segundo campo, el de las lineas pares, es casi exactamente igual al de las lineas impares. No hay allí ninguna información diferente al primer campo. En la sala de transfer, cada fotograma fue escaneado dos veces: Una vez por las lineas impares del primer campo, y otra vez por las lineas pares del segundo campo. Durante todo el tiempo en que se realizaron estos dos barridos, el fotograma fílmico estuvo inmovil en la ventanilla de escaneo.

Esto es diferente de lo que sucede con los campos explorados de una cámara de video standard interlaceado que apunta a la vida real, a unos actores, a un coche que pasa, etcétera. En estos casos, cada uno de los dos campos de cada fotograma de video podría ser diferente entre sí, pues mientras transcurre el escaneo, la realidad se va modificando.
En cambio, al escanear un fotograma fílmico, la realidad está congelada en él. Ya fue congelada por la cámara cinematográfica. Por lo tanto, el segundo campo será prácticamente igual al primero. Por ello, tiene mucho sentido usar solo un campo. Y por ende, es indistinto digitalizar el impar o el par.

Supongamos, entonces, que elegimos digitalizar el impar, el primero que nos llega. Hagámoslo mirando el diagrama que ya conocemos.

Al digitalizar el campo impar la cadencia digitalizada será:

A₁ B₁ C₁ D₁ E₁ F₁ G₁ H₁ I₁ J₁ K₁ L₁ L₂ M₂ N₂ O₂ P₂ Q₂ R₂ S₂ T₂ U₂ V₂ W₂ X₂
(y la rueda se repite)

Vemos que durante los primeros 12 fotogramas de video se digitiliza el campo impar (1). Esto es así hasta llegar al fotograma fílmico “L”. Este fotograma será digitalizado dos veces. Primero el campo impar, y luego el campo par. Por eso lo pusimos en rojo. Para destacarlo y reconocerlo. De las dos duplicaciones de campos, que la sala de transfer genera por segundo, s´olo será digitalizada por nosotros una de ellas: La perteneciente al fotograma fílmico “L”. La duplicación del campo perteneciente al fotograma fílmico “X” no será digitalizada, ya que el primer campo que nos llega de dicho fotograma fílmico (el X₁) se encuentra ocupando un campo par, que no es el que digitalizaremos. El segundo campo que nos llega del fotograma “X” (el X₂) será el que ocupe el lugar impar, ergo, será digitalizado. Así, digitalizaremos el fotograma fílmico “X” una sola vez, ya que su duplicación (el segundo X₂), se encuentra en el último campo par.

Si hubiéramos elegido digitalizar solo los campos pares, el fotograma que veríamos duplicado sería el X, y no el L. Pero sea como sea, al pedirle a nuestro software digitalizador de imágenes que digitalice un solo campo, cualquiera sea, estaremos aumentando al doble el error temporal que salió de la sala de transfer. Por lo tanto, en la práctica, este sistema provoca un error acumulativo que llega hasta un frame. El doble del que aportó la máquina de transfer.

Con estas imagenes que conllevan estos errores temporales es con la que estamos trabajando en el mundo PAL.

APÉNDICE II: Una Introducción a QuickTime

No consideramos vital la comprensión de las entrañas de QuickTime, pero sorprende la poca difusión de su concepto, sus componentes, las implicancias, y cómo se puede jugar con ellos. QuickTime es realmente complejo. Una mirada a sus variables lo deja a uno impávido. Son muchísimas. Veamos solo lo muy, muy básico.

QuickTime utiliza la metáfora de una “película” para describir datos basados en el tiempo. Cualquier dato basado en el tiempo puede ser organizado como una “película” (video, audio o ambos). Estas “películas” son cápsulas, containers, que sostienen toda la información necesaria para organizar los datos en el tiempo, pero no contienen los datos (imágenes, sonido, etc.) en sí mismos. Es decir, estamos hablando de la receta o instrucciones que explican cómo reproducir los datos. Las “películas” están hechas de chorros de datos llamados Tracks y cada track referencia y organiza una secuencia de datos en una manera ordenada en el tiempo. Para hacerlo, losTracks contienen Estructuras de Media que referencian a los datos reales (imágenes, sonidos, etc.). A su vez, la Media está organizada dentro del track en pedazos (chunks) de datos de Media llamados Media Samples. Una típica “película” QuickTime contiene la estructura de la película y su Media ensambladas de modo tal que resulte fácil transportarla o bajarla por internet, por ejemplo.

Dicho de otro modo, QuickTime consiste en tres niveles principales:

- La Media,
- Los Tracks y;
- La Película (Movie).

La Media es la estructura de datos de más bajo nivel, y es, en realidad, el video/audio/texto en sí mismo. La Media está organizada en Samples, que pueden ser fotogramas en el caso de video o samples en el caso de audio, por ejemplo.

Los Tracks son las estructuras de datos que describen la localización de la media y que organiza su correcta decodificación (un decodificador para el audio, otro para el video, etc.).

La Película es el elemento constitutivo de QuickTime de más alto nivel. Es el container donde todos los tracks individuales se juntan. La Película es también la responsable de mantener cada uno de sus tracks en sincro entre sí.

Con respecto a su estructura, la misma está dividida en una multitud de parámetros. Veamos solo los que más nos interesan.

Movie Time - Sistema Coordinador de Tiempo:

La “película” QuickTime organiza la media a traves de la dimensión temporal. Para manejar esta dimensión, QuickTime define un Sistema Coordinador de Tiempo. Este sistema coordina “películas” y estructura de datos de Media con un sistema de medición común entre todas, el SEGUNDO. Cada sistema coordinador de tiempo establece una Escala de Tiempo, y dicha escala establece la traducción entre el tiempo real y el tiempo de la “película”. Las escalas de tiempo están denominadas en X unidades de tiempo por Segundo. El sistema coordinador de tiempo también define la duración de la “película”, o la estructura de Media, en términos de unidades de tiempo. Por lo tanto, un momento en particular de una “película” puede ser identificado por el número de unidades de tiempo que lo separan del comienzo.
A su vez, cada track en una “película” tiene un offset y una duración. Estos atributos determinan cuándo un track debe comenzar a ser reproducido y por cuánto tiempo. Cada estructura de Media también tiene su propia escala de tiempo, la cual determina la cantidad de unidades de tiempo default, por samples de datos, de cada tipo de Media.

Time Scale

La escala de tiempo es la regla maestra para una “película”. Cada evento dentro de una película es medido y localizado por medio de la escala de tiempo, y dicha escala es expresada en unidades por segundo. La duración de un elemento de una “película” es el número de unidades de escala de tiempo desde su comienzo hasta su final.
Cada track en una película tiene también un offset que es especificado en unidades de escala de tiempo. Este offset es el punto de comienzo del track. Un track que comienza en el mismo momento que la película tiene un offset de 0 (cero).

Cada película tiene un sistema coordinador de tiempo, pero ese sistema puede diferir de “película” a “película”. La escala de tiempo en un sistema coordinador de tiempo en una “película” debería tener un número conveniente de fracciones de un Segundo. El número de la escala debería ser uno que haga fácil la traslación de los tiempos de una “película” a otra escala de tiempo.

Una escala de tiempo de una “película” de 600 (la escala de tiempo default de cada nueva “película” QuickTime) puede traducir una velocidad de playback de 24 fps. Con una escala de tiempo de 24 fps, cada frame sería mostrado durante 25 unidades de escala de tiempo (600 / 24 = 25). En este mismo sentido, el número de 600 unidades de Time Scale, funciona bien con 25, 30, 50 y 60 frames por segundo. La Media con muchos samples por segundo (tales como el audio digital, el cual puede tener un sample rate de 48000, por ejemplo) es especificada en cantidad de samples por unidades de escala de tiempo. En el caso de audio digital su escala de tiempo es el segundo. Así que decimos, simplemente, que el audio track es de 48000 samples por segundo, por ejemplo.

La duración de una “película” será, por lo tanto, el número total de su escala de unidades de tiempo desde un extremo al otro. Un track en una película tendrá una duración menor si este no se extiende hasta el final de la misma. En ese caso, los chunks (pedazos) de Media, a los que los tracks refieren, tendrán una duración más corta.

Media Time Scale

Cada chunk de Media que es referenciado por un track tiene su propia escala de tiempo determinada por su sample rate. QuickTime trasducirá entre una escala de tiempo de una “película” y la escala de tiempo de las varias Medias involucradas en la misma automáticamente. QuickTime es el que lo hace, no la aplicación que usa a QuickTime. Por ejemplo ProTools, o Final Cut Pro.
Otro ejemplo podría ser considerar una “película” que contiene un track de video, un solo track de audio y un track de texto. La “película” tiene una duración de 2 segundos y su escala de tiempo default es de 600. El video track comienza junto con la “película” (offset 0), va hasta el final (duración 1200), a razón de 25 frames por segundo (una escala de tiempo de Media de 24 unidades de escala de tiempo). El track de audio también comienza con la película, y va hasta el final (offset 0, duración 1200), a 48000 samples por segundo (la escala de tiempo de esta Media es de 48000). El track de texto contiene un simple frame, el título, el cual aparece por 0,25 segundos en la “película” y dura 1 segundo (offset 150, duración 600, escala de tiempo de Media 1).

Playback Time Base

QuickTime establece la base de tiempo de reproducción cuando se hace play a una “película”. Dicha base consiste en el sistema coordinador de tiempo de la “película”, una velocidad o Rate, un concepto de “en este momento” (current time) y una referencia de componentes de tiempo que provea a QuickTime con mediciones de tiempo real. El Rate determina cuántas unidades de escala de tiempo corren por unidades de tiempo real. El Rate también determina de qué manera es reproducida la “película”; hacia adelante o hacia atrás. Si el valor es negativo, la película debe ser reproducida hacia atrás. Si una “película” con una escala de tiempo de 600 tiene un Rate de 1, QuickTime procesará 600 unidades de escala de tiempo de la “película” cada Segundo yendo hacia adelante, y la “película” correrá a velocidad normal. Un Rate de 0,5 resultará en 300 unidades de escala de la “película” procesadas por Segundo y la película será reproducida a mitad de velocidad. Un Rate de -1 significará que la “película” será reproducida hacia atrás a velocidad normal.

“En este momento” (Current Time) es simplemente la localización expresada en unidades de tiempo de escala donde la “película” está mientras la reproducción sucede. El valor de “en este momento” puede ser desde 0 hasta el valor de la duración de la “película”.

Headers

Cada uno de estos conceptos están compuestos por una serie de partes mínimas llamadas átomos. Hay una miríada de átomos. Estos se referencian entre sí, se armonizan entre sí, y son coherentes entre sí. Generalmente, no se puede alterar uno solo de ellos, sino que hay que alterar todos los que están relacionados entre sí.
Sus nombres son arcanos para nosotros, los no iniciados. Por ejemplo:

mvhd - tkhd - edts - stsd

Hay un programa gratuito de Apple, llamado Dumpster (programa pensado para desarrolladores de software), que permite examinar un archivo QuickTime, y hasta editar los valores de estos átomos.

Veamos como Dumpster ve a una “película”.

Pese a que hay muchos campos, hay algunos que fácilmente son comprensibles. Por ejemplo, en mvhdpodemos ver el valor de “timeScale” (600), y su “duration” (19592). El nombre del átomo mvhd es la abreviatura de movie header.
Si dividimos esta última cifra por la escala de tiempo de la “película” nos dará como resultado 32,32 segundos. Se trata de un comercial de Bimbo. Esa era la duración del comercial más la cola inicial.
En mdia - mdhd la “timeScale” dice 48000. Efectivamente está hablando del track de audio. En cuanto a su “duration” nos informa que es 1554412 de samples totales. En efecto, al dividir esa cantidad total de audio samples por la escala de tiempo de este track (48000), nos da, como resultado, una duración de 32,383583333333 segundos. Sí. No duran exactamente lo mismo ambos tracks.

Como se puede ver, son todos valores coherentes entre sí. Si cambiáramos la escala de tiempo de la Media que referencia el track de sonido de 48000 a otro cualquiera y no cambiásemos acordemente su duración, el sonido se iría desincronizando a medida que progresa la reproducción de esta “película”. Y, por supuesto, terminaría antes o después de la imagen, y oiríamos que su pitch ha cambiado proporcionalmente.

Al cliquear sobre cada una de las siglas en letra minúscula y negrita se despliega toda una lista de átomos. Los valores que aparecen en los campos de estos átomos, como ya dijimos, son editables. Pero, ojo... De meter mal los dedos crearemos un archivo corrupto, medio Frankenstein, que solo un experto podrá corregir.

Sólo mencionamos este programa para comprobar los valores y su correlación con los tantísimos parámetros que puede tener una “película” QuickTime.

APÉNDICE III: Comentarios sobre Cinema Tools

Qué tenía Apple en mente cuando creó Cinema Tools? Acaso lo hizo pensando en el sonidista del mundo PAL y olvidó comunicarselo?

Nada de eso. Apple diseñó este programa para resolverle varios e importantísimos problemas a los usuarios de su programa Final Cut Pro. Problemas como poder exportar una lista de corte de negativo fiable, por ejemplo. O cómo trabajar con materiales de imagen de diferentes frame rates en una misma Time Line. Por ejemplo, negativo filmado a 24fps mezclado con video PAL o NTSC.

Para poder resolver estos problemas Final Cut Pro necesitaba poder rastrear cada fotograma de negativo original a través del transfer a video y de la digitalización a película QuickTime. Necesitaba mantener una relación “Uno a Uno” entre los fotogramas “virtuales” y los originales físicos. Por este y otros fines conexos Apple creó Cinema Tools.

Es justamente la propiedad de Cinema Tools de manipular los archivos QuickTime la que nos permite plantear este cambio en la manera de manejarnos con la imagen durante la post de sonido.

Volviendo nuestras manos sobre Cinema Tools. Hemos cambiado la duración de una película, conservando la misma cantidad de frames. Pero...

- ¿Qué hizo exactamente Cinema Tools?
- ¿Por qué lo hizo tan rápido?
- Y... ¿Por qué este proceso es reversible?

Un archivo QuickTime, como está explicado en el Apéndice II, consta de dos grandes secciones: los datos y la receta (los fotogramas de imagen y las instrucciones que explican cómo reproducirlos).

Con respecto a “la receta”, se puede decir que la misma tiene muchísimos componentes que le dicen al reproductor de ese archivo qué hacer con él. Por ejemplo, definen el Codec que descomprimirá esos datos, la velocidad a la que se los debe reproducir, cuándo aparecen y cuándo desaparecen los títulos (en caso de que existan), a qué volumen reproducir sus tracks de sonido, etc., etc., etc. y el ingrediente de la receta que nos resultará muy útil para resolver el problema que nos atañe: cuánto tiempo dura la reproducción de cada fotograma de la bolsa.

Lo que Cinema Tools hace es cambiar esa información. Pero calcula y cambia también todas las que están irremediablemente asociadas a este cambio. Por ejemplo, la duración total de la película es alterada en forma directamente proporcional al frame rate escogido.

Para entenderlo, si pudiésemos cambiar esa información de modo tal que el frame rate fuese de 1 fotograma por segundo, la duración resultante de la película con la que estuvimos jugando antes sería muchísimo más grande. Sería de 1502 segundos. O sea, duraría 25 minutos, 2 segundos, 00 frames.

Cinema Tools no renderea los fotogramas, sólo cambia las variables de la receta, de la fórmula que explica al reproductor del archivo qué hacer con esa película. Por eso Cinema Tools lo hace tan rápido y sin alterar la calidad de la imagen. Y por eso es infinitamente reversible. Es, por lo tanto, una alteración benigna del archivo. Y por ende, no es destructiva.

Por ejemplo, si luego de haberle pedido a Cinema Tools que conforme a 24 fps un archivo de video de sus originales 25 fps, le solicitáramos que a ese mismo archivo lo vuelva a conformar a 25 fps, nuevamente y sin demoras, lo convertirá otra vez en la misma duración que tuvo el original y por supuesto, con la misma cantidad de fotogramas que al principio. Todo sin degradar la calidad de la imagen pues, como dijimos, Cinema Tools no se mete con la Data del archivo sino con su Meta Data. Es decir, con la información que describe la información del archivo.