JP4820812B2 - 再生装置、プログラム、再生方法 - Google Patents

Description

オーディオストリームの読出技術に属する発明である。

オーディオストリームの読出技術とは、再生装置が圧縮符号化が施されたオーディオストリームを光ディスク等の記録媒体から読み出して、他の機器に出力する技術である。一般に再生装置には、圧縮符号化されたオーディオストリームを伸長するためのデコーダが備えられており、このデコーダのデコードにより得られた非圧縮のLPCM形式のデジタルオーディオ、又は、アナログの音声信号が他の機器に出力される。

ホームシアターシステムにおけるテレビやスピーカーは、そうして出力された非圧縮のLPCM形式のデジタルオーディオ、又は、アナログの音声信号を取り込んだ上音声出力を行う。尚、記録媒体に記録されたオーディオストリームを読みだして再生する技術には、以下の特許文献に記載されている先行技術がある。
特開２０００−２２８６５６号公報

しかしながら、ホームシアターシステムでの使用には、再生装置が高価なAVアンプに接続されていて、そのアンプにデコード能力が存在することがある。
ここで、そのような高価なAVアンプに接続されているデコーダ回路を、再生装置に内蔵されているデコーダ回路と比較とすると、前者のAVアンプは、音質を追及するマニア向けの製品であるので、ハードウェアに高価な材質が使われており、ノイズ対策が徹底されている。これに対して後者のハードウェアは、コストダウンを余儀なくされているため、回路基板等に安価な材質が使われていることが多く、ノイズ対策は、徹底されているとはいい難い。

従って、AVアンプではなく、再生装置でデコードを行い、出力するような場合、たとえ、AVアンプ側のデコーダが高価なものであったとしても、出力される音声は、ノイズが乗った低い品位のものになる。
そこで、高価なAVアンプを所有しているマニア向けに、圧縮されたオーディオストリームをそのまま出力するような再生装置を商品ラインナップに加えることが考えられる。しかしそのようなごく一部のマニア向けに、新たなラインナップを増やすというのは、メーカにとって、負担が重い。

本発明の目的は、高価なAVアンプがおかれているようなホームシアターシステムに再生装置が存在する場合、そのAVアンプの能力を如何なく発揮することができる再生装置を提供することである。

上記目的を達成するため、本発明にかかる再生装置は、符号化された状態のオーディオストリームを記録媒体から読み出して再生する再生装置であって、接続相手となる装置のデコード能力を判定する判定手段と、接続相手となる装置にデコード能力がある場合、接続相手となる装置に内蔵されているデコーダにて、デコードを行わせるかどうかを、ユーザに問い合わせる問合手段と、状態レジスタと、接続相手側のデコーダで、デコードを行う旨を指定する操作をユーザが行った場合、接続相手となる装置のデコード能力を、再生装置における状態レジスタに設定して、当該状態レジスタにおけるデコード能力の設定、及び、オーディオストリームの属性に基づき、再生の対象となるオーディオストリームを選択する選択手段と、選択されたオーディオストリームを、記録媒体から読み出して、符号化された状態のまま、接続相手となる装置に転送する転送手段とを備えることを特徴としている。

接続相手側のデコーダでデコードする旨の指定をユーザが行った場合、再生装置は、自装置のデコード能力にかかわらず、記録媒体から読み出したオーディオストリームを、符号化された状態のまま、接続相手となる装置に転送するので、接続相手となる装置が高価なマニア向けのAVアンプであり、これにデコード能力が存在する場合、再生装置の代わりに、接続相手となるAVアンプ側に、デコードを行わせることができる。ノイズ対策に長けたデコーダがAVアンプに存在する場合は、接続相手となるAVアンプに、デコードを委ねることができるので、高品位の音声出力を実現することができる。

高価なAVアンプがおかれているようなホームシアターシステムに再生装置が存在する場合、そのAVアンプにおけるデコーダの能力を如何なく発揮することができるので、いたずらに商品ラインナップを増やすことなく、一般ユーザから、マニアまでの幅広いユーザ層から支持を得るような再生装置を簡易に開発して市場に投入することができる。

(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体は、ローカルストレージ２００である。ローカルストレージ２００は、再生装置３００、テレビ４００、AVアンプ５００、スピーカ６００から構成されるホームシアターシステムに、映画作品を供給するという用途で使用される。

以降、BD-ROM１００、ローカルストレージ２００、再生装置３００について説明を行う。
BD-ROM１００は、映画作品が記録された記録媒体である。
ローカルストレージ２００は、再生装置に組み込まれ、映画配給者のサーバから配信されたコンテンツの受け皿として利用されるハードディスクである。

再生装置３００は、ネット対応型のデジタル家電機器であり、BD-ROM１００を再生する機能をもつ。また、映画配給者のサーバから、ネットを通じてダウンロードしたコンテンツを、BD-ROM１００に記録されたコンテンツと組み合わせて、BD-ROM１００のコンテンツを拡張/更新をすることができる。BD-ROM１００の記録内容に、ローカルストレージ２００の記録内容を組み合わせて、BD-ROM１００に記録されていないデータを、恰も、記録されているように扱う技術を“バーチャルパッケージ”という。

以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、BD-ROMのファイルシステム上における改良で実現することができる。図２は、BD-ROMにおけるファイル・ディレクトリ構成を示す図である。本図においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。

＜BD-ROMの概要＞
図２は、BD-ROMの内部構成を示す図である。本図の第４段目にBD-ROMを示し、第３段目にBD-ROM上のトラックを示す。本図のトラックは、BD-ROMの内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてBD-ROMの応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第１段目のようになる。この第1段目においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。

BDMVディレクトリには、拡張子bdmvが付与されたファイル(index.bdmv,MovieObject.bdmv)がある。そしてこのBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDBJディレクトリ、BDJAディレクトリ、AUXDATAディレクトリと呼ばれる6つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls)がある。

CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi)がある。
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts)がある。
BDBJディレクトリには、拡張子bobjが付与されたファイル(00001.bobj)が存在する。
BDJAディレクトリには、拡張子jarが付与されたファイル(00001.jar)がある。
AUXDATAディレクトリには、ファイルsound.bdmvが格納される。

以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
＜BD-ROMの構成その１.AVClip＞
先ず初めに、拡張子.m2tsが付与されたファイルについて説明する。図３は、拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。拡張子.m2tsが付与されたファイル(00001.m2ts)は、AVClipを格納している。AVClipはMPEG2-Transport Stream形式のデジタルストリームである。このデジタルストリームは、デジタル化された映像、デジタル化された音声を(上１段目)、PESパケットからなるエレメンタリストリームに変換し(上２段目)、更にTSパケットに変換して(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(Presentatiion Graphics(PG)ストリーム)及び対話系のインタラクティブグラフィクスストリーム(Interactive Graphics(IG)ストリーム)を(下１段目、下２段目)、更にTSパケットに変換して(下３段目)、これらを多重化することで構成される。

PGストリームは、言語毎の字幕を構成するグラフィクスストリームであり、英語、日本語、フランス語というように複数言語についてのストリームが存在する。PGストリームは、PCS(Presentation Control Segment)、PDS(Pallet Define Segment)、WDS(Window DefineSegment)、ODS(Object Define Segment)、END(END of Display Set Segment)という一連の機能セグメントからなる。ODS(Object Define Segment)は、字幕たるグラフィクスオブジェクトを定義する機能セグメントである。

WDS(Window Define Segment)は、画面におけるグラフィクスオブジェクトの描画領域を定義する機能セグメントであり、PDS(Pallet Define Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。PCS(Presentation Control Segment)は、字幕表示におけるページ制御を規定する機能セグメントである。かかるページ制御には、Cut-In/Out、Fade-In/Out、Color Change、Scroll、Wipe-In/Outといったものがあり、PCSによるページ制御を伴うことにより、ある字幕を徐々に消去しつつ、次の字幕を表示させるという表示効果が実現可能になる。

IGストリームは、対話制御を実現するグラフィクスストリームである。IGストリームにて定義される対話制御は、DVD再生装置上の対話制御と互換性がある対話制御である。かかるIGストリームは、ICS(Interactive CompositionSegment)、PDS(Palette Difinition Segment)、ODS(Object Definition Segment)、END(END ofDisplay Set Segment)と呼ばれる機能セグメントからなる。ODS(ObjectDefinition Segment)は、グラフィクスオブジェクトを定義する機能セグメントである。このグラフィクスオブジェクトが複数集まって、対話画面上のボタンが描画される。PDS(Palette Difinition Segment)は、グラフィクスオブジェクトの描画にあたっての、発色を規定する機能セグメントである。ICS(Interactive Composition Segment)は、ユーザ操作に応じてボタンの状態を変化させるという状態変化を実現する機能セグメントである。ICSは、ボタンに対して確定操作がなされた際、実行すべきボタンコマンドを含む。

ここでAVClipは、1つ以上の“STC_Sequence”から構成される。“STC_Sequence”とは、AVストリームのシステム基準時刻であるSTC(System Time Clock)の不連続点(system time-base discontinuity)が存在しない区間をいう。STCの不連続点はデコーダがSTCを得るために参照するPCR(Program Clock Reference)を運ぶPCRパケットの不連続情報(discontinuity_indicator)がONである点である。

続いて、以上のように構成されたAVClipが、BD-ROMにどのように書き込まれるかを説明する。図４は、AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。本図の第１段目にAVClipを構成するTSパケットを示す。

AVClipを構成する188バイトのTSパケットは、第２段目に示すように4バイトのTS_extra_header(図中のハッチング部)、が付されて、192バイト長のSourceパケットになる。このTS_extra_headerは、当該TSパケットのデコーダ入力時刻情報を示すArrival_Time_Stampを含む。
AVClipを構成するSourceパケットは、第3段目におけるAVClipにおいて、1つ以上の“ATC_Sequence”を構成する。“ATC_Sequence”とは、Sourceパケットの配列であって、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、不連続点(no arrivaltime-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、連続性が存在するSourceパケット列を“ATC_Sequence”という。

かかるATC_SequenceがAVClipになり、xxxxx.m2tsというファイル名でBD-ROMに記録される。
かかるAVClipは、通常のコンピュータファイル同様、1つ以上のファイルエクステントに分割され、BD-ROM上の領域に記録される。第4段目はAVClipがどのようにBD-ROMに記録されるかを模式的に示す。この第4段目においてファイルを構成する各ファイルエクステントは、予め定められたＳextent以上のデータ長を有する。

AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓextentを検討する。
ここでBD-ROMにおいて光ピックアップのジャンプに要する時間は、
Ｔjump＝Ｔaccess+Ｔoverhead
で与えられる。

Ｔaccessは、ジャンプ距離（ジャンプする物理アドレスの距離）に応じて与えられる時間である。

BD-ROMから読み出されたTSパケットは、リードバッファと呼ばれるバッファに格納された上、デコーダに出力されるが、リードバッファへの入力が、Rudというビットレートで行われ、ECCブロックにおけるセクタ数をSeccとした場合、
Ｔoverheadは、

Ｔoverhead≦(2×Secc×8)／Rud＝20m秒
という計算で与えられる。

BD-ROMから読み出されたTSパケットは、Sourceパケットの状態でリードバッファに格納された上、TS_Recording_rateという転送レートで、デコーダに供給される。

TS_Recording_rateという転送レートでの、デコーダへのTSパケット供給が跡絶えさせないためには、Ｔjumpの間、リードバッファからデコーダへのTSパケット出力が継続している必要がある。ここでリードバッファからの出力は、TSパケットではなく、Sourceパケットの状態でなされるので、TSパケットのSourceパケットとのサイズ比を192/188とした場合、Ｔjumpの間、(192/188×TS_Recording_rate)という転送レートにより、リードバッファからのSourceパケット出力が継続している必要がある。

従って、リードバッファが、アンダーフローしないためのバッファ蓄積量は、
Ｂoccupied≧(Tjump/1000×8)×((192/188)×TS_Recording_rate)
となる。

リードバッファへの入力レートはRud、リードバッファからの出力レートはTS_Recording_rate×(192/188)であるので、リードバッファへの蓄積レートは、入力レート−出力レートの計算で与えられ、(Rud−TS_Recording_rate×(192/188))になる。

このＢoccupiedを、リードバッファに蓄積するのに要する時間Txは、

Tx＝Ｂoccupied/(Rud−TS_Recording_rate×(192/188))
になる。

BD-ROMからの読み出しには、この時間TxにおいてRudでのTSパケット入力を継続する必要があるので、AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓextentは、

Ｓextent＝Rud×Tx
＝Rud×Ｂoccupied/(Rud−TS_Recording_rate×(192/188))
≧Rud×(Tjump/1000×8)×((192/188)×TS_Recording_rate)
/(Rud−TS_Recording_rate×(192/188))

≧(Rud×Tjump/1000×8)×
×TS_Recording_rate×192/(Rud×188−TS_Recording_rate×192)
になる。
よって
Ｓextent≧
(Tjump×Rud/1000×8)×
（TS_Recording_rate×192/(Rud×188−TS_Recording_rate×192))

になる。

AVClipを構成する各ファイルエクステントは、デコーダのアンダーフローをおこさないように算出されたＳextent以上のデータ長をもつことにより、AVClipを構成する各ファイルエクステントが、BD-ROM上において離散的に位置されたとしても、再生時においてデコーダへのTSパケット供給が途絶えさせることなく、連続的に読み出されることになる。

図５は、BD-ROMの物理単位と、1つのファイルエクステントを構成するSourceパケットとの対応関係を示す図である。第２段目に示すように、BD-ROM上には複数セクタが形成されている。ファイルエクステントを構成するSourceパケットは、第1段目に示すように、32個毎にグループ化されて、連続する3つのセクタに書き込まれる。32個のSourceパケットからなるグループは、6144バイト(=32×192)であり、これは3個のセクタサイズ6144バイト(=2048×3)と一致する。3個のセクタに収められた32個のSourceパケットを“Aligned Unit”といい、BD-ROMへの書き込みは、Aligned Unit単位でなされる。

第３段目においてセクタは、32個単位で誤り訂正符号が付され、ECCブロックを構成する。再生装置はAligned Unitの単位でBD-ROMをアクセスする限り、32個の完結したSourceパケットを得ることができる。以上がBD-ROMに対するAVClipの書き込みのプロセスである。
＜エレメンタリストリームの種類＞
図６は、AVClipにどのようなエレメンタリストリームが多重化されているかを示す図である。

本図に示すように、AVClipには、0x1011のPIDをもつ高画質ビデオストリーム、0x1100から0x111FまでのPIDをもつPrimaryオーディオストリーム、0x1200から0x121FまでのPIDをもつPGストリーム、0x1400から0x141FまでのPIDをもつIGストリームが多重化されている。これらのエレメンタリストリームを構成するパケットは、それに対応するPIDが付与されており、このPIDを手掛かりにして多重分離されることになる。このように、高画質なビデオストリームが多重化されているAVClipを、以下“MainClip”と呼ぶ。これに対し、MainClipと同時に再生されるAVClipを、“SubClip”とよぶ。

＜BD-ROMの構成その２.Clip情報＞
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル(00001.clpi)は、Clip情報を格納している。Clip情報は、個々のAVClipについての管理情報である。図７は、Clip情報の内部構成を示す図である。本図の左側に示すようにClip情報は、

i)AVClipについての情報を格納した『ClipInfo()』、
ii)ATC Sequence,STC Sequenceに関する情報を格納した『Sequence Info()』
iii)Program Sequenceに関する情報を格納した『Program Info()』
iv)『Characteristic Point Info(CPI())』からなる。

ClipInfoには、このClip情報が参照するAVClipのアプリケーションタイプ（application_type）がある。アプリケーションタイプによってMainClipかSubClipかや、動画を含んでいるのか静止画(スライドショー)を含んでいるのかなどが識別できる。TS_recording_rateは該当AVClipのシステムビットレート情報である。
Sequence Infoは、AVClipに含まれる、1つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS,ATSが出現する可能性があり、再生時に不都合が生じる。STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、Sequence Infoは設けられている。

Program Infoとは、Program内容が一定である区間(Program Sequence)を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。Program Sequence情報を設けておくことの意義は、Program内容の変化点を、予め再生装置に通知するためである。ここでのProgram内容の変化点とは、ビデオストリームのPIDが変化したり、ビデオストリームの種類がSDTVからHDTVに変化している点等をいう。

続いてCharacteristic Point Infoについて説明する。図中の引き出し線cu2は、CPIの構成をクローズアップしている。引き出し線cu2に示すように、CPIは、Ne個のEP_map_for_one_stream_PID(EP_map_for_one_stream_PID[0]〜EP_map_for_one_stream_PID[Ne-1])からなる。これらEP_map_for_one_stream_PIDは、AVClipに属する個々のエレメンタリストリームについてのEP_mapである。EP_mapは、1つのエレメンタリストリーム上において、Access Unitが存在するエントリー位置のパケット番号(SPN_EP_start)を、エントリー時刻(PTS_EP_start)と対応づけて示す情報である。図中の引き出し線cu3は、EP_map_for_one_stream_PIDの内部構成をクローズアップしている。

これによると、EP_map_for_one_stream_PIDは、Nc個のEP_High(EP_High(0)〜EP_High(Nc-1))と、Nf個のEP_Low(EP_Low(0)〜EP_Low(Nf-1))とからなることがわかる。ここでEP_Highは、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの上位ビットを表す役割をもち、EP_Lowは、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPN_EP_start及びPTS_EP_startの下位ビットを示す役割をもつ。

図中の引き出し線cu4は、EP_Highの内部構成をクローズアップしている。この引き出し線に示すように、EP_High(i)は、EP_Lowに対する参照値である『ref_to_EP_Low_id[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの上位ビットを示す『PTS_EP_High[i]』と、Access Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの上位ビットを示す『SPN_EP_High[i]』とからなる。ここでiとは、任意のEP_Highを識別するための識別子である。

図中の引き出し線cu5は、EP_Lowの構成をクローズアップしている。引き出し線cu5に示すように、EP_Lowは、対応するAccess UnitがIDRピクチャか否かを示す『is_angle_change_point(EP_Low_id)』と、対応するAccessUnitのサイズを示す『I_end_position_offset(EP_Low_id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のPTSの下位ビットを示す『PTS_EP_Low(EP_Low_id)』と、対応するAccess Unit(Non-IDR Iピクチャ、IDRピクチャ)のSPNの下位ビットを示す『SPN_EP_Low(EP_Low_id)』とからなる。ここでEP_Low_idとは、任意のEP_Lowを識別するための識別子である。

＜Clip情報の説明その２.EP_map＞
以下、具体例を通じて、EP_mapについて説明する。図８は、映画のビデオストリームに対するEP_map設定を示す図である。第1段目は、表示順序に配置された複数のピクチャ(MPEG4-AVCに規定されたIDRピクチャ、Iピクチャ、Bピクチャ、Pピクチャ)を示し、第2段目は、そのピクチャにおける時間軸を示す。第4段目は、BD-ROM上のTSパケット列を示し、第3段目は、EP_mapの設定を示す。

第2段目の時間軸において、時点t1〜t7に、Access UnitとなるIDRピクチャ及びIピクチャが存在するものとする。そしてこれらのt1〜t7の時間間隔が、1秒程度であるとすると、映画に用いられるビデオストリームにおけるEP_mapは、t1〜t7をエントリー時刻(PTS_EP_start)として示し、これに対応づけてエントリー位置(SPN_EP_start)を示すよう、設定される。

＜PlayList情報＞
続いて、PlayList情報について説明する。拡張子“mpls”が付与されたファイル(00001.mpls)は、PlayList(PL)情報を格納したファイルである。

図９は、PlayList情報のデータ構造を示す図であり、本図において、引き出し線mp1に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())を含む。
＜PlayList情報の説明その１.MainPath情報＞
先ずMainPathについて説明する。MainPathは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。

MainPathは、矢印mp1で示すように複数のPlayItem情報#1・・・・#mから定義される。PlayItem情報は、MainPathを構成する1つの論理的な再生区間を定義する。PlayItem情報の構成は、引き出し線hs1によりクローズアップされている。この引き出し線に示すようにPlayItem情報は、再生区間のIN点及びOut点が属するAVClipの再生区間情報のファイル名を示す『Clip_Information_file_name』と、AVClipの符号化方式を示す『Clip_codec_identifier』と、PlayItemがマルチアングルを構成するか否かを示す『is_multi_angle』と、このPlayItemと、その1つ前のPlayItemとの接続を、シームレスに行うか否かを示す『connection_condition』と、このPlayItemが対象としているSTC_Sequenceを一意に示す『ref_to_STC_id[0]』と、再生区間の始点を示す時間情報『In_time』と、再生区間の終点を示す時間情報『Out_time』と、このPlayItemにおいてマスクすべきユーザオペレーションがどれであるかを示す『UO_mask_table』と、このPlayItemの途中へのランダムアクセスを許可するか否かを示す『PlayItem_random_access_flag』と、このPlayItemの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『Still_mode』と、『STN_table』とから構成される。このうち、再生経路を構成するのは、再生区間の始点を示す時間情報『In_time』、再生区間の終点を示す時間情報『Out_time』の組みであり、再生経路情報とは、この『In_time』及び『Out_time』の組みから構成される。

図１０は、AVClipと、PlayList情報との関係を示す図である。第1段目は、PlayList情報がもつ時間軸を示す。第2段目から第5段目は、EP_mapにて参照されているビデオストリームを示す。
PlayList情報は、PlayItem情報#1,#2という2つのPlayItem情報を含んでおり、これらPlayItem情報#1,#2のIn_time,Out_timeにより、2つの再生区間が定義されることになる。これらの再生区間を配列させると、AVClip時間軸とは異なる時間軸が定義されることになる。これが第1段目に示すPlayList時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる再生経路の定義が可能になる。

以上のClip情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のClip情報及びプレイリスト情報により、静的な再生単位であるプレイリストが定義されるからである。以上で静的シナリオについての説明を終わる。

続いて”動的なシナリオ”について説明する。動的シナリオとは、AVClipの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。BD-ROMでは、この再生制御の動作環境として2つのモードを想定している。1つ目は、DVD再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。2つ目は、Java（登録商標）仮想マシンの動作環境である。これら2つの動作環境のうち1つ目は、HDMVモードと呼ばれる。2つ目は、BD-Jモードと呼ばれる。これら2つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。HDMVモードを想定した動的シナリオはMovie Objectと呼ばれる。一方BD-Jモードを想定した動的シナリオはBD-J Objectと呼ばれる。

先ず初めにMovie Objectについて説明する。
＜Movie Object＞
Movie Objectは、図２に示したMovieObject.bdmvというファイルに格納され、ナビゲーションコマンド列を含む。
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Movie Objectにおいて記述可能なコマンドを以下に示す。

PlayPLコマンド
書式:PlayPL(第１引数，第２引数)
第１引数は、プレイリストの番号で、再生すべきプレイリストを指定することができる。第２引数は、そのプレイリストに含まれるPlayItemや、そのプレイリストにおける任意の時刻、Chapter、Markを用いて再生開始位置を指定することができる。

PlayItemによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatPlayItem()、
ChapterによりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatChapter()、
時刻情報によりPL時間軸上の再生開始位置を指定したPlayPL関数をPlayPLatSpecified Time()という。

Movie Objectにおけるナビゲーションコマンドの記述は、DVDにおけるナビゲーションコマンドの記述方式と良く似ているので、DVD上のディスクコンテンツを、BD-ROMに移植するという作業を効率的に行うことができる。Movie Objectについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。

国際公開公報W0 2004/074976

以上でMovie Objectについての説明を終える。続いてBD-JObjectについて説明する。

＜BD-J Object＞
BD-J Objectは、Ｊａｖａ（登録商標）プログラミング環境で記述された、BD-Jモードの動的シナリオであり、00001.bobjというファイルに格納される。Movie Objectとの違いは、BD-J Objectにコマンドが直接記述されていない点である。つまりMovie Objectにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しBD-J Objectでは、Ｊａｖａ（登録商標）アプリケーションに対する指定をアプリケーション管理テーブルに記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。

またMovieObjectにおけるプレイリスト再生は、プレイリスト再生を命じるナビゲーションコマンド(PlayPlコマンド)の記述によりなされるが、BD-J Objectにおけるプレイリスト再生は、プレイリスト再生手順を示すプレイリスト管理テーブルをBD-J Objectに組み込むことで記述が可能になる。
このBD-JモードにおけるＪａｖａ（登録商標）アプリケーションについて説明する。ここでBD-Jモードが想定しているＪａｖａ（登録商標）プラットフォームは、Ｊａｖａ（登録商標）2Micro_Edition(J2ME) Personal Basis Profile(PBP 1.0)と、Globally Executable MHP specification(GEM1.0.2)for package mediatargetsとをフル実装したものである。

このBD-JモードにおけるＪａｖａ（登録商標）アプリケーションは、xletインターフェイスを通じて、Application Managerにより、制御される。xletインターフェイスは、“loaded”,“paused”、“active”,“destoryed”といった4つの状態をもつ。
上述したＪａｖａ（登録商標）プラットフォームは、JFIF(JPEG)やPNG,その他のイメージデータを表示するためのスタンダードＪａｖａ（登録商標）ライブラリを含む。このため、Ｊａｖａ（登録商標）アプリケーションは、HDMVモードにおいてIGストリームにより実現されるGUIとは異なるGUIフレームワークを実現することができる。Ｊａｖａ（登録商標）アプリケーションにおけるGUIフレームワークは、GEM1.0.2にて規定されたHAViフレームワークを含み、GEM1.0.2におけるリモートコントロールナビゲーション機構を含む。

これにより、Ｊａｖａ（登録商標）アプリケーションは、HAViフレームワークに基づくボタン表示、テキスト表示、オンライン表示(BBSの内容)といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。
このＪａｖａ（登録商標）アプリケーションの実体にあたるのが、図２におけるBDMVディレクトリ配下のBDJAディレクトリに格納されたＪａｖａ（登録商標）アーカイブファイル(00001.jar)である。

BD-J Objectについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。

国際公開公報W0 2004/045840 A1
W0 2005/036555 A1
W0 2005/036546 A1

以上でBD-J Objectについての説明を終える。

＜sound.bdmv＞
続いてsound.bdmvについて説明する。sound.bdmvは、IGストリームにて描画されたメニューやＪａｖａ（登録商標）アプリケーションのGUIフレームワークに対して操作がなされた場合、クリック音として出力すべきオーディオデータ(かかるオーディオデータを、サウンドデータという)が格納されるファイルである。

図１１は、ファイルsound.bdmvの構成を示す図である。ファイルsound.bdmvは、Sound Data()と、Sound Index()とからなる。Sound Data()は、複数のサウンドデータ(sound_data(0),sound_data(1))からなる。これらのサウンドデータのうち、sound_data(0)は、メニューに対する操作時に、第１のクリック音として出力される音源である。sound_data(1)は、メニューに対する操作時に、第２のクリック音として出力される音源である。これらのサウンドデータは、sound_IDと呼ばれる識別子にて指示される。

Sound Index()は、サウンド数(number_of_sound_entries)、sound_data(0)に対するインデックス、sound_data(1)に対するインデックス等からなる。
インデックスは、モノラル/ステレオの別などの各サウンドの属性(sound_attributes)、対応するサウンドデータのアドレス(sound_data_start_address)、対応するサウンドデータの連続長(sound_data_length)からなる。

図２〜図６に示したように、映画の劇中に使用される音声の音源は、Primaryオーディオストリームとして、AVClip内に多重化される。これは、映画劇中の音声を表すPrimaryオーディオストリームを、ビデオストリームの読み出しと同時に再生装置に供給するためである。これに対し、ファイルsound.bdmvは、AVClipとは別個のファイルとしてBD-ROMに記録され、ユーザーのメニュー操作に対するクリック音を格納する。ファイルsound.bdmvは、AVClipとは別個のファイルとして記録されるので、AVClipの読み出し中に、サウンドデータを出力させようとすると、ファイルsound.bdmvを読み出すための光ピックアップのジャンプが生じ、AVClipの読み出しが中断せざるを得なくなる。かかる中断が生じれば、AVClip再生に途切れが出る。

かかるAVClipの再生途切れを避けるには、AVClipの再生がなされていない時点において、ファイルsound.bdmvを予めバッファにプリロードしておく必要がある。つまりAVClipの再生に先立ち、ファイルsound.bdmv内のサウンドデータを、プリロードしておく必要がある。以上がファイルsound.bdmvについての説明である。

＜Index.bdmv＞
Index.bdmvは、タイトルを構成する、MovieObject又はBD-J Objectを示すテーブルである。

Titleにおいて、あるTitleの構成要素となるMovieObjectはどれであるか、又は、あるTitleの構成要素となるBD-J Objectはどれであるのかを定義する。
Index.bdmvについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。

国際公開公報WO 2004/025651 A1公報

以上が、BD-ROM１００についての説明である。

＜ローカルストレージ２００＞
続いて、ローカルストレージ２００について説明する。図１２は、ローカルストレージ２００の内部構成を示す図である。本図に示すように、本発明に係る記録媒体は、応用層に対する改良により、生産することができる。
本図の第４段目にローカルストレージ２００を示し、第３段目にローカルストレージ２００上のトラックを示す。本図のトラックは、ローカルストレージ２００の内周から外周にかけて螺旋状に形成されているトラックを、横方向に引き伸ばして描画している。このトラックは、リードイン領域と、ボリューム領域と、リードアウト領域とからなる。本図のボリューム領域は、物理層、ファイルシステム層、応用層というレイヤモデルをもつ。ディレクトリ構造を用いてローカルストレージ２００の応用層フォーマット(アプリケーションフォーマット)を表現すると、図中の第1段目のようになる。

本図のディレクトリ構造においてROOTディレクトリの配下には、「organization#1」というサブディレクトリがあり、その配下に、「disc#1」というサブディレクトリがある。ディレクトリ「organization#1」とは、映画作品の特定のプロバイダに割り当てられたディレクトリである。「disc#1」は、そのプロバイダが提供したBD-ROMのそれぞれに割り当てられたディレクトリである。

特定のプロバイダに対応するディレクトリに、各BD-ROMに対応するディレクトリを設けることにより、各BD-ROMについてのダウンロードデータが個別に格納される。このサブディレクトリの配下に、BD-ROMに格納されていたのと同様、PlayList情報(00002.mpls)、Clip情報(00002.clpi)、AVClip(00002.m2ts),BD-J Object(00002.bobj),Ｊａｖａ（登録商標）アーカイブファイル(00002.jar),クリック音データ(sound.bdmv),MovieObject.bdmvが格納されている。

続いて、ローカルストレージ２００の構成要素となる、PlayList情報、Clip情報、AVClipについての説明する。
＜ローカルストレージ２００の構成その１.AVClip＞
ローカルストレージ２００上のAVClip(00002.m2ts)は、SubClipを構成する。SubClipとは、MainClipと同時にデコードされ再生されるエレメンタリストリームを含むAVClipである。かかるSubClipには、『Primaryオーディオストリーム』、『Secondaryオーディオストリーム』、『PresentationGraphics(PG)ストリーム』、『Interactive Graphics(IG)ストリーム』といった種別がある。(以後、SubClipのことをOut-of-MUXストリームと呼ぶことがある。)
本実施形態では、図１２に示した00002.m2tsは、Secondaryオーディオストリーム、PGストリーム、IGストリームが1つのSubClipに多重化されているものとする。以降Secondaryオーディオストリームの詳細を説明する。

＜Out-of-MUXストリームの説明その１.Secondaryストリーム＞
『Primaryオーディオストリーム』が、いわゆる主音声となるオーディオストリームであるのに対し、『Secondaryオーディオストリーム』とは、いわゆる副音声となるオーディオストリームである。SubClip再生時において、Secondaryオーディオストリームの音声再生は、Primaryオーディオストリームの再生音声にミキシングされた上で出力に供される。Secondaryオーディオストリームとして扱われる音声には、例えば“コメンタリ音声”がある。Primaryオーディオストリームとなる主音声が、映画作品本編の音声であり、Secondaryオーディオストリームとなる副音声が、映画監督のコメンタリ音声である場合、かかる映画作品本編の音声は、コメンタリ音声がミキシングされた上で出力されることになる。

Secondaryオーディオストリームは、ローカルストレージ２００にのみ記録され再生に供されるが、BD-ROMには記録されない。Primaryオーディオストリームは、BD-ROMに置かれていても、ローカルストレージ２００に置かれていてもよい。またPrimaryオーディオストリームの符号化コーディックは、Secondaryオーディオストリームの符号化コーディックと異なっていてもよい。

図１３は、SubClipに多重化されるエレメンタリストリームを示す図である。SubClipには、0x1200から0x121FまでのPIDをもつPGストリーム、0x1400から0x141FまでのPIDをもつIGストリームのほかに、0x1A00から0x1A1FまでのPIDをもつSecondaryオーディオストリームが多重化される。ここでSubClipにおけるPGストリーム、IGストリームのPIDは、MainClipにおけるPGストリーム、IGストリームのPIDと同じになっているものの、SecondaryオーディオストリームのPIDは、上位バイトが異なるため、32本のSecondaryオーディオストリームのPIDは、32本のPrimaryオーディオストリームのPIDと、一切重複していない。

図１４は、BD-ROM規格におけるPID割当マップを示す図である。本図によれば、0x0100は、Program_mapに割り当てられ、0x1001はPCRに、0x1011はビデオストリームに、0x1100から0x111FまでのゾーンはPrimaryオーディオストリームに、0x1200から0x121FまでのゾーンはPGストリームに、0x1400から0x141FまでのゾーンはIGストリームに、0x1A00から0x1A1FまでのゾーンはSecondaryオーディオストリームに割り当てられている。このPID割当マップからもわかるように、Primaryオーディオストリームに割り当てられているゾーンと、Secondaryオーディオストリームに割り当てられているゾーンとが異なっていることがわかる。

図１５（ａ）は、Secondaryオーディオストリームの内部構成を示す図である。
本図に示すように、Secondaryオーディオストリームは、複数のオーディオフレームからなる。図１５（ｂ）は、オーディオフレームの一例を示す図である。Secondaryオーディオストリームのオーディオフレームは、メタデータを含む。
図１５（ｃ）は、メタデータの内部構成を示す図である。メタデータは、本図に示すように、“ダウンミキシング情報”と、“ゲイン制御情報”とからなる。

“ダウンミキシング情報”は、ダウンミキシングのための情報である。ダウンミキシングとは、音声の再生チャネル数を符号化チャンネル数よりも少なくする変換であり、ダウンミキシング情報は、ダウンミキシングのための変換係数行列を規定することにより、このダウンミキシングを再生装置に行わせる。5.1chの音声ストリームを2chで再生することなどがダウンミキシングの一例である。

“ゲイン制御情報”とは、Primaryオーディオストリーム側の音声出力時のゲインを上げ下げする情報であるが、ここでは下げるだけでよい。図１５（ｄ）は、ゲイン制御情報の一例を模式的に示す。このようにSecondaryオーディオストリームのメタデータは、同時に再生されるPrimaryオーディオストリームの出力をリアルタイムに下げることができる。PrimaryオーディオとSecondaryオーディオを重畳する場合には、あらかじめミキシングされるPrimaryオーディオとSecondaryオーディオの対が分かっているため、2本のオーディオのゲインをリアルタイムに制御する必要は無く、Primaryオーディオのゲインだけを下げてSecondaryオーディオのゲインはそのままにミキシング(重畳)することで十分である。

尚、ゲイン制御情報は、PlayListMarkのmark_time_stampに指定される時刻より、durationの時間だけ、有効なゲイン制御情報を格納するようにしても良い。
図１６は、Secondaryオーディオストリーム内のメタデータにより、Primaryオーディオストリームの音量がどのように制御されるかを示す図である。本図における第1段目は、時間軸を示し、第2段目は、ミキシング可能なPrimaryオーディオストリームの再生出力を示す。第3段目は、Secondaryオーディオストリームの再生出力を示し、第4段目は、Secondaryオーディオストリームに多重化されたメタデータを示す。

再生時刻t1にあたるオーディオフレームに配置されたメタデータは、Primaryオーディオストリームの再生出力の音量を全体的に抑えるものであり、再生時刻t2にあたるオーディオフレームに配置されたメタデータは、Primaryオーディオストリームの再生出力の音声を元に戻すものである。再生時刻t1,t2に、かかるメタデータを配置することで、Primaryオーディオストリームとの再生出力の音量と、Secondaryオーディオストリームの再生出力の音量とが合わさり、スピーカを破損させてしまうという事態を避けることができる。
Secondaryオーディオの"ゲイン制御情報“を使ってリアルタイムにミキシングのゲイン調整を行なう場合には、t1からt2までのSecondaryオーディオの各オーディオフレームに格納された”ゲイン制御情報“がPrimaryオーディオのゲインを所定の量だけ下げることを指定していれば良い。特殊再生などでt1からt2の間に飛び込んでミキシング再生を行なうことを想定すれば、常に適切なゲイン制御が可能なこちらの方法の方が都合が良い。

＜ローカルストレージ２００の構成その２.PlayList情報＞
続いて、ローカルストレージ２００上のPlayList情報について説明する。拡張子“mpls”が付与されたファイル(00002.mpls)は、MainPath、Subpathと呼ばれる2種類の再生経路を束ねたものをPlaylist(PL)として定義する情報である。図１７は、PlayList情報のデータ構造を示す図であり、本図に示すようにPlayList情報は、MainPathを定義するMainPath情報(MainPath())と、チャプターを定義するPlayListMark情報(PlayListMark())と、Subpathを定義するSubpath情報(Subpath())とからなる。かかるPlayList情報の内部構成、及び、PlayItem情報の内部構成は、BD-ROMのものと同じであり、説明を省略する。

＜PlayList情報の説明その１.Subpath情報＞
MainPathが、主映像たるMainClipに定義される再生経路であるのに対し、Subpathは、MainPathと同期すべきSubClipに対して定義される再生経路である。

図１８は、Subpath情報の内部構成をクローズアップして示す図である。本図における矢印hc0に示すように各Subpathは、SubClipの類型を示すSubPath_typeと、1つ以上のSubPlayItem情報(・・・SubPlayItem()・・・)とを含む。
図中の引き出し線hc1は、SubPlayItem情報の構成をクローズアップしている。SubPlayItem情報は、図中の矢印hc1に示すように『Clip_information_file_name』、『Clip_codec_identifier』、『ref_to_STC_id[0]』、『SubPlayItem_In_time』、『SubPlayItem_Out_time』、『sync_PlayItem_id』、『sync_start_PTS_of_PlayItem』からなる。

『Clip_information_file_name』は、Clip情報のファイル名を記述することにより、SubPlayItemに対応するSubClipを一意に指定する情報である。
『Clip_codec_identifier』は、AVClipの符号化方式を示す。
『ref_to_STC_id[0]』は、このPlayItemが対象としているSTC_Sequenceを一意に示す。
『SubPlayItem_In_time』は、SubClipの再生時間軸上における、SubPlayItemの始点を示す情報である。

『SubPlayItem_Out_time』は、SubClipの再生時間軸上における、SubPlayItemの終点を示す情報である。
『sync_PlayItem_id』は、MainPathを構成するPlayItemのうち、本SubPlayItemが同期すべきものを一意に指定する情報である。SubPlayItem_In_timeは、このsync_PlayItem_idで指定されたPlay Itemの再生時間軸上に存在する。

『sync_start_PTS_of_PlayItem』は、sync_PlayItem_idで指定されたPlay Itemの再生時間軸上において、SubPlayItem_In_timeで指定されたSubPlayItemの始点が、どこに存在するかを示す。
＜Subpath情報の詳細その１.SubPath_type＞
以上がSubPath情報についての説明である。続いてSubPath_typeについて説明する。SubPath_typeは、0から255までの値に設定されることにより、SubPath情報により定義されるSubPathがどのような再生経路であるのかを示す。

SubPath_typeが5に設定されている場合、このSubPath情報により定義されるSubPathは、Primaryオーディオ再生パスであることを示す。このPrimaryオーディオ再生パスは、MainPath(PlayItem)にて参照されるPrimaryオーディオに置き換えて再生されるべきオーディオストリームがSubPath(SubPlayItem)内に格納されているときに使われる。
SubPath_typeが6に設定された場合、本SubPath情報は、追加・置換のためのPresentation Graphics再生パスを定義していることを示す。何に対する追加・置換であるかというと、PlayItem情報にて再生され得るPGストリームに対して、追加・置換され得るPGストリームである。

SubPath_typeが7に設定された場合、本SubPath情報は、追加・置換のためのIntaractive Graphics再生パスを定義していることを示す。何に対する追加・置換であるかというと、PlayItem情報にて再生され得るIGストリームに対して、追加・置換され得るIGストリームである。
SubPath_typeが8に設定された場合、SubPath情報はSecondaryオーディオ再生パスを定義する旨を示す。このSecondaryオーディオ再生パスは、追加のために定義されている。何に対する追加かというと、PlayItem情報にて再生され得るPrimaryオーディオの再生音声にミキシングされるべきSecondaryオーディオである。
例えば、PrimaryオーディオとSecondaryオーディオのミキシング再生を行う場合には、２つのオーディオデコーダとミキサーを動作させる必要があるため、通常のPrimaryオーディオだけを再生する場合とは要求が異なり、前もってプレイヤがどのような再生タイプかを取得できる必要がある。このために、SubPath_typeやSTN_tableのPIDによって、同期再生すべきSecondaryオーディオが存在することを再生前にプレイヤに通知することが可能となる。

以上がSubPath_typeについての説明である。
＜SubPath情報についての詳細その２.三者の関係＞
ここでの三者とは、ローカルストレージ２００上のSubClip、ローカルストレージ２００上のPlayList情報、BD-ROM上のMainClipの三者をいう。
図１９は、ローカルストレージ２００上のSubClipと、ローカルストレージ２００上のPlayList情報と、BD-ROM上のMainClipとの対応を示す図である。本図において第1段目は、ローカルストレージ２００上に存在するSubClipを示す。この第1段目に示すように、ローカルストレージ２００上のSubClipには、Secondaryオーディオストリーム、PGストリーム、IGストリームといった種別がある。これらのうち何れかが、SubPathとして同期再生に供されることになる。

第2段目は、PlayList情報により定義される2つの時間軸を示す。第2段目のうち下側の時間軸は、PlayItem情報により定義されるPlayItem時間軸を示し、上側の時間軸はSubPlayItemにより定義されるSubPlayItem時間軸を示す。
本図に示すように、SubPlayItem情報のSubPlayItem_Clip_information_file_nameは、STREAMディレクトリに格納された.m2tsファイルのうち、どれを再生区間指定の対象として選ぶかという、SubClip選択の役割を果たしていることがわかる。

そしてSubPlayItem.IN_time、SubPlayItem.Out_timeは、SubClip上の、再生区間の始点及び終点を定義するという役割を果たしていることがわかる。
矢印Sync_PlayItem_Idは、どのPlayItemとの同期を意図しているかという同期指定の役割を果たし、sync_start_PTS_of_PlayItemは、PlayItem時間軸上におけるSubPlayItem_In_timeの位置を決める役割を果たす。

図２０は、MainClipに対して設定されたEP_map及びPlayItem時間軸と、SubClipに対して設定されたEP_map及びSubPlayItem時間軸とを集約して示す図である。
本図の中段、下4段〜下1段は、図１０に示したPlayItem時間軸、ピクチャ列、MainClip時間軸、EP_map、TSパケット列を示す。
また上1段目〜上3段目は、TSパケット列、EP_map、SubClip時間軸を示す。上4段目は、SubPlayItem時間軸を示す。

以上が、SubPath情報についての説明である。
＜STN_table＞
このローカルストレージ２００におけるPlayList情報において特徴的であるのは、STN_Tableである。以降、ローカルストレージ２００上のPlayList情報について説明する。
STN_tableは、PlayItem情報のClip_Information_file_nameで指定されているAVClipに多重化された複数エレメンタリストリーム、SubPlayItem情報のClip_Information_file_nameで指定されているOut_of_MUXストリームのうち、再生可能なものを示すテーブルである。具体的にいうとSTN_tableは、MainClipに多重化されている複数エレメンタリストリーム、SubClipに多重化されているOut_of_MUXストリームのそれぞれについてのStream_entryを、Stream_attributeと対応付けることで構成される。

図２１は、STN_tableの内部構成を示す図である。本図に示すようにSTN_tableは、STN_tableにおけるentryと、attributeとの組み(entry-attribute)を複数含み、これらentry−attributeの組みの個数(number_of_video_stream_entries,number_of_audio_stream_entries,number_of_PG_stream_entries,number_of_IG_stream_entries)を示すデータ構造になっている。

entry-attributeの組みは、図中の括弧記号”｛”に示すように、Play Itemにおいて再生可能なビデオストリーム、Primaryオーディオストリーム、Secondaryオーディオストリーム、PGストリーム、IGストリームのそれぞれに対応している。特に注意すべきは、SecondaryオーディオストリームにおけるStream_entryと、Stream_attributeとの組みが、Comb_info_Secondary_audio_Primary_audioと対応付けられている点である。

entry−attributeの詳細について説明する。

図２２（ａ）は、ビデオストリームに対応したStream_attributeを示す図である。
ビデオストリームにおけるStream_attributeは、ビデオストリームの表示方式を示す『Video_format』と、ビデオストリームの表示周波数を示す『frame_rate』等を含む。
図２２（ｂ）は、Primaryオーディオストリーム、Secondaryオーディオストリームに対応したStream_attributeを示す図である。

Primaryオーディオストリーム,SecondaryオーディオストリームにおけるStream_attributeは、オーディオストリームの符号化方式を示す『stream_coding_type』と、対応するオーディオストリームのチャネル構成を示す『audio_presentation_type』と、対応するオーディオストリームのサンプリング周波数を示す対応する『Sampling_frequency』と、オーディオストリームの言語属性を示す『audio_languagecode』からなる。

図２２（ｃ）は、ビデオストリームにおけるStream_entryを示す図である。本図に示すように、ビデオストリームのStream_entryは、ビデオストリームの多重分離に用いられるPIDを示す「ref_to_Stream_PID_of_Main_Clip」を含む。
MainClipにて多重化されているPrimaryオーディオストリーム、IGストリーム、PGストリームのStream_attributeは、この図２２（ｃ）の形式になっている。

図２２（ｄ）は、SubClipにて多重化されているストリーム(以下Secondaryオーディオストリームとして説明)におけるStream_entryを示す図である。SecondaryオーディオストリームのStream_entryは、Secondaryオーディオストリームを参照しているSubPath情報を示す『ref_to_Sub_Path_id』、Secondaryオーディオストリームが多重化されているSubClipを示す『ref_to_Sub_Clip_entry_id』、Secondaryオーディオストリームの多重分離に用いられるPIDを示す『ref_to_stream_PID_of_Sub_Clip』を含む。

図２２（ｅ）は、SecondaryオーディオストリームにおけるStream_entryと、Stream_attributeとの組みに対応付けられている、Comb_info_Secondary_audio_Primary_audioの内部構成を示す。Comb_info_Secondary_audio_Primary_audioは、各Secondaryオーディオストリームごとに組合せ可能なPrimaryオーディオストリームの総数を示すnumber_of_primary_audio_stream_ref_entriesと、再生時に組合せることができるPrimaryオーディオストリームのストリーム番号を示すPrimary_audio_stream_id_ref[0]〜[n]とからなる。

図２３は、Comb_info_Secondary_audio_Primary_audioによるPrimaryオーディオストリームの指定を示す図である。ここで本図の右側は、32本のSecondaryオーディオストリームを示し、左側は、32本のPrimaryオーディオストリームを示す。そして矢印ym1は、Secondaryオーディオストリーム#1におけるComb_info_Secondary_audio_Primary_audioによる指定を示す。このようにSecondaryオーディオストリーム毎に設定されるComb_info_Secondary_audio_Primary_audioは、そのSecondaryオーディオストリームの再生出力をミキシングすることができる1つ以上のPrimaryオーディオストリームを一意に指定する。これにより、所定の属性を有しているようなPrimaryオーディオストリームの再生時においては、Secondaryオーディオストリームをミキシングさせず、それ以外の属性を有しているようなPrimaryオーディオストリームの再生時においてのみ、Secondaryオーディオストリームをミキシングするというような、音声属性に応じた、ミキシングの可否を、オーサリング時に設定しておくことができる。

以上がローカルストレージ２００の構成たるPlayList情報についての説明である。以上で、ローカルストレージ２００についての説明を終える。

＜バーチャルパッケージ＞
以降、バーチャルパッケージについて説明する。図２４は、再生装置３００により生成されるバーチャルパッケージを示す図である。本図の左上は、BD-ROMの記録内容を示し、左下は、ローカルストレージ２００の記録内容を示す。右側は、バーチャルパッケージの構成を示す。

再生装置は、BD-ROMに存在するAVClip、Clip情報、PlayList情報に、ローカルストレージ２００に存在するAVClip、Clip情報、PlayList情報を組み合わせて、仮想的な１つのBD-ROMディスクイメージ（バーチャルパッケージ）を得る。
この組合せは、
i)Local Storage上のPlayList(00002.mpls)を、BD-ROMにおけるMPLSディレクトリに仮想的に追加し、

ii)Local Storage上のClip情報#2(00002.clpi)を、BD-ROMにおけるCLPIディレクトリに仮想的に追加し、

iii)Local Storage上のAVClip#2(00002.m2ts)を、BD-ROMにおけるSTREAMディレクトリに仮想的に追加することでなされる。

こうすることにより、図２４の右側に示すようなバーチャルパッケージが構成される。
以上が記録媒体についての説明である。続いて本発明に係る再生装置について説明する。
図２５は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置という2つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BD-ROMドライブ１a、バス１b、リードバッファ２a,b、デマルチプレクサ３a,b、ビデオデコーダ４、ビデオプレーン５、バッファ６a,b、オーディオデコーダ７a,b、DownMix/DownSample８、ミキサー９a、ミキサー９b、スイッチ１０a、エンコーダ１０b、Interactive Graphicsデコーダ１１、Interactive Graphicsプレーン１２、PresentationGraphicsデコーダ１３、Presentation Graphicsプレーン １４、JPEGデコーダ１５、Stillプレーン１６、合成部１７、STC生成部１８a,b、ATC生成部１９a,b、メモリ２１、コントローラ２２、PSRセット２３、PID変換部２４、通信部２５、操作受付部２６、HDMI送受信部２７から構成される。

BD-ROMドライブ１aは、BD-ROMのローディング／イジェクトを行い、BD-ROMディスクに対するアクセスを実行する。
バス１bは、BD-ROMから読み出されたTSパケット、ローカルストレージ２００から読み出されたTSパケットが転送される。
リードバッファ２aは、FIFOメモリであり、BD-ROMディスク１００またはローカルストレージ２００から読み出されたTSパケットが先入れ先出し式に格納される。

リードバッファ２bは、FIFOメモリであり、ローカルストレージ２００から読み出されたTSパケットが先入れ先出し式に格納される。
デマルチプレクサ３aは、バスに伝送しているTSパケットのうち、0x1011,0x1100〜0x111F,0x1200〜0x121F,0x1400〜141FのPIDをもつTSパケットのうち、PID変換部２４から通知されたPIDをもつものを、夫々ビデオデコーダ４、オーディオデコーダ７a、Interactive Graphicsデコーダ１１、PresentationGraphicsデコーダ１３に出力する。

デマルチプレクサ３bは、バス１bに伝送しているTSパケットのうち、0x1A00〜0x1A1FのPIDをもつもの、即ち、Secondaryオーディオストリームを構成するTSパケットの多重分離を行う。デマルチプレクサ３bによるSecondaryオーディオストリームの多重分離は、STN_tableに含まれるSecondaryオーディオストリームのstream_entryのうち、PSR14に格納されているストリーム番号に対応するものに記述されているPIDの参照値と、バス１bに転送されているTSパケットのPIDとを比較し、当該比較において一致するPIDをもつTSパケットを、バッファ６ｂを介してオーディオデコーダ７bに出力することでなされる。再生可能なSecondaryオーディオストリームが1つだけである場合、上述した比較は、stream_entryに記述されているPID参照値の上位バイト“1A”と、バス１bに転送されているTSパケットのPIDの上位バイト“1A”との比較で足りる。何故なら、他にSecondaryオーディオストリームが存在しないので、Secondaryオーディオストリームであることを意味するPID上位バイトを参照すれば充分だからである。

再生可能なSecondaryオーディオストリームが複数存在する場合、上述した比較は、stream_entryに記述されているPID参照値の上位バイト“1A”と、バス１bに転送されているTSパケットのPIDの上位バイト“1A”との比較に加え、stream_entryに記述されているPID参照値の下位バイト(0x00から0x1Fまでの数値)と、バス１bに転送されているTSパケットのPIDの下位バイト(0x00から0x1Fまでの数値)との比較が必要になる。何故なら、Secondaryオーディオストリームが複数存在するので、再生すべきSecondaryオーディオストリームを一意に特定するように、PIDの下位バイトまで参照する必要があるからである。

ここでバス１bには、BD-ROMから読み出されたTSパケット、ローカルストレージ２００から読み出されたTSパケットが転送されているので、デマルチプレクサ３a、デマルチプレクサ３bは、これらBD-ROMから読み出されたTSパケット、ローカルストレージ２００から読み出されたTSパケットを、1本のトランスポートストリームとして扱ってバッファに取り込むことができる。Primaryオーディオストリームを構成するTSパケット、Secondaryオーディオストリームを構成するTSパケットに割り当てられているPIDは、PID割当マップにおいて、異なるゾーンに存在しているのでデマルチプレクサ３a、デマルチプレクサ３bは、これらを1つとして、取り込みつつもこれらPrimaryオーディオストリーム、Secondaryオーディオストリームを別々のエレメンタリストリームとして出力することができる。この際、デマルチプレクサ３a、デマルチプレクサ３bは、1つのトランスポートストリームに多重化されている複数のオーディオストリームを多重分離するのと同じ手順を経ることにより、デコーダに供給することができるので、1つのトランスポートストリームから所定のPIDを持つTSパケットだけを多重分離するようなデマルチプレクサと互換を保つ構成で、Primaryオーディオストリーム、Secondaryオーディオストリームを、該当するデコーダに供給することができる。

尚、実装上デマルチプレクサを１つに集約することが考えられる。この場合にもPrimaryオーディオとSecondaryオーディオのPIDが異なることが同様に有効である。
以上が、BD-ROMドライブ１a、バス１b〜デマルチプレクサ３a、デマルチプレクサ３bについての説明である。
ビデオデコーダ４は、デマルチプレクサ３ａから出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。

ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は1920×1080であり、このビデオプレーン５に格納されたピクチャデータは、16ビットのYUV値で表現された画素データにより構成される。

バッファ６aは、デマルチプレクサ３aから出力された、PID=0x1100〜111Fのうち再生されるべきオーディオストリームのPIDを有するTSパケットを、先入れ先だし式に格納して、オーディオデコーダ７aに供する。
バッファ６bは、デマルチプレクサ３ｂから出力された、PID=0x1A00〜1A1Fを有するTSパケットのうち再生されるべきオーディオストリームのPIDを有するTSパケットのみを、先入れ先だし式に格納して、オーディオデコーダ７bに供する。

バッファ６cは、BD-ROM/ローカルストレージから読み出されたファイルsound.bdmvをプリロードしておくためのメモリである。バッファ６cへのプリロードは、BD-ROMのローディング時やタイトル切替時に行うことが望ましい。何故なら、AVClipの再生中にファイルsound.bdmvを読み出そうとすると、AVClipとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、BD-ROMの装填時やタイトル切替時には、AVClipの再生が継続していることは希なので、かかるタイミングにファイルsound.bdmvを読み出すことにより、機器の応答性を高めAVClip再生が途切れにくくすることができる。

オーディオデコーダ７aは、バッファ６aに格納されたTSパケットをPESパケットに変換して、このPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりPrimaryオーディオストリームにおけるデジタル出力がなされる。
オーディオデコーダ７bは、バッファ６bに格納されたTSパケットをPESパケットに変換して、このPESパケットに対しデコード処理を行い、非圧縮状態のLPCM状態のオーディオデータを得て出力する。これによりSecondaryオーディオストリームにおけるデジタル出力がなされる。

DownMix/DownSample８は、ミキシングを行うにあたって、オーディオデコーダ７aから出力されたデジタルオーディオの音声属性を、オーディオデコーダ７bから出力されるデジタルオーディオの音声属性に合わせるための変換を施す。ここで音声属性とは、サンプリング周波数かつ/またはチャンネル数であり、これらを整合させる処理がなされる。またDownMix/DownSample８もしくはミキサー９ａは、Secondaryオーディオストリームに多重化されている、メタデータに従い、Primaryオーディオストリーム側のゲインを下げたりする処理もオーディオデコーダ７ｂが抽出したゲイン制御情報によって行う。

ミキサ９aは、オーディオデコーダ７aから出力されるLPCM状態のデジタルオーディオと、オーディオデコーダ７bから出力されるLPCM状態のデジタルオーディオとをミキシングする。

ミキサ９bは、ミキサ９aから出力されるLPCM状態のデジタルオーディオと、バッファ６cに格納されているサウンドデータとをミキシングする。このサウンドミキサ９bによるミキシングは、クリック音の発音を意図したようなナビゲーションコマンド、又は、クリック音の発音を意図したようなバイトコードを、CPU２２が解読することでなされる。
スイッチ１０aは、デマルチプレクサ３aにより多重分離がなされた、Primaryオーディオストリームを構成するTSパケット、デマルチプレクサ３bにより多重分離がなされたSecondaryオーディオストリームを構成するTSパケットを、オーディオデコーダ７a,bに供給するか、オーディオデコーダ７a,bに供給せずそのエレメンタリーストリームだけを他機器に出力するか切り換えるスイッチである。Primaryオーディオストリームを構成するTSパケットを、オーディオデコーダ７a,bに供給せずそのエレメンタリーストリームを他の機器に出力することを“パススルー出力”という。TSパケットからエレメンタリーストリームへの変換部（TS/PESヘッダの除去を行う）はスイッチ１０ａに組み込まれている。（図示はしていない）
エンコーダ１０bは、オーディオデコーダ７a,bのデコードにより得られ、ミキサー９a、ミキサー９bによるミキシングがなされたLPCM状態のオーディオデータを、サラウンド音声としてS/PDIFのようなデジタルインターフェース上で送る場合、ミキシングされたLPCMをDolby Digital(DD)形式やDolby Theater System(DTS)形式に圧縮符号化する。

Interactive Graphics(IG)デコーダ１１は、BD-ROM１００又はローカルストレージ２００から読み出されたIGストリームをデコードして、非圧縮グラフィクスをIGプレーン１２に書き込む。
Interactive Graphics(IG)プレーン１２は、IGデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。またBD-Jモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。

Presentation Graphics(PG)デコーダ１３は、BD-ROM又はローカルストレージ２００から読み出されたPGストリームをデコードして、非圧縮グラフィクスをPresentation Graphicsプレーン１４に書き込む。PGデコーダ１３によるデコードにより、字幕が画面上に現れることになる。
Presentation Graphics(PG)プレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。

JPEGデコーダ１５は、BD-ROM又はローカルストレージ２００に記録されているJPEGデータをデコードして、Stillプレーン１６に書き込む。
Stillプレーン１６は、JPEGデータを展開することで得られた非圧縮のグラフィクスデータが格納されるプレーンである。このグラフィクスデータは、Ｊａｖａ（登録商標）アプリが描画する、GUIフレームワークのいわゆる“壁紙”として用いられる。

合成部１７は、Interactive Graphicsプレーン１２の格納内容と、Presentation Graphicsプレーン１４の格納内容と、ビデオプレーン５の格納内容と、Stillプレーン１６の格納内容とを合成した合成画像を得る。
STC生成部１８a,bは、コントローラ２２の指示によってSystem Time Clock(STC)を生成し各デコーダの動作タイミングを調整する。

ATC生成部１９a,bは、コントローラ２２の指示によってArrival Time Clock(ATC)を生成しデマルチプレクサの動作タイミングを調整する。 メモリ２１は、カレントのPL情報やカレントのClip情報を格納しておくためのメモリである。カレントPL情報とは、BD-ROMに記録されている複数PlayList情報のうち、現在処理対象になっているものをいう。カレントClip情報とは、BD-ROM/ローカルストレージに記録されている複数Clip情報のうち、現在処理対象になっているものをいう。

コントローラ２２は、MovieObject.bdmvに格納されているMovie Objectや、BD-J Objectにて参照されているＪａｖａ（登録商標）アプリケーションを解読し、この解読結果に従ったプレイリスト再生(カレントPlayList情報に従った再生制御のことである）を実行することで、BD-ROMの再生制御を実現する。また上述のようなATS、STCの制御も行なう。
PSRセット２３は、再生装置に内蔵されるレジスタであり、64個のPlayer Setting/Status Register(PSR)と、4096個のGeneral Purpose Register（GPR)とからなる。Player Setting/Status Registerの設定値(PSR)のうち、PSR4〜PSR8は、現在の再生時点を表現するのに用いられる。

PID変換部２４は、PSRセット２３に格納されているPrimaryオーディオストリーム、Secondaryオーディオストリームのストリーム番号を、STN_Tableに基づき、PIDに変換して、変換結果たるPIDをデマルチプレクサ３a、デマルチプレクサ３bに指示する。
通信部２５は、読出装置における通信機能を実現するものであり、BD-JモードにおいてURL指定がＪａｖａ（登録商標）アプリケーションから与えられれば、そのURLにあたるwebサイトとのTCPコネクション、FTPコネクション等を確立する。かかるコネクション確立によりwebサイトからのダウンロードをＪａｖａ（登録商標）アプリケーションに行わせる。

操作受付部２６は、リモコンに対してなされた操作をユーザから受け付け、そうした操作を示すUserOperation情報をコントローラ２２に通知する。
HDMI送受信部２７は、HDMI（HDMI:High Definition Multimedia Interface）を介して接続された他の機器から、その機器に関する情報を受信とすると共に、ビデオデコーダ４のデコードにより得られたデジタル非圧縮のビデオを、LPCMや圧縮されたオーディオデータと共に、HDMIを介して接続された他の機器に送信する。

以上が、本実施形態に係る再生装置のハードウェア構成である。続いて本実施形態に係る再生装置のソフトウェア構成について説明する。
図２５に示したコントローラ２２を、機能的に表現すると、図２６のようになる。図２６は、コントローラ２２を機能的に表現した図であり、本図に示すようにコントローラ２２は、プレイリスト処理部４１、Procedure実行部４２、Procedure実行部４３、ミキシング制御部４４、ATC生成部１９a,b、STC生成部１８a,bに対して、ATC/STCの生成を行わせるATC/STC制御部から構成される。

これらの構成要素の処理は、PSRセット２３に基づく。以降、PSR1、PSR14、PSR31について説明する。
＜PSR1＞
図２７（ａ）は、PSR1のビットアサインを示す図である。
本図によると、32ビット長のPSR1の下位8ビット(b0〜b7)は、ストリーム番号であり、カレントPlay ItemのSTN_tableにentryが記述されている複数Primaryオーディオストリームのうち、1つを特定する。PSR1の設定値が変化すれば、再生装置はこの変化後のPrimaryオーディオストリームを再生する。PSR1は初期値として0xFFが設定されており、再生装置により1〜32の値に設定されうる。この0xFFは、不定値であり、Primaryオーディオストリームが存在しない旨、又は、Primaryオーディオストリームが選択されてない旨を示す。1〜32の設定値は、Primaryオーディオストリームのストリーム番号として解釈される。

＜PSR14＞
図２７（ｂ）は、PSR14のビットアサインを示す図である。
本図によると、32ビット長のPSR14における下位8ビット(b0〜b7)は、ストリーム番号であり、カレントPlay ItemのSTN_tableにentryが記述されている複数Secondaryオーディオストリームのうち、1つを特定する。PSR14の設定値が変化すれば、再生装置はこの変化後のSecondaryオーディオストリームを再生する。PSR14は初期値として0xFFが設定されており、再生装置により1〜32の値に設定されうる。この0xFFは、不定値であり、Secondaryオーディオストリームが存在しない旨、又は、Secondaryオーディオストリームが選択されてない旨を示す。1〜32の設定値は、Secondaryオーディオストリームのストリーム番号として解釈される。

＜PSR31＞
図２７（ｃ）は、PSR31のビットアサインを示す図である。
本図によると、32ビット長のPSR31のうち、16ビット目から19ビット目まで(b16〜b19)は、Player Profile情報であり、0000bであれば、当該再生装置は、グレースピリオド内に出荷された再生装置であることを示す。ここでグレースピリオドとは、この期間内に出荷されたなら、一定の機能の実装を省くことができる期間である。このグレースピリオドに出荷するため、省略することができる機能には、音声のミキシング機能があり、かかるPSR31のPlayer Profile情報が、0000bであれば、ミキシングを始めとする、様々な機能の実装が省略されている再生装置であると、知ることができる。

Player Profile情報が0001bであれば、当該再生装置は、グレースピリオド経過後に出荷された再生装置であることを示す。グレースピリオドの経過後に出荷された再生装置は、原則として、全ての機能の実装が義務付けられているので、かかるPlayer Profile情報が0001bであるなら、ミキシングが実装されている再生装置であると、知ることができる。

Player Profile情報が0011bであれば、当該再生装置は、全ての機能を実装している再生装置であることを示す。かかる再生装置は、グレースピリオドの経過前後にかかわらず、全ての機能を実装しているので、かかるPlayer Profile情報が0011bであるなら、サウンドミキシング機能が実装されている再生装置であると、知ることができる。
尚、ミキシング機能を示す情報として、再生装置がミキシングできるチャンネル数を示す情報をPSRに持たせても良い。

尚、最終の音声出力チャンネル数を示す情報をPSRに持たせても良い。例えばミキシングした結果の5.1chのLPCM音声はHDMIなどのI/Fが繋がっているのであればそのままLPCMでも出力が可能だが、S/PDIFのようなI/Fの場合にはエンコーダにて圧縮処理を行なわないと5.1chとしてはS/PDIFに出力できずに、2ch(L/R)の出力となってしまう。したがって、ミキサーの後段にエンコーダがありS/PDIFに繋がっている（例えばHDMIで繋がっていない）と判断した場合には、最終の音声出力チャンネル数は5.1chと設定できる。もしミキサーの後段にエンコーダがなければ、最終の音声出力チャンネル数はミキシングした後では2chと設定することができる。

以上が、PSRセット２３についての説明である。
以降、プレイリスト処理部４１〜Procedure実行部４３についての説明を開始する。
＜機能構成の詳細その１.プレイリスト処理部＞
プレイリスト処理部４１は、PL再生を実現するものであり、PlayItem情報のIn_timeにあたる位置から、Out_timeにあたる位置までビデオストリーム及びPrimaryオーディオストリームを再生し、これと同期して、SubPlayItem情報のSub_PlayItem_In_timeにあたる位置から、Sub_PlayItem_Out_timeにあたる位置までのSecondaryオーディオストリームの再生を、オーディオデコーダ７bに行わせる。

図２８は、プレイリスト処理部によるプレイリスト再生手順を示すフローチャートである。
本フローチャートは、カレントPL情報(.mpls)の読み込みを行い(ステップＳ１０１)、その後、ステップＳ１０２〜ステップＳ１１０の処理を実行するというものである。ここでステップＳ１０２〜ステップＳ１１０は、ステップＳ１０９がYesになるまで、カレントPL情報を構成するそれぞれのPI情報について、ステップＳ１０３〜ステップＳ１１０の処理を繰り返すというループ処理を構成している。このループ処理において処理対象となるPlayItemを、PlayItem#x(PI#x)とよぶ。このPlayItem#xは、カレントプレイリストの先頭のPlayItemに設定されることにより、初期化される(ステップＳ１０２)。上述したループ処理の終了要件は、このPlayItem#xがカレントプレイリストの最後のPlayItemになることであり(ステップＳ１０９)、もし最後のPlayItemでなければ、カレントプレイリストにおける次のPlayItemがPlayItem#xに設定される(ステップＳ１１０)。

ループ処理において繰り返し実行されるステップＳ１０３〜ステップＳ１１０は、PlayItem#xのClip_information_file_nameで指定されるClip情報をメモリに読み込み(ステップＳ１０３)、PlayItem#xのIn_timeを、カレントClip情報のEPmapを用いて、Iピクチャアドレスuに変換し(ステップＳ１０４)、PlayItem#xのOut_timeを、カレントClip情報のEP_mapを用いて、Iピクチャアドレスvに変換して(ステップＳ１０５)、これらの変換で得られたアドレスvの次のIピクチャを求めて、そのアドレスの1つ手前をアドレスwに設定し(ステップＳ１０７)、そうして算出されたアドレスwを用いて、IピクチャアドレスuからアドレスwまでのTSパケットの読み出しをBD-ROMドライブ１又はローカルストレージ２００に命じるというものである(ステップＳ１０８)。

一方、ビデオデコーダ等に対しては、カレントPLMarkのmark_time_stampからPlayItem#xのOut_timeまでの出力を命じる(ステップＳ１０６)。以上のステップＳ１０５〜ステップＳ１０８により、AVClipにおいて、PlayItem#xにより指示されている部分の再生がなされることになる。
その後、PlayItem#xがカレントプレイリストの最後のPIであるかの判定がなされる(ステップＳ１０９)。

PlayItem#xがカレントプレイリストの最後のPIでなければ、カレントプレイリストにおける次のPlayItemを、PlayItem#xに設定して(ステップＳ１１０)、ステップＳ１０３に戻る。以上のステップＳ１０３〜ステップＳ１１０を繰り返することにより、プレイリストを構成するPIは順次再生されることになる。

＜機能構成の詳細その２.Procedure実行部４２＞
Procedure実行部４２は、あるPlayItem情報から別のPlayItem情報への切り換わりが生じた場合、又はストリーム番号を切り換える旨の操作がユーザによりなされた場合、所定のストリーム選択プロシージャを実行して、PSR1に新たなストリーム番号を書き込む。再生装置は、PSR1に書き込まれたストリーム番号に応じて、Primaryオーディオストリームを再生するので、かかるPSR1の設定を通じて、Primaryオーディオストリームが選択されることになる。

PlayItem情報の切り換わり時に、ストリーム選択プロシージャを実行するのは、STN_TableはPlayItem情報毎に存在するので、あるPlayItem情報においては再生可能であったPrimaryオーディオストリームが、別のPlayItem情報において再生不可能になることが有り得るからである。
このProcedure実行部４２により、PSR1は、図２９（ａ）に示すような状態遷移をなす。図２９（ａ）は、PSR1の設定値が取り得る状態遷移を示す図である。本図においてValidとは、PSR1の値が、Play ItemのSTN_tableに記述されたentry数以下の番号になっていて、尚且つ、デコード可能であることを意味する。

Invalidとは、PSR1の値が、0であるか、又は、Play ItemのSTN_tableに記述されたentry数を上回る番号になっているか、または、Play ItemのSTN_tableに記述されたentry数が1〜32の値であったとしても、デコードできない場合である。
図２９（ａ）における破線枠は、状態遷移時にあたってPSRの値を決定する手順を模式的に示す。PSRの設定処理手順には、『Procedure when playbackcondition is changed』、『Procedure when Stream change isrequested』がある。

Procedure when playback condition is changedは、何等かの事象が再生装置に生じたため、再生装置の状態が変化した際に実行すべき処理手順を示す。
Procedure when Stream Change is requestedは、ユーザが何等かの切り換え(図２９（ａ）においてstream)を要求した際、実行すべき処理手順を示す。
これら破線枠に示されるProcedure when playback condition ischanged、Procedure when Stream change is requestedが、ストリーム選択プロシージャであり、後でフローチャートを交えて詳細に説明する。

図２９（ａ）における矢印は、PSRが取り得る状態間の状態遷移を象徴的に示す。
状態遷移を意味する矢印に添えられた注釈は、各状態遷移のトリガとなるべき事象を意味する。つまり本図では、”LoadDisc”、”Change a Stream”,”Start PlayListplayback”,”Cross a PlayItem boundary”,”Terminate PlayList playback”というような事象が発生した際、PSR1の状態遷移がなされることになる。これらの記法を理解して図２９（ａ）を参照すれば、Invalid→Invalidの状態遷移時、Valid→Invalidの状態遷移時には、上述した処理手順は実行されていないことがわかる。これに対しInvalid→Valid間の状態遷移、Valid→Valid間の状態遷移は何れも破線枠を経由している。つまりPSR1をValidに設定するにあたって、上述したProcedure when playback condition is changed、Procedure when Stream change is requestedによりPSR1は設定されるのである。

以降、状態遷移のトリガとなるべき事象について説明する。
『Load Disc』とは、再生装置にBD-ROMがローディングされたとの事象を意味する。PSR1は、かかるローディング時において、一旦不定値(0xFF)に設定されるのである。
『Start PlayList playback』とは、PLに基づく再生処理が開始したとの事象を意味する。かかる事象が発生時において、Procedure when playback condition is changedが実行され、PSR1はValidに設定されることがわかる。

『Terminate PlayList playback』とは、PLに基づく再生処理を終了したとの事象を意味する。かかる事象の発生時では、Procedurewhen playback condition is changedは実行されず、Invalidに移行していることがわかる。
『ChangeXXX』とは、ユーザによるXXX(本図ではStream)の切り換え要求がなされたとの事象を意味する。PSR1がInvalidである場合に、かかる事象が発生すれば(図中のcj1)、PSR1はその要求通りの値に設定される。こうして設定された値がたとえ有効なストリーム番号を示していたとしても、このPSR1の設定値はInvalidな値として取り扱われる。即ち、事象”ChangeXXX”による状態遷移では、InvalidであるPSRが、Validに変えることはない。

一方、PSR1がValidである場合に、かかる事象Change a Streamが発生すれば(図中のcj2)、Procedure when Stream change isrequestedが実行されて、新たな値がPSR1に設定される。ここでProcedure when Stream change is requestedの実行により設定される値は、ユーザが希望した値にならない場合も有り得る。何故なら、Procedure when Stream change is requestedは、無効な値を排除する機能を有しているからである。PSR1がValidにおいて、Changestreamが発生した場合、ValidからInvalidに状態遷移することは有り得ない。PSR1がInvalidにならないよう、Procedurewhen Stream change is requested側で保証するからである。

『Cross a PlayItem boundary』とは、あるPlay Itemの境界通過という事象を意味する。ここでPlay Itemの境界とは、連続する2つのPlay Itemのうち、先行する側の終端、後続する側の先端の狭間を意味する。PSR1がValidである場合において、かかる事象が発生すれば、Procedure when playback condition is changedが実行されることがわかる。そして、Procedure when playback condition is changedの実行後、PSR1の状態はValidに戻るか、Invalidに移行することが分かる。STN_tableはPlay Item毎に存在しており、Play Itemが変われば、再生可能なエレメンタリストリームも変わってしまう。PlayItemの再生開始毎に、Procedure when playback condition is changeを実行してPlay Item毎に最適な設定値をPSR1に設定するというのが、この状態遷移の趣旨である。

この状態遷移においてProcedure when playback condition is changedは、図２９（ｂ）のようになる。図２９（ｂ）は、Procedure when playback condition is changedの処理手順を示す図である。本処理手順は、ステップＳ１、ステップＳ２という2つの判定ステップの組合せで、PSR1の設定を行うものである。
ステップＳ１は、STN_tableにおけるentry数が0であるか否かの判定であり、もし0であればPSR1の値を維持する(ステップＳ３)。

ステップＳ２は、STN_tableにおけるentry数は0ではない場合に、PSR1よりSTN_tableのentry数が多く、尚且つ、条件(A)が真であるかを判定するものである。条件(A)とは、PSR1で特定されるPrimaryオーディオストリームを再生する能力が再生装置に存在することである。もしステップＳ２がYesであればPSR1を維持する(ステップＳ４)。もしPSR1の値がentry数より大きいか、或は条件(A)を満たさない場合は、PSR1を再設定する(ステップＳ５)。

図３０は、ステップＳ５の詳細な処理手順に示したフローチャートである。
ステップＳ６、ステップＳ７は、全てのPrimaryオーディオストリームについてステップＳ８を繰り返すループ処理を形成している。このループ処理において、処理対象となる個々のPrimaryオーディオストリームを、Primaryオーディオストリームiという。ステップＳ８は、Primaryオーディオストリームiが3つの条件(a)(b)(c)を満たすかのチェックを行う。

条件(a)とは、Primaryオーディオストリームiを再生する能力が再生装置に存在することであり、これを満たすか否かの判定は、PSR15と、Primaryオーディオストリームiのstream_coding_typeとの比較でなされる。
条件(b)とは、Primaryオーディオストリームiの言語属性が再生装置の言語設定と同じであることであり、これを満たすか否かの判定は、STN_tableに記述されたPrimaryオーディオストリームiのAudio_language_codeがPSRの設定値と同じであるか否かの比較でなされる。

条件(c)とは、Primaryオーディオストリームiのチャネル属性がサラウンドであり、これを再生する能力が再生装置に存在することである。これを満たすか否かの判定は、PSR15と,Audio Streamのaudio_presentation_type、stream_coding_typeとの比較でなされる。
これらの複数の条件のうち、「Primaryオーディオストリームiがどれとどれを満たすか」、また「何個の条件を満たすか」という、満たすべき条件のパターンにより、本フローチャートは、Primaryオーディオストリームに優先順位を付与する。
以上の処理をPrimaryオーディオストリームの全てについて繰り返されれば、ステップＳ９〜ステップＳ１３の処理を行う。ステップＳ９は、(a)を満たすPrimaryオーディオストリームが存在しないかどうかの判定である。もし、存在しなければ、不定値(0xFF)をPSR1に設定する(ステップＳ１４)。

ステップＳ１０は、条件(a)(b)(c)の全てを満たすPrimaryオーディオストリームが存在するかどうかの判定である。もし存在すれば、条件(a)(b)(c)を満たすPrimaryオーディオストリームの番号をPSR1に設定する(ステップＳ１５)。
ここで問題になるのが、条件(a)(b)(c)を満たすPrimaryオーディオストリームが複数存在する場合である。条件(a)〜条件(c)が全てみたされるので、同じ優先順位になってしまうので優劣を決めることができない。この場合ステップＳ１５では、STN_tableにおけるentryの順序に応じて、各ストリームにおける順位が定める。即ち、コーディック−言語属性−チャネル属性が同じPrimaryオーディオストリームについては、STN_tableにおけるentryの順番を参照することで、最もentryの順番が早いPrimaryオーディオストリームが選ばれることになる。

STN_tableにおける記述順序を変えることで、オーサリング担当者は再生時においてどのストリームを優先的に再生させ、どのストリームを後回しにするかという選択制御をオーサリング時に規定することができる。
ステップＳ１１は、条件(a)(b)(c)の全てを満たすPrimaryオーディオストリームが存在しない場合、条件(a)(b)を満たすPrimaryオーディオストリームが存在するかどうかの判定である。もし存在すれば、条件(a)(b)を満たすPrimaryオーディオストリームのうち、STN_tableにおけるエントリーの順番が最も早いものをPSR1に設定する(ステップＳ１６)。

ステップＳ１２は、条件(a)(b)(c)の全てを満たすPrimaryオーディオストリーム、又は、条件(a)(b)を満たすPrimaryオーディオストリームが存在しない場合に、条件(a)(c)を満たすPrimaryオーディオストリームが存在するかどうかの判定である。もし存在すれば、条件(a)(c)を満たすPrimaryオーディオストリームのうち、STN_tableにおけるエントリーの順番が最も早いものをPSR1に設定する(ステップＳ１７)。

ステップＳ１３は、条件(a)(b)(c)の全て、条件(a)(b)、条件(a)(c)を満たすPrimaryオーディオストリームが存在しない場合に、条件(a)を満たすPrimaryオーディオストリームが存在するかどうかの判定である。もし存在すれば、条件(a)を満たすPrimaryオーディオストリームのうち、STN_tableにおけるエントリーの順番が最も早いものをPSR1に設定する(ステップＳ１８)。

以上がProcedure when playback condition is changedである。続いてProcedure when Stream change is requestedについて説明する。図３１は、ストリーム変化時におけるPSR1の設定手順を示すフローチャートである。本フローチャートと、図２９（ｂ）との違いは、図２９（ｂ）におけるPSR1の表記がXに置き換えられている点である。このXは、操作受付部２６から出力されたUser Operation情報やIGデコーダ１３から出力されたボタンコマンドに基づく値である。

本フローチャートにおけるステップＳ１９は、XよりSTN_tableのentry数が多く、尚且つ、条件(A)が真であるかを判定するものである。条件(A)とは、PSR1で特定されるPrimaryオーディオストリームを再生する能力が再生装置に存在することであり、PSR15と、PrimaryオーディオストリームのStream_codeig_typeの比較で判定される。もしXがこの条件を満たすなら、PSR1にXを設定する(ステップＳ２１)。

もしXがentry数より大きいか、或は条件(A)を満たさない場合は、Xが、0xFFであるか否かを判定する。もしOxFFでなければ、ユーザが選択を意図するPrimaryオーディオストリームの番号は無効であると考えられるので、ユーザ操作に基づく値Xを無視し、PSR1の設定値を維持する(ステップＳ２３)。
もしPSR1の設定値が0xFFであるなら、PSR1を設定する(ステップＳ２４)。このステップＳ２４の処理手順は、図３０に示した処理手順と同一である(図３０のうち、ステップＳ９の判定はProcedure when Streamchange is requestedでは必要ではない。何故ならProcedure when Streamchange is requestedでは、条件(a)(b)(c)を満たすPrimaryオーディオストリームが1つも存在しない場合、ユーザが設定した値XをPSR1に設定せず、PSR1の設定値を維持するからである。)。

＜機能構成の詳細その３.Procedure実行部４３＞
Procedure実行部４３は、あるPlayItem情報から別のPlayItem情報への切り換わりが生じた場合、又はストリーム番号を切り換える旨の操作がユーザによりなされた場合、所定の手順を実行して、PSR14に新たなストリーム番号を書き込む。再生装置は、PSR14に書き込まれたストリーム番号に対応するSecondaryオーディオストリームを再生するので、かかるPSR14の設定を通じて、Secondaryオーディオストリームが選択されることになる。

このProcedure実行部４３により、PSR14は、図３２（ａ）に示すような状態遷移をなす。
図３２（ａ）は、PSR14の設定値が取り得る状態遷移を示す図である。本図においてValidとは、PSR14の値が、PlayItemのSTN_tableに記述されたentry数以下の番号になっていて、尚且つ、デコード可能であることを意味する。

Invalidとは、PSR14の値が、0であるか、又は、Play ItemのSTN_tableに記述されたentry数を上回る番号になっているか、または、Play ItemのSTN_tableに記述されたentry数が1〜32の値であったとしても、デコードできない場合である。
図３２（ａ）における破線枠は、状態遷移時にあたってPSRの値を決定する手順を模式的に示す。PSRの設定処理手順には、『Procedure when playbackcondition is changed』、『Procedure when Stream change isrequested』がある。

Procedure when playback condition is changedは、何等かの事象が再生装置に生じたため、再生装置の状態が変化した際に実行すべき処理手順を示す。
Procedure when Stream Change is requestedは、ユーザが何等かの切り換え(図３２においてstream)を要求した際、実行すべき処理手順を示す。
これら破線枠に示されるProcedure when playback condition ischanged、Procedure when Stream change is requestedが、ストリーム選択プロシージャであり、後でフローチャートを交えて詳細に説明する。

図３２（ａ）における矢印は、PSRが取り得る状態間の状態遷移を象徴的に示す。
状態遷移を意味する矢印に添えられた注釈は、各状態遷移のトリガとなるべき事象を意味する。つまり本図では、”LoadDisc”、”Change a Stream”,”Start PlayListplayback”,”Cross a PlayItem boundaryor Change Primary Audio Stream”,”TerminatePlayList playback”というような事象が発生した際、PSR14の状態遷移がなされることになる。これらの記法を理解して図３２（ａ）を参照すれば、Invalid→Invalidの状態遷移時、Valid→Invalidの状態遷移時には、上述した処理手順は実行されていないことがわかる。これに対しInvalid→Valid間の状態遷移、Valid→Valid間の状態遷移は何れも破線枠を経由している。つまりPSR14をValidに設定するにあたって、上述したProcedure when playback condition is changed、Procedure when Stream change is requestedによりPSR14は設定されるのである。

以降、状態遷移のトリガとなるべき事象について説明する。
『Load Disc』とは、再生装置にBD-ROMがローディングされたとの事象を意味する。PSR14は、かかるローディング時において、一旦不定値(0xFF)に設定されるのである。
『Start PlayList playback』とは、PLに基づく再生処理が開始したとの事象を意味する。かかる事象が発生時において、Procedure when playback condition is changedが実行され、PSR14はValidに設定されることがわかる。

『Terminate PlayList playback』とは、PLに基づく再生処理が終了したとの事象を意味する。かかる事象の発生時では、Procedurewhen playback condition is changedは実行されず、Invalidに移行していることがわかる。
『ChangeXXX』とは、ユーザによるXXX(本図ではStream)の切り換え要求がなされたとの事象を意味する。PSR14がInvalidである場合に、かかる事象が発生すれば(図中のcj1)、PSR14はその要求通りの値に設定される。こうして設定された値がたとえ有効なストリーム番号を示していたとしても、このPSR14の設定値はInvalidな値として取り扱われる。即ち、事象”ChangeXXX”による状態遷移では、InvalidであるPSRが、Validに変えることはない。

一方、PSR14がValidである場合に、かかる事象Change a Streamが発生すれば(図中のcj2)、Procedure when Stream change isrequestedが実行されて、新たな値がPSR14に設定される。ここでProcedure when Stream change is requestedの実行により設定される値は、ユーザが希望した値にならない場合も有り得る。何故なら、Procedure when Stream change is requestedは、無効な値を排除する機能を有しているからである。PSR14がValidにおいて、Changestreamが発生した場合、ValidからInvalidに状態遷移することは有り得ない。PSR14がInvalidにならないよう、Procedure when Stream change is requested側で保証するからである。

『Cross a PlayItem boundary orChange Primary Audio Stream』とは、あるPlay Itemの境界通過、又は、Primaryオーディオストリームの切り替えという事象を意味する。PSR14がValidである場合において、かかる事象が発生すれば、Procedure whenplayback condition is changedが実行されることがわかる。そして、Procedurewhen playback condition is changedの実行後、PSR14の状態はValidに戻るか、『Cross a PlayItem boundary or Change Primary Audio Stream』が発生するとInvalidに移行することが分かる。Play Itemの再生開始やPrimaryオーディオストリームの切り替え毎に、Procedure when playback condition is changeを実行してPlay Item毎に最適な設定値をPSR14に設定するというのが、この状態遷移の趣旨である。

この状態遷移においてProcedure when playback condition is changedは、図３２（ｂ）のようになる。本処理手順は、ステップＳ３１、ステップＳ３２という2つの判定ステップの組合せで、PSR14の設定を行うものである。
ステップＳ３１は、STN_tableにおけるentry数が0であるか否かの判定であり、もし0であればPSR14の値を維持する(ステップＳ３３)。

ステップＳ３２は、STN_tableにおけるentry数は0ではない場合に、PSR14よりSTN_tableのentry数が多く、尚且つ、条件(A)と（B）が真であるかを判定するものである。条件(A)とは、PSR14で特定されるSecondaryオーディオストリームを再生する能力が再生装置に存在することである。条件（B）とは、Primary_Audio_Stream_Numberと、Secondary_Audio_Stream_Numberの組み合わせがSTN_tableで許可されていることである。もしステップＳ３２がNoであればPSR14を維持する(ステップＳ３４)。Yesの場合は、PSR14を再設定する(ステップＳ３５)。

図３３は、ステップＳ３５の詳細な処理手順に示したフローチャートである。
ステップＳ３６、ステップＳ３７は、全てのSecondaryオーディオストリームについてステップＳ３８を繰り返すループ処理を形成している。このループ処理において、処理対象となる個々のSecondaryオーディオストリームを、Secondaryオーディオストリームiという。ステップＳ３８は、Secondaryオーディオストリームiが3つの条件(a)(b)(c)を満たすかのチェックを行う。

条件(a)とは、Secondaryオーディオストリームiを再生する能力が再生装置に存在することであり、これを満たすか否かの判定は、オーディオストリームの再生能力を示すレジスタ(PSR15)と、Secondaryオーディオストリームiのstream_coding_typeとの比較でなされる。
条件(b)とは、PrimaryオーディオストリームをSecondaryオーディオストリームにミキシングすることができるか否かであり、この条件が満たされているか否かの判定は、PSR1に設定されているストリーム番号が、SecondaryオーディオストリームのComb_info_Secondary_audio_Primary_audioに記載されているかを判断することでなされる。

条件(c)とは、Secondaryオーディオストリームiの言語属性が再生装置の言語設定と同じであることであり、これを満たすか否かの判定は、STN_tableに記述されたSecondaryオーディオストリームiのAudio_language_codeがPSRの設定値と同じであるか否かの比較でなされる。
これらの複数の条件のうち、「Secondaryオーディオストリームiがどれとどれを満たすか」、また「何個の条件を満たすか」という、満たすべき条件のパターンにより、本フローチャートは、Secondaryオーディオストリームに優先順位を付与する。
以上の処理をSecondaryオーディオストリームの全てについて繰り返されれば、ステップＳ３９〜ステップＳ４１、ステップＳ４４〜ステップＳ４６の処理を行う。ステップＳ３９は、条件(a)及び条件(b)を満たすSecondaryオーディオストリームが存在しないかどうかの判定である。もし、存在しなければ、不定値(0xFF)をPSR14に設定する(ステップＳ４４)。

ステップＳ４０は、条件(a)(b)(c)の全てを満たすSecondaryオーディオストリームが存在するかどうかの判定である。もし存在すれば、条件(a)(b)(c)を満たすSecondaryオーディオストリームの番号をPSR14に設定する(ステップＳ４５)。
ここで問題になるのが、条件(a)(b)(c)を満たすSecondaryオーディオストリームが複数存在する場合である。条件(a)〜条件(c)が全てみたされるので、同じ優先順位になってしまうので優劣を決めることができない。この場合ステップＳ４５では、STN_tableにおけるentryの順序に応じて、各ストリームにおける順位が定める。即ち、コーディック−言語属性−チャネル属性が同じSecondaryオーディオストリームについては、STN_tableにおけるentryの順番が最も早いSecondaryオーディオストリームが選ばれることになる。

STN_tableにおける記述順序を変えることで、オーサリング担当者は再生時においてどのストリームを優先的に再生させ、どのストリームを後回しにするかという選択制御をオーサリング時に規定することができる。
ステップＳ４１は、条件(a)(b)(c)の全てを満たすSecondaryオーディオストリームが存在しない場合、条件(a)(b)を満たすSecondaryオーディオストリームが存在するかどうかの判定である。もし存在すれば、条件(a)(b)を満たすSecondaryオーディオストリームのうち、STN_tableにおけるエントリーの順番が最も早いものをPSR14に設定する(ステップＳ４６)。

以上がProcedure when playback condition is changedである。続いてProcedure when Stream change is requestedについて説明する。図３４は、ストリーム変化時におけるPSR14の設定手順を示すフローチャートである。本フローチャートと、図３２（ｂ）との違いは、図３２（ｂ）におけるPSR14の表記がXに置き換えられている点である。このXは、操作受付部２６から出力されたUser Operation情報やIGデコーダ１３から出力されたボタンコマンドに基づく値である。

本フローチャートにおけるステップＳ４９は、XよりSTN_tableのentry数が多く、尚且つ、条件(A)、条件(b)が真であるかを判定するものである。もしXがこの条件を満たすなら、PSR14にXを設定する(ステップＳ５１)。
もしXがentry数より大きいか、或は条件(A)及び条件(B)を満たさない場合は、Xが、0xFFであるか否かを判定する（ステップＳ５２）。もしOxFFでなければ、ユーザが選択を意図するSecondaryオーディオストリームの番号は無効であると考えられるので、ユーザ操作に基づく値Xを無視し、PSR14の設定値を維持する(ステップＳ５３)。

もしPSR14の設定値が0xFFであるなら、PSR14を設定する(ステップＳ５４)。このステップＳ５４の処理手順は、図３３に示した処理手順と同一である(図３３のうち、ステップＳ３９の判定はProcedure when Streamchange is requestedでは必要ではない。何故ならProcedure when Streamchange is requestedでは、条件(a)(b)(c)を満たすSecondaryオーディオストリームが1つも存在しない場合、ユーザが設定した値XをPSR14に設定せず、PSR14の設定値を維持するからである。)。

以上でProcedure実行部４３についての説明を終える。
＜機能構成の詳細その４.ミキシング制御部４４＞
ミキシング制御部４４は、Player Profile情報が0001hである場合、又は、0011hである場合、Primaryオーディオストリームの再生出力に対して、Secondaryオーディオストリームの再生出力、又は、サウンドデータの再生出力をミキシングするよう、ミキサー９a、ミキサー９bを制御する。

ここでPlayItem時間軸における現在の再生時点が、SubPlayItem情報のIn_timeからOut_timeまでであり、また、カレントPlayItem情報のSTN_Tableにおいて、Secondaryオーディオストリームが有効になっている場合、PSR14に格納されたストリーム番号のSecondaryオーディオストリームのデコードが、オーディオデコーダ７bにてなされているので、ミキシング制御部４４は、オーディオデコーダ７aの再生出力に対して、オーディオデコーダ７bの再生出力をミキシングするよう、ミキサー９aを制御する。

Primaryオーディオストリームにおける属性がサラウンドである場合、L,R,C,LS,RS,LR,RR,LFEといった成分のうち、所望の成分のみを残すようダウンミキシングを行った上で、Secondaryオーディオストリームの再生出力をミキシングすることができる。ここでSecondaryオーディオストリームが映画監督のコメンタリ音声である場合、SecondaryオーディオストリームをミキシングすべきPrimaryオーディオストリームのチャンネルを、L→C→Rというように変化させてゆけば、ユーザの回りを映画監督が、歩き回っているかのような感覚を、ユーザに与えることができる。このようなミキシングをパンニングと呼んでいる。パンニングではPrimaryオーディオストリームよりも少ないチャンネル数のSecondaryオーディオストリーム（例えばモノラル）の音声が使われる。

Ｊａｖａ（登録商標）アプリケーションにて描画されたボタンに対し確定操作がなされた場合、又は、IGストリームにより描画されたボタンに対し確定操作がなされた場合、Primaryオーディオストリームの再生出力、又は、Primaryオーディオストリームの再生出力と、Secondaryオーディオストリームの再生出力とのミキシング結果に対して、サウンドデータをミキシングするよう、ミキサー９bを制御する。

以上のように本実施形態によれば、デマルチプレクサ３bは、バス１bに転送されているTSパケットを取り込み、このPIDの上位バイトを参照することにより、当該TSパケットを、Secondaryオーディオストリーム用のデコーダに投入することができる。これによりデマルチプレクサ３bは、このSecondaryオーディオストリームを構成するPESパケットのみを、多重分離して、Primaryオーディオストリーム用のデコーダとは別のデコーダに取り込むことができる。

Primaryオーディオストリームを構成するパケット、Secondaryオーディオストリームを構成するパケットを別々のデコーダに取り込み、デコードに供給することができるので、Primaryオーディオストリームを構成するパケットのみダウンコンバートを施したり、ダウンミキシングを施したり、ゲインを下げたりすることができる。BD-ROM１００からの読み出す中に、ローカルストレージ２００からSecondaryオーディオストリームを読み出し、これらを2つのデコーダに供給したとしても、Primaryオーディオストリームを構成するパケットのみに対し、リアルタイムに特別な処理を施すことができる。

（第２実施形態）
第２実施形態は、ホームシアターシステムにおける再生装置３００、AVアンプ５００のうち、どの装置において、Primaryオーディオストリームのデコードを行うかという、Primaryオーディオストリームのデコードを行わせるべき装置の選択に関する実施形態である。

図３５（ａ）は、再生装置３００、AVアンプ５００、スピーカ６００の接続形態を示す図である。ホームシアターシステムにおける接続形態には、AVアンプ５００を介さず、再生装置３００を直接、スピーカ６００に接続する形態(接続形態(1))、AVアンプ５００を介してスピーカ６００と接続する形態(接続形態(2))がある。
前者の接続形態(1)には、再生装置３００のデコードで得られたLPCMがスピーカ６００に供給される。一方、後者の接続形態(2）では、再生装置３００はパススルー出力を行うに過ぎず、AVアンプ５００のデコードで得られたLPCMがスピーカ６００に供給される。

このように、何通りかの接続形態がホームシアターシステムに存在する場合、それぞれの装置において、チャンネル数が変化する。
図３５（ｂ）は、再生装置３００、AVアンプ５００、スピーカ６００のそれぞれで、チャンネル数がどのように変化するかを示す図である。本図の第1段目は、BD-ROM１００、再生装置３００、AVアンプ５００、スピーカ６００のそれぞれを示す。これらの機器のデコード能力は、再生装置３００が5.1chまで可能であり、AVアンプ５００は、7.1chまで可能、スピーカ６００は7.1chというものである。

第2段目〜第4段目は、BD-ROM１００に、7.1ch、5.1chのPrimaryオーディオストリームが存在する場合、これらの機器にて、どのようにダウンミキシングが行われるかを示す。第2段目は、BD-ROM１００に7.1chの属性をもつPrimaryオーディオストリームが存在しており、これを再生装置３００でデコードする場合を示している。この場合、再生装置３００は、BD-ROM１００から読み出した7.1chのPrimaryオーディオストリームをデコードして、5.1chにダウンミキシングしたLPCMを出力する。AVアンプ５００は、この5.1chのLPCMを7.1chに変換した上でスピーカ６００に出力する。

第3段目は、BD-ROM１００に5.1chのPrimaryオーディオストリームが記録されている場合を示す。この場合、再生装置３００は、5.1chのPrimaryオーディオストリームをデコードし、ダウンミキシングを施さずにAVアンプ５００にLPCMを出力する。AVアンプ５００は、この5.1chの音声出力を7.1chに変換した上で、スピーカ６００に出力する。
第4段目は、BD-ROM１００に7.1chが記録されており、これを再生装置３００がパススルー出力する場合を示す。この場合、デコードは、AVアンプ５００でなされ、このAVアンプ５００によるデコードにて得られた7.1chの音声が、スピーカ６００に供されて、音声出力される。

これらの出力を比較すれば、第2段目のように再生装置３００が7.1chを5.1chに変換する場合は、音声はいったん5.1chになり、AVアンプ５００が7.1chに変換したものをスピーカ６００に出力するので、BD-ROM１００に記録されているオーディオストリームが7.1chであるにもかかわらず、第2段目の出力時での音質は、第3段目の出力時での音質と大差がない。

これに対して第4段目では、7.1chのオーディオストリームのデコードを、7.1chのデコード能力を有するAVアンプ５００に行わせているので、高音質の出力が期待できる。
そこで本実施形態では、かかる出力形態において、接続相手となる機器に再生能力が存在する場合、かかる機器にデコードを行わせるよう、パススルー出力を行う。
接続相手にどれだけの再生能力があるか、デコード能力があるか、ストリーム出力すべきかどうかは、HDMIにおけるDIB(Decoder Information Block)を通じて判定する。図３６（ａ）は、DIBを示す図である。

本図に示すようにDIBは、AVアンプ５００に出力することができる符号化方式を示す「Coding Type」、接続相手の機器がデコード可能なチャネル数を示す「ChannelCount」、スピーカ配置を示す「Channle/Speaker Allocation」、接続相手の機器において再生することができる周波数を示す「Sample Frenquency」からなる。
図３６（ｂ）は、DIBの各フィールドに設定しうる値を示す。

「CODING TYPE」は、接続相手となる機器において、デコードを行うことができる符号化方式は、DTS-HD、MLP、DD+などのうち、どれであるかを示す。「CODING TYPE」における実際の記述は、CT0,CT1,CT2,CT3という4つのパラメータを用いてなされる。 「Channel Count」は、7.1ch、5.1ch、2chなどデコード可能なチャンネル数を示す。
「Channel/Speaker Allocation」は、5.1chのステレオ配置である「L/R/C/LS/RS/LFE」、7.1chのステレオ配置である「L/R/C/LS/RS/LR/RR/LFE」、2chのステレオ配置である「L/R」などのスピーカーの物理的な配置情報を示す。

「Sample Frenquency」は、「48KHz」、「192KHz」、「96KHz」などのサンプリング周波数示す。
図３６（ｃ）は、DIBを用いた再生装置３００、AVアンプ５００間の通信シーケンスを示す。
再生装置３００のHDMI送受信部２７は、AVアンプ５００と接続された際、◎1に示すように、相互認証を行い、その後、再生装置３００のHDMI送受信部２７は、レシーバとなるAVアンプ５００側から、◎2に示すようにDIBを受信する。こうして受信したDIBにおいて、AVアンプ５００側に、Primaryオーディオストリームをデコードする能力が存在すれば、AVアンプ５００に対し、◎3に示すようにPrimaryオーディオストリームのパススルー出力を行うことができる。AVアンプ５００側に、Primaryオーディオストリームをデコードする能力がなければ、再生装置でデコードしたLPCMを転送するか、そのストリームは再生できないことになる。

続いて、第２実施形態における、再生装置の改良について説明する。
図３７は、PSRセット２３におけるPSR15の内部構成を示す図である。
PSR15は、第１実施形態に示したPSR1、PSR14、PSR31と同様、32ビットのビット長を有する。
PSR15のビットb0からビットb3までは、LPCMのオーディオストリームをデコードして再生する能力が再生装置に存在するか否かを示す。この4ビットが0001bなら、ステレオ属性をもつ48/96HzのLPCMオーディオストリームを再生する能力が、再生装置に存在することを示す。この4ビットが0010bなら、サラウンド属性をもつ48/96HzのLPCMオーディオストリームを再生する能力が、再生装置に存在することを示す。この4ビットが0101bなら、ステレオ属性をもつ全ての周波数のLPCMオーディオストリームを再生する能力が、再生装置に存在することを示す。この4ビットが0110bなら、サラウンド属性をもつ全ての周波数のLPCMオーディオストリームを再生する能力が、再生装置に存在することを示す。

PSR15のビットb4からビットb7までは、DD/DD+形式のオーディオストリームをデコードして再生する能力が再生装置に存在するか否かを示す。この4ビットの下位2ビットが01bなら、DD/DD+オーディオストリームの基本データ(independent substram)の2chストリームまでを再生する能力が、再生装置に存在することを示す。この4ビットの下位2ビットが10bなら、DD/DD+オーディオストリームの基本データ(independent substram)のマルチチャンネルストリーム（2chより多いch数のストリーム）を再生する能力が、再生装置に存在することを示す。

この4ビットの上位2ビットが01bなら、DD/DD+オーディオストリームの拡張データ(Dependent substram)の2chストリームまでを再生する能力が、再生装置に存在することを示す。この4ビットの上位2ビットが10bなら、DD/DD+オーディオストリームの拡張データ(Dependent substram)のマルチチャンネルストリームを再生する能力が、再生装置に存在することを示す。

上位2ビットが00であるなら、DD/DD+オーディオストリームの拡張データ(Dependent substram)を再生する能力が再生装置に存在しないことを示す。
PSR15のビットb8からビットb11までは、DTS-HD形式のオーディオストリームをデコードして再生する能力が再生装置に存在するか否かを示す。この4ビットの下位2ビットが01bなら、DTS-HDオーディオストリームの基本データ(Core substram)の2chまでを再生する能力が、再生装置に存在することを示す。この4ビットの下位2ビットが10bなら、DTS-HDオーディオストリームの基本データ(Core substram)のマルチチャンネルを再生する能力が、再生装置に存在することを示す。

この4ビットの上位2ビットが01bなら、DTS-HDオーディオストリームの拡張データ(Extension substramの2chまでを再生する能力が、再生装置に存在することを示す。この4ビットの上位2ビットが10bなら、DTS-HDオーディオストリームの拡張データ(Extension substram)のマルチチャンネルを再生する能力が、再生装置に存在することを示す。
上位2ビットが00bであるなら、DTS-HDオーディオストリームの拡張データ(Extension substram)を再生する能力が再生装置に存在しないことを示す。

PSR15のビットb12からビットb15までは、DD/MLP形式のオーディオストリームをデコードして再生する能力が再生装置に存在するか否かを示す。この4ビットの下位2ビットが01bなら、DDオーディオストリームの2chまでを再生する能力が、再生装置に存在することを示す。この4ビットの下位2ビットが10bなら、DDオーディオストリームのマルチチャンネルを再生する能力が、再生装置に存在することを示す。

この4ビットの上位2ビットが01bなら、MLPオーディオストリームの2chまでを再生する能力が、再生装置に存在することを示す。この4ビットの上位2ビットが10bなら、MLPオーディオストリームのマルチチャンネルを再生する能力が、再生装置に存在することを示す。
上位2ビットが00であるなら、MLPオーディオストリームを再生する能力が再生装置に存在しないことを示す。

このように、PSR15は、符号化方式毎に、基本データ、拡張データのそれぞれを処理する能力があるか否かを規定できるようにしている。PSR15の説明で言う2chとはL/Rの2chを意味している。
このようにPSR15が規定されているので、第２実施形態にかかるコントローラ２２は、図３８のフローチャートに従って、Primaryオーディオストリームの再生制御を行う。図３８は、第２実施形態にかかるコントローラ２２の処理手順を示すフローチャートである。

ステップＳ６１は、装置起動がなされたかか否かの起動待ち判定であり、もし起動されれば、HDMIを介した接続相手の機器の認証を行う（ステップＳ６２）。この認証により、相互の正当性が判明すれば、ステップＳ６３に移行する。ステップＳ６３は、DIBを受信したかどうかの受信待ちループであり、もしDIBを受信すれば（ステップＳ６３でyes）、接続相手から受け取ったDIBにより、接続相手の能力及びスピーカ数(配置)を認識する（ステップＳ６４）。ステップＳ６５は、接続相手に再生能力が存在するか否かの判定であり、もし再生能力が存在するなら、パススルー出力を行うか否かの設定を受け付けるためのメニューを表示し（ステップＳ６７）、ユーザがパススルー出力を希望したかどうかを判定する（ステップＳ６８）。
尚、DIBによりスピーカが接続されている機器（多くの場合AVアンプ）にてデコードできることが分かった場合には、ユーザーに設定させることなく、自動で接続相手機器にてデコードするようパススルー設定（Ｓ６８でＹＥＳ）を行なっても良い。

尚、再生機器３００の機器設定メニュー（初期設定メニュー）で接続先の機器でデコードできることが分かった場合には自動でパススルー設定（Ｓ６８でＹＥＳ）を行なうよう予め設定をしていても良い。
図３９、図４０は、パススルー出力を行うか否かの設定を受け付けるためのメニューを示す図である。これらの図におけるメニューは、「お客さまのシアターシステムでは、接続先の機器で音声デコードを行うことができます」や「接続先の機器xxxxで音声デコードを行なうことで、より高音質な音声をお楽しみ頂けます」などの注意を喚起する旨のメッセージと、接続先機器でのデコード指示を可否を受け付けるボタン「Yes」「No」とからなる。

一方、図４０のメニューにおいて、XXXの部分には、AVアンプ５００の製品名や型番が表示される。またこのXXXの部分にAVアンプ５００の他、テレビ４００の製品名や型番を表示させ、これらをユーザ操作に応じて選択させるようにしてもよい。こうすることで、デコードを行わせる機器をユーザに選択させてもよい。更に、ユーザが何台もAVアンプを所有しているような場合、これらの製品名や型番を表示させ、これらをユーザ操作に応じて選択させるのが望ましい。

このメニューに対して、Yesボタンを確定することでパススルー出力を希望する旨の操作を行った場合、DIBに応じた、PSR15におけるPlayercapability for Audioの設定を行う（ステップＳ７１）。そして、AVアンプ５００のデコード能力に応じたPrimaryオーディオストリームを選択させる手順をProcedure実行部４２に実行させる（ステップＳ７２）。以降、BD-ROMから読み出されたAVClipのPrimaryオーディオストリームを、パススルー出力させる（ステップＳ７３）。

AVアンプ５００でデコードを行うことを希望する操作を行わなかった場合、自機のデコード能力に応じたPSR１５を設定し、Primaryオーディオストリームを選択させる手順をProcedure実行部４２に実行させ（ステップＳ６９）、自機でデコードした音声(LPCM)を出力させる（ステップＳ７０）。
図４１、図４２は、DIBに応じて、PSR15におけるPlayer capability for Audioを設定する処理手順を示すフローチャートである。

図４１のフローチャートにおいてステップＳ２００は、DIBのCODINGTYPEが、DD+を示しているかを判定するものである。
DIBのCODING TYPEがDD+を示しているなら、ステップＳ２０１に移行する。ステップＳ２０１は、DIBのChannel Countに２よりも大きな値が記載されているか否かの判定である。ステップＳ２０１がyesである場合、ステップＳ２０３において、Dependent Substreamのcapabilityを、10b:Surround Capableに設定する。

ステップＳ２０１がnoである場合、ステップＳ２０５において、DependentSubstreamのcapabilityを、0１b:Stereo Capableに設定する。
図４２のフローチャートにおいてステップＳ８２は、DIBのCODINGTYPEが、MLPを示しているかを判定するものである。DIBのCODING TYPEがMLPを示しているなら、ステップＳ８２がyesになってステップＳ９１に移行する。ステップＳ９１は、DIBのChannel Countが２ｃｈより大きいか否かの判定である。

ステップＳ９１がYESである場合、ステップＳ９３において、MLPのcapabilityを、10b:Surround Capableに設定する。ステップＳ９１がNOである場合、ステップＳ９４において、MLPのcapabilityを、０１b:Stereo Capableに設定する。
図４１のＳ２０１、図４２のＳ９１の判定ではＤＩＢのChannel Countを用いたが、Channel/Speaker Allocationを用いても判定しても良い。

以上のように本実施形態によれば、HDMIのようにデジタルI/Fを介し、接続相手の能力を取得し、それに応じてPSR15を設定した上、このPSR15に基づき、PrimaryオーディオストリームをBD-ROMディスク/ローカルストレージから選択して、このPrimaryオーディオストリームのパススルー出力を行うので、接続相手のデコーダ資源を有効活用することができ、かかる有効活用により、高品質な音声再生を実現することができる。また、AVアンプとスピーカーはセットで開発/販売されることが多いため、スピーカーの特性に合わせた調節がAVアンプでは可能である。したがって、再生機器が内部デコーダでデコードできる場合であっても、接続先のAVアンプでデコードする方が音響学的に高音質な再生結果を得られる。

（第３実施形態）
第１実施形態におけるローカルストレージ２００は、再生装置内蔵型のハードディスクであったが、本実施形態におけるローカルストレージ２００は、可搬型の記録媒体であるSDメモリカードである。そして本実施形態は、この可搬型記録媒体に動的シナリオを記録して再生装置に提供する場合の改良に関する。

SDメモリカードは、セキュアな領域と、非セキュアな領域とをもった可搬型の記録媒体である。第１実施形態に示したようなローカルストレージ上のファイルは、暗号化されて非セキュアな領域に記録され、暗号鍵がセキュアな領域に記録される。セキュア領域に記録された暗号鍵はSDメモリカードによる認証により、正当性が確認されない限り、読み出されることはない。これにより非セキュア領域上のファイルは、不正にコピーされることなく、BD-ROMと併用されるときのみ読み出されることになる。

動的シナリオとは、第１実施形態に示したＪａｖａ（登録商標）アプリケーション、Movie Objectであり、PlayList情報を通じた再生を、再生装置に行わせるプログラムである。かかる動的シナリオは、BD-ROM１００に記録される場合と、ローカルストレージ２００に記録される場合とがあるが、動的シナリオが可搬型記録媒体に記録されていると、かかる記録媒体に記録された動的シナリオは、様々な場所に設置された再生装置に供される。時には、自動車の車内に設置された再生装置３００に供されることもある。

図４３（ａ）は、自動車の車内に設置された再生装置３００を示す図である。かかる再生装置３００は、テレビ４００と共に、カーオーディオシステムを構成するものである、可搬型のローカルストレージ２００は、BD-ROM１００と共に、かかる再生装置３００に導入されることがある。
このように自動車車内に設置される場合、かかる再生装置３００は、CD再生装置のように操作されることを明らかにするのが望ましい。このように、CD再生装置のように操作されるべきであることを示すべく、本実施形態にかかるPSR31は、図４３（ｂ）のように構成されている。

図４３（ｂ）は、第３実施形態にかかるPSR31の内部構成を示す図である。本実施形態におけるPSR31は、自動車内に設置された場合、Player Profile情報＝1000bを示すように、メーカーの技術者、又は、最終消費者により設定される。PSR31におけるPlayer Profile情報が1000bに設定された場合、当該再生装置は、Audio Profile Playerであることを示す。Audio ProfilePlayerとは、対話画面を介した操作には適さず、CDプレーヤーライク（CD再生装置のようなリニアな操作のみでコンテンツの再生制御を行なうBD-ROM再生装置であり、GUIによるコンテンツの再生制御などに対応していない再生機器、もしくは車が走行していることを感知し一時的にそのようなモードに遷移する再生機器）であることを示す。

再生装置がCDプレーヤーライクである場合、チャプタースキップ、チャプターサーチ等、チャプターを単位とした操作で、コンテンツは再生されねばならない。かかるチャプターは、図１７に示したPlayListMark情報に規定されている
以降、PlayListMark情報について説明をはじめる。
図４４は、PlayList情報におけるPlayListMark情報の内部構成を示す図である。本図の図中の引き出し線pm0に示すように、PlayListMark情報は、複数のPLMark情報(#1〜#n)からなる。PLmark情報(PLmark())は、PL時間軸のうち、任意の位置を、チャプター点として指定する情報である。引き出し線pm1に示すようにPLmark情報は、チャプター指定の対象たるPlayItemを示す『ref_to_PlayItem_Id』と、そのPlayItemにおける、チャプター位置を時間表記により示す『mark_time_stamp』とを含む。

図４５は、PlayList情報の、PLMark情報によるチャプター位置の指定を示す図である。本図の第2段目から第5段目は、図１０に示した、EP_mapと、AVClipとを示す。
本図の第1段目は、PLMark情報と、PL時間軸とを示す。この第1段目には、2つのPLMark情報#1〜#2が存在する。矢印kt1,2は、PLMark情報のref_to_PlayItem_Idによる指定を示す。この矢印からもわかるようにPLMark情報のref_to_PlayItem_Idは、参照するPlayItemを指定していることがわかる。また、Mark_time_Stampは、当該PlayItem時間軸のうち、Chapter#1,#2になるべき時点を示す。このように、PLMark情報は、PlayItem時間軸上に、チャプター点を定義することができる。

以上が、PLMark情報についての説明である。続いて動的シナリオにおける改良について説明する。
再生装置組み込み型のプログラムの場合、自動車車内で利用されるか、又は、ホームシアターシステムで使用されるかは、製造の段階で、判明している。しかしBD-ROM１００や可搬型ローカルストレージ２００に記録されて再生装置に供給される動的シナリオ(Movie Object、Ｊａｖａ（登録商標）アプリケーション）は、様々な再生装置に装填されることが考えられるので、再生装置の利用形態が、このどちらであるかは特定できない。BD-ROM１００や、SDメモリカードであるローカルストレージ２００をどのような再生装置で利用するかは、ユーザが任意に決めるものだからである。

そこでPlayer Profile情報がAudioProfile Playerを示すように設定された場合もしくはされている場合、Movie Object、Ｊａｖａ（登録商標）アプリケーションは、CDプレーヤーライクな操作で操作されるよう、再生装置を制御せねばならない。一方、Player Profile情報がこれ以外に設定された場合、対話画面を通じた処理にて操作することが望ましい。
図４６は、本実施形態にかかるＪａｖａ（登録商標）アプリケーションの処理手順を示すフローチャートである。

ステップＳ１４９は、PSR31がAudio ProfilePlayerであるか否かを判定する。もし、Audio Profile Playerでないなら、プレイリストの再生を開始させる（ステップＳ１５０）。以降、ステップＳ１５１のループ処理に移行する。
その後、ステップＳ１５１は、メニューコール操作がなされたか否かの操作待ちループ処理を構成する。もしメニューコールがなされれば、メニューを表示して（ステップＳ１５２）、ステップＳ１５３〜ステップＳ１５６の処理に移行する。ステップＳ１５３は、フォーカス移動操作がでなされたか否かの判定であり、もしフォーカス移動操作がなされたなら、フォーカスを他のボタンに移動する（ステップＳ１５５）。

ステップＳ１５４は、ボタンの確定操作がなされたか否かの判定であり、もし確定操作がなされたなら、ボタンに対応する処理を実行する（ステップＳ１５６）。
ステップＳ１４９において、Audio Profile Playerであると判定された場合（ステップＳ１４９でyes）、音声アナウンスのプレイリストの再生を開始させて、ユーザーにリニアなCDライクな再生を行なうことを説明する。そしてステップS１５８、ステップＳ１５９からなるループ処理に移行する。

ステップＳ１５８は、数値入力がなされたか否か、ステップＳ１５９は、SkipNext又はSkipBackキーががなされたか否かの判定である。
数値入力がなされた場合、ステップＳ１６０に移行して、チャプターサーチを実行する。SkioNext,SkipBackキーが押下された場合、ステップＳ１６１に移行して、チャプタースキップ機能を実行する。

以上は、Ｊａｖａ（登録商標）アプリケーションの例で説明したが、MovieObjectである場合、ステップＳ１５３〜ステップＳ１５５の処理は、IGストリーム内のナビゲーションコマンドやMovieObjectのナビゲーションコマンドを用いて実現すればよい。動作の仕組みは同様であるので、説明は省略する。
以降、フローチャートを参照しながら、チャプターサーチ及びチャプタースキップの処理手順について説明する。図４７は、チャプターサーチの処理手順を示すフローチャートである。

まず始めに、入力された数値にあたるPLMark情報をカレントPlayListMarkとする(ステップＳ１２５)。ステップＳ１２６では、カレントPlayListMarkのref_to_PlayItem_Idに記述されているPIを、PlayItem#xに設定し、ステップＳ１２７では、PlayItem#xのClip_information_file_nameで指定されるClip情報を読み込む。ステップＳ１２８では、カレントClip情報のEP_mapを用いて、カレントPlayListMarkのmark_time_stampを、Iピクチャアドレスuに変換する。

一方ステップＳ１２９では、PlayItem#xのOut_timeを,カレントClip情報のEP_mapを用いて,Iピクチャアドレスvに変換する。ステップＳ１３０は、カレントPlayListMarkのmark_time_stampからPlayItem#xのOut_timeまでの出力をデコーダに命じる。以上がチャプターサーチの処理手順である。続いてチャプタースキップの処理手順について説明する。図４８は、チャプタースキップの処理手順を示すフローチャートである。

ステップＳ１３２は、押下されたのがSkipNextキーであるか、SkipBackキーであるかの判定であり、SkipBackキーであるならステップＳ１３３において方向フラグを-1に設定し、SkipNextキーであるならステップＳ１３４において方向フラグを+1に設定する。
ステップＳ１３５は、カレントPI及びカレントPTMを変換して、カレントPLMarkを特定するステップであり、ステップＳ１３６は、カレントPLMarkの番号に方向フラグの値を足した番号を、カレントPlayListMarkの番号として設定する。ここでSkipNextキーであるなら方向フラグは+1に設定されているのでカレントPlayListMarkはインクリメントされることになる。SkipBackキーであるなら方向フラグは-1に設定されているので、カレントPlayListMarkはデクリメントされることになる。このようにしてPLMark情報を設定すれば、図４７同様、ステップＳ１２６〜ステップＳ１３０の処理手順を実行することにより、TSパケット読み出しを行う。

以上がPLMark情報に基づく、再生を行う際の再生装置の処理手順である。
以上のように本実施形態によれば、PSR31がAudioProfile Playerを示している場合、Movie Object、Ｊａｖａ（登録商標）アプリケーションのような動的シナリオでCD再生装置と同等のユーザー操作性を与えるようにプレイリストを再生するようにすることが可能になる。この場合、ユーザーはBD-ROMを音楽CDと全く変わりなく操作することができる。つまり、チャプターサーチ/スキップが音楽CDで言う所の曲のサーチ/スキップに該当する。勿論、Audio Profile Playerではない再生装置上で動的シナリオが動作する場合は、今まで通り映像出力を仮定してGUIベースのメニューなどを表示し、インタラクティブな再生が可能になる。HDMIのように接続機器の状態をモニタリングできるI/Fを介して再生している場合には、モニターの電源ON/OFFや入力ソース映像の選択状況などを監視することでモニターが再生している映像を映さなくなっている場合には、PSR31をAudio Profile Playerに切り替えたり、再生を一時停止状態にしたり、再生機器３００の電源を連動してOFFとすることなども考えられる。

（第４実施形態）
第４実施形態は、第１実施形態に示したPlayList情報、Clip情報、AVClipを、どのように取得するかという、取得に関する実施形態である。かかる取得において、処理主体になるのは、Ｊａｖａ（登録商標）アプリケーションである。何故なら、Ｊａｖａ（登録商標）アプリケーションは、ネットワーク上でコネクションを形成し、サーバ装置から所望のファイルをダウンロードすることができる、能力をもっているからである。

サーバに存在するファイルを取得するためのコネクションは java.netと呼ばれるＪａｖａ（登録商標）ソフトウェアライブラリィのopenConnectionメソッドを使って、確立することができる。サーバ上のファイルのURLが、http:／／xxx.com／vp_data／0.m2tsである場合におけるコネクション接続の用例を以下に示す。

用例：
new java.net.URL(http:／／xxx.com／vp_data／0.m2ts.openConnection()

図４９は、第４実施形態にかかるＪａｖａ（登録商標）アプリケーションのフローチャートである。ステップＳ１８１において、BD-ROMにおけるプレイリストの再生を開始させる。その後、ステップＳ１８２では、BD-ROMから、そのBD-ROMの配給元となる法人、組織を示す情報(organization)と、そのBD-ROMの識別子(Disc_id)とを読みだす。

ステップＳ１８３では、そうして読み出されたorganization、Disc_idに対応する領域が、ローカルストレージ２００に存在しない否かを判定する。

かかる領域が存在しないなら、ステップＳ１８４では、PSR31におけるPlayer Profile情報が、0x0000でないかどうかを判定する。

ステップＳ１８３、ステップＳ１８４の何れかがNoである場合、処理を終了する。
organization、Disc_idに対応する領域が、ローカルストレージに存在せず、かつ音声のミキシングが可能である場合、ステップＳ１８３及びステップＳ１８４がyesになる。
ステップＳ１８３及びステップＳ１８４の双方がyesである場合、「アップデートボタン」が配置されたメニューを表示する（ステップＳ１８５）。そして、「アップデートボタン」に対する、確定操作待ちになる(ステップＳ１８６)。

図５０は、「アップデートボタン」が配置されたメニューの表示例を示す図である。本図における、「アップデートする」と記述されたボタンが、「アップデートボタン」であり、この「アップデートボタン」を確定する操作がなされれば、ステップＳ１８７においてDisc_id及びPlayList_idをサーバ装置に送信する。
Disc_idは、BD-ROMの識別情報であり、PlayList_idは、再生中プレイリストの識別情報であるので、サーバ装置は、これらを用いて、取得すべき追加コンテンツをコンテンツプロバイダのデータベース上から選択する。そうして選択された追加コンテンツをネットワーク経由で再生装置に送りかえす。この追加コンテンツは、ローカルストレージ２００に記録されるべきファイル一式（PlayList情報、Clip情報、AVClip）を含む。

ステップＳ１８８では、追加コンテンツの受信待ちを行い、もしこれらを受信すれば、ステップＳ１８９において、追加コンテンツを構成する、PlayList情報、Clip情報、AVClipをローカルストレージ２００に書き込む。その後、サーバ装置からのダウンロードが完了し、ミキシングしながらの再生が可能になった場合、ミキシングしながらの再生が可能になった旨をユーザーに通知して（ステップＳ１９０）。ミキシングを行う旨の操作をユーザが行ったか否かを判定するための処理待ちループになる（ステップＳ１９１）。ユーザーが希望する場合に、ステップＳ１９２においてPlayList情報の再生をいったん停止し、バーチャルパッケージの構築を行う。

アップデート有無のサーバーへの確認や、当該コンテンツのダウンロード処理は、任意のタイミングで実行が可能であるため、ディスクロード時や、コンテンツ再生中に所定時間間隔で行なっても良く、再生する準備が整った時点（バーチャルパッケージが再生できる状態となった時点）でユーザーに再生するかの問い合わせを行なってもよい。
以上のように本実施形態によれば、最初にプレイリストを再生する際、AVClipを再生させながら、ダウンロードを処理を行うので、ユーザは、プレイリストの再生画像をみながら、ローカルストレージ２００へのダウンロード完了を待てばよく、Secondaryオーディオストリームを構成するようなローカルストレージ２００上のファイルが、数百メガバイトに及ぶ場合でも、ローカルストレージ２００へのダウンロードがなされている間、ユーザを退屈させずにすむ。

尚、ローカルストレージ２００上の追加コンテンツを消去する条件を、再生装置３００に初期設定しておき、この初期設定に基づき、再生装置３００が追加コンテンツを削除するようにしてもよい。例えば、かかる初期設定において、時間の入力を受け付け、時間に応じて消去する(1ヶ月経つと勝手に消す)等の処理をするのが望ましい。
また、BD-ROMをイジェクトする際、ローカルストレージ２００上の追加コンテンツを消去するかどうかをユーザに問い合わせ、この問い合わせに対して、ユーザが肯定的が回答をした際に消去してもよい。

更に、BD-ROMが、読み出し専用領域と、書き込み可能領域とをもつパーシャルディスクである場合、ローカルストレージ２００上の追加コンテンツを、パーシャルディスク上の書き込み可能領域に書き込んでもよい。
(備考)
以上、本願の出願時点において、出願人が知り得る最良の実施形態について説明したが、 以下に示す技術的トピックについては、更なる改良や変更実施を加えることができる。各実施形態に示した通り実施するか、これらの改良・変更を施すか否かは、何れも任意的であり、実施する者の意思によることは留意されたい。

(追加コンテンツに対する処理)
ローカルストレージ２００にダウンロードされた追加コンテンツは、何ヶ月、何年か経過すれば自動的に消去するよう、再生装置を初期設定しておくのが望ましい。
（PIDの代用）
第１実施形態では、Primaryオーディオストリーム、Secondaryオーディオストリームの区別にPIDを用いたが、MPEG２-PSを使う場合には、PESパケットヘッダのstream_idをそれぞれ異なるものにするのが望ましい。

またPrimaryオーディオストリーム、Secondaryオーディオストリームは、２つの音声ストリームが１つのデマルチプレクサでも弁別可能なように、システムストリームレベルにおいて区別されていればよい。もしくは、２つのストリームを１つに束ねる前に、片方のPIDを重複しないように付け替えておくだけでもよい。
(制御手順の実現)
各実施形態においてフローチャートを引用して説明した制御手順や、機能的な構成要素による制御手順は、ハードウェア資源を用いて具体的に実現されていることから、自然法則を利用した技術的思想の創作といえ、“プログラムの発明”としての成立要件を満たす。

・本発明に係るプログラムの生産形態
本発明に係るプログラムは、コンピュータが実行することができる実行形式のプログラム(オブジェクトプログラム)であり、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA（登録商標）バイトコードというように、様々な種類がある。またプログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップが実現されることもある。

本発明にかかるプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。

記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。

オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。

・本発明に係るプログラムの使用形態
本発明に係るプログラムは、以下のようにして使用することができる。

(i)組込プログラムとしての使用
本発明に係るプログラムを組込プログラムとして使用する場合、プログラムにあたるロードモジュールを、基本入出力プログラム(BIOS)や、様々なミドルウェア(オペレーションシステム)と共に、命令ROMに書き込む。こうした命令ROMを、制御部に組み込み、CPUに実行させることにより、本発明に係るプログラムを、再生装置３００の制御プログラムとして使用することができる。

(ii)アプリケーションとしての使用
再生装置３００が、ハードディスク内蔵モデルである場合は、基本入出力プログラム(BIOS)が命令ROMに組み込まれており、様々なミドルウェア(オペレーションシステム)が、ハードディスクにプレインストールされている。また、ハードディスクから、システムを起動するためのブートROMが、再生装置３００に設けられている。

この場合、ロードモジュールのみを、過搬型の記録媒体やネットワークを通じて、再生装置３００に供給し、1つのアプリケーションとしてハードディスクにインストールする。そうすると、再生装置３００は、ブートROMによるブートストラップを行い、オペレーションシステムを起動した上で、1つのアプリケーションとして、当該アプリケーションをCPUに実行させ、本発明に係るプログラムを使用する。

ハードディスクモデルの再生装置３００では、本発明のプログラムを1つのアプリケーションとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネットワークを通じて供給することができる。

(コントローラ２２)
各実施形態に示したコントローラ２２等の構成要素は、一個のシステムLSIとして実現することができる。

システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも1つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッドフラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。

これらのピンは、他の回路とのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、他の回路を接続することにより、システムLSIは、再生装置３００の中核としての役割を果たす。
システムLSIにパッケージングされるベアチップは、“フロントエンド部”、“バックエンド部”、“デジタル処理部”からなる。“フロントエンド部”は、アナログ信号を、デジタル化する部分であり、“バックエンド部”はデジタル処理の結果、得られたデータを、アナログ化して出力する部分である。

各実施形態において内部構成図として示した各構成要素は、このデジタル処理部内に実装される。
先に“組込プログラムとしての使用”で述べたように、命令ROMには、プログラムにあたるロードモジュールや、基本入出力プログラム(BIOS)、様々なミドルウェア(オペレーションシステム)が書き込まれる。本実施形態において、特に創作したのは、このプログラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュールを格納した命令ROMを、ベアチップとしてパッケージングすることにより、本発明に係るシステムLSIは生産することができる。

具体的な実装については、SoC実装やSiP実装を用いることができ望ましい。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(System in Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置３００の内部構成図を基に作ることができる。

尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
さらに、各記録読出装置の構成要素の一部又は全てを1つのチップとして構成してもよい。集積回路化は、上述したSoC実装,SiP実装に限るものではなく、専用回路又は汎用プロセスで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA（Field Programmable Gate Array）や、LSI内部の回路セルの接続や設定を再構成可能なシリコンフィギュラブル・プロセッサを利用することが考えられる。更には、半導体技術の進歩又は派生する技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バイオ技術の適応などが可能性としてありうる。

本発明に係る再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが明らかなので、資質において工業上利用することができる。このことから本発明に係る再生装置は、産業上の利用可能性を有する。

本発明に係る記録媒体の、使用行為についての形態を示す図である。 BD-ROMの内部構成を示す図である。 拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。 AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。 BD-ROMの物理単位と、1つのファイルエクステントを構成するSourceパケットとの対応関係を示す図である。 AVClipにどのようなエレメンタリストリームが多重化されているかを示す図である。 Clip情報の内部構成を示す図である。 映画のビデオストリームに対するEP_map設定を示す図である。 PlayList情報のデータ構造を示す図である。 AVClipと、PlayList情報との関係を示す図である。 ファイルsound.bdmvの構成を示す図である。 ローカルストレージ２００の内部構成を示す図である。 SubClipに多重化されるエレメンタリストリームを示す図である。 BD-ROM規格におけるPID割当マップを示す図である。 （ａ）Secondaryオーディオストリームの内部構成を示す図である。（ｂ）オーディオフレームの一例を示す図である。（ｃ）メタデータの内部構成を示す図である。（ｄ）ゲイン制御情報の一例を模式的に示す図である。 Secondaryオーディオストリーム内のメタデータにより、Primaryオーディオストリームの音量がどのように制御されるかを示す図である。 PlayList情報のデータ構造を示す図である。 Subpath情報の内部構成をクローズアップして示す図である。 ローカルストレージ２００上のSubClipと、ローカルストレージ２００上のPlayList情報と、BD-ROM上のMainClipとの対応を示す図である。 MainClipに対して設定されたEP_map及びPlayItem時間軸と、Primaryオーディオストリーム、SecondaryオーディオストリームとなるSubClipに対して設定されたEP_map及びSubPlayItem時間軸とを集約して示す図である。 STN_tableの内部構成を示す図である。 （ａ）ビデオストリームに対応したStream_attributeを示す図である。 （ｂ）Primaryオーディオストリーム、Secondaryオーディオストリームに対応したStream_attributeを示す図である。 （ｃ）ビデオストリームにおけるStream_entryを示す図である。 （ｄ）SecondaryオーディオストリームにおけるStream_entryを示す図である。 （ｅ）SecondaryオーディオストリームにおけるStream_entryと、Stream_attributeとの組みに対応付けられている、Comb_info_Secondary_audio_Primary_audioの内部構成を示す図である。 Comb_info_Secondary_audio_Primary_audioによるPrimaryオーディオストリームの指定を示す図である。 再生装置３００により生成されるバーチャルファイルシステムを示す図である。 本発明に係る再生装置の内部構成を示す図である。 コントローラ２２を機能的に表現した図である。 （ａ）PSR1のビットアサインを示す図である。 （ｂ）PSR14のビットアサインを示す図である。 （ｃ）PSR31のビットアサインを示す図である。 プレイリスト処理部によるプレイリスト再生手順を示すフローチャートである。 （ａ）PSR1の設定値が取り得る状態遷移を示す図である。 （ｂ）PSR1のProcedure whenplayback condition is changedの処理手順を示す図である。 ステップＳ５の詳細な処理手順に示したフローチャートである。 ストリーム変化時におけるPSR1の設定手順を示すフローチャートである。 （ａ）PSR14の設定値が取り得る状態遷移を示す図である。 （ｂ）PSR14のProcedure whenplayback condition is changedの処理手順を示す図である。 ステップＳ３５の詳細な処理手順に示したフローチャートである。 ストリーム変化時におけるPSR14の設定手順を示すフローチャートである。 （ａ）再生装置３００、AVアンプ５００、スピーカ６００の接続形態を示す図である。 （ｂ）再生装置３００、テレビ４００、スピーカ６００のそれぞれで、チャンネル数がどのように変化するかを示す図である。 （ａ）DIBを示す図である。 （ｂ）DIBの各フィールドに設定しうる値を示す （ｃ）DIBを用いた再生装置３００、AVアンプ５００間の通信シーケンスを示す。 PSR２３におけるPSR15の内部構成を示す図である。 第２実施形態にかかるコントローラ２２の処理手順を示すフローチャートである。 パススルー出力を行うか否かの設定を受け付けるためのメニューを示す図である。 パススルー出力を行うか否かの設定を受け付けるためのメニューを示す図である。 DIBに応じて、PSR15におけるPlayer capability for Audioを設定する処理手順を示すフローチャートである。 DIBに応じて、PSR15におけるPlayer capability for Audioを設定する処理手順を示すフローチャートである。 （ａ）再生装置３００が自動車の車内に設置存在する場合の設置例を示す図である。 （ｂ）第３実施形態にかかるPSR31の内部構成を示す図である。 PlayList情報におけるPlayListMark情報の内部構成を示す図である。 PlayList情報の、PLMark情報によるチャプター位置の指定を示す図である。 第３実施形態にかかるＪａｖａ（登録商標）アプリケーションの処理手順を示すフローチャートである。 チャプターサーチの処理手順を示すフローチャートである。 チャプタースキップの処理手順を示すフローチャートである。 第４実施形態にかかるＪａｖａ（登録商標）アプリケーションのフローチャートである。 「アップデートボタン」が配置されたメニューの表示例を示す図である。

符号の説明

１００ BD-ROM
２００ ローカルストレージ
３００ 再生装置
４００ テレビ
５００ AVアンプ
６００ スピーカ
１a BD-ROMドライブ
１b バス
２a,b リードバッファ
３a,b デマルチプレクサ
４ ビデオデコーダ
５ ビデオプレーン
６a,b バッファ
７a,b オーディオデコーダ
８ DownMix/DownSample
９a ミキサー
９b ミキサー
１０a スイッチ
１０b エンコーダ
１１ Interactive Graphicsデコーダ
１２ Interactive Graphicsプレーン
１３ Presentation Graphicsデコーダ
１４ Presentation Graphicsプレーン
１５ JPEGデコーダ
１６ Stillプレーン
１７ 合成部
１８a,b STC生成部
１９a,b ATC生成部
２１ メモリ
２２ コントローラ
２３ PSRセット
２４ PID変換部
２５ 通信部
２６ 操作受付部
２７ HDMI送受信部
４１ プレイリスト処理部
４２ Procedure実行部
４３ Procedure実行部
４４ ミキシング制御部

Claims (4)

1. 符号化された状態のオーディオストリームを記録媒体から読み出して再生する再生装置であって、
   接続相手となる装置のデコード能力を判定する判定手段と、
   接続相手となる装置にデコード能力がある場合、接続相手となる装置に内蔵されているデコーダにて、デコードを行わせるかどうかを、ユーザに問い合わせる問合手段と、
   状態レジスタと、
   接続相手側のデコーダで、デコードを行う旨を指定する操作をユーザが行った場合、接続相手となる装置のデコード能力を、再生装置における状態レジスタに設定して、当該状態レジスタにおけるデコード能力の設定、及び、オーディオストリームの属性に基づき、再生の対象となるオーディオストリームを選択する選択手段と、
   選択されたオーディオストリームを、記録媒体から読み出して、符号化された状態のまま、接続相手となる装置に転送する転送手段と
   を備えることを特徴とする再生装置。
2. 前記選択手段は、
   前記記録媒体に複数のオーディオストリームが記録されている場合、接続相手となる装置が再生することができるオーディオストリームであって、自装置に設定されている言語属性と同一の言語属性を有し、かつマルチチャネル属性をもつものを選択し、
   転送手段による転送の対象は、選択手段が選択したオーディオストリームである
   ことを特徴とする請求項１記載の再生装置。
3. 符号化された状態のオーディオストリームを記録媒体から読み出して再生する処理をコンピュータに実行させるプログラムであって、
   接続相手となる装置のデコード能力を判定する判定ステップと、
   接続相手となる装置にデコード能力がある場合、接続相手となる装置に内蔵されているデコーダにて、デコードを行わせるかどうかを、ユーザに問い合わせる問合ステップと、
   接続相手側のデコーダで、デコードを行う旨を指定する操作をユーザが行った場合、接続相手となる装置のデコード能力を、コンピュータにおける状態レジスタに設定して、当該状態レジスタにおけるデコード能力の設定、及び、オーディオストリームの属性に基づき、再生の対象となるオーディオストリームを選択する選択ステップと、
   選択されたオーディオストリームを、記録媒体から読み出して、符号化された状態のまま、接続相手となる装置に転送する転送ステップと
   をコンピュータに実行させることを特徴とするプログラム。
4. 符号化された状態のオーディオストリームを記録媒体から読み出して再生する再生方法であって、
   接続相手となる装置のデコード能力を判定する判定ステップと、
   接続相手となる装置にデコード能力がある場合、接続相手となる装置に内蔵されているデコーダにて、デコードを行わせるかどうかを、ユーザに問い合わせる問合ステップと、
   接続相手側のデコーダで、デコードを行う旨を指定する操作をユーザが行った場合、接続相手となる装置のデコード能力を、コンピュータにおける状態レジスタに設定して、当該状態レジスタにおけるデコード能力の設定、及び、オーディオストリームの属性に基づき、再生の対象となるオーディオストリームを選択する選択ステップと、
   選択されたオーディオストリームを、記録媒体から読み出して、符号化された状態のまま、接続相手となる装置に転送する転送ステップと
   を含むことを特徴とする再生方法。

Images