(57)【要約】【課題】ユーザに混乱を与えずに、参照ムービーをインデックスファイルで管理する。【解決手段】本発明は、例えばファイルサイズに上限があるために生成される参照ムービーを、インデックスファイルを用いて、ユーザに混乱を与えない形で管理することを目的とする。インデックスファイルにおいて、管理している各ファイルに関して、ユーザに見せる又は隠す、オリジナルか又は非破壊編集済みか等を区別する情報を管理し、それらの情報に基づき削除処理や一覧表示処理を行う。【選択図】図１
2010140633.tif 000002
【特許請求の範囲】
【請求項１】
記録媒体に記録されたＡＶデータを再生するデータ再生装置であって、
前記記録媒体には、複数のムービーと、前記複数のムービーを管理するインデックスが記録されており、
前記ムービーは、前記ＡＶデータを参照するための第１の参照情報を含み、
前記インデックスは、前記ムービー毎に前記ムービーを管理するためのエントリを含み、
前記エントリは、対応する前記ムービーを参照するための第２の参照情報と、対応する前記ムービーの存在をユーザに見せるか否かを示す属性情報を含み、
前記第２の参照情報に参照される前記ムービーをユーザに選択させる選択手段を備え、
前記属性情報の値が前記ムービーの存在をユーザに見せない値であった場合、前記ムービーを前記選択手段を通じてユーザに選択させず、
前記複数のムービーのうち、第１のムービーに対応する前記属性情報が当該第１のムービーの存在をユーザに見せない値であり、かつ、第２のムービーに対応する前記属性情報が当該第２のムービーの存在をユーザに見せる値である場合、前記第１のムービーに含まれる前記第１の参照情報により参照される前記ＡＶデータを、前記第２のムービーに含まれる前記第１の参照情報を通じて再生可能にすることを特徴とするデータ再生装置。
【請求項２】
請求項１に記載のデータ再生装置に供給可能であるように、前記複数のムービーと、前記インデックスとが記録されていることを特徴とする記録媒体。
【請求項３】
請求項１に記載のデータ再生装置に供給可能であるように、前記ＡＶデータと前記複数のムービーと前記インデックスとを、前記記録媒体に記録することを特徴とする記録装置。
【請求項４】
記録媒体に記録されたＡＶデータを再生するデータ再生方法であって、
前記記録媒体には、複数のムービーと、前記複数のムービーを管理するインデックスがさらに記録されており、
前記ムービーは、前記ＡＶデータを参照するための第１の参照情報を含み、
前記インデックスは、前記ムービー毎に前記ムービーを管理するためのエントリを含み、
前記エントリは、前記ムービーを参照するための第２の参照情報と、前記ムービーの存在をユーザに見せるか否かを示す属性情報を含み、
前記第２の参照情報に参照される前記ムービーをユーザに選択させる選択ステップを備え、
前記属性情報の値が前記ムービーの存在をユーザに見せない値であった場合、前記ムービーを前記選択ステップにおいてユーザに選択させず、
前記複数のムービーのうち、第１のムービーに対応する前記属性情報が当該第１のムービーの存在をユーザに見せない値であり、かつ、第２のムービーに対応する前記属性情報が当該第２のムービーの存在をユーザに見せる値である場合、前記第１のムービーに含まれる前記第１の参照情報により参照される前記ＡＶデータを、前記第２のムービーに含まれる前記第１の参照情報を通じて再生可能にすることを特徴とするデータ再生方法。
【請求項５】
請求項４に記載のデータ再生方法を、コンピュータに実行させるプログラム。
【請求項６】
請求項５に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、ハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して、映像データ、音声データを記録・削除するデータ記録方法、データ削除方法、データ表示方法、記録装置、記録媒体およびプログラムに関するものである。
【背景技術】
【０００２】
ディスクメディアを用いたビデオのディジタル記録再生装置（以下、ビデオディスクレコーダと呼ぶ）が普及しつつある。その記録フォーマットには、ＰＣ（パーソナル・コンピュータ）との親和性を高めるため、ＰＣで広く使われている、例えばＱｕｉｃｋＴｉｍｅ（登録商標）ファイルフォーマットやＡＶＩ（ＡｕｄｉｏＶｉｄｅｏ Ｉｎｔｅｒｌｅ
ａｖｅ）ファイルフォーマットを用いることがよく行われる。
【０００３】
このようなＰＣ用ファイルフォーマットを用いた場合のディスク中でのコンテンツの管理方法については、特許文献１に開示されている。以下、図３３を用いてその概要を説明する。ディスク２１０５中のファイル２１０１〜２１０３は、録画した各シーンあるいはショットに対応しそれぞれ１個のＱｕｉｃｋＴｉｍｅファイル（以下、ＱｕｉｃｋＴｉｍｅムービーファイルと呼ぶ）である。
【０００４】
インデックスファイル２１００は、ディスク２１０５中のデータの目次的な情報を格納するファイルである。各ＱｕｉｃｋＴｉｍｅムービーファイル毎にエントリが存在する。各エントリには、対応するシーンの代表画面の縮小画像（サムネイル画像）データ２１１１〜２１１３と、そのシーンが含まれるファイルのファイル名とが格納される。
【０００５】
ユーザにインデックス画面を提示する際は、各エントリの縮小画像データ２１１１〜２１１３をデコードした縮小画像２１２１〜２１２３をコンテンツ選択画面２１０７に表示する。ユーザはコンテンツ選択画面２１０７画面に表示されている複数の縮小画像の中から再生や編集をしたいファイルを選択する。例えば、ユーザが縮小画像２１２３を選択し、再生を指示したら、縮小画像２１２３に対応するコンテンツの含まれるファイルのファイル名であるファイル２１０３を取得し、ファイル２１０３の再生を開始する。
【０００６】
インデックスファイル２１００には、ディスク２１０５中のすべてのコンテンツに関して、そのコンテンツを格納したファイルへのポインタと縮小画像データとが含まれる。このため、インデックスファイル２１００をディスク２１０５から読み出すだけで、コンテンツ選択画面２１０７の表示が可能であり、Ｉｎｄｅｘ画面（コンテンツ選択画面）表示に要する時間が少なくて済むという利点がある。コンテンツ選択画面２１０７は頻繁に表示するものであるため、その表示時間の削減は全体的な体感レスポンス向上に大きく寄与する。
【先行技術文献】
【特許文献】
【０００７】
【特許文献１】特開２００１−８４７０５号公報（公開日：２００１年３月３０日）
【発明の概要】
【発明が解決しようとする課題】
【０００８】
しかしながら、上述の従来の構成によると、以下に説明するように参照ムービーを管理する際にユーザに混乱を与えてしまう虞れがある。
【０００９】
ここで、ＰＣ用のファイルフォーマットを用いる際に問題となるのは、大容量ビデオデータの扱いである。前述のＱｕｉｃｋＴｉｍｅファイルフォーマットやＡＶＩファイルフォーマットでは３２ｂｉｔの情報でアドレスを管理しているため、ファイルサイズの上限は２の３２乗、すなわち約４ＧＢ（バイト）となる。ビットレート１０Ｍｂｐｓのビデオデータを記録した場合、記録時間は６０分弱となり、テレビ番組等の録画には不十分である。
【００１０】
このような問題を解消するため、図３４に示すような参照ムービーと呼ばれる方法が用いられている。以下、参照ムービーについて説明する。まず、作成は次の（１）から（４）の手順で行う。（１）録画開始した時点でファイル２２０１にデータを記録していく。（２）ファイル２２０１がファイルサイズの上限に近づいたら、ファイル２２０１への記録をやめ、続きのファイル２２０２に記録していく。（３）ファイル２２０２のファイルサイズが上限に近づいたら同様にファイル２２０３に記録を行う。（４）録画が終了した時点で、ファイル２２０４に管理情報を作成する。
【００１１】
再生時はファイル２２０４を指定し、そこに記録されている管理情報を基に、順にファイル２２０１〜２２０３を再生することが可能である。また、ファイル２２０４が削除された場合でも再生が可能なように、ファイル２２０１〜２２０３にも前記管理情報が付加されている。ここでは、ファイル２２０１〜２２０３を自動分割ムービーファイル、ファイル２２０４を統括ムービーファイルと呼ぶことにする。
【００１２】
このような参照ムービー（自動分割ムービー、統括ムービー）を、前述のインデックスファイルを用いた方法で管理すると次のような問題が生じる。図３５を用いてそれを説明する。前記のファイル２２０１〜２２０４をそれぞれの代表画面の縮小画像データとともにインデックスファイル２１００に登録すると仮定する。このとき、コンテンツ選択画面２１０７には、ファイル２２０１〜２２０４に対応する代表画面２２２１〜２２２４が表示されることになり、ユーザは違和感を抱くことになる。なぜなら、ユーザが撮影したシーンは１個であるのにもかかわらず、４個の代表画面が表示されるからである。
【００１３】
また、参照ムービーを削除する際にも、１個のシーンについて４個の代表画面が表示されているため、削除をどのようにするか明らかでない。
【００１４】
本発明は、上記課題を鑑みてなされたものであり、ユーザに混乱を与えない形で参照ムービーをインデックスファイルで管理することが可能なデータ記録方法、データ削除方法、データ表示方法、記録装置、記録媒体およびプログラムを提供することを目的とする。
【課題を解決するための手段】
【００１５】
本発明に係るデータ削除方法は、前記目的を達成すべく、少なくとも複数の分割データと前記分割データを参照する統括データとを含む複数のデータを一括して管理するテーブルを持つ記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、前記削除の際に、登録されているエントリに対応するデータが初期記録データか否かを判断するステップを有することを特徴とする。
【００１６】
また、本発明に係るデータ削除方法は、前記目的を達成すべく、前記構成において、前記登録されているエントリに対応するデータが初期記録データか否かを判断するステップが、前記エントリの管理するデータが分割記録されたかどうかの情報および他のエントリが管理するデータとの関連情報および作成時間に基づくことを特徴とする。
【００１７】
本発明に係るデータ記録方法は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録するデータ記録方法であって、前記エ
ントリにそのエントリが管理するデータが初期記録データか否かに関する情報を記録することを特徴とする。
【００１８】
本発明に係るデータ記録方法は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録するデータ記録方法であって、前記エントリにそのエントリが管理するデータの存在をユーザに見せるかどうかを管理する情報を記録することを特徴とする。
【００１９】
本発明に係るデータ記録方法は、前記目的を達成すべく、前記構成において、前記複数のデータは、少なくとも複数の分割データと前記分割データを参照する統括データとを含むことを特徴とする。
【００２０】
本発明に係るデータ記録方法は、前記目的を達成すべく、前記構成において、前記エントリに他のエントリが管理するデータとの関連情報を記録することを特徴とする。
【００２１】
本発明に係るデータ記録方法は、前記目的を達成すべく、前記構成において、前記テーブルをファイルに格納することを特徴とする。
【００２２】
本発明に係るデータ削除方法は、前記目的を達成すべく、少なくとも複数の分割データと前記分割データを参照する統括データとを含む複数のデータをそれぞれエントリとして一括管理するテーブルを持つ記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、前記記録媒体には、前記データに対応するエントリに初期記録データか否かを管理する情報が記録してあり、前記削除の際に、削除対象のデータが前記初期記録データか否かに関する情報および他のエントリが管理するデータとの関連情報を基に削除可能かどうかを判断するステップを有することを特徴とする。
【００２３】
本発明に係るデータ削除方法は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを持つ記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、前記記録媒体には、前記データを管理するエントリにそのデータの存在をユーザに見せるかどうかを管理する情報および他のエントリが管理するデータとの関連情報が記録してあり、前記削除の際に、前記関連情報に基づき前記データの存在をユーザに見せるかどうかを管理する情報を変更するステップを有することを特徴とする。
【００２４】
本発明に係るデータ表示方法は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを持つ記録媒体から、前記テーブルを読み出して表示するデータ表示方法であって、前記記録媒体には、前記データを管理するエントリにそのデータの存在をユーザに見せるかどうかを管理する情報が記録してあり、前記データの存在をユーザに見せるかどうかを管理する情報に基づいて表示を制御することを特徴とする。
【００２５】
本発明に係る記録装置は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録する記録装置であって、前記エントリにそのエントリが管理するデータが初期記録データか否かに関する情報を記録する手段を備えることを特徴とする。
【００２６】
本発明に係る記録装置は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録する記録装置であって、前記エントリにそのエントリが管理するデータの存在をユーザに見せるかどうかを管理する情報を記録する手段を備えることを特徴とする。
【００２７】
本発明に係る記録媒体は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録した記録媒体であって、前記エントリにそのエントリが管理するデータが初期記録データか否かに関する情報を記録してあることを特徴とする。
【００２８】
本発明に係る記録媒体は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録した記録媒体であって、前記エントリにそのエントリが管理するデータの存在をユーザに見せるかどうかを管理する情報を記録してあることを特徴とする。
【００２９】
本発明に係るプログラムは、前記目的を達成すべく、上述のいずれかのデータ削除方法、または上述のいずれかのデータ記録方法を、コンピュータに実行させるプログラムである。
【００３０】
また、本発明に係る記録媒体は、上述のプログラムを記録したコンピュータ読み取り可能な記録媒体である。
【００３１】
本発明によれば、ディスク上の各ファイルが自動分割ムービーファイルかどうかを区別する情報とオリジナルかどうかを区別する情報に基づくことで、自動分割ムービーファイルがある場合でもユーザに違和感を与えず削除を実行することができる。
【００３２】
また、本発明によれば、オリジナルかどうかを管理する情報をディスク上に格納することで、自動分割ムービーファイルがある場合でもユーザに違和感を与えず確実に削除を行うことができる。
【００３３】
さらに、本発明によれば、エントリに対応するＡＶファイルに関して、ユーザに見せるか見せないかを区別するための情報をディスク上に格納することで、ファイルの参照を行っていた場合でもユーザが任意のコンテンツを見かけ上削除することが可能となる。
【００３４】
本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。
【図面の簡単な説明】
【００３５】
【図１】本発明の実施形態におけるディジタル記録再生装置の概略構成を示すブロック図である。
【図２（ａ）】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける管理情報とＡＶストリームとの関係の一例を示す説明図である。
【図２（ｂ）】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける管理情報とＡＶストリームとの関係の他の一例を示す説明図である。
【図２（ｃ）】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける管理情報とＡＶストリームとの関係のさらに他の一例を示す説明図である。
【図３】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ ａｔｏｍの概要を示す説明図である。
【図４】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ａｔｏｍの概要を示す説明図である。
【図５】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を示す説明図である。
【図６】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける Ｍｅｄｉａ ａｔｏｍの構成を示す説明図である。
【図７】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎａｔｏｍの構成を示す説明図である。
【図８】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構成を示す説明図である。
【図９】Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍによるデータ管理の例を示す説明図である。
【図１０】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＥｄｉｔ ａｔｏｍの構成を示す説明図である。
【図１１（ａ）】Ｅｄｉｔ ｌｉｓｔ ａｔｏｍの内容を示す図である。
【図１１（ｂ）】サンプルの一例の構成を示す図である。
【図１１（ｃ）】サンプルの再生の順を示す図である。
【図１２】ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＵｓｅｒ ｄａｔａ ａｔｏｍの構成を示す説明図である。
【図１３】ＡＶストリームの構成を示す説明図である。
【図１４】Ｖｉｄｅｏ Ｕｎｉｔ（ＶＵ）の構造を示す説明図である。
【図１５】ＱｕｉｃｋＴｉｍｅによるＡＶストリーム管理形態を示す説明図である。
【図１６】リファレンス・デバイス・モデルを示す説明図である。
【図１７】ＡＶ Ｉｎｄｅｘファイルの構成を示す説明図である。
【図１８】属性情報の構成を示す説明図である。
【図１９】本発明の第１の実施形態におけるｐｅ−ｆｌａｇｓの構成を示す説明図である。
【図２０】記録動作を示すフローチャートである。
【図２１】本発明の第１の実施形態における、記録後の属性情報を示す説明図である。
【図２２】本発明の第１の実施形態における、非破壊編集後の属性情報を示す説明図である。
【図２３】本発明の第１の実施形態における、削除可能性の判定動作を示すフローチャートである。
【図２４】本発明の第１の実施形態における、オリジナルか非破壊編集結果かを判定する動作を示すフローチャートである。
【図２５】本発明の第２の実施形態におけるｐｅ−ｆｌａｇｓの構成を示す説明図である。
【図２６】本発明の第２の実施形態における、記録後の属性情報を示す説明図である。
【図２７】本発明の第２の実施形態における、非破壊編集後の属性情報を示す説明図である。
【図２８】本発明の第３の実施形態におけるｐｅ−ｆｌａｇｓの構成を示す説明図である。
【図２９】本発明の第３の実施形態における、記録後の属性情報を示す説明図である。
【図３０】本発明の第３の実施形態における、非破壊編集後の属性情報を示す説明図である。
【図３１】本発明の第３の実施形態における、アフレコ後の属性情報を示す説明図である。
【図３２】本発明の第３の実施形態における、削除動作を示すフローチャートである。
【図３３】従来技術におけるインデックスファイルを示す説明図である。
【図３４】従来技術における参照ムービーの概念を示す説明図である。
【図３５】従来技術における、参照ムービーを管理するインデックスファイルを示す説明図である。
【図３６】従来技術における、参照ムービーを管理するインデックスファイルの改良例を示す説明図である。
【発明を実施するための形態】
【００３６】
以下、本発明の実施形態について、図面を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行っていく。
【００３７】
＜システム構成＞
図１は本発明において共通に用いる、ディスクメディアを用いたビデオのディジタル記録再生装置（ビデオディスクレコーダ）の構成図である。この装置は、図１に示すように、バス１００、ホストＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ユーザインタフェース１０４、システムクロック１０５、光ディスク１０６、ピックアップ１０７、ＥＣＣ（ＥｒｒｏｒＣｏｒｒｅｃｔｉｎｇ Ｃｏｄｉｎｇ）デコーダ１０８、ＥＣＣエンコーダ１
０９、再生用バッファ１１０、記録／アフレコ用バッファ１１１、デマルチプレクサ１１２、マルチプレクサ１１３、多重化用バッファ１１４、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、および図示しないカメラ、マイク、スピーカ、ディスプレイ等で構成される。なお、アフレコとはアフター・レコーディングの略であり、初期記録したビデオデータに対して後からオーディオデータを追加記録する機能を指す。
【００３８】
ホストＣＰＵ１０１は、バス１００を通じてデマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、また図示していないが、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８の制御を行う。
【００３９】
再生時には、光ディスク１０６からピックアップ１０７を通じて読み出されたデータは、ＥＣＣデコーダ１０８によって誤り訂正され、再生用バッファ１１０に一旦蓄えられる。ホストＣＰＵ１０１は、再生中のデータに関する管理情報に基づき、オーディオデコーダ１１５、ビデオデコーダ１１６からのデータ送信要求に従い、再生用バッファ１１０中のデータをその種別によって適当なデコーダに振り分けるようデマルチプレクサ１１２に指示を与える。
【００４０】
一方、記録時には、オーディオエンコーダ１１７とビデオエンコーダ１１８によって圧縮符号化されたデータは、多重化用バッファ１１４に一旦送られ、マルチプレクサ１１３によってＡＶ多重化され、記録／アフレコ用バッファ１１１に送られる。記録／アフレコ用バッファ１１１中のデータは、ＥＣＣエンコーダ１０９によって誤り訂正符号を付加され、ピックアップ１０７を通じて光ディスク１０６に記録される。
【００４１】
オーディオデータの符号化方式にはＭＰＥＧ−１ Ｌａｙｅｒ−ＩＩを、ビデオデータ
の符号化方式にはＭＰＥＧ−２をそれぞれ用いる。
【００４２】
光ディスク１０６は、外周から内周に向かって螺旋状に記録再生が行われる脱着可能な光ディスクとする。２０４８ｂｙｔｅを１セクタとし、誤り訂正のため１６セクタでＥＣＣブロックを構成する。ＥＣＣブロック中のデータを書き換える場合、そのデータが含まれるＥＣＣブロック全体を読み込み、誤り訂正を行って、対象のデータを書き換え、再び誤り訂正符号を付加し、ＥＣＣブロックを構成して、記録媒体に記録する必要がある。また、光ディスク１０６は、記録効率を上げるためＺＣＡＶ（ゾーン角速度一定）を採用しており、記録領域は回転数の異なる複数のゾーンで構成される。
【００４３】
＜ファイルシステム＞
光ディスク１０６上の各種情報を管理するためにファイルシステムを用いる。ファイルシステムには、ＰＣ（パーソナルコンピュータ）との相互運用を考慮してＵＤＦ（ＵｎｉｖｅｒｓａｌＤｉｓｋ Ｆｏｒｍａｔ）を使用する。ファイルシステム上では、各種管理
情報やＡＶストリームはファイルとして扱われる。
【００４４】
上記構成のビデオディスクレコーダにおいては、ホストＣＰＵ１０１が、ファイルシステムを用いて、光ディスク１０６への記録、または光ディスク１０６からの再生を行うようになっている。すなわち、ホストＣＰＵ１０１が、ファイルシステムにおけるファイル管理情報を用いてデータの記録、再生、削除などを行うファイル管理部として機能する。また、ファイルの属性情報などのファイルについての情報も、ホストＣＰＵ１０１が管理して、光ディスク１０６に記録を行い、または光ディスク１０６から読み取りを行うようになっている。
【００４５】
ユーザエリアは、２０４８ｂｙｔｅの論理ブロック（セクタと一対一対応）で管理される。各ファイルは、整数個のエクステント（連続した論理ブロック）で構成され、エクステント単位で分散して記録しても良い。空き領域は、ＳｐａｃｅＢｉｔｍａｐを用いて論理ブロック単位で管理される。
【００４６】
＜ファイルフォーマット＞
ＡＶストリーム管理のためのフォーマットとして、ＱｕｉｃｋＴｉｍｅファイルフォーマットを用いる。ＱｕｉｃｋＴｉｍｅファイルフォーマットとは、Ａｐｐｌｅ社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。
【００４７】
ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータ、ＡＶストリームとも呼ぶ）と管理情報とで構成される。両者を合わせてここでは、ＱｕｉｃｋＴｉｍｅムービー（略してムービー）と呼ぶ。両者は同じファイル中に存在しても、別々のファイルに存在しても良い。
【００４８】
同じファイル中に存在する場合は、図２（ａ）に示すような構成をとる。各種情報はａｔｏｍという共通の構造に格納される。管理情報はＭｏｖｉｅａｔｏｍという構造に格納され、メディアデータはＭｏｖｉｅ ｄａｔａ ａｔｏｍという構造に格納される。尚、Ｍｏｖｉｅ ａｔｏｍ中の管理情報には、メディアデータ中の任意の時間に対応するメディ
アデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。すなわち、Ｍｏｖｉｅａｔｏｍ中の管理情報には、例えば複数のデータをエントリとして一括管理するためのテーブルが含まれている。
【００４９】
一方、管理情報とメディアデータを別々のファイルに格納した場合は、図２（ｂ）に示すような構成をとる。管理情報はＭｏｖｉｅ ａｔｏｍという構造に格納されるが、メデ
ィアデータはａｔｏｍには格納される必要はない。このとき、Ｍｏｖｉｅ ａｔｏｍはメ
ディアデータを格納したファイルを「外部参照」している、という。
【００５０】
外部参照は、図２（ｃ）に示すように、複数のＡＶストリームファイルに対して行うことが可能であり、この仕組みにより、ＡＶストリーム自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」「非破壊編集」が可能になる。
【００５１】
それでは、図３乃至図１２を用いて、ＱｕｉｃｋＴｉｍｅの管理情報のフォーマットについて説明する。まず、共通の情報格納フォーマットであるａｔｏｍについて説明する。ａｔｏｍの先頭には、そのａｔｏｍのサイズであるＡｔｏｍｓｉｚｅ、そのａｔｏｍの種
別情報であるＴｙｐｅが必ず存在する。Ｔｙｐｅは４文字で区別され、例えばＭｏｖｉｅ
ａｔｏｍでは’ｍｏｏｖ’、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍでは’ｍｄａｔ’となって
いる。
【００５２】
各ａｔｏｍは別のａｔｏｍを含むことができる。すなわち、ａｔｏｍ間には階層構造がある。Ｍｏｖｉｅ ａｔｏｍの構成を図３に示す。Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍは
、そのＭｏｖｉｅ ａｔｏｍが管理するムービーの全体的な属性を管理する。Ｔｒａｃｋ ａｔｏｍは、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。Ｕｓｅｒ ｄａｔａ ａｔｏｍは、独自に定義可能なａｔｏｍである。
【００５３】
Ｔｒａｃｋ ａｔｏｍの構成を図４に示す。Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、そ
のトラックの全体的な属性を管理する。Ｅｄｉｔ ａｔｏｍは、メディアデータのどの区
間を、ムービーのどのタイミングで再生するかを管理する。Ｔｒａｃｋ ｒｅｆｅｒｅｎ
ｃｅ ａｔｏｍは、別のトラックとの関係を管理する。Ｍｅｄｉａ ａｔｏｍは、実際のビデオやオーディオといったデータを管理する。
【００５４】
Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を図５に示す。ここでは、後での説明に必要なもののみについて説明する。Ｆｌａｇｓは属性を示すフラグの集合である。代表的なものとして、Ｔｒａｃｋｅｎａｂｌｅｄフラグがあり、このフラグが１であれば、そのトラックは再生され、０であれば再生されない。Ｌａｙｅｒはそのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、Ｌａｙｅｒの値が小さいトラックほど画像が前面に表示される。Ｅｄｉｔａｔｏｍについては後述する。
【００５５】
Ｍｅｄｉａ ａｔｏｍの構成を図６に示す。Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍは、そ
のＭｅｄｉａ ａｔｏｍの管理するメディアデータに関する全体的な属性等を管理する。
Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、メディアデータをどのデコーダでデコードするかを示す情報を格納する。Ｍｅｄｉａｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、ビ
デオやオーディオ等メディア固有の属性情報を管理する。
【００５６】
Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍの構成を図７に示す。Ｍｅｄｉａ ｉｎ
ｆｏｒｍａｔｉｏｎｈｅａｄｅｒ ａｔｏｍは、ビデオやオーディオ等メディア固有の属
性情報を管理する。Ｈａｎｄｌｅｒｒｅｆｅｒｅｎｃｅ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍの項で説明した通りである。Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎａｔｏｍは、そのＱｕ
ｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名前を管理するａｔｏｍであるＤａｔａ ｒｅｆｅｒｅｎｃｅ ａｔｏｍを含む。Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、データのサイズや再生時間等を管理している。
【００５７】
次に、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍについて図８に基づいて説明する。ここで、まずＱｕｉｃｋＴｉｍｅにおけるデータの管理方法について、図９を用いて説明する。ＱｕｉｃｋＴｉｍｅでは、データの最小単位（例えばビデオフレーム）をサンプルと呼ぶ。個々のトラック毎に、サンプルには再生時間順に１から番号（サンプル番号）がついている。
【００５８】
また、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。また、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンクと呼ぶ。チャンクにも再生時間順に、１から番号がついている。
【００５９】
さらに、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき
、任意の時間に対応するサンプルの位置を求めることが可能となっている。
【００６０】
Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構成を図８に示す。Ｓａｍｐｌｅｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍは、個々のチャンクのデータフォーマット（Ｄａｔａ ｆｏｒｍａｔ）やサンプルが格納されているファイルのチャンクのＩｎｄｅｘ等を管理する。Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルの再生時間を管理する。
【００６１】
Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルのうち、デコード開始可能なサンプルを管理する。Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋａｔｏｍは、個々のチャンクに含まれるサンプル数を管理する。Ｓａｍｐｌｅ ｓｉｚｅａｔｏｍは、個々のサンプルのサイズ
を管理する。Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍは、個々のチャンクのファイル先頭からのアドレスを管理する。
【００６２】
ここで、Ｅｄｉｔ ａｔｏｍについて説明する。Ｅｄｉｔ ａｔｏｍは、図１０に示すように、１個のＥｄｉｔ ｌｉｓｔ ａｔｏｍを含む。Ｅｄｉｔ ｌｉｓｔ ａｔｏｍはＮｕｍｂｅｒｏｆ ｅｎｔｒｉｅｓで指定される個数分の、Ｔｒａｃｋ ｄｕｒａｔｉｏｎ、Ｍｅｄｉａ ｔｉｍｅ、Ｍｅｄｉａ ｒａｔｅの値の組（エントリ）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。
【００６３】
Ｔｒａｃｋ ｄｕｒａｔｉｏｎはそのエントリが管理する区間のトラック上での再生時
間、Ｍｅｄｉａｔｉｍｅはそのエントリが管理する区間の先頭に対応するメディアデータ上での位置、Ｍｅｄｉａ ｒａｔｅはそのエントリが管理する区間の再生スピードを表す
。尚、Ｍｅｄｉａ ｔｉｍｅが−１の場合は、そのエントリのＴｒａｃｋｄｕｒａｔｉｏ
ｎ分、そのトラックでのサンプルの再生を停止する。この区間のことをｅｍｐｔｙ ｅｄ
ｉｔと呼ぶ。
【００６４】
このように、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおいては、管理情報を格納するＭｏｖｉｅ ａｔｏｍに含まれるＴｒａｃｋ ａｔｏｍのうちの、Ｅｄｉｔ ａｔｏｍに
、複数のデータをエントリとして一括管理するためのＥｄｉｔ ｌｉｓｔａｔｏｍが含ま
れている。
【００６５】
図１１にＥｄｉｔ ｌｉｓｔの使用例を示す。図１１（ａ）（ｂ）（ｃ）は、Ｅｄｉｔ ａｔｏｍによる再生範囲指定の例を示す説明図である。ここでは、Ｅｄｉｔ ｌｉｓｔａ
ｔｏｍの内容が図１１（ａ）に示す内容であり、さらにサンプルの構成が図１１（ｂ）であったとする。尚、ここではｉ番目のエントリのＴｒａｃｋｄｕｒａｔｉｏｎをＤ（ｉ）、Ｍｅｄｉａ ｔｉｍｅをＴ（ｉ）、ＭｅｄｉａｒａｔｅをＲ（ｉ）とする。このとき、
実際のサンプルの再生は、図１１（ｃ）に示す順に行われる。このことについて簡単に説明する。
【００６６】
まず、エントリ＃１はＴｒａｃｋ ｄｕｒａｔｉｏｎが１３０００、Ｍｅｄｉａ ｔｉｍｅが２００００、Ｍｅｄｉａ ｒａｔｅが１であるため、そのトラックの先頭から１３０
００の区間はサンプル中の時刻２００００から３３０００の区間を再生する。次に、エントリ＃２はＴｒａｃｋｄｕｒａｔｉｏｎが５０００、Ｍｅｄｉａ ｔｉｍｅが−１である
ため、トラック中の時刻１３０００から１８０００の区間、何も再生を行わない。
【００６７】
最後に、エントリ＃３はＴｒａｃｋ ｄｕｒａｔｉｏｎが１００００、Ｍｅｄｉａ ｔｉｍｅが０、Ｍｅｄｉａ ｒａｔｅが１であるため、トラック中の時刻１８０００から２８
０００の区間において、サンプル中の時刻０から１００００の区間を再生する。
【００６８】
図１２にＵｓｅｒ ｄａｔａ ａｔｏｍの構成を示す。このａｔｏｍには、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自の情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリはＳｉｚｅとＴｙｐｅとＵｓｅｒｄａｔａで構成される。Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報、Ｕｓｅｒ ｄａｔａは実際のデータを表す。
【００６９】
＜ＡＶストリームの形態＞
本発明において共通に用いられるＡＶストリームの構成について、図１３及び図１４を用いて説明する。ＡＶストリームは整数個のＲｅｃｏｒｄＵｎｉｔ（ＲＵ）で構成される。ＲＵはディスク上で連続的に記録する単位である。ＲＵの長さは、ＡＶストリームを構成するＲＵをどのようにディスク上に配置してもシームレス再生（再生中に画像や音声が途切れないで再生できること）やリアルタイムアフレコ（アフレコ対象のビデオをシームレス再生しながらオーディオを記録すること）が保証されるように設定される。この設定方法については後述する。
【００７０】
また、ＲＵ境界がＥＣＣブロック境界と一致するようにストリームを構成する。ＲＵのこれらの性質によって、ＡＶストリームをディスクに記録した後も、シームレス再生を保証したまま、ディスク上でＲＵ単位の配置を容易に変更することができる。
【００７１】
ＲＵは、整数個のＶｉｄｅｏ Ｕｎｉｔ（ＶＵ）で構成される。ＶＵは単独再生可能な
単位であり、そのことから再生の際のエントリ・ポイントとなり得る。
【００７２】
ＶＵ構成を図１４に示す。ＶＵは、１秒程度のビデオデータを格納した整数個のＧＯＰ（グループ・オブ・ピクチャ）と、それらと同じ時間に再生されるメインオーディオデータを格納した整数個のＡＡＵ（オーディオ・アクセス・ユニット）とから構成される。
【００７３】
尚、ＧＯＰは、ＭＰＥＧ−２ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。ＡＡＵはＭＰＥＧ−１Ｌａｙｅｒ−ＩＩ規格における音声圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数が４８ｋＨｚの場合、ＡＡＵあたりの再生時間は０．０２４秒となる。ＶＵ中では、ＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ、ＧＯＰの順に配置する。
【００７４】
また、ＶＵ単位で独立再生を可能とするために、ＶＵ中のビデオデータの先頭にはＳｅｑｕｅｎｃｅ Ｈｅａｄｅｒ（ＳＨ）を置く。ＶＵの再生時間は、ＶＵに含まれるビデオ
フレーム数にビデオフレーム周期をかけたものと定義する。さらに、ＶＵを整数個組み合わせてＲＵを構成する場合、ＲＵの始終端をＥＣＣブロック境界に合うよう、ＶＵの末尾を０で埋める。
【００７５】
＜ＡＶストリーム管理方法＞
ＡＶストリームの管理方法は、前述のＱｕｉｃｋＴｉｍｅファイルフォーマットをベースにしている。図１５にＡＶストリーム管理形態を示す。ビデオデータ及びオーディオデータをそれぞれビデオトラック、オーディオトラックで管理し、ビデオトラックは、１ビデオフレームを１サンプル、ＶＵ中のＧＯＰの列を１チャンクとして管理する。オーディオトラックは、ＡＡＵを１サンプル、ＶＵ中のＡＡＵの列を１チャンクとして管理する。
【００７６】
＜ＲＵ単位決定方法＞
次に、ＲＵ単位決定方法について説明する。この決定方法では、基準となるデバイス（リファレンス・デバイス・モデル）を想定し、その上でシームレス再生が破綻しないように連続記録単位を決める。
【００７７】
それではまず、リファレンス・デバイス・モデルについて、図１６を用いて説明する。リファレンス・デバイス・モデルは１個のピックアップとそれにつながるＥＣＣエンコーダ・デコーダ５０１、トラックバッファ５０２、デマルチプレクサ５０３、アフレコ用バッファ５０４、オーディオエンコーダ５０９、ビデオバッファ５０５、オーディオバッファ５０６、ビデオデコーダ５０７、オーディオデコーダ５０８とによって構成される。
【００７８】
本モデルにおけるシームレス再生は、ＶＵのデコード開始時にトラックバッファ５０２上に少なくとも１個ＶＵが存在すれば保証されるものとする。オーディオフレームデータのＥＣＣエンコーダ５０１へのデータの入力速度およびＥＣＣデコーダ５０１からデータの出力速度はＲｓとする。
【００７９】
また、アクセスによる読み出し、記録の停止する最大期間をＴａとする。さらに、短いアクセス（１００トラック程度）に要する時間をＴｋとする。なお、これら期間には、シーク時間、回転待ち時間、アクセス後に最初にディスクから読み出したデータがＥＣＣから出力されるまでの時間が含まれる。本実施例では、Ｒｓ＝２０Ｍｂｐｓ、Ｔａ＝１秒、Ｔｋ＝０．２秒とする。
【００８０】
前記リファレンス・デバイス・モデルにおいて再生を行った場合、次のような条件を満たせば、トラックバッファ５０２のアンダーフローがないことが保証できる。
【００８１】
条件を示す前にまず、記号の定義を行う。ＡＶストリームを構成するｉ番目の連続領域をＣ＃ｉとし、Ｃ＃ｉ中に含まれる再生時間をＴｃ（ｉ）とする。Ｔｃ（ｉ）はＣ＃ｉ中に先頭が含まれているＶＵの再生時間の合計とする。また、Ｃ＃ｉからＣ＃ｉ＋１へのアクセス時間をＴａとする。
【００８２】
また、再生時間Ｔｃ（ｉ）分のＶＵ読み出し時間をＴｒ（ｉ）とする。このとき、トラックバッファ５０２をアンダーフローさせない条件とは、分断ジャンプを含めた最大読み出し時間をＴｒ（ｉ）としたとき、任意のＣ＃ｉにおいて、
Ｔｃ（ｉ）≧Ｔｒ（ｉ）＋Ｔａ・・・＜式１＞
が成立することである。
【００８３】
なぜなら、この式は、シームレス再生の十分条件である、
ΣｉＴｃ（ｉ）≧Σｉ（Ｔｒ（ｉ）＋Ｔａ）
を満たす十分条件であるためである。
【００８４】
＜式１＞中のＴｒ（ｉ）に、Ｔｒ（ｉ）＝Ｔｃ（ｉ）×（Ｒｖ＋Ｒａ）／Ｒｓを代入して、Ｔｃ（ｉ）で解くとシームレス再生を保証可能なＴｃ（ｉ）の条件
Ｔｃ（ｉ）≧（Ｔａ×Ｒｓ）／（Ｒｓ−Ｒｖ−Ｒａ） ・・・＜式２＞
が得られる。
【００８５】
つまり、各連続領域に先頭の含まれるＶＵの合計が上式を満たすようにすれば、シームレス再生を保証可能である。このとき、各連続領域には合計の再生時間が上式を満たす完全なＶＵ群を含むように制限しても良い。
【００８６】
自動分割ムービーファイルでも＜式２＞を満たす必要がある。ただし、先頭の自動分割ムービーの最初のＲＵおよび末尾の自動分割ムービーの最後のＲＵは＜式２＞を満たさなくてもよい。なぜなら、先頭については記録媒体からのデータ読み出し開始より再生開始を遅らせることにより吸収でき、末尾については次に続くデータがないため連続再生を気にする必要が無いからである。このように先頭と末尾において条件を緩めることにより、
短い空き領域を有効利用できる。
【００８７】
＜インデックス・ファイル＞
光ディスク１０６内に含まれるＱｕｉｃｋＴｉｍｅムービーや静止画データ等を含む各種ファイル（以後、ＡＶファイルと呼ぶ）を管理するため、ＡＶＩｎｄｅｘファイルという特別のＱｕｉｃｋＴｉｍｅムービーファイルをディスク内に１個置く。図１７に、ＡＶ
Ｉｎｄｅｘファイルの構成を示す。ＡＶ Ｉｎｄｅｘファイルは通常のＱｕｉｃｋＴｉｍｅムービーファイルと同様、管理情報であるＭｏｖｉｅａｔｏｍ１７９１とデータ自体のＭｏｖｉｅ ｄａｔａ ａｔｏｍ１７９２で構成される。
【００８８】
ＡＶ Ｉｎｄｅｘファイルは、複数のエントリを管理する。ディスク内の各ＡＶファイ
ルはそれぞれ１個のエントリで管理される。さらに、各ＡＶファイルをまとめるための入れ物（以後フォルダと呼ぶ）等もそれぞれ１個のエントリで管理する。本実施形態においては、ディスク（光ディスク１０６）内のファイルを、ＡＶＩｎｄｅｘファイルを用いてエントリで管理する。このように、エントリを管理するテーブルは、このＡＶ Ｉｎｄｅ
ｘファイルに格納される。
【００８９】
Ｍｏｖｉｅ ａｔｏｍ１７９１は、各エントリの属性情報を管理するためのＰｒｏｐｅ
ｒｔｙｔｒａｃｋ１７９３、各エントリのタイトル文字列データを管理するためのＴｉｔｌｅ ｔｒａｃｋ１７９４、各エントリの代表画像データを管理するためのＴｈｕｍｂｎ
ａｉｌｔｒａｃｋ１７９５、各エントリの代表オーディオデータを管理するためのＩｎｔｒｏ ｍｕｓｉｃｔｒａｃｋ１７９６の計４種類のトラックで構成される。
【００９０】
各エントリに関する属性情報やタイトル文字列データ、代表画像データ、代表オーディオデータはそれぞれの１７９３〜１７９５のトラックのサンプルとして管理される。例えばＡＶファイル１７４１に関する属性情報はＰｒｏｐｅｒｔｙｔｒａｃｋ１７９３上のサンプル１７０１、タイトル文字列データはＴｉｔｌｅ ｔｒａｃｋ１７９４上のサンプル
１７１１、代表画像データはＴｈｕｍｂｎａｉｌ ｔｒａｃｋ１７９５上のサンプル１７
２１、代表オーディオデータはＩｎｔｒｏｍｕｓｉｃ ｔｒａｃｋ１７９６上のサンプル
１７３１で管理する。サンプル間の対応付けは、各サンプルの再生開始時間に基づき行う。すなわち、トラック間で同一時刻に位置するサンプルが同一エントリに対応していると判断する。
【００９１】
このように、Ｍｏｖｉｅ ａｔｏｍ１７９１は、各ＡＶファイルに関する属性情報や、
タイトル文字列データ、代表画像データ、代表オーディオデータを格納する。属性情報は図１８に示す構成を取る。各フィールドについて説明する。ｖｅｒｓｉｏｎは、ファイルフォーマットのバージョンを示す。ｐｅ−ｆｌａｇｓは各種フラグをまとめたものであり、詳細は後述する。
【００９２】
ｐａｒｅｎｔ−ｅｎｔｒｙ−ｎｕｍｂｅｒは、属性情報に対応するエントリが属するフォルダに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを格納、ｅｎｔｒｙ−ｎｕｍｂｅｒは、属性情報に対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを格納する。この２個の情報で、ファイルとフォルダの包含関係を表す。ｓｅｔ−ｄｅｐｅｎｄｅｎｔ−ｆｌａｇｓおよびｕｓｅｒ−ｐｒｉｖａｔｅ−ｆｌａｇｓについては、説明を省略する。
【００９３】
ｃｒｅａｔｉｏｎ−ｔｉｍｅおよびｍｏｄｉｆｉｃａｔｉｏｎ−ｔｉｍｅはこの属性情報に対応するエントリが作成された日時（作成時間）、修正された日時を表す。ｄｕｒａｔｉｏｎはこの属性情報に対応するエントリの再生時間を表す。ｂｉｎａｒｙ−ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒは、この管理情報に対応するエントリがファイルに対応していた場合、そのファイルのパス名を固定長にエンコーディングしたもので、詳細についての説
明は省略する。
【００９４】
ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒはこの属性情報に対応するエントリが管理するファイルが他のファイルから参照されている回数を格納する。すなわち、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒは、他のエントリが管理するファイルとの関連情報に相当する。ｒｅｆｅｒｒｉｎｇｆｉｌｅ ｌｉｓｔは、実際に参照しているファイルのパス名のリストを格納
する。ＵＲＬｆｉｌｅ ｉｄｅｎｔｉｆｉｅｒは、管理するファイルが上記のｂｉｎａｒ
ｙ−ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒにエンコードできない場合にＵＲＬ（ＵｎｉｆｉｅｄＲｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）形式で、ファイルのパスを格納する。
【００９５】
Ｍｏｖｉｅ ａｔｏｍ１７９１に格納されるその他のデータについて説明する。代表画
像データには１６０×１２０画素に縮小されたＪＰＥＧ圧縮されたデータ、タイトル文字列データにはテキストデータ、代表オーディオデータにはＭＰＥＧ−１Ａｕｄｉｏ Ｌａ
ｙｅｒ−ＩＩで圧縮されたデータをそれぞれ用いる。
【００９６】
＜第１の実施形態＞
本発明の第１の実施形態について、図１９乃至図２４を用いて説明する。この実施形態においては、ＡＶ Ｉｎｄｅｘファイルの属性情報に、自動分割ムービーファイルである
かどうかを区別するためのフラグを含ませる。これに応じて、適切な表示、ファイルの削除などを行うことによって、ユーザの混乱を防止する。
【００９７】
＜管理情報フォーマット＞
ＱｕｉｃｋＴｉｍｅムービーファイルおよびＡＶ Ｉｎｄｅｘファイルのフォーマット
は前述の通りである。そのうちＡＶＩｎｄｅｘファイルの属性情報（図１８）のｐｅ−ｆｌａｇｓフィールドを図１９のように定義している。以下、各フィールドの定義を説明する。Ａｔｔｒｉｂｕｔｅｏｆ Ｅｎｔｒｙは、このＰｒｏｐｅｒｔｙエントリに対応する
エントリの属するレイヤーの種別を格納する。レイヤーについてはここでは説明を省略する。
【００９８】
Ｔｙｐｅ ｏｆ Ｅｎｔｒｙは対応するエントリがファイルかフォルダかを識別するための情報を格納する。Ｕｓａｇｅｏｆ ＥｎｔｒｙおよびＳｔａｔｕｓ ｏｆ Ｅｎｔｒｙに
ついてはここでは説明を省略する。Ｄａｔａ ｒｅｆｅｒｅｎｃｅ ｏｆ ｃｏｒｒｅｓｐ
ｏｎｄｉｎｇ ＡＶ Ｆｉｌｅは、対応するエントリがＡＶファイルを管理していた場合に、他のＡＶファイルを参照しているかどうか判別するためのフラグである。
【００９９】
Ｓｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌ
ｅは、対応するエントリが自動分割ムービーファイルであるかどうかを区別するためのフラグであり、自動分割ムービーファイルの場合１がセットされる。Ｓｅｃｕｒｉｔｙｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅは、対応するエントリがＡＶ
ファイルを管理していた場合に、暗号化されているかどうか判別するためのフラグである。
【０１００】
Ｃｏｎｔｅｎｔ ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅは、対応
するエントリがＡＶファイルを管理していた場合に、そのファイルに含まれるコンテンツの種別を格納するフィールドである。このように、本実施形態においては、ＡＶＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍのうちの、属性情報に含まれるｒｅｆｅｒｒｅｄ−ｃ
ｏｕｎｔｅｒの項目によって、対応するエントリが管理するファイルが他のファイルから参照されている回数を区別する。また、ＡＶＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍ
のうちの、属性情報に含まれるｐｅ−ｆｌａｇｓにおける、Ｓｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅのフラグによって、対応するエ
ントリが自動分割ムービーファイルであるかどうかを区別する。以下、これらのフィールドを含めた属性情報をどのように用いるかを説明する。
【０１０１】
＜記録時の処理＞
ユーザから録画が指示された場合の処理を、図２０に沿って説明する。このとき記録するＡＶストリームは、ビデオのビットレートＲｖ＝５Ｍｂｐｓ、オーディオのサンプリング周波数４８ｋＨｚ、ビットレートＲａ＝２５６ｋｂｐｓであるものとする。すでに、ファイルシステムの管理情報はＲＡＭ１０２上に読み込まれているとする。
【０１０２】
まず、ストリームの構成や連続領域の構成を決定する（ステップ（Ｓ）７０１）。 １
ＶＵを１ＧＯＰ＝３０フレームで構成するとしたとき、＜式２＞にＲｓ＝２０Ｍｂｐｓ、Ｔａ＝１秒、Ｒｖ＝５Ｍｂｐｓ、Ｒａ＝２５６ｋｂｐｓを代入し、Ｔｃ（ｉ）の範囲である１．３６秒以上が得られる。１ＶＵの再生時間を０．５秒としているため、ＲＵ再生時間は２秒とする。
【０１０３】
次に、ムービーファイル記録準備を行う（ステップ７０２）。具体的にはファイルをｏｐｅｎし、１個のＲＵを連続的に記録可能な空き領域を探す。存在しなければ録画を中止し、録画できないことをユーザに知らせる。
【０１０４】
また、オーディオエンコーダ１１７、ビデオエンコーダ１１８をそれぞれ起動する（ステップ７０３）。次に、記録用バッファ１１１に１ＲＵ分のデータが蓄積されているかどうかチェックする（ステップ７０４）。
【０１０５】
蓄積されていれば、記録用バッファ１１１中の１ＲＵ分のデータを連続的に光ディスク１０６に記録する（ステップ７０５）。次に現在記録中のファイルのサイズを調べ（ステップ７０６）、次のＲＵを記録したらファイルサイズが４ＧＢを超える可能性がある場合、現在記録中のムービーファイルの管理情報を記録し（ステップ７０７）、以後のデータを別のムービーファイルに記録できるよう新規ムービーファイル記録の準備を行う（ステップ７０８）。また、ステップ７０８の後には、次の１ＲＵ分のデータを記録するために、ステップ７０３に戻る。また、ステップ７０６において、次のＲＵを記録してもファイルサイズが４ＧＢを超えない場合にも、ステップ７０３に戻る。
【０１０６】
ステップ７０４において、１ＲＵ分のデータが蓄積されていなければ、記録終了が指示されていないかどうかチェックし（ステップ７０９）、指示されていなければステップ７０４を実行し、指示されていれば以下の記録終了処理を行う。まず、現在記録中のムービーファイルに残りデータを記録し（ステップ７１０）、管理情報を記録する（ステップ７１１）。
【０１０７】
次に、自動分割されたかどうかをチェックし（ステップ７１２）、自動分割されたなら、統括ムービーファイルを作成する（ステップ７１３）。最後に、ＡＶＩｎｄｅｘファイルに今回作成したＱｕｉｃｋＴｉｍｅムービーファイルを登録する（ステップ７１４）。自動分割された場合は、自動分割ムービーファイルおよび統括ファイルを登録し、それ以外の場合は１個のＱｕｉｃｋＴｉｍｅムービーファイルを登録する。また、ステップ７１２において、自動分割されていなかった場合にも、ステップ７１４に進む。
【０１０８】
図２１を用いて、ＡＶ Ｉｎｄｅｘファイル１８００に登録する属性情報をどのように
セットするかを説明する。まず、自動分割によって自動分割ムービーファイル１８０１、１８０２と統括ムービーファイル１８０３とに分割されて記録された場合について説明する。ここで、この自動分割ムービーファイル１８０１、１８０２が、分割データに相当し、統括ムービーファイル１８０３が、分割データを参照する統括データに相当する。
【０１０９】
自動分割ムービーファイル１８０１、１８０２に関しては、自動分割されているため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉ
ｎｇＡＶ Ｆｉｌｅを１（ａｕｔｏ−ｄｉｖｉｄｅｄ）にセットする。また、統括ムービ
ーファイル１８０３によって参照されているため、属性情報エントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１にセットする。また、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔには、統括ムービーファイル１８０３のｅｎｔｒｙ−ｎｕｍｂｅｒである３をセットする。
【０１１０】
一方、統括ムービーファイル１８０３に関しては、他のファイルから参照されていないため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには０をセットする。また自動分割されていないため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅには０をセットする。
【０１１１】
次に、自動分割されず記録された通常記録ムービーファイル１８０４の場合について説明する。通常記録ムービーファイル１８０４に関しては、他のファイルから参照されていないため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒは０にセットする。また自動分割されていないため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅは０にセットする。
【０１１２】
＜非破壊編集時の処理＞
非破壊編集処理を行った際のＡＶ Ｉｎｄｅｘファイルの管理方法について、図２２を
用いて説明する。まず、自動分割されていないＱｕｉｃｋＴｉｍｅムービーを非破壊編集した場合について説明する。ＡＶＩｎｄｅｘファイル１８００に通常ムービーファイル１８０４が登録されており、このファイルを部分的に参照する非破壊編集結果ムービーファイル１８０５を作成したと仮定する。
【０１１３】
このとき、ＡＶ Ｉｎｄｅｘファイル１８００に登録されている通常ムービーファイル
１８０４の属性情報エントリ中の値は、非破壊編集結果ムービーファイル１８０５から参照されているため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには１がセットされる。また、ｒｅｆｅｒｒｅｄ−ｆｉｌｅ−ｌｉｓｔには非破壊編集結果ムービーファイル１８０５のｅｎｔｒｙ−ｎｕｍｂｅｒである５が格納される。
【０１１４】
また、自動分割されていないため、ｐｅ−ｆｌａｇｓの Ｓｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅは０にセットされる。一方、非
破壊編集結果ムービーファイル１８０５の属性情報エントリ中の値は、他のファイルから参照されていないため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには０がセットされる。また、自動分割されていないため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ 
ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅには０がセットされる。
【０１１５】
次に、自動分割されたＱｕｉｃｋＴｉｍｅムービーを非破壊編集した場合について説明する。ここでは、自動分割によって自動分割ムービーファイル１８０１、１８０２と統括ムービーファイル１８０３に分割されて記録されたＱｕｉｃｋＴｉｍｅムービーの一部を参照する、非破壊編集結果ムービーファイル１８０６を作成したと仮定する。
【０１１６】
このとき、ＡＶ Ｉｎｄｅｘファイル１８００に登録されている自動分割ムービーファ
イル１８０１、１８０２の属性情報エントリ中の値は、統括ムービーファイル１８０３および非破壊編集結果ムービーファイル１８０６から参照されているため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには２がセットされる。また、ｒｅｆｅｒｒｅｄ−ｆｉｌｅ−ｌｉｓｔには統括ムービーファイル１８０３および非破壊編集結果ムービーファイル１８０６のｅｎｔｒｙ−ｎｕｍｂｅｒである３、６が格納される。
【０１１７】
また、自動分割されているため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌ ｓｔａｔ
ｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅは１にセットされる。統括ムービ
ーファイル１８０３および非破壊編集結果ムービーファイル１８０５、１８０６の属性情報エントリ中の値は、他のファイルから参照されていないため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには０がセットされる。また自動分割されていないため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅに
は０がセットされる。
【０１１８】
＜コンテンツ選択画面表示処理＞
ユーザには、属性情報エントリ中のｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌ ｓｔａ
ｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅが０のエントリについてサムネ
イル画像を表示する。例えば図２２の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４、５、６のサムネイル画像が表示されることになる。このように、例えばムービーデータの属性情報エントリ中の、対応するエントリが自動分割ムービーファイルであるかどうかを区別するためのフラグ（分割記録されたかどうかの情報）に応じて、コンテンツ選択画面にサムネイル画像を表示するか否かを決定してもよい。ユーザは、このコンテンツ選択画面から、所望のファイルに対応したサムネイル画像を選択し、そのファイルを再生、削除などすることができる。
【０１１９】
＜削除時の処理＞
コンテンツ選択画面を通じてユーザから削除を指示された場合の運用方針として、次の２種類が考えられる。
【０１２０】
（運用方針１）非破壊編集によって作成されたＡＶファイルは削除可能、それ以外のＡＶファイルは非破壊編集ムービーによって参照されていなければ削除可能とする。なお、自動分割ムービーファイルが非破壊編集ムービーから参照されている場合、その自動分割ムービーファイルを統括する統括ムービーファイルもその非破壊編集ムービーファイルから参照されているものとして扱う。
【０１２１】
（運用方針２）他のＡＶファイルから参照されていないＡＶファイルは削除可能とする。
【０１２２】
（運用方針１）は、ユーザの記録したオリジナル（初期記録）のデータとそこから派生する編集結果を区別し、オリジナルデータをなるべく保護しよう、という考えに基づく。（運用方針２）は、削除によって他のＡＶファイルに影響を与えなければよい、という考えに基づく。
【０１２３】
ここで、オリジナルのデータとは、例えば録画・録音されたそのままのファイルを意味する。一方、オリジナルでないデータとは、例えば録画・録音されたデータそのものではなく、編集によって作成されたＡＶファイルを意味する。すなわち、例えば非破壊編集されたファイルは、オリジナルでないデータである。
【０１２４】
また、ファイルシステムを用いてデータにアクセスする場合には、例えばオリジナルのデータのファイルをオリジナルのファイルと表現し、また例えばオリジナルのファイルのエントリをオリジナルのエントリと表現する。
【０１２５】
以下、それぞれの方針を実施する際の処理手順について説明する。
【０１２６】
＜削除時の処理（運用方針１）＞
図２２の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが５、６のエントリは非破壊編集によって作成されたムービーに相当し、３、４のエントリはｅｎｔｒｙ−ｎｕｍｂｅｒが５、６のムービーに参照されているオリジナルデータに対応する。したがって、ユーザから削除対象としてｅｎｔｒｙ−ｎｕｍｂｅｒが５、６のエントリを指定されたら、削除し、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４のエントリを指定されたら、削除を拒絶あるいは警告を出すことになる。
【０１２７】
以下、削除可能かどうかを判断するための処理手順について、図２３を用いて説明する。まず、指定されたエントリに対応するＡＶファイルが別のＡＶファイルから参照されていないかを調べるため、指定されたエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを調べる。１以上の場合、参照されているため削除不可と判断する（ステップ８０１）。例えば図２２に示す例において、ムービーファイル１８０４は、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが１であるので、削除不可と判断される。ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０の場合は、ステップ８０２に進む。
【０１２８】
次に、指定されたエントリに対応するＡＶファイルが別のＡＶファイルを外部参照しているかどうか調べる。参照していない場合、削除可能と判断する（ステップ８０２）。外部参照しているかどうかは、Ｄａｔａｒｅｆｅｒｅｎｃｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅを参照することで判断できる。あるいは他のエントリのｒｅｆｅｒｒ
ｅｄ−ｆｉｌｅ−ｌｉｓｔを調べ、指定されたエントリのｅｎｔｒｙ−ｎｕｍｂｅｒが含まれているかどうかで判断できる。
【０１２９】
次に、指定されたＡＶファイルが非破壊編集によって作成されたムービーか、それ以外かを調べる（ステップ８０３）。その手順について、図２４のフローチャートを用いて説明する。まず、指定されたエントリのｅｎｔｒｙ−ｎｕｍｂｅｒが含まれるｒｅｆｅｒｒｅｄ−ｆｉｌｅ−ｌｉｓｔを持つエントリをすべてリストアップし、そのエントリのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅの値を
調べる（ステップ９０１）。これによって、そのエントリが分割記録（自動分割）されたものであるか否かを調べる。
【０１３０】
１個でも１（ａｕｔｏ−ｄｉｖｉｄｅｄ）でなければ、非破壊編集によって作成されたムービーと判断する（ステップ９０２）。すべてが１であれば、次にそのエントリに対応するのが統括ムービーファイルなのか非破壊編集ムービーファイルなのかを識別する。具体的には、リストアップされたエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒをチェックし（ステップ９０３）、１個でも２以上のものがない場合には、統括ムービーファイルであるとして、オリジナルのファイルであると判断する（ステップ９０４）。すなわち、非破壊編集によって作成されたムービーファイルでないと判断する。このように、他のエントリが管理するデータとの関連情報としてのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒに応じて判別を行う。
【０１３１】
ステップ９０４においてｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒの値が２以上のものがあれば、そのエントリに対応するファイルを参照している別のファイルに対応するエントリとｃｒｅａｔｉｏｎ−ｔｉｍｅ（作成時間）を比較し、最も古い場合、統括ムービーファイル（オリジナルのファイル）と判断し、それ以外の場合は非破壊編集ムービーファイルと判断する（ステップ９０５）。
【０１３２】
例えば図２２に示す例において、統括ムービーファイル１８０３について上述の手順を実行すると、ステップ９０１，９０２，９０３，９０４を介して、ステップ９０５にて、他のムービーファイル１８０６とｃｒｅａｔｉｏｎ−ｔｉｍｅが比較されて、オリジナルのファイルであると判別されることになる。また、ムービーファイル１８０５，１８０６
については、上述の手順にて非破壊編集ムービーファイルであると判別される。
【０１３３】
なお、ここでは属性情報エントリ中のｃｒｅａｔｉｏｎ−ｔｉｍｅで判断しているが、例えばｄｕｒａｔｉｏｎを用いてもよい。具体的には、参照先のＡＶファイルのｄｕｒａｔｉｏｎの合計と指定されたムービーのｄｕｒａｔｉｏｎが一致すれば統括ムービーファイル、すなわち非破壊編集によって作成されたムービーファイルでない、一致しなければ非破壊編集ムービーファイルと判断する。
【０１３４】
ここで、再び図２３を用いて説明する。指定されたエントリに対応するＡＶファイルがオリジナルでなければ削除可能と判断し（ステップ８０４）、オリジナルであれば次のステップ８０５に進む。次に、指定されたエントリに対応するＡＶファイルが参照しているＡＶファイルのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒをチェックし（ステップ８０５）、すべてが１であれば削除可能、そうでなれば削除不可と判断する（ステップ８０６）。
【０１３５】
次に、削除可能と判断され、実際に削除を行った後の処理について説明する。削除されたのが統括ムービーファイルの場合、統括ムービーファイルだけでなくそこから参照されている自動分割ムービーファイルも削除を行う。
【０１３６】
非破壊編集ムービーファイルの場合、非破壊編集ムービーファイルを削除し、さらに、そのファイルから参照されているＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減らし、さらに、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔからその非破壊編集ムービーファイルに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを削除する。それ以外のＡＶファイルの場合、そのＡＶファイルを削除するだけでよい。なお、いうまでも無いが、削除したＡＶファイルに対応するＡＶＩｎｄｅｘファイルのエントリも削除する。
【０１３７】
このように、ステップ８０３，８０４にて、エントリがオリジナルであるか否かを判断することによって、そのエントリを削除可能であるか削除不可であるかを判断して、これに応じて削除する。したがって、自動分割ムービーファイルがある場合でもユーザに違和感を与えず削除を実行することができる。
【０１３８】
また、上記構成においては、例えば図２３を参照して説明したように、ステップ８０４においてオリジナルであるか否か（初期記録データであるか否か）を判別し、オリジナルであると判別したファイルを、ステップ８０６において参照先のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが全て１の場合には削除可能と判別し、参照先のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが全て１ではない場合には削除不可と判別する。
【０１３９】
したがって、例えば図２２に示すような統括ムービーファイル１８０３について削除の可否を判別する場合には、参照先のファイル１８０１，１８０２のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが全て１ではなく、他のムービーファイル１８０６からも参照されているので、削除不可と判別する。
【０１４０】
また、統括ムービーファイル１８０３について、図２１に示す状態において削除の可否を判別する場合には、参照先のファイル１８０１，１８０２のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが全て１であるので、削除可能と判別する。そして、削除する際には、統括ムービーファイル１８０３に加えて、参照先のファイル１８０１，１８０２をも削除する。
【０１４１】
このように、自動分割ムービーファイルがある場合でも、自動分割ムービーファイルが統括ムービーファイルのみから参照されており、他のファイルから参照されていないときにのみ削除するので、ユーザに違和感を与えず削除を実行できる。また、参照ムービー（
自動分割ムービー、統括ムービー）をユーザに混乱を与えずに管理できる。
【０１４２】
また、図２４を参照して説明したように、登録されているエントリがオリジナルか否かを判断する際には、ステップ９０１〜９０５にて、分割記録されたかどうかの情報、他のエントリが管理するデータとの関連情報、および作成時間に基づいて判断する構成である。したがって、オリジナルか否かを確実に判別できる。
【０１４３】
＜削除時の処理（運用方針２）＞
図２２の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが ３、５、６のエントリに関して、ｒｅｆ
ｅｒｒｅｄ−ｃｏｕｎｔｅｒが０であるため、他のエントリに対応するＡＶファイルから参照されていない、と判断できる。したがって、ユーザから削除対象としてｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリを指定されたら削除し、ｅｎｔｒｙ−ｎｕｍｂｅｒが４のエントリを指定されたら、削除を拒絶あるいは警告を出すことになる。
【０１４４】
実際の削除は、以下の手順で行う。まず、削除を指定されたファイルから参照されているＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減らし、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔからそのＡＶファイルに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを削除する。もし、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０になった場合、そのＡＶファイルを削除する。最後に、削除を指定されたＡＶファイルを削除する。なお、いうまでも無いが、削除したＡＶファイルに対応するＡＶＩｎｄｅｘファイルのエントリも削除する。
【０１４５】
＜第２の実施形態＞
本発明の第２の実施形態について、図２５乃至図２７を用いて説明する。この実施形態においては、ＡＶ Ｉｎｄｅｘファイルの属性情報に、自動分割ムービーファイルである
かどうかを区別するためのフラグに加えて、初期記録データか否かに関するフラグを含ませる。これに応じて、適切な表示、ファイルの削除などを行うことによって、ユーザの混乱を防止する。第２の実施形態は、例えば以下に説明するような、第１の実施形態において記録機器の内蔵時計が正確でない場合に生ずる問題をも解決できる実施形態である。なお、上述した第１の実施形態と共通する点が多いため、ここでは異なる点のみに絞って説明を行う。
【０１４６】
＜管理情報フォーマット＞
ＱｕｉｃｋＴｉｍｅムービーファイルおよびＡＶ Ｉｎｄｅｘファイルのフォーマット
は前述の通りである。本実施形態においては、ＡＶＩｎｄｅｘファイルのＰｒｏｐｅｒｔｙエントリ中のｐｅ−ｆｌａｇｓフィールドは図２５のように定義されている。ｐｅ−ｆｌａｇｓには、例えばＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅのフラグも含まれている。上述した第１の実施形態とほぼ同じである
が、Ｔｙｐｅｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅという、このエントリに
対応するＡＶファイルがオリジナルか編集によって作成されたものかを区別するためのフラグが追加されている点が異なる。Ｔｙｐｅｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆ
ｉｌｅの値が０であればオリジナル（録画・録音されたそのまま）のＡＶファイル、１であれば編集によって作成されたＡＶファイルとなる。すなわち、ＡＶＩｎｄｅｘファイルにおける、Ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅというフラグは、
エントリが管理するデータが初期記録データか否かに関する情報に相当する。
【０１４７】
このフラグの説明を次に行う。第１の実施形態では、図２３に示すように削除時にオリジナルファイルか非破壊編集ファイルかを区別する。ここで、オリジナルファイルとは、ユーザの撮影した初期記録ファイルのことである。その際、図２４に示すようにｃｒｅａｔｉｏｎ−ｔｉｍｅを参照して判断を行っているが、記録機器の内蔵時計が正確でない場
合、処理に誤りが生じる可能性がある。このフラグを導入することで、記録機器の内蔵時計に依存することなくオリジナルファイルか非破壊編集ファイルかを区別することが可能になる。また、ＡＶＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍのうちの、属性情報に含
まれる ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒの項目によって、対応するエントリが管理す
るファイルが他のファイルから参照されている回数を区別する点も、上述の実施の形態と同様である。
【０１４８】
＜記録時の処理＞
ユーザから録画が指示された場合の処理は、第１の実施形態と同じであるため省略する。ただし、図２６に示すように、ＡＶ Ｉｎｄｅｘファイルの属性情報エントリに追加さ
れたＴｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅに、０を設定する点が異なる。
【０１４９】
＜非破壊編集処理＞
非破壊編集処理を行った際のＡＶ Ｉｎｄｅｘファイルの管理方法については、上述し
た第１の実施形態と同じであるため説明を省略する。ただし、図２７に示すように、非破壊編集結果ムービー１８０５、１８０６に対応するＡＶＩｎｄｅｘファイルの属性情報中のＴｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅに１を設定する点が異なる。
【０１５０】
＜コンテンツ選択画面表示処理＞
ユーザには、属性情報エントリ中のｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌ ｓｔａ
ｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅが０のエントリについてサムネ
イル画像を表示する。例えば図２７の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４、５、６のサムネイル画像が表示されることになる。
【０１５１】
＜削除時の処理＞
コンテンツ選択画面を通じてユーザから削除を指示された場合の運用方針として、上述した第１の実施形態と同様、（運用方針１）および（運用方針２）の２種類が考えられる。以下、それぞれの方針を実施する際の処理手順について説明する。
【０１５２】
＜削除時の処理（運用方針１）＞
コンテンツ選択画面を通じてユーザから削除を指示された場合の処理は第１の実施形態において図２３、図２４を参照して説明した処理とほぼ同じである。ただし、本実施形態では、図２３のステップ８０３において、指定されたエントリに対応するＡＶＦｉｌｅが非破壊編集によって作成されたものかオリジナルかを判断するのに、指定されたエントリのｐｅ−ｆｌａｇｓのＴｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅを参照して、１なら非破壊編集、０ならオリジナルと判断する。この点が第１の実施形態と異なる。
【０１５３】
このように、本実施形態においては、ＡＶ Ｉｎｄｅｘファイルにおける、Ｔｙｐｅｏ
ｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅというフラグを用いて、ファイルがオリ
ジナルか否かを判断する構成である。このフラグは、記録または非破壊編集などによる、ファイルの作成時に設定するので、確実に、ファイルがオリジナルか否かを判別できる。
【０１５４】
上述した第１の実施形態では、ｃｒｅａｔｉｏｎ−ｔｉｍｅを参照して判断を行うため、記録機器の内蔵時計が正確でない場合、処理に誤りが生じる可能性があるが、本実施形態の場合、内蔵時計の正確さに処理が依存しないという利点がある。
【０１５５】
また、ファイルの削除の際には、上述の実施の形態と同様に、自動分割ムービーファイ
ルがある場合でも、自動分割ムービーファイルが統括ムービーファイルのみから参照されており、他のファイルから参照されていないときにのみ削除するので、ユーザに違和感を与えず削除を実行できる。また、参照ムービー（自動分割ムービー、統括ムービー）をユーザに混乱を与えずに管理できる。
【０１５６】
＜削除時の処理（運用方針２）＞
第１の実施形態と同様である。すなわち、図２７の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリに関して、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０であるため、他のエントリに対応するＡＶファイルから参照されていない、と判断できる。したがって、ユーザから削除対象としてｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリを指定されたら削除し、ｅｎｔｒｙ−ｎｕｍｂｅｒが４のエントリを指定されたら、削除を拒絶あるいは警告を出すことになる。
【０１５７】
実際の削除は、以下の手順で行う。まず、削除を指定されたファイルから参照されているＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減らし、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔからそのＡＶファイルに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを削除する。もし、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０になった場合、そのＡＶファイルを削除する。最後に、削除を指定されたＡＶファイルを削除する。なお、いうまでも無いが、削除したＡＶファイルに対応するＡＶＩｎｄｅｘファイルのエントリも削除する。
【０１５８】
＜第３の実施形態＞
本発明の第３の実施形態について、図２８乃至図３２を用いて説明する。この実施形態においては、ＡＶ Ｉｎｄｅｘファイルの属性情報に、自動分割ムービーファイルである
かどうかを区別するためのフラグ、初期記録データか否かに関するフラグに加えて、データをユーザに見せるかどうかに関するフラグを含ませる。これに応じて、適切な表示、ファイルの削除などを行うことによって、ユーザの混乱を防止する。なお、上述した第１および第２の実施形態と共通する点が多いため、ここでの説明は相違点のみに絞る。
【０１５９】
＜管理情報フォーマット＞
ＱｕｉｃｋＴｉｍｅムービーファイルおよびＡＶ Ｉｎｄｅｘファイルのフォーマット
は前述の通りである。ＡＶＩｎｄｅｘファイルのＰｒｏｐｅｒｔｙエントリ中のｐｅ−ｆｌａｇｓフィールドは図２８に示すように定義されている。ｐｅ−ｆｌａｇｓには、例えばＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅ
のフラグや、Ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅのフラグも含まれている。上述した第２の実施形態とほぼ同じであるが、Ｖｉｓｕａｌｓｔａｔｕｓ ｏ
ｆ Ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅという、このエントリを
コンテンツ選択画面等でユーザに見せる（０の場合）か隠す（１の場合）かを示すフラグが追加されている点が異なる。このＡＶＩｎｄｅｘファイルのＶｉｓｕａｌ ｓｔａｔｕ
ｓ ｏｆ Ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅというフラグは、エ
ントリが管理するデータをユーザに見せるかどうかを管理する情報に相当する。
【０１６０】
このフィールドを設けることで、後述するように第１および第２の実施形態における削除の運用方法に比べ、異なる運用方法を選択することが可能になる。
【０１６１】
なお、ＡＶ ＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍのうちの、属性情報に含まれるｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒの項目によって、対応するエントリが管理するファイルが他のファイルから参照されている回数を区別する点も、上述の実施の形態と同様である。
【０１６２】
＜記録時の処理＞
ユーザから録画が指示された場合の処理は、上述した第１の実施形態と同じであるため説明を省略する。ただし、図２９に示すように、ＡＶＩｎｄｅｘファイルの属性情報エントリに追加されたＶｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ 
Ｆｉｌｅに、自動分割ムービーファイル１８０１および１８０２に関しては１を設定し、統括ムービーファイル１８０３および通常ムービーファイル１８０４に関しては０を設定する点が異なる。
【０１６３】
＜非破壊編集処理＞
非破壊編集処理を行った際のＡＶ Ｉｎｄｅｘファイルの管理方法については、上述し
た第２の実施形態と同じであるため説明を省略する。ただし、図３０に示すように、非破壊編集結果ムービー１８０５、１８０６に対応するＡＶＩｎｄｅｘファイルの属性情報エントリ中のＶｉｓｕａｌ Ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌ
ｅに０を設定する点が異なる。
【０１６４】
＜アフレコ時の処理＞
図２９のＡＶファイル１８０４に対し、オーディオアフレコを行い、図３１に示すように、入力されたオーディオデータを前記ムービーとは別のＡＶファイル１８０７に格納し、ＡＶファイル１８０４から外部参照するものとする。このとき、ＡＶファイル１８０７に対応するエントリ（ｅｎｔｒｙ−ｎｕｍｂｅｒ＝５のエントリ）のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒは、ＡＶファイル１８０４から参照されているため１となり、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔには、ＡＶファイル１８０４に対応するｅｎｔｒｙ−ｎｕｍｂｅｒである４が格納される。
【０１６５】
また、ＡＶファイル１８０７はＡＶファイル１８０４の付属物であり独立のコンテンツとして扱うことはないため、コンテンツ選択画面に表示しない。そのため、Ｖｉｓｕａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅの値は１（Ｉｎｖｉｓｉ
ｂｌｅ）に設定する。
【０１６６】
＜コンテンツ選択画面表示処理＞
ユーザには、属性情報エントリ中のｐｅ−ｆｌａｇｓのＶｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅが０のエントリについてサムネイル画像
を表示する。すなわち、Ｖｉｓｕａｌ ｓｔａｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ 
ＡＶ Ｆｉｌｅのフラグに基づいて、表示を制御する。例えば図３０の場合、ｅｎｔｒｙ
−ｎｕｍｂｅｒが３、４、５、６のサムネイル画像が表示されることになる。図３１の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４のサムネイル画像が表示され、独立のコンテンツとして扱うことの無いＡＶファイル１８０７に対応するサムネイルは表示されない。不要な情報を表示しないことによって、ユーザに混乱を与える可能性が低くなる。このことは、本実施形態で導入されたＶｉｓｕａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅという情報で可能となっている。
【０１６７】
＜削除時の処理＞
本実施形態では、コンテンツ選択画面を通じてユーザから削除を指示された場合の運用方針は、第１、第２の実施形態で使用しているものに追加して、次のものが考えられる。
【０１６８】
（運用方針３）すべてのＡＶファイルは削除可能とする。
【０１６９】
（運用方針３）は、ユーザにオリジナルと編集結果の違いをなるべく意識させない、という考えに基づく。なお、（運用方針３）は、第３の実施形態で導入された管理情報によって可能となっている。
【０１７０】
以下、それぞれの方針を実施する際の処理手順について説明する。
【０１７１】
＜削除時の処理（運用方針１）＞
上述した第２の実施形態と同様である。すなわち、コンテンツ選択画面を通じてユーザから削除を指示された場合の処理は第１の実施形態において図２３、図２４を参照して説明した処理とほぼ同じである。ただし、本実施形態では、図２３のステップ８０３において、指定されたエントリに対応するＡＶＦｉｌｅが非破壊編集によって作成されたものかオリジナルかを判断するのに、指定されたエントリのｐｅ−ｆｌａｇｓのＴｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅを参照して、１なら非破壊編集、０ならオリジナルと判断する。この点が第１の実施形態と異なる。
【０１７２】
このように、本実施形態においては、ＡＶ Ｉｎｄｅｘファイルにおける、Ｔｙｐｅｏ
ｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅというフラグを用いて、ファイルがオリ
ジナルか否かを判断する構成である。このフラグは、記録または非破壊編集などによる、ファイルの作成時に設定するので、確実に、ファイルがオリジナルか否かを判別できる。また、本実施形態の場合、内蔵時計の正確さに処理が依存しないという利点がある。
【０１７３】
また、ファイルの削除の際には、上述の実施の形態と同様に、自動分割ムービーファイルがある場合でも、自動分割ムービーファイルが統括ムービーファイルのみから参照されており、他のファイルから参照されていないときにのみ削除するので、ユーザに違和感を与えず削除を実行できる。また、参照ムービー（自動分割ムービー、統括ムービー）をユーザに混乱を与えずに管理できる。
【０１７４】
＜削除時の処理（運用方針２）＞
上述した第１の実施形態と同じである。すなわち、図３０の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリに関して、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０であるため、他のエントリに対応するＡＶファイルから参照されていない、と判断できる。したがって、ユーザから削除対象としてｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリを指定されたら削除し、ｅｎｔｒｙ−ｎｕｍｂｅｒが４のエントリを指定されたら、削除を拒絶あるいは警告を出すことになる。
【０１７５】
実際の削除は、以下の手順で行う。まず、削除を指定されたファイルから参照されているＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減らし、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔからそのＡＶファイルに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを削除する。もし、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０になった場合、そのＡＶファイルを削除する。最後に、削除を指定されたＡＶファイルを削除する。なお、いうまでも無いが、削除したＡＶファイルに対応するＡＶＩｎｄｅｘファイルのエントリも削除する。
【０１７６】
＜削除時の処理（運用方針３）＞
コンテンツ選択画面を通じてユーザから削除を指示されたエントリはすべて削除可能、という運用を行う場合の処理について説明する。以下、削除の処理手順について、図３２を用いて説明する。まず、指定されたエントリに対応するＡＶファイルが別のＡＶファイルから参照されていないかを調べるため、指定されたエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを調べる（ステップ１００１）。ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが１の場合、Ｖｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅを１
にセットする（ステップ１００６）。このことにより、他のムービーの再生に影響を与えることなくユーザに対して削除したように見せることができる。すなわち、ファイルを見かけ上削除することができる。なお、この場合、Ｖｉｓｕａｌｓｔａｔｕｓ ｏｆ ｃｏｒ
ｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅのフラグは、０から１に変更されることになる。ｒ
ｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０の場合、指定されたエントリに対応するＡＶファイルが他のＡＶファイルを参照しているかどうかを調べる（ステップ１００２）。
【０１７７】
参照していなければ、後述するステップ１００５を実行する。参照していた場合、まず、参照先のＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減ずる（ステップ１００３）。
【０１７８】
次に、参照先のＡＶファイルのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒおよびＶｉｓｕａｌ
ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶの値を調べ、ｒｅｆｅｒｒｅｄ−
ｃｏｕｎｔｅｒが０、なおかつＶｉｓｕａｌ ｓｔａｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶが１（ｉｎｖｉｓｉｂｌｅ）ならそのファイルを削除し、ＡＶＩｎｄｅｘファ
イルからそのファイルに関するエントリを削除する（ステップ１００４）。最後に、指定されたエントリに対応するＡＶファイルを削除する（ステップ１００５）。
【０１７９】
図３０を用いて上記の処理を具体的に説明する。ｅｎｔｒｙ−ｎｕｍｂｅｒが５あるいは６に対応するエントリを削除指定した場合、それらのエントリを削除し、さらにファイル１８０５あるいは１８０６は削除する。ｅｎｔｒｙ−ｎｕｍｂｅｒが３に対応するエントリを削除指定した場合、そのエントリを削除し、ファイル１８０３も削除する。ただし、参照先のファイル１８０１および１８０２はファイル１８０６から参照されているため削除されない。
【０１８０】
ｅｎｔｒｙ−ｎｕｍｂｅｒが４に対応するエントリを削除指定した場合、そのエントリに対応するファイル１８０４はファイル１８０５から参照されているため削除せず、代わりにＶｉｓｕａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅを１に
セットする。
【０１８１】
図３１の場合も上記と同様である。ｅｎｔｒｙ−ｎｕｍｂｅｒが４に対応するエントリを削除指定した場合、ｒｅｆｅｒｒｅｄ ｃｏｕｎｔｅｒが０であり、そこから参照され
ているＡＶファイル１８０７のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減じて０になるため、ｅｎｔｒｙ−ｎｕｍｂｅｒが４、５に対応するエントリを削除し、さらに、それらのエントリに対応するＡＶファイル１８０４、１８０７も削除する。
【０１８２】
このように、本実施形態は、コンテンツ選択画面でユーザに表示するか否かを示すＶｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅを用いる構成であるので、ファイルの参照を行っていた場合でもユーザが任意のコンテンツを削除することが可能となる。すなわち、例えば他から参照されているファイルであっても、表示しないようにして、見かけ上の削除をすることができる。
【０１８３】
＜バリエーション＞
本発明の第１の実施形態から第３の実施形態までＡＶ Ｉｎｄｅｘファイルは同じ記録
媒体に記録されたファイルの管理を行っているが、別の記録媒体、例えばネットワーク越の別の記録媒体上のファイルであっても構わないことは言うまでもない。
【０１８４】
また、上述の実施形態においては、記録媒体としての光ディスク１０６について説明したが、これに限るものではなく、例えばハードディスク、光磁気ディスクのような、ランダムアクセス可能な記録媒体であってもよい。
【０１８５】
また、ファイルシステムとしてＵＤＦを例にとり、またファイルフォーマットとしてＱｕｉｃｋＴｉｍｅファイルフォーマットを例にした説明をしているが、本発明はこれに限
るものではなく、その他のファイルシステム、ファイルフォーマットであっても同様に適用できる。
【０１８６】
また、ＱｕｉｃｋＴｉｍｅファイルフォーマットを管理するためのＡＶ Ｉｎｄｅｘフ
ァイルを用いてファイルを管理する例について説明したが、本発明はこれに限るものではなく、その他のファイル、テーブルなどを用いて管理する構成であってもよい。
【０１８７】
以上のように、上述の実施の形態においては、記録装置としてのディジタル記録再生装置は、ファイル管理部としてのホストＣＰＵ１０１が、光ディスク１０６に、データが分割記録されたかどうかの情報を記録する。
【０１８８】
したがって、分割記録されたかどうかに応じて適切な表示、削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。
【０１８９】
すなわち、分割記録された場合の分割データとこの分割データを参照する統括データとについて、分割データを表示しないようにする。
【０１９０】
ここで、この分割データは、ファイルシステムにおいてファイルサイズの上限が存在するために、例えばこの上限を超えるサイズのファイルを分割して生成されるものである。上述のように、分割データを表示しないようにすれば、ユーザに混乱を与えることがない。
【０１９１】
また、統括データを削除しようとするときには、統括データが参照している分割データが、その統括データのみから参照されている場合には、統括データとともに参照している分割データをも削除するようにする。
【０１９２】
したがって、分割データがある場合であっても、ユーザに分割データの存在を意識させることなく、削除することができる。なお、データを削除する場合には、他のファイルから参照されていないときに削除が可能である。
【０１９３】
また、記録装置としてのディジタル記録再生装置は、ファイル管理部としてのホストＣＰＵ１０１が、光ディスク１０６に、データが初期記録データか否かに関する情報を記録する。
【０１９４】
したがって、初期記録データか否かに応じて適切な表示、削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。
【０１９５】
すなわち、複数のデータのうち、分割記録された場合の分割データとこの分割データを参照する統括データとがある場合に、そのデータが統括データであるか否かを、初期記録データか否かに関する情報を用いて判別できる。したがって、ファイルの生成時間などを参照する必要がないので、記録装置の内蔵時計が正確でない場合であっても、判別を確実にできる。
【０１９６】
また、記録装置としてのディジタル記録再生装置は、ファイル管理部としてのホストＣＰＵ１０１が、光ディスク１０６に、データの存在をユーザに見せるかどうかを管理する情報を記録する。
【０１９７】
したがって、データの存在をユーザに見せるかどうかを管理する情報に応じて、適切な表示、見かけ上の削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。
【０１９８】
すなわち、例えば分割データであるか否かとは別に、データの存在をユーザに見せるかどうかを管理する情報に応じて表示を行うので、ユーザに混乱を与えることがない表示が可能となるとともに、見かけ上の削除が可能となる。
【０１９９】
また、光ディスク１０６には、上述のようにデータが初期記録データか否かに関する情報が記録される。
【０２００】
したがって、上述のディジタル記録再生装置のような記録装置と組合せて用いられて、初期記録データか否かに応じて適切な表示、削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。
【０２０１】
また、光ディスク１０６には、上述のようにデータの存在をユーザに見せるかどうかを管理する情報が記録される。
【０２０２】
したがって、上述のディジタル記録再生装置のような記録装置と組合せて用いられて、データの存在をユーザに見せるかどうかを管理する情報に応じて適切な表示、見かけ上の削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。
【０２０３】
また、記録装置としてのディジタル記録再生装置は、コンピュータによって実現されるものであってもよい。すなわち、上述したデータ記録方法、データ削除方法のいずれかを実行するプログラムがコンピュータにて読取られ、実行されて、上述のディジタル記録再生装置が実現されてもよい。
【０２０４】
また、以上に説明したデータ記録方法、データ削除方法は、例えば、ファイルシステムにおけるファイル管理情報を用いてデータの管理を行うファイル管理方法である、ということもできる。そして、ファイルのうちに、分割ファイルとこの分割ファイルを参照する統括ファイルとが含まれている場合に、ファイル管理方法のファイル管理情報に、ファイルが分割ファイルであるか否かを示すフラグを含ませる。そして、この分割ファイルであるか否かを示すフラグと、あるファイルが他の何個のファイルから参照されているかを示す数と、ファイルの作成時間とから、ファイルが統括ファイルであるか否かを判別できる。
【０２０５】
また、上述の構成を、例えば、複数のデータを一括して管理するテーブルを持つ記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、前記削除の際に、登録されているエントリがオリジナルか否かを判断するステップを有することを特徴とするデータ削除方法である、と表現することもできる。
【０２０６】
また、上述の構成を、例えば、前記構成において、前記登録されているエントリがオリジナルか否かを判断するステップが、自動分割されたかどうかの情報および参照情報および作成時間に基づくことを特徴とするデータ削除方法である、と表現することもできる。
【０２０７】
また、上述の構成を、例えば、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録するデータ記録方法であって、前記複数のデータに対応するエントリにオリジナルか否かを判断することが可能な情報を記録することを特徴とするデータ記録方法である、と表現することもできる。
【０２０８】
また、上述の構成を、例えば、複数のデータをそれぞれエントリとして一括管理するテーブルを持ち、前記データに対応するエントリにオリジナルか否かを管理する情報が記録してある記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削
除方法であって、削除時に、削除対象のデータが前記オリジナルか否かを管理する情報を基に削除可能かどうかを判断するステップを有することを特徴とするデータ削除方法である、と表現することもできる。
【０２０９】
また、上述の構成を、例えば、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録するデータ記録方法であって、前記データに対応するエントリにそのデータの存在をユーザに見せるかどうかを管理する情報を記録することを特徴とするデータ記録方法である、と表現することもできる。
【０２１０】
また、上述の構成を、例えば、複数のデータをそれぞれエントリとして一括管理するテーブルを持ち、前記データに対応するエントリにそのデータの存在をユーザに見せるかどうかを管理する情報が記録してある記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、削除対象データが他のデータから参照されていた場合、前記データの存在をユーザに見せるかどうかを管理する情報を書き換えることを特徴とするデータ削除方法である、と表現することもできる。
【０２１１】
以上説明したように、本発明によれば、ディスク上の各ファイルが自動分割ムービーファイルかどうかを区別する情報とオリジナルかどうかを区別する情報に基づくことで、自動分割ムービーファイルがある場合でもユーザに違和感を与えず削除を実行することができる。
【０２１２】
また、本発明によれば、オリジナルかどうかを管理する情報をディスク上に格納することで、自動分割ムービーファイルがある場合でもユーザに違和感を与えず確実に削除を行うことができる。
【０２１３】
さらに、本発明によれば、エントリに対応するＡＶファイルに関して、ユーザに見せるか見せないかを区別するための情報をディスク上に格納することで、ファイルの参照を行っていた場合でもユーザが任意のコンテンツを見かけ上削除することが可能となる。
【０２１４】
ここで、例えば、図３６に示すように、インデックスファイル２１００の各エントリ毎に自動分割ムービーであるか否かを管理するフラグａｕｔｏ−ｄｉｖｉｄｅｄをつけ、自動分割ムービーであるファイル２２０１〜２２０３については、ＹＥＳをセットし、コンテンツ選択画面には、ａｕｔｏ−ｄｉｖｉｄｅｄがＮＯのエントリの縮小画像のみ、すなわちファイル２２０４の縮小画像のみ表示する、という方法も考えられる。しかしながら、この構成においては、削除等の管理をどのようにするかは明らかではない。
【０２１５】
発明を実施するための最良の形態の項においてなした具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と請求の範囲に記載した事項の範囲内で、いろいろと変更して実施することができるものである。
【０２１６】
また、請求の範囲に記載した事項や、発明を実施するための最良の形態に記載した技術的手段は、適宜組み合わせることができ、この組み合わせによって得られる事項も本発明の技術的範囲に含まれる。
【産業上の利用可能性】
【０２１７】
本発明のデータ記録方法、データ削除方法、データ表示方法、記録装置、記録媒体およびプログラムによれば、インデックスファイルにおいて、管理している各ファイルに関して、ユーザに見せる又は隠す、オリジナルか又は非破壊編集済みかを区別する情報を管理し、それらの情報に基づき削除処理や一覧表示処理を行う。したがって、ユーザに混乱を
与えずに、参照ムービーをインデックスファイルで管理できる。
【図１】
2010140633.tif 000003
【図２（ａ）】
2010140633.tif 000004
【図２（ｂ）】
2010140633.tif 000005
【図２（ｃ）】
2010140633.tif 000006
【図３】
2010140633.tif 000007
【図４】
2010140633.tif 000008
【図５】
2010140633.tif 000009
【図６】
2010140633.tif 000010
【図７】
2010140633.tif 000011
【図８】
2010140633.tif 000012
【図９】
2010140633.tif 000013
【図１０】
2010140633.tif 000014
【図１１（ａ）】
2010140633.tif 000015
【図１１（ｂ）】
2010140633.tif 000016
【図１１（ｃ）】
2010140633.tif 000017
【図１２】
2010140633.tif 000018
【図１３】
2010140633.tif 000019
【図１４】
2010140633.tif 000020
【図１５】
2010140633.tif 000021
【図１６】
2010140633.tif 000022
【図１７】
2010140633.tif 000023
【図１８】
2010140633.tif 000024
【図１９】
2010140633.tif 000025
【図２０】
2010140633.tif 000026
【図２１】
2010140633.tif 000027
【図２２】
2010140633.tif 000028
【図２３】
2010140633.tif 000029
【図２４】
2010140633.tif 000030
【図２５】
2010140633.tif 000031
【図２６】
2010140633.tif 000032
【図２７】
2010140633.tif 000033
【図２８】
2010140633.tif 000034
【図２９】
2010140633.tif 000035
【図３０】
2010140633.tif 000036
【図３１】
2010140633.tif 000037
【図３２】
2010140633.tif 000038
【図３３】
2010140633.tif 000039
【図３４】
2010140633.tif 000040
【図３５】
2010140633.tif 000041
【図３６】
2010140633.tif 000042