メモ。

　Uジローさんとこにコメントする前に、一応一そろい調べていたつもりだったのですが……すっかり勘違いしていたことがひとつ。
　無圧縮の音声ファイルでも、曲名とかの情報を書く領域はありそうですね……WaveファイルのRIFF SIFとか。

　PASC - Google 検索、DCCの圧縮部分。この前段にある浮動小数点化の考え方はフツーだけど、デジタル値整数のfp化なので本質的にロスレスというのがポイントか。
　うーん……BPFをピアノの鍵盤と同じ感覚間隔で多数確保して、各サブバンドフィルタの受け持ち周期をBPFの値（1/f秒）〜1秒の可変にして(デコーダでは全帯域を積み重ねる……先頭のみが同時間に始まって、fsごとにひとつずつずれていく……という、230MB-MOのようなセクタの積み重ね方にする)、1/fの時は音の高さのみ・それより長い時は開始音高と終了音高のみを記録(デコーダでは2点を直線的な音量変化で繋ぐ……VLSCの音量版のような)して、基音に関連する倍音は基音の倍音成分として倍数を基音側に記録し倍音側から差し引いて……って、書いていてわけが判らなくなってきた。
　1オクターブごとにスペクトルを下行へと折り返すと、スペクトルは理科の「元素周期表」のように綺麗に揃うので、基音の近くと真下方向(1オクターブごとに折り返すので直下は2倍音、以下3,4,5...と続く)にスペクトルが表れる……はず(WaveSpectraの画像を印刷して切り張りすると良く解るかも)。これを動画処理的……2次元的周波数空間＋1次元の波高(音量)として保管できるかも。情報量を削減するときのマスクを周波数領域で2次元的に処理すると「倍音は基本的にカットするけど、特定基音の倍音だけは残す」とかいう選択性を確保できるので、BPFのみに頼る方式よりも「より倍音を大切にした圧縮」が可能になる。浮動小数点化しておけば「聴覚補正カーブ」は一次元的方法とまったく同じに適用できる(むしろ視覚化しやすい分だけ新しいアイデアが出やすい)。BPFのみに頼る方式と比べると「処理が馬鹿みたいに重い」のが問題で、ポータブルプレーヤ用の整数演算デコーダ製作は困難かも。
　#両方とも使えそうにないか……むむむ。MP3やOggVorbisの圧縮方式が解りやすいドキュメントになっていないかしら？

　スラッシュドットの「W-ZERO3、本日発売」に苦笑い。シャープの得意技だったのか……歴史は繰り返すわけですねorz

ところで奇しくも3年前の今日は、やはり大人気で売り切れ続出となったLinuxザウルス「SL-C700」の発売日だった。ZERO3を開発したシャープが「ゲンを担いだ」訳ではないだろうが、SL-C700のように「わずか半年で後継機が登場」という悲しい事態にはならないで欲しいところだ。
(from http://slashdot.jp/mobile/article.pl?sid=05/12/14/1149235 )

　初代は発売日に買ったから、2005年12月14日か……6ヶ月規制の解除は2006年6月14日(→39800円に)、10ヶ月規制の解除は2006年10月14日(→29800円に)……うーん、2006年10月14日はお祭りになるのか？あと1ヶ月だから、それまで待つことにするかも。

　しかし、いつにも増して誤変換が多い……MS-IMEの初期状態ってこんな感じなんだなぁ……と、いまさらながらに納得。以前と違って過学習する傾向は減っているので、道具としての力は確実に上がっているような気がする。
　とはいえ、細かいところで使いづらいというか、案内が足りていないというか……ATOKのような「ちょっと目うるさいぐらい＝視線の移動距離を減らす工夫がある」方が好きな身としては、ちょっと物足りないところ。
　Webページ更新環境すらも整備していない仮設環境だけに、わざわざATOKをインストールするのも微妙だし……どうしようか。