JP4055313B2 - 再生装置、及び情報伝送方法 - Google Patents

再生装置、及び情報伝送方法 Download PDF

Info

Publication number
JP4055313B2
JP4055313B2 JP34681699A JP34681699A JP4055313B2 JP 4055313 B2 JP4055313 B2 JP 4055313B2 JP 34681699 A JP34681699 A JP 34681699A JP 34681699 A JP34681699 A JP 34681699A JP 4055313 B2 JP4055313 B2 JP 4055313B2
Authority
JP
Japan
Prior art keywords
disc
data
information
recording
layer
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Fee Related
Application number
JP34681699A
Other languages
English (en)
Other versions
JP2001167515A (ja
Inventor
由美子 大貫
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Sony Corp
Original Assignee
Sony Corp
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Sony Corp filed Critical Sony Corp
Priority to JP34681699A priority Critical patent/JP4055313B2/ja
Publication of JP2001167515A publication Critical patent/JP2001167515A/ja
Application granted granted Critical
Publication of JP4055313B2 publication Critical patent/JP4055313B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Images

Landscapes

  • Management Or Editing Of Information On Record Carriers (AREA)
  • Small-Scale Networks (AREA)
  • Signal Processing For Digital Recording And Reproducing (AREA)

Description

【０００１】
【発明の属する技術分野】
本発明は、所定の記録媒体に対応して再生が可能な再生装置、また、この再生装置における情報伝送方法に関するものである。
【０００２】
【従来の技術】
オーディオデータが記録された再生専用ディスクとして、ＣＤ(Compact Disc)が広く普及していると共に、このＣＤ−ＤＡより大容量な新たな光ディスクとしてＤＶＤ（Digital Versatile Disc）が提案されている。
このＤＶＤは直径１２ｃｍの光ディスクに従来のＣＤのトラックピッチ１．６μｍの半分の０．８μｍで情報を記録し、半導体レーザの波長をＣＤの７８０ｎｍから例えば６５０ｎｍに変更し、更にＣＤで採用されたＥＦＭ（Eight to Fourteen Modulation）変調方式に改良を加えて片面で約４Ｇバイト相当の高密度記録を実現させている。
そして現在、例えば上記のようなＤＶＤに準拠して、ＣＤよりも高音質とされるオーディオデータを記録した高音質オーディオディスクも提案されている。
【０００３】
ＣＤのデータフォーマットとしては、周知のように、サンプリング周波数が４４．１ＫＨｚとされ、量子化ビットは１６ビットとされる。また、デジタルオーディオ信号の記録変調方式にはＥＦＭ(Eight to Fourteen Moduration)が採用されているものである。
これに対して、上記高音質オーディオディスクのデータフォーマットとしては、サンプリング周波数については、上記４４．１ＫＨｚの６４倍である２．８２２４ＭＨｚという非常に高い周波数によりサンプリングを行い、更に、ΣΔ変調による１ビット量子化を行ってメディアへ記録するものとしている。
また、この高音質オーディオディスクは、従来から販売されているコンパクトディスクと外観はほぼ同じとされる。
なお、以降の説明にあたり、ＣＤのデータフォーマットによるオーディオデータについては「ＣＤデータ」といい、高音質オーディオディスクのデータフォーマットによるオーディオデータについては、「ＨＤ（Hi-Definition）データ」ともいうことにする。
【０００４】
また、上記したＨＤデータが記録されるディスクとしては、記録層として２つの層（レイヤー）を備えたマルチレイヤーディスク（複層ディスク）とすることも提案されている。
このマルチレイヤーディスクとして、１つには、各レイヤーにＨＤデータを記録するようにした複層ディスクが提案されている。
そしてもう１つには、一方のレイヤーにＣＤデータを記録し、他方のレイヤーにＨＤデータを記録した、いわゆるハイブリッドディスクの形態とすることが提案されている。
なお、レイヤーの名称として、ＨＤデータが記録されるレイヤーについては「ＨＤレイヤー」ともいい、また、ＣＤデータが記録されるレイヤーについては「ＣＤレイヤー」ともいうことにする。
【０００５】
上記ハイブリッドディスクについては、音楽等のデータ内容（プログラム）としては、各レイヤーで同一の内容（例えば同一の曲）とすることが考えられており、従ってその同一内容のデータが、ＣＤレベルの通常品質のデータとして一方のレイヤーに記録されるとともに、より高品質なデータが他方のレイヤーに記録されるようにする。
【０００６】
このようなハイブリッドディスクにおいては、一方のレイヤーは、ＣＤデータが記録されることになるので、現在市場で普及しているＣＤプレーヤーの機能によっても再生可能となる。
そして、ＣＤプレーヤとしての機能を有する再生装置において、ＨＤデータに対応したデコーダを備えれば、上記他方のレイヤーに記録された新たなフォーマットのデータも再生できる再生装置が実現される。
即ちこのような再生装置においては、両方のレイヤーからの再生を可能にすることで、一般に多数所有されているコンパクトディスクも再生でき、かつ上記したハイブリッドディスクについても再生可能となる。また、当然のこととして、ＨＤデータを記録したＨＤレイヤーの１層のみを有する高音質オーディオディスクについても再生可能となるものである。
【０００７】
また、近年においては、デジタルデータインターフェイスとして、ＩＥＥＥ(Institute of Electrical Engineers)１３９４データインターフェイスが知られてきている。
ＩＥＥＥ１３９４のデータインターフェイスは、例えばＳＣＳＩやＵＳＢなどのデータインターフェイスよりもデータ転送レートが高速であり、周知のように、所要のデータサイズを周期的に送受信することが保証されるＩｓｏｃｈｒｏｎｏｕｓ通信が可能とされる。このため、ＩＥＥＥ１３９４データインターフェイスは、ＡＶなどのストリームデータをリアルタイムで転送するのに有利とされている。
【０００８】
このため、各種デジタルＡＶ(Audio Visual)機器やパーソナルコンピュータ装置等の電子機器を、例えばＩＥＥＥ(The Institute of Electrical and Electronics Engineers)１３９４等のデジタルデータインターフェイス規格に従ったデータバスを介して相互に接続することで、機器間でデータを送受信できるようにしたデータ伝送システムが提案されてきている。これにより、ＡＶシステムとして有用とされる各種機能を与えることができる。
【０００９】
このようなＡＶシステムとしての機能の一例としては、いわゆるリモート制御も可能となる。例えば、データバスを介してディスク記録再生装置とパーソナルコンピュータが接続されているとして、ディスク記録再生装置に対する記録再生、更には記録ソースの編集などに関する操作をパーソナルコンピュータ装置側での操作によって行うといったことも可能となる。
【００１０】
【発明が解決しようとする課題】
現状、ＩＥＥＥ１３９４データインターフェイスに従ったＡＶ機器を対象とする伝送規格にあっては、例えば上記したＣＤや、また、既に普及率の高いＭＤ（Mini Disc)などのメディアに対応しては、ほぼ機能が充実している段階にある。
【００１１】
そして例えば、ＩＥＥＥ１３９４データインターフェイスによる各種機能を上記のようにして新たに出現してくる高音質オーディオディスクなどのメディアに対応させようとした場合には、上記したＣＤなどの機能に対応して既に定義された規格を利用することで、或る程度の機能の充実を図ることが可能である。
但し、例えば高音質オーディオディスクに特有で、ＣＤなどのフォーマットでは決められていないような規格に対応した機能を実現することはできないことになる。これは、例えば高音質オーディオディスクを再生可能な再生装置を含めてＡＶシステムを構築した場合に、その利便性が十分に発揮されないということにつながり得る。
このため、ＩＥＥＥ１３９４伝送フォーマット上で、例えば高音質オーディオディスク等の新規なメディアに対応した機能が必要充分となるように拡充の図られることが求められている。
【００１２】
【課題を解決するための手段】
そこで本発明は上記した課題を考慮して、再生装置について次のように構成する。
つまり、第１の記録方式で単層にデータが記録された第１のディスク状記録媒体と、上記第１の記録方式とは異なる第２の記録方式で単層にデータが記録された第２のディスク状記録媒体と、上記第１の記録方式で第１の記録層にデータが記録されるとともに上記第２の記録方式で上記第１の記録層とは異なる第２の記録層にデータが記録され上記第１の記録層と上記第２の記録層とが積層された第３のディスク状記録媒体と、上記第２の記録方式でデータが記録された第１の記録層と上記第２の記録方式でデータが記録された第２の記録層とが積層された第４のディスク状記録媒体とのうちの装着された１のディスクを再生する再生手段と、上記再生手段によってディスク状記録媒体の所定領域から読み出されるデータに基づいてディスク状記録媒体の種別を判別する種別判別手段と、上記種別判別手段にて上記第４のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合には、各層に記録された管理情報を取得し、上記種別判別手段にて上記第３のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合に、記録フォーマットが異なる各々の記録方式で記録される管理情報の各記録層における記録位置ごとに複数の記録情報が記録される記録媒体に対して再生を行うことで、少なくとも、記録情報を管理するために上記各記録情報内に設けられる管理情報を取得することのできる情報取得手段と、上記情報取得手段により取得された上記各記録情報内の管理情報に基づいて所定の伝送フォーマットに対応した記述情報を作成するのに、上記第３のディスク状記録媒体の場合には１つの記述情報の構造内において、上記複数の記録情報ごとの記述内容がそれぞれ異なる記録媒体として定義された情報単位として管理されるように記述を行い、上記第４のディスク状記録媒体の場合には上記積層された記録層を単一のディスク状記録媒体として管理されるように記述情報の記述を行う記述情報作成手段とを備えることとした。
【００１３】
また、情報伝送方法として次のように構成する。
第１の記録方式で単層にデータが記録された第１のディスク状記録媒体と、上記第１の記録方式とは異なる第２の記録方式で単層にデータが記録された第２のディスク状記録媒体と、上記第１の記録方式で第１の記録層にデータが記録されるとともに上記第２の記録方式で上記第１の記録層とは異なる第２の記録層にデータが記録され上記第１の記録層と上記第２の記録層とが積層された第３のディスク状記録媒体と、上記第２の記録方式でデータが記録された第１の記録層と上記第２の記録方式でデータが記録された第２の記録層とが積層された第４のディスク状記録媒体とのうちの装着された１のディスクを再生する再生ステップと、上記再生手順によってディスク状記録媒体の所定領域から読み出されるデータに基づいてディスク状記録媒体の種別を判別する種別判別ステップと、上記種別判別ステップにて上記第４のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合には、各層に記録された管理情報を取得し、上記種別判別手順にて上記第３のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合に、記録フォーマットが異なる各々の記録方式で記録される管理情報の各記録層における記録位置ごとに複数の記録情報が記録される記録媒体に対して再生を行うことで、少なくとも、記録情報を管理するために上記各記録情報内に設けられる管理情報を取得する情報取得ステップと、上記情報取得ステップにより取得された上記各記録情報内の管理情報に基づいて所定の伝送フォーマットに対応した記述情報を作成するのに、上記第３のディスク状記録媒体の場合には１つの記述情報の構造内において、上記複数の記録情報ごとの記述内容がそれぞれ異なる記録媒体として定義された情報単位として管理されるように記述を行い、上記第４のディスク状記録媒体の場合には上記積層された記録層を単一のディスク状記録媒体として管理されるように記述情報の記述を行う記述情報作成ステップと、要求に応じて、上記所定の伝送フォーマットに従って、上記記述情報を送信出力することのできる送信ステップとを実行するように構成することとした。
【００１４】
上記各構成によれば、記録フォーマットが異なる複数の記録情報が記録される記録媒体に対応しては、この記録情報ごとの記述内容は、それぞれ異なる記録媒体として定義された情報単位として１つの記述情報構造内で管理される。
例えば記述情報の規格として、記録フォーマットを記録媒体のタイプとして扱っている場合であっても、上記のようにして、記録フォーマットの異なる記録情報を、異なる記録媒体として定義された情報単位として扱って管理することで、１つの記述情報の構造で、複数の異なる記録フォーマットの記録情報が記録された記録媒体を表現することが可能になる。
【００１５】
【発明の実施の形態】
以下、本発明の実施の形態の再生装置を以下の順序で説明する。なおこの再生装置は、光ディスクとしての記録媒体に対応するものとする。
なお、以降の説明は次の順序で行う。
１．ディスク種別
２．ディスクのゾーン構造
３．ＡＶシステム
３−１．システム例
３−２．ディスクプレーヤ
３−３．パーソナルコンピュータ
４．ＩＥＥＥ１３９４データインターフェイス
４−１．概要
４−２．スタックモデル
４−３．信号伝送形態
４−４．機器間のバス接続
４−５．パケット
４−６．トランザクションルール
４−７．アドレッシング
４−８．ＣＩＰ(Common Isochronous Packet)
４−９．コネクションマネージメント
４−１０．ＦＣＰにおけるコマンド及びレスポンス
４−１１．ＡＶ／Ｃコマンドパケット
４−１２．プラグ
４−１３．Asynchronous Connection送信手順
５．本実施の形態のDisc Subunit Identifier Descriptor
５−１．基本概念
５−２．Subunit Identifier Descriptor
５−３．Object List Descriptor
５−４．Object Entry
５−５．Disc Subunit Object
５−６．Disc Subunit Object entry_specific_information
５−７．Audio Track Object entry_specific_information
５−８．Disc Subunit List List_specific_information
５−９．Root Contents List
５−１０．Root Contents List List_specific_information
５−１１．information block
５−１２．Ｒｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄ
５−１３．ＳＡＣＤ type
５−１４．ＳＡＣＤ type／Root Contents List List_specific_information
５−１５．ＳＡＣＤ type／Audio Track Object entry_specific_information
５−１６．ＳＡＣＤ typeのDisc Subunit Identifier Descriptor
５−１７．ハイブリッドディスクのDisc Subunit Identifier Descriptor
６．Disc Subunit Identifier Descriptor作成処理
７．Disc Subunit Identifier Descriptorの送信処理
【００１６】
１．ディスク種別
本例の再生装置では後述する４種類のディスクに対応するものとするが、まずディスク種別としては記録層の数により大別して単層ディスク（シングルレイヤーディスク）と複層ディスク（マルチレイヤーディスク）があり、これについて図１で説明する。
【００１７】
図１（ａ）は記録データによるピットが形成される記録層Ｌが１つ形成される単層ディスクであり、記録層Ｌに対して上面及び下面が透過サブストレートＴＳとされている。このシングルレイヤディスクは、例えば従来より知られているＣＤ−ＤＡやＤＶＤのシングルレイヤディスクに相当する。
また図１（ｂ）は記録データによるピットが形成される記録層が第１記録層Ｌ１と第２記録層Ｌ２として２つ形成される複層ディスクである。この場合、第１記録層Ｌ１と第２記録層Ｌ２は接着層Ｚを介して形成され、その第１記録層Ｌ１，第２記録層Ｌ２に対する上面及び下面が透過サブストレートＴＳとされている。
【００１８】
ディスク直径としては、単層ディスクも複層ディスクも１２ｃｍと８ｃｍのものが考えられている。
そしてディスク上は大きくわけて、内周側からリードイン、データエリア、リードアウトとよぶ３つの領域が形成されている。
リードインが開始される位置としての最大直径は45.2mmと規定され、またデータエリアが開始される位置としての最大直径は48mmと規定されている。
【００１９】
このように記録層の数として、単層ディスク、複層ディスクが存在することに加え、記録層の形成位置（ディスク厚み方向の位置）による種別も存在する。
これは具体的にはＣＤ方式におけるデータ記録層と、ＤＶＤ方式におけるデータ記録層による違いでもある。
【００２０】
なお説明上、ＣＤ方式のデータを「ＣＤデータ」といい、ＣＤデータが記録された記録層を、「ＣＤレイヤー」ということとする。
ここでいうＣＤデータとは、通常のＣＤ−ＤＡで採用されているデータ形式であって、即ち、サンプリング周波数ｆｓ＝４４．１ＫＨｚでサンプリングされた１６ビットデジタルオーディオ信号をＥＦＭ方式で変調したデータのことである。
またこのようなＣＤデータよりも高品位、即ち高音質なデータとして、ＤＶＤ方式に準拠した形でのオーディオデータ形式が提案されている。これはサンプリング周波数を例えば上記サンプリング周波数ｆｓ（＝４４．１ＫＨｚ）の６４倍という非常に高いサンプリング周波数である２．８４２ＭＨｚ（＝６４ｆｓ）でΣΔ変調された１ビットデジタルオーディオ信号を記録するものである。このようなデータを「ＨＤ（Hi-Definition）データ」ということとし、またＨＤデータが記録された記録層を「ＨＤレイヤー」と呼ぶこととする。
【００２１】
ここでＣＤデータとＨＤデータの差異を簡単に説明する。
周波数帯域としてはＣＤデータは５〜２０ＫＨｚを実現し、ＨＤデータはＤＣ成分〜１００ＫＨｚの広範囲の周波数帯域が実現できる。
ダイナミックレンジは、 ＣＤデータではオーディオ帯域全体で９８（ｄＢ）を実現し、ＨＤデータはオーディオ帯域全体で１２０（ｄＢ）の周波数帯域が実現できる。
【００２２】
ＣＤレイヤーに記録されるデータの最小ピット長は０．８３μｍに対して、ＨＤレイヤーに記録されるデータの最小ピット長は０．４μｍである。
トラックピッチに関しては、ＣＤレイヤーは１．６μｍに対して、ＨＤレイヤーは０．７４μｍである。
また、読出レーザー波長としては、ＣＤレイヤーは７８０ｎｍに対して、ＨＤレイヤーは６５０ｎｍと短波長化が図られている。
更に光学ヘッドのレンズの開口率（ＮＡ）はＣＤレイヤーの０．４５に対して、ＨＤレイヤーは０．６とされる。
このように、最小ピット長、トラックピッチ、レンズ開口率ＮＡ、レーザー波長を変化させることで、ＣＤレイヤーのデータ容量は７８０ＭＢに対してＨＤレイヤーのデータ容量は４．７ＧＢとはるかに大きいデータ容量が記録できる。
【００２３】
このようなＣＤデータ又はＨＤデータが記録されるとともに、層構造として単層、複層の別が存在する、本例の再生装置において再生可能な４種類のディスクとは、「ＣＤ−ＤＡ」「単層ＨＤディスク」「ハイブリッドディスク」「複層ＨＤディスク」となる。
これらの各ディスクの違いを図２、図３で説明する。図２は、各種別のディスクにおいて記録層に記録されるデータ種別を、また図３は記録層の形成位置を、それぞれ模式的に示している。
【００２４】
「ＣＤ−ＤＡ」
ＣＤ−ＤＡとは、いわゆる従来より普及しているオーディオ用コンパクトディスクを指し、図２（ａ）のように単層ディスクとして記録層Ｌが形成される。そしてこの記録層Ｌは、斜線部として示すようにＣＤレイヤー１０１とされ、ＣＤデータが記録される。
このＣＤ−ＤＡの場合、図３（ａ）に示すように、記録層Ｌは、ディスク表面（図面でディスク下部となるレーザ入射面）から約１．２ｍｍの位置（つまりレーベル面に近い位置）に形成されている。
【００２５】
「単層ＨＤディスク」
単層ＨＤディスクとは、単層ディスクとしてのＤＶＤに準拠しているものである。図２（ｂ）のように単層ディスクとして記録層Ｌが形成され、この記録層Ｌは、点描部として示すようにＨＤレイヤー１０２とされる。つまりＨＤデータが記録される。
この単層ＨＤディスクの場合、図３（ｂ）に示すように、記録層Ｌは、ディスク表面（レーザ入射面）から約０．６ｍｍの位置、つまり厚み方向に概略中央となる位置に形成されている。
このような単層ＨＤディスクは、オーディオデータがＨＤデータとして記録されたメディアとなるため、ＣＤ−ＤＡに比べて高品位なオーディオ再生が可能となる。
【００２６】
「ハイブリッドディスク」
ハイブリッドディスクとは、上記ＣＤ−ＤＡと単層ＨＤディスクを物理的に張り合わせたような形態となる。
即ち図２（ｃ）のように複層ディスクとして第１記録層Ｌ１，第２記録層Ｌ２が形成される。そして第１記録層Ｌ１はＨＤレイヤー１０２とされてＨＤデータが記録され、第２記録層Ｌ２はＣＤレイヤー１０１とされてＣＤデータが記録される。
このハイブリッドディスクの場合、図３（ｂ）に示すように、第１記録層Ｌ１は、ディスク表面（レーザ入射面）から約０．６ｍｍの位置に形成され、第２記録層Ｌ２は、ディスク表面（レーザ入射面）から約１．２ｍｍの位置に形成されている。
このようなハイブリッドディスクにおいては、記録する音楽等のデータ内容（プログラム）としては、例えば各レイヤーで同一の内容（例えば同一の曲）とする。つまり同一内容の音楽等のデータを、ＣＤレベルの通常品質のデータ（ＣＤデータ）としてＣＤレイヤー１０１に記録し、より高品質なデータ（ＨＤデータ）としてＨＤレイヤー１０２に記録することが考えられる。このようにすると、現在で普及しているＣＤプレーヤーではＣＤレイヤー１０１の再生が可能であるため、ＣＤデータの再生を楽しむことができ、また更にＣＤプレーヤ等においてＨＤデータに対応するデコーダや、短波長レーザを出力可能な光学ヘッド等を備えれば、ＨＤレイヤーに記録された高品位な音楽等も再生できる。
つまり、ハイブリッドディスクは、一般に多数所有されているＣＤプレーヤでも、またＨＤデータ対応の機器でも再生できるメディアとすることができる。
【００２７】
「複層ＨＤディスク」
複層ＨＤディスクとは、単層ＨＤディスクを物理的に張り合わせた形態となる。即ち図２（ｄ）のように複層ディスクとして第１記録層Ｌ１、第２記録層Ｌ２が形成され、この両記録層Ｌ１、Ｌ２は、いづれもＨＤレイヤー１０２とされる。つまりＨＤデータが記録される。
この複層ＨＤディスクの場合、図３（ｄ）に示すように、記録層Ｌ１、Ｌ２はいずれも、ディスク表面（レーザ入射面）から約０．６ｍｍの位置、つまり厚み方向に概略中央となる位置に形成されている。
このような複層ＨＤディスクは、オーディオデータがＨＤデータとして記録されたメディアとなるため、ＣＤ−ＤＡに比べて高品位なオーディオ再生が可能となるとともに、上記単層ＨＤディスクの２倍の記録容量を実現できる。
【００２８】
２．ディスクのゾーン構造
続いて、上記したハイブリッドディスクを例に挙げて、ＣＤレイヤー１０１及びＨＤレイヤー１０２の各ゾーン構造について、図４を参照して説明する。
【００２９】
図４（ａ）に示すＣＤレイヤー１０１の構造と、図４（ｂ）に示すＨＤレイヤー１０２の構造から分かるように、ＣＤレイヤー１０１及びＨＤレイヤー１０２は共に、ディスク内周側から外周側に向かって、リードインゾーン（Lead-in Zone）、データゾーン（Data Zone）、リードアウトゾーン（Lead-out Zone）が形成される。
【００３０】
ＣＤレイヤー１０１の構造は、従来からのＣＤのゾーン構造と同一であるとされる。つまり、リードインゾーンの所定位置にＴＯＣ(Table Of Contents)が記録されており、データゾーンに対して楽曲であるオーディオデータが記録される。なお、以降においては、ＣＤレイヤー１０１に記録されるＴＯＣは、ＣＤ−ＴＯＣと表記して、次に述べるＨＤレイヤー１０２の各ＴＯＣと区別する。
【００３１】
また、ＨＤレイヤー１０２の構造を図５に示す。
図５（ａ）に示されるＨＤレイヤー１０２には、図４（ｂ）に示したと同じ内容のゾーン構造が示される。そして、このゾーン構造内にあって、データゾーン（Data Zone）は、図５（ｂ）に示すように、その内周側から、ＵＤＦファイルシステム（File System）エリア、マスターＴＯＣ（Master TOC)エリア、オーディオエリア（Audio Area）、及びエクストラデータエリア（Extra Data Area）に分割される。
ＵＤＦファイルシステム（File System）エリアには、このＨＤレイヤー１０２に記録されるデータを管理するファイルシステムが格納される。
【００３２】
マスターＴＯＣ（Master TOC)エリアには、図５（ｃ）に示すようにして、アルバム情報とディスク情報とが格納される。
ここでいう「アルバム」とは、例えば２枚組、３枚組などのようにして販売されるような、複数枚のセットで１組とされるものをいう。そして、アルバム情報とはこのアルバムに関連する情報とされる。
このアルバム情報は、図５（ｃ）の上段に示されるように、アルバムを成すディスク枚数、アルバムを成すディスクごとに付される通し番号であるアルバム識別番号、及び、アルバム単位でのジャンル、アルバム単位でのタイトル、及びアルバム単位でのアーティスト名等の情報を備える。
【００３３】
また、ディスク情報とは、このＨＤレイヤー１０２を１枚のディスクとして扱った場合の、このディスクに関連する情報とされ、図５（ｃ）の下段に示すようにして、ディスク種類、ディスク制作日、ディスク識別番号、ディスク単位でのジャンル、ディスク単位でのタイトル、ディスク単位でのアーティスト、ディスクの制作者などの情報を備えるものである。
【００３４】
また、オーディオエリア（Audio Area）は、大別して、２チャンネルステレオによるＨＤデータを記録する２チャンネルステレオエリア（2-channel Streo Area）と、これに続けて、例えば２チャンネルよりも多いマルチチャンネルによるＨＤデータを記録するマルチチャンネルエリア（Multichannel Area）とに分割される。
【００３５】
これら２チャンネルステレオエリアとマルチチャンネルエリアの各々においては、図示していないが、オーディオトラックといわれる、トラック単位で管理されるオーディオデータがトラックナンバ順に記録されるエリアが形成される。そして、前後からこのオーディオトラックを挟むようにして、２つのエリアＴＯＣ（Area TOC-1,Area TOC-2）が配置される。
【００３６】
これらエリアＴＯＣ（Area TOC-1,Area TOC-2）は、それぞれが配置されている各チャンネルエリアのオーディオデータをトラック単位で管理するためのデータ構造を有している。つまり、２チャンネルステレオエリアのＡｒｅａ ＴＯＣ−１，Ａｒｅａ ＴＯＣ−２は、２チャンネルステレオエリアに記録されたオーディオデータをトラック単位で管理する情報を有し、マルチチャンネルエリアのエリアＴＯＣ（Area TOC-1,Area TOC-2）は、マルチチャンネルエリアに記録されたオーディオデータをトラック単位で管理する情報を有する。
また、エリアＴＯＣ（Area TOC-1,Area TOC-2）では、各トラックのタイトル、アーティスト、作曲者、作詞者、ジャンル、編曲者、メッセージ、国際著作権コード（ＩＳＲＣ）などの情報も格納することができるようになっている。
特に、マルチチャンネルエリアのエリアＴＯＣ（Area TOC-1,Area TOC-2）には、マルチチャンネルステレオとしてのオーディオ再生のスピーカレイアウトを指定するスピーカレイアウト情報が格納される。
マルチチャンネルエリアに記録されるデータは、そのフォーマットによっても異なるが、例えば３以上のスピーカを所定の配置形態によりレイアウトして再生音声を出力させることで、その音響効果が発揮されるようになっている。このため、上記のようにして、スピーカレイアウト情報を格納しておくことで、例えば各オーディオトラックごとに適切とされるスピーカレイアウトを指示することが可能になる。
【００３７】
また、エクストラデータエリア（Extra Data Area）は、例えばオーディオデータ以外の、テキスト、画像データなどを記録するために割り当てられた領域とされる。
【００３８】
なお、例えば図２（ｂ）に示した単層ディスクであれば、上記図５に示した構造のＨＤレイヤー１０２が１つの記録層Ｌとして形成されていることになる。
また、図２（ｄ）に示した複層ディスクであれば、第１記録層Ｌ１と第２記録層Ｌ２の各々が、図５に示した構造を有しているものとされる。
【００３９】
３．ＡＶシステム
３−１．システム例
図６は、ＩＥＥＥ１３９４デジタルデータインターフェイスにより接続される本実施の形態としてのＡＶシステムの構成例を示している。
【００４０】
図６に示すＡＶシステムとしては、ディスクプレーヤ０とパーソナルコンピュータ２００とをＩＥＥＥ１３９４データインターフェイス対応のケーブル６０１により接続することで構成される。これにより、ディスクプレーヤ０とパーソナルコンピュータ２００は、ＩＥＥＥ１３９４バス１１６によって相互通信可能となる。
【００４１】
ディスクプレーヤ０は、先に図２に示した各ディスクに対応して再生可能に構成されたオーディオ機器であり、ＩＥＥＥ１３９４バス１１６を介して再生したオーディオデータを出力することも可能とされている。
【００４２】
この場合、パーソナルコンピュータ２００は、ディスクプレーヤ０からの再生オーディオデータをＩＥＥＥ１３９４バス１１６を介して入力して、音声出力を行ったり、また、編集処理等を行うことができる。また、ディスクプレーヤ０に対して、再生に関する操作制御を行うことができる。つまり、リモート制御を実行できる。
上記したような機能は、パーソナルコンピュータ２００に対して、例えばこのような機能を実現するためのアプリケーションソフトウェアをインストールすることで得られるものである。
なお、本実施の形態が対応するＡＶシステムとしては、他にも考えられ、例えばＭＤに対応して記録再生が可能なＭＤレコーダ／プレーヤなども接続されてよいのであるが、ここでは、必要最小限の機器のみによって構成される例のみに限定して示している。
【００４３】
３−２．ディスクプレーヤ
次に上記図６に示したディスクプレーヤ０の内部構成を図７に示す。
この図において装填されている光ディスク１は、図２に示した４種類のうちのいずれかのディスクとされる。
この光ディスク１は、図示しないターンテーブルに載置され、スピンドルモータ２によってＣＬＶ（線速度一定：constant liner velocity）又はＣＡＶ（角速度一定：constant angler velocity）に回転制御される。
【００４４】
この再生装置では、４種類のディスクに対応するために、ＣＤレイヤー１０１とＨＤレイヤー１０２の両方についての再生機能を備える必要があるため、図７に示す光学ヘッド３、ＲＦアンプ４、エラー訂正／デコーダ回路７としては、ＣＤデータ再生系とＨＤデータ再生系の２系等を備えるものとなり、この２系統の構成は図８に示している。
【００４５】
図７に示す光学ヘッド３は、対物レンズ、２軸機構、半導体レーザ、及び上記半導体レーザの出射光及び光ディスク１からの反射の経路となる光学系、反射光を受光するディテクタを有して構成されている。
具体的には図８に示すように、光学ヘッド３としてはＣＤ用ヘッド部３ＡとＨＤ用ヘッド部３Ｂが形成され、それぞれ図示するように対物レンズ１５Ａ、１５Ｂ、２軸機構１６Ａ、１６Ｂ、半導体レーザ１７Ａ、１７Ｂ、ディテクタ１８Ａ、１８Ｂ、光学系１９Ａ、１９Ｂが形成される。
【００４６】
そして上記ターンテーブルに載置されている光ディスクがＣＤ−ＤＡである場合、もしくはハイブリッドディスクのＣＤレイヤ１０１を再生する場合は、ＣＤ用ヘッド部３Ａが用いられる。即ち半導体レーザ１７Ａは７８０nmの波長のレーザ出力を行うものとされ、また対物レンズ１５Ａの開口率は０．４５とされている。
一方、上記ターンテーブルに載置されている光ディスクが単層ＨＤディスク又は複層ＨＤディスクである場合、もしくはハイブリッドディスクのＨＤレイヤー１０２を再生する場合は、ＨＤ用ヘッド部３Ｂが用いられる。即ち半導体レーザ１７Ｂは６５０nmの波長のレーザ出力を行うものとされ、また対物レンズ１５Ｂの開口率は０．６とされている。
【００４７】
このようにＣＤ用ヘッド部３ＡもしくはＨＤ用ヘッド部３Ｂによるレーザ照射が、スピンドルモータ２によって回転されている光ディスク１に対して実行され、その反射光がディテクタ３Ａ又は３Ｂによって受光される。
【００４８】
なお、ホログラム一体型非球面レンズを用いれば、上述したような光学ヘッド３内部に２つの対物レンズ（１５Ａ、１５Ｂ）を設ける必要が無く、１つのレンズで半導体レーザの光路を切換えるのみで構成でき、そのような光学ヘッドを用いてもよい。つまりその場合は半導体レーザのみを短波長用と長波長用の２つ設けるようにし、光学系、対物レンズ、ディテクタ等は共用できる。
また、光学系やディテクタは共用するが、半導体レーザと対物レンズについてはＣＤ用とＨＤ用にそれぞれ用意するような光学ヘッド３の構成も可能である。
【００４９】
対物レンズ１５Ａ、１５Ｂをそれぞれ支持する２軸機構１６Ａ、１６Ｂには、対物レンズ１５Ａ、１５Ｂを光ディスク１に接離する方向に駆動するフォーカス用コイルと、対物レンズ１５Ａ、１５Ｂを光ディスク１の半径方向に駆動するトラッキング用コイルとが形成されている。
また、この再生装置には、光学ヘッド３全体を光ディスク１の半径方向に大きく移動させるスレッド機構１４を更に備えている。
【００５０】
光学ヘッド３内のディテクタ（１８Ａ又は１８Ｂ）にて検知した反射光は反射光量に応じた電流信号とされてＲＦアンプ４に供給され、このＲＦアンプ４での電流電圧変換、マトリクス演算処理により、フォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥが生成されるとともに再生情報（和信号）としてのＲＦ信号、同じく和信号であるＰＩ（プルイン）信号が生成される。
図８のようにディテクタ１８Ａ、１８Ｂが独立系統として形成される場合は、ＲＦアンプ４内には、ＣＤ用ＲＦ部４Ａ、ＨＤ用ＲＦ部４Ｂが形成され、それぞれフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥ、ＲＦ信号、ＰＩ信号が生成されるようになされる。
なお、両系統でディテクタが共用される場合や、或いはディテクタ１８Ａ、１８Ｂの出力が選択的に切り換えられてＲＦアンプ４に供給されるような構成を取った場合は、ＣＤ用ＲＦ部、ＨＤ用ＲＦ部を独立して設ける必要はない。
【００５１】
ＲＦアンプ４で生成されたフォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥはサーボ回路５にて位相補償、利得調整をされたのちに駆動回路６に供給され、フォーカスドライブ信号、トラッキングドライブ信号として上述したフォーカス用コイルと、トラッキング用コイルとに印加される。
さらに上記トラッキングエラー信号ＴＥをサーボ回路５内にてＬＰＦ（low pass filter）を介してスレッドエラー信号を生成して、駆動回路６からスレッドドライブ信号としてスレッド機構１４に印加される。
これによりいわゆるフォーカスサーボ制御、トラッキングサーボ制御、スレッドサーボ制御が実行される。
【００５２】
またサーボ回路５はシステムコントローラ１１からの指示に基づいて、フォーカスサーチ動作、トラックジャンプ動作のための信号を駆動回路６に供給し、それに応じた、フォーカスドライブ信号、トラッキングドライブ信号、スレッドドライブ信号を発生させて、光学ヘッド３のフォーカスサーチやトラックジャンプ及びアクセス等を実行させる。
【００５３】
フォーカスサーチとは、フォーカスサーボ引込のために対物レンズ１５（１５Ａ、１５Ｂ）をディスク１から最も遠い位置と最も近い位置の間を強制的に移動させながらいわゆるＳ字カーブを検出する動作である。既に知られているようにフォーカスエラー信号ＦＥとしては、対物レンズ１５がディスク１の記録層に対して合焦点位置となるポイントの前後の狭い区間においてＳ字カーブが観測されるものとなり、そのＳ字カーブのリニア領域でフォーカスサーボをオンとすることで、フォーカスサーボ引込が可能となる。このようなフォーカスサーボ引込のために、フォーカスサーチが行われるものであり、このためのフォーカスドライブ信号がフォーカス用コイルに印加され、対物レンズ１５の移動が行われる。
【００５４】
またトラックジャンプやアクセスの場合には、２軸機構１６（１６Ａ、１６Ｂ）による対物レンズ１５のディスク半径方向への移動や、スレッド機構１４による光学ヘッド３のディスク半径方向への移動が行われるが、このためのドライブ信号がトラッキングドライブ信号、スレッドドライブ信号としてトラッキング用コイルやスレッド機構１４に印加されることになる。
【００５５】
ＲＦアンプ４にて生成されたＲＦ信号は、載置されている光ディスク１がＣＤ−ＤＡの場合、もしくはハイブリッドディスクのＣＤレイヤー１０１を再生している場合は、エラー訂正及びデコーダ回路７において、２値化してＥＦＭ復調(eight to fourteen demodulation )を行うとともにＣＩＲＣ（cross interleave read solomon coding）によるエラー訂正処理を行った後にメモリコントローラー８に入力される。
一方、上記ターンテーブルに載置されている光ディスク１が単層ＨＤディスク又は複層ＨＤディスクである場合、もしくはハイブリッドディスクのＨＤレイヤ１０２を再生している場合は、エラー訂正及びデコーダ回路７において２値化してＥＦＭ-Ｐｌｕｓ復調(eight to fourteen demodulation Plus)を行うとともに積符号(product code)に基づくエラー訂正処理が行なわれ、メモリコントローラ８に供給される。
即ち機能的に見れば、図８のようにエラー訂正及びデコーダ回路７においてはＣＤ用デコード部７ＡとＨＤ用デコード部７Ｂが形成される。
なおＣＤ用デコード部７ＡとＨＤ用デコード部７Ｂはハードウエア的に独立した回路部としてもよいし、ハードウエア的には共用される回路部とすることもできる。
【００５６】
またエラー訂正及びデコーダー回路７では２値化したＥＦＭ信号もしくはＥＦＭプラス信号の基準クロックとの比較により速度エラー信号及び位相エラー信号を生成して駆動回路６に供給することで、光ディスク１をスピンドルモーター２により所定ＣＬＶ速度（又はＣＡＶ速度）で回転させる。
更にエラー訂正及びデコーダー回路７では２値化したＥＦＭ信号又はＥＦＭプラス信号に基づいてＰＬＬ（Phase Locked loop）の引き込み動作を制御し、デコード処理等に用いる再生クロックを得る。
【００５７】
エラー訂正後の２値化データは、メモリコントローラ８を介して所定の転送レートでバッファメモリ９に書き込まれる。
バッファメモリ９に所定量以上のデータが蓄積されたらバッファメモリ９から書き込みの転送レートより十分遅い第２の転送レートにて読み出しを行う。
このようにバッファメモリ９に一旦データを蓄えてからオーディオデータとして出力するようにしたので、例えば振動等の外乱によってトラックジャンプが生じて光学ヘッド３からの連続したデータ読み出しが途絶えたとしても、光学ヘッド３のトラックジャンプが発生したアドレスへの再配置に要する時間に相当するデータは予めバッファメモリ９に蓄積されているのでオーディオ出力としては連続したものを得ることができる。
【００５８】
尚、メモリコントローラ８はシステムコントローラ１１によって制御されている。
メモリコントローラー８によってバッファメモリ９から読み出されたデジタルデータはＤ／Ａコンバーター１０にてアナログオーディオ信号に変換される。そして、例えばＣＤレイヤーに記録されたオーディオデータ、又は、ＨＤレイヤーの２チャンネルステレオエリアに記録されたオーディオデータであれば、右チャンネル出力、左チャンネル出力として出力される。また、ＨＤレイヤーのマルチチャンネルエリアに記録されたオーディオデータであれば、そのマルチチャンネル数によって出力させることができる。
【００５９】
またこの再生装置では、ＨＤ用ヘッド部３Ｂ内のディテクタ１８Ｂ（ＣＤ用と共用される場合はそのディテクタ）からの反射光情報に基づいてＲＦアンプ４で得られる信号（ＰＩ信号、フォーカスエラー信号ＦＥ、トラッキングエラー信号ＴＥ）のいずれかが判別信号生成部２０に供給される。
判別信号生成部２０では、入力された信号に基づいて所定の検出動作を行うことで、図２に示したディスクのうち、実際に装填されているディスクの種別に対応するパターンの検出信号を出力する。システムコントローラ１１では、この検出信号に基づいて、ディスク１の種別判別を実行する。
なお、ここでのディスク種別判別のための詳細については、省略するが、一例として、さきに本出願により出願された特願平１１−２４７３４６に記載される技術を適用することができる。
【００６０】
システムコントローラ１１は全体を制御する部位としてマイクロコンピュータにより形成される。
システムコントローラ１１は内部ＲＯＭ１１に保持する動作プログラムやユーザーの操作に応じて再生動作のための所要の制御を行うことになる。
例えば操作部１２としての各種の操作キーの操作に応じて各種サーボ用のコマンドをサーボ回路５に転送したり、メモリコントローラ８に対してバッファメモリ９の制御の指令を与えること、エラー訂正・デコーダー回路７でのスピンドルサーボ制御やデコーダ制御を行うことなどで必要な再生動作を実行させる。
また、再生等の動作に応じて表示部１３の表示制御を行う。例えば演奏経過時間や再生しているプログラムのタイトル等の文字情報の表示を表示部１３に表示するように制御を行なう。
また、システムコントローラ１１が処理を実行する過程において必要とされる各種情報はＲＡＭ１１ａに書き込まれて保持される。
【００６１】
また、本実施の形態においては、ＩＥＥＥ１３９４インターフェイス部１４を備えることで、ＩＥＥＥ１３９４バス１１６を介して接続された機器と相互通信を行うことが可能とされる。
これにより、例えば図６に示したシステムの場合を例に挙げれば、例えばパーソナルコンピュータ２００により、ディスクプレーヤ０をリモート制御することが可能となる。つまり、パーソナルコンピュータ２００から或る操作を指示するコマンドが送信されてくると、ディスクプレーヤ０のシステムコントローラ１１はこのコマンドをＩＥＥＥ１３９４インターフェイス部１４を介して受信する。そして、受信したコマンドの内容に応じて、内部の所要の機能回路部に対する制御を実行する。これにより、例えばディスク再生を始めとする各種コントロールを、リモート制御によって行うことができる。
【００６２】
また、例えば光ディスク１にて再生されたデジタルオーディオデータをＩＥＥＥ１３９４バス１１６を介して送信出力することも可能とされる。
例えば、システムコントローラ１１は、バッファメモリ９に蓄積されていデジタルオーディオデータを所定タイミングで読み出して、ＩＥＥＥ１３９４インターフェイス部１４に伝送する。ＩＥＥＥ１３９４インターフェイス部１４では、伝送されてきたデジタルオーディオデータを、例えばパケット化などのＩＥＥＥ１３９４デジタルインターフェイスのフォーマットに従った形式に変換し、ＩＥＥＥ１３９４バス１１６を介して送信出力する。
【００６３】
３−３．パーソナルコンピュータ
続いて、パーソナルコンピュータ２００の内部構成について図９を参照して説明する。
この図に示すパーソナルコンピュータ２００は、外部とデータの授受を行うためのインターフェイスとしてＩＥＥＥ１３９４インターフェイス２０９を備えている。ＩＥＥＥ１３９４インターフェイス２０９は、外部データバスとしてのＩＥＥＥ１３９４バス１１６と接続されることで外部機器と相互通信が可能とされる。
ＩＥＥＥ１３９４インターフェイス２０９は、ＩＥＥＥ１３９４バス１１６を介して受信したパケットを復調し、復調したパケットに含まれるデータを抽出し、この抽出データを内部データ通信に適合するデータフォーマットにより変換を行って、内部バス２１０を介してＣＰＵ２０１に出力する。
また、ＣＰＵ２０１の制御によって出力されたデータを入力し、パケット化等のＩＥＥＥ１３９４フォーマットに従った変調処理を施して、ＩＥＥＥ１３９４バス１１６を介して外部に送信出力する。
【００６４】
ＣＰＵ２０１は、例えばＲＯＭ２０２に保持されているプログラムに従って各種の処理を実行する。本実施の形態では、ＩＥＥＥ１３９４の規格に従って各種データの送受信を可能とするために、上記ＲＯＭ２０２に対してＩＥＥＥ１３９４インターフェイス２０９を制御するためのプログラムも格納されることになる。つまり、パーソナルコンピュータ１１３においては、ＩＥＥＥ１３９４によるデータ送受信に可能なセット（ハードウェア及びソフトウェア）が備えられるものである。
また、ＲＡＭ２０３にはＣＰＵ２０１が各種処理を実行するのに必要なデータやプログラム等が適宜保持される。
【００６５】
入出カインターフェイス２０４は、キーボード２０５とマウス２０６が接続されており、これらから供給された操作信号をＣＰＵ２０１に出カするようにされている。また、入出カインターフェイス２０４には、記憶媒体としてハードディスクを備えたハードディスクドライブ２０７が接続されている。ＣＰＵ２０１は、入出カインターフェイス２０４を介して、ハードディスクドライブ２０７のハードディスクに対してデータやプログラム等の記録又は読み出しを行うことができるようにされている。この場合、入出カインターフェイス２０４には、さらに、画像表示のためのディスプレイモニタ２０８が接続されている。
内部バス２１０は、例えば、ＰＣＩ(Peripheral Component Interconnect)又はローカルバス等により構成され、内部における各機能回路部間を相互に接続している。
【００６６】
なお、前述したディスクプレーヤ０としても、ＩＥＥＥ１３９４インターフェイス機能については、上記したパーソナルコンピュータ１１３と基本的には同様の構成を採る。システムコントローラ１１内に備えられるとされるＲＯＭ１１ｂに対して、システムコントローラ１１１によるＩＥＥＥ１３９４インターフェイス１１０の制御を可能とするためのプログラムが搭載される。
【００６７】
４．ＩＥＥＥ１３９４データインターフェイス
４−１．概要
続いて、本実施の形態において採用されるＩＥＥＥ１３９４データインターフェイスについて説明する。
【００６８】
ＩＥＥＥ１３９４は、シリアルデータ通信の規格の１つとされる。
このＩＥＥＥ１３９４によるデータ伝送方式としては、周期的に通信を行うＩｓｏｃｈｒｏｎｏｕｓ通信方式と、この周期と関係なく非同期で通信するＡｓｙｎｃｈｒｏｎｏｕｓ通信方式が存在する。一般に、Ｉｓｏｃｈｒｏｎｏｕｓ通信方式はデータの送受信に用いられ、Ａｓｙｎｃｈｒｏｎｏｕｓ通信方式は各種制御コマンドの送受信に用いられる。そして、１本のケーブルを使用して、これら２種類の通信方式によって送受信を行うことが出来るようにされている。
また、このようなＩｓｏｃｈｒｏｎｏｕｓ通信方式とＡｓｙｎｃｈｒｏｎｏｕｓ通信方式の使い分け方として、或るメディアに、ＡＶデータ（オーディオデータ、ビデオデータ等）などの時系列的なデータと、静止画やテキストなどの時系列性を有さないとされる補助データが記録されているようなフォーマットを有する場合、ＡＶデータをＩｓｏｃｈｒｏｎｏｕｓ通信により送信し、補助データはＡｓｙｎｃｈｒｏｎｏｕｓ通信方式により送信するという構成を、先に本出願人が提案している。この実施の形態においても、上記した提案の構成に従い、ディスクプレーヤ０にて再生されたオーディオデータに関しては、Ｉｓｏｃｈｒｏｎｏｕｓ通信方式により送信出力を行うものとする。
そこで以降、上記したＩＥＥＥ１３９４規格による本実施の形態の送信形態を前提として、本実施の形態としての説明を行っていくこととする。
【００６９】
４−２．スタックモデル
図１０は、本実施の形態が対応するＩＥＥＥ１３９４のスタックモデルを示している。
ＩＥＥＥ１３９４フォーマットにおいては、Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）とＩｓｏｃｈｒｏｎｏｕｓ系（５００）とに大別される。
ここで、Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）とＩｓｏｃｈｒｏｎｏｕｓ系（５００）に共通な層として、最下位にＰｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）（物理層）が設けられ、その上位にＬｉｎｋ Ｌａｙｅｒ（３０２）（リンク層）が設けられる。Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）はハードウェア的な信号伝送を司るためのレイヤであり、Ｌｉｎｋ Ｌａｙｅｒ（３０２）はＩＥＥＥ１３９４バスを例えば、機器毎に規定された内部バスに変換するための機能を有する層とされる。
【００７０】
Ｐｈｙｓｉｃａｌ Ｌａｙｅｒ（３０１）、Ｌｉｎｋ Ｌａｙｅｒ（３０２）、及び次に説明するＴｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）は、Ｅｖｅｎｔ／Ｃｏｎｔｒｏｌ／ＣｏｎｆｉｇｕｒａｔｉｏｎのラインによってＳｅｒｉａｌ Ｂｕｓ Ｍａｎａｇｅｍｅｎｔ３０３とリンクされる。
また、ＡＶ Ｃａｂｌｅ／Ｃｏｎｎｅｃｔｏｒ３０４は、ＡＶデータ伝送のための物理的なコネクタ、ケーブルを示している。
【００７１】
Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）における上記Ｌｉｎｋ Ｌａｙｅｒ（３０２）の上位には、Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）が設けられる。Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）は、ＩＥＥＥ１３９４としてのデータ伝送プロトコルを規定する層とされ、基本的なＡｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓａｃｔｉｏｎとしては、後述するようにして、Ｗｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎ，Ｒｅａｄ Ｔｒａｎｓａｃｔｉｏｎ，Ｌｏｃｋ Ｔｒａｎｓａｃｔｉｏｎが規定される。
【００７２】
そして、Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）の上層に対してＦＣＰ(Functuin Control Protocol)（４０２）が規定される。ＦＣＰ（４０２）は、ＡＶ／Ｃ Ｃｏｍｍａｎｄ(AV/C Digital Interfase Command Set)（４０３）として規定された制御コマンドを利用することで、各種ＡＶ機器に対するコマンド制御を実行することが出来るようになっている。
【００７３】
また、Ｔｒａｎｓａｃｔｉｏｎ Ｌａｙｅｒ（４０１）の上層に対しては、Ｃｏｎｎｅｃｔｉｏｎ Ｍａｎａｇｅｍｅｎｔ Ｐｒｏｃｅｄｕｒｅｓ（５０５）を利用して、後述するＰｌｕｇ（ＩＥＥＥ１３９４における論理的な機器接続関係）を設定するためのＰｌｕｇ Ｃｏｎｔｒｏｌｌ Ｒｅｇｉｓｔｅｒｓ（４０４）が規定される。
【００７４】
Ｉｓｏｃｈｒｏｎｏｕｓ系（５００）におけるＬｉｎｋ Ｌａｙｅｒ（３０２）の上位には、ＣＩＰ Ｈｅａｄｅｒ Ｆｏｒｍａｔ（５０１）が規定され、このＣＩＰ Ｈｅａｄｅｒ Ｆｏｒｍａｔ（５０１）に管理される形態で、ＳＤ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０２），ＨＤ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０３），ＳＤＬ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０４），ＭＰＥＧ２−ＴＳ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０５），Ａｕｄｉｏａｎｄ Ｍｕｓｉｃ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０６）等の伝送プロトコルが規定されている。
【００７５】
ＳＤ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０２），ＨＤ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０３），ＳＤＬ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０４）は、それぞれ、デジタルＶＴＲ(Video Tape Recorder)に対応するデータ伝送プロトコルである。
ＳＤ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０２）が扱うデータは、ＳＤ−ＤＶＣＲ ｒｅｃｏｒｄｉｎｇ ｆｏｒｍａｔ（５０８）の規定に従って得られたデータシーケンス（ＳＤ−ＤＶＣＲ ｄａｔａ ｓｅｑｕｅｎｃｅ（５０７））とされる。
また、ＨＤ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０３）が扱うデータは、ＨＤ−ＤＶＣＲ ｒｅｃｏｒｄｉｎｇ ｆｏｒｍａｔ（５１０）の規定に従って得られたデータシーケンス（ＳＤ−ＤＶＣＲ ｄａｔａ ｓｅｑｕｅｎｃｅ（５０９））とされる。
ＳＤＬ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０４）が扱うデータは、ＳＤＬ−ＤＶＣＲ ｒｅｃｏｒｄｉｎｇ ｆｏｒｍａｔ（５１２）の規定に従って得られるデータシーケンス（ＳＤ−ＤＶＣＲ ｄａｔａ ｓｅｑｕｅｎｃｅ（５１１））となる。
【００７６】
ＭＰＥＧ２−ＴＳ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０５）は、例えばデジタル衛星放送に対応するチューナ等に対応する伝送プロトコルで、これが扱うデータは、ＤＶＢ ｒｅｃｏｒｄｉｎｇ ｆｏｒｍａｔ（５１４）或いはＡＴＶ ｒｅｃｏｒｄｉｎｇ ｆｏｒｍａｔ（５１５）の規定に従って得られるデータシーケンス（ＭＰＥＧ２−ＴＳ ｄａｔａ ｓｅｑｕｅｎｃｅ（５１３））とされる。
【００７７】
また、Ａｕｄｉｏ ａｎｄ Ｍｕｓｉｃ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０６）は、例えば本実施の形態のＭＤシステムを含むデジタルオーディオ機器全般に対応する伝送プロトコルであり、これが扱うデータは、Ａｕｄｉｏ ａｎｄ Ｍｕｓｉｃ ｒｅｃｏｒｄｉｎｇ ｆｏｒｍａｔ（５１７）の規定に従って得られるデータシーケンス（Ａｕｄｉｏ ａｎｄ Ｍｕｓｉｃ ｄａｔａ ｓｅｑｕｅｎｃｅ）とされる。
【００７８】
４−３．信号伝送形態
図１１は、ＩＥＥＥ１３９４バスとして実際に用いられるケーブルの構造例を示している。
この図においては、コネクタ６００Ａと６００Ｂがケーブル６０１を介して接続されていると共に、ここでは、コネクタ６００Ａと６００Ｂのピン端子として、ピン番号１〜６の６ピンが使用される場合を示している。
コネクタ６００Ａ，６００Ｂに設けられる各ピン端子については、ピン番号１は電源（ＶＰ）、ピン番号２はグランド（ＶＧ）、ピン番号３はＴＰＢ１、ピン番号４はＴＰＢ２、ピン番号５はＴＰＡ１、ピン番号５はＴＰＡ２とされている。
そして、コネクタ６００Ａ−６００Ｂ間の各ピンの接続形態は、
ピン番号１（ＶＰ）−ピン番号１（ＶＰ）
ピン番号２（ＶＧ）−ピン番号２（ＶＧ）
ピン番号３（ＴＰＢ１）−ピン番号５（ＴＰＡ１）
ピン番号４（ＴＰＢ２）−ピン番号６（ＴＰＡ２）
ピン番号５（ＴＰＡ１）−ピン番号３（ＴＰＢ１）
ピン番号６（ＴＰＡ２）−ピン番号３（ＴＰＢ２）
のようになっている。そして、上記ピン接続の組のうち、
ピン番号３（ＴＰＢ１）−ピン番号５（ＴＰＡ１）
ピン番号４（ＴＰＢ２）−ピン番号６（ＴＰＡ２）
の２本のツイスト線の組により、差動で信号を相互伝送する信号線６０１Ａを形成し、
ピン番号５（ＴＰＡ１）−ピン番号３（ＴＰＢ１）
ピン番号６（ＴＰＡ２）−ピン番号３（ＴＰＢ２）
の２本のツイスト線の組により、差動で信号を相互伝送する信号線６０１Ｂを形成している。
【００７９】
上記２組の信号線６０１Ａ及び信号線６０１Ｂにより伝送される信号は、図１２（ａ）に示すデータ信号（Ｄａｔａ）と、図１２（ｂ）に示すストローブ信号（Ｓｔｒｏｂｅ）である。
図１２（ａ）に示すデータ信号は、信号線６０１Ａ又は信号線６０１Ｂの一方を使用してＴＰＢ１，２から出力され、ＴＰＡ１，２に入力される。
また、図１２（ｂ）に示すストローブ信号は、データ信号と、このデータ信号に同期する伝送クロックとについて所定の論理演算を行うことによって得られる信号であり、実際の伝送クロックよりは低い周波数を有する。このストローブ信号は、信号線６０１Ａ又は信号線６０１Ｂのうち、データ信号伝送に使用していない他方の信号線を使用して、ＴＰＡ１，２から出力され、ＴＰＢ１，２に入力される。
【００８０】
例えば、図１２（ａ），図１２（ｂ）に示すデータ信号及びストローブ信号が、或るＩＥＥＥ１３９４対応の機器に対して入力されたとすると、この機器においては、入力されたデータ信号とストローブ信号とについて所定の論理演算を行って、図１２（ｃ）に示すような伝送クロック（Ｃｌｏｃｋ）を生成し、所要の入力データ信号処理に利用する。
ＩＥＥＥ１３９４フォーマットでは、このようなハードウェア的データ伝送形態を採ることで、高速な周期の伝送クロックをケーブルによって機器間で伝送する必要をなくし、信号伝送の信頼性を高めるようにしている。
なお、上記説明では６ピンの仕様について説明したが、ＩＥＥＥ１３９４フォーマットでは電源（ＶＰ）とグランド（ＶＧ）を省略して、２組のツイスト線である信号線６０１Ａ及び信号線６０１Ｂのみからなる４ピンの仕様も存在する。例えば本実施の形態のディスクプレーヤ０の実際として、上記４ピン仕様のケーブルを用いれば、ユーザにとってより簡易なシステムを提供することができる。
【００８１】
４−４．機器間のバス接続
図１３は、ＩＥＥＥ１３９４バスによる機器間接続の形態例を模式的に示している。この図では、機器Ａ，Ｂ，Ｃ，Ｄ，Ｅの５台の機器（Ｎｏｄｅ）がＩＥＥＥ１３９４バス（即ちケーブルである）によって相互通信可能に接続されている場合が示されている。
ＩＥＥＥ１３９４インターフェイスでは、機器Ａ，Ｂ，ＣのようにしてＩＥＥＥ１３９４バスにより直列的に接続するいわゆる「ディージチェーン接続」が可能とされる。また、図１３の場合であれば、機器Ａと、機器Ｂ，Ｄ，Ｅ間の接続形態に示すように、或る機器と複数機器とが並列的に接続されるいわゆる「ブランチ接続」も可能とされる。
システム全体としては、このブランチ接続と上記ディージチェーン接続とを併用して最大６３台の機器（Ｎｏｄｅ）を接続可能とされる。但し、ディージチェーン接続によっては、最大で１６台（１６ポップ）までの接続が可能とされている。また、ＳＣＳＩで必要とされるターミネータはＩＥＥＥ１３９４インターフェイスでは不要である。
そしてＩＥＥＥ１３９４インターフェイスでは、上記のようにしてディージチェーン接続又はブランチ接続により接続された機器間で相互通信を行うことが可能とされている。つまり、図１３の場合であれば、機器Ａ，Ｂ，Ｃ，Ｄ，Ｅ間の任意の複数機器間での相互通信が可能とされる。
【００８２】
また、ＩＥＥＥ１３９４バスにより複数の機器接続を行ったシステム（以降はＩＥＥＥ１３９４システムともいう）内では、機器ごとに割与えられるＮｏｄｅＩＤを設定する処理が実際には行われる。この処理を、図１４により模式的に示す。
ここで、図１４（ａ）に示す接続形態によるＩＥＥＥ１３９４システムにおいて、ケーブルの抜き差し、システムにおける或る機器の電源のオン／オフ、ＰＨＹ(Physical Layer Protocol)での自発発生処理等が有ったとすると、ＩＥＥＥ１３９４システム内においてはバスリセットが発生する。これにより、各機器Ａ，Ｂ，Ｃ，Ｄ，Ｅ間においてＩＥＥＥ１３９４バスを介して全ての機器にバスリセット通知を行う処理が実行される。
【００８３】
このバスリセット通知の結果、図１４（ｂ）に示すようにして、通信（Child−Notify）を行うことで隣接する機器端子間で親子関係が定義される。つまり、ＩＥＥＥ１３９４システム内における機器間のＴｒｅｅ構造を構築する。そして、このＴｒｅｅ構造の構築結果に従って、ルートとしての機器が定義される。ルートとは、全ての端子が子(Ｃｈ；Child)として定義された機器であり、図１４（ｂ）の場合であれば、機器Ｂがルートとして定義されていることになる。逆に言えば、例えばこのルートとしての機器Ｂと接続される機器Ａの端子は親親(Ｐ；Parent)として定義されているものである。
【００８４】
上記のようにしてＩＥＥＥ１３９４システム内のＴｒｅｅ構造及びルートが定義されると、続いては、図１４（ｃ）に示すようにして、各機器から、自己のＮｏｄｅ−ＩＤの宣言としてＳｅｌｆ−ＩＤパケットが出力される。そしてルートがこのＮｏｄｅ−ＩＤに対して順次承認（grant）を行っていくことにより、ＩＥＥＥ１３９４システム内における各機器のアドレス、つまりＮｏｄｅ−ＩＤが決定される。
【００８５】
４−５．パケット
ＩＥＥＥ１３９４フォーマットでは、図１５に示すようにしてＩｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅ（ｎｏｍｉｎａｌ ｃｙｃｌｅ）の周期を繰り返すことによって送信を行う。この場合、１Ｉｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅは、１２５μｓｅｃとされ、帯域としては１００ＭＨｚに相当する。なお、Ｉｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅの周期としては１２５μｓｅｃ以外とされても良いことが規定されている。そして、このＩｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅごとに、データをパケット化して送信する。
【００８６】
この図に示すように、Ｉｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅの先頭には、１Ｉｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅの開始を示すＣｙｃｌｅ Ｓｔａｒｔ Ｐａｃｋｅｔが配置される。
このＣｙｃｌｅ Ｓｔａｒｔ Ｐａｃｋｅｔは、ここでの詳しい説明は省略するが、Ｃｙｃｌｅ Ｍａｓｔｅｒとして定義されたＩＥＥＥ１３９４システム内の特定の１機器によってその発生タイミングが指示される。
Ｃｙｃｌｅ Ｓｔａｒｔ Ｐａｃｋｅｔに続いては、ＩｓｏｃｈｒｏｎｏｕｓＰａｃｋｅｔが優先的に配置される。Ｉｓｏｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔは、図のように、チャンネルごとにパケット化されたうえで時分割的に配列されて転送される（Ｉｓｏｃｈｒｏｎｏｕｓ ｓｕｂａｃｔｉｏｎｓ）。また、Ｉｓｏｃｈｒｏｎｏｕｓ ｓｕｂａｃｔｉｏｎｓ内においてパケット毎の区切りには、Ｉｓｏｃｈｒｏｎｏｕｓ ｇａｐといわれる休止区間（例えば０．０５μｓｅｃ）が設けられる。
このように、ＩＥＥＥ１３９４システムでは、１つの伝送線路によってＩｓｏｃｈｒｏｎｏｕｓデータをマルチチャンネルで送受信することが可能とされている。
【００８７】
ここで、例えば或るメディアに対応したフォーマットのＡＶデータをＩｓｏｃｈｒｏｎｏｕｓ方式により送信することを考えた場合、このＡＶデータの１倍速の転送レートが１．４Ｍｂｐｓであるとすれば、１２５μｓｅｃである１Ｉｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅ周期ごとに、少なくともほぼ２０数ＭバイトのＡＶデータをＩｓｏｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔとして伝送すれば、時系列的な連続性（リアルタイム性）が確保されることになる。
例えば、或る機器が上記したようなＡＶデータを送信する際には、ここでの詳しい説明は省略するが、ＩＥＥＥ１３９４システム内のＩＲＭ(Isochronous Resource Manager)に対して、ＡＶデータのリアルタイム送信が確保できるだけの、Ｉｓｏｃｈｒｏｎｏｕｓ パケットのサイズを要求する。ＩＲＭでは、現在のデータ伝送状況を監視して許可／不許可を与え、許可が与えられれば、指定されたチャンネルによって、ＡＶデータをＩｓｏｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにパケット化して送信することが出来る。これがＩＥＥＥ１３９４インターフェイスにおける帯域予約といわれるものである。
【００８８】
Ｉｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅの帯域内においてＩｓｏｃｈｒｏｎｏｕｓ ｓｕｂａｃｔｉｏｎｓが使用していない残る帯域を用いて、Ａｓｙｎｃｈｒｏｎｏｕｓ ｓｕｂａｃｔｉｏｎｓ、即ちＡｓｙｎｃｈｒｏｎｏｕｓのパケット送信が行われる。
図１５では、Ｐａｃｋｅｔ Ａ，Ｐａｃｋｅｔ Ｂの２つのＡｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔが送信されている例が示されている。Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔの後には、ａｃｋ ｇａｐ（０．０５μｓｅｃ）の休止期間を挟んで、ＡＣＫ（Acknowledge)といわれる信号が付随する。ＡＣＫは、後述するようにして、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｔｒａｎｓａｃｔｉｏｎの過程において、何らかのＡｓｙｎｃｈｒｏｎｏｕｓデータの受信が有ったことを送信側（Ｃｏｎｔｒｏｌｌｅｒ）に知らせるためにハードウェア的に受信側（Ｔａｒｇｅｔ）から出力される信号である。
また、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔ及びこれに続くＡＣＫからなるデータ伝送単位の前後には、１０μｓｅｃ程度のｓｕｂａｃｔｉｏｎ ｇａｐといわれる休止期間が設けられる。
【００８９】
４−６．トランザクションルール
図１６（ａ）の処理遷移図には、Ａｓｙｎｃｈｒｏｎｏｕｓ通信における基本的な通信規則（トランザクションルール）が示されている。このトランザクションルールは、ＦＣＰによって規定される。
図１６（ａ）に示すように、先ずステップＳ１１により、Ｒｅｑｕｅｓｔｅｒ（送信側）は、Ｒｅｓｐｏｎｄｅｒ（受信側）に対してＲｅｑｕｅｓｔを送信する。Ｒｅｓｐｏｎｄｅｒでは、このＲｅｑｕｅｓｔを受信する（ステップＳ１２）と、先ずＡｃｋｎｏｗｌｅｄｇｅをＲｅｑｕｅｓｔｅｒに返送する（ステップＳ１３）。送信側では、Ａｃｋｎｏｗｌｅｄｇｅを受信することで、Ｒｅｑｕｅｓｔが受信側にて受信されたことを認知する（ステップＳ１４）。
この後、Ｒｅｓｐｏｎｄｅｒは先のステップＳ１２にて受信したＲｅｑｕｅｓｔに対する応答として、ＲｅｓｐｏｎｓｅをＲｅｑｕｅｓｔｅｒに送信する（ステップＳ１５）。Ｒｅｑｕｅｓｔｅｒでは、Ｒｅｓｐｏｎｓｅを受信し（ステップＳ１６）、これに応答してＲｅｓｐｏｎｄｅｒに対してＡｃｋｎｏｗｌｅｄｇｅを送信する（ステップＳ１７）。ＲｅｓｐｏｎｄｅｒではＡｃｋｎｏｗｌｅｄｇｅを受信することで、Ｒｅｓｐｏｎｓｅが送信側にて受信されたことを認知する。
【００９０】
上記図１６（ａ）により送信されるＲｅｑｕｅｓｔ Ｔｒａｎｓａｃｔｉｏｎとしては、図１６（ｂ）の左側に示すように、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ、Ｒｅａｄ Ｒｅｑｕｅｓｔ、Ｌｏｃｋ Ｒｅｑｕｅｓｔの３種類に大別して定義されている。
Ｗｒｉｔｅ Ｒｅｑｕｅｓｔは、データ書き込みを要求するコマンドであり、Ｒｅａｄ Ｒｅｑｕｅｓｔはデータの読み出しを要求するコマンドである。Ｌｏｃｋ Ｒｅｑｕｅｓｔはここでは詳しい説明は省略するが、ｓｗａｐ ｃｏｍｐａｒｅ、マスクなどのためのコマンドである。
【００９１】
また、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔは、後に図示して説明するＡｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔ（ＡＶ／Ｃ Ｃｏｍｍａｎｄ Ｐａｃｋｅｔ）に格納するコマンド（ｏｐｅｒａｎｄ）のデータサイズに応じてさらに３種類が定義される。Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ（ｄａｔａ ｑｕａｄｌｅｔ）は、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔのヘッダサイズのみによりコマンドを送信する。Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ（ｄａｔａ ｂｌｏｃｋ：ｄａｔａ ｌｅｎｇｔｈ＝４ｂｙｔｅ）、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ（ｄａｔａ ｂｌｏｃｋ：ｄａｔａ ｌｅｎｇｔｈ≠４ｂｙｔｅ）は、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔとしてヘッダに対してｄａｔａ ｂｌｏｃｋを付加してコマンド送信を行うもので、両者は、ｄａｔａ ｂｌｏｃｋに格納されるｏｐｅｒａｎｄのデータサイズが４バイトであるかそれ以上であるのかが異なる。
【００９２】
Ｒｅａｄ Ｒｅｑｕｅｓｔも同様にして、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔに格納するｏｐｅｒａｎｄのデータサイズに応じて、Ｒｅａｄ Ｒｅｑｕｅｓｔ（ｄａｔａ ｑｕａｄｌｅｔ）、Ｒｅａｄ Ｒｅｑｕｅｓｔ（ｄａｔａ ｂｌｏｃｋ：ｄａｔａ ｌｅｎｇｔｈ＝４ｂｙｔｅ）、Ｒｅａｄ Ｒｅｑｕｅｓｔ（ｄａｔａ ｂｌｏｃｋ：ｄａｔａ ｌｅｎｇｔｈ≠４ｂｙｔｅ）の３種類が定義されている。
【００９３】
また、Ｒｅｓｐｏｎｓｅ Ｔｒａｎｓａｃｔｉｏｎとしては、図１６（ｂ）の右側に示されている。
上述した３種のＷｒｉｔｅ Ｒｅｑｕｅｓｔに対しては、Ｗｒｉｔｅ Ｒｅｓｐｏｎｓｅ或いはＮｏ Ｒｅｓｐｏｎｓｅが定義される。
また、Ｒｅａｄ Ｒｅｑｕｅｓｔ（ｄａｔａ ｑｕａｄｌｅｔ）に対してはＲｅａｄ Ｒｅｓｐｏｎｓｅ（ｄａｔａ ｑｕａｄｌｅｔ）が定義され、ＲｅａｄＲｅｑｕｅｓｔ（ｄａｔａ ｂｌｏｃｋ：ｄａｔａ ｌｅｎｇｔｈ＝４ｂｙｔｅ）、又はＲｅａｄ Ｒｅｑｕｅｓｔ（ｄａｔａ ｂｌｏｃｋ：ｄａｔａ ｌｅｎｇｔｈ≠４ｂｙｔｅ）に対しては、Ｒｅａｄ Ｒｅｓｐｏｎｓｅ（ｄａｔａ ｂｌｏｃｋ）が定義される。
【００９４】
Ｌｏｃｋ Ｒｅｑｕｅｓｔに対しては、Ｌｏｃｋ Ｒｅｓｐｏｎｓｅが定義される。
【００９５】
４−７．アドレッシング
図１７は、ＩＥＥＥ１３９４バスのアドレッシングの構造を示している。
図１７（ａ）に示すように、ＩＥＥＥ１３９４フォーマットでは、バスアドレスのレジスタ（アドレス空間）として６４ビットが用意される。
このレジスタの上位１０ビットの領域は、ＩＥＥＥ１３９４バスを識別するためのバスＩＤを示し、図１７（ｂ）に示すようにしてバスＩＤとしてｂｕｓ＃０〜＃１０２２の計１０２３のバスＩＤを設定可能としている。ｂｕｓ＃１０２３はｌｏｃａｌ ｂｕｓとして定義されている。
【００９６】
図１７（ａ）においてバスアドレスに続く６ビットの領域は、上記バスＩＤにより示されるＩＥＥＥ１３９４バスごとに接続されている機器のＮｏｄｅ ＩＤを示す。Ｎｏｄｅ ＩＤは、図１７（ｃ）に示すようにして、Ｎｏｄｅ ＃０〜＃６２までの６３のＮｏｄｅ ＩＤを識別可能としている。
上記バスＩＤ及びＮｏｄｅ ＩＤを示す計１６ビットの領域は、後述するＡＶ／Ｃ Ｃｏｍｍａｎｄ ＰａｃｋｅｔのヘッダにおけるｄｅｓｔｉｎａｔｉｏｎＩＤに相当するもので、このバスＩＤ及びＮｏｄｅ ＩＤによって、或るバスに接続された機器がＩＥＥＥ１３９４システム上で特定される。
【００９７】
図１７（ａ）においてＮｏｄｅ ＩＤに続く２０ビットの領域は、ｒｅｇｉｓｔｅｒ ｓｐａｃｅであり、このｒｅｇｉｓｔｅｒ ｓｐａｃｅに続く２８ビットの領域は、ｒｅｇｉｓｔｅｒ ａｄｄｒｅｓである。
ｒｅｇｉｓｔｅｒ ｓｐａｃｅの値は［Ｆ ＦＦ ＦＦｈ］とされて、図１７（ｄ）に示すｒｅｇｉｓｔｅｒを示し、このｒｅｇｉｓｔｅｒの内容は、図１７（ｅ）に示すようにして定義される。ｒｅｇｉｓｔｅｒ ａｄｄｒｅｓは、図１７（ｅ）に示すレジスタのアドレスを指定している。
【００９８】
簡単に説明すると、図１７（ｅ）のレジスタにおいて、例えばアドレス５１２［０ ００ ０２ ００ｈ］から始まるＳｅｒｉａｌ Ｂｕｓ−ｄｅｐａｎｄｅｎｔ Ｒｅｇｉｓｔｅｒｓを参照することで、Ｉｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅのサイクルタイムや、空きチャンネルの情報が得られる。
また、アドレス１０２４［０ ００ ０４ ００ｈ］から始まるＣｏｎｆｉｇｕｒａｔｉｏｎ ＲＯＭの内容を参照すれば、Ｎｏｄｅの機種から、その機種に付されているＮｏｄｅ Ｕｎｉｑｕｅ ＩＤなども識別することができる。
【００９９】
４−８．ＣＩＰ
図１８は、ＣＩＰ(Common Isochronos Packet)の構造を示している。つまり、図１５に示したＩｓｏｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔのデータ構造である。
前に述べたように、一般にはリアルタイム性が要求されるＡＶデータは、ＩＥＥＥ１３９４通信においては、Ｉｓｏｃｈｒｏｎｏｕｓ通信によりデータの送受信が行われる。つまり、リアルタイム性が維持されるだけのデータ量をこのＩｓｏｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔに格納して、１Ｉｓｏｃｈｒｏｎｏｕｓ ｃｙｃｌｅ毎に順次送信するものである。
【０１００】
ＣＩＰの先頭３２ビット（１ｑｕａｄｌｅｔ）は、１３９４パケットヘッダとされている。
１３９４パケットヘッダにおいて上位から順に１６ビットの領域は、ｄａｔａ＿Ｌｅｎｇｔｈ、続く２ビットの領域はｔａｇ、続く６ビットの領域はｃｈａｎｎｅｌ、続く４ビットはｔｃｏｄｅ、続く４ビットは、ｓｙとされている。
そして、１３９４パケットヘッダに続く１ｑｕａｄｌｅｔの領域はｈｅａｄｅｒ＿ＣＲＣが格納される。
【０１０１】
ｈｅａｄｅｒ＿ＣＲＣに続く２ｑｕａｄｌｅｔの領域がＣＩＰヘッダとなる。ＣＩＰヘッダの上位ｑｕａｄｌｅｔの上位２バイトには、それぞれ‘０’‘０’が格納され、続く６ビットの領域はＳＩＤ（送信ノード番号）を示す。ＳＩＤに続く８ビットの領域はＤＢＳ（データブロックサイズ）であり、データブロックのサイズ（パケット化の単位データ量）が示される。続いては、ＦＮ（２ビット）、ＱＰＣ（３ビット）の領域が設定されており、ＦＮにはパケット化する際に分割した数が示され、ＱＰＣには分割するために追加したｑｕａｄｌｅｔ数が示される。
ＳＰＨ（１ビット）にはソースパケットのヘッダのフラグが示され、ＤＢＣにはパケットの欠落を検出するカウンタの値が格納される。
【０１０２】
ＣＩＰヘッダの下位ｑｕａｄｌｅｔの上位２バイトにはそれぞれ‘０’‘０’が格納される。そして、これに続いてＦＭＴ（６ビット）、ＦＤＦ（２４ビット）の領域が設けられる。ＦＭＴには信号フォーマット（伝送フォーマット）が示され、ここに示される値によって、当該ＣＩＰに格納されるデータ種類（データフォーマット）が識別可能となる。具体的には、ＭＰＥＧストリームデータ、Ａｕｄｉｏストリームデータ、デジタルビデオカメラ（ＤＶ）ストリームデータ等の識別が可能になる。このＦＭＴにより示されるデータフォーマットは、例えば図１０に示した、ＣＩＰ Ｈｅａｄｅｒ Ｆｏｒｍａｔ（４０１）に管理される、ＳＤ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０２），ＨＤ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０３），ＳＤＬ−ＤＶＣＲ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０４），ＭＰＥＧ２−ＴＳ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０５），Ａｕｄｉｏ ａｎｄ Ｍｕｓｉｃ Ｒｅａｌｔｉｍｅ Ｔｒａｎｓｍｉｓｓｉｏｎ（５０６）等の伝送プロトコルに対応する。
ＦＤＦは、フォーマット依存フィールドであり、上記ＦＭＴにより分類されたデータフォーマットについて更に細分化した分類を示す領域とされる。オーディオに関するデータで有れば、例えばリニアオーディオデータであるのか、ＭＩＤＩデータであるのかといった識別が可能になる。
例えば本実施の形態のディスクプレーヤにより再生可能なＣＤ−ＤＡデータであれば、先ずＦＭＴによりＡｕｄｉｏストリームデータの範疇にあるデータであることが示され、ＦＤＦに規定に従った特定の値が格納されることで、そのＡｕｄｉｏストリームデータはＣＤ−ＤＡデータであることが示される。
【０１０３】
ここで、例えばＦＭＴによりＭＰＥＧであることが示されている場合、ＦＤＦにはＴＳＦ（タイムシフトフラグ）といわれる同期制御情報が格納される。また、ＦＭＴによりＤＶＣＲ（デジタルビデオカメラ）であることが示されている場合、ＦＤＦは、図１８の下に示すように定義される。ここでは、上位から順に、５０／６０（１ビット）により１秒間のフィールド数を規定し、ＳＴＹＰＥ（５ビット）によりビデオのフォーマットがＳＤとＨＤの何れとされてるのかが示され、ＳＹＴによりフレーム同期用のタイムスタンプが示される。
【０１０４】
上記ＣＩＰヘッダに続けては、ＦＭＴ，ＦＤＦによって示されるデータが、ｎ個のデータブロックのシーケンスによって格納される。ＦＭＴ，ＦＤＦによりＣＤ−ＤＡデータであることが示される場合には、このデータブロックとしての領域にＣＤ−ＤＡデータが格納される。
そして、データブロックに続けては、最後にｄａｔａ＿ＣＲＣが配置される。
【０１０５】
４−９．コネクションマネージメント
ＩＥＥＥ１３９４フォーマットにおいては、「プラグ」といわれる論理的接続概念によって、ＩＥＥＥ１３９４バスによって接続された機器間の接続関係が規定される。
図１９は、プラグにより規定された接続関係例を示しており、この場合には、ＩＥＥＥ１３９４バスを介して、ＶＴＲ１、ＶＴＲ２、セットトップボックス（ＳＴＢ；デジタル衛星放送チューナ）、モニタ装置（Ｍｏｎｉｔｏｒ）、及びデジタルスチルカメラ（Ｃａｍｅｒａ）が接続されているシステム形態が示されている。
【０１０６】
ここで、ＩＥＥＥ１３９４のプラグによる接続形態としては、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ−ｃｏｎｎｅｃｔｉｏｎと、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎとの２つの形態が存在する。
ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ−ｃｏｎｎｅｃｔｉｏｎは、送信機器と受信機器との関係が特定され、かつ、特定のチャンネルを使用して送信機器と受信機器との間でデータ伝送が行われる接続形態である。
これに対して、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎは、送信機器においては、特に受信機器及び使用チャンネルを特定せずに送信を行うものである。受信機側では、特に送信機器を識別することなく受信を行い、必要が有れば、送信されたデータの内容に応じた所要の処理を行う。
図１９の場合であれば、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ−ｃｏｎｎｅｃｔｉｏｎとして、ＳＴＢが送信、ＶＴＲ１が受信とされてチャンネル＃１を使用してデータの伝送が行われるように設定されている状態と、デジタルスチルカメラが送信、ＶＴＲ２が受信とされてチャンネル＃２を使用してデータの伝送が行われるように設定されている状態とが示されている。
また、デジタルスチルカメラからは、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによってもデータ送信を行うように設定されている状態が示されており、ここでは、このｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによって送信したデータを、モニタ装置が受信して所要の応答処理を行う場合が示される。
【０１０７】
上記のような接続形態（プラグ）は、各機器におけるアドレス空間に設けられるＰＣＲ(Plug Contorol Register)によって確立される。
図２０（ａ）は、ｏＰＣＲ［ｎ］（出力用プラグコントロールレジスタ）の構造を示し、図２０（ｂ）は、ｉＰＣＲ［ｎ］（入力用プラグコントロールレジスタ）の構造を示している。これらｏＰＣＲ［ｎ］、ｉＰＣＲ［ｎ］のサイズは共に３２ビットとされている。
図２０（ａ）のｏＰＣＲにおいては、例えば上位１ビットのｏｎ−ｌｉｎｅに対して‘１’が格納されていると、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによる送信であることが示され、‘０’が格納されていると、上位１１ビット目から６ビットの領域のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示されるチャンネルにより、ｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎで送信することが示される。
また、図２０（ｂ）のｉＰＣＲにおいても、例えば上位１ビットのｏｎ−ｌｉｎｅに対して‘１’が格納されていれば、ｂｒｏａｄｃａｓｔ ｃｏｎｎｅｃｔｉｏｎによる受信であることが示され、‘０’が格納されていると、上位１１ビット目から６ビットの領域のｃｈａｎｎｅｌ ｎｕｍｂｅｒで示されるチャンネルにより送信されたデータをｐｏｉｎｔ ｔｏ ｐｏｉｎｔ ｃｏｎｎｅｃｔｉｏｎで送信することが示される。
【０１０８】
４−１０．ＦＣＰにおけるコマンド及びレスポンス
本実施の形態のＩＥＥＥ１３９４フォーマットでは、各種コマンドは、Ａｓｙｎｃｈｒｏｎｏｕｓ通信によりデータの送受信が行われる。ここでは、ＦＣＰにより規定されるトランザクションについて説明する。
【０１０９】
ＦＣＰとしては、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において規定されるＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎ（図１６参照）を使用する。
ＦＣＰをサポートする機器は、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタを備え、次に図２１により説明するようにしてＣｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してＭｅｓｓａｇｅを書き込むことでトランザクションを実現する。
【０１１０】
図２１の処理遷移図においては、先ずＣＯＭＭＡＮＤ送信のための処理として、ステップＳ２１として示すように、ＣｏｎｔｒｏｌｌｅｒがＴｒａｎｓａｃｔｉｏｎ Ｒｅｑｕｅｓｔを発生して、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔをＴａｒｇｅｔに対して送信する処理を実行する。Ｔａｒｇｅｔでは、ステップＳ２２として、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔを受信して、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してデータの書き込みを行う。また、この際、ＴａｒｇｅｔからはＣｏｎｔｒｏｌｌｅｒに対してＡｃｋｎｏｗｌｅｄｇを送信し、Ｃｏｎｔｒｏｌｌｅｒでは、このＡｃｋｎｏｗｌｅｄｇを受信する（Ｓ２３→Ｓ２４）。ここまでの一連の処理が、ＣＯＭＭＡＮＤの送信に対応する処理となる。
【０１１１】
続いては、ＣＯＭＭＡＮＤに応答した、ＲＥＳＰＯＮＣＥのための処理として、ＴａｒｇｅｔからＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔが送信される（Ｓ２５）。Ｃｏｎｔｒｏｌｌｅｒではこれを受信して、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してデータの書き込みを行う（Ｓ２６）。また、Ｃｏｎｔｒｏｌｌｅｒでは、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔの受信に応じて、Ｔａｒｇｅｔに対してＡｃｋｎｏｗｌｅｄｇを送信する（Ｓ２７）。Ｔａｒｇｅｔでは、このＡｃｋｎｏｗｌｅｄｇを受信することで、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔがＣｏｎｔｒｏｌｌｅｒにて受信されたことを知る（Ｓ２８）。
つまり、ＣｏｎｔｒｏｌｌｅｒからＴａｒｇｅｔ対するＣＯＭＭＡＮＤ伝送処理と、これに応答したＴａｒｇｅｔからＣｏｎｔｒｏｌｌｅｒに対するＲＥＳＰＯＮＣＥ伝送処理が、ＦＣＰによるデータ伝送（Ｔｒａｎｓａｃｔｉｏｎ）の基本となる。
【０１１２】
４−１１．ＡＶ／Ｃコマンドパケット
図１０により説明したように、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において、ＦＣＰは、ＡＶ／Ｃコマンドを用いて各種ＡＶ機器に対する通信を行うことができるようにされている。
Ａｓｙｎｃｈｒｏｎｏｕｓ通信では、Ｗｒｉｔｅ，Ｒｅａｄ，Ｌｏｃｋの３種のトランザクションが規定されているのは、図１６にて説明した通りであり、実際には各トランザクションに応じたＷｒｉｔｅ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔ，Ｒｅａｄ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔ，Ｌｏｃｋ Ｒｅｑｕｅｓｔ／Ｒｅｓｐｏｎｃｅ Ｐａｃｋｅｔが用いられる。そして、ＦＣＰでは、上述したようにＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを使用するものである。
そこで図２２に、Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ（Asynchronous Packet（Write Request for Data Block)）のフォーマットを示す。本実施の形態では、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔが即ち、ＡＶ／Ｃコマンドパケットとして使用される。
【０１１３】
このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔにおける上位５ｑｕａｄｌｅｔ（第１〜第５ｑｕａｄｌｅｔ）は、ｐａｃｋｅｔ ｈｅａｄｅｒとされる。
ｐａｃｋｅｔ ｈｅａｄｅｒの第１ｑｕａｄｌｅｔにおける上位１６ビットの領域はｄｅｓｔｉｎａｔｉｏｎ＿ＩＤで、データの転送先（宛先）のＮｏｄｅ ＩＤを示す。続く６ビットの領域はｔｌ(transact label)であり、パケット番号を示す。続く２ビットはｒｔ(retry code)であり、当該パケットが初めて伝送されたパケットであるか、再送されたパケット示す。続く４ビットの領域はｔｃｏｄｅ(transaction code)は、指令コードを示している。そして、続く４ビットの領域はｐｒｉ(priority)であり、パケットの優先順位を示す。
【０１１４】
第２ｑｕａｄｌｅｔにおける上位１６ビットの領域はｓｏｕｒｃｅ＿ＩＤであり、データの転送元のＮｏｄｅ＿ＩＤ が示される。
また、第２ｑｕａｄｌｅｔにおける下位１６ビットと第３ｑｕａｄｌｅｔ全体の計４８ビットはｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔとされ、ＣＯＭＭＡＮＤレジスタ（ＦＣＰ＿ＣＯＭＭＡＮＤ ｒｅｇｉｓｔｅｒ）とＲＥＳＰＯＮＣＥレジスタ（ＦＣＰ＿ＲＥＳＰＯＮＣＥ ｒｅｇｉｓｔｅｒ）のアドレスが示されれる。
上記ｄｅｓｔｉｎａｔｉｏｎ＿ＩＤ及びｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔが、ＩＥＥＥ１３９４フォーマットにおいて規定される６４ビットのアドレス空間に相当する。
【０１１５】
第４ｑｕａｄｌｅｔの上位１６ビットの領域は、ｄａｔａ＿ｌｅｎｇｔｈとされ、後述するｄａｔａｆｉｅｌｄ（図２２において太線により囲まれる領域）のデータサイズが示される。
続く下位１６ビットの領域は、ｅｘｔｅｎｄｅｄ＿ｔｃｏｄｅの領域とされ、ｔｃｏｄｅを拡張する場合に使用される領域である。
【０１１６】
第５ｑｕａｄｌｅｔとしての３２ビットの領域は、ｈｅａｄｅｒ＿ＣＲＣであり、Ｐａｃｋｅｔ ｈｅａｄｅｒのチェックサムを行うＣＲＣ計算値が格納される。
【０１１７】
Ｐａｃｋｅｔ ｈｅａｄｅｒに続く第６ｑｕａｄｌｅｔからｄａｔａ ｂｌｏｃｋが配置され、このｄａｔａ ｂｌｏｃｋ内の先頭に対してｄａｔａｆｉｅｌｄが形成される。
ｄａｔａｆｉｅｌｄとして先頭となる第６ｑｕａｄｌｅｔの上位４バイトには、ＣＴＳ(Command and Transaction Set)が記述される。これは、当該Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ ＰａｃｋｅｔのコマンドセットのＩＤを示すもので、例えば、このＣＴＳの値について、図のように［００００］と設定すれば、ｄａｔａｆｉｅｌｄに記述されている内容がＡＶ／Ｃコマンドであると定義されることになる。つまり、このＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔは、ＡＶ／Ｃコマンドパケットであることが示されるものである。従って、本実施の形態においては、ＦＣＰがＡＶ／Ｃコマンドを使用するため、このＣＴＳには［００００］が記述されることになる。
【０１１８】
ＣＴＳに続く４ビットの領域は、ｃｔｙｐｅ(Command type；コマンドの機能分類)、又はコマンドに応じた処理結果(レスポンス)を示すｒｅｓｐｏｎｓｅが記述される。
【０１１９】
図２３に、上記ｃｔｙｐｅ及びｒｅｓｐｏｎｓｅの定義内容を示す。
ｃｔｙｐｅ（Ｃｏｍｍａｎｄ）としては、［００００］〜［０１１１］を使用できるものとしており、［００００］はＣＯＮＴＲＯＬ、［０００１］はＳＴＡＴＵＳ、［００１０］はＩＮＱＵＩＲＹ、［００１１］はＮＯＴＩＦＹとして定義され、［０１００］〜０１１１は、現状、未定義（ｒｅｓｅｒｖｅｄ）とされている。
ＣＯＮＴＲＯＬは機能を外部から制御するコマンドであり、ＳＴＡＴＵＳは外部から状態を間い合わせるコマンド、ＩＮＱＵＩＲＹは、制御コマンドのサポートの有無を外部から問い合わせるコマンド、ＮＯＴＩＦＹは状態の変化を外部に知らせることを要求するコマンドである。
また、ｒｅｓｐｏｎｓｅとしては、［１０００］〜［１１１１］を使用するものとしており、［１０００］はＮＯＴ ＩＭＰＬＥＭＥＮＴＥＤ、［１００１］はＡＣＣＥＰＴＥＤ、［１０１０］はＲＥＪＥＣＴＥＤ、［１０１１］はＩＮ ＴＲＡＮＳＩＴＩＯＮ、［１１００］はＩＭＰＬＥＭＥＮＴＥＤ／ＳＴＡＢＬＥ、［１１０１］はＣＨＡＮＧＥＤ、［１１１０］はｒｅｓｅｒｖｅｄ、［１１１１］はＩＮＴＥＲＩＭとしてそれぞれ定義されている。
これらのｒｅｓｐｏｎｓｅは、コマンドの種類に応じて使い分けられる。例えば、ＣＯＮＴＯＲＯＬのコマンドに対応するｒｅｓｐｏｎｓｅとしては、ＮＯＴＩＭＰＬＥＭＥＮＴＥＤ、ＡＣＣＥＰＴＥＤ、ＲＥＪＥＣＴＥＤ、或いはＩＮＴＥＲＩＭの4つのうちの何れかがＲｅｓｐｏｎｄｅｒ側の状況等に応じて使い分けられる。
【０１２０】
図２２において、ｃｔｙｐｅ／ｒｅｓｐｏｎｓｅに続く５ビットの領域には、ｓｕｂｕｎｉｔ−ｔｙｐｅが格納される。は、ｓｕｂｕｎｉｔ−ｔｙｐｅは、ＣＯＭＭＭＡＮＤの宛先またはＲＥＳＰＯＮＣＥの送信元のｓｕｂｕｎｉｔが何であるのか（機器）を示す。ＩＥＥＥ１３９４フォーマットでは、機器そのものをｕｎｉｔと称し、そのｕｎｉｔ（機器）内において備えられる機能的機器単位の種類をｓｕｂｕｎｉｔと称する。例えば一般のＶＴＲを例に採れば、ＶＴＲとしてのｕｎｉｔは、地上波や衛星放送を受信するチューナと、ビデオカセットレコーダ／プレーヤとの、２つのｓｕｂｕｎｉｔを備える。
ｓｕｂｕｎｉｔ−ｔｙｐｅとしては、例えば図２４（ａ）に示すように定義されている。つまり、［０００００］はＭｏｎｉｔｏｒ、［００００１］〜［０００１０］はｒｅｓｅｒｖｅｄ、［０００１１］はＤｉｓｃ ｒｅｃｏｒｄｅｒ／ｐｌａｙｅｒ、［００１００］はＶＣＲ、［００１０１］はＴｕｎｅｒ、［００１１１］はＣａｍｅｒａ、［０１０００］〜［１１１１０］はｒｅｓｅｒｖｅｄ、［１１１１１］は、ｓｕｂｕｎｉｔが存在しない場合に用いられるｕｎｉｔとして定義されている。
【０１２１】
図２２において、上記ｓｕｂｕｎｉｔ−ｔｙｐｅに続く３ビットには、同―種類のｓｕｂｕｎｉｔが複数存在する場合に、各ｓｕｂｕｎｉｔを特定するためのｉｄ（Ｎｏｄｅ＿ＩＤ）が格納される。
【０１２２】
上記ｉｄ（Ｎｏｄｅ＿ＩＤ）に続く８ビットの領域には、ｏｐｃｏｄｅが格納され、続く８ビットの領域には、ｏｐｅｒａｎｄが格納される。
ｏｐｃｏｄｅとは、オぺレーションコード(Operation Code)のことであって、ｏｐｅｒａｎｄには、ｏｐｃｏｄｅが必要とする情報（パラメータ）が格納される。これらｏｐｃｏｄｅはｓｕｂｕｎｉｔごとに定義され、ｓｕｂｕｎｉｔごとに固有のｏｐｃｏｄｅのリストのテーブルを有する。例えば、ｓｕｂｕｎｉｔがＶＣＲであれば、ｏｐｃｏｄｅとしては、例えば図２４（ｂ）に示すようにして、ＰＬＡＹ（再生），ＲＥＣＯＲＤ（記録）などをはじめとする各種コマンドが定義されている。ｏｐｅｒａｎｄは、ｏｐｃｏｄｅ毎に定義される。
【０１２３】
図２２におけるｄａｔａｆｉｅｌｄとしては、上記第６ｑｕａｄｌｅｔの３２ビットが必須とされるが、必要が有れば、これに続けて、ｏｐｅｒａｎｄを追加することが出来る（Ａｄｄｉｔｉｏｎａｌ ｏｐｅｒａｎｄｓ）。
ｄａｔａｆｉｅｌｄに続けては、ｄａｔａ＿ＣＲＣが配置される。なお、必要が有れば、ｄａｔａ＿ＣＲＣの前にｐａｄｄｉｎｇを配置することが可能である。
【０１２４】
４−１２．プラグ
ここで、ＩＥＥＥ１３９４フォーマットにおけるプラグについて概略的に説明する。ここでいうプラグとは、先に図２０によっても説明したように、ＩＥＥＥ１３９４フォーマットにおける機器間の論理的接続関係をいうものである。
【０１２５】
図２５に示すように、Ａｓｙｎｃｈｒｏｎｏｕｓ通信において有効とされるコマンド等のデータ（ｒｅｑｕｅｓｔ）は、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して伝送される。ここでいうｐｒｏｄｕｃｅｒ及びｃｏｎｓｕｍｅｒは、それぞれＩＥＥＥ１３９４インターフェイス上で送信機器、受信機器として機能する機器をいうものである。そして、ｃｏｎｓｕｍｅｒにおいては、図に斜線で示すように、ｐｒｏｄｕｃｅｒによりデータ書き込みが行われるセグメントバッファ（Segment Buffer）を備える。
また、ＩＥＥＥ１３９４システムにおいて、特定の機器をｐｒｏｄｕｃｅｒ、ｃｏｎｓｕｍｅｒとして規定するための情報（Connection Management Information）は、図に網線で示すプラグアドレス内の所定位置に格納されている。セグメントバッファは、プラグアドレスに続いて配置される。
ｃｏｎｓｕｍｅｒのセグメントバッファに対して書き込み可能なアドレス範囲（データ量）は、後述するようにしてｃｏｎｓｕｍｅｒ側で管理するｌｉｍｉｔ
Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒによって規定される。
【０１２６】
図２６は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグのアドレス空間の構造を示している。
６４ビットから成るプラグのアドレス空間は、図２６（ａ）に示すようにして、２の１６乗（６４Ｋ）のＮｏｄｅに分割される。そして、プラグは、図２６（ｂ）に示すようにして、各Ｎｏｄｅのアドレス空間内に在るようにされる。そして、各プラグは、図２６（ｃ）に示すように、網線の領域により示すレジスタ（ｒｅｇｉｓｔｅｒ）と、斜線の領域により示すセグメントバッファ(Segment Buffer)とを含んで形成される。レジスタには、次に説明するようにして、送信側（ｐｒｏｄｕｃｅｒ）と受信側（ｃｏｎｓｕｍｅｒ）との間におけるデータの授受管理に必要な情報（例えば、送信データサイズ及び受信可能データサイズ）が格納される。セグメントバッファは、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して送信されたデータが書き込まれるべき領域であり、例えば最小で６４バイトであることが規定されている。
【０１２７】
図２７（ａ）にはプラグアドレスが示されている。つまり、上記図２６（ｃ）と同一内容が示されている。
この図に示すように、レジスタはプラグアドレスの先頭に対して配置され、これに続けてセグメントバッファが配置される。
そして、レジスタ内の構造としては、図２７（ｂ）に示すようにして、先頭に対して、例えば３２ビットのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒが配置され、続けて、各３２ビットのｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１］〜［１４］が配置される。つまり、１つのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒと１４のｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒが設けられる。なお、ここでは、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１４］の後ろに未使用（ｕｎｕｓｅｄ）の領域が設けられている。
【０１２８】
上記図２７（ａ）（ｂ）に示すプラグ構造は、図２７（ｃ）に示すようにして、オフセットアドレス(Address Offset)によって指定される。
つまり、オフセットアドレス０は、ｃｏｎｓｕｍｅｒ ｐｏｒｔ（ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ）を指定し、オフセットアドレス４，８，１２・・・５６，６０は、それぞれｐｒｏｄｕｃｅｒ ｐｏｒｔ［１］〜［１４］を指定する。オフセットアドレス６０はｒｅｓｅｒｖｅｄとして定義されることで、未使用（ｕｎｕｓｅｄ）の領域を示し、オフセットアドレス６４によりセグメントバッファを示す。
【０１２９】
図２８には、ｐｒｏｄｕｃｅｒ側とｃｏｎｓｕｍｅｒ側との両者のプラグ構造が示されている。
Ａｓｙｎｃｈｒｏｎｏｕｓ通信のプラグ構造においては、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒへの書き込み、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒへの書き込み、及びセグメントバッファへの書き込みを後述する送受信手順に従って行うことで、Ａｓｙｎｃｈｒｏｎｏｕｓ通信を実現する。これらの書き込みは、先に説明したＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎとしての処理である。
【０１３０】
ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｐｒｏｄｕｃｅｒによってｃｏｎｓｕｍｅｒに対して書き込みが行われる。
ｐｒｏｄｕｃｅｒは、自身のアドレスに在るｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒにｐｒｏｄｕｃｅｒ側のデータ伝送に関する情報を書き込んだ上で、このｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒの内容を、ｃｏｎｓｕｍｅｒのｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒに対して書き込む。
ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｐｒｏｄｕｃｅｒがｃｏｎｓｕｍｅｒのセグメントバッファに対して書き込むデータサイズとして、１回の書き込み処理によって書き込むデータサイズの情報とされる。つまり、ｐｒｏｄｕｃｅｒが、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒの書き込みを行うことによって、ｃｏｎｓｕｍｅｒのセグメントバッファに書き込むデータサイズを知らせる処理が行われる。
【０１３１】
これに対して、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒは、ｃｏｎｓｕｍｅｒによってｐｒｏｄｕｃｅｒに対して書き込みが行われる。
ｃｏｎｓｕｍｅｒ側では、自身のｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［１］〜［１４］のうち、ｐｒｏｄｕｃｅｒに対応して指定された１つのｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に対して、自身のセグメントバッファの容量（サイズ）を書き込み、このｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］の内容を、ｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に対して書き込む。
【０１３２】
ｐｒｏｄｕｃｅｒ側では、上記のようにしてｌｉｍｉｔ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ［ｎ］に書き込まれた内容に応じて、１回あたりの書き込みデータ量を決定して、例えば自身のセグメントバッファに対して書き込みを行う。そして、このセグメントバッファに書き込んだ内容を、ｃｏｎｓｕｍｅｒに対して書き込むようにされる。このセグメントバッファへの書き込みが、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ送信に相当する。
【０１３３】
４−１３．Asynchronous Connection送信手順
続いて、上記図２８により説明したプラグ（ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒ）間の構造を前提として、図２９の処理遷移図により、Ａｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎの基本的な送受信手順について説明する。
図２９に示す送受信処理の手順は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信として、ＦＣＰによって規定された環境のもとで、ＡＶ／Ｃコマンド（Ｗｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ）を使用して行われる。
なお、Ａｓｙｎｃｈｒｏｎｏｕｓ ｃｏｎｎｅｃｔｉｏｎの実際においては、コマンド送信に応じて、図２１に示したように、Ａｃｋｎｏｗｌｅｄｇの送受信が実行されるのであるが、図２９においてはＡｃｋｎｏｗｌｅｄｇについての送受信処理の図示は省略している。
【０１３４】
また、ＩＥＥＥ１３９４インターフェイスでは、プラグ（機器）間の接続関係として、上記したｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係の他に、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔとして規定される関係が存在する。ＩＥＥＥ１３９４システム上においては、ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係が規定された機器と、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔの関係が機器とが必ずしも一致するものではない。つまり、ｐｒｏｄｕｃｅｒとして規定された機器の他に、ｃｏｎｔｒｏｌｌｅｒの機能を有するものとして規定された機器が存在する場合がある。但し、ここでは、ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒとしての関係と、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔとしての関係が一致している場合を例に説明する。
【０１３５】
図２９に示す送信手順としては、先ず、ステップＳ１０１として示すように、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、Ｃｏｎｎｅｃｔ要求を送信する。このＣｏｎｎｅｃｔ要求は、ｐｒｏｄｕｃｅｒがｃｏｎｓｕｍｅｒに対して、接続要求を行うためのコマンドで、ｐｒｏｄｕｃｅｒのレジスタのアドレスをｃｏｎｓｕｍｅｒに対して伝える。
このＣｏｎｎｅｃｔ要求は、ステップＳ１０２の処理としてｃｏｎｓｕｍｅｒが受信することで、ｃｏｎｓｕｍｅｒ側では、ｐｒｏｄｕｃｅｒのレジスタのアドレスを認識する。そして、ステップＳ１０３により、ｒｅｓｐｏｎｃｅとして、ｃｏｎｓｕｍｅｒは、ｐｒｏｄｕｃｅｒに対してＣｏｎｎｅｃｔ受付を送信する。そして、ステップＳ１０４において、ｐｒｏｄｕｃｅｒがこれを受信することで、以降のデータ送受信のためのｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒ間の接続（ｃｏｎｎｅｃｔｉｏｎ）が確立される。
【０１３６】
上記のようにしてｃｏｎｎｅｃｔｉｏｎが確立されると、ステップＳ１０５により、ｃｏｎｓｕｍｅｒは、ｐｒｏｄｕｃｅｒに対してｌｉｍｉｔ Ｃｏｕｎｔｒｅｇｉｓｔｅｒ（（以降、単に「ｌｉｍｉｔ Ｃｏｕｎｔ」と略す））の書込要求を行う。ステップＳ１０６によりこれを受信したｐｒｏｄｕｃｅｒは、続くステップＳ１０７の処理によって、ｌｉｍｉｔ Ｃｏｕｎｔ書込受付を、ｃｏｎｓｕｍｅｒに対して送信する。そして、ステップＳ１０８の処理として、ｃｏｎｓｕｍｅｒがｌｉｍｉｔ Ｃｏｕｎｔ書込受付を受信する。このｌｉｍｉｔ Ｃｏｕｎｔ書込要求／書込受付の一連の処理によって、以降における、セグメントバッファへのデータ書き込みサイズ（セグメントバッファ容量）が決定される。
【０１３７】
続くステップＳ１０９においては、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、セグメントバッファ書込要求を送信する。そして、ステップＳ１１０によってセグメントバッファ書込要求が受信され、これに応答して、ステップＳ１１１の処理として、ｃｏｎｓｕｍｅｒからｐｒｏｄｕｃｅｒに対して、セグメントバッファ書込受付を送信する。ｐｒｏｄｕｃｅｒは、ステップＳ１１２により、セグメントバッファ書込受付を受信する。
このステップＳ１０９〜Ｓ１１２までの処理が実行されることで、１回のｐｒｏｄｕｃｅｒのセグメントバッファからｃｏｎｓｕｍｅｒのセグメントバッファに対してデータへの書き込み処理が完了する。
ここで、上記ステップＳ１０９〜Ｓ１１２の処理によって書き込まれるデータは、図１５に示したＡｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔによる１回の送信により書き込まれる。従って、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにより転送されるデータサイズが、上記ｌｉｍｉｔ Ｃｏｕｎｔによって指定されたデータサイズよりも小さく、かつ、１回のＡｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔによる送信によっては、必要なデータ送信が完了しない場合には、セグメントバッファの容量がフルとなる範囲で、ステップＳ１０９〜Ｓ１１２の処理が繰り返されるようになっている。
【０１３８】
そして、上記したステップＳ１０９〜Ｓ１１２に示すセグメントバッファへの書き込み処理が完了すると、ステップＳ１１３の処理として示すように、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒ（以降、単にｐｒｏｄｕｃｅｒ Ｃｏｕｎｔと略す）書込要求を送信する。そしてｃｏｎｓｕｍｅｒでは、ステップＳ１１４の処理として、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔを受信して、自身のｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ ｒｅｇｉｓｔｅｒに書き込みを行い、続くステップＳ１１５の処理として、ｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書込受付をｐｒｏｄｕｃｅｒに対して送信する。ｐｒｏｄｕｃｅｒはステップＳ１１６により、このｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書込受付を受信する。
この処理によって、先のステップＳ１０９〜Ｓ１１２の処理として、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒのセグメントバッファに対して転送したデータサイズがｃｏｎｓｕｍｅｒに対して知らされることになる。
【０１３９】
続くステップＳ１１７の処理としては、上記ステップＳ１１３〜Ｓ１１６に示したｐｒｏｄｕｃｅｒ Ｃｏｕｎｔ書き込み処理に応答しての、ｌｉｍｉｔ Ｃｏｕｎｔ書き込みのための一連の処理が実行される。つまり、ステップＳ１１７〜Ｓ１２０に示すようにして、ｃｏｎｓｕｍｅｒからｐｒｏｄｕｃｅｒへのｌｉｍｉｔ Ｃｏｕｎｔ書込要求の送信と、この送信に応答してのｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒへのｌｉｍｉｔ Ｃｏｕｎｔ書込受付の送信が行われる。
【０１４０】
上記ステップＳ１０９〜Ｓ１２０までの処理が、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎにおけるデータ伝送処理としての１セットの手順を成す。ここで、例えば送信すべきデータサイズが、セグメントバッファ容量よりも大きく、１回のステップＳ１０９〜Ｓ１２０までの処理によっては、データの転送が完了していないとされる場合には、このステップＳ１０９〜Ｓ１２０までの処理を、データの転送が完了するまで繰り返し実行することが出来るようになっている。
【０１４１】
そして、データの転送が完了したら、ステップＳ１２１に示すようにして、ｐｒｏｄｕｃｅｒはｃｏｎｓｕｍｅｒに対して、Ｄｉｓｃｏｎｎｅｃｔ要求を送信する。ｃｏｎｓｕｍｅｒはステップＳ１２２において、このＤｉｓｃｏｎｎｅｃｔ要求を受信し、続くステップＳ１２３によりＤｉｓｃｏｎｎｅｃｔ受付を送信する。ステップＳ１２４において、ｐｒｏｄｕｃｅｒがＤｉｓｃｏｎｎｅｃｔ受付を受信することで、Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎによるデータ送受信が完結する。
【０１４２】
５．本実施の形態のSubunit Identifier Descriptor
５−１．基本概念
これまでの説明から分かるように、本実施の形態のディスクプレーヤ０は、ＩＥＥＥ１３９４バスを介して例えばパーソナルコンピュータなどの他の機器と接続することが可能とされている。
そして、このようなオーディオ機器がＩＥＥＥ１３９４バスを介して接続を行って、各種機能を実現するためには、そのオーディオ機器に装填されているメディアに記録されているデータを管理するための管理情報として、ＩＥＥＥ１３９４インターフェイス上で認識可能な形式による管理情報を構築することが必要であるとされている。
【０１４３】
前述したように、例えばディスクプレーヤ０のシステムにあっては、記録データを管理する情報としてＴＯＣ情報（ＣＤレイヤーにあってはＣＤ−ＴＯＣ，ＨＤレイヤーにあってはマスターＴＯＣ，エリアＴＯＣ（Area TOC-1,Area TOC-2））が存在し、これがディスクに記録されているのであるが、これらＴＯＣ情報は、あくまでもディスクプレーヤのシステム内で完結する情報であり、そのままＩＥＥＥ１３９４インターフェイスに適合するものではない。
そこで、本実施の形態のディスクプレーヤ０においては、ディスクに記録されたＴＯＣ情報を利用して、ＩＥＥＥ１３９４フォーマットに適合する形式による管理情報を別途作成して保持するようにされる。これが、ＩＥＥＥ１３９４データインターフェイス下でのＡＶ／Ｃプロトコルにて規定される「Subunit Identifier Descriptor」といわれるものである。
【０１４４】
また、この場合には、その対象がディスクであることから、Subunit_typeとしては、Disc recorder／Playerとされることになる。このDisc recorder／PlayerのSubunit_typeに対応して作成されるSubunit Identifier Descriptorは、「Disc Subunit Identifier Descriptor」であるものとされている。そこで以降、本実施の形態のディスクプレーヤ０が有するべき「Disc Subunit Identifier Descriptor」について説明していくこととする。
【０１４５】
ここで先ず、図３０により、Subunit Identifier Descriptorの基本概念について述べておく。
Subunit Identifier Descriptorは、そのSubunitの各種属性の情報が格納したデータ構造とみることができる。そして、その構造としては階層構造を有するものとされている。
図３０（ａ）に示すブロックは、Subunit Identifier Descriptorにおける最も上の階層として見える構造を示している。つまり、階層構造において定義されるルート(root)に対応する。Subunit Identifier Descriptorは、１以上のオブジェクトにより形成されるが、そのオブジェクトとして、例えばここでは、List0〜List n-1として示される、List＿IDが格納される。このList0〜List n-1のList＿IDの各々によって、更にそのディレクトリ下にあるオブジェクトであるListの情報が指定される。つまり、List0のList＿IDによっては、図３０（ｂ）に示すList0のオブジェクトが指定され、List n-1のList＿IDによっては、図３０（ｃ）に示すList n-1のオブジェクトが指定される。
また、図３０（ｂ）のList0のオブジェクトもまた、各Listもまた、親（Parent）のディレクトリが子(Child)のディレクトリを示すようにして階層構造を有するようにされている。このようにして、ルートディレクトリから次々に子のディレクトリを参照してたどっていくことで、目的のオブジェクトに到達するまで階層を降りていくことができる。また逆に或る階層化のオブジェクトから親ディレクトリを参照してたどっていくことで、ルートディレクトリまで階層を上っていくことができる。
【０１４６】
５−２．Subunit Identifier Descriptor
以降、各図を参照して、Subunit Identifier Descriptor、及びその下で定義されるDisc Subunit Identifier Descriptorの具体的構造を述べていく。なお、以降説明する各図及びこれに対応する記述内容において、アドレス及び各種パラメータ等の値の後ろに付される「ｈ」は、その値が１６進法により表記されているものであることを示すものとする。
【０１４７】
ＡＶ／Ｃプロトコルにおいては、「Disc Subunit Identifier Descriptor」の上位概念として、「General Subunit Identifier Descriptor」が規定される。つまり、「General Subunit Identifier Descriptor」の規定によって、「Disc Subunit Identifier Descriptor」以外のSubunit Identifier Descriptorにも共通となる定義が規定されるものである。
【０１４８】
そして、先に図３０（ａ）に示したSubunit Identifier Descriptorは、実際には図３１に示すGeneral Subunit Identifier Descriptorとしての構造を有するものとして規定されている。
以下、この図に示される各エリアの内容のうち、本実施の形態に関して説明が必要とされるエリアについて説明を行っていくこととする。なお、以降においても、このようなデータ構造を示している図については、本実施の形態として必要とされるエリアについての説明にとどめることとする。
【０１４９】
図３１において、先頭のaddress=0000h-0001hで示されるエリアＡ１のdescriptor＿lengthには、このdescriptor＿lengthのエリアから下のエリアのサイズがバイト数により示される。
また、address=0008h以降のエリアＡ２−１〜Ａ２−ｎには、実際に設けられるRoot Contents List数ｎに応じて、root_object_list_id_0〜root_object_List_id_n-1のｎ個のroot_object_List_idが配置される。各root_object_list_idは、ここでは２バイトを使用するものとしているが、この使用バイト数は、アドレス0003hのエリアＡ３におけるsize_of_List_idに格納される値によって指定される。
各root_object_List_idのエリアＡ２−１〜Ａ２−ｎには、それぞれ、このsubunitに関連づけられているRoot Contents List（root object list）を指定するためのＩＤとしての値が格納されている。
また、このroot_object_List_idの数は、address=0006h−00007hで示されるnumber_of_root_object_ListのエリアＡ４に格納される値によって示される。つまり、number_of_root_object_Listによっては、そのsubunitに関連づけられているRoot Contents List（root object list）の総数が示される。
【０１５０】
また、エリアＡ６とされるsubunit_dependent_informationには、subunitのタイプに応じた形式で、subunitに対応した所定内容の情報が格納される。また、このsubunit_dependent_informationのサイズは、エリアＡ５のsubunit_dependent_lengthによって示される。
【０１５１】
５−３．Object List Descriptor
上記root_object_List_idによって指定されるRoot Contents List（root object list）は、図３２に示すObject List Descriptorとしての構造を有する。全てのObject Listは、この図に示すのと同様の基本構造を有している。また、Root Contents Listの階層下には、後述するようにして、object entry[0]-[n-1]内のchild_list_IDにより指定可能なChild Contents Listが置かれるのであるが、このChild Contents Listもまた、図３２に示すObject List Descriptorとしての構造を有する。
【０１５２】
このObject List Descriptorにあっては、次に述べていくように、先ず、データ構造の冒頭部分に対しては、Subunit Identifier Descriptorにおいて基となるような情報の格納されるいくつかのエリアが配置されるものとしている。そしてこれに続けて、object entry群が配置されるものとしている。
【０１５３】
図３２に示すObject List Descriptorにおいて、先頭のaddress=0000h-0001hが示すエリアＡ１１は、descriptor_lengthとされる。
このdescriptor_lengthには、このdescriptor_length自体を除外した、以降のObject List構造のデータサイズをバイト数によって示すための値が格納される。
【０１５４】
続くaddress=0002hにより示されるlist_typeのエリアＡ１２には、当該Object
List Descriptorの種類（タイプ）を示す値が格納される。
そして、このlist_typeに格納されるべき値としては、図３３に示すようにして定義される。この図３３に示されるように、list_typeの値が00h-7Fhの範囲では、[general definitions]とされ、この場合には全てのsubunitのタイプについて同一の定義がされることになる。またlist_typeの値が80h-FFhの範囲では[subunit type-dependent]であるとされる。つまり、80h-FFhまでの値がsubunit Listで使用するために割り当てられている
上記80h-FFhの範囲内の各値は、或る特定のlist_typeごとに応じて定義される。つまり、list_typeが或る特定のsubunit typeを示す場合には、上記80h-FFhのうち、そのsubunit typeに固有に設定された値がlist_typeに対して格納されることになる。
【０１５５】
また、図３２のObject List Descriptorにおいて、address=0003hで示されるエリアＡ１３にはattributesが示される。
attributesには、現listの構造に関連する属性としての情報がビットフラグとして格納される。ここでの詳細な定義内容の説明は省略するが、例えば、Ｃｏｎｔｒｏｌｌｅｒ側がこのlistをスキップするかリードすべきかの情報や、現object List Descriptorにおいて、後述するobject entry[0]-[n-1]に対してＩＤが格納されているか否かの情報や、また、object entry[0]-[n-1]に対して、child_list_idが格納されているか否かを示す情報等を表現することができる。
【０１５６】
続くaddress=0004h-0005hにより示されるエリアＡ１４は、size_of_list_specific_informationとされ、ここには、次に位置するlist_specific_informationのサイズをバイト数によって示す。
そして、address=0006h・・・により示されるlist_specific_informationのエリアＡ１５には、list_typeごとに固有となる情報が格納される。
【０１５７】
上記list_specific_informationに続けては、number_of_entryのエリアＡ１６が配置される。このnumber_of_entries(n)には、このlistにおけるentry数が示される。即ち、以降続くobject_entry[0]-[n-1]の総数が示される。
【０１５８】
object_entry[0]-[n-1]の各エリアＡ１７−１〜Ａ１７−ｎには、それぞれ、object_entryとしての情報が格納される。このobject_entryの構造を次に示す。
【０１５９】
５−４．Object Entry
図３４は、object_entry(Object Entry Descriptor)の構造を示している。ここでは、アドレスは、Object List内におけるオフセットアドレス(adress offset)として示されている。
adress offset=00h-01hで示されるエリアＡ２１はdescriptor_lengthとされ、このdescriptor_length自体を除外した、以降のobject_entry構造のデータサイズをバイト数によって示す。
【０１６０】
続くエリアＡ２２のentry_type(address offset=0002h)には、現Object Entry Descriptorの種類を示す値が格納される。このentry_typeが取り得る値の範囲と、その値に応じた定義内容は、図３３に示した内容に準ずる。また、現Object Entry Descriptorが、Disc Subunit Object Entryとされている場合は、subunit type dependentとして定義される80h-FFhの範囲内で、後述するようにしてentry_typeの値が定義されている。
また、ここでのエリアＡ２３におけるattributes(address offset=0003h)の定義としては、先に図３２に示したObject List Descriptorと同様となる。
【０１６１】
エリアＡ２４としてのchild_list_ID(address offset=0004h・・・・)には、現Oobject_entryの階層下にあるとされるchild_list（Child Contents List）のＩＤが格納される。
【０１６２】
続くエリアＡ２５としてのobject_IDには、或る所定範囲内の値を用いて、現object_entryに固有に設定されたＩＤとしての値が格納される。
【０１６３】
続くエリアＡ２６としてのsize_of_entry_specific_informationは、次に配置されるエリアＡ２７としてのentry_specific_informationのサイズをバイト数によって示している。
そして、entry_specific_informationのエリアＡ２７に対しては、現object_entryのタイプに応じて固有な形式によって、現Objectに固有となる所定内容の情報が格納される。
【０１６４】
５−５．Disc Subunit Object
上記説明は「General Subunit Identifier Descriptor」としての一般規定に関するものであった。
Subunit Identifier Descriptorの実際としては、「General Subunit Identifier Descriptor」としてのSubunit_typeがDisc recorder／Playerとして指定された場合に、「Disc Subunit Identifier Descriptor」とされるものである。
そして以降におけるこれまでの説明の続きとしては、この「Disc Subunit Identifier Descriptor」としての内容に対応させていくこととする。
【０１６５】
先に図３４に示したObject Entry Descriptorにおいて、entry_typeとしてDisc Subunitとしての所定値が格納された場合、このObject Entry Descriptorは、Disc Subunit Object Entryとされることになる。
Disc Subunit Object Entryとされる場合に対応するentry_typeとしては、図３５に示すようにして定義されている。
【０１６６】
この図３５において、本実施の形態に関連するentry_typeとしては、例えば矢印によって指し示すAudio Track、及びChild Directory Objectとが挙げられる。
entry_type＝80hとされてAudio Trackが定義された場合には、現object_entryは、オーディオトラックに関する情報が格納されていることを示すことになる。また、entry_type＝90hとされてChild Directory Objectが定義された場合には、現object_entryは、Child Contens Listを指定するchild list IDが格納されていることを示すことになる。
【０１６７】
５−６．Disc Subunit Object entry_specific_information
そして、図３４に示したObject Entryが、Disc Subunit Object Entryとされた場合の、entry_specific_information（図３４：エリアＡ２７）内の基本的構造は、図３６に示すものとなる。
【０１６８】
先ず、adress offset=0000h-0001hで示されるエリアＡ３１は、non_info_block_fields_lengthとされ、ここには、以降続くnon_info_blockエリアとしての合計サイズをバイト数により示す。つまり、図示するように、エリアＡ３３としてのobject_type_specific_non_info_block_fieldsの終端位置までのサイズを示す。
【０１６９】
続くadress offset=0002hで示されるエリアＡ３２は、disc_Subunit_object_attibutesとされ、Disc Subunit Objectに共通とされる所定の属性情報が記述される。
【０１７０】
また、続くadress offset=0003h以降の、エリアＡ３３としてのobject_type_specific_non_info_block_fieldsには、このDescriptorによって表されるDisc Subunit Objectのタイプに固有となる情報が格納される。
【０１７１】
上記object_type_specific_non_info_block_fieldsに続けては、エリアＡ３４としてのinfo_block(infomation block)を１以上配置することができるようにされている。info_blockは、全てのDisc Subunit Object間で共有することができる。
【０１７２】
５−７．Audio Track Object entry_specific_information
そして、先に図３４に示したObject Entryにおいて、エリアＡ２２のentry_typeとして80h(図３５参照）の値が格納されると、そのObject Entryは、Audio Track Object entryとしてのDisc Subunit Object Entryとされることになる。そこで、上記図３６に示したentry_specific_informationが、Audio Track Object entry_specific_informationとされた場合の構造図を図３７に示す。なお、図３７において、図３６と同一とされる内容については同一符号を付して説明を省略する。
【０１７３】
この場合、エリアＡ３１のnon_info_block_fields_length（adress offset=0000h-0001h）及びエリアＡ３２のdisc_Subunit_object_attibutes（adress offset=0002h）に続けては、エリアＡ３５としてのaudio_recording_parameters_info_blockが配置され、これに続けて、エリアＡ３４としてのoptional info blockを配置可能とされる。
ここでの詳しい説明は省略するが、audio_recording_parameters_info_blockには、ディスクに記録されたオーディオトラック、つまりDesciptor上では、Audio Objectの記録に関する所定の情報が格納される。例えば、デジタルオーディオデータのサンプリングレート、サンプルサイズ（量子化ビット数）や、コンプレッションモード、チャンネルモードなどの情報が格納される。
【０１７４】
５−８．Disc Subunit List List_specific_information
続いて、先に図３２に示したObject List DescriptorがDisc Subunit Listとして規定される場合について説明する。
前述もしたように、図３２に示したObject Listのタイプは、エリアＡ１２のlist_typeの値によって定義される。そして、Object Listを特定のDisc Subunit Listとして規定する場合ためのlist_typeとしては、図３８に示すようにして定義されている。
【０１７５】
先に図３３に示したように、list_typeの値は80h〜FFhの範囲により何らかのSubunit typeであることを示すものとされる。そして、Disc Subunit Listのlist_typeとしては、図３８に示すようにして、上記した80h〜FFhの範囲内における所定の値を利用して定義を行っている。
この図に示されるように、list_type=80hであれば、現Object ListはRoot Content Listであることが示される。また、list_type=81hであればChild Contents
Listsであることが示される。
また、補足的に述べておくと、list_type=82hであればRoot Temporary Contents List、list_type=83hであればChild Temporary Contents Lists、=84hであればPerformance Lists、list_type=85hであればSynchronized Performance Lists、list_type=86hであればText Database Listsであることが示される。
list_type=87h以降の値は現状未定義とされている。
【０１７６】
そして、上記図３８に示したlist_type=80h〜86hの何れかの値が設定されて、図３２に示したObject ListがDisc Subunit Listとされた場合の、同じ図３２に示すList_specific_informationの内容としては、図３９に示すものとなる。
【０１７７】
先ず、adress offset=0000h-0001hで示されるエリアＡ４１は、non_info_block_fields_lengthとされ、以降続く、non_info_blockエリアとしてのサイズをバイト数により示す。ここでは、エリアＡ４３とされるlist_type_specific_non_info_block_fieldsの終端位置までのサイズを示す。
【０１７８】
続くadress offset=0002hで示されるエリアＡ４２は、disc_Subunit_object_attibutesとされ、Disc Subunit Objectに共通とされる所定の属性情報が格納される。
【０１７９】
そして、adress offset=0003h以降の、エリアＡ４３としてのlist_type_specific_non_info_block_fieldsには、このDescriptorによって表されるDisc Subunit Listのタイプに固有となる情報が格納される。
【０１８０】
上記list_type_specific_non_info_block_fieldsに続けては、エリアＡ４４としてのinfo_blockを１以上配置可能とされている。
【０１８１】
５−９．Root Contents List
Disc Subunit ListとしてのRoot Contents Listは、現在インストールされているディスクについての各種所要の情報を表すListとされる。このような情報として、Disc Subunit Listには、例えばディスクタイトルやディスクジャケットなどのディスク全体に関連する情報が格納される。また、オーディオトラック、ビデオトラック、デジタルスチル画像などのトラック(object)単位の情報も格納される。
ここで、図４０に、Root Contents Listの構造概念を示しておく。なお、この図に示す構造は、ディスクメディアが階層構造のファイルシステムによりデータを管理していない、いわゆるフラットストレージシステムに対応したものとされる。
この図に示すように、Root Contents Listにあっては、各object entryによって、各種ＡＶobjects（Audio Track,Video Track,Digital Still Image Track)が表現される。これは、或る１つのディスクに記録された全てのＡＶコンテンツを表示現している。
Root Contents List Headerは、次に説明するRoot Contents List List_specific_informationの他に、全てのＡＶ／Ｃのlist_typeに共通のヘッダを参照するようにされる。
【０１８２】
５−１０．Root Contents List List_specific_information
Root Contents List List_specific_informationとは、図３２に示すObject List DescriptorがRoot Contents Listとして定義された場合の、List_specific_information（エリアＡ１５）とされる。そして、このRoot Contents List List_specific_informationは、図４１に示す構造を有する。
【０１８３】
先頭のadress offset=0000h-0001hで示されるエリアＡ５１は、non_info_block_fields_lengthとされ、以降続く、info_block以外のエリアのサイズをバイト数により示す。この場合は、エリアＡ５４としてのdisc_recordable_informationまでのエリアのサイズを示すことになる。
【０１８４】
adress offset=0002hで示されるエリアＡ５２は、disc_Subunit_list_attibutesとされ、Disc Subunit listに共通とされる所定の属性情報が格納される。
【０１８５】
また、adress offset=0003h-0004hで示されるエリアＡ５３はmedia_typeとされる。media_typeは、ディスクに記録される情報のフォーマットを示すものとされる。これは換言すれば、記録層に記録されるデータのフォーマットに基づいて区分されるディスク種別を示す情報となる。
【０１８６】
このmedia_typeは、図４２に示すようにして定義されている。
media_typeは８ビットにより表現され、上位４ビット（ＭＳＢ）と下位４ビット（ＬＳＢ）の組み合わせによってMedia Typeを示す。
ＭＳＢ＝01hでは、ＣＤ方式によるディスクであることが示され、このとき、ＬＳＢ＝01hが組み合わされれば（0101hとされれば）、ＣＤ−ＤＡ(digital audio)であることが示される。またＬＳＢ＝02hはＶｉｄｅｏ−ＣＤのための値として確保されている。また、ＬＳＢ＝0Ehは、上記ＣＤ−ＤＡ、Ｖｉｄｅｏ−ＣＤ以外のＣＤ方式によるディスクであることが示される。例えばＣＤ−ＲＯＭなどがこれにあたる。
【０１８７】
また、ＭＳＢ＝03hでは、ＭＤ方式によるディスクであることが示され、ＬＳＢ＝01hが組み合わされて、0301hとされたのであれば、ＭＤ−ａｕｄｉｏであることが示される。
また、この場合のＬＳＢ＝02hはＭＤ−ｐｉｔｕｒｅのための値として確保されている。また、ここでもＬＳＢ＝0Ehは、上記ＭＤ−ａｕｄｉｏ、ＭＤ−ｐｉｔｕｒｅ以外のＭＤ方式による何らかディスクであることが示される。
【０１８８】
ここで、例えば先に図２（ｂ）（ｄ）に示したＨＤデータが記録された記録層を有する単層ディスク及び複層ディスク、また、図２（ｃ）に示したようにして２層のうちの一方の記録層に対してＨＤデータを記録した記録層を１枚のディスクとして見なした場合、これらのディスクについては、「ＳＡＣＤ：(Super Audio CD)」ともいいわれる。
即ち、上記した各３つのディスクは、少なくとも１つのレイヤーに対して、ＳＡＣＤ方式に従ったフォーマットのデータが記録されているディスクのグループであると見なすことができる。
【０１８９】
そして本実施の形態においては、media_typeとしてＭＳＢ＝05hとされた場合には、そのディスク（若しくは、ディスク内の或る特定のレイヤー）は、ＳＡＣＤ方式であると定義するようにしている。これにより、ＡＶ／Ｃプロトコルにあって、ＳＡＣＤに対応したDisc Subunit Listが存在するものとして規定されることになる。
なお、現状では、ＳＡＣＤ方式のディスクは１種類のみとされていることから、ＬＳＢ＝01hによってもＳＡＣＤであることを示すようにされる。つまり、現状では、media_type=O501hによってＳＡＣＤであることが表される。
【０１９０】
説明を図４１に戻す。
media_typeに続く、adress offset=0005hで示されるエリアＡ５４はdisc_recordable_informationとされる。disc_recordable_informationは、記録可能であるか、或いはライトプロテクトがかかっているのかをフラグにより示す。
【０１９１】
続く、adress offset=0006h・・・以降のエリアＡ５５に配置されるtime_stamp_ info_blockは、例えばこのListが最後に修正されたときのタイムスタンプが格納される。time_stamp_ info_blocは必須とされる。
また、time_stamp_ info_blockに続くエリアＡ５６には、default_play_list_info_blockが配置される。このdefault_play_list_info_blockもまた必須とされ、ＰＬＡＹオペレーション時において、現Listがデフォルトとして使用されることを指定する。
【０１９２】
これに続くoptional info blockとしてのエリアＡ５７には、必要に応じて、他の１以上のinfomation blockとしての情報を格納可能とされている。例えば新たなMedia Typeが出現したり、既存のMedia Typeにあっても、或る仕様に対応した新機能を追加したいときなど、これまでの定義では充分対応できない場合が生じる。このようなときに、所要の情報をoptional info blockとして定義して、エリアＡ５７に格納することができる。
【０１９３】
５−１１．information block
続いて、information block(info_block)について説明する。
図４３は、information blockの基本構造を示している。この図において、先頭のaddress=0000h-0001hで示されるエリアＡ６１のcompound＿lengthには、現information blockのサイズがバイト数によって示される。但し、compound＿lengthのエリアＡ５６自体のサイズはこれには含めないものとされている。
【０１９４】
次のaddress=0002h-0003hで示されるエリアＡ６２は、info_block_typeとされ、現information blockのタイプを示す。
info_block_typeは、図４４に示すようにして大きくは２つに分けられる。0000h-7FFFhまでの値は、general info brock typesに対して割り当てられている。そして、8000h-FFFFhまでの値がsubunit typeに固有となるinfo block typeとして割り当てられる。例えばsubunit typeの場合であれば、各subunit typeの下で定義される各種info blockの各タイプが、8000h-FFFFhの値のうちの何れか１つを利用して定義されていることになる。
【０１９５】
また、図４５に、上記図４４に示したgeneral info brock type（0000h-7FFFh）とinfo block type（8000h-FFFFh）内における、各info block typeの定義内容を示す。なお、ここでは、図４５に示される各info brock typeごとの内容についての説明は省略する。
【０１９６】
図４３において、info_block_typeに続くaddress=0004h-0005hで示されるエリアＡ６３は、primary_fields_lengthとされる。primary_fields_lengthには、次のaddress=0006h以降に配置されるprimary_fieldsのみのデータサイズをバイト数により示す。
【０１９７】
そして、address=0006h以降に配置されるprimary_fieldsとしてのエリアＡ６４には、原則として上記info_block_typeにより示される内容のinformation blockが、例えば１セット格納される。
但し、primary_fieldsのタイプの解釈は、info_block_typeのみに依存しないものとされ、現information blockが存在するテーブル範囲に基づいて解釈することもできる。例えば、information blockがList_specific_information内に有れば、information blockのタイプとしては、そのListのタイプに従うようにもできる。同様にして、information blockがentry_specific_infomationの構造内にあれば、information blockのタイプとしては、そのentryのタイプに従うようにもできるものである。
【０１９８】
primary_fieldsに続けては、secondary_fieldsをオプションとして追加することができる。secondary_fieldsには、１以上のオプショナルなinformation blockが格納される。
【０１９９】
例えば、システムの所定の動作に伴い、Listの階層構造内から或る特定のinformation blockを参照する必要の生じることがある。
この場合には、例えば図４６に示されるようにして目的とするのinformation blockに対しての参照が行われる。
図４６においては、List構造が概念的に示されている。このListにあっては、先ず、Ｌｅｖｅｌ０としての階層に、Object Descriptor0,Object Descriptor1が存在している。そして、Object Descriptor1において、Ｌｅｖｅｌ０の直下にあるとされるＬｅｖｅｌ１の階層に、Information Block A,Information Block Bが存在している。更に、Information Block Bにおいて、Ｌｅｖｅｌ０の直下にあるとされるＬｅｖｅｌ２の階層にInformation Block X,Information Block Yが存在している。
【０２００】
ここでの詳しい説明は省略するが、例えばNew AV/C Descriptor Identifierとして定義される、Info Block specified by posotion in comtainer structureによって示される階層をたどってのポジション指定情報に基づいて、目的のInformation Blockを参照していくことができる。つまり、例えば図４６の場合において目的のInformation Block Xを参照するのであれば、Ｌｅｖｅｌ０からＬｅｖｅｌ２までの階層をたどりながら、指定されるポジションを参照することで、Information Block Xに到達できる。
また、New AV/C Descriptor Identifierとして定義されるinstance_countによってInformation Block(例：third block of type‘x’）を指定する手法も存在する。
【０２０１】
５−１２．Ｒｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄ
また本実施の形態では、図２２に示したＷｒｉｔｅ Ｒｅｑｕｅｓｔ Ｐａｃｋｅｔ（ＡＶ／Ｃコマンドパケット）の１つとして、Ｒｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄを定義することで、Disc Subunit Identifier Descriptorの情報の送受信として、Information Block単位での送受信を行うことが可能とされる。
図４７は、このＲｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄの構造を示している。なお、この図に示すＲｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄとしての構造は、図２２に示したＡＶ／Ｃコマンドパケットにおける、ｄａｔａｆｉｅｌｄ内のｏｐｃｏｄｅ以降に配置されるものである。
【０２０２】
ｏｐｃｏｄｅの８ビットの領域であるエリアＡ７１には、現ＡＶ／ＣコマンドパケットがＲｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄであることを示す値「０６ｈ」が格納される。
これに続くｏｐｅｒａｎｄ［０］（１バイト）以降の所要数のｏｐｅｒａｎｄが連続して形成されるエリアＡ７２には、info_block_refernce_pathが格納される。
info_block_refernce_pathは、このＲｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄにより要求するInformation Blockへのパスが示される。ここでの詳しい説明は省略するが、info_block_refernce_pathは、先に図４６により説明したように、例えば階層（Ｌｅｖｅｌ）をたどって目的のInformation Blockを参照するための所定のデータにより形成される構造を採る。
【０２０３】
info_block_refernce_pathに続くエリアＡ７３は、read_result_statusとされる。
read_result_statusは、オペレーションのステイタスを示す所要の値が格納される。Ｃｏｎｔｒｏｌｌｅｒが、Ｒｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄを使用してInformation Blockの送信要求を行う場合には、read_result_statusに対してはFFhを書き込むようにされる。そして、subunitとしてのＴａｒｇｅｔでは、このＲｅａｄ Ｉｎｆｏ Ｂｌｏｃｋ ｃｏｍｍａｎｄの受信に応答したｒｅｓｐｏｎｃｅを返送する際に、このread_result_statusの値を、オペレーションステータスの結果に応じて更新するようにされる。
info_block_refernce_pathに続くエリアＡ７４は未定義とされる。
【０２０４】
エリアＡ７５としてのdata_lengthには、要求されたInformation Blockに応じて、Ｔａｒｇｅｔから読み出されるべきデータサイズがバイト数によって示される。なお、data_length＝０とされた場合には特別な意味を持ち、この場合には、全てのInformation Block(the header,the primary_fields,and secondary_fields)がＴａｒｇｅｔから読み出されるべきものとして指定される。
【０２０５】
続くエリアＡ７６としてのaddressは、Ｔａｒｇｅｔから読み出されるべきデータ（Information Block）のアドレスを指定するもので、これは、読み出し開始位置を、Information Blockのheaderの先頭からのオフセット値により示すものとされる。
【０２０６】
Ｃｏｎｔｒｏｌｌｅｒが上記図４７に示したＲｅａｄ Ｉｎｆｏ Ｂｌｏｃｋｃｏｍｍａｎｄを送信すると、Ｔａｒｇｅｔからの応答として、ＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｃｅが送信されてくる。このＡＣＣＥＰＴＥＤ ｒｅｓｐｏｎｃｅには、例えば、address（エリアＡ７６）に続くｏｐｅｒａｎｄのエリアに対して、data_length（エリアＡ７５）により指定されたデータサイズのResponse Dataが配置されている。即ち要求を行ったInformation Blockが格納されて送信されてくるものである。
【０２０７】
５−１３．ＳＡＣＤ type
これまで「Disc Subunit Identifier Descriptor」に関して、本実施の形態に関わるとされる内容について説明を行ってきた。
そして、本実施の形態にあっては、ＳＡＣＤ方式としてのメディアに対応して各種機能が実現されるように、先に図４２に示したようにして、Disc Subunit Identifier Descriptorのメディアタイプ（media_type)を定義している。つまり、media_type＝0501hであれば、そのListはＳＡＣＤ typeとして規定され、ＳＡＣＤの属性を示す内容を有するものとされる。
【０２０８】
また本実施の形態としては、ＳＡＣＤ typeとしてのListのディレクトリ下に含まれるInformation Blockのinfo_block_typeを指定するのにあたっては、次のように規定することとしている。
【０２０９】
ここで、先に示した図４５を再度参照する。この図４５には、Information Block Typeについての定義内容が示されている。Information Block Typeの値としては、図４４に示されるとおり、8000h-FFFFhの範囲の値をsubunit typeが使用できるものとしていた。
そして、ＳＡＣＤ typeにあっては、図４５に示されているinfo block typeの定義内容のうち、disc subunitのinfo block typeに使用するためにリザーブされている、info block type=8000h-80FFhまでの範囲の値と、info block type=8800h-FFFFhまでの範囲の値のうちから、実際に定義して設けられるＳＡＣＤ type下でのinfo block typeに応じて、所要の値を使用するものとしている。
【０２１０】
５−１４．ＳＡＣＤ type／Root Contents List List_specific_information
続いて、ＳＡＣＤ typeとされる場合の、Root Contents List List_specific_informationの構造について、図４８を参照して説明する。
この図において、先頭のエリアＡ５１のnon_info_block_fields_lengthからエリアＡ５６のdefault_play_list_info_blockまでのエリアは、図４１と同様とされることからここでの説明は省略する。
但しこの場合、エリアＡ５３のmedia_typeに対しては、ＳＡＣＤであることを示す0105hの値（図４２参照）が格納されることになる。
【０２１１】
そして、このＳＡＣＤ typeのRoot Contents List List_specific_informationにあっては、図４１においてother optional info blocksとして示されたエリアＡ５７に対して、ＳＡＣＤに対応した次のInformation Blockが配置されていくことになる。
【０２１２】
先ずエリアＡ５７の先頭に配置されるエリアＡ５７−１は、album_set_info_blockとされる。
ＳＡＣＤとしてのディスク、つまりＨＤデータが記録されるＨＤレイヤー１０２にあっては、図５（ｂ）（ｃ）により説明したようにして、マスターＴＯＣに対して、アルバム情報が格納されている。上記album_set_info_blockには、このアルバム情報に基づく情報として、アルバムを成す「アルバムディスク枚数」、及びアルバムを成すディスクごとに付される通し番号である「アルバム内ディスク識別番号」に対応した情報が格納される。なお、このalbum_set_info_blockの構造は、図４９を参照して後述する。
【０２１３】
エリアＡ５７−１に続くエリアＡ５７−２には、album_catalog_code_info_blockが配置される。
このalbum_catalog_code_info_blockには、アルバム単位で固有となるように設定されたＩＤが、album_catalog_codeとして格納される。また、album_catalog_code_info_blockの構造についても、図５０を参照して後述する。
【０２１４】
次のエリアＡ５７−３は、disc_catalog_code_info_blockとされ、ディスク単位（但しハイブリッドディスクの場合にはＨＤレイヤー単位）で固有となるように設定されたＩＤがdisc_catalog_codeとして格納される。
【０２１５】
エリアＡ５７−４はname_info_blocck(album)とされ、アルバムタイトルの情報が格納される。そして、エリアＡ５７−５ はname_info_blocck(disc)とされ、ディスクタイトルの情報が格納される。
また、これに続くエリアＡ５７−６は、other info blocksとされて、必要があれば他のアルバム、又はディスクに関するinformation blockが格納される。
【０２１６】
album_set_info_block
図４９にalbum_set_info_blockの構造を示す。この図に示す構造は、先に図４３に示したinfo_blockの構造に従っており、図４３と同一とされるエリアについては同一符号を付し、同一内容については説明を省略する。
【０２１７】
この場合、エリアＡ６２のinfo_block_typeには、このInfomation Blockがalbum_set_info_blockであることを示す特定の値（8XXXh）が格納される。そして、エリアＡ６３のprimary_fields_lengthに続くprimary_fieldsとしてのエリアＡ６４において、先ず、先頭のaddress=0006h-0007hの２バイトのエリアＡ６４−１に対して、number_of_album_setの情報が格納される。このnumber_of_album_setとしての値が「アルバムディスク枚数」を示す。
そして、エリアＡ６４−１に続く、address=0008h-0009hのエリアＡ６４−２に対して、「アルバム内ディスク識別番号」を示すnumber_of_album_sequenceが格納される。
【０２１８】
album_catalog_code_info_block
続いて、図５０にalbum_catalog_code_info_blockの構造を示す。この図に示す構造も、先に図４３に示したinfo_blockの構造に従っており、図４３と同一とされるエリアについては同一符号を付し、同一内容については説明を省略する。
【０２１９】
この場合にも、エリアＡ６２のinfo_block_typeには、このInfomation Blockがalbum_catalog_code_info_blockであることを示す特定の値（8XXXh）が格納される。
【０２２０】
そしてこの場合には、primary_fieldsとされるエリアＡ６４において、先ず、先頭のaddress=0006h-0007hの２バイトのエリアＡ６４−１に対して、album_catalog_code_lengthの情報が格納される。ここには次に配置されるエリアＡ６４−２のalbum_catalog_codeのデータサイズがバイト数によって示される。album_catalog_codeの情報は可変長とされているため、このようにして、先ず、album_catalog_codeのデータサイズを示す必要がある。
そして、続くaddress=0008h以降のエリアＡ６４−２に対して、アルバム単位についてのＩＤとして機能するalbum_catalog_codeの情報が格納される。
【０２２１】
５−１５．ＳＡＣＤ type／Audio Track Object entry_specific_information
続いて、ＳＡＣＤ typeとされる場合の、Audio Track Object entry_specific_informationの構造について、図５１を参照して説明する。この図に示す構造は図３７に示したAudio Track Object entry_specific_informationの構造に従っている。そこで、図３７と同一エリアについては同一符号を付し、その説明が重複するものについては、ここでの説明は省略する。
【０２２２】
図５１に示す構造において、図３７においてoptional info blocksとされたエリアＡ３４に対しては、ＳＡＣＤに記録されたオーディオトラックに関する情報として以下の各Infomation Blockが格納される。
【０２２３】
先ず、先頭のエリアＡ３４−１には、size_indicator_info_blockが配置され、以下続けて、エリアＡ３４−２のSACD_specific_info_block、エリアＡ３４−３のAV_content_identifier_info_block、エリアＡ３４−４のname_info_blockが配置される。また、エリアＡ３４−４に続くエリアＡ３４−５はother_info_blockとされて、必要があればオーディオトラックに関する他のInfomation Blockを追加することが可能とされている。
ここで、本実施の形態としての特徴となるのが、エリアＡ３４−２のSACD_specific_info_blockとされる。
【０２２４】
ＳＡＣＤでは、図５に示したように、そのデータゾーンに対して、２チャンネルよりも多いマルチチャンネルによるＨＤデータが記録されるマルチチャンネルエリア（Multichannel Area）が設けられる。そして、マルチチャンネルエリアに記録されるエリアＴＯＣには、スピーカレイアウトを指定するスピーカレイアウト情報が格納されている。
上記したエリアＡ３４−２のSACD_specific_info_blockには、内容的には、このエリアＴＯＣにおけるスピーカレイアウトを指定する情報と同一とされる情報が格納される。つまり、SACD_specific_info_blockによって、そのトラックについて指定されたスピーカレイアウトを識別することができるものである。
【０２２５】
そして、上記SACD_specific_info_blockは、図５２に示す構造を有する。
この図に示す構造は、先に図４３に示したinfo_blockの構造に従う。また、この図においても図４３と同一とされるエリアについては同一符号を付し、その説明が重複するものについては、ここでの説明を省略する。
【０２２６】
図５２において、エリアＡ６２のinfo_block_typeには、このInfomation BlockがSACD_specific_info_blockであることを示す特定の値（8XXXh）が格納される。
【０２２７】
そしてこの場合には、エリアＡ６４とされるprimary_fieldsにおいて、先ず、先頭のaddress offset=0006hにより示される１バイトのエリアＡ６４−１に対して、SACD_specific_typeが配置される。SACD_specific_typeには、現SACD_specific_info_blockに記述される情報内容のタイプごとに固有に設定された値が格納されるのであるが、ここでは、SACD_specific_typeが、前述したスピーカレイアウトであることが示される。
そして、SACD_specific_typeに続く、address offset=0007h以降のエリアＡ６４−２に対して、SACD_specific_type_informationが格納される。即ち、この場合であれば、SACD_specific_type_informationとしては、スピーカレイアウトを具体的に示す情報が格納されることになる。
【０２２８】
５−１６．ＳＡＣＤ typeのDisc Subunit Identifier Descriptor
これまでの説明のまとめとして、media_typeについてＳＡＣＤ typeとされた場合のDisc Subunit Identifier Descriptorの構造を図５３に示す。
例えば図５３（ａ）に示すDisc Subunit Identifier Descriptorにおけるroot_object_list_id_0により、図５３（ｂ）に示すRoot Contents Listを指定しているとする。そして、このRoot Contents Listとしては、その構造内に配置されるlist_specific_information内のmedia_typeの値が0510hとされることで、ＳＡＣＤ typeであるものとして定義されているとする。
この場合、Root Contents Listが有するlist_specific_informationには、図５３（ｃ）に示すようにして、album_set_info_blockとalbum_catalog_code_info_blockが格納されることになる。つまり、Root Contents List内には、アルバム情報を示すInfomation Blockが格納されていることになる。そして、先の図４８〜図５０を参照した説明によれば、album_set_info_block、及びalbum_catalog_code_info_blockによって、「アルバムディスク枚数」、「アルバム内ディスク識別番号」、及びアルバムに固有となるＩＤを有することができることになる。つまり、ＳＡＣＤに特有とされる、アルバム情報をDisc Subunit Identifier Descriptorに持つことができるものである。
【０２２９】
また、例えば図５３（ｂ）に示すRoot Contents ListのChild_Directory_Object[0]によって図５３（ｄ）に示すChild Contents Listを指定しているとする。このChild Contents Listは、ＳＡＣＤ typeの階層下にある。
そして、このChild Contents Listが有するAudio_Track_Objectにおいて、ここに含まれるoptional info blocks内のAudio Track Object entry_specific_informationにあっては、図５３（ｅ）に示すようにして、SACD_specific_info_blockが格納されることになる。このSACD_specific_info_blockは、先に図５１及び図５２により説明したように、マルチチャンネルオーディオトラックに対応したスピーカレイアウトの情報を示す。
【０２３０】
このようにして、本実施の形態のDisc Subunit Identifier Descriptorにあっては、ＳＡＣＤ、即ちＨＤレイヤーに固有となる、アルバム情報、及びスピーカレイアウト等の情報を有するようにされる。
これにより、インストールされたディスクがＳＡＣＤである場合としては、Ｃｏｎｔｒｏｌｌｅｒでは、これらのＳＡＣＤに固有なDisc Subunit Identifier Descriptor内の情報を要求して取得することで、ＳＡＣＤならではとされる機能を実現することができる。
【０２３１】
一例として、例えば本実施の形態のディスクプレーヤ０が複数枚のディスクを自動的に交換して再生可能ないわゆるチェンジャ機能を有しているとすれば、Ｃｏｎｔｒｏｌｌｅｒからのリモート制御によって、アルバムを成す複数枚のディスクを、ユーザの所望の再生順によって再生するといったことが可能とされる。このときには、album_set_info_block及びalbum_catalog_code_info_blockの情報が利用される。
また、SACD_specific_info_blockを利用した機能としては、例えば、本実施の形態のＡＶシステムにＡＶアンプを接続し、このＡＶアンプをリモート制御することで、マルチチャンネルのオーディオトラックの再生時には、自動的にスピーカレイアウトを切り換えることなどができる。
【０２３２】
５−１７．ハイブリッドディスクのDisc Subunit Identifier Descriptor
ところで、図２（ｃ）に示したハイブリッドディスクは、ＣＤレイヤー１０１とＨＤレイヤー１０２との２つの記録層を有している。つまり、Disc Subunit Identifier Descriptorとしての概念から見た場合には、異なるメディア(media_type)のListが並列的に存在することになる。
従来、異なるフォーマットのオーディオデータが１つのディスクに混在するということは無かったとされるため、基本的に、Disc Subunit Identifier Descriptorは、１つのディスクフォーマット（media_type)に対応することを前提として、そのフォーマットが規定されていたものである。
しかし、上記のようなハイブリッドディスクの出現によって、１つのディスクに複数のディスクフォーマット、即ちボリュームが存在する場合にも、対応できるようにする必要が生じてきている。
【０２３３】
そこで、本実施の形態においては、１つのディスクに複数のディスクフォーマット、即ちボリュームが存在する場合には、次に述べるようにしてDisc Subunit
Identifier Descriptorを作成するように提案する。
ここでは、先に図２（ｃ）に示したレイヤー構造を有するハイブリッドディスクがインストールされた場合を例に挙げる。
【０２３４】
図５４は、図２（ｃ）に示したハイブリッドディスクに対応して作成されるDisc Subunit Identifier Descriptorの構造を示している。
この場合には、図５４（ａ）に示すDisc Subunit Identifier Descriptorにおけるroot_object_list_id_0により、図５４（ｂ）に示すCD_Root Contents Listを指定し、root_object_list_id_1により、図５４（ｃ）に示すSACD_Root Contents Listを指定しているものとする。
つまり、この構造では、Root Contents Listとして、ＣＤレイヤー１０１に対応するCD_Root Contents Listと、ＨＤレイヤー１０２に対応するSACD_Root Contents Listとが階層構造的には並列に設けられるものである。
【０２３５】
このような構造を実現するため、先ず、本実施の形態では、図５４（ｂ）に示すCD_Root Contents List内に配置されるlist_specific_information内のmedia_typeに対しては、ＣＤであることを示す0101hを格納し、また、図５４（ｃ）に示すSACD_Root Contents List内に配置されるlist_specific_information内のmedia_typeに対しては、ＳＡＣＤであることを示す0501hを格納するようにされる。
つまり、ここではＣＤレイヤー１０１を１つのＣＤというメディアとして扱い、同様にしてＨＤレイヤー１０２を１つのＳＡＣＤというメディアとして扱うものである。
【０２３６】
これにより、図５４（ｂ）に示すCD_Root Contents Listには、ＣＤレイヤー１０１の記録内容に対応する情報を記述することができ、また、図５４（ｃ）に示すSACD_Root Contents Listには、ＨＤレイヤー１０２の記録内容に対応する情報を記述することができる。
そして、これらのＣＤレイヤー１０１とＨＤレイヤー１０２との各々に対応するRoot Contents Listを、ＡＶ／Ｃプロトコルの規定に矛盾することなく併存させることが可能となる。
つまり、１つのディスクと対応付けて作成されるべき１つのDisc Subunit Identifier Descriptor内に、ＣＤ−ＤＡタイプのメディア（ＣＤレイヤー）と、ＳＡＣＤタイプ（ＨＤレイヤー）のメディアに関する内容が記述されるものである。
【０２３７】
そして、図５４（ｂ）に示すCD_Root Contents Listのディレクトリ下において、例えばそのChild_Directory_Object[0]によって指定される、図５４（ｄ）のChild Contents Listは、ＣＤレイヤー１０１に記録されたオーディオトラックについてのlist_specific_infomaton、及びAudio Track Object[0]〜[n]を有することができることになる。
同様に、図５４（ｃ）に示すSACD_Root Contents Listのディレクトリ下において、例えばそのChild_Directory_Object[0]によって指定される、図５４（ｅ）のChild Contents Listは、ＨＤレイヤー１０２に記録されたオーディオトラックについてのlist_specific_infomaton、及びAudio Track Object[0]〜[n]を有することができることになる。
【０２３８】
また、ＳＡＣＤ（ＨＤレイヤー）とＣＤ−ＤＡ（ＣＤレイヤー）が混在する状況となったことに対応して、Contents Listのlist_typeとしては、図５５に示すようにして定義することとした。
この図に示すように、Contents ListがRoot Contentsとされる場合として、CD_Root Contents Listについてはlist_id＝1000hと定義し、SACD_Root Contents Listについては、list_id＝2000hと定義することとしている。
更に、Contents ListがChild Contentsとされる場合として、ＳＡＣＤ（ＨＤレイヤー）の２チャンネルステレオエリアに記録されるトラックに関するAudio Track Objectを有するChild Contents Listについては、list_id＝2001hと定義し、ＳＡＣＤ（ＨＤレイヤー）のマルチチャンネルエリアに記録されるトラックに関するAudio Track Objectを有するChild Contents Listについては、list_id＝2002hと定義することとしている。
【０２３９】
従って、図５４に示す場合であれば、先ず図５４（ｂ）に示すように、CD_Root Contents List内のlist_typeにはlist_id=1000hを格納し、また、図５４（ｃ）に示すように、SACD_Root Contents List内ののlist_typeにはlist_id=2000hを格納するようにされる。
また、図５４（ｅ）に示すSACD_Root Contents Listのディレクトリ下のChild Contents Listが、ＳＡＣＤ（ＨＤレイヤー）の２チャンネルステレオエリアに記録されるトラックに関するAudio Track Objectを有するとすれば、このChild Contents List内のlist_typeにはlist_id=2001hを格納し、ＳＡＣＤ（ＨＤレイヤー）のマルチチャンネルエリアに記録されるトラックに関するAudio Track Objectを有するとすれば、このChild Contents Listのlist_typeにはlist_id=2002hを格納することになる。
【０２４０】
６．Disc Subunit Identifier Descriptor作成処理
本実施の形態のディスクプレーヤ０の実際としては、図２に示した４種のディスクのそれぞれに応じてDisc Subunit Identifier Descriptorを作成することが必要とされる。そこで、以下、ディスクプレーヤ０においてこれら４種のディスクごとに対応してDisc Subunit Identifier Descriptorを作成するための処理動作について、図５６〜図５８を参照して説明する。なお、図５６〜図５８の各図に示す処理は、システムコントローラ１１が実行する。
【０２４１】
例えば、ディスクプレーヤ０に対してディスクが装填されると、システムコントローラ１１は、その後の所定の機会においてDisc Subunit Identifier Descriptorを作成するために、図５６に示す処理を実行する。
【０２４２】
図５６においては、先ずステップＳ１０１において、現在装填されているディスクの種別についての判別を行う。このディスク種別の判別は、例えば図７にて説明したようにして、判別信号生成部２０から入力された判別信号に基づいて行うようにされる。
【０２４３】
ステップＳ１０１において、ディスク種別がＣＤ−ＤＡ（図２（ａ））であると判別された場合には、ステップＳ１０２の処理に進む。
ステップＳ１０２においては、装填されているＣＤ−ＤＡのリードインエリアに対するデータ読み出しを実行させることで、ＴＯＣ（ＣＤ−ＴＯＣ）を読み込むための処理を実行する。そして例えばこの読み込みを行ったＴＯＣを、システムコントローラ１１内のＲＡＭ１１ａに書き込んで保持させる。
但し、例えば既にＣＤ−ＤＡを再生して読み込んだＴＯＣが、ＲＡＭ１１ａに対して保持されている状態にあれば、ステップＳ１０２の処理としては、このＲＡＭ１１ａに保持されているＴＯＣを参照すればよい。この点については、以降説明することとなる、ステップＳ１０４と，ステップＳ１０６，Ｓ１０７と、ステップＳ１０９，Ｓ１１０の各ＴＯＣ読み込み処理についても同様とされる。
【０２４４】
次のステップＳ１０３においては、上記ステップＳ１０２において読み込んだＴＯＣの内容に基づいて、Disc Subunit Identifier Descriptorを作成する。なお、ここで作成されるのは、図５４に示すDisc Subunit Identifier Descriptorの構造において、図５４（ａ）→図５４（ｂ）→図５４（ｄ）の階層構造を抜き出すようにして得られるＣＤ−ＤＡタイプのみとしてのDisc Subunit Identifier Descriptorとされる。
【０２４５】
また、ステップＳ１０１において、単層ＨＤディスク（図２（ｂ））であることが判別された場合には、ステップＳ１０４に進む。
ステップＳ１０４においては、単層ＨＤディスクのＨＤレイヤー１０２に記録されているマスターＴＯＣ、及びエリアＴＯＣを読み込むための処理を実行する。
【０２４６】
そして、次のステップＳ１０５において、上記のようにして読み込みを行って取得したマスターＴＯＣ、及びエリアＴＯＣの内容に基づいて、ＳＡＣＤタイプのDisc Subunit Identifier Descriptorを作成するための処理を実行する。つまり、先に図５３に示した内容及び構造によるDisc Subunit Identifier Descriptorを作成する。
【０２４７】
この際、例えばlist_type、media_typeなどのエリアには、先に図５５や図４２に示した定義内容のうち、ＳＡＣＤに対応した値を格納するようにされる。また、特にChild Contents Listについては、前述したように、２チャンネルステレオエリアに対応するChild Contents Listと、マルチチャンネルエリアに対応するChild Contents Listとの２つが作成され、これら各Child Contents ListのAudio_Track_Object[0]〜[n-1]に対しては、エリアＴＯＣの内容に従って、そのチャンネルエリアに記録されているオーディオトラックの情報を作成して格納するようにされる。
【０２４８】
ところで、先にも述べたように、本実施の形態では、ＳＡＣＤタイプとしてのDisc Subunit Identifier Descriptorには、マスターＴＯＣに記録されたアルバム情報が反映される。そこで、特に、アルバム情報に基づいた作成処理という視点から見た場合のステップＳ１０５としての処理を図５７に示しておく。
【０２４９】
図５７においては、先ずステップＳ２０１において、album_set_info_block（図４９参照）を作成するための処理を実行する。このalbum_set_info_blockの作成にあたっては、マスターＴＯＣにおけるアルバム情報のうち、「アルバムディスク枚数」の情報を利用して、number_of_album_setの情報を作成する。また、「アルバム内ディスク識別番号」利用して、number_of_album_sequenceを作成するようにされる。そして、最終的には図４９に示したテーブル構造のデータを作成するものである。
【０２５０】
また次のステップＳ２０２においては、マスターＴＯＣにおけるアルバム情報のうちから所要の情報を組み合わせて利用することで、現在装填されているディスクを含むアルバムを特定することのできる情報を作成する。これが図５０に示されるalbum_catalog_code_info_block内のalbum_catalog_codeとされる。そして、このようにして作成したalbum_catalog_codeと共に、最終的にalbum_catalog_code_info_blockとしてのデータ構造を作成する。
【０２５１】
次のステップＳ２０３においては、特に、マルチチャンネルエリアのエリアＴＯＣの内容に基づいて、SACD_specific_info_block（図５２参照）を作成する。マルチチャンネルエリアのエリアＴＯＣには、各オーディオトラックごとの情報として、スピーカレイアウト情報が記録されているものであるが、このステップＳ２０３においてはこのスピーカレイアウト情報に基づき、スピーカレイアウトを指示する内容のSACD_specific_type_informationを作成し、更にこれを含めて各Audio Track ObjectのSACD_specific_info_blockを作成するようにされる。
【０２５２】
そして、次のステップＳ２０４においては、上記ステップＳ２０１，Ｓ２０３，Ｓ２０４により作成された、album_set_info_block、album_catalog_code_info_block、及びSACD_specific_info_blockを、適宜所定のエリアに対して格納することで、ＳＡＣＤタイプのDisc Subunit Identifier Descriptorを作成する。
【０２５３】
また、図５６に示すステップＳ１０１において、複層ＨＤディスクであることが判別された場合には、ステップＳ１０６に進む。
複層ＨＤディスクは、２つのＨＤレイヤー１０２を有していることから、例えば先ずステップＳ１０６により、第１ＨＤレイヤー（例えば第１記録層としてのＨＤレイヤー）に記録されているマスターＴＯＣ及びエリアＴＯＣを読み出すようにされる。
そして、次のステップＳ１０７において、第２ＨＤレイヤー（例えば第２記録層としてのＨＤレイヤー）に記録されているマスターＴＯＣ及びエリアＴＯＣを読み出すようにされる。
【０２５４】
このようにして、２つのＨＤレイヤーからマスターＴＯＣ及びエリアＴＯＣを読み出した後はステップＳ１０８のDisc Subunit Identifier Descriptor作成処理に移行する。この場合ＨＤレイヤーは２層であるが、１つのボリュームとして扱うことができるものとされており、従って、ステップＳ１０８の処理としては、例えば先に説明したステップＳ１０５の処理と同様とされてよい。
【０２５５】
また、ステップＳ１０１においてハイブリッドディスクであることが判別された場合にはステップＳ１０９に進む。
ハイブリッドディスクにはＣＤレイヤー１０１とＨＤレイヤー１０２との２層が形成されている。そこで、ステップＳ１０９においては、先ず、ＨＤレイヤー１０２からマスターＴＯＣ、及びエリアＴＯＣを読み込むための処理を実行する。
そして次のステップＳ１１０において、ＣＤレイヤー１０１に記録されているＴＯＣ（ＣＤ−ＴＯＣ）を読み込むための処理を実行する。
以上、上記ステップＳ１０９及びＳ１１０の処理によって、ＳＡＣＤ（ＨＤレイヤー）のＴＯＣ情報と、ＣＤ−ＤＡ（ＣＤレイヤー）のＴＯＣ情報とが取得されたことになる。
【０２５６】
次のステップＳ１１１においては、上記のようにして取得した上記各ＴＯＣの内容に基づき、Disc Subunit Identifier Descriptorを作成する。
ここで作成されるのは、図５４に示す構造及び内容のDisc Subunit Identifier Descriptorとされる。
【０２５７】
このステップＳ１１１としての処理は、例えば図５８に示すようにして実行される。
図５８においては、先ずステップＳ３０１において、ＳＡＣＤボリュームDescriptorを作成するものとしている。ここでいうＳＡＣＤボリュームDescriptorとは、図５４に示す構造を例に挙げれば、Root_object_list_id_1（図５４（ａ））により指定されるSACD_Root Contents List（図５４（ｃ））、及びその階層下のChild Contents List（図５４（ｅ））より成る構造を指す。
つまりは、ＨＤレイヤー１０２から取得したマスターＴＯＣ及びエリアＴＯＣの内容に従って、図５４（ｃ）（ｅ）に示されるような階層構造による、ＳＡＣＤタイプのContents Listを作成するものである。
【０２５８】
そして、次のステップＳ３０２においては、ＣＤレイヤー１０１から読み込んだＴＯＣの内容に基づいてＣＤボリュームDescriptorを作成する。ここでのＣＤボリュームDescriptorとは、図５４の場合であれば、Root_object_list_id_0（図５４（ａ））により指定されるCD_Root Contents List（図５４（ｂ））、及びその階層下のChild Contents List（図５４（ｄ））より成る構造を指すものである。つまり、ステップＳ３０２では、これらCD_Root Contents Listとその階層下のChild Contents Listを作成するものである。
この際には、例えば図５４にも示したように、CD_Root Contents List（図５４（ｂ））の構造内のlist_typeにはList_id=1000h（ＣＤ−ＤＡ）を格納し、media_typeのエリアには0101h（ＣＤ−ＤＡ）を格納することで、実際にCD_Root Contents Listであることが定義されるようにする。同様にして、SACD_Root Contents List（図５４（ｃ））の構造内のlist_typeにはList_id=2000h（ＳＡＣＤ）を格納し、media_typeのエリアには0501h（ＳＡＣＤ）を格納することで、実際にCD_Root Contents Listであることが定義されるようにする。
【０２５９】
図５６に示す処理において、ステップＳ１０３，Ｓ１０５，Ｓ１０８，Ｓ１１１の何れかを実行した後は、ステップＳ１１２に進む。
ステップＳ１１２においては、上記ステップＳ１０３，Ｓ１０５，Ｓ１０８，Ｓ１１１の何れかの処理を経たことによって作成されたDisc Subunit Identifier Descriptorを、ＲＡＭ１１ａに書き込んで保持させるための処理を実行する。これ以降、Ｃｏｎｔｒｏｌｌｅｒ（例えばパーソナルコンピュータ）が、当該ディスクプレーヤ０をＴａｒｇｅｔと見なして、Disc Subunit Identifier Descriptorを要求してきた場合には、システムコントローラ１１は、この要求に応答したDisc Subunit Identifier DescriptorをＲＡＭ１１ａから読み出して送信することが可能になる。
【０２６０】
７．Disc Subunit Identifier Descriptorの送信処理
続いて、システムコントローラ１１が実行するDisc Subunit Identifier Descriptorの送信処理について、図５９及び図６０に示すフローチャートを参照して説明する。
先ず図５９には、Disc Subunit Identifier Descriptor全体を送信する場合の処理が示されている。ここで、Disc Subunit Identifier Descriptor全体の送信を要求するためのＡＶ／Ｃコマンドとしては、ＲＥＡＤ ＤＥＳＣＲＩＰＴＯＲｃｏｍｍｎａｄが定義されているものとする。そして、この処理にあっては、図６に示したシステム構成を例に挙げるとすれば、ディスクプレーヤ０がＴａｒｇｅｔとなり、パーソナルコンピュータ２００がＣｏｎｔｒｏｌｌｅｒとして機能することになる。
【０２６１】
図５９に示す処理にあっては、システムコントローラ１１は、先ずステップＳ４０１において、Ｃｏｎｔｒｏｌｌｅｒから送信されてくるＲＥＡＤ ＤＥＳＣＲＩＰＴＯＲ ｃｏｍｍｎａｄが受信されるのを待機している。そして、このコマンドが受信されたことが判別されるとステップＳ４０２に進んで、Disc Subunit Identifier Descriptor全体のデータをＡＶ／Ｃコマンドパケット化するための処理を実行する。
つまり、図２２に示したＡＶ／Ｃコマンドパケットとして、ＲＥＡＤ ＤＥＳＣＲＩＰＴＯＲ ｃｏｍｍｎａｄに応答するｒｅｓｐｏｎｃｅであることが表されるＰａｃｋｅｔ Ｈｅａｄｅｒの内容を作成し、また、Disc Subunit Identifier Descriptorとしての１纏まりの構造をｏｐｅｒａｎｄに付加したｄａｔａ ｂｌｏｃｋを作成するようにされる。
そして、次のステップＳ４０３において、上記ステップＳ４０２にて作成されたＡＶ／Ｃコマンドパケットを送信出力する。つまり、このＡＶ／Ｃコマンドパケットが、ＩＥＥＥ１３９４バス１１６に接続されたＣｏｎｔｒｏｌｌｅｒに送信出力されるように、ＩＥＥＥ１３９４インターフェイス部１４についての動作制御を実行するものである。
【０２６２】
また、本実施の形態のＡＶシステムとしては、先に図４７に示したＲＥＡＤ ＩＮＦＯ ＢＬＯＣＫ ｃｏｍｍａｎｄを利用すれば、Disc Subunit Identifier Descriptorにおける特定のInfomaition Blockを指定して送受信することが可能とされる。
このＲＥＡＤ ＩＮＦＯ ＢＬＯＣＫ ｃｏｍｍａｎｄの受信に応じたシステムコントローラ１１の処理動作としては、図６０に示すものとなる。
【０２６３】
図６０に示す処理にあっては、先ずステップＳ５０１において、Ｃｏｎｔｒｏｌｌｅｒから送信されてくるＲＥＡＤ ＩＮＦＯ ＢＬＯＣＫ ｃｏｍｍａｎｄの受信を待機しており、このコマンドを受信すると、ステップＳ５０２に進む。
【０２６４】
ステップＳ５０２においては、受信したＲＥＡＤ ＩＮＦＯ ＢＬＯＣＫ ｃｏｍｍａｎｄに格納されているinfo_block_refernce_path、data_length、addressなどの情報に基づいて、要求されたInformation Block、即ちＴａｒｇｅｔから読み出されるべきデータを特定する。そして、次のステップＳ５０３において、この特定されたInformation BlockをＡＶ／Ｃコマンドパケット化する。つまり、図４７においても説明したように、受信したＲＥＡＤ ＩＮＦＯ ＢＬＯＣＫ ｃｏｍｍａｎｄのread_result_statusを処理結果に応じて更新すると共に、ｏｐｅｒａｎｄに対して、上記特定されたInformation Blockを格納するものである。そして、続くステップＳ５０４の処理により、上記のようにして更新したＲＥＡＤ ＩＮＦＯ ＢＬＯＣＫ ｃｏｍｍａｎｄを、ｒｅｓｐｏｎｃｅとしてＣｏｎｔｒｏｌｌｅｒに対して送信出力する。
【０２６５】
ところで、上記実施の形態にあっては、図５４に示すような複数のmedia typeのLISTが格納されるDisc Subunit Identifier Descriptorは、図２（ｃ）に示した形態のハイブリッドディスクに対応しているものとされる。つまり、記録フォーマットが異なるボリューム単位としての記録情報が、物理的に異なるレイヤーとして設けられているディスクに対応している。本発明は、このように１つの記録媒体が物理的に複数のボリュームを有する場合の他、例えば同一レイヤーにおいて、論理的に複数のボリュームを有するようにされたディスクであっても適用が可能とされる。
【０２６６】
また、本発明としての概念は、インストールされたディスクが、図２に例示したディスクである場合に限定されるものではなく、本実施の形態として示したＨＤデータやＣＤ−ＤＡのフォーマット以外のデジタルオーディオデータが記録される記録層（ボリューム）を有するディスクであっても構わない。
また、ディスクに記録されるデータとしては、当然のこととして例えばビデオデータなど、オーディオデータ以外であってもよいものである。更には、本発明が対応し得るメディアとしてはディスクメディアにも限定されるものではなく、例えばテープメディアや、近年普及しつつあるメモリ素子を用いたメディアなどにも適用できる。
また、上記実施の形態としての再生装置は再生専用メディアに対応するものとされるが、これも当然こととして、データの追記又は書き換えが可能なメディアに対応して記録再生が可能な装置にも適用可能である。
更には、本発明としては、ＩＥＥＥ１３９４の規格以外のデジタルデータインターフェイスに対しても適用が可能である。
【０２６７】
【発明の効果】
以上説明したように本発明は、例えばハイブリッドディスクなどといわれる、記録フォーマットが異なる複数の記録情報が記録される記録媒体が存在する場合に、このような記録媒体に関する記述情報を、所定の伝送フォーマットに対応させて作成するのにあたっては、各記録情報に対応した記述内容は、それぞれ異なる記録媒体のタイプ(media type)として定義された情報単位(Contents List)として管理されるようにしている。
また、このようにして作成された記述情報を上記所定の伝送フォーマットに従ったデータバスを介して送信するようにもされる。
【０２６８】
このような構成であれば、例えば記録フォーマットを記録媒体のタイプとして扱っている記述情報の規格であっても、上記ハイブリッドディスクなどのようなハイブリッドメディアに記録された複数ボリュームを、本来１つの記録媒体に対応付けられるべき１つの記述情報の構造内で表現することが可能とされる。そして、所定の伝送フォーマットに従ったデータバスにより接続される機器間で、ハイブリッドメディアに対応した各種機能を実現することができる。つまり、これまでには存在しなかったようなハイブリッドメディアに特化された機能の拡充が図られるものである。
【図面の簡単な説明】
【図１】本発明の実施の形態の再生装置が対応可能なディスクの記録層構造の説明図である。
【図２】実施の形態の再生装置が対応可能なディスクの種別の説明図である。
【図３】実施の形態の再生装置が対応可能なディスクの記録層形成位置の説明図である。
【図４】本実施の形態の再生装置が対応するハイブリッドディスクの記録層のゾーン構造を示す説明図である。
【図５】ＨＤレイヤーのゾーン構造を示す説明図である。
【図６】本実施の形態のＡＶシステム構成例を示す説明図である。
【図７】本実施の形態の再生装置であるディスクプレーヤの構成を示すブロック図である。
【図８】本実施の形態のディスクプレーヤのＣＤデータ再生系及びＨＤデータ再生系のブロック図である。である。
【図９】本実施の形態においてＣｏｎｔｒｏｌｌｅｒとして機能するパーソナルコンピュータの構成例を示すブロック図である。
【図１０】本実施の形態に対応するＩＥＥＥ１３９４のスタックモデルを示す説明図である。
【図１１】ＩＥＥＥ１３９４に使用されるケーブル構造を示す説明図である。
【図１２】ＩＥＥＥ１３９４における信号伝送形態を示す説明図である。
【図１３】ＩＥＥＥ１３９４におけるバス接続規定を説明するための説明図である。
【図１４】ＩＥＥＥ１３９４システム上でのＮｏｄｅ ＩＤ設定手順の概念を示す説明図である。
【図１５】ＩＥＥＥ１３９４におけるＰａｃｋｅｔ送信の概要を示す説明図である。
【図１６】Ａｓｙｎｃｈｒｏｎｏｕｓ通信における基本的な通信規則（トランザクションルール）を示す処理遷移図である。
【図１７】ＩＥＥＥ１３９４バスのアドレッシング構造を示す説明図である。
【図１８】ＣＩＰの構造図である。
【図１９】プラグにより規定された接続関係例を示す説明図である。
【図２０】プラグコントロールレジスタを示す説明図である。
【図２１】Ａｓｙｎｃｈｒｏｎｏｕｓ通信において規定されるＷｒｉｔｅ Ｔｒａｎｓａｃｔｉｏｎを示す処理遷移図である。
【図２２】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔ（ＡＶ／Ｃコマンドパケット）の構造図である。
【図２３】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにおける、ｃｔｙｐｅ／ｒｅｓｐｏｎｃｅの定義内容を示す説明図である。
【図２４】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｐａｃｋｅｔにおける、ｓｕｂｕｎｉｔ＿ｔｙｐｅと、ｏｐｃｏｄｅの定義内容例を示す説明図である。
【図２５】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグ構造を示す説明図である。
【図２６】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグアドレス構造を示す説明図である。
【図２７】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグアドレス構造を示す説明図である。
【図２８】Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるプラグ間での処理を示す説明図である。
【図２９】Ａｓｙｎｃｈｒｏｎｏｕｓ Ｃｏｎｎｅｃｔｉｏｎとしての送信手順を示す説明図である。である。
【図３０】 Subunit Identifier Descriptorの構造概念を示す説明図である。
【図３１】 Subunit Identifier Descriptorの構造を示す説明図である。
【図３２】 Object List Descriptorの構造を示す説明図である。
【図３３】 list typeの定義内容を示す説明図である。
【図３４】 Object Entryの構造を示す説明図である。
【図３５】 entry typeの定義内容を示す説明図である。
【図３６】 Disc Subunit Object entry_specific_informationの構造を示す説明図である。
【図３７】 Audio Track Object entry_specific_informationの構造を示す説明図である。
【図３８】 Disc Subunit typeの定義内容を示す説明図である。
【図３９】 Disc Subunit List List_specific_informationの構造を示す説明図である。
【図４０】 Root Contents Listとしての構造概念を示す説明図である。
【図４１】 Root Contents List List_specific_informationの構造を示す説明図である。
【図４２】 media typeの定義内容を示す説明図である。
【図４３】 information blockの基本構造を示す説明図である。
【図４４】 information block typeの定義内容を示す説明図である。
【図４５】 information block typeの定義内容の詳細を示す説明図である。
【図４６】 List内におけるinformation blockの配置構造を概念的に示す説明図である。
【図４７】ＲＥＡＤ ＩＮＦＯ ＢＬＯＣＫ ｃｏｍｍａｎｄの構造を示す説明図である。
【図４８】ＳＡＣＤに対応するRoot Contents List List_specific_informationの構造を示す説明図である。
【図４９】 album_set_info_blockの構造を示す説明図である。
【図５０】 album_catalog_code_info_blockの構造を示す説明図である。
【図５１】ＳＡＣＤに対応するAudio Track Object entry_specific_informationの構造を示す説明図である。
【図５２】 SACD_specific_informationの構造を示す説明図である。
【図５３】ＳＡＣＤに対応するDisc Subunit Identifier Descriptorの全体構造を示す説明図である。
【図５４】本実施の形態のハイブリッドディスクに対応するDisc Subunit Identifier Descriptorの全体構造を示す説明図である。
【図５５】ＳＡＣＤ及びＣＤ−ＤＡについてのList Typeの定義内容を示す説明図である。
【図５６】本実施の形態が対応するディスクについてのDisc Subunit Identifier Descriptor作成処理を示すフローチャートである。
【図５７】本実施の形態の単層ＨＤディスクに対応したDisc Subunit Identifier Descriptor作成処理を示すフローチャートである。
【図５８】本実施の形態のハイブリッドディスクに対応したDisc Subunit Identifier Descriptor作成処理を示すフローチャートである。
【図５９】 Disc Subunit Identifier Descriptor送信のための処理動作を示すフローチャートである。
【図６０】 Information Block送信のための処理動作を示すフローチャートである。
である。
【符号の説明】
１ 光ディスク、２ スピンドルモータ、３ 光学ヘッド、３Ａ ＣＤ用ヘッド部、３Ｂ ＨＤ用ヘッド部、４ ＲＦアンプ、５ サーボ回路、６ 駆動回路、７ エラー訂正及びデコード回路、８ メモリコントローラ、９ バッファメモリ、１０ Ｄ／Ａコンバータ、１１ システムコントローラ、１２ 操作部、１３ 表示部、１４ ＩＥＥＥ１３９４インターフェイス部、１５Ａ，１５Ｂ 対物レンズ、１６Ａ，１６Ｂ ２軸機構、１７Ａ，１７Ｂ 半導体レーザ、１８Ａ，１８Ｂ ディテクタ、２０ 判別信号生成部、１０１ ＣＤレイヤー、１０２ ＨＤレイヤー、１１６ データバス（ＩＥＥＥ１３９４バス）

Claims (8)

  1. 第１の記録方式で単層にデータが記録された第１のディスク状記録媒体と、上記第１の記録方式とは異なる第２の記録方式で単層にデータが記録された第２のディスク状記録媒体と、上記第１の記録方式で第１の記録層にデータが記録されるとともに上記第２の記録方式で上記第１の記録層とは異なる第２の記録層にデータが記録され上記第１の記録層と上記第２の記録層とが積層された第３のディスク状記録媒体と、上記第２の記録方式でデータが記録された第１の記録層と上記第２の記録方式でデータが記録された第２の記録層とが積層された第４のディスク状記録媒体とのうちの装着された１のディスクを再生する再生手段と、
    上記再生手段によってディスク状記録媒体の所定領域から読み出されるデータに基づいてディスク状記録媒体の種別を判別する種別判別手段と、
    上記種別判別手段にて上記第４のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合には、各層に記録された管理情報を取得し、上記種別判別手段にて上記第３のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合に、記録フォーマットが異なる各々の記録方式で記録される管理情報の各記録層における記録位置ごとに複数の記録情報が記録される記録媒体に対して再生を行うことで、少なくとも、記録情報を管理するために上記各記録情報内に設けられる管理情報を取得することのできる情報取得手段と、
    上記情報取得手段により取得された上記各記録情報内の管理情報に基づいて所定の伝送フォーマットに対応した記述情報を作成するのに、上記第３のディスク状記録媒体の場合には１つの記述情報の構造内において、上記複数の記録情報ごとの記述内容がそれぞれ異なる記録媒体として定義された情報単位として管理されるように記述を行い、上記第４のディスク状記録媒体の場合には上記積層された記録層を単一のディスク状記録媒体として管理されるように記述情報の記述を行う記述情報作成手段と、
    を備えていることを特徴とする再生装置。
  2. 上記記録フォーマットの１つは、サンプリング周波数が、基準サンプリング周波数ｆｓとされ、量子化ビット数が所定のマルチビットとされるデータフォーマットに対応していることを特徴とする請求項１に記載の再生装置。
  3. 上記記録フォーマットの１つは、サンプリング周波数ｆｓ×Ｎ（但し、ｆｓは所定の基準サンプリング周波数、Ｎは２以上の自然数）とされ、量子化ビット数が１ビットとされるデータフォーマットに対応していることを特徴とする請求項１に記載の再生装置。
  4. 上記所定の伝送フォーマットは、ＩＥＥＥ１３９４データインターフェイスとされていることを特徴とする請求項１に記載の再生装置。
  5. 第１の記録方式で単層にデータが記録された第１のディスク状記録媒体と、上記第１の記録方式とは異なる第２の記録方式で単層にデータが記録された第２のディスク状記録媒体と、上記第１の記録方式で第１の記録層にデータが記録されるとともに上記第２の記録方式で上記第１の記録層とは異なる第２の記録層にデータが記録され上記第１の記録層と上記第２の記録層とが積層された第３のディスク状記録媒体と、上記第２の記録方式でデータが記録された第１の記録層と上記第２の記録方式でデータが記録された第２の記録層とが積層された第４のディスク状記録媒体とのうちの装着された１のディスクを再生する再生ステップと、
    上記再生手順によってディスク状記録媒体の所定領域から読み出されるデータに基づいてディスク状記録媒体の種別を判別する種別判別ステップと、
    上記種別判別ステップにて上記第４のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合には、各層に記録された管理情報を取得し、上記種別判別手順にて上記第３のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合に、記録フォーマットが異なる各々の記録方式で記録される管理情報の各記録層における記録位置ごとに複数の記録情報が記録される記録媒体に対して再生を行うことで、少なくとも、記録情報を管理するために上記各記録情報内に設けられる管理情報を取得する情報取得ステップと、
    上記情報取得ステップにより取得された上記各記録情報内の管理情報に基づいて所定の伝送フォーマットに対応した記述情報を作成するのに、上記第３のディスク状記録媒体の場合には１つの記述情報の構造内において、上記複数の記録情報ごとの記述内容がそれぞれ異なる記録媒体として定義された情報単位として管理されるように記述を行い、上記第４のディスク状記録媒体の場合には上記積層された記録層を単一のディスク状記録媒体として管理されるように記述情報の記述を行う記述情報作成ステップと、
    要求に応じて、上記所定の伝送フォーマットに従って、上記記述情報を送信出力することのできる送信ステップと、
    を実行するように構成されていることを特徴とする情報伝送方法。
  6. 上記記録フォーマットの１つは、サンプリング周波数が、基準サンプリング周波数ｆｓとされ、量子化ビット数が所定のマルチビットとされるデータフォーマットに対応していることを特徴とする請求項５に記載の情報伝送方法。
  7. 上記記録フォーマットの１つは、サンプリング周波数ｆｓ×Ｎ（但し、ｆｓは所定の基準サンプリング周波数、Ｎは２以上の自然数）とされ、量子化ビット数が１ビットとされるデータフォーマットに対応していることを特徴とする請求項５に記載の情報伝送方法。
  8. 上記所定の伝送フォーマットは、ＩＥＥＥ１３９４データインターフェイスとされていることを特徴とする請求項５に記載の情報伝送方法。
JP34681699A 1999-12-06 1999-12-06 再生装置、及び情報伝送方法 Expired - Fee Related JP4055313B2 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
JP34681699A JP4055313B2 (ja) 1999-12-06 1999-12-06 再生装置、及び情報伝送方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP34681699A JP4055313B2 (ja) 1999-12-06 1999-12-06 再生装置、及び情報伝送方法

Publications (2)

Publication Number Publication Date
JP2001167515A JP2001167515A (ja) 2001-06-22
JP4055313B2 true JP4055313B2 (ja) 2008-03-05

Family

ID=18386009

Family Applications (1)

Application Number Title Priority Date Filing Date
JP34681699A Expired - Fee Related JP4055313B2 (ja) 1999-12-06 1999-12-06 再生装置、及び情報伝送方法

Country Status (1)

Country Link
JP (1) JP4055313B2 (ja)

Families Citing this family (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP3890927B2 (ja) 2001-07-23 2007-03-07 ヤマハ株式会社 他ノードを管理する通信装置及び他ノードに管理される通信装置
CN101154396B (zh) * 2005-02-16 2010-06-09 三菱电机株式会社 光盘和光盘装置
JP2007004856A (ja) 2005-06-22 2007-01-11 Sony Corp 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム

Also Published As

Publication number Publication date
JP2001167515A (ja) 2001-06-22

Similar Documents

Publication Publication Date Title
JP4449141B2 (ja) 電源制御装置、電源制御システム
JP4403331B2 (ja) 電子機器システム、情報処理機器
JP4147689B2 (ja) 情報処理装置及び情報処理方法
JP4281201B2 (ja) 制御装置、及び制御方法
JP4404190B2 (ja) 電子機器、認証使用情報更新方法
US6493769B1 (en) Stream information processing and method and providing medium
JP4055313B2 (ja) 再生装置、及び情報伝送方法
JP2000132908A (ja) デ―タ送受信装置およびその方法
JP2001006276A (ja) 外部機器の制御装置、及び外部機器の制御方法
KR101165316B1 (ko) 수신장치 및 수신방법
JP2000357386A (ja) 編集装置及び操作装置
JP2001167556A (ja) 再生装置、及び情報伝送方法
JP4225151B2 (ja) 電子機器、フォーマット方法
JP4831157B2 (ja) フォーマット指示方法
JP2002033751A (ja) 電子機器、電子機器管理方法
JP2000209617A (ja) 通信動作検査方法及び通信動作検査装置
JP2001236772A (ja) 電子機器システム、電子機器

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20060309

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20070207

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070227

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070427

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070605

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20070801

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20070828

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20071029

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20071120

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20071203

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101221

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20101221

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111221

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20111221

Year of fee payment: 4

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20121221

Year of fee payment: 5

LAPS Cancellation because of no payment of annual fees