Sound Designers

Bonjour a tous,

Je viens vers vous aujourd'hui afin d'affiner mes connaissances de la vidéo sur protools.

Voila je travaille sur un projet de montage son pour un film d'animation. J'utilise pour cela protools 8.1 LE.

Je viens de récupérer une session protools de bruitage à 25 fps, fait sur une vidéo à 25 fps.
J'importe donc la session de bruitage dans ma session de montage son qui est également à 25 fps.
Puis j'importe la vidéo.
Or, le monteur image a fait une erreur. La video qu'il m'a filé est à 29,97 fps.
Du coup sur la track video apparait en rouge les chiffres "29,97".
Et pourtant tout est synchro. J'aurai cru qu'il y aurait un décalage entre le son et l'image de par la différence de fréquence, mais non.
Est ce que protools corrige automatiquement la fréquence de la vidéo pour l'adapter à la session?

Si je continue à travailler ainsi et qu'au mixage ils repassent sur une vidéo à 25 fps, est ce que l'on risque un problème?

Merci de votre aide et de vos éclaircissements,

Cordialement,

Je n'ai pas la reponse , je fait remonter ta question car elle m'interesse aussi..


En attendant qu'un expert se penche dessus.

Je ne crois pas me tromper en disant que c'est "normal". Qql soit la fréquence, une seconde reste une seconde....
En gros, il est logique que les éléments déjà montés dans la session à 25 soient synchrones. En faisant un export foireux en NTSC, l'image a été compensée (tu dois voir des "sautes" notamment sur les panoramiques) mais, en référence à l'image, les sons restent synchrones.
En revanche, la référence temporelle n'est plus bonne. La où tu avais un bruitage calé à X sec XX images, celui-ci est désormais à X sec XX images +qqls subframes (le "gap" devenant de + en + important à mesure que tu avances dans le film). Ce qui n'empêche pas que l'image, elle, n'a pas bougé pour autant (d'où le synchronisme).
Maintenant, toi tu vas monter sur une image à 29.97 avec une mauvaise référence temporelle, donc, en gros, des frames pas au "bon endroit". Du coup, quand tu vas livrer ta session ou le bounce de ta session (qui, eux, ne seront pas compensés comme ce fut le cas pour l'image lors du passage de PAL en NTSC) et que ça va être recalé sur l'image d'origine en 25, là, ça va pas être joli-joli et ça va être de pire en pire à mesure que le film va se dérouler pour finir en désynchro complète de plusieurs secondes selon la durée du film.
Donc, en gros, coup de fil au monteur pour qu'il fasse son boulot correctement...

Dupont a écrit :Qql soit la fréquence, une seconde reste une seconde....

pas forcément, tout dépend de la manière dont le logiciel gère le timecode. dans un logiciel audio, la référence est toujours (en tout cas à ma connaissance) la référence temporelle : on a bien 1 seconde = 1 seconde. Donc si on change le format de timecode, on change simplement la division virtuelle de la seconde, et les sons ont toujours la même durée (en tout cas si on fait cette mesure en msec). si on se place sur une seconde "ent!ère" (ex : 00:59:58:00), le TC sera le même à 24 ou à 25ips.

dans un logiciel de montage cinéma, on ne mesure pas en temps mais en longueur (de pellicule) et donc en nombre d'image. Un film comporte X images, sa durée change selon la vitesse de lecture choisie. A vitesse de lecture fixe, le timecode affiché (dans un avid par exemple) est basé sur le nombre d'image par rapport à la référence (le début de la timeline), et sera donc différent si on affiche le TC à 24 ou a 25, même sur une seconde entière.

pour les exports type quicktime, ce qui se passe en général (en tout cas ce que j'ai pu constater), c'est que c'est la référence temporelle qui est conservée, pas le nombre d'image (ce qui nécéssiterait un varispeed du son). donc si on exporte en quicktime une timeline 25 à 29,97, on gardera la même durée, et des images intermédiaires vont venir combler les "trous" pour garder une fluidité dans le mouvement (pour du 24>25, ça va être du doublage de trame par exemple). donc la temporalité du film est conservée sur la durée, mais l'image par image est faux. c'est probablement le cas de ton export à 29,97.

par contre, j'ai pu constater que la cadence de lecture que protools affiche, c'est celle qui est inscrite en metadata du fichier quickime. hors, on peut avoir des metadata de vitesse de fichier et de vitesse de lecture différente dans un quiktime. la vitesse de lecture effective du fichier peut donc être différente de celle qui s'affiche... donc dans ton cas, c'est peut etre également ça qui déconne. pour le savoir, ouvre ton fichier dans quicktime et affiche l'inspecteur de séquence (pomme i). enlecture, tu verras s'afficher la cadence réelle en IPS.

Hum, je crois que tu m'as mal lu ou interprété et qu'en gros, on dit la même chose, ou presque... (c'est toujours un peu difficile à mettre en mots ce genre de trucs)
Relis si nécessaire mais tu verras qu'on dit pareil (l'image est compensée, ce que tu appelles "combler les trous", et concernant le son, ce sont juste les termes employés qui changent).
En gros, pour faire plus "ProToolsien", ce qui va bouger pour notre ami (d'où les problèmes futurs), c'est le Grid (la grille temporelle) mais aussi le TC contrairement à ce que tu as l'air de dire (c'est là où on est peut être pas d'accord).
Il suffit de placer le curseur à un temps T dans une session PT et de basculer la session de 24 à 25 ou autre pour constater que, si tant est qu'on soit en affichage de grille=1 image pour + de précision, cette dernière (la grille) va bouger, ainsi que le TC. Donc là où un son était à T, il va se retrouver à T+XX ou T-XX selon le sens.
Cependant, ni le son ni l'image qui va avec n'auront bougé l'un par rapport à l'autre, d'où le synchronisme des sons déjà calés. La où ça va poser problème, c'est pour les sons restant à caler...

Je suis étonné. I am quite surprised...
Personne pour préciser/confirmer/infirmer?....
C'est la grippe A?...

Ben... que dire, à part que t'as raison ?
D'où l'adage : tempo change dans Protools, rien ne bouge.
(du moins jusqu'à l'apparition d'elastic audio !)

Dupont a écrit :Hum, je crois que tu m'as mal lu ou interprété et qu'en gros, on dit la même chose, ou presque... (c'est toujours un peu difficile à mettre en mots ce genre de trucs)

effectivement, on est d'accord. je rebondissait juste sur l'expression 1 sec = 1 sec en essayant de compléter

meumeuh81 a écrit :

Dupont a écrit :Hum, je crois que tu m'as mal lu ou interprété et qu'en gros, on dit la même chose, ou presque... (c'est toujours un peu difficile à mettre en mots ce genre de trucs)

effectivement, on est d'accord. je rebondissait juste sur l'expression 1 sec = 1 sec en essayant de compléter

C'est-à-dire, si je puis me permettre, qu'une seconde de Timecode ne dure pas forcément une seconde de temps réel. C'est pour ça qu'un seconde ne dure pas forcément une seconde...

une seconde de Timecode ne dure pas forcément une seconde de temps réel.

Allons bon..voila autre chose..

Si je me souviens bien la structure du TC c'est : hms-i-ub-(cb-sync)

A la derive de l'horloge pret ( infinitesimale), une Sec de TC= une Seconde "temps reel" . Ou alors explique stp..

Est ce que protools corrige automatiquement la fréquence de la vidéo pour l'adapter à la session?
Si je continue à travailler ainsi et qu'au mixage ils repassent sur une vidéo à 25 fps, est ce que l'on risque un problème?

Si qlq un à une reponse claire et pedagogique à ces questions je suis preneur aussi..

(Je suppose que la cadence image du film 29,97 est incrite en rouge pour signaler quelle est differente de la cadence image du projet son (25), non ?)