(57)【特許請求の範囲】
【請求項１】
複数のオブジェクトファイルを複数のディレクトリに格納して記録媒体に記録する記録装置であって、
前記ディレクトリに格納されたオブジェクトファイルのファイル名と前記オブジェクトファイルを識別するためのＩＤ属性とを含むディレクトリ管理ファイルを、前記複数のディレクトリについてそれぞれ生成する手段と、
前記複数のオブジェクトファイルを複数のグループに分け、前記オブジェクトファイルが格納されたディレクトリのディレクトリ管理ファイル名と前記オブジェクトファイルのＩＤ属性の値とにより各グループに含まれるオブジェクトファイルを指定したグループ管理ファイルを生成する手段と、
前記グループ管理ファイルと、前記複数のディレクトリについて生成された複数の前記ディレクトリ管理ファイルとを前記記録媒体に記録する記録手段とを備える記録装置。
【請求項２】
前記ディレクトリ管理ファイルは前記オブジェクトファイルを指定している前記グループ管理ファイルの数を示す参照数属性を含むことを特徴とする請求項１記載の記録装置。
【請求項３】
前記ディレクトリ管理ファイルを生成する手段は、前記オブジェクトファイルが新たに前記グループ管理ファイルにより指定される度に対応する前記オブジェクトファイルの前記参照数属性の値を増加し、前記オブジェクトファイルが前記グループ管理ファイルによる指定から解除される度に対応する前記オブジェクトファイルの参照数属性の値を減少することを特徴とする請求項２記載の記録装置。
【請求項４】
複数のオブジェクトファイルを複数のディレクトリに格納して記録媒体に記録する記録装置であって、
前記ディレクトリに格納されたオブジェクトファイルのファイル名と前記オブジェクトファイルを識別するためのＩＤ属性とを含むディレクトリ管理ファイルを、前記複数のディレクトリについてそれぞれ生成する手段と、
前記オブジェクトファイルが格納されたディレクトリのディレクトリ管理ファイル名と前記オブジェクトファイルのＩＤ属性の値とにより、前記記録媒体に記録されている複数のオブジェクトファイルのうち再生を開始すべきオブジェクトファイルを指定した記録媒体管理ファイルを生成する手段と、
前記記録媒体管理ファイルと、前記複数のディレクトリについて生成された複数の前記ディレクトリ管理ファイルとを前記記録媒体に記録する記録手段とを備える記録装置。
【請求項５】
前記記録媒体から前記オブジェクトファイルを再生する再生手段を備え、前記記録媒体管理ファイルを生成する手段は前記オブジェクトファイルの再生停止指示に応じて前記記録媒体管理ファイルの内容を変更することを特徴とする請求項４記載の記録装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、対象となるオブジェクトを効率良く管理する記録装置に関する。
【０００２】
【従来の技術】
現在、デジタルカメラやデジタルディスクカムコーダのデータ記録媒体の容量は膨大なものになり、動画、音声、静止画など多岐に渡るデータファイルを、コンパクトフラッシュ（登録商標）メモリやＭＯディスクなどランダムアクセス可能な記録媒体に記録できるようになってきた。デジタルディスクカムコーダで手軽に静止画や動画を撮影できることから、フィルムを使用していた頃に比べ、撮影データ量は飛躍的に増加している。
【０００３】
しかし、膨大な数のデータファイルを管理するのは容易なことではない。そこで、自動的にグループ化したりユーザが気に入ったものをグループ化したりして、データファイルの検索性を向上させようとする試みが行われるようになってきた。また、データのランダムアクセス性を生かし、再生制御スクリプトを用いた非破壊的な動画編集機能を提供するようになってきた（例えば、特許文献１参照）。
【０００４】
【特許文献１】
特開２０００−１８７９６３号公報
【０００５】
【発明が解決しようとする課題】
このように、記録媒体に格納されたデータは、グループ化の対象となったり再生制御スクリプトの参照対象になったりすることで、データ単独ではなく、他の情報と共存するようになった。したがって、ファイルを削除する際に、常にグループや再生制御スクリプトからの参照を管理する必要がある。しかし、膨大な数のファイルと、それらの参照関係を完全に管理するのは困難である。
【０００６】
例えば、あるファイルに対して、管理ファイルや再生制御スクリプトから直接ファイル名で参照した場合、そのファイルのファイル名を変更しようとすると、そのファイルを参照している全ての管理ファイル、再生制御スクリプトの内容を更新しなくてはならない。
【０００７】
本発明は上記問題点を鑑みてなされたものであり、ファイルの管理コストを局所化し、管理コストを低減すると共に、管理ファイル破損時のリスク分散を図ることを目的とする。
【０００８】
【課題を解決するための手段】
上記目的を達成するために、複数のオブジェクトファイルを複数のディレクトリに格納して記録媒体に記録する記録装置は、前記ディレクトリに格納されたオブジェクトファイルのファイル名と前記オブジェクトファイルを識別するためのＩＤ属性とを含むディレクトリ管理ファイルを、前記複数のディレクトリについてそれぞれ生成する手段と、前記複数のオブジェクトファイルを複数のグループに分け、前記オブジェクトファイルが格納されたディレクトリのディレクトリ管理ファイル名と前記オブジェクトファイルのＩＤ属性の値とにより各グループに含まれるオブジェクトファイルを指定したグループ管理ファイルを生成する手段と、前記グループ管理ファイルと、前記複数のディレクトリについて生成された複数の前記ディレクトリ管理ファイルとを前記記録媒体に記録する記録手段とを備える。
【０００９】
また、本発明の別の形態によれば、複数のオブジェクトファイルを複数のディレクトリに格納して記録媒体に記録する記録装置であって、前記ディレクトリに格納されたオブジェクトファイルのファイル名と前記オブジェクトファイルを識別するためのＩＤ属性とを含むディレクトリ管理ファイルを、前記複数のディレクトリについてそれぞれ生成する手段と、前記オブジェクトファイルが格納されたディレクトリのディレクトリ管理ファイル名と前記オブジェクトファイルのＩＤ属性の値とにより、前記記録媒体に記録されている複数のオブジェクトファイルのうち再生を開始すべきオブジェクトファイルを指定した記録媒体管理ファイルを生成する手段と、前記記録媒体管理ファイルと、前記複数のディレクトリについて生成された複数の前記ディレクトリ管理ファイルとを前記記録媒体に記録する記録手段とを備える。
【００１４】
【発明の実施の形態】
以下、添付図面を参照して本発明の好適な実施の形態を詳細に説明する。
【００１５】
＜第１の実施形態＞
まず、図１を用いて本発明の第１の実施形態における装置の一例を説明する。本第１の実施形態における情報記録再生装置としてのビデオカムコーダ装置は、主として記録媒体であるディスク１９と、ディスク１９に対して動画像、静止画像、音声などのメディア・データの書き込み、読み出しを行うピックアップ１と、読み出された信号を増幅するRFアンプ２と、エンコーダ・デコーダ/信号処理回路３と、データを一時的に格納するショックプルーフメモリ５と、ショックプルーフメモリ５をコントロールするメモリコントローラ４と、復号化・符号化回路６と、D/AコンバータとA/Dコンバータとから成るコンバータ７と、送りモータ８と、スピンドルモータ９と、ドライバ回路１０と、サーボ制御回路１１と、種々の制御を行うシステムコントローラ１２と、電源回路１３と、ヘッド駆動装置１４と、記録ヘッド１５と、入力装置１６と、カメラ部１７と、映像音声出力端子１８とを備えている。なお、本第１の実施形態に置いてはディスク１９とは例えば、光磁気ディスク（以下、MO）とするが、ディスク１９の種類はMOに限らないことは言うまでもない。
【００１６】
上記構成によれば、再生時、ドライバ回路１０に駆動されるスピンドルモータ９によりMO１９が回転駆動されるとともに、ドライバ回路１０に駆動される送りモータ８によりピックアップ１がMO１９の半径方向に送られ、このピックアップ１により読み出されたデータは、RFアンプ２において増幅され、エンコーダ・デコーダ/信号処理回路３に送られる。
【００１７】
また、RFアンプ２は、上記データに基づいて、フォーカスエラー信号やトラッキングエラー信号などのサーボ制御信号を生成し、これをサーボ制御回路１１に出力する。サーボ制御回路１１は、RFアンプ２からのサーボ制御信号と、システムコントローラ１２からのコントロール信号に基づいて、ピックアップ１、送りモータ８、スピンドルモータ９を駆動する。
【００１８】
上記エンコーダ・デコーダ/信号処理回路３は、RFアンプ２で増幅された信号を復調し、さらに誤り訂正などの信号処理を行った後、メモリコントローラ４に送る。メモリコントローラ４は、エンコーダ・デコーダ/信号処理回路３から送られてきた信号をショックプルーフメモリ５に書き込む。ショックプルーフメモリ５には、メディア・データの記録領域とは別にメディア・データ以外のTOC(Table of Contents)情報を格納するための領域が設けられており、MO１９が装置に挿入されると直ちにメディア・データと同様の経路でMO１９に格納されているTOC情報がショックプルーフメモリ５の所定領域に格納される。
【００１９】
メモリコントローラ４は、システムコントローラ１２の要求に応じて必要なTOC情報をショックプルーフメモリ５から読み出してシステムコントローラ１２に送る。システムコントローラ１２は、ショックプルーフメモリ５に記憶されたデータを読み出し、復号化・符号化回路６に送る。復号化・符号化回路６は、図示しないデータ復号化回路によって、送られたデータを所定のフォーマットにしたがって符号化処理を解き、コンバータ７内のD/Aコンバータへ送る。D/Aコンバータは、復号化されたメディア・データをアナログ信号に変換する。このアナログ信号は、出力端子１８より外部へ出力される。
【００２０】
また、システムコントローラ１２は、電源回路１３を制御し、ピックアップ１、RFアンプ２、エンコーダ・デコーダ/信号処理回路３、サーボ制御回路１１、およびドライバ回路１０へ電源を供給したり中断したりする。
【００２１】
入力装置１６とは、例えばポーズボタンや再生ボタン、再生/録画モード切替スイッチ、画像選択用カーソルキーなどが考えられる。
【００２２】
記録時は、カメラ部１７から入力されたアナログ映像音声信号をコンバータ７内のA/Dコンバータへ送る。A/Dコンバータは、アナログ映像音声信号をデジタル信号に変換する。このデジタル信号は、復号化・符号化回路６において、図示しないデータ符号化回路によって所定のフォーマットに符号化され、メモリコントローラ４によってショックプルーフメモリ５に格納される。このメモリコントローラ４は、システムコントローラ１２の制御下でショックプルーフメモリ５に格納されているデータを読み出し、エンコーダ・デコーダ/信号処理回路３に送る。エンコーダ・デコーダ/信号処理回路３では、読み出したデータに対して、変調、誤り訂正用符号の付加などを行う。
【００２３】
システムコントローラ１２は、メモリコントローラ４を制御し、ショックプルーフメモリ５の所定領域に格納されているTOC情報を読み出し、このTOC情報に基づいてMO１９上の記録可能領域の位置を認識し、サーボ制御回路１１を制御して所望の記録可能領域をサーチする。サーチ後、システムコントローラ１２の制御下で、エンコーダ・デコーダ/信号処理回路３の出力信号に基づいてヘッド駆動装置１４が記録ヘッド１５を駆動すると共に、RFアンプ２の出力信号に基づいてピックアップ１の図示しないレーザ回路が駆動され、MO１９上にデータを記録する。
【００２４】
所望の記録可能領域への記録動作が終了すると、システムコントローラ１２はメモリコントローラ４を制御し、ショックプルーフメモリ５に格納されているTOC情報と、MO１９のTOC情報とを書き換え、以降これを最新のTOC情報として利用することによってMO上に記録されているデータの管理などを行う。
【００２５】
このようなビデオカムコーダ装置において、本発明による情報記録再生装置を実現するための詳細について以下で述べる。まず、対象となるデータのフォーマットについて述べ、次にそれらのデータの処理方法について述べる。
【００２６】
１．対象となるデータのフォーマット
本発明の情報記録再生装置で扱うデータと、そのデータ形式について述べる。まずビデオカムコーダ装置で記録するデータの種類について述べ、各データを格納するディレクトリ構造、管理ファイル、プレイリストの詳細について順に述べる。
【００２７】
本発明の情報記録再生装置は、ディレクトリ単位にファイルを管理するディレクトリ管理ファイルと、対象ファイルを直接参照するのではなくディレクトリ管理ファイルのエントリを参照して実現するファイルのグルーピング、および再生制御ファイル（プレイリスト）に特徴がある。
【００２８】
・ビデオカムコーダ装置で記録するデータ
ビデオカムコーダ装置で記録するデータは、動画、静止画と音声である。また、動画・静止画・音声を組み合わせて再生するための再生制御スクリプト（以下、プレイリスト）の作成機能を持つ。プレイリストの詳細については後述する。
【００２９】
動画データは、MPEG2で符号化して記録する。データ形式は、PS(Program Stream)もしくはTS(Transport Stream)で、機器のメニューでどちらの形式で保存するか決定できる。
【００３０】
音声データは、MP3（MPEG Audio Layer3）形式で記録する。
【００３１】
静止画データは、DCF規格(Design rule for Camera File system)に準拠した方式で記録する。
【００３２】
これらのデータを管理するため、記憶媒体管理ファイルと、ディレクトリ管理ファイルと、データのグループ化情報を保持するグループ管理ファイルを持つ。これらの管理ファイルの詳細については後述する。
【００３３】
・データの格納方式
図２に、動画データ、音声データ、静止画データ、プレイリスト、および管理ファイルを記録媒体上に格納した状態の一例を示す。以後、本発明の情報記録再生装置で記録される動画、音声、静止画データを総称して、メディア・オブジェクトと呼ぶ。 拡張子が「.4C」であるファイルは、後述する管理ファイルである。
【００３４】
プレイリストは、記録媒体上のルートディレクトリの直下に作成されたPLAYLISTディレクトリに格納する。PLAYLISTディレクトリ下に、プレイリストを格納するPLディレクトリを作成し、PLディレクトリにプレイリストファイル(PLF)を格納する。
【００３５】
動画データは、記録媒体のルートディレクトリの直下に作成されたVIDEOディレクトリに格納する。VIDEOディレクトリ下に、動画データを格納する動画ディレクトリを作成し、動画ディレクトリに動画データを格納する。
【００３６】
本第１の実施形態では、一つの動画ディレクトリに１つ以上の動画データを格納する。一つの動画ディレクトリに複数の動画データを纏める方法については後述する。
【００３７】
音声データも動画データと同様に記録するが、記録媒体上の音声データのファイル数は比較的少ないと予想される。そこで本第１の実施形態では、単純に100ファイルごとにまとめて音声ディレクトリに格納する。音声ディレクトリは、記録媒体上のルートディレクトリの直下に作成されたAUDIOディレクトリ下に作られる。
【００３８】
静止画データは、DCF規格で定められた通り、記録媒体のルートディレクトリの直下に作成されたDCIMディレクトリに格納する。実際に静止画ファイルが格納されるのは、DCIMディレクトリの下に作成された静止画ディレクトリである。
【００３９】
PLディレクトリ、動画ディレクトリ、音声ディレクトリ、および静止画ディレクトリには、それぞれディレクトリに格納されたファイルを管理するディレクトリ管理ファイルを格納する。
【００４０】
ディレクトリ管理ファイル以外の管理ファイルは、ルートディレクトリの下にMANAGEディレクトリの下に配置する。記録媒体管理ファイルは、予め定められたディレクトリ、例えば本第１の実施形態では VOLUMEディレクトリに格納する。グループ管理ファイルは、システムが自動的に生成したグループをGrpDateディレクトリに、ユーザが作成したグループをGrpUserディレクトリに記録する。さらに、GrpDateディレクトリとGrpUserディレクトリにも、ディレクトリ管理ファイルを配置する。
【００４１】
本第１の実施形態による情報記録再生装置では、再生対象となる動画や音声、静止画を記録する際、記録日時に応じて自動的にグルーピングを行う。したがって、システムが自動的に生成するグループとは、この日付によるグループであり、グループ管理ファイルを格納するディレクトリ名もGrpDateとした。
【００４２】
・管理ファイルの基本書式
管理ファイルの詳細な説明として、まず管理ファイルの書式について述べ、次にディレクトリ管理ファイル、記録媒体管理ファイル、グループ管理ファイルの詳細について述べる。
【００４３】
管理ファイルは、XML形式で記述されたテキストファイルである。管理ファイルを構成するXML文書のエレメント構成を図３に示す。また、図２中に示した動画ディレクトリ「MOV00010」のディレクトリ管理ファイルの記述例を、図４に示す。
【００４４】
図３において、COLLECTIONエレメントは、管理情報のルート要素である。
【００４５】
GROUPエレメントは、動画、静止画、音声などのメディア・オブジェクトをグループ化するために用いる。GROUPエレメントは、GROUP_NAMEアトリビュートを持ち、GROUP_NAMEアトリビュートで、グループ名を記述する。
【００４６】
[MEDIA]のIMGエレメントは、静止画データのエントリを記述するために用いる。IMGエレメントは、srcアトリビュート、idアトリビュート、typeアトリビュート、参照カウントアトリビュート、deletedアトリビュートを持つ。srcアトリビュートはファイル名の記述に用い、idアトリビュートはファイルの識別名を記述するために用いる。idアトリビュートで指定する識別名は、管理ファイル内でユニークでなくてはならない。例えば本第１の実施形態では、対象となるファイルのUUID(Universal Unique ID)を16進数にした文字列をidアトリビュート値とする。typeアトリビュートはファイルの種類を表し、静止画の場合は「image」値をとる。また、printCountアトリビュートを持ち、画像が印刷された回数を保持する。本第１の実施形態ではプリント枚数を保持することにしたが、プリントされたかどうかを示すalreadyPrintアトリビュートを持っても良い。alreadyPrintアトリビュート値は、「true」か「false」である。
【００４７】
参照カウントアトリビュートには、PLF_linkCountアトリビュート、SYSTEM_linkCountアトリビュート、USER_linkCountアトリビュートの３つがある。それぞれ、PLFからの参照数、システムが自動生成したグループからの参照数、ユーザが任意に設定したグループからの参照数を示す。したがって、これらのアトリビュート値は整数値である。deletedアトリビュートは削除情報で、アトリビュート値は「true」か「false」である。linkCountアトリビュート値が０で無い時にファイルを削除した場合、deletedアトリビュート値を「true」にする。
【００４８】
また、[MEDIA]のMOVエレメントは、動画データのエントリを記述するために用いる。MOVエレメントは、IMGエレメントと同様、srcアトリビュート、idアトリビュート、typeアトリビュート、参照カウントアトリビュート、deletedアトリビュートを持ち、さらにdurアトリビュートを持つ。typeアトリビュート値は、動画の場合は「movie」である。durアトリビュートは、動画データ全体の再生時間を記述し、clock値をとる。clock値(Clock-value)は、次の書式で表される。
Clock-value        ::= ( Full-clock-value | Partial-clock-value |Timecount-value )
Full-clock-value    ::= Hours ":" Minutes ": "Seconds ("." Fraction)?
Partial-clock-value ::= Minutes ":" Seconds ("." Fraction)?
Timecount-value    ::= Timecount ("." Fraction)? (Metric)?
Hours               ::= DIGIT+; any positive number
Minutess            ::= 2DIGIT; range from 00 to 59
Seconds            ::= 2DIGIT; range from 00 to 59
Fraction            ::= DIGIT+
Timecount          ::= DIGIT+
2DIGIT              ::= DIGIT DIGIT
DIGIT                ::= [0-9]
【００４９】
例えば、14分3秒の場合、「00:14:03」もしくは「14:03」と記述する。
また、[MEDIA]のAUDエレメントは、音声データのエントリを記述するために用いる。AUDエレメントは、MOVエレメントと同様、srcアトリビュート、idアトリビュート、typeアトリビュート、参照カウントアトリビュート、deletedアトリビュート、durアトリビュートを持つ。typeアトリビュート値は、音声の場合は「audio」である。
【００５０】
また、[MEDIA]のPLFエレメントは、PLFのエントリを記述するために用いる。PLFエレメントは、MOVエレメントと同様、srcアトリビュート、idアトリビュート、typeアトリビュート、linkCountアトリビュート、deletedアトリビュート、durアトリビュートを持つ。PLF自身も他のプレイリストから参照される可能性があるので、PLFエレメントにもlinkCountアトリビュートとdeletedアトリビュートが用意されている。typeアトリビュート値は、PLFの場合は「playlist」である。
【００５１】
MOV、AUD、IMG、PLFエレメントは、MRKエレメントを子に持つことができる。MRKエレメントは、親エレメントで示されるメディア・オブジェクトの再生時間上での位置と範囲を指し示すタグである。
【００５２】
例えば、あるオブジェクトファイルの再生中に一時停止した場合、あるいは再生を停止した場合、その停止位置の情報をMRKエレメントとして記述しておき、後述の様に記録媒体管理ファイルにより次回の再生時に再生を停止した位置より再び再生を開始することが可能となる。
【００５３】
MRKエレメントは、SRCアトリビュートとINアトリビュート、DURアトリビュート、AUTOアトリビュートを持つことができ、SRCアトリビュートで指し示す位置に対応するサムネイル画像ファイルのファイル名、INアトリビュートで指定位置、DURアトリビュートで指定範囲を指定可能である。INアトリビュートの書式は、SMIL2.0のbeginアトリビュートの書式に従い、DURアトリビュートの書式は前記clock値に従う。AUTOアトリビュート値は「true」か「false」をとり、「true」の場合、INアトリビュートとDURアトリビュートによって、そのファイルがオートスタート再生対象ファイルである場合の再生範囲を示す。INアトリビュートが省略された場合、データの先頭位置を指し、DURアトリビュートが省略された場合は、データ全体を示す範囲となる。
【００５４】
通常、再生中に停止した場合にはINアトリビュート値のみを記述し、また、AUTOアトリビュート値を「true」とする。
【００５５】
また、MARKアトリビュートを栞として使用する場合、ユーザは、オブジェクトファイルの任意の位置でマーク指示を行い、更に、再生範囲や自動再生を行うか否かということも指定することができる。
【００５６】
このMRKエレメントにより、例えば「動画ファイル「MOV_0001.MPG」の先頭から10秒目を開始点として20秒分を、アイコン画像「THM_0001.THM」で指し示す」という記述は、次のようになる。
＜MOV SRC="MOV_0001.MPG … ＞
＜MRK SRC="THM_0001.THM" IN="10s" DUR="20s" AUTO="true" /＞
＜/MOV＞
【００５７】
この例では、AUTOアトリビュートが「true」なので、動画ファイル「MOV_0001.MPG」がオートラン再生の対象となっている場合、記録媒体のセットアップ後、MRKエレメントで指定された部分が自動再生される。記録媒体のセットアップとは例えば、記録媒体がMOの場合、メディアがドライブに挿入されて読み出し可能になるまでのシーケンスである。
このために、後述の様に、記録媒体管理ファイル内に自動再生すべきファイルを指定しておく。
【００５８】
AUTOアトリビュート値がfalseの場合、そのオブジェクトファイルの先頭位置から再生を開始する。
【００５９】
また、MRKエレメントと同様の位置に、ICONエレメントを持つこともできる。ICONエレメントはSRCアトリビュートを持ち、このアトリビュートで、対象となるメディア・オブジェクトを表す代表画像を関連づけることができる。したがって、ICONエレメントは、MRKエレメントとは異なり、INアトリビュートとDURアトリビュートを持たない。
【００６０】
本実施の形態では、メディア・オブジェクトの付加情報として、MRKエレメントによる栞機能と、ICONエレメントによる代表画像指定機能を挙げたが、同様の方法によって、再生時間テーブルや更なる付加情報を含むファイルを参照しても良いことは言うまでもない。更なる付加情報を表現するために、例えばMPEG7やDIG35などで規定されたメタデータを別ファイルにして保持し、メディア・オブジェクトのエントリから参照することが考えられる。
【００６１】
次に、ディレクトリ管理ファイル、記録媒体管理ファイル、グループ管理ファイルの詳細について述べる。
【００６２】
・ディレクトリ管理ファイル
ディレクトリ管理ファイルは、動画ディレクトリや音声ディレクトリなど、再生対象となるメディア・オブジェクトを格納したディレクトリの管理情報ファイルである（図４）。ディレクトリ管理ファイルを構成するデータは、ディレクトリに格納されるファイルのリストを示す要素を、COLLECTIONエレメントで括った形になっている。
【００６３】
・記録媒体管理ファイル
記録媒体管理ファイルは、記録媒体の識別情報を格納した管理情報ファイルである。記録媒体管理ファイルの一例を図１４に示す。
【００６４】
記録媒体の識別IDとして、COLLECTIONエレメントにVOLUME_IDアトリビュートを持つ。VOLUME_IDアトリビュート値は、UUIDを16進数表記にしたテキスト文字列である。CREATE_DATEアトリビュートは記録媒体の初期化日時、MODIFY_DATEアトリビュートは記録媒体に記録されたデータの最新更新日時を示す。TITLEアトリビュートで、記録媒体にタイトルをつける事もできる。また、WRITE_PROTECTアトリビュートを持ち、このアトリビュート値が「true」の場合、この記録媒体は書込み禁止指定されているので、記録媒体管理ファイル以外の記録媒体上のファイルを書き換えない。
【００６５】
記録媒体管理ファイルには、COLLECTIONエレメントの子として再生対象となるメディア・オブジェクト、もしくはプレイリストファイルを登録することができる。登録されたファイルは、記録媒体がセットアップされた後自動的に再生される。
【００６６】
例えば、前述の様に、再生途中で停止した場合などは、この時に再生していたファイル名をここに記述することで、次回のセットアップ時に自動的に再生停止位置より再生を開始することができる。
【００６７】
複数のファイル名が記載されていた場合には、記載順に再生する。ファイルの指定は、file値で行う。file値(file-value)は、次の書式で表される。
file-value ::= Manage-filename "#xpointer(//"
Element-name "[@id=" Object-id "])"
【００６８】
ここで、Manage-filenameは、対象となるファイルが格納されているディレクトリ管理ファイル名である。Element-nameは、対象となるエントリのエレメント名で、例えば動画データなら「MOV」になる。Object-idは対象となるデータのエントリに付与されているidアトリビュート値である。このようにファイル名の指定はディレクトリ管理ファイル内のエントリを参照することによって行うことで、ファイルそのものの管理はディレクトリ管理ファイルによる管理に局所化し、記録媒体管理ファイルはファイルそのものの管理を行わなくても良い。
この参照方法は、グループ管理ファイルやプレイリストでも同様の方法を採用しており、記録媒体に格納されたファイルの管理コストを大幅に低減することが可能になる。また、このファイル参照の記述方法はW3Cで規定されたXPath/XPointer仕様に準拠しており、汎用性が高い。
【００６９】
この参照方法によって、例えば一つのファイルが記録媒体管理ファイル、グループ管理ファイル、プレイリストファイル全てから参照されていたとしても、ファイル名変更時には、ディレクトリ管理ファイルの内容を更新するだけで良い。この参照方法を用いずに、各々の管理ファイルやプレイリストがファイル名を直接参照していた場合には、ファイル名の変更の際全ての管理ファイル、プレイリストを走査して、当該ファイルを参照しているエントリを全て更新しなくてはならない。
【００７０】
さらに、DIG35などに代表される、XMLによるメタデータ記述をCOLLECTIONエレメントの子として設定されたMETADATAエレメントの下に持つことで、より詳細な記録媒体情報を保持することもできる。
【００７１】
・グループ管理ファイル
グループ管理ファイルは、メディア・オブジェクトをグループ化する場合に使用する。グループ管理ファイルは、COLLECTIONエレメントの下にGROUPエレメントを配し、GROUPエレメントの子として、グループ化対象となるメディア・オブジェクトのエントリを並べることで、グループ化されたファイルのリストを記述する。図１５に、記述例を示す。図１５に示した例は、動画ファイルと静止画ファイルの計２ファイルをグループ化した場合の記述例である。
【００７２】
GROUPエレメントは、GROUP_TYPEアトリビュートを持ち、このアトリビュートで自動的に作成されたグループか、ユーザが任意に作成したグループかを判別する。GROUPエレメントは、その他にCREATE_DATEアトリビュートとMODIFY_DATEアトリビュートを持ち、それぞれのアトリビュートで、グループの作成日時と更新日時を保持する。また、ICONアトリビュートでグループの代表画像、TITLEアトリビュートでグループのタイトルを保持することもできる。グループ化対象となるファイルのファイル名は、記録媒体管理ファイルと同様に、ディレクトリ管理ファイルを利用した間接参照を行う。したがって、ファイル名はfile値で参照する。
【００７３】
・プレイリスト
プレイリストは、SMILに準拠した形式で記述する。ただし、再生オブジェクトのファイル名指定を行うsrcアトリビュート値は、前述のfile値をとる。このように、プレイリストから各ファイルへの参照をidアトリビュート値を介して行うことで、例えファイル名が変更された場合でも、管理ファイルのエントリ内のsrcアトリビュート値だけを変更するだけで良い。
【００７４】
例えば、/DCIM/101CANON/101CANON.4C内に、「IMG_0001」という識別子を持つ静止画データがあるとする。このファイルを参照する場合には、
'/DCIM/101CANON/101CANON.4C#xpointer(//[@id="IMG_0001"])'
【００７５】
と記述して参照する。図５に、プレイリストの記述例を示す。また、図５の場合の管理ファイルとプレイリストの参照関係を示す図を図６に示す。図６では、プレイリストモPLF_0001.SMIモで動画ファイル２つと音声ファイルの再生指定を行っているが、プレイリストから参照しているのは各々のファイルが格納されているディレクトリ管理ファイルである。このディレクトリ管理ファイルは、記録媒体管理ファイル「VOLUME.4C」やグループ管理ファイル「GRP_0001.4C」からも参照されており、ファイル自身を直接管理するファイルはディレクトリ管理ファイルだけという形になっている。
プレイリスト再生時、参照しているエントリのdeletedアトリビュート値が「true」の場合がある。前述の通り、参照先のファイルが消去された場合である。この状況に関する処理については後述する。
【００７６】
２．データの処理方法
１．で説明したデータを処理する方法について、以下で述べる。まず、１つ以上の動画データを一つの動画ディレクトリに纏めて格納するためのデータ記録処理について述べ、次にディレクトリ管理ファイルの更新処理について述べる。最後に、プレイリスト再生時に再生対象となるファイルが消失していたり未対応の形式であったりした場合のファイル対応処理について述べる。
【００７７】
・データ記録処理
同一ディレクトリ格納条件を満たす動画または音声データを一つのグループに纏め、同じグループに属するデータを一つのディレクトリに格納する。本第１の実施形態では、動画データのみを同一ディレクトリ格納条件の対象にする。
【００７８】
図７に、本第１の実施形態における同一ディレクトリ格納条件を示す。図７に示したように、本第１の実施形態では以下の２つの条件を同時に満たす動画データを、直前に記録したデータと同じ動画ディレクトリに格納する。
(1) 直前に記録したデータと同じ種類のコンティニュアス・データである。すなわち動画データ同士もしくは音声データ同士である。静止画データはグループ化の対象にはならない。
(2) 直前に記録した動画データの記録終了時刻から、対象となるデータの記録開始時刻までの時間が、T1以下である。
【００７９】
例えば本第１の実施形態では、T1 = 60分であるとする。
【００８０】
本第１の実施形態では動画データがMPEG2である場合、PS形式かTS形式かは区別しないが、再生互換性を高めるために、同じ形式のデータのみをグループ化しても構わないことは言うまでもない。また、同一ディレクトリ格納条件は適宜設定可能であり、上記に限るものではない。
【００８１】
次に、上記の同一ディレクトリ格納条件に基づくグループ化処理の流れを図８を参照して説明する。
【００８２】
まず、記録するデータ（以下、「現在のデータ」と呼ぶ。）の種類を調べる（ステップＳ８０１）。動画データでなければステップＳ８０８へ進み、動画データの場合はステップＳ８０２へ進む。
【００８３】
ステップＳ８０２では、直前に記録されたデータ（以下、「直前のデータ」と呼ぶ。）の種類を取得し、次のステップＳ８０３で直前のデータの記録終了時刻t1'を取得する。ステップＳ８０４では、現在のデータの記録開始時刻t1を取得する。そして、ステップＳ８０５において、同一ディレクトリ格納条件を満たすかどうか判断する。即ち、 直前のデータと現在のデータの種類が同じで、且つ、t1 - t1' ≦ T1 を満たすかを調べ、双方の条件を満たした場合、ステップＳ８０６へ進む。そうでない場合はステップＳ８０７へ進む。
【００８４】
ステップＳ８０６において、直前のデータと同じ動画ディレクトリに現在のデータを記録して処理を終了する。一方、ステップＳ８０７では新しい動画ディレクトリを作成し、作成したディレクトリに現在のデータを記録して処理を終了する。
【００８５】
また、静止画データ等、動画データでは無い場合はステップＳ８０８においてDCF準拠の方式でデータを記録し、音声データの場合は音声ディレクトリにデータを記録して処理を終了する。
【００８６】
動画データの記録時に、動画ディレクトリにサムネイル画像を記録しても良い。この場合、静止画データがDCF準拠であるので、動画データのサムネイル画像もDCFサムネイルファイルの形式を採ることが望ましい。サムネイルファイルは、データ記録後に作成してもよいが、1フレーム目を記録した直後にサムネイルデータを作成して記録しても良いことは言うまでもない。
【００８７】
・ディレクトリ管理情報更新処理
本第１の実施形態におけるディレクトリ管理情報の更新処理は、ファイルの追加と削除、およびファイルをグループ管理ファイルやプレイリストに登録する際に行う。
【００８８】
まず、ファイル追加時には、対応するディレクトリの管理情報に新たなエントリを作成し、そのファイルを登録する。登録する際には、idアトリビュートで識別情報、srcアトリビュートでファイル名、さらに、登録するファイルが動画もしくは音声ファイルの場合はdurアトリビュートで再生時間を付与する。
【００８９】
ファイル削除時には、SYSTEM_linkCountアトリビュート値、USER_linkCountアトリビュート値、PLF_linkCountアトリビュート値で保持されている参照数によって処理が異なる。PLF以外のファイル削除時の管理情報更新処理の流れを図９に示す。
【００９０】
まずステップＳ９０１において削除するファイルのエントリE1を取得する。取得した エントリE1のlinkCountアトリビュート値が０、もしくは、linkCountアトリビュート自体が無い場合（ステップＳ９０２でＮＯ）、ステップＳ９０３へ進む。そうでない場合は（ステップＳ９０２でＹＥＳ）、ステップＳ９０４に進む。
【００９１】
ステップＳ９０３では、エントリE1を削除してステップＳ９０５へ進む。一方、ステップＳ９０４ではエントリE1にdeletedアトリビュート(削除属性)を付与する。deletedアトリビュート値は、「true」とする。ステップＳ９０３及びＳ９０４の処理後、ステップＳ９０５へ進む。
【００９２】
ステップＳ９０５では対象となるファイルを削除して処理を終了する。
【００９３】
ファイルをプレイリストに登録する場合には、次に述べる処理を行う。まず、登録対象になったファイルのエントリE2を取得する。 次に、エントリE2の、対応するリンクカウントアトリビュート値を１増やす。例えば、ファイルがプレイリストに登録された場合には、PLF_linkCountアトリビュート、システムが自動生成するグループ管理ファイルに登録された場合にはSYSTEM_linkCountアトリビュート、ユーザが作成したグループに対応するグループ管理ファイルに登録された場合にはUSER_linkCountアトリビュートの値を１増やす。リンクカウントアトリビュート自体が無い場合は、対応するリンクカウントアトリビュートを付与する。この場合のアトリビュート値は「１」である。
【００９４】
プレイリストやグループ管理ファイルからメディア・オブジェクトを登録解除する場合、登録解除するファイルに対応するエントリEkについて、図１０に示す処理を適用する。
【００９５】
まずステップＳ１００１で、登録解除するエントリEkを取得し、対応するリンクカウントアトリビュート値を１減らす。
【００９６】
その後、 PLF_linkCountアトリビュート値およびUSER_linkCountアトリビュート値が０に等しく、なおかつエントリEkのdeletedアトリビュート値が「true」である場合は（ステップＳ１００２でＹＥＳ）、ステップＳ１００３でエントリEkを削除して、処理を終了する。そうでない場合は（ステップＳ１００２でＮＯ）、そのまま処理を終了する。
【００９７】
PLFやグループ管理ファイルの削除時には、図９に示したファイルの削除処理に加えて、削除対象となるプレイリストまたはグループ管理ファイルに登録されている全てのファイルのエントリEkに対して、図１０に示す処理を行う。
【００９８】
このような処理を行うことで、全ての参照関係が解消されたエントリで、なおかつ実体（ファイル）が存在しないものの識別名だけを再利用することが可能になる。識別名の再利用によって、例えばファイル名の命名規則が接頭辞と数値の組み合わせになっている場合、ファイルの削除を繰り返すことで使用可能な番号が不足するのを防ぐことができる。また、ファイルの間接参照を用いたシステムでは、ファイル名は同じだが実体は別のファイルに入れ替えられたような状況も考えられる。本発明による管理方法を適用すれば、そのような状況に対し適切に対処することができる。
【００９９】
このような管理情報更新処理を行うことで、プレイリストやグループ管理ファイル、記録媒体管理ファイルから各ファイルへの参照数をファイル毎に管理することができる。また、プレイリストや管理ファイルから参照されているにも関わらず削除したファイルに削除属性を付与することで、未だ参照状態にあるファイルの識別名(id)の再利用を抑止し、ファイルが削除されたという状態を全てのプレイリストや管理ファイルから把握できるようになるという利点がある。
【０１００】
・ファイル対応処理
本第１の実施形態では、プレイリストの再生時、もしくはプレイリスト再生前のスケジューリングの際に、プレイリストから参照しているファイルのエントリに削除属性があることが分かった場合、もしくは、再生対象となるデータが未サポートのデータ形式である場合、そのファイルの再生時間長と同じ時間、画面の表示を抑止する。ただし、この処理を適用するのは、対象となるファイルが静止画もしくは動画データである場合に限る。対象となるファイルが音声データである場合、そのデータを再生しない。
【０１０１】
ファイル対応処理の流れを図１１に示す。
【０１０２】
まずステップＳ１１０１において再生対象ファイルのエントリEiを取得する。取得したエントリEiのdeletedアトリビュート値が「true」である場合、ステップＳ１１０５へ進み、そうでない場合は（ステップＳ１１０２でＮＯ）、ステップＳ１１０３へ進む。
【０１０３】
ステップＳ１１０３では、エントリEiのsrcアトリビュート値で示されるファイルをオープンし、形式を調べる。再生装置でサポートしていない形式のデータである場合、ステップＳ１１０５へ進む。そうでない場合は、ステップＳ１１０４へ進む。ステップＳ１１０４では再生対象ファイルを通常再生することを決定し、処理を終了する。
【０１０４】
一方、ステップＳ１１０５では再生対象ファイルの種類が、「movie」、「image」、「playlist」である場合、代替再生を行うことにして処理を終了する。「audio」の場合は再生しない。
【０１０５】
本第１の実施形態のファイル対応処理によって、再生装置が再生対象ファイルのデータ形式に未対応、もしくは再生対象ファイルが存在しない場合に、そのファイルの再生時間と等しい無再生時間を設けることで、他のファイルの再生タイミングに悪影響を及ぼさないようにすることができる。
【０１０６】
また、無再生時間を設ける代わりに、「未対応のファイル形式」「ファイルが存在しない」などを知らせる警告画面を表示するようにしてもよい。
【０１０７】
上記の通り本第１の実施形態によれば、ファイル自体はディレクトリ単位で管理を行い、グループ化や再生制御スクリプト等からファイル名を直接参照するのではなく、ディレクトリ管理ファイルを参照する仕組みを導入することで、ファイルの管理コストを局所化し、グループ化や再生制御スクリプト等の機能を持つ複雑なシステム全体の管理コストを大幅に低減することが可能になる。
【０１０８】
＜第２の実施形態＞
上記第１の実施形態では、管理情報とプレイリストの連携について述べた。本第２の実施形態では、プレイリストの編集の際の処理について述べる。
【０１０９】
編集対象のプレイリストから参照しているファイルが存在しない、もしくは未対応のデータ形式である場合がある。このような場合でも、ファイル対応処理と同様の方法で、全てのファイルの再生タイミングを得ることができる。本第２の実施形態における編集の前処理例を図１２に示す。
【０１１０】
編集対象プレイリストに登録されている各ファイルFjに対して、次の処理を適用する。
【０１１１】
まずステップＳ１２０１において、対象ファイルFjのエントリEjを取得する。取得したエントリEjのdeletedアトリビュート値が「true」である場合（ステップＳ１２０２でＹＥＳ）、ステップＳ１２０５へ進み、そうでない場合は（ステップＳ１２０２でＮＯ）、ステップＳ１２０３へ進む。
【０１１２】
ステップＳ１２０３では、エントリEjのsrcアトリビュート値で示されるファイルをオープンし、形式を調べる。記録再生装置でサポートしていない形式のデータである場合（ステップＳ１２０３でＮＯ）、ステップＳ１２０６へ進む。そうでない場合は（ステップＳ１２０３でＹＥＳ）、ステップＳ１２０４へ進む。
【０１１３】
ステップＳ１２０４では、再生対象ファイルを通常表示することを決定して、処理を終了する。
【０１１４】
ステップＳ１２０５では、再生対象ファイルを消失表示することを決定して、処理を終了する。
【０１１５】
また、ステップＳ１２０６では、再生対象ファイルを異常表示することを決定して、処理を終了する。
【０１１６】
図１２に示すような処理を適用することで、例えば図１３に示すような表示をして編集操作者に各ファイルの状態を示すことが可能になる。図１３は、Video #1トラックの最初の動画ファイルが消失状態の表示方法の一例である。
【０１１７】
このように、個々のファイルはディレクトリ管理ファイルで管理を行い、ディレクトリ管理ファイルに各データの再生時間長を保持することで、再生不可能なデータについても再生時間を考慮した再生制御スクリプトの再生を行うことが可能になる。
【０１１８】
なお、上記第１及び第２の実施形態においてはディレクトリ管理ファイルとプレイリストとの連携について説明したが、本発明はプレイリストに限るものではなく、メディア・データを参照する任意のファイル管理に適用可能であることは言うまでもない。
【０１１９】
【他の実施形態】
なお、本発明は、複数の機器（例えばホストコンピュータ、インターフェイス機器、ビデオカメラなど）から構成されるシステムに適用しても、一つの機器からなる装置（例えば、ビデオカムコーダなど）に適用してもよい。
【０１２０】
また、本発明の目的は、前述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（または記録媒体）を、システムあるいは装置に供給し、そのシステムあるいは装置のコンピュータ（またはＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行することによっても、達成されることは言うまでもない。この場合、記憶媒体から読み出されたプログラムコード自体が前述した実施形態の機能を実現することになり、そのプログラムコードを記憶した記憶媒体は本発明を構成することになる。また、コンピュータが読み出したプログラムコードを実行することにより、前述した実施形態の機能が実現されるだけでなく、そのプログラムコードの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。ここでプログラムコードを記憶する記憶媒体としては、例えば、フレキシブルディスク、ハードディスク、ＲＯＭ、ＲＡＭ、磁気テープ、不揮発性のメモリカード、ＣＤ−ＲＯＭ、ＣＤ−Ｒ、ＤＶＤ、光ディスク、光磁気ディスク、ＭＯなどが考えられる。また、ＬＡＮ（ローカル・エリア・ネットワーク）やＷＡＮ（ワイド・エリア・ネットワーク）などのコンピュータネットワークを、プログラムコードを供給するために用いることができる。
【０１２１】
さらに、記憶媒体から読み出されたプログラムコードが、コンピュータに挿入された機能拡張カードやコンピュータに接続された機能拡張ユニットに備わるメモリに書込まれた後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵなどが実際の処理の一部または全部を行い、その処理によって前述した実施形態の機能が実現される場合も含まれることは言うまでもない。
【０１２２】
本発明を上記記憶媒体に適用する場合、その記憶媒体には、先に説明した図８乃至図１１、または、更に図１２に示すフローチャートに対応するプログラムコードが格納されることになる。
【０１２３】
【発明の効果】
以上説明したように本発明によれば、ファイルの管理コストを局所化し、管理コストを低減すると共に、管理ファイル破損時のリスク分散を図ることが可能になる。
【図面の簡単な説明】
【図１】本発明の第１の実施形態における情報記録再生装置の構成を表すブロック図である。
【図２】本発明の第１の実施形態における記録媒体上のデータの格納方式を示す図である。
【図３】本発明の第１の実施形態における管理ファイルの基本構造を示す図である。
【図４】本発明の第１の実施形態におけるディレクトリ管理ファイルの記述例を示す図である。
【図５】本発明の第１の実施形態におけるプレイリストの記述例を示す図である。
【図６】本発明の第１の実施形態における管理ファイルとプレイリストの関係を表す図である。
【図７】本発明の第１の実施形態における動画データの同一ディレクトリ格納条件を示す図である。
【図８】本発明の第１の実施形態における動画データのグループ化処理の流れを示すフローチャートである。
【図９】本発明の第１の実施形態におけるファイル削除時のディレクトリ管理ファイル更新処理の流れを示すフローチャートである。
【図１０】本発明の第１の実施形態におけるファイル登録解除時のディレクトリ管理ファイル更新処理の流れを示すフローチャートである。
【図１１】本発明の第１の実施形態におけるファイル対応処理の流れを示すフローチャートである。
【図１２】本発明の第２の実施形態におけるPLF編集の前処理の流れを示すフローチャートである。
【図１３】本発明の第２の実施形態におけるPLF編集GUIの例を示す図である。
【図１４】本発明の第１の実施形態における記録媒体管理ファイルの一例を示す図である。
【図１５】本発明の第１の実施形態におけるグループ管理ファイルの一例を示す図である。
【符号の説明】
１  ピックアップ
２  RFアンプ
３  エンコーダ・デコーダ/信号処理回路
４  メモリコントローラ
５  ショックプルーフメモリ
６  復号化・符号化回路
７  コンバータ
８  送りモータ
９  スピンドルモータ
１０  ドライバ回路
１１  サーボ制御回路
１２  システムコントローラ
１３  電源回路
１４  ヘッド駆動装置
１５  記録ヘッド
１６  入力装置
１７  カメラ部
１８  映像音声出力端子
１９  ディスク
【図１】
0004366120.tif 000002
【図２】
0004366120.tif 000003
【図３】
0004366120.tif 000004
【図４】
0004366120.tif 000005
【図５】
0004366120.tif 000006
【図６】
0004366120.tif 000007
【図７】
0004366120.tif 000008
【図８】
0004366120.tif 000009
【図９】
0004366120.tif 000010
【図１０】
0004366120.tif 000011
【図１１】
0004366120.tif 000012
【図１２】
0004366120.tif 000013
【図１３】
0004366120.tif 000014
【図１４】
0004366120.tif 000015
【図１５】
0004366120.tif 000016