Este método resolve um problema de falta de sincro perfeito, evidenciado nos atuais processos de pós-produção de som do digital cut ou o transfer de positivo, até a cópia final, incluindo as versões VHS e DVD. Esta proposta metodológica não envolve mudanças radicais no fluxo ou no modo de trabalhar. Mas se oferecer certezas de sincros repetíveis e exatos.
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.
Este método resolve um problema de falta de sincro perfeito, evidenciado nos atuais processos de pós-produção de som do digital cut ou o transfer de positivo, até a cópia final, incluindo as versões VHS e DVD.
Esta proposta metodológica não envolve mudanças radicais no fluxo ou no modo de trabalhar. Mas se oferecer certezas de sincros repetíveis e exatos.
Os que trabalhamos na etapa de pós-produção de som de longas-metragem permanentemente nos enfrentamos com um problema:
Inconsistência de sincronismo entre o som e a imagem durante o processo de pós-produção, incluindo à cópia final.
Como se manifesta nos fatos esta afirmação?
Para começar, ao receber a exportação OMF de som que o editor de imagem nos facilita, vemos que quase nenhum clipe de som tem sincro parecido. Freqüentemente os sons estão fora de sincro até um quadro e às vezes até dois quadros.
Os extremos, começos e finais do som que importamos quase nunca estão no comienzo/final exato dos fotogramas.
Estes sound clipes, sound files ou regiões (na linguagem de Pró o Tools) não se encontram em lugares “redondos”, mas sim começam e terminam em algum ponto “dentro” do frame sem coincidir com a grade de nossa Teme Line. Sabemos, entretanto, que o editor de imagem não cortou o som em uma localização diferente dos borde dos frames de imagem.
Portanto essas exportações OMF de som deveriam coincidir perfeitamente com a grade de frames em nossas estações de trabalho.
Entretanto, isto não acontece.
Logo, ao começar nossa tarefa vemos que em várias oportunidades nos custa sincronizar algumas cenas. Por exemplo, se colocarmos em sincro parecido a primeira letra “P” ou “B” de um texto, alguns outros parlamentos da mesma cenaa não estão com o sincro exato.
Além disso, se em alguma oportunidade, logo depois de ajustar os sincros dos sons de um ato, nos dá um novo transfer do mesmo positivo, notaremos que o trabalho feito com respeito à exatidão do sincronismo se corrompeu.
Neste novo transfer muitos das mudanças de seqüências estão corridas um frame. A maioria dos lugares onde tinham colocado sons precisos, não estão onde os tínhamos colocado. Alguns sim, mas mais da metade se encontram um quadro deslocado.
Todo isto sem que tenha havido mudança alguma no positivo.
Por outra parte, ao ver a cópia do filme final achamos que as decisões de sincro, agora aparecem erradas. Alguns diálogos estão claramente fora de sincro e olhando em detalhe, a sensação é persistente ao longo de todo o filme.
Poderíamos atribuir a que isto se deveu a que o software editor de imagem teria entregue listas de corte de negativo defeituosas ou a que o cortador de negativo cometeu algum erro. Mas comprovaremos que isto não é assim.
Pelo descrito e como enunciamos, só vemos inconsistências de sincronismo entre o som e a imagem durante o processo de pós-produção e até a cópia final inclusive.
Não está demais dizer que são muitos os processos envolvidos nesta etapa, edição de direto, dublagem, foley, armado de efeitos sonoros, etc. E muito o trabalho investido em ditas tarefas para acabar com um resultado não procurado.
Os que somos suficientemente velhos para ter chegado a editar som em moviolas não recordamos ter lutado com estes problemas de sincronismo.
O que se via na moviola era o que se via na sala de mixagem e na sala de estréia.
Que passou depois?
O que mudou?
Este inconveniente começou com a introdução das estações de edição não linear de imagem e de som.
A fim de poder trabalhar o áudio de um filme com estas tecnologias, se forneceu aos editores de som de uma imagem do filme transferida sobre um suporte de vídeo. Era a tecnologia que se dispunha nesse momento, que começou esta prática e que segue igual até hoje.
No mundo PAL se utiliza um método pelo qual a máquina de transfer de imagem movimenta ao positivo (ou negativo) de filme a uma velocidade de 24 fps, colocando as imagens obtidas sobre um sinal de vídeo PAL, quer dizer, de 25 fps.
Qualquer pessoa sabe que 24 não é igual a 25.
Assim, Como resolve a máquina de transfer o problema de distribuir 24 frames de filmes em 25 frames de vídeo?
A resposta é, adicionando um fotograma extra por segundo.
Este fotograma extra se produz duplicando um campo de vídeo cada 12 quadros.
O sistema duplica um campo do fotograma 12 e outro campo do fotograma 24 de cada segundo (ver Apêndice I).
Lembremos que cada fotograma de vídeo PAL se compõe de dois campos (vídeo Fields):
- O primeiro contém as linhas de varrido ímpares (1, 3, 5, ...).
- O segundo campo contém as linhas de varrido pares (2, 4, 6, ...).
Se cada quadro de vídeo se compõe de dois campos, a máquina de transfer converterá, por segundo, os 24 fotogramas de filmes iniciais em 48 campos e adicionará 2 campos mais.
Assim, a quantidade total de campos por segundo será 48 + 1 + 1 = 50.
E em termos de quadros por segundo, a cifra será 24 + 1 = 25.
Mas esta manipulação da imagem joga com o momento em que é apresentado cada quadro, pois os fotogramas de vídeo vão "adiantando-se" (ver Apêndice I) aos de filmes (e ao som) até que o erro temporário se reseta.
Isto explica porquê vemos que NÃO todas as consonantes “P” ou “B” dentro de uma mesma cena parecem estar em sincro. E isto, sem que ninguém tenha feito nenhum corte na imagem ou no som. Dependerá então de como ficam essas consonantes na cadência do erro temporário. Em algumas o erro poderá ser 0, em outras poderão estar até um fotograma deslocado.
Mas nunca será exato nem repetitivo.
Isto, como já vimos, complica todas as tarefas de edição de som durante o extenso processo de uma longa-metragem.
- Por que acontecem todos estes problemas?
Porque temos quebrado a relação Um a Um (One to One) entre a imagem com a que trabalhamos na pós-produção e o negativo de filme.
Temos quebrado a correspondência direta fotograma a fotograma, com o agravante da não repetitividad do erro.
Pensando em termos gerais, se os filmes se filmam 24 fps em todo o mundo, aqui, na Espanha, em USA, ou em Líbano e se projetam a 24 fps em todo mundo, no Brasil, Filipinas ou Mongolia, etc. Por que motivo pós-produzimos a 25 fps?
Porque, como dissemos, a partir da chegada das editoras virtuais não havia outra maneira de levar-lhes a imagem aos pós-produtores de som, já que o formato mais próximo, barato e disponível nesse momento era o vídeo PAL.
- A Pergunta que surge é: Haverá alguma maneira de usar os mesmos materiais, as mesmas máquinas, os mesmos reprodutores, mas de um jeito tal que nos permitam retornar à confiabilidade do velho “One to One”?
A resposta é, Sim, há.
A resposta a este problema é que voltemos a ter a mesma quantidade de fotogramas que tem o negativo e reproduzi-los à mesma velocidade a que foram expostos e a que serão reproduzidos.
A solução proposta baseia-se em manipular certas propriedades dos arquivos QuickTime, que é uma tecnologia disponível neste momento.
Para entrar nesta primeira metodologia devemos definir o que é QuickTime (ver Apêndice II).
Grosseiramente se poderia dizer que um arquivo QuickTime é uma bolsa de dados e uma receita que explica como reproduzi-los.
Os dados em questão podem ser fotogramas de imagem, áudio, texto, notas MIDI, gráficos, etc.
A receita explica a que velocidade devem ser reproduzidos esses dados, em que momento devem aparecer e desaparecer, entre outras muitíssimas coisas mais.
Se pudéssemos ter todos os fotogramas do positivo (ou negativo) nessa bolsa, sem que nenhum deles esteja duplicado, e pedir-lhe ao QuickTime que os reproduza a 24 quadros por segundo, estaríamos na mesma condição “One to One” que tínhamos na época das moviolas.
Quer dizer, teríamos o mesmo número de fotogramas, a mesma velocidade de fotogramas por segundo com que se registraram e a mesma velocidade de fotogramas por segundo a que serão reproduzidos na sala de cinema.
O problema é que embora lhe digamos à máquina de transfer “partam a 24 fps” não há nenhum formato de vídeo padrão cuja cadência de fotogramas seja 24.
A velocidade do formato PAL é 25 quadros por segundo (com 50 campos por segundo) e a do formato NTSC é 29,97 quadros por segundo (com 59,94 campos por segundo).
O único formato de vídeo que realmente corre a 24 fps é o High Definition 24p.
Mas se em lugar de pedir um transfer de vídeo padrão o pedimos High Definition, em que suporte receberíamos este vídeo? Acaso temos um player High Definition 24p em nossos estudos?
Assim, pergunta-a é: Como obtê-lo?
Vejamos:
O primeiro a conseguir, será converter exatamente a mesma quantidade de fotogramas de filmes em fotogramas de vídeo. Com a tecnologia corrente a maneira mais fácil (e única) de obter este objetivo, é mover o mecanismo do transporte da máquina de transfer a 25 fps (e não a 24 fps), e colocar este sinal em formato de vídeo PAL.1
A esta velocidade, cada fotograma de filme tem seu irmão gêmeo de vídeo.
Obtemos assim a relação “One to One”.
Esta será uma cadência de vídeo PAL ordinária, comum. Sem nenhum campo ou frame duplicado. E podemos digitalizá-la e convertê-la num arquivo QuickTime de 25fps comum.
Só temos um problema: a imagem resultante é 4,16666667% mais veloz à que foi filmada e que como será reproduzida.
Neste ponto precisamos lhe dizer ao QuickTime... “Reproduça mais devagar cada um destes fotogramas que há nesta bolsa. Exatamente um 4,16666667% mais devagar”.
Ou dito de outro modo... “Cada fotograma desta bolsa nasceu com uma receita de reprodução segundo a qual cada quadro devia ser mostrado durante 1/25 de segundo (40 milissegundos). Pois bem, queria que modifique dita receita e faça que a duração de cada fotograma seja de 1/24 de segundo (41,6666667 milissegundos), que era a duração destes fotogramas quando foram filmados e que será sua duração quando forem projetados num cinema”.
Se pudéssemos mudar esse dado na receita restabeleceríamos a relação firme e procurada do Um a Um, do “One to One”.
1 Isto não é novo. O mundo da publicidade nos países PAL trabalha desta maneira. Filma-se, transfere-se, edita-se, mescla-se e se reproduz a 25 fps.
Como podemos estabelecer este diálogo com o QuickTime?
A ferramenta que o permite é o programa Cinema Tools da Apple.
Este é um software colega do Final Cut Pró. Com o Cinema Tools o caminho para converter um filme QuickTime de 25 fps a 24 fps é simples e veloz.
Vejamos como fazê-lo: Uma vez aberto o programa devemos ir ao File > Open Clip, e navegar até selecionar o filme. Logo depois disso se abrirá uma janela com o filme selecionado e alguns botões.
Se clicamos no botão “Clip Analysis...” uma janela com toda a informação relevante se abrirá perante nós.
Demos “OK” e fazamos clique no botão “Conform...”
Esta nova janela nos informará que o frame rate deste filme é efetivamente 25 fps, tal como saiu da sala de transfer. Se voltamos a clicar e mantemos pressionado o botão do mouse sobre 25.0 logo depois de “Conform to:”, veremos as opções de conversão de frame rate que oferece este programa.
Escolhamos 24.0 e apertemos o botão “Conform”. Este processo demorará 2 ou 3 segundos. A seu término, se voltarmos para clicar na opção de “Clip Analysis...” verificaremos como mudaram os dados relevantes.
Assim comprovamos que:
Verifiquemos agora a quantidade de fotogramas. Primeiro a original a 25 fps.
Dissemos que durava um minuto e 2 fotogramas.
(25 fotogramas x 60 segundos = 1500 fotogramas) + (2 fotogramas)
Agora façamos as contas da versão conformada a 24 fps. Dissemos que durava.
(24 fotog. x 60 seg. = 1440 fotog.) + (24 fotog. x 2 seg. = 48 f.) + (14 f.)
Quer dizer que este procedimento garante que a quantidade de fotogramas seja a mesma independentemente da que velocidade os reproduza (@25 ou @24 fps).
Confiramos agora se a duração total do novo filme é correta usando uma calculadora de Teme Code.
Abrimo-la, selecionamos Film e no Frames digitamos 1502.
Ao dar Enter lhe estaremos pedindo que nos mostre a duração de um filme que contenha essa quantidade de fotogramas quando se move a 25 fps.
Corretamente nos diz o valor que durava o filme QuickTime original, quando ao fazer play o fazia a 25 fps.
Logo lhe pedimos que nos mostre a duração de um filme que contenha essa mesma quantidade de fotogramas (1502) mas movendo-se a 24 fps.
Essa (00:01:02:14) foi a duração da versão processada com Cinema Tools.
Podemos dizer então e com toda segurança, que temos satisfeito as necessidades do “One to One”.
- Em que altera nossa maneira de trabalhar uma imagem assim, a 24fps?
Em muito pouco.
Falemos da ferramenta que quase todos os sonidistas usam, o ProTools.
Bastará trocar na janela Session Set Up (Command + 2) o Teme Code Rate desde nosso padrão 25 a 24fps. Deste modo, as bordas dos fotogramas do vídeo (convertidos agora a 24 fps) coincidirão com a grade do Teme Code da janela de edição. Não faz falta um reprodutor especial desta classe de filmes QuickTime @24 fps. O mesmo reprodutor padrão QuickTime entende esta receita, sabe o que fazer com esses fotogramas e pode fazê-lo. Dito de outro modo, para o QuickTime dá no mesmo reproduzir um filme a 24 ou a 25 fps, pela mesma razão que lhe dá o mesmo fazê-lo a 29.97 ou a 30 fps. Para o programa reprodutor se está falando do mesmo grau de dificuldade.
Outra virtude desta mudança:
Agora, os sons importados das ilhas de edição off line cairão nos bordos exatos da imagem a 24 fps.
Por que? Porque a Teme Line dos programas editores de imagem que se usam em longas-metragem (Avid Filme Composer, Final Cut Pró, etc) é de 24 fps. Ou seja que suas exportações têm todas as propriedades dessa regra de medição de tempo.
E o que passa com a mixagem?
Pois, não muito.
No caso das salas de mixagem que trabalham com imagens que saem de uma placa de vídeo instalada dentro da CPU do computador terá que ir à janela Session Set Up do ProTools da sala de mixagem e trocar o Teme Code Rate de 25 a 24 fps. Quase todos os projetores de vídeo e a totalidade dos projetores de data (VGA, etc) levarão-se bem com este sinal.
As salas de mixagem internacionais equipadas com projetores de filme e não de vídeo, usam uma interfase para converter os pulsos de quadratura bifase do projetor para o formato do TC ao gosto do engenheiro da sala. Tenta-se trocar resets muito simples para que em lugar de correr um TC de 25 fps corra um TC de 24 fps pelas veias do estudo. Todas as consoles de mixagem aceitam, para atender a sua automatização, todos os formatos de teme code.
Quer dizer, não se fazem umas consoles para a Europa e outras para USA. São as mesmas. É uma simples mudança de resetagem.
Mas inclusive há muitas que sempre trabalharam distribuindo um TC de 24 fps. É o caso de Cinema Arte de Madri. Quando nós chega a mesclar a essa sala o primeiro que trocávamos no ProTools reprodutor de nossos tracks era o Teme Code Rate da sessão desde nossos originais 25 aos 24 fps padrão de Cinema Arte. Eles têm a sala configurada com esse padrão. De todas maneiras, na hipótese de que houvesse uma sala de mescla que não aceitasse outro TC que não seja o de 25 fps, pois bem, sem nenhum esforço trocaríamos nosso Teme Code Rate de nossos 24 a seus 25 fps e pronto. O Pró Tools se sincronizará contra 25 fps em lugar de fazê-lo contra 24 fps. O Pró Tools seguirá reproduzindo a mesma quantidade de samples por segundo. Não se acelerará nem se lenteará.
Fica pendente outro item, o Teme Code em tela:
Vamos ver. A principal utilidade da janela queimada de Teme Code em tela numa imagem transferida a vídeo é a de verificar que durante o processo de digitalização a placa de vídeo não se “comeu” algum quadro.
Estranho, mas não impossível.
A sala de transfer está acostumada a queimar uma janela de Teme Code na parte alta do fotograma.
Que formato de Teme Code?
De 25 fps, claro.
Com o método proposto, ao submeter dita imagem ao esticamento de tempo via Cinema Tools o Teme Code queimado e convertido em parte do sinal de vídeo dentro de cada fotograma será também, obviamente, “esticado”.
Então teríamos um filme a 24 fps com uma janela queimada que tem um TC equivocado.
Como o procedimento é sincronizar o filme QuickTime contra a Teme Line, de modo tal que o TC da janela queimada da imagem coincida com o Teme Code da Teme Line do ProTools, logo do primeiro segundo deixarão de coincidir. Depois dos primeiros 24 fotogramas se irão diferenciando a razão de um quadro por segundo acumulado a partir do princípio do filme.
Existe alguma informação, sinal ou data que possa acompanhar cada fotograma em forma independente a sua velocidade de reprodução, que nos identifique inequivocamente cada fotograma e que compreendam tanto o operador como a equipe editora de som?
Sim. Pés e Fotogramas, “Feets and Frames” (F&F).
F&F é padrão em países como USA. Era-o também no processo do Print Master do Dolby Digital antes da chegada do equipamento DMU. Eram feets and frames a informação que pedia o PC do Dolby para saber onde estava o primeiro fotograma do ato e onde o último. Assim se podia fazer o Pull Up que adere os primeiros sons do seguinte ato ao final do anterior de modo de minimizar as moléstias nas mudanças de atos. E, obviamente, também é padrão em todos os passos internos dos laboratórios de imagem.
Outros indícios de sua padronização é que ProTools o inclui como opção em seus contadores, que a cauda numerada com a que iniciamos cada ato tem exatamente 12 pés + 00 frames e que o bepe está exatamente no pé 9 + 00 frames a partir do Start.
Mas, um momento, onde deve começar a contagem do F&F?
O 0000 Feet + 00 Frame deve estar no Start da cauda numerada de modo tal que aos 9 Pés + 00 Fotogramas esteja o Bepe e que aos 12 Feets + 00 Frames esteja o primeiro fotograma do ato.
as se pedirmos à sala de transfer “queimem F&F em lugar de Teme Code”.
Como procedemos no ProTools?
É mais fácil de explicar na versão 6.4 (e superiores) do ProTools, mas também é realizável nas anteriores.
Em PT 6.4 (ou superior) devemos resetar no pull down menu Windows > Show Session Setup, o Feet + Frame Ratio em 24 fps. No Edit Window, um dos dois contadores (o Main ou o Sub) devemos passá-lo ao Feets + Frames e o outro deixá-lo no Teme Code. Por que? Porque às vezes devemos fazer perguntas ao editor de imagem, como algo que não entendemos e que está no tal Teme Code. O que Teme Code lhe diremos? O mesmo que ele tem na sua Teme Line. Pois sua Teme Line é de 24 fps! E não de 25 fps!
Sigamos. A seguir sincronizamos o primeiro fotograma de imagem do ato contra a hora que identifica o número de ato (a hora 01:00:00:00 é o primeiro quadro do Ato 1 e assim sucessivamente). Logo retrocedemos 8 segundos, 00 frames. Aí deve estar a palavra Start na cauda numerada.
Porque 8 segundos exatos (12 pés com 00 frames em 35mm) é a duração do Start até o primeiro fotograma do ato (FFOA, First Frame Of Action).
Deixando o cursor nesse lugar, devemos ir ao pull down menu Setups > Redefine Current Feet + Frames Position...
Uma janela aparecerá. No campo do Feet + Frames digitemos 0.
E demos OK.
A partir de agora o contador resetado no Feets + Frames está sincronizado com a janela queimada de nosso QuickTime. Devemos ir para o último fotograma do ato para verificar se coincidem entre si os Feets + Frames na janela queimada do QuickTime com o contador no Feets + Frames do ProTools. Se não coincidir, durante o processo de digitalização da imagem um ou mais frames foram “comidos”.
Se para definir uma posição dentro do filme nos resulta mais cômodo, por costume ou por alguma outra razão, seguir trabalhando com a estrutura visual e pnemotécnica do TC, podemo-lo seguir fazendo e assim o display do F&F deveria ser o contador secundário, ou Sub, que apenas será usado para checar que nenhum frame tenha sido elidido durante a digitalização. Usaremos então o Main e o Big Counter no TC (de 24 fps).
No caso de versões 5.x.x do ProTools, a maneira de dizer para o programa que desejamos que o contador do F&F comece a contar de 0000 Feets +00 Frames a partir de um lugar dado da Teme Line, quer dizer que aí está a Session Start Teme. No caso do Ato 1 deveremos iniciar a sessão em 00:59:52:00. No caso do Ato 2 será em 01:59:52:00. A Session Start Teme-se reseta no Windows > Show Session Setup.
Uma possível dificuldade nas versões 5.x.x acontecerá se o filme tem algum fotograma antes do Start. Dado que ProTools não deixará que nada vá parar na sua Teme Line antes do tempo marcado em seu Session Start Up.
Haveria porque cortar toda imagem anterior ao fotograma com a palavra Start.
Isto só é necessário nas versões 5.x.x.
As sessões iniciadas em versões 5.x.x com este reset de contadores são 100% compatíveis com as versões 6.x.x. As sessões iniciadas em versões 6.x.x são 100% compatíveis com 5.x.x na medida que a imagem não tenha nenhum fotograma anterior ao Start.
Agora surge uma pergunta.
Poderia se aproveitar este método nos filmes nos que não se faz transfer de positivo para a pós-produção de som?
Sim.
Nos casos em que a edição de imagem se realizou em um equipamento Avid Filme Composer, na hora de fazer o Digital Cut para nosso trabalho, o Avid pergunta ao operador, “A que velocidade reproduzo a Teme Line aberta: a Filme Rate (24 fps) ou a Vídeo Rate (25 fps)?”
Os únicos Digital Cuts que conhecemos quando se tratava de um projeto cinematográfico padrão eram os saídos a Filme Rate. Nesses casos, é o Avid o que duplica um frame cada segundo quando se o reseta assim. Temos aqui as mesmas dificuldades que se se tivesse feito um transfer a 24 quadros por segundo sobre um sinal PAL e que estamos tentando superar.
Em troca na outra opção, Vídeo Rate, Avid reproduzirá as imagens de sua Teme Line à mesma velocidade que as digitalizou: a 25 fps.
Porque lembrem que a única maneira que tem o Avid e qualquer outra editora virtual de imagem, de poder expulsar uma lista de corte sã para os cortadores de negativo é saber clara e inequivocamente como se chama cada um dos fotogramas envolvidos em sua Teme Line.
Avid também necessita, e por isso utiliza, a ditosa relação “One to One”.
No seu caso o obtém a partir de receber transfers feitos a 25 fps do negativo diário de rodagem. Ao fazer play duplica um frame por segundo para que essas imagens se vejam “aceitavelmente” sincrônicas com o som direto (ao que não modifica sua velocidade) porque sua Teme Line é de 24fps.
Se recebêssemos um Digital Cut a Vídeo Rate seria para nós exatamente igual a receber o tipo de transfer que estamos propondo neste método. Ou seja, uma vez digitalizado o Digital Cut (a Vídeo Rate) e trocada a receita de reprodução (os headers do QuickTime) por Cinema Tools, estaríamos na desejada, e tão longamente explicada aqui, condição “One to One”.
A abordagem de Final Cut Pró (FCP) a este problema é diferente.
O FCP também necessita, ao igual a Avid, manter uma relação One to One com o negativo de imagem para poder garantir que suas listas de corte sejam fiéis. Mas o FCP não duplica um fotograma por segundo (como o faz o Avid) mas sim estica a duração de cada frame em 4.16666667% (de 1/25 do transfer a 1/24 de segundo). De modo tal que a Teme Line de um projeto de longa-metragem no FCP tem 24 fotogramas por segundo (igual ao Avid).
O FCP é capaz de exportar um QuickTime a 24 fps diretamente desde sua Teme Line sem necessidade de processar nada com o Cinema Tools. Ou seja que se o editor da longa-metragem ao que vamos fazer o som edita com o FCP, poderemo-lhe pedir que nos exporte em formato QuickTime e a 24 fps os “Digital Cut” dos atos do longo, já que estes terão uma relação “One to One” com o negativo que a Teme Line refere e com a lista de corte de negativo.
Finalmente, seria bom que a sala de transfer nos queime uma pequena janela nalgum canto superior com a lenda “Ato 1”, “Ato 2”, etc., a todo o longo de cada ato. Dizemos que seria bom, já que ao lhe solicitar à sala de transfer nos queime a informação do F&F e não a do TC, não teríamos mais a hora do TC como aviso do ato em que estamos trabalhando. Coisa que segue sendo útil.
Que acontecerá com os sincros quando um filme pós-produzido com imagens a 24fps se distribua no VHS e no DVD?
Vamos ver. Para fazer duplicação VHS se parte de um Master PAL. Um Master PAL é um transfer de negativo ou Dup movendo-se a 25fps sobre formato de vídeo PAL. Como já se explicou, este transfer gerará tantos fotogramas de vídeo como tenho o filme original. Não terá fotogramas duplicados. Este transfer será exatamente igual aos transfers de trabalho que nos deram para fazer a pós-produção de som.
Portanto, o sincro será um 100% igual à cópia final, que o que vimos na sala de mescla, que o que vimos em nosso ProTools.
O que acontecerá com a distribuição no DVD?
Na Argentina, para fazer duplicação do DVD se parte de um Master NTSC.
Há três maneiras de obter este transfer: 1) por transcodificação desde o Master PAL, 2) por transfer de negativo ou Dup a sinal de vídeo NTSC e 3) por meio de reproduzir um Master Hi Definition 24p a 23.976fps e fazer uma downconversion dos 1080 delineia às 625 do PAL.
Se o caminho que escolher o produtor é por transcodificação do Master PAL o resultado final será semelhante ao obtido na distribuição VHS. A mesma percentagem de aceleração do programa sonoro que fizemos para o VHS será o que tenhamos que fazer para entregar o som ao criador do DVD.
Se o produtor escolhe fazer transfer NTSC ou downconvert do Master 24p, o negativo ou Dup se moverá a 23.976fps na máquina de transfer. Quer dizer, a imagem estará 0,1% mais lenta que a velocidade a que foi filmada e a que o som foi gravado, editado e mixado. Bastará com que nós lenteemos o programa 0,1% para que todos os sincros que batalhamos durante a pós de som se conservem em 100%.
Uma das coisas que faz interessante à idéia de pós-produzir o som de uma longa-metragem com filmes a 24 fps é que este conceito não se restringe exclusivamente ao mundo QuickTime. Também no mundo AVI o poderemos aplicar. Não será então com Cinema Tools mas com outras ferramentas que se poderá trocar o frame rate de um arquivo AVI.
Mas, o que é AVI?
O Audio Video Interleaved (AVI), o qual foi definido pela Microsoft ao começo dos anos 90, é o formato mais comum de data de vídeo e áudio nos PC'S. Sua organização interna é muito semelhante a do QuickTime, ao menos a nossos olhos de usuários. AVI é o nome do container dos “Películas” no mundo dos PC'S. Embora com nomes diferentes, suas partes funcionam de modo muito similar. O que no QuickTime se chama Atoms, no AVI se chama Tags, por exemplo.
Pois bem, encontramos vários programas freeware que fazem o que precisamos. Ao menos dois deles parecem ter sido criados para nossa necessidade: trocar os Tags específicos dos “Filmes” AVI para que as que nasceram a 25 fps sejam reproduzidas a 24 fps. Quer dizer, estes programas modificam o Tag que define a duração de reprodução de cada fotograma do filme dos iniciais 40 milissegundos (1/25 de segundo a 25 fps) aos 41,66666667 milissegundos ( 1/24 de segundo) para que sua velocidade seja 24 fps.
O primeiro desses programas se chama AVI Frate (AVI Frame Rate Changer v 1.10). É o mais simples de todos e se pode baixar:
http://www.doom9.org/software.htm
Uma vez ali terá que clicar no Download e procurar o link “full software link”, ali e dentro da subcategoría “AVI Editing Tools”, encontrará-se o AVI Frate v1.10 (apenas pesa 138KB).
Ou de:
http://www.free-codecs.com/download/AVI_Frame_Rate_Changer.htm
O segundo se chama AVI Frame Rate Adjust v 1.00 (pesa só 60KB) e se consegue ingressando em:
http://www.afterdawn.com/guides/archive/how_to_fix_avi_sync_problems.cfm
Vejamos como trabalhar com o “AVI Frate”:
Abrimos o programa. Uma janela muito pequena e singela aparecerá.
Clicamos sobre o ícone da pasta, o qual nos permitirá navegar até achar o filme que desejamos processar.
Para abrir arquivos1- Abrimos o programa
2- Procuramos o arquivo que desejamos processar.
Uma vez selecionado e aberto o arquivo AVI, automaticamente, no campo “Current Frame Rate”, dirá-nos o frame rate do mesmo, quer dizer 25 fps.
3- Abrimos o arquivo.
No único campo editáveç da janelinha clicamos e procuramos a cifra 24.
Liberamos ali o mouse, e damos “Apply”.
4- Escolhemos o novo frame rate.
5- Damos Apply.
Uma nova janelinha nos dirá que um novo frame rate será aplicado ao arquivo. Demos “OK”.
6- Clicamos no OK para finalizar a operação.
Pronto!
Daqui em diante este arquivo será visto por programas como Adobe Premiere Pró, Nuendo, Sonar, etc., como de 24 fps.
Vejamos, agora, como trabalha o “AVI Frame Rate Adjust”:
Ao abrir o programa se desdobrará a seguinte tela.
1- Abrimos o programa.
Deveremos clicar no botão “Open” superior para abrir o arquivo AVI.
2- Procuramos o arquivo.
Abrimos o arquivo e nos aparecerá a informação sobre suas propriedades atuais.
3- Propriedades do arquivo.
Uma vez aberto o arquivo digitamos, no único campo editável, o de “fps”, o novo frame rate que desejamos aplicar. Neste caso, é de 24 quadros por segundo.
4- Novo frame rate digitado.
Agora damos “Save” e com isso efetuamos a mudança. Modificar- se-á a duração do filme em modo proporcional à nova velocidade.
5- Nova informação das propriedades do arquivo.
Deve se salientar que este último programa subdivide o segundo em milissegundos. Assim, os 80 milissegundos da duração inicial de 00:01:00:080 a 25 fps de duração devem ler-se como dois fotogramas. Pois a 25 fps cada fotograma dura 40 milissegundos. O mesmo vale para o resultado final a 24 fps.
Por todo o exposto surge que a forma mais eficiente de receber as imagens dos filmes para realizar a pós-produção de som, é dentro de um container QuickTime e recebendo ditos QuickTimes em suporte CD ou DVD. O copiado a nosso disco rígido acontece a velocidades muito superiores ao tempo real do suporte de vídeo.
Por sua vez, já vimos que a mudança de variáveis na receita de reprodução é instantânea e não destrutiva.
Além disso, as possibilidades de erros envolvidos nas mudanças de dados de um suporte paraa outro, são inexistentes.
O custo do suporte (CD ou DVD) é baixo.
Em contraste, há muitas mais possibilidades de problemas mecânicos em suportes de vídeo: U-Matics, Beta SP, VHS, DV, etc...
Os suportes de vídeo estão muito expostos à sujeira, ao desgaste, a diferenças de ajustes entre o gravador e nossa equipe reprodutora, etc.
Seu custo é importante.
Os transportes de vídeo são custosos como o é também sua manutenção.
Por outra parte, permanentemente surgem novos formatos de suporte (é obvio, totalmente incompatíveis entre si) ou de tipo de sinal de vídeo (24p é um bom exemplo). Seguir investindo em equipamentos de reprodução de vídeo passa a ser desnecessário para desenvolver nosso trabalho.
O método exposto permite:
a) Garantir a consistência dos sincros decididos durante a pós-produção de som até as cópias de filmes finais. Esta consistência atinge todas as variantes de distribuição: VHS ou DVD, PAL, NTSC ou 24p.
b) Manter em 100% o mesmo sincro através de qualquer novo transfer da mesma imagem.
c) Trocar os headers fácil e rapidamente. Isto é seguro, reversível e não destrutivo.
d) Implementar uma janela com a informação do Feet + Frames que facilita traduzir o FFOA (First Frame Of Action), e o LFOI (Last Frame Of Image) que pede o processador do Dolby quando fazemos o Print Master do Dolby Digital, e controlar a não perda de fotogramas durante a digitalização.
e) Obter o benefício do delivery da imagem transferida dos atos das longas-metragens sobre suportes do CD ou DVD, e dentro do container QuickTime. Isto é benéfico tanto no econômico, e na velocidade da ingesta destes dados (por acontecer a menos que o tempo real), como por sua flexibilidade, já que não precisamos ter em nossos estudos transportes de meia de cada novo formato que emerja.
Este Apêndice pretende explicar duas coisas:
a) O que acontece na máquina de transfer quando lhe pedimos que coloque em um trem de sinais de vídeo PAL as imagens residentes num positivo (ou negativo) movidas a 24 fps? E...
b) O que passa quando digitalizamos esta cadência de vídeo?
Como dizíamos no corpo principal deste artigo, a máquina de transfer duplica um campo de vídeo cada 12 quadros.
Na figura se mostram alinhados um segundo de fotogramas de filmes (24 frames) nomeados do foto “A” até o “X”. Debaixo estão mostrados os fotogramas de vídeo que saem da máquina de transfer.
Nota: o sub-índice indica o número de campo.
1 indica o campo ímpar e 2 o par.
Ao ordenar-lhe à máquina de transfer que desejamos que seu output de vídeo seja PAL, não terá outro remédio que dividir o segundo em 25 segmentos. Dado que as imagens de filmes nesse período de tempo são 24, duplica, como já dissemos, um campo do fotograma “L” e outro do fotograma “X” (esses campos estão assinalados em cor celeste e sob o nome do Campos Extras).
Suponhamos que pudéssemos ter, uma ao lado da outra, duas máquinas reprodutoras mecanicamente sincrônicas entre si: Uma máquina reproduziria os fotogramas de filmes e a outra, os fotogramas de vídeo. Ao avançar quadro a quadro, claramente veríamos como os fotogramas de vídeo se adiantam2 aos de filmes.
2 O termo “adiantar” não é exato. Obviamente, a máquina de transfer não pode adivinhar que fotograma de filme vem a seguir. Não sabe se será uma paisagem, uma corda de enforcar sobre um patíbulo, ou um primeiro plano do protagonista. portanto, os fotogramas de filmes não podem adiantar-se. O que acontece é que o transfer tem um buffer no que guarda um campo de vídeo PAL (20 milliseg) liberando-o no tempo segundo a necessidade que lhe expõe o padrão de vídeo PAL. Por outra parte, o trem do TC é atrasado nessa quantidade de tempo. Como resultado, ao desenhar, com um início simultâneo, os dois jorros de fotogramas (o de filme e o de vídeo) observa-se o adiantamento mencionado.
À medida que avançamos no tempo observamos uma maior diferencia ou erro temporário. Ao chegar ao fotograma de vídeo composto pelos campos L1 e L2 a máquina de transfer duplica o campo par L2. Assim, o fotograma de vídeo número 13, compõe-se de um campo L2 e um M1. Com esta ação o erro temporário se resetó a zero, já que no momento em que começa o fotograma de filme “M” há um campo de vídeo que o está mostrando, o M1. Mas a partir daqui, o erro temporário novamente começa a crescer. Ao duplicar o campo L2, a máquina de transfer empurrou para trás no tempo a chegada do primeiro campo de vídeo que se refere ao fotograma de filme “M”.
Dito em outros termos, a máquina de transfer atrasou no tempo ao campo M1 até deixá-lo em sincro.
Tínhamos chegado então até o fotograma de vídeo composto pelos campos L2 y M1. Durante o próximo segundo meio os fotogramas de vídeo se comporão de um campo que corresponderá ao fotograma de filme anterior e outro campo que corresponderá ao fotograma em curso. Assim, até que o último fotograma de vídeo desse segundo, comporá-se dos dois campos pares correspondentes ao fotograma de filme “X”. Até aqui, o máximo erro temporário que o transfer gerará é do meio fotograma. Não se trata de um erro fixo, mas sim o adiantamento do sinal de vídeo em relação a seu original de filme é continuamente variável entre 0 milissegundos (perfeito sincro), nos fotogramas de vídeo A1A2 e L2M1, e 20 milissegundos (meio quadro @25fps), nos fotogramas de vídeo L1L2 e X2X2.
Os casetes U-Matic, Beta SP, VHS ou DV que recebemos da sala de transfer contêm esta cadência e estes erros temporários. Mas ao digitalizar esta cadência adicionamos outra imprecisão: Quase todos nós, como quase todos os editores não lineares de imagem, digitalizamos um campo por fotograma de vídeo e não os dois. Isto se faz para não sobrecarregar o largo de banda dos buses internos da CPU's de nosso Digital Áudio Workstation. Se só digitalizarmos um dos dois campos se reduz na metade a demanda de largura de banda interna exigida para este destino. É um grande benefício. Por outra parte, durante a primeira metade de cada segundo, o segundo campo, o das linhas pares, é quase exatamente igual ao das linhas ímpares. Não há ali nenhuma informação diferente ao primeiro campo. Na sala de transfer, cada fotograma foi escaneado duas vezes: Uma vez pelas linhas ímpares do primeiro campo, e outra vez pelas linhas pares do segundo campo. Durante todo o tempo em que se realizaram estes dois varridos, o fotograma de filme esteve imóvel no guichê de escaneio.
Isto é diferente do que acontece com os campos explorados de uma câmara de vídeo standard interligado que aponta à vida real, a uns atores, a um carro que passa, etcétera. Nestes casos, cada um dos dois campos de cada fotograma de vídeo poderia ser diferente entre si, pois enquanto transcorre o escaneio, a realidade se vai modificando.
Em troca, ao escanear um fotograma de filme, a realidade está congelada nele. Já foi congelada pela câmara cinematográfica. portanto, o segundo campo será virtualmente igual ao primeiro. Por isso, faz muito sentido usar só um campo. E portanto, é indistinto digitalizar o ímpar ou o par.
Suponhamos, então, que escolhemos digitalizar o ímpar, o primeiro que nos chega. Façamo-lo olhando o diagrama que já conhecemos.
Ao digitalizar o campo ímpar a cadência digitalizada será:
A1 B1 C1 D1 E1 F1 G1 H1 I1 J1 K1 L1 L2 M2 N2 O2 P2 Q2 R2 S2 T2 U2 V2 W2 X2
(e a roda se repete)
Vemos que durante os primeiros 12 fotogramas de vídeo se digitaliza o campo ímpar (1). Isto é assim até chegar ao fotograma de filme “L”. Este fotograma será digitalizado duas vezes. Primeiro o campo ímpar, e logo o campo par. Por isso o pusemos em vermelho. Para destacá-lo e reconhecê-lo. Das duas duplicações de campos, que a sala de transfer gera por segundo, só digitalizaremos uma delas: A pertencente ao fotograma de filme “L”. A duplicação do campo pertencente ao fotograma de filme “X” não será digitalizada, já que o primeiro campo que nos chega de dito fotograma do filme (o X1) se encontra ocupando um campo par, que não é o que digitalizaremos. O segundo campo que nos chega do fotograma “X” (o X2) será o que ocupe o lugar ímpar, ergo, será digitalizado. Assim, digitalizaremos o fotograma de filme “X” uma só vez, já que sua duplicação (o segundo X2), encontra-se no último campo par.
Se tivéssemos escolhido digitalizar apenas os campos pares, o fotograma que veríamos duplicado seria o X, e não o L. Mas seja como for, ao pedir-lhe a nosso software digitalizador de imagens que digitalize um só campo, qualquer que seja, estaremos aumentando ao duplo o erro temporário que saiu da sala de transfer. Portanto, na prática, este sistema provoca um erro acumulativo que chega até um frame. O duplo de que contribuiu a máquina de transfer.
Com estas imagens que suportam estes erros temporários é com a que estamos trabalhando no mundo PAL.
Não consideramos vital a compreensão das vísceras do QuickTime, mas surpreende a pouca difusão de seu conceito, seus componentes, as implicâncias, e como se pode jogar com eles. O QuickTime é realmente complexo. Um olhar a suas variáveis nos deixa impávidos. São muitíssimas. Vejamos só o muito básico.
O QuickTime utiliza a metáfora de um “filme” para descrever dados apoiados no tempo. Qualquer dado apoiado no tempo pode ser organizado como um “filme” (vídeo, áudio ou ambos). Estes “filmes” são cápsulas, containers, que sustentam toda a informação necessária para organizar os dados no tempo, mas não contêm os dados (imagens, som, etc.) em si mesmos. Quer dizer, estamos falando da receita ou instruções que explicam como reproduzir os dados. Os “filmes” são feitos de jorros de dados chamados Tracks e cada track referencia e organiza uma seqüência de dados numa maneira ordenada no tempo. Para fazê-lo, os Tracks contêm Estruturas de Meia que catalogam aos dados reais (imagens, sons, etc.). Por sua vez, a Meia está organizada dentro do track em pedaços (chunks) de dados de Meia chamados Media Samples. Um típico “filme” QuickTime contém a estrutura do filme e sua Meia ensambladas de modo tal que resulte fácil transportá-la ou baixá-la por internet, por exemplo.
Dito de outro modo, o QuickTime consiste em três níveis principais:
- A Média,
- Os Tracks e;
- O Filme (Movie).
A Meia a estrutura de dados de mais baixo nível, e é, em realidade, o video/audio/texto em si mesmo. A Meia está organizada nos Samples, que podem ser fotogramas no caso de vídeo ou samples no caso de áudio, por exemplo.
Os Tracks são as estruturas de dados que descrevem a localização da meia e que organizam sua correta decodificação (um decodificador para o áudio, outro para o vídeo, etc.).
O Filme é o elemento constitutivo do QuickTime de mais alto nível. É o container onde todos os tracks individuais se juntam. O Filme é também a responsável por manter cada um de seus tracks em sincro entre si.
Com respeito a sua estrutura, a mesma está dividida em uma multidão de parâmetros. Vejamos só os que mais nos interessam.
O “filme” QuickTime organiza a média através da dimensão temporária. Para dirigir esta dimensão, QuickTime define um Sistema Coordenador de Tempo. Este sistema coordena “filmes” e estrutura de dados de Meia com um sistema de medição comum entre todas, o SEGUNDO. Cada sistema coordenador de tempo estabelece uma Escala de Tempo, e dita escala estabelece a tradução entre o tempo real e o tempo do “filme”. As escalas de tempo estão denominadas em X unidades de tempo por Segundo. O sistema coordenador de tempo também define a duração do “película”, ou a estrutura de Meia, em termos de unidades de tempo. Portanto, um momento em particular de um “filme” pode ser identificado pelo número de unidades de tempo que o separam do começo.
Por sua vez, cada track em um “filme” tem um offset e uma duração. Estes atributos determinam quando um track deve começar a ser reproduzido e por quanto tempo. Cada estrutura de Meia também tem sua própria escala de tempo, a qual determina a quantidade de unidades de tempo default, por samples de dados, de cada tipo de Meia.
A escala de tempo é a regra mestre para um “filme”. Cada evento dentro de um filme é medido e localizado por meio da escala de tempo, e dita escala é expressa em unidades por segundo. A duração de um elemento de um “filme” é o número de unidades de escala de tempo desde seu começo até seu final.
Cada track num filme tem também um offset que é especificado em unidades de escala de tempo. Este offset é o ponto de começo do track. Um track que começa no mesmo momento que o filme tem um offset de 0 (zero).
Cada filme tem um sistema coordenador de tempo, mas esse sistema pode diferir de “filme” para “filme”. A escala de tempo num sistema coordenador de tempo em um “filme” deveria ter um número conveniente de frações de um Segundo. O número da escala deveria ser um que faça fácil a translação dos tempos de um “filme” para outra escala de tempo.
Uma escala de tempo de um “filme” de 600 (a escala de tempo default de cada novo “filme” QuickTime) pode traduzir uma velocidade de playback de 24 fps. Com uma escala de tempo de 24 fps, cada frame seria mostrado durante 25 unidades de escala de tempo (600 / 24 = 25). Neste mesmo sentido, o número de 600 unidades de Teme Scale, funciona bem com 25, 30, 50 e 60 frames por segundo. A Média com muitos samples por segundo (tais como o áudio digital, o qual pode ter um sample rate de 48000, por exemplo) é especificada em quantidade de samples por unidades de escala de tempo. No caso de áudio digital sua escala de tempo é o segundo. Assim dizemos, simplesmente, que o áudio track é de 48000 samples por segundo, por exemplo.
A duração de um “filme” será, portanto, o número total de sua escala de unidades de tempo de um extremo ao outro. Um track num filme terá uma duração menor se este não se estender até o final da mesma. Nesse caso, os chunks (pedaços) de Meia, aos que os tracks referem, terão uma duração mais curta.
Cada chunk de Meia que é catalogado por um track tem sua própria escala de tempo determinada por seu sample rate. O QuickTime traduzirá entre uma escala de tempo de um “filme” e a escala de tempo das várias Meias envolvidas na mesma automaticamente. O QuickTime é o que o faz, não a aplicação que usa ao QuickTime. Por exemplo o ProTools, ou o Final Cut Pro.
Outro exemplo poderia ser considerar um “filme” que contém um track de vídeo, um só track de áudio e um track de texto. O “filme” tem uma duração de 2 segundos e sua escala de tempo default é de 600. O vídeo track começa junto com o “filme” (offset 0), vai até o final (duração 1200), a razão de 25 frames por segundo (uma escala de tempo de Meia de 24 unidades de escala de tempo). O track de áudio também começa com o filme, e vai até o final (offset 0, duração 1200), a 48000 samples por segundo (a escala de tempo desta Meia é de 48000). O track de texto contém um simples frame, o título, o qual aparece por 0,25 segundos no “filme” e duro 1 segundo (offset 150, duração 600, escala de tempo de Meia 1).
O QuickTime estabelece a base de tempo de reprodução quando se faz play a um “filme”. Dita base consiste no sistema coordenador de tempo do “filme”, uma velocidade ou Rate, um conceito de "“neste momento” (current time) e uma referência de componentes de tempo que proveja ao QuickTime com medições de tempo real. O Rate determina quantas unidades de escala de tempo correm por unidades de tempo real. O Rate também determina de que maneira é reproduzida o “filme”; para frente ou para trás. Se o valor for negativo, o filme deve ser reproduzida para trás. Se um “filme” com uma escala de tempo de 600 tem um Rate de 1, o QuickTime processará 600 unidades de escala de tempo do “filme” cada segundo indo para frente, e o “filme” correrá a velocidade normal. Um Rate de 0,5 resultará em 300 unidades de escala do “filme” processados por Segundo e o filme será reproduzido a metade de velocidade. Um Rate de –1 significará que o “filme” será reproduzido menor à velocidade normal.
“Neste momento” (Current Time) é simplesmente a localização expressa em unidades de tempo de escala onde o “filme” está enquanto a reprodução acontece. O valor de “neste momento” pode ser desde 0 até o valor da duração do “filme”.
Cada um destes conceitos está composto por uma série de partes mínimas chamadas átomos. Há uma miríade de átomos. Estes se catalogam entre si, harmonizam-se entre si, e são coerentes entre si. Geralmente, não se pode alterar um só deles, mas sim terá que alterar todos os que estão relacionados entre si.
Seus nomes são ocultos para nós, os não iniciados. Por exemplo:
mvhd - tkhd - edts - stsd
Há um programa gratuito da Apple, chamado Dumpster (programa pensado para desenvolvedores de software), que permite examinar um arquivo QuickTime, e até editar os valores destes átomos.
Vejamos como Dumpster vá a um “filme”.
Em que pese a que há muitos campos, há alguns que facilmente são compreensíveis. Por exemplo, em mvhd podemos ver o valor de “timeScale” (600), e seu “duration” (19592). O nome do átomo mvhd é a abreviatura de movie header.
Se dividirmos esta última cifra pela escala de tempo do “filme” nos dará como resultado 32,32 segundos. Trata-se de um comercial do Bimbo. Essa era a duração do comercial mais a cauda inicial.
Em mdia - mdhd a “timeScale” diz 48000. Efetivamente está falando do track de áudio. Quanto a sua “duration” informa que é 1554412 de samples totais. Em efeito, ao dividir essa quantidade total de áudio samples pela escala de tempo deste track (48000), dá-nos, como resultado, uma duração de 32,383583333333 segundos. Sim. Não duram exatamente o mesmo ambos os tracks.
Como se pode ver, são todos valores coerentes entre si. Se trocássemos a escala de tempo da Meia que referência o track de som de 48000 a outro qualquer e não trocássemos acordemente sua duração, o som se iria desincronizando à medida que progride a reprodução deste “filme”. E, é obvio, terminaria antes ou depois da imagem, e ouviríamos que seu pitch trocou proporcionalmente.
Ao clicar sobre cada uma das siglas em letra minúscula e negrito se desdobra toda uma lista de átomos. Os valores que aparecem nos campos destes átomos, como já dissemos, são editáveis. Mas, cuidado... De colocar mal os dedos criarão um arquivo corrupto, meio Frankenstein, que só um perito poderá corrigir.
Só mencionamos este programa para comprovar os valores e sua correlação com os tantísimos parâmetros que pode ter um “filme” QuickTime.
Que tinha Apple em mente quando criou Cinema Tools? Acaso o fez pensando no sonidista do mundo PAL e esqueceu comunicar-lhe?
Nada disso. Apple desenhou este programa para resolverle varios e muito importantes problemas aos usuários de seu programa Final Cut Pro. Problemas como poder exportar uma lista de corte de negativo confiável, por exemplo. Ou como trabalhar com materiais de imagem de diferentes frame rates numa mesma Teme Line. Por exemplo, negativo filmado 24fps misturado com vídeo PAL ou NTSC.
Para poder resolver estes problemas o Final Cut Pró precisava poder rastear cada fotograma de negativo original através do transfer a vídeo e da digitalização a filme QuickTime. Precisava manter uma relação “Um a Um” entre os fotogramas “virtuais” e os originais físicos. Por este e outros fins conexos a Apple criou o Cinema Tools.
É justamente a propriedade do Cinema Tools de manipular os arquivos QuickTime a que nos permite expor este troco no modo de nos dirigir com a imagem durante a post de som.
Voltando nossas mãos sobre o Cinema Tools. trocamos a duração de um filme, conservando a mesma quantidade de frames. Mas...
- ou O que fez exatamente Cinema Tools?
- ou Por que o fez tão rápido?
- ou E... por que este processo é reversível?
Um arquivo QuickTime, como está explicado no Apêndice II, consta de duas grandes seções: os dados e a receita (os fotogramas de imagem e as instruções que explicam como reproduzi-los).
Com respeito “à receita”, pode-se dizer que a mesma tem muitíssimos componentes que lhe dizem ao reprodutor desse arquivo o que fazer com ele. Por exemplo, definem o Codec que descomprimirá esses dados, a velocidade a que os deve reproduzir, quando aparecem e quando desaparecem os títulos (em caso de que existam), a que volume reproduzir seus tracks de som, etc., etc., etc. e o ingrediente da receita que nos resultará muito útil para resolver o problema que nos corresponde: quanto tempo dura a reprodução de cada fotograma da bolsa.
O que Cinema Tools faz é trocar essa informação. Mas calcula e troca também todas as que estão irremediavelmente associadas a esta mudança. Por exemplo, a duração total do filme é alterada em forma diretamente proporcional ao frame rate escolhido.
Para entendê-lo, se pudéssemos trocar essa informação de modo tal que o frame rate fosse de 1 fotograma por segundo, a duração resultante do filme com a que estivemos trabalhando antes seria muitíssimo maior. Seria de 1502 segundos. Ou seja, duraria 25 minutos, 2 segundos, 00 frames.
O Cinema Tools não renderiza os fotogramas, só troca as variáveis da receita, da fórmula que explica ao reprodutor do arquivo o que fazer com esse filme. Por isso o Cinema Tools o faz tão rápido e sem alterar a qualidade da imagem. E por isso é imensamente reversível. É, portanto, uma alteração benigna do arquivo. E por ende, não é destrutiva.
Por exemplo, se logo depois de ter pedido para o Cinema Tools que conforme a 24 fps um arquivo de vídeo de seus originais 25 fps, solicitássemo-lhe que a esse mesmo arquivo o volte a conformar a 25 fps, novamente e sem demoras, converterá-o outra vez na mesma duração que teve o original e é obvio, com a mesma quantidade de fotogramas que ao começo. Tudo sem degradar a qualidade da imagem pois, como dissemos, o Cinema Tools não se mete com a Data do arquivo a não ser com sua Meta Data. Quer dizer, com a informação que descreve a informação do arquivo.