(57)【要約】ＢＤ−ＲＯＭには、ＡＶＣｌｉｐと、Ｊａｖａ（登録商標）アプリケーションとが記録されている。このＡＶＣｌｉｐには、ビデオストリーム及びオーディオストリームが多重化されている。またＢＤ−ＲＯＭには、管理情報と、これに対応するＭｉｘｉｎｇ＿Ｏｎフラグとが記録されており、前記管理情報は、Ｊａｖａ（登録商標）アプリケーションの実行と同時に開始すべきＡＶＣｌｉｐの再生制御を示す情報であり、Ｍｉｘｉｎｇ＿Ｏｎフラグは、Ｊａｖａ（登録商標）アプリケーションに対するユーザ操作に応じたクリック音と、前記再生制御時におけるＡＶＣｌｉｐの音声出力とをミキシングするか否かを示す。【特許請求の範囲】
【請求項１】
多重化されたビデオストリーム及びオーディオストリームを含むデジタルストリームと、アプリケーションとが記録された記録媒体であって、
管理情報と、これに対応するフラグとが記録されており、
前記管理情報は、
アプリケーションの実行と同時に開始すべきデジタルストリームの再生制御を示す情報であり、
前記フラグは、
アプリケーションに対するユーザ操作に応じたクリック音と、前記再生制御時におけるデジタルストリームの音声出力とをミキシングするか否かを示す
ことを特徴とする記録媒体。
【請求項２】
前記管理情報は、エントリー情報を含み、
前記エントリー情報は、
デジタルストリームの再生制御時において、音声出力が可能となるオーディオストリームを示し、
前記フラグは、
音声出力可能とされているオーディオストリームが、マルチチャネル属性をもっている場合、ミキシング不可を示すよう設定され、
音声出力可能とされているオーディオストリームが、マルチチャネル属性をもっていない場合、ミキシング可能を示すよう設定される
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
前記管理情報は、ビデオストリーム上の再生開始時刻及び再生終了時刻の組みを示すことにより、再生経路を規定する再生経路情報と、
前記再生経路の属性を示す属性情報とを含み、
前記管理情報により示される再生制御とは、所定の再生属性が付加された再生経路情報に示される再生経路に従って、デジタルストリームを再生することである、請求項１記載の記録媒体。
【請求項４】
所定の再生属性とは、再生経路情報に示される再生経路を用いた再生を自動的に開始する旨を示す属性であり、
前記デジタルストリーム再生の同時実行は、
再生経路情報に自動再生を示す再生属性が付加されている場合になされる、ことを特徴とする請求項３記載の記録媒体。
【請求項５】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数再生経路情報のうち、何れか１つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性である
ことを特徴とする請求項１記載の記録媒体。
【請求項６】
前記フラグは、
クリック音の再生を意図した命令又はコードが、前記アプリケーションを構成するプログラムの中に存在する場合、ミキシング不可を示すよう設定され、
クリック音の再生を意図した命令又はコードが、前記アプリケーションを構成するプログラムの中に存在しない場合、ミキシング可能を示すよう設定される
ことを特徴とする請求項１記載の記録媒体。
【請求項７】
アプリケーションを実行すると共に、デジタルストリームを再生する再生装置であって、
管理情報と、これに対応するフラグとを記録媒体から読み出す読出手段と、
記録媒体に記録されたアプリケーションを実行するプラットフォーム部と、
アプリケーションの実行と同時に、管理情報に示された再生制御を実行することにより、デジタルストリームを再生して、映像出力及び音声出力を行う再生制御エンジン部と、
管理情報に対応したフラグがオンである場合、アプリケーションに対するユーザ操作に応じたクリック音と、音声出力とのミキシングを実行するが、管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシング部と
を備えることを特徴とする再生装置。
【請求項８】
前記管理情報は、エントリー情報を含み、
前記エントリー情報は、
デジタルストリームの再生制御時において、音声出力が可能となるオーディオストリームを示し、
前記フラグは、
音声出力可能とされているオーディオストリームが、マルチチャネル属性をもっている場合、オンを示すよう設定され、
音声出力可能とされているオーディオストリームが、マルチチャネル属性をもっていない場合、オフを示すよう設定され、
前記再生制御エンジンは、
デジタルストリームに多重化されているオーディオストリームのうち、エントリー情報において音声出力可能と示されているもののみをデコードして、音声出力を行い、
前記サウンドミキシングは、フラグに基づき、音声出力とのミキシングを実行する
ことを特徴とする請求項７記載の再生装置。
【請求項９】
前記管理情報は、ビデオストリーム上の再生開始時刻及び再生終了時刻の組みを示すことにより、再生経路を規定する再生経路情報と、
前記再生経路の属性を示す属性情報とを含み、
前記再生制御エンジンに基づく再生制御とは、所定の再生属性が付加された再生経路情報に示される再生経路に従って、デジタルストリームを再生することである、請求項７記載の再生装置。
【請求項１０】
所定の再生属性とは、再生経路情報に示される再生経路を用いた再生を自動的に開始する旨を示す属性であり、
前記再生制御エンジンによるデジタルストリーム再生の同時実行は、
再生経路情報に自動再生を示す再生属性が付加されている場合になされる、ことを特徴とする請求項９記載の再生装置。
【請求項１１】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数再生経路情報のうち、何れか１つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性である
ことを特徴とする請求項９記載の再生装置。
【請求項１２】
前記プラットフォーム部は、
何れかの再生経路情報を指定した再生がアプリケーションから命じられた場合、当該アプリケーションの正当性を認証するパーミッションコントローラを備え、
前記再生制御エンジン部が再生経路情報に基づく再生を行うのは、パーミッションコントローラが正当性ありと認証した場合である
ことを特徴とする請求項９記載の再生装置。
【請求項１３】
プラットフォーム部は、再生経路情報に基づく再生を行うアプリケーションが存在する場合、当該アプリケーションが再生可能な再生経路情報を判定して、当該アプリケーションに通知し、
前記再生制御エンジン部による再生は、通知された再生経路情報に基づく
ことを特徴とする請求項９記載の再生装置。
【請求項１４】
前記再生装置は、
アプリケーションの実行画像を格納する第１プレーンと、
映像として出力されるべき再生画像を格納する第２プレーンと、
アプリケーションの実行画像を親画面に配置し、再生制御時における映像出力を子画面に配置した合成画像を出力する合成部とを含む
ことを特徴とする請求項７記載の再生装置。
【請求項１５】
前記プラットフォーム部は更に、
アプリケーションが起動されるまでのスタートアップディレイにおいて、デジタルストリームの再生画像を主画像とするよう、第１プレーンの格納内容をスケーリングする制御を行い、
前記合成画像を、アプリケーションが正常に起動した後に出力する
ことを特徴とする請求項１４記載の再生装置。
【請求項１６】
アプリケーションの実行を管理すると共に、デジタルストリームの再生をコンピュータに実行させる管理プログラムであって、
管理情報と、これに対応するフラグとを記録媒体から読み出す読出ステップと、
記録媒体に記録されたアプリケーションを実行するステップと、
アプリケーションの実行と同時に、管理情報に示された再生制御を実行することにより、デジタルストリームを再生して、映像出力及び音声出力を行う再生制御ステップと、
管理情報に対応したフラグがオンである場合、アプリケーションに対するユーザ操作に応じたクリック音と、音声出力とのミキシングを実行するか、管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシングステップと
をコンピュータに実行させることを特徴とする管理プログラム。
【請求項１７】
アプリケーションを実行すると共に、デジタルストリームを再生する再生方法であって、
管理情報と、これに対応するフラグとを記録媒体から読み出す読出ステップと、
記録媒体に記録されたアプリケーションを実行するステップと、
アプリケーションの実行と同時に、管理情報に示された再生制御を実行することにより、デジタルストリームを再生して、映像出力及び音声出力を行う再生制御ステップと、
管理情報に対応したフラグがオンである場合、アプリケーションに対するユーザ操作に応じたクリック音と、音声出力とのミキシングを実行するか、管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシングステップと
を含むことを特徴とする再生方法。
【請求項１８】
アプリケーションを実行すると共に、デジタルストリームを再生する再生装置に組み込まれる集積回路であって、
再生装置の制御により記録媒体から読み出されたアプリケーションを実行するプラットフォーム部と、
アプリケーションの実行と同時に、記録媒体から読み出された管理情報に示された再生制御を実行することにより、デジタルストリームを再生して、映像出力及び音声出力を行う再生制御エンジン部と、
管理情報に対応したフラグがオンである場合、アプリケーションに対するユーザ操作に応じたクリック音と、音声出力とのミキシングを実行するか、管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシング部と
を備えることを特徴とする集積回路。
【発明の詳細な説明】
【技術分野】
【０００１】  クリック音再生の技術分野に属する発明である。
【背景技術】
【０００２】  クリック音再生とは、映画作品の再生中において表示されたＧＵＩに対し、ユーザが操作を行った場合、その操作に呼応して、映画作品中の再生音声に、クリック音をサウンドミキシングして出力する技術である。
例えば映画作品の再生中に表示されるＧＵＩが、「ゲームの開始」といった機能の実行指示を受け付けるものであり、この実行指示に応じて、「これからゲームを始めるよ」との音声アナウンスをクリック音として、映画本編の音声にサウンドミキシングして出力する場合を考える。この音声アナウンスが、映画作品に登場するキャラクターの声によるものなら、幼年者たるユーザは、この音声アナウンスにより、映画作品に登場するキャラクターから語りかけられているような印象を受ける。以上のクリック音再生の導入により、幼年者が楽しく遊べるようなＧＵＩを映画作品に導入することができる。【０００３】  ここで１つの音声出力に、別の音声出力をミキシングして出力する技術には、以下の特許文献１に記載されているものがある。
【特許文献１】特開平７−３２０４１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】  ところでクリック音のサウンドミキシングを行うには、デジタル化されたオーディオストリームを一旦、ＬＰＣＭ状態まで展開せねばならない。ここでサウンドミキシングの対象となる本編側のオーディオストリームが５．１チャネルといったマルチチャネル属性をもっている場合、展開されたＬＰＣＭ状態でのデータ量は、多大なものとなる。従って、マルチチャネル属性をもっているオーディオストリームに、クリック音をサウンドミキシングして、デジタル音声出力を行う場合、帯域上の制限から、ある種類のデジタルインターフェイスでは、デジタル音声出力が不可能になってしまうことがある。近年の映画は、音響面を重視していることが多く、またユーザも、アンプやサラウンドスピーカ等、巨額な私費を投じて、プライベートな音響システムを構築しているケースが多いので、クリック音をサウンドミキシングしようとした途端、映画本編のデジタル音声出力が不可能になるというのでは、映画に対するマイナスイメージが図りしれない。【０００５】  クリック音の導入により“マルチチャネルの音声出力が途切れるのではないか”という不安の呪縛がある限り、クリック音という機能自体が、映画制作に使用されないとのケースが多発する。かかる呪縛から、映画制作スタジオを解放するには、再生装置に再エンコードを行わせるという考えを、あらゆる再生装置に義務付ければよい。つまり再生装置内にエンコーダを具備しておき、５．１チャネルといったマルチチャネル属性をもっているオーディオストリームをＬＰＣＭ状態に展開して、クリック音をミキシングした後、これを再エンコードした上で、デジタル出力を行えばよい。具体的にいうと、ミキシングした音声のデジタル音声出力をＳ／ＰＤＩＦ（Ｓｏｎｙ／Ｐｈｉｌｉｐｓ  Ｄｉｇｉｔａｌ  ＩｎｔｅｒＣｏｎｎｅｃｔ  Ｆｏｒｍａｔ，ＩＳＯ６０９５８−３規格）のようなデジタルインターフェースを介して、実行する場合、上述した再エンコードを行い、ドルビーデジタルやＤＴＳへと変換することが必要になる。しかしかかる再エンコードには、エンコーダの具備が必須となるので、とてもではないが、ＢＤ−ＲＯＭ再生装置の標準モデルとして採用されるものではない。【０００６】  本発明の目的は、音声出力に対する弊害をもたらすことなく、クリック音のサウンドミキシング出力を実現することができる記録媒体を提供することである。
【課題を解決するための手段】
【０００７】  上記目的は、多重化されたビデオストリーム及びオーディオストリームを含むデジタルストリームと、アプリケーションとが記録された記録媒体であって、管理情報と、これに対応するフラグとが記録されており、前記管理情報は、アプリケーションの実行と同時に開始すべきデジタルストリームの再生制御を示す情報であり、前記フラグは、アプリケーションに対するユーザ操作に応じたクリック音と、前記再生制御時におけるデジタルストリームの音声出力とをミキシングするか否かを示すことを特徴とする記録媒体により達成される。
【発明の効果】
【０００８】  本発明は上述した構成を有しているので、マルチチャネルでの音声出力を意図するような再生制御の実行時にはサウンドミキシングを無効化しておき、マルチチャネルでの音声出力を意図しないような再生制御の実行時にはサウンドミキシングを有効化しておくことができる。
これにより、映画の制作スタジオは、マルチチャネルでの再生を意図している場合は、クリック音を禁止し、代わりにクリック音での再生を意図している場合は、代わりにマルチチャネルによる音声出力を禁止するという調整が可能になる。【０００９】  かかる調整の上で、クリック音を映画制作に導入すれば“マルチチャネルの音声出力が途切れるのではないか”という不安の呪縛から、制作スタジオを解放することができる。これにより映画作品作成にあたってのクリック音の導入に弾みをつけることができる。
【図面の簡単な説明】
【００１０】
【図１】本発明に係る記録媒体の使用行為を示す図である。
【図２】ＢＤ−ＲＯＭの内部構成を示す図である。
【図３】拡張子．ｍ２ｔｓが付与されたファイルがどのように構成されているかを模式的に示す図である。
【図４】ＡＶＣｌｉｐを構成するＴＳパケットがどのような過程を経てＢＤ−ＲＯＭに書き込まれるかを示す図である。
【図５】ＡＶＣｌｉｐを構成するＴＳパケットがどのような過程を経てＢＤ−ＲＯＭに書き込まれるかを示す図である。
【図６】Ｃｌｉｐ情報の内部構成を示す図である。
【図７】映画のビデオストリームに対するＥＰ＿ｍａｐ設定を示す図である。
【図８】ＰｌａｙＬｉｓｔ情報のデータ構造を示す図である。
【図９】ＡＶＣｌｉｐと、ＰｌａｙＬｉｓｔ情報との関係を示す図である。
【図１０】（ａ）ＳＴＮ＿ｔａｂｌｅの構成を示す図である。
【００１１】  （ｂ）〜（ｅ）ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの詳細を示す図である。【図１１】ＰｌａｙＬｉｓｔ情報の、ＰｌａｙＬｉｓｔＭａｒｋ情報の内部構成を示す図である。
【図１２】ＰｌａｙＬｉｓｔ情報の、ＰｌａｙＬｉｓｔＭａｒｋ情報によるチャプター位置の指定を示す図である。
【図１３】ＢＤ−Ｊ  Ｏｂｊｅｃｔの内部構成を示す図である。
【図１４】アーカイブファイルにより収められているプログラム、データを示す図である。
【図１５】ファイルｓｏｕｎｄ．ｂｄｍｖの構成を示す図である。
【図１６】（ａ）アプリケーション管理テーブルの内部構成を示す図である。
【００１２】  （ｂ）アプリケーション管理テーブルを構成する情報要素の意味内容を示す図である。【図１７】ディスクコンテンツにおける状態遷移を示す図である。
【図１８】（ａ）ＢＤ−ＲＯＭ全体の時間軸を示す図である。（ｂ）ＢＤ−ＲＯＭ全体の時間軸における構成を示す図である。
【図１９】（ａ）（ｂ）ＢＤ−ＲＯＭ全体の時間軸において、ＢＤ−Ｊ  Ｏｂｊｅｃｔから特定されるタイトル再生区間を示す図である。
【図２０】図１９（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。
【図２１】本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。
【図２２】（ａ）（ｂ）アプリケーション管理テーブル、生存区間の一例を示す図である。
【図２３】起動属性がとり得る三態様（Ｐｒｅｓｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。
【図２４】（ａ）プレイリスト管理テーブルの内部構成を示す図である。
【００１３】  （ｂ）プレイリスト管理テーブルを構成する情報要素の意味内容を示す図である。【図２５】プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。
【図２６】カレントタイトルがとり得る三態様（プレイリスト管理テーブル無し、プレイリスト管理テーブル有りで尚且つ無指定、プレイリスト管理テーブル有りで尚且つＡｕｔｏＰｌａｙ）と、直前タイトルにおけるＰＬの状態（非再生状態、再生中状態）とがとりうる６通りの組合せを示す図である。
【図２７】（ａ）プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例を示す図である。
【００１４】  （ｂ）図２７（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。【図２８】（ａ）プレイリスト管理テーブルの他の記述例を示す図である。
【００１５】  （ｂ）図２８（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。【図２９】ＳＭＴの内部構成を示す図である。
【図３０】（ａ）（ｂ）は、ＳＴＮ＿Ｔａｂｌｅにおけるオーディオストリームについてのｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅと、Ｍｉｘｉｎｇ＿Ｏｎフラグの設定との因果関係を示す図である。
【図３１】Ｍｉｘｉｎｇ＿ＯｎフラグがＯＮに設定されたタイトルにおいて、ＧＵＩフレームワーク上のボタンが操作された場合の、再生装置による音声再生を示す図である。
【図３２】Ｍｉｘｉｎｇ＿ＯｎフラグがＯＦＦに設定されたタイトルにおいて、ＧＵＩフレームワーク上のボタンが操作された場合の、再生装置による音声再生を示す図である。
【図３３】本発明に係る再生装置の内部構成を示す図である。
【図３４】ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。
【図３５】Ｊａｖａ（登録商標）仮想マシン３６の内部構成を示す図である。
【図３６】Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４による処理を模式化した図である。
【図３７】ＢＤ−Ｊ  ＯｂｊｅｃｔにおけるＰＬＭＴに基づく、アプリケーションマネージャ３７の処理を示す図である。
【図３８】ＢＤ−Ｊ  ＯｂｊｅｃｔにおけるＳＭＴに基づく、アプリケーションマネージャ３７の処理を示す図である。
【図３９】アプリケーションマネージャ３７による処理手順を示すフローチャートである。
【図４０】（ａ）第２実施形態に係るプレイリスト情報の内部構成を示す図である。
【００１６】  （ｂ）は、ＰｌａｙＩｔｅｍ情報内に設けられた、Ｍｉｘｉｎｇ＿Ｏｎフラグの内容を示す図である。【図４１】Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２によるプレイリスト再生手順を示すフローチャートである。
【図４２】アプリケーションマネージャ３７による通知処理の処理手順を示すフローチャートである。
【図４３】第３実施形態に係るアプリケーションマネージャ３７の処理手順を示す図である。
【図４４】（ａ）パレンタルレベルに基づく選択アルゴリズムの内容を示す。
【００１７】  （ｂ）Ｌａｎｇｕｅｇｅ  ｆｏｒ  Ａｕｄｉｏに基づく選択アルゴリズムの内容を示す。
（ｃ）Ｐｌａｙｅｒ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｆｏｒ  Ｖｉｄｅｏに基づく選択アルゴリズムの内容を示す。【図４５】タイトルアンバウンダリーアプリケーションにプレイリスト選択を行わせる過程を模式的に描いた図である。
【符号の説明】
【００１８】      １  ＢＤ−ＲＯＭドライブ
２  リードバッファ
３  デマルチプレクサ
４  ビデオデコーダ
５  ビデオプレーン
６  サウンドプロセッサ
７  サウンドプロセッサ
８  ミキサー
９  サウンドコントローラ
１０  Ｄ／Ａコンバータ
１１  Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓデコーダ
１２  Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン
１３  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓデコーダ
１４  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン
１５  ＪＰＥＧデコーダ
１６  Ｓｔｉｌｌプレーン
１７  合成部
１８  ＳＴＣ−ｄｅｌｔａ付加部
１９  ＡＴＣ−ｄｅｌｔａ付加部
２０  ローカルストレージ
２１  命令ＲＯＭ
２２  ユーザイベント処理部
２３  ＰＳＲセット
２４  ＣＰＵ
２５  シナリオメモリ
２６  ローカルメモリ
【発明を実施するための最良の形態】
【００１９】  （第１実施形態）
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体はＢＤ−ＲＯＭ１００であり、ＢＤ−ＲＯＭ１００は、再生装置２００、リモコン３００、テレビ４００、サラウンドスピーカに接続されたアンプ５００により形成されるホームシアターシステムに、著作物を供給するという用途に供される。【００２０】  本システムにおいて再生装置２００は、ＢＤ−ＲＯＭ１００に記録されている各種データを再生して、映像出力及び音声出力を行う。この再生装置２００による映像出力は、ＨＤＭＩ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ  Ｍｕｌｔｉｍｅｄｉａ  Ｉｎｔｅｒｆａｃｅ）、その他アナログインターフェイスを介して、テレビ４００に出力される。また、再生装置２００による音声出力は、Ｓ／ＰＤＩＦ又はＨＤＭＩ、その他アナログインターフェイスを介して、テレビ４００又はアンプ５００に出力される。【００２１】  以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、ＢＤ−ＲＯＭのファイルシステム上における改良で実現することができる。図２は、ＢＤ−ＲＯＭにおけるファイル・ディレクトリ構成を示す図である。本図においてＢＤ−ＲＯＭには、Ｒｏｏｔディレクトリの下に、ＢＤＭＶディレクトリがある。【００２２】  ＢＤＭＶディレクトリには、拡張子ｂｄｍｖが付与されたファイル（ｉｎｄｅｘ．ｂｄｍｖ，ＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖ）がある。そしてこのＢＤＭＶディレクトリの配下には、更にＰＬＡＹＬＩＳＴディレクトリ、ＣＬＩＰＩＮＦディレクトリ、ＳＴＲＥＡＭディレクトリ、ＢＤＢＪディレクトリ、ＢＤＪＡディレクトリ、ＡＵＸＤＡＴＡディレクトリと呼ばれる６つのサブディレクトリが存在する。
ＰＬＡＹＬＩＳＴディレクトリには、拡張子ｍｐｌｓが付与されたファイル（００００１．ｍｐｌｓ，００００２．ｍｐｌｓ，００００３ｍｐｌｓ）がある。【００２３】  ＣＬＩＰＩＮＦディレクトリには、拡張子ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ）がある。
ＳＴＲＥＡＭディレクトリには、拡張子ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ）がある。
ＢＤＢＪディレクトリには、拡張子ＢＯＢＪが付与されたファイル（００００１．ｂｏｂｊ，００００２．ｂｏｂｊ，００００３．ｂｏｂｊ）が存在する。【００２４】  ＢＤＪＡディレクトリには、拡張子ｊａｒが付与されたファイル（００００１．ｊａｒ，００００２．ｊａｒ，００００３．ｊａｒ）がある。
ＡＵＸＤＡＴＡディレクトリには、ファイルｓｏｕｎｄ．ｂｄｍｖが格納される。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、ＢＤ−ＲＯＭ上に配置されていることがわかる。【００２５】  ＜ＢＤ−ＲＯＭの構成その１．ＡＶＣｌｉｐ＞
先ず初めに、拡張子．ｍ２ｔｓが付与されたファイルについて説明する。図３は、拡張子．ｍ２ｔｓが付与されたファイルがどのように構成されているかを模式的に示す図である。拡張子．ｍ２ｔｓが付与されたファイル（００００１．ｍ２ｔｓ，００００２．ｍ２ｔｓ，００００３．ｍ２ｔｓ・・・・・）は、ＡＶＣｌｉｐを格納している。ＡＶＣｌｉｐはＭＰＥＧ２−Ｔｒａｎｓｐｏｒｔ  Ｓｔｒｅａｍ形式のデジタルストリームである。このデジタルストリームは、フィルム映像、ＮＴＳＣ映像、ＰＡＬ映像をデジタル化することにより得られたデジタルビデオ、ＬＰＣＭ音源、ＡＣ−３音源、ＤＴＳ音源をデジタル化することにより得られたデジタルオーディオを（上１段目）、ＰＥＳパケットからなるエレメンタリストリームに変換し（上２段目）、更にＴＳパケットに変換して（上３段目）、同じく字幕系のプレゼンテーショングラフィクスストリーム（Ｐｒｅｓｅｎｔａｔｉｉｏｎ  Ｇｒａｐｈｉｃｓ（ＰＧ）ストリーム）及び対話系のインタラクティブグラフィクスストリーム（Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓ（ＩＧ）ストリーム）を（下１段目）を、ＰＥＳパケット列に変換し（下２段目）、更にＴＳパケットに変換して（下３段目）、これらを多重化することで構成される。【００２６】  ＰＧストリームとは、動画の再生進行に伴った字幕表示を実現するエレメンタリストリームであり、ＩＧストリームは、動画の再生進行に伴ったＧＵＩを実現するエレメンタリストリームである。
ＰＥＳパケット化されたデジタル映像はビデオストリームと呼ばれ、又はＰＥＳパケット化された音声は、オーディオストリームと呼ばれる。これらビデオストリーム、オーディオストリームはエレメンタリストリームであり、独立復号可能な単位として、“Ａｃｃｅｓｓ  Ｕｎｉｔ”が存在する。ビデオストリームでは、いわゆるＧＯＰ（Ｇｒｏｕｐ  Ｏｆ  Ｐｉｃｔｕｒｅ）が、この“Ａｃｃｅｓｓ  Ｕｎｉｔ”に該当する。【００２７】  ビデオストリームのうち、１つのＰＴＳで再生される再生単位（ピクチャ等）を、“Ｖｉｄｅｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ”という。オーディオストリームのうち、１つのＰＴＳで再生される再生単位を、“Ａｕｄｉｏ  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｕｎｉｔ”という。
ここでＡＶＣｌｉｐを構成するＰＥＳパケットは、１つ以上の“ＳＴＣ＿Ｓｅｕｅｎｃｅ”を構成する。“ＳＴＣ＿Ｓｅｕｅｎｃｅ”とは、ＰＥＳパケットの配列であって、そのＰＴＳ、ＤＴＳが参照しているＳｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ（ＳＴＣ）の値に、ＳＴＣ不連続点（ｓｙｓｔｅｍ  ｔｉｍｅ−ｂａｓｅ  ｄｉｓｃｏｎｔｉｎｕｉｔｙ）が存在しないものをいう。ＳＴＣ不連続点がないことがＳＴＣ＿Ｓｅｕｅｎｃｅの要件であるので、１つのＳＴＣ＿Ｓｅｕｅｎｃｅを構成するＰＥＳパケット列のうち、ＳＴＣ不連続点の直後に位置するＰＥＳパケットであって、ＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ）を包含したものから、次のＳＴＣ不連続点の直前までが１つのＳＴＣ＿Ｓｅｕｅｎｃｅになる。
続いて、以上のように構成されたＡＶＣｌｉｐが、ＢＤ−ＲＯＭにどのように書き込まれるかを説明する。図４は、ＡＶＣｌｉｐを構成するＴＳパケットがどのような過程を経てＢＤ−ＲＯＭに書き込まれるかを示す。本図の第１段目にＡＶＣｌｉｐを構成するＴＳパケットを示す。【００２８】  ＡＶＣｌｉｐを構成する１８８バイトのＴＳパケットは、第２段目に示すように４バイトのＴＳ＿ｅｘｔｒａ＿ｈｅａｄｅｒ（図中のハッチング部）、が付されて、１９２バイト長のＳｏｕｒｃｅパケットになる。このＴＳ＿ｅｘｔｒａ＿ｈｅａｄｅｒは、Ａｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐを含む。
ＡＶＣｌｉｐを構成するＳｏｕｒｃｅパケットは、第３段目におけるＡＶＣｌｉｐにおいて、１つ以上の“ＡＴＣ＿Ｓｅｕｅｎｃｅ”を構成する。“ＡＴＣ＿Ｓｅｕｅｎｃｅ”とは、Ｓｏｕｒｃｅパケットの配列であって、そのＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐが参照しているＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｃｌｏｃｋに、不連続点（ｎｏ  ａｒｒｉｖａｌ  ｔｉｍｅ−ｂａｓｅ  ｄｉｓｃｏｎｔｉｎｕｔｉｙ）が存在しないものをいう。いいかえれば、そのＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｓｔａｍｐが参照しているＡｒｒｉｖａｌ＿Ｔｉｍｅ＿Ｃｌｏｃｋに、連続性が存在するＳｏｕｒｃｅパケット列を“ＡＴＣ＿Ｓｅｕｅｎｃｅ”という。【００２９】  かかるＡＴＣ＿ＳｅｕｅｎｃｅがＡＶＣｌｉｐになり、ｘｘｘｘｘ．ｍ２ｔｓというファイル名でＢＤ−ＲＯＭに記録される。
かかるＡＶＣｌｉｐは、通常のコンピュータファイル同様、複数のファイルエクステントに分割され、ＢＤ−ＲＯＭ上の領域に記録される。第４段目はＡＶＣｌｉｐがどのようにＢＤ−ＲＯＭに記録されるかを模式的に示す。この第４段目においてファイルを構成する各ファイルエクステントは、予め定められたＳｅｘｅｔｅｎｔ以上のデータ長を有する。【００３０】  ＡＶＣｌｉｐを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓｅｘｅｔｅｎｔに検討する。
ここでＢＤ−ＲＯＭにおいて光ピックアップのジャンプに要する時間は、
Ｔｊｕｍｐ＝Ｔａｃｃｅｓｓ＋Ｔｏｖｅｒｈｅａｄ
で与えられる。
Ｔａｃｃｅｓｓは、ジャンプ距離に応じて与えられる時間（ｍ秒）であり、
ジャンプ距離（論理ブロック数）が０〜５０００であるなら１７９ｍ秒、
ジャンプ距離（論理ブロック数）が５００１〜１０，０００であるなら２１０ｍ秒、
ジャンプ距離（論理ブロック数）が１０，００１〜２０，０００であるなら２７０ｍ秒、
ジャンプ距離がハーフストロークであるなら９９０ｍ秒、
ジャンプ距離がフルストロークであるなら１２２０ｍ秒になる。
ＢＤ−ＲＯＭから読み出されたＴＳパケットは、リードバッファと呼ばれるバッファに格納された上、デコーダに出力されるが、リードバッファへの入力が、Ｒｕｄというビットレートで行われ、ＥＣＣブロックにおけるセクタ数をＳｅｃｃとした場合、
Ｔｏｖｅｒｈｅａｄは、
Ｔｏｖｅｒｈｅａｄ≦（２×Ｓｅｃｃ×８）／Ｒｕｄ＝２０ｍ秒
という計算で与えられる。
ＢＤ−ＲＯＭから読み出されたＴＳパケットは、Ｓｏｕｒｃｅパケットの状態でリードバッファに格納された上、ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅというう転送レートで、デコーダに供給される。【００３１】  ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅという転送レートでの、デコーダへのＴＳパケット供給が跡絶えさせないなめには、Ｔｊｕｍｐの間、リードバッファからデコーダへのＴＳパケット出力が継続している必要がある。ここでリードバッファからの出力は、ＴＳパケットではなく、Ｓｏｕｒｃｅパケットの状態でなされるので、ＴＳパケットのＳｏｕｒｃｅパケットとのサイズ比を１９２／１８８とした場合、Ｔｊｕｍｐの間、（１９２／１８８×ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ）という転送レートにより、リードバッファからのＳｏｕｒｃｅパケット出力が継続している必要がある。
従って、リードバッファが、アンダーフローしないためのバッファ蓄積量は、
Ｂｏｃｃｕｐｉｅｄ≧（Ｔｊｕｍｐ／１０００×８）×（（１９２／１８８）×ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ）
となる。
リードバッファへの入力レートはＲｕｄ、リードバッファからの出力レートはＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８）であるので、リードバッファへの蓄積レートは、入力レート−出力レートの計算で与えられ、（Ｒｕｄ−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８））になる。【００３２】  このＢｏｃｃｕｐｉｅｄを、リードバッファに蓄積するのに要する時間Ｔｘは、
Ｔｘ＝Ｂｏｃｃｕｐｉｅｄ／（Ｒｕｄ−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８））
になる。
ＢＤ−ＲＯＭからの読み出しには、この時間ＴｘにおいてＲｕｄでのＴＳパケット入力を継続する必要があるので、ＡＶＣｌｉｐを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓｅｘｅｔｅｎｔは、
Ｓｅｘｅｔｅｎｔ＝Ｒｕｄ×Ｔｘ
＝Ｒｕｄ×Ｂｏｃｃｕｐｉｅｄ／（Ｒｕｄ−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８））
≧Ｒｕｄ×（Ｔｊｕｍｐ／１０００×８）×（（１９２／１８８）×ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ）
／（Ｒｕｄ−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×（１９２／１８８））
≧（Ｒｕｄ×Ｔｊｕｍｐ／１０００×８）×
×ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×１９２／（Ｒｕｄ×１８８−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×１９２）
になる。
よって
Ｓｅｘｅｔｅｎｔ≧
（Ｔｊｕｍｐ×Ｒｕｄ／１０００×８）×
（ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×１９２／（Ｒｕｄ×１８８−ＴＳ＿Ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ×１９２））
になる。
ＡＶＣｌｉｐを構成する各ファイルエクステントは、こうして算出されたＳｅｘｔｅｎｔ以上のデータ長をもつことにより、ＡＶＣｌｉｐを構成する各ファイルエクステントが、ＢＤ−ＲＯＭ上において離散的に位置されたとしても、再生時においてデコーダへのＴＳパケット供給が途絶えさせることなく、連続的に読み出されることになる。【００３３】  図５は、ＢＤ−ＲＯＭの物理単位と、１つのファイルエクステントを構成するＳｏｕｒｃｅパケットとの対応関係を示す図である。第２段目に示すように、ＢＤ−ＲＯＭ上には複数セクタが形成されている。ファイルエクステントを構成するＳｏｕｒｃｅパケットは、第１段目に示すように、３２個毎にグループ化されて、連続する３つのセクタに書き込まれる。３２個のＳｏｕｒｃｅパケットからなるグループは、６１４４バイト（＝３２×１９２）であり、これは３個のセクタサイズ６１４４バイト（＝２０４８×３）と一致する。３個のセクタに収められた３２個のＳｏｕｒｃｅパケットを“Ａｌｉｇｎｅｄ  Ｕｎｉｔ”といい、ＢＤ−ＲＯＭへの書き込みにあたっては、Ａｌｉｇｎｅｄ  Ｕｎｉｔ単位で暗号化がなされる。【００３４】  第３段目においてセクタは、３２個単位で誤り訂正符号が付され、ＥＣＣブロックを構成する。再生装置はＡｌｉｇｎｅｄ  Ｕｎｉｔの単位でＢＤ−ＲＯＭをアクセスする限り、３２個の完結したＳｏｕｒｃｅパケットを得ることができる。以上がＢＤ−ＲＯＭに対するＡＶＣｌｉｐの書き込みのプロセスである。
＜ＢＤ−ＲＯＭの構成その２．Ｃｌｉｐ情報＞
続いて拡張子．ｃｌｐｉが付与されたファイルについて説明する。拡張子．ｃｌｐｉが付与されたファイル（００００１．ｃｌｐｉ，００００２．ｃｌｐｉ，００００３．ｃｌｐｉ・・・・・）は、Ｃｌｉｐ情報を格納している。Ｃｌｉｐ情報は、個々のＡＶＣｌｉｐについての管理情報である。図６は、Ｃｌｉｐ情報の内部構成を示す図である。本図の左側に示すようにＣｌｉｐ情報は、
ｉ）ＡＶＣｌｉｐについての情報を格納した『ＣｌｉｐＩｎｆｏ（）』、
ｉｉ）ＡＴＣ  Ｓｅｑｕｅｎｃｅ，ＳＴＣ  Ｓｅｑｕｅｎｃｅに関する情報を格納した『Ｓｅｑｕｅｎｃｅ  Ｉｎｆｏ（）』
ｉｉｉ）Ｐｒｏｇｒａｍ  Ｓｅｑｕｅｎｃｅに関する情報を格納した『Ｐｒｏｇｒａｍ  Ｉｎｆｏ（）』
ｉｖ）『Ｃｈａｒａｃｔｅｒｉｓｔｉｃ  Ｐｏｉｎｔ  Ｉｎｆｏ（ＣＰＩ（）』からなる。【００３５】  Ｓｅｑｕｅｎｃｅ  Ｉｎｆｏは、ＡＶＣｌｉｐに含まれる、１つ以上のＳＴＣ−Ｓｅｑｕｅｎｃｅ、ＡＴＣ−Ｓｅｑｕｅｎｃｅについての情報である。これらの情報を設けておくことの意義は、ＳＴＣ、ＡＴＣの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、ＡＶＣｌｉｐ内において同じ値のＰＴＳ，ＡＴＳが出現する可能性があり、再生時に不都合が生じる。ＳＴＣ，ＡＴＣが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、Ｓｅｑｕｅｎｃｅ  Ｉｎｆｏは設けられている。【００３６】  Ｐｒｏｇｒａｍ  Ｉｎｆｏとは、Ｐｒｏｇｒａｍ内容が一定である区間（Ｐｒｏｇｒａｍ  Ｓｅｑｕｅｎｃｅ）を示す情報である。Ｐｒｏｇｒａｍとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。Ｐｒｏｇｒａｍ  Ｓｅｑｕｅｎｃｅ情報を設けておくことの意義は、Ｐｒｏｇｒａｍ内容の変化点を、予め再生装置に通知するためである。ここでのＰｒｏｇｒａｍ内容の変化点とは、ビデオストリームのＰＩＤが変化したり、ビデオストリームの種類がＳＤＴＶからＨＤＴＶに変化している点等をいう。
続いてＣｈａｒａｃｔｅｒｉｓｔｉｃ  Ｐｏｉｎｔ  Ｉｎｆｏについて説明する。図中の引き出し線ｃｕ２は、ＣＰＩの構成をクローズアップしている。引き出し線ｃｕ２に示すように、ＣＰＩは、Ｎｅ個のＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ（０）〜ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤ（Ｎｅ−１））からなる。これらＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤは、ＡＶＣｌｉｐに属する個々のエレメンタリストリームについてのＥＰ＿ｍａｐである。ＥＰ＿ｍａｐは、１つのエレメンタリストリーム上において、Ａｃｃｅｓｓ  Ｕｎｉｔの先頭部分である、Ａｃｃｅｓｓ  Ｕｎｉｔ  Ｄｅｌｉｍｉｔｅｒが存在するエントリー位置のパケット番号（ＳＰＮ＿ＥＰ＿ｓｔａｒｔ）を、エントリー時刻（ＰＴＳ＿ＥＰ＿ｓｔａｒｔ）と対応づけて示す情報である。図中の引き出し線ｃｕ３は、ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤの内部構成をクローズアップしている。【００３７】  これによると、ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ＿ＰＩＤは、Ｎｃ個のＥＰ＿Ｈｉｇｈ（ＥＰ＿Ｈｉｇｈ（０）〜ＥＰ＿Ｈｉｇｈ（Ｎｃ−１））と、Ｎｆ個のＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ（０）〜ＥＰ＿Ｌｏｗ（Ｎｆ−１））とからなることがわかる。ここでＥＰ＿Ｈｉｇｈは、Ａｃｃｅｓｓ  ＵｎｉｔのＳＰＮ＿ＥＰ＿ｓｔａｒｔ及びＰＴＳ＿ＥＰ＿ｓｔａｒｔの上位ビットを表す役割をもち、ＥＰ＿Ｌｏｗは、Ａｃｃｅｓｓ  ＵｎｉｔのＳＰＮ＿ＥＰ＿ｓｔａｒｔ及びＰＴＳ＿ＥＰ＿ｓｔａｒｔの下位ビットを示す役割をもつ。
図中の引き出し線ｃｕ４は、ＥＰ＿Ｈｉｇｈの内部構成をクローズアップしている。この引き出し線に示すように、ＥＰ＿Ｈｉｇｈ（ｉ）は、ＥＰ＿Ｌｏｗに対する参照値である『ｒｅｆ＿ｔｏ＿ＥＰ＿Ｌｏｗ＿ｉｄ［ｉ］』と、Ａｃｃｅｓｓ  Ｕｎｉｔの先頭にあたるＮｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャのＰＴＳの上位ビットを示す『ＰＴＳ＿ＥＰ＿Ｈｉｇｈ［ｉ］』と、Ａｃｃｅｓｓ  Ｕｎｉｔの先頭にあたるＮｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャのＳＰＮの上位ビットを示す『ＳＰＮ＿ＥＰ＿Ｈｉｇｈ［ｉ］』とからなる。ここでｉとは、任意のＥＰ＿Ｈｉｇｈを識別するための識別子である。【００３８】  図中の引き出し線ｃｕ５は、ＥＰ＿Ｌｏｗの構成をクローズアップしている。引き出し線ｃｕ５に示すように、ＥＰ＿Ｌｏｗは、対応するＡｃｃｅｓｓ  ＵｎｉｔがＩＤＲピクチャか否かを示す『ｉｓ＿ａｎｇｌｅ＿ｃｈａｎｇｅ＿ｐｏｉｎｔ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓ  Ｕｎｉｔのサイズを示す『Ｉ＿ｅｎｄ＿ｐｏｓｉｔｉｏｎ＿ｏｆｆｓｅｔ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓ  Ｕｎｉｔ（Ｎｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャ）のＰＴＳの下位ビットを示す『ＰＴＳ＿ＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ＿ｉｄ）』と、対応するＡｃｃｅｓｓ  Ｕｎｉｔ（Ｎｏｎ−ＩＤＲ  Ｉピクチャ、ＩＤＲピクチャ）のＳＰＮの下位ビットを示す『ＳＰＮ＿ＥＰ＿Ｌｏｗ（ＥＰ＿Ｌｏｗ＿ｉｄ）』とからなる。ここでＥＰ＿Ｌｏｗ＿ｉｄとは、任意のＥＰ＿Ｌｏｗを識別するための識別子である。【００３９】  ＜Ｃｌｉｐ情報の説明その２．ＥＰ＿ｍａｐ＞
以下、具体例を通じて、ＥＰ＿ｍａｐについて説明する。図７は、映画のビデオストリームに対するＥＰ＿ｍａｐ設定を示す図である。第１段目は、表示順序に配置された複数のピクチャ（ＭＰＥＧ４−ＡＶＣに規定されたＩＤＲピクチャ、Ｉピクチャ、Ｂピクチャ、Ｐピクチャ）を示し、第２段目は、そのピクチャにおける時間軸を示す。第４段目は、ＢＤ−ＲＯＭ上のＴＳパケット列を示し、第３段目は、ＥＰ＿ｍａｐの設定を示す。【００４０】  第２段目の時間軸において、時点ｔ１〜ｔ７に、Ａｃｃｅｓｓ  ＵｎｉｔとなるＩＤＲピクチャ及びＩピクチャが存在するものとする。そしてこれらのｔ１〜ｔ７の時間間隔が、１秒程度であるとすると、映画に用いられるビデオストリームにおけるＥＰ＿ｍａｐは、ｔ１〜ｔ７をエントリー時刻（ＰＴＳ＿ＥＰ＿ｓｔａｒｔ）として示し、これに対応づけてエントリー位置（ＳＰＮ＿ＥＰ＿ｓｔａｒｔ）を示すよう、設定される。
＜ＰｌａｙＬｉｓｔ情報＞
続いて、ＰｌａｙＬｉｓｔ情報について説明する。拡張子“ｍｐｌｓ”が付与されたファイル（００００１．ｍｐｌｓ）は、ＰｌａｙＬｉｓｔ（ＰＬ）情報を格納したファイルである。【００４１】  図８は、ＰｌａｙＬｉｓｔ情報のデータ構造を示す図であり、本図において、引き出し線ｍｐ１に示すようにＰｌａｙＬｉｓｔ情報は、ＭａｉｎＰａｔｈを定義するＭａｉｎＰａｔｈ情報（ＭａｉｎＰａｔｈ（））と、チャプターを定義するＰｌａｙＬｉｓｔＭａｒｋ情報（ＰｌａｙＬｉｓｔＭａｒｋ（））とからなる。
＜ＰｌａｙＬｉｓｔ情報の説明その１．ＭａｉｎＰａｔｈ情報＞
先ずＭａｉｎＰａｔｈについて説明する。ＭａｉｎＰａｔｈは、主映像たるビデオストリームやオーディオストリームに対して定義される再生経路である。【００４２】  ＭａｉｎＰａｔｈは、矢印ｍｐ１で示すように複数のＰｌａｙＩｔｅｍ情報＃１・・・・＃ｍから定義される。ＰｌａｙＩｔｅｍ情報は、ＭａｉｎＰａｔｈを構成する１つ以上の論理的な再生区間を定義する。ＰｌａｙＩｔｅｍ情報の構成は、引き出し線ｈｓ１によりクローズアップされている。この引き出し線に示すようにＰｌａｙＩｔｅｍ情報は、再生区間のＩＮ点及びＯｕｔ点が属するＡＶＣｌｉｐの再生区間情報のファイル名を示す『Ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ』と、ＡＶＣｌｉｐの符号化方式を示す『Ｃｌｉｐ＿ｃｏｄｅｃ＿ｉｄｅｎｔｉｆｉｅｒ』と、ＰｌａｙＩｔｅｍがマルチアングルを構成するか否かを示す『ｉｓ＿ｍｕｌｔｉ＿ａｎｇｌｅ』と、このＰｌａｙＩｔｅｍが対象としているＳＴＣ＿Ｓｅｑｕｅｎｃｅを一意に示す『ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ［０］』と、このＰｌａｙＩｔｅｍと、その１つ前のＰｌａｙＩｔｅｍとの接続を、シームレスに行うか否かを示す『ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ』と、再生区間の始点を示す時間情報『Ｉｎ＿ｔｉｍｅ』と、再生区間の終点を示す時間情報『Ｏｕｔ＿ｔｉｍｅ』と、このＰｌａｙＩｔｅｍにおいてマスクすべきユーザオペレーションがどれであるかを示す『ＵＯ＿ｍａｓｋ＿ｔａｂｌｅ』と、このＰｌａｙｌｔｅｍの途中へのランダムアクセスを寄許可するか否かを示す『ＰｌａｙＩｔｅｍ＿ｒａｎｄｏｍ＿ａｃｃｅｓｓ＿ｆｌａｇ』と、このＰｌａｙＩｔｅｍの再生終了後、最後のピクチャの静止表示を継続するか否かを示す『ｓｔｉｌｌ＿ｍｏｄｅ』と、『ＳＴＮ＿ｔａｂｌｅ』とから構成される。このうち、再生経路を構成するのは、再生区間の始点を示す時間情報『Ｉｎ＿ｔｉｍｅ』、再生区間の終点を示す時間情報『Ｏｕｔ＿ｔｉｍｅ』の組みであり、再生経路情報とは、この『Ｉｎ＿ｔｉｍｅ』及び『Ｏｕｔ＿ｔｉｍｅ』の組みから構成される。【００４３】  図９は、ＡＶＣｌｉｐと、ＰｌａｙＬｉｓｔ情報との関係を示す図である。第１段目は、ＰｌａｙＬｉｓｔ情報がもつ時間軸を示す。第２段目から第５段目は、ＥＰ＿ｍａｐにて参照されているビデオストリーム（図７に示したものと同じ）を示す。
ＰｌａｙＬｉｓｔ情報は、ＰｌａｙＩｔｅｍ情報＃１，＃２という２つのＰｌａｙＩｔｅｍ情報を含んでおり、これらＰｌａｙＩｔｅｍ情報＃１，＃２のＩｎ＿ｔｉｍｅ，Ｏｕｔ＿ｔｉｍｅにより、２つの再生区間が定義されることになる。これらの再生区間を配列させると、ＡＶＣｌｉｐ時間軸とは異なる時間軸が定義されることになる。これが第１段目に示すＰｌａｙＩｔｅｍ時間軸である。このように、ＰｌａｙＩｔｅｍ情報の定義により、ＡＶＣｌｉｐとは異なる時間軸の定義が可能になる。【００４４】  ＜ＳＴＮ＿ｔａｂｌｅ＞
ＳＴＮ＿ｔａｂｌｅは、Ｐｌａｙ  ＩｔｅｍのＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されているＡＶＣｌｉｐに多重化された複数エレメンタリストリームのうち、再生可能なものを示すテーブルである。具体的にいうとＳＴＮ＿ｔａｂｌｅは、複数エレメンタリストリームのそれぞれについてのｅｎｔｒｙを、ａｔｔｒｉｂｕｔｅと対応付けることで構成される。【００４５】  図１０（ａ）は、ＳＴＮ＿ｔａｂｌｅの内部構成を示す図である。本図に示すようにＳＴＮ＿ｔａｂｌｅは、ＳＴＮ＿ｔａｂｌｅにおけるｅｎｔｒｙと、ａｔｔｒｉｂｕｔｅとの組み（ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅ）を複数含み、これらｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みの個数（ｎｕｍｂｅｒ＿ｏｆ＿ｖｉｄｅｏ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ａｕｄｉｏ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ＰＧ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ，ｎｕｍｂｅｒ＿ｏｆ＿ＩＧ＿ｓｔｒｅａｍ＿ｅｎｔｒｉｅｓ）を示すデータ構造になっている。【００４６】  ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みは、図中の括弧記号”｛”に示すように、Ｐｌａｙ  Ｉｔｅｍにおいて再生可能なビデオストリーム、オーディオストリーム、ＰＧ＿ｓｔｒｅａｍ、ＩＧストリームのそれぞれに対応している。
ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの詳細について説明する。図１０（ｂ）〜（ｅ）は、ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの詳細を示す図である。【００４７】  図１０（ｂ）は、ビデオストリームに対応したｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みを示す図である。
ビデオストリームにおけるｅｎｔｒｙは、ＡＶＣｌｉｐを多重分離するにあたって、当該ビデオストリームの抽出に用いられるＰＩＤを示す『ｒｅｆ＿ｔｏ＿ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿ｍａｉｎＣｌｉｐ』を含む。
ビデオストリームにおけるａｔｔｒｉｂｕｔｅは、０ｘ０２に設定された『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、ビデオストリームの表示レートを示す『ｆｒａｍｅ＿ｒａｔｅ』等を含む。【００４８】  図１０（ｃ）は、オーディオストリームに対応したｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みを示す図である。
オーディオストリームにおけるｅｎｔｒｙは、ＡＶＣｌｉｐを多重分離するにあたって、当該オーディオストリームの抽出に用いられるＰＩＤを示す『ｒｅｆ＿ｔｏ＿ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿ｍａｉｎＣｌｉｐ』を含む。【００４９】  オーディオストリームにおけるａｔｔｒｉｂｕｔｅは、０ｘ８０（ＬｉｎｅａｒＰＣＭ），０ｘ８１（ＡＣ−３），０ｘ８２（ＤＴＳ）の何れかに設定されることによりオーディオストリームのコーデイングタイプを示す『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、対応するオーディオストリームのチャネル構成を示し、マルチチャネル出力の可否を示す『ａｕｄｉｏ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｙｐｅ』と、対応するオーディオストリームの言語属性を示す『ａｕｄｉｏ＿ｌａｎｇｕａｇｅ  ｃｏｄｅ』等からなる。【００５０】  マルチチャネルには、５．１ＣＨのサラウンド音声の他、ステレオ音声も含まれるが、以降の説明では、マルチチャネルは、５．１ＣＨのサラウンド音声のみを意味するとして説明を進める。
図１０（ｄ）は、ＰＧストリームに対応したｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みを示す図である。
ＰＧストリームにおけるｅｎｔｒｙは、ＡＶＣｌｉｐを多重分離するにあたって、当該ＰＧストリームの抽出に用いられるＰＩＤを示す『ｒｅｆ＿ｔｏ＿ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿ｍａｉｎＣｌｉｐ』を含む。【００５１】  ＰＧストリームにおけるａｔｔｒｉｂｕｔｅは、０ｘ９０に設定されることによりＰＧストリームのコーディックを示す『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、対応するＰＧストリームの言語属性を示す『ＰＧ＿ｌａｎｇｕａｇｅ  ｃｏｄｅ』とからなる。
図１０（ｅ）は、ＩＧストリームに対応したｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅの組みを示す図である。
ＩＧストリームにおけるｅｎｔｒｙは、ＡＶＣｌｉｐを多重分離するにあたって、当該ＩＧストリームの抽出に用いられるＰＩＤを示す『ｒｅｆ＿ｔｏ＿ｓｔｒｅａｍ＿ＰＩＤ＿ｏｆ＿ｍａｉｎＣｌｉｐ』を含む。【００５２】  ＩＧストリームにおけるａｔｔｒｉｂｕｔｅは、０ｘ９１に設定されることによりＩＧストリームのコーディックを示す『ｓｔｒｅａｍ＿ｃｏｄｉｎｇ＿ｔｙｐｅ』と、対応するＩＧストリームの言語属性を示す『ｌａｎｇｕａｇｅ  ｃｏｄｅ』とからなる。
＜ＰｌａｙＬｉｓｔ情報の説明その２．ＰｌａｙＬｉｓｔＭａｒｋ＞
以上が、本実施形態に係るＰｌａｙＩｔｅｍ情報についての説明である。続いてＰｌａｙＬｉｓｔＭａｒｋ情報について説明する。【００５３】  図１１は、ＰｌａｙＬｉｓｔ情報の、ＰｌａｙＬｉｓｔＭａｒｋ情報の内部構成を示す図である。本図の図中の引き出し線ｐｍ０に示すように、ＰｌａｙＬｉｓｔＭａｒｋ情報は、複数のＰＬＭａｒｋ情報（＃１〜＃ｎ）からなる。ＰＬｍａｒｋ情報（ＰＬｍａｒｋ（））は、ＰＬ時間軸のうち、任意の区間を、チャプター点として指定する情報である。引き出し線ｐｍ１に示すようにＰＬｍａｒｋ情報は、チャプター指定の対象たるＰｌａｙＩｔｅｍを示す『ｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄ』と、そのＰｌａｙＩｔｅｍにおける、チャプター位置を時間表記により示す『ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ』とを含む。【００５４】  図１２は、ＰｌａｙＬｉｓｔ情報の、ＰＬＭａｒｋ情報によるチャプター位置の指定を示す図である。本図の第２段目から第５段目は、図１０に示した、ＥＰ＿ｍａｐと、ＡＶＣｌｉｐとを示す。
本図の第１段目は、ＰＬＭａｒｋ情報と、ＰＬ時間軸とを示す。この第１段目には、２つのＰＬＭａｒｋ情報＃１〜＃２が存在する。矢印ｋｔ１，２は、ＰＬＭａｒｋ情報のｒｅｆ＿ｔｏ＿Ｐｌａｙｌｔｅｍ＿Ｉｄによる指定を示す。この矢印からもわかるように、ＰＬＭａｒｋ情報のｒｅｆ＿ｔｏ＿ＰｌａｙＩｔｅｍ＿Ｉｄは、ＰｌａｙＩｔｅｍ情報のそれぞれを指定していることがわかる。また、Ｍａｒｋ＿ｔｉｍｅ＿Ｓｔａｍｐは、ＰｌａｙＩｔｅｍ時間軸のうち、Ｃｈａｐｔｅｒ＃１，＃２になるべき時点を示す。このように、ＰＬＭａｒｋ情報は、ＰｌａｙＩｔｅｍ時間軸上に、チャプター点を定義することができる。【００５５】  ＡＶＣｌｉｐ−ＳｕｂＣｌｉｐを同期させ得る同期区間の定義を可能とするのが、ＢＤ−ＲＯＭにおけるプレイリスト情報の特徴である。以上のＣｌｉｐ情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のＣｌｉｐ情報及びプレイリスト情報により、静的な再生単位であるプレイリストが定義されるからである。以上で静的シナリオについての説明を終わる。【００５６】  続いて”動的なシナリオ”について説明する。動的シナリオとは、ＡＶＣｌｉｐの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。ＢＤ−ＲＯＭでは、この再生制御の動作環境として２つのモードを想定している。１つ目は、ＤＶＤ再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。２つ目は、Ｊａｖａ（登録商標）仮想マシンの動作環境である。これら２つの動作環境のうち１つ目は、ＨＤＭＶモードと呼ばれる。２つ目は、ＢＤ−Ｊモードと呼ばれる。これら２つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。ＨＤＭＶモードを想定した動的シナリオはＭｏｖｉｅ  Ｏｂｊｅｃｔと呼ばれる。一方ＢＤ−Ｊモードを想定した動的シナリオはＢＤ−Ｊ  Ｏｂｊｅｃｔと呼ばれる。【００５７】  先ず初めにＭｏｖｉｅ  Ｏｂｊｅｃｔについて説明する。
＜Ｍｏｖｉｅ  Ｏｂｊｅｃｔ＞
Ｍｏｖｉｅ  Ｏｂｊｅｃｔは、図２に示したＭｏｖｉｅＯｂｊｅｃｔ．ｂｄｍｖというファイルに格納され、ナビゲーションコマンド列を含む。
ナビゲーションコマンド列は、条件分岐、再生装置における状態レジスタの設定、状態レジスタの設定値取得等を実現するコマンド列からなる。Ｍｏｖｉｅ  Ｏｂｊｅｃｔにおいて記述可能なコマンドを以下に示す。
ＰｌａｙＰＬコマンド
書式：ＰｌａｙＰＬ（第１引数，第２引数）
第１引数は、プレイリストの番号で、再生すべきプレイリストを指定することができる。第２引数は、そのプレイリストに含まれるＰｌａｙＩｔｅｍや、そのプレイリストにおける任意の時刻、Ｃｈａｐｔｅｒ、Ｍａｒｋを用いて再生開始位置を指定することができる。【００５８】  ＰｌａｙＩｔｅｍによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＰｌａｙＩｔｅｍ（）、
ＣｈａｐｔｅｒによりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＣｈａｐｔｅｒ（）、
時刻情報によりＰＬ時間軸上の再生開始位置を指定したＰｌａｙＰＬ関数をＰｌａｙＰＬａｔＳｐｅｃｉｆｉｅｄ  Ｔｉｍｅ（）という。
ＪＭＰコマンド
書式：ＪＭＰ引数
ＪＭＰコマンドは、現在の動的シナリオを途中で廃棄し（ｄｉｓｃａｒｄ）、引数たる分岐先動的シナリオを実行するという分岐である。ＪＭＰ命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。
Ｍｏｖｉｅ  Ｏｂｊｅｃｔにおけるナビゲーションコマンドの記述は、ＤＶＤにおけるナビゲーションコマンドの記述方式と良く似ているので、ＤＶＤ上のディスクコンテンツを、ＢＤ−ＲＯＭに移植するという作業を効率的に行うことができる。Ｍｏｖｉｅ  Ｏｂｊｅｃｔについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。
国際公開公報ＷＯ  ２００４／０７４９７６
以上でＭｏｖｉｅ  Ｏｂｊｅｃｔについての説明を終える。続いてＢＤ−Ｊ  Ｏｂｊｅｃｔについて説明する。
＜ＢＤ−Ｊ  Ｏｂｊｅｃｔ＞
ＢＤ−Ｊ  Ｏｂｊｅｃｔは、Ｊａｖａ（登録商標）プログラミング環境で記述された、ＢＤ−Ｊモードの動的シナリオであり、００００１〜００００３．ｂｏｂｊというファイルに格納される。【００５９】  図１３は、ＢＤ−Ｊ  Ｏｂｊｅｃｔ．ｂｄｍｖの内部構成を示す図である。アプリケーション管理テーブル（ＡＭＴ）、プレイリスト管理テーブル（ＰＬＭＴ）、サウンド管理テーブル（ＳＭＴ）からなる。Ｍｏｖｉｅ  Ｏｂｊｅｃｔとの違いは、ＢＤ−Ｊ  Ｏｂｊｅｃｔにコマンドが直接記述されていない点である。つまりＭｏｖｉｅ  Ｏｂｊｅｃｔにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しＢＤ−Ｊ  Ｏｂｊｅｃｔでは、Ｊａｖａ（登録商標）アプリケーションに対する指定をアプリケーション管理テーブルに記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。【００６０】  またＭｏｖｉｅＯｂｊｅｃｔにおけるプレイリスト再生は、プレイリスト再生を命じるナビゲーションコマンド（ＰｌａｙＰｌコマンド）の記述によりなされるが、ＢＤ−Ｊ  Ｏｂｊｅｃｔにおけるプレイリスト再生は、プレイリスト再生手順を示すプレイリスト管理テーブルをＢＤ−Ｊ  Ｏｂｊｅｃｔに組み込むことで記述が可能になる。
このＢＤ−ＪモードにおけるＪａｖａ（登録商標）アプリケーションについて説明する。ここでＢＤ−Ｊモードが想定しているＪａｖａ（登録商標）プラットフォームは、Ｊａｖａ（登録商標）２Ｍｉｃｒｏ＿Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ）Ｐｅｒｓｏｎａｌ  Ｂａｓｉｓ  Ｐｒｏｆｉｌｅ（ＰＢＰ  １．０）と、Ｇｌｏｂａｌｌｙ  Ｅｘｅｃｕｔａｂｌｅ  ＭＨＰ  ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＧＥＭ１．０．２）ｆｏｒ  ｐａｃｋａｇｅ  ｍｅｄｉａ  ｔａｒｇｅｔｓとをフル実装したものである。【００６１】  このＢＤ−ＪモードにおけるＪａｖａ（登録商標）アプリケーションは、ｘｌｅｔインターフェイスを通じて、Ａｐｐｌｉｃａｔｉｏｎ  Ｍａｎａｇｅｒにより、制御される。ｘｌｅｔインターフェイスは、“ｌｏａｄｅｄ”，“ｐａｕｓｅｄ”、“ａｃｔｉｖｅ”，“ｄｅｓｔｏｒｙｅｄ”といった４つの状態をもつ。
上述したＪａｖａ（登録商標）プラットフォームは、ＪＦＩＦ（ＪＰＥＧ）やＰＮＧ，その他のイメージデータを表示するためのスタンダードＪａｖａ（登録商標）ライブラリを含む。このため、Ｊａｖａ（登録商標）アプリケーションは、ＨＤＭＶモードにおいてＩＧストリームにより実現されるＧＵＩとは異なるＧＵＩフレームワークを実現することができる。Ｊａｖａ（登録商標）アプリケーションにおけるＧＵＩフレームワークは、ＧＥＭ１．０．２にて規定されたＨＡＶｉフレームワークを含み、ＧＥＭ１．０．２におけるリモートコントロールナビゲーション機構を含む。【００６２】  これにより、Ｊａｖａ（登録商標）アプリケーションは、ＨＡＶｉフレームワークに基づくボタン表示、テキスト表示、オンライン表示（ＢＢＳの内容）といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。
このＪａｖａ（登録商標）アプリケーションの実体にあたるのが、図２におけるＢＤＭＶディレクトリ配下のＢＤＪＡディレクトリに格納されたＪａｖａ（登録商標）アーカイブファイル（００００１．ｊａｒ，００００２．ｊａｒ）である。以降、Ｊａｖａ（登録商標）アーカイブファイルについて説明する。【００６３】  ＜Ｊａｖａ（登録商標）アーカイブファイル＞
Ｊａｖａ（登録商標）アーカイブファイル（図２の００００１．ｊａｒ，００００２．ｊａｒ）は、１つ以上のクラスファイル、１つ以上のデータファイル等を１つにまとめることで得られるファイルであり、ＢＤ−Ｊモードにおいて動作すべきＪａｖａ（登録商標）アプリケーションを構成する。
図１４は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるプログラム、データは、枠内に示すディレクトリ構造が配置された複数ファイルを、ｊａｖａ（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Ｒｏｏｔディレクトリ、Ｊａｖａ（登録商標）１，２，３ディレクトリ、Ｉｍａｇｅ１，２，３ディレクトリとからなり、Ｒｏｏｔディレクトリにｃｏｍｍｏｎ．ｐｋｇが、Ｊａｖａ（登録商標）１，Ｊａｖａ（登録商標）２，Ｊａｖａ（登録商標）３ディレクトリにクラスファイル（００００１．ｃｌａｓｓ〜００００７．ｃｌａｓｓ）が、Ｉｍａｇｅ１，Ｉｍａｇｅ２，Ｉｍａｇｅ３ディレクトリに、００００１．ＪＰＥＧ〜００００３．ＪＰＥＧ，００００４．ＰＮＧ〜００００６．ＰＮＧが配置されている。ｊａｖａ（登録商標）アーカイブファイルは、これらをｊａｖａ（登録商標）アーカイバでまとめることで得られる。かかるクラスファイル及びデータは、ＢＤ−ＲＯＭからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Ｊａｖａ（登録商標）アーカイブファイルのファイル名における″ｚｚｚｚｚ″という５桁の数値は、アプリケーションのＩＤ（ａｐｐｌｉｃａｔｉｏｎＩＤ）を示す。本Ｊａｖａ（登録商標）アーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のＪａｖａ（登録商標）アプリケーションを構成するプログラム，データを取り出すことができる。【００６４】  尚、本実施形態においてアプリケーションを構成するプログラム、データは、Ｊａｖａ（登録商標）アーカイブファイルにまとめられたが、ＬＺＨファイル、ｚｉｐファイルであってもよい。
以上が、ＢＤ−Ｊモードにおける動的シナリオについての説明である。
＜ｓｏｕｎｄ．ｂｄｍｖ＞
続いてｓｏｕｎｄ．ｂｄｍｖについて説明する。ｓｏｕｎｄ．ｂｄｍｖは、Ｊａｖａ（登録商標）アプリケーションのＧＵＩフレームワークに対して操作がなされた場合、クリック音として出力すべきオーディオデータ（かかるオーディオデータを、サウンドデータという）が格納されるファイルである。【００６５】  図１５は、ファイルｓｏｕｎｄ．ｂｄｍｖの構成を示す図である。ファイルｓｏｕｎｄ．ｂｄｍｖは、Ｓｏｕｎｄ  Ｄａｔａ（）と、Ｓｏｕｎｄ  Ｉｎｄｅｘ（）とからなる。Ｓｏｕｎｄ  Ｄａｔａ（）は、複数のサウンドデータ（ｓｏｕｎｄ＿ｄａｔａ（０），ｓｏｕｎｄ＿ｄａｔａ（１））からなる。これらのサウンドデータのうち、ｓｏｕｎｄ＿ｄａｔａ（０）は、Ｊａｖａ（登録商標）アプリケーションのＧＵＩフレームワークに対する操作時に、第１のクリック音として出力される音源である。ｓｏｕｎｄ＿ｄａｔａ（１）は、Ｊａｖａ（登録商標）アプリケーションのＧＵＩフレームワークに対する操作時に、第２のクリック音として出力される音源である。これらのサウンドデータは、ｓｏｕｎｄ＿ＩＤと呼ばれる識別子にて指示される。【００６６】  Ｓｏｕｎｄ  Ｉｎｄｅｘ（）は、サウンド数（ｎｕｍｂｅｒ＿ｏｆ＿ｓｏｕｎｄ＿ｅｎｔｒｉｅｓ）、ｓｏｕｎｄ＿ｄａｔａ（０）に対するインデックス、ｓｏｕｎｄ＿ｄａｔａ（１）に対するインデックスからなる。
インデックスは、モノラル／ステレオの別などの各サウンドの属性（ｓｏｕｎｄ＿ａｔｔｒｉｂｕｔｅｓ）、対応するサウンドデータのアドレス（ｓｏｕｎｄ＿ｄａｔａ＿ｓｔａｒｔ＿ａｄｄｒｅｓｓ）、対応するサウンドデータの連続長（ｓｏｕｎｄ＿ｄａｔａ＿ｌｅｎｇｔｈ）からなる。【００６７】  図２〜図６に示したように、映画の劇中に使用される音声（台詞、ＢＧＭ、効果音）の音源は、オーディオストリームとして、ＡＶＣｌｉｐ内に多重化される。これは、映画劇中の音声を表すオーディオストリームを、ビデオストリームの読み出しと同時に再生装置に供給するためである。これに対し、ファイルｓｏｕｎｄ．ｂｄｍｖは、ＡＶＣｌｉｐとは別個のファイルとしてＢＤ−ＲＯＭに記録される。ファイルｓｏｕｎｄ．ｂｄｍｖは、ＡＶＣｌｉｐとは別個のファイルとして記録されるので、ＡＶＣｌｉｐの読み出し中に、サウンドデータを出力させようとすると、ファイルｓｏｕｎｄ．ｂｄｍｖを読み出すための光ピックアップのジャンプが生じ、ＡＶＣｌｉｐの読み出しが中断せざるを得なくなる。かかる中断が生じれば、ＡＶＣｌｉｐ再生に途切れが出る。【００６８】  かかるＡＶＣｌｉｐの再生途切れを避けるには、ＡＶＣｌｉｐの再生がなされていない時点において、ファイルｓｏｕｎｄ．ｂｄｍｖを予めバッファにプリロードしておく必要がある。つまりＡＶＣｌｉｐの再生に先立ち、ファイルｓｏｕｎｄ．ｂｄｍｖ内のサウンドデータを、プリロードしておく必要がある。以上がファイルｓｏｕｎｄ．ｂｄｍｖについての説明である。
＜Ｉｎｄｅｘ．ｂｄｍｖ＞
Ｉｎｄｅｘ．ｂｄｍｖは、タイトルを構成する、Ｍｏｖｉｅ  Ｏｂｊｅｃｔ又はＢＤ−Ｊ  Ｏｂｊｅｃｔを示すテーブルである。【００６９】  Ｔｉｔｌｅにおいて、あるＴｉｔｌｅの構成要素となるＭｏｖｉｅＯｂｊｅｃｔはどれであるか、又は、あるＴｉｔｌｅの構成要素となるＢＤ−Ｊ  Ｏｂｊｅｃｔはどれであるのかを定義する。
Ｉｎｄｅｘ．ｂｄｍｖについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。
国際公開公報ＷＯ  ２００４／０２５６５１  Ａ１公報
以降、図１５に示したアプリケーション管理テーブル、プレイリスト管理テーブル、サウンド管理テーブルのそれぞれについてより詳しく説明する。【００７０】  ＜アプリケーション管理テーブル＞
アプリケーション管理テーブル（ＡＭＴ）について説明する。アプリケーション管理テーブル（ＡＭＴ）とは、上述したＧＥＭ１．０．２ｆｏｒ  ｐａｃｋａｇｅ  ｍｅｄｉａ  ｔａｒｇｅｔｓにおける“アプリケーション  シグナリングを実装するテーブルである。“アプリケーション  シグナリング”とは、ＧＥＭ１．０．２が規定するＭＨＰ（Ｍｕｌｔｉｍｅｄｉａ  Ｈｏｍｅ  Ｐｌａｔｆｏｒｍ）において、“サービス”を生存区間としてアプリケーションの起動、実行を行う制御をいう。本実施形態におけるアプリケーション管理テーブルは、この“サービス”の代わりに、ＢＤ−ＲＯＭにおける“タイトル”を生存区間にして、アプリケーションの起動、実行の制御を実現する。【００７１】  図１６（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。本図に示すようにアプリケーション管理テーブルは、『ｌｉｆｅ＿ｃｙｃｌｅ』と、『ａｐｌｉ＿ｉｄ＿ｒｅｆ』と、『ｒｕｎ＿ａｔｔｒｉｂｕｔｅ』と、『ｒｕｎ＿ｐｒｉｏｒｉｔｙ』からなる。
図１６（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す。【００７２】  『ｌｉｆｅ＿ｃｙｃｌｅ』は、アプリケーションの”生存区間”を示す。
『ａｐｌｉ＿ｉｄ＿ｒｅｆ』は、”アプリケーション識別子”に対する参照値が記述されることにより、左記の生存区間をもつアプリケーションがどれであるかを示す。アプリケーション識別子は、Ｊａｖａ（登録商標）アーカイブファイルにおいて、ファイル名として付与された５桁の数値ｚｚｚｚｚで表現される。『ａｐｌｉ＿ｉｄ＿ｒｅｆ』には、この５桁の数値が記述される。【００７３】  『ｒｕｎ＿ａｔｔｒｉｂｕｔｅ』は、当該生存区間におけるアプリケーションの”起動属性”が記述される。起動属性には、ＡｕｔｏＲｕｎ、Ｐｒｅｓｅｎｔ、Ｓｕｓｐｅｎｄといった種別がある。
『ｒｕｎ＿ｐｒｉｏｒｉｔｙ』は、当該生存区間におけるアプリケーションの”起動優先度”が記述される。ＢＤ−Ｊ  Ｏｂｊｅｃｔでは、これらの情報を用いてアプリケーションの挙動を制御する。
＜生存区間＞
アプリケーション管理テーブルに規定される情報のうち、生存区間について説明する。【００７４】  生存区間とは、ＢＤ−ＲＯＭに記録されたコンテンツ全体の時間軸において、仮想マシンのワークメモリ上でアプリケーションが生存し得る区間を示す。ワークメモリにおける”生存”とは、そのアプリケーションを構成するｘｌｅｔプログラムが、Ｊａｖａ（登録商標）仮想マシン内のワークメモリに読み出され、Ｊａｖａ（登録商標）仮想マシンによる実行が可能になっている状態をいう。【００７５】  Ｊａｖａ（登録商標）仮想マシンにおいてアプリケーションを動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。このサービスの開始点・終了点を規定するのが、アプリケーション管理テーブルにおける生存区間である。【００７６】  一方、ＤＶＤ−Ｖｉｄｅｏのような読出専用ディスクで供給されるディスクコンテンツは、トップメニュータイトルを中核とした構造になっている。そのトップメニュータイトルから、個々の著作物へと分岐して再生を行い、その後再び、トップメニュータイトルに戻るという独特の状態遷移をなす。図１７は、ディスクコンテンツにおける状態遷移を示す図である。本図における四角枠は、Ｔｉｔｌｅである。Ｔｉｔｌｅとは、ディスクコンテンツ特有の状態遷移において、１つの”状態”にあたる再生単位であり、このタイトルが、Ｊａｖａ（登録商標）アプリケーションの生存区間として取り扱われる。【００７７】  Ｔｉｔｌｅには、ＢＤ−ＲＯＭのローディング時に最初に再生される『ＦｉｒｓｔＰｌａｙＴｉｔｌｅ』、Ｔｏｐ−Ｍｅｎｕを構成する『Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅ』、これら以外の一般的な『Ｔｉｔｌｅ』がある。また、図中の矢印ｊｈ１，２，３，４，５，６，７，８は、Ｔｉｔｌｅ間の分岐を象徴的に示す。本図に示される状態遷移とは、ＢＤ−ＲＯＭローディング時に、『ＦｉｒｓｔＰｌａｙＴｉｔｌｅ』が再生され、『Ｔｏｐ＿ｍｅｎｕＴｉｔｌｅ』への分岐が発生して、トップメニューに対する選択待ちになるというものである。【００７８】  トップメニューに対する選択操作がユーザによりなされれば、選択に従って該当Ｔｉｔｌｅの再生を行い、再びＴｏｐＭｅｎｕ  Ｔｉｔｌｅに戻るとの処理を、ＢＤ−ＲＯＭのイジェクトがなされるまで延々と繰り返すというのが、ディスクコンテンツ特有の状態遷移である。
それでは、図１７のような状態遷移をなすディスクコンテンツにおいて、Ｔｉｔｌｅは、どのように生存区間として規定されるのであろうか。ＢＤ−ＲＯＭのローディングがなされた後、図１７において矢印ｊｈ１，２，３，４・・・・・に示された参照符号の数値順に分岐がなされ、ＢＤ−ＲＯＭがイジェクトされたものとする。そうすると、ＢＤ−ＲＯＭがローディングされてから、イジェクトされるまでの連続時間帯を一本の時間軸と同視することができる。この時間軸を、ディスク全体の時間軸とする。図１８（ａ）は、ディスク全体の時間軸を示す図であり、図１８（ｂ）は、この時間軸における構成を示す。図１８（ｂ）に示すように、ディスク全体の時間軸は、ＦｉｒｓｔＰｌａｙ  Ｔｉｔｌｅが再生されている区間、ＴｏｐＭｅｎｕ  Ｔｉｔｌｅが再生されている区間、ｔｉｔｌｅ＃１が再生されている区間等からなる。これらＴｉｔｌｅの再生区間はどのように規定されているかというと、Ｔｉｔｌｅは、唯一のＢＤ−Ｊ  Ｏｂｊｅｃｔから構成されるから、どれかのＭｏｖｉｅＯｂｊｅｃｔ又はＢＤ−Ｊ  Ｏｂｊｅｃｔが、有効になっている期間をＴｉｔｌｅの再生区間と考えることができる。【００７９】  つまりＦｉｒｓｔＰｌａｙ  Ｔｉｔｌｅ、ＴｏｐＭｅｎｕ  Ｔｉｔｌｅ、その他のＴｉｔｌｅは、何れも動的シナリオから構成されるから、Ｔｉｔｌｅを構成するＢＤ−Ｊ  Ｏｂｊｅｃｔのうち、どれかカレントＢＤ−Ｊ  ＯｂｊｅｃｔとしてＡｃｔｉｖａｔｅｄされ、再生装置内において解読・実行に供されている期間を、Ｔｉｔｌｅの再生区間と定義することができる。図１９（ａ）は、ＢＤ−ＲＯＭ全体の時間軸において、識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ  Ｏｂｊｅｃｔから特定されるタイトル再生区間を示す図である。ここで識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ  Ｏｂｊｅｃｔが、１つのＴｉｔｌｅを構成しているなら、その識別子ｂｏｂｊ＿ｉｄにより特定されるＢＤ−Ｊ  Ｏｂｊｅｃｔが有効になっているＢＤ−ＲＯＭ時間軸上の一区間を、Ｔｉｔｌｅの再生区間と考えることができる。
。【００８０】  ここでＢＤ−Ｊ  ＯｂｊｅｃｔがＡｃｔｉｖａｔｅされている期間の終期は、Ｔｉｔｌｅ分岐がなされるまでである。つまり、Ｔｉｔｌｅ分岐がなされるまで、実行の対象になっている動的シナリオは、カレントＢＤ−Ｊ  Ｏｂｊｅｃｔとして扱われるから、そのＢＤ−Ｊ  ＯｂｊｅｃｔにおいてＪｕｍｐＴｉｔｌｅが発生するまでの１つの区間を、Ｔｉｔｌｅ区間として扱う。
続いてＴｉｔｌｅ区間と、ＰＬ時間軸との関係について説明する。上述したようにＭｏｖｉｅＯｂｊｅｃｔ、ＢＤ−Ｊ  Ｏｂｊｅｃｔでは、１つの処理手順としてプレイリスト再生手順を記述することができる。プレイリスト再生手順の記述があれば、上述したＰＬ時間軸の全部又は一部がＴｉｔｌｅ区間に帰属することになる。図１９（ａ）の一例においてＢＤ−Ｊ  Ｏｂｊｅｃｔに、プレイリスト管理テーブルが記述されているとする。この場合、ＢＤ−Ｊ  Ｏｂｊｅｃｔに対応するＴｉｔｌｅ区間には、図１９（ｂ）に示すように、ＰＬ時間軸が帰属する。このＰＬ時間軸には更に、複数チャプター（Ｃｈａｐｔｅｒ＃１，＃２，＃３）が定義され得るため、ＢＤ−ＲＯＭ上の時間軸には、ＢＤ−ＲＯＭ全体−Ｔｉｔｌｅ−プレイリスト−チャプターというドメインが存在することになる。これらのドメインを用いて、アプリケーションの生存区間を記述することができる。尚、プレイリスト再生は、アプリケーション実行と同時になされため、プレイリスト再生の途中で、Ｔｉｔｌｅ分岐が発生することがある。この場合、１つのＴｉｔｌｅ再生区間内にはプレイリスト時間軸全体ではなく、プレイリスト時間軸の一部分のみが帰属することになる。つまり１つのＴｉｔｌｅの再生区間において、プレイリスト時間軸の全体が帰属するか、その一部分が帰属するかは、Ｔｉｔｌｅ分岐が何時発生するかによって変わる。【００８１】  図２０は、図１９（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本図に示すようにアプリケーションには、Ｔｉｔｌｅを生存区間にした”タイトルバウンダリアプリケーション”、Ｔｉｔｌｅ内におけるチャプターを生存区間にした”チャプターバウンダリアプリケーション”、ＢＤ−ＲＯＭ全体の時間軸を生存区間にした”タイトルアンバウンダリーアプリケーション”という３つの典型がある。【００８２】  このうちタイトルバウンダリアプリケーションの生存区間は、そのタイトルの識別子を用いて定義することができる。またチャプターバウンダリアプリケーションの生存区間は、チャプターが属するタイトルの識別子と、そのチャプターの識別子との組みを用いて定義することができる。
プラットフォームが動作していたとしても、Ｔｉｔｌｅやチャプターという生存区間が終われば、リソースをアプリケーションから回収することができる。リソース回収の機会を保証するので、プラットフォームの動作を安定化させることができる。【００８３】  近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。ここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル（ｔｉｔｌｅ＃１）、オンラインショッピングを構成するオンラインショッピングタイトル（ｔｉｔｌｅ＃２）、ゲームアプリケーションを構成するゲームタイトル（ｔｉｔｌｅ＃３）という、性格が異なる３つのタイトルを含むものである。図２１は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという３つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはＩｎｄｅｘ．ｂｄｍｖを記述しており、左側には３つのタイトルを記述している。【００８４】  右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。３つのタイトルのうちｔｉｔｌｅ＃１は、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３という３つのアプリケーションからなる。ｔｉｔｌｅ＃２は、ａｐｐｌｉｃａｔｉｏｎ＃３、ａｐｐｌｉｃａｔｉｏｎ＃４という２つのアプリケーション、ｔｉｔｌｅ＃３は、ａｐｐｌｉｃａｔｉｏｎ＃５を含む。図２１の一例においてａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２の双方で起動される。【００８５】  図２１の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化すると、図２２（ａ）のようになる。本図において横軸は、タイトル再生区間であり、縦軸方向に各アプリケーションの生存区間を配置している。ここでａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２は、ｔｉｔｌｅ＃１のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃４は、ｔｉｔｌｅ＃２のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃２内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃５は、ｔｉｔｌｅ＃３のみに帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃３内に留まっている。ａｐｐｌｉｃａｔｉｏｎ＃３は、ｔｉｔｌｅ＃１及びｔｉｔｌｅ＃２に帰属しているので、これらの生存区間は、ｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２にわたる。この生存区間に基づき、アプリケーション管理テーブルを記述すると、ｔｉｔｌｅ＃１，＃２，＃３のアプリケーション管理テーブルは図２２（ｂ）のようになる。このようにアプリケーション管理テーブルが記述されれば、ｔｉｔｌｅ＃１の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３をワークメモリにロードしておく。そしてｔｉｔｌｅ＃２の開始時にａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２をワークメモリから削除してａｐｐｌｉｃａｔｉｏｎ＃３のみにするという制御を行う。これと同様にｔｉｔｌｅ＃２の再生開始時においてａｐｐｌｉｃａｔｉｏｎ＃４をワークメモリにロードしておき、ｔｉｔｌｅ＃３の開始時にａｐｐｌｉｃａｔｉｏｎ＃３，＃４をワークメモリから削除するという制御を行いうる。【００８６】  更に、ｔｉｔｌｅ＃３の再生中においてａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリにロードしておき、ｔｉｔｌｅ＃３の再生終了時にａｐｐｌｉｃａｔｉｏｎ＃５をワークメモリから削除するという制御を行いうる。
タイトル間分岐があった場合でも、分岐元−分岐先において生存しているアプリケーションはワークメモリ上に格納しておき、分岐元にはなく、分岐先にのみ存在するアプリケーションをワークメモリに読み込めば良いから、アプリケーションをワークメモリに読み込む回数は必要最低数になる。このように、読込回数を少なくすることにより、タイトルの境界を意識させないアプリケーション、つまりアンバウンダリなアプリケーションを実現することができる。【００８７】  続いてアプリケーションの起動属性についてより詳しく説明する。起動属性には、自動的な起動を示す「ＡｕｔｏＲｕｎ」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Ｐｒｅｓｅｎｔ」、仮想マシンのワークメモリにはおかれるが、ＣＰＵパワーの割り当ては不可となる「Ｓｕｓｐｅｎｄ」がある。
「ＡｕｔｏＲｕｎ」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて生存しており、かつ起動属性がＡｕｔｏＲｕｎに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。【００８８】  起動属性「Ｐｒｅｓｅｎｔ」は、継続属性であり、分岐元ｔｉｔｌｅにおけるアプリケーションの状態を継続することを示す。また対応するアプリケーションを実行してよいことを示す属性である。起動属性が「Ｐｒｅｓｅｎｔ」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから呼出があると、そのアプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤが、アプリケーション管理テーブルに記述されていて、起動属性が「Ｐｒｅｓｅｎｔ」であるか否かを判定する。「Ｐｒｅｓｅｎｔ」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのａｐｐｌｉｃａｔｉｏｎＩＤがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Ｐｒｅｓｅｎｔ」が付与されたアプリケーションに限られることになる。「Ｐｒｅｓｅｎｔ」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−−」である場合、そのアプリケーションの起動属性の起動属性はこのＰｒｅｓｅｎｔであることを意味する。【００８９】  「Ｓｕｓｐｅｎｄ」とは、リソースは割り付けられているが、ＣＰＵパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるＳｕｓｐｅｎｄは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。
図２３は、起動属性がとり得る三態様（Ｐｒｅｓｅｎｔ、ＡｕｔｏＲｕｎ、Ｓｕｓｐｅｎｄ）と、直前タイトルにおけるアプリケーション状態の三態様（非起動、起動中、Ｓｕｓｐｅｎｄ）とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。【００９０】  直前状態が”非起動”であり、起動属性が”Ｐｒｅｓｅｎｔ”、”Ｓｕｓｐｅｎｄ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
直前状態が”起動中”である場合、起動属性が”Ｐｒｅｓｅｎｔ”、”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。【００９１】  起動属性が”Ｓｕｓｐｅｎｄ”であるなら、アプリケーションの状態はＳｕｓｐｅｎｄされることになる。直前状態が”Ｓｕｓｐｅｎｄ”である場合、分岐先タイトルの起動属性が”Ｓｕｓｐｅｎｄ”ならＳｕｓｐｅｎｄを維持することになる。”Ｐｒｅｓｅｎｔ”又は”ＡｕｔｏＲｕｎ”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュームすることになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル再生区間の進行に沿って、Ｊａｖａ（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。【００９２】  尚、直前状態が”Ｓｕｓｐｅｎｄ”であり、分岐先タイトルの起動属性が”Ｐｒｅｓｅｎｔ”の場合は、直前状態、すなわちサスペンド状態を維持しても良い。
最後に、各アプリケーションに対する”起動優先度”について説明する。
この起動優先度は、０〜２５５の値をとり、メモリリソース枯渇時や、ＣＰＵ負荷が高まった時に、どのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャが行うにあたっての判断材料になる。この場合、アプリケーションマネージャは、起動優先度が低いアプリケーションの動作を終了し、起動優先度が高いアプリケーションの動作を継続させるとの処理を行う。【００９３】  また起動優先度は、再生中プレイリストに対する要求が競合した場合のアプリケーション間の調停でも利用される。ここであるアプリケーションが、あるプレイリストの旱送りしているものとする。ここで別のアプリケーションが同じプレイリストに対するポーズ要求を行ったとすると、これらのアプリケーションに付与された起動優先度を比較する。そして早送りを命じたアプリケーションの起動優先度が高いなら、かかるアプリケーションによる早送りを継続して行う。逆にポーズを命じたアプリケーションの起動優先度が高いなら、早送り中プレイリストのポーズを行う。【００９４】  以上の生存区間・起動属性・起動優先度により、仮想マシン上で動作し得るアプリケーションの数を所定数以下に制限するよう規定しておくことがオーサリング時に可能なる。そのため、アプリケーションの安定動作を保証することができる。
＜プレイリスト管理テーブル＞
以上がアプリケーション管理テーブルについての説明である。続いてプレイリスト管理テーブル（ＰＬＭＴ）について説明する。プレイリスト管理テーブルとは、アプリケーションの生存区間において、各アプリケーション実行と同時に行うべき再生制御を示すテーブルである。アプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。そこで起動失敗、異常終了があった場合のＦａｉｌ  Ｓａｆｅ機構として、本実施形態ではアプリケーションの生存区間毎に、プレイリスト管理テーブルを設けている。プレイリスト管理テーブルは、あるアプリケーションの生存区間が開始した際、これと同時に行うべき再生制御を規定する情報である。この再生制御とは、プレイリスト情報に基づくＡＶＣｌｉｐ再生であり、プレイリスト情報による再生制御を同時に行うことで、アプリケーション実行と、プレイリスト再生とが同時になされることになる。プレイリスト管理テーブルは、アプリケーションの生存区間毎に設けられるとしたが、プレイリスト管理テーブルが設けられるアプリケーションは、タイトルバウンダリのアプリケーションに限られる。何故ならタイトルアンバウンダリーアプリケーションは、全タイトルを生存区間にしているため、アプリケーション実行と同時にプレイリスト再生を行うという制御は、適合しないからである。【００９５】  チャプターバウンダリアプリケーションは、１つのプレイリスト内のチャプターからアプリケーション実行を開始するという前提の下で生存区間が規定されているため、プレイリスト再生を規定する必要はないからである。以上のことからプレイリスト管理テーブルは、１つ以上のＴｉｔｌｅからなる生存区間に定義されることになる。
図２４（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。本図に示すようにプレイリスト管理テーブルは、『ＰＬ＿ｉｄ＿ｒｅｆ』と、『Ｐｌａｙｂａｃｋ＿Ａｔｔｒｉｂｕｔｅ』とからなる。【００９６】  図２４（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す。
『ＰＬ＿ｉｄ＿ｒｅｆ』は、プレイリスト識別子に対する”参照値”が記述されることにより、アプリケーションの生存区間において再生可能となるプレイリストがどれであるかを示す。プレイリスト識別子は、ファイルＹＹＹＹＹ．ＭＰＬＳにおいて、ファイル名として付与された５桁の数値ＹＹＹＹＹで表現される。このＹＹＹＹＹが記述されることにより、『ＰＬ−ｉｄ−ｒｅｆ』は、対応するＴｉｔｌｅにおいて再生可能となるプレイリストがどれであるかを示す。【００９７】  『Ｐｌａｙｂａｃｋ＿Ａｔｔｒｉｂｕｔｅ』は、アプリケーション管理テーブルにおける起動属性に倣った属性であり、『ＰＬ＿ｉｄ＿ｒｅｆ』に記述されたプレイリストを、タイトル開始時において、どのように再生するかを規定する再生属性である。プレイリストに対する再生属性には、『ＡｕｔｏＰｌａｙ』、『Ｐｒｅｓｅｎｔ』といった種別がある。
『ＡｕｔｏＰｌａｙ』とは、対応するタイトルの分岐と同時に、そのプレイリストを再生させる旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、その分岐先タイトルにおいて再生可能であり、かつ再生属性がＡｕｔｏＰｌａｙに設定されたプレイリストの再生を開始する。これにより起動属性がＡｕｔｏＰｌａｙに設定されたプレイリストは、タイトル分岐と共に自動的に起動されることになる。【００９８】  『Ｐｒｅｓｅｎｔ』とは、起動属性におけるＰｒｅｓｅｎｔ同様、継続属性であり、分岐元ｔｉｔｌｅにおけるプレイリストの状態を継続することを示す。また対応するプレイリストを再生してよいことを示す属性である。例えば連続して再生される２つのＴｉｔｌｅがあり、前のタイトル側のプレイリスト管理テーブルでは、あるプレイリストの再生属性がＡｕｔｏＰｌａｙに設定され、カレントタイトル側のプレイリスト管理テーブルでは、そのプレイリストの再生属性がＰｒｅｓｅｎｔに設定されているものとする。ここでプレイリストの再生時間が２時間長であり、このうち１時間が経過した時点で分岐が発生したとする。この場合カレントタイトルでは、再生属性がＰｒｅｓｅｎｔに設定されているので、カレントタイトルにおいて、そのプレイリストは、１時間という再生済み区間の直後から、再生されることになる。このように再生属性をＰｒｅｓｅｎｔに設定しておけば、Ｔｉｔｌｅ間の分岐があった場合でも、プレイリスト再生をその残りの部分から開始することができる。これにより分岐し合う一連のＴｉｔｌｅにおいて、共通のプレイリストを再生するという”タイトル間におけるプレイリスト再生の共通化”を容易に実現することができる。また分岐先タイトルが複数ある場合、これら複数タイトルの再生属性を何れもＰｒｅｓｅｎｔにしておけば、複数のうちどれに分岐したとしても、１つの共通のプレイリスト再生を継続させることができる。【００９９】  尚Ｔｉｔｌｅの境界は、シームレス再生を保証しなくてもよいので、上述したように複数Ｔｉｔｌｅ間で１つのプレイリストを再生しようとする場合、分岐前後でプレイリスト再生を中断させることは許容される。
また、再生属性が「Ｐｒｅｓｅｎｔ」である場合、この再生属性が付与されたプレイリストは、他のアプリケーションからの再生要求により再生されることになる。アプリケーション管理を行う管理主体（アプリケーションマネージャ）は、起動中のアプリケーションから、プレイリストの再生要求があると、要求を受けたプレイリストのＰＬ＿ｉｄ＿ｒｅｆが、プレイリスト管理テーブルに記述されていて、再生属性が「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかか否かを判定する。「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかであれば、そのプレイリストを再生する。一方、要求を受けたプレイリストのＰＬ＿ｉｄ＿ｒｅｆがプレイリスト管理テーブルに記述されていない場合、そのプレイリストを再生しない。アプリケーションの要求によるプレイリスト再生は、この「ＡｕｔｏＰｌａｙ」か「Ｐｒｅｓｅｎｔ」のいずれかが付与されたプレイリストに限られることになる。「Ｐｒｅｓｅｎｔ」は、再生属性を明示的に指定しない場合に付与されるデフォルトの再生属性であるから、あるプレイリストの再生属性が無指定「−−」であるとそのプレイリストの再生属性はこのＰｒｅｓｅｎｔであることを意味する。【０１００】  図２５は、プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。図２５の第１段目は、Ｔｉｔｌｅの再生映像を示し、第２段目は、Ｔｉｔｌｅの時間軸を示す。第３段目はＰＬＭＴにより再生が規定されるプレイリスト、第４段目は、アプリケーション実行を示す。第４段目においてａｐｐｌｉｃａｔｉｏｎ＃１は、Ｔｉｔｌｅの開始と共に起動されており、その後、時点ｔ１において動作状態になる。一方ＰｌａｙＬｉｓｔ＃１は、Ｔｉｔｌｅの開始と共に再生が開始されている。Ｐｌａｙｌｉｓｔ＃１の再生は、Ｔｉｔｌｅの開始と同じ時点に開始されているので、第１段目の左側に示すように、Ｔｉｔｌｅの再生開始直後から、アプリケーションが動作状態になるまでのスタートアップディレイにおいて、プレイリストの再生画像ｇｊ１がフルスクリーン表示される。プレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておくことにより、Ｊａｖａ（登録商標）アプリケーションが動作状態になるまで５〜１０秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。【０１０１】  一方、ａｐｐｌｉｃａｔｉｏｎ＃１は、時点ｔ１で動作状態になるので、プレイリスト再生画像を子画面、アプリケーションの実行画像を親画面にした合成画像ｇｊ２が時点ｔ１において表示されることになる。アプリケーションの実行画像は、Ｓｔａｒｔボタン，ｃｏｎｔｉｎｕｅボタン，ＰＯＷＥＲインディケータを配置したゲーム用のＧＵＩフレームワークであり、かかるＧＵＩフレームワークの描画処理をＪａｖａ（登録商標）アプリケーションが実行することでなされる。【０１０２】  こうした、プレイリストの再生映像と、Ｊａｖａ（登録商標）アプリケーションのＧＵＩフレームワークとを組み合わせた再生映像をなすタイトルを構成することができるのが、ＰＬＭＴの特徴である。
図２６は、カレントタイトルがとり得る三態様（プレイリスト管理テーブル無し（ｉ）、プレイリスト管理テーブル有りで尚且つＡｕｔｏＰｌａｙ（ｉｉ）、プレイリスト管理テーブル有りで尚且つ無指定（ｉｉｉ））と、直前タイトルにおけるプレイリストの状態（非再生状態、再生中状態）とがとりうる６通りの組合せを示す図である。【０１０３】  本図における６通りの組合せのうち、”直前状態＝非再生状態”と、”カレントタイトル＝プレイリスト管理テーブル有り、尚且つ、カレントタイトルの再生属性＝ＡｕｔｏＰｌａｙ”との組合せにおいて、分岐先タイトルにおけるプレイリストの再生は、自動的に開始することになる。
また”直前状態＝再生中状態”と、”カレントタイトル＝プレイリスト管理テーブル無し”との組合せにおいて、分岐先タイトルでのプレイリストの再生は、自動的に停止することになる。【０１０４】  そしてこれら２つの組合せ以外は全て、前のタイトルの状態を継続することになる。プレイリスト管理テーブルに基づくプレイリスト再生の開始は、分岐元タイトルにおいて非再生状態であり、分岐先タイトルにおいてＡｕｔｏＰｌａｙ属性が付与されている場合に限られるので、タイトルの分岐発生する毎に、プレイリスト再生を開始させる必要はない。タイトル間の分岐が多数発生したとしても、プレイリスト再生を開始させる回数を必要最低数にすることができる。
プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例について図２７（ａ）を参照しながら説明する。ここで想定する具体例は、２つの連続するＴｉｔｌｅ（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）であリ、そのうちｔｉｔｌｅ＃１では、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が記述されている。ｔｉｔｌｅ＃２ではＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。一方、ｔｉｔｌｅ＃１のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が、ｔｉｔｌｅ＃２のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃２が記述されているものとする。図２７（ｂ）は、図２７（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。【０１０５】  ｔｉｔｌｅ＃１においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、ｔｉｔｌｅ＃１の開始時にはａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が自動的に起動され、ＰｌａｙＬｉｓｔ＃１の再生が自動的に開始される。
ｔｉｔｌｅ＃２においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、ｔｉｔｌｅ＃１側に記載はあるが、ｔｉｔｌｅ＃２側には記載がないａｐｐｌｉｃａｔｉｏｎ＃１の実行は停止させられる。同じくｔｉｔｌｅ＃１側に記載があるが、ｔｉｔｌｅ＃２側に記載がないＰｌａｙＬｉｓｔ＃１の再生も停止させられる。【０１０６】  ｔｉｔｌｅ＃１側に記載はないが、ｔｉｔｌｅ＃２側に記載があるＰｌａｙＬｉｓｔ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３は再生及び実行が自動的に開始することになる。タイトル分岐があれば、その分岐を契機に、再生すべきプレイリストを他のプレイリストに切り換えることができる。このようにアプリケーション管理テーブル、プレイリスト管理テーブルを用いることで分岐を契機にして、プレイリスト再生を切り換えるという処理をオーサリング段階において規定しておくことができる。【０１０７】  また図２７では、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２、ａｐｐｌｉｃａｔｉｏｎ＃３にはそれぞれ２００，１２８，２００の起動優先度が与えられている。これらの起動優先度を付与することにより、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２に対する制御要求が競合した場合の調停を行わせることができる。ここでａｐｐｌｉｃａｔｉｏｎ＃１がＰｌａｙＬｉｓｔ＃１に対し早送りを命じているものとする。一方、ａｐｐｌｉｃａｔｉｏｎ＃２がポーズ要求を行ったとする。この場合、アプリケーション管理テーブルに各アプリケーションに対する起動優先度が規定されているため、この起動優先度に従って、両アプリケーションに対する調停がなされることになる。その結果、ａｐｐｌｉｃａｔｉｏｎ＃２による要求を退け、ａｐｐｌｉｃａｔｉｏｎ＃１による制御を継続するという処理をオーサリング時に規定しておくことができる。起動優先度をプレイリスト管理テーブルと併せて利用することにより、プレイリストに対する制御が競合した場合の調停さえも再生装置に行わせることができる。【０１０８】  プレイリスト管理テーブル記述の他の具体例について説明する。図２８（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。本図で想定しているのは、２つの連続するタイトル（ｔｉｔｌｅ＃１、ｔｉｔｌｅ＃２）において、ｔｉｔｌｅ＃１側のプレイリスト管理テーブルには、ＡｕｔｏＰｌａｙプレイリストとしてＰｌａｙＬｉｓｔ＃１が、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２が記述され、ｔｉｔｌｅ＃１側のアプリケーション管理テーブルには、ＡｕｔｏＰｌａｙアプリケーションであるａｐｐｌｉｃａｔｉｏｎ＃１と、実行可能なアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されている。一方ｔｉｔｌｅ＃２側のプレイリスト管理テーブルには再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述され、アプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。図２８（ｂ）は、図２８（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、ＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃１が記述されているので、ｔｉｔｌｅ＃１の開始時にはａｐｐｌｉｃａｔｉｏｎ＃１が自動起動される。一方、ｔｉｔｌｅ＃１のアプリケーション管理テーブルには、実行可能アプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃２が記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃１からの呼出ｙｄ１によりａｐｐｌｉｃａｔｉｏｎ＃２が起動される。【０１０９】  ｔｉｔｌｅ＃２側のアプリケーション管理テーブルにおいてａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２が非生存になっており、代わりにＡｕｔｏＲｕｎアプリケーションとしてａｐｐｌｉｃａｔｉｏｎ＃３が記述されている。そのためｔｉｔｌｅ＃１−ｔｉｔｌｅ＃２の境界部では、ａｐｐｌｉｃａｔｉｏｎ＃１、ａｐｐｌｉｃａｔｉｏｎ＃２を停止し、ａｐｐｌｉｃａｔｉｏｎ＃３を自動的に起動するとの処理がなされる。プレイリスト管理テーブルを参照すると、ｔｉｔｌｅ＃１側のプレイリスト管理テーブルは、ＰｌａｙＬｉｓｔ＃１、ＰｌａｙＬｉｓｔ＃２が再生可能と記述されており、そのうちＰｌａｙＬｉｓｔ＃１はＡｕｔｏＰｌａｙ属性になっている。そのためＰｌａｙＬｉｓｔ＃１は、ｔｉｔｌｅ＃１の開始時において自動的に再生される。【０１１０】  ｔｉｔｌｅ＃１側のプレイリスト管理テーブルには、ＰｌａｙＬｉｓｔ＃１の他、ＰｌａｙＬｉｓｔ＃２が再生可能であると記述されているので、ａｐｐｌｉｃａｔｉｏｎ＃１はＰｌａｙＬｉｓｔ＃１の再生を停止させ、代わりにＰｌａｙＬｉｓｔ＃２の再生を要求することにより、プレイリスト交代を実行することができる。
ｔｉｔｌｅ＃２側のプレイリスト管理テーブルには、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述されている。そしてＡｕｔｏＰｌａｙ属性が付与されたプレイリストはない。そのため、仮にｔｉｔｌｅ＃１開始時において自動再生されたＰｌａｙＬｉｓｔ＃１の再生がｔｉｔｌｅ＃２まで継続したとしても、ＰｌａｙＬｉｓｔ＃１の再生は自動的に終了することになる。【０１１１】  しかしＰｌａｙＬｉｓｔ＃２再生が継続したままｔｉｔｌｅ＃２に至れば、ＰｌａｙＬｉｓｔ＃２再生はｔｉｔｌｅ＃２開始以降も継続する。ｔｉｔｌｅ＃２のプレイリスト管理テーブルには、再生可能なプレイリストとしてＰｌａｙＬｉｓｔ＃２、ＰｌａｙＬｉｓｔ＃３が記述されている。そのため、ｔｉｔｌｅ＃２で実行中となるａｐｐｌｉｃａｔｉｏｎ＃３は、ＰｌａｙＬｉｓｔ＃２の再生を停止し、代わりにＰｌａｙＬｉｓｔ＃３の再生を要求することにより、再生中のプレイリストを交代させることができる。【０１１２】  以上のようにプレイリスト管理テーブルの再生属性を、”ＡｕｔｏＰｌａｙ”に設定しておけば、Ｊａｖａ（登録商標）アプリケーションの起動に、５〜１０秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。タイトル実行開始時において、アプリケーション起動に時間がかかったとしても、画面は、”とりあえず何かが写っている状態”になる。これにより、アプリケーション起動に時間がかかることによるスタートアップディレイの長期化を補うことができる。【０１１３】  アプリケーション管理テーブル及びプレイリスト管理テーブルを定義することにより、タイトル再生区間の進行に沿って、Ｊａｖａ（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。
＜サウンド管理テーブル＞
以降サウンド管理テーブル（ＳＭＴ）について説明する。【０１１４】  図２９は、サウンド管理テーブルの内部構成を示す図である。本図に示すようにサウンド管理テーブルは、Ｍｉｘｉｎｇ＿Ｏｎフラグを含む。Ｍｉｘｉｎｇ＿Ｏｎフラグとは、０又は１に設定されることにより、サウンドミキシングを有効とするか、無効とするかを示すフラグである。“有効”とは、オーディオストリームの再生音声に対してミキシングを行った上で出力することをいい、“無効”とは、オーディオストリームの再生音声をスルー出力することをいう。【０１１５】  Ｍｉｘｉｎｇ＿Ｏｎフラグが１（ＯＮ）に設定された場合、ファイルｓｏｕｎｄ．ｂｄｍｖによるクリック音を、同じＢＤ−Ｊ  Ｏｂｊｅｃｔに属するＰＬＭＴにて再生がなされるプレイリストの再生音声にミキシングする旨を示す。
Ｍｉｘｉｎｇ＿Ｏｎフラグが０（ＯＦＦ）に設定された場合、ファイルｓｏｕｎｄ．ｂｄｍｖによるクリック音を、同じＢＤ−Ｊ  Ｏｂｊｅｃｔに属するＰＬＭＴにて再生がなされるプレイリストの再生音声にミキシングしない旨を示す。【０１１６】  ファイルｓｏｕｎｄ．ｂｄｍｖによるクリック音をミキシングするかどうかを、Ｊａｖａ（登録商標）アプリケーションの生存区間の単位、つまりタイトルの単位で規定することができる。そして、このＭｉｘｉｎｇ＿Ｏｎフラグをどのような値に設定するかは、そのプレイリストが有するＳＴＮ＿Ｔａｂｌｅの設定内容に応じたものとなる。
図３０（ａ）（ｂ）は、ＳＴＮ＿Ｔａｂｌｅにおけるオーディオストリームについてのｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅと、Ｍｉｘｉｎｇ＿Ｏｎフラグの設定との因果関係を示す図である。図３０（ａ）において、ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅにおけるａｕｄｉｏ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｙｐｅが、“マルチチャネル”を示しているなら、Ｍｉｘｉｎｇ＿Ｏｎフラグは、０（ＯＦＦ）に設定される。図３０（ｂ）において、ｅｎｔｒｙ−ａｔｔｒｉｂｕｔｅにおけるａｕｄｉｏ＿ｐｒｅｓｅｎｔａｔｉｏｎ＿ｔｙｐｅが、“非マルチチャネル”を示しているなら、Ｍｉｘｉｎｇ＿Ｏｎフラグは、１（ＯＮ）に設定される。以上のような設定を行うことで、“マルチチャネル”の再生を行うようなプレイリスト（ＰｌａｙＩｔｅｍ）と、アプリケーションとを同時実行する場合、再生装置における音声再生とのミキシングを無効化することができ、“非マルチチャネル”の再生を行うようなプレイリスト（ＰｌａｙＩｔｅｍ）と、アプリケーションとを同時実行する場合、再生装置における音声再生とのミキシングを有効化することができる。【０１１７】  以降、図２７（ａ）におけるサウンド管理テーブルの一例に対して、再生がどのように行われるかについて説明する。図２７（ａ）におけるＴｉｔｌｅ＃１，＃２のうち、Ｔｉｔｌｅ＃１のＭｉｘｉｎｇ＿Ｏｎフラグは、音声再生とのミキシングを有効化する旨を示しており、Ｔｉｔｌｅ＃２におけるサウンド管理テーブル＃２のＭｉｘｉｎｇ＿Ｏｎフラグは、音声再生とのミキシングを無効化する旨を示しているものとする。【０１１８】  更に、Ｔｉｔｌｅ＃１の再生時には、図２５のようなＧＵＩフレームワークと、プレイリストの再生映像とが出力されたものとする。ユーザがリモコンを介して、図３１に示すように、このＧＵＩフレームワークにおけるボタンを操作したものとする。この場合、このＧＵＩフレームワークを描画したＪａｖａ（登録商標）アプリケーションのアプリケーション管理テーブルと、同じＢＤ−ＪＯｂｊｅｃｔに属するサウンド管理テーブルが、Ｍｉｘｉｎｇ＿Ｏｎフラグ＝１に設定されているなら、ファイルｓｏｕｎｄ．ｂｄｍｖにおけるサウンドデータが、プレイリストの再生音声にミキシングされる。【０１１９】  ここでプレイリストの再生音声が、映画劇中のＢＧＭであり、ファイルｓｏｕｎｄ．ｂｄｍｖにおけるサウンドデータが、「さあゲームを始めるよ！」という音声案内であれば、この映画劇中のＢＧＭと、音声案内とがミキシングされて出力されることになる。
更に、Ｔｉｔｌｅ＃２の再生時には、図２５とは異なるＧＵＩフレームワークと、プレイリストの再生映像とが出力されているものとする。そしてユーザがリモコンを介して、図３２に示すように、このＧＵＩフレームワークにおけるボタンを操作したものとする。この場合、このＧＵＩフレームワークを描画したＪａｖａ（登録商標）アプリケーションのアプリケーション管理テーブルと、同じＢＤ−ＪＯｂｊｅｃｔに属するサウンド管理テーブルが、Ｍｉｘｉｎｇ＿Ｏｎフラグ＝０に設定されているなら、ファイルｓｏｕｎｄ．ｂｄｍｖにおけるサウンドデータは、プレイリストの再生音声にミキシングされない。ここでプレイリストの再生音声が、映画劇中のマルチチャネルのＢＧＭであれば、この映画劇中のＢＧＭのみが出力されることになる。【０１２０】  ＜Ｍｉｘｉｎｇ＿Ｏｎフラグの意義＞
再生しようとしているＡＶＣｌｉｐに、５．１Ｃｈのサラウンド音声のオーディオストリームと、モノラル音声のオーディオストリームが多重化されていたとしても、ＰｌａｙＩｔｅｍのＳＴＮ＿Ｔａｂｌｅにおいて、そのモノラル音声のオーディオストリームの再生が許可され、５．１Ｃｈのサラウンド音声のオーディオストリームの再生が許可されていないような場合は、そのＰｌａｙＩｔｅｍに対応するＭｉｘｉｎｇ＿ＯｎフラグをＯＮにして、クリックオンとのミキシングを実行することができる。こうすることにより、５．１Ｃｈのサラウンド音声のオーディオストリームと、モノラル音声のオーディオストリームとが同一のＡＶＣｌｉｐを構成したとしても、当該ＡＶＣｌｉｐが５．１Ｃｈのサラウンド音声の再生を許していないＰｌａｙＩｔｅｍにて、再生されるような場合は、そのＰｌａｙＩｔｅｍの再生時におけるクリックオンのミキシングを実行することができる。【０１２１】  以上のことを考えれば、クリックオンのミキシングを意図するようなタイトルと、ミキシングを意図しないようなタイトルとを、１つのＢＤ−ＲＯＭに記録しようとする場合、５．１Ｃｈのサラウンド音声をもつＡＶＣｌｉｐと、モノラル音声をもつＡＶＣｌｉｐとを別々にＢＤ−ＲＯＭに記録しておく必要がない。
５．１Ｃｈのサラウンド音声と、モノラル音声とが多重化されたＡＶＣｌｉｐを１つだけ、ＢＤ−ＲＯＭに記録しておき、５．１Ｃｈのサラウンド音声のオーディオストリームの再生が許可しているＰｌａｙＩｔｅｍ情報と、５．１Ｃｈのサラウンド音声のオーディオストリームの再生が許可していないＰｌａｙＩｔｅｍ情報とを記録しておけば、クリックオンのミキシングを意図するようなタイトルと、ミキシングを意図しないようなタイトルとを、１つのＢＤ−ＲＯＭにて供給することができる。【０１２２】  ＡＶＣｌｉｐの数を多くすることなく、クリックオンのミキシングを意図せず、音響面の充実を意図したタイトル、クリックオンのミキシングを意図して、対話面の充実を意図したタイトルの双方を制作して、ユーザに供給することができるので、制作スタジオの手間が少なく、映画制作の効率化を図ることができる。
＜Ｍｏｖｉｅ  Ｏｂｊｅｃｔ、Ｊａｖａ（登録商標）アプリとの関係＞
ＨＤＭＶモードにおけるＭｏｖｉｅ  Ｏｂｊｅｃｔに、クリック音の発音を意図したようなナビゲーションコマンドが組み込まれておらず、ＢＤ−ＪモードにおけるＪａｖａ（登録商標）アプリケーションに、クリック音の発音を意図しているようなバイトコードが組み込まれていない場合、つまり、アプリケーションがクリック音の再生を行わないことが明らかである場合、Ｍｉｘｉｎｇ＿Ｏｎフラグは、０（ＯＦＦ）に設定される。逆にクリック音の発音を意図したようなナビゲーションコマンドやバイトコードが存在する場合、Ｍｉｘｉｎｇ＿Ｏｎフラグは、１（ＯＮ）に設定される。以上のような設定を行うことで、クリック音の再生を行わないアプリケーションと、オーディオの再生を行うようなＰｌａｙＩｔｅｍとを同時実行する場合、再生装置におけるミキシングを無効化することができ、クリック音の再生を行うアプリケーションと、オーディオの再生を行うようなＰｌａｙＩｔｅｍとを同時実行する場合、再生装置におけるミキシングを有効化することができる。
以上が記録媒体についての説明である。続いて本発明に係る再生装置について説明する。【０１２３】  図３３は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムＬＳＩと、ドライブ装置という２つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムＬＳＩは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、ＢＤ−ＲＯＭドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、サウンドプロセッサ６、サウンドプロセッサ７、ミキサー８、サウンドコントローラ９、Ｄ／Ａコンバータ１０、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓデコーダ１１、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓデコーダ１３、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン１４、ＪＰＥＧデコーダ１５、Ｓｔｉｌｌプレーン１６、合成部１７、ＳＴＣ−ｄｅｌｔａ付加部１８、ＡＴＣ−ｄｅｌｔａ付加部１９、ローカルストレージ２０、命令ＲＯＭ２１、ユーザイベント処理部２２、ＰＳＲセット２３、ＣＰＵ２４、シナリオメモリ２５、ローカルメモリ２６から構成される。【０１２４】  先ず初めに、ＢＤ−ＲＯＭに記録されたＡＶＣｌｉｐ再生に係る構成要素（ＢＤドライブ１〜オーディオデコーダ６）について説明する。
ＢＤ−ＲＯＭドライブ１は、ＢＤ−ＲＯＭのローディング／イジェクトを行い、ＢＤ−ＲＯＭに対するアクセスを実行する。
リードバッファ２は、ＦＩＦＯメモリであり、ＢＤ−ＲＯＭから読み出されたＴＳパケットが先入れ先出し式に格納される。【０１２５】  デマルチプレクサ（Ｄｅ−ＭＵＸ）３は、リードバッファ２からＳｏｕｒｃｅパケットを取り出して、このＳｏｕｒｃｅパケットを構成するＴＳパケットをＰＥＳパケットに変換する。そして変換により得られたＰＥＳパケットのうち、ＳＴＮ＿Ｔａｂｌｅに記載されたからＰＩＤをもつものをビデオデコーダ４、オーディオデコーダ６、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓデコーダ１１、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓデコーダ１３のどれかに出力する。【０１２６】  ビデオデコーダ４は、デマルチプレクサ３から出力された複数ＰＥＳパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は１９２０×１０８０であり、このビデオプレーン５に格納されたピクチャデータは、１６ビットのＹＵＶ値で表現された画素データにより構成される。ビデオプレーン５では、ビデオストリームにおける一フレーム毎の再生映像を、スケーリングすることができる。スケーリングとは、一フレーム毎の再生画像をビデオプレーン５全体の１／４（クオータという）、１／１（フルスケールという）のどちらかに変化させることである。かかるスケーリングを、ＢＤ−ＪモードにおいてＣＰＵ２４からの指示に従い実行するので、ビデオストリームの再生画像を、画面の隅に追いやったり、全面的に出すという画面演出が可能になる。【０１２７】  サウンドプロセッサ６は、オーディオストリームを構成するＰＥＳパケットをＰＩＤフィルタ３が出力した際、このＰＥＳパケットを格納しておくデコードバッファ（ＤＢ）６ａと、このバッファに格納されたＰＥＳパケットをデコーダして、ＰＣＭ状態のオーディオデータを出力するオーディオデコーダ６ｂとを含む。
サウンドプロセッサ７は、ＢＤ−ＲＯＭから読み出されたファイルｓｏｕｎｄ．ｂｄｍｖをプリロードしておくプリロードメモリ７ａと、プリロードされたファイルｓｏｕｎｄ．ｂｄｍｖにおける複数のサウンドデータのうち、ＣＰＵ２４により指示されたものをデコードして、ＰＣＭ状態のオーディオデータを出力するオーディオデコーダ７ｂとを含む。プリロードバッファ７ａへのプリロードは、ＢＤ−ＲＯＭの装填時やタイトル切替時に行うことが望ましい。何故なら、ＡＶＣｌｉｐの再生中にファイルｓｏｕｎｄ．ｂｄｍｖを読み出そうとすると、ＡＶＣｌｉｐとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、ＢＤ−ＲＯＭの装填時やタイトル切替時には、ＡＶＣｌｉｐの再生が継続していることは希なので、かかるタイミングにファイルｓｏｕｎｄ．ｂｄｍｖを読み出すことにより、ＡＶＣｌｉｐ再生が途切れないことを、保証することができる。【０１２８】  サウンドミキサ８は、サウンドプロセッサ６、及び、サウンドプロセッサ７から出力されるＰＣＭ状態のサウンドデータをミキシングする。ミキシングにあたってサウンドミキサ８はサンプリング周波数とチャネル数を合わせるため、サウンドプロセッサ６から出力された音声の属性を、サウンドプロセッサ７からから出力される音声属性に変換するとの処理を行う。このサウンドミキサ８によるミキシングは、クリック音の発音を意図したようなナビゲーションコマンド、又は、クリック音の発音を意図したようなバイトコードを、ＣＰＵ２４が解読することでなされる。【０１２９】  サウンドコントローラ９は、サウンドミキサ８から出力された展開された状態のオーディオデータ、及び、サウンドプロセッサ６を介さずに圧縮された状態のオーディオデータのうち、どちらを出力するか切り換える。この音声出力は、Ｓ／ＰＤＩＦ又はＨＤＭＩを介して、テレビ４００又はアンプ５００に出力される。圧縮された状態のオーディオデータを出力する場合は、その出力先のテレビ４００及びアンプ５００においてデコードされる。【０１３０】  Ｄ／Ａ変換部１０は、サウンドミキサ８から出力されるディジタルのオーディオデータをＤ／Ａ変換して、アナログ音声を出力する。
Ｉ−Ｇｒａｐｈｉｃｓデコーダ（ＩＧデコーダ）１１は、ＢＤ−ＲＯＭ又はローカルストレージ２０から読み出されたＩＧストリームをデコードして、非圧縮グラフィクスをＩｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２に書き込む。【０１３１】  Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓ（ＩＧ）プレーン１２は、ＨＤＭＶモードにおいてＩ−Ｇｒａｐｈｉｃｓデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。またＢＤ−Ｊモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。
Ｐ−Ｇｒａｐｈｉｃｓデコーダ１３は、ＢＤ−ＲＯＭ又はローカルストレージ２０から読み出されたＰＧストリームをデコードして、非圧縮グラフィクスをＰｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン１１に書き込む。Ｐ−Ｇｒａｐｈｉｃｓデコーダ１３によるデコードにより、字幕が画面上に現れることになる。【０１３２】  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
ＪＰＥＧデコーダ１５は、ＢＤ−ＲＯＭ又はローカルストレージ２０に記録されているＪＰＥＧデータをデコードして、Ｓｔｉｌｌプレーン１６に書き込む。
Ｓｔｉｌｌプレーン１６は、ＪＰＥＧデータを展開することで得られた非圧縮のグラフィクスデータが格納されるプレーンである。このグラフィクスデータは、Ｊａｖａ（登録商標）アプリが描画する、ＧＵＩフレームワークのいわゆる“壁紙”として用いられる。【０１３３】  合成部１７は、Ｉｎｔｅｒａｃｔｉｖｅ  Ｇｒａｐｈｉｃｓプレーン１２の格納内容と、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｇｒａｐｈｉｃｓプレーン１１の格納内容と、ビデオプレーン５の格納内容と、Ｓｔｉｌｌプレーン１６の格納内容とを合成した合成画像を得る。
ＳＴＣ＿ｄｅｌｔａ付加部１８は、Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ（ＳＴＣ）を生成する。そしてＳＴＣ＿Ｓｅｕｅｎｃｅの切り換わり時において、それまでのＳＴＣ＿ＳｅｕｅｎｃｅにおけるＳＴＣ値（ＳＴＣ１）に、ＳＴＣ＿ｄｅｌｔａと呼ばれるオフセット値を加算することにより、新しいＳＴＣ＿ＳｅｕｅｎｃｅのＳＴＣ値（ＳＴＣ２）を求めて、それまでのＳＴＣ＿ＳｅｕｅｎｃｅにおけるＳＴＣ値（ＳＴＣ１）と、新しいＳＴＣ＿ＳｅｕｅｎｃｅのＳＴＣ値（ＳＴＣ２）とを連続した値にする。【０１３４】  先行ＳＴＣ＿Ｓｅｕｅｎｃｅにおいて最後に再生されるピクチャの表示開始時刻をＰＴＳ１（１ｓｔＥＮＤ）、ピクチャの表示期間をＴｐｐとし、後続ＳＴＣ＿Ｓｅｕｅｎｃｅにおいて最初に表示されるピクチャの開始時刻をＰＴＳ２（２ｎｄＳＴＡＲＴ）とした場合、ＳＴＣ＿ｄｅｌｔａはＳＴＣ＿ｄｅｌｔａ＝ＰＴＳ１（１ｓｔＥＮＤ）＋Ｔｐｐ−ＰＴＳ２（２ｎｄＳＴＡＲＴ）として表現される。以上のようにＳＴＣ＿ｄｅｌｔａを求め、これが足し合わされたクロックの計数値を各デコーダに出力する。これにより各デコーダは、２つのＳＴＣ＿Ｓｅｕｅｎｃｅにあたるストリームを途切れなく再生してゆくことができる。以上により、１つのＡＶＣｌｉｐの中に、２以上のＳＴＣ＿Ｓｅｕｅｎｃｅが存在したとしても、また、連続して再生されるべき２以上のＡＶＣｌｉｐのそれぞれが、異なるＳＴＣ＿Ｓｅｕｅｎｃｅをもっていたとしても、これらのＳＴＣ＿Ｓｅｕｅｎｃｅ間のデコード処理を、シームレスに実行することができる。【０１３５】  また、バッファリングの連続性をみたすには、以下の１），２）を満たせば良い。
１）ＳＴＣ２（２ｎｄＳＴＡＲＴ）＞ＳＴＣ２（１ｓｔＥＮＤ）をみたすこと、
ここでＳＴＣ２（１ｓｔＥＮＤ）は、ＳＴＣ１（１ｓｔＥＮＤ）を、ＳＴＣ２の時間軸に投影した値であり、ＳＴＣ２（１ｓｔＥＮＤ）＝ＳＴＣ１（１ｓｔＥＮＤ）−ＳＴＣ＿ｄｅｌｔａという計算式で与えられる。
２）ＴＳ１からのＴＳパケットの取り出しと、ＴＳ２からのＴＳパケットの取り出しとが、同じ時間軸に投影されたＳＴＣ１と、ＳＴＣ２とにより定義され、バッファのアンダーフローや、オーバーフローをもたらさないこと。
ＡＴＣ＿ｄｅｌｔａ付加部１９は、Ａｒｒｉｖａｌ  Ｔｉｍｅ  Ｃｌｏｃｋ（ＡＴＣ）を生成する。そしてＡＴＣ＿Ｓｅｕｅｎｃｅの切り換わり時において、それまでのＡＴＣ＿ＳｅｕｅｎｃｅにおけるＡＴＣ値（ＡＴＣ１）に、ＡＴＣ＿ｄｅｌｔａと呼ばれるオフセット値を加算することにより、それまでのＡＴＣ＿ＳｅｕｅｎｃｅにおけるＡＴＣ値（ＡＴＣ１）と、新しいＡＴＣ＿ＳｅｕｅｎｃｅのＡＴＣ値（ＡＴＣ２）とを連続した値にする。この加算により、ＡＴＣ２＝ＡＴＣ１＋ＡＴＣ＿ｄｅｌｔａになる。ＡＴＣ＿ｄｅｌｔａとは、これまで読み出されているトランスポートストリーム（ＴＳ１）の最後のＴＳパケットの入力時点Ｔ１から、新たに読み出されたトランスポートストリーム（ＴＳ２）の最初のＴＳパケットの入力時点Ｔ２までのオフセット値をいい、“ＡＴＣ＿ｄｅｌｔａ≧Ｎ１／ＴＳ＿ｒｅｃｏｒｄｉｎｇ＿ｒａｔｅ”という計算式で与えられる。ここで入力時点Ｔ２は、ＴＳ２の最初のＴＳパケットの入力時点を、ＴＳ１の時間軸上に投影した時点を意味する。またＮ１は、ＴＳ１の最後のビデオＰＥＳパケットに後続する、ＴＳパケットのパケット数である。ＢＤ−ＲＯＭにおいてかかるＡＴＣ＿ｄｅｌｔａは、Ｃｌｉｐ情報に記述されるので、これを用いることにより、ＡＴＣ＿ｄｅｌｔａを計算することができる。以上の計算により、これまでのＡＴＣ＿ＳｅｕｅｎｃｅがもっているＡＴＣ値（ＡＴＣ１）と、新たなＡＴＣ＿ＳｅｕｅｎｃｅがもっているＡＴＣ値（ＡＴＣ２）とを、連続した値にすることができる。ＡＴＣ＿ｄｅｌｔａが足し合わされたクロックの計数値をデマルチプレクサ（Ｄｅ−ＭＵＸ）３に出力することで、シームレスなバッファ制御を実現することができる。
以上がＡＶＣｌｉｐ再生に係る構成要素である。続いてＢＤ−Ｊモードでの動作に係る構成要素（ローカルストレージ２０〜ローカルメモリ２６）について説明する。【０１３６】  ローカルストレージ２０は、ｗｅｂサイトからダウンロードされたコンテンツ等、ＢＤ−ＲＯＭ以外の記録媒体、通信媒体から供給されたコンテンツを、メタデータと共に格納しておくためのハードディスクである。このメタデータは、ダウンロードコンテンツをローカルストレージ２０にバインドして管理するための情報であり、このローカルストレージ２０をアクセスすることで、ＢＤ−Ｊモードにおけるアプリケーションは、ダウンロードコンテンツ長さを利用した様々な処理を行うことができる。【０１３７】  続いて、再生装置における統合制御を実現する構成要素（命令ＲＯＭ２１〜ローカルメモリ２６）について説明する。
命令ＲＯＭ２１は、再生装置の制御を規定するソフトウェアを記憶している。
ユーザイベント処理部２２は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うユーザイベントをＣＰＵ２４に出力する。【０１３８】  ＰＳＲセット２３は、再生装置に内蔵されるレジスタであり、６４個のＰｌａｙｅｒ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒ（ＰＳＲ）と、４０９６個のＧｅｎｅｒａｌ  Ｐｕｒｐｏｓｅ  Ｒｅｇｉｓｔｅｒ（ＧＰＲ）とからなる。Ｐｌａｙｅｒ  Ｓｔａｔｕｓ  Ｒｅｇｉｓｔｅｒの設定値（ＰＳＲ）のうち、ＰＳＲ４〜ＰＳＲ８は、現在の再生時点を表現するのに用いられる。
ＰＳＲ４は、１〜１００の値に設定されることで、現在の再生時点が属するタイトルを示し、０に設定されることで、現在の再生時点がトップメニューであることを示す。【０１３９】  ＰＳＲ５は、１〜９９９の値に設定されることで、現在の再生時点が属するチャプター番号を示し、０ｘＦＦＦＦに設定されることで、再生装置においてチャプター番号が無効であることを示す。
ＰＳＲ６は、０〜９９９の値に設定されることで、現在の再生時点が属するプレイリスト（カレントＰＬ）の番号を示す。【０１４０】  ＰＳＲ７は、０〜２５５の値に設定されることで、現在の再生時点が属するＰｌａｙＩｔｅｍ（カレントＰｌａｙ  Ｉｔｅｍ）の番号を示す。
ＰＳＲ８は、０〜ＯｘＦＦＦＦＦＦＦＦの値に設定されることで、４５ＫＨｚの時間精度を用いて現在の再生時点（カレントＰＴＭ（Ｐｒｅｓｅｎｔａｔｉｏｎ  ＴｉＭｅ））を示す。以上のＰＳＲ４〜ＰＳＲ８により、図１８（ａ）におけるＢＤ−ＲＯＭ全体の時間軸において、現在の再生時点はどこであるかを特定することができる。【０１４１】  ＣＰＵ２４は、命令ＲＯＭ２１に格納されているソフトウェアを実行して、再生装置全体の制御を実行する。この制御の内容は、ユーザイベント処理部２２から出力されたユーザイベント、及び、ＰＳＲセット２３における各ＰＳＲの設定値に応じて動的に変化する。
シナリオメモリ２５は、カレントのＰＬ情報やカレントのＣｌｉｐ情報を格納しておくためのメモリである。カレントＰＬ情報とは、ＢＤ−ＲＯＭに記録されている複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントＣｌｉｐ情報とは、ＢＤ−ＲＯＭに記録されている複数Ｃｌｉｐ情報のうち、現在処理対象になっているものをいう。【０１４２】  ローカルメモリ２６は、ＢＤ−ＲＯＭからの読み出しは低速である故、ＢＤ−ＲＯＭの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２６が存在することにより、ＢＤ−Ｊモードにおけるアプリケーション実行は、効率化されることになる。
以上が、本実施形態に係る再生装置のハードウェア構成である。続いて本実施形態に係る再生装置のソフトウェア構成について説明する。
図３４は、ＲＯＭ２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のａ），ｂ），ｃ）からなる。つまり、
ａ）ＢＤ  Ｐｌａｙｅｒ  Ｄｅｖｉｃｅの第１階層、
ｂ）ＢＤ  Ｐｌａｙｅｒ  Ｍｏｄｅｌの第２階層、
ｃ）Ａｐｐｌｉｃａｔｉｏｎ  Ｒｕｎｔｉｍｅ  Ｅｎｖｉｒｏｍｅｎｔの第３階層からなる。
これらの階層のうち図３４に示した再生装置のハードウェア構成は、第１階層に属することになる。本図の第１階層”ＢＤ  Ｐｌａｙｅｒ  Ｄｅｖｉｃｅ”には、図３４に示したハードウェア構成のうちビデオデコーダ４、オーディオデコーダ６、ＩＧデコーダ１１、ＰＧデコーダ１３にあたる”デコーダ”と、ビデオプレーン５、ＩＧプレーン１２、ＰＧプレーン１４にあたる”プレーン”、ＢＤ−ＲＯＭ及びそのファイルシステム、ローカルストレージ２０及びそのファイルシステムを含む。【０１４３】  第２階層”ＢＤ  Ｐｌａｙｅｒ  Ｍｏｄｅｌ”は、以下のｂ１），ｂ２）の層からなる。つまり、
ｂ２）Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２の層
ｂ１）Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０及びＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１の層
からなり、自身より上位の階層に対し、ファンクションＡＰＩを提供する。
第３階層”Ａｐｐｌｉｃａｔｉｏｎ  Ｒｕｎｔｉｍｅ  Ｅｎｖｉｒｏｍｅｎｔ”は、以下のｃ１），ｃ２）の階層からなる。つまり、
ｃ１）モジュールマネージャ３４が存在する層、
ｃ２）ＢＤ−Ｊプラットフォーム３５が存在する層
からなる。
先ず初めに、第２層に属するＶｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０〜モジュールマネージャ３４について説明する。【０１４４】  Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０は、ローカルストレージ２０に格納されたダウンロードコンテンツを、ＢＤ−ＲＯＭにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでローカルストレージ２０に格納されたダウンロードコンテンツは、ＳｕｂＣｌｉｐ、Ｃｌｉｐ情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はＢＤ−ＲＯＭ及びローカルストレージ２０のどちらに存在するＣｌｉｐ情報であっても、指定できる点で、ＢＤ−ＲＯＭ上のプレイリスト情報と異なる。この指定にあたって、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０上のプレイリスト情報は、ＢＤ−ＲＯＭやローカルストレージ２０におけるファイルをフルパスで指定する必要はない。ＢＤ−ＲＯＭ上のファイルシステムやローカルストレージ２０上のファイルシステムは、仮想的な１つのファイルシステム（Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０）として、認識されるからである。故に、ＰｌａｙＩｔｅｍ情報におけるＣｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅは、Ｃｌｉｐ情報の格納したファイルのファイルボデイにあたる５桁の数値を指定することにより、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０、ＢＤ−ＲＯＭ上のＡＶＣｌｉｐを指定することができる。Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０を介してローカルストレージ２０の記録内容を読み出し、ＢＤ−ＲＯＭの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。ローカルストレージ２０と、ＢＤ−ＲＯＭとを組合せてなるディスクコンテンツは、ＢＤ−ＲＯＭにおけるディスクコンテンツと対等に扱われるので、本願における”ＢＤ−ＲＯＭ”は、ローカルストレージ２０＋ＢＤ−ＲＯＭの組合せからなる仮想的な記録媒体をも含むことにする。【０１４５】  Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１は、ＡＶ再生ファンクションを実行する。再生装置のＡＶ再生ファンクションとは、ＤＶＤプレーヤ、ＣＤプレーヤから踏襲した伝統的な機能群であり、再生開始（Ｐｌａｙ）、再生停止（Ｓｔｏｐ）、一時停止（Ｐａｕｓｅ  Ｏｎ）、一時停止の解除（Ｐａｕｓｅ  Ｏｆｆ）、Ｓｔｉｌｌ機能の解除（ｓｔｉｌｌ  ｏｆｆ）、速度指定付きの早送り（Ｆｏｒｗａｒｄ  Ｐｌａｙ（ｓｐｅｅｄ））、速度指定付きの巻戻し（Ｂａｃｋｗａｒｄ  Ｐｌａｙ（Ｓｐｅｅｄ））、音声切り換え（Ａｕｄｉｏ  Ｃｈａｎｇｅ）、副映像切り換え（Ｓｕｂｔｉｔｌｅ  Ｃｈａｎｇｅ）、アングル切り換え（Ａｎｇｌｅ  Ｃｈａｎｇｅ）といった機能である。ＡＶ再生ファンクションを実現するべく、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１は、リードバッファ２上に読み出されたＡＶＣｌｉｐのうち、所望に時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、Ｐ−Ｇｒａｐｈｉｃｓデコーダ１３、Ｉ−Ｇｒａｐｈｉｃｓデコーダ１０、オーディオデコーダ６を制御する。所望の時刻としてＰＳＲ８（カレントＰＴＭ）に示される箇所のデコードを行わせることにより、ＡＶＣｌｉｐにおいて、任意の時点を再生を可能することができる。【０１４６】  再生制御エンジン（Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ（ＰＣＥ））３２は、プレイリストに対する再生制御ファンクション（ｉ）、ＰＳＲセット２３における状態取得／設定ファンクション（ｉｉ）といった諸機能を実行する。プレイリストに対する再生制御ファンクションとは、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１が行うＡＶ再生ファンクションのうち、再生開始や再生停止を、カレントＰＬ情報及びＣｌｉｐ情報に従って行わせることをいう。これら機能（ｉ）〜（ｉｉ）は、ＨＤＭＶモジュール３３〜ＢＤ−Ｊプラットフォーム３５からのファンクションコールに応じて実行する。【０１４７】  モジュールマネージャ３４は、ＢＤ−ＲＯＭから読み出されたＩｎｄｅｘ．ｂｄｍｖを保持して、分岐制御を行う。この分岐制御は、カレントタイトルを構成する動的シナリオにＴｅｒｍｉｎａｔｅイベントを発行し、分岐先タイトルを構成する動的シナリオにＡｃｔｉｖａｔｅイベントを発行することでなされる。
以上がＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１〜モジュールマネージャ３４についての説明である。続いてＢＤ−Ｊプラットフォーム３５について説明する。【０１４８】  ＢＤ−Ｊプラットフォーム３５は、いわゆるＪａｖａ（登録商標）プラットフォームであり、Ｊａｖａ（登録商標）仮想マシン３６を中核にした構成になっている。ＢＤ−Ｊプラットフォーム３５は、上述したＪａｖａ（登録商標）２Ｍｉｃｒｏ＿Ｅｄｉｔｉｏｎ（Ｊ２ＭＥ）Ｐｅｒｓｏｎａｌ  Ｂａｓｉｓ  Ｐｒｏｆｉｌｅ（ＰＢＰ  １．０）と、Ｇｌｏｂａｌｌｙ  Ｅｘｅｃｕｔａｂｌｅ  ＭＨＰ  ｓｐｅｃｉｆｉｃａｔｉｏｎ（ＧＥＭ［１．０．２］）ｆｏｒ  ｐａｃｋａｇｅ  ｍｅｄｉａ  ｔａｒｇｅｔｓに加え、ＢＤ−Ｊ  Ｅｘｔｅｎｔｉｏｎを実装している。ＢＤ−Ｊ  Ｅｘｔｅｎｔｉｏｎは、ＧＥＭ［１．０．２］を越えた機能を、ＢＤ−Ｊプラットフォームに与えるために特化された、様々なパッケージを含んでいる。【０１４９】  先ず初めに、ＢＤ−Ｊプラットフォーム３５の中核となるＪａｖａ（登録商標）仮想マシン３６について説明する。
＜Ｊａｖａ（登録商標）仮想マシン３６＞
図３５は、Ｊａｖａ（登録商標）仮想マシン３６の内部構成を示す図である。本図に示すようにＪａｖａ（登録商標）仮想マシン３６は、図３３に示したＣＰＵ２４と、ユーザクラスローダ５２、メソッドエリア５３、ワークメモリ５４、スレッド５５ａ，ｂ・・・ｎ、Ｊａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎとから構成される。【０１５０】  ユーザクラスローダ５２は、ＢＤＪＡディレクトリのＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルをローカルメモリ２６等から読み出してメソッドエリア５３に格納する。このユーザクラスローダ５２によるクラスファイル読み出しは、ファイルパスを指定した読み出しをアプリケーションマネージャ３７がユーザクラスローダ５２に指示することでなされる。ファイルパスがローカルメモリ２６を示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルを、ローカルメモリ２６からワークメモリ５４に読み出す。ファイルパスがＶｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０上のディレクトリを示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するＪａｖａ（登録商標）アーカイブファイルにおけるクラスファイルを、ＢＤ−ＲＯＭ又はローカルストレージ２０からワークメモリ５４に読み出す。アプリケーションの起動制御は、このユーザクラスローダ５２によるクラスファイル読み出しにより実現される。読み出しが指示されたクラスファイルがローカルメモリ２６にない場合、ユーザクラスローダ５２は読み出し失敗をアプリケーションマネージャ３７に通知することになる。【０１５１】  メソッドエリア５３は、ユーザクラスローダ５２によりローカルメモリ２６から読み出されたクラスファイルが格納される。
ワークメモリ５４は、いわゆるヒープエリアであり、様々なクラスファイルのインスタンスが格納される。図３４に示したアプリケーションマネージャ３７は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成するｘｌｅｔプログラムである。かかるｘｌｅｔプログラムをワークメモリ５４に配置することによりアプリケーションは実行可能な状態になる。【０１５２】  図３４のレイアモデルでは、このワークメモリ５４上のアプリケーションマネージャ３７を、Ｊａｖａ（登録商標）仮想マシン３６上に描いていたが、これはわかり易すさを意図した配慮に過ぎない。アプリケーションマネージャ３７及びアプリケーションはインスタンスとしてスレッド５５ａ，ｂ・・・ｎにより実行されるというのが、現実的な記述になる。
スレッド５５ａ，ｂ・・・ｎは、ワークメモリ５４に格納されたメソッドを実行する論理的な実行主体であり、ローカル変数や、オペランドスタックに格納された引数をオペランドにして演算を行い、演算結果を、ローカル変数又はオペランドスタックに格納する。図中の矢印ｋｙ１，ｋｙ２，ｋｙｎは、ワークメモリ５４からスレッド５５ａ，ｂ・・・ｎへのメソッド供給を象徴的に示している。物理的な実行主体がＣＰＵ唯１つであるのに対し、論理的な実行主体たるスレッドは、最大６４個Ｊａｖａ（登録商標）仮想マシン３６内に存在し得る。この６４個という数値内において、スレッドを新規に作成することも、既存のスレッドを削除することも可能であり、スレッドの動作数は、Ｊａｖａ（登録商標）仮想マシン３６の動作中において増減し得る。スレッドの数は適宜増やすことができるので、複数スレッドにより１つのインスタンスの並列実行を行い、インスタンスの高速化を図ることもできる。本図ではＣＰＵ２４と、スレッドとの対応関係は、１対多の関係にしているが、ＣＰＵが複数ある場合、ＣＰＵとスレッドとの対応関係は多対多の関係になりうる。スレッド５５ａ，ｂ・・・ｎによるメソッド実行は、メソッドをなすバイトコードを、ＣＰＵ２４のネイティブコードに変換した上、ＣＰＵ２４に発行することでなされる。このネイティブコード変換については、本願の主眼から外れるため、説明を省く。【０１５３】  Ｊａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎは、スレッド５５ａ，ｂ・・・ｎと１対１の比率で存在しており、プログラムカウンタ（図中のＰＣ）と、１つ以上のフレームとを内部に持つ。”プログラムカウンタ”は、インスタンスにおいて、現在どの部分が実行されているかを示す。”フレーム”はメソッドに対する１回のコールに対して割り当てられたスタック式の領域であり、その１回のコール時の引数が格納される”オペランドスタック”と、コールされたメソッドが用いる”ローカル変数スタック（図中のローカル変数）”とからなる。フレームは、コールが１回なされる度にＪａｖａ（登録商標）スタック５６ａ，ｂ・・・ｎ上に積み上げられるのだから、あるメソッドが自身を再帰的に呼び出す場合も、このフレームは、１つ積み上げられることになる。【０１５４】  以上がＪａｖａ（登録商標）仮想マシンについての説明である。
＜アプリケーションマネージャ３７＞
アプリケーションマネージャ３７は、Ｊａｖａ（登録商標）仮想マシン３６内のワークメモリ上で動作するシステムソフトウェアであり、タイトル分岐が発生する度に、分岐前タイトルでは実行されていないが、新たなタイトルではＡｕｔｏＲｕｎの起動属性を有するアプリケーションを起動するようＪａｖａ（登録商標）仮想マシン３６に指示する。それと共に、分岐前タイトルでは実行されていたが、新たなタイトルを生存区間としないアプリケーションを終了させる。これら起動制御及び終了制御は、カレントＢＤ−Ｊ  Ｏｂｊｅｃｔにおけるアプリケーション管理テーブルを参照した上でなされる。【０１５５】  図３６は、ＢＤ−Ｊ  Ｏｂｊｅｃｔにおけるアプリケーション管理テーブルに基づく、アプリケーションマネージャ３７の処理を示す図である。
図３６における☆１，☆２，☆３は、アプリケーション管理テーブル参照（☆１）、Ｊａｖａ（登録商標）仮想マシン３６に対するアプリケーション起動指示（☆２）、Ｊａｖａ（登録商標）仮想マシン３６による、Ｊａｖａ（登録商標）アーカイブファイルに対する読み出し指示（☆３）、Ｊａｖａ（登録商標）アプリケーションを定義するクラスファイルのクラスロード（☆４，５，６）という一連の過程を模式化して示す。この起動指示によりＪａｖａ（登録商標）仮想マシン３６は、ローカルメモリ２６からワークメモリにｘｌｅｔプログラムを読み出す。【０１５６】  図３７は、ＢＤ−Ｊ  ＯｂｊｅｃｔにおけるＰＬＭＴに基づく、アプリケーションマネージャ３７の処理を示す図である。▽１は、ＢＤ−Ｊ  ＯｂｊｅｃｔにおけるＰＬＭＴの参照を示し、▽２は、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１に対するプレイリスト情報の読み出し指示を示す。
図３７における◎１，２，３，４は、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０経由のプレイリスト情報読み出し（◎１）、プレイリスト情報を構成するＰｌａｙＩｔｅｍ情報の解読（◎２）、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０経由のＣｌｉｐ情報読み出し（◎３）、Ｃｌｉｐ情報の解読（◎４）を模式化したものである。以上の過程を経てＣｌｉｐ情報、プレイリスト情報が解読されれば、ＡＶＣｌｉｐを構成するＴＳパケットを、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０を通じてＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１に引き渡す。このようにしてＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１にＴＳパケットが順次渡れば、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１はＡＶＣｌｉｐを構成するＴＳパケットをデコーダに出力して、プレーンに表示させる。図中の☆１，２，３，４は、ＡＶＣｌｉｐを構成するＴＳパケットの読み出し（☆１，２）、Ｖｉｒｔｕａｌ  Ｆｉｌｅ  Ｓｙｓｔｅｍ３０からＰｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１へのＴＳパケット引き渡し（☆３）、デコーダへのＴＳパケット投入（☆４）、デコーダから各種プレーンへのデコード結果出力（☆５）を模式的に示している。【０１５７】  図３８は、ＢＤ−Ｊ  Ｏｂｊｅｃｔにおけるサウンド管理テーブルに基づく、アプリケーションマネージャ３７の処理を示す図である。図３８における◎０．１，２は、アプリケーションマネージャ３７によるＢＤ−ＪＯｂｊｅｃｔ内のサウンド管理テーブルの参照（◎０）、アプリ生存区間毎のサウンドミキシングの有効化、無効化の指示（◎１）。操作されたボタンに対応するサウンドデータの、出力指示又はデコード指示（◎２）を模式的に示したものである。【０１５８】  以降、ソフトウェアによるアプリケーションマネージャ３７の実装について説明する。図３９は、アプリケーションマネージャ３７による処理手順を示すフローチャートである。本図における処理手順は、ステップＳ１−ステップＳ２−ステップＳ３−ステップＳ４からなるメインループを有している。ステップＳ１は、ＴｉｔｌｅＪｕｍｐがなされたか否かの判定であり、もしなされればＴｉｔｌｅ切り換えを行う（ステップＳ７）。【０１５９】  ステップＳ８は、カレントタイトルに対応するＢＤ−ＪＯｂｊｅｃｔに、ＰＬＭＴが存在するか否かの判定である。もし存在しないのであれば、前のタイトルでは、ＰＬＭＴに記載されていたプレイリストの再生を停止させる（ステップＳ９）。
もし存在するのであれば、前のタイトルではＰＬＭＴに記載されていなかったが、カレントタイトルでは、ＰＬＭＴに記載されており、ＡｕｔｏＰｌａｙ属性が付与されているプレイリストの再生を開始させる（ステップＳ１０）。【０１６０】  ステップＳ１１では、カレントＴｉｔｌｅに対応するＢＤ−ＪＯｂｊｅｃｔに、サウンド管理テーブルが存在するか否かの判定を行う。ステップＳ１２は、サウンド管理テーブルが存在する場合に実行される判定ステップであり、そのサウンド管理テーブルにおけるＭｉｘｉｎｇ＿Ｏｎフラグが１であるか否かの判定を行う。もしＭｉｘｉｎｇ＿Ｏｎフラグが１であるなら、サウンドミキシングを有効化するようサウンドコントローラ９に指示し（ステップＳ１３）、もしＭｉｘｉｎｇ＿Ｏｎフラグが０であるなら、サウンドミキシングを無効化するようサウンドコントローラ９に指示する（ステップＳ１４）。【０１６１】  ステップＳ１５は、カレントＴｉｔｌｅに対応するＢＤ−ＪＯｂｊｅｃｔにアプリケーション管理テーブルが存在するか否かの判定であり、もし存在するなら、前のＴｉｔｌｅを生存区間としていないが、カレントＴｉｔｌｅを生存区間としているＪａｖａ（登録商標）アプリケーションであって、ＡｕｔｏＲｕｎ属性を有するものを起動する（ステップＳ１６）。もし存在しないなら、前のＴｉｔｌｅを生存区間としているが、カレントＴｉｔｌｅを生存区間としていないアプリを停止する（ステップＳ１７）。【０１６２】  その後、Ｊａｖａ（登録商標）アプリケーションの起動に成功したか否かの判定を行い（ステップＳ１８）、起動に成功すれば（ステップＳ１８でＹｅｓ）、ＡｕｔｏＰｌａｙＰＬの再生画像をクオータ（１／４）に変換する（ステップＳ１９）という手順を実現するものである。
一方このステップＳ１８がＮｏであればステップＳ２３、Ｓ２４、Ｓ１６、Ｓ１８からなるループ処理を実行することになる。本ループ処理における制御変数は、再起動カウンタである。再起動カウンタは、アプリケーションの再起動回数を規定するカウンタである。本再起動カウンタは、本フローチャートの起動時にリセットされ、ステップＳ２３において、０か否かの判定がなされる。０でない場合、ステップＳ２４において再起動カウンタはデクリメントされる。以上のステップＳ２３、Ｓ２４、Ｓ１６、Ｓ１８〜ステップＳ１９からなるループ処理により、再起動カウンタが０でない限り、ＡｕｔｏＲｕｎアプリケーションの起動は繰り返されることになる。かかる繰り返しにより、アプリケーションの起動が保証されることになる。【０１６３】  ステップＳ２は、メインとなるアプリケーションが実行されてない状態かどうかの判定であり、もしそうであれば、ステップＳ５の判定を行う。ステップＳ５は、アプリケーションが正常終了したかの判定である。もし異常終了していればステップＳ２１、ステップＳ２２の処理を実行する。正常終了していればステップＳ２１〜ステップＳ２２を実行せず、ステップＳ１〜ステップＳ４からなるメインループに戻る。【０１６４】  ステップＳ２１は、ＡｕｔｏＰｌａｙＰＬの再生中であるか否かの判定であり、もし再生中なら、ＡｕｔｏＰｌａｙＰＬの再生画像をフルスクリーン化するようＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に指示する（ステップＳ２２）。その後、ステップＳ２３に移行する。ステップＳ２３への移行により、異常終了時においてもステップＳ１４〜ステップＳ１７からなるループ処理が実行されることになる。これにより再起動カウンタの回数が０になるまで、アプリケーションの再起動は繰り返されることになる。【０１６５】  ステップＳ４は、ＢＤドライブ１にＢＤ−ＲＯＭが存在しているか否かの判定であり、もしＢＤ−ＲＯＭが存在しなければ、全てのアプリケーションに対し、終了指示を発する（ステップＳ６）。
以上のように本実施形態によれば、マルチチャネルでの音声出力を意図するような再生制御の実行時にはサウンドミキシングを無効化しておき、マルチチャネルでの音声出力を意図しないような再生制御の実行時にはサウンドミキシングを有効化しておくことができる。【０１６６】  これにより、映画の制作スタジオは、マルチチャネルでの再生を意図している場合は、クリック音を禁止し、代わりにクリック音での再生を意図している場合は、代わりにマルチチャネルによる音声出力を禁止するという調整が可能になる。
クリック音の導入により“マルチチャネルの音声出力が途切れるのではないか”という不安の呪縛から、制作スタジオを解放することができるので、映画作品作成にあたってのクリック音の導入に弾みをつけることができる。【０１６７】  尚、第１実施形態では、マルチチャネルが５．１ＣＨのサラウンド音声であり、オーディオストリームがこのマルチチャネルの属性を有している場合、Ｍｉｘｉｎｇ＿ＯｎフラグをＯＦＦにすると説明したが、マルチチャネルが２ＣＨのステレオ音声を意味し、オーディオストリームがステレオ属性を有している場合、Ｍｉｘｉｎｇ＿ＯｎフラグをＯＦＦにしてもよい。
ステレオ音声を展開した後のデータ量はそれ程大きい訳ではなく、ＬＰＣＭ状態に展開した後に、サウンドミキシングを行っても、デジタル出力が可能になることもある。このように、ステレオ音声の展開後のデータ量はそれ程大きくないと期待でき、デジタル出力が可能であることは確認し得た場合、マルチチャネルをＯＮに設定してもよい。
（第２実施形態）
第１実施形態では、プレイリストの自動再生がなされたアプリケーションの生存区間毎にＭｉｘｉｎｇ＿Ｏｎフラグを設けたが、これは見方を変えると、プレイリストと、アプリケーション生存区間とが等価であり、プレイリストを構成する再生区間毎に、Ｍｉｘｉｎｇ＿Ｏｎフラグによる制御が及ぶと考えることができる。
これらに鑑み、本実施形態ではＭｉｘｉｎｇ＿Ｏｎフラグをプレイリスト情報に設ける技術を提案する。【０１６８】  図４０（ａ）は、第２実施形態に係るプレイリスト情報の内部構成を示す図である。本図が、図８（ａ）に示したプレイリスト情報の内部構成と異なるのは、ＰｌａｙＩｔｅｍ情報内にＭｉｘｉｎｇ＿Ｏｎフラグが設けられている点である。図４０（ｂ）は、ＰｌａｙＩｔｅｍ情報内に設けられた、Ｍｉｘｉｎｇ＿Ｏｎフラグの内容を示す図である。
Ｍｉｘｉｎｇ＿Ｏｎフラグが１に設定された場合、ファイルｓｏｕｎｄ．ｂｄｍｖによるクリック音を、ＰｌａｙＩｔｅｍの再生音声にミキシングする旨を示す。【０１６９】  Ｍｉｘｉｎｇ＿Ｏｎフラグが０に設定された場合、ファイルｓｏｕｎｄ．ｂｄｍｖによるクリック音を、ＰｌａｙＩｔｅｍの再生音声にミキシングしない旨を示す。
ファイルｓｏｕｎｄ．ｂｄｍｖによるクリック音をミキシングするかどうかを、プレイリストの単位で規定することができる。そして、このＭｉｘｉｎｇ＿Ｏｎフラグをどのような値に設定するかは、そのＰｌａｙＩｔｅｍ情報が有するＳＴＮ＿Ｔａｂｌｅの設定内容に応じたものとなる。【０１７０】  以上が、第２実施形態に係る記録媒体の改良である。続いて第２実施形態に係る再生装置の改良について説明する。第２実施形態に係る再生装置の改良点は、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に存在する。
以降図４１のフローチャートを参照して、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２による具体的な制御手順を説明する。【０１７１】  図４１は、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２によるプレイリスト再生手順を示すフローチャートである。この再生手順は、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１に対する制御（ステップＳ１０６）と、ＢＤ−ＲＯＭドライブ１又はローカルストレージ２０に対する制御（ステップＳ１０８）とを主に含む。本フローチャートにおいて処理対象たるＰｌａｙＩｔｅｍをＰｌａｙＩｔｅｍ＃ｘとする。本フローチャートは、カレントＰＬ情報（．ｍｐｌｓ）の読み込みを行い（ステップＳ１０１）、その後、ステップＳ１０２〜ステップＳ１１０の処理を実行するというものである。ここでステップＳ１０２〜ステップＳ１１０は、ステップＳ１０９がＹｅｓになるまで、カレントＰＬ情報を構成するそれぞれのＰＩ情報について、ステップＳ１０３〜ステップＳ１１０の処理を繰り返すというループ処理を構成している。このループ処理において処理対象となるＰｌａｙＩｔｅｍを、ＰｌａｙＩｔｅｍ＃ｘ（ＰＩ＃ｘ）とよぶ。このＰｌａｙＩｔｅｍ＃ｘは、カレントプレイリストの先頭のＰｌａｙＩｔｅｍに設定されることにより、初期化される（ステップＳ１０２）。上述したループ処理の終了要件は、このＰｌａｙＩｔｅｍ＃ｘがカレントプレイリストの最後のＰｌａｙＩｔｅｍになることであり（ステップＳ１０９）、もし最後のＰｌａｙＩｔｅｍでなければ、カレントプレイリストにおける次のＰｌａｙＩｔｅｍがＰｌａｙＩｔｅｍ＃ｘに設定される（ステップＳ１１０）。【０１７２】  ループ処理において繰り返し実行されるステップＳ１０３〜ステップＳ１１０は、ＰｌａｙＩｔｅｍ＃ｘのＣｌｉｐ＿ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅで指定されるＣｌｉｐ情報をシナリオメモリ２５に読み込み（ステップＳ１０３）、ＰｌａｙＩｔｅｍ＃ｘのＩｎ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰｍａｐを用いて、Ｉピクチャアドレスｕに変換し（ステップＳ１０４）、ＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅを、カレントＣｌｉｐ情報のＥＰ＿ｍａｐを用いて、Ｉピクチャアドレスｖに変換して（ステップＳ１０５）、これらの変換で得られたアドレスｖの次のＩピクチャを求めて、そのアドレスの１つ手前をアドレスｗに設定し（ステップＳ１０７）、そうして算出されたアドレスｗを用いて、ＩピクチャアドレスｕからアドレスｗまでのＴＳパケットの読み出しをＢＤ−ＲＯＭドライブ１又はローカルストレージ２０に命じるというものである（ステップＳ１０８）。【０１７３】  一方、Ｐｒｅｓｅｎｔａｔｉｏｎ  Ｅｎｇｉｎｅ３１に対しては、カレントＰＬＭａｒｋのｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐからＰｌａｙＩｔｅｍ＃ｘのＯｕｔ＿ｔｉｍｅまでの出力を命じる（ステップＳ１０６）。以上のステップＳ１０５〜ステップＳ１０８により、ＡＶＣｌｉｐにおいて、ＰｌａｙＩｔｅｍ＃ｘにより指示されている部分の再生がなされることになる
その後、ＰｌａｙＩｔｅｍ＃ｘがカレントプレイリストの最後のＰＩであるかの判定がなされる（ステップＳ１０９）。【０１７４】  ＰｌａｙＩｔｅｍ＃ｘがカレントプレイリストの最後のＰＩでなければ、カレントプレイリストにおける次のＰｌａｙＩｔｅｍを、ＰｌａｙＩｔｅｍ＃ｘに設定して（ステップＳ１１０）、ステップＳ１０３に戻る。以上のステップＳ１０３〜ステップＳ１１０を繰り返することにより、プレイリストを構成するＰＩは順次再生されることになる。
本フローチャートにおいて、ステップＳ１１５〜ステップＳ１１７は、ステップＳ１０３〜ステップＳ１１０が一巡される毎に実行されるステップである。ステップＳ１１５は、ＰｌａｙＩｔｅｍ＃ｘにおけるＭｉｘｉｎｇ＿Ｏｎフラグが１であるか否かの判定を行う。もしＭｉｘｉｎｇ＿Ｏｎフラグが１であるなら、サウンドミキシングを有効化するようサウンドコントローラ９に指示し（ステップＳ１１６）、もしＭｉｘｉｎｇ＿Ｏｎフラグが０であるなら、サウンドミキシングを無効化するようサウンドコントローラ９に指示する（ステップＳ１１７）。【０１７５】  以上のように本実施形態によれば、ＨＤＭＶモードにおいても、ＢＤ−Ｊモードにおいても、利用されるプレイリスト情報にＭｉｘｉｎｇ＿Ｏｎフラグを設けるので、ＨＤＭＶモードにおいて、ＩＧストリームを用いてＧＵＩが実現される場合であっても、クリック音のサウンドミキシングの有効化、無効化を規定しておくことができる。
またクリック音に限らず、ＷＷＷサイトからダウンロードした他のオーディオストリームとのサウンドミキシングを実現する場合であっても、そのサウンドミキシングの有効化／無効化をＭｉｘｉｎｇ＿Ｏｎフラグに規定しておくことができる。【０１７６】  （第３実施形態）
第１実施形態においてＪａｖａ（登録商標）仮想マシンにおけるプレイリスト再生は、ＢＤ−Ｊ  Ｏｂｊｅｃｔ内のプレイリスト管理テーブルを用いて規定することができた。ここで問題になるのがプレイリスト管理テーブルである。つまりプレイリストを再生してよいか否かは、ＢＤ−Ｊ  Ｏｂｊｅｃｔ毎のプレイリスト管理テーブルに記述されているから、あるＴｉｔｌｅでは再生可能であるが、別のＴｉｔｌｅでは再生不可能になることがある。またプレイリスト再生は可能であったとしても、著作権保護の観点から、ある種のアプリケーションからの再生を禁じたい場合がある。かかるプレイリスト再生の制限を実現するため、第３実施形態では、Ｊａｖａ（登録商標）プラットフォーム３５にパーミッションコントローラが設けられている。【０１７７】  パーミッションコントローラは、どれかのアプリケーションがプレイリスト再生を要求した場合、そのアプリケーションと相互認証を行い、要求元アプリケーションにプレイリストの再生権限があるかどうかを判定する。もしあれば、当該再生をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に要求し、なければ不許可を示す応答イベントを要求元アプリケーションに出力する。このパーミッションコントローラによる許否判定により、ある配給会社の配給にかかるプレイリストを、別の配給会社の配給にかかるアプリケーションが要求したとしても、かかる要求を不許可にすることができる。そのため、正当権限なきアプリケーションによるプレイリストの無断引用を避けることができる。許可とすべきプレイリストとアプリケーションとの組合せ、不許可とすべきプレイリストとアプリケーションとの組合せは、別途ＢＤ−ＲＯＭに記録されたＰｅｒｍｉｓｓｉｏｎファイルに規定されており、パーミッションコントローラによる判定はこれに基づく。かかるファイルの詳細は本願の主眼ではないので説明を省略する。【０１７８】  第３実施形態においてアプリケーションマネージャ３７は、現在の再生時点において再生可能なプレイリストを、アプリケーションからの要求に応じて通知する。図４２は、このアプリケーションマネージャ３７による通知処理の処理手順を示すフローチャートである。本フローチャートでは、アプリケーションの起動中において、再生可能なプレイリストの通知を求める要求（ＧｅｔＰＬ）をアプリケーションが発行したか否かの監視を行っている（ステップＳ４５）。もし発行されれば、現在の再生時点が属しているＴｉｔｌｅを構成するＢＤ−Ｊ  Ｏｂｊｅｃｔに、プレイリスト管理テーブルが存在するか否かを判定する（ステップＳ４６）。プレイリストの記述があれば、プレイリスト管理テーブルに記述されたプレイリストを再生可能なプレイリストとして要求元のアプリケーションに通知する（ステップＳ４７）。【０１７９】  プレイリストの記述がなければ、プレイリスト再生が不可能な旨を発行元アプリケーションに通知する（ステップＳ４８）。以上が第３実施形態に係るアプリケーションマネージャ３７の処理手順である。
続いてプレイリスト再生が要求された場合のアプリケーションマネージャ３７の処理について説明する。第３実施形態に係るアプリケーションマネージャ３７は、図４３のフローチャートに従って処理を行う。【０１８０】  図４３においてアプリケーションマネージャ３７は、プレイリスト再生を要求したアプリケーションが存在するか否かの判定を行っている（ステップＳ５１）。どれかのアプリケーションがプレイリスト再生を要求すれば、要求元アプリケーションにプレイリスト再生の権利が存在するか否かの認証をパーミッションコントローラに行わさせる（ステップＳ５２）。もし再生する権利があれば、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に再生開始を指示して（ステップＳ５３）、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２からのサクセス応答を待つ（ステップＳ５４）。【０１８１】  かかる再生要求があるとＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、プレイリスト情報の正当性をチェックする。かかる正当性チェックには、プレイリスト情報、Ｃｌｉｐ情報、ＡＶＣｌｉｐが存在するＢＤ−ＲＯＭ及びローカルストレージ２０において、正当なプレイリストを構成しているかというチェックやプレイリスト情報におけるｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにより指定されるＣｌｉｐ情報及びＡＶＣｌｉｐがＢＤ−ＲＯＭ及びローカルストレージ２０に現存するか否かというチェックがある。ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅにより正しいファイルが参照されていない場合、又は、ＢＤ−ＲＯＭ及びローカルストレージ２０から構成される仮想的なパッケージに矛盾があり、正しプレイリストを構成することができない場合、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２はｆａｌｓｅを示す応答を返すことになる。また要求元アプリケーションより、高い起動優先度をもつアプリケーションがそのプレイリストを再生しており、プレイリスト再生を実現するリソースにおいて競合が生じている場合最もＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、ｆａｌｓｅを示す応答を返す。【０１８２】  以上の過程を経てサクセス応答があれば、プレイリスト再生成功を示すイベントを要求元アプリケーションに出力する（ステップＳ５５）。
サクセス応答がなければ、プレイリスト再生失敗を示すイベントを要求元アプリケーションに出力する（ステップＳ５６）。一方、ステップＳ５２において要求元アプリケーションを再生する権利が要求元アプリケーションになければ、プレイリスト再生不可を示すイベントを要求元アプリケーションに出力する（ステップＳ５７）。【０１８３】  以上のように本実施形態によれば、プレイリスト再生可否が各Ｔｉｔｌｅ毎でバラバラであり、プレイリスト再生の権限をもったアプリケーションやそうでないアプリケーション等様々なアプリケーションがあったとしても、適切なプレイリスト再生を、アプリケーションからの要求に応じて実行することができる。そのため、アプリケーション実行と、プレイリスト再生とを組み合わせた、多彩なコンテンツ表現が可能になる。【０１８４】  （第４実施形態）
第１実施形態では、Ｔｉｔｌｅ開始時において、再生を開始したいプレイリストにＡｕｔｏＰｌａｙを示す再生属性を付与して、ＡｕｔｏＰｌａｙＰＬの再生を再生装置に命じていた。これに対し本実施形態では、アンバウンダリーアプリケーションをＢＤ−ＲＯＭに記録しておき、Ｔｉｔｌｅ開始時にあたって、自動的に再生を開始すべきＴｉｔｌｅをアンバウンダリーアプリケーションに選択させる改良に関する。【０１８５】  アンバウンダリーアプリケーションは、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２のような、再生装置におけるレジデントアプリケーションと対等な立場にあるアプリケーションであり、プレイリスト管理テーブルに記述されている複数プレイリスト情報の中から再生装置側のＰＳＲ設定値に合致するものを選び、通知するとの処理をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２からの要求に応じて実行する。【０１８６】  プレイリスト選択をアンバウンダリーアプリケーションに行わせる場合、かかる選択が必要なＴｉｔｌｅにあたっては、プレイリスト管理テーブルにおける再生属性を、全て無指定に設定しておく。これは、”全てが無指定”であることを合図に、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２にプレイリスト選択をタイトルアンバウンダリーアプリケーションに要求させるためである。【０１８７】  このアンバウンダリーアプリケーションによる選択は、オーサリング時に規定された選択アルゴリズムに基づく。図４４（ａ）〜（ｃ）は、アンバウンダリーアプリケーションに組み込まれた選択アルゴリズムの内容を表形式に示す図である。この表は、ＰＳＲの値が取り得る値の範囲と、ＰＳＲがそれらの値になった際、再生すべきプレイリストとを対応付けて示している。このうち図４４（ａ）は、パレンタルレベルに基づく選択アルゴリズムの内容を示す。ここでパレンタルレベルは、再生装置においてＰＳＲ（１４）に示されている。具体的にいうと、ＰＳＲ（１４）には、ユーザの年齢を示す整数値が設定されており、これを再生装置はパレンタルレベルとして解釈する。図４４（ａ）において、ＰＳＲ（１４）がとりうる値は、１４歳未満、１４歳以上１８歳未満、１８歳以上という３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきプレイリストが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、ＰＳＲの設定値が１４歳未満ならＰｌａｙＬｉｓｔ＃１が、１４以上１８歳未満ならＰｌａｙＬｉｓｔ＃２が、１８歳以上ならＰｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。【０１８８】  図４４（ｂ）は、Ｌａｎｇｕｅｇｅ  ｆｏｒ  Ａｕｄｉｏに基づく選択アルゴリズムの内容を示す。ここでＬａｎｇｕｅｇｅ  ｆｏｒ  Ａｕｄｉｏは、再生装置においてＰＳＲ（１６）に示されている。具体的にいうと、ＰＳＲ（１６）には、整数値が設定されており、これを再生装置は音声再生用の言語設定として解釈する。図４４（ｂ）において、ＰＳＲ（１６）がとりうる値は、英語を示す値、日本語を示す値、その他の値という３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきプレイリストが対応づけられている。アンバウンダリーア��リケーションがかかる選択アルゴリズムによる選択を行えば、ＰＳＲ（１６）の設定値が英語を示すならＰｌａｙＬｉｓｔ＃１が、日本語を示すならＰｌａｙＬｉｓｔ＃２が、英語、日本語以外の値ならＰｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。【０１８９】  図４４（ｃ）は、Ｐｌａｙｅｒ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｆｏｒ  Ｖｉｄｅｏに基づく選択アルゴリズムの内容を示す。ここでＰｌａｙｅｒ  Ｃｏｎｆｉｇｕｒａｔｉｏｎ  ｆｏｒ  Ｖｉｄｅｏは、再生装置においてＰＳＲ（１４）に示されている。具体的にいうと、ＰＳＲ（１４）には、整数値が設定されており、これを再生装置は映像再生用の環境設定として解釈する。図４４（ｃ）において、ＰＳＲ（１４）がとりうる値は、解像度５２５×６００  ＴＶｓｙｓｔｅｍ  ＬｅｔｔｅｒＢｏｘ  解像度５２５×６００  ＴＶｓｙｓｔｅｍ、１９２０×１０８０  ＴＶｓｙｓｔｅｍという３つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきプレイリストが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムに従って選択を行えば、ＰＳＲ（１４）の設定値が解像度５２５×６００  ＴＶｓｙｓｔｅｍ  ＬｅｔｔｅｒＢｏｘを示すものならＰｌａｙＬｉｓｔ＃１が、解像度５２５×６００を示すｔのならＰｌａｙＬｉｓｔ＃２が、ＴＶｓｙｓｔｅｍ、１９２０×１０８０  ＴＶｓｙｓｔｅｍを示すものならＰｌａｙＬｉｓｔ＃３がそれぞれ選択されることになる。図４４（ａ）〜（ｃ）に示したような選択アルゴリズムは、これらの図に示される条件分岐を、コンピュータ記述言語で記述することにより作成することができる。【０１９０】  以上が本実施形態に係る記録媒体の改良である。続いて本実施形態に係る再生装置の改良について説明する。本実施形態での改良点は。主としてアプリケーションマネージャ３７、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２にある。
アプリケーションマネージャ３７は、Ｔｉｔｌｅの分岐が生じ、プレイリスト管理テーブルを参照した際、そのプレイリスト管理テーブルにＡｕｔｏＰｌａｙＰＬが存在するか否かを判定する。ＡｕｔｏＰｌａｙＰＬが無ければ、プレイリスト管理テーブルをＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に引き渡して、このプレイリスト管理テーブルに記載されているプレイリストのうち、どれかを自動的に再生するようＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に要求する。【０１９１】  Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、プレイリスト管理テーブルの引き渡しを受ければ、アンバウンダリーアプリケーションに対し、プレイリスト選択を行うよう要求する。この要求に応じてアンバウンダリーアプリケーションから再生可能なプレイリストのリストが通知されれば、そのＰＬリストに記載されたプレイリストのうち、ＰｌａｙＩｔｅｍから引き渡されたプレイリスト管理テーブルに存在するものを判定する。アンバウンダリーアプリケーションにより選択されたプレイリストの中に、プレイリスト管理テーブルに記載されたものがあれば、それの再生を自動的に開始する。【０１９２】  図４５は、タイトルアンバウンダリーアプリケーションにＰＬ選択を行わせる過程を模式的に描いた図である。本図の左側は再生装置におけるソフトウェアのレイヤ構成を示し、本図の右側に、ＢＤ−ＲＯＭの記録内容を示す。図中の◎１，２，３，４は、ＡｕｔｏＰｌａｙがないプレイリスト管理テーブルを発見した場合の、アプリケーションマネージャ３７からの通知（◎１）、Ｐｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２による再生可能プレイリストの間合せ（◎２）、タイトルアンバウンダリーアプリケーションによるＰＳＲ設定値取得（◎３）、タイトルアンバウンダリーアプリケーションからＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２への再生可能なプレイリストの通知（◎４）を模式的に描いている。【０１９３】  尚、図４５においてタイトルアンバウンダリーアプリケーションは、ＢＤ−ＲＯＭ上に記述していたが、これはタイトルアンバウンダリーアプリケーションを、わかり易く記述するための配慮に過ぎない。タイトルアンバウンダリーアプリケーションは、Ｊａｖａ（登録商標）アプリケーションであるので、Ｊａｖａ（登録商標）仮想マシン３６内のワークメモリ５４においてインスタンスとしてスレッド５５により実行されるというのが、現実的な記述になる。【０１９４】  以上のように本実施形態によれば、Ｔｉｔｌｅのバウンダリで生存しているようなアプリケーションに、上述したような判定を行わせるので、再生装置側のＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、ＢＤ−ＲＯＭにおける複数プレイリストのうち、再生装置側の状態設定に応じたものはどれであるかを、Ｔｉｔｌｅ開始時の早い段階で知得することができる。再生属性＝ＡｕｔｏＰｌａｙのアプリケーションを決めておかなくても、Ｔｉｔｌｅ開始時に再生を開始すべきプレイリストを決定することができるので、ラングエージクレジットやパレンタルロックといった再生制御をＢＤ−Ｊモードにおいても実現することができる。【０１９５】  尚、本��施形態における選択アルゴリズムは、ＰＳＲがとり得る値をプレイリストに対応づけたが、再生装置におけるＰＳＲの設定値が、想定外の値であった場合に、再生装置に再生させるプレイリストを予め規定しておいてもよい。
（第５実施形態）
本実施形態は、タイトル切替時において、サウンドミキシングをあらかじめ無効化しておく改良に関する。タイトル切替時には、ファイルｓｏｕｎｄ．ｂｄｍｖの読み出しが発生することがあり得るので、かかる切替時には、デフォルトとして、サウンドミキシングをあらかじめ無効化しておく。こうすることにより、ファイルｓｏｕｎｄ．ｂｄｍｖがプリロードバッファ７ｂ内に存在しないことによる、クリックオン再生の途切れを防止することができる。
（第６実施形態）
本実施形態は、ｘｌｅｔプログラムがＪＭＦ（Ｊａｖａ（登録商標）Ｍｅｄｉａ  ＦｒａｍｅＷｏｒｋ）方式のインターフェイスを利用して、ｍｐｌｓファイルに対するインスタンス（ＪＭＦプレーヤインスタンス）を生成することにより、プレイリスト再生を再生装置に命じる場合の実施形態である。【０１９６】  ｍｐｌｓファイルとは、プレイリスト情報の実体面を規定するファイルであるので、第２実施形態に示したように、このプレイリスト情報に、Ｍｉｘｉｎｇ＿Ｏｎフラグを設けておく。Ｍｉｘｉｎｇ＿Ｏｎフラグを、プレイリストに設けた場合、Ｊａｖａ（登録商標）アプリケーションがプレイリスト情報の再生をＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２に要求することにより、指定されたプレイリスト情報内にあるＭｉｘｉｎｇ＿Ｏｎフラグに応じて、サウンドミキシングを有効化、あるいは、無効化することができる。【０１９７】  （第７実施形態）
第１実施形態では、サウンドミキシングの有効化あるいは無効化等をサウンドコントローラ９に指示するための機能をアプリケーションマネージャ３７にもたせたが、本実施形態は、かかる機能をＪａｖａ（登録商標）アプリケーションにもたせる実施形態である。
そこで本実施形態では、かかる機能の呼出をＪａｖａ（登録商標）アプリケーションから受け付けるためのＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｉｎｔｅｒｆａｃｅ）をＪａｖａ（登録商標）プラットフォーム３５にもたせる。そうして、サウンドミキシングの有効化あるいは無効化を要求する機能呼出をＪａｖａ（登録商標）アプリケーションが実行した場合、サウンドミキシングの有効化あるいは無効化等をサウンドコントローラ９に指示する。【０１９８】  尚、かかる有効化、無効化を指示する機能を、モジュールマネージャ３４にもたせてもよい。
（第８実施形態）
再生装置にＰＣＭでのサラウンド音声の伝送が可能な出力形態が存在し、その出力形態がユーザにより選択されている場合、ミキシング音声の再エンコードは不要であるため、そのまま出力することが可能である場合がある。かかる出力形態には、ＨＤＭＩでの出力形態、アナログでの出力形態がある。【０１９９】  再生装置にＰＣＭでのサラウンド音声の伝送が可能な出力形態が存在するのか、そして、その出力形態が選択されているのかを再生装置が判断するために、どのような音声出力形態をユーザーが望んでいるか、もしくは再生装置のＩ／Ｆの接続形態からどのような音声出力が可能であるかを、本実施形態ではＰＳＲセット２３に記述しておく。
以降、本実施形態にかかるＰＳＲの内容について説明する。本実施形態では、ＰＳＲセット２３のうち、２１番目のＰＳＲ（ＰＳＲ２１），２２番目のＰＳＲ（ＰＳＲ２２）に以下のような改良が加えられている。【０２００】  ＰＳＲ２１は、ミキシング（例えば、２ｃｈの追加音声のミキシング）が可能か否かを示す“Ａｕｄｉｏ  Ｍｉｘｉｎｇ  Ｃａｐａｂｉｌｉｔｙ”、ミキシング可能なチャンネル数（もしくは、ミキシング可能な個々のチャンネル名）を示す“Ａｕｄｉｏ  Ｍｉｘｉｎｇ  Ｃｈａｎｎｅｌ  Ｎｕｍｂｅｒ”、現在ユーザーが選択している音声出力形態に対する最大の出力ｃｈ数を示す“Ａｕｄｉｏ  Ｏｕｔｐｕｔ  Ｃｈａｎｎｅｌ  Ｎｕｍｂｅｒ”を示す。【０２０１】  例えば、音声出力形態としてＳ／ＰＤＩＦを選択している場合、サラウンド音声は帯域上の問題から圧縮符号化しないと出力できない。そのためミキシング後に再エンコードする必要があるが、高ビットレートに対応したデジタルＩ／ＦであるＨＤＭＩ等を選択している場合、非圧縮（ＬＰＣＭ）の形式でもそのままサラウンド音声のまま送ることが可能である。したがって、Ｓ／ＰＤＩＦ接続時には、ミキシング後にエンコードするか否かでＡｕｄｉｏ  Ｏｕｔｐｕｔ  Ｃｈａｎｎｅｌ  Ｎｕｍｂｅｒの値が変わる。【０２０２】  ＰＳＲ２２には、再生装置の一属性として、ビデオの出力を行わない再生装置であることを示すＡｕｄｉｏ  Ｏｎｌｙ  Ｐｌａｙｅｒ、所定のプロファイルに準じた再生装置であることを示すＰｒｏｆｉｌｅ１  Ｐｌａｙｅｒ、Ｐｒｏｆｉｌｅ２  Ｐｌａｙｅｒがある。例えば、Ｐｒｏｆｉｌｅ１には対応しながらも、Ｐｒｏｆｉｌｅ２に対応しない再生装置はＰｒｏｆｉｌｅ１  Ｐｌａｙｅｒを有効に設定し、Ｐｒｏｆｉｌｅ２  Ｐｌａｙｅｒを無効に設定する。これらの値は、日本語Ｌから参照可能なため再生装置のプロファイルに応じた動的な再生経路選択や、メニューの有無などが選択できる。特に、Ａｕｄｉｏ  Ｏｎｌｙ  Ｐｌａｙｅｒが有効になっていた場合には、日本語ＬでＣＤ再生装置と同等のユーザー操作性を与えるようにプレイリストを再生するようタイトルを作成することが可能であり、この場合、ユーザーはＢＤ−ＲＯＭを音楽ＣＤと全く変わりなく操作できる。勿論、同一のディスクでありながら、Ａｕｄｉｏ  Ｏｎｌｙ  Ｐｌａｙｅｒが無効になっている再生装置に対しては、今まで通り映像出力を仮定してＧＵＩベースのメニューなどを表示し、インタラクティブな再生が可能である。このような想定はＢＤを採用したカーオーディオシステムなどで有効と考えられる。【０２０３】  以上のようなＰＳＲが追加されたため、本実施形態に係るＰｌａｙｂａｃｋ  Ｃｏｎｔｒｏｌ  Ｅｎｇｉｎｅ３２は、ＰｌａｙＩｔｅｍ情報又はプレイリスト情報に対応するＭｉｘｉｎｇ＿Ｏｎフラグが、“ミキシング＝有効”を示している場合、ＰＳＲ２１からミキシング可能か否かを判定する。そしてＰＳＲ２１がミキシング可能な場合に、ＰＳＲ２１からミキシング可能なｃｈ数を取得し、そのｃｈ数以下のｃｈ数を持つオーディオストリーム又はサウンドデータを、選択的にサウンドミキサ８、サウンドコントローラ９に出力して、ミキシングを行わせる。【０２０４】  以上のように本実施形���によれば、どのような音声出力形態をユーザーが望んでいるか、もしくは再生装置のＩ／Ｆの接続形態からどのような音声出力が可能であるかを、ＰＳＲに記述しておくので、ミキシング出力の可否を、更に詳細に規定しておくことができる。
（備考）
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記（Ａ）（Ｂ）（Ｃ）（Ｄ）・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。【０２０５】  （Ａ）各実施形態に係るＢＤ−ＲＯＭは、以下の工程を順次実行することにより、作ることができる。
先ず初めに、ＢＤ−ＲＯＭをどのような筋書きで再生させるかを決めるかを企画して（企画工程）、動画収録、音声収録等の素材作成を行い（素材作成工程）、企画工程において作成された筋書きから、ボリューム構成情報を作成する（シナリオ作成工程）。【０２０６】  ボリューム構成情報とは、抽象的な記述にて、光ディスクの応用層のフォーマットを示す情報である。
その後、ビデオ素材、オーディオ素材、字幕素材、メニュー素材のそれぞれをエンコードすることにより、エレメンタリストリームを得る（素材エンコード工程）。その後、複数のエレメンタリストリームの多重化を行う（多重化工程）。【０２０７】  こうして多重化がなされれば、多重化されたストリーム及びボリューム構成情報を、ＢＤ−ＲＯＭの応用層フォーマットに適合させる作業を行い、ＢＤ−ＲＯＭのボリューム領域に記録すべきデータの全体像（一般にボリュームデータという）を得る（フォーマッティング工程）。
ここで本発明に係る記録媒体の応用層フォーマットは、プログラミング言語で記述されたクラス構造体のインスタンスであり、ＢＤ−ＲＯＭ規格、ＢＤ−Ｊ規格に規定された構文に基づいて、クラス構造体のインスタンスを記述することで、ＢＤ−Ｊ  ｏｂｊｅｃｔ，Ｃｌｉｐ情報，ＰｌａｙＬｉｓｔ情報等を作成することができる。この場合、テーブル形式のデータは、プログラミング言語のｆｏｒ文を用いて定義することができ、その他、特定の条件下のみ、必要になるようなデータは、ｉｆ文を用いて定義することができる。【０２０８】  こうした適合処理の後、ボリュームデータが得られれば、ボリュームデータを再生してみてシナリオ作成工程の結果が正しいか否かの確認を行う（エミュレーション工程）。このエミュレーション工程では、ＢＤ−ＲＯＭプレーヤモデルのバッファ状態のシミュレートを行うのが望ましい。
最後にプレス工程を行う。【０２０９】  このプレス工程では、ボリュームイメージを物理データ列に変換して、この物理データ列を用いて原盤カッティングを行い、ディスク原盤を作成する。さらにプレス装置によって作成された原盤から、ＢＤ−ＲＯＭを製造する。この製造は主に、基板成形、反射膜成膜、保護膜コーティング、張り合わせ、レーベルの印刷といった諸工程からなる。
以上の工程を経て、各実施形態に示した記録媒体（ＢＤ−ＲＯＭ）を作ることができる。【０２１０】  （Ｂ）各実施形態に示したフローチャートや、機能的な構成要素による情報処理は、ハードウェア資源を用いて具体的に実現されていることから、自然法則を利用した技術的思想の創作といえ、“プログラムの発明”としての成立要件を満たす。
・本発明に係るプログラムの生産形態
本発明に係るプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。【０２１１】  具体的には、フローチャートにおける繰り返し処理は、上記構文に規定されたｆｏｒ文等を用いて記述する。判定処理は、上記構文に規定されたｉｆ文，ｓｗｉｔｈ文等を用いて記述する。デコーダに対する再生制御や、ドライブ装置のアクセス制御等、ハードウェアについての制御は、ハードウェアの製造元から供給される外部関数を呼び出すことにより、記述する。【０２１２】  記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。【０２１３】  ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような１つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、ＪＡＶＡ（登録商標）バイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、１つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているＲＩＳＣプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。【０２１４】  オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。
（Ｃ）本発明に係るプログラムは、以下のようにして使用することができる。【０２１５】  （ｉ）組込プログラムとしての使用
本発明に係るプログラムを組込プログラムとして使用する場合、プログラムにあたるロードモジュールを、基本入出力プログラム（ＢＩＯＳ）や、様々なミドルウェア（オペレーションシステム）と共に、命令ＲＯＭに書き込む。こうした命令ＲＯＭを、制御部に組み込み、ＣＰＵに実行させることにより、本発明に係るプログラムを、再生装置の制御プログラムとして使用することができる。【０２１６】  （ｉｉ）アプリケーションとしての使用
再生装置が、ハードディスク内蔵モデルである場合は、基本入出力プログラム（ＢＩＯＳ）が命令ＲＯＭに組み込まれており、様々なミドルウェア（オペレーションシステム）が、ハードディスクにプレインストールされている。また、ハードディスクから、システムを起動するためのブートＲＯＭが、再生装置に設けられている。【０２１７】  この場合、ロードモジュールのみを、過搬型の記録媒体やネットワークを通じて、再生装置に供給し、１つのアプリケーションとしてハードディスクにインストールする。そうすると、再生装置は、ブートＲＯＭによるブートストラップを行い、オペレーションシステムを起動した上で、１つのアプリケーションとして、当該アプリケーションをＣＰＵに実行させ、本発明に係るプログラムを使用する。【０２１８】  ハードディスクモデルの再生装置では、本発明のプログラムを１つのアプリケーションとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネットワークを通じて供給することができる。
（Ｄ）本発明に係るシステムＬＳＩの生産・使用行為
システムＬＳＩとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも１つのＬＳＩのような外形構造を複数個のベアチップに持たせたものも、システムＬＳＩに含まれるにのようなシステムＬＳＩは、マルチチップモジュールと呼ばれる。）。【０２１９】  ここでパッケージの種別に着目するとシステムＬＳＩには、ＱＦＰ（クッド  フラッド  アレイ）、ＰＧＡ（ピン  グリッド  アレイ）という種別がある。ＱＦＰは、パッケージの四側面にピンが取り付けられたシステムＬＳＩである。ＰＧＡは、底面全体に、多くのピンが取り付けられたシステムＬＳＩである。
これらのピンは、ドライブ装置との入出力インターフェイス、リモコン装置との入力インターフェイス、テレビとのインターフェイス、その他、ＩＥＥＥ１３９４インターフェイスやＰＣＩバスとのインターフェイスとしての役割を担っている。システムＬＳＩにおけるピンには、こうしたインターフェイスの役割が存在するので、システムＬＳＩにおけるこれらのピンに、ドライブ装置等や再生装置の各種回路を接続することにより、システムＬＳＩは、再生装置の中核としての役割を果たす。【０２２０】  システムＬＳＩにパッケージングされるベアチップとは、各実施形態において内部構成図として示した各構成要素の機能を具現する命令ＲＯＭやＣＰＵ、デコーダＬＳＩ等である。
先に“組込プログラムとしての使用”で述べたように、命令ＲＯＭには、プログラムにあたるロードモジュールや、基本入出力プログラム（ＢＩＯＳ）、様々なミドルウェア（オペレーションシステム）が書き込まれる。本実施形態において、特に創作したのは、このプログラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュールを格納した命令ＲＯＭを、ベアチップとしてパッケージングすることにより、本発明に係るシステムＬＳＩは生産することができる。【０２２１】  具体的な実装としては、ＳｏＣ実装やＳｉＰ実装が望ましい。ＳｏＣ（Ｓｙｓｔｅｍ  ｏｎ  ｃｈｉｐ）実装とは、１チップ上に複数の回路を焼き付ける技術である。ＳｉＰ（Ｓｙｓｔｅｍ  ｉｎ  Ｐａｃｋａｇｅ）実装とは、複数チップを樹脂等で１パッケージにする技術である。以上の過程を経て、本発明に係るシステムＬＳＩは、各実施形態に示した再生装置の内部構成図を基に作ることができる。
尚、上述のようにして生成される集積回路は、集積度の違いにより、ＩＣ、ＬＳＩ、スーパーＬＳＩ、ウルトラＬＳＩと呼称されることもある。【０２２２】  さらに、各再生装置の構成要素の一部又は全てを１つのチップとして構成してもよい。集積回路化は、上述したＳｏＣ実装，ＳｉＰ実装に限るものではなく、専用回路又は汎用プロセスで実現してもよい。ＬＳＩ製造後に、プログラムすることが可能なＦＰＧＡ（Ｆｉｅｌｄ  Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）や、ＬＳＩ内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用することが考えられる。更には、半導体技術の進歩又は派生する技術によりＬＳＩに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バイオ技術の適応などが可能性としてありうる。【０２２３】  （Ｅ）全ての実施形態では、本発明に係る光ディスクをＢＤ−ＲＯＭとして実施したが、どのような記録媒体であってもよい。例えば、ＤＶＤ−ＲＯＭ，ＤＶＤ−ＲＡＭ，ＤＶＤ−ＲＷ，ＤＶＤ−Ｒ，ＤＶＤ＋ＲＷ，ＤＶＤ＋Ｒ，ＣＤ−Ｒ，ＣＤ−ＲＷ等の光ディスク、ＰＤ，ＭＯ等の光磁気ディスクであってもよい。
（Ｆ）各実施形態におけるビデオストリームは、ＢＤ−ＲＯＭ規格のＡＶＣｌｉｐであったが、ＤＶＤ−Ｖｉｄｅｏ規格、ＤＶＤ−Ｖｉｄｅｏ  Ｒｅｃｏｒｄｉｎｇ規格のＶＯＢ（ＶｉｄｅｏＯｂｊｅｃｔ）であってもよい。ＶＯＢは、ビデオストリーム、オーディオストリームを多重化することにより得られたＩＳＯ／ＩＥＣ１３８１８−１規格準拠のプログラムストリームである。またＡＶＣｌｉｐにおけるビデオストリームは、ＭＰＥＧ４やＷＭＶ方式であってもよい。更にオーディオストリームは、Ｌｉｎｅａｒ−ＰＣＭ方式、Ｄｏｌｂｙ−ＡＣ３方式、ＭＰ３方式、ＭＰＥＧ−ＡＡＣ方式、ｄｔｓ方式であってもよい。【０２２４】  （Ｇ）各実施形態ではＭＰＥＧ４−ＡＶＣ（Ｈ．２６４やＪＶＴとも呼ばれる）をもとに説明したが、ＭＰＥＧ２ビデオストリームであってもよく、また、その他の形式（ＶＣ−１等）の画像の場合でも単独でデコード可能な画像であれば、容易に応用可能である。
【産業上の利用可能性】
【０２２５】  本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが可能なので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上利用可能性を有する。
【図１】
2006059654.tif 000002
【図２】
2006059654.tif 000003
【図３】
2006059654.tif 000004
【図４】
2006059654.tif 000005
【図５】
2006059654.tif 000006
【図６】
2006059654.tif 000007
【図７】
2006059654.tif 000008
【図８】
2006059654.tif 000009
【図９】
2006059654.tif 000010
【図１０】
2006059654.tif 000011
【図１１】
2006059654.tif 000012
【図１２】
2006059654.tif 000013
【図１３】
2006059654.tif 000014
【図１４】
2006059654.tif 000015
【図１５】
2006059654.tif 000016
【図１６】
2006059654.tif 000017
【図１７】
2006059654.tif 000018
【図１８】
2006059654.tif 000019
【図１９】
2006059654.tif 000020
【図２０】
2006059654.tif 000021
【図２１】
2006059654.tif 000022
【図２２】
2006059654.tif 000023
【図２３】
2006059654.tif 000024
【図２４】
2006059654.tif 000025
【図２５】
2006059654.tif 000026
【図２６】
2006059654.tif 000027
【図２７】
2006059654.tif 000028
【図２８】
2006059654.tif 000029
【図２９】
2006059654.tif 000030
【図３０】
2006059654.tif 000031
【図３１】
2006059654.tif 000032
【図３２】
2006059654.tif 000033
【図３３】
2006059654.tif 000034
【図３４】
2006059654.tif 000035
【図３５】
2006059654.tif 000036
【図３６】
2006059654.tif 000037
【図３７】
2006059654.tif 000038
【図３８】
2006059654.tif 000039
【図３９】
2006059654.tif 000040
【図４０】
2006059654.tif 000041
【図４１】
2006059654.tif 000042
【図４２】
2006059654.tif 000043
【図４３】
2006059654.tif 000044
【図４４】
2006059654.tif 000045
【図４５】
2006059654.tif 000046
【手続補正書】
【提出日】平成18年9月26日(2006.9.26)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
多重化されたビデオストリーム及びオーディオストリームを含むデジタルストリームと、アプリケーションと、クリック音とが記録された記録媒体であって、
前記記録媒体には管理情報と、これに対応するフラグとが更に記録されており、
前記管理情報は、
アプリケーションの実行中において、同時に開始すべきデジタルストリームの再生制御を示す情報であり、
前記フラグは、
前記実行されるアプリケーションに対するユーザ操作に応じたクリック音と、前記再生制御時におけるデジタルストリームの音声出力とをミキシングするか否かを示す  ことを特徴とする記録媒体。
【請求項２】
前記管理情報は、エントリー情報を含み、
前記エントリー情報は、
デジタルストリームの再生制御時において、音声出力が可能となるオーディオストリームを示し、
前記フラグは、
音声出力可能とされているオーディオストリームが、マルチチャネル属性をもっている場合、ミキシング不可を示すよう設定され、
音声出力可能とされているオーディオストリームが、マルチチャネル属性をもっていない場合、ミキシング可能を示すよう設定される
ことを特徴とする請求項１記載の記録媒体。
【請求項３】
前記管理情報は、ビデオストリーム上の再生開始時刻及び再生終了時刻の組みを示すことにより、再生経路を規定する再生経路情報と、
前記再生経路情報の属性を示す属性情報とを含み、
前記管理情報により示される再生制御とは、前記再生経路情報に示される再生経路に従って、デジタルストリームを再生すること及び前記再生経路情報の属性を示す属性情報を用いて前記再生経路情報に示された再生経路に従ったデジタルストリームの再生の開始を制御することである、請求項１記載の記録媒体。
【請求項４】
前記属性情報とは、再生経路情報に示される再生経路を用いた再生を自動的に開始する旨を示す属性であり、 
前記デジタルストリーム再生の同時実行は、 
再生経路情報に自動再生を示す属性情報が付加されている場合になされる、ことを特徴とする請求項３記載の記録媒体。 
【請求項５】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、 
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数再生経路情報のうち、何れか1つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性である
ことを特徴とする請求項１記載の記録媒体。 
【請求項６】
前記フラグは、
クリック音の再生を意図した命令又はコードが、前記アプリケーションを構成するプログラムの中に存在する場合、ミキシング不可を示すよう設定され、
クリック音の再生を意図した命令又はコードが、前記アプリケーションを構成するプログラムの中に存在しない場合、ミキシング可能を示すよう設定される
ことを特徴とする請求項１記載の記録媒体。
【請求項７】
アプリケーションを実行すると共に、デジタルストリームを再生する再生装置であって、
管理情報と、これに対応するフラグとを記録媒体から読み出す読出手段と、
記録媒体に記録されたアプリケーションを実行するプラットフォーム部と、 
アプリケーションの実行中に、管理情報に示された再生制御を実行することにより、同時にデジタルストリームを再生して、映像出力及び音声出力を行う再生制御エンジン部と、
管理情報に対応したフラグがオンである場合、前記実行中のアプリケーションに対するユーザ操作に応じたクリック音と、音声出力とのミキシングを実行するが、管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシング部と
を備えることを特徴とする再生装置。 
【請求項８】
前記管理情報は、エントリー情報を含み、
前記エントリー情報は、
デジタルストリームの再生制御時において、音声出力が可能となるオーディオストリームを示し、
前記フラグは、
音声出力可能とされているオーディオストリームが、マルチチャネル属性をもっている場合、オンを示すよう設定され、
音声出力可能とされているオーディオストリームが、マルチチャネル属性をもっていない場合、オフを示すよう設定され、
前記再生制御エンジンは、
デジタルストリームに多重化されているオーディオストリームのうち、エントリー情報において音声出力可能と示されているもののみをデコードして、音声出力を行い、
前記サウンドミキシングは、フラグに基づき、音声出力とのミキシングを実行する
ことを特徴とする請求項７記載の再生装置。
【請求項９】
前記管理情報は、ビデオストリーム上の再生開始時刻及び再生終了時刻の組みを示すことにより、再生経路を規定する再生経路情報と、
前記再生経路情報の属性を示す属性情報とを含み、
前記プラットフォーム部は前記属性情報に基づき前記再生制御エンジンを制御し、
前記再生制御エンジンに基づく再生制御とは、所定の再生属性が付加された再生経路情報に示される再生経路に従って、デジタルストリームを再生することである、請求項７記載の再生装置。
【請求項１０】
所定の再生属性とは、再生経路情報に示される再生経路を用いた再生を自動的に開始する旨を示す属性であり、 
前記プラットフォーム部が前記再生制御エンジンに対しデジタルストリーム再生の同時実行を指示するのは、 
再生経路情報に自動再生を示す属性情報が付加されている場合である、ことを特徴とする請求項９記載の再生装置。 
【請求項１１】
前記記録媒体には更に、生存区間がないタイトルアンバウンダリーアプリケーションが記録されており、 
タイトルアンバウンダリーアプリケーションは、記録媒体に記録されている複数再生経路情報のうち、何れか1つを、再生装置における状態レジスタの格納値に応じて選択する処理を行い、
前記所定の再生属性とは、タイトルアンバウンダリーアプリケーションの選択を待って再生される旨を示す再生属性である
ことを特徴とする請求項９記載の再生装置。 
【請求項１２】
前記プラットフォーム部は、 
何れかの再生経路情報を指定した再生がアプリケーションから命じられた場合、当該アプリケーションの正当性を認証するパーミッションコントローラを備え、 
前記再生制御エンジン部が再生経路情報に基づく再生を行うのは、パーミッションコントローラが正当性ありと認証した場合である 
ことを特徴とする請求項９記載の再生装置。 
【請求項１３】
プラットフォーム部は、再生経路情報に基づく再生を行うアプリケーションが存在する場合、当該アプリケーションが再生可能な再生経路情報を判定して、当該アプリケーションに通知し、 
前記再生制御エンジン部による再生は、通知された再生経路情報に基づく 
ことを特徴とする請求項９記載の再生装置。 
【請求項１４】
前記再生装置は、 
アプリケーションの実行画像を格納する第１プレーンと、
映像として出力されるべき再生画像を格納する第２プレーンと、
アプリケーションの実行画像を親画面に配置し、再生制御時における映像出力を子画面に配置した合成画像を出力する合成部とを含む
ことを特徴とする請求項７記載の再生装置。 
【請求項１５】
前記プラットフォーム部は更に、 
アプリケーションが起動されるまでのスタートアップディレイにおいて、デジタルストリームの再生画像を主画像とするよう、第１プレーンの格納内容をスケーリングする制御を行い、
前記合成画像を、アプリケーションが正常に起動した後に出力する
ことを特徴とする請求項１４記載の再生装置。 
【請求項１６】
アプリケーションの実行を管理すると共に、デジタルストリームの再生をコンピュータに実行させる管理プログラムであって、
管理情報と、これに対応するフラグとを記録媒体から読み出す読出ステップと、
記録媒体に記録されたアプリケーションを実行するステップと、 
アプリケーションの実行中に、管理情報に示された再生制御を実行することにより、同時にデジタルストリームを再生して、映像出力及び音声出力を行う再生制御ステップと、
管理情報に対応したフラグがオンである場合、アプリケーションに対するユーザ操作に応じたクリック音と、音声出力とのミキシングを実行するか、管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシングステップと
をコンピュータに実行させることを特徴とする管理プログラム。
【請求項１７】
アプリケーションを実行すると共に、デジタルストリームを再生する再生方法であって、
管理情報と、これに対応するフラグとを記録媒体から読み出す読出ステップと、
記録媒体に記録されたアプリケーションを実行するステップと、 
アプリケーションの実行中に、管理情報に示された再生制御を実行することにより、同時にデジタルストリームを再生して、映像出力及び音声出力を行う再生制御ステップと、
管理情報に対応したフラグがオンである場合、前記実行中のアプリケーションに対するユーザ操作に応じたクリック音と、音声出力とのミキシングを実行するか、管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシングステップと
を含むことを特徴とする再生方法。
【請求項１８】
アプリケーションを実行すると共に、デジタルストリームを再生する再生装置に組み込まれる集積回路であって、
再生装置の制御により記録媒体から読み出されたアプリケーションを実行するプラットフォーム部と、 
アプリケーションの実行中に、記録媒体から読み出された管理情報に示された再生制御を実行することにより、同時にデジタルストリームを再生して、映像出力及び音声出力を行う再生制御エンジン部と、
管理情報に対応したフラグがオンである場合、前記実行中のアプリケーションに対するユーザ操作に応じたクリック音と、音声出力とのミキシングを実行するか、管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシング部と
を備えることを特徴とする集積回路。 
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
クリック音再生の技術分野に属する発明である。
【背景技術】
【０００２】
クリック音再生とは、映画作品の再生中において表示されたGUIに対し、ユーザが操作を行った場合、その操作に呼応して、映画作品中の再生音声に、クリック音をサウンドミキシングして出力する技術である。
例えば映画作品の再生中に表示されるGUIが、「ゲームの開始」といった機能の実行指示を受け付けるものであり、この実行指示に応じて、「これからゲームを始めるよ」との音声アナウンスをクリック音として、映画本編の音声にサウンドミキシングして出力する場合を考える。この音声アナウンスが、映画作品に登場するキャラクターの声によるものなら、幼年者たるユーザは、この音声アナウンスにより、映画作品に登場するキャラクターから語りかけられているような印象を受ける。以上のクリック音再生の導入により、幼年者が楽しく遊べるようなGUIを映画作品に導入することができる。
【０００３】
ここで1つの音声出力に、別の音声出力をミキシングして出力する技術には、以下の特許文献１に記載されているものがある。
【特許文献１】特開平７-３２０４１１号公報
【発明の開示】
【発明が解決しようとする課題】
【０００４】
ところでクリック音のサウンドミキシングを行うには、デジタル化されたオーディオストリームを一旦、LPCM状態まで展開せねばならない。ここでサウンドミキシングの対象となる本編側のオーディオストリームが5.1チャネルといったマルチチャネル属性をもっている場合、展開されたLPCM状態でのデータ量は、多大なものとなる。従って、マルチチャネル属性をもっているオーディオストリームに、クリック音をサウンドミキシングして、デジタル音声出力を行う場合、帯域上の制限から、ある種類のデジタルインターフェイスでは、デジタル音声出力が不可能になってしまうことがある。近年の映画は、音響面を重視していることが多く、またユーザも、アンプやサラウンドスピーカ等、巨額な私費を投じて、プライベートな音響システムを構築しているケースが多いので、クリック音をサウンドミキシングしようとした途端、映画本編のデジタル音声出力が不可能になるというのでは、映画に対するマイナスイメージが図りしれない。
【０００５】
クリック音の導入により“マルチチャネルの音声出力が途切れるのではないか”という不安の呪縛がある限り、クリック音という機能自体が、映画制作に使用されないとのケースが多発する。かかる呪縛から、映画制作スタジオを解放するには、再生装置に再エンコードを行わせるという考えを、あらゆる再生装置に義務付ければよい。つまり再生装置内にエンコーダを具備しておき、5.1チャネルといったマルチチャネル属性をもっているオーディオストリームをLPCM状態に展開して、クリック音をミキシングした後、これを再エンコードした上で、デジタル出力を行えばよい。具体的にいうと、ミキシングした音声のデジタル音声出力をS/PDIF(Sony/PhilipsDigital InterConnect Format,ISO60958-3規格)のようなデジタルインターフェースを介して、実行する場合、上述した再エンコードを行い、ドルビーデジタルやDTSへと変換することが必要になる。しかしかかる再エンコードには、エンコーダの具備が必須となるので、とてもではないが、BD-ROM再生装置の標準モデルとして採用されるものではない。
【０００６】
本発明の目的は、音声出力に対する弊害をもたらすことなく、クリック音のサウンドミキシング出力を実現することができる記録媒体を提供することである。  
【課題を解決するための手段】
【０００７】
上記目的は、多重化されたビデオストリーム及びオーディオストリームを含むデジタルストリームと、アプリケーションと、クリック音とが記録された記録媒体であって、前記記録媒体には管理情報と、これに対応するフラグとが更に記録されており、前記管理情報は、アプリケーションの実行中において、同時に開始すべきデジタルストリームの再生制御を示す情報であり、前記フラグは、前記実行されるアプリケーションに対するユーザ操作に応じたクリック音と、前記再生制御時におけるデジタルストリームの音声出力とをミキシングするか否かを示すことを特徴とする記録媒体により達成される。
【発明の効果】
【０００８】
本発明は上述した構成を有しているので、マルチチャネルでの音声出力を意図するような再生制御の実行時にはサウンドミキシングを無効化しておき、マルチチャネルでの音声出力を意図しないような再生制御の実行時にはサウンドミキシングを有効化しておくことができる。
これにより、映画の制作スタジオは、マルチチャネルでの再生を意図している場合は、クリック音を禁止し、代わりにクリック音での再生を意図している場合は、代わりにマルチチャネルによる音声出力を禁止するという調整が可能になる。
【０００９】
かかる調整の上で、クリック音を映画制作に導入すれば“マルチチャネルの音声出力が途切れるのではないか”という不安の呪縛から、制作スタジオを解放することができる。これにより映画作品作成にあたってのクリック音の導入に弾みをつけることができる。
【発明を実施するための最良の形態】
【００１０】
(第１実施形態)
以降、本発明に係る記録媒体の実施形態について説明する。先ず始めに、本発明に係る記録媒体の実施行為のうち、使用行為についての形態を説明する。図１は、本発明に係る記録媒体の、使用行為についての形態を示す図である。図１において、本発明に係る記録媒体はBD-ROM１００であり、BD-ROM１００は、再生装置２００、リモコン３００、テレビ４００、サラウンドスピーカに接続されたアンプ５００により形成されるホームシアターシステムに、著作物を供給するという用途に供される。
【００１１】
本システムにおいて再生装置２００は、BD-ROM１００に記録されている各種データを再生して、映像出力及び音声出力を行う。この再生装置２００による映像出力は、HDMI(HighDefinition Multimedia Interface)、その他アナログインターフェイスを介して、テレビ４００に出力される。また、再生装置２００による音声出力は、S/PDIF又はHDMI、その他アナログインターフェイスを介して、テレビ４００又はアンプ５００に出力される。
【００１２】
以上が本発明に係る記録媒体の使用形態についての説明である。
続いて本発明に係る記録媒体の生産行為について説明する。本発明に係る記録媒体は、BD-ROMのファイルシステム上における改良で実現することができる。図２は、BD-ROMにおけるファイル・ディレクトリ構成を示す図である。本図においてBD-ROMには、Rootディレクトリの下に、BDMVディレクトリがある。
【００１３】
BDMVディレクトリには、拡張子bdmvが付与されたファイル(index.bdmv,MovieObject.bdmv)がある。そしてこのBDMVディレクトリの配下には、更にPLAYLISTディレクトリ、CLIPINFディレクトリ、STREAMディレクトリ、BDBJディレクトリ、BDJAディレクトリ、AUXDATAディレクトリと呼ばれる6つのサブディレクトリが存在する。
PLAYLISTディレクトリには、拡張子mplsが付与されたファイル(00001.mpls,00002.mpls,00003mpls)がある。
【００１４】
CLIPINFディレクトリには、拡張子clpiが付与されたファイル(00001.clpi,00002.clpi,00003.clpi)がある。
STREAMディレクトリには、拡張子m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts)がある。
BDBJディレクトリには、拡張子BOBJが付与されたファイル(00001.bobj,00002.bobj,00003.bobj)が存在する。
【００１５】
BDJAディレクトリには、拡張子jarが付与されたファイル(00001.jar,00002.jar,00003.jar)がある。
AUXDATAディレクトリには、ファイルsound.bdmvが格納される。
以上のディレクトリ構造により、互いに異なる種別の複数ファイルが、BD-ROM上に配置されていることがわかる。
【００１６】
＜BD-ROMの構成その１.AVClip＞
先ず初めに、拡張子.m2tsが付与されたファイルについて説明する。図３は、拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。拡張子.m2tsが付与されたファイル(00001.m2ts,00002.m2ts,00003.m2ts・・・・・)は、AVClipを格納している。AVClipはMPEG2-TransportStream形式のデジタルストリームである。このデジタルストリームは、フィルム映像、NTSC映像、PAL映像をデジタル化することにより得られたデジタルビデオ、LPCM音源、AC-3音源、DTS音源をデジタル化することにより得られたデジタルオーディオを(上１段目)、PESパケットからなるエレメンタリストリームに変換し(上２段目)、更にTSパケットに変換して(上３段目)、同じく字幕系のプレゼンテーショングラフィクスストリーム(PresentatiionGraphics(PG)ストリーム)及び対話系のインタラクティブグラフィクスストリーム(Interactive Graphics(IG)ストリーム)を(下１段目)を、PESパケット列に変換し(下２段目)、更にTSパケットに変換して(下３段目)、これらを多重化することで構成される。
【００１７】
PGストリームとは、動画の再生進行に伴った字幕表示を実現するエレメンタリストリームであり、IGストリームは、動画の再生進行に伴ったGUIを実現するエレメンタリストリームである。
PESパケット化されたデジタル映像はビデオストリームと呼ばれ、又はPESパケット化された音声は、オーディオストリームと呼ばれる。これらビデオストリーム、オーディオストリームはエレメンタリストリームであり、独立復号可能な単位として、“AccessUnit”が存在する。ビデオストリームでは、いわゆるGOP(Group Of Picture)が、この“Access Unit”に該当する。
【００１８】
ビデオストリームのうち、1つのPTSで再生される再生単位(ピクチャ等)を、“Video Presentation Unit”という。オーディオストリームのうち、1つのPTSで再生される再生単位を、“AudioPresentation Unit”という。
ここでAVClipを構成するPESパケットは、1つ以上の“STC_Seuence”を構成する。“STC_Seuence”とは、PESパケットの配列であって、そのPTS、DTSが参照しているSystemTime Clock(STC)の値に、STC不連続点(system time-base discontinuity)が存在しないものをいう。STC不連続点がないことがSTC_Seuenceの要件であるので、1つのSTC_Seuenceを構成するPESパケット列のうち、STC不連続点の直後に位置するPESパケットであって、PCR(ProgramClock Reference)を包含したものから、次のSTC不連続点の直前までが1つのSTC_Seuenceになる。
続いて、以上のように構成されたAVClipが、BD-ROMにどのように書き込まれるかを説明する。図４は、AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す。本図の第１段目にAVClipを構成するTSパケットを示す。
【００１９】
AVClipを構成する188バイトのTSパケットは、第２段目に示すように4バイトのTS_extra_header(図中のハッチング部)、が付されて、192バイト長のSourceパケットになる。このTS_extra_headerは、Arrival_Time_Stampを含む。
AVClipを構成するSourceパケットは、第3段目におけるAVClipにおいて、1つ以上の“ATC_Seuence”を構成する。“ATC_Seuence”とは、Sourceパケットの配列であって、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、不連続点(noarrival time-base discontinutiy)が存在しないものをいう。いいかえれば、そのArrival_Time_Stampが参照しているArrival_Time_Clockに、連続性が存在するSourceパケット列を“ATC_Seuence”という。
【００２０】
かかるATC_SeuenceがAVClipになり、xxxxx.m2tsというファイル名でBD-ROMに記録される。
かかるAVClipは、通常のコンピュータファイル同様、複数のファイルエクステントに分割され、BD-ROM上の領域に記録される。第4段目はAVClipがどのようにBD-ROMに記録されるかを模式的に示す。この第4段目においてファイルを構成する各ファイルエクステントは、予め定められたＳexetent以上のデータ長を有する。
【００２１】
AVClipを複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓexetentに検討する。
ここでBD-ROMにおいて光ピックアップのジャンプに要する時間は、
Ｔjump＝Ｔaccess+Ｔoverhead
で与えられる。
Ｔaccessは、ジャンプ距離に応じて与えられる時間(m秒)であり、
ジャンプ距離(論理ブロック数)が0〜5000であるなら179m秒、
ジャンプ距離(論理ブロック数)が5001〜10,000であるなら210m秒、
ジャンプ距離(論理ブロック数)が10,001〜20,000であるなら270m秒、
ジャンプ距離がハーフストロークであるなら990m秒、
ジャンプ距離がフルストロークであるなら1220m秒になる。
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を複数のエクステントに分割して記録する場合の、エクステント一個当たりの最小データ長Ｓexetentは、
Ｓexetent＝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)
になる。
よって
Ｓexetent≧
(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パケットを“AlignedUnit”といい、BD-ROMへの書き込みにあたっては、Aligned Unit単位で暗号化がなされる。
【００２５】
第３段目においてセクタは、32個単位で誤り訂正符号が付され、ECCブロックを構成する。再生装置はAligned Unitの単位でBD-ROMをアクセスする限り、32個の完結したSourceパケットを得ることができる。以上がBD-ROMに対するAVClipの書き込みのプロセスである。
＜BD-ROMの構成その２.Clip情報＞
続いて拡張子.clpiが付与されたファイルについて説明する。拡張子.clpiが付与されたファイル(00001.clpi,00002.clpi,00003.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())』からなる。
【００２６】
Sequence Infoは、AVClipに含まれる、1つ以上のSTC-Sequence、ATC-Sequenceについての情報である。これらの情報を設けておくことの意義は、STC、ATCの不連続点を、予め再生装置に通知するためである。つまりかかる不連続点が存在すると、AVClip内において同じ値のPTS,ATSが出現する可能性があり、再生時に不都合が生じる。STC,ATCが連続しているのは、トランスポートストリームのうち、どこからどこまでであるかを示すため、SequenceInfoは設けられている。
【００２７】
Program Infoとは、Program内容が一定である区間(Program Sequence)を示す情報である。Programとは、同期再生のための時間軸を共有し合うエレメンタリーストリーム同士の集まりである。ProgramSequence情報を設けておくことの意義は、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つのエレメンタリストリーム上において、AccessUnitの先頭部分である、Access Unit Delimiterが存在するエントリー位置のパケット番号(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は、AccessUnitのSPN_EP_start及びPTS_EP_startの上位ビットを表す役割をもち、EP_Lowは、Access UnitのSPN_EP_start及びPTS_EP_startの下位ビットを示す役割をもつ。
図中の引き出し線cu4は、EP_Highの内部構成をクローズアップしている。この引き出し線に示すように、EP_High(i)は、EP_Lowに対する参照値である『ref_to_EP_Low_id[i]』と、AccessUnitの先頭にあたるNon-IDR Iピクチャ、IDRピクチャのPTSの上位ビットを示す『PTS_EP_High[i]』と、Access Unitの先頭にあたるNon-IDRIピクチャ、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)』と、対応するAccessUnit(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が対象としているSTC_Sequenceを一意に示す『ref_to_STC_id[0]』と、このPlayItemと、その1つ前のPlayItemとの接続を、シームレスに行うか否かを示す『connection_condition』と、再生区間の始点を示す時間情報『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段目に示すPlayItem時間軸である。このように、PlayItem情報の定義により、AVClipとは異なる時間軸の定義が可能になる。
【００３５】
＜STN_table＞
STN_tableは、Play ItemのClip_Information_file_nameで指定されているAVClipに多重化された複数エレメンタリストリームのうち、再生可能なものを示すテーブルである。具体的にいうとSTN_tableは、複数エレメンタリストリームのそれぞれについてのentryを、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において再生可能なビデオストリーム、オーディオストリーム、PG_stream、IGストリームのそれぞれに対応している。
entry−attributeの詳細について説明する。図１０（ｂ）〜（ｅ）は、entry−attributeの詳細を示す図である。
【００３８】
図１０（ｂ）は、ビデオストリームに対応したentry−attributeの組みを示す図である。
ビデオストリームにおけるentryは、AVClipを多重分離するにあたって、当該ビデオストリームの抽出に用いられるPIDを示す『ref_to_stream_PID_of_mainClip』を含む。
ビデオストリームにおけるattributeは、0x02に設定された『stream_coding_type』と、ビデオストリームの表示レートを示す『frame_rate』等を含む。
【００３９】
図１０（ｃ）は、オーディオストリームに対応したentry−attributeの組みを示す図である。
オーディオストリームにおけるentryは、AVClipを多重分離するにあたって、当該オーディオストリームの抽出に用いられるPIDを示す『ref_to_stream_PID_of_mainClip』を含む。
【００４０】
オーディオストリームにおけるattributeは、0x80(LinearPCM),0x81(AC-3),0x82(DTS)の何れかに設定されることによりオーディオストリームのコーデイングタイプを示す『stream_coding_type』と、対応するオーディオストリームのチャネル構成を示し、マルチチャネル出力の可否を示す『audio_presentation_type』と、対応するオーディオストリームの言語属性を示す『audio_languagecode』等からなる。
【００４１】
マルチチャネルには、5.1CHのサラウンド音声の他、ステレオ音声も含まれるが、以降の説明では、マルチチャネルは、5.1CHのサラウンド音声のみを意味するとして説明を進める。
図１０（ｄ）は、PGストリームに対応したentry−attributeの組みを示す図である。
PGストリームにおけるentryは、AVClipを多重分離するにあたって、当該PGストリームの抽出に用いられるPIDを示す『ref_to_stream_PID_of_mainClip』を含む。
【００４２】
PGストリームにおけるattributeは、0x90に設定されることによりPGストリームのコーディックを示す『stream_coding_type』と、対応するPGストリームの言語属性を示す『PG_languagecode』とからなる。
図１０（ｅ）は、IGストリームに対応したentry−attributeの組みを示す図である。
IGストリームにおけるentryは、AVClipを多重分離するにあたって、当該IGストリームの抽出に用いられるPIDを示す『ref_to_stream_PID_of_mainClip』を含む。
【００４３】
IGストリームにおけるattributeは、0x91に設定されることによりIGストリームのコーディックを示す『stream_coding_type』と、対応するIGストリームの言語属性を示す『languagecode』とからなる。
＜PlayList情報の説明その２.PlayListMark＞
以上が、本実施形態に係るPlayItem情報についての説明である。続いて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時間軸上に、チャプター点を定義することができる。
【００４６】
AVClip−SubClipを同期させ得る同期区間の定義を可能とするのが、BD-ROMにおけるプレイリスト情報の特徴である。以上のClip情報及びプレイリスト情報は、”静的シナリオ”に分類される。何故なら、以上のClip情報及びプレイリスト情報により、静的な再生単位であるプレイリストが定義されるからである。以上で静的シナリオについての説明を終わる。
【００４７】
続いて”動的なシナリオ”について説明する。動的シナリオとは、AVClipの再生制御を動的に規定するシナリオデータである。”動的に”というのは、再生装置における状態変化やユーザからのキーイベントにより再生制御の中身がかわることをいう。BD-ROMでは、この再生制御の動作環境として2つのモードを想定している。1つ目は、DVD再生装置の動作環境と良く似た動作環境であり、コマンドベースの実行環境である。2つ目は、Java（登録商標）仮想マシンの動作環境である。これら2つの動作環境のうち1つ目は、HDMVモードと呼ばれる。2つ目は、BD-Jモードと呼ばれる。これら2つの動作環境があるため、動的シナリオはこのどちらかの動作環境を想定して記述される。HDMVモードを想定した動的シナリオはMovieObjectと呼ばれる。一方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()という。
JMPコマンド
書式：JMP 引数
JMPコマンドは、現在の動的シナリオを途中で廃棄し(discard)、引数たる分岐先動的シナリオを実行するという分岐である。JMP命令の形式には、分岐先動的シナリオを直接指定している直接参照のものと、分岐先動的シナリオを間接参照している間接参照のものがある。
Movie Objectにおけるナビゲーションコマンドの記述は、DVDにおけるナビゲーションコマンドの記述方式と良く似ているので、DVD上のディスクコンテンツを、BD-ROMに移植するという作業を効率的に行うことができる。MovieObjectについては、以下の国際公開公報に記載された先行技術が存在する。詳細については、本国際公開公報を参照されたい。
国際公開公報W0 2004/074976
以上でMovie Objectについての説明を終える。続いてBD-J Objectについて説明する。
＜BD-J Object＞
BD-J Objectは、Java（登録商標）プログラミング環境で記述された、BD-Jモードの動的シナリオであり、00001〜00003.bobjというファイルに格納される。
【００５０】
図１３は、BD-J Object.bdmvの内部構成を示す図である。アプリケーション管理テーブル(AMT)、プレイリスト管理テーブル(PLMT)、サウンド管理テーブル(SMT)からなる。MovieObjectとの違いは、BD-J Objectにコマンドが直接記述されていない点である。つまりMovie Objectにおいて制御手順は、ナビゲーションコマンドにより直接記述されていた。これに対しBD-JObjectでは、Java（登録商標）アプリケーションに対する指定をアプリケーション管理テーブルに記載することにより、間接的に制御手順を規定している。このような間接的な規定により、複数動的シナリオにおいて制御手順を共通化するという、制御手順の共通化を効率的に行うことができる。
【００５１】
またMovieObjectにおけるプレイリスト再生は、プレイリスト再生を命じるナビゲーションコマンド(PlayPlコマンド)の記述によりなされるが、BD-JObjectにおけるプレイリスト再生は、プレイリスト再生手順を示すプレイリスト管理テーブルをBD-J Objectに組み込むことで記述が可能になる。
このBD-JモードにおけるJava（登録商標）アプリケーションについて説明する。ここでBD-Jモードが想定しているJava（登録商標）プラットフォームは、Java（登録商標）2Micro_Edition(J2ME)Personal Basis Profile(PBP 1.0)と、Globally Executable MHPspecification(GEM1.0.2)for package media targetsとをフル実装したものである。
【００５２】
このBD-JモードにおけるJava（登録商標）アプリケーションは、xletインターフェイスを通じて、Application Managerにより、制御される。xletインターフェイスは、“loaded”,“paused”、“active”,“destoryed”といった4つの状態をもつ。
上述したJava（登録商標）プラットフォームは、JFIF(JPEG)やPNG,その他のイメージデータを表示するためのスタンダードJava（登録商標）ライブラリを含む。このため、Java（登録商標）アプリケーションは、HDMVモードにおいてIGストリームにより実現されるGUIとは異なるGUIフレームワークを実現することができる。Java（登録商標）アプリケーションにおけるGUIフレームワークは、GEM1.0.2にて規定されたHAViフレームワークを含み、GEM1.0.2におけるリモートコントロールナビゲーション機構を含む。
【００５３】
これにより、Java（登録商標）アプリケーションは、HAViフレームワークに基づくボタン表示、テキスト表示、オンライン表示(BBSの内容)といった表示を、動画像の表示と組み合わせた画面表示を実現することができ、リモートコントロールを用いて、この画面表示に対する操作を行うことができる。
このJava（登録商標）アプリケーションの実体にあたるのが、図２におけるBDMVディレクトリ配下のBDJAディレクトリに格納されたJava（登録商標）アーカイブファイル(00001.jar,00002.jar)である。以降、Java（登録商標）アーカイブファイルについて説明する。
【００５４】
＜Java（登録商標）アーカイブファイル＞
Java（登録商標）アーカイブファイル(図２の00001.jar,00002.jar)は、1つ以上のクラスファイル、1つ以上のデータファイル等を1つにまとめることで得られるファイルであり、BD-Jモードにおいて動作すべきJava（登録商標）アプリケーションを構成する。
図１４は、アーカイブファイルにより収められているプログラム、データを示す図である。本図におけるプログラム、データは、枠内に示すディレクトリ構造が配置された複数ファイルを、java（登録商標）アーカイバでまとめたものである。枠内に示すディレクトリ構造は、Rootディレクトリ、Java（登録商標）1,2,3ディレクトリ、Image1,2,3ディレクトリとからなり、Rootディレクトリにcommon.pkgが、Java（登録商標）1,Java（登録商標）2,Java（登録商標）3ディレクトリにクラスファイル(00001.class〜00007.class)が、Image1,Image2,Image3ディレクトリに、00001.JPEG〜00003.JPEG,00004.PNG〜00006.PNGが配置されている。java（登録商標）アーカイブファイルは、これらをjava（登録商標）アーカイバでまとめることで得られる。かかるクラスファイル及びデータは、BD-ROMからキャッシュに読み出されるにあたって展開され、キャッシュ上で、ディレクトリに配置された複数ファイルとして取り扱われる。Java（登録商標）アーカイブファイルのファイル名における"zzzzz"という5桁の数値は、アプリケーションのID(applicationID)を示す。本Java（登録商標）アーカイブファイルがキャッシュに読み出された際、このファイル名における数値を参照することにより、任意のJava（登録商標）アプリケーションを構成するプログラム，データを取り出すことができる。
【００５５】
尚、本実施形態においてアプリケーションを構成するプログラム、データは、Java（登録商標）アーカイブファイルにまとめられたが、LZHファイル、zipファイルであってもよい。
以上が、BD-Jモードにおける動的シナリオについての説明である。
＜sound.bdmv＞
続いてsound.bdmvについて説明する。sound.bdmvは、Java（登録商標）アプリケーションのGUIフレームワークに対して操作がなされた場合、クリック音として出力すべきオーディオデータ(かかるオーディオデータを、サウンドデータという)が格納されるファイルである。
【００５６】
図１５は、ファイルsound.bdmvの構成を示す図である。ファイルsound.bdmvは、Sound Data()と、Sound Index()とからなる。SoundData()は、複数のサウンドデータ(sound_data(0),sound_data(1))からなる。これらのサウンドデータのうち、sound_data(0)は、Java（登録商標）アプリケーションのGUIフレームワークに対する操作時に、第１のクリック音として出力される音源である。sound_data(1)は、Java（登録商標）アプリケーションのGUIフレームワークに対する操作時に、第２のクリック音として出力される音源である。これらのサウンドデータは、sound_IDと呼ばれる識別子にて指示される。
【００５７】
Sound Index()は、サウンド数(number_of_sound_entries)、sound_data(0)に対するインデックス、sound_data(1)に対するインデックスからなる。
インデックスは、モノラル/ステレオの別などの各サウンドの属性(sound_attributes)、対応するサウンドデータのアドレス(sound_data_start_address)、対応するサウンドデータの連続長(sound_data_length)からなる。
【００５８】
図２〜図６に示したように、映画の劇中に使用される音声(台詞、BGM、効果音)の音源は、オーディオストリームとして、AVClip内に多重化される。これは、映画劇中の音声を表すオーディオストリームを、ビデオストリームの読み出しと同時に再生装置に供給するためである。これに対し、ファイル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は、タイトルを構成する、Movie Object又はBD-J Objectを示すテーブルである。
【００６０】
Titleにおいて、あるTitleの構成要素となるMovieObjectはどれであるか、又は、あるTitleの構成要素となるBD-J Objectはどれであるのかを定義する。
Index.bdmvについては、以下の国際公開公報に詳細が記載されている。詳細については、本公報を参照されたい。
国際公開公報WO 2004/025651 A1公報
以降、図１５に示したアプリケーション管理テーブル、プレイリスト管理テーブル、サウンド管理テーブルのそれぞれについてより詳しく説明する。
【００６１】
＜アプリケーション管理テーブル＞
アプリケーション管理テーブル(AMT)について説明する。アプリケーション管理テーブル(AMT)とは、上述したGEM1.0.2for packagemedia targetsにおける“アプリケーション  シグナリング”を実装するテーブルである。“アプリケーション  シグナリング”とは、GEM1.0.2が規定するMHP(MultimediaHome Platform)において、“サービス”を生存区間としてアプリケーションの起動、実行を行う制御をいう。本実施形態におけるアプリケーション管理テーブルは、この“サービス”の代わりに、BD-ROMにおける“タイトル”を生存区間にして、アプリケーションの起動、実行の制御を実現する。
【００６２】
図１６（ａ）は、アプリケーション管理テーブルの内部構成を示す図である。本図に示すようにアプリケーション管理テーブルは、『life_cycle』と、『apli_id_ref』と、『run_attribute』と、『run_priority』からなる。
図１６（ｂ）は、アプリケーション管理テーブルを構成する情報要素の意味内容を示す。
【００６３】
『life_cycle』は、アプリケーションの”生存区間”を示す。
『apli_id_ref』は、”アプリケーション識別子”に対する参照値が記述されることにより、左記の生存区間をもつアプリケーションがどれであるかを示す。アプリケーション識別子は、Java（登録商標）アーカイブファイルにおいて、ファイル名として付与された5桁の数値zzzzzで表現される。『apli_id_ref』には、この5桁の数値が記述される。
【００６４】
『run_attribute』は、当該生存区間におけるアプリケーションの”起動属性”が記述される。起動属性には、AutoRun、Present、Suspendといった種別がある。
『run_priority』は、当該生存区間におけるアプリケーションの”起動優先度”が記述される。BD-J Objectでは、これらの情報を用いてアプリケーションの挙動を制御する。
＜生存区間＞
アプリケーション管理テーブルに規定される情報のうち、生存区間について説明する。
【００６５】
生存区間とは、BD-ROMに記録されたコンテンツ全体の時間軸において、仮想マシンのワークメモリ上でアプリケーションが生存し得る区間を示す。ワークメモリにおける”生存”とは、そのアプリケーションを構成するxletプログラムが、Java（登録商標）仮想マシン内のワークメモリに読み出され、Java（登録商標）仮想マシンによる実行が可能になっている状態をいう。
【００６６】
Java（登録商標）仮想マシンにおいてアプリケーションを動作させる場合、時間軸の何処からアプリケーションによるサービスを開始し、時間軸の何処でアプリケーションによるサービスを終えるかという”サービスの開始点・終了点”を明確に規定することが重要になる。このサービスの開始点・終了点を規定するのが、アプリケーション管理テーブルにおける生存区間である。
【００６７】
一方、DVD-Videoのような読出専用ディスクで供給されるディスクコンテンツは、トップメニュータイトルを中核とした構造になっている。そのトップメニュータイトルから、個々の著作物へと分岐して再生を行い、その後再び、トップメニュータイトルに戻るという独特の状態遷移をなす。図１７は、ディスクコンテンツにおける状態遷移を示す図である。本図における四角枠は、Titleである。Titleとは、ディスクコンテンツ特有の状態遷移において、1つの”状態”にあたる再生単位であり、このタイトルが、Java（登録商標）アプリケーションの生存区間として取り扱われる。
【００６８】
Titleには、BD-ROMのローディング時に最初に再生される『FirstPlayTitle』、Top-Menuを構成する『Top_menuTitle』、これら以外の一般的な『Title』がある。また、図中の矢印jh1,2,3,4,5,6,7,8は、Title間の分岐を象徴的に示す。本図に示される状態遷移とは、BD-ROMローディング時に、『FirstPlayTitle』が再生され、『Top_menuTitle』への分岐が発生して、トップメニューに対する選択待ちになるというものである。
【００６９】
トップメニューに対する選択操作がユーザによりなされれば、選択に従って該当Titleの再生を行い、再びTopMenu Titleに戻るとの処理を、BD-ROMのイジェクトがなされるまで延々と繰り返すというのが、ディスクコンテンツ特有の状態遷移である。
それでは、図１７のような状態遷移をなすディスクコンテンツにおいて、Titleは、どのように生存区間として規定されるのであろうか。BD-ROMのローディングがなされた後、図１７において矢印jh1,2,3,4・・・・・に示された参照符号の数値順に分岐がなされ、BD-ROMがイジェクトされたものとする。そうすると、BD-ROMがローディングされてから、イジェクトされるまでの連続時間帯を一本の時間軸と同視することができる。この時間軸を、ディスク全体の時間軸とする。図１８（ａ）は、ディスク全体の時間軸を示す図であり、図１８（ｂ）は、この時間軸における構成を示す。図１８（ｂ）に示すように、ディスク全体の時間軸は、FirstPlayTitleが再生されている区間、TopMenu Titleが再生されている区間、title#1が再生されている区間等からなる。これらTitleの再生区間はどのように規定されているかというと、Titleは、唯一のBD-JObjectから構成されるから、どれかのMovieObject又はBD-J Objectが、有効になっている期間をTitleの再生区間と考えることができる。
【００７０】
つまりFirstPlay Title、TopMenu Title、その他のTitleは、何れも動的シナリオから構成されるから、Titleを構成するBD-JObjectのうち、どれかカレントBD-J ObjectとしてActivatedされ、再生装置内において解読・実行に供されている期間を、Titleの再生区間と定義することができる。図１９（ａ）は、BD-ROM全体の時間軸において、識別子bobj_idにより特定されるBD-JObjectから特定されるタイトル再生区間を示す図である。ここで識別子bobj_idにより特定されるBD-J Objectが、1つのTitleを構成しているなら、その識別子bobj_idにより特定されるBD-JObjectが有効になっているBD-ROM時間軸上の一区間を、Titleの再生区間と考えることができる。
。
【００７１】
ここでBD-J ObjectがActivateされている期間の終期は、Title分岐がなされるまでである。つまり、Title分岐がなされるまで、実行の対象になっている動的シナリオは、カレントBD-JObjectとして扱われるから、そのBD-J ObjectにおいてJumpTitleが発生するまでの1つの区間を、Title区間として扱う。
続いてTitle区間と、PL時間軸との関係について説明する。上述したようにMovieObject、BD-J Objectでは、1つの処理手順としてプレイリスト再生手順を記述することができる。プレイリスト再生手順の記述があれば、上述したPL時間軸の全部又は一部がTitle区間に帰属することになる。図１９（ａ）の一例においてBD-JObjectに、プレイリスト管理テーブルが記述されているとする。この場合、BD-J Objectに対応するTitle区間には、図１９（ｂ）に示すように、PL時間軸が帰属する。このPL時間軸には更に、複数チャプター(Chapter#1,#2,#3)が定義され得るため、BD-ROM上の時間軸には、BD-ROM全体−Title−プレイリスト−チャプターというドメインが存在することになる。これらのドメインを用いて、アプリケーションの生存区間を記述することができる。尚、プレイリスト再生は、アプリケーション実行と同時になされため、プレイリスト再生の途中で、Title分岐が発生することがある。この場合、1つのTitle再生区間内にはプレイリスト時間軸全体ではなく、プレイリスト時間軸の一部分のみが帰属することになる。つまり1つのTitleの再生区間において、プレイリスト時間軸の全体が帰属するか、その一部分が帰属するかは、Title分岐が何時発生するかによって変わる。
【００７２】
図２０は、図１９（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。本図に示すようにアプリケーションには、Titleを生存区間にした”タイトルバウンダリアプリケーション”、Title内におけるチャプターを生存区間にした”チャプターバウンダリアプリケーション”、BD-ROM全体の時間軸を生存区間にした”タイトルアンバウンダリーアプリケーション”という3つの典型がある。
【００７３】
このうちタイトルバウンダリアプリケーションの生存区間は、そのタイトルの識別子を用いて定義することができる。またチャプターバウンダリアプリケーションの生存区間は、チャプターが属するタイトルの識別子と、そのチャプターの識別子との組みを用いて定義することができる。  
プラットフォームが動作していたとしても、Titleやチャプターという生存区間が終われば、リソースをアプリケーションから回収することができる。リソース回収の機会を保証するので、プラットフォームの動作を安定化させることができる。
【００７４】
近い将来、実施されるであろうディスクコンテンツを題材に選んで、アプリケーション管理テーブルにおける生存区間記述について、具体例を交えて説明する。ここで題材にするディスクコンテンツは、映像本編を構成する本編タイトル(title#1)、オンラインショッピングを構成するオンラインショッピングタイトル(title#2)、ゲームアプリケーションを構成するゲームタイトル(title#3)という、性格が異なる3つのタイトルを含むものである。図２１は、本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを含むディスクコンテンツを示す図である。本図における右側にはIndex.bdmvを記述しており、左側には3つのタイトルを記述している。
【００７５】
右側における破線枠は、各アプリケーションがどのタイトルに属しているかという帰属関係を示す。3つのタイトルのうちtitle#1は、application#1、application#2、application#3という3つのアプリケーションからなる。title#2は、application#3、application#4という2つのアプリケーション、title#3は、application#5を含む。図２１の一例においてapplication#3は、title#1、title#2の双方で起動される。
【００７６】
図２１の破線に示される帰属関係から各アプリケーションの生存区間をグラフ化すると、図２２（ａ）のようになる。本図において横軸は、タイトル再生区間であり、縦軸方向に各アプリケーションの生存区間を配置している。ここでapplication#1、application#2は、title#1のみに帰属しているので、これらの生存区間は、title#1内に留まっている。application#4は、title#2のみに帰属しているので、これらの生存区間は、title#2内に留まっている。application#5は、title#3のみに帰属しているので、これらの生存区間は、title#3内に留まっている。application#3は、title#1及びtitle#2に帰属しているので、これらの生存区間は、title#1−title#2にわたる。この生存区間に基づき、アプリケーション管理テーブルを記述すると、title#1,#2,#3のアプリケーション管理テーブルは図２２（ｂ）のようになる。このようにアプリケーション管理テーブルが記述されれば、title#1の再生開始時においてapplication#1、application#2、application#3をワークメモリにロードしておく。そしてtitle#2の開始時にapplication#1、application#2をワークメモリから削除してapplication#3のみにするという制御を行う。これと同様にtitle#2の再生開始時においてapplication#4をワークメモリにロードしておき、title#3の開始時にapplication#3,#4をワークメモリから削除するという制御を行いうる。
【００７７】
更に、title#3の再生中においてapplication#5をワークメモリにロードしておき、title#3の再生終了時にapplication#5をワークメモリから削除するという制御を行いうる。
タイトル間分岐があった場合でも、分岐元−分岐先において生存しているアプリケーションはワークメモリ上に格納しておき、分岐元にはなく、分岐先にのみ存在するアプリケーションをワークメモリに読み込めば良いから、アプリケーションをワークメモリに読み込む回数は必要最低数になる。このように、読込回数を少なくすることにより、タイトルの境界を意識させないアプリケーション、つまりアンバウンダリなアプリケーションを実現することができる。
【００７８】
続いてアプリケーションの起動属性についてより詳しく説明する。起動属性には、自動的な起動を示す「AutoRun」、自動起動の対象ではないが、仮想マシンのワークメモリに置いて良いことを示す「Present」、仮想マシンのワークメモリにはおかれるが、CPUパワーの割り当ては不可となる「Suspend」がある。
「AutoRun」は、対応するタイトルの分岐と同時に、そのアプリケーションをワークメモリに読み込み、且つ実行する旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、その分岐先タイトルにおいて生存しており、かつ起動属性がAutoRunに設定されたアプリケーションを仮想マシンのワークメモリに読み込み実行する。これによりそのアプリケーションは、タイトル分岐と共に自動的に起動されることになる。
【００７９】
起動属性「Present」は、継続属性であり、分岐元titleにおけるアプリケーションの状態を継続することを示す。また対応するアプリケーションを実行してよいことを示す属性である。起動属性が「Present」である場合、この起動属性が付与されたアプリケーションは、他のアプリケーションからの呼び出しが許可されることになる。アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、起動中のアプリケーションから呼出があると、そのアプリケーションのapplicationIDが、アプリケーション管理テーブルに記述されていて、起動属性が「Present」であるか否かを判定する。「Present」であれば、そのアプリケーションをワークメモリにロードする。一方、その呼出先アプリケーションのapplicationIDがアプリケーション管理テーブルに記述されていない場合、そのアプリケーションはワークメモリにロードされない。アプリケーションによる呼出は、この「Present」が付与されたアプリケーションに限られることになる。「Present」は、起動属性を明示的に指定しない場合に付与されるデフォルトの起動属性であるから、あるアプリケーションの起動属性が無指定「−−」である場合、そのアプリケーションの起動属性の起動属性はこのPresentであることを意味する。
【００８０】
「Suspend」とは、リソースは割り付けられているが、CPUパワーは割り当てられない状態にアプリケーションが置かれることをいう。かかるSuspendは、例えばゲームタイトルの実行中に、サイドパスを経由するという処理の実現に有意義である。
図２３は、起動属性がとり得る三態様(Present、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。直前状態が”非起動”である場合、起動属性が”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、起動されることになる。
【００８１】
直前状態が”非起動”であり、起動属性が”Present”、”Suspend”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
直前状態が”起動中”である場合、起動属性が”Present”、”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、何もせず、状態を継続することになる。
【００８２】
起動属性が”Suspend”であるなら、アプリケーションの状態はSuspendされることになる。直前状態が”Suspend”である場合、分岐先タイトルの起動属性が”Suspend”ならSuspendを維持することになる。”Present”又は”AutoRun”であるなら、分岐先タイトルにおいてそのアプリケーションは、レジュームすることになる。アプリケーション管理テーブルにおいて生存区間及び起動属性を定義することにより、タイトル再生区間の進行に沿って、Java（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。
【００８３】
尚、直前状態が”Suspend”であり、分岐先タイトルの起動属性が”Present”の場合は、直前状態、すなわちサスペンド状態を維持しても良い。
最後に、各アプリケーションに対する”起動優先度”について説明する。
この起動優先度は、0〜255の値をとり、メモリリソース枯渇時や、CPU負荷が高まった時に、どのアプリケーションを強制的に終了させるか、また、どちらのアプリケーションからリソースを奪うかという処理をアプリケーションマネージャが行うにあたっての判断材料になる。この場合、アプリケーションマネージャは、起動優先度が低いアプリケーションの動作を終了し、起動優先度が高いアプリケーションの動作を継続させるとの処理を行う。
【００８４】
また起動優先度は、再生中プレイリストに対する要求が競合した場合のアプリケーション間の調停でも利用される。ここであるアプリケーションが、あるプレイリストの早送りしているものとする。ここで別のアプリケーションが同じプレイリストに対するポーズ要求を行ったとすると、これらのアプリケーションに付与された起動優先度を比較する。そして早送りを命じたアプリケーションの起動優先度が高いなら、かかるアプリケーションによる早送りを継続して行う。逆にポーズを命じたアプリケーションの起動優先度が高いなら、早送り中プレイリストのポーズを行う。
【００８５】
以上の生存区間・起動属性・起動優先度により、仮想マシン上で動作し得るアプリケーションの数を所定数以下に制限するよう規定しておくことがオーサリング時に可能なる。そのため、アプリケーションの安定動作を保証することができる。
＜プレイリスト管理テーブル＞
以上がアプリケーション管理テーブルについての説明である。続いてプレイリスト管理テーブル(PLMT)について説明する。プレイリスト管理テーブルとは、アプリケーションの生存区間において、各アプリケーション実行と同時に行うべき再生制御を示すテーブルである。アプリケーションの動作というのは不安定であり、起動の失敗や異常終了がありうる。そこで起動失敗、異常終了があった場合のFailSafe機構として、本実施形態ではアプリケーションの生存区間毎に、プレイリスト管理テーブルを設けている。プレイリスト管理テーブルは、あるアプリケーションの生存区間が開始した際、これと同時に行うべき再生制御を規定する情報である。この再生制御とは、プレイリスト情報に基づくAVClip再生であり、プレイリスト情報による再生制御を同時に行うことで、アプリケーション実行と、プレイリスト再生とが同時になされることになる。プレイリスト管理テーブルは、アプリケーションの生存区間毎に設けられるとしたが、プレイリスト管理テーブルが設けられるアプリケーションは、タイトルバウンダリのアプリケーションに限られる。何故ならタイトルアンバウンダリーアプリケーションは、全タイトルを生存区間にしているため、アプリケーション実行と同時にプレイリスト再生を行うという制御は、適合しないからである。
【００８６】
チャプターバウンダリアプリケーションは、1つのプレイリスト内のチャプターからアプリケーション実行を開始するという前提の下で生存区間が規定されているため、プレイリスト再生を規定する必要はないからである。以上のことからプレイリスト管理テーブルは、1つ以上のTitleからなる生存区間に定義されることになる。
図２４（ａ）は、プレイリスト管理テーブルの内部構成を示す図である。本図に示すようにプレイリスト管理テーブルは、『PL_id_ref』と、『Playback_Attribute』とからなる。
【００８７】
図２４（ｂ）は、プレイリスト管理テーブルを構成する情報要素の意味内容を示す。
『PL_id_ref』は、プレイリスト識別子に対する”参照値”が記述されることにより、アプリケーションの生存区間において再生可能となるプレイリストがどれであるかを示す。プレイリスト識別子は、ファイルYYYYY.MPLSにおいて、ファイル名として付与された5桁の数値YYYYYで表現される。このYYYYYが記述されることにより、『PL_id_ref』は、対応するTitleにおいて再生可能となるプレイリストがどれであるかを示す。
【００８８】
『Playback_Attribute』は、アプリケーション管理テーブルにおける起動属性に倣った属性であり、『PL_id_ref』に記述されたプレイリストを、タイトル開始時において、どのように再生するかを規定する再生属性である。プレイリストに対する再生属性には、『AutoPlay』、『Present』といった種別がある。
『AutoPlay』とは、対応するタイトルの分岐と同時に、そのプレイリストを再生させる旨を示す属性である。あるタイトルから、別のタイトルへの分岐があると、アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、その分岐先タイトルにおいて再生可能であり、かつ再生属性がAutoPlayに設定されたプレイリストの再生を開始する。これにより起動属性がAutoPlayに設定されたプレイリストは、タイトル分岐と共に自動的に起動されることになる。
【００８９】
『Present』とは、起動属性におけるPresent同様、継続属性であり、分岐元titleにおけるプレイリストの状態を継続することを示す。また対応するプレイリストを再生してよいことを示す属性である。例えば連続して再生される2つのTitleがあり、前のタイトル側のプレイリスト管理テーブルでは、あるプレイリストの再生属性がAutoPlayに設定され、カレントタイトル側のプレイリスト管理テーブルでは、そのプレイリストの再生属性がPresentに設定されているものとする。ここでプレイリストの再生時間が2時間長であり、このうち1時間が経過した時点で分岐が発生したとする。この場合カレントタイトルでは、再生属性がPresentに設定されているので、カレントタイトルにおいて、そのプレイリストは、1時間という再生済み区間の直後から、再生されることになる。このように再生属性をPresentに設定しておけば、Title間の分岐があった場合でも、プレイリスト再生をその残りの部分から開始することができる。これにより分岐し合う一連のTitleにおいて、共通のプレイリストを再生するという”タイトル間におけるプレイリスト再生の共通化”を容易に実現することができる。また分岐先タイトルが複数ある場合、これら複数タイトルの再生属性を何れもPresentにしておけば、複数のうちどれに分岐したとしても、1つの共通のプレイリスト再生を継続させることができる。
【００９０】
尚Titleの境界は、シームレス再生を保証しなくてもよいので、上述したように複数Title間で1つのプレイリストを再生しようとする場合、分岐前後でプレイリスト再生を中断させることは許容される。
また、再生属性が「Present」である場合、この再生属性が付与されたプレイリストは、他のアプリケーションからの再生要求により再生されることになる。アプリケーション管理を行う管理主体(アプリケーションマネージャ)は、起動中のアプリケーションから、プレイリストの再生要求があると、要求を受けたプレイリストのPL_id_refが、プレイリスト管理テーブルに記述されていて、再生属性が「AutoPlay」か「Present」のいずれかか否かを判定する。「AutoPlay」か「Present」のいずれかであれば、そのプレイリストを再生する。一方、要求を受けたプレイリストのPL_id_refがプレイリスト管理テーブルに記述されていない場合、そのプレイリストを再生しない。アプリケーションの要求によるプレイリスト再生は、この「AutoPlay」か「Present」のいずれかが付与されたプレイリストに限られることになる。「Present」は、再生属性を明示的に指定しない場合に付与されるデフォルトの再生属性であるから、あるプレイリストの再生属性が無指定「−−」であるとそのプレイリストの再生属性はこのPresentであることを意味する。
【００９１】
図２５は、プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。図２５の第1段目は、Titleの再生映像を示し、第2段目は、Titleの時間軸を示す。第3段目はPLMTにより再生が規定されるプレイリスト、第4段目は、アプリケーション実行を示す。第4段目においてapplication#1は、Titleの開始と共に起動されており、その後、時点t1において動作状態になる。一方PlayList#1は、Titleの開始と共に再生が開始されている。Playlist#1の再生は、Titleの開始と同じ時点に開始されているので、第1段目の左側に示すように、Titleの再生開始直後から、アプリケーションが動作状態になるまでのスタートアップディレイにおいて、プレイリストの再生画像gj1がフルスクリーン表示される。プレイリスト管理テーブルの再生属性を、”AutoPlay”に設定しておくことにより、Java（登録商標）アプリケーションが動作状態になるまで5〜10秒という時間がかかったとしても、その間、”とりあえず何かが写っている状態”になる。この”とりあえず何かが写っている状態”によりタイトル実行開始時のスタートアップディレイを補うことができる。
【００９２】
一方、application#1は、時点t1で動作状態になるので、プレイリスト再生画像を子画面、アプリケーションの実行画像を親画面にした合成画像gj2が時点t1において表示されることになる。アプリケーションの実行画像は、Startボタン,continueボタン,POWERインディケータを配置したゲーム用のGUIフレームワークであり、かかるGUIフレームワークの描画処理をJava（登録商標）アプリケーションが実行することでなされる。
【００９３】
こうした、プレイリストの再生映像と、Java（登録商標）アプリケーションのGUIフレームワークとを組み合わせた再生映像をなすタイトルを構成することができるのが、PLMTの特徴である。
図２６は、カレントタイトルがとり得る三態様(プレイリスト管理テーブル無し(i)、プレイリスト管理テーブル有りで尚且つAutoPlay(ii)、プレイリスト管理テーブル有りで尚且つ無指定(iii))と、直前タイトルにおけるプレイリストの状態(非再生状態、再生中状態)とがとりうる6通りの組合せを示す図である。
【００９４】
本図における6通りの組合せのうち、”直前状態＝非再生状態”と、”カレントタイトル＝プレイリスト管理テーブル有り、尚且つ、カレントタイトルの再生属性＝AutoPlay”との組合せにおいて、分岐先タイトルにおけるプレイリストの再生は、自動的に開始することになる。
また”直前状態＝再生中状態”と、”カレントタイトル＝プレイリスト管理テーブル無し”との組合せにおいて、分岐先タイトルでのプレイリストの再生は、自動的に停止することになる。
【００９５】
そしてこれら2つの組合せ以外は全て、前のタイトルの状態を継続することになる。プレイリスト管理テーブルに基づくプレイリスト再生の開始は、分岐元タイトルにおいて非再生状態であり、分岐先タイトルにおいてAutoPlay属性が付与されている場合に限られるので、タイトルの分岐発生する毎に、プレイリスト再生を開始させる必要はない。タイトル間の分岐が多数発生したとしても、プレイリスト再生を開始させる回数を必要最低数にすることができる。
プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例について図２７（ａ）を参照しながら説明する。ここで想定する具体例は、2つの連続するTitle(title#1、title#2)であリ、そのうちtitle#1では、AutoRunアプリケーションとしてapplication#1、application#2が記述されている。title#2ではAutoRunアプリケーションとしてapplication#2、application#3が記述されている。一方、title#1のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#1が、title#2のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#2が記述されているものとする。図２７（ｂ）は、図２７（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。
【００９６】
title#1においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、title#1の開始時にはapplication#1、application#2が自動的に起動され、PlayList#1の再生が自動的に開始される。
title#2においてアプリケーション管理テーブル、プレイリスト管理テーブルは上述したように設定されているので、title#1側に記載はあるが、title#2側には記載がないapplication#1の実行は停止させられる。同じくtitle#1側に記載があるが、title#2側に記載がないPlayList#1の再生も停止させられる。
【００９７】
title#1側に記載はないが、title#2側に記載があるPlayList#2、application#3は再生及び実行が自動的に開始することになる。タイトル分岐があれば、その分岐を契機に、再生すべきプレイリストを他のプレイリストに切り換えることができる。このようにアプリケーション管理テーブル、プレイリスト管理テーブルを用いることで分岐を契機にして、プレイリスト再生を切り換えるという処理をオーサリング段階において規定しておくことができる。
【００９８】
また図２７では、application#1、application#2、application#3にはそれぞれ200,128,200の起動優先度が与えられている。これらの起動優先度を付与することにより、PlayList#1、PlayList#2に対する制御要求が競合した場合の調停を行わせることができる。ここでapplication#1がPlayList#1に対し早送りを命じているものとする。一方、application#2がポーズ要求を行ったとする。この場合、アプリケーション管理テーブルに各アプリケーションに対する起動優先度が規定されているため、この起動優先度に従って、両アプリケーションに対する調停がなされることになる。その結果、application#2による要求を退け、application#1による制御を継続するという処理をオーサリング時に規定しておくことができる。起動優先度をプレイリスト管理テーブルと併せて利用することにより、プレイリストに対する制御が競合した場合の調停さえも再生装置に行わせることができる。
【００９９】
プレイリスト管理テーブル記述の他の具体例について説明する。図２８（ａ）は、プレイリスト管理テーブルの他の記述例を示す図である。本図で想定しているのは、2つの連続するタイトル(title#1、title#2)において、title#1側のプレイリスト管理テーブルには、AutoPlayプレイリストとしてPlayList#1が、再生可能なプレイリストとしてPlayList#2が記述され、title#1側のアプリケーション管理テーブルには、AutoPlayアプリケーションであるapplication#1と、実行可能なアプリケーションとしてapplication#2が記述されている。一方title#2側のプレイリスト管理テーブルには再生可能なプレイリストとしてPlayList#2、PlayList#3が記述され、アプリケーション管理テーブルには、AutoRunアプリケーションとしてapplication#3が記述されている。図２８（ｂ）は、図２８（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。title#1のアプリケーション管理テーブルには、AutoRunアプリケーションとしてapplication#1が記述されているので、title#1の開始時にはapplication#1が自動起動される。一方、title#1のアプリケーション管理テーブルには、実行可能アプリケーションとしてapplication#2が記述されているので、application#1からの呼出yd1によりapplication#2が起動される。
【０１００】
title#2側のアプリケーション管理テーブルにおいてapplication#1、application#2が非生存になっており、代わりにAutoRunアプリケーションとしてapplication#3が記述されている。そのためtitle#1−title#2の境界部では、application#1、application#2を停止し、application#3を自動的に起動するとの処理がなされる。プレイリスト管理テーブルを参照すると、title#1側のプレイリスト管理テーブルは、PlayList#1、PlayList#2が再生可能と記述されており、そのうちPlayList#1はAutoPlay属性になっている。そのためPlayList#1は、title#1の開始時において自動的に再生される。
【０１０１】
title#1側のプレイリスト管理テーブルには、PlayList#1の他、PlayList#2が再生可能であると記述されているので、application#1はPlayList#1の再生を停止させ、代わりにPlayList#2の再生を要求することにより、プレイリスト交代を実行することができる。
title#2側のプレイリスト管理テーブルには、再生可能なプレイリストとしてPlayList#2、PlayList#3が記述されている。そしてAutoPlay属性が付与されたプレイリストはない。そのため、仮にtitle#1開始時において自動再生されたPlayList#1の再生がtitle#2まで継続したとしても、PlayList#1の再生は自動的に終了することになる。
【０１０２】
しかしPlayList#2再生が継続したままtitle#2に至れば、PlayList#2再生はtitle#2開始以降も継続する。title#2のプレイリスト管理テーブルには、再生可能なプレイリストとしてPlayList#2、PlayList#3が記述されている。そのため、title#2で実行中となるapplication#3は、PlayList#2の再生を停止し、代わりにPlayList#3の再生を要求することにより、再生中のプレイリストを交代させることができる。  
【０１０３】
以上のようにプレイリスト管理テーブルの再生属性を、”AutoPlay”に設定しておけば、Java（登録商標）アプリケーションの起動に、5〜10秒という時間がかかったとしても、その起動がなされている間、”とりあえず何かが写っている状態”になる。タイトル実行開始時において、アプリケーション起動に時間がかかったとしても、画面は、”とりあえず何かが写っている状態”になる。これにより、アプリケーション起動に時間がかかることによるスタートアップディレイの長期化を補うことができる。
【０１０４】
アプリケーション管理テーブル及びプレイリスト管理テーブルを定義することにより、タイトル再生区間の進行に沿って、Java（登録商標）アプリケーションを動作させるという同期制御が可能になり、映像再生と、プログラム実行とを伴った、様々なアプリケーションを世に送り出すことができる。
＜サウンド管理テーブル＞
以降サウンド管理テーブル(SMT)について説明する。
【０１０５】
図２９は、サウンド管理テーブルの内部構成を示す図である。本図に示すようにサウンド管理テーブルは、Mixing_Onフラグを含む。Mixing_Onフラグとは、０又は１に設定されることにより、サウンドミキシングを有効とするか、無効とするかを示すフラグである。“有効”とは、オーディオストリームの再生音声に対してミキシングを行った上で出力することをいい、“無効”とは、オーディオストリームの再生音声をスルー出力することをいう。
【０１０６】
Mixing_Onフラグが1(ON)に設定された場合、ファイルsound.bdmvによるクリック音を、同じBD-J Objectに属するPLMTにて再生がなされるプレイリストの再生音声にミキシングする旨を示す。
Mixing_Onフラグが0(OFF)に設定された場合、ファイルsound.bdmvによるクリック音を、同じBD-J Objectに属するPLMTにて再生がなされるプレイリストの再生音声にミキシングしない旨を示す。
【０１０７】
ファイルsound.bdmvによるクリック音をミキシングするかどうかを、Java（登録商標）アプリケーションの生存区間の単位、つまりタイトルの単位で規定することができる。そして、このMixing_Onフラグをどのような値に設定するかは、そのプレイリストが有するSTN_Tableの設定内容に応じたものとなる。
図３０（ａ）（ｂ）は、STN_Tableにおけるオーディオストリームについてのentry-attributeと、Mixing_Onフラグの設定との因果関係を示す図である。図３０（ａ）において、entry-attributeにおけるaudio_presentation_typeが、“マルチチャネル”を示しているなら、Mixing_Onフラグは、0(OFF)に設定される。図３０（ｂ）において、entry-attributeにおけるaudio_presentation_typeが、“非マルチチャネル”を示しているなら、Mixing_Onフラグは、1(ON)に設定される。以上のような設定を行うことで、“マルチチャネル”の再生を行うようなプレイリスト(PlayItem)と、アプリケーションとを同時実行する場合、再生装置における音声再生とのミキシングを無効化することができ、“非マルチチャネル”の再生を行うようなプレイリスト(PlayItem)と、アプリケーションとを同時実行する場合、再生装置における音声再生とのミキシングを有効化することができる。
【０１０８】
以降、図２７（ａ）におけるサウンド管理テーブルの一例に対して、再生がどのように行われるかについて説明する。図２７（ａ）におけるTitle#1,#2のうち、Title#1のMixing_Onフラグは、音声再生とのミキシングを有効化する旨を示しており、Title#2におけるサウンド管理テーブル#2のMixing_Onフラグは、音声再生とのミキシングを無効化する旨を示しているものとする。
【０１０９】
更に、Title#1の再生時には、図２５のようなGUIフレームワークと、プレイリストの再生映像とが出力されたものとする。ユーザがリモコンを介して、図３１に示すように、このGUIフレームワークにおけるボタンを操作したものとする。この場合、このGUIフレームワークを描画したJava（登録商標）アプリケーションのアプリケーション管理テーブルと、同じBD-JObjectに属するサウンド管理テーブルが、Mixing_Onフラグ=1に設定されているなら、ファイルsound.bdmvにおけるサウンドデータが、プレイリストの再生音声にミキシングされる。
【０１１０】
ここでプレイリストの再生音声が、映画劇中のBGMであり、ファイルsound.bdmvにおけるサウンドデータが、「さあゲームを始めるよ!」という音声案内であれば、この映画劇中のBGMと、音声案内とがミキシングされて出力されることになる。
更に、Title#2の再生時には、図２５とは異なるGUIフレームワークと、プレイリストの再生映像とが出力されているものとする。そしてユーザがリモコンを介して、図３２に示すように、このGUIフレームワークにおけるボタンを操作したものとする。この場合、このGUIフレームワークを描画したJava（登録商標）アプリケーションのアプリケーション管理テーブルと、同じBD-JObjectに属するサウンド管理テーブルが、Mixing_Onフラグ=0に設定されているなら、ファイルsound.bdmvにおけるサウンドデータは、プレイリストの再生音声にミキシングされない。ここでプレイリストの再生音声が、映画劇中のマルチチャネルのBGMであれば、この映画劇中のBGMのみが出力されることになる。
【０１１１】
＜Mixing_Onフラグの意義＞
再生しようとしているAVClipに、5.1Chのサラウンド音声のオーディオストリームと、モノラル音声のオーディオストリームが多重化されていたとしても、PlayItemのSTN_Tableにおいて、そのモノラル音声のオーディオストリームの再生が許可され、5.1Chのサラウンド音声のオーディオストリームの再生が許可されていないような場合は、そのPlayItemに対応するMixing_OnフラグをONにして、クリックオンとのミキシングを実行することができる。こうすることにより、5.1Chのサラウンド音声のオーディオストリームと、モノラル音声のオーディオストリームとが同一のAVClipを構成したとしても、当該AVClipが5.1Chのサラウンド音声の再生を許していないPlayItemにて、再生されるような場合は、そのPlayItemの再生時におけるクリックオンのミキシングを実行することができる。
【０１１２】
以上のことを考えれば、クリックオンのミキシングを意図するようなタイトルと、ミキシングを意図しないようなタイトルとを、1つのBD-ROMに記録しようとする場合、5.1Chのサラウンド音声をもつAVClipと、モノラル音声をもつAVClipとを別々にBD-ROMに記録しておく必要がない。
5.1Chのサラウンド音声と、モノラル音声とが多重化されたAVClipを1つだけ、BD-ROMに記録しておき、5.1Chのサラウンド音声のオーディオストリームの再生が許可しているPlayItem情報と、5.1Chのサラウンド音声のオーディオストリームの再生が許可していないPlayItem情報とを記録しておけば、クリックオンのミキシングを意図するようなタイトルと、ミキシングを意図しないようなタイトルとを、1つのBD-ROMにて供給することができる。
【０１１３】
AVClipの数を多くすることなく、クリックオンのミキシングを意図せず、音響面の充実を意図したタイトル、クリックオンのミキシングを意図して、対話面の充実を意図したタイトルの双方を制作して、ユーザに供給することができるので、制作スタジオの手間が少なく、映画制作の効率化を図ることができる。
＜Movie Object、Java（登録商標）アプリとの関係＞
HDMVモードにおけるMovie Objectに、クリック音の発音を意図したようなナビゲーションコマンドが組み込まれておらず、BD-JモードにおけるJava（登録商標）アプリケーションに、クリック音の発音を意図しているようなバイトコードが組み込まれていない場合、つまり、アプリケーションがクリック音の再生を行わないことが明らかである場合、Mixing_Onフラグは、0(OFF)に設定される。逆にクリック音の発音を意図したようなナビゲーションコマンドやバイトコードが存在する場合、Mixing_Onフラグは、1(ON)に設定される。以上のような設定を行うことで、クリック音の再生を行わないアプリケーションと、オーディオの再生を行うようなPlayItemとを同時実行する場合、再生装置におけるミキシングを無効化することができ、クリック音の再生を行うアプリケーションと、オーディオの再生を行うようなPlayItemとを同時実行する場合、再生装置におけるミキシングを有効化することができる。
以上が記録媒体についての説明である。続いて本発明に係る再生装置について説明する。
【０１１４】
図３３は、本発明に係る再生装置の内部構成を示す図である。本発明に係る再生装置は、本図に示す内部に基づき、工業的に生産される。本発明に係る再生装置は、主としてシステムLSIと、ドライブ装置という2つのパーツからなり、これらのパーツを装置のキャビネット及び基板に実装することで工業的に生産することができる。システムLSIは、再生装置の機能を果たす様々な処理部を集積した集積回路である。こうして生産される再生装置は、BD-ROMドライブ１、リードバッファ２、デマルチプレクサ３、ビデオデコーダ４、ビデオプレーン５、サウンドプロセッサ６、サウンドプロセッサ７、ミキサー８、サウンドコントローラ９、D/Aコンバータ１０、InteractiveGraphicsデコーダ１１、Interactive Graphicsプレーン１２、Presentation Graphicsデコーダ１３、PresentationGraphicsプレーン１４、JPEGデコーダ１５、Stillプレーン１６、合成部１７、STC-delta付加部１８、ATC-delta付加部１９、ローカルストレージ２０、命令ROM２１、ユーザイベント処理部２２、PSRセット２３、CPU２４、シナリオメモリ２５、ローカルメモリ２６から構成される。
【０１１５】
先ず初めに、BD-ROMに記録されたAVClip再生に係る構成要素(BDドライブ１〜オーディオデコーダ６)について説明する。
BD-ROMドライブ１は、BD-ROMのローディング／イジェクトを行い、BD-ROMに対するアクセスを実行する。
リードバッファ２は、FIFOメモリであり、BD-ROMから読み出されたTSパケットが先入れ先出し式に格納される。
【０１１６】
デマルチプレクサ(De-MUX)３は、リードバッファ２からSourceパケットを取り出して、このSourceパケットを構成するTSパケットをPESパケットに変換する。そして変換により得られたPESパケットのうち、STN_Tableに記載されたからPIDをもつものをビデオデコーダ４、オーディオデコーダ６、InteractiveGraphicsデコーダ１１、Presentation Graphicsデコーダ１３のどれかに出力する。
【０１１７】
ビデオデコーダ４は、デマルチプレクサ３から出力された複数PESパケットを復号して非圧縮形式のピクチャを得てビデオプレーン５に書き込む。
ビデオプレーン５は、非圧縮形式のピクチャを格納しておくためのプレーンである。プレーンとは、再生装置において一画面分の画素データを格納しておくためのメモリ領域である。ビデオプレーン５における解像度は1920×1080であり、このビデオプレーン５に格納されたピクチャデータは、16ビットのYUV値で表現された画素データにより構成される。ビデオプレーン５では、ビデオストリームにおける一フレーム毎の再生映像を、スケーリングすることができる。スケーリングとは、一フレーム毎の再生画像をビデオプレーン５全体の1/4(クオータという)、1/1(フルスケールという)のどちらかに変化させることである。かかるスケーリングを、BD-JモードにおいてCPU２４からの指示に従い実行するので、ビデオストリームの再生画像を、画面の隅に追いやったり、全面的に出すという画面演出が可能になる。
【０１１８】
サウンドプロセッサ６は、オーディオストリームを構成するPESパケットをPIDフィルタ３が出力した際、このPESパケットを格納しておくデコードバッファ(DB)６aと、このバッファに格納されたPESパケットをデコーダして、PCM状態のオーディオデータを出力するオーディオデコーダ６bとを含む。
サウンドプロセッサ７は、BD-ROMから読み出されたファイルsound.bdmvをプリロードしておくプリロードメモリ７aと、プリロードされたファイルsound.bdmvにおける複数のサウンドデータのうち、CPU２４により指示されたものをデコードして、PCM状態のオーディオデータを出力するオーディオデコーダ７bとを含む。プリロードバッファ７aへのプリロードは、BD-ROMの装填時やタイトル切替時に行うことが望ましい。何故なら、AVClipの再生中にファイルsound.bdmvを読み出そうとすると、AVClipとは別のファイルを読み出すための光ピックアップのシークが発生するからである。一方、BD-ROMの装填時やタイトル切替時には、AVClipの再生が継続していることは希なので、かかるタイミングにファイルsound.bdmvを読み出すことにより、AVClip再生が途切れないことを、保証することができる。
【０１１９】
サウンドミキサ８は、サウンドプロセッサ６、及び、サウンドプロセッサ７から出力されるPCM状態のサウンドデータをミキシングする。ミキシングにあたってサウンドミキサ８はサンプリング周波数とチャネル数を合わせるため、サウンドプロセッサ６から出力された音声の属性を、サウンドプロセッサ７からから出力される音声属性に変換するとの処理を行う。このサウンドミキサ８によるミキシングは、クリック音の発音を意図したようなナビゲーションコマンド、又は、クリック音の発音を意図したようなバイトコードを、CPU２４が解読することでなされる。
【０１２０】
サウンドコントローラ９は、サウンドミキサ８から出力された展開された状態のオーディオデータ、及び、サウンドプロセッサ６を介さずに圧縮された状態のオーディオデータのうち、どちらを出力するか切り換える。この音声出力は、S/PDIF又はHDMIを介して、テレビ４００又はアンプ５００に出力される。圧縮された状態のオーディオデータを出力する場合は、その出力先のテレビ４００及びアンプ５００においてデコードされる。
【０１２１】
D/A変換部１０は、サウンドミキサ８から出力されるディジタルのオーディオデータをD/A変換して、アナログ音声を出力する。
I-Graphicsデコーダ(IGデコーダ)１１は、BD-ROM又はローカルストレージ２０から読み出されたIGストリームをデコードして、非圧縮グラフィクスをInteractiveGraphicsプレーン１２に書き込む。
【０１２２】
Interactive Graphics(IG)プレーン１２は、HDMVモードにおいてI-Graphicsデコーダ１０によるデコードで得られた非圧縮グラフィクスが書き込まれる。またBD-Jモードにおいて、アプリケーションにより描画された文字やグラフィクスが書き込まれる。
P-Graphicsデコーダ１３は、BD-ROM又はローカルストレージ２０から読み出されたPGストリームをデコードして、非圧縮グラフィクスをPresentationGraphicsプレーン１１に書き込む。P-Graphicsデコーダ１３によるデコードにより、字幕が画面上に現れることになる。
【０１２３】
Presentation Graphicsプレーン１４は、一画面分の領域をもったメモリであり、一画面分の非圧縮グラフィクスを格納することができる。
JPEGデコーダ１５は、BD-ROM又はローカルストレージ２０に記録されているJPEGデータをデコードして、Stillプレーン１６に書き込む。
Stillプレーン１６は、JPEGデータを展開することで得られた非圧縮のグラフィクスデータが格納されるプレーンである。このグラフィクスデータは、Java（登録商標）アプリが描画する、GUIフレームワークのいわゆる“壁紙”として用いられる。
【０１２４】
合成部１７は、Interactive Graphicsプレーン１２の格納内容と、Presentation Graphicsプレーン１１の格納内容と、ビデオプレーン５の格納内容と、Stillプレーン１６の格納内容とを合成した合成画像を得る。
STC_delta付加部１８は、System Time Clock(STC)を生成する。そしてSTC_Seuenceの切り換わり時において、それまでのSTC_SeuenceにおけるSTC値(STC1)に、STC_deltaと呼ばれるオフセット値を加算することにより、新しいSTC_SeuenceのSTC値(STC2)を求めて、それまでのSTC_SeuenceにおけるSTC値(STC1)と、新しいSTC_SeuenceのSTC値(STC2)とを連続した値にする。
【０１２５】
先行STC_Seuenceにおいて最後に再生されるピクチャの表示開始時刻をPTS1(1stEND)、ピクチャの表示期間をTppとし、後続STC_Seuenceにおいて最初に表示されるピクチャの開始時刻をPTS2(2ndSTART)とした場合、STC_deltaは
STC_delta＝PTS1(1stEND)＋Tpp−PTS2(2ndSTART)
として表現される。以上のようにSTC_deltaを求め、これが足し合わされたクロックの計数値を各デコーダに出力する。これにより各デコーダは、2つのSTC_Seuenceにあたるストリームを途切れなく再生してゆくことができる。以上により、1つのAVClipの中に、2以上のSTC_Seuenceが存在したとしても、また、連続して再生されるべき2以上のAVClipのそれぞれが、異なるSTC_Seuenceをもっていたとしても、これらのSTC_Seuence間のデコード処理を、シームレスに実行することができる。
【０１２６】
また、バッファリングの連続性をみたすには、以下の1),2)を満たせば良い。
1) STC2(2ndSTART)＞STC2(1stEND)をみたすこと、
ここでSTC2(1stEND)は、STC1(1stEND)を、STC2の時間軸に投影した値であり、STC2(1stEND)=STC1(1stEND)-STC_deltaという計算式で与えられる。
2) TS1からのTSパケットの取り出しと、TS2からのTSパケットの取り出しとが、同じ時間軸に投影されたSTC1と、STC2とにより定義され、バッファのアンダーフローや、オーバーフローをもたらさないこと。
ATC_delta付加部１９は、Arrival Time Clock(ATC)を生成する。そしてATC_Seuenceの切り換わり時において、それまでのATC_SeuenceにおけるATC値(ATC1)に、ATC_deltaと呼ばれるオフセット値を加算することにより、それまでのATC_SeuenceにおけるATC値(ATC1)と、新しいATC_SeuenceのATC値(ATC2)とを連続した値にする。この加算により、ATC2=ATC1+ATC_deltaになる。ATC_deltaとは、これまで読み出されているトランスポートストリーム(TS1)の最後のTSパケットの入力時点T1から、新たに読み出されたトランスポートストリーム(TS2)の最初のTSパケットの入力時点T2までのオフセット値をいい、“ATC_delta≧N1/TS_recording_rate”という計算式で与えられる。ここで入力時点T2は、TS2の最初のTSパケットの入力時点を、TS1の時間軸上に投影した時点を意味する。またN1は、TS1の最後のビデオPESパケットに後続する、TSパケットのパケット数である。BD-ROMにおいてかかるATC_deltaは、Clip情報に記述されるので、これを用いることにより、ATC_deltaを計算することができる。以上の計算により、これまでのATC_SeuenceがもっているATC値(ATC1)と、新たなATC_SeuenceがもっているATC値(ATC2)とを、連続した値にすることができる。ATC_deltaが足し合わされたクロックの計数値をデマルチプレクサ(De-MUX)３に出力することで、シームレスなバッファ制御を実現することができる。
以上がAVClip再生に係る構成要素である。続いてBD-Jモードでの動作に係る構成要素(ローカルストレージ２０〜ローカルメモリ２６)について説明する。
【０１２７】
ローカルストレージ２０は、webサイトからダウンロードされたコンテンツ等、BD-ROM以外の記録媒体、通信媒体から供給されたコンテンツを、メタデータと共に格納しておくためのハードディスクである。このメタデータは、ダウンロードコンテンツをローカルストレージ２０にバインドして管理するための情報であり、このローカルストレージ２０をアクセスすることで、BD-Jモードにおけるアプリケーションは、ダウンロードコンテンツ長さを利用した様々な処理を行うことができる。
【０１２８】
続いて、再生装置における統合制御を実現する構成要素(命令ROM２１〜ローカルメモリ２６)について説明する。
命令ROM２１は、再生装置の制御を規定するソフトウェアを記憶している。
ユーザイベント処理部２２は、リモコンや再生装置のフロントパネルに対するキー操作に応じて、その操作を行うユーザイベントをCPU２４に出力する。
【０１２９】
PSRセット２３は、再生装置に内蔵されるレジスタであり、64個のPlayer Status Register(PSR)と、4096個のGeneralPurpose Register（GPR)とからなる。Player Status Registerの設定値(PSR)のうち、PSR4〜PSR8は、現在の再生時点を表現するのに用いられる。
PSR4は、1〜100の値に設定されることで、現在の再生時点が属するタイトルを示し、0に設定されることで、現在の再生時点がトップメニューであることを示す。
【０１３０】
PSR5は、1〜999の値に設定されることで、現在の再生時点が属するチャプター番号を示し、0xFFFFに設定されることで、再生装置においてチャプター番号が無効であることを示す。
PSR6は、0〜999の値に設定されることで、現在の再生時点が属するプレイリスト(カレントPL)の番号を示す。
【０１３１】
PSR7は、0〜255の値に設定されることで、現在の再生時点が属するPlayItem(カレントPlay Item)の番号を示す。
PSR8は、0〜OxFFFFFFFFの値に設定されることで、45KHzの時間精度を用いて現在の再生時点(カレントPTM(PresentationTiMe))を示す。以上のPSR4〜PSR8により、図１８（ａ）におけるBD-ROM全体の時間軸において、現在の再生時点はどこであるかを特定することができる。
【０１３２】
CPU２４は、命令ROM２１に格納されているソフトウェアを実行して、再生装置全体の制御を実行する。この制御の内容は、ユーザイベント処理部２２から出力されたユーザイベント、及び、PSRセット２３における各PSRの設定値に応じて動的に変化する。
シナリオメモリ２５は、カレントのPL情報やカレントのClip情報を格納しておくためのメモリである。カレントPL情報とは、BD-ROMに記録されている複数プレイリスト情報のうち、現在処理対象になっているものをいう。カレントClip情報とは、BD-ROMに記録されている複数Clip情報のうち、現在処理対象になっているものをいう。
【０１３３】
ローカルメモリ２６は、BD-ROMからの読み出しは低速である故、BD-ROMの記録内容を一時的に格納しておくためのキャッシュメモリである。かかるローカルメモリ２６が存在することにより、BD-Jモードにおけるアプリケーション実行は、効率化されることになる。
以上が、本実施形態に係る再生装置のハードウェア構成である。続いて本実施形態に係る再生装置のソフトウェア構成について説明する。  
図３４は、ROM２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。本図に示すように、再生装置のレイア構成は、以下のa),b),c)からなる。つまり、
a)BD Player Deviceの第１階層、
b)BD Player Modelの第２階層、
c)Application Runtime Enviromentの第３階層からなる。
これらの階層のうち図３４に示した再生装置のハードウェア構成は、第１階層に属することになる。本図の第１階層”BD Player Device”には、図３４に示したハードウェア構成のうちビデオデコーダ４、オーディオデコーダ６、IGデコーダ１１、PGデコーダ１３にあたる”デコーダ”と、ビデオプレーン５、IGプレーン１２、PGプレーン１４にあたる”プレーン”、BD-ROM及びそのファイルシステム、ローカルストレージ２０及びそのファイルシステムを含む。
【０１３４】
第２階層”BD Player Model”は、以下のb1),b2)の層からなる。つまり、
b2)Playback Control Engine３２の層
b1)Virtual File System３０及びPresentation Engine３１の層
からなり、自身より上位の階層に対し、ファンクションAPIを提供する。
第３階層”Application Runtime Enviroment”は、以下のc1),c2)の階層からなる。つまり、
c1)モジュールマネージャ３４が存在する層、
c2)BD-Jプラットフォーム３５が存在する層
からなる。
先ず初めに、第２層に属するVirtual File System３０〜モジュールマネージャ３４について説明する。
【０１３５】
Virtual File System３０は、ローカルストレージ２０に格納されたダウンロードコンテンツを、BD-ROMにおけるディスクコンテンツと一体的に取り扱うための仮想的なファイルシステムである。ここでローカルストレージ２０に格納されたダウンロードコンテンツは、SubClip、Clip情報、プレイリスト情報を含む。このダウンロードコンテンツにおけるプレイリスト情報はBD-ROM及びローカルストレージ２０のどちらに存在するClip情報であっても、指定できる点で、BD-ROM上のプレイリスト情報と異なる。この指定にあたって、VirtualFile System３０上のプレイリスト情報は、BD-ROMやローカルストレージ２０におけるファイルをフルパスで指定する必要はない。BD-ROM上のファイルシステムやローカルストレージ２０上のファイルシステムは、仮想的な1つのファイルシステム(VirtualFile System３０)として、認識されるからである。故に、PlayItem情報におけるClip_Information_file_nameは、Clip情報の格納したファイルのファイルボデイにあたる5桁の数値を指定することにより、VirtualFile System３０、BD-ROM上のAVClipを指定することができる。Virtual File System３０を介してローカルストレージ２０の記録内容を読み出し、BD-ROMの記録内容と動的に組み合わせることにより、様々な再生のバリエーションを産み出すことができる。ローカルストレージ２０と、BD-ROMとを組合せてなるディスクコンテンツは、BD-ROMにおけるディスクコンテンツと対等に扱われるので、本願における”BD-ROM”は、ローカルストレージ２０＋BD-ROMの組合せからなる仮想的な記録媒体をも含むことにする。
【０１３６】
Presentation Engine３１は、AV再生ファンクションを実行する。再生装置のAV再生ファンクションとは、DVDプレーヤ、CDプレーヤから踏襲した伝統的な機能群であり、再生開始(Play)、再生停止(Stop)、一時停止(PauseOn)、一時停止の解除(Pause Off)、Still機能の解除(still off)、速度指定付きの早送り(Forward Play(speed))、速度指定付きの巻戻し(BackwardPlay(speed))、音声切り換え(Audio Change)、副映像切り換え(Subtitle Change)、アングル切り換え(AngleChange)といった機能である。AV再生ファンクションを実現するべく、Presentation Engine３１は、リードバッファ２上に読み出されたAVClipのうち、所望に時刻にあたる部分のデコードを行うよう、ビデオデコーダ４、P-Graphicsデコーダ１３、I-Graphicsデコーダ１０、オーディオデコーダ６を制御する。所望の時刻としてPSR8(カレントPTM)に示される箇所のデコードを行わせることにより、AVClipにおいて、任意の時点を再生を可能することができる。
【０１３７】
再生制御エンジン(Playback Control Engine(PCE))３２は、プレイリストに対する再生制御ファンクション(i)、PSRセット２３における状態取得／設定ファンクション(ii)といった諸機能を実行する。プレイリストに対する再生制御ファンクションとは、PresentationEngine３１が行うAV再生ファンクションのうち、再生開始や再生停止を、カレントPL情報及びClip情報に従って行わせることをいう。これら機能(i)〜(ii)は、HDMVモジュール３３〜BD-Jプラットフォーム３５からのファンクションコールに応じて実行する。
【０１３８】
モジュールマネージャ３４は、BD-ROMから読み出されたIndex.bdmvを保持して、分岐制御を行う。この分岐制御は、カレントタイトルを構成する動的シナリオにTerminateイベントを発行し、分岐先タイトルを構成する動的シナリオにActivateイベントを発行することでなされる。
以上がPresentation Engine３１〜モジュールマネージャ３４についての説明である。続いてBD-Jプラットフォーム３５について説明する。
【０１３９】
BD-Jプラットフォーム３５は、いわゆるJava（登録商標）プラットフォームであり、Java（登録商標）仮想マシン３６を中核にした構成になっている。BD-Jプラットフォーム３５は、上述したJava（登録商標）2Micro_Edition(J2ME)Personal Basis Profile(PBP 1.0)と、Globally Executable MHPspecification(GEM[1.0.2])for package media targetsに加え、BD-J Extentionを実装している。BD-JExtentionは、GEM[1.0.2]を越えた機能を、BD-Jプラットフォームに与えるために特化された、様々なパッケージを含んでいる。
【０１４０】
先ず初めに、BD-Jプラットフォーム３５の中核となるJava（登録商標）仮想マシン３６について説明する。
＜Java（登録商標）仮想マシン３６＞
図３５は、Java（登録商標）仮想マシン３６の内部構成を示す図である。本図に示すようにJava（登録商標）仮想マシン３６は、図３３に示したCPU２４と、ユーザクラスローダ５２、メソッドエリア５３、ワークメモリ５４、スレッド５５a,b・・・n、Java（登録商標）スタック５６a,b・・・nとから構成される。
【０１４１】
ユーザクラスローダ５２は、BDJAディレクトリのJava（登録商標）アーカイブファイルにおけるクラスファイルをローカルメモリ２６等から読み出してメソッドエリア５３に格納する。このユーザクラスローダ５２によるクラスファイル読み出しは、ファイルパスを指定した読み出しをアプリケーションマネージャ３７がユーザクラスローダ５２に指示することでなされる。ファイルパスがローカルメモリ２６を示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するJava（登録商標）アーカイブファイルにおけるクラスファイルを、ローカルメモリ２６からワークメモリ５４に読み出す。ファイルパスがVirtualFile System３０上のディレクトリを示しているなら、ユーザクラスローダ５２は、アプリケーションを構成するJava（登録商標）アーカイブファイルにおけるクラスファイルを、BD-ROM又はローカルストレージ２０からワークメモリ５４に読み出す。アプリケーションの起動制御は、このユーザクラスローダ５２によるクラスファイル読み出しにより実現される。読み出しが指示されたクラスファイルがローカルメモリ２６にない場合、ユーザクラスローダ５２は読み出し失敗をアプリケーションマネージャ３７に通知することになる。
【０１４２】
メソッドエリア５３は、ユーザクラスローダ５２によりローカルメモリ２６から読み出されたクラスファイルが格納される。
ワークメモリ５４は、いわゆるヒープエリアであり、様々なクラスファイルのインスタンスが格納される。図３４に示したアプリケーションマネージャ３７は、このワークメモリ５４に常駐するレジデントアプリケーションである。ワークメモリ５４には、これらレジデント型のインスタンスの他に、メソッドエリア５３に読み出されたクラスファイルに対応するインスタンスが格納される。このインスタンスが、アプリケーションを構成するxletプログラムである。かかるxletプログラムをワークメモリ５４に配置することによりアプリケーションは実行可能な状態になる。
【０１４３】
図３４のレイアモデルでは、このワークメモリ５４上のアプリケーションマネージャ３７を、Java（登録商標）仮想マシン３６上に描いていたが、これはわかり易すさを意図した配慮に過ぎない。アプリケーションマネージャ３７及びアプリケーションはインスタンスとしてスレッド５５a,b・・・nにより実行されるというのが、現実的な記述になる。
スレッド５５a,b・・・nは、ワークメモリ５４に格納されたメソッドを実行する論理的な実行主体であり、ローカル変数や、オペランドスタックに格納された引数をオペランドにして演算を行い、演算結果を、ローカル変数又はオペランドスタックに格納する。図中の矢印ky1,ky2,kynは、ワークメモリ５４からスレッド５５a,b・・・nへのメソッド供給を象徴的に示している。物理的な実行主体がCPU唯1つであるのに対し、論理的な実行主体たるスレッドは、最大64個Java（登録商標）仮想マシン３６内に存在し得る。この64個という数値内において、スレッドを新規に作成することも、既存のスレッドを削除することも可能であり、スレッドの動作数は、Java（登録商標）仮想マシン３６の動作中において増減し得る。スレッドの数は適宜増やすことができるので、複数スレッドにより1つのインスタンスの並列実行を行い、インスタンスの高速化を図ることもできる。本図ではCPU２４と、スレッドとの対応関係は、1対多の関係にしているが、CPUが複数ある場合、CPUとスレッドとの対応関係は多対多の関係になりうる。スレッド５５a,b・・・nによるメソッド実行は、メソッドをなすバイトコードを、CPU２４のネイティブコードに変換した上、CPU２４に発行することでなされる。このネイティブコード変換については、本願の主眼から外れるため、説明を省く。
【０１４４】
Java（登録商標）スタック５６a,b・・・nは、スレッド５５a,b・・・nと1対1の比率で存在しており、プログラムカウンタ(図中のPC)と、1つ以上のフレームとを内部に持つ。”プログラムカウンタ”は、インスタンスにおいて、現在どの部分が実行されているかを示す。”フレーム”はメソッドに対する1回のコールに対して割り当てられたスタック式の領域であり、その1回のコール時の引数が格納される”オペランドスタック”と、コールされたメソッドが用いる”ローカル変数スタック(図中のローカル変数)”とからなる。フレームは、コールが1回なされる度にJava（登録商標）スタック５６a,b・・・n上に積み上げられるのだから、あるメソッドが自身を再帰的に呼び出す場合も、このフレームは、1つ積み上げられることになる。
【０１４５】
以上がJava（登録商標）仮想マシンについての説明である。
＜アプリケーションマネージャ３７＞
アプリケーションマネージャ３７は、Java（登録商標）仮想マシン３６内のワークメモリ上で動作するシステムソフトウェアであり、タイトル分岐が発生する度に、分岐前タイトルでは実行されていないが、新たなタイトルではAutoRunの起動属性を有するアプリケーションを起動するようJava（登録商標）仮想マシン３６に指示する。それと共に、分岐前タイトルでは実行されていたが、新たなタイトルを生存区間としないアプリケーションを終了させる。これら起動制御及び終了制御は、カレントBD-JObjectにおけるアプリケーション管理テーブルを参照した上でなされる。
【０１４６】
図３６は、BD-J Objectにおけるアプリケーション管理テーブルに基づく、アプリケーションマネージャ３７の処理を示す図である。
図３６における☆1,☆2,☆3は、アプリケーション管理テーブル参照(☆1)、Java（登録商標）仮想マシン３６に対するアプリケーション起動指示(☆2)、Java（登録商標）仮想マシン３６による、Java（登録商標）アーカイブファイルに対する読み出し指示(☆3)、Java（登録商標）アプリケーションを定義するクラスファイルのクラスロード(☆4,5,6)という一連の過程を模式化して示す。この起動指示によりJava（登録商標）仮想マシン３６は、ローカルメモリ２６からワークメモリにxletプログラムを読み出す。
【０１４７】
図３７は、BD-J ObjectにおけるPLMTに基づく、アプリケーションマネージャ３７の処理を示す図である。▽1は、BD-J ObjectにおけるPLMTの参照を示し、▽2は、PresentationEngine３１に対するプレイリスト情報の読み出し指示を示す。
図３７における◎1,2,3,4は、Virtual File System３０経由のプレイリスト情報読み出し(◎1)、プレイリスト情報を構成するPlayItem情報の解読(◎2)、VirtualFile System３０経由のClip情報読み出し(◎3)、Clip情報の解読(◎4)を模式化したものである。以上の過程を経てClip情報、プレイリスト情報が解読されれば、AVClipを構成するTSパケットを、VirtualFile System３０を通じてPresentation Engine３１に引き渡す。このようにしてPresentation Engine３１にTSパケットが順次渡れば、PresentationEngine３１はAVClipを構成するTSパケットをデコーダに出力して、プレーンに表示させる。図中の☆1,2,3,4は、AVClipを構成するTSパケットの読み出し(☆1,2)、VirtualFile System３０からPresentation Engine３１へのTSパケット引き渡し(☆3)、デコーダへのTSパケット投入(☆4)、デコーダから各種プレーンへのデコード結果出力(☆5)を模式的に示している。
【０１４８】
図３８は、BD-J Objectにおけるサウンド管理テーブルに基づく、アプリケーションマネージャ３７の処理を示す図である。図３８における◎0.1,2は、アプリケーションマネージャ３７によるBD-JObject内のサウンド管理テーブルの参照(◎0)、アプリ生存区間毎のサウンドミキシングの有効化、無効化の指示(◎1)。操作されたボタンに対応するサウンドデータの、出力指示又はデコード指示(◎2)を模式的に示したものである。
【０１４９】
以降、ソフトウェアによるアプリケーションマネージャ３７の実装について説明する。図３９は、アプリケーションマネージャ３７による処理手順を示すフローチャートである。本図における処理手順は、ステップＳ１−ステップＳ２−ステップＳ３−ステップＳ４からなるメインループを有している。ステップＳ１は、TitleJumpがなされたか否かの判定であり、もしなされればTitle切り換えを行う(ステップＳ７)。
【０１５０】
ステップＳ８は、カレントタイトルに対応するBD-JObjectに、PLMTが存在するか否かの判定である。もし存在しないのであれば、前のタイトルでは、PLMTに記載されていたプレイリストの再生を停止させる(ステップＳ９)。
もし存在するのであれば、前のタイトルではPLMTに記載されていなかったが、カレントタイトルでは、PLMTに記載されており、AutoPlay属性が付与されているプレイリストの再生を開始させる(ステップＳ１０)。
【０１５１】
ステップＳ１１では、カレントTitleに対応するBD-JObjectに、サウンド管理テーブルが存在するか否かの判定を行う。ステップＳ１２は、サウンド管理テーブルが存在する場合に実行される判定ステップであり、そのサウンド管理テーブルにおけるMixing_Onフラグが1であるか否かの判定を行う。もしMixing_Onフラグが1であるなら、サウンドミキシングを有効化するようサウンドコントローラ９に指示し(ステップＳ１３)、もしMixing_Onフラグが0であるなら、サウンドミキシングを無効化するようサウンドコントローラ９に指示する(ステップＳ１４)。
【０１５２】
ステップＳ１５は、カレントTitleに対応するBD-JObjectにアプリケーション管理テーブルが存在するか否かの判定であり、もし存在するなら、前のTitleを生存区間としていないが、カレントTitleを生存区間としているJava（登録商標）アプリケーションであって、AutoRun属性を有するものを起動する(ステップＳ１６)。もし存在しないなら、前のTitleを生存区間としているが、カレントTitleを生存区間としていないアプリを停止する(ステップＳ１７)。
【０１５３】
その後、Java（登録商標）アプリケーションの起動に成功したか否かの判定を行い(ステップＳ１８)、起動に成功すれば(ステップＳ１８でYes)、AutoPlayPLの再生画像をクオータ(1/4)に変換する(ステップＳ１９)という手順を実現するものである。
一方このステップＳ１８がNoであればステップＳ２３、Ｓ２４、Ｓ１６、Ｓ１８からなるループ処理を実行することになる。本ループ処理における制御変数は、再起動カウンタである。再起動カウンタは、アプリケーションの再起動回数を規定するカウンタである。本再起動カウンタは、本フローチャートの起動時にリセットされ、ステップＳ２３において、0か否かの判定がなされる。0でない場合、ステップＳ２４において再起動カウンタはデクリメントされる。以上のステップＳ２３、Ｓ２４、Ｓ１６、Ｓ１８〜ステップＳ１９からなるループ処理により、再起動カウンタが0でない限り、AutoRunアプリケーションの起動は繰り返されることになる。かかる繰り返しにより、アプリケーションの起動が保証されることになる。
【０１５４】
ステップＳ２は、メインとなるアプリケーションが実行されてない状態かどうかの判定であり、もしそうであれば、ステップＳ５の判定を行う。ステップＳ５は、アプリケーションが正常終了したかの判定である。もし異常終了していればステップＳ２１、ステップＳ２２の処理を実行する。正常終了していればステップＳ２１〜ステップＳ２２を実行せず、ステップＳ１〜ステップＳ４からなるメインループに戻る。
【０１５５】
ステップＳ２１は、AutoPlayPLの再生中であるか否かの判定であり、もし再生中なら、AutoPlayPLの再生画像をフルスクリーン化するようPlaybackControl Engine３２に指示する(ステップＳ２２)。その後、ステップＳ２３に移行する。ステップＳ２３への移行により、異常終了時においてもステップＳ１４〜ステップＳ１７からなるループ処理が実行されることになる。これにより再起動カウンタの回数が0になるまで、アプリケーションの再起動は繰り返されることになる。
【０１５６】
ステップＳ４は、BDドライブ１にBD-ROMが存在しているか否かの判定であり、もしBD-ROMが存在しなければ、全てのアプリケーションに対し、終了指示を発する(ステップＳ６)。
以上のように本実施形態によれば、マルチチャネルでの音声出力を意図するような再生制御の実行時にはサウンドミキシングを無効化しておき、マルチチャネルでの音声出力を意図しないような再生制御の実行時にはサウンドミキシングを有効化しておくことができる。
【０１５７】
これにより、映画の制作スタジオは、マルチチャネルでの再生を意図している場合は、クリック音を禁止し、代わりにクリック音での再生を意図している場合は、代わりにマルチチャネルによる音声出力を禁止するという調整が可能になる。
クリック音の導入により“マルチチャネルの音声出力が途切れるのではないか”という不安の呪縛から、制作スタジオを解放することができるので、映画作品作成にあたってのクリック音の導入に弾みをつけることができる。
【０１５８】
尚、第１実施形態では、マルチチャネルが5.1CHのサラウンド音声であり、オーディオストリームがこのマルチチャネルの属性を有している場合、Mixing_OnフラグをOFFにすると説明したが、マルチチャネルが2CHのステレオ音声を意味し、オーディオストリームがステレオ属性を有している場合、Mixing_OnフラグをOFFにしてもよい。
ステレオ音声を展開した後のデータ量はそれ程大きい訳ではなく、LPCM状態に展開した後に、サウンドミキシングを行っても、デジタル出力が可能になることもある。このように、ステレオ音声の展開後のデータ量はそれ程大きくないと期待でき、デジタル出力が可能であることは確認し得た場合、マルチチャネルをONに設定してもよい。
(第２実施形態)
第１実施形態では、プレイリストの自動再生がなされたアプリケーションの生存区間毎にMixing_Onフラグを設けたが、これは見方を変えると、プレイリストと、アプリケーション生存区間とが等価であり、プレイリストを構成する再生区間毎に、Mixing_Onフラグによる制御が及ぶと考えることができる。
これらに鑑み、本実施形態ではMixing_Onフラグをプレイリスト情報に設ける技術を提案する。
【０１５９】
図４０（ａ）は、第２実施形態に係るプレイリスト情報の内部構成を示す図である。本図が、図８（ａ）に示したプレイリスト情報の内部構成と異なるのは、PlayItem情報内にMixing_Onフラグが設けられている点である。図４０（ｂ）は、PlayItem情報内に設けられた、Mixing_Onフラグの内容を示す図である。
Mixing_Onフラグが1に設定された場合、ファイルsound.bdmvによるクリック音を、PlayItemの再生音声にミキシングする旨を示す。
【０１６０】
Mixing_Onフラグが0に設定された場合、ファイルsound.bdmvによるクリック音を、PlayItemの再生音声にミキシングしない旨を示す。
ファイルsound.bdmvによるクリック音をミキシングするかどうかを、プレイリストの単位で規定することができる。そして、このMixing_Onフラグをどのような値に設定するかは、そのPlayItem情報が有するSTN_Tableの設定内容に応じたものとなる。
【０１６１】
以上が、第２実施形態に係る記録媒体の改良である。続いて第２実施形態に係る再生装置の改良について説明する。第２実施形態に係る再生装置の改良点は、PlaybackControl Engine３２に存在する。
以降図４１のフローチャートを参照して、Playback Control Engine３２による具体的な制御手順を説明する。
【０１６２】
図４１は、Playback Control Engine３２によるプレイリスト再生手順を示すフローチャートである。この再生手順は、PresentationEngine３１に対する制御(ステップＳ１０６)と、BD-ROMドライブ１又はローカルストレージ２０に対する制御(ステップＳ１０８)とを主に含む。本フローチャートにおいて処理対象たるPlayItemをPlayItem#xとする。本フローチャートは、カレント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ドライブ１又はローカルストレージ２０に命じるというものである(ステップＳ１０８)。
【０１６４】
一方、Presentation Engine３１に対しては、カレントPLMarkのmark_time_stampからPlayItem#xのOut_timeまでの出力を命じる(ステップＳ１０６)。以上のステップＳ１０５〜ステップＳ１０８により、AVClipにおいて、PlayItem#xにより指示されている部分の再生がなされることになる
その後、PlayItem#xがカレントプレイリストの最後のPIであるかの判定がなされる(ステップＳ１０９)。
【０１６５】
PlayItem#xがカレントプレイリストの最後のPIでなければ、カレントプレイリストにおける次のPlayItemを、PlayItem#xに設定して(ステップＳ１１０)、ステップＳ１０３に戻る。以上のステップＳ１０３〜ステップＳ１１０を繰り返することにより、プレイリストを構成するPIは順次再生されることになる。
本フローチャートにおいて、ステップＳ１１５〜ステップＳ１１７は、ステップＳ１０３〜ステップＳ１１０が一巡される毎に実行されるステップである。ステップＳ１１５は、PlayItem#xにおけるMixing_Onフラグが1であるか否かの判定を行う。もしMixing_Onフラグが1であるなら、サウンドミキシングを有効化するようサウンドコントローラ９に指示し(ステップＳ１１６)、もしMixing_Onフラグが0であるなら、サウンドミキシングを無効化するようサウンドコントローラ９に指示する(ステップＳ１１７)。
【０１６６】
以上のように本実施形態によれば、HDMVモードにおいても、BD-Jモードにおいても、利用されるプレイリスト情報にMixing_Onフラグを設けるので、HDMVモードにおいて、IGストリームを用いてGUIが実現される場合であっても、クリック音のサウンドミキシングの有効化、無効化を規定しておくことができる。
またクリック音に限らず、WWWサイトからダウンロードした他のオーディオストリームとのサウンドミキシングを実現する場合であっても、そのサウンドミキシングの有効化／無効化をMixing_Onフラグに規定しておくことができる。
【０１６７】
(第３実施形態)
第１実施形態においてJava（登録商標）仮想マシンにおけるプレイリスト再生は、BD-J Object内のプレイリスト管理テーブルを用いて規定することができた。ここで問題になるのがプレイリスト管理テーブルである。つまりプレイリストを再生してよいか否かは、BD-JObject毎のプレイリスト管理テーブルに記述されているから、あるTitleでは再生可能であるが、別のTitleでは再生不可能になることがある。またプレイリスト再生は可能であったとしても、著作権保護の観点から、ある種のアプリケーションからの再生を禁じたい場合がある。かかるプレイリスト再生の制限を実現するため、第３実施形態では、Java（登録商標）プラットフォーム３５にパーミッションコントローラが設けられている。
【０１６８】
パーミッションコントローラは、どれかのアプリケーションがプレイリスト再生を要求した場合、そのアプリケーションと相互認証を行い、要求元アプリケーションにプレイリストの再生権限があるかどうかを判定する。もしあれば、当該再生をPlaybackControl Engine３２に要求し、なければ不許可を示す応答イベントを要求元アプリケーションに出力する。このパーミッションコントローラによる許否判定により、ある配給会社の配給にかかるプレイリストを、別の配給会社の配給にかかるアプリケーションが要求したとしても、かかる要求を不許可にすることができる。そのため、正当権限なきアプリケーションによるプレイリストの無断引用を避けることができる。許可とすべきプレイリストとアプリケーションとの組合せ、不許可とすべきプレイリストとアプリケーションとの組合せは、別途BD-ROMに記録されたPermissionファイルに規定されており、パーミッションコントローラによる判定はこれに基づく。かかるファイルの詳細は本願の主眼ではないので説明を省略する。
【０１６９】
第３実施形態においてアプリケーションマネージャ３７は、現在の再生時点において再生可能なプレイリストを、アプリケーションからの要求に応じて通知する。図４２は、このアプリケーションマネージャ３７による通知処理の処理手順を示すフローチャートである。本フローチャートでは、アプリケーションの起動中において、再生可能なプレイリストの通知を求める要求(GetPL)をアプリケーションが発行したか否かの監視を行っている(ステップＳ４５)。もし発行されれば、現在の再生時点が属しているTitleを構成するBD-JObjectに、プレイリスト管理テーブルが存在するか否かを判定する(ステップＳ４６)。プレイリストの記述があれば、プレイリスト管理テーブルに記述されたプレイリストを再生可能なプレイリストとして要求元のアプリケーションに通知する(ステップＳ４７)。
【０１７０】
プレイリストの記述がなければ、プレイリスト再生が不可能な旨を発行元アプリケーションに通知する(ステップＳ４８)。以上が第３実施形態に係るアプリケーションマネージャ３７の処理手順である。
続いてプレイリスト再生が要求された場合のアプリケーションマネージャ３７の処理について説明する。第３実施形態に係るアプリケーションマネージャ３７は、図４３のフローチャートに従って処理を行う。
【０１７１】
図４３においてアプリケーションマネージャ３７は、プレイリスト再生を要求したアプリケーションが存在するか否かの判定を行っている(ステップＳ５１)。どれかのアプリケーションがプレイリスト再生を要求すれば、要求元アプリケーションにプレイリスト再生の権利が存在するか否かの認証をパーミッションコントローラに行わさせる(ステップＳ５２)。もし再生する権利があれば、PlaybackControl Engine３２に再生開始を指示して(ステップＳ５３)、Playback Control Engine３２からのサクセス応答を待つ(ステップＳ５４)。
【０１７２】
かかる再生要求があるとPlayback Control Engine３２は、プレイリスト情報の正当性をチェックする。かかる正当性チェックには、プレイリスト情報、Clip情報、AVClipが存在するBD-ROM及びローカルストレージ２０において、正当なプレイリストを構成しているかというチェックやプレイリスト情報におけるclip_Information_file_nameにより指定されるClip情報及びAVClipがBD-ROM及びローカルストレージ２０に現存するか否かというチェックがある。clip_Information_file_nameにより正しいファイルが参照されていない場合、又は、BD-ROM及びローカルストレージ２０から構成される仮想的なパッケージに矛盾があり、正しプレイリストを構成することができない場合、PlaybackControl Engine３２はfalseを示す応答を返すことになる。また要求元アプリケーションより、高い起動優先度をもつアプリケーションがそのプレイリストを再生しており、プレイリスト再生を実現するリソースにおいて競合が生じている場合最もPlaybackControl Engine３２は、falseを示す応答を返す。  
【０１７３】
以上の過程を経てサクセス応答があれば、プレイリスト再生成功を示すイベントを要求元アプリケーションに出力する(ステップＳ５５)。
サクセス応答がなければ、プレイリスト再生失敗を示すイベントを要求元アプリケーションに出力する(ステップＳ５６)。一方、ステップＳ５２において要求元アプリケーションを再生する権利が要求元アプリケーションになければ、プレイリスト再生不可を示すイベントを要求元アプリケーションに出力する(ステップＳ５７)。
【０１７４】
以上のように本実施形態によれば、プレイリスト再生可否が各Title毎でバラバラであり、プレイリスト再生の権限をもったアプリケーションやそうでないアプリケーション等様々なアプリケーションがあったとしても、適切なプレイリスト再生を、アプリケーションからの要求に応じて実行することができる。そのため、アプリケーション実行と、プレイリスト再生とを組み合わせた、多彩なコンテンツ表現が可能になる。
【０１７５】
(第４実施形態)
第１実施形態では、Title開始時において、再生を開始したいプレイリストにAutoPlayを示す再生属性を付与して、AutoPlayPLの再生を再生装置に命じていた。これに対し本実施形態では、アンバウンダリーアプリケーションをBD-ROMに記録しておき、Title開始時にあたって、自動的に再生を開始すべきTitleをアンバウンダリーアプリケーションに選択させる改良に関する。
【０１７６】
アンバウンダリーアプリケーションは、Playback Control Engine３２のような、再生装置におけるレジデントアプリケーションと対等な立場にあるアプリケーションであり、プレイリスト管理テーブルに記述されている複数プレイリスト情報の中から再生装置側のPSR設定値に合致するものを選び、通知するとの処理をPlaybackControl Engine３２からの要求に応じて実行する。
【０１７７】
プレイリスト選択をアンバウンダリーアプリケーションに行わせる場合、かかる選択が必要なTitleにあたっては、プレイリスト管理テーブルにおける再生属性を、全て無指定に設定しておく。これは、”全てが無指定”であることを合図に、PlaybackControl Engine３２にプレイリスト選択をタイトルアンバウンダリーアプリケーションに要求させるためである。
【０１７８】
このアンバウンダリーアプリケーションによる選択は、オーサリング時に規定された選択アルゴリズムに基づく。図４４（ａ）〜（ｃ）は、アンバウンダリーアプリケーションに組み込まれた選択アルゴリズムの内容を表形式に示す図である。この表は、PSRの値が取り得る値の範囲と、PSRがそれらの値になった際、再生すべきプレイリストとを対応付けて示している。このうち図４４（ａ）は、パレンタルレベルに基づく選択アルゴリズムの内容を示す。ここでパレンタルレベルは、再生装置においてPSR(14)に示されている。具体的にいうと、PSR(14)には、ユーザの年齢を示す整数値が設定されており、これを再生装置はパレンタルレベルとして解釈する。図４４（ａ）において、PSR(14)がとりうる値は、14歳未満、14歳以上18歳未満、18歳以上という3つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきプレイリストが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、PSRの設定値が14歳未満ならPlayList#1が、14以上18歳未満ならPlayList#2が、18歳以上ならPlayList#3がそれぞれ選択されることになる。
【０１７９】
図４４（ｂ）は、Languege for Audioに基づく選択アルゴリズムの内容を示す。ここでLanguege for Audioは、再生装置においてPSR(16)に示されている。具体的にいうと、PSR(16)には、整数値が設定されており、これを再生装置は音声再生用の言語設定として解釈する。図４４（ｂ）において、PSR(16)がとりうる値は、英語を示す値、日本語を示す値、その他の値という3つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきプレイリストが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムによる選択を行えば、PSR(16)の設定値が英語を示すならPlayList#1が、日本語を示すならPlayList#2が、英語、日本語以外の値ならPlayList#3がそれぞれ選択されることになる。
【０１８０】
図４４（ｃ）は、Player Configuration for Videoに基づく選択アルゴリズムの内容を示す。ここでPlayerConfiguration for Videoは、再生装置においてPSR(14)に示されている。具体的にいうと、PSR(14)には、整数値が設定されており、これを再生装置は映像再生用の環境設定として解釈する。図４４（ｃ）において、PSR(14)がとりうる値は、解像度525×600TVsystem LetterBox  解像度525×600 TVsystem、1920×1080 TVsystemという3つの範囲に分けられている。そしてこれらの範囲毎に、再生すべきプレイリストが対応づけられている。アンバウンダリーアプリケーションがかかる選択アルゴリズムに従って選択を行えば、PSR(14)の設定値が解像度525×600TVsystem LetterBoxを示すものならPlayList#1が、解像度525×600を示すものならPlayList#2が、 TVsystem、1920×1080TVsystemを示すものならPlayList#3がそれぞれ選択されることになる。図４４（ａ）〜（ｃ）に示したような選択アルゴリズムは、これらの図に示される条件分岐を、コンピュータ記述言語で記述することにより作成することができる。
【０１８１】
以上が本実施形態に係る記録媒体の改良である。続いて本実施形態に係る再生装置の改良について説明する。本実施形態での改良点は。主としてアプリケーションマネージャ３７、PlaybackControl Engine３２にある。
アプリケーションマネージャ３７は、Titleの分岐が生じ、プレイリスト管理テーブルを参照した際、そのプレイリスト管理テーブルにAutoPlayPLが存在するか否かを判定する。AutoPlayPLが無ければ、プレイリスト管理テーブルをPlaybackControl Engine３２に引き渡して、このプレイリスト管理テーブルに記載されているプレイリストのうち、どれかを自動的に再生するようPlaybackControl Engine３２に要求する。
【０１８２】
Playback Control Engine３２は、プレイリスト管理テーブルの引き渡しを受ければ、アンバウンダリーアプリケーションに対し、プレイリスト選択を行うよう要求する。この要求に応じてアンバウンダリーアプリケーションから再生可能なプレイリストのリストが通知されれば、そのPLリストに記載されたプレイリストのうち、PlayItemから引き渡されたプレイリスト管理テーブルに存在するものを判定する。アンバウンダリーアプリケーションにより選択されたプレイリストの中に、プレイリスト管理テーブルに記載されたものがあれば、それの再生を自動的に開始する。
【０１８３】
図４５は、タイトルアンバウンダリーアプリケーションにPL選択を行わせる過程を模式的に描いた図である。本図の左側は再生装置におけるソフトウェアのレイヤ構成を示し、本図の右側に、BD-ROMの記録内容を示す。図中の◎1,2,3,4は、AutoPlayがないプレイリスト管理テーブルを発見した場合の、アプリケーションマネージャ３７からの通知(◎1)、PlaybackControl Engine３２による再生可能プレイリストの問合せ(◎2)、タイトルアンバウンダリーアプリケーションによるPSR設定値取得(◎3)、タイトルアンバウンダリーアプリケーションからPlaybackControl Engine３２への再生可能なプレイリストの通知(◎4)を模式的に描いている。
【０１８４】
尚、図４５においてタイトルアンバウンダリーアプリケーションは、BD-ROM上に記述していたが、これはタイトルアンバウンダリーアプリケーションを、わかり易く記述するための配慮に過ぎない。タイトルアンバウンダリーアプリケーションは、Java（登録商標）アプリケーションであるので、Java（登録商標）仮想マシン３６内のワークメモリ５４においてインスタンスとしてスレッド５５により実行されるというのが、現実的な記述になる。
【０１８５】
以上のように本実施形態によれば、Titleのバウンダリで生存しているようなアプリケーションに、上述したような判定を行わせるので、再生装置側のPlaybackControl Engine３２は、BD-ROMにおける複数プレイリストのうち、再生装置側の状態設定に応じたものはどれであるかを、Title開始時の早い段階で知得することができる。再生属性＝AutoPlayのアプリケーションを決めておかなくても、Title開始時に再生を開始すべきプレイリストを決定することができるので、ラングエージクレジットやパレンタルロックといった再生制御をBD-Jモードにおいても実現することができる。
【０１８６】
尚、本実施形態における選択アルゴリズムは、PSRがとり得る値をプレイリストに対応づけたが、再生装置におけるPSRの設定値が、想定外の値であった場合に、再生装置に再生させるプレイリストを予め規定しておいてもよい。
(第５実施形態)
本実施形態は、タイトル切替時において、サウンドミキシングをあらかじめ無効化しておく改良に関する。タイトル切替時には、ファイルsound.bdmvの読み出しが発生することがあり得るので、かかる切替時には、デフォルトとして、サウンドミキシングをあらかじめ無効化しておく。こうすることにより、ファイルsound.bdmvがプリロードバッファ７b内に存在しないことによる、クリックオン再生の途切れを防止することができる。
（第６実施形態）
本実施形態は、xletプログラムがJMF(Java（登録商標） Media FrameWork)方式のインターフェイスを利用して、mplsファイルに対するインスタンス(JMFプレーヤインスタンス)を生成することにより、プレイリスト再生を再生装置に命じる場合の実施形態である。
【０１８７】
mplsファイルとは、プレイリスト情報の実体面を規定するファイルであるので、第２実施形態に示したように、このプレイリスト情報に、Mixing_Onフラグを設けておく。Mixing_Onフラグを、プレイリストに設けた場合、Java（登録商標）アプリケーションがプレイリスト情報の再生をPlaybackControl Engine３２に要求することにより、指定されたプレイリスト情報内にあるMixing_Onフラグに応じて、サウンドミキシングを有効化、あるいは、無効化することができる。
【０１８８】
(第７実施形態)
第１実施形態では、サウンドミキシングの有効化あるいは無効化等をサウンドコントローラ９に指示するための機能をアプリケーションマネージャ３７にもたせたが、本実施形態は、かかる機能をJava（登録商標）アプリケーションにもたせる実施形態である。
そこで本実施形態では、かかる機能の呼出をJava（登録商標）アプリケーションから受け付けるためのAPI(Application Interface)をJava（登録商標）プラットフォーム３５にもたせる。そうして、サウンドミキシングの有効化あるいは無効化を要求する機能呼出をJava（登録商標）アプリケーションが実行した場合、サウンドミキシングの有効化あるいは無効化等をサウンドコントローラ９に指示する。
【０１８９】
尚、かかる有効化、無効化を指示する機能を、モジュールマネージャ３４にもたせてもよい。
(第８実施形態)
再生装置にPCMでのサラウンド音声の伝送が可能な出力形態が存在し、その出力形態がユーザにより選択されている場合、ミキシング音声の再エンコードは不要であるため、そのまま出力することが可能である場合がある。かかる出力形態には、HDMIでの出力形態、アナログでの出力形態がある。
【０１９０】
再生装置にPCMでのサラウンド音声の伝送が可能な出力形態が存在するのか、そして、その出力形態が選択されているのかを再生装置が判断するために、どのような音声出力形態をユーザーが望んでいるか、もしくは再生装置のI/Fの接続形態からどのような音声出力が可能であるかを、本実施形態ではPSRセット２３に記述しておく。
以降、本実施形態にかかるPSRの内容について説明する。本実施形態では、PSRセット２３のうち、21番目のPSR(PSR21),22番目のPSR(PSR22)に以下のような改良が加えられている。
【０１９１】
PSR21は、ミキシング(例えば、2chの追加音声のミキシング)が可能か否かを示す“Audio  Mixing  Capability”、ミキシング可能なチャンネル数(もしくは、ミキシング可能な個々のチャンネル名)を示す“Audio  Mixing  Channel  Number”、現在ユーザーが選択している音声出力形態に対する最大の出力ch数を示す“Audio  Output  Channel  Number”を示す。
【０１９２】
例えば、音声出力形態としてS/PDIFを選択している場合、サラウンド音声は帯域上の問題から圧縮符号化しないと出力できない。そのためミキシング後に再エンコードする必要があるが、高ビットレートに対応したデジタルI/FであるHDMI等を選択している場合、非圧縮(LPCM)の形式でもそのままサラウンド音声のまま送ることが可能である。したがって、S/PDIF接続時には、ミキシング後にエンコードするか否かでAudio  Output  Channel  Numberの値が変わる。
【０１９３】
PSR22には、再生装置のー属性として、ビデオの出力を行わない再生装置であることを示すAudio  Only  Player、所定のプロファイルに準じた再生装置であることを示すProfile１  Player、Profile２  Playerがある。例えば、Profile１には対応しながらも、Profile２に対応しない再生装置はProfile１Playerを有効に設定し、Profile２ Playerを無効に設定する。これらの値は、日本語Ｌから参照可能なため再生装置のプロファイルに応じた動的な再生経路選択や、メニューの有無などが選択できる。特に、AudioOnly Playerが有効になっていた場合には、日本語ＬでCD再生装置と同等のユーザー操作性を与えるようにプレイリストを再生するようタイトルを作成することが可能であり、この場合、ユーザーはBD-ROMを音楽CDと全く変わりなく操作できる。勿論、同一のディスクでありながら、Audio  Only  Playerが無効になっている再生装置に対しては、今まで通り映像出力を仮定してGUIベースのメニューなどを表示し、インタラクティブな再生が可能である。このような想定はBDを採用したカーオーディオシステムなどで有効と考えられる。
【０１９４】
以上のようなPSRが追加されたため、本実施形態に係るPlayback Control Engine３２は、PlayItem情報又はプレイリスト情報に対応するMixing_Onフラグが、“ミキシング＝有効”を示している場合、PSR21からミキシング可能か否かを判定する。そしてPSR21がミキシング可能な場合に、PSR21からミキシング可能なch数を取得し、そのch数以下のch数を持つオーディオストリーム又はサウンドデータを、選択的にサウンドミキサ８、サウンドコントローラ９に出力して、ミキシングを行わせる。
【０１９５】
以上のように本実施形態によれば、どのような音声出力形態をユーザーが望んでいるか、もしくは再生装置のI/Fの接続形態からどのような音声出力が可能であるかを、PSRに記述しておくので、ミキシング出力の可否を、更に詳細に規定しておくことができる。
(備考)
以上の説明は、本発明の全ての実施行為の形態を示している訳ではない。下記(A)(B)(C)(D)・・・・・の変更を施した実施行為の形態によっても、本発明の実施は可能となる。本願の請求項に係る各発明は、以上に記載した複数の実施形態及びそれらの変形形態を拡張した記載、ないし、一般化した記載としている。拡張ないし一般化の程度は、本発明の技術分野の、出願当時の技術水準の特性に基づく。  
【０１９６】
(A)各実施形態に係るBD-ROMは、以下の工程を順次実行することにより、作ることができる。
先ず初めに、BD-ROMをどのような筋書きで再生させるかを決めるかを企画して(企画工程)、動画収録、音声収録等の素材作成を行い(素材作成工程)、企画工程において作成された筋書きから、ボリューム構成情報を作成する(シナリオ作成工程)。
【０１９７】
ボリューム構成情報とは、抽象的な記述にて、光ディスクの応用層のフォーマットを示す情報である。
その後、ビデオ素材、オーディオ素材、字幕素材、メニュー素材のそれぞれをエンコードすることにより、エレメンタリストリームを得る(素材エンコード工程)。その後、複数のエレメンタリストリームの多重化を行う(多重化工程)。
【０１９８】
こうして多重化がなされれば、多重化されたストリーム及びボリューム構成情報を、BD-ROMの応用層フォーマットに適合させる作業を行い、BD-ROMのボリューム領域に記録すべきデータの全体像(一般にボリュームデータという)を得る(フォーマッティング工程)。
ここで本発明に係る記録媒体の応用層フォーマットは、プログラミング言語で記述されたクラス構造体のインスタンスであり、BD-ROM規格、BD-J規格に規定された構文に基づいて、クラス構造体のインスタンスを記述することで、BD-Jobject,Clip情報,PlayList情報等を作成することができる。この場合、テーブル形式のデータは、プログラミング言語のfor文を用いて定義することができ、その他、特定の条件下のみ、必要になるようなデータは、if文を用いて定義することができる。
【０１９９】
こうした適合処理の後、ボリュームデータが得られれば、ボリュームデータを再生してみてシナリオ作成工程の結果が正しいか否かの確認を行う(エミュレーション工程)。このエミュレーション工程では、BD-ROMプレーヤモデルのバッファ状態のシミュレートを行うのが望ましい。
最後にプレス工程を行う。
【０２００】
このプレス工程では、ボリュームイメージを物理データ列に変換して、この物理データ列を用いて原盤カッティングを行い、ディスク原盤を作成する。さらにプレス装置によって作成された原盤から、BD-ROMを製造する。この製造は主に、基板成形、反射膜成膜、保護膜コーティング、張り合わせ、レーベルの印刷といった諸工程からなる。
以上の工程を経て、各実施形態に示した記録媒体(BD-ROM)を作ることができる。
【０２０１】
(B)各実施形態に示したフローチャートや、機能的な構成要素による情報処理は、ハードウェア資源を用いて具体的に実現されていることから、自然法則を利用した技術的思想の創作といえ、“プログラムの発明”としての成立要件を満たす。
・本発明に係るプログラムの生産形態
本発明に係るプログラムは、以下のようにして作ることができる。先ず初めに、ソフトウェア開発者は、プログラミング言語を用いて、各フローチャートや、機能的な構成要素を実現するようなソースプログラムを記述する。この記述にあたって、ソフトウェア開発者は、プログラミング言語の構文に従い、クラス構造体や変数、配列変数、外部関数のコールを用いて、各フローチャートや、機能的な構成要素を具現するソースプログラムを記述する。
【０２０２】
具体的には、フローチャートにおける繰り返し処理は、上記構文に規定されたfor文等を用いて記述する。判定処理は、上記構文に規定されたif文,swith文等を用いて記述する。デコーダに対する再生制御や、ドライブ装置のアクセス制御等、ハードウェアについての制御は、ハードウェアの製造元から供給される外部関数を呼び出すことにより、記述する。
【０２０３】
記述されたソースプログラムは、ファイルとしてコンパイラに与えられる。コンパイラは、これらのソースプログラムを翻訳してオブジェクトプログラムを生成する。
コンパイラによる翻訳は、構文解析、最適化、資源割付、コード生成といった過程からなる。構文解析では、ソースプログラムの字句解析、構文解析および意味解析を行い、ソースプログラムを中間プログラムに変換する。最適化では、中間プログラムに対して、基本ブロック化、制御フロー解析、データフロー解析という作業を行う。資源割付では、ターゲットとなるプロセッサの命令セットへの適合を図るため、中間プログラム中の変数をターゲットとなるプロセッサのプロセッサが有しているレジスタまたはメモリに割り付ける。コード生成では、中間プログラム内の各中間命令を、プログラムコードに変換し、オブジェクトプログラムを得る。
【０２０４】
ここで生成されたオブジェクトプログラムは、各実施形態に示したフローチャートの各ステップや、機能的構成要素の個々の手順を、コンピュータに実行させるような1つ以上のプログラムコードから構成される。ここでプログラムコードは、プロセッサのネィティブコード、JAVA（登録商標）バイトコードというように、様々な種類がある。プログラムコードによる各ステップの実現には、様々な態様がある。外部関数を利用して、各ステップを実現することができる場合、この外部関数をコールするコール文が、プログラムコードになる。また、1つのステップを実現するようなプログラムコードが、別々のオブジェクトプログラムに帰属することもある。命令種が制限されているRISCプロセッサでは、算術演算命令や論理演算命令、分岐命令等を組合せることで、フローチャートの各ステップを実現してもよい。
【０２０５】
オブジェクトプログラムが生成されるとプログラマはこれらに対してリンカを起動する。リンカはこれらのオブジェクトプログラムや、関連するライブラリプログラムをメモリ空間に割り当て、これらを１つに結合して、ロードモジュールを生成する。こうして生成されるロードモジュールは、コンピュータによる読み取りを前提にしたものであり、各フローチャートに示した処理手順や機能的な構成要素の処理手順を、コンピュータに実行させるものである。以上の処理を経て、本発明に係るプログラムを作ることができる。
(C)本発明に係るプログラムは、以下のようにして使用することができる。
【０２０６】
(i)組込プログラムとしての使用
本発明に係るプログラムを組込プログラムとして使用する場合、プログラムにあたるロードモジュールを、基本入出力プログラム(BIOS)や、様々なミドルウェア(オペレーションシステム)と共に、命令ROMに書き込む。こうした命令ROMを、制御部に組み込み、CPUに実行させることにより、本発明に係るプログラムを、再生装置の制御プログラムとして使用することができる。
【０２０７】
(ii)アプリケーションとしての使用
再生装置が、ハードディスク内蔵モデルである場合は、基本入出力プログラム(BIOS)が命令ROMに組み込まれており、様々なミドルウェア(オペレーションシステム)が、ハードディスクにプレインストールされている。また、ハードディスクから、システムを起動するためのブートROMが、再生装置に設けられている。
【０２０８】
この場合、ロードモジュールのみを、過搬型の記録媒体やネットワークを通じて、再生装置に供給し、1つのアプリケーションとしてハードディスクにインストールする。そうすると、再生装置は、ブートROMによるブートストラップを行い、オペレーションシステムを起動した上で、1つのアプリケーションとして、当該アプリケーションをCPUに実行させ、本発明に係るプログラムを使用する。
【０２０９】
ハードディスクモデルの再生装置では、本発明のプログラムを1つのアプリケーションとして使用しうるので、本発明に係るプログラムを単体で譲渡したり、貸与したり、ネットワークを通じて供給することができる。
(D)本発明に係るシステムLSIの生産・使用行為
システムLSIとは、高密度基板上にベアチップを実装し、パッケージングしたものをいう。複数個のベアチップを高密度基板上に実装し、パッケージングすることにより、あたかも１つのLSIのような外形構造を複数個のベアチップに持たせたものも、システムLSIに含まれる(このようなシステムLSIは、マルチチップモジュールと呼ばれる。)。
【０２１０】
ここでパッケージの種別に着目するとシステムLSIには、QFP(クッド フラッド アレイ)、PGA(ピン グリッド アレイ)という種別がある。QFPは、パッケージの四側面にピンが取り付けられたシステムLSIである。PGAは、底面全体に、多くのピンが取り付けられたシステムLSIである。
これらのピンは、ドライブ装置との入出力インターフェイス、リモコン装置との入力インターフェイス、テレビとのインターフェイス、その他、IEEE1394インターフェイスやPCIバスとのインターフェイスとしての役割を担っている。システムLSIにおけるピンには、こうしたインターフェイスの役割が存在するので、システムLSIにおけるこれらのピンに、ドライブ装置等や再生装置の各種回路を接続することにより、システムLSIは、再生装置の中核としての役割を果たす。
【０２１１】
システムLSIにパッケージングされるベアチップとは、各実施形態において内部構成図として示した各構成要素の機能を具現する命令ROMやCPU、デコーダLSI等である。
先に“組込プログラムとしての使用”で述べたように、命令ROMには、プログラムにあたるロードモジュールや、基本入出力プログラム(BIOS)、様々なミドルウェア(オペレーションシステム)が書き込まれる。本実施形態において、特に創作したのは、このプログラムにあたるロードモジュールの部分なので、プログラムにあたるロードモジュールを格納した命令ROMを、ベアチップとしてパッケージングすることにより、本発明に係るシステムLSIは生産することができる。
【０２１２】
具体的な実装としては、SoC実装やSiP実装が望ましい。SoC(System on chip)実装とは、1チップ上に複数の回路を焼き付ける技術である。SiP(Systemin Package)実装とは、複数チップを樹脂等で1パッケージにする技術である。以上の過程を経て、本発明に係るシステムLSIは、各実施形態に示した再生装置の内部構成図を基に作ることができる。
尚、上述のようにして生成される集積回路は、集積度の違いにより、IC、LSI、スーパーLSI、ウルトラLSIと呼称されることもある。
【０２１３】
さらに、各再生装置の構成要素の一部又は全てを1つのチップとして構成してもよい。集積回路化は、上述したSoC実装,SiP実装に限るものではなく、専用回路又は汎用プロセスで実現してもよい。LSI製造後に、プログラムすることが可能なFPGA（FieldProgrammable Gate Array）や、LSI内部の回路セルの接続や設定を再構成可能なリコンフィギュラブル・プロセッサを利用することが考えられる。更には、半導体技術の進歩又は派生する技術によりLSIに置き換わる集積回路化の技術が登場すれば、当然、その技術を用いて機能ブロックの集積回路化を行っても良い。例えば、バイオ技術の適応などが可能性としてありうる。  
【０２１４】
(E)全ての実施形態では、本発明に係る光ディスクをBD-ROMとして実施したが、どのような記録媒体であってもよい。例えば、DVD-ROM,DVD-RAM,DVD-RW,DVD-R,DVD+RW,DVD+R,CD-R,CD-RW等の光ディスク、PD,MO等の光磁気ディスクであってもよい。
(F)各実施形態におけるビデオストリームは、BD-ROM規格のAVClipであったが、DVD-Video規格、DVD-Video Recording規格のVOB(VideoObject)であってもよい。VOBは、ビデオストリーム、オーディオストリームを多重化することにより得られたISO/IEC13818-1規格準拠のプログラムストリームである。またAVClipにおけるビデオストリームは、MPEG4やWMV方式であってもよい。更にオーディオストリームは、Linear-PCM方式、Dolby-AC3方式、MP3方式、MPEG-AAC方式、dts方式であってもよい。
【０２１５】
(G)各実施形態ではMPEG４-AVC（H.264やJVTとも呼ばれる）をもとに説明したが、MPEG２ビデオストリームであってもよく、また、その他の形式(VC-1等)の画像の場合でも単独でデコード可能な画像であれば、容易に応用可能である。
【産業上の利用可能性】
【０２１６】
本発明に係る記録媒体及び再生装置は、上記実施形態に内部構成が開示されており、この内部構成に基づき量産することが可能なので、資質において工業上利用することができる。このことから本発明に係る記録媒体及び再生装置は、産業上利用可能性を有する。
【図面の簡単な説明】
【０２１７】
【図１】本発明に係る記録媒体の使用行為を示す図である。
【図２】BD-ROMの内部構成を示す図である。
【図３】拡張子.m2tsが付与されたファイルがどのように構成されているかを模式的に示す図である。
【図４】AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す図である。
【図５】AVClipを構成するTSパケットがどのような過程を経てBD-ROMに書き込まれるかを示す図である。
【図６】Clip情報の内部構成を示す図である。
【図７】映画のビデオストリームに対するEP_map設定を示す図である。
【図８】PlayList情報のデータ構造を示す図である。
【図９】AVClipと、PlayList情報との関係を示す図である。
【図１０】（ａ）STN_tableの構成を示す図である。  （ｂ）〜（ｅ）entry−attributeの詳細を示す図である。
【図１１】PlayList情報の、PlayListMark情報の内部構成を示す図である。
【図１２】PlayList情報の、PlayListMark情報によるチャプター位置の指定を示す図である。
【図１３】BD-J Objectの内部構成を示す図である。
【図１４】アーカイブファイルにより収められているプログラム、データを示す図である。
【図１５】ファイルsound.bdmvの構成を示す図である。
【図１６】（ａ）アプリケーション管理テーブルの内部構成を示す図である。  （ｂ）アプリケーション管理テーブルを構成する情報要素の意味内容を示す図である。
【図１７】ディスクコンテンツにおける状態遷移を示す図である。
【図１８】（ａ）BD-ROM全体の時間軸を示す図である。  （ｂ）BD-ROM全体の時間軸における構成を示す図である。
【図１９】（ａ）（ｂ）BD-ROM全体の時間軸において、BD-J Objectから特定されるタイトル再生区間を示す図である。
【図２０】図１９（ｂ）の時間軸上に規定される、生存区間の典型を示す図である。
【図２１】本編タイトル、オンラインショッピングタイトル、ゲームタイトルという3つのタイトルを含むディスクコンテンツを示す図である。
【図２２】（ａ）（ｂ）アプリケーション管理テーブル、生存区間の一例を示す図である。
【図２３】起動属性がとり得る三態様(Present、AutoRun、Suspend)と、直前タイトルにおけるアプリケーション状態の三態様(非起動、起動中、Suspend)とがとりうる組合せを示す図である。
【図２４】（ａ）プレイリスト管理テーブルの内部構成を示す図である。  （ｂ）プレイリスト管理テーブルを構成する情報要素の意味内容を示す図である。
【図２５】プレイリスト管理テーブル、アプリケーション管理テーブルにより規定されるタイトルの具体例を示す。
【図２６】カレントタイトルがとり得る三態様(プレイリスト管理テーブル無し、プレイリスト管理テーブル有りで尚且つ無指定、プレイリスト管理テーブル有りで尚且つAutoPlay)と、直前タイトルにおけるPLの状態(非再生状態、再生中状態)とがとりうる6通りの組合せを示す図である。
【図２７】（ａ）プレイリスト管理テーブル及びアプリケーション管理テーブルの記述例を示す図である。  （ｂ）図２７（ａ）のように記述されたアプリケーション管理テーブル、プレイリスト管理テーブルによりプレイリスト再生、アプリケーション実行がどのように進行するかを示す図である。
【図２８】（ａ）プレイリスト管理テーブルの他の記述例を示す図である。  （ｂ）図２８（ａ）のケースに基づくアプリケーション実行及びプレイリスト再生の進行を示す図である。
【図２９】SMTの内部構成を示す図である。
【図３０】（ａ）（ｂ）は、STN_Tableにおけるオーディオストリームについてのentry-attributeと、Mixing_Onフラグの設定との因果関係を示す図である。
【図３１】Mixing_OnフラグがONに設定されたタイトルにおいて、GUIフレームワーク上のボタンが操作された場合の、再生装置による音声再生を示す図である。
【図３２】Mixing_OnフラグがOFFに設定されたタイトルにおいて、GUIフレームワーク上のボタンが操作された場合の、再生装置による音声再生を示す図である。
【図３３】本発明に係る再生装置の内部構成を示す図である。
【図３４】ROM２４に格納されたソフトウェアと、ハードウェアとからなる部分を、レイア構成に置き換えて描いた図である。
【図３５】Java（登録商標）仮想マシン３６の内部構成を示す図である。
【図３６】Presentation Engine３１〜モジュールマネージャ３４による処理を模式化した図である。
【図３７】BD-J ObjectにおけるPLMTに基づく、アプリケーションマネージャ３７の処理を示す図である。
【図３８】BD-J ObjectにおけるSMTに基づく、アプリケーションマネージャ３７の処理を示す図である。
【図３９】アプリケーションマネージャ３７による処理手順を示すフローチャートである。
【図４０】（ａ）第２実施形態に係るプレイリスト情報の内部構成を示す図である。  （ｂ）は、PlayItem情報内に設けられた、Mixing_Onフラグの内容を示す図である。
【図４１】Playback Control Engine３２によるプレイリスト再生手順を示すフローチャートである。
【図４２】アプリケーションマネージャ３７による通知処理の処理手順を示すフローチャートである。
【図４３】第３実施形態に係るアプリケーションマネージャ３７の処理手順を示す図である。
【図４４】（ａ）パレンタルレベルに基づく選択アルゴリズムの内容を示す。  （ｂ）Languege for Audioに基づく選択アルゴリズムの内容を示す。  （ｃ）Player Configuration for Videoに基づく選択アルゴリズムの内容を示す。
【図４５】タイトルアンバウンダリーアプリケーションにプレイリスト選択を行わせる過程を模式的に描いた図である。
【符号の説明】
【０２１８】
１  BD-ROMドライブ
２  リードバッファ
３  デマルチプレクサ
４  ビデオデコーダ
５  ビデオプレーン
６  サウンドプロセッサ
７  サウンドプロセッサ
８  ミキサー
９  サウンドコントローラ
１０  D/Aコンバータ
１１  Interactive Graphicsデコーダ
１２  Interactive Graphicsプレーン
１３  Presentation Graphicsデコーダ
１４  Presentation Graphicsプレーン
１５  JPEGデコーダ
１６  Stillプレーン
１７  合成部
１８  STC-delta付加部
１９  ATC-delta付加部
２０  ローカルストレージ
２１  命令ROM
２２  ユーザイベント処理部
２３  PSRセット
２４  CPU
２５  シナリオメモリ
２６  ローカルメモリ
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006059654.tif 000047
【図２】
2006059654.tif 000048
【図３】
2006059654.tif 000049
【図４】
2006059654.tif 000050
【図５】
2006059654.tif 000051
【図６】
2006059654.tif 000052
【図７】
2006059654.tif 000053
【図８】
2006059654.tif 000054
【図９】
2006059654.tif 000055
【図１０】
2006059654.tif 000056
【図１１】
2006059654.tif 000057
【図１２】
2006059654.tif 000058
【図１３】
2006059654.tif 000059
【図１４】
2006059654.tif 000060
【図１５】
2006059654.tif 000061
【図１６】
2006059654.tif 000062
【図１７】
2006059654.tif 000063
【図１８】
2006059654.tif 000064
【図１９】
2006059654.tif 000065
【図２０】
2006059654.tif 000066
【図２１】
2006059654.tif 000067
【図２２】
2006059654.tif 000068
【図２３】
2006059654.tif 000069
【図２４】
2006059654.tif 000070
【図２５】
2006059654.tif 000071
【図２６】
2006059654.tif 000072
【図２７】
2006059654.tif 000073
【図２８】
2006059654.tif 000074
【図２９】
2006059654.tif 000075
【図３０】
2006059654.tif 000076
【図３１】
2006059654.tif 000077
【図３２】
2006059654.tif 000078
【図３３】
2006059654.tif 000079
【図３４】
2006059654.tif 000080
【図３５】
2006059654.tif 000081
【図３６】
2006059654.tif 000082
【図３７】
2006059654.tif 000083
【図３８】
2006059654.tif 000084
【図３９】
2006059654.tif 000085
【図４０】
2006059654.tif 000086
【図４１】
2006059654.tif 000087
【図４２】
2006059654.tif 000088
【図４３】
2006059654.tif 000089
【図４４】
2006059654.tif 000090
【図４５】
2006059654.tif 000091
【手続補正書】
【提出日】平成19年7月10日(2007.7.10)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
多重化されたビデオストリーム及びオーディオストリームを含むデジタルストリームと、アプリケーションと、クリック音として出力するためのサウンドデータとが記録された記録媒体であって、
前記記録媒体には管理情報と、前記管理情報に対応するフラグとが更に記録されており、
前記管理情報は、
前記アプリケーションの実行中において、同時に開始すべきデジタルストリームの再生制御を示す情報であり、
前記フラグは、
前記実行されるアプリケーションに対するユーザ操作に応じたサウンドデータを用いたクリック音の出力と、前記再生制御時におけるデジタルストリームの音声出力とをミキシングするか否かを示す、
ことを特徴とする記録媒体。
【請求項２】
アプリケーションを実行すると共に、デジタルストリームを再生する再生装置であって、
管理情報と、前記管理情報に対応するフラグとを記録媒体から読み出す読出手段と、
前記記録媒体に記録されたアプリケーションを実行するプラットフォーム部と、 
前記アプリケーションの実行中に、前記管理情報に示された再生制御を実行することにより、同時にデジタルストリームを再生して、映像出力及び音声出力を行う再生制御エンジン部と、
前記管理情報に対応したフラグがオンである場合、前記実行中のアプリケーションに対するユーザ操作に応じたサウンドデータを用いたクリック音の出力と、前記デジタルストリームの音声出力とのミキシングを実行し、前記管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシング部と、
を備えることを特徴とする再生装置。 
【請求項３】
アプリケーションの実行を管理すると共に、デジタルストリームの再生をコンピュータに実行させる管理プログラムであって、
管理情報と、前記管理情報に対応するフラグとを記録媒体から読み出す読出ステップと、
前記記録媒体に記録されたアプリケーションを実行するステップと、 
前記アプリケーションの実行中に、前記管理情報に示された再生制御を実行することにより、同時にデジタルストリームを再生して、映像出力及び音声出力を行う再生制御ステップと、
前記管理情報に対応したフラグがオンである場合、前記アプリケーションに対するユーザ操作に応じたサウンドデータを用いたクリック音の出力と、前記デジタルストリームの音声出力とのミキシングを実行し、前記管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシングステップと、
をコンピュータに実行させることを特徴とする管理プログラム。
【請求項４】
アプリケーションを実行すると共に、デジタルストリームを再生する再生方法であって、
管理情報と、前記管理情報に対応するフラグとを記録媒体から読み出す読出ステップと、
前記記録媒体に記録されたアプリケーションを実行するステップと、 
前記アプリケーションの実行中に、前記管理情報に示された再生制御を実行することにより、同時にデジタルストリームを再生して、映像出力及び音声出力を行う再生制御ステップと、
前記管理情報に対応したフラグがオンである場合、前記実行中のアプリケーションに対するユーザ操作に応じたサウンドデータを用いたクリック音の出力と、前記デジタルストリームの音声出力とのミキシングを実行し、前記管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシングステップと、
を含むことを特徴とする再生方法。
【請求項５】
アプリケーションを実行すると共に、デジタルストリームを再生する再生装置に組み込まれる集積回路であって、
再生装置の制御により記録媒体から読み出されたアプリケーションを実行するプラットフォーム部と、 
前記アプリケーションの実行中に、前記記録媒体から読み出された前記管理情報に示された再生制御を実行することにより、同時にデジタルストリームを再生して、映像出力及び音声出力を行う再生制御エンジン部と、
前記管理情報に対応したフラグがオンである場合、前記実行中のアプリケーションに対するユーザ操作に応じたサウンドデータを用いたクリック音の出力と、前記デジタルストリームの音声出力とのミキシングを実行するか、前記管理情報に対応したフラグがオフである場合、当該ミキシングを実行しないミキシング部と、
を備えることを特徴とする集積回路。 
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】０００５
【補正方法】変更
【補正の内容】
【０００５】
クリック音の導入により“マルチチャネルの音声出力が途切れるのではないか”という不安の呪縛がある限り、クリック音という機能自体が、映画制作に使用されないとのケースが多発する。かかる呪縛から、映画制作スタジオを解放するには、再生装置に再エンコードを行わせるという考えを、あらゆる再生装置に義務付ければよい。つまり再生装置内にエンコーダを具備しておき、5.1チャネルといったマルチチャネル属性をもっているオ
ーディオストリームをLPCM状態に展開して、クリック音をミキシングした後、これを再エンコードした上で、デジタル出力を行えばよい。具体的にいうと、ミキシングした音声のデジタル音声出力をS/PDIF(Sony/PhilipsDigital InterConnect Format,ISO60958-3規格)のようなデジタルインターフェースを介して、実行する場合、上述した再エンコードを行い、ドルビーデジタルやDTSへと変換することが必要になる。しかしかかる再エンコード
には、エンコーダの具備が必須になる。
【手続補正３】
【補正対象書類名】明細書
【補正対象項目名】０００７
【補正方法】変更
【補正の内容】
【０００７】
上記目的は、多重化されたビデオストリーム及びオーディオストリームを含むデジタルストリームと、アプリケーションと、クリック音として出力するためのサウンドデータとが記録された記録媒体であって、前記記録媒体には管理情報と、前記管理情報に対応するフラグとが更に記録されており、前記管理情報は、前記アプリケーションの実行中において、同時に開始すべきデジタルストリームの再生制御を示す情報であり、前記フラグは、前記実行されるアプリケーションに対するユーザ操作に応じたサウンドデータを用いたクリック音の出力と、前記再生制御時におけるデジタルストリームの音声出力とをミキシングするか否かを示すことを特徴とする記録媒体により達成される。
【手続補正４】
【補正対象書類名】明細書
【補正対象項目名】０００８
【補正方法】変更
【補正の内容】
【０００８】
本発明は上述した構成を有しているので、実行中のアプリケーションに対するユーザ操作に応じたサウンドデータを用いたクリック音の出力と、再生制御時におけるデジタルストリームの音声出力とをミキシングするか否かの調整を制作者側の意図に沿ったものとすることが可能となる。これは例えばマルチチャネルでの音声出力を意図するような再生制御の実行時にはサウンドミキシングを無効化しておき、マルチチャネルでの音声出力を意図しないような再生制御の実行時にはサウンドミキシングを有効化しておくことができるようになり、例えば映画の制作スタジオは、マルチチャネルでの再生を意図している場合は、クリック音を禁止し、代わりにクリック音での再生を意図している場合は、代わりにマルチチャネルによる音声出力を禁止するという調整が可能になる。
【国際調査報告】
2006059654.tif 000092
2006059654.tif 000093
2006059654.tif 000094
2006059654.tif 000095