JP3847751B2 - データ記録方法、データ記録装置、データ記録媒体、データ再生方法及びデータ再生装置 - Google Patents

Description

技術分野
本発明は、ハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して、映像データ、音声データを記録するデータ記録方法、データ記録装置、データ記録媒体、データ再生方法、データ再生装置に関するものである。
背景技術
ディスクメディアを用いたビデオのディジタル記録再生装置（以下、ビデオディスクレコーダと呼ぶ）が普及しつつある。その記録フォーマットには、ＰＣ（パーソナル・コンピュータ）との親和性を高めるため、ＰＣで広く使われている、例えばＱｕｉｃｋＴｉｍｅファイルフォーマットやＡＶＩ（Ａｕｄｉｏ Ｖｉｄｅｏ Ｉｎｔｅｒｌｅａｖｅ）ファイルフォーマットを用いることがよく行われる。
このようなＰＣ用ファイルフォーマットを用いた場合のディスク中でのコンテンツの管理方法については、日本国公開特許公報特開２００１−８４７０５公報（２００１年３月３０日公開）に開示されている。以下、図６０を用いてその概要を説明する。ディスク３０５中のファイル３０１〜３０３は、録画した各シーンあるいはショットに対応しそれぞれ１個のＱｕｉｃｋＴｉｍｅファイル（以下、ＱｕｉｃｋＴｉｍｅムービーファイルと呼ぶ）である。
インデックスファイル３００は、ディスク３０５中のデータの目次的な情報を格納するファイルであり、各ＱｕｉｃｋＴｉｍｅムービーファイル毎にエントリが存在し、各エントリには対応するシーンの代表画面の縮小画像データ３１１〜３１３とシーンが含まれるファイルのファイル名が格納される。
ユーザにインデックス画面を提示する際は、各エントリの縮小画像データ３１１〜３１３をデコードした縮小画像３２１〜３２３をコンテンツ選択画面３０７に表示する。ユーザはコンテンツ選択画面３０７に表示されている複数の縮小画像の中から再生や編集をしたいファイルを選択する。例えば、ユーザが縮小画像３２３を選択し、再生を指示したら、縮小画像３２３に対応するコンテンツの含まれるファイルのファイル名であるファイル３０３を取得し、ファイル３０３の再生を開始する。
インデックスファイル３００にディスク３０５中のすべてのコンテンツに関してそれを格納したファイルへのポインタと縮小画像データが含まれているため、インデックスファイル３００をディスク３０５から読み出すだけで、コンテンツ選択画面３０７の表示が可能であり、Ｉｎｄｅｘ画面表示に要する時間が少なくて済むという利点がある。コンテンツ選択画面３０７は頻繁に表示するものであるため、その表示時間の削減は全体的な体感レスポンス向上に大きく寄与する。
近年、追記型の光ディスクの利用が急激に増加している。ＣＤ−Ｒはその代表的な例である。また、ＤＶＤ−Ｒも急速に価格が低下しており、身近なものになってきている。上記のインデックスファイルをこれらの追記型の光ディスクに適用した場合、以下のような問題がある。
インデックスファイルは使用が進むにつれ、そのサイズが大きくなる性質のファイルである。追記型のディスクでは、一度記録した領域に再度記録することができない。そのようなメディアにおいて、インデックスファイルのように、使用が進むにつれ、そのサイズが大きくなるファイルを扱う場合、記憶容量を無駄なく使うことが難しい。例えば、インデックスファイルに対しエントリの追加、削除、変更等が発生するたびに新規のインデックスファイルを追記して行った場合、大量の無駄が発生する。
本発明は、上記課題を鑑みてなされたものであり、追記型の記録媒体において記憶容量の無駄を削減することが可能なデータ記録方法を提供することを目的とする。
発明の開示
本発明のデータ記録方法は、記録媒体に、第１のデータと第２のデータと第３のデータを記録する記録方法であって、前記第１のデータは第４のデータを含み、前記第３のデータは、前記第４のデータに関する情報を含んでいる。
本発明のデータ記録方法では、前記第２のデータが、前記第４のデータと同一のデータを０個以上持っていてもよい。
本発明のデータ記録方法では、同一のデータを含むかどうかは、第４のデータの属性に基づくことができる。
本発明のデータ記録方法では、前記第４のデータの属性がデータ量であってもよい。
本発明のデータ記録方法では、前記第４のデータの属性が階層情報であってもよい。
本発明のデータ記録方法では、前記第４のデータの属性が優先度であってもよい。
本発明のデータ記録方法では、前記第４のデータの属性が、前記第４に関連するデータを再生した時刻であってもよい。
本発明のデータ記録方法では、前記第４のデータの属性を前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記第１のデータと前記第２のデータを１個のファイルとして管理し、前記第４のデータを含む前記第２のデータを整数個の記録ユニットで構成してもよい。
本発明のデータ記録方法では、前記第４のデータを含む前記第２のデータを整数個の記録ユニットで構成するために無意味データを挿入してもよい。
本発明のデータ記録方法では、前記無意味データを無効化するためのデータを前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記無意味データ挿入位置は前記無意味データを挿入可能な位置であってもよい。
本発明のデータ記録方法では、第１のデータを前記第４のデータの近傍の前方と後方を別のファイルとして管理し、前記ファイル間の関連情報を前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記第１のデータが、領域確保用データを含んでいてもよい。
本発明のデータ記録方法では、前記第１のデータと前記第２のデータを別のファイルに記録し、前記ファイル間の読み出し制御情報を前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記第１のデータと前記第２のデータを別のファイルとして管理し、前記ファイル間の関連情報を前記記録媒体に記録してもよい。
本発明のデータ記録方法では、前記関連情報を前記ファイル名で表してもよい。
本発明のデータ記録方法では、前記第３のデータが有効な前記第４のデータの含まれるファイル名と前記ファイル内での位置情報であってもよい。
本発明のデータ記録方法では、前記第３のデータが前記第４のデータを無効化する情報であってもよい。
本発明のデータ記録方法では、前記第３のデータと前記第４のデータを別のファイルに記録してもよい。
本発明のデータ記録方法では、前記第１のデータと前記第２のデータを同一のファイルとして管理してもよい。
本発明のデータ記録方法では、前記第４のデータの先頭位置が記録ユニット境界になるように記録してもよい。
本発明のデータ記録方法では、前記第２のデータを整数個の記録ユニットで構成してもよい。
本発明のデータ記録方法では、前記第３のデータが有効な第４のデータの前記ファイル内での位置情報であってもよい。
本発明のデータ記録方法では、前記第３のデータが前記第４のデータを無効化する情報であってもよい。
本発明のデータ記録方法では、前記第３のデータを前記記録媒体上の近傍に記録してもよい。
本発明のデータ記録方法では、第５のデータを前記記録媒体に記録し、第４のデータは、第５のデータに関する情報であってもよい。
本発明のデータ記録方法では、前記第５のデータに関する情報が、前記第５のデータの代表画像データ、代表音データ、タイトルデータ、属性データの少なくとも１であってもよい。
本発明のデータ記録方法では、前記記録媒体が追記型であってもよい。
本発明のデータ記録方法では、前記第３のデータを前回追記終了位置を示す情報の近傍に記録してもよい。
本発明のデータ記録方法では、前記第２のデータが前記第１のデータの追加データであってもよい。
本発明のデータ記録装置は、記録媒体に、第１のデータと第２のデータと第３のデータを記録する記録手段を備えるデータ記録装置であって、前記第１のデータは第４のデータを含み、前記第３のデータは、前記第４のデータに関する情報を含んでいる。
本発明のデータ記録媒体は、第１のデータと第２のデータと第３のデータが記録された記録媒体であって、前記第１のデータは第４のデータを含み、前記第３のデータは、前記第４のデータに関する情報を含んでいる。
本発明のデータ再生方法は、記録媒体上に、第１のデータと第２のデータと第３のデータが記録され、前記第１のデータは第４のデータを含み、前記第３のデータは、前記第４のデータに関する情報である記録媒体のデータ再生方法であって、再生制御を前記第３のデータに基づいて行う。
本発明のデータ再生装置は、記録媒体上に、第１のデータと第２のデータと第３のデータが記録され、前記第１のデータは第４のデータを含み、前記第３のデータは、前記第４のデータに関する情報である記録媒体のデータ再生装置であって、前記第３のデータに基づく制御手段を備えている。
本発明によれば、追記データを記録する際に、既存データの有効／無効を管理する情報を記録することによって、既存データの再利用が可能となり、記録容量の無駄を削減できる。
また、本発明によれば、追記データを記録する際に、既存データの属性に応じて既存データと同一データを記録することによって、特定の属性を持つデータを高速に読み出すことが可能となり、ユーザへのレスポンスを向上させることができる。
本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。
発明を実施するための最良の形態
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行っていく。
＜システム構成＞
図１は本発明において共通に用いる、ビデオディスクレコーダの構成図である。この装置は、図１に示すように、バス１００、ホストＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ユーザインタフェース１０４、システムクロック１０５、光ディスク１０６、ピックアップ１０７、ＥＣＣ（Ｅｒｒｏｒ Ｃｏｒｒｅｃｔｉｎｇ Ｃｏｄｉｎｇ）デコーダ１０８、ＥＣＣエンコーダ１０９、再生用バッファ１１０、記録／アフレコ用バッファ１１１、デマルチプレクサ１１２、マルチプレクサ１１３、多重化用バッファ１１４、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、および図示しないカメラ、マイク、スピーカ、ディスプレイ等で構成される。
なお、図１のビデオディスクレコーダが請求の範囲における「データ記録装置（記録装置）」または「データ再生装置（再生装置）」に相当し、光ディスク１００が請求の範囲における「データ記録媒体（記録媒体）」に相当する。
ホストＣＰＵ１０１は、バス１００を通じてデマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、また、バス１００との接続は図示していないが、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８の制御を行う。
再生時に、光ディスク１０６からピックアップ１０７を通じて読み出されたデータは、ＥＣＣデコーダ１０８によって誤り訂正され、再生用バッファ１１０に一旦蓄えられる。ホストＣＰＵ１０１は、再生中のデータに関する管理情報に基づき、オーディオデコーダ１１５、ビデオデコーダ１１６からのデータ送信要求に従い、再生用バッファ１１０中のデータをその種別によって適当なデコーダに振り分けるようデマルチプレクサ１１２に指示を与える。
なお、ピックアップ１０７、ＥＣＣデコーダ１０８、再生用バッファ１１０、デマルチプレクサ１１２、オーディオデコーダ１１５、ビデオデコーダ１１６、ホストＣＰＵ１０１、およびＲＡＭ１０２により、請求の範囲における「再生手段」が構成される。
一方、記録時に、オーディオエンコーダ１１７とビデオエンコーダ１１８によって圧縮符号化されたデータは、多重化用バッファ１１４に一旦送られ、マルチプレクサ１１３によってＡＶ多重化され、記録／アフレコ用バッファ１１１に送られる。記録／アフレコ用バッファ１１１中のデータは、ＥＣＣエンコーダ１０９によって誤り訂正符号を付加され、ピックアップ１０７を通じて光ディスク１０６に記録される。
なお、ピックアップ１０７、ＥＣＣエンコーダ１０９、記録／アフレコ用バッファ１１１、マルチプレクサ１１３、多重化用バッファ１１４、オーディオエンコーダ１１７、ビデオエンコーダ１１８、ホストＣＰＵ１０１、およびＲＡＭ１０２により、請求の範囲における「記録手段」が構成される。
オーディオデータの符号化方式にはＭＰＥＧ−１ Ｌａｙｅｒ−ＩＩを、ビデオデータの符号化方式にはＭＰＥＧ−２をそれぞれ用いる。光ディスク１０６は、追記型の光ディスクであるＤＶＤ−Ｒとする。２０４８ｂｙｔｅを１セクタとし、誤り訂正のため１６セクタでＥＣＣブロックを構成する。
＜ファイルフォーマット＞
本発明でＡＶストリーム管理のためのフォーマットとして用いる、ＱｕｉｃｋＴｉｍｅファイルフォーマットについて説明する。ＱｕｉｃｋＴｉｍｅファイルフォーマットとは、Ａｐｐｌｅ社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。
ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータとも呼ぶ）と管理情報とで構成される。両者を合わせてここでは、ＱｕｉｃｋＴｉｍｅムービー（略してムービー）と呼ぶ。両者は同じファイル中に存在しても、別々のファイルに存在しても良い。
管理情報とメディアデータとが同じファイル中に存在する場合は、図２（ａ）に示すような構成をとる。各種情報はａｔｏｍという共通の構造に格納される。管理情報はＭｏｖｉｅ ａｔｏｍという構造に格納され、メディアデータはＭｏｖｉｅ ｄａｔａ ａｔｏｍという構造に格納される。尚、Ｍｏｖｉｅ ａｔｏｍ中の管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。
一方、管理情報とメディアデータを別々のファイルに格納した場合は、図２（ｂ）に示すような構成をとる。管理情報はＭｏｖｉｅ ａｔｏｍという構造に格納されるが、メディアデータはａｔｏｍには格納される必要はない。このとき、Ｍｏｖｉｅ ａｔｏｍはメディアデータを格納したファイルを「外部参照」している、という。
外部参照は、図２（ｃ）に示すように、複数のＡＶストリームファイルに対して行うことが可能であり、この仕組みにより、ＡＶストリーム自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」「非破壊編集」が可能になる。
それでは、図３乃至図１２を用いて、ＱｕｉｃｋＴｉｍｅの管理情報のフォーマットについて説明する。まず、共通の情報格納フォーマットであるａｔｏｍについて説明する。ａｔｏｍの先頭には、そのａｔｏｍのサイズであるＡｔｏｍ ｓｉｚｅ、そのａｔｏｍの種別情報であるＴｙｐｅが必ず存在する。Ｔｙｐｅは４文字で区別され、例えばＭｏｖｉｅ ａｔｏｍでは’ｍｏｏｖ’、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍでは’ｍｄａｔ’となっている。ａｔｏｍの先頭にあるＡｔｏｍ ｓｉｚｅとＴｙｐｅの列をここでは、ａｔｏｍ ｈｅａｄｅｒと呼ぶ。
各ａｔｏｍは別のａｔｏｍを含むことができる。すなわち、ａｔｏｍ間には階層構造がある。Ｍｏｖｉｅ ａｔｏｍの構成を図３に示す。Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍは、そのＭｏｖｉｅ ａｔｏｍが管理するムービーの全体的な属性を管理する。Ｔｒａｃｋ ａｔｏｍは、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。Ｕｓｅｒ ｄａｔａ ａｔｏｍは、独自に定義可能なａｔｏｍである。
Ｔｒａｃｋ ａｔｏｍの構成を図４に示す。Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、そのトラックの全体的な属性を管理する。Ｅｄｉｔ ａｔｏｍは、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。Ｔｒａｃｋ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、別のトラックとの関係を管理する。Ｍｅｄｉａ ａｔｏｍは、実際のビデオやオーディオといったデータを管理する。
Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を図５に示す。ここでは、後での説明に必要なもののみについて説明する。ｆｌａｇｓは属性を示すフラグの集合である。代表的なものとして、Ｔｒａｃｋ ｅｎａｂｌｅｄフラグがあり、このフラグが１であれば、そのトラックは再生され、０であれば再生されない。ｌａｙｅｒはそのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、ｌａｙｅｒの値が小さいトラックほど画像が前面に表示される。
Ｍｅｄｉａ ａｔｏｍの構成を図６に示す。Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍは、そのＭｅｄｉａ ａｔｏｍの管理するメディアデータに関する全体的な属性等を管理する。Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、メディアデータをどのデコーダでデコードするかを示す情報を格納する。Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、ビデオやオーディオ等メディア固有の属性情報を管理する。
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍの構成を図７に示す。Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ｈｅａｄｅｒ ａｔｏｍは、ビデオやオーディオ等メディア固有の属性情報を管理する。Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍの項で説明した通りである。Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、そのＱｕｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名前を管理するａｔｏｍであるＤａｔａ ｒｅｆｅｒｅｎｃｅ ａｔｏｍを含む。Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、データのサイズや再生時間等を管理している。
次に、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍについて説明するが、その前に、ＱｕｉｃｋＴｉｍｅにおけるデータの管理方法について、図８を用いて説明する。ＱｕｉｃｋＴｉｍｅでは、データの最小単位（例えばビデオフレーム）をサンプルと呼ぶ。個々のトラック毎に、サンプルには再生時間順に１から番号（サンプル番号）がついている。
また、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。また、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンクと呼ぶ。チャンクにも再生時間順に、１から番号がついている。
さらに、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき、任意の時間に対応するサンプルの位置を求めることが可能となっている。
Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構成を図９に示す。Ｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍは、個々のチャンクのデータフォーマット（Ｄａｔａ ｆｏｒｍａｔ）やサンプルが格納されているファイルのチャンクのＩｎｄｅｘ等を管理する。Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルの再生時間を管理する。
Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルのうち、デコード開始可能なサンプルを管理する。Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋ ａｔｏｍは、個々のチャンクに含まれるサンプル数を管理する。Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍは、個々のサンプルのサイズを管理する。Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍは、個々のチャンクのファイル先頭からのアドレスを管理する。
Ｅｄｉｔ ａｔｏｍは、図１０に示すように、１個のＥｄｉｔ ｌｉｓｔ ａｔｏｍを含む。Ｅｄｉｔ ｌｉｓｔ ａｔｏｍはＮｕｍｂｅｒ ｏｆ ｅｎｔｒｉｅｓで指定される個数分の、Ｔｒａｃｋ ｄｕｒａｔｉｏｎ、Ｍｅｄｉａ ｔｉｍｅ、Ｍｅｄｉａ ｒａｔｅの値の組（エントリ）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
Ｔｒａｃｋ ｄｕｒａｔｉｏｎはそのエントリが管理する区間のトラック上での再生時間、Ｍｅｄｉａ ｔｉｍｅはそのエントリが管理する区間の先頭に対応するメディアデータ上での位置、Ｍｅｄｉａ ｒａｔｅはそのエントリが管理する区間の再生スピードを表す。尚、Ｍｅｄｉａ ｔｉｍｅが−１の場合は、そのエントリのＴｒａｃｋ ｄｕｒａｔｉｏｎ分、そのトラックでのサンプルの再生を停止する。この区間のことをｅｍｐｔｙ ｅｄｉｔと呼ぶ。
図１１（ａ）〜（ｃ）にＥｄｉｔ ｌｉｓｔの使用例を示す。ここでは、Ｅｄｉｔ ｌｉｓｔ ａｔｏｍの内容が図１１（ａ）に示す内容であり、さらにサンプルの構成が図１１（ｂ）であったとする。尚、ここではｉ番目のエントリのＴｒａｃｋ ｄｕｒａｔｉｏｎをＤ（ｉ）、Ｍｅｄｉａ ｔｉｍｅをＴ（ｉ）、Ｍｅｄｉａ ｒａｔｅをＲ（ｉ）とする。このとき、実際のサンプルの再生は、図１１（ｃ）に示す順に行われる。このことについて簡単に説明する。
まず、エントリ＃１はＴｒａｃｋ ｄｕｒａｔｉｏｎが１３０００、Ｍｅｄｉａ ｔｉｍｅが２００００、Ｍｅｄｉａ ｒａｔｅが１であるため、そのトラックの先頭から１３０００の区間はサンプル中の時刻２００００から３３０００の区間を再生する。次に、エントリ＃２はＴｒａｃｋ ｄｕｒａｔｉｏｎが５０００、Ｍｅｄｉａ ｔｉｍｅが−１であるため、トラック中の時刻１３０００から１８０００の区間、何も再生を行わない。
最後に、エントリ＃３はＴｒａｃｋ ｄｕｒａｔｉｏｎが１００００、Ｍｅｄｉａ ｔｉｍｅが０、Ｍｅｄｉａ ｒａｔｅが１であるため、トラック中の時刻１８０００から２８０００の区間において、サンプル中の時刻０から１００００の区間を再生する。
図１２にＵｓｅｒ ｄａｔａ ａｔｏｍの構成を示す。このａｔｏｍには、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自の情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリはＳｉｚｅとＴｙｐｅとＵｓｅｒ ｄａｔａで構成される。Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報、Ｕｓｅｒ ｄａｔａは実際のデータを表す。
次に、録画中の電源遮断等に対応するために導入された概念であるＦｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅについて説明する。Ｆｒａｇｍｅｎｔｅｄ ｍｏｖｉｅは、ＱｕｉｃｋＴｉｍｅフォーマットの１アプリケーションであるＭｏｔｉｏｎ ＪＰＥＧ２０００で導入された概念であり、上述のＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍに相当する情報を、部分的なＡＶストリーム毎に管理することが可能となっている。Ｍｏｔｉｏｎ ＪＰＥＧ２０００では、ａｔｏｍの代わりにｂｏｘという用語を用いているが、ここでは統一のためにａｔｏｍに置き換えて説明する。
Ｆｒａｇｍｅｎｔｅｄ ｍｏｖｉｅを導入したＱｕｉｃｋＴｉｍｅファイルの全体構成を図１３に示す。先頭に、そのファイル全体に共通する情報を管理するＭｏｖｉｅ ａｔｏｍが配置され、その後に、部分ＡＶストリームデータを格納するＭｏｖｉｅ ｄａｔａ ａｔｏｍと、その部分ＡＶストリームデータを構成するサンプルのアドレスやサイズ、再生時間等を管理するＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍとが交互に配置される。尚、ＡＶストリームデータは、通常のＱｕｉｃｋＴｉｍｅファイルと同様、別ファイルに存在しても構わない。
録画時にはこの順番で記録を行なっていくことにより、録画時の電源切断による被害を最小限に防ぐことが可能となっている。Ｍｏｖｉｅ ａｔｏｍには、そのＱｕｉｃｋＴｉｍｅムービーがＦｒａｇｍｅｎｔｅｄ ｍｏｖｉｅであることを示すためのＭｏｖｉｅ ｅｘｔｅｎｄｓ ａｔｏｍが含まれる。Ｍｏｖｉｅ ｅｘｔｅｎｄｓ ａｔｏｍには、そのムービーに含まれる各トラックに関するデフォルト値が格納される。
また、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍには、そのＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍが管理する部分ＡＶストリームに関する管理情報が含まれている。管理情報には、その管理する部分ＡＶストリーム全体に関する情報を格納するＭｏｖｉｅ ｆｒａｇｍｅｎｔ ｈｅａｄｅｒ ａｔｏｍと、部分ＡＶストリーム中の各トラックに関する情報を格納するＴｒａｃｋ ｆｒａｇｍｅｎｔ ａｔｏｍとがある。
Ｔｒａｃｋ ｆｒａｇｍｅｎｔ ａｔｏｍは、それが管理するトラックに属する部分ＡＶストリームに関する情報を格納するＴｒａｃｋ ｆｒａｇｍｅｎｔ ｈｅａｄｅｒ ａｔｏｍと、そのトラックに属する部分ＡＶストリームを構成する論理的な連続領域（Ｔｒａｃｋ ｒｕｎと呼ばれる）をそれぞれ管理するＴｒａｃｋ ｆｒａｇｍｅｎｔ ｒｕｎ ａｔｏｍとを含む。以下に、各ａｔｏｍについて詳しく説明する。
Ｍｏｖｉｅ ｅｘｔｅｎｄｓ ａｔｏｍの構成を図１４に示す。Ｍｏｖｉｅ ｅｘｔｅｎｄｓ ａｔｏｍは、前述のように、このａｔｏｍを含むＱｕｉｃｋＴｉｍｅムービーがＦｒａｇｍｅｎｔｅｄ ｍｏｖｉｅであることを示す役割を持つ。
Ｔｒａｃｋ ｅｘｔｅｎｄｓ ａｔｏｍの構成を図１５に示す。Ｔｒａｃｋ ｅｘｔｅｎｄｓ ａｔｏｍは、このＱｕｉｃｋＴｉｍｅムービーに含まれる各トラックのサンプルのデフォルト値を設定するために存在する。ｔｒａｃｋ ＩＤはＭｏｖｉｅ ａｔｏｍ中で定義されているトラックのｔｒａｃｋ ＩＤを参照する。ｄｅｆａｕｌｔ−ｓａｍｐｌｅ−で始まるフィールドは、このａｔｏｍで管理されるｔｒａｃｋ ｆｒａｇｍｅｎｔのデフォルト値を設定する。
Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍの構成を図１６に示す。録画中に逐次記録される管理情報はこのａｔｏｍである。このａｔｏｍは、前述のとおり、このａｔｏｍの管理するＭｏｖｉｅ ｆｒａｇｍｅｎｔに関する実際の情報を格納するａｔｏｍであるＭｏｖｉｅ ｆｒａｇｍｅｎｔ ｈｅａｄｅｒ ａｔｏｍやＴｒａｃｋ ｆｒａｇｍｅｎｔ ａｔｏｍを含む。
Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ｈｅａｄｅｒ ａｔｏｍの構成を図１７に示す。このａｔｏｍに格納されている主な情報はｓｅｑｕｅｎｃｅ−ｎｕｍｂｅｒである。ｓｅｑｕｅｎｃｅ−ｎｕｍｂｅｒは、このａｔｏｍが含まれるＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍが管理するＭｏｖｉｅ ｆｒａｇｍｅｎｔの先頭からの順番を表す。
Ｔｒａｃｋ ｆｒａｇｍｅｎｔ ａｔｏｍの構成を図１８に示す。Ｔｒａｃｋ ｆｒａｇｍｅｎｔ ａｔｏｍは、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔに含まれる特定のトラックのサンプルに関する管理情報であるＴｒａｃｋ ｆｒａｇｍｅｎｔ ｈｅａｄｅｒ ａｔｏｍやＴｒａｃｋ ｆｒａｇｍｅｎｔ ｒｕｎ ａｔｏｍを格納する。
Ｔｒａｃｋ ｆｒａｇｍｅｎｔ ｈｅａｄｅｒ ａｔｏｍの構成を図１９に示す。このａｔｏｍは、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔに含まれる特定のトラックのサンプルに関するデフォルト値等を格納する。ｔｒａｃｋ−ＩＤは、Ｍｏｖｉｅ ａｔｏｍ中で定義されているトラックのｔｒａｃｋ ＩＤとの対応を示す。ｓａｍｐｌｅ−ｄｅｓｃｒｉｐｔｉｏｎ−ｉｎｄｅｘは、このａｔｏｍが管理するサンプルの参照するｓａｍｐｌｅ ｄｅｓｃｒｉｐｔｉｏｎ ｔａｂｌｅのインデックス番号、ｄｅｆａｕｌｔ−ｓａｍｐｌｅで始まるフィールドは、それぞれこのａｔｏｍが管理するサンプルのデフォルト値である。
Ｔｒａｃｋ ｆｒａｇｍｅｎｔ ｒｕｎ ａｔｏｍの構成を図２０に示す。このａｔｏｍは、Ｔｒａｃｋ ｒｕｎと呼ばれる、このａｔｏｍの管理する連続領域や個々のサンプルの管理情報を格納する。ｓａｍｐｌｅ−ｃｏｕｎｔはＴｒａｃｋ ｒｕｎに含まれるサンプルの個数を示す。ｄａｔａ−ｏｆｆｓｅｔはｂａｓｅ−ｄａｔａ−ｏｆｆｓｅｔからのＴｒａｃｋ ｒｕｎのオフセット値を示す。ｓａｍｐｌｅ−で始まるフィールドはこのａｔｏｍが管理するサンプルの再生時間等の値を格納する。ただし、上述のデフォルト値と同じであれば、省略してデータサイズを縮小することが可能となっている。
＜ＡＶストリームの形態＞
本発明において共通に用いられるＡＶストリームの構成について、図２１及び図２２を用いて説明する。ＡＶストリームは整数個のＣｏｎｔｉｎｕｏｕｓ Ｕｎｉｔ（ＣＵ）で構成される。ＣＵはディスク上で連続的に記録する単位である。ＣＵの長さは、ＡＶストリームを構成するＣＵをどのようにディスク上に配置してもシームレス再生（再生中に画像や音声が途切れないで再生できること）やリアルタイムアフレコ（アフレコ対象のビデオをシームレス再生しながらオーディオを記録すること）が保証されるように設定される。この設定方法については後述する。
ＣＵは、整数個のＶｉｄｅｏ Ｕｎｉｔ（ＶＵ）で構成される。ＶＵは単独再生可能な単位であり、そのことから再生の際のエントリ・ポイントとなり得る。
ＶＵ構成を図２２に示す。ＶＵは、１秒程度のビデオデータを格納した整数個のＧＯＰ（グループ・オブ・ピクチャ）と、それらと同じ時間に再生されるメインオーディオデータを格納した整数個のＡＡＵ（オーディオ・アクセス・ユニット）とから構成される。
尚、ＧＯＰは、ＭＰＥＧ−２ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。ＡＡＵはＭＰＥＧ−１ Ｌａｙｅｒ−ＩＩ規格における音声圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数が４８ｋＨｚの場合、ＡＡＵあたりの再生時間は０．０２４秒となる。ＶＵ中では、ＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ、ＧＯＰの順に配置する。
また、ＶＵ単位で独立再生を可能とするために、ＶＵ中のビデオデータの先頭にはＳｅｑｕｅｎｃｅ Ｈｅａｄｅｒ（ＳＨ）を置く。ＶＵの再生時間は、ＶＵに含まれるビデオフレーム数にビデオフレーム周期をかけたものと定義する。
＜ＡＶストリーム管理方法＞
ＡＶストリームの管理方法は、前述のＱｕｉｃｋＴｉｍｅファイルフォーマットをベースにしている。図２３にＡＶストリーム管理形態を示す。ビデオトラックは、１ビデオフレームを１サンプル、ＶＵ中のビデオの塊を１チャンクとして管理する。メインオーディオトラックは、ＡＡＵを１サンプル、ＶＵ中のオーディオの塊を１チャンクとして管理する。
＜ＣＵ単位決定方法＞
次に、ＣＵ単位決定方法について説明する。この決定方法では、基準となるデバイス（リファレンス・デバイス・モデル）を想定し、その上でシームレス再生が破綻しないように連続記録単位を決める。
それではまず、リファレンス・デバイス・モデルについて、図２４を用いて説明する。リファレンス・デバイス・モデルは１個のピックアップとそれにつながるＥＣＣエンコーダ・デコーダ５０１、トラックバッファ５０２、デマルチプレクサ５０３、アフレコ用バッファ５０４、オーディオエンコーダ５０９、ビデオバッファ５０５、オーディオバッファ５０６、ビデオデコーダ５０７、オーディオデコーダ５０８とによって構成される。
本モデルにおけるシームレス再生は、ＶＵのデコード開始時にトラックバッファ５０２上に少なくとも１個ＶＵが存在すれば保証されるものとする。オーディオフレームデータのＥＣＣエンコーダ５０１へのデータの入力速度およびＥＣＣデコーダ５０１からデータの出力速度はＲｓとする。
また、アクセスによる読み出し、記録の停止する最大期間をＴａとする。さらに、短いアクセス（１００トラック程度）に要する時間をＴｋとする。なお、これら期間には、シーク時間、回転待ち時間、アクセス後に最初にディスクから読み出したデータがＥＣＣから出力されるまでの時間が含まれる。本実施形態では、Ｒｓ＝２０Ｍｂｐｓ、Ｔａ＝１秒、Ｔｋ＝０．２秒とする。
前記リファレンス・デバイス・モデルにおいて再生を行った場合、次のような条件を満たせば、トラックバッファ５０２のアンダーフローがないことが保証できる。
条件を示す前にまず、記号の定義を行う。ＡＶストリームを構成するｉ番目の連続領域をＣ＃ｉとし、Ｃ＃ｉ中に含まれる再生時間をＴｃ（ｉ）とする。Ｔｃ（ｉ）はＣ＃ｉ中に先頭が含まれているＶＵの再生時間の合計とする。また、Ｃ＃ｉからＣ＃ｉ＋１へのアクセス時間をＴａとする。
また、再生時間Ｔｃ（ｉ）分のＶＵ読み出し時間をＴｒ（ｉ）とする。このとき、トラックバッファ５０２をアンダーフローさせない条件とは、分断ジャンプを含めた最大読み出し時間をＴｒ（ｉ）としたとき、任意のＣ＃ｉにおいて、
Ｔｃ（ｉ）≧Ｔｒ（ｉ）＋Ｔａ・・・＜式１＞
が成立することである。
なぜなら、この式は、シームレス再生の十分条件である、

を満たす十分条件であるためである。
＜式１＞中のＴｒ（ｉ）に、Ｔｒ（ｉ）＝Ｔｃ（ｉ）×（Ｒｖ＋Ｒａ）／Ｒｓを代入して、Ｔｃ（ｉ）で解くとシームレス再生を保証可能なＴｃ（ｉ）の条件
Ｔｃ（ｉ）≧（Ｔａ×Ｒｓ）／（Ｒｓ−Ｒｖ−Ｒａ）・・・＜式２＞
が得られる。
つまり、各連続領域に先頭の含まれるＶＵの合計が上式を満たすようにすれば、シームレス再生を保証可能である。このとき、各連続領域には合計の再生時間が上式を満たす完全なＶＵ群を含むように制限しても良い。
自動分割ムービーファイルでも＜式２＞を満たす必要がある。ただし、先頭の自動分割ムービーの最初のＣＵおよび末尾の自動分割ムービーの最後のＣＵは＜式２＞を満たさなくてもよい。なぜなら、先頭については記録媒体からのデータ読み出し開始より再生開始を遅らせることにより吸収でき、末尾については次に続くデータがないため連続再生を気にする必要が無いからである。このように先頭と末尾において条件を緩めることにより、短い空き領域を有効利用できる。
＜ファイルシステム＞
本発明の説明において用いるファイルシステムのフォーマットである、ＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａｔ）について図２５（ａ）（ｂ）と図２６を用いて説明する。図２５（ａ）に示すディレクトリ／ファイル構成をＵＤＦで記録した例を図２５（ｂ）に示す。図中のＡＶＤＰ６０２はＡｎｃｈｏｒ Ｖｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｐｏｉｎｔｅｒの略であり、ＵＤＦの管理情報を探すためのエントリポイントに相当し、通常２５６セクタ目、Ｎセクタ目あるいはＮ−２５６セクタ目（Ｎは最大論理セクタ番号）に記録する。ＶＤＳ６０１はＶｏｌｕｍｅ Ｄｅｓｃｒｉｐｔｏｒ Ｓｅｑｕｅｎｃｅの略であり、ＵＤＦが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは一般に一枚のディスクに１個存在し、その中にパーティションを一般に１個含む。ＦＳＤ６０３はＦｉｌｅ Ｓｅｔ Ｄｅｓｃｒｉｐｔｏｒの略であり、パーティションに１個存在する。パーティションの中での位置情報はパーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。なお、１個の論理ブロックは１セクタに対応する。
ＦＳＤ６０３は、ルートディレクトリのＦｉｌｅ Ｅｎｔｒｙ（ＦＥ）であるＦＥ６０４の位置情報（論理ブロック番号と論理ブロック数で構成されｅｘｔｅｎｔと呼ばれる）を含む。ＦＥは、ｅｘｔｅｎｔの集合を管理しており、ｅｘｔｅｎｔを書き換えたり、追加したり、削除することで、ファイルを構成する実データの順番を変えたり、データを挿入したり削除したりすることが可能である。ＦＥ６０４はルートディレクトリの直下のファイルやディレクトリの名称等を格納するＦｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒ（ＦＩＤ）の集合を格納する領域６０５を管理する。領域６０５中のＦＩＤ６１１、ＦＩＤ６１２は、それぞれファイル６２１、ファイル６２２のファイル名やｅｘｔｅｎｔの集合を管理するＦＥ６０６、ＦＥ６０８の位置情報を含む。ＦＥ６０６はファイル６２１の実データを構成する領域である領域６０７、領域６１０をｅｘｔｅｎｔとして管理する。このときファイル６２１の実データにアクセスするためには、ＡＶＤＰ６０２、ＶＤＳ６０１、ＦＳＤ６０３、ＦＥ６０４、ＦＩＤ６１１、ＦＥ６０６、領域６０７、領域６１０の順にリンクを辿っていけばよい。
次に追記型ディスクに対応したＵＤＦについて図２６を用いて説明する。図２５（ｂ）と比べ、ＶＡＴ（Ｖｉｒｔｕａｌ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）６１３および前回追記終了領域６１４が加わっている点が異なる。ＶＡＴは、ＦＥを指すアドレスの変換テーブルであり、このテーブルを用いることで書き換えのできない追記型ディスクにおいて見た目上、書き換えを実現する。前回追記終了領域６１４は、前回の追記がどこで終わったかを示すための領域であり、ＤＶＤ−ＲではＢｏｒｄｅｒ ｏｕｔと呼ばれている。ＤＶＤ−ＲではＢｏｒｄｅｒ ｏｕｔの直前にＶＡＴを記録し、再生時はまずＢｏｒｄｅｒ ｏｕｔを検出し、その直前のＶＡＴを読み出すことで、ＦＥを指すアドレスの変換テーブルをメモリ上に構築し、変換テーブルを経由してディスク上の実際のＦＥにアクセスすることになる。したがって、ファイルを見た目上書き換えるようとした場合、更新分のデータを追記し、そのデータのｅｘｔｅｎｔを書き換え対象のファイルのＦＥに追加したものをディスクに追記し、そのファイルのＦＥを新しいＦＥに読みかえるようなマッピングをＶＡＴに登録すればよい。ファイルの追加や削除についても同様に、ＦＩＤの集合のｅｘｔｅｎｔを管理するＦＥを追記し、従来のＦＥと置き換えるようなマッピングをＶＡＴに登録すればよい。
〔第１の実施形態〕
本発明の第１の実施形態について、図２７乃至図４１を用いて説明する。
＜管理情報フォーマット＞
前述のように、ディスク内に含まれるＱｕｉｃｋＴｉｍｅムービーや静止画データ等を含む各種ファイル（以後、ＡＶファイルと呼ぶ）を管理するため、ＡＶ Ｉｎｄｅｘファイル１７４０という特別のＱｕｉｃｋＴｉｍｅムービーファイルをディスク内に置く。図２７に、本実施形態におけるＡＶ Ｉｎｄｅｘファイル１７４０の構成を示す。ＡＶ Ｉｎｄｅｘファイル１７４０は通常のＱｕｉｃｋＴｉｍｅムービーファイルと同様、管理情報であるＭｏｖｉｅ ａｔｏｍ１７９１とデータ自体のＭｏｖｉｅ ｄａｔａ ａｔｏｍ１７９２で構成される。
なお、ＡＶファイルが請求の範囲における「本体データ」に相当し、ＡＶ Ｉｎｄｅｘファイルが請求の範囲における「見出しデータ」に相当する。
ＡＶ Ｉｎｄｅｘファイル１７４０は、複数のエントリを管理し、ディスク内の各ＡＶファイルはそれぞれ１個のエントリで管理される。
Ｍｏｖｉｅ ａｔｏｍ１７９１は、各エントリの属性情報（属性データ）を管理するためのＰｒｏｐｅｒｔｙ ｔｒａｃｋ１７９３、各エントリのタイトル文字列データを管理するためのＴｉｔｌｅ ｔｒａｃｋ１７９４、各エントリの代表画像データを管理するためのＴｈｕｍｂｎａｉｌ ｔｒａｃｋ１７９５、各エントリの代表オーディオデータを管理するためのＩｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ１７９６の計４種類のトラックで構成される。
各エントリに関する属性情報やタイトル文字列データ、代表画像データ、代表オーディオデータはそれぞれ１７９３〜１７９６のトラックのサンプルとして管理される。例えばＡＶファイル１７４１に関する属性情報はＰｒｏｐｅｒｔｙ ｔｒａｃｋ１７９３上のサンプル１７０１、タイトル文字列データはＴｉｔｌｅ ｔｒａｃｋ１７９４上のサンプル１７１１、代表画像データはＴｈｕｍｂｎａｉｌ ｔｒａｃｋ１７９５上のサンプル１７２１、代表オーディオデータはＩｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ１７９６上のサンプル１７３１で管理する。サンプル間の対応付けは、各サンプルの再生開始時間に基づき行う。すなわち、トラック間で同一時刻に位置するサンプルが同一エントリに対応していると判断する。
Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ１７９２は、各ＡＶファイルに関する属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータを格納する。
なお、属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータが、それぞれ請求の範囲における「見出し情報」に相当する。
属性情報は図２８に示す構成を取る。各フィールドについて説明する。ｖｅｒｓｉｏｎは、ファイルフォーマットのバージョンを示す。ｆｌａｇｓは各種フラグをまとめたものである。ｅｎｔｒｙ−ｎｕｍｂｅｒは、属性情報に対応するエントリのＩＤを格納する。
ｃｒｅａｔｉｏｎ−ｔｉｍｅおよびｍｏｄｉｆｉｃａｔｉｏｎ−ｔｉｍｅはこの属性情報に対応するエントリが作成された日時、修正された日時を表す。ｄｕｒａｔｉｏｎはこの属性情報に対応するエントリの再生時間を表す。ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒは、この管理情報に対応するエントリがファイルに対応していた場合、そのファイルのファイル名を格納する。
上記ｆｌａｇｓについて図２９を用いて説明する。Ｓｔａｔｕｓ ｏｆ Ｅｎｔｒｙは、対応するエントリが有効（ａｖａｉｌａｂｌｅ）か無効（ｉｎｖａｌｉｄ）かを識別するためのフラグである。
Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ１７９２に格納されるその他のデータについて説明する。代表画像データには１６０×１２０画素に縮小されたＪＰＥＧ圧縮されたデータ、タイトル文字列データにはテキストデータ、代表オーディオデータにはＭＰＥＧ−１ Ａｕｄｉｏ Ｌａｙｅｒ−ＩＩで圧縮されたデータをそれぞれ用いる。
＜全体の流れ＞
本実施形態における、ディスク挿入から、ディスクイジェクトあるいは電源ＯＦＦまでの流れを、図３０に示す。
光ディスク１０６が挿入されたら、前述のシーケンスに沿って、まずファイルシステムの管理情報を読みこむ（ステップ２０００）。次にＡＶ Ｉｎｄｅｘファイルを光ディスク１０６から読み込み、インデックス画面の表示を行う（ステップ２００１）。次に、ＡＶ Ｉｎｄｅｘファイルをディスクに記録するタイミングかどうかチェックする。記録するタイミングとは、ディスクイジェクト指示や電源ＯＦＦあるいは、ＲＡＭ１０２に新規の情報を光ディスク１０６から読み出すために、ＡＶ Ｉｎｄｅｘファイルに関する情報をＲＡＭ１０２上の光ディスク１０６に一旦記録する必要になったタイミングである。記録するタイミングであればステップ２００３からステップ２００４までのＡＶ Ｉｎｄｅｘ記録処理を行う。一方、そうでなかった場合、まず、ユーザからの指示が無いかチェックする（ステップ２００８）。もし指示があれば、指示に沿って各種処理（図３１参照）を実行し、上記の処理が終了したら、それらを反映してインデックス画面表示更新処理を実行する（ステップ２０１９）。
次に、ステップ２００３からステップ２００７で示される処理について説明する。まず、ＲＡＭ１０２上の情報からＡＶ Ｉｎｄｅｘファイルの記録を行い（ステップ２００３）、ファイル・ディレクトリ情報記録を行う（ステップ２００４）。次に、ＡＶ Ｉｎｄｅｘ記録を行うトリガーとなったのが、電源ＯＦＦあるいはディスクイジェクトがどうかをチェックし（ステップ２００５）、電源ＯＦＦあるいはディスクイジェクトであれば、ＶＡＴを記録し（ステップ２００６）、追記終了位置を示すための領域であるＢｏｒｄｅｒ ｏｕｔを記録する（ステップ２００７）。この光ディスク１０６を再生する場合、最初にＶＡＴを読み出す必要があるが、その位置を探すための情報がＢｏｒｄｅｒ ｏｕｔである。従って再生機器は、ファイルの読み出し前に必ず、ピックアップを光ディスクの半径方向に移動させ、最後のＢｏｒｄｅｒ ｏｕｔを探し、その直前のＶＡＴを読み出す。本実施形態のように、最新のＡＶ Ｉｎｄｅｘファイルの内容を記録する領域をＶＡＴやＢｏｒｄｅｒ ｏｕｔの近傍に置くことによって、ＡＶ Ｉｎｄｅｘファイルを読み出すまでのシーク時間を短縮することができる。このことにより、代表画像やタイトル等を高速にユーザに示すことが可能になり、ユーザへのレスポンスの向上に繋がる。
次に、ステップ２００９における各種処理について図３１を用いて説明する。まず、指示が録画かどうかをチェックし（ステップ２０１０）、録画であれば後述する録画処理を行う（ステップ２０１１）。指示が録画でなければ、エントリ削除、すなわち既存のＡＶファイルの削除かどうかをチェックし（ステップ２０１２）、エントリ削除なら後述するエントリ削除処理（ステップ２０１３）を実行する。指示が録画でもエントリ削除でもなければ次に、既存のエントリに関する代表画像データやタイトル文字列データ、代表オーディオデータ、属性情報のいずれかの変更かどうかをチェックし（ステップ２０１４）、そうであれば後述するサムネイル等変更処理（ステップ２０１５）を実行する。指示されたのがサムネイル等変更処理でなければ、その他処理（ステップ２０１６）を実行する。
以下各処理について詳細を説明する。ここでは、処理を開始する前の初期状態として、光ディスク１０６に図３２（ａ）に示すディレクトリ構成でファイルが記録され、それぞれが光ディスク１０６上に図３２（ｂ）に示すように配置されていると仮定する。すなわち、ＡＶファイルであるＳＨＲＰ０００１．ＭＯＶ、ＳＨＲＰ０００２．ＭＯＶおよびＳＨＲＰ０００３．ＭＯＶは、それぞれ、ＡＶ ｆｉｌｅ２２０１、ＡＶ ｆｉｌｅ２２０２およびＡＶ ｆｉｌｅ２２０３の位置に記録される。またＡＶ ＩｎｄｅｘファイルであるＡＶＩＦ００００．ＭＯＶは、図３２（ｂ）中のＡＶ Ｉｎｄｅｘ ｆｉｌｅ２２０４の領域に記録され、ＡＶ Ｉｎｄｅｘ ｆｉｌｅ２２０４の領域の先頭にはＡＶ Ｉｎｄｅｘ ｆｉｌｅのＭｏｖｉｅ ａｔｏｍが領域２２１１に記録される。また、ＳＨＲＰ０００１．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データが、領域２２１２、領域２２１５、領域２２１８に記録され、ＳＨＲＰ０００２．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データが、領域２２１３、領域２２１６、領域２２１９に記録され、ＳＨＲＰ０００３．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データが、領域２２１４、領域２２１７、領域２２２０に記録されているとする。後述するインデックス画面表示処理を行った結果、ＲＡＭ１０２には、ＡＶ Ｉｎｄｅｘファイルに関する情報を管理するための図３３に示すテーブルが構成される。ここでは、このテーブルをＡＶ Ｉｎｄｅｘ管理テーブルと呼ぶ。このテーブルの各行は、ディスク挿入時に読み出したＡＶ Ｉｎｄｅｘの状態およびその後の各エントリの更新を管理する。各行には、属性に関する情報や各エントリが管理するＡＶファイルの名称、代表画像データが記録してあった位置（ＡＶ Ｉｎｄｅｘファイルの名称およびアドレス情報）、ＲＡＭ１０２の別領域に保持している代表画像データへのポインタ情報を持つ。なお、代表オーディオデータおよびタイトル文字列データに関しては説明を簡単にするため図示していないが、それぞれ、代表画像データおよび属性情報と同様の扱いを行う。また、各ファイルの名称は実際にはルートディレクトリからのフルパスで管理しているが、ここでは簡単のため、ディレクトリ名は省略している。
＜録画時の処理＞
本実施形態における録画時の処理を図３４（ａ）（ｂ）を用いて説明する。ユーザから録画が指示されたら、まずオーディオエンコーダ１１７およびビデオエンコーダ１１８を起動し、図示されないカメラおよびマイクからの入力データを前述の符号化方式でエンコードを開始する。エンコードされたオーディオデータとビデオデータはマルチプレクサ１１３によって、前述のＡＶストリームフォーマットに従って多重化される。その際に、後ほどＭｏｖｉｅ ａｔｏｍを記録するのに必要となる、ＧＯＰのサイズや再生時間などをＲＡＭ１０２に蓄積していく。また、入力ビデオから先頭画像を代表画像として抜き出し縮小したものを、ＪＰＥＧ符号化でエンコードし、代表画像データを作成し、ＲＡＭ１０２に保持する。多重化結果であるＡＶストリームは、記録／アフレコ用バッファ１１１およびＥＣＣエンコーダ１０９を経由して、ピックアップ１０７によって光ディスク１０６に記録される。ＡＶストリームの光ディスク１０６への記録は、図３４（ａ）の２１００の位置に左から右に行われる。
ユーザから録画停止が指示され、記録／アフレコ用バッファ１１１に残ったＡＶストリームを光ディスク１０６へ記録し終わったら、記録したＡＶストリームのバイト数をＲＡＭ１０２に記憶し、次にＭｏｖｉｅ ａｔｏｍの記録を行う。記録は、図３４（ａ）に示すようにセクタ境界２１１２から開始する。Ｍｏｖｉｅ ａｔｏｍの記録が終了したら、次のセクタ境界２１１３の直前にＭｏｖｉｅ ｄａｔａ ａｔｏｍのａｔｏｍ ｈｅａｄｅｒの後端が位置するよう、適切なサイズのＳｋｉｐ ａｔｏｍを領域２１０２に挿入する。なお、Ｓｋｉｐ ａｔｏｍとは、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおいて主にパディング用途に使われるａｔｏｍである。次に、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍのａｔｏｍ ｈｅａｄｅｒを領域２１０３に記録する。ａｔｏｍ ｈｅａｄｅｒにはＲＡＭ１０２に記憶しておいたＡＶストリームのバイト数とＭｏｖｉｅ ｄａｔａ ａｔｏｍのａｔｏｍ ｈｅａｄｅｒのバイト数を足し合わせた値を記録し、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍを意味する″ｍｄａｔ″を記録する。最後に、ＦＥを２１０４の位置に記録する。ＦＥには、このＡＶファイルを先頭から読み出した場合、図３４（ｂ）の順になるように情報を記録しておく。
このような記録形態を採る理由を以下に説明する。ＱｕｉｃｋＴｉｍｅファイルフォーマットにおいて、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ中のｓｉｚｅとＭｏｖｉｅ ａｔｏｍの内容は、録画が終了しない限り決定しない性質の情報である。通常、ＡＶストリームのサイズは、記録／アフレコ用バッファ１１１より大きいため、Ｍｏｖｉｅ ａｔｏｍ記録の前にＡＶストリームを記録する必要がある。このとき、書き換え可能型ディスクにおいては、前方（図３４（ａ）におけるＡＶ ｓｔｒｅａｍ２１００の左）に戻って、Ｍｏｖｉｅ ａｔｏｍを記録することが可能であるが、追記型ディスクの場合、後方（図３４（ａ）におけるＡＶ ｓｔｒｅａｍ２１００の右）にしかできない。したがって、光ディスク上での記録は、図３４（ａ）の順に記録し、ファイルとしての読み出し順が図３４（ｂ）となるよう、ファイルシステムの管理情報であるＦＥを記録する。このとき、ＦＥの情報により、複数の連続領域間を順次に読み出す場合は、最後の領域を除きそれぞれの領域のサイズはセクタ（記録ユニット）の整数倍となっている必要がある。そのため、Ｓｋｉｐ ａｔｏｍ２１０２を挿入し、Ｍｏｖｉｅ ａｔｏｍ２１０１、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍのａｔｏｍ ｈｅａｄｅｒ２１０３を記録した領域のサイズがセクタの整数倍となるよう調節している。Ｓｋｉｐ ａｔｏｍは最上位のａｔｏｍ（例えばＭｏｖｉｅ ａｔｏｍやＭｏｖｉｅ ｄａｔａ ａｔｏｍ）の境界ならどこにでも挿入可能であるため、Ｍｏｖｉｅ ａｔｏｍ２１０１とＭｏｖｉｅ ｄａｔａ ａｔｏｍ２１０３の間以外にも例えば、Ｍｏｖｉｅ ａｔｏｍの直前でも構わない。また、本実施形態では、Ｍｏｖｉｅ ａｔｏｍとＡＶストリームを同一ファイルに格納したが、図２（ｂ）に示すように別ファイルに記録してもよいことは言うまでもない。この場合、ＡＶストリームファイル、Ｍｏｖｉｅ ａｔｏｍのみのファイルの順に記録することになる。
録画が終了した時点で、ＲＡＭ１０２上のＡＶ Ｉｎｄｅｘ管理テーブルには、図３５の行番号３で示す行を追加する。以下、その行の内容について説明する。属性情報において、ｅｎｔｒｙ−ｎｕｍｂｅｒは既存の番号と重複しない番号を格納する。ＡＶファイル名称に関しても、ＡＶ Ｉｎｄｅｘ管理テーブルにおける既存のＡＶファイル名称の５桁目から８桁目までの数字部分がファイルシステム的に重複しないファイル名称を生成して格納する。また、代表画像データ記録位置に関しては、光ディスク１０６上には未記録であるため、未記録を示すＮＵＬＬを格納する。また、代表画像データポインタに関しては、記録時に生成した前述の代表画像データのＲＡＭ１０２上でのアドレスを格納する。
＜エントリ削除処理＞
本実施形態におけるエントリ削除時の処理を説明する。ここでは、削除直前のＡＶ Ｉｎｄｅｘ管理テーブルの状態が図３５に示す状態であったと仮定する。ユーザから、エントリの削除を指示された場合、ＲＡＭ１０２上のＡＶ Ｉｎｄｅｘ管理テーブルに、図３６の行番号４で示す行を追加する。すなわち、削除するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒと同一のｅｎｔｒｙ−ｎｕｍｂｅｒを持ち、ｓｔａｔｕｓ ｏｆ ｅｎｔｒｙがｉｎｖａｌｉｄの行を追加する。
＜エントリデータ変更時の処理＞
本実施形態におけるエントリデータ変更時の処理を説明する。ここでは、エントリデータ変更直前のＡＶ Ｉｎｄｅｘ管理テーブルの状態が図３６に示す状態であったと仮定する。ユーザから、代表画像の変更を指示された場合、まず、変更後の画像を取得し、ＲＡＭ１０２上にＪＰＥＧ符号化データで格納する。次に、ＲＡＭ１０２上のＡＶ Ｉｎｄｅｘ管理テーブルに、図３７の行番号５で示す行を追加する。すなわち、代表画像を変更するエントリとｅｎｔｒｙ−ｎｕｍｂｅｒと同一のｅｎｔｒｙ−ｎｕｍｂｅｒを持ち、代表画像データポインタに前述のＪＰＥＧ符号化データが格納されたＲＡＭ１０２上の先頭アドレスを持つ行を追加する。このとき、変更するのが代表画像データだけであることを示すため、他の項目には、無変更を意味するＮＯ ＣＨＡＮＧＥを格納する。また、録画時と同様、光ディスク１０６上に未記録であるため、代表画像データ記録位置にはＮＵＬＬを格納する。なお、ここでは、代表画像を変更する場合について説明したが代表オーディオやタイトル、その他属性情報等エントリデータの変更に関しても同様の処理を行う。
＜ＡＶ Ｉｎｄｅｘ記録処理＞
本実施形態におけるＡＶ Ｉｎｄｅｘファイル記録処理を図３８に沿って説明する。まず、ＡＶ Ｉｎｄｅｘ管理テーブル上で、ｅｎｔｒｙ−ｎｕｍｂｅｒが重複する行の統合を行う（ステップ２４０１、２４０２）。具体的にはｅｎｔｒｙ−ｎｕｍｂｅｒが重複する行があった場合、行番号の小さい行を行番号の大きい行の内容で上書きし、大きい行を削除する。上書きの際、変更無しを意味するＮＯ ＣＨＡＮＧＥが格納されている項目については、行番号の小さい行の上書きを行わない。次に、削除済みのエントリを除外処理する。具体的にはｓｔａｔｕｓ ｏｆ ｅｎｔｒｙがｉｎｖａｌｉｄとなっている、ｅｎｔｒｙ−ｎｕｍｂｅｒを持つ行をＡＶ Ｉｎｄｅｘ管理テーブルから削除する（ステップ２４０３）。
次に新規記録ＡＶ ＩｎｄｅｘファイルのＳａｍｐｌｅ ｔａｂｌｅの構築をＲＡＭ１０２上で行う（ステップ２４０４）。具体的には、属性情報やタイトル文字列データのようにデータ量の小さく、しかもユーザや機器にとって重要度の高い即座にアクセスしたいデータは、新規記録ＡＶ Ｉｎｄｅｘファイルに記録し、代表画像データや代表オーディオデータのように、重要度の低い情報（例えば、文字列１行分の表示手段しか持たない機器では、代表画像は意味を持たない）は新規に追加されたデータを除き、既存のＡＶ Ｉｎｄｅｘファイルを参照するようにＳａｍｐｌｅ ｔａｂｌｅを構築する。
新規記録ＡＶ Ｉｎｄｅｘファイルに記録するか、既存のＡＶ Ｉｎｄｅｘファイルを参照するようにするかは、属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータの各データの属性に基づいて定められる。このデータの属性としては、上記のようにデータ量が考えられるが、これ以外にも、そのデータの階層情報や、そのデータの優先度、そのデータに対応するＡＶファイルを再生した時刻なども考えられる。このようなデータの属性を、光ディスク１０６に記録しておいてもよい。
以上の処理は、請求の範囲における「見出しデータ作成手段」としてのホストＣＰＵ１０１およびＲＡＭ１０２により実行される。
このようにすることで、記録容量の無駄を削減しつつ、重要度の高い情報へのアクセス性能の低下を防ぐことが可能になる。次に、新規記録ＡＶ ＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍを記録し（ステップ２４０５）、ＡＶ Ｉｎｄｅｘ管理テーブル中の全エントリの属性情報およびタイトル文字列を記録し（ステップ２４０６）、最後に新規に追加された、代表画像データおよび代表オーディオデータを記録する。新規に追加されたかどうかは、ＡＶ Ｉｎｄｅｘ管理テーブル中の代表画像データ記録位置がＮＵＬＬであるか否かで判断できる。
なお、新規記録ＡＶ Ｉｎｄｅｘファイルの名称は光ディスク１０６上の既存のＡＶ Ｉｎｄｅｘファイルの名称の５桁目から８桁目までの数字を取り出した値の最大値に１を加えたものにする。例えば既存のＡＶ Ｉｎｄｅｘファイルの名称がＡＶＩＦ００００．ＭＯＶ〜ＡＶＩＦ０１００．ＭＯＶであった場合、ＳＨＲＰ０１０１．ＭＯＶとする。このことにより、最新のＡＶ Ｉｎｄｅｘファイルを名称から判断することが可能になると同時に、最新以外のＡＶ Ｉｎｄｅｘファイルを参照することで、光ディスク１０６における、過去のスナップショット（状態）を容易に再現することが可能になる。
このように、ＡＶ Ｉｎｄｅｘファイルの名称を、ＡＶ Ｉｎｄｅｘファイル間の関連情報として光ディスク１０６に記録しておくことで、その光ディスク１０６における記録内容の変更履歴に容易にアクセスすることができるようになる。また、ＡＶ Ｉｎｄｅｘファイルの名称の一部を通し番号とすることで、履歴の順番を容易に把握することができる。
以上の処理を行った直後の光ディスク１０６の記録状態を具体的に説明する。ここでは、ＡＶ Ｉｎｄｅｘファイル記録処理開始直前に、ＲＡＭ１０２上には図３７の内容を持つＡＶ Ｉｎｄｅｘ管理テーブルが存在すると仮定する。ＡＶ Ｉｎｄｅｘファイル記録処理を行った結果、光ディスク１０６上には図３９に示すように、新規ＡＶ Ｉｎｄｅｘ ｆｉｌｅ２２４２が作成される。その中には、代表画像データを変更したＳＨＲＰ０００２．ＭＯＶ２２０２に関する属性情報、タイトル文字列データおよび代表画像データが、領域２２３２、領域２２３５、領域２２３８に記録され、変更のないＳＨＲＰ０００３．ＭＯＶ２２０３に関する属性情報、タイトル文字列データが領域２２３３および領域２２３６に記録され、新規に登録されたＳＨＲＰ０００４．ＭＯＶ２２４１に関する属性情報、タイトル文字列データおよび代表画像データが、領域２２３４、領域２２３７、領域２２３９に記録される。ＳＨＲＰ０００３．ＭＯＶ２２０３の代表画像データについては、既存のＡＶ Ｉｎｄｅｘ ｆｉｌｅ中の領域２２２０を参照するため、新たに記録は行わない。
なお、ＡＶ Ｉｎｄｅｘ ｆｉｌｅ２２０４が請求の範囲における「旧い見出しデータ」あるいは「第１のデータ」に相当し、ＡＶ Ｉｎｄｅｘ ｆｉｌｅ２２４２が請求の範囲における「新たな見出しデータ（新しい見出しデータ）」あるいは「第２のデータ」に相当する。
したがって、第１のデータは既記録データであり、第２のデータは新規記録データであることになる。そして、第１のデータと第２のデータとは、記録時期が異なり、記録媒体上でも離れて記録される。再生時には、第１のデータを、第２のデータより先に読み出すことになる。また、第２のデータは、第１のデータの追加データである、ともいえる。
また、Ｍｏｖｉｅ ａｔｏｍ２２３１が請求の範囲における「第３のデータ」に相当し、ＡＶ Ｉｎｄｅｘ ｆｉｌｅ２２０４に含まれる属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータ（図３２参照）等のエントリデータが、それぞれ請求の範囲における「第４のデータ」に相当する。
また、請求の範囲における「参照情報」あるいは「第４のデータに関する情報」は、管理情報であるＭｏｖｉｅ ａｔｏｍ２２３１に含まれるサンプル（図２７参照）の何れかに相当する。
また、ＡＶファイルが請求の範囲における「第５のデータ」に相当する。したがって、属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータ等の第４のデータは、第５のデータに関する情報を有するデータであるといえる。
＜インデックスファイル画面表示処理＞
本実施形態におけるインデックスファイル画面表示処理を図４０に沿って説明する。まず、最新のＡＶ Ｉｎｄｅｘファイルをｏｐｅｎし（ステップ２３００）、Ｍｏｖｉｅ ａｔｏｍを読み込み、前述のＡＶ Ｉｎｄｅｘ管理テーブルをＲＡＭ１０２上に作成する。ただし、この時点では、代表画像データ等各種データの位置情報のみを取得したのみであり、まだ各種データのＲＡＭ１０２上への読み込みは行っていない（ステップ２３０１）。なお、どのＡＶ Ｉｎｄｅｘファイルが最新かどうかは、前述したように、ファイル名を用いて判断することが可能である。次に、各エントリのタイトル文字列データおよび属性情報を読み出し、ＡＶ Ｉｎｄｅｘ管理テーブルに格納する（ステップ２３０２）。次に、代表画像データや代表オーディオデータの読出しのスケジューリングを行う（ステップ２３０３）。すなわち、ユーザに指定された現状のインデックス表示順および、各データの含まれるＡＶ Ｉｎｄｅｘファイルのファイル名を総合し、最も表示までの時間が短くなるようにファイルをｏｐｅｎする順番を決定する。具体的には、インデックス画面の表示順を基本とし、ファイルｏｐｅｎの回数が少なくなるようにする。次に、現在ｏｐｅｎ中のＡＶ Ｉｎｄｅｘファイルから代表画像データおよび代表オーディオデータの読出しを行う（ステップ２３０４〜２３０５）。有効なデータを読み終わったら、ファイルをｃｌｏｓｅし（ステップ２３０６）、ステップ２３０３で決定された、次にｏｐｅｎするＡＶ Ｉｎｄｅｘファイルの名称を取得し（ステップ２３０８）、最後のファイルまで読み終わっていなければそのファイルをｏｐｅｎし（ステップ２３０９）、ステップ２３０４以降を実行する。
前述のように、ステップ２３０１において、最新以外のＡＶ Ｉｎｄｅｘファイルを参照することで、光ディスク１０６における過去のスナップショット（状態）を容易に再現することが可能になる。
＜バリエーション＞
本実施形態では、削除済みのエントリや変更前のエントリデータについて、最新のＡＶ Ｉｎｄｅｘファイルでは管理していないが、管理するようにしてもよい。具体的には、既存エントリの削除や既存エントリデータの変更という属性を持ったエントリを定義し、追加するようにしていくことが考えられる。あるいは、Ｓａｍｐｌｅ ｔａｂｌｅにサンプル毎の有効／無効を管理するテーブルを追加して記録してもよい。
また、本実施形態では、既存のデータを参照するのに、ＱｕｉｃｋＴｉｍｅファイルフォーマットの外部参照機能を用いているが、ファイルシステムの機能を用いても同様の機能は実現可能である。例えば、本実施形態で外部参照しているデータを含むセクタを、最新ＡＶ Ｉｎｄｅｘファイルのｅｘｔｅｎｔにして、Ｍｏｖｉｅ ａｔｏｍから参照すれば、ＱｕｉｃｋＴｉｍｅファイルフォーマットの外部参照機能を用いることなく同様の機能が実現できる。図３９を例にとると、最新ＡＶ Ｉｎｄｅｘファイルを領域２２３１〜２２３９を含む連続セクタと領域２２２０を含む連続セクタの２個のｅｘｔｅｎｔで構成することになる。これにより、ＡＶ Ｉｎｄｅｘファイル２２０４とＡＶ Ｉｎｄｅｘファイル２２４２とを同一のファイルとして管理することになる。このとき、Ｍｏｖｉｅ ａｔｏｍは、上記同一ファイル内での領域２２２０の位置情報を含むことになる。また、最新ＡＶ Ｉｎｄｅｘファイルのファイル名を直前の最新ＡＶ Ｉｎｄｅｘファイルのファイル名と同一にすることで、ＡＶ Ｉｎｄｅｘファイルのファイル数を増加させることなく、既存データの再利用が可能となる。
さらに、代表画像データ等、エントリデータを記録する際に、その先頭位置がセクタの境界に合うように記録しておけば、エントリデータの先頭がｅｘｔｅｎｔの先頭となるため、上記処理が単純化され、しかもＡＶ Ｉｎｄｅｘファイルに余計なデータが含まれる度合いが減少する。
また、本実施形態では、代表画像データ等のエントリデータをＡＶ Ｉｎｄｅｘファイルに格納しているが、エントリデータだけをまとめて、あるいはエントリデータの種別毎に１個のファイルとして管理してもよい。また、ＡＶファイル内に記録して、ＡＶ Ｉｎｄｅｘファイルから参照するようにしてもよい。このようにすることで、ＡＶ Ｉｎｄｅｘファイルの更新処理において、エントリデータは常に共通のデータファイルを参照すればよいため、エントリデータの参照先を変更する処理が不要となる。
また、本実施形態では、最新ＡＶ Ｉｎｄｅｘファイルには、既存ＡＶ Ｉｎｄｅｘファイルに含まれる代表画像データあるいは代表オーディオデータを記録せず、参照するようにしているが、既存ＡＶ Ｉｎｄｅｘファイルに含まれている代表画像データあるいは代表オーディオデータであったとしても、特定のデータに関して光ディスク１０６からの読出しを高速にし、ユーザに対するレスポンスを向上させるため最新ＡＶ Ｉｎｄｅｘファイルに記録してもよい。特定のデータとしては、例えば、記録してあるディレクトリ階層の浅いＡＶファイルに関する代表画像データが考えられる。また、最新ＡＶ Ｉｎｄｅｘファイルを記録するタイミング（ディスクイジェクト時や電源ＯＦＦ時）において、ユーザに示していたファイルに関する代表画像データや代表オーディオデータを最新ＡＶ Ｉｎｄｅｘファイルに記録しておくことも当然考えられる。このことにより、ディスク挿入時や電源ＯＮ時に、前回の状態（例えば画面表示）をより短時間に再現することが可能になる。
代表画像データや代表オーディオデータを新規記録ＡＶ Ｉｎｄｅｘファイルに記録するか、既存のＡＶ Ｉｎｄｅｘファイルを参照するようにするかは、これら代表画像データや代表オーディオデータの属性に基づいて定められるが、この属性としては、上記のように、そのデータの階層情報や、そのデータに対応するＡＶファイルを再生した時刻なども考えられる。
また、図４１に示すように、属性情報に、表示や読出の優先度を格納するフィールドであるｐｒｉｏｒｉｔｙを用意し、優先度の高いものは、既存ＡＶ Ｉｎｄｅｘファイルに含まれていても、最新ＡＶ Ｉｎｄｅｘファイルに代表画像データあるいは代表オーディオデータを記録することで、ディスク挿入時のインデックス画面の表示を高速化し、ユーザに対するレスポンスを向上させることが考えられる。
〔第２の実施形態〕
本発明の第２の実施形態について、図４２乃至図４７を用いて説明する。第１の実施形態との違いは、第２の実施形態において最新ＡＶ Ｉｎｄｅｘファイルには、既存のＡＶ Ｉｎｄｅｘファイル中のデータに関する管理情報を含まれておらず、管理情報の重複記録による無駄が少ない点にある。第１の実施形態と共通する部分が多いため、相違点に絞って説明を行う。
＜管理情報フォーマット＞
本実施形態におけるＡＶ Ｉｎｄｅｘファイルの構成は、Ｍｏｖｉｅ ａｔｏｍのＵｓｅｒ ｄａｔａ ａｔｏｍに図４２に示すｉｎｄｅｘ ｌｉｎｋ ａｔｏｍが含まれている以外は第１の実施形態と共通である。ｉｎｄｅｘ ｌｉｎｋ ａｔｏｍは、複数のＡＶ Ｉｎｄｅｘファイルがディスク上に存在する場合の、ファイル間の前後関係を示す情報である。このａｔｏｍには、フィールドｐｒｅｖｉｏｕｓとフィールドｎｅｘｔが存在するが、本発明ではフィールドｐｒｅｖｉｏｕｓのみ用いる。フィールドｐｒｅｖｉｏｕｓの使用方法については後述する。
＜全体の流れ＞
本実施形態における、ディスク挿入から、ディスクイジェクトあるいは電源ＯＦＦまでの流れは第１の実施形態と同様であり、説明を省略する。
＜録画時の処理＞
第１の実施形態と同様であり、説明を省略する。
＜エントリ削除処理＞
第１の実施形態と同様であり、説明を省略する。
＜エントリデータ変更時の処理＞
第１の実施形態と同様であり、説明を省略する。
＜ＡＶ Ｉｎｄｅｘ記録処理＞
本実施形態におけるＡＶ Ｉｎｄｅｘファイル記録処理を図４３に沿って説明する。まず、ＲＡＭ１０２上のＡＶ Ｉｎｄｅｘ管理テーブルの統合処理を行う（ステップ３１０１〜３１０２）。具体的には、光ディスク１０６挿入後に追加された行について、ＮＯ ＣＨＡＮＧＥの項目があれば、その行より行番号の小さいエントリに実際のデータの位置が記録されていることがわかるため、同一のｅｎｔｒｙ−ｎｕｍｂｅｒを持つ行を探しその項目の内容で補う。内容の取得元が光ディスク１０６挿入後に追加された行であれば、その行を削除する。
次に、ＡＶ Ｉｎｄｅｘ管理テーブルの情報に基づきＳａｍｐｌｅ ｔａｂｌｅの構築を行う（ステップ３１０３）。具体的には、まず、光ディスク１０６挿入後に追加された行について、各行を１エントリとして、各エントリ毎に、属性情報、代表画像データ、代表オーディオデータ、タイトル文字列データを管理するｓａｍｐｌｅを作成する。
次に、行の種別に応じてｓａｍｐｌｅに情報を格納する。エントリ削除を意味する行については、属性情報中のｓｔａｔｕｓ ｏｆ ｅｎｔｒｙにｉｎｖａｌｉｄをセットし、代表画像データ、代表オーディオデータ、タイトル文字列データを管理するｓａｍｐｌｅのｓｉｚｅ情報を０にセットする。それ以外の行については、最新ＡＶ Ｉｎｄｅｘファイルに最新の属性情報、代表データ、代表オーディオデータ、タイトル文字列データを記録するようにｓａｍｐｌｅを構成する。なお、ｓｔａｔｕｓ ｏｆ ｅｎｔｒｙにセットされたｉｎｖａｌｉｄは、その行に対応するエントリを無効化する情報となる。このｓｔａｔｕｓ ｏｆ ｅｎｔｒｙが、請求の範囲における「第３のデータ」に相当する。
次に、Ｍｏｖｉｅ ａｔｏｍを記録し（ステップ３１０４）、最後に、属性情報、代表データ、代表オーディオデータ、タイトル文字列データを記録する。なお、Ｍｏｖｉｅ ａｔｏｍのｉｎｄｅｘ ｌｉｎｋ ａｔｏｍのフィールドｐｒｅｖｉｏｕｓには直前の最新ＡＶ Ｉｎｄｅｘファイルのファイル名を格納しておく。
なお、新規記録ＡＶ Ｉｎｄｅｘファイルの名称は光ディスク１０６上の既存のＡＶ Ｉｎｄｅｘファイルの名称の５桁目から８桁目までの数字を取り出した値の最大値に１を加えたものにする。
以上の処理を行った直後の光ディスク１０６の記録状態を具体的に説明する。ここでは、ＡＶ Ｉｎｄｅｘファイル記録処理開始直前に、ＲＡＭ１０２上には図３７の内容を持つＡＶ Ｉｎｄｅｘ管理テーブルが存在すると仮定する。ＡＶ Ｉｎｄｅｘファイル記録処理を行った結果、光ディスク１０６上には図４４に示すように、新規ＡＶ Ｉｎｄｅｘ ｆｉｌｅ２２４２が作成される。その中には、ＳＨＲＰ０００２．ＭＯＶに関する属性情報、タイトル文字列データおよび代表画像データが、領域２２５２、領域２２５４および領域２２５６に記録され、ＳＨＲＰ０００４．ＭＯＶに関する属性情報、タイトル文字列データおよび代表画像データが領域２２５３、領域２２５５および領域２２５７に記録される。
第１の実施形態においては、最新のＡＶ ＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍは、光ディスク１０６に存在するすべてのエントリに関する情報を管理している。そのため、過去のＡＶ ＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍと重複する情報が含まれており、その分、記憶容量の無駄が多い。それに対し、本実施形態では、最新のＡＶ ＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍは、前回のＡＶ Ｉｎｄｅｘファイルからの差分（エントリの追加・削除、エントリデータの変更）しか管理していないため、第１の実施形態に比べ、管理情報の重複記録が少ないという利点がある。
＜ＡＶ Ｉｎｄｅｘマージ処理＞
上記のＡＶ Ｉｎｄｅｘ記録を繰り返していった場合、図４５（ａ）のように、光ディスク１０６上に複数のＡＶ Ｉｎｄｅｘファイルが分散して記録されることになる。光ディスクは、読み出し位置の移動に時間がかかるため、読み出し位置の変更回数が多いほど、結果として全体的な読み出し時間がかかることになる。したがって、ＡＶ Ｉｎｄｅｘ記録を繰り返すほど、読み出しに時間がかかることになり、インデックス画面表示等のレスポンスに悪化を来す可能性が考えられる。これを解決する方法として、分散して記録された複数のＡＶ Ｉｎｄｅｘファイルの内容を近傍に集めて記録する、というものが考えられる。ここではその処理をマージ処理と呼ぶことにする。
マージ処理について例を用いて説明する。図４５（ｂ）はマージ処理を行った例であり、ＡＶ Ｉｎｄｅｘ ｆｉｌｅ３３０６にＡＶ Ｉｎｄｅｘ ｆｉｌｅ３３０３およびＡＶ Ｉｎｄｅｘ ｆｉｌｅ３３０４に含まれる属性情報や代表画像といったエントリデータをまとめて記録している。Ｍｏｖｉｅ ａｔｏｍには当然、それらのエントリデータを管理するためのＳａｍｐｌｅ ｔａｂｌｅを格納する。ＡＶ Ｉｎｄｅｘ ｆｉｌｅ３３０６のファイル名は、前述した通り、直前のＡＶ ＩｎｄｅｘファイルであるＡＶ Ｉｎｄｅｘ ｆｉｌｅ３３０４のファイル名に関して５〜８桁目の数字に１加算したものとする。このとき、Ｍｏｖｉｅ ａｔｏｍのＵｓｅｒ ｄａｔａ ａｔｏｍ中のｉｎｄｅｘ ｌｉｎｋ ａｔｏｍのｐｒｅｖｉｏｕｓフィールドに、エントリデータのマージ元のＡＶ Ｉｎｄｅｘファイルの１個前のＡＶ ＩｎｄｅｘファイルであるＡＶ Ｉｎｄｅｘ ｆｉｌｅ３３０２のファイル名を格納する。このことによって、ＡＶ Ｉｎｄｅｘファイルを最新のものから過去に遡って読み出していく際に、ｐｒｅｖｉｏｕｓフィールドを参照することでマージ済みのデータを再度読み出してしまうことを防ぐことができる。また、マージ元のＡＶ Ｉｎｄｅｘファイルも残っているため、過去の状態を容易に再現できる機能も損なわれていない。なお、本実施形態ではマージ処理は、通常のＡＶ Ｉｎｄｅｘ記録処理と独立に行ったが、同時に行ってもよいことは言うまでもない。また、第１の実施形態と同様、エントリやエントリデータの属性に応じて、マージするエントリやエントリデータを選択してもよいことは言うまでもない。
このように、Ｍｏｖｉｅ ａｔｏｍのＵｓｅｒ ｄａｔａ ａｔｏｍ中のｉｎｄｅｘ ｌｉｎｋ ａｔｏｍのｐｒｅｖｉｏｕｓフィールドに格納される情報は、ファイル間の読み出しを制御するための情報であり、この情報が、請求の範囲における「読み出し制御情報」に相当する。
＜編集処理のやり直し処理＞
前述のように、ディスクのイジェクトや電源ＯＦＦあるいは任意のタイミングでＡＶ Ｉｎｄｅｘファイルを記録するようにしているため、記録したＡＶ Ｉｎｄｅｘファイル単位で過去のスナップショット（状態）を容易に再現することが可能になる。
また、既存のＡＶ Ｉｎｄｅｘをディスクから読み出して、変更が反映されたＡＶ Ｉｎｄｅｘをディスクに書き出すまでの間に行われた編集操作等は、ＲＡＭ上にＡＶ Ｉｎｄｅｘ管理テーブルがあるため、取り消すことが容易である。一方、ＡＶ Ｉｎｄｅｘのファイル名の番号から、数字が小さいほど過去に作られたことがわかるため、ＡＶ Ｉｎｄｅｘ単位で過去の状態に遡ることが容易である。ＡＶ Ｉｎｄｅｘファイルに設定された日時情報よりいつ作成されたＡＶ Ｉｎｄｅｘファイルを特定することが可能である。
このとき、最新のＡＶ Ｉｎｄｅｘファイルの状態から、例えば３つ前のＡＶ Ｉｎｄｅｘファイルの状態に戻す事を考える。ここでの「戻す」とは、現在ＲＡＭ上にあるＡＶ Ｉｎｄｅｘ管理テーブルの内容と過去２つのＡＶ Ｉｎｄｅｘファイルで管理される編集操作を全て破棄し、３つ前のＡＶ Ｉｎｄｅｘファイルの状態に復帰することを意味する。これは、ｉｎｄｅｘ ｌｉｎｋ ａｔｏｍのｐｒｅｖｉｏｕｓフィールドで管理されている前のＡＶ Ｉｎｄｅｘファイルを３回たどることによって可能である。ｉｎｄｅｘ ｌｉｎｋ ａｔｏｍによって把握した３つ前のＡＶ Ｉｎｄｅｘファイルの状態をディスクから読み出し、その状態に対して編集操作等を続行する。実際に最新のＡＶ Ｉｎｄｅｘファイルをディスクに記録する際、Ｍｏｖｉｅ ａｔｏｍのＵｓｅｒ ｄａｔａ ａｔｏｍ中のｉｎｄｅｘ ｌｉｎｋ ａｔｏｍのｐｒｅｖｉｏｕｓフィールドに、遡った３つ前のＡＶ Ｉｎｄｅｘファイルのファイル名を格納する。
このことによって、ＡＶ Ｉｎｄｅｘファイルを最新のものから過去に遡って読み出していく際に、ｐｒｅｖｉｏｕｓフィールドを参照することで編集操作を取り消したデータを再度読み出してしまうことを防ぐことができる。また、編集操作を取り消したＡＶ Ｉｎｄｅｘファイルも残っているため、取り消した編集操作も含めて過去の状態を容易に再現できる機能も損なわれていない。また、遡った３つ前のＡＶ Ｉｎｄｅｘファイルの状態を最新のＡＶ Ｉｎｄｅｘファイルとしたい場合、ディスク内の未使用最大ファイル番号のＡＶ Ｉｎｄｅｘとして、有効なｅｎｔｒｙが管理されていないことを示すようサンプル数が０（エントリを一つも管理していない）あるいは全てのフィールドにＮＵＬＬを記録するなどした１つの属性情報、またｉｎｄｅｘ ｌｉｎｋ ａｔｏｍに３つ前のＡＶ Ｉｎｄｅｘファイルのファイル名を格納した特別なＡＶ Ｉｎｄｅｘファイルを記録する。これによりファイル番号が最大の最初に読み出すＡＶ Ｉｎｄｅｘファイルより、３つ前のＡＶ Ｉｎｄｅｘファイルを辿ることが可能となる。
＜インデックスファイル画面表示処理＞
本実施形態におけるインデックスファイル画面表示処理を図４６に沿って説明する。まず、最新のＡＶ Ｉｎｄｅｘファイルをｏｐｅｎし（ステップ３２０１）、Ｍｏｖｉｅ ａｔｏｍを読み込み、前述のＡＶ Ｉｎｄｅｘ管理テーブルをＲＡＭ１０２上に作成する。ただし、この時点では、代表画像データ等各種データの位置情報のみを取得したのみであり、まだ各種データのＲＡＭ１０２上への読み込みは行っていない（ステップ３２０３）。なお、どのＡＶ Ｉｎｄｅｘファイルが最新かどうかは、前述したように、ファイル名を用いて判断することが可能である。次に、ＡＶ Ｉｎｄｅｘファイルから各エントリのタイトル文字列データ、属性情報、代表画像データ、代表オーディオデータを読み出し、ＡＶ Ｉｎｄｅｘ管理テーブルに格納する（ステップ３２０４）。
なお、すでにＡＶ Ｉｎｄｅｘ管理テーブルに存在する行と、同じｅｎｔｒｙ−ｎｕｍｂｅｒを持つ属性情報が読み出されたら、その情報は読み捨てる。有効なエントリデータを読み終わったら、ファイルをｃｌｏｓｅする（ステップ２３０６）。次に、直前にｏｐｅｎしたＡＶ Ｉｎｄｅｘファイル中のｉｎｄｅｘ ｌｉｎｋ ａｔｏｍのｐｒｅｖｉｏｕｓフィールドを参照し、次に読み出すＡＶ Ｉｎｄｅｘファイルの名称を取得する（ステップ３２０７）。次に、直前にｏｐｅｎしたＡＶ Ｉｎｄｅｘファイルが最後に読み出すＡＶ Ｉｎｄｅｘかどうか、を判断する（ステップ３２０８）。具体的には、次に読み出すＡＶ Ｉｎｄｅｘファイルの名称がｉｎｄｅｘ ｌｉｎｋ ａｔｏｍで参照無しを示すＮＵＬＬが指定されていれば、最後のＡＶ Ｉｎｄｅｘと判断する。もし最後に読み出すＡＶ Ｉｎｄｅｘでなければ、次に読み出すＡＶ Ｉｎｄｅｘファイルの名称を持つファイルをｏｐｅｎし（ステップ３２０９）、ステップ３２０３以降を実行する。
前述のように、ステップ３２０１において、最新以外のＡＶ Ｉｎｄｅｘファイルを参照することで、光ディスク１０６における過去のスナップショット（状態）を容易に再現することが可能になる。
＜バリエーション＞
本実施形態では、代表画像データ等のエントリデータを変更する場合に、そのデータが含まれるエントリのすべてのエントリデータを再記録している。図４４を例に取ると、領域２２５５にＳＨＲＰ０００２．ＭＯＶのタイトル文字列データを記録しているが、変更したのは代表画像データのみであり、本来は記録する必要がないデータである。しかし、前記のデータフォーマットでは変更対象のエントリデータの種別を指定できないため、ある種別のエントリデータを変更する場合、すべての種別のエントリデータを上書きする必要がある。このことを解決する方法としては、図４７のように属性情報に変更対象のエントリデータの種別を追加することが考えられる。例えば代表画像データの変更をしたければ、Ｓｔａｔｕｓ ｏｆ Ｔｈｕｍｂｎａｉｌをａｖａｉｌａｂｌｅで他のＳｔａｔｕｓ ｏｆ Ｉｎｔｒｏ ｍｕｓｉｃやＳｔａｔｕｓ ｏｆ Ｔｉｔｌｅはｉｎｖａｌｉｄに設定する。読み出し時はＳｔａｔｕｓ ｏｆ Ｔｈｕｍｂｎａｉｌがａｖａｉｌａｂｌｅであればデータを読み出し、ｉｎｖａｌｉｄであればデータは既存のものを用いる。このようにすることで、変更対象の種別のエントリデータだけ記録することが可能になり、記録容量の無駄を削減することが可能になる。
また、本実施形態では、エントリの削除を、ｅｎｔｒｙ−ｎｕｍｂｅｒが同一でｓｔａｔｕｓ ｏｆ ｅｎｔｒｙがｉｎｖａｌｉｄのエントリを追加することで行っているが、削除対象のエントリを管理するＡＶ Ｉｎｄｅｘファイルを削除することで行ってもよい。この場合、各ＡＶ Ｉｎｄｅｘファイルで管理するエントリは１個に限定することになる。さらに、削除対象のエントリを管理するＡＶ Ｉｎｄｅｘファイルに関して、ファイル名を変更し、無効化することで行ってもよい。
〔第３の実施形態〕
本発明の第３の実施形態について、図４８乃至図５２を用いて説明する。本実施形態は、管理情報の重複記録を避けるという点で第２の実施形態と共通するが、管理情報やエントリデータを１個のＡＶ Ｉｎｄｅｘファイルに追記していくという点が異なる。
＜管理情報フォーマット＞
本実施形態におけるＡＶ Ｉｎｄｅｘファイルの構成を図４８に示す。ＡＶ Ｉｎｄｅｘファイルは、前述のＦｒａｇｍｅｎｔｅｄ ｍｏｖｉｅで構成する。すなわち、先頭にファイル全体の管理情報であるＭｏｖｉｅ ａｔｏｍを置き、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍとＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍを交互に並べる。Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍは、属性情報、代表オーディオデータ、代表画像データおよびタイトル文字列データを管理するために、Ｐｒｏｐｅｒｔｙ ｔｒａｃｋ、Ｉｎｔｒｏ ｍｕｓｉｃ ｔｒａｃｋ、Ｔｈｕｍｂｎａｉｌ ｔｒａｃｋ、Ｔｉｔｌｅ ｔｒａｃｋをそれぞれ持つ。各Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍは、トラックをまたぐサンプル同士が共通のエントリに対応していることを示すため、各トラックに関して同一数なおかつ同一時間長のサンプルを管理する。
例えば、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍ４１０３がｍ個のエントリを管理していた場合、属性情報、代表オーディオデータ、代表画像データおよびタイトル文字列データそれぞれにｍ個のサンプルを管理する。そのサンプルに対応するデータは、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍ４１０３に対応するＭｏｖｉｅ ｄａｔａ ａｔｏｍであるＭｏｖｉｅ ｄａｔａ ａｔｏｍ４１０２に格納する。
なお、属性情報、代表オーディオデータ、代表画像データおよびタイトル文字列データのフォーマットは第１の実施形態と同一であるため、説明を省略する。
＜全体の流れ＞
本実施形態における、ディスク挿入から、ディスクイジェクトあるいは電源ＯＦＦまでの流れは第１の実施形態と同様であり、説明を省略する。ここでは、処理を開始する前の初期状態として、光ディスク１０６に第１の実施形態と同様の図３２（ａ）に示すディレクトリ構成でファイルが記録され、それぞれが光ディスク１０６上に図４９に示すように配置されていると仮定する。すなわち、ＡＶファイルであるＳＨＲＰ０００１．ＭＯＶ、ＳＨＲＰ０００２．ＭＯＶおよびＳＨＲＰ０００３．ＭＯＶは、それぞれ、領域４２０１、領域４２０２および領域４２０３に記録される。またＡＶ ＩｎｄｅｘファイルであるＡＶＩＦ００００．ＭＯＶは、図４９中の領域４２０４に記録され、領域４２０４の先頭にはＡＶ Ｉｎｄｅｘ ｆｉｌｅのＭｏｖｉｅ ａｔｏｍが領域４２１１に記録される。
また、ＳＨＲＰ０００１．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データが、領域４２１２、領域４２１５、領域４２１８、に記録され、ＳＨＲＰ０００２．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データが、領域４２１３、領域４２１６、領域４２１９に、記録され、ＳＨＲＰ０００３．ＭＯＶの属性情報、タイトル文字列データおよび代表画像データが、領域４２１４、領域４２１７、領域４２２０に記録され最後に上記のエントリデータを管理するＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍと後述するＳｋｉｐ ａｔｏｍが領域４２２１と領域４２２２にそれぞれ記録されているとする。さらに、後述するインデックス画面表示処理を行った結果、ＲＡＭ１０２には、ＡＶ Ｉｎｄｅｘファイルに関する情報を管理するための図３７に示すテーブルが構成されると仮定する。
＜録画時の処理＞
第１の実施形態と同様であり、説明を省略する。
＜エントリ削除処理＞
第１の実施形態と同様であり、説明を省略する。
＜エントリデータ変更時の処理＞
第１の実施形態と同様であり、説明を省略する。
＜ＡＶ Ｉｎｄｅｘ記録処理＞
本実施形態におけるＡＶ Ｉｎｄｅｘファイル記録処理について図５０を用いて説明する。まず、ＲＡＭ１０２上のＡＶ Ｉｎｄｅｘ管理テーブルの統合処理を行い（ステップ４３０１〜４３０２）、その結果に基づきＳａｍｐｌｅ ｔａｂｌｅを構築する（ステップ４３０３）。具体的な処理は第２の実施形態と同一であるため、説明を省略する。次にＭｏｖｉｅ ｄａｔａ ａｔｏｍを記録する（ステップ４３０４）。具体的には、ａｔｏｍ ｈｅａｄｅｒを記録し、個々のエントリの属性情報、代表データ、代表オーディオデータおよびタイトル文字列データを記録する。最後に、上記のＳａｍｐｌｅ ｔａｂｌｅの内容を元にＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍを記録する（ステップ４３０５）。Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍの記録が終わったら、ファイルの終端がセクタの境界と一致するよう、前述のＳｋｉｐ ａｔｏｍを調整のため挿入する。これにより、ＡＶ Ｉｎｄｅｘファイルを整数個のセクタで構成することになる。なお、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍとＭｏｖｉｅ ｄａｔａ ａｔｏｍの記録順は逆であってもよい。また、サイズの調整にＳｋｉｐ ａｔｏｍでなく、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍの直前に無意味データを入れてもよい。その場合、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍのａｔｏｍ ｈｅａｄｅｒのｓｉｚｅフィールドには、前記無意味データのデータ量を含めることになる。
その後、今回記録した領域を既存のＡＶ Ｉｎｄｅｘファイルの一部とするため、ＡＶ Ｉｎｄｅｘファイルを管理するＦＥに対し、この領域を新規ｅｘｔｅｎｔとして追加して、ディスクに追記する。Ｓｋｉｐ ａｔｏｍによるサイズ調整は、ｅｘｔｅｎｔ追加処理を行った場合でも、ＱｕｉｃｋＴｉｍｅファイルとして矛盾が無いようにするために行っている。
このようにｅｘｔｅｎｔを追加されディスクに追記されたＦＥが、請求の範囲における「第３のデータ」に相当する。
以上の処理を行った直後の光ディスク１０６の記録状態を具体的に説明する。ＡＶ Ｉｎｄｅｘファイル記録処理開始直前に、ＲＡＭ１０２上には図３７の内容を持つＡＶ Ｉｎｄｅｘ管理テーブルが存在すると仮定する。ＡＶ Ｉｎｄｅｘファイル記録処理を行った結果、光ディスク１０６上には図５１（ａ）に示すように、領域４２４２に対し領域４２３０〜４２３９に示すデータが追記される。まず、領域４２４２の先頭の領域４２３０にはＭｏｖｉｅ ｄａｔａ ａｔｏｍのａｔｏｍ ｈｅａｄｅｒが記録される。領域４２３１〜４２３３には属性情報が記録され、それぞれ、ＳＨＲＰ０００１．ＭＯＶ４２０１を無効化するための属性情報、ＳＨＲＰ０００２．ＭＯＶ４２０２の代表画像データを置き換えるための属性情報、ＳＨＲＰ０００４．ＭＯＶ４２４１を新規登録するための属性情報である。領域４２３４および領域４２３５には、代表画像の変更されたＳＨＲＰ０００２．ＭＯＶ４２０２および新規登録されたＳＨＲＰ０００４．ＭＯＶ４２４１のタイトル文字列データが記録される。
また、領域４２３６、領域４２３７には、ＳＨＲＰ０００２．ＭＯＶ４２０２およびＳＨＲＰ０００４．ＭＯＶ４２４１の代表画像データがそれぞれ記録されている。領域４２３８、領域４２３９にはＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍとファイルの終端をセクタ境界に合わせるためのｓｋｉｐ ａｔｏｍがそれぞれ記録されている。ＡＶ Ｉｎｄｅｘファイルに関する既存の情報と最新の情報が領域４２０４および領域４２４２にそれぞれ記録され、ＡＶ ＩｎｄｅｘファイルのＦＥに対して領域４２４２を後続のｅｘｔｅｎｔとして追加したとき、ＡＶ Ｉｎｄｅｘファイルを読み出すと図５１（ｂ）の左から順に読み出されることになる。
＜インデックスファイル画面表示処理＞
本実施形態におけるインデックスファイル画面表示処理を図５２に沿って説明する。まず、ＡＶ Ｉｎｄｅｘファイルをｏｐｅｎし（ステップ４４０１）、Ｍｏｖｉｅ ａｔｏｍを読み出す（ステップ４４０２）。次に、後続する領域を読み出し、ファイルの末尾であれば（ステップ４４０３）、インデックス画面を表示（ステップ４４０４）して終了する。ファイルの末尾でなければＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍかどうかを判断する（ステップ４４０５）。Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍであれば、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍを読み出し（ステップ４４０６）、その情報に従い、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ、すなわち属性情報等のエントリデータを読み出す（ステップ４４０７）。ステップ４４０５において、読み出した領域がＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍ以外のａｔｏｍであった場合は、Ｍｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍが出てくるまで読み飛ばしを行う（ステップ４４０８）。
＜バリエーション＞
本実施形態でも、第２の実施形態と同様、図４７に示す変更対象のエントリデータの種別情報を記録することで、記録容量の無駄を削減することが可能である。
また、本実施形態では、エントリの削除を同一ｅｎｔｒｙ−ｎｕｍｂｅｒを持つエントリを追記することで行っているが、削除対象のエントリを管理するＦｒａｇｍｅｎｔｅｄ Ｍｏｖｉｅに対応するｅｘｔｅｎｔをＡＶ ＩｎｄｅｘファイルのＦＥから削除することで行ってもよい。ただし、ｓｅｑｕｅｎｃｅ−ｎｕｍｂｅｒの不連続を無視する必要がある。
また、本実施形態においてファイルの読み出しは必ず先頭からになるため、最近記録したエントリデータにアクセスする時間が長くなる傾向にある。これを避けるため、エントリデータが新しく記録した順に並ぶよう、ＡＶ ＩｎｄｅｘファイルのＦＥを設定してもよい。また、その際に、第１や第２の実施形態に説明するように、エントリデータへのアクセスが高速化されるよう、特定の属性のエントリデータのみ、重複して記録してもよいことは言うまでもない。
〔第４の実施形態〕
本発明の第４の実施形態について、図５３（ａ）〜図５９（ｂ）を用いて説明する。本実施形態は第１の実施形態に類似するが、Ｍｏｖｉｅ ａｔｏｍを含む記録済みのデータを、ＡＶ Ｉｎｄｅｘファイルに関するＦＥの操作により極力再利用する点が異なる。ここでは、ＡＶ Ｉｎｄｅｘファイルの更新処理に絞って説明する。
本実施形態の管理情報フォーマットは第１の実施形態と同一であるため、説明を省略する。
＜ＡＶ Ｉｎｄｅｘファイル更新時の処理（Ｍｏｖｉｅ ａｔｏｍ中のデータ量の変化がセクタの整数倍の場合）＞
まず、ＡＶ Ｉｎｄｅｘファイル更新によってＭｏｖｉｅ ａｔｏｍのサイズがセクタの整数倍でしか変化しない場合（ＡＶ Ｉｎｄｅｘファイル更新によってＭｏｖｉｅ ａｔｏｍのサイズが変化しない場合も含む）の、ＡＶ Ｉｎｄｅｘファイルの更新処理について図５３（ａ）（ｂ）および図５４を用いて説明する。
まず、更新前のＡＶ Ｉｎｄｅｘファイルのデータ構成を示す図５３（ａ）の説明を行う。ＡＶ ＩｎｄｅｘファイルはＭｏｖｉｅ ａｔｏｍ５１０１とａｔｏｍ ｈｅａｄｅｒ５１０２、属性情報５１０３等で構成されるＭｏｖｉｅ ｄａｔａ ａｔｏｍで構成される。ここでは、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍ中の属性情報５１０３の内容とデータ量を変更することを考える。このとき、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍのサイズが変わるため、ａｔｏｍ ｈｅａｄｅｒ５１０２のｓｉｚｅフィールドを書きかえる必要が発生する。さらに、属性情報５１０３のサイズが変わるため、属性情報５１０３のデータ量情報（Ｓａｍｐｌｅ ｓｉｚｅ ａｔｏｍ）や、後続するデータに対応するサンプルの位置情報（Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍ）を書きかえる必要がある。すなわち、Ｍｏｖｉｅ ａｔｏｍ５１０１の一部を書きかえる必要がある。このとき書きかえる必要のある部分を要変更部分５１０４と呼ぶことにする。なお、この変更によるサンプル数の変更はないため、通常Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍのデータ量の増減は発生しない。
図５３（ａ）に示すＡＶ Ｉｎｄｅｘファイルが、図５４に示すように光ディスク１０６上の領域５２２１に記録され、上記の属性情報５１０３、ａｔｏｍ ｈｅａｄｅｒ５１０２、要変更部分５１０４がディスク上のセクタ上に配置されたと仮定する。なお、データ５２０１およびデータ５２０２は、それぞれ要変更部分が格納されたセクタ列における、要変更部分５１０４の左方、右方のデータを示す。同様に、データ５２０３およびデータ５２０４は、それぞれａｔｏｍ ｈｅａｄｅｒ５１０２の左方、右方のデータを示す。また、データ５２０５、データ５２０６は、それぞれ属性情報５１０３の左方、右方のデータを示す。
変更処理により、変更後の属性情報５１１３、変更後のａｔｏｍ ｈｅａｄｅｒ５１１２、要変更部分５１０４の変更結果５１１４は、領域５２２４に以下に説明する形態で記録される。まず、変更後の属性情報５１１３に関しては、前記データ５２０５、属性情報５１１３、パディング５２０７、前記データ５２０６の順に記録される。パディング５２０７は、前記データ５２０５、属性情報５１１３、パディング５２０７、前記データ５２０６を合わせたデータ量をセクタサイズの整数倍にするための無効データである。
なお、パディング５２０７は、請求の範囲における「無意味データ」に相当する。
次に、変更後のａｔｏｍ ｈｅａｄｅｒ５１１２は、前記データ５２０３、ａｔｏｍ ｈｅａｄｅｒ５１１２、前記データ５２０４の順に記録される。ａｔｏｍ ｈｅａｄｅｒ５１１２はデータ量に変更が無いため、属性情報の記録において説明したようなパディングは必要ない。
次に、変更結果５１１４は、前記データ５２０７、変更結果５１１４、前記データ５２０２の順に記録する。前述のようにデータ量の変更はないため、パディングは必要無い。
最後に、図中のＲ１、Ｒ１０、Ｒ３、Ｒ９、Ｒ５、Ｒ６、Ｒ８の順に読み出されるようにＡＶ ＩｎｄｅｘファイルのＦＥを構成して追記する。
このように再構成されて追記されたＦＥが、請求の範囲における「第３のデータ」に相当する。
以上の処理により、ＡＶ Ｉｎｄｅｘファイルが図５３（ｂ）のように書きかえられることになる。なお、ここでは、属性情報を変更の対象としたが、サムネイル等他のエントリデータについても同様である。
上記のＡＶ Ｉｎｄｅｘファイル更新処理を行うことで、変更に伴う記録容量の無駄を最小限に抑えることが可能になる。
＜ＡＶ Ｉｎｄｅｘファイル更新時の処理（Ｍｏｖｉｅ ａｔｏｍ中のデータ量の変化がセクタの整数倍でない場合）＞
次に、ＡＶ Ｉｎｄｅｘファイル更新によってＭｏｖｉｅ ａｔｏｍのサイズがセクタの整数倍以外で変化する場合の、ＡＶ Ｉｎｄｅｘファイルの更新処理について図５５（ａ）（ｂ）および図５６を用いて説明する。
更新前のＡＶ Ｉｎｄｅｘファイルのデータ構成を図５５（ａ）に示すが、図５３（ａ）と同一であるため、説明を省略する。このＡＶ Ｉｎｄｅｘファイルに対し属性情報等エントリデータの追加を行うことを考える。追加によって、Ｍｏｖｉｅ ａｔｏｍ５１０１の管理するサンプルの数が増加し、Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍのエントリ数が増加、すなわち管理情報の追加が発生する。それに伴い、上位のａｔｏｍのａｔｏｍ ｈｅａｄｅｒのｓｉｚｅフィールドを更新する必要がある。また、エントリデータの追加によって、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍのデータ量が増加するため、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍのａｔｏｍ ｈｅａｄｅｒ中のｓｉｚｅフィールドを更新する必要がある。
図５５（ａ）に示すＡＶ Ｉｎｄｅｘファイルが、図５６に示すように光ディスク１０６上の領域５２２１に記録され、Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍのエントリ数増加に伴う追加管理情報５３０３の挿入位置がデータ追加箇所５３０１であると仮定する。なお、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍのａｔｏｍ ｈｅａｄｅｒ等のデータ量の変わらないものについては、図５４と同様であるため省略する。なお、データ５３１１およびデータ５３１３は、それぞれデータ追加箇所５３０１の含まれるセクタにおける、データ追加箇所５３０１の左方、右方のデータを示す。
変更処理により、前記データ５３１１、前記データ５３１３、追加管理情報５３０３および追加エントリデータ５３０２は、以下に説明する形態で記録される。まず、前記データ５３１１、追加管理情報５３０３、前記データ５３１３、データ５３１４の順にセクタの先頭から記録される。また追加エントリデータ５３０２も、別のセクタ列に記録される。なお、データ５３１４は、前記データ５３１３の末尾からセクタの末尾までに存在する無意味データである。最後に、図５７（ａ）に示すように、Ｒ１１、Ｒ１４、Ｒ１３、Ｒ１５の順にＡＶ ＩｎｄｅｘファイルのＦＥを構成して追記する。このとき、データ５３１４は無意味データであり、このＡＶ Ｉｎｄｅｘファイルを先頭から解釈した場合、正しく解釈できない。それを避けるため、それらの無意味データを無効化する情報を光ディスク１０６に記録する。具体的には、ＳＫＩＰ００００．ＤＡＴというファイルを作成し、それらのデータのＡＶ Ｉｎｄｅｘファイル先頭からのアドレスとバイト数を記録する。
ＡＶ Ｉｎｄｅｘの読み出し時には、直前にＳＫＩＰ００００．ＤＡＴを読み出し、その情報に基づき、ＡＶ Ｉｎｄｅｘファイルを解釈する。
以上のような更新処理により、ＡＶ Ｉｎｄｅｘファイル更新に伴うＭｏｖｉｅ ａｔｏｍ中のデータの重複記録を最小限にすることができる。
＜バリエーション＞
本実施形態では、無意味データも含め１個のファイルにまとめているが、図５７（ｂ）に示すように、複数のファイルで管理してもよい。すなわち、Ｒ１１とデータ５３１１、追加管理情報５３０３、データ５３１３を１個の部分ＡＶ Ｉｎｄｅｘファイル５３２１、Ｒ１３と追加エントリデータ５３０２を１個の部分ＡＶ Ｉｎｄｅｘファイル５３２４として管理する。部分ＡＶ Ｉｎｄｅｘファイル５３２１と部分ＡＶ Ｉｎｄｅｘファイル５３２４を連続して読み出すことで、ＲＡＭ１０２上でＡＶ Ｉｎｄｅｘファイルを復元することになる。複数のファイル間の読み出し順を管理する方法としては、次のものが考えられる。例えば、最新のＡＶ Ｉｎｄｅｘファイルを構成するファイルについては、読み出し順にＡＶＩＦ００００１．ＭＯＳ、ＡＶＩＦ０００２．ＭＯＳのようにファイル名で順序がわかるようにすることが考えられる。ここで拡張子をＭＯＳにしているのは、分割されているものであることを示すためである。また、ファイルの読み出し順を記録したファイルを作成し、ＡＶ Ｉｎｄｅｘ読み出し時は必ずそのファイルを参照することも考えられる。
また、追加管理情報５３０３を含む追加データを、別のファイルに追加位置を管理する情報と共に記録し、ＡＶ Ｉｎｄｅｘ読み出し時は必ずそのファイルを参照することも考えられる。
また、本実施形態では、追加管理情報のデータサイズがセクタの整数倍に満たないデータであった場合に、パディングを挿入しているが、そのパディングに、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるａｔｏｍを用いてもよい。図５８を用いて説明する。なお、上述の説明と同一の符号をつけているものは、上述と同一の意味を持つため、説明を省略する。更新処理の際、まず、データ追加箇所５３０１の右方に、パディングを挿入可能な個所、具体的にはａｔｏｍの境界を探す。最初に見つかった個所をパディング挿入可能個所５３２０とする。また、データ追加箇所５３０１からパディング挿入可能個所５３２０までのデータをデータ５３２１、パディング挿入可能個所５３２０から最初のセクタ境界までのデータを５３２２と定義する。
上記のデータから、データ５３１１、追加管理情報５３０３、データ５３２１、パディング５３２３、データ５３２２を順に記録する。ここでパディング５３２３は上記のデータがセクタの整数倍のデータ量になるように挿入され、前述のｓｋｉｐ ａｔｏｍのように、再生時に無視される無意味なａｔｏｍを用いる。最後に、Ｒ１１、Ｒ２３、Ｒ２２、Ｒ１６の順にＡＶ Ｉｎｄｅｘファイルが読み出されるよう、ＡＶ ＩｎｄｅｘファイルのＦＥを構成して追記する。このように、セクタの整数倍でないデータを追加する場合、ａｔｏｍの境界にサイズ調整用のａｔｏｍを挿入することで、データの追記を少なく抑え、なおかつＡＶ Ｉｎｄｅｘファイル単独で内容の解釈が可能となる。
また、本実施形態では、更新処理によってＭｏｖｉｅ ａｔｏｍ中のａｔｏｍサイズの増減が発生することを前提にしているが、サイズの増減するａｔｏｍ（例：ｅｄｉｔ ａｔｏｍ、ｓａｍｐｌｅ ａｔｏｍ）については、ＡＶ Ｉｎｄｅｘファイルの初期記録時に十分な大きさの領域を確保しておき、使用していない領域に関しては、図５９（ａ）に示すように、再生時に無視される無意味なａｔｏｍ（ここではｎｕｌｌ ａｔｏｍと呼ぶ）を記録することが考えられる。例えば、サンプル情報に追加によりＣｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍのデータ量が図５９（ａ）のｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍ５４０１からｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍ５４０３のように増加したときには、それに伴い、後続するｎｕｌｌ ａｔｏｍの先頭をファイルの後方にずらし、ｓｉｚｅを小さくすることで、上位のａｔｏｍのａｔｏｍ ｈｅａｄｅｒの変更やＭｏｖｉｅ ｄａｔａ ａｔｏｍの移動によるＣｈｕｎｋ ｏｆｆｓｅｔの変更、すなわち追記データの増加を防ぐことが可能になる。このような構成をとった場合、ＡＶ Ｉｎｄｅｘファイルの分割やＡＶ Ｉｎｄｅｘファイルの内容を解釈するための付加的な情報は不要である。さらに、サイズの増減するａｔｏｍの先頭５４０５およびｎｕｌｌ ａｔｏｍの末尾５４０６をセクタ境界に一致させることで、処理を単純化することが可能である。
また、ＡＶ Ｉｎｄｅｘファイルの初期記録時に使用していない領域に対して無意味なａｔｏｍを入れる代わりに、図５９（ｂ）に示すように、十分な数の空のサンプルを登録しておいてもよい。図５９（ｂ）の場合、ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍ５４１１のエントリ数を管理するフィールドであるｎｕｍｂｅｒ ｏｆ ｅｎｔｒｉｅｓ５４１２に、例えば１０００を記録しておき、エントリデータ５４１３からエントリデータ５４１４の間には１０００個のエントリを登録しておく。このとき、ＡＶ Ｉｎｄｅｘファイルへのエントリ追加に伴い、空のサンプルに実際のデータに関する情報を登録していく。サンプルが空であることを示す方法としては、サンプルのコーデック情報を無効なものに設定することが考えられる。あるいは、実際に管理しているｅｎｔｒｙ数に相当するａｔｏｍサイズより大きく、ａｔｏｍ ｈｅａｄｅｒでａｔｏｍサイズを管理することによって領域確保するようにしても良い。さらに、ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍの始終端をセクタ境界に一致させることで、処理を単純化することが可能である。このような構成をとった場合、ＡＶ Ｉｎｄｅｘファイルの分割やＡＶ Ｉｎｄｅｘファイルの内容を解釈するための付加的な情報は不要である。これら方法は、他のａｔｏｍ、例えば、ｅｄｉｔ ｌｉｓｔ ａｔｏｍに関しても適用可能なのは言うまでもない。
また、本実施形態に記してある更新処理は、ＡＶ ＩｎｄｅｘファイルだけでなくＡＶファイルにも適用可能なのは言うまでもない。
〔全実施形態を通じての補足〕
なお、上述の実施形態において記録媒体としてＤＶＤ−Ｒを用いているが、本発明は追記型の記録媒体であればＤＶＤ−Ｒ以外の記録媒体でも適用可能であることは言うまでもない。また、追記型でなくとも媒体の書き換え回数に制限のある記録媒体、例えばフラッシュＲＯＭにも適用可能であることは言うまでもない。したがって本実施形態においてはデータの管理単位としてセクタを用いているが、異なる記録媒体に適用した場合、セクタをそれぞれの記録媒体上のデータの管理／記録単位や管理／記録ユニットに読み替えることになる。
なお、上述の実施形態においてファイルシステムにＵＤＦを用いているが、本発明はＵＤＦに限定されるものではない。
また、上述の実施形態においてデータとしてオーディオやビデオといったＡＶデータを用いているが、本発明はそれに限定されるものではない。
なお、上述の実施形態においてファイルフォーマットとしてＱｕｉｃｋＴｉｍｅファイルフォーマットを用いているが、本発明はそれに限定されるものではない。
以上説明したように、本発明によれば、追記データを記録する際に、既存データの有効／無効を管理する情報を記録することによって、既存データの再利用が可能となり、記録容量の無駄を削減できる。
また、本発明によれば、追記データを記録する際に、既存データの属性に応じて既存データと同一データを記録することによって、特定の属性を持つデータを高速に読み出すことが可能となり、ユーザへのレスポンスを向上させることができる。
尚、発明を実施するための最良の形態の項においてなした具体的な実施態様または実施形態は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と次に記載する特許請求の範囲内で、いろいろと変更して実施することができるものである。
産業上の利用の可能性
本発明は、ハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して、映像データ、音声データを記録するデータ記録方法、データ記録装置、データ記録媒体、データ再生方法、データ再生装置に関するものである。追記型メディアにおいて、ＡＶファイル管理用のインデックスファイルを更新する際、記録容量の無駄が生じる。そこで、更新時に新規のインデックスファイルを作成し、既存のインデックスファイル中のサムネイル画像データを参照することで、無駄を削減すると同時に、属性情報は新規のインデックスファイルに格納することで、最低限必要な情報へのアクセスを高速化する。
【図面の簡単な説明】
図１は、本発明の実施形態におけるビデオディスクレコーダの概略構成を示すブロック図である。
図２（ａ）〜（ｃ）は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける管理情報とＡＶストリームとの関係を示す図面である。
図３は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ ａｔｏｍの概要を示す図面である。
図４は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ａｔｏｍの概要を示す図面である。
図５は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を示す図面である。
図６は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ ａｔｏｍの構成を示す図面である。
図７は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍの構成を示す図面である。
図８は、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍによるデータ管理の例を示す図面である。
図９は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構成を示す図面である。
図１０は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＥｄｉｔ ａｔｏｍの構成を示す図面である。
図１１（ａ）〜（ｃ）は、Ｅｄｉｔ ａｔｏｍによる再生範囲指定の例を示す図面である。
図１２は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＵｓｅｒ ｄａｔａ ａｔｏｍの構成を示す図面である。
図１３は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＦｒａｇｍｅｎｔｅｄ ｍｏｖｉｅの全体構成を示す図面である。
図１４は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ ｅｘｔｅｎｄｓ ａｔｏｍの構成を示す図面である。
図１５は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｅｘｔｅｎｄｓ ａｔｏｍの構成を示す図面である。
図１６は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ ｆｒａｇｍｅｎｔ ａｔｏｍの構成を示す図面である。
図１７は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ ｆｒａｇｍｅｎｔ ｈｅａｄｅｒ ａｔｏｍの構成を示す図面である。
図１８は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｆｒａｇｍｅｎｔ ａｔｏｍの構成を示す図面である。
図１９は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｆｒａｇｍｅｎｔ ｈｅａｄｅｒ ａｔｏｍの構成を示す図面である。
図２０は、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｆｒａｇｍｅｎｔ ｒｕｎ ａｔｏｍの構成を示す図面である。
図２１は、本発明の実施形態におけるＡＶストリームの構成を示す図面である。
図２２は、本発明の実施形態におけるＶＵの構造を示す図面である。
図２３は、本発明の実施形態におけるＱｕｉｃｋＴｉｍｅによるＡＶストリーム管理形態を示す図面である。
図２４は、本発明の実施形態におけるリファレンス・デバイス・モデルを示すブロック図である。
図２５（ａ）（ｂ）は、ＵＤＦにおける管理情報の関係を示す図面である。
図２６は、追記型記録媒体でのＵＤＦにおける管理情報の関係を示す図面である。
図２７は、本発明の第１の実施形態における、ＡＶ Ｉｎｄｅｘファイルの構成を示す図面である。
図２８は、本発明の第１の実施形態における属性情報の構成を示す図面である。
図２９は、本発明の第１の実施形態におけるｆｌａｇｓの構成を示す図面である。
図３０は、本発明の第１の実施形態における全体の処理の流れを示すフローチャートである。
図３１は、本発明の第１の実施形態におけるユーザ指示による各種処理の流れを示すフローチャートである。
図３２（ａ）（ｂ）は、それぞれ本発明の第１の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新前のディレクトリ／ファイル構成および記録媒体上の記録状態の例を示す図面である。
図３３は、本発明の第１の実施形態における、ディスク挿入直後のＡＶ Ｉｎｄｅｘ管理テーブルの例を示す図面である。
図３４（ａ）（ｂ）は、本発明の第１の実施形態における、録画処理直後の記録媒体上の記録状態の例を示す図面である。
図３５は、本発明の第１の実施形態における、録画直後のＡＶ Ｉｎｄｅｘ管理テーブルの例を示す図面である。
図３６は、本発明の第１の実施形態における、エントリ削除直後のＡＶ Ｉｎｄｅｘ管理テーブルの例を示す図面である。
図３７は、本発明の第１の実施形態における、エントリデータ変更直後のＡＶ Ｉｎｄｅｘ管理テーブルの例を示す図面である。
図３８は、本発明の第１の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新処理を示すフローチャートである。
図３９は、本発明の第１の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新後の記録媒体上の記録状態の例を示す図面である。
図４０は、本発明の第１の実施形態におけるＡＶ Ｉｎｄｅｘファイル読み出し処理を示すフローチャートである。
図４１は、本発明の第１の実施形態における属性情報の第２の構成を示す図面である。
図４２は、本発明の第２の実施形態において追加した管理情報の構成を示す図面である。
図４３は、本発明の第２の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新処理を示すフローチャートである。
図４４は、本発明の第２の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新後の記録媒体上の記録状態の例を示す図面である。
図４５（ａ）（ｂ）は、本発明の第２の実施形態におけるＡＶ Ｉｎｄｅｘファイルマージ前後の記録媒体上の記録状態の例を示す図面である。
図４６は、本発明の第２の実施形態におけるＡＶ Ｉｎｄｅｘファイル読み出し処理を示すフローチャートである。
図４７は、本発明の第２の実施形態におけるｆｌａｇｓの第２の構成を示す図面である。
図４８は、本発明の第３の実施形態における、ＡＶ Ｉｎｄｅｘファイルの構成を示す図面である。
図４９は、本発明の第３の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新前の記録媒体上の記録状態の例を示す図面である。
図５０は、本発明の第３の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新処理を示すフローチャートである。
図５１（ａ）（ｂ）は、本発明の第３の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新後の記録媒体上の記録状態の例を示す図面である。
図５２は、本発明の第３の実施形態におけるＡＶ Ｉｎｄｅｘファイル読み出し処理を示すフローチャートである。
図５３（ａ）（ｂ）は、本発明の第４の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新処理（Ｍｏｖｉｅ ａｔｏｍ中のデータ量の変化がセクタの整数倍の場合）を示す図面である。
図５４は、本発明の第４の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新（Ｍｏｖｉｅ ａｔｏｍ中のデータ量の変化がセクタの整数倍の場合）後の記録媒体上の記録状態の例を示す図面である。
図５５（ａ）（ｂ）は、本発明の第４の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新処理（Ｍｏｖｉｅ ａｔｏｍ中のデータ量の変化がセクタの整数倍でない場合）を示す図面である。
図５６は、本発明の第４の実施形態におけるＡＶ Ｉｎｄｅｘファイル更新（Ｍｏｖｉｅ ａｔｏｍ中のデータ量の変化がセクタの整数倍でない場合）後の記録媒体上の記録状態の例を示す図面である。
図５７（ａ）（ｂ）は、本発明の第４の実施形態におけるＡＶ Ｉｎｄｅｘファイルと領域の関係の例を示す図面である。
図５８は、本発明の第４の実施形態における第２の更新方法によるＡＶ Ｉｎｄｅｘファイル更新後の記録媒体上の記録状態の例を示す図面である。
図５９（ａ）（ｂ）は、本発明の第４の実施形態における第３の更新方法によるＡＶ Ｉｎｄｅｘファイル更新後の記録媒体上の記録状態の例を示す図面である。
図６０は、従来技術におけるインデックスファイルを示す図面である。

Claims (5)

1. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体の記録内容を、データ記録装置により変更するデータ記録方法であって、
   前記データ記録装置の見出しデータ作成手段が、変更後の記録内容に応じた新たな見出しデータを作成するステップと、
   前記データ記録装置の記録手段が、前記作成した新たな見出しデータを前記データ記録媒体に記録するステップとを含み、
   前記新たな見出しデータには、
   既に前記データ記録媒体に記録されている旧い見出しデータに含まれ、かつ、内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、
   既に前記データ記録媒体に記録されている旧い見出しデータに含まれ、かつ、内容を変更する必要のない見出し情報のうちの他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とを含め、
   前記新たな見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報を含めるかどうかは、当該見出し情報の属性に基づいて定められるデータ記録方法。
2. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体の記録内容を変更するデータ記録装置であって、
   前記データ記録媒体の記録内容を変更する際に、変更後の記録内容に応じた新たな見出しデータを作成する見出しデータ作成手段と、
   前記作成された新たな見出しデータを前記データ記録媒体に記録する記録手段とを備え、
   前記見出しデータ作成手段は、
   既に前記データ記録媒体に記録されている旧い見出しデータに含まれ、かつ、内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、
   既に前記データ記録媒体に記録されている旧い見出しデータに含まれ、かつ、内容を変更する必要のない見出し情報のうちの他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とを、前記新たな見出しデータに含め、
   前記新たな見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報を含めるかどうかは、当該見出し情報の属性に基づいて定めるデータ記録装置。
3. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体であって、
   記録内容を変更する前に記録された旧い見出しデータと、
   記録内容を変更した後に記録された新しい見出しデータとを含み、
   前記旧い見出しデータに含まれ、かつ、記録内容の変更後においても内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とが、前記新しい見出しデータに含まれ、
   前記新しい見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報が含まれるかどうかは、当該見出し情報の属性に基づいて定まっているデータ記録媒体。
4. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体の記録内容を、データ再生装置により再生するデータ再生方法であって、
   前記データ記録媒体には、記録内容を変更する前に記録された旧い見出しデータと、記録内容を変更した後に記録された新しい見出しデータとが含まれ、
   前記新しい見出しデータには、前記旧い見出しデータに含まれ、かつ、記録内容の変更 後においても内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とが含まれ、
   前記新しい見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報が含まれるかどうかは、当該見出し情報の属性に基づいて定まっており、
   前記データ再生装置の再生手段が、前記新しい見出しデータに含まれる参照情報に基づいて、前記旧い見出しデータから見出し情報を取得するステップと、
   前記データ再生装置の再生手段が、前記新しい見出しデータに含まれる見出し情報を取得するステップとを含むデータ再生方法。
5. 本体データと、その本体データに関する見出し情報を含んだ見出しデータとが記録されているデータ記録媒体の記録内容を再生するデータ再生装置であって、
   前記データ記録媒体には、記録内容を変更する前に記録された旧い見出しデータと、記録内容を変更した後に記録された新しい見出しデータとが含まれ、
   前記新しい見出しデータには、前記旧い見出しデータに含まれ、かつ、記録内容の変更後においても内容を変更する必要のない見出し情報のうちの一部のものに関して、前記旧い見出しデータに含まれる見出し情報を参照するための参照情報と、他の一部のものに関して、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報とが含まれ、
   前記新しい見出しデータに、前記旧い見出しデータに含まれる見出し情報と同一の見出し情報が含まれるかどうかは、当該見出し情報の属性に基づいて定まっており、
   前記データ記録媒体の記録内容を再生する際に、前記新しい見出しデータに含まれる参照情報に基づいて、前記旧い見出しデータから見出し情報を取得するとともに、前記新しい見出しデータに含まれる見出し情報を取得する再生手段を備えるデータ再生装置。

Images