"プレゼンテーションタイムスタンプと、それに対応するアクセスユニットを構成するトランスポートパケットのアドレスとのペアを有する第1のアドレステーブル、または、一つの時間量と、トランスポートパケットの到着時間軸を前記時間量に基づき区切られてなるタイムユニットに含まれるトランスポートパケットのアドレスとを有する第2のアドレステーブルのいずれか一方と、ストリームデータの再生を指定する再生指定情報とを有するデータ構造のデータが記録された記録媒体であって、前記データ構造のデータを取得した情報処理装置により、前記記録媒体に前記第1のアドレステーブルが記録されている場合には、前記再生指定情報を用いて、プレゼンテーションタイムに基づくタイムベースに基づいて前記ストリームデータの再生が制御される記録媒体。記録媒体の製造装置が、プレゼンテーションタイムスタンプと、それに対応するアクセスユニットを構成するトランスポートパケットのアドレスとのペアを有する第1のアドレステーブル、または、一つの時間量と、トランスポートパケットの到着時間軸を前記時間量に基づき区切られてなるタイムユニットに含まれるトランスポートパケットのアドレスとを有する第2のアドレステーブルのいずれか一方と、ストリームデータの再生を指定する再生指定情報とを有するデータ構造のデータを前記記録媒体に記録するステップを含む記録媒体の製造方法。ところで、上述したような記録装置により記録媒体にAVストリームデータを記録する場合、例えば、高速再生ができるようにするために、AVストリームデータを分析し、Iピクチャの位置を検出して、Iピクチャにアクセスできるようにして記録する場合と、AVストリームデータを分析せず、そのまま記録する場合とがある。このような場合、従来、それぞれ専用のアプリケーションプログラムを用意し、それぞれにより、AVストリームを、異なるフォーマットのAVストリーム高速再生が可能なAVストリーム、または不可能なAVストリームとして記録媒体に記録するようにしていた。その結果、アプリケーションプログラムの開発に、費用と時間がかかることがあった。また、それぞれのアプリケーションプログラムにより記録されたAVストリームは、異なるフォーマットのものなので、相互の互換性がなくなり、共通の装置で再生することができないことがあった。さらに、従来の記録装置では、例えば、オーディオデータを、所謂アフターレコーディングすることが困難であった。本発明はこのような状況に鑑みてなされたものであり、高速再生が可能なAVストリームと不可能なAVストリームを、共通に管理することができるようにすることにある。本発明の第1の側面の記録媒体は、プレゼンテーションタイムスタンプと、それに対応するアクセスユニットを構成するトランスポートパケットのアドレスとのペアを有する第1のアドレステーブル、または、一つの時間量と、トランスポートパケットの到着時間軸を前記時間量に基づき区切られてなるタイムユニットに含まれるトランスポートパケットのアドレスとを有する第2のアドレステーブルのいずれか一方と、ストリームデータの再生を指定する再生指定情報とを有するデータ構造のデータが記録された記録媒体であって、前記データ構造のデータを取得した情報処理装置により、前記記録媒体に前記第1のアドレステーブルが記録されている場合には、前記再生指定情報を用いて、プレゼンテーションタイムに基づくタイムベースに基づいて前記ストリームデータの再生が制御される。本発明の第1の側面においては、プレゼンテーションタイムスタンプと、それに対応するアクセスユニットを構成するトランスポートパケットのアドレスとのペアを有する第1のアドレステーブル、または、一つの時間量と、トランスポートパケットの到着時間軸を前記時間量に基づき区切られてなるタイムユニットに含まれるトランスポートパケットのアドレスとを有する第2のアドレステーブルのいずれか一方と、ストリームデータの再生を指定する再生指定情報とを有するデータ構造のデータが記録され、そのデータ構造のデータを取得した情報処理装置が、前記記録媒体に前記第1のアドレステーブルが記録されている場合には、前記再生指定情報を用いて、プレゼンテーションタイムに基づくタイムベースに基づいて前記ストリームデータの再生を制御する。本発明の第2の側面の記録媒体の製造方法は、記録媒体の製造装置が、プレゼンテーションタイムスタンプと、それに対応するアクセスユニットを構成するトランスポートパケットのアドレスとのペアを有する第1のアドレステーブル、または、一つの時間量と、トランスポートパケットの到着時間軸を前記時間量に基づき区切られてなるタイムユニットに含まれるトランスポートパケットのアドレスとを有する第2のアドレステーブルのいずれか一方と、ストリームデータの再生を指定する再生指定情報とを有するデータ構造のデータを記録媒体に記録するステップを含む前記記録媒体の製造方法である。本発明の第2の側面においては、プレゼンテーションタイムスタンプと、それに対応するアクセスユニットを構成するトランスポートパケットのアドレスとのペアを有する第1のアドレステーブル、または、一つの時間量と、トランスポートパケットの到着時間軸を前記時間量に基づき区切られてなるタイムユニットに含まれるトランスポートパケットのアドレスとを有する第2のアドレステーブルのいずれか一方と、ストリームデータの再生を指定する再生指定情報とを有するデータ構造のデータが記録媒体に記録される。本発明の側面によれば、高速再生が可能なAVストリームと不可能なAVストリームを、共通に管理することが可能になる。以下に、本発明の実施の形態について、図面を参照して説明する。図1は、本発明を適用した記録再生装置1の内部構成例を示す図である。まず、外部から入力された信号を記録媒体に記録する動作を行う部分の構成について説明する。記録再生装置1は、アナログデータ、または、デジタルデータを入力し、記録することができる構成とされている。端子11には、アナログのビデオ信号が、端子12には、アナログのオーディオ信号が、それぞれ入力される。端子11に入力されたビデオ信号は、解析部14とAVエンコーダ15に、それぞれ出力される。端子12に入力されたオーディオ信号は、AVエンコーダ15に出力される。解析部14は、入力されたビデオ信号からシーンチェンジなどの特徴点を抽出する。AVエンコーダ15は、入力されたビデオ信号とオーディオ信号を、それぞれ符号化し、符号化ビデオストリーム、符号化オーディオストリーム、およびAV同期等のシステム情報をマルチプレクサ16に出力する。符号化ビデオストリームは、例えば、MPEGMovingPictureExpertGroup2方式により符号化されたビデオストリームであり、符号化オーディオストリームは、例えば、MPEG1方式により符号化されたオーディオストリームや、ドルビーAC3方式により符号化されたオーディオストリーム等である。マルチプレクサ16は、入力されたビデオおよびオーディオのストリームを、入力システム情報に基づいて多重化して、スイッチ17を介して多重化ストリーム解析部18とソースパケッタイザ19に出力する。多重化ストリームは、例えば、MPEG2トランスポートストリームやMPEG2プログラムストリームである。ソースパケッタイザ19は、入力された多重化ストリームを、そのストリームを記録させる記録媒体100のアプリケーションフォーマットに従って、ソースパケットから構成されるAVストリームを符号化する。AVストリームは、ECC誤り訂正符号化部20、変調部21で所定の処理が施され、書き込み部22に出力される。書き込み部22は、制御部23から出力される制御信号に基づいて、記録媒体100にAVストリームファイルを書き込む記録する。デジタルインタフェースまたはデジタルテレビジョンチューナから入力されるデジタルテレビジョン放送等のトランスポートストリームは、端子13に入力される。端子13に入力されたトランスポートストリームの記録方式には、2通りあり、それらは、トランスペアレントに記録する方式と、記録ビットレートを下げるなどの目的のために再エンコードをした後に記録する方式である。記録方式の指示情報は、ユーザインターフェースとしての端子24から制御部23へ入力される。入力トランスポートストリームをトランスペアレントに記録する場合、端子13に入力されたトランスポートストリームは、多重化ストリーム解析部18と、ソースパケッタイザ19に出力される。これ以降の記録媒体100へAVストリームが記録されるまでの処理は、上述の入力オーディオ信号とビデオ信号を符号化して記録する場合と同一の処理なので、その説明は省略する。入力トランスポートストリームを再エンコードした後に記録する場合、端子13に入力されたトランスポートストリームは、デマルチプレクサ26に入力される。デマルチプレクサ26は、入力されたトランスポートストリームに対してデマルチプレクス処理を施し、ビデオストリーム、オーディオストリーム、およびシステム情報を抽出する。デマルチプレクサ26により抽出されたストリーム情報のうち、ビデオストリームはAVデコーダ27に、オーディオストリームとシステム情報はマルチプレクサ16に、それぞれ出力される。AVデコーダ27は、入力されたビデオストリームを復号し、その再生ビデオ信号をAVエンコーダ15に出力する。AVエンコーダ15は、入力ビデオ信号を符号化し、符号化ビデオストリームをマルチプレクサ16に出力する。一方、デマルチプレクサ26から出力され、マルチプレクサ16に入力されたオーディオストリームとシステム情報、および、AVエンコーダ15から出力されたビデオストリームは、入力システム情報に基づいて、多重化されて、多重化ストリームとして多重化ストリーム解析部18とソースパケットタイザ19にスイッチ17を介して出力される。これ以後の記録媒体100へAVストリームが記録されるまでの処理は、上述の入力オーディオ信号とビデオ信号を符号化して記録する場合と同一の処理なので、その説明は省略する。本実施の形態の記録再生装置1は、AVストリームのファイルを記録媒体100に記録すると共に、そのファイルを説明するアプリケーションデータベース情報も記録する。アプリケーションデータベース情報は、制御部23により作成される。制御部23への入力情報は、解析部14からの動画像の特徴情報、多重化ストリーム解析部18からのAVストリームの特徴情報、および端子24から入力されるユーザからの指示情報である。解析部14から供給される動画像の特徴情報は、入力動画像信号の中の特徴的な画像に関係する情報であり、例えば、プログラムの開始点、シーンチェンジ点、コマーシャルCMの開始終了点などの指定情報マークであり、また、その指定場所の画像のサムネイル画像の情報も含まれる。多重化ストリーム解析部18からのAVストリームの特徴情報は、記録されるAVストリームの符号化情報に関係する情報であり、例えば、AVストリーム内のIピクチャのアドレス情報、AVストリームの符号化パラメータ、AVストリームの中の符号化パラメータの変化点情報、ビデオストリームの中の特徴的な画像に関係する情報マークなどである。端子24からのユーザの指示情報は、AVストリームの中の、ユーザが指定した再生区間の指定情報、その再生区間の内容を説明するキャラクター文字、ユーザが好みのシーンにセットするブックマークやリジューム点の情報などである。制御部23は、上記の入力情報に基づいて、AVストリームのデータベース、AVストリームの再生区間をグループ化したものPlayListのデータベース、記録媒体100の記録内容の管理情報、およびサムネイル画像の情報を作成する。これらの情報から構成されるアプリケーションデータベース情報は、AVストリームと同様にして、ECC符号化部20、変調部21で処理されて、書き込み部22へ入力される。書き込み部22は、制御部23から出力される制御信号に基づいて、記録媒体100へデータベースファイルを記録する。上述したアプリケーションデータベース情報についての詳細は後述する。このようにして記録媒体100に記録されたAVストリームファイル画像データと音声データのファイルと、アプリケーションデータベース情報が再生される場合、まず、制御部23は、読み出し部28に対して、記録媒体100からアプリケーションデータベース情報を読み出すように指示する。そして、読み出し部28は、記録媒体100からアプリケーションデータベース情報を読み出し、そのアプリケーションデータベース情報は、復調部29、ECC復号部30の処理を経て、制御部23へ入力される。制御部23は、アプリケーションデータベース情報に基づいて、記録媒体100に記録されているPlayListの一覧を端子24のユーザインターフェースへ出力する。ユーザは、PlayListの一覧から再生したいPlayListを選択し、再生を指定されたPlayListに関する情報が制御部23へ入力される。制御部23は、そのPlayListの再生に必要なAVストリームファイルの読み出しを、読み出し部28に指示する。読み出し部28は、その指示に従い、記録媒体100から対応するAVストリームを読み出し復調部29に出力する。復調部29に入力されたAVストリームは、所定の処理が施されることにより復調され、さらにECC復号部30の処理を経て、ソースデパケッタイザ31出力される。ソースデパケッタイザ31は、記録媒体100から読み出され、所定の処理が施されたアプリケーションフォーマットのAVストリームを、デマルチプレクサ26に出力できるストリームに変換する。デマルチプレクサ26は、制御部23により指定されたAVストリームの再生区間を構成するビデオストリーム、オーディオストリーム、およびAV同期等のシステム情報を、AVデコーダ27に出力する。AVデコーダ27は、ビデオストリームとオーディオストリームを復号し、再生ビデオ信号と再生オーディオ信号を、それぞれ対応する端子32と端子33から出力する。また、ユーザインタフェースとしての端子24から、ランダムアクセス再生や特殊再生を指示する情報が入力された場合、制御部23は、AVストリームのデータベースの内容に基づいて、記憶媒体100からのAVストリームの読み出し位置を決定し、そのAVストリームの読み出しを、読み出し部28に指示する。例えば、ユーザにより選択されたPlayListを、所定の時刻から再生する場合、制御部23は、指定された時刻に最も近いタイムスタンプを持つIピクチャからのデータを読み出すように読み出し部28に指示する。また、ユーザによって高速再生が指示された場合、制御部23は、AVストリームのデータベースに基づいて、AVストリームの中のIピクチャデータを順次連続して読み出すように読み出し部28に指示する。読み出し部28は、指定されたランダムアクセスポイントからAVストリームのデータを読み出し、読み出されたデータは、後段の各部の処理を経て再生される。次に、ユーザが、記録媒体100に記録されているAVストリームの編集をする場合を説明する。ユーザが、記録媒体100に記録されているAVストリームの再生区間を指定して新しい再生経路を作成したい場合、例えば、番組Aという歌番組から歌手Aの部分を再生し、その後続けて、番組Bという歌番組の歌手Aの部分を再生したいといった再生経路を作成したい場合、ユーザインタフェースとしての端子24から再生区間の開始点イン点と終了点アウト点の情報が制御部23に入力される。制御部23は、AVストリームの再生区間をグループ化したものPlayListのデータベースを作成する。ユーザが、記録媒体100に記録されているAVストリームの一部を消去したい場合、ユーザインタフェースとしての端子24から消去区間のイン点とアウト点の情報が制御部23に入力される。制御部23は、必要なAVストリーム部分だけを参照するようにPlayListのデータベースを変更する。また、AVストリームの不必要なストリーム部分を消去するように、書き込み部22に指示する。ユーザが、記録媒体100に記録されているAVストリームの再生区間を指定して新しい再生経路を作成したい場合であり、かつ、それぞれの再生区間をシームレスに接続したい場合について説明する。このような場合、制御部23は、AVストリームの再生区間をグループ化したものPlayListのデータベースを作成し、さらに、再生区間の接続点付近のビデオストリームの部分的な再エンコードと再多重化を行う。まず、端子24から再生区間のイン点のピクチャの情報と、アウト点のピクチャの情報が制御部23へ入力される。制御部23は、読み出し部28にイン点側ピクチャとアウト点側のピクチャを再生するために必要なデータの読み出しを指示する。そして、読み出し部28は、記録媒体100からデータを読み出し、そのデータは、復調部29、ECC復号部30、ソースデパケッタイザ31を経て、デマルチプレクサ26に出力される。制御部23は、デマルチプレクサ26に入力されたデータを解析して、ビデオストリームの再エンコード方法picturecodingtypeの変更、再エンコードする符号化ビット量の割り当てと、再多重化方式を決定し、その方式をAVエンコーダ15とマルチプレクサ16に供給する。次に、デマルチプレクサ26は、入力されたストリームをビデオストリーム、オーディオストリーム、およびシステム情報に分離する。ビデオストリームは、AVデコーダ27に入力されるデータとマルチプレクサ16に入力されるデータがある。前者のデータは、再エンコードするために必要なデータであり、これはAVデコーダ27で復号され、復号されたピクチャはAVエンコーダ15で再エンコードされて、ビデオストリームにされる。後者のデータは、再エンコードをしないで、オリジナルのストリームからコピーされるデータである。オーディオストリーム、システム情報については、直接、マルチプレクサ16に入力される。マルチプレクサ16は、制御部23から入力された情報に基づいて、入力ストリームを多重化し、多重化ストリームを出力する。多重化ストリームは、ECC符号化部20、変調部21で処理されて、書き込み部22に入力される。書き込み部22は、制御部23から供給される制御信号に基づいて、記録媒体100にAVストリームを記録する。以下に、アプリケーションデータベース情報や、その情報に基づく再生、編集といった操作に関する説明をする。図2は、アプリケーションフォーマットの構造を説明する図である。アプリケーションフォーマットは、AVストリームの管理のためにPlayListとClipの2つのレイヤをもつ。VolumeInformationは、ディスク内のすべてのClipとPlayListの管理をする。ここでは、1つのAVストリームとその付属情報のペアを1つのオブジェクトと考え、それをClipと称する。AVストリームファイルはClipAVstreamfileと称し、その付属情報は、ClipInformationfileと称する。1つのClipAVstreamfileは、MPEG2トランスポートストリームをアプリケーションフォーマットによって規定される構造に配置したデータをストアする。一般的に、ファイルは、バイト列として扱われるが、ClipAVstreamfileのコンテンツは、時間軸上に展開され、Clipの中のエントリーポイントは、主に時間ベースで指定される。所定のClipへのアクセスポイントのタイムスタンプが与えられた時、ClipInformationfileは、ClipAVstreamfileの中でデータの読み出しを開始すべきアドレス情報を見つけるために役立つ。PlayListについて、図3を参照して説明する。PlayListは、Clipの中からユーザが見たい再生区間を選択し、それを簡単に編集することができるようにするために設けられている。1つのPlayListは、Clipの中の再生区間の集まりである。所定のClipの中の1つの再生区間は、PlayItemと呼ばれ、それは、時間軸上のイン点INとアウト点OUTの対で表される。従って、PlayListは、複数のPlayItemが集まることにより構成される。PlayListには、2つのタイプがある。1つは、RealPlayListであり、もう1つは、VirtualPlayListである。RealPlayListは、それが参照しているClipのストリーム部分を共有している。すなわち、RealPlayListは、それの参照しているClipのストリーム部分に相当するデータ容量をディスクの中で占め、RealPlayListが消去された場合、それが参照しているClipのストリーム部分もまたデータが消去される。VirtualPlayListは、Clipのデータを共有していない。従って、VirtualPlayListが変更または消去されたとしても、Clipの内容には何も変化が生じない。次に、RealPlayListの編集について説明する。図4Aは、RealPlayListのクリエイトに関する図であり、AVストリームが新しいClipとして記録される場合、そのClip全体を参照するRealPlayListが新たに作成される操作である。図4Bは、RealPlayListのディバイドに関する図であり、RealPlayListが所望な点で分けられて、2つのRealPlayListに分割される操作である。この分割という操作は、例えば、1つのPlayListにより管理される1つのクリップ内に、2つの番組が管理されているような場合に、ユーザが1つ1つの番組として登録記録し直したいといったようなときに行われる。この操作により、Clipの内容が変更されるClip自体が分割されることはない。図4Cは、RealPlayListのコンバインに関する図であり、2つのRealPlayListを結合して、1つの新しいRealPlayListにする操作であ。この結合という操作は、例えば、ユーザが2つの番組を1つの番組として登録し直したいといったようなときに行われる。この操作により、Clipが変更されるClip自体が1つにされることはない。図5Aは、RealPlayList全体のデリートに関する図であり、所定のRealPlayList全体を消去する操作がされた場合、削除されたRealPlayListが参照するClipの、対応するストリーム部分も削除される。図5Bは、RealPlayListの部分的な削除に関する図であり、RealPlayListの所望な部分が削除された場合、対応するPlayItemが、必要なClipのストリーム部分だけを参照するように変更される。そして、Clipの対応するストリーム部分は削除される。図5Cは、RealPlayListのミニマイズに関する図であり、RealPlayListに対応するPlayItemを、VirtualPlayListに必要なClipのストリーム部分だけを参照するようにする操作である。VirtualPlayListにとって不必要なClipの、対応するストリーム部分は削除される。上述したような操作により、RealPlayListが変更されて、そのRealPlayListが参照するClipのストリーム部分が削除された場合、その削除されたClipを使用しているVirtualPlayListが存在し、そのVirtualPlayListにおいて、削除されたClipにより問題が生じる可能性がある。そのようなことが生じないように、ユーザに、削除という操作に対して、そのRealPlayListが参照しているClipのストリーム部分を参照しているVirtualPlayListが存在し、もし、そのRealPlayListが消去されると、そのVirtualPlayListもまた消去されることになるが、それでも良いかといったメッセージなどを表示させることにより、確認警告を促した後に、ユーザの指示により削除の処理を実行、または、キャンセルする。または、VirtualPlayListを削除する代わりに、RealPlayListに対してミニマイズの操作が行われるようにする。次にVirtualPlayListに対する操作について説明する。VirtualPlayListに対して操作が行われたとしても、Clipの内容が変更されることはない。図6は、アセンブル編集に関する図であり、ユーザが見たいと所望した再生区間のPlayItemを作り、VirtualPlayListを作成するといった操作である。PlayItem間のシームレス接続が、アプリケーションフォーマットによりサポートされている後述。図6Aに示したように、2つのRealPlayList1,2と、それぞれのRealPlayListに対応するClip1,2が存在している場合に、ユーザがRealPlayList1内の所定の区間In1乃至Out1までの区間:PlayItem1を再生区間として指示し、続けて再生する区間として、RealPlayList2内の所定の区間In2乃至Out2までの区間:PlayItem2を再生区間として指示したとき、図6Bに示すように、PlayItem1とPlayItem2から構成される1つのVirtualPlayListが作成される。次に、VirtualPlayListの再編集について説明する。再編集には、VirtualPlayListの中のイン点やアウト点の変更、VirtualPlayListへの新しいPlayItemの挿入や追加、VirtualPlayListの中のPlayItemの削除などがある。また、VirtualPlayListそのものを削除することもできる。図7は、VirtualPlayListへのオーディオのアフレコに関する図であり、VirtualPlayListへのオーディオのアフレコをサブパスとして登録する操作のことである。このオーディオのアフレコは、アプリケーションフォーマットによりサポートされている。VirtualPlayListのメインパスのAVストリームに、付加的なオーディオストリームが、サブパスとして付加される。RealPlayListとVirtualPlayListで共通の操作として、図8に示すようなPlayListの再生順序の変更がある。この操作は、ディスクの中でのPlayListの再生順序の変更であり、アプリケーションフォーマットにおいて定義されるTableOfPlayList図20などを参照して後述するによってサポートされる。この操作により、Clipの内容が変更されるようなことはない。次に、マークMarkについて説明する。マークは、ClipおよびPlayListの中のハイライトや特徴的な時間を指定するために設けられている。Clipに付加されるマークは、AVストリームの内容に起因する特徴的なシーンを指定する、例えば、シーンチェンジ点などである。PlayListを再生する時、そのPlayListが参照するClipのマークを参照して、使用する事ができる。PlayListに付加されるマークは、主にユーザによってセットされる、例えば、ブックマークやリジューム点などである。ClipまたはPlayListにマークをセットすることは、マークの時刻を示すタイムスタンプをマークリストに追加することにより行われる。また、マークを削除することは、マークリストの中から、そのマークのタイムスタンプを除去する事である。従って、マークの設定や削除により、AVストリームは何の変更もされない。次にサムネイルについて説明する。サムネイルは、Volume、PlayList、およびClipに付加される静止画である。サムネイルには、2つの種類があり、1つは、内容を表す代表画としてのサムネイルである。これは主としてユーザがカーソル不図示などを操作して見たいものを選択するためのメニュー画面で使われるものである。もう1つは、マークが指しているシーンを表す画像である。Volumeと各Playlistは代表画を持つことができるようにする必要がある。Volumeの代表画は、ディスク記録媒体100、以下、記録媒体100はディスク状のものであるとし、適宜、ディスクと記述するを記録再生装置1の所定の場所にセットした時に、そのディスクの内容を表す静止画を最初に表示する場合などに用いられることを想定している。Playlistの代表画は、Playlistを選択するメニュー画面において、Playlistの内容を表すための静止画として用いられることを想定している。Playlistの代表画として、Playlistの最初の画像をサムネイル代表画にすることが考えられるが、必ずしも再生時刻0の先頭の画像が内容を表す上で最適な画像とは限らない。そこで、Playlistのサムネイルとして、任意の画像をユーザが設定できるようにする。以上2種類のサムネイルをメニューサムネイルと称する。メニューサムネイルは頻繁に表示されるため、ディスクから高速に読み出される必要がある。このため、すべてのメニューサムネイルを1つのファイルに格納することが効率的である。メニューサムネイルは、必ずしもボリューム内の動画から抜き出したピクチャである必要はなく、図10に示すように、パーソナルコンピュータやデジタルスチルカメラから取り込こまれた画像でもよい。一方、ClipとPlaylistには、複数個のマークを打てる必要があり、マーク位置の内容を知るためにマーク点の画像を容易に見ることが出来るようにする必要がある。このようなマーク点を表すピクチャをマークサムネイルMarkThumbnailsと称する。従って、サムネイルの元となる画像は、外部から取り込んだ画像よりも、マーク点の画像を抜き出したものが主となる。図11は、PlayListに付けられるマークと、そのマークサムネイルの関係について示す図であり、図12は、Clipに付けられるマークと、そのマークサムネイルの関係について示す図である。マークサムネイルは、メニューサムネイルと異なり、Playlistの詳細を表す時に、サブメニュー等で使われるため、短いアクセス時間で読み出されるようなことは要求されない。そのため、サムネイルが必要になる度に、記録再生装置1がファイルを開き、そのファイルの一部を読み出すことで多少時間がかかっても、問題にはならない。また、ボリューム内に存在するファイル数を減らすために、すべてのマークサムネイルは1つのファイルに格納するのがよい。Playlistはメニューサムネイル1つと複数のマークサムネイルを有することができるが、Clipは直接ユーザが選択する必要性がない通常、Playlist経由で指定するため、メニューサムネイルを設ける必要はない。図13は、上述したことを考慮した場合のメニューサムネイル、マークサムネイル、PlayList、およびClipの関係について示した図である。メニューサムネイルファイルには、PlayList毎に設けられたメニューサムネイルがファイルされている。メニューサムネイルファイルには、ディスクに記録されているデータの内容を代表するボリュームサムネイルが含まれている。マークサムネイルファイルは、各PlayList毎と各Clip毎に作成されたサムネイルがファイルされている。次に、CPICharacteristicPointInformationについて説明する。CPIは、Clipインフォメーションファイルに含まれるデータであり、主に、それはClipへのアクセスポイントのタイムスタンプが与えられた時、ClipAVstreamfileの中でデータの読み出しを開始すべきデータアドレスを見つけるために用いられる。本実施の形態では、2種類のCPIを用いる。1つは、EPmapであり、もう1つは、TUmapである。EPmapは、エントリーポイントデータのリストであり、それはエレメンタリーストリームおよびトランスポートストリームから抽出されたものである。これは、AVストリームの中でデコードを開始すべきエントリーポイントの場所を見つけるためのアドレス情報を持つ。1つのEPデータは、プレゼンテーションタイムスタンプPTSと、そのPTSに対応するアクセスユニットのAVストリームの中のデータアドレスの対で構成される。EPmapは、主に2つの目的のために使用される。第1に、PlayListの中でプレゼンテーションタイムスタンプによって参照されるアクセスユニットのAVストリームの中のデータアドレスを見つけるために使用される。第2に、ファーストフォワード再生やファーストリバース再生のために使用される。記録再生装置1が、入力AVストリームを記録する場合、そのストリームのシンタクスを解析することができるとき、EPmapが作成され、ディスクに記録される。TUmapは、デジタルインタフェースを通して入力されるトランスポートパケットの到着時刻に基づいたタイムユニットTUデータのリストを持つ。これは、到着時刻ベースの時間とAVストリームの中のデータアドレスとの関係を与える。記録再生装置1が、入力AVストリームを記録する場合、そのストリームのシンタクスを解析することができないとき、TUmapが作成され、ディスクに記録される。STCInfoは、MPEG2トランスポートストリームをストアしているAVストリームファイルの中にあるSTCの不連続点情報をストアする。AVストリームがSTCの不連続点を持つ場合、そのAVストリームファイルの中で同じ値のPTSが現れるかもしれない。そのため、AVストリーム上のある時刻をPTSベースで指す場合、アクセスポイントのPTSだけではそのポイントを特定するためには不十分である。更に、そのPTSを含むところの連続なSTC区間のインデックスが必要である。連続なSTC区間を、このフォーマットではSTCsequenceと呼び、そのインデックスをSTCsequenceidと呼ぶ。STCsequenceの情報は、ClipInformationfileのSTCInfoで定義される。STCsequenceidは、EPmapを持つAVストリームファイルで使用するものであり、TUmapを持つAVストリームファイルではオプションである。プログラムは、エレメンタリーストリームの集まりであり、これらのストリームの同期再生のために、ただ1つのシステムタイムベースを共有するものである。再生装置図1の記録再生装置1にとって、AVストリームのデコードに先だち、そのAVストリームの内容がわかることは有用である。例えば、ビデオやオーディオのエレメンタリーストリームを伝送するトランスポートパケットのPIDの値や、ビデオやオーディオのコンポーネント種類例えば、HDTVのビデオとMPEG2AACのオーディオストリームなどなどの情報である。この情報はAVストリームを参照するところのPlayListの内容をユーザに説明するところのメニュー画面を作成するのに有用であるし、また、AVストリームのデコードに先だって、再生装置のAVデコーダおよびデマルチプレクサの初期状態をセットするために役立つ。この理由のために、ClipInformationfileは、プログラムの内容を説明するためのProgramInfoを持つ。MPEG2トランスポートストリームをストアしているAVストリームファイルは、ファイルの中でプログラム内容が変化するかもしれない。例えば、ビデオエレメンタリーストリームを伝送するところのトランスポートパケットのPIDが変化したり、ビデオストリームのコンポーネント種類がSDTVからHDTVに変化するなどである。ProgramInfoは、AVストリームファイルの中でのプログラム内容の変化点の情報をストアする。AVストリームファイルの中で、このフォーマットで定めるところのプログラム内容が一定である区間をProgramsequenceと呼ぶ。Programsequenceは、EPmapを持つAVストリームファイルで使用するものであり、TUmapを持つAVストリームファイルではオプションである。本実施の形態では、セルフエンコードのストリームフォーマットSESFを定義する。SESFは、アナログ入力信号を符号化する目的、およびデジタル入力信号例えばDVをデコードしてからMPEG2トランスポートストリームに符号化する場合に用いられる。SESFは、MPEG2トランスポートストリームおよびAVストリームについてのエレメンタリーストリームの符号化制限を定義する。記録再生装置1が、SESFストリームをエンコードし、記録する場合、EPmapが作成され、ディスクに記録される。デジタル放送のストリームは、次に示す方式のうちのいずれかが用いられて記録媒体100に記録される。まず、デジタル放送のストリームをSESFストリームにトランスコーディングする。この場合、記録されたストリームは、SESFに準拠しなければならない。この場合、EPmapが作成されて、ディスクに記録されなければならない。あるいは、デジタル放送のストリームを構成するエレメンタリーストリームを新しいエレメンタリーストリームにトランスコーディングし、そのデジタル放送ストリームの規格化組織が定めるストリームフォーマットに準拠した新しいトランスポートストリームに再多重化する。この場合、EPmapが作成されて、ディスクに記録されなければならない。例えば、入力ストリームがISDB日本のデジタルBS放送の規格名称準拠のMPEG2トランスポートストリームであり、それがHDTVビデオストリームとMPEGAACオーディオストリームを含むとする。HDTVビデオストリームをSDTVビデオストリームにトランスコーディングし、そのSDTVビデオストリームとオリジナルのAACオーディオストリームをTSに再多重化する。SDTVストリームと記録されるトランスポートストリームは、共にISDBフォーマットに準拠しなければならない。デジタル放送のストリームが、記録媒体100に記録される際の他の方式として、入力トランスポートストリームをトランスペアレントに記録する入力トランスポートストリームを何も変更しないで記録する場合であり、ストリームのシンタクスを解析することができるときに、EPmapが作成されてディスクに記録される。または、入力トランスポートストリームをトランスペアレントに記録する入力トランスポートストリームを何も変更しないで記録する場合であり、ストリームのシンタクスを解析することができないときに、TUmapが作成されてディスクに記録される。次にディレクトリとファイルについて説明する。以下、記録再生装置1をDVRDigitalVideoRecordingと適宜記述する。図14はディスク上のディレクトリ構造の一例を示す図である。DVRのディスク上に必要なディレクトリは、図14に示したように、DVRディレクトリを含むrootディレクトリ、PLAYLISTディレクトリ、CLIPINFディレクトリ、M2TSディレクトリ、およびDATAディレクトリを含むDVRディレクトリである。rootディレクトリの下に、これら以外のディレクトリを作成されるようにしても良いが、それらは、本実施の形態のアプリケーションフォーマットでは、無視されるとする。DVRディレクトリの下には、DVRアプリケーションフォーマットによって規定される全てのファイルとディレクトリがストアされる。DVRディレクトリは、4個のディレクトリを含む。PLAYLISTディレクトリの下には、RealPlayListとVirtualPlayListのデータベースファイルが置かれる。このディレクトリは、PlayListが1つもなくても存在する。CLIPINFディレクトリの下には、Clipのデータベースが置かれる。このディレクトリも、Clipが1つもなくても存在する。M2TSディレクトリの下には、AVストリームファイルが置かれる。このディレクトリは、AVストリームファイルが1つもなくても存在する。DATAディレクトリは、デジタルTV放送などのデータ放送のファイルがストアされる。DVRディレクトリは、次に示すファイルをストアする。infodvrファイルは、DVRディレクトリの下に作られ、アプリケーションレイヤの全体的な情報をストアする。DVRディレクトリの下には、ただ1つのinfodvrがなければならない。ファイル名は、infodvrに固定されるとする。menuthmbファイルは、メニューサムネイル画像に関連する情報をストアする。DVRディレクトリの下には、ゼロまたは1つのメニューサムネイルがなければならない。ファイル名は、memuthmbに固定されるとする。メニューサムネイル画像が1つもない場合、このファイルは、存在しなくても良い。markthmbファイルは、マークサムネイル画像に関連する情報をストアする。DVRディレクトリの下には、ゼロまたは1つのマークサムネイルがなければならない。ファイル名は、markthmbに固定されるとする。メニューサムネイル画像が1つもない場合、このファイルは、存在しなくても良い。PLAYLISTディレクトリは、2種類のPlayListファイルをストアするものであり、それらは、RealPlayListとVirtualPlayListである。xxxxxrplsファイルは、1つのRealPlayListに関連する情報をストアする。それぞれのRealPlayList毎に、1つのファイルが作られる。ファイル名は、xxxxxrplsである。ここで、xxxxxは、5個の0乃至9まで数字である。ファイル拡張子は、rplsでなければならないとする。yyyyyvplsファイルは、1つのVirtualPlayListに関連する情報をストアする。それぞれのVirtualPlayList毎に、1つのファイルが作られる。ファイル名は、yyyyyvplsである。ここで、yyyyyは、5個の0乃至9まで数字である。ファイル拡張子は、vplsでなければならないとする。CLIPINFディレクトリは、それぞれのAVストリームファイルに対応して、1つのファイルをストアする。zzzzzclpiファイルは、1つのAVストリームファイルに対応するClipInformationfileである。ファイル名は、zzzzzclpiであり、zzzzzは、5個の0乃至9までの数字である。ファイル拡張子は、clpiでなければならないとする。M2TSディレクトリは、AVストリームのファイルをストアする。zzzzzm2tsファイルは、DVRシステムにより扱われるAVストリームファイルである。これは、ClipAVstreamfileまたはBridgeClipAVstreamである。ファイル名は、zzzzzm2tsであり、zzzzzは、5個の0乃至9までの数字である。ファイル拡張子は、m2tsでなければならないとする。DATAディレクトリは、データ放送から伝送されるデータをストアするものであり、データとは、例えば、XMLfileやMHEGファイルなどである。次に、各ディレクトリファイルのシンタクスとセマンティクスを説明する。まず、infodvrファイルについて説明する。図15は、infodvrファイルのシンタクスを示す図である。infodvrファイルは、3個のオブジェクトから構成され、それらは、DVRVolume、TableOfPlayLists、およびMakerPrivateDataである。図15に示したinfodvrのシンタクスについて説明するに、TableOfPlayListsStartaddressは、infodvrファイルの先頭のバイトからの相対バイト数を単位として、TableOfPlayListの先頭アドレスを示す。相対バイト数はゼロからカウントされる。MakerPrivateDataStartaddressは、infodvrファイルの先頭のバイトからの相対バイト数を単位として、MakerPrivateDataの先頭アドレスを示す。相対バイト数はゼロからカウントされる。paddingwordパディングワードは、infodvrのシンタクスに従って挿入される。N1とN2は、ゼロまたは任意の正の整数である。それぞれのパディングワードは、任意の値を取るようにしても良い。DVRVolumeは、ボリュームディスクの内容を記述する情報をストアする。図16は、DVRVolumeのシンタクスを示す図である。図16に示したDVRVolumeのシンタクスを説明するに、versionnumberは、このDVRVolumeのバージョンナンバを示す4個のキャラクター文字を示す。versionnumberは、ISO646に従って、0045と符号化される。lengthは、このlengthフィールドの直後からDVRVolumeの最後までのDVRVolumeのバイト数を示す32ビットの符号なし整数で表される。ResumeVolumeは、ボリュームの中で最後に再生したRealPlayListまたはVirtualPlayListのファイル名を記憶している。ただし、RealPlayListまたはVirtualPlayListの再生をユーザが中断した時の再生位置は、PlayListMarkにおいて定義されるresumemarkにストアされる。図17は、ResumeVolumeのシンタクスを示す図である。図17に示したResumeVolumeのシンタクスを説明するに、validflagは、この1ビットのフラグが1にセットされている場合、resumePlayListnameフィールドが有効であることを示し、このフラグが0にセットされている場合、resumePlayListnameフィールドが無効であることを示す。resumePlayListnameの10バイトのフィールドは、リジュームされるべきRealPlayListまたはVirtualPlayListのファイル名を示す。図16に示したDVRVolumeのシンタクスのなかの、UIAppInfoVolumeは、ボリュームについてのユーザインターフェースアプリケーションのパラメータをストアする。図18は、UIAppInfoVolumeのシンタクスを示す図であり、そのセマンティクスを説明するに、charactersetの8ビットのフィールドは、Volumenameフィールドに符号化されているキャラクター文字の符号化方法を示す。その符号化方法は、図19に示される値に対応する。namelengthの8ビットフィールドは、Volumenameフィールドの中に示されるボリューム名のバイト長を示す。Volumenameのフィールドは、ボリュームの名称を示す。このフィールドの中の左からnamelength数のバイト数が、有効なキャラクター文字であり、それはボリュームの名称を示す。Volumenameフィールドの中で、それら有効なキャラクター文字の後の値は、どんな値が入っていても良い。Volumeprotectflagは、ボリュームの中のコンテンツを、ユーザに制限することなしに見せてよいかどうかを示すフラグである。このフラグが1にセットされている場合、ユーザが正しくPIN番号パスワードを入力できたときだけ、そのボリュームのコンテンツを、ユーザに見せる事再生される事が許可される。このフラグが0にセットされている場合、ユーザがPIN番号を入力しなくても、そのボリュームのコンテンツを、ユーザに見せる事が許可される。最初に、ユーザが、ディスクをプレーヤへ挿入した時点において、もしこのフラグが0にセットされているか、または、このフラグが1にセットされていてもユーザがPIN番号を正しく入力できたならば、記録再生装置1は、そのディスクの中のPlayListの一覧を表示させる。それぞれのPlayListの再生制限は、volumeprotectflagとは無関係であり、それはUIAppInfoPlayListの中に定義されるplaybackcontrolflagによって示される。PINは、4個の0乃至9までの数字で構成され、それぞれの数字は、ISOIEC646に従って符号化される。refthumbnailindexのフィールドは、ボリュームに付加されるサムネイル画像の情報を示す。refthumbnailindexフィールドが、0xFFFFでない値の場合、そのボリュームにはサムネイル画像が付加されており、そのサムネイル画像は、menuthumファイルの中にストアされている。その画像は、menuthumファイルの中でrefthumbnailindexの値を用いて参照される。refthumbnailindexフィールドが、0xFFFFである場合、そのボリュームにはサムネイル画像が付加されていないことを示す。次に図15に示したinfodvrのシンタクス内のTableOfPlayListsについて説明する。TableOfPlayListsは、PlayListのファイル名をストアする。ボリュームに記録されているすべてのPlayListファイルは、TableOfPlayListの中に含まれる。TableOfPlayListsは、ボリュームの中のPlayListのデフォルトの再生順序を示す。図20は、TableOfPlayListsのシンタクスを示す図であり、そのシンタクスについて説明するに、TableOfPlayListsのversionnumberは、このTableOfPlayListsのバージョンナンバーを示す4個のキャラクター文字を示す。versionnumberは、ISO646に従って、0045と符号化されなければならない。lengthは、このlengthフィールドの直後からTableOfPlayListsの最後までのTableOfPlayListsのバイト数を示す32ビットの符号なしの整数である。numberofPlayListsの16ビットのフィールドは、PlayListfilenameを含むforloopのループ回数を示す。この数字は、ボリュームに記録されているPlayListの数に等しくなければならない。PlayListfilenameの10バイトの数字は、PlayListのファイル名を示す。図21は、TableOfPlayListsのシンタクスを別実施の構成を示す図である。図21に示したシンタクスは、図20に示したシンタクスに、UIAppinfoPlayList後述を含ませた構成とされている。このように、UIAppinfoPlayListを含ませた構成とすることで、TableOfPlayListsを読み出すだけで、メニュー画面を作成することが可能となる。ここでは、図20に示したシンタクスを用いるとして以下の説明をする。図15に示したinfodvrのシンタクス内のMakersPrivateDataについて説明する。MakersPrivateDataは、記録再生装置1のメーカが、各社の特別なアプリケーションのために、MakersPrivateDataの中にメーカのプライベートデータを挿入できるように設けられている。各メーカのプライベートデータは、それを定義したメーカを識別するために標準化されたmakerIDを持つ。MakersPrivateDataは、1つ以上のmakerIDを含んでも良い。所定のメーカが、プライベートデータを挿入したい時に、すでに他のメーカのプライベートデータがMakersPrivateDataに含まれていた場合、他のメーカは、既にある古いプライベートデータを消去するのではなく、新しいプライベートデータをMakersPrivateDataの中に追加するようにする。このように、本実施の形態においては、複数のメーカのプライベートデータが、1つのMakersPrivateDataに含まれることが可能であるようにする。図22は、MakersPrivateDataのシンタクスを示す図である。図22に示したMakersPrivateDataのシンタクスについて説明するに、versionnumberは、このMakersPrivateDataのバージョンナンバを示す4個のキャラクター文字を示す。versionnumberは、ISO646に従って、0045と符号化されなければならない。lengthは、このlengthフィールドの直後からMakersPrivateDataの最後までのMakersPrivateDataのバイト数を示す32ビットの符号なし整数を示す。mpdblocksstartaddressは、MakersPrivateDataの先頭のバイトからの相対バイト数を単位として、最初のmpdblockの先頭バイトアドレスを示す。相対バイト数はゼロからカウントされる。numberofmakerentriesは、MakersPrivateDataの中に含まれているメーカプライベートデータのエントリー数を与える16ビットの符号なし整数である。MakersPrivateDataの中に、同じmakerIDの値を持つメーカプライベートデータが2個以上存在してはならない。mpdblocksizeは、1024バイトを単位として、1つのmpdblockの大きさを与える16ビットの符号なし整数である。例えば、mpdblocksize1ならば、それは1つのmpdblockの大きさが1024バイトであることを示す。numberofmpdblocksは、MakersPrivateDataの中に含まれるmpdblockの数を与える16ビットの符号なし整数である。makerIDは、そのメーカプライベートデータを作成したDVRシステムの製造メーカを示す16ビットの符号なし整数である。makerIDに符号化される値は、このDVRフォーマットのライセンサによって指定される。makermodelcodeは、そのメーカプライベートデータを作成したDVRシステムのモデルナンバーコードを示す16ビットの符号なし整数である。makermodelcodeに符号化される値は、このフォーマットのライセンスを受けた製造メーカによって設定される。startmpdblocknumberは、そのメーカプライベートデータが開始されるmpdblockの番号を示す16ビットの符号なし整数である。メーカプライベートデータの先頭データは、mpdblockの先頭にアラインされなければならない。startmpdblocknumberは、mpdblockのforloopの中の変数jに対応する。mpdlengthは、バイト単位でメーカプライベートデータの大きさを示す32ビットの符号なし整数である。mpdblockは、メーカプライベートデータがストアされる領域である。MakersPrivateDataの中のすべてのmpdblockは、同じサイズでなければならない。次に、RealPlayListfileとVirtualPlayListfileについて、換言すれば、xxxxxrplsとyyyyyvplsについて説明する。図23は、xxxxxrplsRealPlayList、または、yyyyyvplsVirtualPlayListのシンタクスを示す図である。xxxxxrplsとyyyyyvplsは、同一のシンタクス構成をもつ。xxxxxrplsとyyyyyvplsは、それぞれ、3個のオブジェクトから構成され、それらは、PlayList、PlayListMark、およびMakerPrivateDataである。PlayListMarkStartaddressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListMarkの先頭アドレスを示す。相対バイト数はゼロからカウントされる。MakerPrivateDataStartaddressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、MakerPrivateDataの先頭アドレスを示す。相対バイト数はゼロからカウントされる。paddingwordパディングワードは、PlayListファイルのシンタクスにしたがって挿入され、N1とN2は、ゼロまたは任意の正の整数である。それぞれのパディングワードは、任意の値を取るようにしても良い。ここで、既に、簡便に説明したが、PlayListについてさらに説明する。ディスク内にあるすべてのRealPlayListによって、BridgeClip後述を除くすべてのClipの中の再生区間が参照されていなければならない。かつ、2つ以上のRealPlayListが、それらのPlayItemで示される再生区間を同一のClipの中でオーバーラップさせてはならない。図24を参照してさらに説明するに、図24Aに示したように、全てのClipは、対応するRealPlayListが存在する。この規則は、図24Bに示したように、編集作業が行われた後においても守られる。従って、全てのClipは、どれかしらのRealPlayListを参照することにより、必ず視聴することが可能である。図24Cに示したように、VirtualPlayListの再生区間は、RealPlayListの再生区間またはBridgeClipの再生区間の中に含まれていなければならない。どのVirtualPlayListにも参照されないBridgeClipがディスクの中に存在してはならない。RealPlayListは、PlayItemのリストを含むが、SubPlayItemを含んではならない。VirtualPlayListは、PlayItemのリストを含み、PlayListの中に示されるCPItypeがEPmaptypeであり、かつPlayListtypeが0ビデオとオーディオを含むPlayListである場合、VirtualPlayListは、ひとつのSubPlayItemを含む事ができる。本実施の形態におけるPlayListでは、SubPlayIteはオーディオのアフレコの目的にだけに使用される。そして、1つのVirtualPlayListが持つSubPlayItemの数は、0または1でなければならない。次に、PlayListについて説明する。図25は、PlayListのシンタクスを示す図である。図25に示したPlayListのシンタクスを説明するに、versionnumberは、このPlayListのバージョンナンバーを示す4個のキャラクター文字である。versionnumberは、ISO646に従って、0045と符号化されなければならない。lengthは、このlengthフィールドの直後からPlayListの最後までのPlayListのバイト数を示す32ビットの符号なし整数である。PlayListtypeは、このPlayListのタイプを示す8ビットのフィールドであり、その一例を図26に示す。CPItypeは、1ビットのフラグであり、PlayItemおよびSubPlayItemによって参照されるClipのCPItypeの値を示す。1つのPlayListによって参照される全てのClipは、それらのCPIの中に定義されるCPItypeの値が同じでなければならない。numberofPlayItemsは、PlayListの中にあるPlayItemの数を示す16ビットのフィールドである。所定のPlayItemに対応するPlayItemidは、PlayItemを含むforloopの中で、そのPlayItemの現れる順番により定義される。PlayItemidは、0から開始される。numberofSubPlayItemsは、PlayListの中にあるSubPlayItemの数を示す16ビットのフィールドである。この値は、0または1である。付加的なオーディオストリームのパスで符号化したものである。例えば、20011223010203は、0x20011223010203と符号化される。durationは、PlayListの総再生時間を時間/分/秒の単位で示した24ビットのフィールドである。このフィールドは、6個の数字を4ビットのBinaryCodedDecimalで符号化したものである。例えば、014530は、0x014530と符号化される。validperiodは、PlayListが有効である期間を示す32ビットのフィールドである。このフィールドは、8個の数字を4ビットのBinaryCodedDecimalで符号化したものである。例えば、記録再生装置1は、この有効期間の過ぎたPlayListを自動消去する、といったように用いられる。例えば、20010507は、0x20010507と符号化される。makeridは、そのPlayListを最後に更新したDVRプレーヤ記録再生装置1の製造者を示す16ビットの符号なし整数である。makeridに符号化される値は、DVRフォーマットのライセンサによって割り当てられる。makercodeは、そのPlayListを最後に更新したDVRプレーヤのモデル番号を示す16ビットの符号なし整数である。makercodeに符号化される値は、DVRフォーマットのライセンスを受けた製造者によって決められる。playbackcontrolflagのフラグが1にセットされている場合、ユーザが正しくPIN番号を入力できた場合にだけ、そのPlayListは再生される。このフラグが0にセットされている場合、ユーザがPIN番号を入力しなくても、ユーザは、そのPlayListを視聴することができる。writeprotectflagは、図28Aにテーブルを示すように、1にセットされている場合、writeprotectflagを除いて、そのPlayListの内容は、消去および変更されない。このフラグが0にセットされている場合、ユーザは、そのPlayListを自由に消去および変更できる。このフラグが1にセットされている場合、ユーザが、そのPlayListを消去、編集、または上書きする前に、記録再生装置1はユーザに再確認するようなメッセージを表示させる。writeprotectflagが0にセットされているRealPlayListが存在し、かつ、そのRealPlayListのClipを参照するVirtualPlayListが存在し、そのVirtualPlayListのwriteprotectflagが1にセットされていても良い。ユーザが、RealPlayListを消去しようとする場合、記録再生装置1は、そのRealPlayListを消去する前に、上記VirtualPlayListの存在をユーザに警告するか、または、そのRealPlayListをMinimizeする。isplayedflagは、図28Bに示すように、フラグが1にセットされている場合、そのPlayListは、記録されてから一度は再生されたことを示し、0にセットされている場合、そのPlayListは、記録されてから一度も再生されたことがないことを示す。archiveは、図28Cに示すように、そのPlayListがオリジナルであるか、コピーされたものであるかを示す2ビットのフィールドである。refthumbnailindexのフィールドは、PlayListを代表するサムネイル画像の情報を示す。refthumbnailindexフィールドが、0xFFFFでない値の場合、そのPlayListには、PlayListを代表するサムネイル画像が付加されており、そのサムネイル画像は、menuthumファイルの中にストアされている。その画像は、menuthumファイルの中でrefthumbnailindexの値を用いて参照される。refthumbnailindexフィールドが、0xFFFFである場合、そのPlayListには、PlayListを代表するサムネイル画像が付加されていない。次にPlayItemについて説明する。1つのPlayItemは、基本的に次のデータを含む。Clipのファイル名を指定するためのClipinformationfilename、Clipの再生区間を特定するためのINtimeとOUTtimeのペア、PlayListにおいて定義されるCPItypeがEPmaptypeである場合、INtimeとOUTtimeが参照するところのSTCsequenceid、および、先行するPlayItemと現在のPlayItemとの接続の状態を示すところのconnectionconditionである。PlayListが2つ以上のPlayItemから構成される時、それらのPlayItemはPlayListのグローバル時間軸上に、時間のギャップまたはオーバーラップなしに一列に並べられる。PlayListにおいて定義されるCPItypeがEPmaptypeであり、かつ現在のPlayItemがBridgeSequenceを持たない時、そのPlayItemにおいて定義されるINtimeとOUTtimeのペアは、STCsequenceidによって指定される同じSTC連続区間上の時間を指していなければならない。そのような例を図29に示す。図30は、PlayListにおいて定義されるCPItypeがEPmaptypeであり、かつ現在のPlayItemがBridgeSequenceを持つ時、次に説明する規則が適用される場合を示している。現在のPlayItemに先行するPlayItemのINtimeは、先行するPlayItemのSTCsequenceidによって指定されるSTC連続区間上の時間を指している。先行するPlayItemのOUTtime図の中でOUTtime1と示されているものは、現在のPlayItemのBridgeSequenceInfoの中で指定されるBridgeClipの中の時間を指している。このOUTtimeは、後述する符号化制限に従っていなければならない。現在のPlayItemのINtime図の中でINtime2と示されているものは、現在のPlayItemのBridgeSequenceInfoの中で指定されるBridgeClipの中の時間を指している。このINtimeも、後述する符号化制限に従っていなければならない。現在のPlayItemのOUTtimeは、現在のPlayItemのSTCsequenceidによって指定されるSTC連続区間上の時間を指している。図31に示すように、PlayListのCPItypeがTUmaptypeである場合、PlayItemのINtimeとOUTtimeのペアは、同じClipAVストリーム上の時間を指している。PlayItemのシンタクスは、図32に示すようになる。図32に示したPlayItemのシンタクスを説明するに、ClipInformationfilenameのフィールドは、ClipInformationfileのファイル名を示す。このClipInformationfileのClipInfoにおいて定義されるClipstreamtypeは、ClipAVstreamを示していなければならない。STCsequenceidは、8ビットのフィールドであり、PlayItemが参照するSTC連続区間のSTCsequenceidを示す。PlayListの中で指定されるCPItypeがTUmaptypeである場合、この8ビットフィールドは何も意味を持たず、0にセットされる。INtimeは、32ビットフィールドであり、PlayItemの再生開始時刻をストアする。INtimeのセマンティクスは、図33に示すように、PlayListにおいて定義されるCPItypeによって異なる。OUTtimeは、32ビットフィールドであり、PlayItemの再生終了時刻をストアする。OUTtimeのセマンティクスは、図34に示すように、PlayListにおいて定義されるCPItypeによって異なる。ConnectionConditionは、図35に示したような先行するPlayItemと、現在のPlayItemとの間の接続状態を示す2ビットのフィールドである。図36は、図35に示したConnectionConditionの各状態について説明する図である。次に、BridgeSequenceInfoについて、図37を参照して説明する。BridgeSequenceInfoは、現在のPlayItemの付属情報であり、次に示す情報を持つ。BridgeClipAVstreamファイルとそれに対応するClipInformationfileを指定するBridgeClipInformationfilenameを含む。また、先行するPlayItemが参照するClipAVstream上のソースパケットのアドレスであり、このソースパケットに続いてBridgeClipAVstreamファイルの最初のソースパケットが接続される。このアドレスは、RSPNexitfrompreviousClipと称される。さらに現在のPlayItemが参照するClipAVstream上のソースパケットのアドレスであり、このソースパケットの前にBridgeClipAVstreamファイルの最後のソースパケットが接続される。このアドレスは、RSPNentertocurrentClipと称される。図37において、RSPNarrivaltimediscontinuityは、theBridgeClipAVstreamファイルの中でアライバルタイムベースの不連続点があるところのソースパケットのアドレスを示す。このアドレスは、ClipInfoの中において定義される。図38は、BridgeSequenceinfoのシンタクスを示す図である。図38に示したBridgeSequenceinfoのシンタクスを説明するに、BridgeClipInformationfilenameのフィールドは、BridgeClipAVstreamファイルに対応するClipInformationfileのファイル名を示す。このClipInformationfileのClipInfoにおいて定義されるClipstreamtypeは、BridgeClipAVstreamを示していなければならない。RSPNexitfrompreviousClipの32ビットフィールドは、先行するPlayItemが参照するClipAVstream上のソースパケットの相対アドレスであり、このソースパケットに続いてBridgeClipAVstreamファイルの最初のソースパケットが接続される。RSPNexitfrompreviousClipは、ソースパケット番号を単位とする大きさであり、先行するPlayItemが参照するClipAVstreamファイルの最初のソースパケットからClipInfoにおいて定義されるoffsetSPNの値を初期値としてカウントされる。RSPNentertocurrentClipの32ビットフィールドは、現在のPlayItemが参照するClipAVstream上のソースパケットの相対アドレスであり、このソースパケットの前にBridgeClipAVstreamファイルの最後のソースパケットが接続される。RSPNexitfrompreviousClipは、ソースパケット番号を単位とする大きさであり、現在のPlayItemが参照するClipAVstreamファイルの最初のソースパケットからClipInfoにおいて定義されるoffsetSPNの値を初期値としてカウントされる。次に、SubPlayItemについて、図39を参照して説明する。SubPlayItemの使用は、PlayListのCPItypeがEPmaptypeである場合だけに許される。本実施の形態においては、SubPlayItemはオーディオのアフレコの目的のためだけに使用されるとする。SubPlayItemは、次に示すデータを含む。まず、PlayListの中のsubpathが参照するClipを指定するためのClipinformationfilenameを含む。また、Clipの中のsubpathの再生区間を指定するためのSubPathINtimeとSubPathOUTtimeを含む。さらに、mainpathの時間軸上でsubpathが再生開始する時刻を指定するためのsyncPlayItemidとsyncstartPTSofPlayItemを含む。subpathに参照されるオーディオのClipAVstreamは、STC不連続点システムタイムベースの不連続点を含んではならない。subpathに使われるClipのオーディオサンプルのクロックは、mainpathのオーディオサンプルのクロックにロックされている。図40は、SubPlayItemのシンタクスを示す図である。図40に示したSubPlayItemのシンタクスを説明するに、ClipInformationfilenameのフィールドは、ClipInformationfileのファイル名を示し、それはPlayListの中でsubpathによって使用される。このClipInformationfileのClipInfoにおいて定義されるClipstreamtypeは、ClipAVstreamを示していなければならない。SubPathtypeの8ビットのフィールドは、subpathのタイプを示す。ここでは、図41に示すように、0x00しか設定されておらず、他の値は、将来のために確保されている。syncPlayItemidの8ビットのフィールドは、mainpathの時間軸上でsubpathが再生開始する時刻が含まれるPlayItemのPlayItemidを示す。所定のPlayItemに対応するPlayItemidの値は、PlayListにおいて定義される図25参照。syncstartPTSofPlayItemの32ビットのフィールドは、mainpathの時間軸上でsubpathが再生開始する時刻を示し、syncPlayItemidで参照されるPlayItem上のPTSの上位32ビットを示す。SubPathINtimeの32ビットフィールドは、Subpathの再生開始時刻をストアする。SubPathINtimeは、SubPathの中で最初のプレゼンテーションユニットに対応する33ビット長のPTSの上位32ビットを示す。SubPathOUTtimeの32ビットフィールドは、Subpathの再生終了時刻をストアする。SubPathOUTtimeは、次式によって算出されるPresentationendTSの値の上位32ビットを示す。PresentationendTSPTSoutAUdurationここで、PTSoutは、SubPathの最後のプレゼンテーションユニットに対応する33ビット長のPTSである。AUdurationは、SubPathの最後のプレゼンテーションユニットの90kHz単位の表示期間である。次に、図23に示したxxxxxrplsとyyyyyvplsのシンタクス内のPlayListMarkについて説明する。PlayListについてのマーク情報は、このPlayListMarkにストアされる。図42は、PlayListMarkのシンタクスを示す図である。図42に示したPlayListMarkのシンタクスについて説明するに、versionnumberは、このPlayListMarkのバージョンナンバを示す4個のキャラクター文字である。versionnumberは、ISO646に従って、0045と符号化されなければならない。lengthは、このlengthフィールドの直後からPlayListMarkの最後までのPlayListMarkのバイト数を示す32ビットの符号なし整数である。numberofPlayListmarksは、PlayListMarkの中にストアされているマークの個数を示す16ビットの符号なし整数である。numberofPlayListmarksは、0であってもよい。marktypeは、マークのタイプを示す8ビットのフィールドであり、図43に示すテーブルに従って符号化される。marktimestampの32ビットフィールドは、マークが指定されたポイントを示すタイムスタンプをストアする。marktimestampのセマンティクスは、図44に示すように、PlayListにおいて定義されるCPItypeによって異なる。PlayItemidは、マークが置かれているところのPlayItemを指定する8ビットのフィールドである。所定のPlayItemに対応するPlayItemidの値は、PlayListにおいて定義される図25参照。charactersetの8ビットのフィールドは、marknameフィールドに符号化されているキャラクター文字の符号化方法を示す。その符号化方法は、図19に示した値に対応する。namelengthの8ビットフィールドは、Marknameフィールドの中に示されるマーク名のバイト長を示す。marknameのフィールドは、マークの名称を示す。このフィールドの中の左からnamelength数のバイト数が、有効なキャラクター文字であり、それはマークの名称を示す。Marknameフィールドの中で、それら有効なキャラクター文字の後の値は、どのような値が設定されても良い。refthumbnailindexのフィールドは、マークに付加されるサムネイル画像の情報を示す。refthumbnailindexフィールドが、0xFFFFでない値の場合、そのマークにはサムネイル画像が付加されており、そのサムネイル画像は、markthmbファイルの中にストアされている。その画像は、markthmbファイルの中でrefthumbnailindexの値を用いて参照される後述。refthumbnailindexフィールドが、0xFFFFである場合、そのマークにはサムネイル画像が付加されていない事を示す。次に、Clipinformationfileについて説明する。zzzzzclpiClipinformationfileファイルは、図45に示すように6個のオブジェクトから構成される。それらは、ClipInfo、STCInfo、ProgramInfo、CPI、ClipMark、およびMakerPrivateDataである。AVストリームとそれに対応するClipInformationファイルは、同じ数字列のzzzzzが使用される。図45に示したzzzzzclpiClipinformationfileファイルのシンタクスについて説明するに、ClipInfoStartaddressは、zzzzzclpiファイルの先頭のバイトからの相対バイト数を単位として、ClipInfoの先頭アドレスを示す。相対バイト数はゼロからカウントされる。STCInfoStartaddressは、zzzzzclpiファイルの先頭のバイトからの相対バイト数を単位として、STCInfoの先頭アドレスを示す。相対バイト数はゼロからカウントされる。ProgramInfoStartaddressは、zzzzzclpiファイルの先頭のバイトからの相対バイト数を単位として、ProgramInfoの先頭アドレスを示す。相対バイト数はゼロからカウントされる。CPIStartaddressは、zzzzzclpiファイルの先頭のバイトからの相対バイト数を単位として、CPIの先頭アドレスを示す。相対バイト数はゼロからカウントされる。ClipMarkStartaddressは、zzzzzclpiファイルの先頭のバイトからの相対バイト数を単位として、ClipMarkの先頭アドレスを示す。相対バイト数はゼロからカウントされる。MakerPrivateDataStartaddressは、zzzzzclpiファイルの先頭のバイトからの相対バイト数を単位として、MakerPrivateDataの先頭アドレスを示す。相対バイト数はゼロからカウントされる。paddingwordパディングワードは、zzzzzclpiファイルのシンタクスにしたがって挿入される。N1,N2,N3,N4、およびN5は、ゼロまたは任意の正の整数でなければならない。それぞれのパディングワードは、任意の値がとられるようにしても良い。次に、ClipInfoについて説明する。図46は、ClipInfoのシンタクスを示す図である。ClipInfoは、それに対応するAVストリームファイルClipAVストリームまたはBridgeClipAVストリームファイルの属性情報をストアする。図46に示したClipInfoのシンタクスについて説明するに、versionnumberは、このClipInfoのバージョンナンバーを示す4個のキャラクター文字である。versionnumberは、ISO646に従って、0045と符号化されなければならない。lengthは、このlengthフィールドの直後からClipInfoの最後までのClipInfoのバイト数を示す32ビットの符号なし整数である。Clipstreamtypeの8ビットのフィールドは、図47に示すように、ClipInformationファイルに対応するAVストリームのタイプを示す。それぞれのタイプのAVストリームのストリームタイプについては後述する。offsetSPNの32ビットのフィールドは、AVストリームClipAVストリームまたはBridgeClipAVストリームファイルの最初のソースパケットについてのソースパケット番号のオフセット値を与える。AVストリームファイルが最初にディスクに記録される時、このoffsetSPNは0でなければならない。図48に示すように、AVストリームファイルのはじめの部分が編集によって消去された時、offsetSPNは、ゼロ以外の値をとっても良い。本実施の形態では、offsetSPNを参照する相対ソースパケット番号相対アドレスが、しばしば、RSPNxxxxxxは変形する。例.RSPNEPstartの形式でシンタクスの中に記述されている。相対ソースパケット番号は、ソースパケット番号を単位とする大きさであり、AVストリームファイルの最初のソースパケットからoffsetSPNの値を初期値としてカウントされる。AVストリームファイルの最初のソースパケットから相対ソースパケット番号で参照されるソースパケットまでのソースパケットの数SPNxxxは、次式で算出される。SPNxxxRSPNxxxoffsetSPN図48に、offsetSPNが4である場合の例を示す。TSrecordingrateは、24ビットの符号なし整数であり、この値は、DVRドライブ書き込み部22へまたはDVRドライブ読み出し部28からのAVストリームの必要な入出力のビットレートを与える。recordtimeanddateは、Clipに対応するAVストリームが記録された時の日時をストアする56ビットのフィールドであり、年/月/日/時/分/秒について、14個の数字を4ビットのBinaryCodedDecimalで符号化したものである。例えば、20011223010203は、0x20011223010203と符号化される。durationは、Clipの総再生時間をアライバルタイムクロックに基づいた時間/分/秒の単位で示した24ビットのフィールドである。このフィールドは、6個の数字を4ビットのBinaryCodedDecimalで符号化したものである。例えば、014530は、0x014530と符号化される。timecontrolledflagのフラグは、AVストリームファイルの記録モードを示す。このtimecontrolledflagが1である場合、記録モードは、記録してからの時間経過に対してファイルサイズが比例するようにして記録されるモードであることを示し、次式に示す条件を満たさなければならない。TSaveragerate192188-α0個のSTC不連続点を含む場合、Clipのシステムタイムベースは、個のSTCsequenceに分割される。STCInfoは、STCの不連続システムタイムベースの不連続が発生する場所のアドレスをストアする。図51を参照して説明するように、RSPNSTCstartが、そのアドレスを示し、最後のSTCsequenceを除くk番目k0のSTCsequenceは、k番目のRSPNSTCstartで参照されるソースパケットが到着した時刻から始まり、番目のRSPNSTCstartで参照されるソースパケットが到着した時刻で終わる。最後のSTCsequenceは、最後のRSPNSTCstartで参照されるソースパケットが到着した時刻から始まり、最後のソースパケットが到着した時刻で終了する。図52は、STCInfoのシンタクスを示す図である。図52に示したSTCInfoのシンタクスについて説明するに、versionnumberは、このSTCInfoのバージョンナンバーを示す4個のキャラクター文字である。versionnumberは、ISO646に従って、0045と符号化されなければならない。lengthは、このlengthフィールドの直後からSTCInfoの最後までのSTCInfoのバイト数を示す32ビットの符号なし整数である。CPIのCPItypeがTUmaptypeを示す場合、このlengthフィールドはゼロをセットしても良い。CPIのCPItypeがEPmaptypeを示す場合、numofSTCsequencesは1以上の値でなければならない。numofSTCsequencesの8ビットの符号なし整数は、Clipの中でのSTCsequenceの数を示す。この値は、このフィールドに続くforloopのループ回数を示す。所定のSTCsequenceに対応するSTCsequenceidは、RSPNSTCstartを含むforloopの中で、そのSTCsequenceに対応するRSPNSTCstartの現れる順番により定義されるものである。STCsequenceidは、0から開始される。RSPNSTCstartの32ビットフィールドは、AVストリームファイル上でSTCsequenceが開始するアドレスを示す。RSPNSTCstartは、AVストリームファイルの中でシステムタイムベースの不連続点が発生するアドレスを示す。RSPNSTCstartは、AVストリームの中で新しいシステムタイムベースの最初のPCRを持つソースパケットの相対アドレスとしても良い。RSPNSTCstartは、ソースパケット番号を単位とする大きさであり、AVストリームファイルの最初のソースパケットからClipInfoにおいて定義されるoffsetSPNの値を初期値としてカウントされる。そのAVstreamファイルの中での絶対アドレスは、既に上述したSPNxxxRSPNxxxoffsetSPNにより算出される。次に、図45に示したzzzzzclipのシンタクス内のProgramInfoについて説明する。図53を参照しながら説明するに、ここでは、Clipの中で次の特徴をもつ時間区間をprogramsequenceと呼ぶ。まず、PCRPIDの値が変わらない。次に、ビデオエレメンタリーストリームの数が変化しない。また、それぞれのビデオストリームについてのPIDの値とそのVideoCodingInfoによって定義される符号化情報が変化しない。さらに、オーディオエレメンタリーストリームの数が変化しない。また、それぞれのオーディオストリームについてのPIDの値とそのAudioCodingInfoによって定義される符号化情報が変化しない。programsequenceは、同一の時刻において、ただ1つのシステムタイムベースを持つ。programsequenceは、同一の時刻において、ただ1つのPMTを持つ。ProgramInfoは、programsequenceが開始する場所のアドレスをストアする。RSPNprogramsequencestartが、そのアドレスを示す。図54は、ProgramInfoのシンタクスを示す図である。図54に示したProgramInfoのシンタクを説明するに、versionnumberは、このProgramInfoのバージョンナンバーを示す4個のキャラクター文字である。versionnumberは、ISO646に従って、0045と符号化されなければならない。lengthは、このlengthフィールドの直後からProgramInfoの最後までのProgramInfoのバイト数を示す32ビットの符号なし整数である。CPIのCPItypeがTUmaptypeを示す場合、このlengthフィールドはゼロにセットされても良い。CPIのCPItypeがEPmaptypeを示す場合、numberofprogramsは1以上の値でなければならない。numberofprogramsequencesの8ビットの符号なし整数は、Clipの中でのprogramsequenceの数を示す。この値は、このフィールドに続くforloopのループ回数を示す。Clipの中でprogramsequenceが変化しない場合、numberofprogramsequencesは1をセットされなければならない。RSPNprogramsequencestartの32ビットフィールドは、AVストリームファイル上でプログラムシーケンスが開始する場所の相対アドレスである。RSPNprogramsequencestartは、ソースパケット番号を単位とする大きさであり、AVストリームファイルの最初のソースパケットからClipInfoにおいて定義されるoffsetSPNの値を初期値としてカウントされる。そのAVストリームファイルの中での絶対アドレスは、SPNxxxRSPNxxxoffsetSPNにより算出される。シンタクスのforloopの中でRSPNprogramsequencestart値は、昇順に現れなければならない。PCRPIDの16ビットフィールドは、そのprogramsequenceに有効なPCRフィールドを含むトランスポートパケットのPIDを示す。numberofvideosの8ビットフィールドは、videostreamPIDとVideoCodingInfoを含むforloopのループ回数を示す。numberofaudiosの8ビットフィールドは、audiostreamPIDとAudioCodingInfoを含むforloopのループ回数を示す。videostreamPIDの16ビットフィールドは、そのprogramsequenceに有効なビデオストリームを含むトランスポートパケットのPIDを示す。このフィールドに続くVideoCodingInfoは、そのvideostreamPIDで参照されるビデオストリームの内容を説明しなければならない。audiostreamPIDの16ビットフィールドは、そのprogramsequenceに有効なオーディオストリームを含むトランスポートパケットのPIDを示す。このフィールドに続くAudioCodingInfoは、そのaudiostreamPIDで参照されるビデオストリームの内容を説明しなければならない。なお、シンタクスのforloopの中でvideostreamPIDの値の現れる順番は、そのprogramsequenceに有効なPMTの中でビデオストリームのPIDが符号化されている順番に等しくなければならない。また、シンタクスのforloopの中でaudiostreamPIDの値の現れる順番は、そのprogramsequenceに有効なPMTの中でオーディオストリームのPIDが符号化されている順番に等しくなければならない。図55は、図54に示したPrograminfoのシンタクス内のVideoCodingInfoのシンタクスを示す図である。図55に示したVideoCodingInfoのシンタクスを説明するに、videoformatの8ビットフィールドは、図56に示すように、ProgramInfoの中のvideostreamPIDに対応するビデオフォーマットを示す。framerateの8ビットフィールドは、図57に示すように、ProgramInfoの中のvideostreamPIDに対応するビデオのフレームレートを示す。displayaspectratioの8ビットフィールドは、図58に示すように、ProgramInfoの中のvideostreamPIDに対応するビデオの表示アスペクト比を示す。図59は、図54に示したPrograminfoのシンタクス内のAudioCodingInfoのシンタクスを示す図である。図59に示したAudioCodingInfoのシンタクスを説明するに、audiocodingの8ビットフィールドは、図60に示すように、ProgramInfoの中のaudiostreamPIDに対応するオーディオの符号化方法を示す。audiocomponenttypeの8ビットフィールドは、図61に示すように、ProgramInfoの中のaudiostreamPIDに対応するオーディオのコンポーネントタイプを示す。samplingfrequencyの8ビットフィールドは、図62に示すように、ProgramInfoの中のaudiostreamPIDに対応するオーディオのサンプリング周波数を示す。次に、図45に示したzzzzzclipのシンタクス内のCPIについて説明する。CPIは、AVストリームの中の時間情報とそのファイルの中のアドレスとを関連づけるためにある。CPIには2つのタイプがあり、それらはEPmapとTUmapである。図63に示すように、CPIの中のCPItypeがEPmaptypeの場合、そのCPIはEPmapを含む。図64に示すように、CPIの中のCPItypeがTUmaptypeの場合、そのCPIはTUmapを含む。1つのAVストリームは、1つのEPmapまたは1つのTUmapを持つ。AVストリームがSESFトランスポートストリームの場合、それに対応するClipはEPmapを持たなければならない。図65は、CPIのシンタクスを示す図である。図65に示したCPIのシンタクスを説明するに、versionnumberは、このCPIのバージョンナンバを示す4個のキャラクター文字である。versionnumberは、ISO646に従って、0045と符号化されなければならない。lengthは、このlengthフィールドの直後からCPIの最後までのCPIのバイト数を示す32ビットの符号なし整数である。CPItypeは、図66に示すように、1ビットのフラグであり、ClipのCPIのタイプを表す。次に、図65に示したCPIのシンタクス内のEPmapについて説明する。EPmapには、2つのタイプがあり、それはビデオストリーム用のEPmapとオーディオストリーム用のEPmapである。EPmapの中のEPmaptypeが、EPmapのタイプを区別する。Clipが1つ以上のビデオストリームを含む場合、ビデオストリーム用のEPmapが使用されなければならない。Clipがビデオストリームを含まず、1つ以上のオーディオストリームを含む場合、オーディオストリーム用のEPmapが使用されなければならない。ビデオストリーム用のEPmapについて図67を参照して説明する。ビデオストリーム用のEPmapは、streamPID、PTstart、および、RSPNEPstartというデータを持つ。streamPIDは、ビデオストリームを伝送するトランスポートパケットのPIDを示す。PTstartは、ビデオストリームのシーケンスヘッダから始めるアクセスユニットのPTSを示す。RSPNEPstartは、AVストリームの中でPTstartにより参照されるアクセスユニットの第1バイト目を含むソースポケットのアドレスを示す。EPmapforonestreamPIDと呼ばれるサブテーブルは、同じPIDを持つトランスポートパケットによって伝送されるビデオストリーム毎に作られる。Clipの中に複数のビデオストリームが存在する場合、EPmapは複数のEPmapforonestreamPIDを含んでも良い。オーディオストリーム用のEPmapは、streamPID、PTstart、およびRSPNEPstartというデータを持つ。streamPIDは、オーディオストリームを伝送するトランスポートパケットのPIDを示す。PTstartは、オーディオストリームのアクセスユニットのPTSを示す。RSPNEPstartは、AVストリームの中でPTstartで参照されるアクセスユニットの第1バイト目を含むソースポケットのアドレスを示す。EPmapforonestreamPIDと呼ばれるサブテーブルは、同じPIDを持つトランスポートパケットによって伝送されるオーディオストリーム毎に作られる。Clipの中に複数のオーディオストリームが存在する場合、EPmapは複数のEPmapforonestreamPIDを含んでも良い。EPmapとSTCInfoの関係を説明するに、1つのEPmapforonestreamPIDは、STCの不連続点に関係なく1つのテーブルに作られる。RSPNEPstartの値とSTCInfoにおいて定義されるRSPNSTCstartの値を比較する事により、それぞれのSTCsequenceに属するEPmapのデータの境界が分かる図68を参照。EPmapは、同じPIDで伝送される連続したストリームの範囲に対して、1つのEPmapforonestreamPIDを持たねばならない。図69に示したような場合、program1とprogram3は、同じビデオPIDを持つが、データ範囲が連続していないので、それぞれのプログラム毎にEPmapforonestreamPIDを持たねばならない。図70は、EPmapのシンタクスを示す図である。図70に示したEPmapのシンタクスを説明するに、EPtypeは、4ビットのフィールドであり、図71に示すように、EPmapのエントリーポイントタイプを示す。EPtypeは、このフィールドに続くデータフィールドのセマンティクスを示す。Clipが1つ以上のビデオストリームを含む場合、EPtypeは0にセットされなければならない。または、Clipがビデオストリームを含まず、1つ以上のオーディオストリームを含む場合、EPtypeは1にセットされなければならない。numberofstreamPIDsの16ビットのフィールドは、EPmapの中のnumberofstreamPIDsを変数にもつforloopのループ回数を示す。streamPIDの16ビットのフィールドは、EPmapforonestreamPIDによって参照されるk番目のエレメンタリーストリームビデオまたはオーディオストリームを伝送するトランスポートパケットのPIDを示す。EPtypeが0に等しい場合、そのエレメンタリーストリームはビデオストリームでなけれならない。また、EPtypeが1に等しい場合、そのエレメンタリーストリームはオーディオストリームでなければならない。numEPentriesの16ビットのフィールドは、EPmapforonestreamPIDによって参照されるnumEPentriesを示す。EPmapforonestreamPIDStartaddressこの32ビットのフィールドは、EPmapの中でEPmapforonestreamPIDが始まる相対バイト位置を示す。この値は、EPmapの第1バイト目からの大きさで示される。paddingwordは、EPmapのシンタクスにしたがって挿入されなければならない。XとYは、ゼロまたは任意の正の整数でなければならない。それぞれのパディングワードは、任意の値を取っても良い。図72は、EPmapforonestreamPIDのシンタクスを示す図である。図72に示したEPmapforonestreamPIDのシンタクスを説明するに、PTstartの32ビットのフィールドのセマンティクスは、EPmapにおいて定義されるEPtypeにより異なる。EPtypeが0に等しい場合、このフィールドは、ビデオストリームのシーケンスヘッダで始まるアクセスユニットの33ビット精度のPTSの上位32ビットを持つ。EPtypeが1に等しい場合、このフィールドは、オーディオストリームのアクセスユニットの33ビット精度のPTSの上位32ビットを持つ。RSPNEPstartの32ビットのフィールドのセマンティクスは、EPmapにおいて定義されるEPtypeにより異なる。EPtypeが0に等しい場合、このフィールドは、AVストリームの中でPTstartにより参照されるアクセスユニットのシーケンスヘッダの第1バイト目を含むソースポケットの相対アドレスを示す。または、EPtypeが1に等しい場合、このフィールドは、AVストリームの中でPTstartにより参照されるアクセスユニットのオーディオフレームの第一バイト目を含むソースポケットの相対アドレスを示す。RSPNEPstartは、ソースパケット番号を単位とする大きさであり、AVストリームファイルの最初のソースパケットからClipInfoにおいて定義されるoffsetSPNの値を初期値としてカウントされる。そのAVストリームファイルの中での絶対アドレスは、SPNxxxRSPNxxxoffsetSPNにより算出される。シンタクスのforloopの中でRSPNEPstartの値は、昇順に現れなければならない。次に、TUmapについて、図73を参照して説明する。TUmapは、ソースパケットのアライバルタイムクロック到着時刻ベースの時計に基づいて、1つの時間軸を作る。その時間軸は、TUmaptimeaxisと呼ばれる。TUmaptimeaxisの原点は、TUmapの中のoffsettimeによって示される。TUmaptimeaxisは、offsettimeから一定の単位に分割される。その単位を、timeunitと称する。AVストリームの中の各々のtimeunitの中で、最初の完全な形のソースパケットのAVストリームファイル上のアドレスが、TUmapにストアされる。これらのアドレスを、RSPNtimeunitstartと称する。TUmaptimeaxis上において、k番目のtimeunitが始まる時刻は、TUstarttimeと呼ばれる。この値は次式に基づいて算出される。TUstarttimeoffsettimektimeunitsizeTUstarttimeは、45kHzの精度を持つ。図74は、TUmapのシンタクスを示す図である。図74に示したTUmapのシンタクスを説明するに、offsettimeの32bit長のフィールドは、TUmaptimeaxisに対するオフセットタイムを与える。この値は、Clipの中の最初のtimeunitに対するオフセット時刻を示す。offsettimeは、27MHz精度のアライバルタイムクロックから導き出される45kHzクロックを単位とする大きさである。AVストリームが新しいClipとして記録される場合、offsettimeはゼロにセットされなければならない。timeunitsizeの32ビットフィールドは、timeunitの大きさを与えるものであり、それは27MHz精度のアライバルタイムクロックから導き出される45kHzクロックを単位とする大きさである。timeunitsizeは、1秒以下timeunitsizeSTC21videoendΔT1この不等式が満たされるように、Clip1および、または、Clip2の部分的なストリームを再エンコードおよび、または、再多重化する必要がある場合は、その必要に応じて行われる。次に、STC1とSTC2を同じ時間軸上に換算したシステムタイムベースの時間軸上において、TS1からのビデオパケットの入力とそれに続くTS2からのビデオパケットの入力は、ビデオバッファをオーバーフロウおよびアンダーフローさせてはならない。このようなシンタクス、データ構造、規則に基づく事により、記録媒体に記録されているデータの内容、再生情報などを適切に管理することができ、もって、ユーザが再生時に適切に記録媒体に記録されているデータの内容を確認したり、所望のデータを簡便に再生できるようにすることができる。なお、本実施の形態は、多重化ストリームとしてMPEG2トランスポートストリームを例にして説明しているが、これに限らず、MPEG2プログラムストリームや米国のDirecTVサービス商標で使用されているDSSトランスポートストリームについても適用することが可能である。次に、図98は、PlayListファイルの別の例を示す。図98と図23のシンタクスの大きな違いは、UIAppInfoPlayListをストアしている場所である。図98の例では、UIAppInfoPlayListがPlayListの中から外に出されているので、UIAppInfoPlayListの将来の情報拡張が比較的容易に行えるようになる。versionnumberは、このサムネールヘッダ情報ファイルのバージョンナンバーを示す4個の数字である。PlayListstartaddressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListの先頭アドレスを示す。相対バイト数はゼロからカウントされる。PlayListMarkstartaddressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、PlayListMarkの先頭アドレスを示す。相対バイト数はゼロからカウントされる。MakersPrivateDatastartaddressは、PlayListファイルの先頭のバイトからの相対バイト数を単位として、MakersPrivateDataの先頭アドレスを示す。相対バイト数はゼロからカウントされる。図99は、図98のPlayListファイルの中のUIAppInfoPlayListのシンタクスを示す。PlayListservicetypeは、PlayListファイルのタイプを示す。その一例は、図26に示されている。また、PlayListservicetypeは、ディジタルTV放送のプログラムが示すサービスタイプと同じ意味を持たせても良い。例えば、日本のディジタルBS放送の場合、サービスタイプは、テレビサービス、音声サービス、およびデータ放送サービスの3種類を持つ。PlayListが使用するClipAVストリームが含むプログラムのサービスタイプを代表する値をPlayListservicetypeにセットする。PlayListcharactersetは、channelnamePlayListnameおよびPlayListdetailフィールドに符号化されているキャラクター文字の符号化方法を示す。また、これはPlayListMarkの中のmarknameフィールドに符号化されているキャラクター文字の符号化方法を示す。channelnumberは、そのPlayListが記録される時、ユーザによって選択された放送チャンネル番号またはサービス番号を示す。複数のPlayListが1つのPlayListにコンバインされた場合は、このフィールドはそのPlayListの代表値を示す。このフィールドが0xFFFFにセットされている場合、このフィールドは何も意味を持たない。channelnamelengthは、channelnameフィールドの中に示されるチャンネル名のバイト長を示す。このフィールドは、20以下の値である。channelnameは、そのPlayListが記録される時、ユーザによって選択された放送チャンネルまたはサービスの名前を示す。このフィールドの中の左からchannelnamelengthによって示される数のバイト数が有効なキャラクター文字であり、前記名前を示す。このフィールドの中で、それら有効なキャラクター文字に続く残りのバイトは、どんな値がセットされていても良い。複数のPlayListが1つのPlayListにコンバインされた場合は、このフィールドはそのPlayListを代表する名前を示す。PlayListnamelengthは、PlayListnameフィールドの中に示されるPlayList名のバイト長を示す。PlayListnameは、PlayListの名前を示す。このフィールドの中の左からPlayListnamelengthによって示される数のバイト数が有効なキャラクター文字であり、前記名前を示す。このフィールドの中で、それら有効なキャラクター文字に続く残りのバイトは、どんな値がセットされていても良い。PlayListdetaillengthは、PlayListdatailフィールドの中に示されるPlayListの詳細情報のバイト長を示す。このフィールドは、1200以下の値である。PlayListdetailは、PlayListの詳細情報を説明するテキストを示す。このフィールドの中の左からPlayListdetaillengthによって示される数のバイト数が有効なキャラクター文字であり、前記テキストを示す。このフィールドの中で、それら有効なキャラクター文字に続く残りのバイトは、どんな値がセットされていても良い。これ以外のシンタクスフィールドの意味は、図27に示す同名のフィールドと同じである。図100は、図98のPlayListファイルの中のPlayListのシンタクスを示す。図25の例と比べると、UIAppInfoPlayListがなくなった点が違うだけで、これ以外は基本的に同じである。図101は、SubPlayItemのシンタクスの別例を示す。図40の例と比べると、STCsequenceidが追加された点が大きな違いである。STCsequenceidは、ClipInformationfilenameに対応するAVストリームファイル上の再生区間を特定するためのSubPathINtimeとSubPathOUTtimeが参照するところのSTCのSTCsequenceidを示す。SubPathINtimeとSubPathOUTtimeは、STCsequenceidによって指定される同じSTC連続区間上の時間を示す。SubPlayItemにSTCsequenceidを追加することにより、SubPlayItemが参照するAVストリームファイルがSTC不連続点を持つことが許されるようになる。これ以外のシンタクスフィールドの意味は、図40に示す同名のフィールドと同じである。図102は、RealPlayListの作成方法を説明するフローチャートを示す。図1の記録再生装置のブロック図を参照しながら説明する。ステップS11で、制御部23はClipAVストリームを記録する。ステップS12で、制御部23はClipAVストリームのEPmapを作成可能かどうかを調べる。ステップS12で、Yesの場合はステップS13へ進み、EPmapを作成する。ステップS12で、Noの場合はステップS14へ進み、TUmapを作成する。その後、ステップS15で、制御部23はPlayListのCPItypeをセットする。ステップS16で、制御部23は上記Clipの全ての再生可能範囲をカバーするPlayItemからなるPlayListを作成する。CPItypeがEPmapタイプの場合は、時間情報をPTSベースでセットする、この時、Clipの中にSTC不連続点があり、PlayListが2つ以上のPlayItemからなる場合は、PlayItem間のconnectionconditionもまた決定する。CPItypeがTUmapタイプの場合は、時間情報をアライバルタイムベースでセットする。ステップS17で、制御部23はUIAppInfoPlayListを作成する。ステップS18で、制御部23はPlayListMarkを作成する。ステップS19で、制御部23はMakersPrivateDataを作成する。ステップS20で、制御部23はRealPlayListファイルを記録する。このようにして、新規にClipAVストリームを記録する毎に、1つのRealPlayListファイルが作られる。図103は、VirtualPlayListの作成方法を説明するフローチャートである。ステップS31で、ユーザインターフェースを通して、ディスクに記録されている1つのRealPlayListが指定される。そして、そのRealPlayListの再生範囲の中から、ユーザインターフェースを通して、IN点とOUT点で示される再生区間が指定される。CPItypeがEPmapタイプの場合は、再生区間をPTSベースでセットし、CPItypeがTUmapタイプの場合は、再生区間をアライバルタイムベースでセットする。ステップS32で、制御部23はユーザによる再生範囲の指定操作がすべて終了したか調べる。ユーザが上記指示した再生区間に続けて再生する区間を選ぶ場合はステップS31へ戻る。ステップS32でユーザによる再生範囲の指定操作がすべて終了した場合は、ステップS33へ進む。ステップS33で、連続して再生される2つの再生区間の間の接続状態を、ユーザがユーザインタフェースを通して決定するか、または制御部23が決定する。ステップS34で、CPItypeがEPmapタイプの場合、ユーザインタフェースを通して、ユーザがサブパス情報を指定する。ユーザがサブパスを作成しない場合はこのステップはない。ステップS35で、制御部23はユーザが指定した再生範囲情報、およびconnectionconditionに基づいて、PlayListを作成する。ステップS36で、制御部23はUIAppInfoPlayListを作成する。ステップS37で、制御部23はPlayListMarkを作成する。ステップS38で、制御部23はMakersPrivateDataを作成する。ステップS39で、制御部23はVirtualPlayListファイルを記録する。このようにして、ディスクに記録されているRealPlayListの再生範囲の中から、ユーザが見たい再生区間を選択してその再生区間をグループ化したもの毎に、1つのVirtualPlayListファイルが作られる。図104はPlayListの再生方法を説明するフローチャートである。ステップS51で、制御部23はInfodvrClipInformationfilePlayListfileおよびサムネールファイルの情報を取得し、ディスクに記録されているPlayListの一覧を示すGUI画面を作成し、ユーザインタフェースを通して、GUIに表示する。ステップS52で、制御部23はそれぞれのPlayListのUIAppInfoPlayListに基づいて、PlayListを説明する情報をGUI画面に提示する。ステップS53で、ユーザインタフェースを通して、GUI画面上からユーザが1つのPlayListの再生を指示する。ステップS54で、制御部23は、CPItypeがEPmapタイプの場合、現在のPlayItemのSTCsequencidとINtimeのPTSから、INtimeより時間的に前で最も近いエントリーポイントのあるソースパケット番号を取得する。または制御部23は、CPItypeがTUmapタイプの場合、現在のPlayItemのINtimeから、INtimeより時間的に前で最も近いタイムユニットの開始するソースパケット番号を取得する。ステップS55で、制御部23は上記ステップで得られたソースパケット番号からAVストリームのデータを読み出し、AVデコーダ27へ供給する。ステップS56で、現在のPlayItemの時間的に前のPlayItemがあった場合は、制御部23は、前のPlayItemと現在のPlayItemとの表示の接続処理をconnectionconditionに従って行う。ステップS57で、制御部23は、CPItypeがEPmapタイプの場合、AVデコーダ27は、INtimeのPTSのピクチャから表示を開始するように指示する。または、制御部23は、CPItypeがTUmapタイプの場合、AVデコーダ27は、INtime以後のストリームのピクチャから表示を開始するように指示する。ステップS58で、制御部23は、AVデコーダ27にAVストリームのデコードを続けるように指示する。ステップS59で、制御部23は、CPItypeがEPmapタイプの場合、現在表示の画像が、OUTtimeのPTSの画像かを調べる。または、制御部23は、CPItypeがTUmapタイプの場合、現在デコードしているストリームがOUTtimeを過ぎたかを調べる。ステップS59で、Noの場合は、ステップS60へ進む。ステップS60で現在の画像を表示して、ステップS58へ戻る。Yesの場合は、ステップS61へ進む。ステップS61で、制御部23は、現在のPlayItemがPlayListの中で最後のPlayItemかを調べる。Noの場合はステップS54へ戻る。Yesの場合は、PlayListの再生を終了する。図105は、PlayListのSubパスの再生方法を説明するフローチャートである。図105のPlayListのサブパスの再生方法は、PlayListのCPItypeがEPmapの場合のみに用いられる。このフローチャートの処理は、図104のPlayListの再生におけるステップS54以後の処理と共に、同時に行われる。また、AVデコーダ27は同時に2本のオーディオストリームのデコードが可能であることを前提とする。ステップS71で、制御部23は、SubPlayItemの情報を取得する。ステップS72で、制御部23は、SubPathINtimeよりも時間的に前で最も近いエントリーポイントのあるソースパケット番号を取得する。ステップS73で、制御部23は、上記エントリーポイントのあるソースパケット番号からサブパスのAVストリームのデータを読み出し、AVデコーダ27へ供給する。ステップS74で、制御部23は、Mainパスの再生が、syncPlayItemidとsyncstartPTSofPlayItemで示されるピクチャになったら、サブパスのオーディオを表示を開始するようにAVデコーダ27に指示する。ステップS75でAVデコーダ27は、サブパスのAVストリームのデコードを続ける。ステップS76で制御部23は、現在表示するサブパスのPTSが、SubPathOUTtimeかを調べる。Noの場合は、ステップS77へ進む。ステップS77でサブパスの表示を続けて、ステップS75へ戻る。ステップS76で現在表示するサブパスのPTSが、SubPathOUTtimeの場合はサブパスの表示を終了する。図104および図105のようにして、ユーザにより再生指示された1つのPlayListファイルのメインパスおよびサブパスの再生が行なわれる。図106は、PlayListMarkの作成方法を説明するフローチャートを示す。図1の記録再生装置のブロック図を参照しながら説明する。ステップS91で、制御部23はInfodvrClipInformationfilePlayListfileおよびThumbnailfileの情報を取得し、ディスクに記録されているPlayListの一覧を示すGUI画面を作成し、ユーザインタフェースを通して、GUIに表示する。ステップS92で、ユーザインタフェースを通して、ユーザが1つのPlayListの再生を制御部23に指示する。ステップS93で、制御部23は、上記指示されたPlayListの再生を開始させる図104参照。ステップS94で、ユーザインタフェースを通して、ユーザがお気に入りのシーンのところにマークのセットを制御部23に指示する。ステップS95で、制御部23は、CPItypeがEPmapの場合、マークのPTSとそれが属するPlayItemのPlayItemidを取得する。または制御部23は、CPItypeがTUmapの場合、マーク点のアライバルタイムを取得するステップS96で、制御部23はマークの情報をPlayListMarkにストアする。ステップS97で、制御部23は、PlayListファイルを記録媒体100に記録する。図107は、PlayListMarkを使用した頭出し再生方法を説明するフローチャートである。図1の記録再生装置のブロック図を参照しながら説明する。ステップS111で、制御部23はInfodvrClipInformationfilePlayListfileおよびThumbnailfileの情報を取得し、ディスク記録媒体100に記録されているPlayListの一覧を示すGUI画面を作成し、ユーザインタフェースを通して、GUIに表示する。ステップS112で、制御部23は、ユーザインタフェースを通して、ユーザが1つのPlayListの再生を指示する。ステップS113で、制御部23はPlayListMarkで参照されるピクチャから生成したサムネールのリストを、ユーザインタフェースを通して、GUIに表示する。ステップS114で、ユーザインタフェースを通して、制御部23にユーザが再生開始点のマーク点を指定する。ステップS115で、制御部23は、CPItypeはEPmapタイプの場合は、マークのPTSとそれが属するPlayItemidを取得する。または制御部23は、CPItypeはTUmapタイプの場合は、マークのATSを取得する。ステップS116で、制御部23は、CPItypeはEPmapタイプの場合、PlayItemidが指すPlayItemが参照するAVストリームのSTCsequenceidを取得する。ステップS117で、制御部23は、CPItypeはEPmapタイプの場合は、上記STCsequenceidとマークのPTSに基づいて、AVストリームをデコーダへ入力する。具体的には、このSTCsequenceidとマーク点のPTSを用いて、図104のステップS54、ステップS55と同様の処理を行う。または制御部23は、CPItypeはTUmapタイプの場合は、マークのATSに基づいて、AVストリームをデコーダへ入力する。具体的には、このATSを用いて図104のステップS54、ステップS55と同様の処理を行う。ステップS118で、制御部23は、CPItypeがEPmapタイプの場合は、マーク点のPTSのピクチャから表示を開始させる。または制御部23は、CPItypeがTUmapタイプの場合は、マーク点のATS以後のピクチャから表示を開始させる。このように、図106のようにして、ユーザがPlayListからお気に入りのシーンの開始点等を選び、それをレコーダ記録再生装置1の制御部23はPlayListMarkに管理する。また図107のようにして、ユーザがPlayListMarkにストアされているマーク点のリストから再生開始点を選択して、プレーヤはその開始点から再生を開始する。このようなシンタクス、データ構造、規則に基づく事により、記録媒体に記録されているデータの内容、再生情報などを適切に管理することができ、もって、ユーザが再生時に適切に記録媒体に記録されているデータの内容を確認したり、所望のデータを簡便に再生できるようにすることができる。Iピクチャの位置を分析できる場合、EPmapを用い、Iピクチャの位置を分析できない場合、TUmapを用いるようにすることで、共通のアプリケーションプログラムソフトウエアで、異なるフォーマットのAVストリームを、同一の記録媒体に対して記録し、再生し、管理することが可能となる。AVストリームを、その中身Iピクチャの位置を分析して記録媒体に記録する場合コグニザント記録する場合、EPmapを使用し、その中身Iピクチャの位置を分析せずに、そのまま記録媒体に記録する場合ノンコグニザント記録する場合、TUmapを使用するなどして、共通のアプリケーションプログラムで、AVデータを、同一の記録媒体に記録し、再生し、管理することができる。従って、例えば、スクランブルされたAVデータを、デスクランブルして分析して記録媒体に記録する場合、EPmapを使用し、デスクランブルせずに分析せずに、そのまま記録媒体に記録する場合、TUmapを使用するなどして、共通のアプリケーションプログラムで、AVデータを、同一の記録媒体に記録し、再生し、管理することができる。さらに、EPmaptypeとTUmaptypeを、CPItypeとして、PlayLyst中に、記述できるようにしたので、Iピクチャの位置が分析できる場合、EPmapを用い、Iピクチャの位置が分析できない場合、TUmapを用いるようにすることができる。これにより、Iピクチャの位置を分析して記録するAVストリームデータと、分析しないで記録するAVストリームデータを、フラグを設定するだけで、共通のプログラムにより、統一して管理することが可能となる。また、PlayListファイルやClipInformationファイルを別々に分離して記録するので、編集などによって、あるPlayListやClipの内容を変更したとき、そのファイルに関係のない他のファイルを変更する必要がない。したがって、ファイルの内容の変更が容易に行え、またその変更および記録にかかる時間を小さくできる。さらに、最初にInfodvrだけを読み出して、ディスクの記録内容をユーザインタフェースへ提示し、ユーザが再生指示したPlayListファイルとそれに関連するClipInformationファイルだけをディスクから読み出すようにすれば、ユーザの待ち時間を小さくすることができる。もし、すべてのPlayListファイルやClipInformationファイルを1つのファイルにまとめて記録すると、そのファイルサイズは非常に大きくなる。そのために、そのファイルの内容を変更して、それを記録するためにかかる時間は、個々のファイルを別々に分離して記録する場合に比べて、非常に大きくなる。本発明は、この問題を解決する。上述した一連の処理は、ハードウェアにより実行させることもできるが、ソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体からインストールされる。この記録媒体は、図108に示すように、コンピュータとは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク221フロッピディスクを含む、光ディスク222CDROMCompactDiskReadOnlyMemory,DVDDigitalVersatileDiskを含む、光磁気ディスク223MDMiniDiskを含む、若しくは半導体メモリ224などよりなるパッケージメディアにより構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているROM202や記憶部208が含まれるハードディスクなどで構成される。なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。"