Tech:friioedit
出典: Tariki
目次 |
friio録画物の編集
(前回までのあらすじ)
friioはMPEG2-TSを吐いてくれる、地上デジタル放送チューナーだ。PCで視聴するためには付属ソフトが使えるが、録画したものを観るのには何らかのメディアプレーヤが必要だ (ちなみにVLCやK-Lite Codec Pack付属のmedia player classicがおすすめだ)。
ところが、例えばCMカット程度でも編集して保存するとなると、いろいろ考えないといけない。自己責任、というか自助努力でどうにかしないといけない。
なおfriioで録画したものを云々、というはなしは伏字でされがちであるが、別に違法行為はさらさらしていないので、ここでは堂々と書く (だいたい伏字にしたら自分メモにならない)。録画したものをタイムシフトして観たり、保存して後で繰り返し観る行為は、自分で録画したものならば完璧に合法である。
メディアとプレーヤをどうするか
これが単体機 (なんとかディスク付きHDDレコーダ) ではどうか、というと、別項に書くような旧来のアナログ放送の(なんとかディスク付き)HDDレコーダでそうであるように
- 録画する
- 編集メニューで切り貼り (場合によってはプレイリストを作る)
- ディスクに『コピー』
というように手軽に行なえる。
手軽とはいっても簡単と同義語ではない。2次元的にタイムラインが拡がった状態で編集できないし、リモコンの、数が多いのにやたら役に立たない専用ボタンが多いボタンをぷちぷち押しながら編集していると、発狂しそうになる。まるで携帯電話でメールを書いているようだ。汎用ボタンの数が多い (キーボードともいう) PCとGUIでささっと済ませ、浮いた時間で別のことをしたい。いらいらいらいらする (私はしたがって携帯電話でメールを書くのも、誘拐されたときか遭難して死にそうになったときだけである)。
地上デジタル(BSやCSのハイビジョンもそうだろう)の場合、元の解像度である1440x1040を保持したまま残そうとすると、第一にメディアを考えないといけない。世の中にはHDDVDだか (ハイビジョン規格のまま従来のDVD-(+)R(/W)メディアを使う) BDだかという規格はある。つまり単体機どうしでメディアをやり取りできるようにした標準規格だ。
これらの標準規格で書き出そうとすると、オーサリングという処理を行なわないといけない。つまり、中身のデータはMPEG2とかH.264などのド標準、メディアのファイルシステムはデータDVD/BDでも標準であるISO (DVD) とかUDF (BD)とかであるが、ディレクトリ構成・名前を定められたとおりにし、インデックスとなるファイルを作成しないとならない。
これは専用のソフトがあれば別段、面倒ではない。だが、メディアをあげるような友人後輩親戚親が誰もハイビジョンを視聴していないような世の中である。かつそういう奴らに何らかの都合で録画物をあげる (TV放送をあげたら違法だが自分で録画した飛行機の着陸などはよいだろう) 場合は、あまり「圧縮率を上げると滑らかな輝度変化の諧調感が失われまったりとした質感が」などとうるさいことは言われないと思う。1440x1080 (おっと自分で撮影したものだから1920x1080だった(笑)) の解像度もなくてもよいだろう。ふつうの720x480のMPEG2の8MbpsくらいにダウンコンバートしてDVD-Rに焼いて差し上げれば事足りると思う。
ということで、しばらくは通常のMS-DOSファイルをDVD-RなりBD-RなりにISOとかUDFとかで格納し、PCのメディアプレーヤ類で観る、という方針を立てることにする。
ファイルフォーマットはどうするか
ファイルフォーマットはMPEG2であれば安心である。将来的にプレーヤ (単体機のことでもメディアプレーヤソフトのことでも) がなくなるおそれはないし大人の利権関係もない。そもそもfriioが吐くのは、25MbpsのMPEG2-TS (transport stream)とAAC音声であるため、切り貼りできるソフトであれば、再エンコードによる劣化も時間が掛かる(高スペックのPCを24時間ぶん回すので電気代がかかることにつながる)ことも避けられる。
だがこの規格、さすがに20年も前に制定されただけあって、効率が悪い。効率、というのは、同じような画質でビットレートが高すぎる、ということだ。こころみに最近の規格をいろいろ試してみたところ、この25Mbps (1440x1080・約30fps) のMPEG2と同じような画質が得られるためには
- WMV (9) なら5～6Mbps
- FLV (VP6)なら6～8Mbps
- DivXなら8Mbps程度
- H.264なら5Mbps程度
(アニメとかは知らないが、割と世界遺産系の美し画像でベンチマークした・PCは写真編集に使っている、カラーやガンマ校正をしたsRGB色域オーバーの液晶)
程度のビットレートでよい。
ただしH.264がBDの標準ファイルフォーマットに採用されている以外は、WMVとかFLVというのはPCのメディアプレーヤ専用の規格である。ここではなしは前項に戻るのだが、したがってWMVやFLVで再エンコードする限り、たとえBDに保存するとしても、UDFのふつーのディスクとしてふつーにファイルとしてデータを保存するしかないのだ (単体機でMS-DOSディレクトリからファイルを指定し、WMVやFLV再生ができる、という特殊なマシンができない限り)。
画像エンコードはモンスターアプリ
ところで(どこか別項に書いた気がするが)、1990年代の終わりころ、私の(当時)モンスターマシンは、フライトシミュレータとDVD編集・圧縮・オーサリング専用機であった。その後PCの速度が向上し、SD品質ならラップトップでもリアルタイムに編集中プレビューでき、実時間の何分の一の時間かでエンコードできるようになってすかっと忘れていたが、このたびWMVやFLVやH.264の再エンコードが必要になって、なおかつSDTVの実に4倍以上という面積のエンコードを行なうに当たって、手元のラップトップやfriioを接続して使っているテレビPCでは、保存用の編集・再エンコードの能力が足りないことに気づいた。
幸い、手元にはフライトシミュレータ用のモンスターマシンがある。これで飛ばしているMS FSXというのは、2006年発売だが2008年末の現在まだ、シーナリを複雑にした羽田空港の上空をまっとうに飛べるCPU・ビデオカードが存在しない、という化け物である (笑)。また1990年代の再来である。
といってもさすがにCore2quad 3.2GHzは速い。下記に示すWMVの書き出し(TMPGenc 4やAdobe Premiere Elements 7)で実時間の6～7倍程度、FLV (Adobe Premiere Elements 7)で実時間の8倍程度、DivX (TMPGenc 4) で実時間の6倍程度、H.264は真面目に試していないが(Corel VideoStudio 12)15倍くらい? といったところだろうか。
この中で最も将来性があると思われるのはH.264であって、再エンコードは保存のために行なうのだから(再再エンコードは考えられない)H.264で保存したらよさそうだが、毎週のSony 世界遺産 (実質25分のプログラム) を残すのにPCを3、4日徹夜でぶん回すのはうれしくない。したがって、圧縮時間の割に画質が良好なWMVを中心に残すことにする。なおWMVは、Premiereなどでは『Windows用』などと表示されるが、いちおう標準規格にも提案されている (と思う) し、Windowsがなくなった将来もフォーマットの存続はするだろう。現状では例えばUNIX系OS用でもフリーのcodecとプレーヤは入手できる。ライセンスとか訴訟問題が起きない限り、別にMSのお世話になる必要もない。
フライトシミュレータ用に組みなおしたマシンは、HDDが弱いようだ。フライトシミュレータは一回起動してしまえばHDDアクセスはそれほどないので (たいてい飛び続けているときはアプリケーションを立ち上げたままハイバネーションで眠らせているので起動時間はきにならない) SATAの500Gをぽこんと付けているだけである。これもあと3個くらい同じHDDを買って、C: ドライブはOS・アプリケーションと編集中ファイルでRAID1 (こちらはミラーリングしないで使っているので、手塩にかけて育てたFSXの環境が失われたら怖いと前から思っていただけだ)、D: ドライブはアプリケーションキャッシュでRAID0でも組もうかな。
ただしTMPGenc 4.0のレンダリング中のアクセスは異常ともいえる。CPU usageをみてもほとんど10%以下なのだが、ディスクがスラッシングでもしているようにからからからから回っていていっこうにレンダリングが進まない。OSのスワップによるスラッシングでないのは明らかなので(実メモリが4G (XPで使い切れない)ありアロケートされているメモリがそれ以下)、おそらく編集元(参照元)ファイルへのアクセスと作業用ファイルへのアクセスの効率が最適化されておらず、ヘッドが往復しているのだろう。仮想(RAM)ディスクでも作ってそちらに作業用ファイルを置くか、と思ったが、メニューのどこをみてもテンポラリファイルのディレクトリの設定が見当たらなかった。
このスラッシングは、もっと非力なラップトップPCでは(試用版を使ってみた)気になっていない。ただしそちらはSSD化しているため、そもそもヘッドが動く動作でエンコード時間の大半を取られてしまっていることが考えられる (すなわちモンスターマシンでも作業用ディスクを別に取れば解決する問題である)。
MPEG2-TSの再エンコード (1) TMPGenc/Premiere Elements編
MPEG2-TSはそのままでは扱えるソフトがそれほど多くない。うわさによるとAdobe PremiereのCSだと読み込めるらしいのだが、仕事で使っているElements (別項で書くがAVCHD編集目当てで7に上げた) では読み込めない。
これまた以前から仕事に使っていたTMPGenc (激古い) の最新版はMPEG2-TSも、その中のFriioが吐く音声フォーマットのAACも問題なく扱える、ということで、バージョンを4に上げた。
結果はTMPGencのバグのため、アウト。
どういうことかというと、画像と音声がずれる。いろいろぐぐってみて、下記の説があることを知った。
- TSファイルが壊れていると音声がずれる: これは初期のノンリニア編集時代に私も経験がある。
- → mpeg2repairというフリーソフトで修復できる。ログを観てみると、たしかに5分間で3バイトくらい(笑)壊れている部分がある。だが、これはまったく音声のずれに影響していなかった。ただし精神衛生上よろしくないので、できるだけこのソフトを通してから後述の編集をしようと思う (音声ずれには無意味だが有効なソフト)
- 内蔵MP3エンコーダだとずれる
- →LAMEをインストールしてみた。だが、そもそもTMPGencでDivXもWMVも、内蔵音声エンコーダを使うほかに道はない (FLVは別売プラグインなので知らない)
- 再生ソフトのせいだ
- →ストップウォッチでリップシンクを測ってみると、media player classicでもVLCでも、部分を切り出しても最初から再生しても、常に同じだけずれます。したがってこれは再エンコード時にきっちりずれた状態で音声が埋め込まれている。
ということで、ひとつひとつ確認してみるとどれも誤りである。明らかにTMPGencの致命的バグ。
ちなみに私はTMPGencは好きなソフトのひとつで(Iフレームを意識しながら編集できるなどなかなかまにあっく)、TSの画と音がずれるからダメダメ、という気はない。だが現状で(正しく動けば)TSを下準備なしで編集できる数少ないソフトになれたはずで (安価なソフトでは唯一)、なおかつこの機能だって (一般人にとっては) ほとんどfriio録画物の編集にしか役立たないはずだ。編集作業でどうにもならない音ずれが少しでもある以上、使い物にはならない。だからバグと言い切った。がんばって修正してほしい。
そこで音声と映像のトラックを分け、Premiere Elementsで編集することにする。場合によっては(ずれが時刻とともに拡がっていくような場合: かつてアナログビデオからのキャプチャではそうであった)、ところどころで映像フレームを抜いてあわせる、という技も使える。
これで悔しいのが、Premiere ElementsではDivXでエンコードできないことである。まあ次善の策である(ものによってはDivXより画質が良い)WMVが使えるからよしとする。
結果はというと、見事に同期していた。実は映像と音声の開始点が同一ではないらしく、2フレーム(30ms程度)のずれはあったのだが、ずれが変動しているわけではない。一回番組の最初のほうで合わせてしまえば、最後までリップシンクは保たれる。
ということで手順:
- mpeg2repairでログを取ってTSの誤り修正。
- このときログをみて、スタート直後またはストップ直前が欠けているのでなければ、元のTSストリームを以下利用したほうがよい。あまり欠けが多くないならば、やはり元ストリームを利用したほうがよいことがある。修復済みストリームだと映像・音声とも欠けるが、修復していなければ映像のみ欠けて音声は保たれる、ということがあるため。
- あまりにパケットのロスが多いと、mpeg2repairでも諦めることがあるようです。こんなときはそのまま以下処理するのも吉。
- BonTsDemux (後述) で映像と音声を分離
- またはtsdemuxでm2v (映像) のみ取り出し、towave (ver 1.03)でAACをWAV化、音声のみ取り出す (VLCを外部デコーダとして使うのでインストール必要)。
- ここまでどのツールも実時間の数十分の1@Core2duo 3.0GHz 程度。
- Premiere Elements 7を立ち上げ
- 映像と音声を読み込み
- それぞれのトラックに配して
- リップシンクを一回だけ合わせ
- 必要なら(音声と映像をロックするとよい)、CMカットなど編集
- WMVで書き出し: パラメータは1440x1040、映像8Mbps (8～10Mbps) (動きの少ないものなら4.2Mbps)・2パス、音声440kbps(最高品質) (音質を問わないものなら160kbps)→これで実時間の10倍程度でエンコード可能
- またはFLVで書き出し: パラメータは1440x1040、映像8Mbps (50%～200% VBR)・2パス、音声〓kbps(最高品質)→これで実時間の7倍程度でエンコード可能
- 再生はmedia player classicまたはVLC
Premiere Elementsは何かユーザインターフェースがおかしな使いづらいソフトだ。お茶の間PCの大画面だと相対的に文字が小さく (フォントサイズが変わらない)、灰色地に黒または白というのが読みづらい (色は変更できるが、黒っぽくすると白い字は読みやすいものの黒い字が×、逆にすると白い字が×)。また書き出しのディレクトリが毎回My Documentsになり (こんなところ使ってるひとってヘビーユーザにはいませんって)、レンダリングのフォーマットなども毎回選ばないといけない。ファイル名もWindowsのふつーのダイアログで選ぶのではないから、既にあるファイルと同名を選ぼうとしても(例えばパラメータを変えてエンコードしなおすとき)長いファイル名を入力しなおさないといけない。さらに、エンコード方式を変えただけでファイル名の入力とセーブディレクトリを選びなおさないといけない。明らかな欠陥である。細かいことのようだが、毎日のように繰り返す作業の場合、こういうことはやる気をそぐ。
- TMPGenc (ver. 4):
- MPEG2 TS (AAC)そのまま読み込み→○
- 編集→× 音声が必ずずれる
- もし音声がずれなかったら: DivX、WMV書き出し→○ (H.264書き出しはフレームサイズを選べないので×)
- Adobe Premiere Elements 7:
- MPEG2 TS (AAC): BonTsDemuxなどで分離
- 編集→△ 使いづらい部分がある
- 書き出し→WMV (2pass、8M + 384Kで実時間の9.9倍@Core2duo 3.0GHz) (H.264書き出しはフレームサイズを選べないので×)
MPEG2-TSの再エンコード (2) EDIUS Pro 5編
- この項、3ヶ月使って大幅に書き直しました。EDIUS関連によるハイビジョンの編集に移動。
リップシンクのコツ
これは、私が1990年代の半ばころの、通常のSDビデオのエンコードにえらく時間がかかっていた時代に身につけた技である。いまでこそふつーの(SDの)ビデオで撮ったものは、パパ・ママでも気軽に1394経由でPCに取り込み、さくっと編集できる。だが当時は、Premiere (10万円くらいした) のプラグインでMPEG2ソフトウェア・エンコーダなる別売品があり (これまた10万円とかした。232Cドングルが付いていた)、映像と音声を別々にエンコードしたものをオーサリング段階で合わせていた。あ、それは別に関係なくて、なぜ音声と画像がずれていたかというと、専用ハードウェア経由で読み込んだデータパケットが時々落ちていたからなんですね。
映像が落ちて音声が残っていると映像が先行するわけで、逆に重複パケットがあったり傷物のパケットが紛れ込んでいると映像が遅れる。音声が壊れる場合もある。10分くらい取り込んだあとさあ編集しようとすると、まずプレビューで(これも30秒くらいレンダリングした後5秒くらいプレビューできるわけであるが)口と音が合っていない。一刻堂状態である。
ほかにこの技は、バンドのライブを音声別録りであとであわせたりとか、2カメ以上で撮って (素人のビデオ撮影だからSMPTE同期とかしているわけがない) あとで編集でスイッチングする場合などに有用であった。音録りがハードディスクレコーダやDATだったり、ビデオカメラが複数といった場合は、1時間回しても1フレームもずれないくらいの精度はあるため、これらはPremiereの複数トラックに読み込んで同期点をいっかい合わせてしまえば、後は細かくいじる必要はないのだが。
これが、まったくFriioでの録画物でパケットが落ちている場合の対処と同じなのである。
こういった映像と音声が食い違っている場合は、まず何フレーム食い違っているかを調べ、傷物のパケットを探し出して、そのフレームを削除したり (映像が遅れている場合)、欠けてフレームを単に隙間(黒画面)で補うと目立つから同じフレームをもういっかい繰り返したり (映像が先行している場合) する。傷が見当たらない場合や面倒くさい場合は、シーンの切れ目を短縮したり(映像が遅れている場合)、ほとんど静止しているシーンを見つけ出して引き伸ばしたり (映像が先行している場合)する。
どこでずれを判別するかは、唇の動きやパーカッシブな音を立てるもの (楽器なら分かりやすいが、他にも物と物がぶつかる音など) の映像と音をみる。Premiereでタイムラインの拡大率を上げ1フレームずつ音と映像を確認するのだが、カーソルを動かす場合1/30秒しか再生してくれない。
以外に後者は難しく、衝撃音のように聴こえても立ち上がりが遅かったり、周囲にノイズがあると違う音に聴こえたりする。ひとの声というのは特徴を捉えるのが容易なのだろうか、割と楽に同期できる。といっても唇の動きが曖昧な子音では難しく、バ・パ・マ (外国語ならあとファ) 行の音なら初心者でも簡単だと思う。
人間の声というのは20～30msecなら定常とみなせるので(音声圧縮などにこれは利用されている)、1フレームが1/30秒、というのはまことによくできた規格だなあ、と思うのだが、例えば「マ」の音でリップシンクする場合、唇を開く前のフレームでは「ン」、次のフレームでは「ア」になっているので非常に判別は容易である。顔が大写しになっていなくてもHDVだと唇の動きがよくわかるので、こんなところもハイビジョンの恐ろしさなのかなあ、とも思う。
ちなみに長年こんなことをして遊んでいると、リップシンクに非常に敏感になってくる。3フレームずれているともう、気になって気になって仕方ない。同じ映画を観ているひとがずれていることに気づかないが私は気づいている、ということもある。金が掛かった映画で、本人吹き替えのアフレコがへたくそな場合など、合ったりずれたりもう耳を覆いたくなる(笑)。もっとも7フレームくらいずれているのにまったく気づかないひともいるのだが、ふだん字幕映画を観ないで、外国語の『吹き替え』 (コロンボ以外は大嫌いだ。もっともリップシンクが理由ではなく、感情表現や俳優の印象が損なわれるから) で唇と音がまったく合っていない映画ばかり観ていると、こんなところが鈍感になるのではないかなあ、と思う。あとビデオと関係ないが、屋外ライブで50mも離れたステージをオペラグラスで観たら、ドラムなどは音と手の動きのずれが目立ち (ビデオ換算で5フレームくらいずれているわけで)、「おおおリップシンク合わせてー」という気持ちになったことがある(笑)。
それから日本語の『マ』行の音は1種類だと思われているが(『ン』は数種類あるが)、唇を閉じずに歯と下唇で『マ』行の音を発音するひとがいるようである (地方による発音の癖だと思う)。このような場合、ちょっとリップシンクは難しい。
さてFriio録画物におけるリップシンクの作業は、書いてみると面倒そうであるが、いろいろいじっているうちに (専用PCを用意・もちろんOSはWinXP・常駐ソフトを外す・録画中は観ないかフレームを小さくする、なお) Friioの録画物のパケットも落ちなくなってきたので、もう後述するようにmpeg2repairで壊れているパケットがないことを確認したら、BonTsDemuxで分離した映像と音声を、番組の最初のほうで合わせ (たいていの場合音声2フレーム先行)、番組の終わりでずれていないことを確認するという程度である。どうせエンコードやCM・頭と終わりカットのためにPremiereは立ち上げるので、1プログラムで1、2分作業が増えるだけ、という程度だ。
まあ中には録画のときに欠損パケットがなかったはずなのに番組の部分部分でリップシンクがずれているという番組もあったりして、プロの編集者もまあ、適当に手を抜いて仕事をしていることもあるんだな、と認識したりする。
困るのが人物が出てこない世界遺産系の番組だったり、もともと口が適当に往復しているだけのアニメだったりするのだが、逆に言えばこれらの番組では多少ずれていても(シーンの変わり目がずれていたらまずいが)分からないので、そのような場合は合わせない(笑)。
AACの音が出ない
放送によっては、AACの音が出ない場合がある。情報によるとAACのチャネル数が0になっている多重放送とかの場合らしいが、私が最初に遭遇したのは落語(笑)。落語の二ヶ国語放送ってやってんですかね。
- →と思ったら副音声で視覚障害者のための解説をやっていた。下記BonTsDemuxでは、主音声がL・副音声がRにミックスされて出る。いちいちR (副) から「と羽織を脱ぐ」などと解説があったら鬱陶しいなあ、と思っていたら、登場と退場のときだけ副音声が流れて(笑)、こんなの見えなくてもわかるわい。
- ちなみに落語などは4.2Mbps + .26Mbpsくらいのレートでもサマになるね。
ともかく、こういう放送は
- VLCでは音がでない
- towaveでは「みぎょー」という変な音のwavファイルが生成される
という現象が起きる。
解決策は、もうひとつのdemuxツール BonTsDemux (1.10) である。これで見事にm2vとaacに分離できるのだが、件のAACファイルをPremiereに読ませるとコアダンプしくさる。しょうがないので、BonTsDemux内でwavに変換、あとは上記と同様。
なおBonTsDemuxはtowaveより音ずれしやすいとか何とかいう噂もあったが、これはウソである(きっとTSが壊れているとそうなるんだと思う)。上記mpeg2fixを通したからかもしれないが、なんと上記tsdemux + towaveで必要だった開始点のシンクも必要なく、最初から最後まで同期が保たれていた (厳密にいうと音が映像より2フレーム程度先行スタートしているようだ)。同一ツール内で映像と音声を分離したおかげだからかもしれません。
それから洋画の吹き替えなどでは、私はわざとステレオ(主 + 副) にして外国語のほうを残したい場合が多い。アナログ放送・ビデオ時代には、強制的にステレオで録画しておけば、L chが主、R chが副になる (あとで好きなほうを消して聴けばよい) のだが、BonTsDemuxでもステレオにすれば同様になる。
ディジタル放送ではステレオの主、ステレオの副、ということもできるはずなんですが、実際そういう送出されているんですかね? もしそうだったらでマルチプレクスを2回かけて、主音声(ステレオ)、副音声(ステレオ)を取り出すという手があるのだが。まあもっともPremiereの各種ファイルフォーマットエンコーダとかDVDのオーサリングソフトで、4ch以上に対応しているものを使っているわけではないし、ステレオの主音声とステレオの副音声が欲しいのって映画くらいで、ニュースとか落語とかの副音声対応番組でステレオで取り出してもあまり意味ないんですけど。wav/MP3ファイルの状態でも取っておけば将来使うこともあるかなーとか。
画面比率がおかしい (1) 4:3→16:9録画物の編集
4:3放送の後に16:9放送が入っていると、Premiereで編集するときに前の4:3部分に合わせてPremiereが読み込みくさるため、16:9放送部分がぐしゃっと潰れた殺人的な映像になってしまう現象である。私が大好きなNHK教育テレビでこの現象がよく起こる。
教育テレビの番組では、前述のように4:3と16:9が混在している (民法などは常時16:9で送出してSD番組は両側黒帯などで対応しているようだ)。なぜ教育テレビだけでこういう問題が起きるのかは、このへんで論じられている。
教育TVのプログラムには下記の4種類あるようだ。
- 16:9コンテンツを16:9信号をつけて送出(例: アジア語楽紀行)
- 4:3コンテンツの両側に黒帯をつけて16:9信号をつけて送出 (例: わかる使える英文法)
- 4:3コンテンツの両側に黒帯をつけて4:3信号をつけて送出 (例: 星空紀行)
- 4:3コンテンツを(画面の端から端まで使って)4:3信号をつけて? 送出 (例: 手話ニュース845)
4. がFriioで困った表示になる (みょい～ん、と伸びた殺人的な映像になる) のは、Friioビューアがおそらくアスペクト信号をみずに常に16:9で表示しているからだろう (なお手動で表示アスペクトは変えられる)。ふつーの16:9TVでも同じ現象が起きると思うのだが、どうしてクレームが来ないのだろう。それはおいといて、これはPremiereで読み込んだら4:3で正しく編集できると思うのだが、いまのところあまりSD放送に用事はないので試してみていない。
1.は表示も編集にも困らない。ただ問題は、2.の放送の後に1.の放送があって (わかる使える英文法の終わりで録画スタート、録りたいのはアジア語楽紀行) 、TVRockにやや早めのスタートを命じていると、前の番組がSDだったときに、画面比率を4:3だと思ってPremiereがおかしな比率で読み込んでしまう (Premiereは最初のGOPかなんかの画面比率をみて読み込み比率を決定しているようである。少なくともElementsでは読んだ後にプロパティなどで変更する術はみつかっていない)。
こうなったら、Murdoc cutterというソフトで頭を切り取ってやればよい。つまり4:3の信号(?)が入っている部分をカットしてしまえばよいわけである。
Murdoc cutterは単にCMなどの切り取りをして再エンコードしない、という局面ではよく使われているソフトのようである (無料でもあるし)。ただしオペレーションがやや面倒で、再エンコードするなら細かい編集はPremiereでタイムラインを拡大・縮小して行なったほうがはるかに楽だ。
なおMurdoc cutterでまたまた映像と音がずれる、という報告も見受けられるが、これまた都市伝説っぽい。元のファイルにエラーがない場合は少なくとも、気になるようなずれは起きていない。
- Murdoc cutterを立ち上げ、下のダイヤログのAddで元TSファイルを追加
- 元TSファイルを選択し、Get GOPする
- ダブルクリックすると、上左のダイヤログでフレームの頭だしをできる。< >ボタンなどで開始フレームを出し (ただしGOP単位。1/30秒のフレームではないので、番組開始前が1～2秒あっても > ボタンで2、3回の操作)、INを設定。スライダなどで最後のフレームまで送りOUTを設定。
- →ボタンで右のダイヤログに送られる。outputファイル名をつけ、cuttingで作業開始
複数ファイルのバッチ処理ができる? のか、CMなど複数のカット箇所があるのに対応しているのか、実際はもっと複雑な処理ができるようではあるが、ここでは頭のゴミだけカットしてあとは上記の編集手順を開始することを前提にしているので、あまり深入りしない。
画面比率がおかしい (1') 4:3録画物
上記作業は、EDIUS 5を使って編集するときにはスキップすることができる。つまりこの現象は、最初のフレームだけみて『自動的に』判断してくれるPremiere Elementsが悪いだけであって、というか、『自動』をやめさせて手動でソースのピクセル比率を指定できればいいだけのことなのだ。
EDIUSではビデオトラックのプロパティ→ビデオから、ピクセル比率を指定できる。1440x1080の送出物が4:3になっているのは、ピクセル比率が1.0になっているだけなので、これを1.333 (16:9)に変更すればよい。
画面比率がおかしい (2) アスペクト比異常録画物の編集
これは16:9であるはずの録画物がぐちゃっと潰れて表示され、Murdoc cutterで先頭を切り取ってやっても直らない、という現象である (というかMurdoc cutterがだまされる)。教育テレビで起こる。
こちらは前項の3. (星空紀行)、つまり16:9の送出物に4:3だよ、という偽の信号が入っているためと思われる。まあ4:3というのは嘘ではなくて、画像の両側には黒帯が入っているので中央だけ利用すればよいのだが (ちなみにPremiereで中央だけ切り取って書き出す、というのは、できなくはないが相当手間である)、あきらかに両側の黒帯部分も画像である(NHK Eのロゴがある)。非可逆圧縮ではビットはほとんど割り当てられないことが期待されるが、それでも画像は画像である。4:3だという情報を無視すれば、単なる両端が黒い16:9画像なのだが、Premiereはバカ正直である。つーかこれに4:3だという信号を入れるのはいかがなものか > NHK。
はじめ、たまたま録画スタートが番組が始まって後であったため、番組の最初にしかアスペクト比の情報が入っていないのか、と思ったが、Murdoc cutterでどの部分を読んでも4:3のままになっている (Murdoc cutterはPremiereと違い、画面比率が変わった部分できちんとプレビュー表示サイズが変わるので、16:9か4:3か部分部分でわかる)。Murdoc cutter様も画面比率の情報が入っていないと4:3がデフォルトなのかなあ、と思っていたが (よく考えればまさか1080iのMPEG2 TSがデフォルトで4:3のわけないのだが)、16:9の番組を途中から録ってMurdoc cutterにつっこんでもきちんと16:9と認識してくれるので、これは教育テレビの信号送出が誤っている(?)ことがわかった。なおこの放送は、4:3のSD? 録画物に両側黒帯をつけて16:9として送出しているものなので、よく考えていないNHKの職員が設定を誤ったものと思われる。
対処法であるが、上記のようにPremiereは読み込んだ最初のGOPの比率で以後の映像を読み込んでくれるので、逆に考えれば頭に16:9の映像をくっつけてやればPremiereはだまされるはずである。くっつけるのもMurdoc cutterを使う。これでうまくいった。
- Murdoc cutterで問題の16:9コンテンツ(設定は4:3になっていると思われる)を読み込む。最初から最後までをIN-OUTとし、クリップのウィンドウ(右上)に送り込む。
- 何でも良いから16:9コンテンツで16:9の信号が入っているものをMurdoc cutterで読み込む。最初の数GOPだけをIN-OUTとし、クリップウィンドウに送り込む。こちらが先にくるようにつながって欲しいので順番を入れ替える。
- Clipで書き出し、BonTsDemuxなどで分離。
- ふつーにPremiereでm2vとwavを読み込む。先頭フレームをみて16:9だと判断してくれるのでめでたしめでたし。
16:9の信号が入っている短い映像、4:3の信号が入っている短い映像は、それぞれPremiereが認識を誤ったときのために『だまし用ヘッダ映像』としてとっとくべきかしら(笑)。
再生してみる
そもそもFriioの直接テレビ観る用PCがあまりスペックが高くなく、それでもコマ落ちせず再生できているので、録画したものを観るプレーヤは (media player classicとVLCを使っている限り) それほど重くない。これはMPEG2-TS(再エンコード前)であっても、WMVでもFLVでもDivXでも同じ。H.264は低スペックのPCではまともに再生できていない。
ところでFriioの付属プレーヤはインターレース除去がデフォルトみたいなので気にならないが、再生時はインターレースが気になる。
TMPGencでエンコードすると、エンコード時のインターレース除去がなくてもWMVはインターレース除去されているので、WMVはインターレース除去がデフォルトなのか? と思っていましたが、PremiereだとWMVはインターレース除去がプレーヤで必要で、FLVは必要ないみたいです。謎。
実はインターレース除去は、エンコード時にはあまりしたくない。保存すべき画像をいじって合成しちゃっていることになるので、インターレース除去の技術が進んだりメディアプレーヤの速度が速くなれば画質はよくなると考えられるが、再エンコード時に除去してしまっているとそれが原因で除去の必要がない部分がボケちゃったり、そもそもエンコード時間が掛かるのが嫌だ。
なおVLCはよくできているが、インターレース除去の設定にバグがある。再生開始してからメニューで除去を選ぶと除去されるのに(次のソフトに移動すると初期化される)、設定メニュー(高度)でインターレース除去を選択しても無視されてしまう。
それから我が家のTV用PCでは、ときどきVLCで再生中に落ちてしまう (アプリケーションやOSが落ちるのではなく、物も言わずにPCがrebootするのだ(笑))。VLCを疑ったが同様の症状は知られていないようだし、Media Player Classicでも同じようになったので、おそらくサウンドハードウェアのバグであろうとにらんでいる。
結論
PCで編集するのは面倒だ(笑)。
まあ編集中は2次元に拡がったタイムラインをマウスであれこれできるのでいらいらしないが、ファイルを上記のようにコンバートしていく手順(Premiere CSをげとすれば不要なのか?)、実時間以下でエンコードできないこと、などを考えると、まだリモコンでいらいらしながら編集し、エンコードはデッキ任せ、というのが精神衛生上は上だ。もっとも現在は『標準規格』で保存する気がないから (WMV化してくれる単体機などないから)、適わぬ願いなんですけどねー。H.264のPC用のハードウェアエンコーダボードがあってもよい。
それより最大の問題は、いまHDVで残しておきたい番組、というのがほとんどないことだ(笑)。電波の埋め草みたいな、芸人 (芸がない人) が「げはは」とバカ声を上げているような番組は残しておくどころか観るのも不要だ。いや不要どころかエコ論からいったら石油資源を大量に浪費する害悪だ。
friioだって『Sony the世界遺産』を良い画質で観たいから、というの目当てで買ったようなもんだし。
