以下、この発明の実施形態について図面に基づいて説明する。なお、各図において、同一の構成については、その説明を省略することがある。図1は、この発明を適用できるディジタル記録再生装置の一構成例を示すブロック図である。ディジタル記録再生装置は、ビデオ符号器11、オーディオ符号器12、ビデオ復号器13、オーディオ復号器14、ファイル生成器15、ファイル復号器16、メモリ17、メモリ20、メモリコントローラ18、システム制御マイコン19、エラー訂正符号/復号器21、ドライブ制御マイコン22、データ変復調器23、磁界変調ドライバ24、操作部26、サーボ回路30、スピンドルモータ31、磁界ヘッド32および光ピックアップ33によって構成される。記録媒体(ここでは、光磁気ディスク)40に対しては、ディジタルデータが磁界ヘッド32および光ピックアップ33によって磁界変調によって記録される。また、記録されたデータが光ピックアップ33によって記録媒体40から読み出される。
ビデオ信号は、ビデオ入力端子からビデオ符号器11に供給され、圧縮符号化される。オーディオ信号は、オーディオ入力端子からオーディオ符号器12に供給され、圧縮符号化される。ビデオ符号器11およびオーディオ符号器12の各出力がエレメンタリストームと呼ばれる。
本実施形態では、ディジタル記録再生装置は、カメラ一体型ディジタル記録再生装置に備えられている。ビデオ信号は、ビデオカメラで撮影された画像が供給され、ビデオカメラは、光学系によって被写体の撮像光がCCD(Charge Coupled Device)などの撮像素子に供給されることによってビデオ信号を生成する。オーディオ信号は、マイクロフォンで集音された音声が供給される。
ビデオ符号器11は、例えば、圧縮符号化がMPEGの場合には、A/D変換器、フォーマット変換部、画像並替部、減算器、DCT部、量子化部、可変長符号化部、バッファメモリ、レート制御部、逆量子化部、逆DCT部、加算部、ビデオメモリ、動き補償予測部およびスイッチの各電子回路によって構成される。
ビデオ符号器11に供給されたビデオ信号は、A/D変換器でディジタル化された後に、フォーマット変換部で符号化で用いる空間解像度に変換され、画像並替部に出力される。画像並替部は、ピクチャの順序を符号化処理に適した順に並び替える。すなわち、IピクチャおよびPピクチャを先に符号化し、その後、Bピクチャを符号化するのに適した順に並び替える。
画面並替部の出力は、減算部を介してDCT部に入力され、DCT符号化が行われる。DCT部の出力は、量子化部に入力され、所定のビット数で量子化される。量子化部の出力は、可変長符号化部および逆量子化部に入力される。可変長符号化部は、出現頻度がより高いデータにより短いコードを割り当てる可変長符号、例えば、ハフマン符号で符号化され、符号化データは、メモリのバッファメモリに出力される。バッファメモリは、一定レートで符号化データをビデオ符号器の出力として出力する。また、レート制御部は、可変長符号化部で発生する符号量が可変であるため、バッファメモリを監視することによって所定のビットレートを保つように、量子化部の量子化動作を制御する。
一方、IピクチャおよびPピクチャの場合は、動き補償予測部で参照画面として使用されるため、量子化部から逆量子化部に入力された信号は、逆量子化された後に逆DCT部に入力され、逆DCTが行われる。逆DCT部の出力は、加算部で動き補償予測部の出力と加算され、ビデオメモリに入力される。ビデオメモリの出力は、動き補償予測部に入力される。動き補償予測部は、前方向予測、後方向予測および両方向予測を行い、加算部および減算部に出力する。これら逆量子化部、逆DCT部、加算部、ビデオメモリおよび動き補償予測部は、ローカル復号部を構成し、ビデオ復号器と同一のビデオ信号が復元される。
減算部は、画像並替部の出力と動き補償予測部の出力との間で減算を行い、ビデオ信号とローカル復号部で復号された復号ビデオ信号との間の予測誤差を形成する。フレーム内符号化(Iピクチャ)の場合では、スイッチにより、減算部は、減算処理を行わず、単にデータが通過する。
図1に戻って説明すると、オーディオ符号器12は、例えば、MPEG/Audioレイヤ1/レイヤ2の場合では、サブバンド符号化部および適応量子化ビット割り当て部などの各電子回路を備えて構成される。オーディオ信号は、サブバンド符号化部で32帯域のサブバンド信号に分割され、適応量子化ビット割り当て部で心理聴覚重み付けに従って量子化され、ビットストリームに形成された後に出力される。
なお、符号化品質を向上させるために、MPEG/Audioレイヤ3の場合では、さらに、適応ブロック長変形離散コサイン変換部、折り返し歪み削減バタフライ部、非線形量子化部および可変長符号化部などが導入される。
ビデオ符号器11の出力およびオーディオ符号器12の出力がファイル生成器15に供給される。ファイル生成器15は、特定のハードウェア構成を使用することなく動画、音声およびテキストなどを同期して再生することができるコンピュータソフトウェアにより扱うことができるファイル構造を持つように、ビデオエレメンタリストリームおよびオーディオエレメンタリストームのデータ構造を変換する。このようなソフトウェアは、例えば、QuickTime (以下、適宜「QT」と略記する。)が知られている。以下、QTを使用する場合について説明する。ファイル生成器15は、符号化ビデオデータと符号化オーディオデータとを多重化する。ファイル生成器15は、システム制御マイコン19によって制御される。
ファイル生成器15の出力であるQuickTime ムービーファイルは、メモリコントローラ18を介してメモリ17に順次に書き込まれる。メモリコントローラ18は、システム制御マイコン19から記録媒体40へのデータ書き込みが要求されると、メモリ17からQuickTime ムービーファイルを読み出す。
ここで、QuickTime ムービー符号化の転送レートは、記録媒体40への書き込みデータの転送レートより低い転送レート、例えば、1/2に設定される。よって、QuickTime ムービーファイルが連続的にメモリ17に書き込まれるのに対し、メモリ17からのQuickTime ムービーファイルの読み出しは、メモリ17がオーバーフローまたはアンダーフローしないように、システム制御マイコン19によって監視されながら間欠的に行われる。
メモリ17から読み出されたQuickTime ムービーファイルは、メモリコントローラ18からエラー訂正符号/復号器21に供給される。エラー訂正符号/復号器21は、このQuickTime ムービーファイルを一旦メモリ20に書き込み、インターリーブ(interleaved
)およびエラー訂正符号の冗長データの生成を行う。エラー訂正符号/復号器21は、冗長データが付加されたデータをメモリ20から読み出し、これをデータ変復調器23に供給する。
データ変復調器23は、デジタルデータを記録媒体40に記録する際に、再生時のクロック抽出を容易とし、符号間干渉などの問題が生じないように、データを変調する。例えば、(1,7)RLL(run length limited)符号やトレリス符号などを利用することができる。
データ変復調器23の出力は、磁界変調ドライバ24および光ピックアップ33に供給される。磁界変調ドライバ24は、入力信号に応じて、磁界ヘッド32を駆動して記録媒体40に磁界を印加する。光ピックアップ33は、入力信号に応じて記録用のレーザビームを記録媒体40に照射する。磁界変調方式によって、記録媒体40にデータが記録される。
記録媒体40は、ディスク状の記録媒体であり、例えば、光磁気ディスク(MO、magneto-optical disk)てある。光磁気ディスク以外に、相変化型ディスク、磁気ディスクなどの書き換え可能なディスク状記録媒体を使用できる。
ここで、後述するインデックスファイルは、読み出しの容易性の観点から、ディスク状の記録媒体における実質的な最内周、例えば、リードインに続く記録部分に記録されることが好ましい。
本実施形態では、MO、例えば、直径約4cm、直径約5cm、直径約6.5cmまたは直径約8cmなどの比較的小径なディスクが使用される。記録媒体40は、モータ31によって、線速度一定(CLV)、角速度一定(CAV)またはゾーンCLV(ZCLV)で回転される。
ドライブ制御マイコン22は、システム制御マイコン19の要求に応じて、サーボ回路30に信号を出力する。サーボ回路30は、この出力に応じて、スピンドルモータ31および光ピックアップ33を制御することによって、ドライブ全体を制御する。例えば、サーボ回路30は、光ピックアップ33に対し、記録媒体40の径方向の移動サーボ、トラッキングサーボおよびフォーカスサーボを行い、スピンドルモータ31の回転を制御する。また、システム制御マイコン19には、ユーザが所定の指示を入力する操作部26が接続される。
再生の際には、光ピックアップ33は、再生用の出力でレーザビームを記録媒体40に照射し、その反射光を光ピックアップ33内の光検出器で受光することによって、再生信号を得る。この場合において、ドライブ制御マイコン22は、光ピックアップ33内の光検出器の出力信号からトラッキングエラーおよびフォーカスエラーを検出し、読み取りのレーザビームがトラック上に位置し、トラック上に合焦するように、サーボ回路30によって光ピックアップ33を制御する。さらに、ドライブ制御マイコン22は、記録媒体40上における所望の位置のデータを再生するために、光ピックアップの径方向における移動も制御する。所望の位置は、記録時と同様にシステム制御マイコン19によって、ドライブ制御マイコン22に信号が与えられ、決定される。
光ピックアップ33の再生信号は、データ変復調器23に供給され、復調される。復調されたデータは、エラー訂正符号/復号器21に供給され、再生データを一旦メモリ20に格納し、デインターリーブ(deinterleaved )およびエラー訂正が行われる、エラー訂正後のQuickTime ムービーファイルは、メモリコントローラ18を介してメモリ17に格納される。
メモリ17に格納されたQuickTime ムービーファイルは、システム制御マイコン19の要求に応じて、ファイル復号器16に出力される。システム制御マイコン19は、ビデオ信号およびオーディオ信号を連続再生するために、記録媒体40の再生信号がメモリ17に格納されるデータ量と、メモリ17から読み出されてファイル復号器16に供給されるデータ量とを監視することによって、メモリ17がオーバーフローまたはアンダーフローしないようにメモリコントローラ18およびドライブ制御マイコン22を制御する。こうして、システム制御マイコン19は、記録媒体40から間欠的にデータを読み出す。
ファイル復号器16は、システム制御マイコン19の制御下で、QuickTime ムービーファイルをビデオエレメンタリストリームとオーディオエレメンタリファイルとに分離する。ビデオエレメンタリストリームは、ビデオ復号器13に供給され、圧縮符号化の復号が行われてビデオ出力となってビデオ出力端子から出力される。オーディオエレメンタリストリームは、オーディオ復号器14に供給され、圧縮符号化の復号が行われてオーディオ出力となってオーディオ出力端子から出力される。ここで、ファイル復号器16は、ビデオエレメンタリストリームとオーディオエレメンタリストリームとが同期するように出力する。
ビデオ復号器13は、例えば、MPEGの場合では、メモリのバッファメモリ、可変長符号復号部、逆量子化部、逆DCT部、加算部、ビデオメモリ、動き補償予測部、画面並替部およびディジタル/アナログ変換器(以下、「D/A」と略記する。)の各電子回路を備えて構成される。ビデオエレメンタリストームは、一旦バッファメモリに蓄積され、可変長復号部に入力される。可変長復号部は、マクロブロック符号化情報が復号され、予測モード、動きベクトル、量子化情報および量子化DCT係数が分離される。量子化DCT係数は、逆量子化部でDCT係数に復元され、逆DCT部で画素空間データに変換される。加算部は、逆量子化部の出力と動き補償予測部の出力とを加算するが、Iピクチャを復号する場合には、加算しない。画面内のすべてのマクロブロックが復号され、画面は、画面並替部で元の入力順序に並べ替えられて、D/Aでアナログ信号に変換されて出力される。また、加算器の出力は、IピクチャおよびPピクチャの場合には、その後の復号処理で参照画面として使用されるため、ビデオメモリに蓄積され、動き補償予測部に出力される。
オーディオ復号器14は、例えば、MPEG/Audioレイヤ1/レイヤ2の場合では、ビットストリーム分解部、逆量子化部およびサブバンド合成フィルタバンク部などの各電子回路を備えて構成される。入力されたオーディオエレメンタリストリームは、ビットストリーム分解部でヘッダと補助情報と量子化サブバンド信号とに分離され、量子化サブバンド信号は、逆量子化部で割り当てられたビット数で逆量子化され、サブバンド合成フィルタバンクで合成された後に、出力される。
図2は、カメラ一体型ディジタル記録再生装置の外形を示す模式図である。カメラ一体型ディジタル記録再生装置50は、本体51、レンズ部52、集音マイク53および表示パネル54を備えて構成される。図1に示すディジタル記録再生装置は、本体51内に収められる。ビデオ信号は、レンズ部52の光学系を介して被写体の撮像光が撮像素子に供給され、生成される。オーディオ信号は、集音マイク53で生成される。表示パネル54は、再生画像や操作内容に対応する表示などが行われる。表示パネル54は、液晶表示と圧電素子とを備えて構成される。ユーザは、表示部分をポインティングデバイス55で押圧することによって、所望の操作を入力する。
表示パネル54は、撮影時のモニタ画像を表示したり、記録媒体の再生画像を表示するのに使用される。さらに、インデックスファイルとして記録されている画像情報例えばサムネイル画像(Thumbnail Picture )が表示パネル54に表示される。具体的には、複数のサムネイルが表示パネル54に整列して表示される。表示パネル54に一度に表示できるサムネイルの枚数は、制約されるので、表示パネル54上に表示されるスクロールキーまたは本体51に設けられているキー操作によって、サムネイルのスクロールが可能とされている。そして、サムネイルの内で所望のものポインティングデバイス55またはカーソルによって指定することによって、指定されたサムネイルに対応する画像データとオーディオデータを扱うファイルが再生されるようになされている。
このようなカメラ一体型ディジタル記録再生装置50は、記録媒体をフォーマットする際や撮影後などにファイルの抜粋情報を生成する。本実施形態では、インデックスファイルは、例えば、QuickTime ムービーファイルの形式で生成される。QuickTime ムービーファイルの形式で生成することによって、映像データやオーディオデータなどの複数の実データと、ファイルの抜粋情報とを同じ形式で記録することができ、記録再生装置は、すべてをQTで再生することができる。
以下、QuickTime ムービーファイルについて概説する。QTは、各種データを時間軸に沿って管理するソフトウェアであり、特殊なハードウェアを用いずに動画や音声やテキストなどを同期して再生するためのOS拡張機能である。QTは、例えば、「INSIDE MACINTOSH :QuickTime(日本語版)(アジソンウエスレス)」などに開示されている。
QTムービーリソースの基本的なデータユニットは、アトム(atom)と呼ばれ、各アトムは、そのデータとともに、サイズおよびタイプ情報を含んでいる。また、QTでは、データの最小単位がサンプル(sample)として扱われ、サンプルの集合としてチャンク(chunk )が定義される。
図3は、QuickTime ムービーファイルの一構成例を示す図である。図4は、ビデオ・メディア情報アトムの一構成例を示す図である。図4は、図3におけるビデオ・メディア情報アトムをより詳細に示した図となっており、トラックがビデオ情報の場合について示している。
図3および図4において、QuickTime ムービーファイルは、大きく2つの部分、ムービーアトム(movie atom)101およびムービー・データ・アトム(movie data atom )102から構成される。ムービーアトム101は、そのファイルを再生するために必要な情報や実データを参照するために必要な情報を格納する部分である。ムービー・データ・アトム102は、ビデオデータやオーディオデータなどの実データを格納する部分である。
ムービーアトム101は、ムービー全体に関する情報を収容するムービー・ヘッダ・アトム(movie header atom )111、クリッピング領域を指定するムービー・クリッピング・アトム(movie clipping atom )112、ユーザ定義データアトム113、および、1または複数のトラックアトム(track atom)114などを含む。
トラックアトム114は、ムービー内の1つのトラックごとに用意される。トラックアトム114は、トラック・ヘッダ・アトム(track header atom )131、トラック・クリッピング・アトム(track clipping atom )132、トラック・マット・アトム(track matte atom)133、エデットアトム(edit atom )134およびメディアアトム(media atom)135に、ムービー・データ・アトム102の個々のデータに関する情報を記述する。図3では、1つのビデオムービーのトラックアトム114-1が示され、他のトラックアトムは、省略されている。
メディアアトム135は、メディア・ヘッダ・アトム(media header atom )144、メディア情報アトム(media information atom)(図3および図4では、ビデオ・メディア情報アトム145)、および、メディア・ハンドラ・リファレンス・アトム(media handler reference atom)146に、ムービートラックのデータやメディアデータを解釈するコンポーネントを規定する情報などを記述する。
メディア・ハンドラは、メディア情報アトムの情報を使用して、メディア時間からメディアデータへのマッピングを行う。
メディア情報アトム145は、データ・ハンドラ・リファレンス・アトム(data handler reference atom )161、メディア情報ヘッダ・アトム(media information header atom )、データ情報アトム(data information atom )163およびサンプル・テーブル・アトム(sample table atom )164を含む。
メディア情報ヘッダ・アトム(図4では、ビデオ・メディア情報ヘッダ・アトム162)は、メディアにかかる情報が記述される。データ・ハンドラ・リファレンス・アトム161は、メディアデータの取り扱いにかかる情報が記述され、メディアデータへのアクセス手段を提供するデータ・ハンドラ・コンポーネントを指定するための情報が含まれる。データ情報アトム163は、データ・リファレンス・アトム(data reference atom )を含み、データについての情報が記述される。
サンプル・テーブル・アトム164は、メディア時間を、サンプル位置を指すサンプル番号に変換するために必要な情報を含む。サンプル・テーブル・アトム164は、サンプル・サイズ・アトム(sample size atom)172、時間サンプル・アトム(time-to-sample atom )173、同期サンプル・アトム(sync sample atom)174、サンプル・ディスクリプション・アトム(sample description atom )175、サンプル・チャンク・アトム(sample-to-chunk atom)176、チャンク・オフセット・アトム(chunk offset atom )177、および、シャドー同期アトム(shadow sync atom)178で構成される場合である。
サンプル・サイズ・アトム172は、サンプルの大きさが記述される。時間サンプル・アトム173は、何秒分のデータが記録されているか?という、サンプルと時間軸との関係が記述される。同期サンプル・アトム174は、同期にかかる情報が記述され、メディア内のキーフレームが指定される。キーフレームは、先行するフレームに依存しない自己内包型のフレームである。サンプル・ディスクリプション・アトム175は、メディア内のサンプルをデコード(decode)するために必要な情報が保存される。メディアは、当該メディア内で使用される圧縮タイプの種類に応じて、1つ又は複数のサンプル・ディスクリプション・アトムを持つことができる。
サンプル・チャンク・アトム176は、サンプル・ディスクリプション・アトム175内のテーブルを参照することで、メディア内の各サンプルに対応するサンプル・ディスクリプションを識別する。サンプル・チャンク・アトム176は、サンプルとチャンクとの関係が記述され、先頭チャンク、チャンク当たりのサンプル数およびサンプル・ディスクリプションID(sample description-ID )の情報を基に、メディア内におけるサンプル位置が識別される。チャンク・オフセット・アトム177は、ムービーデータ内でのチャンクの開始ビット位置が記述され、データストリーム内の各チャンクの位置が規定される。
また、ムービー・データ・アトム102には、図3では、例えば、所定の圧縮符号化方式によって符号化されたオーディオデータ、および、所定の圧縮符号化方式によって符号化された画像データがそれぞれ所定数のサンプルから成るチャンクを単位として格納される。なお、データは、必ずしも圧縮符号化する必要はなく、リニアデータを格納することもできる。そして、例えば、テキストやMIDIなどを扱う場合には、ムービー・データ・アトム102にテキストやMIDIなどの実データが含くまれ、これに対応して、ムービーアトム101にテキストトラックやMIDIトラックなどが含まれる。ムービーアトム101における各トラックと、ムービー・データ・アトム102に格納されているデータとは、対応付けられている。
このような階層構造において、QTは、ムービー・データ・アトム102内のデータを再生する場合に、ムービーアトム101から順次に階層を辿り、サンプル・テーブル・アトム164内の各アトム172〜178を基に、サンプル・テーブルをメモリに展開して、各データ間の関係を識別する。そして、QTは、各データ間の関係を基にデータを再生する。
QTがこのようなデータ構造であるので、本実施形態のインデックスファイルは、ムービー・データ・アトムにファイルの抜粋情報の実データを収容し、これら実データの管理情報をムービーアトムに収容する。このインデックスファイルのムービー・データ・アトムを以下、インデックス・データ・アトムと呼称し、ムービーアトムをインデックス・アトムと呼称する。
ここで、インデックスファイルは、記録媒体に記録されるファイルが扱うデータに依存するが、本実施形態では、ファイルのデータが画像データとオーディオデータである。また、このようなファイルを以下、「AVファイル」と略記する。
このように記録媒体にAVファイルが記録されている場合に、インデックスファイルは、例えば、プロパティ、テキスト、サムネイル、イントロの4種類のデータが収容される。プロパティは、各AVファイルの属性を示すデータであり、AVファイルの実データを参照する情報も有する。インデックスファイルでは、属性情報を収容するプロパティのみが必須ファイルである。テキストは、各AVファイルに係るタイトルの文字列を示すデータである。サムネイルは、各AVファイルの代表的な1枚の画像データである。AVファイルのサムネイルは、ユーザが任意に付与することができるが、例えば、当該AVファイル中の最初の1枚目の画像データとするように自動設定してもよい。
イントロは、各AVファイルの代表的な短時間のオーディオデータである。AVファイルのイントロは、ユーザが任意に付与することができるが、例えば、当該AVファイル中の最初の数秒間、例えば、5秒間のオーディオデータとするように自動設定してもよい。これらタイトル、サムネイルおよびイントロは、検索の便宜などを考慮の上、必要に応じてインデックスファイルに収容領域が用意される。また、プロパティのデータは、登録される必要があるが、タイトル、サムネイルおよびイントロの各収容領域が確保されていたとしても、タイトル、サムネイルおよびイントロのすべてのデータは、必ずしも登録される必要はない。
図5は、QuickTime ムービーファイルを用いて作成されるインデックスファイルの一例を示す図である。図5において、インデックスファイルは、インデックス・アトム201とインデックス・データ・アトム202とによって構成される。
インデックス・データ・アトム202には、プロパティ、テキスト、サムネイルおよびイントロの実データが収容される。そして、各AVファイルに係るプロパティ、テキスト、サムネイルおよびイントロの実データ231、232、233、234は、インデックス・データ・アトム202の第1番目以降の各領域であるエントリ#1〜エントリ#n(nは2以上の整数)にそれぞれ収容される。
インデックス・アトム201は、ムービー・ヘッダ・アトム211と、プロパティ、テキスト、サムネイルおよびイントロの実データにそれぞれ対応して、トラックアトム(プロパティ)212とトラックアトム(テキスト)213とトラックアトム(サムネイル)214とトラックアトム(イントロ)215とから構成される。なお、上述したように、トラックアトム(プロパティ)212およびプロパティの実データ231のみが必須である。
図6は、トラックアトム(プロパティ)の一例を示す図である。図6において、トラックアトム(プロパティ)212は、各AVファイルに対応するプロパティデータに係るチャンクとして定義された、AVファイルプロパティ#1、AVファイルプロパティ#2、・・・、AVファイルプロパティ#nのそれぞれについて、データ長L_PR1、L_PR2、・・・、L_PRn、および開始バイト位置0、L_PR1、L_PR1+L_PR2、・・・、L_PR1+・・・+L_PRn−1をそれぞれ示すテーブルの形式とされる。データ長は、例えば、バイト単位で表示される可変長である。
なお、トラックアトム(テキスト)、トラックアトム(サムネイル)、トラックアトム(イントロ)とテキストの実データ、サムネイルの実データ、イントロの実データのそれぞれとの関係も、上述したトラックアトム(プロパティ)とプロパティの実データの関係と同様のものとされている。
図7は、プロパティの実データの一例を示す図である。プロパティの実データは、エントリ管理情報とファイル属性情報とからなる。エントリ管理情報は、エントリ自身を管理するための情報であり、エントリ番号(entry number)、エントリプロパティ(entry property)およびフォルダプロパティ(folder property )からなる。
エントリ番号は、0から始まる番号であり、インデックスファイル内でのユニークな番号である。エントリ番号は、当該プロパティの実データが何れのエントリに収容されているかを示す。エントリ番号は、0バイト目を開始バイト位置とする4バイトのデータである。カメラ一体型ディジタル記録再生装置50は、このエントリ番号を検索することによって、インデックスファイルにおいてディスクタイトルが収容されている領域を見い出すことができる。
エントリプロパティは、4バイト目を開始バイト位置とする1バイトのデータであり、エントリの属性、状態を示すもので、各1ビットのエントリプロパティ1、エントリプロパティ2、エントリプロパティ3およびエントリプロパティ4が含まれている。
すなわち、エントリプロパティ1は、(0:フォルダ、1:ファイル)の識別を行い、エントリプロパティ2は、(0:ノーマル、1:システム)の識別を行う。ノーマルとは、上述したプロパティの実データのエントリを意味し、システムとは、後述するフラグの定義が記述されているエントリを意味する。フォルダプロパティは、5バイト目を開始バイト位置とする4バイトのデータであり、そのエントリが所属するフォルダを示すものである。
エントリプロパティ3は、エントリに関して(0:有効、1:無効)の識別を行い、エントリプロパティ4は、エントリに登録されたファイルが他のファイルを参照しているかどうかを示し、(0:参照なし、1:参照あり)の識別を行う。
ファイル属性情報は、バージョン(version )、フラグ(flags )、データタイプ(data type )、製作日時(creation time )、編集日時(modification time )、デュレーション(duration)、ファイル識別子(binary file identifier)、リファードカウンタ(referred counter)、リファリングファイルリスト(referring file list) 、およびURLファイルアイデンティファイア(URL file identifier) によって構成される。
バージョンは、9バイト目を開始バイト位置とする1バイトのデータであり、エントリに登録されたファイルのバージョン番号である。フラグは、10バイト目を開始バイト位置とする2バイトのデータであり、ファイルの属性を識別するためのものである。データタイプは、12バイト目を開始バイト位置とする1バイトのデータであり、当該プロパティに係るタイトルファイルまたはAVファイルにおけるデータの種類(動画、静止画、オーディオなど)を示す。
製作日時は、当該プロパティに係るタイトルファイルまたはAVファイルが製作された日時を示し、13バイト目を開始バイト位置とする4バイトのデータである。編集日時は、当該プロパティに係るタイトルファイルまたはAVファイルが修正された日時を示し、17バイト目を開始バイト位置とする4バイトのデータである。デュレーションは、当該プロパティに係るタイトルファイルまたはAVファイルが再生されるために必要とされる時間の長さを示し、21バイト目を開始バイト位置とする4バイトのデータである。ファイル識別子は、当該プロパティに係るファイルの所在を示すバイナリデータであり、25バイト目を開始バイト位置とする6バイトのデータである。
リファードカウンタは、ファイルが別のファイルから参照されている数を示し、31バイト目を開始バイト位置とする4バイトのデータである。リファリングファイルリストは、ファイルが別のファイルから参照されている場合、その参照元を示し、35バイト目を開始バイト位置とする可変長L RFのデータである。リファリングファイルリストは、エントリ番号または実際のファイルの所在を示すIDが記述される。URLファイルアイデンティファイアは、ファイルの所在を示すURL形式のデータであり、(35+L RF)バイト目を開始バイト位置とする可変長L FIのデータである。
上述したエントリ管理情報によって、図8に示すような仮想的な階層構造を持つことができる。図8Aは、#0から#8までの複数のエントリのそれぞれのプロパティ情報から抜き出されたエントリ管理情報の一例であり、図8Bは、図8Aに示すエントリ管理情報によって表される階層構造を示すものである。以下、エントリ管理情報によるAVファイルの管理について説明する。
図8の例では、エントリプロパティ1およびエントリプロパティ2によって、エントリ番号の#0,#3,#4がフォルダであり、#1,#5,#6,#7がファイルであり、#2および#8がシステム情報であることが示されている。エントリ#2および#8は、階層には含まれない。また、フォルダプロパティによって、エントリ番号#1および#3の上位がエントリ番号#0のフォルダであることが示され、エントリ番号#4および#5の上位がエントリ番号#3のフォルダであることが示され、エントリ番号#6および#7の上位がエントリ番号#4のフォルダであることが示されている。したがって、これらのエントリ管理情報によって図8Bに示す階層構造が規定される。
図9Aは、インデックスファイルを示し、図9Aに示すように、システム情報であるエントリ#2および#8は、他のノーマルのエントリと同様に、プロパティ、テキスト、サムネイルのデータによって構成されている。イントロは、必須ではないので、図9Bでは、イントロのデータをシステム情報のエントリ#2および#8が持っていない。そして、他のノーマルのエントリと同様に、システムのエントリは、インデックス・アトム201のトラックアトム(プロパティ)212、トラックアトム(テキスト)213、トラックアトム(サムネイル)214によって管理される。図9Bは、エントリの#0から#8までのプロパティ情報の一部を抜き取って示すもので、図8Aと同一のものである。
図10は、システムの情報であるエントリ#2において、フラグの情報を保持する例を示す。フラグは、2バイト(16ビット)であり、1がセットされているビット位置に応じてフラグの意味が規定されている。したがって、最大で16種類の属性をフラグによって定義することができる。定義できる最大数は、適宜制限することができる。図10の例では、フラグの第1バイトの先頭(MSB)から4番目のビットが1とされている。フラグの値は、0x1000(0xは16進数を表す表記である)である。この場合では、テキストのデータが" BASEBALL" とされ、サムネイルのデータが野球と関連したサムネイル(アイコン)とされる。
図11は、システムの情報であるエントリ#8において、フラグの情報を保持する例を示す。図11の例では、第1バイトのMSBから8番目のビットが1とされている。フラグの値は、0x0100である。この場合では、テキストのデータが" SKI" とされ、サムネイルのデータがスキーと関連したサムネイル(アイコン)とされる。
図10および図11に示す例は、1つのエントリによって、フラグの1ビットの意味を定義するものである。図12に示すように、1つのエントリ例えば#2によって、複数例えば2ビットのフラグの意味を定義するようにしても良い。例えば第1バイトのMSBから4番目および8番目のビットがそれぞれ1にセットされている。フラグの値は、0x1100である。この場合では、テキストデータが" BASEBALL" および" SKI"
とされ、野球に関連したサムネイル(アイコン)とスキーと関連したサムネイル(アイコン)との2枚のサムネイルのデータが記録される。
このように、1つのエントリにおいてフラグの複数ビットを定義する場合、フラグとテキストとサムネイルとの対応関係が予め決められている。例えばフラグのMSB側のビットから順番にテキストおよびサムネイルのそれぞれを並べるようになされる。テキストの場合は、任意の文字数で区切り、各区切りに順にテキスト情報が記録される。または、HTML(Hyper Text Markup Language)のような記述言語を使用してタグを埋め込むことによって、複数のテキストを区別しても良い。サムネイルも実際に格納するサムネイルのどの画素がひとつの絵を構成し、どの場所にある絵から対応させるのかというルールを設けたり、画素の位置情報を、テキストのタグを用いて格納したり、サムネイルのコメント情報に格納することでも対応できる。
図13は、エントリ#2によってフラグの2ビットの意味を定義する場合のファイルの整理の方法を示すものである。図13Aは、エントリ#0から#7までのエントリ管理情報およびフラグを示している。このエントリ管理情報(エントリ番号、エントリプロパティ1、エントリプロパティ2、フォルダプロパティ)は、図8または図9におけるエントリ#0から#7までの情報と同一である。また、エントリ#2は、システム情報であり、フラグが0x1100とされ、図12を参照して説明したように、二つのフラグの定義の情報を保持している。
ファイルであるエントリ#1のフラグは、0であり、このファイル#1の属性が規定されていない。エントリ#5のファイルの属性がフラグ0x1000によって、" BASEBALL" と規定されている。エントリ#6および#7のフラグが共に0x0100とされている。このフラグは、属性が" SKI" であることを示している。
上述した図13Aに示すエントリ管理情報とフラグによって、図13Bに示す階層構造が規定される。フラグによってファイルの属性情報を規定することができる。したがって、インデックスファイルが記録された記録媒体例えば光ディスクを再生する場合に、フラグで規定されるファイル属性を指定することによって、インデックスファイルの中で指定された属性のもののみを例えば表示することができる。さらに、表示されているインデックスファイルの中で所望のものを指定することによって、指定されたインデックスファイルに対応するAVファイルを指定することができる。したがって、ユーザが希望するAVファイルを高速に検索することができる。さらに、システム情報によってフラグの定義を記述するので、必要な範囲の定義を行なえば良く、データ量が増えない利点がある。また、記録媒体毎にフラグの定義が異なっていても良く、汎用性に優れている利点がある。
なお、予め機器がフラグを定義するシステム情報を持つ方法、並びにユーザ自身がフラグの定義を設定する方法の何れも採用することができる。例えば一実施形態では、フラグとして2バイト用意されているので、1バイトを機器例えば光ディスク記録再生装置を備えた撮像装置によって定義されるフラグに割り当て、他の1バイトをユーザが定義できるフラグに割り当てるようにしても良い。
次に、エントリ管理情報とファイルの属性情報の一部を用いて、エントリの参照関係を示す方法について説明する。図14Aは、エントリ#0からエントリ#7までのエントリの参照関係を示すのに必要なプロパティ情報の一例を示す。エントリプロパティ(1バイト)の中には、エントリプロパティ1からエントリプロパティ4までが規定される。エントリプロパティ1がファイルとフォルダの識別に使用され、エントリプロパティ2がノーマル情報とシステム情報との識別に使用される。フォルダプロパティは、上位のフォルダを示している。これらのエントリプロパティ1および2およびフォルダプロパティは、上述したものと同様のものである。
エントリプロパティ3は、エントリに関して(0:有効、1:無効)の識別を行い、エントリプロパティ4は、エントリに登録されたファイルが他のファイルを参照しているかどうかを示し、(0:参照なし、1:参照あり)の識別を行う。リファードカウンタは、ファイルが別のファイルから参照されている数を示し、リファリングファイルリストは、ファイルが別のファイルから参照されている場合、その参照元を示す。
図14Aの例では、全てのエントリが有効であり、エントリプロパティ3が全て0とされ、エントリ#5および#6に登録されたファイルが他のファイルを参照しているので、エントリ#5および#6のエントリプロパティ4が1とされている。また、エントリ#1のリファードカウンタが2とされ、二つのファイルから参照されている。参照元の二つのファイルは、リファリングファイルリストに示されているエントリ#5および#6にそれぞれ登録されているファイルである。
エントリ#1に登録されているAVファイルをAVファイルAとし、エントリ#5,#6,#7にそれぞれ登録されているAVファイルをAVファイルB,C,Dとする。図14Aに示すプロパティの情報と、図14Bに示すようなファイル同士の参照関係とが対応している。すなわち、エントリ#5,#6 にそれぞれ登録されファイルC,Dがエントリ#1に登録されたファイルAを参照しているので、エントリ#5,#6のエントリプロパティ4がそれぞれ1となり、エントリ#1のリファードカウンタが2となり、エントリ#1のリファリングファイルリストが5,6になっている。
記録媒体上に記録されているAVファイルの中で、あるAVファイルを削除しようとした場合、他のAVファイルから参照されているAVファイルを削除することができない。このことは、ファイルの属性情報中のリファードカウンタの値が0か、それ以外かで判定できる。図14の例では、AVファイルAのリファードカウンタの値が2であり、このファイルAを削除することができないことが分かる。
AVファイルを削除した場合に、対応するエントリをどのように処理するかは、二通りの方法が可能である。1つの方法は、図15に示すように、例えばAVファイルCを削除した場合に、対応するエントリ#6を実際に削除する方法である。他の方法は、図16に示すように、エントリ#6を削除しないで、エントリ#6のエントリプロパティ3の値を無効を意味する値(1)に変更する方法である。何れの方法を使用しても良い。
AVファイルの削除に伴ってエントリを実際に削除する方法は、記録媒体の容量の面で、エントリを削除しない方法に比して有利である。処理時間の点から見ると、エントリを実際に削除する方法は、エントリの実データのみならず、トラックアトムを書き換える必要があるので、エントリを削除しない方法に比して不利である。
図17を参照してファイル削除処理について説明する。この処理は、例えば図2参照して説明したカメラ一体型ディジタル記録再生装置において、そのシステムコントローラ(マイクロコンピュータ)の制御によってなされる。最初のステップS1において、ファイル一覧表示において、ファイル(AVファイル)xの削除が選択される。例えば表示パネル(図2参照)上に表示されているファイルの一覧、画面を分割して表示される複数のサムネイル等から削除したいファイルxを選択する。
ステップS2では、インデックスファイル中でファイルxが登録されているエントリのリファードカウンタの値が0か否かが判定される。0でない場合は、他のファイルがファイルxを参照していることを意味するので、ファイルxが削除できないので、例外処理がなされる(ステップS3)。例えばユーザに対して、削除できない旨のメッセージを表示する。
ステップS2でリファードカウンタの値が0と判定されると、ステップS4では、エントリプロパティ4の値が1か否かが判定される。すなわち、ファイルxが他のファイルを参照しているか否かが決定される。エントリプロパティ4=1の場合では、ステップS5において、リファリングファイルリストがファイルxのエントリ番号(ファイルxのIDの場合もある)であるエントリ、すなわち、ファイルxによって参照されているエントリを探す。
ステップS6では、そのようなエントリの有無が決定される。エントリが無いと判定される場合では、ステップS7において、例外処理がなされる。例えばデータの不整合がある旨のメッセージがユーザに提示される。ステップS4において、エントリプロパティ4が1であったので、本来は、ファイルxが参照しているエントリが存在するはずである。にもかかわらず、そのようなエントリが無いことは、データの不整合が存在していることを意味する。
ステップS6においてファイルxによって参照されているエントリがあると判定されると、ステップS8では、そのエントリのリファードカウンタの値がデクリメントされる。そして、ステップS9において、リファリングファイルリストからファイルxのエントリ番号(ファイルxのIDの場合もある)が削除される。
次に、ステップS10において、ファイルxのエントリを削除するか否かが判定される。図17の処理では、AVファイルxを削除する場合に、インデックスファイル中の対応するエントリを実際に削除するか否かを選択することが可能とされている。例えば記録媒体の残りの空き容量の多寡から処理を選択するようになされる。残りの空き容量が多い場合では、エントリを削除しない方法が選択され、残りの空き容量が少ない場合では、エントリを実際に削除する方法が選択される。
ステップS10において、ファイルxに対応するエントリを削除する処理が選択されると、図15に示すように、ステップS11において、インデックス・データ・アトムから対応するエントリが削除され、ステップS12において、削除したエントリ以降のデータが移動され、空いた論理空間が埋められる。そして、ステップS13において、インデックスアトムにおいて、管理ファイルのデータが更新される。若し、ステップS10において、ファイルxに対応するエントリを削除しないと決定した場合では、ステップS15において、そのエントリのエントリプロパティ3の値を1(無効エントリを意味する)に更新する。
ステップS13またはS15までの処理は、システム例えばカメラ一体型ディジタル記録再生装置のシステムコントローラに備えられた半導体メモリ上でのデータの書き換え処理である。そして、記録媒体をイジェクトする直前、一定時間毎等の適切なタイミングでもって、記録媒体のデータが更新される(ステップS14)。すなわち、記録媒体上のAVファイルxの削除、並びに記録媒体上のインデックスファイルの更新が行なわれる。
次に、ファイルの削除後に、新規にエントリを追加する処理について図18を参照して説明する。ステップS21では、ファイルXの追加処理が開始される。ステップS22において、エントリプロパティ3によって無効と示されているエントリが探される。ここでは、エントリプロパティ3の値が1のエントリが無効と規定されている。
無効のエントリがあるとステップS22において決定されると、ステップS23において、無効エントリの領域に新たなエントリが上書きされる。図19は、例えばエントリ#6が無効エントリの場合の処理を示している。インデックスファイル中の管理データであるインデックスアトムを書き換えることは不要である。
一方、ステップS22において、無効エントリが無いと決定されると、ステップS25において、インデックスファイルの任意の場所に新規のエントリ情報が追加される。ステップS26では、インデックスアトムのトラック毎の管理情報が追加されたエントリを規定するように更新される。図20は、エントリ#nとして新規のエントリを追加する処理を示している。
ステップS23またはS26までの処理は、システム例えばカメラ一体型ディジタル記録再生装置のシステムコントローラに備えられた半導体メモリ上でのデータの書き換え処理である。そして、記録媒体をイジェクトする直前、一定時間毎等の適切なタイミングでもって、記録媒体のデータが更新される(ステップS24)。
このように、プロパティ情報がファイルの参照関係の情報を持っているので、実際のファイルにアクセスしないで、参照関係を管理することができ、消去の可否を高速に判断することができる。
この発明は、上述したこの発明の一実施形態等に限定されるものでは無く、この発明の要旨を逸脱しない範囲内で様々な変形や応用が可能である。例えばこの発明は、ディジタルオーディオ信号を記録再生する場合に対しても適用できる。例えばフラグによってAVファイル(楽曲データ)のジャンル(クラシック、ジャズ、ロック、ポピュラー等)を識別するようにしても良い。また、フラグに記述されている属性情報を定義する場合、そのインデックスファイル全体の範囲に関して属性情報を定義したり、インデックスファイルの一部の所定の範囲で属性情報を定義するようにしても良い。さらに、上述した説明では、QuickTime を使用する例について述べたが、他のアプリケーションソフトウェアを使用する場合にこの発明を適用しても良い。