なぜ納品物は素材へ再接続できるパスを渡せないのか
ALE、CSV、PDF、FDX はいずれも構造化された記録を引き継げますが、どれからも、受け取り側の機械にある素材へ再接続できるパスは渡せません。機械可読の 2 種類の納品物には Source File Name のマスとソースファイルを入れるマスが実際にあり、そこに入るのは現場で書き取った文字です。ソフトはディスクを回って位置を探さず、書き取られなければマス全体が空で出ます。プロジェクトライブラリの中にあるあの実際のパスは、エクスポートのスナップショットに一度も運ばれていません。
素材はプロジェクトライブラリの中に実際に保存の位置を持ちます。ただ、納品物の中のあの 1 マスは書き取られた文字にすぎず、受け取り側はそれだけを頼りにメディアを再接続することはできません。
ローカルのメディアに保存先が 2 種類あるのはなぜか
メディアをローカルに保存するとき、単一のディレクトリ規則だけが通るのではありません。新規作成のフォームで生まれる動画は、フラットな受け入れ領域に入ります。一覧側からの撮影、ライブラリ選択、ファイル取り込みは、プロジェクト・シーン・ショット・テイクで層分けされた構造化ディレクトリに入ります。2 つの保存先はいずれも、プロジェクトライブラリの内部でメディアをどう保存するかという話です。
重要な境界は、これらのパスがプロジェクトライブラリの中にだけ存在して、エクスポートのスナップショットには入らないという点です。ALE、CSV、PDF、FDX を生成するとき、エクスポート側が受け取るのはテイク記録と関連フィールドのスナップショットであって、メディア資産のパスの一覧ではありません。受け取り側はリール番号、シーン番号、テイク番号を見られても、納品物ファイルからローカルファイルの物理的な位置を直接得ることはできません。ショット番号は CSV と PDF でだけ独立の列になっていて、ALE にこの列はありません。
ファイル名が元のパスの身代わりにならないのはなぜか
メディアをディスクに落とす前、ファイル名はまず正規化されます。不正な文字はアンダースコアに置換われ、制御文字は削除され、長すぎる名前は切り詰められます。正規化のあとに使える内容が残らなければ、英語の定数のプレースホルダ名に落ちます。つまり、ディスク上のファイル名はすでに外部の由来の名前と違っている可能性があります。
写真は 2 通りに処理されます。現場での撮影とクイックショットで得た写真は再エンコードされ、ライブラリから選んだ写真とファイルから取り込んだ写真はバイトのまま格納されます。どちらも元のパスは伴いません。したがって、受け取り側が偶然に似たファイル名を手にしても、それを「元の名前＋元のバイト」の証明として扱うことはできません。納品物の中のあの 1 マスのファイル名は、リール番号とクリップ番号から組み立てたもので、ディスク上にある名前ではありません。パスの扱い、ファイル名の正規化、メディアのバイトの処理はローカルの保存層の事実で、納品物の中のメディアのパス列にはなりません。
「納品物からパスが読めない」が説明しているのはエクスポート結果の境界で、素材がローカルのプロジェクトライブラリに存在するかどうかを判断したものではありません。
これが素材の再接続を直接制限するのはなぜか
納品物の中にメディアのパスがなければ、受け取り側は 1 行の記録からあるローカルファイルの位置へ直接飛ぶ物理的なポインターを欠きます。リール番号、シーン番号、テイク番号といったフィールドは引き続き身元の対応関係を作るのに使えますが、あれらは識別子であってパスではありません。受け取り側は、その識別子を受け取ったメディアのリスト、ファイル名、ディレクトリの実際の状況と突き合わせる必要があります。
これこそが『ALE を受け取ったら、まずこのフィールドを照合する』が受け取り側に素材と現場の記録へ戻って照合するよう求める理由です。あるファイルが開けて、いくつかの列が読めることは、同じファイルがメディアの位置も運んでいることを意味しません。もしあるワークフローが納品物から素材を直接特定することを要求するなら、その対応関係は受け取り側が既に持っているメディア情報の側から補うしかありません。
4 種類の納品物がいずれも同じ境界に落ちるのはなぜか
ALE と CSV は機械可読のテーブル、PDF は人が読むサマリー、FDX は脚本の交換を担っています。ALE と CSV の背後にあるテイク記録のスナップショットには Source File Name のマスとソースファイルを入れるマスがあり、どちらも現場で書き取って埋めるものです。書き取れば内容が入り、書き取らなければ空になります。PDF は人が読むためだけのもの、FDX は脚本側スナップショットを使っていて、テイク記録すら載せていません。4 種類のどれにも、ソフトがディスクで見つけたパスが入ったマスはありません。フォーマットが違ってもこの境界は変わりません。あるフォーマットの列が多いからといって、プロジェクトライブラリの中のメディアの保存先までおまけで出てくると推測することはできません。
たとえば『CSV の引き渡しは ALE と比べて何を多く運び、何を運ばないか』が議論するのはフィールド集合の違いで、パスがないところから生えてくることではありません。『ALE を受け取ったら、まずこのフィールドを照合する』は、どのマスを現場で書き取らなかったために空で出るのか、その書き取られなかったマスがラップ照合表にどう現れるのかを 1 マスずつ扱っています。受け取るときは「あのマスは書き取られていない」「あのマスは書き取った文字を入れている」「メディアを本当に再接続できるポインター」の 3 つを分けて理解する必要があります。列に名前が書いてあっても、それは位置が書いてあることにはなりません。
受け取り側はどうやって素材の対応関係を作るべきか
納品物の記録とメディアを対応させる必要があるとき、受け取り側はリール番号、シーン番号、テイク番号といった目に見える識別子から出発して、自分のメディアのリストと項目ごとに照合すべきです。メディア側の命名、リール番号、ディレクトリの規則が納品物の記録と合わないなら、パスを推測するのではなく、実際の素材と現場の記録に戻って確認する必要があります。納品物自身はその直接の再接続の手がかりを提供できません。
したがって、こうした種類のファイルは記録と交換データとして理解されるべきで、メディアのリストやメディアのバックアップではありません。あれらが出すのは 1 マ스에書き取られた文字列であって、記録から受け取り側の機械の素材の位置へ至る解析可能なポインターではなく、ある受け取り側のプロジェクトに自動的にメディアのリンクを張る約束にもなっていません。締めくくりとして、受け取り側はリール番号、シーン番号、テイク番号と自分のメディアのリストを自分で照合する必要があります。
FAQ
ALE と CSV にファイル名があるのに、なぜメディアのパスが読めないのですか？
ファイル名は記録の中の身元の手がかりで、パスはメディアの実際の保存先です。同じものではありません。ALE と CSV には Source File Name のマスとソースファイルを入れるマスがあり、値は現場で書き取ったかどうかに掛かっていて、ALE のその 2 マスは ASCII しか受け付けないため、非ラテン文字が混ざるとマス全体が空になります。PDF と FDX にはその 2 マスすらありません。書き取られたあの文字列が名前を付けているのは撮影側のファイルで、受け取り側の機械のディレクトリにはつながりません。だからあの値が出てくることで、再接続できる位置が補われることはありません。
写真を取り込んだあと、外部ファイルのままのバイトですか？
限りません。現場での撮影とクイックショットで得た写真は再エンコードされ、ライブラリから選んだ写真とファイルから取り込んだ写真はバイトのまま格納されます。どちらも元のパスは伴いません。
CSV はフィールドが多いのでメディアのパスを運ぶのですか？
列数が多いからといって、ソフトが見つけたパスの列が増えることはありません。CSV のあの 2 マスは現場で入力した文字で、ALE の同じ名前の 2 マスは ASCII しか受け付けず、PDF と FDX にはあの 2 マスがそもそもありません。
素材を再接続するとき、何を根拠にしますか？
受け取り側は、リール番号、シーン番号、テイク番号といった目に見える識別子で、自分のメディアのリストおよび実際のファイルと照合する必要があります。納品物の中身からローカルの完全なパスを推測してはなりません。
Axiom One LLC — SlateX。上の数字は 2026-09-24 時点のものです。