JP2001167515A

JP2001167515A - 再生装置、及び情報伝送方法

Info

Publication number: JP2001167515A
Application number: JP34681699A
Authority: JP
Inventors: Yumiko Onuki; 由美子大貫
Original assignee: Sony Corp
Current assignee: Sony Corp
Priority date: 1999-12-06
Filing date: 1999-12-06
Publication date: 2001-06-22
Anticipated expiration: 2019-12-06
Also published as: JP4055313B2

Abstract

(57)【要約】【課題】ＩＥＥＥ１３９４データインターフェイスに
よるＡＶ機器通信機能の拡充を図る。【解決手段】例えばハイブリッドディスクなどといわ
れる、記録フォーマットが異なる複数の記録情報が記録
される記録媒体が存在する場合に、このような記録媒体
に対応する記述情報を作成するのにあたっては、各記録
情報に対応した記述内容は、それぞれ異なる記録媒体(m
edia type)として定義された情報単位(Contents List)
として管理されるようにする。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、所定の記録媒体に
対応して再生が可能な再生装置、また、この再生装置に
おける情報伝送方法に関するものである。

【０００２】

【従来の技術】オーディオデータが記録された再生専用
ディスクとして、ＣＤ(Compact Disc)が広く普及してい
ると共に、このＣＤ−ＤＡより大容量な新たな光ディス
クとしてＤＶＤ（Digital Versatile Disc）が提案され
ている。このＤＶＤは直径１２ｃｍの光ディスクに従来
のＣＤのトラックピッチ１．６μｍの半分の０．８μｍ
で情報を記録し、半導体レーザの波長をＣＤの７８０ｎ
ｍから例えば６５０ｎｍに変更し、更にＣＤで採用され
たＥＦＭ（Eight to Fourteen Modulation）変調方式に
改良を加えて片面で約４Ｇバイト相当の高密度記録を実
現させている。そして現在、例えば上記のようなＤＶＤ
に準拠して、ＣＤよりも高音質とされるオーディオデー
タを記録した高音質オーディオディスクも提案されてい
る。

【０００３】ＣＤのデータフォーマットとしては、周知
のように、サンプリング周波数が４４．１ＫＨｚとさ
れ、量子化ビットは１６ビットとされる。また、デジタ
ルオーディオ信号の記録変調方式にはＥＦＭ(Eight to
Fourteen Moduration)が採用されているものである。こ
れに対して、上記高音質オーディオディスクのデータフ
ォーマットとしては、サンプリング周波数については、
上記４４．１ＫＨｚの６４倍である２．８２２４ＭＨｚ
という非常に高い周波数によりサンプリングを行い、更
に、ΣΔ変調による１ビット量子化を行ってメディアへ
記録するものとしている。また、この高音質オーディオ
ディスクは、従来から販売されているコンパクトディス
クと外観はほぼ同じとされる。なお、以降の説明にあた
り、ＣＤのデータフォーマットによるオーディオデータ
については「ＣＤデータ」といい、高音質オーディオデ
ィスクのデータフォーマットによるオーディオデータに
ついては、「ＨＤ（Hi-Definition）データ」ともいう
ことにする。

【０００４】また、上記したＨＤデータが記録されるデ
ィスクとしては、記録層として２つの層（レイヤー）を
備えたマルチレイヤーディスク（複層ディスク）とする
ことも提案されている。このマルチレイヤーディスクと
して、１つには、各レイヤーにＨＤデータを記録するよ
うにした複層ディスクが提案されている。そしてもう１
つには、一方のレイヤーにＣＤデータを記録し、他方の
レイヤーにＨＤデータを記録した、いわゆるハイブリッ
ドディスクの形態とすることが提案されている。なお、
レイヤーの名称として、ＨＤデータが記録されるレイヤ
ーについては「ＨＤレイヤー」ともいい、また、ＣＤデ
ータが記録されるレイヤーについては「ＣＤレイヤー」
ともいうことにする。

【０００５】上記ハイブリッドディスクについては、音
楽等のデータ内容（プログラム）としては、各レイヤー
で同一の内容（例えば同一の曲）とすることが考えられ
ており、従ってその同一内容のデータが、ＣＤレベルの
通常品質のデータとして一方のレイヤーに記録されると
ともに、より高品質なデータが他方のレイヤーに記録さ
れるようにする。

【０００６】このようなハイブリッドディスクにおいて
は、一方のレイヤーは、ＣＤデータが記録されることに
なるので、現在市場で普及しているＣＤプレーヤーの機
能によっても再生可能となる。そして、ＣＤプレーヤと
しての機能を有する再生装置において、ＨＤデータに対
応したデコーダを備えれば、上記他方のレイヤーに記録
された新たなフォーマットのデータも再生できる再生装
置が実現される。即ちこのような再生装置においては、
両方のレイヤーからの再生を可能にすることで、一般に
多数所有されているコンパクトディスクも再生でき、か
つ上記したハイブリッドディスクについても再生可能と
なる。また、当然のこととして、ＨＤデータを記録した
ＨＤレイヤーの１層のみを有する高音質オーディオディ
スクについても再生可能となるものである。

【０００７】また、近年においては、デジタルデータイ
ンターフェイスとして、ＩＥＥＥ(Institute of Electr
ical Engineers)１３９４データインターフェイスが知
られてきている。ＩＥＥＥ１３９４のデータインターフ
ェイスは、例えばＳＣＳＩやＵＳＢなどのデータインタ
ーフェイスよりもデータ転送レートが高速であり、周知
のように、所要のデータサイズを周期的に送受信するこ
とが保証されるＩｓｏｃｈｒｏｎｏｕｓ通信が可能とさ
れる。このため、ＩＥＥＥ１３９４データインターフェ
イスは、ＡＶなどのストリームデータをリアルタイムで
転送するのに有利とされている。

【０００８】このため、各種デジタルＡＶ(Audio Visua
l)機器やパーソナルコンピュータ装置等の電子機器を、
例えばＩＥＥＥ(The Institute of Electrical and Ele
ctronics Engineers)１３９４等のデジタルデータイン
ターフェイス規格に従ったデータバスを介して相互に接
続することで、機器間でデータを送受信できるようにし
たデータ伝送システムが提案されてきている。これによ
り、ＡＶシステムとして有用とされる各種機能を与える
ことができる。

【０００９】このようなＡＶシステムとしての機能の一
例としては、いわゆるリモート制御も可能となる。例え
ば、データバスを介してディスク記録再生装置とパーソ
ナルコンピュータが接続されているとして、ディスク記
録再生装置に対する記録再生、更には記録ソースの編集
などに関する操作をパーソナルコンピュータ装置側での
操作によって行うといったことも可能となる。

【００１０】

【発明が解決しようとする課題】現状、ＩＥＥＥ１３９
４データインターフェイスに従ったＡＶ機器を対象とす
る伝送規格にあっては、例えば上記したＣＤや、また、
既に普及率の高いＭＤ（Mini Disc)などのメディアに対
応しては、ほぼ機能が充実している段階にある。

【００１１】そして例えば、ＩＥＥＥ１３９４データイ
ンターフェイスによる各種機能を上記のようにして新た
に出現してくる高音質オーディオディスクなどのメディ
アに対応させようとした場合には、上記したＣＤなどの
機能に対応して既に定義された規格を利用することで、
或る程度の機能の充実を図ることが可能である。但し、
例えば高音質オーディオディスクに特有で、ＣＤなどの
フォーマットでは決められていないような規格に対応し
た機能を実現することはできないことになる。これは、
例えば高音質オーディオディスクを再生可能な再生装置
を含めてＡＶシステムを構築した場合に、その利便性が
十分に発揮されないということにつながり得る。このた
め、ＩＥＥＥ１３９４伝送フォーマット上で、例えば高
音質オーディオディスク等の新規なメディアに対応した
機能が必要充分となるように拡充の図られることが求め
られている。

【００１２】

【課題を解決するための手段】そこで本発明は上記した
課題を考慮して、再生装置について次のように構成す
る。つまり、記録フォーマットが異なる複数の記録情報
が記録される記録媒体に対して再生を行うことで、少な
くとも、記録情報を管理するために上記各記録情報内に
設けられる管理情報を取得することのできる情報取得手
段と、この情報取得手段により取得した各記録情報内の
管理情報に基づいて所定の伝送フォーマットに対応した
記述情報を作成するのに、１つの記述情報の構造内にお
いて、複数の記録情報ごとの記述内容がそれぞれ異なる
記録媒体として定義された情報単位として管理されるよ
うに記述を行う記述情報作成手段とを備えることとし
た。

【００１３】また、情報伝送方法として次のように構成
する。記録フォーマットが異なる複数の記録情報が記録
される記録媒体に対して再生を行うことで、少なくと
も、記録情報を管理するために上記各記録情報内に設け
られる管理情報を取得する情報取得ステップと、この情
報取得ステップにより取得した各記録情報内の管理情報
に基づいて所定の伝送フォーマットに対応した記述情報
を作成するのに、１つの記述情報の構造内において、上
記複数の記録情報ごとの記述内容がそれぞれ異なる記録
媒体として定義された情報単位として管理されるように
記述する記述情報作成ステップと、要求に応じて所定の
伝送フォーマットに従って、記述情報を送信出力するこ
とのできる送信ステップとを実行するように構成するこ
ととした。

【００１４】上記各構成によれば、記録フォーマットが
異なる複数の記録情報が記録される記録媒体に対応して
は、この記録情報ごとの記述内容は、それぞれ異なる記
録媒体として定義された情報単位として１つの記述情報
構造内で管理される。例えば記述情報の規格として、記
録フォーマットを記録媒体のタイプとして扱っている場
合であっても、上記のようにして、記録フォーマットの
異なる記録情報を、異なる記録媒体として定義された情
報単位として扱って管理することで、１つの記述情報の
構造で、複数の異なる記録フォーマットの記録情報が記
録された記録媒体を表現することが可能になる。

【００１５】

【発明の実施の形態】以下、本発明の実施の形態の再生
装置を以下の順序で説明する。なおこの再生装置は、光
ディスクとしての記録媒体に対応するものとする。な
お、以降の説明は次の順序で行う。１．ディスク種別２．ディスクのゾーン構造３．ＡＶシステム３−１．システム例３−２．ディスクプレーヤ３−３．パーソナルコンピュータ４．ＩＥＥＥ１３９４データインターフェイス４−１．概要４−２．スタックモデル４−３．信号伝送形態４−４．機器間のバス接続４−５．パケット４−６．トランザクションルール４−７．アドレッシング４−８．ＣＩＰ(Common Isochronous Packet) ４−９．コネクションマネージメント４−１０．ＦＣＰにおけるコマンド及びレスポンス４−１１．ＡＶ／Ｃコマンドパケット４−１２．プラグ４−１３．Asynchronous Connection送信手順５．本実施の形態のＤｉｓｃＳｕｂｕｎｉｔＩｄｅ
ｎｔｉｆｉｅｒＤｅｓｃｒｉｐｔｏｒ５−１．基本概念５−２．ＳｕｂｕｎｉｔＩｄｅｎｔｉｆｉｅｒＤｅ
ｓｃｒｉｐｔｏｒ５−３．Object List Descriptor ５−４．Object Entry ５−５．Disc Subunit Object ５−６．Disc Subunit Object entry_specific_informa
tion ５−７．Audio Track Object entry_specific_informat
ion ５−８．Disc Subunit List List_specific_informatio
n ５−９．Root Contents List ５−１０．Root Contents List List_specific_informa
tion ５−１１．information block ５−１２．ＲｅａｄＩｎｆｏＢｌｏｃｋｃｏｍｍ
ａｎｄ５−１３．ＳＡＣＤ type ５−１４．ＳＡＣＤ type／Root Contents List List_s
pecific_information ５−１５．ＳＡＣＤ type／Audio Track Object entry_
specific_information ５−１６．ＳＡＣＤ typeのDisc Subunit Identifier D
escriptor ５−１７．ハイブリッドディスクのDisc Subunit Ident
ifier 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 St
reo Area）と、これに続けて、例えば２チャンネルより
も多いマルチチャンネルによるＨＤデータを記録するマ
ルチチャンネルエリア（Multichannel Area）とに分割
される。

【００３５】これら２チャンネルステレオエリアとマル
チチャンネルエリアの各々においては、図示していない
が、オーディオトラックといわれる、トラック単位で管
理されるオーディオデータがトラックナンバ順に記録さ
れるエリアが形成される。そして、前後からこのオーデ
ィオトラックを挟むようにして、２つのエリアＴＯＣ
（Area TOC-1,Area TOC-2）が配置される。

【００３６】これらエリアＴＯＣ（Area TOC-1,Area TO
C-2）は、それぞれが配置されている各チャンネルエリ
アのオーディオデータをトラック単位で管理するための
データ構造を有している。つまり、２チャンネルステレ
オエリアのＡｒｅａＴＯＣ−１，ＡｒｅａＴＯＣ−
２は、２チャンネルステレオエリアに記録されたオーデ
ィオデータをトラック単位で管理する情報を有し、マル
チチャンネルエリアのエリアＴＯＣ（Area TOC-1,Area
TOC-2）は、マルチチャンネルエリアに記録されたオー
ディオデータをトラック単位で管理する情報を有する。
また、エリアＴＯＣ（Area TOC-1,Area TOC-2）では、
各トラックのタイトル、アーティスト、作曲者、作詞
者、ジャンル、編曲者、メッセージ、国際著作権コード
（ＩＳＲＣ）などの情報も格納することができるように
なっている。特に、マルチチャンネルエリアのエリアＴ
ＯＣ（Area TOC-1,Area TOC-2）には、マルチチャンネ
ルステレオとしてのオーディオ再生のスピーカレイアウ
トを指定するスピーカレイアウト情報が格納される。マ
ルチチャンネルエリアに記録されるデータは、そのフォ
ーマットによっても異なるが、例えば３以上のスピーカ
を所定の配置形態によりレイアウトして再生音声を出力
させることで、その音響効果が発揮されるようになって
いる。このため、上記のようにして、スピーカレイアウ
ト情報を格納しておくことで、例えば各オーディオトラ
ックごとに適切とされるスピーカレイアウトを指示する
ことが可能になる。

【００３７】また、エクストラデータエリア（Extra Da
ta Area）は、例えばオーディオデータ以外の、テキス
ト、画像データなどを記録するために割り当てられた領
域とされる。

【００３８】なお、例えば図２（ｂ）に示した単層ディ
スクであれば、上記図５に示した構造のＨＤレイヤー１
０２が１つの記録層Ｌとして形成されていることにな
る。また、図２（ｄ）に示した複層ディスクであれば、
第１記録層Ｌ１と第２記録層Ｌ２の各々が、図５に示し
た構造を有しているものとされる。

【００３９】３．ＡＶシステム３−１．システム例図６は、ＩＥＥＥ１３９４デジタルデータインターフェ
イスにより接続される本実施の形態としてのＡＶシステ
ムの構成例を示している。

【００４０】図６に示すＡＶシステムとしては、ディス
クプレーヤ０とパーソナルコンピュータ２００とをＩＥ
ＥＥ１３９４データインターフェイス対応のケーブル６
０１により接続することで構成される。これにより、デ
ィスクプレーヤ０とパーソナルコンピュータ２００は、
ＩＥＥＥ１３９４バス１１６によって相互通信可能とな
る。

【００４１】ディスクプレーヤ０は、先に図２に示した
各ディスクに対応して再生可能に構成されたオーディオ
機器であり、ＩＥＥＥ１３９４バス１１６を介して再生
したオーディオデータを出力することも可能とされてい
る。

【００４２】この場合、パーソナルコンピュータ２００
は、ディスクプレーヤ０からの再生オーディオデータを
ＩＥＥＥ１３９４バス１１６を介して入力して、音声出
力を行ったり、また、編集処理等を行うことができる。
また、ディスクプレーヤ０に対して、再生に関する操作
制御を行うことができる。つまり、リモート制御を実行
できる。上記したような機能は、パーソナルコンピュー
タ２００に対して、例えばこのような機能を実現するた
めのアプリケーションソフトウェアをインストールする
ことで得られるものである。なお、本実施の形態が対応
するＡＶシステムとしては、他にも考えられ、例えばＭ
Ｄに対応して記録再生が可能なＭＤレコーダ／プレーヤ
なども接続されてよいのであるが、ここでは、必要最小
限の機器のみによって構成される例のみに限定して示し
ている。

【００４３】３−２．ディスクプレーヤ次に上記図６に示したディスクプレーヤ０の内部構成を
図７に示す。この図において装填されている光ディスク
１は、図２に示した４種類のうちのいずれかのディスク
とされる。この光ディスク１は、図示しないターンテー
ブルに載置され、スピンドルモータ２によってＣＬＶ
（線速度一定：constant liner velocity）又はＣＡＶ
（角速度一定：constant angler velocity）に回転制御
される。

【００４４】この再生装置では、４種類のディスクに対
応するために、ＣＤレイヤー１０１とＨＤレイヤー１０
２の両方についての再生機能を備える必要があるため、
図７に示す光学ヘッド３、ＲＦアンプ４、エラー訂正／
デコーダ回路７としては、ＣＤデータ再生系とＨＤデー
タ再生系の２系等を備えるものとなり、この２系統の構
成は図８に示している。

【００４５】図７に示す光学ヘッド３は、対物レンズ、
２軸機構、半導体レーザ、及び上記半導体レーザの出射
光及び光ディスク１からの反射の経路となる光学系、反
射光を受光するディテクタを有して構成されている。具
体的には図８に示すように、光学ヘッド３としてはＣＤ
用ヘッド部３ＡとＨＤ用ヘッド部３Ｂが形成され、それ
ぞれ図示するように対物レンズ１５Ａ、１５Ｂ、２軸機
構１６Ａ、１６Ｂ、半導体レーザ１７Ａ、１７Ｂ、ディ
テクタ１８Ａ、１８Ｂ、光学系１９Ａ、１９Ｂが形成さ
れる。

【００４６】そして上記ターンテーブルに載置されてい
る光ディスクがＣＤ−ＤＡである場合、もしくはハイブ
リッドディスクのＣＤレイヤ１０１を再生する場合は、
ＣＤ用ヘッド部３Ａが用いられる。即ち半導体レーザ１
７Ａは７８０nmの波長のレーザ出力を行うものとされ、
また対物レンズ１５Ａの開口率は０．４５とされてい
る。一方、上記ターンテーブルに載置されている光ディ
スクが単層ＨＤディスク又は複層ＨＤディスクである場
合、もしくはハイブリッドディスクのＨＤレイヤー１０
２を再生する場合は、ＨＤ用ヘッド部３Ｂが用いられ
る。即ち半導体レーザ１７Ｂは６５０nmの波長のレーザ
出力を行うものとされ、また対物レンズ１５Ｂの開口率
は０．６とされている。

【００４７】このようにＣＤ用ヘッド部３ＡもしくはＨ
Ｄ用ヘッド部３Ｂによるレーザ照射が、スピンドルモー
タ２によって回転されている光ディスク１に対して実行
され、その反射光がディテクタ３Ａ又は３Ｂによって受
光される。

【００４８】なお、ホログラム一体型非球面レンズを用
いれば、上述したような光学ヘッド３内部に２つの対物
レンズ（１５Ａ、１５Ｂ）を設ける必要が無く、１つの
レンズで半導体レーザの光路を切換えるのみで構成で
き、そのような光学ヘッドを用いてもよい。つまりその
場合は半導体レーザのみを短波長用と長波長用の２つ設
けるようにし、光学系、対物レンズ、ディテクタ等は共
用できる。また、光学系やディテクタは共用するが、半
導体レーザと対物レンズについてはＣＤ用とＨＤ用にそ
れぞれ用意するような光学ヘッド３の構成も可能であ
る。

【００４９】対物レンズ１５Ａ、１５Ｂをそれぞれ支持
する２軸機構１６Ａ、１６Ｂには、対物レンズ１５Ａ、
１５Ｂを光ディスク１に接離する方向に駆動するフォー
カス用コイルと、対物レンズ１５Ａ、１５Ｂを光ディス
ク１の半径方向に駆動するトラッキング用コイルとが形
成されている。また、この再生装置には、光学ヘッド３
全体を光ディスク１の半径方向に大きく移動させるスレ
ッド機構１４を更に備えている。

【００５０】光学ヘッド３内のディテクタ（１８Ａ又は
１８Ｂ）にて検知した反射光は反射光量に応じた電流信
号とされてＲＦアンプ４に供給され、このＲＦアンプ４
での電流電圧変換、マトリクス演算処理により、フォー
カスエラー信号ＦＥ、トラッキングエラー信号ＴＥが生
成されるとともに再生情報（和信号）としてのＲＦ信
号、同じく和信号であるＰＩ（プルイン）信号が生成さ
れる。図８のようにディテクタ１８Ａ、１８Ｂが独立系
統として形成される場合は、ＲＦアンプ４内には、ＣＤ
用ＲＦ部４Ａ、ＨＤ用ＲＦ部４Ｂが形成され、それぞれ
フォーカスエラー信号ＦＥ、トラッキングエラー信号Ｔ
Ｅ、ＲＦ信号、ＰＩ信号が生成されるようになされる。
なお、両系統でディテクタが共用される場合や、或いは
ディテクタ１８Ａ、１８Ｂの出力が選択的に切り換えら
れてＲＦアンプ４に供給されるような構成を取った場合
は、ＣＤ用ＲＦ部、ＨＤ用ＲＦ部を独立して設ける必要
はない。

【００５１】ＲＦアンプ４で生成されたフォーカスエラ
ー信号ＦＥ、トラッキングエラー信号ＴＥはサーボ回路
５にて位相補償、利得調整をされたのちに駆動回路６に
供給され、フォーカスドライブ信号、トラッキングドラ
イブ信号として上述したフォーカス用コイルと、トラッ
キング用コイルとに印加される。さらに上記トラッキン
グエラー信号ＴＥをサーボ回路５内にてＬＰＦ（low pa
ss filter）を介してスレッドエラー信号を生成して、
駆動回路６からスレッドドライブ信号としてスレッド機
構１４に印加される。これによりいわゆるフォーカスサ
ーボ制御、トラッキングサーボ制御、スレッドサーボ制
御が実行される。

【００５２】またサーボ回路５はシステムコントローラ
１１からの指示に基づいて、フォーカスサーチ動作、ト
ラックジャンプ動作のための信号を駆動回路６に供給
し、それに応じた、フォーカスドライブ信号、トラッキ
ングドライブ信号、スレッドドライブ信号を発生させ
て、光学ヘッド３のフォーカスサーチやトラックジャン
プ及びアクセス等を実行させる。

【００５３】フォーカスサーチとは、フォーカスサーボ
引込のために対物レンズ１５（１５Ａ、１５Ｂ）をディ
スク１から最も遠い位置と最も近い位置の間を強制的に
移動させながらいわゆるＳ字カーブを検出する動作であ
る。既に知られているようにフォーカスエラー信号ＦＥ
としては、対物レンズ１５がディスク１の記録層に対し
て合焦点位置となるポイントの前後の狭い区間において
Ｓ字カーブが観測されるものとなり、そのＳ字カーブの
リニア領域でフォーカスサーボをオンとすることで、フ
ォーカスサーボ引込が可能となる。このようなフォーカ
スサーボ引込のために、フォーカスサーチが行われるも
のであり、このためのフォーカスドライブ信号がフォー
カス用コイルに印加され、対物レンズ１５の移動が行わ
れる。

【００５４】またトラックジャンプやアクセスの場合に
は、２軸機構１６（１６Ａ、１６Ｂ）による対物レンズ
１５のディスク半径方向への移動や、スレッド機構１４
による光学ヘッド３のディスク半径方向への移動が行わ
れるが、このためのドライブ信号がトラッキングドライ
ブ信号、スレッドドライブ信号としてトラッキング用コ
イルやスレッド機構１４に印加されることになる。

【００５５】ＲＦアンプ４にて生成されたＲＦ信号は、
載置されている光ディスク１がＣＤ−ＤＡの場合、もし
くはハイブリッドディスクのＣＤレイヤー１０１を再生
している場合は、エラー訂正及びデコーダ回路７におい
て、２値化してＥＦＭ復調(eight to fourteen demodul
ation )を行うとともにＣＩＲＣ（cross interleaverea
d solomon coding）によるエラー訂正処理を行った後に
メモリコントローラー８に入力される。一方、上記ター
ンテーブルに載置されている光ディスク１が単層ＨＤデ
ィスク又は複層ＨＤディスクである場合、もしくはハイ
ブリッドディスクのＨＤレイヤ１０２を再生している場
合は、エラー訂正及びデコーダ回路７において２値化し
てＥＦＭ-Ｐｌｕｓ復調(eight to fourteen demodulati
on Plus)を行うとともに積符号(product code)に基づく
エラー訂正処理が行なわれ、メモリコントローラ８に供
給される。即ち機能的に見れば、図８のようにエラー訂
正及びデコーダ回路７においてはＣＤ用デコード部７Ａ
とＨＤ用デコード部７Ｂが形成される。なおＣＤ用デコ
ード部７ＡとＨＤ用デコード部７Ｂはハードウエア的に
独立した回路部としてもよいし、ハードウエア的には共
用される回路部とすることもできる。

【００５６】またエラー訂正及びデコーダー回路７では
２値化したＥＦＭ信号もしくはＥＦＭプラス信号の基準
クロックとの比較により速度エラー信号及び位相エラー
信号を生成して駆動回路６に供給することで、光ディス
ク１をスピンドルモーター２により所定ＣＬＶ速度（又
はＣＡＶ速度）で回転させる。更にエラー訂正及びデコ
ーダー回路７では２値化したＥＦＭ信号又はＥＦＭプラ
ス信号に基づいてＰＬＬ（Phase Locked loop）の引き
込み動作を制御し、デコード処理等に用いる再生クロッ
クを得る。

【００５７】エラー訂正後の２値化データは、メモリコ
ントローラ８を介して所定の転送レートでバッファメモ
リ９に書き込まれる。バッファメモリ９に所定量以上の
データが蓄積されたらバッファメモリ９から書き込みの
転送レートより十分遅い第２の転送レートにて読み出し
を行う。このようにバッファメモリ９に一旦データを蓄
えてからオーディオデータとして出力するようにしたの
で、例えば振動等の外乱によってトラックジャンプが生
じて光学ヘッド３からの連続したデータ読み出しが途絶
えたとしても、光学ヘッド３のトラックジャンプが発生
したアドレスへの再配置に要する時間に相当するデータ
は予めバッファメモリ９に蓄積されているのでオーディ
オ出力としては連続したものを得ることができる。

【００５８】尚、メモリコントローラ８はシステムコン
トローラ１１によって制御されている。メモリコントロ
ーラー８によってバッファメモリ９から読み出されたデ
ジタルデータはＤ／Ａコンバーター１０にてアナログオ
ーディオ信号に変換される。そして、例えばＣＤレイヤ
ーに記録されたオーディオデータ、又は、ＨＤレイヤー
の２チャンネルステレオエリアに記録されたオーディオ
データであれば、右チャンネル出力、左チャンネル出力
として出力される。また、ＨＤレイヤーのマルチチャン
ネルエリアに記録されたオーディオデータであれば、そ
のマルチチャンネル数によって出力させることができ
る。

【００５９】またこの再生装置では、ＨＤ用ヘッド部３
Ｂ内のディテクタ１８Ｂ（ＣＤ用と共用される場合はそ
のディテクタ）からの反射光情報に基づいてＲＦアンプ
４で得られる信号（ＰＩ信号、フォーカスエラー信号Ｆ
Ｅ、トラッキングエラー信号ＴＥ）のいずれかが判別信
号生成部２０に供給される。判別信号生成部２０では、
入力された信号に基づいて所定の検出動作を行うこと
で、図２に示したディスクのうち、実際に装填されてい
るディスクの種別に対応するパターンの検出信号を出力
する。システムコントローラ１１では、この検出信号に
基づいて、ディスク１の種別判別を実行する。なお、こ
こでのディスク種別判別のための詳細については、省略
するが、一例として、さきに本出願により出願された特
願平１１−２４７３４６に記載される技術を適用するこ
とができる。

【００６０】システムコントローラ１１は全体を制御す
る部位としてマイクロコンピュータにより形成される。
システムコントローラ１１は内部ＲＯＭ１１に保持する
動作プログラムやユーザーの操作に応じて再生動作のた
めの所要の制御を行うことになる。例えば操作部１２と
しての各種の操作キーの操作に応じて各種サーボ用のコ
マンドをサーボ回路５に転送したり、メモリコントロー
ラ８に対してバッファメモリ９の制御の指令を与えるこ
と、エラー訂正・デコーダー回路７でのスピンドルサー
ボ制御やデコーダ制御を行うことなどで必要な再生動作
を実行させる。また、再生等の動作に応じて表示部１３
の表示制御を行う。例えば演奏経過時間や再生している
プログラムのタイトル等の文字情報の表示を表示部１３
に表示するように制御を行なう。また、システムコント
ローラ１１が処理を実行する過程において必要とされる
各種情報はＲＡＭ１１ａに書き込まれて保持される。

【００６１】また、本実施の形態においては、ＩＥＥＥ
１３９４インターフェイス部１４を備えることで、ＩＥ
ＥＥ１３９４バス１１６を介して接続された機器と相互
通信を行うことが可能とされる。これにより、例えば図
６に示したシステムの場合を例に挙げれば、例えばパー
ソナルコンピュータ２００により、ディスクプレーヤ０
をリモート制御することが可能となる。つまり、パーソ
ナルコンピュータ２００から或る操作を指示するコマン
ドが送信されてくると、ディスクプレーヤ０のシステム
コントローラ１１はこのコマンドをＩＥＥＥ１３９４イ
ンターフェイス部１４を介して受信する。そして、受信
したコマンドの内容に応じて、内部の所要の機能回路部
に対する制御を実行する。これにより、例えばディスク
再生を始めとする各種コントロールを、リモート制御に
よって行うことができる。

【００６２】また、例えば光ディスク１にて再生された
デジタルオーディオデータをＩＥＥＥ１３９４バス１１
６を介して送信出力することも可能とされる。例えば、
システムコントローラ１１は、バッファメモリ９に蓄積
されていデジタルオーディオデータを所定タイミングで
読み出して、ＩＥＥＥ１３９４インターフェイス部１４
に伝送する。ＩＥＥＥ１３９４インターフェイス部１４
では、伝送されてきたデジタルオーディオデータを、例
えばパケット化などのＩＥＥＥ１３９４デジタルインタ
ーフェイスのフォーマットに従った形式に変換し、ＩＥ
ＥＥ１３９４バス１１６を介して送信出力する。

【００６３】３−３．パーソナルコンピュータ続いて、パーソナルコンピュータ２００の内部構成につ
いて図９を参照して説明する。この図に示すパーソナル
コンピュータ２００は、外部とデータの授受を行うため
のインターフェイスとしてＩＥＥＥ１３９４インターフ
ェイス２０９を備えている。ＩＥＥＥ１３９４インター
フェイス２０９は、外部データバスとしてのＩＥＥＥ１
３９４バス１１６と接続されることで外部機器と相互通
信が可能とされる。ＩＥＥＥ１３９４インターフェイス
２０９は、ＩＥＥＥ１３９４バス１１６を介して受信し
たパケットを復調し、復調したパケットに含まれるデー
タを抽出し、この抽出データを内部データ通信に適合す
るデータフォーマットにより変換を行って、内部バス２
１０を介してＣＰＵ２０１に出力する。また、ＣＰＵ２
０１の制御によって出力されたデータを入力し、パケッ
ト化等のＩＥＥＥ１３９４フォーマットに従った変調処
理を施して、ＩＥＥＥ１３９４バス１１６を介して外部
に送信出力する。

【００６４】ＣＰＵ２０１は、例えばＲＯＭ２０２に保
持されているプログラムに従って各種の処理を実行す
る。本実施の形態では、ＩＥＥＥ１３９４の規格に従っ
て各種データの送受信を可能とするために、上記ＲＯＭ
２０２に対してＩＥＥＥ１３９４インターフェイス２０
９を制御するためのプログラムも格納されることにな
る。つまり、パーソナルコンピュータ１１３において
は、ＩＥＥＥ１３９４によるデータ送受信に可能なセッ
ト（ハードウェア及びソフトウェア）が備えられるもの
である。また、ＲＡＭ２０３にはＣＰＵ２０１が各種処
理を実行するのに必要なデータやプログラム等が適宜保
持される。

【００６５】入出カインターフェイス２０４は、キーボ
ード２０５とマウス２０６が接続されており、これらか
ら供給された操作信号をＣＰＵ２０１に出カするように
されている。また、入出カインターフェイス２０４に
は、記憶媒体としてハードディスクを備えたハードディ
スクドライブ２０７が接続されている。ＣＰＵ２０１
は、入出カインターフェイス２０４を介して、ハードデ
ィスクドライブ２０７のハードディスクに対してデータ
やプログラム等の記録又は読み出しを行うことができる
ようにされている。この場合、入出カインターフェイス
２０４には、さらに、画像表示のためのディスプレイモ
ニタ２０８が接続されている。内部バス２１０は、例え
ば、ＰＣＩ(Peripheral Component Interconnect)又は
ローカルバス等により構成され、内部における各機能回
路部間を相互に接続している。

【００６６】なお、前述したディスクプレーヤ０として
も、ＩＥＥＥ１３９４インターフェイス機能について
は、上記したパーソナルコンピュータ１１３と基本的に
は同様の構成を採る。システムコントローラ１１内に備
えられるとされるＲＯＭ１１ｂに対して、システムコン
トローラ１１１によるＩＥＥＥ１３９４インターフェイ
ス１１０の制御を可能とするためのプログラムが搭載さ
れる。

【００６７】４．ＩＥＥＥ１３９４データインターフェ
イス４−１．概要続いて、本実施の形態において採用されるＩＥＥＥ１３
９４データインターフェイスについて説明する。

【００６８】ＩＥＥＥ１３９４は、シリアルデータ通信
の規格の１つとされる。このＩＥＥＥ１３９４によるデ
ータ伝送方式としては、周期的に通信を行うＩｓｏｃｈ
ｒｏｎｏｕｓ通信方式と、この周期と関係なく非同期で
通信するＡｓｙｎｃｈｒｏｎｏｕｓ通信方式が存在す
る。一般に、Ｉｓｏｃｈｒｏｎｏｕｓ通信方式はデータ
の送受信に用いられ、Ａｓｙｎｃｈｒｏｎｏｕｓ通信方
式は各種制御コマンドの送受信に用いられる。そして、
１本のケーブルを使用して、これら２種類の通信方式に
よって送受信を行うことが出来るようにされている。ま
た、このようなＩｓｏｃｈｒｏｎｏｕｓ通信方式とＡｓ
ｙｎｃｈｒｏｎｏｕｓ通信方式の使い分け方として、或
るメディアに、ＡＶデータ（オーディオデータ、ビデオ
データ等）などの時系列的なデータと、静止画やテキス
トなどの時系列性を有さないとされる補助データが記録
されているようなフォーマットを有する場合、ＡＶデー
タをＩｓｏｃｈｒｏｎｏｕｓ通信により送信し、補助デ
ータはＡｓｙｎｃｈｒｏｎｏｕｓ通信方式により送信す
るという構成を、先に本出願人が提案している。この実
施の形態においても、上記した提案の構成に従い、ディ
スクプレーヤ０にて再生されたオーディオデータに関し
ては、Ｉｓｏｃｈｒｏｎｏｕｓ通信方式により送信出力
を行うものとする。そこで以降、上記したＩＥＥＥ１３
９４規格による本実施の形態の送信形態を前提として、
本実施の形態としての説明を行っていくこととする。

【００６９】４−２．スタックモデル図１０は、本実施の形態が対応するＩＥＥＥ１３９４の
スタックモデルを示している。ＩＥＥＥ１３９４フォー
マットにおいては、Ａｓｙｎｃｈｒｏｎｏｕｓ系（４０
０）とＩｓｏｃｈｒｏｎｏｕｓ系（５００）とに大別さ
れる。ここで、Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）
とＩｓｏｃｈｒｏｎｏｕｓ系（５００）に共通な層とし
て、最下位にＰｈｙｓｉｃａｌＬａｙｅｒ（３０１）
（物理層）が設けられ、その上位にＬｉｎｋＬａｙｅ
ｒ（３０２）（リンク層）が設けられる。Ｐｈｙｓｉｃ
ａｌＬａｙｅｒ（３０１）はハードウェア的な信号伝
送を司るためのレイヤであり、ＬｉｎｋＬａｙｅｒ
（３０２）はＩＥＥＥ１３９４バスを例えば、機器毎に
規定された内部バスに変換するための機能を有する層と
される。

【００７０】ＰｈｙｓｉｃａｌＬａｙｅｒ（３０
１）、ＬｉｎｋＬａｙｅｒ（３０２）、及び次に説明
するＴｒａｎｓａｃｔｉｏｎＬａｙｅｒ（４０１）
は、Ｅｖｅｎｔ／Ｃｏｎｔｒｏｌ／Ｃｏｎｆｉｇｕｒａ
ｔｉｏｎのラインによってＳｅｒｉａｌＢｕｓＭａ
ｎａｇｅｍｅｎｔ３０３とリンクされる。また、ＡＶ
Ｃａｂｌｅ／Ｃｏｎｎｅｃｔｏｒ３０４は、ＡＶデータ
伝送のための物理的なコネクタ、ケーブルを示してい
る。

【００７１】Ａｓｙｎｃｈｒｏｎｏｕｓ系（４００）に
おける上記ＬｉｎｋＬａｙｅｒ（３０２）の上位に
は、ＴｒａｎｓａｃｔｉｏｎＬａｙｅｒ（４０１）が
設けられる。ＴｒａｎｓａｃｔｉｏｎＬａｙｅｒ（４
０１）は、ＩＥＥＥ１３９４としてのデータ伝送プロト
コルを規定する層とされ、基本的なＡｓｙｎｃｈｒｏｎ
ｏｕｓＴｒａｎｓａｃｔｉｏｎとしては、後述するよ
うにして、ＷｒｉｔｅＴｒａｎｓａｃｔｉｏｎ，Ｒｅａ
ｄＴｒａｎｓａｃｔｉｏｎ，ＬｏｃｋＴｒａｎｓａ
ｃｔｉｏｎが規定される。

【００７２】そして、ＴｒａｎｓａｃｔｉｏｎＬａｙ
ｅｒ（４０１）の上層に対してＦＣＰ(Functuin Contro
l Protocol)（４０２）が規定される。ＦＣＰ（４０
２）は、ＡＶ／ＣＣｏｍｍａｎｄ(AV/C Digital Inte
rfase Command Set)（４０３）として規定された制御コ
マンドを利用することで、各種ＡＶ機器に対するコマン
ド制御を実行することが出来るようになっている。

【００７３】また、ＴｒａｎｓａｃｔｉｏｎＬａｙｅ
ｒ（４０１）の上層に対しては、Ｃｏｎｎｅｃｔｉｏｎ
ＭａｎａｇｅｍｅｎｔＰｒｏｃｅｄｕｒｅｓ（５０
５）を利用して、後述するＰｌｕｇ（ＩＥＥＥ１３９４
における論理的な機器接続関係）を設定するためのＰｌ
ｕｇＣｏｎｔｒｏｌｌＲｅｇｉｓｔｅｒｓ（４０
４）が規定される。

【００７４】Ｉｓｏｃｈｒｏｎｏｕｓ系（５００）にお
けるＬｉｎｋＬａｙｅｒ（３０２）の上位には、ＣＩ
ＰＨｅａｄｅｒＦｏｒｍａｔ（５０１）が規定さ
れ、このＣＩＰＨｅａｄｅｒＦｏｒｍａｔ（５０
１）に管理される形態で、ＳＤ−ＤＶＣＲＲｅａｌｔ
ｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０２），ＨＤ−
ＤＶＣＲＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏ
ｎ（５０３），ＳＤＬ−ＤＶＣＲＲｅａｌｔｉｍｅ
Ｔｒａｎｓｍｉｓｓｉｏｎ（５０４），ＭＰＥＧ２−Ｔ
ＳＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５
０５），ＡｕｄｉｏａｎｄＭｕｓｉｃＲｅａｌｔｉ
ｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０６）等の伝送プ
ロトコルが規定されている。

【００７５】ＳＤ−ＤＶＣＲＲｅａｌｔｉｍｅＴｒ
ａｎｓｍｉｓｓｉｏｎ（５０２），ＨＤ−ＤＶＣＲＲ
ｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０
３），ＳＤＬ−ＤＶＣＲＲｅａｌｔｉｍｅＴｒａｎ
ｓｍｉｓｓｉｏｎ（５０４）は、それぞれ、デジタルＶ
ＴＲ(Video Tape Recorder)に対応するデータ伝送プロ
トコルである。ＳＤ−ＤＶＣＲＲｅａｌｔｉｍｅＴ
ｒａｎｓｍｉｓｓｉｏｎ（５０２）が扱うデータは、Ｓ
Ｄ−ＤＶＣＲｒｅｃｏｒｄｉｎｇｆｏｒｍａｔ（５
０８）の規定に従って得られたデータシーケンス（ＳＤ
−ＤＶＣＲｄａｔａｓｅｑｕｅｎｃｅ（５０７））
とされる。また、ＨＤ−ＤＶＣＲＲｅａｌｔｉｍｅ
Ｔｒａｎｓｍｉｓｓｉｏｎ（５０３）が扱うデータは、
ＨＤ−ＤＶＣＲｒｅｃｏｒｄｉｎｇｆｏｒｍａｔ
（５１０）の規定に従って得られたデータシーケンス
（ＳＤ−ＤＶＣＲｄａｔａｓｅｑｕｅｎｃｅ（５０
９））とされる。ＳＤＬ−ＤＶＣＲＲｅａｌｔｉｍｅ
Ｔｒａｎｓｍｉｓｓｉｏｎ（５０４）が扱うデータ
は、ＳＤＬ−ＤＶＣＲｒｅｃｏｒｄｉｎｇｆｏｒｍ
ａｔ（５１２）の規定に従って得られるデータシーケン
ス（ＳＤ−ＤＶＣＲｄａｔａｓｅｑｕｅｎｃｅ（５
１１））となる。

【００７６】ＭＰＥＧ２−ＴＳＲｅａｌｔｉｍｅＴ
ｒａｎｓｍｉｓｓｉｏｎ（５０５）は、例えばデジタル
衛星放送に対応するチューナ等に対応する伝送プロトコ
ルで、これが扱うデータは、ＤＶＢｒｅｃｏｒｄｉｎ
ｇｆｏｒｍａｔ（５１４）或いはＡＴＶｒｅｃｏｒ
ｄｉｎｇｆｏｒｍａｔ（５１５）の規定に従って得ら
れるデータシーケンス（ＭＰＥＧ２−ＴＳｄａｔａ
ｓｅｑｕｅｎｃｅ（５１３））とされる。

【００７７】また、ＡｕｄｉｏａｎｄＭｕｓｉｃ
ＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０
６）は、例えば本実施の形態のＭＤシステムを含むデジ
タルオーディオ機器全般に対応する伝送プロトコルであ
り、これが扱うデータは、ＡｕｄｉｏａｎｄＭｕｓ
ｉｃｒｅｃｏｒｄｉｎｇｆｏｒｍａｔ（５１７）の
規定に従って得られるデータシーケンス（Ａｕｄｉｏ
ａｎｄＭｕｓｉｃｄａｔａｓｅｑｕｅｎｃｅ）と
される。

【００７８】４−３．信号伝送形態図１１は、ＩＥＥＥ１３９４バスとして実際に用いられ
るケーブルの構造例を示している。この図においては、
コネクタ６００Ａと６００Ｂがケーブル６０１を介して
接続されていると共に、ここでは、コネクタ６００Ａと
６００Ｂのピン端子として、ピン番号１〜６の６ピンが
使用される場合を示している。コネクタ６００Ａ，６０
０Ｂに設けられる各ピン端子については、ピン番号１は
電源（ＶＰ）、ピン番号２はグランド（ＶＧ）、ピン番
号３はＴＰＢ１、ピン番号４はＴＰＢ２、ピン番号５は
ＴＰＡ１、ピン番号５はＴＰＡ２とされている。そし
て、コネクタ６００Ａ−６００Ｂ間の各ピンの接続形態
は、ピン番号１（ＶＰ）−ピン番号１（ＶＰ）ピン番号２（ＶＧ）−ピン番号２（ＶＧ）ピン番号３（ＴＰＢ１）−ピン番号５（ＴＰＡ１）ピン番号４（ＴＰＢ２）−ピン番号６（ＴＰＡ２）ピン番号５（ＴＰＡ１）−ピン番号３（ＴＰＢ１）ピン番号６（ＴＰＡ２）−ピン番号３（ＴＰＢ２）のようになっている。そして、上記ピン接続の組のう
ち、ピン番号３（ＴＰＢ１）−ピン番号５（ＴＰＡ１）ピン番号４（ＴＰＢ２）−ピン番号６（ＴＰＡ２）の２本のツイスト線の組により、差動で信号を相互伝送
する信号線６０１Ａを形成し、ピン番号５（ＴＰＡ１）−ピン番号３（ＴＰＢ１）ピン番号６（ＴＰＡ２）−ピン番号３（ＴＰＢ２）の２本のツイスト線の組により、差動で信号を相互伝送
する信号線６０１Ｂを形成している。

【００７９】上記２組の信号線６０１Ａ及び信号線６０
１Ｂにより伝送される信号は、図１２（ａ）に示すデー
タ信号（Ｄａｔａ）と、図１２（ｂ）に示すストローブ
信号（Ｓｔｒｏｂｅ）である。図１２（ａ）に示すデー
タ信号は、信号線６０１Ａ又は信号線６０１Ｂの一方を
使用してＴＰＢ１，２から出力され、ＴＰＡ１，２に入
力される。また、図１２（ｂ）に示すストローブ信号
は、データ信号と、このデータ信号に同期する伝送クロ
ックとについて所定の論理演算を行うことによって得ら
れる信号であり、実際の伝送クロックよりは低い周波数
を有する。このストローブ信号は、信号線６０１Ａ又は
信号線６０１Ｂのうち、データ信号伝送に使用していな
い他方の信号線を使用して、ＴＰＡ１，２から出力さ
れ、ＴＰＢ１，２に入力される。

【００８０】例えば、図１２（ａ），図１２（ｂ）に示
すデータ信号及びストローブ信号が、或るＩＥＥＥ１３
９４対応の機器に対して入力されたとすると、この機器
においては、入力されたデータ信号とストローブ信号と
について所定の論理演算を行って、図１２（ｃ）に示す
ような伝送クロック（Ｃｌｏｃｋ）を生成し、所要の入
力データ信号処理に利用する。ＩＥＥＥ１３９４フォー
マットでは、このようなハードウェア的データ伝送形態
を採ることで、高速な周期の伝送クロックをケーブルに
よって機器間で伝送する必要をなくし、信号伝送の信頼
性を高めるようにしている。なお、上記説明では６ピン
の仕様について説明したが、ＩＥＥＥ１３９４フォーマ
ットでは電源（ＶＰ）とグランド（ＶＧ）を省略して、
２組のツイスト線である信号線６０１Ａ及び信号線６０
１Ｂのみからなる４ピンの仕様も存在する。例えば本実
施の形態のディスクプレーヤ０の実際として、上記４ピ
ン仕様のケーブルを用いれば、ユーザにとってより簡易
なシステムを提供することができる。

【００８１】４−４．機器間のバス接続図１３は、ＩＥＥＥ１３９４バスによる機器間接続の形
態例を模式的に示している。この図では、機器Ａ，Ｂ，
Ｃ，Ｄ，Ｅの５台の機器（Ｎｏｄｅ）がＩＥＥＥ１３９
４バス（即ちケーブルである）によって相互通信可能に
接続されている場合が示されている。ＩＥＥＥ１３９４
インターフェイスでは、機器Ａ，Ｂ，ＣのようにしてＩ
ＥＥＥ１３９４バスにより直列的に接続するいわゆる
「ディージチェーン接続」が可能とされる。また、図１
３の場合であれば、機器Ａと、機器Ｂ，Ｄ，Ｅ間の接続
形態に示すように、或る機器と複数機器とが並列的に接
続されるいわゆる「ブランチ接続」も可能とされる。シ
ステム全体としては、このブランチ接続と上記ディージ
チェーン接続とを併用して最大６３台の機器（Ｎｏｄ
ｅ）を接続可能とされる。但し、ディージチェーン接続
によっては、最大で１６台（１６ポップ）までの接続が
可能とされている。また、ＳＣＳＩで必要とされるター
ミネータはＩＥＥＥ１３９４インターフェイスでは不要
である。そしてＩＥＥＥ１３９４インターフェイスで
は、上記のようにしてディージチェーン接続又はブラン
チ接続により接続された機器間で相互通信を行うことが
可能とされている。つまり、図１３の場合であれば、機
器Ａ，Ｂ，Ｃ，Ｄ，Ｅ間の任意の複数機器間での相互通
信が可能とされる。

【００８２】また、ＩＥＥＥ１３９４バスにより複数の
機器接続を行ったシステム（以降はＩＥＥＥ１３９４シ
ステムともいう）内では、機器ごとに割与えられるＮｏ
ｄｅＩＤを設定する処理が実際には行われる。この処理
を、図１４により模式的に示す。ここで、図１４（ａ）
に示す接続形態によるＩＥＥＥ１３９４システムにおい
て、ケーブルの抜き差し、システムにおける或る機器の
電源のオン／オフ、ＰＨＹ(Physical Layer Protocol)
での自発発生処理等が有ったとすると、ＩＥＥＥ１３９
４システム内においてはバスリセットが発生する。これ
により、各機器Ａ，Ｂ，Ｃ，Ｄ，Ｅ間においてＩＥＥＥ
１３９４バスを介して全ての機器にバスリセット通知を
行う処理が実行される。

【００８３】このバスリセット通知の結果、図１４
（ｂ）に示すようにして、通信（Child−Notify）を行
うことで隣接する機器端子間で親子関係が定義される。
つまり、ＩＥＥＥ１３９４システム内における機器間の
Ｔｒｅｅ構造を構築する。そして、このＴｒｅｅ構造の
構築結果に従って、ルートとしての機器が定義される。
ルートとは、全ての端子が子(Ｃｈ；Child)として定義
された機器であり、図１４（ｂ）の場合であれば、機器
Ｂがルートとして定義されていることになる。逆に言え
ば、例えばこのルートとしての機器Ｂと接続される機器
Ａの端子は親親(Ｐ；Parent)として定義されているもの
である。

【００８４】上記のようにしてＩＥＥＥ１３９４システ
ム内のＴｒｅｅ構造及びルートが定義されると、続いて
は、図１４（ｃ）に示すようにして、各機器から、自己
のＮｏｄｅ−ＩＤの宣言としてＳｅｌｆ−ＩＤパケット
が出力される。そしてルートがこのＮｏｄｅ−ＩＤに対
して順次承認（grant）を行っていくことにより、ＩＥ
ＥＥ１３９４システム内における各機器のアドレス、つ
まりＮｏｄｅ−ＩＤが決定される。

【００８５】４−５．パケットＩＥＥＥ１３９４フォーマットでは、図１５に示すよう
にしてＩｓｏｃｈｒｏｎｏｕｓｃｙｃｌｅ（ｎｏｍｉ
ｎａｌｃｙｃｌｅ）の周期を繰り返すことによって送
信を行う。この場合、１Ｉｓｏｃｈｒｏｎｏｕｓｃｙ
ｃｌｅは、１２５μｓｅｃとされ、帯域としては１００
ＭＨｚに相当する。なお、Ｉｓｏｃｈｒｏｎｏｕｓｃ
ｙｃｌｅの周期としては１２５μｓｅｃ以外とされても
良いことが規定されている。そして、このＩｓｏｃｈｒ
ｏｎｏｕｓｃｙｃｌｅごとに、データをパケット化し
て送信する。

【００８６】この図に示すように、Ｉｓｏｃｈｒｏｎｏ
ｕｓｃｙｃｌｅの先頭には、１Ｉｓｏｃｈｒｏｎｏｕ
ｓｃｙｃｌｅの開始を示すＣｙｃｌｅＳｔａｒｔ
Ｐａｃｋｅｔが配置される。このＣｙｃｌｅＳｔａｒ
ｔＰａｃｋｅｔは、ここでの詳しい説明は省略する
が、ＣｙｃｌｅＭａｓｔｅｒとして定義されたＩＥＥ
Ｅ１３９４システム内の特定の１機器によってその発生
タイミングが指示される。ＣｙｃｌｅＳｔａｒｔＰ
ａｃｋｅｔに続いては、ＩｓｏｃｈｒｏｎｏｕｓＰａｃ
ｋｅｔが優先的に配置される。Ｉｓｏｃｈｒｏｎｏｕｓ
Ｐａｃｋｅｔは、図のように、チャンネルごとにパケ
ット化されたうえで時分割的に配列されて転送される
（Ｉｓｏｃｈｒｏｎｏｕｓｓｕｂａｃｔｉｏｎｓ）。
また、Ｉｓｏｃｈｒｏｎｏｕｓｓｕｂａｃｔｉｏｎｓ
内においてパケット毎の区切りには、Ｉｓｏｃｈｒｏｎ
ｏｕｓｇａｐといわれる休止区間（例えば０．０５μ
ｓｅｃ）が設けられる。このように、ＩＥＥＥ１３９４
システムでは、１つの伝送線路によってＩｓｏｃｈｒｏ
ｎｏｕｓデータをマルチチャンネルで送受信することが
可能とされている。

【００８７】ここで、例えば或るメディアに対応したフ
ォーマットのＡＶデータをＩｓｏｃｈｒｏｎｏｕｓ方式
により送信することを考えた場合、このＡＶデータの１
倍速の転送レートが１．４Ｍｂｐｓであるとすれば、１
２５μｓｅｃである１Ｉｓｏｃｈｒｏｎｏｕｓｃｙｃ
ｌｅ周期ごとに、少なくともほぼ２０数ＭバイトのＡＶ
データをＩｓｏｃｈｒｏｎｏｕｓＰａｃｋｅｔとして
伝送すれば、時系列的な連続性（リアルタイム性）が確
保されることになる。例えば、或る機器が上記したよう
なＡＶデータを送信する際には、ここでの詳しい説明は
省略するが、ＩＥＥＥ１３９４システム内のＩＲＭ(Iso
chronous Resource Manager)に対して、ＡＶデータのリ
アルタイム送信が確保できるだけの、Ｉｓｏｃｈｒｏｎ
ｏｕｓパケットのサイズを要求する。ＩＲＭでは、現
在のデータ伝送状況を監視して許可／不許可を与え、許
可が与えられれば、指定されたチャンネルによって、Ａ
ＶデータをＩｓｏｃｈｒｏｎｏｕｓＰａｃｋｅｔにパ
ケット化して送信することが出来る。これがＩＥＥＥ１
３９４インターフェイスにおける帯域予約といわれるも
のである。

【００８８】Ｉｓｏｃｈｒｏｎｏｕｓｃｙｃｌｅの帯
域内においてＩｓｏｃｈｒｏｎｏｕｓｓｕｂａｃｔｉ
ｏｎｓが使用していない残る帯域を用いて、Ａｓｙｎｃ
ｈｒｏｎｏｕｓｓｕｂａｃｔｉｏｎｓ、即ちＡｓｙｎ
ｃｈｒｏｎｏｕｓのパケット送信が行われる。図１５で
は、ＰａｃｋｅｔＡ，ＰａｃｋｅｔＢの２つのＡｓ
ｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔが送信されている
例が示されている。ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃ
ｋｅｔの後には、ａｃｋｇａｐ（０．０５μｓｅｃ）
の休止期間を挟んで、ＡＣＫ（Acknowledge)といわれる
信号が付随する。ＡＣＫは、後述するようにして、Ａｓ
ｙｎｃｈｒｏｎｏｕｓＴｒａｎｓａｃｔｉｏｎの過程
において、何らかのＡｓｙｎｃｈｒｏｎｏｕｓデータの
受信が有ったことを送信側（Ｃｏｎｔｒｏｌｌｅｒ）に
知らせるためにハードウェア的に受信側（Ｔａｒｇｅ
ｔ）から出力される信号である。また、Ａｓｙｎｃｈｒ
ｏｎｏｕｓＰａｃｋｅｔ及びこれに続くＡＣＫからな
るデータ伝送単位の前後には、１０μｓｅｃ程度のｓｕ
ｂａｃｔｉｏｎｇａｐといわれる休止期間が設けられ
る。

【００８９】４−６．トランザクションルール図１６（ａ）の処理遷移図には、Ａｓｙｎｃｈｒｏｎｏ
ｕｓ通信における基本的な通信規則（トランザクション
ルール）が示されている。このトランザクションルール
は、ＦＣＰによって規定される。図１６（ａ）に示すよ
うに、先ずステップＳ１１により、Ｒｅｑｕｅｓｔｅｒ
（送信側）は、Ｒｅｓｐｏｎｄｅｒ（受信側）に対して
Ｒｅｑｕｅｓｔを送信する。Ｒｅｓｐｏｎｄｅｒでは、
このＲｅｑｕｅｓｔを受信する（ステップＳ１２）と、
先ずＡｃｋｎｏｗｌｅｄｇｅをＲｅｑｕｅｓｔｅｒに返
送する（ステップＳ１３）。送信側では、Ａｃｋｎｏｗ
ｌｅｄｇｅを受信することで、Ｒｅｑｕｅｓｔが受信側
にて受信されたことを認知する（ステップＳ１４）。こ
の後、Ｒｅｓｐｏｎｄｅｒは先のステップＳ１２にて受
信したＲｅｑｕｅｓｔに対する応答として、Ｒｅｓｐｏ
ｎｓｅをＲｅｑｕｅｓｔｅｒに送信する（ステップＳ１
５）。Ｒｅｑｕｅｓｔｅｒでは、Ｒｅｓｐｏｎｓｅを受
信し（ステップＳ１６）、これに応答してＲｅｓｐｏｎ
ｄｅｒに対してＡｃｋｎｏｗｌｅｄｇｅを送信する（ス
テップＳ１７）。ＲｅｓｐｏｎｄｅｒではＡｃｋｎｏｗ
ｌｅｄｇｅを受信することで、Ｒｅｓｐｏｎｓｅが送信
側にて受信されたことを認知する。

【００９０】上記図１６（ａ）により送信されるＲｅｑ
ｕｅｓｔＴｒａｎｓａｃｔｉｏｎとしては、図１６
（ｂ）の左側に示すように、ＷｒｉｔｅＲｅｑｕｅｓ
ｔ、ＲｅａｄＲｅｑｕｅｓｔ、ＬｏｃｋＲｅｑｕｅ
ｓｔの３種類に大別して定義されている。Ｗｒｉｔｅ
Ｒｅｑｕｅｓｔは、データ書き込みを要求するコマンド
であり、ＲｅａｄＲｅｑｕｅｓｔはデータの読み出し
を要求するコマンドである。ＬｏｃｋＲｅｑｕｅｓｔ
はここでは詳しい説明は省略するが、ｓｗａｐｃｏｍ
ｐａｒｅ、マスクなどのためのコマンドである。

【００９１】また、ＷｒｉｔｅＲｅｑｕｅｓｔは、後
に図示して説明するＡｓｙｎｃｈｒｏｎｏｕｓＰａｃ
ｋｅｔ（ＡＶ／ＣＣｏｍｍａｎｄＰａｃｋｅｔ）に
格納するコマンド（ｏｐｅｒａｎｄ）のデータサイズに
応じてさらに３種類が定義される。ＷｒｉｔｅＲｅｑ
ｕｅｓｔ（ｄａｔａｑｕａｄｌｅｔ）は、Ａｓｙｎｃ
ｈｒｏｎｏｕｓＰａｃｋｅｔのヘッダサイズのみによ
りコマンドを送信する。ＷｒｉｔｅＲｅｑｕｅｓｔ
（ｄａｔａｂｌｏｃｋ：ｄａｔａｌｅｎｇｔｈ＝４
ｂｙｔｅ）、ＷｒｉｔｅＲｅｑｕｅｓｔ（ｄａｔａ
ｂｌｏｃｋ：ｄａｔａｌｅｎｇｔｈ≠４ｂｙｔｅ）
は、ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔとしてヘ
ッダに対してｄａｔａｂｌｏｃｋを付加してコマンド
送信を行うもので、両者は、ｄａｔａｂｌｏｃｋに格
納されるｏｐｅｒａｎｄのデータサイズが４バイトであ
るかそれ以上であるのかが異なる。

【００９２】ＲｅａｄＲｅｑｕｅｓｔも同様にして、
ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋｅｔに格納するｏ
ｐｅｒａｎｄのデータサイズに応じて、ＲｅａｄＲｅ
ｑｕｅｓｔ（ｄａｔａｑｕａｄｌｅｔ）、Ｒｅａｄ
Ｒｅｑｕｅｓｔ（ｄａｔａｂｌｏｃｋ：ｄａｔａｌｅ
ｎｇｔｈ＝４ｂｙｔｅ）、ＲｅａｄＲｅｑｕｅｓｔ
（ｄａｔａｂｌｏｃｋ：ｄａｔａｌｅｎｇｔｈ≠４
ｂｙｔｅ）の３種類が定義されている。

【００９３】また、ＲｅｓｐｏｎｓｅＴｒａｎｓａｃ
ｔｉｏｎとしては、図１６（ｂ）の右側に示されてい
る。上述した３種のＷｒｉｔｅＲｅｑｕｅｓｔに対し
ては、ＷｒｉｔｅＲｅｓｐｏｎｓｅ或いはＮｏＲｅ
ｓｐｏｎｓｅが定義される。また、ＲｅａｄＲｅｑｕ
ｅｓｔ（ｄａｔａｑｕａｄｌｅｔ）に対してはＲｅａ
ｄＲｅｓｐｏｎｓｅ（ｄａｔａｑｕａｄｌｅｔ）が
定義され、ＲｅａｄＲｅｑｕｅｓｔ（ｄａｔａｂｌｏ
ｃｋ：ｄａｔａｌｅｎｇｔｈ＝４ｂｙｔｅ）、又はＲ
ｅａｄＲｅｑｕｅｓｔ（ｄａｔａｂｌｏｃｋ：ｄａ
ｔａｌｅｎｇｔｈ≠４ｂｙｔｅ）に対しては、Ｒｅａ
ｄＲｅｓｐｏｎｓｅ（ｄａｔａｂｌｏｃｋ）が定義さ
れる。

【００９４】ＬｏｃｋＲｅｑｕｅｓｔに対しては、Ｌ
ｏｃｋＲｅｓｐｏｎｓｅが定義される。

【００９５】４−７．アドレッシング図１７は、ＩＥＥＥ１３９４バスのアドレッシングの構
造を示している。図１７（ａ）に示すように、ＩＥＥＥ
１３９４フォーマットでは、バスアドレスのレジスタ
（アドレス空間）として６４ビットが用意される。この
レジスタの上位１０ビットの領域は、ＩＥＥＥ１３９４
バスを識別するためのバスＩＤを示し、図１７（ｂ）に
示すようにしてバスＩＤとしてｂｕｓ＃０〜＃１０２２
の計１０２３のバスＩＤを設定可能としている。ｂｕｓ
＃１０２３はｌｏｃａｌｂｕｓとして定義されてい
る。

【００９６】図１７（ａ）においてバスアドレスに続く
６ビットの領域は、上記バスＩＤにより示されるＩＥＥ
Ｅ１３９４バスごとに接続されている機器のＮｏｄｅ
ＩＤを示す。ＮｏｄｅＩＤは、図１７（ｃ）に示すよ
うにして、Ｎｏｄｅ＃０〜＃６２までの６３のＮｏｄ
ｅＩＤを識別可能としている。上記バスＩＤ及びＮｏ
ｄｅＩＤを示す計１６ビットの領域は、後述するＡＶ
／ＣＣｏｍｍａｎｄＰａｃｋｅｔのヘッダにおける
ｄｅｓｔｉｎａｔｉｏｎＩＤに相当するもので、このバ
スＩＤ及びＮｏｄｅＩＤによって、或るバスに接続さ
れた機器がＩＥＥＥ１３９４システム上で特定される。

【００９７】図１７（ａ）においてＮｏｄｅＩＤに続
く２０ビットの領域は、ｒｅｇｉｓｔｅｒｓｐａｃｅ
であり、このｒｅｇｉｓｔｅｒｓｐａｃｅに続く２８
ビットの領域は、ｒｅｇｉｓｔｅｒａｄｄｒｅｓであ
る。ｒｅｇｉｓｔｅｒｓｐａｃｅの値は［ＦＦＦ
ＦＦｈ］とされて、図１７（ｄ）に示すｒｅｇｉｓｔｅ
ｒを示し、このｒｅｇｉｓｔｅｒの内容は、図１７
（ｅ）に示すようにして定義される。ｒｅｇｉｓｔｅｒ
ａｄｄｒｅｓは、図１７（ｅ）に示すレジスタのアド
レスを指定している。

【００９８】簡単に説明すると、図１７（ｅ）のレジス
タにおいて、例えばアドレス５１２［００００２
００ｈ］から始まるＳｅｒｉａｌＢｕｓ−ｄｅｐａｎ
ｄｅｎｔＲｅｇｉｓｔｅｒｓを参照することで、Ｉｓ
ｏｃｈｒｏｎｏｕｓｃｙｃｌｅのサイクルタイムや、
空きチャンネルの情報が得られる。また、アドレス１０
２４［００００４００ｈ］から始まるＣｏｎｆｉ
ｇｕｒａｔｉｏｎＲＯＭの内容を参照すれば、Ｎｏｄ
ｅの機種から、その機種に付されているＮｏｄｅＵｎ
ｉｑｕｅＩＤなども識別することができる。

【００９９】４−８．ＣＩＰ図１８は、ＣＩＰ(Common Isochronos Packet)の構造を
示している。つまり、図１５に示したＩｓｏｃｈｒｏｎ
ｏｕｓＰａｃｋｅｔのデータ構造である。前に述べた
ように、一般にはリアルタイム性が要求されるＡＶデー
タは、ＩＥＥＥ１３９４通信においては、Ｉｓｏｃｈｒ
ｏｎｏｕｓ通信によりデータの送受信が行われる。つま
り、リアルタイム性が維持されるだけのデータ量をこの
ＩｓｏｃｈｒｏｎｏｕｓＰａｃｋｅｔに格納して、１
Ｉｓｏｃｈｒｏｎｏｕｓｃｙｃｌｅ毎に順次送信する
ものである。

【０１００】ＣＩＰの先頭３２ビット（１ｑｕａｄｌｅ
ｔ）は、１３９４パケットヘッダとされている。１３９
４パケットヘッダにおいて上位から順に１６ビットの領
域は、ｄａｔａ＿Ｌｅｎｇｔｈ、続く２ビットの領域は
ｔａｇ、続く６ビットの領域はｃｈａｎｎｅｌ、続く４
ビットはｔｃｏｄｅ、続く４ビットは、ｓｙとされてい
る。そして、１３９４パケットヘッダに続く１ｑｕａｄ
ｌｅｔの領域はｈｅａｄｅｒ＿ＣＲＣが格納される。

【０１０１】ｈｅａｄｅｒ＿ＣＲＣに続く２ｑｕａｄｌ
ｅｔの領域がＣＩＰヘッダとなる。ＣＩＰヘッダの上位
ｑｕａｄｌｅｔの上位２バイトには、それぞれ‘０’
‘０’が格納され、続く６ビットの領域はＳＩＤ（送信
ノード番号）を示す。ＳＩＤに続く８ビットの領域はＤ
ＢＳ（データブロックサイズ）であり、データブロック
のサイズ（パケット化の単位データ量）が示される。続
いては、ＦＮ（２ビット）、ＱＰＣ（３ビット）の領域
が設定されており、ＦＮにはパケット化する際に分割し
た数が示され、ＱＰＣには分割するために追加したｑｕ
ａｄｌｅｔ数が示される。ＳＰＨ（１ビット）にはソー
スパケットのヘッダのフラグが示され、ＤＢＣにはパケ
ットの欠落を検出するカウンタの値が格納される。

【０１０２】ＣＩＰヘッダの下位ｑｕａｄｌｅｔの上位
２バイトにはそれぞれ‘０’‘０’が格納される。そし
て、これに続いてＦＭＴ（６ビット）、ＦＤＦ（２４ビ
ット）の領域が設けられる。ＦＭＴには信号フォーマッ
ト（伝送フォーマット）が示され、ここに示される値に
よって、当該ＣＩＰに格納されるデータ種類（データフ
ォーマット）が識別可能となる。具体的には、ＭＰＥＧ
ストリームデータ、Ａｕｄｉｏストリームデータ、デジ
タルビデオカメラ（ＤＶ）ストリームデータ等の識別が
可能になる。このＦＭＴにより示されるデータフォーマ
ットは、例えば図１０に示した、ＣＩＰＨｅａｄｅｒ
Ｆｏｒｍａｔ（４０１）に管理される、ＳＤ−ＤＶＣ
ＲＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５
０２），ＨＤ−ＤＶＣＲＲｅａｌｔｉｍｅＴｒａｎ
ｓｍｉｓｓｉｏｎ（５０３），ＳＤＬ−ＤＶＣＲＲｅ
ａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５０４），
ＭＰＥＧ２−ＴＳＲｅａｌｔｉｍｅＴｒａｎｓｍｉ
ｓｓｉｏｎ（５０５），ＡｕｄｉｏａｎｄＭｕｓｉ
ｃＲｅａｌｔｉｍｅＴｒａｎｓｍｉｓｓｉｏｎ（５
０６）等の伝送プロトコルに対応する。ＦＤＦは、フォ
ーマット依存フィールドであり、上記ＦＭＴにより分類
されたデータフォーマットについて更に細分化した分類
を示す領域とされる。オーディオに関するデータで有れ
ば、例えばリニアオーディオデータであるのか、ＭＩＤ
Ｉデータであるのかといった識別が可能になる。例えば
本実施の形態のディスクプレーヤにより再生可能なＣＤ
−ＤＡデータであれば、先ずＦＭＴによりＡｕｄｉｏス
トリームデータの範疇にあるデータであることが示さ
れ、ＦＤＦに規定に従った特定の値が格納されること
で、そのＡｕｄｉｏストリームデータはＣＤ−ＤＡデー
タであることが示される。

【０１０３】ここで、例えばＦＭＴによりＭＰＥＧであ
ることが示されている場合、ＦＤＦにはＴＳＦ（タイム
シフトフラグ）といわれる同期制御情報が格納される。
また、ＦＭＴによりＤＶＣＲ（デジタルビデオカメラ）
であることが示されている場合、ＦＤＦは、図１８の下
に示すように定義される。ここでは、上位から順に、５
０／６０（１ビット）により１秒間のフィールド数を規
定し、ＳＴＹＰＥ（５ビット）によりビデオのフォーマ
ットがＳＤとＨＤの何れとされてるのかが示され、ＳＹ
Ｔによりフレーム同期用のタイムスタンプが示される。

【０１０４】上記ＣＩＰヘッダに続けては、ＦＭＴ，Ｆ
ＤＦによって示されるデータが、ｎ個のデータブロック
のシーケンスによって格納される。ＦＭＴ，ＦＤＦによ
りＣＤ−ＤＡデータであることが示される場合には、こ
のデータブロックとしての領域にＣＤ−ＤＡデータが格
納される。そして、データブロックに続けては、最後に
ｄａｔａ＿ＣＲＣが配置される。

【０１０５】４−９．コネクションマネージメントＩＥＥＥ１３９４フォーマットにおいては、「プラグ」
といわれる論理的接続概念によって、ＩＥＥＥ１３９４
バスによって接続された機器間の接続関係が規定され
る。図１９は、プラグにより規定された接続関係例を示
しており、この場合には、ＩＥＥＥ１３９４バスを介し
て、ＶＴＲ１、ＶＴＲ２、セットトップボックス（ＳＴ
Ｂ；デジタル衛星放送チューナ）、モニタ装置（Ｍｏｎ
ｉｔｏｒ）、及びデジタルスチルカメラ（Ｃａｍｅｒ
ａ）が接続されているシステム形態が示されている。

【０１０６】ここで、ＩＥＥＥ１３９４のプラグによる
接続形態としては、ｐｏｉｎｔｔｏｐｏｉｎｔ−ｃ
ｏｎｎｅｃｔｉｏｎと、ｂｒｏａｄｃａｓｔｃｏｎｎ
ｅｃｔｉｏｎとの２つの形態が存在する。ｐｏｉｎｔ
ｔｏｐｏｉｎｔ−ｃｏｎｎｅｃｔｉｏｎは、送信機器
と受信機器との関係が特定され、かつ、特定のチャンネ
ルを使用して送信機器と受信機器との間でデータ伝送が
行われる接続形態である。これに対して、ｂｒｏａｄｃ
ａｓｔｃｏｎｎｅｃｔｉｏｎは、送信機器において
は、特に受信機器及び使用チャンネルを特定せずに送信
を行うものである。受信機側では、特に送信機器を識別
することなく受信を行い、必要が有れば、送信されたデ
ータの内容に応じた所要の処理を行う。図１９の場合で
あれば、ｐｏｉｎｔｔｏｐｏｉｎｔ−ｃｏｎｎｅｃ
ｔｉｏｎとして、ＳＴＢが送信、ＶＴＲ１が受信とされ
てチャンネル＃１を使用してデータの伝送が行われるよ
うに設定されている状態と、デジタルスチルカメラが送
信、ＶＴＲ２が受信とされてチャンネル＃２を使用して
データの伝送が行われるように設定されている状態とが
示されている。また、デジタルスチルカメラからは、ｂ
ｒｏａｄｃａｓｔｃｏｎｎｅｃｔｉｏｎによってもデ
ータ送信を行うように設定されている状態が示されてお
り、ここでは、このｂｒｏａｄｃａｓｔｃｏｎｎｅｃ
ｔｉｏｎによって送信したデータを、モニタ装置が受信
して所要の応答処理を行う場合が示される。

【０１０７】上記のような接続形態（プラグ）は、各機
器におけるアドレス空間に設けられるＰＣＲ(Plug Cont
orol Register)によって確立される。図２０（ａ）は、
ｏＰＣＲ［ｎ］（出力用プラグコントロールレジスタ）
の構造を示し、図２０（ｂ）は、ｉＰＣＲ［ｎ］（入力
用プラグコントロールレジスタ）の構造を示している。
これらｏＰＣＲ［ｎ］、ｉＰＣＲ［ｎ］のサイズは共に
３２ビットとされている。図２０（ａ）のｏＰＣＲにお
いては、例えば上位１ビットのｏｎ−ｌｉｎｅに対して
‘１’が格納されていると、ｂｒｏａｄｃａｓｔｃｏ
ｎｎｅｃｔｉｏｎによる送信であることが示され、
‘０’が格納されていると、上位１１ビット目から６ビ
ットの領域のｃｈａｎｎｅｌｎｕｍｂｅｒで示される
チャンネルにより、ｐｏｉｎｔｔｏｐｏｉｎｔｃ
ｏｎｎｅｃｔｉｏｎで送信することが示される。また、
図２０（ｂ）のｉＰＣＲにおいても、例えば上位１ビッ
トのｏｎ−ｌｉｎｅに対して‘１’が格納されていれ
ば、ｂｒｏａｄｃａｓｔｃｏｎｎｅｃｔｉｏｎによる
受信であることが示され、‘０’が格納されていると、
上位１１ビット目から６ビットの領域のｃｈａｎｎｅｌ
ｎｕｍｂｅｒで示されるチャンネルにより送信された
データをｐｏｉｎｔｔｏｐｏｉｎｔｃｏｎｎｅｃ
ｔｉｏｎで送信することが示される。

【０１０８】４−１０．ＦＣＰにおけるコマンド及びレ
スポンス本実施の形態のＩＥＥＥ１３９４フォーマットでは、各
種コマンドは、Ａｓｙｎｃｈｒｏｎｏｕｓ通信によりデ
ータの送受信が行われる。ここでは、ＦＣＰにより規定
されるトランザクションについて説明する。

【０１０９】ＦＣＰとしては、Ａｓｙｎｃｈｒｏｎｏｕ
ｓ通信において規定されるＷｒｉｔｅＴｒａｎｓａｃ
ｔｉｏｎ（図１６参照）を使用する。ＦＣＰをサポート
する機器は、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジス
タを備え、次に図２１により説明するようにしてＣｏｍ
ｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対してＭｅｓｓ
ａｇｅを書き込むことでトランザクションを実現する。

【０１１０】図２１の処理遷移図においては、先ずＣＯ
ＭＭＡＮＤ送信のための処理として、ステップＳ２１と
して示すように、ＣｏｎｔｒｏｌｌｅｒがＴｒａｎｓａ
ｃｔｉｏｎＲｅｑｕｅｓｔを発生して、Ｗｒｉｔｅ
ＲｅｑｕｅｓｔＰａｃｋｅｔをＴａｒｇｅｔに対して
送信する処理を実行する。Ｔａｒｇｅｔでは、ステップ
Ｓ２２として、このＷｒｉｔｅＲｅｑｕｅｓｔＰａ
ｃｋｅｔを受信して、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃ
ｅレジスタに対してデータの書き込みを行う。また、こ
の際、ＴａｒｇｅｔからはＣｏｎｔｒｏｌｌｅｒに対し
てＡｃｋｎｏｗｌｅｄｇを送信し、Ｃｏｎｔｒｏｌｌｅ
ｒでは、このＡｃｋｎｏｗｌｅｄｇを受信する（Ｓ２３
→Ｓ２４）。ここまでの一連の処理が、ＣＯＭＭＡＮＤ
の送信に対応する処理となる。

【０１１１】続いては、ＣＯＭＭＡＮＤに応答した、Ｒ
ＥＳＰＯＮＣＥのための処理として、Ｔａｒｇｅｔから
ＷｒｉｔｅＲｅｑｕｅｓｔＰａｃｋｅｔが送信され
る（Ｓ２５）。Ｃｏｎｔｒｏｌｌｅｒではこれを受信し
て、Ｃｏｍｍａｎｄ／Ｒｅｓｐｏｎｃｅレジスタに対し
てデータの書き込みを行う（Ｓ２６）。また、Ｃｏｎｔ
ｒｏｌｌｅｒでは、ＷｒｉｔｅＲｅｑｕｅｓｔＰａ
ｃｋｅｔの受信に応じて、Ｔａｒｇｅｔに対してＡｃｋ
ｎｏｗｌｅｄｇを送信する（Ｓ２７）。Ｔａｒｇｅｔで
は、このＡｃｋｎｏｗｌｅｄｇを受信することで、Ｗｒ
ｉｔｅＲｅｑｕｅｓｔＰａｃｋｅｔがＣｏｎｔｒｏ
ｌｌｅｒにて受信されたことを知る（Ｓ２８）。つま
り、ＣｏｎｔｒｏｌｌｅｒからＴａｒｇｅｔ対するＣＯ
ＭＭＡＮＤ伝送処理と、これに応答したＴａｒｇｅｔか
らＣｏｎｔｒｏｌｌｅｒに対するＲＥＳＰＯＮＣＥ伝送
処理が、ＦＣＰによるデータ伝送（Ｔｒａｎｓａｃｔｉ
ｏｎ）の基本となる。

【０１１２】４−１１．ＡＶ／Ｃコマンドパケット図１０により説明したように、Ａｓｙｎｃｈｒｏｎｏｕ
ｓ通信において、ＦＣＰは、ＡＶ／Ｃコマンドを用いて
各種ＡＶ機器に対する通信を行うことができるようにさ
れている。Ａｓｙｎｃｈｒｏｎｏｕｓ通信では、Ｗｒｉ
ｔｅ，Ｒｅａｄ，Ｌｏｃｋの３種のトランザクションが
規定されているのは、図１６にて説明した通りであり、
実際には各トランザクションに応じたＷｒｉｔｅＲｅ
ｑｕｅｓｔ／ＲｅｓｐｏｎｃｅＰａｃｋｅｔ，Ｒｅａ
ｄＲｅｑｕｅｓｔ／ＲｅｓｐｏｎｃｅＰａｃｋｅ
ｔ，ＬｏｃｋＲｅｑｕｅｓｔ／ＲｅｓｐｏｎｃｅＰ
ａｃｋｅｔが用いられる。そして、ＦＣＰでは、上述し
たようにＷｒｉｔｅＴｒａｎｓａｃｔｉｏｎを使用す
るものである。そこで図２２に、ＷｒｉｔｅＲｅｑｕ
ｅｓｔＰａｃｋｅｔ（AsynchronousPacket（Write Re
quest for Data Block)）のフォーマットを示す。本実
施の形態では、このＷｒｉｔｅＲｅｑｕｅｓｔＰａ
ｃｋｅｔが即ち、ＡＶ／Ｃコマンドパケットとして使用
される。

【０１１３】このＷｒｉｔｅＲｅｑｕｅｓｔＰａｃ
ｋｅｔにおける上位５ｑｕａｄｌｅｔ（第１〜第５ｑｕ
ａｄｌｅｔ）は、ｐａｃｋｅｔｈｅａｄｅｒとされ
る。ｐａｃｋｅｔｈｅａｄｅｒの第１ｑｕａｄｌｅｔ
における上位１６ビットの領域はｄｅｓｔｉｎａｔｉｏ
ｎ＿ＩＤで、データの転送先（宛先）のＮｏｄｅＩＤを
示す。続く６ビットの領域はｔｌ(transact label)であ
り、パケット番号を示す。続く２ビットはｒｔ(retry c
ode)であり、当該パケットが初めて伝送されたパケット
であるか、再送されたパケット示す。続く４ビットの領
域はｔｃｏｄｅ(transaction code)は、指令コードを示
している。そして、続く４ビットの領域はｐｒｉ(prior
ity)であり、パケットの優先順位を示す。

【０１１４】第２ｑｕａｄｌｅｔにおける上位１６ビッ
トの領域はｓｏｕｒｃｅ＿ＩＤであり、データの転送元
のＮｏｄｅ＿ＩＤが示される。また、第２ｑｕａｄｌ
ｅｔにおける下位１６ビットと第３ｑｕａｄｌｅｔ全体
の計４８ビットはｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅ
ｔとされ、ＣＯＭＭＡＮＤレジスタ（ＦＣＰ＿ＣＯＭＭ
ＡＮＤｒｅｇｉｓｔｅｒ）とＲＥＳＰＯＮＣＥレジス
タ（ＦＣＰ＿ＲＥＳＰＯＮＣＥｒｅｇｉｓｔｅｒ）の
アドレスが示されれる。上記ｄｅｓｔｉｎａｔｉｏｎ＿
ＩＤ及びｄｅｓｔｉｎａｔｉｏｎ＿ｏｆｆｓｅｔが、Ｉ
ＥＥＥ１３９４フォーマットにおいて規定される６４ビ
ットのアドレス空間に相当する。

【０１１５】第４ｑｕａｄｌｅｔの上位１６ビットの領
域は、ｄａｔａ＿ｌｅｎｇｔｈとされ、後述するｄａｔ
ａｆｉｅｌｄ（図２２において太線により囲まれる領
域）のデータサイズが示される。続く下位１６ビットの
領域は、ｅｘｔｅｎｄｅｄ＿ｔｃｏｄｅの領域とされ、
ｔｃｏｄｅを拡張する場合に使用される領域である。

【０１１６】第５ｑｕａｄｌｅｔとしての３２ビットの
領域は、ｈｅａｄｅｒ＿ＣＲＣであり、Ｐａｃｋｅｔ
ｈｅａｄｅｒのチェックサムを行うＣＲＣ計算値が格納
される。

【０１１７】Ｐａｃｋｅｔｈｅａｄｅｒに続く第６ｑ
ｕａｄｌｅｔからｄａｔａｂｌｏｃｋが配置され、こ
のｄａｔａｂｌｏｃｋ内の先頭に対してｄａｔａｆｉ
ｅｌｄが形成される。ｄａｔａｆｉｅｌｄとして先頭と
なる第６ｑｕａｄｌｅｔの上位４バイトには、ＣＴＳ(C
ommand and Transaction Set)が記述される。これは、
当該ＷｒｉｔｅＲｅｑｕｅｓｔＰａｃｋｅｔのコマ
ンドセットのＩＤを示すもので、例えば、このＣＴＳの
値について、図のように［００００］と設定すれば、ｄ
ａｔａｆｉｅｌｄに記述されている内容がＡＶ／Ｃコマ
ンドであると定義されることになる。つまり、このＷｒ
ｉｔｅＲｅｑｕｅｓｔＰａｃｋｅｔは、ＡＶ／Ｃコ
マンドパケットであることが示されるものである。従っ
て、本実施の形態においては、ＦＣＰがＡＶ／Ｃコマン
ドを使用するため、このＣＴＳには［００００］が記述
されることになる。

【０１１８】ＣＴＳに続く４ビットの領域は、ｃｔｙｐ
ｅ(Command type；コマンドの機能分類)、又はコマンド
に応じた処理結果(レスポンス)を示すｒｅｓｐｏｎｓｅ
が記述される。

【０１１９】図２３に、上記ｃｔｙｐｅ及びｒｅｓｐｏ
ｎｓｅの定義内容を示す。ｃｔｙｐｅ（Ｃｏｍｍａｎ
ｄ）としては、［００００］〜［０１１１］を使用でき
るものとしており、［００００］はＣＯＮＴＲＯＬ、
［０００１］はＳＴＡＴＵＳ、［００１０］はＩＮＱＵ
ＩＲＹ、［００１１］はＮＯＴＩＦＹとして定義され、
［０１００］〜０１１１は、現状、未定義（ｒｅｓｅｒ
ｖｅｄ）とされている。ＣＯＮＴＲＯＬは機能を外部か
ら制御するコマンドであり、ＳＴＡＴＵＳは外部から状
態を間い合わせるコマンド、ＩＮＱＵＩＲＹは、制御コ
マンドのサポートの有無を外部から問い合わせるコマン
ド、ＮＯＴＩＦＹは状態の変化を外部に知らせることを
要求するコマンドである。また、ｒｅｓｐｏｎｓｅとし
ては、［１０００］〜［１１１１］を使用するものとし
ており、［１０００］はＮＯＴＩＭＰＬＥＭＥＮＴＥ
Ｄ、［１００１］はＡＣＣＥＰＴＥＤ、［１０１０］は
ＲＥＪＥＣＴＥＤ、［１０１１］はＩＮＴＲＡＮＳＩＴ
ＩＯＮ、［１１００］はＩＭＰＬＥＭＥＮＴＥＤ／ＳＴ
ＡＢＬＥ、［１１０１］はＣＨＡＮＧＥＤ、［１１１
０］はｒｅｓｅｒｖｅｄ、［１１１１］はＩＮＴＥＲＩ
Ｍとしてそれぞれ定義されている。これらのｒｅｓｐｏ
ｎｓｅは、コマンドの種類に応じて使い分けられる。例
えば、ＣＯＮＴＯＲＯＬのコマンドに対応するｒｅｓｐ
ｏｎｓｅとしては、ＮＯＴＩＭＰＬＥＭＥＮＴＥＤ、Ａ
ＣＣＥＰＴＥＤ、ＲＥＪＥＣＴＥＤ、或いはＩＮＴＥＲ
ＩＭの4つのうちの何れかがＲｅｓｐｏｎｄｅｒ側の状
況等に応じて使い分けられる。

【０１２０】図２２において、ｃｔｙｐｅ／ｒｅｓｐｏ
ｎｓｅに続く５ビットの領域には、ｓｕｂｕｎｉｔ−ｔ
ｙｐｅが格納される。は、ｓｕｂｕｎｉｔ−ｔｙｐｅ
は、ＣＯＭＭＭＡＮＤの宛先またはＲＥＳＰＯＮＣＥの
送信元のｓｕｂｕｎｉｔが何であるのか（機器）を示
す。ＩＥＥＥ１３９４フォーマットでは、機器そのもの
をｕｎｉｔと称し、そのｕｎｉｔ（機器）内において備
えられる機能的機器単位の種類をｓｕｂｕｎｉｔと称す
る。例えば一般のＶＴＲを例に採れば、ＶＴＲとしての
ｕｎｉｔは、地上波や衛星放送を受信するチューナと、
ビデオカセットレコーダ／プレーヤとの、２つのｓｕｂ
ｕｎｉｔを備える。ｓｕｂｕｎｉｔ−ｔｙｐｅとして
は、例えば図２４（ａ）に示すように定義されている。
つまり、［０００００］はＭｏｎｉｔｏｒ、［００００
１］〜［０００１０］はｒｅｓｅｒｖｅｄ、［０００１
１］はＤｉｓｃｒｅｃｏｒｄｅｒ／ｐｌａｙｅｒ、
［００１００］はＶＣＲ、［００１０１］はＴｕｎｅ
ｒ、［００１１１］はＣａｍｅｒａ、［０１０００］〜
［１１１１０］はｒｅｓｅｒｖｅｄ、［１１１１１］
は、ｓｕｂｕｎｉｔが存在しない場合に用いられるｕｎ
ｉｔとして定義されている。

【０１２１】図２２において、上記ｓｕｂｕｎｉｔ−ｔ
ｙｐｅに続く３ビットには、同―種類のｓｕｂｕｎｉｔ
が複数存在する場合に、各ｓｕｂｕｎｉｔを特定するた
めのｉｄ（Ｎｏｄｅ＿ＩＤ）が格納される。

【０１２２】上記ｉｄ（Ｎｏｄｅ＿ＩＤ）に続く８ビッ
トの領域には、ｏｐｃｏｄｅが格納され、続く８ビット
の領域には、ｏｐｅｒａｎｄが格納される。ｏｐｃｏｄ
ｅとは、オぺレーションコード(Operation Code)のこと
であって、ｏｐｅｒａｎｄには、ｏｐｃｏｄｅが必要と
する情報（パラメータ）が格納される。これらｏｐｃｏ
ｄｅはｓｕｂｕｎｉｔごとに定義され、ｓｕｂｕｎｉｔ
ごとに固有のｏｐｃｏｄｅのリストのテーブルを有す
る。例えば、ｓｕｂｕｎｉｔがＶＣＲであれば、ｏｐｃ
ｏｄｅとしては、例えば図２４（ｂ）に示すようにし
て、ＰＬＡＹ（再生），ＲＥＣＯＲＤ（記録）などをは
じめとする各種コマンドが定義されている。ｏｐｅｒａ
ｎｄは、ｏｐｃｏｄｅ毎に定義される。

【０１２３】図２２におけるｄａｔａｆｉｅｌｄとして
は、上記第６ｑｕａｄｌｅｔの３２ビットが必須とされ
るが、必要が有れば、これに続けて、ｏｐｅｒａｎｄを
追加することが出来る（Ａｄｄｉｔｉｏｎａｌｏｐｅ
ｒａｎｄｓ）。ｄａｔａｆｉｅｌｄに続けては、ｄａｔ
ａ＿ＣＲＣが配置される。なお、必要が有れば、ｄａｔ
ａ＿ＣＲＣの前にｐａｄｄｉｎｇを配置することが可能
である。

【０１２４】４−１２．プラグここで、ＩＥＥＥ１３９４フォーマットにおけるプラグ
について概略的に説明する。ここでいうプラグとは、先
に図２０によっても説明したように、ＩＥＥＥ１３９４
フォーマットにおける機器間の論理的接続関係をいうも
のである。

【０１２５】図２５に示すように、Ａｓｙｎｃｈｒｏｎ
ｏｕｓ通信において有効とされるコマンド等のデータ
（ｒｅｑｕｅｓｔ）は、ｐｒｏｄｕｃｅｒからｃｏｎｓ
ｕｍｅｒに対して伝送される。ここでいうｐｒｏｄｕｃ
ｅｒ及びｃｏｎｓｕｍｅｒは、それぞれＩＥＥＥ１３９
４インターフェイス上で送信機器、受信機器として機能
する機器をいうものである。そして、ｃｏｎｓｕｍｅｒ
においては、図に斜線で示すように、ｐｒｏｄｕｃｅｒ
によりデータ書き込みが行われるセグメントバッファ
（Segment Buffer）を備える。また、ＩＥＥＥ１３９４
システムにおいて、特定の機器をｐｒｏｄｕｃｅｒ、ｃ
ｏｎｓｕｍｅｒとして規定するための情報（Connection
Management Information）は、図に網線で示すプラグ
アドレス内の所定位置に格納されている。セグメントバ
ッファは、プラグアドレスに続いて配置される。ｃｏｎ
ｓｕｍｅｒのセグメントバッファに対して書き込み可能
なアドレス範囲（データ量）は、後述するようにしてｃ
ｏｎｓｕｍｅｒ側で管理するｌｉｍｉｔＣｏｕｎｔｒ
ｅｇｉｓｔｅｒによって規定される。

【０１２６】図２６は、Ａｓｙｎｃｈｒｏｎｏｕｓ通信
におけるプラグのアドレス空間の構造を示している。６
４ビットから成るプラグのアドレス空間は、図２６
（ａ）に示すようにして、２の１６乗（６４Ｋ）のＮｏ
ｄｅに分割される。そして、プラグは、図２６（ｂ）に
示すようにして、各Ｎｏｄｅのアドレス空間内に在るよ
うにされる。そして、各プラグは、図２６（ｃ）に示す
ように、網線の領域により示すレジスタ（ｒｅｇｉｓｔ
ｅｒ）と、斜線の領域により示すセグメントバッファ(S
egment Buffer)とを含んで形成される。レジスタには、
次に説明するようにして、送信側（ｐｒｏｄｕｃｅｒ）
と受信側（ｃｏｎｓｕｍｅｒ）との間におけるデータの
授受管理に必要な情報（例えば、送信データサイズ及び
受信可能データサイズ）が格納される。セグメントバッ
ファは、ｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対し
て送信されたデータが書き込まれるべき領域であり、例
えば最小で６４バイトであることが規定されている。

【０１２７】図２７（ａ）にはプラグアドレスが示され
ている。つまり、上記図２６（ｃ）と同一内容が示され
ている。この図に示すように、レジスタはプラグアドレ
スの先頭に対して配置され、これに続けてセグメントバ
ッファが配置される。そして、レジスタ内の構造として
は、図２７（ｂ）に示すようにして、先頭に対して、例
えば３２ビットのｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅ
ｇｉｓｔｅｒが配置され、続けて、各３２ビットのｌｉ
ｍｉｔＣｏｕｎｔｒｅｇｉｓｔｅｒ［１］〜［１
４］が配置される。つまり、１つのｐｒｏｄｕｃｅｒ
Ｃｏｕｎｔｒｅｇｉｓｔｅｒと１４のｌｉｍｉｔＣ
ｏｕｎｔｒｅｇｉｓｔｅｒが設けられる。なお、ここ
では、ｌｉｍｉｔＣｏｕｎｔｒｅｇｉｓｔｅｒ［１
４］の後ろに未使用（ｕｎｕｓｅｄ）の領域が設けられ
ている。

【０１２８】上記図２７（ａ）（ｂ）に示すプラグ構造
は、図２７（ｃ）に示すようにして、オフセットアドレ
ス(Address Offset)によって指定される。つまり、オフ
セットアドレス０は、ｃｏｎｓｕｍｅｒｐｏｒｔ（ｐ
ｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒ）を指
定し、オフセットアドレス４，８，１２・・・５６，６
０は、それぞれｐｒｏｄｕｃｅｒｐｏｒｔ［１］〜
［１４］を指定する。オフセットアドレス６０はｒｅｓ
ｅｒｖｅｄとして定義されることで、未使用（ｕｎｕｓ
ｅｄ）の領域を示し、オフセットアドレス６４によりセ
グメントバッファを示す。

【０１２９】図２８には、ｐｒｏｄｕｃｅｒ側とｃｏｎ
ｓｕｍｅｒ側との両者のプラグ構造が示されている。Ａ
ｓｙｎｃｈｒｏｎｏｕｓ通信のプラグ構造においては、
ｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒへの書
き込み、ｌｉｍｉｔＣｏｕｎｔｒｅｇｉｓｔｅｒへ
の書き込み、及びセグメントバッファへの書き込みを後
述する送受信手順に従って行うことで、Ａｓｙｎｃｈｒ
ｏｎｏｕｓ通信を実現する。これらの書き込みは、先に
説明したＷｒｉｔｅＴｒａｎｓａｃｔｉｏｎとしての
処理である。

【０１３０】ｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉ
ｓｔｅｒは、ｐｒｏｄｕｃｅｒによってｃｏｎｓｕｍｅ
ｒに対して書き込みが行われる。ｐｒｏｄｕｃｅｒは、
自身のアドレスに在るｐｒｏｄｕｃｅｒＣｏｕｎｔｒ
ｅｇｉｓｔｅｒにｐｒｏｄｕｃｅｒ側のデータ伝送に関
する情報を書き込んだ上で、このｐｒｏｄｕｃｅｒＣ
ｏｕｎｔｒｅｇｉｓｔｅｒの内容を、ｃｏｎｓｕｍｅ
ｒのｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒ
に対して書き込む。ｐｒｏｄｕｃｅｒＣｏｕｎｔｒ
ｅｇｉｓｔｅｒは、ｐｒｏｄｕｃｅｒがｃｏｎｓｕｍｅ
ｒのセグメントバッファに対して書き込むデータサイズ
として、１回の書き込み処理によって書き込むデータサ
イズの情報とされる。つまり、ｐｒｏｄｕｃｅｒが、ｐ
ｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒの書き
込みを行うことによって、ｃｏｎｓｕｍｅｒのセグメン
トバッファに書き込むデータサイズを知らせる処理が行
われる。

【０１３１】これに対して、ｌｉｍｉｔＣｏｕｎｔ
ｒｅｇｉｓｔｅｒは、ｃｏｎｓｕｍｅｒによってｐｒｏ
ｄｕｃｅｒに対して書き込みが行われる。ｃｏｎｓｕｍ
ｅｒ側では、自身のｌｉｍｉｔＣｏｕｎｔｒｅｇｉ
ｓｔｅｒ［１］〜［１４］のうち、ｐｒｏｄｕｃｅｒに
対応して指定された１つのｌｉｍｉｔＣｏｕｎｔｒ
ｅｇｉｓｔｅｒ［ｎ］に対して、自身のセグメントバッ
ファの容量（サイズ）を書き込み、このｌｉｍｉｔＣ
ｏｕｎｔｒｅｇｉｓｔｅｒ［ｎ］の内容を、ｌｉｍｉ
ｔＣｏｕｎｔｒｅｇｉｓｔｅｒ［ｎ］に対して書き
込む。

【０１３２】ｐｒｏｄｕｃｅｒ側では、上記のようにし
てｌｉｍｉｔＣｏｕｎｔｒｅｇｉｓｔｅｒ［ｎ］に
書き込まれた内容に応じて、１回あたりの書き込みデー
タ量を決定して、例えば自身のセグメントバッファに対
して書き込みを行う。そして、このセグメントバッファ
に書き込んだ内容を、ｃｏｎｓｕｍｅｒに対して書き込
むようにされる。このセグメントバッファへの書き込み
が、Ａｓｙｎｃｈｒｏｎｏｕｓ通信におけるデータ送信
に相当する。

【０１３３】４−１３．Asynchronous Connection送信
手順続いて、上記図２８により説明したプラグ（ｐｒｏｄｕ
ｃｅｒ−ｃｏｎｓｕｍｅｒ）間の構造を前提として、図
２９の処理遷移図により、Ａｓｙｎｃｈｒｏｎｏｕｓ
ｃｏｎｎｅｃｔｉｏｎの基本的な送受信手順について説
明する。図２９に示す送受信処理の手順は、Ａｓｙｎｃ
ｈｒｏｎｏｕｓ通信として、ＦＣＰによって規定された
環境のもとで、ＡＶ／Ｃコマンド（ＷｒｉｔｅＲｅｑ
ｕｅｓｔＰａｃｋｅｔ）を使用して行われる。なお、
Ａｓｙｎｃｈｒｏｎｏｕｓｃｏｎｎｅｃｔｉｏｎの実
際においては、コマンド送信に応じて、図２１に示した
ように、Ａｃｋｎｏｗｌｅｄｇの送受信が実行されるの
であるが、図２９においてはＡｃｋｎｏｗｌｅｄｇにつ
いての送受信処理の図示は省略している。

【０１３４】また、ＩＥＥＥ１３９４インターフェイス
では、プラグ（機器）間の接続関係として、上記したｐ
ｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係の他に、ｃｏ
ｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔとして規定される関係
が存在する。ＩＥＥＥ１３９４システム上においては、
ｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍｅｒの関係が規定され
た機器と、ｃｏｎｔｒｏｌｌｅｒ−ｔａｒｇｅｔの関係
が機器とが必ずしも一致するものではない。つまり、ｐ
ｒｏｄｕｃｅｒとして規定された機器の他に、ｃｏｎｔ
ｒｏｌｌｅｒの機能を有するものとして規定された機器
が存在する場合がある。但し、ここでは、ｐｒｏｄｕｃ
ｅｒ−ｃｏｎｓｕｍｅｒとしての関係と、ｃｏｎｔｒｏ
ｌｌｅｒ−ｔａｒｇｅｔとしての関係が一致している場
合を例に説明する。

【０１３５】図２９に示す送信手順としては、先ず、ス
テップＳ１０１として示すように、ｐｒｏｄｕｃｅｒか
らｃｏｎｓｕｍｅｒに対して、Ｃｏｎｎｅｃｔ要求を送
信する。このＣｏｎｎｅｃｔ要求は、ｐｒｏｄｕｃｅｒ
がｃｏｎｓｕｍｅｒに対して、接続要求を行うためのコ
マンドで、ｐｒｏｄｕｃｅｒのレジスタのアドレスをｃ
ｏｎｓｕｍｅｒに対して伝える。このＣｏｎｎｅｃｔ要
求は、ステップＳ１０２の処理としてｃｏｎｓｕｍｅｒ
が受信することで、ｃｏｎｓｕｍｅｒ側では、ｐｒｏｄ
ｕｃｅｒのレジスタのアドレスを認識する。そして、ス
テップＳ１０３により、ｒｅｓｐｏｎｃｅとして、ｃｏ
ｎｓｕｍｅｒは、ｐｒｏｄｕｃｅｒに対してＣｏｎｎｅ
ｃｔ受付を送信する。そして、ステップＳ１０４におい
て、ｐｒｏｄｕｃｅｒがこれを受信することで、以降の
データ送受信のためのｐｒｏｄｕｃｅｒ−ｃｏｎｓｕｍ
ｅｒ間の接続（ｃｏｎｎｅｃｔｉｏｎ）が確立される。

【０１３６】上記のようにしてｃｏｎｎｅｃｔｉｏｎが
確立されると、ステップＳ１０５により、ｃｏｎｓｕｍ
ｅｒは、ｐｒｏｄｕｃｅｒに対してｌｉｍｉｔＣｏｕ
ｎｔｒｅｇｉｓｔｅｒ（（以降、単に「ｌｉｍｉｔＣ
ｏｕｎｔ」と略す））の書込要求を行う。ステップＳ１
０６によりこれを受信したｐｒｏｄｕｃｅｒは、続くス
テップＳ１０７の処理によって、ｌｉｍｉｔＣｏｕｎ
ｔ書込受付を、ｃｏｎｓｕｍｅｒに対して送信する。そ
して、ステップＳ１０８の処理として、ｃｏｎｓｕｍｅ
ｒがｌｉｍｉｔＣｏｕｎｔ書込受付を受信する。この
ｌｉｍｉｔＣｏｕｎｔ書込要求／書込受付の一連の処理
によって、以降における、セグメントバッファへのデー
タ書き込みサイズ（セグメントバッファ容量）が決定さ
れる。

【０１３７】続くステップＳ１０９においては、ｐｒｏ
ｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、セグメント
バッファ書込要求を送信する。そして、ステップＳ１１
０によってセグメントバッファ書込要求が受信され、こ
れに応答して、ステップＳ１１１の処理として、ｃｏｎ
ｓｕｍｅｒからｐｒｏｄｕｃｅｒに対して、セグメント
バッファ書込受付を送信する。ｐｒｏｄｕｃｅｒは、ス
テップＳ１１２により、セグメントバッファ書込受付を
受信する。このステップＳ１０９〜Ｓ１１２までの処理
が実行されることで、１回のｐｒｏｄｕｃｅｒのセグメ
ントバッファからｃｏｎｓｕｍｅｒのセグメントバッフ
ァに対してデータへの書き込み処理が完了する。ここ
で、上記ステップＳ１０９〜Ｓ１１２の処理によって書
き込まれるデータは、図１５に示したＡｓｙｎｃｈｒｏ
ｎｏｕｓＰａｃｋｅｔによる１回の送信により書き込
まれる。従って、ＡｓｙｎｃｈｒｏｎｏｕｓＰａｃｋ
ｅｔにより転送されるデータサイズが、上記ｌｉｍｉｔ
Ｃｏｕｎｔによって指定されたデータサイズよりも小
さく、かつ、１回のＡｓｙｎｃｈｒｏｎｏｕｓＰａｃ
ｋｅｔによる送信によっては、必要なデータ送信が完了
しない場合には、セグメントバッファの容量がフルとな
る範囲で、ステップＳ１０９〜Ｓ１１２の処理が繰り返
されるようになっている。

【０１３８】そして、上記したステップＳ１０９〜Ｓ１
１２に示すセグメントバッファへの書き込み処理が完了
すると、ステップＳ１１３の処理として示すように、ｐ
ｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒに対して、ｐｒｏ
ｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓｔｅｒ（以降、単
にｐｒｏｄｕｃｅｒＣｏｕｎｔと略す）書込要求を送
信する。そしてｃｏｎｓｕｍｅｒでは、ステップＳ１１
４の処理として、ｐｒｏｄｕｃｅｒＣｏｕｎｔを受信
して、自身のｐｒｏｄｕｃｅｒＣｏｕｎｔｒｅｇｉｓ
ｔｅｒに書き込みを行い、続くステップＳ１１５の処理
として、ｐｒｏｄｕｃｅｒＣｏｕｎｔ書込受付をｐｒ
ｏｄｕｃｅｒに対して送信する。ｐｒｏｄｕｃｅｒはス
テップＳ１１６により、このｐｒｏｄｕｃｅｒＣｏｕ
ｎｔ書込受付を受信する。この処理によって、先のステ
ップＳ１０９〜Ｓ１１２の処理として、ｐｒｏｄｕｃｅ
ｒからｃｏｎｓｕｍｅｒのセグメントバッファに対して
転送したデータサイズがｃｏｎｓｕｍｅｒに対して知ら
されることになる。

【０１３９】続くステップＳ１１７の処理としては、上
記ステップＳ１１３〜Ｓ１１６に示したｐｒｏｄｕｃｅ
ｒＣｏｕｎｔ書き込み処理に応答しての、ｌｉｍｉｔ
Ｃｏｕｎｔ書き込みのための一連の処理が実行され
る。つまり、ステップＳ１１７〜Ｓ１２０に示すように
して、ｃｏｎｓｕｍｅｒからｐｒｏｄｕｃｅｒへのｌｉ
ｍｉｔＣｏｕｎｔ書込要求の送信と、この送信に応答
してのｐｒｏｄｕｃｅｒからｃｏｎｓｕｍｅｒへのｌｉ
ｍｉｔＣｏｕｎｔ書込受付の送信が行われる。

【０１４０】上記ステップＳ１０９〜Ｓ１２０までの処
理が、ＡｓｙｎｃｈｒｏｎｏｕｓＣｏｎｎｅｃｔｉｏｎ
におけるデータ伝送処理としての１セットの手順を成
す。ここで、例えば送信すべきデータサイズが、セグメ
ントバッファ容量よりも大きく、１回のステップＳ１０
９〜Ｓ１２０までの処理によっては、データの転送が完
了していないとされる場合には、このステップＳ１０９
〜Ｓ１２０までの処理を、データの転送が完了するまで
繰り返し実行することが出来るようになっている。

【０１４１】そして、データの転送が完了したら、ステ
ップＳ１２１に示すようにして、ｐｒｏｄｕｃｅｒはｃ
ｏｎｓｕｍｅｒに対して、Ｄｉｓｃｏｎｎｅｃｔ要求を
送信する。ｃｏｎｓｕｍｅｒはステップＳ１２２におい
て、このＤｉｓｃｏｎｎｅｃｔ要求を受信し、続くステ
ップＳ１２３によりＤｉｓｃｏｎｎｅｃｔ受付を送信す
る。ステップＳ１２４において、ｐｒｏｄｕｃｅｒがＤ
ｉｓｃｏｎｎｅｃｔ受付を受信することで、Ａｓｙｎｃ
ｈｒｏｎｏｕｓＣｏｎｎｅｃｔｉｏｎによるデータ送
受信が完結する。

【０１４２】５．本実施の形態のSubunit Identifier D
escriptor ５−１．基本概念これまでの説明から分かるように、本実施の形態のディ
スクプレーヤ０は、ＩＥＥＥ１３９４バスを介して例え
ばパーソナルコンピュータなどの他の機器と接続するこ
とが可能とされている。そして、このようなオーディオ
機器がＩＥＥＥ１３９４バスを介して接続を行って、各
種機能を実現するためには、そのオーディオ機器に装填
されているメディアに記録されているデータを管理する
ための管理情報として、ＩＥＥＥ１３９４インターフェ
イス上で認識可能な形式による管理情報を構築すること
が必要であるとされている。

【０１４３】前述したように、例えばディスクプレーヤ
０のシステムにあっては、記録データを管理する情報と
してＴＯＣ情報（ＣＤレイヤーにあってはＣＤ−ＴＯ
Ｃ，ＨＤレイヤーにあってはマスターＴＯＣ，エリアＴ
ＯＣ（Area TOC-1,Area TOC-2））が存在し、これがデ
ィスクに記録されているのであるが、これらＴＯＣ情報
は、あくまでもディスクプレーヤのシステム内で完結す
る情報であり、そのままＩＥＥＥ１３９４インターフェ
イスに適合するものではない。そこで、本実施の形態の
ディスクプレーヤ０においては、ディスクに記録された
ＴＯＣ情報を利用して、ＩＥＥＥ１３９４フォーマット
に適合する形式による管理情報を別途作成して保持する
ようにされる。これが、ＩＥＥＥ１３９４データインタ
ーフェイス下でのＡＶ／Ｃプロトコルにて規定される
「Subunit Identifier Descriptor」といわれるもので
ある。

【０１４４】また、この場合には、その対象がディスク
であることから、Subunit_typeとしては、Disc recorde
r／Playerとされることになる。このDisc recorder／Pl
ayerのSubunit_typeに対応して作成されるSubunit Iden
tifier Descriptorは、「Disc Subunit Identifier Des
criptor」であるものとされている。そこで以降、本実
施の形態のディスクプレーヤ０が有するべき「Disc Sub
unitIdentifier Descriptor」について説明していくこ
ととする。

【０１４５】ここで先ず、図３０により、Subunit Iden
tifier Descriptorの基本概念について述べておく。Sub
unit Identifier Descriptorは、そのSubunitの各種属
性の情報が格納したデータ構造とみることができる。そ
して、その構造としては階層構造を有するものとされて
いる。図３０（ａ）に示すブロックは、Subunit Identi
fier Descriptorにおける最も上の階層として見える構
造を示している。つまり、階層構造において定義される
ルート(root)に対応する。Subunit Identifier Descrip
torは、１以上のオブジェクトにより形成されるが、そ
のオブジェクトとして、例えばここでは、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
のオブジェクトが指定される。また、図３０（ｂ）のLi
st0のオブジェクトもまた、各Listもまた、親（Paren
t）のディレクトリが子(Child)のディレクトリを示すよ
うにして階層構造を有するようにされている。このよう
にして、ルートディレクトリから次々に子のディレクト
リを参照してたどっていくことで、目的のオブジェクト
に到達するまで階層を降りていくことができる。また逆
に或る階層化のオブジェクトから親ディレクトリを参照
してたどっていくことで、ルートディレクトリまで階層
を上っていくことができる。

【０１４６】５−２．Subunit Identifier Descriptor 以降、各図を参照して、Subunit Identifier Descripto
r、及びその下で定義されるDisc Subunit Identifier D
escriptorの具体的構造を述べていく。なお、以降説明
する各図及びこれに対応する記述内容において、アドレ
ス及び各種パラメータ等の値の後ろに付される「ｈ」
は、その値が１６進法により表記されているものである
ことを示すものとする。

【０１４７】ＡＶ／Ｃプロトコルにおいては、「Disc S
ubunit Identifier Descriptor」の上位概念として、
「General Subunit Identifier Descriptor」が規定さ
れる。つまり、「General Subunit Identifier Descrip
tor」の規定によって、「DiscSubunit Identifier Desc
riptor」以外のSubunit Identifier Descriptorにも共
通となる定義が規定されるものである。

【０１４８】そして、先に図３０（ａ）に示したSubuni
t Identifier Descriptorは、実際には図３１に示すGen
eral Subunit Identifier Descriptorとしての構造を有
するものとして規定されている。以下、この図に示され
る各エリアの内容のうち、本実施の形態に関して説明が
必要とされるエリアについて説明を行っていくこととす
る。なお、以降においても、このようなデータ構造を示
している図については、本実施の形態として必要とされ
るエリアについての説明にとどめることとする。

【０１４９】図３１において、先頭のaddress=0000h-00
01hで示されるエリアＡ１のdescriptor＿lengthには、
このdescriptor＿lengthのエリアから下のエリアのサイ
ズがバイト数により示される。また、address=0008h以
降のエリアＡ２−１〜Ａ２−ｎには、実際に設けられる
Root Contents List数ｎに応じて、root_object_list_i
d_0〜root_object_List_id_n-1のｎ個のroot_object_Li
st_idが配置される。各root_object_list_idは、ここで
は２バイトを使用するものとしているが、この使用バイ
ト数は、アドレス0003hのエリアＡ３におけるsize_of_L
ist_idに格納される値によって指定される。各root_obj
ect_List_idのエリアＡ２−１〜Ａ２−ｎには、それぞ
れ、このsubunitに関連づけられているRoot Contents L
ist（root object list）を指定するためのＩＤとして
の値が格納されている。また、このroot_object_List_i
dの数は、address=0006h−00007hで示されるnumber_of_
root_object_ListのエリアＡ４に格納される値によって
示される。つまり、number_of_root_object_Listによっ
ては、そのsubunitに関連づけられているRoot Contents
List（root object list）の総数が示される。

【０１５０】また、エリアＡ６とされるsubunit_depend
ent_informationには、subunitのタイプに応じた形式
で、subunitに対応した所定内容の情報が格納される。
また、このsubunit_dependent_informationのサイズ
は、エリアＡ５のsubunit_dependent_lengthによって示
される。

【０１５１】５−３．Object List Descriptor 上記root_object_List_idによって指定されるRoot Cont
ents List（root object list）は、図３２に示すObjec
t List Descriptorとしての構造を有する。全てのObjec
t 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 e
ntry群が配置されるものとしている。

【０１５３】図３２に示すObject List Descriptorにお
いて、先頭のaddress=0000h-0001hが示すエリアＡ１１
は、descriptor_lengthとされる。このdescriptor_leng
thには、このdescriptor_length自体を除外した、以降
のObject List構造のデータサイズをバイト数によって
示すための値が格納される。

【０１５４】続くaddress=0002hにより示されるlist_ty
peのエリアＡ１２には、当該ObjectList Descriptorの
種類（タイプ）を示す値が格納される。そして、このli
st_typeに格納されるべき値としては、図３３に示すよ
うにして定義される。この図３３に示されるように、li
st_typeの値が00h-7Fhの範囲では、[general definitio
ns]とされ、この場合には全ての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で示されるエリアＡ１３にはatt
ributesが示される。attributesには、現listの構造に
関連する属性としての情報がビットフラグとして格納さ
れる。ここでの詳細な定義内容の説明は省略するが、例
えば、Ｃｏｎｔｒｏｌｌｅｒ側がこのlistをスキップす
るかリードすべきかの情報や、現object List Descript
orにおいて、後述するobject entry[0]-[n-1]に対して
ＩＤが格納されているか否かの情報や、また、object e
ntry[0]-[n-1]に対して、child_list_idが格納されてい
るか否かを示す情報等を表現することができる。

【０１５６】続くaddress=0004h-0005hにより示される
エリアＡ１４は、size_of_list_specific_information
とされ、ここには、次に位置するlist_specific_inform
ationのサイズをバイト数によって示す。そして、addre
ss=0006h・・・により示されるlist_specific_informat
ionのエリアＡ１５には、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 Lis
t内におけるオフセットアドレス(adress offset)として
示されている。adress offset=00h-01hで示されるエリ
アＡ２１はdescriptor_lengthとされ、このdescriptor_
length自体を除外した、以降のobject_entry構造のデー
タサイズをバイト数によって示す。

【０１６０】続くエリアＡ２２のentry_type(address o
ffset=0002h)には、現Object EntryDescriptorの種類を
示す値が格納される。このentry_typeが取り得る値の範
囲と、その値に応じた定義内容は、図３３に示した内容
に準ずる。また、現ObjectEntry Descriptorが、Disc S
ubunit Object Entryとされている場合は、subunit typ
e dependentとして定義される80h-FFhの範囲内で、後述
するようにしてentry_typeの値が定義されている。ま
た、ここでのエリアＡ２３におけるattributes(address
offset=0003h)の定義としては、先に図３２に示したOb
ject List Descriptorと同様となる。

【０１６１】エリアＡ２４としてのchild_list_ID(addr
ess offset=0004h・・・・)には、現Oobject_entryの階
層下にあるとされるchild_list（Child Contents Lis
t）のＩＤが格納される。

【０１６２】続くエリアＡ２５としてのobject_IDに
は、或る所定範囲内の値を用いて、現object_entryに固
有に設定されたＩＤとしての値が格納される。

【０１６３】続くエリアＡ２６としてのsize_of_entry_
specific_informationは、次に配置されるエリアＡ２７
としてのentry_specific_informationのサイズをバイト
数によって示している。そして、entry_specific_infor
mationのエリアＡ２７に対しては、現object_entryのタ
イプに応じて固有な形式によって、現Objectに固有とな
る所定内容の情報が格納される。

【０１６４】５−５．Disc Subunit Object 上記説明は「General Subunit Identifier Descripto
r」としての一般規定に関するものであった。Subunit I
dentifier Descriptorの実際としては、「General Subu
nit Identifier Descriptor」としてのSubunit_typeがD
isc recorder／Playerとして指定された場合に、「Disc
Subunit Identifier Descriptor」とされるものであ
る。そして以降におけるこれまでの説明の続きとして
は、この「Disc Subunit Identifier Descriptor」とし
ての内容に対応させていくこととする。

【０１６５】先に図３４に示したObject Entry Descrip
torにおいて、entry_typeとしてDisc Subunitとしての
所定値が格納された場合、このObject Entry Descripto
rは、Disc Subunit Object Entryとされることになる。
Disc Subunit Object Entryとされる場合に対応するent
ry_typeとしては、図３５に示すようにして定義されて
いる。

【０１６６】この図３５において、本実施の形態に関連
するentry_typeとしては、例えば矢印によって指し示す
Audio Track、及びChild Directory Objectとが挙げら
れる。entry_type＝80hとされてAudio Trackが定義され
た場合には、現object_entryは、オーディオトラックに
関する情報が格納されていることを示すことになる。ま
た、entry_type＝90hとされてChild Directory Object
が定義された場合には、現object_entryは、Child Cont
ens Listを指定するchild list IDが格納されているこ
とを示すことになる。

【０１６７】５−６．Disc Subunit Object entry_spec
ific_information そして、図３４に示したObject Entryが、Disc Subunit
Object Entryとされた場合の、entry_specific_inform
ation（図３４：エリアＡ２７）内の基本的構造は、図
３６に示すものとなる。

【０１６８】先ず、adress offset=0000h-0001hで示さ
れるエリアＡ３１は、non_info_block_fields_lengthと
され、ここには、以降続くnon_info_blockエリアとして
の合計サイズをバイト数により示す。つまり、図示する
ように、エリアＡ３３としてのobject_type_specific_n
on_info_block_fieldsの終端位置までのサイズを示す。

【０１６９】続くadress offset=0002hで示されるエリ
アＡ３２は、disc_Subunit_object_attibutesとされ、D
isc Subunit Objectに共通とされる所定の属性情報が記
述される。

【０１７０】また、続くadress offset=0003h以降の、
エリアＡ３３としてのobject_type_specific_non_info_
block_fieldsには、このDescriptorによって表されるDi
sc Subunit Objectのタイプに固有となる情報が格納さ
れる。

【０１７１】上記object_type_specific_non_info_bloc
k_fieldsに続けては、エリアＡ３４としてのinfo_block
(infomation block)を１以上配置することができるよう
にされている。info_blockは、全てのDisc Subunit Obj
ect間で共有することができる。

【０１７２】５−７．Audio Track Object entry_speci
fic_information そして、先に図３４に示したObject Entryにおいて、エ
リアＡ２２のentry_typeとして80h(図３５参照）の値が
格納されると、そのObject Entryは、Audio Track Obje
ct entryとしてのDisc Subunit Object Entryとされる
ことになる。そこで、上記図３６に示したentry_specif
ic_informationが、Audio Track Object entry_specifi
c_informationとされた場合の構造図を図３７に示す。
なお、図３７において、図３６と同一とされる内容につ
いては同一符号を付して説明を省略する。

【０１７３】この場合、エリアＡ３１のnon_info_block
_fields_length（adress offset=0000h-0001h）及びエ
リアＡ３２のdisc_Subunit_object_attibutes（adress
offset=0002h）に続けては、エリアＡ３５としてのaudi
o_recording_parameters_info_blockが配置され、これ
に続けて、エリアＡ３４としてのoptional info block
を配置可能とされる。ここでの詳しい説明は省略する
が、audio_recording_parameters_info_blockには、デ
ィスクに記録されたオーディオトラック、つまりDescip
tor上では、Audio Objectの記録に関する所定の情報が
格納される。例えば、デジタルオーディオデータのサン
プリングレート、サンプルサイズ（量子化ビット数）
や、コンプレッションモード、チャンネルモードなどの
情報が格納される。

【０１７４】５−８．Disc Subunit List List_specifi
c_information 続いて、先に図３２に示したObject List Descriptorが
Disc Subunit Listとして規定される場合について説明
する。前述もしたように、図３２に示したObject List
のタイプは、エリアＡ１２のlist_typeの値によって定
義される。そして、Object Listを特定のDisc SubunitL
istとして規定する場合ためのlist_typeとしては、図３
８に示すようにして定義されている。

【０１７５】先に図３３に示したように、list_typeの
値は80h〜FFhの範囲により何らかのSubunit typeである
ことを示すものとされる。そして、Disc Subunit List
のlist_typeとしては、図３８に示すようにして、上記
した80h〜FFhの範囲内における所定の値を利用して定義
を行っている。この図に示されるように、list_type=80
hであれば、現Object ListはRoot Content Listである
ことが示される。また、list_type=81hであればChild C
ontentsListsであることが示される。また、補足的に述
べておくと、list_type=82hであればRoot Temporary Co
ntents List、list_type=83hであればChild Temporary
Contents Lists、=84hであればPerformance Lists、lis
t_type=85hであればSynchronized Performance Lists、
list_type=86hであればText Database Listsであること
が示される。list_type=87h以降の値は現状未定義とさ
れている。

【０１７６】そして、上記図３８に示したlist_type=80
h〜86hの何れかの値が設定されて、図３２に示したObje
ct 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とされ、D
isc Subunit Objectに共通とされる所定の属性情報が格
納される。

【０１７９】そして、adress offset=0003h以降の、エ
リアＡ４３としてのlist_type_specific_non_info_bloc
k_fieldsには、このDescriptorによって表されるDisc S
ubunit Listのタイプに固有となる情報が格納される。

【０１８０】上記list_type_specific_non_info_block_
fieldsに続けては、エリアＡ４４としてのinfo_blockを
１以上配置可能とされている。

【０１８１】５−９．Root Contents List Disc Subunit ListとしてのRoot Contents Listは、現
在インストールされているディスクについての各種所要
の情報を表すListとされる。このような情報として、Di
sc Subunit Listには、例えばディスクタイトルやディ
スクジャケットなどのディスク全体に関連する情報が格
納される。また、オーディオトラック、ビデオトラッ
ク、デジタルスチル画像などのトラック(object)単位の
情報も格納される。ここで、図４０に、Root Contents
Listの構造概念を示しておく。なお、この図に示す構造
は、ディスクメディアが階層構造のファイルシステムに
よりデータを管理していない、いわゆるフラットストレ
ージシステムに対応したものとされる。この図に示すよ
うに、Root Contents Listにあっては、各object entry
によって、各種ＡＶobjects（ＡｕｄｉｏＴｒａｃ
ｋ，ＶｉｄｅｏＴｒａｃｋ，ＤｉｇｉｔａｌＳｔｉ
ｌｌＩｍａｇｅＴｒａｃｋ）が表現される。これ
は、或る１つのディスクに記録された全てのＡＶコンテ
ンツを表示現している。ＲｏｏｔＣｏｎｔｅｎｔｓ
ＬｉｓｔＨｅａｄｅｒは、次に説明するRoot Content
s List List_specific_informationの他に、全てのＡＶ
／Ｃのlist_typeに共通のヘッダを参照するようにされ
る。

【０１８２】５−１０．Root Contents List List_spec
ific_information Root Contents List List_specific_informationとは、
図３２に示すObject List DescriptorがRoot Contents
Listとして定義された場合の、List_specific_informat
ion（エリアＡ１５）とされる。そして、このRoot Cont
ents 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 Su
bunit 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_ty
peとしてＭＳＢ＝05hとされた場合には、そのディスク
（若しくは、ディスク内の或る特定のレイヤー）は、Ｓ
ＡＣＤ方式であると定義するようにしている。これによ
り、ＡＶ／Ｃプロトコルにあって、ＳＡＣＤに対応した
Disc Subunit Listが存在するものとして規定されるこ
とになる。なお、現状では、ＳＡＣＤ方式のディスクは
１種類のみとされていることから、ＬＳＢ＝01hによっ
てもＳＡＣＤであることを示すようにされる。つまり、
現状では、media_type=O501hによってＳＡＣＤであるこ
とが表される。

【０１９０】説明を図４１に戻す。media_typeに続く、
adress offset=0005hで示されるエリアＡ５４はdisc_re
cordable_informationとされる。disc_recordable_info
rmationは、記録可能であるか、或いはライトプロテク
トがかかっているのかをフラグにより示す。

【０１９１】続く、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としての
エリアＡ５７には、必要に応じて、他の１以上のinfoma
tion blockとしての情報を格納可能とされている。例え
ば新たなMedia Typeが出現したり、既存のMedia Typeに
あっても、或る仕様に対応した新機能を追加したいとき
など、これまでの定義では充分対応できない場合が生じ
る。このようなときに、所要の情報をoptional info bl
ockとして定義して、エリアＡ５７に格納することがで
きる。

【０１９３】５−１１．information block 続いて、information block(info_block)について説明
する。図４３は、information blockの基本構造を示し
ている。この図において、先頭のaddress=0000h-0001h
で示されるエリアＡ６１のcompound＿lengthには、現in
formation blockのサイズがバイト数によって示され
る。但し、compound＿lengthのエリアＡ５６自体のサイ
ズはこれには含めないものとされている。

【０１９４】次のaddress=0002h-0003hで示されるエリ
アＡ６２は、info_block_typeとされ、現information b
lockのタイプを示す。info_block_typeは、図４４に示
すようにして大きくは２つに分けられる。0000h-7FFFh
までの値は、general info brock typesに対して割り当
てられている。そして、8000h-FFFFhまでの値がsubunit
typeに固有となるinfo block typeとして割り当てられ
る。例えばsubunit typeの場合であれば、各subunit ty
peの下で定義される各種info blockの各タイプが、8000
h-FFFFhの値のうちの何れか１つを利用して定義されて
いることになる。

【０１９５】また、図４５に、上記図４４に示したgene
ral info brock type（0000h-7FFFh）とinfo block typ
e（8000h-FFFFh）内における、各info block typeの定
義内容を示す。なお、ここでは、図４５に示される各in
fo brock typeごとの内容についての説明は省略する。

【０１９６】図４３において、info_block_typeに続くa
ddress=0004h-0005hで示されるエリアＡ６３は、primar
y_fields_lengthとされる。primary_fields_lengthに
は、次のaddress=0006h以降に配置されるprimary_field
sのみのデータサイズをバイト数により示す。

【０１９７】そして、address=0006h以降に配置されるp
rimary_fieldsとしてのエリアＡ６４には、原則として
上記info_block_typeにより示される内容のinformation
blockが、例えば１セット格納される。但し、primary_
fieldsのタイプの解釈は、info_block_typeのみに依存
しないものとされ、現information blockが存在するテ
ーブル範囲に基づいて解釈することもできる。例えば、
information blockがList_specific_information内に有
れば、information blockのタイプとしては、そのList
のタイプに従うようにもできる。同様にして、informat
ion blockがentry_specific_infomationの構造内にあれ
ば、information blockのタイプとしては、そのentryの
タイプに従うようにもできるものである。

【０１９８】primary_fieldsに続けては、secondary_fi
eldsをオプションとして追加することができる。second
ary_fieldsには、１以上のオプショナルなinformation
blockが格納される。

【０１９９】例えば、システムの所定の動作に伴い、Li
stの階層構造内から或る特定のinformation blockを参
照する必要の生じることがある。この場合には、例えば
図４６に示されるようにして目的とするのinformationb
lockに対しての参照が行われる。図４６においては、Li
st構造が概念的に示されている。このListにあっては、
先ず、Ｌｅｖｅｌ０としての階層に、Object Descripto
r0,Object Descriptor1が存在している。そして、Objec
t Descriptor1において、Ｌｅｖｅｌ０の直下にあると
されるＬｅｖｅｌ１の階層に、Information Block A,In
formation BlockBが存在している。更に、Information
Block Bにおいて、Ｌｅｖｅｌ０の直下にあるとされる
Ｌｅｖｅｌ２の階層にInformation Block X,Informatio
n Block Yが存在している。

【０２００】ここでの詳しい説明は省略するが、例えば
New AV/C Descriptor Identifierとして定義される、In
fo Block specified by posotion in comtainer struct
ureによって示される階層をたどってのポジション指定
情報に基づいて、目的のInformation Blockを参照して
いくことができる。つまり、例えば図４６の場合におい
て目的のInformation Block Xを参照するのであれば、
Ｌｅｖｅｌ０からＬｅｖｅｌ２までの階層をたどりなが
ら、指定されるポジションを参照することで、Informat
ion Block Xに到達できる。また、New AV/C Descriptor
Identifierとして定義されるinstance_countによってI
nformation Block(例：third block of type‘x’）を
指定する手法も存在する。

【０２０１】５−１２．ＲｅａｄＩｎｆｏＢｌｏｃ
ｋｃｏｍｍａｎｄまた本実施の形態では、図２２に示したＷｒｉｔｅＲ
ｅｑｕｅｓｔＰａｃｋｅｔ（ＡＶ／Ｃコマンドパケッ
ト）の１つとして、ＲｅａｄＩｎｆｏＢｌｏｃｋ
ｃｏｍｍａｎｄを定義することで、Disc Subunit Ident
ifier Descriptorの情報の送受信として、Information
Block単位での送受信を行うことが可能とされる。図４
７は、このＲｅａｄＩｎｆｏＢｌｏｃｋｃｏｍｍ
ａｎｄの構造を示している。なお、この図に示すＲｅａ
ｄＩｎｆｏＢｌｏｃｋｃｏｍｍａｎｄとしての構
造は、図２２に示したＡＶ／Ｃコマンドパケットにおけ
る、ｄａｔａｆｉｅｌｄ内のｏｐｃｏｄｅ以降に配置さ
れるものである。

【０２０２】ｏｐｃｏｄｅの８ビットの領域であるエリ
アＡ７１には、現ＡＶ／ＣコマンドパケットがＲｅａｄ
ＩｎｆｏＢｌｏｃｋｃｏｍｍａｎｄであることを
示す値「０６ｈ」が格納される。これに続くｏｐｅｒａ
ｎｄ［０］（１バイト）以降の所要数のｏｐｅｒａｎｄ
が連続して形成されるエリアＡ７２には、info_block_r
efernce_pathが格納される。info_block_refernce_path
は、このＲｅａｄＩｎｆｏＢｌｏｃｋｃｏｍｍａ
ｎｄにより要求するInformation Blockへのパスが示さ
れる。ここでの詳しい説明は省略するが、info_block_r
efernce_pathは、先に図４６により説明したように、例
えば階層（Ｌｅｖｅｌ）をたどって目的のInformation
Blockを参照するための所定のデータにより形成される
構造を採る。

【０２０３】info_block_refernce_pathに続くエリアＡ
７３は、read_result_statusとされる。read_result_st
atusは、オペレーションのステイタスを示す所要の値が
格納される。Ｃｏｎｔｒｏｌｌｅｒが、ＲｅａｄＩｎ
ｆｏＢｌｏｃｋｃｏｍｍａｎｄを使用してInformat
ion Blockの送信要求を行う場合には、read_result_sta
tusに対してはFFhを書き込むようにされる。そして、su
bunitとしてのＴａｒｇｅｔでは、このＲｅａｄＩｎ
ｆｏＢｌｏｃｋｃｏｍｍａｎｄの受信に応答したｒ
ｅｓｐｏｎｃｅを返送する際に、このread_result_stat
usの値を、オペレーションステータスの結果に応じて更
新するようにされる。info_block_refernce_pathに続く
エリアＡ７４は未定義とされる。

【０２０４】エリアＡ７５としてのdata_lengthには、
要求されたInformation Blockに応じて、Ｔａｒｇｅｔ
から読み出されるべきデータサイズがバイト数によって
示される。なお、data_length＝０とされた場合には特
別な意味を持ち、この場合には、全てのInformation Bl
ock(the header,the primary_fields,and secondary_fi
elds)がＴａｒｇｅｔから読み出されるべきものとして
指定される。

【０２０５】続くエリアＡ７６としてのaddressは、Ｔ
ａｒｇｅｔから読み出されるべきデータ（Information
Block）のアドレスを指定するもので、これは、読み出
し開始位置を、Information Blockのheaderの先頭から
のオフセット値により示すものとされる。

【０２０６】Ｃｏｎｔｒｏｌｌｅｒが上記図４７に示し
たＲｅａｄＩｎｆｏＢｌｏｃｋｃｏｍｍａｎｄを送
信すると、Ｔａｒｇｅｔからの応答として、ＡＣＣＥＰ
ＴＥＤｒｅｓｐｏｎｃｅが送信されてくる。このＡＣ
ＣＥＰＴＥＤｒｅｓｐｏｎｃｅには、例えば、addres
s（エリアＡ７６）に続くｏｐｅｒａｎｄのエリアに対
して、data_length（エリアＡ７５）により指定された
データサイズのResponse Dataが配置されている。即ち
要求を行ったInformation Blockが格納されて送信され
てくるものである。

【０２０７】５−１３．ＳＡＣＤ type これまで「Disc Subunit Identifier Descriptor」に関
して、本実施の形態に関わるとされる内容について説明
を行ってきた。そして、本実施の形態にあっては、ＳＡ
ＣＤ方式としてのメディアに対応して各種機能が実現さ
れるように、先に図４２に示したようにして、Disc Sub
unit Identifier Descriptorのメディアタイプ（media_
type)を定義している。つまり、media_type＝0501hであ
れば、そのListはＳＡＣＤ typeとして規定され、ＳＡ
ＣＤの属性を示す内容を有するものとされる。

【０２０８】また本実施の形態としては、ＳＡＣＤ typ
eとしての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までの範囲の値と、i
nfo block type=8800h-FFFFhまでの範囲の値のうちか
ら、実際に定義して設けられるＳＡＣＤ type下でのinf
o block typeに応じて、所要の値を使用するものとして
いる。

【０２１０】５−１４．ＳＡＣＤ type／ＲｏｏｔＣ
ｏｎｔｅｎｔｓＬｉｓｔＬｉｓｔ＿ｓｐｅｃｉｆｉ
ｃ＿ｉｎｆｏｒｍａｔｉｏｎ続いて、ＳＡＣＤｔｙｐｅとされる場合の、Root Con
tents List List_specific_informationの構造につい
て、図４８を参照して説明する。この図において、先頭
のエリアＡ５１のnon_info_block_fields_lengthからエ
リアＡ５６のdefault_play_list_info_blockまでのエリ
アは、図４１と同様とされることからここでの説明は省
略する。但しこの場合、エリアＡ５３のmedia_typeに対
しては、ＳＡＣＤであることを示す0105hの値（図４２
参照）が格納されることになる。

【０２１１】そして、このＳＡＣＤ typeのRoot Conten
ts List List_specific_informationにあっては、図４
１においてother optional info blocksとして示された
エリアＡ５７に対して、ＳＡＣＤに対応した次のInform
ation Blockが配置されていくことになる。

【０２１２】先ずエリアＡ５７の先頭に配置されるエリ
アＡ５７−１は、album_set_info_blockとされる。ＳＡ
ＣＤとしてのディスク、つまりＨＤデータが記録される
ＨＤレイヤー１０２にあっては、図５（ｂ）（ｃ）によ
り説明したようにして、マスターＴＯＣに対して、アル
バム情報が格納されている。上記album_set_info_block
には、このアルバム情報に基づく情報として、アルバム
を成す「アルバムディスク枚数」、及びアルバムを成す
ディスクごとに付される通し番号である「アルバム内デ
ィスク識別番号」に対応した情報が格納される。なお、
このalbum_set_info_blockの構造は、図４９を参照して
後述する。

【０２１３】エリアＡ５７−１に続くエリアＡ５７−２
には、album_catalog_code_info_blockが配置される。
このalbum_catalog_code_info_blockには、アルバム単
位で固有となるように設定されたＩＤが、album_catalo
g_codeとして格納される。また、album_catalog_code_i
nfo_blockの構造についても、図５０を参照して後述す
る。

【０２１４】次のエリアＡ５７−３は、disc_catalog_c
ode_info_blockとされ、ディスク単位（但しハイブリッ
ドディスクの場合にはＨＤレイヤー単位）で固有となる
ように設定されたＩＤがdisc_catalog_codeとして格納
される。

【０２１５】エリアＡ５７−４はname_info_blocck(alb
um)とされ、アルバムタイトルの情報が格納される。そ
して、エリアＡ５７−５はname_info_blocck(disc)と
され、ディスクタイトルの情報が格納される。また、こ
れに続くエリアＡ５７−６は、other info blocksとさ
れて、必要があれば他のアルバム、又はディスクに関す
るinformation blockが格納される。

【０２１６】album_set_info_block 図４９にalbum_set_info_blockの構造を示す。この図に
示す構造は、先に図４３に示したinfo_blockの構造に従
っており、図４３と同一とされるエリアについては同一
符号を付し、同一内容については説明を省略する。

【０２１７】この場合、エリアＡ６２のinfo_block_typ
eには、このInfomation Blockがalbum_set_info_block
であることを示す特定の値（8XXXh）が格納される。そ
して、エリアＡ６３のprimary_fields_lengthに続くpri
mary_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の構
造を示す。この図に示す構造も、先に図４３に示したin
fo_blockの構造に従っており、図４３と同一とされるエ
リアについては同一符号を付し、同一内容については説
明を省略する。

【０２１９】この場合にも、エリアＡ６２のinfo_block
_typeには、このInfomation Blockがalbum_catalog_cod
e_info_blockであることを示す特定の値（8XXXh）が格
納される。

【０２２０】そしてこの場合には、primary_fieldsとさ
れるエリアＡ６４において、先ず、先頭のaddress=0006
h-0007hの２バイトのエリアＡ６４−１に対して、album
_catalog_code_lengthの情報が格納される。ここには次
に配置されるエリアＡ６４−２のalbum_catalog_codeの
データサイズがバイト数によって示される。album_cata
log_codeの情報は可変長とされているため、このように
して、先ず、album_catalog_codeのデータサイズを示す
必要がある。そして、続くaddress=0008h以降のエリア
Ａ６４−２に対して、アルバム単位についてのＩＤとし
て機能するalbum_catalog_codeの情報が格納される。

【０２２１】５−１５．ＳＡＣＤ type／Audio Track O
bject entry_specific_information 続いて、ＳＡＣＤ typeとされる場合の、Audio Track O
bject entry_specific_informationの構造について、図
５１を参照して説明する。この図に示す構造は図３７に
示したAudio Track Object entry_specific_informatio
nの構造に従っている。そこで、図３７と同一エリアに
ついては同一符号を付し、その説明が重複するものにつ
いては、ここでの説明は省略する。

【０２２２】図５１に示す構造において、図３７におい
てoptional info blocksとされたエリアＡ３４に対して
は、ＳＡＣＤに記録されたオーディオトラックに関する
情報として以下の各Infomation Blockが格納される。

【０２２３】先ず、先頭のエリアＡ３４−１には、size
_indicator_info_blockが配置され、以下続けて、エリ
アＡ３４−２のSACD_specific_info_block、エリアＡ３
４−３のAV_content_identifier_info_block、エリアＡ
３４−４のname_info_blockが配置される。また、エリ
アＡ３４−４に続くエリアＡ３４−５はother_info_blo
ckとされて、必要があればオーディオトラックに関する
他のInfomation Blockを追加することが可能とされて
いる。ここで、本実施の形態としての特徴となるのが、
エリアＡ３４−２のSACD_specific_info_blockとされ
る。

【０２２４】ＳＡＣＤでは、図５に示したように、その
データゾーンに対して、２チャンネルよりも多いマルチ
チャンネルによるＨＤデータが記録されるマルチチャン
ネルエリア（Multichannel Area）が設けられる。そし
て、マルチチャンネルエリアに記録されるエリアＴＯＣ
には、スピーカレイアウトを指定するスピーカレイアウ
ト情報が格納されている。上記したエリアＡ３４−２の
SACD_specific_info_blockには、内容的には、このエリ
アＴＯＣにおけるスピーカレイアウトを指定する情報と
同一とされる情報が格納される。つまり、SACD_specifi
c_info_blockによって、そのトラックについて指定され
たスピーカレイアウトを識別することができるものであ
る。

【０２２５】そして、上記SACD_specific_info_block
は、図５２に示す構造を有する。この図に示す構造は、
先に図４３に示したinfo_blockの構造に従う。また、こ
の図においても図４３と同一とされるエリアについては
同一符号を付し、その説明が重複するものについては、
ここでの説明を省略する。

【０２２６】図５２において、エリアＡ６２のinfo_blo
ck_typeには、このInfomation BlockがSACD_specific_i
nfo_blockであることを示す特定の値（8XXXh）が格納さ
れる。

【０２２７】そしてこの場合には、エリアＡ６４とされ
るprimary_fieldsにおいて、先ず、先頭のaddress offs
et=0006hにより示される１バイトのエリアＡ６４−１に
対して、SACD_specific_typeが配置される。SACD_speci
fic_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 D
escriptorの構造を図５３に示す。例えば図５３（ａ）
に示すDisc Subunit Identifier Descriptorにおけるro
ot_object_list_id_0により、図５３（ｂ）に示すRoot
Contents Listを指定しているとする。そして、このRoo
t Contents Listとしては、その構造内に配置されるlis
t_specific_information内のmedia_typeの値が0510hと
されることで、ＳＡＣＤ typeであるものとして定義さ
れているとする。この場合、Root Contents Listが有す
るlist_specific_informationには、図５３（ｃ）に示
すようにして、album_set_info_blockとalbum_catalog_
code_info_blockが格納されることになる。つまり、Roo
t Contents List内には、アルバム情報を示すInfomatio
n Blockが格納されていることになる。そして、先の図
４８〜図５０を参照した説明によれば、album_set_info
_block、及びalbum_catalog_code_info_blockによっ
て、「アルバムディスク枚数」、「アルバム内ディスク
識別番号」、及びアルバムに固有となるＩＤを有するこ
とができることになる。つまり、ＳＡＣＤに特有とされ
る、アルバム情報をDisc Subunit IdentifierDescripto
rに持つことができるものである。

【０２２９】また、例えば図５３（ｂ）に示すRoot Con
tents ListのChild_Directory_Object[0]によって図５
３（ｄ）に示すChild Contents Listを指定していると
する。このChild Contents Listは、ＳＡＣＤ typeの階
層下にある。そして、このChild Contents Listが有す
るAudio_Track_Objectにおいて、ここに含まれるoption
al info blocks内のAudio Track Object entry_specifi
c_informationにあっては、図５３（ｅ）に示すように
して、SACD_specific_info_blockが格納されることにな
る。このSACD_specific_info_blockは、先に図５１及び
図５２により説明したように、マルチチャンネルオーデ
ィオトラックに対応したスピーカレイアウトの情報を示
す。

【０２３０】このようにして、本実施の形態のDisc Sub
unit Identifier Descriptorにあっては、ＳＡＣＤ、即
ちＨＤレイヤーに固有となる、アルバム情報、及びスピ
ーカレイアウト等の情報を有するようにされる。これに
より、インストールされたディスクがＳＡＣＤである場
合としては、Ｃｏｎｔｒｏｌｌｅｒでは、これらのＳＡ
ＣＤに固有なDisc Subunit IdentifierDescriptor内の
情報を要求して取得することで、ＳＡＣＤならではとさ
れる機能を実現することができる。

【０２３１】一例として、例えば本実施の形態のディス
クプレーヤ０が複数枚のディスクを自動的に交換して再
生可能ないわゆるチェンジャ機能を有しているとすれ
ば、Ｃｏｎｔｒｏｌｌｅｒからのリモート制御によっ
て、アルバムを成す複数枚のディスクを、ユーザの所望
の再生順によって再生するといったことが可能とされ
る。このときには、album_set_info_block及びalbum_ca
talog_code_info_blockの情報が利用される。また、SAC
D_specific_info_blockを利用した機能としては、例え
ば、本実施の形態のＡＶシステムにＡＶアンプを接続
し、このＡＶアンプをリモート制御することで、マルチ
チャンネルのオーディオトラックの再生時には、自動的
にスピーカレイアウトを切り換えることなどができる。

【０２３２】５−１７．ハイブリッドディスクのDisc S
ubunit Identifier Descriptor ところで、図２（ｃ）に示したハイブリッドディスク
は、ＣＤレイヤー１０１とＨＤレイヤー１０２との２つ
の記録層を有している。つまり、Disc Subunit Identif
ier Descriptorとしての概念から見た場合には、異なる
メディア(media_type)のListが並列的に存在することに
なる。従来、異なるフォーマットのオーディオデータが
１つのディスクに混在するということは無かったとされ
るため、基本的に、Disc Subunit Identifier Descript
orは、１つのディスクフォーマット（media_type)に対
応することを前提として、そのフォーマットが規定され
ていたものである。しかし、上記のようなハイブリッド
ディスクの出現によって、１つのディスクに複数のディ
スクフォーマット、即ちボリュームが存在する場合に
も、対応できるようにする必要が生じてきている。

【０２３３】そこで、本実施の形態においては、１つの
ディスクに複数のディスクフォーマット、即ちボリュー
ムが存在する場合には、次に述べるようにしてDisc Sub
unitIdentifier Descriptorを作成するように提案す
る。ここでは、先に図２（ｃ）に示したレイヤー構造を
有するハイブリッドディスクがインストールされた場合
を例に挙げる。

【０２３４】図５４は、図２（ｃ）に示したハイブリッ
ドディスクに対応して作成されるDisc Subunit Identif
ier Descriptorの構造を示している。この場合には、図
５４（ａ）に示すDisc Subunit Identifier Descriptor
におけるroot_object_list_id_0により、図５４（ｂ）
に示すCD_Root Contents Listを指定し、root_object_l
ist_id_1により、図５４（ｃ）に示すSACD_Root Conten
ts Listを指定しているものとする。つまり、この構造
では、Root Contents Listとして、ＣＤレイヤー１０１
に対応するCD_Root Contents Listと、ＨＤレイヤー１
０２に対応するSACD_Root Contents Listとが階層構造
的には並列に設けられるものである。

【０２３５】このような構造を実現するため、先ず、本
実施の形態では、図５４（ｂ）に示すCD_Root Contents
List内に配置されるlist_specific_information内のme
dia_typeに対しては、ＣＤであることを示す0101hを格
納し、また、図５４（ｃ）に示すSACD_Root Contents L
ist内に配置されるlist_specific_information内のmedi
a_typeに対しては、ＳＡＣＤであることを示す0501hを
格納するようにされる。つまり、ここではＣＤレイヤー
１０１を１つのＣＤというメディアとして扱い、同様に
してＨＤレイヤー１０２を１つのＳＡＣＤというメディ
アとして扱うものである。

【０２３６】これにより、図５４（ｂ）に示すCD_Root
Contents Listには、ＣＤレイヤー１０１の記録内容に
対応する情報を記述することができ、また、図５４
（ｃ）に示すSACD_Root Contents Listには、ＨＤレイ
ヤー１０２の記録内容に対応する情報を記述することが
できる。そして、これらのＣＤレイヤー１０１とＨＤレ
イヤー１０２との各々に対応するRoot Contents List
を、ＡＶ／Ｃプロトコルの規定に矛盾することなく併存
させることが可能となる。つまり、１つのディスクと対
応付けて作成されるべき１つのDisc Subunit Identifie
r Descriptor内に、ＣＤ−ＤＡタイプのメディア（ＣＤ
レイヤー）と、ＳＡＣＤタイプ（ＨＤレイヤー）のメデ
ィアに関する内容が記述されるものである。

【０２３７】そして、図５４（ｂ）に示すCD_Root Cont
ents Listのディレクトリ下において、例えばそのChild
_Directory_Object[0]によって指定される、図５４
（ｄ）のChild Contents Listは、ＣＤレイヤー１０１
に記録されたオーディオトラックについてのlist_speci
fic_infomaton、及びAudio Track Object[0]〜[n]を有
することができることになる。同様に、図５４（ｃ）に
示すSACD_Root Contents Listのディレクトリ下におい
て、例えばそのChild_Directory_Object[0]によって指
定される、図５４（ｅ）のChild Contents Listは、Ｈ
Ｄレイヤー１０２に記録されたオーディオトラックにつ
いてのlist_specific_infomaton、及びAudio Track Obj
ect[0]〜[n]を有することができることになる。

【０２３８】また、ＳＡＣＤ（ＨＤレイヤー）とＣＤ−
ＤＡ（ＣＤレイヤー）が混在する状況となったことに対
応して、Contents Listのlist_typeとしては、図５５に
示すようにして定義することとした。この図に示すよう
に、Contents ListがRoot Contentsとされる場合とし
て、CD_Root Contents Listについてはlist_id＝1000h
と定義し、SACD_Root ContentsListについては、list_i
d＝2000hと定義することとしている。更に、Contents L
istがChild Contentsとされる場合として、ＳＡＣＤ
（ＨＤレイヤー）の２チャンネルステレオエリアに記録
されるトラックに関するAudioTrack Objectを有するChi
ld Contents Listについては、list_id＝2001hと定義
し、ＳＡＣＤ（ＨＤレイヤー）のマルチチャンネルエリ
アに記録されるトラックに関するAudio Track Objectを
有するChild Contents Listについては、list_id＝2002
hと定義することとしている。

【０２３９】従って、図５４に示す場合であれば、先ず
図５４（ｂ）に示すように、CD_Root Contents List内
のlist_typeにはlist_id=1000hを格納し、また、図５４
（ｃ）に示すように、SACD_Root Contents List内ののl
ist_typeにはｌｉｓｔ＿ｉｄ＝２０００ｈを格納するよ
うにされる。また、図５４（ｅ）に示すＳＡＣＤ＿Ｒｏ
ｏｔＣｏｎｔｅｎｔｓＬｉｓｔのディレクトリ下の
ChildContents Listが、ＳＡＣＤ（ＨＤレイヤー）の２
チャンネルステレオエリアに記録されるトラックに関す
るAudio Track Objectを有するとすれば、このChildCon
tents List内のlist_typeにはlist_id=2001hを格納し、
ＳＡＣＤ（ＨＤレイヤー）のマルチチャンネルエリアに
記録されるトラックに関するAudio Track Objectを有す
るとすれば、このChild Contents Listのlist_typeには
list_id=2002hを格納することになる。

【０２４０】６．Disc Subunit Identifier Descriptor
作成処理本実施の形態のディスクプレーヤ０の実際としては、図
２に示した４種のディスクのそれぞれに応じてDisc Sub
unit Identifier Descriptorを作成することが必要とさ
れる。そこで、以下、ディスクプレーヤ０においてこれ
ら４種のディスクごとに対応してDisc Subunit Identif
ier Descriptorを作成するための処理動作について、図
５６〜図５８を参照して説明する。なお、図５６〜図５
８の各図に示す処理は、システムコントローラ１１が実
行する。

【０２４１】例えば、ディスクプレーヤ０に対してディ
スクが装填されると、システムコントローラ１１は、そ
の後の所定の機会においてDisc Subunit Identifier De
scriptorを作成するために、図５６に示す処理を実行す
る。

【０２４２】図５６においては、先ずステップＳ１０１
において、現在装填されているディスクの種別について
の判別を行う。このディスク種別の判別は、例えば図７
にて説明したようにして、判別信号生成部２０から入力
された判別信号に基づいて行うようにされる。

【０２４３】ステップＳ１０１において、ディスク種別
がＣＤ−ＤＡ（図２（ａ））であると判別された場合に
は、ステップＳ１０２の処理に進む。ステップＳ１０２
においては、装填されているＣＤ−ＤＡのリードインエ
リアに対するデータ読み出しを実行させることで、ＴＯ
Ｃ（ＣＤ−ＴＯＣ）を読み込むための処理を実行する。
そして例えばこの読み込みを行ったＴＯＣを、システム
コントローラ１１内のＲＡＭ１１ａに書き込んで保持さ
せる。但し、例えば既にＣＤ−ＤＡを再生して読み込ん
だＴＯＣが、ＲＡＭ１１ａに対して保持されている状態
にあれば、ステップＳ１０２の処理としては、このＲＡ
Ｍ１１ａに保持されているＴＯＣを参照すればよい。こ
の点については、以降説明することとなる、ステップＳ
１０４と，ステップＳ１０６，Ｓ１０７と、ステップＳ
１０９，Ｓ１１０の各ＴＯＣ読み込み処理についても同
様とされる。

【０２４４】次のステップＳ１０３においては、上記ス
テップＳ１０２において読み込んだＴＯＣの内容に基づ
いて、Disc Subunit Identifier Descriptorを作成す
る。なお、ここで作成されるのは、図５４に示すDisc S
ubunit Identifier Descriptorの構造において、図５４
（ａ）→図５４（ｂ）→図５４（ｄ）の階層構造を抜き
出すようにして得られるＣＤ−ＤＡタイプのみとしての
Disc Subunit Identifier Descriptorとされる。

【０２４５】また、ステップＳ１０１において、単層Ｈ
Ｄディスク（図２（ｂ））であることが判別された場合
には、ステップＳ１０４に進む。ステップＳ１０４にお
いては、単層ＨＤディスクのＨＤレイヤー１０２に記録
されているマスターＴＯＣ、及びエリアＴＯＣを読み込
むための処理を実行する。

【０２４６】そして、次のステップＳ１０５において、
上記のようにして読み込みを行って取得したマスターＴ
ＯＣ、及びエリアＴＯＣの内容に基づいて、ＳＡＣＤタ
イプのDisc Subunit Identifier Descriptorを作成する
ための処理を実行する。つまり、先に図５３に示した内
容及び構造によるDisc Subunit Identifier Descriptor
を作成する。

【０２４７】この際、例えばlist_type、media_typeな
どのエリアには、先に図５５や図４２に示した定義内容
のうち、ＳＡＣＤに対応した値を格納するようにされ
る。また、特にChild Contents Listについては、前述
したように、２チャンネルステレオエリアに対応するCh
ild Contents Listと、マルチチャンネルエリアに対応
するChild Contents Listとの２つが作成され、これら
各Child Contents ListのAudio_Track_Object[0]〜[n-
1]に対しては、エリアＴＯＣの内容に従って、そのチャ
ンネルエリアに記録されているオーディオトラックの情
報を作成して格納するようにされる。

【０２４８】ところで、先にも述べたように、本実施の
形態では、ＳＡＣＤタイプとしてのDisc Subunit Ident
ifier 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_specifi
c_type_informationを作成し、更にこれを含めて各Audi
o Track ObjectのSACD_specific_info_blockを作成する
ようにされる。

【０２５２】そして、次のステップＳ２０４において
は、上記ステップＳ２０１，Ｓ２０３，Ｓ２０４により
作成された、album_set_info_block、album_catalog_co
de_info_block、及びSACD_specific_info_blockを、適
宜所定のエリアに対して格納することで、ＳＡＣＤタイ
プのDisc Subunit Identifier Descriptorを作成する。

【０２５３】また、図５６に示すステップＳ１０１にお
いて、複層ＨＤディスクであることが判別された場合に
は、ステップＳ１０６に進む。複層ＨＤディスクは、２
つのＨＤレイヤー１０２を有していることから、例えば
先ずステップＳ１０６により、第１ＨＤレイヤー（例え
ば第１記録層としてのＨＤレイヤー）に記録されている
マスターＴＯＣ及びエリアＴＯＣを読み出すようにされ
る。そして、次のステップＳ１０７において、第２ＨＤ
レイヤー（例えば第２記録層としてのＨＤレイヤー）に
記録されているマスターＴＯＣ及びエリアＴＯＣを読み
出すようにされる。

【０２５４】このようにして、２つのＨＤレイヤーから
マスターＴＯＣ及びエリアＴＯＣを読み出した後はステ
ップＳ１０８のDisc Subunit Identifier Descriptor作
成処理に移行する。この場合ＨＤレイヤーは２層である
が、１つのボリュームとして扱うことができるものとさ
れており、従って、ステップＳ１０８の処理としては、
例えば先に説明したステップＳ１０５の処理と同様とさ
れてよい。

【０２５５】また、ステップＳ１０１においてハイブリ
ッドディスクであることが判別された場合にはステップ
Ｓ１０９に進む。ハイブリッドディスクにはＣＤレイヤ
ー１０１とＨＤレイヤー１０２との２層が形成されてい
る。そこで、ステップＳ１０９においては、先ず、ＨＤ
レイヤー１０２からマスターＴＯＣ、及びエリアＴＯＣ
を読み込むための処理を実行する。そして次のステップ
Ｓ１１０において、ＣＤレイヤー１０１に記録されてい
るＴＯＣ（ＣＤ−ＴＯＣ）を読み込むための処理を実行
する。以上、上記ステップＳ１０９及びＳ１１０の処理
によって、ＳＡＣＤ（ＨＤレイヤー）のＴＯＣ情報と、
ＣＤ−ＤＡ（ＣＤレイヤー）のＴＯＣ情報とが取得され
たことになる。

【０２５６】次のステップＳ１１１においては、上記の
ようにして取得した上記各ＴＯＣの内容に基づき、Disc
Subunit Identifier Descriptorを作成する。ここで作
成されるのは、図５４に示す構造及び内容のDisc Subun
it Identifier Descriptorとされる。

【０２５７】このステップＳ１１１としての処理は、例
えば図５８に示すようにして実行される。図５８におい
ては、先ずステップＳ３０１において、ＳＡＣＤボリュ
ームDescriptorを作成するものとしている。ここでいう
ＳＡＣＤボリュームDescriptorとは、図５４に示す構造
を例に挙げれば、Root_object_list_id_1（図５４
（ａ））により指定されるSACD_Root Contents List
（図５４（ｃ））、及びその階層下のChild Contents L
ist（図５４（ｅ））より成る構造を指す。つまりは、
ＨＤレイヤー１０２から取得したマスターＴＯＣ及びエ
リアＴＯＣの内容に従って、図５４（ｃ）（ｅ）に示さ
れるような階層構造による、ＳＡＣＤタイプの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 Conten
ts List（図５４（ｂ））の構造内のlist_typeにはList
_id=1000h（ＣＤ−ＤＡ）を格納し、media_typeのエリ
アには0101h（ＣＤ−ＤＡ）を格納することで、実際にC
D_Root Contents Listであることが定義されるようにす
る。同様にして、SACD_Root Contents List（図５４
（ｃ））の構造内のlist_typeにはList_id=2000h（ＳＡ
ＣＤ）を格納し、media_typeのエリアには0501h（ＳＡ
ＣＤ）を格納することで、実際にCD_Root Contents Lis
tであることが定義されるようにする。

【０２５９】図５６に示す処理において、ステップＳ１
０３，Ｓ１０５，Ｓ１０８，Ｓ１１１の何れかを実行し
た後は、ステップＳ１１２に進む。ステップＳ１１２に
おいては、上記ステップＳ１０３，Ｓ１０５，Ｓ１０
８，Ｓ１１１の何れかの処理を経たことによって作成さ
れたDisc Subunit Identifier Descriptorを、ＲＡＭ１
１ａに書き込んで保持させるための処理を実行する。こ
れ以降、Ｃｏｎｔｒｏｌｌｅｒ（例えばパーソナルコン
ピュータ）が、当該ディスクプレーヤ０をＴａｒｇｅｔ
と見なして、Disc Subunit Identifier Descriptorを要
求してきた場合には、システムコントローラ１１は、こ
の要求に応答したDisc Subunit Identifier Descriptor
をＲＡＭ１１ａから読み出して送信することが可能にな
る。

【０２６０】７．Disc Subunit Identifier Descriptor
の送信処理続いて、システムコントローラ１１が実行するDisc Sub
unit Identifier Descriptorの送信処理について、図５
９及び図６０に示すフローチャートを参照して説明す
る。先ず図５９には、Disc Subunit Identifier Descri
ptor全体を送信する場合の処理が示されている。ここ
で、Disc Subunit Identifier Descriptor全体の送信を
要求するためのＡＶ／Ｃコマンドとしては、ＲＥＡＤ
ＤＥＳＣＲＩＰＴＯＲｃｏｍｍｎａｄが定義されている
ものとする。そして、この処理にあっては、図６に示し
たシステム構成を例に挙げるとすれば、ディスクプレー
ヤ０がＴａｒｇｅｔとなり、パーソナルコンピュータ２
００がＣｏｎｔｒｏｌｌｅｒとして機能することにな
る。

【０２６１】図５９に示す処理にあっては、システムコ
ントローラ１１は、先ずステップＳ４０１において、Ｃ
ｏｎｔｒｏｌｌｅｒから送信されてくるＲＥＡＤＤＥ
ＳＣＲＩＰＴＯＲｃｏｍｍｎａｄが受信されるのを待
機している。そして、このコマンドが受信されたことが
判別されるとステップＳ４０２に進んで、Disc Subunit
Identifier Descriptor全体のデータをＡＶ／Ｃコマン
ドパケット化するための処理を実行する。つまり、図２
２に示したＡＶ／Ｃコマンドパケットとして、ＲＥＡＤ
ＤＥＳＣＲＩＰＴＯＲｃｏｍｍｎａｄに応答するｒ
ｅｓｐｏｎｃｅであることが表されるＰａｃｋｅｔＨ
ｅａｄｅｒの内容を作成し、また、Disc Subunit Ident
ifier Descriptorとしての１纏まりの構造をｏｐｅｒａ
ｎｄに付加したｄａｔａｂｌｏｃｋを作成するようにさ
れる。そして、次のステップＳ４０３において、上記ス
テップＳ４０２にて作成されたＡＶ／Ｃコマンドパケッ
トを送信出力する。つまり、このＡＶ／Ｃコマンドパケ
ットが、ＩＥＥＥ１３９４バス１１６に接続されたＣｏ
ｎｔｒｏｌｌｅｒに送信出力されるように、ＩＥＥＥ１
３９４インターフェイス部１４についての動作制御を実
行するものである。

【０２６２】また、本実施の形態のＡＶシステムとして
は、先に図４７に示したＲＥＡＤＩＮＦＯＢＬＯＣＫ
ｃｏｍｍａｎｄを利用すれば、Disc Subunit Identif
ier Descriptorにおける特定のInfomaition Blockを指
定して送受信することが可能とされる。このＲＥＡＤ
ＩＮＦＯＢＬＯＣＫｃｏｍｍａｎｄの受信に応じた
システムコントローラ１１の処理動作としては、図６０
に示すものとなる。

【０２６３】図６０に示す処理にあっては、先ずステッ
プＳ５０１において、Ｃｏｎｔｒｏｌｌｅｒから送信さ
れてくるＲＥＡＤＩＮＦＯＢＬＯＣＫｃｏｍｍａ
ｎｄの受信を待機しており、このコマンドを受信する
と、ステップＳ５０２に進む。

【０２６４】ステップＳ５０２においては、受信したＲ
ＥＡＤＩＮＦＯＢＬＯＣＫｃｏｍｍａｎｄに格納
されているinfo_block_refernce_path、data_length、a
ddressなどの情報に基づいて、要求された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_infor
mationの構造を示す説明図である。

【図３７】Audio Track Object entry_specific_inform
ationの構造を示す説明図である。

【図３８】Disc Subunit typeの定義内容を示す説明図
である。

【図３９】Disc Subunit List List_specific_informat
ionの構造を示す説明図である。

【図４０】Root Contents Listとしての構造概念を示す
説明図である。

【図４１】Root Contents List List_specific_informa
tionの構造を示す説明図である。

【図４２】media typeの定義内容を示す説明図である。

【図４３】information blockの基本構造を示す説明図
である。

【図４４】information block typeの定義内容を示す説
明図である。

【図４５】information block typeの定義内容の詳細を
示す説明図である。

【図４６】List内におけるinformation blockの配置構
造を概念的に示す説明図である。

【図４７】ＲＥＡＤＩＮＦＯＢＬＯＣＫｃｏｍｍ
ａｎｄの構造を示す説明図である。

【図４８】ＳＡＣＤに対応するRoot Contents List Lis
t_specific_informationの構造を示す説明図である。

【図４９】album_set_info_blockの構造を示す説明図で
ある。

【図５０】album_catalog_code_info_blockの構造を示
す説明図である。

【図５１】ＳＡＣＤに対応するAudio Track Object ent
ry_specific_informationの構造を示す説明図である。

【図５２】SACD_specific_informationの構造を示す説
明図である。

【図５３】ＳＡＣＤに対応するDisc Subunit Identifie
r Descriptorの全体構造を示す説明図である。

【図５４】本実施の形態のハイブリッドディスクに対応
するDisc Subunit Identifier Descriptorの全体構造を
示す説明図である。

【図５５】ＳＡＣＤ及びＣＤ−ＤＡについてのList Typ
eの定義内容を示す説明図である。

【図５６】本実施の形態が対応するディスクについての
Disc Subunit Identifier Descriptor作成処理を示すフ
ローチャートである。

【図５７】本実施の形態の単層ＨＤディスクに対応した
Disc Subunit Identifier Descriptor作成処理を示すフ
ローチャートである。

【図５８】本実施の形態のハイブリッドディスクに対応
したDisc Subunit Identifier Descriptor作成処理を示
すフローチャートである。

【図５９】Disc Subunit Identifier Descriptor送信の
ための処理動作を示すフローチャートである。

【図６０】Information Block送信のための処理動作を
示すフローチャートである。である。

【符号の説明】

１光ディスク、２スピンドルモータ、３光学ヘッ
ド、３ＡＣＤ用ヘッド部、３ＢＨＤ用ヘッド部、４
ＲＦアンプ、５サーボ回路、６駆動回路、７エ
ラー訂正及びデコード回路、８メモリコントローラ、
９バッファメモリ、１０Ｄ／Ａコンバータ、１１
システムコントローラ、１２操作部、１３表示部、
１４ＩＥＥＥ１３９４インターフェイス部、１５Ａ，
１５Ｂ対物レンズ、１６Ａ，１６Ｂ２軸機構、１７
Ａ，１７Ｂ半導体レーザ、１８Ａ，１８Ｂディテク
タ、２０判別信号生成部、１０１ＣＤレイヤー、１
０２ＨＤレイヤー、１１６データバス（ＩＥＥＥ１
３９４バス）

Claims

【特許請求の範囲】

【請求項１】記録フォーマットが異なる複数の記録情
報が記録される記録媒体に対して再生を行うことで、少
なくとも、記録情報を管理するために上記各記録情報内
に設けられる管理情報を取得することのできる情報取得
手段と、上記情報取得手段により取得した上記各記録情報内の管
理情報に基づいて所定の伝送フォーマットに対応した記
述情報を作成するのに、１つの記述情報の構造内におい
て、上記複数の記録情報ごとの記述内容がそれぞれ異な
る記録媒体として定義された情報単位として管理される
ように記述を行う、記述情報作成手段と、を備えていることを特徴とする再生装置。
【請求項２】上記記録フォーマットの１つは、サンプ
リング周波数が、基準サンプリング周波数ｆｓとされ、
量子化ビット数が所定のマルチビットとされるデータフ
ォーマットに対応していることを特徴とする請求項１に
記載の再生装置。
【請求項３】上記記録フォーマットの１つは、サンプ
リング周波数ｆｓ×Ｎ（但し、ｆｓは所定の基準サンプ
リング周波数、Ｎは２以上の自然数）とされ、量子化ビ
ット数が１ビットとされるデータフォーマットに対応し
ていることを特徴とする請求項１に記載の再生装置。
【請求項４】記録フォーマットが異なる複数の記録情
報が記録される記録媒体に対して再生を行うことで、少
なくとも、記録情報を管理するために上記各記録情報内
に設けられる管理情報を取得する情報取得ステップと、上記情報取得ステップにより取得した上記各記録情報内
の管理情報に基づいて所定の伝送フォーマットに対応し
た記述情報を作成するのに、１つの記述情報の構造内に
おいて、上記複数の記録情報ごとの記述内容がそれぞれ
異なる記録媒体として定義された情報単位として管理さ
れるように記述を行う、記述情報作成ステップと、要求に応じて、上記所定の伝送フォーマットに従って、
上記記述情報を送信出力することのできる送信ステップ
と、を実行するように構成されていることを特徴とする情報
伝送方法。
【請求項５】上記記録フォーマットの１つは、サンプ
リング周波数が、基準サンプリング周波数ｆｓとされ、
量子化ビット数が所定のマルチビットとされるデータフ
ォーマットに対応していることを特徴とする請求項４に
記載の情報伝送方法。
【請求項６】上記記録フォーマットの１つは、サンプ
リング周波数ｆｓ×Ｎ（但し、ｆｓは所定の基準サンプ
リング周波数、Ｎは２以上の自然数）とされ、量子化ビ
ット数が１ビットとされるデータフォーマットに対応し
ていることを特徴とする請求項４に記載の情報伝送方
法。
【請求項７】上記所定の伝送フォーマットは、ＩＥＥ
Ｅ１３９４データインターフェイスとされていることを
特徴とする請求項４に記載の情報伝送方法。