(57)【要約】　　　（修正有）【課題】オーディオデータと一般データに兼用して記録／再生を行なう。また小型化、省電力化も好適とし、さらに違法コピーの使用を防止する。【解決手段】オーディオデータ又は一般データファイルの再生動作を管理する管理情報として、記録媒体上の第１の管理情報と、一般データファイル記録領域における物理的に先頭位置に配され一般データファイルの管理用第２の管理情報とを備えたデータ管理構造が形成され、前記第１の管理情報及び／又は前記第２の管理情報において欠陥領域として管理される領域内に、特定のキーワード情報が記録されている記録媒体に対応する再生装置として、第１の管理情報又は第２の管理情報に示される欠陥領域を検索してキーワード情報を読み出し、読み出されるべきキーワード情報の有無又は読み出されたキーワード情報の内容に応じて、実行する処理を選択する。【選択図】図２３
2004095165.tif 000002
【特許請求の範囲】
【請求項１】
　オーディオデータ又は一般データファイルの記録に応じて記録又は更新され、オーディオデータ又は一般データファイルの再生動作を管理する管理情報として、記録媒体上の所定の管理エリア内に配される第１の管理情報と、一般データファイルが記録されている領域における物理的に先頭となる位置に配され一般データファイルの管理を行なう第２の管理情報とを備えたデータ管理構造が形成されるとともに、前記第１の管理情報及び／又は前記第２の管理情報において欠陥領域として管理される領域内に、特定のキーワード情報が記録されている記録媒体に対応する再生装置として、
　前記第１の管理情報又は前記第２の管理情報に示される欠陥領域を検索して前記キーワード情報を読み出すことができるキーワード読出手段と、
　前記キーワード読出手段によって読み出されるべきキーワード情報の有無もしくは読み出されたキーワード情報の内容に応じて、実行する処理を選択する実行制御手段と、
　を備えたことを特徴とする再生装置。
【請求項２】
オーディオデータ又は一般データファイルの記録に応じて記録又は更新され、オーディオデータ又は一般データファイルの再生動作を管理する管理情報として、記録媒体上の所定の管理エリア内に配される第１の管理情報と、一般データファイルが記録されている領域における物理的に先頭となる位置に配され一般データファイルの管理を行なう第２の管理情報とを備えたデータ管理構造が形成されるとともに、前記第１の管理情報が配置される所定の管理エリア内において、前記第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスから記録される情報として、少なくとも特定のキーワード情報が含まれている記録媒体に対応する再生装置として、
　前記第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスにアクセスして前記キーワード情報を読み出すことができるキーワード読出手段と、
　前記キーワード読出手段によって読み出されるべきキーワード情報の有無もしくは読み出されたキーワード情報の内容に応じて、実行する処理を選択する実行制御手段と、
　を備えたことを特徴とする再生装置。
【請求項３】
前記キーワード読出手段によって読み出されるべきキーワード情報が存在しなかった場合、もしくは読み出されたキーワード情報が正しい内容でなかった場合は、前記実行制御手段はその記録媒体に対して再生動作を実行しないように制御することを特徴とする請求項１、又は請求項２に記載の再生装置。
【発明の詳細な説明】
【技術分野】
【０００１】
　本発明は、データ記録を行なう記録媒体（ディスク）に対応する再生装置に関するものである。
【背景技術】
【０００２】
　音楽等を記録／再生することのできる記録装置、再生装置、及び記録媒体としての光磁気ディスクが実用化され、特に近年、光磁気ディスクに対してユーザーが再生だけでなく楽曲等の音声を録音することができるもの（いわゆるミニディスク）も知られている。
【０００３】
　このミニディスクシステムを用いる場合、いわゆる音楽を記録／再生することが行なわれているが、さらにこのミニディスクシステムにおいて、音楽情報以外のデータを記録／再生できるようにすることも考えられる。
【０００４】
　なお、本明細書において、光磁気ディスクに記録される、音楽、音声等のいわゆるオーディオ信号をデジタル化したものを特に『オーディオデータ』といい、その１単位を『楽曲』又は『オーディオトラック』ということとする。そして、オーディオデータ以外の、文字、グラフィック等のいわゆるコンピュータなどの情報機器ユーズのデータであって光磁気ディスクに記録されるものを『一般データ』といい、オーディオデータと区別する。そして一般データの１つの記録再生単位を『データファイル』とする。
【発明の開示】
【発明が解決しようとする課題】
【０００５】
　ところで、もともと音楽用にフォーマットが構成されているミニディスクシステムを、一般データ用に用い、情報の検索や更新等をできるようにしようとすることはあまり適当であるとはいえない。特に、音楽用途のための楽曲の管理情報の場合はデータ用途の場合のデータファイルの管理情報とは異なって、検索のための名称データや属性データなどが重要ではなかったり（少なくとも曲番と対応アドレスが管理されていればよい）、検索データの外部機器への送信のためのデータなどは不要であったりすることや、オーディオデータではデータボリュームの小さいもの（例えば非常に短い楽曲）が多数存在する場合が余り考えられないため、一般データのように小さいデータファイルが非常に多数存在してしまう場合に対応する必要はなく、例えば後述するオーディオデータ用の管理情報では最大２５５曲までしか対応可能とされていない。
【０００６】
　これらの各種の点で音楽用途のための楽曲の管理情報はあくまで音楽用途に好適なように生成されており、一般データ用に適しているとはいえない。つまり、例えばミニディスクシステムをそのままの管理方式を用いて一般データの記録再生用に拡張することは適当でないという問題がある。
　なお、ミニディスクシステムを例にあげているが、もちろん他の方式の音楽用途の記録再生システムについても同様のことがいえる。
【０００７】
　さらに、一般データを記録した場合の管理形態を考えると、記録した一般データを有効に活用するためには、その管理情報の編集処理としてファイル名称の評価係数による整列、入れ換え、ファイル名テーブルのリンクの変更、ファイルアロケーションテーブルのメンテナンス等、各種の処理が行なわれることになるが、これらの処理のためには大容量のメモリが必要になり、また電力消費も大きく、さらに必要な処理が増えるに従って編集処理スピードも遅くなってしまう。これらの処理を例えばバッテリー駆動による携帯用などの小型の機器で十分に実行させようとすると、電力消費の面で負担が大きく、また処理速度の面でも十分な速度とすることは難しいという問題がある。
【０００８】
　また、データファイルを単に記録／再生できるようにするだけではコピーガードなどの点については不十分である。つまり、データソフト作成者が提供したディスクソフトを、作成者の了解を得ずにコピーした違法ディスクを作成することも容易であり、これに対する対策が望まれている。
【課題を解決するための手段】
【０００９】
　本発明はこのような問題点にかんがみてなされたもので、音楽用途の記録再生システムについてデータ記録再生用としても拡張し、オーディオデータと一般データに対して兼用して記録／再生を行なうことができるようにすること、また小型化、省電力化が要請される機器についても好適なものとすること、さらに違法コピーを防止できるようにすることを目的として、これらに好適な記録媒体を用いた再生装置を提供するものである。
【００１０】
　また、第１の管理情報と、第２の管理情報とを備えたデータ管理構造が形成されるとともに、第１の管理情報及び／又は第２の管理情報において欠陥領域として管理される領域内に、特定のキーワード情報が記録されている記録媒体に対応する再生装置として、キーワード読出手段と、実行制御手段とを設ける。
　キーワード読出手段は第１の管理情報又は第２の管理情報に示される欠陥領域を検索してキーワード情報を読み出すことができるようにする。
　実行制御手段は、キーワード読出手段によって読み出されるべきキーワード情報の有無もしくは読み出されたキーワード情報の内容に応じて、実行する処理を選択する。
【００１１】
　また、第１の管理情報と、第２の管理情報とを備えたデータ管理構造が形成されるとともに、第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスから記録される情報として、少なくとも特定のキーワード情報が含まれている記録媒体に対応する再生装置として、キーワード読出手段と、実行制御手段とを設ける。
　キーワード読出手段は、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスにアクセスしてキーワード情報を読み出すことができるようにする。
　実行制御手段は、キーワード読出手段によって読み出されるべきキーワード情報の有無もしくは読み出されたキーワード情報の内容に応じて、実行する処理を選択する。
【００１２】
　これらの再生装置において、キーワード読出手段によって読み出されるべきキーワード情報が存在しなかった場合、もしくは読み出されたキーワード情報が正しい内容でなかった場合は、実行制御手段はその記録媒体に対して再生動作を実行しないように制御する。
【００１３】
　例えばオーディオデータ用に設けられている第１の管理情報に加え、一般データ用としてデータファイル管理に好適な第２の管理情報を設けることにより、音楽用途の記録媒体をデータ用途として拡張し、オーディオデータと一般データの両方に対応する記録媒体を実現できる。そして第２の管理情報は、一般データファイルが記録されている領域における物理的に先頭となる位置に配することで、これをアクセスすることができ、一般データファイルの再生管理に用いることが可能となる。
【００１４】
　そしてこの際に、第１の管理情報では、一般データファイルが記録されている領域を一般データパーツとして管理することで、第１の管理情報においてオーディオデータエリアと一般データエリアを識別可能となり、データ混在に基づく誤記録／誤消去／再生エラー等は防止される。
【００１５】
　さらに第１の管理情報と第２の管理情報のほかに、第１及び第２の管理情報によって再生対象としては管理されない一般データファイルを管理することができる第３の管理情報を備えることで、これを簡易な記録／再生動作に用いることができる。つまり、第２の管理情報によって管理されるデータファイルとは別に、複雑な編集を行なわないファイルを保持することが可能となる。
【００１６】
　この第３の管理情報は、第１及び／又は第２の管理情報によって再生管理されない１又は複数の一般データパーツのうちの、いずれかの一般データパーツ内に配置することと規定するか、もしくは第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスに相当する位置に配置することで、アクセスし読み出すことが可能となる。
【００１７】
　また、第３の管理情報によって管理される一般データファイルが記録された１又は複数の一般データパーツについては、第１の管理情報と第２の管理情報の一方又は両方で、記録／再生対象とはならない欠陥領域として管理しておくことで、第１の管理情報、第２の管理情報から独立したエリアとして利用されている状態とすることができる。つまり第１の管理情報又は第２の管理情報による記録／再生動作対象とはならず消去されたり誤って再生されることはない。
【００１８】
　また、このような第３の管理情報によって管理される一般データファイルを、第２の管理情報によっても管理されるようにすることで、本来のデータファイルとして組み入れることができる。
【００１９】
　ここで、第３の管理情報によって管理される一般データファイルが第２の管理情報による管理対象に組み入れられた場合は、第３の管理情報を用いた動作で消去／書き換えがなされることは不都合となるが、第３の管理情報においてはその一般データファイルを書換不可データとして管理しておくようにすることで、不都合はなくなる。
【００２０】
　また第３の管理情報が、第１及び／又は第２の管理情報によって再生管理されない１又は複数の一般データパーツのうちの、いずれかの一般データパーツ内に配置される場合は、その第３の管理情報が記録されている領域は、第１の管理情報、第２の管理情報の一方又は両方においては記録／再生対象とはならない欠陥領域として管理しておくことで、第１の管理情報、第２の管理情報による記録／再生動作対象とはならず消去されたり誤って再生されることはない。
【００２１】
　また、第１の管理情報及び／又は第２の管理情報において欠陥領域として管理される領域内に、特定のキーワード情報が記録されているようにすると、通常の第１の管理情報、第２の管理情報による記録／再生動作対象とはならず、従ってそのキーワード情報はコピーされることはない。従って、このキーワード情報をコピーガードデータとして利用することができる。
　特定のキーワード情報が第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスから記録される情報内に含まれる場合も同様である。
【発明の効果】
【００２２】
　以上説明したように本発明による再生装置によれば、次のような各種の優れた効果を得ることができる。
【００２３】
　まず、オーディオデータなどのトラック管理のために設けられている第１の管理情報（Ｕ−ＴＯＣ）に加え、一般データ用としてデータファイル管理に好適な第２の管理情報（データＵ−ＴＯＣ）を設けることにより、音楽用途の記録媒体をデータ用途として拡張し、オーディオデータと一般データの両方に対応する記録媒体を実現できる。そして第２の管理情報は、一般データファイルが記録されている領域における物理的に先頭となる位置に配することで、これをアクセスすることができ、一般データファイルの再生管理に用いることが可能となる。
【００２４】
　また、第１の管理情報では、一般データファイルが記録されている領域を一般データパーツ、即ちデータトラックの一部として管理することで、第１の管理情報においてオーディオデータエリアと一般データエリアを識別可能となり、データ混在に基づく誤記録／誤消去／再生エラー等は防止される。
【００２５】
　さらに第１の管理情報（Ｕ−ＴＯＣ）と第２の管理情報（データＵ−ＴＯＣ）のほかに、第１及び第２の管理情報によって再生対象としては管理されない一般データファイルを管理することができる第３の管理情報（簡易Ｕ−ＴＯＣ）を備えることで、これを簡易な記録／再生動作に用いることができる。つまり、第２の管理情報によって管理されるデータファイルとは別に、複雑な編集を行なわないファイルを保持することが可能となる。
　そしてこの第３の管理情報による、記録／再生が行なわれる場合、第２の管理情報の読込／編集の必要はないため、データファイルの記録／再生／編集動作時に大きなメモリ容量を必要とせず、また消費電力も小さくできる。従って、小型機器などでは非常に好適となる。
【００２６】
　また第３の管理情報は、第１及び／又は第２の管理情報によって再生管理されない１又は複数の一般データパーツのうちの、いずれかの一般データパーツ内に配置すると規定するか、もしくは第１の管理情報が配置される所定の管理エリア内において、第１の管理情報のアドレスを用いた所定の演算で算出されるアドレスに相当する位置に配置することで、迅速にアクセスして読み出すことが可能となる。
【００２７】
　また、第３の管理情報によって管理される一般データファイルが記録された１又は複数の一般データパーツについては、第１の管理情報と第２の管理情報の一方又は両方で、記録／再生対象とはならない欠陥領域として管理しておくことで、第１の管理情報、第２の管理情報から独立したエリアとして利用されている状態とすることができる。つまり第１の管理情報又は第２の管理情報による記録／再生動作対象とはならず消去されたり誤って再生されることを防止できる。
【００２８】
　また、このような第３の管理情報によって管理される一般データファイルを、第２の管理情報によっても管理されるようにすることで、本来のデータファイルとして組み入れることができる。
　これによって第２の管理情報を用いた通常のデータファイル再生によって、第３の管理情報に対応するデータファイルを再生することができるようになり、従って、第３の管理情報による再生機能を持たない機器においても再生可能とすることができる。
　さらに、第３の管理情報に対応するデータファイルを第２の管理情報の管理下に編入することで、そのデータファイルは第２の管理情報における高度な編集動作の対象となり、各種有効利用できるようになる。
【００２９】
　また、第３の管理情報によって管理される一般データファイルが第２の管理情報による管理対象に組み入れられた場合は、そのデータファイルについては第３の管理情報を用いた動作による消去／書換が禁止されるようにすることで、第２の管理情報を使用せずに第２の管理情報が管理するデータファイルが消去されてしまうということは防止される。
【００３０】
　また第３の管理情報が、第１及び／又は第２の管理情報によって欠陥領域とされる１又は複数の一般データパーツのうちの、いずれかの一般データパーツ内に配置される場合は、その第３の管理情報が記録されている領域は、第１の管理情報、第２の管理情報の一方又は両方においては記録／再生対象とはならない欠陥領域として管理しておくことで、第１の管理情報、第２の管理情報による記録／再生動作対象とはならず、消去されたり誤って再生されることはない。
【００３１】
　また、第１の管理情報及び／又は第２の管理情報において欠陥領域として管理される領域内に、特定のキーワード情報が記録されているようにすることで、コピー先の記録媒体にはそのキーワード情報はコピーされず、もしくは正しいキーワード情報は得られないため、そのような記録媒体に対しては再生動作等を実行しないようにすれば、高度なコピーガードシステムを実現できる。
【発明を実施するための最良の形態】
【００３２】
　以下、本発明の実施例を次の順序で説明していく。
　Ｉ　．記録再生装置の構成
　　Ｉ−１　外観例
　　Ｉ−２　内部ブロック
　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−２　トラック構造
　ここで、ディスク１におけるトラック構造を説明し、Ｐ−ＴＯＣ及びＵ−ＴＯＣ、データＵ−ＴＯＣの位置関係及び管理態様を説明する。
【００６０】
　光磁気ディスクの場合、大きくわけて図４（ａ）にピットエリアとして示すよ
うにエンボスピットによりデータが記録されているエリア（ピットエリア）と、いわゆる光磁気エリアとされてグルーブが設けられているＭＯエリアに分けられる。
　ここでピットエリアとしてはＰ−ＴＯＣが記録される再生専用管理エリアとされており、後述するＰ−ＴＯＣセクターが繰り返し記録されている。
【００６１】
　最内周側のピットエリアに続いて、ディスク最外周のリードアウトエリアまでがＭＯエリアとされるが、ピットエリアに続く位置からリードアウトエリアの直前までが記録可能なレコーダブルエリアとされる。
【００６２】
　さらにこのレコーダブルエリアのうち、先頭エリアは記録再生管理エリアとされ、Ｕ−ＴＯＣの記録や、レーザーパワーのキャリブレーションエリアとして用いられる。
　Ｕ−ＴＯＣは記録再生管理エリアにおいて所要の位置に３クラスタ連続して記録されるものであり、Ｕ−ＴＯＣが記録再生管理エリア内のどのクラスタアドレスに記録されるかはＰ−ＴＯＣによって示される。
【００６３】
　実際にオーディオデータや一般データが記録されるレコーダブルユーザーエリアは、記録再生管理エリアの後に続くエリアとなる。
　このレコーダブルユーザーエリアにおいて、例えばＭ1 ，Ｍ2 ，Ｍ3 として示すようにオーディオトラック、即ち楽曲が記録されたり、またＦＬ1 ，ＦＬ2 ，ＦＬ3 として示すようにデータファイルが記録されたりする。
　データファイルとされた部位における最も内周側となる部位には、データファイルの管理のためのデータＵ−ＴＯＣが記録される。この例では、データファイルＦＬ1 の直前の位置にデータＵ−ＴＯＣが記録されていることになる。
【００６４】
　また、レコーダブルユーザーエリアにおいて、楽曲やデータファイルが記録されていない部分はフリーエリアとされる。つまり未記録領域であり、今後、楽曲やデータファイルの記録を行なうことができるエリアとして管理される。
【００６５】
　例えばこの図４（ａ）のように記録されたディスクに対して、Ｕ−ＴＯＣでは図４（ｂ）のように管理を行なっている。
　つまりＭ1 ，Ｍ2 ，Ｍ3 となる各オーディオトラックについては、そのスタートアドレス及びエンドアドレスを管理している。またフリーエリアについても同様に管理している。
　ところが、データファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、及びデータＵ−ＴＯＣが記録されている部位については、まとめて１つのデータトラックとして管理している。なお、ＥＢとはＵ−ＴＯＣによって管理されているデータトラック内で、実際にデータファイルが記録されていないエリアを示している。
【００６６】
　一方、データＵ−ＴＯＣでは図４（ｃ）に示すように、データトラック内での各データファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、及び未記録ブロックＥＢの管理を行なう。
【００６７】
　従って、記録再生装置がオーディオトラックを再生する場合はＵ−ＴＯＣからスタートアドレス及びエンドアドレスを判別して再生を行ない、また、データファイルを再生する場合は、Ｕ−ＴＯＣからデータＵ−ＴＯＣを探し、そのデータＵ−ＴＯＣを用いて所要のデータファイルをアクセスすることになる。
【００６８】
　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) までの各パーツテーブルにおいてそれぞれ１バイト（ｄ1 〜ｄ8 の８ビット）設けられているが、この各ビットがそれぞれ次のように各種モード状態を示している。
【０１０２】
　例えばビットｄ1 はそのパーツが記録可／記録不可であるか、ビットｄ2 はそのパーツがコピーライトプロテクトがなされているか、ビットｄ3 はそのパーツがオリジナル／２世代以後のコピー記録か、ビットｄ4 はそのパーツがオーディオデータか一般データか、ビットｄ5 ，ｄ6 はそのパーツがノーマルオーディオか否か、ビットｄ7 はそのパーツがモノラルオーディオデータかステレオオーディオデータか、ビットｄ8 はそのパーツのデータのエンファシス処理について、それぞれモードが示される。
【０１０３】
　従って、一般データエリアとしてパーツが管理される場合、対応するパーツテーブルにはこのトラックモードのうちビットｄ4 が例えば『１』（オーディオデータの場合ビットｄ4 ＝『０』）とされて、データトラックとして識別されることになる。
　なお、一般データがプリマスタードピットとしてディスクにＲＯＭ化されて記録されている場合は、上記Ｐ−ＴＯＣにおいてプリマスタードの楽曲の場合と同様に管理されるが、この場合もパーツテーブルにおけるトラックモードのうちビットｄ4 が『１』とされて、プリマスタードの楽曲と区別される。
【０１０４】
　II−５　データＵ−ＴＯＣセクター（第２の管理情報）
　　　II−５−ａ　全体構造
　上記のようにＵ−ＴＯＣにおいてはデータトラックとしてのパーツが管理されるのみであり、データトラック内の個々のデータファイルについての管理はデータＵ−ＴＯＣによって行なわれることになる。
【０１０５】
　図８にデータトラックの構造例を示す。図８（ａ）に示すようにデータトラックには物理的な先頭位置にデータＵ−ＴＯＣが記録される。つまり、データトラック内における最もディスク内周側に近い位置にデータＵ−ＴＯＣが記録される。データトラックが複数のパーツに別れている場合は、最もディスク内周側に位置するパーツの先頭にデータＵ−ＴＯＣが設けられることになる。
　このデータＵ−ＴＯＣは、図８（ｂ）のように１クラスタのブートエリアと、１６クラスタのボリュームマネジメントエリアから構成されている。
【０１０６】
　図８（ｂ）からわかるように、データＵ−ＴＯＣに続くエリアはファイルエクステンツエリアとされている。このファイルエクステンツエリアには、図８（ａ）のように実際のデータファイルＦＬ1 〜ＦＬ3 などが記録される。また未記録ブロックＥＢには、さらにデータファイルを記録していくことができる。
【０１０７】
　ボリュームマネジメントエリアは、図８（ｃ）のように５１２個のマネジメントブロックから構成される。１つのマネジメントブロックにおけるデータ領域は２０４８バイトとされる。
　そして、このマネジメントブロックにおけるデータが実際のデータファイルの記録／再生のための管理情報となる。
【０１０８】
　各マネジメントブロックは、１〜５１２までのブロックナンバが付されている。そして、ブロックナンバ１のマネジメントブロックはボリュームディスクリプタＶＤとして使用される。また、ブロックナンバ２のマネジメントブロックはボリュームスペースビットマップＶＳＢとして使用され、ブロックナンバ３のマネジメントブロックはマネジメントテーブルとして使用される。
　このブロックナンバ１〜３のマネジメントブロックについての使用形態は以上のように規定されている。ブロックナンバ４以降のマネジメントブロックはファイルエクステンツエリアの使用形態などに応じて使用される。
　即ち、マネジメントテーブルＭＴ、ディレクトリレコードブロックＤＲＢ、エクステンツレコードブロックＥＲＢとして使用できる。
【０１０９】
　　　II−５−ｂ　ブートエリア
　ブートエリアはコンピュータプログラム等が存在する場合のプログラム位置などを示す領域として用いられる。
【０１１０】
　ブートエリアのセクター構造は図９又は図１０のようになる。
　図９のブートエリアセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトに、各５１２バイトの４つのブロックデータが記録できる。即ちブロック０〜ブロック３であり、例えばブロック０はブロックデータ０−０からブロックデータ０−５１１で構成される。
【０１１１】
　ブロックデータが記録されるデータエリアに続いてＥＤＣ０〜ＥＤＣ３の４バイトのＥＤＣデータが記録される。続いてＥＣＣエリアとして、P-parity0 〜P-parity171 の１７２バイトのＰパリティ、及びQ-parity0 〜Q-parity103 の１０４バイトのＱパリティが記録される。
【０１１２】
　一方、図１０のタイプの場合は、データエリアとなる２０４８バイトに、各１０２４バイトの２つのブロックデータが記録できる。即ちブロック０、ブロック１であり、例えばブロック０はブロックデータ０−０からブロックデータ０−１２３で構成される。
　他は図９と同様である。
【０１１３】
　　　II−５−ｃ　ボリュームディスクリプタ
　ボリュームメネジメントエリアにおける先頭のマネジメントブロックはボリュームディスクリプタＶＤとして使用される。
　このボリュームディスクリプタＶＤは、ディスク上のデータトラック（ボリューム）の基本的な管理を行なうものである。
【０１１４】
　図１１にボリュームディスクリプタＶＤのセクター構造を示す。このセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトに各種管理情報が記録される。
【０１１５】
　まず、データエリアの２バイト目から６バイト目に、ボリュームディスクリプタのセクターであることを示すＩＤとして『ＭＤ００１』というコードが例えばアスキーコードで記録される。
　続いてこのシステムのバージョンＩＤが記録される。
【０１１６】
　次にロジカルブロックサイズ、ロジカルクラスタサイズ、アロケーションブロックサイズが記録される。
　ロジカルブロックとは、データトラックにおけるセクター内の実際のデータエリアに相当するもので、データトラックにおけるセクターは２３５２バイトのうち２０４８バイトをデータエリアと設定している。従って、ロジカルブロックサイズとしてバイト長である『２０４８』が記録される。ロジカルブロックは記録／再生におけるデータバイト最小単位となる。
【０１１７】
　またロジカルクラスタサイズはロジカルクラスタにおけるロジカルブロック数を示す。ロジカルクラスタとは、実際に管理情報やデータが記録されるクラスタである。そして、１クラスタは３６セクターとされ、そのうち３２セクター（３２ロジカルブロック）がデータ記録に用いられるため、ロジカルクラスタサイズとして『３２』が示される。
【０１１８】
　アロケーションブロックサイズとしてアロケーションブロックにおけるロジカルブロック数が示される。アロケーションブロックとはロジカルクラスタと同じデータ単位を示すものであり、データトラックにおける実際に管理情報やデータファイルが記録される部位である。例えば図８（ｂ）に示したボリュームマネジメントエリアやファイルエクステンツエリアにおけるロジカルクラスタとしての３２セクターの領域が、１つのアロケーションブロックとされる。
【０１１９】
　続いて、アロケーションブロック総数が記録される。これはボリューム内のアロケーションブロック総数である。ハイブリッドディスクの場合は、ピットエリアにおけるアロケーションブロック数も含まれる。
　また記録可能アロケーションブロック総数として、レコーダブルエリアにおけるアロケーションブロック数が記録される。プリマスタードディスクの場合は、これはゼロとされる。
【０１２０】
　また、未記録アロケーションブロック数としてボリューム内の記録可能アロケーションブロックのうち、まだ記録されていないアロケーションブロックの数が記される。
　さらに記録済アロケーションブロック数として、ボリューム内の記録可能アロケーションブロックのうち、既に記録が行なわれたアロケーションブロックの数が記される。
　またディフェクトアロケーションブロック数として、傷などの欠陥があるアロケーションブロックの数が記される。
【０１２１】
　次に、ボリューム内のディレクトリの数、ボリューム内のデータファイルの数が記される。
　次にＩＤ最大値が記録される。ディレクトリ又はデータファイルに対しては、生成される順にＩＤナンバが付されていくが、これはその最大値となる。
【０１２２】
　続いてボリューム属性が記録される。ここで、ボリュームマネジメントエリアがミラーモードで記録されているか否か、インビジブルファイルであるか否か、ライトプロテクトであるか否か、バックアップ必要か否か、ショートロケーション／ロングロケーションのいづれを使用しているか、などが記録される。
【０１２３】
　次にボリュームマネジメントエリアの長さとしてそのバイト長が記される。
　またボリュームマネジメントエリアの位置として、ボリュームマネジメントエリアの最初のアロケーションブロックのナンバーが記録される。
【０１２４】
　続いて、このボリュームディスクリプタと同様に、ボリュームマネジメントエリア内のマネジメントブロックが使用されて形成される他の管理ブロック、即ちボリュームスペースビットマップＶＳＢ、マネジメントテーブルＭＴ、エクステントレコードブロックＥＲＢ、ディレクトリレコードブロックＤＲＢについて、それぞれ最初のブロックの位置と、そのブロック数が記録される。
　続いて、ルートディレクトリのバイト長、及びルートディレクトリ内のディレクトリ数が記録される。
【０１２５】
　さらに、図１１においては各種ＩＤ等として示したが、以降データエリア内に各種のＩＤ及びキャラクタセットコード等が記録される。
　即ち、ブートシステムＩＤ、ボリュームＩＤ及びそのキャラクタセットコード、パブリッシャーＩＤ及びそのキャラクタセットコード、データプリペアーＩＤ及びそのキャラクタセットコード、アプリケーションＩＤ及びそのキャラクタセットコードが記録される。
　また、ボリュームの生成日時、ボリュームの更新日時、満了日時、有効日時が記録される。そしてデータエリアにおける１０２４〜２０４７バイトが、システムエクステンションエリアとされる。
【０１２６】
　なお、データエリアに続いて４バイトのＥＤＣエリア、及び２７６バイトのＥＣＣエリアが設けられている。ＥＣＣエリアには１７２バイトのＰパリティと１０４バイトのＱパリティが記録される。
【０１２７】
　　　II−５−ｄ　ボリュームスペースビットマップ
　ボリュームメネジメントエリアにおけるブロックナンバ２のマネジメントブロックはボリュームスペースビットマップＶＳＢとして使用される。
　このボリュームスペースビットマップＶＳＢは、データトラックの全てのアロケーションブロックのタイプを示すものである。
【０１２８】
　図１２にボリュームスペースビットマップＶＳＢのセクター構造を示す。このセクターでは、同期パターン及びアドレスが記されたヘッダに続いて、データエリアとなる２０４８バイトにおいて、１つのアロケーションブロックにつき２ビットづつが割り当てられ、そのタイプが示される。
　なお、このボリュームスペースビットマップＶＳＢのセクターも、データエリアに続いてＥＤＣエリア及びＥＣＣエリアが設けられる。
【０１２９】
　図１３（ａ）にデータエリアの内容を示す。
　データトラックにおけるアロケーションブロックには、ナンバー０から昇順にアロケーションブロックナンバが付されているが、ボリュームスペースビットマップＶＳＢのデータエリアの最初のバイトにおけるビット７，６が、ナンバー０のアロケーションブロックＡＬ0 に割り当てられ、以降２ビットづつアロケーションブロックＡＬ1 ，ＡＬ2 ・・・・・ と割り当てられる。
　従って、ボリュームスペースビットマップＶＳＢのデータエリアにおいて、アロケーションブロックＡＬ0 〜ＡＬ8191までの情報を記すことができ、全てのアロケーションブロックに十分に対応できる。
【０１３０】
　２ビットの情報は図１３（ｂ）のとおりである。つまり、未記録アロケーションブロックについては『００』、記録済アロケーションブロックについては『０１』、ディフェクト（欠陥）アロケーションブロックについては『１０』、未定義のアロケーションブロックについては『１１』とされる。
　なお、データエリアにおいて余りの部分、つまり対応するアロケーションブロックが存在しないビットについては『１１』とされる。
【０１３１】
　　　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) ＝（ｘ16＋ｘ15＋ｘ2 ＋１）（ｘ16＋ｘ2 ＋ｘ＋１）
である。
　この場合、このディスクからの再生情報に関しては、記録再生装置において図２に示すデコーダ２８からのエラー検出結果を用いずに、デコーダ２８からのデジタル信号出力のみでエラー検出を行なうことができる。
【０１７９】
　Mode＝『０２ｈ』の場合は、付加エリアの全てについてエラー検出及び訂正用のデータが使用される。つまり２０４８バイトのデータエリアに続く１７２バイトにＰパリティ（P-parity0 〜P-parity171 ）が付加され、さらに続く１０４バイトにＱパリティ（Q-parity0 〜Q-parity103 ）が付加される。これにより最大８０バイト程度のエラー訂正能力が実現される。
　このＰパリティ及びＱパリティはいわゆるＣＤ−ＲＯＭで採用されているガロアフィールド（Garoa Field ）（２8 ）との距離（２６，２４）のリードソロモンコードと同様の構成となっている。
【０１８０】
　次にこのセクターの第２２バイト目に設けられるカテゴリー情報（Category）の定義について説明する。
・・・カテゴリー情報（Category）＝『００ｈ』の場合。
　データエリアの状態に関わらず、このセクターがデータが記録されていないオープンセクターであることを示す。従って、セクターの内容を消去したい場合は、このカテゴリー情報（Category）を『００ｈ』に書き換えればよい。
【０１８１】
・・・カテゴリー情報（Category）＝『０１ｈ』の場合。
　このセクターにバイナリデータが記録されていることを示す。データの種類には制限がない。このようなセクターは、データエリアに記録されたバイトをそのままデジタルデータとしてアプリケーション（ソフトウエア）側に渡すような使い方がされることになる。なお、カテゴリー情報がこの『０１ｈ』である場合、続くインデックス情報としては、（Index ）としてのバイトに記録されている数値×１２８バイトの大きさだけデータ領域が確保されていることを示すこととなる。なお、データエリアは２０４８バイトであるため、インデックス情報（Index ）は『００ｈ』〜『１０ｈ』の内のいづれかの値をとることになる。
【０１８２】
・・・　カテゴリー情報（Category）＝『１０ｈ』〜『１Ｆｈ』の場合。
　このセクターにドキュメント（文書）データが記録されていることを示す。
この場合も、続くインデックス情報としては同様に、（Index ）としてのバイトに記録されている数値×１２８バイトの大きさだけデータ領域が確保されていることを示すこととなる。
【０１８３】
・・・　カテゴリー情報（Category）＝『２０ｈ』〜『２Ｆｈ』の場合。
　このセクターにシングルドットイメージ、つまり１枚のイメージファイルが白黒のドットデータとして記録されていることを示す。この場合も、続くインデックス情報としては同様に、（Index ）としてのバイトに記録されている数値×１２８バイトの大きさだけデータ領域が確保されていることを示す。
【０１８４】
・・・　カテゴリー情報（Category）＝『３０ｈ』〜『３Ｆｈ』の場合。
　このセクターにマルチプルドットイメージ、つまり複数枚のイメージファイルが白黒のドットデータとして記録されていることを示す。この場合も、続くインデックス情報としては同様に、（Index ）としてのバイトに記録されている数値×１２８バイトの大きさだけデータ領域が確保されていることを示す。
【０１８５】
III ．データファイル再生処理
　以上のようなディスク構造のディスクに対して図２の記録再生装置でデータファイルを再生する処理について図２、図４及び図２１を用いて説明する。
【０１８６】
　図２１はデータファイル再生のためのシステムコントローラ２１の処理を示している。
　データファイル再生のためには、ディスク１に対してシステムコントローラ２１はまずリードインエリアに光学ヘッド２３をアクセスさせてＰ−ＴＯＣを読み込む(F101)。ここで、Ｐ−ＴＯＣが読み込めなかった場合は、そのディスクは正しいディスクではない、もしくは再生操作がされた際にディスクが装填されていなかったと判断して、ステップF102からF103に進み、ディスクエラーとする。
【０１８７】
　Ｐ−ＴＯＣが読み込めた場合は、続いてＰ−ＴＯＣにおけるＵ−ＴＯＣスタートアドレス（ＵＳＴA ）に基づいてアクセスを行ない、記録再生管理エリアにおけるＵ−ＴＯＣを読み込む(F104)。
　ここでＵ−ＴＯＣが読み込めなかった場合、即ちＵ−ＴＯＣが記録されていなかった場合は、そのディスクはバージンディスクであると判断する (F105→F106) 。
【０１８８】
　Ｕ−ＴＯＣが読み込めたら、システムコントローラ２１は、このＵ−ＴＯＣに管理されているトラックとして、データトラックが存在するか否かを確認する。つまり、パーツテーブルのトラックモード情報として、ビットｄ4 ＝『１』であるパーツが存在するか否かを確認する(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−２　簡易Ｕ−ＴＯＣが記録された場合の管理形態
　簡易Ｕ−ＴＯＣがレコーダブルユーザーエリア内に記録されるタイプＡにおける、簡易Ｕ−ＴＯＣが記録された場合の管理形態例を、各場合にわけて図２３，図２５，図２７に示す。
　図２３，図２５，図２７は、簡易Ｕ−ＴＯＣによって管理を行なうデータファイルを記録した場合のトラック状態及びその管理形態を示すものである。つまり、簡易Ｕ−ＴＯＣによるデータファイル記録機能を備えた記録装置によってディスクにデータファイルが記録された状態である。この記録方式については後述する。
【０２０８】
　なお、ここで説明する各例は、実行することができる３種類の管理形態を示すものであり、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 の記録される位置についてはフリーエリアのどこかを用いればよいものであって、記録位置が管理形態の種別の特定に影響を与えるものではない。このタイプＡ、及び後述するタイプＢについての記録位置の設定については後にまとめて説明する。
【０２０９】
　まず図２３の例は、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣの両方によってディフェクトエリアとして管理される例である。
【０２１０】
　図２３（ａ）に示すように、オーディオトラックＭ1 ，Ｍ2 ，Ｍ3 、データトラック、即ちデータＵ−ＴＯＣ、データファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢ、に対して、物理的に離れた位置に簡易Ｕ−ＴＯＣと、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 が記録されている。
【０２１１】
　この場合、Ｕ−ＴＯＣによっては、図２３（ｂ）のようにオーディオトラックＭ1 ，Ｍ2 ，Ｍ3 が管理され、またデータＵ−ＴＯＣ、データファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢについては、一括してデータトラックとして管理されている。また、フリーエリアもＵ−ＴＯＣで管理される。
　そして、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域は、Ｕ−ＴＯＣ上では、テーブルポインタP-DFA から示されるディフェクトエリアとして管理されている。即ち、Ｕ−ＴＯＣ上では簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 の領域は記録／再生動作にとって無効な領域とみなされる。
【０２１２】
　また、データＵ−ＴＯＣによっては、図２３（ｃ）のようにデータファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢの管理が行なわれている。
　そして、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域は、データＵ−ＴＯＣ上でもディフェクトエリアとして管理されている。つまり、この領域はデータＵ−ＴＯＣで管理されるデータトラックとしての領域ではないが、ボリュームスペースビットマップ上においてこの領域に含まれるアロケーションブロックはディフェクトアロケーションブロックとして示されている状態である。
　従って、データＵ−ＴＯＣ上でも簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 の領域は記録／再生動作にとって無効な領域とみなされる。
【０２１３】
　そして、簡易Ｕ−ＴＯＣにとっては、図２３（ｄ）のようにデータファイルＫＦＬ1 ，ＫＦＬ2 が有効なデータファイルとして管理される。
　従って、データファイルＫＦＬ1 ，ＫＦＬ2 については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。
【０２１４】
　また、このような簡易Ｕ−ＴＯＣに管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 は、それをデータＵ−ＴＯＣの管理下に組み込んで、データＵ−ＴＯＣを用いた再生操作によっても、再生可能とすることができる。
【０２１５】
　図２３の状態からデータファイルＫＦＬ2 をデータＵ−ＴＯＣの管理下に組み込んだ状態を図２４に示す。
　この場合、図２４（ｂ）のようにＵ−ＴＯＣ上では、データファイルＫＦＬ2 のエリアがデータトラックの一部となるパーツとされるように更新される。
　そしてデータＵ−ＴＯＣでは、図２４（ｃ）のように、それまでディフェクトエリアとしていた部位のうち、データファイルＫＦＬ2 に相当する部位を、新たなデータファイルＦＬ4 として管理することになる。
【０２１６】
　簡易Ｕ−ＴＯＣでは図２４（ｄ）のように基本的に管理状態は変わらないが、データファイルＫＦＬ2 については、これを削除禁止とする。つまり、図２２に示した構成のディレクトリユニットにおいて、データファイルＫＦＬ2 に対応するディレクトリユニットの消去防止フラグ(Flag)を『０１ｈ』とする。
【０２１７】
　これは、データファイルＫＦＬ2 がデータファイルＦＬ4 としてデータＵ−ＴＯＣの管理に組み込まれたことに伴い、簡易Ｕ−ＴＯＣを用いた記録や編集動作によって消去されてしまうことを防止するためである。
　つまり、簡易Ｕ−ＴＯＣを用いた記録／編集により、データファイルＫＦＬ2 が消去されたりオーバライトされてしまうと、データＵ−ＴＯＣにおけるデータファイルＦＬ4 が、管理されているが実態の無いものとなってしまうためであり、これを避ける手段として、データファイルＫＦＬ2 が消去禁止ファイルとされる。
　従ってこれを消去したいときは、データＵ−ＴＯＣによる動作において消去することになる。
【０２１８】
　なお、図２３の例としては、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣの両方によってディフェクトエリアとして管理されているが、これをＵ−ＴＯＣのみがディフェクトエリアとして管理し、データＵ−ＴＯＣではデータトラック外であるとして管理をしないようにしてもよい。
【０２１９】
　次に、図２５の例は、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、データＵ−ＴＯＣによってディフェクトエリアとされ、Ｕ−ＴＯＣではディフェクトエリアとされていない状態で管理されている例である。
【０２２０】
　図２５（ａ）に示すように、データトラック、即ちデータＵ−ＴＯＣ、データファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢ、に対して、連続した位置に簡易Ｕ−ＴＯＣと、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 が記録されている。
【０２２１】
　もちろん、このような位置に記録された場合でも、上記図２３と同様の管理形態とすることもできるが、この例では、Ｕ−ＴＯＣによっては、図２５（ｂ）のように簡易Ｕ−ＴＯＣとデータファイルＫＦＬ1 ，ＫＦＬ2 が、データトラックの一部と見なされて管理されている。従って、図２３のような簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域をディフェクトエリアとする管理は行われていない。
【０２２２】
　一方、データＵ−ＴＯＣによっては、図２５（ｃ）のようにデータファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢの管理が行なわれて。そして、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域は、データトラック内におけるディフェクトエリアとして管理されている。つまり、この領域に含まれるアロケーションブロックはボリュームスペースビットマップ上においてディフェクトアロケーションブロックとして示されている。
　従って、データＵ−ＴＯＣ上では、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 の領域はデータトラック内において記録／再生動作無効な領域とみなされる。
【０２２３】
　そして、簡易Ｕ−ＴＯＣにとっては、図２５（ｄ）のようにデータファイルＫＦＬ1 ，ＫＦＬ2 が有効なデータファイルとして管理される。
　従って、この場合もデータファイルＫＦＬ1 ，ＫＦＬ2 については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。
【０２２４】
　また、このような簡易Ｕ−ＴＯＣに管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 は、それをデータＵ−ＴＯＣの管理下に組み込んで、データＵ−ＴＯＣを用いた再生操作によっても、再生可能とすることができる。
【０２２５】
　図２５の状態からデータファイルＫＦＬ2 をデータＵ−ＴＯＣの管理下に組み込んだ状態を図２６に示す。
　この場合、図２６（ｂ）のようにＵ−ＴＯＣ上での管理形態は変わらない。
　データＵ−ＴＯＣでは、図２６（ｃ）のように、それまでディフェクトエリアとしていた部位のうち、データファイルＫＦＬ2 に相当する部位を、新たなデータファイルＦＬ4 として管理する。
　そして簡易Ｕ−ＴＯＣでは図２６（ｄ）のように基本的に管理状態は変わらないが、上記図２４の場合と同様に、データファイルＫＦＬ2 については、これを消去禁止とする。
【０２２６】
　次に、図２７の例は、簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣによってディフェクトエリアとして管理されている例である。
　図２７（ａ）には、データトラックが記録されていない場合において、Ｕ−ＴＯＣで管理されているフリーエリアに簡易Ｕ−ＴＯＣと、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 が記録された場合を示している。
【０２２７】
　この場合、Ｕ−ＴＯＣは、図２７（ｂ）のように、簡易Ｕ−ＴＯＣとデータファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域をディフェクトエリアとして管理している。
　そして、データトラックが存在しないので、当然データＵ−ＴＯＣも存在せず、従ってデータＵ−ＴＯＣによる管理は行なわれていない（図２７（ｃ））。
【０２２８】
　簡易Ｕ−ＴＯＣでは、図２７（ｄ）のようにデータファイルＫＦＬ1 ，ＫＦＬ2 が有効なデータファイルとして管理される。
　従って、この場合もデータファイルＫＦＬ1 ，ＫＦＬ2 については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。
【０２２９】
　また、このように簡易Ｕ−ＴＯＣに管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 をデータＵ−ＴＯＣの管理下に組み込んで、データＵ−ＴＯＣを用いた再生操作によっても、再生可能とすることができる。
【０２３０】
　図２７の状態からデータファイルＫＦＬ2 をデータＵ−ＴＯＣの管理下に組み込んだ状態を図２８に示す。
　この場合、データトラックが存在しないため、まずデータトラックが生成される。つまり、図２８（ｃ）のように簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 の領域の先頭位置にデータＵ−ＴＯＣを記録し、この領域を図２８（ｂ）のようにＵ−ＴＯＣ上でデータトラックとして管理する。
【０２３１】
　さらに、新たに記録されたデータＵ−ＴＯＣでは、データファイルＫＦＬ2 を新たなデータファイルＦＬ1 として管理し、一方、簡易Ｕ−ＴＯＣ及びデータファイルＫＦＬ1 の領域をディフェクトエリアとする。つまり、ディフェクトアロケーションブロックとして管理する。
　簡易Ｕ−ＴＯＣ上では、図２８（ｄ）のように、データファイルＫＦＬ2 について、そのディレクトリユニット上で、これを消去禁止とする。
　これによってデータファイルＫＦＬ2 のみが、データＵ−ＴＯＣ上でデータファイルＦＬ1 として管理された状態が実現される。
【０２３２】
　なお、この場合に、データトラックＫＦＬ2 と新たに記録するデータＵ−ＴＯＣの領域のみをＵ−ＴＯＣ上でデータトラックとし、簡易Ｕ−ＴＯＣ及びデータファイルＫＦＬ1 の領域を、Ｕ−ＴＯＣ上でディフェクトエリアとするようにしてもよい。
　以上のように簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域についての管理形態は各種考えられる。
【０２３３】
　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 から導かれるパーツテーブルに示されるパーツとして、最初の２つが欠陥パーツで、次に簡易Ｕ−ＴＯＣを有するパーツ、その次に簡易Ｕ−ＴＯＣで管理されるデータファイルＫＦＬ1 を有するパーツが、リンクされて管理されていたとすると、３番目のパーツのアクセス時点で簡易Ｕ−ＴＯＣが発見されることになる。
　このような場合に、処理はステップ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)。これによって違法コピーディスクは記録再生装置にとって再生対象外の無効ディスクとなり、確実なコピーガードが実現されることになる。
【０２７８】
Ｖ　．簡易Ｕ−ＴＯＣを用いた記録再生方式（タイプＢ）
　次に、簡易Ｕ−ＴＯＣを用いた記録再生方式として、簡易Ｕ−ＴＯＣが記録再生管理エリア内に記録されるタイプＢについて述べる。
　なお、簡易Ｕ−ＴＯＣのセクター構造についてはタイプＡで説明した図２２と同様なため、説明を省略する。
【０２７９】
　Ｖ−１　簡易Ｕ−ＴＯＣが記録された場合の管理形態
　簡易Ｕ−ＴＯＣが記録再生管理エリア内に記録されるタイプＢにおける、簡易Ｕ−ＴＯＣが記録された場合の管理形態例を、各場合にわけて図３４，図３６，図３８に示す。
　図３４，図３６，図３８は、簡易Ｕ−ＴＯＣによって管理を行なうデータファイルを記録した場合のトラック状態及びその管理形態を示すものである。つまり、簡易Ｕ−ＴＯＣによるデータファイル記録機能を備えた記録装置によってディスクにデータファイルが記録された状態である。この記録方式については後述する。
【０２８０】
　なお、ここで説明する各例は、タイプＡで説明した際と同様に、実行することができる３種類の管理形態を示すものであり、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 の記録される位置についてはフリーエリアのどこかを用いればよいものであって、記録位置が管理形態の種別の特定に影響を与えるものではない。記録位置の設定については後述する。
【０２８１】
　まず図３４の例は、簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣの両方によってディフェクトエリアとして管理される例である。
【０２８２】
　図３４（ａ）に示すように、オーディオトラックＭ1 ，Ｍ2 ，Ｍ3 、データトラック、即ちデータＵ−ＴＯＣ、データファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢ、に対して、物理的に離れた位置に、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 が記録されている。
　簡易Ｕ−ＴＯＣについては、記録再生管理エリア内において、Ｕ−ＴＯＣ位置から所定のオフセットをもった位置に記録されている。
【０２８３】
　この場合、Ｕ−ＴＯＣによっては、図３４（ｂ）のようにオーディオトラックＭ1 ，Ｍ2 ，Ｍ3 が管理され、またデータＵ−ＴＯＣ、データファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢについては、一括してデータトラックとして管理されている。また、フリーエリアもＵ−ＴＯＣで管理される。
　そして、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域は、Ｕ−ＴＯＣ上では、テーブルポインタP-DFA から示されるディフェクトエリアとして管理されている。即ち、Ｕ−ＴＯＣ上では簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 の領域は記録／再生動作にとって無効な領域とみなされる。
【０２８４】
　また、データＵ−ＴＯＣによっては、図３４（ｃ）のようにデータファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢの管理が行なわれている。
　そして、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域は、データＵ−ＴＯＣ上でもディフェクトエリアとして管理されている。つまり、この領域はデータＵ−ＴＯＣで管理されるデータトラックとしての領域ではないが、ボリュームスペースビットマップ上においてこの領域に含まれるアロケーションブロックはディフェクトアロケーションブロックとして示されている状態である。
　従って、データＵ−ＴＯＣ上でも、データファイルＫＦＬ1 ，ＫＦＬ2 の領域は記録／再生動作にとって無効な領域とみなされる。
【０２８５】
　そして、簡易Ｕ−ＴＯＣにとっては、図３４（ｄ）のようにデータファイルＫＦＬ1 ，ＫＦＬ2 が有効なデータファイルとして管理される。
　従って、データファイルＫＦＬ1 ，ＫＦＬ2 については、後述するように簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。
【０２８６】
　また、タイプＡの場合と同様に、簡易Ｕ−ＴＯＣに管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 は、それをデータＵ−ＴＯＣの管理下に組み込んで、データＵ−ＴＯＣを用いた再生操作によっても、再生可能とすることができる。
【０２８７】
　図３４の状態からデータファイルＫＦＬ2 をデータＵ−ＴＯＣの管理下に組み込んだ状態を図３５に示す。
　この場合、図３５（ｂ）のようにＵ−ＴＯＣ上での管理として、データファイルＫＦＬ2 のエリアをデータトラックの１つのパーツとして組み入れるように、Ｕ−ＴＯＣを更新する。
　またデータＵ−ＴＯＣでは、図３５（ｃ）のように、それまでディフェクトエリアとしていた部位のうち、データファイルＫＦＬ2 に相当する部位を、新たなデータファイルＦＬ4 として管理することになる。
【０２８８】
　簡易Ｕ−ＴＯＣでは図３５（ｄ）のように基本的に管理状態は変わらないが、データファイルＫＦＬ2 については、データファイルＫＦＬ2 に対応するディレクトリユニットの消去防止フラグ(Flag)を『０１ｈ』として、削除禁止とする。これによってデータＵ−ＴＯＣにおけるデータファイルＦＬ4 が、簡易Ｕ−ＴＯＣ上のデータファイルＫＦＬ2 に対する編集動作などによって消去されてしまうことが防止される。
　データファイルＫＦＬ2 （＝ＦＬ4 ）を消去したいときは、データＵ−ＴＯＣによる動作において消去することになる。
【０２８９】
　なお、図３４の例としては、簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣ及びデータＵ−ＴＯＣの両方によってディフェクトエリアとして管理されているが、これをＵ−ＴＯＣのみがディフェクトエリアとして管理し、データＵ−ＴＯＣではデータトラック外であるとして管理をしないようにしてもよい。
【０２９０】
　次に、図３６の例は、簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、データＵ−ＴＯＣによってディフェクトエリアとされ、Ｕ−ＴＯＣではディフェクトエリアとされていない状態で管理されている例である。
【０２９１】
　図３６（ａ）に示すように、データトラック、即ちデータＵ−ＴＯＣ、データファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢ、に対して、連続した位置に、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 が記録されている。
　簡易Ｕ−ＴＯＣは、記録再生管理エリア内において、Ｕ−ＴＯＣ位置から所定のオフセットをもった位置に記録されている。
【０２９２】
　もちろん、このような位置に記録された場合でも、上記図３４と同様の管理形態とすることもできるが、この例では、Ｕ−ＴＯＣによっては、図３６（ｂ）のようにデータファイルＫＦＬ1 とＫＦＬ2 が、データトラックの一部と見なされて管理されている。従って、図３４のような、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域をディフェクトエリアとする管理は行なわれていない。
【０２９３】
　一方、データＵ−ＴＯＣによっては、図３６（ｃ）のようにデータファイルＦＬ1 ，ＦＬ2 ，ＦＬ3 、未記録ブロックＥＢの管理が行なわれて。そして、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域は、データトラック内におけるディフェクトエリアとして管理されている。つまり、この領域に含まれるアロケーションブロックはボリュームスペースビットマップ上においてディフェクトアロケーションブロックとして示されている。
　従って、データＵ−ＴＯＣ上では、簡易Ｕ−ＴＯＣ、データファイルＫＦＬ1 ，ＫＦＬ2 の領域はデータトラック内において記録／再生動作無効な領域とみなされる。
【０２９４】
　そして、簡易Ｕ−ＴＯＣにとっては、図３６（ｄ）のようにデータファイルＫＦＬ1 ，ＫＦＬ2 が有効なデータファイルとして管理される。
　従って、この場合もデータファイルＫＦＬ1 ，ＫＦＬ2 については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。
【０２９５】
　図３６において簡易Ｕ−ＴＯＣのみに管理されているデータファイルＫＦＬ2 を、データＵ−ＴＯＣの管理下に組み込んだ状態を図３７に示す。
　この場合、図３７（ｂ）のようにＵ−ＴＯＣ上での管理形態は変わらない。
　データＵ−ＴＯＣでは、図３７（ｃ）のように、それまでディフェクトエリアとしていた部位のうち、データファイルＫＦＬ2 に相当する部位を、新たなデータファイルＦＬ4 として管理する。
　そして簡易Ｕ−ＴＯＣでは図３７（ｄ）のように基本的に管理状態は変わらないが、上記図３５の場合と同様に、データファイルＫＦＬ2 については、これを消去禁止とする。
【０２９６】
　次に、図３８の例は、簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域が、Ｕ−ＴＯＣによってディフェクトエリアとして管理されている例である。
【０２９７】
　図３８（ａ）には、データトラックが記録されていない場合において、Ｕ−ＴＯＣで管理されているフリーエリアに、簡易Ｕ−ＴＯＣによって管理されるデータファイルＫＦＬ1 ，ＫＦＬ2 が記録された場合を示している。
　簡易Ｕ−ＴＯＣは、記録再生管理エリア内において、Ｕ−ＴＯＣ位置から所定のオフセットをもった位置に記録されている。
【０２９８】
　この場合、Ｕ−ＴＯＣは、図３８（ｂ）のように、データファイルＫＦＬ1 ，ＫＦＬ2 が記録されている領域をディフェクトエリアとして管理している。
　そして、データトラックが存在しないので、当然データＵ−ＴＯＣも存在せず、従ってデータＵ−ＴＯＣによる管理は行なわれていない（図３８（ｃ））。
【０２９９】
　簡易Ｕ−ＴＯＣでは、図３８（ｄ）のようにデータファイルＫＦＬ1 ，ＫＦＬ2 が有効なデータファイルとして管理される。
　従って、この場合もデータファイルＫＦＬ1 ，ＫＦＬ2 については、後述する簡易Ｕ−ＴＯＣをアクセスすることができる機能を有する再生装置によってのみ再生できることになる。
【０３００】
　また、図３８の状態からデータファイルＫＦＬ2 をデータＵ−ＴＯＣの管理下に組み込んだ状態を図３９に示す。
　この場合、データトラックが存在しないため、まずデータトラックが生成される。
　つまり、図３９（ｃ）のようにデータファイルＫＦＬ1 ，ＫＦＬ2 の領域の先頭位置にデータＵ−ＴＯＣを記録し、この領域を図３９（ｂ）のようにＵ−ＴＯＣ上でデータトラックとして管理する。
【０３０１】
　さらに、新たに記録されたデータＵ−ＴＯＣでは、データファイルＫＦＬ2 を新たなデータファイルＦＬ1 として管理し、一方、データファイルＫＦＬ1 の領域をディフェクトエリアとする。つまり、ディフェクトアロケーションブロックとして管理する。
　簡易Ｕ−ＴＯＣ上では、図３９（ｄ）のように、データファイルＫＦＬ2 について、そのディレクトリユニット上で、これを消去禁止とする。
　これによってデータファイルＫＦＬ2 のみが、データＵ−ＴＯＣ上でデータファイルＦＬ1 として管理された状態が実現される。
【０３０２】
　なお、この場合に、データトラックＫＦＬ2 と新たに記録するデータＵ−ＴＯＣの領域のみをＵ−ＴＯＣ上でデータトラックとし、データファイルＫＦＬ1 の領域を、Ｕ−ＴＯＣ上でディフェクトエリアとするようにしてもよい。
【０３０３】
　以上のように簡易Ｕ−ＴＯＣ及び簡易Ｕ−ＴＯＣによって管理されるデータファイルが記録された領域についての管理形態は各種考えられる。
【０３０４】
　Ｖ−２　簡易Ｕ−ＴＯＣを用いるデータファイル記録処理
　次に、図２のような記録再生装置、もしくは同様の記録手段としてのブロック構成を備えた記録装置において実現できる簡易Ｕ−ＴＯＣを用いるデータファイル記録処理を説明する。タイプＡの場合と同様に、この記録処理は図２とほぼ同様の記録ブロック構成を備えているが、メモリ容量などの各種スペックが小規模化された例えば携帯用小型機器においても容易に実現できる。
【０３０５】
　図２の記録再生装置の動作としてこの記録動作を説明する。
　図４０は記録時のシステムコントローラ２１の処理を示している。
　コネクタ部１５及び通信回路３４を介したり、もしくは画像スキャナ１４によって、記録すべきデータが入力されて記録操作がなされたら、実際の記録処理が開始される (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 を、フリーエリアのうち比較的ディスク内周側に記録した場合を示している。
　このとき、データトラックが、データファイルＫＦＬ1 より外周側に位置しており、従ってデータＵ−ＴＯＣがデータファイルＫＦＬ1 より後方のアドレスとなっていたとする。
【０３３６】
　ここで、上述したように、簡易Ｕ−ＴＯＣに対応するデータファイルＫＦＬ1 をデータＵ−ＴＯＣの管理下に編入する操作が行なわれたとする。
　この場合、編入動作としては、データファイルＫＦＬ1 が記録されているエリアを、データＵ−ＴＯＣにおいて新たなデータファイルＦＬ3 として管理するようにデータＵ−ＴＯＣを更新すればよい。また、Ｕ−ＴＯＣ上ではデータファイルＫＦＬ1 のエリアをディフェクトエリアから外し、データトラックのパーツとして組み入れることになる。
【０３３７】
　ところが、この新たなデータファイルＦＬ3 の位置はそれまでのデータＵ−ＴＯＣよりも内周側に位置している。
　データＵ−ＴＯＣはデータトラックを構成するパーツのうち、一番内周側のパーツの先頭位置に記録されることが規定されているため、データファイルＫＦＬ1 をデータファイルＦＬ3 としてデータトラックを構成するパーツに組み入れたら、このデータファイルＦＬ3 となるパーツの直前にデータＵ−ＴＯＣが記録されなければならないことになる。
【０３３８】
　このため、編入時の処理として、データＵ−ＴＯＣで編入のための更新を行なうのみでなく、その更新したデータＵ−ＴＯＣを図４４（ｂ）のようにデータファイルＦＬ3 となるパーツの直前に記録し、次に図４４（ｃ）のように今迄のデータＵ−ＴＯＣのエリアをフリーエリアに編入する処理が必要になる。
　つまり、データＵ−ＴＯＣ内容の更新、データＵ−ＴＯＣの新たな位置への記録、Ｕ−ＴＯＣでのデータトラック、ディフェクトエリア、フリーエリアの更新、という多数の処理が必要となる。
【０３３９】
　一方、図４５（ａ）は、簡易Ｕ−ＴＯＣに対応するデータファイルＫＦＬ1 が、フリーエリアのうちのディスク外周側となる位置に記録した場合を示している。このとき、データトラックは、データファイルＫＦＬ1 より内周側に位置しており、従ってデータＵ−ＴＯＣはデータファイルＫＦＬ1 より前方のアドレスとなっていたとする。
【０３４０】
　ここで、簡易Ｕ−ＴＯＣに対応するデータファイルＫＦＬ1 をデータＵ−ＴＯＣの管理下に編入する操作が行なわれたとする。
　この場合、編入動作としては、図４５（ｂ）のように、データファイルＫＦＬ　が記録されているエリアを、データＵ−ＴＯＣにおいて新たなデータファイルＦＬ　として管理するようにデータＵ−ＴＯＣを更新すればよい。また、Ｕ−ＴＯＣ上ではデータファイルＫＦＬ1 のエリアをディフェクトエリアから外し、データトラックのパーツとして組み入れることになる。
【０３４１】
　つまり、この場合はデータＵ−ＴＯＣの位置を変更する必要はなく、そのデータＵ−ＴＯＣの位置において更新が必要な部分のみ内容を書き換えればよい。
　またＵ−ＴＯＣ上でフリーエリアを更新する必要もない。このため比較的簡単な処理で編入が完了する。
【０３４２】
　この図４４、図４５の例からわかるように、簡易Ｕ−ＴＯＣに対応するデータファイルについては、データＵ−ＴＯＣへの編入処理を考慮して、なるべくディスク外周側の位置に記録できるようにすると都合がよい。
　さらに、これに加えて、データＵ−ＴＯＣへの編入後では、その編入されたデータファイルとデータＵ−ＴＯＣの位置が物理的に近いほうが好ましい。これは再生時のアクセス速度を高速化させることになる。特にＣＬＶ方式の場合、スピンドルモータの回転数はディスク上の位置によって異なるものとなるが、長い距離をアクセスする場合は、スピンドルモータの回転数の制定制御に時間を要することになるため、この点でもデータファイルとデータＵ−ＴＯＣの位置は近いほど好適である。
【０３４３】
　このため、本実施例では次の1，2，3のような条件で、簡易Ｕ−ＴＯＣに対応するデータファイルの記録位置を設定している。
【０３４４】
　1　データトラック（データＵ−ＴＯＣ）が存在しない場合
　存在するフリーエリアのうち、最もディスク外周側に近い部位において必要な領域長を探して記録する。これによって、その後データトラックが形成された場合に、その先頭位置となるデータＵ−ＴＯＣが、簡易Ｕ−ＴＯＣに対応するデータファイルよりもディスク内周側となるようにする。また、最外周位置に記録しておくことで、その後にデータトラックを記録する場合の自由度を最大とすることできる。
【０３４５】
　2　データトラック（データＵ−ＴＯＣ）が存在する場合
　存在するフリーエリアのうち、データトラックより外周側で、しかもデータトラックに近い位置において必要な領域長を探して記録する。これによって簡易Ｕ−ＴＯＣに対応するデータファイルが、データＵ−ＴＯＣよりもディスク外周側となるようにするとともに、できればデータトラックの後に連続した位置に記録されるようにして、編入後のアクセス速度に有利となるようにする。
【０３４６】
　3　上記条件を満たすフリーエリアが存在しない場合
　この場合は、存在するフリーエリアのうちできるだけ外周側に近い位置に記録していくようにする。この場合は、図４４のように簡易Ｕ−ＴＯＣに対応するデータファイルがデータＵ−ＴＯＣより内周側になる場合があるが、これはやむを得ない。
【０３４７】
　簡易Ｕ−ＴＯＣを用いたデータファイルの記録に際して、以上のように記録位置が選定されることで、データＵ−ＴＯＣによる通常のデータファイルの記録／再生などに最も都合のよい状態とすることができる。
【０３４８】
　以上、本発明の実施例を説明してきたが、本発明はこの実施例に示したもの以外にも各種変形例が考えられることはいうまでもない。
【図面の簡単な説明】
【０３４９】
【図１】本発明の実施例の記録再生装置及びディスクの外観の説明図である。
【図２】実施例の記録再生装置のブロック図である。
【図３】実施例のディスクのクラスタ構造の説明図である。
【図４】実施例のＵ−ＴＯＣ及びデータＵ−ＴＯＣが記録されたディスクの管理状態の説明図である。
【図５】実施例のディスクのＰ−ＴＯＣセクターの説明図である。
【図６】実施例のディスクのＵ−ＴＯＣセクターの説明図である。
【図７】実施例のディスクのＵ−ＴＯＣセクターのリンク形態の説明図である。
【図８】実施例のディスクのデータトラックの説明図である。
【図９】実施例のディスクのデータＵ−ＴＯＣにおけるブートエリアの説明図である。
【図１０】実施例のディスクのデータＵ−ＴＯＣにおけるブートエリアの説明図である。
【図１１】実施例のディスクのデータＵ−ＴＯＣにおけるボリュームディスクリプタの説明図である。
【図１２】実施例のディスクのデータＵ−ＴＯＣにおけるボリュームスペースビットマップの説明図である。
【図１３】実施例のディスクのデータＵ−ＴＯＣにおけるボリュームスペースビットマップに記録されるデータの説明図である。
【図１４】実施例のディスクのデータＵ−ＴＯＣにおけるマネジメントテーブルの説明図である。
【図１５】実施例のディスクのデータＵ−ＴＯＣにおけるマネジメントテーブルに記録されるデータの説明図である。
【図１６】実施例のディスクのデータＵ−ＴＯＣにおけるディレクトリレコードブロックの説明図である。
【図１７】実施例のディスクのデータＵ−ＴＯＣにおけるディレクトリレコードブロックの説明図である。
【図１８】実施例のディスクのデータＵ−ＴＯＣにおけるエクステントレコードブロックの説明図である。
【図１９】実施例のディスクのデータＵ−ＴＯＣにおけるエクステントレコードブロックの説明図である。
【図２０】実施例のディスクのデータセクターの説明図である。
【図２１】実施例のデータＵ−ＴＯＣ対応のデータ再生処理のフローチャートである。
【図２２】実施例のディスクの簡易Ｕ−ＴＯＣセクターの説明図である。
【図２３】実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。
【図２４】実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。
【図２５】実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。
【図２６】実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。
【図２７】実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。
【図２８】実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。
【図２９】実施例の簡易Ｕ−ＴＯＣ対応の記録処理のフローチャートである。
【図３０】実施例の簡易Ｕ−ＴＯＣ対応の再生／編入処理のフローチャートである。
【図３１】実施例の簡易Ｕ−ＴＯＣ検索動作の説明図である。
【図３２】実施例のコピーガードデータ記録処理のフローチャートである。
【図３３】実施例のコピーガードのための再生処理のフローチャートである。
【図３４】実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。
【図３５】実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。
【図３６】実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。
【図３７】実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。
【図３８】実施例の簡易Ｕ−ＴＯＣが記録されたディスクのトラック管理状態の説明図である。
【図３９】実施例の簡易Ｕ−ＴＯＣに対応するデータファイルをデータＵ−ＴＯＣに編入した後のトラック管理状態の説明図である。
【図４０】実施例の簡易Ｕ−ＴＯＣ対応の記録処理のフローチャートである。
【図４１】実施例の簡易Ｕ−ＴＯＣ対応の再生／編入処理のフローチャートである。
【図４２】実施例のコピーガードデータ記録処理のフローチャートである。
【図４３】実施例のコピーガードのための再生処理のフローチャートである。
【図４４】実施例の簡易Ｕ−ＴＯＣ対応のデータファイルの記録位置の説明図である。
【図４５】実施例の簡易Ｕ−ＴＯＣ対応のデータファイルの記録位置の説明図である。
【符号の説明】
【０３５０】
　１　ディスク
　１０　記録再生装置
　１１　ディスク挿入部
　１２　キー入力部
　１３　表示部
　１４　画像スキャナ部
　１５　入出力コネクタ部
　１６　入出力端子
　２１　システムコントローラ
　２３　光学ヘッド
　２８　デコーダ
　３０　エンコーダ
　３２　変換メモリ
　３３　バッファＲＡＭ
　３４　通信回路
　３５　表示コントローラ
　３６　Ａ／Ｄ変換器
　３７　エンコーダ部
　３８　デコーダ部
　３９　Ｄ／Ａ変換器
【図１】
2004095165.tif 000003
【図２】
2004095165.tif 000004
【図３】
2004095165.tif 000005
【図４】
2004095165.tif 000006
【図５】
2004095165.tif 000007
【図６】
2004095165.tif 000008
【図７】
2004095165.tif 000009
【図８】
2004095165.tif 000010
【図９】
2004095165.tif 000011
【図１０】
2004095165.tif 000012
【図１１】
2004095165.tif 000013
【図１２】
2004095165.tif 000014
【図１３】
2004095165.tif 000015
【図１４】
2004095165.tif 000016
【図１５】
2004095165.tif 000017
【図１６】
2004095165.tif 000018
【図１７】
2004095165.tif 000019
【図１８】
2004095165.tif 000020
【図１９】
2004095165.tif 000021
【図２０】
2004095165.tif 000022
【図２１】
2004095165.tif 000023
【図２２】
2004095165.tif 000024
【図２３】
2004095165.tif 000025
【図２４】
2004095165.tif 000026
【図２５】
2004095165.tif 000027
【図２６】
2004095165.tif 000028
【図２７】
2004095165.tif 000029
【図２８】
2004095165.tif 000030
【図２９】
2004095165.tif 000031
【図３０】
2004095165.tif 000032
【図３１】
2004095165.tif 000033
【図３２】
2004095165.tif 000034
【図３３】
2004095165.tif 000035
【図３４】
2004095165.tif 000036
【図３５】
2004095165.tif 000037
【図３６】
2004095165.tif 000038
【図３７】
2004095165.tif 000039
【図３８】
2004095165.tif 000040
【図３９】
2004095165.tif 000041
【図４０】
2004095165.tif 000042
【図４１】
2004095165.tif 000043
【図４２】
2004095165.tif 000044
【図４３】
2004095165.tif 000045
【図４４】
2004095165.tif 000046
【図４５】
2004095165.tif 000047