データ編集方法、データ編集装置
【課題】記録媒体に記録されるストリームデータについての編集処理の負担軽減を図り、より高速な編集動作を得る。
【解決手段】記録媒体に記録されるストリームデータは、ファイルシステムによってファイルとして管理することを前提とし、ファイルシステムによって管理されるトラック管理用データファイルにより、ストリームデータをトラック単位で管理するようにされる。そして、トラック単位による分割、消去の編集は、トラック管理用データファイルにおいて各トラックを規定するトラック管理情報の内容を書き換えることで実行することとする。この構成であれば、トラック単位による分割、消去編集処理にあたっては、ファイルシステムを書き換える必要はないことになる。
【解決手段】記録媒体に記録されるストリームデータは、ファイルシステムによってファイルとして管理することを前提とし、ファイルシステムによって管理されるトラック管理用データファイルにより、ストリームデータをトラック単位で管理するようにされる。そして、トラック単位による分割、消去の編集は、トラック管理用データファイルにおいて各トラックを規定するトラック管理情報の内容を書き換えることで実行することとする。この構成であれば、トラック単位による分割、消去編集処理にあたっては、ファイルシステムを書き換える必要はないことになる。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、所定の記録媒体に記録されたデータを編集するためのデータ編集方法、データ編集装置に関する。
【０００２】
【従来の技術】
パーソナルコンピュータには、記憶媒体としてＨＤＤ（ハードディスクドライブ）が備えられる。
そして、周知のようにして、このようなＨＤＤに対するファイルの記録再生は、いわゆるファイルシステムが採用される。例えばこのようなファイルシステムとしては、ＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）が知られている（例えば非特許文献１参照）。
【０００３】
また、近年においては、上記したパーソナルコンピュータの周辺機器として、ビデオ、オーディオなどのコンテンツデータを記録再生できるＡＶ機器が提案され、また、知られるようになってきている。
このようなＡＶ機器は、例えば携帯可能な程度のサイズ形状とされる。そして、所定のデジタルインターフェイスによって、パーソナルコンピュータと接続されることで、例えばパーソナルコンピュータ側から、コンテンツデータを取り込み、装填された所定の記録媒体に記録して保存することができる。
そして、このようにして記録媒体にコンテンツデータを保存した後は、ＡＶ機器単体で、記録媒体からコンテンツデータを再生して音声、画像として出力することが可能とされている。
【０００４】
【非特許文献１】
Ｍｉｃｒｏｓｏｆｔ Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｉｔｉａｔｉｖｅ ＦＡＴ３２ Ｆｉｌｅ Ｓｙｓｔｅｍ Ｓｐｅｃｉｆｉａｔｉｏｎ
ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｈｗｄｅｖ／ｈａｒｄｗａｒｅ／ｆａｔｇｅｎ．ａｓｐ
【発明が解決しようとする課題】
【０００５】
そして、上記したようなＡＶ機器において、記録媒体に記録したコンテンツデータを管理するのにあたっては、例えば、ファイルシステムを採用することも提案され、また、実現されてきている。このようにすれば、ファイル管理の形態は、データインターフェイスを介して接続されるパーソナルコンピュータと同様となるから、それだけ、パーソナルコンピュータとの親和性が高まり、この点で、有用性が高い。
【０００６】
また、上記したようなＡＶ機器においては、コンテンツデータの分割、消去などの、いわゆる編集機能が与えられることが、ユーザの使い勝手上好ましい。
しかしながら、記録データの管理に、上記のようにしてファイルシステムを採用した場合には、次のような問題を有することになる。
ファイルシステムによるデータ管理は、記録媒体に物理的に記録されたデータを直接的に管理するものである。従って、例えば、コンテンツデータに対する分割、消去等の編集に応じては、その編集結果が適切に得られるように、ファイルシステムの内容そのものを更新する必要が生じる。
例えば、上記したようなＡＶ機器にとっては、ファイルシステムの更新は、相応に重い処理であり、システムにもかなりの負荷がかかる。このため、上記した分割、消去などの編集処理に際しては、ファイルシステムの更新の終了に或る程度の時間を要することになるので、結果として、編集処理には相応の時間がかかることになってしまう。
【０００７】
【課題を解決するための手段】
そこで、本発明は上記した課題を考慮して、先ずは、ファイルシステムによりファイルとして管理されるコンテンツデータ（ストリームデータ）についての編集処理について、より軽い処理負担により実行できるようにしてシステムの効率化を図ることを目的とする。
【０００８】
そこで先ず、データ編集方法として次のように構成する。
つまり、本発明のデータ編集方法としては、所定の記録媒体に記録されるストリームデータを、ファイルシステムに基づくファイル単位で管理する第１のデータ管理手順と、ファイル単位のストリームデータの範囲内におけるデータ部分をトラックとし、トラックごとに対応する情報であって、ファイル単位のストリームデータとの対応を示す情報要素と、対応するファイル単位のストリームデータにおけるそのトラックのデータ位置を示す情報要素とを有して形成されるトラック管理情報を含むトラック管理用データファイルに基づいて、トラック単位での管理を行う第２のデータ管理手順とを実行するものとされる。
そして、上記ファイル単位のストリームデータを分割して複数トラックを形成するトラック分割、又はトラックを消去するトラック消去を行う場合には、第２のデータ管理手順が、トラック分割又はトラック消去の態様に応じて、トラック管理用データファイルにおけるトラック管理情報の内容について更新処理を実行するように構成する。
【０００９】
また、データ編集装置として次のように構成する。
本発明のデータ編集装置は、所定の記録媒体に記録されるストリームデータを、ファイルシステムに基づくファイル単位で管理する第１のデータ管理手段と、ファイル単位のストリームデータの範囲内におけるデータ部分をトラックとし、トラックごとに対応する情報であって、ファイル単位のストリームデータとの対応を示す情報要素と、対応するファイル単位のストリームデータにおけるそのトラックのデータ位置を示す情報要素とを有して形成されるトラック管理情報を含むトラック管理用データファイルに基づいて、トラック単位での管理を行う第２のデータ管理手段とを備える。
そして、ファイル単位のストリームデータを分割して複数トラックを形成するトラック分割、又はトラックを消去するトラック消去を行う場合には、第２のデータ管理手段が、上記トラック分割又はトラック消去の態様に応じて、トラック管理用データファイルにおけるトラック管理情報の内容について更新処理を実行するように構成することとした。
【００１０】
上記各構成によれば本発明は、先ずは、記録媒体に記録されるストリームデータを、ファイルシステムによってファイルとして管理するようにされる。その下で、ファイルシステムによって管理されるトラック管理用データファイルにより、ストリームデータをトラック単位で管理するという管理構造を有するようにされている。そして、トラック単位による分割、消去などの編集（トラック分割、トラック消去）は、上記トラック管理用データファイルにおいて各トラックを規定する情報内容を有するトラック管理情報の内容を書き換えることで行われる。このような構成であれば、トラック単位による分割、消去編集を行うのにあたっては、ファイルシステムの書き換えに依存する必要はないこととなる。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態について説明を行うこととする。なお、以降の説明は次の順序で行う。
１．記録再生装置の構成
２．ディスク及びストレージ部の構成
３．ＡＶデータの管理
４．トラック分割、消去編集
５．ディスク上消去
６．ブロック暗号化されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのディスク上消去
【００１２】
１．記録再生装置の構成
実施の形態としての記録再生装置は、一例として、磁界変調方式でデータ記録が行われる光磁気ディスクであるミニディスク（ＭＤ）方式のディスクに対する記録再生装置とする。但し、既に普及している音楽用途のミニディスクのみではなく、より高密度記録を可能とし、ビデオデータの他、コンピュータユースの各種データのストレージに利用できる高密度ディスクについても対応可能な記録再生装置である。
【００１３】
図１により本実施の形態の記録再生装置の構成を説明する。
図１においては、本実施の形態の記録再生装置１が、例えばパーソナルコンピュータ（或いはネットワーク）１００として外部の機器との間でデータ通信可能な機器として示している。
例えば記録再生装置１は、パーソナルコンピュータ１００とＵＳＢケーブル等の伝送路１０１で接続されることで、パーソナルコンピュータ１００に対する外部ストレージ機器として機能できる。また、パーソナルコンピュータ１００を介したり、或いは直接ネットワークと接続できる機能を備えるなどしてネットワーク接続されることで、音楽や各種データをダウンロードし、記録再生装置１においてストレージ部２に装填されたディスクに保存できるものともなる。
【００１４】
一方、この記録再生装置１はパーソナルコンピュータ１００等に接続しなくとも、例えばＡＶ（オーディオ・ビデオ）機器として機能する。例えば他のＡＶ機器等から入力されたオーディオデータやビデオデータ（ＡＶデータ）をディスクに記録したり、ディスクに記録された音楽データ等を再生出力することができる。
即ち本実施の形態の記録再生装置１は、パーソナルコンピュータ１００等に接続されることで汎用的なデータストレージ機器として利用でき、かつ単体ではＡＶ対応の記録再生機器としても利用できる装置である。
【００１５】
記録再生装置１は、ストレージ部２、キャッシュメモリ３、ＵＳＢインターフェース４、入出力処理部５、表示部６、操作部７、システムコントローラ８、ＲＯＭ９、ＲＡＭ１０、キャッシュ管理メモリ１１、ＮＶ−ＲＡＭ１２を備える。
【００１６】
ストレージ部２は、装填されたディスクに対する記録／再生を行う。本実施の形態で用いるいわゆるミニディスク方式のディスク及びそれに対応するストレージ部２の構成については後述する。
【００１７】
キャッシュメモリ３は、ストレージ部２でディスクに記録するデータ、或いはストレージ部２によってディスクから読み出されたデータについてのバッファリングを行うキャッシュメモリである。例えばＤ−ＲＡＭ２より構成される。
キャッシュメモリへのデータの書込／読出は、システムコントローラ（ＣＰＵ）８において起動されるタスクによって制御される。
【００１８】
ＵＳＢインターフェース４は、例えばパーソナルコンピュータ１００とＵＳＢケーブルとしての伝送路１０１で接続された際の、データ伝送のための処理を行う。
入出力処理部５は、例えば記録再生装置１が単体でオーディオ機器として機能する場合に記録再生データの入出力のための処理を行う。
【００１９】
システムコントローラ８は、記録再生装置１内の全体の制御を行うと共に、接続されたパーソナルコンピュータ１００との間の通信制御を行う。
ＲＯＭ９にはシステムコントローラ８の動作プログラムや固定パラメータ等が記憶される。
ＲＡＭ１０はシステムコントローラ８によるワーク領域として用いられ、また各種必要な情報の格納領域とされる。
例えばストレージ部２によってディスクから読み出された各種管理情報や特殊情報を記憶する。例えばＰ−ＴＯＣデータ、Ｕ−ＴＯＣデータ、プレイリストデータ、ＦＡＴデータ、ユニークＩＤ、ハッシュ値等を記憶する。Ｐ−ＴＯＣデータ、Ｕ−ＴＯＣデータはミニディスクに記録されている音楽トラック等の管理情報である。また後述もするが本実施の形態の記録再生装置１が対応できるミニディスク方式に準拠した高密度ディスクは、Ｐ−ＴＯＣ、Ｕ−ＴＯＣによる管理形式のうえに、ＦＡＴファイルシステムを構築したものである。プレイリストは、高密度ディスクにおいてＡＴＲＡＣ方式などによる音楽データ等のアドレス等を管理する情報であって、ＦＡＴシステム上の１つのファイルとして記録されるものである。高密度ディスクが装填された場合には、これらＦＡＴやプレイリストの情報も読み込むことになる。ユニークＩＤ、ハッシュ値等はパーソナルコンピュータ１００等との間でのデータ伝送に際しての認証処理や暗号化／復号に用いられる情報である。
【００２０】
キャッシュ管理メモリ１１は、例えばＳ−ＲＡＭで構成され、キャッシュメモリ３の状態を管理する情報が格納される。システムコントローラ８はキャッシュ管理メモリ１１を参照しながらデータキャッシュ処理の制御を行う。キャッシュ管理メモリ１１の情報については後述する。
ＮＶ−ＲＡＭ（不揮発性ＲＡＭ）１２は、電源オフ時にも消失させないデータの格納領域として用いられる。
【００２１】
表示部６は、システムコントローラ８の制御に基づいて、ユーザーに対して提示すべき各種情報の表示を行う。例えば動作状態、モード状態、楽曲等のデータの名称情報、トラックナンバ、時間情報、その他の情報表示を行う。
操作部７には、ユーザーの操作のための各種操作子として、操作キーやジョグダイヤルなどが形成される。ユーザーは記録・再生、データ通信のための所要の動作を操作部７を操作して指示する。システムコントローラ８は操作部７によって入力された操作情報に基づいて所定の制御処理を行う。
【００２２】
パーソナルコンピュータ１００等が接続された際の、システムコントローラ８による制御は例えば次のようになる。
システムコントローラ８は、ＵＳＢインターフェース４を介して接続されたパーソナルコンピュータ１００との間で通信可能とされ、書込要求、読出要求等のコマンドの受信やステイタス情報その他の必要情報の送信などを行う。
システムコントローラ８は、例えばディスクがストレージ部２に装填されることに応じて、ディスクからの管理情報等の読出をストレージ部２に指示し、キャッシュメモリ３を介して取り込んでＲＡＭ１０に格納させる。
Ｐ−ＴＯＣ、Ｕ−ＴＯＣの管理情報を読み込ませることで、システムコントローラ８はディスクのトラック記録状態を把握できる。
またＣＡＴを読み込ませることによりデータトラック内の高密度データクラスタ構造を把握でき、パーソナルコンピュータ１００からのデータトラックに対するアクセス要求に対応できる状態となる。
またユニークＩＤやハッシュ値により、ディスク認証その他の処理を行ったり、或いはこれらの値をパーソナルコンピュータ１００に送信して処理させることができる。
【００２３】
パーソナルコンピュータ１００からの或るデータの読出要求があった場合は、システムコントローラ８はストレージ部２に、当該データの読出を実行させる。読み出されたデータは、必要に応じてＡＶ信号処理部３にて信号処理が施された上で、キャッシュメモリ３に書き込まれる。但し、既に当該要求されたデータが既にキャッシュメモリ３に格納されていた場合は、ストレージ部２による読出は必要ない。いわゆるキャッシュヒットである。
そしてシステムコントローラ８はキャッシュメモリ３に書き込まれているデータを読み出させ、ＵＳＢインターフェース４を介してパーソナルコンピュータ１００に送信させる制御を行う。
【００２４】
パーソナルコンピュータ１００からの或るデータの書込要求があった場合は、システムコントローラ８は、伝送されてくるデータをキャッシュメモリ３に格納させる。そして、キャッシュメモリ３に格納されたデータをストレージ部２によってディスクに記録させる。
なお、ディスクへのデータ記録は、クラスタという単位が最小単位で行われるものとされる。例えばクラスタは３２ＦＡＴセクターである。
もし、パーソナルコンピュータ１００等が記録要求したデータ量が数セクターなどであって１クラスタに満たない場合、ブロッキングと呼ばれる処理が行われる。即ちシステムコントローラ８は、ストレージ部２に、まず当該ＦＡＴセクターを含むクラスタの読出を実行させる。読み出されたクラスタデータはキャッシュメモリ３に書き込まれる。
そしてシステムコントローラ８は、パーソナルコンピュータ１００からのＦＡＴセクターのデータ（記録データ）をＵＳＢインターフェース４を介してキャッシュメモリ３に供給させ、格納されているクラスタデータに対して、該当するＦＡＴセクターのデータの書換を実行させる。
そしてシステムコントローラ８は、必要なＦＡＴセクターが書き換えられた状態でキャッシュメモリ３に記憶されているクラスタデータを、記録データとしてストレージ部２に転送させる。ストレージ部２では、当該クラスタ単位のデータをディスクに書き込む。
【００２５】
なお、以上は例えばパーソナルコンピュータ１００との伝送を伴うデータの記録再生のための制御であり、例えばミニディスク方式のオーディオデータなどのの記録再生時のデータ転送は、入出力処理部５を介して行われる。
入出力処理部５は、例えば入力系として、ライン入力回路／マイクロホン入力回路等のアナログ音声信号入力部、Ａ／Ｄ変換器や、デジタルオーディオデータ入力部を備える。またＡＴＲＡＣ圧縮エンコーダ／デコーダを備える。ＡＴＲＡＣ圧縮エンコーダ／デコーダは、ＡＴＲＡＣ方式によるオーディオデータの圧縮／伸長処理を実行するための回路である。なお、もちろんのこと、本実施の形態の記録再生装置としては、例えばＭＰ３などの他のフォーマットによる圧縮オーディオデータが記録再生可能な構成を採ってもよく、この場合には、これらの圧縮オーディオデータのフォーマットに対応したエンコーダ／デコーダを備えればよい。
また、本実施の形態としは、ビデオデータに関しては、特に記録再生可能なフォーマットの限定は行わないが、例えばＭＰＥＧ４などが考えられる。そして、入出力処理部５としては、このようなフォーマットに対応したエンコーダ／デコーダを備えればよいこととなる。
さらに入出力処理部５は、出力系として、デジタルオーディオデータ出力部や、Ｄ／Ａ変換器及びライン出力回路／ヘッドホン出力回路等のアナログ音声信号出力部を備える。
【００２６】
また、この場合の入出力処理部５内には、暗号処理部５ａが備えられる。暗号処理部５ａにおいては、例えばディスクに記録すべきＡＶデータについて、所定のアルゴリズムによる暗号化処理を施すようにされる。また、例えばディスクから読み出されたＡＶデータについて暗号化が施されている場合には、必要に応じて暗号解読のための復号処理を実行するようにもされている。
【００２７】
入出力処理部５を介した処理としてディスクにオーディオデータが記録されるのは、例えば入力ＴＩＮとして入出力処理部５にデジタルオーディオデータ（又はアナログ音声信号）が入力される場合である。入力されたリニアＰＣＭデジタルオーディオデータ、或いはアナログ音声信号で入力されＡ／Ｄ変換器で変換されて得られたリニアＰＣＭオーディオデータは、ＡＴＲＡＣ圧縮エンコードされてキャッシュメモリ３に蓄積される。そして所定タイミング（ＡＤＩＰクラスタ相当のデータ単位）でキャッシュメモリ３から読み出されてストレージ部２に転送される。ストレージ部２では、転送されてくる圧縮データを所定の変調方式で変調してディスクに記録する。
【００２８】
ディスクからミニディスク方式のオーディオデータが再生される場合は、ストレージ部２は再生データをＡＴＲＡＣ圧縮データ状態に復調してキャッシュメモリ３に転送する。そしてキャッシュメモリ３から読み出されて入出力処理部５に転送される。入出力処理部５は、供給されてくる圧縮オーディオデータに対してＡＴＲＡＣ圧縮デコードを行ってリニアＰＣＭオーディオデータとし、デジタルオーディオデータ出力部から出力する。或いはＤ／Ａ変換器によりアナログ音声信号としてライン出力／ヘッドホン出力を行う。
【００２９】
なお、この図１の記録再生装置１の構成は一例であり、例えば入出力処理部５は、オーディオデータだけでなく、ビデオデータに対応する入出力処理系を備えるようにしてもよい。
また、パーソナルコンピュータ１００との接続はＵＳＢでなく、ＩＥＥＥ１３９４等の他の外部インターフェイスが用いられても良い。
【００３０】
２．ディスク及びストレージ部の構成
本実施の形態の記録再生装置１で記録媒体とされるディスクは、例えばミニディスク方式のディスクである。特に従前の音楽用のミニディスクだけではなく、コンピュータユースの各種データを記録できる高密度ディスクにも対応する。
【００３１】
ここで図２（ａ）（ｂ）に、オーディオ用ミニディスク（及びＭＤ−ＤＡＴＡ）と、高密度ディスクの規格を比較して示す。
図２（ａ）に示すように、ミニディスク（及びＭＤ−ＤＡＴＡ）のフォーマットとしては、トラックピッチは１．６μｍ、ビット長は０．５９μｍ／ｂｉｔとなる。また、レーザ波長λ＝７８０ｎｍとされ、光学ヘッドの開口率ＮＡ＝０．４５とされる。
記録方式としては、グルーブ記録方式を採っている。つまり、グルーブ（ディスク盤面上の溝）をトラックとして記録再生に用いるようにしている。
アドレス方式としては、シングルスパイラルによるグルーブ（トラック）を形成したうえで、このグルーブの両側に対してアドレス情報としてのウォブルを形成したウォブルドグルーブを利用する方式を採るようにされている。
なお、本明細書では、ウォブリングにより記録される絶対アドレスをＡＤＩＰ（Ａｄｄｒｅｓｓ ｉｎ Ｐｒｅｇｒｏｏｖｅ）とも呼ぶ。
【００３２】
記録データの変調方式としてはＥＦＭ（８−１４変換）方式を採用している。また、誤り訂正方式としてはＡＣＩＲＣ（Ａｄｖａｎｃｅｄ Ｃｒｏｓｓ Ｉｎｔｅｒｌｅａｖｅ Ｒｅｅｄ−Ｓｏｌｏｍｏｎ Ｃｏｄｅ） が採用され、データインターリーブには畳み込み型を採用している。データの冗長度は４６．３％となる。
【００３３】
また、データの検出方式はビットバイビット方式である。ディスク駆動方式としてはＣＬＶ（Ｃｏｎｓｔａｎｔ Ｌｉｎｅａｒ Ｖｅｒｏｃｉｔｙ）が採用されており、ＣＬＶの線速度としては、１．２ｍ／ｓとされる。
そして、記録再生時の標準のデータレートとしては、１３３ｋＢ／ｓとされ、記録容量としては、１６４ＭＢ（ＭＤ−ＤＡＴＡでは１４０ＭＢ）となる。
またクラスタというデータ単位がデータの最小書換単位とされるが、このクラスタは、３２個のメインセクターと４個のリンクセクターによる３６セクターで構成される。
【００３４】
一方、高密度ディスクは、現状において、２つの規格が存在する。ここでは、２つの高密度ディスクの規格を、それぞれ、高密度ディスク（１）（２）として示す。
先ず、高密度ディスク（１）は、トラックピッチが１．５〜１．６μｍ、線密度０．４３７μｍ／ｂｉｔであり、記録容量としては３００ＭＢまで高くなっている。また、標準速度における転送レートは、４．３７Ｍｂｐｓ、線速度は、２．４ｍ／ｓｅｃとなっている。
また、高密度ディスク（２）は、トラックピッチが１．２５μｍ、線密度０．１６μｍ／ｂｉｔであり、記録容量は１ＧＢにまで高められている。また、標準速度における転送レートは、９．８３Ｍｂｐｓ、線速度は、１．９８ｍ／ｓｅｃとなっている。
【００３５】
なお、図２（ｂ）には示していないが、記録データの変調方式としては、高密度記録に適合するとされるＲＬＬ（１，７）ＰＰ方式（ＲＬＬ；Ｒｕｎ Ｌｅｎｇｔｈ Ｌｉｍｉｔｅｄ、ＰＰ：Ｐａｒｉｔｙ ｐｒｅｓｅｒｖｅ／Ｐｒｏｈｉｂｉｔ ｒｍｔｒ（ｒｅｐｅａｔｅｄ ｍｉｎｉｍｕｍ ｔｒａｎｓｉｔｉｏｎ ｒｕｎｌｅｎｇｔｈ））が採用され、誤り訂正方式としては、より訂正能力の高いＢＩＳ（Ｂｕｒｓｔ Ｉｎｄｉｃａｔｏｒ Ｓｕｂｃｏｄｅ）付きのＲＳ−ＬＤＣ（Ｒｅｅｄ Ｓｏｌｏｍｏｎ−Ｌｏｎｇ Ｄｉｓｔａｎｃｅ Ｃｏｄｅ）方式を用いている。データインターリーブにはブロック完結型が採用される。データの冗長度は２０．５０％とされる。
またデータの検出方式はパーシャルレスポンスＰＲ（１，２，１）ＭＬを用いたビタビ復号方式とされる。
なおＲＬＬ（１−７）変調及びＲＳ−ＬＤＣ誤り訂正方式については、例えば「特開平１１−３４６１５４号公報」や、「国際特許公開公報ＷＯ ００／０７３００」などに開示されている技術である。
またディスク駆動方式はＣＬＶ（Ｃｏｎｓｔａｎｔ Ｌｉｎｅａｒ Ｖｅｒｏｃｉｔｙ）又はＺＣＡＶ（Ｚｏｎｅ Ｃｏｎｓｔａｎｔ Ａｎｇｕｌａｒ Ｖｅｒｏｃｉｔｙ）である。
【００３６】
ディスク上のエリア構造を図３に模式的に示す。
図３に示すように、ディスクの最内周側はＰ−ＴＯＣ（プリマスタードＴＯＣ）領域とされ、ここは物理的な構造としてはプリマスタードエリアとなる。即ち、エンボスピットによる再生専用データが記録されるエリアであり、その再生専用データとして管理情報であるＰ−ＴＯＣが記録される。
【００３７】
プリマスタードエリアより外周はレコーダブルエリア（光磁気記録可能な領域）とされ、記録トラックの案内溝としてのグルーブが形成された記録再生可能領域となっている。
このレコーダブルエリアの最内周側はＵ−ＴＯＣ領域とされる。
なおＵ−ＴＯＣ領域では、プリマスタードエリアとの緩衝エリアや、レーザー光の出力パワー調整等のために用いられるパワーキャリブレーションエリアが設けられ、またＵ−ＴＯＣ領域内の特定の３クラスタの区間にＵ−ＴＯＣデータが３回繰り返し記録される。
Ｕ−ＴＯＣの内容の詳細については省略するが、プログラムエリアに記録されている各トラックのアドレス、フリーエリアのアドレス等が記録され、また各トラックに付随するトラックネーム、記録日時などの情報が記録できるようにＵ−ＴＯＣセクターが規定されている。
【００３８】
レコーダブルエリアにおいてＵ−ＴＯＣ領域より外周側にアラートトラック及びデータエリアが形成される。アラートトラックは、このディスクが高密度ディスクであって、従前のミニディスクプレーヤでは再生できないことを示す警告音が記録された警告トラックである。データエリアは、オーディオデータやコンピュータユースのデータなどの記録に用いられるエリアとなる。
即ち、通常の音楽用ミニディスクの場合であれば、データエリアに１又は複数の音楽トラックが記録される。
高密度ディスクの場合は、データエリアが各種データのストレージ領域として用いられるものとなる。
【００３９】
図４によりディスクの管理構造を説明する。
図４（ｂ）は、音楽用ミニディスクシステムでの管理構造を示している。
この場合、管理情報としては、Ｐ−ＴＯＣ、Ｕ−ＴＯＣが記録される。
Ｐ−ＴＯＣは書き換え不能な情報としてピットにより記録される。このＰ−ＴＯＣには、ディスクの基本的な管理情報として、ディスクの総容量、Ｕ−ＴＯＣ領域におけるＵ−ＴＯＣ位置、パワーキャリブレーションエリアの位置、データエリアの開始位置、データエリアの終了位置（リードアウト位置）などが記録されている。
【００４０】
一方、レコーダブルエリアに記録されるＵ−ＴＯＣは、トラック（オーディオトラック／データトラック）の記録、消去などに応じて書き換えられる管理情報であり、各トラック（トラックを構成するパーツ）について開始位置、終了位置、やモードを管理する。また、データエリアにおいて未だトラックが記録されていないフリーエリア、つまり書込可能領域としてのパーツも管理する。
例えば図示するようにデータエリア内に、ＡＴＲＡＣデータとして３曲のオーディオトラックが記録されている場合、Ｕ−ＴＯＣでは、３つのトラックをそれぞれスタートアドレス、エンドアドレス、モード情報、さらには記録日時や名称情報を管理することになる。
【００４１】
高密度ディスクの場合は図４（ａ）のようになる。
高密度ディスクの場合も、Ｕ−ＴＯＣ及びＰ−ＴＯＣは、従前のミニディスクシステムに準拠する方式で記録される。
そして図４（ａ）のデータエリアには、１つの高密度データトラックを示しているが、Ｕ−ＴＯＣでは、この高密度データトラックを１つのトラックとして管理する状態となっている。
つまりＵ−ＴＯＣからは、ディスク上における、データトラックの全体としての１又は複数のパーツ位置を管理するものとなる。なお、上述したアラートトラックの位置もＵ−ＴＯＣに管理される。
【００４２】
高密度データトラックは、ＲＳ−ＬＤＣ及びＲＬＬ（１−７）ＰＰ方式で変調された高密度データによって形成されるトラックとされる。
高密度データトラック内には、該データトラックに含まれる高密度データクラスタを管理するクラスタアトリビュートテーブル（ＣＡＴ：Ｃｌｕｓｔｅｒ Ａｔｔｒｉｂｕｔｅ Ｔａｂｌｅ）が記録される。ＣＡＴでは、データトラックを構成する高密度データクラスタのそれぞれについての属性（公開可能／不可、正常／不良等）を管理する。
【００４３】
このデータトラック内で公開不可とされる高密度データクラスタを用いて、著作権保護等のために用いられる、ディスクに固有のユニークＩＤ（ＵＩＤ）や、データ改竄チェックのためのハッシュ値（ｈａｓｈ）が記録される。もちろんこれ以外にも、各種の非公開情報が記録されても良い。
この公開不可とされる領域には、特別に許可された機器のみが限定的にアクセスすることができるものとする。
【００４４】
データトラック内で公開可能とされる高密度データクラスタによる領域（エクスポータブルエリア）は、例えばＵＳＢやＳＣＳＩなどの汎用データインターフェースを経由して、外部のコンピュータなどがアクセスし、記録領域として利用できる領域とされる。
例えばこの図４（ａ）の場合、エクスポータブルエリアには、ＦＡＴ及びＦＡＴ管理のデータファイルによる、ＦＡＴファイルシステムが構築されている状態を示している。
つまり、エクスポータブルエリアに記録されるデータは、Ｕ−ＴＯＣによっては管理されず、ＦＡＴなどの汎用的な管理情報により管理される形態となり、ミニディスクシステムに準拠しない外部のコンピュータなどによって認識可能なデータとなる。
【００４５】
ＡＴＲＡＣ方式等の音楽データ等がＦＡＴシステム上で記録される場合は、その音楽データ等のファイルを管理する管理情報としてプレイリストが記録される。このプレイリストはＦＡＴシステム上の１つのファイルとして記録されるものであり、記録再生装置１のシステムコントローラは、音楽データファイルの再生時にはプレイリストからアドレス等を把握するものとなる。
【００４６】
なお、このような構造のデータトラックが、ディスク上に複数記録される場合もある。その場合、各データトラックが、それぞれ１つのトラックとしてＵ−ＴＯＣから管理され、それぞれのデータトラック内のエクスポータブルエリア内のデータについては、ＦＡＴ等により管理される。例えば各データトラックがそれぞれ独自にＦＡＴファイルシステムを持つものとなる。あるいは、複数のデータトラックに渡って一つのＦＡＴファイルシステムが記録されるようにしてもよい。
【００４７】
また、ユニークＩＤ等の情報は、データトラック内であって、ＦＡＴ管理されないデータとする例を述べたが、ＦＡＴ管理されない情報とするなら、どのような論理形態で記録されてもよい。例えばＵ−ＴＯＣから直接的に管理されるトラックとして、非公開情報用のトラックを設けるようにしたり、あるいはＵ−ＴＯＣ／Ｐ−ＴＯＣ内に記録してもよい。更に、Ｕ−ＴＯＣ領域内で、Ｕ−ＴＯＣに使用されていない部分を用いて、非公開情報用の記録領域を設けてもよい。
【００４８】
なお、説明上、従前のミニディスクを「音楽用ミニディスク」と呼ぶが、いわゆるＭＤ−ＤＡＴＡとして知られているミニディスクも、この音楽用ミニディスクの範疇となる。
また、高密度ディスクに対してデータファイルとして音楽データが記録されることも当然にあり得る。例えばネットワークやパーソナルコンピュータからの音楽ファイルのダウンロードの場合などである。
【００４９】
図１に示したストレージ部２は、以上のような音楽用ミニディスクと汎用データ記録媒体としての高密度ディスクに対応できるディスクドライブ部とされる。
このストレージ部２の構成例を図５に示す。
【００５０】
図示するディスク９０は、上述した音楽用ミニディスク或いは高密度ディスク（１）又は高密度ディスク（２）である。
ストレージ部２においては、装填されたディスク９０をスピンドルモータ２９によってＣＬＶ方式で回転駆動させる。
このディスク９０に対しては記録／再生時に光学ヘッド１９によってレーザ光が照射される。
光学ヘッド１９は、記録時には記録トラックをキュリー温度まで加熱するための高レベルのレーザ出力を行い、また再生時には磁気カー効果により反射光からデータを検出するための比較的低レベルのレーザ出力を行う。このため、光学ヘッド１９には、ここでは詳しい図示は省略するがレーザ出力手段としてのレーザダイオード、偏光ビームスプリッタや対物レンズ等からなる光学系、及び反射光を検出するためのディテクタが搭載されている。光学ヘッド１９に備えられる対物レンズとしては、例えば２軸機構によってディスク半径方向及びディスクに接離する方向に変位可能に保持されている。
【００５１】
また、ディスク９０を挟んで光学ヘッド１９と対向する位置には磁気ヘッド１８が配置されている。磁気ヘッド１８は記録データによって変調された磁界をディスク９０に印加する動作を行う。
また、図示しないが光学ヘッド１９全体及び磁気ヘッド１８をディスク半径方向に移動させためスレッドモータ及びスレッド機構が備えられている。
【００５２】
このストレージ部２では、光学ヘッド１９、磁気ヘッド１８による記録再生ヘッド系、スピンドルモータ２９によるディスク回転駆動系のほかに、記録処理系、再生処理系、サーボ系等が設けられる。
記録処理系では、音楽用ミニディスクに対する記録時に第１の変調方式の変調（ＥＦＭ変調・ＡＣＩＲＣエンコード）を行う部位と、高密度ディスクに対する記録時に第２の変調方式（ＲＬＬ（１−７）ＰＰ変調、ＲＳ−ＬＤＣエンコード）の変調を行う部位が設けられる。
再生処理系では、音楽用ミニディスク（及び高密度ディスクのＵ−ＴＯＣ）の再生時に第１の変調方式に対する復調（ＥＦＭ復調・ＡＣＩＲＣデコード）を行う部位と、高密度ディスクの再生時に第２の変調方式に対する復調（パーシャルレスポンスＰＲ（１，２，１）及びビタビ復号を用いたデータ検出に基づくＲＬＬ（１−７）復調、ＲＳ−ＬＤＣデコード）を行う部位が設けられる。
【００５３】
光学ヘッド１９のディスク９０に対するレーザ照射によりその反射光として検出された情報（フォトディテクタによりレーザ反射光を検出して得られる光電流）は、ＲＦアンプ２１に供給される。
ＲＦアンプ２１では入力された検出情報に対して電流−電圧変換、増幅、マトリクス演算等を行い、再生情報としての再生ＲＦ信号、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥ、グルーブ情報（ディスク９０にトラックのウォブリングにより記録されているＡＤＩＰ情報）等を抽出する。
【００５４】
音楽用ミニディスク再生時には、ＲＦアンプで得られた再生ＲＦ信号は、ＥＦＭ復調部２４及びＡＣＩＲＣデコーダ２５で処理される。
即ち再生ＲＦ信号は、ＥＦＭ復調部２４で２値化されてＥＦＭ信号列とされた後、ＥＦＭ復調され、さらにＡＣＩＲＣデコーダ２５で誤り訂正及びデインターリーブ処理される。即ちこの時点でＡＴＲＡＣ圧縮データの状態となる。
そして音楽用ミニディスク再生時には、セレクタ２６はＢ接点側が選択されており、当該復調されたＡＴＲＡＣ圧縮データがディスク９０からの再生データとして出力される。この場合、図１のキャッシュメモリ３に圧縮データが供給されることになる。
【００５５】
一方、高密度ディスク再生時には、ＲＦアンプで得られた再生ＲＦ信号は、ＲＬＬ（１−７）ＰＰ復調部２２及びＲＳ−ＬＤＣデコーダ２５で処理される。
即ち再生ＲＦ信号は、ＲＬＬ（１−７）ＰＰ復調部２２において、ＰＲ（１，２，１）及びビタビ復号を用いたデータ検出によりＲＬＬ（１−７）符号列としての再生データを得、このＲＬＬ（１−７）符号列に対してＲＬＬ（１−７）復調処理が行われる。そして更にＲＳ−ＬＤＣデコーダ２３で誤り訂正及びデインターリーブ処理される。
そして高密度ディスク再生時には、セレクタ２６はＡ接点側が選択されており、当該復調されたデータがディスク９０からの再生データとして出力される。この場合、図１のキャッシュメモリ３に復調データが供給されることになる。
【００５６】
ＲＦアンプ２１から出力されるトラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥはサーボ回路２７に供給され、グルーブ情報はＡＤＩＰデコーダ３０に供給される。
【００５７】
ＡＤＩＰデコーダ３０は、グルーブ情報に対してバンドパスフィルタにより帯域制限してウォブル成分を抽出した後、ＦＭ復調、バイフェーズ復調を行ってＡＤＩＰアドレスを抽出する。
抽出された、ディスク上の絶対アドレス情報であるＡＤＩＰアドレスは図１に示したシステムコントローラ８に供給される。システムコントローラ８ではＡＤＩＰアドレスに基づいて、所要の制御処理を実行する。
またグルーブ情報はスピンドルサーボ制御のためにサーボ回路２７に供給される。
【００５８】
サーボ回路２７は、例えばグルーブ情報に対して再生クロック（デコード時のＰＬＬ系クロック）との位相誤差を積分して得られる誤差信号に基づき、ＣＬＶサーボ制御のためのスピンドルエラー信号を生成する。
またサーボ回路２７は、スピンドルエラー信号や、上記のようにＲＦアンプ２１から供給されたトラッキングエラー信号、フォーカスエラー信号、或いはシステムコントローラ８からのトラックジャンプ指令、アクセス指令等に基づいて各種サーボ制御信号（トラッキング制御信号、フォーカス制御信号、スレッド制御信号、スピンドル制御信号等）を生成し、モータドライバ２８に対して出力する。即ち上記サーボエラー信号や指令に対して位相補償処理、ゲイン処理、目標値設定処理等の必要処理を行って各種サーボ制御信号を生成する。
【００５９】
モータドライバ２８では、サーボ回路２７から供給されたサーボ制御信号に基づいて所要のサーボドライブ信号を生成する。ここでのサーボドライブ信号としては、二軸機構を駆動する二軸ドライブ信号（フォーカス方向、トラッキング方向の２種）、スレッド機構を駆動するスレッドモータ駆動信号、スピンドルモータ２９を駆動するスピンドルモータ駆動信号となる。
このようなサーボドライブ信号により、ディスク９０に対するフォーカス制御、トラッキング制御、及びスピンドルモータ２９に対するＣＬＶ制御が行われることになる。
【００６０】
ディスク９０に対して記録動作が実行される際には、キャッシュメモリ３からデータが供給される。
音楽用ミニディスク記録時には、セレクタ１６がＢ接点に接続され、従ってＡＣＩＲＣエンコーダ１４及びＥＦＭ変調部１５が機能することになる。
この場合、オーディオ処理部１０からの圧縮データはＡＣＩＲＣエンコーダ１４でインターリーブ及びエラー訂正コード付加が行われた後、ＥＦＭ変調部１５でＥＦＭ変調が行われる。
そしてＥＦＭ変調データがセレクタ１６を介して磁気ヘッドドライバ１７に供給され、磁気ヘッド１８がディスク９０に対してＥＦＭ変調データに基づいた磁界印加を行うことでデータ記録が行われる。
【００６１】
高密度ディスク記録時には、セレクタ１６がＡ接点に接続され、従ってＲＳ−ＬＤＣエンコーダ１２及びＲＬＬ（１−７）ＰＰ変調部１３が機能することになる。
この場合、メモリ転送コントローラ３からの高密度データはＲＳ−ＬＤＣエンコーダ１２でインターリーブ及びＲＳ−ＬＤＣ方式のエラー訂正コード付加が行われた後、ＲＬＬ（１−７）ＰＰ変調部１３でＲＬＬ（１−７）変調が行われる。
そしてＲＬＬ（１−７）符号列としての記録データがセレクタ１６を介して磁気ヘッドドライバ１７に供給され、磁気ヘッド１８がディスク９０に対して変調データに基づいた磁界印加を行うことでデータ記録が行われる。
【００６２】
レーザドライバ／ＡＰＣ２０は、上記のような再生時及び記録時においてレーザダイオードにレーザ発光動作を実行させるが、いわゆるＡＰＣ（Ａｕｔｏｍａｔｉｃ Ｌａｚｅｒ Ｐｏｗｅｒ Ｃｏｎｔｒｏｌ）動作も行う。
即ち、図示していないが、光学ヘッド１９内にはレーザパワーモニタ用のディテクタが設けられ、そのモニタ信号がレーザドライバ／ＡＰＣ２０にフィードバックされる。レーザドライバ／ＡＰＣ２０は、モニタ信号として得られる現在のレーザパワーを、設定されているレーザパワーと比較して、その誤差分をレーザ駆動信号に反映させることで、レーザダイオードから出力されるレーザパワーが、設定値で安定するように制御している。
なお、レーザパワーとしては、再生レーザパワー、記録レーザパワーとしての値がシステムコントローラ８によって、レーザドライバ／ＡＰＣ２０内部のレジスタにセットされる。
【００６３】
以上の各動作（アクセス、各種サーボ、データ書込、データ読出の各動作）は、システムコントローラ８からの指示に基づいて実行される。
【００６４】
３．ＡＶデータの管理
これまでの説明からも分かるように、例えば音楽用ミニディスクが原則オーディオデータのみを記録可能とされるのに対して、高密度ディスクは、汎用データが記録可能なディスクとされる。
そして、このような汎用データのなかにも、例えばオーディオデータやビデオデータなどのＡＶデータが含まれる。つまり、本実施の形態の高密度ディスクに対しても、ＡＶデータが記録可能である。特に、ＡＶデータの記録に関していえば、高密度ディスクは、音楽用ミニディスクと比較して大容量であるから、データレートの高いストリームデータである、ビデオデータの記録に適しているということがいえる。
【００６５】
そして、本実施の形態においては、高密度ディスクに記録されるＡＶデータは、図６に示すようにしてＦＡＴファイルシステム上で管理される。
先ず、ＦＡＴファイルシステムにおいては、ＡＶデータ用のディレクトリが存在するようにして管理が行われる。ここでは、ＡＶデータ用のディレクトリについては、ここでは仮に、「Ｈｉ−ＭＤＶ」というディレクトリ名としている。
そして、このディレクトリＨｉ−ＭＤＶには、図示するように、少なくとも３種類のファイルが格納されることになる。
まず、ＡＶデータの実体は、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとしてファイル単位により管理されて、このディレクトリＨｉ−ＭＤＶに格納される。そして、このディレクトリＨｉ−ＭＤＶに格納されるＡＶ Ｓｔｒｅａｍ Ｆｉｌｅごとに対応付けられるようにして、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが格納される。このＡＶ Ｈｅａｄｅｒ Ｆｉｌｅには、後述するようにして、対応付けられたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに関する所定内容の情報が格納される。また、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅと、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとの対応付けは、ここでは、各ファイルのファイル名の拡張子以外の部分を同一とすることで行うこととしている。
【００６６】
ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅは、ディレクトリＨｉ−ＭＤＶに格納されるＡＶデータを、トラック単位で管理するための管理情報が記述されたファイルである。以降の説明により理解されることであるが、本実施の形態では、ディレクトリＨｉ−ＭＤＶに格納されるＡＶデータとして、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、あくまでも、ＦＡＴファイルシステム上で管理されるファイルであり、トラックとしては扱わない。トラックは、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅによって管理される。
【００６７】
図７（ａ）にはＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの構造例が示されている。この図に示すようにして、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅは、Ｐｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅと、Ｔｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ
Ｔａｂｌｅとにより成る。
先ず、Ｔｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅは、１以上のＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒから成る。各Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒは、トラックごとに対応して設けられるもので、図示するようにして、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃１，＃２，・・・＃ｎのようにしてナンバが付されている。なお、このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバは、分割消去などによる編集結果に応じて欠落してもよいものであり、必ずしも連番となる必要はない。
【００６８】
また、Ｐｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅは、トラック単位での再生順を規定する。例えば、この場合のＰｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅには、左から順に、格納位置番号Ｐ１〜Ｐ（ｎ）により示される格納位置があるものとされ、これらの格納位置に対しては、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバが格納される。ここでは、格納位置番号Ｐ１に＃２、格納位置番号Ｐ２に＃１、・・・格納位置番号Ｐ（ｎ−１）に＃ｎが格納されていることから、トラック再生順としては、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃２が示すトラック→Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃１が示すトラック→・・・・→Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎが示すトラックの順となる。なお、この場合のＰｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅとしては、例えば格納位置番号Ｐ３が「−」と記載されており、これはＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバが格納されていないことを示す。つまり、本実施の形態としては、この図の場合であれば、再生順に従って、格納位置番号Ｐ１から左詰めとなるようにしてＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバを格納していく必要はない。再生順は、格納位置番号に従って、格納されているＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバを順次ピックアップしていくことで得られるものである。
【００６９】
１つのＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒは、図７（ｂ）に示す情報内容を有している。つまり、Ｔｒａｃｋ Ｆｉｌｅ ＩＤ，Ｐｌａｙ Ｆｒｏｍ，Ｐｌａｙ Ｔｏ，ＣＯＤＥＣ Ｉｎｆｏｒｍａｔｉｏｎを有する。
Ｔｒａｃｋ Ｆｉｌｅ ＩＤは、現Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒが示すトラックとしてのデータを含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ）のファイルＩＤを示す。このファイルＩＤは、例えばＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ）に与えられたファイル名と対応している。
Ｐｌａｙ Ｆｒｏｍは、現Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒが示すトラックについての、上記ファイルＩＤが示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいて再生が開始されるべき時間を示す。Ｐｌａｙ Ｔｏは、再生が終了すべき時間を示す。
ＣＯＤＥＣ Ｉｎｆｏｒｍａｔｉｏｎは、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコーデックの方式や、コーデック後のデータについての時間情報などに関する情報が格納される。
【００７０】
図８（ａ）は、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの構造を示している。
この図において、矢印ａで示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとしてのデータ開始位置からは、ＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ） Ｏｆｆｓｅｔとしての領域が設けられる場合がある。ＥＳ Ｏｆｆｓｅｔは、本実施の形態のＡＶ Ｓｔｒｅａｍ ＦｉｌｅがＦＡＴファイルシステムによって管理されることに応じて付加されるものである。ＦＡＴファイルシステムでは、例えばクラスタ単位によりデータの記録再生を行うという条件が存在する。矢印ｂにより示す、コンテンツデータの再生開始位置（再生時間“０”）は、記録時の書き込みや、後述するような分割、ディスク上消去などの処理によって、必ずしもセクターの先頭から開始されるとは限らない。このようにして、コンテンツデータの再生開始位置を含むクラスタにおける空き領域を埋めるために、ＥＳ Ｏｆｆｓｅｔが定義されている。
そして、このＥＳ Ｏｆｆｓｅｔに続けて、ＡＶデータとしての実体であるコンテンツデータが配置される。
【００７１】
ここで、先に図７（ｂ）に示したＰｌａｙ Ｆｒｏｍ及びＰｌａｙ Ｔｏは、例えば図８（ａ）において、矢印ｃ，ｄで示すように、そのトラックの開始位置及び終了位置となるコンテンツデータの再生時間を示す。
つまり、本実施の形態でいうトラックは、コンテンツデータ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の一部データにより形成することができるようになっている。もちろんのこと、Ｐｌａｙ Ｆｒｏｍがコンテンツデータの再生時間“０”を示し、Ｐｌａｙ Ｔｏがコンテンツデータにおいて、図８（ａ）に矢印ｅで示す終端位置の時間を示すのであれば、トラックとしては、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの全部分のコンテンツデータとされることになる。
【００７２】
図８（ｂ）は、１つのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが有する情報内容例を示している。
先ず、ＥＳ Ｏｆｆｓｅｔ Ｓｉｚｅは、現ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが対応するＡＶ Ｓｔｒｅａｍ ＦｉｌｅのＥＳ Ｏｆｆｓｅｔについてのデータサイズを示す。
また、本実施の形態の場合、詳しいことは後述するが、例えばＡＶデータに対する分割編集処理などによって、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいて複数のトラックが存在するようにして管理される場合が生じる。この場合、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対して、複数の参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒが存在することになる。つまり、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応して参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ数は、変わり得るものとなる。
Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒは、この参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒの数を示す。例えばＲｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒの示す値が“２”であれば、このＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒの数は２であることになる。そしてこれは、そのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいて２つのトラックとしてのデータ部分が存在していることを示している。
【００７３】
Ｅｒａｓｅ Ｆｌａｇは、そのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、「トラック消去」によって消去されたトラックが存在する場合に立つフラグが格納される。詳細については後述するが、「トラック消去」は、編集処理として、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ上での書き換えによりトラック消去を行う処理であり、逆にいえば、ＦＡＴファイルシステムの書き換えは行わない。つまり、ＡＶ Ｔｒａｃｋ ＩｎｄｅｘＦｉｌｅ上で消去されたとみなされるものであって、ＦＡＴファイルシステム上では、このトラック消去されたデータ部分を含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅそのものがディスクに記録されているものとして管理されている。
【００７４】
Ｔｏｔａｌ Ｐｌａｙ Ｔｉｍｅは、そのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの総再生時間を示す。つまり、図８（ａ）において矢印ｅにより示す終端の再生時間を示す。
なお、このような構造及び情報内容を有するＡＶ Ｈｅａｄｅｒ Ｆｉｌｅであれば、上記した情報内容は、それぞれ所定のバイト数を割り当てるようにして固定長とすることが可能である。つまり、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅとしても固定長とすることができる。ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが固定長であれば、例えば既にディスクに記録済みとされているＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを更新する場合においてもそのサイズは変化しないから、例えば、１つのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを形成する複数のデータ部分が、ディスク上において物理的に離散して記録されるようなことにはならない。これによっては、ＦＡＴによるＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの管理が、より単純なものになって、読み出し、アクセスなどが容易になるというメリットが得られる。このようにして、本実施の形態では、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについて固定長とすることによっても、ＦＡＴファイルシステムに対する処理負担を軽減している。
【００７５】
続いて、これまでの説明を踏まえて、図９を参照して、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対するトラック管理例について説明する。この図９に示すトラック管理は、最も単純な例であり、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅが１つのトラックとして管理される場合を示している。例えば、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅをディスクに記録する場合において、特に、その途中でトラック分割などのマーキング操作を行わなければ、このようなＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとトラックの関係が得られる。
【００７６】
先ず、図９（ｂ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、ここでは、ＭＰ０００００７．ＶＳＦというファイル名及び拡張子であるとする。つまり、拡張子ＶＳＦにより、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅであることが示された上で、このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、ＭＰ０００００７というファイル名によって特定されることになる。
そして、このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、データ開始位置から１ＫバイトのＥＳ Ｏｆｆｓｅｔの領域を有するものとされ、これに続けて総再生時間“１００”のコンテンツデータが配置されてディスクに記録されていることとする。
【００７７】
このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応付けられたＡＶ Ｈｅａｄｅｒ Ｆｉｌｅは、図９（ｃ）に示される。このＡＶ Ｈｅａｄｅｒ Ｆｉｌｅは、ＭＰ０００００７．ＶＨＦというファイル名及び拡張子を有している。拡張子ＶＨＦにより、このファイルはＡＶ Ｈｅａｄｅｒ Ｆｉｌｅであることが示され、さらに、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおいて、ＭＰ０００００７というファイル名によって特定がされることになる。
そして、図９（ｂ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅと、図９（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅは、拡張子以外のファイル名部分である「ＭＰ０００００７」が同一であり、これによって、両者の対応付けが行われているものである。
なお、確認のために述べておくと、ＡＶ Ｓｔｒｅａｍ ＦｉｌｅとＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのファイル名（＋拡張子）は、ＦＡＴファイルシステムによる管理の下で与えられるものである。
【００７８】
そして、図９（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおいて、ＥＳ Ｏｆｆｓｅｔ Ｓｉｚｅは、図９（ｂ）のＡＶ Ｓｔｒｅａｍ ＦｉｌｅのＥＳ Ｏｆｆｓｅｔが１Ｋバイトであることに対応して、この１Ｋバイトを示す１０００が格納される。
また、Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒは、１とされており、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒは１つであることが示される。
また、Ｅｒａｓｅ Ｆｌａｇは、０となっており、これは、図９（ｂ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（コンテンツデータ）について、「トラック消去」によって消去されたトラックは存在していないことを示している。
また、Ｔｏｔａｌ Ｐｌａｙ Ｔｉｍｅは、図９（ｂ）に示すコンテンツデータの終端の再生時間が“１００”であることに対応して、１００が格納されている。
【００７９】
そして、図９（ａ）に示すＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ内のＴｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅにおいて、図９（ｂ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応して参照すべき１つのＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎが示されている。
このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎのＴｒａｃｋ Ｆｉｌｅ ＩＤは、図では７が記載されているが、これは、図９（ｂ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅと、図９（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅで共通となっているファイル名「ＭＰ０００００７」における「０００００７」を示している。つまり、この場合のＴｒａｃｋ Ｆｉｌｅ ＩＤとしては、ファイル名としてＡＶ Ｓｔｒｅａｍ ＦｉｌｅとＡＶ Ｈｅａｄｅｒ Ｆｉｌｅに対して共通に与えられた数値を示すこととしており、これによって、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ、及びＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒとの対応関係を特定する仕組みとしている。
【００８０】
また、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎのＰｌａｙ Ｆｒｏｍは、コンテンツデータの再生時間“０”を示す、０が格納される。また、Ｐｌａｙ Ｔｏは、コンテンツデータの終端の再生時間“１００”に対応する１００が格納される。このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎのＰｌａｙ Ｆｒｏｍ、Ｐｌａｙ Ｔｏを参照するによっては、図９（ｂ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータは、その開始位置（再生時間“０”）から終了位置（再生時間“１００”）まで、１つのトラックとして再生されるべきであることが分かる。
【００８１】
また、ここでのＣＯＤＥＣ Ｉｎｆｏｒｍａｔｉｏｎは、ｔｙｐｅＸであることとして、実際には、所要のコーデックに関する情報を格納しているものとされる。
【００８２】
続いては、図１０のフローチャートを参照して、ｎ番目に再生すべきトラックを再生するための処理動作について説明する。なお、この図に示す処理は、本実施の形態の記録再生装置１のシステムコントローラ８が実行する。
先ず、システムコントローラ８は、ステップＳ１０１により、トラック再生指示が得られるのを待機している。そして、例えばユーザの操作部７に対する操作などによって、ｎ番目に再生すべきトラックの指定と共に、再生開始の指示が行われ、これに応じたコマンドが発生したとされるとステップＳ１０２以降の処理に進むことになる。
【００８３】
ステップＳ１０２では、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの読み込みを実行する。なお、この読み込みは、ディスクから読み出しを行うようにしてもよいが、ＲＡＭ１０から読み込むようにすればよい。つまり、ディスク装填時において、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅをディスクから読み出してＲＡＭ１０に保持させておくようにして、以降は、このＲＡＭ１０にアクセスして、必要に応じてＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの読み込みを行うようにするものである。このようにすれば、逐一ディスクにアクセスする必要が無くなって、それだけ短時間で処理を実行することができる。
【００８４】
次のステップＳ１０３では、読み込みを行ったＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ ＦｉｌｅにおけるＰｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅを参照して、再生順がｎ番目となっているＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒのナンバを特定する。このためには、例えばＰｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅの格納位置Ｐ１から順次スキャンしていき、ｎ番目にヒットしたＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバを参照すればよい。
【００８５】
そして、次のステップＳ１０４では、先ず、上記ステップＳ１０３により特定されたナンバのＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒに格納されているＴｒａｃｋ Ｆｉｌｅ ＩＤを認識する。そして、この認識したＴｒａｃｋ Ｆｉｌｅ ＩＤに対応するファイル名が与えられているＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ及びＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを特定する。
【００８６】
ステップＳ１０５においては、上記ステップＳ１０４にて特定したＡＶ Ｈｅａｄｅｒ Ｆｉｌｅに格納されているＥＳ Ｏｆｆｓｅｔ Ｓｉｚｅを参照することで、同じく上記ステップＳ１０４にて特定したＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの再生開始位置を特定する。つまり、コンテンツデータの開始位置である再生時間“０”の位置を特定するものである。
【００８７】
続くステップＳ１０６においては、先のステップＳ１０４にて特定したＡＶ Ｈｅａｄｅｒ Ｆｉｌｅに格納されているＰｌａｙ Ｆｒｏｍの値を認識する。そして、上記ステップＳ１０５にて特定したコンテンツデータの再生時間“０”の位置を基点として、Ｐｌａｙ Ｆｒｏｍの時間分シフトした再生時間位置にアクセスする。そして、このアクセスした再生時間位置から、コンテンツデータの再生を開始する。
【００８８】
そして、ステップＳ１０７においては、先のステップＳ１０４にて特定したＡＶＨｅａｄｅｒ Ｆｉｌｅに格納されているＰｌａｙ Ｔｏの値を認識した上で、このコンテンツデータの再生時間“０”の位置を基点として、Ｐｌａｙ Ｔｏの時間分シフトした再生時間位置を認識する。そして、このＰｌａｙ Ｔｏの時間が示すとされる再生時間位置までの再生が終了するのを待機する。
そして、Ｐｌａｙ Ｔｏの時間が示すとされる再生時間位置までの再生が終了したとされると、ｎ番目のトラックを完全に再生終了したこととなって、例えばステップＳ１０８により再生終了処理を実行する。
このようにして、本実施の形態では、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容を参照することで、トラック単位によるデータ管理、及び再生制御が可能であることが分かる。これは即ち、トラック単位によるデータ管理、及び再生制御を実行するのにあたり、ＦＡＴファイルシステムのレベルでの管理情報内容を使用するのではなく、このＦＡＴファイルシステムにより管理されるインデックス情報ファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ）及びヘッダファイル（ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ）などを使用する構成となっていることを意味する。
【００８９】
４．トラック分割、消去編集
上記したトラック管理の下では、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容を変更することによって、トラック単位での編集を行うことが可能とされる。ここでは、このような編集処理として、トラックの分割編集、及びトラック消去編集について説明する。
【００９０】
先ず、トラック分割編集について説明する。
ここで、トラック分割編集前のトラックの管理状態としては、先に図９に示したとおりであるとする。つまり、図９（ｂ）に示すファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、１つのトラックとして管理されている状態である。以降においては、この図９（ｂ）に示されるファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、トラック分割、及びトラック消去の各編集を行う場合について説明する。
【００９１】
そして、上記図９（ｂ）に示すようにして１トラックとして管理されるＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、図１０（ｂ）に示すようにしてトラック分割を行ったとする。つまり、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータにおいて、再生時間“０”〜“８０”までのデータ部分から成るトラックと、再生時間“８０”〜“１００”までのデータ部分から成るトラックとに分割したものとする。なお、ここでは、前者をトラック＃ｎ、後者をトラック＃ｍということにする。
【００９２】
そして、上記のようにして分割編集されたものとして管理が行われるようにするためには、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ ＦｉｌｅとＡＶ Ｈｅａｄｅｒ Ｆｉｌｅとについて、それぞれ、図９（ａ）（ｃ）から図１１（ａ）（ｃ）に示すようにして内容を変更することになる。
先ず、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについては、図１１（ｃ）に示すようにして、Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒの値について１から２となるように変更され、これにより、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒが２つ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅが含むトラックが２つ）であることを示すようにされる。なお、ここまでの段階でのファイル名＝ＭＰ０００００７．ＶＳＦのＡＶＳｔｒｅａｍ Ｆｉｌｅについて、ＥＳ Ｏｆｆｓｅｔのサイズ及びコンテンツの終端の再生時間が“１００”であることに変わりはないから、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにおけるＥＳ Ｏｆｆｓｅｔ Ｓｉｚｅ及びＴｏｔａｌ Ｐｌａｙ Ｔｉｍｅの値は変化しない。さらに、Ｅｒａｓｅ Ｆｌａｇについても、ここまでの段階では、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータにおいて、消去されたトラックは存在しないから、０のまま変わらない。
【００９３】
そして、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅにおいて、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ及びＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのファイル名に対応する、Ｔｒａｃｋ Ｆｉｌｅ ＩＤを有するＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒを参照すると、例えば図１１（ａ）に示すようにして、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎ，＃ｍの２つが存在していることになる。このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒの数は、図１１（ｃ）に示したＲｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒの値である２と一致している。つまり、トラック分割によってトラックが１つ増えるのに対応して、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎに、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍが追加されているものである。
【００９４】
Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎは、コンテンツデータにおける再生時間“０”〜“８０”までのデータ部分によるＴｒａｃｋ ＃ｎについて定義しているものとなる。そして、この場合においては、図９（ａ）に示したＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎについて、下記のようにして必要な情報を書き換えることで得られたものとされる。
先ず、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎにおけるＴｒａｃｋ Ｆｉｌｅ ＩＤは、図９（ａ）と同様に、７を示している。これにより、このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎが、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ内のトラックについて記述したものであることが特定される。
そして、Ｐｌａｙ Ｆｒｏｍ及びＰｌａｙ Ｔｏは、それぞれ０、８０を示すことで、図１１１１に示すトラック＃ｎとしてのデータ部分の再生開始時間が“０”、再生終了時間が“８０”であることを示すようにされる。従って、ここではＰｌａｙ Ｔｏの値が書き換えられていることになる。
なお、ＣＯＤＥＣ Ｉｎｆｏｒｍａｔｉｏｎは、ＴｙｐｅＸを示すという点では同じである。ただし、例えば再生時間に関する情報などは、必要に応じて、そのトラックごとに対応した内容に変更される場合がある。
【００９５】
また、分割編集に応じて新たに生成されたＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍは、コンテンツデータにおける再生時間“８０”〜“１００”までのデータ部分によるＴｒａｃｋ＃ｍについて定義する。
Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎにおけるＴｒａｃｋ Ｆｉｌｅ ＩＤも７を示すことになる。つまり、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍも、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ内のトラックについて記述したものであることが特定される。
また、Ｐｌａｙ Ｆｒｏｍ及びＰｌａｙ Ｔｏは、それぞれ８０、１００を示し、Ｔｒａｃｋ ＃ｍについての、コンテンツデータの再生開始位置（再生時間“０”）を基点とした、再生開始時間と再生終了時間を示すようにされる。
このように、図１１（ａ）（ｃ）に示すＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容とすることによって、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅが図１１（ｂ）に示すようにしてトラック分割されるように管理する。
【００９６】
続いては、図１２（ｂ）に示すようにして、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、トラック＃ｎを消去する編集を行って、結果的にトラック＃ｍを残すという場合を考えてみる。
なお、確認のために述べておくと、ここでの消去は、あくまでも、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによってトラックを消去したものとして管理するものであって、ＦＡＴファイルシステムによって、ディスクに実際に記録されているデータ部分を消去するものではない。つまり、ユーザインターフェイス上は、消去したものとしてみえるが、ＦＡＴファイルシステム上で消去したとして管理していない以上、ディスクから消去されてはいないものである。
本明細書では、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによって管理される消去を「トラック消去」といい、ＦＡＴファイルシステム上で管理される消去については、「ディスク上消去」ということにしている。
【００９７】
そして、図１２（ｂ）に示すようにしてトラック消去されたものとして管理されるためには、先ず、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ ＦｉｌｅにおけるＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒとしては、図１２（ａ）に示すようになる。
つまり、トラック＃ｎを消去することに応じて、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶＳｔｒｅａｍ Ｆｉｌｅに対応するＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒのうち、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎは削除され、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍのみが存在することとなる。このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍの内容については、図１１（ａ）におけるＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍと同様である。
【００９８】
また、このトラック消去編集に応じて、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容は、図１１（ｃ）から図１２（ｃ）に示すようにして更新される。つまり、Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒは２から１となって、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒの数（ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ内のトラック数）が１になったことを示すようにされる。
そして、この段階では、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、トラック消去されたトラックが存在していることになるから、Ｅｒａｓｅ Ｆｌａｇが立つこととなって、その値は０から１に書き換えられることになる。
【００９９】
ところで、上記図９、及び図１１、図１２により説明したようにして、本実施の形態ではトラック分割、トラック消去の編集が可能とされるが、このような編集処理にあってはいわゆるアンドゥといわれる、編集前の状態に戻すことが可能なように構成されることが、例えばユーザにとっての利便性などを考慮すると好ましい。
本実施の形態において、トラック分割、及びトラック消去についてのアンドゥは可能であり、例えば次のようにして実行させることができる。
【０１００】
先ず、トラック分割のアンドゥについて、再度図９及び図１１を例に説明する。
先ず、アンドゥを可能とすることを前提とした場合には、編集対象となっているＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応するＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容について、編集処理前の内容を、例えばＲＡＭ１０上の所定の待避領域に待避させるようにして保持しておくようにされる。
従って、図９から図１１に示すようにしてトラック分割のための編集を行ったとした場合においては、図９（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎと、図９（ｃ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容を、上記待避領域に保持しておくことになる。
【０１０１】
そして、このトラック分割のアンドゥを実行するとした場合には、先ず、図１１（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎ，＃ｍの２つのＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒを、ＡＶ ＴｒａｃｋＩｎｄｅｘ Ｆｉｌｅから削除し、かわりに、待避領域に保持させておいた図９（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎを、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅに格納する。
また、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについても、図１１（ｃ）に示す内容から、待避領域に保持させておいた、図９（ｃ）に示す内容に書き換えを行うようにされる。
このような処理を実行することで、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅは、図１１（ａ）（ｃ）から図９（ａ）（ｃ）に示す内容に変更されることとなり、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータは、１つのトラックとして管理されることになる。つまり、トラック分割編集についてのアンドゥが行われたことになる。
なお、上記したトラック分割編集のアンドゥに際して、図１１（ａ）（ｃ）に示す内容のＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを待避領域に保持させておくようにすれば、さらに、図９に示す管理状態から、図１１に示されるトラック分割後の管理状態にアンドゥさせることが可能である。
【０１０２】
また、図１２に示すトラック消去が行われた状態から、図１１に示す状態となるようにアンドゥを実行する場合も、上記と同様にすればよい。
つまり、先ずは、図１１に示す管理状態から図１２に示す管理状態となるようにしてトラック消去を実行した際において、図１１（ａ）（ｃ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎ，＃ｍ、及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを、待避領域に保持させる。
そして、アンドゥを実行する際には、図１２（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍをＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅから削除し、かわりに、待避領域に保持させておいた図１１（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎ，＃ｍを、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅに格納する。
また、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについて、図１２（ｃ）に示す内容から、待避領域に保持させておいた、図１１（ｃ）に示す内容に書き換えを行うようにされる。
この結果、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによる、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの管理は、図１２（ａ）（ｃ）から図１１（ａ）（ｃ）に示す内容に変更され、トラック削除編集についてのアンドゥが行われたことになる。
【０１０３】
５．ディスク上消去
続いては、ファイルシステム上で、トラックに相当するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分を削除する、ディスク上消去の処理について説明を行うこととする。
本実施の形態では、これまでの説明から分かるように、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（コンテンツデータ）は、ＦＡＴファイルシステムによる管理と、このＦＡＴファイルシステム下での、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ（インデックス情報）による管理とが行われる。ここで、着目すべきことは、ディスクに記録されるデータについて、ＦＡＴファイルシステムによるデータ管理単位のサイズと、コンテンツデータとして管理する場合のデータ管理単位のサイズには、相違を有することである。先ず、この点について図１３１３を参照して説明しておく。
【０１０４】
図１３は、ある１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツデータのデータ管理単位と、ファイルシステムのデータ管理単位との関係を概念的に示している。
先ず、図１３（ａ）に示すように、コンテンツデータとして、領域Ａによる１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅがあるとして、このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対するコンテンツのデータ管理単位は、図１３（ｂ）に示すようにして、Ａ〜Ｊの１０のデータ管理単位により等分割することとする。
これに対して、ＦＡＴファイルシステムのデータ管理単位は、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを、Ａ〜Ｄの４等分に分割しているものとする。
なお、図１３（ｂ）に示すコンテンツのデータ管理単位は、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの仕様によって決定されるインデックス単位となる。また、図１３（ｃ）に示すＦＡＴファイルシステムのデータ管理単位は、例えばクラスタ単位となる。
【０１０５】
そして、上記のように説明した図１３は、次のようなことを意味する。
先ず、図１３（ａ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（Ａ）としてのコンテンツデータについて、トラック分割、トラック消去を行う場合には、図１３（ｂ）に示すコンテンツのデータ管理単位Ａ〜Ｊにおける境界位置のいずれかを分割位置、消去位置とすることになる。
これに対して、例えばＦＡＴファイルシステム上での管理により、ディスク上消去を行おうとした場合には、図１３（ｃ）に示すファイルシステムのデータ管理単位Ａ〜Ｄにおける境界位置の何れかを、消去されるデータ部分の境界位置とすることになる。
そして、図１３（ｂ）（ｃ）を比較すれば、コンテンツのデータ管理単位の境界位置と、ファイルシステムのデータ管理単位との境界位置とは必ずしも一致していないことがわかる。
例えばこの図では、説明の便宜上、ファイルシステムのデータ管理単位のサイズを、コンテンツのデータ管理単位のサイズの２．５倍としているのであるが、この場合には、ファイルシステムのデータ管理単位Ｂ，Ｃの境界は、コンテンツのデータ管理単位Ｅ，Ｆの境界と一致はしているものの、ファイルシステムのデータ管理単位Ａ，Ｂ、及びＣ，Ｄの境界は、コンテンツのデータ管理単位Ｃ，Ｈ内に含まれるような状態で、ずれが生じている。また、コンテンツのデータ管理単位Ｂ，Ｄ，Ｇ，Ｉなどは、ファイルシステムのデータ管理単位のブロック内に収まっている。
【０１０６】
そして、上記図１３に示す状態から、領域ＡのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、図１４（ａ）に示すようにして領域Ａ−１，Ａ−２の各データ部分に分割することで、トラック＃ｎ，＃ｍの２つのトラックとなるようにトラック分割編集を行ったとする。この場合には、図１４（ｂ）におけるコンテンツのデータ管理単位Ｇ，Ｈの境界位置によりトラック分割編集を行っている。
なお、確認のために述べておくと、図１４（ｂ）（ｃ）には、図１３（ｂ）（ｃ）と同一のパターンが示されている。
【０１０７】
そして、上記図１４に示すようにして分割編集を行った後において、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（Ａ）から、領域Ａ−１に対応するトラック＃ｍについてディスク上消去を行うとした場合を、図１５により説明する。
ここで仮に、トラック＃ｍをディスク上消去するために、図１５（ａ）に示される、全体領域ＡとされるＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおける領域Ａ−１を完全に、ＦＡＴの書き換えにより消去することを考えてみる。すると、領域Ａ−１，Ａ−２の境界は、図１５（ｃ）に示すファイルシステムデータ管理の境界とは一致しておらず、ファイルシステムデータ管理Ｃのブロック内に在る。
従って、領域Ａ−１を完全にディスク上消去しようとすれば、ファイルシステム管理単位Ａ，Ｂ，Ｃの連続した３ブロック分に対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分を消去することになる。しかしながら、コンテンツのデータ管理単位Ｃのブロックは、図１５（ｂ）に示すコンテンツのデータ管理単位Ｈの前半を含んでいる。つまり、図１５（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａ−２における、コンテンツのデータ管理単位Ｈの前半のデータ部分もディスク上消去されてしまうことになる。
【０１０８】
このため、トラック＃ｍに相当するデータ部分をディスク上消去しようとする場合には、領域Ａ−２の冒頭部分の消去を避けるために、ファイルシステム管理単位Ａ，Ｂの連続した２ブロック分に対応したＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分をを消去することになる。
これにより、図１３（ａ）において領域Ａ−３が、ＦＡＴの書き換えによってディスクから消去されることになる。しかし、領域Ａ−１において、領域Ａ−３に続く領域Ａ−４としてのデータ部分が残ってしまうことになる。この領域Ａ−４は、図１５から分かるように、ファイルシステム管理単位Ｃの先頭位置から開始され、コンテンツのデータ管理単位Ｇ，Ｈの境界位置で終了するデータ部分となる。
【０１０９】
このようにして、コンテンツのデータ管理単位によりトラック分割（或いはトラック消去）されたトラックについてディスク上消去を行う場合には、そのトラックとしてのデータ部分の終端部分で、実際には、ディスク上において消去されずに残ることがある。
このような場合には、実際にディスク上で消去されたとされるデータサイズと、ユーザ側からディスク上で消去したように見えるデータサイズの間に、領域Ａ−４分の差分が生じる。そして、このような差分となるデータ部分は、ディスク上消去が実行される回数に応じて増加することにもなるので、実際にディスク上で消去されたデータサイズと、ユーザ側からディスク上で消去したように見えるデータサイズの誤差は拡大していくことになってしまう。
そこで、このような不都合を回避するために、本実施の形態では、図１５（ａ）に示すように、この領域Ａ−４を、後に続く領域Ａ−２の先頭に付加されるＥＳＯｆｆｓｅｔとして扱うようにされる。従って、この図１５に示すディスク上消去の結果、図１５（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとして、ディスクに記録されているものとしてＦＡＴファイルシステム上で管理されるのは、領域Ａ−４（ＥＳ Ｏｆｆｓｅｔ）＋領域Ａ−２で表される領域となる。
【０１１０】
これまでの説明によると、本実施の形態では、前提として、ディスクに記録されるデータは、ＦＡＴファイルシステムによって管理される。そのうえで、コンテンツデータ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）のトラック分割、トラック消去編集はＦＡＴの書き換えに依存することなく、このＦＡＴにより管理されるデータファイル（ＡＶＴｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）の内容を書き換えることで以て行うことが可能となっている。
例えば、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）の書き換えによるトラック分割、トラック消去編集を行わず、ＦＡＴの書き換えのみに依存して、コンテンツデータ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の編集を行うこととした場合には、トラック分割、トラック消去編集の都度、ＦＡＴの書き換えが行われることになる。ＦＡＴの書き換えは、例えば、データファイルを操作する場合よりも重い処理となることから、それだけシステムの負担が大きくなる。このため、例えば編集処理の終了（ＦＡＴの書き換えの完了）に時間がかかることになってしまうという不都合が生じる。
これに対して本実施の形態のようにして、データファイルに対する書き換えによって編集が行えるようにすれば、編集の都度、ＦＡＴを書き換える必要はなくなるので、より軽い負担で編集処理を実行することができ、より迅速な編集処理動作を得ることが可能となる。
【０１１１】
ここで、上記したように、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ ＨｅａｄｅｒＦｉｌｅ等）の書き換えによるトラック分割、トラック消去が行われる環境の下で、例えばトラックとしてのデータ部分をディスク上消去（ＦＡＴの書き換え）によって消去することには次のような意味がある。
先ず、ＦＡＴの書き換えによりデータを積極的に消去する場合とは、不要なデータをユーザが任意に削除する場合であるということになるが、これは即ち、必要なデータのみがディスクに記録されるようにして、できるだけディスクの記録容量が節約できるようにすることを目的としている、ということがいえる。これは、本実施の形態に限ることなく、他の書き換え可能なメディアを使用する場合にもいえることである。
そして、本実施の形態においては、上記した記録容量の節約とも関わるものの、次のような意味合いも有している。
つまり、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）の書き換えによるトラック消去を行っただけでは、ＦＡＴ上では、トラック消去されたデータ部分はディスクに記録されているものとして管理されるから、トラック消去が行われれば、ユーザから見たコンテンツの総データサイズよりも実際にディスクに消去されずに記録されているコンテンツの総データサイズのほうが大きくなるようにして差が生じることになる。
【０１１２】
そして、トラック消去について回数を重ねていくと、ユーザから見た、データファイルにより管理される全トラックの総データサイズ（総再生時間）と、実際にディスクに消去されずに記録されている全コンテンツ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の総データサイズとの差は拡大していくことになる。このような差分の拡大が大きくなるのは、例えばユーザが思っている以上にディスクの記録済み容量が大きくなっており、あるときに、記録できると思ったコンテンツが容量不足で記録できなくなるなど、ユーザにとって好ましくない不都合を生じる原因となる。
そこで、例えばトラック消去により消去されたトラックをディスク上消去するようにすれば、上記したようなユーザ側とＦＡＴ管理上との間でのデータサイズの差分の問題を解消できることになる。
【０１１３】
このことから、例えば実際の記録再生装置のアプリケーションとしては、次のような自動のディスク上消去動作を考えることができる。
つまり、データファイルの書き換えによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックの総データサイズが一定以上となった場合、これは、データファイルによって管理される全トラックの総データサイズと、実際にディスクに消去されずに記録されている全コンテンツ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の総データサイズとの差が一定以上となったということになる。
そして、このような条件を満たした場合には、トラック消去されたデータ部分を対象として、必要とされるデータサイズ分のディスク上消去を実行するようにされる。
【０１１４】
図１６及び図１７のフローチャートは、上記のような自動のディスク上消去動作のための処理動作を示している。なお、この図に示す処理も、記録再生装置１のシステムコントローラ８が実行する。
【０１１５】
先ず、システムとしては、一定期間ごとに、データサイズチェックを行うこととしている。ここでいうデータサイズチェックとは、上記もしているように、データファイルによって管理される全トラックの総データサイズと、実際にディスクに消去されずに記録されている全コンテンツ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の総データサイズとの差をチェックするものとされる。
そして、システムにおいては一定時間間隔ごとに上記データサイズチェックのためのコマンドを内部で発生させることとしている。そして、システムコントローラ８は、図１６のステップＳ２０１の処理として、このデータサイズチェックのためのコマンドが得られるのを待機している。そして、このコマンドが取得されるとステップＳ２０２以降の処理に進む。
【０１１６】
ステップＳ２０２においては、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ内のＴｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅを読み込む。そして、読み込んだＴｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ内に格納されている各Ｔｒａｃｋ ＤｅｓｃｒｉｐｔｏｒのＰｌａｙ Ｆｒｏｍ−Ｐｌａｙ Ｔｏにより示される時間幅を認識し、これらのＰｌａｙ Ｆｒｏｍ−Ｐｌａｙ Ｔｏの時間幅を加算する。これにより、現在、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ，ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ）により管理される全トラックの再生時間を総計した総再生時間ａの値が算出される。
そして、例えば次のステップＳ２０３により、所定の演算規則に従って、上記総再生時間ａの値を、ディスク上に記録されているデータサイズｂの値に変換する。
【０１１７】
続いては、ステップＳ２０４により、ＦＡＴの読み込みを実行する。そして、次のステップＳ２０５において、読み込みを行ったＦＡＴを参照することで、ＦＡＴによりディスク上に記録されているものとして管理されている全てのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの総データサイズｃを算出する。
【０１１８】
そして、次のステップＳ２０６においては、上記ステップＳ２０３により得られた値ｂと、上記ステップＳ２０５により得られた値ｃとについて、ｃ−ｂが予め設定された一定値以上であるか否かについて判別する。
ここで、肯定結果が得られたのであれば、データファイルの書き換えによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックの総データサイズが一定以上となっているということになる。そこで、この場合には、ステップＳ２０７によるディスク上消去処理を実行する。このディスク上消去処理によっては、データファイルの書き換えによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分について、必要なデータサイズ分に応じた消去をトラック単位で実行することになる。
これに対して、ステップＳ２０６において否定結果が得られた場合には、このまま処理を終了し、再度、ステップＳ２０１の処理により次のデータサイズチェックコマンドが得られるのを待機することになる。
【０１１９】
そして、ステップＳ２０７におけるディスク上消去の処理は、例えば図１７に示す手順によって実行することができる。
図１７に示すディスク上消去処理としては、先ず、ステップＳ３０１において、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの読み込みを行い、読み込みを行ったＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのうちから、Ｅｒａｓｅ Ｆｌａｇ＝１となっているＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを検索する。
ここで、Ｅｒａｓｅ Ｆｌａｇ＝１となっているＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを検索するということは、そのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのファイル名を特定することになる。これは、データファイルによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分を含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを特定することを意味する。
【０１２０】
つまり、本実施の形態では、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにＥｒａｓｅ Ｆｌａｇを格納することで、データファイルによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分を含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅと、これを含まないＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとを区別して認識することが可能となるものである。
仮に、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにはＥｒａｓｅ Ｆｌａｇを格納しないこととすれば、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいて、データファイルによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分が存在するか否かについては、判断することができなくなる。つまり、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅから、データファイルによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分のみをディスク上消去しようとした場合にも、このようなデータ部分がＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに存在するかどうかを判断することができない以上、適正に実行することはできないことになる。
ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにはＥｒａｓｅ Ｆｌａｇを格納しない場合には、例えばＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを形成する全てのトラックについて、データファイルによるトラック消去が行われて、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅのＲｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒが０となったときにはじめて、そのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ全体をディスク消去することが可能となる。
【０１２１】
そして、次のステップＳ３０２においては、先ず、Ｔｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの読み込みを実行し、このＴｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅに格納されるＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒのうちから、上記ステップＳ３０１において検索したＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのファイル名に対応するＴｒａｃｋ Ｆｉｌｅ ＩＤを格納したＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒを認識する。
【０１２２】
次のステップＳ３０３においては、上記ステップＳ３０２により認識したＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒと、先にステップＳ３０１により読み込みを行ったＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容に基づいて、各ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおけるトラック消去済みとされているデータ部分の再生時間幅を認識する。
このステップＳ３０３による再生時間幅認識のための処理を、図１８の模式図により説明する。
【０１２３】
ここで、トラック消去済みの（かつ、ディスク上消去（ＦＡＴ書き換え）による消去はされていない）データ部分を含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとして、図１８（ａ）（ｂ）（ｃ）に示す３つが存在しているとする。
ここでは仮に、図１８（ａ）（ｂ）（ｃ）に示す各ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応するＴｒａｃｋ Ｆｉｌｅ ＩＤは、それぞれ、Ｔｒａｃｋ Ｆｉｌｅ ＩＤ＝０，Ｔｒａｃｋ Ｆｉｌｅ ＩＤ＝１，Ｔｒａｃｋ Ｆｉｌｅ ＩＤ＝２であるとする。
先ず、図１８（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいては、コンテンツデータ全体の再生時間幅が“４００”とされるうち、トラック消去済みのデータ部分は、再生時間“１５０”〜“４００”の範囲となる領域Ｂであり、その再生時間幅は“２５０”となる。
また、図１８（ｂ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅでは、コンテンツデータ全体の再生時間幅は、図１８（ａ）と同じ“４００”とされる。しかし、トラック消去済みのデータ部分である領域Ｂは、この場合、再生時間“２５０”〜“４００”の範囲であるから、その再生時間幅は“１５０”となる。
さらに、図１８（ｃ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータ全体の再生時間幅は“６００”とされる。そして、この場合のトラック消去済みのデータ部分は領域Ａ〜Ｅのうち、領域Ｂ，Ｄとなる。領域Ｂは、再生時間“２００”〜“３００”の範囲で、その再生時間幅は“１００”となる。領域Ｃは、再生時間“５００”〜“５５０”の範囲で、その再生時間幅は“５０”となる。
【０１２４】
ここで、例えば図１８（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応するＡＶ Ｈｅａｄｅｒ Ｆｉｌｅとしては、Ｔｏｔａｌ Ｐｌａｙ Ｔｉｍｅは、４００を示すことになる。また、図１８（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応するＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒでは、領域Ａをトラックとして管理するための内容が格納され、そのＰｌａｙ Ｆｒｏｍ，Ｐｌａｙ Ｔｏは、それぞれ０、１５０を示すことになる。
そして、上記したＴｏｔａｌ Ｐｌａｙ Ｔｉｍｅ＝４００、Ｐｌａｙ Ｆｒｏｍ＝０，Ｐｌａｙ Ｔｏ＝１５０の情報から、トラック消去済みのデータ部分である領域Ｂの再生時間幅は、“２５０”（＝４００−１５０）であることが認識できることになる。
【０１２５】
そして、図１８（ｂ）（ｃ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについても同様にして、対応するＡＶ Ｈｅａｄｅｒ ＦｉｌｅのＴｏｔａｌ Ｐｌａｙ Ｔｉｍｅと、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒに格納されるＰｌａｙ Ｆｒｏｍ，Ｐｌａｙ Ｔｏの値を利用することで、トラック消去済みのデータ部分である各領域の再生時間幅を特定することができる。
【０１２６】
そして、上記のようにして、ステップＳ３０３において、トラック消去済みのデータ部分ごとの再生時間幅を認識した後は、次のステップＳ３０４によって、トラック消去済みのデータ部分について、再生時間幅順のリストを作成する。
このリストは、例えば図１９に示すものとなる。この図１９に示すリストは、トラック消去済みのデータ部分を含むＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが、図１８（ａ）（ｂ）（ｃ）に示したものである場合を例にしている。
【０１２７】
図１９に示すリストは、リスト順ごとに対応して、トラック消去済みデータ部分を特定するアドレス的な情報と、その再生時間幅の情報を格納する構造を有している。ここでのトラック消去済みデータ部分を特定する情報としては、先ず、そのトラック消去済みデータ部分を含むＡＶ Ｈｅａｄｅｒ ＦｉｌｅのファイルＩＤ（Ｔｒａｃｋ Ｆｉｌｅ ＩＤ）と、そのトラック消去済みデータ部分についてのＰｌａｙ Ｆｒｏｍ／Ｐｌａｙ Ｔｏの値を格納することとしている。
【０１２８】
ここで、図１８（ａ）（ｂ）（ｃ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのトラック消去済みのデータ部分のうち、、図１８（ａ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂが、再生時間幅“２５０”とされて、最も長い再生時間幅を有している。また、次に長いのは、図１８（ｂ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂの再生時間幅“１５０”である。さらに続いて、図１８（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂの再生時間幅“１００”、領域Ｄの再生時間幅“５０”となる。
【０１２９】
従って、図１９に示すリスト順１には、図１８（ａ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂについての情報が格納される。この場合、トラック消去済みデータ部分を特定する情報としては、ＩＤ＝０，Ｐｌａｙ Ｆｒｏｍ／Ｐｌａｙ Ｔｏ＝１５０／４００の情報が格納されることで、図１８（ａ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂであることが特定される。また、再生時間幅の情報としては２５０が格納される。
以降、リスト順２〜リスト順４には、上記した再生時間幅順に従って、図１８（ｂ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂ、図１８（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂ、Ｄについての情報が格納される。
【０１３０】
次のステップＳ３０５においては、上記ステップＳ３０４により作成したリストの内容を参照して、リスト順に従って、トラック消去済みのデータ部分についてのディスク上消去を実行する。つまりは、必要なディスク上でのデータ消去量が得られるように、リスト順に従って、トラック消去済みのデータ部分についてのディスク上消去を実行する。
【０１３１】
ここで、例えば図１９に示すようにして作成されるリスト順により、トラック消去済みのデータ部分を、ディスク上消去していくということは、できるだけ再生時間幅が長い、つまり、ひとまとまりのデータサイズが大きい領域から消去していくということを意味する。
本実施の形態の記録再生装置１としては、ディスクに対するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの書き込みは、できるかぎり、ディスク上において物理的に連続するようにして行うようにされており、なるべく離散して記録されることが無いように配慮される。
これは、記録媒体がディスクであることから、離散記録されたデータにアクセスしながらストリームデータの記録再生を行うのは、アクセスタイム、及びシークタイムが必要となる関係上、システムに負担がかかることが理由となっている。
【０１３２】
このようなことを考慮すれば、トラック消去済みのデータ部分についてのディスク上消去によってディスクに空き容量を形成するとした場合にも、ディスク上において物理的にできるだけ長く連続した空き容量を形成することが好ましいということになる。
そこで、本実施の形態では、上記したように再生時間幅が最も長いトラック消去済みのデータ部分から、優先的にディスク上消去を実行することとしているものである。これにより、トラック消去済みのデータ部分についてのディスク上消去によっても、できるだけ長く連続した空き容量が得られるようにしている。
なお、ディスク上消去のリスト順を形成するのは、あくまでもトラック消去済みのデータ部分の再生時間幅に依るから、必ずしも、この再生時間幅を有するデータ部分が、そのまま、ディスク上における物理的な連続性を有しているとは限らず、ディスク上では離散的に記録されている可能性を有してはいる。
しかしながら、本実施の形態の記録再生装置１としては、先にも述べたようにして、先ずは、できるだけディスク上において物理的に連続した領域に１つのＡＶＳｔｒｅａｍ Ｆｉｌｅが記録されるようにして書き込みを実行することとしている。このため、上記した効果は相当に高い確率で得ることができるものである。
【０１３３】
６．ブロック暗号化されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのディスク上消去
また、本実施の形態の記録再生装置１では、図１にも示したようにして、例えば入出力処理部５内に、暗号化及び暗号復号化処理を実行する暗号処理部５ａを備える。つまり、本実施の形態において、ディスクに対して記録されるデータとしては、暗号化される場合があるということになる。
そして、暗号化のアルゴリズムの１つとしてブロック暗号化が知られているが、さらに、このブロック暗号化のモードの１つとしてＣＢＣモードが知られている。
ここでＣＢＣモードによる暗号化処理を簡単に述べておくと、次のようになる。
・平文データＤを同じデータ長のブロックｄ１，ｄ２，．．，ｄｎに分ける。
・上記のブロックと同じ長さのＩＶ（Ｉｎｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ）を用意する。
・ｄ１とＩＶの排他的論理和を暗号化し、これをｅ１とする。
・ｄ２とｅ１の排他的論理和を暗号化し、これをｅ２とする。
・ｄ３とｅ２の排他的論理和を暗号化し、これをｅ３とする。
・以下同様の処理を繰り返し、得られたｅ１、ｅ２、…をつなげたものを暗号文とする。
【０１３４】
そして、ここで暗号処理部５ａが、上記ＣＢＣモードによるブロック暗号化に対応した暗号化／復号化処理を実行可能であるとした場合における、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ、コンテンツのデータ管理単位、ＦＡＴファイルシステムのデータ管理単位、及びブロック暗号化単位の関係例を、図２０に示す。なお、この図に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する各単位の関係は、あくまでも説明の便宜のための概念的なものであって、必ずしも実際と同一ではない。
【０１３５】
そして、この図２０によると、図２０（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、全体で領域Ａを有している。そして、このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａは、図２０R>０（ｂ）のコンテンツのデータ管理単位としては、管理単位Ａ〜Ｅの５つ分のサイズに相当することになる。
また、図２０（ｃ）に示すＦＡＴファイルシステムのデータ管理単位は、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａに対して、管理単位Ａ，Ｂと、これに続く管理単位Ｃの一部が対応するようになっている。また、図２０（ｂ）に示すコンテンツのデータ管理単位の２つ分のサイズが、１つのＦＡＴファイルシステムのデータ管理単位のサイズと同じになる関係を有している。
さらに、図２０（ｄ）に示すブロック暗号化単位は、８つ分で、１つのＦＡＴファイルシステムのデータ管理単位と同じサイズになる関係を有する。従って、４つ分であれば、１つのコンテンツのデータ管理単位と同じサイズとなる。
【０１３６】
そして、ここでは、図２０に示す分割位置により、図２０（ａ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、領域Ａを領域Ａ−１と領域Ａ−２とに分割するようにしてトラック分割編集したとする。この分割位置は、図２０（ｂ）に示すように、コンテンツデータの管理単位Ｂ，Ｃの境界位置に対応する。また、この場合には、この分割位置は、図２０（ｃ）に示すファイルシステムのデータ管理単位Ａ，Ｂの境界とも一致している状態となっている。
さらに、この図に示す分割位置は、図２０（ｄ）に示すブロック暗号化単位Ａ，Ｂの境界にも対応している。
【０１３７】
そして、上記のようにしてＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのトラック分割を行ったところ、図に示すブロック暗号化単位のシーケンスにおいて、分割位置に対応する境界の直前のブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分は、ＩＶ（Ｉｎｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ）として必要なデータを含むデータ部分であったとする。なお、この場合には、例えば図２０（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ全体を、暗号化ブロックのチェーン範囲としているものとする。
【０１３８】
そして、上記図２０に示すようにしてトラック分割編集した後において、例えば、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａ−１のデータ部分について、ディスク上消去を行ったとする。このような編集結果に対応する状態を図２１に示す。
この図から分かるように、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａ−１のデータ部分についてディスク上消去を行うということは、ファイルシステムのデータ管理単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分がディスク上から消去されるようにＦＡＴを書き換えるということである。
しかしながら、この場合において、単純に、ＦＡＴの書き換えによってファイルシステムのデータ管理単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分をディスクから消去したとすると、ブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分に含まれるＩＶも消去されてしまうこととなる。
このＩＶは、以降のブロック暗号化単位のデータ部分についての暗号復号化処理に必要な情報である。従って、このＩＶをそのままディスク上から消去してしまったのでは、以降の領域Ａ−２としてのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分について、適正に暗号復号化処理を施して再生出力することができなくなってしまう。
【０１３９】
従来における、上記のような不都合への対策として、例えば１つには、このブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分のように、ＩＶを含むとされるデータ部分については、ディスク上からの消去は行わずに残すということが行われている。
しかしながら、例えば図２０からも分かるように、ＩＶを含むブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分を、ディスクから消去しないように残そうとすれば、結局、ファイルシステムのデータ管理単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分をまるごとディスクから消去せずに残さなければならない。従って、この図の場合には、結局、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａ−１としてのデータ部分は、ディスクから消去されずに残ってしまうことになる。
これは、実際においては、ＩＶを含むブロック暗号化単位のデータ部分を残すために、例えばこれよりデータサイズの大きなファイルシステムのデータ管理単位分のデータを残さなければならないことを意味する。つまり、この場合には、ディスク空き容量を有効に確保できないという問題を有することになる。
【０１４０】
また、対策の１つとして、ブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分のように、ＩＶを含む１ブロック暗号化単位のデータを、例えばディスク上において確保された所定の待避用のアドレス領域に書き込んでおき、そのＩＶが必要となった場合に、この待避用のアドレス領域からデータ読み出しを行って使用する、ということも行われている。
しかしながら、この場合には、ディスク上に、ＩＶのデータを待避させる領域を確保しなければならないために、その分、ユーザデータを書き込み可能なディスク容量が減少してしまうという不都合が生じる。また、待避用のアドレス領域と、ここに記録されるＩＶのデータをＦＡＴによって管理することになるので、ＦＡＴファイルシステムもそれだけ複雑になって、処理も重くなってしまうことにもなる。
【０１４１】
そこで、本実施の形態としては、図２２に示すようにして上記問題を解決することとしている。なお、図２２において、図２２（ａ）（ｂ）（ｃ）（ｄ）は、図２１（ａ）（ｂ）（ｃ）（ｄ）と同一であることから、ここでの説明は省略する。
図２２（ｅ）には、暗号化チェーン単位が示されている。この図２２（ｅ）に示す暗号化チェーン単位と、図２２（ｂ）に示すコンテンツのデータ管理単位とを比較して分かるように、ここでは、暗号化チェーン単位とコンテンツのデータ管理単位とについて同じとなるようにしているものである。
そして、この図に関しては、１つの暗号化チェーン単位は、図２２（ｄ）に示すブロック暗号化単位の４つ分に相当させることとしている。
つまり、本実施の形態では、少なくとも、１つの暗号化チェーン単位を、１つのコンテンツのデータ管理単位の範囲内に納めることとしているものである。その例として、図２２では、暗号化チェーン単位とコンテンツのデータ管理単位とについて同じとなるようにしているものである。従って、例えば２以上の暗号化チェーン単位を、１つのコンテンツのデータ管理単位の範囲内に納めるようにしても構わないことになる。なお、このような場合、全てのＩＶについて定数（例えば０）とすることになる。
【０１４２】
上記図２２に示す手法を採ることで、先に述べたように、ディスク消去時において、ＩＶを含むデータ部分についてはファイルシステムのデータ管理単位分により未消去としたり、また、ディスク上に設けた待避領域にＩＶを待避させる必要はなくなって、上記した問題は解決されることになる。
なお、図２２に示す手法を実現するのには、暗号処理部５ａについて、ディスクに記録すべきＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対して、上記図２２の説明に基づいて定められた所定のチェーン範囲によって暗号化処理を施すように構成すればよい。
【０１４３】
これまで説明してきた実施の形態については、次のようなことがいえる。
先ず、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとしてのコンテンツデータのトラック分割、トラック消去の編集としては、図６〜図１２により説明したように、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）の書き換えにより行うようにしている。これにより、本実施の形態としては、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとしてのコンテンツデータのトラック分割、トラック消去の編集までの段階では、ＦＡＴの書き換えに依存しないことになるので、ＦＡＴ書き換えのための処理負担が軽減され、例えばそれだけ高速な編集処理動作を得ることができる。
【０１４４】
また、そのうえで、図１５に示したようにして、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについてディスク上消去を実行した場合において、このディスク上消去すべきデータ領域の終端部分について、消去されずに残る場合には、この消去されずに残ったデータ部分をＥＳ Ｏｆｆｓｅｔとして、このデータ部分に続くトラックデータ部分の先頭に付加してＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを形成することとしている。これにより、実際にディスク上で消去されたとされるデータサイズと、ユーザ側からディスク上で消去したように見えるデータサイズの間に生じる差分を解消することが可能となる。
つまり、これはファイルシステムによるファイル管理の下で、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）によりトラック管理を行う場合において、このような場合における不整合を解消し、より効率的なデータ管理が行われるようにしているということができる。
【０１４５】
さらに、本実施の形態では、図１７により説明したようにして、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにＥｒａｓｓｅ Ｆｌａｇを設けるようにしている。そして、このＥｒａｓｓｅ Ｆｌａｇの状態を見ることで、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいてトラック消去済みとされているデータ部分があるか否かを判定するようにしている。つまり、Ｅｒａｓｓｅ Ｆｌａｇを設けたことで、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの一部であるとしても、ディスク上消去してもよいとされるデータ部分を適切に見つけだして、ディスクの空き容量を効率的に作り出していくことが可能とされているものである。
さらに、図１７及び図１８により説明したようにして、トラック消去済みのデータ部分のうちで、再生時間幅が長いものからディスク上消去していくようにし、できるだけ連続した空き容量が得られるようにしている。これによっては、上記したディスクの空き容量を、書き込み／読み出し効率を考慮して作り出していくことが可能となるものである。
そして、これらの手法を採ることによっても、ファイルシステムによるファイル管理の下で、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）によりトラック管理を行う場合において、より効率的なデータ管理を実現しているということがいえる。
【０１４６】
さらに、図２２により説明したようにして、暗号化チェーン範囲を規定することで、例えばＣＢＣモード等により暗号化されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅをトラック分割したデータ部分を消去するときにも、ＩＶを保存、待避させておく必要が無くなって、ＦＡＴ書き換え処理等の負担の軽減や、ディスク容量の節約が図られる。
つまり、このような手法も、同じく、ファイルシステムによるファイル管理下で、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）によりトラック管理を行うという構成を採る場合において、より効率的なデータ管理を行うことを目的として行われるものである。
【０１４７】
ところで、上記のようにして各図により説明してきた手法は、例えばシステムコントローラ８がプログラムを実行することによって実現される。このためのプログラムは、例えば記録再生装置１のＲＯＭ９に予め記憶して格納しておくものである。
【０１４８】
あるいは、プログラムは、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔ Ｏｐｔｉｃａｌ）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。例えば、本実施の形態であれば、ディスク９０にプログラムを記録し、パッケージソフトウェアとして提供することができる。これにより、記録再生装置１では、ディスク９０を再生してプログラムを読み出し、ＲＯＭ９に記憶させることでインストールできる。
また、例えば、本実施の形態としての処理を実行させるプログラムを各種記録媒体に記憶させておけば、本実施の形態としての動作を、汎用のパーソナルコンピュータなどにインストールして実行させることが可能になる。
なお、プログラムは、上記のようなリムーバブルな記録媒体からインストールする他、プログラムを記憶しているサーバなどから、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークを介してダウンロードすることもできる。
【０１４９】
また、本発明としてはこれまでに説明した構成に限定されるものではない。例えば、各図により説明した処理手順などは、実際に応じて適宜変更されてよい。また、本実施の形態において編集対象となっているＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（ストリームデータ）は、ビデオデータであることとしているが、前述もしているように、そのフォーマットについてここでは特に限定されるものではない。また、ビデオデータ以外にも、例えば圧縮符号化フォーマットを含む、各種フォーマットによるオーディオデータなどとされてもよいものである。
また、ここでは、記録再生装置としては、ミニディスク（ＭＤ）方式のディスクに対応するものとしているが、これに限定されるものではなく、他の各種方式による記録可能なディスクメディアに対応する構成とされてよい。さらには、ファイルシステムによって管理される下で、データファイルによってトラック管理されるデータ管理構造を採るのであれば、ディスクメディア以外の他のメディアを対象として本発明を適用することも考えられる。
【０１５０】
【発明の効果】
以上説明したように本発明は、記録媒体に記録されるストリームデータを、ファイルシステムによってファイルとして管理するようにされる。これを前提として、ファイルシステムによって管理されるトラック管理用データファイルにより、ストリームデータをトラック単位で管理するようにされる。そして、トラック単位による分割、消去の編集（トラック分割、トラック消去）は、上記トラック管理用データファイルにおいて各トラックを規定するトラック管理情報の内容を書き換えることで実行される。
このような構成とされることで、トラック単位による分割、消去編集処理にあたっては、ファイルシステムを書き換える必要はないこととなって、それだけ、編集処理の負担は軽減され、例えばより高速な編集動作を得ることができる。
【０１５１】
また、ファイルシステムの書き換えによって、ファイルシステムのデータ管理単位に基づいて、ストリームデータを記録媒体から消去するときに、このファイルシステムのデータ管理単位に相当するデータ領域に、上記記録媒体からの消去対象であったデータ部分の一部が残る状態となった場合には、この残ったデータ部分の一部をオフセット領域として、ストリームデータの実体の先頭に付加する。そして、このオフセット領域＋ストリームデータの実体が、新規なストリームデータのファイルとして管理されるようにする。
これにより、実際にディスク上で消去されたとされるデータサイズと、ユーザ側からディスク上で消去したように見えるデータサイズの間に生じる差分が解消される。
【０１５２】
さらに本発明では、トラック消去情報（Ｅｒａｓｓｅ Ｆｌａｇ）を規定して、このトラック消去情報の状態を見ることで、１つのストリームデータのファイルにおいて、トラック消去編集が行われたデータ部分があるか否か判定し、このデータ部分の消去が行えるようにしている。これにより、例えばストリームデータのファイルの一部であっても、不要とされるデータ部分を適切にディスク上から消去して、ディスクの空き容量を効率的に得ていくことができる。
【０１５３】
さらには、トラック管理情報によりトラック単位でストリームデータを管理するための最小データ単位（コンテンツのデータ管理単位）の範囲内において、暗号ブロックをチェーン化する範囲が収まるようにして暗号化処理を実行するように構成される。これにより、暗号化されたストリームデータのファイルをトラック分割したデータ部分を消去するときにも、例えばＩＶなどの暗号化に必要となる情報を保存、待避させておく必要が無くなって、ファイルシステム書き換えのための処理等の負担を軽減し、ディスク容量の節約を図ることができる。
【０１５４】
このようにして、本発明としては、先ず、ファイルシステムによるファイル管理下で、データファイルによりトラック管理を行うという構成を採ることで処理負担の軽減効果などを得ており、さらにこのような構成を採る場合において、記録媒体に記録されるデータについて、より効率的な管理が行われるようにされるものである。
【図面の簡単な説明】
【図１】本発明の実施の形態の記録再生装置の構成例を示すブロック図である。
【図２】実施の形態のディスクのフォーマットの説明図である。
【図３】実施の形態のディスクのエリア構造の説明図である。
【図４】実施の形態のディスクの管理構造の説明図である。
【図５】実施の形態の記録再生装置のストレージ部のブロック図である。
【図６】実施の形態におけるディスク上でのファイル構成例を概念的に示す説明図である。
【図７】実施の形態のＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの構造例を示す説明図である。
【図８】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの構造例を示す説明図である。
【図９】ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅと、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとの関係を示す説明図である。
【図１０】トラック再生のための処理動作を示すフローチャートである。
【図１１】トラック分割編集に対応するＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによるトラック管理例を示す説明図である。
【図１２】トラック消去編集に対応するＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによるトラック管理例を示す説明図である。
【図１３】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツのデータ管理単位、及びファイルシステムのデータ管理単位の関係例を示す説明図である。
【図１４】トラック分割されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツのデータ管理単位、及びファイルシステムのデータ管理単位の関係例を示す説明図である。
【図１５】ディスク消去時におけるＥＳ Ｏｆｆｓｅｔの設定例を示す説明図である。
【図１６】ディスク上消去開始のための処理動作を示すフローチャートである。
【図１７】ディスク上消去のための処理動作を示すフローチャートである。
【図１８】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいてトラック消去された領域の再生時間幅を説明するための説明図である。
【図１９】図１７に示す処理において作成されるリストのデータの構造例を示す説明図である。
【図２０】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツのデータ管理単位、ファイルシステムのデータ管理単位、及びブロック暗号化単位の関係を示す説明図である。
【図２１】暗号化されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを分割して形成したトラックをトラック消去した場合において、ＩＶがトラック消去の対象データ部分となる事例を示す説明図である。
【図２２】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツのデータ管理単位、ファイルシステムのデータ管理単位、ブロック暗号化単位、暗号チェーン化単位の関係を示す説明図である。
【符号の説明】
１ 記録再生装置、２ ストレージ部、３ キャッシュメモリ、４ ＵＳＢインターフェース、５ 入出力処理部、５ａ 暗号処理部、６ 表示部、７ 操作部、８ システムコントローラ、９ ＲＯＭ、１０ ＲＡＭ、１１ キャッシュ管理メモリ、１２ ＮＶ−ＲＡＭ、１００ パーソナルコンピュータ／ネットワーク
【０００１】
【発明の属する技術分野】
本発明は、所定の記録媒体に記録されたデータを編集するためのデータ編集方法、データ編集装置に関する。
【０００２】
【従来の技術】
パーソナルコンピュータには、記憶媒体としてＨＤＤ（ハードディスクドライブ）が備えられる。
そして、周知のようにして、このようなＨＤＤに対するファイルの記録再生は、いわゆるファイルシステムが採用される。例えばこのようなファイルシステムとしては、ＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）が知られている（例えば非特許文献１参照）。
【０００３】
また、近年においては、上記したパーソナルコンピュータの周辺機器として、ビデオ、オーディオなどのコンテンツデータを記録再生できるＡＶ機器が提案され、また、知られるようになってきている。
このようなＡＶ機器は、例えば携帯可能な程度のサイズ形状とされる。そして、所定のデジタルインターフェイスによって、パーソナルコンピュータと接続されることで、例えばパーソナルコンピュータ側から、コンテンツデータを取り込み、装填された所定の記録媒体に記録して保存することができる。
そして、このようにして記録媒体にコンテンツデータを保存した後は、ＡＶ機器単体で、記録媒体からコンテンツデータを再生して音声、画像として出力することが可能とされている。
【０００４】
【非特許文献１】
Ｍｉｃｒｏｓｏｆｔ Ｅｘｔｅｎｓｉｂｌｅ Ｆｉｒｍｗａｒｅ Ｉｎｉｔｉａｔｉｖｅ ＦＡＴ３２ Ｆｉｌｅ Ｓｙｓｔｅｍ Ｓｐｅｃｉｆｉａｔｉｏｎ
ｈｔｔｐ：／／ｗｗｗ．ｍｉｃｒｏｓｏｆｔ．ｃｏｍ／ｈｗｄｅｖ／ｈａｒｄｗａｒｅ／ｆａｔｇｅｎ．ａｓｐ
【発明が解決しようとする課題】
【０００５】
そして、上記したようなＡＶ機器において、記録媒体に記録したコンテンツデータを管理するのにあたっては、例えば、ファイルシステムを採用することも提案され、また、実現されてきている。このようにすれば、ファイル管理の形態は、データインターフェイスを介して接続されるパーソナルコンピュータと同様となるから、それだけ、パーソナルコンピュータとの親和性が高まり、この点で、有用性が高い。
【０００６】
また、上記したようなＡＶ機器においては、コンテンツデータの分割、消去などの、いわゆる編集機能が与えられることが、ユーザの使い勝手上好ましい。
しかしながら、記録データの管理に、上記のようにしてファイルシステムを採用した場合には、次のような問題を有することになる。
ファイルシステムによるデータ管理は、記録媒体に物理的に記録されたデータを直接的に管理するものである。従って、例えば、コンテンツデータに対する分割、消去等の編集に応じては、その編集結果が適切に得られるように、ファイルシステムの内容そのものを更新する必要が生じる。
例えば、上記したようなＡＶ機器にとっては、ファイルシステムの更新は、相応に重い処理であり、システムにもかなりの負荷がかかる。このため、上記した分割、消去などの編集処理に際しては、ファイルシステムの更新の終了に或る程度の時間を要することになるので、結果として、編集処理には相応の時間がかかることになってしまう。
【０００７】
【課題を解決するための手段】
そこで、本発明は上記した課題を考慮して、先ずは、ファイルシステムによりファイルとして管理されるコンテンツデータ（ストリームデータ）についての編集処理について、より軽い処理負担により実行できるようにしてシステムの効率化を図ることを目的とする。
【０００８】
そこで先ず、データ編集方法として次のように構成する。
つまり、本発明のデータ編集方法としては、所定の記録媒体に記録されるストリームデータを、ファイルシステムに基づくファイル単位で管理する第１のデータ管理手順と、ファイル単位のストリームデータの範囲内におけるデータ部分をトラックとし、トラックごとに対応する情報であって、ファイル単位のストリームデータとの対応を示す情報要素と、対応するファイル単位のストリームデータにおけるそのトラックのデータ位置を示す情報要素とを有して形成されるトラック管理情報を含むトラック管理用データファイルに基づいて、トラック単位での管理を行う第２のデータ管理手順とを実行するものとされる。
そして、上記ファイル単位のストリームデータを分割して複数トラックを形成するトラック分割、又はトラックを消去するトラック消去を行う場合には、第２のデータ管理手順が、トラック分割又はトラック消去の態様に応じて、トラック管理用データファイルにおけるトラック管理情報の内容について更新処理を実行するように構成する。
【０００９】
また、データ編集装置として次のように構成する。
本発明のデータ編集装置は、所定の記録媒体に記録されるストリームデータを、ファイルシステムに基づくファイル単位で管理する第１のデータ管理手段と、ファイル単位のストリームデータの範囲内におけるデータ部分をトラックとし、トラックごとに対応する情報であって、ファイル単位のストリームデータとの対応を示す情報要素と、対応するファイル単位のストリームデータにおけるそのトラックのデータ位置を示す情報要素とを有して形成されるトラック管理情報を含むトラック管理用データファイルに基づいて、トラック単位での管理を行う第２のデータ管理手段とを備える。
そして、ファイル単位のストリームデータを分割して複数トラックを形成するトラック分割、又はトラックを消去するトラック消去を行う場合には、第２のデータ管理手段が、上記トラック分割又はトラック消去の態様に応じて、トラック管理用データファイルにおけるトラック管理情報の内容について更新処理を実行するように構成することとした。
【００１０】
上記各構成によれば本発明は、先ずは、記録媒体に記録されるストリームデータを、ファイルシステムによってファイルとして管理するようにされる。その下で、ファイルシステムによって管理されるトラック管理用データファイルにより、ストリームデータをトラック単位で管理するという管理構造を有するようにされている。そして、トラック単位による分割、消去などの編集（トラック分割、トラック消去）は、上記トラック管理用データファイルにおいて各トラックを規定する情報内容を有するトラック管理情報の内容を書き換えることで行われる。このような構成であれば、トラック単位による分割、消去編集を行うのにあたっては、ファイルシステムの書き換えに依存する必要はないこととなる。
【００１１】
【発明の実施の形態】
以下、本発明の実施の形態について説明を行うこととする。なお、以降の説明は次の順序で行う。
１．記録再生装置の構成
２．ディスク及びストレージ部の構成
３．ＡＶデータの管理
４．トラック分割、消去編集
５．ディスク上消去
６．ブロック暗号化されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのディスク上消去
【００１２】
１．記録再生装置の構成
実施の形態としての記録再生装置は、一例として、磁界変調方式でデータ記録が行われる光磁気ディスクであるミニディスク（ＭＤ）方式のディスクに対する記録再生装置とする。但し、既に普及している音楽用途のミニディスクのみではなく、より高密度記録を可能とし、ビデオデータの他、コンピュータユースの各種データのストレージに利用できる高密度ディスクについても対応可能な記録再生装置である。
【００１３】
図１により本実施の形態の記録再生装置の構成を説明する。
図１においては、本実施の形態の記録再生装置１が、例えばパーソナルコンピュータ（或いはネットワーク）１００として外部の機器との間でデータ通信可能な機器として示している。
例えば記録再生装置１は、パーソナルコンピュータ１００とＵＳＢケーブル等の伝送路１０１で接続されることで、パーソナルコンピュータ１００に対する外部ストレージ機器として機能できる。また、パーソナルコンピュータ１００を介したり、或いは直接ネットワークと接続できる機能を備えるなどしてネットワーク接続されることで、音楽や各種データをダウンロードし、記録再生装置１においてストレージ部２に装填されたディスクに保存できるものともなる。
【００１４】
一方、この記録再生装置１はパーソナルコンピュータ１００等に接続しなくとも、例えばＡＶ（オーディオ・ビデオ）機器として機能する。例えば他のＡＶ機器等から入力されたオーディオデータやビデオデータ（ＡＶデータ）をディスクに記録したり、ディスクに記録された音楽データ等を再生出力することができる。
即ち本実施の形態の記録再生装置１は、パーソナルコンピュータ１００等に接続されることで汎用的なデータストレージ機器として利用でき、かつ単体ではＡＶ対応の記録再生機器としても利用できる装置である。
【００１５】
記録再生装置１は、ストレージ部２、キャッシュメモリ３、ＵＳＢインターフェース４、入出力処理部５、表示部６、操作部７、システムコントローラ８、ＲＯＭ９、ＲＡＭ１０、キャッシュ管理メモリ１１、ＮＶ−ＲＡＭ１２を備える。
【００１６】
ストレージ部２は、装填されたディスクに対する記録／再生を行う。本実施の形態で用いるいわゆるミニディスク方式のディスク及びそれに対応するストレージ部２の構成については後述する。
【００１７】
キャッシュメモリ３は、ストレージ部２でディスクに記録するデータ、或いはストレージ部２によってディスクから読み出されたデータについてのバッファリングを行うキャッシュメモリである。例えばＤ−ＲＡＭ２より構成される。
キャッシュメモリへのデータの書込／読出は、システムコントローラ（ＣＰＵ）８において起動されるタスクによって制御される。
【００１８】
ＵＳＢインターフェース４は、例えばパーソナルコンピュータ１００とＵＳＢケーブルとしての伝送路１０１で接続された際の、データ伝送のための処理を行う。
入出力処理部５は、例えば記録再生装置１が単体でオーディオ機器として機能する場合に記録再生データの入出力のための処理を行う。
【００１９】
システムコントローラ８は、記録再生装置１内の全体の制御を行うと共に、接続されたパーソナルコンピュータ１００との間の通信制御を行う。
ＲＯＭ９にはシステムコントローラ８の動作プログラムや固定パラメータ等が記憶される。
ＲＡＭ１０はシステムコントローラ８によるワーク領域として用いられ、また各種必要な情報の格納領域とされる。
例えばストレージ部２によってディスクから読み出された各種管理情報や特殊情報を記憶する。例えばＰ−ＴＯＣデータ、Ｕ−ＴＯＣデータ、プレイリストデータ、ＦＡＴデータ、ユニークＩＤ、ハッシュ値等を記憶する。Ｐ−ＴＯＣデータ、Ｕ−ＴＯＣデータはミニディスクに記録されている音楽トラック等の管理情報である。また後述もするが本実施の形態の記録再生装置１が対応できるミニディスク方式に準拠した高密度ディスクは、Ｐ−ＴＯＣ、Ｕ−ＴＯＣによる管理形式のうえに、ＦＡＴファイルシステムを構築したものである。プレイリストは、高密度ディスクにおいてＡＴＲＡＣ方式などによる音楽データ等のアドレス等を管理する情報であって、ＦＡＴシステム上の１つのファイルとして記録されるものである。高密度ディスクが装填された場合には、これらＦＡＴやプレイリストの情報も読み込むことになる。ユニークＩＤ、ハッシュ値等はパーソナルコンピュータ１００等との間でのデータ伝送に際しての認証処理や暗号化／復号に用いられる情報である。
【００２０】
キャッシュ管理メモリ１１は、例えばＳ−ＲＡＭで構成され、キャッシュメモリ３の状態を管理する情報が格納される。システムコントローラ８はキャッシュ管理メモリ１１を参照しながらデータキャッシュ処理の制御を行う。キャッシュ管理メモリ１１の情報については後述する。
ＮＶ−ＲＡＭ（不揮発性ＲＡＭ）１２は、電源オフ時にも消失させないデータの格納領域として用いられる。
【００２１】
表示部６は、システムコントローラ８の制御に基づいて、ユーザーに対して提示すべき各種情報の表示を行う。例えば動作状態、モード状態、楽曲等のデータの名称情報、トラックナンバ、時間情報、その他の情報表示を行う。
操作部７には、ユーザーの操作のための各種操作子として、操作キーやジョグダイヤルなどが形成される。ユーザーは記録・再生、データ通信のための所要の動作を操作部７を操作して指示する。システムコントローラ８は操作部７によって入力された操作情報に基づいて所定の制御処理を行う。
【００２２】
パーソナルコンピュータ１００等が接続された際の、システムコントローラ８による制御は例えば次のようになる。
システムコントローラ８は、ＵＳＢインターフェース４を介して接続されたパーソナルコンピュータ１００との間で通信可能とされ、書込要求、読出要求等のコマンドの受信やステイタス情報その他の必要情報の送信などを行う。
システムコントローラ８は、例えばディスクがストレージ部２に装填されることに応じて、ディスクからの管理情報等の読出をストレージ部２に指示し、キャッシュメモリ３を介して取り込んでＲＡＭ１０に格納させる。
Ｐ−ＴＯＣ、Ｕ−ＴＯＣの管理情報を読み込ませることで、システムコントローラ８はディスクのトラック記録状態を把握できる。
またＣＡＴを読み込ませることによりデータトラック内の高密度データクラスタ構造を把握でき、パーソナルコンピュータ１００からのデータトラックに対するアクセス要求に対応できる状態となる。
またユニークＩＤやハッシュ値により、ディスク認証その他の処理を行ったり、或いはこれらの値をパーソナルコンピュータ１００に送信して処理させることができる。
【００２３】
パーソナルコンピュータ１００からの或るデータの読出要求があった場合は、システムコントローラ８はストレージ部２に、当該データの読出を実行させる。読み出されたデータは、必要に応じてＡＶ信号処理部３にて信号処理が施された上で、キャッシュメモリ３に書き込まれる。但し、既に当該要求されたデータが既にキャッシュメモリ３に格納されていた場合は、ストレージ部２による読出は必要ない。いわゆるキャッシュヒットである。
そしてシステムコントローラ８はキャッシュメモリ３に書き込まれているデータを読み出させ、ＵＳＢインターフェース４を介してパーソナルコンピュータ１００に送信させる制御を行う。
【００２４】
パーソナルコンピュータ１００からの或るデータの書込要求があった場合は、システムコントローラ８は、伝送されてくるデータをキャッシュメモリ３に格納させる。そして、キャッシュメモリ３に格納されたデータをストレージ部２によってディスクに記録させる。
なお、ディスクへのデータ記録は、クラスタという単位が最小単位で行われるものとされる。例えばクラスタは３２ＦＡＴセクターである。
もし、パーソナルコンピュータ１００等が記録要求したデータ量が数セクターなどであって１クラスタに満たない場合、ブロッキングと呼ばれる処理が行われる。即ちシステムコントローラ８は、ストレージ部２に、まず当該ＦＡＴセクターを含むクラスタの読出を実行させる。読み出されたクラスタデータはキャッシュメモリ３に書き込まれる。
そしてシステムコントローラ８は、パーソナルコンピュータ１００からのＦＡＴセクターのデータ（記録データ）をＵＳＢインターフェース４を介してキャッシュメモリ３に供給させ、格納されているクラスタデータに対して、該当するＦＡＴセクターのデータの書換を実行させる。
そしてシステムコントローラ８は、必要なＦＡＴセクターが書き換えられた状態でキャッシュメモリ３に記憶されているクラスタデータを、記録データとしてストレージ部２に転送させる。ストレージ部２では、当該クラスタ単位のデータをディスクに書き込む。
【００２５】
なお、以上は例えばパーソナルコンピュータ１００との伝送を伴うデータの記録再生のための制御であり、例えばミニディスク方式のオーディオデータなどのの記録再生時のデータ転送は、入出力処理部５を介して行われる。
入出力処理部５は、例えば入力系として、ライン入力回路／マイクロホン入力回路等のアナログ音声信号入力部、Ａ／Ｄ変換器や、デジタルオーディオデータ入力部を備える。またＡＴＲＡＣ圧縮エンコーダ／デコーダを備える。ＡＴＲＡＣ圧縮エンコーダ／デコーダは、ＡＴＲＡＣ方式によるオーディオデータの圧縮／伸長処理を実行するための回路である。なお、もちろんのこと、本実施の形態の記録再生装置としては、例えばＭＰ３などの他のフォーマットによる圧縮オーディオデータが記録再生可能な構成を採ってもよく、この場合には、これらの圧縮オーディオデータのフォーマットに対応したエンコーダ／デコーダを備えればよい。
また、本実施の形態としは、ビデオデータに関しては、特に記録再生可能なフォーマットの限定は行わないが、例えばＭＰＥＧ４などが考えられる。そして、入出力処理部５としては、このようなフォーマットに対応したエンコーダ／デコーダを備えればよいこととなる。
さらに入出力処理部５は、出力系として、デジタルオーディオデータ出力部や、Ｄ／Ａ変換器及びライン出力回路／ヘッドホン出力回路等のアナログ音声信号出力部を備える。
【００２６】
また、この場合の入出力処理部５内には、暗号処理部５ａが備えられる。暗号処理部５ａにおいては、例えばディスクに記録すべきＡＶデータについて、所定のアルゴリズムによる暗号化処理を施すようにされる。また、例えばディスクから読み出されたＡＶデータについて暗号化が施されている場合には、必要に応じて暗号解読のための復号処理を実行するようにもされている。
【００２７】
入出力処理部５を介した処理としてディスクにオーディオデータが記録されるのは、例えば入力ＴＩＮとして入出力処理部５にデジタルオーディオデータ（又はアナログ音声信号）が入力される場合である。入力されたリニアＰＣＭデジタルオーディオデータ、或いはアナログ音声信号で入力されＡ／Ｄ変換器で変換されて得られたリニアＰＣＭオーディオデータは、ＡＴＲＡＣ圧縮エンコードされてキャッシュメモリ３に蓄積される。そして所定タイミング（ＡＤＩＰクラスタ相当のデータ単位）でキャッシュメモリ３から読み出されてストレージ部２に転送される。ストレージ部２では、転送されてくる圧縮データを所定の変調方式で変調してディスクに記録する。
【００２８】
ディスクからミニディスク方式のオーディオデータが再生される場合は、ストレージ部２は再生データをＡＴＲＡＣ圧縮データ状態に復調してキャッシュメモリ３に転送する。そしてキャッシュメモリ３から読み出されて入出力処理部５に転送される。入出力処理部５は、供給されてくる圧縮オーディオデータに対してＡＴＲＡＣ圧縮デコードを行ってリニアＰＣＭオーディオデータとし、デジタルオーディオデータ出力部から出力する。或いはＤ／Ａ変換器によりアナログ音声信号としてライン出力／ヘッドホン出力を行う。
【００２９】
なお、この図１の記録再生装置１の構成は一例であり、例えば入出力処理部５は、オーディオデータだけでなく、ビデオデータに対応する入出力処理系を備えるようにしてもよい。
また、パーソナルコンピュータ１００との接続はＵＳＢでなく、ＩＥＥＥ１３９４等の他の外部インターフェイスが用いられても良い。
【００３０】
２．ディスク及びストレージ部の構成
本実施の形態の記録再生装置１で記録媒体とされるディスクは、例えばミニディスク方式のディスクである。特に従前の音楽用のミニディスクだけではなく、コンピュータユースの各種データを記録できる高密度ディスクにも対応する。
【００３１】
ここで図２（ａ）（ｂ）に、オーディオ用ミニディスク（及びＭＤ−ＤＡＴＡ）と、高密度ディスクの規格を比較して示す。
図２（ａ）に示すように、ミニディスク（及びＭＤ−ＤＡＴＡ）のフォーマットとしては、トラックピッチは１．６μｍ、ビット長は０．５９μｍ／ｂｉｔとなる。また、レーザ波長λ＝７８０ｎｍとされ、光学ヘッドの開口率ＮＡ＝０．４５とされる。
記録方式としては、グルーブ記録方式を採っている。つまり、グルーブ（ディスク盤面上の溝）をトラックとして記録再生に用いるようにしている。
アドレス方式としては、シングルスパイラルによるグルーブ（トラック）を形成したうえで、このグルーブの両側に対してアドレス情報としてのウォブルを形成したウォブルドグルーブを利用する方式を採るようにされている。
なお、本明細書では、ウォブリングにより記録される絶対アドレスをＡＤＩＰ（Ａｄｄｒｅｓｓ ｉｎ Ｐｒｅｇｒｏｏｖｅ）とも呼ぶ。
【００３２】
記録データの変調方式としてはＥＦＭ（８−１４変換）方式を採用している。また、誤り訂正方式としてはＡＣＩＲＣ（Ａｄｖａｎｃｅｄ Ｃｒｏｓｓ Ｉｎｔｅｒｌｅａｖｅ Ｒｅｅｄ−Ｓｏｌｏｍｏｎ Ｃｏｄｅ） が採用され、データインターリーブには畳み込み型を採用している。データの冗長度は４６．３％となる。
【００３３】
また、データの検出方式はビットバイビット方式である。ディスク駆動方式としてはＣＬＶ（Ｃｏｎｓｔａｎｔ Ｌｉｎｅａｒ Ｖｅｒｏｃｉｔｙ）が採用されており、ＣＬＶの線速度としては、１．２ｍ／ｓとされる。
そして、記録再生時の標準のデータレートとしては、１３３ｋＢ／ｓとされ、記録容量としては、１６４ＭＢ（ＭＤ−ＤＡＴＡでは１４０ＭＢ）となる。
またクラスタというデータ単位がデータの最小書換単位とされるが、このクラスタは、３２個のメインセクターと４個のリンクセクターによる３６セクターで構成される。
【００３４】
一方、高密度ディスクは、現状において、２つの規格が存在する。ここでは、２つの高密度ディスクの規格を、それぞれ、高密度ディスク（１）（２）として示す。
先ず、高密度ディスク（１）は、トラックピッチが１．５〜１．６μｍ、線密度０．４３７μｍ／ｂｉｔであり、記録容量としては３００ＭＢまで高くなっている。また、標準速度における転送レートは、４．３７Ｍｂｐｓ、線速度は、２．４ｍ／ｓｅｃとなっている。
また、高密度ディスク（２）は、トラックピッチが１．２５μｍ、線密度０．１６μｍ／ｂｉｔであり、記録容量は１ＧＢにまで高められている。また、標準速度における転送レートは、９．８３Ｍｂｐｓ、線速度は、１．９８ｍ／ｓｅｃとなっている。
【００３５】
なお、図２（ｂ）には示していないが、記録データの変調方式としては、高密度記録に適合するとされるＲＬＬ（１，７）ＰＰ方式（ＲＬＬ；Ｒｕｎ Ｌｅｎｇｔｈ Ｌｉｍｉｔｅｄ、ＰＰ：Ｐａｒｉｔｙ ｐｒｅｓｅｒｖｅ／Ｐｒｏｈｉｂｉｔ ｒｍｔｒ（ｒｅｐｅａｔｅｄ ｍｉｎｉｍｕｍ ｔｒａｎｓｉｔｉｏｎ ｒｕｎｌｅｎｇｔｈ））が採用され、誤り訂正方式としては、より訂正能力の高いＢＩＳ（Ｂｕｒｓｔ Ｉｎｄｉｃａｔｏｒ Ｓｕｂｃｏｄｅ）付きのＲＳ−ＬＤＣ（Ｒｅｅｄ Ｓｏｌｏｍｏｎ−Ｌｏｎｇ Ｄｉｓｔａｎｃｅ Ｃｏｄｅ）方式を用いている。データインターリーブにはブロック完結型が採用される。データの冗長度は２０．５０％とされる。
またデータの検出方式はパーシャルレスポンスＰＲ（１，２，１）ＭＬを用いたビタビ復号方式とされる。
なおＲＬＬ（１−７）変調及びＲＳ−ＬＤＣ誤り訂正方式については、例えば「特開平１１−３４６１５４号公報」や、「国際特許公開公報ＷＯ ００／０７３００」などに開示されている技術である。
またディスク駆動方式はＣＬＶ（Ｃｏｎｓｔａｎｔ Ｌｉｎｅａｒ Ｖｅｒｏｃｉｔｙ）又はＺＣＡＶ（Ｚｏｎｅ Ｃｏｎｓｔａｎｔ Ａｎｇｕｌａｒ Ｖｅｒｏｃｉｔｙ）である。
【００３６】
ディスク上のエリア構造を図３に模式的に示す。
図３に示すように、ディスクの最内周側はＰ−ＴＯＣ（プリマスタードＴＯＣ）領域とされ、ここは物理的な構造としてはプリマスタードエリアとなる。即ち、エンボスピットによる再生専用データが記録されるエリアであり、その再生専用データとして管理情報であるＰ−ＴＯＣが記録される。
【００３７】
プリマスタードエリアより外周はレコーダブルエリア（光磁気記録可能な領域）とされ、記録トラックの案内溝としてのグルーブが形成された記録再生可能領域となっている。
このレコーダブルエリアの最内周側はＵ−ＴＯＣ領域とされる。
なおＵ−ＴＯＣ領域では、プリマスタードエリアとの緩衝エリアや、レーザー光の出力パワー調整等のために用いられるパワーキャリブレーションエリアが設けられ、またＵ−ＴＯＣ領域内の特定の３クラスタの区間にＵ−ＴＯＣデータが３回繰り返し記録される。
Ｕ−ＴＯＣの内容の詳細については省略するが、プログラムエリアに記録されている各トラックのアドレス、フリーエリアのアドレス等が記録され、また各トラックに付随するトラックネーム、記録日時などの情報が記録できるようにＵ−ＴＯＣセクターが規定されている。
【００３８】
レコーダブルエリアにおいてＵ−ＴＯＣ領域より外周側にアラートトラック及びデータエリアが形成される。アラートトラックは、このディスクが高密度ディスクであって、従前のミニディスクプレーヤでは再生できないことを示す警告音が記録された警告トラックである。データエリアは、オーディオデータやコンピュータユースのデータなどの記録に用いられるエリアとなる。
即ち、通常の音楽用ミニディスクの場合であれば、データエリアに１又は複数の音楽トラックが記録される。
高密度ディスクの場合は、データエリアが各種データのストレージ領域として用いられるものとなる。
【００３９】
図４によりディスクの管理構造を説明する。
図４（ｂ）は、音楽用ミニディスクシステムでの管理構造を示している。
この場合、管理情報としては、Ｐ−ＴＯＣ、Ｕ−ＴＯＣが記録される。
Ｐ−ＴＯＣは書き換え不能な情報としてピットにより記録される。このＰ−ＴＯＣには、ディスクの基本的な管理情報として、ディスクの総容量、Ｕ−ＴＯＣ領域におけるＵ−ＴＯＣ位置、パワーキャリブレーションエリアの位置、データエリアの開始位置、データエリアの終了位置（リードアウト位置）などが記録されている。
【００４０】
一方、レコーダブルエリアに記録されるＵ−ＴＯＣは、トラック（オーディオトラック／データトラック）の記録、消去などに応じて書き換えられる管理情報であり、各トラック（トラックを構成するパーツ）について開始位置、終了位置、やモードを管理する。また、データエリアにおいて未だトラックが記録されていないフリーエリア、つまり書込可能領域としてのパーツも管理する。
例えば図示するようにデータエリア内に、ＡＴＲＡＣデータとして３曲のオーディオトラックが記録されている場合、Ｕ−ＴＯＣでは、３つのトラックをそれぞれスタートアドレス、エンドアドレス、モード情報、さらには記録日時や名称情報を管理することになる。
【００４１】
高密度ディスクの場合は図４（ａ）のようになる。
高密度ディスクの場合も、Ｕ−ＴＯＣ及びＰ−ＴＯＣは、従前のミニディスクシステムに準拠する方式で記録される。
そして図４（ａ）のデータエリアには、１つの高密度データトラックを示しているが、Ｕ−ＴＯＣでは、この高密度データトラックを１つのトラックとして管理する状態となっている。
つまりＵ−ＴＯＣからは、ディスク上における、データトラックの全体としての１又は複数のパーツ位置を管理するものとなる。なお、上述したアラートトラックの位置もＵ−ＴＯＣに管理される。
【００４２】
高密度データトラックは、ＲＳ−ＬＤＣ及びＲＬＬ（１−７）ＰＰ方式で変調された高密度データによって形成されるトラックとされる。
高密度データトラック内には、該データトラックに含まれる高密度データクラスタを管理するクラスタアトリビュートテーブル（ＣＡＴ：Ｃｌｕｓｔｅｒ Ａｔｔｒｉｂｕｔｅ Ｔａｂｌｅ）が記録される。ＣＡＴでは、データトラックを構成する高密度データクラスタのそれぞれについての属性（公開可能／不可、正常／不良等）を管理する。
【００４３】
このデータトラック内で公開不可とされる高密度データクラスタを用いて、著作権保護等のために用いられる、ディスクに固有のユニークＩＤ（ＵＩＤ）や、データ改竄チェックのためのハッシュ値（ｈａｓｈ）が記録される。もちろんこれ以外にも、各種の非公開情報が記録されても良い。
この公開不可とされる領域には、特別に許可された機器のみが限定的にアクセスすることができるものとする。
【００４４】
データトラック内で公開可能とされる高密度データクラスタによる領域（エクスポータブルエリア）は、例えばＵＳＢやＳＣＳＩなどの汎用データインターフェースを経由して、外部のコンピュータなどがアクセスし、記録領域として利用できる領域とされる。
例えばこの図４（ａ）の場合、エクスポータブルエリアには、ＦＡＴ及びＦＡＴ管理のデータファイルによる、ＦＡＴファイルシステムが構築されている状態を示している。
つまり、エクスポータブルエリアに記録されるデータは、Ｕ−ＴＯＣによっては管理されず、ＦＡＴなどの汎用的な管理情報により管理される形態となり、ミニディスクシステムに準拠しない外部のコンピュータなどによって認識可能なデータとなる。
【００４５】
ＡＴＲＡＣ方式等の音楽データ等がＦＡＴシステム上で記録される場合は、その音楽データ等のファイルを管理する管理情報としてプレイリストが記録される。このプレイリストはＦＡＴシステム上の１つのファイルとして記録されるものであり、記録再生装置１のシステムコントローラは、音楽データファイルの再生時にはプレイリストからアドレス等を把握するものとなる。
【００４６】
なお、このような構造のデータトラックが、ディスク上に複数記録される場合もある。その場合、各データトラックが、それぞれ１つのトラックとしてＵ−ＴＯＣから管理され、それぞれのデータトラック内のエクスポータブルエリア内のデータについては、ＦＡＴ等により管理される。例えば各データトラックがそれぞれ独自にＦＡＴファイルシステムを持つものとなる。あるいは、複数のデータトラックに渡って一つのＦＡＴファイルシステムが記録されるようにしてもよい。
【００４７】
また、ユニークＩＤ等の情報は、データトラック内であって、ＦＡＴ管理されないデータとする例を述べたが、ＦＡＴ管理されない情報とするなら、どのような論理形態で記録されてもよい。例えばＵ−ＴＯＣから直接的に管理されるトラックとして、非公開情報用のトラックを設けるようにしたり、あるいはＵ−ＴＯＣ／Ｐ−ＴＯＣ内に記録してもよい。更に、Ｕ−ＴＯＣ領域内で、Ｕ−ＴＯＣに使用されていない部分を用いて、非公開情報用の記録領域を設けてもよい。
【００４８】
なお、説明上、従前のミニディスクを「音楽用ミニディスク」と呼ぶが、いわゆるＭＤ−ＤＡＴＡとして知られているミニディスクも、この音楽用ミニディスクの範疇となる。
また、高密度ディスクに対してデータファイルとして音楽データが記録されることも当然にあり得る。例えばネットワークやパーソナルコンピュータからの音楽ファイルのダウンロードの場合などである。
【００４９】
図１に示したストレージ部２は、以上のような音楽用ミニディスクと汎用データ記録媒体としての高密度ディスクに対応できるディスクドライブ部とされる。
このストレージ部２の構成例を図５に示す。
【００５０】
図示するディスク９０は、上述した音楽用ミニディスク或いは高密度ディスク（１）又は高密度ディスク（２）である。
ストレージ部２においては、装填されたディスク９０をスピンドルモータ２９によってＣＬＶ方式で回転駆動させる。
このディスク９０に対しては記録／再生時に光学ヘッド１９によってレーザ光が照射される。
光学ヘッド１９は、記録時には記録トラックをキュリー温度まで加熱するための高レベルのレーザ出力を行い、また再生時には磁気カー効果により反射光からデータを検出するための比較的低レベルのレーザ出力を行う。このため、光学ヘッド１９には、ここでは詳しい図示は省略するがレーザ出力手段としてのレーザダイオード、偏光ビームスプリッタや対物レンズ等からなる光学系、及び反射光を検出するためのディテクタが搭載されている。光学ヘッド１９に備えられる対物レンズとしては、例えば２軸機構によってディスク半径方向及びディスクに接離する方向に変位可能に保持されている。
【００５１】
また、ディスク９０を挟んで光学ヘッド１９と対向する位置には磁気ヘッド１８が配置されている。磁気ヘッド１８は記録データによって変調された磁界をディスク９０に印加する動作を行う。
また、図示しないが光学ヘッド１９全体及び磁気ヘッド１８をディスク半径方向に移動させためスレッドモータ及びスレッド機構が備えられている。
【００５２】
このストレージ部２では、光学ヘッド１９、磁気ヘッド１８による記録再生ヘッド系、スピンドルモータ２９によるディスク回転駆動系のほかに、記録処理系、再生処理系、サーボ系等が設けられる。
記録処理系では、音楽用ミニディスクに対する記録時に第１の変調方式の変調（ＥＦＭ変調・ＡＣＩＲＣエンコード）を行う部位と、高密度ディスクに対する記録時に第２の変調方式（ＲＬＬ（１−７）ＰＰ変調、ＲＳ−ＬＤＣエンコード）の変調を行う部位が設けられる。
再生処理系では、音楽用ミニディスク（及び高密度ディスクのＵ−ＴＯＣ）の再生時に第１の変調方式に対する復調（ＥＦＭ復調・ＡＣＩＲＣデコード）を行う部位と、高密度ディスクの再生時に第２の変調方式に対する復調（パーシャルレスポンスＰＲ（１，２，１）及びビタビ復号を用いたデータ検出に基づくＲＬＬ（１−７）復調、ＲＳ−ＬＤＣデコード）を行う部位が設けられる。
【００５３】
光学ヘッド１９のディスク９０に対するレーザ照射によりその反射光として検出された情報（フォトディテクタによりレーザ反射光を検出して得られる光電流）は、ＲＦアンプ２１に供給される。
ＲＦアンプ２１では入力された検出情報に対して電流−電圧変換、増幅、マトリクス演算等を行い、再生情報としての再生ＲＦ信号、トラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥ、グルーブ情報（ディスク９０にトラックのウォブリングにより記録されているＡＤＩＰ情報）等を抽出する。
【００５４】
音楽用ミニディスク再生時には、ＲＦアンプで得られた再生ＲＦ信号は、ＥＦＭ復調部２４及びＡＣＩＲＣデコーダ２５で処理される。
即ち再生ＲＦ信号は、ＥＦＭ復調部２４で２値化されてＥＦＭ信号列とされた後、ＥＦＭ復調され、さらにＡＣＩＲＣデコーダ２５で誤り訂正及びデインターリーブ処理される。即ちこの時点でＡＴＲＡＣ圧縮データの状態となる。
そして音楽用ミニディスク再生時には、セレクタ２６はＢ接点側が選択されており、当該復調されたＡＴＲＡＣ圧縮データがディスク９０からの再生データとして出力される。この場合、図１のキャッシュメモリ３に圧縮データが供給されることになる。
【００５５】
一方、高密度ディスク再生時には、ＲＦアンプで得られた再生ＲＦ信号は、ＲＬＬ（１−７）ＰＰ復調部２２及びＲＳ−ＬＤＣデコーダ２５で処理される。
即ち再生ＲＦ信号は、ＲＬＬ（１−７）ＰＰ復調部２２において、ＰＲ（１，２，１）及びビタビ復号を用いたデータ検出によりＲＬＬ（１−７）符号列としての再生データを得、このＲＬＬ（１−７）符号列に対してＲＬＬ（１−７）復調処理が行われる。そして更にＲＳ−ＬＤＣデコーダ２３で誤り訂正及びデインターリーブ処理される。
そして高密度ディスク再生時には、セレクタ２６はＡ接点側が選択されており、当該復調されたデータがディスク９０からの再生データとして出力される。この場合、図１のキャッシュメモリ３に復調データが供給されることになる。
【００５６】
ＲＦアンプ２１から出力されるトラッキングエラー信号ＴＥ、フォーカスエラー信号ＦＥはサーボ回路２７に供給され、グルーブ情報はＡＤＩＰデコーダ３０に供給される。
【００５７】
ＡＤＩＰデコーダ３０は、グルーブ情報に対してバンドパスフィルタにより帯域制限してウォブル成分を抽出した後、ＦＭ復調、バイフェーズ復調を行ってＡＤＩＰアドレスを抽出する。
抽出された、ディスク上の絶対アドレス情報であるＡＤＩＰアドレスは図１に示したシステムコントローラ８に供給される。システムコントローラ８ではＡＤＩＰアドレスに基づいて、所要の制御処理を実行する。
またグルーブ情報はスピンドルサーボ制御のためにサーボ回路２７に供給される。
【００５８】
サーボ回路２７は、例えばグルーブ情報に対して再生クロック（デコード時のＰＬＬ系クロック）との位相誤差を積分して得られる誤差信号に基づき、ＣＬＶサーボ制御のためのスピンドルエラー信号を生成する。
またサーボ回路２７は、スピンドルエラー信号や、上記のようにＲＦアンプ２１から供給されたトラッキングエラー信号、フォーカスエラー信号、或いはシステムコントローラ８からのトラックジャンプ指令、アクセス指令等に基づいて各種サーボ制御信号（トラッキング制御信号、フォーカス制御信号、スレッド制御信号、スピンドル制御信号等）を生成し、モータドライバ２８に対して出力する。即ち上記サーボエラー信号や指令に対して位相補償処理、ゲイン処理、目標値設定処理等の必要処理を行って各種サーボ制御信号を生成する。
【００５９】
モータドライバ２８では、サーボ回路２７から供給されたサーボ制御信号に基づいて所要のサーボドライブ信号を生成する。ここでのサーボドライブ信号としては、二軸機構を駆動する二軸ドライブ信号（フォーカス方向、トラッキング方向の２種）、スレッド機構を駆動するスレッドモータ駆動信号、スピンドルモータ２９を駆動するスピンドルモータ駆動信号となる。
このようなサーボドライブ信号により、ディスク９０に対するフォーカス制御、トラッキング制御、及びスピンドルモータ２９に対するＣＬＶ制御が行われることになる。
【００６０】
ディスク９０に対して記録動作が実行される際には、キャッシュメモリ３からデータが供給される。
音楽用ミニディスク記録時には、セレクタ１６がＢ接点に接続され、従ってＡＣＩＲＣエンコーダ１４及びＥＦＭ変調部１５が機能することになる。
この場合、オーディオ処理部１０からの圧縮データはＡＣＩＲＣエンコーダ１４でインターリーブ及びエラー訂正コード付加が行われた後、ＥＦＭ変調部１５でＥＦＭ変調が行われる。
そしてＥＦＭ変調データがセレクタ１６を介して磁気ヘッドドライバ１７に供給され、磁気ヘッド１８がディスク９０に対してＥＦＭ変調データに基づいた磁界印加を行うことでデータ記録が行われる。
【００６１】
高密度ディスク記録時には、セレクタ１６がＡ接点に接続され、従ってＲＳ−ＬＤＣエンコーダ１２及びＲＬＬ（１−７）ＰＰ変調部１３が機能することになる。
この場合、メモリ転送コントローラ３からの高密度データはＲＳ−ＬＤＣエンコーダ１２でインターリーブ及びＲＳ−ＬＤＣ方式のエラー訂正コード付加が行われた後、ＲＬＬ（１−７）ＰＰ変調部１３でＲＬＬ（１−７）変調が行われる。
そしてＲＬＬ（１−７）符号列としての記録データがセレクタ１６を介して磁気ヘッドドライバ１７に供給され、磁気ヘッド１８がディスク９０に対して変調データに基づいた磁界印加を行うことでデータ記録が行われる。
【００６２】
レーザドライバ／ＡＰＣ２０は、上記のような再生時及び記録時においてレーザダイオードにレーザ発光動作を実行させるが、いわゆるＡＰＣ（Ａｕｔｏｍａｔｉｃ Ｌａｚｅｒ Ｐｏｗｅｒ Ｃｏｎｔｒｏｌ）動作も行う。
即ち、図示していないが、光学ヘッド１９内にはレーザパワーモニタ用のディテクタが設けられ、そのモニタ信号がレーザドライバ／ＡＰＣ２０にフィードバックされる。レーザドライバ／ＡＰＣ２０は、モニタ信号として得られる現在のレーザパワーを、設定されているレーザパワーと比較して、その誤差分をレーザ駆動信号に反映させることで、レーザダイオードから出力されるレーザパワーが、設定値で安定するように制御している。
なお、レーザパワーとしては、再生レーザパワー、記録レーザパワーとしての値がシステムコントローラ８によって、レーザドライバ／ＡＰＣ２０内部のレジスタにセットされる。
【００６３】
以上の各動作（アクセス、各種サーボ、データ書込、データ読出の各動作）は、システムコントローラ８からの指示に基づいて実行される。
【００６４】
３．ＡＶデータの管理
これまでの説明からも分かるように、例えば音楽用ミニディスクが原則オーディオデータのみを記録可能とされるのに対して、高密度ディスクは、汎用データが記録可能なディスクとされる。
そして、このような汎用データのなかにも、例えばオーディオデータやビデオデータなどのＡＶデータが含まれる。つまり、本実施の形態の高密度ディスクに対しても、ＡＶデータが記録可能である。特に、ＡＶデータの記録に関していえば、高密度ディスクは、音楽用ミニディスクと比較して大容量であるから、データレートの高いストリームデータである、ビデオデータの記録に適しているということがいえる。
【００６５】
そして、本実施の形態においては、高密度ディスクに記録されるＡＶデータは、図６に示すようにしてＦＡＴファイルシステム上で管理される。
先ず、ＦＡＴファイルシステムにおいては、ＡＶデータ用のディレクトリが存在するようにして管理が行われる。ここでは、ＡＶデータ用のディレクトリについては、ここでは仮に、「Ｈｉ−ＭＤＶ」というディレクトリ名としている。
そして、このディレクトリＨｉ−ＭＤＶには、図示するように、少なくとも３種類のファイルが格納されることになる。
まず、ＡＶデータの実体は、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとしてファイル単位により管理されて、このディレクトリＨｉ−ＭＤＶに格納される。そして、このディレクトリＨｉ−ＭＤＶに格納されるＡＶ Ｓｔｒｅａｍ Ｆｉｌｅごとに対応付けられるようにして、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが格納される。このＡＶ Ｈｅａｄｅｒ Ｆｉｌｅには、後述するようにして、対応付けられたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに関する所定内容の情報が格納される。また、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅと、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとの対応付けは、ここでは、各ファイルのファイル名の拡張子以外の部分を同一とすることで行うこととしている。
【００６６】
ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅは、ディレクトリＨｉ−ＭＤＶに格納されるＡＶデータを、トラック単位で管理するための管理情報が記述されたファイルである。以降の説明により理解されることであるが、本実施の形態では、ディレクトリＨｉ−ＭＤＶに格納されるＡＶデータとして、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、あくまでも、ＦＡＴファイルシステム上で管理されるファイルであり、トラックとしては扱わない。トラックは、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅによって管理される。
【００６７】
図７（ａ）にはＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの構造例が示されている。この図に示すようにして、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅは、Ｐｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅと、Ｔｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ
Ｔａｂｌｅとにより成る。
先ず、Ｔｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅは、１以上のＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒから成る。各Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒは、トラックごとに対応して設けられるもので、図示するようにして、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃１，＃２，・・・＃ｎのようにしてナンバが付されている。なお、このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバは、分割消去などによる編集結果に応じて欠落してもよいものであり、必ずしも連番となる必要はない。
【００６８】
また、Ｐｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅは、トラック単位での再生順を規定する。例えば、この場合のＰｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅには、左から順に、格納位置番号Ｐ１〜Ｐ（ｎ）により示される格納位置があるものとされ、これらの格納位置に対しては、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバが格納される。ここでは、格納位置番号Ｐ１に＃２、格納位置番号Ｐ２に＃１、・・・格納位置番号Ｐ（ｎ−１）に＃ｎが格納されていることから、トラック再生順としては、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃２が示すトラック→Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃１が示すトラック→・・・・→Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎが示すトラックの順となる。なお、この場合のＰｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅとしては、例えば格納位置番号Ｐ３が「−」と記載されており、これはＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバが格納されていないことを示す。つまり、本実施の形態としては、この図の場合であれば、再生順に従って、格納位置番号Ｐ１から左詰めとなるようにしてＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバを格納していく必要はない。再生順は、格納位置番号に従って、格納されているＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバを順次ピックアップしていくことで得られるものである。
【００６９】
１つのＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒは、図７（ｂ）に示す情報内容を有している。つまり、Ｔｒａｃｋ Ｆｉｌｅ ＩＤ，Ｐｌａｙ Ｆｒｏｍ，Ｐｌａｙ Ｔｏ，ＣＯＤＥＣ Ｉｎｆｏｒｍａｔｉｏｎを有する。
Ｔｒａｃｋ Ｆｉｌｅ ＩＤは、現Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒが示すトラックとしてのデータを含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ）のファイルＩＤを示す。このファイルＩＤは、例えばＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ）に与えられたファイル名と対応している。
Ｐｌａｙ Ｆｒｏｍは、現Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒが示すトラックについての、上記ファイルＩＤが示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいて再生が開始されるべき時間を示す。Ｐｌａｙ Ｔｏは、再生が終了すべき時間を示す。
ＣＯＤＥＣ Ｉｎｆｏｒｍａｔｉｏｎは、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコーデックの方式や、コーデック後のデータについての時間情報などに関する情報が格納される。
【００７０】
図８（ａ）は、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの構造を示している。
この図において、矢印ａで示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとしてのデータ開始位置からは、ＥＳ（Ｅｌｅｍｅｎｔａｒｙ Ｓｔｒｅａｍ） Ｏｆｆｓｅｔとしての領域が設けられる場合がある。ＥＳ Ｏｆｆｓｅｔは、本実施の形態のＡＶ Ｓｔｒｅａｍ ＦｉｌｅがＦＡＴファイルシステムによって管理されることに応じて付加されるものである。ＦＡＴファイルシステムでは、例えばクラスタ単位によりデータの記録再生を行うという条件が存在する。矢印ｂにより示す、コンテンツデータの再生開始位置（再生時間“０”）は、記録時の書き込みや、後述するような分割、ディスク上消去などの処理によって、必ずしもセクターの先頭から開始されるとは限らない。このようにして、コンテンツデータの再生開始位置を含むクラスタにおける空き領域を埋めるために、ＥＳ Ｏｆｆｓｅｔが定義されている。
そして、このＥＳ Ｏｆｆｓｅｔに続けて、ＡＶデータとしての実体であるコンテンツデータが配置される。
【００７１】
ここで、先に図７（ｂ）に示したＰｌａｙ Ｆｒｏｍ及びＰｌａｙ Ｔｏは、例えば図８（ａ）において、矢印ｃ，ｄで示すように、そのトラックの開始位置及び終了位置となるコンテンツデータの再生時間を示す。
つまり、本実施の形態でいうトラックは、コンテンツデータ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の一部データにより形成することができるようになっている。もちろんのこと、Ｐｌａｙ Ｆｒｏｍがコンテンツデータの再生時間“０”を示し、Ｐｌａｙ Ｔｏがコンテンツデータにおいて、図８（ａ）に矢印ｅで示す終端位置の時間を示すのであれば、トラックとしては、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの全部分のコンテンツデータとされることになる。
【００７２】
図８（ｂ）は、１つのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが有する情報内容例を示している。
先ず、ＥＳ Ｏｆｆｓｅｔ Ｓｉｚｅは、現ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが対応するＡＶ Ｓｔｒｅａｍ ＦｉｌｅのＥＳ Ｏｆｆｓｅｔについてのデータサイズを示す。
また、本実施の形態の場合、詳しいことは後述するが、例えばＡＶデータに対する分割編集処理などによって、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいて複数のトラックが存在するようにして管理される場合が生じる。この場合、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対して、複数の参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒが存在することになる。つまり、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応して参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ数は、変わり得るものとなる。
Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒは、この参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒの数を示す。例えばＲｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒの示す値が“２”であれば、このＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒの数は２であることになる。そしてこれは、そのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいて２つのトラックとしてのデータ部分が存在していることを示している。
【００７３】
Ｅｒａｓｅ Ｆｌａｇは、そのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、「トラック消去」によって消去されたトラックが存在する場合に立つフラグが格納される。詳細については後述するが、「トラック消去」は、編集処理として、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ上での書き換えによりトラック消去を行う処理であり、逆にいえば、ＦＡＴファイルシステムの書き換えは行わない。つまり、ＡＶ Ｔｒａｃｋ ＩｎｄｅｘＦｉｌｅ上で消去されたとみなされるものであって、ＦＡＴファイルシステム上では、このトラック消去されたデータ部分を含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅそのものがディスクに記録されているものとして管理されている。
【００７４】
Ｔｏｔａｌ Ｐｌａｙ Ｔｉｍｅは、そのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの総再生時間を示す。つまり、図８（ａ）において矢印ｅにより示す終端の再生時間を示す。
なお、このような構造及び情報内容を有するＡＶ Ｈｅａｄｅｒ Ｆｉｌｅであれば、上記した情報内容は、それぞれ所定のバイト数を割り当てるようにして固定長とすることが可能である。つまり、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅとしても固定長とすることができる。ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが固定長であれば、例えば既にディスクに記録済みとされているＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを更新する場合においてもそのサイズは変化しないから、例えば、１つのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを形成する複数のデータ部分が、ディスク上において物理的に離散して記録されるようなことにはならない。これによっては、ＦＡＴによるＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの管理が、より単純なものになって、読み出し、アクセスなどが容易になるというメリットが得られる。このようにして、本実施の形態では、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについて固定長とすることによっても、ＦＡＴファイルシステムに対する処理負担を軽減している。
【００７５】
続いて、これまでの説明を踏まえて、図９を参照して、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対するトラック管理例について説明する。この図９に示すトラック管理は、最も単純な例であり、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅが１つのトラックとして管理される場合を示している。例えば、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅをディスクに記録する場合において、特に、その途中でトラック分割などのマーキング操作を行わなければ、このようなＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとトラックの関係が得られる。
【００７６】
先ず、図９（ｂ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、ここでは、ＭＰ０００００７．ＶＳＦというファイル名及び拡張子であるとする。つまり、拡張子ＶＳＦにより、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅであることが示された上で、このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、ＭＰ０００００７というファイル名によって特定されることになる。
そして、このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、データ開始位置から１ＫバイトのＥＳ Ｏｆｆｓｅｔの領域を有するものとされ、これに続けて総再生時間“１００”のコンテンツデータが配置されてディスクに記録されていることとする。
【００７７】
このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応付けられたＡＶ Ｈｅａｄｅｒ Ｆｉｌｅは、図９（ｃ）に示される。このＡＶ Ｈｅａｄｅｒ Ｆｉｌｅは、ＭＰ０００００７．ＶＨＦというファイル名及び拡張子を有している。拡張子ＶＨＦにより、このファイルはＡＶ Ｈｅａｄｅｒ Ｆｉｌｅであることが示され、さらに、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおいて、ＭＰ０００００７というファイル名によって特定がされることになる。
そして、図９（ｂ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅと、図９（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅは、拡張子以外のファイル名部分である「ＭＰ０００００７」が同一であり、これによって、両者の対応付けが行われているものである。
なお、確認のために述べておくと、ＡＶ Ｓｔｒｅａｍ ＦｉｌｅとＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのファイル名（＋拡張子）は、ＦＡＴファイルシステムによる管理の下で与えられるものである。
【００７８】
そして、図９（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおいて、ＥＳ Ｏｆｆｓｅｔ Ｓｉｚｅは、図９（ｂ）のＡＶ Ｓｔｒｅａｍ ＦｉｌｅのＥＳ Ｏｆｆｓｅｔが１Ｋバイトであることに対応して、この１Ｋバイトを示す１０００が格納される。
また、Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒは、１とされており、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒは１つであることが示される。
また、Ｅｒａｓｅ Ｆｌａｇは、０となっており、これは、図９（ｂ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（コンテンツデータ）について、「トラック消去」によって消去されたトラックは存在していないことを示している。
また、Ｔｏｔａｌ Ｐｌａｙ Ｔｉｍｅは、図９（ｂ）に示すコンテンツデータの終端の再生時間が“１００”であることに対応して、１００が格納されている。
【００７９】
そして、図９（ａ）に示すＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ内のＴｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅにおいて、図９（ｂ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応して参照すべき１つのＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎが示されている。
このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎのＴｒａｃｋ Ｆｉｌｅ ＩＤは、図では７が記載されているが、これは、図９（ｂ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅと、図９（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅで共通となっているファイル名「ＭＰ０００００７」における「０００００７」を示している。つまり、この場合のＴｒａｃｋ Ｆｉｌｅ ＩＤとしては、ファイル名としてＡＶ Ｓｔｒｅａｍ ＦｉｌｅとＡＶ Ｈｅａｄｅｒ Ｆｉｌｅに対して共通に与えられた数値を示すこととしており、これによって、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ、及びＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒとの対応関係を特定する仕組みとしている。
【００８０】
また、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎのＰｌａｙ Ｆｒｏｍは、コンテンツデータの再生時間“０”を示す、０が格納される。また、Ｐｌａｙ Ｔｏは、コンテンツデータの終端の再生時間“１００”に対応する１００が格納される。このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎのＰｌａｙ Ｆｒｏｍ、Ｐｌａｙ Ｔｏを参照するによっては、図９（ｂ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータは、その開始位置（再生時間“０”）から終了位置（再生時間“１００”）まで、１つのトラックとして再生されるべきであることが分かる。
【００８１】
また、ここでのＣＯＤＥＣ Ｉｎｆｏｒｍａｔｉｏｎは、ｔｙｐｅＸであることとして、実際には、所要のコーデックに関する情報を格納しているものとされる。
【００８２】
続いては、図１０のフローチャートを参照して、ｎ番目に再生すべきトラックを再生するための処理動作について説明する。なお、この図に示す処理は、本実施の形態の記録再生装置１のシステムコントローラ８が実行する。
先ず、システムコントローラ８は、ステップＳ１０１により、トラック再生指示が得られるのを待機している。そして、例えばユーザの操作部７に対する操作などによって、ｎ番目に再生すべきトラックの指定と共に、再生開始の指示が行われ、これに応じたコマンドが発生したとされるとステップＳ１０２以降の処理に進むことになる。
【００８３】
ステップＳ１０２では、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの読み込みを実行する。なお、この読み込みは、ディスクから読み出しを行うようにしてもよいが、ＲＡＭ１０から読み込むようにすればよい。つまり、ディスク装填時において、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅをディスクから読み出してＲＡＭ１０に保持させておくようにして、以降は、このＲＡＭ１０にアクセスして、必要に応じてＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの読み込みを行うようにするものである。このようにすれば、逐一ディスクにアクセスする必要が無くなって、それだけ短時間で処理を実行することができる。
【００８４】
次のステップＳ１０３では、読み込みを行ったＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ ＦｉｌｅにおけるＰｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅを参照して、再生順がｎ番目となっているＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒのナンバを特定する。このためには、例えばＰｌａｙ Ｏｒｄｅｒ Ｔａｂｌｅの格納位置Ｐ１から順次スキャンしていき、ｎ番目にヒットしたＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒナンバを参照すればよい。
【００８５】
そして、次のステップＳ１０４では、先ず、上記ステップＳ１０３により特定されたナンバのＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒに格納されているＴｒａｃｋ Ｆｉｌｅ ＩＤを認識する。そして、この認識したＴｒａｃｋ Ｆｉｌｅ ＩＤに対応するファイル名が与えられているＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ及びＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを特定する。
【００８６】
ステップＳ１０５においては、上記ステップＳ１０４にて特定したＡＶ Ｈｅａｄｅｒ Ｆｉｌｅに格納されているＥＳ Ｏｆｆｓｅｔ Ｓｉｚｅを参照することで、同じく上記ステップＳ１０４にて特定したＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの再生開始位置を特定する。つまり、コンテンツデータの開始位置である再生時間“０”の位置を特定するものである。
【００８７】
続くステップＳ１０６においては、先のステップＳ１０４にて特定したＡＶ Ｈｅａｄｅｒ Ｆｉｌｅに格納されているＰｌａｙ Ｆｒｏｍの値を認識する。そして、上記ステップＳ１０５にて特定したコンテンツデータの再生時間“０”の位置を基点として、Ｐｌａｙ Ｆｒｏｍの時間分シフトした再生時間位置にアクセスする。そして、このアクセスした再生時間位置から、コンテンツデータの再生を開始する。
【００８８】
そして、ステップＳ１０７においては、先のステップＳ１０４にて特定したＡＶＨｅａｄｅｒ Ｆｉｌｅに格納されているＰｌａｙ Ｔｏの値を認識した上で、このコンテンツデータの再生時間“０”の位置を基点として、Ｐｌａｙ Ｔｏの時間分シフトした再生時間位置を認識する。そして、このＰｌａｙ Ｔｏの時間が示すとされる再生時間位置までの再生が終了するのを待機する。
そして、Ｐｌａｙ Ｔｏの時間が示すとされる再生時間位置までの再生が終了したとされると、ｎ番目のトラックを完全に再生終了したこととなって、例えばステップＳ１０８により再生終了処理を実行する。
このようにして、本実施の形態では、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容を参照することで、トラック単位によるデータ管理、及び再生制御が可能であることが分かる。これは即ち、トラック単位によるデータ管理、及び再生制御を実行するのにあたり、ＦＡＴファイルシステムのレベルでの管理情報内容を使用するのではなく、このＦＡＴファイルシステムにより管理されるインデックス情報ファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ）及びヘッダファイル（ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ）などを使用する構成となっていることを意味する。
【００８９】
４．トラック分割、消去編集
上記したトラック管理の下では、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容を変更することによって、トラック単位での編集を行うことが可能とされる。ここでは、このような編集処理として、トラックの分割編集、及びトラック消去編集について説明する。
【００９０】
先ず、トラック分割編集について説明する。
ここで、トラック分割編集前のトラックの管理状態としては、先に図９に示したとおりであるとする。つまり、図９（ｂ）に示すファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、１つのトラックとして管理されている状態である。以降においては、この図９（ｂ）に示されるファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、トラック分割、及びトラック消去の各編集を行う場合について説明する。
【００９１】
そして、上記図９（ｂ）に示すようにして１トラックとして管理されるＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、図１０（ｂ）に示すようにしてトラック分割を行ったとする。つまり、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータにおいて、再生時間“０”〜“８０”までのデータ部分から成るトラックと、再生時間“８０”〜“１００”までのデータ部分から成るトラックとに分割したものとする。なお、ここでは、前者をトラック＃ｎ、後者をトラック＃ｍということにする。
【００９２】
そして、上記のようにして分割編集されたものとして管理が行われるようにするためには、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ ＦｉｌｅとＡＶ Ｈｅａｄｅｒ Ｆｉｌｅとについて、それぞれ、図９（ａ）（ｃ）から図１１（ａ）（ｃ）に示すようにして内容を変更することになる。
先ず、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについては、図１１（ｃ）に示すようにして、Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒの値について１から２となるように変更され、これにより、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒが２つ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅが含むトラックが２つ）であることを示すようにされる。なお、ここまでの段階でのファイル名＝ＭＰ０００００７．ＶＳＦのＡＶＳｔｒｅａｍ Ｆｉｌｅについて、ＥＳ Ｏｆｆｓｅｔのサイズ及びコンテンツの終端の再生時間が“１００”であることに変わりはないから、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにおけるＥＳ Ｏｆｆｓｅｔ Ｓｉｚｅ及びＴｏｔａｌ Ｐｌａｙ Ｔｉｍｅの値は変化しない。さらに、Ｅｒａｓｅ Ｆｌａｇについても、ここまでの段階では、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータにおいて、消去されたトラックは存在しないから、０のまま変わらない。
【００９３】
そして、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅにおいて、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ及びＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのファイル名に対応する、Ｔｒａｃｋ Ｆｉｌｅ ＩＤを有するＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒを参照すると、例えば図１１（ａ）に示すようにして、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎ，＃ｍの２つが存在していることになる。このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒの数は、図１１（ｃ）に示したＲｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒの値である２と一致している。つまり、トラック分割によってトラックが１つ増えるのに対応して、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎに、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍが追加されているものである。
【００９４】
Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎは、コンテンツデータにおける再生時間“０”〜“８０”までのデータ部分によるＴｒａｃｋ ＃ｎについて定義しているものとなる。そして、この場合においては、図９（ａ）に示したＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎについて、下記のようにして必要な情報を書き換えることで得られたものとされる。
先ず、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎにおけるＴｒａｃｋ Ｆｉｌｅ ＩＤは、図９（ａ）と同様に、７を示している。これにより、このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎが、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ内のトラックについて記述したものであることが特定される。
そして、Ｐｌａｙ Ｆｒｏｍ及びＰｌａｙ Ｔｏは、それぞれ０、８０を示すことで、図１１１１に示すトラック＃ｎとしてのデータ部分の再生開始時間が“０”、再生終了時間が“８０”であることを示すようにされる。従って、ここではＰｌａｙ Ｔｏの値が書き換えられていることになる。
なお、ＣＯＤＥＣ Ｉｎｆｏｒｍａｔｉｏｎは、ＴｙｐｅＸを示すという点では同じである。ただし、例えば再生時間に関する情報などは、必要に応じて、そのトラックごとに対応した内容に変更される場合がある。
【００９５】
また、分割編集に応じて新たに生成されたＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍは、コンテンツデータにおける再生時間“８０”〜“１００”までのデータ部分によるＴｒａｃｋ＃ｍについて定義する。
Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎにおけるＴｒａｃｋ Ｆｉｌｅ ＩＤも７を示すことになる。つまり、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍも、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ内のトラックについて記述したものであることが特定される。
また、Ｐｌａｙ Ｆｒｏｍ及びＰｌａｙ Ｔｏは、それぞれ８０、１００を示し、Ｔｒａｃｋ ＃ｍについての、コンテンツデータの再生開始位置（再生時間“０”）を基点とした、再生開始時間と再生終了時間を示すようにされる。
このように、図１１（ａ）（ｃ）に示すＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容とすることによって、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅが図１１（ｂ）に示すようにしてトラック分割されるように管理する。
【００９６】
続いては、図１２（ｂ）に示すようにして、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、トラック＃ｎを消去する編集を行って、結果的にトラック＃ｍを残すという場合を考えてみる。
なお、確認のために述べておくと、ここでの消去は、あくまでも、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによってトラックを消去したものとして管理するものであって、ＦＡＴファイルシステムによって、ディスクに実際に記録されているデータ部分を消去するものではない。つまり、ユーザインターフェイス上は、消去したものとしてみえるが、ＦＡＴファイルシステム上で消去したとして管理していない以上、ディスクから消去されてはいないものである。
本明細書では、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによって管理される消去を「トラック消去」といい、ＦＡＴファイルシステム上で管理される消去については、「ディスク上消去」ということにしている。
【００９７】
そして、図１２（ｂ）に示すようにしてトラック消去されたものとして管理されるためには、先ず、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ ＦｉｌｅにおけるＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒとしては、図１２（ａ）に示すようになる。
つまり、トラック＃ｎを消去することに応じて、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶＳｔｒｅａｍ Ｆｉｌｅに対応するＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒのうち、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎは削除され、Ｔｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍのみが存在することとなる。このＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍの内容については、図１１（ａ）におけるＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍと同様である。
【００９８】
また、このトラック消去編集に応じて、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容は、図１１（ｃ）から図１２（ｃ）に示すようにして更新される。つまり、Ｒｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒは２から１となって、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒの数（ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ内のトラック数）が１になったことを示すようにされる。
そして、この段階では、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、トラック消去されたトラックが存在していることになるから、Ｅｒａｓｅ Ｆｌａｇが立つこととなって、その値は０から１に書き換えられることになる。
【００９９】
ところで、上記図９、及び図１１、図１２により説明したようにして、本実施の形態ではトラック分割、トラック消去の編集が可能とされるが、このような編集処理にあってはいわゆるアンドゥといわれる、編集前の状態に戻すことが可能なように構成されることが、例えばユーザにとっての利便性などを考慮すると好ましい。
本実施の形態において、トラック分割、及びトラック消去についてのアンドゥは可能であり、例えば次のようにして実行させることができる。
【０１００】
先ず、トラック分割のアンドゥについて、再度図９及び図１１を例に説明する。
先ず、アンドゥを可能とすることを前提とした場合には、編集対象となっているＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応するＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容について、編集処理前の内容を、例えばＲＡＭ１０上の所定の待避領域に待避させるようにして保持しておくようにされる。
従って、図９から図１１に示すようにしてトラック分割のための編集を行ったとした場合においては、図９（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎと、図９（ｃ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容を、上記待避領域に保持しておくことになる。
【０１０１】
そして、このトラック分割のアンドゥを実行するとした場合には、先ず、図１１（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎ，＃ｍの２つのＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒを、ＡＶ ＴｒａｃｋＩｎｄｅｘ Ｆｉｌｅから削除し、かわりに、待避領域に保持させておいた図９（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎを、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅに格納する。
また、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについても、図１１（ｃ）に示す内容から、待避領域に保持させておいた、図９（ｃ）に示す内容に書き換えを行うようにされる。
このような処理を実行することで、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅは、図１１（ａ）（ｃ）から図９（ａ）（ｃ）に示す内容に変更されることとなり、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータは、１つのトラックとして管理されることになる。つまり、トラック分割編集についてのアンドゥが行われたことになる。
なお、上記したトラック分割編集のアンドゥに際して、図１１（ａ）（ｃ）に示す内容のＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを待避領域に保持させておくようにすれば、さらに、図９に示す管理状態から、図１１に示されるトラック分割後の管理状態にアンドゥさせることが可能である。
【０１０２】
また、図１２に示すトラック消去が行われた状態から、図１１に示す状態となるようにアンドゥを実行する場合も、上記と同様にすればよい。
つまり、先ずは、図１１に示す管理状態から図１２に示す管理状態となるようにしてトラック消去を実行した際において、図１１（ａ）（ｃ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎ，＃ｍ、及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを、待避領域に保持させる。
そして、アンドゥを実行する際には、図１２（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｍをＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅから削除し、かわりに、待避領域に保持させておいた図１１（ａ）に示すＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒ＃ｎ，＃ｍを、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅに格納する。
また、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについて、図１２（ｃ）に示す内容から、待避領域に保持させておいた、図１１（ｃ）に示す内容に書き換えを行うようにされる。
この結果、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによる、ファイル名＝ＭＰ０００００７．ＶＳＦのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの管理は、図１２（ａ）（ｃ）から図１１（ａ）（ｃ）に示す内容に変更され、トラック削除編集についてのアンドゥが行われたことになる。
【０１０３】
５．ディスク上消去
続いては、ファイルシステム上で、トラックに相当するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分を削除する、ディスク上消去の処理について説明を行うこととする。
本実施の形態では、これまでの説明から分かるように、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（コンテンツデータ）は、ＦＡＴファイルシステムによる管理と、このＦＡＴファイルシステム下での、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ（インデックス情報）による管理とが行われる。ここで、着目すべきことは、ディスクに記録されるデータについて、ＦＡＴファイルシステムによるデータ管理単位のサイズと、コンテンツデータとして管理する場合のデータ管理単位のサイズには、相違を有することである。先ず、この点について図１３１３を参照して説明しておく。
【０１０４】
図１３は、ある１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツデータのデータ管理単位と、ファイルシステムのデータ管理単位との関係を概念的に示している。
先ず、図１３（ａ）に示すように、コンテンツデータとして、領域Ａによる１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅがあるとして、このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対するコンテンツのデータ管理単位は、図１３（ｂ）に示すようにして、Ａ〜Ｊの１０のデータ管理単位により等分割することとする。
これに対して、ＦＡＴファイルシステムのデータ管理単位は、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを、Ａ〜Ｄの４等分に分割しているものとする。
なお、図１３（ｂ）に示すコンテンツのデータ管理単位は、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの仕様によって決定されるインデックス単位となる。また、図１３（ｃ）に示すＦＡＴファイルシステムのデータ管理単位は、例えばクラスタ単位となる。
【０１０５】
そして、上記のように説明した図１３は、次のようなことを意味する。
先ず、図１３（ａ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（Ａ）としてのコンテンツデータについて、トラック分割、トラック消去を行う場合には、図１３（ｂ）に示すコンテンツのデータ管理単位Ａ〜Ｊにおける境界位置のいずれかを分割位置、消去位置とすることになる。
これに対して、例えばＦＡＴファイルシステム上での管理により、ディスク上消去を行おうとした場合には、図１３（ｃ）に示すファイルシステムのデータ管理単位Ａ〜Ｄにおける境界位置の何れかを、消去されるデータ部分の境界位置とすることになる。
そして、図１３（ｂ）（ｃ）を比較すれば、コンテンツのデータ管理単位の境界位置と、ファイルシステムのデータ管理単位との境界位置とは必ずしも一致していないことがわかる。
例えばこの図では、説明の便宜上、ファイルシステムのデータ管理単位のサイズを、コンテンツのデータ管理単位のサイズの２．５倍としているのであるが、この場合には、ファイルシステムのデータ管理単位Ｂ，Ｃの境界は、コンテンツのデータ管理単位Ｅ，Ｆの境界と一致はしているものの、ファイルシステムのデータ管理単位Ａ，Ｂ、及びＣ，Ｄの境界は、コンテンツのデータ管理単位Ｃ，Ｈ内に含まれるような状態で、ずれが生じている。また、コンテンツのデータ管理単位Ｂ，Ｄ，Ｇ，Ｉなどは、ファイルシステムのデータ管理単位のブロック内に収まっている。
【０１０６】
そして、上記図１３に示す状態から、領域ＡのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、図１４（ａ）に示すようにして領域Ａ−１，Ａ−２の各データ部分に分割することで、トラック＃ｎ，＃ｍの２つのトラックとなるようにトラック分割編集を行ったとする。この場合には、図１４（ｂ）におけるコンテンツのデータ管理単位Ｇ，Ｈの境界位置によりトラック分割編集を行っている。
なお、確認のために述べておくと、図１４（ｂ）（ｃ）には、図１３（ｂ）（ｃ）と同一のパターンが示されている。
【０１０７】
そして、上記図１４に示すようにして分割編集を行った後において、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（Ａ）から、領域Ａ−１に対応するトラック＃ｍについてディスク上消去を行うとした場合を、図１５により説明する。
ここで仮に、トラック＃ｍをディスク上消去するために、図１５（ａ）に示される、全体領域ＡとされるＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおける領域Ａ−１を完全に、ＦＡＴの書き換えにより消去することを考えてみる。すると、領域Ａ−１，Ａ−２の境界は、図１５（ｃ）に示すファイルシステムデータ管理の境界とは一致しておらず、ファイルシステムデータ管理Ｃのブロック内に在る。
従って、領域Ａ−１を完全にディスク上消去しようとすれば、ファイルシステム管理単位Ａ，Ｂ，Ｃの連続した３ブロック分に対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分を消去することになる。しかしながら、コンテンツのデータ管理単位Ｃのブロックは、図１５（ｂ）に示すコンテンツのデータ管理単位Ｈの前半を含んでいる。つまり、図１５（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａ−２における、コンテンツのデータ管理単位Ｈの前半のデータ部分もディスク上消去されてしまうことになる。
【０１０８】
このため、トラック＃ｍに相当するデータ部分をディスク上消去しようとする場合には、領域Ａ−２の冒頭部分の消去を避けるために、ファイルシステム管理単位Ａ，Ｂの連続した２ブロック分に対応したＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分をを消去することになる。
これにより、図１３（ａ）において領域Ａ−３が、ＦＡＴの書き換えによってディスクから消去されることになる。しかし、領域Ａ−１において、領域Ａ−３に続く領域Ａ−４としてのデータ部分が残ってしまうことになる。この領域Ａ−４は、図１５から分かるように、ファイルシステム管理単位Ｃの先頭位置から開始され、コンテンツのデータ管理単位Ｇ，Ｈの境界位置で終了するデータ部分となる。
【０１０９】
このようにして、コンテンツのデータ管理単位によりトラック分割（或いはトラック消去）されたトラックについてディスク上消去を行う場合には、そのトラックとしてのデータ部分の終端部分で、実際には、ディスク上において消去されずに残ることがある。
このような場合には、実際にディスク上で消去されたとされるデータサイズと、ユーザ側からディスク上で消去したように見えるデータサイズの間に、領域Ａ−４分の差分が生じる。そして、このような差分となるデータ部分は、ディスク上消去が実行される回数に応じて増加することにもなるので、実際にディスク上で消去されたデータサイズと、ユーザ側からディスク上で消去したように見えるデータサイズの誤差は拡大していくことになってしまう。
そこで、このような不都合を回避するために、本実施の形態では、図１５（ａ）に示すように、この領域Ａ−４を、後に続く領域Ａ−２の先頭に付加されるＥＳＯｆｆｓｅｔとして扱うようにされる。従って、この図１５に示すディスク上消去の結果、図１５（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとして、ディスクに記録されているものとしてＦＡＴファイルシステム上で管理されるのは、領域Ａ−４（ＥＳ Ｏｆｆｓｅｔ）＋領域Ａ−２で表される領域となる。
【０１１０】
これまでの説明によると、本実施の形態では、前提として、ディスクに記録されるデータは、ＦＡＴファイルシステムによって管理される。そのうえで、コンテンツデータ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）のトラック分割、トラック消去編集はＦＡＴの書き換えに依存することなく、このＦＡＴにより管理されるデータファイル（ＡＶＴｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）の内容を書き換えることで以て行うことが可能となっている。
例えば、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）の書き換えによるトラック分割、トラック消去編集を行わず、ＦＡＴの書き換えのみに依存して、コンテンツデータ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の編集を行うこととした場合には、トラック分割、トラック消去編集の都度、ＦＡＴの書き換えが行われることになる。ＦＡＴの書き換えは、例えば、データファイルを操作する場合よりも重い処理となることから、それだけシステムの負担が大きくなる。このため、例えば編集処理の終了（ＦＡＴの書き換えの完了）に時間がかかることになってしまうという不都合が生じる。
これに対して本実施の形態のようにして、データファイルに対する書き換えによって編集が行えるようにすれば、編集の都度、ＦＡＴを書き換える必要はなくなるので、より軽い負担で編集処理を実行することができ、より迅速な編集処理動作を得ることが可能となる。
【０１１１】
ここで、上記したように、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ ＨｅａｄｅｒＦｉｌｅ等）の書き換えによるトラック分割、トラック消去が行われる環境の下で、例えばトラックとしてのデータ部分をディスク上消去（ＦＡＴの書き換え）によって消去することには次のような意味がある。
先ず、ＦＡＴの書き換えによりデータを積極的に消去する場合とは、不要なデータをユーザが任意に削除する場合であるということになるが、これは即ち、必要なデータのみがディスクに記録されるようにして、できるだけディスクの記録容量が節約できるようにすることを目的としている、ということがいえる。これは、本実施の形態に限ることなく、他の書き換え可能なメディアを使用する場合にもいえることである。
そして、本実施の形態においては、上記した記録容量の節約とも関わるものの、次のような意味合いも有している。
つまり、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）の書き換えによるトラック消去を行っただけでは、ＦＡＴ上では、トラック消去されたデータ部分はディスクに記録されているものとして管理されるから、トラック消去が行われれば、ユーザから見たコンテンツの総データサイズよりも実際にディスクに消去されずに記録されているコンテンツの総データサイズのほうが大きくなるようにして差が生じることになる。
【０１１２】
そして、トラック消去について回数を重ねていくと、ユーザから見た、データファイルにより管理される全トラックの総データサイズ（総再生時間）と、実際にディスクに消去されずに記録されている全コンテンツ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の総データサイズとの差は拡大していくことになる。このような差分の拡大が大きくなるのは、例えばユーザが思っている以上にディスクの記録済み容量が大きくなっており、あるときに、記録できると思ったコンテンツが容量不足で記録できなくなるなど、ユーザにとって好ましくない不都合を生じる原因となる。
そこで、例えばトラック消去により消去されたトラックをディスク上消去するようにすれば、上記したようなユーザ側とＦＡＴ管理上との間でのデータサイズの差分の問題を解消できることになる。
【０１１３】
このことから、例えば実際の記録再生装置のアプリケーションとしては、次のような自動のディスク上消去動作を考えることができる。
つまり、データファイルの書き換えによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックの総データサイズが一定以上となった場合、これは、データファイルによって管理される全トラックの総データサイズと、実際にディスクに消去されずに記録されている全コンテンツ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の総データサイズとの差が一定以上となったということになる。
そして、このような条件を満たした場合には、トラック消去されたデータ部分を対象として、必要とされるデータサイズ分のディスク上消去を実行するようにされる。
【０１１４】
図１６及び図１７のフローチャートは、上記のような自動のディスク上消去動作のための処理動作を示している。なお、この図に示す処理も、記録再生装置１のシステムコントローラ８が実行する。
【０１１５】
先ず、システムとしては、一定期間ごとに、データサイズチェックを行うこととしている。ここでいうデータサイズチェックとは、上記もしているように、データファイルによって管理される全トラックの総データサイズと、実際にディスクに消去されずに記録されている全コンテンツ（ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ）の総データサイズとの差をチェックするものとされる。
そして、システムにおいては一定時間間隔ごとに上記データサイズチェックのためのコマンドを内部で発生させることとしている。そして、システムコントローラ８は、図１６のステップＳ２０１の処理として、このデータサイズチェックのためのコマンドが得られるのを待機している。そして、このコマンドが取得されるとステップＳ２０２以降の処理に進む。
【０１１６】
ステップＳ２０２においては、ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ内のＴｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅを読み込む。そして、読み込んだＴｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅ内に格納されている各Ｔｒａｃｋ ＤｅｓｃｒｉｐｔｏｒのＰｌａｙ Ｆｒｏｍ−Ｐｌａｙ Ｔｏにより示される時間幅を認識し、これらのＰｌａｙ Ｆｒｏｍ−Ｐｌａｙ Ｔｏの時間幅を加算する。これにより、現在、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ，ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ）により管理される全トラックの再生時間を総計した総再生時間ａの値が算出される。
そして、例えば次のステップＳ２０３により、所定の演算規則に従って、上記総再生時間ａの値を、ディスク上に記録されているデータサイズｂの値に変換する。
【０１１７】
続いては、ステップＳ２０４により、ＦＡＴの読み込みを実行する。そして、次のステップＳ２０５において、読み込みを行ったＦＡＴを参照することで、ＦＡＴによりディスク上に記録されているものとして管理されている全てのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの総データサイズｃを算出する。
【０１１８】
そして、次のステップＳ２０６においては、上記ステップＳ２０３により得られた値ｂと、上記ステップＳ２０５により得られた値ｃとについて、ｃ−ｂが予め設定された一定値以上であるか否かについて判別する。
ここで、肯定結果が得られたのであれば、データファイルの書き換えによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックの総データサイズが一定以上となっているということになる。そこで、この場合には、ステップＳ２０７によるディスク上消去処理を実行する。このディスク上消去処理によっては、データファイルの書き換えによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分について、必要なデータサイズ分に応じた消去をトラック単位で実行することになる。
これに対して、ステップＳ２０６において否定結果が得られた場合には、このまま処理を終了し、再度、ステップＳ２０１の処理により次のデータサイズチェックコマンドが得られるのを待機することになる。
【０１１９】
そして、ステップＳ２０７におけるディスク上消去の処理は、例えば図１７に示す手順によって実行することができる。
図１７に示すディスク上消去処理としては、先ず、ステップＳ３０１において、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの読み込みを行い、読み込みを行ったＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのうちから、Ｅｒａｓｅ Ｆｌａｇ＝１となっているＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを検索する。
ここで、Ｅｒａｓｅ Ｆｌａｇ＝１となっているＡＶ Ｈｅａｄｅｒ Ｆｉｌｅを検索するということは、そのＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのファイル名を特定することになる。これは、データファイルによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分を含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを特定することを意味する。
【０１２０】
つまり、本実施の形態では、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにＥｒａｓｅ Ｆｌａｇを格納することで、データファイルによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分を含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅと、これを含まないＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとを区別して認識することが可能となるものである。
仮に、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにはＥｒａｓｅ Ｆｌａｇを格納しないこととすれば、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいて、データファイルによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分が存在するか否かについては、判断することができなくなる。つまり、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅから、データファイルによってトラック消去されてはいるが、ＦＡＴによっては消去されていないトラックとしてのデータ部分のみをディスク上消去しようとした場合にも、このようなデータ部分がＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに存在するかどうかを判断することができない以上、適正に実行することはできないことになる。
ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにはＥｒａｓｅ Ｆｌａｇを格納しない場合には、例えばＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを形成する全てのトラックについて、データファイルによるトラック消去が行われて、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅのＲｅｆｅｒｅｎｃｅ Ｃｏｕｎｔｅｒが０となったときにはじめて、そのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ全体をディスク消去することが可能となる。
【０１２１】
そして、次のステップＳ３０２においては、先ず、Ｔｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅの読み込みを実行し、このＴｒａｃｋ Ｉｎｆｏｒｍａｔｉｏｎ Ｔａｂｌｅに格納されるＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒのうちから、上記ステップＳ３０１において検索したＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのファイル名に対応するＴｒａｃｋ Ｆｉｌｅ ＩＤを格納したＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒを認識する。
【０１２２】
次のステップＳ３０３においては、上記ステップＳ３０２により認識したＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒと、先にステップＳ３０１により読み込みを行ったＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの内容に基づいて、各ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおけるトラック消去済みとされているデータ部分の再生時間幅を認識する。
このステップＳ３０３による再生時間幅認識のための処理を、図１８の模式図により説明する。
【０１２３】
ここで、トラック消去済みの（かつ、ディスク上消去（ＦＡＴ書き換え）による消去はされていない）データ部分を含むＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとして、図１８（ａ）（ｂ）（ｃ）に示す３つが存在しているとする。
ここでは仮に、図１８（ａ）（ｂ）（ｃ）に示す各ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応するＴｒａｃｋ Ｆｉｌｅ ＩＤは、それぞれ、Ｔｒａｃｋ Ｆｉｌｅ ＩＤ＝０，Ｔｒａｃｋ Ｆｉｌｅ ＩＤ＝１，Ｔｒａｃｋ Ｆｉｌｅ ＩＤ＝２であるとする。
先ず、図１８（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいては、コンテンツデータ全体の再生時間幅が“４００”とされるうち、トラック消去済みのデータ部分は、再生時間“１５０”〜“４００”の範囲となる領域Ｂであり、その再生時間幅は“２５０”となる。
また、図１８（ｂ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅでは、コンテンツデータ全体の再生時間幅は、図１８（ａ）と同じ“４００”とされる。しかし、トラック消去済みのデータ部分である領域Ｂは、この場合、再生時間“２５０”〜“４００”の範囲であるから、その再生時間幅は“１５０”となる。
さらに、図１８（ｃ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのコンテンツデータ全体の再生時間幅は“６００”とされる。そして、この場合のトラック消去済みのデータ部分は領域Ａ〜Ｅのうち、領域Ｂ，Ｄとなる。領域Ｂは、再生時間“２００”〜“３００”の範囲で、その再生時間幅は“１００”となる。領域Ｃは、再生時間“５００”〜“５５０”の範囲で、その再生時間幅は“５０”となる。
【０１２４】
ここで、例えば図１８（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応するＡＶ Ｈｅａｄｅｒ Ｆｉｌｅとしては、Ｔｏｔａｌ Ｐｌａｙ Ｔｉｍｅは、４００を示すことになる。また、図１８（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対応するＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒでは、領域Ａをトラックとして管理するための内容が格納され、そのＰｌａｙ Ｆｒｏｍ，Ｐｌａｙ Ｔｏは、それぞれ０、１５０を示すことになる。
そして、上記したＴｏｔａｌ Ｐｌａｙ Ｔｉｍｅ＝４００、Ｐｌａｙ Ｆｒｏｍ＝０，Ｐｌａｙ Ｔｏ＝１５０の情報から、トラック消去済みのデータ部分である領域Ｂの再生時間幅は、“２５０”（＝４００−１５０）であることが認識できることになる。
【０１２５】
そして、図１８（ｂ）（ｃ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅについても同様にして、対応するＡＶ Ｈｅａｄｅｒ ＦｉｌｅのＴｏｔａｌ Ｐｌａｙ Ｔｉｍｅと、参照すべきＴｒａｃｋ Ｄｅｓｃｒｉｐｔｏｒに格納されるＰｌａｙ Ｆｒｏｍ，Ｐｌａｙ Ｔｏの値を利用することで、トラック消去済みのデータ部分である各領域の再生時間幅を特定することができる。
【０１２６】
そして、上記のようにして、ステップＳ３０３において、トラック消去済みのデータ部分ごとの再生時間幅を認識した後は、次のステップＳ３０４によって、トラック消去済みのデータ部分について、再生時間幅順のリストを作成する。
このリストは、例えば図１９に示すものとなる。この図１９に示すリストは、トラック消去済みのデータ部分を含むＡＶ Ｈｅａｄｅｒ Ｆｉｌｅが、図１８（ａ）（ｂ）（ｃ）に示したものである場合を例にしている。
【０１２７】
図１９に示すリストは、リスト順ごとに対応して、トラック消去済みデータ部分を特定するアドレス的な情報と、その再生時間幅の情報を格納する構造を有している。ここでのトラック消去済みデータ部分を特定する情報としては、先ず、そのトラック消去済みデータ部分を含むＡＶ Ｈｅａｄｅｒ ＦｉｌｅのファイルＩＤ（Ｔｒａｃｋ Ｆｉｌｅ ＩＤ）と、そのトラック消去済みデータ部分についてのＰｌａｙ Ｆｒｏｍ／Ｐｌａｙ Ｔｏの値を格納することとしている。
【０１２８】
ここで、図１８（ａ）（ｂ）（ｃ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅのトラック消去済みのデータ部分のうち、、図１８（ａ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂが、再生時間幅“２５０”とされて、最も長い再生時間幅を有している。また、次に長いのは、図１８（ｂ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂの再生時間幅“１５０”である。さらに続いて、図１８（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂの再生時間幅“１００”、領域Ｄの再生時間幅“５０”となる。
【０１２９】
従って、図１９に示すリスト順１には、図１８（ａ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂについての情報が格納される。この場合、トラック消去済みデータ部分を特定する情報としては、ＩＤ＝０，Ｐｌａｙ Ｆｒｏｍ／Ｐｌａｙ Ｔｏ＝１５０／４００の情報が格納されることで、図１８（ａ）に示すＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂであることが特定される。また、再生時間幅の情報としては２５０が格納される。
以降、リスト順２〜リスト順４には、上記した再生時間幅順に従って、図１８（ｂ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂ、図１８（ｃ）のＡＶ Ｈｅａｄｅｒ Ｆｉｌｅにおける領域Ｂ、Ｄについての情報が格納される。
【０１３０】
次のステップＳ３０５においては、上記ステップＳ３０４により作成したリストの内容を参照して、リスト順に従って、トラック消去済みのデータ部分についてのディスク上消去を実行する。つまりは、必要なディスク上でのデータ消去量が得られるように、リスト順に従って、トラック消去済みのデータ部分についてのディスク上消去を実行する。
【０１３１】
ここで、例えば図１９に示すようにして作成されるリスト順により、トラック消去済みのデータ部分を、ディスク上消去していくということは、できるだけ再生時間幅が長い、つまり、ひとまとまりのデータサイズが大きい領域から消去していくということを意味する。
本実施の形態の記録再生装置１としては、ディスクに対するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの書き込みは、できるかぎり、ディスク上において物理的に連続するようにして行うようにされており、なるべく離散して記録されることが無いように配慮される。
これは、記録媒体がディスクであることから、離散記録されたデータにアクセスしながらストリームデータの記録再生を行うのは、アクセスタイム、及びシークタイムが必要となる関係上、システムに負担がかかることが理由となっている。
【０１３２】
このようなことを考慮すれば、トラック消去済みのデータ部分についてのディスク上消去によってディスクに空き容量を形成するとした場合にも、ディスク上において物理的にできるだけ長く連続した空き容量を形成することが好ましいということになる。
そこで、本実施の形態では、上記したように再生時間幅が最も長いトラック消去済みのデータ部分から、優先的にディスク上消去を実行することとしているものである。これにより、トラック消去済みのデータ部分についてのディスク上消去によっても、できるだけ長く連続した空き容量が得られるようにしている。
なお、ディスク上消去のリスト順を形成するのは、あくまでもトラック消去済みのデータ部分の再生時間幅に依るから、必ずしも、この再生時間幅を有するデータ部分が、そのまま、ディスク上における物理的な連続性を有しているとは限らず、ディスク上では離散的に記録されている可能性を有してはいる。
しかしながら、本実施の形態の記録再生装置１としては、先にも述べたようにして、先ずは、できるだけディスク上において物理的に連続した領域に１つのＡＶＳｔｒｅａｍ Ｆｉｌｅが記録されるようにして書き込みを実行することとしている。このため、上記した効果は相当に高い確率で得ることができるものである。
【０１３３】
６．ブロック暗号化されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのディスク上消去
また、本実施の形態の記録再生装置１では、図１にも示したようにして、例えば入出力処理部５内に、暗号化及び暗号復号化処理を実行する暗号処理部５ａを備える。つまり、本実施の形態において、ディスクに対して記録されるデータとしては、暗号化される場合があるということになる。
そして、暗号化のアルゴリズムの１つとしてブロック暗号化が知られているが、さらに、このブロック暗号化のモードの１つとしてＣＢＣモードが知られている。
ここでＣＢＣモードによる暗号化処理を簡単に述べておくと、次のようになる。
・平文データＤを同じデータ長のブロックｄ１，ｄ２，．．，ｄｎに分ける。
・上記のブロックと同じ長さのＩＶ（Ｉｎｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ）を用意する。
・ｄ１とＩＶの排他的論理和を暗号化し、これをｅ１とする。
・ｄ２とｅ１の排他的論理和を暗号化し、これをｅ２とする。
・ｄ３とｅ２の排他的論理和を暗号化し、これをｅ３とする。
・以下同様の処理を繰り返し、得られたｅ１、ｅ２、…をつなげたものを暗号文とする。
【０１３４】
そして、ここで暗号処理部５ａが、上記ＣＢＣモードによるブロック暗号化に対応した暗号化／復号化処理を実行可能であるとした場合における、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ、コンテンツのデータ管理単位、ＦＡＴファイルシステムのデータ管理単位、及びブロック暗号化単位の関係例を、図２０に示す。なお、この図に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する各単位の関係は、あくまでも説明の便宜のための概念的なものであって、必ずしも実際と同一ではない。
【０１３５】
そして、この図２０によると、図２０（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅは、全体で領域Ａを有している。そして、このＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａは、図２０R>０（ｂ）のコンテンツのデータ管理単位としては、管理単位Ａ〜Ｅの５つ分のサイズに相当することになる。
また、図２０（ｃ）に示すＦＡＴファイルシステムのデータ管理単位は、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａに対して、管理単位Ａ，Ｂと、これに続く管理単位Ｃの一部が対応するようになっている。また、図２０（ｂ）に示すコンテンツのデータ管理単位の２つ分のサイズが、１つのＦＡＴファイルシステムのデータ管理単位のサイズと同じになる関係を有している。
さらに、図２０（ｄ）に示すブロック暗号化単位は、８つ分で、１つのＦＡＴファイルシステムのデータ管理単位と同じサイズになる関係を有する。従って、４つ分であれば、１つのコンテンツのデータ管理単位と同じサイズとなる。
【０１３６】
そして、ここでは、図２０に示す分割位置により、図２０（ａ）のＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについて、領域Ａを領域Ａ−１と領域Ａ−２とに分割するようにしてトラック分割編集したとする。この分割位置は、図２０（ｂ）に示すように、コンテンツデータの管理単位Ｂ，Ｃの境界位置に対応する。また、この場合には、この分割位置は、図２０（ｃ）に示すファイルシステムのデータ管理単位Ａ，Ｂの境界とも一致している状態となっている。
さらに、この図に示す分割位置は、図２０（ｄ）に示すブロック暗号化単位Ａ，Ｂの境界にも対応している。
【０１３７】
そして、上記のようにしてＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのトラック分割を行ったところ、図に示すブロック暗号化単位のシーケンスにおいて、分割位置に対応する境界の直前のブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分は、ＩＶ（Ｉｎｔｉａｌｉｚａｔｉｏｎ Ｖｅｃｔｏｒ）として必要なデータを含むデータ部分であったとする。なお、この場合には、例えば図２０（ａ）に示すＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ全体を、暗号化ブロックのチェーン範囲としているものとする。
【０１３８】
そして、上記図２０に示すようにしてトラック分割編集した後において、例えば、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａ−１のデータ部分について、ディスク上消去を行ったとする。このような編集結果に対応する状態を図２１に示す。
この図から分かるように、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａ−１のデータ部分についてディスク上消去を行うということは、ファイルシステムのデータ管理単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分がディスク上から消去されるようにＦＡＴを書き換えるということである。
しかしながら、この場合において、単純に、ＦＡＴの書き換えによってファイルシステムのデータ管理単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分をディスクから消去したとすると、ブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分に含まれるＩＶも消去されてしまうこととなる。
このＩＶは、以降のブロック暗号化単位のデータ部分についての暗号復号化処理に必要な情報である。従って、このＩＶをそのままディスク上から消去してしまったのでは、以降の領域Ａ−２としてのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分について、適正に暗号復号化処理を施して再生出力することができなくなってしまう。
【０１３９】
従来における、上記のような不都合への対策として、例えば１つには、このブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分のように、ＩＶを含むとされるデータ部分については、ディスク上からの消去は行わずに残すということが行われている。
しかしながら、例えば図２０からも分かるように、ＩＶを含むブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分を、ディスクから消去しないように残そうとすれば、結局、ファイルシステムのデータ管理単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分をまるごとディスクから消去せずに残さなければならない。従って、この図の場合には、結局、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの領域Ａ−１としてのデータ部分は、ディスクから消去されずに残ってしまうことになる。
これは、実際においては、ＩＶを含むブロック暗号化単位のデータ部分を残すために、例えばこれよりデータサイズの大きなファイルシステムのデータ管理単位分のデータを残さなければならないことを意味する。つまり、この場合には、ディスク空き容量を有効に確保できないという問題を有することになる。
【０１４０】
また、対策の１つとして、ブロック暗号化単位Ａに対応するＡＶ Ｓｔｒｅａｍ Ｆｉｌｅのデータ部分のように、ＩＶを含む１ブロック暗号化単位のデータを、例えばディスク上において確保された所定の待避用のアドレス領域に書き込んでおき、そのＩＶが必要となった場合に、この待避用のアドレス領域からデータ読み出しを行って使用する、ということも行われている。
しかしながら、この場合には、ディスク上に、ＩＶのデータを待避させる領域を確保しなければならないために、その分、ユーザデータを書き込み可能なディスク容量が減少してしまうという不都合が生じる。また、待避用のアドレス領域と、ここに記録されるＩＶのデータをＦＡＴによって管理することになるので、ＦＡＴファイルシステムもそれだけ複雑になって、処理も重くなってしまうことにもなる。
【０１４１】
そこで、本実施の形態としては、図２２に示すようにして上記問題を解決することとしている。なお、図２２において、図２２（ａ）（ｂ）（ｃ）（ｄ）は、図２１（ａ）（ｂ）（ｃ）（ｄ）と同一であることから、ここでの説明は省略する。
図２２（ｅ）には、暗号化チェーン単位が示されている。この図２２（ｅ）に示す暗号化チェーン単位と、図２２（ｂ）に示すコンテンツのデータ管理単位とを比較して分かるように、ここでは、暗号化チェーン単位とコンテンツのデータ管理単位とについて同じとなるようにしているものである。
そして、この図に関しては、１つの暗号化チェーン単位は、図２２（ｄ）に示すブロック暗号化単位の４つ分に相当させることとしている。
つまり、本実施の形態では、少なくとも、１つの暗号化チェーン単位を、１つのコンテンツのデータ管理単位の範囲内に納めることとしているものである。その例として、図２２では、暗号化チェーン単位とコンテンツのデータ管理単位とについて同じとなるようにしているものである。従って、例えば２以上の暗号化チェーン単位を、１つのコンテンツのデータ管理単位の範囲内に納めるようにしても構わないことになる。なお、このような場合、全てのＩＶについて定数（例えば０）とすることになる。
【０１４２】
上記図２２に示す手法を採ることで、先に述べたように、ディスク消去時において、ＩＶを含むデータ部分についてはファイルシステムのデータ管理単位分により未消去としたり、また、ディスク上に設けた待避領域にＩＶを待避させる必要はなくなって、上記した問題は解決されることになる。
なお、図２２に示す手法を実現するのには、暗号処理部５ａについて、ディスクに記録すべきＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対して、上記図２２の説明に基づいて定められた所定のチェーン範囲によって暗号化処理を施すように構成すればよい。
【０１４３】
これまで説明してきた実施の形態については、次のようなことがいえる。
先ず、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとしてのコンテンツデータのトラック分割、トラック消去の編集としては、図６〜図１２により説明したように、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）の書き換えにより行うようにしている。これにより、本実施の形態としては、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとしてのコンテンツデータのトラック分割、トラック消去の編集までの段階では、ＦＡＴの書き換えに依存しないことになるので、ＦＡＴ書き換えのための処理負担が軽減され、例えばそれだけ高速な編集処理動作を得ることができる。
【０１４４】
また、そのうえで、図１５に示したようにして、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅについてディスク上消去を実行した場合において、このディスク上消去すべきデータ領域の終端部分について、消去されずに残る場合には、この消去されずに残ったデータ部分をＥＳ Ｏｆｆｓｅｔとして、このデータ部分に続くトラックデータ部分の先頭に付加してＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを形成することとしている。これにより、実際にディスク上で消去されたとされるデータサイズと、ユーザ側からディスク上で消去したように見えるデータサイズの間に生じる差分を解消することが可能となる。
つまり、これはファイルシステムによるファイル管理の下で、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）によりトラック管理を行う場合において、このような場合における不整合を解消し、より効率的なデータ管理が行われるようにしているということができる。
【０１４５】
さらに、本実施の形態では、図１７により説明したようにして、ＡＶ Ｈｅａｄｅｒ ＦｉｌｅにＥｒａｓｓｅ Ｆｌａｇを設けるようにしている。そして、このＥｒａｓｓｅ Ｆｌａｇの状態を見ることで、１つのＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいてトラック消去済みとされているデータ部分があるか否かを判定するようにしている。つまり、Ｅｒａｓｓｅ Ｆｌａｇを設けたことで、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅの一部であるとしても、ディスク上消去してもよいとされるデータ部分を適切に見つけだして、ディスクの空き容量を効率的に作り出していくことが可能とされているものである。
さらに、図１７及び図１８により説明したようにして、トラック消去済みのデータ部分のうちで、再生時間幅が長いものからディスク上消去していくようにし、できるだけ連続した空き容量が得られるようにしている。これによっては、上記したディスクの空き容量を、書き込み／読み出し効率を考慮して作り出していくことが可能となるものである。
そして、これらの手法を採ることによっても、ファイルシステムによるファイル管理の下で、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）によりトラック管理を行う場合において、より効率的なデータ管理を実現しているということがいえる。
【０１４６】
さらに、図２２により説明したようにして、暗号化チェーン範囲を規定することで、例えばＣＢＣモード等により暗号化されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅをトラック分割したデータ部分を消去するときにも、ＩＶを保存、待避させておく必要が無くなって、ＦＡＴ書き換え処理等の負担の軽減や、ディスク容量の節約が図られる。
つまり、このような手法も、同じく、ファイルシステムによるファイル管理下で、データファイル（ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ、ＡＶ Ｈｅａｄｅｒ Ｆｉｌｅ等）によりトラック管理を行うという構成を採る場合において、より効率的なデータ管理を行うことを目的として行われるものである。
【０１４７】
ところで、上記のようにして各図により説明してきた手法は、例えばシステムコントローラ８がプログラムを実行することによって実現される。このためのプログラムは、例えば記録再生装置１のＲＯＭ９に予め記憶して格納しておくものである。
【０１４８】
あるいは、プログラムは、フレキシブルディスク、ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）、ＭＯ（Ｍａｇｎｅｔ Ｏｐｔｉｃａｌ）ディスク、ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、磁気ディスク、半導体メモリなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。例えば、本実施の形態であれば、ディスク９０にプログラムを記録し、パッケージソフトウェアとして提供することができる。これにより、記録再生装置１では、ディスク９０を再生してプログラムを読み出し、ＲＯＭ９に記憶させることでインストールできる。
また、例えば、本実施の形態としての処理を実行させるプログラムを各種記録媒体に記憶させておけば、本実施の形態としての動作を、汎用のパーソナルコンピュータなどにインストールして実行させることが可能になる。
なお、プログラムは、上記のようなリムーバブルな記録媒体からインストールする他、プログラムを記憶しているサーバなどから、ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）、インターネットなどのネットワークを介してダウンロードすることもできる。
【０１４９】
また、本発明としてはこれまでに説明した構成に限定されるものではない。例えば、各図により説明した処理手順などは、実際に応じて適宜変更されてよい。また、本実施の形態において編集対象となっているＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ（ストリームデータ）は、ビデオデータであることとしているが、前述もしているように、そのフォーマットについてここでは特に限定されるものではない。また、ビデオデータ以外にも、例えば圧縮符号化フォーマットを含む、各種フォーマットによるオーディオデータなどとされてもよいものである。
また、ここでは、記録再生装置としては、ミニディスク（ＭＤ）方式のディスクに対応するものとしているが、これに限定されるものではなく、他の各種方式による記録可能なディスクメディアに対応する構成とされてよい。さらには、ファイルシステムによって管理される下で、データファイルによってトラック管理されるデータ管理構造を採るのであれば、ディスクメディア以外の他のメディアを対象として本発明を適用することも考えられる。
【０１５０】
【発明の効果】
以上説明したように本発明は、記録媒体に記録されるストリームデータを、ファイルシステムによってファイルとして管理するようにされる。これを前提として、ファイルシステムによって管理されるトラック管理用データファイルにより、ストリームデータをトラック単位で管理するようにされる。そして、トラック単位による分割、消去の編集（トラック分割、トラック消去）は、上記トラック管理用データファイルにおいて各トラックを規定するトラック管理情報の内容を書き換えることで実行される。
このような構成とされることで、トラック単位による分割、消去編集処理にあたっては、ファイルシステムを書き換える必要はないこととなって、それだけ、編集処理の負担は軽減され、例えばより高速な編集動作を得ることができる。
【０１５１】
また、ファイルシステムの書き換えによって、ファイルシステムのデータ管理単位に基づいて、ストリームデータを記録媒体から消去するときに、このファイルシステムのデータ管理単位に相当するデータ領域に、上記記録媒体からの消去対象であったデータ部分の一部が残る状態となった場合には、この残ったデータ部分の一部をオフセット領域として、ストリームデータの実体の先頭に付加する。そして、このオフセット領域＋ストリームデータの実体が、新規なストリームデータのファイルとして管理されるようにする。
これにより、実際にディスク上で消去されたとされるデータサイズと、ユーザ側からディスク上で消去したように見えるデータサイズの間に生じる差分が解消される。
【０１５２】
さらに本発明では、トラック消去情報（Ｅｒａｓｓｅ Ｆｌａｇ）を規定して、このトラック消去情報の状態を見ることで、１つのストリームデータのファイルにおいて、トラック消去編集が行われたデータ部分があるか否か判定し、このデータ部分の消去が行えるようにしている。これにより、例えばストリームデータのファイルの一部であっても、不要とされるデータ部分を適切にディスク上から消去して、ディスクの空き容量を効率的に得ていくことができる。
【０１５３】
さらには、トラック管理情報によりトラック単位でストリームデータを管理するための最小データ単位（コンテンツのデータ管理単位）の範囲内において、暗号ブロックをチェーン化する範囲が収まるようにして暗号化処理を実行するように構成される。これにより、暗号化されたストリームデータのファイルをトラック分割したデータ部分を消去するときにも、例えばＩＶなどの暗号化に必要となる情報を保存、待避させておく必要が無くなって、ファイルシステム書き換えのための処理等の負担を軽減し、ディスク容量の節約を図ることができる。
【０１５４】
このようにして、本発明としては、先ず、ファイルシステムによるファイル管理下で、データファイルによりトラック管理を行うという構成を採ることで処理負担の軽減効果などを得ており、さらにこのような構成を採る場合において、記録媒体に記録されるデータについて、より効率的な管理が行われるようにされるものである。
【図面の簡単な説明】
【図１】本発明の実施の形態の記録再生装置の構成例を示すブロック図である。
【図２】実施の形態のディスクのフォーマットの説明図である。
【図３】実施の形態のディスクのエリア構造の説明図である。
【図４】実施の形態のディスクの管理構造の説明図である。
【図５】実施の形態の記録再生装置のストレージ部のブロック図である。
【図６】実施の形態におけるディスク上でのファイル構成例を概念的に示す説明図である。
【図７】実施の形態のＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅの構造例を示す説明図である。
【図８】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅの構造例を示す説明図である。
【図９】ＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅと、ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅとの関係を示す説明図である。
【図１０】トラック再生のための処理動作を示すフローチャートである。
【図１１】トラック分割編集に対応するＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによるトラック管理例を示す説明図である。
【図１２】トラック消去編集に対応するＡＶ Ｔｒａｃｋ Ｉｎｄｅｘ Ｆｉｌｅ及びＡＶ Ｈｅａｄｅｒ Ｆｉｌｅによるトラック管理例を示す説明図である。
【図１３】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツのデータ管理単位、及びファイルシステムのデータ管理単位の関係例を示す説明図である。
【図１４】トラック分割されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツのデータ管理単位、及びファイルシステムのデータ管理単位の関係例を示す説明図である。
【図１５】ディスク消去時におけるＥＳ Ｏｆｆｓｅｔの設定例を示す説明図である。
【図１６】ディスク上消去開始のための処理動作を示すフローチャートである。
【図１７】ディスク上消去のための処理動作を示すフローチャートである。
【図１８】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅにおいてトラック消去された領域の再生時間幅を説明するための説明図である。
【図１９】図１７に示す処理において作成されるリストのデータの構造例を示す説明図である。
【図２０】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツのデータ管理単位、ファイルシステムのデータ管理単位、及びブロック暗号化単位の関係を示す説明図である。
【図２１】暗号化されたＡＶ Ｓｔｒｅａｍ Ｆｉｌｅを分割して形成したトラックをトラック消去した場合において、ＩＶがトラック消去の対象データ部分となる事例を示す説明図である。
【図２２】ＡＶ Ｓｔｒｅａｍ Ｆｉｌｅに対する、コンテンツのデータ管理単位、ファイルシステムのデータ管理単位、ブロック暗号化単位、暗号チェーン化単位の関係を示す説明図である。
【符号の説明】
１ 記録再生装置、２ ストレージ部、３ キャッシュメモリ、４ ＵＳＢインターフェース、５ 入出力処理部、５ａ 暗号処理部、６ 表示部、７ 操作部、８ システムコントローラ、９ ＲＯＭ、１０ ＲＡＭ、１１ キャッシュ管理メモリ、１２ ＮＶ−ＲＡＭ、１００ パーソナルコンピュータ／ネットワーク
【特許請求の範囲】
【請求項１】
所定の記録媒体に記録されるストリームデータを、ファイルシステムに基づくファイル単位で管理する第１のデータ管理手順と、
上記ファイル単位のストリームデータの範囲内におけるデータ部分をトラックとし、上記トラックごとに対応する情報であって、上記ファイル単位のストリームデータとの対応を示す情報要素と、対応する上記ファイル単位のストリームデータにおけるそのトラックのデータ位置を示す情報要素とを有して形成されるトラック管理情報を含むトラック管理用データファイルに基づいて、トラック単位での管理を行う第２のデータ管理手順とを実行するものとされ、
上記ファイル単位のストリームデータを分割して複数トラックを形成するトラック分割、又はトラックを消去するトラック消去を行う場合には、上記第２のデータ管理手順が、上記トラック分割又はトラック消去の態様に応じて、上記トラック管理用データファイルにおけるトラック管理情報の内容について更新処理を実行するようにされている、
ことを特徴とするデータ編集方法。
【請求項２】
上記第１のデータ管理手順は、
１ファイルとしてのストリームデータについて、先頭にオフセット領域を設け、このオフセット領域に続けて、ストリームデータの実体を配置するようにして管理可能とされていると共に、
上記ストリームデータにおけるトラック単位のデータ部分を、上記ファイルシステムの書き換えにより上記記録媒体上から消去する、上記媒体上消去を行う場合において、上記媒体上消去の対象となったトラック単位のデータ部分における終端位置を含む、ファイルシステムのデータ管理単位分のデータ部分に、上記媒体上消去の対象となったトラック単位のデータ部分のさらに一部データが残る状態となった場合には、この残った上記一部データを、上記オフセット領域として管理するようにされる、
ことを特徴とする請求項１に記載のデータ編集方法。
【請求項３】
上記第１のデータ管理手順は、１ファイルとしてのストリームデータを形成するトラックとしてのデータ部分の少なくとも何れか１つについて、上記トラック消去による消去が行われているか否かを示すトラック消去情報を生成して保持すると共に、
上記トラック消去情報を参照することにより、トラック消去可能なデータ部分を有するストリームデータを判定する判定手順と、
上記ストリームデータ判定手順の判定結果に基づいて、消去すべきトラックとしてのデータ部分を決定し、上記第１のデータ管理手順により、この決定されたトラックとしてのデータ部分がトラック消去されるように制御する制御手順とを実行する、
ことを特徴とする請求項１に記載のデータ編集方法。
【請求項４】
少なくとも、上記記録媒体に記録すべきデータについて、暗号ブロックをチェーン化して暗号化を施す暗号化処理手順をさらに実行するものとされ、
上記暗号化処理手順は、
上記トラック管理情報によりトラック単位で上記ストリームデータを管理するための最小データ単位の範囲内において、上記暗号ブロックをチェーン化する範囲が収まるようにして暗号化処理を実行するように構成されている、
ことを特徴とする請求項１に記載のデータ編集方法。
【請求項５】
所定の記録媒体に記録されるストリームデータを、ファイルシステムに基づくファイル単位で管理する第１のデータ管理手段と、
上記ファイル単位のストリームデータの範囲内におけるデータ部分をトラックとし、上記トラックごとに対応する情報であって、上記ファイル単位のストリームデータとの対応を示す情報要素と、対応する上記ファイル単位のストリームデータにおけるそのトラックのデータ位置を示す情報要素とを有して形成されるトラック管理情報を含むトラック管理用データファイルに基づいて、トラック単位での管理を行う第２のデータ管理手段とを備え、
上記ファイル単位のストリームデータを分割して複数トラックを形成するトラック分割、又はトラックを消去するトラック消去を行う場合には、上記第２のデータ管理手段が、上記トラック分割又はトラック消去の態様に応じて、上記トラック管理用データファイルにおけるトラック管理情報の内容について更新処理を実行するようにされている、
ことを特徴とするデータ編集装置。
【請求項６】
上記第１のデータ管理手段は、
１ファイルとしてのストリームデータについて、先頭にオフセット領域を設け、このオフセット領域に続けて、ストリームデータの実体を配置するようにして管理可能とされていると共に、
上記ストリームデータにおけるトラック単位のデータ部分を、上記ファイルシステムの書き換えにより上記記録媒体上から消去する、上記媒体上消去を行う場合において、上記媒体上消去の対象となったトラック単位のデータ部分における終端位置を含む、ファイルシステムのデータ管理単位分のデータ部分に、上記媒体上消去の対象となったトラック単位のデータ部分のさらに一部データが残る状態となった場合には、この残った上記一部データを、上記オフセット領域として管理するようにされる、
ことを特徴とする請求項５に記載のデータ編集装置。
【請求項７】
上記第１のデータ管理手段は、１ファイルとしてのストリームデータを形成するトラックとしてのデータ部分の少なくとも何れか１つについて、上記トラック消去による消去が行われているか否かを示すトラック消去情報を生成して保持すると共に、
上記トラック消去情報を参照することにより、トラック消去可能なデータ部分を有するストリームデータを判定する判定手段と、
上記ストリームデータ判定手段の判定結果に基づいて、消去すべきトラックとしてのデータ部分を決定し、上記第１のデータ管理手段により、この決定されたトラックとしてのデータ部分がトラック消去されるように制御する制御手段とを備える、
ことを特徴とする請求項５に記載のデータ編集装置。
【請求項８】
少なくとも、上記記録媒体に記録すべきデータについて、暗号ブロックをチェーン化して暗号化を施す暗号化処理手段をさらに備えるものとされ、
上記暗号化処理手段は、
上記トラック管理情報によりトラック単位で上記ストリームデータを管理するための最小データ単位の範囲内において、上記暗号ブロックをチェーン化する範囲が収まるようにして暗号化処理を実行するように構成されている、
ことを特徴とする請求項５に記載のデータ編集装置。
【請求項１】
所定の記録媒体に記録されるストリームデータを、ファイルシステムに基づくファイル単位で管理する第１のデータ管理手順と、
上記ファイル単位のストリームデータの範囲内におけるデータ部分をトラックとし、上記トラックごとに対応する情報であって、上記ファイル単位のストリームデータとの対応を示す情報要素と、対応する上記ファイル単位のストリームデータにおけるそのトラックのデータ位置を示す情報要素とを有して形成されるトラック管理情報を含むトラック管理用データファイルに基づいて、トラック単位での管理を行う第２のデータ管理手順とを実行するものとされ、
上記ファイル単位のストリームデータを分割して複数トラックを形成するトラック分割、又はトラックを消去するトラック消去を行う場合には、上記第２のデータ管理手順が、上記トラック分割又はトラック消去の態様に応じて、上記トラック管理用データファイルにおけるトラック管理情報の内容について更新処理を実行するようにされている、
ことを特徴とするデータ編集方法。
【請求項２】
上記第１のデータ管理手順は、
１ファイルとしてのストリームデータについて、先頭にオフセット領域を設け、このオフセット領域に続けて、ストリームデータの実体を配置するようにして管理可能とされていると共に、
上記ストリームデータにおけるトラック単位のデータ部分を、上記ファイルシステムの書き換えにより上記記録媒体上から消去する、上記媒体上消去を行う場合において、上記媒体上消去の対象となったトラック単位のデータ部分における終端位置を含む、ファイルシステムのデータ管理単位分のデータ部分に、上記媒体上消去の対象となったトラック単位のデータ部分のさらに一部データが残る状態となった場合には、この残った上記一部データを、上記オフセット領域として管理するようにされる、
ことを特徴とする請求項１に記載のデータ編集方法。
【請求項３】
上記第１のデータ管理手順は、１ファイルとしてのストリームデータを形成するトラックとしてのデータ部分の少なくとも何れか１つについて、上記トラック消去による消去が行われているか否かを示すトラック消去情報を生成して保持すると共に、
上記トラック消去情報を参照することにより、トラック消去可能なデータ部分を有するストリームデータを判定する判定手順と、
上記ストリームデータ判定手順の判定結果に基づいて、消去すべきトラックとしてのデータ部分を決定し、上記第１のデータ管理手順により、この決定されたトラックとしてのデータ部分がトラック消去されるように制御する制御手順とを実行する、
ことを特徴とする請求項１に記載のデータ編集方法。
【請求項４】
少なくとも、上記記録媒体に記録すべきデータについて、暗号ブロックをチェーン化して暗号化を施す暗号化処理手順をさらに実行するものとされ、
上記暗号化処理手順は、
上記トラック管理情報によりトラック単位で上記ストリームデータを管理するための最小データ単位の範囲内において、上記暗号ブロックをチェーン化する範囲が収まるようにして暗号化処理を実行するように構成されている、
ことを特徴とする請求項１に記載のデータ編集方法。
【請求項５】
所定の記録媒体に記録されるストリームデータを、ファイルシステムに基づくファイル単位で管理する第１のデータ管理手段と、
上記ファイル単位のストリームデータの範囲内におけるデータ部分をトラックとし、上記トラックごとに対応する情報であって、上記ファイル単位のストリームデータとの対応を示す情報要素と、対応する上記ファイル単位のストリームデータにおけるそのトラックのデータ位置を示す情報要素とを有して形成されるトラック管理情報を含むトラック管理用データファイルに基づいて、トラック単位での管理を行う第２のデータ管理手段とを備え、
上記ファイル単位のストリームデータを分割して複数トラックを形成するトラック分割、又はトラックを消去するトラック消去を行う場合には、上記第２のデータ管理手段が、上記トラック分割又はトラック消去の態様に応じて、上記トラック管理用データファイルにおけるトラック管理情報の内容について更新処理を実行するようにされている、
ことを特徴とするデータ編集装置。
【請求項６】
上記第１のデータ管理手段は、
１ファイルとしてのストリームデータについて、先頭にオフセット領域を設け、このオフセット領域に続けて、ストリームデータの実体を配置するようにして管理可能とされていると共に、
上記ストリームデータにおけるトラック単位のデータ部分を、上記ファイルシステムの書き換えにより上記記録媒体上から消去する、上記媒体上消去を行う場合において、上記媒体上消去の対象となったトラック単位のデータ部分における終端位置を含む、ファイルシステムのデータ管理単位分のデータ部分に、上記媒体上消去の対象となったトラック単位のデータ部分のさらに一部データが残る状態となった場合には、この残った上記一部データを、上記オフセット領域として管理するようにされる、
ことを特徴とする請求項５に記載のデータ編集装置。
【請求項７】
上記第１のデータ管理手段は、１ファイルとしてのストリームデータを形成するトラックとしてのデータ部分の少なくとも何れか１つについて、上記トラック消去による消去が行われているか否かを示すトラック消去情報を生成して保持すると共に、
上記トラック消去情報を参照することにより、トラック消去可能なデータ部分を有するストリームデータを判定する判定手段と、
上記ストリームデータ判定手段の判定結果に基づいて、消去すべきトラックとしてのデータ部分を決定し、上記第１のデータ管理手段により、この決定されたトラックとしてのデータ部分がトラック消去されるように制御する制御手段とを備える、
ことを特徴とする請求項５に記載のデータ編集装置。
【請求項８】
少なくとも、上記記録媒体に記録すべきデータについて、暗号ブロックをチェーン化して暗号化を施す暗号化処理手段をさらに備えるものとされ、
上記暗号化処理手段は、
上記トラック管理情報によりトラック単位で上記ストリームデータを管理するための最小データ単位の範囲内において、上記暗号ブロックをチェーン化する範囲が収まるようにして暗号化処理を実行するように構成されている、
ことを特徴とする請求項５に記載のデータ編集装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【公開番号】特開２００４−１９２６８５（Ｐ２００４−１９２６８５Ａ）
【公開日】平成１６年７月８日（２００４．７．８）
【国際特許分類】
【出願番号】特願２００２−３５７１５９（Ｐ２００２−３５７１５９）
【出願日】平成１４年１２月９日（２００２．１２．９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
【公開日】平成１６年７月８日（２００４．７．８）
【国際特許分類】
【出願日】平成１４年１２月９日（２００２．１２．９）
【出願人】（０００００２１８５）ソニー株式会社 (34,172)
【Ｆターム（参考）】
[ Back to top ]