(57)【要約】記録媒体に情報の記録を行う記録部と、前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、ディレクトリ及びファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、ディレクトリ及びファイルに対する拡張情報を管理する拡張情報処理部とを備えた記録装置である。コンテンツ管理情報は、パス名を変換して得られるオブジェクト参照情報によりディレクトリ及びファイルを参照するメディアオブジェクト管理情報と、拡張情報を管理する拡張オブジェクト管理情報とを含み、ディレクトリ及びファイルと拡張情報とが、オブジェクト参照情報を経由して対応付けられている。
2004095285.tif 000002
【特許請求の範囲】
【請求項１】
記録媒体に情報の記録を行う記録部と、
前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、
前記ディレクトリ及び前記ファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、
前記ディレクトリ及び前記ファイルに対する拡張情報を管理する拡張情報処理部と、を備えた記録装置であって、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが、前記オブジェクト参照情報を経由して対応付けられていることを特徴とする記録装置。
【請求項２】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、
前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報については、前記拡張情報を更新し、
処理不可能な種類の前記拡張情報については、前記拡張情報を更新せず、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じ
て前記整合性状態管理情報を更新する、請求項１に記載の記録装置。
【請求項３】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、
請求項２に記載の記録装置。
【請求項４】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記メディアオブジェクト管理情報を更新した時、
前記第１の更新日時情報を更新し、
処理可能な種類の前記拡張情報については、前記第２の更新日時情報に前記第１の更新日時情報と同じ値を設定し、
処理不可能な種類の前記拡張情報については、前記第２の更新日時情報を更新しない、請求項１に記載の記録装置。
【請求項５】
記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、
前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを備えた記録方法であって、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記記録方法は、
前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を含むことを特徴とする記録方法。
【請求項６】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、
前記記録方法は、
前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報を更新する工程と、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新する工程とを含む、請求項５に記載の記録方法。
【請求項７】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項６に記載の記録方法。
【請求項８】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記コンテンツ管理情報を更新する工程と、
前記第１の更新日時情報を更新する工程と、
処理可能な種類の前記拡張情報については、前記第２の更新日時情報に前記第１の更新日時情報と同じ値を設定する工程とを含む、請求項５に記載の記録方法。
【請求項９】
情報が記録された記録媒体であって、
前記情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、
前記ディレクトリ及び前記ファイルに対する拡張情報とが記録されており、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする記録媒体。
【請求項１０】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含む、請求項９に記載の記録媒体。
【請求項１１】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項１０に記載の記録媒体。
【請求項１２】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記ディレクトリ及び前記ファイルと、それに対応する前記拡張情報との整合性が保証されている場合に、
前記第１の更新日時情報と前記第２の更新日時情報に同じ値が記録されている、
請求項９に記載の記録媒体。
【請求項１３】
請求項１０または１１に記載の記録媒体から情報の再生を行う再生装置であって、
前記情報を前記記録媒体から再生する再生部と、
前記ファイルシステム情報を処理するファイルシステム処理部と、
前記拡張情報を処理する拡張情報処理部と、
前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、
前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定することを特徴とする再生装置。
【請求項１４】
請求項１２に記載の記録媒体から情報の再生を行う再生装置であって、
前記情報を前記記録媒体から再生する再生部と、
前記ファイルシステム情報を処理するファイルシステム処理部と、
前記拡張情報を処理する拡張情報処理部と、
前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、
前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定することを特徴とする再生装置。
【請求項１５】
請求項１０または１１に記載の記録媒体から情報の再生を行う再生方法であって、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを備え、
前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする再生方法。
【請求項１６】
請求項１２に記載の記録媒体から情報の再生を行う再生方法であって、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを備え、
前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする再生方法。
【請求項１７】
記録媒体へ情報の記録を行う記録装置において、当該記録装置の記録動作を制御するプログラムであって、
前記プログラムは、
記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、
前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを前記記録装置に実行させる命令を含み、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記プログラムは、
前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を前記記録装置に実行させる命令をさらに含むことを特徴とするプログラム。
【請求項１８】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性
に関する状態を管理する整合性状態管理情報を含み、
前記プログラムは、
前記記録装置が前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報を更新する工程と、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じ
て前記整合性状態管理情報を更新する工程と前記記録装置に実行させる命令を含む、請求項１７に記載のプログラム。
【請求項１９】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項１８に記載のプログラム。
【請求項２０】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記プログラムは、
前記コンテンツ管理情報を更新する工程と、
前記第１の更新日時情報を更新する工程と、
処理可能な種類の前記拡張情報については、前記第２の更新日時情報に前記第１の更新日時情報と同じ値を設定する工程を前記記録装置に実行させる命令を含む、請求項１７に記載のプログラム。
【請求項２１】
請求項１０または１１に記載の記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムであって、
前記プログラムは、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、
前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とするプログラム。
【請求項２２】
請求項１２に記載の記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムであって、
前記プログラムは、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、
前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とするプログラム。
【請求項２３】
請求項１７〜２２のいずれか一項に記載のプログラムを媒体に記録したプログラム提供媒体。
【請求項２４】
記録媒体に記録されたデータ構造であって、
前記記録媒体に記録されたコンテンツ情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、
前記ディレクトリ及び前記ファイルに対する拡張情報とを含み、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とするデータ構造。
【請求項２５】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含む、請求項２４に記載のデータ構造。
【請求項２６】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項２５に記載のデータ構造。
【請求項２７】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記ディレクトリ及び前記ファイルと、それに対応する前記拡張情報との整合性が保証されている場合に、
前記第１の更新日時情報と前記第２の更新日時情報に同じ値が記録されている、請求項２４に記載のデータ構造。
【発明の詳細な説明】
【技術分野】  本発明は、主に、記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体並びに当該記録媒体を再生する再生装置及び再生方法に関する。特に、画像データや音声データを記録媒体にファイルとして記録する記録再生装置、記録再生方法及び当該記録再生装置又は記録再生方法により記録された記録媒体に関する。
【背景技術】  近年、動画情報や静止画情報、音声情報等のＡＶデータをデジタル化して記録・再生することが良く行われている。このようなデジタル情報を蓄積する記録媒体としては、フラッシュメモリ等の半導体メモリ、あるいはディスクメディアであるＤＶＤ、ハードディスク、ＭＤ（ミニディスク）等が存在する。
これらの記録媒体に対して、ＭＰＥＧ２やＪＰＥＧ等の符号化方式で符号化されたＡＶデータの記録や再生が行われている。かかるＡＶデータの記録において、各ＡＶデータはファイルシステムによりファイルとして管理されており、それぞれの再生に際してもファイル単位での指定が行われている。
そして、上述した半導体メディアやディスクメディアにおいては、ランダムアクセス性という優れた特徴が存在する。ランダムアクセス性を利用することにより、ユーザからの指示等に従って、記録済みのファイルを任意の順番で再生することが可能となる。
さらにそれを発展させた技術として、プログラム再生機能の実現が挙げられる。例えば、特開２００２−１９９３３５号公報に開示されている記録／再生システムにおいては、ＡＶデータをメディアオブジェクトと呼ぶファイルとして記録し、複数のメディアオブジェクトをプログラムと呼ばれるディレクトリの下に記録している。このような記録形態とすることによって、記録媒体上には当該プログラムを複数個作成することが可能となる。
また、各プログラムに対してプログラム情報（ＰＲＧ＿ＩＮＦＯ）と呼ばれる情報を管理し、メディアオブジェクトとは異なるファイルとして記録媒体上に記録する。ＰＲＧ＿ＩＮＦＯに登録されるメディアオブジェクトの情報を参照することにより、記録媒体上に記録されたＡＶファイルの再生順序を自由に制御することが可能となる。
上述したような機能は、一般に「プログラム再生」と呼ばれており、ディスクメディアにおけるランダムアクセス性を利用することにより実現されている。
このように、ＡＶデータをメディアオブジェクトとして記録し、そのメディアオブジェクトを参照するプログラムもファイルとして記録する場合、当該プログラムファイルからメディアオブジェクトへの参照情報を持たなければならない。参照情報の形式は、ファイルに対するパス情報、すなわちファイルを管理するファイルシステム内で、当該ファイルの名前と階層位置を示す情報を用いるのが一般的である。
ここで、メディアオブジェクトとプログラムファイルとの関係の一例を図３０に示す。図３０は、メディアオブジェクトのディレクトリ構造と、プログラムファイルの構造の説明図である。
各プログラムファイル１０００２は、各メディアオブジェクト１０００１への参照を、ＲＯＯＴディレクトリ１００００からのフルパス名１０００３の形式で保持している。なお、図３０に例示したフルパス名においては、パス区切り文字は”／”として記述している。
上述したメディアオブジェクトやプログラムファイルは、全てＵＤＦやＦＡＴ等のファイルシステムを利用して管理される。ファイルシステムは、パーソナルコンピュータ（以下、「ＰＣ」という。）のアーキテクチャで一般的に利用され、ファイルシステムを導入することにより、上述のプログラムファイルを編集したり、再生したりするＰＣ上のアプリケーションソフトを作成することが容易となる。
図３０に示すように、プログラムファイル１０００２は、３つのメディアオブジェクト１０００１のプログラム再生を指示するものである。ここに示すように、複数のメディアオブジェクトがそれぞれ異なる親ディレクトリの下に記録されていてもプログラム再生を指示することが可能である。
また、半導体メディアやディスクメディアの異なる特徴として、データの追加と、それによる機能拡張の容易性が挙げられる。
特開２０００−５７７４５号公報や特開２００１−１６０２６９号公報の記録再生装置では、図３１に示すように、ＡＶデータであるビットストリームファイル１００１０と、それを管理する情報ファイル１００１１が存在する。この情報ファイル１００１１に新たなデータ（製造業体情報項目１００１２）を追加していくことにより、この記録再生装置に対する新たな機能の追加が可能となる。
しかし、上述した構成のようなプログラムファイルによるプログラム再生を実現するためには、それを処理する記録または再生装置などに、追加のハードウエア及びソフトウエア資源が要求される。
よって、ハードウエア及びソフトウエア資源が限られる記録／再生装置では、その実現が不可能な場合がある。
そのため、メディアオブジェクトの単純な記録及び再生に関しては基本機能としてすべての記録／再生機器で実現されることが想定されるが、上述のようなプログラム再生機能は拡張機能として位置づけられ、ある機器では処理可能であるが、別の機器では処理不可能となるような場合がありうる。
このような場合においても、ＤＶＤのようなディスクメディアは、一つのディスクメディアが複数の記録／再生機器で記録または再生がされる。
そのため、プログラム再生のような拡張機能に対応しない機器でディスクメディア上の情報を操作（メディアオブジェクトの編集や削除など）した場合、メディアオブジェクトの情報とプログラムファイルとの情報の間に不整合が発生してしまう。
そして、このような不整合状態にあるディスクメディアを、プログラム再生に対応した記録／再生機器で再生しようとすると、プログラムファイルで参照しているはずのメディアオブジェクトが存在しないので、場合によっては機器の誤動作の発生や、最悪の場合は動作が停止してしまう等、の不都合が生じる。
このような不都合を回避するためには、ある拡張機能に対応した記録／再生機器は、その拡張機能を使用する前に、拡張機能に関するデータの整合性をすべて確認する必要があるが、このデータの量が多くなる（例えばプログラムファイルの数が非常に多なる）と、その確認処理に時間がかかり、ユーザにとって非常に不便である。
また、特開２０００−５７７４５号公報及び特開２００１−１６０２６９号公報に記載されているような、情報ファイルに拡張機能のためのデータを追加していく構成においては、情報ファイルの容量増加が避けられない。
情報ファイルの基本的な部分は、すべての記録／再生装置で必要とされるが、拡張機能に関する部分は、その拡張機能に対応した機器にのみ必要なデータであり、拡張機能に対応しない機器にとっては無駄なデータであり、ハードウエア資源の浪費となってしまう。
【発明の開示】
本発明は、上述したような状況に鑑みてなされたものであり、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能とする記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体、並びに当該記録媒体を再生する再生装置及び再生方法を提供することを目的とする。
上記目的を達成するために本発明にかかる記録装置は、記録媒体に情報の記録を行う記録部と、前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、前記ディレクトリ及び前記ファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、前記ディレクトリ及び前記ファイルに対する拡張情報を管理する拡張情報処理部と、を備えた記録装置であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが、前記オブジェクト参照情報を経由して対応付けられていることを特徴とする。
また、本発明にかかる記録装置は、前記拡張オブジェクト管理情報に、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、前記ディレクトリ及び前記ファイルに対する操作を行う時、処理可能な種類の前記拡張情報については、前記拡張情報を更新し、処理不可能な種類の前記拡張情報については、前記拡張情報を更新せず、前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新することが好ましい。
また、本発明にかかる記録装置は、前記整合性状態管理情報が、前記メディアオブジェクト管理情報毎に設けられ、前記拡張情報の種別毎に、少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含むことが好ましい。
また、本発明にかかる記録装置は、前記コンテンツ管理情報に、第１の更新日時情報を含み、前記拡張情報には、第２の更新日時情報を含み、前記メディアオブジェクト管理情報を更新した時、前記第１の更新日時情報を更新し、処理可能な種類の前記拡張情報については、前記第２の更新日時情報に前記第１の更新日時情報と同じ値を設定し、処理不可能な種類の前記拡張情報については、前記第２の更新日時情報を更新しないことが好ましい。
また、本発明にかかる第１の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定することを特徴とする。
また、本発明にかかる第２の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定することを特徴とする。
かかる構成により、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能となる。
また、本発明の他の側面は、記録媒体への情報の記録方法である。この記録方法は、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを備えた記録方法であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記記録方法は、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体からの情報の再生方法である。第１の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする。第２の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を含む。
また、本発明のさらに他の側面は記録媒体である。この記録媒体は、情報が記録された記録媒体であって、前記情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とが記録されており、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
また、本発明のさらに他の側面は、記録媒体へ情報の記録を行う記録装置において、当該記録装置の記録動作を制御するプログラムである。このプログラムは、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを前記記録装置に実行させる命令を含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記プログラムは、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を前記記録装置に実行させる命令をさらに含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
また、本発明のさらに他の側面は、上述のプログラムを、コンピュータによる読み取りが可能な媒体に記録したプログラム提供媒体（プログラム製品）である。
また、本発明のさらに他の側面は、記録媒体に記録されたデータ構造である。このデータ構造は、記録媒体に記録されたコンテンツ情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とを含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
【図面の簡単な説明】  図１は、本発明の実施の形態１にかかる記録再生装置の外観と関連機器とのインタフェースの例示図である。
図２は、本発明の実施の形態１にかかる記録再生装置に組み込まれるドライブ装置１１０とその周辺の概略構成を示すブロック図である。
図３は、本発明の実施の形態１にかかる記録再生装置の構成の一例を示すブロック図である。
図４は、本発明の実施の形態１にかかる記録再生装置の構成の他の例を示すブロック図である。
図５は、本発明の実施の形態１にかかる記録再生装置の構成のさらに他の例を示すブロック図である。
図６は、本発明の実施の形態１にかかる記録再生装置の構成のさらに他の例を示すブロック図である。
図７（ａ）は、記録可能なディスクメディア１００の記録領域を表した図である。図７（ｂ）は、図７（ａ）において同心円状に示されるリードイン領域と、リードアウト領域と、データ領域を横方向に配置した説明図である。図７（ｃ）は、論理セクタにより構成されるディスクメディア１００の論理的なデータ空間を示す図である。
図８は、ディスクメディア１００に記録されるディレクトリとファイルの階層構造を示す図である。
図９（ａ）は、ＵＤＦ規格におけるディレクトリ階層を管理するためのデータ構造の例示図である。図９（ｂ）は、ＵＤＦ規格におけるディレクトリ階層を管理するためのデータ構造のパーティション空間内での配置の例示図である。
図１０（ａ）は、ＵＤＦ規格で定義されるファイルセットディスクリプタＦＳＤのデータ構造の例示図である。図１０（ｂ）は、ＵＤＦ規格で定義されるｌｏｎｇ＿ａｄのデータ構造の例示図である。図１０（ｃ）は、ＵＤＦ規格で定義されるＡＤＩｍｐＵｓｅのデータ構造の例示図である。
図１１（ａ）は、ＵＤＦ規格で定義される拡張ファイルエントリのデータ構造の例示図である。図１１（ｂ）は、ＵＤＦ規格で定義されるＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒのデータ構造の例示図である。図１１（ｃ）は、ＵＤＦ規格で定義されるファイル識別記述子ＦＩＤのデータ構造の例示図である。
図１２（ａ）は、ＵＤＦ規格で定義されるＩｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ  Ｅｘｔｅｎｄｅｄ  Ａｔｔｒｉｂｕｔｅのデータ構造を示す図である。図１２（ｂ）は、Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ２１００中に格納される拡張属性のデータ構造を示す図である。
図１３（ａ）は、ディスクメディア１００上のアドレス空間を示す図である。図１３（ｂ）は、トラックバッファに蓄積してあるデータをデコーダへ供給することでＡＶデータの連続再生が可能になる時の状態を示した図である。
図１４は、ディスクメディア１００上に記録されるデータの階層構造と、それらを処理するシステム制御部１０４及びその内部構造を示す図である。
図１５（ａ）は、本発明の実施の形態１にかかる記録再生装置におけるメディアオブジェクトマネージャ３２０のデータ構造の例示図である。図１５（ｂ）は、本発明の実施の形態１にかかる記録再生装置における拡張オブジェクト管理情報（ＥＯ＿ＩＮＦＯ）７２０のデータ構造の例示図である。図１５（ｃ）は、属性フラグ  ７２４に設定される値の例示図である。
図１６（ａ）は、本発明の実施の形態１にかかる記録再生装置におけるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）７００のデータ構造の例示図である。図１６（ｂ）は、ＭｏＴｙｐｅ７４１に設定される値の例示図である。図１６（ｃ）は、ＯＢＪ＿ＩＤ型のフィールドへ値を設定するときの変換規則の例示図である。
図１７（ａ）は、本発明の実施の形態１にかかる記録再生装置におけるプログラムマネージャ３３０のデータ構造の例示図である。図１７（ｂ）は、本発明の実施の形態１にかかる記録再生装置におけるプログラム情報（ＰＲＧ＿ＩＮＦＯ）８００のデータ構造の例示図である。
図１８は、ディレクトリ及びメディアオブジェクトとＭＯ＿ＩＮＦＯ７００との関係を示す図である。
図１９は、メディアオブジェクトマネージャ３２０に対するプログラムマネージャ３３０の関係を示す図である。
図２０は、本発明の実施の形態１におけるディレクトリ及びメディアオブジェクトとメディアオブジェクトマネージャ３２０と拡張オブジェクトの関係を示す図である。
図２１（ａ）は、拡張オブジェクト管理情報テーブル７１０に設定される値の一例である。図２１（ｂ）は、拡張オブジェクト管理情報テーブル７１０に設定される値の他の例である。
図２２は、本発明の実施の形態１にかかる記録再生装置における拡張情報の記録処理を示すフローチャートである。
図２３は、本発明の実施の形態１にかかる記録再生装置における拡張情報の管理処理を示すフローチャートである。
図２４は、本発明の実施の形態１にかかる記録再生装置における拡張情報の再生処理を示すフローチャートである。
図２５は、本発明の実施の形態２におけるディレクトリ及びメディアオブジェクトとメディアオブジェクトマネージャ３２０と拡張オブジェクトの関係を示す図である。
図２６（ａ）は、本発明の実施の形態２にかかる記録再生装置におけるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）２０００のデータ構造の例示図である。図２６（ｂ）は、本発明の実施の形態２にかかる記録再生装置における拡張オブジェクト管理情報（ＥＯ＿ＩＮＦＯ）２１００のデータ構造の例示図である。
図２７（ａ）は、本発明の実施の形態３にかかる記録再生装置におけるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）３０００のデータ構造の例示図である。図２７（ｂ）は、拡張データ属性フラグ３１００に設定される値の例示図である。
図２８は、本発明の実施の形態３にかかる記録再生装置における拡張データ属性フラグの管理処理を示すフローチャートである。
図２９は、拡張データ属性フラグ３１００に設定される値の例示図である。
図３０は、従来のディレクトリ及びメディアオブジェクトとプログラムファイル１０００２との関係を示す図である。
図３１は、従来のディレクトリ及びビットストリームファイルと情報ファイルとの関係を示す図である。
【発明を実施するための最良の形態】  以下、本発明の実施の形態にかかる記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体、並びに再生装置、再生方法について、図面を参照しながら説明する。
（実施の形態１）
図１は、本発明の実施の形態１にかかる記録再生装置の一例である、ＤＶＤレコーダの外観と、関連機器とのインタフェースを説明するための図である。図１に示すように、本発明にかかる記録再生装置の一実施形態としてのＤＶＤレコーダ１は、記録媒体であるディスクメディアとしてＤＶＤディスク２が装填され、ビデオ情報等の記録再生が行なわれる。ＤＶＤレコーダ１の操作は、一般的にはリモートコントローラ３や機器上のスイッチ（図示せず）によって行なわれる。
ＤＶＤレコーダ１に入力されるビデオ情報には、アナログ信号とデジタル信号の両者があり、アナログ信号としてはアナログ放送が、デジタル信号としてはデジタル放送がある。一般的に、アナログ放送は、テレビジョン装置４に内蔵されている受信機により受信、復調され、ＮＴＳＣ方式等のアナログビデオ信号としてＤＶＤレコーダ１に入力される。
また、デジタル放送は、受信機であるセットトップボックス（ＳＴＢ）５でデジタル信号に復調され、ＤＶＤレコーダ１に入力され記録される。
一方、ビデオ情報が記録されたＤＶＤディスク２は、ＤＶＤレコーダ１により再生され外部に出力される。出力される信号も入力される信号と同様に、アナログ信号とデジタル信号の両者があり、アナログ信号であれば直接テレビジョン装置４に入力され、デジタル信号であればＳＴＢ５を経由し、アナログ信号に変換された後にテレビジョン装置４に入力され、テレビジョン（ＴＶ）で映像として表示される。
さらに、本発明にかかる記録再生装置の他の実施形態として、ＤＶＤディスク２を利用する装置にＤＶＤビデオカメラ６がある。ＤＶＤビデオカメラ６は、ＤＶＤレコーダにレンズやＣＣＤからなるカメラ装置を組み合わせた装置であり、撮影した動画情報を符号化して記録する。
また、ＤＶＤディスク２は、ＤＶＤレコーダ１やＤＶＤビデオカメラ６以外に、ＰＣ７等でビデオ情報が記録再生される場合もある。ＰＣ７等でビデオ情報が記録されたＤＶＤディスク２であっても、ＤＶＤレコーダに装填されれば、ＤＶＤレコーダは当該ＤＶＤディスクを再生する。
なお、上述したアナログ放送やデジタル放送のビデオ情報には、通常、音声情報が付随している。付随している音声情報もビデオ情報と同様に、ＤＶＤレコーダで記録再生される。
また、ビデオ情報は、動画の他に、静止画の場合もある。例えば、ＤＶＤビデオカメラ６の写真機能で静止画が記録されたり、ＰＣ７上で他の記録装置（ハードディスク）等から静止画がＤＶＤディスク２へコピーされたりする場合が該当する。
なお、ＤＶＤレコーダとＳＴＢ５等の外部機器との間のデジタルインタフェースとしては様々なインタフェースが考えられる。例えば、ＩＥＥＥ１３９４、ＡＴＡＰＩ、ＳＣＳＩ、ＵＳＢ、等である。
また、上記では、ＤＶＤレコーダ１とテレビジョン（ＴＶ）４との間の信号として、ＮＴＳＣ方式のアナログ（コンポジット）ビデオ信号を用いる場合について例示したが、輝度信号と色差信号を個別に伝送するコンポーネント信号であってもよい。
さらには、ＡＶ機器とテレビジョンの間の映像伝送インタフェースとしては、アナログインタフェースをデジタルインタフェース、例えば、ＤＶＩに置きかえる研究開発が進められており、ＤＶＤレコーダとテレビジョンがデジタルインタフェースで接続されることも当然予想される。
このようなＤＶＤレコーダ１やＤＶＤビデオカメラ６等の記録再生装置において、記録媒体であるディスクメディア２は、複数の記録再生装置上で記録・再生される。この時の記録装置は同一の製造メーカの場合もあるし、異なる製造メーカによる記録装置の場合もあり得る。
様々な記録再生装置における記録・再生の互換性確保のため、記録媒体における記録フォーマットやファイルフォーマットの規格化・標準化が行われるのが一般的である。例えば、ＤＶＤ−Ｖｉｄｅｏ  Ｒｅｃｏｒｄｉｎｇ規格等、様々な統一規格が策定されている。
記録再生装置の製造メーカは、ユーザの利便性に配慮して、統一規格に準拠した記録再生装置の製品化を行う。
その一方で、各製造メーカは、他社製品との差別化を図るべく、独自の拡張機能を自社製品に盛り込んで記録再生装置を製品化する場合が多く見られる。この拡張機能とは、統一規格には含まれておらず、各製造メーカが、その内容を独自に設けるさまざまな機能である。拡張機能の実現のために、図１には示していない追加のハードウエアやソフトウエア、周辺機器が必要に応じて記録再生装置に設けられる場合がある。例えば、位置情報を取得するＧＰＳレシーバ、等である。
図２は、本実施の形態１にかかる記録再生装置に組み込まれるドライブ装置１１０とその周辺の概略構成を示すブロック図である。図２において、ドライブ装置１１０は、記録媒体に対して情報の記録再生を行う光ピックアップ１０１と、ＥＣＣ（Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｎｇ  Ｃｏｄｅ）処理部１０２を備え、例えばＤＶＤディスクのような記録媒体であるディスクメディア１００に対してデータの記録及び再生を行う。
ディスクメディア１００には、セクタと呼ばれる最小単位でデータが記録される。また、複数のセクタで一つのＥＣＣブロックを構成し、ＥＣＣブロックを１単位としてＥＣＣ処理部１０２でエラー訂正処理が施される。なお、ＥＣＣブロックはＥＣＣクラスタと呼ばれることもある。
ディスクメディア１００の一例であるＤＶＤ−ＲＡＭディスクの場合、セクタのサイズは２ＫＢであり、１６セクタを１ＥＣＣブロックとして構成されている。当該セクタサイズは、ディスクメディア１００の種類に応じて変動するものであり、１セクタは５１２Ｂ（バイト）であっても良いし、８ＫＢ等であっても良い。
また、ＥＣＣブロックについても、１セクタを１ＥＣＣブロックとして構成しても良いし、１６セクタを、あるいは３２セクタ等を１ＥＣＣブロックとして構成しても良い。今後、記録できる情報容量の増大に伴い、セクタサイズ及びＥＣＣブロックを構成するセクタ数は増大するものと予想される。
また、ドライブ装置１１０は、トラックバッファ１０３と接続されており、トラックバッファ１０３は、システムバス１０５を経由して記録再生装置のシステム全体を制御するシステム制御部１０４と接続されている。
トラックバッファ１０３は、ディスクメディア１００にＡＶデータをより効率良く記録するため、ＡＶデータを可変ビットレート（ＶＢＲ）で記録するためのバッファである。ディスクメディア１００への読み書きレート（Ｖａ）が固定レートであるのに対して、ＡＶデータはその内容（ビデオであれば画像）の持つ複雑さに応じてビットレート（Ｖｂ）が変化する。トラックバッファ１０３は、このビットレートの差を吸収するためのバッファである。
図３は、ドライブ装置１１０を含む、本実施の形態１にかかる記録再生装置のブロック構成図である。図３に示すように、本実施の形態１にかかる記録再生装置は、システム全体の管理及び制御を司るシステム制御部１０４、ユーザへの表示及びユーザからの要求を受け付けるユーザＩ／Ｆ（インタフェース）部２００、ＶＨＦ及びＵＨＦを受信するアナログ放送チューナ２１０、映像をＡＶ信号へ変換するカメラ部２１１、デジタル放送を受信するデジタル放送チューナ２１２、ＡＶ信号入力をデジタル信号に変換し、ＭＰＥＧプログラムストリーム等にエンコードする動画エンコーダ２２１、ＡＶ信号入力をＪＰＥＧストリーム等にエンコードする静止画エンコーダ２２２、デジタル放送で送られるＭＰＥＧトランスポートストリームを解析する解析部２２３、ＭＰＥＧ等の動画データをデコードする動画デコーダ２４０、静止画データをデコードする静止画デコーダ２４１、テレビ及びスピーカ等の表示部２５０、等を備えている。
動画エンコーダ２２１、静止画エンコーダ２２２や解析部２２３には、ＡＶデータの入力源として、アナログ放送チューナ２１０、カメラ部２１１、デジタル放送チューナ２１２等が接続されている。
なお、上述したエンコーダやチューナ、カメラ部については、全てを同時に備える必要はなく、記録再生装置の使用目的に応じて必要なものだけを備えれば良い。例えば、記録再生装置がＤＶＤ等の光ディスク用レコーダの場合であれば、図４に示すように、図３に示した構成のうち、カメラ部２１１を省いた構成としても良い。また、記録再生装置がビデオカメラの場合であれば、図５に示すように、図３に示した構成のうち、アナログ放送チューナ２１０およびデジタル放送チューナ２１２を省き、集音用のマイク部２６１をさらに備えた構成としても良い。また、記録再生装置がパーソナルコンピュータの場合であれば、図４と同様の構成としても良い。あるいは、図６に示すように、図３に示した構成のうち、アナログ放送チューナ２１０、カメラ部２１１、およびデジタル放送チューナ２１２を省いた構成としても良い。
さらに、図３に示す記録再生装置は、図２で示したように、書き込みデータを一時的に格納するトラックバッファ１０３と、ディスクメディア１００にデータを書き込むドライブ装置１１０とを備えている。
また、ＩＥＥＥ１３９４やＵＳＢ等の通信手段により外部機器にデータを出力するインタフェースであるデジタルＩ／Ｆ（インタフェース）部２３０を備えても良い。
なお、本実施の形態１にかかる記録再生装置の詳しい動作については後ほど説明を行う。
次に、図７は、本実施の形態１にかかる記録再生装置において記録可能なディスクメディア１００の外観と物理構造を表した図である。なお、例えばＤＶＤ−ＲＡＭのようなディスクメディアは、記録面を保護するのを目的として、カートリッジに収納された状態で記録再生装置に装填される。ただし、記録面の保護が別の構成で行なわれたり、容認できる場合にはカートリッジに収納せずに、記録再生装置に直接装填できるようにしてもよい。
図７（ａ）は、記録可能なディスクメディア１００の記録領域の一例を示した図である。図７（ａ）の例では、最内周にリードイン領域１４１が、最外周にリードアウト領域１４２が、その間にデータ領域１４３が配置されている。リードイン領域１４１は、光ピックアップ１０１がディスクメディア１００へアクセスする時に、サーボを安定させるために必要な基準信号や他のメディアとの識別信号等が記録されている。リードアウト領域１４２もリードイン領域１４１と同様の基準信号等が記録されている。またデータ領域１４３は、最小のアクセス単位であるセクタに分割されている。
図７（ｂ）は、図７（ａ）において同心円状に示されているリードイン領域１４１と、リードアウト領域１４２と、データ領域１４３を横方向に配置した説明図である。
リードイン領域１４１とリードアウト領域１４２は、その内部に欠陥管理領域（ＤＭＡ：Ｄｅｆｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ａｒｅａ）１４４，１４７を有する。欠陥管理領域とは、欠陥が生じたセクタの位置を示す位置情報と、その欠陥セクタを交替するセクタが後述する交替領域のいずれに存在するかを示す交替位置情報とが記録されている領域をいう。
また、データ領域１４３は、その内部に交替領域１４５とユーザ領域１４６を有している。交替領域１４５は、欠陥セクタが存在する場合に代替セクタとして使用される領域である。ユーザ領域１４６は、ファイルシステムが記録用領域として利用することができる領域をいう。なお、ディスクメディアの種類によっては交替領域を持たないディスクメディアも存在し、この場合、必要に応じて、後述するＵＤＦ等のファイルシステムにおいて、欠陥セクタの交替処理を行う場合もある。
データ領域１４３にある各セクタへアクセスするため、内周から順に物理セクタ番号（ＰＳＮ：Ｐｈｙｓｉｃａｌ  Ｓｅｃｔｏｒ  Ｎｕｍｂｅｒ）をデータ領域へ割り当てることが一般に行われている。ＰＳＮによって管理されるセクタを物理セクタと呼ぶ。
また、データ記録に使用されるセクタのみを連続的に示すように、内周から順に論理セクタ番号ＬＳＮ（Ｌｏｇｉｃａｌ  Ｓｅｃｔｏｒ  Ｎｕｍｂｅｒ）をユーザ領域の物理セクタに割り当てることも行われる。ＬＳＮによって管理されるセクタを論理セクタと呼ぶ。
図７（ｃ）は、図７（ｂ）のユーザ領域１４６内で、論理セクタにより構成される論理的なデータ空間を示す図である。論理的なデータ空間は、ボリューム空間と呼称され、ユーザデータを記録する。ボリューム空間においては、記録データをファイルシステムで管理する。
ＤＶＤ−ＲＡＭ等のディスクメディアでは、ファイルシステムは、ＵＤＦと呼称され、ＥＣＭＡ１６７及びＩＳＯ１３３４６規格に準拠したものが一般的に使用される。
ＵＤＦのパーティション空間２９２では、データアクセスの単位ごとに論理ブロック番号ＬＢＮ（Ｌｏｇｉｃａｌ  Ｂｌｏｃｋ  Ｎｕｍｂｅｒ）が割り当てられ、データの配置や管理が行われる。
データの配置のために、パーティション空間２９２で連続的に配置される１群のセクタはエクステントと呼ばれる単位で管理され、さらに関連のあるエクステントの集合がファイルとして管理される。
エクステント及びエクステントの集合であるファイルを管理する情報制御ブロック（ＩＣＢ）であるファイルエントリ（ＦＥ）及び拡張ファイルエントリ（ＥＦＥ）と呼ばれる構造、さらには１群のファイルをディレクトリとして管理するための情報であるファイル識別記述子（ＦＩＤ）等がボリューム空間内のパーティション空間内に記録される。
そして、パーティション空間等を管理するためのボリューム構造情報２９０（及びそのバックアップである２９１）が、ボリューム領域の先頭と終端に記録される。
図８は、本発明の実施の形態１にかかる記録再生装置により記録されるディスクメディア１００におけるディレクトリとファイルの階層構造の一例を示す図である。図８に示すように、ＲＯＯＴディレクトリ３００の下に、階層化されたサブディレクトリ（３０１〜３０５等）があり、さらにその階層下に、動画データや静止画データを含むファイルである各種メディアオブジェクト（３１０〜３１３等）や、各メディアオブジェクトを管理するためのファイルであるメディアオブジェクトマネージャ３２０（ファイル名：ＭＯＩ＿ＭＧＲ）や、複数のメディアオブジェクトをグループ化し、再生順序や分類情報を管理するプログラムマネージャ３３０（ファイル名：ＰＲＧＭ０００１．ＥＸＴ）等が格納されている。
ここでプログラムマネージャ３３０は拡張情報を格納する拡張オブジェクトの一種であり、プログラム再生機能に対応した記録再生装置がその記録及び再生等の処理を行う。
なお、本実施の形態においてはメディアオブジェクトマネージャ３２０の構造や機能は統一規格の一種であるとし、全ての本発明の記録再生装置において記録や再生が保証されるものとする。
また、拡張情報とは、統一規格に含まれない拡張機能を製造メーカが独自に実現する上で必要な様々な情報のことである。拡張情報は拡張オブジェクトと呼ばれるファイルに格納されてディスクメディア１００に記録される。上述の、プログラム再生機能は拡張機能の一例である。
本実施の形態１においては、記録及び再生用の対象となるＡＶデータを含む各種メディアオブジェクトのディレクトリ階層やファイル名は、後述するＤＣＦ規格及びそれに類した形式を利用して以降の説明を行う。ただし、ディレクトリ階層やファイル名の命名則はこれに限られるものではなく、他の命名則を用いても良い。
メディアオブジェクトのうち、ＭＰＥＧ２等の動画データを含む動画オブジェクトは、ＡＢＣＤｎｎｎｎ．ＭＰＧというように、最初の４文字が任意のアルファベット文字の組み合わせであり、次のｎｎｎｎが１０進数であるような命名側に従って動画ファイルとして記録される。動画ファイルは、ＭＰＥＧ２方式やＭＰＥＧ４方式等で圧縮されたＡＶデータを含んでおり、プログラムストリーム（ＰＳ）や、トランスポートストリーム（ＴＳ）、あるいは他の形式のファイルとして記録される。
また、各々の動画ファイルに関する属性情報は、属性情報ファイル（ファイル名：ＡＢＣＤｎｎｎｎ．ＭＯＩ）に記録される。属性情報ファイルには、それぞれの動画ファイルの識別情報、記録された日時、動画データの代表画像（サムネイルピクチャ）、動画データの再生時刻をディスクメディア１００上の論理アドレスに変換するためのアクセスマップ情報及びその管理情報、等を有している。アクセスマップ情報を持つことにより、動画データの持つ時間軸とデータ（ビット列）軸との間の変換を行うことが可能となり、動画データに対する時間軸を基準にしたランダムアクセスが可能となる。
属性情報ファイルは、例えばＡｐｐｌｅ社のＱｕｉｃｋＴｉｍｅファイルフォーマットに準拠する形式でもよい。ＱｕｉｃｋＴｉｍｅファイルフォーマットでは、前記属性情報は、ムービーリソース（ｍｏｖｉｅｒｅｓｏｕｒｃｅ）と呼ばれる。また同様に、前記アクセスマップ情報は、サンプルテーブル（Ｓａｍｐｌｅ  Ｔａｂｌｅ）と呼ばれる。
一つの動画オブジェクトは、一つの属性情報ファイルと一つ又はそれ以上の動画ファイルとで構成され、それらはファイル名により関連づけられるものとする。すなわち、関連のある属性情報ファイルと動画ファイルは、そのファイル名において拡張子を除く部分、例えば動画オブジェクト３１０では、動画ファイル３１１と属性情報ファイル３１２が”ＡＢＣＤ０００１”の部分が同一に設定されることによって、その関連付けがなされていることとする。
ただし、属性情報ファイルと動画ファイルの関連付けは上述の方法に限定されるものではなく、属性情報ファイル内に関連付けられた動画ファイルへのリンク情報、例えば動画ファイルへのパス名等を保持したり、両者の対応付けをテーブル情報として保持したりする等、他の方法であっても良い。なお、一つの動画オブジェクトに、一つの属性情報ファイルと一つ又はそれ以上の動画ファイル以外を含むようにしてもよい。また、属性情報ファイルと動画ファイルを一体として、１つのファイルで動画オブジェクトを構成するようにしてもよい。
メディアオブジェクトのうち、ＪＰＥＧ等の静止画データを含む静止画オブジェクトは、各々の静止画情報が静止画ファイル（ファイル名：ＡＢＣＤｎｎｎｎ．ＪＰＧ）等として記録される。静止画ファイルは、ＪＰＥＧ方式等で圧縮された映像データであり、例えば、ＤＣＦフォーマットやＥｘｉｆフォーマットによりファイルとして記録される。
上記のメディアオブジェクトは、ＤＣＦ規格あるいはそれに類するディレクトリ構造にしたがって記録される。すなわち、ＲＯＯＴディレクトリ３００の下にＤＣＦイメージルートディレクトリ３０２（ディレクトリ名：ＤＣＩＭ）があり、さらにその下に静止画ファイルを格納するためのＤＣＦディレクトリ３０５がある。（ディレクトリ名：３００ＡＢＣＤＥ）。そして、ＤＣＦディレクトリ３０５の下に静止画オブジェクトの一種であるＤＣＦ基本ファイル３１３（例えば、ファイル名：ＡＢＣＤ０００１．ＪＰＧ）が格納される。
また、ＲＯＯＴディレクトリ３００の下にＶＩＤＥＯイメージルートディレクトリ３０１（ディレクトリ名：ＶＩＤＥＯ）があり、さらにその下に、主に動画オブジェクトを格納するためのＶＩＤＥＯディレクトリ３０４がある。（例えば、ディレクトリ名：１００ＡＢＣＤＥ）。そして、ＶＩＤＥＯディレクトリ３０４下に、動画オブジェクト３１０を構成する属性情報ファイル３１２（拡張子がＭＯＩであるファイル）と動画ファイル３１１（拡張子がＭＰＧであるファイル）が格納される。
なお、メディアオブジェクトとして、ＡＣ−３やＡＡＣ等による圧縮音声ファイルや非圧縮の音声ファイル、ＭｏｔｉｏｎＪＰＥＧファイル、ＤＣＦ規格で定められたＤＣＦ拡張画像ファイル、ＤＣＦサムネイルファイル、ＰＮＧファイル等、他のファイルフォーマットのＡＶファイルを記録してもよい。
記録されたメディアオブジェクトを管理するコンテンツ管理情報は、管理データディレクトリ３０３（ディレクトリ名：ＩＮＦＯ）下のメディアオブジェクトマネージャファイル３２０として記録される。
また、メディアオブジェクトに対して拡張情報を付加する拡張オブジェクトも管理データディレクトリ３０３に記録される。図８では、拡張オブジェクトの例として、プログラムマネージャファイル３３０が記録されている。なお、メディアオブジェクトマネージャファイル３２０及び拡張オブジェクトの記録位置は管理データディレクトリ３０３下に限られるものではなく、例えば、ＶＩＤＥＯイメージルートディレクトリ３０１下、等でもよい。メディアオブジェクトマネージャファイル３２０及びプログラムマネージャファイル３３０の構造については後述する。
次に、図９、図１０及び図１１を用いて、本実施の形態１にかかる記録再生装置で用いられるディスクメディア上でデータをファイルとして管理する、ＵＤＦファイルシステムの構造を説明する。
図９は、ＵＤＦファイルシステムにおけるディレクトリ階層を管理するためのデータ構造を示す図である。なお、図９は、図８に示したディレクトリ階層構造に対応しているが、そのうちＲＯＯＴディレクトリ３００から属性情報ファイル３１２へ至るまでのファイルシステム情報のみを示しており、他のディレクトリやファイルに対する同様の情報については、説明を簡単にするため省略している。
ディレクトリ階層構造の起点はファイルセットディスクリプタ（ＦＳＤ：Ｆｉｌｅ  Ｓｅｔ  Ｄｅｓｃｒｉｐｔｏｒ）４００である。ＦＳＤ４００は、図１０（ａ）に示されるデータ構造を有している。ＦＳＤ４００は、拡張ファイルエントリ（ＥＦＥ：Ｅｘｔｅｎｄｅｄ  Ｆｉｌｅ  Ｅｎｔｒｙ）５１０への参照情報４０１（ディスクメディア１００上での記録位置）をＲｏｏｔ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５０１の値として保持している。また、ＦＳＤ４００は、Ｓｙｓｔｅｍ  Ｓｔｒｅａｍ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５０２からＮａｍｅｄ  Ｓｔｒｅａｍと呼ばれるデータを参照可能である。
Ｒｏｏｔ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５０１及びＳｙｓｔｅｍ  Ｓｔｒｅａｍ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５０２は、図１０（ｂ）に示すｌｏｎｇ＿ａｄ５０３という構造を持つ。ｌｏｎｇ＿ａｄ５０３は、参照先のエクステントの長さ（Ｅｘｔｅｎｔ  Ｌｅｎｇｔｈ）と、位置（Ｅｘｔｅｎｔ  Ｌｏｃａｔｉｏｎ）を保持する。さらに、Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ５０４には、図１０（ｃ）に示すＡＤＩｍｐＵｓｅの形式によりＵＤＦ  ＵｎｉｑｕｅＩＤ５０５と呼ばれる値が保持される。
また、ＥＦＥ５１０は、図１１（ａ）に示される構造を有している。ＥＦＥ５１０は、ディスクメディア１００上に記録された各ディレクトリやファイルを構成するエクステントの集合を管理するための構造体であり、各エクステントのディスクメディア１００上での記録位置とデータ長を管理するため、図１１（ｂ）に示す構造を有するアロケーション記述子（ＡＤ：Ａｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒ）５１４と呼ばれる構造を含んでいる。各ディレクトリやファイルは複数のエクステントから構成されるので、ＥＦＥ５１０には複数のＡＤ５１４が含まれる。
その他にも、ＥＦＥ５１０には、図１１（ａ）に示すように、データの種別を表すディスクリプタタグ（Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｇ）や、各ディレクトリやファイルごとに、ディスクメディア１００上で重複しない一意のＩＤ値を設定するＵｎｉｑｕｅ  ＩＤ５１１、ＥＦＥ５１０ごとの拡張属性を設定可能なＳｔｒｅａｍ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５１２や、拡張属性（ＥＡｓ；  Ｅｘｔｅｎｄｅｄ  Ａｔｔｒｉｂｕｔｅｓ）５１３等が含まれる。
ＥＡｓ５１３は、ＵＤＦファイルシステムで規定される拡張属性を格納するための領域であり、ＥＣＭＡ１６７規格等で定められた拡張属性データや、様々なアプリケーションシステム等が必要に応じて使用できる。ＥＡｓ５１３中には、属性タイプ（Ａｔｔｒｉｂｕｔｅ  Ｔｙｐｅ）や属性サブタイプ（Ａｔｔｒｉｂｕｔｅ  Ｓｕｂｔｙｐｅ）と呼ばれるフィールドが存在し、ここに適切な値を設定することにより、この拡張属性中に含まれるデータの種別を識別できるようになっている。特定の属性タイプや属性サブタイプの値とそれに対応するデータ構造がＥＣＭＡ１６７規格等ですでに定義されている。
図１２（ａ）に、ＥＡｓ５１３に含まれる拡張属性データの一種で、任意のアプリケーションシステムが使用可能な処理システム用拡張属性（Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ  Ｅｘｔｅｎｄｅｄ  Ａｔｔｒｉｂｕｔｅ）５３０と呼ばれる構造を示す。
アプリケーションシステムがこの処理システム用拡張属性５３０を使用する時には、Ａｔｔｒｉｂｕｔｅ  Ｔｙｐｅ、Ａｔｔｒｉｂｕｔｅ  Ｓｕｂｔｙｐｅ及びＩｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒの各フィールドに適切な値を設定することにより、処理システム用拡張属性５３０中に含まれる拡張属性が、どんなアプリケーションシステムにより使用されるかを識別できるようになっている。
そして、実際の拡張属性の値は、Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ  Ｌｅｎｇｔｈ（ＩＵ＿Ｌ）でデータ長が示される可変長のフィールドＩｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ５３１中に格納される。Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ５３１中に格納される拡張属性のデータ構造は、それを使用するアプリケーションごとに決められる。
本実施の形態においてＩｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ５３１中に格納される拡張属性のデータの一例として、Ｍｅｄｉａ  Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ５４０の構造を、図１２（ｂ）に示す。ここでは、Ｍｏ（Ｍｅｄｉａ  Ｏｂｊｅｃｔ）Ｕｎｉｑｕｅ  ＩＤ５４１というフィールドが設けられている。本フィールドの利用例については後述する。
ＲＯＯＴディレクトリ３００等のディレクトリデータを含むエクステント４２０（図９（ａ）参照）は、各ディレクトリやファイルのファイル名を保持するファイル識別記述子ＦＩＤ（Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒ）５２０で構成される。あるディレクトリ下にサブディレクトリやファイルが存在する場合、それぞれのディレクトリ又はファイルに対してＦＩＤ５２０が保持される。
例えば、図８によれば、ＲＯＯＴディレクトリ３００の下にはＶＩＤＥＯイメージルートディレクトリ３０１とＤＣＩＭイメージルートディレクトリ３０２があるので、図９（ａ）に示すように、ＲＯＯＴディレクトリ３００のエクステント４２０には、各々に対応するＦＩＤ４２１及び４２２が保持されている。
ＦＩＤ５２０は、図１１（ｃ）に示される構造を持つ。ＦＩＤ５２０は、ＵＤＦ上で管理される各ディレクトリやファイルの名前（ファイル識別子）をファイル識別子（Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ）５２１として保持する。ＦＩＤ５２０はさらに、対応するディレクトリ又はファイルの実データを管理するＥＦＥ５１０への参照情報（例えば図９（ａ）の４３０）を、ＩＣＢ５２２として保持する。
そのほかにも、ＦＩＤ５２０には、データの種別を表すディスクリプタタグ（Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｇ）や、ファイル識別子５２１のデータ長を表すファイル識別子長さ（Ｌｅｎｇｔｈ  ｏｆ  Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ）等が含まれる。
以降、同様にＥＦＥ５１０とＦＩＤ５２０の参照関係を保持することによりディレクトリの階層構造が管理され、この参照関係を順次たどることによって、任意のディレクトリやファイルの実データであるエクステントへアクセスすることが可能となる。
ファイルに関しても、ＥＦＥ５１０によりエクステントの集合が管理される。図９の場合、エクステントの集合４４２がファイルを構成し、これは図８における属性情報ファイル３１２に相当する。
上記のＦＳＤ４００やＥＦＥ５１０、ＦＩＤ５２０は、パーティション空間２９２内に配置される。図９（ｂ）は、図９（ａ）のデータ構造のパーティション空間内での配置の例示図である。ここで、図９（ａ）と図９（ｂ）で同じデータに関しては同じ番号を付与している。
エクステント４４２へアクセスするためには、ＦＳＤ４００から順にＥＦＥ５１０、ＦＩＤ５２０、・・・、ＥＦＥ４４０のように、順次、データへアクセスする。
上述のような階層構造を持ったファイルシステムにおいて、特定のディレクトリやファイルを参照するために、パス名が利用できる。パス名は、例えば、図９のエクステント４４２（ファイル名：ＡＢＣＤ０００１．ＭＯＩ）に対しては、”／ＶＩＤＥＯ／１００ＡＢＣＤＥ／ＡＢＣＤ０００１．ＭＯＩ”のように表される。ここでは、ＲＯＯＴディレクトリ３００及びパス区切り文字を”／”で表している。
このように、パス名は、ＲＯＯＴディレクトリ３００から、対象のディレクトリやファイルにたどり着くまでディレクトリ階層をたどっていく時、その経路上に存在するディレクトリの名前（ファイル識別子５２１に格納されている情報）を、パス区切り文字で区切りながら一続きに記述したものである。このパス名を利用すれば、ファイルシステム上で管理される任意のディレクトリやファイルを参照することが可能となる。
次に、ディスクメディア１００へ記録を行なう、本実施の形態にかかる記録再生装置の動作について説明する。
まず、図１３を用いて、ディスクメディア１００上でのＡＶデータの分散配置について説明する。すなわち、図２に示すようなシステムにおいて、トラックバッファ１０３を有効利用することによって、ＡＶデータを離散配置することが可能になる。
図１３（ａ）は、ディスクメディア１００上のアドレス空間を示す図である。図１３（ａ）においては、左端がアドレス値が０の点であり、右に向かってアドレス値が増加していくものとしている。また、’０’、ａ１〜ａ４は、その位置におけるアドレス値を示している。
図１３（ａ）に示されるように、ＡＶデータが［ａ１、ａ２］の連続領域Ａ１と［ａ３、ａ４］の連続領域Ａ２に分かれて記録されている場合、光ピックアップ１０１がａ２からａ３へシーク動作を行なっている間、トラックバッファ１０３に蓄積してあるデータを動画デコーダ２４０へ供給することでＡＶデータの連続再生が可能になる。
この時のトラックバッファ１０３内のデータ蓄積量の状態を示したのが、図１３（ｂ）である。位置ａ１で読み出しが開始されたＡＶデータは、時刻ｔ１からトラックバッファ１０３に入力されると共に、トラックバッファ１０３からデータの出力が開始される。これにより、トラックバッファ１０３への入力レート（Ｖａ）とトラックバッファ１０３からの出力レート（Ｖｂ）のレート差（Ｖａ−Ｖｂ）の分だけトラックバッファ１０３にデータが蓄積されていく。この状態が、光ピックアップ１０１がａ２に達するまで、すなわち時刻ｔ２に達するまで継続する。
この間にトラックバッファ１０３に蓄積されたデータ量をＢ（ｔ２）とすると、時間ｔ２から、位置ａ３のデータの読み出しを開始する時刻ｔ３までの間、トラックバッファ１０３に蓄積されているデータ量Ｂ（ｔ２）を消費して動画デコーダ２４０へ供給し続けられれば良い。
換言すると、シーク前に読み出すデータ量（［ａ１、ａ２］）が一定量以上確保されていれば、シークが発生した場合であっても、ＡＶデータの連続供給が可能となる。
ＡＶデータの連続供給が可能な連続領域のサイズは、ＥＣＣブロック数Ｎ＿ｅｃｃに換算すると、（数１）のように求められる。（数１）において、Ｎ＿ｓｅｃはＥＣＣブロックを構成するセクタ数であり、Ｓ＿ｓｉｚｅはセクタサイズ、Ｔｊはシーク性能（最大シーク時間）である。
2004095285.tif 000003
また、連続領域の中には欠陥セクタが生じる場合がある。この場合を考慮すると、ＡＶデータの連続供給が可能な連続領域のサイズは（数２）のように求められる。（数２）において、ｄＮ＿ｅｃｃは容認する欠陥セクタのサイズであり、Ｔｓは連続領域の中で欠陥セクタをスキップするのに要する時間である。
2004095285.tif 000004
なお、本実施の形態１においては、ディスクメディア１００からデータを読み出す場合、すなわち再生の場合について説明しているが、ディスクメディア１００へデータを書き込む場合、すなわち記録又は録画の場合も同様に考えることができる。
上述したように、ディスクメディア１００では、一定量以上のデータが連続記録されていれば、ディスク上にＡＶデータを分散記録しても連続再生が可能である。なお、例えばＤＶＤでは、この連続領域をＣＤＡと呼称する。あるいは、ＡＶデータを記録する特別なエクステントであることから、ＡＶエクステントと呼ばれることもある。
次に、図３を用いて、本実施の形態１にかかる記録再生装置の動作について説明する。図３に示した記録再生装置においては、例えばユーザＩ／Ｆ部２００がユーザからの要求を受け付けた場合に動作を開始する。
ユーザＩ／Ｆ部２００は、ユーザからの要求をシステム制御部１０４に伝え、システム制御部１０４は、ユーザからの要求を解釈すると共に各モジュールへの処理要求を行なう。
以下、アナログ放送をＭＰＥＧ−２  ＰＳにエンコードして動画オブジェクトとして記録する動作を例に挙げて説明する。
システム制御部１０４は、アナログ放送チューナ２１０への受信と動画エンコーダ２２１へのエンコードを要求する。動画エンコーダ２２１は、アナログ放送チューナ２１０から送られてくるＡＶ信号を、ビデオエンコード、オーディオエンコード及びシステムエンコードしてトラックバッファ１０３に送出する。動画エンコーダ２２１は、エンコード開始後、アクセスマップ情報等を作成するために必要な情報をエンコード処理と平行してシステム制御部１０４に送る。
次に、システム制御部１０４は、ドライブ装置１１０に対して記録要求を出し、ドライブ装置１１０は、トラックバッファ１０３に蓄積されているデータを取り出してディスクメディア１００に記録する。この際、前述した連続領域であるＣＤＡをディスク上の記録可能領域から検索し、見つかったＣＤＡにデータを記録していく。
この時、ＣＤＡとして記録可能な領域の検索は、ＵＤＦ等のファイルシステムが管理する空き領域情報、例えば、スペースビットマップディスクリプタ（Ｓｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒ）に基づいて実行される。
録画終了は、ユーザからのストップ要求によって指示される。ユーザからの録画停止要求は、ユーザＩ／Ｆ部２００を通してシステム制御部１０４に伝えられ、システム制御部１０４は、アナログ放送チューナ２１０と動画エンコーダ２２１に対して停止要求を出す。動画エンコーダ２２１は、システム制御部１０４からのエンコード停止要求を受けてエンコード処理を終了する。
システム制御部１０４は、エンコード処理終了後、動画エンコーダ２２１から受け取った情報に基づいて、アクセスマップ情報とその管理情報、等を含む属性情報を生成する。
次に、システム制御部１０４は、ドライブ装置１１０に対してトラックバッファ１０３に蓄積されているデータの記録終了と属性情報の記録を要求し、ドライブ装置１１０が、トラックバッファ１０３の残りデータと、属性情報を属性情報ファイル、例えば、図９に示す動画オブジェクトを構成しているファイルであるＡＢＣＤ０００１．ＭＯＩとしてディスクメディア１００に記録し、動画オブジェクトの録画処理を終了する。
なお、上記のほかに、システム制御部１０４は、図１０や図１１、図１２で説明したようなＵＤＦファイルシステムの情報を必要に応じて生成したり更新したりする。すなわち、動画オブジェクトを構成するファイルに対して、ＥＦＥ５１０やＦＩＤ５２０を生成し、必要な情報を設定した上でディスクメディア１００上に記録する。
記録再生装置がビデオカメラである場合は、図５を参照して説明したように、ＡＶ信号源がアナログ放送チューナ２１０ではなくカメラ部２１１へ変わるだけで、他の処理は同様である。
また、デジタル放送を動画オブジェクトとして記録する動作には、動画データのエンコードは行わず、デジタル放送チューナ２１２及び解析部２２３を通じてＭＰＥＧ２  ＴＳのデータをディスクメディア１００へ動画オブジェクトとして記録するようシステム制御部１０４が制御を行う。このとき、上述と同様に、ファイルシステム情報の記録も行われる。
次に、静止画オブジェクトの記録に関して、カメラ部２１１から送られてくるＡＶ信号をＪＰＥＧエンコードして記録する動作について説明する。
システム制御部１０４は、カメラ部２１１へＡＶ信号の出力を、静止画エンコーダ２２２へＡＶ信号のエンコード実施を要求する。静止画エンコーダ２２２は、カメラ部２１１から送られるＡＶ信号をＪＰＥＧエンコードし、トラックバッファ１０３に送出する。
ドライブ装置１１０は、システム制御部１０４からの指示を受けながら、トラックバッファ１０３に蓄積されているデータをディスクメディア１００に記録する。この時、データの記録可能領域の検索は、ＵＤＦ等のファイルシステムが管理する空き領域情報をもとに実行される。
一つの静止画オブジェクトが記録されたら撮影は終了する。あるいは、ユーザから連続撮影の指示があった場合は、ユーザからの撮影停止要求によって終了するか、所定の枚数の静止画オブジェクトを記録して終了する。ユーザからの撮影停止要求は、ユーザＩ／Ｆ部２００を通してシステム制御部１０４に伝えられ、システム制御部１０４はカメラ部２１１と静止画エンコーダ２２２に対して停止要求を出す。
さらに、システム制御部１０４は、ＵＤＦファイルシステムの情報についても必要な処理を行う。すなわち、静止画オブジェクトを構成するファイルに対して、ＥＦＥ５１０やＦＩＤ５２０等を生成し、必要な情報を設定した上でディスクメディア１００上に記録する。
以上のような手順でディスクメディア１００に記録される各メディアオブジェクトは、後々の管理のために、図８で示したメディアオブジェクトマネージ３２０に登録される。各メディアオブジェクトとメディアオブジェクトマネージ３２０との関係については後述する。なお、本発明においてはＥＦＥ５１０を用いて説明を行っているが、その代わりにＦＥを用いてもかまわない。
図１４は、本実施の形態１における記録再生装置で用いられるディスクメディア１００上に記録されるデータの階層構造と、それらを処理するシステム制御部１０４及びその内部構造の一例を示す図である。
ディスクメディア１００上にはファイルシステム情報６００が記録される。ファイルシステム情報６００には、図７（ｃ）で示したボリューム構造情報２９０や、図１０、図１１及び図１２で示したＦＳＤ４００、ＥＦＥ５１０、ＦＩＤ５２０、また上述したスペースビットマップディスクリプタ（Ｓｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒ）等が含まれる。
また、複数のメディアオブジェクトをまとめて管理するためのメディアオブジェクトマネージャ３２０が同様にファイルとして管理され、コンテンツ管理情報６０１を構成する。
さらに、メディアオブジェクトに拡張情報６０２を付与する拡張オブジェクト６０３もファイルとして管理される。プログラムマネージャ３３０も拡張オブジェクトの一例であり、複数のメディアオブジェクトの内容や記録日時等に応じて整理分類したり、ユーザが自由な再生順序を設定するプログラム再生を行ったりするための拡張情報を格納するために設けられている。
これらのディスクメディア１００に記録されるデータは、システムバス１０５を通じて、システム制御部１０４により操作される。
一方、システム制御部１０４は、より詳細には、オペレーティングシステム（ＯＳ）とアプリケーションシステムとからなる。
オペレーティングシステムには、ファイルシステム情報６００を制御するファイルシステム処理部６１０や、特に図示されていないハードウエアの制御を行うデバイスドライバ部、メモリ制御部、等が含まれ、アプリケーションシステムに対して、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を通じてさまざまな共通機能を提供する。これにより、アプリケーションシステムをハードウエアやファイルシステムの詳細とは分離した形で実現することが可能となる。
一方、アプリケーションシステムでは、特定のアプリケーションのための制御動作を行う。本実施の形態１においては、例えば図３を用いて説明したように、動画オブジェクトや静止画オブジェクトの記録あるいは再生処理に関する制御を行う。
また、アプリケーションシステム中のコンテンツ管理情報処理部６１１は、コンテンツ管理情報６０１及びそこに含まれるメディアオブジェクトマネージャ３２０に対する操作を行う。
そして、拡張情報処理部６１２は、拡張情報６０２及びそこに含まれる拡張オブジェクト６０３に対する操作を行う。拡張オブジェクト６０３に対する操作については、後でさらに説明する。
また、アプリケーションシステムには、その他にも必要に応じて、ＡＶデータの表示や、ユーザインタフェースを処理する部分等を含む場合もある。
メディアオブジェクトマネージャ３２０のデータ構造については、図１５〜図１６を用いて以下に説明する。
図１５（ａ）は、メディアオブジェクトマネージャ３２０のデータ構造の例示図である。図１５（ａ）に示すようにメディアオブジェクトマネージャ３２０は、ヘッダ部７００とデータ部７０１とから構成される。
ヘッダ部７００には、ファイルのタイプを表すＤａｔａＴｙｐｅ、ファイルのサイズを表すＤａｔａＳｉｚｅ、メディアオブジェクトマネージャ３２０の更新日時であるＭｏｄＴｉｍｅ７０２、等が含まれる。また、拡張情報６０２を管理するための拡張オブジェクト管理情報テーブル７１０が含まれる。なお、ＬａｓｔＭｏＵｎｉｑｕｅＩＤ７０３については後述する。
データ部７０１は、メディアオブジェクト管理情報テーブル７３０を含む。メディアオブジェクト管理情報テーブル７３０は、メディアオブジェクトマネージャ３２０中に含まれるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）７００の数を示すＮｕｍＭｏＩｎｆｏと、ＮｕｍＭｏＩｎｆｏ個のＭＯ＿ＩＮＦＯ７００から構成される。
なお、図１５等におけるフィールド名欄の表記は、データ型とフィールド名を続けて記述しており、データ型については、例えば以下のような意味を示している。
ｃｏｎｓｔは、フィールドが定数であることを意味しており、ｃｏｎｓｔがない場合は変数であることを示している。ｕｎｓｉｇｎｅｄは、当該フィールドは符号無しの値であることを示しており、ｕｎｓｉｇｎｅｄがない場合は符号付きの値であることを示している。また、ｉｎｔ（）は、フィールドはカッコ内のビット長を持つ整数値であることを示している。例えば、カッコ内の値が’１６’である場合には、１６ビット長であることを意味する。また、ｓｔｒｉｎｇは文字列情報であることを意味する。
図１５（ｂ）は、メディアオブジェクトマネージャ３２０に含まれる拡張オブジェクト管理情報（ＥＯ＿ＩＮＦＯ）７２０のデータ構造である。ＥＯ＿ＩＮＦＯ７２０は、プログラムマネージャ３３０のような拡張オブジェクトを登録・管理するデータ構造であり、各拡張オブジェクトをそれぞれ識別するための型情報を示すＥｏＴｙｐｅ７２１及びＥｏＳｕｂＴｙｐｅ７２２を持つ。
ＥｏＴｙｐｅ７２１及びＥｏＳｕｂＴｙｐｅ７２２には、例えば、拡張オブジェクトの所有者（オーナー）情報やその使用目的を示す情報を数値やアルファベット値として格納しても良い。
さらにＥＯ＿ＩＮＦＯ７２０は、拡張オブジェクトへの参照情報をパス名により保持する拡張オブジェクト参照情報ＥｏＲｅｆ７２３、図１５（ｃ）で示される属性フラグであるＥｏＦｌａｇｓ７２４、拡張オブジェクトの概要を示す文字列情報を格納するＴｅｘｔＤｅｓｃ７２６、等から構成される。
図１５（ｃ）は、ＥＯ＿ＩＮＦＯ７２０が指し示す拡張オブジェクトに関する様々な情報をフラグとして格納するＥｏＦｌａｇｓ７２４の構造例である。本実施の形態においては、０ビット目をＶａｌｉｄフィールドとしている。
Ｖａｌｉｄフィールドの値が１ｂの場合、メディアオブジェクトマネージャ３２０及びそれが管理するメディアオブジェクトと、ＥＯ＿ＩＮＦＯ７２０が指し示す拡張オブジェクトとの整合性が維持されており、該拡張オブジェクトに含まれる情報が有効であることが保障されている状態を示す。一方、Ｖａｌｉｄフィールドの値が０ｂの場合は、その保障がないことを示す。
図１６（ａ）は、メディアオブジェクトマネージャ３２０に含まれるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）７４０のデータ構造である。
ＭＯ＿ＩＮＦＯ７４０は、登録されるメディアオブジェクトの型情報を示すＭｏＴｙｐｅ７４１、メディアオブジェクトへの参照情報であるオブジェクト参照情報ＭｏＲｅｆ７４２、少なくともメディアオブジェクトマネージャ３２０内で重複しない値であるメディアユニークＩＤが設定されるＭｏＵｎｉｑｕｅＩＤ７４３、等から構成される。
重複しないメディアユニークＩＤの設定方法は、例えば、初期値を０とし、メディアオブジェクトを新たに記録するたびにメディアユニークＩＤの値を１ずつ加算しながら割り当てていく。そして、ある時点でのメディアユニークＩＤの最大値をＬａｓｔＭｏＵｎｉｑｕｅＩＤ７０３に記録しておくことにより、記録を一旦中断した時にも次に割り当てるメディアユニークＩＤの値（すなわち、ＬａｓｔＭｏＵｎｉｑｕｅＩＤ７０３に１を加算した値）を容易に決めることができる。
あるいは、図１１を用いて説明したように、ＵＤＦファイルシステムはファイルシステム上で、各ファイルに対して重複しないＵｎｉｑｕｅＩＤ５１１を設定するので、このＵｎｉｑｕｅ  ＩＤ５１１の値をメディアユニークＩＤの値として流用することも可能である。
なお、本実施の形態においては、ＭｏＵｎｉｑｕｅＩＤ７４３に設定された値と同じ値を図１１（ａ）で示したＥＦＥ５１０のＥＡｓ５１３中にＭｏＵｎｉｑｕｅＩＤ５４１として設定するようにしてもよい。
その他にも、各種属性情報を示すＡｔｔｒｉｂｕｔｅｓ、当該メディアオブジェクトの再生時間であるＰｌａｙＢａｃｋＤｕｒａｔｉｏｎ、ＭＯ＿ＩＮＦＯ７４０とは異なる場所に格納されるテキスト情報への参照情報ＴｅｘｔＩＤやサムネイル情報への参照情報ＴｈｕｍＩＤ等も含んでいる。
図１６（ｂ）に示すように、ＭｏＴｙｐｅ７４１に設定される値は、参照先のメディアオブジェクトの種類により決まる。
ＭｏＴｙｐｅの値が’１’である場合、あるオブジェクトメディア情報に登録されているメディアオブジェクトの種類は、ファイルシステム上のあるディレクトリである。同様に、値が’２’の場合には動画オブジェクト（拡張子：ＭＯＩ）を、値が’３’の時は静止画オブジェクト（拡張子：ＪＰＧ）を、それぞれ示す。以下同様に、メディアオブジェクトの種類ごとに異なるＭｏＴｙｐｅの値を割り当てることとする。
また、ＭｏＲｅｆ７４２へ設定される値は、参照先のメディアオブジェクトの持つパス名情報を図１６（ｃ）に示す変換規則により変換することにより決定される。
最初のフィールドＰａｒｅｎｔ  Ｄｉｒ  ＮｏはＭＯ＿ＩＮＦＯ７４０が参照するメディアオブジェクトの親ディレクトリのパス名により決められる。すなわち、親ディレクトリがＶＩＤＥＯイメージルートディレクトリ３０１の場合は’０’、ＤＣＩＭイメージルートディレクトリ３０２の場合は’１’となる。それ以外の値については、本実施の形態１では使用しないので予約値としている。
もちろん、変換規則によって与えられる値は別の組み合わせであってもよく、例えば、ＶＩＤＥＯイメージルートディレクトリ３０１に’１’を、ＤＣＩＭイメージルートディレクトリ３０２に’２’を割り当て、その他の場合を予約値とするようにしてもかまわない。
次のフィールドであるＤｉｒ  Ｎｏには、ＭＯ＿ＩＮＦＯ７４０に登録されたメディアオブジェクトのディレクトリ番号部分を抜き出して格納する。ここでディレクトリ番号とは、メディアオブジェクトの上位ディレクトリのディレクトリ名における数値部分である。
次のフィールドであるＦｉｌｅ  Ｎｏには、ＭＯ＿ＩＮＦＯ７４０に登録されたメディアオブジェクトのファイル番号を抜き出して格納する。ここでファイル番号とは、メディアオブジェクトのファイル名における数値部分である。
例えば、メディアオブジェクトのパス名が、“／ＶＩＤＥＯ／１００ＡＢＣＤＥ／ＡＢＣＤ０００１．ＭＯＩ”である場合、当該メディアオブジェクトは“／ＶＩＤＥＯ”ディレクトリを親ディレクトリとして持つので、ＯＢＪ＿ＩＤのＰａｒｅｎｔ  Ｄｉｒ  Ｎｏの値は’０’、そして当該メディアオブジェクトの上位ディレクトリ名の数値部分の値が１００であるので、ＯＢＪ＿ＩＤのＤｉｒ  Ｎｏの値は’１００’となる。さらに、当該メディアオブジェクトのファイル名の数値部分の値をとって、ＯＢＪ＿ＩＤのＦｉｌｅ  Ｎｏの値は’０００１’となる。
以上より、ＭｏＲｅｆ７４２に設定される値は、“／”を区切りとし、Ｐａｒｅｎｔ  Ｄｉｒ  Ｎｏ、Ｄｉｒ  Ｎｏ、Ｆｉｌｅ  Ｎｏの順に並べる表記によれば、０／１００／０００１となる。以降、ＯＢＪ＿ＩＤの値を必要に応じて同様の表記により示す。
ＯＢＪ＿ＩＤをこのような形式としても、ＤＣＦ規格の命名規則のように、メディアオブジェクトの名前やその上位ディレクトリの名前に含まれる数値部分の値が重複しないような命名規則を守っておけば、上述のＭｏＴｙｐｅ７４１の値から導かれる拡張子情報とあわせて、ファイルシステム上で、ＭｏＲｅｆ７４２が参照しているメディアオブジェクトを特定することが可能である。このような構成はＭＯ＿ＩＮＦＯ７４０のデータ量を減らす目的に好適である。
もちろん、ＯＢＪ＿ＩＤのデータ構造は、ＭＯ＿ＩＮＦＯ７４０とメディアオブジェクトが一意に対応づけられる形式であれば他の形式でもよい。例えば、メディアオブジェクトのパス情報をそのまま格納する方法もある。すなわち、“／ＶＩＤＯＥ／１００ＡＢＣＤＥ／ＡＢＣＤ０００１．ＭＯＩ”のように、“／”をパス区切り文字としたフルパス名の文字列を格納してもよい。
あるいは、ＭｏＴｙｐｅ７４０の部分の代わりに、ファイルの拡張子を格納するようにしてもよい。例えば“／ＶＩＤＯＥ／１００ＡＢＣＤＥ／ＡＢＣＤ０００１．ＭＯＩ”というファイルに対しては“ＭＯＩ”の部分を格納するようにしてもよい。
なお、動画オブジェクトについては、属性情報ファイル（例えば、図８における３１２）だけをメディアオブジェクト管理情報に登録してもよい。対応する動画ファイル（この場合、図８における３１１）は、上述のようにファイル名の対応付け等により属性情報ファイルから知ることができるからである。あるいは、逆に、動画ファイルをメディアオブジェクト管理情報に登録するようにしてもよい。同様に対応する属性情報ファイルを知ることができるからである。もちろん、属性情報ファイルと動画ファイルの両方を登録してもかまわない。
次に本実施の形態における拡張オブジェクトの一例であるプログラムマネージャ３３０のデータ構造について、図１７を用いて以下に説明する。
拡張オブジェクトの共通構造として、ヘッダ部８００とデータ部８０１を持つ。
ヘッダ部８００は、ファイルのタイプを表すＤａｔａＴｙｐｅ（拡張オブジェクトを示す固定値を設定）、ファイルのサイズを表すＤａｔａＳｉｚｅ、拡張オブジェクトの型情報を示すＥｏＴｙｐｅ８１１及びＥｏＳｕｂＴｙｐｅ８１２、更新時刻を示すＭｏｄＴｉｍｅ８１３、拡張オブジェクトの概要を示す文字列情報を格納するＴｅｘｔＤｅｓｃ８１４、等から構成される。
ヘッダ部８００において、ＥｏＴｙｐｅ８１１、ＥｏＳｕｂＴｙｐｅ８１２の値により拡張オブジェクトの種類分けを行う。
また、拡張オブジェクトはＥＯ＿ＩＮＦＯ７２０から参照されるが、この時、ＥｏＴｙｐｅ８１１、ＥｏＳｕｂＴｙｐｅ８１２及びＴｅｘｔＤｅｓｃ８１４の値が、ＥＯ＿ＩＮＦＯ７２０中のＥｏＴｙｐｅ７２１、ＥｏＳｕｂＴｙｐｅ７２２及びＴｅｘｔＤｅｓｃ７２６へと設定される。
一方、データ部８０１は、拡張オブジェクトの種類ごとに固有の拡張データを格納し、ＥｏＴｙｐｅ８１１、ＥｏＳｕｂＴｙｐｅ８１２の値により異なるデータ構造を持つ。
図１７（ａ）は、プログラム再生を行うための拡張オブジェクトであるプログラムマネージャ３３０の場合の例であり、拡張データとして次のような構造を持つ。
プログラムマネージャ３３０に登録されたすべてのメディアオブジェクトの再生時間の合計であるＰｌａｙＢａｃｋＤｕｒａｔｉｏｎ、プログラムマネージャ３３０中に含まれるプログラム情報（ＰＲＧ＿ＩＮＦＯ）８２０の数を示すＮｕｍＰｒｇＩｎｆｏ、そして、ＮｕｍＰｒｇＩｎｆｏ個のＰＲＧ＿ＩＮＦＯ８２０からなるプログラム情報テーブル８３０で構成される。
そして、図１７（ｂ）はプログラムマネージャ３３０に含まれるプログラム情報（ＰＲＧ＿ＩＮＦＯ）８２０のデータ構造である。ＰＲＧ＿ＩＮＦＯ８２０は、ＭＯ＿ＩＮＦＯ７４０をグループ化し、ディスクメディア１００上に記録された複数のメディアオブジェクトの分類を行ったり、あるいは、ＰＲＧ＿ＩＮＦＯ８２０から参照しているメディアオブジェクトを順に再生することにより、プログラム再生を実現するときの一つの単位である。
図１７（ｂ）に示すように、ＰＲＧ＿ＩＮＦＯ８２０は、プログラム情報であることを示すＤａｔａＴｙｐｅ、ＰＲＧ＿ＩＮＦＯ８２０のサイズを示すＤａｔａＳｉｚｅ、プログラムの各種属性情報を示すＡｔｔｒｉｂｕｔｅｓ、プログラムの再生時間であるＰａｙＢａｃｋＤｕｒａｔｉｏｎ、ＰＲＧ＿ＩＮＦＯ８２０中に含まれるＭＯ＿ＩＮＦＯ７４０への参照の数を示すＮｕｍＭｏＩｎｆｏ、そして、ＮｕｍＭｏＩｎｆｏ個のＭｏＩＤからなるＭＯ＿ＩＮＦＯ７４０への参照テーブル、等から構成される。
その他にも、ＰＲＧ＿ＩＮＦＯ８２０とは異なる場所に格納されるテキスト情報への参照情報ＴｅｘｔＩＤやサムネイル情報への参照情報ＴｈｕｍＩＤ等も含んでもよい。
本構造により、拡張オブジェクトであるプログラムマネージャ３３０は、任意のメディアオブジェクトをグループ化することが可能となる。これにより、ファイルシステム上のディレクトリ構造とは独立して、仮想的なフォルダー構造を構成し、メディアオブジェクトの自由な分類整理を行える。また、ユーザの望みの再生順序でメディアオブジェクトを再生するプログラム再生等の機能も実現できる。
次に、図１８を用いて、ファイルシステムで管理されるディレクトリやメディアオブジェクトと、ＭＯ＿ＩＮＦＯ７４０との関係を説明する。
メディアオブジェクトマネージャ３２０には、複数のＭＯ＿ＩＮＦＯ７４０が含まれており、それぞれにメディアオブジェクトが登録されている。例えば、ＭｏＩｎｆｏ［１］９００には、ディレクトリ３０４が登録されている。この時、ＭｏＩｎｆｏ［１］９００のフィールドの値は次のように設定される。
まずＭｏＴｙｐｅは、図１６（ｂ）より、ディレクトリを示す’１’が設定される。ＭｏＲｅｆは、図１６（ｃ）より、親ディレクトリ’０’、ディレクトリ番号’１００’、ファイル番号’００００’となり、フィールド値全体としては０／１００／００００となる。
ＭｏＵｎｉｑｕｅＩＤ７４３は、ここでは’１００’が設定されており、他のＭＯ＿ＩＮＦＯに設定されている値と重複していない。
また、ＭｏＩｎｆｏ［２］９０１のフィールドの値は次のように設定される。まずＭｏＴｙｐｅは、動画オブジェクトを示す’２’が設定される。ＭｏＲｅｆ７１１は、親ディレクトリ’０’、ディレクトリ番号’１００’、ファイル番号’０００１’となり、フィールド値全体としては０／１００／０００１となる。ＭｏＵｎｉｑｕｅＩＤは、重複しない値として’１０１’が設定されている。以降、その他のＭｏＩｎｆｏも同様に値が設定される。
図１９は、このようなメディアオブジェクトマネージャ３２０に対する、プログラムマネージャ３３０の関係を示すものである。上述のように、プログラムマネージャ３３０には複数のＰＲＧ＿ＩＮＦＯ８００（ＰｒｇＩｎｆｏ［１］９１０〜）が含まれる。
各ＰＲＧ＿ＩＮＦＯ８００は、ＭＯ＿ＩＮＦＯ７００への参照情報を、メディアユニークＩＤとして保持する。すなわち、ＭＯ＿ＩＮＦＯ７００がＭｏＵｎｉｑｕｅＩＤ７１２で保持しているメディアユニークＩＤの値を参照情報とする。
例えば、ＰｒｇＩｎｆｏ［１］９１０では、図１９中の波線矢印で示すように、ＭｏＩｎｆｏ［２］とＭｏＩｎｆｏ［５］とＭｏＩｎｆｏ［８］への参照を持つので、ＭｏＩＤのテーブル（ＭｏＩＤ［］）の値として、１０１、１０４、２０１を保持する。ＰｒｇＩｎｆｏ［２］９１１でも同様に、ＭｏＩｎｆｏ［６］とＭｏＩｎｆｏ［８］への参照を持つので、ＭｏＩＤ［］の値として、１０５、２０１を保持する。
この状態において、プログラム再生を実施するための処理について説明する。例えば、ＰｒｇＩｎｆｏ［１］９１０によるプログラム再生の開始が指示されたとすると、コンテンツ管理情報処理部６１１は、ＰｒｇＩｎｆｏ［１］９１０内のメディアオブジェクト情報への参照テーブルＭｏＩＤ［］内の値を読み出す。上述したとおり、ＭｏＩＤ［］には、プログラム再生の対象となるメディアオブジェクトへの参照情報がメディアユニークＩＤとして保持されている。
よって、プログラム再生を行うには、ＭｏＩＤ［］に保持されているメディアユニークＩＤの指し示すＭＯ＿ＩＮＦＯ７４０をメディアオブジェクトマネージャ３２０中から検索し、それが見つかったら、ＭＯ＿ＩＮＦＯ７４０が参照するメディアオブジェクトの再生を行う。
ＭｏＩＤ［］に保持されているすべてのメディアユニークＩＤに対して同様の手順を繰り返すことによりプログラム再生が実行される。
図２０は、複数の拡張オブジェクトが存在する場合において、ファイルシステムで管理されるディレクトリやメディアオブジェクト、メディアオブジェクトマネージャ３２０との関係を示すものである。ここでは、プログラムマネージャ３３０とは異なる拡張オブジェクト１０００と１００１が存在する。
図１９を用いて説明したのと同様に、拡張オブジェクト１０００と１００１はメディアオブジェクトマネージャ３２０を経由して（例えば、プログラムマネージャ３３０と同様にメディアユニークＩＤにより）メディアオブジェクトに対応付けられており、さまざまな拡張情報を提供する。
例えば、拡張オブジェクト１０００は、各メディアオブジェクトがこれまでに何回再生されたかの再生回数のカウント値を保持する拡張オブジェクトである。各メディアオブジェクトが再生されるたびにそのカウント値を増加させて、拡張オブジェクト１０００内に保持する。このようなカウント値を拡張情報として保持しておくことにより、あるメディアオブジェクトをユーザが既に視聴したかどうかを示すことが出来る。
あるいは、再生回数のカウント値をユーザの録画映像に対する好みの判定に用いることも出来る。例えばカウント値が大きい場合は、ユーザの好みの映像が録画されていると判断し、逆に、カウント値が少ないメディアオブジェクトは好みではないと判断する。このような情報は、例えば、記録媒体１００上の空き容量が少なくなったとき、不要なメディアオブジェクトの削除を行う時の参考情報として用いることが可能である。
また、拡張オブジェクト１００１は、各メディアオブジェクトに対するＧＰＳ情報を格納する。各メディアオブジェクトが記録された時点での位置情報を記録しておき、後に検索や表示するために用いることが可能である。
ユーザが旅行の記念撮影などを行った時に、ＧＰＳ情報があれば、行き先の位置情報を頼りに、多数のメディアオブジェクトから目的のメディアオブジェクトを容易に探し出すことが可能となる。
なお、拡張オブジェクトとして保持するデータとしては、上記に限られるものではなく、他のデータでもよい。例えば、各メディアオブジェクトに対するｃａｍｅｒａパラメータ（記録時のカメラの種別、ズームの有無、フラッシュの有無、等）や、ＭＰＥＧ７などのメタデータ等でもよい。その他、製造メーカが他社製品との差別化やユーザに対する独自の利便性を提供することを目的として、メディアオブジェクトマネージャ３２０等の統一規格に含まれない機能を実現するために利用してよい。
図２１は、図２０の状態において、拡張オブジェクト管理情報テーブル７１０に設定される値の例を示す図である。
図２１（ａ）の一つの行がＥＯ＿ＩＮＦＯ７２０に相当する。各ＥＯ＿ＩＮＦＯのＥｏＴｙｐｅ及びＥｏＳｕｂｔｙｐｅは、それぞれの拡張オブジェクトの内容を識別するための値（ここではそれぞれ２文字のアスキーコード）が設定される。なお、各ＥｏＴｙｐｅ及びＥｏＳｕｂｔｙｐｅの値は一例であり、各拡張オブジェクトが識別可能であれば他の値でもかまわない。
ＥｏＲｅｆとして、ここでは、拡張オブジェクトのファイル名を格納する。なお、拡張オブジェクトを参照する時のデータ形式は他の形式でもよく、ＭＯ＿ＩＮＦＯ７４０がメディアオブジェクトを参照する時に使用するＯＢＪ＿ＩＤのように、ファイル番号などの特定の変換規則を利用することも可能である。
ＥｏＦｌａｇｓについては、ここでは、すべての情報が有効であるとし、Ｖａｌｉｄ＝１ｂがすべて設定されている。ＴｅｘｔＤｅｓｃは、それぞれの拡張オブジェクトの保持する情報の内容を簡単な文字列として保持している。
図２２は、本実施の形態において、新規の拡張オブジェクト及び拡張データを記録するための処理を示すフローチャートである。
まず、拡張情報処理部６１２が、拡張オブジェクト管理情報テーブル７１０をメディアオブジェクトマネージャ３２０から読み出す（ステップＳ１０１）。
次に、拡張オブジェクト管理情報テーブル７１０中の各ＥＯ＿ＩＮＦＯ７２０の値を調べることにより、追加したい拡張データを含む拡張オブジェクトがすでに存在しているかどうかを調べる（ステップＳ１０２）。
拡張オブジェクトが存在していない場合は新規に作成し（ステップＳ１０３）、対応するＥＯ＿ＩＮＦＯ７２０を拡張オブジェクト管理情報テーブル７１０へと追加する（ステップＳ１０４）。拡張オブジェクトが存在していた場合及び新規に作成した後は、その拡張オブジェクトへ拡張データを追加する（ステップＳ１０５）。
図２３は、本実施の形態において、メディアオブジェクト及びＭＯＩＮＦＯ７４０に対する何らかの操作が行われた後、拡張オブジェクト管理情報テーブル７１０に対して行われる処理を示すフローチャートである。ここで、メディアオブジェクト及びＭＯ＿ＩＮＦＯ７４０に対する何らかの操作とは、例えば、メディアオブジェクトやＭＯ＿ＩＮＦＯ７４０中のデータ値の書き換えや編集及び削除、等のことである。
このような操作が行われると、メディアオブジェクト及びメディアオブジェクトマネージャ３２０と、拡張オブジェクト及び拡張データ間の情報の不整合が発生する場合がある。
例えば、拡張データの一種であるＰＲＧ＿ＩＮＦＯ８２０から参照されているメディアオブジェクトが削除されてしまうと、ＰＲＧ＿ＩＮＦＯ８２０からの参照先がなくなってしまい、プログラム再生の実行の際に不都合が生じる。
プログラム再生以外の他の拡張データの場合も同じで、参照先のメディアオブジェクトやＭＯ＿ＩＮＦＯ７４０が変更されると、不整合が発生する。
そこで本実施の形態においては、メディアオブジェクト及びメディアオブジェクトマネージャ３２０に対して何らかの操作が行われると以下の処理を実施する。
まず、拡張情報処理部６１２は、拡張オブジェクト管理情報テーブル７１０をメディアオブジェクトマネージャ３２０から読み出す（ステップＳ２０１）。
拡張オブジェクト管理情報テーブル７１０には、ＴｏｔａｌＮｕｍＥｏＩｎｆｏ７０４で示される数だけＥＯ＿ＩＮＦＯ７２０が存在するので、ステップＳ２０２からステップＳ２０８のループ処理によりすべてのＥＯ＿ＩＮＦＯ７２０に対する処理を行う。
まず、ループ処理のカウント値を初期化し（ステップＳ２０２）する。
そして、最初の拡張オブジェクトに対して、処理可能かどうかを判別する（ステップＳ２０３）。この判別には、ＥｏＴｙｐｅ７２１及びＥｏＳｕｂｔｙｐｅ７２２やＥｏＲｅｆ７２３が利用可能である。
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、Ｖａｌｉｄフラグ７３１を０ｂに設定する（ステップＳ２０４）。これにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ３２０との間での整合性を保障しない状態であることを示す。一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し（ステップＳ２０５）、Ｖａｌｉｄフラグ７３１を１ｂに設定する（ステップＳ２０６）。
ここで、該拡張オブジェクトの内容を更新とは、先に行われたメディアオブジェクト及びメディアオブジェクトマネージャ３２０に対する操作の結果と、該拡張オブジェクトの内容が整合するような処理である。
例えば、拡張オブジェクトがプログラムマネージャ３３０であり、メディアオブジェクト及びメディアオブジェクトマネージャ３２０に対する操作が、メディアオブジェクト及びそれを参照するＭＯ＿ＩＮＦＯ７４０の削除であった場合、プログラムマネージャ３３０に対しては、該ＭＯ＿ＩＮＦＯ７４０を参照するＰＲＧ＿ＩＮＦＯ８２０を更新し、削除された該ＭＯ＿ＩＮＦＯ７４０への参照を削除する処理を行う。他の種類の拡張オブジェクトに対しても、それぞれの拡張情報に応じた更新処理を実施する。
更新処理を実施することにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ３２０との間での整合性を保障できるので、Ｖａｌｉｄフラグ７３１を１ｂに設定している。
以降、カウント値を加算しながら、ＴｏｔａｌＮｕｍＥｏＩｎｆｏの値に等しくなるまで処理を繰り返す（ステップＳ２０７、ステップＳ２０８）。
図２３のような処理が終了した後の拡張オブジェクト管理情報テーブル７１０に設定される値の例を図２１（ｂ）に示す。
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。２行目以降のＥＯ＿ＩＮＦＯ７２０のＶａｌｉｄフラグが０ｂに設定され、これらの拡張オブジェクトのデータの有効性が保障されない状態であることを示している。
図２４は、本実施の形態において、特定の種類の拡張オブジェクトを指定してそのデータを利用する際の処理に関するフローチャートである。
まず、拡張情報処理部６１２は、拡張オブジェクト管理情報テーブル７１０をメディアオブジェクトマネージャ３２０から読み出す（ステップＳ３０１）。
次に、拡張オブジェクト管理情報テーブル７１０内を検索し、目的の拡張オブジェクトを参照しているＥＯ＿ＩＮＦＯ７２０を得る（ステップＳ３０２）。目的の拡張オブジェクトの検出は、ＥｏＴｙｐｅ７２１及びＥｏＳｕｂｔｙｐｅ７２２の値を調べることにより行える。あるいは拡張オブジェクトのパス名の命名側を決めておくことにより、ＥｏＲｅｆ７２３の値を見ることにより検出可能である。
もし、目的の拡張オブジェクトを参照しているＥＯ＿ＩＮＦＯ７２０が見つからなければ、例外処理を行い（ステップＳ３０３）、本フローチャートで示す処理を終了する。例外処理とは例えば、ユーザに所望の拡張オブジェクトが存在しないことを知らせるメッセージを表示したり、あるいは、新たに、該拡張オブジェクトを作成したりする処理などである。
もし、目的の拡張オブジェクトを参照しているＥＯ＿ＩＮＦＯ７２０が見つかれば、Ｖａｌｉｄフラグの値が１ｂであるかを調べる（ステップＳ３０４）。
Ｖａｌｉｄフラグの値が１ｂでなければ例外処理を実施する（ステップＳ３０５）。ここでの例外処理とは例えば、ユーザに所望の拡張オブジェクトとメディアオブジェクトマネージャ３２０との間で不整合が存在することを知らせるメッセージを表示したり、記録媒体１００の書き込みを禁止したり、あるいは、該拡張オブジェクトとメディアオブジェクトマネージャ３２０の不整合を解消すべく、該拡張オブジェクト内の情報を更新する処理を実施したりする処理、等である。
一方、Ｖａｌｉｄフラグの値が１ｂであれば、該拡張オブジェクトに対する通常処理を実施する（ステップＳ３０６）。通常処理とは、例えば、該拡張オブジェクトが、プログラムマネージャ３３０であれば、プログラム再生を実施することである。
他の拡張オブジェクトに関しても、あるメディアオブジェクトに関連付けられている拡張データをユーザに対して表示する（ＧＰＳ情報の表示など）、等、夫々の種類に応じた動作を行う。
図２４中の例外処理を行う場合に、少なくともＴｅｘｔＤｅｓｃ７２６の値を表示するようにすれば、どんな拡張情報が設定されているかをユーザに知らせることが可能である。
以上により、メディアオブジェクトマネージャ３２０のデータ容量を大幅には増加させず、拡張情報の追加が行える。
これは、ＤＶＤレコーダやＤＶＤビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、ある記録再生装置が対応していない拡張機能が存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
これは、ＤＶＤレコーダやＤＶＤビデオカメラなどの可搬型の記録媒体を用いた記録再生装置において、１つの記録媒体が複数の製造メーカによる記録再生装置で記録・再生される場合において望ましい構成である。
（実施の形態２）
本実施の形態では、実施の形態１とは異なる拡張オブジェクトの管理の方法について述べる。実施の形態１では、拡張オブジェクト管理情報テーブル７１０により拡張オブジェクトを管理したが、本実施の形態では、ＭＯ＿ＩＮＦＯにより各拡張オブジェクトを管理する。
このときの、拡張オブジェクトとＭＯ＿ＩＮＦＯの関係を図２５に示す。ここでは、メディアオブジェクトマネージャ３２０に含まれるＭＯ＿ＩＮＦＯであるＭｏＩｎｆｏ［ｉ］〜ＭｏＩｎｆｏ［ｉ＋２］がそれぞれ拡張オブジェクト１０００、３３０、１００１を参照、管理しているものとする。ただし、本実施の形態におけるＭＯ＿ＩＮＦＯは、図２６に示す構造を持つものとする。
図２６（ａ）におけるＭＯ＿ＩＮＦＯ２０００は、ＭＯ＿ＩＮＦＯ７４０に対して、ＥＯ＿ＩＮＦＯ２１００のフィールドが追加されている点を除いて同一である。
ＥＯ＿ＩＮＦＯ２１００は、ＥＯ＿ＩＮＦＯ７２０と異なる構造を持ち、図２６（ｂ）で示す構造を持つ。
ＥＯ＿ＩＮＦＯ２１００は、ＥＯ＿ＩＮＦＯ７２０からＥｏＲｅｆ７２３とＴｅｘｔＤｅｓｃ７２６を除いた構造を持ち、ＥｏＲｅｆ７２３の代わりにＭｏＴｙｐｅ７４１とＭｏＲｅｆ７４２を、ＴｅｘｔＤｅｓｃ７２６の代わりにＴｅｘｔＩＤ７４４を用いることで同様の機能を果たす。すなわち、ＭｏＴｙｐｅ７４１とＭｏＲｅｆ７４２により拡張オブジェクトを参照し、ＴｅｘｔＤｅｓｃ７２６により拡張オブジェクトに対する文字列情報を格納する。
なお、上記機能を実現するために、図１６（ｂ）のＭｏＴｙｐｅ７４１の値に対して、拡張オブジェクト（拡張子：ＥＸＴ）を示す値（例えば“４”）を定義することとする。
また、ＭｏＲｅｆ  ７４２による参照を行うために、拡張オブジェクトのディレクトリ名やファイル名は、ディレクトリ番号及びファイル番号による一意な参照が可能となるような命名則を用いる。
上記構成により、メディアオブジェクトと拡張オブジェクトを共通の枠組みで管理することが可能となり、装置の実装上、好都合である。
（実施の形態３）
本実施の形態では、異なる拡張オブジェクトの管理の方法について述べる。
実施の形態１では、拡張オブジェクト管理情報テーブル７１０のＶａｌｉｄフラグ７３１において拡張オブジェクトの有効性を管理したが、本実施の形態では、ＭＯ＿ＩＮＦＯにおいて各拡張オブジェクトの有効性を管理する。
このとき、メディアオブジェクトを参照・管理するＭＯ＿ＩＮＦＯは図２７に示すデータ構造を持つものとする。
図２７（ａ）におけるＭＯ＿ＩＮＦＯ３０００は、ＭＯ＿ＩＮＦＯ７４０に対して、拡張データ属性フラグ（ＲｅｆＶａｌｉｄＦｌａｇ）３１００のフィールドが追加されている点を除いて同一である。
ＲｅｆＶａｌｉｄＦｌａｇ３１００は、図２７（ｂ）に示す情報を保持する。ＲｅｆＶａｌｉｄＦｌａｇ３１００では、２ビットがひとつの拡張オブジェクトに対応している。
例えば、ビット０〜１は、拡張オブジェクトの内、ファイル番号が０００１番を持つものに対応する。同様に、ビット１〜２はファイル番号が０００２番に対応し、以降も同様である。
そして、この各２ビットの解釈は、次のとおりである。すなわち、上位ビットは、該ＭＯ＿ＩＮＦＯ３０００が管理するメディアオブジェクトに対して、拡張オブジェクトからの参照が存在する（１ｂ）か、存在しない（０ｂ）かを示す。そして、下位ビットは、ＭＯ＿ＩＮＦＯ３０００が管理するメディアオブジェクトに対する拡張データが有効である（１ｂ）か無効である（０ｂ）かを示す。
すなわち、この下位ビットは、Ｖａｌｉｄフラグ７３１と同じ意味を持つ。ただし、このＲｅｆＶａｌｉｄＦｌａｇ３１００の下位ビットは、ＭＯ＿ＩＮＦＯ３０００単位で拡張データが有効かどうかを示すことができ、より詳細な単位での拡張データの管理が可能となっている。
具体的には、例えば図２０に示したのと同様な参照関係が存在する場合、図２０中のＭｏＩｎｆｏ［１］のＲｅｆＶａｌｉｄＦｌａｇ３１００に設定される値は、図２７（ｂ）の右端の列「設定値の例」のようになる。
すなわち、ＭｏＩｎｆｏ［１］は、ファイル番号０００１を持つ拡張オブジェクトであるプログラムマネージャ３３０からの参照を持ち、かつその値が有効であるとすると、ビット０〜１は１１ｂという値に設定される。また、同様に、ファイル番号０００２を持つ拡張オブジェクトからも参照されており、かつその値が有効であるとすると、ビット２〜３は１１ｂという値に設定される。
一方、ファイル番号００１６を持つ拡張オブジェクトも存在するが、そこからは参照されていないので、ビット３０〜３１は００ｂという値に設定される。
また、上記状態から、図２３を用いて説明した処理と同様、メディアオブジェクトに対する編集操作等が行われると拡張オブジェクトとの整合性が保証されない場合が発生する。
例えば、拡張データの一種であるＰＲＧ＿ＩＮＦＯ８２０から参照されているメディアオブジェクトが編集され、その再生時間長が変化してしまう（例えば、再生時間が短くなる）と、プログラムの再生時間であるＰｌａｙＢａｃｋＤｕｒａｔｉｏｎが実際の値と異なってしまい、プログラム再生の実行の際にユーザに混乱を与えてしまう。
そこでこの時、図２８で示す処理を実施する。
まず、拡張情報処理部６１２は、編集対象のメディアオブジェク管理情報３０００からＲｅｆＶａｌｉｄＦｌａｇ３１００を読み出す（ステップＳ４０１）。
ＲｅｆＶａｌｉｄＦｌａｇ３１００のフィールド長に応じた数だけ拡張オブジェクトが存在する可能性があるので、ステップＳ４０２からステップＳ４０９のループ処理により、存在するすべての拡張オブジェクトに対する処理を行う。
次に、ループ処理のカウント値を初期化（ステップＳ４０２）する。
そして、最初の拡張オブジェクトに対して、該メディアオブジェクトに対して参照する拡張オブジェクトが存在するかを判別する（ステップＳ２０３）。この判別は、該拡張オブジェクトに対応するＲｅｆＶａｌｉｄＦｌａｇ３１００中の２ビットの内、上位ビットの値により行われる。もし、参照が存在しない場合は、ステップ４０８へ進む。
参照が存在した場合は、該拡張オブジェクトに対して、処理可能かどうかを判別する（ステップＳ４０４）。
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトに対応するＲｅｆＶａｌｉｄＦｌａｇ３１００中の２ビットの内、下位ビットの値を０ｂに設定する（ステップＳ４０５）。これにより、該拡張オブジェクトと該メディアオブジェクトとの間での整合性を保障しない状態であることを示す。
一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し（ステップＳ４０６）、該拡張オブジェクトに対応するＲｅｆＶａｌｉｄＦｌａｇ３１００中の２ビットの内、下位ビットの値を１ｂに設定する（ステップＳ４０７）。ここで、拡張オブジェクトの内容を更新とは、例えば、メディアオブジェクトの編集に伴い、プログラムのＰｌａｙＢａｃｋＤｕｒａｔｉｏｎを更新する処理である。
以降、カウント値を加算しながら、全てのＲｅｆＶａｌｉｄＦｌａｇ３１００に対して処理を繰り返す（ステップＳ４０８、ステップＳ４０９）。
図２８のような処理が終了した後のＲｅｆＶａｌｉｄＦｌａｇ３１００に設定される値の例を図２９に示す。
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。ＲｅｆＶａｌｉｄＦｌａｇ３１００ビット２については１ｂのまま変化がなく、一方、ビット３が０ｂに設定され、この拡張オブジェクトからの参照は依然として存在するが、そのデータの有効性が保障されない状態であることを示している。
以上のように、実施の形態１においては、拡張オブジェクト全体に対して有効かどうかをＶａｌｉｄフラグ７３１を用いて管理したが、本実施の形態においては、ＲｅｆＶａｌｉｄＦｌａｇ３１００の下位ビットを用いることにより、メディアオブジェクト及びＭＯ＿ＩＮＦＯ毎に有効性の管理が可能となり、拡張オブジェクト全体を更新せず、その一部だけを更新するような、より柔軟な管理が可能となる。
また、図２４を用いて説明したのと同様、ＲｅｆＶａｌｉｄＦｌａｇ３１００の下位ビットの値を見る（すなわち、図２４のステップＳ３０４に相当する処理を実施する）ことにより、拡張オブジェクトの情報が有効な場合は通常処理を行い、有効性が保証されない場合は、適切な例外処理や書き込みの禁止、ユーザへのメッセージの表示などを行うことが可能である。
このような構成は、特にメディアオブジェクトマネージャのデータ量が大きい場合、必ずしもその全体を更新しなくてよいので、データ処理量の効率化に有効である。
なお、本実施の形態においては、ＲｅｆＶａｌｉｄＦｌａｇ３１００を３２ビット長としたが、他のデータ長でもよく、あるいは、可変長にすることも可能である。可変長にすることにより効率的に拡張オブジェクトの数の変化に対応可能となる。
また、上記においては、ＲｅｆＶａｌｉｄＦｌａｇ３１００のビット０〜１をファイル番号が０００１番である拡張オブジェクトに対応するとしたが、ＲｅｆＶａｌｉｄＦｌａｇ３１００の各ビットと拡張オブジェクトとの対応関係についてはこれに限るものではない。例えば、ビット３０〜３１のようなＲｅｆＶａｌｉｄＦｌａｇ３１００の上位ビットにファイル番号が０００１番である拡張オブジェクトを対応させるようにしても良い。
また、ＲｅｆＶａｌｉｄＦｌａｇ３１００と拡張オブジェクトをそのファイル番号により対応づけたが、他の方法による対応付けを行ってもよい。
（実施の形態４）
本実施の形態では、更新日時情報を用いた拡張オブジェクトの有効性管理方法について述べる。
図１５（ａ）で示したように、メディアオブジェクトマネージャ３２０には、その更新日時を示すＭｏｄＴｉｍｅ７０２が設けられている。メディアオブジェクトマネージャ３２０の内容が更新されるたびに、ＭｏｄＴｉｍｅ７０２の値も更新するものとする。
一方、拡張オブジェクトにもその更新日時を示すＭｏｄＴｉｍｅ８１２が設けられている。ＭｏｄＴｉｍｅ８１３も同様に、拡張オブジェクトの内容が更新されるたびに、その値が更新されるものとする。
ただし、図２３の処理手順で示したとおり、本発明の記録再生装置においては、処理可能な拡張オブジェクトのみをその内容を更新するものとする（図２３のステップＳ２０５）。
これにより、メディアオブジェクトに対する編集操作等が行われると、メディアオブジェクトマネージャ３２０が更新され、さらに、処理可能な拡張オブジェクトのみが更新される。
結果として、ＭｏｄＴｉｍｅ７０２の値と、処理可能な拡張オブジェクトのＭｏｄＴｉｍｅ８１３が一致する。一方、処理不可能な拡張オブジェクトは更新されないのでそのＭｏｄＴｉｍｅ８１３も更新されず、ＭｏｄＴｉｍｅ７０２の値と一致しなくなる。
よって、本発明の記録再生装置において、ある拡張オブジェクトを処理しようとする時、ＭｏｄＴｉｍｅ７０２の値とのＭｏｄＴｉｍｅ８１３の値を比較することにより、該拡張オブジェクトが有効であるかどうかを知ることができる。
これはすなわち、図２４で示したＶａｌｉｄフラグの値が１ｂであるかどうかを調べる（図２４のステップＳ３０４）のと同様の効果があることを意味する。
なお、図１７では、拡張オブジェクトとしてプログラムマネージャ３３０を用いて説明したが、他の拡張オブジェクトでも、ＭｏｄＴｉｍｅ８１３と同じフィールドを持つことにより同様の効果を得ること可能である。
なお、上述の実施例において、ＭＯ＿ＩＮＦＯ７４０、２０００、３０００は、Ｐｒｏｐｅｒｔｙ  Ｅｎｔｒｙと呼ばれることもある。また、ＭｏＴｙｐｅ７４１及びＭｏＲｅｆ７４２をあわせて、Ｂｉｎａｒｙ  Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒと呼ばれることもある。また、ＭｏＵｎｉｑｕｅＩＤ７４３は、ｅｎｔｒｙ＿ｎｕｍｂｅｒと呼ばれることもある。また、拡張オブジェクトはメーカ独自ファイル、あるいは、プライベートファイルと呼ばれることもある。また、ＲｅｆＶａｌｉｄＦｌａｇ３１００は、ｖｆｌａｇｓと呼ばれることもある。
なお、上述したいずれの実施の形態においても、記録再生装置及び記録媒体をＤＶＤのような光ディスクメディアを例に挙げて説明しているが、特に限定されるものではなく、その他磁気記録メディアを用いたハードディスクドライブ、光磁気ディスクメディア等、他の記録装置や記録媒体であっても良い。
以上のように、本発明にかかる記録再生装置及び方法によれば、拡張機能のためのデータ追加を効率的に行える。これは、ＤＶＤレコーダやＤＶＤビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、統一規格では定められていないため、ある記録再生装置では対応していない拡張機能または拡張オブジェクトが存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
特に、ＤＶＤレコーダやＤＶＤビデオカメラなどの可搬型の記録媒体を用いた民生用の記録再生装置では、１つの記録媒体が複数の製造メーカによる異なる拡張機能を持った記録再生装置で記録・再生されることが想定される。よって、本発明にかかる記録再生装置及び方法により、より大きな効果を得ることが可能となる。
なお、上記の実施形態では、本発明の側面のうち、主に、記録装置、再生装置、記録媒体、記録方法、再生方法に関する実施形態を説明した。しかし、本発明は、他の側面として、前記記録装置の記録動作を制御するプログラム、前記再生装置の再生動作を制御するプログラム、これらのプログラムの提供媒体（プログラム製品）、および、記録媒体に記録されたデータ構造、としても実施することが可能である。当業者であれば、上述の実施形態の説明から、これらの側面の実施形態についても容易に理解することが可能であろう。
【産業上の利用可能性】  本発明は、これらに限定されないが、例えばＤＶＤ等の記録媒体や、ＤＶＤレコーダやＤＶＤビデオカメラ等の記録・再生装置に利用可能である。
【図１】
2004095285.tif 000005
【図２】
2004095285.tif 000006
【図３】
2004095285.tif 000007
【図４】
2004095285.tif 000008
【図５】
2004095285.tif 000009
【図６】
2004095285.tif 000010
2004095285.tif 000011
【図８】
2004095285.tif 000012
2004095285.tif 000013
2004095285.tif 000014
2004095285.tif 000015
2004095285.tif 000016
2004095285.tif 000017
【図１４】
2004095285.tif 000018
2004095285.tif 000019
2004095285.tif 000020
2004095285.tif 000021
【図１８】
2004095285.tif 000022
【図１９】
2004095285.tif 000023
【図２０】
2004095285.tif 000024
2004095285.tif 000025
【図２２】
2004095285.tif 000026
【図２３】
2004095285.tif 000027
【図２４】
2004095285.tif 000028
【図２５】
2004095285.tif 000029
2004095285.tif 000030
2004095285.tif 000031
【図２８】
2004095285.tif 000032
【図２９】
2004095285.tif 000033
【図３０】
2004095285.tif 000034
【図３１】
2004095285.tif 000035
【手続補正書】
【提出日】平成17年3月16日(2005.3.16)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
記録媒体に情報の記録を行う記録部と、
前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、
前記ディレクトリ及び前記ファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、
前記ディレクトリ及び前記ファイルに対する拡張情報を管理する拡張情報処理部と、を備えた記録装置であって、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが、前記オブジェクト参照情報を経由して対応付けられていることを特徴とする記録装置。
【請求項２】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、
前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報については、前記拡張情報を更新し、
処理不可能な種類の前記拡張情報については、前記拡張情報を更新せず、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新する、請求項１に記載の記録装置。
【請求項３】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項２に記載の記録装置。
【請求項４】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記メディアオブジェクト管理情報を更新した時、
前記第１の更新日時情報を更新し、
処理可能な種類の前記拡張情報については、前記第２の更新日時情報に前記第１の更新日時情報と同じ値を設定し、
処理不可能な種類の前記拡張情報については、前記第２の更新日時情報を更新しない、請求項１に記載の記録装置。
【請求項５】
記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、
前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを備えた記録方法であって、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記記録方法は、
前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を含むことを特徴とする記録方法。
【請求項６】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、
前記記録方法は、
前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報を更新する工程と、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新する工程とを含む、請求項５に記載の記録方法。
【請求項７】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項６に記載の記録方法。
【請求項８】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記コンテンツ管理情報を更新する工程と、
前記第１の更新日時情報を更新する工程と、
処理可能な種類の前記拡張情報については、前記第２の更新日時情報に前記第１の更新日時情報と同じ値を設定する工程とを含む、請求項５に記載の記録方法。
【請求項９】
情報が記録された記録媒体であって、
前記情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、
前記ディレクトリ及び前記ファイルに対する拡張情報とが記録されており、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする記録媒体。
【請求項１０】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含む、請求項９に記載の記録媒体。
【請求項１１】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項１０に記載の記録媒体。
【請求項１２】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記ディレクトリ及び前記ファイルと、それに対応する前記拡張情報との整合性が保証されている場合に、
前記第１の更新日時情報と前記第２の更新日時情報に同じ値が記録されている、
請求項９に記載の記録媒体。
【請求項１３】
請求項１０または１１に記載の記録媒体から情報の再生を行う再生装置であって、
前記情報を前記記録媒体から再生する再生部と、
前記ファイルシステム情報を処理するファイルシステム処理部と、
前記拡張情報を処理する拡張情報処理部と、
前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、
前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定することを特徴とする再生装置。
【請求項１４】
請求項１２に記載の記録媒体から情報の再生を行う再生装置であって、
前記情報を前記記録媒体から再生する再生部と、
前記ファイルシステム情報を処理するファイルシステム処理部と、
前記拡張情報を処理する拡張情報処理部と、
前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、
前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定することを特徴とする再生装置。
【請求項１５】
請求項１０または１１に記載の記録媒体から情報の再生を行う再生方法であって、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを備え、
前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする再生方法。
【請求項１６】
請求項１２に記載の記録媒体から情報の再生を行う再生方法であって、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを備え、
前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする再生方法。
【請求項１７】
記録媒体へ情報の記録を行う記録装置において、当該記録装置の記録動作を制御するプログラムであって、
前記プログラムは、
記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、
前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを前記記録装置に実行させる命令を含み、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記プログラムは、
前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を前記記録装置に実行させる命令をさらに含むことを特徴とするプログラム。
【請求項１８】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性
に関する状態を管理する整合性状態管理情報を含み、
前記プログラムは、
前記記録装置が前記ディレクトリ及び前記ファイルに対する操作を行う時、
処理可能な種類の前記拡張情報を更新する工程と、
前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新する工程と前記記録装置に実行させる命令を含む、請求項１７に記載のプログラム。
【請求項１９】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項１８に記載のプログラム。
【請求項２０】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記プログラムは、
前記コンテンツ管理情報を更新する工程と、
前記第１の更新日時情報を更新する工程と、
処理可能な種類の前記拡張情報については、前記第２の更新日時情報に前記第１の更新日時情報と同じ値を設定する工程を前記記録装置に実行させる命令を含む、請求項１７に記載のプログラム。
【請求項２１】
請求項１０または１１に記載の記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムであって、
前記プログラムは、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、
前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とするプログラム。
【請求項２２】
請求項１２に記載の記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムであって、
前記プログラムは、
前記情報を前記記録媒体から再生する工程と、
前記ファイルシステム情報を処理する工程と、
前記拡張情報を処理する工程と、
前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、
前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とするプログラム。
【請求項２３】
請求項１７〜２２のいずれか一項に記載のプログラムを媒体に記録したプログラム提供媒体。
【請求項２４】
記録媒体に記録されたデータ構造であって、
前記記録媒体に記録されたコンテンツ情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、
前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、
前記ディレクトリ及び前記ファイルに対する拡張情報とを含み、
前記コンテンツ管理情報は、
前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、
前記拡張情報を管理する拡張オブジェクト管理情報とを含み、
前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とするデータ構造。
【請求項２５】
前記拡張オブジェクト管理情報は、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含む、請求項２４に記載のデータ構造。
【請求項２６】
前記整合性状態管理情報が、
前記メディアオブジェクト管理情報毎に設けられ、
前記拡張情報の種別毎に、
少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、
前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含む、請求項２５に記載のデータ構造。
【請求項２７】
前記コンテンツ管理情報は、第１の更新日時情報を含み、
前記拡張情報には、第２の更新日時情報を含み、
前記ディレクトリ及び前記ファイルと、それに対応する前記拡張情報との整合性が保証されている場合に、
前記第１の更新日時情報と前記第２の更新日時情報に同じ値が記録されている、請求項２４に記載のデータ構造。
【手続補正２】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、主に、記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体並びに当該記録媒体を再生する再生装置及び再生方法に関する。特に、画像データや音声データを記録媒体にファイルとして記録する記録再生装置、記録再生方法及び当該記録再生装置又は記録再生方法により記録された記録媒体に関する。
【背景技術】
【０００２】
近年、動画情報や静止画情報、音声情報等のＡＶデータをデジタル化して記録・再生することが良く行われている。このようなデジタル情報を蓄積する記録媒体としては、フラッシュメモリ等の半導体メモリ、あるいはディスクメディアであるＤＶＤ、ハードディスク、ＭＤ（ミニディスク）等が存在する。
【０００３】
これらの記録媒体に対して、ＭＰＥＧ２やＪＰＥＧ等の符号化方式で符号化されたＡＶデータの記録や再生が行われている。かかるＡＶデータの記録において、各ＡＶデータはファイルシステムによりファイルとして管理されており、それぞれの再生に際してもファイル単位での指定が行われている。
【０００４】
そして、上述した半導体メディアやディスクメディアにおいては、ランダムアクセス性という優れた特徴が存在する。ランダムアクセス性を利用することにより、ユーザからの指示等に従って、記録済みのファイルを任意の順番で再生することが可能となる。
【０００５】
さらにそれを発展させた技術として、プログラム再生機能の実現が挙げられる。例えば、特開２００２−１９９３３５号公報に開示されている記録／再生システムにおいては、ＡＶデータをメディアオブジェクトと呼ぶファイルとして記録し、複数のメディアオブジェクトをプログラムと呼ばれるディレクトリの下に記録している。このような記録形態とすることによって、記録媒体上には当該プログラムを複数個作成することが可能となる。
【０００６】
また、各プログラムに対してプログラム情報（ＰＲＧ＿ＩＮＦＯ）と呼ばれる情報を管理し、メディアオブジェクトとは異なるファイルとして記録媒体上に記録する。ＰＲＧ＿ＩＮＦＯに登録されるメディアオブジェクトの情報を参照することにより、記録媒体上に記録されたＡＶファイルの再生順序を自由に制御することが可能となる。
【０００７】
上述したような機能は、一般に「プログラム再生」と呼ばれており、ディスクメディアにおけるランダムアクセス性を利用することにより実現されている。
【０００８】
このように、ＡＶデータをメディアオブジェクトとして記録し、そのメディアオブジェトを参照するプログラムもファイルとして記録する場合、当該プログラムファイルからメディアオブジェクトへの参照情報を持たなければならない。参照情報の形式は、ファイルに対するパス情報、すなわちファイルを管理するファイルシステム内で、当該ファイルの名前と階層位置を示す情報を用いるのが一般的である。
【０００９】
ここで、メディアオブジェクトとプログラムファイルとの関係の一例を図３０に示す。図３０は、メディアオブジェクトのディレクトリ構造と、プログラムファイルの構造の説明図である。
【００１０】
各プログラムファイル１０００２は、各メディアオブジェクト１０００１への参照を、ＲＯＯＴディレクトリ１００００からのフルパス名１０００３の形式で保持している。なお、図３０に例示したフルパス名においては、パス区切り文字は“／”として記述している。
【００１１】
上述したメディアオブジェクトやプログラムファイルは、全てＵＤＦやＦＡＴ等のファイルシステムを利用して管理される。ファイルシステムは、パーソナルコンピュータ（以下、「ＰＣ」という。）のアーキテクチャで一般的に利用され、ファイルシステムを導入することにより、上述のプログラムファイルを編集したり、再生したりするＰＣ上のアプリケーションソフトを作成することが容易となる。
【００１２】
図３０に示すように、プログラムファイル１０００２は、３つのメディアオブジェクト１０００１のプログラム再生を指示するものである。ここに示すように、複数のメディアオブジェクトがそれぞれ異なる親ディレクトリの下に記録されていてもプログラム再生を指示することが可能である。
【００１３】
また、半導体メディアやディスクメディアの異なる特徴として、データの追加と、それによる機能拡張の容易性が挙げられる。
【００１４】
特開２０００−５７７４５号公報や特開２００１−１６０２６９号公報の記録再生装置では、図３１に示すように、ＡＶデータであるビットストリームファイル１００１０と、それを管理する情報ファイル１００１１が存在する。この情報ファイル１００１１に新たなデータ（製造業体情報項目１００１２）を追加していくことにより、この記録再生装置に対する新たな機能の追加が可能となる。
【特許文献１】特開２００２−１９９３３５号公報
【特許文献２】特開２０００−５７７４５号公報
【特許文献３】特開２００１−１６０２６９号公報
【発明の開示】
【発明が解決しようとする課題】
【００１５】
しかし、上述した構成のようなプログラムファイルによるプログラム再生を実現するためには、それを処理する記録または再生装置などに、追加のハードウエア及びソフトウエア資源が要求される。
【００１６】
よって、ハードウエア及びソフトウエア資源が限られる記録／再生装置では、その実現が不可能な場合がある。
【００１７】
そのため、メディアオブジェクトの単純な記録及び再生に関しては基本機能としてすべての記録／再生機器で実現されることが想定されるが、上述のようなプログラム再生機能は拡張機能として位置づけられ、ある機器では処理可能であるが、別の機器では処理不可能となるような場合がありうる。
【００１８】
このような場合においても、ＤＶＤのようなディスクメディアは、一つのディスクメディアが複数の記録／再生機器で記録または再生がされる。
【００１９】
そのため、プログラム再生のような拡張機能に対応しない機器でディスクメディア上の情報を操作（メディアオブジェクトの編集や削除など）した場合、メディアオブジェクトの情報とプログラムファイルとの情報の間に不整合が発生してしまう。
【００２０】
そして、このような不整合状態にあるディスクメディアを、プログラム再生に対応した記録／再生機器で再生しようとすると、プログラムファイルで参照しているはずのメディアオブジェクトが存在しないので、場合によっては機器の誤動作の発生や、最悪の場合は動作が停止してしまう等、の不都合が生じる。
【００２１】
このような不都合を回避するためには、ある拡張機能に対応した記録／再生機器は、その拡張機能を使用する前に、拡張機能に関するデータの整合性をすべて確認する必要があるが、このデータの量が多くなる（例えばプログラムファイルの数が非常に多なる）と、その確認処理に時間がかかり、ユーザにとって非常に不便である。
【００２２】
また、特開２０００−５７７４５号公報及び特開２００１−１６０２６９号公報に記載されているような、情報ファイルに拡張機能のためのデータを追加していく構成においては、情報ファイルの容量増加が避けられない。
【００２３】
情報ファイルの基本的な部分は、すべての記録／再生装置で必要とされるが、拡張機能に関する部分は、その拡張機能に対応した機器にのみ必要なデータであり、拡張機能に対応しない機器にとっては無駄なデータであり、ハードウエア資源の浪費となってしまう。
【００２４】
本発明は、上述したような状況に鑑みてなされたものであり、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能とする記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体、並びに当該記録媒体を再生する再生装置及び再生方法を提供することを目的とする。
【課題を解決するための手段】
【００２５】
上記目的を達成するために本発明にかかる記録装置は、記録媒体に情報の記録を行う記録部と、前記情報を、パス名により参照可能なディレクトリ階層構造を有したファイルシステム情報を用いてファイルとして管理するファイルシステム処理部と、前記ディレクトリ及び前記ファイルを、コンテンツ管理情報を用いて管理するコンテンツ管理情報処理部と、前記ディレクトリ及び前記ファイルに対する拡張情報を管理する拡張情報処理部と、を備えた記録装置であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが、前記オブジェクト参照情報を経由して対応付けられていることを特徴とする。
【００２６】
また、本発明にかかる記録装置は、前記拡張オブジェクト管理情報に、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性に関する状態を管理する整合性状態管理情報を含み、前記ディレクトリ及び前記ファイルに対する操作を行う時、処理可能な種類の前記拡張情報については、前記拡張情報を更新し、処理不可能な種類の前記拡張情報については、前記拡張情報を更新せず、前記ディレクトリ及び前記ファイルと、前記拡張情報との整合性の状態に応じて前記整合性状態管理情報を更新することが好ましい。
【００２７】
また、本発明にかかる記録装置は、前記整合性状態管理情報が、前記メディアオブジェクト管理情報毎に設けられ、前記拡張情報の種別毎に、少なくとも、前記拡張情報から前記ディレクトリ及び前記ファイルへの参照関係の有無を示す情報と、前記ディレクトリ及び前記ファイルと、それに対する前記拡張情報との整合性が保証されているか否かを示す情報を含むことが好ましい。
【００２８】
また、本発明にかかる記録装置は、前記コンテンツ管理情報に、第１の更新日時情報を含み、前記拡張情報には、第２の更新日時情報を含み、前記メディアオブジェクト管理情報を更新した時、前記第１の更新日時情報を更新し、処理可能な種類の前記拡張情報については、前記第２の更新日時情報に前記第１の更新日時情報と同じ値を設定し、処理不可能な種類の前記拡張情報については、前記第２の更新日時情報を更新しないことが好ましい。
【００２９】
また、本発明にかかる第１の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定することを特徴とする。
【００３０】
また、本発明にかかる第２の再生装置は、上述した記録装置により記録された記録媒体から情報の再生を行う再生装置であって、前記情報を前記記録媒体から再生する再生部と、前記ファイルシステム情報を処理するファイルシステム処理部と、前記拡張情報を処理する拡張情報処理部と、前記コンテンツ管理情報を処理するコンテンツ管理情報処理部とを備え、前記拡張情報処理部は、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する時、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定することを特徴とする。
【００３１】
かかる構成により、拡張機能のためのデータ追加を効率的に行え、なおかつ、拡張機能に対応していない機器がメディアオブジェクトの編集や削除を行った場合にも、データ間の不整合を最小限に抑制し、適切なデータ処理方法を決定可能となる。
【００３２】
また、本発明の他の側面は、記録媒体への情報の記録方法である。この記録方法は、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを備えた記録方法であって、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記記録方法は、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を含むことを特徴とする。
【００３３】
また、本発明のさらに他の側面は、記録媒体からの情報の再生方法である。第１の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を含むことを特徴とする。第２の再生方法は、情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを備え、前記拡張情報処理工程が、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を含む。
【００３４】
また、本発明のさらに他の側面は記録媒体である。この記録媒体は、情報が記録された記録媒体であって、前記情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とが記録されており、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
【００３５】
また、本発明のさらに他の側面は、記録媒体へ情報の記録を行う記録装置において、当該記録装置の記録動作を制御するプログラムである。このプログラムは、記録媒体に、コンテンツ情報を、パス名により参照可能なディレクトリ階層構造を有するファイルシステム情報を用いて、ファイルとして記録する工程と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報を前記記録媒体へ記録する工程と、前記ディレクトリ及び前記ファイルに対する拡張情報を前記記録媒体へ記録する工程とを前記記録装置に実行させる命令を含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記プログラムは、前記ディレクトリ及び前記ファイルと前記拡張情報とを前記オブジェクト情報を経由して対応付ける工程を前記記録装置に実行させる命令をさらに含むことを特徴とする。
【００３６】
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記整合性状態管理情報の設定値に従って前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
【００３７】
また、本発明のさらに他の側面は、記録媒体から情報の再生を行う再生装置において、当該再生装置の再生動作を制御するプログラムである。このプログラムは、前記情報を前記記録媒体から再生する工程と、前記ファイルシステム情報を処理する工程と、前記拡張情報を処理する工程と、前記コンテンツ管理情報を処理する工程とを前記再生装置に実行させる命令を含むと共に、前記拡張情報処理工程において、前記ディレクトリ及び前記ファイルに対応する前記拡張情報を処理する前に、前記第１の更新日時情報と前記第２の更新日時情報とが一致するかどうかで、前記拡張情報に対する処理手順を決定する工程を前記再生装置に実行させる命令を含むことを特徴とする。
【００３８】
また、本発明のさらに他の側面は、上述のプログラムを、コンピュータによる読み取りが可能な媒体に記録したプログラム提供媒体（プログラム製品）である。
【００３９】
また、本発明のさらに他の側面は、記録媒体に記録されたデータ構造である。このデータ構造は、記録媒体に記録されたコンテンツ情報をパス名により参照可能なディレクトリ階層構造として管理するファイルシステム情報と、前記ディレクトリ及び前記ファイルを管理するコンテンツ管理情報と、前記ディレクトリ及び前記ファイルに対する拡張情報とを含み、前記コンテンツ管理情報は、前記パス名を変換して得られるオブジェクト参照情報により前記ディレクトリ及び前記ファイルを参照するメディアオブジェクト管理情報と、前記拡張情報を管理する拡張オブジェクト管理情報とを含み、前記ディレクトリ及び前記ファイルと前記拡張情報とが前記オブジェクト情報を経由して対応付けられていることを特徴とする。
【発明を実施するための最良の形態】
【００４０】
以下、本発明の実施の形態にかかる記録装置、記録方法及び当該記録装置又は記録方法により記録された記録媒体、並びに再生装置、再生方法について、図面を参照しながら説明する。
【００４１】
（実施の形態１）
図１は、本発明の実施の形態１にかかる記録再生装置の一例である、ＤＶＤレコーダの外観と、関連機器とのインタフェースを説明するための図である。図１に示すように、本発明にかかる記録再生装置の一実施形態としてのＤＶＤレコーダ１は、記録媒体であるディスクメディアとしてＤＶＤディスク２が装填され、ビデオ情報等の記録再生が行なわれる。ＤＶＤレコーダ１の操作は、一般的にはリモートコントローラ３や機器上のスイッチ（図示せず）によって行なわれる。
【００４２】
ＤＶＤレコーダ１に入力されるビデオ情報には、アナログ信号とデジタル信号の両者があり、アナログ信号としてはアナログ放送が、デジタル信号としてはデジタル放送がある。一般的に、アナログ放送は、テレビジョン装置４に内蔵されている受信機により受信、復調され、ＮＴＳＣ方式等のアナログビデオ信号としてＤＶＤレコーダ１に入力される。
【００４３】
また、デジタル放送は、受信機であるセットトップボックス（ＳＴＢ）５でデジタル信号に復調され、ＤＶＤレコーダ１に入力され記録される。
【００４４】
一方、ビデオ情報が記録されたＤＶＤディスク２は、ＤＶＤレコーダ１により再生され外部に出力される。出力される信号も入力される信号と同様に、アナログ信号とデジタル信号の両者があり、アナログ信号であれば直接テレビジョン装置４に入力され、デジタル信号であればＳＴＢ５を経由し、アナログ信号に変換された後にテレビジョン装置４に入力され、テレビジョン（ＴＶ）で映像として表示される。
【００４５】
さらに、本発明にかかる記録再生装置の他の実施形態として、ＤＶＤディスク２を利用する装置にＤＶＤビデオカメラ６がある。ＤＶＤビデオカメラ６は、ＤＶＤレコーダにレンズやＣＣＤからなるカメラ装置を組み合わせた装置であり、撮影した動画情報を符号化して記録する。
【００４６】
また、ＤＶＤディスク２は、ＤＶＤレコーダ１やＤＶＤビデオカメラ６以外に、ＰＣ７等でビデオ情報が記録再生される場合もある。ＰＣ７等でビデオ情報が記録されたＤＶＤディスク２であっても、ＤＶＤレコーダに装填されれば、ＤＶＤレコーダは当該ＤＶＤディスクを再生する。
【００４７】
なお、上述したアナログ放送やデジタル放送のビデオ情報には、通常、音声情報が付随している。付随している音声情報もビデオ情報と同様に、ＤＶＤレコーダで記録再生される。
【００４８】
また、ビデオ情報は、動画の他に、静止画の場合もある。例えば、ＤＶＤビデオカメラ６の写真機能で静止画が記録されたり、ＰＣ７上で他の記録装置（ハードディスク）等から静止画がＤＶＤディスク２へコピーされたりする場合が該当する。
【００４９】
なお、ＤＶＤレコーダとＳＴＢ５等の外部機器との間のデジタルインタフェースとしては様々なインタフェースが考えられる。例えば、ＩＥＥＥ１３９４、ＡＴＡＰＩ、ＳＣＳＩ、ＵＳＢ、等である。
【００５０】
また、上記では、ＤＶＤレコーダ１とテレビジョン（ＴＶ）４との間の信号として、ＮＴＳＣ方式のアナログ（コンポジット）ビデオ信号を用いる場合について例示したが、輝度信号と色差信号を個別に伝送するコンポーネント信号であってもよい。
【００５１】
さらには、ＡＶ機器とテレビジョンの間の映像伝送インタフェースとしては、アナログインタフェースをデジタルインタフェース、例えば、ＤＶＩに置きかえる研究開発が進められており、ＤＶＤレコーダとテレビジョンがデジタルインタフェースで接続されることも当然予想される。
【００５２】
このようなＤＶＤレコーダ１やＤＶＤビデオカメラ６等の記録再生装置において、記録媒体であるディスクメディア２は、複数の記録再生装置上で記録・再生される。この時の記録装置は同一の製造メーカの場合もあるし、異なる製造メーカによる記録装置の場合もあり得る。
【００５３】
様々な記録再生装置における記録・再生の互換性確保のため、記録媒体における記録フォーマットやファイルフォーマットの規格化・標準化が行われるのが一般的である。例えば、ＤＶＤ−Ｖｉｄｅｏ  Ｒｅｃｏｒｄｉｎｇ規格等、様々な統一規格が策定されている。
【００５４】
記録再生装置の製造メーカは、ユーザの利便性に配慮して、統一規格に準拠した記録再生装置の製品化を行う。
【００５５】
その一方で、各製造メーカは、他社製品との差別化を図るべく、独自の拡張機能を自社製品に盛り込んで記録再生装置を製品化する場合が多く見られる。この拡張機能とは、統一規格には含まれておらず、各製造メーカが、その内容を独自に設けるさまざまな機能である。拡張機能の実現のために、図１には示していない追加のハードウエアやソフトウエア、周辺機器が必要に応じて記録再生装置に設けられる場合がある。例えば、位置情報を取得するＧＰＳレシーバ、等である。
【００５６】
図２は、本実施の形態１にかかる記録再生装置に組み込まれるドライブ装置１１０とその周辺の概略構成を示すブロック図である。図２において、ドライブ装置１１０は、記録媒体に対して情報の記録再生を行う光ピックアップ１０１と、ＥＣＣ（Ｅｒｒｏｒ  Ｃｏｒｒｅｃｔｉｎｇ  Ｃｏｄｅ）処理部１０２を備え、例えばＤＶＤディスクのような記録媒体であるディスクメディア１００に対してデータの記録及び再生を行う。
【００５７】
ディスクメディア１００には、セクタと呼ばれる最小単位でデータが記録される。また、複数のセクタで一つのＥＣＣブロックを構成し、ＥＣＣブロックを１単位としてＥＣＣ処理部１０２でエラー訂正処理が施される。なお、ＥＣＣブロックはＥＣＣクラスタと呼ばれることもある。
【００５８】
ディスクメディア１００の一例であるＤＶＤ−ＲＡＭディスクの場合、セクタのサイズは２ＫＢであり、１６セクタを１ＥＣＣブロックとして構成されている。当該セクタサイズは、ディスクメディア１００の種類に応じて変動するものであり、１セクタは５１２Ｂ（バイト）であっても良いし、８ＫＢ等であっても良い。
【００５９】
また、ＥＣＣブロックについても、１セクタを１ＥＣＣブロックとして構成しても良いし、１６セクタを、あるいは３２セクタ等を１ＥＣＣブロックとして構成しても良い。今後、記録できる情報容量の増大に伴い、セクタサイズ及びＥＣＣブロックを構成するセクタ数は増大するものと予想される。
【００６０】
また、ドライブ装置１１０は、トラックバッファ１０３と接続されており、トラックバッファ１０３は、システムバス１０５を経由して記録再生装置のシステム全体を制御するシステム制御部１０４と接続されている。
【００６１】
トラックバッファ１０３は、ディスクメディア１００にＡＶデータをより効率良く記録するため、ＡＶデータを可変ビットレート（ＶＢＲ）で記録するためのバッファである。ディスクメディア１００への読み書きレート（Ｖａ）が固定レートであるのに対して、ＡＶデータはその内容（ビデオであれば画像）の持つ複雑さに応じてビットレート（Ｖｂ）が変化する。トラックバッファ１０３は、このビットレートの差を吸収するためのバッファである。
【００６２】
図３は、ドライブ装置１１０を含む、本実施の形態１にかかる記録再生装置のブロック構成図である。図３に示すように、本実施の形態１にかかる記録再生装置は、システム全体の管理及び制御を司るシステム制御部１０４、ユーザへの表示及びユーザからの要求を受け付けるユーザＩ／Ｆ（インタフェース）部２００、ＶＨＦ及びＵＨＦを受信するアナログ放送チューナ２１０、映像をＡＶ信号へ変換するカメラ部２１１、デジタル放送を受信するデジタル放送チューナ２１２、ＡＶ信号入力をデジタル信号に変換し、ＭＰＥＧプログラムストリーム等にエンコードする動画エンコーダ２２１、ＡＶ信号入力をＪＰＥＧストリーム等にエンコードする静止画エンコーダ２２２、デジタル放送で送られるＭＰＥＧトランスポートストリームを解析する解析部２２３、ＭＰＥＧ等の動画データをデコードする動画デコーダ２４０、静止画データをデコードする静止画デコーダ２４１、テレビ及びスピーカ等の表示部２５０、等を備えている。
【００６３】
動画エンコーダ２２１、静止画エンコーダ２２２や解析部２２３には、ＡＶデータの入力源として、アナログ放送チューナ２１０、カメラ部２１１、デジタル放送チューナ２１２等が接続されている。
【００６４】
なお、上述したエンコーダやチューナ、カメラ部については、全てを同時に備える必要はなく、記録再生装置の使用目的に応じて必要なものだけを備えれば良い。例えば、記録再生装置がＤＶＤ等の光ディスク用レコーダの場合であれば、図４に示すように、図３に示した構成のうち、カメラ部２１１を省いた構成としても良い。また、記録再生装置がビデオカメラの場合であれば、図５に示すように、図３に示した構成のうち、アナログ放送チューナ２１０およびデジタル放送チューナ２１２を省き、集音用のマイク部２６１をさらに備えた構成としても良い。また、記録再生装置がパーソナルコンピュータの場合であれば、図４と同様の構成としても良い。あるいは、図６に示すように、図３に示した構成のうち、アナログ放送チューナ２１０、カメラ部２１１、およびデジタル放送チューナ２１２を省いた構成としても良い。
【００６５】
さらに、図３に示す記録再生装置は、図２で示したように、書き込みデータを一時的に格納するトラックバッファ１０３と、ディスクメディア１００にデータを書き込むドライブ装置１１０とを備えている。
【００６６】
また、ＩＥＥＥ１３９４やＵＳＢ等の通信手段により外部機器にデータを出力するインタフェースであるデジタルＩ／Ｆ（インタフェース）部２３０を備えても良い。
【００６７】
なお、本実施の形態１にかかる記録再生装置の詳しい動作については後ほど説明を行う。
【００６８】
次に、図７は、本実施の形態１にかかる記録再生装置において記録可能なディスクメディア１００の外観と物理構造を表した図である。なお、例えばＤＶＤ−ＲＡＭのようなディスクメディアは、記録面を保護するのを目的として、カートリッジに収納された状態で記録再生装置に装填される。ただし、記録面の保護が別の構成で行なわれたり、容認できる場合にはカートリッジに収納せずに、記録再生装置に直接装填できるようにしてもよい。
【００６９】
図７（ａ）は、記録可能なディスクメディア１００の記録領域の一例を示した図である。図７（ａ）の例では、最内周にリードイン領域１４１が、最外周にリードアウト領域１４２が、その間にデータ領域１４３が配置されている。リードイン領域１４１は、光ピックアップ１０１がディスクメディア１００へアクセスする時に、サーボを安定させるために必要な基準信号や他のメディアとの識別信号等が記録されている。リードアウト領域１４２もリードイン領域１４１と同様の基準信号等が記録されている。またデータ領域１４３は、最小のアクセス単位であるセクタに分割されている。
【００７０】
図７（ｂ）は、図７（ａ）において同心円状に示されているリードイン領域１４１と、リードアウト領域１４２と、データ領域１４３を横方向に配置した説明図である。
【００７１】
リードイン領域１４１とリードアウト領域１４２は、その内部に欠陥管理領域（ＤＭＡ：Ｄｅｆｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ａｒｅａ）１４４，１４７を有する。欠陥管理領域とは、欠陥が生じたセクタの位置を示す位置情報と、その欠陥セクタを交替するセクタが後述する交替領域のいずれに存在するかを示す交替位置情報とが記録されている領域をいう。
【００７２】
また、データ領域１４３は、その内部に交替領域１４５とユーザ領域１４６を有している。交替領域１４５は、欠陥セクタが存在する場合に代替セクタとして使用される領域である。ユーザ領域１４６は、ファイルシステムが記録用領域として利用することができる領域をいう。なお、ディスクメディアの種類によっては交替領域を持たないディスクメディアも存在し、この場合、必要に応じて、後述するＵＤＦ等のファイルシステムにおいて、欠陥セクタの交替処理を行う場合もある。
【００７３】
データ領域１４３にある各セクタへアクセスするため、内周から順に物理セクタ番号（ＰＳＮ：Ｐｈｙｓｉｃａｌ  Ｓｅｃｔｏｒ  Ｎｕｍｂｅｒ）をデータ領域へ割り当てることが一般に行われている。ＰＳＮによって管理されるセクタを物理セクタと呼ぶ。
【００７４】
また、データ記録に使用されるセクタのみを連続的に示すように、内周から順に論理セクタ番号ＬＳＮ（Ｌｏｇｉｃａｌ  Ｓｅｃｔｏｒ  Ｎｕｍｂｅｒ）をユーザ領域の物理セクタに割り当てることも行われる。ＬＳＮによって管理されるセクタを論理セクタと呼ぶ。
【００７５】
図７（ｃ）は、図７（ｂ）のユーザ領域１４６内で、論理セクタにより構成される論理的なデータ空間を示す図である。論理的なデータ空間は、ボリューム空間と呼称され、ユーザデータを記録する。ボリューム空間においては、記録データをファイルシステムで管理する。
【００７６】
ＤＶＤ−ＲＡＭ等のディスクメディアでは、ファイルシステムは、ＵＤＦと呼称され、ＥＣＭＡ１６７及びＩＳＯ１３３４６規格に準拠したものが一般的に使用される。
【００７７】
ＵＤＦのパーティション空間２９２では、データアクセスの単位ごとに論理ブロック番号ＬＢＮ（Ｌｏｇｉｃａｌ  Ｂｌｏｃｋ  Ｎｕｍｂｅｒ）が割り当てられ、データの配置や管理が行われる。
【００７８】
データの配置のために、パーティション空間２９２で連続的に配置される１群のセクタはエクステントと呼ばれる単位で管理され、さらに関連のあるエクステントの集合がファイルとして管理される。
【００７９】
エクステント及びエクステントの集合であるファイルを管理する情報制御ブロック（ＩＣＢ）であるファイルエントリ（ＦＥ）及び拡張ファイルエントリ（ＥＦＥ）と呼ばれる構造、さらには１群のファイルをディレクトリとして管理するための情報であるファイル識別記述子（ＦＩＤ）等がボリューム空間内のパーティション空間内に記録される。
【００８０】
そして、パーティション空間等を管理するためのボリューム構造情報２９０（及びそのバックアップである２９１）が、ボリューム領域の先頭と終端に記録される。
【００８１】
図８は、本発明の実施の形態１にかかる記録再生装置により記録されるディスクメディア１００におけるディレクトリとファイルの階層構造の一例を示す図である。図８に示すように、ＲＯＯＴディレクトリ３００の下に、階層化されたサブディレクトリ（３０１〜３０５等）があり、さらにその階層下に、動画データや静止画データを含むファイルである各種メディアオブジェクト（３１０〜３１３等）や、各メディアオブジェクトを管理するためのファイルであるメディアオブジェクトマネージャ３２０（ファイル名：ＭＯＩ＿ＭＧＲ）や、複数のメディアオブジェクトをグループ化し、再生順序や分類情報を管理するプログラムマネージャ３３０（ファイル名：ＰＲＧＭ０００１．ＥＸＴ）等が格納されている。
【００８２】
ここでプログラムマネージャ３３０は拡張情報を格納する拡張オブジェクトの一種であり、プログラム再生機能に対応した記録再生装置がその記録及び再生等の処理を行う。
【００８３】
なお、本実施の形態においてはメディアオブジェクトマネージャ３２０の構造や機能は統一規格の一種であるとし、全ての本発明の記録再生装置において記録や再生が保証されるものとする。
【００８４】
また、拡張情報とは、統一規格に含まれない拡張機能を製造メーカが独自に実現する上で必要な様々な情報のことである。拡張情報は拡張オブジェクトと呼ばれるファイルに格納されてディスクメディア１００に記録される。上述の、プログラム再生機能は拡張機能の一例である。
【００８５】
本実施の形態１においては、記録及び再生用の対象となるＡＶデータを含む各種メディアオブジェクトのディレクトリ階層やファイル名は、後述するＤＣＦ規格及びそれに類した形式を利用して以降の説明を行う。ただし、ディレクトリ階層やファイル名の命名則はこれに限られるものではなく、他の命名則を用いても良い。
【００８６】
メディアオブジェクトのうち、ＭＰＥＧ２等の動画データを含む動画オブジェクトは、ＡＢＣＤｎｎｎｎ．ＭＰＧというように、最初の４文字が任意のアルファベット文字の組み合わせであり、次のｎｎｎｎが１０進数であるような命名側に従って動画ファイルとして記録される。動画ファイルは、ＭＰＥＧ２方式やＭＰＥＧ４方式等で圧縮されたＡＶデータを含んでおり、プログラムストリーム（ＰＳ）や、トランスポートストリーム（ＴＳ）、あるいは他の形式のファイルとして記録される。
【００８７】
また、各々の動画ファイルに関する属性情報は、属性情報ファイル（ファイル名：ＡＢＣＤｎｎｎｎ．ＭＯＩ）に記録される。属性情報ファイルには、それぞれの動画ファイルの識別情報、記録された日時、動画データの代表画像（サムネイルピクチャ）、動画データの再生時刻をディスクメディア１００上の論理アドレスに変換するためのアクセスマップ情報及びその管理情報、等を有している。アクセスマップ情報を持つことにより、動画データの持つ時間軸とデータ（ビット列）軸との間の変換を行うことが可能となり、動画データに対する時間軸を基準にしたランダムアクセスが可能となる。
【００８８】
属性情報ファイルは、例えばＡｐｐｌｅ社のＱｕｉｃｋＴｉｍｅファイルフォーマットに準拠する形式でもよい。ＱｕｉｃｋＴｉｍｅファイルフォーマットでは、前記属性情報は、ムービーリソース（ｍｏｖｉｅ  ｒｅｓｏｕｒｃｅ）と呼ばれる。また同様に、前記アクセスマップ情報は、サンプルテーブル（Ｓａｍｐｌｅ  Ｔａｂｌｅ）と呼ばれる。
【００８９】
一つの動画オブジェクトは、一つの属性情報ファイルと一つ又はそれ以上の動画ファイルとで構成され、それらはファイル名により関連づけられるものとする。すなわち、関連のある属性情報ファイルと動画ファイルは、そのファイル名において拡張子を除く部分、例えば動画オブジェクト３１０では、動画ファイル３１１と属性情報ファイル３１２が“ＡＢＣＤ０００１”の部分が同一に設定されることによって、その関連付けがなされていることとする。
【００９０】
ただし、属性情報ファイルと動画ファイルの関連付けは上述の方法に限定されるものではなく、属性情報ファイル内に関連付けられた動画ファイルへのリンク情報、例えば動画ファイルへのパス名等を保持したり、両者の対応付けをテーブル情報として保持したりする等、他の方法であっても良い。なお、一つの動画オブジェクトに、一つの属性情報ファイルと一つ又はそれ以上の動画ファイル以外を含むようにしてもよい。また、属性情報ファイルと動画ファイルを一体として、１つのファイルで動画オブジェクトを構成するようにしてもよい。
【００９１】
メディアオブジェクトのうち、ＪＰＥＧ等の静止画データを含む静止画オブジェクトは、各々の静止画情報が静止画ファイル（ファイル名：ＡＢＣＤｎｎｎｎ．ＪＰＧ）等として記録される。静止画ファイルは、ＪＰＥＧ方式等で圧縮された映像データであり、例えば、ＤＣＦフォーマットやＥｘｉｆフォーマットによりファイルとして記録される。
【００９２】
上記のメディアオブジェクトは、ＤＣＦ規格あるいはそれに類するディレクトリ構造にしたがって記録される。すなわち、ＲＯＯＴディレクトリ３００の下にＤＣＦイメージルートディレクトリ３０２（ディレクトリ名：ＤＣＩＭ）があり、さらにその下に静止画ファイルを格納するためのＤＣＦディレクトリ３０５がある。（ディレクトリ名：３００ＡＢＣＤＥ）。そして、ＤＣＦディレクトリ３０５の下に静止画オブジェクトの一種であるＤＣＦ基本ファイル３１３（例えば、ファイル名：ＡＢＣＤ０００１．ＪＰＧ）が格納される。
【００９３】
また、ＲＯＯＴディレクトリ３００の下にＶＩＤＥＯイメージルートディレクトリ３０１（ディレクトリ名：ＶＩＤＥＯ）があり、さらにその下に、主に動画オブジェクトを格納するためのＶＩＤＥＯディレクトリ３０４がある。（例えば、ディレクトリ名：１００ＡＢＣＤＥ）。そして、ＶＩＤＥＯディレクトリ３０４下に、動画オブジェクト３１０を構成する属性情報ファイル３１２（拡張子がＭＯＩであるファイル）と動画ファイル３１１（拡張子がＭＰＧであるファイル）が格納される。
【００９４】
なお、メディアオブジェクトとして、ＡＣ−３やＡＡＣ等による圧縮音声ファイルや非圧縮の音声ファイル、ＭｏｔｉｏｎＪＰＥＧファイル、ＤＣＦ規格で定められたＤＣＦ拡張画像ファイル、ＤＣＦサムネイルファイル、ＰＮＧファイル等、他のファイルフォーマットのＡＶファイルを記録してもよい。
【００９５】
記録されたメディアオブジェクトを管理するコンテンツ管理情報は、管理データディレクトリ３０３（ディレクトリ名：ＩＮＦＯ）下のメディアオブジェクトマネージャファイル３２０として記録される。
【００９６】
また、メディアオブジェクトに対して拡張情報を付加する拡張オブジェクトも管理データディレクトリ３０３に記録される。図８では、拡張オブジェクトの例として、プログラムマネージャファイル３３０が記録されている。なお、メディアオブジェクトマネージャファイル３２０及び拡張オブジェクトの記録位置は管理データディレクトリ３０３下に限られるものではなく、例えば、ＶＩＤＥＯイメージルートディレクトリ３０１下、等でもよい。メディアオブジェクトマネージャファイル３２０及びプログラムマネージャファイル３３０の構造については後述する。
【００９７】
次に、図９、図１０及び図１１を用いて、本実施の形態１にかかる記録再生装置で用いられるディスクメディア上でデータをファイルとして管理する、ＵＤＦファイルシステムの構造を説明する。
【００９８】
図９は、ＵＤＦファイルシステムにおけるディレクトリ階層を管理するためのデータ構造を示す図である。なお、図９は、図８に示したディレクトリ階層構造に対応しているが、そのうちＲＯＯＴディレクトリ３００から属性情報ファイル３１２へ至るまでのファイルシステム情報のみを示しており、他のディレクトリやファイルに対する同様の情報については、説明を簡単にするため省略している。
【００９９】
ディレクトリ階層構造の起点はファイルセットディスクリプタ（ＦＳＤ：Ｆｉｌｅ  Ｓｅｔ  Ｄｅｓｃｒｉｐｔｏｒ）４００である。ＦＳＤ４００は、図１０（ａ）に示されるデータ構造を有している。ＦＳＤ４００は、拡張ファイルエントリ（ＥＦＥ：Ｅｘｔｅｎｄｅｄ  Ｆｉｌｅ  Ｅｎｔｒｙ）５１０への参照情報４０１（ディスクメディア１００上での記録位置）をＲｏｏｔ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５０１の値として保持している。また、ＦＳＤ４００は、Ｓｙｓｔｅｍ  Ｓｔｒｅａｍ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５０２からＮａｍｅｄ  Ｓｔｒｅａｍと呼ばれるデータを参照可能である。
【０１００】
Ｒｏｏｔ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５０１及びＳｙｓｔｅｍ  Ｓｔｒｅａｍ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５０２は、図１０（ｂ）に示すｌｏｎｇ＿ａｄ５０３という構造を持つ。ｌｏｎｇ＿ａｄ５０３は、参照先のエクステントの長さ（Ｅｘｔｅｎｔ  Ｌｅｎｇｔｈ）と、位置（Ｅｘｔｅｎｔ  Ｌｏｃａｔｉｏｎ）を保持する。さらに、Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ５０４には、図１０（ｃ）に示すＡＤＩｍｐＵｓｅの形式によりＵＤＦ  ＵｎｉｑｕｅＩＤ５０５と呼ばれる値が保持される。
【０１０１】
また、ＥＦＥ５１０は、図１１（ａ）に示される構造を有している。ＥＦＥ５１０は、ディスクメディア１００上に記録された各ディレクトリやファイルを構成するエクステントの集合を管理するための構造体であり、各エクステントのディスクメディア１００上での記録位置とデータ長を管理するため、図１１（ｂ）に示す構造を有するアロケーション記述子（ＡＤ：Ａｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒ）５１４と呼ばれる構造を含んでいる。各ディレクトリやファイルは複数のエクステントから構成されるので、ＥＦＥ５１０には複数のＡＤ５１４が含まれる。
【０１０２】
その他にも、ＥＦＥ５１０には、図１１（ａ）に示すように、データの種別を表すディスクリプタタグ（Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｇ）や、各ディレクトリやファイルごとに、ディスクメディア１００上で重複しない一意のＩＤ値を設定するＵｎｉｑｕｅ  ＩＤ５１１、ＥＦＥ５１０ごとの拡張属性を設定可能なＳｔｒｅａｍ  Ｄｉｒｅｃｔｏｒｙ  ＩＣＢ５１２や、拡張属性（ＥＡｓ；  Ｅｘｔｅｎｄｅｄ  Ａｔｔｒｉｂｕｔｅｓ）５１３等が含まれる。
【０１０３】
ＥＡｓ５１３は、ＵＤＦファイルシステムで規定される拡張属性を格納するための領域であり、ＥＣＭＡ１６７規格等で定められた拡張属性データや、様々なアプリケーションシステム等が必要に応じて使用できる。ＥＡｓ５１３中には、属性タイプ（Ａｔｔｒｉｂｕｔｅ  Ｔｙｐｅ）や属性サブタイプ（Ａｔｔｒｉｂｕｔｅ  Ｓｕｂｔｙｐｅ）と呼ばれるフィールドが存在し、ここに適切な値を設定することにより、この拡張属性中に含まれるデータの種別を識別できるようになっている。特定の属性タイプや属性サブタイプの値とそれに対応するデータ構造がＥＣＭＡ１６７規格等ですでに定義されている。
【０１０４】
図１２（ａ）に、ＥＡｓ５１３に含まれる拡張属性データの一種で、任意のアプリケーションシステムが使用可能な処理システム用拡張属性（Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ  Ｅｘｔｅｎｄｅｄ  Ａｔｔｒｉｂｕｔｅ）５３０と呼ばれる構造を示す。
【０１０５】
アプリケーションシステムがこの処理システム用拡張属性５３０を使用する時には、Ａｔｔｒｉｂｕｔｅ  Ｔｙｐｅ、Ａｔｔｒｉｂｕｔｅ  Ｓｕｂｔｙｐｅ及びＩｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｉｄｅｎｔｉｆｉｅｒの各フィールドに適切な値を設定することにより、処理システム用拡張属性５３０中に含まれる拡張属性が、どんなアプリケーションシステムにより使用されるかを識別できるようになっている。
【０１０６】
そして、実際の拡張属性の値は、Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ  Ｌｅｎｇｔｈ（ＩＵ＿Ｌ）でデータ長が示される可変長のフィールドＩｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ５３１中に格納される。Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ５３１中に格納される拡張属性のデータ構造は、それを使用するアプリケーションごとに決められる。
【０１０７】
本実施の形態においてＩｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ５３１中に格納される拡張属性のデータの一例として、Ｍｅｄｉａ  Ｏｂｊｅｃｔ  Ｍａｎａｇｅｍｅｎｔ  Ｉｎｆｏｒｍａｔｉｏｎ５４０の構造を、図１２（ｂ）に示す。ここでは、Ｍｏ（Ｍｅｄｉａ  Ｏｂｊｅｃｔ）  Ｕｎｉｑｕｅ  ＩＤ５４１というフィールドが設けられている。本フィールドの利用例については後述する。
【０１０８】
ＲＯＯＴディレクトリ３００等のディレクトリデータを含むエクステント４２０（図９（ａ）参照）は、各ディレクトリやファイルのファイル名を保持するファイル識別記述子ＦＩＤ（Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ  Ｄｅｓｃｒｉｐｔｏｒ）５２０で構成される。あるディレクトリ下にサブディレクトリやファイルが存在する場合、それぞれのディレクトリ又はファイルに対してＦＩＤ５２０が保持される。
【０１０９】
例えば、図８によれば、ＲＯＯＴディレクトリ３００の下にはＶＩＤＥＯイメージルートディレクトリ３０１とＤＣＩＭイメージルートディレクトリ３０２があるので、図９（ａ）に示すように、ＲＯＯＴディレクトリ３００のエクステント４２０には、各々に対応するＦＩＤ４２１及び４２２が保持されている。
【０１１０】
ＦＩＤ５２０は、図１１（ｃ）に示される構造を持つ。ＦＩＤ５２０は、ＵＤＦ上で管理される各ディレクトリやファイルの名前（ファイル識別子）をファイル識別子（Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ）５２１として保持する。ＦＩＤ５２０はさらに、対応するディレクトリ又はファイルの実データを管理するＥＦＥ５１０への参照情報（例えば図９（ａ）の４３０）を、ＩＣＢ５２２として保持する。
【０１１１】
そのほかにも、ＦＩＤ５２０には、データの種別を表すディスクリプタタグ（Ｄｅｓｃｒｉｐｔｏｒ  Ｔａｇ）や、ファイル識別子５２１のデータ長を表すファイル識別子長さ（Ｌｅｎｇｔｈ  ｏｆ  Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒ）等が含まれる。
【０１１２】
以降、同様にＥＦＥ５１０とＦＩＤ５２０の参照関係を保持することによりディレクトリの階層構造が管理され、この参照関係を順次たどることによって、任意のディレクトリやファイルの実データであるエクステントへアクセスすることが可能となる。
【０１１３】
ファイルに関しても、ＥＦＥ５１０によりエクステントの集合が管理される。図９の場合、エクステントの集合４４２がファイルを構成し、これは図８における属性情報ファイル３１２に相当する。
【０１１４】
上記のＦＳＤ４００やＥＦＥ５１０、ＦＩＤ５２０は、パーティション空間２９２内に配置される。図９（ｂ）は、図９（ａ）のデータ構造のパーティション空間内での配置の例示図である。ここで、図９（ａ）と図９（ｂ）で同じデータに関しては同じ番号を付与している。
【０１１５】
エクステント４４２へアクセスするためには、ＦＳＤ４００から順にＥＦＥ５１０、ＦＩＤ５２０、・・・、ＥＦＥ４４０のように、順次、データへアクセスする。
【０１１６】
上述のような階層構造を持ったファイルシステムにおいて、特定のディレクトリやファイルを参照するために、パス名が利用できる。パス名は、例えば、図９のエクステント４４２（ファイル名：ＡＢＣＤ０００１．ＭＯＩ）に対しては、“／ＶＩＤＥＯ／１００ＡＢＣＤＥ／ＡＢＣＤ０００１．ＭＯＩ”のように表される。ここでは、ＲＯＯＴディレクトリ３００及びパス区切り文字を“／”で表している。
【０１１７】
このように、パス名は、ＲＯＯＴディレクトリ３００から、対象のディレクトリやファイルにたどり着くまでディレクトリ階層をたどっていく時、その経路上に存在するディレクトリの名前（ファイル識別子５２１に格納されている情報）を、パス区切り文字で区切りながら一続きに記述したものである。このパス名を利用すれば、ファイルシステム上で管理される任意のディレクトリやファイルを参照することが可能となる。
【０１１８】
次に、ディスクメディア１００へ記録を行なう、本実施の形態にかかる記録再生装置の動作について説明する。
【０１１９】
まず、図１３を用いて、ディスクメディア１００上でのＡＶデータの分散配置について説明する。すなわち、図２に示すようなシステムにおいて、トラックバッファ１０３を有効利用することによって、ＡＶデータを離散配置することが可能になる。
【０１２０】
図１３（ａ）は、ディスクメディア１００上のアドレス空間を示す図である。図１３（ａ）においては、左端がアドレス値が０の点であり、右に向かってアドレス値が増加していくものとしている。また、“０”、ａ１〜ａ４は、その位置におけるアドレス値を示している。
【０１２１】
図１３（ａ）に示されるように、ＡＶデータが［ａ１、ａ２］の連続領域Ａ１と［ａ３、ａ４］の連続領域Ａ２に分かれて記録されている場合、光ピックアップ１０１がａ２からａ３へシーク動作を行なっている間、トラックバッファ１０３に蓄積してあるデータを動画デコーダ２４０へ供給することでＡＶデータの連続再生が可能になる。
【０１２２】
この時のトラックバッファ１０３内のデータ蓄積量の状態を示したのが、図１３（ｂ）である。位置ａ１で読み出しが開始されたＡＶデータは、時刻ｔ１からトラックバッファ１０３に入力されると共に、トラックバッファ１０３からデータの出力が開始される。これにより、トラックバッファ１０３への入力レート（Ｖａ）とトラックバッファ１０３からの出力レート（Ｖｂ）のレート差（Ｖａ−Ｖｂ）の分だけトラックバッファ１０３にデータが蓄積されていく。この状態が、光ピックアップ１０１がａ２に達するまで、すなわち時刻ｔ２に達するまで継続する。
【０１２３】
この間にトラックバッファ１０３に蓄積されたデータ量をＢ（ｔ２）とすると、時間ｔ２から、位置ａ３のデータの読み出しを開始する時刻ｔ３までの間、トラックバッファ１０３に蓄積されているデータ量Ｂ（ｔ２）を消費して動画デコーダ２４０へ供給し続けられれば良い。
【０１２４】
換言すると、シーク前に読み出すデータ量（［ａ１、ａ２］）が一定量以上確保されていれば、シークが発生した場合であっても、ＡＶデータの連続供給が可能となる。
【０１２５】
ＡＶデータの連続供給が可能な連続領域のサイズは、ＥＣＣブロック数Ｎ＿ｅｃｃに換算すると、（数１）のように求められる。（数１）において、Ｎ＿ｓｅｃはＥＣＣブロックを構成するセクタ数であり、Ｓ＿ｓｉｚｅはセクタサイズ、Ｔｊはシーク性能（最大シーク時間）である。
【０１２６】
（数１）
N＿ecc=Vb×Tj/((N＿sec×8×S＿size)×(1-Vb/Va))
【０１２７】
また、連続領域の中には欠陥セクタが生じる場合がある。この場合を考慮すると、ＡＶデータの連続供給が可能な連続領域のサイズは（数２）のように求められる。（数２）において、ｄＮ＿ｅｃｃは容認する欠陥セクタのサイズであり、Ｔｓは連続領域の中で欠陥セクタをスキップするのに要する時間である。
【０１２８】
（数２）
N＿ecc=dN＿ecc+Vb×(Tj+Ts)/((N＿sec×8×S＿size)×(1-Vb/Va))
【０１２９】
なお、本実施の形態１においては、ディスクメディア１００からデータを読み出す場合、すなわち再生の場合について説明しているが、ディスクメディア１００へデータを書き込む場合、すなわち記録又は録画の場合も同様に考えることができる。
【０１３０】
上述したように、ディスクメディア１００では、一定量以上のデータが連続記録されていれば、ディスク上にＡＶデータを分散記録しても連続再生が可能である。なお、例えばＤＶＤでは、この連続領域をＣＤＡと呼称する。あるいは、ＡＶデータを記録する特別なエクステントであることから、ＡＶエクステントと呼ばれることもある。
【０１３１】
次に、図３を用いて、本実施の形態１にかかる記録再生装置の動作について説明する。図３に示した記録再生装置においては、例えばユーザＩ／Ｆ部２００がユーザからの要求を受け付けた場合に動作を開始する。
【０１３２】
ユーザＩ／Ｆ部２００は、ユーザからの要求をシステム制御部１０４に伝え、システム制御部１０４は、ユーザからの要求を解釈すると共に各モジュールへの処理要求を行なう。
【０１３３】
以下、アナログ放送をＭＰＥＧ−２  ＰＳにエンコードして動画オブジェクトとして記録する動作を例に挙げて説明する。
【０１３４】
システム制御部１０４は、アナログ放送チューナ２１０への受信と動画エンコーダ２２１へのエンコードを要求する。動画エンコーダ２２１は、アナログ放送チューナ２１０から送られてくるＡＶ信号を、ビデオエンコード、オーディオエンコード及びシステムエンコードしてトラックバッファ１０３に送出する。動画エンコーダ２２１は、エンコード開始後、アクセスマップ情報等を作成するために必要な情報をエンコード処理と平行してシステム制御部１０４に送る。
【０１３５】
次に、システム制御部１０４は、ドライブ装置１１０に対して記録要求を出し、ドライブ装置１１０は、トラックバッファ１０３に蓄積されているデータを取り出してディスクメディア１００に記録する。この際、前述した連続領域であるＣＤＡをディスク上の記録可能領域から検索し、見つかったＣＤＡにデータを記録していく。
【０１３６】
この時、ＣＤＡとして記録可能な領域の検索は、ＵＤＦ等のファイルシステムが管理する空き領域情報、例えば、スペースビットマップディスクリプタ（Ｓｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒ）に基づいて実行される。
【０１３７】
録画終了は、ユーザからのストップ要求によって指示される。ユーザからの録画停止要求は、ユーザＩ／Ｆ部２００を通してシステム制御部１０４に伝えられ、システム制御部１０４は、アナログ放送チューナ２１０と動画エンコーダ２２１に対して停止要求を出す。動画エンコーダ２２１は、システム制御部１０４からのエンコード停止要求を受けてエンコード処理を終了する。
【０１３８】
システム制御部１０４は、エンコード処理終了後、動画エンコーダ２２１から受け取った情報に基づいて、アクセスマップ情報とその管理情報、等を含む属性情報を生成する。
【０１３９】
次に、システム制御部１０４は、ドライブ装置１１０に対してトラックバッファ１０３に蓄積されているデータの記録終了と属性情報の記録を要求し、ドライブ装置１１０が、トラックバッファ１０３の残りデータと、属性情報を属性情報ファイル、例えば、図９に示す動画オブジェクトを構成しているファイルであるＡＢＣＤ０００１．ＭＯＩとしてディスクメディア１００に記録し、動画オブジェクトの録画処理を終了する。
【０１４０】
なお、上記のほかに、システム制御部１０４は、図１０や図１１、図１２で説明したようなＵＤＦファイルシステムの情報を必要に応じて生成したり更新したりする。すなわち、動画オブジェクトを構成するファイルに対して、ＥＦＥ５１０やＦＩＤ５２０を生成し、必要な情報を設定した上でディスクメディア１００上に記録する。
【０１４１】
記録再生装置がビデオカメラである場合は、図５を参照して説明したように、ＡＶ信号源がアナログ放送チューナ２１０ではなくカメラ部２１１へ変わるだけで、他の処理は同様である。
【０１４２】
また、デジタル放送を動画オブジェクトとして記録する動作には、動画データのエンコードは行わず、デジタル放送チューナ２１２及び解析部２２３を通じてＭＰＥＧ２  ＴＳのデータをディスクメディア１００へ動画オブジェクトとして記録するようシステム制御部１０４が制御を行う。このとき、上述と同様に、ファイルシステム情報の記録も行われる。
【０１４３】
次に、静止画オブジェクトの記録に関して、カメラ部２１１から送られてくるＡＶ信号をＪＰＥＧエンコードして記録する動作について説明する。
【０１４４】
システム制御部１０４は、カメラ部２１１へＡＶ信号の出力を、静止画エンコーダ２２２へＡＶ信号のエンコード実施を要求する。静止画エンコーダ２２２は、カメラ部２１１から送られるＡＶ信号をＪＰＥＧエンコードし、トラックバッファ１０３に送出する。
【０１４５】
ドライブ装置１１０は、システム制御部１０４からの指示を受けながら、トラックバッファ１０３に蓄積されているデータをディスクメディア１００に記録する。この時、データの記録可能領域の検索は、ＵＤＦ等のファイルシステムが管理する空き領域情報をもとに実行される。
【０１４６】
一つの静止画オブジェクトが記録されたら撮影は終了する。あるいは、ユーザから連続撮影の指示があった場合は、ユーザからの撮影停止要求によって終了するか、所定の枚数の静止画オブジェクトを記録して終了する。ユーザからの撮影停止要求は、ユーザＩ／Ｆ部２００を通してシステム制御部１０４に伝えられ、システム制御部１０４はカメラ部２１１と静止画エンコーダ２２２に対して停止要求を出す。
【０１４７】
さらに、システム制御部１０４は、ＵＤＦファイルシステムの情報についても必要な処理を行う。すなわち、静止画オブジェクトを構成するファイルに対して、ＥＦＥ５１０やＦＩＤ５２０等を生成し、必要な情報を設定した上でディスクメディア１００上に記録する。
【０１４８】
以上のような手順でディスクメディア１００に記録される各メディアオブジェクトは、後々の管理のために、図８で示したメディアオブジェクトマネージ３２０に登録される。各メディアオブジェクトとメディアオブジェクトマネージ３２０との関係については後述する。なお、本発明においてはＥＦＥ５１０を用いて説明を行っているが、その代わりにＦＥを用いてもかまわない。
【０１４９】
図１４は、本実施の形態１における記録再生装置で用いられるディスクメディア１００上に記録されるデータの階層構造と、それらを処理するシステム制御部１０４及びその内部構造の一例を示す図である。
【０１５０】
ディスクメディア１００上にはファイルシステム情報６００が記録される。ファイルシステム情報６００には、図７（ｃ）で示したボリューム構造情報２９０や、図１０、図１１及び図１２で示したＦＳＤ４００、ＥＦＥ５１０、ＦＩＤ５２０、また上述したスペースビットマップディスクリプタ（Ｓｐａｃｅ  Ｂｉｔｍａｐ  Ｄｅｓｃｒｉｐｔｏｒ）等が含まれる。
【０１５１】
また、複数のメディアオブジェクトをまとめて管理するためのメディアオブジェクトマネージャ３２０が同様にファイルとして管理され、コンテンツ管理情報６０１を構成する。
【０１５２】
さらに、メディアオブジェクトに拡張情報６０２を付与する拡張オブジェクト６０３もファイルとして管理される。プログラムマネージャ３３０も拡張オブジェクトの一例であり、複数のメディアオブジェクトの内容や記録日時等に応じて整理分類したり、ユーザが自由な再生順序を設定するプログラム再生を行ったりするための拡張情報を格納するために設けられている。
【０１５３】
これらのディスクメディア１００に記録されるデータは、システムバス１０５を通じて、システム制御部１０４により操作される。
【０１５４】
一方、システム制御部１０４は、より詳細には、オペレーティングシステム（ＯＳ）とアプリケーションシステムとからなる。
【０１５５】
オペレーティングシステムには、ファイルシステム情報６００を制御するファイルシステム処理部６１０や、特に図示されていないハードウエアの制御を行うデバイスドライバ部、メモリ制御部、等が含まれ、アプリケーションシステムに対して、ＡＰＩ（Ａｐｐｌｉｃａｔｉｏｎ  Ｐｒｏｇｒａｍ  Ｉｎｔｅｒｆａｃｅ）を通じてさまざまな共通機能を提供する。これにより、アプリケーションシステムをハードウエアやファイルシステムの詳細とは分離した形で実現することが可能となる。
【０１５６】
一方、アプリケーションシステムでは、特定のアプリケーションのための制御動作を行う。本実施の形態１においては、例えば図３を用いて説明したように、動画オブジェクトや静止画オブジェクトの記録あるいは再生処理に関する制御を行う。
【０１５７】
また、アプリケーションシステム中のコンテンツ管理情報処理部６１１は、コンテンツ管理情報６０１及びそこに含まれるメディアオブジェクトマネージャ３２０に対する操作を行う。
【０１５８】
そして、拡張情報処理部６１２は、拡張情報６０２及びそこに含まれる拡張オブジェクト６０３に対する操作を行う。拡張オブジェクト６０３に対する操作については、後でさらに説明する。
【０１５９】
また、アプリケーションシステムには、その他にも必要に応じて、ＡＶデータの表示や、ユーザインタフェースを処理する部分等を含む場合もある。
【０１６０】
メディアオブジェクトマネージャ３２０のデータ構造については、図１５〜図１６を用いて以下に説明する。
【０１６１】
図１５（ａ）は、メディアオブジェクトマネージャ３２０のデータ構造の例示図である。図１５（ａ）に示すようにメディアオブジェクトマネージャ３２０は、ヘッダ部７００とデータ部７０１とから構成される。
【０１６２】
ヘッダ部７００には、ファイルのタイプを表すＤａｔａＴｙｐｅ、ファイルのサイズを表すＤａｔａＳｉｚｅ、メディアオブジェクトマネージャ３２０の更新日時であるＭｏｄＴｉｍｅ７０２、等が含まれる。また、拡張情報６０２を管理するための拡張オブジェクト管理情報テーブル７１０が含まれる。なお、ＬａｓｔＭｏＵｎｉｑｕｅＩＤ７０３については後述する。
【０１６３】
データ部７０１は、メディアオブジェクト管理情報テーブル７３０を含む。メディアオブジェクト管理情報テーブル７３０は、メディアオブジェクトマネージャ３２０中に含まれるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）７００の数を示すＮｕｍＭｏＩｎｆｏと、ＮｕｍＭｏＩｎｆｏ個のＭＯ＿ＩＮＦＯ７００から構成される。
【０１６４】
なお、図１５等におけるフィールド名欄の表記は、データ型とフィールド名を続けて記述しており、データ型については、例えば以下のような意味を示している。
【０１６５】
ｃｏｎｓｔは、フィールドが定数であることを意味しており、ｃｏｎｓｔがない場合は変数であることを示している。ｕｎｓｉｇｎｅｄは、当該フィールドは符号無しの値であることを示しており、ｕｎｓｉｇｎｅｄがない場合は符号付きの値であることを示している。また、ｉｎｔ（）は、フィールドはカッコ内のビット長を持つ整数値であることを示している。例えば、カッコ内の値が“１６”である場合には、１６ビット長であることを意味する。また、ｓｔｒｉｎｇは文字列情報であることを意味する。
【０１６６】
図１５（ｂ）は、メディアオブジェクトマネージャ３２０に含まれる拡張オブジェクト管理情報（ＥＯ＿ＩＮＦＯ）７２０のデータ構造である。ＥＯ＿ＩＮＦＯ７２０は、プログラムマネージャ３３０のような拡張オブジェクトを登録・管理するデータ構造であり、各拡張オブジェクトをそれぞれ識別するための型情報を示すＥｏＴｙｐｅ７２１及びＥｏＳｕｂＴｙｐｅ７２２を持つ。
【０１６７】
ＥｏＴｙｐｅ７２１及びＥｏＳｕｂＴｙｐｅ７２２には、例えば、拡張オブジェクトの所有者（オーナー）情報やその使用目的を示す情報を数値やアルファベット値として格納しても良い。
【０１６８】
さらにＥＯ＿ＩＮＦＯ７２０は、拡張オブジェクトへの参照情報をパス名により保持する拡張オブジェクト参照情報ＥｏＲｅｆ７２３、図１５（ｃ）で示される属性フラグであるＥｏＦｌａｇｓ７２４、拡張オブジェクトの概要を示す文字列情報を格納するＴｅｘｔＤｅｓｃ７２６、等から構成される。
【０１６９】
図１５（ｃ）は、ＥＯ＿ＩＮＦＯ７２０が指し示す拡張オブジェクトに関する様々な情報をフラグとして格納するＥｏＦｌａｇｓ７２４の構造例である。本実施の形態においては、０ビット目をＶａｌｉｄフィールドとしている。
【０１７０】
Ｖａｌｉｄフィールドの値が１ｂの場合、メディアオブジェクトマネージャ３２０及びそれが管理するメディアオブジェクトと、ＥＯ＿ＩＮＦＯ７２０が指し示す拡張オブジェクトとの整合性が維持されており、該拡張オブジェクトに含まれる情報が有効であることが保障されている状態を示す。一方、Ｖａｌｉｄフィールドの値が０ｂの場合は、その保障がないことを示す。
【０１７１】
図１６（ａ）は、メディアオブジェクトマネージャ３２０に含まれるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）７４０のデータ構造である。
【０１７２】
ＭＯ＿ＩＮＦＯ７４０は、登録されるメディアオブジェクトの型情報を示すＭｏＴｙｐｅ７４１、メディアオブジェクトへの参照情報であるオブジェクト参照情報ＭｏＲｅｆ７４２、少なくともメディアオブジェクトマネージャ３２０内で重複しない値であるメディアユニークＩＤが設定されるＭｏＵｎｉｑｕｅＩＤ７４３、等から構成される。
【０１７３】
重複しないメディアユニークＩＤの設定方法は、例えば、初期値を０とし、メディアオブジェクトを新たに記録するたびにメディアユニークＩＤの値を１ずつ加算しながら割り当てていく。そして、ある時点でのメディアユニークＩＤの最大値をＬａｓｔＭｏＵｎｉｑｕｅＩＤ７０３に記録しておくことにより、記録を一旦中断した時にも次に割り当てるメディアユニークＩＤの値（すなわち、ＬａｓｔＭｏＵｎｉｑｕｅＩＤ７０３に１を加算した値）を容易に決めることができる。
【０１７４】
あるいは、図１１を用いて説明したように、ＵＤＦファイルシステムはファイルシステム上で、各ファイルに対して重複しないＵｎｉｑｕｅ  ＩＤ５１１を設定するので、このＵｎｉｑｕｅ  ＩＤ５１１の値をメディアユニークＩＤの値として流用することも可能である。
【０１７５】
なお、本実施の形態においては、ＭｏＵｎｉｑｕｅＩＤ７４３に設定された値と同じ値を図１１（ａ）で示したＥＦＥ５１０のＥＡｓ５１３中にＭｏＵｎｉｑｕｅＩＤ５４１として設定するようにしてもよい。
【０１７６】
その他にも、各種属性情報を示すＡｔｔｒｉｂｕｔｅｓ、当該メディアオブジェクトの再生時間であるＰｌａｙＢａｃｋＤｕｒａｔｉｏｎ、ＭＯ＿ＩＮＦＯ７４０とは異なる場所に格納されるテキスト情報への参照情報ＴｅｘｔＩＤやサムネイル情報への参照情報ＴｈｕｍＩＤ等も含んでいる。
【０１７７】
図１６（ｂ）に示すように、ＭｏＴｙｐｅ７４１に設定される値は、参照先のメディアオブジェクトの種類により決まる。
【０１７８】
ＭｏＴｙｐｅの値が“１”である場合、あるオブジェクトメディア情報に登録されているメディアオブジェクトの種類は、ファイルシステム上のあるディレクトリである。同様に、値が“２”の場合には動画オブジェクト（拡張子：ＭＯＩ）を、値が“３”の時は静止画オブジェクト（拡張子：ＪＰＧ）を、それぞれ示す。以下同様に、メディアオブジェクトの種類ごとに異なるＭｏＴｙｐｅの値を割り当てることとする。
【０１７９】
また、ＭｏＲｅｆ７４２へ設定される値は、参照先のメディアオブジェクトの持つパス名情報を図１６（ｃ）に示す変換規則により変換することにより決定される。
【０１８０】
最初のフィールドＰａｒｅｎｔ  Ｄｉｒ  ＮｏはＭＯ＿ＩＮＦＯ７４０が参照するメディアオブジェクトの親ディレクトリのパス名により決められる。すなわち、親ディレクトリがＶＩＤＥＯイメージルートディレクトリ３０１の場合は“０”、ＤＣＩＭイメージルートディレクトリ３０２の場合は“１”となる。それ以外の値については、本実施の形態１では使用しないので予約値としている。
【０１８１】
もちろん、変換規則によって与えられる値は別の組み合わせであってもよく、例えば、ＶＩＤＥＯイメージルートディレクトリ３０１に’１’を、ＤＣＩＭイメージルートディレクトリ３０２に’２’を割り当て、その他の場合を予約値とするようにしてもかまわない。
【０１８２】
次のフィールドであるＤｉｒ  Ｎｏには、ＭＯ＿ＩＮＦＯ７４０に登録されたメディアオブジェクトのディレクトリ番号部分を抜き出して格納する。ここでディレクトリ番号とは、メディアオブジェクトの上位ディレクトリのディレクトリ名における数値部分である。
【０１８３】
次のフィールドであるＦｉｌｅ  Ｎｏには、ＭＯ＿ＩＮＦＯ７４０に登録されたメディアオブジェクトのファイル番号を抜き出して格納する。ここでファイル番号とは、メディアオブジェクトのファイル名における数値部分である。
【０１８４】
例えば、メディアオブジェクトのパス名が、“／ＶＩＤＥＯ／１００ＡＢＣＤＥ／ＡＢＣＤ０００１．ＭＯＩ”である場合、当該メディアオブジェクトは“／ＶＩＤＥＯ”ディレクトリを親ディレクトリとして持つので、ＯＢＪ＿ＩＤのＰａｒｅｎｔ  Ｄｉｒ  Ｎｏの値は“０”、そして当該メディアオブジェクトの上位ディレクトリ名の数値部分の値が１００であるので、ＯＢＪ＿ＩＤのＤｉｒ  Ｎｏの値は“１００”となる。さらに、当該メディアオブジェクトのファイル名の数値部分の値をとって、ＯＢＪ＿ＩＤのＦｉｌｅ  Ｎｏの値は“０００１”となる。
【０１８５】
以上より、ＭｏＲｅｆ７４２に設定される値は、“／”を区切りとし、Ｐａｒｅｎｔ  Ｄｉｒ  Ｎｏ、Ｄｉｒ  Ｎｏ、Ｆｉｌｅ  Ｎｏの順に並べる表記によれば、０／１００／０００１となる。以降、ＯＢＪ＿ＩＤの値を必要に応じて同様の表記により示す。
【０１８６】
ＯＢＪ＿ＩＤをこのような形式としても、ＤＣＦ規格の命名規則のように、メディアオブジェクトの名前やその上位ディレクトリの名前に含まれる数値部分の値が重複しないような命名規則を守っておけば、上述のＭｏＴｙｐｅ７４１の値から導かれる拡張子情報とあわせて、ファイルシステム上で、ＭｏＲｅｆ７４２が参照しているメディアオブジェクトを特定することが可能である。このような構成はＭＯ＿ＩＮＦＯ７４０のデータ量を減らす目的に好適である。
【０１８７】
もちろん、ＯＢＪ＿ＩＤのデータ構造は、ＭＯ＿ＩＮＦＯ７４０とメディアオブジェクトが一意に対応づけられる形式であれば他の形式でもよい。例えば、メディアオブジェトのパス情報をそのまま格納する方法もある。すなわち、“／ＶＩＤＯＥ／１００ＡＢＣＤＥ／ＡＢＣＤ０００１．ＭＯＩ”のように、“／”をパス区切り文字としたフルパス名の文字列を格納してもよい。
【０１８８】
あるいは、ＭｏＴｙｐｅ７４０の部分の代わりに、ファイルの拡張子を格納するようにしてもよい。例えば“／ＶＩＤＯＥ／１００ＡＢＣＤＥ／ＡＢＣＤ０００１．ＭＯＩ”というファイルに対しては“ＭＯＩ”の部分を格納するようにしてもよい。
【０１８９】
なお、動画オブジェクトについては、属性情報ファイル（例えば、図８における３１２）だけをメディアオブジェクト管理情報に登録してもよい。対応する動画ファイル（この場合、図８における３１１）は、上述のようにファイル名の対応付け等により属性情報ファイルから知ることができるからである。あるいは、逆に、動画ファイルをメディアオブジェクト管理情報に登録するようにしてもよい。同様に対応する属性情報ファイルを知ることができるからである。もちろん、属性情報ファイルと動画ファイルの両方を登録してもかまわない。
【０１９０】
次に本実施の形態における拡張オブジェクトの一例であるプログラムマネージャ３３０のデータ構造について、図１７を用いて以下に説明する。
【０１９１】
拡張オブジェクトの共通構造として、ヘッダ部８００とデータ部８０１を持つ。
【０１９２】
ヘッダ部８００は、ファイルのタイプを表すＤａｔａＴｙｐｅ（拡張オブジェクトを示す固定値を設定）、ファイルのサイズを表すＤａｔａＳｉｚｅ、拡張オブジェクトの型情報を示すＥｏＴｙｐｅ８１１及びＥｏＳｕｂＴｙｐｅ８１２、更新時刻を示すＭｏｄＴｉｍｅ８１３、拡張オブジェクトの概要を示す文字列情報を格納するＴｅｘｔＤｅｓｃ８１４、等から構成される。
【０１９３】
ヘッダ部８００において、ＥｏＴｙｐｅ８１１、ＥｏＳｕｂＴｙｐｅ８１２の値により拡張オブジェクトの種類分けを行う。
【０１９４】
また、拡張オブジェクトはＥＯ＿ＩＮＦＯ７２０から参照されるが、この時、ＥｏＴｙｐｅ８１１、ＥｏＳｕｂＴｙｐｅ８１２及びＴｅｘｔＤｅｓｃ８１４の値が、ＥＯ＿ＩＮＦＯ７２０中のＥｏＴｙｐｅ７２１、ＥｏＳｕｂＴｙｐｅ７２２及びＴｅｘｔＤｅｓｃ７２６へと設定される。
【０１９５】
一方、データ部８０１は、拡張オブジェクトの種類ごとに固有の拡張データを格納し、ＥｏＴｙｐｅ８１１、ＥｏＳｕｂＴｙｐｅ８１２の値により異なるデータ構造を持つ。
【０１９６】
図１７（ａ）は、プログラム再生を行うための拡張オブジェクトであるプログラムマネージャ３３０の場合の例であり、拡張データとして次のような構造を持つ。
【０１９７】
プログラムマネージャ３３０に登録されたすべてのメディアオブジェクトの再生時間の合計であるＰｌａｙＢａｃｋＤｕｒａｔｉｏｎ、プログラムマネージャ３３０中に含まれるプログラム情報（ＰＲＧ＿ＩＮＦＯ）８２０の数を示すＮｕｍＰｒｇＩｎｆｏ、そして、ＮｕｍＰｒｇＩｎｆｏ個のＰＲＧ＿ＩＮＦＯ８２０からなるプログラム情報テーブル８３０で構成される。
【０１９８】
そして、図１７（ｂ）はプログラムマネージャ３３０に含まれるプログラム情報（ＰＲＧ＿ＩＮＦＯ）８２０のデータ構造である。ＰＲＧ＿ＩＮＦＯ８２０は、ＭＯ＿ＩＮＦＯ７４０をグループ化し、ディスクメディア１００上に記録された複数のメディアオブジェクトの分類を行ったり、あるいは、ＰＲＧ＿ＩＮＦＯ８２０から参照しているメディアオブジェクトを順に再生することにより、プログラム再生を実現するときの一つの単位である。
【０１９９】
図１７（ｂ）に示すように、ＰＲＧ＿ＩＮＦＯ８２０は、プログラム情報であることを示すＤａｔａＴｙｐｅ、ＰＲＧ＿ＩＮＦＯ８２０のサイズを示すＤａｔａＳｉｚｅ、プログラムの各種属性情報を示すＡｔｔｒｉｂｕｔｅｓ、プログラムの再生時間であるＰａｙＢａｃｋＤｕｒａｔｉｏｎ、ＰＲＧ＿ＩＮＦＯ８２０中に含まれるＭＯ＿ＩＮＦＯ７４０への参照の数を示すＮｕｍＭｏＩｎｆｏ、そして、ＮｕｍＭｏＩｎｆｏ個のＭｏＩＤからなるＭＯ＿ＩＮＦＯ７４０への参照テーブル、等から構成される。
【０２００】
その他にも、ＰＲＧ＿ＩＮＦＯ８２０とは異なる場所に格納されるテキスト情報への参照情報ＴｅｘｔＩＤやサムネイル情報への参照情報ＴｈｕｍＩＤ等も含んでもよい。
【０２０１】
本構造により、拡張オブジェクトであるプログラムマネージャ３３０は、任意のメディアオブジェクトをグループ化することが可能となる。これにより、ファイルシステム上のディレクトリ構造とは独立して、仮想的なフォルダー構造を構成し、メディアオブジェクトの自由な分類整理を行える。また、ユーザの望みの再生順序でメディアオブジェクトを再生するプログラム再生等の機能も実現できる。
【０２０２】
次に、図１８を用いて、ファイルシステムで管理されるディレクトリやメディアオブジェクトと、ＭＯ＿ＩＮＦＯ７４０との関係を説明する。
【０２０３】
メディアオブジェクトマネージャ３２０には、複数のＭＯ＿ＩＮＦＯ７４０が含まれており、それぞれにメディアオブジェクトが登録されている。例えば、ＭｏＩｎｆｏ［１］９００には、ディレクトリ３０４が登録されている。この時、ＭｏＩｎｆｏ［１］９００のフィールドの値は次のように設定される。
【０２０４】
まずＭｏＴｙｐｅは、図１６（ｂ）より、ディレクトリを示す“１”が設定される。ＭｏＲｅｆは、図１６（ｃ）より、親ディレクトリ“０”、ディレクトリ番号“１００”、ファイル番号“００００”となり、フィールド値全体としては０／１００／００００となる。
【０２０５】
ＭｏＵｎｉｑｕｅＩＤ７４３は、ここでは“１００”が設定されており、他のＭＯ＿ＩＮＦＯに設定されている値と重複していない。
【０２０６】
また、ＭｏＩｎｆｏ［２］９０１のフィールドの値は次のように設定される。まずＭｏＴｙｐｅは、動画オブジェクトを示す“２”が設定される。ＭｏＲｅｆ７１１は、親ディレクトリ“０”、ディレクトリ番号“１００”、ファイル番号“０００１”となり、フィールド値全体としては０／１００／０００１となる。ＭｏＵｎｉｑｕｅＩＤは、重複しない値として“１０１”が設定されている。以降、その他のＭｏＩｎｆｏも同様に値が設定される。
【０２０７】
図１９は、このようなメディアオブジェクトマネージャ３２０に対する、プログラムマネージャ３３０の関係を示すものである。上述のように、プログラムマネージャ３３０には複数のＰＲＧ＿ＩＮＦＯ８００（ＰｒｇＩｎｆｏ［１］９１０〜）が含まれる。
【０２０８】
各ＰＲＧ＿ＩＮＦＯ８００は、ＭＯ＿ＩＮＦＯ７００への参照情報を、メディアユニークＩＤとして保持する。すなわち、ＭＯ＿ＩＮＦＯ７００がＭｏＵｎｉｑｕｅＩＤ７１２で保持しているメディアユニークＩＤの値を参照情報とする。
【０２０９】
例えば、ＰｒｇＩｎｆｏ［１］９１０では、図１９中の波線矢印で示すように、ＭｏＩｎｆｏ［２］とＭｏＩｎｆｏ［５］とＭｏＩｎｆｏ［８］への参照を持つので、ＭｏＩＤのテーブル（ＭｏＩＤ［］）の値として、１０１、１０４、２０１を保持する。ＰｒｇＩｎｆｏ［２］９１１でも同様に、ＭｏＩｎｆｏ［６］とＭｏＩｎｆｏ［８］への参照を持つので、ＭｏＩＤ［］の値として、１０５、２０１を保持する。
【０２１０】
この状態において、プログラム再生を実施するための処理について説明する。例えば、ＰｒｇＩｎｆｏ［１］９１０によるプログラム再生の開始が支持されたとすると、コンテンツ管理情報処理部６１１は、ＰｒｇＩｎｆｏ［１］９１０内のメディアオブジェクト情報への参照テーブルＭｏＩＤ[]内の値を読み出す。上述したとおり、ＭｏＩＤ[]には、プログラム再生の対象となるメディアオブジェクトへの参照情報がメディアユニークＩＤとして保持されている。
【０２１１】
よって、プログラム再生を行うには、ＭｏＩＤ［］に保持されているメディアユニークＩＤの指し示すＭＯ＿ＩＮＦＯ７４０をメディアオブジェクトマネージャ３２０中から検索し、それが見つかったら、ＭＯ＿ＩＮＦＯ７４０が参照するメディアオブジェクトの再生を行う。
【０２１２】
ＭｏＩＤ[]に保持されているすべてのメディアユニークＩＤに対して同様の手順を繰り返すことによりプログラム再生が実行される。
【０２１３】
図２０は、複数の拡張オブジェクトが存在する場合において、ファイルシステムで管理されるディレクトリやメディアオブジェクト、メディアオブジェクトマネージャ３２０との関係を示すものである。ここでは、プログラムマネージャ３３０とは異なる拡張オブジェクト１０００と１００１が存在する。
【０２１４】
図１９を用いて説明したのと同様に、拡張オブジェクト１０００と１００１はメディアオブジェクトマネージャ３２０を経由して（例えば、プログラムマネージャ３３０と同様にメディアユニークＩＤにより）メディアオブジェクトに対応付けられており、さまざまな拡張情報を提供する。
【０２１５】
例えば、拡張オブジェクト１０００は、各メディアオブジェクトがこれまでに何回再生されたかの再生回数のカウント値を保持する拡張オブジェクトである。各メディアオブジェクトが再生されるたびにそのカウント値を増加させて、拡張オブジェクト１０００内に保持する。このようなカウント値を拡張情報として保持しておくことにより、あるメディアオブジェクトをユーザが既に視聴したかどうかを示すことが出来る。
【０２１６】
あるいは、再生回数のカウント値をユーザの録画映像に対する好みの判定に用いることも出来る。例えばカウント値が大きい場合は、ユーザの好みの映像が録画されていると判断し、逆に、カウント値が少ないメディアオブジェクトは好みではないと判断する。このような情報は、例えば、記録媒体１００上の空き容量が少なくなったとき、不要なメディアオブジェクトの削除を行う時の参考情報として用いることが可能である。
【０２１７】
また、拡張オブジェクト１００１は、各メディアオブジェクトに対するＧＰＳ情報を格納する。各メディアオブジェクトが記録された時点での位置情報を記録しておき、後に検索や表示するために用いることが可能である。
【０２１８】
ユーザが旅行の記念撮影などを行った時に、ＧＰＳ情報があれば、行き先の位置情報を頼りに、多数のメディアオブジェクトから目的のメディアオブジェクトを容易に探し出すことが可能となる。
【０２１９】
なお、拡張オブジェクトとして保持するデータとしては、上記に限られるものではなく、他のデータでもよい。例えば、各メディアオブジェクトに対するｃａｍｅｒａパラメータ（記録時のカメラの種別、ズームの有無、フラッシュの有無、等）や、ＭＰＥＧ７などのメタデータ等でもよい。その他、製造メーカが他社製品との差別化やユーザに対する独自の利便性を提供することを目的として、メディアオブジェクトマネージャ３２０等の統一規格に含まれない機能を実現するために利用してよい。
【０２２０】
図２１は、図２０の状態において、拡張オブジェクト管理情報テーブル７１０に設定される値の例を示す図である。
【０２２１】
図２１（ａ）の一つの行がＥＯ＿ＩＮＦＯ７２０に相当する。各ＥＯ＿ＩＮＦＯのＥｏＴｙｐｅ及びＥｏＳｕｂｔｙｐｅは、それぞれの拡張オブジェクトの内容を識別するための値（ここではそれぞれ２文字のアスキーコード）が設定される。なお、各ＥｏＴｙｐｅ及びＥｏＳｕｂｔｙｐｅの値は一例であり、各拡張オブジェクトが識別可能であれば他の値でもかまわない。
【０２２２】
ＥｏＲｅｆとして、ここでは、拡張オブジェクトのファイル名を格納する。なお、拡張オブジェクトを参照する時のデータ形式は他の形式でもよく、ＭＯ＿ＩＮＦＯ７４０がメディアオブジェクトを参照する時に使用するＯＢＪ＿ＩＤのように、ファイル番号などの特定の変換規則を利用することも可能である。
【０２２３】
ＥｏＦｌａｇｓについては、ここでは、すべての情報が有効であるとし、Ｖａｌｉｄ＝１ｂがすべて設定されている。ＴｅｘｔＤｅｓｃは、それぞれの拡張オブジェクトの保持する情報の内容を簡単な文字列として保持している。
【０２２４】
図２２は、本実施の形態において、新規の拡張オブジェクト及び拡張データを記録するための処理を示すフローチャートである。
【０２２５】
まず、拡張情報処理部６１２が、拡張オブジェクト管理情報テーブル７１０をメディアオブジェクトマネージャ３２０から読み出す（ステップＳ１０１）。
【０２２６】
次に、拡張オブジェクト管理情報テーブル７１０中の各ＥＯ＿ＩＮＦＯ７２０の値を調べることにより、追加したい拡張データを含む拡張オブジェクトがすでに存在しているかどうかを調べる（ステップＳ１０２）。
【０２２７】
拡張オブジェクトが存在していない場合は新規に作成し（ステップＳ１０３）、対応するＥＯ＿ＩＮＦＯ７２０を拡張オブジェクト管理情報テーブル７１０へと追加する（ステップＳ１０４）。拡張オブジェクトが存在していた場合及び新規に作成した後は、その拡張オブジェクトへ拡張データを追加する（ステップＳ１０５）。
【０２２８】
図２３は、本実施の形態において、メディアオブジェクト及びＭＯ＿ＩＮＦＯ７４０に対する何らかの操作が行われた後、拡張オブジェクト管理情報テーブル７１０に対して行われる処理を示すフローチャートである。ここで、メディアオブジェクト及びＭＯ＿ＩＮＦＯ７４０に対する何らかの操作とは、例えば、メディアオブジェクトやＭＯ＿ＩＮＦＯ７４０中のデータ値の書き換えや編集及び削除、等のことである。
【０２２９】
このような操作が行われると、メディアオブジェクト及びメディアオブジェクトマネージャ３２０と、拡張オブジェクト及び拡張データ間の情報の不整合が発生する場合がある。
【０２３０】
例えば、拡張データの一種であるＰＲＧ＿ＩＮＦＯ８２０から参照されているメディアオブジェクトが削除されてしまうと、ＰＲＧ＿ＩＮＦＯ８２０からの参照先がなくなってしまい、プログラム再生の実行の際に不都合が生じる。
【０２３１】
プログラム再生以外の他の拡張データの場合も同じで、参照先のメディアオブジェクトやＭＯ＿ＩＮＦＯ７４０が変更されると、不整合が発生する。
【０２３２】
そこで本実施の形態においては、メディアオブジェクト及びメディアオブジェクトマネージャ３２０に対して何らかの操作が行われると以下の処理を実施する。
【０２３３】
まず、拡張情報処理部６１２は、拡張オブジェクト管理情報テーブル７１０をメディアオブジェクトマネージャ３２０から読み出す（ステップＳ２０１）。
【０２３４】
拡張オブジェクト管理情報テーブル７１０には、ＴｏｔａｌＮｕｍＥｏＩｎｆｏ７０４で示される数だけＥＯ＿ＩＮＦＯ７２０が存在するので、ステップＳ２０２からステップＳ２０８のループ処理によりすべてのＥＯ＿ＩＮＦＯ７２０に対する処理を行う。
【０２３５】
まず、ループ処理のカウント値を初期化し（ステップＳ２０２）する。
【０２３６】
そして、最初の拡張オブジェクトに対して、処理可能かどうかを判別する（ステップＳ２０３）。この判別には、ＥｏＴｙｐｅ７２１及びＥｏＳｕｂｔｙｐｅ７２２やＥｏＲｅｆ７２３が利用可能である。
【０２３７】
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、Ｖａｌｉｄフラグ７３１を０ｂに設定する（ステップＳ２０４）。これにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ３２０との間での整合性を保障しない状態であることを示す。一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し（ステップＳ２０５）、Ｖａｌｉｄフラグ７３１を１ｂに設定する（ステップＳ２０６）。
【０２３８】
ここで、該拡張オブジェクトの内容を更新とは、先に行われたメディアオブジェクト及びメディアオブジェクトマネージャ３２０に対する操作の結果と、該拡張オブジェクトの内容が整合するような処理である。
【０２３９】
例えば、拡張オブジェクトがプログラムマネージャ３３０であり、メディアオブジェクト及びメディアオブジェクトマネージャ３２０に対する操作が、メディアオブジェクト及びそれを参照するＭＯ＿ＩＮＦＯ７４０の削除であった場合、プログラムマネージャ３３０に対しては、該ＭＯ＿ＩＮＦＯ７４０を参照するＰＲＧ＿ＩＮＦＯ８２０を更新し、削除された該ＭＯ＿ＩＮＦＯ７４０への参照を削除する処理を行う。他の種類の拡張オブジェクトに対しても、それぞれの拡張情報に応じた更新処理を実施する。
【０２４０】
更新処理を実施することにより、該拡張オブジェクトとメディアオブジェクト及びメディアオブジェクトマネージャ３２０との間での整合性を保障できるので、Ｖａｌｉｄフラグ７３１を１ｂに設定している。
【０２４１】
以降、カウント値を加算しながら、ＴｏｔａｌＮｕｍＥｏＩｎｆｏの値に等しくなるまで処理を繰り返す（ステップＳ２０７、ステップＳ２０８）。
【０２４２】
図２３のような処理が終了した後の拡張オブジェクト管理情報テーブル７１０に設定される値の例を図２１（ｂ）に示す。
【０２４３】
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。２行目以降のＥＯ＿ＩＮＦＯ  ７２０のＶａｌｉｄフラグが０ｂに設定され、これらの拡張オブジェクトのデータの有効性が保障されない状態であることを示している。
【０２４４】
図２４は、本実施の形態において、特定の種類の拡張オブジェクトを指定してそのデータを利用する際の処理に関するフローチャートである。
【０２４５】
まず、拡張情報処理部６１２は、拡張オブジェクト管理情報テーブル７１０をメディアオブジェクトマネージャ３２０から読み出す（ステップＳ３０１）。
【０２４６】
次に、拡張オブジェクト管理情報テーブル７１０内を検索し、目的の拡張オブジェクトを参照しているＥＯ＿ＩＮＦＯ７２０を得る（ステップＳ３０２）。目的の拡張オブジェクトの検出は、ＥｏＴｙｐｅ７２１及びＥｏＳｕｂｔｙｐｅ７２２の値を調べることにより行える。あるいは拡張オブジェクトのパス名の命名側を決めておくことにより、ＥｏＲｅｆ７２３の値を見ることにより検出可能である。
【０２４７】
もし、目的の拡張オブジェクトを参照しているＥＯ＿ＩＮＦＯ７２０が見つからなければ、例外処理を行い（ステップＳ３０３）、本フローチャートで示す処理を終了する。例外処理とは例えば、ユーザに所望の拡張オブジェクトが存在しないことを知らせるメッセージを表示したり、あるいは、新たに、該拡張オブジェクトを作成したりする処理などである。
【０２４８】
もし、目的の拡張オブジェクトを参照しているＥＯ＿ＩＮＦＯ７２０が見つかれば、Ｖａｌｉｄフラグの値が１ｂであるかを調べる（ステップＳ３０４）。
【０２４９】
Ｖａｌｉｄフラグの値が１ｂでなければ例外処理を実施する（ステップＳ３０５）。ここでの例外処理とは例えば、ユーザに所望の拡張オブジェクトとメディアオブジェクトマネージャ３２０との間で不整合が存在することを知らせるメッセージを表示したり、記録媒体１００の書き込みを禁止したり、あるいは、該拡張オブジェクトとメディアオブジェクトマネージャ３２０の不整合を解消すべく、該拡張オブジェクト内の情報を更新する処理を実施したりする処理、等である。
【０２５０】
一方、Ｖａｌｉｄフラグの値が１ｂであれば、該拡張オブジェクトに対する通常処理を実施する（ステップＳ３０６）。通常処理とは、例えば、該拡張オブジェクトが、プログラムマネージャ３３０であれば、プログラム再生を実施することである。
【０２５１】
他の拡張オブジェクトに関しても、あるメディアオブジェクトに関連付けられている拡張データをユーザに対して表示する（ＧＰＳ情報の表示など）、等、夫々の種類に応じた動作を行う。
【０２５２】
図２４中の例外処理を行う場合に、少なくともＴｅｘｔＤｅｓｃ７２６の値を表示するようにすれば、どんな拡張情報が設定されているかをユーザに知らせることが可能である。
【０２５３】
以上により、メディアオブジェクトマネージャ３２０のデータ容量を大幅には増加させず、拡張情報の追加が行える。
【０２５４】
これは、ＤＶＤレコーダやＤＶＤビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、ある記録再生装置が対応していない拡張機能が存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
【０２５５】
これは、ＤＶＤレコーダやＤＶＤビデオカメラなどの可搬型の記録媒体を用いた記録再生装置において、１つの記録媒体が複数の製造メーカによる記録再生装置で記録・再生される場合において望ましい構成である。
【０２５６】
（実施の形態２）
本実施の形態では、実施の形態１とは異なる拡張オブジェクトの管理の方法について述べる。実施の形態１では、拡張オブジェクト管理情報テーブル７１０により拡張オブジェクトを管理したが、本実施の形態では、ＭＯ＿ＩＮＦＯにより各拡張オブジェクトを管理する。
【０２５７】
このときの、拡張オブジェクトとＭＯ＿ＩＮＦＯの関係を図２５に示す。ここでは、メディアオブジェクトマネージャ３２０に含まれるＭＯ＿ＩＮＦＯであるＭｏＩｎｆｏ［ｉ］〜ＭｏＩｎｆｏ［ｉ＋２］がそれぞれ拡張オブジェクト１０００、３３０、１００１を参照、管理しているものとする。ただし、本実施の形態におけるＭＯ＿ＩＮＦＯは、図２６に示す構造を持つものとする。
【０２５８】
図２６（ａ）におけるＭＯ＿ＩＮＦＯ２０００は、ＭＯ＿ＩＮＦＯ７４０に対して、ＥＯ＿ＩＮＦＯ２１００のフィールドが追加されている点を除いて同一である。
【０２５９】
ＥＯ＿ＩＮＦＯ２１００は、ＥＯ＿ＩＮＦＯ７２０と異なる構造を持ち、図２６（ｂ）で示す構造を持つ。
【０２６０】
ＥＯ＿ＩＮＦＯ２１００は、ＥＯ＿ＩＮＦＯ７２０からＥｏＲｅｆ７２３とＴｅｘｔＤｅｓｃ７２６を除いた構造を持ち、ＥｏＲｅｆ７２３の代わりにＭｏＴｙｐｅ７４１とＭｏＲｅｆ７４２を、ＴｅｘｔＤｅｓｃ７２６の代わりにＴｅｘｔＩＤ７４４を用いることで同様の機能を果たす。すわわち、ＭｏＴｙｐｅ７４１とＭｏＲｅｆ７４２により拡張オブジェクトを参照し、ＴｅｘｔＤｅｓｃ７２６により拡張オブジェクトに対する文字列情報を格納する。
【０２６１】
なお、上記機能を実現するために、図１６（ｂ）のＭｏＴｙｐｅ７４１の値に対して、拡張オブジェクト（拡張子：ＥＸＴ）を示す値（例えば“４”）を定義することとする。
【０２６２】
また、ＭｏＲｅｆ  ７４２による参照を行うために、拡張オブジェクトのディレクトリ名やファイル名は、ディレクトリ番号及びファイル番号による一意な参照が可能となるような命名即を用いる。
【０２６３】
上記構成により、メディアオブジェクトと拡張オブジェクトを共通の枠組みで管理することが可能となり、装置の実装上、好都合である。
【０２６４】
（実施の形態３）
本実施の形態では、異なる拡張オブジェクトの管理の方法について述べる。
【０２６５】
実施の形態１では、拡張オブジェクト管理情報テーブル７１０のＶａｌｉｄフラグ７３１において拡張オブジェクトの有効性を管理したが、本実施の形態では、ＭＯ＿ＩＮＦＯにおいて各拡張オブジェクトの有効性を管理する。
【０２６６】
このとき、メディアオブジェクトを参照・管理するＭＯ＿ＩＮＦＯは図２７に示すデータ構造を持つものとする。
【０２６７】
図２７（ａ）におけるＭＯ＿ＩＮＦＯ３０００は、ＭＯ＿ＩＮＦＯ７４０に対して、拡張データ属性フラグ（ＲｅｆＶａｌｉｄＦｌａｇ）３１００のフィールドが追加されている点を除いて同一である。
【０２６８】
ＲｅｆＶａｌｉｄＦｌａｇ３１００は、図２７（ｂ）に示す情報を保持する。ＲｅｆＶａｌｉｄＦｌａｇ３１００では、２ビットがひとつの拡張オブジェクトに対応している。
【０２６９】
例えば、ビット０〜１は、拡張オブジェクトの内、ファイル番号が０００１番を持つものに対応する。同様に、ビット１〜２はファイル番号が０００２番に対応し、以降も同様である。
【０２７０】
そして、この各２ビットの解釈は、次のとおりである。すなわち、上位ビットは、該ＭＯ＿ＩＮＦＯ３０００が管理するメディアオブジェクトに対して、拡張オブジェクトからの参照が存在する（１ｂ）か、存在しない（０ｂ）かを示す。そして、下位ビットは、ＭＯ＿ＩＮＦＯ３０００が管理するメディアオブジェクトに対する拡張データが有効である（１ｂ）か無効である（０ｂ）かを示す。
【０２７１】
すなわち、この下位ビットは、Ｖａｌｉｄフラグ７３１と同じ意味を持つ。ただし、このＲｅｆＶａｌｉｄＦｌａｇ３１００の下位ビットは、ＭＯ＿ＩＮＦＯ３０００単位で拡張データが有効かどうかを示すことができ、より詳細な単位での拡張データの管理が可能となっている。
【０２７２】
具体的には、例えば図２０に示したのと同様な参照関係が存在する場合、図２０中のＭｏＩｎｆｏ［１］のＲｅｆＶａｌｉｄＦｌａｇ３１００に設定される値は、図２７（ｂ）の右端の列「設定値の例」のようになる。
【０２７３】
すなわち、ＭｏＩｎｆｏ［１］は、ファイル番号０００１を持つ拡張オブジェクトであるプログラムマネージャ３３０からの参照を持ち、かつその値が有効であるとすると、ビット０〜１は１１ｂという値に設定される。また、同様に、ファイル番号０００２を持つ拡張オブジェクトからも参照されており、かつその値が有効であるとすると、ビット２〜３は１１ｂという値に設定される。
【０２７４】
一方、ファイル番号００１６を持つ拡張オブジェクトも存在するが、そこからは参照されていないので、ビット３０〜３１は００ｂという値に設定される。
【０２７５】
また、上記状態から、図２３を用いて説明した処理と同様、メディアオブジェクトに対する編集操作等が行われると拡張オブジェクトとの整合性が保証されない場合が発生する。
【０２７６】
例えば、拡張データの一種であるＰＲＧ＿ＩＮＦＯ８２０から参照されているメディアオブジェクトが編集され、その再生時間長が変化してしまう（例えば、再生時間が短くなる）と、プログラムの再生時間であるＰｌａｙＢａｃｋＤｕｒａｔｉｏｎが実際の値と異なってしまい、プログラム再生の実行の際にユーザに混乱を与えてしまう。
【０２７７】
そこでこの時、図２８で示す処理を実施する。
【０２７８】
まず、拡張情報処理部６１２は、編集対象のメディアオブジェク管理情報３０００からＲｅｆＶａｌｉｄＦｌａｇ３１００を読み出す（ステップＳ４０１）。
【０２７９】
ＲｅｆＶａｌｉｄＦｌａｇ３１００のフィールド長に応じた数だけ拡張オブジェクトが存在する可能性があるので、ステップＳ４０２からステップＳ４０９のループ処理により、存在するすべての拡張オブジェクトに対する処理を行う。
【０２８０】
次に、ループ処理のカウント値を初期化（ステップＳ４０２）する。
【０２８１】
そして、最初の拡張オブジェクトに対して、該メディアオブジェクトに対して参照する拡張オブジェクトが存在するかを判別する（ステップＳ２０３）。この判別は、該拡張オブジェクトに対応するＲｅｆＶａｌｉｄＦｌａｇ３１００中の２ビットの内、上位ビットの値により行われる。もし、参照が存在しない場合は、ステップ４０８へ進む。
【０２８２】
参照が存在した場合は、該拡張オブジェクトに対して、処理可能かどうかを判別する（ステップＳ４０４）。
【０２８３】
ある記録再生装置は、特定の種類の拡張オブジェクトしか操作できない場合があるので、もし、処理不可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトに対応するＲｅｆＶａｌｉｄＦｌａｇ３１００中の２ビットの内、下位ビットの値を０ｂに設定する（ステップＳ４０５）。これにより、該拡張オブジェクトと該メディアオブジェクトとの間での整合性を保障しない状態であることを示す。
【０２８４】
一方、処理可能な拡張オブジェクトであることがわかったら、該拡張オブジェクトの内容を更新し（ステップＳ４０６）、該拡張オブジェクトに対応するＲｅｆＶａｌｉｄＦｌａｇ３１００中の２ビットの内、下位ビットの値を１ｂに設定する（ステップＳ４０７）。ここで、拡張オブジェクトの内容を更新とは、例えば、メディアオブジェクトの編集に伴い、プログラムのＰｌａｙＢａｃｋＤｕｒａｔｉｏｎを更新する処理である。
【０２８５】
以降、カウント値を加算しながら、全てのＲｅｆＶａｌｉｄＦｌａｇ３１００に対して処理を繰り返す（ステップＳ４０８、ステップＳ４０９）。
【０２８６】
図２８のような処理が終了した後のＲｅｆＶａｌｉｄＦｌａｇ３１００に設定される値の例を図２９に示す。
【０２８７】
ここでは、一例として、拡張オブジェクトとしてプログラム再生のみを処理可能であり、他の種類の拡張オブジェクトの処理ができない記録再生装置による処理後の設定値の例を記す。ＲｅｆＶａｌｉｄＦｌａｇ３１００ビット２については１ｂのまま変化がなく、一方、ビット３が０ｂに設定され、この拡張オブジェクトからの参照は依然として存在するが、そのデータの有効性が保障されない状態であることを示している。
【０２８８】
以上のように、実施の形態１においては、拡張オブジェクト全体に対して有効かどうかをＶａｌｉｄフラグ７３１を用いて管理したが、本実施の形態においては、ＲｅｆＶａｌｉｄＦｌａｇ３１００の下位ビットを用いることにより、メディアオブジェクト及びＭＯ＿ＩＮＦＯ毎に有効性の管理が可能となり、拡張オブジェクト全体を更新せず、その一部だけを更新するような、より柔軟な管理が可能となる。
【０２８９】
また、図２４を用いて説明したのと同様、ＲｅｆＶａｌｉｄＦｌａｇ３１００の下位ビットの値を見る（すなわち、図２４のステップＳ３０４に相当する処理を実施する）ことにより、拡張オブジェクトの情報が有効な場合は通常処理を行い、有効性が保証されない場合は、適切な例外処理や書き込みの禁止、ユーザへのメッセージの表示などを行うことが可能である。
【０２９０】
このような構成は、特にメディアオブジェクトマネージャのデータ量が大きい場合、必ずしもその全体を更新しなくてよいので、データ処理量の効率化に有効である。
【０２９１】
なお、本実施の形態においては、ＲｅｆＶａｌｉｄＦｌａｇ３１００を３２ビット長としたが、他のデータ長でもよく、あるいは、可変長にすることも可能である。可変長にすることにより効率的に拡張オブジェクトの数の変化に対応可能となる。
【０２９２】
また、上記においては、ＲｅｆＶａｌｉｄＦｌａｇ３１００のビット０〜１をファイル番号が０００１番である拡張オブジェクトに対応するとしたが、ＲｅｆＶａｌｉｄＦｌａｇ３１００の各ビットと拡張オブジェクトとの対応関係についてはこれに限るものではない。例えば、ビット３０〜３１のようなＲｅｆＶａｌｉｄＦｌａｇ３１００の上位ビットにファイル番号が０００１番である拡張オブジェクトを対応させるようにしても良い。
【０２９３】
また、ＲｅｆＶａｌｉｄＦｌａｇ３１００と拡張オブジェクトをそのファイル番号により対応づけたが、他の方法による対応付けを行ってもよい。
【０２９４】
（実施の形態４）
本実施の形態では、更新日時情報を用いた拡張オブジェクトの有効性管理方法について述べる。
【０２９５】
図１５（ａ）で示したように、メディアオブジェクトマネージャ３２０には、その更新日時を示すＭｏｄＴｉｍｅ７０２が設けられている。メディアオブジェクトマネージャ３２０の内容が更新されるたびに、ＭｏｄＴｉｍｅ７０２の値も更新するものとする。
【０２９６】
一方、拡張オブジェクトにもその更新日時を示すＭｏｄＴｉｍｅ８１２が設けられている。ＭｏｄＴｉｍｅ８１３も同様に、拡張オブジェクトの内容が更新されるたびに、その値が更新されるものとする。
【０２９７】
ただし、図２３の処理手順で示したとおり、本発明の記録再生装置においては、処理可能な拡張オブジェクトのみをその内容を更新するものとする（図２３のステップＳ２０５）。
【０２９８】
これにより、メディアオブジェクトに対する編集操作等が行われると、メディアオブジェクトマネージャ３２０が更新され、さらに、処理可能な拡張オブジェクトのみが更新される。
【０２９９】
結果として、ＭｏｄＴｉｍｅ７０２の値と、処理可能な拡張オブジェクトのＭｏｄＴｉｍｅ８１３が一致する。一方、処理不可能な拡張オブジェクトは更新されないのでそのＭｏｄＴｉｍｅ８１３も更新されず、ＭｏｄＴｉｍｅ７０２の値と一致しなくなる。
【０３００】
よって、本発明の記録再生装置において、ある拡張オブジェクトを処理しようとする時、ＭｏｄＴｉｍｅ７０２の値とのＭｏｄＴｉｍｅ８１３の値を比較することにより、該拡張オブジェクトが有効であるかどうかを知ることができる。
【０３０１】
これはすなわち、図２４で示したＶａｌｉｄフラグの値が１ｂであるかどうかを調べる（図２４のステップＳ３０４）のと同様の効果があることを意味する。
【０３０２】
なお、図１７では、拡張オブジェクトとしてプログラムマネージャ３３０を用いて説明したが、他の拡張オブジェクトでも、ＭｏｄＴｉｍｅ８１３と同じフィールドを持つことにより同様の効果を得ること可能である。
【０３０３】
なお、上述の実施例において、ＭＯ＿ＩＮＦＯ７４０、２０００、３０００は、Ｐｒｏｐｅｒｔｙ  Ｅｎｔｒｙと呼ばれることもある。また、ＭｏＴｙｐｅ７４１及びＭｏＲｅｆ７４２をあわせて、Ｂｉｎａｒｙ  Ｆｉｌｅ  Ｉｄｅｎｔｉｆｉｅｒと呼ばれることもある。また、ＭｏＵｎｉｑｕｅＩＤ７４３は、ｅｎｔｒｙ＿ｎｕｍｂｅｒと呼ばれることもある。また、拡張オブジェクトはメーカ独自ファイル、あるいは、プライベートファイルと呼ばれることもある。また、ＲｅｆＶａｌｉｄＦｌａｇ３１００は、ｖｆｌａｇｓと呼ばれることもある。
【０３０４】
なお、上述したいずれの実施の形態においても、記録再生装置及び記録媒体をＤＶＤのような光ディスクメディアを例に挙げて説明しているが、特に限定されるものではなく、その他磁気記録メディアを用いたハードディスクドライブ、光磁気ディスクメディア等、他の記録装置や記録媒体であっても良い。
【０３０５】
以上のように、本発明にかかる記録再生装置及び方法によれば、拡張機能のためのデータ追加を効率的に行える。これは、ＤＶＤレコーダやＤＶＤビデオカメラのような民生の家電機器等のハードウエア資源が限られる記録再生装置において望ましい構成である。また、メディアオブジェクトの編集や削除を行った場合に、統一規格では定められていないため、ある記録再生装置では対応していない拡張機能または拡張オブジェクトが存在しても、データの不整合を最小限に抑制し、かつ、適切なデータ処理方法を決定可能となり、機器の誤動作やシステム停止、ユーザに対する利便性の低下等を回避することが可能となる。
【０３０６】
特に、ＤＶＤレコーダやＤＶＤビデオカメラなどの可搬型の記録媒体を用いた民生用の記録再生装置では、１つの記録媒体が複数の製造メーカによる異なる拡張機能を持った記録再生装置で記録・再生されることが想定される。よって、本発明にかかる記録再生装置及び方法により、より大きな効果を得ることが可能となる。
【０３０７】
なお、上記の実施形態では、本発明の側面のうち、主に、記録装置、再生装置、記録媒体、記録方法、再生方法に関する実施形態を説明した。しかし、本発明は、他の側面として、前記記録装置の記録動作を制御するプログラム、前記再生装置の再生動作を制御するプログラム、これらのプログラムの提供媒体（プログラム製品）、および、記録媒体に記録されたデータ構造、としても実施することが可能である。当業者であれば、上述の実施形態の説明から、これらの側面の実施形態についても容易に理解することが可能であろう。
【産業上の利用可能性】
【０３０８】
本発明は、これらに限定されないが、例えばＤＶＤ等の記録媒体や、ＤＶＤレコーダやＤＶＤビデオカメラ等の記録・再生装置に利用可能である。
【図面の簡単な説明】
【０３０９】
【図１】図１は、本発明の実施の形態１にかかる記録再生装置の外観と関連機器とのインタフェースの例示図である。
【図２】図２は、本発明の実施の形態１にかかる記録再生装置に組み込まれるドライブ装置１１０とその周辺の概略構成を示すブロック図である。
【図３】図３は、本発明の実施の形態１にかかる記録再生装置の構成の一例を示すブロック図である。
【図４】図４は、本発明の実施の形態１にかかる記録再生装置の構成の他の例を示すブロック図である。
【図５】図５は、本発明の実施の形態１にかかる記録再生装置の構成のさらに他の例を示すブロック図である。
【図６】図６は、本発明の実施の形態１にかかる記録再生装置の構成のさらに他の例を示すブロック図である。
【図７（ａ）】図７（ａ）は、記録可能なディスクメディア１００の記録領域を表した図である。
【図７（ｂ）】図７（ｂ）は、図７（ａ）において同心円状に示されるリードイン領域と、リードアウト領域と、データ領域を横方向に配置した説明図である。
【図７（ｃ）】図７（ｃ）は、論理セクタにより構成されるディスクメディア１００の論理的なデータ空間を示す図である。
【図８】図８は、ディスクメディア１００に記録されるディレクトリとファイルの階層構造を示す図である。
【図９（ａ）】図９（ａ）は、ＵＤＦ規格におけるディレクトリ階層を管理するためのデータ構造の例示図である。
【図９（ｂ）】図９（ｂ）は、ＵＤＦ規格におけるディレクトリ階層を管理するためのデータ構造のパーティション空間内での配置の例示図である。
【図１０（ａ）】図１０（ａ）は、ＵＤＦ規格で定義されるファイルセットディスクリプタＦＳＤのデータ構造の例示図である。
【図１０（ｂ）】図１０（ｂ）は、ＵＤＦ規格で定義されるｌｏｎｇ＿ａｄのデータ構造の例示図である。
【図１０（ｃ）】図１０（ｃ）は、ＵＤＦ規格で定義されるＡＤＩｍｐＵｓｅのデータ構造の例示図である。
【図１１（ａ）】図１１（ａ）は、ＵＤＦ規格で定義される拡張ファイルエントリのデータ構造の例示図である。
【図１１（ｂ）】図１１（ｂ）は、ＵＤＦ規格で定義されるＡｌｌｏｃａｔｉｏｎ  Ｄｅｓｃｒｉｐｔｏｒのデータ構造の例示図である。
【図１１（ｃ）】図１１（ｃ）は、ＵＤＦ規格で定義されるファイル識別記述子ＦＩＤのデータ構造の例示図である。
【図１２（ａ）】図１２（ａ）は、ＵＤＦ規格で定義されるＩｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ  Ｅｘｔｅｎｄｅｄ  Ａｔｔｒｉｂｕｔｅのデータ構造を示す図である。
【図１２（ｂ）】図１２（ｂ）は、Ｉｍｐｌｅｍｅｎｔａｔｉｏｎ  Ｕｓｅ２１００中に格納される拡張属性のデータ構造を示す図である。
【図１３（ａ）】図１３（ａ）は、ディスクメディア１００上のアドレス空間を示す図である。
【図１３（ｂ）】図１３（ｂ）は、トラックバッファに蓄積してあるデータをデコーダへ供給することでＡＶデータの連続再生が可能になる時の状態を示した図である。
【図１４】図１４は、ディスクメディア１００上に記録されるデータの階層構造と、それらを処理するシステム制御部１０４及びその内部構造を示す図である。
【図１５（ａ）】図１５（ａ）は、本発明の実施の形態１にかかる記録再生装置におけるメディアオブジェクトマネージャ３２０のデータ構造の例示図である。
【図１５（ｂ）】図１５（ｂ）は、本発明の実施の形態１にかかる記録再生装置における拡張オブジェクト管理情報（ＥＯ＿ＩＮＦＯ）７２０のデータ構造の例示図である。
【図１５（ｃ）】図１５（ｃ）は、属性フラグ  ７２４に設定される値の例示図である。
【図１６（ａ）】図１６（ａ）は、本発明の実施の形態１にかかる記録再生装置におけるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）７００のデータ構造の例示図である。
【図１６（ｂ）】図１６（ｂ）は、ＭｏＴｙｐｅ７４１に設定される値の例示図である。
【図１６（ｃ）】図１６（ｃ）は、ＯＢＪ＿ＩＤ型のフィールドへ値を設定するときの変換規則の例示図である。
【図１７（ａ）】図１７（ａ）は、本発明の実施の形態１にかかる記録再生装置におけるプログラムマネージャ３３０のデータ構造の例示図である。
【図１７（ｂ）】図１７（ｂ）は、本発明の実施の形態１にかかる記録再生装置におけるプログラム情報（ＰＲＧ＿ＩＮＦＯ）８００のデータ構造の例示図である。
【図１８】図１８は、ディレクトリ及びメディアオブジェクトとＭＯ＿ＩＮＦＯ７００との関係を示す図である。
【図１９】図１９は、メディアオブジェクトマネージャ３２０に対するプログラムマネージャ３３０の関係を示す図である。
【図２０】図２０は、本発明の実施の形態１におけるディレクトリ及びメディアオブジェクトとメディアオブジェクトマネージャ３２０と拡張オブジェクトの関係を示す図である。
【図２１（ａ）】図２１（ａ）は、拡張オブジェクト管理情報テーブル７１０に設定される値の一例である。
【図２１（ｂ）】図２１（ｂ）は、拡張オブジェクト管理情報テーブル７１０に設定される値の他の例である。
【図２２】図２２は、本発明の実施の形態１にかかる記録再生装置における拡張情報の記録処理を示すフローチャートである。
【図２３】図２３は、本発明の実施の形態１にかかる記録再生装置における拡張情報の管理処理を示すフローチャートである。
【図２４】図２４は、本発明の実施の形態１にかかる記録再生装置における拡張情報の再生処理を示すフローチャートである。
【図２５】図２５は、本発明の実施の形態２におけるディレクトリ及びメディアオブジェクトとメディアオブジェクトマネージャ３２０と拡張オブジェクトの関係を示す図である。
【図２６（ａ）】図２６（ａ）は、本発明の実施の形態２にかかる記録再生装置におけるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）２０００のデータ構造の例示図である。
【図２６（ｂ）】図２６（ｂ）は、本発明の実施の形態２にかかる記録再生装置における拡張オブジェクト管理情報（ＥＯ＿ＩＮＦＯ）２１００のデータ構造の例示図である。
【図２７（ａ）】図２７（ａ）は、本発明の実施の形態３にかかる記録再生装置におけるメディアオブジェクト管理情報（ＭＯ＿ＩＮＦＯ）３０００のデータ構造の例示図である。
【図２７（ｂ）】図２７（ｂ）は、拡張データ属性フラグ３１００に設定される値の例示図である。
【図２８】図２８は、本発明の実施の形態３にかかる記録再生装置における拡張データ属性フラグの管理処理を示すフローチャートである。
【図２９】図２９は、拡張データ属性フラグ３１００に設定される値の例示図である。
【図３０】図３０は、従来のディレクトリ及びメディアオブジェクトとプログラムファイル１０００２との関係を示す図である。
【図３１】図３１は、従来のディレクトリ及びビットストリームファイルと情報ファイルとの関係を示す図である。
【国際調査報告】
2004095285.tif 000036
2004095285.tif 000037
2004095285.tif 000038
2004095285.tif 000039