Por que uma mesma taxa de quadros tem uma taxa de contagem e uma base de exibição
Uma mesma opção de taxa de quadros carrega aqui dois números ao mesmo tempo, mas o trabalho que cada um faz é diferente. Um é a taxa de contagem, usada para converter o tempo decorrido do relógio de parede em quantidade de quadros, e ela pode ter decimal; o outro é a base de exibição inteira, usada para converter entre a string de timecode e a contagem de quadros.
Ver 29.97 e agrupar o timecode pela base de 30 não é misturar duas taxas de quadros: são a taxa de contagem e a base de exibição fazendo dois trabalhos diferentes.
Por que uma única opção de taxa de quadros mantém dois conjuntos de números
Numa opção como 29.97, a taxa de contagem responde a “passado tanto tempo do relógio de parede, quantos quadros devem avançar”, e a base de exibição responde a “como esses quadros devem ser divididos numa string de horas, minutos, segundos e quadros”. A primeira admite decimal, porque é a escala do tempo decorrido; a segunda precisa ser inteira, porque é a base de agrupamento do campo de quadros do timecode. Confundir as duas em um único número equivale a tratar a velocidade de avanço e a regra de numeração da string como se fossem a mesma coisa.
23.976 tem a mesma estrutura: o avanço usa a taxa de contagem com decimal, e a conversão em string usa uma base de exibição inteira. Nas opções inteiras, como 24, 25 e 30, essa camada de diferença não existe, porque a taxa de contagem e a base de exibição são iguais. O ponto discutido aqui não é qual dos dois números é mais “real”, e sim que cada conjunto de números serve a um cálculo diferente.
Como dois números diferentes se acumulam numa diferença de tempo
Nessas opções não inteiras, a taxa de contagem é cerca de uma milésima mais lenta que a base de exibição, então o ritmo da numeração de timecode não é a mesma coisa que a velocidade de avanço do relógio de parede. Com 29.97 pareado a 30, ou 23.976 pareado a 24, as strings continuam agrupadas pela base de exibição inteira, enquanto o avanço real usa a taxa de contagem mais lenta. O resultado não é um número que falta de vez em quando, e sim a mesma diferença se acumulando sem parar.
Nesse critério, o timecode fica cada vez mais atrasado em relação ao relógio de parede, na ordem de segundos por hora. Convertendo nesse ritmo, o atraso é de cerca de 3.6 segundos por hora; o mesmo ritmo aplicado a 24 horas dá 86.4 segundos, ou seja, a casa de um minuto e meio. Essa diferença não pode ser apagada com um “parece próximo”, porque ela vem justamente da separação de funções entre os dois conjuntos de números.
O essencial numa opção não inteira não é o decimal se parecer com um inteiro: a taxa de contagem define a velocidade de avanço, a base de exibição define a estrutura da numeração, e a diferença entre as duas se acumula com o tempo.
Como a taxa de quadros do registro de câmera volta à taxa-base
Quando a taxa de quadros registrada em uma câmera é um valor elevado acima da base, a lógica de conversão testa os divisores um a um e compara cada resultado com as taxas-base disponíveis. O primeiro candidato que entra na tolerância mínima passa a ser a taxa-base; se nenhum candidato corresponder, o caminho de volta usa 24. Aqui a tolerância é pequena para que valores elevados próximos possam cair de volta na base correspondente sem misturar as opções normais vizinhas.
Por exemplo, 24 e 23.976 diferem em 0.024, então a tolerância precisa ser menor que essa distância para que 24 continue sendo 24, em vez de ser sugado para 23.976. Contar o material elevado pela taxa-base é um tratamento comum no setor, mas isso não quer dizer que seja o único caminho que a parte receptora deva adotar. Ela ainda deve conferir o rótulo da taxa de quadros contra o arquivo de entrega real e os próprios registros de mídia.
Por que essa contagem em tempo real ainda é NDF
Na cadeia em tempo real das opções não inteiras, os números de quadro crescem de forma contínua, sem recuperar o relógio de parede pulando números de quadro; por isso a contagem aqui é não drop-frame, isto é, NDF. NDF descreve como a cadeia em tempo real numera, e não declara que a cadeia de entrega de ponta a ponta tenha a mesma regra de exibição. Ler “não pular números” como “o timecode vai alcançar o relógio de parede” dá exatamente o contrário: a diferença acumulada descrita acima continua lá.
O lado da exportação tem uma decisão própria sobre a exibição drop-frame, e essa escrita com ponto e vírgula hoje aparece apenas nas colunas de timecode do ALE e do CSV (o corpo do PDF do relatório diário não tem coluna de timecode), então o critério da cadeia em tempo real e o do lado da exportação não são unificados. Não se pode concluir daí que o app tenha uma capacidade de timecode drop-frame que atravesse do set até a entrega, nem escrever que o timecode está sincronizado com o relógio de parede. Sobre o significado do ponto e vírgula num arquivo de entrega, veja “O que exatamente o ponto e vírgula no timecode indica”, em vez de inferir o resultado da exportação a partir do NDF em tempo real.
Por que a entrega ainda exige olhar o rótulo e o separador
O rótulo da taxa de quadros diz à parte receptora qual velocidade aquela linha do arquivo de entrega declara usar, e o separador do timecode mostra qual escrita de exibição o lado da exportação adotou. Nenhuma dessas duas informações substitui a conferência do registro de origem, sobretudo quando os critérios da cadeia em tempo real e da exportação não são unificados. Quando for preciso rastrear de onde vem o valor de uma coluna, combine “De onde vem o valor de cada coluna do ALE” e confira coluna por coluna, em vez de olhar apenas se o timecode tem um formato familiar.
Portanto, a parte receptora deve conferir ela mesma o rótulo da taxa de quadros e o separador do timecode no arquivo de entrega e colocá-los lado a lado com o registro do set e com as informações do lado da mídia. A taxa de contagem cuida do avanço, a base de exibição cuida da conversão em string e o lado da exportação decide a forma de exibição; essas três camadas não devem se substituir entre si. Uma vez separadas as camadas, ver 29.97 e 30 aparecendo juntos deixa de ser duas respostas contraditórias.
FAQ
Se a taxa é 29.97, por que ainda aparece o número 30?
29.97 é a taxa de contagem e 30 é a base de exibição; eles servem, respectivamente, ao avanço da quantidade de quadros e à divisão da string de timecode. Os dois aparecerem ao mesmo tempo é uma divisão de trabalho entre os cálculos, e não uma troca temporária de uma opção de taxa de quadros por outra.
23.976 também usa essa estrutura de dois números?
Sim, 23.976 avança com uma taxa de contagem com decimal, e a conversão da string de timecode usa uma base de exibição inteira. A taxa de contagem é cerca de uma milésima mais lenta que a base de exibição, então o timecode vai ficando cada vez mais atrasado em relação ao relógio de parede.
O NDF da cadeia em tempo real significa que a exportação também escreve em NDF?
Não se pode fazer essa inferência. A cadeia em tempo real é uma contagem NDF, que não pula número de quadro, enquanto o lado da exportação tem uma decisão própria de exibição drop-frame, então os critérios de ponta a ponta não são unificados.
O que a parte receptora deve conferir no final?
A parte receptora deve conferir ela mesma o rótulo da taxa de quadros e o separador do timecode no arquivo de entrega, comparando-os com o registro do set e com as informações de mídia. Um único número ou um único tipo de separador não basta para tratar a cadeia inteira como se já estivesse verificada.
Axiom One LLC — SlateX. Os números acima são os de 2026-09-24.