(57)【要約】１回の録画で得られる映像・音声データを複数のファイルに分割したときのデータの管理方法を提供する。  データ処理装置は、映像のデータストリーム、および、データストリームに基づいて映像を再生するための管理情報のそれぞれを１以上の記録媒体に書き込む。データストリームには、映像を構成する各ピクチャのピクチャデータ、および、各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されている。データ処理装置は、１以上のピクチャに関し、時刻情報とデータストリーム内のピクチャデータの格納位置と、ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルを、管理情報の一部として生成するプロセッサと、データストリームおよび管理情報を、１以上のストリームファイル、および、１以上の管理情報ファイルとして記録媒体に書き込むコントローラとを備えている。【特許請求の範囲】
【請求項１】
映像のデータストリーム、および、前記データストリームに基づいて前記映像を再生するための管理情報のそれぞれを１以上の記録媒体に書き込むデータ処理装置であって、
前記データストリームには、前記映像を構成する各ピクチャのピクチャデータ、および、前記各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されており、
１以上のピクチャに関し、前記時刻情報と前記データストリーム内の前記ピクチャデータの格納位置と、前記ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルを、前記管理情報の一部として生成するプロセッサと、
前記データストリームおよび前記管理情報を、１以上のストリームファイル、および、１以上の管理情報ファイルとして前記記録媒体に書き込むコントローラと
を備えたデータ処理装置。
【請求項２】
前記コントローラは、複数のストリームファイルおよび１つの管理情報ファイルを生成する、請求項１に記載のデータ処理装置。
【請求項３】
前記データストリームは、単独で復号化が可能な基準ピクチャの基準ピクチャデータから開始される１以上の再生単位を含み、
前記プロセッサは、前記再生単位の先頭の基準ピクチャデータに対し、前記テーブルを生成する、請求項２に記載のデータ処理装置。
【請求項４】
前記プロセッサは、前記複数のストリームファイルの各々において最初に配置された前記先頭の基準ピクチャデータに対し、前記テーブルを生成する、請求項３に記載のデータ処理装置。
【請求項５】
前記データストリームは、連続して録画された前記映像に関し、共通の基準時刻に基づいて生成された前記時刻情報を含み、
前記コントローラは、前記共通の基準時刻に基づいて生成された前記データストリームを分割して、前記複数のストリームファイルを生成する、請求項２に記載のデータ処理装置。
【請求項６】
前記データストリームは、一定のデータ長を有する複数のパケットから構成されており、
前記プロセッサは、前記データストリーム内の前記複数のパケットの配置に基づいて、前記ピクチャデータの格納位置を特定する、請求項１に記載のデータ処理装置。
【請求項７】
前記コントローラは、ＦＡＴ３２ファイルシステムが採用されている前記記録媒体に対して、前記１以上のストリームファイル、および、前記１以上の管理情報ファイルを書き込む、請求項１に記載のデータ処理装置。
【請求項８】
アナログ信号に基づいて前記１以上の再生単位を生成するエンコーダをさらに備えた、請求項３に記載のデータ処理装置。
【請求項９】
アナログ信号に基づいて映像を連続して録画するときにおいて、前記共通の基準時刻に基づいて前記データストリームを生成するエンコーダをさらに備えた、請求項５に記載のデータ処理装置。
【請求項１０】
映像のデータストリームを格納した１以上のストリームファイル、および、前記データストリームに基づいて前記映像を再生するための管理情報を格納した１以上の管理情報ファイルが記録されている記録媒体であって、
前記データストリームには、前記映像を構成する各ピクチャのピクチャデータ、および、前記各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されており、
前記管理情報には、１以上のピクチャに関し、前記時刻情報と、前記データストリーム内の前記ピクチャデータの格納位置と、前記ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルが格納されている、記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、動画データを記録媒体に記録し、記録された動画データを管理する技術に関する。
【背景技術】
【０００２】  近年、ＤＶＤ等の光ディスクにデジタルデータを書き込み、蓄積できる光ディスクレコーダの普及が進んでいる。書き込まれる対象は、例えば放送された番組のデータストリームや、カムコーダ等によって撮影された映像および音声のデータストリームである。書き込まれたデータは、ランダムアクセス可能な状態でＤＶＤに保持される。【０００３】  ＤＶＤでは、ＵＤＦ（Ｕｎｉｖｅｒｓａｌ  Ｄｉｓｃ  Ｆｏｒｍａｔ）と呼ばれるファイルシステムが採用されている。ＵＤＦファイルシステムは映像・音声データの記録・再生・編集に適している。例えば、ＤＶＤに主に書き込まれる映像・音声データは大きいため、ＵＤＦファイルシステムにおける最大ファイルサイズは十分大きく設定されている。また、ＵＤＦファイルシステムではセクタ単位でのデータの編集が容易である。特許文献１は、このようなＵＤＦファイルシステムを開示している。【０００４】  ＤＶＤに代表されるランダムアクセス可能な記録媒体に映像・音声データを記録するために、従来はデータの性質に応じた適切なファイルシステムが開発され、利便性や機器実装容易性を確保してきた。
【特許文献１】特開２０００−０１３７２８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】  近年は、ＰＣを利用した映像・音声データの編集（ノンリニア編集（ＮＬＥ））が普及しつつあるため、ＰＣのファイルシステムで編集されることを想定して映像・音声データを記録し、管理することが必要とされている。【０００６】  ＰＣでは一般的にＦＡＴ３２ファイルシステムが採用されている。ＦＡＴ３２ファイルシステムでは、１データファイルのファイルサイズは４ＧＢ未満に制限される。よって、ＦＡＴ３２ファイルシステムでの編集を考慮すると、１回の録画で得られる映像・音声データを複数のファイルに分割して格納する必要が生じる。そこで、それらの映像・音声データをどのように管理するかが問題となる。【０００７】  特に、近年は小径のハードディスクや半導体メモリのような記録媒体を複数装填できる機器（例えばカムコーダ）が開発されているため、分割された映像・音声データが複数の記録媒体に跨って書き込まれることもある。よって、映像・音声データが分割されて１つの記録媒体に書き込まれている状況のみならず、異なる記録媒体に書き込まれている状況においても、適切に映像・音声データを管理する必要がある。【０００８】  本発明の目的は、１回の録画で得られる映像・音声データを複数のファイルに分割したときのデータの管理方法を提供することである。
【課題を解決するための手段】
【０００９】  本発明によるデータ処理装置は、映像のデータストリーム、および、前記データストリームに基づいて前記映像を再生するための管理情報のそれぞれを１以上の記録媒体に書き込む。前記データストリームには、前記映像を構成する各ピクチャのピクチャデータ、および、前記各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されている。前記データ処理装置は、１以上のピクチャに関し、前記時刻情報と前記データストリーム内の前記ピクチャデータの格納位置と、前記ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルを前記管理情報の一部として生成するプロセッサと、前記データストリームおよび前記管理情報を、１以上のストリームファイル、および、１以上の管理情報ファイルとして前記記録媒体に書き込むコントローラとを備えている。【００１０】  前記コントローラは、複数のストリームファイルおよび１つの管理情報ファイルを生成してもよい。【００１１】  前記データストリームは、単独で復号化が可能な基準ピクチャの基準ピクチャデータから開始される１以上の再生単位を含み、前記プロセッサは、前記再生単位の先頭の基準ピクチャデータに対し、前記テーブルを生成してもよい。【００１２】  前記プロセッサは、前記複数のストリームファイルの各々において最初に配置された前記先頭の基準ピクチャデータに対し、前記テーブルを生成してもよい。【００１３】  前記データストリームは、連続して録画された前記映像に関し、共通の基準時刻に基づいて生成された前記時刻情報を含み、前記コントローラは、前記共通の基準時刻に基づいて生成された前記データストリームを分割して、前記複数のストリームファイルを生成してもよい。【００１４】  前記データストリームは、一定のデータ長を有する複数のパケットから構成されており、前記プロセッサは、前記データストリーム内の前記複数のパケットの配置に基づいて、前記ピクチャデータの格納位置を特定してもよい。【００１５】  前記コントローラは、ＦＡＴ３２ファイルシステムが採用されている前記記録媒体に対して、前記１以上のストリームファイル、および、前記１以上の管理情報ファイルを書き込んでもよい。【００１６】  前記データ処理装置は、アナログ信号に基づいて前記１以上の再生単位を生成するエンコーダをさらに備えていてもよい。【００１７】  前記データ処理装置は、アナログ信号に基づいて映像を連続して録画するときにおいて、前記共通の基準時刻に基づいて前記データストリームを生成するエンコーダをさらに備えていてもよい。本発明による記録媒体には、映像のデータストリームを格納した１以上のストリームファイル、および、前記データストリームに基づいて前記映像を再生するための管理情報を格納した１以上の管理情報ファイルが記録されている。前記データストリームには、前記映像を構成する各ピクチャのピクチャデータ、および、前記各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されている。前記管理情報には、１以上のピクチャに関し、前記時刻情報と、前記データストリーム内の前記ピクチャデータの格納位置と、前記ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルが格納されている。
【発明の効果】
【００１８】  本発明によれば、データ処理装置は、データストリームが格納されたファイルを特定するファイル情報等を格納したテーブルを生成する。このテーブルを参照すれば、データストリームを解析することなく、データストリームの全部または一部がどのファイルに格納されているかを特定できる。よって、データストリームの所望の再生位置に高速にアクセスすることができる。
【図面の簡単な説明】
【００１９】
【図１】本発明の実施形態による光ディスクレコーダ１００と他の機器とによって形成されるシステムの構成を示す図である。
【図２】トランスポートストリーム（ＴＳ）２０のデータ構造を示す図である。
【図３】（ａ）はビデオＴＳパケット３０のデータ構造を示す図であり、（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す図である。
【図４】（ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す図である。
【図５】レコーダ１００の機能ブロックの構成を示す図である。
【図６】ＴＳ処理部２０４の詳細な機能ブロックの構成を示す図である。
【図７】（ａ）〜（ｅ）は、トランスポートストリームとクリップＡＶストリームとの関係を示す図である。
【図８】ＢＤ２０５ａの記録領域と、そのディレクトリ／ファイル構造を示す図である。
【図９】（ａ）〜（ｄ）は、管理情報とストリームデータとの関係を示す図である。
【図１０】プレイリストファイル８３に格納される情報（エントリ）およびプレイリストファイルのデータ構造を示す図である。
【図１１】クリップ情報ファイル８４に格納される情報（エントリ）およびクリップ情報ファイルの一部のエントリに関するデータ構造を示す図である。
【図１２】クリップ情報ファイル８４に格納される情報（エントリ）およびクリップ情報ファイルの他の一部のエントリに関するデータ構造を示す図である。
【図１３】時間・アドレス変換テーブルのデータ構造を示す図である。
【図１４】第１の例による時間とアドレスの対応を示す図である。
【図１５】第２の例による時間とアドレスの対応を示す図である。
【図１６】（ａ）はリアルプレイリスト１および２と、対応するクリップ１および２を示す図であり、（ｂ）はＩＮ１からＯＵＴ１までの第１区間およびＩＮ２からＯＵＴ２までの第２区間を連続して再生するバーチャルプレイリストを示す図である。
【図１７】（ａ）はバーチャルプレイリストを分割するときの分割点の位置を示す図であり、（ｂ）は分割されたバーチャルプレイリスト１および２を示す。
【図１８】（ａ）は併合の対象であるバーチャルプレイリスト１および２を示す図であり、（ｂ）は１つに併合されたバーチャルプレイリストを示す図である。
【図１９】（ａ）は区間Ａ−Ｂを削除の対象とするリアルプレイリストおよびクリップを示す図であり、（ｂ）は区間Ａ−Ｂを削除して、点ＡおよびＢの位置を結合したリアルプレイリストおよびクリップを示す図である。
【図２０】ＢＤ２０５ａにおいて管理されるサムネイルピクチャと管理ファイルとの関係を示す図である。
【図２１】（ａ）〜（ｃ）は、それぞれ、マークが付加されたバーチャルプレイリスト３１２、リアルプレイリスト３１４およびクリップ３１６を示す図である。
【図２２】（ａ）〜（ｄ）は、ファイルサイズに上限のあるファイルシステムでのファイル構成を説明する図である。
【図２３】（ａ）および（ｂ）は、途中が削除される前後のストリームとシーケンスの相関関係を示す図である。
【図２４】（ａ）〜（ｄ）は、本実施形態による、ＦＡＴ３２ファイルシステムにおいて好適な管理情報ファイル８２〜８４とクリップＡＶストリームファイル８５の関係を示す図である。
【図２５】時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）８７のデータ構造を模式的に示す図である。
【図２６】変換テーブル８７の詳細なデータ構造を示す図である。
【図２７】変換テーブル８７を利用して指定されたＰＴＳに対応するピクチャを再生する処理の手順を示すフローチャートである。
【図２８】（ａ）および（ｂ）は、本実施形態による編集前後のクリップを示す図である。
【図２９】（ａ）は編集されたクリップＡＶストリームに対する、一つのクリップ情報ファイルに格納された時間・アドレス変換テーブルの概念を示す図であり、（ｂ）は２つのＳＴＣシーケンスの範囲をそれぞれ示す図であり、（ｃ）はクリップＡＶストリームが格納された２つのファイルを示す図であり、（ｄ）は複数のファイルに跨るクリップＡＶストリームのＡＴＳの変化を示す図である。
【図３０】ファインエントリと各ＧＯＰの先頭に配置されるＩピクチャとの対応を示す図である。
【図３１】（ａ）〜（ｄ）は、ファインエントリのデータ構造の変形例を示す図である。
【図３２】本実施形態によるタイムマップのデータ構造を示す図である。
【図３３】（ａ）は本実施形態における１コンテンツの概念を示す図であり、（ｂ）はコンテンツの管理情報とストリームのデータとを含むクリップの概念を示す図であり、（ｃ）は３つのメモリカード１１２ａ〜１１２ｃを示す図である。
【図３４】クリップメタデータ３３１に含まれる情報の内容を示す図である。
【符号の説明】
【００２０】  １００  ＨＤＤ内蔵ＢＤレコーダ
１０６  ＴＶ
１０８  ＰＣ
１１２  メモリカード
１１４  ＢＤ
２０１ａ  デジタルチューナ
２０１ｂ  アナログチューナ
２０２  ＡＤコンバータ
２０３  ＭＰＥＧ−２エンコーダ
２０４  ＴＳ処理部
２０５ａ  ＢＤ
２０５ｂ  ＨＤＤ
２０６  ＭＰＥＧ−２デコーダ
２０７  グラフィック制御部
２０８  メモリ
２０９  ＤＡコンバータ
２１０  プログラムＲＯＭ
２１１  ＣＰＵ
２１２  ＲＡＭ
２１３  ＣＰＵバス
２１４  ネットワーク制御部
２１５  指示受信部
２１６  インターフェース（Ｉ／Ｆ）部
２１７  メモリカード制御部
２５０  システム制御部
２６１  ソース・パケタイザ
２６２  クロックカウンタ
２６３  ＰＬＬ回路
２６４  バッファ
２６５  ソース・デ・パケタイザ
【発明を実施するための最良の形態】
【００２１】  以下、添付の図面を参照して、本発明によるデータ処理装置の実施形態を説明する。本実施の形態においては、データ処理装置は光ディスクや半導体メモリ、小型ＨＤＤなどのドライブ／スロットを搭載したＨＤＤ内蔵型の光ディスクレコーダであるとして説明するが、カムコーダやムービー撮影機能を有する携帯電話等でもよく、特にこれに限定されない。【００２２】  図１は、光ディスクレコーダ１００と他の機器とによって形成されるシステムの構成を示す。光ディスクレコーダ１００（以下「レコーダ１００」と記述する）は、放送番組の映像および音声に関する動画のデータストリームを１種類以上の記録媒体に記録する録画機能を有する。記録媒体として、例えば半導体メモリカード１１２、小型のＨＤＤを利用したメモリカード１１３、Ｂｌｕ−ｒａｙディスク（ＢＤ）１１４である。なお、これらはリムーバブルな記録媒体の例であるが、レコーダ１００がＨＤＤを内蔵しているときには、そのＨＤＤに動画のデータストリームを記録し、蓄積することもできる。またレコーダ１００は、それらの記録媒体に記録されたデータストリームを読み出して動画を再生する再生機能も有する。【００２３】  図１には、レコーダ１００の録画機能および再生機能に関連して連携することが可能な他の機器（ＰＣ１０８、カムコーダ１１０）を示している。ただし、これらの機器もまた固有の録画機能および再生機能を有している。各機能はレコーダ１００と同等である。以下の説明では、主としてレコーダ１００を例に挙げて説明する。【００２４】  レコーダ１００の録画機能および再生機能に関する処理は、リモコン１１６や、レコーダ１００本体のボタン（図示せず）等を利用してユーザが与えた指示に基づいて行われる。【００２５】  まず、レコーダ１００の録画機能に関連する処理を説明する。レコーダ１００は、デジタル放送番組に関するデジタル信号を受信するアンテナ１０２ａ、および、アナログ放送番組に関するアナログ信号を受信するアンテナ１０２ｂと接続され、デジタル信号およびアナログ信号を受信する。レコーダ１００は、例えば同軸ケーブル１０４を介してデジタル信号およびアナログ信号を受け取る。【００２６】  デジタル信号は、ＭＰＥＧ−２トランスポートストリーム（以下「トランスポートストリーム」または「ＴＳ」と記述する）として伝送されている。ＴＳを受信した場合には、レコーダ１００は、そのＴＳに所定の処理を行い、後述するＴＳのパケット構造を保持しながらＢＤ１１４に記録する。アナログ信号を受信した場合には、レコーダ１００は、そのアナログ信号から得られた動画のデータを圧縮符号化してＴＳを生成し、そのＴＳをＢＤ１１４に記録する。さらにレコーダ１００は、ＳＤメモリカードのような半導体を利用したメモリカード１１２や小型のＨＤＤを利用したメモリカード１１３にアナログ／デジタル放送番組を録画することもできる。また、メモリカード１１２、１１３に記録された静止画データなどをＢＤ１１４にコピーすることもできる。なお、カムコーダ１１０を利用して録画が行われるときには、カムコーダ１１０は撮影対象の映像および音声のアナログ信号に基づいてＴＳを生成する。【００２７】  次に、レコーダ１���０が有する再生機能に関連する処理を説明する。レコーダ１００はＢＤ１１４に記録された映像および音声を復号化し、ＴＶ１０６、スピーカ（図示せず）等を介して再生する。この映像および音声は放送番組に限られることはなく、例えばカムコーダ１１０によって記録された映像および音声であってもよい。なお、映像および／または音声を記録した機器と、それらを再生する機器とが異なっていてもよい。例えば、映像および音声が記録されたＢＤ１１４がレコーダ１００から取り出されてＰＣ１０８やカムコーダ１１０等の他の機器に装填されてもよい。そしてそのＢＤ１１４が装填された機器が映像および音声を再生してもよい。【００２８】  ここで、図２〜図４を参照しながら、デジタル放送信号として伝送されるトランスポートストリームのデータ構造を説明する。【００２９】  図２は、トランスポートストリーム（ＴＳ）２０のデータ構造を示す。ＴＳパケットは、例えば、圧縮されたビデオデータが格納されたビデオＴＳパケット（Ｖ＿ＴＳＰ）３０、圧縮されたオーディオデータが格納されたオーディオＴＳパケット（Ａ＿ＴＳＰ）３１の他、番組表（プログラム・アソシエーション・テーブル；ＰＡＴ）が格納されたパケット（ＰＡＴ＿ＴＳＰ）、番組対応表（プログラム・マップ・テーブル；ＰＭＴ）が格納されたパケット（ＰＭＴ＿ＴＳＰ）およびプログラム・クロック・リファレンス（ＰＣＲ）が格納されたパケット（ＰＣＲ＿ＴＳＰ）等を含む。各ＴＳパケットのデータ量は１８８バイトである。また、ＰＡＴ＿ＴＳＰ、ＰＭＴ＿ＴＳＰ等のＴＳの番組構成を記述するＴＳパケットを一般に、ＰＳＩ／ＳＩパケットと呼ぶ。【００３０】  以下、本発明の処理に関連するビデオＴＳパケットおよびオーディオＴＳパケットを説明する。図３（ａ）はビデオＴＳパケット３０のデータ構造を示す。ビデオＴＳパケット３０は、４バイトのトランスポートパケットヘッダ３０ａ、および、１８４バイトのトランスポートパケットペイロード３０ｂを有する。ペイロード３０ｂにはビデオデータ３０ｂが格納されている。一方、図３（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す。オーディオＴＳパケット３１も同様に、４バイトのトランスポートパケットヘッダ３１ａ、および、１８４バイトのトランスポートパケットペイロード３１ｂを有する。オーディオデータ３１ｂはトランスポートパケットペイロード３１ｂに格納されている。【００３１】  上述の例から理解されるように、一般にＴＳパケットは４バイトのトランスポートパケットヘッダと、１８４バイトのエレメンタリデータとから構成されている。パケットヘッダには、そのパケットの種類を特定するパケット識別子（Ｐａｃｋｅｔ  ＩＤｅｎｔｉｆｉｅｒ；ＰＩＤ）が記述されている。例えば、ビデオＴＳパケットのＰＩＤは“０ｘ００２０”であり、オーディオＴＳパケットのＰＩＤは“０ｘ００２１”である。エレメンタリデータは、ビデオデータ、オーディオデータ等のコンテンツデータや、再生を制御するための制御データ等である。どのようなデータが格納されているかは、パケットの種類に応じて異なる。【００３２】  以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。図４���ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す。図４（ａ）に示すように、ＴＳ４０は、ビデオＴＳパケット４０ａ〜４０ｄを含む。なお、ＴＳ４０には、他のパケットも含まれ得るが、ここではビデオＴＳパケットのみを示している。ビデオＴＳパケットは、ヘッダ４０ａ−１に格納されたＰＩＤによって容易に特定される。【００３３】  ビデオデータ４０ａ−２等の各ビデオＴＳパケットのビデオデータから、ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）パケットが構成される。図４（ｂ）は、パケット化エレメンタリストリーム（ＰＥＳ）４１のデータ構造を示す。ＰＥＳ４１は、複数のＰＥＳパケット４１ａ、４１ｂ等から構成される。ＰＥＳパケット４１ａは、ＰＥＳヘッダ４１ａ−１およびＰＥＳペイロード４１ａ−２から構成されており、これらのデータがビデオＴＳパケットのビデオデータとして格納されている。【００３４】  ＰＥＳペイロード４１ａ−２は、それぞれが１つのピクチャのデータを含んでいる。ＰＥＳヘッダ４１ａ−１には、各ピクチャの再生表示時刻を特定するプレゼンテーションタイムスタンプ（ＰＴＳ）が格納されている。【００３５】  ＰＥＳペイロード４１ａ−２から、エレメンタリストリームが構成される。図４（ｃ）は、エレメンタリストリーム（ＥＳ）４２のデータ構造を示す。ＥＳ４２は、ピクチャヘッダ、および、ピクチャデータの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールドのいずれも含む概念として用いられる。【００３６】  図４（ｃ）に示すピクチャヘッダ４２ａには、その後に配置されたピクチャデータ４２ｂのピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ４２ｃにはピクチャデータ４２ｄのピクチャ種別を特定するピクチャコーディングタイプが記述されている。種別とは、Ｉピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）またはＢピクチャ（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ−ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）を表す。種別がＩピクチャであれば、そのピクチャコーディングタイプは、ＭＰＥＧ−２ビデオならば“００１ｂ”である。【００３７】  ピクチャデータ４２ｂ、４２ｄ等は、そのデータのみによって、または、そのデータとその前および／または後に復号化されるデータとによって構築可能な１枚分のフレームのデータである。例えば図４（ｄ）は、ピクチャデータ４２ｂから構築されるピクチャ４３ａおよびピクチャデータ４２ｄから構築されるピクチャ４３ｂを示す。【００３８】  ＴＳに基づいて映像を再生する際、レコーダ１００のＭＰＥＧ２デコーダ２０６（後述）はビデオＴＳパケットを取得して上述の処理にしたがってピクチャデータを取得し、復号化することによって映像を構成するピクチャを取得する。これにより映像をＴＶ１０６上に再生することができる。逆に、映像を記録する際には、レコーダ１００のＭＰＥＧ２エンコーダ２０３（後述）は、図４（ｄ）、（ｃ）、（ｂ）および（ａ）の順に処理を行って、ＴＳ４０を構築する。【００３９】  次に、図���を参照しながら、機器のハードウェア構成を説明する。以下ではレコーダ１００を例に挙げて説明するが、その説明は図１に示すＰＣ１０８、カムコーダ１１０にも適用できる。なお、カムコーダ１１０には後述するデジタルチューナ２０１ａを含んでいなくてもよい。【００４０】  以下、本実施形態によるレコーダ１００の構成を説明する。図５は、レコーダ１００の機能ブロックの構成を示す。レコーダ１００は、記録媒体としてＢＤ２０５ａのみならず、ハードディスクドライブ（ＨＤＤ）２０５ｂをも有している。すなわちレコーダ１００は、ＨＤＤ２０５ｂを内蔵したＢＤレコーダである。【００４１】  レコーダ１００は、デジタルチューナ２０１ａおよびアナログチューナ２０１ｂと、ＡＤコンバータ２０２と、ＭＰＥＧ−２エンコーダ２０３と、ＴＳ処理部２０４と、ＭＰＥＧ−２デコーダ２０６と、グラフィック制御部２０７と、メモリ２０８と、ＤＡコンバータ２０９と、ＣＰＵバス２１３と、ネットワーク制御部２１４と、指示受信部２１５と、インターフェース（Ｉ／Ｆ）部２１６と、メモリカード制御部２１７と、システム制御部２５０とを含む。なお、図５には、光ディスク２０５ａがレコーダ１００内に記載されているが、光ディスク２０５ａは光ディスクレコーダ１００から取り外し可能であり、レコーダ１００自体の構成要素ではない。【００４２】  以下、各構成要素の機能を説明する。デジタルチューナ２０１ａは、アンテナ１０２ａ（図１）から１以上の番組が含まれるデジタル信号を受け取る。デジタル信号として伝送されるトランスポートストリームには複数の番組のパケットが混在している。複数の番組のパケットを含むトランスポートストリームは“フルＴＳ“と呼ばれる。デジタルチューナ２０１ａは、選局を行ってフルＴＳから必要な番組のパケットのみを取り出し、”パーシャルＴＳ“として出力する。【００４３】  フルＴＳから所望のチャンネルのパケットを取り出す手順は以下のとおりである。いま、希望の番組の番組番号（チャンネル番号）をＸとする。まず、フルＴＳから番組表パケット（図２のＰＡＴ＿ＴＳＰ）が検索される。番組表パケットのパケットＩＤ（ＰＩＤ）には、必ず０が与えられているので、その値を有するパケットを検索すればよい。番組表パケット内の番組表には、各番組番号と、その番組番号に対応する各番組の番組対応表パケット（図２のＰＭＴ＿ＴＳＰ）のＰＩＤが格納されている。これにより、番組番号Ｘに対応する番組対応表ＰＭＴのパケットＩＤ（ＰＩＤ）を特定できる。番組対応表ＰＭＴのＰＩＤをＸＸとする。【００４４】  次に、ＰＩＤ＝ＸＸが付された番組対応表パケット（図２のＰＭＴ＿ＴＳＰ）を抽出すると、番組番号Ｘに対応する番組対応表ＰＭＴが得られる。番組対応表ＰＭＴには、番組ごとに、視聴の対象として各番組を構成する映像・音声情報等が格納されたＴＳパケットのＰＩＤが格納されている。例えば、番組番号Ｘの映像情報のＰＩＤはＸＶであり、音声情報のＰＩＤはＸＡである。このようにして得られた映像情報を格納したパケットのＰＩＤ（＝ＸＶ）と、音声情報を格納したパケットのＰＩＤ（＝ＸＡ）とを利用して、フルＴＳから特定の番組に関する映像・音声のパケットを抽出できる。【００４５】  なお、フルＴＳからパーシャルＴＳを生成する際には、必要な映像・音声情報を格納したパケットを取り出すだけでなく、ＰＳＩ（Ｐｒｏｇｒａｍ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎ）パケットおよびＳＩ（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ）パケットも抽出および変更する必要がある。ＰＳＩパケットとは、図２に示す番組表パケット（ＰＡＴ＿ＴＳＰ）および番組対応表パケット（ＰＭＴ＿ＴＳＰ）等を総称するパケットである。ＰＳＩパケットを修正する理由は、フルＴＳとパーシャルＴＳとでは含まれる番組数等が異なるため、番組表および番組対応表をパーシャルＴＳに適合させる必要が生じるからである。一方、ＳＩパケットとは、フルＴＳに含まれる番組の内容、スケジュール／タイミング等を記述するデータ、独自に定義された拡張情報（これらは「番組配列情報」とも呼ばれる）等を含むパケットである。フルＴＳではＳＩパケットに含まれるデータは２０〜３０種類にも上る。これらのデータのうち、パーシャルＴＳの再生等に関して重要なデータのみが抽出されて１つのＳＩＴパケットが生成され、パーシャルＴＳ内に多重化される。またパーシャルＴＳでは、ＳＩＴパケットにはそのストリームがパーシャルＴＳであることを示す情報（ｐａｒｔｉａｌ  ｔｒａｎｓｐｏｒｔ  ｓｔｒｅａｍ  ｄｅｓｃｒｉｐｔｏｒ）が格納されている。パーシャルＴＳ内にＳＩＴパケットを多重化することは慣用されている。これは、欧州／日本のデジタル放送規定（ＤＶＢ／ＡＲＩＢ）との整合性のためである。【００４６】  アナログチューナ２０１ｂは、アンテナ１０２ｂ（図１）からアナログ信号を受け取り、周波数に基づいて選局を行って必要な番組の信号を取り出す。そして番組の映像および音声信号をＡＤコンバータ２０２に出力する。なお、図１ではレコーダ１００は同軸ケーブル１０４を介してデジタル信号およびアナログ信号を取得しているため、図５に入力される信号系統は厳密には１本である。しかし、デジタル信号およびアナログ信号は周波数によって容易に分離できるため、図５ではデジタル信号およびアナログ信号が別系統で入力されているように記載している。【００４７】  ＡＤコンバータ２０２は入力された信号をデジタル変換してＭＰＥＧ−２エンコーダ２０３に供給する。ＭＰＥＧ−２エンコーダ２０３（以下「エンコーダ２０３」と記述する）は、録画の開始指示を受け取ると、供給されたアナログ放送のデジタルデータをＭＰＥＧ−２形式に圧縮符号化してトランスポートストリームを生成し、ＴＳ処理部２０４に入力する。この処理は、図４（ｄ）に示す各ピクチャから、図４（ａ）に示すＴＳ４０を生成する処理である。具体的には、エンコーダ２０３は、アナログ放送信号から得られたピクチャ４３ａ、４３ｂ等のデジタルベースバンド信号を取得して符号化し、ピクチャデータ４２ｂを生成する。そして図４（ｃ）に示すＥＳ４２を生成する。【００４８】  また、エンコーダ２０３はピクチャ（フレームまたはフィールド）の再生出力時刻を特定するプレゼンテーションタイムスタンプ（ＰＴＳ）等も生成し、そのＰＴＳ等をＰＥＳヘッダ４１ａに格納して図４（ｂ）に示すＰＥＳ４１を生成する。その後、エンコーダ２０３は図４（ａ���に示すＴＳ４０を構築する。上述の処理は、エンコーダ２０３が録画の終了指示を受け取るまで継続される。なお、エンコーダ２０３は圧縮符号化を行うために、参照ピクチャ等を一時的に保持するバッファ（図示せず）等を有している。【００４９】  ＴＳ処理部２０４は、動画の記録時にはパーシャルＴＳを受け取り、クリップＡＶストリーム（ＣｌｉｐＡＶストリーム）を生成し、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録する。クリップＡＶストリームとは、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録するための形式を有するデータストリームである。クリップＡＶストリームは複数の「ソースパケット」から構成されており、「ソースパケット」はパーシャルＴＳを構成する各ＴＳパケットに所定のヘッダを付加して生成される。なお、クリップＡＶストリームを生成する際の処理の詳細は、図７（ａ）〜（ｅ）に関連して後述する。【００５０】  ＴＳ処理部２０４は、動画の再生時には、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂからクリップＡＶストリームを読み出し、そのクリップＡＶストリームに基づいてパーシャルＴＳを生成してＭＰＥＧ−２デコーダ２０６に出力する。【００５１】  また、ＴＳ処理部２０４は、後述するメモリカード制御部２１７からメモリカード１１２、または１１３に格納された静止画データを受け取り、その静止画を加工することなくそのままＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録する。また、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録された静止画データを読み出してデコーダ２０６に出力することもできる。ＴＳ処理部２０４のさらに具体的な構成および動作は、後に図６および図７を参照しながら詳述する。なお、本明細書では、ＴＳ処理部２０４がＢＤ２０５ａおよび／またはＨＤＤ２０５ｂにデータを記録し、またはそれらからデータを読み出すとして説明しているが、これは説明の便宜のためである。ＢＤ２０５ａやＨＤＤ２０５ｂに対するストリームの書き込みや読み出しは、実際には、ディスクの回転、ヘッドの移動とともに各々のドライブ装置に設けられたコントローラ（図示せず）が行っている。【００５２】  ＭＰＥＧ−２デコーダ２０６（以下「デコーダ２０６」と記述する）は、供給されたパーシャルＴＳを解析してＭＰＥＧ−２圧縮符号化データを取得する。そして、その圧縮符号化データを伸長して非圧縮データに変換し、グラフィック制御部２０７に供給する。また、デコーダ２０６は、ＭＰＥＧ−２規格の圧縮符号化データのみならず、例えばＪＰＥＧ規格に従った静止画データも非圧縮データに変換することができる。グラフィック制御部２０７には内部演算用のメモリ２０８が接続されており、オン・スクリーン・ディスプレイ（Ｏｎ  Ｓｃｒｅｅｎ  Ｄｉｓｐｌａｙ；ＯＳＤ）機能を実現できる。例えば、グラフィック制御部２０７は種々のメニュー画像と映像とを合成してＤＡコンバータ２０９に出力することができる。ＤＡコンバータ２０９は、入力されたＯＳＤ合成画像および音声データをアナログ変換して出力する。出力先は、例えばＴＶ１０６である。【００５３】  ＣＰＵバス２１３はレコーダ１００内の信号を伝送する経路であり、図示されるように各機能ブロックと接続されてい��。また、ＣＰＵバス２１３には、後述するシステム制御部２５０の各構成要素も接続されている。【００５４】  ネットワーク制御部２１４は、レコーダ１００をインターネット等のネットワーク１０１に接続するためのインターフェイスであり、例えば、イーサネット（登録商標）規格に準拠した端子およびコントローラである。ネットワーク制御部２１４は、ネットワーク１０１を介してデータを授受する。このデータは、例えば放送番組に関する番組表のデータや、レコーダ１００の動作を制御するためのソフトウェアプログラムの更新データである。【００５５】  指示受信部２１５は、レコーダ１００の本体部に設けられた操作ボタン、または、リモートコントローラからの赤外線を受光する受光部である。指示受信部２１５は、ユーザから、例えば録画の開始／停止、録画した番組の再生の開始／停止等の指示や、装填されたメモリカード１１２の静止画をＢＤ２０５ａまたはＨＤＤ２０５ｂにコピーする指示を与える。【００５６】  インターフェース（Ｉ／Ｆ）部２１６は、レコーダ１００が他の機器と通信するためのコネクタおよびその通信を制御する。Ｉ／Ｆ部２１６は、例えばＵＳＢ２．０規格の端子、ＩＥＥＥ１３９４規格の端子および各規格によるデータ通信を可能とするコントローラを含み、各規格に準拠した方式でデータを授受することができる。例えば、レコーダ１００は、ＵＳＢ２．０規格の端子を介してＰＣ１０８や、カムコーダ（図示せず）等と接続され、ＩＥＥＥ１３９４規格の端子の端子を介してデジタルハイビジョンチューナや、カムコーダ（図示せず）等と接続される。【００５７】  メモリカード制御部２１７は、メモリカード１１２をレコーダ１００に装填するためのスロット、および、レコーダ１００とメモリカード１１２との間のデータ通信を制御するコントローラである。メモリカード制御部２１７は、ＣＰＵバス２１３を介して動画データ、静止画データ、それらに関連する管理情報等を受け取り、装填されたメモリカード１１２、１１３に書き込む。またメモリカード制御部２１７は、装填されたメモリカード１１２、１１３から静止画データファイル、動画データファイル等を読み出して、ＣＰＵバス２１３に伝送する。【００５８】  システム制御部２５０は、レコーダ１００内の信号の流れを含む全体的な処理を制御する。システム制御部２５０は、プログラムＲＯＭ２１０と、ＣＰＵ２１１と、ＲＡＭ２１２とを有している。それぞれはＣＰＵバス２１３に接続されている。プログラムＲＯＭ２１０にはレコーダ１００を制御するためのソフトウェアプログラムが格納されている。【００５９】  ＣＰＵ２１１は、レコーダ１００の全体の動作を制御する中央制御ユニットである。ＣＰＵ２１１は、プログラムを読み出して実行することにより、プログラムに基づいて規定される処理を実現するための制御信号を生成し、ＣＰＵバス２１３を介して各構成要素に出力する。またＣＰＵ２１１は、後述の管理情報（例えば図２４に示す管理ファイル８２、プレイリストファイル８３、クリップ情報ファイル８４）を生成し、ＣＰＵバスを介してＴＳ処理部２０４やメモリカード制御部２１７に出力する。【００６０】  メモリ２１２は、ＣＰＵ２１１がプログラムを実行するために必要なデータを格納するためのワーク領域を有する。例えば、ＣＰＵ２１１は、ＣＰＵバス２１３を使用してプログラムＲＯＭ２１０からプログラムをランダムアクセスメモリ（ＲＡＭ）２１２に読み出し、そのプログラムを実行する。なお、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録して市場に流通され、または、インターネット等の電気通信回線を通じて伝送される。これにより、ＰＣ等を利用して構成されたコンピュータシステムを、本実施形態によるレコーダ１００と同等の機能を有するデータ処理装置として動作させることができる。【００６１】  図６は、ＴＳ処理部２０４の詳細な機能ブロックの構成を示す。ＴＳ処理部２０４は、ソース・パケタイザ２６１と、クロックカウンタ２６２と、ＰＬＬ回路２６３と、バッファ２６４と、ソース・デ・パケタイザ２６５とを有する。【００６２】  ソース・パケタイザ２６１は、パーシャルＴＳを受け取り、そのパーシャルＴＳを構成するＴＳパケットの前に所定のヘッダを付加してソースパケットを生成して出力する。ヘッダには、そのＴＳパケットを受信した時刻（すなわちそのＴＳパケットの到着時刻）を示す時刻情報ＡＴＳ（Ａｒｒｉｖａｌ  Ｔｉｍｅ  Ｓｔａｍｐ）が含まれている。ＴＳパケットの到着時刻は、ソース・パケタイザ２６１に与えられる基準時刻からのカウント値（カウント情報）に基づいて特定される。ＴＳパケットの到着時刻に関する情報を含める理由は、図７を参照しながら後述する。【００６３】  クロックカウンタ２６２およびＰＬＬ回路２６３は、ソース・パケタイザ２６１がＴＳパケットの到着時刻を特定するために必要な情報を生成する。まずＰＬＬ回路２６３は、パーシャルＴＳに含まれるＰＣＲパケット（図２のＰＣＲ＿ＴＳＰ）を抽出して、基準時刻を示すＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ  Ｒｅｆｅｒｅｎｃｅ：プログラム時刻基準参照値）を取得する。ＰＣＲの値と同じ値がレコーダ１００のシステム基準時刻ＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）として設定され、基準時刻とされる。システム基準時刻ＳＴＣのシステムクロックの周波数は２７ＭＨｚである。ＰＬＬ回路２６３は、２７ＭＨｚのクロック信号をクロックカウンタ２６２に出力する。クロックカウンタ２６２はクロック信号を受け取り、そのクロック信号をカウント情報としてソース・パケタイザ２６１に出力される。【００６４】  バッファ２６４は、ライトバッファ２６４ａおよびリードバッファ２６４ｂを有する。ライトバッファ２６４ａは、送られてきたソースパケットを逐次保持し、合計のデータ量が所定値（例えばバッファの全容量）になったときに、書き込みのためにＢＤ２０５ａ等に出力する。このとき出力される一連のソースパケット列（データストリーム）を、クリップＡＶストリームと呼ぶ。一方、リードバッファ２６４ｂは、ＢＤ２０５ａ等から読み出されたクリップＡＶストリームを一時的にバッファして、ソースパケット単位で出力する。【００６５】  ソース・デ・パケタイザ２６５は、ソースパケットを受け取ってＴＳパケットに変換し、パーシャルＴＳとして出力する。留意すべきは、ソース・デ・パケタイザ２６５は、クロックカウンタ２６２から与えられるタイミ��グ情報と、ソースパケットに含まれていたＴＳパケットの到着時刻情報ＡＴＳとに基づいて、元の到着時刻に対応する時間間隔でＴＳパケットを出力することである。これにより、ＴＳ処理部２０４は、記録時のＴＳパケットの到着タイミングと同じタイミングでＴＳパケットを出力することができる。なお、ソース・デ・パケタイザ２６５は、読み出したパーシャルＴＳの基準時刻を指定するために、例えば最初のソースパケットにおいて指定されている到着時刻を初期値としてクロックカウンタ２６２に送る。これにより、クロックカウンタ２６２においてその初期値からカウントを開始させることができ、よってその後のカウント結果をタイミング情報として受け取ることができる。【００６６】  ここで、図７を参照しながら、ＴＳ処理部２０４において行われる処理を具体的に説明する。図７（ａ）〜（ｅ）は、トランスポートストリームとクリップＡＶストリームとの関係を示す。参考のため、図７（ａ）にフルＴＳ７０を示している。フルＴＳ７０は、ＴＳパケットが連続して配置されており、例えば３つの番組Ｘ，ＹおよびＺのデータを含む。図７（ｂ）は、デジタルチューナ２０１ａによってフルＴＳ７０から生成されたパーシャルＴＳ７１を示す。パーシャルＴＳ７１は、連続したフルＴＳから一部のパケットを取り出したストリームであるため、パケットが時間的に離散して存在している。このパケットの間隔は、フルＴＳの送信側によって調整されており、デコーダにおいてデコードが適正に行われるために必要な条件を満たす。この「条件」とは、ＭＰＥＧ−２ＴＳでデコーダモデルとして規定されたＴ−ＳＴＤ（ＴＳシステムターゲットデコーダ；ＴＳ  Ｓｙｓｔｅｍ  Ｔａｒｇｅｔ  Ｄｅｃｏｄｅｒ）のバッファメモリがオーバーフローおよびアンダーフローなどの不具合を引き起こさないためにＭＰＥＧ規格上定められた条件である。【００６７】  パーシャルＴＳ７１は、例えば番組Ｘに関するＴＳパケットを含んでいる。【００６８】  図７（ｃ）は、クリップＡＶストリーム７２を示す。クリップＡＶストリーム７２は、ソースパケットが連続して配列されている。各ソースパケットは、ソースパケット番号（ＳＰＮ）＃０、１、２・・・で区別される。【００６９】  図７（ｄ）は、ソースパケット７３のデータ構造を示す。ソースパケット７３のデータ長は１９２バイトに固定されている。すなわち、各ソースパケット７３は、１８８バイトのＴＳパケット７５の前に、４バイトのＴＰエクストラヘッダ７４を付加して構成されている。ソース・パケタイザ２６１は、パーシャルＴＳを構成するＴＳパケットの前にＴＰエクストラヘッダ７４を付加することにより、ソースパケットを生成している。【００７０】  図７（ｅ）は、ＴＰエクストラヘッダ７４のデータ構造を示す。ＴＰエクストラヘッダ７４は、２ビットのコピー許可インジケータ（ＣＰＩ）７６と、３０ビットの到着タイムスタンプＡＴＳ７７とから構成されている。コピー許可インジケータ（ＣＰＩ）７６は、そのビット値に応じて、クリップＡＶストリーム７２の全部または一部のコピー回数（０回（コピー不可）／１回のみ／制限なし等）を規定している。到着タイムスタンプＡＴＳ７７には、２７ＭＨｚ精度で時刻が���述される。【００７１】  次に、図８を参照しながら、クリップＡＶストリームがどのようにＢＤ２０５ａ上に記録されるかを説明する。なお、本実施形態においては、クリップＡＶストリームはメモリカード１１２、１１３等のＢＤ２０５ａ以外の記録媒体にも書き込まれる。メモリカード１１２、１１３においては、ＢＤ２０５ａとは異なるファイルシステム（本実施形態ではＦＡＴ３２ファイルシステム）が採用されている。よって、以下ではまず、クリップＡＶストリームがＢＤ２０５ａに書き込まれるときの態様を説明し、その後、クリップＡＶストリームがＦＡＴ３２ファイルシステムを採用する記録媒体に書き込まれるときの態様を説明する。【００７２】  なお、クリップＡＶストリームはＨＤＤ２０５ｂにも記録され得る。このとき、ＢＤ２０５ａのファイルシステムおよびＦＡＴ３２ファイルシステムのいずれを採用して記録してもよい。ただし、ＨＤＤ２０５ｂは一般にレコーダ１００から取り外されて他の機器に装填されることはないため、独自のデータ構造によってデータを記録してもよい。【００７３】  図８は、ＢＤ２０５ａの記録領域と、そのディレクトリ／ファイル構造を示す。ＢＤ２０５ａは、ギャザード・ファイル領域８１−１とリアルタイム・データ領域８１−２とを有する。ギャザード・ファイル領域８１−１の記録容量は数百メガバイトである。ギャザード・ファイル領域８１−１には、クリップＡＶストリームの再生等を管理する管理情報のファイル（データベースファイル）が記録される。図８に示すように、データベースファイルは複数種類存在しており、例えば管理ファイル８２（Ｉｎｆｏ．ｂｄａｖ）、プレイリストファイル８３（０１００１．ｒｐｌｓ、１００００．ｖｐｌｓ）、クリップ情報ファイル８４（０１０００．ｃｌｐｉ）が存在する。これらはアクセスされる頻度が高い。よって、ギャザード・ファイル領域８１−１は効率的にアクセスが可能な、ＢＤ２０５ａの記録領域の中間部に設けられている。また、データベースファイルはクリップＡＶストリーム等の動画ストリームを再生するために必須であり、記録内容の誤りは重大な障害を引き起こす。そのため、データベースファイルは同じＢＤＡＶディレクトリ内のＢＡＣＫＵＰディレクトリ（図示なし）にバックアップされてもよい。【００７４】  一方、リアルタイム・データ領域８１−２の記録容量は片面単層のＢｌｕ−ｒａｙディスクであれば２３〜２７ギガバイトである。リアルタイム・データ領域８１−２には、クリップＡＶストリームのストリームファイルが記録される。例えばクリップＡＶストリームファイル８５（０１０００．ｍ２ｔｓ）が記録される。先のデータベースファイルと異なり、ストリームファイルの再生誤りの影響は局所的であり、その一方、連続的な読み出しを確保する必要がある。よって、誤りの発生を低減するよりも、連続読み出しを保証する方に重点をおいた書き込み処理が行われる。具体的には、クリップＡＶストリームファイル８５は最小で１２Ｍバイトの連続領域（連続した論理セクタ）に記録される。この最小の記録データサイズは「エクステント」と呼ばれる。なお、リアルタイム・データ領域８１−２には、ＤＶストリームを記録することもできる��、以下ではクリップＡＶストリームが記録されているとして説明する。【００７５】  次に、図９を参照しながら、上述の管理ファイル８２、プレイリストファイル８３、クリップ情報ファイル８４およびクリップＡＶストリームファイル８５相互の関係を説明する。図９（ａ）〜（ｄ）は、管理情報とストリームデータとの関係を示す。図９（ａ）〜（ｃ）が管理情報であり、図９（ｄ）がストリームデータである。図９（ａ）は管理ファイル８２（Ｉｎｆｏ．ｂｄａｖ）に記述されるプレイリストのテーブルを示す。すなわち、管理ファイル８２には、ＢＤ２０５ａ上に存在するプレイリストを特定するプレイリストファイル名のテーブルが格納されている。ここで「プレイリスト」とは、１以上のクリップＡＶストリームの一部または全部に跨る再生経路を規定した情報である。【００７６】  図９（ｂ）は、プレイリストファイル８３（拡張子：ｒｐｌｓ／ｖｐｌｓ）に記述されるプレイリストを示す。プレイリストは、リアルプレイリストおよびバーチャルプレイリストに分類できる。リアルプレイリストは、例えば初めてストリームデータが記録されたときにレコーダ１００によって生成されるプレイリストであり、再生経路として動画の最初から最後までが指定される。一方、バーチャルプレイリストは、記録されたストリームデータに対してユーザが設定したプレイリストであり、ユーザの希望する任意の位置および区間が指定される。【００７７】  プレイリストの各区間は、プレイリスト内の各プレイアイテムにおいて規定される。すなわち、プレイアイテムには、再生開始位置に対応する開始時刻（Ｉｎ＿ｔｉｍｅ）および再生終了位置に対応する終了時刻（Ｏｕｔ＿ｔｉｍｅ）が記述される。開始時刻および終了時刻は、映像のフレームの再生表示時刻や音声のフレームの再生出力時刻を特定するプレゼンテーションタイムスタンプ（ＰＴＳ）によって記述される。通常、記録直後のリアルプレイリストではプレイアイテムは１つだけ設けられ、動画の最初と最後の時刻が指定される。一方、バーチャルプレイリストではプレイアイテムの数は任意である。１つのバーチャルプレイリストに複数のプレイアイテムを設け、各プレイアイテムが異なる動画ストリームを指定するように記述することもできる。【００７８】  図９（ｃ）はクリップ情報ファイル（拡張子：ｃｌｐｉ）に記述される時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）を示す。変換テーブル（ＥＰ＿ｍａｐ）８４は、クリップＡＶストリームの再生時刻と、その時刻に再生されるデータが格納されたアドレスとを対応付けたテーブルである。この変換テーブル８４を利用することにより、プレイアイテムにおいて指定される開始時刻（Ｉｎ＿ｔｉｍｅ）および終了時刻（Ｏｕｔ＿ｔｉｍｅ）から、その時刻に再生すべきデータが格納されたクリップＡＶストリームにおけるアドレスを特定することができる。なお、この変換テーブル８４を利用した変換の原理は、後に図１３から図１５を参照しながら詳述する。【００７９】  図９（ｄ）は、クリップＡＶストリームファイル８５（拡張子：ｍ２ｔｓ）に格納される動画ストリームを示す。この図では、ファイル“０１０００．ｍ２ｔｓ”および“０２０００．ｍ２ｔｓ”の各々がクリッ���ＡＶストリームファイルである。【００８０】  図９（ｃ）および（ｄ）に示すように、ＢＤ２０５ａ上では、１つのクリップＡＶストリームファイルに対して１つのクリップ情報ファイルが設けられる。以下では、クリップＡＶストリームファイルと、クリップ情報ファイルの対を、クリップ（Ｃｌｉｐ）と称する。【００８１】  図１０は、プレイリストファイル８３に格納される情報（エントリ）およびそのデータ構造を示す。拡張子“ｒｐｌｓ”および“ｖｐｌｓ”ファイル８３内にはＰｌａｙＬｉｓｔ（）として示すエントリが存在する。これが上述の「プレイリスト」に対応する。プレイリスト情報（ＰｌａｙＬｉｓｔ）の下位には、プレイアイテム（ＰｌａｙＩｔｅｍ）１、２・・・が記述される。各プレイアイテムには再生対象となるクリップ情報ファイルのファイル名（Ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ）、ＳＴＣを特定するための識別子（ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ）、開始時刻（Ｉｎ＿ｔｉｍｅ）、終了時刻（Ｏｕｔ＿ｔｉｍｅ）等が格納される。なお、プレイリストファイル８３には、“プレイリストマーク（ＰｌａｙＬｉｓｔＭａｒｋ）”として示すエントリを設けることもできる。プレイリストマークの機能は後述する。【００８２】  図１１および図１２は、クリップ情報ファイル８４に格納される情報（エントリ）およびクリップ情報ファイルのエントリに関するデータ構造を示す図である。クリップ情報ファイル８４には、種々のエントリが設けられている。このうち、図１１にはさらに、クリップ関連情報（ＣｌｉｐＩｎｆｏ）の詳細なデータ構造とシーケンス情報（ＳｅｑｕｅｎｃｅＩｎｆｏ）の詳細なデータ構造とが示されている。クリップ関連情報（ＣｌｉｐＩｎｆｏ）にもまた、複数のエントリが存在する。図１１には、クリップ関連情報に含まれる１つのエントリ（ＴＳ＿ｔｙｐｅ＿ｉｎｆｏ＿ｂｌｏｃｋ）の詳細なデータ構造が示されている。【００８３】  また図１２によれば、特徴点情報（ＣＰＩ）内のエントリとして時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）が設けられていることが理解される。このテーブルは、１以上のクリップＡＶストリームごとに設けられた時間・アドレス変換テーブル（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ）の集合である。テーブル８６は、クリップＡＶストリームごとの時間・アドレス変換テーブル（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ）のデータ構造を示している。他のエントリ（ＣｌｉｐＭａｒｋ）等に関しては後述する。変換テーブル（ＥＰ＿ｍａｐ）は、録画した番組ごと、換言すれば記録したビデオＴＳパケットのＰＩＤごとに設けられる。【００８４】  なお、図１２のＣＰＩテーブルに示されるように、ＥＰ＿ｍａｐに代えてＴＵ＿ｍａｐを設けることもできる。ＴＵ＿ｍａｐとは、パケットの到着時刻（ＡＴＳ）とソースパケット番号との対応を示すテーブルである。パケットの到着時刻のエントリは、例えば１秒間隔で設けられる。そして、その時刻の直後に最初に受け取られたＴＳパケットから生成されたソースパケットの番号が、その時刻に対応付けられる。【００８５】  次に、図１３から図１５を参照しながら、時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）のデー���構造と、変換テーブル８４を利用した時間−アドレス変換の原理を説明する。図１３は、時間・アドレス変換テーブルのデータ構造を示す。変換テーブルでは、時間を示すタイムスタンプ（ＰＴＳ）とアドレスを示すソースパケット番号（ＳＰＮ）とが対応付けられている。このタイムスタンプ（ＰＴＳ）は、映像に関していえばＭＰＥＧ規格のＧＯＰの先頭に配置される各ＩピクチャのＰＴＳを表す。またソースパケット番号（ＳＰＮ）とは、そのＰＴＳに対応する時刻に再生されるＩピクチャの先頭データが格納されたソースパケット番号（ＳＰＮ）である。ソースパケットのデータサイズは１９２バイトであるから、ソースパケット番号が特定されるとクリップＡＶストリームの先頭からのバイト数が特定され、そのデータに容易かつ確実にアクセスできる。なお、この変換テーブルにおけるソースパケット番号Ｘ１、Ｘ２等の実際の値は必ずしも連続する整数ではなく、飛び飛びに大きくなっていく整数値である。【００８６】  図１４は、第１の例による時間とアドレスの対応を示す。上述のように、時間・アドレス変換テーブルにはＧＯＰの先頭に配置される各ＩピクチャのＰＴＳ値のみが記述されているため、そのＰＴＳ値以外のＰＴＳ値が開始時刻（Ｉｎ＿ｔｉｍｅ）および／または終了時刻（Ｏｕｔ＿ｔｉｍｅ）として指定されると、その時刻に対応するアドレス（ソースパケット番号）を直接得ることができない。しかし、ＭＰＥＧ−２ビデオの符号化圧縮方式では、ピクチャ間の差分を用いて圧縮処理を行うため、最初にＧＯＰ先頭のＩピクチャを復号しなければ、続くピクチャも復号できない。したがって、Ｉピクチャのエントリが記述されていれば実際の再生には問題なく、それ以上のピクチャ単位の再生制御は、時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）で指定されるＩピクチャから復号を開始し、続くピクチャを解析／復号しながら、期待されるピクチャだけを表示処理すればよいことになる。【００８７】  図１５は、第２の例による時間とアドレスの対応を示す。図１４の例と異なる点を説明する。放送番組の録画は、１つの番組のみならず連続する複数の番組に亘る場合がある。このとき、ＰＴＳやソースパケット番号の値は１つの番組内（パーシャルＴＳ内）では一意に定められているが、番組相互での調整はされていない。よって、ＰＴＳやソースパケット番号の値は、２つ以上の番組において重複する場合がある。したがって、そのような場合にも時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）によって確実に時間とアドレスとの変換を可能にする必要がある。そこで、特定の再生ポイントを一意に特定するための情報（ＳＴＣ＿ＩＤ）を規定し、時刻情報とともにソースパケット番号を特定するために利用する。【００８８】  まず、最初に録画されている番組に対し、ＳＴＣ＿ＩＤ＝０を与える。図６に関連して説明したように、各パーシャルＴＳは独自のシステム時刻基準ＳＴＣに基づいて処理されるため、番組の切り替え点においてはシステム時刻基準ＳＴＣが不連続になる。図１５には、番組Ａ、ＢおよびＣを録画したときにおいて、番組ＡとＢ、および、番組ＢとＣとの間にＳＴＣ不連続点が存在する例を示す。各タイミングにおいて異なるＳＴＣ＿ＩＤが設定されてい���。図１５では、最初の番組ＡはＳＴＣ＿ＩＤ＝０、次の番組ＢはＳＴＣ＿ＩＤ＝１、最後の番組ＣはＳＴＣ＿ＩＤ＝２である。さらに、１つのＳＴＣ＿ＩＤのストリームの最長再生時間を規定することで、同一のＳＴＣ＿ＩＤ内でも同一のＰＴＳが存在しないことを保証している。なお、ＭＰＥＧのＰＴＳは９０ＫＨｚ精度で３３ビット長であるため、約２６．５時間までであれば一意のＰＴＳを与えて表示時刻を正しく記述できる。【００８９】  上述のようにＳＴＣ＿ＩＤを割り当てておくことにより、時刻情報（Ｉｎ＿ｔｉｍｅ／Ｏｕｔ＿ｔｉｍｅ）およびＳＴＣ＿ＩＤに基づいて、本来指定されたとおりの適切なソースパケット番号を得ることができる。図１０に示すＰｌａｙＩｔｅｍ（）には、開始時刻（ＩＮ＿ｔｉｍｅ）および終了時刻（ＯＵＴ＿ｔｉｍｅ）の情報とともにＳＴＣ＿ＩＤを特定するためのエントリ（ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ）が設けられていることが理解される。【００９０】  なお、カムコーダ１１０のように、その機器自らが映像信号をエンコードしてクリップＡＶストリームを生成するときには、１回の録画開始から終了までの、一連続な記録区間内でＳＴＣを不連続にする必要はない。このようなときには、その一連続な記録区間中ではＳＴＣが不連続にならないように機器の動作を制限してもよい。なお、レコーダ１００が映像信号を受け取って、ＡＤＣ２０２およびエンコーダ２０３を利用してエンコードするときも同様である。【００９１】  次に、図１６から図１９を参照しながら、バーチャルプレイリストを利用したクリップＡＶストリームの編集処理を説明する。図１６（ａ）は、リアルプレイリスト１および２と、対応するクリップ１および２を示す。クリップ１の一部およびクリップ２の一部を連続して再生するバーチャルプレイリストを生成することを考える。図１６（ｂ）は、ＩＮ１からＯＵＴ１までの第１区間およびＩＮ２からＯＵＴ２までの第２区間を連続して再生するバーチャルプレイリストを示す。第１区間および第２区間はそれぞれバーチャルプレイリスト内の別個のプレイアイテムによって指定される。バーチャルプレイリストによれば、リアルプレイリスト１および２およびクリップ１および２を直接加工することなく、別個のクリップの一部の再生区間を見かけ上つなぎ合わせることができる。【００９２】  しかしながら、前述の通り、ＭＰＥＧ−２ビデオ圧縮方式はピクチャ間の差分を用いて圧縮しているため、ＩＮ２で飛び込んだ直後のピクチャは、そのピクチャの復号に必要な先行するピクチャのデータが取得されていないために通常復号できず、しばらく映像が表示されないことになる。【００９３】  映像のみに関し、シームレスな再生を実現するためには、もともとのストリームを破壊編集し、接続点でのビデオの再エンコードする必要がある。このとき、プレイアイテムの接続情報（ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ）は「４」に設定される。しかしながら、破壊編集は元の映像が残らない編集である。そこで、破壊編集のような元のストリームの編集は行わずに、接合点付近のストリームを集め、シームレス接続できるように再エンコード処理した「ブリッジクリップ」というクリップを新たに設けることができる。再生時は、つなぎ目の直前でブリッジクリップに再生制御を切り替え、ブリッジクリップの再生後に第２区間の再生に移る。これにより、矛盾のない滑らかな場面の切り替えを実現することができる。なお、このブリッジクリップによる接続情報は「３」に設定される。【００９４】  図１７（ａ）は、図１６（ｂ）のバーチャルプレイリストを分割するときの分割点の位置を示す。図１７（ｂ）は、分割されたバーチャルプレイリスト１および２を示す。バーチャルプレイリスト１は、リアルプレイリスト１の区間とリアルプレイリスト２の一部の区間の連続再生を規定する。一方、バーチャルプレイリスト２は、リアルプレイリスト２の残りの区間の再生を規定する。【００９５】  図１７（ａ）および（ｂ）に示す処理とは逆の処理、すなわち複数のバーチャルプレイリストを併合することもできる。図１８（ａ）は、併合の対象であるバーチャルプレイリスト１および２を示す。図１８（ｂ）は、１つに併合されたバーチャルプレイリストを示す。【００９６】  図１７（ａ）および（ｂ）の例においても、また図１８（ａ）および（ｂ）の例においても、バーチャルプレイリストを用いることにより、リアルプレイリスト１および２およびクリップ１および２を直接加工することなく、クリップを見かけ上分割し、または併合することができる。【００９７】  一方、リアルプレイリストの部分削除の場合には、クリップおよびリアルプレイリストを直接加工する必要がある。図１９（ａ）は、区間Ａ−Ｂを削除の対象とするリアルプレイリストおよびクリップを示す。そして、図１９（ｂ）は、区間Ａ−Ｂを削除して、点ＡおよびＢの位置を結合したリアルプレイリストおよびクリップを示す。リアルプレイリストの部分削除および削除の場合にのみクリップおよびリアルプレイリストを直接加工する理由は、リアルプレイリストのみが映像・音声データと直接の因果関係を持つためである。つまり、レコーダ上のユーザーインターフェースにおいて、ユーザにクリップを認識させず、リアルプレイリスト（ユーザにとって、クリップと同じ意味を持つ）とバーチャルプレイリスト（単なる再生経路情報）のみを提示することを想定しているためである。【００９８】  次に、図２０を参照しながらサムネイルピクチャの管理を説明する。図２０は、ＢＤ２０５ａにおいて管理されるサムネイルピクチャと管理ファイルとの関係を示す。サムネイルピクチャとは、動画の一場面や静止画等の縮小されたピクチャであり、動画や静止画の内容を容易に確認する目的で設けられる。【００９９】  サムネイルピクチャに関連するデータは、複数のファイルに格納される。図２０には、サムネイルピクチャを管理するメニューサムネイルファイル３０２およびマークサムネイルファイル３０４が示されている。メニューサムネイルファイル３０２は、ＢＤ２０５ａやプレイリストのサムネイルに関するインデクス情報を格納している。このインデクス情報は、メニューサムネイルファイル３０２において管理されるサムネイルピクチャ（サムネイルピクチャ３０２ａ、３０２ｂ等）の管理番号（ｍｅｎｕ＿ｔｈｕｍｂｎａｉｌ＿ｉｎｄｅｘ）を含む。サムネイルピクチャ３０２ａはバーチャルプレイリスト３１２の代表的な内容を示す。また、サムネイルピクチャ３０２ｂはボリュームサムネイルと呼ばれ、本ＢＤＡＶディレクトリの全体に関する代表的な内容を示す。なお図８には、メニューサムネイルファイル３０２に対応する“ｍｅｎｕ．ｔｉｄｘ”ファイルと、各サムネイルピクチャの実体データを示す“ｍｅｎｕ．ｔｄｔ（ｎ）”（ｎ＝１，２・・・）が示されている。【０１００】  一方、マークサムネイルファイル３０４は、所望の映像の位置に付加され、しおりとして機能する「マーク」のサムネイルに関するインデクス情報を格納している。このインデクス情報も同様に、マークサムネイルファイル３０４において管理されるサムネイルピクチャ（サムネイルピクチャ３０４ａ、３０４ｂ、３０４ｃ等）の管理番号（ｍａｒｋ＿ｔｈｕｍｂｎａｉｌ＿ｉｎｄｅｘ）を含む。サムネイルピクチャ３０４ａはバーチャルプレイリスト３１２内のマークが付加された位置の縮小画像である。サムネイルピクチャ３０４ｂはリアルプレイリスト３１４内のマークが付加された位置の縮小画像である。また、サムネイルピクチャ３０４ｃはクリップ３１６内のクリップマークが付加された位置の縮小画像である。なお図８には、マークサムネイルファイル３０４に対応する“ｍａｒｋ．ｔｉｄｘ”ファイルと、各サムネイルピクチャの実体データを示す“ｍａｒｋ．ｔｄｔ（ｎ）”（ｎ＝１，２・・・）が示されている。上述の各サムネイルピクチャのデータは、ＪＰＥＧ規格に基づいて圧縮符号化されている。【０１０１】  上述のメニューサムネイルファイル３０２およびマークサムネイルファイル３０４を利用すると、サムネイルピクチャを一覧表示したり、特定のマークのみのサムネイルピクチャを選択的に表示させることができる。これにより、ユーザはそのＢＤ２０５ａで管理されている動画の概要、種々のプレイリストの概要、または、特定のプレイリストの複数の場面の概要を容易に把握できる。【０１０２】  図２１（ａ）〜（ｃ）は、それぞれ、マークが付加されたバーチャルプレイリスト３１２、リアルプレイリスト３１４およびクリップ３１６を示す。ＢＤ２０５ａではユーザは複数種類のマークを設定することができる。すなわち、所望の動画等（コンテンツ）の頭出し点を指定する「ブックマーク」、再生を飛ばす点（区間）を指定する「スキップマーク」、および、先に視聴を停止したコンテンツの位置を指定する「レジュームマーク」、チャプターの先頭を指定する「チャプターマーク」等である。【０１０３】  図２１（ａ）に示すバーチャルプレイリスト３１２には、ブックマークおよびレジュームマークが設定されている。これらのマークは、プレイリストファイル（拡張子：ｖｐｌｓ）の“ＰｌａｙＬｉｓｔＭａｒｋ”エントリに記述される。図１０には、“ＰｌａｙＬｉｓｔＭａｒｋ”エントリに対応するＰｌａｙＬｉｓｔＭａｒｋ（）が記載されている。ＰｌａｙＬｉｓｔＭａｒｋ（）において、“ｍａｒｋ＿ｔｙｐｅ”は、ブックマーク、レジュームマーク等のマークの種類を特定する情報である。“ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ”は、マークが設定されるピクチャのタイムスタンプ（ＰＴＳ）を特定する情報である。各マークにはサムネイルピクチャを対応付けることもできる。図２１（ａ）に示すサムネ���ルピクチャ３０４ａは、ブックマークが設定された場面の縮小画像である。バーチャルプレイリスト３１２に設定されたサムネイルピクチャ３０４ａは、マークサムネイルファイル３０４において管理される。【０１０４】  次に、図２１（ｂ）に示すリアルプレイリスト３１２には、ブックマーク、レジュームマークおよびスキップマークが設定されている。スキップマークについても、スキップ開始位置のサムネイルピクチャ３０４ｂを設定できる。またスキップする期間（ｄｕｒａｔｉｏｎ）もあわせて設定できる。【０１０５】  図２１（ｃ）に示すクリップ３１６には、クリップマークが設定されている。クリップマークは、クリップＡＶストリームを生成した際にレコーダ１００が付加するマークである。ユーザはクリップマークの生成に関与できず、また生成されたクリップマークの削除等にも関与できない。クリップマークは、クリップに直接付加されるため、プレイリスト３１２および３１４に基づく再生時にもその機能は有効である。なお、クリップマークにもサムネイルピクチャ３０４ｃが設定され得る。【０１０６】  上述の各マークには、録画機器（例えばレコーダ１００）のメーカごとのＩＤ（ｍａｋｅｒ＿ＩＤ）と独自情報（ｍａｋｅｒｓ＿ｐｒｉｖａｔｅ＿ｄａｔａ）を付加することもできる。これにより、マークを用いてメーカ独自に機器の機能を拡張することができる。【０１０７】  これまでは、ＵＤＦのような映像・音声データファイルの扱いに優れたファイルシステムを利用した、動画ストリームの記録、編集、再生を説明した。次に、ＰＣで広く利用されているＦＡＴ３２ファイルシステムを利用した動画ストリームの記録、編集、再生を説明する。【０１０８】  ＦＡＴ３２ファイルシステムは、映像・音声データファイルを主として扱うために策定されていないため、ＦＡＴ３２ファイルシステム上の各種ファイルのデータ構造を、これまでに説明したファイルシステム上のデータ構造と同じにすることは適切ではない。その理由は、ＦＡＴ３２ファイルシステムの制約により、４ＧＢを超えるファイルを記録することはできないからである。番組の録画や映像の撮影が長時間にわたると、動画ストリームのデータが４ＧＢを超える可能性は十分にある。以下、図２２および図２３を参照しながら、これまで説明したデータ構造をそのままＦＡＴ３２ファイルシステムにおいて適用したときの問題をより詳しく説明する。【０１０９】  図２２（ａ）〜（ｄ）は、ＦＡＴ３２ファイルシステムにおいて、クリップＡＶストリーム８５および対応する管理情報ファイル８２〜８４を設けたときの第１の例を示す。図２２（ｄ）は、連続して撮影／録画された動画のデータが複数のファイルに分割して記録されていることを示す。なお、図２２（ａ）の管理ファイル８２は図９（ａ）の管理ファイルと同じであるため、説明は省略する。【０１１０】  図２２（ｃ）および（ｄ）に示すように、ＦＡＴ３２ファイルシステムにおいては、連続して撮影／録画された動画が複数のクリップに分割されて格納されることがある。より詳細に説明すると、図２２（ｄ）のクリップＡＶストリームファイル８５は、（ｃ）のクリップ情報ファイル８４と１対１で生成され、その組がクリップとして��義される。ＦＡＴ３２ファイルシステムは４ＧＢ以上のファイルサイズを扱うことができないため、連続して撮影／録画された動画のデータが非常に大きくなると、４ＧＢ未満のクリップＡＶストリームファイルが複数生成され得る。するとその都度クリップ情報ファイル８４も生成され、結果としてクリップが複数生成される。これらのクリップにわたって映像を再生するためには、再生経路情報（プレイリスト）を設けて複数のクリップ間のつながりを規定し、一つの再生シーケンスとして設定する必要がある。図２２（ｂ）に示すプレイリストファイル８３（０１００１．ｒｐｌｓ）は、複数のクリップを一つの再生シーケンスとして連結したときの例を示す。なお、図９に示すようなＵＤＦを用いると、連続して撮影／録画された動画を１クリップとして収めることができる。【０１１１】  次に、図２３を参照する。図２３（ａ）および（ｂ）は、編集前後のクリップを示す。図２３（ａ）は、図２２で生成されたプレイリストに対するクリップの編集範囲を示す。図２３（ａ）の例では、０１００２．ｍ２ｔｓファイルのストリームの途中を削除する編集を行うとする。このときクリップ情報ファイル（０１００２．ｃｌｐｉ）の対応する範囲の情報も削除される。図２３（ｂ）は、編集後のクリップ（０１００２．ｃｌｐｉファイルおよび０１００２．ｍ２ｔｓファイル）を示す。【０１１２】  図２３（ａ）に示す編集前の状態では、連続して記録された動画ストリームのＳＴＣ＿ｉｄは１つ（ＳＴＣ＿ｉｄ＝１）である。このときは、複数のクリップＡＶストリームファイルにわたる１つのＳＴＣシーケンスが存在している。【０１１３】  しかし、編集後の０１００２．ｍ２ｔｓファイルには、図２３（ｂ）にＳＴＣ＿ｉｄ＃１および＃２として示されるように２つのＳＴＣシーケンスが存在する。すなわち、１つの動画ファイル内に複数のＳＴＣシーケンスが存在する。なお、クリップＡＶストリームファイル０１００１．ｍ２ｔｓおよび０１００３．ｍ２ｔｓファイルには、引き続き複数のクリップＡＶストリームファイルにわたる１つのＳＴＣシーケンスが存在している。また、編集内容によっては、１つの動画ストリーム内に１つのＳＴＣシーケンスが存在することもある。【０１１４】  今後、このような編集処理（部分削除処理）が繰り返されると、一つの動画ストリームを格納するファイルと、その中に格納されるＳＴＣシーケンスとの包含関係がさらに複雑に変動することが容易に理解される。【０１１５】  また、半導体メモリ１１２のような比較的小型かつ小容量の記録媒体を利用して動画ストリームを記録する場合には、レコーダ装置にメモリカードスロットを複数用意できるため、異なる半導体メモリに跨って動画ストリーム（または一つのプレイリスト）が記録されることも想定される。そうなれば、記録媒体、動画ストリームファイル、ＳＴＣシーケンスの３者間の相関がさらに複雑になり得る。その結果、処理の複雑化および遅延が生じ得る。【０１１６】  そこで、本実施形態においては図２４〜図２６に示す新たなデータ構造を規定して、柔軟なデータの管理を実現する。具体的には、１つにクリップＡＶストリームファイルに１つの管理情報ファイル（クリップ情報ファイル��を対応させるのではなく、１または複数のクリップＡＶストリームファイルと１つの管理情報ファイル（クリップ情報ファイル）とを対応させる。１つの管理情報ファイルだけで複数のストリームを管理すると、後述のようにタイムマップ（ＥＰ＿ｍａｐ）のみを参照すればこれらのファイルとシーケンスの関係を得ることができる。その結果、再生すべき映像は、ＰＴＳとＳＴＣシーケンスのみを利用して指定される。【０１１７】  新たなデータ構造は、レコーダ１００、ＰＣ１０８、カムコーダ１１０のいずれもが構築できる。以下では、図５に示すレコーダ１００が新たなデータ構造を構築するとして説明する。【０１１８】  レコーダ１００のエンコーダ２０３および／またはＣＰＵ２１１は、アナログ信号に基づいて映像を記録する時、および、デジタル信号に基づいて映像を記録する時のいずれにおいても、図２４〜図２６に示すデータ構造を構築できる。そこで、以下ではアナログ信号に基づいて映像が記録される例を説明する。記録媒体は、ＦＡＴ３２ファイルシステムを採用するメモリカード１１２であるとする。【０１１９】  この例においては、エンコーダ２０３は、図４（ｄ）、（ｃ）、（ｂ）および（ａ）の順に処理を行って、トランスポートストリームを生成する。エンコーダ２０３は、各ピクチャのＰＴＳ等も同時に生成して、図４（ｂ）に示すＰＥＳヘッダ４１ａ−１に格納する。生成されたトランスポートストリームに基づいて、ＴＳ処理部２０４はクリップＡＶストリームを生成する。【０１２０】  一方、ＣＰＵ２１１は管理情報を生成する。エンコーダ２０３およびＣＰＵ２１１は、ＣＰＵバス２１３を介して、クリップＡＶストリームおよび管理情報をメモリカード制御部２１７に送る。メモリカード制御部２１７は、クリップＡＶストリームおよび管理情報を受け取り、メモリカード１１２に書き込む。図２４（ａ）〜（ｄ）は、本実施形態による、ＦＡＴ３２ファイルシステムにおいて好適な管理情報ファイル８２〜８４とクリップＡＶストリームファイル８５の関係を示す。図２４（ａ）〜（ｄ）に示す各ファイルは、例えばカムコーダ１１０を利用して動画が連続的に撮影されたときにメモリカード１１２に記録される。このメモリカード１１２は、ＦＡＴ３２ファイルシステムを採用する。いうまでもなく、メモリカード１１２の記録容量は全ファイルのファイルサイズの和以上である。【０１２１】  本実施形態による管理構造は、以下に示す２つの主要な特徴を備えている。【０１２２】  第１には、図２４（ｄ）に示すように、連続的に撮影された動画ストリームが複数のクリップＡＶストリームファイル（０２００１．ｍ２ｔｓ／０２００２．ｍ２ｔｓ／０２００３．ｍ２ｔｓ）に分割されていることである。上述のＦＡＴ３２ファイルシステムの制約により、各クリップＡＶストリームファイル８５のデータサイズは４ＧＢ未満である。【０１２３】  ここで留意すべきは、各クリップＡＶストリームファイル８５内のクリップＡＶストリームには、同じＳＴＣ＿ｉｄが与えられていることである。さらに、ソース・パケタイザ２６１（図６）によって付加されるＡＴＳの値も連続的に変化している。その意味は、動画が連続して撮影されている間は、ＡＴＳを生成するためのクロックカウンタ２６２およびＰＬＬ回路２６３はリセットされることなく動作を継続することである。複数のクリップＡＶストリームファイル８５が生成されるか否かには影響を受けない。【０１２４】  なお、クリップＡＶストリームファイルは動画を録画した直後において複数に分割されている必要はない。録画直後は１つであっても、編集等により複数のクリップＡＶストリームファイルが生成されてもよい。次に説明する管理情報を利用すれば、事後的に複数のクリップＡＶストリームファイルが生成されても統一的に動画ファイル群を管理できる。【０１２５】  第２の主要な特徴は、図２４（ｃ）に示すように、クリップ情報ファイル８４（０２００１．ｃｌｐｉ）がクリップＡＶストリームファイルの数にかかわらず１つ設けられていることである。このクリップ情報ファイル８４は、クリップＡＶストリーム全体にわたる時間・アドレス変換テーブル（ＥＰ＿ＭＡＰ）を規定している。このクリップ情報ファイル８４を利用すれば、指定された時刻に再生すべき映像のデータがどのクリップＡＶストリームファイル８５に格納されているのか、そして、そのクリップＡＶストリームファイル８５内のどの位置（何番目のソースパケット）に格納されているのかを特定できる。【０１２６】  なお、変換テーブルは、クリップＡＶストリームの全体にわたる時間とデータ位置（アドレス）との関係を規定している。よって、プレイリストファイル８３（０２００１．ｒｐｌｓ）内にはプレイアイテム（図１０）を１つ設ければ十分である。そのプレイアイテム内の開始時刻（Ｉｎ＿ｔｉｍｅ）および終了時刻（Ｏｕｔ＿ｔｉｍｅ）に、それぞれクリップＡＶストリーム先頭の時刻と末尾の時刻とを記述すればよい。【０１２７】  次に、図２５および図２６を参照しながら、クリップ情報ファイル８４内のデータ構造を説明する。【０１２８】  図２５は、時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）８７のデータ構造を模式的に示す。変換テーブル８７は、図１３に示す変換テーブルデータ構造を拡張して構成されている。具体的に説明すると、変換テーブル８７には時間（ＰＴＳ）およびアドレス（ＳＰＮ）との対応関係のみならず、そのソースパケットを含むファイル名が記述されている。なお、変換テーブル８７においても、タイムスタンプ（ＰＴＳ）はＭＰＥＧ規格のＧＯＰの先頭に配置される各ＩピクチャのＰＴＳを表すとする。【０１２９】  変換テーブル８７にファイル名を記述する理由は、１つのクリップＡＶストリームが図２４に示すように複数のファイルに分割して格納されたためである。すなわち、与えられた時刻（ＰＴＳ）とソースパケット番号（ＳＰＮ）との対応関係のみでは、与えられたＰＴＳに対応するソースパケットがどのファイルに含まれているかを特定できないためである。【０１３０】  なお、変換テーブル８７においては、ＰＴＳおよびＳＰＮの各値はコアースエントリ（ｃｏａｒｓｅ  ｅｎｔｒｙ）およびファインエントリ（ｆｉｎｅ  ｅｎｔｒｙ）に分けて格納されている。すべてのビットが記述されるのではない。例えば３３ビットのＰＴＳを例に挙げると、３３ビットのうち上位１７ビットをコアースエントリとし、下位１７ビットをファインエントリとして変換テーブル８７に記述する。最下位ビットから数えて１７ビット目はコアースエントリおよびファインエントリの両方に重複して規定されるが、これは設計上任意に変更できる。【０１３１】  コアースエントリが共通する１以上のＰＴＳはそのコアースエントリのグループに分類される。そのグループにおいては、コアースエントリは１つしか記述されない。一方、ファインエントリは、ＰＴＳごとに記述される。同じグループの各ＰＴＳは、ファインエントリによって識別できる。【０１３２】  上述のＳＰＮについても、まったく同様にコアースエントリおよびファインエントリが設けられる。そして、そのＳＰＮが与えられたソースパケットを含むファイル名も対応付けて記述される。なお、ファイル名はＳＰＮのすべてのファインエントリに対応して記述してもよいし、ＳＰＮのコアースエントリ単位で記述してもよい。【０１３３】  ＰＴＳの各ビットをコアースエントリおよびファインエントリに分けることにより、変換テーブル８７のデータ量を低減できる。ＰＴＳからＳＰＮへの変換処理、および、得られたＳＰＮに対応するソースパケットがどのファイルに属するかは後述する。【０１３４】  図２６は、変換テーブル８７の詳細なデータ構造を示す。変換テーブル８７は、大きく第１ループ８８、第２ループ８９および第３ループ９０に分けることができる。第１ループ８８のループ回数はＮｅ回、第２ループ８９のループ回数はＮｃ回、および第３ループ９０のループ回数はＮｆ回である。Ｎｅ、Ｎｃ、Ｎｆの各値はフィールド９１−１に記述されている。【０１３５】  第１ループ８８は、後述のファイルエントリに対応する。第１ループ８８は、少なくとも、記録媒体、１つの記録媒体内のクリップＡＶストリーム格納先のフォルダ、クリップＡＶストリームのファイル名のいずれか１つが変化するたびに繰り返される。換言すれば、クリップＡＶストリームが複数の記録媒体、複数の格納フォルダおよび／または複数のファイルにまたがって格納されても、第１ループ８８を利用して記述できる。【０１３６】  第１ループ８８は、例えばファイル名フィールド８８−１およびエントリＩＤフィールド８８−２を有している。ファイル名フィールド８８−１には、クリップＡＶストリームのファイル名が記述される。これにより、１つのクリップＡＶストリームが複数のファイルに跨ってもそのファイル名を記述できる。またエントリＩＤフィールド８８−２には、そのファイルに含まれるクリップＡＶストリームの先頭ソースパケットのファインエントリが記述される。【０１３７】  第２ループ８９および第３ループ９０は、ＰＴＳとＳＰＮとの対応関係を規定する。この対応関係に基づいて時間とアドレスとを変換することができる。【０１３８】  第２ループ８９は、ＰＴＳとＳＰＮの各コアースエントリが繰り返し記述される。第２ループ８９は、ファインＩＤフィールド８９−１、コアースフィールド８９−２および８９−３を有している。ファインＩＤフィールド８９−１は、各コアースエントリに対応する１以上のファインエントリを特定するために設けられる。コアースフィールド８９−２および８９−３は、それぞれＰＴＳコアースエントリおよびＳＰＮコアースエントリが記述��れる。【０１３９】  第３ループ９０は、ＰＴＳとＳＰＮの各ファインエントリが繰り返し記述される。第３ループ９０は、オフセットフィールド９０−１、ファインフィールド９０−２および９０−３を有している。オフセットフィールド９０−１は、Ｉピクチャデータの末尾までのオフセット値が格納されている。ファインフィールド９０−２および９０−３は、それぞれＰＴＳファインエントリおよびＳＰＮファインエントリが記述される。【０１４０】  なお、第１ループ８８には他のフィールドを設けることもできる。例えば、クリップＡＶストリームファイルが、どの記録媒体に記録されているかを識別するための記録媒体のシリアル番号等を記述するｍｅｄｉａ＿ｒｅｆ＿ｉｄフィールドや、そのストリームファイルがどのＢＤＡＶディレクトリに格納されているのかを示すＢＤＡＶ＿ｒｅｆ＿ｉｄフィールド等を設けることができる。ｍｅｄｉａ＿ｒｅｆ＿ｉｄフィールドを設けた理由は、複数の記録媒体を同時に装填可能なレコーダであれば分割されたクリップＡＶストリームファイルを異なる記録媒体に記録し得るため、各記録媒体を特定する必要が生じるからである。また、ＢＤＡＶ＿ｒｅｆ＿ｉｄフィールドを設けた理由は、ＢＤＡＶディレクトリは同じ記録領域（同一の記録媒体）に対して複数生成できるからである。【０１４１】  クリップＡＶストリームが１以上のストリームファイルとして書き込まれると、各ストリームファイルのファイル名、クリップＡＶストリーム内の各ソースパケットの配置等が確定する。よって、ＣＰＵ２１１は上述の変換テーブル８７の各エントリの内容を確定することができる。ＣＰＵ２１１は、変換テーブル８７をクリップ情報ファイルに格納してメモリカード１１２へさらに書き込む。【０１４２】  なお、ＣＰＵ２１１は、デジタル放送番組を録画する際にも変換テーブル８７を生成する。このときの処理は以下のとおりである。まずＣＰＵ２１１は、受信したトランスポートストリームを図４（ａ）から（ｃ）に示すデータ構造にしたがって解析する。そしてＣＰＵ２１１は、ピクチャヘッダ４２ａからＧＯＰヘッダおよびＩピクチャヘッダを検出してＧＯＰの先頭のＩピクチャを特定し、そのときのＰＥＳヘッダ４１ａ−１からＰＴＳを抽出する。これによりＣＰＵ２１１は、変換テーブル８７内のＰＴＳファインエントリを生成できる。一方、ＴＳ処理部２０４がトランスポートストリームからクリップＡＶストリームを生成したとき、ＣＰＵ２１１は、そのＧＯＰの先頭のＩピクチャのデータがどのソースパケットに格納されているかを特定できる。そのソースパケットが先頭から何番目に配置されているかにしたがって、ＣＰＵ２１１は、対応するＳＰＮファインエントリを生成できる。【０１４３】  上述のアナログ／デジタル放送番組のいずれの例においても、クリップＡＶストリームの現実の書き込みが完了しなくても、ＣＰＵ２１１はそのストリームを格納したファイルのファイル名を変換テーブル８７に記述することは可能である。ストリームファイルのファイル名等は、書き込み開始前には予め決定されているためである。【０１４４】  上述のように、本実施形態においては、一連の映像のデータストリームが複数のクリップＡＶストリ��ムファイルに分割される。そして、各ファイルが複数の記録媒体に格納され、および／または、複数のＢＤＡＶディレクトリに格納されることを想定している。このような複雑な記録態様のもとで的確に再生を行うため、変換テーブル８７にはさらに状態フィールド９１−２が設けられている。【０１４５】  例えば、変換テーブル８７が分割された全てのクリップＡＶストリームファイルの格納先を規定しているときには、レコーダ１００のＣＰＵ２１１は、状態フィールド９１−２に「１１」を記述する。一部のクリップＡＶストリームファイルの格納先のみを規定しているときには、状態フィールド９１−２に「１１」以外の値を記述する。レコーダ１００のＣＰＵ２１１は、全てのクリップＡＶストリームファイルの格納先が変換テーブル８７に記述されているか否かを判断できるため、その結果を状態フィールド９１−２に記述できる。再生時において状態フィールド９１−２の値を確認することにより、ＣＰＵ２１１は少なくとも全ての映像を再生できるか否かを特定できる。状態フィールド９１−２のさらに具体的な説明は、図３３を参照しながら後述する。【０１４６】  次に、図２７を参照しながら、変換テーブル８７を利用してクリップＡＶストリームのピクチャを再生する手順を説明する。以下では、レコーダ１００が、図２４に示すメモリカード１１２から、変換テーブル８７を格納したクリップ情報ファイル８４、クリップＡＶストリームファイル８５等を読み出し、それらに基づいてピクチャを再生するとして説明する。なお、図２４に示す管理ファイル８２、プレイリストファイル８３、クリップ情報ファイル８４等は、メモリカード１１２がレコーダ１００に装填されたときにメモリカード制御部２１７によって読み出され、ＲＡＭ２１２に格納されているとする。【０１４７】  図２７は、変換テーブル８７を利用して指定されたＰＴＳに対応するピクチャを再生する処理の手順を示す。まず、ステップＳ２７１において、システム制御部２５０のＣＰＵ２１１はピクチャの再生時刻を特定する情報（ＰＴＳ）を取得する。指定されるＰＴＳは、ユーザから指定された特定の再生時刻に対応するＰＴＳ値であってもよいし、早送り、早戻し再生等のときのＩピクチャの再生時刻に対応する値であってもよい。ここでは説明の簡単のため、ＧＯＰの先頭に配置されるＩピクチャのＰＴＳが指定されたとする。【０１４８】  与えられたＰＴＳは、３３ビットのうち上位１７ビットと下位１７ビットとに分けて、以下処理される。【０１４９】  ステップＳ２７２において、ＣＰＵ２１１は、与えられたＰＴＳ値の上位１７ビットを利用して、図２６の時間・アドレス変換テーブル８７（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ）中の第２ループ８９を参照し、そのＰＴＳが属するＰＴＳコアースエントリ８９−２および対応するＳＰＮコアースエントリ８９−３を特定する。また、同時にファインＩＤフィールド８９−１の値も特定される。ファインＩＤフィールド８９−１には、テーブル８７の第３ループ９０に関し、何番目のループを参照すればよいかを示す情報が記述されている。【０１５０】  次に、ステップＳ２７３において、ＣＰＵ２１１は、特定されたファインＩＤフィールド８��−１の値を利用してテーブル８７の第３ループ９０を参照し、ＰＴＳ／ＳＰＮコアースエントリに対応するＰＴＳおよびＳＰＮファインエントリ９０−２および９０−３を特定する。この結果、そのＰＴＳに対応するＳＰＮ（コアースエントリおよびファインエントリ）が特定される。【０１５１】  ステップＳ２７４においては、ＣＰＵ２１１は、ＳＰＮファインエントリ９０−３およびテーブル８７の第１ループ８８に基づいて、そのＳＰＮが付されたソースパケットを格納したファイル名を特定する。【０１５２】  この処理は具体的には以下のとおり行われる。上述のように、第１ループ８８内のエントリＩＤフィールド８８−２には、各ファイルに含まれるクリップＡＶストリームの先頭ソースパケットのファインエントリの値が記述される。そして先頭ソースパケットのファインエントリ８８−２と対応して、ファイル名フィールド８８−１にはファイル名が記述されている。【０１５３】  よって、ＣＰＵ２１１は、先のステップにおいて得られたＳＰＮファインエントリ９０−３の値が、エントリＩＤフィールド８８−２に記述されたファインエントリの値と等しいまたはそれよりも大きいか否かを判定する。等しいときには、ＣＰＵ２１１は、そのＳＰＮのファインエントリ８８−２と対応するファイル名フィールド８８−１からファイル名を特定する。大きいときには、ＣＰＵ２１１は、ＳＰＮファインエントリ９０−３の値が、次のエントリＩＤフィールド８８−２に記述されたファインエントリの値と同じまたはそれよりも大きいか否かを判定する。【０１５４】  この処理を繰り返すと、いずれかの時点で、ＳＰＮファインエントリ９０−３の値が、エントリＩＤフィールド８８−２に記述されたファインエントリの値と等しく、またはそれよりも小さくなる。等しくなるときは上述のとおりファイル名を特定する。小さくなったときは、そのとき参照していたエントリＩＤフィールドの１つ前のエントリＩＤフィールドに規定されたファイル名フィールド８８−１から、ファイル名を特定する。【０１５５】  その結果、ステップＳ２７５において、ＣＰＵ２１１はメモリカード制御部２１７に対して特定されたファイル名を指定して、１以上のソースパケットを読み出すよう指示する。読み出されるソースパケットは、先に特定されたＳＰＮが割り当てられたソースパケット以後の１以上のソースパケットである。ＴＳ処理部２０４は、読み出されたソースパケットを受け取り、図６に関連して説明した処理を行ったトランスポートストリームを、デコーダ２０６に送る。デコーダ２０６がピクチャを復号化すると、最終的にはアナログ信号としてＴＶ等へ出力され、再生が開始される。【０１５６】  図２４から図２６に示すクリップ情報ファイル８４によれば、映像を部分的に削除する編集が行われ、一つの動画ストリームを格納するファイルと、その中に格納されるＳＴＣシーケンスとの包含関係が複雑になったときにも十分対応できる。例えば、図２８（ａ）および（ｂ）は、本実施形態による編集前後のクリップを示す。編集前後のクリップ情報ファイル８４はいずれも１つである。【０１５７】  以下では、図２９および図３０を参照しながら、図２８（ｂ）におけるクリップ情報ファイル８４およびクリップＡＶストリームファイル８５をより詳しく説明する。【０１５８】  図２９（ａ）〜（ｄ）は、図２８（ｂ）に示す編集処理後のクリップ情報ファイルとクリップＡＶストリームファイルとの対応を示す。ここでは、図２８（ｂ）の１番目および２番目のクリップＡＶストリームファイル（０２００１．ｍ２ｔｓおよび０２００２．ｍ２ｔｓ）を示している。以下図２９（ａ）〜（ｄ）を参照しながら、ＣＰＵ２１１が時間・アドレス変換テーブルを生成する処理とともにそのデータ構造を説明する。【０１５９】  図２９（ａ）は、編集されたクリップＡＶストリームに対する、一つのクリップ情報ファイルに格納された時間・アドレス変換テーブルの概念を示す。図２９（ａ）の上から順に、１段目はファイルエントリが設けられている位置、２段目はコアースエントリが設けられている位置、３段目はファインエントリが設けられている位置を概念的に示している。【０１６０】  このようなテーブルを生成するにあたり、ＣＰＵ２１１は時間・アドレス変換テーブルをＳＴＣシーケンス単位で記述する。図２９（ｂ）は、２つのＳＴＣシーケンスの範囲をそれぞれ示す。０２００１．ｍ２ｔｓの全体および０２００２．ｍ２ｔｓの編集点までのストリームにはＳＴＣ＿ｉｄ＃１が与えられており、０２００２．ｍ２ｔｓの編集点以降のストリームにはＳＴＣ＿ｉｄ＃２が与えられているとする。これらは別個のＳＴＣシーケンスである。また、図２９（ｃ）は、クリップＡＶストリームが格納された２つのファイルを示す。【０１６１】  ＣＰＵ２１１は、まずＳＴＣシーケンス（ＳＴＣ＿ｉｄ＃１）の先頭（すなわちストリームファイル０２００１．ｍ２ｔｓの先頭）に対応するアドレスに関連付けて、テーブルにファイルエントリ＃０を登録する。ファイルエントリ＃０にはストリームファイルのファイル名（０２００１．ｍ２ｔｓ）が記述される。【０１６２】  ＳＴＣシーケンスが進むと、その途中において、クリップＡＶストリームを格納しているファイルがストリームファイル０２００１．ｍ２ｔｓから０２００２．ｍ２ｔｓに切り替わる。そこで、ＣＰＵ２１１は、その切り替わり位置に対応するアドレスに関連付けて、テーブルにファイルエントリ＃１を登録する。ファイルエントリ＃１には次のストリームファイルのファイル名（０２００２．ｍ２ｔｓ）が記述される。【０１６３】  図２６の第１ループ８８に示されるように、各ファイルエントリ８８−１とファインエントリ８８−２とは対応付けられて記述されている。本実施形態では、各ファイルエントリは、そのファイルエントリによって指定されたファイルにおいて最初に設けられたファインエントリと関連付けて第１ループ８８に格納される。【０１６４】  本実施形態においては、ＳＴＣ＿ｉｄ＃１が割り当てられたクリップＡＶストリームは、ＦＡＴ３２ファイルシステムの制約に起因して複数のファイル０２００１．ｍ２ｔｓおよび０２００２．ｍ２ｔｓに格納されている。したがって、これらのファイルに跨るクリップＡＶストリームは、本来的には途切れることなく連続的に再生することができる。【０１６５】  連続的な再生を保証するため、本実施形態においては、クリップＡＶストリームの各ソースパケットの��ッダ７４に格納されたＡＴＳの値は連続的かつ周期的に変化している。換言すれば、ＡＴＳの値は途切れることなく周期的に変化している。図２９（ｄ）は、複数のファイルに跨るクリップＡＶストリームのＡＴＳの変化を示す。ファイル０２００１．ｍ２ｔｓがファイル０２００２．ｍ２ｔｓに切り替わっている点においても、ＡＴＳの値は連続していることが理解される。【０１６６】  これまでは、ファイルが切り替わると、クリップＡＶストリームのＳＴＣ＿ｉｄも変化することが前提であった。よって、ＴＳ処理部２０４およびデコーダ２０６は、異なるファイルからのクリップＡＶストリームを解析するときには処理回路を一旦リセットしていた。これにより、デコーダ２０６内の参照ピクチャ等が一時的に格納されているバッファもクリアされ、再生される映像は途切れていた。【０１６７】  本実施形態においては、ＣＰＵ２１１は、ファイルが切り替わったときにはＴＳ処理部２０４およびデコーダ２０６の処理回路をリセットしない。ＴＳ処理部２０４のクロックカウンタ２６２、ＰＬＬ回路２６３等は、ファイルが切り替わっても継続して動作する。その結果、クロックカウンタ２６２は連続的に変換するタイミング情報を出力し、ソース・デ・パケタイザ２６５はその信号とＡＴＳとに基づいて、ＴＳパケットをデコーダ２０６へ送出する。これにより、クリップＡＶストリームが複数のファイルに跨って格納されていても、そのストリームのＡＴＳに基づいて途切れることなく映像を再生できる。【０１６８】  ＣＰＵ２１１は、ＴＳ処理部２０４等の処理回路をリセットするか否かを判断する基準としてファイルエントリの記述を利用することができる。ファイルエントリに指定されたファイルを再生するときには、ＣＰＵ２１１は処理回路をリセットしない。その理由は、ファイルエントリの存在は、１つのクリップＡＶストリームが複数のファイルに分割されて格納されていることを意味するからである。ただし、ファイルエントリ＃０が付加されているときには新たなストリームの開始を意味するため、処理回路をリセットすればよい。【０１６９】  一方、ＳＴＣ＿ｉｄ＃１がＳＴＣ＿ｉｄ＃２に切り替わっている点（例えば編集点）においては、ＡＴＳは不連続である。このときは映像の連続再生を保証する必要はない。またＳＴＣ＿ｉｄ＃２が割り当てられたストリームには改めてファイルエントリ＃０に格納ファイル名（「０２００２．ｍ２ｔｓ」）が付加される。よって、このストリームから映像を再生する時にはＴＳ処理部２０４およびデコーダ２０６等はリセットされる。【０１７０】  これまでは、ファインエントリはＧＯＰの先頭に配置される各ＩピクチャのＰＴＳに基づいて設定されており、再生開始時刻としてそのようなＩピクチャのＰＴＳが指定されるとして説明した。しかし、一般的には、そのようなＩピクチャ以外のピクチャの再生開始時刻（ＰＴＳ）が指定される。以下、ファインエントリを利用して任意のピクチャから表示できることを説明する。【０１７１】  図３０は、ファインエントリと各ＧＯＰの先頭に配置されるＩピクチャとの対応を示す。以下、ＧＯＰ（Ｎ−１）内の最後のＢピクチャ３０１を再生するための処理を説明する。与えられた再生開始時��（ＰＴＳ）に対応するピクチャはＢピクチャ３０１である。【０１７２】  なお、ＧＯＰ（Ｎ−１）はクリップＡＶストリームファイル０２００１．ｍ２ｔｓと０２００２．ｍ２ｔｓとに跨って格納されている。そしてＢピクチャ３０１のデータはファイル０２００２．ｍ２ｔｓに格納されているとする。【０１７３】  まずＣＰＵ２１１がＰＴＳを取得すると、そのＰＴＳの上位１７ビットを利用して、ＰＴＳコアースエントリ８９−２、および、対応するＳＰＮコアースエントリ８９−３とファインＩＤフィールド８９−１とを特定する。続いてＣＰＵ２１１は、特定されたファインＩＤフィールド８９−１の値を利用して、ＰＴＳ／ＳＰＮコアースエントリに対応するＰＴＳおよびＳＰＮファインエントリ９０−２および９０−３を特定する。ここでは、図３０に示すファインエントリ（Ｎ−１）がＰＴＳファインエントリとして得られたとする。【０１７４】  ＣＰＵ２１１は、得られたＰＴＳファインエントリと、与えられたＰＴＳの下位１７ビットとを比較し、後者の方が大きいと判断する。そしてＣＰＵ２１１は、得られたＰＴＳファインエントリの次のファインエントリ（図３０におけるＰＴＳファインエントリＮ）を、時間・アドレス変換テーブル８７の第３ループ９０から読み出し、そのＰＴＳファインエントリと、与えられたＰＴＳの下位１７ビットとを比較する。その結果、後者の方が小さいと判断する。【０１７５】  この比較結果により、与えられたＰＴＳは、ＧＯＰ（Ｎ−１）の先頭Ｉピクチャよりは大きいがＧＯＰ（Ｎ）の先頭Ｉピクチャよりは小さいことが特定される。よって与えられたＰＴＳに対応するピクチャは、ＧＯＰ（Ｎ−１）に存在することが特定される。【０１７６】  ここで、ＧＯＰ（Ｎ−１）の先頭Ｉピクチャから再生を開始するためには、そのＩピクチャのデータが格納されたファイル０２００１．ｍ２ｔｓを特定する必要がある。特定するための処理の手順は、先に図２７を参照しながら説明したとおりであるため、ここでは省略する。【０１７７】  デコーダ２０６は、ＧＯＰ（Ｎ−１）の先頭Ｉピクチャから順に復号化し、与えられたＰＴＳと一致するＰＴＳのピクチャ（Ｂピクチャ３０１）が現れると、そのＢピクチャ３０１から出力を開始すればよい。上述の処理は、任意のピクチャに関して実行できる。【０１７８】  本実施形態による時間・アドレス変換テーブル８７のように、所定のピクチャの再生時刻と記録アドレスとファイルエントリとを対応付けたテーブル（リスト）を設けることにより、記録媒体、ＡＶストリームファイル、ＳＴＣシーケンスの如何なる相関に対しても、正しく検索をかけることができる。【０１７９】  上述の説明では、図２６に示すファイルエントリ（第１ループ８８）に４種類のフィールド（ｍｅｄｉａ＿ｒｅｆ＿ｉｄ、ＢＤＡＶ＿ｒｅｆ＿ｉｄ、Ｃｌｉｐ＿ＡＶ＿ｓｔｒｅａｍ＿ｆｉｌｅ＿ｎａｍｅおよびｆｉｒｓｔ＿ｆｉｎｅ＿ｅｎｔｒｙ＿ｒｅｆ＿ｉｄ）を設けた例を説明した。しかし、規定するフィールドは変更してもよい。【０１８０】  図３１（ａ）〜（ｄ）は、ファインエントリのデータ構造の他の例を示す。図２６に示すファイルエントリ（第１ループ８８）中の先頭ソースパケットのファインエントリに代えて��種々の情報を記述できる。図３１（ａ）は、最初のコアースエントリおよび最後のコアースエントリの組を規定したフィールド８８ａを示す。図３１（ｂ）は、最初のファインエントリおよび最後のファインエントリの組を規定したフィールド８８ｂを示す。図３１（ｃ）は、最初のコアースエントリおよびコアースエントリの数の組を規定したフィールド８８ｃを示す。図３１（ｄ）は、最初のファインエントリおよびファインエントリの数の組を規定したフィールド８８ｄを示す。【０１８１】  本実施形態においてはファイルエントリを追加したが、その追加に代えて、または追加とともに、ファイルエントリとして規定される情報（上述のｍｅｄｉａ＿ｒｅｆ＿ｉｄ、ＢＤＡＶ＿ｒｅｆ＿ｉｄ、Ｃｌｉｐ＿ＡＶ＿ｓｔｒｅａｍ＿ｆｉｌｅ＿ｎａｍｅ）の一部または全部を、コアースエントリ（図２６に示す第２ループ８９）またはファインエントリ（図２６に示す第３ループ９０）自体に格納してもよい。【０１８２】  また、ＤＶＤビデオレコーディング規格のタイムマップＴＭＡＰに対して、上述のファイルエントリと同等のファイルエントリを追加することもできる。例えば、図３２は、ファイルエントリ３２、タイムエントリ３３およびＶＯＢＵエントリ３４を含む拡張されたタイムマップＴＭＡＰを示す。このような情報を得るためには、図２６（図３１（ａ）〜（ｄ）の変形例を含む）のコアースエントリに関する情報（第２ループ８９）をＴｉｍｅエントリとして置き換え、ファインエントリ（第１ループ８８）に関する情報をＶＯＢＵエントリに置き換えればよい。【０１８３】  タイムマップＴＭＡＰに対してもファイルエントリを追加したが、その追加に代えて、または追加とともに、ファイルエントリとして規定される情報（上述のｍｅｄｉａ＿ｒｅｆ＿ｉｄ、ＢＤＡＶ＿ｒｅｆ＿ｉｄ、Ｃｌｉｐ＿ＡＶ＿ｓｔｒｅａｍ＿ｆｉｌｅ＿ｎａｍｅ）の一部または全部を、Ｔｉｍｅエントリ３３またはＶＯＢＵエントリ３４自体に格納してもよい。また、図２６に示す状態フィールド９１−２と同等の情報を格納するフィールドを設けてもよい。【０１８４】  本実施形態においては、図２４に示されるように、メモリカード１１２に複数のクリップＡＶストリームファイルが記録されるとした。しかし、これら複数のファイルはそれぞれ別個の記録媒体に記録されてもよい。以下、図３３を参照しながら変形例を説明する。【０１８５】  図３３（ａ）は、連続的に動画が撮影された「１ショット」の範囲を示す。図３３（ｂ）は、コンテンツの管理情報とストリームのデータとを含むクリップの概念を示す。１ショット、すなわち１つのコンテンツは、複数のクリップａ〜ｃに分けて各メモリカード１１２ａ〜１１２ｃに格納することができる（１つのクリップで完結してもよい）。１つのクリップは、クリップメタデータ３３１と、タイムマップ３３２と、クリップＡＶストリーム３３３の一部（部分ストリーム）とを含む。クリップＡＶストリーム３３３は、部分ストリーム３３３ａ〜３３３ｃから構成されており、クリップａ〜ｃのそれぞれに含まれる。図３３（ｂ）には３つのクリップａ〜ｃが記載されているが、各クリップの構成は共通しているため、ここではクリップａを例に挙げて説明する���記載の簡略化のため、部分ストリーム３３３ａを部分ストリームａなどと記載する。【０１８６】  クリップａは、クリップメタデータａと、タイムマップａと、部分ストリームａとを含む。クリップメタデータａおよびタイムマップａは管理情報である。一方、部分ストリームａはクリップＡＶストリーム３３３を構成するデータである。このデータは、図２４（ｄ）に示すクリップＡＶストリームファイル８５（例えば０２００１．ｍ２ｔｓ）に対応する。【０１８７】  クリップメタデータａはＸＭＬ形式で記述されており、コンテンツの再生に必要な情報、例えば映像／音声フォーマット等が規定される。クリップメタデータａの詳細は、図３４を参照しながら後述する。【０１８８】  タイムマップａは、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を規定したテーブルである。ここでは、このタイムマップを「クリップタイムライン」（ＣｌｉｐＴｉｍｅＬｉｎｅ）と呼び、クリップタイムラインが格納されたファイルの拡張子に“ＣＴＬ”を付して図示している。タイムマップａは、図２６に示す時間・アドレス変換テーブル８７（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ）または図３２に示すタイムマップＴＭＡＰと同じである。【０１８９】  図３３に示す例では、クリップメタデータおよびタイムマップは１つではなく、対応する部分ストリームファイルごとに存在していることに留意されたい。ただし、各タイムマップａ〜ｃは同一の情報である。例えば図５に示すレコーダ１００に３つのカードスロットが設けられ、そこにメモリカード１１２ａ〜１１２ｃが装填されている状態で、書き込み処理が行われることを想定する。レコーダ１００が部分ストリームファイルａ〜ｃをメモリカード１１２ａ〜１１２ｃに順次書き終えたとき、タイムマップの内容が確定する。その結果、レコーダ１００はさらにそのタイムマップを各メモリカード１１２ａ〜１１２ｃに書き込めばよい。なお、そのタイムマップには全てのストリームファイルの格納先が規定されているため、状態フィールド９１−２にはその状態を示す値「１１」が規定される。【０１９０】  このタイムマップを利用することにより、再生のために各メモリカード１１２ａ〜１１２ｃが機器に装填されているときは、任意の記録媒体の任意のピクチャから再生を開始できる。タイムマップａ〜ｃが図２６に示す時間・アドレス変換テーブル８７であるとすると、機器のＣＰＵは、まず状態フィールド９１−２を参照して、各タイムマップａ〜ｃには全てのストリームファイルの格納先が規定されていると判断できる。さらに、再生を行うべき時刻（ＰＴＳ）の指定を受けると、どのメモリカードのタイムマップを利用しても、そのＣＰＵはそのＰＴＳに基づいて再生すべきピクチャのデータがどのメモリカードに格納されているかを特定し、かつ、そのデータを格納したストリームファイルのファイル名も特定できる。このとき、タイムマップ中の第１ループ８８のｍｅｄｉａ＿ｒｅｆ＿ｉｄフィールドおよびファイル名フィールド８８−１が参照される。【０１９１】  なお、特定されたメモリカードがその機器に装填されていないことがある。このときは、その機器のＣＰＵは、そのメモリカードを特定する情報（メ���リカード名）等をユーザに通知すればよい。さらに、ストリームファイルのファイル名も特定されているため、例えば「ファイル名ｘｘｘｘのファイルが記録されたメモリカードｙｙｙｙを挿入してください」という通知をＴＶの画面に表示してもよい。【０１９２】  本実施形態の例において各メモリカードの容量を４ギガバイトとしたときには、各部分ストリームのファイルサイズをＦＡＴ３２ファイルシステムにおけるファイルサイズの最大値（４ギガバイト）とすると、メモリカード１１２ａ〜ｃの記録可能容量がなくなって管理情報をメモリカード１１２に書き込みできなくなる。よって、このときは各部分ストリームファイルのファイルサイズは４ギガバイトよりも小さくなることに留意されたい。さらに、部分ストリームは整数個のソースパケットから構成されるとし、上記ファイルシステムからの制限である４ギガバイト未満であり、かつ、ソースパケット（１９２バイト）の整数倍としてもよい。【０１９３】  なお、１ショット内では、クリップＡＶストリーム３３３のシステム時刻基準ＳＴＣの識別情報（ＳＴＣ＿ｉｄ）は変化することはなく、到着時刻情報ＡＴＳも図２９（ｄ）に示すように連続している。この関係は、部分ストリームａ〜ｃに分割されても保持されるため、部分ストリームのＳＴＣ＿ｉｄは一致し、連続する２つの部分ストリームの境界の前後では、ＡＴＳも連続的に変化している。部分ストリームａ〜ｃの再生中にファイルが切り替わったときには、ＡＴＳのクロックカウンタ２６２（図６）がリセットされたり、それまでのカウント値とは無関係な値が設定されることはない。クロックカウンタ２６２（図６）は、設定されていた基準時刻に基づくカウントを継続的に行ってカウント値を出力する。【０１９４】  図３３（ｃ）は、３つのメモリカード１１２ａ〜１１２ｃを示す。各クリップａ〜ｃを構成するデータのファイルが各メモリカード１１２ａ〜１１２ｃに書き込まれる。【０１９５】  図３４は、クリップメタデータ３３１に含まれる情報の内容を示す。クリップメタデータ３３１は、構成データ（“Ｓｔｒｕｃｔｕｒａｌ”）および記述データ（“Ｄｅｓｃｒｉｐｔｉｖｅ”）の２種類に分類される。【０１９６】  構成データには、クリップ名、エッセンスリスト、リレーション情報等が記述される。クリップ名は、そのファイルを特定するための情報であり、例えば周知のＵＭＩＤ（Ｕｎｉｑｕｅ  Ｍａｔｅｒｉａｌ  ＩＤｅｎｔｉｆｉｅｒ）が記述される。ＵＭＩＤは、例えば、コンテンツが生成された時刻とそれを生成した機器のＭＡＣ（Ｍｅｄｉａ  ＡｃｃｅｓｓＣｏｎｔｒｏｌ）アドレスを組み合わせて生成される。さらにＵＭＩＤは、コンテンツが新たに生成されたか否かをも考慮して生成される。すなわち、一旦ＵＭＩＤが付加され、その後に編集・加工等されたコンテンツには、元のコンテンツのＵＭＩＤとは異なる値が付加される。よってＵＭＩＤを利用すると世界中に存在するコンテンツに対して異なる値が定義されるため、コンテンツを一意に特定できる。【０１９７】  エッセンスリストには、映像および音声の復号化に必要な情報（ビデオ情報およびオーディオ情報）が記述されている。例えばビデオ情報には、ビデオデータのフォーマット���圧縮符号化方式、フレームレートなどが記述される。オーディオ情報には、オーディオデータのフォーマット、サンプリングレート等が記述される。本実施形態では、圧縮符号化方式はＭＰＥＧ−２方式である。【０１９８】  リレーション情報は、図３３（ｂ）に示すような複数のクリップａ〜ｃが存在するときのクリップの間の関係を規定する。具体的には、リレーション情報は、複数クリップの各々に対応するクリップＡＶストリーム（部分ストリーム）の再生の先後関係または再生順序を規定している。これらは、接続情報３４０として管理される。接続情報３４０は、そのショットの先頭のクリップを特定する情報、そのクリップの直前のクリップ名および直後のクリップ名を特定する情報がそれぞれ記述される。クリップ名を特定する情報は、例えば、ＵＭＩＤおよびそのメモリカード１１２固有のシリアル番号によって規定される。【０１９９】  記述データには、アクセス情報、デバイス、撮影情報等が含まれている。アクセス情報には、そのクリップの最終更新者、日時等が記述されている。デバイス情報には、製造者名、記録した装置のシリアル番号、モデル番号等が記述されている。撮影情報は、撮影者名、撮影開始日時、終了日時、位置などを含む。【０２００】  なお、図３３に示す例では、各タイムマップａ〜ｃは同一の情報であるとしたが、同一の情報でなくてもよい。以下に、想定される（１）〜（４）のタイムマップの態様を説明する。【０２０１】  （１）部分ストリームごとに１つのタイムマップを設ける（タイムマップｘは部分ストリームｘのみの再生に用いられる）。このタイムマップによれば、指定された再生時刻（ＰＴＳ）が最初にアクセスしたタイムマップに記述されていなければ、上述のリレーション情報を用いて次のまたは前のクリップ等に移り、そのクリップにおいて再びタイムマップを参照する必要がある。【０２０２】  （２）それまでに記録された全ての部分ストリームに対応するタイムマップを設ける（タイムマップｘは最初の部分ストリーム０から部分ストリームｘまでの部分ストリームの再生に用いられる）。このタイムマップによれば、指定された再生時刻（ＰＴＳ）のピクチャデータがそれまでに生成された部分ストリームに含まれているときには、そのデータが格納されたメモリカードやファイル名を、１つのタイムマップから特定できる。ただし、そのデータがそれまでの部分ストリームに含まれていないときには、リレーション情報を用いて次のクリップに移り、そのクリップにおいて再びタイムマップを参照する必要がある。【０２０３】  （３）上述の（２）のタイムマップに、さらに次に記録される部分ストリームやタイムマップ等を特定する情報（例えば次の部分ストリームやタイムマップのファイル名）を追加的に規定したタイムマップを設ける（タイムマップｘは最初の部分ストリーム０から部分ストリームｘまでの部分ストリームの再生に用いられる。さらにタイムマップｘによれば、次の部分ストリーム（ｘ＋１）のファイルにアクセスできる）。このタイムマップによれば、上述の（２）の利点の他に、リレーション情報を介することなく次の部分ストリームファイルやタイムマップを直接特定できるため、アクセスを高速化できる���【０２０４】  （４）全ての部分ストリームに対応するタイムマップを設ける（タイムマップｘは全ての部分ストリームの再生に用いられる）。この形態は、図３３を参照しながら説明した上述の態様と同じである。各メモリカードに格納されたタイムマップは互いに同一である。【０２０５】  上述の状態フィールド９１−２を利用すれば、メモリカードに記録されたタイムマップが上述の（１）〜（４）のいずれの態様であるかを示すことができる。例えば状態フィールド９１−２には、（１）のタイムマップに対しては「００」、（２）のタイムマップに対しては「０１」、（３）のタイムマップに対しては「１０」、（４）のタイムマップに対しては「１１」の各値を記述すればよい。この状態フィールド９１−２の値に応じて、機器のＣＰＵは、与えられた再生時刻（ＰＴＳ）からどのように各ファイルを参照すればよいかの処理を切り替えることができる。【０２０６】  以上説明した本発明に係るデータ処理は、コンピュータが所定のプログラムを実行することによって実現できることは言うまでもない。そのプログラムはフレキシブルディスク、ハードディスク、光ディスク、その他のコンピュータに読み取り可能な情報記録媒体に格納されることができる。【０２０７】  本発明は、特定の実施形態について説明されてきたが、当業者にとっては他の多くの変形例、修正、他の利用が明らかである。それゆえ、本発明は、ここでの特定の開示に限定されず、添付の請求の範囲によってのみ限定され得る。
【産業上の利用可能性】
【０２０８】  本発明のデータ処理装置は、記録媒体とファイル、ファイルの中のストリームの包含関係に関わらず統一的に記述できるテーブル（アクセスマップ）を生成する。このアクセスマップには、そのストリームのファイルを特定する情報、そのファイルが記録される記録媒体の情報および／またはフォルダの情報等が格納される。この結果、データ処理装置は、アクセスマップによれば、ストリームの全部または一部の格納状況を、ストリームを解析して把握する必要はない。そしてアクセスマップを利用すれば、ストリームの所望の再生位置にアクセスすることができる。
【図１】
2006030767.tif 000002
【図２】
2006030767.tif 000003
【図３】
2006030767.tif 000004
【図４】
2006030767.tif 000005
【図５】
2006030767.tif 000006
【図６】
2006030767.tif 000007
【図７】
2006030767.tif 000008
【図８】
2006030767.tif 000009
【図９】
2006030767.tif 000010
【図１０】
2006030767.tif 000011
【図１１】
2006030767.tif 000012
【図１２】
2006030767.tif 000013
【図１３】
2006030767.tif 000014
【図１４】
2006030767.tif 000015
【図１５】
2006030767.tif 000016
【図１６】
2006030767.tif 000017
【図１７】
2006030767.tif 000018
【図１８】
2006030767.tif 000019
【図１９】
2006030767.tif 000020
【図２０】
2006030767.tif 000021
【図２１】
2006030767.tif 000022
【図２２】
2006030767.tif 000023
【図２３】
2006030767.tif 000024
【図２４】
2006030767.tif 000025
【図２５】
2006030767.tif 000026
【図２６】
2006030767.tif 000027
【図２７】
2006030767.tif 000028
【図２８】
2006030767.tif 000029
【図２９】
2006030767.tif 000030
【図３０】
2006030767.tif 000031
【図３１】
2006030767.tif 000032
【図３２】
2006030767.tif 000033
【図３３】
2006030767.tif 000034
【図３４】
2006030767.tif 000035
【手続補正書】
【提出日】平成18年12月22日(2006.12.22)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
映像のデータストリーム、および、前記データストリームに基づいて前記映像を再生するための管理情報のそれぞれを１以上の記録媒体に書き込むデータ処理装置であって、
前記データストリームには、前記映像を構成する各ピクチャのピクチャデータ、および、前記各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されており、
１以上のピクチャに関し、前記時刻情報と前記データストリーム内の前記ピクチャデータの格納位置と、前記ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルを、前記管理情報の一部として生成するプロセッサと、
前記データストリームおよび前記管理情報を、１以上のストリームファイル、および、１以上の管理情報ファイルとして前記記録媒体に書き込むコントローラと
を備えたデータ処理装置。
【請求項２】
前記コントローラは、複数のストリームファイルおよび１つの管理情報ファイルを生成する、請求項１に記載のデータ処理装置。
【請求項３】
前記データストリームは、単独で復号化が可能な基準ピクチャの基準ピクチャデータから開始される１以上の再生単位を含み、
前記プロセッサは、前記再生単位の先頭の基準ピクチャデータに対し、前記テーブルを生成する、請求項２に記載のデータ処理装置。
【請求項４】
前記プロセッサは、前記複数のストリームファイルの各々において最初に配置された前記先頭の基準ピクチャデータに対し、前記テーブルを生成する、請求項３に記載のデータ処理装置。
【請求項５】
前記データストリームは、連続して録画された前記映像に関し、共通の基準時刻に基づいて生成された前記時刻情報を含み、
前記コントローラは、前記共通の基準時刻に基づいて生成された前記データストリームを分割して、前記複数のストリームファイルを生成する、請求項２に記載のデータ処理装置。
【請求項６】
前記データストリームは、一定のデータ長を有する複数のパケットから構成されており、
前記プロセッサは、前記データストリーム内の前記複数のパケットの配置に基づいて、前記ピクチャデータの格納位置を特定する、請求項１に記載のデータ処理装置。
【請求項７】
前記コントローラは、ＦＡＴ３２ファイルシステムが採用されている前記記録媒体に対して、前記１以上のストリームファイル、および、前記１以上の管理情報ファイルを書き込む、請求項１に記載のデータ処理装置。
【請求項８】
アナログ信号に基づいて前記１以上の再生単位を生成するエンコーダをさらに備えた、請求項３に記載のデータ処理装置。
【請求項９】
アナログ信号に基づいて映像を連続して録画するときにおいて、前記共通の基準時刻に基づいて前記データストリームを生成するエンコーダをさらに備えた、請求項５に記載のデータ処理装置。
【請求項１０】
映像のデータストリームを格納した１以上のストリームファイル、および、前記データストリームに基づいて前記映像を再生するための管理情報を格納した１以上の管理情報ファイルが記録されている記録媒体であって、
前記データストリームには、前記映像を構成する各ピクチャのピクチャデータ、および、前記各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されており、
前記管理情報には、１以上のピクチャに関し、前記時刻情報と、前記データストリーム内の前記ピクチャデータの格納位置と、前記ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルが格納されている、記録媒体。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、動画データを記録媒体に記録し、記録された動画データを管理する技術に関する。
【背景技術】
【０００２】
近年、ＤＶＤ等の光ディスクにデジタルデータを書き込み、蓄積できる光ディスクレコーダの普及が進んでいる。書き込まれる対象は、例えば放送された番組のデータストリームや、カムコーダ等によって撮影された映像および音声のデータストリームである。書き込まれたデータは、ランダムアクセス可能な状態でＤＶＤに保持される。
【０００３】
ＤＶＤでは、ＵＤＦ（Ｕｎｉｖｅｒｓａｌ  Ｄｉｓｃ  Ｆｏｒｍａｔ）と呼ばれるファイルシステムが採用されている。ＵＤＦファイルシステムは映像・音声データの記録・再生・編集に適している。例えば、ＤＶＤに主に書き込まれる映像・音声データは大きいため、ＵＤＦファイルシステムにおける最大ファイルサイズは十分大きく設定されている。また、ＵＤＦファイルシステムではセクタ単位でのデータの編集が容易である。特許文献１は、このようなＵＤＦファイルシステムを開示している。
【０００４】
ＤＶＤに代表されるランダムアクセス可能な記録媒体に映像・音声データを記録するために、従来はデータの性質に応じた適切なファイルシステムが開発され、利便性や機器実装容易性を確保してきた。
【特許文献１】特開２０００−０１３７２８号公報
【発明の開示】
【発明が解決しようとする課題】
【０００５】
近年は、ＰＣを利用した映像・音声データの編集（ノンリニア編集（ＮＬＥ））が普及しつつあるため、ＰＣのファイルシステムで編集されることを想定して映像・音声データを記録し、管理することが必要とされている。
【０００６】
ＰＣでは一般的にＦＡＴ３２ファイルシステムが採用されている。ＦＡＴ３２ファイルシステムでは、１データファイルのファイルサイズは４ＧＢ未満に制限される。よって、ＦＡＴ３２ファイルシステムでの編集を考慮すると、１回の録画で得られる映像・音声データを複数のファイルに分割して格納する必要が生じる。そこで、それらの映像・音声データをどのように管理するかが問題となる。
【０００７】
特に、近年は小径のハードディスクや半導体メモリのような記録媒体を複数装填できる機器（例えばカムコーダ）が開発されているため、分割された映像・音声データが複数の記録媒体に跨って書き込まれることもある。よって、映像・音声データが分割されて１つの記録媒体に書き込まれている状況のみならず、異なる記録媒体に書き込まれている状況においても、適切に映像・音声データを管理する必要がある。
【０００８】
本発明の目的は、１回の録画で得られる映像・音声データを複数のファイルに分割したときのデータの管理方法を提供することである。
【課題を解決するための手段】
【０００９】
本発明によるデータ処理装置は、映像のデータストリーム、および、前記データストリームに基づいて前記映像を再生するための管理情報のそれぞれを１以上の記録媒体に書き込む。前記データストリームには、前記映像を構成する各ピクチャのピクチャデータ、および、前記各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されている。前記データ処理装置は、１以上のピクチャに関し、前記時刻情報と前記データストリーム内の前記ピクチャデータの格納位置と、前記ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルを前記管理情報の一部として生成するプロセッサと、前記データストリームおよび前記管理情報を、１以上のストリームファイル、および、１以上の管理情報ファイルとして前記記録媒体に書き込むコントローラとを備えている。
【００１０】
前記コントローラは、複数のストリームファイルおよび１つの管理情報ファイルを生成してもよい。
【００１１】
前記データストリームは、単独で復号化が可能な基準ピクチャの基準ピクチャデータから開始される１以上の再生単位を含み、前記プロセッサは、前記再生単位の先頭の基準ピクチャデータに対し、前記テーブルを生成してもよい。
【００１２】
前記プロセッサは、前記複数のストリームファイルの各々において最初に配置された前記先頭の基準ピクチャデータに対し、前記テーブルを生成してもよい。
【００１３】
前記データストリームは、連続して録画された前記映像に関し、共通の基準時刻に基づいて生成された前記時刻情報を含み、前記コントローラは、前記共通の基準時刻に基づいて生成された前記データストリームを分割して、前記複数のストリームファイルを生成してもよい。
【００１４】
前記データストリームは、一定のデータ長を有する複数のパケットから構成されており、前記プロセッサは、前記データストリーム内の前記複数のパケットの配置に基づいて、前記ピクチャデータの格納位置を特定してもよい。
【００１５】
前記コントローラは、ＦＡＴ３２ファイルシステムが採用されている前記記録媒体に対して、前記１以上のストリームファイル、および、前記１以上の管理情報ファイルを書き込んでもよい。
【００１６】
前記データ処理装置は、アナログ信号に基づいて前記１以上の再生単位を生成するエンコーダをさらに備えていてもよい。
【００１７】
前記データ処理装置は、アナログ信号に基づいて映像を連続して録画するときにおいて、前記共通の基準時刻に基づいて前記データストリームを生成するエンコーダをさらに備えていてもよい。
【００１８】
本発明による記録媒体には、映像のデータストリームを格納した１以上のストリームファイル、および、前記データストリームに基づいて前記映像を再生するための管理情報を格納した１以上の管理情報ファイルが記録されている。前記データストリームには、前記映像を構成する各ピクチャのピクチャデータ、および、前記各ピクチャの表示時刻を特定する時刻情報が対応付けられて格納されている。前記管理情報には、１以上のピクチャに関し、前記時刻情報と、前記データストリーム内の前記ピクチャデータの格納位置と、前記ピクチャデータが格納されるストリームファイルを特定するファイル情報とを対応付けたテーブルが格納されている。
【発明の効果】
【００１９】
本発明によれば、データ処理装置は、データストリームが格納されたファイルを特定するファイル情報等を格納したテーブルを生成する。このテーブルを参照すれば、データストリームを解析することなく、データストリームの全部または一部がどのファイルに格納されているかを特定できる。よって、データストリームの所望の再生位置に高速にアクセスすることができる。
【発明を実施するための最良の形態】
【００２０】
以下、添付の図面を参照して、本発明によるデータ処理装置の実施形態を説明する。本実施の形態においては、データ処理装置は光ディスクや半導体メモリ、小型ＨＤＤなどのドライブ／スロットを搭載したＨＤＤ内蔵型の光ディスクレコーダであるとして説明するが、カムコーダやムービー撮影機能を有する携帯電話等でもよく、特にこれに限定されない。
【００２１】
図１は、光ディスクレコーダ１００と他の機器とによって形成されるシステムの構成を示す。光ディスクレコーダ１００（以下「レコーダ１００」と記述する）は、放送番組の映像および音声に関する動画のデータストリームを１種類以上の記録媒体に記録する録画機能を有する。記録媒体として、例えば半導体メモリカード１１２、小型のＨＤＤを利用したメモリカード１１３、Ｂｌｕ−ｒａｙディスク（ＢＤ）１１４である。なお、これらはリムーバブルな記録媒体の例であるが、レコーダ１００がＨＤＤを内蔵しているときには、そのＨＤＤに動画のデータストリームを記録し、蓄積することもできる。またレコーダ１００は、それらの記録媒体に記録されたデータストリームを読み出して動画を再生する再生機能も有する。
【００２２】
図１には、レコーダ１００の録画機能および再生機能に関連して連携することが可能な他の機器（ＰＣ１０８、カムコーダ１１０）を示している。ただし、これらの機器もまた固有の録画機能および再生機能を有している。各機能はレコーダ１００と同等である。以下の説明では、主としてレコーダ１００を例に挙げて説明する。
【００２３】
レコーダ１００の録画機能および再生機能に関する処理は、リモコン１１６や、レコーダ１００本体のボタン（図示せず）等を利用してユーザが与えた指示に基づいて行われる。
【００２４】
まず、レコーダ１００の録画機能に関連する処理を説明する。レコーダ１００は、デジタル放送番組に関するデジタル信号を受信するアンテナ１０２ａ、および、アナログ放送番組に関するアナログ信号を受信するアンテナ１０２ｂと接続され、デジタル信号およびアナログ信号を受信する。レコーダ１００は、例えば同軸ケーブル１０４を介してデジタル信号およびアナログ信号を受け取る。
【００２５】
デジタル信号は、ＭＰＥＧ−２トランスポートストリーム（以下「トランスポートストリーム」または「ＴＳ」と記述する）として伝送されている。ＴＳを受信した場合には、レコーダ１００は、そのＴＳに所定の処理を行い、後述するＴＳのパケット構造を保持しながらＢＤ１１４に記録する。アナログ信号を受信した場合には、レコーダ１００は、そのアナログ信号から得られた動画のデータを圧縮符号化してＴＳを生成し、そのＴＳをＢＤ１１４に記録する。さらにレコーダ１００は、ＳＤメモリカードのような半導体を利用したメモリカード１１２や小型のＨＤＤを利用したメモリカード１１３にアナログ／デジタル放送番組を録画することもできる。また、メモリカード１１２、１１３に記録された静止画データなどをＢＤ１１４にコピーすることもできる。なお、カムコーダ１１０を利用して録画が行われるときには、カムコーダ１１０は撮影対象の映像および音声のアナログ信号に基づいてＴＳを生成する。
【００２６】
次に、レコーダ１００が有する再生機能に関連する処理を説明する。レコーダ１００はＢＤ１１４に記録された映像および音声を復号化し、ＴＶ１０６、スピーカ（図示せず）等を介して再生する。この映像および音声は放送番組に限られることはなく、例えばカムコーダ１１０によって記録された映像および音声であってもよい。なお、映像および／または音声を記録した機器と、それらを再生する機器とが異なっていてもよい。例えば、映像および音声が記録されたＢＤ１１４がレコーダ１００から取り出されてＰＣ１０８やカムコーダ１１０等の他の機器に装填されてもよい。そしてそのＢＤ１１４が装填された機器が映像および音声を再生してもよい。
【００２７】
ここで、図２〜図４を参照しながら、デジタル放送信号として伝送されるトランスポートストリームのデータ構造を説明する。
【００２８】
図２は、トランスポートストリーム（ＴＳ）２０のデータ構造を示す。ＴＳパケットは、例えば、圧縮されたビデオデータが格納されたビデオＴＳパケット（Ｖ＿ＴＳＰ）３０、圧縮されたオーディオデータが格納されたオーディオＴＳパケット（Ａ＿ＴＳＰ）３１の他、番組表（プログラム・アソシエーション・テーブル；ＰＡＴ）が格納されたパケット（ＰＡＴ＿ＴＳＰ）、番組対応表（プログラム・マップ・テーブル；ＰＭＴ）が格納されたパケット（ＰＭＴ＿ＴＳＰ）およびプログラム・クロック・リファレンス（ＰＣＲ）が格納されたパケット（ＰＣＲ＿ＴＳＰ）等を含む。各ＴＳパケットのデータ量は１８８バイトである。また、ＰＡＴ＿ＴＳＰ、ＰＭＴ＿ＴＳＰ等のＴＳの番組構成を記述するＴＳパケットを一般に、ＰＳＩ／ＳＩパケットと呼ぶ。
【００２９】
以下、本発明の処理に関連するビデオＴＳパケットおよびオーディオＴＳパケットを説明する。図３（ａ）はビデオＴＳパケット３０のデータ構造を示す。ビデオＴＳパケット３０は、４バイトのトランスポートパケットヘッダ３０ａ、および、１８４バイトのトランスポートパケットペイロード３０ｂを有する。ペイロード３０ｂにはビデオデータ３０ｂが格納されている。一方、図３（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す。オーディオＴＳパケット３１も同様に、４バイトのトランスポートパケットヘッダ３１ａ、および、１８４バイトのトランスポートパケットペイロード３１ｂを有する。オーディオデータ３１ｂはトランスポートパケットペイロード３１ｂに格納されている。
【００３０】
上述の例から理解されるように、一般にＴＳパケットは４バイトのトランスポートパケットヘッダと、１８４バイトのエレメンタリデータとから構成されている。パケットヘッダには、そのパケットの種類を特定するパケット識別子（Ｐａｃｋｅｔ  ＩＤｅｎｔｉｆｉｅｒ；ＰＩＤ）が記述されている。例えば、ビデオＴＳパケットのＰＩＤは“０ｘ００２０”であり、オーディオＴＳパケットのＰＩＤは“０ｘ００２１”である。エレメンタリデータは、ビデオデータ、オーディオデータ等のコンテンツデータや、再生を制御するための制御データ等である。どのようなデータが格納されているかは、パケットの種類に応じて異なる。
【００３１】
以下、ビデオデータを例に挙げて、映像を構成するピクチャとの関係を説明する。図４（ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す。図４（ａ）に示すように、ＴＳ４０は、ビデオＴＳパケット４０ａ〜４０ｄを含む。なお、ＴＳ４０には、他のパケットも含まれ得るが、ここではビデオＴＳパケットのみを示している。ビデオＴＳパケットは、ヘッダ４０ａ−１に格納されたＰＩＤによって容易に特定される。
【００３２】
ビデオデータ４０ａ−２等の各ビデオＴＳパケットのビデオデータから、ＰＥＳ（Ｐａｃｋｅｔｉｚｅｄ  Ｅｌｅｍｅｎｔａｒｙ  Ｓｔｒｅａｍ）パケットが構成される。図４（ｂ）は、パケット化エレメンタリストリーム（ＰＥＳ）４１のデータ構造を示す。ＰＥＳ４１は、複数のＰＥＳパケット４１ａ、４１ｂ等から構成される。ＰＥＳパケット４１ａは、ＰＥＳヘッダ４１ａ−１およびＰＥＳペイロード４１ａ−２から構成されており、これらのデータがビデオＴＳパケットのビデオデータとして格納されている。
【００３３】
ＰＥＳペイロード４１ａ−２は、それぞれが１つのピクチャのデータを含んでいる。ＰＥＳヘッダ４１ａ−１には、各ピクチャの再生表示時刻を特定するプレゼンテーションタイムスタンプ（ＰＴＳ）が格納されている。
【００３４】
ＰＥＳペイロード４１ａ−２から、エレメンタリストリームが構成される。図４（ｃ）は、エレメンタリストリーム（ＥＳ）４２のデータ構造を示す。ＥＳ４２は、ピクチャヘッダ、および、ピクチャデータの組を複数有している。なお、「ピクチャ」とは一般にフレームおよびフィールドのいずれも含む概念として用いられる。
【００３５】
図４（ｃ）に示すピクチャヘッダ４２ａには、その後に配置されたピクチャデータ４２ｂのピクチャ種別を特定するピクチャコーディングタイプが記述され、ピクチャヘッダ４２ｃにはピクチャデータ４２ｄのピクチャ種別を特定するピクチャコーディングタイプが記述されている。種別とは、Ｉピクチャ（Ｉｎｔｒａ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）、Ｐピクチャ（Ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）またはＢピクチャ（Ｂｉｄｉｒｅｃｔｉｏｎａｌｌｙ−ｐｒｅｄｉｃｔｉｖｅ−ｃｏｄｅｄ  ｐｉｃｔｕｒｅ）を表す。種別がＩピクチャであれば、そのピクチャコーディングタイプは、ＭＰＥＧ−２ビデオならば“００１ｂ”である。
【００３６】
ピクチャデータ４２ｂ、４２ｄ等は、そのデータのみによって、または、そのデータとその前および／または後に復号化されるデータとによって構築可能な１枚分のフレームのデータである。例えば図４（ｄ）は、ピクチャデータ４２ｂから構築されるピクチャ４３ａおよびピクチャデータ４２ｄから構築されるピクチャ４３ｂを示す。
【００３７】
ＴＳに基づいて映像を再生する際、レコーダ１００のＭＰＥＧ２デコーダ２０６（後述）はビデオＴＳパケットを取得して上述の処理にしたがってピクチャデータを取得し、復号化することによって映像を構成するピクチャを取得する。これにより映像をＴＶ１０６上に再生することができる。逆に、映像を記録する際には、レコーダ１００のＭＰＥＧ２エンコーダ２０３（後述）は、図４（ｄ）、（ｃ）、（ｂ）および（ａ）の順に処理を行って、ＴＳ４０を構築する。
【００３８】
次に、図５を参照しながら、機器のハードウェア構成を説明する。以下ではレコーダ１００を例に挙げて説明するが、その説明は図１に示すＰＣ１０８、カムコーダ１１０にも適用できる。なお、カムコーダ１１０には後述するデジタルチューナ２０１ａを含んでいなくてもよい。
【００３９】
以下、本実施形態によるレコーダ１００の構成を説明する。図５は、レコーダ１００の機能ブロックの構成を示す。レコーダ１００は、記録媒体としてＢＤ２０５ａのみならず、ハードディスクドライブ（ＨＤＤ）２０５ｂをも有している。すなわちレコーダ１００は、ＨＤＤ２０５ｂを内蔵したＢＤレコーダである。
【００４０】
レコーダ１００は、デジタルチューナ２０１ａおよびアナログチューナ２０１ｂと、ＡＤコンバータ２０２と、ＭＰＥＧ−２エンコーダ２０３と、ＴＳ処理部２０４と、ＭＰＥＧ−２デコーダ２０６と、グラフィック制御部２０７と、メモリ２０８と、ＤＡコンバータ２０９と、ＣＰＵバス２１３と、ネットワーク制御部２１４と、指示受信部２１５と、インターフェース（Ｉ／Ｆ）部２１６と、メモリカード制御部２１７と、システム制御部２５０とを含む。なお、図５には、光ディスク２０５ａがレコーダ１００内に記載されているが、光ディスク２０５ａは光ディスクレコーダ１００から取り外し可能であり、レコーダ１００自体の構成要素ではない。
【００４１】
以下、各構成要素の機能を説明する。デジタルチューナ２０１ａは、アンテナ１０２ａ（図１）から１以上の番組が含まれるデジタル信号を受け取る。デジタル信号として伝送されるトランスポートストリームには複数の番組のパケットが混在している。複数の番組のパケットを含むトランスポートストリームは“フルＴＳ”と呼ばれる。デジタルチューナ２０１ａは、選局を行ってフルＴＳから必要な番組のパケットのみを取り出し、“パーシャルＴＳ”として出力する。
【００４２】
フルＴＳから所望のチャンネルのパケットを取り出す手順は以下のとおりである。いま、希望の番組の番組番号（チャンネル番号）をＸとする。まず、フルＴＳから番組表パケット（図２のＰＡＴ＿ＴＳＰ）が検索される。番組表パケットのパケットＩＤ（ＰＩＤ）には、必ず０が与えられているので、その値を有するパケットを検索すればよい。番組表パケット内の番組表には、各番組番号と、その番組番号に対応する各番組の番組対応表パケット（図２のＰＭＴ＿ＴＳＰ）のＰＩＤが格納されている。これにより、番組番号Ｘに対応する番組対応表ＰＭＴのパケットＩＤ（ＰＩＤ）を特定できる。番組対応表ＰＭＴのＰＩＤをＸＸとする。
【００４３】
次に、ＰＩＤ＝ＸＸが付された番組対応表パケット（図２のＰＭＴ＿ＴＳＰ）を抽出すると、番組番号Ｘに対応する番組対応表ＰＭＴが得られる。番組対応表ＰＭＴには、番組ごとに、視聴の対象として各番組を構成する映像・音声情報等が格納されたＴＳパケットのＰＩＤが格納されている。例えば、番組番号Ｘの映像情報のＰＩＤはＸＶであり、音声情報のＰＩＤはＸＡである。このようにして得られた映像情報を格納したパケットのＰＩＤ（＝ＸＶ）と、音声情報を格納したパケットのＰＩＤ（＝ＸＡ）とを利用して、フルＴＳから特定の番組に関する映像・音声のパケットを抽出できる。
【００４４】
なお、フルＴＳからパーシャルＴＳを生成する際には、必要な映像・音声情報を格納したパケットを取り出すだけでなく、ＰＳＩ（Ｐｒｏｇｒａｍ  Ｓｐｅｃｉｆｉｃ  Ｉｎｆｏｒｍａｔｉｏｎ）パケットおよびＳＩ（Ｓｅｒｖｉｃｅ  Ｉｎｆｏｒｍａｔｉｏｎ）パケットも抽出および変更する必要がある。ＰＳＩパケットとは、図２に示す番組表パケット（ＰＡＴ＿ＴＳＰ）および番組対応表パケット（ＰＭＴ＿ＴＳＰ）等を総称するパケットである。ＰＳＩパケットを修正する理由は、フルＴＳとパーシャルＴＳとでは含まれる番組数等が異なるため、番組表および番組対応表をパーシャルＴＳに適合させる必要が生じるからである。一方、ＳＩパケットとは、フルＴＳに含まれる番組の内容、スケジュール／タイミング等を記述するデータ、独自に定義された拡張情報（これらは「番組配列情報」とも呼ばれる）等を含むパケットである。フルＴＳではＳＩパケットに含まれるデータは２０〜３０種類にも上る。これらのデータのうち、パーシャルＴＳの再生等に関して重要なデータのみが抽出されて１つのＳＩＴパケットが生成され、パーシャルＴＳ内に多重化される。またパーシャルＴＳでは、ＳＩＴパケットにはそのストリームがパーシャルＴＳであることを示す情報（ｐａｒｔｉａｌ  ｔｒａｎｓｐｏｒｔ  ｓｔｒｅａｍ  ｄｅｓｃｒｉｐｔｏｒ）が格納されている。パーシャルＴＳ内にＳＩＴパケットを多重化することは慣用されている。これは、欧州／日本のデジタル放送規定（ＤＶＢ／ＡＲＩＢ）との整合性のためである。
【００４５】
アナログチューナ２０１ｂは、アンテナ１０２ｂ（図１）からアナログ信号を受け取り、周波数に基づいて選局を行って必要な番組の信号を取り出す。そして番組の映像および音声信号をＡＤコンバータ２０２に出力する。なお、図１ではレコーダ１００は同軸ケーブル１０４を介してデジタル信号およびアナログ信号を取得しているため、図５に入力される信号系統は厳密には１本である。しかし、デジタル信号およびアナログ信号は周波数によって容易に分離できるため、図５ではデジタル信号およびアナログ信号が別系統で入力されているように記載している。
【００４６】
ＡＤコンバータ２０２は入力された信号をデジタル変換してＭＰＥＧ−２エンコーダ２０３に供給する。ＭＰＥＧ−２エンコーダ２０３（以下「エンコーダ２０３」と記述する）は、録画の開始指示を受け取ると、供給されたアナログ放送のデジタルデータをＭＰＥＧ−２形式に圧縮符号化してトランスポートストリームを生成し、ＴＳ処理部２０４に入力する。この処理は、図４（ｄ）に示す各ピクチャから、図４（ａ）に示すＴＳ４０を生成する処理である。具体的には、エンコーダ２０３は、アナログ放送信号から得られたピクチャ４３ａ、４３ｂ等のデジタルベースバンド信号を取得して符号化し、ピクチャデータ４２ｂを生成する。そして図４（ｃ）に示すＥＳ４２を生成する。
【００４７】
また、エンコーダ２０３はピクチャ（フレームまたはフィールド）の再生出力時刻を特定するプレゼンテーションタイムスタンプ（ＰＴＳ）等も生成し、そのＰＴＳ等をＰＥＳヘッダ４１ａに格納して図４（ｂ）に示すＰＥＳ４１を生成する。その後、エンコーダ２０３は図４（ａ）に示すＴＳ４０を構築する。上述の処理は、エンコーダ２０３が録画の終了指示を受け取るまで継続される。なお、エンコーダ２０３は圧縮符号化を行うために、参照ピクチャ等を一時的に保持するバッファ（図示せず）等を有している。
【００４８】
ＴＳ処理部２０４は、動画の記録時にはパーシャルＴＳを受け取り、クリップＡＶストリーム（ＣｌｉｐＡＶストリーム）を生成し、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録する。クリップＡＶストリームとは、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録するための形式を有するデータストリームである。クリップＡＶストリームは複数の「ソースパケット」から構成されており、「ソースパケット」はパーシャルＴＳを構成する各ＴＳパケットに所定のヘッダを付加して生成される。なお、クリップＡＶストリームを生成する際の処理の詳細は、図７（ａ）〜（ｅ）に関連して後述する。
【００４９】
ＴＳ処理部２０４は、動画の再生時には、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂからクリップＡＶストリームを読み出し、そのクリップＡＶストリームに基づいてパーシャルＴＳを生成してＭＰＥＧ−２デコーダ２０６に出力する。
【００５０】
また、ＴＳ処理部２０４は、後述するメモリカード制御部２１７からメモリカード１１２、または１１３に格納された静止画データを受け取り、その静止画を加工することなくそのままＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録する。また、ＢＤ２０５ａおよび／またはＨＤＤ２０５ｂに記録された静止画データを読み出してデコーダ２０６に出力することもできる。ＴＳ処理部２０４のさらに具体的な構成および動作は、後に図６および図７を参照しながら詳述する。なお、本明細書では、ＴＳ処理部２０４がＢＤ２０５ａおよび／またはＨＤＤ２０５ｂにデータを記録し、またはそれらからデータを読み出すとして説明しているが、これは説明の便宜のためである。ＢＤ２０５ａやＨＤＤ２０５ｂに対するストリームの書き込みや読み出しは、実際には、ディスクの回転、ヘッドの移動とともに各々のドライブ装置に設けられたコントローラ（図示せず）が行っている。
【００５１】
ＭＰＥＧ−２デコーダ２０６（以下「デコーダ２０６」と記述する）は、供給されたパーシャルＴＳを解析してＭＰＥＧ−２圧縮符号化データを取得する。そして、その圧縮符号化データを伸長して非圧縮データに変換し、グラフィック制御部２０７に供給する。また、デコーダ２０６は、ＭＰＥＧ−２規格の圧縮符号化データのみならず、例えばＪＰＥＧ規格に従った静止画データも非圧縮データに変換することができる。グラフィック制御部２０７には内部演算用のメモリ２０８が接続されており、オン・スクリーン・ディスプレイ（Ｏｎ  Ｓｃｒｅｅｎ  Ｄｉｓｐｌａｙ；ＯＳＤ）機能を実現できる。例えば、グラフィック制御部２０７は種々のメニュー画像と映像とを合成してＤＡコンバータ２０９に出力することができる。ＤＡコンバータ２０９は、入力されたＯＳＤ合成画像および音声データをアナログ変換して出力する。出力先は、例えばＴＶ１０６である。
【００５２】
ＣＰＵバス２１３はレコーダ１００内の信号を伝送する経路であり、図示されるように各機能ブロックと接続されている。また、ＣＰＵバス２１３には、後述するシステム制御部２５０の各構成要素も接続されている。
【００５３】
ネットワーク制御部２１４は、レコーダ１００をインターネット等のネットワーク１０１に接続するためのインターフェイスであり、例えば、イーサネット（登録商標）規格に準拠した端子およびコントローラである。ネットワーク制御部２１４は、ネットワーク１０１を介してデータを授受する。このデータは、例えば放送番組に関する番組表のデータや、レコーダ１００の動作を制御するためのソフトウェアプログラムの更新データである。
【００５４】
指示受信部２１５は、レコーダ１００の本体部に設けられた操作ボタン、または、リモートコントローラからの赤外線を受光する受光部である。指示受信部２１５は、ユーザから、例えば録画の開始／停止、録画した番組の再生の開始／停止等の指示や、装填されたメモリカード１１２の静止画をＢＤ２０５ａまたはＨＤＤ２０５ｂにコピーする指示を与える。
【００５５】
インターフェース（Ｉ／Ｆ）部２１６は、レコーダ１００が他の機器と通信するためのコネクタおよびその通信を制御する。Ｉ／Ｆ部２１６は、例えばＵＳＢ２．０規格の端子、ＩＥＥＥ１３９４規格の端子および各規格によるデータ通信を可能とするコントローラを含み、各規格に準拠した方式でデータを授受することができる。例えば、レコーダ１００は、ＵＳＢ２．０規格の端子を介してＰＣ１０８や、カムコーダ（図示せず）等と接続され、ＩＥＥＥ１３９４規格の端子の端子を介してデジタルハイビジョンチューナや、カムコーダ（図示せず）等と接続される。
【００５６】
メモリカード制御部２１７は、メモリカード１１２をレコーダ１００に装填するためのスロット、および、レコーダ１００とメモリカード１１２との間のデータ通信を制御するコントローラである。メモリカード制御部２１７は、ＣＰＵバス２１３を介して動画データ、静止画データ、それらに関連する管理情報等を受け取り、装填されたメモリカード１１２、１１３に書き込む。またメモリカード制御部２１７は、装填されたメモリカード１１２、１１３から静止画データファイル、動画データファイル等を読み出して、ＣＰＵバス２１３に伝送する。
【００５７】
システム制御部２５０は、レコーダ１００内の信号の流れを含む全体的な処理を制御する。システム制御部２５０は、プログラムＲＯＭ２１０と、ＣＰＵ２１１と、ＲＡＭ２１２とを有している。それぞれはＣＰＵバス２１３に接続されている。プログラムＲＯＭ２１０にはレコーダ１００を制御するためのソフトウェアプログラムが格納されている。
【００５８】
ＣＰＵ２１１は、レコーダ１００の全体の動作を制御する中央制御ユニットである。ＣＰＵ２１１は、プログラムを読み出して実行することにより、プログラムに基づいて規定される処理を実現するための制御信号を生成し、ＣＰＵバス２１３を介して各構成要素に出力する。またＣＰＵ２１１は、後述の管理情報（例えば図２４に示す管理ファイル８２、プレイリストファイル８３、クリップ情報ファイル８４）を生成し、ＣＰＵバスを介してＴＳ処理部２０４やメモリカード制御部２１７に出力する。
【００５９】
メモリ２１２は、ＣＰＵ２１１がプログラムを実行するために必要なデータを格納するためのワーク領域を有する。例えば、ＣＰＵ２１１は、ＣＰＵバス２１３を使用してプログラムＲＯＭ２１０からプログラムをランダムアクセスメモリ（ＲＡＭ）２１２に読み出し、そのプログラムを実行する。なお、コンピュータプログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録して市場に流通され、または、インターネット等の電気通信回線を通じて伝送される。これにより、ＰＣ等を利用して構成されたコンピュータシステムを、本実施形態によるレコーダ１００と同等の機能を有するデータ処理装置として動作させることができる。
【００６０】
図６は、ＴＳ処理部２０４の詳細な機能ブロックの構成を示す。ＴＳ処理部２０４は、ソース・パケタイザ２６１と、クロックカウンタ２６２と、ＰＬＬ回路２６３と、バッファ２６４と、ソース・デ・パケタイザ２６５とを有する。
【００６１】
ソース・パケタイザ２６１は、パーシャルＴＳを受け取り、そのパーシャルＴＳを構成するＴＳパケットの前に所定のヘッダを付加してソースパケットを生成して出力する。ヘッダには、そのＴＳパケットを受信した時刻（すなわちそのＴＳパケットの到着時刻）を示す時刻情報ＡＴＳ（Ａｒｒｉｖａｌ  Ｔｉｍｅ  Ｓｔａｍｐ）が含まれている。ＴＳパケットの到着時刻は、ソース・パケタイザ２６１に与えられる基準時刻からのカウント値（カウント情報）に基づいて特定される。ＴＳパケットの到着時刻に関する情報を含める理由は、図７を参照しながら後述する。
【００６２】
クロックカウンタ２６２およびＰＬＬ回路２６３は、ソース・パケタイザ２６１がＴＳパケットの到着時刻を特定するために必要な情報を生成する。まずＰＬＬ回路２６３は、パーシャルＴＳに含まれるＰＣＲパケット（図２のＰＣＲ＿ＴＳＰ）を抽出して、基準時刻を示すＰＣＲ（Ｐｒｏｇｒａｍ  Ｃｌｏｃｋ    Ｒｅｆｅｒｅｎｃｅ：プログラム時刻基準参照値）を取得する。ＰＣＲの値と同じ値がレコーダ１００のシステム基準時刻ＳＴＣ（Ｓｙｓｔｅｍ  Ｔｉｍｅ  Ｃｌｏｃｋ）として設定され、基準時刻とされる。システム基準時刻ＳＴＣのシステムクロックの周波数は２７ＭＨｚである。ＰＬＬ回路２６３は、２７ＭＨｚのクロック信号をクロックカウンタ２６２に出力する。クロックカウンタ２６２はクロック信号を受け取り、そのクロック信号をカウント情報としてソース・パケタイザ２６１に出力される。
【００６３】
バッファ２６４は、ライトバッファ２６４ａおよびリードバッファ２６４ｂを有する。ライトバッファ２６４ａは、送られてきたソースパケットを逐次保持し、合計のデータ量が所定値（例えばバッファの全容量）になったときに、書き込みのためにＢＤ２０５ａ等に出力する。このとき出力される一連のソースパケット列（データストリーム）を、クリップＡＶストリームと呼ぶ。一方、リードバッファ２６４ｂは、ＢＤ２０５ａ等から読み出されたクリップＡＶストリームを一時的にバッファして、ソースパケット単位で出力する。
【００６４】
ソース・デ・パケタイザ２６５は、ソースパケットを受け取ってＴＳパケットに変換し、パーシャルＴＳとして出力する。留意すべきは、ソース・デ・パケタイザ２６５は、クロックカウンタ２６２から与えられるタイミング情報と、ソースパケットに含まれていたＴＳパケットの到着時刻情報ＡＴＳとに基づいて、元の到着時刻に対応する時間間隔でＴＳパケットを出力することである。これにより、ＴＳ処理部２０４は、記録時のＴＳパケットの到着タイミングと同じタイミングでＴＳパケットを出力することができる。なお、ソース・デ・パケタイザ２６５は、読み出したパーシャルＴＳの基準時刻を指定するために、例えば最初のソースパケットにおいて指定されている到着時刻を初期値としてクロックカウンタ２６２に送る。これにより、クロックカウンタ２６２においてその初期値からカウントを開始させることができ、よってその後のカウント結果をタイミング情報として受け取ることができる。
【００６５】
ここで、図７を参照しながら、ＴＳ処理部２０４において行われる処理を具体的に説明する。図７（ａ）〜（ｅ）は、トランスポートストリームとクリップＡＶストリームとの関係を示す。参考のため、図７（ａ）にフルＴＳ７０を示している。フルＴＳ７０は、ＴＳパケットが連続して配置されており、例えば３つの番組Ｘ，ＹおよびＺのデータを含む。図７（ｂ）は、デジタルチューナ２０１ａによってフルＴＳ７０から生成されたパーシャルＴＳ７１を示す。パーシャルＴＳ７１は、連続したフルＴＳから一部のパケットを取り出したストリームであるため、パケットが時間的に離散して存在している。このパケットの間隔は、フルＴＳの送信側によって調整されており、デコーダにおいてデコードが適正に行われるために必要な条件を満たす。この「条件」とは、ＭＰＥＧ−２ＴＳでデコーダモデルとして規定されたＴ−ＳＴＤ（ＴＳシステムターゲットデコーダ；ＴＳ  Ｓｙｓｔｅｍ  Ｔａｒｇｅｔ  Ｄｅｃｏｄｅｒ）のバッファメモリがオーバーフローおよびアンダーフローなどの不具合を引き起こさないためにＭＰＥＧ規格上定められた条件である。
【００６６】
パーシャルＴＳ７１は、例えば番組Ｘに関するＴＳパケットを含んでいる。
【００６７】
図７（ｃ）は、クリップＡＶストリーム７２を示す。クリップＡＶストリーム７２は、ソースパケットが連続して配列されている。各ソースパケットは、ソースパケット番号（ＳＰＮ）＃０、１、２・・・で区別される。
【００６８】
図７（ｄ）は、ソースパケット７３のデータ構造を示す。ソースパケット７３のデータ長は１９２バイトに固定されている。すなわち、各ソースパケット７３は、１８８バイトのＴＳパケット７５の前に、４バイトのＴＰエクストラヘッダ７４を付加して構成されている。ソース・パケタイザ２６１は、パーシャルＴＳを構成するＴＳパケットの前にＴＰエクストラヘッダ７４を付加することにより、ソースパケットを生成している。
【００６９】
図７（ｅ）は、ＴＰエクストラヘッダ７４のデータ構造を示す。ＴＰエクストラヘッダ７４は、２ビットのコピー許可インジケータ（ＣＰＩ）７６と、３０ビットの到着タイムスタンプＡＴＳ７７とから構成されている。コピー許可インジケータ（ＣＰＩ）７６は、そのビット値に応じて、クリップＡＶストリーム７２の全部または一部のコピー回数（０回（コピー不可）／１回のみ／制限なし等）を規定している。到着タイムスタンプＡＴＳ７７には、２７ＭＨｚ精度で時刻が記述される。
【００７０】
次に、図８を参照しながら、クリップＡＶストリームがどのようにＢＤ２０５ａ上に記録されるかを説明する。なお、本実施形態においては、クリップＡＶストリームはメモリカード１１２、１１３等のＢＤ２０５ａ以外の記録媒体にも書き込まれる。メモリカード１１２、１１３においては、ＢＤ２０５ａとは異なるファイルシステム（本実施形態ではＦＡＴ３２ファイルシステム）が採用されている。よって、以下ではまず、クリップＡＶストリームがＢＤ２０５ａに書き込まれるときの態様を説明し、その後、クリップＡＶストリームがＦＡＴ３２ファイルシステムを採用する記録媒体に書き込まれるときの態様を説明する。
【００７１】
なお、クリップＡＶストリームはＨＤＤ２０５ｂにも記録され得る。このとき、ＢＤ２０５ａのファイルシステムおよびＦＡＴ３２ファイルシステムのいずれを採用して記録してもよい。ただし、ＨＤＤ２０５ｂは一般にレコーダ１００から取り外されて他の機器に装填されることはないため、独自のデータ構造によってデータを記録してもよい。
【００７２】
図８は、ＢＤ２０５ａの記録領域と、そのディレクトリ／ファイル構造を示す。ＢＤ２０５ａは、ギャザード・ファイル領域８１−１とリアルタイム・データ領域８１−２とを有する。ギャザード・ファイル領域８１−１の記録容量は数百メガバイトである。ギャザード・ファイル領域８１−１には、クリップＡＶストリームの再生等を管理する管理情報のファイル（データベースファイル）が記録される。図８に示すように、データベースファイルは複数種類存在しており、例えば管理ファイル８２（Ｉｎｆｏ．ｂｄａｖ）、プレイリストファイル８３（０１００１．ｒｐｌｓ、１００００．ｖｐｌｓ）、クリップ情報ファイル８４（０１０００．ｃｌｐｉ）が存在する。これらはアクセスされる頻度が高い。よって、ギャザード・ファイル領域８１−１は効率的にアクセスが可能な、ＢＤ２０５ａの記録領域の中間部に設けられている。また、データベースファイルはクリップＡＶストリーム等の動画ストリームを再生するために必須であり、記録内容の誤りは重大な障害を引き起こす。そのため、データベースファイルは同じＢＤＡＶディレクトリ内のＢＡＣＫＵＰディレクトリ（図示なし）にバックアップされてもよい。
【００７３】
一方、リアルタイム・データ領域８１−２の記録容量は片面単層のＢｌｕ−ｒａｙディスクであれば２３〜２７ギガバイトである。リアルタイム・データ領域８１−２には、クリップＡＶストリームのストリームファイルが記録される。例えばクリップＡＶストリームファイル８５（０１０００．ｍ２ｔｓ）が記録される。先のデータベースファイルと異なり、ストリームファイルの再生誤りの影響は局所的であり、その一方、連続的な読み出しを確保する必要がある。よって、誤りの発生を低減するよりも、連続読み出しを保証する方に重点をおいた書き込み処理が行われる。具体的には、クリップＡＶストリームファイル８５は最小で１２Ｍバイトの連続領域（連続した論理セクタ）に記録される。この最小の記録データサイズは「エクステント」と呼ばれる。なお、リアルタイム・データ領域８１−２には、ＤＶストリームを記録することもできるが、以下ではクリップＡＶストリームが記録されているとして説明する。
【００７４】
次に、図９を参照しながら、上述の管理ファイル８２、プレイリストファイル８３、クリップ情報ファイル８４およびクリップＡＶストリームファイル８５相互の関係を説明する。図９（ａ）〜（ｄ）は、管理情報とストリームデータとの関係を示す。図９（ａ）〜（ｃ）が管理情報であり、図９（ｄ）がストリームデータである。図９（ａ）は管理ファイル８２（Ｉｎｆｏ．ｂｄａｖ）に記述されるプレイリストのテーブルを示す。すなわち、管理ファイル８２には、ＢＤ２０５ａ上に存在するプレイリストを特定するプレイリストファイル名のテーブルが格納されている。ここで「プレイリスト」とは、１以上のクリップＡＶストリームの一部または全部に跨る再生経路を規定した情報である。
【００７５】
図９（ｂ）は、プレイリストファイル８３（拡張子：ｒｐｌｓ／ｖｐｌｓ）に記述されるプレイリストを示す。プレイリストは、リアルプレイリストおよびバーチャルプレイリストに分類できる。リアルプレイリストは、例えば初めてストリームデータが記録されたときにレコーダ１００によって生成されるプレイリストであり、再生経路として動画の最初から最後までが指定される。一方、バーチャルプレイリストは、記録されたストリームデータに対してユーザが設定したプレイリストであり、ユーザの希望する任意の位置および区間が指定される。
【００７６】
プレイリストの各区間は、プレイリスト内の各プレイアイテムにおいて規定される。すなわち、プレイアイテムには、再生開始位置に対応する開始時刻（Ｉｎ＿ｔｉｍｅ）および再生終了位置に対応する終了時刻（Ｏｕｔ＿ｔｉｍｅ）が記述される。開始時刻および終了時刻は、映像のフレームの再生表示時刻や音声のフレームの再生出力時刻を特定するプレゼンテーションタイムスタンプ（ＰＴＳ）によって記述される。通常、記録直後のリアルプレイリストではプレイアイテムは１つだけ設けられ、動画の最初と最後の時刻が指定される。一方、バーチャルプレイリストではプレイアイテムの数は任意である。１つのバーチャルプレイリストに複数のプレイアイテムを設け、各プレイアイテムが異なる動画ストリームを指定するように記述することもできる。
【００７７】
図９（ｃ）はクリップ情報ファイル（拡張子：ｃｌｐｉ）に記述される時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）を示す。変換テーブル（ＥＰ＿ｍａｐ）８４は、クリップＡＶストリームの再生時刻と、その時刻に再生されるデータが格納されたアドレスとを対応付けたテーブルである。この変換テーブル８４を利用することにより、プレイアイテムにおいて指定される開始時刻（Ｉｎ＿ｔｉｍｅ）および終了時刻（Ｏｕｔ＿ｔｉｍｅ）から、その時刻に再生すべきデータが格納されたクリップＡＶストリームにおけるアドレスを特定することができる。なお、この変換テーブル８４を利用した変換の原理は、後に図１３から図１５を参照しながら詳述する。
【００７８】
図９（ｄ）は、クリップＡＶストリームファイル８５（拡張子：ｍ２ｔｓ）に格納される動画ストリームを示す。この図では、ファイル“０１０００．ｍ２ｔｓ”および“０２０００．ｍ２ｔｓ”の各々がクリップＡＶストリームファイルである。
【００７９】
図９（ｃ）および（ｄ）に示すように、ＢＤ２０５ａ上では、１つのクリップＡＶストリームファイルに対して１つのクリップ情報ファイルが設けられる。以下では、クリップＡＶストリームファイルと、クリップ情報ファイルの対を、クリップ（Ｃｌｉｐ）と称する。
【００８０】
図１０は、プレイリストファイル８３に格納される情報（エントリ）およびそのデータ構造を示す。拡張子“ｒｐｌｓ”および“ｖｐｌｓ”ファイル８３内にはＰｌａｙＬｉｓｔ（）として示すエントリが存在する。これが上述の「プレイリスト」に対応する。プレイリスト情報（ＰｌａｙＬｉｓｔ）の下位には、プレイアイテム（ＰｌａｙＩｔｅｍ）１、２・・・が記述される。各プレイアイテムには再生対象となるクリップ情報ファイルのファイル名（Ｃｌｉｐ＿Ｉｎｆｏｒｍａｔｉｏｎ＿ｆｉｌｅ＿ｎａｍｅ）、ＳＴＣを特定するための識別子（ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ）、開始時刻（Ｉｎ＿ｔｉｍｅ）、終了時刻（Ｏｕｔ＿ｔｉｍｅ）等が格納される。なお、プレイリストファイル８３には、“プレイリストマーク（ＰｌａｙＬｉｓｔＭａｒｋ）”として示すエントリを設けることもできる。プレイリストマークの機能は後述する。
【００８１】
図１１および図１２は、クリップ情報ファイル８４に格納される情報（エントリ）およびクリップ情報ファイルのエントリに関するデータ構造を示す図である。クリップ情報ファイル８４には、種々のエントリが設けられている。このうち、図１１にはさらに、クリップ関連情報（ＣｌｉｐＩｎｆｏ）の詳細なデータ構造とシーケンス情報（ＳｅｑｕｅｎｃｅＩｎｆｏ）の詳細なデータ構造とが示されている。クリップ関連情報（ＣｌｉｐＩｎｆｏ）にもまた、複数のエントリが存在する。図１１には、クリップ関連情報に含まれる１つのエントリ（ＴＳ＿ｔｙｐｅ＿ｉｎｆｏ＿ｂｌｏｃｋ）の詳細なデータ構造が示されている。
【００８２】
また図１２によれば、特徴点情報（ＣＰＩ）内のエントリとして時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）が設けられていることが理解される。このテーブルは、１以上のクリップＡＶストリームごとに設けられた時間・アドレス変換テーブル（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ）の集合である。テーブル８６は、クリップＡＶストリームごとの時間・アドレス変換テーブル（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ）のデータ構造を示している。他のエントリ（ＣｌｉｐＭａｒｋ）等に関しては後述する。変換テーブル（ＥＰ＿ｍａｐ）は、録画した番組ごと、換言すれば記録したビデオＴＳパケットのＰＩＤごとに設けられる。
【００８３】
なお、図１２のＣＰＩテーブルに示されるように、ＥＰ＿ｍａｐに代えてＴＵ＿ｍａｐを設けることもできる。ＴＵ＿ｍａｐとは、パケットの到着時刻（ＡＴＳ）とソースパケット番号との対応を示すテーブルである。パケットの到着時刻のエントリは、例えば１秒間隔で設けられる。そして、その時刻の直後に最初に受け取られたＴＳパケットから生成されたソースパケットの番号が、その時刻に対応付けられる。
【００８４】
次に、図１３から図１５を参照しながら、時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）のデータ構造と、変換テーブル８４を利用した時間−アドレス変換の原理を説明する。図１３は、時間・アドレス変換テーブルのデータ構造を示す。変換テーブルでは、時間を示すタイムスタンプ（ＰＴＳ）とアドレスを示すソースパケット番号（ＳＰＮ）とが対応付けられている。このタイムスタンプ（ＰＴＳ）は、映像に関していえばＭＰＥＧ規格のＧＯＰの先頭に配置される各ＩピクチャのＰＴＳを表す。またソースパケット番号（ＳＰＮ）とは、そのＰＴＳに対応する時刻に再生されるＩピクチャの先頭データが格納されたソースパケット番号（ＳＰＮ）である。ソースパケットのデータサイズは１９２バイトであるから、ソースパケット番号が特定されるとクリップＡＶストリームの先頭からのバイト数が特定され、そのデータに容易かつ確実にアクセスできる。なお、この変換テーブルにおけるソースパケット番号Ｘ１、Ｘ２等の実際の値は必ずしも連続する整数ではなく、飛び飛びに大きくなっていく整数値である。
【００８５】
図１４は、第１の例による時間とアドレスの対応を示す。上述のように、時間・アドレス変換テーブルにはＧＯＰの先頭に配置される各ＩピクチャのＰＴＳ値のみが記述されているため、そのＰＴＳ値以外のＰＴＳ値が開始時刻（Ｉｎ＿ｔｉｍｅ）および／または終了時刻（Ｏｕｔ＿ｔｉｍｅ）として指定されると、その時刻に対応するアドレス（ソースパケット番号）を直接得ることができない。しかし、ＭＰＥＧ−２ビデオの符号化圧縮方式では、ピクチャ間の差分を用いて圧縮処理を行うため、最初にＧＯＰ先頭のＩピクチャを復号しなければ、続くピクチャも復号できない。したがって、Ｉピクチャのエントリが記述されていれば実際の再生には問題なく、それ以上のピクチャ単位の再生制御は、時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）で指定されるＩピクチャから復号を開始し、続くピクチャを解析／復号しながら、期待されるピクチャだけを表示処理すればよいことになる。
【００８６】
図１５は、第２の例による時間とアドレスの対応を示す。図１４の例と異なる点を説明する。放送番組の録画は、１つの番組のみならず連続する複数の番組に亘る場合がある。このとき、ＰＴＳやソースパケット番号の値は１つの番組内（パーシャルＴＳ内）では一意に定められているが、番組相互での調整はされていない。よって、ＰＴＳやソースパケット番号の値は、２つ以上の番組において重複する場合がある。したがって、そのような場合にも時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）によって確実に時間とアドレスとの変換を可能にする必要がある。そこで、特定の再生ポイントを一意に特定するための情報（ＳＴＣ＿ＩＤ）を規定し、時刻情報とともにソースパケット番号を特定するために利用する。
【００８７】
まず、最初に録画されている番組に対し、ＳＴＣ＿ＩＤ＝０を与える。図６に関連して説明したように、各パーシャルＴＳは独自のシステム時刻基準ＳＴＣに基づいて処理されるため、番組の切り替え点においてはシステム時刻基準ＳＴＣが不連続になる。図１５には、番組Ａ、ＢおよびＣを録画したときにおいて、番組ＡとＢ、および、番組ＢとＣとの間にＳＴＣ不連続点が存在する例を示す。各タイミングにおいて異なるＳＴＣ＿ＩＤが設定されている。図１５では、最初の番組ＡはＳＴＣ＿ＩＤ＝０、次の番組ＢはＳＴＣ＿ＩＤ＝１、最後の番組ＣはＳＴＣ＿ＩＤ＝２である。さらに、１つのＳＴＣ＿ＩＤのストリームの最長再生時間を規定することで、同一のＳＴＣ＿ＩＤ内でも同一のＰＴＳが存在しないことを保証している。なお、ＭＰＥＧのＰＴＳは９０ＫＨｚ精度で３３ビット長であるため、約２６．５時間までであれば一意のＰＴＳを与えて表示時刻を正しく記述できる。
【００８８】
上述のようにＳＴＣ＿ＩＤを割り当てておくことにより、時刻情報（Ｉｎ＿ｔｉｍｅ／Ｏｕｔ＿ｔｉｍｅ）およびＳＴＣ＿ＩＤに基づいて、本来指定されたとおりの適切なソースパケット番号を得ることができる。図１０に示すＰｌａｙＩｔｅｍ（）には、開始時刻（ＩＮ＿ｔｉｍｅ）および終了時刻（ＯＵＴ＿ｔｉｍｅ）の情報とともにＳＴＣ＿ＩＤを特定するためのエントリ（ｒｅｆ＿ｔｏ＿ＳＴＣ＿ｉｄ）が設けられていることが理解される。
【００８９】
なお、カムコーダ１１０のように、その機器自らが映像信号をエンコードしてクリップＡＶストリームを生成するときには、１回の録画開始から終了までの、一連続な記録区間内でＳＴＣを不連続にする必要はない。このようなときには、その一連続な記録区間中ではＳＴＣが不連続にならないように機器の動作を制限してもよい。なお、レコーダ１００が映像信号を受け取って、ＡＤＣ２０２およびエンコーダ２０３を利用してエンコードするときも同様である。
【００９０】
次に、図１６から図１９を参照しながら、バーチャルプレイリストを利用したクリップＡＶストリームの編集処理を説明する。図１６（ａ）は、リアルプレイリスト１および２と、対応するクリップ１および２を示す。クリップ１の一部およびクリップ２の一部を連続して再生するバーチャルプレイリストを生成することを考える。図１６（ｂ）は、ＩＮ１からＯＵＴ１までの第１区間およびＩＮ２からＯＵＴ２までの第２区間を連続して再生するバーチャルプレイリストを示す。第１区間および第２区間はそれぞれバーチャルプレイリスト内の別個のプレイアイテムによって指定される。バーチャルプレイリストによれば、リアルプレイリスト１および２およびクリップ１および２を直接加工することなく、別個のクリップの一部の再生区間を見かけ上つなぎ合わせることができる。
【００９１】
しかしながら、前述の通り、ＭＰＥＧ−２ビデオ圧縮方式はピクチャ間の差分を用いて圧縮しているため、ＩＮ２で飛び込んだ直後のピクチャは、そのピクチャの復号に必要な先行するピクチャのデータが取得されていないために通常復号できず、しばらく映像が表示されないことになる。
【００９２】
映像のみに関し、シームレスな再生を実現するためには、もともとのストリームを破壊編集し、接続点でのビデオの再エンコードする必要がある。このとき、プレイアイテムの接続情報（ｃｏｎｎｅｃｔｉｏｎ＿ｃｏｎｄｉｔｉｏｎ）は「４」に設定される。しかしながら、破壊編集は元の映像が残らない編集である。そこで、破壊編集のような元のストリームの編集は行わずに、接合点付近のストリームを集め、シームレス接続できるように再エンコード処理した「ブリッジクリップ」というクリップを新たに設けることができる。再生時は、つなぎ目の直前でブリッジクリップに再生制御を切り替え、ブリッジクリップの再生後に第２区間の再生に移る。これにより、矛盾のない滑らかな場面の切り替えを実現することができる。なお、このブリッジクリップによる接続情報は「３」に設定される。
【００９３】
図１７（ａ）は、図１６（ｂ）のバーチャルプレイリストを分割するときの分割点の位置を示す。図１７（ｂ）は、分割されたバーチャルプレイリスト１および２を示す。バーチャルプレイリスト１は、リアルプレイリスト１の区間とリアルプレイリスト２の一部の区間の連続再生を規定する。一方、バーチャルプレイリスト２は、リアルプレイリスト２の残りの区間の再生を規定する。
【００９４】
図１７（ａ）および（ｂ）に示す処理とは逆の処理、すなわち複数のバーチャルプレイリストを併合することもできる。図１８（ａ）は、併合の対象であるバーチャルプレイリスト１および２を示す。図１８（ｂ）は、１つに併合されたバーチャルプレイリストを示す。
【００９５】
図１７（ａ）および（ｂ）の例においても、また図１８（ａ）および（ｂ）の例においても、バーチャルプレイリストを用いることにより、リアルプレイリスト１および２およびクリップ１および２を直接加工することなく、クリップを見かけ上分割し、または併合することができる。
【００９６】
一方、リアルプレイリストの部分削除の場合には、クリップおよびリアルプレイリストを直接加工する必要がある。図１９（ａ）は、区間Ａ−Ｂを削除の対象とするリアルプレイリストおよびクリップを示す。そして、図１９（ｂ）は、区間Ａ−Ｂを削除して、点ＡおよびＢの位置を結合したリアルプレイリストおよびクリップを示す。リアルプレイリストの部分削除および削除の場合にのみクリップおよびリアルプレイリストを直接加工する理由は、リアルプレイリストのみが映像・音声データと直接の因果関係を持つためである。つまり、レコーダ上のユーザーインターフェースにおいて、ユーザにクリップを認識させず、リアルプレイリスト（ユーザにとって、クリップと同じ意味を持つ）とバーチャルプレイリスト（単なる再生経路情報）のみを提示することを想定しているためである。
【００９７】
次に、図２０を参照しながらサムネイルピクチャの管理を説明する。図２０は、ＢＤ２０５ａにおいて管理されるサムネイルピクチャと管理ファイルとの関係を示す。サムネイルピクチャとは、動画の一場面や静止画等の縮小されたピクチャであり、動画や静止画の内容を容易に確認する目的で設けられる。
【００９８】
サムネイルピクチャに関連するデータは、複数のファイルに格納される。図２０には、サムネイルピクチャを管理するメニューサムネイルファイル３０２およびマークサムネイルファイル３０４が示されている。メニューサムネイルファイル３０２は、ＢＤ２０５ａやプレイリストのサムネイルに関するインデクス情報を格納している。このインデクス情報は、メニューサムネイルファイル３０２において管理されるサムネイルピクチャ（サムネイルピクチャ３０２ａ、３０２ｂ等）の管理番号（ｍｅｎｕ＿ｔｈｕｍｂｎａｉｌ＿ｉｎｄｅｘ）を含む。サムネイルピクチャ３０２ａはバーチャルプレイリスト３１２の代表的な内容を示す。また、サムネイルピクチャ３０２ｂはボリュームサムネイルと呼ばれ、本ＢＤＡＶディレクトリの全体に関する代表的な内容を示す。なお図８には、メニューサムネイルファイル３０２に対応する“ｍｅｎｕ．ｔｉｄｘ”ファイルと、各サムネイルピクチャの実体データを示す“ｍｅｎｕ．ｔｄｔ（ｎ）”（ｎ＝１，２・・・）が示されている。
【００９９】
一方、マークサムネイルファイル３０４は、所望の映像の位置に付加され、しおりとして機能する「マーク」のサムネイルに関するインデクス情報を格納している。このインデクス情報も同様に、マークサムネイルファイル３０４において管理されるサムネイルピクチャ（サムネイルピクチャ３０４ａ、３０４ｂ、３０４ｃ等）の管理番号（ｍａｒｋ＿ｔｈｕｍｂｎａｉｌ＿ｉｎｄｅｘ）を含む。サムネイルピクチャ３０４ａはバーチャルプレイリスト３１２内のマークが付加された位置の縮小画像である。サムネイルピクチャ３０４ｂはリアルプレイリスト３１４内のマークが付加された位置の縮小画像である。また、サムネイルピクチャ３０４ｃはクリップ３１６内のクリップマークが付加された位置の縮小画像である。なお図８には、マークサムネイルファイル３０４に対応する“ｍａｒｋ．ｔｉｄｘ”ファイルと、各サムネイルピクチャの実体データを示す“ｍａｒｋ．ｔｄｔ（ｎ）”（ｎ＝１，２・・・）が示されている。上述の各サムネイルピクチャのデータは、ＪＰＥＧ規格に基づいて圧縮符号化されている。
【０１００】
上述のメニューサムネイルファイル３０２およびマークサムネイルファイル３０４を利用すると、サムネイルピクチャを一覧表示したり、特定のマークのみのサムネイルピクチャを選択的に表示させることができる。これにより、ユーザはそのＢＤ２０５ａで管理されている動画の概要、種々のプレイリストの概要、または、特定のプレイリストの複数の場面の概要を容易に把握できる。
【０１０１】
図２１（ａ）〜（ｃ）は、それぞれ、マークが付加されたバーチャルプレイリスト３１２、リアルプレイリスト３１４およびクリップ３１６を示す。ＢＤ２０５ａではユーザは複数種類のマークを設定することができる。すなわち、所望の動画等（コンテンツ）の頭出し点を指定する「ブックマーク」、再生を飛ばす点（区間）を指定する「スキップマーク」、および、先に視聴を停止したコンテンツの位置を指定する「レジュームマーク」、チャプターの先頭を指定する「チャプターマーク」等である。
【０１０２】
図２１（ａ）に示すバーチャルプレイリスト３１２には、ブックマークおよびレジュームマークが設定されている。これらのマークは、プレイリストファイル（拡張子：ｖｐｌｓ）の“ＰｌａｙＬｉｓｔＭａｒｋ”エントリに記述される。図１０には、“ＰｌａｙＬｉｓｔＭａｒｋ”エントリに対応するＰｌａｙＬｉｓｔＭａｒｋ（）が記載されている。ＰｌａｙＬｉｓｔＭａｒｋ（）において、“ｍａｒｋ＿ｔｙｐｅ”は、ブックマーク、レジュームマーク等のマークの種類を特定する情報である。“ｍａｒｋ＿ｔｉｍｅ＿ｓｔａｍｐ”は、マークが設定されるピクチャのタイムスタンプ（ＰＴＳ）を特定する情報である。各マークにはサムネイルピクチャを対応付けることもできる。図２１（ａ）に示すサムネイルピクチャ３０４ａは、ブックマークが設定された場面の縮小画像である。バーチャルプレイリスト３１２に設定されたサムネイルピクチャ３０４ａは、マークサムネイルファイル３０４において管理される。
【０１０３】
次に、図２１（ｂ）に示すリアルプレイリスト３１２には、ブックマーク、レジュームマークおよびスキップマークが設定されている。スキップマークについても、スキップ開始位置のサムネイルピクチャ３０４ｂを設定できる。またスキップする期間（ｄｕｒａｔｉｏｎ）もあわせて設定できる。
【０１０４】
図２１（ｃ）に示すクリップ３１６には、クリップマークが設定されている。クリップマークは、クリップＡＶストリームを生成した際にレコーダ１００が付加するマークである。ユーザはクリップマークの生成に関与できず、また生成されたクリップマークの削除等にも関与できない。クリップマークは、クリップに直接付加されるため、プレイリスト３１２および３１４に基づく再生時にもその機能は有効である。なお、クリップマークにもサムネイルピクチャ３０４ｃが設定され得る。
【０１０５】
上述の各マークには、録画機器（例えばレコーダ１００）のメーカごとのＩＤ（ｍａｋｅｒ＿ＩＤ）と独自情報（ｍａｋｅｒｓ＿ｐｒｉｖａｔｅ＿ｄａｔａ）を付加することもできる。これにより、マークを用いてメーカ独自に機器の機能を拡張することができる。
【０１０６】
これまでは、ＵＤＦのような映像・音声データファイルの扱いに優れたファイルシステムを利用した、動画ストリームの記録、編集、再生を説明した。次に、ＰＣで広く利用されているＦＡＴ３２ファイルシステムを利用した動画ストリームの記録、編集、再生を説明する。
【０１０７】
ＦＡＴ３２ファイルシステムは、映像・音声データファイルを主として扱うために策定されていないため、ＦＡＴ３２ファイルシステム上の各種ファイルのデータ構造を、これまでに説明したファイルシステム上のデータ構造と同じにすることは適切ではない。その理由は、ＦＡＴ３２ファイルシステムの制約により、４ＧＢを超えるファイルを記録することはできないからである。番組の録画や映像の撮影が長時間にわたると、動画ストリームのデータが４ＧＢを超える可能性は十分にある。以下、図２２および図２３を参照しながら、これまで説明したデータ構造をそのままＦＡＴ３２ファイルシステムにおいて適用したときの問題をより詳しく説明する。
【０１０８】
図２２（ａ）〜（ｄ）は、ＦＡＴ３２ファイルシステムにおいて、クリップＡＶストリーム８５および対応する管理情報ファイル８２〜８４を設けたときの第１の例を示す。図２２（ｄ）は、連続して撮影／録画された動画のデータが複数のファイルに分割して記録されていることを示す。なお、図２２（ａ）の管理ファイル８２は図９（ａ）の管理ファイルと同じであるため、説明は省略する。
【０１０９】
図２２（ｃ）および（ｄ）に示すように、ＦＡＴ３２ファイルシステムにおいては、連続して撮影／録画された動画が複数のクリップに分割されて格納されることがある。より詳細に説明すると、図２２（ｄ）のクリップＡＶストリームファイル８５は、（ｃ）のクリップ情報ファイル８４と１対１で生成され、その組がクリップとして定義される。ＦＡＴ３２ファイルシステムは４ＧＢ以上のファイルサイズを扱うことができないため、連続して撮影／録画された動画のデータが非常に大きくなると、４ＧＢ未満のクリップＡＶストリームファイルが複数生成され得る。するとその都度クリップ情報ファイル８４も生成され、結果としてクリップが複数生成される。これらのクリップにわたって映像を再生するためには、再生経路情報（プレイリスト）を設けて複数のクリップ間のつながりを規定し、一つの再生シーケンスとして設定する必要がある。図２２（ｂ）に示すプレイリストファイル８３（０１００１．ｒｐｌｓ）は、複数のクリップを一つの再生シーケンスとして連結したときの例を示す。なお、図９に示すようなＵＤＦを用いると、連続して撮影／録画された動画を１クリップとして収めることができる。
【０１１０】
次に、図２３を参照する。図２３（ａ）および（ｂ）は、編集前後のクリップを示す。図２３（ａ）は、図２２で生成されたプレイリストに対するクリップの編集範囲を示す。図２３（ａ）の例では、０１００２．ｍ２ｔｓファイルのストリームの途中を削除する編集を行うとする。このときクリップ情報ファイル（０１００２．ｃｌｐｉ）の対応する範囲の情報も削除される。図２３（ｂ）は、編集後のクリップ（０１００２．ｃｌｐｉファイルおよび０１００２．ｍ２ｔｓファイル）を示す。
【０１１１】
図２３（ａ）に示す編集前の状態では、連続して記録された動画ストリームのＳＴＣ＿ｉｄは１つ（ＳＴＣ＿ｉｄ＝１）である。このときは、複数のクリップＡＶストリームファイルにわたる１つのＳＴＣシーケンスが存在している。
【０１１２】
しかし、編集後の０１００２．ｍ２ｔｓファイルには、図２３（ｂ）にＳＴＣ＿ｉｄ＃１および＃２として示されるように２つのＳＴＣシーケンスが存在する。すなわち、１つの動画ファイル内に複数のＳＴＣシーケンスが存在する。なお、クリップＡＶストリームファイル０１００１．ｍ２ｔｓおよび０１００３．ｍ２ｔｓファイルには、引き続き複数のクリップＡＶストリームファイルにわたる１つのＳＴＣシーケンスが存在している。また、編集内容によっては、１つの動画ストリーム内に１つのＳＴＣシーケンスが存在することもある。
【０１１３】
今後、このような編集処理（部分削除処理）が繰り返されると、一つの動画ストリームを格納するファイルと、その中に格納されるＳＴＣシーケンスとの包含関係がさらに複雑に変動することが容易に理解される。
【０１１４】
また、半導体メモリ１１２のような比較的小型かつ小容量の記録媒体を利用して動画ストリームを記録する場合には、レコーダ装置にメモリカードスロットを複数用意できるため、異なる半導体メモリに跨って動画ストリーム（または一つのプレイリスト）が記録されることも想定される。そうなれば、記録媒体、動画ストリームファイル、ＳＴＣシーケンスの３者間の相関がさらに複雑になり得る。その結果、処理の複雑化および遅延が生じ得る。
【０１１５】
そこで、本実施形態においては図２４〜図２６に示す新たなデータ構造を規定して、柔軟なデータの管理を実現する。具体的には、１つにクリップＡＶストリームファイルに１つの管理情報ファイル（クリップ情報ファイル）を対応させるのではなく、１または複数のクリップＡＶストリームファイルと１つの管理情報ファイル（クリップ情報ファイル）とを対応させる。１つの管理情報ファイルだけで複数のストリームを管理すると、後述のようにタイムマップ（ＥＰ＿ｍａｐ）のみを参照すればこれらのファイルとシーケンスの関係を得ることができる。その結果、再生すべき映像は、ＰＴＳとＳＴＣシーケンスのみを利用して指定される。
【０１１６】
新たなデータ構造は、レコーダ１００、ＰＣ１０８、カムコーダ１１０のいずれもが構築できる。以下では、図５に示すレコーダ１００が新たなデータ構造を構築するとして説明する。
【０１１７】
レコーダ１００のエンコーダ２０３および／またはＣＰＵ２１１は、アナログ信号に基づいて映像を記録する時、および、デジタル信号に基づいて映像を記録する時のいずれにおいても、図２４〜図２６に示すデータ構造を構築できる。そこで、以下ではアナログ信号に基づいて映像が記録される例を説明する。記録媒体は、ＦＡＴ３２ファイルシステムを採用するメモリカード１１２であるとする。
【０１１８】
この例においては、エンコーダ２０３は、図４（ｄ）、（ｃ）、（ｂ）および（ａ）の順に処理を行って、トランスポートストリームを生成する。エンコーダ２０３は、各ピクチャのＰＴＳ等も同時に生成して、図４（ｂ）に示すＰＥＳヘッダ４１ａ−１に格納する。生成されたトランスポートストリームに基づいて、ＴＳ処理部２０４はクリップＡＶストリームを生成する。
【０１１９】
一方、ＣＰＵ２１１は管理情報を生成する。エンコーダ２０３およびＣＰＵ２１１は、ＣＰＵバス２１３を介して、クリップＡＶストリームおよび管理情報をメモリカード制御部２１７に送る。メモリカード制御部２１７は、クリップＡＶストリームおよび管理情報を受け取り、メモリカード１１２に書き込む。  図２４（ａ）〜（ｄ）は、本実施形態による、ＦＡＴ３２ファイルシステムにおいて好適な管理情報ファイル８２〜８４とクリップＡＶストリームファイル８５の関係を示す。図２４（ａ）〜（ｄ）に示す各ファイルは、例えばカムコーダ１１０を利用して動画が連続的に撮影されたときにメモリカード１１２に記録される。このメモリカード１１２は、ＦＡＴ３２ファイルシステムを採用する。いうまでもなく、メモリカード１１２の記録容量は全ファイルのファイルサイズの和以上である。
【０１２０】
本実施形態による管理構造は、以下に示す２つの主要な特徴を備えている。
【０１２１】
第１には、図２４（ｄ）に示すように、連続的に撮影された動画ストリームが複数のクリップＡＶストリームファイル（０２００１．ｍ２ｔｓ／０２００２．ｍ２ｔｓ／０２００３．ｍ２ｔｓ）に分割されていることである。上述のＦＡＴ３２ファイルシステムの制約により、各クリップＡＶストリームファイル８５のデータサイズは４ＧＢ未満である。
【０１２２】
ここで留意すべきは、各クリップＡＶストリームファイル８５内のクリップＡＶストリームには、同じＳＴＣ＿ｉｄが与えられていることである。さらに、ソース・パケタイザ２６１（図６）によって付加されるＡＴＳの値も連続的に変化している。その意味は、動画が連続して撮影されている間は、ＡＴＳを生成するためのクロックカウンタ２６２およびＰＬＬ回路２６３はリセットされることなく動作を継続することである。複数のクリップＡＶストリームファイル８５が生成されるか否かには影響を受けない。
【０１２３】
なお、クリップＡＶストリームファイルは動画を録画した直後において複数に分割されている必要はない。録画直後は１つであっても、編集等により複数のクリップＡＶストリームファイルが生成されてもよい。次に説明する管理情報を利用すれば、事後的に複数のクリップＡＶストリームファイルが生成されても統一的に動画ファイル群を管理できる。
【０１２４】
第２の主要な特徴は、図２４（ｃ）に示すように、クリップ情報ファイル８４（０２００１．ｃｌｐｉ）がクリップＡＶストリームファイルの数にかかわらず１つ設けられていることである。このクリップ情報ファイル８４は、クリップＡＶストリーム全体にわたる時間・アドレス変換テーブル（ＥＰ＿ＭＡＰ）を規定している。このクリップ情報ファイル８４を利用すれば、指定された時刻に再生すべき映像のデータがどのクリップＡＶストリームファイル８５に格納されているのか、そして、そのクリップＡＶストリームファイル８５内のどの位置（何番目のソースパケット）に格納されているのかを特定できる。
【０１２５】
なお、変換テーブルは、クリップＡＶストリームの全体にわたる時間とデータ位置（アドレス）との関係を規定している。よって、プレイリストファイル８３（０２００１．ｒｐｌｓ）内にはプレイアイテム（図１０）を１つ設ければ十分である。そのプレイアイテム内の開始時刻（Ｉｎ＿ｔｉｍｅ）および終了時刻（Ｏｕｔ＿ｔｉｍｅ）に、それぞれクリップＡＶストリーム先頭の時刻と末尾の時刻とを記述すればよい。
【０１２６】
次に、図２５および図２６を参照しながら、クリップ情報ファイル８４内のデータ構造を説明する。
【０１２７】
図２５は、時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）８７のデータ構造を模式的に示す。変換テーブル８７は、図１３に示す変換テーブルデータ構造を拡張して構成されている。具体的に説明すると、変換テーブル８７には時間（ＰＴＳ）およびアドレス（ＳＰＮ）との対応関係のみならず、そのソースパケットを含むファイル名が記述されている。なお、変換テーブル８７においても、タイムスタンプ（ＰＴＳ）はＭＰＥＧ規格のＧＯＰの先頭に配置される各ＩピクチャのＰＴＳを表すとする。
【０１２８】
変換テーブル８７にファイル名を記述する理由は、１つのクリップＡＶストリームが図２４に示すように複数のファイルに分割して格納されたためである。すなわち、与えられた時刻（ＰＴＳ）とソースパケット番号（ＳＰＮ）との対応関係のみでは、与えられたＰＴＳに対応するソースパケットがどのファイルに含まれているかを特定できないためである。
【０１２９】
なお、変換テーブル８７においては、ＰＴＳおよびＳＰＮの各値はコアースエントリ（ｃｏａｒｓｅ  ｅｎｔｒｙ）およびファインエントリ（ｆｉｎｅ  ｅｎｔｒｙ）に分けて格納されている。すべてのビットが記述されるのではない。例えば３３ビットのＰＴＳを例に挙げると、３３ビットのうち上位１７ビットをコアースエントリとし、下位１７ビットをファインエントリとして変換テーブル８７に記述する。最下位ビットから数えて１７ビット目はコアースエントリおよびファインエントリの両方に重複して規定されるが、これは設計上任意に変更できる。
【０１３０】
コアースエントリが共通する１以上のＰＴＳはそのコアースエントリのグループに分類される。そのグループにおいては、コアースエントリは１つしか記述されない。一方、ファインエントリは、ＰＴＳごとに記述される。同じグループの各ＰＴＳは、ファインエントリによって識別できる。
【０１３１】
上述のＳＰＮについても、まったく同様にコアースエントリおよびファインエントリが設けられる。そして、そのＳＰＮが与えられたソースパケットを含むファイル名も対応付けて記述される。なお、ファイル名はＳＰＮのすべてのファインエントリに対応して記述してもよいし、ＳＰＮのコアースエントリ単位で記述してもよい。
【０１３２】
ＰＴＳの各ビットをコアースエントリおよびファインエントリに分けることにより、変換テーブル８７のデータ量を低減できる。ＰＴＳからＳＰＮへの変換処理、および、得られたＳＰＮに対応するソースパケットがどのファイルに属するかは後述する。
【０１３３】
図２６は、変換テーブル８７の詳細なデータ構造を示す。変換テーブル８７は、大きく第１ループ８８、第２ループ８９および第３ループ９０に分けることができる。第１ループ８８のループ回数はＮｅ回、第２ループ８９のループ回数はＮｃ回、および第３ループ９０のループ回数はＮｆ回である。Ｎｅ、Ｎｃ、Ｎｆの各値はフィールド９１−１に記述されている。
【０１３４】
第１ループ８８は、後述のファイルエントリに対応する。第１ループ８８は、少なくとも、記録媒体、１つの記録媒体内のクリップＡＶストリーム格納先のフォルダ、クリップＡＶストリームのファイル名のいずれか１つが変化するたびに繰り返される。換言すれば、クリップＡＶストリームが複数の記録媒体、複数の格納フォルダおよび／または複数のファイルにまたがって格納されても、第１ループ８８を利用して記述できる。
【０１３５】
第１ループ８８は、例えばファイル名フィールド８８−１およびエントリＩＤフィールド８８−２を有している。ファイル名フィールド８８−１には、クリップＡＶストリームのファイル名が記述される。これにより、１つのクリップＡＶストリームが複数のファイルに跨ってもそのファイル名を記述できる。またエントリＩＤフィールド８８−２には、そのファイルに含まれるクリップＡＶストリームの先頭ソースパケットのファインエントリが記述される。
【０１３６】
第２ループ８９および第３ループ９０は、ＰＴＳとＳＰＮとの対応関係を規定する。この対応関係に基づいて時間とアドレスとを変換することができる。
【０１３７】
第２ループ８９は、ＰＴＳとＳＰＮの各コアースエントリが繰り返し記述される。第２ループ８９は、ファインＩＤフィールド８９−１、コアースフィールド８９−２および８９−３を有している。ファインＩＤフィールド８９−１は、各コアースエントリに対応する１以上のファインエントリを特定するために設けられる。コアースフィールド８９−２および８９−３は、それぞれＰＴＳコアースエントリおよびＳＰＮコアースエントリが記述される。
【０１３８】
第３ループ９０は、ＰＴＳとＳＰＮの各ファインエントリが繰り返し記述される。第３ループ９０は、オフセットフィールド９０−１、ファインフィールド９０−２および９０−３を有している。オフセットフィールド９０−１は、Ｉピクチャデータの末尾までのオフセット値が格納されている。ファインフィールド９０−２および９０−３は、それぞれＰＴＳファインエントリおよびＳＰＮファインエントリが記述される。
【０１３９】
なお、第１ループ８８には他のフィールドを設けることもできる。例えば、クリップＡＶストリームファイルが、どの記録媒体に記録されているかを識別するための記録媒体のシリアル番号等を記述するｍｅｄｉａ＿ｒｅｆ＿ｉｄフィールドや、そのストリームファイルがどのＢＤＡＶディレクトリに格納されているのかを示すＢＤＡＶ＿ｒｅｆ＿ｉｄフィールド等を設けることができる。ｍｅｄｉａ＿ｒｅｆ＿ｉｄフィールドを設けた理由は、複数の記録媒体を同時に装填可能なレコーダであれば分割されたクリップＡＶストリームファイルを異なる記録媒体に記録し得るため、各記録媒体を特定する必要が生じるからである。また、ＢＤＡＶ＿ｒｅｆ＿ｉｄフィールドを設けた理由は、ＢＤＡＶディレクトリは同じ記録領域（同一の記録媒体）に対して複数生成できるからである。
【０１４０】
クリップＡＶストリームが１以上のストリームファイルとして書き込まれると、各ストリームファイルのファイル名、クリップＡＶストリーム内の各ソースパケットの配置等が確定する。よって、ＣＰＵ２１１は上述の変換テーブル８７の各エントリの内容を確定することができる。ＣＰＵ２１１は、変換テーブル８７をクリップ情報ファイルに格納してメモリカード１１２へさらに書き込む。
【０１４１】
なお、ＣＰＵ２１１は、デジタル放送番組を録画する際にも変換テーブル８７を生成する。このときの処理は以下のとおりである。まずＣＰＵ２１１は、受信したトランスポートストリームを図４（ａ）から（ｃ）に示すデータ構造にしたがって解析する。そしてＣＰＵ２１１は、ピクチャヘッダ４２ａからＧＯＰヘッダおよびＩピクチャヘッダを検出してＧＯＰの先頭のＩピクチャを特定し、そのときのＰＥＳヘッダ４１ａ−１からＰＴＳを抽出する。これによりＣＰＵ２１１は、変換テーブル８７内のＰＴＳファインエントリを生成できる。一方、ＴＳ処理部２０４がトランスポートストリームからクリップＡＶストリームを生成したとき、ＣＰＵ２１１は、そのＧＯＰの先頭のＩピクチャのデータがどのソースパケットに格納されているかを特定できる。そのソースパケットが先頭から何番目に配置されているかにしたがって、ＣＰＵ２１１は、対応するＳＰＮファインエントリを生成できる。
【０１４２】
上述のアナログ／デジタル放送番組のいずれの例においても、クリップＡＶストリームの現実の書き込みが完了しなくても、ＣＰＵ２１１はそのストリームを格納したファイルのファイル名を変換テーブル８７に記述することは可能である。ストリームファイルのファイル名等は、書き込み開始前には予め決定されているためである。
【０１４３】
上述のように、本実施形態においては、一連の映像のデータストリームが複数のクリップＡＶストリームファイルに分割される。そして、各ファイルが複数の記録媒体に格納され、および／または、複数のＢＤＡＶディレクトリに格納されることを想定している。このような複雑な記録態様のもとで的確に再生を行うため、変換テーブル８７にはさらに状態フィールド９１−２が設けられている。
【０１４４】
例えば、変換テーブル８７が分割された全てのクリップＡＶストリームファイルの格納先を規定しているときには、レコーダ１００のＣＰＵ２１１は、状態フィールド９１−２に「１１」を記述する。一部のクリップＡＶストリームファイルの格納先のみを規定しているときには、状態フィールド９１−２に「１１」以外の値を記述する。レコーダ１００のＣＰＵ２１１は、全てのクリップＡＶストリームファイルの格納先が変換テーブル８７に記述されているか否かを判断できるため、その結果を状態フィールド９１−２に記述できる。再生時において状態フィールド９１−２の値を確認することにより、ＣＰＵ２１１は少なくとも全ての映像を再生できるか否かを特定できる。状態フィールド９１−２のさらに具体的な説明は、図３３を参照しながら後述する。
【０１４５】
次に、図２７を参照しながら、変換テーブル８７を利用してクリップＡＶストリームのピクチャを再生する手順を説明する。以下では、レコーダ１００が、図２４に示すメモリカード１１２から、変換テーブル８７を格納したクリップ情報ファイル８４、クリップＡＶストリームファイル８５等を読み出し、それらに基づいてピクチャを再生するとして説明する。なお、図２４に示す管理ファイル８２、プレイリストファイル８３、クリップ情報ファイル８４等は、メモリカード１１２がレコーダ１００に装填されたときにメモリカード制御部２１７によって読み出され、ＲＡＭ２１２に格納されているとする。
【０１４６】
図２７は、変換テーブル８７を利用して指定されたＰＴＳに対応するピクチャを再生する処理の手順を示す。まず、ステップＳ２７１において、システム制御部２５０のＣＰＵ２１１はピクチャの再生時刻を特定する情報（ＰＴＳ）を取得する。指定されるＰＴＳは、ユーザから指定された特定の再生時刻に対応するＰＴＳ値であってもよいし、早送り、早戻し再生等のときのＩピクチャの再生時刻に対応する値であってもよい。ここでは説明の簡単のため、ＧＯＰの先頭に配置されるＩピクチャのＰＴＳが指定されたとする。
【０１４７】
与えられたＰＴＳは、３３ビットのうち上位１７ビットと下位１７ビットとに分けて、以下処理される。
【０１４８】
ステップＳ２７２において、ＣＰＵ２１１は、与えられたＰＴＳ値の上位１７ビットを利用して、図２６の時間・アドレス変換テーブル８７（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ）中の第２ループ８９を参照し、そのＰＴＳが属するＰＴＳコアースエントリ８９−２および対応するＳＰＮコアースエントリ８９−３を特定する。また、同時にファインＩＤフィールド８９−１の値も特定される。ファインＩＤフィールド８９−１には、テーブル８７の第３ループ９０に関し、何番目のループを参照すればよいかを示す情報が記述されている。
【０１４９】
次に、ステップＳ２７３において、ＣＰＵ２１１は、特定されたファインＩＤフィールド８９−１の値を利用してテーブル８７の第３ループ９０を参照し、ＰＴＳ／ＳＰＮコアースエントリに対応するＰＴＳおよびＳＰＮファインエントリ９０−２および９０−３を特定する。この結果、そのＰＴＳに対応するＳＰＮ（コアースエントリおよびファインエントリ）が特定される。
【０１５０】
ステップＳ２７４においては、ＣＰＵ２１１は、ＳＰＮファインエントリ９０−３およびテーブル８７の第１ループ８８に基づいて、そのＳＰＮが付されたソースパケットを格納したファイル名を特定する。
【０１５１】
この処理は具体的には以下のとおり行われる。上述のように、第１ループ８８内のエントリＩＤフィールド８８−２には、各ファイルに含まれるクリップＡＶストリームの先頭ソースパケットのファインエントリの値が記述される。そして先頭ソースパケットのファインエントリ８８−２と対応して、ファイル名フィールド８８−１にはファイル名が記述されている。
【０１５２】
よって、ＣＰＵ２１１は、先のステップにおいて得られたＳＰＮファインエントリ９０−３の値が、エントリＩＤフィールド８８−２に記述されたファインエントリの値と等しいまたはそれよりも大きいか否かを判定する。等しいときには、ＣＰＵ２１１は、そのＳＰＮのファインエントリ８８−２と対応するファイル名フィールド８８−１からファイル名を特定する。大きいときには、ＣＰＵ２１１は、ＳＰＮファインエントリ９０−３の値が、次のエントリＩＤフィールド８８−２に記述されたファインエントリの値と同じまたはそれよりも大きいか否かを判定する。
【０１５３】
この処理を繰り返すと、いずれかの時点で、ＳＰＮファインエントリ９０−３の値が、エントリＩＤフィールド８８−２に記述されたファインエントリの値と等しく、またはそれよりも小さくなる。等しくなるときは上述のとおりファイル名を特定する。小さくなったときは、そのとき参照していたエントリＩＤフィールドの１つ前のエントリＩＤフィールドに規定されたファイル名フィールド８８−１から、ファイル名を特定する。
【０１５４】
その結果、ステップＳ２７５において、ＣＰＵ２１１はメモリカード制御部２１７に対して特定されたファイル名を指定して、１以上のソースパケットを読み出すよう指示する。読み出されるソースパケットは、先に特定されたＳＰＮが割り当てられたソースパケット以後の１以上のソースパケットである。ＴＳ処理部２０４は、読み出されたソースパケットを受け取り、図６に関連して説明した処理を行ったトランスポートストリームを、デコーダ２０６に送る。デコーダ２０６がピクチャを復号化すると、最終的にはアナログ信号としてＴＶ等へ出力され、再生が開始される。
【０１５５】
図２４から図２６に示すクリップ情報ファイル８４によれば、映像を部分的に削除する編集が行われ、一つの動画ストリームを格納するファイルと、その中に格納されるＳＴＣシーケンスとの包含関係が複雑になったときにも十分対応できる。例えば、図２８（ａ）および（ｂ）は、本実施形態による編集前後のクリップを示す。編集前後のクリップ情報ファイル８４はいずれも１つである。
【０１５６】
以下では、図２９および図３０を参照しながら、図２８（ｂ）におけるクリップ情報ファイル８４およびクリップＡＶストリームファイル８５をより詳しく説明する。
【０１５７】
図２９（ａ）〜（ｄ）は、図２８（ｂ）に示す編集処理後のクリップ情報ファイルとクリップＡＶストリームファイルとの対応を示す。ここでは、図２８（ｂ）の１番目および２番目のクリップＡＶストリームファイル（０２００１．ｍ２ｔｓおよび０２００２．ｍ２ｔｓ）を示している。以下図２９（ａ）〜（ｄ）を参照しながら、ＣＰＵ２１１が時間・アドレス変換テーブルを生成する処理とともにそのデータ構造を説明する。
【０１５８】
図２９（ａ）は、編集されたクリップＡＶストリームに対する、一つのクリップ情報ファイルに格納された時間・アドレス変換テーブルの概念を示す。図２９（ａ）の上から順に、１段目はファイルエントリが設けられている位置、２段目はコアースエントリが設けられている位置、３段目はファインエントリが設けられている位置を概念的に示している。
【０１５９】
このようなテーブルを生成するにあたり、ＣＰＵ２１１は時間・アドレス変換テーブルをＳＴＣシーケンス単位で記述する。図２９（ｂ）は、２つのＳＴＣシーケンスの範囲をそれぞれ示す。０２００１．ｍ２ｔｓの全体および０２００２．ｍ２ｔｓの編集点までのストリームにはＳＴＣ＿ｉｄ＃１が与えられており、０２００２．ｍ２ｔｓの編集点以降のストリームにはＳＴＣ＿ｉｄ＃２が与えられているとする。これらは別個のＳＴＣシーケンスである。また、図２９（ｃ）は、クリップＡＶストリームが格納された２つのファイルを示す。
【０１６０】
ＣＰＵ２１１は、まずＳＴＣシーケンス（ＳＴＣ＿ｉｄ＃１）の先頭（すなわちストリームファイル０２００１．ｍ２ｔｓの先頭）に対応するアドレスに関連付けて、テーブルにファイルエントリ＃０を登録する。ファイルエントリ＃０にはストリームファイルのファイル名（０２００１．ｍ２ｔｓ）が記述される。
【０１６１】
ＳＴＣシーケンスが進むと、その途中において、クリップＡＶストリームを格納しているファイルがストリームファイル０２００１．ｍ２ｔｓから０２００２．ｍ２ｔｓに切り替わる。そこで、ＣＰＵ２１１は、その切り替わり位置に対応するアドレスに関連付けて、テーブルにファイルエントリ＃１を登録する。ファイルエントリ＃１には次のストリームファイルのファイル名（０２００２．ｍ２ｔｓ）が記述される。
【０１６２】
図２６の第１ループ８８に示されるように、各ファイルエントリ８８−１とファインエントリ８８−２とは対応付けられて記述されている。本実施形態では、各ファイルエントリは、そのファイルエントリによって指定されたファイルにおいて最初に設けられたファインエントリと関連付けて第１ループ８８に格納される。
【０１６３】
本実施形態においては、ＳＴＣ＿ｉｄ＃１が割り当てられたクリップＡＶストリームは、ＦＡＴ３２ファイルシステムの制約に起因して複数のファイル０２００１．ｍ２ｔｓおよび０２００２．ｍ２ｔｓに格納されている。したがって、これらのファイルに跨るクリップＡＶストリームは、本来的には途切れることなく連続的に再生することができる。
【０１６４】
連続的な再生を保証するため、本実施形態においては、クリップＡＶストリームの各ソースパケットのヘッダ７４に格納されたＡＴＳの値は連続的かつ周期的に変化している。換言すれば、ＡＴＳの値は途切れることなく周期的に変化している。図２９（ｄ）は、複数のファイルに跨るクリップＡＶストリームのＡＴＳの変化を示す。ファイル０２００１．ｍ２ｔｓがファイル０２００２．ｍ２ｔｓに切り替わっている点においても、ＡＴＳの値は連続していることが理解される。
【０１６５】
これまでは、ファイルが切り替わると、クリップＡＶストリームのＳＴＣ＿ｉｄも変化することが前提であった。よって、ＴＳ処理部２０４およびデコーダ２０６は、異なるファイルからのクリップＡＶストリームを解析するときには処理回路を一旦リセットしていた。これにより、デコーダ２０６内の参照ピクチャ等が一時的に格納されているバッファもクリアされ、再生される映像は途切れていた。
【０１６６】
本実施形態においては、ＣＰＵ２１１は、ファイルが切り替わったときにはＴＳ処理部２０４およびデコーダ２０６の処理回路をリセットしない。ＴＳ処理部２０４のクロックカウンタ２６２、ＰＬＬ回路２６３等は、ファイルが切り替わっても継続して動作する。その結果、クロックカウンタ２６２は連続的に変換するタイミング情報を出力し、ソース・デ・パケタイザ２６５はその信号とＡＴＳとに基づいて、ＴＳパケットをデコーダ２０６へ送出する。これにより、クリップＡＶストリームが複数のファイルに跨って格納されていても、そのストリームのＡＴＳに基づいて途切れることなく映像を再生できる。
【０１６７】
ＣＰＵ２１１は、ＴＳ処理部２０４等の処理回路をリセットするか否かを判断する基準としてファイルエントリの記述を利用することができる。ファイルエントリに指定されたファイルを再生するときには、ＣＰＵ２１１は処理回路をリセットしない。その理由は、ファイルエントリの存在は、１つのクリップＡＶストリームが複数のファイルに分割されて格納されていることを意味するからである。ただし、ファイルエントリ＃０が付加されているときには新たなストリームの開始を意味するため、処理回路をリセットすればよい。
【０１６８】
一方、ＳＴＣ＿ｉｄ＃１がＳＴＣ＿ｉｄ＃２に切り替わっている点（例えば編集点）においては、ＡＴＳは不連続である。このときは映像の連続再生を保証する必要はない。またＳＴＣ＿ｉｄ＃２が割り当てられたストリームには改めてファイルエントリ＃０に格納ファイル名（「０２００２．ｍ２ｔｓ」）が付加される。よって、このストリームから映像を再生する時にはＴＳ処理部２０４およびデコーダ２０６等はリセットされる。
【０１６９】
これまでは、ファインエントリはＧＯＰの先頭に配置される各ＩピクチャのＰＴＳに基づいて設定されており、再生開始時刻としてそのようなＩピクチャのＰＴＳが指定されるとして説明した。しかし、一般的には、そのようなＩピクチャ以外のピクチャの再生開始時刻（ＰＴＳ）が指定される。以下、ファインエントリを利用して任意のピクチャから表示できることを説明する。
【０１７０】
図３０は、ファインエントリと各ＧＯＰの先頭に配置されるＩピクチャとの対応を示す。以下、ＧＯＰ（Ｎ−１）内の最後のＢピクチャ３０１を再生するための処理を説明する。与えられた再生開始時刻（ＰＴＳ）に対応するピクチャはＢピクチャ３０１である。
【０１７１】
なお、ＧＯＰ（Ｎ−１）はクリップＡＶストリームファイル０２００１．ｍ２ｔｓと０２００２．ｍ２ｔｓとに跨って格納されている。そしてＢピクチャ３０１のデータはファイル０２００２．ｍ２ｔｓに格納されているとする。
【０１７２】
まずＣＰＵ２１１がＰＴＳを取得すると、そのＰＴＳの上位１７ビットを利用して、ＰＴＳコアースエントリ８９−２、および、対応するＳＰＮコアースエントリ８９−３とファインＩＤフィールド８９−１とを特定する。続いてＣＰＵ２１１は、特定されたファインＩＤフィールド８９−１の値を利用して、ＰＴＳ／ＳＰＮコアースエントリに対応するＰＴＳおよびＳＰＮファインエントリ９０−２および９０−３を特定する。ここでは、図３０に示すファインエントリ（Ｎ−１）がＰＴＳファインエントリとして得られたとする。
【０１７３】
ＣＰＵ２１１は、得られたＰＴＳファインエントリと、与えられたＰＴＳの下位１７ビットとを比較し、後者の方が大きいと判断する。そしてＣＰＵ２１１は、得られたＰＴＳファインエントリの次のファインエントリ（図３０におけるＰＴＳファインエントリＮ）を、時間・アドレス変換テーブル８７の第３ループ９０から読み出し、そのＰＴＳファインエントリと、与えられたＰＴＳの下位１７ビットとを比較する。その結果、後者の方が小さいと判断する。
【０１７４】
この比較結果により、与えられたＰＴＳは、ＧＯＰ（Ｎ−１）の先頭Ｉピクチャよりは大きいがＧＯＰ（Ｎ）の先頭Ｉピクチャよりは小さいことが特定される。よって与えられたＰＴＳに対応するピクチャは、ＧＯＰ（Ｎ−１）に存在することが特定される。
【０１７５】
ここで、ＧＯＰ（Ｎ−１）の先頭Ｉピクチャから再生を開始するためには、そのＩピクチャのデータが格納されたファイル０２００１．ｍ２ｔｓを特定する必要がある。特定するための処理の手順は、先に図２７を参照しながら説明したとおりであるため、ここでは省略する。
【０１７６】
デコーダ２０６は、ＧＯＰ（Ｎ−１）の先頭Ｉピクチャから順に復号化し、与えられたＰＴＳと一致するＰＴＳのピクチャ（Ｂピクチャ３０１）が現れると、そのＢピクチャ３０１から出力を開始すればよい。上述の処理は、任意のピクチャに関して実行できる。
【０１７７】
本実施形態による時間・アドレス変換テーブル８７のように、所定のピクチャの再生時刻と記録アドレスとファイルエントリとを対応付けたテーブル（リスト）を設けることにより、記録媒体、ＡＶストリームファイル、ＳＴＣシーケンスの如何なる相関に対しても、正しく検索をかけることができる。
【０１７８】
上述の説明では、図２６に示すファイルエントリ（第１ループ８８）に４種類のフィールド（ｍｅｄｉａ＿ｒｅｆ＿ｉｄ、ＢＤＡＶ＿ｒｅｆ＿ｉｄ、Ｃｌｉｐ＿ＡＶ＿ｓｔｒｅａｍ＿ｆｉｌｅ＿ｎａｍｅおよびｆｉｒｓｔ＿ｆｉｎｅ＿ｅｎｔｒｙ＿ｒｅｆ＿ｉｄ）を設けた例を説明した。しかし、規定するフィールドは変更してもよい。
【０１７９】
図３１（ａ）〜（ｄ）は、ファインエントリのデータ構造の他の例を示す。図２６に示すファイルエントリ（第１ループ８８）中の先頭ソースパケットのファインエントリに代えて、種々の情報を記述できる。図３１（ａ）は、最初のコアースエントリおよび最後のコアースエントリの組を規定したフィールド８８ａを示す。図３１（ｂ）は、最初のファインエントリおよび最後のファインエントリの組を規定したフィールド８８ｂを示す。図３１（ｃ）は、最初のコアースエントリおよびコアースエントリの数の組を規定したフィールド８８ｃを示す。図３１（ｄ）は、最初のファインエントリおよびファインエントリの数の組を規定したフィールド８８ｄを示す。
【０１８０】
本実施形態においてはファイルエントリを追加したが、その追加に代えて、または追加とともに、ファイルエントリとして規定される情報（上述のｍｅｄｉａ＿ｒｅｆ＿ｉｄ、ＢＤＡＶ＿ｒｅｆ＿ｉｄ、Ｃｌｉｐ＿ＡＶ＿ｓｔｒｅａｍ＿ｆｉｌｅ＿ｎａｍｅ）の一部または全部を、コアースエントリ（図２６に示す第２ループ８９）またはファインエントリ（図２６に示す第３ループ９０）自体に格納してもよい。
【０１８１】
また、ＤＶＤビデオレコーディング規格のタイムマップＴＭＡＰに対して、上述のファイルエントリと同等のファイルエントリを追加することもできる。例えば、図３２は、ファイルエントリ３２、タイムエントリ３３およびＶＯＢＵエントリ３４を含む拡張されたタイムマップＴＭＡＰを示す。このような情報を得るためには、図２６（図３１（ａ）〜（ｄ）の変形例を含む）のコアースエントリに関する情報（第２ループ８９）をＴｉｍｅエントリとして置き換え、ファインエントリ（第１ループ８８）に関する情報をＶＯＢＵエントリに置き換えればよい。
【０１８２】
タイムマップＴＭＡＰに対してもファイルエントリを追加したが、その追加に代えて、または追加とともに、ファイルエントリとして規定される情報（上述のｍｅｄｉａ＿ｒｅｆ＿ｉｄ、ＢＤＡＶ＿ｒｅｆ＿ｉｄ、Ｃｌｉｐ＿ＡＶ＿ｓｔｒｅａｍ＿ｆｉｌｅ＿ｎａｍｅ）の一部または全部を、Ｔｉｍｅエントリ３３またはＶＯＢＵエントリ３４自体に格納してもよい。また、図２６に示す状態フィールド９１−２と同等の情報を格納するフィールドを設けてもよい。
【０１８３】
本実施形態においては、図２４に示されるように、メモリカード１１２に複数のクリップＡＶストリームファイルが記録されるとした。しかし、これら複数のファイルはそれぞれ別個の記録媒体に記録されてもよい。以下、図３３を参照しながら変形例を説明する。
【０１８４】
図３３（ａ）は、連続的に動画が撮影された「１ショット」の範囲を示す。図３３（ｂ）は、コンテンツの管理情報とストリームのデータとを含むクリップの概念を示す。１ショット、すなわち１つのコンテンツは、複数のクリップａ〜ｃに分けて各メモリカード１１２ａ〜１１２ｃに格納することができる（１つのクリップで完結してもよい）。１つのクリップは、クリップメタデータ３３１と、タイムマップ３３２と、クリップＡＶストリーム３３３の一部（部分ストリーム）とを含む。クリップＡＶストリーム３３３は、部分ストリーム３３３ａ〜３３３ｃから構成されており、クリップａ〜ｃのそれぞれに含まれる。図３３（ｂ）には３つのクリップａ〜ｃが記載されているが、各クリップの構成は共通しているため、ここではクリップａを例に挙げて説明する。記載の簡略化のため、部分ストリーム３３３ａを部分ストリームａなどと記載する。
【０１８５】
クリップａは、クリップメタデータａと、タイムマップａと、部分ストリームａとを含む。クリップメタデータａおよびタイムマップａは管理情報である。一方、部分ストリームａはクリップＡＶストリーム３３３を構成するデータである。このデータは、図２４（ｄ）に示すクリップＡＶストリームファイル８５（例えば０２００１．ｍ２ｔｓ）に対応する。
【０１８６】
クリップメタデータａはＸＭＬ形式で記述されており、コンテンツの再生に必要な情報、例えば映像／音声フォーマット等が規定される。クリップメタデータａの詳細は、図３４を参照しながら後述する。
【０１８７】
タイムマップａは、再生単位ごとの、表示時刻とその格納位置（アドレス）との関係を規定したテーブルである。ここでは、このタイムマップを「クリップタイムライン」（ＣｌｉｐＴｉｍｅＬｉｎｅ）と呼び、クリップタイムラインが格納されたファイルの拡張子に“ＣＴＬ”を付して図示している。タイムマップａは、図２６に示す時間・アドレス変換テーブル８７（ＥＰ＿ｍａｐ＿ｆｏｒ＿ｏｎｅ＿ｓｔｒｅａｍ）または図３２に示すタイムマップＴＭＡＰと同じである。
【０１８８】
図３３に示す例では、クリップメタデータおよびタイムマップは１つではなく、対応する部分ストリームファイルごとに存在していることに留意されたい。ただし、各タイムマップａ〜ｃは同一の情報である。例えば図５に示すレコーダ１００に３つのカードスロットが設けられ、そこにメモリカード１１２ａ〜１１２ｃが装填されている状態で、書き込み処理が行われることを想定する。レコーダ１００が部分ストリームファイルａ〜ｃをメモリカード１１２ａ〜１１２ｃに順次書き終えたとき、タイムマップの内容が確定する。その結果、レコーダ１００はさらにそのタイムマップを各メモリカード１１２ａ〜１１２ｃに書き込めばよい。なお、そのタイムマップには全てのストリームファイルの格納先が規定されているため、状態フィールド９１−２にはその状態を示す値「１１」が規定される。
【０１８９】
このタイムマップを利用することにより、再生のために各メモリカード１１２ａ〜１１２ｃが機器に装填されているときは、任意の記録媒体の任意のピクチャから再生を開始できる。タイムマップａ〜ｃが図２６に示す時間・アドレス変換テーブル８７であるとすると、機器のＣＰＵは、まず状態フィールド９１−２を参照して、各タイムマップａ〜ｃには全てのストリームファイルの格納先が規定されていると判断できる。さらに、再生を行うべき時刻（ＰＴＳ）の指定を受けると、どのメモリカードのタイムマップを利用しても、そのＣＰＵはそのＰＴＳに基づいて再生すべきピクチャのデータがどのメモリカードに格納されているかを特定し、かつ、そのデータを格納したストリームファイルのファイル名も特定できる。このとき、タイムマップ中の第１ループ８８のｍｅｄｉａ＿ｒｅｆ＿ｉｄフィールドおよびファイル名フィールド８８−１が参照される。
【０１９０】
なお、特定されたメモリカードがその機器に装填されていないことがある。このときは、その機器のＣＰＵは、そのメモリカードを特定する情報（メモリカード名）等をユーザに通知すればよい。さらに、ストリームファイルのファイル名も特定されているため、例えば「ファイル名ｘｘｘｘのファイルが記録されたメモリカードｙｙｙｙを挿入してください」という通知をＴＶの画面に表示してもよい。
【０１９１】
本実施形態の例において各メモリカードの容量を４ギガバイトとしたときには、各部分ストリームのファイルサイズをＦＡＴ３２ファイルシステムにおけるファイルサイズの最大値（４ギガバイト）とすると、メモリカード１１２ａ〜ｃの記録可能容量がなくなって管理情報をメモリカード１１２に書き込みできなくなる。よって、このときは各部分ストリームファイルのファイルサイズは４ギガバイトよりも小さくなることに留意されたい。さらに、部分ストリームは整数個のソースパケットから構成されるとし、上記ファイルシステムからの制限である４ギガバイト未満であり、かつ、ソースパケット（１９２バイト）の整数倍としてもよい。
【０１９２】
なお、１ショット内では、クリップＡＶストリーム３３３のシステム時刻基準ＳＴＣの識別情報（ＳＴＣ＿ｉｄ）は変化することはなく、到着時刻情報ＡＴＳも図２９（ｄ）に示すように連続している。この関係は、部分ストリームａ〜ｃに分割されても保持されるため、部分ストリームのＳＴＣ＿ｉｄは一致し、連続する２つの部分ストリームの境界の前後では、ＡＴＳも連続的に変化している。部分ストリームａ〜ｃの再生中にファイルが切り替わったときには、ＡＴＳのクロックカウンタ２６２（図６）がリセットされたり、それまでのカウント値とは無関係な値が設定されることはない。クロックカウンタ２６２（図６）は、設定されていた基準時刻に基づくカウントを継続的に行ってカウント値を出力する。
【０１９３】
図３３（ｃ）は、３つのメモリカード１１２ａ〜１１２ｃを示す。各クリップａ〜ｃを構成するデータのファイルが各メモリカード１１２ａ〜１１２ｃに書き込まれる。
【０１９４】
図３４は、クリップメタデータ３３１に含まれる情報の内容を示す。クリップメタデータ３３１は、構成データ（“Ｓｔｒｕｃｔｕｒａｌ”）および記述データ（“Ｄｅｓｃｒｉｐｔｉｖｅ”）の２種類に分類される。
【０１９５】
構成データには、クリップ名、エッセンスリスト、リレーション情報等が記述される。クリップ名は、そのファイルを特定するための情報であり、例えば周知のＵＭＩＤ（Ｕｎｉｑｕｅ  Ｍａｔｅｒｉａｌ  ＩＤｅｎｔｉｆｉｅｒ）が記述される。ＵＭＩＤは、例えば、コンテンツが生成された時刻とそれを生成した機器のＭＡＣ（Ｍｅｄｉａ  Ａｃｃｅｓｓ  Ｃｏｎｔｒｏｌ）アドレスを組み合わせて生成される。さらにＵＭＩＤは、コンテンツが新たに生成されたか否かをも考慮して生成される。すなわち、一旦ＵＭＩＤが付加され、その後に編集・加工等されたコンテンツには、元のコンテンツのＵＭＩＤとは異なる値が付加される。よってＵＭＩＤを利用すると世界中に存在するコンテンツに対して異なる値が定義されるため、コンテンツを一意に特定できる。
【０１９６】
エッセンスリストには、映像および音声の復号化に必要な情報（ビデオ情報およびオーディオ情報）が記述されている。例えばビデオ情報には、ビデオデータのフォーマット、圧縮符号化方式、フレームレートなどが記述される。オーディオ情報には、オーディオデータのフォーマット、サンプリングレート等が記述される。本実施形態では、圧縮符号化方式はＭＰＥＧ−２方式である。
【０１９７】
リレーション情報は、図３３（ｂ）に示すような複数のクリップａ〜ｃが存在するときのクリップの間の関係を規定する。具体的には、リレーション情報は、複数クリップの各々に対応するクリップＡＶストリーム（部分ストリーム）の再生の先後関係または再生順序を規定している。これらは、接続情報３４０として管理される。接続情報３４０は、そのショットの先頭のクリップを特定する情報、そのクリップの直前のクリップ名および直後のクリップ名を特定する情報がそれぞれ記述される。クリップ名を特定する情報は、例えば、ＵＭＩＤおよびそのメモリカード１１２固有のシリアル番号によって規定される。
【０１９８】
記述データには、アクセス情報、デバイス、撮影情報等が含まれている。アクセス情報には、そのクリップの最終更新者、日時等が記述されている。デバイス情報には、製造者名、記録した装置のシリアル番号、モデル番号等が記述されている。撮影情報は、撮影者名、撮影開始日時、終了日時、位置などを含む。
【０１９９】
なお、図３３に示す例では、各タイムマップａ〜ｃは同一の情報であるとしたが、同一の情報でなくてもよい。以下に、想定される（１）〜（４）のタイムマップの態様を説明する。
【０２００】
（１）部分ストリームごとに１つのタイムマップを設ける（タイムマップｘは部分ストリームｘのみの再生に用いられる）。このタイムマップによれば、指定された再生時刻（ＰＴＳ）が最初にアクセスしたタイムマップに記述されていなければ、上述のリレーション情報を用いて次のまたは前のクリップ等に移り、そのクリップにおいて再びタイムマップを参照する必要がある。
【０２０１】
（２）それまでに記録された全ての部分ストリームに対応するタイムマップを設ける（タイムマップｘは最初の部分ストリーム０から部分ストリームｘまでの部分ストリームの再生に用いられる）。このタイムマップによれば、指定された再生時刻（ＰＴＳ）のピクチャデータがそれまでに生成された部分ストリームに含まれているときには、そのデータが格納されたメモリカードやファイル名を、１つのタイムマップから特定できる。ただし、そのデータがそれまでの部分ストリームに含まれていないときには、リレーション情報を用いて次のクリップに移り、そのクリップにおいて再びタイムマップを参照する必要がある。
【０２０２】
（３）上述の（２）のタイムマップに、さらに次に記録される部分ストリームやタイムマップ等を特定する情報（例えば次の部分ストリームやタイムマップのファイル名）を追加的に規定したタイムマップを設ける（タイムマップｘは最初の部分ストリーム０から部分ストリームｘまでの部分ストリームの再生に用いられる。さらにタイムマップｘによれば、次の部分ストリーム（ｘ＋１）のファイルにアクセスできる）。このタイムマップによれば、上述の（２）の利点の他に、リレーション情報を介することなく次の部分ストリームファイルやタイムマップを直接特定できるため、アクセスを高速化できる。
【０２０３】
（４）全ての部分ストリームに対応するタイムマップを設ける（タイムマップｘは全ての部分ストリームの再生に用いられる）。この形態は、図３３を参照しながら説明した上述の態様と同じである。各メモリカードに格納されたタイムマップは互いに同一である。
【０２０４】
上述の状態フィールド９１−２を利用すれば、メモリカードに記録されたタイムマップが上述の（１）〜（４）のいずれの態様であるかを示すことができる。例えば状態フィールド９１−２には、（１）のタイムマップに対しては「００」、（２）のタイムマップに対しては「０１」、（３）のタイムマップに対しては「１０」、（４）のタイムマップに対しては「１１」の各値を記述すればよい。この状態フィールド９１−２の値に応じて、機器のＣＰＵは、与えられた再生時刻（ＰＴＳ）からどのように各ファイルを参照すればよいかの処理を切り替えることができる。
【０２０５】
以上説明した本発明に係るデータ処理は、コンピュータが所定のプログラムを実行することによって実現できることは言うまでもない。そのプログラムはフレキシブルディスク、ハードディスク、光ディスク、その他のコンピュータに読み取り可能な情報記録媒体に格納されることができる。
【０２０６】
本発明は、特定の実施形態について説明されてきたが、当業者にとっては他の多くの変形例、修正、他の利用が明らかである。それゆえ、本発明は、ここでの特定の開示に限定されず、添付の請求の範囲によってのみ限定され得る。
【産業上の利用可能性】
【０２０７】
本発明のデータ処理装置は、記録媒体とファイル、ファイルの中のストリームの包含関係に関わらず統一的に記述できるテーブル（アクセスマップ）を生成する。このアクセスマップには、そのストリームのファイルを特定する情報、そのファイルが記録される記録媒体の情報および／またはフォルダの情報等が格納される。この結果、データ処理装置は、アクセスマップによれば、ストリームの全部または一部の格納状況を、ストリームを解析して把握する必要はない。そしてアクセスマップを利用すれば、ストリームの所望の再生位置にアクセスすることができる。
【図面の簡単な説明】
【０２０８】
【図１】本発明の実施形態による光ディスクレコーダ１００と他の機器とによって形成されるシステムの構成を示す図である。
【図２】トランスポートストリーム（ＴＳ）２０のデータ構造を示す図である。
【図３】（ａ）はビデオＴＳパケット３０のデータ構造を示す図であり、（ｂ）は、オーディオＴＳパケット３１のデータ構造を示す図である。
【図４】（ａ）〜（ｄ）は、ビデオＴＳパケットからビデオピクチャを再生する際に構築されるストリームの関係を示す図である。
【図５】レコーダ１００の機能ブロックの構成を示す図である。
【図６】ＴＳ処理部２０４の詳細な機能ブロックの構成を示す図である。
【図７】（ａ）〜（ｅ）は、トランスポートストリームとクリップＡＶストリームとの関係を示す図である。
【図８】ＢＤ２０５ａの記録領域と、そのディレクトリ／ファイル構造を示す図である。
【図９】（ａ）〜（ｄ）は、管理情報とストリームデータとの関係を示す図である。
【図１０】プレイリストファイル８３に格納される情報（エントリ）およびプレイリストファイルのデータ構造を示す図である。
【図１１】クリップ情報ファイル８４に格納される情報（エントリ）およびクリップ情報ファイルの一部のエントリに関するデータ構造を示す図である。
【図１２】クリップ情報ファイル８４に格納される情報（エントリ）およびクリップ情報ファイルの他の一部のエントリに関するデータ構造を示す図である。
【図１３】時間・アドレス変換テーブルのデータ構造を示す図である。
【図１４】第１の例による時間とアドレスの対応を示す図である。
【図１５】第２の例による時間とアドレスの対応を示す図である。
【図１６】（ａ）はリアルプレイリスト１および２と、対応するクリップ１および２を示す図であり、（ｂ）はＩＮ１からＯＵＴ１までの第１区間およびＩＮ２からＯＵＴ２までの第２区間を連続して再生するバーチャルプレイリストを示す図である。
【図１７】（ａ）はバーチャルプレイリストを分割するときの分割点の位置を示す図であり、（ｂ）は分割されたバーチャルプレイリスト１および２を示す。
【図１８】（ａ）は併合の対象であるバーチャルプレイリスト１および２を示す図であり、（ｂ）は１つに併合されたバーチャルプレイリストを示す図である。
【図１９】（ａ）は区間Ａ−Ｂを削除の対象とするリアルプレイリストおよびクリップを示す図であり、（ｂ）は区間Ａ−Ｂを削除して、点ＡおよびＢの位置を結合したリアルプレイリストおよびクリップを示す図である。
【図２０】ＢＤ２０５ａにおいて管理されるサムネイルピクチャと管理ファイルとの関係を示す図である。
【図２１】（ａ）〜（ｃ）は、それぞれ、マークが付加されたバーチャルプレイリスト３１２、リアルプレイリスト３１４およびクリップ３１６を示す図である。
【図２２】（ａ）〜（ｄ）は、ファイルサイズに上限のあるファイルシステムでのファイル構成を説明する図である。
【図２３】（ａ）および（ｂ）は、途中が削除される前後のストリームとシーケンスの相関関係を示す図である。
【図２４】（ａ）〜（ｄ）は、本実施形態による、ＦＡＴ３２ファイルシステムにおいて好適な管理情報ファイル８２〜８４とクリップＡＶストリームファイル８５の関係を示す図である。
【図２５】時間・アドレス変換テーブル（ＥＰ＿ｍａｐ）８７のデータ構造を模式的に示す図である。
【図２６】変換テーブル８７の詳細なデータ構造を示す図である。
【図２７】変換テーブル８７を利用して指定されたＰＴＳに対応するピクチャを再生する処理の手順を示すフローチャートである。
【図２８】（ａ）および（ｂ）は、本実施形態による編集前後のクリップを示す図である。
【図２９】（ａ）は編集されたクリップＡＶストリームに対する、一つのクリップ情報ファイルに格納された時間・アドレス変換テーブルの概念を示す図であり、（ｂ）は２つのＳＴＣシーケンスの範囲をそれぞれ示す図であり、（ｃ）はクリップＡＶストリームが格納された２つのファイルを示す図であり、（ｄ）は複数のファイルに跨るクリップＡＶストリームのＡＴＳの変化を示す図である。
【図３０】ファインエントリと各ＧＯＰの先頭に配置されるＩピクチャとの対応を示す図である。
【図３１】（ａ）〜（ｄ）は、ファインエントリのデータ構造の変形例を示す図である。
【図３２】本実施形態によるタイムマップのデータ構造を示す図である。
【図３３】（ａ）は本実施形態における１コンテンツの概念を示す図であり、（ｂ）はコンテンツの管理情報とストリームのデータとを含むクリップの概念を示す図であり、（ｃ）は３つのメモリカード１１２ａ〜１１２ｃを示す図である。
【図３４】クリップメタデータ３３１に含まれる情報の内容を示す図である。
【符号の説明】
【０２０９】
１００  ＨＤＤ内蔵ＢＤレコーダ
１０６  ＴＶ
１０８  ＰＣ
１１２  メモリカード
１１４  ＢＤ
２０１ａ  デジタルチューナ
２０１ｂ  アナログチューナ
２０２  ＡＤコンバータ
２０３  ＭＰＥＧ−２エンコーダ
２０４  ＴＳ処理部
２０５ａ  ＢＤ
２０５ｂ  ＨＤＤ
２０６  ＭＰＥＧ−２デコーダ
２０７  グラフィック制御部
２０８  メモリ
２０９  ＤＡコンバータ
２１０  プログラムＲＯＭ
２１１  ＣＰＵ
２１２  ＲＡＭ
２１３  ＣＰＵバス
２１４  ネットワーク制御部
２１５  指示受信部
２１６  インターフェース（Ｉ／Ｆ）部
２１７  メモリカード制御部
２５０  システム制御部
２６１  ソース・パケタイザ
２６２  クロックカウンタ
２６３  ＰＬＬ回路
２６４  バッファ
２６５  ソース・デ・パケタイザ
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2006030767.tif 000036
【図２】
2006030767.tif 000037
【図３】
2006030767.tif 000038
【図４】
2006030767.tif 000039
【図５】
2006030767.tif 000040
【図６】
2006030767.tif 000041
【図７】
2006030767.tif 000042
【図８】
2006030767.tif 000043
【図９】
2006030767.tif 000044
【図１０】
2006030767.tif 000045
【図１１】
2006030767.tif 000046
【図１２】
2006030767.tif 000047
【図１３】
2006030767.tif 000048
【図１４】
2006030767.tif 000049
【図１５】
2006030767.tif 000050
【図１６】
2006030767.tif 000051
【図１７】
2006030767.tif 000052
【図１８】
2006030767.tif 000053
【図１９】
2006030767.tif 000054
【図２０】
2006030767.tif 000055
【図２１】
2006030767.tif 000056
【図２２】
2006030767.tif 000057
【図２３】
2006030767.tif 000058
【図２４】
2006030767.tif 000059
【図２５】
2006030767.tif 000060
【図２６】
2006030767.tif 000061
【図２７】
2006030767.tif 000062
【図２８】
2006030767.tif 000063
【図２９】
2006030767.tif 000064
【図３０】
2006030767.tif 000065
【図３１】
2006030767.tif 000066
【図３２】
2006030767.tif 000067
【図３３】
2006030767.tif 000068
【図３４】
2006030767.tif 000069
【国際調査報告】
2006030767.tif 000070
2006030767.tif 000071
2006030767.tif 000072
2006030767.tif 000073