Revolutionaly Compressing Software FZSS

インターネット時代を見据えた次世代圧縮技術
はじめに
電子情報社会化の進む現代では、さまざまな種類の膨大なデータが世界中を駆け巡っている。これらの膨大なデータを、通信網の負担を軽減しつつ効率的にやり取りするために不可欠なのが、データ圧縮の技術である。
現存の圧縮技術の方法論
では、現在データ圧縮にはどのような技術が使われているのであろうか。
まず、データ圧縮技術の基本として、データの中身を別の符号に置き換えてその容量を減らす、データの符号化が挙げられる。例えば、仮に
「怪人ゲグ怪人ゲグ怪人ゲグ怪人ゲグ怪人ゲグ」
という、半角換算で40文字のデータがあったとする。この場合、「怪人ゲグ」という文字列が重複している。そこで、例えばこれを「\1」という文字列に置き換え、その繰り返し回数を「*n(nは繰り返し回数)」で表すと、上の文字列は
「\1*5」
と、わずか半角４文字の記号で表記できるのである。なお、これは例に過ぎず、実際には、もっと複雑な符号化アルゴリズムが用いられる。
次に、映像や音声のように、元のデータ量が膨大でなおかつ微妙なデータの変質が許容される種類のデータについては、より思い切ったアプローチが試みられる。不可逆圧縮技術において用いられる、冗長情報の削除である。
たとえば、音声圧縮技術で有名なMP3の場合、音声の元データを「逆コサイン変換」という手法によって周波数成分に分解し、なおかつ人間の耳では聞き取れない周波数成分（これが「冗長情報」）を切り捨てる、という手法を用いている。
この手法によって圧縮されたデータでは、もとのデータの一部分が変質してしまう。このため、解凍後も元のデータと全く同じ情報を必要とする、例えば文書のようなデータの圧縮は不可能である。しかし、このようなデータの不可逆性と引き換えに、より高い圧縮率が得られるという特徴がある。
現代の圧縮技術の課題
現在では、音声・画像など情報量の多いマルティメディア関連のデータが、より重要性を増している。また、これらのマルティメディア関連データには、必ずしも可逆性は必要ない。それゆえ、将来における圧縮技術も、圧縮率重視の不可逆圧縮が主流になっていくであろう。　　
そして事実、画像のjpeg,音声のMP3という優れた圧縮方法が存在している。その圧縮率は、例えばmp3による128kbpsの圧縮で、元データの１０分の１以上にまで達する。*0.1
しかし、既存の圧縮技術にも課題がある。
まず第一に、クロック数が１ＧＨｚを超えようかという現在のCPUでは、既存の不可逆・高圧縮な圧縮方法をもってしても、まだその処理能力に余裕がありすぎるのである。たとえば、mov形式で圧縮された動画を再生する場合ですら、当研究所のパソコン*0.2のCPUパワーをわずか10%程度*0.3使用するに過ぎない。
一方で、音声だけのMP3ですら、ステレオで聞くに堪える音質でストリーミング演奏を楽しむには128kbps、即ちISDN回線をMP（マルチキャスト）で接続してやっとぎりぎりの高速な回線が必要とされる。
すなわち、現在の圧縮技術には、圧縮率がインターネット回線の速度に対して不十分だという、重大な課題が存するのである。そして、CPUの処理能力に余裕があることに鑑みれば、よりCPUを酷使し、圧縮率を高度化した圧縮技術が求められているといえる。
藤木総研の圧縮技術"FZSS"
このような課題に鑑み、既存の圧縮技術を応用して当研究所が開発したのが「FZSS」である。
ご存知のように、パソコンで扱われる全てのデータは結局２進数、すなわち０と１の羅列で表される。しかし、果して「空」のデータである「０」は必要不可欠だろうか？たとえば
「あした天気になれ」
というデータと、
「あ　し　た　天　気　に　な　れ」
というデータに、内容の差はあるのか。たしかに、文字数や受ける印象など、細かな違いはあるといえよう。しかし、そのような差はまさしく削除してしまってかまわないレベルの問題に過ぎない。もうお分かりだろう。２進数における「０」は、不可逆圧縮において削除すべき「冗長情報」なのである。
また、データの全ての要素が「１」となれば、同一情報の重複が生じる。そこで、重複情報を「符号化」することにより、さらに圧縮率を高めることが出来る。
これらの点を踏まえて、FZSSでは、以下のような圧縮アルゴリズムを採用している。
（１）データの中の冗長情報である「０」の要素を
　　　ビット単位で除去し、中身のある「１」のデータだけを抽出。
（２）次に、２ビット単位で「１１（２進法）」となるデータを、
　「１０」に符号化する。*1
この単純なアルゴリズムによるFZSSの圧縮率は、理論上ほぼ５０パーセントに過ぎない。この圧縮率では、現存の圧縮方法よりも優れているとは到底いえない。
しかしながら、FZSS方式では、（２）の作業によって、圧縮後もファイル容量のほぼ半分は、冗長情報である「０」で占められることになる。そこで、再圧縮により、さらに圧縮後のファイルの半分にまで圧縮が可能となる。そして、これを何回も繰り返すことにより、FZSSでは全てのデータを最小で１ビット（！）にまで圧縮することが出来るのである。
また、このアルゴリズムを最大圧縮のために最適化した「FZMX」も、同時に開発した。
これらのFZSS系の圧縮技術には、以下のような特徴がある。
（１）最大１００パーセントに近い、驚異の圧縮率
（２）圧縮後データの類似性による、極めて優れた元データの秘匿性
（３）CPUパワーと必要圧縮率との兼ね合いによる最適な圧縮率の実現が可能
そして、フリーなインターネットの発展に資すため、当研究所では、これらの資産を広く無料で公開することとした。改良、再利用などは当方の承諾なしでご自由になさっていただいてかまわない。
なお、今現在入手可能なバージョンとプラットフォームは以下のとおり。

FZSS

Ver 1.00
BeOS5 (zip形式：ソース＋実行ファイル）

Ver 1.01
Linux (tar.gz.形式：ソース＋実行ファイル）
Windows (LHA形式：ソース＋実行ファイル)
X680x0 (LHA形式：ソース＋実行ファイル）

FZMX
Ver 1.00
Windows (LHA形式：ソース＋実行ファイル)
C source (html版。おそらく全機種共通)
使用方法：
解凍（必要・お望みならコンパイルも）の上、シェル（ターミナル）ないし
コマンドプロンプト上から実行ファイルを実行。
ファイルネームを聞いてくるので、それを入力。
エラーメッセージが出るか、圧縮ファイルが完成して終了。なお、圧縮後のファイル名は現在のところtest.fzzまたはtest2.fzzに固定。ソースはあるのでお好みに合わせてご改造あれ。*2

開発履歴
FZSS
ver 1.00
とりあえず動作。なお、BeOS版がver1.00のままなのは、
パーソナルユースを前提としたBeOSではセキュリティーの問題は
生じないだろうとの考えによる。
ver 1.01
Linux、WinNTのセキュリティー確保のため、gets()をfgets()に変更。
その後にコンパイルしたX68000もその恩恵を受けている。
FZMX
Ver 1.00
動作するようにする。
元ファイルの終了判定に用いる関数をfeof()からfilelength()に変更。
コンパイル環境（全部無料・通信費除く）
Linux :
CorelLinux SE (Debian-based ; Kernel-2.2.14)
http://linux.corel.com/

Laser5Linux6.2(Amatsukaze)でも動作確認済み
http://www.laser5.co.jp/

BeOS :
BeOS5-DevTools
ftp://ftp.be.com/pub/beos/BeOS5-DevTools.zip

Windows
Borland C++(FreeVersion) 5.51
http://www.borland.com/bcppbuilder/freecompiler/cppc55steps.html

X68000
C Compiler PRO-68K ver2.1 on Human68k 3.0
http://www.nifty.ne.jp/forum/fsharp/
Virus Check:
NortonAntiVirus2001 and VirusDefinitionFile of 22Jan.2001
----footnote------
*0.1　当研究所による実測値。
*0.2　Pentium!!! 733MHzの自作機。
*0.3　BeOS5 PersonalEditionでの、Pulseによる目測値。
*1　なお、こうすると、もともと「１０（２進法）」だったデータとの区別が
出来ないと思われる向きもあるかもしれない。
しかし、FZSSではあらかじめ下位ビットに１の要素を集中させているため、
符号化前の元データに「１０」というデータはあり得ず、このような
問題は生じないのである。
*2　藤木総研では、FZSS、FZMX両技術によって圧縮されたデータを
解凍できる優秀な解凍技術者をボランティアで募集している。
われこそはと思われる方はメールして頂きたい。

戻る