データ記録方法、データ再生方法、データ記録装置、データ再生装置、データ記録媒体、プログラム、およびそのプログラムを格納した記録媒体
本データ記録装置は、インデックス情報に、各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報（フラグ）を設けることにより、インデックス表示画面で拡張付加情報の有無を表示する。よって、実際にコンテンツにアクセスして拡張付加情報の有無を確認する手間を省略することでき、より簡易に拡張付加情報の有無を確認することができる。
【発明の詳細な説明】
【技術分野】
本発明は、ハードディスク、光ディスク、半導体メモリ等のランダムアクセス可能な記録媒体に対して、映像データ、音声データ等を記録するデータ記録方法、データ記録装置、データ記録媒体、データ再生方法、データ再生装置、プログラム、およびそのプログラムを格納した記録媒体に関するものである。
【背景技術】
近年、光ディスク等のメディアに記録されたコンテンツのディジタル記録再生装置（以下、ビデオディスクレコーダと呼ぶ）が普及しつつある。そして、メディアへのコンテンツの記録フォーマットとして、ＰＣで広く使われているフォーマット、たとえばＱｕｉｃｋＴｉｍｅファイルフォーマットやＡＶＩ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｉｎｔｅｒｌｅａｖｅ）ファイルフォーマットを用いることが広く行われる。これにより、映像データとＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）との親和性が高められている。
このようなＰＣ用ファイルフォーマットを用いた場合における光ディスク内でのコンテンツの管理方法について、日本国公開特許公報「特開２００１−８４７０５公報（公開日２００１年３月３０日）」に開示された技術がある。以下、図３６を用いて、その概要を説明する。
ディスク３０５に記録されたコンテンツファイル３０１・３０２・３０３は、録画した各シーンあるいはコンテンツに対応するファイルであり、それぞれ１個のＱｕｉｃｋＴｉｍｅファイル（以下、ＱｕｉｃｋＴｉｍｅムービーファイルと呼ぶ）である。
また、インデックスファイル３００は、ディスク３０５内のデータの目次的な情報を格納するファイルであり、各ＱｕｉｃｋＴｉｍｅムービーファイル毎にエントリを有している。なお、各エントリには、対応するシーンの代表画面の縮小画像データ３１１・３１２・３１３と、対応するシーンが含まれるファイルのファイル名とが格納されている。
そして、ユーザにインデックス画面を提示する際、ビデオディスクレコーダは、各エントリの縮小画像データ３１１〜３１３をデコードした縮小画像３２１〜３２３を、コンテンツ選択画面３０７に表示する。ユーザは、コンテンツ選択画面３０７に表示されている複数の縮小画像３２１〜３２３の中から、再生や編集をしたいファイルを選択する。
たとえば、ユーザが縮小画像３２３を選択し、再生を指示した場合、ビデオディスクレコーダは、縮小画像３２３に対応するコンテンツの含まれるファイルのファイル名であるファイル３０３を取得し、ファイル３０３の再生を開始する。
さらに、インデックスファイル３００には、ディスク３０５中のすべてのコンテンツに関して、コンテンツを格納したファイルへのポインタと、縮小画像データとが含まれている。したがって、ビデオディスクレコーダは、インデックスファイル３００をディスク３０５から読み出すだけで、コンテンツ選択画面３０７の表示が可能である。その結果、上記公報の技術は、インデックス画面表示に要する時間が少なくて済むという利点がある。
ところで、コンテンツ選択画面３０７は頻繁に表示するものであるので、コンテンツ選択画面３０７の表示時間を削減すれば、ユーザが体感するビデオディスクレコーダの反応速度（以下、体感レスポンスという）は大きく向上する。
そこで、従来のビデオディスクレコーダにおいては、ディスク挿入時における体感レスポンスを向上させるため、各コンテンツに対応する縮小画像や撮影時刻などのコンテンツの内容を表す付加情報をインデックスファイルに格納し、該インデックスファイルに基づき縮小画像や基本的な情報のみがコンテンツ選択画面３０７に一覧表示されていた。
ところが、従来技術におけるコンテンツ選択画面３０７のような縮小画像の一覧表示だけからは、コンテンツファイル内に、インデックスファイルに格納されている情報以外の付加情報（以下、拡張付加情報という）が含まれているかどうかを判断することができない。すなわち、実際にコンテンツにアクセスしてみなければ、拡張付加情報の有無すら確認することができないという問題がある。
本発明は、上記従来の問題点に鑑みなされたものであって、その目的は、各コンテンツにおける拡張付加情報の有無を、より簡易に確認することができるデータ記録方法、データ再生方法、データ記録装置、データ再生装置、データ記録媒体、プログラム、およびそのプログラムを格納した記録媒体を提供することにある。
【発明の開示】
本発明のデータ記録方法は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を、記録媒体に記録するデータ記録方法において、上記インデックス情報が、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含む。
また、本発明のデータ記録装置は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を、記録媒体に記録するデータ記録装置において、上記インデックス情報が、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含む。
上記構成によれば、インデックス情報は、拡張付加情報がコンテンツに付加されているか否かに関する識別情報を含んでいる。したがって、各コンテンツに直接アクセスしなくても、インデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを識別情報に基づき把握することができる。なお、拡張付加情報とは、ＡＶデータが記録された場所のＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）情報や温度、ＡＶデータについてユーザにより追加されたコメントや、ＡＶデータの作者、出演者等の、ＡＶデータについてより具体的な内容を表す情報である。
ここで、本発明において、インデックス情報にアクセスして各コンテンツに対する拡張付加情報の有無を判断する処理に要する時間は、従来技術において、各コンテンツのＡＶデータもしくはＡＶデータと管理情報をそれぞれ開いた後に、該コンテンツに拡張付加情報が付加されているか否かを判断する処理に要していた時間よりも短い。
それゆえ、各コンテンツにおける拡張付加情報の有無を、より簡易に確認することができる。
また、本発明のデータ記録方法は、上記構成において、上記拡張付加情報が、動画サムネイルデータであってもよい。
上記構成によれば、インデックス画面を静止画サムネイルにより表示するので、ビデオディスクレコーダの体感レスポンスは低下しない。また、識別情報に基づいて拡張付加情報が存在すると把握されたコンテンツのみについて拡張付加情報としての動画サムネイルデータを読み出し、インデックス画面を静止画サムネイルから動画サムネイルに切り替えることができる。また、動画サムネイルによれば、静止画サムネイルよりも具体的にコンテンツの内容を確認することができる。
それゆえ、ビデオディスクレコーダの体感レスポンスを低下させることなく、複数のコンテンツの内容をより詳細にユーザに提示することができる。
また、本発明のデータ記録方法は、上記構成において、上記各コンテンツの所定領域に、上記拡張付加情報を含んでいてもよい。
上記構成によれば、多くの拡張付加情報がコンテンツに付加されている場合でも、各コンテンツにおける所定領域（Ｕｓｅｒ ｄａｔａ ａｔｏｍ）を参照することにより、拡張付加情報の内容を把握することができる。つまり、拡張付加情報の内容を把握するために、拡張付加情報がどの場所に格納されているかということを探索するための時間を省略することができる。
したがって、インデックス表示の体感レスポンスを落とさずに、より多くの拡張付加情報をすばやく参照することができる。
また、本発明のデータ記録方法は、上記構成において、上記拡張付加情報を、上記各コンテンツを記録する記録媒体の領域と別の領域に記録してもよい。
上記構成によれば、拡張付加情報を、記録媒体においてコンテンツが記録されている領域とは別の領域から読み出すことができる。したがって、拡張付加情報のみを容易に読み出すことができる。
また、本発明のデータ記録方法は、上記構成において、上記識別情報を、上記拡張付加情報の種別毎に設定してもよい。
上記構成によれば、拡張付加情報の種別毎に、各コンテンツにおける拡張付加情報の有無を把握することができる。したがって、より詳細に拡張付加情報の有無を確認することができる。
また、本発明のデータ記録方法は、上記構成において、上記識別情報が、上記拡張付加情報を再生可能な機器に関する情報を含んでいてもよい。
上記構成によれば、識別情報に基づき、拡張付加情報を再生可能な機器を把握することができる。したがって、現在コンテンツを再生している機器が、拡張付加情報を再生可能な機器であるか否かを判断することができる。
それゆえ、たとえば現在コンテンツを再生している機器が、拡張付加情報を再生できる機器である場合にのみ、インデックス画面に拡張付加情報の有無を表示するというように、より効率的に拡張付加情報の有無の確認を行うことができる。
また、本発明のデータ記録方法は、上記の構成に加えて、上記識別情報は、拡張付加情報が付加されていない状態と、拡張付加情報が付加されている、あるいは付加されているかどうか不明である状態とのどちらかを示す情報を含んでいてもよい。
上記構成によれば、識別情報に基づき、拡張付加情報を得るためにコンテンツにアクセスする必要があるかないかを即座に把握するこができる。また、存在するという状態を保証する必要がないため、付加情報の記録・編集時にＡＶ Ｉｎｄｅｘとコンテンツファイルの付加情報を比較し、拡張付加情報がコンテンツファイルに含まれるかどうかを調べるという処理を常に行わなくてもよい。
また、本発明のデータ再生方法は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生方法において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、上記識別情報に基づき、上記拡張付加情報の読み出しを制御する。
また、本発明のデータ再生装置は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生装置において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、上記識別情報に基づき、上記拡張付加情報の読み出しを制御する制御手段を備えている。
上記構成によれば、インデックス情報は、拡張付加情報がコンテンツに付加されているか否かに関する識別情報を含んでいる。したがって、各コンテンツのＡＶデータに直接アクセスしなくても、インデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを、識別情報に基づき把握することができる。
それゆえ、識別情報に基づきより簡易に拡張付加情報の有無を把握し、より迅速に拡張付加情報の読み出しを行うことが可能となる。
また、本発明のデータ再生方法は、上記構成において、上記インデックス情報を読み出した後で、ユーザによる上記拡張付加情報の表示の指示前に、該拡張付加情報を読み出してもよい。
すなわち、多くのユーザは、インデックス画面により複数のコンテンツの内容を確認した後に、各コンテンツに拡張付加情報が付加されているか否かを判断する傾向がある。
上記構成によれば、インデックス情報を読み出した後で、ユーザによる上記拡張付加情報の表示の指示前に、各コンテンツの識別情報に基づき拡張付加情報を予め読み出す。したがって、インデックス画面の表示後に、ユーザの指示により拡張付加情報の表示があった場合に、すばやく拡張付加情報を表示させることができる。
また、本発明のデータ再生方法は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生方法において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、上記識別情報を表示する。
また、本発明のデータ再生装置は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生装置において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、上記識別情報を表示する表示手段を備えている。
上記構成によれば、インデックス情報は、拡張付加情報がコンテンツに付加されているか否かに関する識別情報を含んでいる。したがって、各コンテンツに直接アクセスしなくても、インデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを、識別情報に基づき把握することができる。
それゆえ、表示された識別情報により、コンテンツに拡張付加情報が付加されているか否かをより簡易にユーザに視認させることができる。
また、本発明のデータ記録媒体は、ＡＶデータを含む複数のコンテンツのインデックス情報が記録されたデータ記録媒体において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含む。
上記構成によれば、データ記録媒体に記録されたインデックス情報は、拡張付加情報がコンテンツに付加されているか否かに関する識別情報を含んでいる。したがって、各コンテンツに直接アクセスしなくても、本発明によるデータ記録媒体のインデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを識別情報に基づき把握することができる。
それゆえ、各コンテンツにおける拡張付加情報の有無を、より簡易に確認することができる。
また、本発明のプログラムは、上記記載のデータ記録方法またはデータ再生方法をコンピュータに実行させるプログラムである。さらに、本発明のコンピュータ読み取り可能な記録媒体は、上記プログラムを格納している。
本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。
【図面の簡単な説明】
図１は、本発明の実施形態に係るビデオディスクレコーダの概略構成図である。
図２（ａ）は、管理情報とメディアデータとが同じファイルに存在する場合における、ＱｕｉｃｋＴｉｍｅファイルフォーマットの管理情報とＡＶストリームとの関係を示す図である。
図２（ｂ）は、管理情報とメディアデータとが別々のファイルに存在する場合における、ＱｕｉｃｋＴｉｍｅファイルフォーマットの管理情報とＡＶストリームとの関係を示す図である。
図２（ｃ）は、複数のＡＶストリームファイルに対する外部参照する場合における、ＱｕｉｃｋＴｉｍｅファイルフォーマットの管理情報とＡＶストリームとの関係を示す図である。
図３は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ ａｔｏｍの概要を示す図である。
図４は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ａｔｏｍの概要を示す図である。
図５は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を示す図である。
図６は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ ａｔｏｍの構成を示す図である。
図７は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍの構成を示す図である。
図８は、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍによるデータ管理の例を示す図である。
図９は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構成を示す図である。
図１０は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＥｄｉｔ ａｔｏｍの構成を示す図である。
図１１（ａ）は、Ｅｄｉｔ ａｔｏｍによる再生範囲指定の例を示す図である。
図１１（ｂ）は、サンプルの構成の例を示す図である。
図１１（ｃ）は、実際のサンプルの再生順の例を示す図である。
図１２は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＵｓｅｒ ｄａｔａ ａｔｏｍの構成を示す図である。
図１３は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＵｓｅｒ ｄａｔａのｔｙｐｅの種類を示す図である。
図１４は、本発明の各実施形態におけるＡＶストリームの構成を示す図である。
図１５は、本発明の各実施形態におけるＶＵの構成を示す図である。
図１６は、本発明の各実施形態におけるＱｕｉｃｋＴｉｍｅによるＡＶストリーム管理形態を示す図である。
図１７（ａ）は、ファイルのディレクトリ構成を示す図である。
図１７（ｂ）は、図１７（ａ）に示すディレクトリ／ファイル構成をＵＣＦで記録した例を示す図である。
図１８は、本発明の第１の実施形態における、ＡＶ Ｉｎｄｅｘファイルの構成を示す図である。
図１９は、本発明の第１の実施形態における属性情報の構成を示す図である。
図２０は、本発明の第１の実施形態におけるｆｌａｇｓの構成を示す図である。
図２１は、本発明の第１の実施形態における全体の処理の流れを示すフローチャートである。
図２２は、本発明の第１の実施形態におけるユーザ指示による各種処理の流れを示すフローチャートである。
図２３（ａ）は、光ディスクに記録されたファイルのディレクトリ構成を示す図である。
図２３（ｂ）は、記録媒体上の記録状態の例を示す図である。
図２４は、本発明の第１の実施形態における、ディスク挿入直後のＡＶ Ｉｎｄｅｘ管理テーブルの例を示す図である。
図２５は、本発明の第１の実施形態における、録画直後のＡＶ Ｉｎｄｅｘ管理テーブルの例を示す図である。
図２６は、本発明の第１の実施形態における、付加情報変更処理を示すフローチャートである。
図２７は、本発明の第１の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新処理を示すフローチャートである。
図２８は、本発明の第１の実施形態におけるＡＶ Ｉｎｄｅｘファイル読み出し処理を示すフローチャートである。
図２９は、本発明の第１の実施形態におけるインデックス表示画面の例を示す図である。
図３０は、本発明の第１の実施形態における拡張付加情報表示画面の例を示す図ある。
図３１は、本発明の第１の実施形態におけるフラグの第２の構成を示す図である。
図３２は、本発明の第１の実施形態における第２のインデックス表示画面の例を示す図である。
図３３は、本発明の第２の実施形態におけるフラグの構成を示す図である。
図３４は、本発明の第３の実施形態におけるフラグの構成を示す図である。
図３５は、本発明の第３の実施形態における、拡張付加情報有無のフラグ変更条件を示す図である。
図３６は、従来技術におけるインデックスファイルを示す図である。
【発明を実施するための最良の形態】
以下、実施例および比較例により、本発明をさらに詳細に説明するが、本発明はこれらにより何ら限定されるものではない。
以下、本発明の実施の一形態について、図面を参照しながら説明すれば以下の通りである。なお、以下の説明では、本発明の複数の実施形態において共通に用いるビデオディスクレコーダの構成を説明した後、各実施形態に固有の特徴点を説明する。
〔ビデオディスクレコーダの構成について〕
ビデオディスクレコーダは、図１に示すように、制御手段としてのホストＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３と、ユーザインタフェース４と、システムクロック５と、光ディスク６と、ピックアップ７と、ＥＣＣ（Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｎｇ Ｃｏｄｉｎｇ）デコーダ８と、ＥＣＣエンコーダ９と、再生用バッファ１０と、記録／アフレコ用バッファ１１と、デマルチプレクサ１２と、マルチプレクサ１３と、多重化用バッファ１４と、オーディオデコーダ１５と、ビデオデコーダ１６と、オーディオエンコーダ１７と、ビデオエンコーダ１８とを備えている。さらに、ビデオディスクレコーダは、図示しないカメラ、マイク、スピーカ、あるいはディスプレイ（表示手段）等を備えている。
ホストＣＰＵ１は、バス１９を通じて、ピックアップ７と、デマルチプレクサ１２と、マルチプレクサ１３と、オーディオデコーダ１５と、ビデオデコーダ１６と、オーディオエンコーダ１７と、ビデオエンコーダ１８との制御を行う。
また、ホストＣＰＵ１は、再生中のデータに関する管理情報に基づき、オーディオデコーダ１５とビデオデコーダ１６とからのデータ送信要求に従い、再生用バッファ１０内のデータを、データ種別に対応するデコーダに振り分けるよう、デマルチプレクサ１２に指示を与える。
上記構成により、ビデオディスクレコーダは、光ディスク６の再生時において、光ディスク６からピックアップ７を通じて光ディスク６に格納されたデータを読み出すとともに、読み出したデータをＥＣＣデコーダ８により誤り訂正した後、再生用バッファ１０に一旦蓄える。
一方、ビデオディスクレコーダは、光ディスク６の記録時において、オーディオエンコーダ１７とビデオエンコーダ１８とを用いて、光ディスク６に記録すべきデータを圧縮符号化するとともに、圧縮符号化されたデータを多重化用バッファ１４に一旦送信する。その後、ビデオディスクレコーダは、多重化用バッファ１４に送信されたデータをマルチプレクサ１３を用いてＡＶ多重化した後、記録／アフレコ用バッファ１１に送信する。そして、ビデオディスクレコーダは、記録／アフレコ用バッファ１１内のデータを、ＥＣＣエンコーダ９を用いて誤り訂正符号を付加した後、ピックアップ７を通じて光ディスク６に記録する。
なお、オーディオデータの符号化方式としてＭＰＥＧ−１ Ｌａｙｅｒ−ＩＩを、ビデオデータの符号化方式としてＭＰＥＧ−２をそれぞれ用いた。また、これらの符号化方式では、２０４８ｂｙｔｅを１セクタとするとともに、誤り訂正のためのＥＣＣブロックを１６セクタで構成する。
〔ファイルフォーマットについて〕
本発明でＡＶストリーム管理のためのフォーマットとして用いる、ＱｕｉｃｋＴｉｍｅファイルフォーマットについて説明する。なお、ＱｕｉｃｋＴｉｍｅファイルフォーマットとは、Ａｐｐｌｅ社が開発したマルチメディアデータ管理用フォーマットのことであり、ＰＣの世界で広く用いられている。
ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータとも呼ぶ）と、管理情報とで構成される。メディアデータと、管理情報とを組み合わせたものを、ＱｕｉｃｋＴｉｍｅムービーと呼ぶ。また、ＱｕｉｃｋＴｉｍｅムービーは、単にムービーと呼ぶ場合もある。なお、メディアデータと、管理情報とは、同じファイル中に存在しても、別々のファイルに存在してもよい。
メディアデータと、管理情報とが同じファイル中に存在する場合、ＱｕｉｃｋＴｉｍｅムービーは、図２（ａ）に示すような構成をとる。すなわち、ＱｕｉｃｋＴｉｍｅムービーにおける各種情報は、ファイル２１内のａｔｏｍという共通の構造に格納される。たとえば、ＱｕｉｃｋＴｉｍｅムービーにおける管理情報は、Ｍｏｖｉｅ ａｔｏｍという構造に格納され、一方、メディアデータはＭｏｖｉｅ ｄａｔａ ａｔｏｍという構造に格納される。なお、図２（ａ）において「ＡＨ」と記載されているのは、Ａｔｏｍ Ｈｅａｄｅｒの略である。
また、Ｍｏｖｉｅ ａｔｏｍ中の管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。
一方、管理情報とメディアデータを別々のファイルに格納した場合、ＱｕｉｃｋＴｉｍｅムービーは、図２（ｂ）に示すような構成をとる。すなわち、管理情報はファイル２２におけるＭｏｖｉｅ ａｔｏｍという構造に格納されるが、メディアデータはａｔｏｍには格納される必要はない。つまり、メディアデータは、ファイル２２とは別のファイル２３にＡＶストリームとして格納される。
このように、管理情報とメディアデータとが別々のファイルに格納されているとき、Ｍｏｖｉｅ ａｔｏｍは、メディアデータを格納したファイルを「外部参照」しているという。
外部参照は、図２（ｃ）に示すように、複数のＡＶストリームファイル２５・２６に対して行うことが可能である。これにより、ＡＶストリーム自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」あるいは「非破壊編集」が可能となる。
次に、図３ないし図１３を用いて、ＱｕｉｃｋＴｉｍｅムービーにおける管理情報のフォーマットについて説明する。
先ず、共通の情報格納フォーマットであるａｔｏｍについて説明する。
ａｔｏｍの先頭には、そのａｔｏｍのサイズを表すＡｔｏｍ ｓｉｚｅと、そのａｔｏｍの種別情報を表すＴｙｐｅとが必ず存在する。Ｔｙｐｅは４文字で区別され、たとえばＭｏｖｉｅ ａｔｏｍでは‘ｍｏｏｖ’、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍでは‘ｍｄａｔ’となっている。このように、ａｔｏｍの先頭にあるＡｔｏｍ ｓｉｚｅとＴｙｐｅとを、ａｔｏｍ ｈｅａｄｅｒと呼ぶ。
また、ａｔｏｍは、別のａｔｏｍを含むことができる。すなわち、ａｔｏｍ間には階層構造がある。
ａｔｏｍの一例としてのＭｏｖｉｅ ａｔｏｍの構成を図３に示す。Ｍｏｖｉｅ ａｔｏｍは、図３に示すように、Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍと、Ｔｒａｃｋ ａｔｏｍと、Ｕｓｅｒ ｄａｔａ ａｔｏｍとが含まれている。
Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍは、Ｍｏｖｉｅ ａｔｏｍが管理するムービーの全体的な属性を管理するａｔｏｍである。Ｔｒａｃｋ ａｔｏｍは、ムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納するａｔｏｍである。Ｕｓｅｒ ｄａｔａ ａｔｏｍは、メーカが独自に定義可能なａｔｏｍである。
Ｔｒａｃｋ ａｔｏｍの構成を図４に示す。Ｔｒａｃｋ ａｔｏｍは、図４に示すように、Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍと、Ｅｄｉｔ ａｔｏｍと、Ｔｒａｃｋ ｒｅｆｅｒｅｎｃｅ ａｔｏｍと、Ｍｅｄｉａ ａｔｏｍとを含んでいる。
Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、トラックの全体的な属性を管理するａｔｏｍである。Ｅｄｉｔ ａｔｏｍは、メディアデータの各区間について、ムービーにおいて再生すべきタイミングを管理するａｔｏｍである。Ｔｒａｃｋ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、他のトラックとの関係を管理するａｔｏｍである。Ｍｅｄｉａ ａｔｏｍは、ビデオやオーディオといった、メディアに関するデータ（メディアデータ）を管理する。
Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を図５に示す。なお、Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成については、主要なものについてのみ説明する。Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、図５に示すように、Ｆｌａｇｓと、Ｌａｙｅｒとを含んでいる。
Ｆｌａｇｓは、トラックの属性を示すフラグの集合である。フラグの代表的なものとしては、Ｔｒａｃｋ ｅｎａｂｌｅｄフラグを挙げることができる。Ｔｒａｃｋ ｅｎａｂｌｅｄフラグが１であれば、そのトラックは再生され、Ｔｒａｃｋ ｅｎａｂｌｅｄフラグが０であれば、そのトラックは再生されない。
Ｌａｙｅｒは、トラックの空間的な優先度を表すものである。たとえば画像を表示するトラックが複数ある場合においては、Ｌａｙｅｒの値が小さいトラックほど、対応する画像が前面に表示される。
Ｍｅｄｉａ ａｔｏｍの構成を図６に示す。Ｍｅｄｉａ ａｔｏｍは、図６に示すように、Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍと、Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍと、Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍとを含んでいる。
Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍの管理するメディアデータに関する全体的な属性等を管理するものである。Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、メディアデータをどのデコーダでデコードするかを示す情報を格納するものである。Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、ビデオやオーディオ等のメディアに固有の属性情報を管理するものである。
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍの構成を図７に示す。Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、図７に示すように、Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ｈｅａｄｅｒ ａｔｏｍと、Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍと、Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍと、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍとを含んでいる。
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ｈｅａｄｅｒ ａｔｏｍは、ビデオやオーディオ等のメディアについて固有の属性情報を管理するものである。Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍについての説明で記載した通り、メディアデータをどのデコーダでデコードするかを示す情報を格納するものである。Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、そのＱｕｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名前を管理するａｔｏｍである、Ｄａｔａ ｒｅｆｅｒｅｎｃｅ ａｔｏｍを含むものである。Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、データのサイズや、再生時間等を管理するものである。
ところで、ＱｕｉｃｋＴｉｍｅフォーマットでは、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンク（ｃｈｕｎｋ）と呼ぶ。チャンクには、再生時間順に１から番号が付与されており、この番号により、個々のｃｈｕｎｋのファイル先頭からのアドレスを把握することができる。
また、ＱｕｉｃｋＴｉｍｅフォーマットでは、データの最小単位（たとえばビデオフレーム）をサンプル（Ｓａｍｐｌｅ）と呼ぶ。さらに、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のトラックのサンプルに、再生時間順に１から番号（サンプル番号）を付与することにより、サンプル数を管理している。
さらに、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のサンプルの再生時間長とデータサイズ（ｓａｍｐｌｅ ｓｉｚｅ）とを管理している。
つまり、図８に示すように、ファイル３１に含まれるｃｈｕｎｋには、再生時間順に１から番号が付けられている。さらに、たとえばｍ番のｃｈｕｎｋには、サンプル番号がｊからｉまでの複数のＳａｍｐｌｅが含まれている。
このように、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のチャンクのファイル先頭からのアドレスと、個々のチャンクが含むサンプル数とを管理している。これらの情報に基づき、ＱｕｉｃｋＴｉｍｅフォーマットでは、任意の時間に対応するサンプルの位置を求めることが可能となっている。
次に、Ｓａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍの構成について説明する。Ｓａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍは、図９に示すように、Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍと、Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ ａｔｏｍと、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍと、Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ ａｔｏｍと、Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍと、Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍとを含んでいる。
Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍは、個々のチャンクのデータフォーマット（Ｄａｔａ ｆｏｒｍａｔ）やサンプルが格納されているファイルのチャンクのＩｎｄｅｘ等を管理するものである。Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルの再生時間を管理する。
Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルのうち、デコード開始可能なサンプルを管理するものである。Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ ａｔｏｍは、個々のチャンクに含まれるサンプル数を管理するものである。Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍは、個々のサンプルのサイズを管理するものである。Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍは、個々のチャンクのファイル先頭からのアドレスを管理するものである。
Ｅｄｉｔ ａｔｏｍは、図１０に示すように、１個のＥｄｉｔ ｌｉｓｔ ａｔｏｍを含むものである。Ｅｄｉｔ ｌｉｓｔ ａｔｏｍは、Ｎｕｍｂｅｒ ｏｆ ｅｎｔｒｉｅｓで指定される個数分の、Ｔｒａｃｋ ｄｕｒａｔｉｏｎと、Ｍｅｄｉａ ｔｉｍｅと、Ｍｅｄｉａ ｒａｔｅとの値の組（以下、この組をエントリという）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
Ｔｒａｃｋ ｄｕｒａｔｉｏｎは、エントリが管理する区間のトラック上での再生時間を表し、Ｍｅｄｉａ ｔｉｍｅは、エントリが管理する区間の先頭に対応するメディアデータ上での位置を表し、Ｍｅｄｉａ ｒａｔｅは、エントリが管理する区間の再生スピードを表す。なお、Ｍｅｄｉａ ｔｉｍｅが−１の場合は、そのエントリのＴｒａｃｋ ｄｕｒａｔｉｏｎ分、そのトラックでのサンプルの再生を停止する。このように再生が停止される区間のことを、ｅｍｐｔｙ ｅｄｉｔと呼ぶ。
次に、実際にサンプルの再生がどのように行われるかについて説明する。サンプルの再生を説明するにあたり、Ｅｄｉｔ ｌｉｓｔ ａｔｏｍの内容は、図１１（ａ）に示すように、ｉ番目のエントリについてＴｒａｃｋ ｄｕｒａｔｉｏｎ（Ｄ（ｉ））と、Ｍｅｄｉａ ｔｉｍｅ（Ｔ（ｉ））と、Ｍｅｄｉａ ｒａｔｅ（Ｒ（ｉ））とが割当られているものとする。また、サンプルの構成は、図１１（ｂ）に示すように、サンプル＃１がＭｅｄｉａ ｔｉｍｅ＝０の位置に存在し、サンプル＃ｍ＋２がＭｅｄｉａ ｔｉｍｅ＝２００００の位置に存在するものとする。このとき、実際のサンプルの再生は、図１１（ｃ）に示す順にて、以下に説明するように行われる。
まず、エントリ＃１は、図１１（ａ）に示すように、Ｔｒａｃｋ ｄｕｒａｔｉｏｎが１３０００、Ｍｅｄｉａ ｔｉｍｅが２００００、Ｍｅｄｉａ ｒａｔｅが１である。したがって、図１１（ｃ）に示すように、トラックの先頭から１３０００の区間は、サンプル中の時刻２００００から３３０００の区間を再生する。
次に、エントリ＃２は、図１１（ａ）に示すように、Ｔｒａｃｋ ｄｕｒａｔｉｏｎが５０００、Ｍｅｄｉａ ｔｉｍｅが−１である。したがって、図１１（ｃ）に示すように、トラック中の時刻１３０００から１８０００の区間、何も再生を行わない。
最後に、エントリ＃３は、図１１（ａ）に示すように、Ｔｒａｃｋ ｄｕｒａｔｉｏｎが１００００、Ｍｅｄｉａ ｔｉｍｅが０、Ｍｅｄｉａ ｒａｔｅが１である。したがって、図１１（ｃ）に示すように、トラック中の時刻１８０００から２８０００の区間において、サンプル中の時刻０から１００００の区間を再生する。
次に、Ｕｓｅｒ ｄａｔａ ａｔｏｍの構成について図１２を参照しつつ説明する。Ｕｓｅｒ ｄａｔａ ａｔｏｍには、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自の拡張付加情報を、任意の個数だけ格納することができる。なお、１個の独自拡張付加情報は１個のエントリで管理され、１個のエントリはＳｉｚｅとＴｙｐｅとＵｓｅｒ ｄａｔａで構成される。
また、Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報を表し、Ｕｓｅｒ ｄａｔａは実際のデータを表す。
図１３にＵｓｅｒ ｄａｔａのｔｙｐｅの例を示す。Ｕｓｅｒ ｄａｔａのｔｙｐｅでマルシーマークから始まるものについては、そのデータがテキスト情報であることを示す。
〔ＡＶストリームの形態について〕
本発明において共通に用いられるＡＶストリームの構成について、図１４および図１５を用いて説明する。
ＡＶストリームは、図１４に示すように、整数個のＣｏｎｔｉｎｕｏｕｓ Ｕｎｉｔ（ＣＵ）で構成されている。ＣＵとは、ディスク上で連続的に記録されるデータの単位である。また、ＣＵの長さは、ＡＶストリームを構成するＣＵをどのようにディスク上に配置しても、シームレス再生やリアルタイムアフレコが保証されるように設定される。
なお、シームレス再生とは、再生中に画像や音声を途切れさせないで再生することをいう。また、リアルタイムアフレコとは、アフレコ対象のビデオをシームレス再生しながらオーディオを記録することをいう。
さらに、ＣＵは、図１４に示すように、整数個のＶｉｄｅｏ Ｕｎｉｔ（ＶＵ）で構成される。ＶＵとは、単独再生可能なデータの単位であり、再生の際のエントリポイントとなり得る。
ＶＵは、図１５に示すように、１秒程度のビデオデータを格納した整数個のＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）と、それらと同じ時間に再生されるメインオーディオデータを格納した整数個のＡＡＵ（Ａｕｄｉｏ Ａｃｃｅｓｓ Ｕｎｉｔ）とから構成される。
なお、ＧＯＰは、ＭＰＥＧ−２ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。また、ＡＡＵはＭＰＥＧ−１ Ｌａｙｅｒ−ＩＩ規格における音声圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数がたとえば４８ｋＨｚの場合、ＡＡＵあたりの再生時間は０．０２４秒となる。
なお、ＶＵ中では、ＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ、ＧＯＰの順に配置する。
また、ＶＵ単位で独立再生を可能とするために、ＶＵ中のビデオデータの先頭にはＳｅｑｕｅｎｃｅ Ｈｅａｄｅｒ（ＳＨ）を置く。ＶＵの再生時間は、ＶＵに含まれるビデオフレーム数にビデオフレーム周期をかけたものと定義する。
〔ＡＶストリームの管理方法について〕
本発明におけるＡＶストリームの管理方法について、図１６を用いて説明する。ＡＶストリーム管理方法は、ＱｕｉｃｋＴｉｍｅファイルフォーマットをベースにするものであり、ビデオデータおよびオーディオデータを、それぞれビデオトラック、オーディオトラックでそれぞれ管理する。
すなわち図１６に示すように、ビデオトラックは、ＧＯＰを１サンプル、ＶＵ中のビデオの塊を１チャンクとして管理する。一方、メインオーディオトラックは、ＡＡＵを１サンプル、ＶＵ中のオーディオの塊を１チャンクとして管理する。
〔ファイルシステムについて〕
本発明の説明において用いるファイルシステムのフォーマットである、ＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａｔ）について、図１７を用いて説明する。
図１７（ａ）に、ファイル４０・４１・４２のディレクトリ構成を示す。また、図１７（ｂ）に、図１７（ａ）に示すディレクトリ／ファイル構成をＵＤＦで記録した例を示す。
図１７（ｂ）において、参照番号４４により示されるＡＶＤＰとは、Ａｎｃｈｏｒ Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｐｏｉｎｔｅｒの略である。ＡＶＤＰ４４は、ＵＤＦの管理情報を探すためのエントリポイントに相当し、通常２５６セクタ目、Ｎセクタ目あるいはＮ−２５６セクタ目に記録する。なお、Ｎは最大論理セクタ番号である。
また、参照番号４３により示されるＶＤＳとは、Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｓｅｑｕｅｎｃｅの略である。ＶＤＳ４３は、ＵＤＦが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは、一般に１枚のディスクに１個存在し、その中にパーティションを一般に１個含む
また、参照番号４５により示されるＦＳＤとは、Ｆｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔｏｒの略である。ＦＳＤ４５は、パーティションに１個存在する。なお、パーティションの中での位置情報は、パーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。また、１個の論理ブロックは１セクタに対応する。
さらに、ＦＳＤ４５は、ルートディレクトリのＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）であるＦＥ４６の位置情報（論理ブロック番号と論理ブロック数で構成され、ｅｘｔｅｎｔと呼ばれる）を含む。
ＦＥとは、ｅｘｔｅｎｔの集合を管理するものである。ｅｘｔｅｎｔを書き換えたり、追加したり、削除することで、ファイルを構成する実データの順番を変えたり、データを挿入したり削除したりすることが可能である。
ＦＥ４６は、ルートディレクトリの直下のファイルやディレクトリの名称等を格納するＦＩＤ（Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒ）の集合を格納する領域４７を管理する。
領域４７中のＦＩＤ５３、ＦＩＤ５４は、それぞれファイル４１、ファイル４２のファイル名やｅｘｔｅｎｔの集合を管理するＦＥ４８、ＦＥ５０の位置情報を含む。
ＦＥ４８は、ファイル４１の実データを構成する領域である領域４９、領域５２をｅｘｔｅｎｔとして管理する。このときファイル４１の実データにアクセスするためには、ＡＶＤＰ４４、ＶＤＳ４３、ＦＳＤ４５、ＦＥ４６、ＦＩＤ５３、ＦＥ４８、領域４９、領域５２の順にリンクを辿っていけばよい。
〔第１の実施形態〕
本発明の第１の実施形態について、図１８ないし図３２を用いて説明する。なお、第１の実施形態を説明するにあたっては、項目（１．管理情報フォーマットについて）・（２．全体の流れについて）・（３．録画処理について）・（４．付加情報変更処理について）・（５．ＡＶ Ｉｎｄｅｘファイル記録処理について）・（６．インデックスファイル画面表示処理について）・（７．変更態様について）を設け、これらの項目を順番に説明する。
（１．管理情報フォーマットについて）
先ず、本発明の第１の実施形態を説明するにあたり、管理情報のフォーマットを説明する。上述のように、ディスク内に含まれるＱｕｉｃｋＴｉｍｅムービーや、静止画データ等のコンテンツと管理情報とを含む各種ファイル（以後、コンテンツファイルと呼ぶ）を管理するため、ＡＶ Ｉｎｄｅｘファイル（インデックス情報）という特別のＱｕｉｃｋＴｉｍｅムービーファイルをディスク内に置く。
図１８に、本実施形態におけるＡＶ Ｉｎｄｅｘファイルの構成を示す。ＡＶ Ｉｎｄｅｘファイルは、通常のＱｕｉｃｋＴｉｍｅムービーファイルと同様、管理情報であるＭｏｖｉｅ ａｔｏｍ６０と、データ自体のＭｏｖｉｅ ｄａｔａ ａｔｏｍ６１とで構成される。また、ＡＶ Ｉｎｄｅｘファイルは、複数のエントリを管理し、ディスク内の各コンテンツファイルは、それぞれ１個のエントリで管理される。
Ｍｏｖｉｅ ａｔｏｍ６０は、各エントリの属性情報を管理するためのＰｒｏｐｅｒｔｙ ｔｒａｃｋ６２、各エントリのタイトル文字列データを管理するためのＴｉｔｌｅ ｔｒａｃｋ６３、各エントリの代表画像データを管理するためのＴｈｕｍｂｎａｉｌ ｔｒａｃｋ６４、および各エントリの代表オーディオデータを管理するためのＩｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ６５の計４種類のトラックで構成される。
各エントリに関する属性情報やタイトル文字列データ、代表画像データ、代表オーディオデータは、それぞれ参照番号６２〜６５にて示されるトラックのサンプルとして管理される。
たとえばコンテンツファイル６６に関する属性情報はＰｒｏｐｅｒｔｙ ｔｒａｃｋ６２上のサンプル６７、タイトル文字列データはＴｉｔｌｅ ｔｒａｃｋ６３上のサンプル６８、代表画像データはＴｈｕｍｂｎａｉｌ ｔｒａｃｋ ６４上のサンプル６９、代表オーディオデータはＩｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ６５上のサンプル７０で管理する。
また、コンテンツファイル７１に関する属性情報はＰｒｏｐｅｒｔｙ ｔｒａｃｋ６２上のサンプル７２、タイトル文字列データはＴｉｔｌｅ ｔｒａｃｋ６３上のサンプル７３、代表画像データはＴｈｕｍｂｎａｉｌ ｔｒａｃｋ６４上のサンプル７４、代表オーディオデータはＩｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ６５上のサンプル７５で管理する。
同様に、コンテンツファイル７６に関する情報は、サンプル７７〜８０で管理し、コンテンツファイル８１に関する情報は、サンプル８２〜８５で管理し、コンテンツファイル８６に関する情報は、サンプル８７〜９０で管理する。
なお、サンプル間の対応付けは、各サンプルの再生開始時間に基づき行う。すなわち、トラック間で同一時刻に位置するサンプルは、同一エントリに対応していると判断する。
Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ６１は、各コンテンツファイルに関する属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータを格納する。
属性情報は、図１９に示すように、ｖｅｒｓｉｏｎと、ｆｌａｇｓと、ｅｎｔｒｙ−ｎｕｍｂｅｒと、ｃｒｅａｔｉｏｎ−ｔｉｍｅと、ｍｏｄｉｆｉｃａｔｉｏｎ−ｔｉｍｅと、ｄｕｒａｔｉｏｎと、ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒとを含んでいる。
ｖｅｒｓｉｏｎは、ファイルフォーマットのバージョンを示す。ｆｌａｇｓは各種フラグをまとめたものである。ｅｎｔｒｙ−ｎｕｍｂｅｒは、属性情報に対応するエントリのＩＤを格納するものである。ｃｒｅａｔｉｏｎ−ｔｉｍｅは、属性情報に対応するエントリが作成された日時を表すものである。ｍｏｄｉｆｉｃａｔｉｏｎ−ｔｉｍｅは、属性情報に対応するエントリが修正された日時を表すものである。ｄｕｒａｔｉｏｎは、属性情報に対応するエントリの再生時間を表すものである。ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒは、管理情報に対応するエントリがファイルに対応していた場合、そのファイルのファイル名を格納するものである。
ｆｌａｇｓは、図２０に示すように、Ｓｔａｔｕｓ ｏｆ Ｅｎｔｒｙと、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎとが存在する。
Ｓｔａｔｕｓ ｏｆ Ｅｎｔｒｙは、対応するエントリが有効（ａｖａｉｌａｂｌｅ）か無効（ｉｎｖａｌｉｄ）かを識別するためのフラグである。Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎは、対応するエントリが拡張付加情報を持っている（Ｔｈｅ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅ ｈａｓ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）か、持っていない（Ｔｈｅ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅ ｈａｓ ｎｏ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）かを識別するためのフラグ（識別情報）である。
Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ６１に格納されるその他のデータについて説明する。代表画像データには１６０×１２０画素に縮小されたＪＰＥＧ圧縮されたデータ、タイトル文字列データにはテキストデータ、代表オーディオデータにはＭＰＥＧ−１ Ａｕｄｉｏ Ｌａｙｅｒ−ＩＩで圧縮されたデータがそれぞれ用いられる。
（２．全体の流れについて）
次に、本実施形態における、ディスク挿入から、ディスクイジェクトあるいは電源ＯＦＦまでの流れを、図２１に示す。
光ディスク６が挿入されたら、前述のシーケンスに沿って、まずファイルシステムの管理情報を読みこむ（ステップ１）。なお、以下の説明では、ステップを単に「Ｓ」と記載する。
次に、ＡＶ Ｉｎｄｅｘファイルを光ディスク６から読み込み、インデックス画面の表示を行う（Ｓ２）。その後、現在がＡＶ Ｉｎｄｅｘファイルをディスクに記録するタイミングかどうかチェックする（Ｓ３）。
なお、記録するタイミングとは、ディスクイジェクト指示や電源ＯＦＦ、あるいはＲＡＭ２に新規の情報を光ディスク６から読み出すために、ＲＡＭ２上のＡＶ Ｉｎｄｅｘファイルに関する情報を光ディスク６に一旦記録するために必要になるタイミングである。
Ｓ３において、現在が記録するタイミングであると判断された場合、Ｓ４においてＡＶ Ｉｎｄｅｘ記録処理を行う。その後、ファイル・ディレクトリ情報記録を行う（Ｓ５）。次に、ＡＶ Ｉｎｄｅｘ記録を行うトリガーとなったのが、電源ＯＦＦあるいはディスクイジェクトがどうかをチェックする（Ｓ６）。
一方、Ｓ３において、現在は記録するタイミングではないと判断された場合、ユーザからの指示が無いかチェックする（Ｓ７）。Ｓ７にてユーザからの指示があると判断された場合、ユーザからの指示に沿って後述する各種処理を実行し（Ｓ８）、各種処理が終了したら、処理結果を反映してインデックス画面表示更新処理を実行する（Ｓ１８）。
次に、Ｓ８における各種処理について図２２を用いて説明する。
まず、ユーザからの指示が録画かどうかをチェックし（Ｓ９）、録画であれば後述する録画処理を行う（Ｓ１０）。指示が録画でなければ、指示がエントリ削除、すなわち既存のコンテンツファイルの削除かどうかをチェックし（Ｓ１１）、エントリ削除ならエントリ削除処理（Ｓ１２）を実行する。
次に、指示が録画でもエントリ削除でもなければ、指示が既存のエントリに関する付加情報の変更かどうかをチェックし（Ｓ１３）、そうであれば後述する付加情報変更処理（Ｓ１４）を実行する。
指示が付加情報変更でなければ、次に、既存のエントリに関する代表画像データ、タイトル文字列データ、代表オーディオデータ、および属性情報のいずれかの変更かどうかをチェックし（Ｓ１５）、そうであれば属性情報等変更処理（Ｓ１６）を実行する。指示されたのが属性情報等変更処理でなければ、その他処理（Ｓ１７）を実行する。
次に、各種処理の内容について詳細を説明する。なお、エントリ削除処理および属性情報等変更処理については本発明の内容に関係ないため説明を省略する。
ここでは、処理を開始する前の初期状態として、光ディスク６に、図２３（ａ）に示すようなディレクトリ構成でファイルが記録され、それぞれが光ディスク６上に図２３（ｂ）に示すように配置されていると仮定する。
すなわち、コンテンツファイルであるＳＨＲＰ０００１．ＭＯＶ、ＳＨＲＰ０００２．ＭＯＶおよびＳＨＲＰ０００３．ＭＯＶは、それぞれ、ＡＶ ｆｉｌｅ９１ａ、ＡＶ ｆｉｌｅ９１ｂ、およびＡＶ ｆｉｌｅ９１ｃの位置に記録される。
またＡＶ ＩｎｄｅｘファイルであるＡＶＩＦ００００．ＭＯＶは、図２３（ｂ）中のＡＶ Ｉｎｄｅｘ ｆｉｌｅ９２の領域に記録され、ＡＶ Ｉｎｄｅｘ ｆｉｌｅ９２の領域の先頭にはＡＶ Ｉｎｄｅｘ ｆｉｌｅのＭｏｖｉｅ ａｔｏｍが領域９３に記録される。
また、ＳＨＲＰ０００１．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データは、それぞれ領域９４ａ、領域９５ａ、領域９６ａに記録され、ＳＨＲＰ０００２．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データは、それぞれ領域９４ｂ、領域９５ｂ、領域９６ｂに記録され、ＳＨＲＰ０００３．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データは、それぞれ領域９４ｃ、領域９５ｃ、領域９６ｃに記録されているとする。
後述するインデックス画面表示処理を行った結果、ＲＡＭ２には、図２４に示すように、ＡＶ Ｉｎｄｅｘファイルに関する情報を管理するためのテーブルが構成される。以下、このテーブルをＡＶ Ｉｎｄｅｘ管理テーブルと呼ぶ。
ＡＶ Ｉｎｄｅｘ管理テーブルの各行は、ディスク挿入時に読み出したＡＶ Ｉｎｄｅｘの状態およびその後の各エントリの更新を管理する。また、ＡＶ Ｉｎｄｅｘ管理テーブルの各行には、拡張付加情報有無を示すフラグ（識別情報）を含む属性に関する情報や、各エントリが管理するコンテンツファイルの名称、ＲＡＭ２の別領域に保持している代表画像データへのポインタ情報を持つ。
なお、代表オーディオデータおよびタイトル文字列データに関しては説明を簡単にするため図示していないが、それぞれ、代表画像データおよび属性情報と同様の扱いを行う。また、各ファイルの名称は実際にはルートディレクトリからのフルパスで管理しているが、ここでは簡単のため、ディレクトリ名は省略している。
（３．録画処理について）
本実施形態における録画時の処理を説明する。ユーザから録画が指示されたら、まずオーディオエンコーダ１７およびビデオエンコーダ１８を起動し、カメラおよびマイク（図示せず）からの入力データを、前述の符号化方式にてエンコードを開始する。
エンコードされたオーディオデータとビデオデータは、マルチプレクサ１３によって、前述のＡＶストリームフォーマットに従って多重化される。その際に、後にＭｏｖｉｅ ａｔｏｍを記録するのに必要となる、ＧＯＰのサイズや再生時間などをＲＡＭ２に蓄積していく。
また、録画時に得られるＧＰＳ位置情報もＲＡＭ２に保持する。また、入力ビデオから先頭画像を代表画像として抜き出し縮小したものを、ＪＰＥＧ符号化でエンコードし、代表画像データを作成し、ＲＡＭ２に保持する。さらに、多重化結果であるＡＶストリームは、記録／アフレコ用バッファ１１およびＥＣＣエンコーダ９を経由して、ピックアップ７によって光ディスク６に記録される。
ユーザから録画停止が指示され、記録／アフレコ用バッファ１１に残ったＡＶストリームを光ディスク６へ記録し終わったら、Ｍｏｖｉｅ ａｔｏｍ中のｕｓｅｒ ｄａｔａ ａｔｏｍにおいてｕｓｅｒ ｄａｔａ ｔｙｐｅを“ｇｂｐｓ”とし、ＲＡＭ２に保存されているＧＰＳ位置情報をｕｓｅｒ ｄａｔａへ格納する。最後にＭｏｖｉｅ ａｔｏｍの記録を行う。
録画が終了した時点で、ＲＡＭ２上のＡＶ Ｉｎｄｅｘ管理テーブルには、図２５に示すように、行番号３で示す行を追加する。以下、その行の内容について説明する。
図２５に示すように、属性情報において、ｅｎｔｒｙ−ｎｕｍｂｅｒは既存の番号と重複しない番号を格納する。また、記録時に拡張付加情報がある場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’とする。
コンテンツファイル名称に関しても、ＡＶ Ｉｎｄｅｘ管理テーブルにおける既存のコンテンツファイル名称の５桁目から８桁目までの数字部分が、ファイルシステム的に重複しないファイル名称を生成して格納する。また、代表画像データに関しては、記録時に生成した前述の代表画像データのＲＡＭ２上でのアドレスを格納する。
（４．付加情報変更処理について）
次に、すでに録画済のコンテンツに対し、付加情報を追記、変更もしくは削除する場合について、図２６を参照しながら説明する。既に録画済のコンテンツに追記する付加情報としては、ユーザが自由に編集可能なコンテンツに関するコメント（ｄｅｓｃｒｉｐｔｉｏｎ）や作者、出演者などの情報がある。
ユーザから付加情報変更が指示されたら、指定されたコンテンツの含まれるコンテンツファイルのｍｏｖｉｅ ａｔｏｍを開き、ｕｓｅｒ ｄａｔａ ａｔｏｍを読み込む。次に、ユーザが指定したタイプ（ｔｙｐｅ）の拡張付加情報エントリが既に存在するか否か、すなわち、付加情報の追記か否かをチェックする（Ｓ１４０１）。
存在しないｔｙｐｅが指定された場合、つまり、追記の場合（Ｓ１４０１でＹＥＳ）、新規にエントリを作成し（Ｓ１４０２）、情報を記録する（Ｓ１４０３）。
次に、ＡＶ Ｉｎｄｅｘファイルのプロパティ情報を見て、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグ（拡張付加情報有無フラグ）をチェックする（Ｓ１４０４）。Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（拡張付加情報が存在する）になっていた場合（Ｓ１４０４でＮＯ）、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’のままにして、変更を行わない。
一方、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘０’（拡張付加情報が存在しない）になっていた場合（Ｓ１４０４でＹＥＳ）、ＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリの付加情報を調べる（Ｓ１４０５）。追記したものと同じ付加情報が存在しない場合、つまり、異なるタイプの付加情報のみが存在する場合（Ｓ１４０５でＹＥＳ）、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’（拡張付加情報が存在する）に書き換える（Ｓ１４０６）。既に追記したものと同じ付加情報が存在する場合（Ｓ１４０５でＮＯ）、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘０’のまま変更を行わない。
Ｓ１４０１において、すでに存在するｔｙｐｅが指定された場合、つまり、追記ではない場合（Ｓ１４０１でＮＯ）、ユーザからの指示が付加情報の変更か否かをチェックする（Ｓ１４０７）。
付加情報を変更する場合（Ｓ１４０７でＹＥＳ）、変更情報をｕｓｅｒ ｄａｔａに上書きして終了する（Ｓ１４０８）。
付加情報を変更しない場合（Ｓ１４０７でＮＯ）、ユーザからの指示が付加情報の削除か否かをチェックする（Ｓ１４０９）。コンテンツファイルからすでに存在する付加情報の削除が指示された場合（Ｓ１４０９でＹＥＳ）、付加情報の削除を行う（Ｓ１４１０）。次に、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’か否かをチェックする（Ｓ１４１１）。
Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’の場合（Ｓ１４１１でＹＥＳ）、コンテンツファイル内に残った他のｔｙｐｅの付加情報が、ＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリ内にも存在するかどうかを調べる（Ｓ１４１２）。他の付加情報が全てＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリに含まれていた場合、すなわち、コンテンツファイル内に、ＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリに含まれる付加情報と異なるタイプの付加情報が存在しない場合（Ｓ１４１２でＮＯ）、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘０’に書き換える（Ｓ１４１３）。一方、他の付加情報が全てＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリに含まれていない場合（Ｓ１４１２でＹＥＳ）、‘１’のまま変更は行わない。
また、付加情報を削除したことによって、コンテンツファイル内にひとつも付加情報が存在しなくなった場合も、フラグを‘０’に書き換える。
さらに、コンテンツファイルに付加情報を追記すると同時に、ＡＶ Ｉｎｄｅｘファイルにも同じ付加情報を追記してもよい。この場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの書き換えは行わない。
（５．ＡＶ Ｉｎｄｅｘファイル記録処理について）
次に、ＡＶ Ｉｎｄｅｘファイル記録処理を図２７を用いて説明する。先ず、図２７に示すように、ＡＶ ＩｎｄｅｘファイルのＳａｍｐｌｅ ｔａｂｌｅの構築をＲＡＭ２上で行う（Ｓ２０）。次に、ＡＶ ＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍを記録し（Ｓ２１）、ＡＶ Ｉｎｄｅｘ管理テーブル中の全エントリの属性情報およびタイトル文字列を記録し（Ｓ２２）、最後に、代表画像データおよび代表オーディオデータを記録する（Ｓ２３）。
（６．インデックスファイル画面表示処理について）
本実施形態におけるインデックスファイル画面表示処理を図２８を用いて説明する。まず、ＡＶ Ｉｎｄｅｘファイルをｏｐｅｎし（Ｓ３０）、Ｍｏｖｉｅ ａｔｏｍを読み込み、上述のＡＶ Ｉｎｄｅｘ管理テーブルをＲＡＭ２上に作成する（Ｓ３１）。ただし、この時点では、代表画像データ等各種データの位置情報のみを取得したのみであり、まだ各種データのＲＡＭ２上への読み込みは行っていない。
次に、各エントリのタイトル文字列データおよび属性情報を読み出し、ＡＶ Ｉｎｄｅｘ管理テーブルに格納する（Ｓ３２）。その後、現在ｏｐｅｎ中のＡＶ Ｉｎｄｅｘファイルに、有効なサムネイルが存在するか否かを判断し（Ｓ３３）、有効なサムネイルがあれば、そのサムネイルを読出し（Ｓ３４）、代表画像データをインデックスファイル画面として表示したり、代表オーディオデータを再生する。
このようにして表示したＡＶ Ｉｎｄｅｘの画面イメージを図２９に示す。図２９に示すように、ユーザがサムネイル選択枠を次から次へと移動させるに従って、画面の下部に、選択されたコンテンツの含まれるコンテンツファイルの属性情報（撮影日時、再生時間等）や、タイトルを表示する。
なお、属性情報の拡張付加情報有無フラグ（Ｅｘｉｓｔｅｎｃｅ Ｓｔａｔｕｓ ｏｆ Ｅｘｔｅｎｄ Ｉｎｆｏｒｍａｔｉｏｎ）が‘１’となっていた場合には、この部分に拡張付加情報が存在することを示すアイコンあるいは拡張付加情報を表示するためのボタンを表示する。
拡張付加情報を表示する際の処理について説明する。インデックス画面表示中にユーザから拡張付加情報表示の指示があったら、ＡＶ Ｉｎｄｅｘのエントリに対応するコンテンツファイルをｏｐｅｎするとともに、Ｍｏｖｉｅａｔｏｍの中のｕｓｅｒ ｄａｔａ ａｔｏｍを読み込み、図３０に示すように、拡張付加情報のタイプと内容とを表示する。なお、再生の指示がなく、「インデックス画面に戻る」ボタンが選択された場合や、「次へ」あるいは「前へ」ボタンが選択されて、別のコンテンツファイルの拡張付加情報表示が指示された場合は、現在拡張付加情報を表示しているコンテンツファイルをｃｌｏｓｅする。
このように、インデックス画面表示中にコンテンツの拡張付加情報に関する情報を表示することで、コンテンツの含まれるコンテンツファイルにアクセスせずともインデックス表示画面で拡張付加情報の有無がわかり、所望の映像を検索する際にさらに使い勝手の良いものとなる。
また、拡張付加情報は、コンテンツファイル内に格納するので、多くの拡張付加情報があった場合でも、インデックス表示の体感レスポンスを落とさずに、より多くの情報をすばやく見ることが可能となる。また、ＧＰＳ位置情報のような拡張付加情報を、コンテンツの含まれるコンテンツファイルに格納することで、管理が容易になる。
（７．変更態様について）
本実施形態では、拡張付加情報の読み出しは、ユーザが拡張付加情報の表示を指示した後に行っているが、本発明はそれに限定されるものではない。
たとえば、インデックス画面表示が完了してから、実際にユーザが指示するまでの空き時間に、拡張付加情報有無のフラグが立っているコンテンツファイルについての拡張付加情報をＲＡＭ２に読み出してもよい。
これにより、インデックス画面の表示に要する時間を増加させることなく、ユーザが指示してから実際に拡張付加情報が表示されるまでのレスポンスを短縮することが可能である。また、拡張付加情報の読み出す順番については、インデックス画面で現在表示されているコンテンツの含まれるコンテンツファイルを優先して読み出すことで、さらに効率的に拡張付加情報の表示が行える。
また、記録媒体としてフラッシュメモリを用いた場合、光ディスクに比べてアクセス時間が短いので、ＡＶ Ｉｎｄｅｘファイルに含まれている基本情報のＲＡＭ２への読み出しと同時に、拡張付加情報有無のフラグが立っているコンテンツファイルについて、拡張付加情報の読み出しを行ってもよい。
この場合、ＲＡＭ２上にすべてのコンテンツの拡張付加情報が保持されているため、たとえばコンテンツをグループ分けして表示することが可能になる。すなわち、本発明によれば、記録媒体の特性に応じて、拡張付加情報を最適に読み出すことができる。
また、本実施形態では、拡張付加情報の有無を示すフラグ（識別情報）をひとつ用意したが、拡張付加情報の種類毎にフラグを用意してもよい。
すなわち、図３１に示すように、機器が対応する拡張付加情報毎にフラグを設け、情報があれば‘１’を、情報がなければ‘０’を設定する。さらに、図３２に示すように、インデックス表示画面において、各拡張付加情報に対応するアイコンを用意し、フラグが‘１’になっている拡張付加情報に対応するアイコンを表示する。
これにより、インデックス表示画面上で選択したコンテンツの含まれるコンテンツファイルがどのような拡張付加情報を持っているかをユーザが一目で確認することができる。さらに、たとえばコメント情報を持つコンテンツだけを抽出し、そのコンテンツの含まれるコンテンツファイルのコメント情報のみを先にＲＡＭ２に読み出すことにより、インデックス表示画面で選択された際にコメントをテロップ表示させることも可能になる。
また、ＡＶ Ｉｎｄｅｘのプロパティ情報に、拡張付加情報を再生可能な機器に関する情報、たとえばメーカーＩＤを追加してもよい。これにより、メーカー独自の情報を拡張付加情報に持つことができ、その独自の拡張付加情報を再生機器のメーカーＩＤがプロパティ情報のメーカーＩＤと一致した場合のみ読み込んでインデックス画面に表示させるなどの読み出しの制御が可能になる。
また、本実施形態では、拡張付加情報はコンテンツファイル内に格納したが、本発明はそれに限定されるものではない。たとえば、コンテンツを格納するコンテンツファイルをＳＨＲＰ０００１．ＭＯＶとしたとき、それに対応する拡張付加情報をＳＨＲＰ０００１．ＭＯＶではなく、ＳＨＲＰ０００１．ＥＸＴに格納してもよい。
この場合、拡張付加情報を含むファイルのファイル名は、コンテンツを格納するコンテンツファイルのファイル名の拡張子を“ＥＸＴ”に変更することで特定可能である。拡張付加情報をコンテンツとは別ファイルに格納することによって、拡張付加情報だけを容易に抜き出すことが可能になる。
なお、本実施形態では、拡張付加情報にＧＰＳ位置情報を用いているが、本発明はそれに限定されるものではなく、たとえば、第２の実施形態で説明する動画サムネイルや温度、湿度、天候、撮影者名、編集者名等様々な情報が対象となることはいうまでもない。
〔第２の実施形態〕
本発明の第２の実施形態について説明する。第１の実施形態との違いは、第２の実施形態においては、ＡＶ Ｉｎｄｅｘの属性情報に、動画サムネイルの有無を示すフラグを設けることにある。なお、動画サムネイルはサイズが大きいためＡＶ Ｉｎｄｅｘファイルには格納されず、コンテンツファイル内に格納される。
したがって、第２の実施形態では、インデックス表示中にフラグが立っているコンテンツの含まれるコンテンツファイルに対してのみ動画サムネイルを読みにいくことで、全体的なインデックス表示の体感レスポンスを落とさずに、次々と静止画サムネイルから動画サムネイルへ切り替えて表示することが可能になる。
なお、第２の実施形態の構成は、第１の実施形態の構成と共通する部分が多いため、第２の実施形態と第１の実施形態との間の相違点に絞って第２の実施形態について説明を行う。
（１．管理情報フォーマットについて）
本実施形態におけるＡＶ Ｉｎｄｅｘファイルの構成は、図３３に示すように、属性情報のフラグに動画サムネイルの有無を示すＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｍｏｖｉｅ ｔｈｕｍｂｎａｉｌフラグが含まれている以外は、第１の実施形態と共通である。なお、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｍｏｖｉｅ ｔｈｕｍｂｎａｉｌフラグが‘０’の場合は、動画サムネイルが存在しないことを示し、‘１’の場合は動画サムネイルが存在することを示す。
（２．全体の流れについて）
本実施形態における全体の流れは、第１の実施形態と同様であるので、説明を省略する。
（３．録画処理について）
本実施形態では、記録／アフレコ用バッファ１１に残ったＡＶストリームを、光ディスク６に記録する際、ＡＶストリームの最初の数秒間をＭｏｔｉｏｎ ＪＰＥＧで圧縮し、動画サムネイルとして、ＡＶストリーム本体とは別にコンテンツファイル内に格納する。動画サムネイルの記録をした場合は、ＡＶ Ｉｎｄｅｘの属性情報の動画サムネイル有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｍｏｖｉｅ ｔｈｕｍｂｎａｉｌ）を‘１’にする。それ以外の処理は、第１の実施形態と共通である。
（４．付加情報変更処理について）
本実施形態における付加情報変更処理は、第１の実施形態と同様であるので、説明を省略する。
（５．ＡＶ Ｉｎｄｅｘ記録処理について）
本実施形態におけるＡＶ Ｉｎｄｅｘ記録処理は、第１の実施形態と同様であるので、説明を省略する。
（６．インデックスファイル画面表示処理について）
本実施形態のインデックスファイル画面表示処理は、動画サムネイルの表示に関する部分以外について第１の実施形態と同様である。したがって、本実施形態において動画サムネイルを表示する際の処理について説明する。
本実施形態では、ＡＶ Ｉｎｄｅｘファイルの代表画像データ等の基本情報に関するインデックス表示が終わったら、属性情報において動画サムネイル有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｍｏｖｉｅ ｔｈｕｍｂｎａｉｌ）が‘１’になっているＡＶ Ｉｎｄｅｘファイルについて、順番に対応するコンテンツファイルをｏｐｅｎする。そして、動画サムネイルデータを読み込み、代表画像データによるサムネイルと置き換え、動画サムネイルをインデックス表示画面上に表示する。
これにより、全体的なインデックス表示の体感レスポンスを落とさずに、次々と効率よく静止画サムネイルから動画サムネイルへ切り替えて表示することが可能になる。
〔第３の実施形態〕
次に、本発明の第３の実施の形態を説明する。本実施形態において、拡張付加情報の有無を示すフラグＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎとは、コンテンツファイル内に拡張付加情報が存在しない状態と、存在する、あるいは存在するかどうかわからない状態とのどちらかの状態を示すものである。存在するという状態を保証する必要がないため、付加情報の記録・編集時にＡＶ Ｉｎｄｅｘとコンテンツファイルの付加情報を常に比較し、拡張付加情報がコンテンツファイルに含まれるかどうかを調べるという処理を行わない機器があってもよい。
なお、第３の実施形態の構成は、第１の実施形態と共通する部分が多いため、相違点に絞って説明を行う。
（１．管理情報フォーマットについて）
本実施形態におけるＡＶ Ｉｎｄｅｘファイルの構成は図３４に示すように、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎの示す意味が第１の実施形態と異なる点を除けば、第１の実施形態と共通である。本実施形態では、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎが‘０’の場合は、対応するコンテンツファイルに拡張付加情報が存在する、もしくは存在するかどうかが分からない状態を示し、‘１’の場合は、対応するコンテンツファイルに拡張付加情報が存在しない状態を示す。
（２．全体の流れについて）
本実施形態における全体の流れは、第１の実施形態と同様であるので、説明を省略する。
（３．録画処理について）
録画が終了した時点で、ＲＡＭ２上のＡＶ Ｉｎｄｅｘ管理テーブルを更新する際に、記録時にコンテンツファイルに対して拡張付加情報がある場合はＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘０’に、拡張付加情報がない場合はＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’として記録する。
上記以外の処理については、第１の実施形態と同様であるので説明を省く。
（４．付加情報変更処理について）
次に、本実施形態における付加情報変更時の処理について説明する。Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの書き換えのところを除けば、付加情報の記録に関して第１の実施の形態と同様である。
Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの書き換えの処理について説明する。図３５は、フラグの書き換えの条件を示している。
まず、既に録画済みのコンテンツの含まれるコンテンツファイルに対し付加情報を追記する場合について説明する。この場合、追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの状態により、処理が異なる。
追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（存在しない）になっていた場合、ＡＶ Ｉｎｄｅｘのコンテンツに対応するエントリに同じ情報が既に含まれているかどうかを調べる。追加したのと同じ情報が含まれていた場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’のままにして、変更を行わない。あるいは、調べる処理を行わずに‘０’（存在するか不明）にしてもよい。
一方、追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが’０’（存在するか不明）になっていた場合、コンテンツファイルに含まれる付加情報の全てがＡＶ Ｉｎｄｅｘのコンテンツに対応するエントリに含まれているかどうかを調べる。付加情報の全てが含まれていた場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’（存在しない）に変更する。あるいは、調べる処理を行わずに、‘０’のままにして、変更を行わなくてもよい。
次に、コンテンツファイルに含まれる付加情報を削除する場合について説明する。この場合、削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの状態により、処理が異なる。
削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（存在しない）になっていた場合、該フラグを‘１’のままにして、変更を行わない。
一方、削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘０’（存在するか不明）になっていた場合、コンテンツファイルに含まれる付加情報がまったく無いか、もしくは全てＡＶ Ｉｎｄｅｘのコンテンツに対応するエントリに含まれているかどうかを調べる。コンテンツファイル内に付加情報がまったく無い、もしくはＡＶ Ｉｎｄｅｘに全て含まれていた場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’（存在しない）に変更する。あるいは、調べる処理を行わずに’０’のまま変更を行わなくてもよい。
次に、ＡＶ Ｉｎｄｅｘに付加情報を追記する場合について説明する。この場合も、追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの状態により、処理が異なる。
追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（存在しない）になっていた場合、‘１’のまま変更を行わない。
一方、追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘０’（存在するか不明）になっていた場合、ＡＶ Ｉｎｄｅｘに追記した内容が既に対応するコンテンツファイルに含まれているか否かを調べる処理を行う。ＡＶ Ｉｎｄｅｘに追記した内容が既に対応するコンテンツファイルに含まれている場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’に変更する。あるいは、調べる処理を行わずに、‘０’のまま変更を行わなくても良い。
さらに、ＡＶ Ｉｎｄｅｘ内に含まれる情報を削除する場合について説明する。この場合も、削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの状態により、処理が異なる。
削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（存在しない）になっていた場合、削除を行う情報が対応するコンテンツファイルに含まれている内容かどうかを調べる処理を行う。対応するコンテンツファイルに存在する場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘０’に変更する。あるいは、調べる処理を行わずに’０’に変更する。
削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘０’（存在するか不明）になっていた場合、対応するコンテンツファイルに含まれる付加情報の全てがＡＶ Ｉｎｄｅｘ内に含まれているかどうかを調べる処理を行う。全て含まれていた場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’（存在しない）に変更する。あるいは、調べる処理を行わずに‘０’のまま変更を行わなくてもよい。
コンテンツファイルとＡＶ Ｉｎｄｅｘとに同時に同じ情報を追記する、あるいは削除する場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの書き換えを行わない。
（５．ＡＶ Ｉｎｄｅｘ記録処理について）
本実施形態におけるＡＶ Ｉｎｄｅｘ記録処理は、第１の実施形態と同様であるので、説明を省略する。
（６．インデックスファイル画面表示処理について）
本実施形態のインデックスファイル画面表示処理は、拡張付加情報有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）の値を見て、インデックス画面に反映させるところ以外は第１の実施形態と同様である。
本実施形態においては、コンテンツファイルに拡張付加情報が存在しない場合が‘１’、存在するかもしれない場合が‘０’であるため、拡張付加情報有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）が‘０’となっているエントリについては、コンテンツファイルを開き、拡張付加情報が存在するか否かを確認する必要がある。
拡張付加情報が存在すると確認されたエントリについては、インデックス画面の下部に拡張付加情報が存在することを示すアイコンあるいは拡張付加情報を表示するためのボタンを表示する。
一方、拡張付加情報が存在しないと確認されたエントリについては、このとき拡張付加情報有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）を‘１’に書き換える。
このように、表示の際にコンテンツファイルを確認して、拡張付加情報が存在しないのに拡張付加情報有無フラグが‘０’となっていたエントリについて‘１’に書き換えていくことで、無駄なアクセスが少なくなっていく。
また、インデックス画面表示の体感レスポンスを落とさないよう、拡張付加情報が存在するか否かを確認する処理は、１画面に表示するすべてのエントリについてサムネイルを表示した後に行っても良い。
また、本実施形態においては、付加情報の追記・編集時の拡張付加情報有無のフラグの書き換えにおいて、現在のフラグの状態に係わらず、ＡＶ Ｉｎｄｅｘとの比較も行わず、常に‘０’を記録するような機器が存在しても良い。
また、本実施形態においても、第１の実施形態で説明したとおり、拡張付加情報の有無を示す識別情報は、拡張付加情報の種別毎に設定してもよい。
また、本実施形態においても、拡張付加情報が再生可能な機器に関する情報を含む構成としても良い。
第１の実施形態に比べて、表示に関する手間が増えてはいるが、拡張付加情報の有無に関する情報がない場合に比べ、フラグが‘１’（存在しない）となっているエントリに関しては拡張付加情報の有無に関して対応するコンテンツファイルを読みに行く必要がないという重要な効果を奏する。
本実施形態のような構成にすることによって、付加情報の記録・編集時にＡＶ Ｉｎｄｅｘとコンテンツファイルの付加情報を比較し、拡張付加情報がコンテンツファイルに含まれるかどうかを調べるという処理を常に行わない機器があってもよく、実装の負担を増やしたくない機器との混在が可能になる。
なお、本発明のデータ記録方法は、ＡＶデータを含む複数のコンテンツのインデックス情報を記録媒体に記録するデータ記録方法であって、上記インデックス情報には、上記各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報を上記インデックス外に記録し、上記属性情報には上記拡張付加情報に関する情報を含む構成であってもよい。
また、上記拡張付加情報に関する情報が、上記拡張付加情報の有無に関する情報を含む構成であってもよい。さらに、上記拡張付加情報が、動画サムネイルデータであることが好ましい。
さらに、上記コンテンツは、上記拡張付加情報を含む構成であってもよい。また、上記拡張付加情報に関する情報が、上記拡張付加情報の種別毎の有無に関する情報を含む構成であってもよい。さらに、上記拡張付加情報に関する情報が、上記拡張付加情報を解釈可能な機器に関する情報を含む構成であってもよい。
また、本発明のデータ再生方法は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報の再生方法であって、上記拡張付加情報に関する情報に基づき各コンテンツの拡張付加情報の読み出しを制御する構成であってもよい。さらに、拡張付加情報の読み出しは、インデックス情報の読み出しの後に行うことが好ましい。
また、本発明のデータ再生方法は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報のデータ再生方法であって、上記拡張付加情報に関する情報を表示する構成であってもよい。
また、本発明のデータ記録装置は、ＡＶデータを含むコンテンツのインデックス情報を記録媒体に記録するデータ記録装置であって、上記インデックス情報に、上記各コンテンツの属性情報を格納する手段と、上記コンテンツに関する拡張付加情報を上記インデックス外に記録する手段と、上記属性情報には上記拡張付加情報に関する情報を格納する手段とを備える構成であってもよい。
また、本発明のデータ再生装置は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報のデータ再生装置であって、上記拡張付加情報に関する情報を基づき各コンテンツの拡張付加情報の読み出しを制御する手段を備える構成であってもよい。
さらに、本発明のデータ再生装置は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報のデータ再生装置であって、上記拡張付加情報に関する情報を表示する手段を備える構成であってもよい。
また、本発明のデータ記録媒体は、ＡＶデータを含む複数のコンテンツのインデックス情報を記録したデータ記録媒体であって、上記インデックス情報には、上記各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報を上記インデックス外に記録され、上記属性情報には上記拡張付加情報に関する情報を含む構成であってもよい。
また、本発明のプログラムは、ＡＶデータを含む複数のコンテンツのインデックス情報を記録媒体に記録するコンピュータプログラムであって、上記インデックス情報には、上記各コンテンツの属性情報を格納するステップと、上記コンテンツに関する拡張付加情報を上記インデックス外に記録するステップと、上記属性情報には上記拡張付加情報に関する情報を格納するステップとを有する構成であってもよい。
また、本発明のプログラムは、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際に、インデックス情報を再生するコンピュータプログラムであって、上記拡張付加情報に関する情報を基づき各コンテンツの拡張付加情報の読み出しを制御するステップを有する構成であってもよい。
また、本発明のプログラムは、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報を再生するコンピュータプログラムであって、上記拡張付加情報に関する情報を表示するステップを有する構成であってもよい。
また、本発明の記録媒体は、ＡＶデータを含む複数のコンテンツのインデックス情報を記録媒体に記録するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、上記インデックス情報には、上記各コンテンツの属性情報を格納するステップと、上記コンテンツに関する拡張付加情報を上記インデックス外に記録するステップと、上記属性情報には上記拡張付加情報に関する情報を格納するステップを有することを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体であってもよい。
また、本発明の記録媒体は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際に、インデックス情報を再生するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、上記拡張付加情報に関する情報を基づき各コンテンツの拡張付加情報の読み出しを制御するステップを有する構成であってもよい。
また、本発明の記録媒体は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報を再生するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、上記拡張付加情報に関する情報を表示するステップを有することを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体であってもよい。
上記構成によれば、拡張付加情報の有無を示すフラグを設けることによって、コンテンツにアクセスせずともインデックス表示画面で拡張付加情報の有無がわかり、所望の映像を検索する際にさらに使い勝手の良いものとなる。また、拡張付加情報はコンテンツファイル内に格納するため、多くの拡張付加情報があった場合でも、インデックス表示の体感レスポンスを落とさずに、より多くの情報をすばやく見ることが可能となる。
また、動画サムネイルの有無を示すフラグを設けることによって、インデックス表示の体感レスポンスを落とさずに、インデックス画面上で動画サムネイルの表示を行うことが可能となる。
尚、発明を実施するための最良の形態の項においてなした具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求の範囲内で、いろいろと変更して実施することができるものである。
【産業上の利用の可能性】
本発明の構成によれば、各コンテンツに直接アクセスしなくても、インデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを識別情報に基づき把握することができる。これにより、本発明を、各コンテンツにおける拡張付加情報の有無をより簡易に確認することができるデータ記録方法、データ再生方法、データ記録装置、データ再生装置、データ記録媒体、プログラム、およびそのプログラムを格納した記録媒体に好適に用いることができる。
【図１】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【技術分野】
本発明は、ハードディスク、光ディスク、半導体メモリ等のランダムアクセス可能な記録媒体に対して、映像データ、音声データ等を記録するデータ記録方法、データ記録装置、データ記録媒体、データ再生方法、データ再生装置、プログラム、およびそのプログラムを格納した記録媒体に関するものである。
【背景技術】
近年、光ディスク等のメディアに記録されたコンテンツのディジタル記録再生装置（以下、ビデオディスクレコーダと呼ぶ）が普及しつつある。そして、メディアへのコンテンツの記録フォーマットとして、ＰＣで広く使われているフォーマット、たとえばＱｕｉｃｋＴｉｍｅファイルフォーマットやＡＶＩ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｉｎｔｅｒｌｅａｖｅ）ファイルフォーマットを用いることが広く行われる。これにより、映像データとＰＣ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ）との親和性が高められている。
このようなＰＣ用ファイルフォーマットを用いた場合における光ディスク内でのコンテンツの管理方法について、日本国公開特許公報「特開２００１−８４７０５公報（公開日２００１年３月３０日）」に開示された技術がある。以下、図３６を用いて、その概要を説明する。
ディスク３０５に記録されたコンテンツファイル３０１・３０２・３０３は、録画した各シーンあるいはコンテンツに対応するファイルであり、それぞれ１個のＱｕｉｃｋＴｉｍｅファイル（以下、ＱｕｉｃｋＴｉｍｅムービーファイルと呼ぶ）である。
また、インデックスファイル３００は、ディスク３０５内のデータの目次的な情報を格納するファイルであり、各ＱｕｉｃｋＴｉｍｅムービーファイル毎にエントリを有している。なお、各エントリには、対応するシーンの代表画面の縮小画像データ３１１・３１２・３１３と、対応するシーンが含まれるファイルのファイル名とが格納されている。
そして、ユーザにインデックス画面を提示する際、ビデオディスクレコーダは、各エントリの縮小画像データ３１１〜３１３をデコードした縮小画像３２１〜３２３を、コンテンツ選択画面３０７に表示する。ユーザは、コンテンツ選択画面３０７に表示されている複数の縮小画像３２１〜３２３の中から、再生や編集をしたいファイルを選択する。
たとえば、ユーザが縮小画像３２３を選択し、再生を指示した場合、ビデオディスクレコーダは、縮小画像３２３に対応するコンテンツの含まれるファイルのファイル名であるファイル３０３を取得し、ファイル３０３の再生を開始する。
さらに、インデックスファイル３００には、ディスク３０５中のすべてのコンテンツに関して、コンテンツを格納したファイルへのポインタと、縮小画像データとが含まれている。したがって、ビデオディスクレコーダは、インデックスファイル３００をディスク３０５から読み出すだけで、コンテンツ選択画面３０７の表示が可能である。その結果、上記公報の技術は、インデックス画面表示に要する時間が少なくて済むという利点がある。
ところで、コンテンツ選択画面３０７は頻繁に表示するものであるので、コンテンツ選択画面３０７の表示時間を削減すれば、ユーザが体感するビデオディスクレコーダの反応速度（以下、体感レスポンスという）は大きく向上する。
そこで、従来のビデオディスクレコーダにおいては、ディスク挿入時における体感レスポンスを向上させるため、各コンテンツに対応する縮小画像や撮影時刻などのコンテンツの内容を表す付加情報をインデックスファイルに格納し、該インデックスファイルに基づき縮小画像や基本的な情報のみがコンテンツ選択画面３０７に一覧表示されていた。
ところが、従来技術におけるコンテンツ選択画面３０７のような縮小画像の一覧表示だけからは、コンテンツファイル内に、インデックスファイルに格納されている情報以外の付加情報（以下、拡張付加情報という）が含まれているかどうかを判断することができない。すなわち、実際にコンテンツにアクセスしてみなければ、拡張付加情報の有無すら確認することができないという問題がある。
本発明は、上記従来の問題点に鑑みなされたものであって、その目的は、各コンテンツにおける拡張付加情報の有無を、より簡易に確認することができるデータ記録方法、データ再生方法、データ記録装置、データ再生装置、データ記録媒体、プログラム、およびそのプログラムを格納した記録媒体を提供することにある。
【発明の開示】
本発明のデータ記録方法は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を、記録媒体に記録するデータ記録方法において、上記インデックス情報が、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含む。
また、本発明のデータ記録装置は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を、記録媒体に記録するデータ記録装置において、上記インデックス情報が、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含む。
上記構成によれば、インデックス情報は、拡張付加情報がコンテンツに付加されているか否かに関する識別情報を含んでいる。したがって、各コンテンツに直接アクセスしなくても、インデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを識別情報に基づき把握することができる。なお、拡張付加情報とは、ＡＶデータが記録された場所のＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）情報や温度、ＡＶデータについてユーザにより追加されたコメントや、ＡＶデータの作者、出演者等の、ＡＶデータについてより具体的な内容を表す情報である。
ここで、本発明において、インデックス情報にアクセスして各コンテンツに対する拡張付加情報の有無を判断する処理に要する時間は、従来技術において、各コンテンツのＡＶデータもしくはＡＶデータと管理情報をそれぞれ開いた後に、該コンテンツに拡張付加情報が付加されているか否かを判断する処理に要していた時間よりも短い。
それゆえ、各コンテンツにおける拡張付加情報の有無を、より簡易に確認することができる。
また、本発明のデータ記録方法は、上記構成において、上記拡張付加情報が、動画サムネイルデータであってもよい。
上記構成によれば、インデックス画面を静止画サムネイルにより表示するので、ビデオディスクレコーダの体感レスポンスは低下しない。また、識別情報に基づいて拡張付加情報が存在すると把握されたコンテンツのみについて拡張付加情報としての動画サムネイルデータを読み出し、インデックス画面を静止画サムネイルから動画サムネイルに切り替えることができる。また、動画サムネイルによれば、静止画サムネイルよりも具体的にコンテンツの内容を確認することができる。
それゆえ、ビデオディスクレコーダの体感レスポンスを低下させることなく、複数のコンテンツの内容をより詳細にユーザに提示することができる。
また、本発明のデータ記録方法は、上記構成において、上記各コンテンツの所定領域に、上記拡張付加情報を含んでいてもよい。
上記構成によれば、多くの拡張付加情報がコンテンツに付加されている場合でも、各コンテンツにおける所定領域（Ｕｓｅｒ ｄａｔａ ａｔｏｍ）を参照することにより、拡張付加情報の内容を把握することができる。つまり、拡張付加情報の内容を把握するために、拡張付加情報がどの場所に格納されているかということを探索するための時間を省略することができる。
したがって、インデックス表示の体感レスポンスを落とさずに、より多くの拡張付加情報をすばやく参照することができる。
また、本発明のデータ記録方法は、上記構成において、上記拡張付加情報を、上記各コンテンツを記録する記録媒体の領域と別の領域に記録してもよい。
上記構成によれば、拡張付加情報を、記録媒体においてコンテンツが記録されている領域とは別の領域から読み出すことができる。したがって、拡張付加情報のみを容易に読み出すことができる。
また、本発明のデータ記録方法は、上記構成において、上記識別情報を、上記拡張付加情報の種別毎に設定してもよい。
上記構成によれば、拡張付加情報の種別毎に、各コンテンツにおける拡張付加情報の有無を把握することができる。したがって、より詳細に拡張付加情報の有無を確認することができる。
また、本発明のデータ記録方法は、上記構成において、上記識別情報が、上記拡張付加情報を再生可能な機器に関する情報を含んでいてもよい。
上記構成によれば、識別情報に基づき、拡張付加情報を再生可能な機器を把握することができる。したがって、現在コンテンツを再生している機器が、拡張付加情報を再生可能な機器であるか否かを判断することができる。
それゆえ、たとえば現在コンテンツを再生している機器が、拡張付加情報を再生できる機器である場合にのみ、インデックス画面に拡張付加情報の有無を表示するというように、より効率的に拡張付加情報の有無の確認を行うことができる。
また、本発明のデータ記録方法は、上記の構成に加えて、上記識別情報は、拡張付加情報が付加されていない状態と、拡張付加情報が付加されている、あるいは付加されているかどうか不明である状態とのどちらかを示す情報を含んでいてもよい。
上記構成によれば、識別情報に基づき、拡張付加情報を得るためにコンテンツにアクセスする必要があるかないかを即座に把握するこができる。また、存在するという状態を保証する必要がないため、付加情報の記録・編集時にＡＶ Ｉｎｄｅｘとコンテンツファイルの付加情報を比較し、拡張付加情報がコンテンツファイルに含まれるかどうかを調べるという処理を常に行わなくてもよい。
また、本発明のデータ再生方法は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生方法において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、上記識別情報に基づき、上記拡張付加情報の読み出しを制御する。
また、本発明のデータ再生装置は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生装置において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、上記識別情報に基づき、上記拡張付加情報の読み出しを制御する制御手段を備えている。
上記構成によれば、インデックス情報は、拡張付加情報がコンテンツに付加されているか否かに関する識別情報を含んでいる。したがって、各コンテンツのＡＶデータに直接アクセスしなくても、インデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを、識別情報に基づき把握することができる。
それゆえ、識別情報に基づきより簡易に拡張付加情報の有無を把握し、より迅速に拡張付加情報の読み出しを行うことが可能となる。
また、本発明のデータ再生方法は、上記構成において、上記インデックス情報を読み出した後で、ユーザによる上記拡張付加情報の表示の指示前に、該拡張付加情報を読み出してもよい。
すなわち、多くのユーザは、インデックス画面により複数のコンテンツの内容を確認した後に、各コンテンツに拡張付加情報が付加されているか否かを判断する傾向がある。
上記構成によれば、インデックス情報を読み出した後で、ユーザによる上記拡張付加情報の表示の指示前に、各コンテンツの識別情報に基づき拡張付加情報を予め読み出す。したがって、インデックス画面の表示後に、ユーザの指示により拡張付加情報の表示があった場合に、すばやく拡張付加情報を表示させることができる。
また、本発明のデータ再生方法は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生方法において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、上記識別情報を表示する。
また、本発明のデータ再生装置は、上記の目的を達成するために、ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生装置において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、上記識別情報を表示する表示手段を備えている。
上記構成によれば、インデックス情報は、拡張付加情報がコンテンツに付加されているか否かに関する識別情報を含んでいる。したがって、各コンテンツに直接アクセスしなくても、インデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを、識別情報に基づき把握することができる。
それゆえ、表示された識別情報により、コンテンツに拡張付加情報が付加されているか否かをより簡易にユーザに視認させることができる。
また、本発明のデータ記録媒体は、ＡＶデータを含む複数のコンテンツのインデックス情報が記録されたデータ記録媒体において、上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含む。
上記構成によれば、データ記録媒体に記録されたインデックス情報は、拡張付加情報がコンテンツに付加されているか否かに関する識別情報を含んでいる。したがって、各コンテンツに直接アクセスしなくても、本発明によるデータ記録媒体のインデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを識別情報に基づき把握することができる。
それゆえ、各コンテンツにおける拡張付加情報の有無を、より簡易に確認することができる。
また、本発明のプログラムは、上記記載のデータ記録方法またはデータ再生方法をコンピュータに実行させるプログラムである。さらに、本発明のコンピュータ読み取り可能な記録媒体は、上記プログラムを格納している。
本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。
【図面の簡単な説明】
図１は、本発明の実施形態に係るビデオディスクレコーダの概略構成図である。
図２（ａ）は、管理情報とメディアデータとが同じファイルに存在する場合における、ＱｕｉｃｋＴｉｍｅファイルフォーマットの管理情報とＡＶストリームとの関係を示す図である。
図２（ｂ）は、管理情報とメディアデータとが別々のファイルに存在する場合における、ＱｕｉｃｋＴｉｍｅファイルフォーマットの管理情報とＡＶストリームとの関係を示す図である。
図２（ｃ）は、複数のＡＶストリームファイルに対する外部参照する場合における、ＱｕｉｃｋＴｉｍｅファイルフォーマットの管理情報とＡＶストリームとの関係を示す図である。
図３は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ ａｔｏｍの概要を示す図である。
図４は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ａｔｏｍの概要を示す図である。
図５は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を示す図である。
図６は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ ａｔｏｍの構成を示す図である。
図７は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍの構成を示す図である。
図８は、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍによるデータ管理の例を示す図である。
図９は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構成を示す図である。
図１０は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＥｄｉｔ ａｔｏｍの構成を示す図である。
図１１（ａ）は、Ｅｄｉｔ ａｔｏｍによる再生範囲指定の例を示す図である。
図１１（ｂ）は、サンプルの構成の例を示す図である。
図１１（ｃ）は、実際のサンプルの再生順の例を示す図である。
図１２は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＵｓｅｒ ｄａｔａ ａｔｏｍの構成を示す図である。
図１３は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＵｓｅｒ ｄａｔａのｔｙｐｅの種類を示す図である。
図１４は、本発明の各実施形態におけるＡＶストリームの構成を示す図である。
図１５は、本発明の各実施形態におけるＶＵの構成を示す図である。
図１６は、本発明の各実施形態におけるＱｕｉｃｋＴｉｍｅによるＡＶストリーム管理形態を示す図である。
図１７（ａ）は、ファイルのディレクトリ構成を示す図である。
図１７（ｂ）は、図１７（ａ）に示すディレクトリ／ファイル構成をＵＣＦで記録した例を示す図である。
図１８は、本発明の第１の実施形態における、ＡＶ Ｉｎｄｅｘファイルの構成を示す図である。
図１９は、本発明の第１の実施形態における属性情報の構成を示す図である。
図２０は、本発明の第１の実施形態におけるｆｌａｇｓの構成を示す図である。
図２１は、本発明の第１の実施形態における全体の処理の流れを示すフローチャートである。
図２２は、本発明の第１の実施形態におけるユーザ指示による各種処理の流れを示すフローチャートである。
図２３（ａ）は、光ディスクに記録されたファイルのディレクトリ構成を示す図である。
図２３（ｂ）は、記録媒体上の記録状態の例を示す図である。
図２４は、本発明の第１の実施形態における、ディスク挿入直後のＡＶ Ｉｎｄｅｘ管理テーブルの例を示す図である。
図２５は、本発明の第１の実施形態における、録画直後のＡＶ Ｉｎｄｅｘ管理テーブルの例を示す図である。
図２６は、本発明の第１の実施形態における、付加情報変更処理を示すフローチャートである。
図２７は、本発明の第１の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新処理を示すフローチャートである。
図２８は、本発明の第１の実施形態におけるＡＶ Ｉｎｄｅｘファイル読み出し処理を示すフローチャートである。
図２９は、本発明の第１の実施形態におけるインデックス表示画面の例を示す図である。
図３０は、本発明の第１の実施形態における拡張付加情報表示画面の例を示す図ある。
図３１は、本発明の第１の実施形態におけるフラグの第２の構成を示す図である。
図３２は、本発明の第１の実施形態における第２のインデックス表示画面の例を示す図である。
図３３は、本発明の第２の実施形態におけるフラグの構成を示す図である。
図３４は、本発明の第３の実施形態におけるフラグの構成を示す図である。
図３５は、本発明の第３の実施形態における、拡張付加情報有無のフラグ変更条件を示す図である。
図３６は、従来技術におけるインデックスファイルを示す図である。
【発明を実施するための最良の形態】
以下、実施例および比較例により、本発明をさらに詳細に説明するが、本発明はこれらにより何ら限定されるものではない。
以下、本発明の実施の一形態について、図面を参照しながら説明すれば以下の通りである。なお、以下の説明では、本発明の複数の実施形態において共通に用いるビデオディスクレコーダの構成を説明した後、各実施形態に固有の特徴点を説明する。
〔ビデオディスクレコーダの構成について〕
ビデオディスクレコーダは、図１に示すように、制御手段としてのホストＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）１と、ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）２と、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）３と、ユーザインタフェース４と、システムクロック５と、光ディスク６と、ピックアップ７と、ＥＣＣ（Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｎｇ Ｃｏｄｉｎｇ）デコーダ８と、ＥＣＣエンコーダ９と、再生用バッファ１０と、記録／アフレコ用バッファ１１と、デマルチプレクサ１２と、マルチプレクサ１３と、多重化用バッファ１４と、オーディオデコーダ１５と、ビデオデコーダ１６と、オーディオエンコーダ１７と、ビデオエンコーダ１８とを備えている。さらに、ビデオディスクレコーダは、図示しないカメラ、マイク、スピーカ、あるいはディスプレイ（表示手段）等を備えている。
ホストＣＰＵ１は、バス１９を通じて、ピックアップ７と、デマルチプレクサ１２と、マルチプレクサ１３と、オーディオデコーダ１５と、ビデオデコーダ１６と、オーディオエンコーダ１７と、ビデオエンコーダ１８との制御を行う。
また、ホストＣＰＵ１は、再生中のデータに関する管理情報に基づき、オーディオデコーダ１５とビデオデコーダ１６とからのデータ送信要求に従い、再生用バッファ１０内のデータを、データ種別に対応するデコーダに振り分けるよう、デマルチプレクサ１２に指示を与える。
上記構成により、ビデオディスクレコーダは、光ディスク６の再生時において、光ディスク６からピックアップ７を通じて光ディスク６に格納されたデータを読み出すとともに、読み出したデータをＥＣＣデコーダ８により誤り訂正した後、再生用バッファ１０に一旦蓄える。
一方、ビデオディスクレコーダは、光ディスク６の記録時において、オーディオエンコーダ１７とビデオエンコーダ１８とを用いて、光ディスク６に記録すべきデータを圧縮符号化するとともに、圧縮符号化されたデータを多重化用バッファ１４に一旦送信する。その後、ビデオディスクレコーダは、多重化用バッファ１４に送信されたデータをマルチプレクサ１３を用いてＡＶ多重化した後、記録／アフレコ用バッファ１１に送信する。そして、ビデオディスクレコーダは、記録／アフレコ用バッファ１１内のデータを、ＥＣＣエンコーダ９を用いて誤り訂正符号を付加した後、ピックアップ７を通じて光ディスク６に記録する。
なお、オーディオデータの符号化方式としてＭＰＥＧ−１ Ｌａｙｅｒ−ＩＩを、ビデオデータの符号化方式としてＭＰＥＧ−２をそれぞれ用いた。また、これらの符号化方式では、２０４８ｂｙｔｅを１セクタとするとともに、誤り訂正のためのＥＣＣブロックを１６セクタで構成する。
〔ファイルフォーマットについて〕
本発明でＡＶストリーム管理のためのフォーマットとして用いる、ＱｕｉｃｋＴｉｍｅファイルフォーマットについて説明する。なお、ＱｕｉｃｋＴｉｍｅファイルフォーマットとは、Ａｐｐｌｅ社が開発したマルチメディアデータ管理用フォーマットのことであり、ＰＣの世界で広く用いられている。
ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータとも呼ぶ）と、管理情報とで構成される。メディアデータと、管理情報とを組み合わせたものを、ＱｕｉｃｋＴｉｍｅムービーと呼ぶ。また、ＱｕｉｃｋＴｉｍｅムービーは、単にムービーと呼ぶ場合もある。なお、メディアデータと、管理情報とは、同じファイル中に存在しても、別々のファイルに存在してもよい。
メディアデータと、管理情報とが同じファイル中に存在する場合、ＱｕｉｃｋＴｉｍｅムービーは、図２（ａ）に示すような構成をとる。すなわち、ＱｕｉｃｋＴｉｍｅムービーにおける各種情報は、ファイル２１内のａｔｏｍという共通の構造に格納される。たとえば、ＱｕｉｃｋＴｉｍｅムービーにおける管理情報は、Ｍｏｖｉｅ ａｔｏｍという構造に格納され、一方、メディアデータはＭｏｖｉｅ ｄａｔａ ａｔｏｍという構造に格納される。なお、図２（ａ）において「ＡＨ」と記載されているのは、Ａｔｏｍ Ｈｅａｄｅｒの略である。
また、Ｍｏｖｉｅ ａｔｏｍ中の管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。
一方、管理情報とメディアデータを別々のファイルに格納した場合、ＱｕｉｃｋＴｉｍｅムービーは、図２（ｂ）に示すような構成をとる。すなわち、管理情報はファイル２２におけるＭｏｖｉｅ ａｔｏｍという構造に格納されるが、メディアデータはａｔｏｍには格納される必要はない。つまり、メディアデータは、ファイル２２とは別のファイル２３にＡＶストリームとして格納される。
このように、管理情報とメディアデータとが別々のファイルに格納されているとき、Ｍｏｖｉｅ ａｔｏｍは、メディアデータを格納したファイルを「外部参照」しているという。
外部参照は、図２（ｃ）に示すように、複数のＡＶストリームファイル２５・２６に対して行うことが可能である。これにより、ＡＶストリーム自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」あるいは「非破壊編集」が可能となる。
次に、図３ないし図１３を用いて、ＱｕｉｃｋＴｉｍｅムービーにおける管理情報のフォーマットについて説明する。
先ず、共通の情報格納フォーマットであるａｔｏｍについて説明する。
ａｔｏｍの先頭には、そのａｔｏｍのサイズを表すＡｔｏｍ ｓｉｚｅと、そのａｔｏｍの種別情報を表すＴｙｐｅとが必ず存在する。Ｔｙｐｅは４文字で区別され、たとえばＭｏｖｉｅ ａｔｏｍでは‘ｍｏｏｖ’、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍでは‘ｍｄａｔ’となっている。このように、ａｔｏｍの先頭にあるＡｔｏｍ ｓｉｚｅとＴｙｐｅとを、ａｔｏｍ ｈｅａｄｅｒと呼ぶ。
また、ａｔｏｍは、別のａｔｏｍを含むことができる。すなわち、ａｔｏｍ間には階層構造がある。
ａｔｏｍの一例としてのＭｏｖｉｅ ａｔｏｍの構成を図３に示す。Ｍｏｖｉｅ ａｔｏｍは、図３に示すように、Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍと、Ｔｒａｃｋ ａｔｏｍと、Ｕｓｅｒ ｄａｔａ ａｔｏｍとが含まれている。
Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍは、Ｍｏｖｉｅ ａｔｏｍが管理するムービーの全体的な属性を管理するａｔｏｍである。Ｔｒａｃｋ ａｔｏｍは、ムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納するａｔｏｍである。Ｕｓｅｒ ｄａｔａ ａｔｏｍは、メーカが独自に定義可能なａｔｏｍである。
Ｔｒａｃｋ ａｔｏｍの構成を図４に示す。Ｔｒａｃｋ ａｔｏｍは、図４に示すように、Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍと、Ｅｄｉｔ ａｔｏｍと、Ｔｒａｃｋ ｒｅｆｅｒｅｎｃｅ ａｔｏｍと、Ｍｅｄｉａ ａｔｏｍとを含んでいる。
Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、トラックの全体的な属性を管理するａｔｏｍである。Ｅｄｉｔ ａｔｏｍは、メディアデータの各区間について、ムービーにおいて再生すべきタイミングを管理するａｔｏｍである。Ｔｒａｃｋ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、他のトラックとの関係を管理するａｔｏｍである。Ｍｅｄｉａ ａｔｏｍは、ビデオやオーディオといった、メディアに関するデータ（メディアデータ）を管理する。
Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を図５に示す。なお、Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成については、主要なものについてのみ説明する。Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、図５に示すように、Ｆｌａｇｓと、Ｌａｙｅｒとを含んでいる。
Ｆｌａｇｓは、トラックの属性を示すフラグの集合である。フラグの代表的なものとしては、Ｔｒａｃｋ ｅｎａｂｌｅｄフラグを挙げることができる。Ｔｒａｃｋ ｅｎａｂｌｅｄフラグが１であれば、そのトラックは再生され、Ｔｒａｃｋ ｅｎａｂｌｅｄフラグが０であれば、そのトラックは再生されない。
Ｌａｙｅｒは、トラックの空間的な優先度を表すものである。たとえば画像を表示するトラックが複数ある場合においては、Ｌａｙｅｒの値が小さいトラックほど、対応する画像が前面に表示される。
Ｍｅｄｉａ ａｔｏｍの構成を図６に示す。Ｍｅｄｉａ ａｔｏｍは、図６に示すように、Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍと、Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍと、Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍとを含んでいる。
Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍの管理するメディアデータに関する全体的な属性等を管理するものである。Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、メディアデータをどのデコーダでデコードするかを示す情報を格納するものである。Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、ビデオやオーディオ等のメディアに固有の属性情報を管理するものである。
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍの構成を図７に示す。Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、図７に示すように、Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ｈｅａｄｅｒ ａｔｏｍと、Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍと、Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍと、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍとを含んでいる。
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ｈｅａｄｅｒ ａｔｏｍは、ビデオやオーディオ等のメディアについて固有の属性情報を管理するものである。Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍについての説明で記載した通り、メディアデータをどのデコーダでデコードするかを示す情報を格納するものである。Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、そのＱｕｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名前を管理するａｔｏｍである、Ｄａｔａ ｒｅｆｅｒｅｎｃｅ ａｔｏｍを含むものである。Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、データのサイズや、再生時間等を管理するものである。
ところで、ＱｕｉｃｋＴｉｍｅフォーマットでは、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンク（ｃｈｕｎｋ）と呼ぶ。チャンクには、再生時間順に１から番号が付与されており、この番号により、個々のｃｈｕｎｋのファイル先頭からのアドレスを把握することができる。
また、ＱｕｉｃｋＴｉｍｅフォーマットでは、データの最小単位（たとえばビデオフレーム）をサンプル（Ｓａｍｐｌｅ）と呼ぶ。さらに、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のトラックのサンプルに、再生時間順に１から番号（サンプル番号）を付与することにより、サンプル数を管理している。
さらに、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のサンプルの再生時間長とデータサイズ（ｓａｍｐｌｅ ｓｉｚｅ）とを管理している。
つまり、図８に示すように、ファイル３１に含まれるｃｈｕｎｋには、再生時間順に１から番号が付けられている。さらに、たとえばｍ番のｃｈｕｎｋには、サンプル番号がｊからｉまでの複数のＳａｍｐｌｅが含まれている。
このように、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のチャンクのファイル先頭からのアドレスと、個々のチャンクが含むサンプル数とを管理している。これらの情報に基づき、ＱｕｉｃｋＴｉｍｅフォーマットでは、任意の時間に対応するサンプルの位置を求めることが可能となっている。
次に、Ｓａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍの構成について説明する。Ｓａｍｐｌｅ Ｔａｂｌｅ ａｔｏｍは、図９に示すように、Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍと、Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ ａｔｏｍと、Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍと、Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ ａｔｏｍと、Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍと、Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍとを含んでいる。
Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍは、個々のチャンクのデータフォーマット（Ｄａｔａ ｆｏｒｍａｔ）やサンプルが格納されているファイルのチャンクのＩｎｄｅｘ等を管理するものである。Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルの再生時間を管理する。
Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルのうち、デコード開始可能なサンプルを管理するものである。Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ ａｔｏｍは、個々のチャンクに含まれるサンプル数を管理するものである。Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍは、個々のサンプルのサイズを管理するものである。Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍは、個々のチャンクのファイル先頭からのアドレスを管理するものである。
Ｅｄｉｔ ａｔｏｍは、図１０に示すように、１個のＥｄｉｔ ｌｉｓｔ ａｔｏｍを含むものである。Ｅｄｉｔ ｌｉｓｔ ａｔｏｍは、Ｎｕｍｂｅｒ ｏｆ ｅｎｔｒｉｅｓで指定される個数分の、Ｔｒａｃｋ ｄｕｒａｔｉｏｎと、Ｍｅｄｉａ ｔｉｍｅと、Ｍｅｄｉａ ｒａｔｅとの値の組（以下、この組をエントリという）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
Ｔｒａｃｋ ｄｕｒａｔｉｏｎは、エントリが管理する区間のトラック上での再生時間を表し、Ｍｅｄｉａ ｔｉｍｅは、エントリが管理する区間の先頭に対応するメディアデータ上での位置を表し、Ｍｅｄｉａ ｒａｔｅは、エントリが管理する区間の再生スピードを表す。なお、Ｍｅｄｉａ ｔｉｍｅが−１の場合は、そのエントリのＴｒａｃｋ ｄｕｒａｔｉｏｎ分、そのトラックでのサンプルの再生を停止する。このように再生が停止される区間のことを、ｅｍｐｔｙ ｅｄｉｔと呼ぶ。
次に、実際にサンプルの再生がどのように行われるかについて説明する。サンプルの再生を説明するにあたり、Ｅｄｉｔ ｌｉｓｔ ａｔｏｍの内容は、図１１（ａ）に示すように、ｉ番目のエントリについてＴｒａｃｋ ｄｕｒａｔｉｏｎ（Ｄ（ｉ））と、Ｍｅｄｉａ ｔｉｍｅ（Ｔ（ｉ））と、Ｍｅｄｉａ ｒａｔｅ（Ｒ（ｉ））とが割当られているものとする。また、サンプルの構成は、図１１（ｂ）に示すように、サンプル＃１がＭｅｄｉａ ｔｉｍｅ＝０の位置に存在し、サンプル＃ｍ＋２がＭｅｄｉａ ｔｉｍｅ＝２００００の位置に存在するものとする。このとき、実際のサンプルの再生は、図１１（ｃ）に示す順にて、以下に説明するように行われる。
まず、エントリ＃１は、図１１（ａ）に示すように、Ｔｒａｃｋ ｄｕｒａｔｉｏｎが１３０００、Ｍｅｄｉａ ｔｉｍｅが２００００、Ｍｅｄｉａ ｒａｔｅが１である。したがって、図１１（ｃ）に示すように、トラックの先頭から１３０００の区間は、サンプル中の時刻２００００から３３０００の区間を再生する。
次に、エントリ＃２は、図１１（ａ）に示すように、Ｔｒａｃｋ ｄｕｒａｔｉｏｎが５０００、Ｍｅｄｉａ ｔｉｍｅが−１である。したがって、図１１（ｃ）に示すように、トラック中の時刻１３０００から１８０００の区間、何も再生を行わない。
最後に、エントリ＃３は、図１１（ａ）に示すように、Ｔｒａｃｋ ｄｕｒａｔｉｏｎが１００００、Ｍｅｄｉａ ｔｉｍｅが０、Ｍｅｄｉａ ｒａｔｅが１である。したがって、図１１（ｃ）に示すように、トラック中の時刻１８０００から２８０００の区間において、サンプル中の時刻０から１００００の区間を再生する。
次に、Ｕｓｅｒ ｄａｔａ ａｔｏｍの構成について図１２を参照しつつ説明する。Ｕｓｅｒ ｄａｔａ ａｔｏｍには、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自の拡張付加情報を、任意の個数だけ格納することができる。なお、１個の独自拡張付加情報は１個のエントリで管理され、１個のエントリはＳｉｚｅとＴｙｐｅとＵｓｅｒ ｄａｔａで構成される。
また、Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報を表し、Ｕｓｅｒ ｄａｔａは実際のデータを表す。
図１３にＵｓｅｒ ｄａｔａのｔｙｐｅの例を示す。Ｕｓｅｒ ｄａｔａのｔｙｐｅでマルシーマークから始まるものについては、そのデータがテキスト情報であることを示す。
〔ＡＶストリームの形態について〕
本発明において共通に用いられるＡＶストリームの構成について、図１４および図１５を用いて説明する。
ＡＶストリームは、図１４に示すように、整数個のＣｏｎｔｉｎｕｏｕｓ Ｕｎｉｔ（ＣＵ）で構成されている。ＣＵとは、ディスク上で連続的に記録されるデータの単位である。また、ＣＵの長さは、ＡＶストリームを構成するＣＵをどのようにディスク上に配置しても、シームレス再生やリアルタイムアフレコが保証されるように設定される。
なお、シームレス再生とは、再生中に画像や音声を途切れさせないで再生することをいう。また、リアルタイムアフレコとは、アフレコ対象のビデオをシームレス再生しながらオーディオを記録することをいう。
さらに、ＣＵは、図１４に示すように、整数個のＶｉｄｅｏ Ｕｎｉｔ（ＶＵ）で構成される。ＶＵとは、単独再生可能なデータの単位であり、再生の際のエントリポイントとなり得る。
ＶＵは、図１５に示すように、１秒程度のビデオデータを格納した整数個のＧＯＰ（Ｇｒｏｕｐ Ｏｆ Ｐｉｃｔｕｒｅ）と、それらと同じ時間に再生されるメインオーディオデータを格納した整数個のＡＡＵ（Ａｕｄｉｏ Ａｃｃｅｓｓ Ｕｎｉｔ）とから構成される。
なお、ＧＯＰは、ＭＰＥＧ−２ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。また、ＡＡＵはＭＰＥＧ−１ Ｌａｙｅｒ−ＩＩ規格における音声圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数がたとえば４８ｋＨｚの場合、ＡＡＵあたりの再生時間は０．０２４秒となる。
なお、ＶＵ中では、ＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ、ＧＯＰの順に配置する。
また、ＶＵ単位で独立再生を可能とするために、ＶＵ中のビデオデータの先頭にはＳｅｑｕｅｎｃｅ Ｈｅａｄｅｒ（ＳＨ）を置く。ＶＵの再生時間は、ＶＵに含まれるビデオフレーム数にビデオフレーム周期をかけたものと定義する。
〔ＡＶストリームの管理方法について〕
本発明におけるＡＶストリームの管理方法について、図１６を用いて説明する。ＡＶストリーム管理方法は、ＱｕｉｃｋＴｉｍｅファイルフォーマットをベースにするものであり、ビデオデータおよびオーディオデータを、それぞれビデオトラック、オーディオトラックでそれぞれ管理する。
すなわち図１６に示すように、ビデオトラックは、ＧＯＰを１サンプル、ＶＵ中のビデオの塊を１チャンクとして管理する。一方、メインオーディオトラックは、ＡＡＵを１サンプル、ＶＵ中のオーディオの塊を１チャンクとして管理する。
〔ファイルシステムについて〕
本発明の説明において用いるファイルシステムのフォーマットである、ＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａｔ）について、図１７を用いて説明する。
図１７（ａ）に、ファイル４０・４１・４２のディレクトリ構成を示す。また、図１７（ｂ）に、図１７（ａ）に示すディレクトリ／ファイル構成をＵＤＦで記録した例を示す。
図１７（ｂ）において、参照番号４４により示されるＡＶＤＰとは、Ａｎｃｈｏｒ Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｐｏｉｎｔｅｒの略である。ＡＶＤＰ４４は、ＵＤＦの管理情報を探すためのエントリポイントに相当し、通常２５６セクタ目、Ｎセクタ目あるいはＮ−２５６セクタ目に記録する。なお、Ｎは最大論理セクタ番号である。
また、参照番号４３により示されるＶＤＳとは、Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｓｅｑｕｅｎｃｅの略である。ＶＤＳ４３は、ＵＤＦが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは、一般に１枚のディスクに１個存在し、その中にパーティションを一般に１個含む
また、参照番号４５により示されるＦＳＤとは、Ｆｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔｏｒの略である。ＦＳＤ４５は、パーティションに１個存在する。なお、パーティションの中での位置情報は、パーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。また、１個の論理ブロックは１セクタに対応する。
さらに、ＦＳＤ４５は、ルートディレクトリのＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）であるＦＥ４６の位置情報（論理ブロック番号と論理ブロック数で構成され、ｅｘｔｅｎｔと呼ばれる）を含む。
ＦＥとは、ｅｘｔｅｎｔの集合を管理するものである。ｅｘｔｅｎｔを書き換えたり、追加したり、削除することで、ファイルを構成する実データの順番を変えたり、データを挿入したり削除したりすることが可能である。
ＦＥ４６は、ルートディレクトリの直下のファイルやディレクトリの名称等を格納するＦＩＤ（Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒ）の集合を格納する領域４７を管理する。
領域４７中のＦＩＤ５３、ＦＩＤ５４は、それぞれファイル４１、ファイル４２のファイル名やｅｘｔｅｎｔの集合を管理するＦＥ４８、ＦＥ５０の位置情報を含む。
ＦＥ４８は、ファイル４１の実データを構成する領域である領域４９、領域５２をｅｘｔｅｎｔとして管理する。このときファイル４１の実データにアクセスするためには、ＡＶＤＰ４４、ＶＤＳ４３、ＦＳＤ４５、ＦＥ４６、ＦＩＤ５３、ＦＥ４８、領域４９、領域５２の順にリンクを辿っていけばよい。
〔第１の実施形態〕
本発明の第１の実施形態について、図１８ないし図３２を用いて説明する。なお、第１の実施形態を説明するにあたっては、項目（１．管理情報フォーマットについて）・（２．全体の流れについて）・（３．録画処理について）・（４．付加情報変更処理について）・（５．ＡＶ Ｉｎｄｅｘファイル記録処理について）・（６．インデックスファイル画面表示処理について）・（７．変更態様について）を設け、これらの項目を順番に説明する。
（１．管理情報フォーマットについて）
先ず、本発明の第１の実施形態を説明するにあたり、管理情報のフォーマットを説明する。上述のように、ディスク内に含まれるＱｕｉｃｋＴｉｍｅムービーや、静止画データ等のコンテンツと管理情報とを含む各種ファイル（以後、コンテンツファイルと呼ぶ）を管理するため、ＡＶ Ｉｎｄｅｘファイル（インデックス情報）という特別のＱｕｉｃｋＴｉｍｅムービーファイルをディスク内に置く。
図１８に、本実施形態におけるＡＶ Ｉｎｄｅｘファイルの構成を示す。ＡＶ Ｉｎｄｅｘファイルは、通常のＱｕｉｃｋＴｉｍｅムービーファイルと同様、管理情報であるＭｏｖｉｅ ａｔｏｍ６０と、データ自体のＭｏｖｉｅ ｄａｔａ ａｔｏｍ６１とで構成される。また、ＡＶ Ｉｎｄｅｘファイルは、複数のエントリを管理し、ディスク内の各コンテンツファイルは、それぞれ１個のエントリで管理される。
Ｍｏｖｉｅ ａｔｏｍ６０は、各エントリの属性情報を管理するためのＰｒｏｐｅｒｔｙ ｔｒａｃｋ６２、各エントリのタイトル文字列データを管理するためのＴｉｔｌｅ ｔｒａｃｋ６３、各エントリの代表画像データを管理するためのＴｈｕｍｂｎａｉｌ ｔｒａｃｋ６４、および各エントリの代表オーディオデータを管理するためのＩｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ６５の計４種類のトラックで構成される。
各エントリに関する属性情報やタイトル文字列データ、代表画像データ、代表オーディオデータは、それぞれ参照番号６２〜６５にて示されるトラックのサンプルとして管理される。
たとえばコンテンツファイル６６に関する属性情報はＰｒｏｐｅｒｔｙ ｔｒａｃｋ６２上のサンプル６７、タイトル文字列データはＴｉｔｌｅ ｔｒａｃｋ６３上のサンプル６８、代表画像データはＴｈｕｍｂｎａｉｌ ｔｒａｃｋ ６４上のサンプル６９、代表オーディオデータはＩｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ６５上のサンプル７０で管理する。
また、コンテンツファイル７１に関する属性情報はＰｒｏｐｅｒｔｙ ｔｒａｃｋ６２上のサンプル７２、タイトル文字列データはＴｉｔｌｅ ｔｒａｃｋ６３上のサンプル７３、代表画像データはＴｈｕｍｂｎａｉｌ ｔｒａｃｋ６４上のサンプル７４、代表オーディオデータはＩｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ６５上のサンプル７５で管理する。
同様に、コンテンツファイル７６に関する情報は、サンプル７７〜８０で管理し、コンテンツファイル８１に関する情報は、サンプル８２〜８５で管理し、コンテンツファイル８６に関する情報は、サンプル８７〜９０で管理する。
なお、サンプル間の対応付けは、各サンプルの再生開始時間に基づき行う。すなわち、トラック間で同一時刻に位置するサンプルは、同一エントリに対応していると判断する。
Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ６１は、各コンテンツファイルに関する属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータを格納する。
属性情報は、図１９に示すように、ｖｅｒｓｉｏｎと、ｆｌａｇｓと、ｅｎｔｒｙ−ｎｕｍｂｅｒと、ｃｒｅａｔｉｏｎ−ｔｉｍｅと、ｍｏｄｉｆｉｃａｔｉｏｎ−ｔｉｍｅと、ｄｕｒａｔｉｏｎと、ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒとを含んでいる。
ｖｅｒｓｉｏｎは、ファイルフォーマットのバージョンを示す。ｆｌａｇｓは各種フラグをまとめたものである。ｅｎｔｒｙ−ｎｕｍｂｅｒは、属性情報に対応するエントリのＩＤを格納するものである。ｃｒｅａｔｉｏｎ−ｔｉｍｅは、属性情報に対応するエントリが作成された日時を表すものである。ｍｏｄｉｆｉｃａｔｉｏｎ−ｔｉｍｅは、属性情報に対応するエントリが修正された日時を表すものである。ｄｕｒａｔｉｏｎは、属性情報に対応するエントリの再生時間を表すものである。ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒは、管理情報に対応するエントリがファイルに対応していた場合、そのファイルのファイル名を格納するものである。
ｆｌａｇｓは、図２０に示すように、Ｓｔａｔｕｓ ｏｆ Ｅｎｔｒｙと、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎとが存在する。
Ｓｔａｔｕｓ ｏｆ Ｅｎｔｒｙは、対応するエントリが有効（ａｖａｉｌａｂｌｅ）か無効（ｉｎｖａｌｉｄ）かを識別するためのフラグである。Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎは、対応するエントリが拡張付加情報を持っている（Ｔｈｅ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅ ｈａｓ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）か、持っていない（Ｔｈｅ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅ ｈａｓ ｎｏ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）かを識別するためのフラグ（識別情報）である。
Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ６１に格納されるその他のデータについて説明する。代表画像データには１６０×１２０画素に縮小されたＪＰＥＧ圧縮されたデータ、タイトル文字列データにはテキストデータ、代表オーディオデータにはＭＰＥＧ−１ Ａｕｄｉｏ Ｌａｙｅｒ−ＩＩで圧縮されたデータがそれぞれ用いられる。
（２．全体の流れについて）
次に、本実施形態における、ディスク挿入から、ディスクイジェクトあるいは電源ＯＦＦまでの流れを、図２１に示す。
光ディスク６が挿入されたら、前述のシーケンスに沿って、まずファイルシステムの管理情報を読みこむ（ステップ１）。なお、以下の説明では、ステップを単に「Ｓ」と記載する。
次に、ＡＶ Ｉｎｄｅｘファイルを光ディスク６から読み込み、インデックス画面の表示を行う（Ｓ２）。その後、現在がＡＶ Ｉｎｄｅｘファイルをディスクに記録するタイミングかどうかチェックする（Ｓ３）。
なお、記録するタイミングとは、ディスクイジェクト指示や電源ＯＦＦ、あるいはＲＡＭ２に新規の情報を光ディスク６から読み出すために、ＲＡＭ２上のＡＶ Ｉｎｄｅｘファイルに関する情報を光ディスク６に一旦記録するために必要になるタイミングである。
Ｓ３において、現在が記録するタイミングであると判断された場合、Ｓ４においてＡＶ Ｉｎｄｅｘ記録処理を行う。その後、ファイル・ディレクトリ情報記録を行う（Ｓ５）。次に、ＡＶ Ｉｎｄｅｘ記録を行うトリガーとなったのが、電源ＯＦＦあるいはディスクイジェクトがどうかをチェックする（Ｓ６）。
一方、Ｓ３において、現在は記録するタイミングではないと判断された場合、ユーザからの指示が無いかチェックする（Ｓ７）。Ｓ７にてユーザからの指示があると判断された場合、ユーザからの指示に沿って後述する各種処理を実行し（Ｓ８）、各種処理が終了したら、処理結果を反映してインデックス画面表示更新処理を実行する（Ｓ１８）。
次に、Ｓ８における各種処理について図２２を用いて説明する。
まず、ユーザからの指示が録画かどうかをチェックし（Ｓ９）、録画であれば後述する録画処理を行う（Ｓ１０）。指示が録画でなければ、指示がエントリ削除、すなわち既存のコンテンツファイルの削除かどうかをチェックし（Ｓ１１）、エントリ削除ならエントリ削除処理（Ｓ１２）を実行する。
次に、指示が録画でもエントリ削除でもなければ、指示が既存のエントリに関する付加情報の変更かどうかをチェックし（Ｓ１３）、そうであれば後述する付加情報変更処理（Ｓ１４）を実行する。
指示が付加情報変更でなければ、次に、既存のエントリに関する代表画像データ、タイトル文字列データ、代表オーディオデータ、および属性情報のいずれかの変更かどうかをチェックし（Ｓ１５）、そうであれば属性情報等変更処理（Ｓ１６）を実行する。指示されたのが属性情報等変更処理でなければ、その他処理（Ｓ１７）を実行する。
次に、各種処理の内容について詳細を説明する。なお、エントリ削除処理および属性情報等変更処理については本発明の内容に関係ないため説明を省略する。
ここでは、処理を開始する前の初期状態として、光ディスク６に、図２３（ａ）に示すようなディレクトリ構成でファイルが記録され、それぞれが光ディスク６上に図２３（ｂ）に示すように配置されていると仮定する。
すなわち、コンテンツファイルであるＳＨＲＰ０００１．ＭＯＶ、ＳＨＲＰ０００２．ＭＯＶおよびＳＨＲＰ０００３．ＭＯＶは、それぞれ、ＡＶ ｆｉｌｅ９１ａ、ＡＶ ｆｉｌｅ９１ｂ、およびＡＶ ｆｉｌｅ９１ｃの位置に記録される。
またＡＶ ＩｎｄｅｘファイルであるＡＶＩＦ００００．ＭＯＶは、図２３（ｂ）中のＡＶ Ｉｎｄｅｘ ｆｉｌｅ９２の領域に記録され、ＡＶ Ｉｎｄｅｘ ｆｉｌｅ９２の領域の先頭にはＡＶ Ｉｎｄｅｘ ｆｉｌｅのＭｏｖｉｅ ａｔｏｍが領域９３に記録される。
また、ＳＨＲＰ０００１．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データは、それぞれ領域９４ａ、領域９５ａ、領域９６ａに記録され、ＳＨＲＰ０００２．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データは、それぞれ領域９４ｂ、領域９５ｂ、領域９６ｂに記録され、ＳＨＲＰ０００３．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データは、それぞれ領域９４ｃ、領域９５ｃ、領域９６ｃに記録されているとする。
後述するインデックス画面表示処理を行った結果、ＲＡＭ２には、図２４に示すように、ＡＶ Ｉｎｄｅｘファイルに関する情報を管理するためのテーブルが構成される。以下、このテーブルをＡＶ Ｉｎｄｅｘ管理テーブルと呼ぶ。
ＡＶ Ｉｎｄｅｘ管理テーブルの各行は、ディスク挿入時に読み出したＡＶ Ｉｎｄｅｘの状態およびその後の各エントリの更新を管理する。また、ＡＶ Ｉｎｄｅｘ管理テーブルの各行には、拡張付加情報有無を示すフラグ（識別情報）を含む属性に関する情報や、各エントリが管理するコンテンツファイルの名称、ＲＡＭ２の別領域に保持している代表画像データへのポインタ情報を持つ。
なお、代表オーディオデータおよびタイトル文字列データに関しては説明を簡単にするため図示していないが、それぞれ、代表画像データおよび属性情報と同様の扱いを行う。また、各ファイルの名称は実際にはルートディレクトリからのフルパスで管理しているが、ここでは簡単のため、ディレクトリ名は省略している。
（３．録画処理について）
本実施形態における録画時の処理を説明する。ユーザから録画が指示されたら、まずオーディオエンコーダ１７およびビデオエンコーダ１８を起動し、カメラおよびマイク（図示せず）からの入力データを、前述の符号化方式にてエンコードを開始する。
エンコードされたオーディオデータとビデオデータは、マルチプレクサ１３によって、前述のＡＶストリームフォーマットに従って多重化される。その際に、後にＭｏｖｉｅ ａｔｏｍを記録するのに必要となる、ＧＯＰのサイズや再生時間などをＲＡＭ２に蓄積していく。
また、録画時に得られるＧＰＳ位置情報もＲＡＭ２に保持する。また、入力ビデオから先頭画像を代表画像として抜き出し縮小したものを、ＪＰＥＧ符号化でエンコードし、代表画像データを作成し、ＲＡＭ２に保持する。さらに、多重化結果であるＡＶストリームは、記録／アフレコ用バッファ１１およびＥＣＣエンコーダ９を経由して、ピックアップ７によって光ディスク６に記録される。
ユーザから録画停止が指示され、記録／アフレコ用バッファ１１に残ったＡＶストリームを光ディスク６へ記録し終わったら、Ｍｏｖｉｅ ａｔｏｍ中のｕｓｅｒ ｄａｔａ ａｔｏｍにおいてｕｓｅｒ ｄａｔａ ｔｙｐｅを“ｇｂｐｓ”とし、ＲＡＭ２に保存されているＧＰＳ位置情報をｕｓｅｒ ｄａｔａへ格納する。最後にＭｏｖｉｅ ａｔｏｍの記録を行う。
録画が終了した時点で、ＲＡＭ２上のＡＶ Ｉｎｄｅｘ管理テーブルには、図２５に示すように、行番号３で示す行を追加する。以下、その行の内容について説明する。
図２５に示すように、属性情報において、ｅｎｔｒｙ−ｎｕｍｂｅｒは既存の番号と重複しない番号を格納する。また、記録時に拡張付加情報がある場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’とする。
コンテンツファイル名称に関しても、ＡＶ Ｉｎｄｅｘ管理テーブルにおける既存のコンテンツファイル名称の５桁目から８桁目までの数字部分が、ファイルシステム的に重複しないファイル名称を生成して格納する。また、代表画像データに関しては、記録時に生成した前述の代表画像データのＲＡＭ２上でのアドレスを格納する。
（４．付加情報変更処理について）
次に、すでに録画済のコンテンツに対し、付加情報を追記、変更もしくは削除する場合について、図２６を参照しながら説明する。既に録画済のコンテンツに追記する付加情報としては、ユーザが自由に編集可能なコンテンツに関するコメント（ｄｅｓｃｒｉｐｔｉｏｎ）や作者、出演者などの情報がある。
ユーザから付加情報変更が指示されたら、指定されたコンテンツの含まれるコンテンツファイルのｍｏｖｉｅ ａｔｏｍを開き、ｕｓｅｒ ｄａｔａ ａｔｏｍを読み込む。次に、ユーザが指定したタイプ（ｔｙｐｅ）の拡張付加情報エントリが既に存在するか否か、すなわち、付加情報の追記か否かをチェックする（Ｓ１４０１）。
存在しないｔｙｐｅが指定された場合、つまり、追記の場合（Ｓ１４０１でＹＥＳ）、新規にエントリを作成し（Ｓ１４０２）、情報を記録する（Ｓ１４０３）。
次に、ＡＶ Ｉｎｄｅｘファイルのプロパティ情報を見て、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグ（拡張付加情報有無フラグ）をチェックする（Ｓ１４０４）。Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（拡張付加情報が存在する）になっていた場合（Ｓ１４０４でＮＯ）、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’のままにして、変更を行わない。
一方、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘０’（拡張付加情報が存在しない）になっていた場合（Ｓ１４０４でＹＥＳ）、ＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリの付加情報を調べる（Ｓ１４０５）。追記したものと同じ付加情報が存在しない場合、つまり、異なるタイプの付加情報のみが存在する場合（Ｓ１４０５でＹＥＳ）、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’（拡張付加情報が存在する）に書き換える（Ｓ１４０６）。既に追記したものと同じ付加情報が存在する場合（Ｓ１４０５でＮＯ）、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘０’のまま変更を行わない。
Ｓ１４０１において、すでに存在するｔｙｐｅが指定された場合、つまり、追記ではない場合（Ｓ１４０１でＮＯ）、ユーザからの指示が付加情報の変更か否かをチェックする（Ｓ１４０７）。
付加情報を変更する場合（Ｓ１４０７でＹＥＳ）、変更情報をｕｓｅｒ ｄａｔａに上書きして終了する（Ｓ１４０８）。
付加情報を変更しない場合（Ｓ１４０７でＮＯ）、ユーザからの指示が付加情報の削除か否かをチェックする（Ｓ１４０９）。コンテンツファイルからすでに存在する付加情報の削除が指示された場合（Ｓ１４０９でＹＥＳ）、付加情報の削除を行う（Ｓ１４１０）。次に、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’か否かをチェックする（Ｓ１４１１）。
Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’の場合（Ｓ１４１１でＹＥＳ）、コンテンツファイル内に残った他のｔｙｐｅの付加情報が、ＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリ内にも存在するかどうかを調べる（Ｓ１４１２）。他の付加情報が全てＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリに含まれていた場合、すなわち、コンテンツファイル内に、ＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリに含まれる付加情報と異なるタイプの付加情報が存在しない場合（Ｓ１４１２でＮＯ）、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘０’に書き換える（Ｓ１４１３）。一方、他の付加情報が全てＡＶ Ｉｎｄｅｘファイルのコンテンツに対応するエントリに含まれていない場合（Ｓ１４１２でＹＥＳ）、‘１’のまま変更は行わない。
また、付加情報を削除したことによって、コンテンツファイル内にひとつも付加情報が存在しなくなった場合も、フラグを‘０’に書き換える。
さらに、コンテンツファイルに付加情報を追記すると同時に、ＡＶ Ｉｎｄｅｘファイルにも同じ付加情報を追記してもよい。この場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの書き換えは行わない。
（５．ＡＶ Ｉｎｄｅｘファイル記録処理について）
次に、ＡＶ Ｉｎｄｅｘファイル記録処理を図２７を用いて説明する。先ず、図２７に示すように、ＡＶ ＩｎｄｅｘファイルのＳａｍｐｌｅ ｔａｂｌｅの構築をＲＡＭ２上で行う（Ｓ２０）。次に、ＡＶ ＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍを記録し（Ｓ２１）、ＡＶ Ｉｎｄｅｘ管理テーブル中の全エントリの属性情報およびタイトル文字列を記録し（Ｓ２２）、最後に、代表画像データおよび代表オーディオデータを記録する（Ｓ２３）。
（６．インデックスファイル画面表示処理について）
本実施形態におけるインデックスファイル画面表示処理を図２８を用いて説明する。まず、ＡＶ Ｉｎｄｅｘファイルをｏｐｅｎし（Ｓ３０）、Ｍｏｖｉｅ ａｔｏｍを読み込み、上述のＡＶ Ｉｎｄｅｘ管理テーブルをＲＡＭ２上に作成する（Ｓ３１）。ただし、この時点では、代表画像データ等各種データの位置情報のみを取得したのみであり、まだ各種データのＲＡＭ２上への読み込みは行っていない。
次に、各エントリのタイトル文字列データおよび属性情報を読み出し、ＡＶ Ｉｎｄｅｘ管理テーブルに格納する（Ｓ３２）。その後、現在ｏｐｅｎ中のＡＶ Ｉｎｄｅｘファイルに、有効なサムネイルが存在するか否かを判断し（Ｓ３３）、有効なサムネイルがあれば、そのサムネイルを読出し（Ｓ３４）、代表画像データをインデックスファイル画面として表示したり、代表オーディオデータを再生する。
このようにして表示したＡＶ Ｉｎｄｅｘの画面イメージを図２９に示す。図２９に示すように、ユーザがサムネイル選択枠を次から次へと移動させるに従って、画面の下部に、選択されたコンテンツの含まれるコンテンツファイルの属性情報（撮影日時、再生時間等）や、タイトルを表示する。
なお、属性情報の拡張付加情報有無フラグ（Ｅｘｉｓｔｅｎｃｅ Ｓｔａｔｕｓ ｏｆ Ｅｘｔｅｎｄ Ｉｎｆｏｒｍａｔｉｏｎ）が‘１’となっていた場合には、この部分に拡張付加情報が存在することを示すアイコンあるいは拡張付加情報を表示するためのボタンを表示する。
拡張付加情報を表示する際の処理について説明する。インデックス画面表示中にユーザから拡張付加情報表示の指示があったら、ＡＶ Ｉｎｄｅｘのエントリに対応するコンテンツファイルをｏｐｅｎするとともに、Ｍｏｖｉｅａｔｏｍの中のｕｓｅｒ ｄａｔａ ａｔｏｍを読み込み、図３０に示すように、拡張付加情報のタイプと内容とを表示する。なお、再生の指示がなく、「インデックス画面に戻る」ボタンが選択された場合や、「次へ」あるいは「前へ」ボタンが選択されて、別のコンテンツファイルの拡張付加情報表示が指示された場合は、現在拡張付加情報を表示しているコンテンツファイルをｃｌｏｓｅする。
このように、インデックス画面表示中にコンテンツの拡張付加情報に関する情報を表示することで、コンテンツの含まれるコンテンツファイルにアクセスせずともインデックス表示画面で拡張付加情報の有無がわかり、所望の映像を検索する際にさらに使い勝手の良いものとなる。
また、拡張付加情報は、コンテンツファイル内に格納するので、多くの拡張付加情報があった場合でも、インデックス表示の体感レスポンスを落とさずに、より多くの情報をすばやく見ることが可能となる。また、ＧＰＳ位置情報のような拡張付加情報を、コンテンツの含まれるコンテンツファイルに格納することで、管理が容易になる。
（７．変更態様について）
本実施形態では、拡張付加情報の読み出しは、ユーザが拡張付加情報の表示を指示した後に行っているが、本発明はそれに限定されるものではない。
たとえば、インデックス画面表示が完了してから、実際にユーザが指示するまでの空き時間に、拡張付加情報有無のフラグが立っているコンテンツファイルについての拡張付加情報をＲＡＭ２に読み出してもよい。
これにより、インデックス画面の表示に要する時間を増加させることなく、ユーザが指示してから実際に拡張付加情報が表示されるまでのレスポンスを短縮することが可能である。また、拡張付加情報の読み出す順番については、インデックス画面で現在表示されているコンテンツの含まれるコンテンツファイルを優先して読み出すことで、さらに効率的に拡張付加情報の表示が行える。
また、記録媒体としてフラッシュメモリを用いた場合、光ディスクに比べてアクセス時間が短いので、ＡＶ Ｉｎｄｅｘファイルに含まれている基本情報のＲＡＭ２への読み出しと同時に、拡張付加情報有無のフラグが立っているコンテンツファイルについて、拡張付加情報の読み出しを行ってもよい。
この場合、ＲＡＭ２上にすべてのコンテンツの拡張付加情報が保持されているため、たとえばコンテンツをグループ分けして表示することが可能になる。すなわち、本発明によれば、記録媒体の特性に応じて、拡張付加情報を最適に読み出すことができる。
また、本実施形態では、拡張付加情報の有無を示すフラグ（識別情報）をひとつ用意したが、拡張付加情報の種類毎にフラグを用意してもよい。
すなわち、図３１に示すように、機器が対応する拡張付加情報毎にフラグを設け、情報があれば‘１’を、情報がなければ‘０’を設定する。さらに、図３２に示すように、インデックス表示画面において、各拡張付加情報に対応するアイコンを用意し、フラグが‘１’になっている拡張付加情報に対応するアイコンを表示する。
これにより、インデックス表示画面上で選択したコンテンツの含まれるコンテンツファイルがどのような拡張付加情報を持っているかをユーザが一目で確認することができる。さらに、たとえばコメント情報を持つコンテンツだけを抽出し、そのコンテンツの含まれるコンテンツファイルのコメント情報のみを先にＲＡＭ２に読み出すことにより、インデックス表示画面で選択された際にコメントをテロップ表示させることも可能になる。
また、ＡＶ Ｉｎｄｅｘのプロパティ情報に、拡張付加情報を再生可能な機器に関する情報、たとえばメーカーＩＤを追加してもよい。これにより、メーカー独自の情報を拡張付加情報に持つことができ、その独自の拡張付加情報を再生機器のメーカーＩＤがプロパティ情報のメーカーＩＤと一致した場合のみ読み込んでインデックス画面に表示させるなどの読み出しの制御が可能になる。
また、本実施形態では、拡張付加情報はコンテンツファイル内に格納したが、本発明はそれに限定されるものではない。たとえば、コンテンツを格納するコンテンツファイルをＳＨＲＰ０００１．ＭＯＶとしたとき、それに対応する拡張付加情報をＳＨＲＰ０００１．ＭＯＶではなく、ＳＨＲＰ０００１．ＥＸＴに格納してもよい。
この場合、拡張付加情報を含むファイルのファイル名は、コンテンツを格納するコンテンツファイルのファイル名の拡張子を“ＥＸＴ”に変更することで特定可能である。拡張付加情報をコンテンツとは別ファイルに格納することによって、拡張付加情報だけを容易に抜き出すことが可能になる。
なお、本実施形態では、拡張付加情報にＧＰＳ位置情報を用いているが、本発明はそれに限定されるものではなく、たとえば、第２の実施形態で説明する動画サムネイルや温度、湿度、天候、撮影者名、編集者名等様々な情報が対象となることはいうまでもない。
〔第２の実施形態〕
本発明の第２の実施形態について説明する。第１の実施形態との違いは、第２の実施形態においては、ＡＶ Ｉｎｄｅｘの属性情報に、動画サムネイルの有無を示すフラグを設けることにある。なお、動画サムネイルはサイズが大きいためＡＶ Ｉｎｄｅｘファイルには格納されず、コンテンツファイル内に格納される。
したがって、第２の実施形態では、インデックス表示中にフラグが立っているコンテンツの含まれるコンテンツファイルに対してのみ動画サムネイルを読みにいくことで、全体的なインデックス表示の体感レスポンスを落とさずに、次々と静止画サムネイルから動画サムネイルへ切り替えて表示することが可能になる。
なお、第２の実施形態の構成は、第１の実施形態の構成と共通する部分が多いため、第２の実施形態と第１の実施形態との間の相違点に絞って第２の実施形態について説明を行う。
（１．管理情報フォーマットについて）
本実施形態におけるＡＶ Ｉｎｄｅｘファイルの構成は、図３３に示すように、属性情報のフラグに動画サムネイルの有無を示すＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｍｏｖｉｅ ｔｈｕｍｂｎａｉｌフラグが含まれている以外は、第１の実施形態と共通である。なお、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｍｏｖｉｅ ｔｈｕｍｂｎａｉｌフラグが‘０’の場合は、動画サムネイルが存在しないことを示し、‘１’の場合は動画サムネイルが存在することを示す。
（２．全体の流れについて）
本実施形態における全体の流れは、第１の実施形態と同様であるので、説明を省略する。
（３．録画処理について）
本実施形態では、記録／アフレコ用バッファ１１に残ったＡＶストリームを、光ディスク６に記録する際、ＡＶストリームの最初の数秒間をＭｏｔｉｏｎ ＪＰＥＧで圧縮し、動画サムネイルとして、ＡＶストリーム本体とは別にコンテンツファイル内に格納する。動画サムネイルの記録をした場合は、ＡＶ Ｉｎｄｅｘの属性情報の動画サムネイル有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｍｏｖｉｅ ｔｈｕｍｂｎａｉｌ）を‘１’にする。それ以外の処理は、第１の実施形態と共通である。
（４．付加情報変更処理について）
本実施形態における付加情報変更処理は、第１の実施形態と同様であるので、説明を省略する。
（５．ＡＶ Ｉｎｄｅｘ記録処理について）
本実施形態におけるＡＶ Ｉｎｄｅｘ記録処理は、第１の実施形態と同様であるので、説明を省略する。
（６．インデックスファイル画面表示処理について）
本実施形態のインデックスファイル画面表示処理は、動画サムネイルの表示に関する部分以外について第１の実施形態と同様である。したがって、本実施形態において動画サムネイルを表示する際の処理について説明する。
本実施形態では、ＡＶ Ｉｎｄｅｘファイルの代表画像データ等の基本情報に関するインデックス表示が終わったら、属性情報において動画サムネイル有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｍｏｖｉｅ ｔｈｕｍｂｎａｉｌ）が‘１’になっているＡＶ Ｉｎｄｅｘファイルについて、順番に対応するコンテンツファイルをｏｐｅｎする。そして、動画サムネイルデータを読み込み、代表画像データによるサムネイルと置き換え、動画サムネイルをインデックス表示画面上に表示する。
これにより、全体的なインデックス表示の体感レスポンスを落とさずに、次々と効率よく静止画サムネイルから動画サムネイルへ切り替えて表示することが可能になる。
〔第３の実施形態〕
次に、本発明の第３の実施の形態を説明する。本実施形態において、拡張付加情報の有無を示すフラグＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎとは、コンテンツファイル内に拡張付加情報が存在しない状態と、存在する、あるいは存在するかどうかわからない状態とのどちらかの状態を示すものである。存在するという状態を保証する必要がないため、付加情報の記録・編集時にＡＶ Ｉｎｄｅｘとコンテンツファイルの付加情報を常に比較し、拡張付加情報がコンテンツファイルに含まれるかどうかを調べるという処理を行わない機器があってもよい。
なお、第３の実施形態の構成は、第１の実施形態と共通する部分が多いため、相違点に絞って説明を行う。
（１．管理情報フォーマットについて）
本実施形態におけるＡＶ Ｉｎｄｅｘファイルの構成は図３４に示すように、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎの示す意味が第１の実施形態と異なる点を除けば、第１の実施形態と共通である。本実施形態では、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎが‘０’の場合は、対応するコンテンツファイルに拡張付加情報が存在する、もしくは存在するかどうかが分からない状態を示し、‘１’の場合は、対応するコンテンツファイルに拡張付加情報が存在しない状態を示す。
（２．全体の流れについて）
本実施形態における全体の流れは、第１の実施形態と同様であるので、説明を省略する。
（３．録画処理について）
録画が終了した時点で、ＲＡＭ２上のＡＶ Ｉｎｄｅｘ管理テーブルを更新する際に、記録時にコンテンツファイルに対して拡張付加情報がある場合はＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘０’に、拡張付加情報がない場合はＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’として記録する。
上記以外の処理については、第１の実施形態と同様であるので説明を省く。
（４．付加情報変更処理について）
次に、本実施形態における付加情報変更時の処理について説明する。Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの書き換えのところを除けば、付加情報の記録に関して第１の実施の形態と同様である。
Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの書き換えの処理について説明する。図３５は、フラグの書き換えの条件を示している。
まず、既に録画済みのコンテンツの含まれるコンテンツファイルに対し付加情報を追記する場合について説明する。この場合、追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの状態により、処理が異なる。
追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（存在しない）になっていた場合、ＡＶ Ｉｎｄｅｘのコンテンツに対応するエントリに同じ情報が既に含まれているかどうかを調べる。追加したのと同じ情報が含まれていた場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’のままにして、変更を行わない。あるいは、調べる処理を行わずに‘０’（存在するか不明）にしてもよい。
一方、追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが’０’（存在するか不明）になっていた場合、コンテンツファイルに含まれる付加情報の全てがＡＶ Ｉｎｄｅｘのコンテンツに対応するエントリに含まれているかどうかを調べる。付加情報の全てが含まれていた場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’（存在しない）に変更する。あるいは、調べる処理を行わずに、‘０’のままにして、変更を行わなくてもよい。
次に、コンテンツファイルに含まれる付加情報を削除する場合について説明する。この場合、削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの状態により、処理が異なる。
削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（存在しない）になっていた場合、該フラグを‘１’のままにして、変更を行わない。
一方、削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘０’（存在するか不明）になっていた場合、コンテンツファイルに含まれる付加情報がまったく無いか、もしくは全てＡＶ Ｉｎｄｅｘのコンテンツに対応するエントリに含まれているかどうかを調べる。コンテンツファイル内に付加情報がまったく無い、もしくはＡＶ Ｉｎｄｅｘに全て含まれていた場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’（存在しない）に変更する。あるいは、調べる処理を行わずに’０’のまま変更を行わなくてもよい。
次に、ＡＶ Ｉｎｄｅｘに付加情報を追記する場合について説明する。この場合も、追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの状態により、処理が異なる。
追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（存在しない）になっていた場合、‘１’のまま変更を行わない。
一方、追記前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘０’（存在するか不明）になっていた場合、ＡＶ Ｉｎｄｅｘに追記した内容が既に対応するコンテンツファイルに含まれているか否かを調べる処理を行う。ＡＶ Ｉｎｄｅｘに追記した内容が既に対応するコンテンツファイルに含まれている場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’に変更する。あるいは、調べる処理を行わずに、‘０’のまま変更を行わなくても良い。
さらに、ＡＶ Ｉｎｄｅｘ内に含まれる情報を削除する場合について説明する。この場合も、削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの状態により、処理が異なる。
削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘１’（存在しない）になっていた場合、削除を行う情報が対応するコンテンツファイルに含まれている内容かどうかを調べる処理を行う。対応するコンテンツファイルに存在する場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘０’に変更する。あるいは、調べる処理を行わずに’０’に変更する。
削除前のＥｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグが‘０’（存在するか不明）になっていた場合、対応するコンテンツファイルに含まれる付加情報の全てがＡＶ Ｉｎｄｅｘ内に含まれているかどうかを調べる処理を行う。全て含まれていた場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグを‘１’（存在しない）に変更する。あるいは、調べる処理を行わずに‘０’のまま変更を行わなくてもよい。
コンテンツファイルとＡＶ Ｉｎｄｅｘとに同時に同じ情報を追記する、あるいは削除する場合、Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎフラグの書き換えを行わない。
（５．ＡＶ Ｉｎｄｅｘ記録処理について）
本実施形態におけるＡＶ Ｉｎｄｅｘ記録処理は、第１の実施形態と同様であるので、説明を省略する。
（６．インデックスファイル画面表示処理について）
本実施形態のインデックスファイル画面表示処理は、拡張付加情報有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）の値を見て、インデックス画面に反映させるところ以外は第１の実施形態と同様である。
本実施形態においては、コンテンツファイルに拡張付加情報が存在しない場合が‘１’、存在するかもしれない場合が‘０’であるため、拡張付加情報有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）が‘０’となっているエントリについては、コンテンツファイルを開き、拡張付加情報が存在するか否かを確認する必要がある。
拡張付加情報が存在すると確認されたエントリについては、インデックス画面の下部に拡張付加情報が存在することを示すアイコンあるいは拡張付加情報を表示するためのボタンを表示する。
一方、拡張付加情報が存在しないと確認されたエントリについては、このとき拡張付加情報有無フラグ（Ｅｘｉｓｔｅｎｃｅ ｓｔａｔｕｓ ｏｆ ｅｘｔｅｎｄ ｉｎｆｏｒｍａｔｉｏｎ）を‘１’に書き換える。
このように、表示の際にコンテンツファイルを確認して、拡張付加情報が存在しないのに拡張付加情報有無フラグが‘０’となっていたエントリについて‘１’に書き換えていくことで、無駄なアクセスが少なくなっていく。
また、インデックス画面表示の体感レスポンスを落とさないよう、拡張付加情報が存在するか否かを確認する処理は、１画面に表示するすべてのエントリについてサムネイルを表示した後に行っても良い。
また、本実施形態においては、付加情報の追記・編集時の拡張付加情報有無のフラグの書き換えにおいて、現在のフラグの状態に係わらず、ＡＶ Ｉｎｄｅｘとの比較も行わず、常に‘０’を記録するような機器が存在しても良い。
また、本実施形態においても、第１の実施形態で説明したとおり、拡張付加情報の有無を示す識別情報は、拡張付加情報の種別毎に設定してもよい。
また、本実施形態においても、拡張付加情報が再生可能な機器に関する情報を含む構成としても良い。
第１の実施形態に比べて、表示に関する手間が増えてはいるが、拡張付加情報の有無に関する情報がない場合に比べ、フラグが‘１’（存在しない）となっているエントリに関しては拡張付加情報の有無に関して対応するコンテンツファイルを読みに行く必要がないという重要な効果を奏する。
本実施形態のような構成にすることによって、付加情報の記録・編集時にＡＶ Ｉｎｄｅｘとコンテンツファイルの付加情報を比較し、拡張付加情報がコンテンツファイルに含まれるかどうかを調べるという処理を常に行わない機器があってもよく、実装の負担を増やしたくない機器との混在が可能になる。
なお、本発明のデータ記録方法は、ＡＶデータを含む複数のコンテンツのインデックス情報を記録媒体に記録するデータ記録方法であって、上記インデックス情報には、上記各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報を上記インデックス外に記録し、上記属性情報には上記拡張付加情報に関する情報を含む構成であってもよい。
また、上記拡張付加情報に関する情報が、上記拡張付加情報の有無に関する情報を含む構成であってもよい。さらに、上記拡張付加情報が、動画サムネイルデータであることが好ましい。
さらに、上記コンテンツは、上記拡張付加情報を含む構成であってもよい。また、上記拡張付加情報に関する情報が、上記拡張付加情報の種別毎の有無に関する情報を含む構成であってもよい。さらに、上記拡張付加情報に関する情報が、上記拡張付加情報を解釈可能な機器に関する情報を含む構成であってもよい。
また、本発明のデータ再生方法は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報の再生方法であって、上記拡張付加情報に関する情報に基づき各コンテンツの拡張付加情報の読み出しを制御する構成であってもよい。さらに、拡張付加情報の読み出しは、インデックス情報の読み出しの後に行うことが好ましい。
また、本発明のデータ再生方法は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報のデータ再生方法であって、上記拡張付加情報に関する情報を表示する構成であってもよい。
また、本発明のデータ記録装置は、ＡＶデータを含むコンテンツのインデックス情報を記録媒体に記録するデータ記録装置であって、上記インデックス情報に、上記各コンテンツの属性情報を格納する手段と、上記コンテンツに関する拡張付加情報を上記インデックス外に記録する手段と、上記属性情報には上記拡張付加情報に関する情報を格納する手段とを備える構成であってもよい。
また、本発明のデータ再生装置は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報のデータ再生装置であって、上記拡張付加情報に関する情報を基づき各コンテンツの拡張付加情報の読み出しを制御する手段を備える構成であってもよい。
さらに、本発明のデータ再生装置は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報のデータ再生装置であって、上記拡張付加情報に関する情報を表示する手段を備える構成であってもよい。
また、本発明のデータ記録媒体は、ＡＶデータを含む複数のコンテンツのインデックス情報を記録したデータ記録媒体であって、上記インデックス情報には、上記各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報を上記インデックス外に記録され、上記属性情報には上記拡張付加情報に関する情報を含む構成であってもよい。
また、本発明のプログラムは、ＡＶデータを含む複数のコンテンツのインデックス情報を記録媒体に記録するコンピュータプログラムであって、上記インデックス情報には、上記各コンテンツの属性情報を格納するステップと、上記コンテンツに関する拡張付加情報を上記インデックス外に記録するステップと、上記属性情報には上記拡張付加情報に関する情報を格納するステップとを有する構成であってもよい。
また、本発明のプログラムは、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際に、インデックス情報を再生するコンピュータプログラムであって、上記拡張付加情報に関する情報を基づき各コンテンツの拡張付加情報の読み出しを制御するステップを有する構成であってもよい。
また、本発明のプログラムは、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報を再生するコンピュータプログラムであって、上記拡張付加情報に関する情報を表示するステップを有する構成であってもよい。
また、本発明の記録媒体は、ＡＶデータを含む複数のコンテンツのインデックス情報を記録媒体に記録するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、上記インデックス情報には、上記各コンテンツの属性情報を格納するステップと、上記コンテンツに関する拡張付加情報を上記インデックス外に記録するステップと、上記属性情報には上記拡張付加情報に関する情報を格納するステップを有することを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体であってもよい。
また、本発明の記録媒体は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際に、インデックス情報を再生するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、上記拡張付加情報に関する情報を基づき各コンテンツの拡張付加情報の読み出しを制御するステップを有する構成であってもよい。
また、本発明の記録媒体は、ＡＶデータを含むコンテンツのインデックス情報が記録媒体に記録され、上記インデックス情報には各コンテンツの属性情報が含まれ、上記コンテンツに関する拡張付加情報が上記インデックス外に記録され、上記インデックス情報が上記拡張付加情報に関する情報を含む際のインデックス情報を再生するコンピュータが読み取り可能なプログラムが記録されている記録媒体であって、上記拡張付加情報に関する情報を表示するステップを有することを特徴とするコンピュータが読み取り可能なプログラムが記録されている記録媒体であってもよい。
上記構成によれば、拡張付加情報の有無を示すフラグを設けることによって、コンテンツにアクセスせずともインデックス表示画面で拡張付加情報の有無がわかり、所望の映像を検索する際にさらに使い勝手の良いものとなる。また、拡張付加情報はコンテンツファイル内に格納するため、多くの拡張付加情報があった場合でも、インデックス表示の体感レスポンスを落とさずに、より多くの情報をすばやく見ることが可能となる。
また、動画サムネイルの有無を示すフラグを設けることによって、インデックス表示の体感レスポンスを落とさずに、インデックス画面上で動画サムネイルの表示を行うことが可能となる。
尚、発明を実施するための最良の形態の項においてなした具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求の範囲内で、いろいろと変更して実施することができるものである。
【産業上の利用の可能性】
本発明の構成によれば、各コンテンツに直接アクセスしなくても、インデックス情報のみにアクセスすることによって、各コンテンツに拡張付加情報が付加されているか否かを識別情報に基づき把握することができる。これにより、本発明を、各コンテンツにおける拡張付加情報の有無をより簡易に確認することができるデータ記録方法、データ再生方法、データ記録装置、データ再生装置、データ記録媒体、プログラム、およびそのプログラムを格納した記録媒体に好適に用いることができる。
【図１】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２４】
【図２５】
【図２６】
【図２７】
【図２８】
【図２９】
【図３０】
【図３１】
【図３２】
【図３３】
【図３４】
【図３５】
【図３６】
【特許請求の範囲】
【請求項１】
ＡＶデータを含む複数のコンテンツのインデックス情報を、記録媒体に記録するデータ記録方法において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含むデータ記録方法。
【請求項２】
上記拡張付加情報は、動画サムネイルデータである請求の範囲第１項に記載のデータ記録方法。
【請求項３】
上記各コンテンツの所定領域に、上記拡張付加情報を含む請求の範囲第１項に記載のデータ記録方法。
【請求項４】
上記拡張付加情報を、上記各コンテンツを記録する記録媒体の領域と別の領域に記録する請求の範囲第１項に記載のデータ記録方法。
【請求項５】
上記識別情報を、上記拡張付加情報の種別毎に設定する請求の範囲第１項に記載のデータ記録方法。
【請求項６】
上記識別情報は、上記拡張付加情報を再生可能な機器に関する情報を含む請求の範囲第１項に記載のデータ記録方法。
【請求項７】
上記識別情報は、拡張付加情報が付加されていない状態と、拡張付加情報が付加されている、あるいは付加されているかどうか不明である状態とのどちらかを示す情報を含む請求の範囲第１項に記載のデータ記録方法。
【請求項８】
ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生方法において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、
上記識別情報に基づき、上記拡張付加情報の読み出しを制御するデータ再生方法。
【請求項９】
上記インデックス情報を読み出した後で、ユーザによる上記拡張付加情報の表示の指示前に、該拡張付加情報を読み出す請求の範囲第８項に記載のデータ記録方法。
【請求項１０】
ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生方法において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、
上記識別情報を表示するデータ再生方法。
【請求項１１】
ＡＶデータを含む複数のコンテンツのインデックス情報を、記録媒体に記録するデータ記録装置において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含むデータ記録装置。
【請求項１２】
ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生装置において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、
上記識別情報に基づき、上記拡張付加情報の読み出しを制御する制御手段を備えているデータ再生装置。
【請求項１３】
ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生装置において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、
上記識別情報を表示する表示手段を備えているデータ再生装置。
【請求項１４】
ＡＶデータを含む複数のコンテンツのインデックス情報が記録されたデータ記録媒体において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含むデータ記録媒体。
【請求項１５】
請求の範囲第１項から第７項のいずれか１項に記載のデータ記録方法をコンピュータに実行させるプログラム。
【請求項１６】
請求の範囲第８項から第１０項のいずれか１項に記載のデータ再生方法をコンピュータに実行させるプログラム。
【請求項１７】
請求の範囲第１５項または第１６項に記載のプログラムを格納したコンピュータ読み取り可能な記録媒体。
【請求項１】
ＡＶデータを含む複数のコンテンツのインデックス情報を、記録媒体に記録するデータ記録方法において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含むデータ記録方法。
【請求項２】
上記拡張付加情報は、動画サムネイルデータである請求の範囲第１項に記載のデータ記録方法。
【請求項３】
上記各コンテンツの所定領域に、上記拡張付加情報を含む請求の範囲第１項に記載のデータ記録方法。
【請求項４】
上記拡張付加情報を、上記各コンテンツを記録する記録媒体の領域と別の領域に記録する請求の範囲第１項に記載のデータ記録方法。
【請求項５】
上記識別情報を、上記拡張付加情報の種別毎に設定する請求の範囲第１項に記載のデータ記録方法。
【請求項６】
上記識別情報は、上記拡張付加情報を再生可能な機器に関する情報を含む請求の範囲第１項に記載のデータ記録方法。
【請求項７】
上記識別情報は、拡張付加情報が付加されていない状態と、拡張付加情報が付加されている、あるいは付加されているかどうか不明である状態とのどちらかを示す情報を含む請求の範囲第１項に記載のデータ記録方法。
【請求項８】
ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生方法において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、
上記識別情報に基づき、上記拡張付加情報の読み出しを制御するデータ再生方法。
【請求項９】
上記インデックス情報を読み出した後で、ユーザによる上記拡張付加情報の表示の指示前に、該拡張付加情報を読み出す請求の範囲第８項に記載のデータ記録方法。
【請求項１０】
ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生方法において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、
上記識別情報を表示するデータ再生方法。
【請求項１１】
ＡＶデータを含む複数のコンテンツのインデックス情報を、記録媒体に記録するデータ記録装置において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含むデータ記録装置。
【請求項１２】
ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生装置において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、
上記識別情報に基づき、上記拡張付加情報の読み出しを制御する制御手段を備えているデータ再生装置。
【請求項１３】
ＡＶデータを含む複数のコンテンツのインデックス情報を再生するデータ再生装置において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含み、
上記識別情報を表示する表示手段を備えているデータ再生装置。
【請求項１４】
ＡＶデータを含む複数のコンテンツのインデックス情報が記録されたデータ記録媒体において、
上記インデックス情報は、上記各コンテンツに対して拡張付加情報が付加されているか否かを表す識別情報を含むデータ記録媒体。
【請求項１５】
請求の範囲第１項から第７項のいずれか１項に記載のデータ記録方法をコンピュータに実行させるプログラム。
【請求項１６】
請求の範囲第８項から第１０項のいずれか１項に記載のデータ再生方法をコンピュータに実行させるプログラム。
【請求項１７】
請求の範囲第１５項または第１６項に記載のプログラムを格納したコンピュータ読み取り可能な記録媒体。
【国際公開番号】ＷＯ２００４／０２８１５７
【国際公開日】平成１６年４月１日（２００４．４．１）
【発行日】平成１８年１月１９日（２００６．１．１９）
【国際特許分類】
【出願番号】特願２００４−５３７６０２（Ｐ２００４−５３７６０２）
【国際出願番号】ＰＣＴ／ＪＰ２００３／０１１９１０
【国際出願日】平成１５年９月１８日（２００３．９．１８）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【国際公開日】平成１６年４月１日（２００４．４．１）
【発行日】平成１８年１月１９日（２００６．１．１９）
【国際特許分類】
【国際出願番号】ＰＣＴ／ＪＰ２００３／０１１９１０
【国際出願日】平成１５年９月１８日（２００３．９．１８）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]