EDL・AAF・XMEMLの違い|編集データの受け渡しで壊れない形式

別の編集室で開いたら、テロップだけが消えていました。カットの順番も尺も合っている。音も出ている。ただ画面から文字が全部いなくなっていて、そこだけ素材のままの映像が流れます。

渡したのはEDL。書き出したときにエラーは出ませんでした。運べないものを黙って落としただけです。

編集データの受け渡しは、ファイルが開けたかどうかでは判断できません。何が運ばれて何が運ばれないかを、形式ごとに分けて把握しておく必要があります。

3つの形式は、生まれた目的が違う

EDLはリニア編集の時代からある形式です。テープのどこからどこまでを、完成尺のどこへ置くか。それを1行ずつテキストで並べただけのもので、中身をテキストエディタで読めます。いくつかの方言がありますが、実務で見かけるのはCMX3600と呼ばれる系統がほとんどです。

AAFはAdvanced Authoring Formatの略で、複数のソフトのあいだで編集情報を交換するために作られました。策定はAAF Association、現在のAdvanced Media Workflow Associationで、オブジェクトモデルはSMPTEでの標準化も進んでいます。映像だけでなく音声のトラックや処理も運べる設計で、素材そのものを内部に抱え込むこともできます。バイナリ形式なので、目で読むことはできません。

この設計思想は名前の似た規格と対にすると分かりやすくなります。MXFはAAFのデータモデルのサブタイプとして作られていて、両者を混ぜた工程が成り立つように設計されています。違いは想定している段階です。AAFは制作の途中にあるもの、MXFは完成した映像を交換するためのもの。同じ系統から、作業中と完成品で役割を分けて生えています。

XMEMLはFinal Cut Pro 7のプロジェクト記述形式で、XMLで書かれています。そこから他のソフトへ読み込ませる経路として使われるようになりました。元になったソフト自体はすでに現役ではありませんが、形式のほうは受け渡しの経路として残っています。

つまり3つは、代替品として並んでいるのではありません。運べる情報の幅が違い、テキストで読めるかどうかも違います。用途が重なる部分があるだけです。

早見表

読める形式は壊れたときに追えます。EDLは行の並びを目で確認できるので、どこで尺が合わなくなったかを特定するのが速い。ただし運べる情報は最も少ない。

この「読めるが運べない」と「運べるが読めない」の対立が、選定の軸になります。

何が壊れるのかは、だいたい決まっている

受け渡しで消えるものには傾向があります。

まずエフェクトです。ソフト固有の処理は、そのソフトの外では意味を持ちません。名前だけが残って中身が空になるか、まるごと落ちるかのどちらかになります。

次にテロップです。編集ソフトの中でテロップは映像素材ではなく、そのソフトのタイトル機能が生成した表示です。形式が運ぶのは「ここにタイトルがある」という記述までで、書体も位置も相手側の解釈になります。XMEMLで字幕を渡す仕組みがテキストとして成立するのは、この記述の部分を使っているからです。

音声のフェードやレベルも落ちどころです。EDLは音声トラックの扱いが弱く、ミックスの情報を運べません。MAへ渡すときにAAFが選ばれるのは、ここが理由です。素材と処理をまとめて持っていける形式でないと、音の作業をやり直すことになります。

素材を内部に抱えるか、外部のファイルを参照するかも選べます。抱え込めばファイルは重くなりますが、渡した先で素材が見つからない事故は起きません。参照にすれば軽い代わりに、パスの解決が相手の環境任せになります。ここは相手のストレージ構成を聞いてから決める部分です。

そして冒頭のテロップ消失は、EDLの仕様どおりの動作でした。運べないものを渡そうとしたほうに原因があります。

近年はOTIOという選択肢もある

OpenTimelineIOは、編集のタイムラインを記述するために設計されたオープンソースの形式です。特定のソフトの都合ではなく、タイムラインという構造そのものを表現することを目的にしています。

制作パイプラインを自前で組んでいる現場では、変換のハブとして使われることがあります。ソフトAからソフトBへ直接渡す経路を全部用意する代わりに、いったんこの形式へ落とす。

ただ、放送の制作現場でこれが標準になっているとは言えません。既存の3形式に対応した機材と工程がすでにあり、そちらを置き換える理由が小さいからです。選択肢として頭に入れておく程度で足ります。

完全に運ぶことは、どの形式でもできない

ここまで見ると、AAFがいちばん多く運べるように読めます。実際そうなのですが、それでも完全ではありません。

そもそも編集ソフトごとに、内部で持っている情報の構造が違います。ある機能を持たないソフトへ渡すとき、対応する表現がない。落とす以外にできることがありません。

だから受け渡しの設計は、何を運ぶかではなく何を運ばないと決めるかになります。テロップは相手側で入れ直す。音のミックスはこちらで確定させてから渡す。エフェクトは適用済みの映像として書き出す。どれも手間ですが、事故は起きません。

完パケまでの工程で、どの段階のデータをどの形式で渡すかは、この判断の積み重ねで決まっています。素材側がMXFで届いている場合は、参照している素材のパスが相手の環境で解決できるかまで含めて確認が要ります。

渡す前に、開ける環境で開いてみる

形式の選定はここまでで済みます。残るのは確認の手順です。

書き出したファイルを、渡す相手と同じ構成で一度開く。これができれば、何が落ちたかは目で分かります。できない場合は、落ちる可能性のあるものを先に列挙して、相手と共有しておく。

面倒に見えますが、テロップが消えた状態で先に進んだときの手戻りと比べれば軽い作業です。実際、事故が起きるのはたいてい「前回と同じだから」で確認を飛ばしたときでした。

では、その確認を毎回やる余裕はあるのでしょうか。受け渡しの回数が増えるほど、この工程をどこまで自動で回せるかが効いてきます。

NAXAの取り組み

NAXAは放送局・制作会社向けにシステム開発を手がけており、字幕や編集データを既存の編集環境へ渡す仕組みも扱っています。Subtitle Generatorでは、編集ソフトのタイムラインで人が直せる形での受け渡しを前提に設計しています。