txt:高信行秀 構成:編集

前回の「クリップの整理」に続いて、今回はさらに地味な「データ管理」について説明していく。ここでの「データ」とは映像/静止画/オーディオなどの素材や、レンダリング/キャッシュなどの編集作業に伴うデータに関してだ。FCPXでのデータ管理に関しては、これまでのNLEと異なるように見えるために誤解を招き、敬遠される要素となったが、実際は難しいことはない。実際にFCPX内でのデータ管理の内容を見ていき、結果的に効率のよいデータ管理について考えてみよう。

データの種類

まず、データ管理に関して説明をする前に認識を整理しよう。データには次のものがある。

  • オリジナルメディア(映像や静止画、オーディオのデータなど)
  • レンダーファイル(レンダリングされたファイル/キャッシュ/サムネイル)
  • トランスコードメディア(最適化されたメディア/プロキシ)
  • アナライズファイル(人物検出/カラーバランス/手ブレなどの解析情報)
  • Motionコンテンツ(Motionで作成されたタイトル/エフェクト/トランジションなど)

これらのものに分類される。それぞれの内容は次の通りになる。

■オリジナルメディア

「オリジナル」の名前の通り映像や静止画、オーディオなどの元素材のデータ。オリジナルメディアは、元のデータからコピーして管理することができるほか、リンク(エイリアス)だけを貼りデータ量を少なく管理することもできる。コピーかリンクかは読み込みの際に設定できる。

読み込み時の設定

カメラなどで撮影されたメディア(SD/PD/P2/CFastなど)からの読み込みは自動的にコピー処理となる。ユニークな機能として上記のメディアからの映像ファイルの読み込みの時に限り、全体を取り込むだけでなく部分的に取り込むことができる。これによりデータ量を節約することができる。

■トランスコードメディア

オリジナルメディアから変換された「最適化されたメディア」や「プロキシ」データ。読み込み時の設定や「メディアをトランスコード」コマンドを使用することで作成される。目的のフッテージがトランスコードされているかはインスペクタの「情報」から知ることができる。

「最適化されたメディア」はデコードの負荷の高いメディアを、デコードの負荷が低く画質に優れたProRes 422(REDなどのハイクオリティな素材はProRes 4444)に変換し、編集の快適さを狙ったものである。

「プロキシ」はProRes 422 Proxyに変換し、さらに解像度を1/2にすることでオフライン編集での快適性を狙ったものである。

最適化されたメディアとプロキシ

■レンダーファイル

エフェクトやトランジションなどの負荷がかかる部分をレンダリング処理することで作成されるデータ。その他にもサムネイルやオーディオの波形情報も含まれる。

作成されたレンダーファイルを削除するには「生成されたXXXXXファイルを削除」コマンドを使用することで削除できる。このコマンドは、プロジェクト/イベント/ライブラリのいずれかを選択しているかによって、対象範囲とコマンド名が変わる。コマンドを使うことで無駄に蓄積したレンダリングファイルを削除できる。

作成されたファイルの削除

■アナライズファイル

アナライズファイルには「解析と修復」で生成される、人物検索/バランスカラー/スタビライズの解析データが含まれる。

■「Motionコンテンツ」データ

「Motionコンテンツ」データはMoitonで作成されたタイトルやトランジション、エフェクトのファイルを読み込んだもの。デフォルトの設定では共用できる「Motionコンテンツ」フォルダ(/ユーザ/Movie/Motion Templates)にまとめられる。この場合、これらのデータは共用データとなり移動できないため、ライブラリだけを別システムに移動した場合は先のMotionコンテンツの内容は再現されない。

「Motionコンテンツ」の保存場所をライブラリにすることで、ライブラリを渡せばMotionによる内容も同時に渡すことができるようになる。

「Motionコンテンツ」

バックアップ

バックアップは、所定の場所にライブラリを複製して保存したものだ。ただし、保存されたものはメディア(オリジナル/最適化/プロキシ)やレンダリングデータを含んでいない軽量化されたものだ。

バックアップ

以上の種類のデータが編集時に利用される。そして、これらをまとめているものが「ライブラリ」だ。次にライブラリについて見ていこう。

ライブラリを知る

FCPXのGUI上では、編集で使用するデータは「ライブラリ」を基に、イベント>プロジェクト/メディアの順で管理される。そして実際のデータでも、基本的に「ライブラリ」内にまとめることになっている。

FCPXのGUI上でのライブラリ

「ライブラリ」は、Finderからは1つのファイルにまとまって見えるが、実際はパッケージ形式と呼ばれるフォルダであり、その中にライブラリを構成するファイルやフォルダを収めている。

ライブラリはパッケージ形式のフォルダ

■ライブラリ内の構造

「ライブラリ」パッケージ内の構造を見てみると、FCPX上のライブラリ内で作成されたイベントと同じ名前がついたフォルダがある。その中にはイベントを構成するデータが収まっている。

その内容を見て気づくことがあるだろう。そう、先に説明した種類のデータがパッケージ内にまとめられていることがわかる。これに、オリジナルメディアやMotionコンテンツをライブラリ内で管理する設定であれば、編集する内容はライブラリ1つの中に全て収まることがわかる。

ライブラリの中身(主要パートのみ)

どうだろうか。内容を整理すれば難しそうなライブラリの管理もそうでないことがわかるだろう。それでは次はライブラリの枠を超えてみよう。

環境に応じたデータの管理場所の変更

ライブラリでひとまとまりにデータ管理ができれば、データの所在に戸惑うことなく使用できるが、必ずしもそれが最良の方法とは限らない。例えば、

  • サーバーなどセントラルストレージで素材を共有している
  • 長尺の編集などで大量のレンダリングファイルが想定されるのでレンダーファイルは外部ストレージを保存先としたい

といった場合だ。これらのような場合にはライブラリまるごとを外部ストレージに置くことが考えられるほか、データの種類によってライブラリ以外の場所で管理する方法も選択できる。

■データの管理する場所の設定

データの管理する場所はライブラリのインスペクタにある「ストレージの場所」で設定できる。

「ストレージの場所」設定

メディア(オリジナル/トランスコード)/Motionコンテンツ/キャッシュ(レンダーファイルを含む)/バックアップなどのデータを管理する場所を任意に設定できる。

データ管理の設定などを利用したパターン

これまでで、データの種類や配置する場所の変更方法がわかったので、シチュエーションに応じてどのように使えるか考えてみよう。

■小容量のMacBookと外部ストレージを接続している環境の場合

基本的には外部のストレージにライブラリごと保持するしかないだろう。ただし、外部ストレージは高速な環境でないと、内蔵のストレージ(多くが高速なSSDだろう)との差が激しく、ストレスに感じることだろう。

ライブラリを外部に移動するにはライブラリを手動でコピーしてライブラリをダブルクリックで起動するのみだ。

■セントラルストレージがある場合

セントラルストレージ(ファイルサーバー)などを使う場合でも、基本的にはライブラリを丸ごとを外部ストレージで管理する方法が簡単である。ただし、例えば4K素材などの大きなデータを扱う場合は、セントラルストレージからデータを参照していると帯域的に厳しいことが多く、更にスループットの制限による操作レスポンスへの影響も大きい。

セントラルストレージを利用した場合

例えばこういった場合、「メディア」の設定をクライアントの内蔵ストレージ(ライブラリ)に設定し、オリジナルメディアは「リンク」で読み込む。これでオリジナルメディアはサーバーに置きながら、作成するプロキシは内蔵に作成される。この方法を使えば、プロキシでの内容だがセンターストレージに負担をかけずに個々で編集ができる。

更に端末がMacBookなどであれば接続を切って持ち出しても、「内蔵に持つプロキシファイルで編集もできる」(※ただし、残念ながら静止画とオーディオはプロキシが作成されないためオリジナルメディアでの管理が必要)。もちろん、フィニッシング時にはセントラルストレージ内のオリジナルメディアに1コマンドでスイッチして完成させることもできる。

■編集内容を外部と受け渡しする場合

外部に編集データを渡す際は、データはライブラリにまとめてライブラリごと渡すことが確実だろう。Motionデータに関しては先に説明した通り管理先をライブラリに設定し、オリジナルメディアは取り込み時にライブラリへコピーする設定にする。

ただ、必ずしも作業しているライブラリが作業開始時からそのような設定になっているとは限らない。そして、途中で設定を変えても変更結果はそれ以降の内容にしか反映されない。

このような場合は「統合」コマンドを使うことで解決できる。これまでの設定での内容を、新しい設定の場所へまとめる(移動またはコピー)ことができる。ポイントとしては「統合」コマンドを使うとリンク状態のオリジナルメディアは元のデータをコピーしたものに置き換えられる。

「統合」コマンド

ストレージの容量を節約して使う

「FCPXを使用していたらいつの間にかストレージが一杯になっていた」という話を聞くことがある。実際、起こる可能が高いのは事実だ。これに関しては、その多くがレンダリングファイルの問題と、設定による影響がある。ここではその原因と対策について見ていこう。

■レンダリングの問題

FCPXの傾向として過去に作成したレンダリングファイルを消さないように見える。これによるメリットは、過去のバックアップから復元した場合でも当時のレンダリング結果を含めてすぐに再開できる可能性があるという点だ。デメリットはもちろん、際限なくストレージ空き容量を食いつぶすことだ。

これを解決するには先に書いた通り「生成されたXXXXXファイルを削除」コマンドを使用することで対応できる。ただし残念なのは現在の状態のレンダリングデータも削除されることだ。

■バックグラウンドレンダリングを使わない

バックグラウンドレンダリングは操作していない時間をつかって自動的にレンダリング処理をする機能で効率よく作業ができる。一方で先に書いた通りレンダリングデータは蓄積していく一方となる。

そこで手動でのレンダリング操作することでストレージの無駄使いを防げる。幸いにも最近のMacを使用しての編集において、高負荷なエフェクトを使わない限りレンダリングをしなくも編集作業に支障がない場合が多い。

バックグラウンドレンダリングをオフ

そこで、デフォルトでオンになっているバックグラウンドレンダリングをオフにすることを検討したい。これにより意図しないストレージスペースの圧迫を防げる。

■最適化されたメディアをつくらない

30Pを超える4K XAVCやRED RAWを使用する場合など、デコード処理の負荷が高い場合は「最適化されたメディア」は有効である。ただ近年のMacとFCPXのバージョンであればQuick Sync Videoなどの支援もあり、HDフォーマットであれば最適化されたメディアは必要ない場合がほとんどだ。

「最適化されたメディア」を作成するとフォーマットによってはデータ量がオリジナルの5倍以上に膨れ上がる。これは空き容量の圧迫はもちろん、データスループットにも影響を与えることとなり、結果的に編集パフォーマンスを落とすこともある。

「最適化されたメディア」を作らないことも検討したい。

■プロジェクトのレンダリングコーデックを変更する

プロジェクトごとに設定できることだが、レンダリングする際のコーデックはデフォルトでは「ProRes 422」になっている。これを「ProRes 422 LT」に変更することも検討したい。

プロジェクトのレンダリングコーデックを変更

ご存じの通り、「ProRes 422 LT」コーデックは品質グレードでは「ProRes 422」コーデックより1つ下位のものだ。ただし品質は十分で、用途にもよるがブロードキャストでも多用されているコーデックだ。そのバランスの良さから特に最近見直されている。

「ProRes 422 LT」を使用することでデフォルトの設定「ProRes 422」に比べて約70%のサイズで済む。さらにデコード処理は1.2倍の速度になり処理も高速化される。

■映像をすべて取り込まない

FCPXで意外と知られていない機能として、カメラなどのメディアからの読み込みの際にフッテージ中の一部分だけを取り込むことができる。

部分的な読み込み

例えば1時間の連続した撮影素材の中から必要な10分だけを取り込むなんてことができる。この機能は多くのカメラ/収録メディアで対応している。これにより不必要な内容のために容量を消費することを防げる。

■ライブラリを小分けにする

これはまだライブラリの概念を理解できていない場合によく見られる傾向でもあるが、FCPXを最初に起動した際に作成されたライブラリだけをそのまま継続して使用している様子を見ることがある。これはこれで使用できるのだが、できればこまめにライブラリを分けて作業をすることを勧める。

ライブラリは用途ごとにわける

ライブラリを分けて管理することで、例えばしばらく使用しないライブラリは閉じて、別のストレージにコピーして退避しやすくなる。また、ライブラリ内の項目が多いとFCPXの起動やライブラリを開く際に時間がかかるようになるので、それらも回避できる。

まとめ

データ管理について、いかがだっただろうか。FCPXは特に意識しなくても使用でき、デフォルトの設定に任せてしまいがちだが、設定することで利便性が高まることもある。今回の内容で皆さんの編集環境が少しでも快適になれば幸いだ。

FCPXが出た当初は「ライブラリ」という概念が、FCP7と大きく異なり敬遠されることもあった。さらに今回紹介したライブラリ以外の場所でのデータ管理が、初期のバージョンではできなかったので尚更だ。また当時のストレージ事情(サイズ/スピード)も影響もあっただろう。

しかし、現在の状況においてはいずれも解決されていることだ。もし初期の情報を元に評価されているのであれば、是非もう一度確認してみてほしい。

次がやってくる?

この11月16日~18日(現地日時)にクパティーノのホテルで「FCPX Creative Summit」が開催される。昨年の同会では初日にApple社のAppleParkへの訪問が行われ、その際にFCPX10.4とiMac Proの先行プレビューがされた。そして、今年も同じようにApple社への訪問がスケジューリングされている。いろいろ期待したい。

WRITER PROFILE

高信行秀

ターミガンデザインズ代表。トレーニングや技術解説、マニュアルなどのドキュメント作成など、テクニカルに関しての裏方を務める。