(57)【特許請求の範囲】
【請求項１】
ディジタルデータが所定の単位で入力される入力手段と、
入力されたディジタルデータを圧縮するデータ圧縮手段と、
固定長を有するグループ単位に対応して、上記データ圧縮手段で圧縮されたディジタルデータを一旦蓄えるバッファメモリと、
上記データ圧縮手段にデータが残っているかどうかを検出するレジスタと、
上記バッファメモリに蓄えられた上記圧縮ディジタルデータを記録媒体に記録する際に、上記レジスタにデータが残っているかどうかにより、上記圧縮された所定単位のディジタルデータが次のグループに続くかどうかを判断する判断手段と、
上記判断手段の判断結果を示す識別信号を上記バッファメモリに蓄えられた上記圧縮ディジタルデータに付加して、上記グループ単位毎に上記記録媒体に記録する記録手段と
を備えるディジタルデータ記録装置。
【請求項２】
上記記録媒体はテープ状記録媒体であり、上記グループは、上記テープ状記録媒体に形成されるトラックの複数本分からなる請求項１記載のディジタルデータ記録装置。
【請求項３】
所定の単位でディジタルデータをデータ圧縮手段で圧縮し、固定長を有するグループ単位に対応して、上記圧縮されたディジタルデータをバッファメモリに一旦蓄えると共に、上記データ圧縮手段にデータが残っているかどうかをレジスタで検出し、上記レジスタにデータが残っているかどうかにより、上記圧縮された所定単位のディジタルデータが次のグループに続くかどうかを判断し、上記判断結果を示す識別信号を上記バッファメモリに蓄えられた上記圧縮ディジタルデータに付加して上記グループ単位毎に記録された記録媒体から上記記録単位毎にデータを再生する再生手段と、
上記記録媒体から上記グループ単位毎に再生された上記圧縮ディジタルデータを一旦蓄えるバッファメモリと、
上記バッファメモリから読み出された上記圧縮ディジタルデータを伸長するデータ伸長手段と、
上記データ伸長手段から供給されたディジタルデータを、上記グループ単位とは別の所定単位で処理して出力する出力手段と、
上記記録媒体から上記識別信号を検出するための検出手段と、
上記検出手段の出力に応じて、次の上記記録媒体の記録単位のディジタルデータを再生するかどうかを制御する制御手段と
を備えてなるディジタルデータ再生装置。
【請求項４】
上記記録媒体はテープ状記録媒体であり、上記記録媒体の記録単位に対応するデータ量は、上記テープ状記録媒体に形成されるトラックの複数本分からなる固定長を有するグループである請求項３記載のディジタルデータ再生装置。
【発明の詳細な説明】
技術分野
この発明は、テープ状記録媒体にディジタルデータを記録／再生するデータ記録／再生装置に関するもので、特に、データを圧縮して、回転ヘッドによりヘリカルスキャン方式で磁気テープに記録／再生するようにしたものに係わる。
背景技術
磁気テープにディジタルデータを記録／再生するテープストリーマドライブは、記録容量が膨大であるため、ハードディスク等に記録されたデータをバックアップするのに広く用いられている。また、テープストリーマドライブは、バックアップ用としてばかりでなく、動画データのように大きなファイルのデータを記録／再生する場合に用いて好適である。
このようなテープストリーマドライブとしては、例えば、８ミリＶＴＲのテープカセットと同様のテープカセットを利用したものが知られている。このようなテープストリーマドライブでは、回転ヘッドを用いて、ヘリカルスキャン方式でディジタルデータを磁気テープに記録／再生している。
また、このようなテープストリーマドライブにおいては、データ記録容量の増大を図るために、ＬＺ（Lempel-ZIV）符号を用いてデータを圧縮して記録するようにしたものが知られている。ＬＺ符号は、文字列の繰り返しを検出することで、データの圧縮を行なうものである。このようにデータ圧縮して記録すると、データの記録容量が増大するばかりでなく、特に、シーケンシャルなデータを記録／再生する場合には、読み出し／書き込みをするデータ量が少なくなるので、アクセス速度が見かけ上速くなる。
このようなデータ圧縮機能を実現するために、テープストリーマドライブには、例えばＬＺ符号のデータ圧縮／伸長を行なうデータ圧縮／伸長部が設けられる。通常、データ圧縮／伸長部は、オリジナルデータ側インターフェースと、圧縮／伸長エンジンと、圧縮データ側インターフェースとを有している。オリジナルデータ側のインターフェース及び圧縮データ側のインターフェースには、ＤＭＡ（Direct Memory Access）の転送速度を調整するためのＦＩＦＯ（First-In-First-Out）レジスタが設けられる。
このようなテープストリーマドライブにおいては、記録時に、ホストコンピュータからオリジナルデータ側のインターフェースにデータが転送される。このデータは、所定の大きさ例えば５１２バイトを１レコードとして転送される。このデータは、データ圧縮／伸長エンジンに供給され、データ圧縮／伸長エンジンで、このデータが連続的に圧縮されていく。この圧縮されたデータは、数トラックからなるグループを単位として磁気テープに記録されていく。
すなわち、第１図Ａに示すように、オリジナルデータ側のインターフェースには、レコード単位でデータＳＤ1、ＳＤ2、ＳＤ3、・・・が入力される。このデータＳＤ1、ＳＤ2、ＳＤ3、・・・がデータ圧縮／伸長エンジンに送られる。データ圧縮／伸長エンジンにより、第１図Ｂに示すように、各レコード毎のデータＳＤ1、ＳＤ2、ＳＤ3、・・・は、圧縮データｓｄ1、ｓｄ2、ｓｄ3、・・・に圧縮される。データ圧縮／伸長部の後段にはバッファメモリが設けられており、圧縮後のデータｓｄ1、ｓｄ2、ｓｄ3、・・・は、バッファメモリに一旦蓄えられる。圧縮後のデータｓｄ1、ｓｄ2、ｓｄ3、・・・が１グループに相当する量に達すると、第１図Ｃに示すように、このデータが所定数のトラックからなるグループに記録される。
再生時には、所定数のトラックからなる１グループ毎に、磁気テープのデータが再生される。この１グループの再生データは、一旦、バッファメモリに蓄えられる。バッファメモリに１グループ分のデータが蓄えられると、このデータがデータ圧縮／伸長部に送られる。データ圧縮／伸長部で、この再生データが元の大きさのデータに伸長され、例えば５１２バイトを１レコードとして、ホストコンピュータに送られてくる。
ところで、このようにデータを圧縮して磁気テープに記録するようにしたテープストリーマドライブでは、前述したように、記録時にホストコンピュータからレコード単位で入力されたデータは、圧縮された後に、バッファメモリに蓄えられる。圧縮後のデータは可変長であり、データの種類によって、圧縮率が変化する。このため、圧縮後のデータのデータ量を予測することは困難であり、このため、バッファメモリが溢れ出すようなことがあり得る。
すなわち、通常、記録時には、ホストコンピュータからは、レコード長とレコード数を指定して、データが送られてくる。圧縮したときのデータ量は予測できなきいので、指定されたレコード長のデータを指定されたレコード数だけ圧縮してバッファメモリに取り込んだときに、バッファメモリが溢れ出すようなことがあり得る。このようにバッファメモリが溢れ出すような場合には、ホストコンピュータからのデータの転送を一時的に中断するような制御が必要である。
また、このようにデータを圧縮して磁気テープに記録するようにしたテープストリーマドライブでは、再生時には、磁気テープのデータは１グループ毎に再生され、バッファメモリに蓄えられる。このとき、例えば複数レコードからなる所定単位のデータが次のグループに続いている場合には、次のグループのデータを読み込む必要がある。
すなわち、第２図に示すように、所定単位のデータｓｄ11、ｓｄ12、ｓｄ12、・・・を記録した場合、第２図Ａに示すように、グループＧＰ１の最後に入るべきデータｓｄmが次のグループＧＰ２に続く場合と、第２図Ｂに示すように、グループＧＰ１の最後に入るべきデータｓｄmがグループＧＰ１内に収まる場合がある。第２図Ｂに示すように、グループＧＰ１の最後に入るべきデータｓｄmがグループＧＰ１内に収まる場合には、グループＧＰ１のデータを完結しているので、グループＧＰ１のアクセスのみでグループＧＰ１のデータの再生が完了する。ところが、第２図Ａに示すように、グループＧＰ１の最後に入るべきデータｓｄmがグループＧＰ２に続く場合には、データｓｄmを再生させるために、次のグループＧＰ２をアクセスする必要がある。
このように、データを圧縮して磁気テープに記録するデータ記録／再生装置においては、記録時に、バッファが溢れることがないように、ホストコンピュータからのデータの転送を制御する必要がある。また、再生時には、所定単位のデータが１つのグループ内に完結しているか、次のグループに続いているかを判断して、データのアクセスを制御する必要がある。
発明の開示
したがって、この発明の目的は、ホストコンピュータから送られてきたデータを圧縮して記録する際に、バッファメモリのデータを溢れさせることなく、データを効率的に圧縮して記録できるディジタルデータ記録装置を提供することにある。
この発明の他の目的は、次グループにデータが続いているかどうかの情報を得ることができ、この情報を用いて伸長処理を効率的に行なうことができるディジタルデータ再生装置を提供することにある。
この発明は、ディジタルデータを入力する入力手段と、入力されたディジタルデータを圧縮するデータ圧縮手段と、固定長を有するグループ単位に対応してデータ圧縮手段で圧縮されたディジタルデータを一旦蓄えるバッファメモリと、データ圧縮手段にデータが残っているかどうかを検出するレジスタと、バッファメモリに蓄えられた圧縮ディジタルデータを記録媒体に記録する際に、レジスタにデータが残っているかどうかにより、圧縮された所定単位のディジタルデータが次のグループに続くかどうかを判断する判断手段と、
判断手段の判断結果を示す識別信号をバッファメモリに蓄えられた圧縮ディジタルデータに付加して、グループ単位毎に記録媒体に記録する記録手段とを備えるディジタルデータ記録装置である。
また、この発明は、所定の単位でディジタルデータをデータ圧縮手段で圧縮し、固定長を有するグループ単位に対応して、圧縮されたディジタルデータをバッファメモリに一旦蓄えると共に、データ圧縮手段にデータが残っているかどうかをレジスタで検出し、レジスタにデータが残っているかどうかにより、圧縮された所定単位のディジタルデータが次のグループに続くかどうかを判断し、判断結果を示す識別信号をバッファメモリに蓄えられた圧縮ディジタルデータに付加してグループ単位毎に記録された記録媒体から記録単位毎にデータを再生する再生手段と、記録媒体からグループ単位毎に再生された圧縮ディジタルデータを一旦蓄えるバッファメモリと、バッファメモリから読み出された圧縮ディジタルデータを伸長するデータ伸長手段と、データ伸長手段から供給されたディジタルデータを、グループ単位とは別の所定単位で処理して出力する出力手段と、記録媒体から識別信号を検出するための検出手段と、検出手段の出力に応じて、次の記録媒体の記録単位のディジタルデータを再生するかどうかを制御する制御手段とを備えてなるディジタルデータ再生装置である。
【図面の簡単な説明】
第１図及び第２図は従来の記録／再生装置の説明に用いる略線図、第３図はこの発明が適用されたテープストリーマドライブの一例のブロック図、第４図は磁気テープに記録される１パーティション内のデータ構造を示す略線図、第５図〜第７図はこの発明が適用されたテープストリーマドライブの一例におけるテープ記録フォーマットの説明に用いる略線図、第８図及び第９図はエンティティの説明に用いる略線図、第１０図及び第１１図はエンティティマップの説明に用いる略線図、第１２図はＧＩＴの説明に用いる略線図、第１３図及び第１４図はＢＡＴの説明に用いる略線図、第１５図はこの発明の適用されたテープストリーマドライブの一例における記録処理の説明に用いるフローチャート、第１６図はこの発明の適用されたテープストリーマドライブの一例における再生処理の説明に用いるフローチャート、第１７図はこの発明が適用されたテープストリーマドライブの他の例のブロック図、第１８図はこの発明が適用されたテープストリーマドライブの他の例の説明に用いるフローチャートである。
発明を実施するための最良の形態
以下、この発明の一実施例について図面を参照して説明する。第３図は、この発明が適用されたテープストリーマドライブの一例を示すものである。このテープストリーマドライブは、８ミリＶＴＲと同様の磁気テープを用い、ヘリカルスキャン方式で、磁気テープにデータを記録／再生するものである。
第３図において、１は回転ドラムである。回転ドラム１には、記録ヘッド２Ａ及び２Ｂ、再生ヘッド３Ａ及び３Ｂが配置される。記録ヘッド２Ａ及び２Ｂは、アジマス角の異なる２つのギャップが極めて近接して一体構造で設けられた所謂ダブルアジマス構造とされている。同様に、再生ヘッド３Ａ及び３Ｂは、ダブルアジマス構造とされている。
回転ドラム１に、磁気テープ５が巻き付けられる。この磁気テープ５は、８ミリＶＴＲのテープカセットと同様のカセットから引き出されたものである。回転ドラム１は、ドラムモータ４により回転される。また、磁気テープ５は、キャプスタンモータ６及びピンチローラ（図示せず）により送られる。ドラムモータ４及びキャプスタンモータ６は、メカコントローラ７の制御の基に回転される。メカコントローラ７により、ドラムサーボ及びトラッキングサーボ等の処理が行なわれている。メカコントローラ７と、全体制御を行なうシステムコントローラ２０とは双方向に接続されている。
このように記録ヘッド２Ａ及び２Ｂ、再生ヘッド３Ａ及び３Ｂが配置された回転ドラム１を用いて、ヘリカルスキャン方式でデータが記録／再生される。すなわち、磁気テープ５への記録データは、変調回路８で変調され、記録アンプ９を介して、記録ヘッド２Ａ及び２Ｂに供給される。記録ヘッド２Ａ及び２Ｂは互いに異なるアジマス角とされており、この傾斜トラックは、１トラック毎に異なるアジマス角のトラックとなる。
磁気テープ５のデータは、再生ヘッド３Ａ及び３Ｂにより再生される。再生ヘッド３Ａ及び３Ｂの出力は、再生アンプ１０を介して、復調回路１１に供給される。復調回路１１により、再生データが復調される。
このテープストリーマドライブでは、データの入出力に、ＳＣＳＩ（Small Computer System Interface）インターフェースが用いられている。すなわち、データを記録する際には、ホストコンピュータ（図示せず）から、所定の大きさ、例えば５１２バイトを１レコードとして、データが送られてくる。このデータは、ＳＣＳＩインターフェース１３を介して入力される。
このテープストリーマドライブでは、データを圧縮／伸長するためのデータ圧縮／伸長部１４が設けられている。データ圧縮／伸長部１４は、オリジナルデータ側インターフェース１５と、データ圧縮／伸長エンジン１６と、圧縮データ側インターフェース１７とからなる。データ圧縮／伸長部１４へのデータは、ＤＭＡで転送される。オリジルナルデータ側インターフェース１５及び圧縮データ側インターフェース１７は、ＤＭＡ転送を調整するためのＦＩＦＯ（First-In First-Out）レジスタを有している。
データ圧縮／伸長エンジン１６は、ＬＺ符号により、データの圧縮／伸長処理を行なうものである。ＬＺ符号は、入力した文字列の繰り返しを検出することにより、データの圧縮を行なうものである。すなわち、過去に処理した文字列とに専用のコードが割り振られ、辞書の形で登録される。文字列と辞書とが比較され、一致したときは辞書コードに書き換えられる。一致しなかった文字列は、逐次辞書に登録される。このように、入力文字列を辞書に登録し、文字列を辞書のコードに書き換えていくことにより、データが圧縮される。
このストリーマドライブには、レコード長レジスタ３１及びレコード数カウンタ３２が設けられる。レコード長レジスタ３１及びレコード数カウンタ３２により、オリジナルデータのレコード長及びレコード数が設定される。レコード長レジスタ３１及びレコードカウンタ３２の内容は、システムコントローラ２０により読み出し／書き込みできる。
データを記録する際には、ホストコンピュータから、レコード長とレコード数がレコード長レジスタ３１及びレコード数カウンタ３２に設定される。ホストコンピュータからは、例えば５１２バイトを１レコードとして、データが送られてくる。このデータは、ＳＣＳＩインターフェース１３を介して入力される。ＳＣＳＩインターフェース１３の出力は、データ圧縮／伸長部１４のオリシナルデータ側インターフェース１５を介して、データ圧縮／伸長エンジン１６に供給される。このデータは、データ圧縮／伸長エンジン１６により、ＬＺ符号を用いて圧縮される。データ圧縮／伸長エンジン１６の出力は圧縮データ側インターフェース１７を介して出力される。
圧縮データ側インターフェース１７の出力は、バッファコントローラ１８の制御の基に、バッファメモリ１９に一旦蓄えられる。バッファメモリ１９には、１グループ分のデータが蓄えられる。バッファメモリ１９の出力は、変調回路８に供給される。変調回路８の出力は、記録アンプ９を介して、記録ヘッド２Ａ及び２Ｂに供給される。記録ヘッド２Ａ及び２Ｂにより、磁気テープ５にデータが傾斜トラックで記録される。
データを再生する際には、磁気テープ５の記録データが再生ヘッド３Ａ及び３Ｂにより再生される。再生ヘッド３Ａ及び３Ｂの出力は、再生アンプ１０を介して、復調回路１１に供給される。復調回路１１により、再生データが復調される。復調回路１１の出力は、バッファコントローラ１８の制御の基に、バッファメモリ１９に一旦蓄えられる。バッファメモリ１９には、１グループ分のデータが蓄えられる。
バッファメモリ１９の出力は、データ圧縮／伸長部１４の圧縮データ側インターフェース１７を介して、データ圧縮／伸長エンジン１６に供給される。データ圧縮／伸長エンジン１６により、データが伸長され、元のデータに戻される。データ圧縮／伸長エンジン１６の出力は、オリジナルデータ側インターフェース１５を介して、ＳＣＳＩインターフェース１３に供給される。ＳＣＳＩインターフェース１３の出力がホストコンピュータに転送される。
第４図は、磁気テープ５の構成を示すものである。この発明が適用されたテープストリーマドライブでは、１本の磁気テープ５を複数のパーティションに区分けして管理することが可能とされている。すなわち、第４図Ａに示すように、磁気テープ５は、リールＲ１とＲ２との間に巻装される。第４図Ｂに示すように、１本の磁気テープ５は、最大２５６のパーティションに区分けして管理することが可能とされる。第４図Ｃに示すように、各パーティション内において、１グループと呼ばれる固定長の単位毎に、磁気テープ５への記録が行われる。１グループは２０フレームのデータ量に対応し、第４図Ｄに示すように、１フレームは２トラックである。このため、１グループは４０トラックとなる。
次に、この発明が適用されたテープストリーマドライブにおけるテープの記録フォーマットについて説明する。
第５図は１パーティションの構造を示すものである。なお、この図においては、全テープ長に対して１パーティションを形成していくものとして説明する。第５図に示すように、磁気テープの最初の部分にリーダーテープが位置しており、次にテープカセットのローディング／アンローディングを行う領域となるデバイスエリアが設けられる。このデバイスエリアの先頭が物理的テープの先頭位置ＰＢＯＴ（Phisycal Begining of Tape）とされる。
このデバイスエリアに続いて、テープの使用履歴情報等が格納されるシステム・ログエリアが設けられ、以降にデータエリアが設けられる。システム・ログエリアの先頭が論理的テープの開始位置ＬＢＯＴ（Logical Begining of Tape）とされる。
このデータエリアにおいては、最初にデータを作成して供給するベンダーに関する情報が示されるベンダーグループが設けられ、続いてグループ１〜ｎ毎にデータが記録される。そして、最後のグループｎに続いて、パーティションの終了を示すＥＯＤ（End of Date）の領域が設けられる。そしてＥＯＤの最後が、論理的テープの終了位置ＬＥＯＴ（Logical End of Tape）とされる。ＰＥＯＴ（Phisycal Ending of Tape）は、物理的テープの終了位置を示す。
１トラックには、第６図Ａに示すようなブロック構造でデータが記録される。１ブロックは１バイトのＳＹＮＣデータＡ１に続いてサーチ等に用いる６バイトのＩＤデータＡ２、２バイトのＩＤデータのためのエラー検出用のパリティＡ３、６４バイトのデータＡ４より構成される。
第６図Ｂに示すように、１トラックには４７１ブロックが配置される。１トラックには両端に４ブロック分のマージンＡ１１、Ａ１７が設けられ、これらマージンＡ１１の後ろとマージンＡ１７の前にはトラッキング制御用のＡＴＦエリアＡ１２、Ａ１６が設けられる。更に１トラックの中間に対しＡＴＦエリアＡ１４が設けられる。これらＡＴＦエリアＡ１２、Ａ１４、Ａ１６としては５ブロック分の領域が設けられる。そして、ＡＴＦエリアＡ１２、Ａ１４の間と、ＡＴＦエリアＡ１４、Ａ１６との間にそれぞれ２２４ブロック分のデータエリアＡ１３、Ａ１５が設けられる。
第７図は１グループのデータ構造を示すものである。前述したように２０フレーム（４０トラック）で１グループが構成される。第７図に示すように、１グループを形成する２０フレームのうち最後の２フレームには、エラー訂正用のＣ３パリティが割り当てられる。なお、Ｃ１、Ｃ２パリティは、ここでは詳しい説明は省略するが、例えば１トラック単位で完結するようにして第６図に示したデータについて付加される。
データの記録時には、矢印Ａｒｌで示すように、データグループの先頭のフレームから順次データが書き込まれていく。これに対して、矢印Ａｒ２で示すように、インデックス情報は、データの書き込み方向とは逆方向に、１８番目のフレームから順に書き込みが行われていく。
インデックス情報としては、現グループの内容を示すＧＩＴ（Group Information Table）と、エンティティ単位の管理情報となるＢＡＴ（Block Access Table）とがある。ＧＩＴは例えば４０バイトの固定長とされ、ＢＡＴはグループの内容に基づいて作成される４バイト単位のアクセスエントリよりなり、グループの内容に応じて可変長とされる。これらのインデックス情報については、後に詳述する。
エンティティとは、圧縮されたレコード毎のデータを管理するための単位で、複数分の圧縮されたレコードのデータで、エンティティが構成される。すなわち、例えば、第８図Ａに示すレコードがテープストリーマドライブに逐次入力されて圧縮処理が施されると、そのデータサイズは、レコードごとのデータ内容により変化する。この場合にはグループ化の前段階において、圧縮された所定の複数のレコードによって、第８図Ｂに示すエンティティというデータ単位が形成される。
なお、この図では、１エンティティを４つのレコードにより形成しているが、ここではあくまでも模式的に示しており、実際に１エンティティ内に含むべきレコード数は任意に設定される。
このエンティティは、第８図Ｂに示すように、最初にエンティティのデータ内容を示すエンティティヘッダが形成され、続いて圧縮された複数のレコードが位置される。なお、エンティティヘッダの内容については後述する。
そして、このようにレコードをエンティティ化したのち、例えば第８図Ｃに示すように、複数のエンティティＥ１、Ｅ２、Ｅ３、Ｅ４、Ｅ５によりデータのグループ化が行われる。この場合、ＢＡＴのアクセスエントリーはエンティティごとに作成される。
実際にグループにあてはめられるエンティティとしては、第９図の各エンティティＥ１１、Ｅ１２、Ｅ１３、Ｅ１４、Ｅ１５に示すように、エンティティはそのデータ長と開始位置に応じて、１グループ内に納まる場合（エンティティＥ１１、Ｅ１２、Ｅ１４）と、２以上の連続したグループにまたがる場合（エンティティＥ１３、Ｅ１５、Ｅ１６）がある。そして、１グループ内に納まるエンティティは「Entire Entity（ＥＴＥ）」として定義される。また、エンティティＥ１５のように、エンティティが２つのグループにまたがる場合には、２つのグループに渡るエンティティの前の部分が「Start Part of Entity（ＳＰＥ）」とされ、後ろの部分が「Last Part of Entity（ＬＰＥ）」として定義される。
また、エンティティＥ１３のように、３つのグループにまたがるものについては、連続する各グループにより分割されるエンティティのパートごとに、「Start Part of Entity（ＳＰＥ）」、「Middle Part of Entity（ＭＰＥ）」、「Last Part of Entity（ＬＰＥ）」として定義されて管理される。また、ここでは図示していないが、エンティティが２つのグループにまたがる場合には、このエンティティが各グループごとに「Start Part of Entity（ＳＰＥ）」、「Last Part of Entity（ＬＰＥ）」として定義されて管理される。
なお、エンティティ１４とエンティティ１５間に設けられる「File Mark」は、データファイルごとの区切りを示すファイルマークが付される位置に対応し、したがって、続くエンティティ１５は他のファイルのデータとなる。また、ここでは図示しないが１回の保存（記録）動作により記録されるデータの区切りに対しては、セーブセットマークが付される。
また、第９図のエンティティＥ１１、Ｅ１４、Ｅ１５の先頭部分に記されている＊印はアクセスポイントとされ、例えばＬＢＯＴ、セパレータマーク（ファイルマーク、セーブセットマーク）、アルゴリズムの変更など、エンティティの属性が変更されるような場合に、そのエンティティの先頭のレコードの開始位置に付される。
エンティティの構造について、更に詳述する。第１０図はエンティティの構造を示すものである。第１０図に示すように、エンティティの先頭にはエンティティヘッダが設けられる。バイトナンバ０〜バイトナンバ７までの８バイトの領域が与えられており、バイトナンバ０にはエンティティヘッダのデータ長を示す「Header Lendth」が配置される。例えば、現エンティティにアクセスポイントが存在するとすれば、レコードの記録はバイトナンバｎから開始されるものとされるが、このバイトナンバｎが「Header Lendth」により定義される。
バイトナンバ１にはアルゴリズムナンバ（「Algorithm Number」）が２進法により示される。このアルゴリズムナンバは、例えば、第１１図に示すように定義されており、アルゴリズムナンバが「０」とされている場合には、現エンティティに対してアクセスポイントが付されていないことが示され、「１」とされている場合には、現エンティティにアクセスポイントが存在すると共に、現エンティティ内のレコードは非圧縮データである。またアルゴリズムナンバが「３」若しくは「３２」とされている場合には、現エンティティにアクセスポイントが存在すると共に、現エンティティ内のデータについて所定方式によるデータ圧縮が施されているものとされる。
また、アルゴリズムナンバが「２」、「４」〜「３１」、「３３」〜「２５５」の場合は未定義（Reserved）とされている。
また、第１０図においてバイトナンバ２〜４の３バイトの領域には、例えばレコードの元のデータ長の情報である「Original record Length」が示される。この場合は前述のように５１２バイトであることが示される。
続く、バイトナンバ５〜７の３バイトの領域にはエンティティ内に含まれるべきレコード数の情報である「Record count in this Entity」とされ、予め規定されたレコード数の情報が格納される。なお、このレコード数としては、例えばレコード内にファイルの区切りを示すファイルマークが及び、データ保存時のセーブ位置の区切りを示すセーブセットマークが存在すれば、これらファイルマーク及びセーブセットマークもレコード数に含むようにされる。
そして、続くバイトナンバ８以降のバイト列に対してレコード群のデータが格納されていき、このようにして１エンティティが形成される。
前述のように、１グループ内にはインデックス情報としてＧＩＴ（Group Information Table）及びＢＡＴ（Block Access Table）が設けられる。これらのインディクス情報について更に説明する。
第１２図はＧＩＴの構造を示すものである。前述したように、ＧＩＴは例えば４０バイトからなる固定長とされ、以下説明するように現グループに関わる管理情報等が格納される。ＧＩＴには、図のようにフィールドＦ１〜Ｆ１６が配置される。
これらフィールドＦ１〜Ｆ１６において、先ずフィールドＦ２は、「Group Number」のフィールドとされて３バイトの領域を有し、現グループに対して割り当てられた固有のグループナンバの情報が格納される。
フィールドＦ３は４バイトからなる「Record count」の領域とされて論理的テープ開始位置ＬＢＯＴから現グループ内に含まれるレコードの総数の情報が格納される。
フィールドＦ４は４「File Mark Count」とされて４バイトからなり、ＬＢＯＴから現グループ内に含まれるファイルマークの総数の情報が格納され、同様に４バイトからなるフィールドＦ５の「Save-Set Mark Count」の領域は、ＬＢＯＴから現グループ内に含まれるセーブセットマークの総数の情報が格納される。
フィールドＦ７（３バイト）は、「Group Number of the Previous Record」の領域とされ、現グループより前のグループにおいてファイルマーク、又はセーブセットマーク、又はレコードの先頭が存在する最後のグループのグループナンバの情報が格納される。
フィールドＦ９（３バイト）の「Group Number of the Previous File Mark」の領域は、最後に記録されたファイルマークの存在するグループのグループナンバの情報が格納され、フィールドＦ１１（３バイト）の「Group Number of the Previous Save-Set Mark」の領域は、最後に記録されたセーブセットマークの存在するグループのグループナンバの情報が格納される。
フィールドＦ１２（２バイト）、は「Block Access Table Count」の領域とされ、現グループのＢＡＴのアクセスエントリー数の情報が格納される。ＢＡＴは、４バイトのアクセスエントリーという単位よりなる。
フィールドＦ１３（２バイト）は、「Count of Record in current Basic Group」の領域とされて、現グループ内のレコード数の情報が格納されるが、この場合のレコード数には現グループ内のファイルマーク及びセーブセットマークの数も含まれる。
また、フィールドＦ１４（２バイト）は「Count of File Mark in current Basic Group」とされて、現グループ内のファイルマークの数の情報が格納され、フィールド１５（２バイト）は「Count of Save-Set Mark in current Basic Group」とされて、現グループ内のセーブセットマーク数の情報が格納される。
またフィールドＦ１、Ｆ６、Ｆ８、Ｆ１０（各１バイト）及びフィールドＦ１６（４バイト）は未定義とされている。
次にＢＡＴの構造について説明する。ＢＡＴは１以上のアクセスエントリーにより形成される。ＢＡＴを形成する個々のアクセスエントリーにより、グループ内に含まれることになるレコード、ファイルマーク及びセーブセットマークに関する情報が示される。したがって、ＢＡＴアクセスエントリー数は、グループごとに当てはめられたエンティティの内容に応じて変わるために、ＢＡＴのデータサイズは可変長となる。
１アクセスエントリーは、第１３図に示すように４バイトとされる。そして、最初の第１バイト（１ｓｔ  Ｂｙｔｅ）は、ＢＡＴフラグが割り当てられるフラグバイトとされ、アクセスエントリーを定義し、残る第２〜第４バイト（２ｎｄ〜４ｔｈ  Ｂｙｔｅ）の計３バイトがそれに関わる内容を示すカウントフィールドとされている。
ここでＢＡＴを形成するアクセスエントリーが複数ある場合、グループに対して最初に書き込まれることになるアクセスエントリーはＧＩＴの直前に配置され、続く残りのアクセスエントリーは、データの記録方向と逆方向から順に書き込まれていくようにされる。
そして、アクセスエントリーの第１バイトに割り当てられるＢＡＴフラグは第１４図に示すように定義されている。この図によればＢＡＴフラグナンバはビットアサインとされており、２進法によりＢＡＴフラグナンバが割り与えられる。
ＢＡＴフラグナンバ１（00000001）の場合は、「Entire Entry」と定義される。「Entire Entry」と定義された場合は、このアクセスエントリーにより示されるエンティティが「Entire Entity（ＥＴＥ）」とされていることを表す。すなわち、先に第９図に示したエンティティＥ１１、Ｅ１２、Ｅ１４のように、現グループ内においてそのエンティティが開始／終了していることを示す。そして、カウントフィールドにより当該エンティティのバイト数が表される。また、ＢＡＴフラグナンバ２（00000010）の場合は、「Start Part of Entry」と定義され、このアクセスエントリーが示すエンティティが現グループ内において「Start Part of Entity（ＳＰＥ）」であることが示され、カウントフィールドにより、そのバイト数が示される。
ＢＡＴフラグナンバ３（00000011）の場合は、「Middle Part of Entry」が定義されて、現グループ内のエンティティが「Middle Part of Entity（ＭＰＥ）」であることが示され、カウントフィールドによりそのバイト数が表される。
ＢＡＴフラグが４（00000100）の場合は、「Last Part of Entry」が定義されて、対応するエンティティが現グループ内において「Last Part of Entity（ＬＰＥ）」であることが示され、カウントフィールドによりそのバイト数が示される。
ＢＡＴフラグナンバ５（00000101）は、「Total Count of Entry」とされる。「Total Count of Entry」は「Last Part Entry」のすぐ次に配置されるものとされ、原則として、両者は同一のグループ内にあるようにされる。この場合、カウントフィールドにより直前の「Last Part Entity」が示すエンティティ全体のバイト数が表される。
次に、ＢＡＴフラグナンバ６（00000111）〜１０（00001010）の場合は、それぞれ「Entire Unprocessed Entry」，「Start Part of Unprocessed Entry」，「Middle Part of Unprocessed Entry」，「Last Part of Unprocessed Entry」，「Total Count of Unprocessed Entry」とされ、特に、圧縮処理されないレコードによって形成されたエンティティを含むグループを作成する場合に、そのグループ内のエンティティの内容に応じて設定される。
なお、その定義内容及びフィールドカウントの示す内容は、上述した「Entire Entry」，「Start Part of Entry」，「Middle Part of Entry」，「Last Part of Entry」，「Total Count of Entry」に原則として準ずるものとされる。
ＢＡＴフラグナンバ１１（00001011）の場合は、「Separator Mark Entry」が定義され、このアクセステーブルによりファイル・マーク又はセーブセット・マークの領域を示すことになる。この場合、当該アクセステーブルに対応するセパレータマークがファイル・マークであればフィールドカウントが「０」とされ、セーブセット・マークであればフィールドカウントが「１」とされる。
ＢＡＴフラグナンバ１２（00001011）の場合は「Skip Entry」が定義され、この「Skip Entry」により現グループにおけるユーザデータの最終バイトが示される。そして、カウントフィールドにはグループ内の残りのバイト数が示される。このため、カウントフィールドの最小値が、現グループにおけるＧＩＴとＢＡＴよりなるインデックス情報の領域の全バイト数に対応する。
ＢＡＴフラグナンバ０及びＢＡＴフラグナンバ０１３〜２５５は未定義とされている。
また、このテープストリーマドライブのシステムにおいてはＥＷＰ（Early Warning Point」という概念があり、これは磁気テープの記録可能領域の終端が近くなっていることを警告するために示すポイントとされる。
例えば、このＥＷＰを越えてデータ記録が行われると、アクセスエントリーについて、ＡＥＷＰ（After Early Warning Point）であるという情報が付加される。
このＡＥＷＰは、ＢＡＴフラグナンバの１バイトにおけるＭＳＢをＡＥＭＰとして扱うことにより定義される。ＡＥＷＰビットが「０」とされていれば、上述したようにＢＡＴフラグナンバ０〜１２７によるアクセスニントリーが用いられ、これらのＢＡＴフラグについてＡＥＷＰビットが「１」とされると、ＢＡＴフラグナンバはそれぞれＢＡＴフラグナンバ−１２８〜−１となり、上述したＢＡＴフラグナンバ０〜１２７のＢＡＴフラグの各定義内容に対して、ＥＷＰを越えて記録されているものであるという内容が付加される（図には（ｗｉｔｈ  ＡＥＷＰ）として示す。）
第３図に示したように、この発明が適用されたテープストリーマドライブでは、レコード長レジスタ３１及びレコード数カウンタ３２が設けられる。そして、データ記録時には、レコード長レジスタ３１に転送されるデータのレコード長が設定され、レコード数カウンタ３２に転送されるデータのレコード数が設定される。そして、このレコード長レジスタ３１及びレコード数カウンタ３２は、外部から書き換えることができる。
レコード数カウンタ３２は、ホストコンピュータから１レコードづつデータが送られてくる毎にデクリメントされる。このレコード数カウンタ３２により転送されてきたデータのレコード数が判断できる。転送されてきたレコード数が最初にホストコンピュータから要求された数に達すると、レコード数カウンタ３２が例えば「０」となり、ホストコンピュータからのデータの転送が終了される。
ところで、圧縮データは可変長なので、転送されてきたデータが最初にホストコンピュータから要求された数に達する前に、バッファメモリ１９が溢れるようなことがあり得る。バッファメモリ１９が溢れたかどうかは、例えば、現在までのデータを格納した位置を示すバッファメモリ１９のカレントアドレスと、メモリ容量として確保されている終了アドレスとを比較することで判断できる。カレントアドレスが終了アドレスと一致したら、バッファメモリ１９が溢れ出すことを意味する。このバッファメモリ１９が溢れ出すかどうかの情報はレジスタ３３により示される。バッファメモリ１９が溢れるような場合には、レコード数カウンタ３２が例えば「１」に設定される。これにより、次の１回のデータの転送で、レコード数カウンタ３２が「０」になり、ホストコンピュータからのデータの転送が中断される。
このように、レコード数カウンタ３２の値を変更することで、ホストコンピューからのデータを圧縮して記録する際に、バッファメモリが溢れることがないようにデータの転送を制御することが可能である。
第１５図は、このときの処理を示すフローチャートである。第１５図において、システムコントローラ２０は、ＳＣＳＩインターフェース１３を介して入力されるホストコンピュータからの指令により、コード長及びレコード数をレコード長レジスタ３１及びレコード数カウンタ３２に設定する（ステップＳＴ１）。加えて、システムコントローラ２０はバッファコントローラ１８にバッファメモリ１９の開始アドレスと終了アドレスと設定させ、バッファメモリ１９の容量が確保される（ステップＳＴ２）。つまり、バッファメモリ１９は、メモリコントローラ１８により制御されており、バッファメモリ１９の残量（記憶可能容量）は、バッファコントローラ１８内のレジスタ３３により監視されている。
ホストコンピュータからレコード毎にデータが転送されてくる（ステップＳＴ３）。このデータは、データ圧縮伸長部で１４で圧縮され、バッファメモリ１９に蓄えられる（ステップＳＴ４）。バッファコントローラ１８のレジスタ３３により、バッファメモリ１９の残量が監視され、バッファメモリ１９が溢れたかどうかが判断される（ステップＳＴ５）。バッファメモリ１９が溢れ出していなければ、システムコントローラ２０は、１レコード分のデータが圧縮される毎に、レコード数カウンタ３２をデクリメントする（ステップＳＴ６）。そして、システムコントローラ２０によってレコード数カウンタ３２が「０」に達したかどうかが判断され（ステップＳＴ７）、「０」に達していなければ、ステップＳＴ３に戻される。
ステップＳＴ３〜ＳＴ７を繰り返していくと、１レコードづつ転送されてくるに従って、レコード数カウンタ３２の値が「０」に近づいていく。その間、バッファメモリ１９が溢れ出さなければ、ステップＳＴ７でレコード数カウンタ３２の値が「０」になる。システムコントローラ２０は、レコード数カウンタ３２の値が「０」になったら、ＢＡＴフラグを付加し（ステップＳＴ８）、データ転送が終了される（ステップＳＴ９）。バッファメモリ１９が溢れ出さないときには、そのグループでレコードのデータが全て記録されるので、エンティティとしては「Entire Entity（ＥＴＥ）」又は「Last Part of Entity（ＬＰＥ）」となり、これに応じて、「Entire Entry」又は「Last Part of Entry」が付加されることになる。
ステップＳＴ３〜ＳＴ７を繰り返していく間に、ステップＳＴ５でバッファメモリ１９が溢れ出したことが検出されると、システムコントローラ２０は、レコード数カウンタ３２の値を「１」に設定する（ステップＳＴ１０）。レコード数カウンタ３２の値が「１」に設定されると、現在転送されているレコードの転送が終了したときにレコード数カウンタ３２が「０」になり、ステップＳＴ７でレコード数カウンタ３２の値が「０」になる。レコード数カウンタ３２の値が「０」になったら、ＢＡＴフラグが付加され（ステップＳＴ８）、データ転送が終了される（ステップＳＴ９）。このときには、そのグループの次にデータが跨がるので、エンティティとしては「Start Part of Entity（ＳＰＥ）」又は「Middle Part of Entity（ＭＰＥ）」となり、これに応じてシステムコントローラ２０は、ＢＡＴフラグを付加する。
前述したように、この発明が適用されたテープストリーマドライブでは、データを記録する際に、レコードをエンティティ化して記録している。そして、エンティティとしては、「Entire Entity（ＥＴＥ）」と、「Start Part of Entity（ＳＰＥ）」と、「Last Part of Entity（ＬＰＥ）」と、「Middle Part of Entity（ＭＰＥ）」が定義されており、ＢＡＴフラグには、どのエンティティに属するかが示されている。このエンティティの種類から、データがそのグループで完結するか、次のグループに続くかを判断できる。したがって、ＢＡＴの情報から、エンティティの種類を判断し、次グループに続くエンティティの場合には、次のグループをアクセスするようにし、次のグループに続かない場合には、そのグループで終了している。
すなわち、「Entire Entity（ＥＴＥ）」は、１グループ内に収まるエンティティである。また、「Last Part of Entity（ＬＰＥ）」は、複数のグループに渡るエンティティの後半部である。したがって、エンティティが「Entire Entity（ＥＴＥ）」又は「Last Part of Entity（ＬＰＥ）」なら、次のグループにアクセスする必要はない。「Start Part of Entity（ＳＰＥ）」は、複数のグループに渡るエンティティの前半部である。また、「Middle Part of Entity（ＭＰＥ）」は、複数のグループに渡るエンティティの中間部である。したがって、エンティティが「Start Part of Entity（ＳＰＥ）」又は「Middle Part of Entity（ＭＰＥ）」なら、次のグループに続いているので、次のグループをアクセスする必要がある。
第１６図は、第３図に示されるテープストリーマドライブの再生時の処理を示すフローチャートである。第１６図において、ホストコンピュータからの指令により、システムコントローラ２０は、レコード長レジスタ３１及びレコード数カウンタ３２に、レコード長及びレコードカウント数を設定する（ステップＳＴ２１）。そして、磁気テープ５から１グループ分のデータが再生され、この１グループ分の再生データがバッファメモリ１９に蓄えられる（ステップＳＴ２２）。
前述したように、ＧＩＴには、現グループ内のレコード数の情報が格納されており、この情報から、現グループのレコード数が得られる。システムコントローラ２０は、ステップＳＴ２１で設定されたレコード数と、再生された現グループのレコード数とを比較する（ステップＳＴ２３）。
システムコントローラ２０は、設定されたレコード数が現グループのレコード数より大きければ、バッファメモリ１９に蓄えられていた１グループ分のデータをデータ圧縮伸長部１４に送り、この圧縮伸長部１４において、１グループ分のデータの伸長処理が行なわれる（ステップＳＴ２４）。なお、設定されたレコード数が現グループのレコード数より大きくなければ、後に説明するように、ステップＳＴ２８に進み、システムコントローラ２０は、ＢＡＴフラグから、「Entire Entity（ＥＴＥ）」、「Last Part of Entity（ＬＰＥ）」であるかどうかを判断して、処理が進められる。
ステップＳＴ２４で、１グループ分のデータの伸長処理が行なわれるとき、レコード数カウンタ３２に設定されているレコード数から送出したレコード数がデクリメントされていき、残りのレコード数としてレコード数カウンタ３２に設定される（ステップＳＴ２５）。
データ圧縮／伸長エンジン１６がバッファメモリ１９にある１グループ分のデータの伸長処理を終了したら、システムコントローラ２０は、残りのレコード数と、現グループのレコード数とを比較する（ステップＳＴ２６）。そして、残りのレコード数が現グループのレコード数より大きければ、次の１グループ分のデータがバッファメモリ１９に蓄えられる（ステップＳＴ２７）。そして、ステップＳＴ２４に戻され、次の１グループ分のデータがバッファメモリ１９からデータ圧縮伸長部１４に送られ、１グループ分のデータの伸長処理が行なわれる。
ステップＳＴ２４〜ステップＳＴ２７の処理を繰り返していくと、１グループづつ再生データの伸長処理が続けられ、残りのレコード数が減少していく。やがて、ステップＳＴ２６で、残りのレコード数がそのグループのレコード数より大きくないと判断される。
ステップＳＴ２６で、残りのレコード数がそのグループのレコード数より大きくないと判断されたら、システムコントローラ２０は、ＢＡＴフラグから、「Entire Entity（ＥＴＥ）」若しくは「Last Part of Entity（ＥＰＥ）」であるかどうかを判断する（ステップＳＴ２８）。前述したように、ＢＡＴフラグが「Entire Entity（ＥＴＥ）」若しくは「Last Part of Entity（ＬＰＥ）」なら、そのエンティティは、そのブロックで完結しているとみなすことができる。
ステップＳＴ２８で、ＢＡＴフラグが「Entire Entity」若しくは「Last Part of Entity（ＬＰＥ）」なら、システムコントローラ２０は、レコード数カウンタ３２をそのエンティティのレコード数に設定する（ステップＳＴ２９）。そして、そのエンティティのデータがデータ圧縮／伸長部１４に送られ（ステップＳＴ３０）、そして、レコード数カウンタ３２に設定されているレコード数から、送出されたレコード数だけデクリメントされていき、残りのレコード数がレコード数カウンタ３２に設定される（ステップＳＴ３１）。更に、システムコントローラ２０は、残りのレコード数が「０」になったかどうかを判断し（ステップＳＴ３２）、残りのレコード数が「０」になったら、データの再生処理を終了する。
ステップＳＴ２８で、エンティティが「Entire Entity（ＥＴＥ）」若しくは「Last Part of Entity（ＬＰＥ）」以外であると判断されたら、すなわち、エンティティが「Start Part of Entity（ＳＰＥ）」若しくは「Middle Part of Entity（ＭＰＥ）」であると判断されたら、次のエンティティのデータは次のグループに続いているので、次のグループにアクセスする必要がある。
つまり、システムコントローラ２０はＢＡＴフラグの内容に基づいて、そのグループの最後のエンティティが「Entire Entity（ＥＴＥ）」若しくは「Last Part of Entity（ＬＰＥ）」以外であると判断すると、レコード数カウンタ３２の残りレコード数をそのエンティティのレコードに設定する（ステップＳＴ３３）。そして、そのエンティティのデータがデータ圧縮／伸長部１４に送られ（ステップＳＴ３４）、レコード数カウンタ３２に設定されているレコード数から、送出されたレコード数だけデクリメントされていき、残りのレコード数としてレコード数カウンタ３２に設定される（ステップＳＴ３５）。そして、システムコントローラ２０によって、残りのコード数が「０」になったかどうかが判断される（ステップＳＴ３６）。残りのレコード数が「０」になったら、次の１グループ分のデータがバッファメモリ１９に蓄えられる（ステップＳＴ３７）。そして、ステップＳＴ２８に進められる。
ステップＳＴ３３〜３７で、「Start Part of Entity（ＳＰＥ）」若しくは「Middle Part of Entity（ＭＰＥ）」のエンティティの処理が行なわれているので、次のグループの最初のエンティティは、通常、これに続く「Last Part of Entity」（ＬＰＥ）」である。したがって、通常、ステップＳＴ２８で、エンティティは「Entire Entity（ＥＴＥ）」若しくは「Last Part of Entity（ＬＰＥ）」であると判断される。
システムコントローラ２０によってエンティティは「Entire Entity（ＥＴＥ）」若しくは「Last Part of Entity（ＬＰＥ）］であると判断されたら、前述したように、ステップＳＴ２９でレコード数カウンタ３２の残りレコード数がそのエンティティのレコード数に設定され、ステップＳＴ３０でそのエンティティのデータがデータ圧縮／伸長部１４に送られ、ステップＳＴ３１で残りのレコード数としてレコード数カウンタ３２に設定され、ステップＳＴ３２で残りのコード数が「０」になったかどうかが判断され、残りのレコード数が「０」になったら、データの再生処理が終了される。
次に、第１７図を参照しながら、本願発明が適用されるテープストリーマの記録動作時の他の実施例を説明する。前述の例では第１５図に示されるように、バッファメモリ１９内の記憶可能な残量を監視してＢＡＴフラグの付加を行っていたが、以下の例では、１グループの圧縮が終了したときに、データ圧縮伸長部１４にデータが残っているかどうかに応じて、ＢＡＴフラグを付加する。すなわち、第１７図に示すように、データ圧縮伸長部１４にデータが残っているかどうかを検出するためのレジスタ４１、４２、４３が設けられる。これらのレジスタ４１、４２、４３により、オリジナルデータ側インタフェース１５、圧縮データ側インターフェース１７、及びデータ圧縮／伸長エンジン１６にデータがあるかどうかが検出される。システムコントローラ２０は１グループ分のデータの圧縮を終了したときに、これらのレジスタ４１、４２、４３により、オリジナルデータ側インタフェース１５、圧縮データ側インターフェース１７、及びデータ圧縮／伸長エンジン１６にデータが残っているかどうかを検出し、これに応じて、ＢＡＴフラグを付加する。
すなわち、第１８図はこのときの処理を示すフローチャートである。第１８図において、１グループ分のデータを圧縮したかどうかが判断される（ステップＳＴ５１）。１グループ分に到達するまで圧縮していなければ、圧縮処理が続けられる。なお、バッファメモリ１９は１グループ分のデータを圧縮させるのに十分な容量を有するものとする。
１グループ分のデータが圧縮されたら、システムコントローラ２０はレジスタ４１の内容から、オリジナルデータ側インターフェース１５にデータが残っているかどうかを判断する（ステップＳＴ５２）。オリジナルデータ側インターフェース１５にデータが残っていなければ、同様にレジスタ４２の内容から、データ圧縮／伸長エンジン１６にデータが残っているかどうかが判断される（ステップＳＴ５３）。データ圧縮／伸長エンジン１６にデータが残っていなければ、更にレジスタ４３の内容から、圧縮データ側インターフェース１７にデータが残っているかどうかが判断される（ステップＳＴ５４）。
ステップＳＴ５２〜ＳＴ５４で、オリジナルデータ側インターフェース１５、データ圧縮／伸長エンジン１６、圧縮データ側インターフェース１７の何れかにデータが残っている場合には、システムコントローラ２０は次グループに続くエンティティ、「Start Part of Entity（ＳＰＥ）」又は「Middle Part of Entity（ＭＰＥ）」であるであると判断し（ステップＳＴ５５）、そのことを示すＢＡＴフラグを付加する（ステップＳＴ５６）。そして、次のグループのデータがデータ圧縮伸長部１４に取り込まれる。
ステップＳＴ５２〜ＳＴ５４で、オリジナルデータ側インターフェース１５、データ圧縮／伸長エンジン１６、圧縮データ側インターフェース１７の何れにもデータが残っていない場合には、システムコントローラ２０によってグループの最後のエンティティは、そのグループ内で収まるエンティティ、「Entire Entity（ＥＴＥ）」又は「Last Part of Entity（ＬＰＥ）」であると判断され（ステップＳＴ５８）、そのことを示すＢＡＴフラグが付加される（ステップＳＴ５９）。そして、そのグループの処理は終了される。
以上のように、この発明によれば、レコード単位に入力されたオリジナルデータを圧縮し、バッファメモリに一旦蓄え、磁気テープに記録している。そして、記録時に、バッファメモリが溢れるかどうかが検出され、バッファメモリが溢れることが検出されると、レコード数カウンタの値が動的に変更される。このため、バッファメモリが溢れることが防止できる。そして、圧縮されたデータをエンティティ化して、各グループに記録し、エンティティの種類を示すＢＡＴフラグが付加されている。
再生時には、ＢＡＴフラグから、次グループに続くエンティティ「Start Part of Entity（ＳＰＥ）又は「Middle Part of Entity（ＭＰＥ）」か、そのグループで完結されるエンティティ「Entire Entity（ＥＴＥ）又はLast Part of Entity（ＬＰＥ）」かが判断される。エンティティが「Start Part of Entity（ＳＰＥ）又はMiddle Part of Entity（ＭＰＥ）」なら、次のグループがアクセスされ、「Entire Entity（ＥＴＥ）又はLast Part of Entity（ＬＰＥ）」なら、そのグループでアクセスが終了される。これにより、無駄なアクセスが起こらなくなり、再生処理の効率化が図れる。
【図１】
0003750137.tif 000002
【図２】
0003750137.tif 000003
【図３】
0003750137.tif 000004
【図４】
0003750137.tif 000005
【図５】
0003750137.tif 000006
【図６】
0003750137.tif 000007
【図７】
0003750137.tif 000008
【図８】
0003750137.tif 000009
【図９】
0003750137.tif 000010
【図１０】
0003750137.tif 000011
【図１１】
0003750137.tif 000012
【図１２】
0003750137.tif 000013
【図１３】
0003750137.tif 000014
【図１４】
0003750137.tif 000015
【図１５】
0003750137.tif 000016
【図１６】
0003750137.tif 000017
【図１７】
0003750137.tif 000018
【図１８】
0003750137.tif 000019
0003750137.tif 000020