日々の戯言

７月２日（月）　色々あるけど

Lanczos3 の SSE2 化も iDCT の SSE2 化もさっぱり進んでいない。やはり本棚の届いた日曜に部屋の模様替えに着手してしまったのがまずかったのだろうか。それともようやくまともな外部 YC 分離機を NV-DM1 に追加できたと思ったとたんに EZDV が機嫌を損ねてくれたからだろうか。

EZDV の方はまだ解決していなくて、とりあえず空いてた HDD に OS クリーンインストールして、EZDV DRV/APP を入れた状況でも、Disconnect と正常に操作できる状態を行ったり来たり。内 Disconnect が 9 割で何かの拍子に何故か操作できるようになるのが 1 割。

なんとか今日明日で解決しないことには、今週開始予定の水・木の新番組がというわけでかなり追いつめられてる気分。今日は PCI スロット変更を試す予定。今挿してるのは一番安定してるはずの PCI 2 だし、以前は使えてたのだけど。これで直らなかったら…… GV-DVC/PCI は実家に置いてきてしまったからどうしよう。

まーそゆことばかりやってた訳じゃなくて、一応それなりにコードは書いてるんだけど。しかし SSE2 って使えないね。32bit 精度固定小数点（小数点以下 16 bit）で４並列の乗算ができるものと思ってたのに、PMULHD/PMULLD が無いときてやがる。乗算するには一度 16 bit 精度に落としてから PMADDWD 使えってか。

SSE2 最適化なんていう P4 ユーザの自己満足なことしてないで、素直に、SSE 最適化だけで単精度浮動少数点４並列演算してた方が仕合わせなんじゃないかという気がしてくるから不思議。なんで Intel の 整数 SIMD って PMULHD/PMULLD とか PMULHB/PMULLB とか PMADDBW が無いのだろう。

７月３日（火）　悲しき SSE2

本題に入る前に。EZDV は無事……といえるのかどうか……復活した。スロットを変えても症状は改善せず、絶望のあまり儚くなってしまいそうな時、藁にもすがる想いでケーブルを逆に入れなおしたら治ってくれた。

今まで EZDV 側につなげていた固めのを NV-DM1 側にし、今まで NV-DM1 に接続していたものを EZDV に接続したところ、今までゴネていたのが嘘のように復活してくれた。自分は今まで何をしていたのだろう。

本題。lanczos3.auf を SSE2 に対応。更新。あー SSE/MMX には対応してないので、そこのとこよろしく。

で、この場合 SSE2 に対応してどの程度早くなるかというと、なんとたったの 6 % だけ。まあとりあえず並列計算するようにさせただけのいい加減な対応（とても最適化とは言えない）だけど、それでもこの程度だったなんてちょっとがっくり。

どうやら C からそのまま SSE2 形式に対応させる形で ASM コード書いてもあまり速くならないような訳で……徹底的に最適化するとなると……はげしく面倒だからできればやりたくないんだけどね。

まあ次は使い勝手というわけで３次補間からコード引っ張ってきて、設定ボタンつけますか。SIMD の最適化コードはゆっくり考えることにして。

７月４日（水）　縮小アルゴリズム（５）― 補間（Interpolation）

大昔 にちろっと書いた戯言の続きです。といっても今回は前置きなので気楽に読んでください。

補間（Interpolation）と呼ばれる処理があります。３次補間、線形補間、最近傍点補間の「補間」のことです。

これはどのような処理かというと、サイズ変更や回転処理などによって画素の座標がずれた時に、周辺の画素から目的の位置での画素の値を求める処理のことです。

以前も使った例ですが、704x480 から 320x240 に縮小する場合、縮小後画像の x=99, y=99 の座標は、縮小前画像での x=217.8, y=198 の座標に相当します。このように原画像での座標と完全に一致しない場合に、座標の間の値を周囲の座標の値から補うのが補間処理です。

縮小処理で補間を使用する場合の問題点は、折り返し歪み（エイリアスノイズ）の存在です。補間処理は基本的に低域通過フィルタを含まないので、縮小処理に使用すると折り返し歪みが出ます。補間は座標変換一般（平行移動や回転処理）などに使われる処理のため、低域通過フィルタを入れることはできないのです。

そこで、良質な縮小処理を行う場合には、補間と低域通過フィルタを併用するか、あるいは、縮小専用の処理――デシメーション（Decimation）――を行う必要がでるのです。

……続く（はず）

えと、lanczos3.auf 一応更新してます。３次補間と同様のボタンを追加しただけなんですけど。

７月６日（金）　縮小アルゴリズム（６）― デシメーション

縮小処理用のフィルタはデシメーション（decimation）フィルタと呼ばれます。

デシメーションの最大の特徴は、縮小率に応じて、フィルタのタップ数（原画像からの参照画素数）が変わることです。これは、低域通過フィルタのような効果をデシメーションフィルタ内に盛り込むために行われます。

例えば、平均画素法でのフィルタの形は次の図のような台形になります。

この台形の範囲内にある原画像の画素に、台形の（全てを足し合わせるとトータルで 1 になるように正規化された）高さを掛けて畳み込み、縮小後画像の１画素を決定するわけです。

デシメーションフィルタとしては、この他にボックスフィルタ、テントフィルタ、ガウシアンフィルタ、そして Lanczos フィルタ等がありますが、縮小率によって１画素を決定するための参照画素数が変化するという点は変わりません。

さて、デシメーションでは帯域制限が必要になるのですが、デシメーションフィルタとして FIR 形式の低域通過フィルタをそのまま使用したならばどうなるでしょうか。理論的にはもっとも高画質な縮小が可能になるはずです。

実は Lanczos2/Lanczos3 フィルタこそが、その低域通過フィルタをそのままデシメーションに使ったフィルタなのです。

低域通過フィルタを使ったことのある人ならば体験的に理解してるはずですが、解像感を高めようとタップ数を増やせばリンギングノイズが発生し、リンギングノイズを減らそうとタップ数を減らせばエイリアスノイズが発生し、エイリアスノイズを減らそうと縮小サイズよりも小さい阻止周波数を指定すれば解像感が失われるといった具合に、バランスの良い設定値を見つけることが困難です。

しかし、Lanczos フィルタ（正確には Lanczos 窓関数を使用した FIR 低域通過フィルタ）は解像感・リンギング・エイリアスのバランスが高いレベルで取れているためその心配がなく、画像処理には最適であると言われています。

Lanczos フィルタの処理内容詳細は、まだ図が書けていないため明日になります。

えと、Lanczos3.auf、ダイアログ関連バグ修正版の 0.3.1 ができてます。ホントは SSE 対応もやってみたのですけど、私の環境では非 SIMD よりも遅くなってしまったので封印してます。ソースには残ってるので興味がある方は覗いてみてください。

ごめんなさい。水曜日に上げた Lanczos3.auf アーカイブ構成が狂ってました。古いのがトップフォルダにあって、新しいのはソースだけだったようです。0.3.0 にはダイアログ周りにバグがあるので捨ててください。手数かけて申し訳ありません。

７月７日（土）　縮小アルゴリズム（８）― Lanczos

Lanczos2/Lanczos3 フィルタの形は次の図のようになります。上が Lanczos2 フィルタ、下が Lanczos3 フィルタです。

Ken Turkowski "Filters for Common Resampling Task" (1990, Apple Computer) より引用

さて、Lanczos3 の場合、図の -3 〜 3 までの範囲に対して図の式を適用し、縮小後の１画素を決定する訳ですが、この時に問題になるのは -3 〜 3 という範囲（図での X 軸）の単位です。基本的にここさえ判れば後は式のとおりに実装して、Lanczos3 縮小フィルタを作成することができます。

この図は、11:5 の縮小比（704 -> 320 と同じ）場合の、Lanczos3 フィルタの参照画素サンプルを示しています。上が原画像で、下が縮小後画像に相当します。

まず、X 軸の単位は縮小後画像での１画素の幅になります。中央の赤い丸を置いた座標の画素値を求める場合、-3 〜 3 という範囲は、矢印で示した範囲になります。この範囲内にある原画像の画素（灰色の丸を置いた座標）に、Lanczos3 の式から求めた重みを掛けて、畳み込むわけです。

lanczos3.auf まだバグがありました。一度出力が終了した場合に SIMD 関連のラジオボタンが全て有効になってしまい、その状況から、SSE2 非対応マシンで SSE2 整数とか選ぶと、AviUtl 巻き添えにして落ちてました。修正版は 0.3.2 です。

７月９日（月）　縮小アルゴリズム（９）― おまけ（補間の場合）

Lanczos フィルタは補間（拡大）にも使用することができます。補間の場合、参照画素数は拡大後の解像度によらず原画像の解像度によってのみ決定されます。

Lanczos フィルタは基本的に低域通過フィルタなのですが、その遮断周波数は基準にとる幅によって決定されます。具体的には、基準の幅のナイキスト周波数が遮断周波数になります。

原画像の１画素の幅を基準にとると、遮断周波数は原画像解像度のナイキスト周波数に等しくなるので、オリジナルに含まれる（計算誤差によって削除・追加される歪みを除いた）全情報をそのまま通すフィルタになり、補間に使用することができるようになります。

lanczos3.auf の SSE 最適化完了しました。今のところ SSE2 整数版よりも速くなってます。

７月１０日（火）　NY ってアメリカの NY ですか

８月末にアメリカ出張ですか……。まあ会社のお金で行けるのでしたら、トラブルさえ発生しなければ楽な仕事だし行くこと自体はやぶさかではないのですが。まあそんなことがあるかもしれないから考えといてという段階の話でまだ確定じゃないんだけど。

会社の営業担当に相談しても、まあ本人が問題なければいいんじゃないとのことなので、こちら方面からストップはかからない。二人に増えても予算的にペイすると向こうが判断すれば、行くことになるわけか。

初の海外旅行が仕事の出張というのもアレだな〜。２・３日という話だけども、水・木にかぶる場合どうしよう。NV-DM1 だと予約録画は 60 分が実用上の限界だからな〜。

ああ、メディアコンバート機能はさっぱり使ってないし、（そもそも NV-DM1 は外部からの電源ノイズの影響を受けやすいので、録画時に PC の電源 OFF が基本）予約数は少ないし、外部チューナ＆Y/C 分離機必須だし、ミニテープだからドロップノイズが発生しやすいし、音はずれるし。SONY の WV-D9000 の展示品処分を逃して NV-DM1 にしてしまったのがつくづく悔やまれる。

lanczos3.auf ですが、SSE 実数最適化に色々とバグがあるようです。現在原因調査中ですので、修正版をリリースできるまでは SSE 実数は使用しないようにしてください。

７月１１日（水）　アニヲタ失格

できることならリアルタイムで見たかったのだが、デジタル BS を導入する余裕はない。仕方がないから、DVD が出るまで待つことにしよう。

まほろの話。立派なアニヲタというものは、カードキャプターさくらが始まると聞けば BS チューナを導入し、星界の紋章がスクランブルでやると聞けば WOWWOW に加入し、まほろが BS-i で放送と聞けばデジタル BS ＆ D-VHS システムを導入するものらしいのだけれども、残念なことに先立つものが無いため断念。前の二つもやってないんだけど。

こんなことでは立派なアニヲタになれないと判っているのだが、流石にデジタル BS よりも先にまともな（せめて S 入力のある）TV モニタ買うほうが先かなという気がするので。

lanczos3.auf SSE 実数の左端バグ修正と、SSE2 整数の最適化をしました。0.3.4 です。SSE の左端バグは……なんでテスト中に気がつかなかったのだろうってぐらい派手に出てますね。報告のメールくれた皆様、本当にありがとうございます。あと SSE2 整数の最適化で SSE 実数よりも速くなったはずです。粘ればもうすこし速くすることもできるのですが、それやるにはちょっと腰を据えなければ無理なので、その前に MMX 最適化にいきます。

７月１２日（木）　あやや、本決まりですか。

会社の方にも話が来たということは、ほぼ本決まりということですね。あー旅券の申請しなきゃ。住民票は駅前に出張所があるらしいから良いとして、戸籍抄本って……本籍はどこだったかな。親に聞かなきゃ。

でも、わざわざ向こうに行かなきゃいけないということは、今作ってるシステムがかなり不安定で、まともに動くか怪しいという評価を受けた（のでトラブル対処要員としての動員がかかった）ということなのだよなぁ。実際まだ開発途中だし、テストしたはずの所でもまたバグでてるし。昨日今日でまた４つもバグが発覚してるから……。

なるべく機能を保ちつつ内部をもうちっと見通しよくとか考えて、余裕のあるうちに汎用のマルチスレッドサーバソケットクラス作って、せめて転送制御部分以外では非同期ソケット＆ Windows メッセージと縁を切ろうとしてるのだけど。

かえって不安定にしてるかもという気がしてきて恐い。が、私には非同期ソケットを自在に操る自信がないので今後機能追加するならブロッキングソケットに逃げるしかないのだ。

最近気がついた楽しいコード。

CHoge:RecvData(SOCKET hSock, const char *mess)
{
    ...

    n = ::recv(hSock, (char *)mess, len, 0);

    ...
}

読んでいて１０分間ほど何をやってるのか悩んでしまった。

ごめんなさい。lanczos3.auf まだバグが取りきれていないようです。SSE 実数、SSE2 整数等で不具合（AviUtl ごと落ちる）が発生するという報告が上がってますが、まだ原因を特定できていません。もうしばらくお待ちください。もし、特定環境でのみ落ちるという条件の特定できた方いましたら、報告をお願いします。

あーメモリ管理周りじゃなくて、レジスタの初期化忘れとかなのかな。うーどこでバグってるんだろ〜（涙）

７月１３日（金）　夏季賞与

遅れていただけで一応出るらしい。先日帰社した折に就業規則をつらつらと眺めていたところ「前年１２月１日〜６月１日まで勤務していた正社員で……」という記述があったため、あ〜まだ振り込まれてないし、こりゃ出ないんだなと早合点してしまったのだけど。

さすがに実質２ヶ月しか勤務していないので満額とは行かないらしいけど、それなりに出てくれるのならありがたい。でも、自己評価資料書いて部課長と面談って……面倒だね。なるべく多くもらえるように努力したいところなんだけどどうしたものかな。

うげげ、WM_USER+100 って出力プラグインで出したときしか上がってこないのか。どうしよう。WM_USER+106 は常に上がってくるけど、そこで WindowEnable(false) にしてもすぐに WindowEnable(true) されちゃうし、func_save_end() もダイアログアイテム有効化の前に呼ばれるし。一番良いのは WM_USER+106 を func_wndProc() で FALSE 返した時はデフォルトの処理を行わないとかにしてもらうことなんだけど。

それには本体の対応が必要だし……今の処理もかなり（仕様として公開されてないことを無理やりなんとかしようとして）汚いハックになっちゃってるから。一番綺麗なのは BUTTON の WM_ENABLE をオーバーライドしてしまうことなんだけど……サブクラス化ってどうやるんだろう。

あーひょっとしたら malloc で確保した重み配列が 16 byte アライメント取れてないのかも。今まではアライメント取れてるものと思い込んでいたけど、そういえば malloc で確保した領域にアセンブラで触るのは初めてだった。だとしたら movaps を movups に置き換えて、movdqa を movdqu に置き換えれば動くようになるのかな。

でもそれやるとパフォーマンスが落ちるから……、何かコンパイラオプションでそういうのが無かったか探してみよう。見つけられなかったら無理やりアライメント調整するしかないから管理がさらにややこしくなるけど、それは setup_xxx_table() の中をホゲるだけで済むはずだから。

７月１４日（土）　SSE/SSE2 と malloc

SSE/SSE2 拡張の MOVAPS/MOVDQA で、malloc で確保したメモリにアクセスする際のメモ。主に VC++/MASM 環境想定

1. malloc で確保するメモリ領域は、特にアライメントが保証されている訳ではない。
2. Windows 2000 SP1 + DirectX 7 環境では、実験してみたところ 8 byte アライメントが成り立っていた
3. Windows 98SE + DirectX 8 環境では、特に問題が発生していなかった所を見ると、16 byte アライメントが成立していたのだろう
4. どの環境でも動くようにするためには、malloc 後のポインタを free の為に保持しておく物とは別に、unsigned long に変換して無理矢理 16 byte アライメントをとるという方法がある（lanczos3.auf 0.3.5 ではこれを採用）
5. コンパイル時に malloc のアライメントを指定するのは、不可能な模様
6. 静的に確保したグローバル変数の場合、コンパイル時のアライメント指定および、リンク時のベースアドレス指定で 16 byte アライメントを簡単に取ることが可能
7. ところで係数配列って、パックされた４つの変数に全て同じ値が入ってるのだけど、この場合って MOVAPS の１命令で読み込むのと、MOVSS で読み込んでから SHUFPS でコピーするのとどっちが速いんだろう
8. いや、MOVSS+SHUFPS だとアライメントを気にしなくても済むものだから

というわけで、SSE/SSE2 で落ちてた方、多分 0.3.5 で直ってるはずです。あと、直った場合、もし良ければ DirectX のバージョンとか、DirectX 8 を入れてみて、0.3.4 を使った時の結果報告とか頂けると嬉しかったりします。

ダイアログ（SIMD ラジオボタン）の件はまだ解決してません。しばらくは気にしないでいてください。修正版のリリースははやくても月曜になる予定です。

７月１５日（日）　軟弱

土曜は実家に戻っていたのだが、あまりの暑さに堪えきれずその日の内に逃亡。冷房のある生活って素敵。

電気代がもったいないからクーラーを使いたくないという気持ちは理解できなくもないのだけど、でも 35℃を余裕で超えてるのに、それでも使わないのだとしたら何の為にクーラー購入したのだといいたくなる。

少なくとも夏の間はなるべく帰りたくないと思ったのだが、選挙名簿ではまだあっちに登録されているらしい。投票案内の葉書が届いていて、なんだか見たことのある学校が投票所だなとか思っていたら、実家の方だった。

仕方がないから再来週もまた帰らなければいけない。

７月１６日（月）　虫と試験

やっぱりテストしてないと駄目だね。lanczos3.auf 0.3.5 に SSE2 整数でバグ入れてしまった。

しかもバグ修正でバグ入れてるという一番最悪のパターン。テストしてれば十分気がついたバグだったし、テストしなくても冷静にソース眺めれば確実に気がついたはずのバグなんだけど。

言い訳

1. 作業環境に P4 機械がなく、テストできなかった
2. 作業環境に冷房がなく暑かった
3. 非 SIMD / SSE 実数 / SSE 整数と似たようなコードが並んでいて幻惑された

上二つはまあ自分の所為では無いが、最後のは自業自得だからな〜。えーと、このバグは 0.3.6 で修正されてるはずです。出力後の SIMD 関連ラジオボタンのバグもようやく修正できました。あと、SSE2 実数 SIMD も実装してます。P4 持ってる人はぜひ SSE2 の遅さに幻滅してみてください。

メモ：TV 購入。7/21 到着予定。

７月１８日（水）　SIMD

業務連絡。lanczos3.auf の最新版は 0.4.2 です。0.4.1 にはまだ SSE2 実数での下端処理にバグがありました。

さて本題。Intel は市場競争力を維持するために、プロセッサの世代交代の度に SIMD 命令を追加しているわけですが、MMX, SSE, SSE2 といい加減その数も増えてきたところで、どれがどの程度速いのかとか気になる方も多いと思われます。で、折角 lanczos3.auf で現在の Intel 系 CPU の全 SIMD パターンを実装してみたわけですし、ベンチマーク的な速度計測をしてみたくなるのが人の常だと思います。

というわけで、非 SIMD 〜 MMX 整数を、それぞれ３回ずつスパゲッティ２１号で出力して、木村安子さんとギコ猫にログを採ってもらいました。測定環境は次の表のとおりです。

補足事項として、使用フィルタはクリッピング（左10,右6）のみで「元のサイズに拡大」はなし。結果は次のとおり。

ポイントは MMX 整数の意外な健闘と、SSE2 実数の異常な遅さ。一応、計算精度は MMX 整数 = SSE2 整数 < SSE 実数 < 非 SIMD < SSE2 実数 だけれども、私の見た目ではほぼ差はないと感じてる（ただ、自分では使ってなかったとはいえ LPF の MMX ノイズに気がつかなかった前科があるのであまり信用しないように）

SSE2 整数と MMX 整数は内部的なループ構造はまるきり一緒で、並列計算数が２倍になっているだけのものだったりする。つまり、同時に 2 倍の計算ができるようになっても、90 秒分のデータを処理する時間との比較としては 4 秒程度しか小さくならない訳だ。

まーおまいの最適化がへこいからだとかいわれちゃうと、そうかもしれないな〜と感じるのだけど、SSE2 向けにもっと最適化しろといわれても、やりようが無いのだよね。SSE2 整数 SIMD 命令って、MMX 命令で SSE レジスタ使えるようになっただけで、特に命令は増えてないから、どちらも同じ方法を使うので速度差が開いたりはしないはずだし。

SSE2 独自に（MMX との差別化として）できる最適化というと、後はデータ書き込み時にキャッシュを汚染しないようにするぐらいなんだけど、どの程度効果があるかは試してみないと判らないんだなこれが。

これで効果がでないようだと、SSE2 最適化って高速化は期待できないじゃんという結論だしてあっさり見捨てることもできるから、それはそれで嬉しいのだけど。（でも P4 買ってしまった身としてはちょっと切ない）

７月１９日（木）　相不変

NV-DM1 の調子は良くない。というよりも、IEEE1394 コネクタの調子が非常に悪いようだ。取り込んでいると警告無しにごそっとフレームが抜けたあげく、しばらく経過しから「HDD の書き込みが……」というエラーメッセージを出して止まっていたりする。

最初に抜ける時点ではプレビューも音のモニターもストップするうえ、再生してみるときっちりそこだけ抜けているので、おそらくケーブルの接触が瞬間的に失われているのだろう。

つか、これに気がつくまでに数回デフラグしてしまったが、それは完璧に無駄だったわけね。

まあ水・木は暫くの間、ずっとこんなことをしている予定なので、趣味のコード書きは止まります。よっぽど致命的なバグが見つかれば別ですが。

明日からの連休も仕事のプログラムが遅れているので、持ち帰りざんぎょーの予定。家で別のことやってるだけでも作業効率ってかなり落ちるのね（涙）

ので、SSE のキャッシュ操作命令やら 整数 SIMD のさらなる高速化とかは暫く先になる予定。はやくても８月頭かなといったところです。

７月２３日（月）　初めてのウイルスメール

ウイルスメールをもらってしまった。いや、KaMail 使ってるおかげで SIROLAST.zip.pif とか添付ファイル名が表示されてるからウイルスだというのは一目瞭然なんで、ファイルをうっかり開いて感染する心配はないのだけど。

うーん、この手のメールをもらうのは初めてなので結構ワクワクしながらバイナリエディタに入れてみたのだけど、あまり面白い情報は残ってないな〜。WIN32 EXE 形式で TObject とかが入ってるし、Outlook Express 感染型のわりには 400k 近くと結構サイズが大きいから Delphi とか BCB とか使って作られたウィルスなのかも。

どうせもらうならもちっとエレガントなウィルスの方が嬉しいな。今までは Hybrid 系のメールってもらったこと無かったから、まるも製作所見に来るような人にはウィルスに感染するような初心者は居ないのねとか思ってたのにがっかり。

えーと、どこまでが本当か判らないけど、ヘッダ晒します。心当たりのある人は悔い改めるように。騙られただけだとしたらごめんなさい。

Received: from takoyaki1.osk.3web.ne.jp (takoyaki1.osk.3web.ne.jp [202.210.150.11])
	by apa01.a2.ocv.ne.jp (8.9.3/3.7W) with ESMTP id LAA26564
	for ; Mon, 23 Jul 2001 11:32:14 +0900 (JST)
Received: from TARO_S.zaq.ne.jp (zaqd387129d.zaq.ne.jp [211.135.18.157])
	by takoyaki1.osk.3web.ne.jp (Postfix) with SMTP id 014033DD7E
	for ; Mon, 23 Jul 2001 11:29:27 +0900 (JST)
From: "Taro Sakaguchi" 
To: kazhiro@a2.ocv.ne.jp
Subject: SIROLAST
date: Mon, 23 Jul 2001 11:31:21 +0900
MIME-Version: 1.0
X-MIMEOLE: Produced By Microsoft MimeOLE V5.50.4133.2400
X-Mailer: Microsoft Outlook Express 5.50.4133.2400
Content-Type: multipart/mixed; boundary="----1C8E7457_Outlook_Express_message_boundary"
Content-Disposition: Multipart message
Message-Id: <20010723022928.014033DD7E@takoyaki1.osk.3web.ne.jp>
X-UIDL: V31"!$nl"!b$a!!#$>"!
Status: RO

７月２４日（火）　STL と多態

ANSI C++ 標準が腐っているのか、STL が駄目なのか、VC++ が問題外なのか判らないのだけど。どうも STL と多態は相性が悪いらしい。

当初は std::list<basic_abstract_class> class_list; として、class_list.push_back(sub_class); のように使おうとしたのだけど、これだと基本抽象クラスのインスタンスを作ろうとしていますと文句を言われコンパイルできず。

仕方が無いから NULL を入れてた純粋仮想関数に適当な何も実行しない関数をあてがい std::list<base_class> class_list; として無理やりコンパイラを通したが、この場合 class_list.push_back(sub_class); の段階でサブクラス情報が失われてしまうらしく、オーバライドしている関数が呼び出されず。多態を実現できない。

こうすると STL コンテナのメモリ管理機能の恩恵を受けられなくなるんだけどなと思いつつ、std::list<basic_abstract_class *> class_list; に変更。std::list<basic_abstract_class *>::iterator i から (*i)->member_function(); として使うしかないこととか class_list.erase(i) の前に delete (*i) しなければいけないのが醜いと感じつつ耐える。

もっと、こう、泥臭くない書き方があるのでは無いかと思って、職場の先輩に聞いてみても、それで我慢するか、あるいはメモリ管理用のラッパクラスを用意しといて、それをコンテナに入れるぐらいしかないんじゃないかなという返事。

こうして C++ が嫌いになっていくのは仕方が無いことなのだろうか。

７月２５日（水）　贅沢 != 貧乏

届いたのは先週土曜のことなのだけど、TV 購入。機種は SONY の KV-28DX550。流石に DBS には手が出なかったのだけど、今後の為に D4 端子が欲しかったので最安値モデルを。実際 750p での放送が行われるかどうかと言われるとかなり疑問なのだけど、もしも放送されることがあったときに、525p でしか見れないと悲しいので。

しかし最安値モデルとはいえ専用台とセットで買ってしまったので口座の残高は非常にきびしくなっている。今日は給料日なのだけど、何とか今日まで持ちこたえることができたという感じ。

どうして私はこんなにも貧乏なのだろうと悩んでいたのだけど、どうやら私は貧乏なのではなく贅沢なだけらしい。会社の同期に言わせると、給料 4/5 でも良いから月にもう一週間休ませて欲しいとかいうのが普通の人間の心情のようだ。あれでもきびしいと言ったらそれは贅沢だと諭されてしまった。

うーん、大卒新人で手取りン十万貰ってて、一人暮しなのに 40�u 1LDK の物件借りてるってやっぱり贅沢なのかしらん。

どうやら最近私が受け取っているウィルスメールは TROJ SIRCAM.A という形式のものらしい。なんでもウイルス本体を送る際に、HDD 内から無作為に選んだファイルを本体の後ろにくっつけて送るので、それで 200k 以上の巨大な添付ファイルがくっついてくるわけね。

ちょっと興味があったので、今日までに届いた３通から添付ファイルを取り出し 0x21800 以降を切り出すプログラムを書いて遊んでみたら……おお、確かに非感染ファイルが取り出せた。うん、ひょっとしたら何かの役に立つかもと思って保存してて良かった。

今のところメールボックスが溢れる程度に届いてる訳ではないためそれほど実害を感じていない。ので、結構愉快なウィルスなのかも（他人事モード 75%）と感じてる。対策に奔走してるネットワーク担当の人に言ったら殺されそうだけど。

現在 M1 は落ちています。ping が通らないから、多分落雷による停電ではないかと推測してます。あ〜、またケーブルモデムがハブ巻き添えに死んでたらどうしよう。一応今週末は実家に帰るつもりだったのだけど……。

電源再投入で復活するようなら明日には M1 復帰しているはずですが、それ以外の場合だと復活は土曜以降になります。しばらく更新は M2 のみになるので、その際はよろしく。

７月２６日（木）　また死亡

またもやケーブルモデムが死亡。雷なんて大嫌いだ。確か前回壊れたのは 5/29 なので、ほぼ２ヶ月に一回ケーブルモデムが壊れている計算になる。まあケーブルモデムは OCV が無料交換してくれるから良いのだけど。

今度はハブが壊れてなければいいのだけど……多分それは期待できないんだろうな〜。一応最悪の事態を想定すると PC やネットワークカードも巻き添えに死んでるとなるのだけど、電話で聞いた話によれば一応 PC の電源は入ったようだから、そこまでは行っていない模様。

OCV ってシステム全体のデザインとしての雷対策ってしてないのかな〜。雷が鳴ったらケーブルモデムからアンテナ線を抜いてくださいと言われても、雷の危険性があるときに都合良くそんな作業ができるってケースはまず考えられないと思うのだけどな〜。

７月２８日（土）　M1 復活（２）

えーと、M1 復活しました。今は以前と同じアドレスで見えるようになっているはずです。例によって例の如くハブを巻き添えにケーブルモデムが死んでいたのでまたハブを買わなければいけないのが非常にアレな気分ですな。

最初は電源内蔵タイプの 8 port ハブ使ってて、２代目は電源内蔵タイプの 5 port ハブ、そして今回の３代目は電源が AC/DC アダプタ形式の 5 port ハブと、壊れる度に安物になってるのが悲しい。

一応 OCV 的にもそれなりに雷対策をしているようで、最初は 5C ケーブルとケーブルモデムを F 型コネクタで直結していたのだけど、一度目に破壊された次の交換時には -3 dB のアッテネータ（減衰機）が追加され、今回はそれが更に -10 dB のアッテネータに変更されていた。

なんだか「焼け石に水」とか「対処療法」とかいう言葉が思い浮かぶのだけど…… -10 dB なら電圧比で 1/3 に減衰するはずだから 9000 V まで耐えられるケーブルモデムなら 27000 V に耐えられる計算に……。雷って平気で 10 万 V とか超えてなかったっけ。

サージアレスタの導入による自衛を考えた方が良いのかも。ただ、この場合アースも考えないといけないから悩みどころ。まあ壊れる度に実家に戻ってきて、OCV に連絡とって、巻き添えになったハブを交換してとかの手間を考えれば安いものなんだろうけど。

でもさ、これぐらいのことは OCV が保安機でやっててくれても良さそうなものだと思うのだけどどうかな。雷のたびにケーブルモデム交換して、修理派遣してってかなり大変な出費じゃない？

補足。OCV 的には、保安機での雷対策もやっている模様。少なくとも 5/29 のメールではそう主張していた。ただし、どの程度の対策なのかは不明。サージアレスタ入れてるけど、アースはとってないとかいうオチでは無いことを希望。

７月２９日（日）　デモでエラーを出さない秘訣

もしあるのならば非常に知りたい。

７月３０日（月）　ダメ人間

最近職場以外では Porno Graffitti のアゲハ蝶をループ状態で聴いている。ダメ人間の極みのような歌詞が最高。

歯止めが利かなくなったように漫画を買い漁ってるのもダメなところ。最近のハマリは橘裕さんの本。「Honey」と「人形師の夜」は既刊分なら揃え済みで、初期の短編集も Book Off で発掘済みだから後は「渡辺さん家の一家言」と「もしかしてヴァンプ」の５〜１０と「刻の聖獣」でコンプリートの予定。当然「だって愛だもん」も購入済。

流石に同人誌にまでは手を出せないので、そちら方面は断念。財力が溢れてて探す時間が充分に取れる職業なら諦めたりはしないのだけどね。

阿〜吽。やっぱり毎日気を張ってると生きていくのに疲れてしまうから、たまにはこう言う日々があってもいいんじゃないかと思うのだけど、やっぱダメかな。

７月３１日（火）　DVD の評価基準（NOIR の場合）

「NOIR」１巻を購入。まあ、エンコードに力を入れているというのは認めましょう。普通は 35mm ネガからテレシネなんてわざわざしないでしょうから。

でもね、そこまでするんだったら 2:3 プルダウンなんてしないで、24P でエンコードして（RFF と TFF フラグを使って）再生時 2:3 プルダウンしましょ〜よ。

未だに据え置き型 DVD プレイヤーを買えていないので、PowerDVD で見てるのだけど、常用環境である 1280x960@85Hz では G450 の DirectDraw の制限から BOB フィルタが効かずにコーミングが出まくりの悲しい状況。

かといって垂直同期周波数を 60 Hz に落とすと、こんどはディスプレイ（低残光タイプ 19inch CRT）の制限からフリッカーがチカチカ。

仕方が無いから 見るときだけ 1024x768 に解像度を落としてる。

しっかし、どうしてこう TV 放映されたアニメ DVD ってことごとく 29.97i でエンコードされてるんだろうね。最初はテープに落として放送局に納品してしまったら素材は全部捨て捨てでエンコードとかは局側にお任せの所為かともおもってたのだけど、35mm ネガから作り直してるはずの「NOIR」でも 29.97i だし……。

今のところ、私の手元にある DVD で 24P エンコードされてるのって「秋葉原電脳組〜2011年の夏休み〜」だけなんだけど、何か事情でもあるのかしらん。

少なくとも劇場版のフィルムソースから作られてるものの中では 24P エンコードされてるのがあるんだから、再生側で問題が発生するかもしれないからってのは理由にならないよな〜。んな事言い出したら洋モノの DVD は全滅になるし。