引き渡しと交換 / X8 · 突き合わせの仕組み

同じ一連のテイク記録が複数の納品物で行番号が互いに対応しない理由

同じ一批のテイク記録が複数の納品物で行番号が互いに対応しないのは、あれらが別のプロジェクトからデータを取っているからではありません。それぞれの生成物が自分独自のソートルールで出力するからです。表形式の生成物は作成日時順を保ち、構造化リストはシーン・ショット・テイクで並び直し、人が読む日報はもう 1 系統のショットキーを使います。3 つはいまはどれもカメラごとに展開するので、1 回の書き出しで出る行数は同じ粒度です。違うのは行の順序だけです。

ファイルをまたいで突き合わせるとき、安定した共通キーはシーン・ショット・テイクの身元で、「何行目」ではありません。

出発点は同じで、その後の並びの規則が違う

表形式の生成物は、記録が作られた順をほぼそのまま保ちます。構造化リストは同じ記録をシーン番号、ショットの採番、テイク番号で並び直し、うちシーン番号とショットは自然順で比較します。テイク記録自体は同じですが、行の位置はもう共有されません。

人が読む日報はもう 1 系統の並びを追加します。シーン番号のあと、ショットの修飾名を 2 番目のキーにし、さらにテイク番号で並べます。この修飾名は構造化リストが使う元のショットの採番と等しくないため、2 枚のファイルが同じ一批のテイクを含んでいても、「2 行目同士が対応すべき」という関係は成立しません。

インターフェースのログにはさらに別の順序があります。ショット番号の文字列の昇順、そのあとにテイク番号の昇順です。文字列順では 10 が 2 より前に並びます。これはインターフェース層自身の表示順序で、そこから書き出しファイルの中の位置を逆推することもできません。

行番号が対応しない核心は、それぞれが別の並びキーを使うことにあります

3 つともカメラごとに展開します。1 本のテイクに複数のカメラが含まれていれば、それぞれが複数の行を生成し、カメラがなくても 1 行はそのまま残ります。ですから 1 回の書き出しで出た 3 枚のファイルは、行数の実のところ同じ粒度です。違いは、同じこれらの行がそれぞれのキーで別の順序に並べられていることだけです。

これは、行番号がなぜ互いに対応しないのかも説明します。CSV は記録を作った順をほぼ保ち、ALE はシーン番号・ショット番号・テイク番号で並び直し、日報はシーン番号・ショットの修飾名・テイク番号で並びます。日報で連番らしく見えるあの 1 マスの No. も、実際はドキュメント全体の行番号であってテイクの採番ではないので、ファイルをまたぐ突き合わせのキーにすることはできません。

行番号が対応しないのは、それぞれの並びキーが違うことから来ます。ある 1 枚が「撮影を 1 本多く持った」「撮影を 1 本落とした」こととは違います。

ショットの識別子は生成物ごとに同じ文字列とは限らない

人が読む日報はショットの修飾名を使い、表形式の生成物のショットの列は元のショットの採番を使います。1 つのショットは、インターフェースまたはあるファイルではシーン番号の接頭辞付きや修飾された形を帯び、別のファイルではより短い採番だけ残ることがあります。受け取り側は、あれらをシーン・ショット・テイクの関係へ戻して理解すべきで、ある列の文字列が一致するかどうかだけで同じ 1 本かを判断しないでください。

ここで説明しているのは、こちら側の生成物の仕組みです。現在の証拠から、ある下流のソフトウェアがこれによって必ず誤ったマッチング・取りこぼし・インポート拒否をするとさらに主張することはできません。具体的な受け入れの挙動は、引き続き受け取り側が自分のインポート用テンプレートで列ごとに照合します。

突き合わせるときは何を使うべきか

ファイルをまたいで照合するときは、まずシーン番号を固定し、次にショットを固定し、そのあとテイク番号を見ます。マルチカメラの記録ではさらにカメラまで追います。この目的は、身元の関係を共通言語にすることであって、あるファイルに偶然現れた行の位置を主キーとして扱うのではありません。

1 回の書き出しで出た 3 枚は、いまでは行数の粒度が同じです。順序が違うなら、それぞれがどの並びキーを使ったかを見ます。範囲をまたいだ比較は成り立ちません。日報が出るのは撮影日範囲のときだけで、プロジェクト全体範囲では ALE と CSV のみになります。身元の関係そのものが合わない場合に限って、元の記録へ戻って確認するのであって、複数の生成物に行単位の揃いを先に要求するのは違います。受け取り側の手順でこの納品物を引き続き使えるか判断する必要があれば、『受け取り側は現場の納品物を使い続けられるとどう判断するか』の対照順で別途ご確認ください。

これらの差異は生成の仕組みの結果ですが、「仕組みがそう」は照合を忽略してよいこととも等しくありません。各生成物は別の責務を担っていて、受け取り側は、自分が使うフィールドが本当に同じ 1 件の現場の記録へ戻れるかを引き続き確認する必要があります。

FAQ

表形式の生成物と構造化リストで順序が違うのはなぜですか?

表形式の生成物は作成日時順を保つのに対し、構造化リストはシーン・ショット・テイクで並び直すためです。両者は同じ一批のテイク記録から出発しますが、その後の並びの規則が違います。

1 回の書き出しで出た数枚の総行数は同じですか?

同じです。3 つともカメラ 1 台ごとに行を書き、1 本のマルチカメラのテイクは 3 つのいずれでも同じ数の行を占めます。違うのは順序だけです。プロジェクト全体の書き出しでは日報は生成されないので、その範囲をまたいで行数を比べること自体が成り立ちません。

日報の No. を別のファイルの行番号と対応付けられますか?

対応付けません。日報の No. はドキュメント全体の行番号で、テイクの採番とは同じ概念ではないため、ファイルをまたぐ身元のキーにはできません。

数枚のファイルは何を共通キーにして照合すべきですか?

シーン・ショット・テイクの身元を優先し、マルチカメラの記録ではカメラまで続けて照合します。行番号やある 1 枚の並びの位置を共通キーとして扱うのは違います。


Axiom One LLC — SlateX