昨日は酷い目にあった。完成した PC に入れる定番オンラインソフトの数々をダウンロードして CD に焼いて帰ろう等と考えていたために１１時過ぎまでかかってしまい、しかも大学から外に出てみたら雨が降っているときた。
どうしてこういう目にあうのか……。
傘など持ってきていないので仕方なく自宅までの３０分間、ぬれるのを我慢して帰ることにした。
しかも今朝は１限から講義があるというのに……。大体どうして１限からしかも一般教養科目で出席をとったりするのだろう。
さぼり続けている専門科目の方でも中間テストがあるとかいうし……。
最近不真面目な生活を送っているからそのつけが回ってきたのかなぁ。
nVIDIA 128 のビデオキャプチャは順調に動いているようだ。
何故か 32bit カラーモードや水平周波数 85 kHz の 1152x864 では動かないようだが、なに取り込むときだけ 16bit カラーに切り替えてやればよいのだから問題ない。
うーん、良い買い物をした。キャプチャデバイスと VRAM 4M で７千円以内に収まったのだから。
しかし 10 秒取り込んだだけで 70M か……ディスクはいくらあっても足りないな、こんなことを始めると。
MO か CD-R 、あるいは DVD-RAM が欲しくなってくる。（一気に貧乏になったくせに何を言っているのやら）
とりあえずはビデオとサウンド関係のケーブル（長さは余裕を見て 5m 程度）、ついでに適当なスピーカーを仕入れたいのだが、これは２千円以内で収まる物なのだろうか？
いい加減ケーブルの長さを気にしながらヘッドホンで音を聞くのはつらいと感じ始めたのでスピーカーも欲しいのだが、これを言い出すとちょっと２千円以内では無理に近いのではと思ったりもする。
まあそんなことは物を見てから考えればよいことだ。どうせ時期を待つ意外に対策など取れないのだから。
昨日 PCG-723 の CD が実家から帰ってきた。ただ、やはりというか予想どおりというか、帰ってきたのは１０月に生まれたばかりの別人であった。
まあこの前電源が入らなくて問い合わせた時と比べれば比較的早く帰ってきたから良いと思うことにしよう。
異様に寒い。こんな日に好き好んで外に出かけるのは馬鹿か変態だけだというわけで大学はサボることにした。
今日量子力学で中間があるとかないとかいう話も聞いたのだが、どうにもやる気が出ない。
まあ後期に入ってから出たのは最初の２回だけなのでいい加減切ってしまっても良いだろう。（確か単位は足りてるはずだし）
で、大学をさぼって何をしているかといえばキャプチャデバイスと戯れているのだ。
とりあえず、ASUS のホームページからドライバと対応アプリの最新版を落としたので、それを入れてみたところ（ホントは最初からできたのかもしれないけど）MCI デバイスとして普通に他の（付属で無い）アプリからもキャプチャ出来るようになった。
さらに Microsoft が無料で配布してる NetShow On-Demand Producer のベータ１を入れたところ、MPEG4 の codec も入ったので、その他のものと比べて圧縮率や画質などを比較してみようかとも考えている。
んー、MPEG-4 も結局期待外れかもしれない。確かに奇麗で圧縮も早く、サイズも普通に小さくなるのだけど、処理が重いようでノーマルサイズで再生していても時々コマ落ちが発生する。（CPU: K6-2 300, Mem: 128M, GA: ASUS V3000(nVIDIA 128, 4M) での実行結果）
もう少し再生用 codec の最適化が進めば多少はこれも改善されるのかもしれないけど、現段階では Intel の Indeo 5 を使っていた方が良い結果が得られるような気がする。（圧縮率をもっと上げてみると違う結果が出るかもしれない）
午前中サボる予定は無かったのだが、何故か私が意識を取戻したときは１２時だった。
というわけで結果的に午前中の講義をサボることになってしまった。
２週前に提出しなければいけないはずのレポートを提出していないのでこんな事をしてよい訳もないのだが、まあ過ぎてしまったことは仕方がない。
本日のインストールソフト。
Intel Indeo developer kit、カノープス Motion JPEG Playback Codec、Opera、Meadow 1.01
あと、dsp98 も入れてみようとしたのだが起動直後に「リソースファイルが見つからないので安全のために終了します」と言って終了してしまう。
まあ、それはそれとして Indeo の開発キットと Motion JPEG の再生 Codec は最近動画にはまっているからなのだが、Opera は……、こんなものを試そうとするのはよっぽどの変人だよなぁ。
とりあえず日本語が表示できるか試してみて、出来るようならちょっと使ってみようとしたところ、力技を使えば何とか日本語を表示できることは確認できた。
ただし、表示できるのは SJIS のみで、しかも２バイト目が HTML での特殊文字の時にはあちこちで表示が崩れたりする。
動作は軽くて快適なので結構気に入ったのだが、これを常用するのは少しきついと感じた。
ので、３０日目の試用期限切れを待たずにアンインストール。
次のバージョン（4.x）が出たらまた試してみることにしようと思う。
で Meadow 1.01 だけどこれは今まで使ってた 1.00 からのバージョンアップ。
とりあえず問題は発生していないから古いままでも良いのだけど、ちょっと Meadow の設定の変更方法を調べようとしていたら、たまたま新しいバージョンが出ていると知ったのでついでにやってしまうことにした。
ちなみにその知りたかったこととは、表示フォントの設定変更方法である。
今までは ノートパソコンの 800x600 画面で使っていたから丁度良い .emacs ファイルを発見して、それをそのまま利用していたのだけど、自作機の広い画面では今までの設定では字を読むのがつらく、もう少し大きくしたいと考えたのだ。
ただ、何をどうすれば良いのか大体判ったつもりなのだけど、実際にいじってみると妙な表示にしかなってくれないので、とりあえずはデフォルトのフォントに戻して使っている。
欲を言えばもう少し行間を広く表示したいし、ASCII 文字と日本語のバランスももう少し何とかしたいと考えているのだが、しばらくはこのまま使うしかないようだ。
どこぞにスクリーンショットと .emacs のサンプルでも公開していればそこを参考にするのだが……。
今日のところは丁度良いものを見つけることが出来なかった。（EmEdit で妥協すればこの辺はもう少し楽になるのだろうなぁ）
現在奇妙な現象が発生している。
Meadow を起動して文章を編集し、保存してから終了すると、それ以降 Explorer（= Windows）の挙動が奇妙になるのだ。
アイコン名の表示が妙になったり、キーボードの入力と実際の動作が食い違ったり。
どうにも再現性が無いので困っている。（再インストールは嫌だしなぁ）
とりあえず再起動すれば直るようなのだが、ファイルを一つ編集するごとに OS を再起動するのは遠慮したいし……。
一度起動したら Meadow を閉じなければ良いと言う意見もあるかもしれない。
まあ、閉じなくても困ることは無いのだよな、実際。
で、最近はまってる動画圧縮の話。
Indeo は フレームの縦横のピクセル数が４で割り切れないと圧縮できないらしい。なんとなく Duck の Ture Motion と挙動が似ているが、きっと同じようなアルゴリズムを使っているのだろう。
しかし、原因に気がつくまでは今まで普通に動いていたのにどうしてこんなことが……とパニックを起こし、一時は windows の再インストールを考えたほどだった。
まあ、それに似たようなことはしてしまったけど。
とりあえず原因さえ判れば解決策も浮かぶわけで、ビデオ信号から取り込んだときに入ったノイズを除くため、上の 2pix だけを間引いていたのを下の 2pix も間引いて結果４で割り切れるようにすれば順調に圧縮できた。
しかし動画をあれこれと扱っていると、この辺の詳細や Codec の入手元などについて詳しく書いてあるページが欲しくなってくる。
どこかに在れば良いのだが、多分在ったとしても英語なんだろうなぁ。
珍しく実験のレポートをやる気になったので手をつけているのだが、どうしてこうちっとも進まないのだろう。
さっきから数行打っては休み、また数行打って休むということを繰り返している。
おまけに、考えている時間が長すぎてうっかりスクリーンセーバーが動きだそうものなら、ついつい３周分ぐらいそれに見入ってしまうためにさらに作業が遅れると来ている。（ちなみに現在のスクリーンセーバーは AVI Screen Saver で、ソウルハッカーズ、バブルガムクライシス、ガサラキ、守護月天のオープニングが登録されている）
実際考えていても課題は相変わらず良く判らないし、考察には当たり前のことしか書けないし……、やっぱり書かされてるという感じがすべてを邪魔しているような気がする。
まあ、結果がでて書くことがあるのだから良いじゃないかと院生の方達は言うだろうけど、だれかの思惑通りに動かされるのはやはり気に食わない。
実験のレポートというものに意味を見出せないだけに、今やっていることが穴を掘っては埋め戻す作業のように思えて実際嫌になってくる。
大体、正答が用意されてる考察ほど馬鹿らしいものは無いよなぁ。
あー、いくらここに愚痴を連ねても結局書かなきゃいけないのだけどね。
多少はストレスの解消につながるから良いか。
物欲その１。
RGB 24 bit, 30 fps, 320x240 pix でドロップフレームなしに取り込み可能なビデオキャプチャデバイス。
最初は 640x480 でとか考えていたのだが、それだと１分間で 1G を超えることが判明したので 320x240 に要求を下方修正した。
とりあえず nVIDIA の無印 128 (AGP x1) では VfW から利用する限り 24 bit, 15 fps が限界のようなので 30 fps で取り込めるキャプチャが欲しいと考えているのだ。
とりあえず今あるものでも、16 bit に落とせばぎりぎり 30 fps も行けそうなのだが、それでも数フレーム取りこぼすことがあるし、何より 16 bit だと色の差が大きいため、本来なら人間の目では気づかない程度の色のぶれを判別できる程度に拡大してしまうのだ。
これは小さなぶれが出るのは当たり前のアナログ信号を扱う上では致命的なことである。
ので、24bit でどこまでなら行けるのかと試してみたところ、24 fps で取り込んだ際のドロップフレーム等を計算するとどうも 15 fps が限界のようなのだ。
うーん、これをやろうとしたらキャプチャのほうに手を入れるよりも、システム全体に対してパフォーマンスを底上げしなきゃいかないのかもしれない。
メモリの追加とか RAID の SCSI Ultra-WIDE 2 ディスクとか……。
特にディスクのほうが問題があるかもしれないなぁ。今使ってるのは 5400 rpm の IDE ディスクだから。（一応 DMA/33 は有効になってるはずだけど）
しかし、ディスクのパフォーマンスを劇的に変えるとするとやっぱり上で書いたような選択肢しかないのだろうけど……。
半端じゃなく金がかかるからなぁ、それをやろうとすると。
というわけでこれはまあ保留しておくことにして、物欲その２。
640M の MO ドライブ、もしくは書きこみ 2 倍速の CD-R ドライブ。もちろん余計な出費は避けたいので IDE 接続の方が望ましい。
大学とのファイルのやり取りや作成した AVI のバックアップ等が目的なのだが、そうするとやはり MO か CD-R ということになる。
使いやすさなどを考えれば MO の方が良いのだが、大学とのデータの移動ということを考えないとすれば CD-R の方がまだ将来性があるように思えてきて迷っている。
まあしばらく金を貯めないことにはとてもこんな出費は出来ないのだけど、どうも金の無いときに限って物欲というのは膨張するから困る。
やっぱり 24bit で 30 fps が出ないのはキャプチャデバイスの制限なのだろうか。
Microsoft が配布している On Demand Prodecer に付属のキャプチャソフト（やっぱり VfW 経由で取り込みを行うソフトなのだけど）で copy to memory という設定があったのでそちらを選択してみても数１０フレームの段階からドロップフレームが発生してしまう。
でもあれはかなり動作が怪しいソフトだからなぁ。
ASUS が提供しているソフトもいまいち動作が判らないし。（Live 3000 というものなのだけど、YUV9 と RGB 24 のみ対応で大体 24 fps 前後で取り込めるんだよなぁ）
うーん、ここはやはりハードディスク関係のベンチマークを探してきて、どの程度の転送速度があるのか確認してみるべきなのかなぁ。とりあえず 30 fps で取り込もうとしたら秒間 8M は確実に必要になるのだから。
それにしても今度は SCSI のホストアダプタが必要になるのか……、ディスクは以前ノートから試用していた Ultra (Narrow) の 2G があるからとりあえずそれで試すことにして……、誰か知り合いで Ultra SCSI 対応の PCI ホストアダプタを余らせている人は……居ないのだろうなぁ。
やっぱり長時間録画する訳ではないのだから、30 fps（正確には 29.97 fps）欲しいよなぁ。とりあえず私の使用目的だとキャプチャするものは長くても２分程度なのだから。
nVIDIA が配布している RIVA 128 用の新しいドライバ (2.77、ASUS の最新版は 2.50 使用) があったので、3DNow 対応というコピーに引かれインストールしてみたのだが、普通に動くもののディスプレイから設定、詳細と進むと RunDLL のエラーで設定できず。
おまけに VfW の動作が怪しくなったので慌てて元に戻すこととした。
やっぱりチップ開発元のドライバはいざ何かが起こったという時になっても文句は言わないか笑って許せる状態じゃないと試すべきでは無いと痛感した。
本日のイロモノインストール。
Paradigm Matrix M-JPEG Codec (Secondary) (Expires Feb. 1, 1998)
体験版のソフトウェア Motion JPEG codec という恐ろしいものである。
24bit 30fps での取り込みの際のドロップフレーム問題がハードディスクへの書きこみ速度にあるのなら取り込みと同時に圧縮して書きこんだらどうなるだろうと考えて試してみたのである。
結果はかえってドロップフレームが増えてしまった。圧縮技術としては比較的シンプルで早いと噂の Motion JPEG だからとすこし期待していたのだが、やっぱり取り込みの際に併用して使い物になるのは専用チップを利用したハードウェア圧縮の場合だけだという事なのだろう。
肝心の画質のほうもどうも今一つであったので。これも使用期限切れと同時にアンインストールかもしれない。（そう言えば無圧縮で取り込んだものを圧縮する場合はまだ試していなかったような……）
とりあえず AVI の圧縮に関しては Indeo 4 が最高というのが現時点での評価である。
さて、HDBench が手に入ったので動かしてみたのだが……。
「24 bit で 30 fps が出ないのはディスクがボトルネックになっているはず」という推測が正しければ、5 M/sec 程度の性能しか出ないはずと予想していたのと近く、512M の Read/Write テストで Read 9081 k/sec, Write 6711 k/sec しか出ていなかった。
Write 6711 k/sec で 24 bit, 15 fps が安定しているということは、えーと３掛け１５掛けの……、音も同時に取り込んでるから、理論上必要な速さが 3.76 M/sec になって、大体理論値の 1.7 倍は出なきゃまずいという事になるのかな？
とすると、30 fps をやろうとすると、書きこみで 13 M/sec が保証されているディスクが必要になるのかな？
なんか変だな、音も同時に取り込んでいるにしても、オーバーヘッドが７割も存在するのか？
これは 16 bit ソフトの VfW の限界が出ていると考えた方が良さそうだ。
えーと、ASUS 提供のキャプチャソフトだと 24 bit で大体 24 fps を達成できるから、これに必要なのは 5.94 M/sec。うん、こっちのほうがベンチマークの値と近い。
とすると、この場合オーバーヘッドは２割以内だから、9 M/sec のディスクを用意すれば 24 bit で 30 fps が達成できるのか。
これなら余り出費は必要としない気がする。
Ultra SCSI なら 20M/sec が上限のはずだから、問題は今持っているディスク（１年前購入の 2G）がどれほどの性能をもっているかだな。
実験のレポートをやろうと思っていたのだが、昨日本を借りてくるのを忘れてしまったので、C++ Builder と戯れていた。
ファイル選択欄を持ったちょっとしたソフトを作ろうとしているのだが、どうしてこう手ごろなコンポーネントが標準では用意されていないのだろう。
作りたいのはドライブ・フォルダ選択用の履歴付テキスト編集欄とファイルリスト表示欄を持ったシンプルなものなのに、どうしてこれを用意しておかないのか理解に苦しむ。
そこそこ需要はあるだろうから、多分海外のページも含めて丹念に探せば公開コンポーネントが幾つか見つかるだろうけど……。
ま、いいや。明日実験終了後に探してみることにしよう。あっさりと見つかれば嬉しいのだが……。
結局昨日は都合の良いコンポーネントを見つけることが出来なかった。
仕方が無いので、とりあえず見つけた中では一番使えそうだった Rx Library 2.50 の DirectoryEdit と Win32 コンポーネント内の ListView を組み合わせて何とかすることにした。
作成する物の大体の方針は決まってデザインも固まったので実際に各イベントごとのコードを書き始めたのだが……、クラスもスコープも継承が判らないと、C++ も C も変わらないということに気がついていしまった。
さらに GUI の宿命なのだろうか、イベント駆動型のアプリケーションであるため、関数以外では絶対に使うものかと決めていたグローバル変数を幾つか使う羽目に。（C++ をきちんと勉強すればこの辺は使わなくても済むようになるのだろうなぁ）
やれやれ。
どうしてこう、出来る限り苦労をしなくて済むようにと考えて作っているはずなのに、あちこちで苦労してしまうのだろう。
昨日見つけることが出来なかったファイルリストボックスだが、国内のページを探してみたところ、かなり多く見つけることが出来た。
しかし、家に持ち帰ってセットアップしようとしてみても、Delphi 用であったためかなかなか上手くいかず、結局何とかコンパイルして登録できるものを探すのだけでかなりの時間を取られてしまった。
とりあえず試してみたのは４個ほどで、その内きちんとセットアップできたのが１つだけというのもなかなか悲しいものがある。
一つなどは C++ Builder 用との事で期待していたのだが、unlink を使っていたところでコンパイルエラーが出て失敗してしまい、残りのもの（３個ほど残っていた）を試す気力が失われてしまった。
とりあえず使えそうで動くものがあるのだからそれを使おうと考えてしまったのだ。
で、現在の開発状況だが、とりあえず UI 部分については順調に完成してきている。
一応ファイルの選択までは出来る状態にたどり着いたので、そろそろ本体の方のコーディングに取り掛かれる。
まあこの辺で問題になるのは Builder が用意してくれている socket のライブラリがどの程度 UNIX の socket と互換性が取れてるかなんだよなぁ。
とりあえずホスト名とポート番号で接続できて、char 型の配列を read & write できれば十分なんだけど、いろいろと機能を拡張されているとその分調べなければいけないから大変になるのだ。
実際今までにも AnsiString には苦しめられた（文字列なんて Null 端の char 配列で十分じゃないか……）ので素直な実装ならばと期待しているのだが、どうも今までの経験から言うと、こういった期待は概して裏切られるものだと決まっているのでなかなかヘルプファイルを調べる気になれない。
どーしてこの期に及んで Objective Pascal のソースなんて読まなきゃいけないんだろう。
まあ Free のコンポーネントだからヘルプファイルやドキュメントなどが不足しているのは仕方がないかと納得できるし、実際我慢してソースを読む気になるのだが、Builder 本体のヘルプが腐っている現状というものは何とかならないのだろうか。
コンポーネントの継承元になっているクラスのヘルプを参照しながら何とか理解しようとしても、そのオリジナルのヘルプから腐っている状況では調べようが無い。（結局はソースへと走ることになる）
それともこれはソースを読んで良く理解してから VCL を使いなさいという親切心……な訳がないよなぁ。
やっぱり何か本を買うべきなのだろうか？
ヘルプに書いてあることをそのまま並べ替えたような本に出費したくないのだけどなぁ。
現在のところ開発は順調に遅れている。
とりあえず一通りディレクトリの移動／ファイルの選択ができて前回起動時の設定を保存しておけるものは出来あがったのだが、ファイルリスト内から複数選択した状態でそのファイルのフルパスを手に入れる方法がコンポーネント付属のドキュメントには見当たらなかったので次の段階に進むことが出来ない。
ついついコンポーネント自作という誘惑に駆られるが、そんなことをしていたらいつ完成するか判らなくなるのでとりあえずはこのまま突き進んで見ることにする。
たしか３ヶ月ほど前似たような事をしていた記憶があるが、そのときは結局全部公開ライブラリは一切使わずに全部自分で書く結果になったんだよなぁ。
今回はそうならずに済むことを祈ろう。
どうしてこう Builder のヘルプは腐っているのだろう。
頼むから FileOpen 関数の第２引数として指定するモード値の表ぐらい用意しておいてくれ。
最低限関数のリファレンスとして使えないことには何のためのオンラインヘルプなのか……。
結局 AnsiString 型のファイル指定でファイルを開くことをあきらめ、char の配列に変換してから ANSI 標準の fopen 関数でファイルを開くことになった。（こっちはこっちでメモリリークが心配なんだけど）
てーかさ、どーして char の配列を操作するための関数として StrCmp だの StrCpy だの StrCat だとかいう訳が判らないものが存在するの？
そんなに string.h をインクルードさせたくないのかな。
実行ファイルのサイズは無駄に大きいし（現時点で既に 376k）、ヘルプは腐ってるし、VCL は……。
……判っている。良く判っている。こんな愚痴を書いたところでどうにもならないということは。
そう、C++ Builder とは、C++ インターフェースを持った VCL 言語であり、C++ の処理系では無いということは判っていたはずだ。
こんなものを喜んで使うのはよっぽど物が判っていない馬鹿だけだということも判っていたはずだ。
それでも「もしかしたら英語のオンラインヘルプならもう少しましな内容になっているのかなぁ」などとつい考えてしまう自分が恨めしい。
とりあえず、ここ数日全てを忘れて没頭していた Windows 用のプログラムが何とか動くようになってくれた。
お世話になっていた幾つかの掲示板で告知したところ、なかなかの人気。
うーん、人の為になることをするって素晴らしい。＜─どこかから嘘つけ、ていう突っ込みが聞こえて来そうだけど、気にしないことにしよう。
とりあえず現在のバージョンは中途半端なものだから、何とかもう少し対応している所を増やして Ver. 1 を目指すことにしよう。
後は、さる筋から希望があった終了時のメッセージ表示をサポートして、と。
とりあえず身辺をもう少しクリアにしなければあれの作者が自分だとは言えないのが悲しいところだ。（そんな日が来るのだろうか？）
なにしろ作成したツールというのが物凄く暗黒に近い灰色なものだからなぁ。
うーん、日記に穴をあけるのは良くないと判っているのだが、ついつい忙しさにまぎれてまた盛大に更新をサボってしまった。
それなりに色々あったので、ネタが無いわけではない（書けないことも色々あるけど）ので時間さえあれば書いていたのだが、どーも時間が無いことにはやりようがない。
昨日は昨日で１２時までかけて CD-R ５枚焼いていたし、水曜は例のネットワーククライアントアプリケーションの内部構造を変更した結果発生したバグを潰すのに時間を取られ、火曜は力学の中間が帰ってきたショックで何もする気になれず。
CD-R は焼くのに久しぶりに失敗してしまい、昨日焼いていた CD-R の内、一番重要だった１枚はイメージファイルの作成に失敗したようで、74 分フルに使いきった挙句、家の CD ドライブでは（多分どこのドライブでも）読めないものになってしまった。
ああ、もう少し /opt/work/ の空き容量が大きければこんな失敗はしなくて済んだのに……。Joliet も Romeo もでぇっ嫌いだ。（MicroSoft の馬鹿野郎、どうして既に現行規格があるのに互換性のない規格をぶち上げてそれを強制的にひろめようとするんだ）
水曜に潰していたバグは結局 strlen を使うときに +1 するのを忘れていたためなのだが、問題が表面化するのがアプリの終了時のためどこにバグがあるのかを突き止めるのに時間がかかった。
結局問題の関数内で、モジュール化した部分を全部コメントアウトしてから、一つづつ戻して発症するか、しないかをチェックして突き止めることができたからまあ良いのだ。（デバッガを使いこなせればこんな苦労はしなくて済むのかもしれないけど）
てーか、こう言う問題なら、コピーしようとしたときに Segmemtation Fault を出して欲しいよなぁ。終了時に未知の例外エラーを出すんじゃなくて。
ま、それは結局解決したのだから良いのだ。問題は力学のほうだ。
中間で 28 点というのはひどすぎるよなぁ。２年の必修科目なのに。
休み中必死で勉強しなきゃいけないみたいだ。