音の波を周波数情報に変換せず、そのまま波の形状を安定化した上で音楽情報を圧縮する技術です。現在、WAVE形式の音データを２００分の１〜１６００分の１に圧縮することに成功しています
と書いてあるが，
0.3*e^u(t-2) * y(t-2) + 1.4*u(t) + 5.1*sin( y(t) ) ... + sin( y(t-1) ) + ...
これ見る限り後半はフーリエぽい．1.4*u(t)とかはノイジーな高周波とかを個別に記録するのためのものか？それでさらにeとか使えそうなところは使っていくみたいな？普通に考えたら無理くさいけど．それからy(t)が何か分からない．
ってこんな式あてにならないか．

ＭＹＣ技術を用いれば音情報、画像情報、文字情報等全てのデータを既存の２０分の１〜数百分の１のスピードで通信することが可能になります。約６０分の音楽ＣＤデータであれば全く劣化せずに０．４秒以下で送受信することができます。
ロスレスにも対応!?恐るべし．
しかしサンプルデータ聞いても元の音質が悪すぎてよく分かりませんでした．

参考 : 高度技術研究室＠ＪＧＳ
参考 : 大学生の常識を覆す、元スーパー大学生・現夢の伝導師社長 和田さん並に怪しすぎ．
参考 : 株式会社ジェイジーエス研究所（徳島市） 技術アイデアをアプリケーション（具現化）

占いみたいな感じになってます．

この前久しぶりにプールに行って1時間泳いだ．
めちゃ疲れた．
で，パンツはく時に足攣りそうになりました．パンツはきかけのときに足攣ったら最高にカッコ悪いよなあ．
背泳ぎのバサロキックに感動．
参考 : one point lesson 水泳

何気にアクセス解析を見ていたら，実行ファイルからの並列性抽出及び並列化変換というのを見つけた．命令単位の並列性の抽出は今のところプロセッサが実行時に動的に行っています．ということで，ある程度大きな処理単位での並列性やSIMDが適用できるところを探すといった内容のようです．面白そう．
で，なぜリファラが？と思ったら，
＞逆アセンブラとしては、dispeを利用する予定である。このアセンブラは単なるバイナリ単位の１ライン逆アセンブルではなく，人間が解析するように命令の流れを追ってコード領域やデータ領域を判別してくれるため、後の中間表現の導出に役立つ。
使っていいのか！？
バグ出たらすみません．

1年ぶり以上にmodpをアップしました(modp20040829.zip)．
あまりにも時が経ちすぎて，どこがどのように変わってるのか自分でも分からない．
というよりあまり変わってないというのが正解か．
エミュ関係を削ったmodpLiteなんてのも作ったけど，ライトな割にはでかいし，あまり意味がなさそうだ．
DirectX関係を全て削ったらもっと小さくなるだろうけど，そこまで軽くて小さいのがいいならfoobarとか使えばいいんだし．これまた意味がない．
というかそれくらいなら一から作り直したほうが良いのができるからそうする．
みたいな感じで，だんだん方向性が怪しくなってきましたが，これからも自分がやりたい事を自分の手に馴染む様に実装していくだけです．
年一回くらいのペースで！