Ce que le point-virgule d'un timecode indique réellement
Quand le dernier séparateur d'un timecode passe des deux-points au point-virgule, c'est en général une invite à lire « cette chaîne est présentée en notation drop frame ». Ce que cela traite, c'est l'écart de longue haleine entre le comptage d'images et l'horloge murale à certaines cadences fractionnaires. Mais à la réception d'un fichier de livraison, le point-virgule n'est qu'une invite, et ne prouve pas à lui seul que les positions d'images ont été converties selon les règles drop frame. Notation d'affichage et algorithme de comptage se vérifient séparément.
Le point-virgule dit « cette chaîne veut exprimer une écriture drop frame » ; il ne dit pas automatiquement « ces positions d'images ont été calculées par les règles drop frame ».
D'où vient l'écriture d'un comptage drop frame
À une cadence fractionnaire comme 29.97, le nombre d'images réellement avancées par seconde ne suit pas exactement le rythme d'une numérotation de timecode bâtie sur l'entier 30. Si l'on affiche des numéros d'images continus sans compensation, la lecture du timecode prend peu à peu du retard sur l'horloge murale.
Le calcul par la formule donne, pour un comptage continu comme 29.97, un cumul de l'ordre d'une minute et demie par jour. La pratique du comptage drop frame ne jette donc pas de vraies images vidéo : elle saute certains numéros dans la numérotation du timecode, pour rapprocher de nouveau l'horloge affichée du temps réellement écoulé.
Une convention de texte courante écrit le séparateur de fin en point-virgule, par exemple 01:00:00;00. Ce signe est utile, parce que le destinataire voit tout de suite que le fichier exprime une notation drop frame. Mais le signe reste une partie de la chaîne.
Notation d'affichage et conversion des positions d'images sont deux choses
Un vrai calcul drop frame applique les règles de saut de numéros lorsqu'on convertit entre un numéro d'image et une chaîne heures-minutes-secondes-images. Remplacer simplement le dernier : par un ; change l'apparence, sans changer la position d'images que représentent les chiffres déjà là.
Les deux comportements existent dans le chemin de livraison actuel de SlateX. Quand la position de fin manque et que le logiciel doit calculer un point de sortie à partir du point d'entrée et de la durée, c'est une arithmétique drop frame effective qui est appliquée. Une chaîne de point d'entrée ou de sortie déjà présente, elle, ne voit que son séparateur de fin remplacé par un point-virgule, sans aucune conversion des positions d'images.
C'est la frontière dure de cette page : à voir ;, on sait que la couche de livraison a marqué cette chaîne comme écriture drop frame ; mais le seul symbole ne permet pas de juger si ces chiffres ont déjà été obtenus par une règle drop frame.
Les deux jugements de « proximité à 29.97 » n'ont pas la même tolérance
Le côté temps réel utilise une tolérance de 0.013 pour ramener la cadence nominale de la caméra à un taux de base, et le côté export utilise une tolérance de 0.02 pour décider du drop frame à partir de la valeur numérique — les deux jugements ne portent pas sur le même objet, et leurs tolérances ne sont pas le même nombre. Il en résulte qu'une valeur de cadence située en bordure peut être classée différemment par les deux logiques.
Ce genre d'écart ne doit pas être présenté comme un détail de mise en œuvre que le destinataire n'a pas à regarder. Dès qu'il change le chemin d'affichage ou de calcul retenu par un timecode, l'acceptation doit mettre ensemble le FPS réellement présent dans le fichier, la chaîne de timecode et les médias.
De même, on ne peut pas tenir « la valeur numérique est proche d'une cadence courante » pour l'affirmation que toute la chaîne a déjà retenu la même règle de comptage. Les entrées de jugement diffèrent, et les conclusions peuvent différer.
Ce que le destinataire doit vérifier, c'est comment un média réel correspond au timecode, et non à quoi ressemble seulement le séparateur.
L'affichage en temps réel et le fichier de livraison ne sont pas la même représentation
La chaîne en temps réel de SlateX sort aujourd'hui des timecodes entièrement à deux-points, et ne produit aucune représentation en point-virgule. Autrement dit, la chaîne vue en direct à l'écran de l'app et le point-virgule qui peut apparaître dans un fichier de livraison obéissent à deux règles de représentation d'étapes différentes.
Sous une cadence fractionnaire, la chaîne en direct avance selon la valeur fractionnaire, puis convertit le nombre d'images en chaîne avec une cadence entière ; elle n'a en elle-même aucune représentation de saut de numéros drop frame. On ne peut donc pas, du fait qu'un point-virgule apparaît ensuite dans le fichier de livraison, remonter à l'idée que l'affichage en direct sur le plateau fonctionnait déjà selon la même règle.
À la réception, il faut tenir les deux couches séparées : d'où vient la chaîne brute consignée sur le plateau, si un recalcul a eu lieu à la livraison, si le séparateur a seulement été remplacé, et si le point final correspond réellement aux médias. S'il manque un seul de ces contrôles, le point-virgule ne doit pas être tenu pour une conclusion d'acceptation.
Comment vérifier concrètement un timecode qui contient un point-virgule
Regardez d'abord si le FPS de cette ligne concorde avec les médias et les enregistrements de plateau, puis prenez un média repérable et comparez le point d'entrée réel et la durée écoulée. Si la position de fin du fichier est calculée par le logiciel, il faut confirmer en plus, à part, si elle a suivi la règle de comptage correspondante.
Si le point d'entrée ou de sortie est une chaîne déjà existante, ne regardez pas seulement si elle porte un point-virgule. Le destinataire doit vérifier que les positions d'images elles-mêmes correspondent aux médias. Une chaîne où seul le symbole a changé peut ressembler visuellement à un timecode drop frame correct, mais ses chiffres peuvent venir d'une autre manière de compter.
Le point-virgule convient donc comme invite « ici, il faut vérifier la règle de comptage drop frame », et non comme étiquette « cette ligne est déjà vérifiée ».
FAQ
Le dernier séparateur est un point-virgule : suffit-il à confirmer un calcul drop frame ?
Non. Le point-virgule peut n'être qu'un signe de la couche d'affichage. Le chemin de livraison actuel peut remplacer seulement le séparateur de fin d'une chaîne de timecode déjà présente, sans recalculer les positions d'images.
Drop frame veut-il dire que des images vidéo sont supprimées ?
Ce n'est pas le sens discuté ici. Le comptage drop frame ajuste une règle de numérotation du timecode, destinée à compenser l'écart de longue haleine entre une numérotation continue et l'horloge murale à cadence fractionnaire.
Pourquoi une même valeur de cadence peut-elle être jugée différemment par deux logiques ?
Parce que les deux tolérances actuelles de « proximité à 29.97 » sont 0.013 et 0.02. Une valeur en bordure peut tomber dans des branches différentes, et le destinataire doit vérifier le fichier et les médias réels.
Le timecode affiché en direct à l'écran de l'app utilise-t-il aussi le point-virgule ?
La chaîne en direct actuelle sort des chaînes entièrement à deux-points et ne produit aucune représentation en point-virgule. Le point-virgule d'un fichier de livraison appartient à une autre étape de représentation, et l'on ne peut pas en déduire que la chaîne en direct a retenu le même comptage drop frame.
Axiom One LLC — SlateX. Chiffres arrêtés au 2026-09-24.