JP4091990B2 - データ符号化ネットワーク - Google Patents

Description

発明の背景
高性能データ圧縮システムは、値を予測する能力を高めるデータのモデルを使用し、これにより圧縮度が逆に高められることになる。最良のモデルは、特定のデータフォーマットをサポートするための圧縮システムを構築することにより実現する。特定のファイルの中のデータから粗モデルを誘導することを試みる代わりに、フォーマットに固有の圧縮システムは、精密な予め定められたモデルを提供することができる。モデルは、ファイルフォーマット構造そのものに限らず、サンプルデータベースから集められた統計データをも利用することができる。
従来のフォーマットに固有の圧縮における試みは、多くのフォーマットに適合する汎用法の開発よりも、僅かな固有のフォーマットに対する解を見出すことに集中していた。作り出されたモデルは、通常極めて僅かな数のコンポーネントを含むに過ぎない。大抵は赤、青および緑のピクセル値を持つイメージファイルのようなデータの大部分が僅かなコンポーネントの中に含まれる時には、前記のモデルで充分間に合う。しかし、多くのフォーマットは、多量のコンポーネントを用いなければ最良のモデル化は不可能であり、従来のシステムは、このようなモデルを構築またはエンコードするようには設計されていない。
発明の概要
本発明による好ましい符号化システムは、公知の技術のこれらの２つの問題を解決する。システムは、広汎なフォーマットを扱うのに適合した汎用解法を提供し、多数のコンポーネントを使用するモデルを効果的に扱う。システムは、多くのレベルで、すなわち、最高（インタフェース）レベルから最低（コアーエンコードアルゴリズム）レベルまでにおいて、新しいアプローチを使用する。符号化ネットワークは、データをエンコードするための圧縮ネットワークと、データをデコードするための伸張ネットワークとを含む。
最高レベルでは、本発明による好ましい圧縮システムは、Ｂａｓｅ−Ｆｉｌｔｅｒ−Ｒｅｓｏｕｒｃｅ（ＢＦＲ）システムと呼ばれるアーキテクチャーを使用する。このアプローチは、フォーマットに固有の圧縮の利点を、広汎のデータフォーマットに用いられる汎用圧縮ツールに統合する。前記システムは、そのそれぞれが例えばＥｘｃｅｌ ＸＬＳワークシート、またはＷｏｒｄ ＤＯＣファイルのためのような特定のデータフォーマットをサポートするフィルタを含む。ベースは、システムコントロールモジュールおよびすべてのフィルタにより用いられるライブラリを含む。リソースは、一つ以上のフィルタにより使用されるが、ベースの一部ではないルーチンを含む。エンコードされるべきデータのフォーマットに合致するフィルタが設けられる時には、フォーマットに固有の圧縮の利点は、このデータに対して実現することができる。しかし、前記以外では、他の固有でないデータ圧縮システム（ＰＫＺｉｐ、Ｓｔａｃｋｅｒ等のような）に類似の性能を達成する“汎用的な”フィルタが用いられる。
次のレベルでは、システムは、ソースデータを個々のコンポーネント（要素）に分解するための方法を含むのが好ましい。“ストラクチャーフリッピング”と呼ばれる基本アプローチは、フォーマット情報を圧縮モデルに変換するための鍵を提供する。ストラクチャーフリッピングは、通常分離される類似のコンポーネントが同じグループに入れられるように、情報をファイルに再構築する。
この基礎の上に、下記のような多くのツールが設けられている。
−分解ルーチンの作成を簡単にするための言語。
−この方法を用いてソースデータを別個のコンポーネントに分解するためのツール。
−サンプルデータベースの自動的な解析による個々のコンポーネントに対するモデルの作成のためのツール。
これらのツールは、広汎なファイルおよびデータタイプに対するフィルタに適用することができる。
圧縮システムは、特定のフィルタおよびあるタイプのフィルタのためのカスタマイズされたアレー（配列）変形器と呼ばれるツールを含むのが望ましい。これらの技術は、特定のファイルタイプまたは幾つかのファイルタイプにより用いられるあるデータ構造を、多くのデータベースフォーマットに見られるデータの２次元配列をエンコードするように、取り扱う。
システムの低レベルでは、下記を含むデータ配列をエンコードするための多くのメカニズムが存在するのが望ましい。
−新しい低レベルエンコードアルゴリズム。
−多数のトランスフォームとエンコードアルゴリズムを統合するための方法。
−小さいデータブロックが効果的に符号化できるようにオーバーヘッドを除去するための方法。
−静的モデル（サンプルデータベースの統計的解析から求められた）および動的モデル（特定のアレーの中でのデータに適用される）を各コンポーネントのエンコードに統合するための新しい方法。
ソースデータのエンコードの好ましい方法は、ソースデータの多数のブロックへの分解を含む。分解されたブロックは、通常ソースデータフォーマット以外のフォーマットを持つ。特に、ソースデータからの類似のデータが集められ、それぞれのブロックにグループ分けされる。
各ブロックに対し、圧縮アルゴリズムは、多数の候補圧縮アルゴリズムから選ばれ、ブロックに適用される。圧縮アルゴリズムは、該当ブロック中のデータの量に基づいて決めることができる。さらに圧縮アルゴリズムは、カスタマイズされた変形の使用を含め、該当ブロックに適用することができる。アルゴリズムの選択は、ソースデータのフォーマットから誘導される圧縮モデルにも基づくことができる。多数のブロックからの圧縮されたデータは、次にエンコードデータに結合される。
符号化ネットワークは、また符号化されたデータをソースデータに戻すための圧縮解除ネットワークをも含む。最初にデータが解読され、次に分解が反転される。ロスのないシステムでは、得られたデータはソースデータと同じである。
本発明の実施形態は、ＣＤ−ＲＯＭ、フロッピーディスク、ハードディスク、またはその他の機械での読取りの可能な配付媒体上に、機械で読取りの可能なフォーマットで書き込まれた、機械で実行できる命令の形態を持つことが望ましい。これらの命令は、圧縮および伸張ネットワークを実行するための一以上のプロセスユニットにより実行される。
【図面の簡単な説明】
本発明の前述のおよびその他の目的、特徴ならびに長所は、本発明の下記の好ましい実施形態の詳細な記述から、添付の図面に図示されるように、明らかであり、図面においては、共通の部分には共通の記号が付されている。図面は、必ずしも厳密な縮尺を用いておらず、むしろ本発明の原理を示すために誇張されている。
図１は、代表的なデータ圧縮システムの高レベルブロック図である。
図２は、本発明によるＢＦＲシステムを用いた好ましいエンコーダのブロック図である。
図３は、アレー符号器のフローチャートである。
図４は、図３の文字列符号器４０のブロック図である。
図５は、図３の浮動小数点符号器５０のブロック図である。
図６は、好ましい自動化された解析システムのフローチャートである。
図７は、整数符号器の高レベル状態を概観するフローチャートである。
図８は、整数符号器の中レベル状態を概観するフローチャートである。
好適な実施形態の説明
図１は、代表的なデータ圧縮システムの高レベルブロック図である。システムの主要な構成要素は、送信アプリケーション１、エンコーダ３、デコーダ５および受信アプリケーション７である。
送信アプリケーション１は、エンコーダ３によりエンコードされるソースデータ２を提供する。送信アプリケーションは、ファイル保管、通信システム、又は元のフォーマットよりも少ないバイトを使用するデータ表現することを必要とする他のアプリケーションとなりうる。
エンコーダ３は、ソースデータ２を受信し、少ないバイトを用いてデータを表現する為のデータ圧縮アルゴリズムを使用する。エンコーダ３の代表的な実現は、汎用コンピュータ上で動作するソフトウエアとしてであるが、記載されるアルゴリズムは特殊化されたハードウエア上でも実現できる。
エンコーダの出力は、エンコードされたデータ４であり、これはメモリに格納されることができるか（この場合には、エンコードにより同じハードウエア中により多くのソースデータを格納することができる）、又はデコーダ５に送られる（この場合には、転送チャネル帯域幅が限られている時には、高速に転送にされるソースデータをエンコードする）。
デコーダ５は、エンコードデータ４を検索、又は受信し、データをエンコードする為に用いられたアルゴリズムを逆にしてソースデータをデコードデータ６として再構築する。ロスのないシステムにおいては、デコードデータ６はソースデータと同一である。しかし、アプリケーションによっては、或る程度のデータのロスは容認することができる。エンコーダ３を用いる場合のように、デコーダ５は、汎用コンピュータにおいて動作するソフトウエアとして通常実現されるが、特殊化されたハードウエアにおいて実現することができる。
受信アプリケーション７は、デコードデータ６を処理の為に受信する。
好ましい圧縮エンジンは、フィルタを基礎とするエンコーダとデコーダを有し、これらは多数の送信アプリケーション１と受信アプリケーション７により利用することができる。エンコードされたデータを格納／検索、又は送信／受信するアプリケーション１，７は、圧縮システムの一部ではないが、これらアプリケーションは、利用可能な転送チャネルの帯域幅のようなシステムの状態によってエンコードおよびデコード動作を調整することができる。
次の記載は主としてエンコーダを対象とする。デコーダは、エンコーダの動作の逆の動作を行うに過ぎず、従ってエンコーダの記述は、エンコード／デコードシステム全体を記載するのに十分である。用語“ファイル”は、ソースデータのブロックを記載するために用いられ、これは従来の用法に適合するが、クライアントサーバーアプリケーションのデータ交換のようなデータブロックの他の多くのタイプに適用することもできる。
エンコーダ
図２は、本発明によるＢａｓｅ−Ｆｉｌｔｅｒ−Ｒｅｓｏｕｒｃｅ（ＢＦＲ）ネットワークを用いる好ましいエンコーダのブロック図である。エンコーダ３’は、特定のファイルフォーマットを提供する複数のフィルタ１０ａ，…，１０ｘ，…，１０ｚの使用を基礎としている。例えば、一つのフィルタ１０ａは、ＤＢＦデータベースフォーマットの幾つかのバージョン（変形）をサポートすることが考えられるのに対し、別のフィルタ１０ｚは、マイクロソフトのワードソフトウエアプログラムにより用いられるＤＯＣフォーマットの幾つかのバージョンをサポートすることができる。個々のフィルタは、フィルタ選択システム２２にそれぞれの選択規則１２を提供する。
フィルタ選択システム２２は、ソースデータ２を受信し、システムにインストールされたべてのフィルタ１０ａ，…，１０ｘ，…，１０ｚの選択規則１２ａ，…，１２ｘ，…，１２ｚをチェックして、ソースデータのフォーマットをその規則の何れかがサポートするか否かを認める。フォーマットがサポートされない場合には“汎用”システムが用いられ、Ｌｅｍｐｅｌ−Ｚｉｖ（ＬＺ）エンジンのような他の汎用圧縮システムと同様の圧縮性能を提供する。本発明の特定の好ましい実施形態では、汎用的な圧縮システムは、その教示が本明細書に参照としてすべて取り入れられている１９９７年１１月１４日に出願された米国特許出願第０８／９７０，２２０号においてシンドラー（Ｍｒ．Ｓｃｈｉｎｄｌｅｒ）により記載されたＳＺＩＰエンジンを使用している。ネットワークの記述は、主としてデータフォーマットをサポートするフィルタが首尾よく見出される状況を包含する。
簡単に説明すれば、分解システム２４は、ソースデータ２を多数の分解されたアレー２５に分解し、上記のアレーの各々は、ソースファイルの中の特定のコンポーネントのすべてのインスタンスを含む。以下に更に詳述されている用語「アレー（Array）」は、用語「配列（array）」の通常の用法と異なり、ネットワークに特定の構造体のタイプを指すことを示す為にカタカナ（大文字）にされている。ソースデータ２を分解する為に用いられるアルゴリズムは、以下に更に詳述される「ストラクチャ（構造体）フリッピング」と呼ばれるネットワークの重要な構成である。
ＢＦＲシステムは、アレー２５が配列符号器２８で符号化される時に用いられる各アレー２５用モデルを確立する為に、自動化された解析システム（以下に詳述されている）を使用する。場合によっては、カスタマイズされた配列変形器２６が最初に用いられると、更に良好な圧縮が得られる。自動化された解析システムにより生成されたモデルは、各コンポーネントアレー２５を個別に処理するが、カスタマイズされたルーチンは、コンポーネント間の関係を利用することができる。
配列符号器２８は、静的モデル（すべてのデータベースに対して一定）と各特定のアレー２５に対する動的調整の混合体を含む、数に依存するモデリングシステムを用いるアレー２５をエンコードする。
フィルタ１０ｘは、エンコーダ３’の４つのセクションの各々をサポートする為の構成要素を有する。ファイルフォーマット仕様により決まる選択規則１２ｘは、ファイル、又はファイルタイトルサフィスの先頭のバイト値のようなフィルタ１０ｘにより提供されたファイルを認識するのに必要な情報を含む。ファイルフォーマット仕様によって、さらに決まる分解命令１４は、ソースファイル中の特定のコンポーネントのすべてのインスタンスを持つ、分解アレー２５にソースファイルを分解するのに必要な情報を含む。カスタムコンポーネントモデル１６は、ファイルフォーマット仕様およびサンプルデータベースの両者を参照することにより構築される。それらは、コンポーネントアレー２５のいくつかを更に圧縮し得るものにするように変形させる為に、コンポーネント間の関係を利用することができる。エンコード用パラメータ１８は、多数のサンプルデータベースから分解されたコンポーネントアレー２５を検査する自動化された解析システムにより生成される。エンコード用パラメータ１８は、配列符号器２８中の数に依存するモデリングシステムをサポートする為に必要なデータを提供する。
フィルタ選択システム
好ましい圧縮システムは、フィルタ１０を追加、又は入れ替えることにより、ユーザーが新しい、又は更新されたフォーマットをサポートすることのできる拡張可能なアーキテクチャを使用する。上述のように、フィルタ１０は、一つ以上のフォーマットをサポートすることができる。例えば「ロータス１２３バージョン４（ＬＯＴＵＳ １２３ｖ４」と呼ばれるフィルタは、現行のＷＫ４フォーマットおよび以前のＷＫ３およびＦＭ３フォーマットのようなロータス１２３プログラムに関連するすべてのファイルフォーマットをサポートする。フィルタが新しいロータスＷＫ５フォーマットに対して後に開発された時には、ユーザーは古いフィルタを、新しいフォーマットをサポートするフィルタに取り替え、また、このフィルタは古いフォーマットに関する以前のフィルタに、後退的に適合できる。
マイクロソフトウィンドウズ（Ｗｉｎｄｏｗｓ）環境では、各フィルタは別個の動的リンクライブラリ（ＤＬＬ）ファイルである。データテーブルのほかに、フィルタは実行可能な符号を含む。あるファイルに対するフィルタが見出されると、動的にリンクされ、次にファイルをエンコードする為に呼び出される。エンコードされたデータのストリームは、何れのフィルタがデータをエンコードするのに用いられたかを示す識別子（ＩＤ）符号を含み、デコーダは対応するデコードフィルタを有する。
フィルタ選択システム２２を実施する為に、ベースモジュールは、現在インストールされているファイルの登録を保持し、このファイルは、ＤＬＬのパスのほかに、ソースファイルタイプを識別するのに必要なデータを含む。この登録は、フィルタが追加されるか、又は取替えられるたびに更新される。識別データは、ファイルタイトルサフィスのリスト、およびファイルの先頭近くのバイト値によってファイルを識別する方法を含むことができる。識別手順は、多くのフィルタがインストールされた時にリストをチェックする時間を短縮するサーチツリー法を用いる。この登録から、適切なフィルタ１０がフィルタタイプに対して呼び出される。
マイクロソフトのＯＬＥ２のような混合ファイルフォーマットを扱う為に、一つのフィルタが、混合ファイル中のサブファイル、又はストリームをエンコードする為に別のフィルタを呼び出す。例えばウィンワード（Ｗｉｎｗｏｒｄ）フィルタは、混合ドキュメントファイルの中に埋め込まれていたエクセル（Ｅｘｃｅｌ）データをエンコードする為のエクセル（Ｅｘｃｅｌ）フィルタを呼ぶことができる。
分解システム
上述のように、分解システム２４は、多数の分解されたアレー２５を作り出す。各分解されたアレー２５は、ファイル中の特定のコンポーネントのすべてのインスタンスを含む。各決められたされた構造体タイプの各メンバに対して、別個のコンポーネントが作り出される。
実施例１
例えば、ファイルフォーマット記述において決められたレコードの下記の記述を考える。
セル値：
フォーマットは、メモリとディスクスペースを節約する為に、ＲＫ番号と呼ばれる内部番号タイプにおける番号を符号化する特別な方法を使用する。
レコーダデータ：

分解システム２４は、このレコードの４つのコンポーネントの各々に対する分解されたアレー２５を作り出す。ＲＫレコードが見出される度に、エントリが各アレーに加えられる。分解されたアレー２５は、５つのレコードからのデータによって示されるように、未処理ソースデータよりもさらに圧縮が可能である。

ソースデータは、バイト合致アルゴリズムに対してほぼランダムに現れる（１６進法で示された）。
01 00 02 00 55 00 00 e1 f1 3f 01 00 03 00 5f 00 00 a3 f1 3f 01
00 04 00 53 00 00 d0 f1 3f
01 00 06 00 5f 00 00 c4 e1 f1 3f 01 00 07 00 5f 00 00 d3 f1 3f
各コンポーネントに対して最適化されたアルゴリズムを用いて４つの別個のアレー２５（列、行、インデックスおよび数値）として扱われる時には、データは十分に圧縮されることができる。この手法は、本明細書中では、データを再配置する方法のために、「構造体フリッピング」と称される。
データベース中の同一のコンポーネントのインスタンスを共にエンコードすることは、一般的な圧縮技術であり、ファイルフォーマットは、しばしばこのようなコンポーネントを識別するのに用いられる。しかし、従来技術では、この手法は特定のファイルフォーマットの少しの主要なコンポーネントを分離することに制限されており、又ファイルフォーマット記述は、これらの主要なコンポーネントを見つける為の技術としてのみ使用されてきた。本発明の好ましい実施形態によれば、ファイルフォーマットは、実際に、圧縮モデルに変換され、次に、データを解析して各コンポーネントの符号化性能を最適化するために、この圧縮モデルが自動化されたシステムにインターフェースされる。この圧縮モデルは、カスタマイズされた配列変形器２６によって、通常、圧縮度を高められるが、それは、システム全体の一構成に過ぎない。
好ましい手法が従来のシステムと異なる度合いは、それを実施する為に構築された新しいツールに反映されている。この手法は、多数のアレー２５を作り出す。各アレー２５は、異なった圧縮モデルを必要とし、各々のエントリ数は、ファイル毎に大幅に相違する。このような場合に効果的に動作するには、本発明の好ましい実施形態は、オーバーヘッドの除去、数に依存する処理、および固定された符号化アルゴリズムに代わる処理ネットワークの使用のような低レベル符号化の取扱いに関する新しい手法を用いる。上記のこれらの技術は、分解システム２４の出力を取扱う為に好んで用いられる。
これらの実施上の特徴のすべては、高いレベルで統合されて、これにより、高レベルの呼び出しは、システムを初期化し、データを分解し、アレーをエンコードするのに必要な動作のすべてを取扱うことができる。
本発明の特定の好ましい実施形態によれば、ファイル分解システム２４は、３つのサブシステムを用いる。
FILE＿BUFFER 入力／出力インターフェース
ARRAYs 単一コンポーネント用データを格納する
PVSTRUCT 入力をアレーに分解し、又はデコードされたアレーを出力ストリームに書き込む
複数のFILE＿BUFFERルーチンは、FILE＿BUFFER構造体を用いるフレキシブルな入力／出力インターフェースを提供し、したがって、入力／出力フォーマットには無関係に同一の分解ルーチンのセットを用いることができる。これにより、圧縮システムは、入力／出力フォーマットには無関係となる。ファイル分解システムは、好ましくは次の２つのファイルフォーマット、ＤＯＳおよびＯＬＥ２をサポートするが、通信ポートおよび他の入力／出力オプションに対するインターフェースのほかに、他のファイルフォーマットに拡大できる。ＤＯＳファイルに対しては、論理ストリーム位置は、通常、未処理ファイル位置と同じである。ＯＬＥ２フォーマットは、コンテナファイル中のＯＬＥ２ストリームに追随する為に、広範な符号の層を必要とする。
複数のARRAYルーチンが、初期化、データの追加、符号化およびデータのアレーを解放する処理を管理するシステムを提供する。各ARRAY構造体は、アレー２５へのエントリの数、アレーに現在割当てられているバッファのサイズ、およびアレーをエンコードするのに役立つ情報のような、これらの処理を管理するのに必要なデータおよび情報の一つのアレーを含む。
特にARRAY＿XX構造体は、コンポーネントからのすべてのデータを格納し、高速で連続するデータへの読み／書きアクセス、データ用拡張可能バッファおよびモデルデータの格納をサポートするメカニズムを含む。この構造体によれば、また、単純なセットのツールによって、すべての割当て、分解および符号化機能を取扱うことができる。＿XXの表現は、異なった整数ワードサイズ、文字列、および浮動小数点タイプのような異なったデータタイプに対してわずかに異なったARRAY構造体が決められることを示すが、処理ルーチンの多くは、全てのバリエーションに関して機能する。
複数のPVSTRUCTルーチンは、ファイルデータを分解する自動化されたシステムを編成する。エンコードの間、ルーチンは、FILE＿BUFFER構造体からデータを読み出し、データをアレー２５に書込む。デコードの間、PVSTRUCTルーチンは、アレー２５からデータを取り出し、FILE＿BUFFER構造体に書き込む。これらのルーチンは、ファイルフォーマットの高レベル記述を取り出し、分解されたデータのエンコードのほかに、分解の管理に関連するすべてのタスクを取扱う。また、フィルタ１０の多くは、FILE＿BUFFERを呼び出すカスタマイズされた分解ルーチンおよびPVSTRUCTルーチンの使用に直接代わるARRAYルーチンを含む。しかし、分解システム２４の一構成は、PVSTRUCTルーチンであり、この考察は主としてそれらの動作に関するものである。
PVSTRUCT構造体は、ファイルフォーマットで決められたデータ構造体を分解し符号化するのに必要なすべての情報を含む。このPVSTRUCT構造体は、通常、複数のコンポーネントを含み、これにより、各コンポーネントに対する個別のアレー２５を提供し取扱う。用語“PVSTRUCT”は、予測可変構造（Ｐｒｅｄｉｃｔｏｒ Ｖａｒｉａｂｌｅ Ｓｔｒｕｃｔｕｒｅ）から来ており、予測（Ｐｒｅｄｉｃｔｏｒ）は、データのエンコードを助ける為に多数のサンプルファイルを解析することから得られる統計データの使用を指す。また、可変（Ｖａｒｉａｂｌｅ）は、構造体（あるテキストブックでは「動的構造体（ｄｙｎａｍｉｃ ｓｔｒｕｃｔｕｒｅｓ）」と呼ばれている）をサポートすることを示し、コンポーネントの数が各インスタンスに対する実行時間で変化できる。
分解言語は、決められた命令セットであり、PVSTRUCT構造体の分解を特定する簡潔な方法を提供する。命令セットは、広範な動的バリエーションのサポートを含み、コンポーネントの数が、外部因子のほかに、他のコンポーネントのファイル数に左右される場合も含む。決められた値、又は範囲の制約のような、他のファイルフォーマットデータが取り込まれる。命令セットは、また、分解器とフィルタとの間のデータ交換手段を提供する。
圧縮システムは、類似のアイテムをまとめる為に、ファイルを分解することに基づいている。圧縮システムの以下の記述において、実施例は、代表的なスプレッドシートファイルフォーマットに見られる構造体を示す。
実施例２
スプレッドシートファイルは、通常、多数のレコードを含む。各レコードは、レコードのタイプを示す１６ビットワードで始まり、続く１６ビットワードは、レコードの本文のバイト数を示す。次に、ファイル仕様は、レコードの内容を記述する。TABLE SIZEレコードの仕様は次のようなものである。
RecType＝0x402
Rec Body Sixe＝12
レコードデータ：

データには、複数のこのようなレコードが存在できる。複数のレコードが存在する場合には、各レコード中の同一のコンポーネントの値は互いに類似したものになって行く。これにより、圧縮システムは、圧縮比を高める為に、類似性を利用することができる。
圧縮システムは、好ましくは、以下のARRAY＿XX構造体に基づく。
ARRAY＿U8： ±符号なしとしてエンコードシステムによって扱われる８ビットデータアイテム用
ARRAY＿16： ±符号ありとしてエンコードシステムによって扱われる１６ビットデータアイテム用
ARRAY＿32： ±符号ありとしてエンコードシステムによって扱われる３２ビットデータアイテム用
ARRAY＿F32： ３２ビット浮動少数点用
ARRAY＿F64： ６４ビット浮動少数点用（「ダブル」）
ARRAY＿F80： ８０ビット浮動少数点用（「ロングダブル」）
ARRAY＿STR： 各エントリは、その数がサイズ（文字列サイズ）によって与えられる数バイトを含む。
TABLE SIZEレコードに対しては、５つのアレーが作り出される（レコード仕様を参照して）。レコードが分解される度に、エントリは５つのアレーの各々に加えられる。
すべてのレコードが分解された時には、各アレー中のアイテムをエンコードする関数が呼び出される。この関数は、圧縮を最大にする為の多種類の関係を解明する（exploit）ことのできる多数のアルゴリズムを含む。オーバーヘッドが事実上要求されない点で、この実現は極めて効果的である。一つのエントリしか持たないアレーでさえも、効果的に圧縮することができる。分解システムがファイルを膨大な数のこれらの小さいアレーに変形することがあるので、この事は必要である。エンコード関数は、また、データのエンコードが終わった後にデータを解放することができる。
デコード処理は、上記シーケンスを逆にする。最初に、各コンポーネントアレーはデコードされる。次に、分解が逆になされる。
このタイプの分解は、広範囲に行わなければならないが、処理を簡素化するために、多数のツールが用いられる。それらのツールは、vstruct＿defsと呼ばれる命令の使用に基づいている。TABLE SIZE実施例で続けるには、このようなレコードを分解する命令セットは、下記の通りとなる。

vstruct＿def命令は、１６ビット整数である。最初の３つのワードは、必ずレコードに関する一般情報を含む。残りのワードは、このようなレコードが現れた時の処置を自動化された分解システムに教示する命令を含む。この場合には、命令は可能な限り簡単であり、レコードの各コンポーネントに対するデータタイプのリストに過ぎない。分解器は、各コンポーネントに対して一つの配列を作り出し、そのタイプの一つのエントリを、そのタイプのレコードを分解する度に、配列にロードする。
次に、これらの命令に基づいてレコードを分解しエンコードする関数が提供される。さらに、デコード処理が、エンコーダの動作を逆になす。
vstruct＿def命令は、前の実施例よりもさらに複雑な状況を処理することができる。便宜上、これらの命令の構造の概要が次に要約される。１６ビット命令の上位バイトは、下位バイトにより要求されるアーギュメント（argument）である。下位バイトは２つの４ビット符号に分割される。最下位の４ビットは、命令のタイプを記述し、次の４ビットの意味を決める。このビットフィールド構造は、符号の下記の記述の中で使用される１６進法で命令を極めて読み易くする。文字‘ｘ’は、記述される符号ワードに影響を及ぼすことのない１６進値をあらわす。
Bits 0＝3は命令タイプ（opcode）を設定する。
opcode＜＝bの場合には、この値はコンポーネントのデータタイプを示す。上位フィールドは、下記のように使用される。
Bits 8-15は、使用される時には、アーギュメント（ARG）である。
Bits 4-7は、下記のように使用される。
xx0x：単純なエントリ。このタイプの一つのデータアイテムを読む
xx1x：そのタイプのARGエントリを単一アレーに加える
xx2x：複数のアイテムも同じアレーに加えるが、数はDataBuf[ARG]で与えられる
xx8x：値のアイテムは、仕様で限定される。値は、読み出され、チェックされるが、格納される必要はない。
xxfx：値の範囲はデータタイプによって許可される範囲よりも小さく制約される。
ARGは決められた範囲、又は決められたリストを選択する。
opcode＝xxxdの場合：サブ構造体をスタートする
opcode＝xxxeの場合：サブ−サブ構造体をスタートする
opcode＝xxxfの場合：ビット4-7によって決まる特別な命令、タイプである。
xx0x：サブ構造体を終わる
xx1x：サブ−サブ構造体を終わる
xx2x：DataBufに値を加える（位置はARGにより与えられる）
xx5x：外部から与えられたレコード長に残るサイズARGのワード数を格納する
opcodeにより選ばれたデータタイプは、下記のように決められる。
#define CHAR 0
#define UCHAR 0
#define INT16 1
#define UINT16 1
#define INT32 2
#define UINT32 2
#define FLOAT32 3
#define FLOAT64 4
#define FLOAT80 5
#define STRING 6
#define STRINGZ 7
#define SYS＿S1 8
#define SYS＿SZ1 9
#define SYS＿S2 0xa
#define SYS＿SZ2 0xb
エンコーダにおいて、±符号あり整数と±符号なし整数の間の区別はされない。８ビット値は、常に±符号なしとして処理される。１６ビットおよび３２ビット値は、±符号ありとして処理される。この取り決めは、分岐（switch）ステートメントにおけるチェックの為の「場合（case）」の数を少なくするように、ルーチンを簡単化し高速化する為に用いられる。これは、圧縮性能には余り影響を及ぼすことはないが、ファイルデータが分解にも用いられる時（エレメント数がファイルデータの一部である時のように）には注意が必要である。
STRINGZは、ゼロで終る文字列を指す。それらは正規の文字列と同様にARRAY＿STRに格納されるが、分解中の取扱いは異なる。例えば、正規の文字列を分解する時には、文字列の長さが与えられなければならないが、STRINGZは、その長さを見つけることができる。STRINGZは、ゼロで終わるchar（キャラクタ）を格納する必要はない。
SYS＿Sxxタイプは、システム文字列を指す。通常、各pvstructの各コンポーネントは、各々が個別の配列に入れられ、個別に符号化されている点で独立している。小さいが極めて相関度の高い配列を持つことは、エンコードルーチンを用いる時に、数値データに対して極めて有効である。しかし、文字列に対しては、圧縮は複数のレコードからのテキストデータを組合わせるように多くのコンポーネント文字列を単一配列に入れることによって、しばしば改善することができる。システムは、２つの“System”文字列に対して、これらの組合わせコンポーネントを保持することを許容する。これらのシステムデータに加えられた文字列は、正規のタイプまたはSTRINGZタイプの何れも可能である。
説明の為に、２つの簡単な実施例を以下に示す。
実施例３
この実施例においては、特定の位置（location）の水深（depth）が８回にわたり測定され、データベースに格納される。
レコードコンポーネント
int16 locationX （位置X）；
int16 locationY （位置Y）；
int16 depth[8] （深さ[8]）；
深さの測定は、極めて類似するため：それらを単一のアレーに入れ様とするものである。命令セットは、次の通りとなる。

但し、0x811は、
xxx1：データタイプはINT16である
xx1x：各レコードにおけるこのコンポーネントに対するインスタンス数はAGRによって与えられる
08xx：ARG＝８
実施例４
この実施例では、レコードは、ある人の友達（friend）の年令（age）を格納する。
レコードコンポーネント
int16 num＿friends （友人番号）；
uchar ages[num＿friends] （年令[友人番号]）；
この場合のような、サイズの可変な配列は、‘Ｃ’プログラミング言語の構造体内で宣言できないが、しばしばファイルフォーマットにおいて起こる。このタイプの構造体は、動的構造体と呼ばれる。これは、命令セットにより分解することができる。

但し、0x12fは次の通りである。
xxxf：特別な命令
xx2x：ARGによって特定されたレジスタの中の以前の命令によって分解されたデータ値を格納する
01xx：ARG＝１の時は、レジスタ１を使用する
および0x120は次の通りである。
xxx0：データタイプはucharである
xx2x：複数エントリ、レジスタ内に見つけられる数はARGで与えられる
01xx：ARG＝１の時レジスタ１を使用する
レジスタは、PVSTRUCT構造体の一部として割当てられ、レコードを処理している間に、データを一時的に格納するのに使用される。レジスタ０は、特別な目的で使用される（次の実施例を参照）。フィルタを設計するプログラマーは、エントリの残りを任意に使用することができる。レジスタは、また、pvstructおよび残りのプログラム間のデータの交換に用いることもできる。例えば、大きいレコードの中に埋まった一つのアイテムが制御に必要な場合には、データアイテムを読む命令に続くxx2f命令を持つレジスタ内に、レコードをダンプできる。データアイテムは、次にファイルを読み書きする為の呼び出しの後に、レジスタの中で利用可能となる。
実施例５
COLUMUN TYPESと呼ばれるレコードに対するファイル仕様は次のとおりである。
RecType ＝0x413
RecBodySize ＝可変
レコードデータは次の通りである。

オフセットは１バイト値である。オフセットの数は、レコードサイズによって決まる。
このレコードに対する命令セットは次の通りとなる。

レコードの最後のコンポーネントは、１バイトコラムオフセットのリストである。これらは、互いに類似しており、すべてが単一の配列内に入れられる。この場合に、この様なエントリの数は、内部的には決定することはできず、以前に分解されたレコードサイズを使用しなければならない。0x15f命令は、レコード中に残る１バイトワードの数を決定することを分解器に命令し、この数は、常にレジスタ０に格納される。0x020は、複数の１バイトアイテムを単一配列に加えなければならず、このようなアイテムの数はレジスタ０で見つけられることを、分解器に教示する。
実施例６
文字列を含むRANGE DEFINITIONと呼ばれるレコードの実施例である。
RecType ＝0x215
RecBodySize ＝24
レコードデータ：

このレコードに対する命令セットは下記の通りである。

但し、0x1018：
xxx8：文字列がSYS＿STR1配列に格納されることを示す
xx1x：長さはARGにより与えられる
10xx：ARG＝16（0×10）
フィルタを書く人物による主観的な決定がここでは、行われる。文字列として扱われたコンポーネントは、また、上述のように、複数のエントリとして扱うことができる。その命令は次の通りである。
0x1010
但し
xxx0＝UCHARタイプ
xx1x＝アーギュメントで与えられた固定数
10xx＝ARG＝16（0x10 １６進法）
文字列アレーを使用する解決は、エントリの性質に基づいていた。レコードはテキスト文字列を含む。配列エンコードシステムは、文字列を取扱うのに、多数の特別な性質を提供する。例えば、システムは完全な文字列合致をチェックし、極めて効果的にエンコードされうる（一つのエントリのすべての１６charは他方の１６charと合致する）。したがって、テキスト文字列は、文字列として格納される時には、必ずより効果的に圧縮される。これとは逆に、前段落では、文字列サイズを使用しない数値コンプレッサ内で、オフセットがよりよく扱われる。
実施例７
文字列を含むEXTERNAL REFERENCESと呼ばれる別のレコードに対するファイル仕様は次のようなものである。
RecType ＝0x17A
RecBodySize ＝var（可変）
レコードデータ：

このレコードに対する命令セットは次の通りである。

レコードの最後のコンポーネントは、ゼロで終る文字列である。文字列の長さは、終りの文字を探すことによって見出すことができる。文字列配列は、文字列サイズを格納しエンコードするので、終端の文字はセーブしておく必要はない。INTERN＿SZはレコードサイズを示し、これは、予め判明していないが、内部的に決定されるので、レコードサイズは実施例５のColumn Typeレコードに対しては必要とされたように、エンコードされる必要はない。
実施例８
構造体、は別の構造体内に収める、つまり入れ子にすることができる。親構造体は、入れ子にされた構造体の複数のインスタンスを含むことができる。このようなCOLUMN STATUSレコードの記述は、次のようなものである。
Rec Type ＝0x7
RecBodySize ＝var（可変）
レコードデータ：

コラムデータエントリは、その状態がデフォルトに等しくない各コラムに対するオフセット、およびそのコラムの状態を示す。各エントリは２バイトである。
オフセット １バイト
ステータス １バイト
このレコードに対する命令は次の通りである：

レコードの最後のコンポーネントは、多数のオフセット／状態の対である。別個の配列を、オフセットコンポーネントおよび幅コンポーネントに対して作り出す必要がある。分解器は、対のシーケンスを調べ、アイテムをそれらの適切な配列に入れる。この一般的な手順は、サブ構造体により取扱われる。この場合には、サブ構造体は２つのuchar（±符号なしキャラクタ）コンポーネントを持つ。２つの命令が、サブ構造体を組み立てるのに呼び出された。
0x25f：この場合に数を設定するのに用いられる
xxxf：fは特別な命令を示す
xx5x：レコードの中に残ったARG長ユニットの数を決定し、これをレジスタ０に格納する
02xx：ユニットサイズは２（サブ構造体当たり２バイト）
0x02d：サブ構造体をスタートする実際の指令
xxxd：サブ構造体をスタートする
xx2x：レコード中のサブ構造体のインスタンス数は、register［ARG］内で、見つけられる
00xx：ARG＝０（従って、数はレジスタ０にある）
後に続くすべてのコンポーネントは、End＿SubStructure命令（0x000f）が現れるまで、サブ構造体のエレメントとして扱われる。命令リストが終るまでに、何も現れなければ、すべての残りのコンポーネントはサブ構造体の一部である。End＿SubStructure指令が見つけられると、その後の命令は、メイン構造体の一部として含まれるコンポーネントを参照する。
分解システムも、また、サブ−サブ構造体（サブ構造体中のサブ構造体）をサポートするが、好ましくは、より高レベルの入れ子構造は許されない。なぜならば、これ程複雑になったファイルスペックは、未だ識別されたことがないからである。多くのサブ構造体、又はサブ−サブ構造体は、好ましくは、入れ子が一度に２レベル以上深まることのない限り、pvstructの中で必要に応じて限定することができる。即ち、End＿SubStructure命令を介して親ネスティングレベルに戻る。
実施例９
場合によっては、アレーに書きこむデータのレンジは、ワードサイズによって許容される全数値レンジよりも小さいとして、ファイルフォーマットにより決められる。例えば、ファイル仕様は、０又は１の１バイトエントリを特定する。この情報は、分解システムによる正常チェック、およびエンコードシステムによる圧縮度の向上に使用できる。説明的なCOLUMN OPENレコードの記述は次の通りである。
Rec Type ＝0x11
RecBodySize ＝１
レコードデータ：

このレコードに対する命令セットは下記の通りである。

UCHARエントリの代わりに、D8＿1がエントリとなり、８ビットワードサイズおよび１ビットの値の範囲を示す決められた符号が実際に用いられる。これらのレンジの制約は、ファイルの分解に影響を及ぼすことはない。レンジ制約エントリは、そのワードサイズにしたがって分解される。レンジ制約は、PREDICTOR構造体が自動生成を助ける為に用いられ、この構造体はコンポーネントの静的モデルを含み、アレーのエンコードを制御する。現在、決められた符号ワードは、次のフォーマットを用いる。
min＿val＝0；max＿val＝（1＜＜nbits）−1である、決められたレンジ。
DX＿Y： X＝ワードサイズ（8＝uchar；16＝int16；32＝int32）
Y＝nbits（nビッド）
min＿val＝１；max＿val＝（1＜＜nbits）であって、１で始まる決められたレンジ。
DX＿Ys1： X＝ワードサイズ（8＝uchar；16＝int16；32＝int32）
Y＝nbits（nビッド）
特別に決められたレンジ
DX＿rY： X＝ワードサイズ（8＝uchar；16＝int16；32＝int32）
Y＝PREDICTOR＿CONTROLにおけるRANGEエントリのインデックス-＞spec＿range[]
特別に決められた値のリスト：
DX＿vY： X＝ワードサイズ（8＝uchar；16＝int16；32＝int32）
Y＝PREDICTOR＿CONTROLにおける値リストエントリのインデックス-＞spec＿dlist[]
分解システム２４（図２）は、好ましくは、Ｃプログラミング言語で書かれた関数ライブラリとして実現される。ライブラリのこの記述は、FILE I/Oルーチン、ARRAYルーチン、およびPVSTRUCTルーチンの３つのセクションに分割される。
分解システム２４は、フレキシブルな入力／出力インターフェースを有するので、同一セットの分解ルーチンを、入力／出力フォーマットには関係なく使用できる。ＤＯＳ、およびＯＬＥ２の２つのファイルフォーマットがサポートされる。しかし、通信ポートおよび他のＩ／Ｏオプションのほかに、他のファイルフォーマットにまで拡大できる。ＤＯＳフォーマットは、論理ストリーム位置が、通常、未処理のファイル位置と同一であるため、平易である。ＯＬＥ２フォーマッは、内部割当てテーブルを用いるＯＬＥ２ストリームを再構築する為に、広範な符号の層を要求する。
カスタマイズされた配列変形器
分解システム２４は、ソースファイル中の各コンポーネントに対してアレー２５を作り出し、自動化された解析システムにより生成されたエンコード用パラメータ１８によって援助された配列符号器２８は、利用可能なアルゴリズムを用いて各アレー２５をエンコードする最良の方法を見つける。場合によっては、これらの自動化されたデフォルトメカニズムは、カスタムルーチンを用いることによって改善できる。カスタムルーチンは、変形器と呼ばれる。なぜならば、カスタムルーチンは分解されたアレー２５で始まり、結果は、配列符号器２８に送られるアレー２５の異なるセットだからである。
カスタマイズされた配列変形器２６の主な役割は、コンポーネント間のモデルの実施である。一つのコンポーネントからのデータが、別のコンポーネントの符号化を援助できる。自動化されたデフォルトメカニズムは、各コンポーネントを個別に処理し、圧縮性能はコンポーネント間の関係を解明することにより、時には、改善できる。このようなシステムは、アレー２５中のすべての値を正確に予測でき、これより、アレー２５に符号は必要ない。カスタマイズされた配列変形器２６は、シミュレータになり、ソースデータファイルを生成するプログラムの機能性を複写する。各カスタムルーチンは、単一フィルタ１０に関連する特定の問題を解決する別個の創造物である。これらのルーチンの多くは、特定の問題に対する解決手段として独立して適用される。
カスタムルーチンは、実行可能なサイズを構築して拡大するために、多くの労力を要求するので、カスタムルーチンの使用は、好ましくは、総合的な性能が大幅に急増すると考えられる場合に制限する。多くのファイルフォーマットにおいて、少数のコンポーネントがデータの大部分を編成する。カスタマイズされた配列変形器２６は、通常、これらの頻度の高いコンポーネントの圧縮度を改善でき、自動化されたデフォルトメカニズムは、残りのコンポーネントの十分な圧縮を達成する。
システムの他の部分は、カスタマイズされた配列変形器２６が書かれるコンポーネントに関しても、十分な役割を果たす。分解システム２４は、コンポーネントの隔離と、カスタム作業を必要とするコンポーネントの識別および解析を簡易化する。配列符号器２８および自動化された解析ルーチンは、カスタマイズされた配列変形器２６によって生成されたアレーをさらに処理する。配列符号器２８の能力によって、カスタムモデリングに対する革新的なアプローチが可能である。このようなアプローチの一つは、サブディビジョンによる圧縮であり、アレー２５を複数のアレー２５に変形し、その各々を、配列符号器２８によって解明された方法で内部的に相関させる。
この一例として、上記実施例１における符号化された数字を考える。これらの値は、３２ビットの整数の単一アレー２５に分解される。しかし、これらの値は整数ではなく、むしろ、エントリは４つの異なるタイプの一つであることを２つのビットが示し、残りビットが各タイプに対して異なる意味を持つ、符号である。新しいアレー２５が、２ビットフラグに対して作り出され、次に、分離した配列が各４つのタイプに対して作り出される。自動化された分解システムおよび配列符号器２８は、これらの各５つのアレーに対して異なった最適モデルを見つけることができ、エントリの少ないアレーの取扱いにおけるシステムの効率は、複数のアレーの使用から、オーバーヘッドを除去する。この結果として、これら５つの高度に相関化されたアレーを符号化して得られる全符号サイズは、単一オリジナルアレーの符号化によって得られるサイズよりも十分に小さい。
カスタマイズされた配列変形器が、複数のフィルタ１０によって使用される場合、リソースにすることができる。リソースは、複数のフィルタによって使用される個別のモジュール（Ｗｉｎｄｏｗｓ環境におけるＤＬＬ）である。リソースを用いることの主たる理由は、冗長符号を減らすことにある。
配列符号器
大抵の圧縮アルゴリズムは、データブロックを変形し、その結果を少ないビットで頻度の最も高い値をあらわす方法を用いてエンコードするプロセスを含む。前記の変形は、数回継続することが可能であり、変形ごとに複数の出力ブロックを作り出すことができる。例えば代表的なＬＺ７７符号器において、ソースデータは、４つの異なる配列（array）に変形される。すなわち、合致シーケンスが見出されたか否かを示す１ビットフラグのブロック、以前のシーケンスと合致しなかったバイトの配列、および一つのシーケンスが見出された時の合致シーケンスの長さと位置、である。最初の３つの配列は、しばしば単一の配列に結合されてからハフマン符号化されるのに対し、合致位置は、レンジ変形されてからハフマン符号化される。
このタイプの圧縮システムは、ソースアレー（Array）が変形されて一つ以上のアレーになり、これらがまた他の変形を行うようなプロセスネットワークとみなすことができる。各パスの終わりには、確率的なモデルをエンコードされた出力に変形するハフマン符号器、または算術符号器のような低レベル符号器がある。データ圧縮のための従来のアプローチは、僅かな数の変形を持ち、それらへの固定化されたパスを定義する“圧縮アルゴリズム”に基づいている。これらの固定されたシステムは、僅かな数のコンポーネントを作り出す従来の分解システムに必要とされるエンコードを扱う。
本発明による好ましい分解システム２４は、異なるフィルタ１０の異なるコンポーネントをあらわす多数のアレー２５を作り出す。データタイプ（文字列、浮動小数点（フローティングポイント）値および各種のワードサイズの整数）は、コンポーネントごとに異なっていることが考えられる。これらのコンポーネントアレーのそれぞれの中のデータは、多様な方法で内部的に相関化できる。最適の圧縮を実現するためには、これらのパターンを利用する圧縮アルゴリズムを用いることが必要となる。また、最適アルゴリズムは、その時利用可能なメモリおよび速度と圧縮能力との兼合いの必要性に影響を受ける。各アレーにおけるエントリの数もまた大幅に変化し、異なる符号化アプローチが、異なるアレーカウントにおいて、より効率的に作動できる。
好ましい符号器システムは、各コンポーネントの静的モデルを利用することができる。このモデルは、フィルタが使用されているタイプの多数のソースファイルにおけるこのコンポーネントのインスタンスを解析することにより、得ることができる。このシステムは、“静的”でもなく“適合的”でもなく、むしろ役に立ちさえずれば静的モデルからの情報を使用する一方、各アレーに見出される個々のデータに完全に応答できる。静的モデルは、変形アルゴリズムの選択を導くこと、および各種のアルゴリズムに対する予め算出されたエンコードテーブルを提供することができる。
従って、好ましい符号器システムは、各アレーをエンコードするための何千種の方法をサポートせねばならない。プロセスシステムは、固定されたアルゴリズムではなく、むしろ動的ネットワークであり、このネットワークを通る各パスは、各種のエンコードアルゴリズムを作り出す。ネットワークを通るデータのパスは、静的モデルならびにアレーへのエントリ数、速度およびメモリ上の制約のような動的な考慮により導かれる。
好ましい符号器システムの持つ一面は、ネットワークを制御するためのアレーカウント（アレーへのエントリ数）の広汎な使用にある。低いカウントでは、システムは、サンプルデータベースの解析から作り出される静的モデルに全面的に依存する。カウントが増大するにつれて、システムは、特定のアレーの特性に対する適合度の高いアプローチを使用する。なぜならば、適合モデルの使用から得られる利点が、適合モデルのエンコードのオーバーヘッドよりも重要になり始めるからである。カウントの低い時のオーバーヘッドは、ほとんど完全に除去されるから、エントリが一つしかないアレーでも、効果的にエンコードできる。オーバーヘッドが無くなることにより、サブディビジョンによる圧縮と呼ばれる新しいタイプのアプローチを使用することが可能となり、この場合には、ソースアレーは、多数の高度に相関化された小さいアレーに変形される。
また、好ましい符号器システムは、出現したコンポーネントの多くに対して圧縮能力を高める多数のオリジナルアルゴリズムを含む。浮動小数点および文字列アレー変形のようなルーチンは、これらのコンポーネントをエンコードするための以前の方法を十分に上回る利点を提供する。
図３は、配列符号器のフローチャートである。他のルーチンとの間のインタフェースを簡単にするために、配列符号器の好ましい導入は、すべてのアレータイプ（各種のワードサイズ、文字列等の整数および浮動小数点）を扱う単一エンコードルーチンを含む。次に、マスタールーチンが、各アレーを図示されたデータタイプに対する特殊なエンコードルーチンに導く。
特にステップ３２において、アレー２５タイプは、文字列配列としてチェックされる。アレーが文字列配列の場合には、文字列符号器４０が呼び出される。配列が文字列配列でない時には、アレー２５タイプは浮動小数点（フロート）タイプとしてステップ３４においてチェックされる。アレーが浮動小数点タイプであれば浮動小数点符号器５０が呼び出される。アレーが文字列タイプでも浮動小数点タイプでもなければ、整数タイプであり整数符号器７０が呼び出される。
図４は、図３の文字列符号器４０のブロック図である。ここでは、用語“文字列（String）”は、文字のマルチバイトシーケンスを記載するために用いられる。文字列アレーは、一つ以上の文字列を含むことが可能であり、そのそれぞれは異なる文字列サイズ（そのシーケンスでのバイトの数）を持つことができる。文字列符号器は、まず、文字列合致判断器４１を用いて、受取った文字列データにおける文字列合致をチェックできる（文字列全体がアレーの中の他のすべての文字列に合致する場合）。文字列合致判断器４１は、配列符号器２８からの文字列データ、または静的モデル４３により供給され予測された文字列のリストについて作動できる。その後にアレーは、いくつかのメカニズムによりエンコードされ得る。合致していない文字列のような小さいアレーは、テキスト符号器４７により処理され、この符号器４７は、ＬＺ変形の一種を用い、文字列位置を利用し、静的モデルを用いて辞書を準備（Prime（プライム））し、または符号化テーブルを提示できる。合致符号の大きなアレーは、ブロック分類アルゴリズムおよび他の公知の技術のような配列符号器２８により提供される標準テキスト圧縮ルーチンにより扱われ得る。テキスト符号器４７が静的モデル４３により使用される時には、符号器は静的モデル４３により準備される。
図５は、図３の浮動小数点符号器５０のブロック図である。浮動小数点アレーは、３２、６４、または８０ビットのフォーマットのいずれをもとることができる。浮動小数点符号器は、配列符号器２８から浮動小数点データを受取り、フルワード（２倍精度浮動小数点値のすべての８バイトのような）のみの合致を調べて合致していない値を持つアレーを戻すＬＺ符号器５１を用いて、まず、以前の値との合致の有無をチェックする。次に、合致していない値は、ベース１０変換器５３の中でベース１０記号に変形される、なぜならば、多くのデータベースは、ベース１０値として当初エントリされた浮動小数点値を含み、またアレー符号器２８を通った値をそれらのネイティブフォーマットでエンコードすることが、より有効であるからである。ベース１０仮数、指数および変換エラーは、配列符号器２８により個別に処理される。ロスのない符号化のために、オフセットは変形時の僅かな丸め誤差を修正するように格納されねばならないことがある。ベース１０に効果的に変換されなかった値は、次に、文字列符号器４０（図４）を用いてエンコードされる。
自動化された解析システム
分解システムは、ソースファイルを多数のコンポーネントに分解する。多数のサンプルファイルの中の同じコンポーネントを調べることにより、静的モデルは、アレー符号器の中のコンポーネントのアレーの圧縮を高めることのできるコンポーネントで構成できる。自動化された解析システムは、最良のこのようなモデルを見出す。
図６は、好ましい自動化された解析システムのフローチャートである。ステップ６２においては、動作は、まず、全ソースファイルの中の特定のコンポーネントのすべてのインスタンスを持つファイルに、ソースデータファイルのすべてを分解することにより簡単化される。次に、これらの分解されたファイルは、ステップ６４において解析される。この解析は、高速である必要はない、なぜならば、その作業はオフラインで行なわれるからである。次に、フィルタに対するすべてのコンポーネントに対する結果は、多数コンポーネントモデルの中で冗長データを消去する単一の“Ｐｒｅｄｉｃｔｏｒ Ｄａｔａ”ファイルにステップ６６で統合される。
整数データ用の符号器
整数データに対する符号器は、３レベルシステムに基づくのが望ましい。高レベル操作は、合致値のシーケンスに対する距離をエンコードするＬＺアルゴリズム、又はある値を以前の値からのオフセットに変換する差変形のようなデータブロックの中のデータアイテムと特定の以前のデータアイテムとの間の関係を解明するモデルに基づく。中レベル操作は、ソースデータブロックにおけるデータ値の位置とは無関係なモデルをベースとする。操作により、特定値がブロック全体の中で生じる頻度のようなデータ、又はデータ値が各種の数値範囲の中にある頻度のようなデータの特性を解明する。データ値を１ブロックの符号に変形する操作が行われる。低レベル符号器は、これらの符号を確率的なモデルに基づいて圧縮する。２つの公知の低レベル符号器は、ハフマン符号および算術符号を用いたものであり、そのいずれもが本発明のシステムに使用することができる。下記の考察は、中および高レベルシステムに限定することとする。
高レベル符号器は、単一の解法ではなく、むしろその各々が特定のタイプのデータセットに関して有効な方法とモデルの集合体である。問題のこの部分については、単一の解法は存在しない。何故ならば多くの他の方法は同じ汎用の目的に用いられ、あるいはこの中で考察されているものとは別の性格を持つデータセットに対する解法を提供するためである。記載される方法のあるものは、標準的な技術であり、又他のものは標準技術の独自の改変である。これらの方法を記載することの外に一般的なフレームワークがこれらの高レベルモデルを統合するために、又それらの変形から得られるデータが中レベル符号器により如何に効果的に処理されるかを示すために記載される。
中レベル符号器は、アルファベットのサイズを低レベル符号器により有効に処理することのできるものに減らさねばならない。通常の数値ワードサイズは、しばしばハフマン符号、又は算術符号を用いた従来の手段により処理することのできる以上のシンボルを必要とする。例えばこれらの符号器の処理容量をはるかに上回る３２ビット整数のアルファベットをあらわすのに４，０００，０００，０００以上のシンボルが必要である。中レベル符号器は、数値データブロックにおいて公知の２つの特性を利用する。
第１に特定データ値は、しばしばデータブロックの中で高い頻度で現れる。各データブロックは、これらのマジック値の独自のセットを持つことが可能であり、これらの値は、数値範囲の中の何れかのポイントに生じることがある。
第２にデータ値は、数値範囲に関して不均一に分布することがある。例えばあるデータブロックにおいては小さい値は大きな値よりも更に頻度の高い傾向がある。
図７は、整数符号器の高レベルの動作を示すフローチャートである。整数符号器７０は、ステップ７１においていずれの変換が用いられるか、又これらの変形を実施するのに必要な他のパラメータを決める高レベルモデルを構築することにより始まる。このデータは、ステップ７３においてエンコードモジュールデータ構造の中に格納され、図示されたようにプロセス中、各種のステップで使用される。
最初のオプションは、ステップ７５における初期の分割器であり、これは値が低いバイトが高いバイトとは無関係に高度に相関化される時に用いられる。これに対する通常例は、ランダムデータセットの場合に予測される１０％よりはるかに高い頻度でベース１０値の低い桁の中にゼロが出現することである。高レベルモデラ（符号器）がこのような状態を検出した時には、ステップ７７においてソースアレーをソース値の上と下の桁をあらわす別個のアレーに分離させる。分割器によって戻された複数のアレーは、別個に処理される。
アレーデータは、次にステップ７９において合致アルゴリズムがデータに用いられるべきか否かを決めるためにテストされる。ステップ８１における合致アルゴリズムは、冗長データアイテム（即ち、配列の中の以前の入力に完全に合致するもの）を取り去る。合致アルゴリズムは、ステップ８３においてデータを合致したデータをもつアレーを格納する。合致しない値は、ステップ８５においてサイズオーバアレー処理器により処理される。
システムは、整数アレーのサイズを効率の改善とデザイン上の問題のいくつかの簡単化に役立つ固定された最大値に限定するのが望ましい。アレーカウントがこの最大値を越えると、オーバーサイズアレー処理器（ステップ８５）は、配列を一連の小さいアレーに分割する。次にこれらのアレーは、ステップ８７において、残りのルーチンが通常データタイプに関して操作することができるように、int32に変換される。これらの変形は、合致アルゴリズム（ステップ８１）の後に行なわれる、何故ならば合致アルゴリズムは、大きなブロックに関して、より効率的に機能するからである。
次にint32データがステップ８９において数値変形が次に行なわれるか否かを決定するためにチェックされる。ステップ９１において数値アルゴリズムは、以前の値を用いてアレーを予測された値からのオフセットに変形する。これらのモデルからのオフセットは、次にステップ９３において分割器決定ブロックに渡される。
上述のように分割器機能が必要な時には、分割器操作がステップ９５において実施される。分割器機能は、別個に処理される複数のアレーを戻す。
ステップ９７において、繰り返し変形（ステップ９９）を用いるべきか否かの決定が行なわれる。ステップ９９の繰り返し変形は、合致変形の１タイプであるが、すべての他の変形の後に行なうことができる。何れの場合にもプロセス動作は中レベル符号器１００に渡される。
分割器がフローチャート中の２箇所（ステップ７７および９５）で示されていることに留意する必要がある。これは、分割化が、下記の変形の一つが用いられる時に、数値変形の前に、又は合致変形の後に定常的に行なわれるためである。合致、数値変形および繰り返し変形は、データアイテムとエンコードブロックの中の前のデータとの間の関係を解明する。
“高レベル”の用語は、この符号器の構造に関係することに注意すべきであるが、この符号器と総合的な圧縮システムとの間の関係には無関係であることにも注意すべきである。データブロックをこの符号器に送る前に総合的なシステムは圧縮を高めるために、例えば類似の成分の配列を生成するためにソースデータを分析し、各種の成分の間の相互関係を利用するような多くの事を行なうことができる。ここに記載の操作は、システムレベルで取り扱うべきものを除外する。この記載は、又総合システムがバイレベルデータ、テキスト、ビットマップイメージ、等のような特殊化された符号器の使用がより適切なデータタイプを選び出すことを前提としている。
高レベル符号器の目的は、データブロックの中の異なったデータアイテムの間の関係を解明することにある。現在では上記の関係は、次の２つのタイプ、数値変形および合致変形が対象となる。数値変形は、ブロックの前のデータ値に関して行なわれた算術符号操作の関数としてのデータ値Ｄ〔ｉ〕を予測する。この時、Ｄ〔ｉ〕は、変形方程式により予測された値からのオフセットとしてあらわされる。変形は、変形された値をエンコードするのに必要なビットの数がオリジナルの値をエンコードするのに必要な数よりも少ない時には有効である。合致アルゴリズムエンコードは、Ｄ〔ｉ〕とデータブロックの中の前の値との間を合致させる。アルゴリズムは、合致値の位置をエンコードするのに必要なビットの数が〔ｉ〕をエンコードするために必要な数よりも少ない時には有効である。両タイプの操作は、同じブロックにおいて行うことができる。例えばＤ〔ｉ〕をＤ〔ｉ−１〕からのオフセットとしてあらわす差変形の次には、これらのオフセットのマッチを見出す合致アルゴリズムが続くことができる。
データブロックに関して何れの操作を行なうべきかに関する決定はモデラ（符号器）により行なわれる。アルゴリズムに考えられる各組合せを用いてフルデータブロックをエンコードすることにより最大の圧縮を実施することができるが、これには最も現実的な用法が節約できるよりも多くの処理時間を必要とする。エンコードされるべきデータブロックのサブセットに関する代案をテストするとともに、変形されたデータブロックを完全にエンコードすることなしにそのエンコードコストを推定するモデルを作ることにより、スピードアップすることができることの決定がなされる。符号器は、圧縮性能に対して次のような兼合い（トレードオフ）方式のプロセスサイクルの能力を提供する。つまり、アプリケーション環境が圧力時間のより少ない状態に在る時には、圧縮性能を改善するための代案の決定に、より多くの時間を費やすことができる。各アルゴリズムの考察は、そのアルゴリズムが用いられる時にエンコードコストを推定するために用いられるモデルの記載を含む。
高レベル符号器に於ける第１のステップは、変形が使用されぬ時にはデータブロックをエンコードするコストを決めることである、何故ならばバイパス符号化テーブルは、他の代案の有効性を決定するために後で用いられるからである。バイパスモードは、サンプルデータブロックを生成し、それを中レベルシミュレータに送ることによりテストすることができる。後述の中レベルシミュレータは、中レベル符号器に送られるブロックのエンコードのコストを推定するための高速メカニズムを提供する。サンプルデータブロックのサイズは、時定数によって調整される。中レベルエンコードは、データ値の位置には無関係であるために、サンプルは一連のアルゴリズムを決定するために必要なサンプルブロックを選ぶ代わりにデータブロック中にランダムに分散することができる。他の高レベルモードを決定する時に、モデラはソースデータブロックの中の各アイテムをエンコードするためのコストを推定するために中レベル符号器により生成されたエンコードテーブルを使用することができる。
最も簡単な関係は、ある値を前の値からのオフセットとしてエンコードすることである。これは、ほぼＤ〔ｉ〕＝Ｄ〔ｉ−１〕であることを予測し、Ｄ〔ｉ〕を前の値からのオフセットに変形する。

上記のシステムは、又ノイズの影響を受けにくい値に関してある値がＮ回の以前の入力に関する平均値に等しいことを予測する点で、変化に対応する。

式（１）は、式（２）においてＮ＝１である場合と見なすことができる。しかし式は、更に簡単な式（１）を処理する時に高い速度を利用するための別個のルーチンを用いて実行することができる。
あるデータタイプ（音響、画像、等）は、更に複雑な関係を利用することができるかも知れないが、他の式が汎用整数符号器に統合されることのないために、このようなデータタイプは特殊なルーチンを用いてエーンコードされることが望ましい。
モデラは２段階で操作される。第１段階は最良の数値モデルを選ぶが、これは我々のこの場合の設定では式（２）のＮの最適値の選択である。Ｎ＝１、２および４のような幾つかの値をチェックし、次に生じるオフセットが最小になるＮの値を選ぶことで充分である。符号化コストのもっとも正確な表現は、オフセットのベース２対数を比較することであるが、オフセットの絶対値（ａｂｓ）を判定することで充分である。

但し、ｃｔ＝データブロックへの入力の数
このルーチンは、エンコードコストを推定するために必要な、より詳細なルーチンが一つの代わりの数値で実行されるだけでよいように、最適の数値関係を迅速に見出すことができる。実際の符号化コストを推定するための現行のルーチンは、バイパス決定のために行なわれていたように中レベル符号器を用いたサンプルデータセットのエンコードに基づく。
３つの合致アルゴリズムの実施されていることが望ましい。つまり、整数を用いて使用するのに多くの改善の行なわれたＬＺアルゴリズムのバージョン、繰り返し変形、およびＭＴＦ（ムーブ−トゥ−フロント）アルゴリズムである。
基本的なＬＺアルゴリズムは、ワードサイズを定めないが、大抵の手段は、１バイトワードを用いることを基本としている。好ましいシステムは、現行では１、２および４バイト整数を含むフレキシブルワードサイズを可能にする。ルーチンは、３つの出力アレーを生成する。
（合致しない値について）
これらは合致シーケンスの一部ではないデータブロックの中の整数である。データタイプは変化しない。つまり、ソースアレーがint32であった時には合致しない値も又int32であろう。このコンパクトにされたアレーは圧縮のために整数符号器の低いレベルに送られる。
（長さについて）
合致シーケンスにおいて、長さはそのシーケンスにおいて合致していたワードの数を示す。上記以外であれば長さは次の合致の前の合致しない値の数を与える。
（位置について）
位置は合致シーケンスのスタートに対するオフセット（ワードの数であって、バイトではない）を与える。
アルゴリズムの手段における別の工夫は、合致の判定のための動的システムである。従来のＬＺ手段は、合致しないデータアイテムをエンコードするための固定コストを前提とするが、バイパス判定の結果が利用可能であり、この判定は各々の異なった合致しないデータ値をエンコードするコストの優れた推定値を与える。例えば値１０１９が２５％の頻度で出現する時には、その合致しないアイテムとしてのエンコードコストは２ビットであり、この事は合致シーケンスとしてこのような２つの値の合致をエンコードすることは有効でないことを意味する、なぜならば合致をエンコードするコストは、合致しない入力としての値をエンコードするコストを上回るからである。動的判定のこのシステムが実施される度合いは、各リアルタイム状況下での速度／圧縮の兼合いに従って調節することができる。
繰り返し変形は、繰り返し符号を持つ繰り返された値に置き換えるものである。好ましいシステムは、標準手段に対する幾つかの改善点を提供する。第１に繰り返し符号は動的に調節される。即ち各データブロックのために用いられた繰り返し符号は、データブロックの次の２つの特性、つまり、データブロックのサイズとブロック中の繰り返し値の数に従って調節される。第２に特殊なＲＴＥ（ラン−トゥ−エンド）符号は、繰り返しシーケンスがブロックの終りに迄続くことを意味する。最後に大きな値をあらわすために特殊なコードも存在する。繰り返し符号のためのスペースを設けるために合致しない正の値は、上方に繰り返し符号の数だけシフトされる。我々の、数値レンジの増えることを避けるために正のレンジの終りの値は、特殊符号を用いてエンコードされる。
従来のＭＴＦ符号器は、小さいワードサイズを前提とするので、すべての考えられるシンボルを合致距離としてあらわすことができる．大きいワードサイズは、限定されたサイズのバッファを用い、合致しない値の出力配列を生成することにより考慮され、上記の出力配列は、エンコードのために整数符号器のすぐ次のレベルに送ることができる。あるデータ値がこのバッファの中の値に合致する時には、バッファの中の合致値インデックスを用いてあらわされる。別に、次のバッファ合致の前の合致しない値の数が記録される。バッファのサイズは、バイパステスト結果に従って調節される。時間が許す場合、あるアイテムを合致しない値としてエンコードするためのコストは、バッファ合致としてそれをエンコードするコストとの間で兼合いを求められるが、低いオーバーヘッドのためにこの事は、ＭＴＦアルゴリズムにとってはＬＺに対する場合に対する程には重要な問題ではない。
このＭＴＦアルゴリズムは、個別のアイテムが合致するが、多ワード合致シーケンスが少ない時には、整数ＬＺよりも能力が優れている。合致の冗長化された探索を避けるために両アルゴリズムは、単一の変形ルーチンに統合されて別個の出力配列を形成し、その後により性能の良かった方を選ぶことが望ましい。
小さいサンプルセットを用いて合致アルゴリズムを判定するよりは、変形は完全なデータブロックにおいて実行され、次にそれらを中レベルシミュレータに送るために結果を判定することができる。アプリケーション環境が時間的に極めて制約される場合に、この判定はブロックの一部のみが変形された後に行なわれる。
多くの現実のデータセットの中では、値の表現におけるベース１０の個々の桁は圧縮を高めるために解明することのできる特性を持つ。これらの特性は“分割化（splitting）”と呼ばれるテクニックを用いて解明される。整数の配列は、２つ以上の整数の個別の配列に分割され、ここでは各配列は、ソースアレーの中の桁のサブセットから生成される。分割された配列のエンコードのための全コストが、入力ソースアレーをエンコードするためのコストよりも小さい時に分割化は有効である。分割化を用いて有効に処理される配列の一つの例は次のようなものである。

分割の前のソースアレーは、２１ビットレンジ（１０７９５４８４−１３１９５３９９）の中でランダムに変化する様に見える。然し、分割の後には第１行は４ビット／入力においてエンコードすることが可能であり、第２行は消滅し、第３行は７ビットレンジ（３９９−５０１）に所属する。符号化のための全コストは、ソースアレーを符号化するコストの約半分である。更に各配列はしばしば幾つかの方法で分割することができる。
分割化は、それが数を判定する他の方法にとって見出せない桁分野の間で時として起きる相関性を見出すために有用である。この事は特にここでは重要である、何故ならばレンジ再マップのために記載すべき変形のあるものがランダム数のような低いビットを処理するからである。分割化を用いなければ多くのゼロの存在のような低い桁における相関性は失われることになる。
高レベルモデラは、分割化に関する幾つかの決定を行なわねばならない。第１にモデラは、使用すべき最良のモデルおよび分割化が他のエンコードのための代わりの方法よりも有効であるか否かを決定する。第２にモデラは、合致アルゴリズムが分割化の行なわれる前に実行すべきか否かを決定する。最後にモデラは、例えば数値変形、又は合致アルゴリズムの一つのような何れの高レベルアルゴリズムが分割化の後に分割アレーの各々に実行すべきかを決める。
分割化に従うべき関係は、通常ベース１０の表現においてしか可視的でないために、分割器の第１の動作は、データをベース１０の表現に変換することである。場合によっては、ソースデータは当初は英数字表現であることも考えられ、このような場合の変形時間は、整数符号器に対する可視的アーギュメントとしてデータブロックの文字列表現を用いることにより、節約される。
分割器アルゴリズムを判定するためにヒストグラムが各桁に対して作られ、その桁分野の中の１０の可能な値の出現の頻度を示す。これらのヒストグラムは、次に個別の配列に分割すべき桁分野を特定しグループ化するのに用いられる。配列は、次に繰り返し変形が有効であるか否かをチェックされ、次にエンコードのためのコストは中レベルシミュレータを用いて推定することができる。
図８は、整数符号器の中レベルの動作を示すフローチャートである。アレーデータは、ステップ１０において入力され、先ずステップ１０３においてレンジマップにより処理される。パックすべきエキストラビットは、ステップ１０５において格納される。得られたレンジ符号からステップ１０７においてＭＴＦ符号器を用いるべきか否かの決定が行なわれる。この決定が肯定的であればＭＴＦ符号器がステップ１０９において実行される。最終レンジ符号は、ステップ１１０における低レベル符号器に対して与えられる。
この中レベル符号器は、低レベル符号器により効果的に処理することのできるサイズにアルファベットのサイズを減らし、又圧縮を最大にする方法で実施せねばならない。この符号器は、レンジ再マップ（ステップ１０３）およびオプションの変形後のＭＴＦ（ムーブ−トゥ−フロント）変形（ステップ１０９）を含む。レンジ符号化は、位置成分をデータセットに再投入し、このレンジ符号の中で当初の値が合致していなかった場合にも近くのレンジ符号に合致する傾向を示すことがある。この現象が生じた場合、ＭＴＦ変形はこれらのシンボルをエンコードされたデータの流れに変換する低レベル符号器に送る前に実行される。中レベル符号器の出力は、低レベル符号器に送られる。中レベルシュミレータは、又エンコードコストを推定するための高レベルルーチンにより用いることもできる。
レンジ再マップは、整数をコードワードに変換する。各入力値は、単純なコードワードにより表現される。コードワードの数は、通常考えられるデータ値の数以下であるから、コードワードのあるものは考えられる一つのソース値以上のものを表現することができる。これらの場合においては、コードワードはある範囲の値を示し、レンジ再マップはオフセットをこの範囲内にビットパックする。これは標準的な圧縮技術である。
標準アプローチは、予め限定されたレンジテーブルを使用し、低レベル符号器がそのデータブロックにおいて最も通常のレンジに対するレンジ符号に対して少ししかビットを使用せぬことを可能にする傾向を持つ。好ましいシステムは、各データブロックに対して最適化されるレンジテーブルを作り出し、そのレンジ内のオフセットをパックするために用いられるビットの数を有意義に減少させる。例えば固定されたレンジテーブルは、そのレンジにおける各入力に対するオフセットをパックするために１６ビットを必要とする0x10000で始まり0x20000で終るレンジを限定することがある。然しこのレンジ内の入力のすべては、値0x18000を持つことができる。好ましいシステムは、これを見出し、エキストラビットを必要とせぬこの値に対するエキストラレンジを作り出す。
システムは、データブロックに高い頻度で出現する特定値を記載するために“マジック値”の用語を使用する。これらの値は、特殊な処理を施される。なぜならばデータレンジの中で出現する場所とは無関係にそれらはエキストラビットを用いることなしにパックすべきであるからである。残りの“非マジック”に対しては、データブロックの中の値の分布に適合する最適化レンジが生成される。
第１ステップは、ターゲットテーブルサイズを決定することである。テーブル入力の各々は、レンジ再マップおよび低レベル符号器の両者に固定されたオーバーヘッドを必要とする。データブロックが小さければ使用されるテーブルも小さくすべきである。しかし大きな数値レンジを持つデータブロックは、より優れたテーブルを用いて、より多くのビットを節約することができるために、テーブルのサイズは、又データレンジに対しても調節すべきである。各テーブル入力に対する入力の目標数は、ｍｉｎ頻度と呼ばれ下記の式により計算される。
ｍｉｎ頻度＝入力のターゲット数／ターゲットテーブルサイズ （４）
最終テーブルサイズは、目標からかなり異なったものであるが、これによりテーブルの構成に用いるための値が得られる。データブロックの中の各値の頻度を示す分類されたヒストグラムが次に生成される。このテーブルは、正の値のためのセクションと負の値のためのセクションの２つのセクションを持つ。追随型レンジテーブルを生成するための一般的な手順が正のテーブルに対して記載される。
頻度＞０を持つ最小値から始め、これを我々の最初のレンジの“ベース”と呼ぶ。その頻度がｍｉｎ頻度よりも小さい時には、レンジの中に含まれる値の全頻度＞ｍｉｎ頻度となるまで、別の値を加えてレンジを拡大する。この時点でレンジは次のサイズを持つ。
レンジサイズ＝ベースの最終値 （５）
レンジの中の考えられるすべての値を表現するために必要なビットの数、ｎビットを求める。レンジをサイズ１＜＜ｎビットまで拡大する。
次のレンジは下記から始まる：
ベース〔ｉ＋１〕＝ベース〔ｉ〕＋（１＜＜ｎビット〔ｉ〕） （６）
次の値＞＝ベース〔ｉ＋１〕に達するまでヒスト値を飛び越し、次に続くレンジを生成する。負のテーブルは同じ方法であるが、−１から始まり、大きな負の値に移行する。
実施例１０
この実施例は、一般的なアプローチを紹介するが、同時にマジック値を扱うことのできるように改変される。その頻度＞ｍｉｎ頻度である値はマジック値であり、エキストラビット（Ｅビット）を必要とせぬ別個のテーブル入力に到達すべきである。テーブルを作るプロセス中に一つが出現すると、マジック値を保持する特別リストに加えられる。データレンジは、レンジからマジック値を除去するためにコンパクト化される。
ｍｉｎ頻度＝１０の場合には、

この実施例においてｍｉｎ頻度が１０であり、新たなレンジが値１００においてスタートすべきであれば、‘１０２’の値はマジック値であり、そのベースが１００に在るレンジから削除される。このレンジに残る４つのすべての値（１００、１０１、１０３、１０４）は、次に２ビットオフセットを用いて表現することができる。
レンジテーブルは、各レンジに対するマジック値とＥビット（オフセットをエンコードするためのエキストラビットの数）を用いて再構成することができる。Ｅビットをエンコードするためにその値が前のＥビット入力からのオフセットをあらわす２ビットコードが各入力に対して生成される。
0：Ｅビット〔ｉ〕＝Ｅビット〔ｉ−１〕−１
1：Ｅビット〔ｉ〕＝Ｅビット〔ｉ−１〕
2：Ｅビット〔ｉ〕＝Ｅビット〔ｉ−１〕＋１
3：Ｅビット〔ｉ〕＝Ｅビット〔ｉ−１〕＋オフセット
但し、オフセットは、多数のＥビットを用いるサインされた値としてパックされる。
これらのコードの４つは、パックされて１バイト値にされ、次に低レベル符号器が１バイトコードワードをエンコードするために予め限定された静的テーブルと共に使用される。サンプリング間隔が限定され、各サンプルグループに対してエキストラビット値（オフセットに対して必要なビットの最大値）が調節される。いくつかのセットの低レベルエンコードテーブルも又生成され、コードテーブルはサンプルグループの中の動作の量（変更された全ビット）により選ばれる。
マジック値のリストをエンコードするために、リストは格納され、前の値からのオフセットに変換される。これらのオフセットは次に２ビットコードを用いてエンコードされる。
0： オフセット＝１
1： オフセット＝2-5、２つのＥビットをパックして何れかを選ぶ
2： オフセット＞＝6、オーバーサイズオフセットに対し特殊エンコード手順を使用すること
3： 前のオフセットをｒｐｔ ｃｔ（データブロックへの入力の数）回繰り返すこと。ｒｐｔ ｃｔを見出すために用いられる２ビット符号は次の通りである：
0：ｒｐｔ ｃｔ＝１
1：ｒｐｔ ｃｔ＝2、3、選択のためにＥビットをパックすること
2：ｒｐｔ ｃｔ＝4-6、選択のためにＥビットをパックすること、オフセット＝３を持つ符号２が特殊な最大ｒｐｔ値を示すために用いられる
3：ｒｐｔ ｃｔ＝7-22、選択のために４つのＥビットをパックすること
これらの２ビット符号の４つが１バイトワードにパックされ、次にこのワードが前のワードにおける最後の２ビット符号に従って予め限定された静的テーブルを用いてエンコードされる。オーバーサイズオフセットは、静的に限定されたベース＋オフセットレンジテーブルを用いてエンコードされる。レンジ符号は、前のレンジ符号に従って選ばれるテーブルを持つ低レベルエン符号器を用いてエンコードされる。オフセットはビットパックされる。
レンジコードは、しばしば位置的に相関化される。つまり、類似のコードは、互いに近くに集まることができる。このような場合には、標準ＭＴＦ変換の中で符号化を実行することにより、低レベル符号器における符号化を改善することができる。その時にそれを用いている変形は有効である。
高レベルモデラは、競合する高レベルアルゴリズムの中から選ぶために、しばしば１ブロックのエンコードコストの推定値を必要とする。シミュレータは、サンプル値のブロック並びにフルデータブロックのサイズを受け取る。シミュレータは、フルデータブロックのエンコードのためのコストの推定値を生成するためにサンプルを使用する。この推定値を生成する時に、以下のように、いくつかの改変が中レベル符号器の操作に施される。
（ａ）入力の数並びに入力テーブルに対して変更されたビットの全数に基づくモデルを用いたテーブルのエンコードのコストの推定。
（ｂ）下記の標準式の高速近似化を用いる各符号の頻度から、レンジ符号をエンコードするコストの推定。

但し：頻度〔ｉ〕 ＝符号〔ｉ〕の頻度
全頻度 ＝すべての符号の全頻度
log2 ＝ベース２の対数
コスト ＝ブロックをエンコードするために必要とされるビット数
（ｃ）レンジ内のオフセットをエンコードするために必要なエクストラビットを計算すること。
（ｄ）中レベルＭＴＦを削除すること。
なお、本発明は、その好ましい実施形態に関して特定的に図示記載されているが、この分野の当業者によっては形態および詳細に於ける各種の変更を随意に請求項により限定された発明の原理と範囲から逸脱せずに行なうことができるものと理解される。この分野の当業者は、日常的な実験以上の手段を用いることなくこの中に具体的に記載された発明の特定の実施形態に対する多くの同等の事項を認識し、又は確認することができるであろう。このような同等の事項を請求項の範囲内に包含することが意図される。

Claims (29)

1. 複数のコンポーネントを有するデータをコンピュータで符号化する方法であって、
   すべてのデータコンポーネントは、体系化されたファイルフォーマットに従って、データ型を伴うデータフィールドに構造化されており、
   体系化されたファイルフォーマットのソースデータ構造体から、ソースデータ構造体フォーマットに基づいて複数のブロックを生成する工程であって、各ブロックが特定のデータフィールドに関連している生成工程と、
   データコンポーネントのデータフィールドに基づいて、ソースデータ構造体から複数のブロックの１つに各データコンポーネントを分類する分類工程と、
   前記ブロックごとに、
   ブロックに関連付けられたデータフィールドのデータ型に基づいて、複数の候補圧縮アルゴリズムから圧縮アルゴリズムを選択する選択工程と、
   前記選択された圧縮アルゴリズムを前記ブロックの各データコンポーネントを圧縮するように適用する圧縮工程と、
   前記複数のブロックから圧縮されたデータコンポーネントをエンコードデータ構造体に結合させる結合工程とを備えた方法。
2. 請求項１において、
   前記ソースデータ構造体が、第１フォーマットに体系化され、
   前記分類工程が、前記ソースデータ構造体を第２フォーマットへ変換する変換工程を有する方法。
3. 請求項２において、
   前記変換工程が、前記ソースデータ構造体からの類似のデータをそれぞれのブロックに集める工程を有する方法。
4. 請求項２において、
   前記変換が、前記第１フォーマットに基づいて行われる方法。
5. 請求項１において、
   前記圧縮アルゴリズムが、さらに、それぞれのブロック中のデータ量に基づいて決定される方法。
6. 請求項１において、
   前記圧縮アルゴリズムが、それぞれのブロックに適合している方法。
7. 請求項１において、
   前記選択工程が、ブロックのデータコンポーネントの圧縮に先立って、カスタマイズされた変換器によってブロックを変形する工程を有する方法。
8. 請求項７において、さらに、ブロックのデータコンポーネント間の関係に基づいて、ブロックを変形させる工程を備えた方法。
9. 請求項１において、
   前記エンコードデータ構造体から前記ソースデータ構造体を復元する工程を備えた方法。
10. 請求項１において、前記体系化されたファイルフォーマットが定義データ型を含む方法。
11. 請求項１０において、各データ型は、ブロックが出現する構造体のタイプおよび構造体内のブロックの位置によって決定される方法。
12. コンピュータに、
    複数のコンポーネントを有するデータ符号化ネットワークを実行する一連の命令を記憶する機械可読記憶媒体であって、
    すべてのデータコンポーネントが、体系化されたファイルフォーマットに従って、データ型を伴うデータフィールドに構造化されており、
    体系化されたファイルフォーマットのソースデータ構造体から、ソースデータ構造体フォーマットに基づいて複数のブロックを生成する手順であって、各ブロックが特定のデータフィールドに関連している生成手順と、
    データコンポーネントのデータフィールドに基づいて、ソースデータ構造体から複数のブロックの１つに各データコンポーネントを分類する分類手順と、
    前記ブロックごとに
    ブロックに関連付けられたデータフィールドのデータ型に基づいて、複数の候補圧縮アルゴリズムから圧縮アルゴリズムを選択する選択手順と、
    前記選択された圧縮アルゴリズムを前記ブロックの各データコンポーネントを圧縮するように適用する圧縮手順と、
    前記複数のブロックから圧縮されたデータコンポーネントをエンコードデータ構造体に結合させる結合手順とを実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
13. 請求項１２において、
    前記ソースデータが、第１データフォーマットに体系化され、
    前記分類手順が、前記ソースデータを第２フォーマットへ変換する変換手順を有するコンピュータ読み取り可能な記録媒体。
14. 請求項１３において、
    前記変換手順が、前記ソースデータからの類似のデータをそれぞれのブロックに集める手順を有するコンピュータ読み取り可能な記録媒体。
15. 請求項１３において、
    前記変換が、前記第１フォーマットに基づいて行われる、コンピュータ読み取り可能な記録媒体。
16. 請求項１２において、
    前記圧縮アルゴリズムが、さらに、それぞれのブロック中のデータ量に基づいて決定されるコンピュータ読み取り可能な記録媒体。
17. 請求項１２において、
    前記圧縮アルゴリズムが、それぞれのブロックに適合しているコンピュータ読み取り可能な記録媒体。
18. 請求項１２において、
    前記選択手順が、ブロックのデータコンポーネントの圧縮に先立って、カスタマイズされた変換器によってブロックを変形する手順を有するコンピュータ読み取り可能な記録媒体。
19. 請求項１８において、さらに、ブロックのデータコンポーネント間の関係に基づいて、ブロックを変形させる手順を備えたコンピュータ読み取り可能な記録媒体。
20. 請求項１２において、
    さらに、前記エンコードデータ構造体から前記ソースデータ構造体を復元する手順を備えたコンピュータ読み取り可能な記録媒体。
21. 請求項１２において、前記体系化されたファイルフォーマットが定義データ型を含むコンピュータ読み取り可能な記録媒体。
22. 請求項２１において、各データ型は、ブロックが出現する構造体のタイプおよび構造体内のブロックの位置によって決定されるコンピュータ読み取り可能な記録媒体。
23. 複数のコンポーネントを有するデータを符号化する装置であって、
    すべてのデータコンポーネントは、体系化されたファイルフォーマットに従って、データ型を伴うデータフィールドに構造化されており、
    体系化されたファイルフォーマットのソースデータ構造体に基づいて導入された複数のブロックであって、各ブロックが特定のデータフィールドに関連しているブロックと、
    データコンポーネントのデータフィールドに基づいて、ソースデータ構造体から複数のブロックの１つに各データコンポーネントを分類する分類器と、
    ブロックに関連付けられたデータフィールドのデータ型に基づいて、前記ブロックごとに、複数の候補圧縮アルゴリズムから圧縮アルゴリズムを選択する選択システムと、
    前記ブロック中の各データコンポーネントを圧縮するために前記選択された圧縮アルゴリズムを適用し、前記複数のブロックから圧縮されたデータコンポーネントをエンコードデータ構造体に結合させる符号器とを備えた装置。
24. 請求項２３において、
    前記分類器が、前記ソースデータ構造体からの類似のデータをそれぞれのブロックに集める装置。
25. 請求項２３において、
    前記選択システムによって選択される圧縮アルゴリズムが、前記ブロック中のデータに適合している装置。
26. 請求項２３において、
    さらに、前記エンコードデータ構造体から前記ソースデータ構造体を復元する復元システムを備えた装置。
27. 請求項２３において、
    前記体系化されたファイルフォーマットが定義データ型を含む装置。
28. 請求項２７において、各データ型は、ブロックが出現する構造体のタイプおよび構造体内のブロックの位置によって決定される装置。
29. 請求項２３において、さらに、ブロックのデータコンポーネント間の関係に基づいて、ブロックを変形させる変換器を備えた装置。

Images