Pourquoi une même cadence d'images porte à la fois un taux de comptage et une base d'affichage

Un seul réglage de cadence d'images porte ici deux nombres, mais les deux ne font pas le même travail. L'un est le taux de comptage, qui sert à faire avancer l'horloge murale en nombre d'images, et il peut être décimal ; l'autre est la base d'affichage, un entier, qui sert à convertir une chaîne de timecode en nombre d'images et inversement.

Voir 29.97 et écrire le timecode sur 30 cases ne veut pas dire mélanger deux cadences d'images : le taux de comptage et la base d'affichage font deux choses différentes.

Pourquoi un seul réglage de cadence garde deux nombres

Prenons un réglage comme 29.97 : le taux de comptage répond à « si l'horloge murale a avancé de telle durée, de combien d'images doit-on avancer », et la base d'affichage répond à « comment ces images doivent être découpées en une chaîne heures, minutes, secondes, images ». Le premier admet les décimales, c'est l'échelle de la marche du temps ; la seconde doit être un entier, c'est la base de groupement des positions d'images du timecode. Réduire les deux à un seul nombre, c'est tenir la vitesse de marche du temps et la règle de numérotation des chaînes pour une seule et même chose.

23.976 présente la même structure : l'avancement utilise un taux de comptage décimal, et la conversion en chaîne de timecode utilise une base d'affichage entière. Les réglages entiers comme 24, 25 ou 30 n'ont pas cet écart, parce que le taux de comptage y est égal à la base d'affichage. Ce qui est en jeu ici n'est pas de savoir quel nombre est le plus « vrai » : ce qui compte, c'est que les deux nombres servent chacun des calculs différents.

Comment l'écart entre les deux nombres se cumule en décalage de temps

Sur ces réglages non entiers, le taux de comptage avance d'environ un millième moins vite que la base d'affichage, et le rythme de numérotation du timecode ne coïncide donc pas avec la vitesse de marche de l'horloge murale. Avec 29.97 associé à 30, ou 23.976 associé à 24, la chaîne reste groupée par la base d'affichage entière, mais l'avancement réel utilise le taux de comptage plus lent. Le résultat n'est pas un numéro manqué de temps en temps, c'est le même écart qui se cumule sans s'arrêter.

Sous cette convention, le timecode décroche de plus en plus par rapport à l'horloge murale, de l'ordre de la seconde par heure. À ce rythme, le retard fait environ 3.6 secondes par heure ; en appliquant le même rythme sur 24 heures on obtient 86.4 secondes, soit cet ordre d'une minute et demie. Cet écart ne s'efface pas en disant que « cela paraît proche », puisqu'il vient précisément de la séparation des rôles entre les deux nombres.

Sur un réglage non entier, l'essentiel n'est pas que le décimal ressemble à un entier : le taux de comptage décide de la vitesse d'avancement et la base d'affichage décide de la structure de numérotation, et leur écart se cumule avec le temps.

Comment la cadence enregistrée sur une caméra se ramène au taux de base

Quand la cadence enregistrée sur une caméra est une valeur de surcadence supérieure à la base, la conversion essaie les diviseurs l'un après l'autre et compare chaque résultat aux taux de base disponibles. Le premier candidat qui tombe dans la très petite tolérance retenue devient le taux de base ; si aucun candidat ne tombe juste, on retombe sur 24. La tolérance est volontairement étroite, pour que des valeurs de surcadence proches reviennent bien à la base correspondante sans mêler pour autant les réglages normaux voisins.

Par exemple 24 et 23.976 diffèrent de 0.024, donc la tolérance doit être plus petite que cette distance pour que 24 reste 24 au lieu d'être absorbé par 23.976. Compter les rushes de surcadence au taux de base est un traitement courant dans le métier, mais cela ne veut pas dire que ce soit le chemin unique que le destinataire doit adopter. Le destinataire doit continuer de vérifier l'étiquette de cadence d'images à partir du fichier de livraison effectif et de ses propres enregistrements de médias.

Pourquoi ce comptage en direct reste du NDF

Dans la chaîne en direct d'un réglage non entier, les numéros d'images augmentent de façon continue, sans rattraper l'horloge murale en sautant certains numéros d'images : il s'agit donc d'un comptage non drop frame, c'est-à-dire NDF. Le NDF décrit la façon dont la chaîne en direct numérote, il n'annonce pas que la chaîne de livraison de bout en bout porte la même règle d'affichage. Tenir « on ne saute pas de numéro » pour « le timecode rattrapera l'horloge murale » inverse exactement le sens : le décalage cumulé décrit plus haut reste en place.

Le côté export a par ailleurs son propre arbitrage d'affichage drop frame, et cette écriture au point-virgule n'apparaît actuellement que dans les colonnes de timecode des ALE et des CSV (le corps du tableau du rapport journalier en PDF n'a pas de colonne de timecode), si bien que les conventions de la chaîne en direct et du côté export ne concordent pas. On ne peut pas en déduire que l'app ait une capacité de timecode drop frame allant du plateau jusqu'à la livraison, ni écrire que le timecode est synchronisé sur l'horloge murale. Pour la signification du point-virgule dans un fichier de livraison, il faut lire « Ce que le point-virgule d'un timecode indique réellement », et non remonter du NDF en direct jusqu'au résultat de l'export.

À la livraison, pourquoi regarder aussi l'étiquette et le séparateur

L'étiquette de cadence d'images dit au destinataire quelle vitesse cette ligne de livraison prétend utiliser, et le séparateur de timecode reflète quelle écriture d'affichage a été retenue côté export. Aucune de ces deux informations ne remplace la vérification de l'enregistrement source, surtout quand les arbitrages de la chaîne en direct et du côté export ne sont pas unifiés. Quand il faut remonter d'où vient une valeur de colonne, on peut s'appuyer sur « D'où viennent les valeurs de chaque colonne d'un ALE » et vérifier colonne par colonne, au lieu de regarder seulement si le timecode a une forme familière.

Le destinataire doit donc vérifier lui-même, dans le fichier de livraison, les étiquettes de cadence d'images et les séparateurs de timecode, et les croiser avec les enregistrements de plateau et les informations côté médias. Le taux de comptage gère l'avancement, la base d'affichage gère la conversion en chaîne, et le côté export décide ensuite la forme d'affichage : ces trois couches ne doivent pas se remplacer l'une l'autre. Tant que les couches restent distinctes, voir 29.97 et 30 ensemble n'est plus deux réponses qui se contredisent.

FAQ

Pourquoi voit-on aussi 30 avec du 29.97 ?

29.97 est le taux de comptage et 30 la base d'affichage, servant l'un à faire avancer le nombre d'images et l'autre à découper la chaîne de timecode. Les voir ensemble relève d'une répartition des calculs, et ne veut pas dire qu'un réglage a été remplacé provisoirement par un autre réglage.

23.976 utilise-t-il la même structure à deux nombres ?

Oui : 23.976 avance avec un taux de comptage décimal, tandis que la conversion de la chaîne de timecode utilise une base d'affichage entière. Le taux de comptage avance d'environ un millième moins vite que la base d'affichage, donc le timecode ralentit peu à peu par rapport à l'horloge murale.

Le NDF de la chaîne en direct veut-il dire que l'export est écrit en NDF ?

On ne peut pas le tirer ainsi. La chaîne en direct compte en NDF, sans sauter de numéros d'images, tandis que le côté export a son propre arbitrage d'affichage drop frame, et les conventions de bout en bout ne concordent pas.

Que doit vérifier le destinataire à la fin ?

Le destinataire doit vérifier lui-même, dans le fichier de livraison, les étiquettes de cadence d'images et les séparateurs de timecode, et les confronter aux enregistrements de plateau comme aux informations des médias. Un seul nombre ou une seule forme de séparateur ne permet pas de tenir la chaîne entière pour vérifiée.

Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.