WO2007013378A1

WO2007013378A1 - 情報記録媒体、記録装置、および記録方法

Info

Publication number: WO2007013378A1
Application number: PCT/JP2006/314526
Authority: WO
Inventors: Hiroshi Yahata; Wataru Ikeda; Shigeki Matsunaga
Original assignee: Matsushita Electric Industrial Co., Ltd.
Priority date: 2005-07-27
Filing date: 2006-07-21
Publication date: 2007-02-01
Also published as: EP1909281A1; CN101228584A; CN101228584B; CN101996664A; CN101996664B; KR20080031013A; KR101248305B1; EP1909281A4; JP2011227990A; JP2011227989A; JP5314097B2; US20100284667A1; CN101964914B; CN101964914A

Abstract

　本発明は、デジタルストリームの一部または全部である部分区間で構成されるＡＶコンテンツであるタイトルが記録された情報記録媒体であって、デジタルストリームにおける部分区間の位置と、再生順序とを指定することでタイトルを特定する情報を有するプレイリストと、プレイリストを呼び出すことによりタイトルの再生を制御するプログラムと、メニューを識別する“ＴｏｐＭｅｎｕ”と、プログラムを識別する“ＰｒｏｇｒａｍＩＤＲｅｆ”とが対応付けられて含まれている“Ｉｎｄｅｘ”と、“ＴｏｐＭｅｎｕ”と“ＰｌａｙＬｉｓｔＩＤ”とが対応付けられて含まれている“Ｅｘｔｅｎｓｉｏｎ”とが記録されている。

Description

明細書

情報記録媒体、記録装置、および記録方法

技術分野

[0001] 本発明は、記録した映像データの再生をユーザに指示させるためのメニューが付与された形式で映像データを記録した情報記録媒体、その記録装置及び記録方法に関する。

背景技術

[0002] 映像データを記録した情報記録媒体の代表格は、 DVD (以下、「Standard Difi nition (SD)—DVD」ともいう。）である。以下に従来の DVDについて説明する。

[0003] 図 1は、 SD— DVDの構造を示す図である。図 1の下段に示すように、 DVDデイスク上にはリードインからリードアウトまでの間に論理アドレス空間が設けられている。その論理アドレス空間には先頭力ファイルシステムのボリューム情報が記録され、続 V、て映像音声などのアプリケーションデータが記録されて、る。

[0004] ファイルシステムとは、 ISO9660や Universal Disc Format (UDF)等の規格により定められたデータを管理する仕組みのことであり、ディスク上のデータをディレクトリまたはファイルと呼ばれる単位で表現する仕組みである。

[0005] 日常使っているパーソナルコンピュータ（PC)の場合でも、 File Allocation Tabl es (FAT)または NT File System (NTFS)と呼ばれるファイルシステムにより、ディレクトリゃファイルという構造でノヽードディスクに記録されたデータがコンピュータ上で表現され、ユーザピリティを高めている。

[0006] SD— DVDの場合、 UDF及び ISO9660の両方のファイルシステムが使用されている。両方を合わせて「UDFブリッジ」とも呼ばれる。記録されているデータは UDFまたは ISO9660どちらのファイルシステムドライバによってもデータの読み出しができるようになっている。なお、ここで取り扱う DVDはパッケージメディア用の ROMデイスクであり、物理的に書き込みが不可能である。

[0007] DVD上に記録されたデータは、 UDFブリッジを通して、図 1左上に示すようなディレクトリまたはファイルとして見ることができる。ルートディレクトリ（図 1における「ROO T」）の直下に「VIDEO— TS」と呼ばれるディレクトリが置かれ、ここに DVDのアプリケーシヨンデータが記録されている。アプリケーションデータは、複数のファイルとして記録され、主なファイルとして以下の種類のファイルがある。

[0008] VIDEO— TS. IFO ディスク再生制御情報ファイル

VTS— 01— 0. IFO ビデオタイトルセット # 1再生制御情報ファイル VTS 01 0. VOB ビデオタイトルセット # 1ストリームファイル

[0009] 上記例に示すように 2つの拡張子が規定されている。「IFO」は再生制御情報が記録されたファイルであることを示す拡張子であり、「VOB」は AVデータである MPEG ストリームが記録されたファイルであることを示す拡張子である。

[0010] 再生制御情報とは、 DVDで採用されたインタラクテイビティ (ユーザの操作に応じて再生を動的に変化させる技術)を実現するための情報や、メタデータのような、 AVデータに付属する情報などのことである。また、 DVDでは一般的に再生制御情報のことをナビゲーシヨン情報と呼ぶことがある。

[0011] 再生制御情報ファイルは、ディスク全体を管理する「VIDEO— TS. IFO」と、個々のビデオタイトルセット毎の再生制御情報である「VTS— 01— 0. IFO」がある。なお、 DVDでは複数のタイトル、言い換えれば複数の異なる映画や楽曲を 1枚のディスクに記録することが可能である。

[0012] ここで、ファイル名ボディにある「01」はビデオタイトルセットの番号を示しており、例えば、ビデオタイトルセット # 2の場合は、「VTS— 02— 0. IFO」となる。

[0013] 図 1の右上部は、 DVDのアプリケーション層での DVDナビゲーシヨン空間であり、前述した再生制御情報が展開された論理構造空間である。「VIDEO— TS. IFOJ 内の情報は、 VIDEO Manager Information (VMGI)として、「VTS— 01— 0. I FO」または、他のビデオタイトルセット毎に存在する再生制御情報は Video Title Set Information (VTSI)として DVDナビゲーシヨン空間に展開される。

[0014] VTSIの中には Program Chain (PGC)と呼ばれる再生シーケンスの情報である Program Chain Information (PGCI)が記述されている。 PGCIは、 Cellの集合とコマンドと呼ばれる一種のプログラミング情報によって構成されている。 [0015] Cell自身は VOB (Video Objectの略であり、 MPEGストリームを指す）の一部区間または全部区間を指定する情報であり、 Cellの再生は、当該 VOBの Cellによって指定された区間を再生することを意味している。

[0016] コマンドは、 DVDの仮想マシンによって処理されるものであり、例えば、ウェブべ一ジを表示するブラウザ上で実行される Java (登録商標)スクリプトなどに近、ものである。し力しながら Java (登録商標)スクリプトが論理演算の他にウィンドウやブラウザの制御（例えば、新しいブラウザのウィンドウを開くなど）を行うのに対して、 DVDのコマンドは、論理演算の他に AVタイトルの再生制御、例えば、再生するチャプターの指定などを実行するだけのものである点で異なっている。

[0017] Cellはディスク上に記録されている VOBの開始及び終了アドレス (論理アドレス）をその内部情報として有しており、プレーヤは、 Cellに記述された VOBの開始及び終了アドレス情報を使ってデータの読み出し、再生を実行する。

[0018] 図 2は、 AVデータである MPEGストリーム中に埋め込まれているナビゲーシヨン情報を説明する概要図である。

[0019] SD— DVDの特長であるインタラクテイビティは前述した「VIDEO— TS. IFO」や「 VTS— 01— 0. IFOJなどに記録されてヽるナビゲーシヨン情報だけによつて実現されているのではなぐ幾つかの重要な情報はナビゲーシヨン'パック（ナビパックまたは、 NV— PCKという。）と呼ばれる専用キャリアを使い VOB内に映像、音声データと一緒に多重化されている。

[0020] ここでは簡単なインタラクテイビティの例としてメニュー画面について説明する。メ- ユー画面上には、幾つかのボタンが現れ、それぞれのボタンには当該ボタンが選択実行された時の処理が定義されて、る。

[0021] また、メニュー画面上では一つのボタンが選択されており（選択ボタン上に半透明色がオーバーレイされることで該ボタンがハイライトされ、該ボタンが選択状態であることをユーザに示す）、ユーザは、リモコンの上下左右キーを使って、選択状態のボタンを上下左右の何れかのボタンに移動させることが出来る。

[0022] リモコンの上下左右キーを使って、選択実行したいボタンまでノヽイライトを移動させ、決定する (決定キーを押す)ことによって対応するコマンドのプログラムが実行される。一般的には対応するタイトルやチャプターの再生がコマンドによって実行されている (例えば、特許文献 1参照)。

[0023] 図 2の左上部は NV—PCKに格納される情報の概要を示している。 NV— PCK内には、ノ、イライトカラー情報と個々のボタン情報などが含まれている。ノ、イライトカラー情報には、カラーパレット情報が記述され、オーバーレイ表示されるハイライトの半透明色が指定される。

[0024] ボタン情報には、個々のボタンの位置情報である矩形領域情報と、当該ボタンから他のボタンへの移動情報 (ユーザの上下左右キー操作それぞれに対応する移動先ボタンの指定）と、ボタンコマンド情報（当該ボタンが決定された時に実行されるコマンド）とが記述されている。

[0025] メニュー画面上のハイライトは、図 2の右上部に示すように、オーバーレイ画像として作られる。オーバーレイ画像は、ボタン情報の矩形領域情報にカラーパレット情報の色を付した物である。このオーバーレイ画像は図 2の右部に示す背景画像と合成されて画面上に表示される。

[0026] 前述のようにして、 DVDではメニュー画面を実現して、る。また、何故、ナビゲーシヨンデータの一部を NV—PCKを使ってストリーム中に埋め込んで!/、るのかにつ、ては、以下の理由力もである。

[0027] すなわち、ストリームと同期して動的にメニュー情報を更新、例えば、映画再生中の途中 5分〜 10分の間にだけメニュー画面を表示するといつた、同期タイミングが問題となりやすヽ処理を問題なく実現できるようにするためである。

[0028] また、もう一つの大きな理由は、 NV— PCKには特殊再生を支援するための情報を格納し、 DVD再生時の早送り、巻き戻しなどの非通常再生時にも円滑に AVデータをデコードし再生させる等、ユーザの操作性を向上させるためである。

[0029] 図 3は、 DVDにおける VOBの構成を示す概要図である。図に示すように、映像、音声、字幕などのデータ（図 3の（1) )は、 MPEGシステム（ISOZIEC13818— 1) 規格に基づいて、パケット及びパック化し（図 3の（2) )、それぞれを多重化して 1本の MPEGプログラムストリームにして!/、る（図 3の（3) )。

[0030] また、前述した通りインタラクティブを実現するためのボタンコマンドを含んだ NV— PCKも一緒に多重化をされてヽる。

[0031] MPEGシステムの多重化の特徴として、多重化する個々のデータは、そのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕の間は必ずしも再生順、言ヽ換えればデコード順に基づ！ヽてビット列が形成されて

V、るわけではな、ことが挙げられる。

[0032] これは MPEGシステムストリームのデコーダモデル（図 3の（4)、一般に System T arget Decoder,または STDと呼ばれる）が多重化を解、た後に個々のエレメンタリストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積して、る事に由来して、る。

[0033] このデコーダバッファは、個々のエレメンタリストリーム毎にサイズが異なり、映像に対しては、 232kB、音声に対しては 4kB、字幕に対しては 52kBをそれぞれ有している。

[0034] このため、各デコーダバッファへのデータ入力タイミングは個々のエレメンタリストリームで異なるため、 MPEGシステムストリームとしてビット列を形成する順番と表示（デコード)されるタイミングにずれが生じている。

[0035] 即ち、映像データと並んで多重化されている字幕データが必ずしも同一タイミングでデコードされて、るわけでは無、。

[0036] 以上述べたような DVDに関する技術は、下記の特許文献 2に記載されている。

特許文献 1：特願平 8— 83478号公報

特許文献 2：特許第 2813245号公報

発明の開示

発明が解決しょうとする課題

[0037] ここで、現在、撮影した映像等のデジタルコンテンツ（以下、単に「コンテンツ」 t 、う。）を、情報記録媒体である前述の DVD等のディスクに逐次記録する各種のビデオカメラレコーダ (以下、単に「ビデオカメラ」という。）が多くのメーカーで生産され、広く流通している。

[0038] また、これらビデオカメラは、独自のメニュー画面を生成し、ディスクに書き込む機能を有している。このメニュー画面を以下、「ディスクメニュー」という。 [0039] ユーザは、ビデオカメラで情報記録媒体に映像を記録し、その情報記録媒体をプレーャで再生すると、そのビデオカメラで生成されたディスクメニューを見ることができる。また、そのメニュー力も再生等の対象とするタイトルの選択を行うことができる。

[0040] し力しながら、様々なメーカーで生産される各種のビデオカメラにお、て、ディスクメニューに係る各種ファイルの記述内容や構成等が統一されているわけではない。

[0041] つまり、あるメーカーのビデオカメラで生成されたディスクメニューを、他のメーカーのビデオカメラが解釈することは実質的に不可能である。

[0042] そのため、例えば、あるメーカーのビデオカメラで映像が記録されたディスク力他のメーカーのビデオカメラにロードされ、新たなタイトルの追加等が行われた場合、当該他のメーカーのカメラでは、記録済みのディスクメニューに関するファイルを削除し、新たにディスクメニューを作成する必要がある。

[0043] この場合、ディスクがロードされたビデオカメラでは、記録済みのディスクメニューに関連する各種ファイルを、そのディスクメニューの再生を制御するプログラム等を解析することにより探し出すという、極めて高度な解析作業が必要となる。

[0044] そのため、ディスクがセットされた後に、映像の記録等の動作が開始可能となるまで長時間掛カることになり、実質的には、上記の各種ファイルを探し出せないといった問題がある。

[0045] また、新たなディスクメニューを記録する際に、不要となった既存のディスクメニューに関連するファイルを削除しない場合、不要なファイルがディスクに蓄積していくことになる。これにより、ディスクの記録可能容量を不要に圧迫するだけでなぐ当該ディスクを使用する記録装置および再生装置においてファイル管理に係る処理負荷が増カロすること〖こなる。

[0046] そこで本発明は、上記従来の課題を考慮し、ある記録装置で生成されたメニューが情報記録媒体に記録された後にその情報記録媒体が他の記録装置にセットされた場合、当該他の記録装置において本来的には不要な処理負荷および処理時間を発生させないための情報記録媒体、記録装置、および、記録方法を提供することを目的とする。

課題を解決するための手段 [0047] 上記目的を達成するために、本発明の情報記録媒体は、デジタルストリームの一部または全部である部分区間で構成される AVコンテンツであるタイトルが記録された情報記録媒体であって、デジタルストリームにおける部分区間の位置と、再生順序とを指定することで前記タイトルを特定する情報を有するプレイリストと、前記プレイリストを呼び出すことにより前記タイトルの再生を制御するプログラムと、前記タイトルを識別するタイトル識別情報と、前記プログラムを識別するプログラム識別情報とが対応付けられて含まれて、るインデックス情報と、前記タイトル識別情報と前記プレイリストを識別するプレイリスト識別情報とが対応付けられて含まれている拡張情報とが記録されている。

[0048] これにより、本発明の情報記録媒体を使用する記録装置が、情報記録媒体に記録するタイトルの 1つであるメニューを削除する際に、そのメニューの再生を制御するプログラムを解析することなぐそのメニューに関連するプレイリストを容易に特定することがでさる。

[0049] 従って、例えば、記録装置であるビデオカメラにお、て、他のビデオカメラが生成しディスクに記録したディスクメニューを削除する際、ディスクメニューに関連するプレイリストを特定し、肖 IJ除することができる。

[0050] また、この削除に係る作業において、プログラムの解析等を行う必要がなぐ容易に削除すべきプレイリストを特定することができる。つまり、本発明の情報記録媒体を使用する記録装置において、本来的には不要な処理負荷および処理時間が発生することがない。

[0051] また、本発明の記録装置は、前記情報記録媒体にデジタルストリームを記録する記録装置であって、前記情報記録媒体には、複数のタイトルが記録されており、前記複数のタイトルのうちの 1つは、自身以外のタイトルをユーザに選択させるメニューであり、前記記録装置は、前記メニューの再生を制御するプログラムから呼び出されるプレイリストを、前記拡張情報に含まれる、前記メニューのタイトル識別情報に対応付けられた前記プレイリスト識別情報を用いて特定するプレイリスト特定手段と、前記メニュ一に換えて、新たなメニューを生成し前記情報記録媒体に記録するメニュー生成手段と、前記メニュー生成手段により前記新たなメニューが生成される場合、前記プレイリスト特定手段により特定されたプレイリストを削除する削除手段とを備える。

[0052] これにより、本発明の記録装置は、容易にタイトルに関連するプレイリストを特定することができ、そのプレイリストを削除することができる。

[0053] 従って、例えば、ビデオカメラとして本発明の記録装置を実現した場合、他メーカーのビデオカメラによりディスクメニューが記録された DVDや半導体メモリ等の情報記録媒体から、容易にそのディスクメニューに関連するプレイリストを削除することができる。

[0054] つまり、不要なファイルを削除した上で、新たなディスクメニューを生成し、当該情報記録媒体に記録することができる。また、このように、不要なファイルを削除することで、当該情報記録媒体の記録可能容量を無駄に消費することがなぐまたファイル管理に係る処理負荷の増加を抑えることができる。

[0055] なお、本発明は、このような情報記録装置として実現することができるだけでなぐこのような情報記録装置が備える特徴的な手段を有する集積回路として実現することもできる。これら特徴的な手段は、個別に 1チップ化されても良いし、これらのうちの一部又はすベてを含むように 1チップ化されても良!、。

[0056] また、本発明は、このような情報記録装置が備える特徴的な手段をステップとする記録方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、 CD— ROM等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。

[0057] また、本発明は、本発明の情報記録媒体から情報を読み取って再生する再生装置として実現したり、このような再生装置が備える特徴的な手段をステップとする再生方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、 CD— ROM等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。発明の効果

[0058] ある記録装置で生成されたメニューが情報記録媒体に記録された後にその情報記録媒体が他の記録装置にセットされた場合、当該他の記録装置において本来的には不要な処理負荷および処理時間を発生させな!/、ための情報記録媒体、記録装置、および、記録方法を提供することができる。

図面の簡単な説明

[図 1]図 1は、 SD— DVDの構造を示す図である。

[図 2]図 2は、 AVデータである MPEGストリーム中に埋め込まれているナビゲーシヨン情報を説明する概要図である。

[図 3]図 3は、 DVDにおける VOBの構成を示す概要図である。

[図 4]図 4は、 BD— ROMのデータ階層を示す図である。

[図 5]図 5は、 BD— ROMに記録されている論理データの構造を示す図である。

[図 6]図 6は、 BD— ROMを再生する BD— ROMプレーヤの基本的な構成の概要を示す図である。

[図 7]図 7は、図 6に示すプレーヤの構成を詳細化したブロック図である。

[図 8]図 8は、 BD— ROMのアプリケーション空間を示す図である。

[図 9]図 9は、 MPEGストリーム（VOB)の構成を示す図である。

[図 10]図 10は、 MPEGストリームにおけるパックの構成を示す図である。

[図 11]図 11は、 AVデータとプレーヤ構成との関係を説明するための図である。

[図 12]図 12は、トラックバッファを使った VOBデータ連続供給モデルを説明するための図である。

[図 13]図 13は、 VOB管理情報ファイルの内部構造を示す図である。

[図 14]図 14は、 VOBU情報の詳細を説明するための図である。

[図 15]図 15は、タイムマップを使ったアドレス情報取得方法を説明するための図である。

[図 16]図 16は、プレイリストの構成を示す図である。

[図 17]図 17は、イベントハンドラテーブルの構成を示す図である。

[図 18]図 18は、 BD—ROM全体情報である BD. INFOの構成を示す図である。

[図 19]図 19は、グローバルイベントハンドラテーブルの構成を示す図である。

[図 20]図 20は、タイムイベントの例を示す図である。

[図 21]図 21は、ユーザのメニュー操作によるユーザイベントの例を示す図である。 [図 22]図 22は、グローバルイベントの例を示す図である。

[図 23]図 23は、プログラムプロセッサの機能的な構成を説明するための図である。

[図 24]図 24は、システムパラメータ（SPRM)の一覧を示す図である。

[図 25]図 25は、 2つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。

[図 26]図 26は、メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。

[図 27]図 27は、 BD— ROMプレーヤにおける AVデータ再生の基本処理の流れを示すフローチャートである。

[図 28]図 28は、 BD— ROMプレーヤにおけるプレイリスト再生開始から VOB再生終了までの処理の流れを示すフローチャートである。

[図 29] (A)は、 BD— ROMプレーヤにおけるタイムイベントに係る処理の流れを示すフローチャートであり、（B)は、 BD— ROMプレーヤにおけるユーザイベントに係る処理の流れを示すフローチャートである。

[図 30]図 30は、 BD— ROMプレーヤにおける字幕データの処理の流れを示すフロ一チャートである。

[図 31]図 31は、実施の形態 2におけるディスクを使用するレコーダおよびプレーヤで表示されるメニューの例を示す図である。

[図 32]図 32は、実施の形態 2における BD. INFOの内容を示す図である。

[図 33]図 33は、実施の形態 2における BD. PROGの内容を示す図である。

[図 34]図 34は、メニュー表示およびタイトル再生に係る表示および動作の遷移の一例を示す図である。

[図 35] (A)は、ディスクメニューの更新において BD. INFO等の各ファイルをどのように扱うかを示す図であり、（B)は、（A)に示される番号の意味を説明する図である。

[図 36]図 36は、 BD. INFOの" Extension"にプレイリストを特定するための情報を格納した状態を示す図である。

[図 37]図 37は、実施の形態 2における、ディスクメニューの更新前後のタイトルとプレイリスト（コンテンツ）との相関の例を示す図である。 [図 38]図 38は、実施の形態 2のレコーダの機能的な構成を示す機能ブロック図である。

[図 39]図 39は、実施の形態 2のレコーダ 400における記録/編集時のタイトル構成の更新時の動作の流れの概要を示すフロー図である。

[図 40]図 40は、実施の形態 3における、 BDディスク全体管理情報および Title情報を記録するファイルの構成図である。

[図 41]図 41は、実施の形態 3における、プログラムを格納する Object情報を記録するファイルの構成図である。

[図 42]図 42は、実施の形態 3における、 BD— ROMでの多重化の例を示す図である

[図 43]図 43は、実施の形態 3における、ナビゲーシヨン機能のページのデータ構造を示す図である。

[図 44]図 44は、実施の形態 3における、ナビゲーシヨン機能のボタンのデータ構造を示す図である。

[図 45]図 45は、実施の形態 3における、ナビゲーシヨン機能の例を示す図である。

[図 46]図 46は、実施の形態 3における、スライドショウ機能の構造を示す図である。

[図 47] (A)は、実施の形態 3における、再生メニューの例を示す図であり、（B)は、実施の形態 3における、メニュー画面の遷移の例を示す図である。

[図 48]図 48は、実施の形態 3における、各 Titleが参照するプレイリスト並びにォブジェタトの情報を格納するメタデータの例を示す図である。

[図 49]図 49は、実施の形態 4における、メタデータを IndexExtentionData Oに格納した場合の例を示す図である。

[図 50]図 50は、実施の形態 4における、 Real PlayList (実シナリオ情報)及び Virta ul PlayList (仮想シナリオ情報）と Shot (撮影または録画した映像単位)との関係を示す図である。

[図 51]図 51は、実施の形態 4における、 Shotの先頭を示す Markと Shotの撮影順との関係を示す図である。

[図 52] (A)は、実施の形態 4における、メタデータのデータ構造の一例を示す図であり、（B)は、（A)に示すメタデータに基づき生成された Shotメニューの一例を示す図である。

[図 53]図 53は、実施の形態 5における、メタデータの一部を IndexExtentionData ( )に格納した場合の例を示す図である。

[図 54]図 54は、実施の形態 5における、メタデータの一部を PlayListExtentionDat a ()に格納した場合の例を示す図である。場合の例を示す図である。

[図 55] (A)は、実施の形態 5における、メタデータのデータ構造の一例を示す図であり、（B)は、（A)に示すメタデータに基づき生成された Shotメニューの一例を示す図である。

[図 56]図 56は、映像の編集により撮影日時情報が失われる例を示す図である。

[図 57]図 57は、実施の形態 6における、 Markを用いて編集時でも撮影日時を保持する方法を示す図である。

[図 58]図 58は、実施の形態 7における、メタデータの格納位置を説明する図である。

[図 59]図 59は、実施の形態 7における、メタデータのデータ構造を説明する図である

[図 60]図 60は、実施の形態 7における、メタデータの識別情報 (ID)と種類とを説明する図である。

[図 61]図 61は、実施の形態 7における、メタデータの取得処理を示すフロー図である

[図 62]図 62は. DVと EXIFで同種情報を持つことを説明する図である。

[図 63]図 63は. 同種情報を持つ場合の記録ルールを説明する図である。

[図 64]図 64は. BD— ROMディスク記録されているストリームのデータ構造を説明する図である。

[図 65]図 65は.従来のスライドショウに係るデータ構造を説明する図である。

[図 66]図 66は.実施の形態 8における、スライドショウに係るデータ構造を説明する図である。

[図 67]図 67は.実施の形態 8における、 Still Unitのデータ構造を説明する図である。 [図 68]図 68は、実施の形態 8における、副映像を用いた静止画スライドショウを説明する図である。

[図 69]図 69は、実施の形態 8における、副映像を用いた静止画スライドショウの作成のための処理の流れを示すフロー図である。

符号の説明

1 BD— ROMプレーヤ

2 オーディオ専用プレーヤ

104 BD-ROM

105 ディスク

202 光ピックアップ

203 プログラム記録メモリ

204 管理情報記録メモリ

205 AV記録メモリ

206 プログラム処理部

207 管理情報処理部

208 プレゼンテーション処理部

209 イメージプレーン

210 ビデ才プレーン

211 合成処理部

302 プログラムプロセッサ

303 UOマネージャ

305 シナリオプロセッサ

306 プレゼンテーションコントローラ

307 クロック

308 イメージメモリ

309 トラックノッファ

310 デマノレチプレクサ

311 イメージプロセッサ 312 ビデオプロセッサ

313 サウンドプロセッサ

317 ドライブコントローラ

400 レコーダ

401 プレイリスト特定部

402 削除部

403 メニュー生成部

404 メーカー判定部

405 受付部

406 編集部

407 番号読出部

408 撮影部

409 表示部

S801 記録 Z編集開始ステップ

S802 BD. INFO, BD. PROG読み込みステップ

S803 タイトル番号取得ステップ

S804 関連ファイル更新ステップ

S805 新規タイトル番号付与ステップ

S806 ダミーデータ付与ステップ

S807 更新済 BD. INFOおよび更新済 BD. PROG書込みステップ発明を実施するための最良の形態

[0061] 以下、添付の図面を参照しながら、本発明を実施するための最良の形態ついて説明する。

[0062] なお、本願請求項 1に係る発明に最も近!、実施の形態は実施の形態 2であるが、理解を容易にするために、実施の形態 2における情報記録媒体等の基本的な構成を説明する実施の形態 1を先に説明する。

[0063] (実施の形態 1)

まず、 BD (Blu—ray Disc) ROMおよび BD— ROMを再生する BD— ROMプレーャの基本的な構成および動作について、図 1〜図 30を用いて説明する。

[0064] (ディスク上の論理データ構造）

図 4は、 BD— ROMのデータ階層を示す図である。

[0065] 図 4に示すように、ディスク媒体である BD—ROM104上には、 AVデータ 103と、

AVデータに関する管理情報及び AV再生シーケンスなどの BD管理情報 102と、ィンタラタティブを実現する BD再生プログラム 101とが記録されている。

[0066] なお、各タイトルの実体データは、 AVデータ 103として存在し、各タイトルのシナリォ制御記述データ（以下、単に「シナリオ」ともいう。）は、 BD管理情報 102として存在する。

[0067] なお、本実施の形態では、映画などの AVコンテンツを再生するための AVアプリケーシヨンを主眼において BD— ROMの説明を行う力 BD— ROMを CD— ROMや DVD— ROMの様にコンピュータ用途の記録媒体として使用することも当然のことな力可能である。

[0068] 図 5は、前述の BD— ROM104に記録されている論理データの構造を示す図である。 BD— ROM104は、他の光ディスク、例えば DVDや CDなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリードインと外周のリードアウトの間に論理データを記録できる論理アドレス空間を有して、る。

[0069] また、リードインの内側には Burst Cutting Area (BCA)と呼ばれる、ドライブでしか読み出せな、特別な領域がある。この領域はアプリケーション力も読み出せな!/ヽため、例えば著作権保護技術などに利用されることがよくある。

[0070] 論理アドレス空間には、ファイルシステム情報 (ボリューム）を先頭に映像データなどのアプリケーションデータが記録されて、る。ファイルシステムとは従来技術で説明した通り、 UDFや ISO9660等の規格により定められたデータを管理する仕組みのことであり、通常の PCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になって、る。

[0071] 本実施の形態の場合、 BD—ROM104上のディレクトリ、ファイル構造は、ルートディレクトリ（ROOT)直下に BD VIDEOディレクトリが置かれている。このディレクトリは BD— ROMで扱う AVデータや管理情報などのデータ（図 4に示す BD再生プログラム 101、 BD管理情報 102、 AVデータ 103)が記録されているディレクトリである。

[0072] BDVIDEOディレクトリの下には、次の 7種類のファイルが記録されている。

[0073] BD. INFO (ファイル名固定）

「BD管理情報」の一つであり、 BD— ROM全体に関する情報を記録したファイルである。 BD— ROMプレーヤは最初にこのファイルを読み出す。

[0074] BD. PROG (ファイル名固定）

「BD再生プログラム」の一つであり、 BD— ROM全体に関わるプログラムを記録したファイルである。

[0075] XXX. PL (「XXX」は可変、拡張子「PL」は固定）

「BD管理情報」の一つであり、シナリオを記録するプレイリスト (Play List)情報を記録したファイルである。プレイリスト毎に 1つのファイルを持っている。

[0076] XXX. PROG (「XXX」は可変、拡張子「PROG」は固定）

「BD再生プログラム」の一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名（「XXX」がー致する）によつて識別される。

[0077] YYY. VOB (「YYY」は可変、拡張子「VOB」は固定）

「AVデータ」の一つであり、 VOB (従来例で説明した VOBと同じ)を記録したフアイルである。 1つの VOBは 1つのファイルに対応する。

[0078] YYY. VOBI (「YYY」は可変、拡張子「VOBI」は固定）

「BD管理情報」の一つであり、 AVデータである VOBに関わる管理情報を記録したファイルである。 VOBとの対応はファイルボディ名（「YYY」が一致する）によって識別される。

[0079] ZZZ. PNG (「ΖΖΖ」は可変、拡張子「PNG」は固定）

「AVデータ」の一つであり、字幕及びメニュー画面を構成するためのイメージデータである PNG (World Wide Web Consortium (W3C)によって標準化された画像フォーマットであり「ビング」と読む。）形式のイメージファイルである。 1つの PNGィメージは 1つのファイルに対応する。

[0080] (プレーヤの構成）次に、前述の BD— ROM104を再生するプレーヤの構成につ!、て図 6及び図 7を用いて説明する。

[0081] 図 6は、 BD— ROM104を再生する BD— ROMプレーヤの基本的な構成の概要を示す図である。

[0082] 図 6に示す BD— ROMプレーヤにおいて、 BD—ROM104上のデータは、光ピックアップ 202を通して読み出される。読み出されたデータはそれぞれのデータの種類に応じて専用のメモリに記録される。

[0083] BD再生プログラム（「BD. PROGJまたは「XXX. PROGJファイル）はプログラム記録メモリ 203に、 BD管理情報（「BD. INFO」、「XXX. PL」または「YYY. VOBI」フアイル）は管理情報記録メモリ 204に、 AVデータ（「YYY. VOB」または「ΖΖΖ. ΡΝ

GJファイル）は AV記録メモリ 205にそれぞれ記録される。

[0084] プログラム記録メモリ 203に記録された BD再生プログラムはプログラム処理部 206 によって処理される。管理情報記録メモリ 204に記録された BD管理情報は管理情報処理部 207によって処理される。

[0085] また、 AV記録メモリ 205に記録された AVデータはプレゼンテーション処理部 208 によって処理される。

[0086] プログラム処理部 206は、管理情報処理部 207から再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムで再生するプレイリストを動的に変更する事が可能であり、この場合は管理情報処理部 207に対して変更後のプレイリストの再生命令を送ることで実現する

[0087] プログラム処理部 206は、更に、ユーザからのイベント、例えば、ユーザが操作するリモコン力ものリクエストを受け付け、ユーザイベントに対応するプログラムがある場合は、実行処理する。

[0088] 管理情報処理部 207は、プログラム処理部 206の指示を受け、その指示に対応するプレイリスト及びそのプレイリストに対応した VOBの管理情報を解析する。更に、プレゼンテーシヨン処理部 208に再生の対象となる AVデータの再生を指示する。

[0089] また、管理情報処理部 207は、プレゼンテーション処理部 208から基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部 208に AVデータ再生の停止指示を行う。更に、プログラム処理部 206に対してプログラム実行タイミングを示すイベントを生成する。

[0090] プレゼンテーション処理部 208は、映像、音声、および字幕それぞれのデータに対応するデコーダを持ち、管理情報処理部 207からの指示に従い、 AVデータのデコード及び出力を行う。映像データ及び字幕データは、デコード後にそれぞれの専用プレーンに描画される。

[0091] 具体的には、映像データはビデオプレーン 210に描画され、字幕データ等のィメージデータはイメージプレーン 209に描画される。更に、 2つのプレーンに描画された映像の合成処理が合成処理部 211によって行われ TVなどの表示デバイスへ出力される。

[0092] 図 6で示すように、 BD— ROMプレーヤは図 4で示した BD— ROM104に記録されて、るデータ構造に基づ!/、た構成をとつて、る。

[0093] 図 7は、図 6に示すプレーヤの構成を詳細化したブロック図である。図 6に示す各構成部と、図 7に示す各構成部との対応は以下の通りである。

[0094] AV記録メモリ 205はイメージメモリ 308とトラックバッファ 309に対応する。プログラム処理部 206はプログラムプロセッサ 302と UO (User Operation)マネージャ 303 に対応する。管理情報処理部 207はシナリオプロセッサ 305とプレゼンテーションコントローラ 306とに対応する。プレゼンテーション処理部 208はクロック 307、デマルチプレクサ 310、イメージプロセッサ 311、ビデオプロセッサ 312とサウンドプロセッサ 313とに対応する。

[0095] BD—ROM104から読み出された VOBデータ（MPEGストリーム）はトラックバッファ 309に、イメージデータ（PNG)はイメージメモリ 308にそれぞれ記録される。

[0096] デマルチプレクサ 310は、クロック 307から得られる時刻に基づき、トラックバッファ 3 09に記録された VOBデータを抜き出す。更に、 VOBデータに含まれる映像データをビデオプロセッサ 312に音声データをサウンドプロセッサ 313にそれぞれ送り込む

[0097] ビデオプロセッサ 312及びサウンドプロセッサ 313はそれぞれ MPEGシステム規格で定められる通りに、デコーダバッファとデコーダ力もそれぞれ構成されている。即ち

、デマルチプレクサ 310から送りこまれる映像、音声それぞれのデータは、それぞれのデコーダバッファに一時的に記録され、クロック 307に従い個々のデコーダでデコード処理される。

[0098] イメージメモリ 308に記録された PNGデータは、次の 2つの処理方法がある。 PNG データが字幕用の場合は、プレゼンテーションコントローラ 306によってデコードタイミングが指示される。クロック 307からの時刻情報をシナリオプロセッサ 305がー且受け、適切な字幕表示が行えるように、字幕表示時刻（開始及び終了）になればプレゼンテーシヨンコントローラ 306に対して字幕の表示、非表示の指示を出す。

[0099] プレゼンテーションコントローラ 306からデコード Z表示の指示を受けたイメージプ口セッサ 311は対応する PNGデータをイメージメモリ 308から抜き出し、デコードし、イメージプレーン 209に描画する。

[0100] また、 PNGデータカ -ユー画面用の場合は、プログラムプロセッサ 302によってデコードタイミングが指示される。プログラムプロセッサ 302が!、つイメージのデコードを指示するかは、プログラムプロセッサ 302が処理している BDプログラムに因るものであって一概には決まらな!/ヽ。

[0101] イメージデータ及び映像データは、図 6で説明したようにそれぞれデコード後にィメージプレーン 209およびビデオプレーン 210に描画され、合成処理部 211によって合成出力される。

[0102] BD—ROM104から読み出された管理情報 (シナリオ、 AV管理情報）は、管理情報記録メモリ 204に記録される力シナリオ情報（「BD. INFO」及び「XXX. PL」）はシナリオプロセッサ 305によって読み出され処理される。また、 AV管理情報（「YYY . VOBI」）はプレゼンテーションコントローラ 306によって読み出され処理される。

[0103] シナリオプロセッサ 305は、プレイリストの情報を解析し、プレイリストによって参照されている VOBとその再生位置をプレゼンテーションコントローラ 306に指示し、プレゼンテーシヨンコントローラ 306は対象となる VOBの管理情報（「YYY. VOBI」）を解祈して、対象となる VOBを読み出すようにドライブコントローラ 317に指示を出す。

[0104] ドライブコントローラ 317はプレゼンテーションコントローラ 306の指示に従い、光ピックアップを移動させ、対象となる AVデータの読み出しを行う。読み出された AVデータは、前述したようにイメージメモリ 308またはトラックバッファ 309に記録される。

[0105] また、シナリオプロセッサ 305は、クロック 307の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ 302に投げる。

[0106] プログラム記録メモリ 203に記録された BDプログラム（「BD. PROG」または「XXX . PROG」）は、プログラムプロセッサ 302によって実行処理される。プログラムプロセッサ 302が BDプログラムを処理するのは、シナリオプロセッサ 305からイベントが送られてきた場合か、 UOマネージャ 303からイベントが送られてきた場合である。

[0107] UOマネージャ 303は、ユーザからリモコンキーによってリクエストが送られてきた場合に、当該リクエストに対応するイベントを生成しプログラムプロセッサ 302に送る。

[0108] このような各構成部の動作により、 BD— ROMの再生がおこなわれる。

[0109] (アプリケーション空間）

図 8は、 BD— ROMのアプリケーション空間を示す図である。

[0110] BD— ROMのアプリケーション空間では、プレイリスト（PlayList)がーつの再生単位になって!/、る。プレイリストはセル（Cell)の再生シーケンス力も構成される静的なシナリオと、プログラムによって記述される動的なシナリオとを有している。

[0111] プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。

[0112] 一方で、プログラムは、プレイリストを超えての再生記述や、ユーザの選択またはプレーャの状態に応じて再生する対象を動的に変えることが可能である。典型的な例としてはメニュー画面を介した再生対象の動的変更が挙げられる。 BD— ROMの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択するための機能の構成要素の 1つである。

[0113] また、ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。

[0114] 時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるィべントである。図 7で説明したシナリオプロセッサ 305からプログラムプロセッサ 302に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ

302は IDによって対応付けられるイベントハンドラを実行処理する。

[0115] 前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。

[0116] ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ュ一ザイベントは大きく 2つのタイプに分けられる。一つ目は、リモコンが備えるカーソルキー（「上」「下」「左」「右」キー）または「決定」キーの操作によって生成されるメニュー選択のイベントである。

[0117] メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効である。つまり、プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている。プログラムプロセッサ 302は、リモコンの「上」「下」「左」「右」キーまたは「決定」キーが押された時に有効なイベントハンドラを検索して、有効なィベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。

[0118] 二つ目のユーザイベントは、「メニュー」キーの操作によって生成されるメニュー画面呼び出しのイベントである。メニュー画面呼び出しのイベントが生成されると、グロ一バルイベントハンドラが呼ばれる。

[0119] グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、 DVDのメニューコールを実装することができる。メニューコールを実装することにより、タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点力ものタイトル再生を実行することができる。

[0120] プレイリストで静的シナリオを構成する単位であるセル（Cell)は VOB (MPEGストリーム）の全部または一部の再生区間を参照したものである。セルは VOB内の再生区間を開始、終了時刻の情報として持っている。個々の VOBと一対になっている VOB 管理情報 (VOBI)は、その内部にタイムマップ (Time Mapまたは TM)を有しており、このタイムマップによって前述した VOBの再生、終了時刻を VOB内（即ち対象となるファイル「YYY. VOBJ内）での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は図 14を用いて後述する。

[0121] (VOBの詳細）

図 9は、本実施の形態で使用する MPEGストリーム (VOB)の構成を示す図である。図 9に示すように、 VOBは複数の Video Object Unit (VOBU)によって構成されている。 VOBUは、 MPEGビデオストリームにおける Group Of Pictures (GOP )を基準とする単位であり、音声データも含んだ多重化ストリームとしての一再生単位である。

[0122] VOBUは 0. 4秒から 1. 0秒の再生時間を持ち、通常は 0. 5秒の再生時間を持つている。これは MPEGの GOPの構造が通常は 15フレーム Z秒（NTSCの場合）であることによって導力れるものである。

[0123] VOBUは、その内部に映像データであるビデオパック (V— PCK)と、音声データであるオーディオパック (A— PCK)とを有している。各パックは 1セクタで構成され、本実施の形態の場合は 2kB単位で構成されて、る。

[0124] 図 10は、 MPEGストリームにおけるパックの構成を示す図である。

[0125] 図 10に示すように、映像データ及び音声データといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭力順次入れられて、く。ペイ口一ドにはパケットヘッダが付けられ 1つのパケットを構成する。

[0126] パケットヘッダには、ペイロードに格納してあるデータがどのストリームのデータであるのかを示す情報、映像データであるのか音声データであるのかを示す情報、また、映像データまたは音声データがそれぞれ複数ストリームある場合は、どのストリームのデータなのかを識別するための ID (stream— id)、および、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプである Decode Time Stamp (DTS)及び Presentation Time Stamp (PTS)が記録されている。

[0127] DTSおよび PTSは必ずしも全てのパケットヘッダに記録されている訳ではなぐ M PEGによって記録するルールが規定されている。ルールの詳細については MPEG システム（ISOZIEC13818— 1)規格書に記述されているので省略する。

[0128] パケットには更にヘッダ (パックヘッダ）が付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプである System Clock Refer ence (SCR)が記録されて!、る。

[0129] (VOBのインターリーブ記録）

図 11及び図 12を用いて VOBファイルのインターリーブ記録につ!、て説明する。

[0130] 図 11は、 AVデータと BD— ROMプレーヤの構成との関係を説明するための図である。

[0131] 図 11上段の図は、図 7を用いて前述したプレーヤ構成図の一部である。図の通り、 BD— ROM上のデータは、光ピックアップを通して VOB即ち MPEGストリームであればトラックバッファ 309へ入力され、 PNG即ちイメージデータであればイメージメモリ 308へと入力される。

[0132] トラックバッファ 309は First— In First— Out (FIFO)であり、入力された VOBのデータは入力された順にデマルチプレクサ 310へと送られる。この時、前述した SCR に従って個々のパックはトラックバッファ 309から引き抜かれデマルチプレクサ 310を介してビデオプロセッサ 312またはサウンドプロセッサ 313へとデータが送り届けられる。

[0133] 一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラ 306 (図 7参照）によって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリ 308から削除される力メ- ユー用のイメージデータの場合は、イメージメモリ内にそのまま残される。

[0134] これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。

[0135] 図 11下段の図は、 BD— ROM上での VOBフアイノレ及び PNGフアイノレのインターリーブ記録を示す図である。

[0136] 一般的に ROM、例えば CD— ROMや DVD— ROMの場合、一連の連続再生単位となる AVデータは連続記録されている。連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけでよい。

[0137] し力しながら、連続再生すべき AVデータが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになる。つまり、データの供給が止まる可能性がある。

[0138] BD— ROMの場合も同様に、 VOBファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのように VOBに記録されている映像データと同期して再生されるデータがあり、 VOBファイルと同様に字幕データも何らかの方法によつて BD— ROM力も読み出す事が必要になる。

[0139] 字幕データの読み出し方法の一手段として、 VOBの再生開始前に一まとめで字幕用のイメージデータ（PNGファイル）を読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、現実的ではない。

[0140] そこで、本実施の形態では、 VOBファイルを幾つかのブロックに分けて、 VOBファィルとイメージデータとをインターリーブ記録する方式を使用する。

[0141] 図 11下段はそのインターリーブ記録を説明するための図である。 VOBファイルとィメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可會になる。

[0142] し力しながらイメージデータを読み出している際には、 VOBデータの読み込みは当然のことながら停止することになる。

[0143] 図 12は、上記のインターリーブ記録における問題を解決するトラックバッファ 309を使った VOBデータ連続供給モデルを説明するための図である。

[0144] 既に説明したように、 VOBのデータは、ー且トラックバッファ 309に蓄積される。トラックバッファ 309へのデータ入力レートをトラックバッファ 309からのデータ出力レートより高く設定すると、 BD— ROM力データを読み出し続けている限り、トラックバッファ 309のデータ蓄積量は増加をして、くことになる。

[0145] ここでトラックバッファ 309への入力レートを Va、トラックバッファからの出力レートを Vbとする。図 12の上段の図に示すように VOBの一連続記録領域が論理アドレスの" al"から" a2"まで続くとする。また、 "a2"から" a3"の間は、イメージデータが記録されていて、 VOBデータの読み出しが行えない区間であるとする。

[0146] 図 12の下段の図は、トラックバッファ 309の蓄積量を示す図である。横軸が時間、縦軸がトラックバッファ 309内部に蓄積されているデータ量を示している。時刻" tl" が VOBの一連続記録領域の開始点である" al"の読み出しを開始した時刻を示している。

[0147] この時刻以降、トラックバッファ 309にはレート Va—Vbでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻 "t2"は一連続記録領域の終了点である" a2"のデータを読み込む時刻である。

[0148] 即ち時刻" tl"から" t2"の間レート Va— Vbでトラックバッファ内はデータ量が増加していき、時刻" t2"でのデータ蓄積量は B (t2)は下記の（式 1)によって求めることができる。

[0149] B (t2) = (Va-Vb) X (t2~tl) (式 1)

[0150] この後、 BD— ROM上のアドレス" a3"まではイメージデータが続くため、トラックバッファへの入力は 0となり、出力レートである" Vb"でトラックバッファ内のデータ量は減少していくことになる。このデータ量の減少は読み出し位置" a3"まで、つまり、時刻でいう" t3"まで続く。

[0151] ここで大事なことは、時刻" t3"より前にトラックバッファに蓄積されているデータ量が

0になると、デコーダへ供給する VOBのデータが無くなってしまい、 VOBの再生がストップしてしまうことである。

[0152] しかしながら、時刻" t3"でトラックバッファにデータが残っている場合には、 VOBの再生がストップすることなく連続して行われることを意味している。

[0153] この VOBの再生がストップすることなく連続して行われるための条件は下記の（式 2

)によって示すことができる。

[0154] B (t2) ≥ Vb X (t3— 12) (式 2)

[0155] 即ち、（式 2)を満たすようにイメージデータの配置を決めればよい事になる。

[0156] (ナビゲーシヨンデータ構造）

図 13力ら図 19を用いて、 BD— ROMに記録されたナビゲーシヨンデータ（BD管理情報)の構造について説明をする。

[0157] 図 13は、 VOB管理情報ファイル（"YYY. VOBI")の内部構造を示す図である。

[0158] VOB管理情報は、当該 VOBのストリーム属性情報 (Attribute)とタイムマップ (T MAP)とを有している。ストリーム属性情報は、ビデオ属性 (Video)、オーディオ属性 (Audio # 0〜Audio # m)個々に持つ構成となっている。特にオーディオストリームの場合は、 VOBが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数（Number)によって、オーディオ属性のデータフィールドの数が特定される。

[0159] 下記はビデオ属性 (Video)の持つフィールドとそれぞれが持ち得る値の例である。

[0160] 圧縮方式 (Coding) :

MPEG1

MPEG2

MPEG4

解像度（Resolution)：

1920x1080

1280x720

720x480

720x565

アスペクト比（Aspect)：

4 : 3

16 : 9

フレ¹ ~~ムレ¹ ~~ト (Framerate)：

60

59. 94

50

30

29. 97

25

24

[0161] 下記はオーディオ属性 (Audio)の持つフィールドとそれぞれが持ち得る値の例である。 [0162] 圧縮方式 (Coding) :

AC 3

MPEG1

MPEG2

LPCM

チャンネル数（Ch)：

1〜8

m 属性 (Language)：

JPN、 ENG、 · · ·

[0163] タイムマップ (TMAP)は VOBU毎の情報を持つテーブルであって、当該 VOBが有する VOBU数（Number)と各 VOBU情報（VOBU # l〜VOBU # n)を持つ。

[0164] 個々の VOBU情報は、 VOBUの再生時間長（Duration)と VOBUのデータサイズ（Size)とを有している。

[0165] 図 14は、 VOBU情報の詳細を説明するための図である。

[0166] 広く知られているように、 MPEGストリームは時間的側面とデータサイズとしての側面との 2つの物理量についての側面を有している。例えば、音声の圧縮規格である A udio Code number 3 (AC3)は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は 1次式によって求めることができる。

[0167] しかしながら MPEGビデオデータの場合、個々のフレームは固定の表示時間、例えば NTSCの場合、 1フレームは 1Z29. 97秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、、わゆる IZ PZBピクチャによってデータサイズは大きく変わってくる。

[0168] 従って、 MPEGビデオの場合は、時間とアドレスとの関係は一般式の形で表現することは不可能である。

[0169] 当然の事として、 MPEGビデオデータを多重化している MPEGストリーム、即ち VO Bについても、時間とデータとを一般式の形で表現することは不可能である。

[0170] これに代わって、 VOB内での時間とアドレスとの関係を結びつけるのがタイムマツプ（TMAP)である。図 14に示すように、 VOBU毎に VOBU内のフレーム数と、 VO BU内のパック数とをそれぞれエントリとして持つテーブルがタイムマップ（TMAP)である。

[0171] 図 15を使って、タイムマップ (TMAP)の使い方を説明する。

[0172] 図 15は、タイムマップを使ったアドレス情報取得方法を説明するための図である。

[0173] 図 15に示すように時刻情報 (Time)が与えられた場合、まずは当該時刻がどの VO

BUに属するのかを検索する。具体的には、タイムマップの VOBU毎のフレーム数を加算して行き、フレーム数の和が、当該時刻をフレーム数に換算した値を超えるまたは一致する VOBUが当該時刻に対応する VOBUになる。

[0174] 次に、タイムマップの VOBU毎のサイズを当該 VOBUの直前の VOBUまで力卩算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレス（Address)になっている。

[0175] このようにして、 MPEGストリームにおいて、与えられた時刻情報に対応するァドレスを得ることができる。

[0176] 次に図 16を使って、プレイリスト（"XXX. PL")の内部構造を説明する。

[0177] 図 16は、プレイリストの構成を示す図である。

[0178] プレイリストは、セルリスト（CellList)とイベントリスト（EventList)とから構成されている。

[0179] セルリスト（CellList)は、プレイリスト内の再生セルシーケンスを示す情報であり、本リストの記述順でセルが再生される事になる。

[0180] セルリスト（CellList)の中身は、セルの数（Number)と各セル情報（Cell # l〜Cel l # n)である。

[0181] 各セル情報（Cell #〜Cell# n)は、 VOBファイル名 (VOBName) ,当該 VOB内での有効区間開始時刻（In)及び有効区間終了時刻 (Out)と、字幕テーブル (Subt itleTable)を持っている。

[0182] 有効区間開始時刻 (In)及び有効区間終了時刻 (Out)は、それぞれ当該 VOB内でのフレーム番号で表現され、前述したタイムマップ (TMAP)を使うことによって再生に必要な VOBデータのアドレスを得る事ができる。

[0183] 字幕テーブル (SubtitleTable)は、当該 VOBと同期再生される字幕情報を持つテ一ブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブル (Sub titleTable)は言語数 (Number)とそれに続く個々の言語ごとのテーブル (Langua ge # 1〜： Language # k)とから構成されて、る。

[0184] 各言語のテーブル (Language # 1〜： Language # k)は、言語情報（Language)と、表示される字幕の字幕情報数 (Number)と、表示される字幕の字幕情報 (Speech # l〜Speech #j)とから構成され、各字幕情報（Speech# l〜Speech #j)は対応するイメージデータファイル名（Name)、字幕表示開始時刻（In)及び字幕表示終了時刻 (Out)と、字幕の表示位置 (Position)とから構成されて、る。

[0185] イベントリスト (EventList)は、当該プレイリスト内で発生するイベントを定義したテ一ブルである。イベントリストは、イベント数（Number)に続いて個々のイベント（Eve nt # l〜Event # m)とから構成され、各イベント（Event # l〜Event # m)は、ィべントの種類 (Type)、イベントの ID (ID)、イベント生成時刻（Time)と有効期間（Dura tion)とから構成されて、る。

[0186] 図 17は、個々のプレイリスト毎のイベントハンドラ（時間イベントと、メニュー選択用のユーザイベント）を持つイベントハンドラテーブル ("XXX. PROG")の構成を示す図である。

[0187] イベントハンドラテーブルは、定義されているイベントハンドラ Zプログラム数 (Num ber)と個々のイベントハンドラ Zプログラム（Program # l〜Program # n)を有している。

[0188] 各イベントハンドラ Zプログラム (Program # l〜Program # n)内の記述は、ィべントハンドラ開始の定義（く event— handler >タグ）と前述したイベントの IDと対になるイベントハンドラの ID (event— handler id)を持ち、その後に当該プログラムが" f unction"に続く括弧" { "ど ' } "との間に記述される。

[0189] 次に図 18を用いて BD— ROM全体に関する情報（"BD. INFO")の内部構造について説明をする。

[0190] 図 18は、 BD— ROM全体情報である BD. INFOの構成を示す図である。

[0191] BD— ROM全体情報は、タイトルリスト（TitleList)とグローバルイベント用のィベントリスト（EventList)とから構成されてヽる。 [0192] タイトルリスト（TitleList)は、ディスク内のタイトル数（Number)と、これに続く各タィトル情報 (Title # l〜Title # n)と力ら構成されて、る。

[0193] 各タイトル情報 (Titlel〜Title # n)は、タイトルに含まれるプレイリストのテーブル ( PLTalble)とタイトル内のチャプターリスト (ChapterList)とを含んで!/、る。プレイリストのテーブル（PLTable)はタイトル内のプレイリストの数（Number)と、プレイリスト名 (Name)即ちプレイリストのファイル名を有して!/、る。

[0194] チャプターリスト (ChapterList)は、当該タイトルに含まれるチャプター数（Numbe r)と各チャプター情報（Chapter # l〜Chapter # n)とから構成され、各チャプター情報（Chapter# l〜Chapter# n)は当該チャプターが含むセルのテーブル（Cell Table)を持ち、セルのテーブル (CellTable)はセル数 (Number)と各セルのェントリ情報（CellEntry # l〜CellEntry # k)と力構成されて、る。

[0195] セルのエントリ情報（CellEntry # l〜CellEntry # k)は当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。

[0196] イベントリスト（EventList)は、グローバルイベントの数（Number)と各グローバルイベントの情報（Event # l〜Event # m)とを持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベント（FirstEvent)と呼ばれ、 BD ROMがプレーヤに挿入された時、最初に実行されるイベントである。

[0197] 各グローバルイベントの情報（Event # l〜Event # m)はイベントタイプ（Type)とイベントの ID (ID)だけを持って!/、る。

[0198] 図 19は、グローバルイベントハンドラテーブル（"BD. PROG")の構成を示す図である。本テーブルは、図 17で説明したイベントハンドラテーブルと同一内容であり、その説明は省略する。

[0199] (イベント発生のメカニズム）

図 20から図 22を使ってイベント発生のメカニズムについて説明する。

[0200] 図 20は、タイムイベントの例を示す図である。

[0201] 前述したとおり、タイムイベントはプレイリスト（"XXX. PL")のイベントリスト（Event List)で定義される。

[0202] タイムイベントとして定義されて、るイベント、即ちイベントタイプ (Type)力 S"TimeE vent"の場合、イベント生成時刻（"tl")になった時点で、 ID"Exl"を持つタイムィべントがシナリオプロセッサ 305からプログラムプロセッサ 302に対して出力される。

[0203] プログラムプロセッサ 302は、イベント ID"Exl"を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、 2つのボタンイメージの描画を行うことなどが可能である。

[0204] 図 21は、ユーザのメニュー操作によるユーザイベントの例を示す図である。

[0205] 前述したとおり、メニュー操作によるユーザイベントもプレイリスト（"XXX. PL")のィベントリスト（EventList)で定義される。

[0206] ユーザイベントとして定義されるイベント、即ちイベントタイプ（Type)力 ' UserEven t"の場合、イベント生成時刻 ("tl")になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。

[0207] 当該イベントは、有効規格情報 (Duration)で記される期間（"T1")レディ状態にある。

[0208] 図 21に示すように、ユーザによりリモコンキーの「上」「下」「左」「右」キーの、ずれかのキー、または「決定」キーが押された場合、まず UOイベントが UOマネージャ 303 によって生成されプログラムプロセッサ 302に出力される。

[0209] プログラムプロセッサ 302は、シナリオプロセッサ 305に対して UOイベントを流し、シナリオプロセッサ 305は UOイベントを受け取った時刻に有効なユーザイベントが存在するかを検索する。

[0210] シナリオプロセッサ 305は、検索の結果、対象となるユーザイベントがあった場合、ユーザイベントを生成し、プログラムプロセッサ 302に出力する。

[0211] プログラムプロセッサ 302では、イベント、例えば、図 21に示す例の場合では" E vl"を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。本例の場合、プレイリスト # 2の再生を開始する。

[0212] 生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、 UOイベントによってプログラムプロセッサ 302に伝えられ、仮想プレーヤが持つレジスタに記録保持される。

[0213] イベントハンドラのプログラムは、このレジスタの値を調べ、分岐処理を実行することが可能である。

[0214] 図 22は、グローバルイベントの例を示す図である。

[0215] 前述のように、グローバルイベントは BD— ROM全体情報（"BD. INFO")のィべントリスト（EventList)で定義される。

[0216] グローバルイベントとして定義されるイベント、即ちイベントタイプ (Type)が" Global

Event"であるイベントは、ユーザのリモコンキー操作があった場合にのみ生成される

[0217] ユーザによりメニューキーが押された場合、先ず UOイベントが UOマネージャ 303 によって生成されプログラムプロセッサ 302に出力される。プログラムプロセッサ 302 は、シナリオプロセッサ 305に対して UOイベントを流す。

[0218] シナリオプロセッサ 305は、該当するグローバルイベントを生成し、プログラムプロセッサ 302に送る。プログラムプロセッサ 302は、イベント ID"menu"を持つイベントノヽンドラを探し、対象のイベントハンドラを実行する。例えば、図 22に示す例の場合、プレイリスト # 3の再生を開始して、る。

[0219] 本実施の形態では、単にメニューキーと呼んでいる力 DVDを再生するプレーヤにおけるリモコンのように複数のメニューキーがあってもよい。各メニューキーに対応する IDをそれぞれ定義することで各メニューキーに対応する適切な処理が可能である。

[0220] (仮想プレーヤマシン）

図 23は、プログラムプロセッサの機能的な構成を説明するための図である。

[0221] 図 23を用いてプログラムプロセッサ 302の機能的な構成を説明する。

[0222] プログラムプロセッサ 302は、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンは BD— ROMとして定義された機能モデルであって、各 B

D— ROMプレーヤの実装には依存しないものである。即ち、どの BD— ROMプレーャにお、ても同様の機能を実行できることを保証して！/、る。

[0223] 仮想プレーヤマシンは大きく 2つの機能を持っている。プログラミング関数とプレーャ変数 (レジスタ）である。

[0224] プログラミング関数は、 Java (登録商標） Scriptをベースとして、以下に記す 3つの機能を BD— ROM固有関数として定義している。

[0225] リンク関数:現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始する

Link (PL # , Cell # , time)

PL # ：プレイリスト名

Cell # ：セル番号

time ：セル内での再生開始時刻

PNG描画関数：指定 PNGデータをイメージプレーンに描画する

Draw (File, X, Y)

File ： PNGファイル名

X ： X座標位置

Y ： Y座標位置

イメージプレーンクリア関数:イメージプレーンの指定領域をクリアする Clear (X, Y, W, H)

X ： X座標位置

Y ： Y座標位置

W ： X方向幅

H ： Y方向幅

[0226] また、プレーヤ変数は、プレーヤの状態を示すシステムパラメータ（SPRM)と、一般用途として使用可能なゼネラルパラメータ（GPRM)とがある。

[0227] 図 24は、システムパラメータ（SPRM)の一覧を示す図である。

[0228] SPRM (0) ：言語コード

SPRM (l) ：音声ストリーム番号

SPRM (2) ：字幕ストリーム番号

SPRM (3) ：アングル番号

SPRM (4) ：タイトル番号

SPRM (5) ：チャプター番号

SPRM (6) ：プログラム番号 SPRM (7) ：セル番号

SPRM (8) ：選択キー情報

SPRM (9) ：ナビゲーシヨンタイマー

SPRM (10) ：再生時刻情報

SPRM (11) ：カラオケ用ミキシングモード、

SPRM (12) ：パレンタル用国情報

SPRM (13) ：ノレンタノレレべノレ

SPRM (14) ：プレーヤ設定値 (ビデオ)

SPRM (15) ：プレーヤ設定値 (オーディオ）

SPRM (16) ：音声ストリ -ム用目ロロ"¹¹ ~ -ド、

SPRM (17) ：音声ストリ -ム用目ロロ"¹¹ ~ -ド (拡張)

SPRM (18) ：字幕ストリ -ム用目ロロ"¹¹ ~ -ド、

SPRM (19) ：字幕ストリ -ム用目ロロ"^{1 1} ~ -ド (拡張)

SPRM (20) ：プレーヤリ、一ジョンコード

SPRM (21) ：予備

SPRM (22) ：予備

SPRM (23) ：再生状態

SPRM (24) ：予備

SPRM (25) ：予備

SPRM (26) ：予備

SPRM (27) ：予備

SPRM (28) ：予備

SPRM (29) ：予備

SPRM (30) ：予備

SPRM (31) ：予備

なお、本実施の形態では、仮想プレーヤのプログラミング関数を Java (登録商標） Scriptベースとしたが、 Java (登録商標） Scriptではなぐ UNIX (登録商標） OS などで使われている B— Shellや、 Perl Scriptなど他のプログラミング関数であってもよ、。言、換えれば、本発明における使用プログラム言語 «Java (登録商標） Scr iptに限定されるものでは無、。

[0230] (プログラムの例）

図 25及び図 26は、イベントハンドラにおけるプログラムの例を示す図である。

[0231] 図 25は、 2つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。

[0232] セル（PlayList # l. Cell # 1)先頭でタイムイベントを使って図 25左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つ GPRM (O)に" 1"がセットされている。 GPRM (O)は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン 1が選択されている状態を初期値として持たされて、る。

[0233] 次に、 PNGの描画を描画関数である" Draw"を使ってボタン 1、ボタン 2それぞれについて行っている。ボタン 1は、座標（10、 200)を起点（左上端）として PNGィメージ" lblack. png"を描画している。ボタン 2は、座標（330, 200)を起点（左上端）として PNGイメージ" 2white. png"を描画して!/、る。

[0234] また、本セル最後ではタイムイベントを使って図 25右側のプログラムが実行される。

ここでは、 Link関数を使って当該セルの先頭力も再度再生するように指定している。

[0235] 図 26は、メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。

[0236] 「左」キー、「右」キー、「決定」キー何れかのリモコンキーが押された場合それぞれに対応するプログラムがイベントハンドラに書かれて、る。ユーザによりリモコンキーが押された場合、図 21を用いて説明したように、ユーザイベントが生成され、図 26のイベントハンドラが起動されることになる。

[0237] 本イベントハンドラでは、選択ボタンを識別して、る GPRM (0)の値と、選択されたリモコンキーを識別する SPRM (8)を使って以下のように分岐処理を行って!/ヽる。

[0238] 条件 1)ボタン 1が選択されている、かつ、選択キーが「右」キーの場合

GPRM (0)を 2に再設定して、選択状態にあるボタンを右のボタン 2に変更する。ボタン 1、ボタン 2のイメージをそれぞれ書き換える。 [0239] 条件 2)選択キーが「決定 (OK)」の場合で、ボタン 1が選択されて、る場合プレイリスト # 2の再生を開始する。

[0240] 条件 3)選択キーが「決定 (OK)」の場合で、ボタン 2が選択されて、る場合

プレイリスト # 3の再生を開始する。

[0241] 図 26に示すプログラムは、上記のように解釈され実行される。

[0242] (プレーヤ処理フロー）

図 27から図 30を用いてプレーヤでの処理の流れを説明する。

[0243] 図 27は、 BD— ROMプレーヤにおける AVデータ再生の基本処理の流れを示すフロー図である。

[0244] BD— ROMが挿入されると（S101)、 BD— ROMプレーヤは" BD. INFO"の読み込みと解析（S 102)、および、 "BD. PROG"の読み込み（S 103)を実行する。 "BD . INFO"及び" BD. PROG"は共に管理情報記録メモリ 204にー且格納され、シナリォプロセッサ 305によって解析される。

[0245] 続いて、シナリオプロセッサ 305は、 "BD. INFO"ファイル内のファーストイベント（ FirstEvent)情報に従い、最初のイベントを生成する（S 104)。生成されたファーストイベントは、プログラムプロセッサ 302で受け取られ、当該イベントに対応するイベントハンドラを実行処理する（S 105)。

[0246] ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリストを指定する情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなぐユーザイベントを受け付けるのを待ち続けるだけになる（S201で No)。

[0247] UOマネージャ 303は、ユーザからのリモコン操作を受け付けると（S201で Yes)、プログラムプロセッサ 302に対する UOイベントを生成する（S202)。

[0248] プログラムプロセッサ 302は、 UOイベントがメニューキーによるものであるかを判別し（S203)、メニューキーの場合（S203で Yes)は、シナリオプロセッサ 305に UOィベントを流し、シナリオプロセッサ 305がユーザイベントを生成する（S204)。プロダラムプロセッサ 302は生成されたユーザイベントに対応するイベントハンドラを実行処理する（S205)。 [0249] 図 28は、 BD— ROMプレーヤにおけるプレイリスト再生開始から VOB再生終了までの処理の流れを示すフロー図である。

[0250] 前述したように、ファーストイベントハンドラまたはグローバノレイベントハンドラによつてプレイリスト再生が開始される（S301)。シナリオプロセッサ 305は、再生対象のプレイリスト再生に必要な情報として、プレイリスド' XXX. PL"の読み込みと解析 (S30 2)、および、プレイリストに対応するプログラム情報" XXX. PROG"の読み込みを行う（S303)。

[0251] 続いてシナリオプロセッサ 305は、プレイリストに登録されているセル情報に基づいてセルの再生を開始する（S304)。セル再生は、シナリオプロセッサからプレゼンテーシヨンコントローラ 306に対して要求が出される事を意味し、プレゼンテーションコントローラ 306は AVデータ再生を開始する（S 305)。

[0252] AVデータの再生が開始されると、プレゼンテーションコントローラ 306は、再生するセルに対応する VOBの情報ファイル" XXX. VOBI"を読み込み（S402)、解析する。プレゼンテーションコントローラ 306は、タイムマップを使って再生開始する VOBU とそのアドレスを特定し、ドライブコントローラ 317に読み出しアドレスを指示する。ドライブコントローラ 317は対象となる VOBデータ" YYY. VOB"を読み出す（S403)。

[0253] 読み出された VOBデータはデコーダに送られ再生が開始される（S404)。 VOB再生は、当該 VOBの再生区間が終了するまで続けられ (S405)、終了すると次のセルが存在する場合（S406で Yes)、 Cellの再生（S304)へ移行する。また、次のセルが無い場合（S406で No)は、再生に係る処理が終了する。

[0254] 図 29は、 AVデータ再生開始後からのイベント処理の流れを示すフロー図である。

[0255] 図 29 (A)は、 BD— ROMプレーヤにおけるタイムイベントに係る処理の流れを示すフロー図である。

[0256] なお、 BD— ROMプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスがそれぞれ起動され、平行してイベント処理を実行するようになる。

[0257] BD— ROMプレーヤにおいてプレイリスト再生の再生が開始されると（S501)、プレイリスト再生が終了していないことが確認され（S502で No)、シナリオプロセッサ 305 は、タイムイベント発生時刻になつたかを確認する。

[0258] タイムイベント発生時刻になっている場合（S503で Yes)には、シナリオプロセッサ 3

05はタイムイベントを生成する（S504)。プログラムプロセッサ 302はタイムイベントを受け取り、イベントハンドラを実行処理する（S505)。

[0259] また、タイムイベント発生時刻になっていない場合（S503で No)、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認 (S502)以降の処理を繰り返す。

[0260] また、プレイリスト再生が終了したことが確認されると（S502で Yes)、タイムイベント系の処理は強制的に終了する。

[0261] 図 29 (B)は、 BD— ROMプレーヤにおけるユーザイベントに係る処理の流れを示すフロー図である。

[0262] BD— ROMプレーヤ 1においてプレイリストの再生が開始されると（S601)、プレイリスト再生が終了していないことが確認され（S602で No)、 UOマネージャ 303は、 U Oの受け付けがあつたかを確認する。

[0263] UOの受け付けがあった場合（S603で Yes)、 UOマネージャ 303は UOイベントを生成する（S604)。プログラムプロセッサ 302は UOイベントを受け取り、その UOィべントがメニューコールであるかを確認する。

[0264] メニューコールであった場合（S605で Yes)、プログラムプロセッサ 302はシナリオプロセッサ 305にイベントを生成させ（S607)、プログラムプロセッサ 302はイベントハンドラを実行処理する（S608)。

[0265] また、 UOイベントがメニューコールで無!、と判断された場合（S605で No)、 UOィベントはカーソルキーまたは「決定」キーによるイベントである事を示して、る。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサ 305が判断し、有効期間内である場合（S606で Yes)には、シナリオプロセッサ 305がユーザィベントを生成し（S607)、プログラムプロセッサ 302が対象のイベントハンドラを実行処理する（S608)。

[0266] また、 UO受付が無い場合 (S603で No)、現在時刻がユーザイベント有効期間内にない場合（S606で No)、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認 (S602)以降の処理を繰り返す。

[0267] また、プレイリスト再生が終了したことが確認されると（S602で Yes)、ユーザィベント系の処理は強制的に終了する。

[0268] 図 30は、 BD— ROMプレーヤにおける字幕データの処理の流れを示すフロー図である。

[0269] BD— ROMプレーヤにおいてプレイリストの再生が開始されると、プレイリスト再生が終了していないことが確認され（S702で No)、シナリオプロセッサ 305は、字幕表示開始時刻になつたかを確認する。字幕表示開始時刻になって!/ヽる場合 (S703で Yes)、シナリオプロセッサ 305はプレゼンテーションコントローラ 306に字幕描画を指示し、プレゼンテーションコントローラ 306はイメージプロセッサ 311に字幕描画を指示する。イメージプロセッサ 311は、その指示に従い字幕をイメージプレーン 209に字幕を描画する (S704)。

[0270] また、字幕表示開始時刻になっていない場合 (S703で No)、字幕表示終了時刻であるかを確認する。字幕表示終了時刻であると判断された場合 (S705で Yes)、プレゼンテーシヨンコントローラ 306がイメージプロセッサ 311に字幕消去指示を行う。

[0271] イメージプロセッサ 311は、その指示に従い描画されている字幕をイメージプレーン 209から消去する（S706)。

[0272] また、イメージプロセッサ 311による字幕描画 (S704)が終了した場合、イメージプ口セッサ 311による字幕消去（S706)のが終了した場合、および、字幕表示終了時刻でないと判断 (S705で No)された場合、プレイリスト再生の終了確認 (S702)以降の処理を繰り返す。

[0273] また、プレイリスト再生が終了したことが確認されると（S702で Yes)、字幕表示系の処理は強制的に終了する。

[0274] 以上の動作により、 BD— ROMプレーヤは、ユーザの指示または BD— ROMに記録されている BD管理情報等に基づき、 BD— ROMの再生に係る基本的な処理を行

[0275] (実施の形態 2)

次に本発明の実施の形態 2について説明する。 [0276] 基本的には、実施の形態 1に基づく内容であり、拡張した部分または異なる部分を中心に説明する。

[0277] なお、実施の形態 2では、実施の形態 1に記載のデータ構造を基本のデータ構造として有するディスクを用い、本発明の特徴であるディスクメニューに関するデータ構造について説明を行う。

[0278] また、このディスクに情報を記録し、記録した情報を編集する記録装置としてビデオカメラを想定し、ビデオカメラの構成および動作にっ、ても説明を行う。

[0279] 図 31は、実施の形態 2におけるディスクを使用するレコーダおよびプレーヤにおけるメニュー表示の例を示す図である。

[0280] 図 31に示す、 Recorder— Aおよび Recorder— Bは、それぞれ A社および B社のレコーダである。また、各レコーダには、複数のコンテンツが記録されたディスクがセットされた状態である。

[0281] 図 31の上段は、それぞれのレコーダが表示する機器メニューの例を示している。

[0282] 機器メニューとは、レコーダ力自機にセットされたディスクに記録されているタイトルの名前等を、自機の表示部または自機に接続された表示装置に表示することを目的とする簡易なメニューである。

[0283] なお、 "タイトル"とは、デジタルストリームの一部または全部である部分区間で構成される AVコンテンツである。また、タイトルに関連するプレイリストにより、 MPEGストリーム等のデジタルストリームにおける部分区間の位置と、再生順序とが指定されることで当該タイトルが特定される。例えば、ユーザが撮影した 1つの映像コンテンツが 1 つのタイトルとしてディスクに記録される。

[0284] 図に示すように、 Recorder— Aが表示する機器メニューは、ディスクに記録されて

V、るタイトルのサムネイルを複数並べて表示して、る。

[0285] また、 Recorder— Bが表示する機器メニューは、ディスクに記録されているコンテンッの記録日時をリスト形式で表示して、る。

[0286] このようにサムネイル等を用いて機器が独自に生成したメニューを表示するのは以下の理由による。すなわち、記録 Z撮影の日付やサムネイル (JPEG)の表示は処理時間が少なくユーザレスポンスが良いこと、および、ビデオカメラのような小さい表示デバイスしか装備して！/ヽなヽ機器にて適切なメニュー表示を行うためである。

[0287] これらレコーダは、機器メニューのほかに、ディスクメニューを生成し、ディスクに記録する機能を有している。

[0288] 図 31の下段は、各レコーダが生成しディスクに記録したディスクメニューの例を示す図である。これらディスクメニューは各レコーダでは再生されず、当該ディスクを再生するプレーヤによって再生され、ユーザに提示される。

[0289] ディスクメニューは、"タイトル"の一種であり、自身以外のタイトルをユーザに選択させるものである。また、このように、レコーダにより生成されディスク等の情報記録媒体に記録される。

[0290] 具体的には、実施の形態 1で説明した BD. INFOや BD. PROGなどによって提供される機能によって構成されるメニューであって、 TVに接続されたプレーヤにて再生されることを想定して、るメニューである。

[0291] そのため、大きな画面上に様々な情報を表示するように設計され、前述の機器メ- ユーとは異なり、アニメーション効果や階層化された論理構成などを用いることもあり見た目も良い場合が多い。

[0292] 図に示すように、レコーダごとにディスクメニューのデザインが異なるため、同じような記録 Z撮影を行っても図の下段のように異なる表示方式 (デザイン)のディスクメ- ユーが生成される。

[0293] このように、 A社のレコーダ Recorder— Aと B社のレコーダ Recorder— Bでは、ディスクメニューが異なる。これは、ディスクメニューの実装はレコーダのメーカーごとに自由であるためである。

[0294] そのため、レコーダやビデオカメラ等の機器において、他のメーカーの機器でディスクメニューが記録されたディスクがセットされた場合、このディスクメニューを解釈できないことにより、前述のように、ディスクメニューの削除に伴う処理時間の増加等の問題が発生する。この問題につ!、ての詳細は図 34を用、て後述する。

[0295] 図 32は、実施の形態 2における BD. INFOの内容を示す図である。図に示すように BD. INFOには、ディスクに記録されているタイトルを識別する情報群を格納する領域である" Index"が存在する。当該ディスクを再生するプレーヤは、この" Index" に格納されている情報に基づき、タイトルの再生等を行う。

[0296] なお、 "Index"に格納されて、る情報は、本発明の情報記録媒体におけるインデッタス情報の一例である。

[0297] また、 "Index"には、 "FirstPlayback", "TopMenu，，、および" Title # 1"等のそれぞれのタイトルの再生を制御するプログラムの参照番号（ProgramlDRef)だけが記述されている。

[0298] ProgramlDRefは、本発明の情報記録媒体におけるプログラム識別情報の一例であり、これら ProgramlDRefにより、各プログラムが特定される。また、特定されたプログラムは、プレイリストを呼び出すことによりタイトルの再生を制御する。

[0299] なお、 "FirstPlayback"とは、ディスク挿入時に最初に再生すべきタイトル等を意味しており、情報として、そのタイトルの再生のためのプログラムの参照番号が格納される。

[0300] また、 "TopMenu"とは、リモコンでメニューボタンが押された場合などに選択されるタイトルであるディスクメニューを意味しており、情報として、ディスクメニューの再生のためのプログラムの参照番号が格納される。

[0301] また、図 32に示す BD. INFO内の" Index"に格納されている、 "FirstPlayback"

、 "TopMenu",および" Title # 1"等のそれぞれの名前は、本発明の情報記録媒体におけるタイトル識別情報の一例である。

[0302] また、ユーザが撮影した映像コンテンツ等の、ディスクメニュー以外のタイトルのタイトル識別情報は、 "Title" + " #タイトル番号"という形式である。タイトル番号については後述する。

[0303] 具体的には、ディスクロード時に、 "FirstPlayback"に格納されている ProgramlD Refに示される番号で指定されるプログラムが自動で実行される。また、ユーザがリモコンのメニューキーを押せば" TopMenu"に登録されている ProgramlDRefの番号で指定されるプログラムが実行される。

[0304] プレーヤの通常の動作としては、 "FirstPlayback "力参照されるプログラムに応じてディスクローデイング時のオープニング映像を再生した後、もしくは一切何も表示せずに" TopMenu"にジャンプし、 "TopMenu"にて規定されるディスクメニューを表示すること〖こなる。

[0305] また、 "Title # l"〜"Title # n"のそれぞれにはユーザが撮影および記録した映像コンテンツの再生を制御するプログラムを指定する ProgramlDRefだけが登録される。

[0306] 図 33は、実施の形態 2における BD. PROGの内容を示す図である。 BD. INFOにて参照される ProgramlDRefの番号は BD. PROGでの Programの並び順である。

[0307] 図に示すように、例えば、 Program # 1は何らかの処理を行った後、 GPRM0の値力 SOであるかの条件判定を行い、その値に応じて、 GPRM0 = 0であれば、 111. PL を、 GPRM0が GPRM3と同じであれば、 GPRM0に 2をカ卩えた値の番号を持つ PL の再生を行、、後続の処理を行うように記述されて、る。

[0308] このように BD. PROGに含まれるプログラムには、条件分岐（if)、プレーヤ変数の一種である GPRM (ゼネラルパラメータ）を使った演算処理、および、プレイリストの再生命令（PlayPlayList)などのコマンドを自由に組み合わせることができる。

[0309] 図 34は、メニュー表示およびタイトル再生に係る表示および動作の遷移の一例を示す図である。

[0310] 具体的には、プレーヤにおいて、前述の BD. INFOおよび BD. PROGによりメ- ユーが再生され、その後、ユーザの指示により、ユーザが記録した映像コンテンツであるタイトルを再生し、またメニューに戻る一連の処理をデータ構造の面力説明する図である。

[0311] 図 34において、表示および動作の遷移は、 TopMenuとして左下のディスクメ-ュ一が TVに表示されて、る所力始まる。

[0312] この TopMenuにお!/、て、ユーザがリモコンを使って一番右のボタン（Button3)を選択し決定したことにより、 TopMenuに関連するプレイリストである 100. PLに指定されたストリーム（100. VOB)に多重化されているボタンプログラム（Button Progr am3)が実行される。

[0313] ボタンプログラム（Button Program3)は、 Title3の再生を意図するコマンド (Jum pTitle (3) )が書かれており、そのコマンドが実行されることによって Title3の再生に遷移する。 [0314] 具体的には、 BD. INFOに記述された" Title3"に示される ProgramlDRefのフィ一ルドの値力 ¾であるために、 BD. PROGの k番目のプログラム（Program # k)が実行される。

[0315] プログラム（Program # k)には、プレイリスト（200. PL)の再生命令があるために 2 00. PLの再生を行い、再生が終了した後で後続のコマンド処理が続けられる。

[0316] プログラム（Program # k)の最後では、 TopMenuに戻るコマンド (JumpTopMen u () )が実行されるため元の TopMenuが再び表示される。

[0317] 以上がデータ構造から見た TopMenuと Title再生の仕組みである。

[0318] 上記の表示および動作の遷移は、プレーヤが、ディスクメニューに関連するプレイリスト等の記述に沿って処理を行うことで実現され、ディスクメニューを生成したのがどのメーカーであるかによって問題が生じることはない。

[0319] しかし、 1つのディスク力互いに異なるメーカーのビデオカメラ間を移動する場合を想定すると、ディスクメニューについて、ビデオカメラ側、つまり、ディスクメニューを生成しディスクに記録する記録装置側における互換性がないことが問題となる。

[0320] すなわち、あるディスクに Recorder— Aだけが記録および編集を行う限りにお、ては問題ない。しかし、 Recorder— Aが記録を行ったディスクを、他メーカーの製品である Recorder— Bにセットし、 Recorder— B上で記録 Z編集を行う場合、 Recorder —Aが生成したディスクメニューの設計ポリシーを Recorder— Bは特定することができない。

[0321] そのため、ディスクメニューの既存部分を残しつつ、編集内容に応じた追加等をすることができな、と!/、う問題がある。

[0322] これは、図 33に示すように、 BD. PROGの Programが再生状態に応じて変化するプレーヤ変数を使った条件分岐を行えるためである。

[0323] つまり、上記問題は、所定の Programだけを見てもどのように動作するのかは、他の要素との関連があり特定することが実装上不可能であるだけなぐ Recorder— A で生成されたディスクメニューに使って、る素材 (背景やボタン映像の選択)のポリシ一も Recorder— Bには特定できな、ことに起因する。

[0324] 例えば、 Titlelを最初から最後まで再生したか否かをプレーヤ変数の GPRM100 の値で管理しており、 Title2の再生が Titlelを再生済みであれば途中から、そうでなければ Title2の先頭からの再生を行うようにプログラムされてヽる場合を想定する。

[0325] このような場合に、 GPRM100が Titlelの再生経歴を示す情報であり、それが Titl e2の再生を制御するように設計されており、これ以外の他の要素が影響しないことを検証するためには、全ての再生可能なパターンでの再生をシミュレートすることが必要になる。

[0326] そのため、全ての BD. PROGのプログラム（Program)、およびストリームに多重化された全てのボタンプログラム（Button Program)を取得し解析し、プレーヤ変数の設定の意味を特定して、かなければならず、データの読み込みおよび解析に膨大な時間がかかると思われる。

[0327] 従って、ディスクメニューを Recorder— Aから Recorder— Bに引き継ぐことは実質的に不可能である。

[0328] そこで、 Recorder— Aが生成しディスクに記録したディスクメニューは、 Recorder —Bがそのディスクに対して記録および編集などを行う場合、ディスクメニューに関連する各種ファイルを全て削除し、一力ゝら作り直すことが、ディスク全体のデータの整合性を取る最も確実で簡易な方法である。

[0329] また、既存のディスクメニューに関連する各種ファイルを削除せずに、新たなデイスクメニューを生成することも考えられるが、この場合、不要なファイルがディスクに蓄積していくことになる。これにより、ディスクの記録可能容量が無駄に消費されるだけでなぐディスクをロードする機器において、ファイル管理に係る処理負担が増加することになる。

[0330] 図 35は、異なるメーカーのレコーダ間でディスクの移動があった場合のディスクメ- ユーの更新におけるルールを示す図である。

[0331] 図 35 (A)は、ディスクメニューの更新において BD. INFO等の各ファイルをどのように扱うかを示す図であり、図 35 (B)は、図 35 (A)に示される番号の意味を説明する図である。

[0332] 例えば、 Recorder— Aによりコンテンツが記録されたディスクに対し Recorder— B 力 Sさらに記録および編集する場合、その編集によって追加または削除されたコンテンッをディスクメニューに反映しなければならない。

[0333] このように、 Recorder— Bが、 Recorder— Aによりディスクメニューが記録されたデイスクに対してコンテンツの記録および編集を行ヽ、ディスクメニューを更新しなければならない場合、 FirstPlaybackおよび TopMenuに関連する箇所の全て（BD. IN FOの該当部分、 BD. PROGの該当部分、 XXX. PLの全て、 YYY. VOBIの全て、 YYY. VOBの全て）を変更する。なお、「変更する」とは、当該データを削除して新たなものを生成することも含む。以下の記載にぉ、ても同様である。

[0334] さらに、新しい FirstPlaybackおよび TopMenuと整合性がとれた Titleと、その Tit le用の Programを規定しなおすために、 Titleに関しても関連する箇所の全て（BD. INFOの該当部分、 BD. PROGの該当部分）を変更する。

[0335] 逆に言えば、ディスクメニューの更新時にそのまま残るのは、ユーザが撮影した映像を格納している各 Titleのプレイリスト以下だけとなる。

[0336] また、上記の変更だけでメニュー更新が実現可能なように、 Titleで使用するストリーム（YYY. VOB)にはメニュー動作に影響する Button Programを含ませないことも重要である。

[0337] このようなルールに従えば、異なるメーカーのレコーダ間でディスクを移動させた場合においても、ディスク全体のデータ整合性を維持しつつ、ディスクメニューを更新することがでさる。

[0338] しかしながら、このルールによれば、 FirstPlaybackおよび TopMenuが使用するプレイリストを特定する必要がある力これは前述のように実質的に不可能である。そのため、ディスクメニューの更新時に、どの XXX. PLを削除すれば良いのかは分からな、と!/、う問題が依然として残存する。

[0339] そこで、図 36に示すように BD. INFOの" Extension"に、以下のような情報を格納しておくことが有効である。

[0340] 図 36は、 BD. INFOの" Extension"にプレイリストを特定するための情報を格納した状態を示す図である。

[0341] "Extension"は、 BD. INFOの末尾に設けられた拡張領域であり、このように、規格に規定されていない情報を格納することができる領域である。また、 "Extension" 力もは、プレーヤは情報を読み出す義務がないため、規格に規定されていない情報を格納した場合であってもプレーヤに何らかの悪影響を与えることはない。

[0342] なお、 "Extension"に格納されている情報は、本発明の情報記録媒体における拡張情報の一例である。

[0343] 以下に、 "Extension"に格納されている情報について説明を行う。

[0344] (1) "Makerlnfo"は、本発明の情報記録媒体における生産者識別情報の一例であり、メーカーを識別する識別子である" MakerlD"と、この BD. INFOを記録した機器を特定する識別子" ModellD"とを含む情報である。

[0345] (2) "Disclnfo"は、このディスク上に記録可能な、もしくは既に記録されている映像のフレームレートを特定する情報であり、以下の各情報を含んでいる。

[0346] "IsNTSC"は、 29. 97/59. 94Hzのフレームレートの映像符号化を行って良い力もしくはそれらのフレームレートの映像が既に記録されているかを示す情報である。

[0347] "IsPAL"は、 25Z50Hzのフレームレートの映像符号化を行って良いか、もしくはそれらのフレームレートの映像が既に記録されているかを示す情報である。

[0348] "IsFILM"は 23. 97Z24Hzのフレームレートの映像符号化を行って良いか、もしくはそれらのフレームレートの映像が既に記録されて、るかを示す。

[0349] なお、 "IsNTSC"と" IsPAL"が 1つのディスクに混在するのは一部のコンテンツが再生できな!/、事態を招きうるため禁止される。

[0350] 因みに" IsFILM"は" IsNTSC"および" IsPAL"のどちらとも共存が可能である。例えばレコーダは 29. 97/59. 94Hzのフレームレートの映像符号化を行って記録する場合には事前に" IsNTSC = 1 "となっているかを確認して記録する。

[0351] もじ' IsNTSC = 0"の場合には、 "IsPAL = 0"であるかを確認じ' IsNTSC = 1"と書き換えて記録する。もしくは" IsNTSC = 0"かつ" IsPAL= 1"であってもディスク上に 25Z50Hzのフレームレートの映像がないことを確認した上で、 "IsNTSC= l"および" IsPAL = 0"と書き換えて記録することができる。このようにすることで、ディスク上での NTSC/PAL混在をストリームのフレームレートを全て調べることなく簡易に防ぐことが可能である。 [0352] (3) "FirstPlayback，，は、 BD. INFO内の" Index"に含まれる" FirstPlayback" により指定されるプログラムから呼び出されるプレイリストの総数を示す" PlayListNu mber"と、そのプレイリストの番号を示す" PlayListID"とを含む情報である。

[0353] なお、 PlayListIDは、本発明の情報記録媒体におけるプレイリスト識別情報の一例である。

[0354] (4) "TopMenu，，は、 BD. INFO内の" Index"に含まれる" TopMenu"により指定されるプログラムから呼び出される可能性のあるプレイリストの総数を示す" PlayList Number"と、そのプレイリストの番号を示す" PlayListID"とを含む情報である。

[0355] (5) "TitlePLPairNumber"は、下記に示す" TitlePLPair"の総数を示す情報である。

[0356] (6) "TitlePLPair"は、プレイリストの番号を示す" PlayListID"と、そのプレイリストにより特定されるタイトルのタイトル番号 (Title # nと XXX. PLは 1対 1で使用することを想定)を示す" TitlelD"とを含む情報である。

[0357] タイトル番号とは、上述のように、タイトル識別情報である" Title # n"の" n"の部分の数字である。つまり、タイトル番号はタイトル識別情報に対応する数字である。

[0358] このように、 BD. INFOの拡張領域である" Extension"に記述された" Makerlnfo "に示される情報によって、ビデオカメラ等のレコーダはこのディスクに記録されたメ- ユーを生成したレコーダのメーカーを特定する情報と機器を特定する情報を得ることができる。

[0359] ディスクがセットされたレコーダにおいて、仮に、自機がディスクメニューを記録したディスクであることが判明した場合、ディスクメニュー（FirstPlaybackZTopMenu) を一力作り直すことなぐ特定の差分情報の更新だけを行えばよぐメニューの更新時間を短縮することが可能である。

[0360] また、ディスクがセットされたレコーダは、 "Makerlnfo"に示される情報を参照することにより、他メーカーのレコーダでディスクメニューが記録されたディスクである力否かの判定が可能であり、他メーカーのレコーダでディスクメニューが記録されたデイスクであると判定した場合は、ディスクメニューを一からつくり直すことにより更新する。

[0361] さらに、 BD. INFOの拡張領域である" Extension"に記述された" FirstPlayback "に示される情報および" TopMenu"に示される情報によって、ディスクメニューで使用されているプレイリスト (XXX. PL)を容易に特定できる。そのため、そのプレイリストを解析することにより使用する YYY. VOBI、 YYY. VOBを特定することができる。

[0362] すなわち、ディスクメニューに関連する XXX. PL、 YYY. VOBI、 YYY. VOBファィルの全てを容易に特定でき、これらを削除することが可能となる。

[0363] つまり、削除の対象となるタイトルに関連するプレイリスト、当該タイトルの管理情報、および、当該プレイリストに指定されるデジタルストリームの部分区間を削除することができる。

[0364] このように、ディスクメニューに関連するプレイリストを容易に特定できる情報をディスクに記憶させておくことで、ディスクメニューに関連する各種ファイルを容易に特定でき、これらを削除した上でディスクメニューを新たに生成することができる。

[0365] これにより、互いに異なるメーカーの機器間でディスクが移動した場合であっても、ディスクメニューに関連する各種ファイルを削除した上で、新たなディスクメニューを生成することができる。

[0366] つまり、前述のような情報が記録された情報記録媒体は、 V、ずれのメーカーの記録装置においても、不要な処理負荷や処理時間が発生させることなぐディスク全体のデータの整合性を保ちながら、容易にディスクメニューを更新させることができる。

[0367] 次に、ディスクメニューの更新時のタイトル番号の保持について説明する。

[0368] 多くの公開文献や実施の形態 1でも示されているように、 DVD—Videoや BD—R OMのような情報記録媒体を再生するプレーヤではタイトルとチャプターという 2つの階層を用いてユーザにコンテンツを提供して、る。

[0369] 一般的なプレーヤではタイトルサーチと、う機能が実装されて、る。ユーザは、この機能により、 GUI (Graphical User Interface)のディスクメニューを経由せずに、直接リモコンの数字キーなどを使ってタイトル番号を指定し、そのタイトルカゝら再生を開始することが可能である。

[0370] なお、タイトル番号とは、 BD. INFOの Index部分にて表現された Titleのループ順を意味しているため、タイトル 1とは、ループ順で先頭の Titleを意味する。

[0371] ここで、将来的には、ディスクのラベルにタイトル番号とそのコンテンツの内容を表すような情報 (記録日時や放送局のチャンネル、サムネイル映像など）を印刷することもあると居、われる。

[0372] CD -DA (Compact Disc Digital Audio)のようなオーディオコンテンツを収録したディスクのラベルに、曲番号と曲名の組み合わせを印刷しているように、本発明の記録装置を利用するユーザにとってタイトルとそのコンテンツとの関連はタイトルサーチの機能が利用できる以上、とても重要である。

[0373] ここで、あるコンテンツと、そのコンテンツに付されたタイトル番号との関係、つまり、あるコンテンツに関連するプレイリストと、そのプレイリストに関連付けられたタイトル番号との関係は、パッケージメディア (Read Only Media)では変更されることがないため、考える必要がない。

[0374] しかし、情報の記録および編集が可能な情報記録媒体にお!、ては、あるメーカーのレコーダで生成されたディスクメニュー力 S、他のメーカーのレコーダで更新される際に、上記のコンテンツとタイトル番号との関係は維持されない。

[0375] そのため、例えば、ユーザが、上記の Recorder— Aで映像コンテンツを記録したデイスクにおいて、タイトル番号が" 1"であると認識していたコンテンツ力その後に Rec order— Bによりディスクメニューが更新されたために、不意にタイトル番号が" 3"に変更される場合がある。

[0376] もちろん、ディスクメニューの更新の前に、どのコンテンツ、つまりタイトル力どのプレイリストと関連しているの力、つまり、どのプレイリストを参照しているのかを容易に知ることができるのであれば、その時点でコンテンツに付されて、るタイトル番号を取得し、更新の際に維持しておくことは可能である。

[0377] しかし、どのタイトルがどのプレイリストと関連しているかを取得するためには、図 32 に示す Title # 1 · · -Title # nに示される、 BD. PROGに記録されて!、る各 Program を解析する必要があり、前述のように非常に困難である。

[0378] 従って、本実施の开態では、図 36に示すように BD. INFOの" Extension"に、タィトル番号 (TitlelD)とそのプレイリスト番号（PlayListlD)とを含む情報として" Title

PLPair"を記述する。

[0379] また、タイトル番号とそのプレイリスト番号とは順次追加記録される。つまり、 TitlePL Pairの中の記述順はそのプレイリスト（PlayListIDで特定されるプレイリスト）の記録日時順である。

[0380] これによつて、以前のタイトル番号とそのコンテンツ（つまり、プレイリスト）との対応を崩さないようにメニューを更新することが可能となり、ユーザにとっては不意にタイトル番号とコンテンツの相関が変更されることを防ぐことができる。

[0381] なお、あるディスクにおいて記録されていたタイトルが削除された場合には、タイトル番号が BD. INFOの Index内のループ順であることから、削除したタイトルにダミーのプレイリストを付与してもよ！/、。

[0382] 更に、そのコンテンツとして" Deleted Title"などと既にそのタイトルに関連していたコンテンツが削除されたことをユーザに認識させるような映像等のコンテンツを、削除されたタイトルに関連するプレイリストに関連付ける。こうすることにより、他のタイトル番号に影響させなヽことができる。

[0383] また、上記の削除されたことを示すコンテンツはタイトルサーチの操作においてのみ再生可能であって、ディスクメニューでは選択されなヽように実装される。

[0384] 図 37は、実施の形態 2における、ディスクメニューの更新前後のタイトルとプレイリスト（コンテンツ）との相関の例を示す図である。

[0385] あるディスクにおいて、ある時点で図 37 (A)に示すように、ディスク上に 3つのタイトルがあり、それぞれのタイトルが 101. PL、 102. PL、 103. PLのプレイリストと関連付けられていると想定する。また、各プレイリストが上記の順番で、コンテンツ A、 B、 C に関連するものである場合を想定する。

[0386] この想定下において、レコーダで Title 2を全削除し、新規にコンテンツ Dを記録した場合、図 37 (B)に示すようにタイトルとプレイリスト (コンテンツ）の関係が一部変更される。

[0387] 具体的には、削除された Title2は BD. INFOの Indexから削除されることなくそのまま残され、 Title2のプレイリスト 102. PLが参照する AVストリーム（YYY. VOB)が、Title2がユーザの編集操作によって削除されたことを示す映像や音声情報に置き換わる。

[0388] また、 Titlelおよび Title3については、タイトル番号とプレイリスト（コンテンツ）との関係は維持される。つまり、それらタイトルに付与されたタイトル番号に変更はない。

[0389] また、新たに記録されたコンテンツ Dは図 36に示す TitlePLPairの中で最後に追加される。

[0390] つまり、 TitlePLPairの中の記述順はそのプレイリスト（PlayListIDで特定されるプレイリスト）の記録日時順を示すことになるため、記録日時順でメニュー表示を行う場合に有用である。

[0391] 次に、図 32、図 33、および図 36に示すデータ構造を有するディスクに対し、前述のようなメニューの更新や各種情報の操作を行うレコーダの構成および動作について以下に述べる。

[0392] 図 38は、実施の形態 2のレコーダの機能的な構成を示す機能ブロック図である。

[0393] 図 38に示すレコーダ 400は、本発明の記録装置の一例であり、例えば、映像をデジタルストリームとして記録するビデオカメラとして実現される。

[0394] なお、レコーダ 400は、デジタルストリームを記録する記録装置が本来有する、ェンコーダ等の他の構成部を備えているが、本発明の特徴を明確にするために、それら他の構成部についての図示および説明は省略する。

[0395] レコーダ 400は、図 38に示すようにプレイリスト特定部 401、削除部 402、メニュー生成部 403、メーカー判定部 404、受付部 405、編集部 406、番号読出部 407、撮影部 408、および表示部 409を備える。

[0396] また、情報記録媒体として、図 32、図 33、および図 36に示すデータ構造を有するディスク 105を使用する。

[0397] プレイリスト特定部 401は、ディスクメニュー等のタイトルの再生を制御するプロダラムから呼び出されるプレイリスト、つまり、処理の対象とするタイトルに関連するプレイリストを図 36に示す PlayListIDを用いて特定する処理部である。

[0398] メニュー生成部 403は、ディスク 105に記録されているメニューに換えて、新たなメニューを生成しディスク 105記録する処理部である。

[0399] 削除部 402は、メニュー生成部 403により新たなメニューが生成される場合、デイスク 105に記録されて、るメニューに関連するプレイリストを削除する処理部である。なお、削除するプレイリストは、プレイリスト特定部 401により特定される。 [0400] メーカー判定部 404は、図 36に示す Extensionに含まれる Makerlnfoに示されるメーカーが、レコーダ 400を生産したメーカーと一致するか否かを判定する処理部である。

[0401] 受付部 405は、ユーザまたはレコーダ 400に接続された機器力も入力される、レコーダに対する指示等を受け付ける処理部である。

[0402] 編集部 406は、ディスク 105に記録されているタイトルの編集を行う処理部である。

[0403] 番号読出部 407は、 "Extension"に含まれるタイトル番号、つまり、 TitlelDをディスク 105から読み出す処理部である。

[0404] 撮影部 408は、映像をデジタルストリームとしてディスク 105に記録する処理部である。

[0405] 表示部 409は、レコーダ 400が備える小型の液晶デバイス等である。表示部 409には、図 31の上段に示す簡易な機器メニューが表示される。

[0406] このように構成されたレコーダ 400の基本的な動作の概要は以下のようになる。なお、レコーダ 400を生産したメーカーとは異なるメーカーのレコーダにより生成されたディスクメニューがディスク 105に既に記録されていると場合を想定する。

[0407] このディスク 105がレコーダ 400にセットされると、プレイリスト特定部 401は、デイスクに記録されているディスクメニューに関連するプレイリストを、 "Extension"に含まれる、 "TopMenu"に対応付けられた PlayListIDを用いて特定する。

[0408] メニュー生成部 403は、新たなディスクメニューを生成しディスク 105に記録する。また、削除部 402は、プレイリスト特定部 401により特定されたプレイリストをはじめ、他メーカーのレコーダにより生成されたディスクメニューに関連する各種ファイルを削除する。

[0409] このようにして、レコーダ 400は、他メーカーのレコーダにより生成されたディスクメ- ユーを削除し、新たなディスクメニューをディスクに記録することができる。

[0410] 次に、レコーダ 400がディスク 105上のタイトル構成を更新する際の動作の流れを説明する。

[0411] 図 39は、実施の形態 2のレコーダ 400における記録/編集時のタイトル構成の更新時の動作の流れの概要を示すフロー図である。 [0412] ユーザの指示等により、新たなタイトルの記録または既存のタイトルに対する編集が開始される（S801)と、編集部 406は、 BD. INFOおよび BD. PROGをディスク 105 力も読み込む（S802)。さらに、番号読出部 407は、ディスク 105に記録されているタィトル番号の最後の番号を取得する。

[0413] 具体的には、 BD. INFOの" Index"に含まれる" Title # 1"から並んで存在するタィトル識別情報カゝら最後のタイトル番号 (Tn)を取得する（S803)。

[0414] 例えば、 "Index"に" Title # 1"、 "Title # 2"、 "Title # 3"と存在する場合、 "3"が取得される。

[0415] その後、編集部 406力 XXX. PL、 YYY. VOBI、および YYY. VOBを必要に応じて更新し (S804)、新規にタイトルを記録した場合、上記 Tn以降の番号に、新規に記録したタイトルを割り振り、読み出した BD. INFOにその番号とタイトルとを記録する（S805)。

[0416] 例えば、 Tn= "3"である場合、新たなタイトルが記録されると、そのタイトルにはタイトル番号" 4"が付与される。

[0417] この場合、編集部 406により、 BD. INFOの" Index"に" Title # 4"が追加され、更に、 "Extension"に TitlelDである" 4"と、 Title4に関連するプレイリストの PlayListl

Dとが対応付けられて追加される。

[0418] また、上記 Tn以前のタイトル番号のタイトルで削除されたものがある場合、編集部 4

06は、その削除されたタイトルのタイトル番号を削除するのではなぐそのタイトル番号に関連するプレイリストに示されるデジタルストリームの部分区間をタイトルが削除されたことを示す内容のダミーのデジタルストリームに置き換える。つまり、削除されたタイトルにダミーのデジタルストリームを付与する（S806)。

[0419] ダミーのデジタルストリームとは、前述のように、 " Deleted Title"等の映像のデータ等である。

[0420] この削除の際には、具体的には、プレイリスト特定部 401が、削除されたタイトルのタイトル番号、つまり TitlelDと対応付けられている PlayListIDから、削除されたタイトルに関連するプレイリストを特定する。

[0421] このような動作により、例えば、タイトル番号" 2"のタイトルが削除された場合、タイトル番号" 2"を削除するのではなぐタイトル番号" 2"に、 "Deleted Title"と名付けられた映像等のデータが対応付けられる。

[0422] このように、更新された BD. INFOおよび BD. PROG等をディスク 105に書き込む

(S807)。以上により、一連の記録 Z編集に係る動作を終了する。

[0423] 上記のように、タイトル番号とそのコンテンツ（関連するプレイリスト番号)の関係を崩すことなく BD. INFOを更新することで、ディスクメニューではなぐタイトルサーチで直接コンテンツの再生を行うような場合であっても、ディスクメニューの更新の度にタィトル番号とコンテンツとの関係が変わることを防ぐことができ、ユーザの利便性を高めることができる。

[0424] またこの際に、ディスクメニューでは削除したタイトルは選択できなヽ（一切表示されな、）ように作りこむことで、 GUIを使ったディスクメニュー力コンテンツ再生を制御するユーザに対しても Title2をダミーで残す悪影響を与えることがなヽようにすることができる。

[0425] なお、本実施の形態において、図 32等に示すデータ構造を有する情報記録媒体としてディスクを用いた力情報を記録できる媒体であれば、 BDおよび DVD等のデイスクでなくてもよい。例えば、フラッシュメモリ等の半導体メモリでもよい。

[0426] なお、 "FirstPlayback"、 "TopMenu"に関連するコンテンツ（VOBファイル）力 " Title"力もも参照されている場合、ディスクメニューを削除すると、 "FirstPlayback" ど' TopMenu"として登録されたプレイリストとそのプレイリストから参照されるコンテンッ (VOBファイル）とが削除され、タイトルの再生に支障をきたすこととなる。従って、これは禁止されるべきである。

[0427] 本実施の形態で言えば、 BD. INFOの" Extension"に記述される" FirstPlaybac k"、 "TopMenu"のプレイリストが参照するコンテンツ（XXX. VOB)が、同じく BD. I NFOの" Extension"に記述される" Title"のプレイリストが参照することは禁止される。

[0428] ディスクメニュー（FirstPlaybackZTopMenu)とそのディスクに記録されたタイトルが同じ VOBを参照しないこと力迅速なディスクメニューの更新、つまりディスクメニューに関わるファイルの特定と削除のために必要である。 [0429] なお、 BD. INFO内の" Extension"として説明した情報が無い場合であっても、 " FirstPlayback", "TopMenu"が参照するプレイリストのファイル番号と、 "Title"が参照するプレイリストのファイル番号とを別個の範囲とすることでディスクメニューの更新のために、更新が必要なプレイリストファイルを迅速に特定することが可能である。

[0430] また、プレイリストを削除する際、図 36に示す" TitlePLPair"に含まれる" PlayList ID"から、当該プレイリストが他のタイトルにも関連していないか事前に検索し、関連して!、なければ削除すると、う対策を取ってもょ、。

[0431] (実施の形態 3)

次に本発明の実施の形態 3について説明する。

[0432] 基本的には実施の形態 1に基づく内容であり、拡張または異なる部分を中心に説明する。

[0433] 本発明の実施の形態 1において、図 18を用いて BD管理情報の 1つで、ディスク全体の情報を管理する" BD. INFO"の例を説明した力本実施の形態では図 40の形式を取るものとする。

[0434] BD. INFOはディスクに 1つだけ存在し、当該ディスクが挿入された際に一番初めに解釈される。図 40における BD. INFOは、 Applnfoと TitleList、 ExtensionDat aからなり、 Applnfoにはディスク全体に関する情報が格納される。

[0435] なお、図 40に示す" TitleList"および" ExtensionData"のそれぞれは、図 36に示す、実施の形態 2における" Index"および" Extension"に相当する情報領域である。

[0436] TitleListには当該ディスクに格納される Titleの情報が格納されており、 FirstPlay backと TopMenuと!、う二つの特別な Titleと複数の通常の Titleからなる。通常の Ti tieの総数は TitleList以下の Numberに格納される。 FirstPlaybackと TopMenuと各 Titleは各々タイトル選択時に実行すべき後述する Objectへのリンク情報 (Object の ID)を持っている。 FirstPlaybackは、ディスク挿入時に一番最初に選択されるタィトルであり、 TopMenuは、リモコンでメニューボタンが押された場合などに選択される再生メニュー用のタイトルである。

[0437] 次に Objectに関する情報を格納する" BD. PROG"について図 41を用いて説明する。 Objectとは複数のナビゲーシヨンコマンドからなるプログラム群であり、 Object を実行する際はナビゲーシヨンコマンドを 1つずつ逐次実行される。

[0438] 図 41に示すように" BD. PROG"は格納する Objectの総数を示す Numberおよび各 Objectのエントリ力もなる。図中にある各 Objectの添え字（ # 1など）は Objectの I Dであり、各 Objectは ID順に並ぶものとする。

[0439] 前述のようにタイトルからはこの ObjectIDを元にタイトル選択時に実行される Obje ctが参照されている。各 Objectは Objectlnfo領域と Program領域とからなる。 Obj ectlnfo領域には Objectの設定情報が格納される。 Program領域には当該 Object 実行時に逐次実行するナビゲーシヨンコマンド群が格納される。

[0440] なお、図 41に示す" BD. PROG"は実施の形態 1において図 18を用いて説明した "BD. PROG"に変わるものであり、合わせて図 17を用いて説明した" XXX. PROG "は廃止される。

[0441] また、実施の形態 1において説明したイベントに関しては、他の機能により代替される。例えば図 20を用ヽて説明したタイムイベント及び図 21を用ヽて説明したユーザィベントは、詳しくは後述するがストリーム中に埋め込まれるナビゲーシヨンコマンドに相当するボタンにより代替される。

[0442] また、図 22を用いて説明したグローノレイベントは、リモコンキー操作毎にプレーヤの実行動作が規定されることとなる。

[0443] 例えば図 22で説明したようにリモコンの Menuキーが押された場合、前述した BD.

INFOで規定されるタイトルの 1つである TopMenuが自動選択されるよう規定されており、結果、 TopMenuからリンクが張られた Objectが選択され、 BD. PROG中の当該 Objectの Program領域に格納されたコマンド群が実行されることになる。

[0444] 次に、本実施の形態におけるナビゲーシヨン機能の 1つであるボタンおよびページについて説明する。

[0445] 本発明の実施の形態 1にて、図 20〜図 21を用いてイベントを契機としたボタン描画の例を説明したが、 BD— ROM規格に於いては、前述した DVDの NV— PCKと同じぐナビゲーシヨンコマンドをページ及びにボタン（NV—DS)として、 MPEG—TS 形式のストリーム中にビデオエレメンタリストリーム（V PES)やオーディオエレメンタリストリーム (A_PES)と一緒に埋め込むことができる。

[0446] BD— ROMにおいて、インタラクティブを実現するナビゲーシヨン機能をストリーム化し、映像、音声、字幕などの AVデータと共にストリームに多重化する構成について説明する。

[0447] なお、本発明の実施の形態 1では、 BD— ROM Discに記録する AVストリームを

MPEG— PSに準じた形で説明していた力本実施の形態では AVストリームを MPE

G— TS形式で実現する。

[0448] 本実施の形態における AVストリームを、図 42を用いて説明する。

[0449] 図 42に示すように、映像、音声、字幕そしてインタラクティブを実現するナビゲーシヨンなどのエレメンタリストリーム（図 42の（1) )は、それぞれ PESストリーム化され（図 4

2の（2) )、さらにそれぞれが一本の MPEG— TSに多重化される（図 42の（3) )。

[0450] なお、 MPEG— TSにおける多重化も、多重化する個々のデータはそのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕、ナビゲーシヨンの間は必ずしも再生順、言、換えればデコード順に基づ、てビット列が形成されて、るわけではな、。

[0451] MPEG— TSのデコーダモデル（図 42の（4) )も多重化を解いた後に個々のエレメンタリストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している。

[0452] 次に BD— ROMにおけるページとボタンの具体的な内容を説明する。

[0453] BD— ROMにおけるナビゲーシヨン機能ではページとボタンの二つの概念を提供している。

[0454] ページはボタンをグループ化して管理する単位であり、ボタンはユーザの操作に応じて実動作を行う単位である。

[0455] 具体的にディスプレイセット（NV— DS)としてページがどの様な情報を持ち MPEG

— TSに多重化されて、るのかを図 43を用いて説明する。

[0456] 図 43に示すように、ページは、自身の「ページ ID」と、ページ遷移時のアニメーション効果が設定された「アニメーション情報」と、ページ内の描画パレットが設定された「パレット情報」と、ページが onになった際に選択状態にするボタンのボタン IDが設定された「デフォルト選択ボタン ID」と、ページが onになった際に実行するボタンのボタン IDが設定された「デフォルト実行ボタン ID」と、当該ページに所属するボタン群の情報が設定された「所属ボタン情報」とが NV— DSに設定され、図 42を用、て前述したように MPEG—TSに多重化される。

[0457] 次に、ディスプレイセットとしてボタンがどの様な情報を持ち MPEG—TSに多重化されて、るのかを図 44を用いて説明する。

[0458] 図 44に示すように、ボタンは、自身の「ボタン」と、自身の大きさやボタン画像として描画する内容等を示す「領域情報」と、ボタンが選択された際に自身に設定されたナビゲーシヨンコマンドを自動実行するか否かを示す「自動実行可否フラグ」と、自身が選択された状態でリモコンによるユーザ操作 (上下左右）が発生した際にどのボタンに遷移するかが設定された「ボタン遷移情報」と、ボタンが選択されたり押下されたりするなどボタンの状態が変化した際に鳴らす効果音や実行するアニメーション効果などが設定された「状態情報」と、ボタンが押下されるなどボタンが有効になった際に実行するナビゲーシヨンコマンド群が設定された「実行コマンド」とが NV—DSに設定され、図 42を用いて前述したように MPEG— TSに多重化される。

[0459] 以上、 BD— ROMにおけるナビゲーシヨン機能の 1つであるページとボタンについて説明した力前述したタイムイベント及びユーザイベントはこのページとボタンにより実現される。

[0460] 例えばタイムイベントは、ボタンをストリームの所望の位置に再生されるように埋め込み、前記「自動実行可否フラグ」を設定しておくことで、ストリーム再生中に所定の時刻に前記ボタンに設定された「実行コマンド」が実行されることになる。

[0461] また、ユーザイベントに関しても所望の動作を行うように「ボタン遷移情報」及び「実行コマンド」を設定したボタンをストリームに多重化しておくことで実現可能である。

[0462] また、ページおよびボタンを活用することで、撮影した映像を再生する再生メニューなどインタラクティブなユーザインターフェースを実現出来る。

[0463] 例えば図 45に示すように階層化されたメニューを実現する場合、トップメニューと二つのサブメニュー毎に各メニューに表示したいボタンを取りまとめるページを用意する。トップメニューではボタン 1、 2を取りまとめるページ 1、サブメニュー 1ではボタン 3 を表示するページ 2、サブメニュー 2ではボタン 4, 5を取りまとめるページ 3を設け、前述したようにストリームに多重化する。

[0464] トップメニューからサブメニューへの遷移はボタン 1、 2のようにメニュー遷移用のボタンを用意し、ボタン押下に合わせて切り替えるよう設定する。例えばボタン 1はトップメニューからサブメニュー 1への遷移を行うために、ボタン押下時にページ 1を offにし、ページ 2を onにするナビゲーシヨンコマンドが前記実行コマンド領域に設定されている。

[0465] また、ボタン 2でも同様にトップメニューからサブメニュー 2への遷移を行うために、ボタン押下時にページ 1を offにし、ページ 2を onにするナビゲーシヨンコマンドが前記実行コマンド領域に設定されてヽる。

[0466] また、実行コマンド領域で指定可能なナビゲーシヨンコマンドはページ遷移以外にも様々なナビゲーシヨンコマンドを指定可能である。例えばボタン 3のようにプレイリスト再生中にチャプターを切り替えるナビゲーシヨンコマンドを設定したり、ボタン 5のように表示する字幕ストリームを切り替えるナビゲーシヨンコマンドを設定することもできる。

[0467] ここで、ボタンの実行コマンド領域にはプレイリストの再生を開始させるナビゲーションコマンドは指定できない規定となっており、前述の Objectにおける Program領域でのみ指定できる。

[0468] 従って、ボタン 4押下時にプレイリスト XXX. PLを再生させたい場合、まず当該ボタンからプレイリスト XXX. PLを再生させるナビゲーシヨンコマンドが記述された Object (図中の Object # N)へ遷移し、その Objectから所望のプレイリスト（図中では XXX . PL)を再生するナビゲーシヨンコマンドを実行してもらう必要がある。

[0469] 以上説明したように、ページ及びボタンで再生メニューを作成する場合、ページ及びボタン以外にも、ボタン力も遷移されボタンでは実行出来な、ナビゲーシヨンコマンドを実行してもらうための Obj ectが必要となる。図 40と図 41とを用!ヽて Titleと Obj ectとの関係を説明した力 Objectには前述のように Titleから参照される Objectだけではなぐボタン力参照される Objectが存在しうる。

[0470] 以上説明したように、ページとボタンとの組み合わせにより容易にインタラクティブなユーザインターフェースを実現可能である。

[0471] なお、再生メニューなどのインタラクティブなユーザインターフェースにおける GUI 描画に BD— ROMのスライドショウ機能を活用することもできる。

[0472] まず、図 46を用いて V— PESにおけるスライドショウ機能について説明する。まず当該 V— PESがスライドショウである力否かは、例えば当該 V— PESが含まれた AV データの VOB管理情報ファイル VOBIにおいて設定されるものとする。

[0473] 上記スライドショウである旨を設定された V— PESは、例えば全て Iフレーム (Iピクチャ）のみで構成されており、一枚のスライドショウとして表示される画面の静止画像がそれぞれ Iフレームとして V— PESに埋め込まれる。同時に、各 Iフレームの先頭毎にプレイリストにおいてチャプターイベントが設定される。

[0474] また、各 Iフレームの表示時間は無限大または固定時間が設定されており、設定された時間が経過するか、チャプタースキップまたはバックが実行されることで前の静止画に進んだり、前の静止画に戻ったりする。このように Iフレームとチャプターによりスライドショウ機能が実現される。

[0475] ここで、図 44を用いて前述したようにディスプレイセット（NV— DS)にお!/、てボタンの描画内容を記述可能であるが、描画情報を設定しないボタンも実現可能である。また、ボタンの実行コマンド領域を駆使して、チャプタースキップ、チャプターバックに相当するボタンも実現可能である。

[0476] 従って、ページとボタンとスライドショウ機能とを併用し、メニューの GUI描画を Iフレームイメージとしてスライドショウに設定し、ユーザ操作によるメニュー遷移やナビゲーシヨンコマンド実行などのメニュー制御をページ及びボタンに行わせることもできる。

[0477] 例えば図 47を用いて説明すると、まず図 47 (A)に示すようなメニューを構成する各メニュー画面イメージを Iフレームイメージとして V— PESに埋め込んでスライドショウを構成する。

[0478] 次に図 47 (B)に示すようなメニュー画面の遷移や押下時の動作をページとボタン、そしてボタン力遷移される Objectにより実現する。具体的にはサムネイル Fの選択時にリモコンの右ボタンが押された場合など、メニュー画面を切り換える場合に対応するためには、チャプター変更に相当するナビゲーシヨンコマンドをボタンに設定すればよい。

[0479] また、サムネイル A押下時にサムネイル Aに対応する動画を再生する場合には、ボタン押下時にサムネイル Aに対応する動画を再生するための Objectに遷移するようボタンを設定すればよい。

[0480] 以上説明したようにメニューはスライドショウとページ及びボタンを併用することでも実現可能であり、このようなメニューは図 42を用いて前述したように 1つの MPEG— T

Sに多重化される。

[0481] 再生メニューを BD— ROM形式で記録されたディスクに設定する方法について述ベる。前述のように BD. INFOにおける TopMenuはメニュー専用の Titleであるため前述のメニューを実現する MPEG— TSは TopMenuタイトルが選択された際に自動実行される必要がある。

[0482] 従って、 TopMenuから参照する Objectを作成して BD. PROGに登録し、当該 O bjectの Program領域には、前記メニューを実現する MPEG— TSを再生するプレイリストを再生させるナビゲーシヨンコマンドを設定すればよい。

[0483] また、ディスク挿入時に自動的に再生メニューが表示されるようにするには、 FirstP laybackから参照する Objectを作成して BD. PROGに登録し、当該 Objectの Prog ram領域には、 TopMenuにタイトル遷移するナビゲーシヨンコマンドを設定すればよい。

[0484] ここで、他機器で既に映像を記録されたディスクに対し、自機器で新規に映像を追記したとする。この場合 TopMenuカゝら実行される再生メニューに、当然追記した映像のサムネイル並びに当該映像を再生させるナビゲーシヨン情報を反映させる必要がある。

[0485] しかしながら、再生メニューの構成は各社各様であり、 TopMenu力も参照される O bjectの Program領域がどのようになって!/、るか容易には判別出来な!/、。

[0486] 従って、一端再生メニューを削除し自機器で再生成することになる。しかし、この場合、実施の形態 2で説明したように、再生メニューを削除するにあたって、 BD. INFO で規定されている FirstPlayBackおよび TopMenuから参照される Objectがどれであるかは解る力そこカゝら再生される PlayList (図 47で説明した再生メニューを構成する MPEG— TSを再生する PlayList)がどれかを判別するには Objectの Program 領域を逐次解析して!/ヽく必要がある。

[0487] また、前述のように再生メニューのボタンから PlayListを再生するにはボタンから P1 ayList再生用の Objectに遷移し、その Objectから PlayListを再生する必要がある

[0488] このようなボタンのみ力参照される Objectを識別するには、再生メニューを構成する MPEG—TSの多重化をほどき、ボタンの NV— DSを逐次解析していき、ボタン力も遷移して、る Objectの IDを逐次解析して、く必要があり大変な手間となる。

[0489] 従って本実施の开態では、 FirstPlaybackや TopMenuなど NV— DSを含むストリームを再生する Titleにお!/、て、 NV—DSから遷移する Objectの IDをメタデータとして記録するものとする。

[0490] また、当該メタデータは、図 40における BD. INFOの ExtensionDataに格納するものとする。

[0491] 本実施の形態におけるメタデータの例を図 48に示す。

[0492] 図 48に示すように BD. INFOの ExtensionData領域には、 FirstPlaybackのメタデータを格納する FirstPlaybackMeta ()領域と、 TopMenuのメタデータを格納する TopMenuMeta O領域とが存在する。さらに、 Title毎に各 Titleの属性を示す Tit le Domain領域と各 Titleのメタデータを格納する TitleMeta ()領域とが存在する。

[0493] Title Domainは、 Menu、 Real, Virtaul、 SlideShowの四つの属性（Domain) の!、ずれかを示す情報である。

[0494] Menu Domainは、 FirstPlayBackと TopMenuから遷移された Titleなど、 First Playbackと TopMenu以外に、映像をユーザに選択させて再生する再生メニューやディスク挿入時の自動再生シーケンス制御などを実現する Titleが有する属性である

[0495] Real Domainは、実際に撮影または録画した映像をシーケンシャルに再生するだけの Titleが有する属性である。

[0496] Virtual Domainは、撮影または録画した映像をユーザが編集した結果作成したプレイリストを再生するだけの Titleが有する属性である。 [0497] Slideshow Domainはスライドショウを再生する Titleが有する属性である。

[0498] FirstPlaybackMeta ()と TopMenuMeta ()と TitleMeta ()の構造は同一である。具体的には、 FirstPlaybackと TopMenuと各 Titleが参照する PlayListのフアイル名一覧である PLNameList領域と参照する Objectの IDの一覧である ObjectlD List領域からなる。

[0499] なお、各 TitleMeta ()にお!/、て、 PlayListの記録順情報を持たせるため、 PLNa meList領域に記録される PlayListのファイル名は当該 PlayListの作成順であってちょい。

[0500] 以上、本実施の形態におけるメタデータの例を説明した力本実施の形態のメタデータにより、各 Titleが参照する Objectや Objectから再生されるストリームを解析することなく、各 Titleで使用されるデータ（PlayList及び PlayListから参照されるデジタルストリームと、プログラム群である Object)を識別することができる。

[0501] 特に FirstPlaybackMeta ()と TopMenuMeta ()と前記 Title Domainが Menu である Titleの TitleMeta ()を解析することにより、当該ディスクにおける再生メ-ュ一を構成するデータ（PlayList及び PlayListから参照されるデジタルストリームと、プログラム群である Object)を識別可能である。

[0502] そのため、他機器が作成した再生メニューであっても容易に削除可能となる。特に再生メニューを実現するストリームにボタン (NV— DS)が含まれそのボタン力 Obje ctが参照されている場合でも容易に識別可能であり、削除も容易となる。

[0503] なお、例えば TopMenuから参照する Objectや PlayListが、任意の Title # Aでも参照されてヽる場合、本メタデータに基づ!/、て TopMenuから参照される Objectや P layListを削除、編集すると Title # Aの動作に支障が出る可能性がある。

[0504] この場合、規格として、 Title作成と同時に作成され当該 Titleが参照している Obje ctや PlayListに関しては、後から作成された Titleが参照することを禁止してもよい。

[0505] また、 Objectや PlayListを削除 ·編集する際、図 48を用いて説明したメタデータを元に、当該 Objectや PlayListが他の Titleからも参照されていないか事前に検索し、参照されて!、なければ削除すると!、う対策を取ってもよ!、。

[0506] また、 PLNameList領域および ObjectlDList領域に、当該 PlayListまたは Obje ctを参照して、る Titleの逆参照情報を持たせるなどの対策を取ってもょ、。

[0507] 以上、本発明の実施の形態 3について説明したが、本実施の形態の記録方法およびデータ構造は、各 Title配下の PlayList並びに Objectメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに本実施の形態の記録方法を実現する半導体に適用される。

[0508] (実施の形態 4)

従来、ビデオカメラで撮影した映像などを逐次ディスクに記録する場合にぉヽて、映像を次世代光ディスクの商用映像データ用のフォーマットである BD— ROM形式で映像を記録した場合、映像の記録順序を保持する方法が存在しなカゝつた。

[0509] そこで、実施の形態 4として、 BD— ROMの拡張領域に記録するメタデータを記録順に配置し、かつ、編集による順序入れ替えを禁止する記録方法について説明する

[0510] この記録方法により、ビデオカメラで撮影した映像を BD— ROM形式で記録した場合においても、撮影した映像の撮影順を保持することが可能であり、再生メニュー等においてユーザの期待する順序で撮影した映像のサムネイルを並べることが出来る

[0511] なお、本実施の形態において、撮影した映像を記録する AVストリームは、実施の形態 3と同じく、 MPEG— TS形式のストリーム（図 42参照）である。

[0512] また、本実施の形態では、ビデオカメラゃ据置ビデオレコーダーなどに於!、て、撮影または録画する映像を BD— ROM形式により記録する方法について述べる。

[0513] まず撮影の単位と BD管理情報との対応関係について述べる。

[0514] 撮影した映像並びに音声はそれぞれ V— PESならびに A— PESとして前述の図 4 2に示すように MPEG— TS形式のストリームに記録されていく。ここで撮影開始ボタンを押して力もボタンを放す、または撮影停止ボタンを押すまでの撮影単位を Shotと呼ぶこととすると、 1つの shotは、一本のストリームとして記録してもよいし、一本のストリームに複数の Shotを格納してもよ!/、。

[0515] ここで Shotは各 Shot毎または撮影日などのグループ単位毎に前述したプレイリス

(PlayList)に関連づけられる。そして最終的には各 PlayList単体または PlayList 単位で、前述の BD管理情報である BD. INFOで管理される Titleに関連づけられる

[0516] 図 16においてプレイリスド' XXX. PL"の詳細について述べた力本実施の形態で述べるビデオカメラなどで撮影したストリームにおヽては、必ず撮影の単位である Sh ot毎にプレイリストで管理する EVENT (Mark)を付けるものとする。

[0517] 以前述べたように、撮影の単位である Shotは、プレイリストの Markに一対一対応することとなる。従って、 Shotの撮影日時や Shotのサムネイル等の Shotに関連するデータの管理も Mark単位で行うことにより、 Shotと、 Shotと関連するデータとの対応関係が明確になり、参照や管理が容易になる。

[0518] 以上、撮影の単位である Shotと BD管理情報における Markとの対応関係について述べたが、そもそも BD— ROM形式は予め編集された映画などを記録し配布する用途に用いるものである。

[0519] そのため、例えば前述の Shotの撮影日時やそのサムネイル等、撮影した映像を記録する場合に BD管理情報では記録できな、情報が!/、くつか存在する。

[0520] 従って本実施の形態では、これら BD管理情報では記録出来な、情報を、メタデータとして別途管理するものとする。

[0521] メタデータ格納場所としては、 BD管理情報とは別のファイルに格納するものとしてもよ!/、し、 BD管理情報の各拡張領域に格納するものとしてもょ、。

[0522] BD管理情報の拡張領域とは、実施の形態 2で説明した" Extension"に相当する領域のことである。

[0523] 例えば、図 18において BD— ROM形式で記録されたディスクが挿入された際に B D Playerが最初に読み出す BD管理情報である BD. INFOの詳細につ!/、て述べた力図 18を用いて説明した構造に加えてデータの末尾に拡張領域として IndexEx tentionData ()を持つ。

[0524] 従って、本実施の形態では、前記 BD— ROMで規定出来な、情報をこの IndexE xtentionData Oにて規定するものとする。なお、説明するまでもないが、 PlayList や VOB管理情報ファイル (Cliplnformation)の拡張領域に分散してメタデータを格糸内してちょい。 [0525] 本実施の形態で規定する IndexExtentionData ()の例を図 49に示す。

[0526] 図 49は本実施の形態にて規定するメタデータを BD. INFOの拡張領域である Ind exExtentionData ()に格納した場合の例を示す図である。

[0527] なお、本実施の形態はこれに限定するものではなぐ例えば、 BD. INFOとは別のファイルに図 49に示す構造ならびにデータを持ったメタデータを記録して持たせてもよいし、図 49に示すメタデータを、 BD管理情報の各ファイルに分散させて持たせてちょい。

[0528] まず、前述した BD管理情報" BD. INFO"の末尾にある IndexExtentionData () に、 "Disclnfo"領域ど' PLTable"領域の二つの領域を持たせる。

[0529] "Disclnfo"領域はディスク全体に関するメタデータを格納するための領域であり、例として" Discタイトル"にはディスクのタイトル情報を格納し、 "Discサムネイル"には

、ディスクを代表するサムネイル画像に関する情報を格納する。

[0530] "PLTable"領域は BD管理情報の 1つである PlayListに関するメタデータを PlayL ist毎に格納する領域であり、 "PL— Number"領域と各 PlayListのメタデータ領域（図中の" PL # 1"〜"PL # m")とからなる。

[0531] "PL— Number"とプレイリスド' XXX. PL"のファイル総数とは同数となり、以降各 P layList (プレイリスド' XXX. PL")毎のメタデータが" PL # 1"から順に格納される。

[0532] 各 PlayListのメタデータは、例として" PL— FileName"領域ど' PL— Type"領域、

"PL作成日時"領域、 "PLタイトル"領域、 "MarkTable"領域の 5つの領域からなる。

[0533] "PL— FileName"領域は、当該メタデータ領域（"PL # 1"〜"PL # m")がどの Pla yListのメタデータを格納して!/、るかを示す情報であり、例えば PlayListファイル" XX

X. PL"のファイルボディ" XXX"が格納される。

[0534] また、 "PL— Type"領域には、当該 PlayListの種別が格納される。 BD— ROMにお!ヽては映像は全て予めォーサリングされて、るため PlayListに種別を設ける必要がな、が、撮影または録画する映像を BD— ROM形式で記録する場合は大きく二つに大別される。

[0535] まず 1つ目は撮影または録画したオリジナルの映像を一力再生するシナリオが記録される PlayListであり、以降本実施の形態では Real PlayListと呼ぶ。 [0536] もう一つは、ユーザがオリジナルの映像に対して再生順序の入れ替えや再生箇所の指定などの編集を行ったシナリオが記録される PlayListであり、以降本実施の形態では Virtual PlayListと呼ぶ。

[0537] ここで、撮影または録画した映像の単位である Shotと Real PlayList, Virtual P layListとの対応関係を図 50に示す。

[0538] 図 50に示すように、 Real PlayListは撮影した Shotが格納されたストリームを撮影順に再生するものであり、基本的にストリームが記録される際にストリーム情報と共に生成される。

[0539] また、 Real PlayListは、例えば Shotの撮影後に追加または修正されていく。

[0540] 一方、 Virtual PlayListはユーザによる映像編集の結果として記録した映像の一部を所望の順序で再生するためのものであり、ユーザの編集処理時に作成される。

[0541] このように撮影または録画したストリームは複数の PlayListから参照される可能性がある。このためある PlayListを削除する際に当該 PlayListが参照するストリームも同時に削除すると、存在しなヽストリームを参照する PlayListが出来てしまう可能性がある。

[0542] 従って、あるストリームは、必ず 1つの Real PlayListからは参照されるため、 Virtu al PlayList削除時は参照するストリーム及びストリーム情報は削除せず、 Real Pla yList削除時は参照するストリーム及びストリーム情報を削除し、当該ストリームを参照する Virtual PlayListを修正するものとしてもよ!/、。

[0543] 以上、 Real PlayListと Virtual PlayListについて説明した力これらの識別情報を前記" PL_Type"に格納するものとする。

[0544] なお、メニュー用ストリームがどのストリームであるかを容易に判別するため、メ-ュ一用ストリームを参照する PlayListであることを前記" PL— Type"に持たせてもよいし、後述する Mark用のメタデータやストリーム情報のメタデータに持たせてもよい。

[0545] また、図 34の説明の中で述べたプログラムが多重化されたストリーム（Interactive

Graphics (IG) Stream)を参照する PlayListであることを前記" PL— Type"に持たせてもよいし、後述する Mark用のメタデータやストリーム情報のメタデータに持たせてもよい。 [0546] 例えば、スライドショウを実現する PlayListである場合、当該ストリームは、ページ送りやページ戻り用のボタン及びボタンコマンド（IG Stream)をストリーム中に含む場合もあり得る。

[0547] この場合例えば、ある機器でスライドショウを作成した後、別の機器で当該スライドショウを変更する場合に、単純に編集してもよいのカゝ、それとも IG Streamを含んでおりそれを考慮した上で編集する必要があるのかを判断することが出来る。

[0548] 例えば IG Streamを含んだ Real PlayListであることが前記 PL— Typeに指定された識別子で判明した場合、当該機器はまず IG Streamを検出していき、検出した IG Streamを全て削除した上で、スライドショウを編集することが可能となる。

[0549] なお、図示して!/ヽな、が、あるディスクがどの機器で記録されたディスクであるのかどうかという情報を、例えば本実施の形態のメタデータにおける" Disclnfo"に持たせてもよい。

[0550] これにより、記録装置は前記 IG Streamを含むストリームは当該機器で作成されたものかどうかを判別することが可能である。

[0551] 例えば、前記 PL— Typeにより IG Streamを含む PlayListであることが判別された場合、当該機器で作成したものである場合は直接修正してもよ、。

[0552] 以下、図 49の説明を続行する。

[0553] "PL作成日時"領域には当該 PlayListを作成した日時を記録する。

[0554] "PLタイトル"領域には PlayListのタイトル名を記録する。

[0555] "MarkTable"領域は当該 PlayListメタデータが参照する PlayListが管理する各

Markのメタデータを格納する領域であり、 "Mark— Number"領域と各 Markのメタデータ領域（図中の" Mark # l"〜"Mark # n")からなる。

[0556] 図 49に示す例では" Mark— Number"と当該 PlayListが管理する Markの数とが同数となり、以降当該 PlayListが管理する順番に従って、 Mark毎のメタデータが"

Mark # 1"から順に格納される。

[0557] なお、本実施の形態では PlayListが管理する Markとメタデータで管理する Mark とか一対一対応するものとして記述する力これに限るものではない。

[0558] 例えば、再生を一時停止した地点を示す Markなど BD管理情報では規定出来なヽ Markをメタデータでのみ管理してもよ!/、。

[0559] この場合、例えば図 49に示す Markのメタデータ領域に BD管理情報で規定する

Markを参照して!/、るのか否かを示す情報と、参照して!/、る場合はその Markの IDを

、参照して!/、な、場合はメタデータで管理する Markが指すストリームの位置情報を格納する領域を別途設ける必要がある。

[0560] 各 Markのメタデータは、例として" Mark— Type"領域、 "サムネイル"領域、 "撮影日時"領域、および" PL参照情報"領域の 4つの領域力もなる。

[0561] "Mark— Type"領域は当該 PlayListで管理する Markの種別を記録するものであり、本実施の形態では当該 Markが Shotの先頭を示す Mark (Shot -Mark)であるか否かを示す。

[0562] この場合、 Markの機能の性質上、 Shotの先頭を示す Markを管理するのは前述の Real PlayListのみとなる。

[0563] また、本実施の形態では当該 PlayListを代表するサムネイルにあたるストリーム位置を Markとして管理するものとする。

[0564] 具体的には、 "Mark— Type"領域にて、当該 Mark力 PlayListの代表サムネイルを示す Mark (PL -Mark)なのか否かを識別する情報も持たせるものとする。その他

、ユーザが付加する BookMarkであるか否かなどを規定してもよ!/、。

[0565] 次に"サムネイル"領域は当該 Markの指すストリーム位置における画像をサムネィルとして指定する。

[0566] なお、当該 Mark力 hotの先頭を示す Markである場合、基本は Shotの先頭の画像がサムネイルとして設定される。しかし Shotを代表するサムネイルを参照させるために、当該 Markが指すストリーム位置の画像ではなぐユーザの設定や自動判別などにより抽出した、当該 Markが指すストリーム位置とは別の位置の画像を代表サムネイルとしてもよい。

[0567] "撮影日時"領域は、当該 Markが Shotの先頭を示す Markである場合、当該 Shot の撮影日時を記録する。

[0568] "PL参照情報"領域は、当該 Markが Shotの先頭を示す Markである場合のみ設定されるものとし、当該 Shotを参照する PlayListの参照情報を格納するものとする。 [0569] この PL参照情報は、前述したように当該 Shotまたは Shotを含むストリームが削除された際に、当該 Shotを参照しており削除時に修正の必要がある PlayListを容易に検索するために付加するものである。

[0570] なお、前述のように Shotと当該 Shotを管理する Real PlayListとは、一方が削除された際に自動的にもう一方も削除される関係にある。従って、 "PL参照情報"領域に格納する参照情報は Virtual PlayListに対する参照情報のみ格納するものとしてもよい。

[0571] なお、 Real PlayListの編集/削除時に更新されるべき Virtual PlayListを効率良く特定するために、 Real PlayListと Virtual PlayListのプレイリストファイル番号を予め別個に定義しておくことも考えられる。こうすることで、 Real PlayList編集時に内容を確認するべきプレイリストファイルを瞬時に特定することができる。この場合、 BD. INFOの Extensionのような特別な情報は必要がない。

[0572] 以上、本実施の形態におけるメタデータの種類とその格納方法について説明した力 Shotを一覧メニューとして表示する際、撮影'録画順にそのサムネイルを表示することで、 Shotの相関関係が掴みやすくユーザの利便性を向上することができる。

[0573] 本実施の形態ではこのような撮影 ·録画順のソートならびにメニュー表示を容易とするため、図 49で示したメタデータにおいて、 PlayListのメタデータ（図中" PL # 1"〜 "PL # m")を格納する順番を記録順に格納するものとする。

[0574] 基本的には PlayListのメタデータの格納位置は編集等でも変更しな、ものとする。

また図 51に示すように、 Real PlayListにおいて、 Shotの先頭を示す Markは、 Pla yListにおける Markの付加順ならびに当該 Markのメタデータの記録順も撮影順に並ぶものとし、当該順序は削除を除き編集等で入れ替えないものとする。

[0575] 以上により、 Real PlayListのメタデータの格納順と、当該 Real PlayListが管理する Markにお!/、て Shotの先頭を示す Markのメタデータの格納順とにより、当該デイスクに記録された Shotの撮影 ·録画順序を識別することが可能となる。

[0576] 以上により、 Shotの撮影順にサムネイルや撮影日時等を一覧表示した再生メ-ュ一を生成する場合は、図 49に示すメタデータを参照するだけでょ、。

[0577] また、 "PL Type"が Real PlayListである PlayListのメタデータを順次解析し、当該 PlayListのメタデータにおいて、 Mark— Type = Shot - Mark (当該 Markが S hotの先頭を示す）である Markのメタデータを順次参照しメニュー表示すればよ!、。

[0578] 例えば本実施の形態のメタデータが図 52 (A)に簡易的に示す状態である場合を想定する。この場合、 PlayList # 1、 # 2、 # 4は Real PlayListであり、 PlayList #

3は Virtual PlayListである。

[0579] 従って、 PlayListの記録順は、 PlayList # 1、 # 2、 # 4の順になる。

[0580] また、図中にお!/、て、 "（Shot) "が付された Markは、 Shotの先頭を示す Markを表している。

[0581] 従って、各 PlayListの中で Shotの先頭を示す Markの記録順を抽出すると、 Shot の記録順が PlayList # 1の Mark # 1, # 3、 PlayList # 2の Mark # 1、 PlayList # 4の Mark # 1 , # 2の順であることが分力る。

[0582] このようにして、最終的に Shotの一覧メニューを図 52 (B)のように表示することが出来る。

[0583] なお、 Real PlayList及び Virtual PlayListの作成順も前記メタデータの格納順序により識別することも可能である。

[0584] また、各 PlayListが管理する Markにおいて、 Mark— Typeが PlayListの代表サムネイルを示す Mark (PL— Mark)を検索することで、必要があれば PlayListのサムネイルを作成順に一覧表示したメニューも作成可能である。

[0585] 以上、実施の形態 4について説明したが、実施の形態 4の記録方法およびデータ構造は、撮影または録画した映像を BD— ROM形式で記録する場合に、映像の記録順序を保持するようにメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに実施の形態 4の記録方法を実現する半導体に適用される。

[0586] (実施の形態 5)

従来、ビデオカメラで撮影した映像などを逐次ディスクに記録する場合にぉヽて、映像を次世代光ディスクの商用映像データ用のフォーマットである BD— ROM形式で映像を記録した場合、映像の撮影日時を保持する方法が存在しなカゝつた。

[0587] そこで、実施の形態 5として、撮影した映像毎の撮影日時情報を BD— ROMの拡張領域にメタデータとして記録する記録方法について説明する。

[0588] この記録方法により、ビデオカメラで撮影した映像を BD— ROM形式で記録した場合においても、撮影した映像の撮影日時を保持することが可能であり、ユーザに対して撮影した映像の撮影日時を適切な形で提示することができる。

[0589] なお、本実施の形態にぉ、て、撮影した映像を記録する AVストリームは、実施の形態 3と同じく、 MPEG— TS形式のストリーム（図 42参照）である。

[0590] また、本実施の形態では、ビデオカメラゃ据置ビデオレコーダーなどに於!、て、撮影または録画する映像を BD— ROM形式により情報記録媒体に記録する方法について述べる。

[0591] なお、本実施の形態では情報記録媒体の例として次世代ディスクである BD— RO

M Discを例に挙げている力これに限られることはない。

[0592] 例えば、本実施の形態におけるアプリケーション及びデータ構造を DVDなどの光ディスクや他の情報記録媒体である、メモリーカード (SDメモリーカードやメモリースティックなど)ゃノヽードディスクなどに書き込む場合でも同様の効果を得る。

[0593] また、情報記録媒体ではなぐ本実施の形態におけるアプリケーション及びデータ構造をネットワークを介して配布する場合にぉ、ても同様の効果を得る。

[0594] 撮影の単位と BD管理情報との対応関係は、実施の形態 4と同じである。

[0595] すなわち、撮影した映像並びに音声はそれぞれ V— PESならびに A— PESとして前述の図 42に示すように MPEG— TS形式のストリームに記録されていく。

[0596] ここで撮影開始ボタンを押して力ボタンを放す、または撮影停止ボタンを押すまでなど、ユーザが撮影または録画した映像の単位 (撮影単位)を Shotと呼ぶこととすると、 1つの shotは、一本のストリームとして記録してもよいし、一本のストリームに複数の Shotを格納してもよ!/、。

[0597] 詳しくは後述する力 Shotは、 Shot毎または撮影日などのグループ単位毎に前述したプレイリスト（PlayList)に関連づけて管理されるものとし、各 Shotの先頭には当該プレイリストにて管理する Eventが設定されるものとする。

[0598] 本発明の実施の形態 1において、図 18を用いて BD管理情報の 1つで、ディスク全体の情報を管理する" BD. INFO"の例を説明した力本実施の形態では図 53の形式を取るものとする。

[0599] 図 53に示す BD. INFOはディスクに 1つだけ存在し、当該ディスクが挿入された際に一番初めに解釈される。図 53に示す BD. INFOは、 "Applnfo"と" TitleList，，、 " ExtensionData "力なり、 "Applnfo"にはディスク全体に関する情報が格納される

[0600] "TitleList"には当該ディスクに格納されるタイトルの情報が格納されており、 "Firs tPlayback"ど' TopMenu"という二つの特別なタイトルと複数の通常のタイトルとからなる。

[0601] 通常のタイトルの総数は" TitleList"以下の" Number"に格納される。 "FirstPlay back"ど' TopMenu"と各" Title"は、それぞれタイトル選択時に実行すべき後述する Objectへのリンク情報（Objectの ID)を持って!/、る。

[0602] FirstPlaybackは、ディスク挿入時に一番最初に選択されるタイトルであり、 TopM enuは、リモコンでメニューボタンが押された場合などに選択される再生メニュー用のタイトルである。

[0603] なお、本実施の形態において、 Objectに関する情報を格納する" BD. PROG"のデータ構造は、実施の形態図 3で説明した図 41に示す BD. PROGのデータ構造と同じである。

[0604] なお、図 41に示す" BD. PROG"は実施の形態 1において図 18を用いて説明した "BD. PROG"に変わるものであり、合わせて図 17を用いて説明した" XXX. PROG "は廃止される。

[0605] 以上、本実施の形態における BD管理情報について述べたが、前記 Shotを管理するプレイリストは、各プレイリスト単位で、前述の BD管理情報である BD. INFOで管理される Titleに関連づけられる。

[0606] 具体的には、 Titleが参照する Objectにおいて、当該 Titleに対応するプレイリストを再生するナビゲーシヨンコマンドが記述される。

[0607] また、図 16においてプレイリスド' XXX. PL"の詳細を説明した力プレイリストにて管理するイベントは、以後 Markと呼ぶことにする。 Markは前述の通り、当該プレイリスト内で生成されるイベント（Mark)を定義したものであり、プレイリストでは複数の Ma rkを IDで管理している。

[0608] また、各 Markは Markの種別（Mark_Type)、 Markの ID (Mark_ID)、イベント

(Mark)の生成時刻時刻 (Time)と有効期間（Duration)力も構成されて、る。ここで Markの種別である Mark— Typeには、 EntryMarkと LinkPointの二つの種別がある。

[0609] EntryMarkは Chapterとしてユーザが識別可能である Markであり、プレイリストの先頭から何番目の EntryMarkであるかをユーザに提示することで Chapter番号を提示可能である。

[0610] またリモコン操作により再生するチャプターを前後のチャプターに切り替えることも可能である。

[0611] LinkPointは、ユーザは識別できない Markであり、前述のような Chapterとしては識別されず、プログラム力もの再生位置指定など主にプログラムにて識別する再生時刻情報として用いられる。

[0612] 以上 Markについて説明した力本実施の形態で述べるビデオカメラなどで撮影または録画した映像を管理するプレイリストにぉ、ては、撮影の単位である Shot毎にその Shotの先頭にあたる再生時刻に対して必ず当該プレイリストにて管理する Entry Markを設定するものとする。

[0613] これにより、撮影の単位である Shotはプレイリストの EntryMarkに一対一対応することとなる。これによりユーザは撮影した Shotを Chapterとして識別可能となり、 Chap ter切替操作により再生する Shotを選択することも可能となる。

[0614] また、本実施の形態では Shotの撮影日時や Shotのサムネイル等の Shotに関連する情報の管理も EntryMark単位で行うこととする。これにより、 Shotと、 Shotと関連するデータとの対応関係が明確になり、参照や管理が容易になる。

[0615] 以上、撮影の単位である Shotと BD管理情報における Markとの対応関係について述べたが、そもそも BD— ROM形式は予め編集された映画などを記録し配布する用途に用いるため、例えば前述の Shotの撮影日時やそのサムネイル等、撮影した映像を記録する場合に BD管理情報では記録できな、情報が!/、くつか存在する。

[0616] 従って本実施の形態では、これら BD管理情報では記録出来な、情報を、メタデータとして別途管理するものとする。メタデータ格納場所としては、 BD管理情報とは別のファイルに格納するものとしてもょ、し、 BD管理情報の各拡張領域に格納するものとしてもよい。

[0617] BD管理情報の拡張領域とは、実施の形態 2で説明した" Extension"に相当する領域のことである。

[0618] 本実施の形態においては、 BD. INFOは図 53に示すようにデータの末尾に拡張領域として IndexExtentionData Oを持つ。また、各プレイリスト情報を格納する XX X. PLの詳細について図 16を用いて説明したが、プレイリスト XXX. PLにおいても図 16を用いて説明した構造に加えて、図 54に示すように、データの末尾に拡張領域として PlayListExtentionData ()を持つ。

[0619] 従って、本実施の形態では、前記 BD— ROMで規定出来ない情報をこの IndexE xtentionData ()や PlayListExtentionData ()にて規定するものとする。

[0620] なお、説明するまでもないが、以後述べるメタデータの格納方法についてはあくまでも例であり、以後述べる情報をメタデータとして格納することが重要であって VOB 管理情報ファイル (Cliplnformation)の拡張領域に格納したり、別の構造を取っても構わない。

[0621] 本実施の形態で規定する IndexExtentionData Oの例を、図 53を用いて説明する。

[0622] まず、前述した BD管理情報" BD. INFO"の末尾にある IndexExtentionData O に、 "Disclnfo"領域ど' PLTable"領域の二つの領域を持たせる。

[0623] "Disclnfo"領域はディスク全体に関するメタデータを格納するための領域である。

例として" Discタイトル"には Discのタイトル情報を格納し、 "Discサムネイル"には、ディスクを代表するサムネイル画像に関する情報を格納する。

[0624] "PLTable"領域は BD管理情報の 1つである PlayListのメタデータを格納する領域であり、 "PL— Number"領域と各 PlayListのメタデータ領域（図中の" PL # 1"〜

"PL # m")力なる。

[0625] "PL— Number"とプレイリスド' XXX. PL"のファイル総数とは同数となり、以降 Pla yList (プレイリスド' XXX. PL")毎のメタデータが" PL # 1"から順に格納される。 [0626] 各 PlayListのメタデータは、例として" PL— FileName"領域ど' PL— Type"領域を持つ。

[0627] "PL— FileName"領域は、当該メタデータ領域（"PL # 1"〜"PL # m")がどの Pla yListのメタデータを格納して!/、るかを示す情報である。例えば PlayListファイル" X XX. PL"のファイルボディ" XXX"が格納される。

[0628] また、 "PL— Type"領域には、当該 PlayListの種別が格納される。 BD— ROMにお!ヽては映像は全て予めォーサリングされて、るため PlayListに種別を設ける必要がな、が、撮影または録画する映像を BD— ROM形式で記録する場合は大きく二つに大別される。

[0629] まず 1つ目は撮影または録画したオリジナルの映像を管理し、順次先頭から再生するシナリオが記録される PlayListであり、以降本実施の形態では Real PlayListと呼ぶ。

[0630] もう一つは、ユーザがオリジナルの映像に対して再生順序の入れ替えや再生箇所の指定などの編集を行ったシナリオが記録される PlayListであり、以降本実施の形態では Virtual PlayListと呼ぶ。

[0631] 撮影または録画した映像の単位である Shotと Real PlayList, Virtual PlayList との対応関係は、実施の形態 4において図 50を用いて説明した当該対応関係と同じである。

[0632] すなわち、図 50に示すように、 Real PlayListは撮影した Shotが格納されたストリームを撮影順に再生するものであり、基本的にストリームが記録される際にストリーム情報と共に生成される。例えば Real PlayListは Shotの撮影後に追加または修正されていく。

[0633] 一方、 Virtual PlayListはユーザによる映像編集の結果として記録した映像の一部を所望の順序で再生するためのものであり、ユーザの編集処理時に作成される。

[0634] このように撮影または録画したストリームは複数の PlayListから参照される可能性がある。このためある PlayListを削除する際に当該 PlayListが参照するストリームも同時に削除すると存在しないストリームを参照する PlayListが出来てしまう可能性がある。 [0635] 従って、必ず 1つの Real PlayListからは参照されるため、 Virtual PlayList削除時は参照するストリーム及びストリーム情報は削除せず、 Real PlayList削除時は参照するストリーム及びストリーム情報を削除し、当該ストリームを参照する Virtual PlayListを修正するものとしてもよ!/、。

[0636] 以上、 Real PlayListと Virtual PlayListについて説明した力これらの識別情報を前記" PL— Type"に格納するものとする。またその他の種別として、当該プレイリストで再生されるストリームカ -ユー用ストリームであることを示す種別や、スライドショウであることを示す種別を設けてもよ!、。

[0637] また、図 34の説明の中で述べたプログラムが多重化されたストリーム（Interactive

Graphics (IG) Stream)を参照する PlayListであることを前記" PL— Type"に合わせて記録してもよい。

[0638] 例えば、当該プレイリストの PL— Typeがスライドショウであった場合、当該ストリームは、ページ送りやページ戻り用のボタン及びボタンコマンド（IG Stream)をストリーム中に含む場合もあり得る。

[0639] この場合、例えばある機器でスライドショウを作成した後、別の機器で当該スライドショウを変更する場合に、単純に編集してもよいのカゝ、それとも IG Streamを含んでおりそれを考慮した上で編集する必要があるのかを判断することが出来る。

[0640] 例えば IG Streamを含んだスライドショウであることが前記 PL— Typeに指定された識別子で判明した場合、当該機器はまず IG Streamを検出していき、検出した I G Streamを全て削除した上で、スライドショウを編集することが可能となる。

[0641] なお、図示していないがあるディスクがどの機器で記録されたディスクであるのかどうかという情報を、例えば本実施の形態のメタデータにおける" Disclnfo"に持たせてちょい。

[0642] これにより、記録装置は前記 IG Streamを含むスライドショウが当該機器で作成されたものかどうかを判別することが可能である。

[0643] 例えば、前記 PL— Typeにより IG Streamを含むスライドショウであることを判別した場合、当該機器で作成したものである場合は直接修正してもよ、。

[0644] 次に、本実施の形態で規定する PlayListExtentionData ()の例を図 54に示す。 [0645] PlayListExtentionData ()は、 "PL作成日時，，領域、 "PLタイトル"領域、 "PLサムネイル"領域、および" MarkTable"領域の 4つの領域からなる。

[0646] "PL作成日時"領域には当該 PlayListを作成した日時を記録する。

[0647] "PLタイトル"領域には PlayListのタイトル名を記録する。

[0648] "PLサムネイル"領域には当該 PlayListを代表するサムネイルへの参照情報を記録する。

[0649] "MarkTable"領域は当該 PlayListメタデータが参照する PlayListが管理する各

[0650] 図 54に示す例では "Mark— Number"と当該 PlayListが管理する Markの数とが同数となり、以降当該 PlayListが管理する順番に従って、 Mark毎のメタデータが"

Mark # 1"から順に格納される。

[0651] なお、本実施の形態では PlayListが管理する Markとメタデータで管理する Mark とか一対一対応するものとして記述する力これに限るものではない。

[0652] 例えば、再生を一時停止した地点を示す Markなど BD管理情報では規定出来な

Vヽ Markをメタデータでのみ管理してもよ!/、。

[0653] この場合、例えば図 54に示す Markのメタデータ領域に、 BD管理情報で規定する

[0654] 各 Markのメタデータは、例として" Mark— Type"領域と"サムネイル"領域、および

"撮影日時"領域、の 3つの領域力なる。

[0655] "Mark— Type"領域は当該 PlayListで管理する Markの種別を記録するものである。 Mark— typeの 1つとして、例えば当該 Markが Shotの先頭を示す Markである

Shot— Markがある。この Shot— Markを管理するのは前述の Real PlayListのみとしてちよい。

[0656] その他の Mark— Typeとしては、後述する OldShotMarkの他に、例えばスライドショウにおける各静止画の開始位置を意味する SlideshowMarkを定義してもよい。 [0657] 例えば Real PlayListが再生するストリームは動画とスライドショウの混在を許すとした場合、当該 SlideshowMarkと ShotMarkにより各 Chapterが動画なのか静止画なの力判別することができる。

[0658] またメニュー表示にぉ、て動画 Shotのサムネイルのみを表示する場合であっても、

Markが EntryMarkであり、かつ、 Markのメタデータにおける MarkTypeが Shot

Markのもののみサムネイル一覧表示するといつたことが可能となる。

[0659] また、例えば MakerPrivateと!、う MarkTypeを定義しておき、メーカー独自機能を実現する Markを実現可能としてもよ、。

[0660] 次に"サムネイル"領域は当該 Markの指すストリーム位置における画像をサムネィルとして指定する。なお、当該 Markが Shotの先頭を示す Markである場合、基本は

Shotの先頭の画像がサムネイルとして設定される。

[0661] しかし Shotを代表するサムネイルを参照させるために、当該 Markが指すストリーム位置の画像ではなぐユーザの設定や自動判別などにより抽出した、当該 Markが指すストリーム位置とは別の位置の画像を代表サムネイルとしてもよい。

[0662] "撮影日時"領域は、当該 Markが Shotの先頭を示す Markである場合、当該 Shot の撮影日時を記録する。

[0663] なお、 Markのメタデータとして記録される情報は、上記説明の内容に限られることはない。例えば、 BD— ROM規格では記録出来ない、撮影した情報に関する情報をメタデータとして持たせてもよヽ。

[0664] 以上、本実施の形態におけるメタデータの種類とその格納方法について説明した。

Shotを一覧メニューとして表示する際、撮影'録画順にそのサムネイルを表示することで、 Shotの相関関係が掴みやすくユーザの利便性を向上することができる。

[0665] 本実施の形態ではこのような撮影 ·録画順のソートならびにメニュー表示を容易とするため、図 53および図 54で示したメタデータにおいて、図 53における PlayListのメタデータ（図中" PL # 1"〜"PL # m")を格納する順番を記録順に格納するものとする。

[0666] また、基本的には PlayListのメタデータの格納位置は編集等でも変更しないものとする。また前述の図 51に示すように、 Real PlayListにおいて、 Shotの先頭を示す Shot Markは当該 Shotの撮影順に並ぶものとし、当然プレイリストにて管理する Markの付加順及び図 54で説明した当該 Markのメタデータの記録順も同様に撮影順に並ぶものとする。

[0667] また、当該順序は削除を除き編集等で入れ替えないものとする。以上により、 Real

PlayListのメタデータの格納順と、当該 Real PlayListが管理する Markにおいて

Shotの先頭を示す Markのメタデータの格納順とにより、当該ディスクに記録された

Shotの撮影'録画順序を識別することが可能となる。

[0668] 以上により、 Shotの撮影順にサムネイルや撮影日時等を一覧表示した再生メ-ュ一を生成する場合は、図 53および図 54に示すメタデータを参照するだけでよい。

[0669] また、 "PL— Type"が Real PlayListである PlayListのメタデータを順次解析し、当該 PlayListのメタデータに於、て、 Mark— Type = Shot - Mark (当該 Markが S hotの先頭を示す）である Markのメタデータを順次参照しメニュー表示すればよ!、。

[0670] 例えば本実施の形態のメタデータが図 55 (A)に簡易的に示す状態である場合を想定する。この場合、 PlayList # 1、 # 2、 # 4は Real PlayListであり、 PlayList #

3は Virtual PlayListである。

[0671] 従って、 PlayListの記録順は、 PlayList # 1, # 2, # 4の順になる。

[0672] また、図中にお!/、て、 "（Shot) "が付された Markは、 Shotの先頭を示す Markを表している。また、図中において、 "（OldShot) "が付された Markは、後述する、失われるメタデータを保持するための Markを表して!/、る。

[0673] 従って、各 PlayListの中で Shotの先頭を示す Markの記録順を抽出すると、 Shot の記録順が PlayList # 1の Mark # 1, # 3、 PlayList # 2の Mark # 1、 PlayList #

4の Mark # 1, # 2の順であることがわかる。

[0674] このようにして、最終的に Shotの一覧メニューを図 55 (B)のように表示することが出来る。

[0675] 以上、説明したように本実施の形態の記録方法およびデータ構造により、撮影または録画した映像 (Shot)の記録順を管理することが可能であり、また各 Shot毎に撮影または録画した映像の撮影日時やサムネイルといった情報をメタデータとして管理することが可能となる。 [0676] (実施の形態 6)

次に本発明の実施の形態 6について説明する。

[0677] なお、本実施の形態では情報記録媒体の例として次世代ディスクである BD— RO

M Discを例に挙げている力あくまでも例であり、本実施の形態のアプリケーション及びデータ構造を DVDなどの光ディスクや他の情報記録媒体である、メモリーカード（SDメモリーカードやメモリースティックなど）ゃノヽードディスクなどに書き込む場合でも同様の効果を得る。

[0678] また、情報記録媒体ではなぐ本実施の形態のアプリケーション及びデータ構造をネットワークを介して配布する場合にぉヽても同様の効果を得る。

[0679] 実施の形態 5にお、て、撮影または録画した映像の撮影日時やサムネイルと、つた

BD— ROM規格では記録出来ない情報を Shot単位で情報記録媒体に記録する方法について説明した。

[0680] 実施の形態 6では、 Shotの編集作業により Shotの撮影日

、つた情報が失われると、う問題を解決する記録方法にっ、て説明する。

[0681] 上記問題の具体例を、図 56を用いて説明する。

[0682] まず初期状態として図 56 (A)に示すように 1つのプレイリスト（Real PlayList)が撮影時間 20分の 3つの Shot (Shotl〜Shot3)を管理しているものと想定する。

[0683] ここで図 55 (A)に示すように MarkType = ShotMarkの Markを各 Shotの先頭に付与し、各 Shotの撮影日時やサムネイル、必要があれば前述の撮影時間などの情報を実施の形態 6で述べたように Markのメタデータで管理するものとする。

[0684] また ShotMarkは本実施の形態ではユーザに Chapterとして識別させるため Entr yMarkとする。

[0685] 以上、説明した初期状態から、図 56 (B)に示すように Shotlと Shot2を結合する編集を行った場合を想定する。この場合、 Shot2は Shotlの後ろに結合され、 Shotlと Shot2とは、 1つの Shotである撮影時間 40分の Shotlとなる。さらに、 Shot2の先頭に付与されて、た ShotMarkは削除される。

[0686] この状態で、図 56 (C)に示すように Shotlを旧 Shot2の先頭よりも後ろの時間位置にあたる 25分の地点で 2つに分割する編集を行う場合を想定する。 [0687] このように分割してできた新たな Shotを Shot4とすると、 Shot4の先頭にも新規に MarkType = ShotMarkの EntryMarkを設定し、 Markのメタデータを記録することになる。

[0688] この場合、 Shot4の撮影日時を正確に計算することは不可能である。ここで、例えば、 Shotlの撮影日時である" 9月 1日 12時 0分"に、前述の分割した時間位置である 25分をカ卩えることが考えられる。しかし、この加算で得られる" 9月 1日 12時 25分"という日時は、 Shot4の撮影日時として正しくない。

[0689] このように、 Shotの結合、分割と、つた処理をおこなうことで、 Shotの撮影日時が失われるという問題がある。

[0690] そこで本実施の形態では、 MarkTypeとして新規に OldShotMarkという MarkTy peを設けるものとする。

[0691] この MarkType = 01dshotMarkは図 56 (B)で示した結合処理によって失われるメタデータを保持するための Markであり、ユーザが Chapterとして識別するための Markではない。そのため、本実施の形態では MarkType = OldShotMarkは Link Pointにのみ設定可能とする。

[0692] 編集処理によっても Shotの撮影日時等のメタデータを保持し、例えば Shotの正確な撮影日時を設定可能とする本実施の形態の具体内容について、図 57を用いて説明する。

[0693] まず図 57 (A)に初期状態を示す。これは図 56 (A)で示した初期状態と同じである。また以後行う編集も図 56 (B)に示す編集内容と同じ編集を実行することを想定する

[0694] すなわち、図 57 (A)に示す初期状態から、図 57 (B)に示すように Shotlと Shot2 の結合処理を行い Shot4を生成する編集を行ったとする。

[0695] この場合、まず Shot4の先頭に付与すべき EntryMarkは Shotlのものと同様であり特に処理は行わない。

[0696] 一方、 Shot2は消失するため Shot2の先頭に付与していた MarkType = ShotMa rkの EntryMarkを LinkPointに変更する。

[0697] 次に、図 54を用いて説明した MarkTypeを ShotMarkから OldShotMarkに変更する。これにより Shot2の先頭を示していた Markは BD— ROMにおける管理情報としては、 LinkPointとして保持される。そのため、 Markと一対一として管理される Ma rkのメタデータも同じく保持される。

[0698] 次に、図 57 (C)〖こ示すように、 Shot4の先頭から 25分の地点で Shot4を 2つに分割する編集を行、、 Shot5と Shot6の 2つの Shotを生成する編集を行ったとする。

[0699] この場合、 Shot5の先頭に付与すべき EntryMarkは Shot4のものと同様であり特に処理は行わない。

[0700] 一方、 Shot6の先頭には EntryMarkが設定されていないため、 Shot6の先頭にも新規に MarkType = ShotMarkの EntryMarkを設定する必要がある。また、当該 E ntryMarkのメタデータも新規に記録することになる。

[0701] この場合の Shot6の撮影日時を計算する方法を以下に述べる。まず、分割前の Sh ot4において、分割地点にあたる Shot6の先頭より前に存在する Markを検索する。

[0702] ここで MarkType = OWShotMarkの LinkPointを検出する前に、 MarkType = ShotMarkの EntryMarkを検出、つまり Shot4の先頭に到達した場合は、単純に S hot4の撮影日時に分割した地点の時間を加えたものが Shot4の撮影日時となる。

[0703] し力し、本例の場合、図 57 (C)に示すように、旧 Shot2の先頭よりも後方で Shot4 を分割して、るため、 MarkType = OWShotMarkの LinkPointが先に検出される

[0704] この場合は、旧 Shot2の先頭にあたる MarkType = 01dShotMarkの LinkPoint のメタデータを参照して" 9月 5日 9時 30分"という日時情報が得られる。

[0705] 次に、検出した MarkType = 01dShotMarkの LinkPointの地点（旧 Shot2の先頭)から Shot6の先頭までの再生時間である 5分を、先ほど得た日時情報（9月 5日 9 時 30分）〖こカ卩える。

[0706] このようにして算出される" 9月 5日 9時 35分"という正しい日時情報が、 Shot6の撮影日時情報となる。

[0707] なお、図示しないが、図 57 (B)に示す Shot4を先頭から 20分の地点、すなわち旧 Shot2の先頭の地点で分割する場合は、単に旧 Shot2の先頭を示す LinkPointを EntrvMarkに変更し、 Markのメタデータにおける MarkTypeを Shotmarkに変更するだけでよい。

[0708] なお、図 56および図 57を用いて説明した例は Shotの結合や分割といった、あくまでもストリームの再生位置を指定して、る Real PlayListの再生制御データの変更による編集作業で発生する問題を例としている。

[0709] し力しながら、 Shotのある区間を中抜き削除するといつた AVストリーム自体を編集する場合にぉヽても適用出来る。

[0710] 例えば、ストリームの一部を削除する場合は、削除部分の直後の再生時刻に Mark を設定し、当該 Markのメタデータに 57 (C)に示す手法と同様に計算した撮影日時を設定すればよい。

[0711] なお、 Markを EntryMarkとし、メタデータにおける MarkTypeを ShotMarkにする力、 Markを LinkPointとしメタデータにおける MArkTypeを OldShotMarkにするかについては、以下のように判断する。

[0712] すなわち、削除部分の前後の映像の扱いにより、削除部分の前後の映像を各々別の Shotとして扱う場合は前者として設定し、削除部分の前後の映像を結合し 1つの S hotとして扱う場合は後者として設定する。

[0713] 以上のように本実施の形態の記録方法およびデータ構造により、 Shotの結合や分割といった処理を行っても Shotの撮影日時を保持することができる。

[0714] なお、撮影日時情報など撮影および録画した映像の情報は、メタデータとして BD

ROMの管理情報の拡張領域に格納する方法だけでなぐストリーム中に例えば S

EI— MESSEGEに埋め込むことも可能である。

[0715] またこの場合分割等の編集処理を行ってもその地点でストリームカゝら撮影日時を検出することも可能である。

[0716] 従って、図 56 (B)に示す Shotの結合を行った場合、ストリーム中に撮影日時情報を持たせて、る場合は、前述のように Shot2の EntryMarkを LinkPointに変更し M arkType = ShotMarkを OldShotに変更するといつた一連の処理を行わないものとしてちよい。

[0717] また、図 56 (C)に示す Shotの分割を行った場合、まずストリーム中の撮影日時情報を調べ、ストリーム中に撮影日時情報が記録されている場合は、図 56 (C)を用いて説明した撮影日時計算処理を行わずストリームから撮影日時を検出し、メタデータとして設定してちょい。

[0718] 以上、本発明の実施の形態 5および 6について説明したが、これら実施の形態で示した記録方法およびデータ構造は、撮影または録画した映像を BD— ROM形式で記録する場合に、映像の記録順序を保持するようにメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに、これら実施の形態の記録方法を実現する半導体に適用される。

[0719] また、実施の形態 5および 6の記録方法およびデータ構造によれば、映像を撮影した順序を記録可能であり、特に、民生機器産業において利用される可能性をもつ。

[0720] (実施の形態 7)

従来、ストリーム内にメタデータを記録する場合には、その記録順が不明であり、数多くのメタデータの全体を検索し解析しなければ、必要なメタデータが記述されてヽるの力否かが分力もない。

[0721] また、同一種類のメタデータを記述する異なるメタデータがあるような場合、読み出し機器の解析処理が煩雑になるとヽぅ課題もある。

[0722] そこで、実施の形態 7として、映像情報を符号化する際に、映像情報への付随情報を同時に符号化する情報記録装置であって、付随情報は、映像情報のピクチャ単位に付与され、 1つの付属情報は識別情報 (ID)と実情報 (データ)力も構成され、同一ピクチャ内で同一種類の情報を格納できる前記付属情報を複数記述する場合には、所定の識別情報 (ID)を持つ付属情報を記録することを特徴とする情報記録装置、および、当該情報記録装置における記録方法について説明を行う。

[0723] この情報記録装置および記録方法によれば、メタデータの検索性を向上することができ、同一種類のメタデータが別個の方法で記録されている場合であっても、機器の性能に応じて容易に解析することが可能となる。

[0724] なお、実施の形態 7は、ムービー機器でのメタデータに関する内容である。基本的には実施の形態 1に基づく内容であり、拡張または異なる部分を中心に説明する。

[0725] 図 58は、 PESパケット以下のデータ構造を示す図である。 BDやデジタル放送のように MPEG2—TSを使う場合には、 1つの PESパケットに 1つのピクチヤが格納されることが一般的である。

[0726] 1つの MPEG— 4 AVCで符号化されたピクチャは、アクセスユニットの先頭を示す AU Delimiter (Access Unit Delimiter)、シーケンス属性を示す SPS (Seq uence Parameter Set)、ピクチャ属'性を示す PPS (Picture Parameter Set) 、付属情報などを格納する SEI (Supplemental Enhancement Information)、および、スライス符号情報を示す Sliceなど力構成される。

[0727] 付属情報を格納する SEIは、 ClosedCaption情報やその他の情報を格納している

[0728] ここでは、主にビデオカメラレコーダ向けのメタデータを HDMとして束ね、 SEIの中に格納している。

[0729] 図 59には、 SEIのデータ構造を示した。図に示されたように当該 SEIにどのような付属情報が入っているかを示す識別情報 (type— indicator)により、格納されているデータ種類が特定できる。

[0730] 例えば、 "type— indicator = 0x00000020"であれば、 HDMデータが格納されているということがわ力る。

[0731] HDMデータは、 HDM— pack— ID (8ビット）と HDM— pack— data (32ビット）から構成される HDM— packの集合体である。

[0732] この ID値によって、どのような種類の付属情報力後続の HDM— pack— dataに記録されているのかを示している。ここで示されるように、 HDM— packは連続して H

DM— meta ()内に記録される。

[0733] ちなみに、 HDM— packは、 DV (Digital Video)カメラが使用している付属情報の DVパックと同じデータ構造（8ビットの ID + 32ビットのデータ）である。

[0734] 図 60は、 HDM— packの ID値と格納している情報との関係を示す表である。

[0735] TIME列（上位 4ビットが 0001b)の TIME CODE, BINARY GROUPと、 CA

MERA列（上位 4ビット力 SOI 1 lb)の全ての HDM— packは DVパックと同じである。

[0736] REC DATE&TIMEは、この付属情報 (ピクチャ）が撮影された日時情報である。

[0737] EXIF列（上位 4ビットが 1010b)、 GPS列（上位 4ビット力 011b、 1100b)はデジタルスチルカメラで使われている Exifの情報と同じである。 [0738] ただし、 Exifで使われている 32bitZ32bitの RATIONAL表記ではサイズが大きいため、 16bitZ 16bitの RATIONAL表記として!/、る。

[0739] EXIF OPTION, GPS OPTIONには、この表に記載のない Exif ZGPSの情報を書き込みた、場合に使うパックである。

[0740] 具体的には、 HDM— pack— dataに Exifの Tag値を書く Exif— Tag (16ビット）、 E xif〖こ 16ビット表記の RATIONAL 16、符号付きの SRATIONAL 16を新規追加した Exif— Type (8ビット）、および、続くパック数を示す Pack— Length (8ビット）を記述し、 Exifのメタデータを後続のパックに記録することができる。

[0741] MAKER列（上位 4ビット力 110b)には、メーカーコードと記録したモデルコードを

16ビットずつで記述する MAKER&MODELパックと、各メーカーが独自に使うことのできる MAKER OPTIONパックが規定されて!、る。

[0742] このように、 HDM— pack— ID値によって、どのデータが記録されて!、るパックなの、すぐに特定することができる。しかし、 HDM_meta ()の中での記録規則が無いと常に最後のパックまで検索が必要となり、高速なメタデータの検索 Z抽出が不可能になる。

[0743] また、 SEIはピクチャ単位で 256バイトの上限サイズと共に書き込まれるデータであるため、このメタデータの処理にはリアルタイム性 (高速性）が要求される。

[0744] また、全てのパックをピクチャごとに記録する必要はな、ため、最後のパックまで検索しても所望のメタデータを格納したパックが見つからないことも考えられる。

[0745] そこで、 HDM— meta ()内での HDM— pack ()の記録 j噴は、 HDM— pack ()の HDM— pack— IDの小さい順番に並ぶことと規定することが重要である。

[0746] これにより、所望のパックを検索するために、 HDM— meta ()内でさらなるサーチが必要力否かを判定することが可能となる。また、所望のパックの ID値を超えた場合、それより先に所望のパックが存在していないことが分かり、サーチ処理を早期に終了することが可能となる。

[0747] 図 61は、上記処理の流れを示すフロー図である。

[0748] HDMメタの取得が開始されると（S901)、 HDMパック数を取得する（S902)。 HD Mメタを取得し、データの最後尾であれば（S903で Yes)、 HDMメタの取得に係る処理を終了する（S904)。

[0749] また、データの最後尾でなければ（S 903で No)、取得した、情報を全て取得したか否かを判断する。全て取得した場合は（S905で Yes)、 HDMメタの取得に係る処理を終了する（S904)。また、全て取得していない場合は（S 905で No)、解析を続けても取得した情報が取得できるか否かを判断する。

[0750] 取得できな!/、場合は（S906で Yes)は、 HDMメタの取得に係る処理を終了する（S

904)。また、取得できる場合は（S906で No)、 1つ HDM— pack ()を取得し、上記のデータの最後尾であるか否かの判断 (S903)に戻る。

[0751] 図 61に示すように、 HDM— meta ()内のパックは、 ID順で記述されているため、所望のパックを最低の処理負荷で検索 Z抽出することができる。

[0752] 図 62は、 DVにて定義されて!、る CAMERA列のパックと、 EXIFにて定義されて!ヽる EXIF列のパックとの格納して、る情報の同一性を比較したものである。

[0753] 図 62に示すように、 EXIF列のパックにて格納される情報が、 CAMERA列のパックでも記述できるケースがあることが分かる。即ち 2重に定義された状態となっている

[0754] これは、 HDM— meta ()が DVと Exifの主要なメタデータを利用して!/、るために、焦点距離などの光学パラメーターなどで一部重複して、ることを示して、る。

[0755] 例えば、 EXIF列の FOCAL LENGTH (焦点距離）は、 CAMERA列の CONS UMER CAMERA1と CONSUMER CAMERA2のそれぞれにて記述することが可能である。

[0756] 安価な機器では、静止画向けで高品位な EXIF列の情報までは不必要だが、 DV で使われている CAMERA列程度の精度の情報で十分な場合も想定される。

[0757] また、このように同種の情報が 2重持ちされているため、 HDM— meta ()を解析する処理が煩雑になる課題もある。

[0758] そこで、 EXIF列のパックを記録する場合には、そのパックが格納する情報を CAM

ERA列にお!、ても記述できるのであれば、その CAMERA列のパックも記録することが重要である。

[0759] 先ほどの ID順で記録されるルールを加味して考慮すれば、安価な機器は、 ID順にサーチを行ヽ、自らが欲し、情報の精度である CAMERA列のパックだけを解析し、以降に EXIF列のパックがあつたとしても、 CAMERA列の情報だけを取得した時点で、解析処理を止め、ユーザにその情報を提供することが可能となる。

[0760] また、 EXIF列まで対応した機器にぉ、ては、 CAMERA列で所望のデータを取得できても、 EXIF列まで解析を行い、より高精度な付属情報を取得することが容易に可能となる。

[0761] 図 63は、 DVと EXIFとで同種情報を持つ場合の記録ルールの例を説明する図である。この例では、 EXIF列の EXPOSURE TIME, F NUMBER, EXPOSURE BIAS, MAX APERTURE, FLASH,および、 FOCAL LENGTHのパックが記録されて、るために、対応する CAMERA列のパックも記録されて、る。

[0762] また、 F NUMBERおよび FOCAL LENGTHが記録されているため、 CONSU

MER CAMERAlが記録されており、同様に EXPOSURE TIMEが記録されているため、 SHUTTERが記録されている。

[0763] このように、精度が異なる同種の情報を記録する場合には、精度の低、方の情報が必ず記録順として先になるように記録されていることが肝要である。

[0764] なお、対応するパックの相関が複雑になったり、 EXIF列のデータを追加するために、 EXIF列よりも前方の CAMERA列のデータを追加することになる力このために

、メモリ上での挿入処理が煩雑になることも考えられる。

[0765] このような場合には、 EXIF列に所定のパックを記録する場合には、必ず CAMER

A列の CONSUMER CAMERAlだけは記録する、といった規則を設けることも効果的である。

[0766] 図 62によれば、所定のパックとは、 F NUMBER, EXPOSURE PROG. 、 FO

CAL LENGTH, WHITE BALANCEを指している。

[0767] 勿論、より簡単に、 EXIF列に何か記録する場合には、必ず CAMERA列の所定のノックを記録するとしてもよヽ。

[0768] また、 CAMERA列を使う力、 EXIF列を使うかを当該ストリームの管理情報（YYY

. VOBI)などで示しておくことも考えられる。

[0769] DVは動画向けのメタデータとして設計され、 EXIFは静止画向けのメタデータとして設計されているため、当該 VOBが動画力静止画かの情報を VOBIに記録させ、その値に応じて、動画であれば CAMERA列を使い、静止画であれば EXIF列を使うことも可能である。

[0770] 本実施の形態の情報記録装置および記録方法は、光ディスクなどに記録するメタデータに情報の重複がある場合や、その種類が膨大である場合などに、メタデータの検索処理を簡易化することができ、大幅に再生 (検索)処理時間を減らすことができる。そのため、ハードディスクや半導体メモリなどの記録メディア上に記録する場合にも同様に有用である。

[0771] (実施の形態 8)

近年、デジタルスチルカメラなどで撮影した静止画を、動画と共に管理したいというユーザ要求が近年高まってきて、る。

[0772] しかしながら、デジタルスチルカメラの静止画は一般には非常に高画素（1920x1 080以上）の JPEGであって、 HDTVへの出力を行うことが前提である民生 AV機器にとつては、その Codecとサイズの両面から扱いにくいと!/、う課題があった。

[0773] また、次世代 DVD規格 (BD— ROM規格)では、スライドショウとして静止画を扱うことは可能である力基本的にはパッケージメディアを対象とした規格である。そのため、スライドショウの静止画の再生順番を入れ替えたり、 1枚を削除するといつた編集作業が実現困難である。

[0774] そこで実施の形態 8として、 BD— ROM規格のスライドショウにデジタルスチルカメラの静止画を取り込む際に編集容易な形で取り込めるようにする記録方法について説明する。

[0775] 具体的には、 1つの静止画映像を含むシステムストリームである静止画ユニットを生成し、前記静止画ユニットの再生を管理する再生管理情報と共に情報記録媒体に記録する情報記録装置であって、静止画ユニットは記録する情報記録媒体の記録単位 (セクタ)の整数倍のデータサイズとする情報記録装置および記録方法にっ、て説明する。

[0776] 本実施の形態では、上記情報記録装置および記録方法によって、静止画スライドショウを用いて、動画と静止画を同列で管理することができ、イベント単位 (例えば子供の運動会で撮影した動画と静止画)などでコンテンツを管理することが可能となる。

[0777] また、その際に静止画スライドショウに編集耐性を与えることで、静止画スライドショゥの再生順序の入れ替えや削除といった編集作業が容易かつ高速になる。

[0778] 実施の形態 8は、上述のように、 BD— ROMの静止画スライドショウにおけるストリーム構造に関する内容である。基本的には実施の形態 1に基づく内容であり、拡張または異なる部分を中心に説明する。

[0779] 図 64は、 BDのストリーム構造を示している。 BDで扱うストリームは記録するメディアのセクタサイズなどとは無関係に、 TSパケット（188バイト）とその TSパケットのデコーダへの入力時刻を復元する ATS (Arrival Time Stamp、 4バイト）をカ卩えた Time d TS Packetと呼ばれる 192バイトの繰り返しで構成されている。

[0780] BDが TSパケット（MPEG— 2 Transport Stream)を採用している理由は、デジタル放送が MPEG2—TSを用いて行われていることとの親和性を確保するためである。

[0781] 192ノイトの Timed TS Packetは、 DVDや BDの 2KBのセクタサイズとは合致しな、ため、これを 32個集めた単位 (Aligned Unitとも呼ばれる 6KB)を最小記録単位としている。

[0782] 従って、仮に編集がある場合には、この Aligned Unit (6KB)単位での追加 Z削除がなされ、 BDで扱うストリーム自体が整数個の Aligned Unitから構成されるように扱われる。

[0783] 図 65は、デジタルスチルカメラなどで撮影した静止画を BD— ROMで規定するスライドショウとして取り込んだ場合のフォーマット構成を示す。

[0784] 図に示すように、 "XXX. PROG"は" XXX. PL"を再生するようなプログラム（再生管理情報）であり、 "XXX. PL"は、 1つの Cellから成るプレイリストである。

[0785] Cell # 1は、 3つの Still Unit (lつの静止画映像を含む MPEG2— TSの区間）を含む" YYY. VOB"ストリーム全体を指し示している。また、再生開始時刻（In # 1)と再生終了時刻 (Out # 1)とは、この 3つの Still Unitの再生期間を指定する情報である。

[0786] 各 Still Unit内の、 I—pictureに付与された PTSの値はそれぞれ PTS # 1、 PTS # 2、および PTS # 3であって、ユーザのスキップ指令などのインタラクションが無い場合には、その PTSタイミングから自動で切り替わり再生される。

[0787] 従って、ユーザが何も操作をしない場合には、 PTS # 2— PTS # 1の時間が Still Unit # 1の静止画の表示時間となる。

[0788] ユーザが次の静止画にスキップするなどといった操作を行う場合には、その操作のタイミングで次の Still Unitの再生を開始するようすることもできる。

[0789] このような、 BD— ROMのスライドショウを使ってユーザがデジタルスチルカメラの静止画を取り込む場合、 Cell内の STC時間軸（MPEGストリームの内部基準時間）が連続して経過しな、と、けな、など制限があるために、例えば Still Unit # 2だけを削除するなどの編集をされた場合、ストリーム力もの部分削除時に、 PTS # 3などのストリームに埋め込まれた時刻情報などを修正していく必要がでてくる。

[0790] また、 Still Unit # 2がセクタァライメントされていないため、つまり、データ長が 6K Bの整数倍にされていないため、ストリームからの中抜き編集において、セクタ単位の削除処理ができず煩雑となる。

[0791] これは、 Still Unit # 2の最初と最後の Timed TS Packetが、両端の Still Un it (Stiil Unit # 1と # 3)の Timed TS Packetと同じセクタに記録されているためである。

[0792] このようにスライドショウの編集には、セクタァライメントと時刻情報の変更という 2つの処理が付きまとう。以下に、この課題を解決するための方法を説明する。

[0793] 図 66に示す" XXX. PROG"は図 65に示すものと同一だ力 "XXX. PL"を構成する Cellを Still Unitと 1対 1に対応させている。この利点は、特定の Still Unitを削除してもストリーム内部のタイムスタンプの修正が不要になるということである（図に示すように、各 Cellはそれぞれ独自の STC時間軸上に配置されて、る。）。

[0794] また、図 67に詳細に示すように、 1つの Still Unitのデータサイズが Aligned Un it (6KB)の整数倍となるように、ダミーの Timed TS Packet (NULLパケットでよ V、）を追加することが可能である。

[0795] このようにすることで、 1枚の静止画単位（1つの Still Unit単位）での削除や、順番の入れ替えにも容易に対応することができるようになる。 [0796] 1つの Still Unitは、例えば MPEG2— Videoを用いる場合には、シーケンスへッダ、 GOPヘッダ、 Iピクチャ、シーケンスエンドコードからなる 1枚の静止画を示す主映像ストリームと、プログラム構成に必要な PSIZSIパケット（PAT、 PMT、および SIT など）、基準時刻 STCを生成する時刻情報を運ぶ PCRパケット、および静止画 (主映像ストリーム）に重畳して表示する副映像ストリームとから構成される。

[0797] 前述のような制限をカ卩えることで、例えば図 66の Still Unit # 2を削除したり、 Still

Unit # 2と Still Unit # 3の順番を変更する処理が、単純なプレイリストファイルの Cell情報の修正と、ストリーム（Still Unit)の部分削除 Z部分並び替えで済むようになる。

[0798] つまり、修正箇所以降のストリームを解析し、 PTSの値を変更していくなどの処理は不要である。

[0799] 図 68には、副映像情報として、デジタルスチルカメラなどで良く使われている Exif 情報を字幕ストリームとして取り込む例を示している。

[0800] Exif情報とは、シャッター速度や ISO感度、撮影日時などの静止画に関連する付加情報を格納した情報であり、各種様々な静止画に関連する情報を格納している情報である。

[0801] このような静止画に付随する情報は常には表示される必要は無いため、図 68 (C) に示すような副映像情報を、 BD— ROMにおける字幕ストリームのような仕組み (ュ一ザが意図的に表示 Z非表示を選択可能な仕み)として多重化することも考えられる。

[0802] この場合、ユーザは、図 68 (B)のような静止画だけの静止画スライドショウだけではなぐもしユーザが望むならば、それに付随する情報も表示する図 68 (A)のような形式で静止画スライドショウを楽しむこともできる。

[0803] 図 69は、デジタルスチルカメラの静止画と Exif情報から、図 68 (A)〜図 68 (C)に示すような主映像と副映像に区別されたスライドショウを作成するためのフロー図である。

[0804] 静止画の取り込みが開始されると（S1001)、まず、変換する静止画を読み込む（S 1002)。静止画カゝら Exif情報を抽出し（S1003)、 Exif情報の一部を主映像に重畳する副映像としてエンコードする（S1004)。

[0805] また、静止画を 1920 X 1080の画素数にリサイズする（S1005)。リサイズ後、 1枚の I— pictureからなる主映像（MPEG2— Video等）としてエンコードする（S1006)

[0806] 以上により、主映像と副映像とが生成され、主映像と副映像とを合わせた Stil Uni tを生成する（S1007)。

[0807] Stil Unitがセクタアラインメントされて!/、る場合は（S 1008で Yes)、静止画の取り込みに係る処理を終了する（S1010)。

[0808] また、 Stil Unitがセクタアラインメントされて!/ヽな、場合は（S 1008で No)、ダミーパケット（NULLパケット）を追カロし、セクタアラインメントにする（S 1009)。その後、静止画の取り込みに係る処理を終了する（S1010)。

[0809] 一般的にはデジタルスチルカメラの画素数はフル HDの 1920x1080を超えるものが多いため、 HDサイズにリサイズして I— pictureとしてエンコードを行う。また、所定の Exif情報を抽出し、字幕ストリーム（PGストリーム： Presentation Graphicsストリーム）としてエンコードを行う。

[0810] エンコードが済んで多重化を行い、 Still Unit単位でセクタァライメントがとれるよう

、ダミーパケットを挿入して多重化を終える。

[0811] 本実施の形態にかかる光ディスクおよびその記録 Z再生装置、記録 Z再生方法は

、光ディスクに記録された静止画スライドショウの 1論理単位を記録媒体の記録単位 ( セクタ）に合わせることで、静止画スライドショウの編集が極めて容易となる。

[0812] また、光ディスクに限らず、ハードディスクや半導体メモリなどの記録メディア上に記録する場合にも有用であり、このような種々の記録メディアに記録する AVレコーダや

、記録された記録メディア、これらの記録メディアを再生する AVプレーヤに適用できる。

産業上の利用可能性

[0813] 本発明によれば、映像コンテンツ等を追記した際に、既存のディスクメニューに関連するファイルを容易に識別し削除可能な情報記録媒体を提供できる。この情報記録媒体は、ディスク媒体のみならず、半導体メモリ等の他の記録媒体としても実現可能である。従って映像コンテンツの制作に携わる映画産業'民生機器産業において使用される情報記録媒体として特に有用である。

Claims

請求の範囲

[1] デジタルストリームの一部または全部である部分区間で構成される AVコンテンツであるタイトルが記録された情報記録媒体であって、

デジタルストリームにおける部分区間の位置と再生順序とを指定することで前記タイトルを特定する情報を有するプレイリストと、

前記プレイリストを呼び出すことにより前記タイトルの再生を制御するプログラムと、前記タイトルを識別するタイトル識別情報と、前記プログラムを識別するプログラム識別情報とが対応付けられて含まれているインデックス情報と、

前記タイトル識別情報と前記プレイリストを識別するプレイリスト識別情報とが対応付けられて含まれて、る拡張情報と

が記録されてヽる情報記録媒体。

[2] 前記情報記録媒体には、複数のタイトルが記録されており、

前記拡張情報には、更に、前記複数のタイトルそれぞれのタイトル識別情報に対応する番号であるタイトル番号が、それぞれのプレイリスト識別情報に対応付けられてプレイリストの記録日時順に並んで含まれている

請求項 1記載の情報記録媒体。

[3] 前記情報記録媒体には、複数のタイトルが記録されており、

前記複数のタイトルのうちの 1つは、自身以外のタイトルをユーザに選択させるメ- ユーであり、

前記拡張情報には、更に、前記メニューを前記情報記録媒体に記録した記録装置の生産者を識別する生産者識別情報が含まれてヽる

請求項 1記載の情報記録媒体。

[4] 請求項 1記載の情報記録媒体にデジタルストリームを記録する記録装置であって、前記情報記録媒体には、複数のタイトルが記録されており、

前記記録装置は、

前記メニューの再生を制御するプログラムから呼び出されるプレイリストを、前記拡張情報に含まれる、前記メニューのタイトル識別情報に対応付けられた前記プレイリスト識別情報を用いて特定するプレイリスト特定手段と、

前記メニューに換えて、新たなメニューを生成し前記情報記録媒体に記録するメ- ユー生成手段と、

前記メニュー生成手段により前記新たなメニューが生成される場合、前記プレイリスト特定手段により特定されたプレイリストを削除する削除手段と

を備える記録装置。

[5] 前記プレイリストは、更に、前記プレイリストにより特定されるタイトルの管理情報を有しており、

前記削除手段は、前記プレイリストを削除する場合、更に、前記プレイリストに指定されるデジタルストリームの部分区間と前記タイトルの管理情報とを前記情報記録媒体から削除する

請求項 4記載の記録装置。

[6] 更に、前記情報記録媒体に新たなタイトルを追加するとともに、前記情報記録媒体に記録されているタイトル番号の最後の番号以降の番号を前記タイトルのタイトル番号として、前記タイトルに関連するプレイリストのプレイリスト識別情報と対応させて、前記拡張情報に追加する編集手段を備える

請求項 4記載の記録装置。

[7] 前記拡張情報には、更に、前記タイトル識別情報に対応する番号であるタイトル番号が、前記プレイリスト識別情報と対応付けられて、プレイリストの記録日時順に並んで含まれており、

前記記録装置は、更に、前記拡張情報に含まれるタイトル番号を読み出す番号読出手段を備え、

前記メニュー生成手段は、前記新たなメニューに、前記番号読出手段により読み出されたタイトル番号と前記タイトル番号に対応するタイトルを示す情報とを表示するように前記新たなメニューを生成する

請求項 4記載の記録装置。

[8] 更に、前記情報記録媒体に記録されてヽるタイトルの編集を行う編集手段を備え、前記プレイリスト特定手段は、更に、前記編集手段により、前記情報記録媒体に記録されているタイトルが削除された場合、削除されたタイトルに関連するプレイリストを、前記拡張情報に記録されている、前記削除されたタイトルのタイトル番号と対応付けられたプレイリスト識別情報を用いて特定し、

前記編集手段は、前記プレイリスト特定手段により特定されたプレイリストに示されるデジタルストリームの部分区間を、タイトルが削除されたことを示す内容のデジタルストリームに置き換える

請求項 7記載の記録装置。

[9] 前記拡張情報には、更に、前記メニューを前記情報記録媒体に記録した記録装置の生産者を識別する生産者識別情報が含まれており、

前記記録装置は、更に、前記拡張情報に含まれる生産者識別情報に示される生産者が、前記記録装置の生産者と一致するか否かを判定する判定手段を備え、前記メニュー生成手段は、前記判定手段により、前記生産者識別情報に示される生産者が、前記記録装置の生産者と一致しないと判定された場合、前記新たなメニユーを生成し、

前記削除手段は、前記判定手段により、前記生産者識別情報に示される生産者が、前記記録装置の生産者と一致しないと判定された場合、前記プレイリスト特定手段により特定されたプレイリストを削除する

請求項 4記載の記録装置。

[10] 請求項 1記載の情報記録媒体にデジタルストリームを記録する記録方法であって、前記情報記録媒体には、複数のタイトルが記録されており、

前記記録方法は、

前記メニューの再生を制御するプログラムから呼び出されるプレイリストを、前記拡張情報に含まれる、前記メニューのタイトル識別情報に対応付けられた前記プレイリスト識別情報を用いて特定するプレイリスト特定ステップと、

前記メニューに換えて、新たなメニューを生成し前記情報記録媒体に記録するメ- ユー生成ステップと、

前記メニュー生成ステップにお、て前記新たなメニューが生成される場合、前記プレイリスト特定ステップにおいて特定されたプレイリストを削除する削除ステップとを含む記録方法。

[11] 請求項 1記載の情報記録媒体にデジタルストリームを記録するためのプログラムであって、

前記情報記録媒体には、複数のタイトルが記録されており、

前記プログラムは、

前記メニュー生成ステップにお、て前記新たなメニューが生成される場合、前記プレイリスト特定ステップにおいて特定されたプレイリストを削除する削除ステップとをコンピュータに実行させるためのプログラム。

[12] 請求項 1記載の情報記録媒体にデジタルストリームを記録する集積回路であって、前記情報記録媒体には、複数のタイトルが記録されており、

前記集積回路は、

前記メニューに換えて、新たなメニューを生成し前記情報記録媒体に記録するメ- ユー生成手段と、前記メニュー生成手段により前記新たなメニューが生成される場合、前記プレイリスト特定手段により特定されたプレイリストを削除する削除手段と

を備える集積回路。