O que exatamente o ponto e vírgula no timecode indica

Quando o último separador do timecode passa de dois-pontos para ponto e vírgula, isso costuma estar sinalizando “esta string está exibida com marcador de drop-frame”. O problema que ele resolve é o desvio de longo prazo entre a contagem de quadros e o relógio humano em certas taxas de quadros não inteiras. Mas, ao receber um arquivo de entrega, o ponto e vírgula só serve como indício e não prova sozinho que os números de quadro já foram convertidos pela regra de drop-frame. O marcador de exibição e o algoritmo de contagem precisam ser conferidos separadamente.

O ponto e vírgula diz que “esta string quer expressar uma escrita de drop-frame”; ele não diz automaticamente que “estes números de quadro já foram calculados pela regra de drop-frame”.

Por que existe uma escrita de contagem drop-frame

Numa taxa de quadros não inteira como 29.97, a quantidade de quadros que realmente avança por segundo não tem exatamente o mesmo ritmo da numeração de timecode feita com o inteiro 30. Se a exibição continuar usando números de quadro inteiros consecutivos sem compensação, a leitura do timecode vai ficando progressivamente atrasada em relação ao relógio de parede.

Calculando pela fórmula, uma contagem consecutiva como a de 29.97 acumula, ao longo de um dia, algo na ordem de um minuto e meio. Por isso a contagem drop-frame não consiste em descartar de fato quadros de vídeo: ela pula alguns números na numeração do timecode, seguindo uma regra, para aproximar de novo o relógio exibido do tempo realmente decorrido.

A convenção de texto mais comum escreve o último separador como ponto e vírgula, por exemplo 01:00:00;00. Esse símbolo é útil, porque a parte receptora percebe de imediato que o arquivo está expressando uma forma de marcador de drop-frame. Mas o símbolo continua sendo só uma parte da string.

Marcador de exibição e conversão dos números de quadro são duas coisas

O cálculo verdadeiro de drop-frame precisa executar a regra de pular números ao converter entre a numeração de quadros e as casas de hora, minuto, segundo e quadro. Trocar simplesmente o último : por ; só muda a aparência, sem mudar a posição de quadro que aquela sequência de números já representava.

Nos caminhos de entrega atuais do SlateX, os dois comportamentos existem. Quando falta a posição final e o software precisa calcular o ponto de saída a partir do ponto de entrada e da duração, entra a aritmética real de drop-frame. Já uma string de ponto de entrada ou de saída que já existe tem apenas o seu último separador trocado por ponto e vírgula, sem nenhuma conversão de posição de quadro.

Essa é a fronteira rígida deste texto: ao ver ;, dá para saber que a camada de entrega marcou aquela string como escrita de drop-frame; mas só com esse símbolo não se pode julgar se aqueles números foram ou não obtidos antes pela regra de drop-frame.

As duas tolerâncias de “perto de 29.97” não são o mesmo número

No lado em tempo real, a tolerância usada para devolver a taxa nominal da câmera à taxa-base é 0.013; no lado da exportação, a tolerância usada para decidir por valor se há drop-frame é 0.02. As duas verificações julgam objetos diferentes, e a tolerância também não é o mesmo número. Isso significa que um valor de taxa de quadros que esteja na borda pode receber classificações diferentes nesses dois pedaços de lógica.

Esse tipo de diferença não deve ser embalado como detalhe de implementação de que a parte receptora não precisa cuidar. Sempre que ele mudar qual caminho de exibição ou de cálculo um timecode adotou, a aceitação deve pôr lado a lado o FPS real do arquivo, a string de timecode e a própria mídia para conferir.

Do mesmo modo, não se pode equiparar diretamente “o valor numérico é próximo de uma taxa de quadros comum” com “toda a cadeia já adotou a mesma regra de contagem”. Se o ponto de julgamento é diferente, a conclusão também pode ser diferente.

O que a parte receptora precisa verificar é como uma mídia real corresponde ao timecode, e não só com que aparência vem o separador.

A exibição em tempo real do app e o arquivo de entrega não são a mesma representação

A cadeia em tempo real do SlateX hoje emite timecode com todos os dois-pontos e não produz representação com ponto e vírgula. Ou seja, a string em tempo real que se vê na tela do app e o ponto e vírgula que pode aparecer no arquivo de entrega são regras de representação de duas etapas diferentes.

A cadeia em tempo real avança a contagem pelo valor não inteiro nas taxas fracionárias e depois converte a quantidade de quadros em string usando a taxa de quadros inteira; ela própria não tem representação de pular números no estilo drop-frame. Portanto, não se pode, porque um ponto e vírgula apareceu depois no arquivo de entrega, retroceder e concluir que a exibição em tempo real no set já trabalhava com a mesma regra.

Na recepção, as duas camadas devem ser separadas: de onde vem a string original registrada no set, se houve recálculo na entrega, se o separador foi apenas substituído e se o alinhamento com a mídia final realmente se sustenta. Faltando um desses itens, não se deve tomar o ponto e vírgula como conclusão de aceitação.

Como conferir na prática um timecode com ponto e vírgula

Veja primeiro se o FPS daquela linha bate com a mídia e com o registro do set, depois escolha uma mídia localizada e confronte o ponto de entrada real e o tempo decorrido. Se a posição final do arquivo foi calculada pelo software, confirme ainda, à parte, se ela passou pela regra de contagem correspondente.

Se o ponto de entrada ou o ponto de saída for uma string já existente, não olhe apenas se ela tem um ponto e vírgula. A parte receptora deve verificar se os próprios números de quadro conseguem corresponder à mídia. Uma string em que só o símbolo foi trocado pode visualmente parecer um timecode drop-frame correto, mas os seus números ainda podem vir de outro modo de contagem.

Por isso, o ponto e vírgula serve bem como o indício de “aqui é preciso verificar o critério de drop-frame”, e não como a etiqueta de “esta linha já está verificada”.

FAQ

Se o último separador do timecode é ponto e vírgula, dá para confirmar que ele foi calculado pela regra de drop-frame?

Não. O ponto e vírgula pode ser só um marcador da camada de exibição. Nos caminhos de entrega atuais, uma string de timecode já existente pode ter apenas o seu último separador substituído, sem recálculo das posições de quadro.

Drop-frame quer dizer que quadros reais de vídeo foram apagados?

Não é esse o sentido discutido aqui. A contagem drop-frame ajusta a regra de numeração do timecode, para compensar o desvio de longo prazo entre a numeração consecutiva e o relógio de parede nas taxas de quadros não inteiras.

Por que o mesmo valor de taxa de quadros pode ser julgado de dois modos?

Porque as duas tolerâncias atuais de “perto de 29.97” são 0.013 e 0.02, cada uma em um lugar. Valores na borda podem cair em ramos diferentes, e por isso a parte receptora deve conferir o arquivo e a mídia reais.

O timecode em tempo real na tela do app também usa ponto e vírgula?

A cadeia em tempo real atual emite strings com todos os dois-pontos e não produz representação com ponto e vírgula. O ponto e vírgula do arquivo de entrega pertence à representação de outra etapa, e não se pode inferir dele que a cadeia em tempo real também adotou a mesma contagem drop-frame.

Axiom One LLC — SlateX. Os números acima são os de 2026-09-24.