JP4055313B2 - 再生装置、及び情報伝送方法 - Google Patents
再生装置、及び情報伝送方法 Download PDFInfo
- 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
Links
Images
Landscapes
- Signal Processing For Digital Recording And Reproducing (AREA)
- Management Or Editing Of Information On Record Carriers (AREA)
- Small-Scale Networks (AREA)
Description
【発明の属する技術分野】
本発明は、所定の記録媒体に対応して再生が可能な再生装置、また、この再生装置における情報伝送方法に関するものである。
【0002】
【従来の技術】
オーディオデータが記録された再生専用ディスクとして、CD(Compact Disc)が広く普及していると共に、このCD−DAより大容量な新たな光ディスクとしてDVD(Digital Versatile Disc)が提案されている。
このDVDは直径12cmの光ディスクに従来のCDのトラックピッチ1.6μmの半分の0.8μmで情報を記録し、半導体レーザの波長をCDの780nmから例えば650nmに変更し、更にCDで採用されたEFM(Eight to Fourteen Modulation)変調方式に改良を加えて片面で約4Gバイト相当の高密度記録を実現させている。
そして現在、例えば上記のようなDVDに準拠して、CDよりも高音質とされるオーディオデータを記録した高音質オーディオディスクも提案されている。
【0003】
CDのデータフォーマットとしては、周知のように、サンプリング周波数が44.1KHzとされ、量子化ビットは16ビットとされる。また、デジタルオーディオ信号の記録変調方式にはEFM(Eight to Fourteen Moduration)が採用されているものである。
これに対して、上記高音質オーディオディスクのデータフォーマットとしては、サンプリング周波数については、上記44.1KHzの64倍である2.8224MHzという非常に高い周波数によりサンプリングを行い、更に、ΣΔ変調による1ビット量子化を行ってメディアへ記録するものとしている。
また、この高音質オーディオディスクは、従来から販売されているコンパクトディスクと外観はほぼ同じとされる。
なお、以降の説明にあたり、CDのデータフォーマットによるオーディオデータについては「CDデータ」といい、高音質オーディオディスクのデータフォーマットによるオーディオデータについては、「HD(Hi-Definition)データ」ともいうことにする。
【0004】
また、上記したHDデータが記録されるディスクとしては、記録層として2つの層(レイヤー)を備えたマルチレイヤーディスク(複層ディスク)とすることも提案されている。
このマルチレイヤーディスクとして、1つには、各レイヤーにHDデータを記録するようにした複層ディスクが提案されている。
そしてもう1つには、一方のレイヤーにCDデータを記録し、他方のレイヤーにHDデータを記録した、いわゆるハイブリッドディスクの形態とすることが提案されている。
なお、レイヤーの名称として、HDデータが記録されるレイヤーについては「HDレイヤー」ともいい、また、CDデータが記録されるレイヤーについては「CDレイヤー」ともいうことにする。
【0005】
上記ハイブリッドディスクについては、音楽等のデータ内容(プログラム)としては、各レイヤーで同一の内容(例えば同一の曲)とすることが考えられており、従ってその同一内容のデータが、CDレベルの通常品質のデータとして一方のレイヤーに記録されるとともに、より高品質なデータが他方のレイヤーに記録されるようにする。
【0006】
このようなハイブリッドディスクにおいては、一方のレイヤーは、CDデータが記録されることになるので、現在市場で普及しているCDプレーヤーの機能によっても再生可能となる。
そして、CDプレーヤとしての機能を有する再生装置において、HDデータに対応したデコーダを備えれば、上記他方のレイヤーに記録された新たなフォーマットのデータも再生できる再生装置が実現される。
即ちこのような再生装置においては、両方のレイヤーからの再生を可能にすることで、一般に多数所有されているコンパクトディスクも再生でき、かつ上記したハイブリッドディスクについても再生可能となる。また、当然のこととして、HDデータを記録したHDレイヤーの1層のみを有する高音質オーディオディスクについても再生可能となるものである。
【0007】
また、近年においては、デジタルデータインターフェイスとして、IEEE(Institute of Electrical Engineers)1394データインターフェイスが知られてきている。
IEEE1394のデータインターフェイスは、例えばSCSIやUSBなどのデータインターフェイスよりもデータ転送レートが高速であり、周知のように、所要のデータサイズを周期的に送受信することが保証されるIsochronous通信が可能とされる。このため、IEEE1394データインターフェイスは、AVなどのストリームデータをリアルタイムで転送するのに有利とされている。
【0008】
このため、各種デジタルAV(Audio Visual)機器やパーソナルコンピュータ装置等の電子機器を、例えばIEEE(The Institute of Electrical and Electronics Engineers)1394等のデジタルデータインターフェイス規格に従ったデータバスを介して相互に接続することで、機器間でデータを送受信できるようにしたデータ伝送システムが提案されてきている。これにより、AVシステムとして有用とされる各種機能を与えることができる。
【0009】
このようなAVシステムとしての機能の一例としては、いわゆるリモート制御も可能となる。例えば、データバスを介してディスク記録再生装置とパーソナルコンピュータが接続されているとして、ディスク記録再生装置に対する記録再生、更には記録ソースの編集などに関する操作をパーソナルコンピュータ装置側での操作によって行うといったことも可能となる。
【0010】
【発明が解決しようとする課題】
現状、IEEE1394データインターフェイスに従ったAV機器を対象とする伝送規格にあっては、例えば上記したCDや、また、既に普及率の高いMD(Mini Disc)などのメディアに対応しては、ほぼ機能が充実している段階にある。
【0011】
そして例えば、IEEE1394データインターフェイスによる各種機能を上記のようにして新たに出現してくる高音質オーディオディスクなどのメディアに対応させようとした場合には、上記したCDなどの機能に対応して既に定義された規格を利用することで、或る程度の機能の充実を図ることが可能である。
但し、例えば高音質オーディオディスクに特有で、CDなどのフォーマットでは決められていないような規格に対応した機能を実現することはできないことになる。これは、例えば高音質オーディオディスクを再生可能な再生装置を含めてAVシステムを構築した場合に、その利便性が十分に発揮されないということにつながり得る。
このため、IEEE1394伝送フォーマット上で、例えば高音質オーディオディスク等の新規なメディアに対応した機能が必要充分となるように拡充の図られることが求められている。
【0012】
【課題を解決するための手段】
そこで本発明は上記した課題を考慮して、再生装置について次のように構成する。
つまり、第1の記録方式で単層にデータが記録された第1のディスク状記録媒体と、上記第1の記録方式とは異なる第2の記録方式で単層にデータが記録された第2のディスク状記録媒体と、上記第1の記録方式で第1の記録層にデータが記録されるとともに上記第2の記録方式で上記第1の記録層とは異なる第2の記録層にデータが記録され上記第1の記録層と上記第2の記録層とが積層された第3のディスク状記録媒体と、上記第2の記録方式でデータが記録された第1の記録層と上記第2の記録方式でデータが記録された第2の記録層とが積層された第4のディスク状記録媒体とのうちの装着された1のディスクを再生する再生手段と、上記再生手段によってディスク状記録媒体の所定領域から読み出されるデータに基づいてディスク状記録媒体の種別を判別する種別判別手段と、上記種別判別手段にて上記第4のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合には、各層に記録された管理情報を取得し、上記種別判別手段にて上記第3のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合に、記録フォーマットが異なる各々の記録方式で記録される管理情報の各記録層における記録位置ごとに複数の記録情報が記録される記録媒体に対して再生を行うことで、少なくとも、記録情報を管理するために上記各記録情報内に設けられる管理情報を取得することのできる情報取得手段と、上記情報取得手段により取得された上記各記録情報内の管理情報に基づいて所定の伝送フォーマットに対応した記述情報を作成するのに、上記第3のディスク状記録媒体の場合には1つの記述情報の構造内において、上記複数の記録情報ごとの記述内容がそれぞれ異なる記録媒体として定義された情報単位として管理されるように記述を行い、上記第4のディスク状記録媒体の場合には上記積層された記録層を単一のディスク状記録媒体として管理されるように記述情報の記述を行う記述情報作成手段とを備えることとした。
【0013】
また、情報伝送方法として次のように構成する。
第1の記録方式で単層にデータが記録された第1のディスク状記録媒体と、上記第1の記録方式とは異なる第2の記録方式で単層にデータが記録された第2のディスク状記録媒体と、上記第1の記録方式で第1の記録層にデータが記録されるとともに上記第2の記録方式で上記第1の記録層とは異なる第2の記録層にデータが記録され上記第1の記録層と上記第2の記録層とが積層された第3のディスク状記録媒体と、上記第2の記録方式でデータが記録された第1の記録層と上記第2の記録方式でデータが記録された第2の記録層とが積層された第4のディスク状記録媒体とのうちの装着された1のディスクを再生する再生ステップと、上記再生手順によってディスク状記録媒体の所定領域から読み出されるデータに基づいてディスク状記録媒体の種別を判別する種別判別ステップと、上記種別判別ステップにて上記第4のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合には、各層に記録された管理情報を取得し、上記種別判別手順にて上記第3のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合に、記録フォーマットが異なる各々の記録方式で記録される管理情報の各記録層における記録位置ごとに複数の記録情報が記録される記録媒体に対して再生を行うことで、少なくとも、記録情報を管理するために上記各記録情報内に設けられる管理情報を取得する情報取得ステップと、上記情報取得ステップにより取得された上記各記録情報内の管理情報に基づいて所定の伝送フォーマットに対応した記述情報を作成するのに、上記第3のディスク状記録媒体の場合には1つの記述情報の構造内において、上記複数の記録情報ごとの記述内容がそれぞれ異なる記録媒体として定義された情報単位として管理されるように記述を行い、上記第4のディスク状記録媒体の場合には上記積層された記録層を単一のディスク状記録媒体として管理されるように記述情報の記述を行う記述情報作成ステップと、要求に応じて、上記所定の伝送フォーマットに従って、上記記述情報を送信出力することのできる送信ステップとを実行するように構成することとした。
【0014】
上記各構成によれば、記録フォーマットが異なる複数の記録情報が記録される記録媒体に対応しては、この記録情報ごとの記述内容は、それぞれ異なる記録媒体として定義された情報単位として1つの記述情報構造内で管理される。
例えば記述情報の規格として、記録フォーマットを記録媒体のタイプとして扱っている場合であっても、上記のようにして、記録フォーマットの異なる記録情報を、異なる記録媒体として定義された情報単位として扱って管理することで、1つの記述情報の構造で、複数の異なる記録フォーマットの記録情報が記録された記録媒体を表現することが可能になる。
【0015】
【発明の実施の形態】
以下、本発明の実施の形態の再生装置を以下の順序で説明する。なおこの再生装置は、光ディスクとしての記録媒体に対応するものとする。
なお、以降の説明は次の順序で行う。
1.ディスク種別
2.ディスクのゾーン構造
3.AVシステム
3−1.システム例
3−2.ディスクプレーヤ
3−3.パーソナルコンピュータ
4.IEEE1394データインターフェイス
4−1.概要
4−2.スタックモデル
4−3.信号伝送形態
4−4.機器間のバス接続
4−5.パケット
4−6.トランザクションルール
4−7.アドレッシング
4−8.CIP(Common Isochronous Packet)
4−9.コネクションマネージメント
4−10.FCPにおけるコマンド及びレスポンス
4−11.AV/Cコマンドパケット
4−12.プラグ
4−13.Asynchronous Connection送信手順
5.本実施の形態のDisc Subunit Identifier Descriptor
5−1.基本概念
5−2.Subunit Identifier Descriptor
5−3.Object List Descriptor
5−4.Object Entry
5−5.Disc Subunit Object
5−6.Disc Subunit Object entry_specific_information
5−7.Audio Track Object entry_specific_information
5−8.Disc Subunit List List_specific_information
5−9.Root Contents List
5−10.Root Contents List List_specific_information
5−11.information block
5−12.Read Info Block command
5−13.SACD type
5−14.SACD type/Root Contents List List_specific_information
5−15.SACD type/Audio Track Object entry_specific_information
5−16.SACD typeのDisc Subunit Identifier Descriptor
5−17.ハイブリッドディスクのDisc Subunit Identifier Descriptor
6.Disc Subunit Identifier Descriptor作成処理
7.Disc Subunit Identifier Descriptorの送信処理
【0016】
1.ディスク種別
本例の再生装置では後述する4種類のディスクに対応するものとするが、まずディスク種別としては記録層の数により大別して単層ディスク(シングルレイヤーディスク)と複層ディスク(マルチレイヤーディスク)があり、これについて図1で説明する。
【0017】
図1(a)は記録データによるピットが形成される記録層Lが1つ形成される単層ディスクであり、記録層Lに対して上面及び下面が透過サブストレートTSとされている。このシングルレイヤディスクは、例えば従来より知られているCD−DAやDVDのシングルレイヤディスクに相当する。
また図1(b)は記録データによるピットが形成される記録層が第1記録層L1と第2記録層L2として2つ形成される複層ディスクである。この場合、第1記録層L1と第2記録層L2は接着層Zを介して形成され、その第1記録層L1,第2記録層L2に対する上面及び下面が透過サブストレートTSとされている。
【0018】
ディスク直径としては、単層ディスクも複層ディスクも12cmと8cmのものが考えられている。
そしてディスク上は大きくわけて、内周側からリードイン、データエリア、リードアウトとよぶ3つの領域が形成されている。
リードインが開始される位置としての最大直径は45.2mmと規定され、またデータエリアが開始される位置としての最大直径は48mmと規定されている。
【0019】
このように記録層の数として、単層ディスク、複層ディスクが存在することに加え、記録層の形成位置(ディスク厚み方向の位置)による種別も存在する。
これは具体的にはCD方式におけるデータ記録層と、DVD方式におけるデータ記録層による違いでもある。
【0020】
なお説明上、CD方式のデータを「CDデータ」といい、CDデータが記録された記録層を、「CDレイヤー」ということとする。
ここでいうCDデータとは、通常のCD−DAで採用されているデータ形式であって、即ち、サンプリング周波数fs=44.1KHzでサンプリングされた16ビットデジタルオーディオ信号をEFM方式で変調したデータのことである。
またこのようなCDデータよりも高品位、即ち高音質なデータとして、DVD方式に準拠した形でのオーディオデータ形式が提案されている。これはサンプリング周波数を例えば上記サンプリング周波数fs(=44.1KHz)の64倍という非常に高いサンプリング周波数である2.842MHz(=64fs)でΣΔ変調された1ビットデジタルオーディオ信号を記録するものである。このようなデータを「HD(Hi-Definition)データ」ということとし、またHDデータが記録された記録層を「HDレイヤー」と呼ぶこととする。
【0021】
ここでCDデータとHDデータの差異を簡単に説明する。
周波数帯域としてはCDデータは5〜20KHzを実現し、HDデータはDC成分〜100KHzの広範囲の周波数帯域が実現できる。
ダイナミックレンジは、 CDデータではオーディオ帯域全体で98(dB)を実現し、HDデータはオーディオ帯域全体で120(dB)の周波数帯域が実現できる。
【0022】
CDレイヤーに記録されるデータの最小ピット長は0.83μmに対して、HDレイヤーに記録されるデータの最小ピット長は0.4μmである。
トラックピッチに関しては、CDレイヤーは1.6μmに対して、HDレイヤーは0.74μmである。
また、読出レーザー波長としては、CDレイヤーは780nmに対して、HDレイヤーは650nmと短波長化が図られている。
更に光学ヘッドのレンズの開口率(NA)はCDレイヤーの0.45に対して、HDレイヤーは0.6とされる。
このように、最小ピット長、トラックピッチ、レンズ開口率NA、レーザー波長を変化させることで、CDレイヤーのデータ容量は780MBに対してHDレイヤーのデータ容量は4.7GBとはるかに大きいデータ容量が記録できる。
【0023】
このようなCDデータ又はHDデータが記録されるとともに、層構造として単層、複層の別が存在する、本例の再生装置において再生可能な4種類のディスクとは、「CD−DA」「単層HDディスク」「ハイブリッドディスク」「複層HDディスク」となる。
これらの各ディスクの違いを図2、図3で説明する。図2は、各種別のディスクにおいて記録層に記録されるデータ種別を、また図3は記録層の形成位置を、それぞれ模式的に示している。
【0024】
「CD−DA」
CD−DAとは、いわゆる従来より普及しているオーディオ用コンパクトディスクを指し、図2(a)のように単層ディスクとして記録層Lが形成される。そしてこの記録層Lは、斜線部として示すようにCDレイヤー101とされ、CDデータが記録される。
このCD−DAの場合、図3(a)に示すように、記録層Lは、ディスク表面(図面でディスク下部となるレーザ入射面)から約1.2mmの位置(つまりレーベル面に近い位置)に形成されている。
【0025】
「単層HDディスク」
単層HDディスクとは、単層ディスクとしてのDVDに準拠しているものである。図2(b)のように単層ディスクとして記録層Lが形成され、この記録層Lは、点描部として示すようにHDレイヤー102とされる。つまりHDデータが記録される。
この単層HDディスクの場合、図3(b)に示すように、記録層Lは、ディスク表面(レーザ入射面)から約0.6mmの位置、つまり厚み方向に概略中央となる位置に形成されている。
このような単層HDディスクは、オーディオデータがHDデータとして記録されたメディアとなるため、CD−DAに比べて高品位なオーディオ再生が可能となる。
【0026】
「ハイブリッドディスク」
ハイブリッドディスクとは、上記CD−DAと単層HDディスクを物理的に張り合わせたような形態となる。
即ち図2(c)のように複層ディスクとして第1記録層L1,第2記録層L2が形成される。そして第1記録層L1はHDレイヤー102とされてHDデータが記録され、第2記録層L2はCDレイヤー101とされてCDデータが記録される。
このハイブリッドディスクの場合、図3(b)に示すように、第1記録層L1は、ディスク表面(レーザ入射面)から約0.6mmの位置に形成され、第2記録層L2は、ディスク表面(レーザ入射面)から約1.2mmの位置に形成されている。
このようなハイブリッドディスクにおいては、記録する音楽等のデータ内容(プログラム)としては、例えば各レイヤーで同一の内容(例えば同一の曲)とする。つまり同一内容の音楽等のデータを、CDレベルの通常品質のデータ(CDデータ)としてCDレイヤー101に記録し、より高品質なデータ(HDデータ)としてHDレイヤー102に記録することが考えられる。このようにすると、現在で普及しているCDプレーヤーではCDレイヤー101の再生が可能であるため、CDデータの再生を楽しむことができ、また更にCDプレーヤ等においてHDデータに対応するデコーダや、短波長レーザを出力可能な光学ヘッド等を備えれば、HDレイヤーに記録された高品位な音楽等も再生できる。
つまり、ハイブリッドディスクは、一般に多数所有されているCDプレーヤでも、またHDデータ対応の機器でも再生できるメディアとすることができる。
【0027】
「複層HDディスク」
複層HDディスクとは、単層HDディスクを物理的に張り合わせた形態となる。即ち図2(d)のように複層ディスクとして第1記録層L1、第2記録層L2が形成され、この両記録層L1、L2は、いづれもHDレイヤー102とされる。つまりHDデータが記録される。
この複層HDディスクの場合、図3(d)に示すように、記録層L1、L2はいずれも、ディスク表面(レーザ入射面)から約0.6mmの位置、つまり厚み方向に概略中央となる位置に形成されている。
このような複層HDディスクは、オーディオデータがHDデータとして記録されたメディアとなるため、CD−DAに比べて高品位なオーディオ再生が可能となるとともに、上記単層HDディスクの2倍の記録容量を実現できる。
【0028】
2.ディスクのゾーン構造
続いて、上記したハイブリッドディスクを例に挙げて、CDレイヤー101及びHDレイヤー102の各ゾーン構造について、図4を参照して説明する。
【0029】
図4(a)に示すCDレイヤー101の構造と、図4(b)に示すHDレイヤー102の構造から分かるように、CDレイヤー101及びHDレイヤー102は共に、ディスク内周側から外周側に向かって、リードインゾーン(Lead-in Zone)、データゾーン(Data Zone)、リードアウトゾーン(Lead-out Zone)が形成される。
【0030】
CDレイヤー101の構造は、従来からのCDのゾーン構造と同一であるとされる。つまり、リードインゾーンの所定位置にTOC(Table Of Contents)が記録されており、データゾーンに対して楽曲であるオーディオデータが記録される。なお、以降においては、CDレイヤー101に記録されるTOCは、CD−TOCと表記して、次に述べるHDレイヤー102の各TOCと区別する。
【0031】
また、HDレイヤー102の構造を図5に示す。
図5(a)に示されるHDレイヤー102には、図4(b)に示したと同じ内容のゾーン構造が示される。そして、このゾーン構造内にあって、データゾーン(Data Zone)は、図5(b)に示すように、その内周側から、UDFファイルシステム(File System)エリア、マスターTOC(Master TOC)エリア、オーディオエリア(Audio Area)、及びエクストラデータエリア(Extra Data Area)に分割される。
UDFファイルシステム(File System)エリアには、このHDレイヤー102に記録されるデータを管理するファイルシステムが格納される。
【0032】
マスターTOC(Master TOC)エリアには、図5(c)に示すようにして、アルバム情報とディスク情報とが格納される。
ここでいう「アルバム」とは、例えば2枚組、3枚組などのようにして販売されるような、複数枚のセットで1組とされるものをいう。そして、アルバム情報とはこのアルバムに関連する情報とされる。
このアルバム情報は、図5(c)の上段に示されるように、アルバムを成すディスク枚数、アルバムを成すディスクごとに付される通し番号であるアルバム識別番号、及び、アルバム単位でのジャンル、アルバム単位でのタイトル、及びアルバム単位でのアーティスト名等の情報を備える。
【0033】
また、ディスク情報とは、このHDレイヤー102を1枚のディスクとして扱った場合の、このディスクに関連する情報とされ、図5(c)の下段に示すようにして、ディスク種類、ディスク制作日、ディスク識別番号、ディスク単位でのジャンル、ディスク単位でのタイトル、ディスク単位でのアーティスト、ディスクの制作者などの情報を備えるものである。
【0034】
また、オーディオエリア(Audio Area)は、大別して、2チャンネルステレオによるHDデータを記録する2チャンネルステレオエリア(2-channel Streo Area)と、これに続けて、例えば2チャンネルよりも多いマルチチャンネルによるHDデータを記録するマルチチャンネルエリア(Multichannel Area)とに分割される。
【0035】
これら2チャンネルステレオエリアとマルチチャンネルエリアの各々においては、図示していないが、オーディオトラックといわれる、トラック単位で管理されるオーディオデータがトラックナンバ順に記録されるエリアが形成される。そして、前後からこのオーディオトラックを挟むようにして、2つのエリアTOC(Area TOC-1,Area TOC-2)が配置される。
【0036】
これらエリアTOC(Area TOC-1,Area TOC-2)は、それぞれが配置されている各チャンネルエリアのオーディオデータをトラック単位で管理するためのデータ構造を有している。つまり、2チャンネルステレオエリアのArea TOC−1,Area TOC−2は、2チャンネルステレオエリアに記録されたオーディオデータをトラック単位で管理する情報を有し、マルチチャンネルエリアのエリアTOC(Area TOC-1,Area TOC-2)は、マルチチャンネルエリアに記録されたオーディオデータをトラック単位で管理する情報を有する。
また、エリアTOC(Area TOC-1,Area TOC-2)では、各トラックのタイトル、アーティスト、作曲者、作詞者、ジャンル、編曲者、メッセージ、国際著作権コード(ISRC)などの情報も格納することができるようになっている。
特に、マルチチャンネルエリアのエリアTOC(Area TOC-1,Area TOC-2)には、マルチチャンネルステレオとしてのオーディオ再生のスピーカレイアウトを指定するスピーカレイアウト情報が格納される。
マルチチャンネルエリアに記録されるデータは、そのフォーマットによっても異なるが、例えば3以上のスピーカを所定の配置形態によりレイアウトして再生音声を出力させることで、その音響効果が発揮されるようになっている。このため、上記のようにして、スピーカレイアウト情報を格納しておくことで、例えば各オーディオトラックごとに適切とされるスピーカレイアウトを指示することが可能になる。
【0037】
また、エクストラデータエリア(Extra Data Area)は、例えばオーディオデータ以外の、テキスト、画像データなどを記録するために割り当てられた領域とされる。
【0038】
なお、例えば図2(b)に示した単層ディスクであれば、上記図5に示した構造のHDレイヤー102が1つの記録層Lとして形成されていることになる。
また、図2(d)に示した複層ディスクであれば、第1記録層L1と第2記録層L2の各々が、図5に示した構造を有しているものとされる。
【0039】
3.AVシステム
3−1.システム例
図6は、IEEE1394デジタルデータインターフェイスにより接続される本実施の形態としてのAVシステムの構成例を示している。
【0040】
図6に示すAVシステムとしては、ディスクプレーヤ0とパーソナルコンピュータ200とをIEEE1394データインターフェイス対応のケーブル601により接続することで構成される。これにより、ディスクプレーヤ0とパーソナルコンピュータ200は、IEEE1394バス116によって相互通信可能となる。
【0041】
ディスクプレーヤ0は、先に図2に示した各ディスクに対応して再生可能に構成されたオーディオ機器であり、IEEE1394バス116を介して再生したオーディオデータを出力することも可能とされている。
【0042】
この場合、パーソナルコンピュータ200は、ディスクプレーヤ0からの再生オーディオデータをIEEE1394バス116を介して入力して、音声出力を行ったり、また、編集処理等を行うことができる。また、ディスクプレーヤ0に対して、再生に関する操作制御を行うことができる。つまり、リモート制御を実行できる。
上記したような機能は、パーソナルコンピュータ200に対して、例えばこのような機能を実現するためのアプリケーションソフトウェアをインストールすることで得られるものである。
なお、本実施の形態が対応するAVシステムとしては、他にも考えられ、例えばMDに対応して記録再生が可能なMDレコーダ/プレーヤなども接続されてよいのであるが、ここでは、必要最小限の機器のみによって構成される例のみに限定して示している。
【0043】
3−2.ディスクプレーヤ
次に上記図6に示したディスクプレーヤ0の内部構成を図7に示す。
この図において装填されている光ディスク1は、図2に示した4種類のうちのいずれかのディスクとされる。
この光ディスク1は、図示しないターンテーブルに載置され、スピンドルモータ2によってCLV(線速度一定:constant liner velocity)又はCAV(角速度一定:constant angler velocity)に回転制御される。
【0044】
この再生装置では、4種類のディスクに対応するために、CDレイヤー101とHDレイヤー102の両方についての再生機能を備える必要があるため、図7に示す光学ヘッド3、RFアンプ4、エラー訂正/デコーダ回路7としては、CDデータ再生系とHDデータ再生系の2系等を備えるものとなり、この2系統の構成は図8に示している。
【0045】
図7に示す光学ヘッド3は、対物レンズ、2軸機構、半導体レーザ、及び上記半導体レーザの出射光及び光ディスク1からの反射の経路となる光学系、反射光を受光するディテクタを有して構成されている。
具体的には図8に示すように、光学ヘッド3としてはCD用ヘッド部3AとHD用ヘッド部3Bが形成され、それぞれ図示するように対物レンズ15A、15B、2軸機構16A、16B、半導体レーザ17A、17B、ディテクタ18A、18B、光学系19A、19Bが形成される。
【0046】
そして上記ターンテーブルに載置されている光ディスクがCD−DAである場合、もしくはハイブリッドディスクのCDレイヤ101を再生する場合は、CD用ヘッド部3Aが用いられる。即ち半導体レーザ17Aは780nmの波長のレーザ出力を行うものとされ、また対物レンズ15Aの開口率は0.45とされている。
一方、上記ターンテーブルに載置されている光ディスクが単層HDディスク又は複層HDディスクである場合、もしくはハイブリッドディスクのHDレイヤー102を再生する場合は、HD用ヘッド部3Bが用いられる。即ち半導体レーザ17Bは650nmの波長のレーザ出力を行うものとされ、また対物レンズ15Bの開口率は0.6とされている。
【0047】
このようにCD用ヘッド部3AもしくはHD用ヘッド部3Bによるレーザ照射が、スピンドルモータ2によって回転されている光ディスク1に対して実行され、その反射光がディテクタ3A又は3Bによって受光される。
【0048】
なお、ホログラム一体型非球面レンズを用いれば、上述したような光学ヘッド3内部に2つの対物レンズ(15A、15B)を設ける必要が無く、1つのレンズで半導体レーザの光路を切換えるのみで構成でき、そのような光学ヘッドを用いてもよい。つまりその場合は半導体レーザのみを短波長用と長波長用の2つ設けるようにし、光学系、対物レンズ、ディテクタ等は共用できる。
また、光学系やディテクタは共用するが、半導体レーザと対物レンズについてはCD用とHD用にそれぞれ用意するような光学ヘッド3の構成も可能である。
【0049】
対物レンズ15A、15Bをそれぞれ支持する2軸機構16A、16Bには、対物レンズ15A、15Bを光ディスク1に接離する方向に駆動するフォーカス用コイルと、対物レンズ15A、15Bを光ディスク1の半径方向に駆動するトラッキング用コイルとが形成されている。
また、この再生装置には、光学ヘッド3全体を光ディスク1の半径方向に大きく移動させるスレッド機構14を更に備えている。
【0050】
光学ヘッド3内のディテクタ(18A又は18B)にて検知した反射光は反射光量に応じた電流信号とされてRFアンプ4に供給され、このRFアンプ4での電流電圧変換、マトリクス演算処理により、フォーカスエラー信号FE、トラッキングエラー信号TEが生成されるとともに再生情報(和信号)としてのRF信号、同じく和信号であるPI(プルイン)信号が生成される。
図8のようにディテクタ18A、18Bが独立系統として形成される場合は、RFアンプ4内には、CD用RF部4A、HD用RF部4Bが形成され、それぞれフォーカスエラー信号FE、トラッキングエラー信号TE、RF信号、PI信号が生成されるようになされる。
なお、両系統でディテクタが共用される場合や、或いはディテクタ18A、18Bの出力が選択的に切り換えられてRFアンプ4に供給されるような構成を取った場合は、CD用RF部、HD用RF部を独立して設ける必要はない。
【0051】
RFアンプ4で生成されたフォーカスエラー信号FE、トラッキングエラー信号TEはサーボ回路5にて位相補償、利得調整をされたのちに駆動回路6に供給され、フォーカスドライブ信号、トラッキングドライブ信号として上述したフォーカス用コイルと、トラッキング用コイルとに印加される。
さらに上記トラッキングエラー信号TEをサーボ回路5内にてLPF(low pass filter)を介してスレッドエラー信号を生成して、駆動回路6からスレッドドライブ信号としてスレッド機構14に印加される。
これによりいわゆるフォーカスサーボ制御、トラッキングサーボ制御、スレッドサーボ制御が実行される。
【0052】
またサーボ回路5はシステムコントローラ11からの指示に基づいて、フォーカスサーチ動作、トラックジャンプ動作のための信号を駆動回路6に供給し、それに応じた、フォーカスドライブ信号、トラッキングドライブ信号、スレッドドライブ信号を発生させて、光学ヘッド3のフォーカスサーチやトラックジャンプ及びアクセス等を実行させる。
【0053】
フォーカスサーチとは、フォーカスサーボ引込のために対物レンズ15(15A、15B)をディスク1から最も遠い位置と最も近い位置の間を強制的に移動させながらいわゆるS字カーブを検出する動作である。既に知られているようにフォーカスエラー信号FEとしては、対物レンズ15がディスク1の記録層に対して合焦点位置となるポイントの前後の狭い区間においてS字カーブが観測されるものとなり、そのS字カーブのリニア領域でフォーカスサーボをオンとすることで、フォーカスサーボ引込が可能となる。このようなフォーカスサーボ引込のために、フォーカスサーチが行われるものであり、このためのフォーカスドライブ信号がフォーカス用コイルに印加され、対物レンズ15の移動が行われる。
【0054】
またトラックジャンプやアクセスの場合には、2軸機構16(16A、16B)による対物レンズ15のディスク半径方向への移動や、スレッド機構14による光学ヘッド3のディスク半径方向への移動が行われるが、このためのドライブ信号がトラッキングドライブ信号、スレッドドライブ信号としてトラッキング用コイルやスレッド機構14に印加されることになる。
【0055】
RFアンプ4にて生成されたRF信号は、載置されている光ディスク1がCD−DAの場合、もしくはハイブリッドディスクのCDレイヤー101を再生している場合は、エラー訂正及びデコーダ回路7において、2値化してEFM復調(eight to fourteen demodulation )を行うとともにCIRC(cross interleave read solomon coding)によるエラー訂正処理を行った後にメモリコントローラー8に入力される。
一方、上記ターンテーブルに載置されている光ディスク1が単層HDディスク又は複層HDディスクである場合、もしくはハイブリッドディスクのHDレイヤ102を再生している場合は、エラー訂正及びデコーダ回路7において2値化してEFM-Plus復調(eight to fourteen demodulation Plus)を行うとともに積符号(product code)に基づくエラー訂正処理が行なわれ、メモリコントローラ8に供給される。
即ち機能的に見れば、図8のようにエラー訂正及びデコーダ回路7においてはCD用デコード部7AとHD用デコード部7Bが形成される。
なおCD用デコード部7AとHD用デコード部7Bはハードウエア的に独立した回路部としてもよいし、ハードウエア的には共用される回路部とすることもできる。
【0056】
またエラー訂正及びデコーダー回路7では2値化したEFM信号もしくはEFMプラス信号の基準クロックとの比較により速度エラー信号及び位相エラー信号を生成して駆動回路6に供給することで、光ディスク1をスピンドルモーター2により所定CLV速度(又はCAV速度)で回転させる。
更にエラー訂正及びデコーダー回路7では2値化したEFM信号又はEFMプラス信号に基づいてPLL(Phase Locked loop)の引き込み動作を制御し、デコード処理等に用いる再生クロックを得る。
【0057】
エラー訂正後の2値化データは、メモリコントローラ8を介して所定の転送レートでバッファメモリ9に書き込まれる。
バッファメモリ9に所定量以上のデータが蓄積されたらバッファメモリ9から書き込みの転送レートより十分遅い第2の転送レートにて読み出しを行う。
このようにバッファメモリ9に一旦データを蓄えてからオーディオデータとして出力するようにしたので、例えば振動等の外乱によってトラックジャンプが生じて光学ヘッド3からの連続したデータ読み出しが途絶えたとしても、光学ヘッド3のトラックジャンプが発生したアドレスへの再配置に要する時間に相当するデータは予めバッファメモリ9に蓄積されているのでオーディオ出力としては連続したものを得ることができる。
【0058】
尚、メモリコントローラ8はシステムコントローラ11によって制御されている。
メモリコントローラー8によってバッファメモリ9から読み出されたデジタルデータはD/Aコンバーター10にてアナログオーディオ信号に変換される。そして、例えばCDレイヤーに記録されたオーディオデータ、又は、HDレイヤーの2チャンネルステレオエリアに記録されたオーディオデータであれば、右チャンネル出力、左チャンネル出力として出力される。また、HDレイヤーのマルチチャンネルエリアに記録されたオーディオデータであれば、そのマルチチャンネル数によって出力させることができる。
【0059】
またこの再生装置では、HD用ヘッド部3B内のディテクタ18B(CD用と共用される場合はそのディテクタ)からの反射光情報に基づいてRFアンプ4で得られる信号(PI信号、フォーカスエラー信号FE、トラッキングエラー信号TE)のいずれかが判別信号生成部20に供給される。
判別信号生成部20では、入力された信号に基づいて所定の検出動作を行うことで、図2に示したディスクのうち、実際に装填されているディスクの種別に対応するパターンの検出信号を出力する。システムコントローラ11では、この検出信号に基づいて、ディスク1の種別判別を実行する。
なお、ここでのディスク種別判別のための詳細については、省略するが、一例として、さきに本出願により出願された特願平11−247346に記載される技術を適用することができる。
【0060】
システムコントローラ11は全体を制御する部位としてマイクロコンピュータにより形成される。
システムコントローラ11は内部ROM11に保持する動作プログラムやユーザーの操作に応じて再生動作のための所要の制御を行うことになる。
例えば操作部12としての各種の操作キーの操作に応じて各種サーボ用のコマンドをサーボ回路5に転送したり、メモリコントローラ8に対してバッファメモリ9の制御の指令を与えること、エラー訂正・デコーダー回路7でのスピンドルサーボ制御やデコーダ制御を行うことなどで必要な再生動作を実行させる。
また、再生等の動作に応じて表示部13の表示制御を行う。例えば演奏経過時間や再生しているプログラムのタイトル等の文字情報の表示を表示部13に表示するように制御を行なう。
また、システムコントローラ11が処理を実行する過程において必要とされる各種情報はRAM11aに書き込まれて保持される。
【0061】
また、本実施の形態においては、IEEE1394インターフェイス部14を備えることで、IEEE1394バス116を介して接続された機器と相互通信を行うことが可能とされる。
これにより、例えば図6に示したシステムの場合を例に挙げれば、例えばパーソナルコンピュータ200により、ディスクプレーヤ0をリモート制御することが可能となる。つまり、パーソナルコンピュータ200から或る操作を指示するコマンドが送信されてくると、ディスクプレーヤ0のシステムコントローラ11はこのコマンドをIEEE1394インターフェイス部14を介して受信する。そして、受信したコマンドの内容に応じて、内部の所要の機能回路部に対する制御を実行する。これにより、例えばディスク再生を始めとする各種コントロールを、リモート制御によって行うことができる。
【0062】
また、例えば光ディスク1にて再生されたデジタルオーディオデータをIEEE1394バス116を介して送信出力することも可能とされる。
例えば、システムコントローラ11は、バッファメモリ9に蓄積されていデジタルオーディオデータを所定タイミングで読み出して、IEEE1394インターフェイス部14に伝送する。IEEE1394インターフェイス部14では、伝送されてきたデジタルオーディオデータを、例えばパケット化などのIEEE1394デジタルインターフェイスのフォーマットに従った形式に変換し、IEEE1394バス116を介して送信出力する。
【0063】
3−3.パーソナルコンピュータ
続いて、パーソナルコンピュータ200の内部構成について図9を参照して説明する。
この図に示すパーソナルコンピュータ200は、外部とデータの授受を行うためのインターフェイスとしてIEEE1394インターフェイス209を備えている。IEEE1394インターフェイス209は、外部データバスとしてのIEEE1394バス116と接続されることで外部機器と相互通信が可能とされる。
IEEE1394インターフェイス209は、IEEE1394バス116を介して受信したパケットを復調し、復調したパケットに含まれるデータを抽出し、この抽出データを内部データ通信に適合するデータフォーマットにより変換を行って、内部バス210を介してCPU201に出力する。
また、CPU201の制御によって出力されたデータを入力し、パケット化等のIEEE1394フォーマットに従った変調処理を施して、IEEE1394バス116を介して外部に送信出力する。
【0064】
CPU201は、例えばROM202に保持されているプログラムに従って各種の処理を実行する。本実施の形態では、IEEE1394の規格に従って各種データの送受信を可能とするために、上記ROM202に対してIEEE1394インターフェイス209を制御するためのプログラムも格納されることになる。つまり、パーソナルコンピュータ113においては、IEEE1394によるデータ送受信に可能なセット(ハードウェア及びソフトウェア)が備えられるものである。
また、RAM203にはCPU201が各種処理を実行するのに必要なデータやプログラム等が適宜保持される。
【0065】
入出カインターフェイス204は、キーボード205とマウス206が接続されており、これらから供給された操作信号をCPU201に出カするようにされている。また、入出カインターフェイス204には、記憶媒体としてハードディスクを備えたハードディスクドライブ207が接続されている。CPU201は、入出カインターフェイス204を介して、ハードディスクドライブ207のハードディスクに対してデータやプログラム等の記録又は読み出しを行うことができるようにされている。この場合、入出カインターフェイス204には、さらに、画像表示のためのディスプレイモニタ208が接続されている。
内部バス210は、例えば、PCI(Peripheral Component Interconnect)又はローカルバス等により構成され、内部における各機能回路部間を相互に接続している。
【0066】
なお、前述したディスクプレーヤ0としても、IEEE1394インターフェイス機能については、上記したパーソナルコンピュータ113と基本的には同様の構成を採る。システムコントローラ11内に備えられるとされるROM11bに対して、システムコントローラ111によるIEEE1394インターフェイス110の制御を可能とするためのプログラムが搭載される。
【0067】
4.IEEE1394データインターフェイス
4−1.概要
続いて、本実施の形態において採用されるIEEE1394データインターフェイスについて説明する。
【0068】
IEEE1394は、シリアルデータ通信の規格の1つとされる。
このIEEE1394によるデータ伝送方式としては、周期的に通信を行うIsochronous通信方式と、この周期と関係なく非同期で通信するAsynchronous通信方式が存在する。一般に、Isochronous通信方式はデータの送受信に用いられ、Asynchronous通信方式は各種制御コマンドの送受信に用いられる。そして、1本のケーブルを使用して、これら2種類の通信方式によって送受信を行うことが出来るようにされている。
また、このようなIsochronous通信方式とAsynchronous通信方式の使い分け方として、或るメディアに、AVデータ(オーディオデータ、ビデオデータ等)などの時系列的なデータと、静止画やテキストなどの時系列性を有さないとされる補助データが記録されているようなフォーマットを有する場合、AVデータをIsochronous通信により送信し、補助データはAsynchronous通信方式により送信するという構成を、先に本出願人が提案している。この実施の形態においても、上記した提案の構成に従い、ディスクプレーヤ0にて再生されたオーディオデータに関しては、Isochronous通信方式により送信出力を行うものとする。
そこで以降、上記したIEEE1394規格による本実施の形態の送信形態を前提として、本実施の形態としての説明を行っていくこととする。
【0069】
4−2.スタックモデル
図10は、本実施の形態が対応するIEEE1394のスタックモデルを示している。
IEEE1394フォーマットにおいては、Asynchronous系(400)とIsochronous系(500)とに大別される。
ここで、Asynchronous系(400)とIsochronous系(500)に共通な層として、最下位にPhysical Layer(301)(物理層)が設けられ、その上位にLink Layer(302)(リンク層)が設けられる。Physical Layer(301)はハードウェア的な信号伝送を司るためのレイヤであり、Link Layer(302)はIEEE1394バスを例えば、機器毎に規定された内部バスに変換するための機能を有する層とされる。
【0070】
Physical Layer(301)、Link Layer(302)、及び次に説明するTransaction Layer(401)は、Event/Control/ConfigurationのラインによってSerial Bus Management303とリンクされる。
また、AV Cable/Connector304は、AVデータ伝送のための物理的なコネクタ、ケーブルを示している。
【0071】
Asynchronous系(400)における上記Link Layer(302)の上位には、Transaction Layer(401)が設けられる。Transaction Layer(401)は、IEEE1394としてのデータ伝送プロトコルを規定する層とされ、基本的なAsynchronous Transactionとしては、後述するようにして、Write Transaction,Read Transaction,Lock Transactionが規定される。
【0072】
そして、Transaction Layer(401)の上層に対してFCP(Functuin Control Protocol)(402)が規定される。FCP(402)は、AV/C Command(AV/C Digital Interfase Command Set)(403)として規定された制御コマンドを利用することで、各種AV機器に対するコマンド制御を実行することが出来るようになっている。
【0073】
また、Transaction Layer(401)の上層に対しては、Connection Management Procedures(505)を利用して、後述するPlug(IEEE1394における論理的な機器接続関係)を設定するためのPlug Controll Registers(404)が規定される。
【0074】
Isochronous系(500)におけるLink Layer(302)の上位には、CIP Header Format(501)が規定され、このCIP Header Format(501)に管理される形態で、SD−DVCR Realtime Transmission(502),HD−DVCR Realtime Transmission(503),SDL−DVCR Realtime Transmission(504),MPEG2−TS Realtime Transmission(505),Audioand Music Realtime Transmission(506)等の伝送プロトコルが規定されている。
【0075】
SD−DVCR Realtime Transmission(502),HD−DVCR Realtime Transmission(503),SDL−DVCR Realtime Transmission(504)は、それぞれ、デジタルVTR(Video Tape Recorder)に対応するデータ伝送プロトコルである。
SD−DVCR Realtime Transmission(502)が扱うデータは、SD−DVCR recording format(508)の規定に従って得られたデータシーケンス(SD−DVCR data sequence(507))とされる。
また、HD−DVCR Realtime Transmission(503)が扱うデータは、HD−DVCR recording format(510)の規定に従って得られたデータシーケンス(SD−DVCR data sequence(509))とされる。
SDL−DVCR Realtime Transmission(504)が扱うデータは、SDL−DVCR recording format(512)の規定に従って得られるデータシーケンス(SD−DVCR data sequence(511))となる。
【0076】
MPEG2−TS Realtime Transmission(505)は、例えばデジタル衛星放送に対応するチューナ等に対応する伝送プロトコルで、これが扱うデータは、DVB recording format(514)或いはATV recording format(515)の規定に従って得られるデータシーケンス(MPEG2−TS data sequence(513))とされる。
【0077】
また、Audio and Music Realtime Transmission(506)は、例えば本実施の形態のMDシステムを含むデジタルオーディオ機器全般に対応する伝送プロトコルであり、これが扱うデータは、Audio and Music recording format(517)の規定に従って得られるデータシーケンス(Audio and Music data sequence)とされる。
【0078】
4−3.信号伝送形態
図11は、IEEE1394バスとして実際に用いられるケーブルの構造例を示している。
この図においては、コネクタ600Aと600Bがケーブル601を介して接続されていると共に、ここでは、コネクタ600Aと600Bのピン端子として、ピン番号1〜6の6ピンが使用される場合を示している。
コネクタ600A,600Bに設けられる各ピン端子については、ピン番号1は電源(VP)、ピン番号2はグランド(VG)、ピン番号3はTPB1、ピン番号4はTPB2、ピン番号5はTPA1、ピン番号5はTPA2とされている。
そして、コネクタ600A−600B間の各ピンの接続形態は、
ピン番号1(VP)−ピン番号1(VP)
ピン番号2(VG)−ピン番号2(VG)
ピン番号3(TPB1)−ピン番号5(TPA1)
ピン番号4(TPB2)−ピン番号6(TPA2)
ピン番号5(TPA1)−ピン番号3(TPB1)
ピン番号6(TPA2)−ピン番号3(TPB2)
のようになっている。そして、上記ピン接続の組のうち、
ピン番号3(TPB1)−ピン番号5(TPA1)
ピン番号4(TPB2)−ピン番号6(TPA2)
の2本のツイスト線の組により、差動で信号を相互伝送する信号線601Aを形成し、
ピン番号5(TPA1)−ピン番号3(TPB1)
ピン番号6(TPA2)−ピン番号3(TPB2)
の2本のツイスト線の組により、差動で信号を相互伝送する信号線601Bを形成している。
【0079】
上記2組の信号線601A及び信号線601Bにより伝送される信号は、図12(a)に示すデータ信号(Data)と、図12(b)に示すストローブ信号(Strobe)である。
図12(a)に示すデータ信号は、信号線601A又は信号線601Bの一方を使用してTPB1,2から出力され、TPA1,2に入力される。
また、図12(b)に示すストローブ信号は、データ信号と、このデータ信号に同期する伝送クロックとについて所定の論理演算を行うことによって得られる信号であり、実際の伝送クロックよりは低い周波数を有する。このストローブ信号は、信号線601A又は信号線601Bのうち、データ信号伝送に使用していない他方の信号線を使用して、TPA1,2から出力され、TPB1,2に入力される。
【0080】
例えば、図12(a),図12(b)に示すデータ信号及びストローブ信号が、或るIEEE1394対応の機器に対して入力されたとすると、この機器においては、入力されたデータ信号とストローブ信号とについて所定の論理演算を行って、図12(c)に示すような伝送クロック(Clock)を生成し、所要の入力データ信号処理に利用する。
IEEE1394フォーマットでは、このようなハードウェア的データ伝送形態を採ることで、高速な周期の伝送クロックをケーブルによって機器間で伝送する必要をなくし、信号伝送の信頼性を高めるようにしている。
なお、上記説明では6ピンの仕様について説明したが、IEEE1394フォーマットでは電源(VP)とグランド(VG)を省略して、2組のツイスト線である信号線601A及び信号線601Bのみからなる4ピンの仕様も存在する。例えば本実施の形態のディスクプレーヤ0の実際として、上記4ピン仕様のケーブルを用いれば、ユーザにとってより簡易なシステムを提供することができる。
【0081】
4−4.機器間のバス接続
図13は、IEEE1394バスによる機器間接続の形態例を模式的に示している。この図では、機器A,B,C,D,Eの5台の機器(Node)がIEEE1394バス(即ちケーブルである)によって相互通信可能に接続されている場合が示されている。
IEEE1394インターフェイスでは、機器A,B,CのようにしてIEEE1394バスにより直列的に接続するいわゆる「ディージチェーン接続」が可能とされる。また、図13の場合であれば、機器Aと、機器B,D,E間の接続形態に示すように、或る機器と複数機器とが並列的に接続されるいわゆる「ブランチ接続」も可能とされる。
システム全体としては、このブランチ接続と上記ディージチェーン接続とを併用して最大63台の機器(Node)を接続可能とされる。但し、ディージチェーン接続によっては、最大で16台(16ポップ)までの接続が可能とされている。また、SCSIで必要とされるターミネータはIEEE1394インターフェイスでは不要である。
そしてIEEE1394インターフェイスでは、上記のようにしてディージチェーン接続又はブランチ接続により接続された機器間で相互通信を行うことが可能とされている。つまり、図13の場合であれば、機器A,B,C,D,E間の任意の複数機器間での相互通信が可能とされる。
【0082】
また、IEEE1394バスにより複数の機器接続を行ったシステム(以降はIEEE1394システムともいう)内では、機器ごとに割与えられるNodeIDを設定する処理が実際には行われる。この処理を、図14により模式的に示す。
ここで、図14(a)に示す接続形態によるIEEE1394システムにおいて、ケーブルの抜き差し、システムにおける或る機器の電源のオン/オフ、PHY(Physical Layer Protocol)での自発発生処理等が有ったとすると、IEEE1394システム内においてはバスリセットが発生する。これにより、各機器A,B,C,D,E間においてIEEE1394バスを介して全ての機器にバスリセット通知を行う処理が実行される。
【0083】
このバスリセット通知の結果、図14(b)に示すようにして、通信(Child−Notify)を行うことで隣接する機器端子間で親子関係が定義される。つまり、IEEE1394システム内における機器間のTree構造を構築する。そして、このTree構造の構築結果に従って、ルートとしての機器が定義される。ルートとは、全ての端子が子(Ch;Child)として定義された機器であり、図14(b)の場合であれば、機器Bがルートとして定義されていることになる。逆に言えば、例えばこのルートとしての機器Bと接続される機器Aの端子は親親(P;Parent)として定義されているものである。
【0084】
上記のようにしてIEEE1394システム内のTree構造及びルートが定義されると、続いては、図14(c)に示すようにして、各機器から、自己のNode−IDの宣言としてSelf−IDパケットが出力される。そしてルートがこのNode−IDに対して順次承認(grant)を行っていくことにより、IEEE1394システム内における各機器のアドレス、つまりNode−IDが決定される。
【0085】
4−5.パケット
IEEE1394フォーマットでは、図15に示すようにしてIsochronous cycle(nominal cycle)の周期を繰り返すことによって送信を行う。この場合、1Isochronous cycleは、125μsecとされ、帯域としては100MHzに相当する。なお、Isochronous cycleの周期としては125μsec以外とされても良いことが規定されている。そして、このIsochronous cycleごとに、データをパケット化して送信する。
【0086】
この図に示すように、Isochronous cycleの先頭には、1Isochronous cycleの開始を示すCycle Start Packetが配置される。
このCycle Start Packetは、ここでの詳しい説明は省略するが、Cycle Masterとして定義されたIEEE1394システム内の特定の1機器によってその発生タイミングが指示される。
Cycle Start Packetに続いては、IsochronousPacketが優先的に配置される。Isochronous Packetは、図のように、チャンネルごとにパケット化されたうえで時分割的に配列されて転送される(Isochronous subactions)。また、Isochronous subactions内においてパケット毎の区切りには、Isochronous gapといわれる休止区間(例えば0.05μsec)が設けられる。
このように、IEEE1394システムでは、1つの伝送線路によってIsochronousデータをマルチチャンネルで送受信することが可能とされている。
【0087】
ここで、例えば或るメディアに対応したフォーマットのAVデータをIsochronous方式により送信することを考えた場合、このAVデータの1倍速の転送レートが1.4Mbpsであるとすれば、125μsecである1Isochronous cycle周期ごとに、少なくともほぼ20数MバイトのAVデータをIsochronous Packetとして伝送すれば、時系列的な連続性(リアルタイム性)が確保されることになる。
例えば、或る機器が上記したようなAVデータを送信する際には、ここでの詳しい説明は省略するが、IEEE1394システム内のIRM(Isochronous Resource Manager)に対して、AVデータのリアルタイム送信が確保できるだけの、Isochronous パケットのサイズを要求する。IRMでは、現在のデータ伝送状況を監視して許可/不許可を与え、許可が与えられれば、指定されたチャンネルによって、AVデータをIsochronous Packetにパケット化して送信することが出来る。これがIEEE1394インターフェイスにおける帯域予約といわれるものである。
【0088】
Isochronous cycleの帯域内においてIsochronous subactionsが使用していない残る帯域を用いて、Asynchronous subactions、即ちAsynchronousのパケット送信が行われる。
図15では、Packet A,Packet Bの2つのAsynchronous Packetが送信されている例が示されている。Asynchronous Packetの後には、ack gap(0.05μsec)の休止期間を挟んで、ACK(Acknowledge)といわれる信号が付随する。ACKは、後述するようにして、Asynchronous Transactionの過程において、何らかのAsynchronousデータの受信が有ったことを送信側(Controller)に知らせるためにハードウェア的に受信側(Target)から出力される信号である。
また、Asynchronous Packet及びこれに続くACKからなるデータ伝送単位の前後には、10μsec程度のsubaction gapといわれる休止期間が設けられる。
【0089】
4−6.トランザクションルール
図16(a)の処理遷移図には、Asynchronous通信における基本的な通信規則(トランザクションルール)が示されている。このトランザクションルールは、FCPによって規定される。
図16(a)に示すように、先ずステップS11により、Requester(送信側)は、Responder(受信側)に対してRequestを送信する。Responderでは、このRequestを受信する(ステップS12)と、先ずAcknowledgeをRequesterに返送する(ステップS13)。送信側では、Acknowledgeを受信することで、Requestが受信側にて受信されたことを認知する(ステップS14)。
この後、Responderは先のステップS12にて受信したRequestに対する応答として、ResponseをRequesterに送信する(ステップS15)。Requesterでは、Responseを受信し(ステップS16)、これに応答してResponderに対してAcknowledgeを送信する(ステップS17)。ResponderではAcknowledgeを受信することで、Responseが送信側にて受信されたことを認知する。
【0090】
上記図16(a)により送信されるRequest Transactionとしては、図16(b)の左側に示すように、Write Request、Read Request、Lock Requestの3種類に大別して定義されている。
Write Requestは、データ書き込みを要求するコマンドであり、Read Requestはデータの読み出しを要求するコマンドである。Lock Requestはここでは詳しい説明は省略するが、swap compare、マスクなどのためのコマンドである。
【0091】
また、Write Requestは、後に図示して説明するAsynchronous Packet(AV/C Command Packet)に格納するコマンド(operand)のデータサイズに応じてさらに3種類が定義される。Write Request(data quadlet)は、Asynchronous Packetのヘッダサイズのみによりコマンドを送信する。Write Request(data block:data length=4byte)、Write Request(data block:data length≠4byte)は、Asynchronous Packetとしてヘッダに対してdata blockを付加してコマンド送信を行うもので、両者は、data blockに格納されるoperandのデータサイズが4バイトであるかそれ以上であるのかが異なる。
【0092】
Read Requestも同様にして、Asynchronous Packetに格納するoperandのデータサイズに応じて、Read Request(data quadlet)、Read Request(data block:data length=4byte)、Read Request(data block:data length≠4byte)の3種類が定義されている。
【0093】
また、Response Transactionとしては、図16(b)の右側に示されている。
上述した3種のWrite Requestに対しては、Write Response或いはNo Responseが定義される。
また、Read Request(data quadlet)に対してはRead Response(data quadlet)が定義され、ReadRequest(data block:data length=4byte)、又はRead Request(data block:data length≠4byte)に対しては、Read Response(data block)が定義される。
【0094】
Lock Requestに対しては、Lock Responseが定義される。
【0095】
4−7.アドレッシング
図17は、IEEE1394バスのアドレッシングの構造を示している。
図17(a)に示すように、IEEE1394フォーマットでは、バスアドレスのレジスタ(アドレス空間)として64ビットが用意される。
このレジスタの上位10ビットの領域は、IEEE1394バスを識別するためのバスIDを示し、図17(b)に示すようにしてバスIDとしてbus#0〜#1022の計1023のバスIDを設定可能としている。bus#1023はlocal busとして定義されている。
【0096】
図17(a)においてバスアドレスに続く6ビットの領域は、上記バスIDにより示されるIEEE1394バスごとに接続されている機器のNode IDを示す。Node IDは、図17(c)に示すようにして、Node #0〜#62までの63のNode IDを識別可能としている。
上記バスID及びNode IDを示す計16ビットの領域は、後述するAV/C Command PacketのヘッダにおけるdestinationIDに相当するもので、このバスID及びNode IDによって、或るバスに接続された機器がIEEE1394システム上で特定される。
【0097】
図17(a)においてNode IDに続く20ビットの領域は、register spaceであり、このregister spaceに続く28ビットの領域は、register addresである。
register spaceの値は[F FF FFh]とされて、図17(d)に示すregisterを示し、このregisterの内容は、図17(e)に示すようにして定義される。register addresは、図17(e)に示すレジスタのアドレスを指定している。
【0098】
簡単に説明すると、図17(e)のレジスタにおいて、例えばアドレス512[0 00 02 00h]から始まるSerial Bus−depandent Registersを参照することで、Isochronous cycleのサイクルタイムや、空きチャンネルの情報が得られる。
また、アドレス1024[0 00 04 00h]から始まるConfiguration ROMの内容を参照すれば、Nodeの機種から、その機種に付されているNode Unique IDなども識別することができる。
【0099】
4−8.CIP
図18は、CIP(Common Isochronos Packet)の構造を示している。つまり、図15に示したIsochronous Packetのデータ構造である。
前に述べたように、一般にはリアルタイム性が要求されるAVデータは、IEEE1394通信においては、Isochronous通信によりデータの送受信が行われる。つまり、リアルタイム性が維持されるだけのデータ量をこのIsochronous Packetに格納して、1Isochronous cycle毎に順次送信するものである。
【0100】
CIPの先頭32ビット(1quadlet)は、1394パケットヘッダとされている。
1394パケットヘッダにおいて上位から順に16ビットの領域は、data_Length、続く2ビットの領域はtag、続く6ビットの領域はchannel、続く4ビットはtcode、続く4ビットは、syとされている。
そして、1394パケットヘッダに続く1quadletの領域はheader_CRCが格納される。
【0101】
header_CRCに続く2quadletの領域がCIPヘッダとなる。CIPヘッダの上位quadletの上位2バイトには、それぞれ‘0’‘0’が格納され、続く6ビットの領域はSID(送信ノード番号)を示す。SIDに続く8ビットの領域はDBS(データブロックサイズ)であり、データブロックのサイズ(パケット化の単位データ量)が示される。続いては、FN(2ビット)、QPC(3ビット)の領域が設定されており、FNにはパケット化する際に分割した数が示され、QPCには分割するために追加したquadlet数が示される。
SPH(1ビット)にはソースパケットのヘッダのフラグが示され、DBCにはパケットの欠落を検出するカウンタの値が格納される。
【0102】
CIPヘッダの下位quadletの上位2バイトにはそれぞれ‘0’‘0’が格納される。そして、これに続いてFMT(6ビット)、FDF(24ビット)の領域が設けられる。FMTには信号フォーマット(伝送フォーマット)が示され、ここに示される値によって、当該CIPに格納されるデータ種類(データフォーマット)が識別可能となる。具体的には、MPEGストリームデータ、Audioストリームデータ、デジタルビデオカメラ(DV)ストリームデータ等の識別が可能になる。このFMTにより示されるデータフォーマットは、例えば図10に示した、CIP Header Format(401)に管理される、SD−DVCR Realtime Transmission(502),HD−DVCR Realtime Transmission(503),SDL−DVCR Realtime Transmission(504),MPEG2−TS Realtime Transmission(505),Audio and Music Realtime Transmission(506)等の伝送プロトコルに対応する。
FDFは、フォーマット依存フィールドであり、上記FMTにより分類されたデータフォーマットについて更に細分化した分類を示す領域とされる。オーディオに関するデータで有れば、例えばリニアオーディオデータであるのか、MIDIデータであるのかといった識別が可能になる。
例えば本実施の形態のディスクプレーヤにより再生可能なCD−DAデータであれば、先ずFMTによりAudioストリームデータの範疇にあるデータであることが示され、FDFに規定に従った特定の値が格納されることで、そのAudioストリームデータはCD−DAデータであることが示される。
【0103】
ここで、例えばFMTによりMPEGであることが示されている場合、FDFにはTSF(タイムシフトフラグ)といわれる同期制御情報が格納される。また、FMTによりDVCR(デジタルビデオカメラ)であることが示されている場合、FDFは、図18の下に示すように定義される。ここでは、上位から順に、50/60(1ビット)により1秒間のフィールド数を規定し、STYPE(5ビット)によりビデオのフォーマットがSDとHDの何れとされてるのかが示され、SYTによりフレーム同期用のタイムスタンプが示される。
【0104】
上記CIPヘッダに続けては、FMT,FDFによって示されるデータが、n個のデータブロックのシーケンスによって格納される。FMT,FDFによりCD−DAデータであることが示される場合には、このデータブロックとしての領域にCD−DAデータが格納される。
そして、データブロックに続けては、最後にdata_CRCが配置される。
【0105】
4−9.コネクションマネージメント
IEEE1394フォーマットにおいては、「プラグ」といわれる論理的接続概念によって、IEEE1394バスによって接続された機器間の接続関係が規定される。
図19は、プラグにより規定された接続関係例を示しており、この場合には、IEEE1394バスを介して、VTR1、VTR2、セットトップボックス(STB;デジタル衛星放送チューナ)、モニタ装置(Monitor)、及びデジタルスチルカメラ(Camera)が接続されているシステム形態が示されている。
【0106】
ここで、IEEE1394のプラグによる接続形態としては、point to point−connectionと、broadcast connectionとの2つの形態が存在する。
point to point−connectionは、送信機器と受信機器との関係が特定され、かつ、特定のチャンネルを使用して送信機器と受信機器との間でデータ伝送が行われる接続形態である。
これに対して、broadcast connectionは、送信機器においては、特に受信機器及び使用チャンネルを特定せずに送信を行うものである。受信機側では、特に送信機器を識別することなく受信を行い、必要が有れば、送信されたデータの内容に応じた所要の処理を行う。
図19の場合であれば、point to point−connectionとして、STBが送信、VTR1が受信とされてチャンネル#1を使用してデータの伝送が行われるように設定されている状態と、デジタルスチルカメラが送信、VTR2が受信とされてチャンネル#2を使用してデータの伝送が行われるように設定されている状態とが示されている。
また、デジタルスチルカメラからは、broadcast connectionによってもデータ送信を行うように設定されている状態が示されており、ここでは、このbroadcast connectionによって送信したデータを、モニタ装置が受信して所要の応答処理を行う場合が示される。
【0107】
上記のような接続形態(プラグ)は、各機器におけるアドレス空間に設けられるPCR(Plug Contorol Register)によって確立される。
図20(a)は、oPCR[n](出力用プラグコントロールレジスタ)の構造を示し、図20(b)は、iPCR[n](入力用プラグコントロールレジスタ)の構造を示している。これらoPCR[n]、iPCR[n]のサイズは共に32ビットとされている。
図20(a)のoPCRにおいては、例えば上位1ビットのon−lineに対して‘1’が格納されていると、broadcast connectionによる送信であることが示され、‘0’が格納されていると、上位11ビット目から6ビットの領域のchannel numberで示されるチャンネルにより、point to point connectionで送信することが示される。
また、図20(b)のiPCRにおいても、例えば上位1ビットのon−lineに対して‘1’が格納されていれば、broadcast connectionによる受信であることが示され、‘0’が格納されていると、上位11ビット目から6ビットの領域のchannel numberで示されるチャンネルにより送信されたデータをpoint to point connectionで送信することが示される。
【0108】
4−10.FCPにおけるコマンド及びレスポンス
本実施の形態のIEEE1394フォーマットでは、各種コマンドは、Asynchronous通信によりデータの送受信が行われる。ここでは、FCPにより規定されるトランザクションについて説明する。
【0109】
FCPとしては、Asynchronous通信において規定されるWrite Transaction(図16参照)を使用する。
FCPをサポートする機器は、Command/Responceレジスタを備え、次に図21により説明するようにしてCommand/Responceレジスタに対してMessageを書き込むことでトランザクションを実現する。
【0110】
図21の処理遷移図においては、先ずCOMMAND送信のための処理として、ステップS21として示すように、ControllerがTransaction Requestを発生して、Write Request PacketをTargetに対して送信する処理を実行する。Targetでは、ステップS22として、このWrite Request Packetを受信して、Command/Responceレジスタに対してデータの書き込みを行う。また、この際、TargetからはControllerに対してAcknowledgを送信し、Controllerでは、このAcknowledgを受信する(S23→S24)。ここまでの一連の処理が、COMMANDの送信に対応する処理となる。
【0111】
続いては、COMMANDに応答した、RESPONCEのための処理として、TargetからWrite Request Packetが送信される(S25)。Controllerではこれを受信して、Command/Responceレジスタに対してデータの書き込みを行う(S26)。また、Controllerでは、Write Request Packetの受信に応じて、Targetに対してAcknowledgを送信する(S27)。Targetでは、このAcknowledgを受信することで、Write Request PacketがControllerにて受信されたことを知る(S28)。
つまり、ControllerからTarget対するCOMMAND伝送処理と、これに応答したTargetからControllerに対するRESPONCE伝送処理が、FCPによるデータ伝送(Transaction)の基本となる。
【0112】
4−11.AV/Cコマンドパケット
図10により説明したように、Asynchronous通信において、FCPは、AV/Cコマンドを用いて各種AV機器に対する通信を行うことができるようにされている。
Asynchronous通信では、Write,Read,Lockの3種のトランザクションが規定されているのは、図16にて説明した通りであり、実際には各トランザクションに応じたWrite Request/Responce Packet,Read Request/Responce Packet,Lock Request/Responce Packetが用いられる。そして、FCPでは、上述したようにWrite Transactionを使用するものである。
そこで図22に、Write Request Packet(Asynchronous Packet(Write Request for Data Block))のフォーマットを示す。本実施の形態では、このWrite Request Packetが即ち、AV/Cコマンドパケットとして使用される。
【0113】
このWrite Request Packetにおける上位5quadlet(第1〜第5quadlet)は、packet headerとされる。
packet headerの第1quadletにおける上位16ビットの領域はdestination_IDで、データの転送先(宛先)のNode IDを示す。続く6ビットの領域はtl(transact label)であり、パケット番号を示す。続く2ビットはrt(retry code)であり、当該パケットが初めて伝送されたパケットであるか、再送されたパケット示す。続く4ビットの領域はtcode(transaction code)は、指令コードを示している。そして、続く4ビットの領域はpri(priority)であり、パケットの優先順位を示す。
【0114】
第2quadletにおける上位16ビットの領域はsource_IDであり、データの転送元のNode_ID が示される。
また、第2quadletにおける下位16ビットと第3quadlet全体の計48ビットはdestination_offsetとされ、COMMANDレジスタ(FCP_COMMAND register)とRESPONCEレジスタ(FCP_RESPONCE register)のアドレスが示されれる。
上記destination_ID及びdestination_offsetが、IEEE1394フォーマットにおいて規定される64ビットのアドレス空間に相当する。
【0115】
第4quadletの上位16ビットの領域は、data_lengthとされ、後述するdatafield(図22において太線により囲まれる領域)のデータサイズが示される。
続く下位16ビットの領域は、extended_tcodeの領域とされ、tcodeを拡張する場合に使用される領域である。
【0116】
第5quadletとしての32ビットの領域は、header_CRCであり、Packet headerのチェックサムを行うCRC計算値が格納される。
【0117】
Packet headerに続く第6quadletからdata blockが配置され、このdata block内の先頭に対してdatafieldが形成される。
datafieldとして先頭となる第6quadletの上位4バイトには、CTS(Command and Transaction Set)が記述される。これは、当該Write Request PacketのコマンドセットのIDを示すもので、例えば、このCTSの値について、図のように[0000]と設定すれば、datafieldに記述されている内容がAV/Cコマンドであると定義されることになる。つまり、このWrite Request Packetは、AV/Cコマンドパケットであることが示されるものである。従って、本実施の形態においては、FCPがAV/Cコマンドを使用するため、このCTSには[0000]が記述されることになる。
【0118】
CTSに続く4ビットの領域は、ctype(Command type;コマンドの機能分類)、又はコマンドに応じた処理結果(レスポンス)を示すresponseが記述される。
【0119】
図23に、上記ctype及びresponseの定義内容を示す。
ctype(Command)としては、[0000]〜[0111]を使用できるものとしており、[0000]はCONTROL、[0001]はSTATUS、[0010]はINQUIRY、[0011]はNOTIFYとして定義され、[0100]〜0111は、現状、未定義(reserved)とされている。
CONTROLは機能を外部から制御するコマンドであり、STATUSは外部から状態を間い合わせるコマンド、INQUIRYは、制御コマンドのサポートの有無を外部から問い合わせるコマンド、NOTIFYは状態の変化を外部に知らせることを要求するコマンドである。
また、responseとしては、[1000]〜[1111]を使用するものとしており、[1000]はNOT IMPLEMENTED、[1001]はACCEPTED、[1010]はREJECTED、[1011]はIN TRANSITION、[1100]はIMPLEMENTED/STABLE、[1101]はCHANGED、[1110]はreserved、[1111]はINTERIMとしてそれぞれ定義されている。
これらのresponseは、コマンドの種類に応じて使い分けられる。例えば、CONTOROLのコマンドに対応するresponseとしては、NOTIMPLEMENTED、ACCEPTED、REJECTED、或いはINTERIMの4つのうちの何れかがResponder側の状況等に応じて使い分けられる。
【0120】
図22において、ctype/responseに続く5ビットの領域には、subunit−typeが格納される。は、subunit−typeは、COMMMANDの宛先またはRESPONCEの送信元のsubunitが何であるのか(機器)を示す。IEEE1394フォーマットでは、機器そのものをunitと称し、そのunit(機器)内において備えられる機能的機器単位の種類をsubunitと称する。例えば一般のVTRを例に採れば、VTRとしてのunitは、地上波や衛星放送を受信するチューナと、ビデオカセットレコーダ/プレーヤとの、2つのsubunitを備える。
subunit−typeとしては、例えば図24(a)に示すように定義されている。つまり、[00000]はMonitor、[00001]〜[00010]はreserved、[00011]はDisc recorder/player、[00100]はVCR、[00101]はTuner、[00111]はCamera、[01000]〜[11110]はreserved、[11111]は、subunitが存在しない場合に用いられるunitとして定義されている。
【0121】
図22において、上記subunit−typeに続く3ビットには、同―種類のsubunitが複数存在する場合に、各subunitを特定するためのid(Node_ID)が格納される。
【0122】
上記id(Node_ID)に続く8ビットの領域には、opcodeが格納され、続く8ビットの領域には、operandが格納される。
opcodeとは、オぺレーションコード(Operation Code)のことであって、operandには、opcodeが必要とする情報(パラメータ)が格納される。これらopcodeはsubunitごとに定義され、subunitごとに固有のopcodeのリストのテーブルを有する。例えば、subunitがVCRであれば、opcodeとしては、例えば図24(b)に示すようにして、PLAY(再生),RECORD(記録)などをはじめとする各種コマンドが定義されている。operandは、opcode毎に定義される。
【0123】
図22におけるdatafieldとしては、上記第6quadletの32ビットが必須とされるが、必要が有れば、これに続けて、operandを追加することが出来る(Additional operands)。
datafieldに続けては、data_CRCが配置される。なお、必要が有れば、data_CRCの前にpaddingを配置することが可能である。
【0124】
4−12.プラグ
ここで、IEEE1394フォーマットにおけるプラグについて概略的に説明する。ここでいうプラグとは、先に図20によっても説明したように、IEEE1394フォーマットにおける機器間の論理的接続関係をいうものである。
【0125】
図25に示すように、Asynchronous通信において有効とされるコマンド等のデータ(request)は、producerからconsumerに対して伝送される。ここでいうproducer及びconsumerは、それぞれIEEE1394インターフェイス上で送信機器、受信機器として機能する機器をいうものである。そして、consumerにおいては、図に斜線で示すように、producerによりデータ書き込みが行われるセグメントバッファ(Segment Buffer)を備える。
また、IEEE1394システムにおいて、特定の機器をproducer、consumerとして規定するための情報(Connection Management Information)は、図に網線で示すプラグアドレス内の所定位置に格納されている。セグメントバッファは、プラグアドレスに続いて配置される。
consumerのセグメントバッファに対して書き込み可能なアドレス範囲(データ量)は、後述するようにしてconsumer側で管理するlimit
Count registerによって規定される。
【0126】
図26は、Asynchronous通信におけるプラグのアドレス空間の構造を示している。
64ビットから成るプラグのアドレス空間は、図26(a)に示すようにして、2の16乗(64K)のNodeに分割される。そして、プラグは、図26(b)に示すようにして、各Nodeのアドレス空間内に在るようにされる。そして、各プラグは、図26(c)に示すように、網線の領域により示すレジスタ(register)と、斜線の領域により示すセグメントバッファ(Segment Buffer)とを含んで形成される。レジスタには、次に説明するようにして、送信側(producer)と受信側(consumer)との間におけるデータの授受管理に必要な情報(例えば、送信データサイズ及び受信可能データサイズ)が格納される。セグメントバッファは、producerからconsumerに対して送信されたデータが書き込まれるべき領域であり、例えば最小で64バイトであることが規定されている。
【0127】
図27(a)にはプラグアドレスが示されている。つまり、上記図26(c)と同一内容が示されている。
この図に示すように、レジスタはプラグアドレスの先頭に対して配置され、これに続けてセグメントバッファが配置される。
そして、レジスタ内の構造としては、図27(b)に示すようにして、先頭に対して、例えば32ビットのproducer Count registerが配置され、続けて、各32ビットのlimit Count register[1]〜[14]が配置される。つまり、1つのproducer Count registerと14のlimit Count registerが設けられる。なお、ここでは、limit Count register[14]の後ろに未使用(unused)の領域が設けられている。
【0128】
上記図27(a)(b)に示すプラグ構造は、図27(c)に示すようにして、オフセットアドレス(Address Offset)によって指定される。
つまり、オフセットアドレス0は、consumer port(producer Count register)を指定し、オフセットアドレス4,8,12・・・56,60は、それぞれproducer port[1]〜[14]を指定する。オフセットアドレス60はreservedとして定義されることで、未使用(unused)の領域を示し、オフセットアドレス64によりセグメントバッファを示す。
【0129】
図28には、producer側とconsumer側との両者のプラグ構造が示されている。
Asynchronous通信のプラグ構造においては、producer Count registerへの書き込み、limit Count registerへの書き込み、及びセグメントバッファへの書き込みを後述する送受信手順に従って行うことで、Asynchronous通信を実現する。これらの書き込みは、先に説明したWrite Transactionとしての処理である。
【0130】
producer Count registerは、producerによってconsumerに対して書き込みが行われる。
producerは、自身のアドレスに在るproducer Count registerにproducer側のデータ伝送に関する情報を書き込んだ上で、このproducer Count registerの内容を、consumerのproducer Count registerに対して書き込む。
producer Count registerは、producerがconsumerのセグメントバッファに対して書き込むデータサイズとして、1回の書き込み処理によって書き込むデータサイズの情報とされる。つまり、producerが、producer Count registerの書き込みを行うことによって、consumerのセグメントバッファに書き込むデータサイズを知らせる処理が行われる。
【0131】
これに対して、limit Count registerは、consumerによってproducerに対して書き込みが行われる。
consumer側では、自身のlimit Count register[1]〜[14]のうち、producerに対応して指定された1つのlimit Count register[n]に対して、自身のセグメントバッファの容量(サイズ)を書き込み、このlimit Count register[n]の内容を、limit Count register[n]に対して書き込む。
【0132】
producer側では、上記のようにしてlimit Count register[n]に書き込まれた内容に応じて、1回あたりの書き込みデータ量を決定して、例えば自身のセグメントバッファに対して書き込みを行う。そして、このセグメントバッファに書き込んだ内容を、consumerに対して書き込むようにされる。このセグメントバッファへの書き込みが、Asynchronous通信におけるデータ送信に相当する。
【0133】
4−13.Asynchronous Connection送信手順
続いて、上記図28により説明したプラグ(producer−consumer)間の構造を前提として、図29の処理遷移図により、Asynchronous connectionの基本的な送受信手順について説明する。
図29に示す送受信処理の手順は、Asynchronous通信として、FCPによって規定された環境のもとで、AV/Cコマンド(Write Request Packet)を使用して行われる。
なお、Asynchronous connectionの実際においては、コマンド送信に応じて、図21に示したように、Acknowledgの送受信が実行されるのであるが、図29においてはAcknowledgについての送受信処理の図示は省略している。
【0134】
また、IEEE1394インターフェイスでは、プラグ(機器)間の接続関係として、上記したproducer−consumerの関係の他に、controller−targetとして規定される関係が存在する。IEEE1394システム上においては、producer−consumerの関係が規定された機器と、controller−targetの関係が機器とが必ずしも一致するものではない。つまり、producerとして規定された機器の他に、controllerの機能を有するものとして規定された機器が存在する場合がある。但し、ここでは、producer−consumerとしての関係と、controller−targetとしての関係が一致している場合を例に説明する。
【0135】
図29に示す送信手順としては、先ず、ステップS101として示すように、producerからconsumerに対して、Connect要求を送信する。このConnect要求は、producerがconsumerに対して、接続要求を行うためのコマンドで、producerのレジスタのアドレスをconsumerに対して伝える。
このConnect要求は、ステップS102の処理としてconsumerが受信することで、consumer側では、producerのレジスタのアドレスを認識する。そして、ステップS103により、responceとして、consumerは、producerに対してConnect受付を送信する。そして、ステップS104において、producerがこれを受信することで、以降のデータ送受信のためのproducer−consumer間の接続(connection)が確立される。
【0136】
上記のようにしてconnectionが確立されると、ステップS105により、consumerは、producerに対してlimit Countregister((以降、単に「limit Count」と略す))の書込要求を行う。ステップS106によりこれを受信したproducerは、続くステップS107の処理によって、limit Count書込受付を、consumerに対して送信する。そして、ステップS108の処理として、consumerがlimit Count書込受付を受信する。このlimit Count書込要求/書込受付の一連の処理によって、以降における、セグメントバッファへのデータ書き込みサイズ(セグメントバッファ容量)が決定される。
【0137】
続くステップS109においては、producerからconsumerに対して、セグメントバッファ書込要求を送信する。そして、ステップS110によってセグメントバッファ書込要求が受信され、これに応答して、ステップS111の処理として、consumerからproducerに対して、セグメントバッファ書込受付を送信する。producerは、ステップS112により、セグメントバッファ書込受付を受信する。
このステップS109〜S112までの処理が実行されることで、1回のproducerのセグメントバッファからconsumerのセグメントバッファに対してデータへの書き込み処理が完了する。
ここで、上記ステップS109〜S112の処理によって書き込まれるデータは、図15に示したAsynchronous Packetによる1回の送信により書き込まれる。従って、Asynchronous Packetにより転送されるデータサイズが、上記limit Countによって指定されたデータサイズよりも小さく、かつ、1回のAsynchronous Packetによる送信によっては、必要なデータ送信が完了しない場合には、セグメントバッファの容量がフルとなる範囲で、ステップS109〜S112の処理が繰り返されるようになっている。
【0138】
そして、上記したステップS109〜S112に示すセグメントバッファへの書き込み処理が完了すると、ステップS113の処理として示すように、producerからconsumerに対して、producer Count register(以降、単にproducer Countと略す)書込要求を送信する。そしてconsumerでは、ステップS114の処理として、producer Countを受信して、自身のproducer Count registerに書き込みを行い、続くステップS115の処理として、producer Count書込受付をproducerに対して送信する。producerはステップS116により、このproducer Count書込受付を受信する。
この処理によって、先のステップS109〜S112の処理として、producerからconsumerのセグメントバッファに対して転送したデータサイズがconsumerに対して知らされることになる。
【0139】
続くステップS117の処理としては、上記ステップS113〜S116に示したproducer Count書き込み処理に応答しての、limit Count書き込みのための一連の処理が実行される。つまり、ステップS117〜S120に示すようにして、consumerからproducerへのlimit Count書込要求の送信と、この送信に応答してのproducerからconsumerへのlimit Count書込受付の送信が行われる。
【0140】
上記ステップS109〜S120までの処理が、Asynchronous Connectionにおけるデータ伝送処理としての1セットの手順を成す。ここで、例えば送信すべきデータサイズが、セグメントバッファ容量よりも大きく、1回のステップS109〜S120までの処理によっては、データの転送が完了していないとされる場合には、このステップS109〜S120までの処理を、データの転送が完了するまで繰り返し実行することが出来るようになっている。
【0141】
そして、データの転送が完了したら、ステップS121に示すようにして、producerはconsumerに対して、Disconnect要求を送信する。consumerはステップS122において、このDisconnect要求を受信し、続くステップS123によりDisconnect受付を送信する。ステップS124において、producerがDisconnect受付を受信することで、Asynchronous Connectionによるデータ送受信が完結する。
【0142】
5.本実施の形態のSubunit Identifier Descriptor
5−1.基本概念
これまでの説明から分かるように、本実施の形態のディスクプレーヤ0は、IEEE1394バスを介して例えばパーソナルコンピュータなどの他の機器と接続することが可能とされている。
そして、このようなオーディオ機器がIEEE1394バスを介して接続を行って、各種機能を実現するためには、そのオーディオ機器に装填されているメディアに記録されているデータを管理するための管理情報として、IEEE1394インターフェイス上で認識可能な形式による管理情報を構築することが必要であるとされている。
【0143】
前述したように、例えばディスクプレーヤ0のシステムにあっては、記録データを管理する情報としてTOC情報(CDレイヤーにあってはCD−TOC,HDレイヤーにあってはマスターTOC,エリアTOC(Area TOC-1,Area TOC-2))が存在し、これがディスクに記録されているのであるが、これらTOC情報は、あくまでもディスクプレーヤのシステム内で完結する情報であり、そのままIEEE1394インターフェイスに適合するものではない。
そこで、本実施の形態のディスクプレーヤ0においては、ディスクに記録されたTOC情報を利用して、IEEE1394フォーマットに適合する形式による管理情報を別途作成して保持するようにされる。これが、IEEE1394データインターフェイス下でのAV/Cプロトコルにて規定される「Subunit Identifier Descriptor」といわれるものである。
【0144】
また、この場合には、その対象がディスクであることから、Subunit_typeとしては、Disc recorder/Playerとされることになる。このDisc recorder/PlayerのSubunit_typeに対応して作成されるSubunit Identifier Descriptorは、「Disc Subunit Identifier Descriptor」であるものとされている。そこで以降、本実施の形態のディスクプレーヤ0が有するべき「Disc Subunit Identifier Descriptor」について説明していくこととする。
【0145】
ここで先ず、図30により、Subunit Identifier Descriptorの基本概念について述べておく。
Subunit Identifier Descriptorは、そのSubunitの各種属性の情報が格納したデータ構造とみることができる。そして、その構造としては階層構造を有するものとされている。
図30(a)に示すブロックは、Subunit Identifier Descriptorにおける最も上の階層として見える構造を示している。つまり、階層構造において定義されるルート(root)に対応する。Subunit Identifier Descriptorは、1以上のオブジェクトにより形成されるが、そのオブジェクトとして、例えばここでは、List0〜List n-1として示される、List_IDが格納される。このList0〜List n-1のList_IDの各々によって、更にそのディレクトリ下にあるオブジェクトであるListの情報が指定される。つまり、List0のList_IDによっては、図30(b)に示すList0のオブジェクトが指定され、List n-1のList_IDによっては、図30(c)に示すList n-1のオブジェクトが指定される。
また、図30(b)のList0のオブジェクトもまた、各Listもまた、親(Parent)のディレクトリが子(Child)のディレクトリを示すようにして階層構造を有するようにされている。このようにして、ルートディレクトリから次々に子のディレクトリを参照してたどっていくことで、目的のオブジェクトに到達するまで階層を降りていくことができる。また逆に或る階層化のオブジェクトから親ディレクトリを参照してたどっていくことで、ルートディレクトリまで階層を上っていくことができる。
【0146】
5−2.Subunit Identifier Descriptor
以降、各図を参照して、Subunit Identifier Descriptor、及びその下で定義されるDisc Subunit Identifier Descriptorの具体的構造を述べていく。なお、以降説明する各図及びこれに対応する記述内容において、アドレス及び各種パラメータ等の値の後ろに付される「h」は、その値が16進法により表記されているものであることを示すものとする。
【0147】
AV/Cプロトコルにおいては、「Disc Subunit Identifier Descriptor」の上位概念として、「General Subunit Identifier Descriptor」が規定される。つまり、「General Subunit Identifier Descriptor」の規定によって、「Disc Subunit Identifier Descriptor」以外のSubunit Identifier Descriptorにも共通となる定義が規定されるものである。
【0148】
そして、先に図30(a)に示したSubunit Identifier Descriptorは、実際には図31に示すGeneral Subunit Identifier Descriptorとしての構造を有するものとして規定されている。
以下、この図に示される各エリアの内容のうち、本実施の形態に関して説明が必要とされるエリアについて説明を行っていくこととする。なお、以降においても、このようなデータ構造を示している図については、本実施の形態として必要とされるエリアについての説明にとどめることとする。
【0149】
図31において、先頭のaddress=0000h-0001hで示されるエリアA1のdescriptor_lengthには、このdescriptor_lengthのエリアから下のエリアのサイズがバイト数により示される。
また、address=0008h以降のエリアA2−1〜A2−nには、実際に設けられるRoot Contents List数nに応じて、root_object_list_id_0〜root_object_List_id_n-1のn個のroot_object_List_idが配置される。各root_object_list_idは、ここでは2バイトを使用するものとしているが、この使用バイト数は、アドレス0003hのエリアA3におけるsize_of_List_idに格納される値によって指定される。
各root_object_List_idのエリアA2−1〜A2−nには、それぞれ、このsubunitに関連づけられているRoot Contents List(root object list)を指定するためのIDとしての値が格納されている。
また、このroot_object_List_idの数は、address=0006h−00007hで示されるnumber_of_root_object_ListのエリアA4に格納される値によって示される。つまり、number_of_root_object_Listによっては、そのsubunitに関連づけられているRoot Contents List(root object list)の総数が示される。
【0150】
また、エリアA6とされるsubunit_dependent_informationには、subunitのタイプに応じた形式で、subunitに対応した所定内容の情報が格納される。また、このsubunit_dependent_informationのサイズは、エリアA5のsubunit_dependent_lengthによって示される。
【0151】
5−3.Object List Descriptor
上記root_object_List_idによって指定されるRoot Contents List(root object list)は、図32に示すObject List Descriptorとしての構造を有する。全てのObject Listは、この図に示すのと同様の基本構造を有している。また、Root Contents Listの階層下には、後述するようにして、object entry[0]-[n-1]内のchild_list_IDにより指定可能なChild Contents Listが置かれるのであるが、このChild Contents Listもまた、図32に示すObject List Descriptorとしての構造を有する。
【0152】
このObject List Descriptorにあっては、次に述べていくように、先ず、データ構造の冒頭部分に対しては、Subunit Identifier Descriptorにおいて基となるような情報の格納されるいくつかのエリアが配置されるものとしている。そしてこれに続けて、object entry群が配置されるものとしている。
【0153】
図32に示すObject List Descriptorにおいて、先頭のaddress=0000h-0001hが示すエリアA11は、descriptor_lengthとされる。
このdescriptor_lengthには、このdescriptor_length自体を除外した、以降のObject List構造のデータサイズをバイト数によって示すための値が格納される。
【0154】
続くaddress=0002hにより示されるlist_typeのエリアA12には、当該Object
List Descriptorの種類(タイプ)を示す値が格納される。
そして、このlist_typeに格納されるべき値としては、図33に示すようにして定義される。この図33に示されるように、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に対して格納されることになる。
【0155】
また、図32のObject List Descriptorにおいて、address=0003hで示されるエリアA13にはattributesが示される。
attributesには、現listの構造に関連する属性としての情報がビットフラグとして格納される。ここでの詳細な定義内容の説明は省略するが、例えば、Controller側がこのlistをスキップするかリードすべきかの情報や、現object List Descriptorにおいて、後述するobject entry[0]-[n-1]に対してIDが格納されているか否かの情報や、また、object entry[0]-[n-1]に対して、child_list_idが格納されているか否かを示す情報等を表現することができる。
【0156】
続くaddress=0004h-0005hにより示されるエリアA14は、size_of_list_specific_informationとされ、ここには、次に位置するlist_specific_informationのサイズをバイト数によって示す。
そして、address=0006h・・・により示されるlist_specific_informationのエリアA15には、list_typeごとに固有となる情報が格納される。
【0157】
上記list_specific_informationに続けては、number_of_entryのエリアA16が配置される。このnumber_of_entries(n)には、このlistにおけるentry数が示される。即ち、以降続くobject_entry[0]-[n-1]の総数が示される。
【0158】
object_entry[0]-[n-1]の各エリアA17−1〜A17−nには、それぞれ、object_entryとしての情報が格納される。このobject_entryの構造を次に示す。
【0159】
5−4.Object Entry
図34は、object_entry(Object Entry Descriptor)の構造を示している。ここでは、アドレスは、Object List内におけるオフセットアドレス(adress offset)として示されている。
adress offset=00h-01hで示されるエリアA21はdescriptor_lengthとされ、このdescriptor_length自体を除外した、以降のobject_entry構造のデータサイズをバイト数によって示す。
【0160】
続くエリアA22のentry_type(address offset=0002h)には、現Object Entry Descriptorの種類を示す値が格納される。このentry_typeが取り得る値の範囲と、その値に応じた定義内容は、図33に示した内容に準ずる。また、現Object Entry Descriptorが、Disc Subunit Object Entryとされている場合は、subunit type dependentとして定義される80h-FFhの範囲内で、後述するようにしてentry_typeの値が定義されている。
また、ここでのエリアA23におけるattributes(address offset=0003h)の定義としては、先に図32に示したObject List Descriptorと同様となる。
【0161】
エリアA24としてのchild_list_ID(address offset=0004h・・・・)には、現Oobject_entryの階層下にあるとされるchild_list(Child Contents List)のIDが格納される。
【0162】
続くエリアA25としてのobject_IDには、或る所定範囲内の値を用いて、現object_entryに固有に設定されたIDとしての値が格納される。
【0163】
続くエリアA26としてのsize_of_entry_specific_informationは、次に配置されるエリアA27としてのentry_specific_informationのサイズをバイト数によって示している。
そして、entry_specific_informationのエリアA27に対しては、現object_entryのタイプに応じて固有な形式によって、現Objectに固有となる所定内容の情報が格納される。
【0164】
5−5.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」としての内容に対応させていくこととする。
【0165】
先に図34に示したObject Entry Descriptorにおいて、entry_typeとしてDisc Subunitとしての所定値が格納された場合、このObject Entry Descriptorは、Disc Subunit Object Entryとされることになる。
Disc Subunit Object Entryとされる場合に対応するentry_typeとしては、図35に示すようにして定義されている。
【0166】
この図35において、本実施の形態に関連する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が格納されていることを示すことになる。
【0167】
5−6.Disc Subunit Object entry_specific_information
そして、図34に示したObject Entryが、Disc Subunit Object Entryとされた場合の、entry_specific_information(図34:エリアA27)内の基本的構造は、図36に示すものとなる。
【0168】
先ず、adress offset=0000h-0001hで示されるエリアA31は、non_info_block_fields_lengthとされ、ここには、以降続くnon_info_blockエリアとしての合計サイズをバイト数により示す。つまり、図示するように、エリアA33としてのobject_type_specific_non_info_block_fieldsの終端位置までのサイズを示す。
【0169】
続くadress offset=0002hで示されるエリアA32は、disc_Subunit_object_attibutesとされ、Disc Subunit Objectに共通とされる所定の属性情報が記述される。
【0170】
また、続くadress offset=0003h以降の、エリアA33としてのobject_type_specific_non_info_block_fieldsには、このDescriptorによって表されるDisc Subunit Objectのタイプに固有となる情報が格納される。
【0171】
上記object_type_specific_non_info_block_fieldsに続けては、エリアA34としてのinfo_block(infomation block)を1以上配置することができるようにされている。info_blockは、全てのDisc Subunit Object間で共有することができる。
【0172】
5−7.Audio Track Object entry_specific_information
そして、先に図34に示したObject Entryにおいて、エリアA22のentry_typeとして80h(図35参照)の値が格納されると、そのObject Entryは、Audio Track Object entryとしてのDisc Subunit Object Entryとされることになる。そこで、上記図36に示したentry_specific_informationが、Audio Track Object entry_specific_informationとされた場合の構造図を図37に示す。なお、図37において、図36と同一とされる内容については同一符号を付して説明を省略する。
【0173】
この場合、エリアA31のnon_info_block_fields_length(adress offset=0000h-0001h)及びエリアA32のdisc_Subunit_object_attibutes(adress offset=0002h)に続けては、エリアA35としてのaudio_recording_parameters_info_blockが配置され、これに続けて、エリアA34としてのoptional info blockを配置可能とされる。
ここでの詳しい説明は省略するが、audio_recording_parameters_info_blockには、ディスクに記録されたオーディオトラック、つまりDesciptor上では、Audio Objectの記録に関する所定の情報が格納される。例えば、デジタルオーディオデータのサンプリングレート、サンプルサイズ(量子化ビット数)や、コンプレッションモード、チャンネルモードなどの情報が格納される。
【0174】
5−8.Disc Subunit List List_specific_information
続いて、先に図32に示したObject List DescriptorがDisc Subunit Listとして規定される場合について説明する。
前述もしたように、図32に示したObject Listのタイプは、エリアA12のlist_typeの値によって定義される。そして、Object Listを特定のDisc Subunit Listとして規定する場合ためのlist_typeとしては、図38に示すようにして定義されている。
【0175】
先に図33に示したように、list_typeの値は80h〜FFhの範囲により何らかのSubunit typeであることを示すものとされる。そして、Disc Subunit Listのlist_typeとしては、図38に示すようにして、上記した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以降の値は現状未定義とされている。
【0176】
そして、上記図38に示したlist_type=80h〜86hの何れかの値が設定されて、図32に示したObject ListがDisc Subunit Listとされた場合の、同じ図32に示すList_specific_informationの内容としては、図39に示すものとなる。
【0177】
先ず、adress offset=0000h-0001hで示されるエリアA41は、non_info_block_fields_lengthとされ、以降続く、non_info_blockエリアとしてのサイズをバイト数により示す。ここでは、エリアA43とされるlist_type_specific_non_info_block_fieldsの終端位置までのサイズを示す。
【0178】
続くadress offset=0002hで示されるエリアA42は、disc_Subunit_object_attibutesとされ、Disc Subunit Objectに共通とされる所定の属性情報が格納される。
【0179】
そして、adress offset=0003h以降の、エリアA43としてのlist_type_specific_non_info_block_fieldsには、このDescriptorによって表されるDisc Subunit Listのタイプに固有となる情報が格納される。
【0180】
上記list_type_specific_non_info_block_fieldsに続けては、エリアA44としてのinfo_blockを1以上配置可能とされている。
【0181】
5−9.Root Contents List
Disc Subunit ListとしてのRoot Contents Listは、現在インストールされているディスクについての各種所要の情報を表すListとされる。このような情報として、Disc Subunit Listには、例えばディスクタイトルやディスクジャケットなどのディスク全体に関連する情報が格納される。また、オーディオトラック、ビデオトラック、デジタルスチル画像などのトラック(object)単位の情報も格納される。
ここで、図40に、Root Contents Listの構造概念を示しておく。なお、この図に示す構造は、ディスクメディアが階層構造のファイルシステムによりデータを管理していない、いわゆるフラットストレージシステムに対応したものとされる。
この図に示すように、Root Contents Listにあっては、各object entryによって、各種AVobjects(Audio Track,Video Track,Digital Still Image Track)が表現される。これは、或る1つのディスクに記録された全てのAVコンテンツを表示現している。
Root Contents List Headerは、次に説明するRoot Contents List List_specific_informationの他に、全てのAV/Cのlist_typeに共通のヘッダを参照するようにされる。
【0182】
5−10.Root Contents List List_specific_information
Root Contents List List_specific_informationとは、図32に示すObject List DescriptorがRoot Contents Listとして定義された場合の、List_specific_information(エリアA15)とされる。そして、このRoot Contents List List_specific_informationは、図41に示す構造を有する。
【0183】
先頭のadress offset=0000h-0001hで示されるエリアA51は、non_info_block_fields_lengthとされ、以降続く、info_block以外のエリアのサイズをバイト数により示す。この場合は、エリアA54としてのdisc_recordable_informationまでのエリアのサイズを示すことになる。
【0184】
adress offset=0002hで示されるエリアA52は、disc_Subunit_list_attibutesとされ、Disc Subunit listに共通とされる所定の属性情報が格納される。
【0185】
また、adress offset=0003h-0004hで示されるエリアA53はmedia_typeとされる。media_typeは、ディスクに記録される情報のフォーマットを示すものとされる。これは換言すれば、記録層に記録されるデータのフォーマットに基づいて区分されるディスク種別を示す情報となる。
【0186】
このmedia_typeは、図42に示すようにして定義されている。
media_typeは8ビットにより表現され、上位4ビット(MSB)と下位4ビット(LSB)の組み合わせによってMedia Typeを示す。
MSB=01hでは、CD方式によるディスクであることが示され、このとき、LSB=01hが組み合わされれば(0101hとされれば)、CD−DA(digital audio)であることが示される。またLSB=02hはVideo−CDのための値として確保されている。また、LSB=0Ehは、上記CD−DA、Video−CD以外のCD方式によるディスクであることが示される。例えばCD−ROMなどがこれにあたる。
【0187】
また、MSB=03hでは、MD方式によるディスクであることが示され、LSB=01hが組み合わされて、0301hとされたのであれば、MD−audioであることが示される。
また、この場合のLSB=02hはMD−pitureのための値として確保されている。また、ここでもLSB=0Ehは、上記MD−audio、MD−piture以外のMD方式による何らかディスクであることが示される。
【0188】
ここで、例えば先に図2(b)(d)に示したHDデータが記録された記録層を有する単層ディスク及び複層ディスク、また、図2(c)に示したようにして2層のうちの一方の記録層に対してHDデータを記録した記録層を1枚のディスクとして見なした場合、これらのディスクについては、「SACD:(Super Audio CD)」ともいいわれる。
即ち、上記した各3つのディスクは、少なくとも1つのレイヤーに対して、SACD方式に従ったフォーマットのデータが記録されているディスクのグループであると見なすことができる。
【0189】
そして本実施の形態においては、media_typeとしてMSB=05hとされた場合には、そのディスク(若しくは、ディスク内の或る特定のレイヤー)は、SACD方式であると定義するようにしている。これにより、AV/Cプロトコルにあって、SACDに対応したDisc Subunit Listが存在するものとして規定されることになる。
なお、現状では、SACD方式のディスクは1種類のみとされていることから、LSB=01hによってもSACDであることを示すようにされる。つまり、現状では、media_type=O501hによってSACDであることが表される。
【0190】
説明を図41に戻す。
media_typeに続く、adress offset=0005hで示されるエリアA54はdisc_recordable_informationとされる。disc_recordable_informationは、記録可能であるか、或いはライトプロテクトがかかっているのかをフラグにより示す。
【0191】
続く、adress offset=0006h・・・以降のエリアA55に配置されるtime_stamp_ info_blockは、例えばこのListが最後に修正されたときのタイムスタンプが格納される。time_stamp_ info_blocは必須とされる。
また、time_stamp_ info_blockに続くエリアA56には、default_play_list_info_blockが配置される。このdefault_play_list_info_blockもまた必須とされ、PLAYオペレーション時において、現Listがデフォルトとして使用されることを指定する。
【0192】
これに続くoptional info blockとしてのエリアA57には、必要に応じて、他の1以上のinfomation blockとしての情報を格納可能とされている。例えば新たなMedia Typeが出現したり、既存のMedia Typeにあっても、或る仕様に対応した新機能を追加したいときなど、これまでの定義では充分対応できない場合が生じる。このようなときに、所要の情報をoptional info blockとして定義して、エリアA57に格納することができる。
【0193】
5−11.information block
続いて、information block(info_block)について説明する。
図43は、information blockの基本構造を示している。この図において、先頭のaddress=0000h-0001hで示されるエリアA61のcompound_lengthには、現information blockのサイズがバイト数によって示される。但し、compound_lengthのエリアA56自体のサイズはこれには含めないものとされている。
【0194】
次のaddress=0002h-0003hで示されるエリアA62は、info_block_typeとされ、現information blockのタイプを示す。
info_block_typeは、図44に示すようにして大きくは2つに分けられる。0000h-7FFFhまでの値は、general info brock typesに対して割り当てられている。そして、8000h-FFFFhまでの値がsubunit typeに固有となるinfo block typeとして割り当てられる。例えばsubunit typeの場合であれば、各subunit typeの下で定義される各種info blockの各タイプが、8000h-FFFFhの値のうちの何れか1つを利用して定義されていることになる。
【0195】
また、図45に、上記図44に示したgeneral info brock type(0000h-7FFFh)とinfo block type(8000h-FFFFh)内における、各info block typeの定義内容を示す。なお、ここでは、図45に示される各info brock typeごとの内容についての説明は省略する。
【0196】
図43において、info_block_typeに続くaddress=0004h-0005hで示されるエリアA63は、primary_fields_lengthとされる。primary_fields_lengthには、次のaddress=0006h以降に配置されるprimary_fieldsのみのデータサイズをバイト数により示す。
【0197】
そして、address=0006h以降に配置されるprimary_fieldsとしてのエリアA64には、原則として上記info_block_typeにより示される内容のinformation blockが、例えば1セット格納される。
但し、primary_fieldsのタイプの解釈は、info_block_typeのみに依存しないものとされ、現information blockが存在するテーブル範囲に基づいて解釈することもできる。例えば、information blockがList_specific_information内に有れば、information blockのタイプとしては、そのListのタイプに従うようにもできる。同様にして、information blockがentry_specific_infomationの構造内にあれば、information blockのタイプとしては、そのentryのタイプに従うようにもできるものである。
【0198】
primary_fieldsに続けては、secondary_fieldsをオプションとして追加することができる。secondary_fieldsには、1以上のオプショナルなinformation blockが格納される。
【0199】
例えば、システムの所定の動作に伴い、Listの階層構造内から或る特定のinformation blockを参照する必要の生じることがある。
この場合には、例えば図46に示されるようにして目的とするのinformation blockに対しての参照が行われる。
図46においては、List構造が概念的に示されている。このListにあっては、先ず、Level0としての階層に、Object Descriptor0,Object Descriptor1が存在している。そして、Object Descriptor1において、Level0の直下にあるとされるLevel1の階層に、Information Block A,Information Block Bが存在している。更に、Information Block Bにおいて、Level0の直下にあるとされるLevel2の階層にInformation Block X,Information Block Yが存在している。
【0200】
ここでの詳しい説明は省略するが、例えばNew AV/C Descriptor Identifierとして定義される、Info Block specified by posotion in comtainer structureによって示される階層をたどってのポジション指定情報に基づいて、目的のInformation Blockを参照していくことができる。つまり、例えば図46の場合において目的のInformation Block Xを参照するのであれば、Level0からLevel2までの階層をたどりながら、指定されるポジションを参照することで、Information Block Xに到達できる。
また、New AV/C Descriptor Identifierとして定義されるinstance_countによってInformation Block(例:third block of type‘x’)を指定する手法も存在する。
【0201】
5−12.Read Info Block command
また本実施の形態では、図22に示したWrite Request Packet(AV/Cコマンドパケット)の1つとして、Read Info Block commandを定義することで、Disc Subunit Identifier Descriptorの情報の送受信として、Information Block単位での送受信を行うことが可能とされる。
図47は、このRead Info Block commandの構造を示している。なお、この図に示すRead Info Block commandとしての構造は、図22に示したAV/Cコマンドパケットにおける、datafield内のopcode以降に配置されるものである。
【0202】
opcodeの8ビットの領域であるエリアA71には、現AV/CコマンドパケットがRead Info Block commandであることを示す値「06h」が格納される。
これに続くoperand[0](1バイト)以降の所要数のoperandが連続して形成されるエリアA72には、info_block_refernce_pathが格納される。
info_block_refernce_pathは、このRead Info Block commandにより要求するInformation Blockへのパスが示される。ここでの詳しい説明は省略するが、info_block_refernce_pathは、先に図46により説明したように、例えば階層(Level)をたどって目的のInformation Blockを参照するための所定のデータにより形成される構造を採る。
【0203】
info_block_refernce_pathに続くエリアA73は、read_result_statusとされる。
read_result_statusは、オペレーションのステイタスを示す所要の値が格納される。Controllerが、Read Info Block commandを使用してInformation Blockの送信要求を行う場合には、read_result_statusに対してはFFhを書き込むようにされる。そして、subunitとしてのTargetでは、このRead Info Block commandの受信に応答したresponceを返送する際に、このread_result_statusの値を、オペレーションステータスの結果に応じて更新するようにされる。
info_block_refernce_pathに続くエリアA74は未定義とされる。
【0204】
エリアA75としてのdata_lengthには、要求されたInformation Blockに応じて、Targetから読み出されるべきデータサイズがバイト数によって示される。なお、data_length=0とされた場合には特別な意味を持ち、この場合には、全てのInformation Block(the header,the primary_fields,and secondary_fields)がTargetから読み出されるべきものとして指定される。
【0205】
続くエリアA76としてのaddressは、Targetから読み出されるべきデータ(Information Block)のアドレスを指定するもので、これは、読み出し開始位置を、Information Blockのheaderの先頭からのオフセット値により示すものとされる。
【0206】
Controllerが上記図47に示したRead Info Blockcommandを送信すると、Targetからの応答として、ACCEPTED responceが送信されてくる。このACCEPTED responceには、例えば、address(エリアA76)に続くoperandのエリアに対して、data_length(エリアA75)により指定されたデータサイズのResponse Dataが配置されている。即ち要求を行ったInformation Blockが格納されて送信されてくるものである。
【0207】
5−13.SACD type
これまで「Disc Subunit Identifier Descriptor」に関して、本実施の形態に関わるとされる内容について説明を行ってきた。
そして、本実施の形態にあっては、SACD方式としてのメディアに対応して各種機能が実現されるように、先に図42に示したようにして、Disc Subunit Identifier Descriptorのメディアタイプ(media_type)を定義している。つまり、media_type=0501hであれば、そのListはSACD typeとして規定され、SACDの属性を示す内容を有するものとされる。
【0208】
また本実施の形態としては、SACD typeとしてのListのディレクトリ下に含まれるInformation Blockのinfo_block_typeを指定するのにあたっては、次のように規定することとしている。
【0209】
ここで、先に示した図45を再度参照する。この図45には、Information Block Typeについての定義内容が示されている。Information Block Typeの値としては、図44に示されるとおり、8000h-FFFFhの範囲の値をsubunit typeが使用できるものとしていた。
そして、SACD typeにあっては、図45に示されているinfo block typeの定義内容のうち、disc subunitのinfo block typeに使用するためにリザーブされている、info block type=8000h-80FFhまでの範囲の値と、info block type=8800h-FFFFhまでの範囲の値のうちから、実際に定義して設けられるSACD type下でのinfo block typeに応じて、所要の値を使用するものとしている。
【0210】
5−14.SACD type/Root Contents List List_specific_information
続いて、SACD typeとされる場合の、Root Contents List List_specific_informationの構造について、図48を参照して説明する。
この図において、先頭のエリアA51のnon_info_block_fields_lengthからエリアA56のdefault_play_list_info_blockまでのエリアは、図41と同様とされることからここでの説明は省略する。
但しこの場合、エリアA53のmedia_typeに対しては、SACDであることを示す0105hの値(図42参照)が格納されることになる。
【0211】
そして、このSACD typeのRoot Contents List List_specific_informationにあっては、図41においてother optional info blocksとして示されたエリアA57に対して、SACDに対応した次のInformation Blockが配置されていくことになる。
【0212】
先ずエリアA57の先頭に配置されるエリアA57−1は、album_set_info_blockとされる。
SACDとしてのディスク、つまりHDデータが記録されるHDレイヤー102にあっては、図5(b)(c)により説明したようにして、マスターTOCに対して、アルバム情報が格納されている。上記album_set_info_blockには、このアルバム情報に基づく情報として、アルバムを成す「アルバムディスク枚数」、及びアルバムを成すディスクごとに付される通し番号である「アルバム内ディスク識別番号」に対応した情報が格納される。なお、このalbum_set_info_blockの構造は、図49を参照して後述する。
【0213】
エリアA57−1に続くエリアA57−2には、album_catalog_code_info_blockが配置される。
このalbum_catalog_code_info_blockには、アルバム単位で固有となるように設定されたIDが、album_catalog_codeとして格納される。また、album_catalog_code_info_blockの構造についても、図50を参照して後述する。
【0214】
次のエリアA57−3は、disc_catalog_code_info_blockとされ、ディスク単位(但しハイブリッドディスクの場合にはHDレイヤー単位)で固有となるように設定されたIDがdisc_catalog_codeとして格納される。
【0215】
エリアA57−4はname_info_blocck(album)とされ、アルバムタイトルの情報が格納される。そして、エリアA57−5 はname_info_blocck(disc)とされ、ディスクタイトルの情報が格納される。
また、これに続くエリアA57−6は、other info blocksとされて、必要があれば他のアルバム、又はディスクに関するinformation blockが格納される。
【0216】
album_set_info_block
図49にalbum_set_info_blockの構造を示す。この図に示す構造は、先に図43に示したinfo_blockの構造に従っており、図43と同一とされるエリアについては同一符号を付し、同一内容については説明を省略する。
【0217】
この場合、エリアA62のinfo_block_typeには、このInfomation Blockがalbum_set_info_blockであることを示す特定の値(8XXXh)が格納される。そして、エリアA63のprimary_fields_lengthに続くprimary_fieldsとしてのエリアA64において、先ず、先頭のaddress=0006h-0007hの2バイトのエリアA64−1に対して、number_of_album_setの情報が格納される。このnumber_of_album_setとしての値が「アルバムディスク枚数」を示す。
そして、エリアA64−1に続く、address=0008h-0009hのエリアA64−2に対して、「アルバム内ディスク識別番号」を示すnumber_of_album_sequenceが格納される。
【0218】
album_catalog_code_info_block
続いて、図50にalbum_catalog_code_info_blockの構造を示す。この図に示す構造も、先に図43に示したinfo_blockの構造に従っており、図43と同一とされるエリアについては同一符号を付し、同一内容については説明を省略する。
【0219】
この場合にも、エリアA62のinfo_block_typeには、このInfomation Blockがalbum_catalog_code_info_blockであることを示す特定の値(8XXXh)が格納される。
【0220】
そしてこの場合には、primary_fieldsとされるエリアA64において、先ず、先頭のaddress=0006h-0007hの2バイトのエリアA64−1に対して、album_catalog_code_lengthの情報が格納される。ここには次に配置されるエリアA64−2のalbum_catalog_codeのデータサイズがバイト数によって示される。album_catalog_codeの情報は可変長とされているため、このようにして、先ず、album_catalog_codeのデータサイズを示す必要がある。
そして、続くaddress=0008h以降のエリアA64−2に対して、アルバム単位についてのIDとして機能するalbum_catalog_codeの情報が格納される。
【0221】
5−15.SACD type/Audio Track Object entry_specific_information
続いて、SACD typeとされる場合の、Audio Track Object entry_specific_informationの構造について、図51を参照して説明する。この図に示す構造は図37に示したAudio Track Object entry_specific_informationの構造に従っている。そこで、図37と同一エリアについては同一符号を付し、その説明が重複するものについては、ここでの説明は省略する。
【0222】
図51に示す構造において、図37においてoptional info blocksとされたエリアA34に対しては、SACDに記録されたオーディオトラックに関する情報として以下の各Infomation Blockが格納される。
【0223】
先ず、先頭のエリアA34−1には、size_indicator_info_blockが配置され、以下続けて、エリアA34−2のSACD_specific_info_block、エリアA34−3のAV_content_identifier_info_block、エリアA34−4のname_info_blockが配置される。また、エリアA34−4に続くエリアA34−5はother_info_blockとされて、必要があればオーディオトラックに関する他のInfomation Blockを追加することが可能とされている。
ここで、本実施の形態としての特徴となるのが、エリアA34−2のSACD_specific_info_blockとされる。
【0224】
SACDでは、図5に示したように、そのデータゾーンに対して、2チャンネルよりも多いマルチチャンネルによるHDデータが記録されるマルチチャンネルエリア(Multichannel Area)が設けられる。そして、マルチチャンネルエリアに記録されるエリアTOCには、スピーカレイアウトを指定するスピーカレイアウト情報が格納されている。
上記したエリアA34−2のSACD_specific_info_blockには、内容的には、このエリアTOCにおけるスピーカレイアウトを指定する情報と同一とされる情報が格納される。つまり、SACD_specific_info_blockによって、そのトラックについて指定されたスピーカレイアウトを識別することができるものである。
【0225】
そして、上記SACD_specific_info_blockは、図52に示す構造を有する。
この図に示す構造は、先に図43に示したinfo_blockの構造に従う。また、この図においても図43と同一とされるエリアについては同一符号を付し、その説明が重複するものについては、ここでの説明を省略する。
【0226】
図52において、エリアA62のinfo_block_typeには、このInfomation BlockがSACD_specific_info_blockであることを示す特定の値(8XXXh)が格納される。
【0227】
そしてこの場合には、エリアA64とされるprimary_fieldsにおいて、先ず、先頭のaddress offset=0006hにより示される1バイトのエリアA64−1に対して、SACD_specific_typeが配置される。SACD_specific_typeには、現SACD_specific_info_blockに記述される情報内容のタイプごとに固有に設定された値が格納されるのであるが、ここでは、SACD_specific_typeが、前述したスピーカレイアウトであることが示される。
そして、SACD_specific_typeに続く、address offset=0007h以降のエリアA64−2に対して、SACD_specific_type_informationが格納される。即ち、この場合であれば、SACD_specific_type_informationとしては、スピーカレイアウトを具体的に示す情報が格納されることになる。
【0228】
5−16.SACD typeのDisc Subunit Identifier Descriptor
これまでの説明のまとめとして、media_typeについてSACD typeとされた場合のDisc Subunit Identifier Descriptorの構造を図53に示す。
例えば図53(a)に示すDisc Subunit Identifier Descriptorにおけるroot_object_list_id_0により、図53(b)に示すRoot Contents Listを指定しているとする。そして、このRoot Contents Listとしては、その構造内に配置されるlist_specific_information内のmedia_typeの値が0510hとされることで、SACD typeであるものとして定義されているとする。
この場合、Root Contents Listが有するlist_specific_informationには、図53(c)に示すようにして、album_set_info_blockとalbum_catalog_code_info_blockが格納されることになる。つまり、Root Contents List内には、アルバム情報を示すInfomation Blockが格納されていることになる。そして、先の図48〜図50を参照した説明によれば、album_set_info_block、及びalbum_catalog_code_info_blockによって、「アルバムディスク枚数」、「アルバム内ディスク識別番号」、及びアルバムに固有となるIDを有することができることになる。つまり、SACDに特有とされる、アルバム情報をDisc Subunit Identifier Descriptorに持つことができるものである。
【0229】
また、例えば図53(b)に示すRoot Contents ListのChild_Directory_Object[0]によって図53(d)に示すChild Contents Listを指定しているとする。このChild Contents Listは、SACD typeの階層下にある。
そして、このChild Contents Listが有するAudio_Track_Objectにおいて、ここに含まれるoptional info blocks内のAudio Track Object entry_specific_informationにあっては、図53(e)に示すようにして、SACD_specific_info_blockが格納されることになる。このSACD_specific_info_blockは、先に図51及び図52により説明したように、マルチチャンネルオーディオトラックに対応したスピーカレイアウトの情報を示す。
【0230】
このようにして、本実施の形態のDisc Subunit Identifier Descriptorにあっては、SACD、即ちHDレイヤーに固有となる、アルバム情報、及びスピーカレイアウト等の情報を有するようにされる。
これにより、インストールされたディスクがSACDである場合としては、Controllerでは、これらのSACDに固有なDisc Subunit Identifier Descriptor内の情報を要求して取得することで、SACDならではとされる機能を実現することができる。
【0231】
一例として、例えば本実施の形態のディスクプレーヤ0が複数枚のディスクを自動的に交換して再生可能ないわゆるチェンジャ機能を有しているとすれば、Controllerからのリモート制御によって、アルバムを成す複数枚のディスクを、ユーザの所望の再生順によって再生するといったことが可能とされる。このときには、album_set_info_block及びalbum_catalog_code_info_blockの情報が利用される。
また、SACD_specific_info_blockを利用した機能としては、例えば、本実施の形態のAVシステムにAVアンプを接続し、このAVアンプをリモート制御することで、マルチチャンネルのオーディオトラックの再生時には、自動的にスピーカレイアウトを切り換えることなどができる。
【0232】
5−17.ハイブリッドディスクのDisc Subunit Identifier Descriptor
ところで、図2(c)に示したハイブリッドディスクは、CDレイヤー101とHDレイヤー102との2つの記録層を有している。つまり、Disc Subunit Identifier Descriptorとしての概念から見た場合には、異なるメディア(media_type)のListが並列的に存在することになる。
従来、異なるフォーマットのオーディオデータが1つのディスクに混在するということは無かったとされるため、基本的に、Disc Subunit Identifier Descriptorは、1つのディスクフォーマット(media_type)に対応することを前提として、そのフォーマットが規定されていたものである。
しかし、上記のようなハイブリッドディスクの出現によって、1つのディスクに複数のディスクフォーマット、即ちボリュームが存在する場合にも、対応できるようにする必要が生じてきている。
【0233】
そこで、本実施の形態においては、1つのディスクに複数のディスクフォーマット、即ちボリュームが存在する場合には、次に述べるようにしてDisc Subunit
Identifier Descriptorを作成するように提案する。
ここでは、先に図2(c)に示したレイヤー構造を有するハイブリッドディスクがインストールされた場合を例に挙げる。
【0234】
図54は、図2(c)に示したハイブリッドディスクに対応して作成されるDisc Subunit Identifier Descriptorの構造を示している。
この場合には、図54(a)に示すDisc Subunit Identifier Descriptorにおけるroot_object_list_id_0により、図54(b)に示すCD_Root Contents Listを指定し、root_object_list_id_1により、図54(c)に示すSACD_Root Contents Listを指定しているものとする。
つまり、この構造では、Root Contents Listとして、CDレイヤー101に対応するCD_Root Contents Listと、HDレイヤー102に対応するSACD_Root Contents Listとが階層構造的には並列に設けられるものである。
【0235】
このような構造を実現するため、先ず、本実施の形態では、図54(b)に示すCD_Root Contents List内に配置されるlist_specific_information内のmedia_typeに対しては、CDであることを示す0101hを格納し、また、図54(c)に示すSACD_Root Contents List内に配置されるlist_specific_information内のmedia_typeに対しては、SACDであることを示す0501hを格納するようにされる。
つまり、ここではCDレイヤー101を1つのCDというメディアとして扱い、同様にしてHDレイヤー102を1つのSACDというメディアとして扱うものである。
【0236】
これにより、図54(b)に示すCD_Root Contents Listには、CDレイヤー101の記録内容に対応する情報を記述することができ、また、図54(c)に示すSACD_Root Contents Listには、HDレイヤー102の記録内容に対応する情報を記述することができる。
そして、これらのCDレイヤー101とHDレイヤー102との各々に対応するRoot Contents Listを、AV/Cプロトコルの規定に矛盾することなく併存させることが可能となる。
つまり、1つのディスクと対応付けて作成されるべき1つのDisc Subunit Identifier Descriptor内に、CD−DAタイプのメディア(CDレイヤー)と、SACDタイプ(HDレイヤー)のメディアに関する内容が記述されるものである。
【0237】
そして、図54(b)に示すCD_Root Contents Listのディレクトリ下において、例えばそのChild_Directory_Object[0]によって指定される、図54(d)のChild Contents Listは、CDレイヤー101に記録されたオーディオトラックについてのlist_specific_infomaton、及びAudio Track Object[0]〜[n]を有することができることになる。
同様に、図54(c)に示すSACD_Root Contents Listのディレクトリ下において、例えばそのChild_Directory_Object[0]によって指定される、図54(e)のChild Contents Listは、HDレイヤー102に記録されたオーディオトラックについてのlist_specific_infomaton、及びAudio Track Object[0]〜[n]を有することができることになる。
【0238】
また、SACD(HDレイヤー)とCD−DA(CDレイヤー)が混在する状況となったことに対応して、Contents Listのlist_typeとしては、図55に示すようにして定義することとした。
この図に示すように、Contents ListがRoot Contentsとされる場合として、CD_Root Contents Listについてはlist_id=1000hと定義し、SACD_Root Contents Listについては、list_id=2000hと定義することとしている。
更に、Contents ListがChild Contentsとされる場合として、SACD(HDレイヤー)の2チャンネルステレオエリアに記録されるトラックに関するAudio Track Objectを有するChild Contents Listについては、list_id=2001hと定義し、SACD(HDレイヤー)のマルチチャンネルエリアに記録されるトラックに関するAudio Track Objectを有するChild Contents Listについては、list_id=2002hと定義することとしている。
【0239】
従って、図54に示す場合であれば、先ず図54(b)に示すように、CD_Root Contents List内のlist_typeにはlist_id=1000hを格納し、また、図54(c)に示すように、SACD_Root Contents List内ののlist_typeにはlist_id=2000hを格納するようにされる。
また、図54(e)に示すSACD_Root Contents Listのディレクトリ下のChild Contents Listが、SACD(HDレイヤー)の2チャンネルステレオエリアに記録されるトラックに関するAudio Track Objectを有するとすれば、このChild Contents List内のlist_typeにはlist_id=2001hを格納し、SACD(HDレイヤー)のマルチチャンネルエリアに記録されるトラックに関するAudio Track Objectを有するとすれば、このChild Contents Listのlist_typeにはlist_id=2002hを格納することになる。
【0240】
6.Disc Subunit Identifier Descriptor作成処理
本実施の形態のディスクプレーヤ0の実際としては、図2に示した4種のディスクのそれぞれに応じてDisc Subunit Identifier Descriptorを作成することが必要とされる。そこで、以下、ディスクプレーヤ0においてこれら4種のディスクごとに対応してDisc Subunit Identifier Descriptorを作成するための処理動作について、図56〜図58を参照して説明する。なお、図56〜図58の各図に示す処理は、システムコントローラ11が実行する。
【0241】
例えば、ディスクプレーヤ0に対してディスクが装填されると、システムコントローラ11は、その後の所定の機会においてDisc Subunit Identifier Descriptorを作成するために、図56に示す処理を実行する。
【0242】
図56においては、先ずステップS101において、現在装填されているディスクの種別についての判別を行う。このディスク種別の判別は、例えば図7にて説明したようにして、判別信号生成部20から入力された判別信号に基づいて行うようにされる。
【0243】
ステップS101において、ディスク種別がCD−DA(図2(a))であると判別された場合には、ステップS102の処理に進む。
ステップS102においては、装填されているCD−DAのリードインエリアに対するデータ読み出しを実行させることで、TOC(CD−TOC)を読み込むための処理を実行する。そして例えばこの読み込みを行ったTOCを、システムコントローラ11内のRAM11aに書き込んで保持させる。
但し、例えば既にCD−DAを再生して読み込んだTOCが、RAM11aに対して保持されている状態にあれば、ステップS102の処理としては、このRAM11aに保持されているTOCを参照すればよい。この点については、以降説明することとなる、ステップS104と,ステップS106,S107と、ステップS109,S110の各TOC読み込み処理についても同様とされる。
【0244】
次のステップS103においては、上記ステップS102において読み込んだTOCの内容に基づいて、Disc Subunit Identifier Descriptorを作成する。なお、ここで作成されるのは、図54に示すDisc Subunit Identifier Descriptorの構造において、図54(a)→図54(b)→図54(d)の階層構造を抜き出すようにして得られるCD−DAタイプのみとしてのDisc Subunit Identifier Descriptorとされる。
【0245】
また、ステップS101において、単層HDディスク(図2(b))であることが判別された場合には、ステップS104に進む。
ステップS104においては、単層HDディスクのHDレイヤー102に記録されているマスターTOC、及びエリアTOCを読み込むための処理を実行する。
【0246】
そして、次のステップS105において、上記のようにして読み込みを行って取得したマスターTOC、及びエリアTOCの内容に基づいて、SACDタイプのDisc Subunit Identifier Descriptorを作成するための処理を実行する。つまり、先に図53に示した内容及び構造によるDisc Subunit Identifier Descriptorを作成する。
【0247】
この際、例えばlist_type、media_typeなどのエリアには、先に図55や図42に示した定義内容のうち、SACDに対応した値を格納するようにされる。また、特にChild Contents Listについては、前述したように、2チャンネルステレオエリアに対応するChild Contents Listと、マルチチャンネルエリアに対応するChild Contents Listとの2つが作成され、これら各Child Contents ListのAudio_Track_Object[0]〜[n-1]に対しては、エリアTOCの内容に従って、そのチャンネルエリアに記録されているオーディオトラックの情報を作成して格納するようにされる。
【0248】
ところで、先にも述べたように、本実施の形態では、SACDタイプとしてのDisc Subunit Identifier Descriptorには、マスターTOCに記録されたアルバム情報が反映される。そこで、特に、アルバム情報に基づいた作成処理という視点から見た場合のステップS105としての処理を図57に示しておく。
【0249】
図57においては、先ずステップS201において、album_set_info_block(図49参照)を作成するための処理を実行する。このalbum_set_info_blockの作成にあたっては、マスターTOCにおけるアルバム情報のうち、「アルバムディスク枚数」の情報を利用して、number_of_album_setの情報を作成する。また、「アルバム内ディスク識別番号」利用して、number_of_album_sequenceを作成するようにされる。そして、最終的には図49に示したテーブル構造のデータを作成するものである。
【0250】
また次のステップS202においては、マスターTOCにおけるアルバム情報のうちから所要の情報を組み合わせて利用することで、現在装填されているディスクを含むアルバムを特定することのできる情報を作成する。これが図50に示されるalbum_catalog_code_info_block内のalbum_catalog_codeとされる。そして、このようにして作成したalbum_catalog_codeと共に、最終的にalbum_catalog_code_info_blockとしてのデータ構造を作成する。
【0251】
次のステップS203においては、特に、マルチチャンネルエリアのエリアTOCの内容に基づいて、SACD_specific_info_block(図52参照)を作成する。マルチチャンネルエリアのエリアTOCには、各オーディオトラックごとの情報として、スピーカレイアウト情報が記録されているものであるが、このステップS203においてはこのスピーカレイアウト情報に基づき、スピーカレイアウトを指示する内容のSACD_specific_type_informationを作成し、更にこれを含めて各Audio Track ObjectのSACD_specific_info_blockを作成するようにされる。
【0252】
そして、次のステップS204においては、上記ステップS201,S203,S204により作成された、album_set_info_block、album_catalog_code_info_block、及びSACD_specific_info_blockを、適宜所定のエリアに対して格納することで、SACDタイプのDisc Subunit Identifier Descriptorを作成する。
【0253】
また、図56に示すステップS101において、複層HDディスクであることが判別された場合には、ステップS106に進む。
複層HDディスクは、2つのHDレイヤー102を有していることから、例えば先ずステップS106により、第1HDレイヤー(例えば第1記録層としてのHDレイヤー)に記録されているマスターTOC及びエリアTOCを読み出すようにされる。
そして、次のステップS107において、第2HDレイヤー(例えば第2記録層としてのHDレイヤー)に記録されているマスターTOC及びエリアTOCを読み出すようにされる。
【0254】
このようにして、2つのHDレイヤーからマスターTOC及びエリアTOCを読み出した後はステップS108のDisc Subunit Identifier Descriptor作成処理に移行する。この場合HDレイヤーは2層であるが、1つのボリュームとして扱うことができるものとされており、従って、ステップS108の処理としては、例えば先に説明したステップS105の処理と同様とされてよい。
【0255】
また、ステップS101においてハイブリッドディスクであることが判別された場合にはステップS109に進む。
ハイブリッドディスクにはCDレイヤー101とHDレイヤー102との2層が形成されている。そこで、ステップS109においては、先ず、HDレイヤー102からマスターTOC、及びエリアTOCを読み込むための処理を実行する。
そして次のステップS110において、CDレイヤー101に記録されているTOC(CD−TOC)を読み込むための処理を実行する。
以上、上記ステップS109及びS110の処理によって、SACD(HDレイヤー)のTOC情報と、CD−DA(CDレイヤー)のTOC情報とが取得されたことになる。
【0256】
次のステップS111においては、上記のようにして取得した上記各TOCの内容に基づき、Disc Subunit Identifier Descriptorを作成する。
ここで作成されるのは、図54に示す構造及び内容のDisc Subunit Identifier Descriptorとされる。
【0257】
このステップS111としての処理は、例えば図58に示すようにして実行される。
図58においては、先ずステップS301において、SACDボリュームDescriptorを作成するものとしている。ここでいうSACDボリュームDescriptorとは、図54に示す構造を例に挙げれば、Root_object_list_id_1(図54(a))により指定されるSACD_Root Contents List(図54(c))、及びその階層下のChild Contents List(図54(e))より成る構造を指す。
つまりは、HDレイヤー102から取得したマスターTOC及びエリアTOCの内容に従って、図54(c)(e)に示されるような階層構造による、SACDタイプのContents Listを作成するものである。
【0258】
そして、次のステップS302においては、CDレイヤー101から読み込んだTOCの内容に基づいてCDボリュームDescriptorを作成する。ここでのCDボリュームDescriptorとは、図54の場合であれば、Root_object_list_id_0(図54(a))により指定されるCD_Root Contents List(図54(b))、及びその階層下のChild Contents List(図54(d))より成る構造を指すものである。つまり、ステップS302では、これらCD_Root Contents Listとその階層下のChild Contents Listを作成するものである。
この際には、例えば図54にも示したように、CD_Root Contents List(図54(b))の構造内のlist_typeにはList_id=1000h(CD−DA)を格納し、media_typeのエリアには0101h(CD−DA)を格納することで、実際にCD_Root Contents Listであることが定義されるようにする。同様にして、SACD_Root Contents List(図54(c))の構造内のlist_typeにはList_id=2000h(SACD)を格納し、media_typeのエリアには0501h(SACD)を格納することで、実際にCD_Root Contents Listであることが定義されるようにする。
【0259】
図56に示す処理において、ステップS103,S105,S108,S111の何れかを実行した後は、ステップS112に進む。
ステップS112においては、上記ステップS103,S105,S108,S111の何れかの処理を経たことによって作成されたDisc Subunit Identifier Descriptorを、RAM11aに書き込んで保持させるための処理を実行する。これ以降、Controller(例えばパーソナルコンピュータ)が、当該ディスクプレーヤ0をTargetと見なして、Disc Subunit Identifier Descriptorを要求してきた場合には、システムコントローラ11は、この要求に応答したDisc Subunit Identifier DescriptorをRAM11aから読み出して送信することが可能になる。
【0260】
7.Disc Subunit Identifier Descriptorの送信処理
続いて、システムコントローラ11が実行するDisc Subunit Identifier Descriptorの送信処理について、図59及び図60に示すフローチャートを参照して説明する。
先ず図59には、Disc Subunit Identifier Descriptor全体を送信する場合の処理が示されている。ここで、Disc Subunit Identifier Descriptor全体の送信を要求するためのAV/Cコマンドとしては、READ DESCRIPTORcommnadが定義されているものとする。そして、この処理にあっては、図6に示したシステム構成を例に挙げるとすれば、ディスクプレーヤ0がTargetとなり、パーソナルコンピュータ200がControllerとして機能することになる。
【0261】
図59に示す処理にあっては、システムコントローラ11は、先ずステップS401において、Controllerから送信されてくるREAD DESCRIPTOR commnadが受信されるのを待機している。そして、このコマンドが受信されたことが判別されるとステップS402に進んで、Disc Subunit Identifier Descriptor全体のデータをAV/Cコマンドパケット化するための処理を実行する。
つまり、図22に示したAV/Cコマンドパケットとして、READ DESCRIPTOR commnadに応答するresponceであることが表されるPacket Headerの内容を作成し、また、Disc Subunit Identifier Descriptorとしての1纏まりの構造をoperandに付加したdata blockを作成するようにされる。
そして、次のステップS403において、上記ステップS402にて作成されたAV/Cコマンドパケットを送信出力する。つまり、このAV/Cコマンドパケットが、IEEE1394バス116に接続されたControllerに送信出力されるように、IEEE1394インターフェイス部14についての動作制御を実行するものである。
【0262】
また、本実施の形態のAVシステムとしては、先に図47に示したREAD INFO BLOCK commandを利用すれば、Disc Subunit Identifier Descriptorにおける特定のInfomaition Blockを指定して送受信することが可能とされる。
このREAD INFO BLOCK commandの受信に応じたシステムコントローラ11の処理動作としては、図60に示すものとなる。
【0263】
図60に示す処理にあっては、先ずステップS501において、Controllerから送信されてくるREAD INFO BLOCK commandの受信を待機しており、このコマンドを受信すると、ステップS502に進む。
【0264】
ステップS502においては、受信したREAD INFO BLOCK commandに格納されているinfo_block_refernce_path、data_length、addressなどの情報に基づいて、要求されたInformation Block、即ちTargetから読み出されるべきデータを特定する。そして、次のステップS503において、この特定されたInformation BlockをAV/Cコマンドパケット化する。つまり、図47においても説明したように、受信したREAD INFO BLOCK commandのread_result_statusを処理結果に応じて更新すると共に、operandに対して、上記特定されたInformation Blockを格納するものである。そして、続くステップS504の処理により、上記のようにして更新したREAD INFO BLOCK commandを、responceとしてControllerに対して送信出力する。
【0265】
ところで、上記実施の形態にあっては、図54に示すような複数のmedia typeのLISTが格納されるDisc Subunit Identifier Descriptorは、図2(c)に示した形態のハイブリッドディスクに対応しているものとされる。つまり、記録フォーマットが異なるボリューム単位としての記録情報が、物理的に異なるレイヤーとして設けられているディスクに対応している。本発明は、このように1つの記録媒体が物理的に複数のボリュームを有する場合の他、例えば同一レイヤーにおいて、論理的に複数のボリュームを有するようにされたディスクであっても適用が可能とされる。
【0266】
また、本発明としての概念は、インストールされたディスクが、図2に例示したディスクである場合に限定されるものではなく、本実施の形態として示したHDデータやCD−DAのフォーマット以外のデジタルオーディオデータが記録される記録層(ボリューム)を有するディスクであっても構わない。
また、ディスクに記録されるデータとしては、当然のこととして例えばビデオデータなど、オーディオデータ以外であってもよいものである。更には、本発明が対応し得るメディアとしてはディスクメディアにも限定されるものではなく、例えばテープメディアや、近年普及しつつあるメモリ素子を用いたメディアなどにも適用できる。
また、上記実施の形態としての再生装置は再生専用メディアに対応するものとされるが、これも当然こととして、データの追記又は書き換えが可能なメディアに対応して記録再生が可能な装置にも適用可能である。
更には、本発明としては、IEEE1394の規格以外のデジタルデータインターフェイスに対しても適用が可能である。
【0267】
【発明の効果】
以上説明したように本発明は、例えばハイブリッドディスクなどといわれる、記録フォーマットが異なる複数の記録情報が記録される記録媒体が存在する場合に、このような記録媒体に関する記述情報を、所定の伝送フォーマットに対応させて作成するのにあたっては、各記録情報に対応した記述内容は、それぞれ異なる記録媒体のタイプ(media type)として定義された情報単位(Contents List)として管理されるようにしている。
また、このようにして作成された記述情報を上記所定の伝送フォーマットに従ったデータバスを介して送信するようにもされる。
【0268】
このような構成であれば、例えば記録フォーマットを記録媒体のタイプとして扱っている記述情報の規格であっても、上記ハイブリッドディスクなどのようなハイブリッドメディアに記録された複数ボリュームを、本来1つの記録媒体に対応付けられるべき1つの記述情報の構造内で表現することが可能とされる。そして、所定の伝送フォーマットに従ったデータバスにより接続される機器間で、ハイブリッドメディアに対応した各種機能を実現することができる。つまり、これまでには存在しなかったようなハイブリッドメディアに特化された機能の拡充が図られるものである。
【図面の簡単な説明】
【図1】本発明の実施の形態の再生装置が対応可能なディスクの記録層構造の説明図である。
【図2】実施の形態の再生装置が対応可能なディスクの種別の説明図である。
【図3】実施の形態の再生装置が対応可能なディスクの記録層形成位置の説明図である。
【図4】本実施の形態の再生装置が対応するハイブリッドディスクの記録層のゾーン構造を示す説明図である。
【図5】HDレイヤーのゾーン構造を示す説明図である。
【図6】本実施の形態のAVシステム構成例を示す説明図である。
【図7】本実施の形態の再生装置であるディスクプレーヤの構成を示すブロック図である。
【図8】本実施の形態のディスクプレーヤのCDデータ再生系及びHDデータ再生系のブロック図である。である。
【図9】本実施の形態においてControllerとして機能するパーソナルコンピュータの構成例を示すブロック図である。
【図10】本実施の形態に対応するIEEE1394のスタックモデルを示す説明図である。
【図11】IEEE1394に使用されるケーブル構造を示す説明図である。
【図12】IEEE1394における信号伝送形態を示す説明図である。
【図13】IEEE1394におけるバス接続規定を説明するための説明図である。
【図14】IEEE1394システム上でのNode ID設定手順の概念を示す説明図である。
【図15】IEEE1394におけるPacket送信の概要を示す説明図である。
【図16】Asynchronous通信における基本的な通信規則(トランザクションルール)を示す処理遷移図である。
【図17】IEEE1394バスのアドレッシング構造を示す説明図である。
【図18】CIPの構造図である。
【図19】プラグにより規定された接続関係例を示す説明図である。
【図20】プラグコントロールレジスタを示す説明図である。
【図21】Asynchronous通信において規定されるWrite Transactionを示す処理遷移図である。
【図22】Asynchronous Packet(AV/Cコマンドパケット)の構造図である。
【図23】Asynchronous Packetにおける、ctype/responceの定義内容を示す説明図である。
【図24】Asynchronous Packetにおける、subunit_typeと、opcodeの定義内容例を示す説明図である。
【図25】Asynchronous通信におけるプラグ構造を示す説明図である。
【図26】Asynchronous通信におけるプラグアドレス構造を示す説明図である。
【図27】Asynchronous通信におけるプラグアドレス構造を示す説明図である。
【図28】Asynchronous通信におけるプラグ間での処理を示す説明図である。
【図29】Asynchronous Connectionとしての送信手順を示す説明図である。である。
【図30】 Subunit Identifier Descriptorの構造概念を示す説明図である。
【図31】 Subunit Identifier Descriptorの構造を示す説明図である。
【図32】 Object List Descriptorの構造を示す説明図である。
【図33】 list typeの定義内容を示す説明図である。
【図34】 Object Entryの構造を示す説明図である。
【図35】 entry typeの定義内容を示す説明図である。
【図36】 Disc Subunit Object entry_specific_informationの構造を示す説明図である。
【図37】 Audio Track Object entry_specific_informationの構造を示す説明図である。
【図38】 Disc Subunit typeの定義内容を示す説明図である。
【図39】 Disc Subunit List List_specific_informationの構造を示す説明図である。
【図40】 Root Contents Listとしての構造概念を示す説明図である。
【図41】 Root Contents List List_specific_informationの構造を示す説明図である。
【図42】 media typeの定義内容を示す説明図である。
【図43】 information blockの基本構造を示す説明図である。
【図44】 information block typeの定義内容を示す説明図である。
【図45】 information block typeの定義内容の詳細を示す説明図である。
【図46】 List内におけるinformation blockの配置構造を概念的に示す説明図である。
【図47】READ INFO BLOCK commandの構造を示す説明図である。
【図48】SACDに対応するRoot Contents List List_specific_informationの構造を示す説明図である。
【図49】 album_set_info_blockの構造を示す説明図である。
【図50】 album_catalog_code_info_blockの構造を示す説明図である。
【図51】SACDに対応するAudio Track Object entry_specific_informationの構造を示す説明図である。
【図52】 SACD_specific_informationの構造を示す説明図である。
【図53】SACDに対応するDisc Subunit Identifier Descriptorの全体構造を示す説明図である。
【図54】本実施の形態のハイブリッドディスクに対応するDisc Subunit Identifier Descriptorの全体構造を示す説明図である。
【図55】SACD及びCD−DAについてのList Typeの定義内容を示す説明図である。
【図56】本実施の形態が対応するディスクについてのDisc Subunit Identifier Descriptor作成処理を示すフローチャートである。
【図57】本実施の形態の単層HDディスクに対応したDisc Subunit Identifier Descriptor作成処理を示すフローチャートである。
【図58】本実施の形態のハイブリッドディスクに対応したDisc Subunit Identifier Descriptor作成処理を示すフローチャートである。
【図59】 Disc Subunit Identifier Descriptor送信のための処理動作を示すフローチャートである。
【図60】 Information Block送信のための処理動作を示すフローチャートである。
である。
【符号の説明】
1 光ディスク、2 スピンドルモータ、3 光学ヘッド、3A CD用ヘッド部、3B HD用ヘッド部、4 RFアンプ、5 サーボ回路、6 駆動回路、7 エラー訂正及びデコード回路、8 メモリコントローラ、9 バッファメモリ、10 D/Aコンバータ、11 システムコントローラ、12 操作部、13 表示部、14 IEEE1394インターフェイス部、15A,15B 対物レンズ、16A,16B 2軸機構、17A,17B 半導体レーザ、18A,18B ディテクタ、20 判別信号生成部、101 CDレイヤー、102 HDレイヤー、116 データバス(IEEE1394バス)
Claims (8)
- 第1の記録方式で単層にデータが記録された第1のディスク状記録媒体と、上記第1の記録方式とは異なる第2の記録方式で単層にデータが記録された第2のディスク状記録媒体と、上記第1の記録方式で第1の記録層にデータが記録されるとともに上記第2の記録方式で上記第1の記録層とは異なる第2の記録層にデータが記録され上記第1の記録層と上記第2の記録層とが積層された第3のディスク状記録媒体と、上記第2の記録方式でデータが記録された第1の記録層と上記第2の記録方式でデータが記録された第2の記録層とが積層された第4のディスク状記録媒体とのうちの装着された1のディスクを再生する再生手段と、
上記再生手段によってディスク状記録媒体の所定領域から読み出されるデータに基づいてディスク状記録媒体の種別を判別する種別判別手段と、
上記種別判別手段にて上記第4のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合には、各層に記録された管理情報を取得し、上記種別判別手段にて上記第3のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合に、記録フォーマットが異なる各々の記録方式で記録される管理情報の各記録層における記録位置ごとに複数の記録情報が記録される記録媒体に対して再生を行うことで、少なくとも、記録情報を管理するために上記各記録情報内に設けられる管理情報を取得することのできる情報取得手段と、
上記情報取得手段により取得された上記各記録情報内の管理情報に基づいて所定の伝送フォーマットに対応した記述情報を作成するのに、上記第3のディスク状記録媒体の場合には1つの記述情報の構造内において、上記複数の記録情報ごとの記述内容がそれぞれ異なる記録媒体として定義された情報単位として管理されるように記述を行い、上記第4のディスク状記録媒体の場合には上記積層された記録層を単一のディスク状記録媒体として管理されるように記述情報の記述を行う記述情報作成手段と、
を備えていることを特徴とする再生装置。 - 上記記録フォーマットの1つは、サンプリング周波数が、基準サンプリング周波数fsとされ、量子化ビット数が所定のマルチビットとされるデータフォーマットに対応していることを特徴とする請求項1に記載の再生装置。
- 上記記録フォーマットの1つは、サンプリング周波数fs×N(但し、fsは所定の基準サンプリング周波数、Nは2以上の自然数)とされ、量子化ビット数が1ビットとされるデータフォーマットに対応していることを特徴とする請求項1に記載の再生装置。
- 上記所定の伝送フォーマットは、IEEE1394データインターフェイスとされていることを特徴とする請求項1に記載の再生装置。
- 第1の記録方式で単層にデータが記録された第1のディスク状記録媒体と、上記第1の記録方式とは異なる第2の記録方式で単層にデータが記録された第2のディスク状記録媒体と、上記第1の記録方式で第1の記録層にデータが記録されるとともに上記第2の記録方式で上記第1の記録層とは異なる第2の記録層にデータが記録され上記第1の記録層と上記第2の記録層とが積層された第3のディスク状記録媒体と、上記第2の記録方式でデータが記録された第1の記録層と上記第2の記録方式でデータが記録された第2の記録層とが積層された第4のディスク状記録媒体とのうちの装着された1のディスクを再生する再生ステップと、
上記再生手順によってディスク状記録媒体の所定領域から読み出されるデータに基づいてディスク状記録媒体の種別を判別する種別判別ステップと、
上記種別判別ステップにて上記第4のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合には、各層に記録された管理情報を取得し、上記種別判別手順にて上記第3のディスク状記録媒体と判別されたディスク状記録媒体の再生を行う場合に、記録フォーマットが異なる各々の記録方式で記録される管理情報の各記録層における記録位置ごとに複数の記録情報が記録される記録媒体に対して再生を行うことで、少なくとも、記録情報を管理するために上記各記録情報内に設けられる管理情報を取得する情報取得ステップと、
上記情報取得ステップにより取得された上記各記録情報内の管理情報に基づいて所定の伝送フォーマットに対応した記述情報を作成するのに、上記第3のディスク状記録媒体の場合には1つの記述情報の構造内において、上記複数の記録情報ごとの記述内容がそれぞれ異なる記録媒体として定義された情報単位として管理されるように記述を行い、上記第4のディスク状記録媒体の場合には上記積層された記録層を単一のディスク状記録媒体として管理されるように記述情報の記述を行う記述情報作成ステップと、
要求に応じて、上記所定の伝送フォーマットに従って、上記記述情報を送信出力することのできる送信ステップと、
を実行するように構成されていることを特徴とする情報伝送方法。 - 上記記録フォーマットの1つは、サンプリング周波数が、基準サンプリング周波数fsとされ、量子化ビット数が所定のマルチビットとされるデータフォーマットに対応していることを特徴とする請求項5に記載の情報伝送方法。
- 上記記録フォーマットの1つは、サンプリング周波数fs×N(但し、fsは所定の基準サンプリング周波数、Nは2以上の自然数)とされ、量子化ビット数が1ビットとされるデータフォーマットに対応していることを特徴とする請求項5に記載の情報伝送方法。
- 上記所定の伝送フォーマットは、IEEE1394データインターフェイスとされていることを特徴とする請求項5に記載の情報伝送方法。
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)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
JP3890927B2 (ja) | 2001-07-23 | 2007-03-07 | ヤマハ株式会社 | 他ノードを管理する通信装置及び他ノードに管理される通信装置 |
CN101015013A (zh) * | 2005-02-16 | 2007-08-08 | 三菱电机株式会社 | 光盘和光盘装置 |
JP2007004856A (ja) | 2005-06-22 | 2007-01-11 | Sony Corp | 情報処理装置、および情報処理方法、並びにコンピュータ・プログラム |
-
1999
- 1999-12-06 JP JP34681699A patent/JP4055313B2/ja not_active Expired - Fee Related
Also Published As
Publication number | Publication date |
---|---|
JP2001167515A (ja) | 2001-06-22 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
JP4449141B2 (ja) | 電源制御装置、電源制御システム | |
US7130945B2 (en) | Controlling method for transmitting reserve commands from a controller to target devices | |
JP4403331B2 (ja) | 電子機器システム、情報処理機器 | |
JP4281201B2 (ja) | 制御装置、及び制御方法 | |
JP4404190B2 (ja) | 電子機器、認証使用情報更新方法 | |
US6493769B1 (en) | Stream information processing and method and providing medium | |
JP4055313B2 (ja) | 再生装置、及び情報伝送方法 | |
JP2000132908A (ja) | デ―タ送受信装置およびその方法 | |
JP2001006276A (ja) | 外部機器の制御装置、及び外部機器の制御方法 | |
KR101165316B1 (ko) | 수신장치 및 수신방법 | |
JP2003289304A (ja) | 信号処理装置、信号処理方法 | |
JP2001167556A (ja) | 再生装置、及び情報伝送方法 | |
JP2000357386A (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 |