On dit DF ou NDF.

La plupart du temps, lorsqu'on utilise le Time Code, c'est pour qu'un événement puisse être aisément localisé sur un support. Grâce à son adresse unique en HH:MM:SS:II, on peut distinguer chaque "image" d'un enregistrement, qu'il soit purement audio ou vidéo (image+audio).

Dans ce cas, on se contrefiche de savoir si un coup de tom a lieu exactement à 00 Heure 03 Minutes 42 Secondes et 19 Images depuis le début du morceau. Ce qui importe, c'est que ce coup de tom soit à une adresse précise, ce qui va permettre à l'ingénieur du son de faire des choses par rapport à cette adresse : déclencher un sample, ouvrir un noise-gate, caler un autre son en vis à vis du tom, etc...

Maintenant, lorsqu'une régie finale d'une chaîne de télévision diffuse un film et, par exemple, qu'une coupure publicitaire doit se faire à un instant précis depuis le début du film, c'est à la seconde près, voire même à l'image près qu'elle doit avoir lieu. Or, le time code SMPTE ne peut incrémenter que par images entières.

Si le film est en noir et blanc, tout se passe bien :

A chaque nouvelle image (qui dure 1/30ème de sec.), le Time Code incrémente d'1/30ème

Si le film est en couleur, l'indication du Time Code est de plus en plus fausse, quant à la position de l'événement depuis le début du film puisque :

A chaque nouvelle image (qui dure un peu plus qu'1/30ème de sec.), le Time code incrémente, lui, toujours d'1/30ème (il ne peut faire autrement). Il prend du retard par rapport au temps réel.

Ce décalage par rapport au temps réel est ennuyeux pour de nombreuses applications liées à l'image des systèmes vidéo-couleur américains et japonais (60 Hz).

Pour remédier à ce problème, la SMPTE a trouvé une méthode d'incrémentation des chiffres du time code, appellée Drop Frame (DF). Accrochez-vous, ça devient marrant :

Toutes les minutes, le time code incrémente directement de 3 images au lieu d'une. Exemple :

.................
01:23:59:27
01:23:59:28
01:23:59:29
01:24:00:02	<-- le compteur de TC saute (drop) l'adresse 01:24:00:00 et 01:24:00:01
01:24:00:03
01:24:00:04
.................

En faisant ça le time code prend effectivement un peu d'avance par rapport au temps réel (c'est le but recherché, car sinon, il prend du retard)... Mais maintenant il en prend trop !!!

Ah Shit !!!

Bon alors... Réfléchissons... mmmmmhhmhhh.... Euréka !

Revenons à l'incrémentation normale toutes les dizaines de minutes !!! Exemple :

.................
01:29:59:27
01:29:59:28
01:29:59:29
01:30:00:00	<-- on vient de passer à la dizaine "30" minutes, l'incrémentation se déroule normalement. Il en est de même lorsque le chiffre des minutes passe à "00", "10", "20", "40" et "50".
01:30:00:01
01:30:00:02
.................

Pour résumer, chaque heure, il y a 54 minutes où il se passe quelque chose de bizarre, et 6 minutes où tout est normal.

Un bon synchroniseur est capable de se dépatouiller entre n'importe quel format de Time Code, qu'il soit 24, 25, 30 ou 29,97 i/s, et qu'il soit DF ou NDF.

J'insiste sur le fait que dans un studio qui se sert du time code uniquement pour synchroniser deux magnétos, par exemple, ou encore pour piloter une automation de console, ou pour caler des samples.... sans que la moindre image vidéo soit impliquée de près ou de loin dans le projet : on se contre fout du temps-réel. Ce qui compte, c'est que chaque événement ait une adresse unique.

Par contre, si vous travaillez pour l'image d'un pays en 60 Hz, directement ou indirectement, il vaut mieux bosser en 29,97 DF. Tôt ou tard, votre travail se retrouvera confronté à cette cadence bizarre de la vidéo couleur 60 Hz, et autant être temps réel, comme le demande ce genre de travail.

Eho ! Vous autres qui consultez ce site depuis un pays autre que l'Amérique du Nord ou le Japon (ou les Emirats Arabes Unis) !!! Tout ceci ne vous concerne pas, vous êtes dans un pays où le secteur est à 50 Hz !!!!!!!!!

Pas de panique, donc, la cadence image est toujours de 25 i/s, et il n'y a pas besoin de système DF. On est en permanence en NDF, à tel point qu'on ne le précise même pas ! On parle toujours de "time code 25 i/s", jamais de "25 NDF" (et encore moins, sauf idiotie totale, de 25 DF !!!).

RECAPITULATIF :

S'il y a 3 grands formats de Time Code dans le monde, on a vu que le format SMPTE comportait des variantes, ce qui porte le total des formats à 6. Quoique...

Film :	24 i/s		Pour le cinéma. On est forcément en NDF, on ne le précise donc pas.
EBU :	25 i/s		Pour la télévision dans les pays où le secteur est à 50 Hz. On est forcément en NDF, on ne le précise donc pas.
SMPTE :	30 i/s	NDF	temps-réel, vidéo 60 Hz N&B
	30 i/s	DF	Complètement débile ! On va volontairement rendre non-temps-réel un truc qui l'était parfaitement bien ?!?!
	29,97 i/s	NDF	non-temps-réel, vidéo 60 Hz couleur
	29,97 i/s	DF	temps-réel, vidéo 60 Hz couleur

Le 30 DF étant absurde, il ne reste plus que 5 formats de Time Code (certains logiciels, pour paraître professionnels, proposent de tourner à 30 DF dans leurs menus de synchro !!!).