書き出した FDX から戻ってこないものは何か

SlateX が書き出した FDX をこの App に再び読み込ませても、元のプロジェクトをそのまま積み直すことにはなりません。ファイル単位ではプロジェクト名を書き、シーン単位ではシーン番号、内/外、シーン名、時間帯、八分の一、改稿カラー、省略の状態、ページ番号、脚本項目を中心に取り交わします。この書き出し範囲に入っていない App データは、このファイルでは戻ってきません。それ以上に重要なのは、書き出し範囲に属する値でも、ファイルを書き出して再び読み込むたびに、決まった挙動どおりの書き換えを受けるという点です。

FDX で戻ってこられる上限は、まず書き出し範囲が決めます。範囲内の値であっても、一文字違わず元の形に戻ることを意味しません。

書き出した範囲がそのまま戻ってこられる上限になる

ファイル単位とシーン単位を合わせると、エクスポートでは、プロジェクト名を保ち、さらにシーン番号、内/外、シーン名、時間帯、八分の一、改稿カラー、省略の状態、ページ番号、脚本項目という 1 組の情報を保ちます。ショット、テイク記録、カメラ、タイムコード（音声タイムコード Sound TC を含む）、メディアパスなどはこの FDX の書き出し構造に入っていないため、このファイルからそれらの現場記録を復元することはできません。

ここが『FDX は何を交換し、何を運ばないか』と本稿の役割分担です。親篇は交換範囲を説明し、本稿は同じ 1 つの脚本交換ファイルが出てから戻るだけを見て、範囲内の内容がどう変化するのか、どの内容には戻りの担い手自体がないのかを扱います。

往復で区別すべき、シーンタイトルと概要の 3 つの挙動

ひとつはシーンタイトルの重ね書きです。FDX から読み込んだシーンでは、シーン名に元のタイトルがまるごと残され、それとは別に内/外と時間帯が各自 1 つずつ保存されています。もう一度エクスポートするとき、「内/外の接頭辞 + 元のタイトルまるごと + 区切り文字 + 元の時間帯」でシーンタイトルが組み立て直されるため、タイトルと時間帯のテキストがもう一遍重ねられます。App 内で手作業により新規作成したシーンはこの点で挙動が違い、3 つの部分はもともと別々に保存されているので、同じ重ね書きの出所が発生しません。

もうひとつはピリオドです。読み込み時は INT. のような接頭辞がそのまま保持され、エクスポート時は末尾にピリオドがなければ 1 つ補うだけなので、往復しても INT.. のようなピリオド 2 つは現れません。重複するのはシーンタイトルの中のタイトルと時間帯の情報です。ここで言っているのは両側の規則を合わせた結果であって、第三者のソフトウェアの挙動の推測ではありません。

3 つめは概要の置換です。読み込み時、メモ・概要類の内容がシーン概要に入ることがあり、そうした書き込み待ちの概要がないときは、先頭の動作または一般の段落が概要として使われることもあります。そのため概要に入るのは動作描写の全文であって、あらすじではありません。エクスポートではシーン概要を対応する属性へ書き戻さないため、再度読み込むと、この位置は再び先頭の動作または一般の段落に置換され得ます。

戻る経路の変化がほかにも 3 種類あり、分けて見る必要がある

シーンの八分の一が 0 のとき、エクスポートでは長さ属性そのものを書きません。読み戻すときには長さがないものは 1/8 ページとして扱われるため、「0 または空」は 1/8 ページになります。再び読み込んだシーンの状態は「未撮影」として書かれ、FDX から元の撮影状態を復元することはできません。メモ・概要類の段落は脚本項目として元の位置に戻らず、脚本項目の順序も番号の採り直しになります。

これらの変化はファイルが壊れているという話ではなく、「このフォーマットが何を書くか」と「読み戻し時にどうオブジェクトを作るか」が同じ話ではないということです。『納品物の欠値を読み分ける：空欄にはいくつかの形がある』は空文字列、属性の欠落、プレースホルダなどの形を区別する助けになりますが、ここでは引き続き FDX の往復だけを論じています。

硬い境界：挙動は説明できるが、四つの点はやはり実際のファイルに落とす必要がある

シーンタイトルの重ね書き、概要の置換、八分の一が 0 のときに長さ属性を省き読み戻しで 1/8 ページに補うこと、再読み込み後の状態が「未撮影」と書かれること、そしてメモ・概要類の段落が元の脚本項目の位置に戻らず脚本項目の順序も振り直されることは、いずれもこの App がファイルを書き出して再び読み込む際に観察できる挙動です。本稿で踏み込めない問いは、次の四つです。

ある実在の FDX がさらにどのフィールドを失うか。 読み込みは上記の五つの属性だけを取ります。あるファイルが実際に何を失うかを挙げるには、そのファイルと項目ごとに突き合わせる必要があります。

重複除去の規則が実際にどのシーンを除くか。 実際に除かれるシーンの集合は入力ファイルによって変わるため、元のファイルと読み込み結果を照合してください。

第三者の脚本ソフトとの実際の相互運用結果。 本稿は無損失の往復を約束するものではありません。第三者ソフトで「開く、名前を付けて保存、再び読み込む」を行った結果は、実際にそのファイルで一走した結果を基準にしてください。

これらの決まった書き換えが、ある往復でどの程度起きるか。 これらの書き換えは確かに起きます。あるファイルのタイトル、概要、長さが具体的にどれだけ変わったかは、実際の書き出しファイルと読み戻し結果を比べる必要があります。

したがって対外的な境界はこうです。往復は逐字の保存を保証しません。確定した挙動を「どのファイルでも同じ程度に変わる」という主張に広げることはできず、第三者ソフトの実際の結果を確認済みとして書くこともできません。受け取り側は、実際の交換ファイルと、読み戻し後のシーンタイトル、長さ、概要、状態を照合してください。

往復は逐字の保存を保証しません。これらの書き換えは確かに起きますが、個々のファイルが実際にどれだけ変わるかはやはりそのつど確かめる必要があります。

FAQ

FDX はショットとテイク記録も一緒に戻してくれますか？

現在の書き出し構造からそれらの現場オブジェクトは得られません。この FDX の交換範囲に入っていないため、ファイルを再び読み込んでも何もないところから再作成はされません。

シーンタイトルに接頭辞と時間帯がもう 1 層増えるのはなぜですか？

FDX から読み込んだシーンは元のタイトルまるごと、内/外、時間帯を同時に保持していて、再エクスポートのときにこの 3 つをもう一度結合します。手作業で作ったシーンはこの点で挙動が違い、3 つの部分はもともと別々に保存されているためです。

概要が動作描写になってしまうのはなぜですか？

書き込み待ちのメモや概要がないとき、先頭の動作または一般の段落が概要として使われることがあり、しかも概要には対応する書き戻し経路がありません。そのため再読み込みのときにこの位置は動作描写の全文に置換され得ます。

これらの結論は第三者の脚本ソフトで往復が通ったことを意味しますか？

意味しません。本稿は第三者の脚本ソフトでの「開く、名前を付けて保存、再び読み込む」の実際の結果を保証していないため、受け取り側は自分の手にしたファイルを照合する必要があります。対外的な境界は引き続き「往復は逐字の保存を保証しない」です。

Axiom One LLC — SlateX