受け取り側は現場の納品物を使い続けられるとどう判断するか
現場の納品物をそのまま使えるかどうかを判断するのは、「ファイルが開けるか」から始めるべきではありません。次の 3層の順序で照合します。まず素材へ対応付けられるか、次にシーン・ショット・テイクへ対応付けられるか、最後に現場の判断が本当にこの生成物まで書き込まれているかです。SlateX が渡せるのは、各生成物に実際に書き込まれた文字どおりの値と、その由来の関係までです。下流の流れへ入れるに足るか否かは、引き続き受け取り側が自分のインポート用テンプレートと素材の状況で判断します。
検収とは、ファイルに「合格」の印を押すことではなく、「身元が不明、関係が合わない、判断を追跡できない」という 3種類のリスクを順番に除外していくことです。
まず問う：この行は本当に素材へ対応付けられるか
最初に素材の身元と時間上の位置を見ます。リール番号、クリップ名、カメラ、入り点、終り点、長さ、フレームレートは、素材または現場の記録へ戻って出所を確認する必要があります。あるフィールドは人の入力から、あるフィールドはソフトウェアの派生から来ています。あるフィールドは値が欠けているときに空のセルで渡され、欠値の代わりにフォールバックの文字列が書き込まれることはありません。受け取り側は、今見ている値がどれなのかを先に知ったうえで、その値をマッチングの根拠に担わせられるかを決めます。
ここで構文的に正しいことを事実として正しいものと取り違えません。形の正しいタイムコードの文字列でも、それがどこへ書き込まれたのかまでたどる必要があります。終り点は、停止を告げたあの瞬間に読まれた読み取り値です。収録チェーンが止まる瞬間に機械がその場で読み取るか、スクリプターが機械の画面を見ながら手で書き取るか、どちらか一方です。読まれればセルに値があり、読まれなければ空のままです。ソフトウェアが入り点に長さを足してそれを作り出すことはありません。個々の受け入れソフトがこれらの列をどう解釈するかまでは、現在の証拠では次の 1文の境界しか支えられません。受け取り側は自分のインポート用テンプレートで列ごとに照合します。
この段階で素材の身元または時間の出所がそもそもたどれないなら、後続の並び順やテイク評価を論じる必要はありません。出所のはっきりしない値へ受け入れ側で新しい説明を足し続けるより、まず元の記録へ戻って確認するほうが確実です。
2番目の問い：シーン・ショット・テイクへ対応付けられるか
素材を識別できるようになったら、次に同じ 1件の記録がシーン・ショット・テイクの関係に沿って現場の記録へ戻せるかを確認します。これらの生成物は同じ表の別の見た目ではないため、ある 1枚のファイルの行番号を別のファイルの位置キーとしてそのまま使うことはできません。
抜き取り検査では、シーンごとに一部のテイク記録を選び、身元が整いカメラがはっきりしている記録から始めて、複数のカメラや欠値のある場合までカバーします。このやり方の目的は、固定の抜き取り比率を出すことではなく、1枚の全行を人の手で見る人手コストを避けつつ、ある生成物から別の生成物へ主要な関係がたどれるかを確認することです。
この層で知っておく必要がある事実は「同じ一回の書き出しで出た複数の納品物は行数の粒度が同じで、順序はそれぞれ自分のキーで並ぶ」だけであって、個々の並び順の規則まではここで展開しません。実際に突き合わせで使うのはシーン・ショット・テイクの身元で、行番号ではありません。並び順の差異の仕組みは、別の篇で専ら説明しています。
3番目の問い：現場の判断はこの生成物まで出てきたか
素材にも対応付けられ、シーン・ショット・テイクにも対応付けられるようになって、はじめて現場の判断が追跡できるかを確認します。ここで特に「ファイルに列が 1本ある」と「その列が現場の判断」を分けます。
構造化リストには Rating と Circled take の2本の列があります。前者はテイク評価の文言を書き、1つもマークされなければ空の文字列を渡します。後者は現場の基準で TRUE を書き、Circle と Keep の2つの評価はいずれも Circle 印を付けたことに数えます。表形式の生成物にはこれとは別に Circle の列があり、そのテイクが Circle にマークされたときだけ TRUE を書き、その他は一律 FALSE を書きます。同じ1枚のファイルの中の Circled On Set とは答える問いが別々で、1つの読み取り値にまとめることはできません。したがって生成物から現場の判断を復元するには、自分がどの列の基準で読んでいるかを先に確認し、そのうえで、それが現場で Circle 印を付けた状況を表せるかを判断します。人が読む日報もいまはカメラ 1 台ごとに行を書き、各行にはそのカメラ自身の読み取り値だけが入ります。あの表にはカメラ番号の列がなく、列の数も機械可読の納品物より少なめです。脚本の工程ファイルは脚本の構造までしか戻らず、撮影結果・テイク記録・カメラ・タイムコードはいずれも入っていません。
同じ 1件の記録が複数の生成物に「どれも有るように見える」ことは、それらが同じ種類の判断情報を担っていることを意味しません。
各生成物はそれぞれどこまで担えるか
構造化リストはカメラごとの素材の身元・タイムコード・シーンとテイクの関係を検査するのに向いていて、テイク評価のテキストと Circle フラグの 2本の列も担っています。ただし、素材そのもの、チャンネルマップ、タイムコード以外のレンズパラメータは持ちません。表形式の生成物はさらに多くの現場フィールドとテイク評価のテキストを担いますが、派生列と現場の意味が別物であることに引き続き注意が必要です。人が読む日報は、カメラ 1 台ごとの読み取りを目で確認するのにより向いていますが、各行に入るのはそのカメラ自身の読み取り値だけで、あの表に載らなかったカメラのパラメータは ALE か CSV で見る必要があります。脚本の工程ファイルが担うのは脚本構造の交換で、撮影結果の書き戻しは担いません。
これらの差は、受け取り側が各生成物に互いにマスごとに複製させることはできないことを意味します。正しい検収の目標は、各ファイルが自分の一区間の責務を担い、主要な身元が元の記録へ戻って照合できることです。
通らないとき、どの層で止まるか
素材の身元または時間の出所が合わなければ、素材の照合という層で止めて、まず出所へ戻ります。素材は合うがシーン・ショット・テイクの関係が作れないなら、身元の関係という層で止めます。前の 2層が成立しているのに現場の判断が対象の生成物にそもそも存在しないか意味が違うなら、ファイルが表していない結論を代わりに補うことはしません。
現在の証拠では、撮影日別の集計や撮影日別の書き出しを検証済みの能力として扱うこともできません。したがってこのやり方は「ある 1日の集計ファイル」を検収の前提にしません。実際に生成される生成物と、そこに既にある文字どおりの値だけを検査します。撮影日範囲では 4 枚が出ます——日報 PDF、ALE、明細 CSV、ラップ照合 CSV。プロジェクト全体範囲では ALE と CSV のみで、脚本の工程ファイル FDX は専用の書き出し経路を 1 本作ります。
検収は最終的に受け取り側の仕事です。SlateX が渡せるのは、検証できる値・派生の関係・既知の境界までで、「検収通過」の証明ではなく、下流の結果を保証するものではありません。
複数の納品物で同じ行番号が同じ記録を指すとは限らない理由は、『同じ一連のテイク記録が複数の納品物で行番号が互いに対応しない理由』で説明しています。
FAQ
納品物を受け取るとき、まず何を照合しますか？
最初に素材の身元と時間の出所を照合します。リール番号、クリップ、カメラ、入り点、長さ、フレームレートが素材または現場の記録へ戻って確認できないなら、後続のシーン・ショット・テイクの関係もテイク評価の判断も信頼できる前提を欠きます。
なぜ複数のファイルを行番号でそのまま突き合わせられないのですか？
各納品物は自分のキーで並ぶからです。同じ一回の書き出しで出た 3 枚の納品物は行数の粒度が同じで、順序は違います。撮影日範囲の書き出しだけが日報を生成し、プロジェクト全体範囲の書き出しは日報を生成しません。受け取る際はシーン・ショット・テイクの身元を共通キーにし、あるファイルの行番号が別のファイルでも同じ記録を表すとは想定しません。
表形式の生成物の Circle を現場の Circle 印の状態として扱えますか？
そのまま等しくはできません。Circle 列はそのテイクが Circle にマークされたときだけ TRUE を書き、その他は一律 FALSE です。現場の基準で Circle 印を付けた読み取りは同じファイルの Circled On Set 列に書かれ、こちらでは Circle と Keep の2つの評価はいずれも真に数えます。尋ねるのがどの問いなのかを決めて、その列を読み、元の記録へ戻って照合します。
この流れは、ファイルが下流の検収を通ったことを証明できますか？
証明できません。これが提供するのは照合の順序と追跡の条件までで、具体的なインポートの挙動と下流への影響は、引き続き受け取り側が自分の環境で検証する必要があります。
Axiom One LLC — SlateX