Pourquoi une livraison ne peut pas rendre un chemin jusqu’aux médias

ALE, CSV, PDF et FDX peuvent échanger des enregistrements structurés, mais aucun ne remet un chemin qui résoudrait jusqu’aux médias sur la machine du destinataire. Les deux fichiers lisibles par machine portent bien une case « nom de fichier » et une case « chemin », mais pas sous le même nom de colonne : le CSV porte Source File Name et Source File Path, l’ALE porte Source File Name et Source File : le CSV écrit tel quel le chemin que contient l’enregistrement, et dans l’ALE ces deux cases ne sortent que si la chaîne entière est en ASCII, si bien qu’un texte non latin les laisse vides ; ce qu’elles contiennent vient de la recopie sur le plateau ou, si les médias ont été importés depuis un fichier, du chemin relevé sur cette machine, et une case sans l’un ni l’autre part vide. PDF et FDX n’ont aucune de ces deux cases.

Les médias ont bien une place sur le disque dans la bibliothèque de projet ; une case remplie du fichier de livraison nomme un emplacement de la machine émettrice, et le destinataire ne peut pas raccorder ses propres médias en s’appuyant sur elle.

Le chemin d’une case du fichier de livraison appartient à la machine émettrice, et la présence des médias sur cette machine est une autre question

La façon dont les médias sont stockés sur cet appareil regarde l’application ; ce qui compte ici, c’est qu’un chemin du fichier de livraison appartient à la machine émettrice et n’est pas un pointeur que le destinataire peut résoudre. Quand un ALE, un CSV, un PDF ou un FDX est généré, le fichier porte des enregistrements de prises et les champs associés, et non une liste de chemins de médias. Le destinataire a beau voir un numéro de bobine, un numéro de scène ou un numéro de prise, il ne reçoit pas la position physique du fichier local qu’utilisait le projet d’origine. Le numéro de plan n’a une colonne à part que dans CSV et PDF ; l’ALE n’a pas cette colonne.

Pourquoi le nom de fichier ne remplace pas le chemin d’origine

Le nom de fichier porté sur le disque peut déjà différer du nom porté par la source extérieure, et il ne permet donc pas de retrouver d’où vient ce média.

Les photos viennent de deux sources : celles prises sur le plateau ou par prise rapide, et celles choisies dans la photothèque ou importées depuis un fichier. Dans les deux cas, le chemin d’origine n’est pas emporté. Même si le destinataire tombe sur un nom de fichier semblable, il ne peut pas y voir la preuve d’un « nom de fichier d’origine plus octets d’origine » : la case du nom dans le fichier de livraison est assemblée à partir du numéro de bobine et du numéro de clip, et non le nom porté sur le disque. La normalisation des chemins et des noms de fichiers reste sur cette machine ; un chemin écrit dans une case du fichier de livraison nomme le répertoire de cette machine, non la copie du destinataire.

« Le chemin d’une case du fichier de livraison ne permet pas de raccorder les médias du destinataire » décrit une frontière du résultat d’export, et ne porte aucun jugement sur la présence ou l’absence du média dans la bibliothèque de projet locale.

Pourquoi cela borne directement le raccordement des médias

Le chemin écrit dans le fichier de livraison pointe dans le répertoire de la machine émettrice, aussi manque-t-il au destinataire le pointeur physique qui permet de passer d’une ligne d’enregistrement à une position précise de fichier sur sa propre machine. Le numéro de bobine, le numéro de scène et le numéro de prise restent utilisables pour établir une relation d’identité, mais ce sont des identifiants, pas des chemins. Le destinataire doit mettre ces identifiants en correspondance avec son propre inventaire des médias, le nommage des fichiers et l’état réel des répertoires.

C’est exactement la raison pour laquelle « À la réception d’un ALE, vérifiez d’abord ces champs » renvoie le destinataire vers les médias et les enregistrements de plateau. Un fichier s’ouvre et certaines colonnes se lisent sans qu’il porte pour autant la position des médias. Si un flux de travail exige de localiser un média directement depuis le fichier de livraison, cette correspondance doit être apportée par les informations de médias déjà disponibles du côté de la réception.

Pourquoi les quatre fichiers de livraison butent sur la même frontière

ALE et CSV sont des tableaux lisibles par machine, PDF est un résumé destiné à la lecture humaine et FDX sert à l’échange de scénario. ALE et CSV s’appuient sur les mêmes enregistrements de prises et portent une case « nom de fichier » et une case « chemin », mais pas sous des noms communs : le CSV porte Source File Name et Source File Path, l’ALE porte Source File Name et Source File : le CSV écrit telle quelle la valeur stockée, la paire de l’ALE n’accepte que l’ASCII, et la valeur vient de la recopie sur le plateau ou du chemin relevé lors de l’importation des médias depuis un fichier ; sans l’un ni l’autre, la case reste vide. Le PDF existe pour être lu, et FDX travaille depuis un contenu du côté scénario, qui ne porte même pas les enregistrements de prises. Aucun des quatre fichiers ne porte une adresse qui puisse raccorder les médias, et une différence de format ne change pas cette frontière. On ne peut pas déduire d’un format qui a plus de colonnes que cette adresse deviendra un emplacement que le destinataire peut ouvrir. Voir « Où vivent les fichiers de livraison après l’export, et combien de temps ».

Par exemple, « Ce qu’un CSV apporte de plus ou de moins qu’un ALE » traite des écarts entre jeux de champs, et non d’un chemin qui surgirait de nulle part. « À la réception d’un ALE, vérifiez d’abord ces champs » passe case par case celles qui partent vides faute d’avoir été recopiées sur le plateau, et la façon dont cette case manquante ressort sur la feuille de réconciliation de fin de journée. « Les différentes formes d’une valeur manquante dans un fichier de livraison » ajoute une couche sous cette case vide : chaîne vide, tiret en guise de substitut, numéro par défaut généré et timecode à tous les zéros — chacun en arrive là pour une raison différente. À la réception, il faut tenir séparés « cette case, personne ne l’a remplie », « cette case porte un texte recopié » et « un pointeur qui pourrait réellement raccorder un média ». Un nom écrit dans une colonne n’est pas une position.

Comment le destinataire établit la correspondance avec les médias

Pour relier les enregistrements d’un fichier de livraison aux médias, le destinataire doit partir des identifiants visibles tels que numéro de bobine, numéro de scène et numéro de prise, et les vérifier un à un contre son propre inventaire des médias. Si le nommage côté médias, les numéros de bobine ou l’organisation des répertoires ne concordent pas avec l’enregistrement reçu, il faut revenir à l’actualité des médias et aux enregistrements de plateau, au lieu de deviner un chemin. Le fichier de livraison, lui, n’apporte pas cette liaison directe.

Ces fichiers doivent donc être compris comme des données d’enregistrements et d’échange, et non comme un inventaire ou une sauvegarde de médias. Ce qu’ils donnent est une chaîne écrite dans une case et venue de la machine émettrice, pas un pointeur résoluble d’un enregistrement jusqu’aux médias de la machine du destinataire, et ils ne constituent aucune promesse qu’un projet récepteur établisse automatiquement des liens de médias. En conclusion, le destinataire doit vérifier lui-même les numéros de bobine, de scène et de prise contre son propre inventaire des médias.

FAQ

Pourquoi une case de chemin remplie ne permet-elle toujours pas de raccorder les médias ?

Le nom de fichier est un indice d’identité dans l’enregistrement, le chemin est l’endroit où le média se trouve réellement : ce ne sont pas la même chose. ALE et CSV portent chacun une case « nom de fichier » et une case « chemin », mais pas sous des noms communs : le CSV porte Source File Name et Source File Path, l’ALE porte Source File Name et Source File, le CSV écrit telle quelle la valeur stockée, et la paire de l’ALE n’accepte que l’ASCII, si bien qu’un texte non latin les laisse vides. PDF et FDX n’ont aucune des deux. Que la valeur vienne de la recopie sur le plateau ou du chemin relevé à l’importation, elle nomme les fichiers du côté du tournage, pas le répertoire de la machine du destinataire, et une case remplie ne reconstitue donc jamais une position que le destinataire puisse ouvrir.

La livraison peut-elle me rendre le fichier photo d’origine ?

Pas à partir du seul fichier de livraison. Il porte un nom de fichier assemblé à partir du numéro de bobine et du numéro de clip, et non le chemin d’origine de la photo, et il ne promet pas une correspondance octet pour octet avec le fichier d’origine.

CSV porte-t-il des chemins de médias parce qu’il a plus de champs ?

Plus de colonnes ne donnent pas au destinataire un emplacement qu’il pourrait résoudre. Le CSV écrit tel quel dans sa case le chemin que contient l’enregistrement, les deux cases homonymes de l’ALE n’acceptent que l’ASCII, et PDF et FDX n’ont pas ces deux cases du tout ; une case remplie nomme malgré tout un emplacement de la machine émettrice.

À quoi se fier quand il faut raccorder un média ?

Le destinataire doit vérifier lui-même les identifiants visibles tels que numéro de bobine, numéro de scène et numéro de prise, contre son propre inventaire des médias et les fichiers réels. Le chemin que porte le fichier de livraison appartient à la machine émettrice et ne doit pas être lu comme une adresse sur le disque du destinataire.

Axiom One LLC — SlateX