こんばんは、川合です。
bim2bin4dの結果にそこそこ満足していた僕でありましたが、5/19に
対象ファイルによってはtek0よりも圧縮率が悪くなることが、2chのOSA
SKスレッドの406さんによって報告されました。なんと5KB以上もtek1が
負けているのです。1MBに対して5KBですから、実に4%もの差です。
これはよろしくないと思い、tek1からそういう弱点を取り除けるよう
にフォーマットを（またしても）改定し、ついに最悪でもtek0とほぼ同
等サイズになるようにできました。ということでbim2bin4dとの互換性
はまたなくなりました。すみません。
またtek1ではビットストリームとバイトストリームを分割している関
係上、もしファイル破損で後ろが切れてしまったら、しかもそのせいで
バイトストリーム部分が全部失われてしまったら、なんと1バイトも展
開できないというさみしい性質があります。この点だけならtek0のほう
がましなのです。・・・で、これを回避するにはtek0のように全部ビッ
トストリームにしてしまえばいいわけです。ということで、そういうモ
ードも選べるようにしました。tek2です。
tek2ではtek0のように無圧縮部分を8bitずつ出力するのではなく、出
現頻度を解析して、頻度の高いものには短い符号、頻度の低いものには
長い符号を割り当てるという、なんかハフマン符号を思わせるような、
そんな方法でデータを格納しています。だからtek1よりもtek2のほうが
コンパクトになります。展開速度は、tek0より速いけどtek1よりは遅い
、といったところでしょうか。・・・なお、もちろんハフマン符号は使
っていません。tek1用のルーチンを流用してそれっぽいことをやってい
るだけです。ということでハフマン符号ほどには縮みません。
僕の推奨としては、デフォルトはtek2、破損とかはあまり気にしない
し圧縮率が少し下がっていいから少しでも速く展開したいという場合は
tek1、tek0とL2D3はもう過去の互換性以外には出番なし、という風に考
えています。
tek2とtek1の違いは無圧縮部分をバイトストリームに入れるかどうか
だけが違って、他は同じです。だからどちらもブロックごとに展開可能
です。OSASKやKHBIOSでもtek1だけではなくtek2もサポートします。tek
2の展開ルーチンはほとんどtek1と同じですので、うまく書けばtek2の
サポートを加えてもたいした量にはなりません。
http://k.hideyosi.com/bim2bi4e.lzh (35.9KB)
---
さて新tek1やtek2がどの程度のものなのか、例によって比較表を作
りました。今回は、bz2(-z -9)だけではなく、RK(-c -mx3)も挙げるこ
とにしました。RKは、圧縮時にも展開時にもたくさんの時間とメモリ
を使う代わりに、驚異的な圧縮率をたたき出します。bzip2がかすみま
す。たぶん最強です。フリーソフトで、以下のページからダウンロー
ドできます（rk104a1w）。
http://rksoft.virtualave.net/downloads.html
今回はこれを圧縮限界とみなして、それにどこまで近づいたのか、
という指標で考えてみたいと思います。
org tek0 tek1 tek2 bz2 rk
hellok1 272 128 126 125 166 208
zero4k 4096 27 25 25 43 100
zero64k 65536 28 27 27 43 108
bim2binc 53792 15091 14744 14392 12903 11608
kdun00b 655360 46246 45788 44820 47306 36736
osaskgo 1973741 1149662 1149672 1145810 1047411 909824
bim2bincはbim2bin4cのときのものです。tek1、tek2でのbsizは基本
的にファイルサイズ以上にしていますが、tek2には例外があって、
kdun00bはbsiz:64k、osaskgoはbsiz:256kの時のほうが圧縮率が良かっ
たのでその値を書いています。
またしつこくzero4kやzero64kなどというファイル圧縮としては非現
実的なものが対象になっているのは、tek1やtek2もOSASKのスタティッ
クデータ初期化用APIとしての任務があり、そのときに典型的なこれら
に対する挙動は決して軽視できないと僕が考えているからです。
とりあえず、圧縮後のサイズが100バイト前後になるものについては
bz2やRKの出番はなく、tek2がベストの値を出しています。そしてそれ
以外では、RKがぶっちぎりの圧縮率を出しています。osaskgoなんて、
bz2の結果でさえ、「なんでそこまで縮むんだよ！」と思わずツッコミ
たくなるものでしたが、RKを見るともやは言葉を失います。rk.exeは
せいぜい83.5KBのソフトウェアなんですがねえ・・・。いったいどん
な仕組みがあるのやら。
一応RKに対して弁護しておくと、RKはLHAのように書庫をサポートし
ているので、展開後のファイル名などを保持しています。そのせいで
圧縮結果が極端に小さくなるものでは不利なのだろうと思います。
さてこれをorgを100にした比率にすると、次のようになります。
org tek0 tek1 tek2 bz2 rk
hellok1 100.00 47.06 46.32 45.96 61.03 76.47
zero4k 100.00 0.007 0.006 0.006 0.010 0.024
zero64k 100.00 0.000 0.000 0.000 0.001 0.002
bim2binc 100.00 28.05 27.41 26.75 23.99 21.58
kdun00b 100.00 7.057 6.987 6.839 7.218 5.605
osaskgo 1973741 58.25 58.25 58.05 53.07 46.10
そして最小のものを100にした比率にすると、次のようになります。
org tek0 tek1 tek2 bz2 rk
hellok1 217.6 102.4 100.8 100.0 132.8 166.4
zero4k 16384 108.0 100.0 100.0 172.0 400.0
zero64k 242726 103.7 100.0 100.0 159.3 400.0
bim2binc 463.4 130.0 127.0 124.0 111.2 100.0
kdun00b 1784.0 125.9 124.6 122.0 128.8 100.0
osaskgo 216.9 126.4 126.4 125.9 115.1 100.0
orgを100にしたものはいわゆる圧縮率ですが、はっきりいってあまり
面白くはありません。むしろ面白いのはこの最小100方式で、これをみ
ると、たとえばtek0はベストなものとくらべて30%ほど大きくなること
がある、ということが分かります。bz2も、まあhellok1〜zero64kにつ
いては無視するにしても、最大で28.8%ほど大きくなるという不名誉な
結果になっています。というかRKが偉大すぎるのでありますが。
そういうふうに見れば、なるほどtek2はいい感じです。最大でも+26%
です。これは安定しているといえるでしょう。アルゴリズムも相変わら
ず単純ですし、展開速度もtek0より速いくらいなのですから、これでこ
の成績なら合格でしょう。
次はOSASKアプリです。
tek0 tek1 tek2 tek0→tek2での改善率
helloc4 497 492 490 1.41%
helloc9 176 174 172 2.27%
bballc0 628 620 619 1.43%
bballc2 295 293 291 1.36%
invader2 1699 1685 1670 1.71%
invader5 1258 1246 1243 1.19%
ということでいい感じでサイズが下がっております。何の苦労もしな
いで1%程度アプリをコンパクトにできるわけです。
おまけでやってみました。先ごろリリースされたI.Tak.さんのUNICOD
E0.MAPです。
org:262144 tek0:22206 tek2:21180(-4.62%)
ということでOSASKがtek2をサポートすれば1KB以上小さくできます。
たぶん今度こそこれでフォーマット確定です。なお、tek1とtek2は圧
縮ルーチンを賢くすることで、もっと圧縮率があがります（展開ルーチ
ンの変更なしに）。そこまで作りこめていないのです。すみません。と
りあえずフォーマットだけでも早く決めてしまいたかったのです。
・・・でも、展開ルーチンのほうも手抜きなので、圧縮ルーチンが賢
くなりすぎると展開できなくなったりもしますが。とにかくフォーマッ
トの互換性は保たれるので気長に改良することにします。
さすがに疲れてきたので、たぶんOSASK ver.4.6はこのtek1、tek2関
連のサポートだけになるでしょう。すみません。まあこれもKHBIOS関連
といえなくもないですが。
なお一部で話題になっているbim2binの圧縮速度ですが、オプション
maxdis:4k を付けたりすれば、圧縮率は下がるもののとりあえず圧縮速
度は上がります。開発中はこれにして、リリース時にのみちゃんと圧縮
するといいかもしれません。・・・まあ、もちろん圧縮ルーチンをまと
もにするほうがいいのでありますが（どうもフォーマットを確定するほ
うに興味が行ってしまって、圧縮ルーチンをまともにするほうがお留守
になりがちなんですよね・・・）。
それでは。
--
川合 秀実(KAWAI Hidemi)
OSASK計画代表 / システム設計開発担当
E-mail:kawai !Atmark! osask.jp
Homepage http://osask.jp/