JP3829836B2 - 再生方法、記録装置、及び再生装置 - Google Patents

Description

本発明は、データ記録を行なう記録媒体（ディスク）に対応する再生方法、記録装置、再生装置に関するものである。

音楽等を記録／再生することのできる記録装置、再生装置、及び記録媒体としての光磁気ディスクが実用化され、特に近年、光磁気ディスクに対してユーザーが再生だけでなく楽曲等の音声を録音することができるもの（いわゆるミニディスク）も知られている。

このミニディスクシステムを用いる場合、いわゆる音楽を記録／再生することが行なわれているが、さらにこのミニディスクシステムにおいて、音楽情報以外のデータを記録／再生できるようにすることも考えられる。

なお、本明細書において、光磁気ディスクに記録される、音楽、音声等のいわゆるオーディオ信号をデジタル化したものを特に『オーディオデータ』といい、その１単位を『楽曲』又は『オーディオトラック』ということとする。そして、オーディオデータ以外の、文字、グラフィック等のいわゆるコンピュータなどの情報機器ユーズのデータであって光磁気ディスクに記録されるものを『一般データ』といい、オーディオデータと区別する。そして一般データの１つの記録再生単位を『データファイル』とする。

ところで、もともと音楽用にフォーマットが構成されているミニディスクシステムを、一般データ用に用い、情報の検索や更新等をできるようにしようとすることはあまり適当であるとはいえない。特に、音楽用途のための楽曲の管理情報の場合はデータ用途の場合のデータファイルの管理情報とは異なって、検索のための名称データや属性データなどが重要ではなかったり（少なくとも曲番と対応アドレスが管理されていればよい）、検索データの外部機器への送信のためのデータなどは不要であったりすることや、オーディオデータではデータボリュームの小さいもの（例えば非常に短い楽曲）が多数存在する場合が余り考えられないため、一般データのように小さいデータファイルが非常に多数存在してしまう場合に対応する必要はなく、例えば後述するオーディオデータ用の管理情報では最大２５５曲までしか対応可能とされていない。

これらの各種の点で音楽用途のための楽曲の管理情報はあくまで音楽用途に好適なように生成されており、一般データ用に適しているとはいえない。つまり、例えばミニディスクシステムをそのままの管理方式を用いて一般データの記録再生用に拡張することは適当でないという問題がある。
なお、ミニディスクシステムを例にあげているが、もちろん他の方式の音楽用途の記録再生システムについても同様のことがいえる。

さらに、一般データを記録した場合の管理形態を考えると、記録した一般データを有効に活用するためには、その管理情報の編集処理としてファイル名称の評価係数による整列、入れ換え、ファイル名テーブルのリンクの変更、ファイルアロケーションテーブルのメンテナンス等、各種の処理が行なわれることになるが、これらの処理のためには大容量のメモリが必要になり、また電力消費も大きく、さらに必要な処理が増えるに従って編集処理スピードも遅くなってしまう。これらの処理を例えばバッテリー駆動による携帯用などの小型の機器で十分に実行させようとすると、電力消費の面で負担が大きく、また処理速度の面でも十分な速度とすることは難しいという問題がある。

また、データファイルを単に記録／再生できるようにするだけではコピーガードなどの点については不十分である。つまり、データソフト作成者が提供したディスクソフトを、作成者の了解を得ずにコピーした違法ディスクを作成することも容易であり、これに対する対策が望まれている。

本発明はこのような問題点にかんがみてなされたもので、音楽用途の記録再生システムについてデータ記録再生用としても拡張し、オーディオデータと一般データに対して兼用して記録／再生を行なうことができるようにすること、また小型化、省電力化が要請される機器についても好適なものとすること、さらに違法コピーを防止できるようにすることを目的として、これらに好適な記録媒体を用いた再生方法及び再生装置を提供するものである。

第１の管理情報と、第２の管理情報と、第１及び／又は第２の管理情報によって欠陥領域とされた領域に記録されている一般データファイルを管理することができる第３の管理情報とを備え、この第３の管理情報は、第１及び／又は第２の管理情報によって欠陥領域とされる１又は複数の一般データパーツのうちのいずれかの一般データパーツ内に配置されているデータ管理構造が形成される記録媒体に対して、第３の管理情報によって管理される一般データファイルの再生方法としては、まず第１の管理情報又は第２の管理情報に示される欠陥領域を検索して第３の管理情報を読み出す。そして、その第３の管理情報を用いて、管理されている一般データファイルを再生するようにする。

また、第１の管理情報と、第２の管理情報と、第１及び／又は第２の管理情報によって欠陥領域とされた領域に記録されている一般データファイルを管理することができる第３の管理情報とを備え、この第３の管理情報は、第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスに相当する位置に配置されるデータ管理構造が形成される記録媒体に対して、第３の管理情報によって管理される一般データファイルの再生方法としては、まず第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスにアクセスして第３の管理情報を読み出す。そして、その第３の管理情報を用いて、管理されている一般データファイルを再生するようにする。

次に、第１の管理情報と、第２の管理情報と、第１及び／又は第２の管理情報によって欠陥領域とされた領域に記録されている一般データファイルを管理することができる第３の管理情報とを備え、この第３の管理情報は、第１及び／又は第２の管理情報によって欠陥領域とされる１又は複数の一般データパーツのうちのいずれかの一般データパーツ内に配置されているデータ管理構造が形成される記録媒体に対応する再生装置として、管理情報読出手段と、一般データ再生手段とを設ける。
管理情報読出手段は、第１の管理情報又は第２の管理情報に示される欠陥領域を検索して第３の管理情報を読み出すことができるようにする。
一般データ再生手段は、読み出された第３の管理情報に基づいて一般データファイルを再生することができるようにする。

また、第１の管理情報と、第２の管理情報と、第１及び／又は第２の管理情報によって欠陥領域とされた領域に記録されている一般データファイルを管理することができる第３の管理情報とを備え、この第３の管理情報は、第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスに相当する位置に配置されるデータ管理構造が形成される記録媒体に対応する再生装置として、管理情報読出手段と、一般データ再生手段とを設ける。
管理情報読出手段は、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスにアクセスして第３の管理情報を読み出すことができるように構成する。
一般データ再生手段は、読み出された第３の管理情報に基づいて一般データファイルを再生することができるようにする。

例えばオーディオデータ用に設けられている第１の管理情報に加え、一般データ用としてデータファイル管理に好適な第２の管理情報を設けることにより、音楽用途の記録媒体をデータ用途として拡張し、オーディオデータと一般データの両方に対応する記録媒体を実現できる。そして第２の管理情報は、一般データファイルが記録されている領域における物理的に先頭となる位置に配することで、これをアクセスすることができ、一般データファイルの再生管理に用いることが可能となる。

そしてこの際に、第１の管理情報では、一般データファイルが記録されている領域を一般データパーツとして管理することで、第１の管理情報においてオーディオデータエリアと一般データエリアを識別可能となり、データ混在に基づく誤記録／誤消去／再生エラー等は防止される。

さらに第１の管理情報と第２の管理情報のほかに、第１及び第２の管理情報によって再生対象としては管理されない一般データファイルを管理することができる第３の管理情報を備えることで、これを簡易な記録／再生動作に用いることができる。つまり、第２の管理情報によって管理されるデータファイルとは別に、複雑な編集を行なわないファイルを保持することが可能となる。

この第３の管理情報は、第１及び／又は第２の管理情報によって再生管理されない１又は複数の一般データパーツのうちの、いずれかの一般データパーツ内に配置することと規定するか、もしくは第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスに相当する位置に配置することで、アクセスし読み出すことが可能となる。

また、第３の管理情報によって管理される一般データファイルが記録された１又は複数の一般データパーツについては、第１の管理情報と第２の管理情報の一方又は両方で、記録／再生対象とはならない欠陥領域として管理しておくことで、第１の管理情報、第２の管理情報から独立したエリアとして利用されている状態とすることができる。つまり第１の管理情報又は第２の管理情報による記録／再生動作対象とはならず消去されたり誤って再生されることはない。

また、このような第３の管理情報によって管理される一般データファイルを、第２の管理情報によっても管理されるようにすることで、本来のデータファイルとして組み入れることができる。

ここで、第３の管理情報によって管理される一般データファイルが第２の管理情報による管理対象に組み入れられた場合は、第３の管理情報を用いた動作で消去／書き換えがなされることは不都合となるが、第３の管理情報においてはその一般データファイルを書換不可データとして管理しておくようにすることで、不都合はなくなる。

また第３の管理情報が、第１及び／又は第２の管理情報によって再生管理されない１又は複数の一般データパーツのうちの、いずれかの一般データパーツ内に配置される場合は、その第３の管理情報が記録されている領域は、第１の管理情報、第２の管理情報の一方又は両方においては記録／再生対象とはならない欠陥領域として管理しておくことで、第１の管理情報、第２の管理情報による記録／再生動作対象とはならず消去されたり誤って再生されることはない。

また、第１の管理情報及び／又は第２の管理情報において欠陥領域として管理される領域内に、特定のキーワード情報が記録されているようにすると、通常の第１の管理情報、第２の管理情報による記録／再生動作対象とはならず、従ってそのキーワード情報はコピーされることはない。従って、このキーワード情報をコピーガードデータとして利用することができる。
特定のキーワード情報が第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスから記録される情報内に含まれる場合も同様である。

以上説明したように本発明による記録媒体、再生方法、記録装置、及び再生装置によれば、次のような各種の優れた効果を得ることができる。

まず、オーディオデータなどのトラック管理のために設けられている第１の管理情報（Ｕ−ＴＯＣ）に加え、一般データ用としてデータファイル管理に好適な第２の管理情報（データＵ−ＴＯＣ）を設けることにより、音楽用途の記録媒体をデータ用途として拡張し、オーディオデータと一般データの両方に対応する記録媒体を実現できる。そして第２の管理情報は、一般データファイルが記録されている領域における物理的に先頭となる位置に配することで、これをアクセスすることができ、一般データファイルの再生管理に用いることが可能となる。

また、第１の管理情報では、一般データファイルが記録されている領域を一般データパーツ、即ちデータトラックの一部として管理することで、第１の管理情報においてオーディオデータエリアと一般データエリアを識別可能となり、データ混在に基づく誤記録／誤消去／再生エラー等は防止される。

さらに第１の管理情報（Ｕ−ＴＯＣ）と第２の管理情報（データＵ−ＴＯＣ）のほかに、第１及び第２の管理情報によって再生対象としては管理されない一般データファイルを管理することができる第３の管理情報（簡易Ｕ−ＴＯＣ）を備えることで、これを簡易な記録／再生動作に用いることができる。つまり、第２の管理情報によって管理されるデータファイルとは別に、複雑な編集を行なわないファイルを保持することが可能となる。
そしてこの第３の管理情報による、記録／再生が行なわれる場合、第２の管理情報の読込／編集の必要はないため、データファイルの記録／再生／編集動作時に大きなメモリ容量を必要とせず、また消費電力も小さくできる。従って、小型機器などでは非常に好適となる。

また第３の管理情報は、第１及び／又は第２の管理情報によって再生管理されない１又は複数の一般データパーツのうちの、いずれかの一般データパーツ内に配置すると規定するか、もしくは第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスに相当する位置に配置することで、迅速にアクセスして読み出すことが可能となる。

また、第３の管理情報によって管理される一般データファイルが記録された１又は複数の一般データパーツについては、第１の管理情報と第２の管理情報の一方又は両方で、記録／再生対象とはならない欠陥領域として管理しておくことで、第１の管理情報、第２の管理情報から独立したエリアとして利用されている状態とすることができる。つまり第１の管理情報又は第２の管理情報による記録／再生動作対象とはならず消去されたり誤って再生されることを防止できる。

また、このような第３の管理情報によって管理される一般データファイルを、第２の管理情報によっても管理されるようにすることで、本来のデータファイルとして組み入れることができる。
これによって第２の管理情報を用いた通常のデータファイル再生によって、第３の管理情報に対応するデータファイルを再生することができるようになり、従って、第３の管理情報による再生機能を持たない機器においても再生可能とすることができる。
さらに、第３の管理情報に対応するデータファイルを第２の管理情報の管理下に編入することで、そのデータファイルは第２の管理情報における高度な編集動作の対象となり、各種有効利用できるようになる。

また、第３の管理情報によって管理される一般データファイルが第２の管理情報による管理対象に組み入れられた場合は、そのデータファイルについては第３の管理情報を用いた動作による消去／書換が禁止されるようにすることで、第２の管理情報を使用せずに第２の管理情報が管理するデータファイルが消去されてしまうということは防止される。

また第３の管理情報が、第１及び／又は第２の管理情報によって欠陥領域とされる１又は複数の一般データパーツのうちの、いずれかの一般データパーツ内に配置される場合は、その第３の管理情報が記録されている領域は、第１の管理情報、第２の管理情報の一方又は両方においては記録／再生対象とはならない欠陥領域として管理しておくことで、第１の管理情報、第２の管理情報による記録／再生動作対象とはならず、消去されたり誤って再生されることはない。

また、第１の管理情報及び／又は第２の管理情報において欠陥領域として管理される領域内に、特定のキーワード情報が記録されているようにすることで、コピー先の記録媒体にはそのキーワード情報はコピーされず、もしくは正しいキーワード情報は得られないため、そのような記録媒体に対しては再生動作等を実行しないようにすれば、高度なコピーガードシステムを実現できる。

以下、本発明の実施例を次の順序で説明していく。

Ｉ ．記録再生装置の構成
Ｉ−１ 外観例
Ｉ−２ 内部ブロック

II ．ディスク構造
II−１ クラスタ構造
II−２ トラック構造
II−３ Ｐ−ＴＯＣセクター
II−４ Ｕ−ＴＯＣセクター（第１の管理情報）
II−５ データＵ−ＴＯＣセクター（第２の管理情報）
II−５−ａ 全体構造
II−５−ｂ ブートエリア
II−５−ｃ ボリュームディスクリプタ
II−５−ｄ ボリュームスペースビットマップ
II−５−ｅ マネジメントテーブル
II−５−ｆ ディレクトリレコードブロック
II−５−ｇ エクステントレコードブロック
II−６ データセクター

III ．データファイル再生処理

IV ．簡易Ｕ−ＴＯＣを用いた記録再生方式（タイプＡ）
IV−１ 簡易Ｕ−ＴＯＣセクター（第３の管理情報）
IV−２ 簡易Ｕ−ＴＯＣが記録された場合の管理状態
IV−３ 簡易Ｕ−ＴＯＣを用いるデータファイル記録処理
IV−４ 簡易Ｕ−ＴＯＣによるデータファイルの再生処理及びデータＵ−ＴＯＣへの編入処理
IV−５ 簡易Ｕ−ＴＯＣを用いたコピーガードデータ記録
IV−６ コピーガードに対応する再生処理

Ｖ ．簡易Ｕ−ＴＯＣを用いた記録再生方式（タイプＢ）
Ｖ−１ 簡易Ｕ−ＴＯＣが記録された場合の管理状態
Ｖ−２ 簡易Ｕ−ＴＯＣを用いるデータファイル記録処理
Ｖ−３ 簡易Ｕ−ＴＯＣによるデータファイルの再生処理及びデータＵ−ＴＯＣへの編入処理
Ｖ−４ 簡易Ｕ−ＴＯＣを用いたコピーガードデータ記録
Ｖ−５ コピーガードに対応する再生処理

VI ．簡易Ｕ−ＴＯＣで管理されるデータファイルの記録位置

Ｉ ．記録再生装置の構成

Ｉ−１ 外観例

図１に実施例となる記録再生装置及びディスクの外観を示す。
ディスク１としては光磁気ディスクが用いられるが、図１に示すようにその外部はカートリッジＫに収納されており、シャッタＳがスライドされることによりディスク記録面が表出されるようになされている。
記録再生装置１０としてはディスク１が収納されたカートリッジＫが装填されるディスク挿入部１１が設けられ、カートリッジＫがこのディスク挿入部１１に挿入されることにより、図示しない内部機構によってシャッタＳがスライドされ、ディスク１の盤面が表出されて記録又は再生可能状態とされる。

記録再生装置１０の筺体上面にはユーザー操作に供されるキー入力部１２及びデータ検索のためのメニュー情報や検索されたデータの表示出力を行なうための表示部１３が設けられている。キー入力部１２としてはカーソル移動キー、エンターキー、データ入力キー等が設けられる。
また１４は画像スキャナ部であり、紙面に記された画像情報を検出してドットデータに変換し、画像データとして入力できるようになされている。
さらに１５は入出力コネクタ部であり、通信ケーブルＣを接続することにより、他の情報機器（コンピュータ、ワープロ等）とデータの送受信ができるようになされている。

１６はアナログオーディオ信号の入出力に用いる端子であり、オーディオコード１７を介して他の音響機器に対して、ディスク１からの再生音声信号又はディスク１に録音すべき音声信号のライン入出力がなされる。

Ｉ−２ 内部ブロック

記録再生装置１０の要部の構成は図２に示される。
図２においてはディスク１（ディスク１を収納したカートリッジＫ）が装填された状態で示している。２１は記録再生装置の各種動作を制御するシステムコントローラを示し、例えばマイクロコンピュータにより形成される。
２２はスピンドルモータであり、装填されたディスク１はスピンドルモータ２２により回転駆動される。２３はディスク１に対して記録／再生時にレーザ光を照射する光学ヘッドであり、記録時には記録トラックをキュリー温度まで加熱するための高レベルのレーザ出力をなし、また再生時には磁気カー効果により反射光からデータを検出するための比較的低レベルのレーザ出力をなす。

このため、光学ヘッド２３はレーザ出力手段としてのレーザダイオードや、偏向ビームスプリッタや対物レンズ等からなる光学系、及び反射光を検出するためのディテクタが搭載されている。対物レンズ２３ａは２軸機構２４によってディスク半径方向及びディスクに接離する方向に変位可能に保持されており、また、光学ヘッド２３全体はスレッド機構２５によりディスク半径方向に移動可能とされている。

また、２６は供給された情報によって変調された磁界を光磁気ディスクに印加する磁気ヘッドを示し、ディスク１を挟んで光学ヘッド２３と対向する位置に配置されている。

再生動作によって、光学ヘッド２３によりディスク２１から検出された情報はＲＦアンプ２７に供給される。ＲＦアンプ２７は供給された情報の演算処理により、再生ＲＦ信号、トラッキングエラー信号、フォーカスエラー信号、絶対位置情報（ディスク１にプリグルーブ（ウォブリンググルーブ）として記録されている絶対位置情報）、アドレス情報、サブコード情報、フォーカスモニタ信号等を抽出する。そして、抽出された再生ＲＦ信号はデコーダ部２８に供給される。また、トラッキングエラー信号、フォーカスエラー信号はサーボ回路２９に供給される。さらにフォーカスモニタ信号はシステムコントローラ２１に供給される。

また、アドレスデコーダ２９から出力される、プリグルーブ情報をデコードして得られた絶対位置情報、又はデータとして記録されたアドレス情報はデコーダ部２８を介してシステムコントローラ２１に供給され、各種の制御動作に用いられる。

サーボ回路２９は供給されたトラッキングエラー信号、フォーカスエラー信号や、システムコントローラ２１からのトラックジャンプ指令、シーク指令、回転速度検出情報等により各種サーボ駆動信号を発生させ、２軸機構２４及びスレッド機構２５を制御してフォーカス及びトラッキング制御をなし、またスピンドルモータ２２を一定角速度（ＣＡＶ）又は一定線速度（ＣＬＶ）に制御する。

再生ＲＦ信号はデコーダ部２８でＥＦＭ復調、ＣＩＲＣデコード、ＡＣＩＲＣデコード等のデコード処理された後システムコントローラ２１を介して所定の処理に供される。

また、記録動作の際にディスク１に記録すべき情報としてシステムコントローラ２１に供給された情報はエンコーダ部３０においてＡＣＩＲＣエンコード、ＣＩＲＣエンコード、ＥＦＭ変調等のエンコード処理された後、磁気ヘッド駆動回路３１に供給される。

磁気ヘッド駆動回路３１はエンコード処理された記録データに応じて、磁気ヘッド２６に磁気ヘッド駆動信号を供給する。つまり、ディスク１に対して磁気ヘッド２６によるＮ又はＳの磁界印加を実行させる。また、このときシステムコントローラ２１は光学ヘッド２３に対して、記録レベルのレーザ光を出力するように制御信号を供給する。

３２はコードデータをフォントデータに変換するための変換メモリであり、ディスク１から読み出した文字データ等の表示のためのフォント変換処理を行なう。

また、３３はバッファＲＡＭであり、画像スキャナ１４によって取り込まれたドットデータ、表示部１３で表示される表示データ、コネクタ部１５による送受信データなどの一時保持や、ディスク１から読み出されたオーディオデータやデータファイルを出力する際の一時記憶部として機能する。

また、ディスク１に対して記録／再生動作を行なう際には、ディスク１に記録されている管理情報、即ちプリマスタードＴＯＣ（以下、Ｐ−ＴＯＣという）、オーディオデータ記録／再生の管理用のＴＯＣ（以下、Ｕ−ＴＯＣという），及び一般データ記録／再生の管理用のＴＯＣ（以下、データＵ−ＴＯＣという）、さらに後述する簡易な一般データ記録／再生のために用いるＴＯＣ（以下、簡易Ｕ−ＴＯＣという）を読み出して、システムコントローラ２１はこれらの管理情報に応じて記録すべきアドレスや、データ検索及び再生すべきアドレスを判別することとなるが、これらの管理情報はバッファＲＡＭ３３に保持される。
例えば、システムコントローラ２１はＰ−ＴＯＣ及びＵ−ＴＯＣをディスク１が装填された際に管理情報エリア（例えばディスクの最内周側）の再生動作を実行させることによって読み出し、バッファＲＡＭ３３に記憶しておき、以後そのディスク１に対する記録／再生動作の際に参照できるようにしている。

また、Ｕ−ＴＯＣ、データＵ−ＴＯＣ、簡易Ｕ−ＴＯＣはデータの記録や消去に応じて書き換えられるものであるが、システムコントローラ２１は記録／消去動作のたびにこの書換をバッファＲＡＭ３３に記憶された管理情報に対して行ない、その書換動作に応じて所定のタイミングでディスク１の管理情報エリアについても書き換えるようにしている。

３４は通信回路を示し、コネクタ部１５を介してデータの外部機器と送受信を実行する。
３５は表示コントローラであり、システムコントローラ２１からの表示データ、即ち検索メニューの表示やディスク１から読み出したデータの表示等を表示部１３において実行させるための制御回路となる。
以上の構成により、記録再生装置１０は各種一般データのディスク１に対する記録動作及び再生動作が可能となる。

ディスク１からオーディオデータを再生し、音声信号として出力する際には、ディスク１から読み出されたオーディオデータとしての再生ＲＦ信号は、デコーダ部２８でＥＦＭ復調、ＣＩＲＣ等のデコード処理された後、システムコントローラ２１によって一旦バッファＲＡＭ３３に書き込まれる。なお、光学ヘッド２３による光磁気ディスク１からのオーディオデータの読み取り、及び光学ヘッド２３からバッファＲＡＭ３３までの再生オーディオデータの転送は1.41Mbit/secで（間欠的に）行なわれる。

バッファＲＡＭ３３に書き込まれたデータは、再生オーディオデータの転送が0.3Mbit/sec となるタイミングで読み出され、音声圧縮デコーダ部３８に供給される。この記録再生システムでは音声信号についてはデジタルデータ段階でデータ圧縮処理が施されて記録されている。例えば２チャンネル１６ビットでサンプリング周波数44.1Kbit（≒1.4Mbit/sec ）のデータを約１／５の0.3Mbit/sec に圧縮する処理が施されている。従って再生時にはこの圧縮処理に対する逆処理となるデコード処理が行なわれる。
そしてデコーダ部３８において音声圧縮処理に対するデコード処理等の再生信号処理を施されると、Ｄ／Ａ変換器３９によってアナログ信号とされ、端子１６ｂから所定の増幅回路部又はコード１７を介してライン出力され、再生出力される。例えばＬ，Ｒオーディオ信号として出力される。

ディスク１に対してオーディオ信号の記録動作が実行される際には、コード１７によるライン入力系や図示しないマイクロフォン系から端子１６ａに供給された記録信号（アナログオーディオ信号）は、Ａ／Ｄ変換器３６によってサンプリング周波数44.1Kbit、量子化１６ビットのデジタルデータとされた後、エンコーダ部３７に供給され、上記した音声圧縮エンコード処理を施される。エンコーダ部３４によって圧縮された記録データはシステムコントローラ２１によって一旦バッファＲＡＭ３３に書き込まれ、また所定タイミングで読み出されてエンコーダ部３０に送られる。そしてエンコーダ部３０でＣＩＲＣエンコード、ＥＦＭ変調等のエンコード処理された後、磁気ヘッド駆動回路３１に供給される。

磁気ヘッド駆動回路３１は、一般データ記録の場合と同様に、エンコード処理された記録オーディオデータに応じて、磁気ヘッド２６に磁気ヘッド駆動信号を供給する。つまり、光磁気ディスク１に対して磁気ヘッド２６によるＮ又はＳの磁界印加を実行させる。また、このときシステムコントローラ２１は光学ヘッド２３に対して、記録レベルのレーザ光を出力するように制御信号を供給する。

なお、再生動作はディスク１が光磁気ディスクである場合として説明したが、データをＣＤと同様にピット形態で記録している光ディスク（及び光磁気ディスクにおけるＰ−ＴＯＣなどのようなピットデータ）についても、いわゆるミニディスク再生装置としては再生が可能とされており、この場合、光学ヘッド２３は磁気カー効果ではなくＣＤプレーヤの場合と同様にピットの有無による反射光レベルの変化に応じて再生ＲＦ信号を取り出すものである。もちろん光ディスク、及び光磁気ディスクのピットデータエリアに対しては磁界記録動作は実行されない。

また上述したように、バッファＲＡＭ３３にはディスク１におけるＴＯＣ情報が読み込まれるが、この実施例の記録再生装置が対応するディスク１には、予め楽曲等が記録されているプリマスタードタイプ（光ディスク）のものと、ユーザーがオーディオデータや後述するように一般データを記録することのできるデータ書き換え可能とされるもの（光磁気ディスク）、及びデータファイルや楽曲等を予め記録したＲＯＭエリアと録音可能な光磁気エリアを設けたハイブリッドタイプのものがあり、これらのディスクにはそのタイプに応じて、既に楽曲等が記録されているエリアや未記録エリアを管理するデータ等がＴＯＣ情報として記録されている。

そして、上記のようにオーディオデータ（楽曲）の録音を行なおうとする際には、Ｕ−ＴＯＣからディスク上の未記録エリアを探し出し、ここに音声データを記録していくことになる。また、オーディオデータの再生時には再生すべき楽曲が記録されているエリアを、その楽曲がプリマスタードの楽曲の場合はＰ−ＴＯＣから、又はその楽曲が光磁気記録されている楽曲の場合はＵ−ＴＯＣから判別し、そのエリアにアクセスして再生動作を行なうことになる。
一方、一般データの記録／再生の動作については管理情報としてデータＵ−ＴＯＣの情報を使用することになる。
なお、光磁気ディスクにおいてもＰ−ＴＯＣはピットデータとしてＲＯＭ化されて記録されている。

II ．ディスク構造

II−１ クラスタ構造

ミニディスクシステムにおける、光磁気ディスク１に対してはクラスタという単位で記録が行なわれる。この１クラスタは２〜３周回トラック分に相当する。このクラスタが時間的に連続されて、１つのトラック、即ち楽曲やデータトラックが形成される。

図３のように１クラスタは４セクターのサブデータ領域と３２セクターのメインデータ領域からなる。１セクターは２３５２バイトである。アドレスは１セクター毎に記録される。
なお、各セクターにおいて実際にデータが記録されるのは２０４８バイトの領域であり、他のバイトは同期パターンやアドレスなどによるヘッダや、エラー訂正コードなどに用いられる。
４セクターのサブデータ領域はサブデータやリンキングエリアとしてなどに用いられ、ＴＯＣデータ、音声データ、一般データ等の記録は３２セクターのメインデータ領域に行なわれる。

II−２ トラック構造

ここで、ディスク１におけるトラック構造を説明し、Ｐ−ＴＯＣ及びＵ−ＴＯＣ、データＵ−ＴＯＣの位置関係及び管理態様を説明する。

光磁気ディスクの場合、大きくわけて図４（ａ）にピットエリアとして示すよ
うにエンボスピットによりデータが記録されているエリア（ピットエリア）と、いわゆる光磁気エリアとされてグルーブが設けられているＭＯエリアに分けられる。
ここでピットエリアとしてはＰ−ＴＯＣが記録される再生専用管理エリアとされており、後述するＰ−ＴＯＣセクターが繰り返し記録されている。

最内周側のピットエリアに続いて、ディスク最外周のリードアウトエリアまでがＭＯエリアとされるが、ピットエリアに続く位置からリードアウトエリアの直前までが記録可能なレコーダブルエリアとされる。

さらにこのレコーダブルエリアのうち、先頭エリアは記録再生管理エリアとされ、Ｕ−ＴＯＣの記録や、レーザーパワーのキャリブレーションエリアとして用いられる。
Ｕ−ＴＯＣは記録再生管理エリアにおいて所要の位置に３クラスタ連続して記録されるものであり、Ｕ−ＴＯＣが記録再生管理エリア内のどのクラスタアドレスに記録されるかはＰ−ＴＯＣによって示される。

実際にオーディオデータや一般データが記録されるレコーダブルユーザーエリアは、記録再生管理エリアの後に続くエリアとなる。
このレコーダブルユーザーエリアにおいて、例えばＭ₁ ，Ｍ₂ ，Ｍ₃ として示すようにオーディオトラック、即ち楽曲が記録されたり、またＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ として示すようにデータファイルが記録されたりする。
データファイルとされた部位における最も内周側となる部位には、データファイルの管理のためのデータＵ−ＴＯＣが記録される。この例では、データファイルＦＬ₁ の直前の位置にデータＵ−ＴＯＣが記録されていることになる。

また、レコーダブルユーザーエリアにおいて、楽曲やデータファイルが記録されていない部分はフリーエリアとされる。つまり未記録領域であり、今後、楽曲やデータファイルの記録を行なうことができるエリアとして管理される。

例えばこの図４（ａ）のように記録されたディスクに対して、Ｕ−ＴＯＣでは図４（ｂ）のように管理を行なっている。
つまりＭ₁ ，Ｍ₂ ，Ｍ₃ となる各オーディオトラックについては、そのスタートアドレス及びエンドアドレスを管理している。またフリーエリアについても同様に管理している。
ところが、データファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、及びデータＵ−ＴＯＣが記録されている部位については、まとめて１つのデータトラックとして管理している。なお、ＥＢとはＵ−ＴＯＣによって管理されているデータトラック内で、実際にデータファイルが記録されていないエリアを示している。

一方、データＵ−ＴＯＣでは図４（ｃ）に示すように、データトラック内での各データファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、及び未記録ブロックＥＢの管理を行なう。

従って、記録再生装置がオーディオトラックを再生する場合はＵ−ＴＯＣからスタートアドレス及びエンドアドレスを判別して再生を行ない、また、データファイルを再生する場合は、Ｕ−ＴＯＣからデータＵ−ＴＯＣを探し、そのデータＵ−ＴＯＣを用いて所要のデータファイルをアクセスすることになる。

II−３ Ｐ−ＴＯＣセクター

次にディスク１におけるＰ−ＴＯＣのフォーマットについて説明する。
Ｐ−ＴＯＣ情報としては、ディスクの記録可能エリア（レコーダブルユーザーエリア）などのエリア指定やＲＯＭエリアの管理等が行なわれる。また、プリマスタードディスク又はハイブリッドディスクの場合に、ＲＯＭ化されて記録されているオーディオトラックやデータトラックの管理も行なうことができるようになされている。

Ｐ−ＴＯＣのフォーマットを図５に示す。
図５は、図４に示した再生専用管理領域において繰り返し記録されるＰ−ＴＯＣ情報の最初のセクター（セクター０）を示している。
なお、Ｐ−ＴＯＣセクターとしてはセクター０〜７が用意されるが、セクター１以降はオプションとされる。

Ｐ−ＴＯＣのセクターのデータ領域は、例えば４バイト×588 の２３５２バイトのデータ領域として構成され、先頭位置にオール０又はオール１の１バイトデータによって成る同期パターンが記録される。
さらにこのセクターのアドレスとして上位と下位の２バイトのクラスタアドレスと、１バイトのセクターアドレスが記録され、さらに『０２ｈ』の１バイトが付加されてヘッダが構成される。
なお、本明細書で『ｈ』を付した数値はいわゆる１６進表記のものである。

また、ヘッダに続いて所定アドレス位置に『ＭＩＮＸ』という文字に対応したアスキーコードによる識別コードが付加されている。この『ＭＩＮＸ』はデータファイル用途のディスクにおけるＰ−ＴＯＣの領域であることの識別コードである。

さらに、続いてディスクタイプ(Disc type) や録音レベル(Rec power) 、記録されている最初のトラックのナンバ（First TNO)、最後のトラックのナンバ（Last TNO) が示される。
ディスクタイプ(Disc type) としては、そのディスクがリードオンリーのプリマスタードディスクか、レコーダブルな光磁気ディスクか、もしくはハイブリッドディスクかを識別するコードが記録される。

つづいてリードアウトスタートアドレスＬＯ_A として図４のリードアウトエリアのスタートアドレスが示される。
またセクター使用状況(Used sectors)として、この１バイトの各ビットがＰ−ＴＯＣセクター０〜７に対応し、各セクターが使用されているか否かを示している。

パワーキャルエリアスタートアドレスＰＣ_A は記録再生管理エリア内に設けられるパワーキャリブレーションエリアのスタートアドレスである。
また、Ｕ−ＴＯＣスタートアドレスＵＳＴ_A として記録再生管理エリア内に記録されるＵ−ＴＯＣの開始位置のアドレスが記される。
さらに、レコーダブルユーザーエリアのスタートアドレスＲＳＴ_A が記録される。

続いて、記録されている各トラック等を後述する管理テーブル部におけるパーツテーブルに対応させるテーブルポインタ(P-TNO1 〜P-TNO255) を有する対応テーブル指示データ部が用意されている。

そして対応テーブル指示データ部に続く領域には、(01h) 〜(FFh) までの２５５個のパーツテーブルが設けられた管理テーブル部が用意される。それぞれのパーツテーブルには、或るパーツについて起点となるスタートアドレス、終端となるエンドアドレス、及びそのパーツのモード情報（トラックモード）が記録できるようになされている。
なお、パーツとはディスク上で物理的に連続して一連のデータが記録されたトラック部分をいう。

各パーツテーブルにおけるトラックのモード情報とは、そのパーツが例えばオーバーライト禁止やデータ複写禁止に設定されているか否かの情報や、オーディオ情報か否か、モノラル／ステレオの種別などが記録されている。

管理テーブル部における(01h) 〜(FFh) までの各パーツテーブルは、対応テーブル指示データ部のテーブルポインタ (P-TNO1〜P-TNO255) によって、そのパーツの内容が示される。つまり、第１トラックについてはテーブルポインタP-TNO1としてパーツテーブル(01h) が記録されている。なお、実際にはテーブルポインタには所定の演算処理によりＴＯＣセクター０内のバイトポジションで或るパーツテーブルを示すことができる数値が記されている。
この場合パーツテーブル(01h) のスタートアドレスは第１トラックの記録位置のスタートアドレスとなり、同様にエンドアドレスは第１トラックの終端位置のアドレスとなる。さらに、トラックモード情報はその第１トラックについての情報となる。

同様に第２トラックについては、テーブルポインタP-TNO2に示されるパーツテーブル（02h)に、そのスタートアドレス、エンドアドレス、及びトラックモード情報が記録されている。
以下同様にテーブルポインタはP-TNO255まで用意されているため、ＴＯＣ上では第２５５トラックまで管理可能とされている。
そして、このようにＴＯＣセクター０が形成されることにより、例えば再生時において、所定の楽曲をアクセスして再生させることができる。

ただし、このＰ−ＴＯＣで管理されるトラックはいわゆるプリマスタードのトラックのみであり、従ってＲＯＭタイプのオーディオトラック又はデータトラックが記録されていない光磁気ディスクでは、上記した対応テーブル指示データ部及び管理テーブル部は用いられることはないため、各バイトは全て『００ｈ』とされている。

II−４ Ｕ−ＴＯＣセクター（第１の管理情報）

図６はＵ−ＴＯＣの最初のセクター（セクター０）のフォーマットを示している。このＵ−ＴＯＣセクターは、主にユーザーが録音を行なった楽曲や新たに楽曲が録音可能なフリーエリアについての管理情報が記録されているデータ領域とされる。
なお、Ｕ−ＴＯＣセクターもセクター０〜７が用意されるが、セクター１以降はオプションとされる。

例えばディスク１に或る楽曲やデータファイルの記録を行なおうとする際には、記録再生装置１０は、このＵ−ＴＯＣからディスク上のフリーエリアを探し出して記録していく。また、再生時には再生すべき楽曲（オーディオトラック）が記録されているエリアやデータトラックをＵ−ＴＯＣ情報から判別し、そのエリアにアクセスして再生動作を行なう。

図６に示すＵ−ＴＯＣのセクターには、Ｐ−ＴＯＣセクターと同様に、まず同期パターン及びアドレスを示したヘッダが設けられる。
続いて所定アドレス位置に、メーカーコード、モデルコード、最初のトラックのトラックナンバ(First TNO）、最後のトラックのトラックナンバ（Last TNO）、セクター使用状況(Used sectors)、ディスクシリアルナンバ、ディスクＩＤが記録される。
セクター使用状況の１バイトでは、各ビットがＵ−ＴＯＣセクター０〜７に対応し、各セクターが使用されているか否かを示している。

さらに、ユーザーが記録を行なったオーディオトラックや、データファイルが記録されたデータトラック、及びフリーエリアを後述する管理テーブル部に対応させて管理するために、対応テーブル指示データ部として各種のテーブルポインタ(P-DFA，P-EMPTY ，P-FRA ，P-TNO1〜P-TNO255) が記録される領域が用意されている。

そしてテーブルポインタ(P-DFA〜P-TNO255) に対応させる管理テーブル部として(01h) 〜(FFh) までの２５５個のパーツテーブルが設けられる。それぞれのパーツテーブルには、上記図５のＰ−ＴＯＣセクター０と同様に或るパーツについて起点となるスタートアドレス、終端となるエンドアドレス、そのパーツのモード情報（トラックモード）が記録されている。さらにこのＵ−ＴＯＣセクター０の場合、各パーツテーブルで示されるパーツが他のパーツへ続いて連結される場合があるため、その連結されるパーツのスタートアドレス及びエンドアドレスが記録されているパーツテーブルを示すリンク情報が記録できるようになされている。

ミニディスクシステムの場合、例えば１つの楽曲のデータを物理的に不連続に、即ち複数のパーツにわたって記録されていてもパーツ間でアクセスしながら再生していくことにより再生動作に支障はないため、ユーザーが録音する楽曲等については、録音可能エリアの効率使用等の目的から、複数パーツにわけて記録する場合もある。そのため、リンク情報が設けられ、例えば各パーツテーブルに与えられたナンバ(01h) 〜(FFh) （実際には所定の演算処理によりＵ−ＴＯＣセクター０内のバイトポジションとされる数値で示される）によって、連結すべきパーツテーブルを指定することによってパーツテーブルが連結できるようになされている。
なお、あらかじめ記録される楽曲やデータファイルについては通常パーツ分割されることがないため、前記図５のようにＰ−ＴＯＣセクター０においてリンク情報はすべて『(00h) 』とされている。

つまりＵ−ＴＯＣセクター０における管理テーブル部においては、１つのパーツテーブルは１つのパーツを表現しており、例えば３つのパーツが連結されて構成される楽曲についてはリンク情報によって連結される３つのパーツテーブルによって、その各パーツ位置の管理はなされる。

Ｕ−ＴＯＣセクター０の管理テーブル部における(01h) 〜(FFh) までの各パーツテーブルは、対応テーブル指示データ部におけるテーブルポインタ(P-DFA，P-EMPTY ，P-FRA ，P-TNO1〜P-TNO255) によって、以下のようにそのパーツの内容が示される。

テーブルポインタP-DFA は光磁気ディスク１上の欠陥領域に付いて示しており、傷などによる欠陥領域となるトラック部分（＝パーツ）が示された１つのパーツテーブル又は複数のパーツテーブル内の先頭のパーツテーブルを指定している。つまり、欠陥パーツが存在する場合はテーブルポインタP-DFA において(01h) 〜(FFh) のいづれかが記録されており、それに相当するパーツテーブルには、欠陥パーツがスタート及びエンドアドレスによって示されている。また、他にも欠陥パーツが存在する場合は、そのパーツテーブルにおけるリンク情報として他のパーツテーブルが指定され、そのパーツテーブルにも欠陥パーツが示されている。そして、さらに他の欠陥パーツがない場合はリンク情報は例えば『(00h) 』とされ、以降リンクなしとされる。

テーブルポインタP-EMPTY は管理テーブル部における１又は複数の未使用のパーツテーブルの先頭のパーツテーブルを示すものであり、未使用のパーツテーブルが存在する場合は、テーブルポインタP-EMPTY として、(01h) 〜(FFh) のうちのいづれかが記録される。未使用のパーツテーブルが複数存在する場合は、テーブルポインタP-EMPTY によって指定されたパーツテーブルからリンク情報によって順次パーツテーブルが指定されていき、全ての未使用のパーツテーブルが管理テーブル部上で連結される。

テーブルポインタP-FRA は光磁気ディスク１上のデータの書込可能なフリーエリア（消去領域を含む）について示しており、フリーエリアとなるトラック部分（＝パーツ）が示された１又は複数のパーツテーブル内の先頭のパーツテーブルを指定している。つまり、フリーエリアが存在する場合はテーブルポインタP-FRA において(01h) 〜(FFh) のいづれかが記録されており、それに相当するパーツテーブルには、フリーエリアであるパーツがスタート及びエンドアドレスによって示されている。また、このようなパーツが複数個有り、つまりパーツテーブルが複数個有る場合はリンク情報により、リンク情報が『(00h) 』となるパーツテーブルまで順次指定されている。

図７にパーツテーブルにより、フリーエリアとなるパーツの管理状態を模式的に示す。これはパーツ(03h)(18h)(1Fh)(2Bh)(E3h) がフリーエリアとされている時に、この状態がテーブルポインタP-FRA に引き続きパーツテーブル(03h)(18h)(1Fh)(2Bh)(E3h) のリンクによって表現されている状態を示している。
なお、上記した欠陥領域や、未使用パーツテーブルの管理形態もこれと同様となる。

ところで、全く楽曲やデータファイルの記録がなされていないバージンディスクであって、しかも欠陥もない光磁気ディスクであれば、テーブルポインタP-FRA によってパーツテーブル(01h) が指定され、これによってディスクのレコーダブルユーザーエリアの全体がフリーエリアであることが示される。そしてこの場合、残る (02h)〜(FFh) のパーツテーブルは使用されていないことになるため、上記したテーブルポインタP-EMPTY によってパーツテーブル(02h) が指定され、また、パーツテーブル(02h) のリンク情報としてパーツテーブル(03h) が指定され、というようにパーツテーブル(FFh) まで連結される。この場合パーツテーブル(FFh) のリンク情報は以降連結なしを示す『(00h) 』とされる。
なお、このときパーツテーブル(01h) については、スタートアドレスとしてレコーダブルユーザーエリアのスタートアドレス（ＲＳＴ_A ）の値が記録され、またエンドアドレスとしてはリードアウトスタートアドレスの直前のアドレス（ＬＯ_A −１）の値が記録されることになる。

テーブルポインタP-TNO1〜P-TNO255は、光磁気ディスク１にユーザーが記録を行なったトラックについて示しており、例えばテーブルポインタP-TNO1では第１トラックのデータが記録された１又は複数のパーツのうちの時間的に先頭となるパーツが示されたパーツテーブルを指定している。

例えば第１トラックとされた楽曲がディスク上で１つのパーツで記録されている場合は、その第１トラックの記録領域はテーブルポインタP-TNO1で示されるパーツテーブルにおけるスタート及びエンドアドレスとして記録されている。

また、例えば第２トラックとされた楽曲がディスク上で複数のパーツに離散的に記録されている場合は、その楽曲の記録位置を示すため各パーツが時間的な順序に従って指定される。つまり、テーブルポインタP-TNO2に指定されたパーツテーブルから、さらにリンク情報によって他のパーツテーブルが順次時間的な順序に従って指定されて、リンク情報が『(00h) 』となるパーツテーブルまで連結される（上記、図７と同様の形態）。このように例えば２曲目を構成するデータが記録された全パーツが順次指定されて記録されていることにより、このＵ−ＴＯＣセクター０のデータを用いて、第２トラックの再生時や、その第２トラックの領域へのオーバライトを行なう際に、光学ヘッド２３及び磁気ヘッド２６をアクセスさせ離散的なパーツから連続的な音楽情報を取り出したり、記録エリアを効率使用した記録が可能になる。

さらに、本実施例では、ディスク１が後述するようにデータ記録用途にも兼用（又はデータ専用としてもよい）して用いられる場合があるが、このＵ−ＴＯＣにおいては、データ用途に使用されるデータトラックについても、楽曲の場合と同様に管理している。

なお、データトラックとは通常、複数のデータファイルによって構成されるもので、例えばディスク上で一般データが記録されたパーツは全て１つのデータトラックに含まれる。
１つのディスクにおいて一般データが記録されるパーツの全てを含んだ単位をボリュームとよぶ。

そして、光磁気ディスク上で一般データが記録されるパーツを全てリンクさせて１つのデータトラックとした場合、このデータトラック全体が１つのボリュームとなる。
なお、ハイブリッドディスクの場合ではピットエリアにもデータトラックが形成することができ、ピットエリアとレコーダブルユーザーエリアとで２つのデータトラックが存在する場合がある。

例えば図４のように第４トラックとしてデータトラックが存在する場合は、その領域はテーブルポインタP-TNO4によって管理される。
つまり、例えばテーブルポインタP-TNO4によって導かれるパーツテーブルにデータトラックのスタートアドレス及びエンドアドレスが示されている。また、データトラックが複数のパーツに分割されている場合は、各パーツのスタートアドレス及びエンドアドレスを示すパーツテーブルがリンクされている。

そして、この場合、パーツテーブルに示されたパーツがオーディオトラックではなくデータトラックを構成するパーツであることは、トラックモード情報で識別される。
トラックモードは、(01h) 〜(FFh) までの各パーツテーブルにおいてそれぞれ１バイト（ｄ₁ 〜ｄ₈ の８ビット）設けられているが、この各ビットがそれぞれ次のように各種モード状態を示している。

例えばビットｄ₁ はそのパーツが記録可／記録不可であるか、ビットｄ₂ はそのパーツがコピーライトプロテクトがなされているか、ビットｄ₃ はそのパーツがオリジナル／２世代以後のコピー記録か、ビットｄ₄ はそのパーツがオーディオデータか一般データか、ビットｄ₅ ，ｄ₆ はそのパーツがノーマルオーディオか否か、ビットｄ₇ はそのパーツがモノラルオーディオデータかステレオオーディオデータか、ビットｄ₈ はそのパーツのデータのエンファシス処理について、それぞれモードが示される。

従って、一般データエリアとしてパーツが管理される場合、対応するパーツテーブルにはこのトラックモードのうちビットｄ₄ が例えば『１』（オーディオデータの場合ビットｄ₄ ＝『０』）とされて、データトラックとして識別されることになる。
なお、一般データがプリマスタードピットとしてディスクにＲＯＭ化されて記録されている場合は、上記Ｐ−ＴＯＣにおいてプリマスタードの楽曲の場合と同様に管理されるが、この場合もパーツテーブルにおけるトラックモードのうちビットｄ₄ が『１』とされて、プリマスタードの楽曲と区別される。

II−５ データＵ−ＴＯＣセクター（第２の管理情報）

II−５−ａ 全体構造

上記のようにＵ−ＴＯＣにおいてはデータトラックとしてのパーツが管理されるのみであり、データトラック内の個々のデータファイルについての管理はデータＵ−ＴＯＣによって行なわれることになる。

図８にデータトラックの構造例を示す。図８（ａ）に示すようにデータトラックには物理的な先頭位置にデータＵ−ＴＯＣが記録される。つまり、データトラック内における最もディスク内周側に近い位置にデータＵ−ＴＯＣが記録される。データトラックが複数のパーツに別れている場合は、最もディスク内周側に位置するパーツの先頭にデータＵ−ＴＯＣが設けられることになる。
このデータＵ−ＴＯＣは、図８（ｂ）のように１クラスタのブートエリアと、１６クラスタのボリュームマネジメントエリアから構成されている。

図８（ｂ）からわかるように、データＵ−ＴＯＣに続くエリアはファイルエクステンツエリアとされている。このファイルエクステンツエリアには、図８（ａ）のように実際のデータファイルＦＬ₁ 〜ＦＬ₃ などが記録される。また未記録ブロックＥＢには、さらにデータファイルを記録していくことができる。

ボリュームマネジメントエリアは、図８（ｃ）のように５１２個のマネジメントブロックから構成される。１つのマネジメントブロックにおけるデータ領域は２０４８バイトとされる。
そして、このマネジメントブロックにおけるデータが実際のデータファイルの記録／再生のための管理情報となる。

各マネジメントブロックは、１〜５１２までのブロックナンバが付されている。そして、ブロックナンバ１のマネジメントブロックはボリュームディスクリプタＶＤとして使用される。また、ブロックナンバ２のマネジメントブロックはボリュームスペースビットマップＶＳＢとして使用され、ブロックナンバ３のマネジメントブロックはマネジメントテーブルとして使用される。
このブロックナンバ１〜３のマネジメントブロックについての使用形態は以上のように規定されている。ブロックナンバ４以降のマネジメントブロックはファイルエクステンツエリアの使用形態などに応じて使用される。
即ち、マネジメントテーブルＭＴ、ディレクトリレコードブロックＤＲＢ、エクステンツレコードブロックＥＲＢとして使用できる。

II−５−ｂ ブートエリア

ブートエリアはコンピュータプログラム等が存在する場合のプログラム位置などを示す領域として用いられる。

ブートエリアのセクター構造は図９又は図１０のようになる。
図９のブートエリアセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトに、各５１２バイトの４つのブロックデータが記録できる。即ちブロック０〜ブロック３であり、例えばブロック０はブロックデータ０−０からブロックデータ０−５１１で構成される。

ブロックデータが記録されるデータエリアに続いてＥＤＣ０〜ＥＤＣ３の４バイトのＥＤＣデータが記録される。続いてＥＣＣエリアとして、P-parity0 〜P-parity171 の１７２バイトのＰパリティ、及びQ-parity0 〜Q-parity103 の１０４バイトのＱパリティが記録される。

一方、図１０のタイプの場合は、データエリアとなる２０４８バイトに、各１０２４バイトの２つのブロックデータが記録できる。即ちブロック０、ブロック１であり、例えばブロック０はブロックデータ０−０からブロックデータ０−１２３で構成される。
他は図９と同様である。

II−５−ｃ ボリュームディスクリプタ

ボリュームメネジメントエリアにおける先頭のマネジメントブロックはボリュームディスクリプタＶＤとして使用される。
このボリュームディスクリプタＶＤは、ディスク上のデータトラック（ボリューム）の基本的な管理を行なうものである。

図１１にボリュームディスクリプタＶＤのセクター構造を示す。このセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトに各種管理情報が記録される。

まず、データエリアの２バイト目から６バイト目に、ボリュームディスクリプタのセクターであることを示すＩＤとして『ＭＤ００１』というコードが例えばアスキーコードで記録される。
続いてこのシステムのバージョンＩＤが記録される。

次にロジカルブロックサイズ、ロジカルクラスタサイズ、アロケーションブロックサイズが記録される。
ロジカルブロックとは、データトラックにおけるセクター内の実際のデータエリアに相当するもので、データトラックにおけるセクターは２３５２バイトのうち２０４８バイトをデータエリアと設定している。従って、ロジカルブロックサイズとしてバイト長である『２０４８』が記録される。ロジカルブロックは記録／再生におけるデータバイト最小単位となる。

またロジカルクラスタサイズはロジカルクラスタにおけるロジカルブロック数を示す。ロジカルクラスタとは、実際に管理情報やデータが記録されるクラスタである。そして、１クラスタは３６セクターとされ、そのうち３２セクター（３２ロジカルブロック）がデータ記録に用いられるため、ロジカルクラスタサイズとして『３２』が示される。

アロケーションブロックサイズとしてアロケーションブロックにおけるロジカルブロック数が示される。アロケーションブロックとはロジカルクラスタと同じデータ単位を示すものであり、データトラックにおける実際に管理情報やデータファイルが記録される部位である。例えば図８（ｂ）に示したボリュームマネジメントエリアやファイルエクステンツエリアにおけるロジカルクラスタとしての３２セクターの領域が、１つのアロケーションブロックとされる。

続いて、アロケーションブロック総数が記録される。これはボリューム内のアロケーションブロック総数である。ハイブリッドディスクの場合は、ピットエリアにおけるアロケーションブロック数も含まれる。
また記録可能アロケーションブロック総数として、レコーダブルエリアにおけるアロケーションブロック数が記録される。プリマスタードディスクの場合は、これはゼロとされる。

また、未記録アロケーションブロック数としてボリューム内の記録可能アロケーションブロックのうち、まだ記録されていないアロケーションブロックの数が記される。
さらに記録済アロケーションブロック数として、ボリューム内の記録可能アロケーションブロックのうち、既に記録が行なわれたアロケーションブロックの数が記される。
またディフェクトアロケーションブロック数として、傷などの欠陥があるアロケーションブロックの数が記される。

次に、ボリューム内のディレクトリの数、ボリューム内のデータファイルの数が記される。
次にＩＤ最大値が記録される。ディレクトリ又はデータファイルに対しては、生成される順にＩＤナンバが付されていくが、これはその最大値となる。

続いてボリューム属性が記録される。ここで、ボリュームマネジメントエリアがミラーモードで記録されているか否か、インビジブルファイルであるか否か、ライトプロテクトであるか否か、バックアップ必要か否か、ショートロケーション／ロングロケーションのいづれを使用しているか、などが記録される。

次にボリュームマネジメントエリアの長さとしてそのバイト長が記される。
またボリュームマネジメントエリアの位置として、ボリュームマネジメントエリアの最初のアロケーションブロックのナンバーが記録される。

続いて、このボリュームディスクリプタと同様に、ボリュームマネジメントエリア内のマネジメントブロックが使用されて形成される他の管理ブロック、即ちボリュームスペースビットマップＶＳＢ、マネジメントテーブルＭＴ、エクステントレコードブロックＥＲＢ、ディレクトリレコードブロックＤＲＢについて、それぞれ最初のブロックの位置と、そのブロック数が記録される。
続いて、ルートディレクトリのバイト長、及びルートディレクトリ内のディレクトリ数が記録される。

さらに、図１１においては各種ＩＤ等として示したが、以降データエリア内に各種のＩＤ及びキャラクタセットコード等が記録される。
即ち、ブートシステムＩＤ、ボリュームＩＤ及びそのキャラクタセットコード、パブリッシャーＩＤ及びそのキャラクタセットコード、データプリペアーＩＤ及びそのキャラクタセットコード、アプリケーションＩＤ及びそのキャラクタセットコードが記録される。
また、ボリュームの生成日時、ボリュームの更新日時、満了日時、有効日時が記録される。そしてデータエリアにおける１０２４〜２０４７バイトが、システムエクステンションエリアとされる。

なお、データエリアに続いて４バイトのＥＤＣエリア、及び２７６バイトのＥＣＣエリアが設けられている。ＥＣＣエリアには１７２バイトのＰパリティと１０４バイトのＱパリティが記録される。

II−５−ｄ ボリュームスペースビットマップ

ボリュームメネジメントエリアにおけるブロックナンバ２のマネジメントブロックはボリュームスペースビットマップＶＳＢとして使用される。
このボリュームスペースビットマップＶＳＢは、データトラックの全てのアロケーションブロックのタイプを示すものである。

図１２にボリュームスペースビットマップＶＳＢのセクター構造を示す。このセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトにおいて、１つのアロケーションブロックにつき２ビットづつが割り当てられ、そのタイプが示される。
なお、このボリュームスペースビットマップＶＳＢのセクターも、データエリアに続いてＥＤＣエリア及びＥＣＣエリアが設けられる。

図１３（ａ）にデータエリアの内容を示す。
データトラックにおけるアロケーションブロックには、ナンバー０から昇順にアロケーションブロックナンバが付されているが、ボリュームスペースビットマップＶＳＢのデータエリアの最初のバイトにおけるビット７，６が、ナンバー０のアロケーションブロックＡＬ₀ に割り当てられ、以降２ビットづつアロケーションブロックＡＬ₁ ，ＡＬ₂ ・・・・・ と割り当てられる。
従って、ボリュームスペースビットマップＶＳＢのデータエリアにおいて、アロケーションブロックＡＬ₀ 〜ＡＬ₈₁₉₁までの情報を記すことができ、全てのアロケーションブロックに十分に対応できる。

２ビットの情報は図１３（ｂ）のとおりである。つまり、未記録アロケーションブロックについては『００』、記録済アロケーションブロックについては『０１』、ディフェクト（欠陥）アロケーションブロックについては『１０』、未定義のアロケーションブロックについては『１１』とされる。
なお、データエリアにおいて余りの部分、つまり対応するアロケーションブロックが存在しないビットについては『１１』とされる。

II−５−ｅ マネジメントテーブル

ボリュームメネジメントエリアにおけるブロックナンバ３のマネジメントブロックはマネジメントテーブルＭＴとして使用され、またブロックナンバ４以降のマネジメントブロックもマネジメントテーブルとして使用できる。
このマネジメントテーブルＭＴは、ボリュームマネジメントエリアにおける各マネジメントブロックの使用形態を示している。

図１４にマネジメントテーブルＭＴのセクター構造を示す。このセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトにおいて、１つのマネジメントブロックにつき４バイトづつを割り当て、各マネジメントブロックの管理を行なう。
即ち、マネジメントブロック０エントリーからマネジメントブロック５１１エントリーにより、ボリュームマネジメントエリアにおける５１２個のマネジメントブロックのそれぞれの使用内容が示される。
なお、データエリアに続いてＥＤＣエリア及びＥＣＣエリアが設けられる。

マネジメントブロック０エントリーからマネジメントブロック５１１エントリーのそれぞれにおける４バイトのデータ内容を図１５に示す。
最初のマネジメントブロック（マネジメントブロック０）は上述したようにボリュームディスクリプタに使用される。
この場合、マネジメントブロック０エントリーでは、マネジメントブロック０がボリュームディスクリプタであることを示すため、図１５（ａ）のように第４バイト目にエントリータイプとして『８０ｈ』が記される。

また、２番目のマネジメントブロック（マネジメントブロック１）は上述したようにボリュームスペースビットマップに使用される。
この場合、マネジメントブロック１エントリーでは、マネジメントブロック１がボリュームディスクリプタであることを示すため、図１５（ｂ）のように第４バイト目にエントリータイプとして『９０ｈ』が記される。また、第１、第２バイト目において、未記録アロケーションブロック数が記録される。

マネージメントテーブルとされるマネジメントブロックに対応するエントリーでは、図１５（ｃ）のように、第１、第２バイト目に次のマネージメントテーブルの位置が記録され、第３バイト目に未使用のマネジメントブロック数が記録される。そして、そのマネジメントブロックがマネージメントテーブルであることを示すために、第４バイト目にエントリータイプとして『Ａ０ｈ』が記される。

エクステントレコードブロックとされるマネジメントブロックに対応するエントリーでは、図１５（ｄ）のように、第１、第２バイト目に次のエクステントレコードブロックの位置が記録され、第３バイト目に未使用のエクステントレコードブロック数が記録される。そして、そのマネジメントブロックがエクステントレコードブロックであることを示すために、第４バイト目にエントリータイプとして『Ｂ０ｈ』が記される。

ディレクトリレコードブロックは、１つのマネジメントブロックを用いて記したディレクトリレコードでディレクトリが完結され、単独で用いられる場合と、１つのディレクトリに含まれるディレクトリレコードが、複数のマネジメントブロック、即ち複数のディレクトリレコードブロックにわけて記録される場合がある。

或るマネジメントブロックが単独ディレクトリレコードブロックとされる場合は、そのマネジメントブロックに対応するエントリーでは、図１５（ｅ）のように０〜２９ビットまででディレクトリＩＤが記録され、最後の２ビットがエントリータイプとして『００ｈ』とされる。

また或るマネジメントブロックが複数ディレクトリレコードブロックの最初のディレクトリレコードブロックとされる場合は、そのマネジメントブロックに対応するエントリーでは、図１５（ｆ）のように第１、第２バイト目に次のディレクトリレコードブロックの位置が記録され、第３バイト目にディレクトリＩＤの上位バイトが記録される。そして、そのマネジメントブロックが第１のディレクトリレコードブロックであることを示すために、第４バイト目にエントリータイプとして『Ｄ０ｈ』が記される。

或るマネジメントブロックが複数ディレクトリレコードブロックの中間の（つまり第１又は最後ではない）ディレクトリレコードブロックとされる場合は、そのマネジメントブロックに対応するエントリーでは、図１５（ｇ）のように第１、第２バイト目に次のディレクトリレコードブロックの位置が記録される。そして、そのマネジメントブロックが中間のディレクトリレコードブロックであることを示すために、第４バイト目にエントリータイプとして『Ｅ０ｈ』が記録される。

或るマネジメントブロックが複数ディレクトリレコードブロックの最後のディレクトリレコードブロックである場合は、そのマネジメントブロックに対応するエントリーでは、図１５（ｈ）のように第１、第２、第３バイト目にディレクトリＩＤの下位バイトが記録される。そして、そのマネジメントブロックが最後のディレクトリレコードブロックであることを示すために、第４バイト目にエントリータイプとして『Ｆ０ｈ』が記録される。

II−５−ｆ ディレクトリレコードブロック

ボリュームメネジメントエリアにおけるブロックナンバ４以降のマネジメントブロックはディレクトリレコードブロックＤＲＢとして使用できる。
このディレクトリレコードブロックＤＲＢには、１又は複数のディレクトリレコードが記録される。

ディレクトリレコードとしては、ディレクトリを構成するためのディレクトリレコードと、或るデータファイルに対応してその位置などを指定するためのディレクトリレコードがある。

図１６はディレクトリを構成するためのディレクトリレコードが記録されるディレクトリレコードブロックＤＲＢのセクター構造を示す。このセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトにおいて、１又は複数のディレクトリレコードが記録できる。

ディレクトリレコードの１つのユニットとしては、まずディレクトリレコード長が示される。ディレクトリレコードの１つのユニットの長さは可変長とされているため、このディレクトリレコード長によって、そのディレクトリレコードのバイト長が示される。
続いてディレクトリの属性が記録される。これによって、このディレクトリレコードがディレクトリのためのディレクトリレコードか、このディレクトリレコードが含まれるディレクトリがインビジブルディレクトリであるか、システムディレクトリであるか、などの各種属性が示される。

続いて、キャラクタセットコード及びショートネームＩＤが記録される。キャラクタセットコードはショートネームＩＤのキャラクタ種別を示す。
ショートネームＩＤは１１バイトで記録されるＩＤである。

続いて、ディレクトリ生成日時、ディレクトリ更新日時が記され、ステイタス更新日時としてこのディレクトリレコードの更新日時が記される。
さらにディレクトリＩＤナンバ、ディレクトリ長が示される。

続いてディレクトリ位置として、このディレクトリレコードが含まれるディレクトリにおける最初のディレクトリレコードが記録されたディレクトリレコードブロックの位置が記される。
また、ディレクトリレコード数として、このディレクトリレコードが含まれるディレクトリにおけるディレクトリレコード数が記録される。

続いてロングネームＩＤの長さが記され、その長さによるロングネームＩＤが記録される。つまりロングネームＩＤは可変長である。なおロングネームＩＤを記録しない場合もあるが、そのときはロングネームＩＤの長さは『００ｈ』とされる。
また、ロングネームＩＤの長さが偶数バイトになった場合のみ、あまりバイトを埋めるためパディングとして『００ｈ』が記録される。
ロングネームＩＤに続くバイトは、システムエクステンションエリアとして利用される。

ディレクトリに対応するディレクトリレコードの１ユニットはこのように構成され、このようなディレクトリレコードを２０４８バイトのデータエリア内において複数個設けることができる。
なお、データエリアに続いてＥＤＣエリア及びＥＣＣエリアが設けられる。

次に、図１７は或るデータファイルに対応するディレクトリレコードが記録されるディレクトリレコードブロックＤＲＢのセクター構造を示す。
データファイルが１つのファイル単位で構成される場合のみ、このセクターのディレクトリレコードによって直接その位置等が示される。
データファイルが複数のファイル単位で構成される場合は、そのデータファイルの位置などについては、ディレクトリレコードによって直接示されることはなく、後述するエクステンツレコードブロックに示されることになる。

このセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトにおいて、それぞれデータファイルに対応する１又は複数のディレクトリレコードを記録できる。

ディレクトリレコードの１つのユニットとしては、上記図１６におけるディレクトリレコードと同様に、まずディレクトリレコード長が示され、続いて属性が記録される。この属性によって、このディレクトリレコードがディレクトリに対応するものではないことや、対応するデータファイルがインビジブルファイルであるか、システムファイルであるか、そのデータファイル位置がエクステントレコードによって指定されるものであるか、などの各種属性が示される。

続いて、図１６のディレクトリレコードと同様に、キャラクタセットコード、ショートネームＩＤ、ディレクトリ生成日時、ディレクトリ更新日時、ステイタス更新日時が記される。

続いてデータファイルのＩＤナンバ、データファイル長が示される。
また、そのデータファイルの位置が示され、続いてそのデータファイルにおいて使用されているアロケーションブロック数が記される。
さらにアソシエイトデータ長、アソシエイトデータ位置、アソシエイトデータのアロケーションブロック数が記される。

その後、可変長であるロングネームＩＤの長さが記され、その長さによるロングネームＩＤが記録される。ロングネームＩＤを記録しない場合はロングネームＩＤの長さは『００ｈ』とされる。
また、ロングネームＩＤの長さが偶数バイトになった場合のみ、あまりバイトを埋めるためパディングとして『００ｈ』が記録される。
ロングネームＩＤに続くバイトは、システムエクステンションエリアとして利用される。

データファイルに対応するディレクトリレコードの１ユニットはこのように構成され、このようなディレクトリレコードを２０４８バイトのデータエリア内において複数個設けることができる。
なお、データエリアに続いてＥＤＣエリア及びＥＣＣエリアが設けられる。

II−５−ｇ エクステントレコードブロック

ボリュームメネジメントエリアにおけるブロックナンバ４以降のマネジメントブロックはエクステントレコードブロックＥＲＢとして使用できる。
このエクステントレコードブロックＥＲＢには、１又は複数のエクステントレコードが記録できる。

エクステントレコードとしてはエクステントレコードインデックスとエクステントディスクリプタの２種類のデータを記録することができる。
エクステントディスクリプタは、実際にデータファイルを構成するファイル単位の位置を示すための情報である。上記したようにディレクトリレコードがデータファイルの位置を示すのは、そのデータファイルが１つのファイル単位によって構成される場合のみである。データファイルが複数のファイル単位によって構成される場合、各ファイル単位の位置は、エクステントディスクリプタによって指定される。

またエクステントレコードインデックスは、他のエクステントレコードの位置を示す情報であり、これによってエクステントレコードのツリー構造を形成することができる。

また、エクステントレコードではファイル単位の位置を示す方法として１６ビットアドレスによるショートロケーションと、３２ビットアドレスによるロングロケーションがある。どちらが採用されているかは前述したボリュームディスクリプタにおいて示されている。

図１８はショートロケーションによるエクステントレコードブロックＤＲＢのセクター構造を示す。
このセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトにおいて、１又は複数のエクステントレコードを記録できる。１つのエクステントレコードは３２バイトで構成される。

この図では、データエリアの最初の３２バイトのエクステントレコードとしてエクステントレコードインデックスが含まれるエクステントレコードが記録されている例をあげている。

エクステントレコードインデックスが記録されるエクステントレコードでは、最初にインデックスＩＤが記録される。このインデックスＩＤは『ＦＦＦＦｈ』とされて、このエクステントレコードがエクステントレコードインデックスを含むことが示される。

続いてマキシマムディプスが記録される。エクステントレコードインデックスによりエクステントレコードのツリー構成が構築されるが、マキシマムディプスによって、このエクステントレコードから指定されていくサブツリー階層が示される。
もしエクステントレコードインデックスが、エクステントディスクリプタを含むエクステントレコードを指定している場合、つまり最下層の場合は、マキシマムディプスは『００００ｈ』とされる。

そして、その後に、エクステントレコードインデックスを最大７個記録することができる。つまりエクステントレコードインデックス０〜エクステントレコードインデックス７、及びロジカルオフセット０〜ロジカルオフセット７である。各エクステントレコードインデックス０〜７として、他のエクステントレコードのインデックスが示され、それに対応してロジカルオフセットとしてそのエクステントレコードの論理的な位置が示される。エクステントレコードインデックスとは、マネージメントブロックエリア内のどのアロケーションテーブルかを示すデータである。
エクステントレコードのインデックスは、エクステントレコードのエントリーナンバとマネジメントブロックナンバで示される。

なお、１つのエクステントレコード内に、エクステントレコードインデックスを含むエクステントレコードを指定するエクステントレコードインデックスと、エクステントディスクリプタを含むエクステントレコードを指定するエクステントレコードインデックスとが併存することはない。

図１８の例では、データエリアにおける２つ目のエクステントレコードとしてエクステントディスクリプタが含まれるエクステントレコードが記録されている。エクステントディスクリプタは、１つのエクステントレコード内に最大８個記録することができる。即ち、エクステント０スタート位置〜エクステント７スタート位置、及びエクステント０ブロック数〜エクステント７ブロック数である。

エクステントｘスタート位置として、そのファイル単位のスタート位置が記録される。つまりそのファイル単位の最初のアロケーションブロックのナンバが記される。またそのファイル単位を構成するアロケーションブロック数がエクステントｘブロック数として記録される。

以上のようにエクステントレコードは最大７個のエクステントレコードインデックス、もしくは最大８個のエクステントディスクリプタを記録できる。
このようなエクステントレコードを２０４８バイトのデータエリア内において最大６４個設けることができる。
なお、データエリアに続いてＥＤＣエリア及びＥＣＣエリアが設けられる。

次に、図１９はロングロケーションによるエクステントレコードブロックＤＲＢのセクター構造を示している。
実質的なデータ内容はショートロケーションの場合と同様であるため、重複説明を避けるが、ショートロケーションでは各データはそれぞれ２バイトで記録されていたが、このロングロケーションでは、各データはそれぞれ４バイトで記録される。

この場合も、エクステントレコードは最大７個のエクステントレコードインデックス、もしくは最大８個のエクステントディスクリプタを記録できる。
そして、ロングロケーションの場合、１つのエクステントレコードは６４バイトで構成されるため、２０４８バイトのデータエリア内において最大３２個設けることができる。
なお、同様に、データエリアに続いてＥＤＣエリア及びＥＣＣエリアが設けられる。

II−６ データセクター

次に、データファイルが記録されるファイルエクステンツエリアにおけるセクターの構造を説明する。

図２０はデータ用セクターのフォーマットを示している。
４×５８８の２３５２バイトのセクターの先頭１２バイトは同期パターンとされ、続いてクラスタアドレス（Cluster H ，Cluster L ）、セクターアドレス（sector）、モード情報が記録されてヘッダとされる。

続いての４バイトにはアプリケーション側のためのアドレスエリア（Logical Sector 0 〜Logical Sector 3）が設けられる。また、続いてエラー訂正モードを示す情報（Mode) 、データファイルの属性を示すカテゴリー情報（Category）、データファイルのパラメータを示すインデックス情報（Index ）が設けられる。インデックス情報としての具体的な例はカテゴリー情報及びアプリケーションにより決定されるが（後述）、インデックス情報が『００ｈ』であるときは、データ記録内容（つまりボリュームが）ゼロであることを示すことになる。エラー訂正モードを示す情報（Mode) 及びデータファイルの属性を示すカテゴリー情報（Category）については後述する。
またID0 〜ID3 の４バイトとしてシステムＩＤが付加される。

Data Byte0〜Data Byte2047 として示した２０４８バイトのデータエリアには実際のファイルデータが記録される。
データエリア以降の２７６バイトは付加エリアとされている（Aux 0 〜Aux 275 ）。この付加エリアは、上述したマネジメントブロックのセクターのようにＥＤＣエリアやＥＣＣエリアとして使用できる。
付加エリアの使用形態は、このセクターの第２１バイト目のエラー訂正モードを示す情報（Mode) によって示される。

例えば、Mode＝『００ｈ』の場合は、特にエラー検出及び訂正用のデータを付加するエリアは設けられていない。つまり４×５１９バイト目以降の付加エリア（Aux 0 〜Aux 275 ）は未定義のままである。
この場合、このディスクからの再生情報に関しては、記録再生装置において図２に示すデコーダ２８でＣＩＲＣコードによるエラー検出、訂正処理がなされるのみであるが、ＣＩＲＣコードはよく知られているように実用上十分なエラー訂正能力を有するものであり特にエラー処理について問題は生じない。

Mode＝『０１ｈ』の場合は、エラー検出及び訂正用のデータとしてエラー検出用パリティが４バイト付加されている。即ち２０４８バイトのデータエリアに続く４バイトにパリティ（ＥＣＤ０〜ＥＣＤ３）が付加される。これにより未定義の付加エリアは（Aux 4 〜Aux 275 ）と示した２７２バイトとなる。
このパリティＰ_(X) （つまりＥＣＤ０〜ＥＣＤ３）についての生成多項式は、Ｐ_(X) ＝（ｘ¹⁶＋ｘ¹⁵＋ｘ² ＋１）（ｘ¹⁶＋ｘ² ＋ｘ＋１）
である。
この場合、このディスクからの再生情報に関しては、記録再生装置において図２に示すデコーダ２８からのエラー検出結果を用いずに、デコーダ２８からのデジタル信号出力のみでエラー検出を行なうことができる。

Mode＝『０２ｈ』の場合は、付加エリアの全てについてエラー検出及び訂正用のデータが使用される。つまり２０４８バイトのデータエリアに続く１７２バイトにＰパリティ（P-parity0 〜P-parity171 ）が付加され、さらに続く１０４バイトにＱパリティ（Q-parity0 〜Q-parity103 ）が付加される。これにより最大８０バイト程度のエラー訂正能力が実現される。
このＰパリティ及びＱパリティはいわゆるＣＤ−ＲＯＭで採用されているガロアフィールド（Garoa Field ）（２⁸ ）との距離（２６，２４）のリードソロモンコードと同様の構成となっている。

次にこのセクターの第２２バイト目に設けられるカテゴリー情報（Category）の定義について説明する。
・・・カテゴリー情報（Category）＝『００ｈ』の場合。
データエリアの状態に関わらず、このセクターがデータが記録されていないオープンセクターであることを示す。従って、セクターの内容を消去したい場合は、このカテゴリー情報（Category）を『００ｈ』に書き換えればよい。

・・・カテゴリー情報（Category）＝『０１ｈ』の場合。
このセクターにバイナリデータが記録されていることを示す。データの種類には制限がない。このようなセクターは、データエリアに記録されたバイトをそのままデジタルデータとしてアプリケーション（ソフトウエア）側に渡すような使い方がされることになる。なお、カテゴリー情報がこの『０１ｈ』である場合、続くインデックス情報としては、（Index ）としてのバイトに記録されている数値×１２８バイトの大きさだけデータ領域が確保されていることを示すこととなる。なお、データエリアは２０４８バイトであるため、インデックス情報（Index ）は『００ｈ』〜『１０ｈ』の内のいづれかの値をとることになる。

・・・ カテゴリー情報（Category）＝『１０ｈ』〜『１Ｆｈ』の場合。
このセクターにドキュメント（文書）データが記録されていることを示す。
この場合も、続くインデックス情報としては同様に、（Index ）としてのバイトに記録されている数値×１２８バイトの大きさだけデータ領域が確保されていることを示すこととなる。

・・・ カテゴリー情報（Category）＝『２０ｈ』〜『２Ｆｈ』の場合。
このセクターにシングルドットイメージ、つまり１枚のイメージファイルが白黒のドットデータとして記録されていることを示す。この場合も、続くインデックス情報としては同様に、（Index ）としてのバイトに記録されている数値×１２８バイトの大きさだけデータ領域が確保されていることを示す。

・・・ カテゴリー情報（Category）＝『３０ｈ』〜『３Ｆｈ』の場合。
このセクターにマルチプルドットイメージ、つまり複数枚のイメージファイルが白黒のドットデータとして記録されていることを示す。この場合も、続くインデックス情報としては同様に、（Index ）としてのバイトに記録されている数値×１２８バイトの大きさだけデータ領域が確保されていることを示す。

III ．データファイル再生処理

以上のようなディスク構造のディスクに対して図２の記録再生装置でデータファイルを再生する処理について図２、図４及び図２１を用いて説明する。

図２１はデータファイル再生のためのシステムコントローラ２１の処理を示している。
データファイル再生のためには、ディスク１に対してシステムコントローラ２１はまずリードインエリアに光学ヘッド２３をアクセスさせてＰ−ＴＯＣを読み込む(F101)。ここで、Ｐ−ＴＯＣが読み込めなかった場合は、そのディスクは正しいディスクではない、もしくは再生操作がされた際にディスクが装填されていなかったと判断して、ステップF102からF103に進み、ディスクエラーとする。

Ｐ−ＴＯＣが読み込めた場合は、続いてＰ−ＴＯＣにおけるＵ−ＴＯＣスタートアドレス（ＵＳＴ_A ）に基づいてアクセスを行ない、記録再生管理エリアにおけるＵ−ＴＯＣを読み込む(F104)。
ここでＵ−ＴＯＣが読み込めなかった場合、即ちＵ−ＴＯＣが記録されていなかった場合は、そのディスクはバージンディスクであると判断する (F105→F106) 。

Ｕ−ＴＯＣが読み込めたら、システムコントローラ２１は、このＵ−ＴＯＣに管理されているトラックとして、データトラックが存在するか否かを確認する。つまり、パーツテーブルのトラックモード情報として、ビットｄ₄ ＝『１』であるパーツが存在するか否かを確認する(F107)。
存在しなければ、即ちそのディスクにはデータファイルが記録されていないことになるため、データファイル再生処理は終了する (F107→NO) 。

なお、オーディオトラックを再生する場合は、この時点でＵ−ＴＯＣのデータから光学ヘッド２３を所要のオーディオトラックにアクセスさせ、データを読み出すことになる。そして、ＲＦアンプ２７、デコーダ２８、バッファＲＡＭ３３、音声圧縮デコーダ３８、Ｄ／Ａ変換器３９を介して出力端子１６ｂからオーディオ信号として出力する。

データトラックが存在する場合は、ステップF108に進み、まずＵ−ＴＯＣからデータトラックを構成するパーツのうち一番小さいアドレスを含むパーツを探してアクセスさせる。つまり、データトラックの内の一番ディスク内周側となる部位に光学ヘッド２３をアクセスさせる。
上述したように、データトラックを管理するためのデータＵ−ＴＯＣはデータトラックの内の一番ディスク内周側の部位に位置するものである。
そこで、その部位にアクセスさせてデータＵ−ＴＯＣを読み込む(F109)。つまり、システムＩＤが『ＭＤ００１』とされているボリュームディスクリプタから始まるボリュームマネジメントエリアにおいて使用されているマネジメントブロックを読み込む。

データＵ−ＴＯＣが読み込めたことで、データファイルの再生が可能となる。そして、データファイル再生のための各種操作、即ち再生すべきデータファイルの指定操作に応じて(F110)、ディレクトリレコードもしくはエクステントレコードによって示される位置にアクセスさせ、そのデータファイルを読み込み、バッファＲＡＭ３３に取り込む(F111)。

そして、操作などに応じて所定の出力態様で出力する(F112)。例えば表示コントローラ３５を介して表示部１３に出力したり、通信回路３４を介してコネクタ部１５から他の機器に出力する。
他のデータファイルの再生操作がなされた場合は、再びステップF113からF110に戻って、処理が繰り返される。

以上のように、データファイル再生の場合はＰ−ＴＯＣからＵ−ＴＯＣをたどり、さらにＵ−ＴＯＣからデータＵ−ＴＯＣをたどって、上述したデータＵ−ＴＯＣ（ボリュームマネジメントエリア）内のディレクトリ構造に従って再生処理を行なうことになる。

IV ．簡易Ｕ−ＴＯＣを用いた記録再生方式（タイプＡ）

ところで、以上のようにデータＵ−ＴＯＣを用いるデータファイルの記録／再生処理の管理は、上記したデータＵ−ＴＯＣ内の複雑なディレクトリ構成に従って実行される。上記のデータＵ−ＴＯＣによりデータファイルの階層構造を形成したり複雑なオペーレーションを行なうことが可能となり、高性能なデータ記録／再生機器を実現できることになるが、この場合、データＵ−ＴＯＣの編集、例えばファイルソート、ファイルリンク構造の変更などのために、記録再生装置としてはメモリ容量を大きくし、また消費電力は大きくなってしまう。
このため、携帯用小型の記録再生装置を実現したい場合などでは、データＵ−ＴＯＣをそのまま用いることは不利なものとなってしまう。

そこで、本実施例では上記したデータＵ−ＴＯＣによるファイル記録／再生方式に加え、データＵ−ＴＯＣとは別に簡易なデータファイル管理を行なう簡易Ｕ−ＴＯＣを用いた、小型機器にも好適な記録／再生方式を実現する。
この記録再生方式は、もちろん図２の記録再生装置でも実現できるし、ほぼ同様の構成の小型携帯用の記録再生装置としても採用できる。そして、小型携帯用の記録再生装置では、簡易Ｕ−ＴＯＣによる記録／再生のみが実行できるものとすることで、メモリ容量の削減、電力消費の削減が実現できる。
例えば携帯用スチルカメラなどにおいて、撮影した画像データをディスクに記録させることができるようにする場合などに好適である。

なお、この簡易Ｕ−ＴＯＣを用いた記録再生方式としては、簡易Ｕ−ＴＯＣの記録位置に関して２通りの方式が考えられるが、これをタイプＡ、タイプＢとしてわけて説明する。タイプＡとは簡易Ｕ−ＴＯＣがレコーダブルユーザーエリア内に記録されるタイプであり、タイプＢとは簡易Ｕ−ＴＯＣが記録再生管理エリア内に記録されるタイプであるとする。
最初にタイプＡについて述べる。

IV−１ 簡易Ｕ−ＴＯＣセクター（第３の管理情報）

まず簡易Ｕ−ＴＯＣのセクター構造を説明する。なお、これはタイプＡ、タイプＢに共通である。
この簡易Ｕ−ＴＯＣは、データファイルに対する簡易ディレクトリを有するものである。

簡易Ｕ−ＴＯＣのセクター構造は図２２に示される。
このセクターの場合、同期パターン及びクラスタアドレス(cluster H ,cluster L)、セクターアドレス(sector)、及びモード(mode)によるヘッダに続いて、所定バイト位置からシステムＩＤが記録される。
このシステムＩＤとしては、『ＭＩＥＸ』というコードがアスキーコードにより記録される。この『ＭＩＥＸ』により、そのセクターが簡易Ｕ−ＴＯＣとして使用されていることが示される。

データエリアとなる２０４８バイトには１ユニットが３２バイトで構成されるディレクトリユニットを６４単位の記録することができる。
３２バイトのディレクトリユニット（つまり１つのディレクトリ）は或るデータファイルに対応して設けられるものである。

ディレクトリユニットにおいて先頭の８バイト（Name0 〜Name7 ）にはデータファイルの名称が記録される。また、続く３バイト（Suffix0 〜Suffix2 ）には拡張子が記録されるように割り当てられている。 例えばこの簡易Ｕ−ＴＯＣに管理された状態でレコーダブルユーザーエリアに記録されているデータファイルを検索する際には、このディレクトリユニットの名称及び拡張子が用いられる。

拡張子に続く１バイトにはカテゴリー情報(Category ）が配される。このカテゴリー情報(Category ）は、このディレクトリユニットの対応するデータファイルの属性を示すもので、図２０を用いて前述したデータセクターのフォーマットの中で説明したカテゴリー情報と同様のものである。

続く２バイトのボリューム情報（Volume1-0 ，Volume1-1 ）は、このディレクトリが示すデータファイルが使用しているアロケーションブロック（クラスタ）数を表わしている。つまりデータファイルの再生にいくつのアロケーションブロックのアクセスが必要かを示す。

続く２バイトのインデックス情報（Index0，Index1）は、この簡易Ｕ−ＴＯＣセクターと同じクラスタ内に、そのデータファイルの参照情報としてのヘディングセクターが存在する場合に用いられるもので、インデックス情報（Index0）としてそのヘディングセクターのセクターナンバが記録され、インデックス情報（Index1）としてそのヘディングセクターのセクター内におけるパーツナンバが記録されている。
ヘディングセクターが存在しない場合はインデックス情報（Index0）＝『００ｈ』とされる。

次のバイトには消去防止フラグ(Flag)が記録される。
消去防止フラグ(Flag)＝『００ｈ』の場合は、そのディレクトリユニットが対応するデータファイルが消去可能とされ、また、消去防止フラグ(Flag)＝『０１ｈ』の場合は、そのディレクトリユニットが対応するデータファイルが消去不可とされる。

続く５バイトにはそのディレクトリユニットが対応するデータファイルが最後に更新された日時情報が記録される。即ち、年、月、日、時、分の情報が、それぞれ(Year)、(Month) 、(Day) 、(Hour)、(Minutes) としての各バイトに記録される。

続いて対応するデータファイルのアドレスが記録される。即ち(Cluster-H）(Cluster-L）の２バイトでクラスタアドレスが示され、（Sector）の１バイトでセクターアドレスが示される。
以上の構成でディレクトリユニットが形成され、各データファイルについての検索情報として機能することになる。

IV−２ 簡易Ｕ−ＴＯＣが記録された場合の管理形態

簡易Ｕ−ＴＯＣがレコーダブルユーザーエリア内に記録されるタイプＡにおける、簡易Ｕ−ＴＯＣが記録された場合の管理形態例を、各場合にわけて図２３，図２５，図２７に示す。
図２３，図２５，図２７は、簡易Ｕ−ＴＯＣによって管理を行なうデータファイルを記録した場合のトラック状態及びその管理形態を示すものである。つまり、簡易Ｕ−ＴＯＣによるデータファイル記録機能を備えた記録装置によってディスクにデータファイルが記録された状態である。この記録方式については後述する。

なお、ここで説明する各例は、実行することができる３種類の管理形態を示すものであり、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ の記録される位置についてはフリーエリアのどこかを用いればよいものであって、記録位置が管理形態の種別の特定に影響を与えるものではない。このタイプＡ、及び後述するタイプＢについての記録位置の設定については後にまとめて説明する。

まず図２３の例は、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣの両方によってディフェクトエリアとして管理される例である。

図２３（ａ）に示すように、オーディオトラックＭ₁ ，Ｍ₂ ，Ｍ₃ 、データトラック、即ちデータＵ−ＴＯＣ、データファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢ、に対して、物理的に離れた位置に簡易Ｕ−ＴＯＣと、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている。

この場合、Ｕ−ＴＯＣによっては、図２３（ｂ）のようにオーディオトラックＭ₁ ，Ｍ₂ ，Ｍ₃ が管理され、またデータＵ−ＴＯＣ、データファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢについては、一括してデータトラックとして管理されている。また、フリーエリアもＵ−ＴＯＣで管理される。
そして、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域は、Ｕ−ＴＯＣ上では、テーブルポインタP-DFA から示されるディフェクトエリアとして管理されている。即ち、Ｕ−ＴＯＣ上では簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ の領域は記録／再生動作にとって無効な領域とみなされる。

また、データＵ−ＴＯＣによっては、図２３（ｃ）のようにデータファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢの管理が行なわれている。
そして、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域は、データＵ−ＴＯＣ上でもディフェクトエリアとして管理されている。つまり、この領域はデータＵ−ＴＯＣで管理されるデータトラックとしての領域ではないが、ボリュームスペースビットマップ上においてこの領域に含まれるアロケーションブロックはディフェクトアロケーションブロックとして示されている状態である。
従って、データＵ−ＴＯＣ上でも簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ の領域は記録／再生動作にとって無効な領域とみなされる。

そして、簡易Ｕ−ＴＯＣにとっては、図２３（ｄ）のようにデータファイルＫＦＬ₁ ，ＫＦＬ₂ が有効なデータファイルとして管理される。
従って、データファイルＫＦＬ₁ ，ＫＦＬ₂ については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。

また、このような簡易Ｕ−ＴＯＣに管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ は、それをデータＵ−ＴＯＣの管理下に組み込んで、データＵ−ＴＯＣを用いた再生操作によっても、再生可能とすることができる。

図２３の状態からデータファイルＫＦＬ₂ をデータＵ−ＴＯＣの管理下に組み込んだ状態を図２４に示す。
この場合、図２４（ｂ）のようにＵ−ＴＯＣ上では、データファイルＫＦＬ₂ のエリアがデータトラックの一部となるパーツとされるように更新される。
そしてデータＵ−ＴＯＣでは、図２４（ｃ）のように、それまでディフェクトエリアとしていた部位のうち、データファイルＫＦＬ₂ に相当する部位を、新たなデータファイルＦＬ₄ として管理することになる。

簡易Ｕ−ＴＯＣでは図２４（ｄ）のように基本的に管理状態は変わらないが、データファイルＫＦＬ₂ については、これを削除禁止とする。つまり、図２２に示した構成のディレクトリユニットにおいて、データファイルＫＦＬ₂ に対応するディレクトリユニットの消去防止フラグ(Flag)を『０１ｈ』とする。

これは、データファイルＫＦＬ₂ がデータファイルＦＬ₄ としてデータＵ−ＴＯＣの管理に組み込まれたことに伴い、簡易Ｕ−ＴＯＣを用いた記録や編集動作によって消去されてしまうことを防止するためである。
つまり、簡易Ｕ−ＴＯＣを用いた記録／編集により、データファイルＫＦＬ₂ が消去されたりオーバライトされてしまうと、データＵ−ＴＯＣにおけるデータファイルＦＬ₄ が、管理されているが実態の無いものとなってしまうためであり、これを避ける手段として、データファイルＫＦＬ₂ が消去禁止ファイルとされる。
従ってこれを消去したいときは、データＵ−ＴＯＣによる動作において消去することになる。

なお、図２３の例としては、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣの両方によってディフェクトエリアとして管理されているが、これをＵ−ＴＯＣのみがディフェクトエリアとして管理し、データＵ−ＴＯＣではデータトラック外であるとして管理をしないようにしてもよい。

次に、図２５の例は、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、データＵ−ＴＯＣによってディフェクトエリアとされ、Ｕ−ＴＯＣではディフェクトエリアとされていない状態で管理されている例である。

図２５（ａ）に示すように、データトラック、即ちデータＵ−ＴＯＣ、データファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢ、に対して、連続した位置に簡易Ｕ−ＴＯＣと、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている。

もちろん、このような位置に記録された場合でも、上記図２３と同様の管理形態とすることもできるが、この例では、Ｕ−ＴＯＣによっては、図２５（ｂ）のように簡易Ｕ−ＴＯＣとデータファイルＫＦＬ₁ ，ＫＦＬ₂ が、データトラックの一部と見なされて管理されている。従って、図２３のような簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域をディフェクトエリアとする管理は行われていない。

一方、データＵ−ＴＯＣによっては、図２５（ｃ）のようにデータファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢの管理が行なわれて。そして、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域は、データトラック内におけるディフェクトエリアとして管理されている。つまり、この領域に含まれるアロケーションブロックはボリュームスペースビットマップ上においてディフェクトアロケーションブロックとして示されている。
従って、データＵ−ＴＯＣ上では、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ の領域はデータトラック内において記録／再生動作無効な領域とみなされる。

そして、簡易Ｕ−ＴＯＣにとっては、図２５（ｄ）のようにデータファイルＫＦＬ₁ ，ＫＦＬ₂ が有効なデータファイルとして管理される。
従って、この場合もデータファイルＫＦＬ₁ ，ＫＦＬ₂ については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。

また、このような簡易Ｕ−ＴＯＣに管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ は、それをデータＵ−ＴＯＣの管理下に組み込んで、データＵ−ＴＯＣを用いた再生操作によっても、再生可能とすることができる。

図２５の状態からデータファイルＫＦＬ₂ をデータＵ−ＴＯＣの管理下に組み込んだ状態を図２６に示す。
この場合、図２６（ｂ）のようにＵ−ＴＯＣ上での管理形態は変わらない。
データＵ−ＴＯＣでは、図２６（ｃ）のように、それまでディフェクトエリアとしていた部位のうち、データファイルＫＦＬ₂ に相当する部位を、新たなデータファイルＦＬ₄ として管理する。
そして簡易Ｕ−ＴＯＣでは図２６（ｄ）のように基本的に管理状態は変わらないが、上記図２４の場合と同様に、データファイルＫＦＬ₂ については、これを消去禁止とする。

次に、図２７の例は、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣによってディフェクトエリアとして管理されている例である。
図２７（ａ）には、データトラックが記録されていない場合において、Ｕ−ＴＯＣで管理されているフリーエリアに簡易Ｕ−ＴＯＣと、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ が記録された場合を示している。

この場合、Ｕ−ＴＯＣは、図２７（ｂ）のように、簡易Ｕ−ＴＯＣとデータファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域をディフェクトエリアとして管理している。
そして、データトラックが存在しないので、当然データＵ−ＴＯＣも存在せず、従ってデータＵ−ＴＯＣによる管理は行なわれていない（図２７（ｃ））。

簡易Ｕ−ＴＯＣでは、図２７（ｄ）のようにデータファイルＫＦＬ₁ ，ＫＦＬ₂ が有効なデータファイルとして管理される。
従って、この場合もデータファイルＫＦＬ₁ ，ＫＦＬ₂ については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。

また、このように簡易Ｕ−ＴＯＣに管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ をデータＵ−ＴＯＣの管理下に組み込んで、データＵ−ＴＯＣを用いた再生操作によっても、再生可能とすることができる。

図２７の状態からデータファイルＫＦＬ₂ をデータＵ−ＴＯＣの管理下に組み込んだ状態を図２８に示す。
この場合、データトラックが存在しないため、まずデータトラックが生成される。つまり、図２８（ｃ）のように簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ の領域の先頭位置にデータＵ−ＴＯＣを記録し、この領域を図２８（ｂ）のようにＵ−ＴＯＣ上でデータトラックとして管理する。

さらに、新たに記録されたデータＵ−ＴＯＣでは、データファイルＫＦＬ₂ を新たなデータファイルＦＬ₁ として管理し、一方、簡易Ｕ−ＴＯＣ及びデータファイルＫＦＬ₁ の領域をディフェクトエリアとする。つまり、ディフェクトアロケーションブロックとして管理する。
簡易Ｕ−ＴＯＣ上では、図２８（ｄ）のように、データファイルＫＦＬ₂ について、そのディレクトリユニット上で、これを消去禁止とする。
これによってデータファイルＫＦＬ₂ のみが、データＵ−ＴＯＣ上でデータファイルＦＬ₁ として管理された状態が実現される。

なお、この場合に、データトラックＫＦＬ₂ と新たに記録するデータＵ−ＴＯＣの領域のみをＵ−ＴＯＣ上でデータトラックとし、簡易Ｕ−ＴＯＣ及びデータファイルＫＦＬ₁ の領域を、Ｕ−ＴＯＣ上でディフェクトエリアとするようにしてもよい。

以上のように簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域についての管理形態は各種考えられる。

IV−３ 簡易Ｕ−ＴＯＣを用いるデータファイル記録処理

次に、図２のような記録再生装置、もしくは同様の記録手段としてのブロック構成を備えた記録装置において実現できる簡易Ｕ−ＴＯＣを用いるデータファイル記録処理を説明する。この記録処理は図２とほぼ同様の記録ブロック構成を備えているが、メモリ容量などの各種スペックが小規模化された例えば携帯用小型機器においても容易に実現できる。

図２の記録再生装置の動作としてこの記録動作を説明する。
図２９は記録時のシステムコントローラ２１の処理を示している。
記録すべきデータが入力されて記録操作がなされたら、実際の記録処理が開始される (F201→F202→F203) 。
なお、データ入力は図２のブロックではコネクタ部１５及び通信回路３４を介して行なわれたり、画像スキャナ１４によって行なわれるが、例えば携帯用スチルカメラなどの場合は撮影手段からのデータ入力となり、また電子手帳のような機器ではキー操作による文字データ入力として行なわれる。

まず、その入力データを記録できるフリーエリアをＵ−ＴＯＣから検索する(F203)。そして、フリーエリアに入力データを記録していく(F204)。
ここで、その記録したデータファイルに対応するディレクトリユニットが簡易Ｕ−ＴＯＣとして記録されなければならないので、このためのデータを生成する(F205)。即ち、記録を行なったディスクに既に簡易Ｕ−ＴＯＣが存在していた場合は、これを読み込み、今回記録を行なったデータファイルに対応するディレクトリユニットを生成する。また、簡易Ｕ−ＴＯＣが存在していなければ、今回記録を行なったデータファイルに対応するディレクトリユニットを記録した簡易Ｕ−ＴＯＣデータを生成する。
なお、ディスク上での簡易Ｕ−ＴＯＣの存在／非存在の判別、及び存在する場合の読込処理については、後述する再生時の処理における読込処理と同様となるため、ここでは詳しい説明を省略する。

そして、データファイル記録に応じた簡易Ｕ−ＴＯＣデータの編集／生成が行なわれたら、その簡易Ｕ−ＴＯＣデータをフリーエリアに記録する(F206)。
そして、記録した簡易Ｕ−ＴＯＣ及びデータファイルの領域を、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣ上で、もしくはその一方で、ディフェクトエリアに編入されるようにＵ−ＴＯＣ／データＵ−ＴＯＣの書き換えを行なう(F207)。つまり、上述した図２３，図２５，図２７のいづれかの管理形態が実現されるようにＵ−ＴＯＣ，データＵ−ＴＯＣの一方または両方を書き換える。
これにより、簡易Ｕ−ＴＯＣに対応するデータファイルの記録動作は終了する。

IV−４ 簡易Ｕ−ＴＯＣによるデータファイルの再生処理及びデータＵ−ＴＯ Ｃへの編入処理

次に、例えば図２３，図２５，図２７のように簡易Ｕ−ＴＯＣに管理されて記録されているデータファイルの再生処理、及び図２４，図２６，図２８のように簡易Ｕ−ＴＯＣのみに管理されているデータファイルをデータＵ−ＴＯＣの管理下に組み込む処理について説明する。

図３０は簡易Ｕ−ＴＯＣ対応のデータ再生／編入についてのシステムコントローラ２１の処理を示す。なお、このうちの再生処理のみについては、各種スペックが小規模化された携帯用小型機器においても容易に実現できる処理である。

簡易Ｕ−ＴＯＣ対応のデータファイル再生のためには簡易Ｕ−ＴＯＣを読み込まなければならない。
まずシステムコントローラ２１は、ディスク１に対してリードインエリアに光学ヘッド２３をアクセスさせてＰ−ＴＯＣを読み込む(F301)。ここで、Ｐ−ＴＯＣが読み込めなかった場合はステップF302からF303に進み、ディスクエラーとする。

Ｐ−ＴＯＣが読み込めた場合は、続いてＰ−ＴＯＣにおけるＵ−ＴＯＣスタートアドレス（ＵＳＴ_A ）に基づいてアクセスを行ない、記録再生管理エリアにおけるＵ−ＴＯＣを読み込む(F304)。
Ｕ−ＴＯＣが読み込めなかった場合は、そのディスクはバージンディスクであると判断する (F305→F306) 。

Ｕ−ＴＯＣが読み込めたら、システムコントローラ２１は、このＵ−ＴＯＣの管理上でディフェクトエリアが存在するか否かを判別する(F307)。簡易Ｕ−ＴＯＣ及びそれに管理されるデータファイルが記録されている領域が、図２３又は図２７の状態で管理されている場合は、その領域はＵ−ＴＯＣ上でディフェクトエリアとされている。即ちＵ−ＴＯＣの管理上でディフェクトエリアが存在することになる。

そこで、以降の処理として、Ｕ−ＴＯＣでテーブルポインタP-DFA から導かれるパーツテーブルに示されるパーツを順にアクセスしていくことになる(F308)。
まず、１つ目のパーツにアクセスし、そのパーツから情報を読み取ってみてディスクエラーが発生するか否かを判断する(F309)。そのパーツが本当の欠陥パーツであったらディスクエラーが発生するはずである。
ディスクエラーが発生した場合は、次に、そのパーツを示すパーツテーブルからリンクされるパーツテーブルに示されているパーツをアクセスする (F309→F312→F308) 。

また、ディフェクトエリアとされるパーツにアクセスして再生してみて、ディスクエラーが発生しなかった場合は、そこに簡易Ｕ−ＴＯＣが存在しているか否かを判断する(F310)。即ち、簡易Ｕ−ＴＯＣであることを示すシステムＩＤである『ＭＩＥＸ』というコードデータが読み込めたか否かを判断する。

ステップF310で『ＭＩＥＸ』が読み込めなかったと判断された場合は、そのパーツは欠陥パーツではなく、また簡易Ｕ−ＴＯＣも記録されていないパーツである。例えば簡易Ｕ−ＴＯＣに管理されるデータファイルが記録されているパーツであったか、もしくは欠陥パーツであったが何らかの事情でディスクエラーが発生しなかったような場合が考えられる。
この場合は、次に、そのパーツを示すパーツテーブルからリンクされるパーツテーブルに示されているパーツをアクセスする (F310→F312→F308) 。

このようにディフェクトパーツをたどっていくと、或る時点で簡易Ｕ−ＴＯＣであることを示す『ＭＩＥＸ』というコードデータが読み込めるパーツがみつかる。例えば、Ｕ−ＴＯＣ上で図３１のようにディフェクトパーツが管理されているとする。即ち、テーブルポインタP-DFA から導かれるパーツテーブルに示されるパーツとして、最初の２つが欠陥パーツで、次に簡易Ｕ−ＴＯＣを有するパーツ、その次に簡易Ｕ−ＴＯＣで管理されるデータファイルＫＦＬ₁ を有するパーツが、リンクされて管理されていたとすると、３番目のパーツのアクセス時点で簡易Ｕ−ＴＯＣが発見されることになる。
このような場合に、処理はステップF310からF311に進むことになり、発見した簡易Ｕ−ＴＯＣを読み込むことになる。

なおディフェクトエリアとされるパーツをアクセスし、再生していって最後のパーツの読取が終了しても簡易Ｕ−ＴＯＣがみつからなかった場合は、そのディスクには簡易Ｕ−ＴＯＣが存在しないと判断され、当然簡易Ｕ−ＴＯＣに管理されるデータファイルの再生動作は行なわれない (F312→F317) 。例えば図４のような状態のディスクに、欠陥によるディフェクトエリアが存在する場合である。

また、ステップF307でＵ−ＴＯＣ上でディフェクトエリアが存在しないとされた場合は、次にＵ−ＴＯＣで管理されているトラックとして、データトラックが存在するか否かを確認する。つまり、パーツテーブルのトラックモード情報として、ビットｄ４ ＝『１』であるパーツが存在するか否かを確認する(F313)。

例えば図２５のような管理状態であった場合は、簡易Ｕ−ＴＯＣ及びそれに管理されるデータファイルが記録されている領域は、Ｕ−ＴＯＣ上でディフェクトエリアとされず、データＵ−ＴＯＣ上でディフェクトエリアとされている。

ステップF313データトラックが存在しないと判断されれば、データＵ−ＴＯＣも記録されてにないことになり、従ってデータＵ−ＴＯＣ上でディフェクトエリアとされる簡易Ｕ−ＴＯＣ及びそれに管理されるデータファイルも存在しないことになるため、簡易Ｕ−ＴＯＣなしとして簡易Ｕ−ＴＯＣによるデータファイル再生処理は終了する (F313→F317) 。

データトラックが存在する場合は、ステップF314に進み、まずＵ−ＴＯＣからデータトラックを構成するパーツのうち一番小さいアドレスを含むパーツを探してアクセスさせる。つまり、データトラックの内の一番ディスク内周側となる部位に光学ヘッド２３をアクセスさせ、データＵ−ＴＯＣを読み込む(F315)。つまり、システムＩＤが『ＭＤ００１』とされているボリュームディスクリプタから始まるボリュームマネジメントエリアにおいて使用されているマネジメントブロックを読み込む。

データＵ−ＴＯＣが読み込めたら、データＵ−ＴＯＣ上でディフェクトエリアが存在するか否かを判別する。つまり、ボリュームスペースビットマップ上においてディフェクトアロケーションブロックが存在するか否かを確認する。
ここでディフェクトアロケーションブロックが存在しなければ、すなわち簡易Ｕ−ＴＯＣなしとして簡易Ｕ−ＴＯＣによるデータファイル再生処理は終了する (F316→F317) 。

ディフェクトアロケーションブロックが存在したら、ステップF308に進み、そのディフェクトパーツ（ディフェクトアロケーションブロック）を順次アクセスして上記と同様に簡易Ｕ−ＴＯＣを探していくことになる(F308,F309,F310,F312) 。そして『ＭＩＥＸ』というコードデータが読み込めるアロケーションブロックがみつかったら、ステップF311で簡易Ｕ−ＴＯＣを読み込むことになる。
ディフェクトアロケーションブロックをすべて再生しても『ＭＩＥＸ』が見つからなかった場合は、簡易Ｕ−ＴＯＣ無しと判断する (F312→F317) 。

以上の処理で、簡易Ｕ−ＴＯＣを読み込めたら、簡易Ｕ−ＴＯＣに管理されるデータファイルの再生が可能となる。そして、データファイル再生のための各種操作、即ち再生すべきデータファイルの指定操作に応じて(F318)、そのディレクトリユニットによって示される位置にアクセスさせ、そのデータファイルを読み込み、バッファＲＡＭ３３に取り込む(F319)。

そして、操作などに応じて所定の出力態様で出力する(F320)。例えば表示コントローラ３５を介して表示部１３に出力したり、通信回路３４を介してコネクタ部１５から他の機器に出力する。
簡易Ｕ−ＴＯＣに管理される他のデータファイルの再生操作がなされた場合は、再びステップF324からF318に戻って、処理が繰り返される。

ところで、例えば或るデータファイルを再生出力した段階でユーザーがそのデータファイルをデータＵ−ＴＯＣの管理下に編入させる操作を行なうことなどで、編入処理が行なわれる。即ち、編入操作がなされたら(F321)、データＵ−ＴＯＣの書き換え処理を行ない、図２４（ｃ）、図２６（ｃ）、図２８（ｃ）に示したように該当するデータファイルをデータＵ−ＴＯＣにより管理されるデータファイルとする。また、それまで図２３又は図２７のような管理状態であった場合は、Ｕ−ＴＯＣで図２４（ｂ）、図２８（ｂ）に示すような管理が行われるようにＵ−ＴＯＣが更新される(F322)。
そして、簡易Ｕ−ＴＯＣの書き換えも行なう。即ち、そのデータファイルに対応するディレクトリユニットにおいて、消去防止フラグ(Flag)を『０１ｈ』とする(F323)。

以上のように、簡易Ｕ−ＴＯＣに対応するデータファイル再生の場合はＰ−ＴＯＣからＵ−ＴＯＣをたどり、Ｕ−ＴＯＣのディフェクトエリアを検索して簡易Ｕ−ＴＯＣを読み込む。もしくはＵ−ＴＯＣからデータＵ−ＴＯＣをたどって、データＵ−ＴＯＣ上でのディフェクトエリアを検索して簡易Ｕ−ＴＯＣを読み込む。そして簡易Ｕ−ＴＯＣにおけるディレクトリユニットに従って再生処理を行なうことになる。

以上のような簡易Ｕ−ＴＯＣによる記録／再生が行なわれる場合、データＵ−ＴＯＣの読込／編集の必要はないため、データファイルの記録／再生／編集動作時に大きなメモリ容量を必要とせず、また消費電力も小さくできる。従って、小型機器などでは非常に好適な記録再生方式となる。

また、簡易Ｕ−ＴＯＣに管理されるデータファイルをデータＵ−ＴＯＣの管理下に編入することができ、これによってデータＵ−ＴＯＣを用いた通常のデータファイル再生によって、簡易Ｕ−ＴＯＣに対応するデータファイルを再生することができるようになる。従って、簡易Ｕ−ＴＯＣによる再生機能を持たない機器においても再生可能となる。

また、簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣの管理下に編入することで、そのデータファイルはデータＵ−ＴＯＣにおける高度な編集動作の対象となり、各種有効利用できることになる。
例えば簡易Ｕ−ＴＯＣによる記録機能を有する携帯用スチルカメラで撮影し、ディスクにデータファイルとして記録しておいたものを、フルスペックの記録再生機器で再生してみて必要なデータファイルを選択してデータＵ−ＴＯＣの管理下に編入し、各種高度な編集を行なうといった使用形態も可能となる。

IV−５ 簡易Ｕ−ＴＯＣを用いたコピーガードデータ記録

ところで、以上説明してきたように簡易Ｕ−ＴＯＣは、Ｕ−ＴＯＣ及び／又はデータＵ−ＴＯＣによってディフェクトエリアとして管理されるため、これを用いて違法コピー防止のための隠されたプロテクション領域とし、コピーガードを行なうことができる。

本実施例のミニディスクデータシステムでは、Ｕ−ＴＯＣのおけるパーツテーブルのトラックモード情報としてコピープロテクトのフラグを立てることができ、またデータＵ−ＴＯＣでもファイルやディレクトリの属性データとしてコピープロテクトのフラグを立てることができる。
ところが、記録再生装置においてこれらのフラグを無視することができるような改造を行なうことは比較的容易に可能である。従って、絶対的なコピーガード手段とはいえない。

そこで、ここでは簡易Ｕ−ＴＯＣを用いてより確実なコピーガードを実現する方式について説明する。
なお、この実施例としては簡易Ｕ−ＴＯＣを利用するものであるが、簡易Ｕ−ＴＯＣではなく、コピーガード専用のセクターを設けて、これを簡易Ｕ−ＴＯＣと同様にディフェクトエリアとして管理することも可能である。

このコピーガード方式は、まず簡易Ｕ−ＴＯＣ内にコピーガードのためのキーワードを記録することになる。
この記録処理について図３２に示す。

まず、キーワードが設定される(F401)。これは例えばコピーガードのための記録プログラムにおいて設定されているキーワードデータを記録装置が発生させることになる。

そして、図２２に示した簡易Ｕ−ＴＯＣの１つのディレクトリユニットを用いてこのキーワードを記録する。
例えばディレクトリユニットにおけるデータファイルの名称の８バイト（Name0 〜Name7 ）と、拡張子の３バイト（Suffix0 〜Suffix2 ）を用いてキーワードを記録するようにする。
そして、カテゴリー情報(Category ）、ボリューム情報（Volume1-0 ，Volume1-1 ）を用いて、そのディレクトリユニットが長さ『０』のデータファイルに対応するディレクトリ、即ちキーワードを記録したディレクトリユニットであることを示すようにする。

このようなディレクトリユニットデータを生成したら(F402)、Ｕ−ＴＯＣからフリーエリアを検索し(F403)、フリーエリアに簡易Ｕ−ＴＯＣとして書き込む(F404)。
そして、上述した簡易Ｕ−ＴＯＣに対応するデータファイルの記録の場合と同様に、記録した簡易Ｕ−ＴＯＣがディフェクトエリアとされるようにＵ−ＴＯＣとデータＵ−ＴＯＣの一方又は両方を更新する(F405)。

このように簡易Ｕ−ＴＯＣ内にキーワードを記録しておき、さらに再生装置はこのキーワードに応じて処理を行なうようにすることでコピーガードが行なわれる。
通常ディスク上からデータをコピーする場合は、元ディスクの再生時にはＵ−ＴＯＣ及びデータＵ−ＴＯＣ上のディフェクトエリアについては無視されることになる。
従って、コピーされたディスクにおいては、キーワードは記録されない。

また、ディフェクトエリアについてもコピーできるようにすることは不可能ではないが、これに対してはキーワードを、元のディスクの固有の情報と演算を行なうものに設定すれば、キーワードまでがコピーされた場合も、コピーガードを行なうことができる。

例えば、キーワードを記録する位置のクラスタアドレスとキーワードの値を演算することによって、正確なキーワード値が得られるようなコピーガードシステムを設定しておく。
すると、仮にキーワードまでもがコピーされてしまったとしても、コピー先のディスクにおいて全く同値となるクラスタアドレスにそのキーワードが記録されることは殆どありえないため、そのディスクから正確なキーワードは得られないことになる。

IV−６ コピーガードに対応する再生処理

このように正規ディスクではキーワードを簡易Ｕ−ＴＯＣ内に記録するようにした場合において、コピーガードを実現するための再生処理を説明する。
図３３は再生時に行なわれる処理を示している。なお、これはディスクが装填され、Ｐ−ＴＯＣ、Ｕ−ＴＯＣが読み込まれた後の処理として示している。

システムコントローラ２１は、装填されたディスク１に対して再生操作などの操作がなされたら、Ｕ−ＴＯＣの管理上でディフェクトエリアが存在するか否かを判別する(F501)。適正なディスクであって、キーワードが簡易Ｕ−ＴＯＣに記録されているはずであるとすると、簡易Ｕ−ＴＯＣはＵ−ＴＯＣ、データＵ−ＴＯＣのいづれかにおいてディフェクトエリアとされる領域に存在する。

Ｕ−ＴＯＣの管理上でディフェクトエリアが存在したら、Ｕ−ＴＯＣでテーブルポインタP-DFA から導かれるパーツテーブルに示されるパーツを順にアクセスしていき、簡易Ｕ−ＴＯＣを探していくことになる(F503,F504,F505,F507) 。つまり、上述した図３０のステップF308,F309,F310,F312 と同様の処理が行なわれる。そして、『ＭＩＥＸ』というコードデータが読み込めたら、簡易Ｕ−ＴＯＣが見つかったことになり、その簡易Ｕ−ＴＯＣを読み込む(F506)。

また、Ｕ−ＴＯＣ上でディフェクトエリアが存在しないとされた場合は、ステップF502からF508に進み、Ｕ−ＴＯＣで管理されているトラックとして、データトラックが存在するデ否かを確認する。
そして、データトラックが存在すれば、その物理的先頭位置にあるデータＵ−ＴＯＣをアクセスして取り込み(F509,F510) 、データＵ−ＴＯＣ上でのディフェクトエリアの存在を確認する(F511)。そしてディフェクトエリアが存在すれば、ディフェクトエリア、即ちディフェクトアロケーションブロックをたどって簡易Ｕ−ＴＯＣを探すことになる(F503,F504,F505,F507) 。
そして、『ＭＩＥＸ』というコードデータが読み込めたら、簡易Ｕ−ＴＯＣが見つかったことになり、その簡易Ｕ−ＴＯＣを読み込む(F506)。

簡易Ｕ−ＴＯＣを読み込んだら、その中でキーワードが記録されているディレクトリユニットを探し、正しいキーワードが存在するか否かを確認する(F512)。 即ち、カテゴリー情報(Category ）、ボリューム情報（Volume1-0 ，Volume1-1 ）からキーワードを記録したディレクトリユニットを確認し、データファイル（Name0 〜Name7 ）と、拡張子（Suffix0 〜Suffix2 ）のバイトにかかれているキーワードを確認する。
そして、正しいキーワードであれば、正規ディスクと判別し(F513)、再生操作に応じたプログラムを実行する(F514)。

一方、これ以外の場合は、そのディスクは違法コピーされたディスクであると判別することになる。
つまり、Ｕ−ＴＯＣ、データＵ−ＴＯＣのいづれにもディフェクトエリアが存在しなかった場合、Ｕ−ＴＯＣ、データＵ−ＴＯＣのどちらかにディフェクトエリアが存在したが、その中に簡易Ｕ−ＴＯＣが含まれていなかった場合は、記録されているべき簡易Ｕ−ＴＯＣが存在しないことから、違法コピーディスクと判別する (F508→F515) ,(F507→F515) ,(F511→F515) 。

また、簡易Ｕ−ＴＯＣは存在したが、キーワードが記録されていなかった場合、キーワードが正しくなかった場合、もしくは上述したように例えばクラスタアドレスとキーワードの演算によって特定の値を得るシステムであって場合は、その演算結果が正しい値でなかった場合は、違法コピーディスクと判別する (F512→F515) 。

このように違法コピーディスクと判別された場合は、システムコントローラ２１は再生操作等については一切無視し、全く動作を行なわないようにする(F516)。これによって違法コピーディスクは記録再生装置にとって再生対象外の無効ディスクとなり、確実なコピーガードが実現されることになる。

Ｖ ．簡易Ｕ−ＴＯＣを用いた記録再生方式（タイプＢ）

次に、簡易Ｕ−ＴＯＣを用いた記録再生方式として、簡易Ｕ−ＴＯＣが記録再生管理エリア内に記録されるタイプＢについて述べる。
なお、簡易Ｕ−ＴＯＣのセクター構造についてはタイプＡで説明した図２２と同様なため、説明を省略する。

Ｖ−１ 簡易Ｕ−ＴＯＣが記録された場合の管理形態

簡易Ｕ−ＴＯＣが記録再生管理エリア内に記録されるタイプＢにおける、簡易Ｕ−ＴＯＣが記録された場合の管理形態例を、各場合にわけて図３４，図３６，図３８に示す。
図３４，図３６，図３８は、簡易Ｕ−ＴＯＣによって管理を行なうデータファイルを記録した場合のトラック状態及びその管理形態を示すものである。つまり、簡易Ｕ−ＴＯＣによるデータファイル記録機能を備えた記録装置によってディスクにデータファイルが記録された状態である。この記録方式については後述する。

なお、ここで説明する各例は、タイプＡで説明した際と同様に、実行することができる３種類の管理形態を示すものであり、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ の記録される位置についてはフリーエリアのどこかを用いればよいものであって、記録位置が管理形態の種別の特定に影響を与えるものではない。記録位置の設定については後述する。

まず図３４の例は、簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣの両方によってディフェクトエリアとして管理される例である。

図３４（ａ）に示すように、オーディオトラックＭ₁ ，Ｍ₂ ，Ｍ₃ 、データトラック、即ちデータＵ−ＴＯＣ、データファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢ、に対して、物理的に離れた位置に、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている。
簡易Ｕ−ＴＯＣについては、記録再生管理エリア内において、Ｕ−ＴＯＣ位置から所定のオフセットをもった位置に記録されている。

この場合、Ｕ−ＴＯＣによっては、図３４（ｂ）のようにオーディオトラックＭ₁ ，Ｍ₂ ，Ｍ₃ が管理され、またデータＵ−ＴＯＣ、データファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢについては、一括してデータトラックとして管理されている。また、フリーエリアもＵ−ＴＯＣで管理される。
そして、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域は、Ｕ−ＴＯＣ上では、テーブルポインタP-DFA から示されるディフェクトエリアとして管理されている。即ち、Ｕ−ＴＯＣ上では簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ の領域は記録／再生動作にとって無効な領域とみなされる。

また、データＵ−ＴＯＣによっては、図３４（ｃ）のようにデータファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢの管理が行なわれている。
そして、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域は、データＵ−ＴＯＣ上でもディフェクトエリアとして管理されている。つまり、この領域はデータＵ−ＴＯＣで管理されるデータトラックとしての領域ではないが、ボリュームスペースビットマップ上においてこの領域に含まれるアロケーションブロックはディフェクトアロケーションブロックとして示されている状態である。
従って、データＵ−ＴＯＣ上でも、データファイルＫＦＬ₁ ，ＫＦＬ₂ の領域は記録／再生動作にとって無効な領域とみなされる。

そして、簡易Ｕ−ＴＯＣにとっては、図３４（ｄ）のようにデータファイルＫＦＬ₁ ，ＫＦＬ₂ が有効なデータファイルとして管理される。
従って、データファイルＫＦＬ₁ ，ＫＦＬ₂ については、後述するように簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。

また、タイプＡの場合と同様に、簡易Ｕ−ＴＯＣに管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ は、それをデータＵ−ＴＯＣの管理下に組み込んで、データＵ−ＴＯＣを用いた再生操作によっても、再生可能とすることができる。

図３４の状態からデータファイルＫＦＬ₂ をデータＵ−ＴＯＣの管理下に組み込んだ状態を図３５に示す。
この場合、図３５（ｂ）のようにＵ−ＴＯＣ上での管理として、データファイルＫＦＬ₂ のエリアをデータトラックの１つのパーツとして組み入れるように、Ｕ−ＴＯＣを更新する。
またデータＵ−ＴＯＣでは、図３５（ｃ）のように、それまでディフェクトエリアとしていた部位のうち、データファイルＫＦＬ₂ に相当する部位を、新たなデータファイルＦＬ₄ として管理することになる。

簡易Ｕ−ＴＯＣでは図３５（ｄ）のように基本的に管理状態は変わらないが、データファイルＫＦＬ₂ については、データファイルＫＦＬ₂ に対応するディレクトリユニットの消去防止フラグ(Flag)を『０１ｈ』として、削除禁止とする。これによってデータＵ−ＴＯＣにおけるデータファイルＦＬ₄ が、簡易Ｕ−ＴＯＣ上のデータファイルＫＦＬ₂ に対する編集動作などによって消去されてしまうことが防止される。
データファイルＫＦＬ₂ （＝ＦＬ₄ ）を消去したいときは、データＵ−ＴＯＣによる動作において消去することになる。

なお、図３４の例としては、簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣの両方によってディフェクトエリアとして管理されているが、これをＵ−ＴＯＣのみがディフェクトエリアとして管理し、データＵ−ＴＯＣではデータトラック外であるとして管理をしないようにしてもよい。

次に、図３６の例は、簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、データＵ−ＴＯＣによってディフェクトエリアとされ、Ｕ−ＴＯＣではディフェクトエリアとされていない状態で管理されている例である。

図３６（ａ）に示すように、データトラック、即ちデータＵ−ＴＯＣ、データファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢ、に対して、連続した位置に、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている。
簡易Ｕ−ＴＯＣは、記録再生管理エリア内において、Ｕ−ＴＯＣ位置から所定のオフセットをもった位置に記録されている。

もちろん、このような位置に記録された場合でも、上記図３４と同様の管理形態とすることもできるが、この例では、Ｕ−ＴＯＣによっては、図３６（ｂ）のようにデータファイルＫＦＬ₁ とＫＦＬ₂ が、データトラックの一部と見なされて管理されている。従って、図３４のような、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域をディフェクトエリアとする管理は行なわれていない。

一方、データＵ−ＴＯＣによっては、図３６（ｃ）のようにデータファイルＦＬ₁ ，ＦＬ₂ ，ＦＬ₃ 、未記録ブロックＥＢの管理が行なわれて。そして、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域は、データトラック内におけるディフェクトエリアとして管理されている。つまり、この領域に含まれるアロケーションブロックはボリュームスペースビットマップ上においてディフェクトアロケーションブロックとして示されている。
従って、データＵ−ＴＯＣ上では、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ₁ ，ＫＦＬ₂ の領域はデータトラック内において記録／再生動作無効な領域とみなされる。

そして、簡易Ｕ−ＴＯＣにとっては、図３６（ｄ）のようにデータファイルＫＦＬ₁ ，ＫＦＬ₂ が有効なデータファイルとして管理される。
従って、この場合もデータファイルＫＦＬ₁ ，ＫＦＬ₂ については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。

図３６において簡易Ｕ−ＴＯＣのみに管理されているデータファイルＫＦＬ₂ を、データＵ−ＴＯＣの管理下に組み込んだ状態を図３７に示す。
この場合、図３７（ｂ）のようにＵ−ＴＯＣ上での管理形態は変わらない。
データＵ−ＴＯＣでは、図３７（ｃ）のように、それまでディフェクトエリアとしていた部位のうち、データファイルＫＦＬ₂ に相当する部位を、新たなデータファイルＦＬ₄ として管理する。
そして簡易Ｕ−ＴＯＣでは図３７（ｄ）のように基本的に管理状態は変わらないが、上記図３５の場合と同様に、データファイルＫＦＬ₂ については、これを消去禁止とする。

次に、図３８の例は、簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣによってディフェクトエリアとして管理されている例である。

図３８（ａ）には、データトラックが記録されていない場合において、Ｕ−ＴＯＣで管理されているフリーエリアに、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ₁ ，ＫＦＬ₂ が記録された場合を示している。
簡易Ｕ−ＴＯＣは、記録再生管理エリア内において、Ｕ−ＴＯＣ位置から所定のオフセットをもった位置に記録されている。

この場合、Ｕ−ＴＯＣは、図３８（ｂ）のように、データファイルＫＦＬ₁ ，ＫＦＬ₂ が記録されている領域をディフェクトエリアとして管理している。
そして、データトラックが存在しないので、当然データＵ−ＴＯＣも存在せず、従ってデータＵ−ＴＯＣによる管理は行なわれていない（図３８（ｃ））。

簡易Ｕ−ＴＯＣでは、図３８（ｄ）のようにデータファイルＫＦＬ₁ ，ＫＦＬ₂ が有効なデータファイルとして管理される。
従って、この場合もデータファイルＫＦＬ₁ ，ＫＦＬ₂ については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。

また、図３８の状態からデータファイルＫＦＬ₂ をデータＵ−ＴＯＣの管理下に組み込んだ状態を図３９に示す。
この場合、データトラックが存在しないため、まずデータトラックが生成される。
つまり、図３９（ｃ）のようにデータファイルＫＦＬ₁ ，ＫＦＬ₂ の領域の先頭位置にデータＵ−ＴＯＣを記録し、この領域を図３９（ｂ）のようにＵ−ＴＯＣ上でデータトラックとして管理する。

さらに、新たに記録されたデータＵ−ＴＯＣでは、データファイルＫＦＬ₂ を新たなデータファイルＦＬ₁ として管理し、一方、データファイルＫＦＬ₁ の領域をディフェクトエリアとする。つまり、ディフェクトアロケーションブロックとして管理する。
簡易Ｕ−ＴＯＣ上では、図３９（ｄ）のように、データファイルＫＦＬ₂ について、そのディレクトリユニット上で、これを消去禁止とする。
これによってデータファイルＫＦＬ₂ のみが、データＵ−ＴＯＣ上でデータファイルＦＬ₁ として管理された状態が実現される。

なお、この場合に、データトラックＫＦＬ₂ と新たに記録するデータＵ−ＴＯＣの領域のみをＵ−ＴＯＣ上でデータトラックとし、データファイルＫＦＬ₁ の領域を、Ｕ−ＴＯＣ上でディフェクトエリアとするようにしてもよい。

以上のように簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域についての管理形態は各種考えられる。

Ｖ−２ 簡易Ｕ−ＴＯＣを用いるデータファイル記録処理

次に、図２のような記録再生装置、もしくは同様の記録手段としてのブロック構成を備えた記録装置において実現できる簡易Ｕ−ＴＯＣを用いるデータファイル記録処理を説明する。タイプＡの場合と同様に、この記録処理は図２とほぼ同様の記録ブロック構成を備えているが、メモリ容量などの各種スペックが小規模化された例えば携帯用小型機器においても容易に実現できる。

図２の記録再生装置の動作としてこの記録動作を説明する。
図４０は記録時のシステムコントローラ２１の処理を示している。
コネクタ部１５及び通信回路３４を介したり、もしくは画像スキャナ１４によって、記録すべきデータが入力されて記録操作がなされたら、実際の記録処理が開始される (F601→F602→F603) 。

まず、その入力データを記録できるフリーエリアをＵ−ＴＯＣから検索する(F603)。そして、フリーエリアに入力データを記録していく(F604)。
ここで、その記録したデータファイルに対応するディレクトリユニットが簡易Ｕ−ＴＯＣとして記録されなければならないので、このためのデータを生成する(F605)。即ち、記録を行なったディスクに既に簡易Ｕ−ＴＯＣが存在していた場合は、これを読み込み、今回記録を行なったデータファイルに対応するディレクトリユニットを生成する。また、簡易Ｕ−ＴＯＣが存在していなければ、今回記録を行なったデータファイルに対応するディレクトリユニットを記録した簡易Ｕ−ＴＯＣデータを生成する。
なお、ディスク上での簡易Ｕ−ＴＯＣの存在／非存在の判別、及び存在する場合の読込処理については、後述する再生時の処理における読込処理と同様となるため、ここでは詳しい説明を省略する。

そして、データファイル記録に応じた簡易Ｕ−ＴＯＣデータの編集／生成が行なわれたら、その簡易Ｕ−ＴＯＣデータを記録再生管理エリアに記録する(F606)。記録再生管理エリア内における記録位置としては、Ｕ−ＴＯＣから所定のオフセットをもった位置とする。例えばＵ−ＴＯＣスタートアドレスＵＳＴ_A に対して特定のオフセット値を加算した値としてクラスタアドレスを得、これを簡易Ｕ−ＴＯＣのスタートアドレスとする。

そして次に、記録したデータファイルの領域を、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣ上で、もしくはその一方で、ディフェクトエリアに編入されるようにＵ−ＴＯＣ／データＵ−ＴＯＣの書き換えを行なう(F607)。つまり、上述した図３４，図３６，図３８のいづれかの管理形態が実現されるようにＵ−ＴＯＣ，データＵ−ＴＯＣの一方または両方を書き換える。
これにより、簡易Ｕ−ＴＯＣに対応するデータファイルの記録動作は終了する。

Ｖ−３ 簡易Ｕ−ＴＯＣによるデータファイルの再生処理及びデータＵ−ＴＯＣへの編入処理

次に、例えば図３４，図３６，図３８のように簡易Ｕ−ＴＯＣに管理されて記録されているデータファイルの再生処理、及び図３５，図３７，図３９のように簡易Ｕ−ＴＯＣのみに管理されているデータファイルをデータＵ−ＴＯＣの管理下に組み込む処理について説明する。

図４１は簡易Ｕ−ＴＯＣ対応のデータ再生／編入についてのシステムコントローラ２１の処理を示す。なお、このうちの再生処理のみについては、各種スペックが小規模化された携帯用小型機器においても容易に実現できる処理である。

簡易Ｕ−ＴＯＣ対応のデータファイル再生のためには簡易Ｕ−ＴＯＣを読み込まなければならない。
まずシステムコントローラ２１は、ディスク１に対してリードインエリアに光学ヘッド２３をアクセスさせてＰ−ＴＯＣを読み込む(F701)。ここで、Ｐ−ＴＯＣが読み込めなかった場合はステップF702からF703に進み、ディスクエラーとする。

Ｐ−ＴＯＣが読み込めた場合は、続いてＰ−ＴＯＣにおけるＵ−ＴＯＣスタートアドレス（ＵＳＴ_A ）に基づいてアクセスを行ない、記録再生管理エリアにおけるＵ−ＴＯＣを読み込む(F704)。
Ｕ−ＴＯＣが読み込めなかった場合は、そのディスクはバージンディスクであると判断する (F705→F706) 。

Ｕ−ＴＯＣが読み込めたら、システムコントローラ２１は、次にＵ−ＴＯＣの位置から所定のオフセットをもった位置に光学ヘッド２３をアクセスさせ(F707)、その位置からデータ読込を行なう。これは、つまり簡易Ｕ−ＴＯＣのアクセス動作となる。
ここでデータが読み込めなければ簡易Ｕ−ＴＯＣは存在していないことになる。従って簡易Ｕ−ＴＯＣなしとして簡易Ｕ−ＴＯＣによるデータファイル再生処理は終了する (F708→F710) 。

Ｕ−ＴＯＣから所定のオフセットをもった位置からデータが読み出された場合は、それが簡易Ｕ−ＴＯＣであるか否かを判別する(F709)。即ち、簡易Ｕ−ＴＯＣであることを示すシステムＩＤである『ＭＩＥＸ』というコードデータが読み込めたか否かを判断する。

ステップF709で『ＭＩＥＸ』が読み込めなかったと判断された場合は、そのディスクには簡易Ｕ−ＴＯＣは存在していないと判断され、簡易Ｕ−ＴＯＣによるデータファイル再生処理は終了する (F709→F710) 。
Ｕ−ＴＯＣから所定のオフセットをもった位置から読み出したデータとして『ＭＩＥＸ』というコードデータが存在したら、処理はステップF709からF711に進むことになり、簡易Ｕ−ＴＯＣを読み込むことになる。

簡易Ｕ−ＴＯＣを読み込めたら、簡易Ｕ−ＴＯＣに管理されるデータファイルの再生が可能となる。そして、データファイル再生のための各種操作、即ち再生すべきデータファイルの指定操作に応じて(F712)、そのディレクトリユニットによって示される位置にアクセスさせ、そのデータファイルを読み込み、バッファＲＡＭ３３に取り込む(F713)。

そして、操作などに応じて所定の出力態様で出力する(F714)。例えば表示コントローラ３５を介して表示部１３に出力したり、通信回路３４を介してコネクタ部１５から他の機器に出力する。
簡易Ｕ−ＴＯＣに管理される他のデータファイルの再生操作がなされた場合は、再びステップF718からF712に戻って、処理が繰り返される。

ところで、例えば或るデータファイルを再生出力した段階でユーザーがそのデータファイルをデータＵ−ＴＯＣの管理下に編入させる操作を行なうことなどで、編入処理が行なわれる。即ち、編入操作がなされたら(F715)、データＵ−ＴＯＣの書き換え処理を行ない、図３５（ｃ）、図３７（ｃ）、図３９（ｃ）に示したように該当するデータファイルをデータＵ−ＴＯＣにより管理されるデータファイルとする。なお、それまで図３４、図３８のような管理状態であった場合は、Ｕ−ＴＯＣの管理が図３５（ｂ）、図３７（ｂ）のような状態となるように、Ｕ−ＴＯＣも更新する(F716)。
そして、簡易Ｕ−ＴＯＣの書き換えも行なう。即ち、そのデータファイルに対応するディレクトリユニットにおいて、消去防止フラグ(Flag)を『０１ｈ』とする(F717)。

以上のように、簡易Ｕ−ＴＯＣに対応するデータファイル再生の場合はＰ−ＴＯＣに示されるＵ−ＴＯＣスタートアドレスＵＳＴ_A に対して所定のオフセット値を加算して簡易Ｕ−ＴＯＣが記録されているはずのアドレスを得、その位置から簡易Ｕ−ＴＯＣを読み込む。そして簡易Ｕ−ＴＯＣにおけるディレクトリユニットに従って再生処理を行なうことになる。

以上のような簡易Ｕ−ＴＯＣによる記録／再生が行なわれる場合、上述したタイプＡの場合と同様に、データＵ−ＴＯＣの読込／編集の必要はないため、データファイルの記録／再生／編集動作時に大きなメモリ容量を必要とせず、また消費電力も小さくできる。従って、小型機器などでは非常に好適な記録再生方式となる。

また、簡易Ｕ−ＴＯＣに管理されるデータファイルをデータＵ−ＴＯＣの管理下に編入することができ、これによってデータＵ−ＴＯＣを用いた通常のデータファイル再生によって、簡易Ｕ−ＴＯＣに対応するデータファイルを再生することができるようになる。従って、簡易Ｕ−ＴＯＣによる再生機能を持たない機器においても再生可能となる。

また、簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣの管理下に編入することで、そのデータファイルはデータＵ−ＴＯＣにおける高度な編集動作の対象となり、各種有効利用できることになる。
例えば簡易Ｕ−ＴＯＣによる記録機能を有する携帯用スチルカメラで撮影し、ディスクにデータファイルとして記録しておいたものを、フルスペックの記録再生機器で再生してみて必要なデータファイルを選択してデータＵ−ＴＯＣの管理下に編入し、各種高度な編集を行なうといった使用形態も可能となる。

Ｖ−４ 簡易Ｕ−ＴＯＣを用いたコピーガードデータ記録

ところでこのタイプＢでも、簡易Ｕ−ＴＯＣは、Ｕ−ＴＯＣ及び／又はデータＵ−ＴＯＣによって管理されないため、これを用いて違法コピー防止のための隠されたプロテクション領域とし、コピーガードを行なうことができる。
なお、この実施例としては簡易Ｕ−ＴＯＣを利用するものであるが、簡易Ｕ−ＴＯＣではなく、コピーガード専用の領域を記録再生管理エリアに設けて、そこにキーワードを記録するようにしてもよい。

この場合も、まず簡易Ｕ−ＴＯＣ内にコピーガードのためのキーワードを記録することになる。
この記録処理について図４２に示す。
まず、コピーガードのための記録プログラムにおいて設定されているキーワードデータを記録装置が発生させる(F801)。

そして、図２２に示した簡易Ｕ−ＴＯＣの１つのディレクトリユニットを用いてこのキーワードを記録する。つまり、タイプＡで説明した場合と同様にディレクトリユニットにおけるデータファイルの名称の８バイト（Name0 〜Name7 ）と、拡張子の３バイト（Suffix0 〜Suffix2 ）を用いてキーワードを記録するようにする。
そして、またカテゴリー情報(Category ）、ボリューム情報（Volume1-0 ，Volume1-1 ）を用いて、そのディレクトリユニットが長さ『０』のデータファイルに対応するディレクトリ、即ちキーワードを記録したディレクトリユニットであることを示すようにする。

このようなディレクトリユニットデータを生成したら(F802)、Ｕ−ＴＯＣのスタートアドレスＵＳＴ_A に所定のオフセット値を加算し、記録再生管理エリア内における簡易Ｕ−ＴＯＣを記録すべきクラスタアドレスを得る。そして、そのクラスタアドレスに簡易Ｕ−ＴＯＣとして書き込む(F803)。

このように簡易Ｕ−ＴＯＣ内にキーワードを記録しておき、さらに再生装置はこのキーワードに応じて処理を行なうようにすることでコピーガードが行なわれる。
通常、或るディスクからデータを再生して他のディスクにコピーする場合は、再生側のディスクでは簡易Ｕ−ＴＯＣは無視されることになる。
また、上記のように簡易Ｕ−ＴＯＣを用いた再生を行なうことで、簡易Ｕ−ＴＯＣに対応するデータファイルを再生させてコピーすることも可能であるが、簡易Ｕ−ＴＯＣ自体は再生出力されないため、コピーされない。
従って、データをコピーしたディスクにはキーワードが記録されていないことになる。

Ｖ−５ コピーガードに対応する再生処理

このように正規ディスクでは、キーワードを簡易Ｕ−ＴＯＣ内に記録することとした場合において、コピーガードを実現するための再生処理を説明する。
図４３は再生時に行なわれる処理を示している。なお、これはディスクが装填され、Ｐ−ＴＯＣ、Ｕ−ＴＯＣが読み込まれた後の処理として示している。

システムコントローラ２１は、装填されたディスク１に対して再生操作などの操作がなされたら、Ｐ−ＴＯＣに記録されたＵ−ＴＯＣスタートアドレスＵＳＴ_A に所定のオフセットを加算したアドレス位置にアクセスさせ(F902)、その位置にデータが存在するか、及びそのデータは簡易Ｕ−ＴＯＣであるか否かを判別する(F903,F904) 。
そして、『ＭＩＥＸ』というコードデータが読み込め、簡易Ｕ−ＴＯＣが存在すると判断されたら、その簡易Ｕ−ＴＯＣを読み込む(F905)。

簡易Ｕ−ＴＯＣを読み込んだら、その中でキーワードが記録されているディレクトリユニットを探し、キーワードが存在するか否かを確認する(F906)。即ち、カテゴリー情報(Category ）、ボリューム情報（Volume1-0 ，Volume1-1 ）からキーワードを記録したディレクトリユニットを確認し、データファイル（Name0 〜Name7 ）と、拡張子（Suffix0 〜Suffix2 ）のバイトにかかれているキーワードを確認する。
そして、正しいキーワードであれば、正規ディスクと判別し(F907)、再生操作などに応じたプログラムを実行する(F908)。

一方、簡易Ｕ−ＴＯＣが存在しなかった場合、及び簡易Ｕ−ＴＯＣは存在したがキーワードが書かれていなかった場合やキーワードが正しくなかった場合は、そのディスクは違法コピーされたディスクであると判別することになる (F903→F909) ,(F904→F909) ,(F906→F909) 。

このように違法コピーディスクと判別された場合は、システムコントローラ２１は再生操作等については一切無視し、全く動作を行なわないようにする(F910)。これによって違法コピーディスクは記録再生装置にとって再生対象外の無効ディスクとなり、確実なコピーガードが実現されることになる。

VI ．簡易Ｕ−ＴＯＣで管理されるデータファイルの記録位置

上述のしてきたように、簡易Ｕ−ＴＯＣを用いた記録再生方式がタイプＡ又はタイプＢとして実現されるが、タイプＡの場合、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣに対応するデータファイルがフリーエリアに記録され、またタイプＢの場合、簡易Ｕ−ＴＯＣに対応するデータファイルがフリーエリアに記録されることになる。

いづれの場合も、フリーエリア内におけるどの位置にデータファイル（タイプＡの場合はデータファイル及び簡易Ｕ−ＴＯＣ）を記録してもよいわけであるが、本実施例では、これらを、可能な限りディスク外周側となる位置に記録するようにしている。
以下、この記録位置に関する説明を行なう。なお、説明ではタイプＢを例に上げ、簡易Ｕ−ＴＯＣに対応するデータファイルの記録位置を述べるが、タイプＡについても同様に適用される。つまり、タイプＡでの簡易Ｕ−ＴＯＣの記録位置についても同様となる。

図４４（ａ）は、簡易Ｕ−ＴＯＣに対応するデータファイルＫＦＬ₁ を、フリーエリアのうち比較的ディスク内周側に記録した場合を示している。
このとき、データトラックが、データファイルＫＦＬ₁ より外周側に位置しており、従ってデータＵ−ＴＯＣがデータファイルＫＦＬ₁ より後方のアドレスとなっていたとする。

ここで、上述したように、簡易Ｕ−ＴＯＣに対応するデータファイルＫＦＬ₁ をデータＵ−ＴＯＣの管理下に編入する操作が行なわれたとする。
この場合、編入動作としては、データファイルＫＦＬ₁ が記録されているエリアを、データＵ−ＴＯＣにおいて新たなデータファイルＦＬ₃ として管理するようにデータＵ−ＴＯＣを更新すればよい。また、Ｕ−ＴＯＣ上ではデータファイルＫＦＬ₁ のエリアをディフェクトエリアから外し、データトラックのパーツとして組み入れることになる。

ところが、この新たなデータファイルＦＬ₃ の位置はそれまでのデータＵ−ＴＯＣよりも内周側に位置している。
データＵ−ＴＯＣはデータトラックを構成するパーツのうち、一番内周側のパーツの先頭位置に記録されることが規定されているため、データファイルＫＦＬ₁ をデータファイルＦＬ₃ としてデータトラックを構成するパーツに組み入れたら、このデータファイルＦＬ₃ となるパーツの直前にデータＵ−ＴＯＣが記録されなければならないことになる。

このため、編入時の処理として、データＵ−ＴＯＣで編入のための更新を行なうのみでなく、その更新したデータＵ−ＴＯＣを図４４（ｂ）のようにデータファイルＦＬ₃ となるパーツの直前に記録し、次に図４４（ｃ）のように今迄のデータＵ−ＴＯＣのエリアをフリーエリアに編入する処理が必要になる。
つまり、データＵ−ＴＯＣ内容の更新、データＵ−ＴＯＣの新たな位置への記録、Ｕ−ＴＯＣでのデータトラック、ディフェクトエリア、フリーエリアの更新、という多数の処理が必要となる。

一方、図４５（ａ）は、簡易Ｕ−ＴＯＣに対応するデータファイルＫＦＬ₁ が、フリーエリアのうちのディスク外周側となる位置に記録した場合を示している。このとき、データトラックは、データファイルＫＦＬ₁ より内周側に位置しており、従ってデータＵ−ＴＯＣはデータファイルＫＦＬ₁ より前方のアドレスとなっていたとする。

ここで、簡易Ｕ−ＴＯＣに対応するデータファイルＫＦＬ₁ をデータＵ−ＴＯＣの管理下に編入する操作が行なわれたとする。
この場合、編入動作としては、図４５（ｂ）のように、データファイルＫＦＬ が記録されているエリアを、データＵ−ＴＯＣにおいて新たなデータファイルＦＬ として管理するようにデータＵ−ＴＯＣを更新すればよい。また、Ｕ−ＴＯＣ上ではデータファイルＫＦＬ₁ のエリアをディフェクトエリアから外し、データトラックのパーツとして組み入れることになる。

つまり、この場合はデータＵ−ＴＯＣの位置を変更する必要はなく、そのデータＵ−ＴＯＣの位置において更新が必要な部分のみ内容を書き換えればよい。
またＵ−ＴＯＣ上でフリーエリアを更新する必要もない。このため比較的簡単な処理で編入が完了する。

この図４４、図４５の例からわかるように、簡易Ｕ−ＴＯＣに対応するデータファイルについては、データＵ−ＴＯＣへの編入処理を考慮して、なるべくディスク外周側の位置に記録できるようにすると都合がよい。
さらに、これに加えて、データＵ−ＴＯＣへの編入後では、その編入されたデータファイルとデータＵ−ＴＯＣの位置が物理的に近いほうが好ましい。これは再生時のアクセス速度を高速化させることになる。特にＣＬＶ方式の場合、スピンドルモータの回転数はディスク上の位置によって異なるものとなるが、長い距離をアクセスする場合は、スピンドルモータの回転数の制定制御に時間を要することになるため、この点でもデータファイルとデータＵ−ＴＯＣの位置は近いほど好適である。

このため、本実施例では次の1，2，3のような条件で、簡易Ｕ−ＴＯＣに対応するデータファイルの記録位置を設定している。

1 データトラック（データＵ−ＴＯＣ）が存在しない場合
存在するフリーエリアのうち、最もディスク外周側に近い部位において必要な領域長を探して記録する。これによって、その後データトラックが形成された場合に、その先頭位置となるデータＵ−ＴＯＣが、簡易Ｕ−ＴＯＣに対応するデータファイルよりもディスク内周側となるようにする。また、最外周位置に記録しておくことで、その後にデータトラックを記録する場合の自由度を最大とすることできる。

2 データトラック（データＵ−ＴＯＣ）が存在する場合
存在するフリーエリアのうち、データトラックより外周側で、しかもデータトラックに近い位置において必要な領域長を探して記録する。これによって簡易Ｕ−ＴＯＣに対応するデータファイルが、データＵ−ＴＯＣよりもディスク外周側となるようにするとともに、できればデータトラックの後に連続した位置に記録されるようにして、編入後のアクセス速度に有利となるようにする。

3 上記条件を満たすフリーエリアが存在しない場合
この場合は、存在するフリーエリアのうちできるだけ外周側に近い位置に記録していくようにする。この場合は、図４４のように簡易Ｕ−ＴＯＣに対応するデータファイルがデータＵ−ＴＯＣより内周側になる場合があるが、これはやむを得ない。

簡易Ｕ−ＴＯＣを用いたデータファイルの記録に際して、以上のように記録位置が選定されることで、データＵ−ＴＯＣによる通常のデータファイルの記録／再生などに最も都合のよい状態とすることができる。

以上、本発明の実施例を説明してきたが、本発明はこの実施例に示したもの以外にも各種変形例が考えられることはいうまでもない。

本発明の実施例の記録再生装置及びディスクの外観の説明図である。 実施例の記録再生装置のブロック図である。 実施例のディスクのクラスタ構造の説明図である。 実施例のＵ−ＴＯＣ及びデータＵ−ＴＯＣが記録されたディスクの管理状態の説明図である。 実施例のディスクのＰ−ＴＯＣセクターの説明図である。 実施例のディスクのＵ−ＴＯＣセクターの説明図である。 実施例のディスクのＵ−ＴＯＣセクターのリンク形態の説明図である。 実施例のディスクのデータトラックの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるブートエリアの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるブートエリアの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるボリュームディスクリプタの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるボリュームスペースビットマップの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるボリュームスペースビットマップに記録されるデータの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるマネジメントテーブルの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるマネジメントテーブルに記録されるデータの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるディレクトリレコードブロックの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるディレクトリレコードブロックの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるエクステントレコードブロックの説明図である。 実施例のディスクのデータＵ−ＴＯＣにおけるエクステントレコードブロックの説明図である。 実施例のディスクのデータセクターの説明図である。 実施例のデータＵ−ＴＯＣ対応のデータ再生処理のフローチャートである。 実施例のディスクの簡易Ｕ−ＴＯＣセクターの説明図である。 実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣ対応の記録処理のフローチャートである。 実施例の簡易Ｕ−ＴＯＣ対応の再生／編入処理のフローチャートである。 実施例の簡易Ｕ−ＴＯＣ検索動作の説明図である。 実施例のコピーガードデータ記録処理のフローチャートである。 実施例のコピーガードのための再生処理のフローチャートである。 実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。 実施例の簡易Ｕ−ＴＯＣ対応の記録処理のフローチャートである。 実施例の簡易Ｕ−ＴＯＣ対応の再生／編入処理のフローチャートである。 実施例のコピーガードデータ記録処理のフローチャートである。 実施例のコピーガードのための再生処理のフローチャートである。 実施例の簡易Ｕ−ＴＯＣ対応のデータファイルの記録位置の説明図である。 実施例の簡易Ｕ−ＴＯＣ対応のデータファイルの記録位置の説明図である。

符号の説明

１ ディスク
１０ 記録再生装置
１１ ディスク挿入部
１２ キー入力部
１３ 表示部
１４ 画像スキャナ部
１５ 入出力コネクタ部
１６ 入出力端子
２１ システムコントローラ
２３ 光学ヘッド
２８ デコーダ
３０ エンコーダ
３２ 変換メモリ
３３ バッファＲＡＭ
３４ 通信回路
３５ 表示コントローラ
３６ Ａ／Ｄ変換器
３７ エンコーダ部
３８ デコーダ部
３９ Ｄ／Ａ変換器

Claims (4)

1. オーディオデータ又は一般データファイルの記録に応じて記録又は更新され、オーディオデータ又は一般データファイルの再生動作を管理する管理情報として、記録媒体上の所定の管理エリア内に配される第１の管理情報と、一般データファイルが記録されている領域における物理的に先頭となる位置に配され一般データファイルの管理を行なう第２の管理情報と、前記第１の管理情報及び／又は第２の管理情報によって欠陥領域とされた領域に記録されている一般データファイルを管理することができる第３の管理情報とを備え、前記第３の管理情報は、前記第１の管理情報及び／又は第２の管理情報によって欠陥領域とされる１又は複数の一般データパーツのうちのいずれかの一般データパーツ内に配置されているデータ管理構造が形成される記録媒体に対して、
   前記第１の管理情報又は前記第２の管理情報に示される欠陥領域を検索して前記第３の管理情報を読み出し、その第３の管理情報に管理される一般データファイルを再生することを特徴とする再生方法。
2. オーディオデータ又は一般データファイルの記録に応じて記録又は更新され、オーディオデータ又は一般データファイルの再生動作を管理する管理情報として、記録媒体上の所定の管理エリア内に配される第１の管理情報と、一般データファイルが記録されている領域における物理的に先頭となる位置に配され一般データファイルの管理を行なう第２の管理情報と、前記第１及び／又は第２の管理情報によって欠陥領域とされた領域に記録された一般データファイルを管理することができる第３の管理情報とを備え、前記第３の管理情報は、前記第１の管理情報が配置される所定の管理エリア内において、前記第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスに相当する位置に配置されるデータ管理構造が形成される記録媒体に対して、
   前記第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスにアクセスして前記第３の管理情報を読み出し、その第３の管理情報に管理される一般データファイルを再生することを特徴とする再生方法。
3. オーディオデータ又は一般データファイルの記録に応じて記録又は更新され、オーディオデータ又は一般データファイルの再生動作を管理する管理情報として、記録媒体上の所定の管理エリア内に配される第１の管理情報と、一般データファイルが記録されている領域における物理的に先頭となる位置に配され一般データファイルの管理を行なう第２の管理情報と、前記第１の管理情報及び／又は第２の管理情報によって欠陥領域とされた領域に記録された一般データファイルを管理することができる第３の管理情報とを備え、前記第３の管理情報は、前記第１の管理情報及び／又は第２の管理情報によって欠陥領域とされる１又は複数の一般データパーツのうちのいずれかの一般データパーツ内に配置されているデータ管理構造が形成される記録媒体に対応する再生装置として、
   前記第１の管理情報又は前記第２の管理情報に示される欠陥領域を検索して前記第３の管理情報を読み出すことができる管理情報読出手段と、
   読み出された第３の管理情報に基づいて一般データファイルを再生することができる一般データ再生手段と、
   を備えたことを特徴とする再生装置。
4. オーディオデータ又は一般データファイルの記録に応じて記録又は更新され、オーディオデータ又は一般データファイルの再生動作を管理する管理情報として、記録媒体上の所定の管理エリア内に配される第１の管理情報と、一般データファイルが記録されている領域における物理的に先頭となる位置に配され一般データファイルの管理を行なう第２の管理情報と、前記第１及び／又は第２の管理情報によって欠陥領域とされた領域に記録された一般データファイルを管理することができる第３の管理情報とを備え、前記第３の管理情報は、前記第１の管理情報が配置される所定の管理エリア内において、前記第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスに相当する位置に配置されるデータ管理構造が形成される記録媒体に対応する再生装置として、
   前記第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスにアクセスして前記第３の管理情報を読み出すことができる管理情報読出手段と、
   読み出された第３の管理情報に基づいて一般データファイルを再生することができる一般データ再生手段と、
   を備えたことを特徴とする再生装置。
   

Images