(57)【要約】  【課題】  記録媒体上のファイルの消去の判断を高速に行うことを可能とする  【解決手段】  エントリプロパティに含まれるエントリプロパティ２は、ノーマルとシステムの識別を行う。ノーマルとは、実データのエントリを意味し、システムとは、フラグの定義が記述されているエントリを意味する。フラグがファイルの属性情報を示す。フラグが機器またはユーザによって定義される。エントリプロパティ３は、エントリに関して、有効、無効の識別を行い、エントリプロパティ４は、エントリに登録されたファイルが他のファイルを参照しているかどうかを示す。リファードカウンタは、ファイルが別のファイルから参照されている数を示す。リファリングファイルリストは、ファイルが別のファイルから参照されている場合、その参照元を示す。これらの情報によってファイル間の参照関係が記述できる。  【選択図】  図７
2004355800.tif 000002
【特許請求の範囲】
【請求項１】
記録媒体に記録された複数のファイルのそれぞれに係るインデックスデータを上記複数のファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、上記インデックスファイルを記録媒体に記録するようにした記録装置であって、
上記インデックスデータに上記複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした記録装置。
【請求項２】
記録媒体に記録された複数のファイルのそれぞれに係るインデックスデータを上記複数のファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、上記インデックスファイルを記録媒体に記録するようにした記録方法であって、
上記インデックスデータに上記複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした記録方法。
【請求項３】
記録媒体に記録された複数のファイルファイルのそれぞれに係るインデックスデータを上記複数のファイルファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、上記インデックスファイルを記録媒体に記録する記録方法であって、
上記インデックスデータに上記複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした記録方法をコンピュータに実行させるためのプログラム。
【請求項４】
記録媒体に記録された複数のファイルファイルのそれぞれに係るインデックスデータを上記複数のファイルファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、上記インデックスファイルを記録媒体に記録する記録方法であって、
上記インデックスデータに上記複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした記録方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体。
【請求項５】
被写体の像を撮影し得られた画像信号を記録媒体に記録する撮像装置において、
記録媒体に記録された複数のファイルファイルのそれぞれに係るインデックスデータを上記複数のファイルファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、上記インデックスファイルを記録媒体に記録するようにしたインデックス記録装置を備え、
上記インデックスデータに上記複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした撮像装置。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、記録媒体に映像データやオーディオデータなどを記録する記録装置において、特に、記録媒体を区別する情報を所定の形式で記録媒体に記録する記録装置に関する。この発明は、このような記録装置に用いられる記録方法、プログラムおよび記録媒体に関する。さらに、この発明は、このような記録装置を備えた電子カメラに関する。
【背景技術】
【０００２】
例えば、光ディスク記録装置とビデオカメラを一体型の構成とした携帯型ビデオカメラの構成が提案されている。かかる記録装置において、幾つかの場面を記録した複数のデータが光ディスクにファイルとして記録される。
【０００３】
また、このような記録装置に、例えば、液晶表示パネルや有機エレクトロルミネセンス表示パネルなどの表示部やスピーカなどの音発生部を備えることにより、記録したデータを再生・編集する機能も併せ持つ記録再生装置が知られている。
【０００４】
ユーザが記録媒体に記録されているデータ中の所望のデータ例えば画像データを検索する処理を容易とするために、記録されている複数の画像データの一部の画像、音声等を管理情報（インデックスファイルと称する）としてディスク状記録媒体の所定の位置例えば最内周領域に記録することが提案されている。
【０００５】
インデックスファイルは、記録媒体に記録された１以上のファイルの内容を識別するための情報を纏めたファイルである。インデックスファイルには、属性情報と抜粋情報が含まれる。一例として、インデックスファイルは、例えば、プロパティ、テキスト、サムネイル、イントロの４種類のデータが収容される。プロパティは、タイトルおよび各ＡＶファイルの属性を示すデータである。また、テキストは、各ＡＶファイルに係るタイトルの文字列を示すデータである。サムネイルおよびイントロのデータは、ファイルの代表的な１画面および代表的な数秒程度のオーディオデータである。
【発明の開示】
【発明が解決しようとする課題】
【０００６】
インデックスファイルに登録されているファイルを消去する場合、他のファイルから参照されいるファイルを消去することができない。しかしながら、ファイルの参照関係を調べるためには、全ての実際のファイルを解析する必要がある。この解析のために時間がかかり、ファイルの消去動作に時間がかかる問題が生じる。
【０００７】
したがって、この発明の目的は、ファイルを消去する処理をより高速とすることが可能な記録方法および記録装置を提供することにある。また、この発明の目的は、このような記録方法をコンピュータに実行させるためのプログラムおよび該プログラムを記録したコンピュータ読み取り可能な記録媒体を提供することにある。さらに、この発明は、このような記録方法を採用する撮像装置を提供するとにある。
【課題を解決するための手段】
【０００８】
上述した課題を解決するために、この発明の第１の態様は、記録媒体に記録された複数のファイルのそれぞれに係るインデックスデータを複数のファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、インデックスファイルを記録媒体に記録するようにした記録装置であって、
インデックスデータに複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした記録装置である。
【０００９】
この発明の第２の態様は、記録媒体に記録された複数のファイルのそれぞれに係るインデックスデータを複数のファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、インデックスファイルを記録媒体に記録するようにした記録方法であって、
インデックスデータに複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした記録方法である。
【００１０】
この発明の第３の態様は、記録媒体に記録された複数のファイルファイルのそれぞれに係るインデックスデータを複数のファイルファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、インデックスファイルを記録媒体に記録する記録方法であって、
インデックスデータに複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした記録方法をコンピュータに実行させるためのプログラムである。
【００１１】
この発明の第４の態様は、記録媒体に記録された複数のファイルファイルのそれぞれに係るインデックスデータを複数のファイルファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、インデックスファイルを記録媒体に記録する記録方法であって、
インデックスデータに複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした記録方法をコンピュータに実行させるためのプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００１２】
この発明の第５の態様は、被写体の像を撮影し得られた画像信号を記録媒体に記録する撮像装置において、
記録媒体に記録された複数のファイルファイルのそれぞれに係るインデックスデータを複数のファイルファイルの実データのそれぞれと関連付けて所定の形式で収容することによってインデックスファイルを生成し、インデックスファイルを記録媒体に記録するようにしたインデックス記録装置を備え、
インデックスデータに複数のファイルの参照関係を示す、他のファイルから参照されている数、そのファイルを参照しているファイルを特定する情報、そのファイルが他のファイルを参照しているか否かの情報およびそのファイルが有効か無効かの情報とを含む参照関係データを収容するようにした撮像装置である。
【発明の効果】
【００１３】
この発明による記録装置、記録方法、プログラム、該プログラムを記録した記録媒体、および、該記録装置を備える撮像装置では、ファイルの参照関係を示す情報がエントリ管理情報に含まれているので、実際のファイルにアクセスすることなく、ファイルの参照関係が管理できるので、消去の可否を高速に判断することができ、ユーザに対する警告の提示も高速になしうる。さらに、エントリの有効／無効の情報を持つことによって、ファイル消去時に対応するエントリを消去しないで良く、記録媒体の書き換えが最小限の領域に限定でき、高速な消去処理を行うことができる。また、この有効／無効の情報に基づいて、消去扱い（無効処理）のエントリを検出し、検出したエントリに追加するエントリを上書きすることによって、エントリのデータおよびその管理領域を変更する処理を不要とでき、高速のエントリ追加処理が可能となる。
【発明を実施するための最良の形態】
【００１４】
以下、この発明の実施形態について図面に基づいて説明する。なお、各図において、同一の構成については、その説明を省略することがある。図１は、この発明を適用できるディジタル記録再生装置の一構成例を示すブロック図である。ディジタル記録再生装置は、ビデオ符号器１１、オーディオ符号器１２、ビデオ復号器１３、オーディオ復号器１４、ファイル生成器１５、ファイル復号器１６、メモリ１７、メモリ２０、メモリコントローラ１８、システム制御マイコン１９、エラー訂正符号／復号器２１、ドライブ制御マイコン２２、データ変復調器２３、磁界変調ドライバ２４、操作部２６、サーボ回路３０、スピンドルモータ３１、磁界ヘッド３２および光ピックアップ３３によって構成される。記録媒体（ここでは、光磁気ディスク）４０に対しては、ディジタルデータが磁界ヘッド３２および光ピックアップ３３によって磁界変調によって記録される。また、記録されたデータが光ピックアップ３３によって記録媒体４０から読み出される。
【００１５】
ビデオ信号は、ビデオ入力端子からビデオ符号器１１に供給され、圧縮符号化される。オーディオ信号は、オーディオ入力端子からオーディオ符号器１２に供給され、圧縮符号化される。ビデオ符号器１１およびオーディオ符号器１２の各出力がエレメンタリストームと呼ばれる。
【００１６】
本実施形態では、ディジタル記録再生装置は、カメラ一体型ディジタル記録再生装置に備えられている。ビデオ信号は、ビデオカメラで撮影された画像が供給され、ビデオカメラは、光学系によって被写体の撮像光がCCD(Charge Coupled Device)などの撮像素子に供給されることによってビデオ信号を生成する。オーディオ信号は、マイクロフォンで集音された音声が供給される。
【００１７】
ビデオ符号器１１は、例えば、圧縮符号化がＭＰＥＧの場合には、Ａ／Ｄ変換器、フォーマット変換部、画像並替部、減算器、ＤＣＴ部、量子化部、可変長符号化部、バッファメモリ、レート制御部、逆量子化部、逆ＤＣＴ部、加算部、ビデオメモリ、動き補償予測部およびスイッチの各電子回路によって構成される。
【００１８】
ビデオ符号器１１に供給されたビデオ信号は、Ａ／Ｄ変換器でディジタル化された後に、フォーマット変換部で符号化で用いる空間解像度に変換され、画像並替部に出力される。画像並替部は、ピクチャの順序を符号化処理に適した順に並び替える。すなわち、ＩピクチャおよびＰピクチャを先に符号化し、その後、Ｂピクチャを符号化するのに適した順に並び替える。
【００１９】
画面並替部の出力は、減算部を介してＤＣＴ部に入力され、ＤＣＴ符号化が行われる。ＤＣＴ部の出力は、量子化部に入力され、所定のビット数で量子化される。量子化部の出力は、可変長符号化部および逆量子化部に入力される。可変長符号化部は、出現頻度がより高いデータにより短いコードを割り当てる可変長符号、例えば、ハフマン符号で符号化され、符号化データは、メモリのバッファメモリに出力される。バッファメモリは、一定レートで符号化データをビデオ符号器の出力として出力する。また、レート制御部は、可変長符号化部で発生する符号量が可変であるため、バッファメモリを監視することによって所定のビットレートを保つように、量子化部の量子化動作を制御する。
【００２０】
一方、ＩピクチャおよびＰピクチャの場合は、動き補償予測部で参照画面として使用されるため、量子化部から逆量子化部に入力された信号は、逆量子化された後に逆ＤＣＴ部に入力され、逆ＤＣＴが行われる。逆ＤＣＴ部の出力は、加算部で動き補償予測部の出力と加算され、ビデオメモリに入力される。ビデオメモリの出力は、動き補償予測部に入力される。動き補償予測部は、前方向予測、後方向予測および両方向予測を行い、加算部および減算部に出力する。これら逆量子化部、逆ＤＣＴ部、加算部、ビデオメモリおよび動き補償予測部は、ローカル復号部を構成し、ビデオ復号器と同一のビデオ信号が復元される。
【００２１】
減算部は、画像並替部の出力と動き補償予測部の出力との間で減算を行い、ビデオ信号とローカル復号部で復号された復号ビデオ信号との間の予測誤差を形成する。フレーム内符号化（Ｉピクチャ）の場合では、スイッチにより、減算部は、減算処理を行わず、単にデータが通過する。
【００２２】
図１に戻って説明すると、オーディオ符号器１２は、例えば、ＭＰＥＧ／Ａｕｄｉｏレイヤ１／レイヤ２の場合では、サブバンド符号化部および適応量子化ビット割り当て部などの各電子回路を備えて構成される。オーディオ信号は、サブバンド符号化部で３２帯域のサブバンド信号に分割され、適応量子化ビット割り当て部で心理聴覚重み付けに従って量子化され、ビットストリームに形成された後に出力される。
【００２３】
なお、符号化品質を向上させるために、ＭＰＥＧ／Ａｕｄｉｏレイヤ３の場合では、さらに、適応ブロック長変形離散コサイン変換部、折り返し歪み削減バタフライ部、非線形量子化部および可変長符号化部などが導入される。
【００２４】
ビデオ符号器１１の出力およびオーディオ符号器１２の出力がファイル生成器１５に供給される。ファイル生成器１５は、特定のハードウェア構成を使用することなく動画、音声およびテキストなどを同期して再生することができるコンピュータソフトウェアにより扱うことができるファイル構造を持つように、ビデオエレメンタリストリームおよびオーディオエレメンタリストームのデータ構造を変換する。このようなソフトウェアは、例えば、QuickTime （以下、適宜「ＱＴ」と略記する。）が知られている。以下、ＱＴを使用する場合について説明する。ファイル生成器１５は、符号化ビデオデータと符号化オーディオデータとを多重化する。ファイル生成器１５は、システム制御マイコン１９によって制御される。
【００２５】
ファイル生成器１５の出力であるQuickTime ムービーファイルは、メモリコントローラ１８を介してメモリ１７に順次に書き込まれる。メモリコントローラ１８は、システム制御マイコン１９から記録媒体４０へのデータ書き込みが要求されると、メモリ１７からQuickTime ムービーファイルを読み出す。
【００２６】
ここで、QuickTime ムービー符号化の転送レートは、記録媒体４０への書き込みデータの転送レートより低い転送レート、例えば、１／２に設定される。よって、QuickTime ムービーファイルが連続的にメモリ１７に書き込まれるのに対し、メモリ１７からのQuickTime ムービーファイルの読み出しは、メモリ１７がオーバーフローまたはアンダーフローしないように、システム制御マイコン１９によって監視されながら間欠的に行われる。
【００２７】
メモリ１７から読み出されたQuickTime ムービーファイルは、メモリコントローラ１８からエラー訂正符号／復号器２１に供給される。エラー訂正符号／復号器２１は、このQuickTime ムービーファイルを一旦メモリ２０に書き込み、インターリーブ（interleaved
）およびエラー訂正符号の冗長データの生成を行う。エラー訂正符号／復号器２１は、冗長データが付加されたデータをメモリ２０から読み出し、これをデータ変復調器２３に供給する。
【００２８】
データ変復調器２３は、デジタルデータを記録媒体４０に記録する際に、再生時のクロック抽出を容易とし、符号間干渉などの問題が生じないように、データを変調する。例えば、（１，７）ＲＬＬ（run length limited）符号やトレリス符号などを利用することができる。
【００２９】
データ変復調器２３の出力は、磁界変調ドライバ２４および光ピックアップ３３に供給される。磁界変調ドライバ２４は、入力信号に応じて、磁界ヘッド３２を駆動して記録媒体４０に磁界を印加する。光ピックアップ３３は、入力信号に応じて記録用のレーザビームを記録媒体４０に照射する。磁界変調方式によって、記録媒体４０にデータが記録される。
【００３０】
記録媒体４０は、ディスク状の記録媒体であり、例えば、光磁気ディスク（ＭＯ、magneto-optical disk）てある。光磁気ディスク以外に、相変化型ディスク、磁気ディスクなどの書き換え可能なディスク状記録媒体を使用できる。
【００３１】
ここで、後述するインデックスファイルは、読み出しの容易性の観点から、ディスク状の記録媒体における実質的な最内周、例えば、リードインに続く記録部分に記録されることが好ましい。
【００３２】
本実施形態では、ＭＯ、例えば、直径約４ｃｍ、直径約５ｃｍ、直径約６．５ｃｍまたは直径約８ｃｍなどの比較的小径なディスクが使用される。記録媒体４０は、モータ３１によって、線速度一定（ＣＬＶ）、角速度一定（ＣＡＶ）またはゾーンＣＬＶ（ＺＣＬＶ）で回転される。
【００３３】
ドライブ制御マイコン２２は、システム制御マイコン１９の要求に応じて、サーボ回路３０に信号を出力する。サーボ回路３０は、この出力に応じて、スピンドルモータ３１および光ピックアップ３３を制御することによって、ドライブ全体を制御する。例えば、サーボ回路３０は、光ピックアップ３３に対し、記録媒体４０の径方向の移動サーボ、トラッキングサーボおよびフォーカスサーボを行い、スピンドルモータ３１の回転を制御する。また、システム制御マイコン１９には、ユーザが所定の指示を入力する操作部２６が接続される。
【００３４】
再生の際には、光ピックアップ３３は、再生用の出力でレーザビームを記録媒体４０に照射し、その反射光を光ピックアップ３３内の光検出器で受光することによって、再生信号を得る。この場合において、ドライブ制御マイコン２２は、光ピックアップ３３内の光検出器の出力信号からトラッキングエラーおよびフォーカスエラーを検出し、読み取りのレーザビームがトラック上に位置し、トラック上に合焦するように、サーボ回路３０によって光ピックアップ３３を制御する。さらに、ドライブ制御マイコン２２は、記録媒体４０上における所望の位置のデータを再生するために、光ピックアップの径方向における移動も制御する。所望の位置は、記録時と同様にシステム制御マイコン１９によって、ドライブ制御マイコン２２に信号が与えられ、決定される。
【００３５】
光ピックアップ３３の再生信号は、データ変復調器２３に供給され、復調される。復調されたデータは、エラー訂正符号／復号器２１に供給され、再生データを一旦メモリ２０に格納し、デインターリーブ（deinterleaved ）およびエラー訂正が行われる、エラー訂正後のQuickTime ムービーファイルは、メモリコントローラ１８を介してメモリ１７に格納される。
【００３６】
メモリ１７に格納されたQuickTime ムービーファイルは、システム制御マイコン１９の要求に応じて、ファイル復号器１６に出力される。システム制御マイコン１９は、ビデオ信号およびオーディオ信号を連続再生するために、記録媒体４０の再生信号がメモリ１７に格納されるデータ量と、メモリ１７から読み出されてファイル復号器１６に供給されるデータ量とを監視することによって、メモリ１７がオーバーフローまたはアンダーフローしないようにメモリコントローラ１８およびドライブ制御マイコン２２を制御する。こうして、システム制御マイコン１９は、記録媒体４０から間欠的にデータを読み出す。
【００３７】
ファイル復号器１６は、システム制御マイコン１９の制御下で、QuickTime ムービーファイルをビデオエレメンタリストリームとオーディオエレメンタリファイルとに分離する。ビデオエレメンタリストリームは、ビデオ復号器１３に供給され、圧縮符号化の復号が行われてビデオ出力となってビデオ出力端子から出力される。オーディオエレメンタリストリームは、オーディオ復号器１４に供給され、圧縮符号化の復号が行われてオーディオ出力となってオーディオ出力端子から出力される。ここで、ファイル復号器１６は、ビデオエレメンタリストリームとオーディオエレメンタリストリームとが同期するように出力する。
【００３８】
ビデオ復号器１３は、例えば、ＭＰＥＧの場合では、メモリのバッファメモリ、可変長符号復号部、逆量子化部、逆ＤＣＴ部、加算部、ビデオメモリ、動き補償予測部、画面並替部およびディジタル／アナログ変換器（以下、「Ｄ／Ａ」と略記する。）の各電子回路を備えて構成される。ビデオエレメンタリストームは、一旦バッファメモリに蓄積され、可変長復号部に入力される。可変長復号部は、マクロブロック符号化情報が復号され、予測モード、動きベクトル、量子化情報および量子化ＤＣＴ係数が分離される。量子化ＤＣＴ係数は、逆量子化部でＤＣＴ係数に復元され、逆ＤＣＴ部で画素空間データに変換される。加算部は、逆量子化部の出力と動き補償予測部の出力とを加算するが、Ｉピクチャを復号する場合には、加算しない。画面内のすべてのマクロブロックが復号され、画面は、画面並替部で元の入力順序に並べ替えられて、Ｄ／Ａでアナログ信号に変換されて出力される。また、加算器の出力は、ＩピクチャおよびＰピクチャの場合には、その後の復号処理で参照画面として使用されるため、ビデオメモリに蓄積され、動き補償予測部に出力される。
【００３９】
オーディオ復号器１４は、例えば、ＭＰＥＧ／Ａｕｄｉｏレイヤ１／レイヤ２の場合では、ビットストリーム分解部、逆量子化部およびサブバンド合成フィルタバンク部などの各電子回路を備えて構成される。入力されたオーディオエレメンタリストリームは、ビットストリーム分解部でヘッダと補助情報と量子化サブバンド信号とに分離され、量子化サブバンド信号は、逆量子化部で割り当てられたビット数で逆量子化され、サブバンド合成フィルタバンクで合成された後に、出力される。
【００４０】
図２は、カメラ一体型ディジタル記録再生装置の外形を示す模式図である。カメラ一体型ディジタル記録再生装置５０は、本体５１、レンズ部５２、集音マイク５３および表示パネル５４を備えて構成される。図１に示すディジタル記録再生装置は、本体５１内に収められる。ビデオ信号は、レンズ部５２の光学系を介して被写体の撮像光が撮像素子に供給され、生成される。オーディオ信号は、集音マイク５３で生成される。表示パネル５４は、再生画像や操作内容に対応する表示などが行われる。表示パネル５４は、液晶表示と圧電素子とを備えて構成される。ユーザは、表示部分をポインティングデバイス５５で押圧することによって、所望の操作を入力する。
【００４１】
表示パネル５４は、撮影時のモニタ画像を表示したり、記録媒体の再生画像を表示するのに使用される。さらに、インデックスファイルとして記録されている画像情報例えばサムネイル画像（Thumbnail Picture ）が表示パネル５４に表示される。具体的には、複数のサムネイルが表示パネル５４に整列して表示される。表示パネル５４に一度に表示できるサムネイルの枚数は、制約されるので、表示パネル５４上に表示されるスクロールキーまたは本体５１に設けられているキー操作によって、サムネイルのスクロールが可能とされている。そして、サムネイルの内で所望のものポインティングデバイス５５またはカーソルによって指定することによって、指定されたサムネイルに対応する画像データとオーディオデータを扱うファイルが再生されるようになされている。
【００４２】
このようなカメラ一体型ディジタル記録再生装置５０は、記録媒体をフォーマットする際や撮影後などにファイルの抜粋情報を生成する。本実施形態では、インデックスファイルは、例えば、QuickTime ムービーファイルの形式で生成される。QuickTime ムービーファイルの形式で生成することによって、映像データやオーディオデータなどの複数の実データと、ファイルの抜粋情報とを同じ形式で記録することができ、記録再生装置は、すべてをＱＴで再生することができる。
【００４３】
以下、QuickTime ムービーファイルについて概説する。ＱＴは、各種データを時間軸に沿って管理するソフトウェアであり、特殊なハードウェアを用いずに動画や音声やテキストなどを同期して再生するためのＯＳ拡張機能である。ＱＴは、例えば、「INSIDE  MACINTOSH :QuickTime（日本語版）（アジソンウエスレス）」などに開示されている。
【００４４】
ＱＴムービーリソースの基本的なデータユニットは、アトム（atom）と呼ばれ、各アトムは、そのデータとともに、サイズおよびタイプ情報を含んでいる。また、ＱＴでは、データの最小単位がサンプル（sample）として扱われ、サンプルの集合としてチャンク（chunk ）が定義される。
【００４５】
図３は、QuickTime ムービーファイルの一構成例を示す図である。図４は、ビデオ・メディア情報アトムの一構成例を示す図である。図４は、図３におけるビデオ・メディア情報アトムをより詳細に示した図となっており、トラックがビデオ情報の場合について示している。
【００４６】
図３および図４において、QuickTime ムービーファイルは、大きく２つの部分、ムービーアトム（movie atom）１０１およびムービー・データ・アトム（movie data atom ）１０２から構成される。ムービーアトム１０１は、そのファイルを再生するために必要な情報や実データを参照するために必要な情報を格納する部分である。ムービー・データ・アトム１０２は、ビデオデータやオーディオデータなどの実データを格納する部分である。
【００４７】
ムービーアトム１０１は、ムービー全体に関する情報を収容するムービー・ヘッダ・アトム（movie header atom ）１１１、クリッピング領域を指定するムービー・クリッピング・アトム（movie clipping atom ）１１２、ユーザ定義データアトム１１３、および、１または複数のトラックアトム（track atom）１１４などを含む。
【００４８】
トラックアトム１１４は、ムービー内の１つのトラックごとに用意される。トラックアトム１１４は、トラック・ヘッダ・アトム（track header atom ）１３１、トラック・クリッピング・アトム（track clipping atom ）１３２、トラック・マット・アトム（track matte atom）１３３、エデットアトム（edit atom ）１３４およびメディアアトム（media atom）１３５に、ムービー・データ・アトム１０２の個々のデータに関する情報を記述する。図３では、１つのビデオムービーのトラックアトム１１４-1が示され、他のトラックアトムは、省略されている。
【００４９】
メディアアトム１３５は、メディア・ヘッダ・アトム（media header atom ）１４４、メディア情報アトム（media information atom）（図３および図４では、ビデオ・メディア情報アトム１４５）、および、メディア・ハンドラ・リファレンス・アトム（media handler reference atom）１４６に、ムービートラックのデータやメディアデータを解釈するコンポーネントを規定する情報などを記述する。
【００５０】
メディア・ハンドラは、メディア情報アトムの情報を使用して、メディア時間からメディアデータへのマッピングを行う。
【００５１】
メディア情報アトム１４５は、データ・ハンドラ・リファレンス・アトム（data handler reference atom ）１６１、メディア情報ヘッダ・アトム（media information header atom ）、データ情報アトム（data information atom ）１６３およびサンプル・テーブル・アトム（sample table atom ）１６４を含む。
【００５２】
メディア情報ヘッダ・アトム（図４では、ビデオ・メディア情報ヘッダ・アトム１６２）は、メディアにかかる情報が記述される。データ・ハンドラ・リファレンス・アトム１６１は、メディアデータの取り扱いにかかる情報が記述され、メディアデータへのアクセス手段を提供するデータ・ハンドラ・コンポーネントを指定するための情報が含まれる。データ情報アトム１６３は、データ・リファレンス・アトム（data reference atom ）を含み、データについての情報が記述される。
【００５３】
サンプル・テーブル・アトム１６４は、メディア時間を、サンプル位置を指すサンプル番号に変換するために必要な情報を含む。サンプル・テーブル・アトム１６４は、サンプル・サイズ・アトム（sample size atom）１７２、時間サンプル・アトム（time-to-sample atom ）１７３、同期サンプル・アトム（sync sample atom）１７４、サンプル・ディスクリプション・アトム（sample description atom ）１７５、サンプル・チャンク・アトム（sample-to-chunk atom）１７６、チャンク・オフセット・アトム（chunk offset atom ）１７７、および、シャドー同期アトム（shadow sync atom）１７８で構成される場合である。
【００５４】
サンプル・サイズ・アトム１７２は、サンプルの大きさが記述される。時間サンプル・アトム１７３は、何秒分のデータが記録されているか？という、サンプルと時間軸との関係が記述される。同期サンプル・アトム１７４は、同期にかかる情報が記述され、メディア内のキーフレームが指定される。キーフレームは、先行するフレームに依存しない自己内包型のフレームである。サンプル・ディスクリプション・アトム１７５は、メディア内のサンプルをデコード（decode）するために必要な情報が保存される。メディアは、当該メディア内で使用される圧縮タイプの種類に応じて、１つ又は複数のサンプル・ディスクリプション・アトムを持つことができる。
【００５５】
サンプル・チャンク・アトム１７６は、サンプル・ディスクリプション・アトム１７５内のテーブルを参照することで、メディア内の各サンプルに対応するサンプル・ディスクリプションを識別する。サンプル・チャンク・アトム１７６は、サンプルとチャンクとの関係が記述され、先頭チャンク、チャンク当たりのサンプル数およびサンプル・ディスクリプションＩＤ（sample description-ID ）の情報を基に、メディア内におけるサンプル位置が識別される。チャンク・オフセット・アトム１７７は、ムービーデータ内でのチャンクの開始ビット位置が記述され、データストリーム内の各チャンクの位置が規定される。
【００５６】
また、ムービー・データ・アトム１０２には、図３では、例えば、所定の圧縮符号化方式によって符号化されたオーディオデータ、および、所定の圧縮符号化方式によって符号化された画像データがそれぞれ所定数のサンプルから成るチャンクを単位として格納される。なお、データは、必ずしも圧縮符号化する必要はなく、リニアデータを格納することもできる。そして、例えば、テキストやＭＩＤＩなどを扱う場合には、ムービー・データ・アトム１０２にテキストやＭＩＤＩなどの実データが含くまれ、これに対応して、ムービーアトム１０１にテキストトラックやＭＩＤＩトラックなどが含まれる。ムービーアトム１０１における各トラックと、ムービー・データ・アトム１０２に格納されているデータとは、対応付けられている。
【００５７】
このような階層構造において、ＱＴは、ムービー・データ・アトム１０２内のデータを再生する場合に、ムービーアトム１０１から順次に階層を辿り、サンプル・テーブル・アトム１６４内の各アトム１７２〜１７８を基に、サンプル・テーブルをメモリに展開して、各データ間の関係を識別する。そして、ＱＴは、各データ間の関係を基にデータを再生する。
【００５８】
ＱＴがこのようなデータ構造であるので、本実施形態のインデックスファイルは、ムービー・データ・アトムにファイルの抜粋情報の実データを収容し、これら実データの管理情報をムービーアトムに収容する。このインデックスファイルのムービー・データ・アトムを以下、インデックス・データ・アトムと呼称し、ムービーアトムをインデックス・アトムと呼称する。
【００５９】
ここで、インデックスファイルは、記録媒体に記録されるファイルが扱うデータに依存するが、本実施形態では、ファイルのデータが画像データとオーディオデータである。また、このようなファイルを以下、「ＡＶファイル」と略記する。
【００６０】
このように記録媒体にＡＶファイルが記録されている場合に、インデックスファイルは、例えば、プロパティ、テキスト、サムネイル、イントロの４種類のデータが収容される。プロパティは、各ＡＶファイルの属性を示すデータであり、ＡＶファイルの実データを参照する情報も有する。インデックスファイルでは、属性情報を収容するプロパティのみが必須ファイルである。テキストは、各ＡＶファイルに係るタイトルの文字列を示すデータである。サムネイルは、各ＡＶファイルの代表的な１枚の画像データである。ＡＶファイルのサムネイルは、ユーザが任意に付与することができるが、例えば、当該ＡＶファイル中の最初の１枚目の画像データとするように自動設定してもよい。
【００６１】
イントロは、各ＡＶファイルの代表的な短時間のオーディオデータである。ＡＶファイルのイントロは、ユーザが任意に付与することができるが、例えば、当該ＡＶファイル中の最初の数秒間、例えば、５秒間のオーディオデータとするように自動設定してもよい。これらタイトル、サムネイルおよびイントロは、検索の便宜などを考慮の上、必要に応じてインデックスファイルに収容領域が用意される。また、プロパティのデータは、登録される必要があるが、タイトル、サムネイルおよびイントロの各収容領域が確保されていたとしても、タイトル、サムネイルおよびイントロのすべてのデータは、必ずしも登録される必要はない。
【００６２】
図５は、QuickTime ムービーファイルを用いて作成されるインデックスファイルの一例を示す図である。図５において、インデックスファイルは、インデックス・アトム２０１とインデックス・データ・アトム２０２とによって構成される。
【００６３】
インデックス・データ・アトム２０２には、プロパティ、テキスト、サムネイルおよびイントロの実データが収容される。そして、各ＡＶファイルに係るプロパティ、テキスト、サムネイルおよびイントロの実データ２３１、２３２、２３３、２３４は、インデックス・データ・アトム２０２の第１番目以降の各領域であるエントリ＃１〜エントリ＃ｎ（ｎは２以上の整数）にそれぞれ収容される。
【００６４】
インデックス・アトム２０１は、ムービー・ヘッダ・アトム２１１と、プロパティ、テキスト、サムネイルおよびイントロの実データにそれぞれ対応して、トラックアトム（プロパティ）２１２とトラックアトム（テキスト）２１３とトラックアトム（サムネイル）２１４とトラックアトム（イントロ）２１５とから構成される。なお、上述したように、トラックアトム（プロパティ）２１２およびプロパティの実データ２３１のみが必須である。
【００６５】
図６は、トラックアトム（プロパティ）の一例を示す図である。図６において、トラックアトム（プロパティ）２１２は、各ＡＶファイルに対応するプロパティデータに係るチャンクとして定義された、ＡＶファイルプロパティ＃１、ＡＶファイルプロパティ＃２、・・・、ＡＶファイルプロパティ＃ｎのそれぞれについて、データ長Ｌ＿ＰＲ１、Ｌ＿ＰＲ２、・・・、Ｌ＿ＰＲｎ、および開始バイト位置０、Ｌ＿ＰＲ１、Ｌ＿ＰＲ１＋Ｌ＿ＰＲ２、・・・、Ｌ＿ＰＲ１＋・・・＋Ｌ＿ＰＲｎ−１をそれぞれ示すテーブルの形式とされる。データ長は、例えば、バイト単位で表示される可変長である。
【００６６】
なお、トラックアトム（テキスト）、トラックアトム（サムネイル）、トラックアトム（イントロ）とテキストの実データ、サムネイルの実データ、イントロの実データのそれぞれとの関係も、上述したトラックアトム（プロパティ）とプロパティの実データの関係と同様のものとされている。
【００６７】
図７は、プロパティの実データの一例を示す図である。プロパティの実データは、エントリ管理情報とファイル属性情報とからなる。エントリ管理情報は、エントリ自身を管理するための情報であり、エントリ番号（entry number）、エントリプロパティ（entry property）およびフォルダプロパティ（folder property ）からなる。
【００６８】
エントリ番号は、０から始まる番号であり、インデックスファイル内でのユニークな番号である。エントリ番号は、当該プロパティの実データが何れのエントリに収容されているかを示す。エントリ番号は、０バイト目を開始バイト位置とする４バイトのデータである。カメラ一体型ディジタル記録再生装置５０は、このエントリ番号を検索することによって、インデックスファイルにおいてディスクタイトルが収容されている領域を見い出すことができる。
【００６９】
エントリプロパティは、４バイト目を開始バイト位置とする１バイトのデータであり、エントリの属性、状態を示すもので、各１ビットのエントリプロパティ１、エントリプロパティ２、エントリプロパティ３およびエントリプロパティ４が含まれている。
【００７０】
すなわち、エントリプロパティ１は、（０：フォルダ、１：ファイル）の識別を行い、エントリプロパティ２は、（０：ノーマル、１：システム）の識別を行う。ノーマルとは、上述したプロパティの実データのエントリを意味し、システムとは、後述するフラグの定義が記述されているエントリを意味する。フォルダプロパティは、５バイト目を開始バイト位置とする４バイトのデータであり、そのエントリが所属するフォルダを示すものである。
【００７１】
エントリプロパティ３は、エントリに関して（０：有効、１：無効）の識別を行い、エントリプロパティ４は、エントリに登録されたファイルが他のファイルを参照しているかどうかを示し、（０：参照なし、１：参照あり）の識別を行う。
【００７２】
ファイル属性情報は、バージョン（version ）、フラグ（flags ）、データタイプ（data type ）、製作日時（creation time ）、編集日時（modification time ）、デュレーション（duration）、ファイル識別子（binary file identifier）、リファードカウンタ(referred counter)、リファリングファイルリスト(referring file list) 、およびＵＲＬファイルアイデンティファイア(URL file identifier) によって構成される。
【００７３】
バージョンは、９バイト目を開始バイト位置とする１バイトのデータであり、エントリに登録されたファイルのバージョン番号である。フラグは、１０バイト目を開始バイト位置とする２バイトのデータであり、ファイルの属性を識別するためのものである。データタイプは、１２バイト目を開始バイト位置とする１バイトのデータであり、当該プロパティに係るタイトルファイルまたはＡＶファイルにおけるデータの種類（動画、静止画、オーディオなど）を示す。
【００７４】
製作日時は、当該プロパティに係るタイトルファイルまたはＡＶファイルが製作された日時を示し、１３バイト目を開始バイト位置とする４バイトのデータである。編集日時は、当該プロパティに係るタイトルファイルまたはＡＶファイルが修正された日時を示し、１７バイト目を開始バイト位置とする４バイトのデータである。デュレーションは、当該プロパティに係るタイトルファイルまたはＡＶファイルが再生されるために必要とされる時間の長さを示し、２１バイト目を開始バイト位置とする４バイトのデータである。ファイル識別子は、当該プロパティに係るファイルの所在を示すバイナリデータであり、２５バイト目を開始バイト位置とする６バイトのデータである。
【００７５】
リファードカウンタは、ファイルが別のファイルから参照されている数を示し、３１バイト目を開始バイト位置とする４バイトのデータである。リファリングファイルリストは、ファイルが別のファイルから参照されている場合、その参照元を示し、３５バイト目を開始バイト位置とする可変長Ｌ ＲＦのデータである。リファリングファイルリストは、エントリ番号または実際のファイルの所在を示すＩＤが記述される。ＵＲＬファイルアイデンティファイアは、ファイルの所在を示すＵＲＬ形式のデータであり、（３５＋Ｌ ＲＦ）バイト目を開始バイト位置とする可変長Ｌ ＦＩのデータである。
【００７６】
上述したエントリ管理情報によって、図８に示すような仮想的な階層構造を持つことができる。図８Ａは、＃０から＃８までの複数のエントリのそれぞれのプロパティ情報から抜き出されたエントリ管理情報の一例であり、図８Ｂは、図８Ａに示すエントリ管理情報によって表される階層構造を示すものである。以下、エントリ管理情報によるＡＶファイルの管理について説明する。
【００７７】
図８の例では、エントリプロパティ１およびエントリプロパティ２によって、エントリ番号の＃０，＃３，＃４がフォルダであり、＃１，＃５，＃６，＃７がファイルであり、＃２および＃８がシステム情報であることが示されている。エントリ＃２および＃８は、階層には含まれない。また、フォルダプロパティによって、エントリ番号＃１および＃３の上位がエントリ番号＃０のフォルダであることが示され、エントリ番号＃４および＃５の上位がエントリ番号＃３のフォルダであることが示され、エントリ番号＃６および＃７の上位がエントリ番号＃４のフォルダであることが示されている。したがって、これらのエントリ管理情報によって図８Ｂに示す階層構造が規定される。
【００７８】
図９Ａは、インデックスファイルを示し、図９Ａに示すように、システム情報であるエントリ＃２および＃８は、他のノーマルのエントリと同様に、プロパティ、テキスト、サムネイルのデータによって構成されている。イントロは、必須ではないので、図９Ｂでは、イントロのデータをシステム情報のエントリ＃２および＃８が持っていない。そして、他のノーマルのエントリと同様に、システムのエントリは、インデックス・アトム２０１のトラックアトム（プロパティ）２１２、トラックアトム（テキスト）２１３、トラックアトム（サムネイル）２１４によって管理される。図９Ｂは、エントリの＃０から＃８までのプロパティ情報の一部を抜き取って示すもので、図８Ａと同一のものである。
【００７９】
図１０は、システムの情報であるエントリ＃２において、フラグの情報を保持する例を示す。フラグは、２バイト（１６ビット）であり、１がセットされているビット位置に応じてフラグの意味が規定されている。したがって、最大で１６種類の属性をフラグによって定義することができる。定義できる最大数は、適宜制限することができる。図１０の例では、フラグの第１バイトの先頭（ＭＳＢ）から４番目のビットが１とされている。フラグの値は、０ｘ１０００（０ｘは１６進数を表す表記である）である。この場合では、テキストのデータが" ＢＡＳＥＢＡＬＬ" とされ、サムネイルのデータが野球と関連したサムネイル（アイコン）とされる。
【００８０】
図１１は、システムの情報であるエントリ＃８において、フラグの情報を保持する例を示す。図１１の例では、第１バイトのＭＳＢから８番目のビットが１とされている。フラグの値は、０ｘ０１００である。この場合では、テキストのデータが" ＳＫＩ" とされ、サムネイルのデータがスキーと関連したサムネイル（アイコン）とされる。
【００８１】
図１０および図１１に示す例は、１つのエントリによって、フラグの１ビットの意味を定義するものである。図１２に示すように、１つのエントリ例えば＃２によって、複数例えば２ビットのフラグの意味を定義するようにしても良い。例えば第１バイトのＭＳＢから４番目および８番目のビットがそれぞれ１にセットされている。フラグの値は、０ｘ１１００である。この場合では、テキストデータが" ＢＡＳＥＢＡＬＬ" および" ＳＫＩ"
とされ、野球に関連したサムネイル（アイコン）とスキーと関連したサムネイル（アイコン）との２枚のサムネイルのデータが記録される。
【００８２】
このように、１つのエントリにおいてフラグの複数ビットを定義する場合、フラグとテキストとサムネイルとの対応関係が予め決められている。例えばフラグのＭＳＢ側のビットから順番にテキストおよびサムネイルのそれぞれを並べるようになされる。テキストの場合は、任意の文字数で区切り、各区切りに順にテキスト情報が記録される。または、ＨＴＭＬ(Hyper Text Markup Language)のような記述言語を使用してタグを埋め込むことによって、複数のテキストを区別しても良い。サムネイルも実際に格納するサムネイルのどの画素がひとつの絵を構成し、どの場所にある絵から対応させるのかというルールを設けたり、画素の位置情報を、テキストのタグを用いて格納したり、サムネイルのコメント情報に格納することでも対応できる。
【００８３】
図１３は、エントリ＃２によってフラグの２ビットの意味を定義する場合のファイルの整理の方法を示すものである。図１３Ａは、エントリ＃０から＃７までのエントリ管理情報およびフラグを示している。このエントリ管理情報（エントリ番号、エントリプロパティ１、エントリプロパティ２、フォルダプロパティ）は、図８または図９におけるエントリ＃０から＃７までの情報と同一である。また、エントリ＃２は、システム情報であり、フラグが０ｘ１１００とされ、図１２を参照して説明したように、二つのフラグの定義の情報を保持している。
【００８４】
ファイルであるエントリ＃１のフラグは、０であり、このファイル＃１の属性が規定されていない。エントリ＃５のファイルの属性がフラグ０ｘ１０００によって、" ＢＡＳＥＢＡＬＬ" と規定されている。エントリ＃６および＃７のフラグが共に０ｘ０１００とされている。このフラグは、属性が" ＳＫＩ" であることを示している。
【００８５】
上述した図１３Ａに示すエントリ管理情報とフラグによって、図１３Ｂに示す階層構造が規定される。フラグによってファイルの属性情報を規定することができる。したがって、インデックスファイルが記録された記録媒体例えば光ディスクを再生する場合に、フラグで規定されるファイル属性を指定することによって、インデックスファイルの中で指定された属性のもののみを例えば表示することができる。さらに、表示されているインデックスファイルの中で所望のものを指定することによって、指定されたインデックスファイルに対応するＡＶファイルを指定することができる。したがって、ユーザが希望するＡＶファイルを高速に検索することができる。さらに、システム情報によってフラグの定義を記述するので、必要な範囲の定義を行なえば良く、データ量が増えない利点がある。また、記録媒体毎にフラグの定義が異なっていても良く、汎用性に優れている利点がある。
【００８６】
なお、予め機器がフラグを定義するシステム情報を持つ方法、並びにユーザ自身がフラグの定義を設定する方法の何れも採用することができる。例えば一実施形態では、フラグとして２バイト用意されているので、１バイトを機器例えば光ディスク記録再生装置を備えた撮像装置によって定義されるフラグに割り当て、他の１バイトをユーザが定義できるフラグに割り当てるようにしても良い。
【００８７】
次に、エントリ管理情報とファイルの属性情報の一部を用いて、エントリの参照関係を示す方法について説明する。図１４Ａは、エントリ＃０からエントリ＃７までのエントリの参照関係を示すのに必要なプロパティ情報の一例を示す。エントリプロパティ（１バイト）の中には、エントリプロパティ１からエントリプロパティ４までが規定される。エントリプロパティ１がファイルとフォルダの識別に使用され、エントリプロパティ２がノーマル情報とシステム情報との識別に使用される。フォルダプロパティは、上位のフォルダを示している。これらのエントリプロパティ１および２およびフォルダプロパティは、上述したものと同様のものである。
【００８８】
エントリプロパティ３は、エントリに関して（０：有効、１：無効）の識別を行い、エントリプロパティ４は、エントリに登録されたファイルが他のファイルを参照しているかどうかを示し、（０：参照なし、１：参照あり）の識別を行う。リファードカウンタは、ファイルが別のファイルから参照されている数を示し、リファリングファイルリストは、ファイルが別のファイルから参照されている場合、その参照元を示す。
【００８９】
図１４Ａの例では、全てのエントリが有効であり、エントリプロパティ３が全て０とされ、エントリ＃５および＃６に登録されたファイルが他のファイルを参照しているので、エントリ＃５および＃６のエントリプロパティ４が１とされている。また、エントリ＃１のリファードカウンタが２とされ、二つのファイルから参照されている。参照元の二つのファイルは、リファリングファイルリストに示されているエントリ＃５および＃６にそれぞれ登録されているファイルである。
【００９０】
エントリ＃１に登録されているＡＶファイルをＡＶファイルＡとし、エントリ＃５，＃６，＃７にそれぞれ登録されているＡＶファイルをＡＶファイルＢ，Ｃ，Ｄとする。図１４Ａに示すプロパティの情報と、図１４Ｂに示すようなファイル同士の参照関係とが対応している。すなわち、エントリ＃５，＃6 にそれぞれ登録されファイルＣ，Ｄがエントリ＃１に登録されたファイルＡを参照しているので、エントリ＃５，＃６のエントリプロパティ４がそれぞれ１となり、エントリ＃１のリファードカウンタが２となり、エントリ＃１のリファリングファイルリストが５，６になっている。
【００９１】
記録媒体上に記録されているＡＶファイルの中で、あるＡＶファイルを削除しようとした場合、他のＡＶファイルから参照されているＡＶファイルを削除することができない。このことは、ファイルの属性情報中のリファードカウンタの値が０か、それ以外かで判定できる。図１４の例では、ＡＶファイルＡのリファードカウンタの値が２であり、このファイルＡを削除することができないことが分かる。
【００９２】
ＡＶファイルを削除した場合に、対応するエントリをどのように処理するかは、二通りの方法が可能である。１つの方法は、図１５に示すように、例えばＡＶファイルＣを削除した場合に、対応するエントリ＃６を実際に削除する方法である。他の方法は、図１６に示すように、エントリ＃６を削除しないで、エントリ＃６のエントリプロパティ３の値を無効を意味する値（１）に変更する方法である。何れの方法を使用しても良い。
【００９３】
ＡＶファイルの削除に伴ってエントリを実際に削除する方法は、記録媒体の容量の面で、エントリを削除しない方法に比して有利である。処理時間の点から見ると、エントリを実際に削除する方法は、エントリの実データのみならず、トラックアトムを書き換える必要があるので、エントリを削除しない方法に比して不利である。
【００９４】
図１７を参照してファイル削除処理について説明する。この処理は、例えば図２参照して説明したカメラ一体型ディジタル記録再生装置において、そのシステムコントローラ（マイクロコンピュータ）の制御によってなされる。最初のステップＳ１において、ファイル一覧表示において、ファイル（ＡＶファイル）ｘの削除が選択される。例えば表示パネル（図２参照）上に表示されているファイルの一覧、画面を分割して表示される複数のサムネイル等から削除したいファイルｘを選択する。
【００９５】
ステップＳ２では、インデックスファイル中でファイルｘが登録されているエントリのリファードカウンタの値が０か否かが判定される。０でない場合は、他のファイルがファイルｘを参照していることを意味するので、ファイルｘが削除できないので、例外処理がなされる（ステップＳ３）。例えばユーザに対して、削除できない旨のメッセージを表示する。
【００９６】
ステップＳ２でリファードカウンタの値が０と判定されると、ステップＳ４では、エントリプロパティ４の値が１か否かが判定される。すなわち、ファイルｘが他のファイルを参照しているか否かが決定される。エントリプロパティ４＝１の場合では、ステップＳ５において、リファリングファイルリストがファイルｘのエントリ番号（ファイルｘのＩＤの場合もある）であるエントリ、すなわち、ファイルｘによって参照されているエントリを探す。
【００９７】
ステップＳ６では、そのようなエントリの有無が決定される。エントリが無いと判定される場合では、ステップＳ７において、例外処理がなされる。例えばデータの不整合がある旨のメッセージがユーザに提示される。ステップＳ４において、エントリプロパティ４が１であったので、本来は、ファイルｘが参照しているエントリが存在するはずである。にもかかわらず、そのようなエントリが無いことは、データの不整合が存在していることを意味する。
【００９８】
ステップＳ６においてファイルｘによって参照されているエントリがあると判定されると、ステップＳ８では、そのエントリのリファードカウンタの値がデクリメントされる。そして、ステップＳ９において、リファリングファイルリストからファイルｘのエントリ番号（ファイルｘのＩＤの場合もある）が削除される。
【００９９】
次に、ステップＳ１０において、ファイルｘのエントリを削除するか否かが判定される。図１７の処理では、ＡＶファイルｘを削除する場合に、インデックスファイル中の対応するエントリを実際に削除するか否かを選択することが可能とされている。例えば記録媒体の残りの空き容量の多寡から処理を選択するようになされる。残りの空き容量が多い場合では、エントリを削除しない方法が選択され、残りの空き容量が少ない場合では、エントリを実際に削除する方法が選択される。
【０１００】
ステップＳ１０において、ファイルｘに対応するエントリを削除する処理が選択されると、図１５に示すように、ステップＳ１１において、インデックス・データ・アトムから対応するエントリが削除され、ステップＳ１２において、削除したエントリ以降のデータが移動され、空いた論理空間が埋められる。そして、ステップＳ１３において、インデックスアトムにおいて、管理ファイルのデータが更新される。若し、ステップＳ１０において、ファイルｘに対応するエントリを削除しないと決定した場合では、ステップＳ１５において、そのエントリのエントリプロパティ３の値を１（無効エントリを意味する）に更新する。
【０１０１】
ステップＳ１３またはＳ１５までの処理は、システム例えばカメラ一体型ディジタル記録再生装置のシステムコントローラに備えられた半導体メモリ上でのデータの書き換え処理である。そして、記録媒体をイジェクトする直前、一定時間毎等の適切なタイミングでもって、記録媒体のデータが更新される（ステップＳ１４）。すなわち、記録媒体上のＡＶファイルｘの削除、並びに記録媒体上のインデックスファイルの更新が行なわれる。
【０１０２】
次に、ファイルの削除後に、新規にエントリを追加する処理について図１８を参照して説明する。ステップＳ２１では、ファイルＸの追加処理が開始される。ステップＳ２２において、エントリプロパティ３によって無効と示されているエントリが探される。ここでは、エントリプロパティ３の値が１のエントリが無効と規定されている。
【０１０３】
無効のエントリがあるとステップＳ２２において決定されると、ステップＳ２３において、無効エントリの領域に新たなエントリが上書きされる。図１９は、例えばエントリ＃６が無効エントリの場合の処理を示している。インデックスファイル中の管理データであるインデックスアトムを書き換えることは不要である。
【０１０４】
一方、ステップＳ２２において、無効エントリが無いと決定されると、ステップＳ２５において、インデックスファイルの任意の場所に新規のエントリ情報が追加される。ステップＳ２６では、インデックスアトムのトラック毎の管理情報が追加されたエントリを規定するように更新される。図２０は、エントリ＃ｎとして新規のエントリを追加する処理を示している。
【０１０５】
ステップＳ２３またはＳ２６までの処理は、システム例えばカメラ一体型ディジタル記録再生装置のシステムコントローラに備えられた半導体メモリ上でのデータの書き換え処理である。そして、記録媒体をイジェクトする直前、一定時間毎等の適切なタイミングでもって、記録媒体のデータが更新される（ステップＳ２４）。
【０１０６】
このように、プロパティ情報がファイルの参照関係の情報を持っているので、実際のファイルにアクセスしないで、参照関係を管理することができ、消去の可否を高速に判断することができる。
【０１０７】
この発明は、上述したこの発明の一実施形態等に限定されるものでは無く、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。例えばこの発明は、ディジタルオーディオ信号を記録再生する場合に対しても適用できる。例えばフラグによってＡＶファイル（楽曲データ）のジャンル（クラシック、ジャズ、ロック、ポピュラー等）を識別するようにしても良い。また、フラグに記述されている属性情報を定義する場合、そのインデックスファイル全体の範囲に関して属性情報を定義したり、インデックスファイルの一部の所定の範囲で属性情報を定義するようにしても良い。さらに、上述した説明では、QuickTime を使用する例について述べたが、他のアプリケーションソフトウェアを使用する場合にこの発明を適用しても良い。
【図面の簡単な説明】
【０１０８】
【図１】この発明を適用できるディジタル記録再生装置の一構成例を示すブロック図である。
【図２】この発明を適用できるカメラ一体型ディジタル記録再生装置の外形を示す略線図である。
【図３】QuickTime ムービーファイルの一構成例を示す略線図である。
【図４】ビデオ・メディア情報アトムの一構成例を示す略線図である。
【図５】QuickTime ムービーファイルを用いて作成されるインデックスファイルの一例を示す略線図である。
【図６】トラックアトム（プロパティ）の一例を示す略線図である。
【図７】プロパティの実データの一例を示す略線図である。
【図８】プロパティ情報の一部とファイルおよびフォルダの階層構造の具体例を示す略線図である。
【図９】インデックスファイルの構成とプロパティ情報の一部の具体例を示す略線図である。
【図１０】エントリ＃２によって１つのフラグの内容を登録する一例を示す略線図である。
【図１１】エントリ＃８によって１つのフラグの内容を登録する他の例を示す略線図である。
【図１２】エントリ＃２によって２つのフラグの内容を登録する一例を示す略線図である。
【図１３】フラグを含むプロパティ情報の一部とファイルおよびフォルダの階層構造の具体例を示す略線図である。
【図１４】ファイルの参照関係を示すプロパティ情報の説明に用いる略線図である。
【図１５】ファイルの削除時のプロパティ情報の処理の一例の説明に用いる略線図である。
【図１６】ファイルの削除時のプロパティ情報の処理の他の例の説明に用いる略線図である。
【図１７】ファイルの削除時のプロパティ情報の処理の説明に用いるフローチャートである。
【図１８】ファイルのエントリ追加時の処理の説明に用いるフローチャートである。
【図１９】ファイルのエントリ追加時の処理の一例の説明に用いる略線図である。
【図２０】ファイルのエントリ追加時の処理の他の例の説明に用いる略線図である。
【符号の説明】
【０１０９】
１１・・・ビデオ符号器
１２・・・オーディオ符号器
１３・・・ビデオ復号器
１４・・・オーディオ復号器
１５・・・ファイル生成器
１６・・・ファイル復号器
１７、２０・・・メモリ
１８・・・メモリコントローラ
１９・・・システム制御マイコン
２１・・・エラー訂正符号／復号器
２３・・・データ変復調器
２４・・・磁界変調ドライバ
２６・・・操作部
３０・・・サーボ回路
３１・・・モータ
３２・・・磁界ヘッド
３３・・・光ピックアップ
４０・・・記録媒体
５０・・・カメラ一体型ディジタル記録再生装置
５１・・・本体
５２・・・レンズ部
５３・・・集音マイク
５４・・・表示パネル
５５・・・ポインティングデバイス
２０１・・・インデックス・アトム
２０２・・・インデックス・データ・アトム
２３１・・・プロパティ
２３２・・・テキスト
２３３・・・サムネイル
２３４・・・イントロ
【図１】
2004355800.tif 000003
【図２】
2004355800.tif 000004
【図３】
2004355800.tif 000005
【図４】
2004355800.tif 000006
【図５】
2004355800.tif 000007
【図６】
2004355800.tif 000008
【図７】
2004355800.tif 000009
【図８】
2004355800.tif 000010
【図９】
2004355800.tif 000011
【図１０】
2004355800.tif 000012
【図１１】
2004355800.tif 000013
【図１２】
2004355800.tif 000014
【図１３】
2004355800.tif 000015
【図１４】
2004355800.tif 000016
【図１５】
2004355800.tif 000017
【図１６】
2004355800.tif 000018
【図１７】
2004355800.tif 000019
【図１８】
2004355800.tif 000020
【図１９】
2004355800.tif 000021
【図２０】
2004355800.tif 000022