ソフトウェアをいじる話 2002年(その1)

最新の「ソフトウェアをいじる話」は
http://www.kmc.gr.jp/~ranran/memo/software.html
で参照できます。リンクされる方は目的に応じてURLを使い分けてください。

2002/4/12

DivX 5.0

• 某「大手掲示板サイト」(笑)では DivX5 の評価は芳しくないようだ。 一言でいうと「完成度がDivX4よりはるかに劣る」ようだ。 まぁそのうち改善されるだろう。 それよりMPEG4という標準規格に沿ってくれてるほうが、 codec の別実装には都合が良い。
• ……とかいいつつ、私も今のところは DIvX4 でしばらく様子見、 だったりするのだが(^^;
• DivX の派生品でオープンソースな Codec にXviDというのがあるようだ。 Windows と Unix の両方で再生できるようなら使ってみようかな。 でも DivX5 がちゃんと品種改良されてくれれば必要ないかも。

xkanon と esound

• アニメ Kan○n の進行と同期してゲーム Kan○n をやる、 というアホなことを考えて、しばらくぶりに xkanon を実行してみる…… BGM が鳴らない(泣)
• 起動してすぐはBGM は鳴ってるけど効果音を鳴らしだすとその後止まってしまう。 その後無理矢理ゲームを続けると、効果音が鳴ってる間だけBGM も鳴る。
• xair で試してみると、こっちは最初に効果音(海の波音のアレ) が鳴るので最初から音楽が鳴らない。
• しかも、この状態になると xkanon だけでなくすべての esd 使うプログラム(esdctl とかも)が動作しなくなる。 ので、esd 側の問題っぽい。
• esound のバージョン上げた(0.2.20 → 0.2.24)せいかなぁ? と思ったが、普通にコマンドラインから別の esd アプリ (mpg321 とか esdcat とか)を使ってる分には何も問題がない。
• esd をデバッガにかけて調べる。 xkanon との socket からデータを read しようとして esd が停止している。
• 昔の esound と diff とったりしてさらに調べた結果、 esound の欠陥(?)らしきものを発見。
• >esound が socket でクライアントから再生データを受けとるとき [players.c:read_player()]、
  1. select で poll する
  2. socket が読み込み可能ならバッファ長分 read
     
  3. (0.2.20 の頃は「読めるだけ読む」だったのだが、0.2.24 ではきっちりバッファ長分だけ読みにいく)
  4. (バッファ長がどうやって決まるのかはややこしそうだから調べてない)
  という動作をしている。
  よって、クライアントからバッファ長に満たない分しかデータを送らないと、 esd が read で止まってしまう。 当然ながら、この状態だと esd が他のクライアントからのデータを処理できないので、 他の esd クライアントも動作できなくなる、というわけか。
  …… 悪用すると esd に DoS 攻撃できないか? これ。 まぁ普通は認証ではねられるから大丈夫だろうけど…
• とりあえず、xkanon 側でブロックサイズ(ESD_BUF_SIZE) 分バッファリングしてから esd に送るように改造してみる…… 直ったようだ。
• しかし、以前の周波数変換のヘタれ具合といい、de facto standard(?) にしてはいろいろ不備の出るソフトだなぁ < esound
• さらに調べたら、0.2.22 あたりで socket からの読み込みを「バッファ長分きっちり読む」 ように「改良」してくれたようだ。 この「改良」した人もアプリケーションに xmms とか esdcat とか mpg123 とかの「ストリーム垂れ流し」アプリケーションのことしか考えてないっぽいし。
• 普通に音声ファイルを再生するだけなら、 「書けるだけガンガン書いて、全部書いたら close」 するからこういう仕様でも問題ない (手元で mpg321 や esdcat だけなら問題出なかったのもこのせい)けど、 xkan○n のように再生が断続的におこるアプリケーションだと問題ありまくりだ。 xmms にしても再生中にポーズとかするとハマるんじゃないのかなぁ?
• というわけで、この問題は esound が悪い、ということにしておこう。 esound 直すより xkanon で対処したほうが楽なんだけど。

2002/4/2

DivX 5.0

• DivX5 がいつのまにかリリースされてた。
• 完全にMPEG4互換になったのが最大のウリっぽいが、 かわりに従来の DivX4 と互換性がなくなっている。
• まぁ上位互換はあるので DivX4 でエンコードしたデータを DivX5 でデコードすることはできるが、DivX5 で DivX4 でデコードできるデータを作ることはできないっぽい。
• 別に Windows だけならこれでも困らんのだが、 こっちは Unix (最低限 Linux) で再生できないと困るのである。
• divx.com では今のところ Linux 用の Codec は 4.12 しかないし、 ソース配布されている OpenDivX は 4.0a36 から更新なし (CVS もどっか逝っちゃったみたいだし、 もう開発止まっちゃったのかなぁ…)。
• このまま DivX4 を使い続けるか、あるいは MPEG1 あたりの別の Codec に乗り換える(退化、ともゆーかも…)か、 どうしたもんだろうか。
• …などと考えていたのだが、 ffmpeg(libavcodec) の CVS 版 と mplayer の CVS 版を組み合わせると DivX5 も再生できるらしい、 という情報を入手したので試してみた。
• 結果は…… 成功。これで DivX5 に移行しても安心、かな?

2002/2/28

Windows2000のシステムを丸ごとコピーする(4)

• HDD容量も増えたし、 これでやっと Zwei!! が遊べる … と、上機嫌で CloneCD のセットアップをはじめる (何でセットアップしてるものが違うのかは深く考えないよーに (^^;))
  …… "config.wow システムファイルが MS-DOS または Microsoft Windows アプリケーションに適していません"
  なんじゃこりゃあ?
• 調べてみると、どうも 16bit Windows アプリケーションのエミュレーション環境用の config.sys らしい < config.wow
• 新 HDD の中にはそんなファイルはない。 で、元 HDD の中を探してみると… \winnt\system32\config.wow とかいうファイルがあった。 元 HDD からコピーしてやると解決した。
• しかし何で新 HDD にコピーされてなかったんだろう…… あ、除外パターンの "C:\WINNT\system32\config" にひっかかったのか!! うわー、あぶねー。 "C:\WINNT\system32\config\" って最後に \ つけとけばよかったんだな。
• で、結局 Zwei!! はインストールすると CD-ROM なくても起動できるので、 CloneCD/DaemonTools の出番はなかったのであった (^^;)
  (まぁフルインストール1.3GBとかいう上にCD-ROM のイメージまで入れさせられたら、いかに増量したマイノートのHDD とはいえ辛いわな)
• それにしても、CloneCD のインストーラが未だに 16bit アプリケーションだったとはねぇ……
  世間一般的にもまだ 16 bit アプリケーションの「新作」 って出てきてるもんなんだろーか…

2002/2/26

Windows2000のシステムを丸ごとコピーする(3)

• xcopy で /C スイッチをつけずに C: の中身を新HDDの C:(になる予定のパーティション)にコピー。 「共有違反です」と言われてコピーできなかったファイルは /EXCLUDE スイッチで除けていく
  
• /EXCLUDE スイッチって「除外パターンそのもの」 じゃなくて「除外パターンを書いたファイル」を指定するのか。 ヘルプじゃわかりにくいなぁ……
  → 最終的な exclude ファイル
• コピーできなかったファイルは:
  • システムレジストリハイブ
  • Administrator のユーザレジストリハイブ
  • Administrator の UsrClass.dat (何?)
  • pagefile.sys (スワップファイル)
  • 一部のテンポラリファイル
• pagefile.sys とテンポラリファイルはまぁコピーせんでも大丈夫だろう。 レジストリ関係は「システム状態のバックアップ」 を使ってコピーできる。 問題は UsrClass.dat か。 これも「バックアップ」でコピーできないかな…… おお、できた。
• 念のため ERD を作り直す。
• 新HDDをつなぎかえて起動してみる… わ、boot.ini が元に戻ってて起動しない。 幸い前に書き換えたのが残ってたのでこれを書き戻す。
  (回復コンソールにはなんでエディタがないんだろう?)
• 狙い通り起動するようにはなったものの。 ログオンすると「ページファイルがないか容量が不足しています」 とかいう(うろ覚え)エラー。 で、その後勝手にログオフしてしまう。 Win2k をセーフモードで起動しても同じ。 これでは手のつけようがない。
• もう一回回復コンソールで何とかならんか調べてみる…… と、妙な点に気がついた。
• 現在新HDDの(基本)パーティションテーブルは:
  • #1: Win2k システム(C:, NTFS)
  • #2: Win2k データ(D:, FAT32)
  • #3: FreeBSD
  • #4: 未使用
  となっているのだが、回復コンソールから見ると:
  • #0: 未使用
  • #1: Win2k システム(C:, NTFS)
  • #2: Win2k データ(D:, FAT32)
  • #3: 不明なパーティション(多分FreeBSD用領域のことだろう)
  になっている。何か変だ。 というか、この切り方は昔のHDDのそれではないか?
• まさかと思い、FreeBSD の fdisk を使って パーティションテーブルを1つずらしてみる。こんな感じ:
  • #1: 未使用
  • #2: Win2k システム(C:, NTFS)
  • #3: Win2k データ(D:, FAT32)
  • #4: FreeBSD
• これで Windows2000 を起動してみると…… ログオンできた。 すべて以前と同じように動作してくれるようだ。
• 多分 boot.ini 以外にパーティション情報を直に参照しているデータがレジストリなり何なりにあって、 そこが悪さをしていたんだろうけど、 それがどこかわからない。 レジストリの中だとすると事前に修正するのは絶望的なんで、 手の打ちようがない。結局、 「HDDを移植するときはパーティションの順番は一致させろ」 という結論になりそうだ。 なんだかなぁ。

2002/2/25

Windows2000のシステムを丸ごとコピーする(2)

• コピーできるだけした状態で HDD をつなぎかえて、とりあえず起動してみる。 起動せんだろうけど… ほら。
• でもいくらなんでも「No system disk」は変だよなぁ…… どうも新HDDのパーティションがアクティブになってないっぽい。 GRUB のインストールFDを使って makeactive すると NTローダは起動するようになった (最初にパーティション切ったときにアクテ%#%V$K$7$H$/$Y$-$@$C$?$J)。 当然これでも途中でコケるんだけど、これは予想通りの動作。
• Windows 2000 の CD-ROM から起動して修復セットアップ …… あれ? 何で C: じゃなくて D: ドライブに修復してるかな …… ひょっとして旧HDDよりパーティションが1つずれてるせい?
• 仕方がないので ERD(修復ディスク)の中身と C:\boot.ini を自力でいじる。
  1. ERD の setup.log というファイルの [Paths] セクション。 TargetDevice と SystemPartition の "Partition2" を "Partition1" に修正
  2. boot.ini の partition(2) になってる部分を全部 partition(1) に修正
• この作業、別の Linux マシン上でやったのだが、 setup.log の [Files.WinNt] (←見た感じシステムファイルの一覧と各ファイルのチェックサムが記録されているようだ) に日本語(てゆかunicode?)の部分があって、jvim が思いきり壊してしまったようだ。 setup.log の読み込みエラーで修復セットアップが起動できなくなってしまった。 どうせ日本語の名前のついたファイルなんてなくても起動はできるに違いない、 と踏んで読み込みエラーの出る行を全部削って対処。 ERD のバックアップをとらなかったのは痛いミスだ。
• … で、修復セットアップは通ったものの、 「C:\WINNT\system32\config\system (←システムのレジストリハイブ) が無いので起動できん」 と言われてしまった。 setup.log にもこのファイルの情報は記録されてないみたいなので、 おそらく Windows 2000 は、NT4.0 と違って修復セットアップではレジストリは修復不可能ということなんだろう。 困った。
• …… でも修復ディスク作るときに 「レジストリのバックアップ」とかいうのを一緒にとったな、確か。 あれ使えば修復できるかもしれない。
• やっぱり真面目にコピーできないファイルを探していかないとダメだな、 ということでフォーマットから仕切り直し。
• 戦略としては、
  • C: をコピーできるだけコピーする
  • システム状態のバックアップをとる
  • バックアップを「別のディレクトリ」に書き戻して、 それをコピー
  • レジストリのバックアップを使ってレジストリをコピー
  って感じ。 問題は「システム状態のバックアップ」と「レジストリのバックアップ」 でとれるファイルだけですべてのコピーできないファイルが揃うか、だけど。 これはコピーできないファイルを真面目に検証していかないといけない。
• …… やれやれ、長丁場になりそうだ (やっぱ再インストールしたほうが早かったかなぁ……)。

2002/2/24

Windows2000のシステムを丸ごとコピーする(1)

• …というわけで、 IEEE1394に外付けしたHDDに内蔵HDDの中身を移すことになったわけだが。
• 昔やったときは OS が Windows NT4.0 だったけど、 今回は Windows2000。 ま、基本的な方針は一緒だろうから昔の資料を参考にしながらやるとしようか。
• …今回は対象がノートPCなので、第3メディアを用意する方法は無理。 となると昔教えてもらった修復セットアップする方法になる。
• まずは NTFS の所有権とか ACL とか含めてコピーするツールを用意する必要がある。 NT4.0 のときはリソースキットの scopy.exe を使ったけど、 Win2k ではどうすればいいかな……
• …わ、xcopy に /K(属性もコピる) とか /O(所有権とACL情報もコピる) とか /X(監査設定もコピる) とかいうスイッチがあるよ。 なんだ、これでできるじゃないか。楽ちん楽ちん。
• ……ちょっとつまづいた(/Lスイッチが「コピーされるファイル名を表示する」 だけ(実際にはコピーしない)とは盲点だった(笑)) けど、コピーは終了。 システムドライブにコピーできないファイルが存在するのは先刻承知なので、 エラーを無視する /C スイッチは必須。
• でもこのスイッチ使ってもどのファイルでコピーに失敗したかがわからない。 xcopy の出力をリダイレクトして後で解析しようかと思ったのだが、 これでも肝心のエラーメッセージ(「共有違反です」) がリダイレクトされてくれないのでダメだった (CMD.EXE で標準エラー出力のリダイレクトはできないのかー!!)。
  しかたがない、これは後でディレクトリを比較するか。 コピーに失敗したファイルの数、15。 まぁ頑張れば探せなくはないレベル……だといいなぁ。
• あと問題になりそうなのは…… システムドライブのドライブレターかな。 パーティション構成を前と変えたから (前に問題になった 謎の 16MB パーティションの分をなくしたから)。 ノート購入当時にもこれでハマって再インストールするハメになったしなぁ。
• とりあえず修復ディスクを作って挑戦してみよう…… Windows2000 の修復ディスクは「バックアップ」で作るらしい。
• 実は「バックアップ」で HDD のフルコピーができたりしないか、 と思ったのだが、 通常のファイル/ディレクトリのバックアップはファイルの形で書き出すので今回の目的には使えなさそうだ。
• 念のため、修復ディスクの作成の前に「システム状態のバックアップ」 も新HDDにとっておくことにした。
  …… なんかいっぱい(250MBくらい)書き出してるなぁ。 レジストリハイブとか .ini ファイルくらいかと思ってたのだが、 どうもシステムの DLL とか全部バックアップしてるようだ。
  まぁ今はHDDの容量は余裕ありまくりだからいいけど。

2002/2/22

• 最近部室の CD-R ドライブの調子がおかしいらしい。 何でも B's recorder GOLD で CD-R を焼くと、最後のコンペアの段階で 「コンペアに失敗しました」と言われてしまうらしい。 私が焼くときは何も問題ないんだけどなぁ?
• 検証のため、「コンペアに失敗しました」と言われてしまった CD-R のデータを他所のマシンで吸い出して元のイメージと比較してみる… 問題なし、と出た。 どうも B's recorder GOLD の不具合っぽい。

DAEMON Tools再び

• 最近後輩I君から聞いたのだが、D(isc)Dump のページがいつの間にか消滅してしまったらしい。 DAEMON Tools と組み合わせて仮想CD作るのに重宝していたのだが…
• まぁ手元には DDump のバイナリが残ってるから何とかなってしまう、 ということでしばらく事態を静観していたのだが……
• 先の B's recorder の件で Web を検索している間に Raw CD Copy というソフトの存在を知る。 フリーソフトながら CD の raw イメージの吸い出しと書き込みができてしまうスグレモノ。
• これ DDump の代わりに使えんかなぁ、と思ったのだが、 吸い出した形式が独自形式で DAEMON Tools では扱えないことが判明。 ちぇっ。
• まぁ丁度いい機会なんで、 将来のために DDump を使わずフリーソフトの範疇で何とか DAEMON Tools 用のデータを作る方法を探しておくとしようか。
• コピープロテクトのことはこの際考えないとして、 理論上は raw データを SCSI/ATAPI コマンドを直に叩いて吸い出し、 toc データを生成してやれば必要な情報は揃うはず。
• Unix 上だと cdrtools に入ってる readcd コマンドでできるようなのだが、 あいにく手元のノートPCのは ATAPI 接続の CDROM ドライブなので、 SCSI ドライブでしか動かない readcd コマンドは試しようがない。 OS が FreeBSD なので ATAPI-SCSI 変換もできないし…
  まぁこれは今度部室で試してみるとして、今回は別の方法を試してみるとしよう。
• EAC (Exact Audio Copy) という Windows 用の CD Ripper がある。 本来の用途は CDDA の吸い出しなのだが、 ディスク全体のイメージを吸い出す機能があるらしいのでこれで何とかならんかなー、 と思い試してみた。
• 吸い出し先ファイル名が .wav なので「ダメかな」 と思ったが、案の定ダメだった。 EAC の「イメージ」はあくまで Audio Track 全部をまとめて1つの .wav ファイルとして吸い出す機能であり、 データトラックの部分は除けてイメージ化されてしまうようだ。
• が、EAC のイメージ化機能で作成される CUEシートにはデータトラックのエントリ(のテンプレート) が用意されている。 つまり、別のツールでデータトラックを吸い出してこのCUE シートを適当に修正してやれば DAEMON Tools でマウントできるようになる、というわけだ。
• で、データトラックを吸い出すツールを探してみたのだが…… ありそうでないもんだ。 結局 FreeBSD 上で cat /dev/cd0c してイメージを作った。
  Unix でたったこれだけのことでできてしまうんだから、 Windows 上でも同じことをやるツールなんていくらでもあるかと思ったんだけど。
• このイメージを Windows に持っていって CUEシートを修正。こんな感じ:

  FILE "hoge.iso" BINARY
    TRACK 01 MODE1/2352
      INDEX 01 00:00:00
  FILE "hoge.wav" WAVE ← こっから先は EAC が作ったまんま
    ...
        

• で、この CUE シートを DAEMON Tools に食わせてみる…… 音楽CDとしては使えるようになったが、 CD-ROMドライブを開こうとするとエラーが出て使えない。 FreeBSD 側で loop デバイス使ってマウントできる (…あぁ、正確には Windowsに転送するとき一旦 Linuxホストを中継させて、そのときマウントしてみたので loop デバイスであってます。と書いとかないとツッコまれてしまう(誰にだよ (^^;))) のは確認してあるから、吸い出したデータにミスはないはず。
• …… あ、raw データじゃないからセクタ長は 2352 じゃなくて 2048 になるのか。 しまった。

  FILE "hoge.iso" BINARY
    TRACK 01 MODE1/2048
      INDEX 01 00:00:00
  FILE "hoge.wav" WAVE
    ...
        

  これが正解。
• 今度はちゃんと CD-ROM としても使えるようになった。 あとは昔も問題になったマルチセッションの CD をこの方法で仮想化できるか、だな…

2002/2/20

• 最近 T-gnus の nnshimbun で新たに講読項目を増やした。 impress のとか /.-j のとか ruby のとかその他いろいろ。
• が、そのうちのいくつかが記事を取ってきた後で Emacs がエラーを吐いてくれるので読めない。
• Backtrace を調べると、luna-apply-generic か mime-entity-fetch-field あたりで変になってるようだ。
• flim のバージョンが古いのかなぁ? と思って emacs-w3m のドキュメントを眺めてみたが、 emacs-w3m は FLIM のバージョンに関して特に注記がない。 ということは現行バージョンでも問題なく動くはず……
• …… あれ? なんだこの FLIM 1.14 って…… オフィシャルな最新は 1.13 だと思ったけど…… 誰かが開発版入れたのか? ひょっとしてこのせいで変になってる? …… 困ったなぁ ……

DivXのあれ(5)

• VirtualDub-MP3、私が入手したのは 1.4c をベースにしていて、 オリジナルの最新(1.4.8)より古い。
• そのせいかわからないが、 VBR MP3 な 音声と DivX4 な画像を VirtualDub-MP3 で合成して AVI(1.1) に吐かせると、 Playa でも再生が詰まることがあるようだ。 ソースによるらしく、詰まらず最後まで再生できる画像もある。
• オリジナルの VirtualDub 1.4.8 で WAV 化した CBR の MP3 と AVI 化した DivX4 で合成仕直すとうまく再生できるようだ。
• まぁ30分(賞味20分台前半ってとこだが) もある画像なら VBR と CBR の差など些細なものなのでいいんだけど、 CM とか OP/ED のような短い画像だと VBR も使いたくなるんだよなぁ……
• …… というようなことをチェックするために VirtualDub.org の News を読んでたら、1.4.8 で VBR MP3 を含む AVI ファイルを扱えるようになったようなことが書いてある。 ひょっとしたら書き出しのほうもできるようになって…ないかなぁ (←希望的観測)

• TMPGEnc や VirtualDub から DivX コーデック使って AVI 吐かせるスキルが身について、はたと気付く。 「ひょっとして AviUtl 以外のツールなら Windows XPでも DivXエンコードができるのでは?
• 実験してみる…… ビンゴ！ TMPGEnc と DivX Codec は Pentium4 用の最適化もされてるみたいだから、 これでエンコード作業がだいぶ速くできるようになる。
• まぁ現在一番時間を食っている AviUtl でのフィルタ掛けは、 個々のフィルタが Pentium4 に最適化されてないとどうにもならない。 何せ純粋なマシンパワーでは今の PentiumIII 1GHz と Pentium4 1.4 GHz であまり差がないだろうし。

2002/2/19

DivXのあれ(4)

• フィルタを使うようになってから、 AviUtl & DivX4.12 のコンビが突然破綻する (^^;)
• AviUtl で DivX 4.12 の 2pass モードで AVI ファイル書き出しをすると、 最後の最後(2pass でエンコードが終了した瞬間) にAviUtl が落ちる。 .avi ファイルは残るけど再生不能。
  はぅ、4時間かけてエンコードしたのに……(T_T)
• 最初はフィルタのせいだと思ったのだが、 フィルタを外してもやっぱり同じにようにダメになる。 トホホ。これからどうしよ…
• とりあえず Codec の問題か AviUtl の問題か切り分けるため、 別のソフトを使ってみる…… VirtualDub と TMPGEnc は問題ないようだ。
• とするとやっぱり AviUtl の問題? でもついこの間までちゃんと使えてたのに…
• まぁ何にせよ、AviUtl でフィルタをかけた後で TMPGEnc なり VirtualDub に渡して DivX4 に落とせば OK ってことだ。
• …… この Frameserver って機能はこういうときに使うのかなぁ? …… Web で適当にサーチして調べてみたが、 VirtualDub でこの機能を使うのはどうも使うのは面倒なようだ :-)
• 多分 AviUtl と TMPGEnc の組み合わせでやるのがベストだろう、 というわけでやってみるが……遅い。 フレームレート変換に4時間、エンコードに2時間の計6時間。 まぁエンコードにはフィルタの処理時間も入ってるんだけど。 しかも DivX4 の2パスモードだからこれを2回やらないといけない …… ってやってられるかぁ!
• やはりフィルタかけてフレームレート変換した時点で、 一旦中間ファイルに書き出すしかないだろう。 無論 MJPEG みたいな非可逆の圧縮をここで使うと、 なんのためにノイズフィルタかけたのかわかんなくなるから、 中間ファイルは可逆圧縮でないといけない。 そう、昔調べた Huffyuv や LCL の出番というわけだ。
• しかし可逆コーデックはどうしても生成されるファイルのサイズが MJPEGより大きくなるから、HDD容量が保つかどうか… よし、実験して$_$k$+!#
• というわけで適当にTVから取り込んだCM(15秒)を使って実験。 結果はというと、
  
  1. MJPEG : 21MB
  2. Yuvhuff(yuy2変換) : 28MB
  3. AVIzlib(Hi Compress,YUV4:2:2,PNGfilter) : 34MB
  4. Yuvhuff(デフォルト) : 44MB
  5. AVIzlib(Hi Compress,YUV4:2:2) : 45MB
  6. AVImszh(YUV4:2:2) : 61MB
  7. AVIzlib(Hi Compress,RGB) : 66MB
  8. AVImszh(RGB) : 99MB
  という感じになった。 Yuvhuff の yuy2 変換付き(←ほんのちょっと lossy っぽいけど) なら MJPEG の 3〜4割増し程度に収まるようだ。 音声は別に MP3 エンコードできるから、これなら何とかなりそうだ。
• 今回の計画(あくまで予定):
  1. AviUtl で取り込んだ .avi ファイルを編集 (連番AVIの連結とCMカット)
  2. プロジェクトを .aup に書き出して保存
  3. 保存した .aup を TMPGEnc に食わせる
  4. TMPGEnc でノイズフィルタと24fps化(自動設定: 24fps化(ノンインターレース用)) と音声の正規化とクロップ(上下左右の欠けを削る)
     (24fps化と正規化は TMPGEnc でやったほうが速くて正確っぽい。 クロップも TMPGEnc のほうがやりやすいと思う。 ノイズフィルタは TMPGEnc と AviUtl の両方でかける)
  5. .tpr に書き出し
  6. .tpr を再び AviUtl に食わせる
  7. AviUtl でノイズフィルタとかいろいろフィルタをかける
  8. 画像のみを Yuvhuff(yuy2変換) で中間 AVI ファイルとして一旦書き出し (書き出し時間約3時間)
  9. 中間ファイルを書き出してる間に音声の準備をする (4. から分岐)
     1. TMPGEnc で音声を .wav (PCM16bit,44.1kHz) で吐かせる
     2. lame で .wav → MP3(44.1kHz,96kbps) にエンコード
     3. mp3wrapper で MP3 → .wav (MP3) に変換
  10. 中間ファイルを TMPGEnc に食わせ、 DivX エンコード(first pass) で AVI ファイルに出力する。 このときはまだ画像のみ
  11. エンコードしておいた音声を読み込む
  12. DivX エンコード(second pass) で AVI ファイルに出力する。 今度は音声付き
  13. できあがり!
• …… う、TMPGEnc は普通に映像ソースと音声ソースを指定した場合、 AviUtl みたく「無変換」という選択はできないのか。 というわけで、DivX の画像ファイルだけ2回書き出して、 音声との合成は VirtualDub でやるとしよう。
• …… しかし DivX の圧縮も速くなったなぁ。 1年前は1pass当り1時間かかってたのが、 今じゃ20分足らずでできてしまう。 DivX コーデックが SMID とかに対応した成果なんだろうな (まぁ画像と音声を別々にエンコードするようになった、 っつーのもあるだろうけど)。
• あと Web を調べていたところ、 「VirtualDub-MP3 を使うと VBR の MP3 も AVI に合成できる」という情報が。 やってみよ……
  おお、できた。すごい。
• FreeBSD+xine でも問題なく再生できるみたいだから、 今後はこれでいくか。
• 注意: VirtualDub-MP3 は一次配布元が lost しているようなので、 入手するときは適当にサーチエンジンで二次配布してるとこを探すこと。
• 今回見つけた有益なサイト:

  labdv.com

  DV,キャプチャ,動画編集関係の色々なツールがリストアップ・ ミラーされている。VirtualDub-MP3 も置いてあるようだ。

• …… 問題発覚。 例によって(!) WinXP の WMP(8?) で再生できない…
  はぁ〜、とことん腐れとるなぁ > WinXP
  もう無視だ無視! Playa (← DivX.com で配布されてる DivX 標準プレーヤー) で再生できればOKなことにしとこう。

2002/2/18

Emacs21

• 最近自分のノートPC(FreeBSD)の emacs 環境を 20 → 21 に移行した。
• 大きさの違うフォントで交ぜ書きできたり (Info を読んでみると効果がよくわかるっす)、 kterm の上から -nw で起動しても色が出るようになったり (mule 2.3 の terminal face が 21 になってようやく本家取り込み?)、 X 上で起動すると物理行の折り返しが \ じゃなくてアヤしいグリフで表示されるようになったり、 とアヤしい機能が満載。 その割に 19 → 20 のときほど重くなってないみたいだし (自分の使ってるPCのパワーがありすぎるのかもしれないけど)。
• が、teraterm と組み合わせると変だ。 TERM=teraterm や TERM=kterm だと色が変でまっとうに使えない。 色使いが非常識とかいう以前の問題で、 同じ face であるはずのフォントが一部だけ背景色がついたり反転したり…
• TERM=vt100 にすると一応まともになるようだ。 強調/反転/下線しか使えなくなるけど。

2002/2/17

DivXのあれ(3)

• やっぱりいた同好の士 :-)
• すげぇ、この人真面目に AviUtl のフィルタ使っとる… ちょっと参考にさせてもらおう…
• というわけでまたまたエンコード、 といっても今回はいつもの「30分アニメ」の圧縮ではなくて、 OP/ED 部分だけの圧縮。せめて OP/ED くらいは高画質にしとこう、というわけだ (^^;)
• 先のページを参考にしながらフィルタをかけてみる… だいたい AviUtl の画像フィルタは、
  1. 入力の不備を補うためのフィルタ
  2. 入力の形式を変換するフィルタ
  3. 圧縮や縮小による画質低下を抑制するためのフィルタ
  に分類できるようだ。
• 「30分アニメ13話を1枚のCD-Rに焼く」 とかいう無茶な圧縮をするならどれも重要そうだけど、 今日のは Quality Base で 90%超の高品質圧縮にする予定なのと、 大量のフィルタを一度に扱いきれるほどのスキルがない、 という理由から、ウェーブレット・ノイズフィルタと(普通の) ノイズフィルタをかけるだけにしとく。
• これだけでも画像に入ってた縞々なノイズが取れて大分見栄えが違う。 うーん、知っとけばもっと前からやっといたんだけどなぁ。
• ただ、ウェーブレットノイズフィルタの数値は微調整してもあんまり効果が出ない。 というか、設定値を全部最大に振り切らせてもゴミが取りきれないのでどうしようもない。ノイズフィルタと組み合わせたらほとんど消えたけど。

2002/2/16

DivXのあれ(2)

• lame を最新版 (3.91) に上げた。 せっかくだから何か圧縮してみよう… おお、こんなところにこの間キャプチャしたばかりの某鍵アニメの第一話が :-)
• これを圧縮してみよう。 画像パートはいつものように DivX4 で圧縮。
• 音声パートはこの間会得した分離& 合成テクを使って lame でエンコードしたものを使う。
• せっかくだから ABR でエンコードしてみよう、と思ったのが失敗。
• ABR の RIFF MP3 と DivX4 を AviUtl を合わせてみたところ、 合成した AVI ファイルは問題なく生成されたものの、 いざそれを再生してみると音声と画像の同期がまるで取れてない… 敗北。
• 結局 CBR で MP3 をエンコードしなおして再合成。 ちなみに今回はちょっとゴージャスに動画 192kbps、音声 96kbps に設定してある。1話だいたい50MBくらい。 700MB メディアを使うことを前提にして、 1枚のCD-Rに13話が入るくらいのクオリティだとこんなもんだろ。
• MP3エンコードのために Unix にデータを毎回転送するのもアレなんで、 Windows用の lame バイナ%j$r%S%k%I$7$F$_$k!# 「VC++用のプロジェクトファイルがあるよん」 と INSTALL には書かれてるのだが… どこの dsp を使えばいいんだ?
• 結局 frontend/lame.dsp が正解だったっぽい。 あと nasm がパスの通ってるとこに必要っぽい。 C:\winnt の下にコピー、ってのも何だし、 かといって Program FIles の下だとパス通すのめんどいし… 結局 libmp3lame/ の下に直に nasm.exe を置いてコンパイル。 まぁ、いいか。Windowsプログラミングは専門外だから (^^;)

2002/2/10

共有メモリとロック(2)

• 「mkstempか何かでサイズ0のテンポラリファイルをopenして、 ファイルをすぐunlinkしてしまう」方法。
• ファイルを消しても fd は生きてるから、 この fd に対して flock なり lockf なりでロックをかければいい。
• この方法なら、semget と違って自分とその子プロセスからしかアクセスできない。
• そして何といってもファイルはプロセスが終わればカーネルが勝手に消してくれるから semget のように消し忘れの心配がない(笑)
• 欠点は descriptor を無駄に一個消費すること、かな?
• まぁ fd なんて semaphore に比べたら無尽蔵に使える資源だから些細な問題ではある。

DivXのあれ

• 最近作り溜めた DivX+MP3 な動画像データが部員の間に広まってるらしい
• …で、「画像はともかく音が悪い!」と言われてしまった…
• といっても、Windows 標準の MP3 Codec (聞いた話だと Fraunhofer の IIS MPEG Layer-3 Codec の機能制限版らしい) だとエンコード時の品質は 56kbps が上限なので、 これ以上のビットレートでエンコードするには音だけ別のソフトで MP3 encode して後で動画と合成する必要がある
• …まぁおもしろそうだからやってみようか (^^;)
• AVI の編集ソフトにはたいがいアフレコ用(?)に 「音声部分を別ファイルから取り込む」機能が付いてるので、 これで合成してやればいいわけだが、 たいがい .wav ファイルでないと受けつけてくれない。
• たしか中身が mp3 で RIFF ヘッダだけつけたような .wav ファイルってーのが世の中にはあるみたいだから、 手元の .mp3 ファイルに RIFF ヘッダ付けて .wav 形式にしてくれるようなソフトもどっかにあるよなぁ? …というわけで「教えて! google 先生」:-)
• わかったこと。 一般にはこの「中身が MP3 の .wav ファイル」 は "RIFF MP3" とか "RMP" とか呼ばれてるようだ。
• 生の .mp3 ファイルと RIFF MP3 の相互変換専門のソフトはあんまりないみたい 唯一見つけたのが WaveMP3 というソフトだけど、 これは一次配布元がどっか逝っちゃったみたい (欲しい人はサーチエンジンでコピーを探そう)。 うーん、今後のバージョンアップが不安だなぁ。
• 変換専門のソフトはないけど、 ID3 タグ編集ソフトの中には生MP3 ⇔ RIFF MP3 の変換機能を持ってるソフトがいくつかあるみたいだ。 有名どころだと SuperTagEditor (とその variant)とか。
• というわけでソフトを取ってきてチャレンジ!
  1. AviUtl で動画を編集。ここまでは普段と一緒
  2. AVI出力で「音声無し」にして動画部分のみ (DivX で圧縮)の AVI ファイルを作る
  3. 「WAV出力」機能を使って音声部分だけ切り出した WAV ファイルを作る
  4. WAV ファイルを Unix マシンにコピーして lame で MP3 エンコード
     (Unix に持ってったのは単に私が使い慣れてて、 コピーの手間暇を入れても Windows 上でやるより早い、 というだけの理由。普通の人は適当な Windows 用の MP3 エンコーダで圧縮しませう)
  5. できた MP3 ファイルを Windows マシンに戻して、 SuperTagEditor で開いて RIFF MP3 に変換。 変換すると元ファイルが上書きされるので要注意。
  6. 変換したファイルを .wav にリネームして AviUtl の「音声読み込み」で食わせ… たらエラーになった(T_T)
  7. この .wav ファイルをメディアプレイヤーに食わせたら正常に演奏してくれるんだけどなあ? 何でだろ?
  8. もう一度生 MP3 を Unix からコピーし直して、 今度は WaveMP3 で変換してみる。
  9. WaveMP3 は変換すると .mp3 → .wav に名前を変えたファイルを新しく作ってくれる。 この .wav ファイルを AviUtl の「音声読み込み」で食わせる。 今度はうまくいった。
  10. 「AVI 出力」で画像音声共「再圧縮なし」を指定して AVI ファイルを吐かせれば合成完了!
• しかし何で SuperTagEditor での変換ではうまくいかなかったんだろう? 使い方がまずかったんかのう。 ドキュメントをよく読んでみよう…
• …「MP3 について」という解説ページでとんでもない事実が判明。 「RIFF ヘッダ付 MP3 ファイルには2種類ある!」
• ファイルをダンプしてみたところ、 WaveMP3 が変換してくれるのは上のページでいうところの "RIFF WAVE 形式 MP3" で、SuperTagEditor が変換するのが真性の "RIFF MP3 形式 (RMP)" だったようだ。 つまり RIFF MP3 じゃなくて RIFF WAVE 形式でないと AviUtl に食わせることはできない、ということか?
• さて、RMP じゃなくて RIFF WAVE と生 MP3 の相互変換ができるソフトが一次配布元のない WaveMP3 だけ、というのは不安なので他にないか探してみよう…
  YunaSoft の MP3 Wrapper で MP3 → RIFF WAVE 変換ができるようだ (「WAVE format」にチェックを入れるのを忘れずに、と)。
• ちなみに同じ YunaSoft の MP3 Encoder 98 という別のソフトに 「RIFF MP3 to MP3 コンバータ」機能があって、 これを使うと RIFF WAVE/RIFF MP3 を生の MP3 に戻せる。 MP3 Encoder 98 の本来の機能である PCM の WAV ファイル → MP3 のエンコードはレジストしないと制限がかかるが、 コンバータ部分だけ使う分には未レジストでも OK のようだ。
• ん? MP3 Encoder 98 のヘルプに RIFF MP3 の技術情報があるな。 …… RIFF WAVE は MP3 形式の WAV そのものではなく、 MP3 形式の WAV に IDtag 相当の情報を埋めこめるように LIST chunk を付加した、303tek と YunaSoft の独自拡張、 RIFF MP3(RMP) は RIFF WAVE から fmt chunk を省いた(やっぱり)独自拡張らしい。
• まぁ今回は MP3 形式のまま .wav の体裁の整ったファイルが作れれば OK なので、拡張云々に関してはどうでもいい話だけど :-)
  実際 MP3 Wrapper で変換した MP3 形式の .wav でも問題なく AviUtl で合成できたし。

2002/2/5

共有メモリとロック

プロセス間で共有メモリ空間を作成する方法としては、

1. SVR4由来の共有メモリ(shmget/shmat/shmdt)を使う
2. mmap を MAP_SHARED オプションを付けて使う
3. POSIX の共有メモリライブラリ(shm_open)を使う

で、共有メモリ空間はこの方法で作れるけど、この空間へのアクセスに排他制御を かけたいと思うとはたと困ってしまう。 Unix でロックというと flock とか lockf とかのファイルへのロックがあるけど、 これはファイルがないと使えない (テンポラリファイルを作って mmap する方法だとこの方法でロックできるんだけど)
では他の代表的なロック… mutex とか semaphore とかはどうか? POSIX に semaphore 関係の関数(sem_open/sem_init etc.) があるのでこれが使えるか、というと… FreeBSD では未実装、あるいは実装されてるけど「プロセス間で semaphore の共有はできません」とか書いてある(4.4R のマニュアル)。 Linux でも(そしておそらく他のフリーのPC-UNIXでも)状況は似たりよったりっぽい。 プロセス間で共有できなきゃ何のための semaphore やねんっ! とツッコミたくなってくるが、まぁ thread 間で使え、ということなんだろう。 …ってことは fork() するんじゃなくて pthread 使ってマルチスレッドにする しかテがないってことですカ!? あるいは共有メモリ使って排他制御するロジックを自分で組めと!? (メンドクセー)

… というとこで「何でこんな需要のありそうなもんが標準ライブラリにないんだろ」 と思って WWW で何か定石がないか探してみると… MM という共有メモリのライブラリを発見した。 共有メモリにロックをかけることもできる。 まさに私が求めていたライブラリである。

で、この MM がどうやって lock をかけてるのかを見てみると… ファイルがあれば flock を使うけど、ない場合は semaphore を使ってるっぽい。 といっても POSIX の semaphore ライブラリじゃなくて、 SVR4 由来の semget/semop のほうを使うようだ。 …そうか、こっちの semaphore だと FreeBSD や Linux でもプロセス間でも共有できるのか。じゃあ何で POSIX の semaphore ライブラリをこれで実装しないんだろう? 謎だ。

結論: POSIX並に互換性の高い関数でロックできる共有メモリを作る一般的な方法は ないらしい。
…うーん。

でも SVR4 の semget とか shmget って key が 分かれば他所のプロセスからもちょっかい出せるっぽいよねぇ。 自分的には「自分とその子プロセスでだけで使える共有メモリ」 が欲しいんだけど、できるのかな… まぁどっちも普通のファイルシステムっぽい permission の設定はできるみたいだから、すくなくとも他人にイタズラされる心配は なさそうだけど。