Last update: Saturday, 04-Jun-2011 17:29:22 JST
Access Count: (start 1997/07/04)
この日記はGNSで生成しています。
この日記の画像はOPTPiX webDesigner Ver.4で生成しています。
|
Last update: Saturday, 04-Jun-2011 17:29:22 JST |
【USB2.0接続 IDE3.5inch HDケース】」（コレガ）
_ 昨晩のHDD顛末がようやく済んだと思ったころに、いままで使っていた外付けHDDの１台が沈黙しているのを発見・・・幸いにしてHDDそのものではなく、制御基板の死亡っぽいということで、ケースだけ交換して無事動作確認。
_ VBR。オーディオエンコーダで使われる「VBR」と、ビデオエンコーダで使われる「VBR」は、かなり意味の違う使われ方をしているので、注意。
_ あるデータを圧縮すると、ストリームサイズが小さくなる・・・のは言うまでもない。もちろん、どれくらいになるかは、圧縮してみるまでわからない。
_ 「ストリームサイズは問わないので、このくらいの品質でやってくれや」というのが、第一のパターン。可逆圧縮（ZIPとかLZHとか）なら常にこれ。非可逆な圧縮の場合、たとえばJPEGは普通これになる。DivXエンコーダなんかでも「Quality-Based」とか「QBR」とかいわれるのがこれ。TMPGEncの「固定品質(CQ)」もこれ。
_ 「理論最大で指定のストリームサイズに収まるように、品質パラメータを指定する」のが、第二のパターン。理論最大なので、これよりストリームサイズが短くなることがありうるが、このときは残りを「意味のないデータで埋める」ことで、都度ストリームサイズを固定する。いわゆる「CBR」がこれ。
_ 第二のパターンで、「意味のないデータで埋める」ことをしなければ、ストリームサイズは小さくなるよね・・・というのが、第三のパターン。映像をリアルタイムエンコード録画するときに「VBRモード」があったら、これ。
_ 「理論平均で指定のストリームサイズに収まるように、品質パラメータを指定する」というのが、第四のパターン。よーく考えると、実はこれは第一のパターンと同じ。「理論平均のストリームサイズ」を「品質パラメータ」にテーブル変換していると考えれば、わかるかと。「理論平均」じゃなく「理論最大」にテーブル変換すれば、第三のパターンと同じともいえる。
_ 「まず１回圧縮してみて、その結果から『この部分はこの品質で圧縮するとこれくらいのサイズになる』というデータを得て、それに沿ってもう１回圧縮する」というのが、第五のパターン。「ファイルサイズを指定して保存するJPEG」がこれ。またDivXやTMPGEncの2passエンコードもこれ。「Variable Bit Rate」というよりは、「Variable Quality」と言ったほうが適切かも。
_ 「VBRのほうが品質がいい」というのは、「データの傾向によって細かくビットレートを調整する」からではない。「CBRにはサイズ合わせのために常に無意味なデータが埋まっている」からにすぎない。上に５つのパターンを挙げたが、「第二のパターン」以外のすべてを「VBR」と呼ぶ可能性があるので、ひとくくりにしないよう注意。「指定ストリームサイズの範囲内で最高品質が得られる」という意味での「真のVBR」は、第五パターンのみ。代償として「試行と逆算のために余分な時間がかかる」のは不可避。
_ さて、LAMEのABRやVBRはどれだろう。ABRは・・・「今までの圧縮実績から次のフレームの品質を自動算出する」というのは、第六のパターンになるのか・・・総合的には「圧縮後のストリームサイズに応じて品質を変える」のだが、局所的に「必要な部分に多くのストリームサイズを割く」ということは不可能か。
_ 対してVBRは・・・「指定した品質でフレームを圧縮してみて、上限・下限を超えちゃったら品質をずらしてやり直し」かな。ということは、どっちにしても「指定ストリームサイズの範囲内で最高品質が得られる」という意味での「真のVBR」ではないわけか・・・2passでエンコードするMP3エンコーダって聞いたことないしな・・・。
_
なお今回のLAMEの調査には「最初から説明するInside MP3」の「フレームヘッダ出力プログラム」を使っている。これを使うと、「CBR以外のエンコードをしたときに、どこのフレームがどのくらいのストリームサイズで圧縮されたか」がわかる。
_ お仕事あとに帰りに秋葉で買い物。
」（うたたねひろゆき）
」（熊倉隆敏）
」（新谷かおる）
」
」
」
_ あと、帰宅後あまぞんぽちっとな。
」（予約）
_ CM挟む余裕なんかない残りの話で「どこにCMを挟むか」がいちばん気にかかっていたところ。「祭りから帰ったとこ」か「ゴール後」かどっちかしかありえないんだが、前者は早すぎるし後者は遅すぎるから。
_ 次の焦点、「『ゴール』シーンの画と音の連携をどうするか」。「夏影〜無音〜銀色〜青空」を崩すことがなかったのはよかったが、「晴子の胸に飛び込む」→「視点変化＋『とさっ』効果音」→「ホワイトアウトしながら『ゴールっ』」→「青空」というシーケンスがやや不自然。「飛び込みながら『ゴールっ』」→「視点変化＋『とさっ』効果音」→「青空」→「ホワイトアウト」のほうが自然だったんじゃないかな。
_ 「青空」のまま晴子の語りに入る構成アレンジはなかなか。「夏の終わり……僕の休暇も終わりだ」の台詞の直後に「♪また 夏が来る」の歌詞を繋げるところはうまい。
_ 最後の翼人の語りのあたり、アニメだけでは説明が不足してるかな。端々を繋げる言葉がいくつか省かれているため、どれがどこに繋がるかを思いっきりボカしてる・・・というか、この時間に収めるためにはボカすしかなかったのかもしれず。ただ、それゆえに最後の少年少女へ繋がりの唐突さと最後の「さようなら」で終わる、ファーストプレイを終了したゲームプレイヤーの「なんか置いてかれた・・・」感を見事に再現したともいえる・・・（笑）。
_ なんだかんだ言いつつ、「12話でゲーム版AIRをアニメで再現する」というミッションは、見事クリアできたと思う。アニメの部分だけ思い出して「全体の筋はわかんなかったけどいいシーンを観られてよかった」と言わせるだけの作りこみはなされていたし、全体を再把握するために原作のゲームをするのはもちろんおすすめできるし、「ゲームすんのはかったるいけどもうちょっと詳しい解説が欲しい」という向きには各地の「ゲーム版の」AIR考察が違和感なくアニメに当てはめられる。
_ 原作つきアニメは「原作を知らなくてもアニメだけで完結させるよう作らないとダメ」というスタンスが一般的だと思う。しかし、この作品は「端々省略するけど十分楽しめるようには作る。それでも不足なら原作を当たってみろや」というスタンスもアリだ、ということを示してくれたと感じた。あっぱれアニメスタッフ。
_ 追記。ちょっと古めのリンク集だが、古いゆえにいろいろ役立つかもということで。
_ AIRゴールお疲れさまです。最終回の率直な感想が、「PC初回版発売直後のクリア感想の一大勢力」と見事に同じ・・・ゲーム版のプレイによる「事実上のリプレイ」でどうなるかな。
_ 日記レイアウト変更。うちでは非常に寂しい結果に・・・なんかPDAの簡略化縦画面モードみたいな感じ（苦笑）。キャプチャ貼っておきますんで、ご参考に。なおIEは6.0.2900.2180.xpsp_sp2_rtm.040803-2158（WindowsUpdateで普通に入る最新版）、フォントサイズ最小。
_ Amazonアソシエイト管理ページリニューアル。わしも指摘されて気づいたんだが、「注文レポート」のページで[クリックのみで注文のない商品]項の[すべての商品を表示]の左の小さい三角マークをクリックすると出ます。とはいえ、
_ という感じで、使い物になりゃしません。ということで旧来のをそのまま使っていたりする。
_ いいかげんDivXを5.2台にするかと、エンコ作業が少なくなる今週を狙ってサブマシンで試験を始めようとしたんだが、DivXをアップデートした途端にTMPGEnc 2.5の圧縮CodecにDivXが表示されず、選択できなくなる罠。
_ なんじゃこりゃーと、別のマシンで同様に試験してみたら、DivXはおろかWMV9VCMまでも表示されない罠。
_ さんざん調べたあげく、ようやく原因っぽいものがわかった・・・ということで、サポート掲示板に投稿。一応コピーをここに。
過去何度か「TMPGEnc 2.5でAVI出力時の映像CodecにDivXなどが表示されない」という 問題の報告があったようですが、原因がわかりましたのでレポートいたします。 まず、レジストリエディタで、以下をテキストにexportしてください。 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32 このとき、exportされたテキストのセクション [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32] にドライバ情報が列挙されますが、ここのリストの「先頭約64個くらいまでしか TMPGEnc 2.5が認識しない」のが不具合の原因です。 現在のWindows XPでは、ここに70〜80個のドライバが列挙されることが珍しく ありません。このため、64個を超えている状態でDivXの新規インストールや バージョンアップなどを行うと、DivXのドライバ情報はリストの一番最後に なってしまい、TMPGEnc 2.5で列挙されなくなります。 （レジストリエディタ上では、登録順でなくABC順に並べ替えて表示されて しまうため、ドライバの登録順序を知ることはできません。登録順序を知るには、 exportする必要があります。） TMPGEnc 2.5の次バージョンがもし出るのであれば、ドライバの列挙個数を増やすよう 改善をお願いしたいと思います。 -- とりあえずの対処方法です。 このexportしたテキストをエディタで開いて、"VIDC.????"="????"という行をリストの 手前に持ってくるよう修正します。たとえば、 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32] "midimapper"="midimap.dll" "msacm.imaadpcm"="imaadp32.acm" "vidc.cvid"="iccvid.dll" "vidc.DIVX"="DivX.dll" このようになっていたら、次のように並べ替えます。 [HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Drivers32] "vidc.cvid"="iccvid.dll" "vidc.DIVX"="DivX.dll" "midimapper"="midimap.dll" "msacm.imaadpcm"="imaadp32.acm" 次に、このレジストリエントリのツリーをレジストリエディタでツリーまるごと 削除します。削除する場所や手順を間違うと、Windows環境を破壊しますので注意。 最後に、exportして順序を修正したテキストをレジストリエディタに読み込ませ、 レジストリエントリのツリーを再構成させます。 TMPGEnc2.5を起動し、AVI保存コーデックに各ドライバが表示されるのを確認して、 作業終了です。
_ しかし、しばらく後に「Codecの登録数には依存しない」というリターンが。ということで追加調査のうえ、以下の結論に。
＞ TMPGEncシリーズでは Video for Windows の標準的な機能を使いましてコーデック ＞ の取得を行っており、現在の仕様で検証を行ったところ、64個以上のコーデックを ＞ レジストリに登録しましても、64個を超えるコーデックの取得は出来ております。 追試の結果、当方のもとにおいては"ITIG726.acm"という音声Codecより後のビデオCodecが 認識されないという問題であることがわかりました。 個数によるものではなかったことをお詫びします。 ただ、一般的な列挙API（ICInfo(ICTYPE_VIDEO, num, &info)）では音声Codecをskipする ことができ、現に3.0 XPressではskipできていますが、2.5ではskipできていないようです。
_ まあ何にせよ、「Codecの登録順によって不具合が起こる可能性がある」という結論で。
_ うちのDivXエンコーダ環境はいまだに「DivX 5.1・Bフレームなし」だったわけだが、そろそろBフレームが安定して扱えるようになってきたかな〜ということで、5.2.1をサブマシンに導入してテスト中。
_ 比較的品質のいい映像に対して、Bフレームによる「2passモードで、ファイルサイズに対するDRF値の向上（値としては小さくなる）」「1pass QBモードで、同じ品質の映像に対するファイルサイズの減少」が確かに認められる。
_ 逆に、品質のよくない映像・・・たとえば電波状況のあまりよくないUHFチャンネルの映像とか、もともと品質のよくない高圧縮の映像とか・・・では、むしろ「DRF値の悪化（値としては大きくなる）」がみられる。ただ、上がってる割には見た目での品質の悪化は認められない。
_ と、ここまで来て困った問題が。TMPGEncやAviUtlでBフレームを使ってエンコードすると、「最初のフレームがダブって、末尾の１フレームが欠ける」現象が起こる。なぜかVirtualDubでは発生しないのが謎。詳しくは、下の「８枚のフレームに１〜８の数字を書いただけ」の映像ファイルを各自でエンコードしてみるとわかるかと。
」
」（Blueberry&Yogurt）
」
」
」
」
」
Last update: Saturday, 04-Jun-2011 17:29:22 JSTメールはこちらへ...[後藤浩昭 / Hiroaki GOTO / GORRY / gorry@hauN.org]
