Perché alla stessa frequenza fotogrammi corrispondono una frequenza di conteggio e una base di visualizzazione
Qui un'unica opzione di frequenza fotogrammi porta con sé due numeri, che però svolgono lavori diversi. Uno è la frequenza di conteggio usata per far avanzare il tempo dell'orologio da parete fino al numero di fotogrammi, e può essere frazionaria; l'altro è la base di visualizzazione intera usata per convertire la stringa di timecode in numero di fotogrammi e viceversa.
Vedere 29.97 e scrivere il timecode raggruppato su 30 non significa mescolare due frequenze fotogrammi: sono la frequenza di conteggio e la base di visualizzazione a fare due cose diverse.
Perché una sola impostazione di frequenza fotogrammi mantiene due serie di numeri
Prendendo un'impostazione come 29.97, la frequenza di conteggio risponde alla domanda «trascorso tutto questo tempo dell'orologio da parete, di quanti fotogrammi va fatto avanzare il conteggio», mentre la base di visualizzazione risponde a «come vanno divisi questi fotogrammi in una stringa di ore, minuti, secondi e fotogrammi». La prima ammette i decimali ed è la scala del trascorrere; la seconda deve essere intera ed è la base di raggruppamento del campo fotogrammi del timecode. Fonderle in un unico numero vorrebbe dire scambiare la velocità di avanzamento e la regola di numerazione della stringa per la stessa cosa.
23.976 ha la stessa struttura: l'avanzamento usa la frequenza di conteggio decimale, la conversione in stringa usa una base di visualizzazione intera. Le impostazioni intere come 24, 25 e 30 non hanno questa differenza, perché frequenza di conteggio e base di visualizzazione coincidono. Qui il punto non è quale dei due numeri sia più «vero», ma che le due serie di numeri servono calcoli diversi.
Come due numeri discordanti si accumulano in una differenza di tempo
Nelle impostazioni non intere la frequenza di conteggio è più lenta della base di visualizzazione di circa un millesimo, quindi il ritmo della numerazione del timecode non coincide con la velocità di avanzamento dell'orologio da parete. Con 29.97 abbinato a 30, o 23.976 abbinato a 24, la stringa resta raggruppata sulla base di visualizzazione intera, ma l'avanzamento reale usa la frequenza di conteggio più lenta. Il risultato non è un'etichetta che ogni tanto manca, è la stessa differenza che si accumula in modo continuo.
Con questo criterio il timecode resta progressivamente più indietro rispetto all'orologio da parete, su una scala di secondi per ora. Convertendo quel ritmo, il ritardo è di circa 3.6 secondi all'ora; applicato lo stesso ritmo a 24 ore si ottengono 86.4 secondi, cioè l'ordine del minuto e mezzo. Questa differenza non si può annullare con un «sembrano vicini», perché nasce proprio dalla separazione dei compiti tra le due serie di numeri.
Nelle impostazioni non intere quel che conta non è che il decimale somigli a un intero: la frequenza di conteggio decide la velocità di avanzamento, la base di visualizzazione decide la struttura della numerazione, e la differenza tra le due si accumula nel tempo.
Come la frequenza fotogrammi del record della videocamera viene riportata a una frequenza base
Quando la frequenza fotogrammi registrata su una videocamera è un valore di overcrank, cioè più alto di una frequenza base, la logica di conversione prova i divisori uno dopo l'altro e confronta il risultato con le frequenze base disponibili. Il primo candidato che cade dentro una tolleranza molto stretta viene preso come frequenza base; se nessun candidato corrisponde, si ripiega su 24. La tolleranza è piccola perché i valori di overcrank prossimi a una base possano ricadere sulla base corrispondente senza fondere le impostazioni ordinarie adiacenti.
Per esempio 24 e 23.976 distano 0.024, quindi la tolleranza deve essere più piccola di questo scarto perché 24 resti 24 invece di essere assorbito in 23.976. Contare i materiali in overcrank sulla frequenza base è un trattamento comune nel settore, ma non equivale a dire che sia l'unica strada che chi riceve il file deve adottare. Chi riceve il file continua a dover verificare l'etichetta della frequenza fotogrammi in base al file di consegna effettivo e ai propri record dei media.
Perché questo conteggio live resta NDF
Nel percorso live delle impostazioni non intere i numeri di fotogramma crescono in modo continuo, senza recuperare l'orologio da parete saltando alcuni numeri di fotogramma: qui si tratta quindi di un conteggio non-drop-frame, cioè NDF. NDF descrive la numerazione del percorso live, non dichiara che la catena di consegna end-to-end abbia la stessa regola di visualizzazione. Leggere «non salta numeri» come «il timecode raggiungerà l'orologio da parete» è esattamente il contrario: la differenza accumulata sopra resta.
Il lato esportazione ha una propria decisione separata per la visualizzazione drop-frame, e questa scrittura con punto e virgola al momento compare solo nelle colonne del timecode di ALE e CSV (il corpo della tabella del PDF del rapporto giornaliero non ha una colonna di timecode), quindi i criteri del percorso live e del lato esportazione non sono allineati. Da qui non si può affermare che l'app abbia una capacità di timecode drop-frame che attraversa il set fino alla consegna, né scrivere che il timecode è sincronizzato con l'orologio da parete. Per il significato del punto e virgola in un file di consegna occorre guardare «Cosa dice davvero un punto e virgola nel timecode», invece di risalire al risultato dell'esportazione partendo dall'NDF del percorso live.
Perché in consegna contano ancora etichetta e separatore
L'etichetta della frequenza fotogrammi dice a chi riceve il file quale ritmo quella riga di consegna dichiara di usare, mentre il separatore del timecode riflette quale scrittura di visualizzazione il lato esportazione ha adottato. Nessuna delle due informazioni sostituisce la verifica del record sorgente, tanto meno quando le regole del percorso live e del lato esportazione non sono unificate. Per risalire da dove arriva il valore di una colonna ci si può appoggiare a «Da dove viene il valore di ogni colonna ALE» e verificare colonna per colonna, invece di guardare soltanto se la stringa di timecode ha un aspetto familiare.
Perciò chi riceve il file deve verificare in autonomia l'etichetta della frequenza fotogrammi e il separatore del timecode nel file di consegna, e giudicarli insieme alle registrazioni del set e alle informazioni lato media. La frequenza di conteggio fa l'avanzamento, la base di visualizzazione fa la conversione in stringa e il lato esportazione decide separatamente la forma di visualizzazione: questi tre livelli non si sostituiscono l'uno con l'altro. Tenendoli separati, vedere 29.97 e 30 nello stesso momento non è più una coppia di risposte che si contraddicono.
FAQ
Perché con 29.97 si vede anche il numero 30?
29.97 è la frequenza di conteggio e 30 è la base di visualizzazione: servono rispettivamente a far avanzare i fotogrammi e a dividere la stringa di timecode. La loro compresenza è una divisione dei calcoli, non indica che un'impostazione sia stata temporaneamente trasformata in un'altra.
Anche 23.976 usa la stessa struttura a due numeri?
Sì: 23.976 avanza con una frequenza di conteggio decimale, mentre la conversione della stringa di timecode usa una base di visualizzazione intera. La frequenza di conteggio è più lenta della base di visualizzazione di circa un millesimo, quindi il timecode resta gradualmente indietro rispetto all'orologio da parete.
L'NDF del percorso live significa che anche l'esportazione scrive in NDF?
Non se ne può dedurre. Il percorso live è un conteggio NDF che non salta numeri di fotogramma, mentre il lato esportazione ha una propria decisione per la visualizzazione drop-frame: i criteri end-to-end non sono allineati.
Cosa deve verificare alla fine chi riceve il file?
Chi riceve il file deve verificare in autonomia l'etichetta della frequenza fotogrammi e il separatore del timecode nel file di consegna, confrontandoli con le registrazioni del set e con le informazioni sui media. Un singolo numero o una singola forma di separatore non bastano a considerare verificata l'intera catena.
Axiom One LLC — SlateX. I numeri di questo articolo sono aggiornati al 2026-09-24.