"映像情報を符号化する際に、映像情報への付属情報を同時に符号化して、情報記録媒体に情報を記録する情報記録方法であって、前記付属情報は、映像情報のピクチャ単位に付与されており、前記付属情報が、同じ種類且つ精度が異なる複数の情報を含む場合、精度の低い情報を、精度の高い情報よりも記録の順番で先に、前記情報記録媒体に記録することを特徴とする情報記録方法。映像情報を符号化する際に、映像情報への付属情報を同時に符号化して、情報記録媒体に情報を記録する記録装置であって、前記付属情報は、映像情報のピクチャ単位に付与されており、前記付属情報が、同じ種類且つ精度が異なる複数の情報を含む場合、精度の低い情報を、精度の高い情報よりも記録の順番で先に、前記情報記録媒体に記録する記録手段を有することを特徴とする記録装置。ここで、現在、撮影した映像等のデジタルコンテンツ以下、単にコンテンツという。を、情報記録媒体である前述のDVD等のディスクに逐次記録する各種のビデオカメラレコーダ以下、単にビデオカメラという。が多くのメーカーで生産され、広く流通している。また、これらビデオカメラは、独自のメニュー画面を生成し、ディスクに書き込む機能を有している。このメニュー画面を以下、ディスクメニューという。ユーザは、ビデオカメラで情報記録媒体に映像を記録し、その情報記録媒体をプレーヤで再生すると、そのビデオカメラで生成されたディスクメニューを見ることができる。また、そのメニューから再生等の対象とするタイトルの選択を行うことができる。しかしながら、様々なメーカーで生産される各種のビデオカメラにおいて、ディスクメニューに係る各種ファイルの記述内容や構成等が統一されているわけではない。つまり、あるメーカーのビデオカメラで生成されたディスクメニューを、他のメーカーのビデオカメラが解釈することは実質的に不可能である。そのため、例えば、あるメーカーのビデオカメラで映像が記録されたディスクが、他のメーカーのビデオカメラにロードされ、新たなタイトルの追加等が行われた場合、当該他のメーカーのカメラでは、記録済みのディスクメニューに関するファイルを削除し、新たにディスクメニューを作成する必要がある。この場合、ディスクがロードされたビデオカメラでは、記録済みのディスクメニューに関連する各種ファイルを、そのディスクメニューの再生を制御するプログラム等を解析することにより探し出すという、極めて高度な解析作業が必要となる。そのため、ディスクがセットされた後に、映像の記録等の動作が開始可能となるまで長時間掛かることになり、実質的には、上記の各種ファイルを探し出せないといった問題がある。また、新たなディスクメニューを記録する際に、不要となった既存のディスクメニューに関連するファイルを削除しない場合、不要なファイルがディスクに蓄積していくことになる。これにより、ディスクの記録可能容量を不要に圧迫するだけでなく、当該ディスクを使用する記録装置および再生装置においてファイル管理に係る処理負荷が増加することになる。そこで本発明は、上記従来の課題を考慮し、ある記録装置で生成されたメニューが情報記録媒体に記録された後にその情報記録媒体が他の記録装置にセットされた場合、当該他の記録装置において本来的には不要な処理負荷および処理時間を発生させないための記録装置、および、情報記録方法を提供することを目的とする。上記目的を達成するために、本発明の情報記録方法は、映像情報を符号化する際に、映像情報への付随情報を同時に符号化して、情報記録媒体に情報を記録する情報記録方法であって、前記付随情報は、映像情報のピクチャ単位に付与されており、前記付随情報が、同じ種類且つ精度が異なる複数の情報を含む場合、精度の低い情報を、精度の高い情報よりも記録の順番で先に、前記情報記録媒体に記録することを特徴とする。これにより、メタデータの検索性を向上することができ、同一種類のメタデータが別個の方法で記録されている場合であっても、機器の性能に応じて容易に解析することが可能となる。また、情報記録媒体は、デジタルストリームの一部または全部である部分区間で構成されるAVコンテンツであるタイトルが記録された情報記録媒体であって、デジタルストリームにおける部分区間の位置と、再生順序とを指定することで前記タイトルを特定する情報を有するプレイリストと、前記プレイリストを呼び出すことにより前記タイトルの再生を制御するプログラムと、前記タイトルを識別するタイトル識別情報と、前記プログラムを識別するプログラム識別情報とが対応付けられて含まれているインデックス情報と、前記タイトル識別情報と前記プレイリストを識別するプレイリスト識別情報とが対応付けられて含まれている拡張情報とが記録されている。これにより、本発明の情報記録媒体を使用する記録装置が、情報記録媒体に記録するタイトルの1つであるメニューを削除する際に、そのメニューの再生を制御するプログラムを解析することなく、そのメニューに関連するプレイリストを容易に特定することができる。従って、例えば、記録装置であるビデオカメラにおいて、他のビデオカメラが生成しディスクに記録したディスクメニューを削除する際、ディスクメニューに関連するプレイリストを特定し、削除することができる。また、この削除に係る作業において、プログラムの解析等を行う必要がなく、容易に削除すべきプレイリストを特定することができる。つまり、本発明の情報記録媒体を使用する記録装置において、本来的には不要な処理負荷および処理時間が発生することがない。また、本発明の記録装置は、映像情報を符号化する際に、映像情報への付随情報を同時に符号化して、情報記録媒体に情報を記録する記録装置であって、前記付随情報は、映像情報のピクチャ単位に付与されており、前記付随情報が、同じ種類且つ精度が異なる複数の情報を含む場合、精度の低い情報を、精度の高い情報よりも記録の順番で先に、前記情報記録媒体に記録する記録手段を有する。これにより、メタデータの検索性を向上することができ、同一種類のメタデータが別個の方法で記録されている場合であっても、機器の性能に応じて容易に解析することが可能となる。また、記録装置は、前記情報記録媒体にデジタルストリームを記録する記録装置であって、前記情報記録媒体には、複数のタイトルが記録されており、前記複数のタイトルのうちの1つは、自身以外のタイトルをユーザに選択させるメニューであり、前記記録装置は、前記メニューの再生を制御するプログラムから呼び出されるプレイリストを、前記拡張情報に含まれる、前記メニューのタイトル識別情報に対応付けられた前記プレイリスト識別情報を用いて特定するプレイリスト特定手段と、前記メニューに換えて、新たなメニューを生成し前記情報記録媒体に記録するメニュー生成手段と、前記メニュー生成手段により前記新たなメニューが生成される場合、前記プレイリスト特定手段により特定されたプレイリストを削除する削除手段とを備えるとしてもよい。これにより、本発明の記録装置は、容易にタイトルに関連するプレイリストを特定することができ、そのプレイリストを削除することができる。従って、例えば、ビデオカメラとして本発明の記録装置を実現した場合、他メーカーのビデオカメラによりディスクメニューが記録されたDVDや半導体メモリ等の情報記録媒体から、容易にそのディスクメニューに関連するプレイリストを削除することができる。つまり、不要なファイルを削除した上で、新たなディスクメニューを生成し、当該情報記録媒体に記録することができる。また、このように、不要なファイルを削除することで、当該情報記録媒体の記録可能容量を無駄に消費することがなく、またファイル管理に係る処理負荷の増加を抑えることができる。なお、本発明は、このような情報記録装置として実現することができるだけでなく、このような情報記録装置が備える特徴的な手段を有する集積回路として実現することもできる。これら特徴的な手段は、個別に1チップ化されても良いし、これらのうちの一部又はすべてを含むように1チップ化されても良い。また、本発明は、このような情報記録装置が備える特徴的な手段をステップとする記録方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、CD-ROM等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。また、本発明は、本発明の情報記録媒体から情報を読み取って再生する再生装置として実現したり、このような再生装置が備える特徴的な手段をステップとする再生方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、CD-ROM等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。ある記録装置で生成されたメニューが情報記録媒体に記録された後にその情報記録媒体が他の記録装置にセットされた場合、当該他の記録装置において本来的には不要な処理負荷および処理時間を発生させないための記録装置、および、情報記録方法を提供することができる。以下、添付の図面を参照しながら、本発明を実施するための最良の形態ついて説明する。なお、本願請求項1に係る発明に最も近い実施の形態は実施の形態2であるが、理解を容易にするために、実施の形態2における情報記録媒体等の基本的な構成を説明する実施の形態1を先に説明する。実施の形態1まず、BDBlu-rayDisc-ROMおよびBD-ROMを再生するBD-ROMプレーヤの基本的な構成および動作について、図1~図30を用いて説明する。ディスク上の論理データ構造図4は、BD-ROMのデータ階層を示す図である。図4に示すように、ディスク媒体であるBD-ROM104上には、AVデータ103と、AVデータに関する管理情報及びAV再生シーケンスなどのBD管理情報102と、インタラクティブを実現するBD再生プログラム101とが記録されている。なお、各タイトルの実体データは、AVデータ103として存在し、各タイトルのシナリオ制御記述データ以下、単にシナリオともいう。は、BD管理情報102として存在する。なお、本実施の形態では、映画などのAVコンテンツを再生するためのAVアプリケーションを主眼においてBD-ROMの説明を行うが、BD-ROMをCD-ROMやDVD-ROMの様にコンピュータ用途の記録媒体として使用することも当然のことながら可能である。図5は、前述のBD-ROM104に記録されている論理データの構造を示す図である。BD-ROM104は、他の光ディスク、例えばDVDやCDなどと同様にその内周から外周に向けてらせん状に記録領域を持ち、内周のリードインと外周のリードアウトの間に論理データを記録できる論理アドレス空間を有している。また、リードインの内側にはBurstCuttingAreaBCAと呼ばれる、ドライブでしか読み出せない特別な領域がある。この領域はアプリケーションから読み出せないため、例えば著作権保護技術などに利用されることがよくある。論理アドレス空間には、ファイルシステム情報ボリュームを先頭に映像データなどのアプリケーションデータが記録されている。ファイルシステムとは従来技術で説明した通り、UDFやISO9660等の規格により定められたデータを管理する仕組みのことであり、通常のPCと同じように記録されている論理データをディレクトリ、ファイル構造を使って読み出しする事が可能になっている。本実施の形態の場合、BD-ROM104上のディレクトリ、ファイル構造は、ルートディレクトリROOT直下にBDVIDEOディレクトリが置かれている。このディレクトリはBD-ROMで扱うAVデータや管理情報などのデータ図4に示すBD再生プログラム101、BD管理情報102、AVデータ103が記録されているディレクトリである。BDVIDEOディレクトリの下には、次の7種類のファイルが記録されている。BD.INFOファイル名固定BD管理情報の一つであり、BD-ROM全体に関する情報を記録したファイルである。BD-ROMプレーヤは最初にこのファイルを読み出す。BD.PROGファイル名固定BD再生プログラムの一つであり、BD-ROM全体に関わるプログラムを記録したファイルである。XXX.PLXXXは可変、拡張子PLは固定BD管理情報の一つであり、シナリオを記録するプレイリストPlayList情報を記録したファイルである。プレイリスト毎に1つのファイルを持っている。XXX.PROGXXXは可変、拡張子PROGは固定BD再生プログラムの一つであり、前述したプレイリスト毎のプログラムを記録したファイルである。プレイリストとの対応はファイルボディ名XXXが一致するによって識別される。YYY.VOBYYYは可変、拡張子VOBは固定AVデータの一つであり、VOB従来例で説明したVOBと同じを記録したファイルである。1つのVOBは1つのファイルに対応する。YYY.VOBIYYYは可変、拡張子VOBIは固定BD管理情報の一つであり、AVデータであるVOBに関わる管理情報を記録したファイルである。VOBとの対応はファイルボディ名YYYが一致するによって識別される。ZZZ.PNGZZZは可変、拡張子PNGは固定AVデータの一つであり、字幕及びメニュー画面を構成するためのイメージデータであるPNGWorldWideWebConsortiumW3Cによって標準化された画像フォーマットでありピングと読む。形式のイメージファイルである。1つのPNGイメージは1つのファイルに対応する。プレーヤの構成次に、前述のBD-ROM104を再生するプレーヤの構成について図6及び図7を用いて説明する。図6は、BD-ROM104を再生するBD-ROMプレーヤの基本的な構成の概要を示す図である。図6に示すBD-ROMプレーヤにおいて、BD-ROM104上のデータは、光ピックアップ202を通して読み出される。読み出されたデータはそれぞれのデータの種類に応じて専用のメモリに記録される。BD再生プログラムBD.PROGまたはXXX.PROGファイルはプログラム記録メモリ203に、BD管理情報BD.INFO、XXX.PLまたはYYY.VOBIファイルは管理情報記録メモリ204に、AVデータYYY.VOBまたはZZZ.PNGファイルはAV記録メモリ205にそれぞれ記録される。プログラム記録メモリ203に記録されたBD再生プログラムはプログラム処理部206によって処理される。管理情報記録メモリ204に記録されたBD管理情報は管理情報処理部207によって処理される。また、AV記録メモリ205に記録されたAVデータはプレゼンテーション処理部208によって処理される。プログラム処理部206は、管理情報処理部207から再生するプレイリストの情報やプログラムの実行タイミングなどのイベント情報を受け取りプログラムの処理を行う。また、プログラムで再生するプレイリストを動的に変更する事が可能であり、この場合は管理情報処理部207に対して変更後のプレイリストの再生命令を送ることで実現する。プログラム処理部206は、更に、ユーザからのイベント、例えば、ユーザが操作するリモコンからのリクエストを受け付け、ユーザイベントに対応するプログラムがある場合は、実行処理する。管理情報処理部207は、プログラム処理部206の指示を受け、その指示に対応するプレイリスト及びそのプレイリストに対応したVOBの管理情報を解析する。更に、プレゼンテーション処理部208に再生の対象となるAVデータの再生を指示する。また、管理情報処理部207は、プレゼンテーション処理部208から基準時刻情報を受け取り、時刻情報に基づいてプレゼンテーション処理部208にAVデータ再生の停止指示を行う。更に、プログラム処理部206に対してプログラム実行タイミングを示すイベントを生成する。プレゼンテーション処理部208は、映像、音声、および字幕それぞれのデータに対応するデコーダを持ち、管理情報処理部207からの指示に従い、AVデータのデコード及び出力を行う。映像データ及び字幕データは、デコード後にそれぞれの専用プレーンに描画される。具体的には、映像データはビデオプレーン210に描画され、字幕データ等のイメージデータはイメージプレーン209に描画される。更に、2つのプレーンに描画された映像の合成処理が合成処理部211によって行われTVなどの表示デバイスへ出力される。図6で示すように、BD-ROMプレーヤは図4で示したBD-ROM104に記録されているデータ構造に基づいた構成をとっている。図7は、図6に示すプレーヤの構成を詳細化したブロック図である。図6に示す各構成部と、図7に示す各構成部との対応は以下の通りである。AV記録メモリ205はイメージメモリ308とトラックバッファ309に対応する。プログラム処理部206はプログラムプロセッサ302とUOUserOperationマネージャ303に対応する。管理情報処理部207はシナリオプロセッサ305とプレゼンテーションコントローラ306とに対応する。プレゼンテーション処理部208はクロック307、デマルチプレクサ310、イメージプロセッサ311、ビデオプロセッサ312とサウンドプロセッサ313とに対応する。BD-ROM104から読み出されたVOBデータMPEGストリームはトラックバッファ309に、イメージデータPNGはイメージメモリ308にそれぞれ記録される。デマルチプレクサ310は、クロック307から得られる時刻に基づき、トラックバッファ309に記録されたVOBデータを抜き出す。更に、VOBデータに含まれる映像データをビデオプロセッサ312に音声データをサウンドプロセッサ313にそれぞれ送り込む。ビデオプロセッサ312及びサウンドプロセッサ313はそれぞれMPEGシステム規格で定められる通りに、デコーダバッファとデコーダからそれぞれ構成されている。即ち、デマルチプレクサ310から送りこまれる映像、音声それぞれのデータは、それぞれのデコーダバッファに一時的に記録され、クロック307に従い個々のデコーダでデコード処理される。イメージメモリ308に記録されたPNGデータは、次の2つの処理方法がある。PNGデータが字幕用の場合は、プレゼンテーションコントローラ306によってデコードタイミングが指示される。クロック307からの時刻情報をシナリオプロセッサ305が一旦受け、適切な字幕表示が行えるように、字幕表示時刻開始及び終了になればプレゼンテーションコントローラ306に対して字幕の表示、非表示の指示を出す。プレゼンテーションコントローラ306からデコード/表示の指示を受けたイメージプロセッサ311は対応するPNGデータをイメージメモリ308から抜き出し、デコードし、イメージプレーン209に描画する。また、PNGデータがメニュー画面用の場合は、プログラムプロセッサ302によってデコードタイミングが指示される。プログラムプロセッサ302がいつイメージのデコードを指示するかは、プログラムプロセッサ302が処理しているBDプログラムに因るものであって一概には決まらない。イメージデータ及び映像データは、図6で説明したようにそれぞれデコード後にイメージプレーン209およびビデオプレーン210に描画され、合成処理部211によって合成出力される。BD-ROM104から読み出された管理情報シナリオ、AV管理情報は、管理情報記録メモリ204に記録されるが、シナリオ情報BD.INFO及びXXX.PLはシナリオプロセッサ305によって読み出され処理される。また、AV管理情報YYY.VOBIはプレゼンテーションコントローラ306によって読み出され処理される。シナリオプロセッサ305は、プレイリストの情報を解析し、プレイリストによって参照されているVOBとその再生位置をプレゼンテーションコントローラ306に指示し、プレゼンテーションコントローラ306は対象となるVOBの管理情報YYY.VOBIを解析して、対象となるVOBを読み出すようにドライブコントローラ317に指示を出す。ドライブコントローラ317はプレゼンテーションコントローラ306の指示に従い、光ピックアップを移動させ、対象となるAVデータの読み出しを行う。読み出されたAVデータは、前述したようにイメージメモリ308またはトラックバッファ309に記録される。また、シナリオプロセッサ305は、クロック307の時刻を監視し、管理情報で設定されているタイミングでイベントをプログラムプロセッサ302に投げる。プログラム記録メモリ203に記録されたBDプログラムBD.PROGまたはXXX.PROGは、プログラムプロセッサ302によって実行処理される。プログラムプロセッサ302がBDプログラムを処理するのは、シナリオプロセッサ305からイベントが送られてきた場合か、UOマネージャ303からイベントが送られてきた場合である。UOマネージャ303は、ユーザからリモコンキーによってリクエストが送られてきた場合に、当該リクエストに対応するイベントを生成しプログラムプロセッサ302に送る。このような各構成部の動作により、BD-ROMの再生がおこなわれる。アプリケーション空間図8は、BD-ROMのアプリケーション空間を示す図である。BD-ROMのアプリケーション空間では、プレイリストPlayListが一つの再生単位になっている。プレイリストはセルCellの再生シーケンスから構成される静的なシナリオと、プログラムによって記述される動的なシナリオとを有している。プログラムによる動的なシナリオが無い限り、プレイリストは個々のセルを順に再生するだけであり、また、全てのセルの再生を終了した時点でプレイリストの再生は終了する。一方で、プログラムは、プレイリストを超えての再生記述や、ユーザの選択またはプレーヤの状態に応じて再生する対象を動的に変えることが可能である。典型的な例としてはメニュー画面を介した再生対象の動的変更が挙げられる。BD-ROMの場合、メニューとはユーザの選択によって再生するシナリオ、即ちプレイリストを動的に選択するための機能の構成要素の1つである。また、ここで言うプログラムは、時間イベントまたはユーザイベントによって実行されるイベントハンドラの事である。時間イベントは、プレイリスト中に埋め込まれた時刻情報に基づいて生成されるイベントである。図7で説明したシナリオプロセッサ305からプログラムプロセッサ302に送られるイベントがこれに相当する。時間イベントが発行されると、プログラムプロセッサ302はIDによって対応付けられるイベントハンドラを実行処理する。前述した通り、実行されるプログラムが他のプレイリストの再生を指示することが可能であり、この場合には、現在再生されているプレイリストの再生は中止され、指定されたプレイリストの再生へと遷移する。ユーザイベントは、ユーザのリモコンキー操作によって生成されるイベントである。ユーザイベントは大きく2つのタイプに分けられる。一つ目は、リモコンが備えるカーソルキー上下左右キーまたは決定キーの操作によって生成されるメニュー選択のイベントである。メニュー選択のイベントに対応するイベントハンドラはプレイリスト内の限られた期間でのみ有効である。つまり、プレイリストの情報として、個々のイベントハンドラの有効期間が設定されている。プログラムプロセッサ302は、リモコンの上下左右キーまたは決定キーが押された時に有効なイベントハンドラを検索して、有効なイベントハンドラがある場合は当該イベントハンドラが実行処理される。他の場合は、メニュー選択のイベントは無視されることになる。二つ目のユーザイベントは、メニューキーの操作によって生成されるメニュー画面呼び出しのイベントである。メニュー画面呼び出しのイベントが生成されると、グローバルイベントハンドラが呼ばれる。グローバルイベントハンドラはプレイリストに依存せず、常に有効なイベントハンドラである。この機能を使うことにより、DVDのメニューコールを実装することができる。メニューコールを実装することにより、タイトル再生中に音声、字幕メニューなどを呼び出し、音声または字幕を変更後に中断した地点からのタイトル再生を実行することができる。プレイリストで静的シナリオを構成する単位であるセルCellはVOBMPEGストリームの全部または一部の再生区間を参照したものである。セルはVOB内の再生区間を開始、終了時刻の情報として持っている。個々のVOBと一対になっているVOB管理情報VOBIは、その内部にタイムマップTimeMapまたはTMを有しており、このタイムマップによって前述したVOBの再生、終了時刻をVOB内即ち対象となるファイルYYY.VOB内での読み出し開始アドレス及び終了アドレスを導き出すことが可能である。なおタイムマップの詳細は図14を用いて後述する。VOBの詳細図9は、本実施の形態で使用するMPEGストリームVOBの構成を示す図である。図9に示すように、VOBは複数のVideoObjectUnitVOBUによって構成されている。VOBUは、MPEGビデオストリームにおけるGroupOfPicturesGOPを基準とする単位であり、音声データも含んだ多重化ストリームとしての一再生単位である。VOBUは0.4秒から1.0秒の再生時間を持ち、通常は0.5秒の再生時間を持っている。これはMPEGのGOPの構造が通常は15フレーム/秒NTSCの場合であることによって導かれるものである。VOBUは、その内部に映像データであるビデオパックV_PCKと、音声データであるオーディオパックA_PCKとを有している。各パックは1セクタで構成され、本実施の形態の場合は2kB単位で構成されている。図10は、MPEGストリームにおけるパックの構成を示す図である。図10に示すように、映像データ及び音声データといったエレメンタリデータは、ペイロードと呼ばれるパケットのデータ格納領域に先頭から順次入れられていく。ペイロードにはパケットヘッダが付けられ1つのパケットを構成する。パケットヘッダには、ペイロードに格納してあるデータがどのストリームのデータであるのかを示す情報、映像データであるのか音声データであるのかを示す情報、また、映像データまたは音声データがそれぞれ複数ストリームある場合は、どのストリームのデータなのかを識別するためのIDstream_id、および、当該ペイロードのデコード及び表示時刻情報であるタイムスタンプであるDecodeTimeStampDTS及びPresentationTimeStampPTSが記録されている。DTSおよびPTSは必ずしも全てのパケットヘッダに記録されている訳ではなく、MPEGによって記録するルールが規定されている。ルールの詳細についてはMPEGシステムISO/IEC13818-1規格書に記述されているので省略する。パケットには更にヘッダパックヘッダが付けられ、パックを構成する。パックヘッダには、当該パックがいつデマルチプレクサを通過し、個々のエレメンタリストリームのデコーダバッファに入力されるかを示すタイムスタンプであるSystemClockReferenceSCRが記録されている。VOBのインターリーブ記録図11及び図12を用いてVOBファイルのインターリーブ記録について説明する。図11は、AVデータとBD-ROMプレーヤの構成との関係を説明するための図である。図11上段の図は、図7を用いて前述したプレーヤ構成図の一部である。図の通り、BD-ROM上のデータは、光ピックアップを通してVOB即ちMPEGストリームであればトラックバッファ309へ入力され、PNG即ちイメージデータであればイメージメモリ308へと入力される。トラックバッファ309はFirst-InFirst-OutFIFOであり、入力されたVOBのデータは入力された順にデマルチプレクサ310へと送られる。この時、前述したSCRに従って個々のパックはトラックバッファ309から引き抜かれデマルチプレクサ310を介してビデオプロセッサ312またはサウンドプロセッサ313へとデータが送り届けられる。一方で、イメージデータの場合は、どのイメージを描画するかはプレゼンテーションコントローラ306図7参照によって指示される。また、描画に使ったイメージデータは、字幕用イメージデータの場合は同時にイメージメモリ308から削除されるが、メニュー用のイメージデータの場合は、イメージメモリ内にそのまま残される。これはメニューの描画はユーザ操作に依存するところがあるため、同一イメージを複数回描画する可能性があるためである。図11下段の図は、BD-ROM上でのVOBファイル及びPNGファイルのインターリーブ記録を示す図である。一般的にROM、例えばCD-ROMやDVD-ROMの場合、一連の連続再生単位となるAVデータは連続記録されている。連続記録されている限り、ドライブは順次データを読み出しプレーヤ側に送り届けるだけでよい。しかしながら、連続再生すべきAVデータが分断されてディスク上に離散配置されている場合は、個々の連続区間の間でシーク操作が入ることになり、この間データの読み出しが止まることになる。つまり、データの供給が止まる可能性がある。BD-ROMの場合も同様に、VOBファイルは連続領域に記録することができる方が望ましいが、例えば字幕データのようにVOBに記録されている映像データと同期して再生されるデータがあり、VOBファイルと同様に字幕データも何らかの方法によってBD-ROMから読み出す事が必要になる。字幕データの読み出し方法の一手段として、VOBの再生開始前に一まとめで字幕用のイメージデータPNGファイルを読み出してしまう方法がある。しかしながら、この場合には一時記録に使用する大量のメモリが必要となり、現実的ではない。そこで、本実施の形態では、VOBファイルを幾つかのブロックに分けて、VOBファイルとイメージデータとをインターリーブ記録する方式を使用する。図11下段はそのインターリーブ記録を説明するための図である。VOBファイルとイメージデータを適切にインターリーブ配置することで、前述したような大量の一時記録メモリ無しに、必要なタイミングでイメージデータをイメージメモリに格納することが可能になる。しかしながらイメージデータを読み出している際には、VOBデータの読み込みは当然のことながら停止することになる。図12は、上記のインターリーブ記録における問題を解決するトラックバッファ309を使ったVOBデータ連続供給モデルを説明するための図である。既に説明したように、VOBのデータは、一旦トラックバッファ309に蓄積される。トラックバッファ309へのデータ入力レートをトラックバッファ309からのデータ出力レートより高く設定すると、BD-ROMからデータを読み出し続けている限り、トラックバッファ309のデータ蓄積量は増加をしていくことになる。ここでトラックバッファ309への入力レートをVa、トラックバッファからの出力レートをVbとする。図12の上段の図に示すようにVOBの一連続記録領域が論理アドレスのa1からa2まで続くとする。また、a2からa3の間は、イメージデータが記録されていて、VOBデータの読み出しが行えない区間であるとする。図12の下段の図は、トラックバッファ309の蓄積量を示す図である。横軸が時間、縦軸がトラックバッファ309内部に蓄積されているデータ量を示している。時刻t1がVOBの一連続記録領域の開始点であるa1の読み出しを開始した時刻を示している。この時刻以降、トラックバッファ309にはレートVa-Vbでデータが蓄積されていくことになる。このレートは言うまでもなくトラックバッファの入出力レートの差である。時刻t2は一連続記録領域の終了点であるa2のデータを読み込む時刻である。即ち時刻t1からt2の間レートVa-Vbでトラックバッファ内はデータ量が増加していき、時刻t2でのデータ蓄積量はBt2は下記の式1によって求めることができる。Bt2=Va-Vb×t2-t1式1この後、BD-ROM上のアドレスa3まではイメージデータが続くため、トラックバッファへの入力は0となり、出力レートである-Vbでトラックバッファ内のデータ量は減少していくことになる。このデータ量の減少は読み出し位置a3まで、つまり、時刻でいうt3まで続く。ここで大事なことは、時刻t3より前にトラックバッファに蓄積されているデータ量が0になると、デコーダへ供給するVOBのデータが無くなってしまい、VOBの再生がストップしてしまうことである。しかしながら、時刻t3でトラックバッファにデータが残っている場合には、VOBの再生がストップすることなく連続して行われることを意味している。このVOBの再生がストップすることなく連続して行われるための条件は下記の式2によって示すことができる。Bt2≧-Vb×t3-t2式2即ち、式2を満たすようにイメージデータの配置を決めればよい事になる。ナビゲーションデータ構造図13から図19を用いて、BD-ROMに記録されたナビゲーションデータBD管理情報の構造について説明をする。図13は、VOB管理情報ファイルYYY.VOBIの内部構造を示す図である。VOB管理情報は、当該VOBのストリーム属性情報AttributeとタイムマップTMAPとを有している。ストリーム属性情報は、ビデオ属性Video、オーディオ属性Audio0~Audiom個々に持つ構成となっている。特にオーディオストリームの場合は、VOBが複数本のオーディオストリームを同時に持つことができることから、オーディオストリーム数Numberによって、オーディオ属性のデータフィールドの数が特定される。下記はビデオ属性Videoの持つフィールドとそれぞれが持ち得る値の例である。圧縮方式Coding:MPEG1MPEG2MPEG4解像度Resolution:1920x10801280x720720x480720x565アスペクト比Aspect:4:316:9フレームレートFramerate:6059.94503029.972524下記はオーディオ属性Audioの持つフィールドとそれぞれが持ち得る値の例である。圧縮方式Coding:AC3MPEG1MPEG2LPCMチャンネル数Ch:1~8言語属性Language:JPN、ENG、タイムマップTMAPはVOBU毎の情報を持つテーブルであって、当該VOBが有するVOBU数Numberと各VOBU情報VOBU1~VOBUnを持つ。個々のVOBU情報は、VOBUの再生時間長DurationとVOBUのデータサイズSizeとを有している。図14は、VOBU情報の詳細を説明するための図である。広く知られているように、MPEGストリームは時間的側面とデータサイズとしての側面との2つの物理量についての側面を有している。例えば、音声の圧縮規格であるAudioCodenumber3AC3は固定ビットレートでの圧縮を行っているため、時間とアドレスとの関係は1次式によって求めることができる。しかしながらMPEGビデオデータの場合、個々のフレームは固定の表示時間、例えばNTSCの場合、1フレームは1/29.97秒の表示時間を持つが、個々のフレームの圧縮後のデータサイズは絵の特性や圧縮に使ったピクチャタイプ、いわゆるI/P/Bピクチャによってデータサイズは大きく変わってくる。従って、MPEGビデオの場合は、時間とアドレスとの関係は一般式の形で表現することは不可能である。当然の事として、MPEGビデオデータを多重化しているMPEGストリーム、即ちVOBについても、時間とデータとを一般式の形で表現することは不可能である。これに代わって、VOB内での時間とアドレスとの関係を結びつけるのがタイムマップTMAPである。図14に示すように、VOBU毎にVOBU内のフレーム数と、VOBU内のパック数とをそれぞれエントリとして持つテーブルがタイムマップTMAPである。図15を使って、タイムマップTMAPの使い方を説明する。図15は、タイムマップを使ったアドレス情報取得方法を説明するための図である。図15に示すように時刻情報Timeが与えられた場合、まずは当該時刻がどのVOBUに属するのかを検索する。具体的には、タイムマップのVOBU毎のフレーム数を加算して行き、フレーム数の和が、当該時刻をフレーム数に換算した値を超えるまたは一致するVOBUが当該時刻に対応するVOBUになる。次に、タイムマップのVOBU毎のサイズを当該VOBUの直前のVOBUまで加算して行き、その値が与えられた時刻を含むフレームを再生するために読み出すべきパックの先頭アドレスAddressになっている。このようにして、MPEGストリームにおいて、与えられた時刻情報に対応するアドレスを得ることができる。次に図16を使って、プレイリストXXX.PLの内部構造を説明する。図16は、プレイリストの構成を示す図である。プレイリストは、セルリストCellListとイベントリストEventListとから構成されている。セルリストCellListは、プレイリスト内の再生セルシーケンスを示す情報であり、本リストの記述順でセルが再生される事になる。セルリストCellListの中身は、セルの数Numberと各セル情報Cell1~Cellnである。各セル情報Cell~Cellnは、VOBファイル名VOBName、当該VOB内での有効区間開始時刻In及び有効区間終了時刻Outと、字幕テーブルSubtitleTableを持っている。有効区間開始時刻In及び有効区間終了時刻Outは、それぞれ当該VOB内でのフレーム番号で表現され、前述したタイムマップTMAPを使うことによって再生に必要なVOBデータのアドレスを得る事ができる。字幕テーブルSubtitleTableは、当該VOBと同期再生される字幕情報を持つテーブルである。字幕は音声同様に複数の言語を持つことができ、字幕テーブルSubtitleTableは言語数Numberとそれに続く個々の言語ごとのテーブルLanguage1~Languagekとから構成されている。各言語のテーブルLanguage1~Languagekは、言語情報Languageと、表示される字幕の字幕情報数Numberと、表示される字幕の字幕情報Speech1~Speechjとから構成され、各字幕情報Speech1~Speechjは対応するイメージデータファイル名Name、字幕表示開始時刻In及び字幕表示終了時刻Outと、字幕の表示位置Positionとから構成されている。イベントリストEventListは、当該プレイリスト内で発生するイベントを定義したテーブルである。イベントリストは、イベント数Numberに続いて個々のイベントEvent1~Eventmとから構成され、各イベントEvent1~Eventmは、イベントの種類Type、イベントのIDID、イベント生成時刻Timeと有効期間Durationとから構成されている。図17は、個々のプレイリスト毎のイベントハンドラ時間イベントと、メニュー選択用のユーザイベントを持つイベントハンドラテーブルXXX.PROGの構成を示す図である。イベントハンドラテーブルは、定義されているイベントハンドラ/プログラム数Numberと個々のイベントハンドラ/プログラムProgram1~Programnを有している。各イベントハンドラ/プログラムProgram1~Programn内の記述は、イベントハンドラ開始の定義<event_handler>タグと前述したイベントのIDと対になるイベントハンドラのIDevent_handleridを持ち、その後に当該プログラムがfunctionに続く括弧{と}との間に記述される。次に図18を用いてBD-ROM全体に関する情報BD.INFOの内部構造について説明をする。図18は、BD-ROM全体情報であるBD.INFOの構成を示す図である。BD-ROM全体情報は、タイトルリストTitleListとグローバルイベント用のイベントリストEventListとから構成されている。タイトルリストTitleListは、ディスク内のタイトル数Numberと、これに続く各タイトル情報Title1~Titlenとから構成されている。各タイトル情報Title1~Titlenは、タイトルに含まれるプレイリストのテーブルPLTalbleとタイトル内のチャプターリストChapterListとを含んでいる。プレイリストのテーブルPLTableはタイトル内のプレイリストの数Numberと、プレイリスト名Name即ちプレイリストのファイル名を有している。チャプターリストChapterListは、当該タイトルに含まれるチャプター数Numberと各チャプター情報Chapter1~Chapternとから構成され、各チャプター情報Chapter1~Chapternは当該チャプターが含むセルのテーブルCellTableを持ち、セルのテーブルCellTableはセル数Numberと各セルのエントリ情報CellEntry1~CellEntrykとから構成されている。セルのエントリ情報CellEntry1~CellEntrykは当該セルを含むプレイリスト名と、プレイリスト内でのセル番号によって記述されている。イベントリストEventListは、グローバルイベントの数Numberと各グローバルイベントの情報Event1~Eventmとを持っている。ここで注意すべきは、最初に定義されるグローバルイベントは、ファーストイベントFirstEventと呼ばれ、BD-ROMがプレーヤに挿入された時、最初に実行されるイベントである。各グローバルイベントの情報Event1~EventmはイベントタイプTypeとイベントのIDIDだけを持っている。図19は、グローバルイベントハンドラテーブルBD.PROGの構成を示す図である。本テーブルは、図17で説明したイベントハンドラテーブルと同一内容であり、その説明は省略する。イベント発生のメカニズム図20から図22を使ってイベント発生のメカニズムについて説明する。図20は、タイムイベントの例を示す図である。前述したとおり、タイムイベントはプレイリストXXX.PLのイベントリストEventListで定義される。タイムイベントとして定義されているイベント、即ちイベントタイプTypeがTimeEventの場合、イベント生成時刻t1になった時点で、IDEx1を持つタイムイベントがシナリオプロセッサ305からプログラムプロセッサ302に対して出力される。プログラムプロセッサ302は、イベントIDEx1を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。例えば、本実施の形態の場合では、2つのボタンイメージの描画を行うことなどが可能である。図21は、ユーザのメニュー操作によるユーザイベントの例を示す図である。前述したとおり、メニュー操作によるユーザイベントもプレイリストXXX.PLのイベントリストEventListで定義される。ユーザイベントとして定義されるイベント、即ちイベントタイプTypeがUserEventの場合、イベント生成時刻t1になった時点で、当該ユーザイベントがレディとなる。この時、イベント自身は未だ生成されてはいない。当該イベントは、有効規格情報Durationで記される期間T1レディ状態にある。図21に示すように、ユーザによりリモコンキーの上下左右キーのいずれかのキー、または決定キーが押された場合、まずUOイベントがUOマネージャ303によって生成されプログラムプロセッサ302に出力される。プログラムプロセッサ302は、シナリオプロセッサ305に対してUOイベントを流し、シナリオプロセッサ305はUOイベントを受け取った時刻に有効なユーザイベントが存在するかを検索する。シナリオプロセッサ305は、検索の結果、対象となるユーザイベントがあった場合、ユーザイベントを生成し、プログラムプロセッサ302に出力する。プログラムプロセッサ302では、イベントID、例えば、図21に示す例の場合ではEv1を持つイベントハンドラを探し、対象のイベントハンドラを実行処理する。本例の場合、プレイリスト2の再生を開始する。生成されるユーザイベントには、どのリモコンキーがユーザによって押されたかの情報は含まれていない。選択されたリモコンキーの情報は、UOイベントによってプログラムプロセッサ302に伝えられ、仮想プレーヤが持つレジスタに記録保持される。イベントハンドラのプログラムは、このレジスタの値を調べ、分岐処理を実行することが可能である。図22は、グローバルイベントの例を示す図である。前述のように、グローバルイベントはBD-ROM全体情報BD.INFOのイベントリストEventListで定義される。グローバルイベントとして定義されるイベント、即ちイベントタイプTypeがGlobalEventであるイベントは、ユーザのリモコンキー操作があった場合にのみ生成される。ユーザによりメニューキーが押された場合、先ずUOイベントがUOマネージャ303によって生成されプログラムプロセッサ302に出力される。プログラムプロセッサ302は、シナリオプロセッサ305に対してUOイベントを流す。シナリオプロセッサ305は、該当するグローバルイベントを生成し、プログラムプロセッサ302に送る。プログラムプロセッサ302は、イベントIDmenuを持つイベントハンドラを探し、対象のイベントハンドラを実行する。例えば、図22に示す例の場合、プレイリスト3の再生を開始している。本実施の形態では、単にメニューキーと呼んでいるが、DVDを再生するプレーヤにおけるリモコンのように複数のメニューキーがあってもよい。各メニューキーに対応するIDをそれぞれ定義することで各メニューキーに対応する適切な処理が可能である。仮想プレーヤマシン図23は、プログラムプロセッサの機能的な構成を説明するための図である。図23を用いてプログラムプロセッサ302の機能的な構成を説明する。プログラムプロセッサ302は、内部に仮想プレーヤマシンを持つ処理モジュールである。仮想プレーヤマシンはBD-ROMとして定義された機能モデルであって、各BD-ROMプレーヤの実装には依存しないものである。即ち、どのBD-ROMプレーヤにおいても同様の機能を実行できることを保証している。仮想プレーヤマシンは大きく2つの機能を持っている。プログラミング関数とプレーヤ変数レジスタである。プログラミング関数は、Java登録商標Scriptをベースとして、以下に記す3つの機能をBD-ROM固有関数として定義している。リンク関数:現在の再生を停止し、指定するプレイリスト、セル、時刻からの再生を開始するLinkPL,Cell,timePL:プレイリスト名Cell:セル番号time:セル内での再生開始時刻PNG描画関数:指定PNGデータをイメージプレーンに描画するDrawFile,X,YFile:PNGファイル名X:X座標位置Y:Y座標位置イメージプレーンクリア関数:イメージプレーンの指定領域をクリアするClearX,Y,W,HX:X座標位置Y:Y座標位置W:X方向幅H:Y方向幅また、プレーヤ変数は、プレーヤの状態を示すシステムパラメータSPRMと、一般用途として使用可能なゼネラルパラメータGPRMとがある。図24は、システムパラメータSPRMの一覧を示す図である。SPRM0:言語コードSPRM1:音声ストリーム番号SPRM2:字幕ストリーム番号SPRM3:アングル番号SPRM4:タイトル番号SPRM5:チャプター番号SPRM6:プログラム番号SPRM7:セル番号SPRM8:選択キー情報SPRM9:ナビゲーションタイマーSPRM10:再生時刻情報SPRM11:カラオケ用ミキシングモードSPRM12:パレンタル用国情報SPRM13:パレンタルレベルSPRM14:プレーヤ設定値ビデオSPRM15:プレーヤ設定値オーディオSPRM16:音声ストリーム用言語コードSPRM17:音声ストリーム用言語コード拡張SPRM18:字幕ストリーム用言語コードSPRM19:字幕ストリーム用言語コード拡張SPRM20:プレーヤリージョンコードSPRM21:予備SPRM22:予備SPRM23:再生状態SPRM24:予備SPRM25:予備SPRM26:予備SPRM27:予備SPRM28:予備SPRM29:予備SPRM30:予備SPRM31:予備なお、本実施の形態では、仮想プレーヤのプログラミング関数をJava登録商標Scriptベースとしたが、Java登録商標Scriptではなく、UNIX登録商標OSなどで使われているB-Shellや、PerlScriptなど他のプログラミング関数であってもよい。言い換えれば、本発明における使用プログラム言語はJava登録商標Scriptに限定されるものでは無い。プログラムの例図25及び図26は、イベントハンドラにおけるプログラムの例を示す図である。図25は、2つの選択ボタンを持つメニュー画面の制御に係るイベントハンドラにおけるプログラムの例を示す図である。セルPlayList1.Cell1先頭でタイムイベントを使って図25左側のプログラムが実行される。ここでは、最初にゼネラルパラメータの一つGPRM0に1がセットされている。GPRM0は、当該プログラムの中で、選択されているボタンを識別するのに使っている。最初の状態では、左側に配置するボタン1が選択されている状態を初期値として持たされている。次に、PNGの描画を描画関数であるDrawを使ってボタン1、ボタン2それぞれについて行っている。ボタン1は、座標10、200を起点左上端としてPNGイメージ1black.pngを描画している。ボタン2は、座標330,200を起点左上端としてPNGイメージ2white.pngを描画している。また、本セル最後ではタイムイベントを使って図25右側のプログラムが実行される。ここでは、Link関数を使って当該セルの先頭から再度再生するように指定している。図26は、メニュー選択のユーザイベントに係るイベントハンドラにおけるプログラムの例を示す図である。左キー、右キー、決定キー何れかのリモコンキーが押された場合それぞれに対応するプログラムがイベントハンドラに書かれている。ユーザによりリモコンキーが押された場合、図21を用いて説明したように、ユーザイベントが生成され、図26のイベントハンドラが起動されることになる。本イベントハンドラでは、選択ボタンを識別しているGPRM0の値と、選択されたリモコンキーを識別するSPRM8を使って以下のように分岐処理を行っている。条件1ボタン1が選択されている、かつ、選択キーが右キーの場合GPRM0を2に再設定して、選択状態にあるボタンを右のボタン2に変更する。ボタン1、ボタン2のイメージをそれぞれ書き換える。条件2選択キーが決定OKの場合で、ボタン1が選択されている場合プレイリスト2の再生を開始する。条件3選択キーが決定OKの場合で、ボタン2が選択されている場合プレイリスト3の再生を開始する。図26に示すプログラムは、上記のように解釈され実行される。プレーヤ処理フロー図27から図30を用いてプレーヤでの処理の流れを説明する。図27は、BD-ROMプレーヤにおけるAVデータ再生の基本処理の流れを示すフロー図である。BD-ROMが挿入されるとS101、BD-ROMプレーヤはBD.INFOの読み込みと解析S102、および、BD.PROGの読み込みS103を実行する。BD.INFO及びBD.PROGは共に管理情報記録メモリ204に一旦格納され、シナリオプロセッサ305によって解析される。続いて、シナリオプロセッサ305は、BD.INFOファイル内のファーストイベントFirstEvent情報に従い、最初のイベントを生成するS104。生成されたファーストイベントは、プログラムプロセッサ302で受け取られ、当該イベントに対応するイベントハンドラを実行処理するS105。ファーストイベントに対応するイベントハンドラには、最初に再生するべきプレイリストを指定する情報が記録されていることが期待される。仮に、プレイリスト再生が指示されていない場合には、プレーヤは何も再生することなく、ユーザイベントを受け付けるのを待ち続けるだけになるS201でNo。UOマネージャ303は、ユーザからのリモコン操作を受け付けるとS201でYes、プログラムプロセッサ302に対するUOイベントを生成するS202。プログラムプロセッサ302は、UOイベントがメニューキーによるものであるかを判別しS203、メニューキーの場合S203でYesは、シナリオプロセッサ305にUOイベントを流し、シナリオプロセッサ305がユーザイベントを生成するS204。プログラムプロセッサ302は生成されたユーザイベントに対応するイベントハンドラを実行処理するS205。図28は、BD-ROMプレーヤにおけるプレイリスト再生開始からVOB再生終了までの処理の流れを示すフロー図である。前述したように、ファーストイベントハンドラまたはグローバルイベントハンドラによってプレイリスト再生が開始されるS301。シナリオプロセッサ305は、再生対象のプレイリスト再生に必要な情報として、プレイリストXXX.PLの読み込みと解析S302、および、プレイリストに対応するプログラム情報XXX.PROGの読み込みを行うS303。続いてシナリオプロセッサ305は、プレイリストに登録されているセル情報に基づいてセルの再生を開始するS304。セル再生は、シナリオプロセッサからプレゼンテーションコントローラ306に対して要求が出される事を意味し、プレゼンテーションコントローラ306はAVデータ再生を開始するS305。AVデータの再生が開始されると、プレゼンテーションコントローラ306は、再生するセルに対応するVOBの情報ファイルXXX.VOBIを読み込みS402、解析する。プレゼンテーションコントローラ306は、タイムマップを使って再生開始するVOBUとそのアドレスを特定し、ドライブコントローラ317に読み出しアドレスを指示する。ドライブコントローラ317は対象となるVOBデータYYY.VOBを読み出すS403。読み出されたVOBデータはデコーダに送られ再生が開始されるS404。VOB再生は、当該VOBの再生区間が終了するまで続けられS405、終了すると次のセルが存在する場合S406でYes、Cellの再生S304へ移行する。また、次のセルが無い場合S406でNoは、再生に係る処理が終了する。図29は、AVデータ再生開始後からのイベント処理の流れを示すフロー図である。図29Aは、BD-ROMプレーヤにおけるタイムイベントに係る処理の流れを示すフロー図である。なお、BD-ROMプレーヤはイベントドリブン型のプレーヤモデルである。プレイリストの再生を開始すると、タイムイベント系、ユーザイベント系、字幕表示系のイベント処理プロセスがそれぞれ起動され、平行してイベント処理を実行するようになる。BD-ROMプレーヤにおいてプレイリスト再生の再生が開始されるとS501、プレイリスト再生が終了していないことが確認されS502でNo、シナリオプロセッサ305は、タイムイベント発生時刻になったかを確認する。タイムイベント発生時刻になっている場合S503でYesには、シナリオプロセッサ305はタイムイベントを生成するS504。プログラムプロセッサ302はタイムイベントを受け取り、イベントハンドラを実行処理するS505。また、タイムイベント発生時刻になっていない場合S503でNo、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認S502以降の処理を繰り返す。また、プレイリスト再生が終了したことが確認されるとS502でYes、タイムイベント系の処理は強制的に終了する。図29Bは、BD-ROMプレーヤにおけるユーザイベントに係る処理の流れを示すフロー図である。BD-ROMプレーヤ1においてプレイリストの再生が開始されるとS601、プレイリスト再生が終了していないことが確認されS602でNo、UOマネージャ303は、UOの受け付けがあったかを確認する。UOの受け付けがあった場合S603でYes、UOマネージャ303はUOイベントを生成するS604。プログラムプロセッサ302はUOイベントを受け取り、そのUOイベントがメニューコールであるかを確認する。メニューコールであった場合S605でYes、プログラムプロセッサ302はシナリオプロセッサ305にイベントを生成させS607、プログラムプロセッサ302はイベントハンドラを実行処理するS608。また、UOイベントがメニューコールで無いと判断された場合S605でNo、UOイベントはカーソルキーまたは決定キーによるイベントである事を示している。この場合、現在時刻がユーザイベント有効期間内であるかをシナリオプロセッサ305が判断し、有効期間内である場合S606でYesには、シナリオプロセッサ305がユーザイベントを生成しS607、プログラムプロセッサ302が対象のイベントハンドラを実行処理するS608。また、UO受付が無い場合S603でNo、現在時刻がユーザイベント有効期間内にない場合S606でNo、および、イベントハンドラの実行処理が終了した場合、プレイリスト再生の終了確認S602以降の処理を繰り返す。また、プレイリスト再生が終了したことが確認されるとS602でYes、ユーザイベント系の処理は強制的に終了する。図30は、BD-ROMプレーヤにおける字幕データの処理の流れを示すフロー図である。BD-ROMプレーヤにおいてプレイリストの再生が開始されると、プレイリスト再生が終了していないことが確認されS702でNo、シナリオプロセッサ305は、字幕表示開始時刻になったかを確認する。字幕表示開始時刻になっている場合S703でYes、シナリオプロセッサ305はプレゼンテーションコントローラ306に字幕描画を指示し、プレゼンテーションコントローラ306はイメージプロセッサ311に字幕描画を指示する。イメージプロセッサ311は、その指示に従い字幕をイメージプレーン209に字幕を描画するS704。また、字幕表示開始時刻になっていない場合S703でNo、字幕表示終了時刻であるかを確認する。字幕表示終了時刻であると判断された場合S705でYes、プレゼンテーションコントローラ306がイメージプロセッサ311に字幕消去指示を行う。イメージプロセッサ311は、その指示に従い描画されている字幕をイメージプレーン209から消去するS706。また、イメージプロセッサ311による字幕描画S704が終了した場合、イメージプロセッサ311による字幕消去S706のが終了した場合、および、字幕表示終了時刻でないと判断S705でNoされた場合、プレイリスト再生の終了確認S702以降の処理を繰り返す。また、プレイリスト再生が終了したことが確認されるとS702でYes、字幕表示系の処理は強制的に終了する。以上の動作により、BD-ROMプレーヤは、ユーザの指示またはBD-ROMに記録されているBD管理情報等に基づき、BD-ROMの再生に係る基本的な処理を行う。実施の形態2次に本発明の実施の形態2について説明する。基本的には、実施の形態1に基づく内容であり、拡張した部分または異なる部分を中心に説明する。なお、実施の形態2では、実施の形態1に記載のデータ構造を基本のデータ構造として有するディスクを用い、本発明の特徴であるディスクメニューに関するデータ構造について説明を行う。また、このディスクに情報を記録し、記録した情報を編集する記録装置としてビデオカメラを想定し、ビデオカメラの構成および動作についても説明を行う。図31は、実施の形態2におけるディスクを使用するレコーダおよびプレーヤにおけるメニュー表示の例を示す図である。図31に示す、Recorder-AおよびRecorder-Bは、それぞれA社およびB社のレコーダである。また、各レコーダには、複数のコンテンツが記録されたディスクがセットされた状態である。図31の上段は、それぞれのレコーダが表示する機器メニューの例を示している。機器メニューとは、レコーダが、自機にセットされたディスクに記録されているタイトルの名前等を、自機の表示部または自機に接続された表示装置に表示することを目的とする簡易なメニューである。なお、タイトルとは、デジタルストリームの一部または全部である部分区間で構成されるAVコンテンツである。また、タイトルに関連するプレイリストにより、MPEGストリーム等のデジタルストリームにおける部分区間の位置と、再生順序とが指定されることで当該タイトルが特定される。例えば、ユーザが撮影した1つの映像コンテンツが1つのタイトルとしてディスクに記録される。図に示すように、Recorder-Aが表示する機器メニューは、ディスクに記録されているタイトルのサムネイルを複数並べて表示している。また、Recorder-Bが表示する機器メニューは、ディスクに記録されているコンテンツの記録日時をリスト形式で表示している。このようにサムネイル等を用いて機器が独自に生成したメニューを表示するのは以下の理由による。すなわち、記録/撮影の日付やサムネイルJPEGの表示は処理時間が少なくユーザレスポンスが良いこと、および、ビデオカメラのような小さい表示デバイスしか装備していない機器にて適切なメニュー表示を行うためである。これらレコーダは、機器メニューのほかに、ディスクメニューを生成し、ディスクに記録する機能を有している。図31の下段は、各レコーダが生成しディスクに記録したディスクメニューの例を示す図である。これらディスクメニューは各レコーダでは再生されず、当該ディスクを再生するプレーヤによって再生され、ユーザに提示される。ディスクメニューは、タイトルの一種であり、自身以外のタイトルをユーザに選択させるものである。また、このように、レコーダにより生成されディスク等の情報記録媒体に記録される。具体的には、実施の形態1で説明したBD.INFOやBD.PROGなどによって提供される機能によって構成されるメニューであって、TVに接続されたプレーヤにて再生されることを想定しているメニューである。そのため、大きな画面上に様々な情報を表示するように設計され、前述の機器メニューとは異なり、アニメーション効果や階層化された論理構成などを用いることもあり見た目も良い場合が多い。図に示すように、レコーダごとにディスクメニューのデザインが異なるため、同じような記録/撮影を行っても図の下段のように異なる表示方式デザインのディスクメニューが生成される。このように、A社のレコーダRecorder-AとB社のレコーダRecorder-Bでは、ディスクメニューが異なる。これは、ディスクメニューの実装はレコーダのメーカーごとに自由であるためである。そのため、レコーダやビデオカメラ等の機器において、他のメーカーの機器でディスクメニューが記録されたディスクがセットされた場合、このディスクメニューを解釈できないことにより、前述のように、ディスクメニューの削除に伴う処理時間の増加等の問題が発生する。この問題についての詳細は図34を用いて後述する。図32は、実施の形態2におけるBD.INFOの内容を示す図である。図に示すようにBD.INFOには、ディスクに記録されているタイトルを識別する情報群を格納する領域であるIndexが存在する。当該ディスクを再生するプレーヤは、このIndexに格納されている情報に基づき、タイトルの再生等を行う。なお、Indexに格納されている情報は、本発明の情報記録媒体におけるインデックス情報の一例である。また、Indexには、FirstPlayback、TopMenu、およびTitle1等のそれぞれのタイトルの再生を制御するプログラムの参照番号ProgramIDRefだけが記述されている。ProgramIDRefは、本発明の情報記録媒体におけるプログラム識別情報の一例であり、これらProgramIDRefにより、各プログラムが特定される。また、特定されたプログラムは、プレイリストを呼び出すことによりタイトルの再生を制御する。なお、FirstPlaybackとは、ディスク挿入時に最初に再生すべきタイトル等を意味しており、情報として、そのタイトルの再生のためのプログラムの参照番号が格納される。また、TopMenuとは、リモコンでメニューボタンが押された場合などに選択されるタイトルであるディスクメニューを意味しており、情報として、ディスクメニューの再生のためのプログラムの参照番号が格納される。また、図32に示すBD.INFO内のIndexに格納されている、FirstPlayback、TopMenu、およびTitle1等のそれぞれの名前は、本発明の情報記録媒体におけるタイトル識別情報の一例である。また、ユーザが撮影した映像コンテンツ等の、ディスクメニュー以外のタイトルのタイトル識別情報は、Titleタイトル番号という形式である。タイトル番号については後述する。具体的には、ディスクロード時に、FirstPlaybackに格納されているProgramIDRefに示される番号で指定されるプログラムが自動で実行される。また、ユーザがリモコンのメニューキーを押せばTopMenuに登録されているProgramIDRefの番号で指定されるプログラムが実行される。プレーヤの通常の動作としては、FirstPlaybackから参照されるプログラムに応じてディスクローディング時のオープニング映像を再生した後、もしくは一切何も表示せずにTopMenuにジャンプし、TopMenuにて規定されるディスクメニューを表示することになる。また、Title1~Titlenのそれぞれにはユーザが撮影および記録した映像コンテンツの再生を制御するプログラムを指定するProgramIDRefだけが登録される。図33は、実施の形態2におけるBD.PROGの内容を示す図である。BD.INFOにて参照されるProgramIDRefの番号はBD.PROGでのProgramの並び順である。図に示すように、例えば、Program1は何らかの処理を行った後、GPRM0の値が0であるかの条件判定を行い、その値に応じて、GPRM0=0であれば、111.PLを、GPRM0がGPRM3と同じであれば、GPRM0に2を加えた値の番号を持つPLの再生を行い、後続の処理を行うように記述されている。このようにBD.PROGに含まれるプログラムには、条件分岐if、プレーヤ変数の一種であるGPRMゼネラルパラメータを使った演算処理、および、プレイリストの再生命令PlayPlayListなどのコマンドを自由に組み合わせることができる。図34は、メニュー表示およびタイトル再生に係る表示および動作の遷移の一例を示す図である。具体的には、プレーヤにおいて、前述のBD.INFOおよびBD.PROGによりメニューが再生され、その後、ユーザの指示により、ユーザが記録した映像コンテンツであるタイトルを再生し、またメニューに戻る一連の処理をデータ構造の面から説明する図である。図34において、表示および動作の遷移は、TopMenuとして左下のディスクメニューがTVに表示されている所から始まる。このTopMenuにおいて、ユーザがリモコンを使って一番右のボタンButton3を選択し決定したことにより、TopMenuに関連するプレイリストである100.PLに指定されたストリーム100.VOBに多重化されているボタンプログラムButtonProgram3が実行される。ボタンプログラムButtonProgram3は、Title3の再生を意図するコマンドJumpTitle3が書かれており、そのコマンドが実行されることによってTitle3の再生に遷移する。具体的には、BD.INFOに記述されたTitle3に示されるProgramIDRefのフィールドの値がkであるために、BD.PROGのk番目のプログラムProgramkが実行される。プログラムProgramkには、プレイリスト200.PLの再生命令があるために200.PLの再生を行い、再生が終了した後で後続のコマンド処理が続けられる。プログラムProgramkの最後では、TopMenuに戻るコマンドJumpTopMenuが実行されるため元のTopMenuが再び表示される。以上がデータ構造から見たTopMenuとTitle再生の仕組みである。上記の表示および動作の遷移は、プレーヤが、ディスクメニューに関連するプレイリスト等の記述に沿って処理を行うことで実現され、ディスクメニューを生成したのがどのメーカーであるかによって問題が生じることはない。しかし、1つのディスクが、互いに異なるメーカーのビデオカメラ間を移動する場合を想定すると、ディスクメニューについて、ビデオカメラ側、つまり、ディスクメニューを生成しディスクに記録する記録装置側における互換性がないことが問題となる。すなわち、あるディスクにRecorder-Aだけが記録および編集を行う限りにおいては問題ない。しかし、Recorder-Aが記録を行ったディスクを、他メーカーの製品であるRecorder-Bにセットし、Recorder-B上で記録/編集を行う場合、Recorder-Aが生成したディスクメニューの設計ポリシーをRecorder-Bは特定することができない。そのため、ディスクメニューの既存部分を残しつつ、編集内容に応じた追加等をすることができないという問題がある。これは、図33に示すように、BD.PROGのProgramが再生状態に応じて変化するプレーヤ変数を使った条件分岐を行えるためである。つまり、上記問題は、所定のProgramだけを見てもどのように動作するのかは、他の要素との関連があり特定することが実装上不可能であるだけなく、Recorder-Aで生成されたディスクメニューに使っている素材背景やボタン映像の選択のポリシーもRecorder-Bには特定できないことに起因する。例えば、Title1を最初から最後まで再生したか否かをプレーヤ変数のGPRM100の値で管理しており、Title2の再生がTitle1を再生済みであれば途中から、そうでなければTitle2の先頭からの再生を行うようにプログラムされている場合を想定する。このような場合に、GPRM100がTitle1の再生経歴を示す情報であり、それがTitle2の再生を制御するように設計されており、これ以外の他の要素が影響しないことを検証するためには、全ての再生可能なパターンでの再生をシミュレートすることが必要になる。そのため、全てのBD.PROGのプログラムProgram、およびストリームに多重化された全てのボタンプログラムButtonProgramを取得し解析し、プレーヤ変数の設定の意味を特定していかなければならず、データの読み込みおよび解析に膨大な時間がかかると思われる。従って、ディスクメニューをRecorder-AからRecorder-Bに引き継ぐことは実質的に不可能である。そこで、Recorder-Aが生成しディスクに記録したディスクメニューは、Recorder-Bがそのディスクに対して記録および編集などを行う場合、ディスクメニューに関連する各種ファイルを全て削除し、一から作り直すことが、ディスク全体のデータの整合性を取る最も確実で簡易な方法である。また、既存のディスクメニューに関連する各種ファイルを削除せずに、新たなディスクメニューを生成することも考えられるが、この場合、不要なファイルがディスクに蓄積していくことになる。これにより、ディスクの記録可能容量が無駄に消費されるだけでなく、ディスクをロードする機器において、ファイル管理に係る処理負担が増加することになる。図35は、異なるメーカーのレコーダ間でディスクの移動があった場合のディスクメニューの更新におけるルールを示す図である。図35Aは、ディスクメニューの更新においてBD.INFO等の各ファイルをどのように扱うかを示す図であり、図35Bは、図35Aに示される番号の意味を説明する図である。例えば、Recorder-Aによりコンテンツが記録されたディスクに対しRecorder-Bがさらに記録および編集する場合、その編集によって追加または削除されたコンテンツをディスクメニューに反映しなければならない。このように、Recorder-Bが、Recorder-Aによりディスクメニューが記録されたディスクに対してコンテンツの記録および編集を行い、ディスクメニューを更新しなければならない場合、FirstPlaybackおよびTopMenuに関連する箇所の全てBD.INFOの該当部分、BD.PROGの該当部分、XXX.PLの全て、YYY.VOBIの全て、YYY.VOBの全てを変更する。なお、変更するとは、当該データを削除して新たなものを生成することも含む。以下の記載においても同様である。さらに、新しいFirstPlaybackおよびTopMenuと整合性がとれたTitleと、そのTitle用のProgramを規定しなおすために、Titleに関しても関連する箇所の全てBD.INFOの該当部分、BD.PROGの該当部分を変更する。逆に言えば、ディスクメニューの更新時にそのまま残るのは、ユーザが撮影した映像を格納している各Titleのプレイリスト以下だけとなる。また、上記の変更だけでメニュー更新が実現可能なように、Titleで使用するストリームYYY.VOBにはメニュー動作に影響するButtonProgramを含ませないことも重要である。このようなルールに従えば、異なるメーカーのレコーダ間でディスクを移動させた場合においても、ディスク全体のデータ整合性を維持しつつ、ディスクメニューを更新することができる。しかしながら、このルールによれば、FirstPlaybackおよびTopMenuが使用するプレイリストを特定する必要があるが、これは前述のように実質的に不可能である。そのため、ディスクメニューの更新時に、どのXXX.PLを削除すれば良いのかは分からないという問題が依然として残存する。そこで、図36に示すようにBD.INFOのExtensionに、以下のような情報を格納しておくことが有効である。図36は、BD.INFOのExtensionにプレイリストを特定するための情報を格納した状態を示す図である。Extensionは、BD.INFOの末尾に設けられた拡張領域であり、このように、規格に規定されていない情報を格納することができる領域である。また、Extensionからは、プレーヤは情報を読み出す義務がないため、規格に規定されていない情報を格納した場合であってもプレーヤに何らかの悪影響を与えることはない。なお、Extensionに格納されている情報は、本発明の情報記録媒体における拡張情報の一例である。以下に、Extensionに格納されている情報について説明を行う。1MakerInfoは、本発明の情報記録媒体における生産者識別情報の一例であり、メーカーを識別する識別子であるMakerIDと、このBD.INFOを記録した機器を特定する識別子ModelIDとを含む情報である。2DiscInfoは、このディスク上に記録可能な、もしくは既に記録されている映像のフレームレートを特定する情報であり、以下の各情報を含んでいる。IsNTSCは、29.97/59.94Hzのフレームレートの映像符号化を行って良いか、もしくはそれらのフレームレートの映像が既に記録されているかを示す情報である。IsPALは、25/50Hzのフレームレートの映像符号化を行って良いか、もしくはそれらのフレームレートの映像が既に記録されているかを示す情報である。IsFILMは23.97/24Hzのフレームレートの映像符号化を行って良いか、もしくはそれらのフレームレートの映像が既に記録されているかを示す。なお、IsNTSCとIsPALが1つのディスクに混在するのは一部のコンテンツが再生できない事態を招きうるため禁止される。因みにIsFILMはIsNTSCおよびIsPALのどちらとも共存が可能である。例えばレコーダは29.97/59.94Hzのフレームレートの映像符号化を行って記録する場合には事前にIsNTSC=1となっているかを確認して記録する。もしIsNTSC=0の場合には、IsPAL=0であるかを確認しIsNTSC=1と書き換えて記録する。もしくはIsNTSC=0かつIsPAL=1であってもディスク上に25/50Hzのフレームレートの映像がないことを確認した上で、IsNTSC=1およびIsPAL=0と書き換えて記録することができる。このようにすることで、ディスク上でのNTSC/PAL混在をストリームのフレームレートを全て調べることなく簡易に防ぐことが可能である。3FirstPlaybackは、BD.INFO内のIndexに含まれるFirstPlaybackにより指定されるプログラムから呼び出されるプレイリストの総数を示すPlayListNumberと、そのプレイリストの番号を示すPlayListIDとを含む情報である。なお、PlayListIDは、本発明の情報記録媒体におけるプレイリスト識別情報の一例である。4TopMenuは、BD.INFO内のIndexに含まれるTopMenuにより指定されるプログラムから呼び出される可能性のあるプレイリストの総数を示すPlayListNumberと、そのプレイリストの番号を示すPlayListIDとを含む情報である。5TitlePLPairNumberは、下記に示すTitlePLPairの総数を示す情報である。6TitlePLPairは、プレイリストの番号を示すPlayListIDと、そのプレイリストにより特定されるタイトルのタイトル番号TitlenとXXX.PLは1対1で使用することを想定を示すTitleIDとを含む情報である。タイトル番号とは、上述のように、タイトル識別情報であるTitlenのnの部分の数字である。つまり、タイトル番号はタイトル識別情報に対応する数字である。このように、BD.INFOの拡張領域であるExtensionに記述されたMakerInfoに示される情報によって、ビデオカメラ等のレコーダはこのディスクに記録されたメニューを生成したレコーダのメーカーを特定する情報と機器を特定する情報を得ることができる。ディスクがセットされたレコーダにおいて、仮に、自機がディスクメニューを記録したディスクであることが判明した場合、ディスクメニューFirstPlayback/TopMenuを一から作り直すことなく、特定の差分情報の更新だけを行えばよく、メニューの更新時間を短縮することが可能である。また、ディスクがセットされたレコーダは、MakerInfoに示される情報を参照することにより、他メーカーのレコーダでディスクメニューが記録されたディスクであるか否かの判定が可能であり、他メーカーのレコーダでディスクメニューが記録されたディスクであると判定した場合は、ディスクメニューを一からつくり直すことにより更新する。さらに、BD.INFOの拡張領域であるExtensionに記述されたFirstPlaybackに示される情報およびTopMenuに示される情報によって、ディスクメニューで使用されているプレイリストXXX.PLを容易に特定できる。そのため、そのプレイリストを解析することにより使用するYYY.VOBI、YYY.VOBを特定することができる。すなわち、ディスクメニューに関連するXXX.PL、YYY.VOBI、YYY.VOBファイルの全てを容易に特定でき、これらを削除することが可能となる。つまり、削除の対象となるタイトルに関連するプレイリスト、当該タイトルの管理情報、および、当該プレイリストに指定されるデジタルストリームの部分区間を削除することができる。このように、ディスクメニューに関連するプレイリストを容易に特定できる情報をディスクに記憶させておくことで、ディスクメニューに関連する各種ファイルを容易に特定でき、これらを削除した上でディスクメニューを新たに生成することができる。これにより、互いに異なるメーカーの機器間でディスクが移動した場合であっても、ディスクメニューに関連する各種ファイルを削除した上で、新たなディスクメニューを生成することができる。つまり、前述のような情報が記録された情報記録媒体は、いずれのメーカーの記録装置においても、不要な処理負荷や処理時間が発生させることなく、ディスク全体のデータの整合性を保ちながら、容易にディスクメニューを更新させることができる。次に、ディスクメニューの更新時のタイトル番号の保持について説明する。多くの公開文献や実施の形態1でも示されているように、DVD-VideoやBD-ROMのような情報記録媒体を再生するプレーヤではタイトルとチャプターという2つの階層を用いてユーザにコンテンツを提供している。一般的なプレーヤではタイトルサーチという機能が実装されている。ユーザは、この機能により、GUIGraphicalUserInterfaceのディスクメニューを経由せずに、直接リモコンの数字キーなどを使ってタイトル番号を指定し、そのタイトルから再生を開始することが可能である。なお、タイトル番号とは、BD.INFOのIndex部分にて表現されたTitleのループ順を意味しているため、タイトル1とは、ループ順で先頭のTitleを意味する。ここで、将来的には、ディスクのラベルにタイトル番号とそのコンテンツの内容を表すような情報記録日時や放送局のチャンネル、サムネイル映像などを印刷することもあると思われる。CD-DACompactDiscDigitalAudioのようなオーディオコンテンツを収録したディスクのラベルに、曲番号と曲名の組み合わせを印刷しているように、本発明の記録装置を利用するユーザにとってタイトルとそのコンテンツとの関連はタイトルサーチの機能が利用できる以上、とても重要である。ここで、あるコンテンツと、そのコンテンツに付されたタイトル番号との関係、つまり、あるコンテンツに関連するプレイリストと、そのプレイリストに関連付けられたタイトル番号との関係は、パッケージメディアReadOnlyMediaでは変更されることがないため、考える必要がない。しかし、情報の記録および編集が可能な情報記録媒体においては、あるメーカーのレコーダで生成されたディスクメニューが、他のメーカーのレコーダで更新される際に、上記のコンテンツとタイトル番号との関係は維持されない。そのため、例えば、ユーザが、上記のRecorder-Aで映像コンテンツを記録したディスクにおいて、タイトル番号が1であると認識していたコンテンツが、その後にRecorder-Bによりディスクメニューが更新されたために、不意にタイトル番号が3に変更される場合がある。もちろん、ディスクメニューの更新の前に、どのコンテンツ、つまりタイトルが、どのプレイリストと関連しているのか、つまり、どのプレイリストを参照しているのかを容易に知ることができるのであれば、その時点でコンテンツに付されているタイトル番号を取得し、更新の際に維持しておくことは可能である。しかし、どのタイトルがどのプレイリストと関連しているかを取得するためには、図32に示すTitle1Titlenに示される、BD.PROGに記録されている各Programを解析する必要があり、前述のように非常に困難である。従って、本実施の形態では、図36に示すようにBD.INFOのExtensionに、タイトル番号TitleIDとそのプレイリスト番号PlayListIDとを含む情報としてTitlePLPairを記述する。また、タイトル番号とそのプレイリスト番号とは順次追加記録される。つまり、TitlePLPairの中の記述順はそのプレイリストPlayListIDで特定されるプレイリストの記録日時順である。これによって、以前のタイトル番号とそのコンテンツつまり、プレイリストとの対応を崩さないようにメニューを更新することが可能となり、ユーザにとっては不意にタイトル番号とコンテンツの相関が変更されることを防ぐことができる。なお、あるディスクにおいて記録されていたタイトルが削除された場合には、タイトル番号がBD.INFOのIndex内のループ順であることから、削除したタイトルにダミーのプレイリストを付与してもよい。更に、そのコンテンツとしてDeletedTitleなどと既にそのタイトルに関連していたコンテンツが削除されたことをユーザに認識させるような映像等のコンテンツを、削除されたタイトルに関連するプレイリストに関連付ける。こうすることにより、他のタイトル番号に影響させないことができる。また、上記の削除されたことを示すコンテンツはタイトルサーチの操作においてのみ再生可能であって、ディスクメニューでは選択されないように実装される。図37は、実施の形態2における、ディスクメニューの更新前後のタイトルとプレイリストコンテンツとの相関の例を示す図である。あるディスクにおいて、ある時点で図37Aに示すように、ディスク上に3つのタイトルがあり、それぞれのタイトルが101.PL、102.PL、103.PLのプレイリストと関連付けられていると想定する。また、各プレイリストが上記の順番で、コンテンツA、B、Cに関連するものである場合を想定する。この想定下において、レコーダでTitle2を全削除し、新規にコンテンツDを記録した場合、図37Bに示すようにタイトルとプレイリストコンテンツの関係が一部変更される。具体的には、削除されたTitle2はBD.INFOのIndexから削除されることなくそのまま残され、Title2のプレイリスト102.PLが参照するAVストリームYYY.VOBが、Title2がユーザの編集操作によって削除されたことを示す映像や音声情報に置き換わる。また、Title1およびTitle3については、タイトル番号とプレイリストコンテンツとの関係は維持される。つまり、それらタイトルに付与されたタイトル番号に変更はない。また、新たに記録されたコンテンツDは図36に示すTitlePLPairの中で最後に追加される。つまり、TitlePLPairの中の記述順はそのプレイリストPlayListIDで特定されるプレイリストの記録日時順を示すことになるため、記録日時順でメニュー表示を行う場合に有用である。次に、図32、図33、および図36に示すデータ構造を有するディスクに対し、前述のようなメニューの更新や各種情報の操作を行うレコーダの構成および動作について以下に述べる。図38は、実施の形態2のレコーダの機能的な構成を示す機能ブロック図である。図38に示すレコーダ400は、本発明の記録装置の一例であり、例えば、映像をデジタルストリームとして記録するビデオカメラとして実現される。なお、レコーダ400は、デジタルストリームを記録する記録装置が本来有する、エンコーダ等の他の構成部を備えているが、本発明の特徴を明確にするために、それら他の構成部についての図示および説明は省略する。レコーダ400は、図38に示すようにプレイリスト特定部401、削除部402、メニュー生成部403、メーカー判定部404、受付部405、編集部406、番号読出部407、撮影部408、および表示部409を備える。また、情報記録媒体として、図32、図33、および図36に示すデータ構造を有するディスク105を使用する。プレイリスト特定部401は、ディスクメニュー等のタイトルの再生を制御するプログラムから呼び出されるプレイリスト、つまり、処理の対象とするタイトルに関連するプレイリストを図36に示すPlayListIDを用いて特定する処理部である。メニュー生成部403は、ディスク105に記録されているメニューに換えて、新たなメニューを生成しディスク105記録する処理部である。削除部402は、メニュー生成部403により新たなメニューが生成される場合、ディスク105に記録されているメニューに関連するプレイリストを削除する処理部である。なお、削除するプレイリストは、プレイリスト特定部401により特定される。メーカー判定部404は、図36に示すExtensionに含まれるMakerInfoに示されるメーカーが、レコーダ400を生産したメーカーと一致するか否かを判定する処理部である。受付部405は、ユーザまたはレコーダ400に接続された機器から入力される、レコーダに対する指示等を受け付ける処理部である。編集部406は、ディスク105に記録されているタイトルの編集を行う処理部である。番号読出部407は、Extensionに含まれるタイトル番号、つまり、TitleIDをディスク105から読み出す処理部である。撮影部408は、映像をデジタルストリームとしてディスク105に記録する処理部である。表示部409は、レコーダ400が備える小型の液晶デバイス等である。表示部409には、図31の上段に示す簡易な機器メニューが表示される。このように構成されたレコーダ400の基本的な動作の概要は以下のようになる。なお、レコーダ400を生産したメーカーとは異なるメーカーのレコーダにより生成されたディスクメニューがディスク105に既に記録されていると場合を想定する。このディスク105がレコーダ400にセットされると、プレイリスト特定部401は、ディスクに記録されているディスクメニューに関連するプレイリストを、Extensionに含まれる、TopMenuに対応付けられたPlayListIDを用いて特定する。メニュー生成部403は、新たなディスクメニューを生成しディスク105に記録する。また、削除部402は、プレイリスト特定部401により特定されたプレイリストをはじめ、他メーカーのレコーダにより生成されたディスクメニューに関連する各種ファイルを削除する。このようにして、レコーダ400は、他メーカーのレコーダにより生成されたディスクメニューを削除し、新たなディスクメニューをディスクに記録することができる。次に、レコーダ400がディスク105上のタイトル構成を更新する際の動作の流れを説明する。図39は、実施の形態2のレコーダ400における記録編集時のタイトル構成の更新時の動作の流れの概要を示すフロー図である。ユーザの指示等により、新たなタイトルの記録または既存のタイトルに対する編集が開始されるS801と、編集部406は、BD.INFOおよびBD.PROGをディスク105から読み込むS802。さらに、番号読出部407は、ディスク105に記録されているタイトル番号の最後の番号を取得する。具体的には、BD.INFOのIndexに含まれるTitle1から並んで存在するタイトル識別情報から最後のタイトル番号Tnを取得するS803。例えば、IndexにTitle1、Title2、Title3と存在する場合、3が取得される。その後、編集部406が、XXX.PL、YYY.VOBI、およびYYY.VOBを必要に応じて更新しS804、新規にタイトルを記録した場合、上記Tn以降の番号に、新規に記録したタイトルを割り振り、読み出したBD.INFOにその番号とタイトルとを記録するS805。例えば、Tn=3である場合、新たなタイトルが記録されると、そのタイトルにはタイトル番号4が付与される。この場合、編集部406により、BD.INFOのIndexにTitle4が追加され、更に、ExtensionにTitleIDである4と、Title4に関連するプレイリストのPlayListIDとが対応付けられて追加される。また、上記Tn以前のタイトル番号のタイトルで削除されたものがある場合、編集部406は、その削除されたタイトルのタイトル番号を削除するのではなく、そのタイトル番号に関連するプレイリストに示されるデジタルストリームの部分区間をタイトルが削除されたことを示す内容のダミーのデジタルストリームに置き換える。つまり、削除されたタイトルにダミーのデジタルストリームを付与するS806。ダミーのデジタルストリームとは、前述のように、DeletedTitle等の映像のデータ等である。この削除の際には、具体的には、プレイリスト特定部401が、削除されたタイトルのタイトル番号、つまりTitleIDと対応付けられているPlayListIDから、削除されたタイトルに関連するプレイリストを特定する。このような動作により、例えば、タイトル番号2のタイトルが削除された場合、タイトル番号2を削除するのではなく、タイトル番号2に、DeletedTitleと名付けられた映像等のデータが対応付けられる。このように、更新されたBD.INFOおよびBD.PROG等をディスク105に書き込むS807。以上により、一連の記録/編集に係る動作を終了する。上記のように、タイトル番号とそのコンテンツ関連するプレイリスト番号の関係を崩すことなくBD.INFOを更新することで、ディスクメニューではなく、タイトルサーチで直接コンテンツの再生を行うような場合であっても、ディスクメニューの更新の度にタイトル番号とコンテンツとの関係が変わることを防ぐことができ、ユーザの利便性を高めることができる。またこの際に、ディスクメニューでは削除したタイトルは選択できない一切表示されないように作りこむことで、GUIを使ったディスクメニューからコンテンツ再生を制御するユーザに対してもTitle2をダミーで残す悪影響を与えることがないようにすることができる。なお、本実施の形態において、図32等に示すデータ構造を有する情報記録媒体としてディスクを用いたが、情報を記録できる媒体であれば、BDおよびDVD等のディスクでなくてもよい。例えば、フラッシュメモリ等の半導体メモリでもよい。なお、FirstPlayback、TopMenuに関連するコンテンツVOBファイルが、Titleからも参照されている場合、ディスクメニューを削除すると、FirstPlaybackとTopMenuとして登録されたプレイリストとそのプレイリストから参照されるコンテンツVOBファイルとが削除され、タイトルの再生に支障をきたすこととなる。従って、これは禁止されるべきである。本実施の形態で言えば、BD.INFOのExtensionに記述されるFirstPlayback、TopMenuのプレイリストが参照するコンテンツXXX.VOBが、同じくBD.INFOのExtensionに記述されるTitleのプレイリストが参照することは禁止される。ディスクメニューFirstPlayback/TopMenuとそのディスクに記録されたタイトルが同じVOBを参照しないことが、迅速なディスクメニューの更新、つまりディスクメニューに関わるファイルの特定と削除のために必要である。なお、BD.INFO内のExtensionとして説明した情報が無い場合であっても、FirstPlayback、TopMenuが参照するプレイリストのファイル番号と、Titleが参照するプレイリストのファイル番号とを別個の範囲とすることでディスクメニューの更新のために、更新が必要なプレイリストファイルを迅速に特定することが可能である。また、プレイリストを削除する際、図36に示すTitlePLPairに含まれるPlayListIDから、当該プレイリストが他のタイトルにも関連していないか事前に検索し、関連していなければ削除するという対策を取ってもよい。実施の形態3次に本発明の実施の形態3について説明する。基本的には実施の形態1に基づく内容であり、拡張または異なる部分を中心に説明する。本発明の実施の形態1において、図18を用いてBD管理情報の1つで、ディスク全体の情報を管理するBD.INFOの例を説明したが、本実施の形態では図40の形式を取るものとする。BD.INFOはディスクに1つだけ存在し、当該ディスクが挿入された際に一番初めに解釈される。図40におけるBD.INFOは、AppInfoとTitleList、ExtensionDataからなり、AppInfoにはディスク全体に関する情報が格納される。なお、図40に示すTitleListおよびExtensionDataのそれぞれは、図36に示す、実施の形態2におけるIndexおよびExtensionに相当する情報領域である。TitleListには当該ディスクに格納されるTitleの情報が格納されており、FirstPlaybackとTopMenuという二つの特別なTitleと複数の通常のTitleからなる。通常のTitleの総数はTitleList以下のNumberに格納される。FirstPlaybackとTopMenuと各Titleは各々タイトル選択時に実行すべき後述するObjectへのリンク情報ObjectのIDを持っている。FirstPlaybackは、ディスク挿入時に一番最初に選択されるタイトルであり、TopMenuは、リモコンでメニューボタンが押された場合などに選択される再生メニュー用のタイトルである。次にObjectに関する情報を格納するBD.PROGについて図41を用いて説明する。Objectとは複数のナビゲーションコマンドからなるプログラム群であり、Objectを実行する際はナビゲーションコマンドを1つずつ逐次実行される。図41に示すようにBD.PROGは格納するObjectの総数を示すNumberおよび各Objectのエントリからなる。図中にある各Objectの添え字1などはObjectのIDであり、各ObjectはID順に並ぶものとする。前述のようにタイトルからはこのObjectIDを元にタイトル選択時に実行されるObjectが参照されている。各ObjectはObjectInfo領域とProgram領域とからなる。ObjectInfo領域にはObjectの設定情報が格納される。Program領域には当該Object実行時に逐次実行するナビゲーションコマンド群が格納される。なお、図41に示すBD.PROGは実施の形態1において図18を用いて説明したBD.PROGに変わるものであり、合わせて図17を用いて説明したXXX.PROGは廃止される。また、実施の形態1において説明したイベントに関しては、他の機能により代替される。例えば図20を用いて説明したタイムイベント及び図21を用いて説明したユーザイベントは、詳しくは後述するがストリーム中に埋め込まれるナビゲーションコマンドに相当するボタンにより代替される。また、図22を用いて説明したグローバルイベントは、リモコンキー操作毎にプレーヤの実行動作が規定されることとなる。例えば図22で説明したようにリモコンのMenuキーが押された場合、前述したBD.INFOで規定されるタイトルの1つであるTopMenuが自動選択されるよう規定されており、結果、TopMenuからリンクが張られたObjectが選択され、BD.PROG中の当該ObjectのProgram領域に格納されたコマンド群が実行されることになる。次に、本実施の形態におけるナビゲーション機能の1つであるボタンおよびページについて説明する。本発明の実施の形態1にて、図20~図21を用いてイベントを契機としたボタン描画の例を説明したが、BD-ROM規格に於いては、前述したDVDのNV_PCKと同じく、ナビゲーションコマンドをページ及びにボタンNV_DSとして、MPEG-TS形式のストリーム中にビデオエレメンタリストリームV_PESやオーディオエレメンタリストリームA_PESと一緒に埋め込むことができる。BD-ROMにおいて、インタラクティブを実現するナビゲーション機能をストリーム化し、映像、音声、字幕などのAVデータと共にストリームに多重化する構成について説明する。なお、本発明の実施の形態1では、BD-ROMDiscに記録するAVストリームをMPEG-PSに準じた形で説明していたが、本実施の形態ではAVストリームをMPEG-TS形式で実現する。本実施の形態におけるAVストリームを、図42を用いて説明する。図42に示すように、映像、音声、字幕そしてインタラクティブを実現するナビゲーションなどのエレメンタリストリーム図42の1は、それぞれPESストリーム化され図42の2、さらにそれぞれが一本のMPEG-TSに多重化される図42の3。なお、MPEG-TSにおける多重化も、多重化する個々のデータはそのデコード順に基づくビット列になっているが、多重化されるデータ間、即ち、映像、音声、字幕、ナビゲーションの間は必ずしも再生順、言い換えればデコード順に基づいてビット列が形成されているわけではない。MPEG-TSのデコーダモデル図42の4も多重化を解いた後に個々のエレメンタリストリームに対応するデコーダバッファを持ち、デコードタイミングまでに一時的にデータを蓄積している。次にBD-ROMにおけるページとボタンの具体的な内容を説明する。BD-ROMにおけるナビゲーション機能ではページとボタンの二つの概念を提供している。ページはボタンをグループ化して管理する単位であり、ボタンはユーザの操作に応じて実動作を行う単位である。具体的にディスプレイセットNV_DSとしてページがどの様な情報を持ちMPEG-TSに多重化されているのかを図43を用いて説明する。図43に示すように、ページは、自身のページIDと、ページ遷移時のアニメーション効果が設定されたアニメーション情報と、ページ内の描画パレットが設定されたパレット情報と、ページがonになった際に選択状態にするボタンのボタンIDが設定されたデフォルト選択ボタンIDと、ページがonになった際に実行するボタンのボタンIDが設定されたデフォルト実行ボタンIDと、当該ページに所属するボタン群の情報が設定された所属ボタン情報とがNV_DSに設定され、図42を用いて前述したようにMPEG-TSに多重化される。次に、ディスプレイセットとしてボタンがどの様な情報を持ちMPEG-TSに多重化されているのかを図44を用いて説明する。図44に示すように、ボタンは、自身のボタンIDと、自身の大きさやボタン画像として描画する内容等を示す領域情報と、ボタンが選択された際に自身に設定されたナビゲーションコマンドを自動実行するか否かを示す自動実行可否フラグと、自身が選択された状態でリモコンによるユーザ操作上下左右が発生した際にどのボタンに遷移するかが設定されたボタン遷移情報と、ボタンが選択されたり押下されたりするなどボタンの状態が変化した際に鳴らす効果音や実行するアニメーション効果などが設定された状態情報と、ボタンが押下されるなどボタンが有効になった際に実行するナビゲーションコマンド群が設定された実行コマンドとがNV_DSに設定され、図42を用いて前述したようにMPEG-TSに多重化される。以上、BD-ROMにおけるナビゲーション機能の1つであるページとボタンについて説明したが、前述したタイムイベント及びユーザイベントはこのページとボタンにより実現される。例えばタイムイベントは、ボタンをストリームの所望の位置に再生されるように埋め込み、前記自動実行可否フラグを設定しておくことで、ストリーム再生中に所定の時刻に前記ボタンに設定された実行コマンドが実行されることになる。また、ユーザイベントに関しても所望の動作を行うようにボタン遷移情報及び実行コマンドを設定したボタンをストリームに多重化しておくことで実現可能である。また、ページおよびボタンを活用することで、撮影した映像を再生する再生メニューなどインタラクティブなユーザインターフェースを実現出来る。例えば図45に示すように階層化されたメニューを実現する場合、トップメニューと二つのサブメニュー毎に各メニューに表示したいボタンを取りまとめるページを用意する。トップメニューではボタン1、2を取りまとめるページ1、サブメニュー1ではボタン3を表示するページ2、サブメニュー2ではボタン4,5を取りまとめるページ3を設け、前述したようにストリームに多重化する。トップメニューからサブメニューへの遷移はボタン1、2のようにメニュー遷移用のボタンを用意し、ボタン押下に合わせて切り替えるよう設定する。例えばボタン1はトップメニューからサブメニュー1への遷移を行うために、ボタン押下時にページ1をoffにし、ページ2をonにするナビゲーションコマンドが前記実行コマンド領域に設定されている。また、ボタン2でも同様にトップメニューからサブメニュー2への遷移を行うために、ボタン押下時にページ1をoffにし、ページ2をonにするナビゲーションコマンドが前記実行コマンド領域に設定されている。また、実行コマンド領域で指定可能なナビゲーションコマンドはページ遷移以外にも様々なナビゲーションコマンドを指定可能である。例えばボタン3のようにプレイリスト再生中にチャプターを切り替えるナビゲーションコマンドを設定したり、ボタン5のように表示する字幕ストリームを切り替えるナビゲーションコマンドを設定することもできる。ここで、ボタンの実行コマンド領域にはプレイリストの再生を開始させるナビゲーションコマンドは指定できない規定となっており、前述のObjectにおけるProgram領域でのみ指定できる。従って、ボタン4押下時にプレイリストXXX.PLを再生させたい場合、まず当該ボタンからプレイリストXXX.PLを再生させるナビゲーションコマンドが記述されたObject図中のObjectNへ遷移し、そのObjectから所望のプレイリスト図中ではXXX.PLを再生するナビゲーションコマンドを実行してもらう必要がある。以上説明したように、ページ及びボタンで再生メニューを作成する場合、ページ及びボタン以外にも、ボタンから遷移されボタンでは実行出来ないナビゲーションコマンドを実行してもらうためのObjectが必要となる。図40と図41とを用いてTitleとObjectとの関係を説明したが、Objectには前述のようにTitleから参照されるObjectだけではなく、ボタンから参照されるObjectが存在しうる。以上説明したように、ページとボタンとの組み合わせにより容易にインタラクティブなユーザインターフェースを実現可能である。なお、再生メニューなどのインタラクティブなユーザインターフェースにおけるGUI描画にBD-ROMのスライドショウ機能を活用することもできる。まず、図46を用いてV_PESにおけるスライドショウ機能について説明する。まず当該V_PESがスライドショウであるか否かは、例えば当該V_PESが含まれたAVデータのVOB管理情報ファイルVOBIにおいて設定されるものとする。上記スライドショウである旨を設定されたV_PESは、例えば全てIフレームIピクチャのみで構成されており、一枚のスライドショウとして表示される画面の静止画像がそれぞれIフレームとしてV_PESに埋め込まれる。同時に、各Iフレームの先頭毎にプレイリストにおいてチャプターイベントが設定される。また、各Iフレームの表示時間は無限大または固定時間が設定されており、設定された時間が経過するか、チャプタースキップまたはバックが実行されることで前の静止画に進んだり、前の静止画に戻ったりする。このようにIフレームとチャプターによりスライドショウ機能が実現される。ここで、図44を用いて前述したようにディスプレイセットNV_DSにおいてボタンの描画内容を記述可能であるが、描画情報を設定しないボタンも実現可能である。また、ボタンの実行コマンド領域を駆使して、チャプタースキップ、チャプターバックに相当するボタンも実現可能である。従って、ページとボタンとスライドショウ機能とを併用し、メニューのGUI描画をIフレームイメージとしてスライドショウに設定し、ユーザ操作によるメニュー遷移やナビゲーションコマンド実行などのメニュー制御をページ及びボタンに行わせることもできる。例えば図47を用いて説明すると、まず図47Aに示すようなメニューを構成する各メニュー画面イメージをIフレームイメージとしてV_PESに埋め込んでスライドショウを構成する。次に図47Bに示すようなメニュー画面の遷移や押下時の動作をページとボタン、そしてボタンから遷移されるObjectにより実現する。具体的にはサムネイルFの選択時にリモコンの右ボタンが押された場合など、メニュー画面を切り換える場合に対応するためには、チャプター変更に相当するナビゲーションコマンドをボタンに設定すればよい。また、サムネイルA押下時にサムネイルAに対応する動画を再生する場合には、ボタン押下時にサムネイルAに対応する動画を再生するためのObjectに遷移するようボタンを設定すればよい。以上説明したようにメニューはスライドショウとページ及びボタンを併用することでも実現可能であり、このようなメニューは図42を用いて前述したように1つのMPEG-TSに多重化される。再生メニューをBD-ROM形式で記録されたディスクに設定する方法について述べる。前述のようにBD.INFOにおけるTopMenuはメニュー専用のTitleであるため前述のメニューを実現するMPEG-TSはTopMenuタイトルが選択された際に自動実行される必要がある。従って、TopMenuから参照するObjectを作成してBD.PROGに登録し、当該ObjectのProgram領域には、前記メニューを実現するMPEG-TSを再生するプレイリストを再生させるナビゲーションコマンドを設定すればよい。また、ディスク挿入時に自動的に再生メニューが表示されるようにするには、FirstPlaybackから参照するObjectを作成してBD.PROGに登録し、当該ObjectのProgram領域には、TopMenuにタイトル遷移するナビゲーションコマンドを設定すればよい。ここで、他機器で既に映像を記録されたディスクに対し、自機器で新規に映像を追記したとする。この場合TopMenuから実行される再生メニューに、当然追記した映像のサムネイル並びに当該映像を再生させるナビゲーション情報を反映させる必要がある。しかしながら、再生メニューの構成は各社各様であり、TopMenuから参照されるObjectのProgram領域がどのようになっているか容易には判別出来ない。従って、一端再生メニューを削除し自機器で再生成することになる。しかし、この場合、実施の形態2で説明したように、再生メニューを削除するにあたって、BD.INFOで規定されているFirstPlayBackおよびTopMenuから参照されるObjectがどれであるかは解るが、そこから再生されるPlayList図47で説明した再生メニューを構成するMPEG-TSを再生するPlayListがどれかを判別するにはObjectのProgram領域を逐次解析していく必要がある。また、前述のように再生メニューのボタンからPlayListを再生するにはボタンからPlayList再生用のObjectに遷移し、そのObjectからPlayListを再生する必要がある。このようなボタンのみから参照されるObjectを識別するには、再生メニューを構成するMPEG-TSの多重化をほどき、ボタンのNV_DSを逐次解析していき、ボタンから遷移しているObjectのIDを逐次解析していく必要があり大変な手間となる。従って本実施の形態では、FirstPlaybackやTopMenuなどNV_DSを含むストリームを再生するTitleにおいて、NV_DSから遷移するObjectのIDをメタデータとして記録するものとする。また、当該メタデータは、図40におけるBD.INFOのExtensionDataに格納するものとする。本実施の形態におけるメタデータの例を図48に示す。図48に示すようにBD.INFOのExtensionData領域には、FirstPlaybackのメタデータを格納するFirstPlaybackMeta領域と、TopMenuのメタデータを格納するTopMenuMeta領域とが存在する。さらに、Title毎に各Titleの属性を示すTitleDomain領域と各Titleのメタデータを格納するTitleMeta領域とが存在する。TitleDomainは、Menu、Real、Virtaul、SlideShowの四つの属性Domainのいずれかを示す情報である。MenuDomainは、FirstPlayBackとTopMenuから遷移されたTitleなど、FirstPlaybackとTopMenu以外に、映像をユーザに選択させて再生する再生メニューやディスク挿入時の自動再生シーケンス制御などを実現するTitleが有する属性である。RealDomainは、実際に撮影または録画した映像をシーケンシャルに再生するだけのTitleが有する属性である。VirtualDomainは、撮影または録画した映像をユーザが編集した結果作成したプレイリストを再生するだけのTitleが有する属性である。SlideshowDomainはスライドショウを再生するTitleが有する属性である。FirstPlaybackMetaとTopMenuMetaとTitleMetaの構造は同一である。具体的には、FirstPlaybackとTopMenuと各Titleが参照するPlayListのファイル名一覧であるPLNameList領域と参照するObjectのIDの一覧であるObjectIDList領域からなる。なお、各TitleMetaにおいて、PlayListの記録順情報を持たせるため、PLNameList領域に記録されるPlayListのファイル名は当該PlayListの作成順であってもよい。以上、本実施の形態におけるメタデータの例を説明したが、本実施の形態のメタデータにより、各Titleが参照するObjectやObjectから再生されるストリームを解析することなく、各Titleで使用されるデータPlayList及びPlayListから参照されるデジタルストリームと、プログラム群であるObjectを識別することができる。特にFirstPlaybackMetaとTopMenuMetaと前記TitleDomainがMenuであるTitleのTitleMetaを解析することにより、当該ディスクにおける再生メニューを構成するデータPlayList及びPlayListから参照されるデジタルストリームと、プログラム群であるObjectを識別可能である。そのため、他機器が作成した再生メニューであっても容易に削除可能となる。特に再生メニューを実現するストリームにボタンNV_DSが含まれそのボタンからObjectが参照されている場合でも容易に識別可能であり、削除も容易となる。なお、例えばTopMenuから参照するObjectやPlayListが、任意のTitleAでも参照されている場合、本メタデータに基づいてTopMenuから参照されるObjectやPlayListを削除、編集するとTitleAの動作に支障が出る可能性がある。この場合、規格として、Title作成と同時に作成され当該Titleが参照しているObjectやPlayListに関しては、後から作成されたTitleが参照することを禁止してもよい。また、ObjectやPlayListを削除編集する際、図48を用いて説明したメタデータを元に、当該ObjectやPlayListが他のTitleからも参照されていないか事前に検索し、参照されていなければ削除するという対策を取ってもよい。また、PLNameList領域およびObjectIDList領域に、当該PlayListまたはObjectを参照しているTitleの逆参照情報を持たせるなどの対策を取ってもよい。以上、本発明の実施の形態3について説明したが、本実施の形態の記録方法およびデータ構造は、各Title配下のPlayList並びにObjectメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに本実施の形態の記録方法を実現する半導体に適用される。実施の形態4従来、ビデオカメラで撮影した映像などを逐次ディスクに記録する場合において、映像を次世代光ディスクの商用映像データ用のフォーマットであるBD-ROM形式で映像を記録した場合、映像の記録順序を保持する方法が存在しなかった。そこで、実施の形態4として、BD-ROMの拡張領域に記録するメタデータを記録順に配置し、かつ、編集による順序入れ替えを禁止する記録方法について説明する。この記録方法により、ビデオカメラで撮影した映像をBD-ROM形式で記録した場合においても、撮影した映像の撮影順を保持することが可能であり、再生メニュー等においてユーザの期待する順序で撮影した映像のサムネイルを並べることが出来る。なお、本実施の形態において、撮影した映像を記録するAVストリームは、実施の形態3と同じく、MPEG-TS形式のストリーム図42参照である。また、本実施の形態では、ビデオカメラや据置ビデオレコーダーなどに於いて、撮影または録画する映像をBD-ROM形式により記録する方法について述べる。まず撮影の単位とBD管理情報との対応関係について述べる。撮影した映像並びに音声はそれぞれV_PESならびにA_PESとして前述の図42に示すようにMPEG-TS形式のストリームに記録されていく。ここで撮影開始ボタンを押してからボタンを放す、または撮影停止ボタンを押すまでの撮影単位をShotと呼ぶこととすると、1つのshotは、一本のストリームとして記録してもよいし、一本のストリームに複数のShotを格納してもよい。ここでShotは各Shot毎または撮影日などのグループ単位毎に前述したプレイリストPlayListに関連づけられる。そして最終的には各PlayList単体またはPlayList単位で、前述のBD管理情報であるBD.INFOで管理されるTitleに関連づけられる。図16においてプレイリストXXX.PLの詳細について述べたが、本実施の形態で述べるビデオカメラなどで撮影したストリームにおいては、必ず撮影の単位であるShot毎にプレイリストで管理するEVENTMarkを付けるものとする。以前述べたように、撮影の単位であるShotは、プレイリストのMarkに一対一対応することとなる。従って、Shotの撮影日時やShotのサムネイル等のShotに関連するデータの管理もMark単位で行うことにより、Shotと、Shotと関連するデータとの対応関係が明確になり、参照や管理が容易になる。以上、撮影の単位であるShotとBD管理情報におけるMarkとの対応関係について述べたが、そもそもBD-ROM形式は予め編集された映画などを記録し配布する用途に用いるものである。そのため、例えば前述のShotの撮影日時やそのサムネイル等、撮影した映像を記録する場合にBD管理情報では記録できない情報がいくつか存在する。従って本実施の形態では、これらBD管理情報では記録出来ない情報を、メタデータとして別途管理するものとする。メタデータ格納場所としては、BD管理情報とは別のファイルに格納するものとしてもよいし、BD管理情報の各拡張領域に格納するものとしてもよい。BD管理情報の拡張領域とは、実施の形態2で説明したExtensionに相当する領域のことである。例えば、図18においてBD-ROM形式で記録されたディスクが挿入された際にBD-Playerが最初に読み出すBD管理情報であるBD.INFOの詳細について述べたが、図18を用いて説明した構造に加えてデータの末尾に拡張領域としてIndexExtensionDataを持つ。従って、本実施の形態では、前記BD-ROMで規定出来ない情報をこのIndexExtensionDataにて規定するものとする。なお、説明するまでもないが、PlayListやVOB管理情報ファイルClipInformationの拡張領域に分散してメタデータを格納してもよい。本実施の形態で規定するIndexExtensionDataの例を図49に示す。図49は本実施の形態にて規定するメタデータをBD.INFOの拡張領域であるIndexExtensionDataに格納した場合の例を示す図である。なお、本実施の形態はこれに限定するものではなく、例えば、BD.INFOとは別のファイルに図49に示す構造ならびにデータを持ったメタデータを記録して持たせてもよいし、図49に示すメタデータを、BD管理情報の各ファイルに分散させて持たせてもよい。まず、前述したBD管理情報BD.INFOの末尾にあるIndexExtensionDataに、DiscInfo領域とPLTable領域の二つの領域を持たせる。DiscInfo領域はディスク全体に関するメタデータを格納するための領域であり、例としてDiscタイトルにはディスクのタイトル情報を格納し、Discサムネイルには、ディスクを代表するサムネイル画像に関する情報を格納する。PLTable領域はBD管理情報の1つであるPlayListに関するメタデータをPlayList毎に格納する領域であり、PL_Number領域と各PlayListのメタデータ領域図中のPL1~PLmとからなる。PL_NumberとプレイリストXXX.PLのファイル総数とは同数となり、以降各PlayListプレイリストXXX.PL毎のメタデータがPL1から順に格納される。各PlayListのメタデータは、例としてPL_FileName領域とPL_Type領域、PL作成日時領域、PLタイトル領域、MarkTable領域の5つの領域からなる。PL_FileName領域は、当該メタデータ領域PL1~PLmがどのPlayListのメタデータを格納しているかを示す情報であり、例えばPlayListファイルXXX.PLのファイルボディXXXが格納される。また、PL_Type領域には、当該PlayListの種別が格納される。BD-ROMにおいては映像は全て予めオーサリングされているためPlayListに種別を設ける必要がないが、撮影または録画する映像をBD-ROM形式で記録する場合は大きく二つに大別される。まず1つ目は撮影または録画したオリジナルの映像を一から再生するシナリオが記録されるPlayListであり、以降本実施の形態ではRealPlayListと呼ぶ。もう一つは、ユーザがオリジナルの映像に対して再生順序の入れ替えや再生箇所の指定などの編集を行ったシナリオが記録されるPlayListであり、以降本実施の形態ではVirtualPlayListと呼ぶ。ここで、撮影または録画した映像の単位であるShotとRealPlayList、VirtualPlayListとの対応関係を図50に示す。図50に示すように、RealPlayListは撮影したShotが格納されたストリームを撮影順に再生するものであり、基本的にストリームが記録される際にストリーム情報と共に生成される。また、RealPlayListは、例えばShotの撮影後に追加または修正されていく。一方、VirtualPlayListはユーザによる映像編集の結果として記録した映像の一部を所望の順序で再生するためのものであり、ユーザの編集処理時に作成される。このように撮影または録画したストリームは複数のPlayListから参照される可能性がある。このためあるPlayListを削除する際に当該PlayListが参照するストリームも同時に削除すると、存在しないストリームを参照するPlayListが出来てしまう可能性がある。従って、あるストリームは、必ず1つのRealPlayListからは参照されるため、VirtualPlayList削除時は参照するストリーム及びストリーム情報は削除せず、RealPlayList削除時は参照するストリーム及びストリーム情報を削除し、当該ストリームを参照するVirtualPlayListを修正するものとしてもよい。以上、RealPlayListとVirtualPlayListについて説明したが、これらの識別情報を前記PL_Typeに格納するものとする。なお、メニュー用ストリームがどのストリームであるかを容易に判別するため、メニュー用ストリームを参照するPlayListであることを前記PL_Typeに持たせてもよいし、後述するMark用のメタデータやストリーム情報のメタデータに持たせてもよい。また、図34の説明の中で述べたプログラムが多重化されたストリームInteractiveGraphicsIGStreamを参照するPlayListであることを前記PL_Typeに持たせてもよいし、後述するMark用のメタデータやストリーム情報のメタデータに持たせてもよい。例えば、スライドショウを実現するPlayListである場合、当該ストリームは、ページ送りやページ戻り用のボタン及びボタンコマンドIGStreamをストリーム中に含む場合もあり得る。この場合例えば、ある機器でスライドショウを作成した後、別の機器で当該スライドショウを変更する場合に、単純に編集してもよいのか、それともIGStreamを含んでおりそれを考慮した上で編集する必要があるのかを判断することが出来る。例えばIGStreamを含んだRealPlayListであることが前記PL_Typeに指定された識別子で判明した場合、当該機器はまずIGStreamを検出していき、検出したIGStreamを全て削除した上で、スライドショウを編集することが可能となる。なお、図示していないが、あるディスクがどの機器で記録されたディスクであるのかどうかという情報を、例えば本実施の形態のメタデータにおけるDiscInfoに持たせてもよい。これにより、記録装置は前記IGStreamを含むストリームは当該機器で作成されたものかどうかを判別することが可能である。例えば、前記PL_TypeによりIGStreamを含むPlayListであることが判別された場合、当該機器で作成したものである場合は直接修正してもよい。以下、図49の説明を続行する。PL作成日時領域には当該PlayListを作成した日時を記録する。PLタイトル領域にはPlayListのタイトル名を記録する。MarkTable領域は当該PlayListメタデータが参照するPlayListが管理する各Markのメタデータを格納する領域であり、Mark_Number領域と各Markのメタデータ領域図中のMark1~Marknからなる。図49に示す例ではMark_Numberと当該PlayListが管理するMarkの数とが同数となり、以降当該PlayListが管理する順番に従って、Mark毎のメタデータがMark1から順に格納される。なお、本実施の形態ではPlayListが管理するMarkとメタデータで管理するMarkとか一対一対応するものとして記述するが、これに限るものではない。例えば、再生を一時停止した地点を示すMarkなどBD管理情報では規定出来ないMarkをメタデータでのみ管理してもよい。この場合、例えば図49に示すMarkのメタデータ領域にBD管理情報で規定するMarkを参照しているのか否かを示す情報と、参照している場合はそのMarkのIDを、参照していない場合はメタデータで管理するMarkが指すストリームの位置情報を格納する領域を別途設ける必要がある。各Markのメタデータは、例としてMark_Type領域、サムネイル領域、撮影日時領域、およびPL参照情報領域の4つの領域からなる。Mark_Type領域は当該PlayListで管理するMarkの種別を記録するものであり、本実施の形態では当該MarkがShotの先頭を示すMarkShot-Markであるか否かを示す。この場合、Markの機能の性質上、Shotの先頭を示すMarkを管理するのは前述のRealPlayListのみとなる。また、本実施の形態では当該PlayListを代表するサムネイルにあたるストリーム位置をMarkとして管理するものとする。具体的には、Mark_Type領域にて、当該MarkがPlayListの代表サムネイルを示すMarkPL-Markなのか否かを識別する情報も持たせるものとする。その他、ユーザが付加するBookMarkであるか否かなどを規定してもよい。次にサムネイル領域は当該Markの指すストリーム位置における画像をサムネイルとして指定する。なお、当該MarkがShotの先頭を示すMarkである場合、基本はShotの先頭の画像がサムネイルとして設定される。しかしShotを代表するサムネイルを参照させるために、当該Markが指すストリーム位置の画像ではなく、ユーザの設定や自動判別などにより抽出した、当該Markが指すストリーム位置とは別の位置の画像を代表サムネイルとしてもよい。撮影日時領域は、当該MarkがShotの先頭を示すMarkである場合、当該Shotの撮影日時を記録する。PL参照情報領域は、当該MarkがShotの先頭を示すMarkである場合のみ設定されるものとし、当該Shotを参照するPlayListの参照情報を格納するものとする。このPL参照情報は、前述したように当該ShotまたはShotを含むストリームが削除された際に、当該Shotを参照しており削除時に修正の必要があるPlayListを容易に検索するために付加するものである。なお、前述のようにShotと当該Shotを管理するRealPlayListとは、一方が削除された際に自動的にもう一方も削除される関係にある。従って、PL参照情報領域に格納する参照情報はVirtualPlayListに対する参照情報のみ格納するものとしてもよい。なお、RealPlayListの編集削除時に更新されるべきVirtualPlayListを効率良く特定するために、RealPlayListとVirtualPlayListのプレイリストファイル番号を予め別個に定義しておくことも考えられる。こうすることで、RealPlayList編集時に内容を確認するべきプレイリストファイルを瞬時に特定することができる。この場合、BD.INFOのExtensionのような特別な情報は必要がない。以上、本実施の形態におけるメタデータの種類とその格納方法について説明したが、Shotを一覧メニューとして表示する際、撮影録画順にそのサムネイルを表示することで、Shotの相関関係が掴みやすくユーザの利便性を向上することができる。本実施の形態ではこのような撮影録画順のソートならびにメニュー表示を容易とするため、図49で示したメタデータにおいて、PlayListのメタデータ図中PL1~PLmを格納する順番を記録順に格納するものとする。基本的にはPlayListのメタデータの格納位置は編集等でも変更しないものとする。また図51に示すように、RealPlayListにおいて、Shotの先頭を示すMarkは、PlayListにおけるMarkの付加順ならびに当該Markのメタデータの記録順も撮影順に並ぶものとし、当該順序は削除を除き編集等で入れ替えないものとする。以上により、RealPlayListのメタデータの格納順と、当該RealPlayListが管理するMarkにおいてShotの先頭を示すMarkのメタデータの格納順とにより、当該ディスクに記録されたShotの撮影録画順序を識別することが可能となる。以上により、Shotの撮影順にサムネイルや撮影日時等を一覧表示した再生メニューを生成する場合は、図49に示すメタデータを参照するだけでよい。また、PL_TypeがRealPlayListであるPlayListのメタデータを順次解析し、当該PlayListのメタデータにおいて、Mark_Type=Shot-Mark当該MarkがShotの先頭を示すであるMarkのメタデータを順次参照しメニュー表示すればよい。例えば本実施の形態のメタデータが図52Aに簡易的に示す状態である場合を想定する。この場合、PlayList1、2、4はRealPlayListであり、PlayList3はVirtualPlayListである。従って、PlayListの記録順は、PlayList1、2、4の順になる。また、図中において、Shotが付されたMarkは、Shotの先頭を示すMarkを表している。従って、各PlayListの中でShotの先頭を示すMarkの記録順を抽出すると、Shotの記録順がPlayList1のMark1,3、PlayList2のMark1、PlayList4のMark1,2の順であることが分かる。このようにして、最終的にShotの一覧メニューを図52Bのように表示することが出来る。なお、RealPlayList及びVirtualPlayListの作成順も前記メタデータの格納順序により識別することも可能である。また、各PlayListが管理するMarkにおいて、Mark_TypeがPlayListの代表サムネイルを示すMarkPL-Markを検索することで、必要があればPlayListのサムネイルを作成順に一覧表示したメニューも作成可能である。以上、実施の形態4について説明したが、実施の形態4の記録方法およびデータ構造は、撮影または録画した映像をBD-ROM形式で記録する場合に、映像の記録順序を保持するようにメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに実施の形態4の記録方法を実現する半導体に適用される。実施の形態5従来、ビデオカメラで撮影した映像などを逐次ディスクに記録する場合において、映像を次世代光ディスクの商用映像データ用のフォーマットであるBD-ROM形式で映像を記録した場合、映像の撮影日時を保持する方法が存在しなかった。そこで、実施の形態5として、撮影した映像毎の撮影日時情報をBD-ROMの拡張領域にメタデータとして記録する記録方法について説明する。この記録方法により、ビデオカメラで撮影した映像をBD-ROM形式で記録した場合においても、撮影した映像の撮影日時を保持することが可能であり、ユーザに対して撮影した映像の撮影日時を適切な形で提示することができる。なお、本実施の形態において、撮影した映像を記録するAVストリームは、実施の形態3と同じく、MPEG-TS形式のストリーム図42参照である。また、本実施の形態では、ビデオカメラや据置ビデオレコーダーなどに於いて、撮影または録画する映像をBD-ROM形式により情報記録媒体に記録する方法について述べる。なお、本実施の形態では情報記録媒体の例として次世代ディスクであるBD-ROMDiscを例に挙げているが、これに限られることはない。例えば、本実施の形態におけるアプリケーション及びデータ構造をDVDなどの光ディスクや他の情報記録媒体である、メモリーカードSDメモリーカードやメモリースティックなどやハードディスクなどに書き込む場合でも同様の効果を得る。また、情報記録媒体ではなく、本実施の形態におけるアプリケーション及びデータ構造をネットワークを介して配布する場合においても同様の効果を得る。撮影の単位とBD管理情報との対応関係は、実施の形態4と同じである。すなわち、撮影した映像並びに音声はそれぞれV_PESならびにA_PESとして前述の図42に示すようにMPEG-TS形式のストリームに記録されていく。ここで撮影開始ボタンを押してからボタンを放す、または撮影停止ボタンを押すまでなど、ユーザが撮影または録画した映像の単位撮影単位をShotと呼ぶこととすると、1つのshotは、一本のストリームとして記録してもよいし、一本のストリームに複数のShotを格納してもよい。詳しくは後述するが、Shotは、Shot毎または撮影日などのグループ単位毎に前述したプレイリストPlayListに関連づけて管理されるものとし、各Shotの先頭には当該プレイリストにて管理するEventが設定されるものとする。本発明の実施の形態1において、図18を用いてBD管理情報の1つで、ディスク全体の情報を管理するBD.INFOの例を説明したが、本実施の形態では図53の形式を取るものとする。図53に示すBD.INFOはディスクに1つだけ存在し、当該ディスクが挿入された際に一番初めに解釈される。図53に示すBD.INFOは、AppInfoとTitleList、ExtensionDataからなり、AppInfoにはディスク全体に関する情報が格納される。TitleListには当該ディスクに格納されるタイトルの情報が格納されており、FirstPlaybackとTopMenuという二つの特別なタイトルと複数の通常のタイトルとからなる。通常のタイトルの総数はTitleList以下のNumberに格納される。FirstPlaybackとTopMenuと各Titleは、それぞれタイトル選択時に実行すべき後述するObjectへのリンク情報ObjectのIDを持っている。FirstPlaybackは、ディスク挿入時に一番最初に選択されるタイトルであり、TopMenuは、リモコンでメニューボタンが押された場合などに選択される再生メニュー用のタイトルである。なお、本実施の形態において、Objectに関する情報を格納するBD.PROGのデータ構造は、実施の形態図3で説明した図41に示すBD.PROGのデータ構造と同じである。なお、図41に示すBD.PROGは実施の形態1において図18を用いて説明したBD.PROGに変わるものであり、合わせて図17を用いて説明したXXX.PROGは廃止される。以上、本実施の形態におけるBD管理情報について述べたが、前記Shotを管理するプレイリストは、各プレイリスト単位で、前述のBD管理情報であるBD.INFOで管理されるTitleに関連づけられる。具体的には、Titleが参照するObjectにおいて、当該Titleに対応するプレイリストを再生するナビゲーションコマンドが記述される。また、図16においてプレイリストXXX.PLの詳細を説明したが、プレイリストにて管理するイベントは、以後Markと呼ぶことにする。Markは前述の通り、当該プレイリスト内で生成されるイベントMarkを定義したものであり、プレイリストでは複数のMarkをIDで管理している。また、各MarkはMarkの種別Mark_Type、MarkのIDMark_ID、イベントMarkの生成時刻時刻Timeと有効期間Durationから構成されている。ここでMarkの種別であるMark_Typeには、EntryMarkとLinkPointの二つの種別がある。EntryMarkはChapterとしてユーザが識別可能であるMarkであり、プレイリストの先頭から何番目のEntryMarkであるかをユーザに提示することでChapter番号を提示可能である。またリモコン操作により再生するチャプターを前後のチャプターに切り替えることも可能である。LinkPointは、ユーザは識別できないMarkであり、前述のようなChapterとしては識別されず、プログラムからの再生位置指定など主にプログラムにて識別する再生時刻情報として用いられる。以上Markについて説明したが、本実施の形態で述べるビデオカメラなどで撮影または録画した映像を管理するプレイリストにおいては、撮影の単位であるShot毎にそのShotの先頭にあたる再生時刻に対して必ず当該プレイリストにて管理するEntryMarkを設定するものとする。これにより、撮影の単位であるShotはプレイリストのEntryMarkに一対一対応することとなる。これによりユーザは撮影したShotをChapterとして識別可能となり、Chapter切替操作により再生するShotを選択することも可能となる。また、本実施の形態ではShotの撮影日時やShotのサムネイル等のShotに関連する情報の管理もEntryMark単位で行うこととする。これにより、Shotと、Shotと関連するデータとの対応関係が明確になり、参照や管理が容易になる。以上、撮影の単位であるShotとBD管理情報におけるMarkとの対応関係について述べたが、そもそもBD-ROM形式は予め編集された映画などを記録し配布する用途に用いるため、例えば前述のShotの撮影日時やそのサムネイル等、撮影した映像を記録する場合にBD管理情報では記録できない情報がいくつか存在する。従って本実施の形態では、これらBD管理情報では記録出来ない情報を、メタデータとして別途管理するものとする。メタデータ格納場所としては、BD管理情報とは別のファイルに格納するものとしてもよいし、BD管理情報の各拡張領域に格納するものとしてもよい。BD管理情報の拡張領域とは、実施の形態2で説明したExtensionに相当する領域のことである。本実施の形態においては、BD.INFOは図53に示すようにデータの末尾に拡張領域としてIndexExtensionDataを持つ。また、各プレイリスト情報を格納するXXX.PLの詳細について図16を用いて説明したが、プレイリストXXX.PLにおいても図16を用いて説明した構造に加えて、図54に示すように、データの末尾に拡張領域としてPlayListExtensionDataを持つ。従って、本実施の形態では、前記BD-ROMで規定出来ない情報をこのIndexExtensionDataやPlayListExtensionDataにて規定するものとする。なお、説明するまでもないが、以後述べるメタデータの格納方法についてはあくまでも例であり、以後述べる情報をメタデータとして格納することが重要であってVOB管理情報ファイルClipInformationの拡張領域に格納したり、別の構造を取っても構わない。本実施の形態で規定するIndexExtensionDataの例を、図53を用いて説明する。まず、前述したBD管理情報BD.INFOの末尾にあるIndexExtensionDataに、DiscInfo領域とPLTable領域の二つの領域を持たせる。DiscInfo領域はディスク全体に関するメタデータを格納するための領域である。例としてDiscタイトルにはDiscのタイトル情報を格納し、Discサムネイルには、ディスクを代表するサムネイル画像に関する情報を格納する。PLTable領域はBD管理情報の1つであるPlayListのメタデータを格納する領域であり、PL_Number領域と各PlayListのメタデータ領域図中のPL1~PLmからなる。PL_NumberとプレイリストXXX.PLのファイル総数とは同数となり、以降PlayListプレイリストXXX.PL毎のメタデータがPL1から順に格納される。各PlayListのメタデータは、例としてPL_FileName領域とPL_Type領域を持つ。PL_FileName領域は、当該メタデータ領域PL1~PLmがどのPlayListのメタデータを格納しているかを示す情報である。例えばPlayListファイルXXX.PLのファイルボディXXXが格納される。また、PL_Type領域には、当該PlayListの種別が格納される。BD-ROMにおいては映像は全て予めオーサリングされているためPlayListに種別を設ける必要がないが、撮影または録画する映像をBD-ROM形式で記録する場合は大きく二つに大別される。まず1つ目は撮影または録画したオリジナルの映像を管理し、順次先頭から再生するシナリオが記録されるPlayListであり、以降本実施の形態ではRealPlayListと呼ぶ。もう一つは、ユーザがオリジナルの映像に対して再生順序の入れ替えや再生箇所の指定などの編集を行ったシナリオが記録されるPlayListであり、以降本実施の形態ではVirtualPlayListと呼ぶ。撮影または録画した映像の単位であるShotとRealPlayList、VirtualPlayListとの対応関係は、実施の形態4において図50を用いて説明した当該対応関係と同じである。すなわち、図50に示すように、RealPlayListは撮影したShotが格納されたストリームを撮影順に再生するものであり、基本的にストリームが記録される際にストリーム情報と共に生成される。例えばRealPlayListはShotの撮影後に追加または修正されていく。一方、VirtualPlayListはユーザによる映像編集の結果として記録した映像の一部を所望の順序で再生するためのものであり、ユーザの編集処理時に作成される。このように撮影または録画したストリームは複数のPlayListから参照される可能性がある。このためあるPlayListを削除する際に当該PlayListが参照するストリームも同時に削除すると存在しないストリームを参照するPlayListが出来てしまう可能性がある。従って、必ず1つのRealPlayListからは参照されるため、VirtualPlayList削除時は参照するストリーム及びストリーム情報は削除せず、RealPlayList削除時は参照するストリーム及びストリーム情報を削除し、当該ストリームを参照するVirtualPlayListを修正するものとしてもよい。以上、RealPlayListとVirtualPlayListについて説明したが、これらの識別情報を前記PL_Typeに格納するものとする。またその他の種別として、当該プレイリストで再生されるストリームがメニュー用ストリームであることを示す種別や、スライドショウであることを示す種別を設けてもよい。また、図34の説明の中で述べたプログラムが多重化されたストリームInteractiveGraphicsIGStreamを参照するPlayListであることを前記PL_Typeに合わせて記録してもよい。例えば、当該プレイリストのPL_Typeがスライドショウであった場合、当該ストリームは、ページ送りやページ戻り用のボタン及びボタンコマンドIGStreamをストリーム中に含む場合もあり得る。この場合、例えばある機器でスライドショウを作成した後、別の機器で当該スライドショウを変更する場合に、単純に編集してもよいのか、それともIGStreamを含んでおりそれを考慮した上で編集する必要があるのかを判断することが出来る。例えばIGStreamを含んだスライドショウであることが前記PL_Typeに指定された識別子で判明した場合、当該機器はまずIGStreamを検出していき、検出したIGStreamを全て削除した上で、スライドショウを編集することが可能となる。なお、図示していないがあるディスクがどの機器で記録されたディスクであるのかどうかという情報を、例えば本実施の形態のメタデータにおけるDiscInfoに持たせてもよい。これにより、記録装置は前記IGStreamを含むスライドショウが当該機器で作成されたものかどうかを判別することが可能である。例えば、前記PL_TypeによりIGStreamを含むスライドショウであることを判別した場合、当該機器で作成したものである場合は直接修正してもよい。次に、本実施の形態で規定するPlayListExtensionDataの例を図54に示す。PlayListExtensionDataは、PL作成日時領域、PLタイトル領域、PLサムネイル領域、およびMarkTable領域の4つの領域からなる。PL作成日時領域には当該PlayListを作成した日時を記録する。PLタイトル領域にはPlayListのタイトル名を記録する。PLサムネイル領域には当該PlayListを代表するサムネイルへの参照情報を記録する。MarkTable領域は当該PlayListメタデータが参照するPlayListが管理する各Markのメタデータを格納する領域であり、Mark_Number領域と各Markのメタデータ領域図中のMark1~Marknからなる。図54に示す例ではMark_Numberと当該PlayListが管理するMarkの数とが同数となり、以降当該PlayListが管理する順番に従って、Mark毎のメタデータがMark1から順に格納される。なお、本実施の形態ではPlayListが管理するMarkとメタデータで管理するMarkとか一対一対応するものとして記述するが、これに限るものではない。例えば、再生を一時停止した地点を示すMarkなどBD管理情報では規定出来ないMarkをメタデータでのみ管理してもよい。この場合、例えば図54に示すMarkのメタデータ領域に、BD管理情報で規定するMarkを参照しているのか否かを示す情報と、参照している場合はそのMarkのIDを、参照していない場合はメタデータで管理するMarkが指すストリームの位置情報を格納する領域を別途設ける必要がある。各Markのメタデータは、例としてMark_Type領域とサムネイル領域、および撮影日時領域、の3つの領域からなる。Mark_Type領域は当該PlayListで管理するMarkの種別を記録するものである。Mark_typeの1つとして、例えば当該MarkがShotの先頭を示すMarkであるShot-Markがある。このShot-Markを管理するのは前述のRealPlayListのみとしてもよい。その他のMark_Typeとしては、後述するOldShotMarkの他に、例えばスライドショウにおける各静止画の開始位置を意味するSlideshowMarkを定義してもよい。例えばRealPlayListが再生するストリームは動画とスライドショウの混在を許すとした場合、当該SlideshowMarkとShotMarkにより各Chapterが動画なのか静止画なのか判別することができる。またメニュー表示において動画Shotのサムネイルのみを表示する場合であっても、MarkがEntryMarkであり、かつ、MarkのメタデータにおけるMarkTypeがShotMarkのもののみサムネイル一覧表示するといったことが可能となる。また、例えばMakerPrivateというMarkTypeを定義しておき、メーカー独自機能を実現するMarkを実現可能としてもよい。次にサムネイル領域は当該Markの指すストリーム位置における画像をサムネイルとして指定する。なお、当該MarkがShotの先頭を示すMarkである場合、基本はShotの先頭の画像がサムネイルとして設定される。しかしShotを代表するサムネイルを参照させるために、当該Markが指すストリーム位置の画像ではなく、ユーザの設定や自動判別などにより抽出した、当該Markが指すストリーム位置とは別の位置の画像を代表サムネイルとしてもよい。撮影日時領域は、当該MarkがShotの先頭を示すMarkである場合、当該Shotの撮影日時を記録する。なお、Markのメタデータとして記録される情報は、上記説明の内容に限られることはない。例えば、BD-ROM規格では記録出来ない、撮影した情報に関する情報をメタデータとして持たせてもよい。以上、本実施の形態におけるメタデータの種類とその格納方法について説明した。Shotを一覧メニューとして表示する際、撮影録画順にそのサムネイルを表示することで、Shotの相関関係が掴みやすくユーザの利便性を向上することができる。本実施の形態ではこのような撮影録画順のソートならびにメニュー表示を容易とするため、図53および図54で示したメタデータにおいて、図53におけるPlayListのメタデータ図中PL1~PLmを格納する順番を記録順に格納するものとする。また、基本的にはPlayListのメタデータの格納位置は編集等でも変更しないものとする。また前述の図51に示すように、RealPlayListにおいて、Shotの先頭を示すShot-Markは当該Shotの撮影順に並ぶものとし、当然プレイリストにて管理するMarkの付加順及び図54で説明した当該Markのメタデータの記録順も同様に撮影順に並ぶものとする。また、当該順序は削除を除き編集等で入れ替えないものとする。以上により、RealPlayListのメタデータの格納順と、当該RealPlayListが管理するMarkにおいてShotの先頭を示すMarkのメタデータの格納順とにより、当該ディスクに記録されたShotの撮影録画順序を識別することが可能となる。以上により、Shotの撮影順にサムネイルや撮影日時等を一覧表示した再生メニューを生成する場合は、図53および図54に示すメタデータを参照するだけでよい。また、PL_TypeがRealPlayListであるPlayListのメタデータを順次解析し、当該PlayListのメタデータに於いて、Mark_Type=Shot-Mark当該MarkがShotの先頭を示すであるMarkのメタデータを順次参照しメニュー表示すればよい。例えば本実施の形態のメタデータが図55Aに簡易的に示す状態である場合を想定する。この場合、PlayList1、2、4はRealPlayListであり、PlayList3はVirtualPlayListである。従って、PlayListの記録順は、PlayList1,2,4の順になる。また、図中において、Shotが付されたMarkは、Shotの先頭を示すMarkを表している。また、図中において、OldShotが付されたMarkは、後述する、失われるメタデータを保持するためのMarkを表している。従って、各PlayListの中でShotの先頭を示すMarkの記録順を抽出すると、Shotの記録順がPlayList1のMark1,3、PlayList2のMark1、PlayList4のMark1,2の順であることがわかる。このようにして、最終的にShotの一覧メニューを図55Bのように表示することが出来る。以上、説明したように本実施の形態の記録方法およびデータ構造により、撮影または録画した映像Shotの記録順を管理することが可能であり、また各Shot毎に撮影または録画した映像の撮影日時やサムネイルといった情報をメタデータとして管理することが可能となる。実施の形態6次に本発明の実施の形態6について説明する。なお、本実施の形態では情報記録媒体の例として次世代ディスクであるBD-ROMDiscを例に挙げているが、あくまでも例であり、本実施の形態のアプリケーション及びデータ構造をDVDなどの光ディスクや他の情報記録媒体である、メモリーカードSDメモリーカードやメモリースティックなどやハードディスクなどに書き込む場合でも同様の効果を得る。また、情報記録媒体ではなく、本実施の形態のアプリケーション及びデータ構造をネットワークを介して配布する場合においても同様の効果を得る。実施の形態5において、撮影または録画した映像の撮影日時やサムネイルといったBD-ROM規格では記録出来ない情報をShot単位で情報記録媒体に記録する方法について説明した。実施の形態6では、Shotの編集作業によりShotの撮影日時やサムネイルといった情報が失われるという問題を解決する記録方法について説明する。上記問題の具体例を、図56を用いて説明する。まず初期状態として図56Aに示すように1つのプレイリストRealPlayListが撮影時間20分の3つのShotShot1~Shot3を管理しているものと想定する。ここで図55Aに示すようにMarkType=ShotMarkのMarkを各Shotの先頭に付与し、各Shotの撮影日時やサムネイル、必要があれば前述の撮影時間などの情報を実施の形態6で述べたようにMarkのメタデータで管理するものとする。またShotMarkは本実施の形態ではユーザにChapterとして識別させるためEntryMarkとする。以上、説明した初期状態から、図56Bに示すようにShot1とShot2を結合する編集を行った場合を想定する。この場合、Shot2はShot1の後ろに結合され、Shot1とShot2とは、1つのShotである撮影時間40分のShot1となる。さらに、Shot2の先頭に付与されていたShotMarkは削除される。この状態で、図56Cに示すようにShot1を旧Shot2の先頭よりも後ろの時間位置にあたる25分の地点で2つに分割する編集を行う場合を想定する。このように分割してできた新たなShotをShot4とすると、Shot4の先頭にも新規にMarkType=ShotMarkのEntryMarkを設定し、Markのメタデータを記録することになる。この場合、Shot4の撮影日時を正確に計算することは不可能である。ここで、例えば、Shot1の撮影日時である9月1日12時0分に、前述の分割した時間位置である25分を加えることが考えられる。しかし、この加算で得られる9月1日12時25分という日時は、Shot4の撮影日時として正しくない。このように、Shotの結合、分割といった処理をおこなうことで、Shotの撮影日時が失われるという問題がある。そこで本実施の形態では、MarkTypeとして新規にOldShotMarkというMarkTypeを設けるものとする。このMarkType=OldshotMarkは図56Bで示した結合処理によって失われるメタデータを保持するためのMarkであり、ユーザがChapterとして識別するためのMarkではない。そのため、本実施の形態ではMarkType=OldShotMarkはLinkPointにのみ設定可能とする。編集処理によってもShotの撮影日時等のメタデータを保持し、例えばShotの正確な撮影日時を設定可能とする本実施の形態の具体内容について、図57を用いて説明する。まず図57Aに初期状態を示す。これは図56Aで示した初期状態と同じである。また以後行う編集も図56Bに示す編集内容と同じ編集を実行することを想定する。すなわち、図57Aに示す初期状態から、図57Bに示すようにShot1とShot2の結合処理を行いShot4を生成する編集を行ったとする。この場合、まずShot4の先頭に付与すべきEntryMarkはShot1のものと同様であり特に処理は行わない。一方、Shot2は消失するためShot2の先頭に付与していたMarkType=ShotMarkのEntryMarkをLinkPointに変更する。次に、図54を用いて説明したMarkTypeをShotMarkからOldShotMarkに変更する。これによりShot2の先頭を示していたMarkはBD-ROMにおける管理情報としては、LinkPointとして保持される。そのため、Markと一対一として管理されるMarkのメタデータも同じく保持される。次に、図57Cに示すように、Shot4の先頭から25分の地点でShot4を2つに分割する編集を行い、Shot5とShot6の2つのShotを生成する編集を行ったとする。この場合、Shot5の先頭に付与すべきEntryMarkはShot4のものと同様であり特に処理は行わない。一方、Shot6の先頭にはEntryMarkが設定されていないため、Shot6の先頭にも新規にMarkType=ShotMarkのEntryMarkを設定する必要がある。また、当該EntryMarkのメタデータも新規に記録することになる。この場合のShot6の撮影日時を計算する方法を以下に述べる。まず、分割前のShot4において、分割地点にあたるShot6の先頭より前に存在するMarkを検索する。ここでMarkType=OldShotMarkのLinkPointを検出する前に、MarkType=ShotMarkのEntryMarkを検出、つまりShot4の先頭に到達した場合は、単純にShot4の撮影日時に分割した地点の時間を加えたものがShot4の撮影日時となる。しかし、本例の場合、図57Cに示すように、旧Shot2の先頭よりも後方でShot4を分割しているため、MarkType=OldShotMarkのLinkPointが先に検出される。この場合は、旧Shot2の先頭にあたるMarkType=OldShotMarkのLinkPointのメタデータを参照して9月5日9時30分という日時情報が得られる。次に、検出したMarkType=OldShotMarkのLinkPointの地点旧Shot2の先頭からShot6の先頭までの再生時間である5分を、先ほど得た日時情報9月5日9時30分に加える。このようにして算出される9月5日9時35分という正しい日時情報が、Shot6の撮影日時情報となる。なお、図示しないが、図57Bに示すShot4を先頭から20分の地点、すなわち旧Shot2の先頭の地点で分割する場合は、単に旧Shot2の先頭を示すLinkPointをEntryMarkに変更し、MarkのメタデータにおけるMarkTypeをShotmarkに変更するだけでよい。なお、図56および図57を用いて説明した例はShotの結合や分割といった、あくまでもストリームの再生位置を指定しているRealPlayListの再生制御データの変更による編集作業で発生する問題を例としている。しかしながら、Shotのある区間を中抜き削除するといったAVストリーム自体を編集する場合においても適用出来る。例えば、ストリームの一部を削除する場合は、削除部分の直後の再生時刻にMarkを設定し、当該Markのメタデータに57Cに示す手法と同様に計算した撮影日時を設定すればよい。なお、MarkをEntryMarkとし、メタデータにおけるMarkTypeをShotMarkにするか、MarkをLinkPointとしメタデータにおけるMArkTypeをOldShotMarkにするかについては、以下のように判断する。すなわち、削除部分の前後の映像の扱いにより、削除部分の前後の映像を各々別のShotとして扱う場合は前者として設定し、削除部分の前後の映像を結合し1つのShotとして扱う場合は後者として設定する。以上のように本実施の形態の記録方法およびデータ構造により、Shotの結合や分割といった処理を行ってもShotの撮影日時を保持することができる。なお、撮影日時情報など撮影および録画した映像の情報は、メタデータとしてBD-ROMの管理情報の拡張領域に格納する方法だけでなく、ストリーム中に例えばSEI_MESSEGEに埋め込むことも可能である。またこの場合分割等の編集処理を行ってもその地点でストリームから撮影日時を検出することも可能である。従って、図56Bに示すShotの結合を行った場合、ストリーム中に撮影日時情報を持たせている場合は、前述のようにShot2のEntryMarkをLinkPointに変更しMarkType=ShotMarkをOldShotに変更するといった一連の処理を行わないものとしてもよい。また、図56Cに示すShotの分割を行った場合、まずストリーム中の撮影日時情報を調べ、ストリーム中に撮影日時情報が記録されている場合は、図56Cを用いて説明した撮影日時計算処理を行わずストリームから撮影日時を検出し、メタデータとして設定してもよい。以上、本発明の実施の形態5および6について説明したが、これら実施の形態で示した記録方法およびデータ構造は、撮影または録画した映像をBD-ROM形式で記録する場合に、映像の記録順序を保持するようにメタデータを記録した情報記録媒体と、それを記録する記録装置、記録方法、記録プログラム、並びに、これら実施の形態の記録方法を実現する半導体に適用される。また、実施の形態5および6の記録方法およびデータ構造によれば、映像を撮影した順序を記録可能であり、特に、民生機器産業において利用される可能性をもつ。実施の形態7従来、ストリーム内にメタデータを記録する場合には、その記録順が不明であり、数多くのメタデータの全体を検索し解析しなければ、必要なメタデータが記述されているのか否かが分からない。また、同一種類のメタデータを記述する異なるメタデータがあるような場合、読み出し機器の解析処理が煩雑になるという課題もある。そこで、実施の形態7として、映像情報を符号化する際に、映像情報への付属情報を同時に符号化する情報記録装置であって、付属情報は、映像情報のピクチャ単位に付与され、1つの付属情報は識別情報IDと実情報データから構成され、同一ピクチャ内で同一種類の情報を格納できる前記付属情報を複数記述する場合には、所定の識別情報IDを持つ付属情報を記録することを特徴とする情報記録装置、および、当該情報記録装置における記録方法について説明を行う。この情報記録装置および記録方法によれば、メタデータの検索性を向上することができ、同一種類のメタデータが別個の方法で記録されている場合であっても、機器の性能に応じて容易に解析することが可能となる。なお、実施の形態7は、ムービー機器でのメタデータに関する内容である。基本的には実施の形態1に基づく内容であり、拡張または異なる部分を中心に説明する。図58は、PESパケット以下のデータ構造を示す図である。BDやデジタル放送のようにMPEG2-TSを使う場合には、1つのPESパケットに1つのピクチャが格納されることが一般的である。1つのMPEG-4AVCで符号化されたピクチャは、アクセスユニットの先頭を示すAUDelimiterAccessUnitDelimiter、シーケンス属性を示すSPSSequenceParameterSet、ピクチャ属性を示すPPSPictureParameterSet、付属情報などを格納するSEISupplementalEnhancementInformation、および、スライス符号情報を示すSliceなどから構成される。付属情報を格納するSEIは、ClosedCaption情報やその他の情報を格納している。ここでは、主にビデオカメラレコーダ向けのメタデータをHDMとして束ね、SEIの中に格納している。図59には、SEIのデータ構造を示した。図に示されたように当該SEIにどのような付属情報が入っているかを示す識別情報type_indicatorにより、格納されているデータ種類が特定できる。例えば、type_indicator=0x00000020であれば、HDMデータが格納されているということがわかる。HDMデータは、HDM_pack_ID8ビットとHDM_pack_data32ビットから構成されるHDM_packの集合体である。このID値によって、どのような種類の付属情報が、後続のHDM_pack_dataに記録されているのかを示している。ここで示されるように、HDM_packは連続してHDM_meta内に記録される。ちなみに、HDM_packは、DVDigitalVideoカメラが使用している付属情報のDVパックと同じデータ構造8ビットのID32ビットのデータである。図60は、HDM_packのID値と格納している情報との関係を示す表である。TIME列上位4ビットが0001bのTIMECODE、BINARYGROUPと、CAMERA列上位4ビットが0111bの全てのHDM_packはDVパックと同じである。RECDATETIMEは、この付属情報ピクチャが撮影された日時情報である。EXIF列上位4ビットが1010b、GPS列上位4ビットが1011b、1100bはデジタルスチルカメラで使われているExifの情報と同じである。ただし、Exifで使われている32bit/32bitのRATIONAL表記ではサイズが大きいため、16bit/16bitのRATIONAL表記としている。EXIFOPTION、GPSOPTIONには、この表に記載のないExif/GPSの情報を書き込みたい場合に使うパックである。具体的には、HDM_pack_dataにExifのTag値を書くExif_Tag16ビット、Exifに16ビット表記のRATIONAL16、符号付きのSRATIONAL16を新規追加したExif_Type8ビット、および、続くパック数を示すPack_Length8ビットを記述し、Exifのメタデータを後続のパックに記録することができる。MAKER列上位4ビットが1110bには、メーカーコードと記録したモデルコードを16ビットずつで記述するMAKERMODELパックと、各メーカーが独自に使うことのできるMAKEROPTIONパックが規定されている。このように、HDM_pack_ID値によって、どのデータが記録されているパックなのか、すぐに特定することができる。しかし、HDM_metaの中での記録規則が無いと常に最後のパックまで検索が必要となり、高速なメタデータの検索/抽出が不可能になる。また、SEIはピクチャ単位で256バイトの上限サイズと共に書き込まれるデータであるため、このメタデータの処理にはリアルタイム性高速性が要求される。また、全てのパックをピクチャごとに記録する必要はないため、最後のパックまで検索しても所望のメタデータを格納したパックが見つからないことも考えられる。そこで、HDM_meta内でのHDM_packの記録順は、HDM_packのHDM_pack_IDの小さい順番に並ぶことと規定することが重要である。これにより、所望のパックを検索するために、HDM_meta内でさらなるサーチが必要か否かを判定することが可能となる。また、所望のパックのID値を超えた場合、それより先に所望のパックが存在していないことが分かり、サーチ処理を早期に終了することが可能となる。図61は、上記処理の流れを示すフロー図である。HDMメタの取得が開始されるとS901、HDMパック数を取得するS902。HDMメタを取得し、データの最後尾であればS903でYes、HDMメタの取得に係る処理を終了するS904。また、データの最後尾でなければS903でNo、取得したい情報を全て取得したか否かを判断する。全て取得した場合はS905でYes、HDMメタの取得に係る処理を終了するS904。また、全て取得していない場合はS905でNo、解析を続けても取得した情報が取得できるか否かを判断する。取得できない場合はS906でYesは、HDMメタの取得に係る処理を終了するS904。また、取得できる場合はS906でNo、1つHDM_packを取得し、上記のデータの最後尾であるか否かの判断S903に戻る。図61に示すように、HDM_meta内のパックは、ID順で記述されているため、所望のパックを最低の処理負荷で検索/抽出することができる。図62は、DVにて定義されているCAMERA列のパックと、EXIFにて定義されているEXIF列のパックとの格納している情報の同一性を比較したものである。図62に示すように、EXIF列のパックにて格納される情報が、CAMERA列のパックでも記述できるケースがあることが分かる。即ち2重に定義された状態となっている。これは、HDM_metaがDVとExifの主要なメタデータを利用しているために、焦点距離などの光学パラメーターなどで一部重複していることを示している。例えば、EXIF列のFOCALLENGTH焦点距離は、CAMERA列のCONSUMERCAMERA1とCONSUMERCAMERA2のそれぞれにて記述することが可能である。安価な機器では、静止画向けで高品位なEXIF列の情報までは不必要だが、DVで使われているCAMERA列程度の精度の情報で十分な場合も想定される。また、このように同種の情報が2重持ちされているため、HDM_metaを解析する処理が煩雑になる課題もある。そこで、EXIF列のパックを記録する場合には、そのパックが格納する情報をCAMERA列においても記述できるのであれば、そのCAMERA列のパックも記録することが重要である。先ほどのID順で記録されるルールを加味して考慮すれば、安価な機器は、ID順にサーチを行い、自らが欲しい情報の精度であるCAMERA列のパックだけを解析し、以降にEXIF列のパックがあったとしても、CAMERA列の情報だけを取得した時点で、解析処理を止め、ユーザにその情報を提供することが可能となる。また、EXIF列まで対応した機器においては、CAMERA列で所望のデータを取得できても、EXIF列まで解析を行い、より高精度な付属情報を取得することが容易に可能となる。図63は、DVとEXIFとで同種情報を持つ場合の記録ルールの例を説明する図である。この例では、EXIF列のEXPOSURETIME、FNUMBER、EXPOSUREBIAS、MAXAPERTURE、FLASH、および、FOCALLENGTHのパックが記録されているために、対応するCAMERA列のパックも記録されている。また、FNUMBERおよびFOCALLENGTHが記録されているため、CONSUMERCAMERA1が記録されており、同様にEXPOSURETIMEが記録されているため、SHUTTERが記録されている。このように、精度が異なる同種の情報を記録する場合には、精度の低い方の情報が必ず記録順として先になるように記録されていることが肝要である。なお、対応するパックの相関が複雑になったり、EXIF列のデータを追加するために、EXIF列よりも前方のCAMERA列のデータを追加することになるが、このために、メモリ上での挿入処理が煩雑になることも考えられる。このような場合には、EXIF列に所定のパックを記録する場合には、必ずCAMERA列のCONSUMERCAMERA1だけは記録する、といった規則を設けることも効果的である。図62によれば、所定のパックとは、FNUMBER、EXPOSUREPROG.、FOCALLENGTH、WHITEBALANCEを指している。勿論、より簡単に、EXIF列に何か記録する場合には、必ずCAMERA列の所定のパックを記録するとしてもよい。また、CAMERA列を使うか、EXIF列を使うかを当該ストリームの管理情報YYY.VOBIなどで示しておくことも考えられる。DVは動画向けのメタデータとして設計され、EXIFは静止画向けのメタデータとして設計されているため、当該VOBが動画か、静止画かの情報をVOBIに記録させ、その値に応じて、動画であればCAMERA列を使い、静止画であればEXIF列を使うことも可能である。本実施の形態の情報記録装置および記録方法は、光ディスクなどに記録するメタデータに情報の重複がある場合や、その種類が膨大である場合などに、メタデータの検索処理を簡易化することができ、大幅に再生検索処理時間を減らすことができる。そのため、ハードディスクや半導体メモリなどの記録メディア上に記録する場合にも同様に有用である。実施の形態8近年、デジタルスチルカメラなどで撮影した静止画を、動画と共に管理したいというユーザ要求が近年高まってきている。しかしながら、デジタルスチルカメラの静止画は一般には非常に高画素1920x1080以上のJPEGであって、HDTVへの出力を行うことが前提である民生AV機器にとっては、そのCodecとサイズの両面から扱いにくいという課題があった。また、次世代DVD規格BD-ROM規格では、スライドショウとして静止画を扱うことは可能であるが、基本的にはパッケージメディアを対象とした規格である。そのため、スライドショウの静止画の再生順番を入れ替えたり、1枚を削除するといった編集作業が実現困難である。そこで実施の形態8として、BD-ROM規格のスライドショウにデジタルスチルカメラの静止画を取り込む際に編集容易な形で取り込めるようにする記録方法について説明する。具体的には、1つの静止画映像を含むシステムストリームである静止画ユニットを生成し、前記静止画ユニットの再生を管理する再生管理情報と共に情報記録媒体に記録する情報記録装置であって、静止画ユニットは記録する情報記録媒体の記録単位セクタの整数倍のデータサイズとする情報記録装置および記録方法について説明する。本実施の形態では、上記情報記録装置および記録方法によって、静止画スライドショウを用いて、動画と静止画を同列で管理することができ、イベント単位例えば子供の運動会で撮影した動画と静止画などでコンテンツを管理することが可能となる。また、その際に静止画スライドショウに編集耐性を与えることで、静止画スライドショーの再生順序の入れ替えや削除といった編集作業が容易かつ高速になる。実施の形態8は、上述のように、BD-ROMの静止画スライドショウにおけるストリーム構造に関する内容である。基本的には実施の形態1に基づく内容であり、拡張または異なる部分を中心に説明する。図64は、BDのストリーム構造を示している。BDで扱うストリームは記録するメディアのセクタサイズなどとは無関係に、TSパケット188バイトとそのTSパケットのデコーダへの入力時刻を復元するATSArrivalTimeStamp、4バイトを加えたTimedTSPacketと呼ばれる192バイトの繰り返しで構成されている。BDがTSパケットMPEG-2TransportStreamを採用している理由は、デジタル放送がMPEG2-TSを用いて行われていることとの親和性を確保するためである。192バイトのTimedTSPacketは、DVDやBDの2KBのセクタサイズとは合致しないため、これを32個集めた単位AlignedUnitとも呼ばれる6KBを最小記録単位としている。従って、仮に編集がある場合には、このAlignedUnit6KB単位での追加/削除がなされ、BDで扱うストリーム自体が整数個のAlignedUnitから構成されるように扱われる。図65は、デジタルスチルカメラなどで撮影した静止画をBD-ROMで規定するスライドショウとして取り込んだ場合のフォーマット構成を示す。図に示すように、XXX.PROGはXXX.PLを再生するようなプログラム再生管理情報であり、XXX.PLは、1つのCellから成るプレイリストである。Cell1は、3つのStillUnit1つの静止画映像を含むMPEG2-TSの区間を含むYYY.VOBストリーム全体を指し示している。また、再生開始時刻In1と再生終了時刻Out1とは、この3つのStillUnitの再生期間を指定する情報である。各StillUnit内の、I-pictureに付与されたPTSの値はそれぞれPTS1、PTS2、およびPTS3であって、ユーザのスキップ指令などのインタラクションが無い場合には、そのPTSタイミングから自動で切り替わり再生される。従って、ユーザが何も操作をしない場合には、PTS2-PTS1の時間がStillUnit1の静止画の表示時間となる。ユーザが次の静止画にスキップするなどといった操作を行う場合には、その操作のタイミングで次のStillUnitの再生を開始するようすることもできる。このような、BD-ROMのスライドショウを使ってユーザがデジタルスチルカメラの静止画を取り込む場合、Cell内のSTC時間軸MPEGストリームの内部基準時間が連続して経過しないといけないなど制限があるために、例えばStillUnit2だけを削除するなどの編集をされた場合、ストリームからの部分削除時に、PTS3などのストリームに埋め込まれた時刻情報などを修正していく必要がでてくる。また、StillUnit2がセクタアライメントされていないため、つまり、データ長が6KBの整数倍にされていないため、ストリームからの中抜き編集において、セクタ単位の削除処理ができず煩雑となる。これは、StillUnit2の最初と最後のTimedTSPacketが、両端のStillUnitStiilUnit1と3のTimedTSPacketと同じセクタに記録されているためである。このようにスライドショウの編集には、セクタアライメントと時刻情報の変更という2つの処理が付きまとう。以下に、この課題を解決するための方法を説明する。図66に示すXXX.PROGは図65に示すものと同一だが、XXX.PLを構成するCellをStillUnitと1対1に対応させている。この利点は、特定のStillUnitを削除してもストリーム内部のタイムスタンプの修正が不要になるということである図に示すように、各Cellはそれぞれ独自のSTC時間軸上に配置されている。。また、図67に詳細に示すように、1つのStillUnitのデータサイズがAlignedUnit6KBの整数倍となるように、ダミーのTimedTSPacketNULLパケットでよいを追加することが可能である。このようにすることで、1枚の静止画単位1つのStillUnit単位での削除や、順番の入れ替えにも容易に対応することができるようになる。1つのStillUnitは、例えばMPEG2-Videoを用いる場合には、シーケンスヘッダ、GOPヘッダ、Iピクチャ、シーケンスエンドコードからなる1枚の静止画を示す主映像ストリームと、プログラム構成に必要なPSI/SIパケットPAT、PMT、およびSITなど、基準時刻STCを生成する時刻情報を運ぶPCRパケット、および静止画主映像ストリームに重畳して表示する副映像ストリームとから構成される。前述のような制限を加えることで、例えば図66のStillUnit2を削除したり、StillUnit2とStillUnit3の順番を変更する処理が、単純なプレイリストファイルのCell情報の修正と、ストリームStillUnitの部分削除/部分並び替えで済むようになる。つまり、修正箇所以降のストリームを解析し、PTSの値を変更していくなどの処理は不要である。図68には、副映像情報として、デジタルスチルカメラなどで良く使われているExif情報を字幕ストリームとして取り込む例を示している。Exif情報とは、シャッター速度やISO感度、撮影日時などの静止画に関連する付加情報を格納した情報であり、各種様々な静止画に関連する情報を格納している情報である。このような静止画に付随する情報は常には表示される必要は無いため、図68Cに示すような副映像情報を、BD-ROMにおける字幕ストリームのような仕組みユーザが意図的に表示/非表示を選択可能な仕組みとして多重化することも考えられる。この場合、ユーザは、図68Bのような静止画だけの静止画スライドショウだけではなく、もしユーザが望むならば、それに付随する情報も表示する図68Aのような形式で静止画スライドショウを楽しむこともできる。図69は、デジタルスチルカメラの静止画とExif情報から、図68A~図68Cに示すような主映像と副映像に区別されたスライドショウを作成するためのフロー図である。静止画の取り込みが開始されるとS1001、まず、変換する静止画を読み込むS1002。静止画からExif情報を抽出しS1003、Exif情報の一部を主映像に重畳する副映像としてエンコードするS1004。また、静止画を1920×1080の画素数にリサイズするS1005。リサイズ後、1枚のI-pictureからなる主映像MPEG2-Video等としてエンコードするS1006。以上により、主映像と副映像とが生成され、主映像と副映像とを合わせたStilUnitを生成するS1007。StilUnitがセクタアラインメントされている場合はS1008でYes、静止画の取り込みに係る処理を終了するS1010。また、StilUnitがセクタアラインメントされていない場合はS1008でNo、ダミーパケットNULLパケットを追加し、セクタアラインメントにするS1009。その後、静止画の取り込みに係る処理を終了するS1010。一般的にはデジタルスチルカメラの画素数はフルHDの1920x1080を超えるものが多いため、HDサイズにリサイズしてI-pictureとしてエンコードを行う。また、所定のExif情報を抽出し、字幕ストリームPGストリーム:PresentationGraphicsストリームとしてエンコードを行う。エンコードが済んで多重化を行い、StillUnit単位でセクタアライメントがとれるよう、ダミーパケットを挿入して多重化を終える。本実施の形態にかかる光ディスクおよびその記録/再生装置、記録/再生方法は、光ディスクに記録された静止画スライドショウの1論理単位を記録媒体の記録単位セクタに合わせることで、静止画スライドショウの編集が極めて容易となる。また、光ディスクに限らず、ハードディスクや半導体メモリなどの記録メディア上に記録する場合にも有用であり、このような種々の記録メディアに記録するAVレコーダや、記録された記録メディア、これらの記録メディアを再生するAVプレーヤに適用できる。"