Tech:edius

出典: Tariki

目次 1 EDIUS関連によるハイビジョンの編集 1.1 friio録画物の編集 1.1.1 EDIUSでも音声がずれる!! 1.1.1.1 (1) NHKソース(途中CMカットなし)でドロップアウトがない場合 1.1.1.2 (2) NHKでドロップアウトがあったり、TV東京でドロップアウト・CMがある 1.2 EDIUS Pro 5 + FIRECODER Blu + FIREWRITERでMPEG2-TSの再エンコード 1.2.1 FIREWRITERを使ったfriio録画物の編集手順 1.2.2 エンコード速度と画質 1.3 EDIUS Pro 5 + FIRECODER Blu でMPEG2-TSの再エンコード 1.4 夜中にまとめてエンコード 1.5 二ヶ国語ステレオのエンコード 1.6 5.1chのエンコード

EDIUS関連によるハイビジョンの編集

EDIUSはThomson Canopusのビデオ編集環境である。いままでSD時代はカメラ撮りはAdobe Premiereシリーズで編集していたことが多かったのだが、このたびfriioを導入してEDIUSで編集することが多くなった。これにはEDUIS Proが便利だ。

実はSD (DV) 時代のはしりには、PCでビデオを編集するというとハードウェアエンコーダやDV取り込みボードが必要で、仕事でCanopus製品を多用していた。ただし付属していたCanopus製ソフトには目もくれず、Premiere (当時ElementsとかCSという区別はなかった) で編集しまくっていた。ごめんね。

だからEDIUSの以前のバージョンからどうなったのかはよくわからないが、Adobe Premiereなどパパママに媚びて (インスタント編集や定形外編集以外は非常に使いづらいか、できない)、一見素人向けで実は使いづらいソフトが氾濫する中、Premiere (以前のまたはCS路線) ライクというか仕事で使えるというか、そういう感覚が一番残っているソフトだと思う。もっともPremiere ElementsとEDIUS Proを比べるのはグレード違いであって、Premiere CSと、またはEDUIS NEOと比べるべきかもしれない。あいにくPremiereはCSを使っていないし、EDIUSははじめから廉価版を使っていない。

---

friio録画物の編集

EDIUS Proは、Premiere環境で落ち着いてエンコードすること1ヶ月以上経ってから知ることとなった。以前Canopusとして名をはせていたThomsonの製品である。HDVおよびAVCHDをそのまま読めて (実はfriioの吐くMPEG2 TSはBonTsDemuxなどで分離が必要だったが) H.264のフルHDサイズで書き出せるもの、ということなので、試供品を使ってみた。試供品とはいっても太っ腹にほとんどの機能がそのまま使えちゃう(30日)ものである。いろいろベンチマークをするのに不自由なく、1日使ってみただけで製品版を発注することにした。

Premiere Elementsに比べ、各種ダイアログなどはふつーにWindowsのUIで使いやすい。文字もみやすいし、なによりアプリケーションルートウィンドウに拘束されず各種ウィンドウがばらばらに配置できるのがよい。シェルからのドラッグ & ドロップも使えるので、binウィンドウは使わず、画面の1/4を空けて編集ディレクトリを覗かせておいたほうがよいくらいである。

エンコードした結果、実はこのソフトは劇速であることがわかった。H.264で圧縮しているにもかかわらず、Premiere Elementsで画質と速度の妥協点として落ち着いたWMV形式の圧縮より速い。しかも、このへんで書いているようにBD専用機などで「このビットレート以下は選んだらクソ」といわれている12Mbpsよりはるかに低くても観られる絵を吐いてくれる (リアルタイムエンコードできるしょぼいハードウェアエンコーダだと移動量検出とか量子化の最適化をさぼるため、同じ画質ならはるかに高いビットレートが必要になる)。2passを選んでいるせいかもしれないが、H.264の圧縮率のよさ (同ビットレートなら画質のよさ) を活かしている。

唯一の難点は、リップシンクがPremiereよりとりにくい点だ。カーソル線をつまんで左右させるのではなく(耳を保護してくれるためかボリュームが下がる)、ビデオ再生ウィンドウ下のコマ送りボタンをクリックしてやる (元の音量で出る) ことで解決できる。 ←リップシンクをとるときは、マウスのスクロールホイールで送り戻しするのが便利だ。カーソル線のドラッグと異なり音量が下がらず1フレームずつの音声を再生できる。 ただしカーソル線をドラッグしても正しくプレビュー表示せず、インターレースなソースのトップとボトムフレームをまとめて表示しようとするため、シーンの変わり目でちらつくようになるのはやはり観辛い。

friioで録画したMPEG2 TSをH.264にコンバートする手順は下記のようになる。EDIUSだけではできないフリーソフトを必要とする部分などはこちらのページにまとめてある。

1. mpeg2repairでログを取って必要あればTSの誤り修正 (前節と同じ)。
2. BonTsDemux (後述) で映像と音声を分離
3. Edius Pro 5を立ち上げ
4. 映像をV1A、音声を1A + 2Aに読み込み
   • ここで波形表示にしているとキャッシュ作りに時間がかかるが、波形をみてリップシンクしたり、切れ目でCM入りなどを判別するために表示させたほうがよい。
   • 新規編集開始などのときはきちんと音声のプロパティがそれぞれ左・右チャンネルのみに出力する2chステレオ、1Aと2Aのパンが左右に振られているか確認したほうがよい。
5. 頭・ケツ・CMをカットする、など編集。ドロップアウトがある場合はドロップアウト点前後でのリップシンクも合わせる。
   • 後述するようにNHK(総合・教育)・テレビ東京などでは音声がずれる。
6. その他→H.264で書き出し: パラメータはほとんど『ソースと同じ』を選べる。2pass・VBR、音声は384K、映像は動きが激しいもので12Mbps (～15Mbps)、動きの少ないものなら7 (～9)Mbpsもあれば元動画 (MPEG2 17M/25M)と区別が付かない→これで実時間の6倍程度@Core2quad 2.8GHz でエンコード可能
   • 地上デジタルの場合トップフィールドファーストになっていることを確認
7. 再生はmedia player classicまたはVLC

EDIUSでも音声がずれる!!

EDIUSを使い始めて、2つの問題点があることがわかった。ひとつは、私のPC環境に起因するので普遍性はない問題点だ。あるPCでPremiere Elementsは落ちないのだが、EDIUSではPCが落ちるのである。そのPC (別項で書いたTV用PC。FS用激速PCでは落ちない) では、落ちるといってもアプリが落ちたり青画面になるというような生易しいものではなく、突然リセットボタンを押したのと同じ状態になってOSそのものが再起動する。他にも重い動画再生などでも落ちることからも推測するに、グラフィックカードとソフトの相性かもしれない。

もうひとつは、画像と音声がずれる場合がある問題である。friio録画物ではNHK総合・教育、テレビ東京でずれる。

最初、ドロップフレームの映像をノンドロップタイムラインに並べるために、30秒で1フレームの誤差が生じるのだと思った。ところが上記キー局2 (3)局以外の放送物はずれない。 いろいろ実験・観察してみると、つぎのようなことがわかった。

• タイムライン上で長さが異なる映像と音声は、エンコードするとぴったり合う。つまり編集時のタイムラインが狂っているだけ
• 音声のOrg (オリジナル)は何分何秒何フレーム、Dur (継続時間)は何分何秒何フレーム、という表示が異なっている。だが継続時間のほうが正しい
• 映像のタイムライン表示は正しくない。音声のOrgともDurとも異なる

これらより、TS記録時に何らかの情報が入っていて、それにだまされて映像の長さが狂い、それにあわせて音声の長さが狂うようだ。ちなみにこのずれはタイムライン上に並べた素片単位でおきるようで、カット点で頭をそろえてやると元に戻ったりする。

カット編集をまったくしないのならエンコードするとどうせシンクロしているのだから支障はない (下記(1)) のだが、音声と画像が異なるドロップアウトをしていたり、もちろんCMなど途中のカット編集が必要な場合はまったく同期しない。はじめは『音声の速度を修正して編集してからエンコード直前に元に戻す』などを試したが、どうもうまくいかない。シンクを正しくしてエンコードするのは辛苦ではあるが、方法がないわけではない (下記(2))。

(1) NHKソース(途中CMカットなし)でドロップアウトがない場合

NHKのソースはたいがいの場合、途中(CM)カットの必要がないので、ドロップアウトさえしていなければ、音声と映像の頭とケツの余計な部分を、とにかくシンクロは無視して切ってしまえば問題ない。

1. もしNHKの番組の1コーナーなど『余計な部分が多すぎる』ようなら、Murdoc Cutterでまず大きめに切り取る。Murdoc CutterはGOP単位での編集なので、ジャストとか必要部分に食い込むIフレームでカットすると、やや欠ける部分があるようである (別ページに書いた東芝のDVDレコーダのようである)。たいてい必要部分の2つ分←GOPでIn・2つ分→GOPでOutすればよい。
2. 元ソースまたはMurdoc Cutterで切ったのをBonTsDemuxで画像・音声に分離しEDIUSに読み込み
3. 頭で音声・画像を切って
4. 画像の末尾は次の番組入りのフレーム
5. 音声は番組間で切れ目(まったくの無音)の部分がわかるので、長さが異なるがそこでカットする。
6. エンコードのOut点は、これらに関わりなく番組の正しいと思われるフレーム数に設定すればよい (わからなければ音声のほうがおおむね正しいOut時間を指しているので音声のOutに合わせる)。映像のOutに合わせるとエンコード後にケツが切れることになる。

(2) NHKでドロップアウトがあったり、TV東京でドロップアウト・CMがある

これはいったんAVI化して出力してから読み込めばずれない、ということを利用している。2度読み込みするので、ロスレスコーディングしたほうがよい。

1. 元ソースをBonTsDemuxで分離
2. ただタイムラインに読み込んで、In/Outを設定しCanopus Loslessで書き出す
   • 地上デジタルの場合トップフィールドファーストになっていることを確認
3. これをまたタイムラインに読み込んで、グループ解除
4. 心行くまで編集
   • ドロップアウトがある場合は同期をとる
5. 上記と同じようにH.264(など)で書き出し
   • 地上デジタルの場合トップフィールドファーストになっていることを確認

---

EDIUS Pro 5 + FIRECODER Blu + FIREWRITERでMPEG2-TSの再エンコード

• マイコミジャーナル『SpursEngineで動画はどれだけ変わる!?　カノープス「FIRECODER Blu」』

FIRECODER Bluは、東芝のH.264ハードウェアエンコードチップを搭載したエンコーダボードである。といっても入出力の部分に入るわけではなく、純粋にアプリケーションと通信するボード (アプリからエンコードすべきデータを受け取ってエンコードして返す) である。まあ一時期DV編集でよくあったアクセラレータボードであるが、これらが大抵入出力端子 (IEEE1394端子が普通にPCに付く前はDV入出力であったり、アナログからの取り込みであったり) を伴っていたのと異なり、FIRECODERのPCI-eカードの背面にコネクタなどは一切ない。

実はCanopus製品でありながら、EDIUSのエンコード時の出力先としてFIRECODERを選べるわけではなく (これは間もなく対応するようだ)、ボードの通信相手となるアプリケーションソフトは、ボード付属のFIRECODER WRITER だけという応用の効かなさである(笑)。5月2日に対応しました。

FIREWRITERを使ったfriio録画物の編集手順

FIREWRITER は FIRECODER Bluの付属(無保証)ソフトである。このソフトがこれまた、BD作成機能なんてものがある割にはカット編集すら出来なく、読み込めるフォーマットも限られている。したがって雑誌などの論評で、『EDIUSを伴いハイビジョン編集をするという限られた環境で役に立つ』と酷評されているのも然り、である。だが私はEDIUSをfriio録画物のメイン編集環境に選んでいるので、十分役に立つ。

カット編集すら出来ないということは、少しでも編集する必要がある場合 (頭とケツのカットだけでも)、まずEDIUSで編集することが必須、ということだ。

friioが吐いたMPEG-2 TSをそのままH.264化できるので、では編集の必要がないように録画してしまえばよいかというと、たいてい番組録画時にはタイマーずれを見込んで余分に取っておくし(うちの設定では2秒前スタート、1秒後ストップ)、MurdocCutterなどでカット編集を済ませてしまえばよいのだが、たまにMurdocCutterでカットしたつなぎ目が原因になって? FIREWRITERが途中でエラーを起こしてしまう。

画質劣化させたくなければEDIUSの編集結果をCanopus Losless AVIで渡せばよいのだが、これがまたクソでかい。どのくらいでかいかというと、friioで1時間の番組を録画するとおおよそ7GBくらいになるのだが、これが20倍くらいに化ける。つまり編集をまったくしなかったとすると、150GBくらいのファイルになっちゃうのだ。

NHKモノでパケットが落ちたり、TV東京モノでCMカットしたりする日には(前項参照)、friio TS (7GB)→Canopus Losless (150GB)→ (編集) →Canopus Losless (150GB) → (FIRECODERでエンコード)、となるので、莫大なディスクの空き容量が必要である。さらに、Canopus Loslessエンコード(? エンコードしてるのか?)の所要時間は、ほとんどがディスクのアクセス時間と思われる。いまの編集環境ではシステム(C:)、エンコード前、エンコード後のドライブを分けていないので、ほとんどこの所要時間って (録画実時間と同じくらい掛かる) 150GBのファイルを読んで150GBのファイルにコピーしているのと同じじゃないだろうか(笑)。

Friio録画物の通常の編集手順は下記のようになる。

1. BonTsDemuxで画像と音声を分離
2. EDUISで好きなだけ編集
   • NHK・TV東京モノの音声がずれるソースでは、いったんただCanopus Loslessに書き出し読み込んでから編集
3. Canopus Losless AVIで書き出す

   これを繰り返してためておいて (編集→裏でエンコードを繰り返す場合はためる必要なし)

4. FIRECODER WRITERを起動してクリップ読み込み、画質を選んで激速エンコード。

   ファイルの出力先に日付と時間のディレクトリが造られ、その中に.m2tsファイル(H.264の場合)ができる。DVD/BDチャプタ作成時のEDIUSでの編集情報(.m2ts.eseファイル)はEDIUSから受け継がれないので、Canopus Losless AVIのチャプタ情報(.avi.eseファイル)を流用すれば良いかと思われるが、ただ変名しただけで使えるかどうかは不明。

   • FIRECODER WRITER1.02βではEDIUS同様画質が好きな数値にセットできる。ただしVBRのみ (セットできるのは平均値で、最大値は平均の1.5倍らしい)、音声は384Kbps (48KHz) のCBRだけらしい。

   Losless AVIはクソでかいのですぐ消さないと死んでしまう

まあともあれ、前のプログラムをFIRECODERでエンコードしている間は、CPUにほとんど負担が掛からないため、別の編集をEDIUSですいすいできる、という利点がある。つまりためておいた録画物を土日にエンコードするような場合、ほとんど編集時間だけで作業が済んでしまう。やはりこれは大きい。何が大きいってうちのPCは消費電力が大きいので、編集の裏でエンコードしてくれると夜中にPCを (EDIUSでエンコードだけするため) 連続でフルパワー運転しなくて済むのだ。

逆に夜中にまとめてFIRECODERでエンコードを済ませてしまおうと思ったら、次項のようにまとめてAVIを大量に作っておいて、FIRECODER WRITERで片っ端からまとめてFIRECODERに食わせてエンコードできる。もっともLosless AVIは大きさが洒落にならないので、ディスクの許す限りしか『まとめて編集→AVI』は作っておけないのだが。

エンコード速度と画質

まずエンコード速度の『再生時間の0.4倍』というのは、ほんとであるようなうそであるような。この測定環境は2.83GHzのCore2Quadということだから、我が家のモンスターマシンとほぼ、スペックは一致する。だが、このマシンでは実際のFIRECODERでのエンコード時間は、Canopus Losless AVI→H.264 (1440x1080i) で実時間の約1.1倍程度かかるようだ。EDIUSでの編集後のAVIの書き出し時間が実時間の0.7倍くらいかかるので、EDIUSでの書き出し(実時間の2.2倍程度)とさほど変わらない。

この原因は別にCanopusの誇大広告なのではなく、ハードディスクにあると思われる。上述のように私はC: ドライブにシステム (OS + プログラム) から (これはあまり関係ない。FIRECODER WRITERが起動するとほぼアプリへのアクセスはないし、スワップしないくらいのメモリは積んである、というかプログラムの性質からいってメモリは喰わないだろう) エンコード元とエンコード先から一時ファイル (FIRECODER WRITERが一時ファイルを作るかどうかは知らない) からすべて置いてある。せめてエンコード元とエンコード先を分けると、ほぼ所定の性能はでるのだろう。

ほかに、上記編集プロセスでの画質劣化を避けるため、クソでかいAVIファイルを経由しているのも問題だろう。これが圧縮済みファイルだったりすると、ディスクバスを大きなファイルが通るよりデコード (CPUがやるだろう) のほうが速かったりすると思われる。また最近、上記C: ドライブは現在最高速のHDDに換えてRAIDを組んだのだが、RAIDはストライピングではなくミラーリングである。仮にも4代まえのMSFSからが温存されているHDDがとんだら、泣く (というか別にFS2004以前は実行しないけど、現行のFSXのチューニングした・フリーの機体、シーナリや空港データなどがとんだら、もう再現は不可能と思われる)。いちおうCPUボックスとHDDボックス間はeSATA接続なのだが、アクセス中にeSATAランプを見ると、もう真っ青に灯きっぱなしである (逆にCPU負荷など10%未満だ) から、かなりディスクアクセスに無駄な時間をとられている。

合計時間はEDIUSだけのエンコードと変わらない、と書いたが、実際は快適さが全然異なる。まずFIRECODER WRITERのエンコード中に次の編集をEDIUSでできるためである。EDIUSの操作のもたつきなどはほとんど (音声のキャッシュを作る処理←これまたディスクアクセスの鬼 以外は) ない。ちなみにEDIUSのほうがプロセスの優先順位が高いのか、編集をしていると、ますますFIRECODER WRITERの処理が遅くなる(笑)。

さて画質であるがEDIUSでのエンコードからFIRECODERでのエンコードに換えてみて、私が標準としている12Mbps (世界遺産・料理系)・9Mbps (動きの速い映画など)・7Mbps (アニメなど)・6Mbps (情報番組・落語など)では、おおきな差はみられない。っていうかわからない(笑)。ただし、一箇所非常に大きな進歩がある。なぜかEDIUSのソフトウェアエンコーダでは、特定のシーンに出るフリックが、FIRECODERでは出ないのだ。EDIUSでは、中間階調～暗めのランダムな模様 (たとえば森の俯瞰など) が0.5秒サイクルで明滅するのだ。これは18Mbpsでも出る。おそらく2パスでエンコードしているので、ビット割り当てが増減してしまうのだろう。これはFIRECODERではでないのだが、その構造上FIRECODERは1パスだからであろう。そうすると逆に、2パスで最適化しているビットレートの割り当てが均一で同じ画質になるのか、という疑問を持ったが、静止画にして比較しても上記のビットレートで顕著な違いはみられない。したがってFIRECODERのほうが画質が上 (というより観ていてフリックは不快である)、ということになる。

FIRECODERのウリであるSDからのアップコンバートについては、また後ほど。

それにつけてもやはり、ハードウェアエンコーダは偉大だなあ。Core2quadの2倍以上速いんだもの。こんなのが2セット入っているんだから、いまのBD専用機は家電価格で売られているのは安すぎる(笑)。

---

EDIUS Pro 5 + FIRECODER Blu でMPEG2-TSの再エンコード

待ってました。2009年5月にバージョンアップによって、EDIUS Pro 5本体がFIRECODER Bluに対応した。実は廉価版のEDIUS Neoの方が先に対応していたので、ちょっといらいらしていたのだ。

このバージョンアップによって、EDIUS Pro本体はそれほど変わっていない。気づいた点といえば、私がよく使う『カーソル線をつまんでタイムラインの左や右に投げ出し』→タイムライン1画面スクロール、という小技が使えなくなったくらいである。

エンコードは、メニューの中からH.264を選ぶと『FIRECODER Blu』がエンコード方式として表示されるので、それを使うだけである。上述のFIREWRITERのメニューと以下のような点が異なる。

• CBRかVBRが選べる(VBRは2パスじゃないようだがどうやってるんだろう)
• 最低ビットレートが7Mから。FIREWRITERでは6Mから0.1M単位で自由に選べたが、6M/9M/11M/… と (どうやらEDIUSのソフトウェアエンコーダのレートに合わせてあるよう) 決められた中から選ぶ

なお、どうもFIREWRITERは1パスのCBRであるようなのに対し (それでも特にどう平均ビットレートのEDIUSのソフトウェアエンコーダより悪いとは思えない。ってか『0.5秒フリッカ』現象が起きないだけ良く感じられる)、EDIUSからFIRECODERをドライブして1パスのVBR(?)だと画質がどうなるかは、まだベンチマークしていない。

これを使うと、編集手順は以下のように実にシンプルになる(当たり前)。

1. BonTSDemuxで分離した映像と音声を読み込んで
2. ふつーに編集
3. エクスポートで上記のようにH.264→FIREWRITERを選ぶ(あるいはバッチで書き出すためにためておく←前述の音声ずれソースのためにCanopus Loslessと混在でバッチ処理も可能 →バッチで書き出す)

EDIUS本体の問題であろうが、前述のNHK(総合・教育)およびTV神奈川でみられる、映像と音声がずれる現象はまだ改善されていない。したがって、ずれるソースを編集するときは

1. BonTSDemuxで分離した映像と音声を読み込んで
2. 一回全体をCanopus Loslessでエクスポート
3. そのAVIを読み込んで
4. ふつーに編集
5. エクスポートで上記のようにH.264→FIREWRITERを選ぶ(あるいはバッチで書き出すためにためておく →バッチで書き出す)

と、まあいままでと基本的に変わらない手順となる (いままでよりもちろん、2回目もCanopus Loslessで書き出し→FIREWRITERでエンコードという時間が少なくなるぶん速くなる)。

速度はどうか。これはもう、劇速のひとことにつきる。

ここまでのおさらいをしておくと、まずEDIUSのソフトウェアエンコーダで書き出していたときは、MPEG-2 TS (friio作の18Mbps)を読みながらH.264 (わたし標準では7～12Mbps) を書いていたので、ディスクアクセスは軽かった。だがCPU負荷がかかり、そのせいでエンコード速度も実時間の3倍くらいかかっていた。

次にFIREWRITERを併用した場合、EDIUSからの書き出しは、CPUはほとんど無負荷といえ、18MbpsのMPEG-2 TSを読みながらその9倍もある(したがって160Mbps(!)ということに) Canopus Losless AVIを書き出していたのだから、ディスクアクセスはたまったもんじゃなかった。ってかほとんどこれはディスク速度がボトルネックになって、実時間の1倍以上の時間がかかっていた。またバックグラウンドでFIREWRITERにコーディングさせる場合はほとんどフロントの仕事(EDIUSによる次の編集作業)に影響を与えないとはいえ、やはりディスクアクセスが激しくて(160MbpsのAVIを読みながら6～12MbpsのH.264書き出し) 実時間の1.5倍程度の時間が掛かっていた。同時に行なうともっと遅く、また1本だけエンコードするなら直列に時間が掛かるので、実時間の2.5倍くらい掛かっていたことになる。

対してEDIUSからFIRECODERをドライブした場合、18MbpsのMPEG-2 TSを読みながら6～12MbpsのH.264を吐いているのだからディスクアクセスも軽く、またハードウェアに任せているのだからCPU負荷もあまりない。FIREWRITERよりは重いが、4CPUがそれぞれ30%くらい使われている状態である (FSXでもエンコードしながらまあまあ軽々飛べる(笑))。逆にこのわずかなCPU負荷は(それもわざわざ4コアに振り分けて) 何に使っているのか謎である(笑)。VBRではソフトウェアが先読みとか担当してたりするんだろうか。

これでやっと、フルHDでありながらなんと実時間の0.6倍くらいでエンコードが終わっちゃう環境が構築できた。ビバ・ハードウェアエンコーダ(笑)。

---

夜中にまとめてエンコード

私がハイビジョンで録画し保存したい番組というのは、実に5分間番組が多い。1時間以上あるのは映画くらい、NHK『新日曜美術館』、TBS『SONY THE世界遺産』やNHK『とっておき世界遺産』などは長いほうで、NHK『アジア語楽紀行』とか『世界遺産100』『ことばおじさん』など、5分間のまるでクリップのような美しい(永久保存に値する)番組が多い。 テレビ朝日『タモリ倶楽部』(空耳アワーのみ)やテレビ朝日『世界の車窓から』など2分とか4分だ(笑)。

そうなるとエンコード時間が中途半端に長いのが気になる。EDIUSは私のCore2quad 2.8GHz環境では、実時間の2倍ちょっとでエンコードが終わる。これは速いほうだとは思うのだが、編集(CMカットなしなら1、2分でちょちょいである)→エンコード(10分ちょっと)の間お茶→次の編集→めし→次の編集→ふろ→、と繰り返していると他のことに集中できない。出かける前や寝る前にエンコードをスタートして大電力大喰らいのPCを放置しておくのは、2時間映画とかならもったいなくもないが(エンコードに5時間くらい掛かる)、留守中 (睡眠中) ちょっとだけエンコードしてあとずーっとアイドリングしているともったいない。週にまとめて1度くらい集中して1時間くらいで15本くらいの編集を終わらせて、寝ている間にまとめてエンコードできないものか。

EDIUSにバッチエンコードの機能があるのを発見したのは、実は上記FIRECODER Bluを導入したときである(笑)。FIRECODER用のAVIをまとめてどさっと作るためにいろいろいじっていて発見したのだが (マニュアルが不親切だ)、これはAVIでなくてもいきなりH.264を大量に作る場合でも使えるので、したがってFIRECODERがなくても関係ない。

1. タイムラインにBonTsDemuxで分離した5分間番組の画像と音声を読み込む
2. 不要部分をカットし、In点とOut点をセット
   • このときNHK・テレビ東京モノは長さがずれるが、気にせず『真の番組の長さ』と思われる長さにセットする(例えば4;59;28)。
3. 『ファイルに出力』でフォーマットを選び (H.264書き出しまたはFIRECODERに読ませるためのCanopus Losless)、『保存』しないで『バッチリスト』に書き出す。ファイル名をつけてバッチリストに登録。
4. 次の番組を同一タイムラインの、前のOut点の後に読み込む。

   バッチリストは同一ファイル内のタイムラインの局部局部を別々のファイルに書き出すものなので、新しい編集ファイルを開いてはダメ

   • NHK・テレビ東京モノならば、前のOut点より後の位置に画像と音声の頭をそろえて読み込む。
5. 編集、In/Out設定、バッチリストに書き出す。

   好きなだけ繰り返したら

6. 『バッチリストを出力』で登録したものを一括で書き出す。
   • ここでエンコードフォーマット・パラメータを変えられる。EDIUSで直接エンコードする場合はビットレートなどはまちまちで構わない。FIRECODERのためのLosless AVI作成も一緒に出来る。なおFIRECODERでは一括エンコードする場合すべてのビットレートが同じになるので、画質が同じものを一括して書き出すと混乱しない。
7. このあとまた1.から繰り返してバッチリストを作るのであれば、バッチリストは削除しておいたほうが混乱しない。実は削除しなくてもチェックマークが外れているので実害はないが。

この技を使うと、FIRECODERがエンコードしている裏でEDIUSでエンコードできる。FIRECODERはほとんどCPU負荷を食わないので並列激速エンコードができるわけだが、どういうわけかEDIUSのエンコード時間にあまり影響がなくてFIRECODERが遅くなってしまう。FIRECODERの方が (エンコードする入力がLosless AVIなので) ディスクアクセスが多く (上記参照) HDDのヘッドが飛ぶと速度低下するのに加え、EDIUSは優先度 (UNIXでいうところのnice) が上げられているようで (FSと同時に実行するとわかる(笑)) あまり他アプリの実行が影響しないのだろう。

---

二ヶ国語ステレオのエンコード

この件まだ未解決。知っているひといたら垂れ込みお願い。

地上デジタルになってよかったなー、と思うのは、画質もさることながら、映画で二ヶ国語のステレオという番組がたまにある、ということである。

私は日本のしらけた声優による映画の吹き替えが大嫌いだ(『刑事コロンボ』以外)。したがって二ヶ国語放送の場合、もちろん左右に振り分けてH.264ファイルを作ることになる。ところがそれだと音声がモノラルになる。映画がモノラルであるのほどつまらないことはない。したがって一番良いのは字幕のステレオ原語のみ、という番組であった。と、ここまでは地上アナログでも同じ話。

二ヶ国語のステレオ放送は、元のTSファイルにはきちんと4トラック分の音声が記録されている。たとえばVLCで再生すると、ちゃんと音声トラックを選べて、それぞれをステレオで聴くことができる。

ところがエンコード前の下処理で音声トラックを4トラック得る方法がわからない。BonTSDemuxではちゃんと『主+副』『主』『副』と選べるようになっているのに、どう選択しても副音声トラックが抽出できない (ちなみに『強制5.1ch』とかでもダメである)。

さらに5.1chのエンコードは、EDIUSのソフトウェアエンコーダを使うという条件で下記のように(まだチャンネルアサインが分からないのが原因で完全成功には至っていないが) なんとかできそうだという感触がある。だが、動画プレイヤのメニューで言語を選べるような4ch (2ch×2音声) のH.264ファイルというのはどうやってEDIUSで作れるのかもわからない。スペックとしてはできると思うんですけどね、その後BDに焼いた状態ではふつーにセルビデオとして販売されているんだし(?)。

---

5.1chのエンコード

5.1chサラウンド(6ch)というのは、6つの別々の音を再生できるハイビジョンのソースである。

ま同様の試みは、誰でも知ってる冨田勲大先生(知らない? 『きょうの料理』のテーマ曲知ってるよね)が1970年代の終わりごろに5ch再生を試みたりとか (ピラミッド・サウンド: 前左右・後左右・上(!)の5chであった)、Earth Wind & Fireのエンジニアであった (? ここ曖昧。ともかくアナログで録られた"In the Stone"のパーカッションのカチカチ感を聴け!!) George Massenburg大先生が2chスピーカで前後だけでなく上下から音が聴こえる錯覚を、これまた1970年代の終わりごろ研究していたりとか、古い話ではある。ブームになったきょうびでは安価に6chアンプ + スピーカ6個セットで値段は3倍高くない音響装置が売られていたりするが、これ音楽を聴くのには不向きなのな。

というわけで我が家は旧来の『音楽を聴くための』(変な重低音を強調したシアターシステムではない) 2chステレオでハイビジョンを観ているのだが (なお再生ソフトとかお茶の間PCのサウンドアダプタで、擬似4chを得ることはできる)、この間('09年4月)の『SONY THE世界遺産』で5.1ch放送というのがあったのだ。いま聴けないが、とりあえずエンコードしときたい(笑)。てかチャレンジ精神。

ところで5.1ch音声というのは、前後の左右(4ch)のほかに、前センター、重低音の2chが加わる。前のセンターというのは、ナレーション等をはっきりさせるためだというが、こんなの定位がちゃんと出ないまずいアンプ・スピーカが悪いんじゃないか? 低音も別に録っておくのは、フィルタ回路を端折るためとしか思えない。

ともかく。

まず、6chの音声を分離し、編集するのは簡単だ。BonTsDemuxで『強制5.1ch(split)』を選ぶと、FR・FL (前右・左)、SR・SL(後右・左のはずだが、サラウンド右・左という名称なので、必ずしも後ではないようだ)、C(中央前)、LFE(重低音)というwavファイルに分かれる。Ediusの音声トラックを6以上に増やしてこれを読み込み編集するのは通常と同じだ。なんか、重低音(アフリカの風の音)なんかが入る部分はLFEトラックに振幅がみられ、アナウンスはちゃんとセンタートラックらしきところに入っているようだ。わくわく。

問題は再エンコードである。まず、音声6chを内包できる方式は、AC3またはAACというのを選ばなければならない。幸いEdius・Firecoderでエンコードした(従来の2chステレオの)ファイルはAC3のようなので、これは問題ない。

あとはトラックの順番である。Ediusで並べられたトラックはどのようにAC3にアサインされるのか。AC3やAACの規格で定義されている、トラックの入っている順番と再生機器のスピーカの対応が誤っていると、とんでもない位置からとんでもない音が再生されるに違いない。ま、規格書を読めばいいんだろうがどこにあるかわからんし面倒なので放置した。

最初にオチを書いてしまうが、Firecoderでは5.1chのAC3ファイルは作れなかった。おそらく、EdiusからFirewriterにデータを渡すとき経由するCanopus Losless方式が5.1chをサポートしていないためと思われる。この状況は、今年5月下旬に予定されているとアナウンスされている、EdiusからのFirecoder直接ドライブで解決されるかもしれない。

上記のEdiusのソフトウェアエンコーダ (エンコード時間はともかく0.5秒間隔のフリッカーが発生するので最近使っていなかった) を使ってみることにする。

あちこちのwebをあさってみて、とりあえずトラックの並び順(?)がAC3ではFL、C、FR、SL、SR、LFEとなっているらしいことをつきとめ、この順にEdiusの音声トラックを並べ替えて出力してみる。ちなみにAACではFR、FL、C、LFE、SL、SRの順らしい。

出来上がったファイルをとりあえず再生ソフトの5.1ch→擬似2chマッピングで聴いてみたわけだが、なんかセンターのナレーションが右に定位しているらしい音声が聴こえる。

まあちょっと試して失敗だった、という顛末であるが、詳しいことが分かり次第この項は補足する。