JP5386384B2 - データ記録方法、データ削除方法、記録装置、記録媒体およびプログラム - Google Patents

Description

本発明は、ハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して、映像データ、音声データを記録・削除するデータ記録方法、データ削除方法、データ表示方法、記録装置、記録媒体およびプログラムに関するものである。

ディスクメディアを用いたビデオのディジタル記録再生装置（以下、ビデオディスクレコーダと呼ぶ）が普及しつつある。その記録フォーマットには、ＰＣ（パーソナル・コンピュータ）との親和性を高めるため、ＰＣで広く使われている、例えばＱｕｉｃｋＴｉｍｅ（登録商標）ファイルフォーマットやＡＶＩ（ＡｕｄｉｏＶｉｄｅｏ Ｉｎｔｅｒｌｅａｖｅ）ファイルフォーマットを用いることがよく行われる。

このようなＰＣ用ファイルフォーマットを用いた場合のディスク中でのコンテンツの管理方法については、特許文献１に開示されている。以下、図３３を用いてその概要を説明する。ディスク２１０５中のファイル２１０１〜２１０３は、録画した各シーンあるいはショットに対応しそれぞれ１個のＱｕｉｃｋＴｉｍｅファイル（以下、ＱｕｉｃｋＴｉｍｅムービーファイルと呼ぶ）である。

インデックスファイル２１００は、ディスク２１０５中のデータの目次的な情報を格納するファイルである。各ＱｕｉｃｋＴｉｍｅムービーファイル毎にエントリが存在する。各エントリには、対応するシーンの代表画面の縮小画像（サムネイル画像）データ２１１１〜２１１３と、そのシーンが含まれるファイルのファイル名とが格納される。

ユーザにインデックス画面を提示する際は、各エントリの縮小画像データ２１１１〜２１１３をデコードした縮小画像２１２１〜２１２３をコンテンツ選択画面２１０７に表示する。ユーザはコンテンツ選択画面２１０７画面に表示されている複数の縮小画像の中から再生や編集をしたいファイルを選択する。例えば、ユーザが縮小画像２１２３を選択し、再生を指示したら、縮小画像２１２３に対応するコンテンツの含まれるファイルのファイル名であるファイル２１０３を取得し、ファイル２１０３の再生を開始する。

インデックスファイル２１００には、ディスク２１０５中のすべてのコンテンツに関して、そのコンテンツを格納したファイルへのポインタと縮小画像データとが含まれる。このため、インデックスファイル２１００をディスク２１０５から読み出すだけで、コンテンツ選択画面２１０７の表示が可能であり、Ｉｎｄｅｘ画面（コンテンツ選択画面）表示に要する時間が少なくて済むという利点がある。コンテンツ選択画面２１０７は頻繁に表示するものであるため、その表示時間の削減は全体的な体感レスポンス向上に大きく寄与する。

特開２００１−８４７０５号公報（公開日：２００１年３月３０日）

しかしながら、上述の従来の構成によると、以下に説明するように参照ムービーを管理する際にユーザに混乱を与えてしまう虞れがある。

ここで、ＰＣ用のファイルフォーマットを用いる際に問題となるのは、大容量ビデオデータの扱いである。前述のＱｕｉｃｋＴｉｍｅファイルフォーマットやＡＶＩファイルフォーマットでは３２ｂｉｔの情報でアドレスを管理しているため、ファイルサイズの上限は２の３２乗、すなわち約４ＧＢ（バイト）となる。ビットレート１０Ｍｂｐｓのビデオデータを記録した場合、記録時間は６０分弱となり、テレビ番組等の録画には不十分である。

このような問題を解消するため、図３４に示すような参照ムービーと呼ばれる方法が用いられている。以下、参照ムービーについて説明する。まず、作成は次の（１）から（４）の手順で行う。（１）録画開始した時点でファイル２２０１にデータを記録していく。（２）ファイル２２０１がファイルサイズの上限に近づいたら、ファイル２２０１への記録をやめ、続きのファイル２２０２に記録していく。（３）ファイル２２０２のファイルサイズが上限に近づいたら同様にファイル２２０３に記録を行う。（４）録画が終了した時点で、ファイル２２０４に管理情報を作成する。

再生時はファイル２２０４を指定し、そこに記録されている管理情報を基に、順にファイル２２０１〜２２０３を再生することが可能である。また、ファイル２２０４が削除された場合でも再生が可能なように、ファイル２２０１〜２２０３にも前記管理情報が付加されている。ここでは、ファイル２２０１〜２２０３を自動分割ムービーファイル、ファイル２２０４を統括ムービーファイルと呼ぶことにする。

このような参照ムービー（自動分割ムービー、統括ムービー）を、前述のインデックスファイルを用いた方法で管理すると次のような問題が生じる。図３５を用いてそれを説明する。前記のファイル２２０１〜２２０４をそれぞれの代表画面の縮小画像データとともにインデックスファイル２１００に登録すると仮定する。このとき、コンテンツ選択画面２１０７には、ファイル２２０１〜２２０４に対応する代表画面２２２１〜２２２４が表示されることになり、ユーザは違和感を抱くことになる。なぜなら、ユーザが撮影したシーンは１個であるのにもかかわらず、４個の代表画面が表示されるからである。

また、参照ムービーを削除する際にも、１個のシーンについて４個の代表画面が表示されているため、削除をどのようにするか明らかでない。

本発明は、上記課題を鑑みてなされたものであり、ユーザに混乱を与えない形で参照ムービーをインデックスファイルで管理することが可能なデータ記録方法、データ削除方法、データ表示方法、記録装置、記録媒体およびプログラムを提供することを目的とする。

本発明に係るデータ削除方法は、前記目的を達成すべく、少なくとも複数の分割データと前記分割データを参照する統括データとを含む複数のデータを一括して管理するテーブルを持つ記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、前記削除の際に、登録されているエントリに対応するデータが初期記録データか否かを判断するステップを有することを特徴とする。

また、本発明に係るデータ削除方法は、前記目的を達成すべく、前記構成において、前記登録されているエントリに対応するデータが初期記録データか否かを判断するステップが、前記エントリの管理するデータが分割記録されたかどうかの情報および他のエントリが管理するデータとの関連情報および作成時間に基づくことを特徴とする。

本発明に係るデータ記録方法は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録するデータ記録方法であって、前記エントリにそのエントリが管理するデータが初期記録データか否かに関する情報を記録することを特徴とする。

本発明に係るデータ記録方法は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録するデータ記録方法であって、前記エントリにそのエントリが管理するデータの存在をユーザに見せるかどうかを管理する情報を記録することを特徴とする。

本発明に係るデータ記録方法は、前記目的を達成すべく、前記構成において、前記複数のデータは、少なくとも複数の分割データと前記分割データを参照する統括データとを含むことを特徴とする。

本発明に係るデータ記録方法は、前記目的を達成すべく、前記構成において、前記エントリに他のエントリが管理するデータとの関連情報を記録することを特徴とする。

本発明に係るデータ記録方法は、前記目的を達成すべく、前記構成において、前記テーブルをファイルに格納することを特徴とする。

本発明に係るデータ削除方法は、前記目的を達成すべく、少なくとも複数の分割データと前記分割データを参照する統括データとを含む複数のデータをそれぞれエントリとして一括管理するテーブルを持つ記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、前記記録媒体には、前記データに対応するエントリに初期記録データか否かを管理する情報が記録してあり、前記削除の際に、削除対象のデータが前記初期記録データか否かに関する情報および他のエントリが管理するデータとの関連情報を基に削除可能かどうかを判断するステップを有することを特徴とする。

本発明に係るデータ削除方法は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを持つ記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、前記記録媒体には、前記データを管理するエントリにそのデータの存在をユーザに見せるかどうかを管理する情報および他のエントリが管理するデータとの関連情報が記録してあり、前記削除の際に、前記関連情報に基づき前記データの存在をユーザに見せるかどうかを管理する情報を変更するステップを有することを特徴とする。

本発明に係るデータ表示方法は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを持つ記録媒体から、前記テーブルを読み出して表示するデータ表示方法であって、前記記録媒体には、前記データを管理するエントリにそのデータの存在をユーザに見せるかどうかを管理する情報が記録してあり、前記データの存在をユーザに見せるかどうかを管理する情報に基づいて表示を制御することを特徴とする。

本発明に係る記録装置は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録する記録装置であって、前記エントリにそのエントリが管理するデータが初期記録データか否かに関する情報を記録する手段を備えることを特徴とする。

本発明に係る記録装置は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録する記録装置であって、前記エントリにそのエントリが管理するデータの存在をユーザに見せるかどうかを管理する情報を記録する手段を備えることを特徴とする。

本発明に係る記録媒体は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録した記録媒体であって、前記エントリにそのエントリが管理するデータが初期記録データか否かに関する情報を記録してあることを特徴とする。

本発明に係る記録媒体は、前記目的を達成すべく、複数のデータをそれぞれエントリとして一括管理するテーブルを記録した記録媒体であって、前記エントリにそのエントリが管理するデータの存在をユーザに見せるかどうかを管理する情報を記録してあることを特徴とする。

本発明に係るプログラムは、前記目的を達成すべく、上述のいずれかのデータ削除方法、または上述のいずれかのデータ記録方法を、コンピュータに実行させるプログラムである。

また、本発明に係る記録媒体は、上述のプログラムを記録したコンピュータ読み取り可能な記録媒体である。

本発明によれば、ディスク上の各ファイルが自動分割ムービーファイルかどうかを区別する情報とオリジナルかどうかを区別する情報に基づくことで、自動分割ムービーファイルがある場合でもユーザに違和感を与えず削除を実行することができる。

また、本発明によれば、オリジナルかどうかを管理する情報をディスク上に格納することで、自動分割ムービーファイルがある場合でもユーザに違和感を与えず確実に削除を行うことができる。

さらに、本発明によれば、エントリに対応するＡＶファイルに関して、ユーザに見せるか見せないかを区別するための情報をディスク上に格納することで、ファイルの参照を行っていた場合でもユーザが任意のコンテンツを見かけ上削除することが可能となる。

本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分わかるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。

本発明の実施形態におけるディジタル記録再生装置の概略構成を示すブロック図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける管理情報とＡＶストリームとの関係の一例を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける管理情報とＡＶストリームとの関係の他の一例を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける管理情報とＡＶストリームとの関係のさらに他の一例を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｏｖｉｅ ａｔｏｍの概要を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ａｔｏｍの概要を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＴｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおける Ｍｅｄｉａ ａｔｏｍの構成を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＭｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎａｔｏｍの構成を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＳａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構成を示す説明図である。 Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍによるデータ管理の例を示す説明図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＥｄｉｔ ａｔｏｍの構成を示す説明図である。 Ｅｄｉｔ ｌｉｓｔ ａｔｏｍの内容を示す図である。 サンプルの一例の構成を示す図である。 サンプルの再生の順を示す図である。 ＱｕｉｃｋＴｉｍｅファイルフォーマットにおけるＵｓｅｒ ｄａｔａ ａｔｏｍの構成を示す説明図である。 ＡＶストリームの構成を示す説明図である。 Ｖｉｄｅｏ Ｕｎｉｔ（ＶＵ）の構造を示す説明図である。 ＱｕｉｃｋＴｉｍｅによるＡＶストリーム管理形態を示す説明図である。 リファレンス・デバイス・モデルを示す説明図である。 ＡＶ Ｉｎｄｅｘファイルの構成を示す説明図である。 属性情報の構成を示す説明図である。 本発明の第１の実施形態におけるｐｅ−ｆｌａｇｓの構成を示す説明図である。 記録動作を示すフローチャートである。 本発明の第１の実施形態における、記録後の属性情報を示す説明図である。 本発明の第１の実施形態における、非破壊編集後の属性情報を示す説明図である。 本発明の第１の実施形態における、削除可能性の判定動作を示すフローチャートである。 本発明の第１の実施形態における、オリジナルか非破壊編集結果かを判定する動作を示すフローチャートである。 本発明の第２の実施形態におけるｐｅ−ｆｌａｇｓの構成を示す説明図である。 本発明の第２の実施形態における、記録後の属性情報を示す説明図である。 本発明の第２の実施形態における、非破壊編集後の属性情報を示す説明図である。 本発明の第３の実施形態におけるｐｅ−ｆｌａｇｓの構成を示す説明図である。 本発明の第３の実施形態における、記録後の属性情報を示す説明図である。 本発明の第３の実施形態における、非破壊編集後の属性情報を示す説明図である。 本発明の第３の実施形態における、アフレコ後の属性情報を示す説明図である。 本発明の第３の実施形態における、削除動作を示すフローチャートである。 従来技術におけるインデックスファイルを示す説明図である。 従来技術における参照ムービーの概念を示す説明図である。 従来技術における、参照ムービーを管理するインデックスファイルを示す説明図である。 従来技術における、参照ムービーを管理するインデックスファイルの改良例を示す説明図である。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行っていく。

＜システム構成＞
図１は本発明において共通に用いる、ディスクメディアを用いたビデオのディジタル記録再生装置（ビデオディスクレコーダ）の構成図である。この装置は、図１に示すように、バス１００、ホストＣＰＵ１０１、ＲＡＭ１０２、ＲＯＭ１０３、ユーザインタフェース１０４、システムクロック１０５、光ディスク１０６、ピックアップ１０７、ＥＣＣ（ＥｒｒｏｒＣｏｒｒｅｃｔｉｎｇ Ｃｏｄｉｎｇ）デコーダ１０８、ＥＣＣエンコーダ１０９、再生用バッファ１１０、記録／アフレコ用バッファ１１１、デマルチプレクサ１１２、マルチプレクサ１１３、多重化用バッファ１１４、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８、および図示しないカメラ、マイク、スピーカ、ディスプレイ等で構成される。なお、アフレコとはアフター・レコーディングの略であり、初期記録したビデオデータに対して後からオーディオデータを追加記録する機能を指す。

ホストＣＰＵ１０１は、バス１００を通じてデマルチプレクサ１１２、マルチプレクサ１１３、ピックアップ１０７、また図示していないが、オーディオデコーダ１１５、ビデオデコーダ１１６、オーディオエンコーダ１１７、ビデオエンコーダ１１８の制御を行う。

再生時には、光ディスク１０６からピックアップ１０７を通じて読み出されたデータは、ＥＣＣデコーダ１０８によって誤り訂正され、再生用バッファ１１０に一旦蓄えられる。ホストＣＰＵ１０１は、再生中のデータに関する管理情報に基づき、オーディオデコーダ１１５、ビデオデコーダ１１６からのデータ送信要求に従い、再生用バッファ１１０中のデータをその種別によって適当なデコーダに振り分けるようデマルチプレクサ１１２に指示を与える。

一方、記録時には、オーディオエンコーダ１１７とビデオエンコーダ１１８によって圧縮符号化されたデータは、多重化用バッファ１１４に一旦送られ、マルチプレクサ１１３によってＡＶ多重化され、記録／アフレコ用バッファ１１１に送られる。記録／アフレコ用バッファ１１１中のデータは、ＥＣＣエンコーダ１０９によって誤り訂正符号を付加され、ピックアップ１０７を通じて光ディスク１０６に記録される。

オーディオデータの符号化方式にはＭＰＥＧ−１ Ｌａｙｅｒ−ＩＩを、ビデオデータの符号化方式にはＭＰＥＧ−２をそれぞれ用いる。

光ディスク１０６は、外周から内周に向かって螺旋状に記録再生が行われる脱着可能な光ディスクとする。２０４８ｂｙｔｅを１セクタとし、誤り訂正のため１６セクタでＥＣＣブロックを構成する。ＥＣＣブロック中のデータを書き換える場合、そのデータが含まれるＥＣＣブロック全体を読み込み、誤り訂正を行って、対象のデータを書き換え、再び誤り訂正符号を付加し、ＥＣＣブロックを構成して、記録媒体に記録する必要がある。また、光ディスク１０６は、記録効率を上げるためＺＣＡＶ（ゾーン角速度一定）を採用しており、記録領域は回転数の異なる複数のゾーンで構成される。

＜ファイルシステム＞
光ディスク１０６上の各種情報を管理するためにファイルシステムを用いる。ファイルシステムには、ＰＣ（パーソナルコンピュータ）との相互運用を考慮してＵＤＦ（ＵｎｉｖｅｒｓａｌＤｉｓｋ Ｆｏｒｍａｔ）を使用する。ファイルシステム上では、各種管理情報やＡＶストリームはファイルとして扱われる。

上記構成のビデオディスクレコーダにおいては、ホストＣＰＵ１０１が、ファイルシステムを用いて、光ディスク１０６への記録、または光ディスク１０６からの再生を行うようになっている。すなわち、ホストＣＰＵ１０１が、ファイルシステムにおけるファイル管理情報を用いてデータの記録、再生、削除などを行うファイル管理部として機能する。また、ファイルの属性情報などのファイルについての情報も、ホストＣＰＵ１０１が管理して、光ディスク１０６に記録を行い、または光ディスク１０６から読み取りを行うようになっている。

ユーザエリアは、２０４８ｂｙｔｅの論理ブロック（セクタと一対一対応）で管理される。各ファイルは、整数個のエクステント（連続した論理ブロック）で構成され、エクステント単位で分散して記録しても良い。空き領域は、ＳｐａｃｅＢｉｔｍａｐを用いて論理ブロック単位で管理される。

＜ファイルフォーマット＞
ＡＶストリーム管理のためのフォーマットとして、ＱｕｉｃｋＴｉｍｅファイルフォーマットを用いる。ＱｕｉｃｋＴｉｍｅファイルフォーマットとは、Ａｐｐｌｅ社が開発したマルチメディアデータ管理用フォーマットであり、ＰＣの世界で広く用いられている。

ＱｕｉｃｋＴｉｍｅファイルフォーマットは、ビデオデータやオーディオデータ等（これらを総称してメディアデータ、ＡＶストリームとも呼ぶ）と管理情報とで構成される。両者を合わせてここでは、ＱｕｉｃｋＴｉｍｅムービー（略してムービー）と呼ぶ。両者は同じファイル中に存在しても、別々のファイルに存在しても良い。

同じファイル中に存在する場合は、図２（ａ）に示すような構成をとる。各種情報はａｔｏｍという共通の構造に格納される。管理情報はＭｏｖｉｅａｔｏｍという構造に格納され、メディアデータはＭｏｖｉｅ ｄａｔａ ａｔｏｍという構造に格納される。尚、Ｍｏｖｉｅ ａｔｏｍ中の管理情報には、メディアデータ中の任意の時間に対応するメディアデータのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。すなわち、Ｍｏｖｉｅａｔｏｍ中の管理情報には、例えば複数のデータをエントリとして一括管理するためのテーブルが含まれている。

一方、管理情報とメディアデータを別々のファイルに格納した場合は、図２（ｂ）に示すような構成をとる。管理情報はＭｏｖｉｅ ａｔｏｍという構造に格納されるが、メディアデータはａｔｏｍには格納される必要はない。このとき、Ｍｏｖｉｅ ａｔｏｍはメディアデータを格納したファイルを「外部参照」している、という。

外部参照は、図２（ｃ）に示すように、複数のＡＶストリームファイルに対して行うことが可能であり、この仕組みにより、ＡＶストリーム自体を物理的に移動することなく、見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」「非破壊編集」が可能になる。

それでは、図３乃至図１２を用いて、ＱｕｉｃｋＴｉｍｅの管理情報のフォーマットについて説明する。まず、共通の情報格納フォーマットであるａｔｏｍについて説明する。ａｔｏｍの先頭には、そのａｔｏｍのサイズであるＡｔｏｍｓｉｚｅ、そのａｔｏｍの種別情報であるＴｙｐｅが必ず存在する。Ｔｙｐｅは４文字で区別され、例えばＭｏｖｉｅ ａｔｏｍでは’ｍｏｏｖ’、Ｍｏｖｉｅ ｄａｔａ ａｔｏｍでは’ｍｄａｔ’となっている。

各ａｔｏｍは別のａｔｏｍを含むことができる。すなわち、ａｔｏｍ間には階層構造がある。Ｍｏｖｉｅ ａｔｏｍの構成を図３に示す。Ｍｏｖｉｅ ｈｅａｄｅｒ ａｔｏｍは、そのＭｏｖｉｅ ａｔｏｍが管理するムービーの全体的な属性を管理する。Ｔｒａｃｋ ａｔｏｍは、そのムービーに含まれるビデオやオーディオ等のトラックに関する情報を格納する。Ｕｓｅｒ ｄａｔａ ａｔｏｍは、独自に定義可能なａｔｏｍである。

Ｔｒａｃｋ ａｔｏｍの構成を図４に示す。Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍは、そのトラックの全体的な属性を管理する。Ｅｄｉｔ ａｔｏｍは、メディアデータのどの区間を、ムービーのどのタイミングで再生するかを管理する。Ｔｒａｃｋ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、別のトラックとの関係を管理する。Ｍｅｄｉａ ａｔｏｍは、実際のビデオやオーディオといったデータを管理する。

Ｔｒａｃｋ ｈｅａｄｅｒ ａｔｏｍの構成を図５に示す。ここでは、後での説明に必要なもののみについて説明する。Ｆｌａｇｓは属性を示すフラグの集合である。代表的なものとして、Ｔｒａｃｋｅｎａｂｌｅｄフラグがあり、このフラグが１であれば、そのトラックは再生され、０であれば再生されない。Ｌａｙｅｒはそのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、Ｌａｙｅｒの値が小さいトラックほど画像が前面に表示される。Ｅｄｉｔａｔｏｍについては後述する。

Ｍｅｄｉａ ａｔｏｍの構成を図６に示す。Ｍｅｄｉａ ｈｅａｄｅｒ ａｔｏｍは、そのＭｅｄｉａ ａｔｏｍの管理するメディアデータに関する全体的な属性等を管理する。Ｈａｎｄｌｅｒ ｒｅｆｅｒｅｎｃｅ ａｔｏｍは、メディアデータをどのデコーダでデコードするかを示す情報を格納する。Ｍｅｄｉａｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍは、ビデオやオーディオ等メディア固有の属性情報を管理する。

Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎ ａｔｏｍの構成を図７に示す。Ｍｅｄｉａ ｉｎｆｏｒｍａｔｉｏｎｈｅａｄｅｒ ａｔｏｍは、ビデオやオーディオ等メディア固有の属性情報を管理する。Ｈａｎｄｌｅｒｒｅｆｅｒｅｎｃｅ ａｔｏｍは、Ｍｅｄｉａ ａｔｏｍの項で説明した通りである。Ｄａｔａ ｉｎｆｏｒｍａｔｉｏｎａｔｏｍは、そのＱｕｉｃｋＴｉｍｅムービーが参照するメディアデータを含むファイルの名前を管理するａｔｏｍであるＤａｔａ ｒｅｆｅｒｅｎｃｅ ａｔｏｍを含む。Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍは、データのサイズや再生時間等を管理している。

次に、Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍについて図８に基づいて説明する。ここで、まずＱｕｉｃｋＴｉｍｅにおけるデータの管理方法について、図９を用いて説明する。ＱｕｉｃｋＴｉｍｅでは、データの最小単位（例えばビデオフレーム）をサンプルと呼ぶ。個々のトラック毎に、サンプルには再生時間順に１から番号（サンプル番号）がついている。

また、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のサンプルの再生時間長およびデータサイズを管理している。また、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンクと呼ぶ。チャンクにも再生時間順に、１から番号がついている。

さらに、ＱｕｉｃｋＴｉｍｅフォーマットでは、個々のチャンクのファイル先頭からのアドレスおよび個々のチャンクが含むサンプル数を管理している。これらの情報に基づき、任意の時間に対応するサンプルの位置を求めることが可能となっている。

Ｓａｍｐｌｅ ｔａｂｌｅ ａｔｏｍの構成を図８に示す。Ｓａｍｐｌｅｄｅｓｃｒｉｐｔｉｏｎ ａｔｏｍは、個々のチャンクのデータフォーマット（Ｄａｔａ ｆｏｒｍａｔ）やサンプルが格納されているファイルのチャンクのＩｎｄｅｘ等を管理する。Ｔｉｍｅ−ｔｏ−ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルの再生時間を管理する。

Ｓｙｎｃ ｓａｍｐｌｅ ａｔｏｍは、個々のサンプルのうち、デコード開始可能なサンプルを管理する。Ｓａｍｐｌｅ−ｔｏ−ｃｈｕｎｋａｔｏｍは、個々のチャンクに含まれるサンプル数を管理する。Ｓａｍｐｌｅ ｓｉｚｅａｔｏｍは、個々のサンプルのサイズを管理する。Ｃｈｕｎｋ ｏｆｆｓｅｔ ａｔｏｍは、個々のチャンクのファイル先頭からのアドレスを管理する。

ここで、Ｅｄｉｔ ａｔｏｍについて説明する。Ｅｄｉｔ ａｔｏｍは、図１０に示すように、１個のＥｄｉｔ ｌｉｓｔ ａｔｏｍを含む。Ｅｄｉｔ ｌｉｓｔ ａｔｏｍはＮｕｍｂｅｒｏｆ ｅｎｔｒｉｅｓで指定される個数分の、Ｔｒａｃｋ ｄｕｒａｔｉｏｎ、Ｍｅｄｉａ ｔｉｍｅ、Ｍｅｄｉａ ｒａｔｅの値の組（エントリ）を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでいる。

Ｔｒａｃｋ ｄｕｒａｔｉｏｎはそのエントリが管理する区間のトラック上での再生時間、Ｍｅｄｉａｔｉｍｅはそのエントリが管理する区間の先頭に対応するメディアデータ上での位置、Ｍｅｄｉａ ｒａｔｅはそのエントリが管理する区間の再生スピードを表す。尚、Ｍｅｄｉａ ｔｉｍｅが−１の場合は、そのエントリのＴｒａｃｋｄｕｒａｔｉｏｎ分、そのトラックでのサンプルの再生を停止する。この区間のことをｅｍｐｔｙ ｅｄｉｔと呼ぶ。

このように、ＱｕｉｃｋＴｉｍｅファイルフォーマットにおいては、管理情報を格納するＭｏｖｉｅ ａｔｏｍに含まれるＴｒａｃｋ ａｔｏｍのうちの、Ｅｄｉｔ ａｔｏｍに、複数のデータをエントリとして一括管理するためのＥｄｉｔ ｌｉｓｔａｔｏｍが含まれている。

図１１にＥｄｉｔ ｌｉｓｔの使用例を示す。図１１（ａ）（ｂ）（ｃ）は、Ｅｄｉｔ ａｔｏｍによる再生範囲指定の例を示す説明図である。ここでは、Ｅｄｉｔ ｌｉｓｔａｔｏｍの内容が図１１（ａ）に示す内容であり、さらにサンプルの構成が図１１（ｂ）であったとする。尚、ここではｉ番目のエントリのＴｒａｃｋｄｕｒａｔｉｏｎをＤ（ｉ）、Ｍｅｄｉａ ｔｉｍｅをＴ（ｉ）、ＭｅｄｉａｒａｔｅをＲ（ｉ）とする。このとき、実際のサンプルの再生は、図１１（ｃ）に示す順に行われる。このことについて簡単に説明する。

まず、エントリ＃１はＴｒａｃｋ ｄｕｒａｔｉｏｎが１３０００、Ｍｅｄｉａ ｔｉｍｅが２００００、Ｍｅｄｉａ ｒａｔｅが１であるため、そのトラックの先頭から１３０００の区間はサンプル中の時刻２００００から３３０００の区間を再生する。次に、エントリ＃２はＴｒａｃｋｄｕｒａｔｉｏｎが５０００、Ｍｅｄｉａ ｔｉｍｅが−１であるため、トラック中の時刻１３０００から１８０００の区間、何も再生を行わない。

最後に、エントリ＃３はＴｒａｃｋ ｄｕｒａｔｉｏｎが１００００、Ｍｅｄｉａ ｔｉｍｅが０、Ｍｅｄｉａ ｒａｔｅが１であるため、トラック中の時刻１８０００から２８０００の区間において、サンプル中の時刻０から１００００の区間を再生する。

図１２にＵｓｅｒ ｄａｔａ ａｔｏｍの構成を示す。このａｔｏｍには、ＱｕｉｃｋＴｉｍｅフォーマットで定義されてない独自の情報を任意個数格納することができる。１個の独自情報は１個のエントリで管理され、１個のエントリはＳｉｚｅとＴｙｐｅとＵｓｅｒｄａｔａで構成される。Ｓｉｚｅはそのエントリ自体のサイズを表し、Ｔｙｐｅは独自情報をそれぞれ区別するための識別情報、Ｕｓｅｒ ｄａｔａは実際のデータを表す。

＜ＡＶストリームの形態＞
本発明において共通に用いられるＡＶストリームの構成について、図１３及び図１４を用いて説明する。ＡＶストリームは整数個のＲｅｃｏｒｄＵｎｉｔ（ＲＵ）で構成される。ＲＵはディスク上で連続的に記録する単位である。ＲＵの長さは、ＡＶストリームを構成するＲＵをどのようにディスク上に配置してもシームレス再生（再生中に画像や音声が途切れないで再生できること）やリアルタイムアフレコ（アフレコ対象のビデオをシームレス再生しながらオーディオを記録すること）が保証されるように設定される。この設定方法については後述する。

また、ＲＵ境界がＥＣＣブロック境界と一致するようにストリームを構成する。ＲＵのこれらの性質によって、ＡＶストリームをディスクに記録した後も、シームレス再生を保証したまま、ディスク上でＲＵ単位の配置を容易に変更することができる。

ＲＵは、整数個のＶｉｄｅｏ Ｕｎｉｔ（ＶＵ）で構成される。ＶＵは単独再生可能な単位であり、そのことから再生の際のエントリ・ポイントとなり得る。

ＶＵ構成を図１４に示す。ＶＵは、１秒程度のビデオデータを格納した整数個のＧＯＰ（グループ・オブ・ピクチャ）と、それらと同じ時間に再生されるメインオーディオデータを格納した整数個のＡＡＵ（オーディオ・アクセス・ユニット）とから構成される。

尚、ＧＯＰは、ＭＰＥＧ−２ビデオ規格における画像圧縮の単位であり、複数のビデオフレーム（典型的には１５フレーム程度）で構成される。ＡＡＵはＭＰＥＧ−１Ｌａｙｅｒ−ＩＩ規格における音声圧縮の単位で、１１５２点の音波形サンプル点により構成される。サンプリング周波数が４８ｋＨｚの場合、ＡＡＵあたりの再生時間は０．０２４秒となる。ＶＵ中では、ＡＶ同期再生のために必要となる遅延を小さくするため、ＡＡＵ、ＧＯＰの順に配置する。

また、ＶＵ単位で独立再生を可能とするために、ＶＵ中のビデオデータの先頭にはＳｅｑｕｅｎｃｅ Ｈｅａｄｅｒ（ＳＨ）を置く。ＶＵの再生時間は、ＶＵに含まれるビデオフレーム数にビデオフレーム周期をかけたものと定義する。さらに、ＶＵを整数個組み合わせてＲＵを構成する場合、ＲＵの始終端をＥＣＣブロック境界に合うよう、ＶＵの末尾を０で埋める。

＜ＡＶストリーム管理方法＞
ＡＶストリームの管理方法は、前述のＱｕｉｃｋＴｉｍｅファイルフォーマットをベースにしている。図１５にＡＶストリーム管理形態を示す。ビデオデータ及びオーディオデータをそれぞれビデオトラック、オーディオトラックで管理し、ビデオトラックは、１ビデオフレームを１サンプル、ＶＵ中のＧＯＰの列を１チャンクとして管理する。オーディオトラックは、ＡＡＵを１サンプル、ＶＵ中のＡＡＵの列を１チャンクとして管理する。

＜ＲＵ単位決定方法＞
次に、ＲＵ単位決定方法について説明する。この決定方法では、基準となるデバイス（リファレンス・デバイス・モデル）を想定し、その上でシームレス再生が破綻しないように連続記録単位を決める。

それではまず、リファレンス・デバイス・モデルについて、図１６を用いて説明する。リファレンス・デバイス・モデルは１個のピックアップとそれにつながるＥＣＣエンコーダ・デコーダ５０１、トラックバッファ５０２、デマルチプレクサ５０３、アフレコ用バッファ５０４、オーディオエンコーダ５０９、ビデオバッファ５０５、オーディオバッファ５０６、ビデオデコーダ５０７、オーディオデコーダ５０８とによって構成される。

本モデルにおけるシームレス再生は、ＶＵのデコード開始時にトラックバッファ５０２上に少なくとも１個ＶＵが存在すれば保証されるものとする。オーディオフレームデータのＥＣＣエンコーダ５０１へのデータの入力速度およびＥＣＣデコーダ５０１からデータの出力速度はＲｓとする。

また、アクセスによる読み出し、記録の停止する最大期間をＴａとする。さらに、短いアクセス（１００トラック程度）に要する時間をＴｋとする。なお、これら期間には、シーク時間、回転待ち時間、アクセス後に最初にディスクから読み出したデータがＥＣＣから出力されるまでの時間が含まれる。本実施例では、Ｒｓ＝２０Ｍｂｐｓ、Ｔａ＝１秒、Ｔｋ＝０．２秒とする。

前記リファレンス・デバイス・モデルにおいて再生を行った場合、次のような条件を満たせば、トラックバッファ５０２のアンダーフローがないことが保証できる。

条件を示す前にまず、記号の定義を行う。ＡＶストリームを構成するｉ番目の連続領域をＣ＃ｉとし、Ｃ＃ｉ中に含まれる再生時間をＴｃ（ｉ）とする。Ｔｃ（ｉ）はＣ＃ｉ中に先頭が含まれているＶＵの再生時間の合計とする。また、Ｃ＃ｉからＣ＃ｉ＋１へのアクセス時間をＴａとする。

また、再生時間Ｔｃ（ｉ）分のＶＵ読み出し時間をＴｒ（ｉ）とする。このとき、トラックバッファ５０２をアンダーフローさせない条件とは、分断ジャンプを含めた最大読み出し時間をＴｒ（ｉ）としたとき、任意のＣ＃ｉにおいて、
Ｔｃ（ｉ）≧Ｔｒ（ｉ）＋Ｔａ・・・＜式１＞
が成立することである。

なぜなら、この式は、シームレス再生の十分条件である、
ΣｉＴｃ（ｉ）≧Σｉ（Ｔｒ（ｉ）＋Ｔａ）
を満たす十分条件であるためである。

＜式１＞中のＴｒ（ｉ）に、Ｔｒ（ｉ）＝Ｔｃ（ｉ）×（Ｒｖ＋Ｒａ）／Ｒｓを代入して、Ｔｃ（ｉ）で解くとシームレス再生を保証可能なＴｃ（ｉ）の条件
Ｔｃ（ｉ）≧（Ｔａ×Ｒｓ）／（Ｒｓ−Ｒｖ−Ｒａ） ・・・＜式２＞
が得られる。

つまり、各連続領域に先頭の含まれるＶＵの合計が上式を満たすようにすれば、シームレス再生を保証可能である。このとき、各連続領域には合計の再生時間が上式を満たす完全なＶＵ群を含むように制限しても良い。

自動分割ムービーファイルでも＜式２＞を満たす必要がある。ただし、先頭の自動分割ムービーの最初のＲＵおよび末尾の自動分割ムービーの最後のＲＵは＜式２＞を満たさなくてもよい。なぜなら、先頭については記録媒体からのデータ読み出し開始より再生開始を遅らせることにより吸収でき、末尾については次に続くデータがないため連続再生を気にする必要が無いからである。このように先頭と末尾において条件を緩めることにより、短い空き領域を有効利用できる。

＜インデックス・ファイル＞
光ディスク１０６内に含まれるＱｕｉｃｋＴｉｍｅムービーや静止画データ等を含む各種ファイル（以後、ＡＶファイルと呼ぶ）を管理するため、ＡＶＩｎｄｅｘファイルという特別のＱｕｉｃｋＴｉｍｅムービーファイルをディスク内に１個置く。図１７に、ＡＶ Ｉｎｄｅｘファイルの構成を示す。ＡＶ Ｉｎｄｅｘファイルは通常のＱｕｉｃｋＴｉｍｅムービーファイルと同様、管理情報であるＭｏｖｉｅａｔｏｍ１７９１とデータ自体のＭｏｖｉｅ ｄａｔａ ａｔｏｍ１７９２で構成される。

ＡＶ Ｉｎｄｅｘファイルは、複数のエントリを管理する。ディスク内の各ＡＶファイルはそれぞれ１個のエントリで管理される。さらに、各ＡＶファイルをまとめるための入れ物（以後フォルダと呼ぶ）等もそれぞれ１個のエントリで管理する。本実施形態においては、ディスク（光ディスク１０６）内のファイルを、ＡＶＩｎｄｅｘファイルを用いてエントリで管理する。このように、エントリを管理するテーブルは、このＡＶ Ｉｎｄｅｘファイルに格納される。

Ｍｏｖｉｅ ａｔｏｍ１７９１は、各エントリの属性情報を管理するためのＰｒｏｐｅｒｔｙｔｒａｃｋ１７９３、各エントリのタイトル文字列データを管理するためのＴｉｔｌｅ ｔｒａｃｋ１７９４、各エントリの代表画像データを管理するためのＴｈｕｍｂｎａｉｌｔｒａｃｋ１７９５、各エントリの代表オーディオデータを管理するためのＩｎｔｒｏ ｍｕｓｉｃｔｒａｃｋ１７９６の計４種類のトラックで構成される。

各エントリに関する属性情報やタイトル文字列データ、代表画像データ、代表オーディオデータはそれぞれの１７９３〜１７９５のトラックのサンプルとして管理される。例えばＡＶファイル１７４１に関する属性情報はＰｒｏｐｅｒｔｙｔｒａｃｋ１７９３上のサンプル１７０１、タイトル文字列データはＴｉｔｌｅ ｔｒａｃｋ１７９４上のサンプル１７１１、代表画像データはＴｈｕｍｂｎａｉｌ ｔｒａｃｋ１７９５上のサンプル１７２１、代表オーディオデータはＩｎｔｒｏｍｕｓｉｃ ｔｒａｃｋ１７９６上のサンプル１７３１で管理する。サンプル間の対応付けは、各サンプルの再生開始時間に基づき行う。すなわち、トラック間で同一時刻に位置するサンプルが同一エントリに対応していると判断する。

このように、Ｍｏｖｉｅ ａｔｏｍ１７９１は、各ＡＶファイルに関する属性情報や、タイトル文字列データ、代表画像データ、代表オーディオデータを格納する。属性情報は図１８に示す構成を取る。各フィールドについて説明する。ｖｅｒｓｉｏｎは、ファイルフォーマットのバージョンを示す。ｐｅ−ｆｌａｇｓは各種フラグをまとめたものであり、詳細は後述する。

ｐａｒｅｎｔ−ｅｎｔｒｙ−ｎｕｍｂｅｒは、属性情報に対応するエントリが属するフォルダに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを格納、ｅｎｔｒｙ−ｎｕｍｂｅｒは、属性情報に対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを格納する。この２個の情報で、ファイルとフォルダの包含関係を表す。ｓｅｔ−ｄｅｐｅｎｄｅｎｔ−ｆｌａｇｓおよびｕｓｅｒ−ｐｒｉｖａｔｅ−ｆｌａｇｓについては、説明を省略する。

ｃｒｅａｔｉｏｎ−ｔｉｍｅおよびｍｏｄｉｆｉｃａｔｉｏｎ−ｔｉｍｅはこの属性情報に対応するエントリが作成された日時（作成時間）、修正された日時を表す。ｄｕｒａｔｉｏｎはこの属性情報に対応するエントリの再生時間を表す。ｂｉｎａｒｙ−ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒは、この管理情報に対応するエントリがファイルに対応していた場合、そのファイルのパス名を固定長にエンコーディングしたもので、詳細についての説明は省略する。

ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒはこの属性情報に対応するエントリが管理するファイルが他のファイルから参照されている回数を格納する。すなわち、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒは、他のエントリが管理するファイルとの関連情報に相当する。ｒｅｆｅｒｒｉｎｇｆｉｌｅ ｌｉｓｔは、実際に参照しているファイルのパス名のリストを格納する。ＵＲＬｆｉｌｅ ｉｄｅｎｔｉｆｉｅｒは、管理するファイルが上記のｂｉｎａｒｙ−ｆｉｌｅ−ｉｄｅｎｔｉｆｉｅｒにエンコードできない場合にＵＲＬ（ＵｎｉｆｉｅｄＲｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）形式で、ファイルのパスを格納する。

Ｍｏｖｉｅ ａｔｏｍ１７９１に格納されるその他のデータについて説明する。代表画像データには１６０×１２０画素に縮小されたＪＰＥＧ圧縮されたデータ、タイトル文字列データにはテキストデータ、代表オーディオデータにはＭＰＥＧ−１Ａｕｄｉｏ Ｌａｙｅｒ−ＩＩで圧縮されたデータをそれぞれ用いる。

＜第１の実施形態＞
本発明の第１の実施形態について、図１９乃至図２４を用いて説明する。この実施形態においては、ＡＶ Ｉｎｄｅｘファイルの属性情報に、自動分割ムービーファイルであるかどうかを区別するためのフラグを含ませる。これに応じて、適切な表示、ファイルの削除などを行うことによって、ユーザの混乱を防止する。

＜管理情報フォーマット＞
ＱｕｉｃｋＴｉｍｅムービーファイルおよびＡＶ Ｉｎｄｅｘファイルのフォーマットは前述の通りである。そのうちＡＶＩｎｄｅｘファイルの属性情報（図１８）のｐｅ−ｆｌａｇｓフィールドを図１９のように定義している。以下、各フィールドの定義を説明する。Ａｔｔｒｉｂｕｔｅｏｆ Ｅｎｔｒｙは、このＰｒｏｐｅｒｔｙエントリに対応するエントリの属するレイヤーの種別を格納する。レイヤーについてはここでは説明を省略する。

Ｔｙｐｅ ｏｆ Ｅｎｔｒｙは対応するエントリがファイルかフォルダかを識別するための情報を格納する。Ｕｓａｇｅｏｆ ＥｎｔｒｙおよびＳｔａｔｕｓ ｏｆ Ｅｎｔｒｙについてはここでは説明を省略する。Ｄａｔａ ｒｅｆｅｒｅｎｃｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅは、対応するエントリがＡＶファイルを管理していた場合に、他のＡＶファイルを参照しているかどうか判別するためのフラグである。

Ｓｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅは、対応するエントリが自動分割ムービーファイルであるかどうかを区別するためのフラグであり、自動分割ムービーファイルの場合１がセットされる。Ｓｅｃｕｒｉｔｙｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅは、対応するエントリがＡＶファイルを管理していた場合に、暗号化されているかどうか判別するためのフラグである。

Ｃｏｎｔｅｎｔ ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅは、対応するエントリがＡＶファイルを管理していた場合に、そのファイルに含まれるコンテンツの種別を格納するフィールドである。このように、本実施形態においては、ＡＶＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍのうちの、属性情報に含まれるｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒの項目によって、対応するエントリが管理するファイルが他のファイルから参照されている回数を区別する。また、ＡＶＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍのうちの、属性情報に含まれるｐｅ−ｆｌａｇｓにおける、Ｓｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅのフラグによって、対応するエントリが自動分割ムービーファイルであるかどうかを区別する。以下、これらのフィールドを含めた属性情報をどのように用いるかを説明する。

＜記録時の処理＞
ユーザから録画が指示された場合の処理を、図２０に沿って説明する。このとき記録するＡＶストリームは、ビデオのビットレートＲｖ＝５Ｍｂｐｓ、オーディオのサンプリング周波数４８ｋＨｚ、ビットレートＲａ＝２５６ｋｂｐｓであるものとする。すでに、ファイルシステムの管理情報はＲＡＭ１０２上に読み込まれているとする。

まず、ストリームの構成や連続領域の構成を決定する（ステップ（Ｓ）７０１）。 １ＶＵを１ＧＯＰ＝３０フレームで構成するとしたとき、＜式２＞にＲｓ＝２０Ｍｂｐｓ、Ｔａ＝１秒、Ｒｖ＝５Ｍｂｐｓ、Ｒａ＝２５６ｋｂｐｓを代入し、Ｔｃ（ｉ）の範囲である１．３６秒以上が得られる。１ＶＵの再生時間を０．５秒としているため、ＲＵ再生時間は２秒とする。

次に、ムービーファイル記録準備を行う（ステップ７０２）。具体的にはファイルをｏｐｅｎし、１個のＲＵを連続的に記録可能な空き領域を探す。存在しなければ録画を中止し、録画できないことをユーザに知らせる。

また、オーディオエンコーダ１１７、ビデオエンコーダ１１８をそれぞれ起動する（ステップ７０３）。次に、記録用バッファ１１１に１ＲＵ分のデータが蓄積されているかどうかチェックする（ステップ７０４）。

蓄積されていれば、記録用バッファ１１１中の１ＲＵ分のデータを連続的に光ディスク１０６に記録する（ステップ７０５）。次に現在記録中のファイルのサイズを調べ（ステップ７０６）、次のＲＵを記録したらファイルサイズが４ＧＢを超える可能性がある場合、現在記録中のムービーファイルの管理情報を記録し（ステップ７０７）、以後のデータを別のムービーファイルに記録できるよう新規ムービーファイル記録の準備を行う（ステップ７０８）。また、ステップ７０８の後には、次の１ＲＵ分のデータを記録するために、ステップ７０３に戻る。また、ステップ７０６において、次のＲＵを記録してもファイルサイズが４ＧＢを超えない場合にも、ステップ７０３に戻る。

ステップ７０４において、１ＲＵ分のデータが蓄積されていなければ、記録終了が指示されていないかどうかチェックし（ステップ７０９）、指示されていなければステップ７０４を実行し、指示されていれば以下の記録終了処理を行う。まず、現在記録中のムービーファイルに残りデータを記録し（ステップ７１０）、管理情報を記録する（ステップ７１１）。

次に、自動分割されたかどうかをチェックし（ステップ７１２）、自動分割されたなら、統括ムービーファイルを作成する（ステップ７１３）。最後に、ＡＶＩｎｄｅｘファイルに今回作成したＱｕｉｃｋＴｉｍｅムービーファイルを登録する（ステップ７１４）。自動分割された場合は、自動分割ムービーファイルおよび統括ファイルを登録し、それ以外の場合は１個のＱｕｉｃｋＴｉｍｅムービーファイルを登録する。また、ステップ７１２において、自動分割されていなかった場合にも、ステップ７１４に進む。

図２１を用いて、ＡＶ Ｉｎｄｅｘファイル１８００に登録する属性情報をどのようにセットするかを説明する。まず、自動分割によって自動分割ムービーファイル１８０１、１８０２と統括ムービーファイル１８０３とに分割されて記録された場合について説明する。ここで、この自動分割ムービーファイル１８０１、１８０２が、分割データに相当し、統括ムービーファイル１８０３が、分割データを参照する統括データに相当する。

自動分割ムービーファイル１８０１、１８０２に関しては、自動分割されているため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅを１（ａｕｔｏ−ｄｉｖｉｄｅｄ）にセットする。また、統括ムービーファイル１８０３によって参照されているため、属性情報エントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１にセットする。また、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔには、統括ムービーファイル１８０３のｅｎｔｒｙ−ｎｕｍｂｅｒである３をセットする。

一方、統括ムービーファイル１８０３に関しては、他のファイルから参照されていないため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには０をセットする。また自動分割されていないため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅには０をセットする。

次に、自動分割されず記録された通常記録ムービーファイル１８０４の場合について説明する。通常記録ムービーファイル１８０４に関しては、他のファイルから参照されていないため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒは０にセットする。また自動分割されていないため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅは０にセットする。

＜非破壊編集時の処理＞
非破壊編集処理を行った際のＡＶ Ｉｎｄｅｘファイルの管理方法について、図２２を用いて説明する。まず、自動分割されていないＱｕｉｃｋＴｉｍｅムービーを非破壊編集した場合について説明する。ＡＶＩｎｄｅｘファイル１８００に通常ムービーファイル１８０４が登録されており、このファイルを部分的に参照する非破壊編集結果ムービーファイル１８０５を作成したと仮定する。

このとき、ＡＶ Ｉｎｄｅｘファイル１８００に登録されている通常ムービーファイル１８０４の属性情報エントリ中の値は、非破壊編集結果ムービーファイル１８０５から参照されているため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには１がセットされる。また、ｒｅｆｅｒｒｅｄ−ｆｉｌｅ−ｌｉｓｔには非破壊編集結果ムービーファイル１８０５のｅｎｔｒｙ−ｎｕｍｂｅｒである５が格納される。

また、自動分割されていないため、ｐｅ−ｆｌａｇｓの Ｓｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅは０にセットされる。一方、非破壊編集結果ムービーファイル１８０５の属性情報エントリ中の値は、他のファイルから参照されていないため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには０がセットされる。また、自動分割されていないため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅには０がセットされる。

次に、自動分割されたＱｕｉｃｋＴｉｍｅムービーを非破壊編集した場合について説明する。ここでは、自動分割によって自動分割ムービーファイル１８０１、１８０２と統括ムービーファイル１８０３に分割されて記録されたＱｕｉｃｋＴｉｍｅムービーの一部を参照する、非破壊編集結果ムービーファイル１８０６を作成したと仮定する。

このとき、ＡＶ Ｉｎｄｅｘファイル１８００に登録されている自動分割ムービーファイル１８０１、１８０２の属性情報エントリ中の値は、統括ムービーファイル１８０３および非破壊編集結果ムービーファイル１８０６から参照されているため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには２がセットされる。また、ｒｅｆｅｒｒｅｄ−ｆｉｌｅ−ｌｉｓｔには統括ムービーファイル１８０３および非破壊編集結果ムービーファイル１８０６のｅｎｔｒｙ−ｎｕｍｂｅｒである３、６が格納される。

また、自動分割されているため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅは１にセットされる。統括ムービーファイル１８０３および非破壊編集結果ムービーファイル１８０５、１８０６の属性情報エントリ中の値は、他のファイルから参照されていないため、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒには０がセットされる。また自動分割されていないため、ｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅには０がセットされる。

＜コンテンツ選択画面表示処理＞
ユーザには、属性情報エントリ中のｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅが０のエントリについてサムネイル画像を表示する。例えば図２２の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４、５、６のサムネイル画像が表示されることになる。このように、例えばムービーデータの属性情報エントリ中の、対応するエントリが自動分割ムービーファイルであるかどうかを区別するためのフラグ（分割記録されたかどうかの情報）に応じて、コンテンツ選択画面にサムネイル画像を表示するか否かを決定してもよい。ユーザは、このコンテンツ選択画面から、所望のファイルに対応したサムネイル画像を選択し、そのファイルを再生、削除などすることができる。

＜削除時の処理＞
コンテンツ選択画面を通じてユーザから削除を指示された場合の運用方針として、次の２種類が考えられる。

（運用方針１）非破壊編集によって作成されたＡＶファイルは削除可能、それ以外のＡＶファイルは非破壊編集ムービーによって参照されていなければ削除可能とする。なお、自動分割ムービーファイルが非破壊編集ムービーから参照されている場合、その自動分割ムービーファイルを統括する統括ムービーファイルもその非破壊編集ムービーファイルから参照されているものとして扱う。

（運用方針２）他のＡＶファイルから参照されていないＡＶファイルは削除可能とする。

（運用方針１）は、ユーザの記録したオリジナル（初期記録）のデータとそこから派生する編集結果を区別し、オリジナルデータをなるべく保護しよう、という考えに基づく。（運用方針２）は、削除によって他のＡＶファイルに影響を与えなければよい、という考えに基づく。

ここで、オリジナルのデータとは、例えば録画・録音されたそのままのファイルを意味する。一方、オリジナルでないデータとは、例えば録画・録音されたデータそのものではなく、編集によって作成されたＡＶファイルを意味する。すなわち、例えば非破壊編集されたファイルは、オリジナルでないデータである。

また、ファイルシステムを用いてデータにアクセスする場合には、例えばオリジナルのデータのファイルをオリジナルのファイルと表現し、また例えばオリジナルのファイルのエントリをオリジナルのエントリと表現する。

以下、それぞれの方針を実施する際の処理手順について説明する。

＜削除時の処理（運用方針１）＞
図２２の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが５、６のエントリは非破壊編集によって作成されたムービーに相当し、３、４のエントリはｅｎｔｒｙ−ｎｕｍｂｅｒが５、６のムービーに参照されているオリジナルデータに対応する。したがって、ユーザから削除対象としてｅｎｔｒｙ−ｎｕｍｂｅｒが５、６のエントリを指定されたら、削除し、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４のエントリを指定されたら、削除を拒絶あるいは警告を出すことになる。

以下、削除可能かどうかを判断するための処理手順について、図２３を用いて説明する。まず、指定されたエントリに対応するＡＶファイルが別のＡＶファイルから参照されていないかを調べるため、指定されたエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを調べる。１以上の場合、参照されているため削除不可と判断する（ステップ８０１）。例えば図２２に示す例において、ムービーファイル１８０４は、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが１であるので、削除不可と判断される。ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０の場合は、ステップ８０２に進む。

次に、指定されたエントリに対応するＡＶファイルが別のＡＶファイルを外部参照しているかどうか調べる。参照していない場合、削除可能と判断する（ステップ８０２）。外部参照しているかどうかは、Ｄａｔａｒｅｆｅｒｅｎｃｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅを参照することで判断できる。あるいは他のエントリのｒｅｆｅｒｒｅｄ−ｆｉｌｅ−ｌｉｓｔを調べ、指定されたエントリのｅｎｔｒｙ−ｎｕｍｂｅｒが含まれているかどうかで判断できる。

次に、指定されたＡＶファイルが非破壊編集によって作成されたムービーか、それ以外かを調べる（ステップ８０３）。その手順について、図２４のフローチャートを用いて説明する。まず、指定されたエントリのｅｎｔｒｙ−ｎｕｍｂｅｒが含まれるｒｅｆｅｒｒｅｄ−ｆｉｌｅ−ｌｉｓｔを持つエントリをすべてリストアップし、そのエントリのＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅの値を調べる（ステップ９０１）。これによって、そのエントリが分割記録（自動分割）されたものであるか否かを調べる。

１個でも１（ａｕｔｏ−ｄｉｖｉｄｅｄ）でなければ、非破壊編集によって作成されたムービーと判断する（ステップ９０２）。すべてが１であれば、次にそのエントリに対応するのが統括ムービーファイルなのか非破壊編集ムービーファイルなのかを識別する。具体的には、リストアップされたエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒをチェックし（ステップ９０３）、１個でも２以上のものがない場合には、統括ムービーファイルであるとして、オリジナルのファイルであると判断する（ステップ９０４）。すなわち、非破壊編集によって作成されたムービーファイルでないと判断する。このように、他のエントリが管理するデータとの関連情報としてのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒに応じて判別を行う。

ステップ９０４においてｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒの値が２以上のものがあれば、そのエントリに対応するファイルを参照している別のファイルに対応するエントリとｃｒｅａｔｉｏｎ−ｔｉｍｅ（作成時間）を比較し、最も古い場合、統括ムービーファイル（オリジナルのファイル）と判断し、それ以外の場合は非破壊編集ムービーファイルと判断する（ステップ９０５）。

例えば図２２に示す例において、統括ムービーファイル１８０３について上述の手順を実行すると、ステップ９０１，９０２，９０３，９０４を介して、ステップ９０５にて、他のムービーファイル１８０６とｃｒｅａｔｉｏｎ−ｔｉｍｅが比較されて、オリジナルのファイルであると判別されることになる。また、ムービーファイル１８０５，１８０６については、上述の手順にて非破壊編集ムービーファイルであると判別される。

なお、ここでは属性情報エントリ中のｃｒｅａｔｉｏｎ−ｔｉｍｅで判断しているが、例えばｄｕｒａｔｉｏｎを用いてもよい。具体的には、参照先のＡＶファイルのｄｕｒａｔｉｏｎの合計と指定されたムービーのｄｕｒａｔｉｏｎが一致すれば統括ムービーファイル、すなわち非破壊編集によって作成されたムービーファイルでない、一致しなければ非破壊編集ムービーファイルと判断する。

ここで、再び図２３を用いて説明する。指定されたエントリに対応するＡＶファイルがオリジナルでなければ削除可能と判断し（ステップ８０４）、オリジナルであれば次のステップ８０５に進む。次に、指定されたエントリに対応するＡＶファイルが参照しているＡＶファイルのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒをチェックし（ステップ８０５）、すべてが１であれば削除可能、そうでなれば削除不可と判断する（ステップ８０６）。

次に、削除可能と判断され、実際に削除を行った後の処理について説明する。削除されたのが統括ムービーファイルの場合、統括ムービーファイルだけでなくそこから参照されている自動分割ムービーファイルも削除を行う。

非破壊編集ムービーファイルの場合、非破壊編集ムービーファイルを削除し、さらに、そのファイルから参照されているＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減らし、さらに、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔからその非破壊編集ムービーファイルに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを削除する。それ以外のＡＶファイルの場合、そのＡＶファイルを削除するだけでよい。なお、いうまでも無いが、削除したＡＶファイルに対応するＡＶＩｎｄｅｘファイルのエントリも削除する。

このように、ステップ８０３，８０４にて、エントリがオリジナルであるか否かを判断することによって、そのエントリを削除可能であるか削除不可であるかを判断して、これに応じて削除する。したがって、自動分割ムービーファイルがある場合でもユーザに違和感を与えず削除を実行することができる。

また、上記構成においては、例えば図２３を参照して説明したように、ステップ８０４においてオリジナルであるか否か（初期記録データであるか否か）を判別し、オリジナルであると判別したファイルを、ステップ８０６において参照先のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが全て１の場合には削除可能と判別し、参照先のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが全て１ではない場合には削除不可と判別する。

したがって、例えば図２２に示すような統括ムービーファイル１８０３について削除の可否を判別する場合には、参照先のファイル１８０１，１８０２のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが全て１ではなく、他のムービーファイル１８０６からも参照されているので、削除不可と判別する。

また、統括ムービーファイル１８０３について、図２１に示す状態において削除の可否を判別する場合には、参照先のファイル１８０１，１８０２のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが全て１であるので、削除可能と判別する。そして、削除する際には、統括ムービーファイル１８０３に加えて、参照先のファイル１８０１，１８０２をも削除する。

このように、自動分割ムービーファイルがある場合でも、自動分割ムービーファイルが統括ムービーファイルのみから参照されており、他のファイルから参照されていないときにのみ削除するので、ユーザに違和感を与えず削除を実行できる。また、参照ムービー（自動分割ムービー、統括ムービー）をユーザに混乱を与えずに管理できる。

また、図２４を参照して説明したように、登録されているエントリがオリジナルか否かを判断する際には、ステップ９０１〜９０５にて、分割記録されたかどうかの情報、他のエントリが管理するデータとの関連情報、および作成時間に基づいて判断する構成である。したがって、オリジナルか否かを確実に判別できる。

＜削除時の処理（運用方針２）＞
図２２の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが ３、５、６のエントリに関して、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０であるため、他のエントリに対応するＡＶファイルから参照されていない、と判断できる。したがって、ユーザから削除対象としてｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリを指定されたら削除し、ｅｎｔｒｙ−ｎｕｍｂｅｒが４のエントリを指定されたら、削除を拒絶あるいは警告を出すことになる。

実際の削除は、以下の手順で行う。まず、削除を指定されたファイルから参照されているＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減らし、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔからそのＡＶファイルに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを削除する。もし、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０になった場合、そのＡＶファイルを削除する。最後に、削除を指定されたＡＶファイルを削除する。なお、いうまでも無いが、削除したＡＶファイルに対応するＡＶＩｎｄｅｘファイルのエントリも削除する。

＜第２の実施形態＞
本発明の第２の実施形態について、図２５乃至図２７を用いて説明する。この実施形態においては、ＡＶ Ｉｎｄｅｘファイルの属性情報に、自動分割ムービーファイルであるかどうかを区別するためのフラグに加えて、初期記録データか否かに関するフラグを含ませる。これに応じて、適切な表示、ファイルの削除などを行うことによって、ユーザの混乱を防止する。第２の実施形態は、例えば以下に説明するような、第１の実施形態において記録機器の内蔵時計が正確でない場合に生ずる問題をも解決できる実施形態である。なお、上述した第１の実施形態と共通する点が多いため、ここでは異なる点のみに絞って説明を行う。

＜管理情報フォーマット＞
ＱｕｉｃｋＴｉｍｅムービーファイルおよびＡＶ Ｉｎｄｅｘファイルのフォーマットは前述の通りである。本実施形態においては、ＡＶＩｎｄｅｘファイルのＰｒｏｐｅｒｔｙエントリ中のｐｅ−ｆｌａｇｓフィールドは図２５のように定義されている。ｐｅ−ｆｌａｇｓには、例えばＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅのフラグも含まれている。上述した第１の実施形態とほぼ同じであるが、Ｔｙｐｅｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅという、このエントリに対応するＡＶファイルがオリジナルか編集によって作成されたものかを区別するためのフラグが追加されている点が異なる。Ｔｙｐｅｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅの値が０であればオリジナル（録画・録音されたそのまま）のＡＶファイル、１であれば編集によって作成されたＡＶファイルとなる。すなわち、ＡＶＩｎｄｅｘファイルにおける、Ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅというフラグは、エントリが管理するデータが初期記録データか否かに関する情報に相当する。

このフラグの説明を次に行う。第１の実施形態では、図２３に示すように削除時にオリジナルファイルか非破壊編集ファイルかを区別する。ここで、オリジナルファイルとは、ユーザの撮影した初期記録ファイルのことである。その際、図２４に示すようにｃｒｅａｔｉｏｎ−ｔｉｍｅを参照して判断を行っているが、記録機器の内蔵時計が正確でない場合、処理に誤りが生じる可能性がある。このフラグを導入することで、記録機器の内蔵時計に依存することなくオリジナルファイルか非破壊編集ファイルかを区別することが可能になる。また、ＡＶＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍのうちの、属性情報に含まれる ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒの項目によって、対応するエントリが管理するファイルが他のファイルから参照されている回数を区別する点も、上述の実施の形態と同様である。

＜記録時の処理＞
ユーザから録画が指示された場合の処理は、第１の実施形態と同じであるため省略する。ただし、図２６に示すように、ＡＶ Ｉｎｄｅｘファイルの属性情報エントリに追加されたＴｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅに、０を設定する点が異なる。

＜非破壊編集処理＞
非破壊編集処理を行った際のＡＶ Ｉｎｄｅｘファイルの管理方法については、上述した第１の実施形態と同じであるため説明を省略する。ただし、図２７に示すように、非破壊編集結果ムービー１８０５、１８０６に対応するＡＶＩｎｄｅｘファイルの属性情報中のＴｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅに１を設定する点が異なる。

＜コンテンツ選択画面表示処理＞
ユーザには、属性情報エントリ中のｐｅ−ｆｌａｇｓのＳｔｒｕｃｔｕｒａｌ ｓｔａｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅが０のエントリについてサムネイル画像を表示する。例えば図２７の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４、５、６のサムネイル画像が表示されることになる。

＜削除時の処理＞
コンテンツ選択画面を通じてユーザから削除を指示された場合の運用方針として、上述した第１の実施形態と同様、（運用方針１）および（運用方針２）の２種類が考えられる。以下、それぞれの方針を実施する際の処理手順について説明する。

＜削除時の処理（運用方針１）＞
コンテンツ選択画面を通じてユーザから削除を指示された場合の処理は第１の実施形態において図２３、図２４を参照して説明した処理とほぼ同じである。ただし、本実施形態では、図２３のステップ８０３において、指定されたエントリに対応するＡＶＦｉｌｅが非破壊編集によって作成されたものかオリジナルかを判断するのに、指定されたエントリのｐｅ−ｆｌａｇｓのＴｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅを参照して、１なら非破壊編集、０ならオリジナルと判断する。この点が第１の実施形態と異なる。

このように、本実施形態においては、ＡＶ Ｉｎｄｅｘファイルにおける、Ｔｙｐｅｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅというフラグを用いて、ファイルがオリジナルか否かを判断する構成である。このフラグは、記録または非破壊編集などによる、ファイルの作成時に設定するので、確実に、ファイルがオリジナルか否かを判別できる。

上述した第１の実施形態では、ｃｒｅａｔｉｏｎ−ｔｉｍｅを参照して判断を行うため、記録機器の内蔵時計が正確でない場合、処理に誤りが生じる可能性があるが、本実施形態の場合、内蔵時計の正確さに処理が依存しないという利点がある。

また、ファイルの削除の際には、上述の実施の形態と同様に、自動分割ムービーファイルがある場合でも、自動分割ムービーファイルが統括ムービーファイルのみから参照されており、他のファイルから参照されていないときにのみ削除するので、ユーザに違和感を与えず削除を実行できる。また、参照ムービー（自動分割ムービー、統括ムービー）をユーザに混乱を与えずに管理できる。

＜削除時の処理（運用方針２）＞
第１の実施形態と同様である。すなわち、図２７の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリに関して、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０であるため、他のエントリに対応するＡＶファイルから参照されていない、と判断できる。したがって、ユーザから削除対象としてｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリを指定されたら削除し、ｅｎｔｒｙ−ｎｕｍｂｅｒが４のエントリを指定されたら、削除を拒絶あるいは警告を出すことになる。

実際の削除は、以下の手順で行う。まず、削除を指定されたファイルから参照されているＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減らし、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔからそのＡＶファイルに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを削除する。もし、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０になった場合、そのＡＶファイルを削除する。最後に、削除を指定されたＡＶファイルを削除する。なお、いうまでも無いが、削除したＡＶファイルに対応するＡＶＩｎｄｅｘファイルのエントリも削除する。

＜第３の実施形態＞
本発明の第３の実施形態について、図２８乃至図３２を用いて説明する。この実施形態においては、ＡＶ Ｉｎｄｅｘファイルの属性情報に、自動分割ムービーファイルであるかどうかを区別するためのフラグ、初期記録データか否かに関するフラグに加えて、データをユーザに見せるかどうかに関するフラグを含ませる。これに応じて、適切な表示、ファイルの削除などを行うことによって、ユーザの混乱を防止する。なお、上述した第１および第２の実施形態と共通する点が多いため、ここでの説明は相違点のみに絞る。

＜管理情報フォーマット＞
ＱｕｉｃｋＴｉｍｅムービーファイルおよびＡＶ Ｉｎｄｅｘファイルのフォーマットは前述の通りである。ＡＶＩｎｄｅｘファイルのＰｒｏｐｅｒｔｙエントリ中のｐｅ−ｆｌａｇｓフィールドは図２８に示すように定義されている。ｐｅ−ｆｌａｇｓには、例えばＳｔｒｕｃｔｕｒａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅのフラグや、Ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅのフラグも含まれている。上述した第２の実施形態とほぼ同じであるが、Ｖｉｓｕａｌｓｔａｔｕｓ ｏｆ Ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅという、このエントリをコンテンツ選択画面等でユーザに見せる（０の場合）か隠す（１の場合）かを示すフラグが追加されている点が異なる。このＡＶＩｎｄｅｘファイルのＶｉｓｕａｌ ｓｔａｔｕｓ ｏｆ Ｔｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅというフラグは、エントリが管理するデータをユーザに見せるかどうかを管理する情報に相当する。

このフィールドを設けることで、後述するように第１および第２の実施形態における削除の運用方法に比べ、異なる運用方法を選択することが可能になる。

なお、ＡＶ ＩｎｄｅｘファイルのＭｏｖｉｅ ａｔｏｍのうちの、属性情報に含まれるｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒの項目によって、対応するエントリが管理するファイルが他のファイルから参照されている回数を区別する点も、上述の実施の形態と同様である。

＜記録時の処理＞
ユーザから録画が指示された場合の処理は、上述した第１の実施形態と同じであるため説明を省略する。ただし、図２９に示すように、ＡＶＩｎｄｅｘファイルの属性情報エントリに追加されたＶｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅに、自動分割ムービーファイル１８０１および１８０２に関しては１を設定し、統括ムービーファイル１８０３および通常ムービーファイル１８０４に関しては０を設定する点が異なる。

＜非破壊編集処理＞
非破壊編集処理を行った際のＡＶ Ｉｎｄｅｘファイルの管理方法については、上述した第２の実施形態と同じであるため説明を省略する。ただし、図３０に示すように、非破壊編集結果ムービー１８０５、１８０６に対応するＡＶＩｎｄｅｘファイルの属性情報エントリ中のＶｉｓｕａｌ Ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅに０を設定する点が異なる。

＜アフレコ時の処理＞
図２９のＡＶファイル１８０４に対し、オーディオアフレコを行い、図３１に示すように、入力されたオーディオデータを前記ムービーとは別のＡＶファイル１８０７に格納し、ＡＶファイル１８０４から外部参照するものとする。このとき、ＡＶファイル１８０７に対応するエントリ（ｅｎｔｒｙ−ｎｕｍｂｅｒ＝５のエントリ）のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒは、ＡＶファイル１８０４から参照されているため１となり、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔには、ＡＶファイル１８０４に対応するｅｎｔｒｙ−ｎｕｍｂｅｒである４が格納される。

また、ＡＶファイル１８０７はＡＶファイル１８０４の付属物であり独立のコンテンツとして扱うことはないため、コンテンツ選択画面に表示しない。そのため、Ｖｉｓｕａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅの値は１（Ｉｎｖｉｓｉｂｌｅ）に設定する。

＜コンテンツ選択画面表示処理＞
ユーザには、属性情報エントリ中のｐｅ−ｆｌａｇｓのＶｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅが０のエントリについてサムネイル画像を表示する。すなわち、Ｖｉｓｕａｌ ｓｔａｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅのフラグに基づいて、表示を制御する。例えば図３０の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４、５、６のサムネイル画像が表示されることになる。図３１の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、４のサムネイル画像が表示され、独立のコンテンツとして扱うことの無いＡＶファイル１８０７に対応するサムネイルは表示されない。不要な情報を表示しないことによって、ユーザに混乱を与える可能性が低くなる。このことは、本実施形態で導入されたＶｉｓｕａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅという情報で可能となっている。

＜削除時の処理＞
本実施形態では、コンテンツ選択画面を通じてユーザから削除を指示された場合の運用方針は、第１、第２の実施形態で使用しているものに追加して、次のものが考えられる。

（運用方針３）すべてのＡＶファイルは削除可能とする。

（運用方針３）は、ユーザにオリジナルと編集結果の違いをなるべく意識させない、という考えに基づく。なお、（運用方針３）は、第３の実施形態で導入された管理情報によって可能となっている。

以下、それぞれの方針を実施する際の処理手順について説明する。

＜削除時の処理（運用方針１）＞
上述した第２の実施形態と同様である。すなわち、コンテンツ選択画面を通じてユーザから削除を指示された場合の処理は第１の実施形態において図２３、図２４を参照して説明した処理とほぼ同じである。ただし、本実施形態では、図２３のステップ８０３において、指定されたエントリに対応するＡＶＦｉｌｅが非破壊編集によって作成されたものかオリジナルかを判断するのに、指定されたエントリのｐｅ−ｆｌａｇｓのＴｙｐｅ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅを参照して、１なら非破壊編集、０ならオリジナルと判断する。この点が第１の実施形態と異なる。

このように、本実施形態においては、ＡＶ Ｉｎｄｅｘファイルにおける、Ｔｙｐｅｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅというフラグを用いて、ファイルがオリジナルか否かを判断する構成である。このフラグは、記録または非破壊編集などによる、ファイルの作成時に設定するので、確実に、ファイルがオリジナルか否かを判別できる。また、本実施形態の場合、内蔵時計の正確さに処理が依存しないという利点がある。

また、ファイルの削除の際には、上述の実施の形態と同様に、自動分割ムービーファイルがある場合でも、自動分割ムービーファイルが統括ムービーファイルのみから参照されており、他のファイルから参照されていないときにのみ削除するので、ユーザに違和感を与えず削除を実行できる。また、参照ムービー（自動分割ムービー、統括ムービー）をユーザに混乱を与えずに管理できる。

＜削除時の処理（運用方針２）＞
上述した第１の実施形態と同じである。すなわち、図３０の場合、ｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリに関して、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０であるため、他のエントリに対応するＡＶファイルから参照されていない、と判断できる。したがって、ユーザから削除対象としてｅｎｔｒｙ−ｎｕｍｂｅｒが３、５、６のエントリを指定されたら削除し、ｅｎｔｒｙ−ｎｕｍｂｅｒが４のエントリを指定されたら、削除を拒絶あるいは警告を出すことになる。

実際の削除は、以下の手順で行う。まず、削除を指定されたファイルから参照されているＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減らし、ｒｅｆｅｒｒｉｎｇ−ｆｉｌｅ−ｌｉｓｔからそのＡＶファイルに対応するエントリのｅｎｔｒｙ−ｎｕｍｂｅｒを削除する。もし、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０になった場合、そのＡＶファイルを削除する。最後に、削除を指定されたＡＶファイルを削除する。なお、いうまでも無いが、削除したＡＶファイルに対応するＡＶＩｎｄｅｘファイルのエントリも削除する。

＜削除時の処理（運用方針３）＞
コンテンツ選択画面を通じてユーザから削除を指示されたエントリはすべて削除可能、という運用を行う場合の処理について説明する。以下、削除の処理手順について、図３２を用いて説明する。まず、指定されたエントリに対応するＡＶファイルが別のＡＶファイルから参照されていないかを調べるため、指定されたエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを調べる（ステップ１００１）。ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが１の場合、Ｖｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶ Ｆｉｌｅを１にセットする（ステップ１００６）。このことにより、他のムービーの再生に影響を与えることなくユーザに対して削除したように見せることができる。すなわち、ファイルを見かけ上削除することができる。なお、この場合、Ｖｉｓｕａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅのフラグは、０から１に変更されることになる。ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０の場合、指定されたエントリに対応するＡＶファイルが他のＡＶファイルを参照しているかどうかを調べる（ステップ１００２）。

参照していなければ、後述するステップ１００５を実行する。参照していた場合、まず、参照先のＡＶファイルに対応するエントリのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減ずる（ステップ１００３）。

次に、参照先のＡＶファイルのｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒおよびＶｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶの値を調べ、ｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒが０、なおかつＶｉｓｕａｌ ｓｔａｔｕｓｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇ ＡＶが１（ｉｎｖｉｓｉｂｌｅ）ならそのファイルを削除し、ＡＶＩｎｄｅｘファイルからそのファイルに関するエントリを削除する（ステップ１００４）。最後に、指定されたエントリに対応するＡＶファイルを削除する（ステップ１００５）。

図３０を用いて上記の処理を具体的に説明する。ｅｎｔｒｙ−ｎｕｍｂｅｒが５あるいは６に対応するエントリを削除指定した場合、それらのエントリを削除し、さらにファイル１８０５あるいは１８０６は削除する。ｅｎｔｒｙ−ｎｕｍｂｅｒが３に対応するエントリを削除指定した場合、そのエントリを削除し、ファイル１８０３も削除する。ただし、参照先のファイル１８０１および１８０２はファイル１８０６から参照されているため削除されない。

ｅｎｔｒｙ−ｎｕｍｂｅｒが４に対応するエントリを削除指定した場合、そのエントリに対応するファイル１８０４はファイル１８０５から参照されているため削除せず、代わりにＶｉｓｕａｌｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅを１にセットする。

図３１の場合も上記と同様である。ｅｎｔｒｙ−ｎｕｍｂｅｒが４に対応するエントリを削除指定した場合、ｒｅｆｅｒｒｅｄ ｃｏｕｎｔｅｒが０であり、そこから参照されているＡＶファイル１８０７のｒｅｆｅｒｒｅｄ−ｃｏｕｎｔｅｒを１減じて０になるため、ｅｎｔｒｙ−ｎｕｍｂｅｒが４、５に対応するエントリを削除し、さらに、それらのエントリに対応するＡＶファイル１８０４、１８０７も削除する。

このように、本実施形態は、コンテンツ選択画面でユーザに表示するか否かを示すＶｉｓｕａｌ ｓｔａｔｕｓ ｏｆ ｃｏｒｒｅｓｐｏｎｄｉｎｇＡＶ Ｆｉｌｅを用いる構成であるので、ファイルの参照を行っていた場合でもユーザが任意のコンテンツを削除することが可能となる。すなわち、例えば他から参照されているファイルであっても、表示しないようにして、見かけ上の削除をすることができる。

＜バリエーション＞
本発明の第１の実施形態から第３の実施形態までＡＶ Ｉｎｄｅｘファイルは同じ記録媒体に記録されたファイルの管理を行っているが、別の記録媒体、例えばネットワーク越の別の記録媒体上のファイルであっても構わないことは言うまでもない。

また、上述の実施形態においては、記録媒体としての光ディスク１０６について説明したが、これに限るものではなく、例えばハードディスク、光磁気ディスクのような、ランダムアクセス可能な記録媒体であってもよい。

また、ファイルシステムとしてＵＤＦを例にとり、またファイルフォーマットとしてＱｕｉｃｋＴｉｍｅファイルフォーマットを例にした説明をしているが、本発明はこれに限るものではなく、その他のファイルシステム、ファイルフォーマットであっても同様に適用できる。

また、ＱｕｉｃｋＴｉｍｅファイルフォーマットを管理するためのＡＶ Ｉｎｄｅｘファイルを用いてファイルを管理する例について説明したが、本発明はこれに限るものではなく、その他のファイル、テーブルなどを用いて管理する構成であってもよい。

以上のように、上述の実施の形態においては、記録装置としてのディジタル記録再生装置は、ファイル管理部としてのホストＣＰＵ１０１が、光ディスク１０６に、データが分割記録されたかどうかの情報を記録する。

したがって、分割記録されたかどうかに応じて適切な表示、削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。

すなわち、分割記録された場合の分割データとこの分割データを参照する統括データとについて、分割データを表示しないようにする。

ここで、この分割データは、ファイルシステムにおいてファイルサイズの上限が存在するために、例えばこの上限を超えるサイズのファイルを分割して生成されるものである。上述のように、分割データを表示しないようにすれば、ユーザに混乱を与えることがない。

また、統括データを削除しようとするときには、統括データが参照している分割データが、その統括データのみから参照されている場合には、統括データとともに参照している分割データをも削除するようにする。

したがって、分割データがある場合であっても、ユーザに分割データの存在を意識させることなく、削除することができる。なお、データを削除する場合には、他のファイルから参照されていないときに削除が可能である。

また、記録装置としてのディジタル記録再生装置は、ファイル管理部としてのホストＣＰＵ１０１が、光ディスク１０６に、データが初期記録データか否かに関する情報を記録する。

したがって、初期記録データか否かに応じて適切な表示、削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。

すなわち、複数のデータのうち、分割記録された場合の分割データとこの分割データを参照する統括データとがある場合に、そのデータが統括データであるか否かを、初期記録データか否かに関する情報を用いて判別できる。したがって、ファイルの生成時間などを参照する必要がないので、記録装置の内蔵時計が正確でない場合であっても、判別を確実にできる。

また、記録装置としてのディジタル記録再生装置は、ファイル管理部としてのホストＣＰＵ１０１が、光ディスク１０６に、データの存在をユーザに見せるかどうかを管理する情報を記録する。

したがって、データの存在をユーザに見せるかどうかを管理する情報に応じて、適切な表示、見かけ上の削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。

すなわち、例えば分割データであるか否かとは別に、データの存在をユーザに見せるかどうかを管理する情報に応じて表示を行うので、ユーザに混乱を与えることがない表示が可能となるとともに、見かけ上の削除が可能となる。

また、光ディスク１０６には、上述のようにデータが初期記録データか否かに関する情報が記録される。

したがって、上述のディジタル記録再生装置のような記録装置と組合せて用いられて、初期記録データか否かに応じて適切な表示、削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。

また、光ディスク１０６には、上述のようにデータの存在をユーザに見せるかどうかを管理する情報が記録される。

したがって、上述のディジタル記録再生装置のような記録装置と組合せて用いられて、データの存在をユーザに見せるかどうかを管理する情報に応じて適切な表示、見かけ上の削除などのファイル操作を行って、ユーザに混乱を与えずにファイル管理ができる。

また、記録装置としてのディジタル記録再生装置は、コンピュータによって実現されるものであってもよい。すなわち、上述したデータ記録方法、データ削除方法のいずれかを実行するプログラムがコンピュータにて読取られ、実行されて、上述のディジタル記録再生装置が実現されてもよい。

また、以上に説明したデータ記録方法、データ削除方法は、例えば、ファイルシステムにおけるファイル管理情報を用いてデータの管理を行うファイル管理方法である、ということもできる。そして、ファイルのうちに、分割ファイルとこの分割ファイルを参照する統括ファイルとが含まれている場合に、ファイル管理方法のファイル管理情報に、ファイルが分割ファイルであるか否かを示すフラグを含ませる。そして、この分割ファイルであるか否かを示すフラグと、あるファイルが他の何個のファイルから参照されているかを示す数と、ファイルの作成時間とから、ファイルが統括ファイルであるか否かを判別できる。

また、上述の構成を、例えば、複数のデータを一括して管理するテーブルを持つ記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、前記削除の際に、登録されているエントリがオリジナルか否かを判断するステップを有することを特徴とするデータ削除方法である、と表現することもできる。

また、上述の構成を、例えば、前記構成において、前記登録されているエントリがオリジナルか否かを判断するステップが、自動分割されたかどうかの情報および参照情報および作成時間に基づくことを特徴とするデータ削除方法である、と表現することもできる。

また、上述の構成を、例えば、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録するデータ記録方法であって、前記複数のデータに対応するエントリにオリジナルか否かを判断することが可能な情報を記録することを特徴とするデータ記録方法である、と表現することもできる。

また、上述の構成を、例えば、複数のデータをそれぞれエントリとして一括管理するテーブルを持ち、前記データに対応するエントリにオリジナルか否かを管理する情報が記録してある記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、削除時に、削除対象のデータが前記オリジナルか否かを管理する情報を基に削除可能かどうかを判断するステップを有することを特徴とするデータ削除方法である、と表現することもできる。

また、上述の構成を、例えば、複数のデータをそれぞれエントリとして一括管理するテーブルを記録媒体に記録するデータ記録方法であって、前記データに対応するエントリにそのデータの存在をユーザに見せるかどうかを管理する情報を記録することを特徴とするデータ記録方法である、と表現することもできる。

また、上述の構成を、例えば、複数のデータをそれぞれエントリとして一括管理するテーブルを持ち、前記データに対応するエントリにそのデータの存在をユーザに見せるかどうかを管理する情報が記録してある記録媒体から、前記テーブル中のエントリに対応するデータを削除するデータ削除方法であって、削除対象データが他のデータから参照されていた場合、前記データの存在をユーザに見せるかどうかを管理する情報を書き換えることを特徴とするデータ削除方法である、と表現することもできる。

以上説明したように、本発明によれば、ディスク上の各ファイルが自動分割ムービーファイルかどうかを区別する情報とオリジナルかどうかを区別する情報に基づくことで、自動分割ムービーファイルがある場合でもユーザに違和感を与えず削除を実行することができる。

また、本発明によれば、オリジナルかどうかを管理する情報をディスク上に格納することで、自動分割ムービーファイルがある場合でもユーザに違和感を与えず確実に削除を行うことができる。

さらに、本発明によれば、エントリに対応するＡＶファイルに関して、ユーザに見せるか見せないかを区別するための情報をディスク上に格納することで、ファイルの参照を行っていた場合でもユーザが任意のコンテンツを見かけ上削除することが可能となる。

ここで、例えば、図３６に示すように、インデックスファイル２１００の各エントリ毎に自動分割ムービーであるか否かを管理するフラグａｕｔｏ−ｄｉｖｉｄｅｄをつけ、自動分割ムービーであるファイル２２０１〜２２０３については、ＹＥＳをセットし、コンテンツ選択画面には、ａｕｔｏ−ｄｉｖｉｄｅｄがＮＯのエントリの縮小画像のみ、すなわちファイル２２０４の縮小画像のみ表示する、という方法も考えられる。しかしながら、この構成においては、削除等の管理をどのようにするかは明らかではない。

発明を実施するための最良の形態の項においてなした具体的な実施態様または実施例は、あくまでも、本発明の技術内容を明らかにするものであって、そのような具体例にのみ限定して狭義に解釈されるべきものではなく、本発明の精神と請求の範囲に記載した事項の範囲内で、いろいろと変更して実施することができるものである。

また、請求の範囲に記載した事項や、発明を実施するための最良の形態に記載した技術的手段は、適宜組み合わせることができ、この組み合わせによって得られる事項も本発明の技術的範囲に含まれる。

本発明のデータ記録方法、データ削除方法、データ表示方法、記録装置、記録媒体およびプログラムによれば、インデックスファイルにおいて、管理している各ファイルに関して、ユーザに見せる又は隠す、オリジナルか又は非破壊編集済みかを区別する情報を管理し、それらの情報に基づき削除処理や一覧表示処理を行う。したがって、ユーザに混乱を与えずに、参照ムービーをインデックスファイルで管理できる。

Claims (4)

1. 記録媒体に記録された、ムービーを構成するＡＶデータを再生するデータ再生装置であって、
   前記記録媒体には、複数のムービーと、前記複数のムービーを管理するインデックスが記録されており、
   前記複数のムービーは、それぞれ、前記ＡＶデータを参照するための第１の参照情報と、前記ＡＶデータの再生を制御する再生制御情報とを含み、
   前記インデックスは、前記ムービー毎に前記ムービーを管理するためのエントリを含み、
   前記エントリは、対応する前記ムービーを参照するための第２の参照情報と、対応する前記ムービーの存在をユーザに見せるか否かを示す属性情報を含み、
   前記第２の参照情報によって参照され、かつ、対応する前記属性情報の値が前記ムービーの存在をユーザに見せる値である前記ムービーをユーザに選択させる選択手段と、
   選択された前記ムービーの前記第１の参照情報および前記再生制御情報に基づいて前記ＡＶデータを再生する再生手段とを備え、
   前記対応する前記属性情報の値が前記ムービーの存在をユーザに見せない値であった場合、当該ムービーを前記選択手段を通じてユーザに選択させず、かつ、当該ムービーの前記第１の参照情報が参照する前記ＡＶデータを前記再生手段を通じて再生させないことを特徴とするデータ再生装置。
2. 記録媒体に記録された、ムービーを構成するＡＶデータを再生するデータ再生方法であって、
   前記記録媒体には、複数のムービーと、前記複数のムービーを管理するインデックスが記録されており、
   前記複数のムービーは、それぞれ、前記ＡＶデータを参照するための第１の参照情報と、前記ＡＶデータの再生を制御する再生制御情報とを含み、
   前記インデックスは、前記ムービー毎に前記ムービーを管理するためのエントリを含み、
   前記エントリは、対応する前記ムービーを参照するための第２の参照情報と、対応する前記ムービーの存在をユーザに見せるか否かを示す属性情報を含み、
   前記第２の参照情報によって参照され、かつ、対応する前記属性情報の値が前記ムービーの存在をユーザに見せる値である前記ムービーをユーザに選択させる選択ステップと、
   選択された前記ムービーの前記第１の参照情報および前記再生制御情報に基づいて前記ＡＶデータを再生する再生ステップとを備え、
   前記対応する前記属性情報の値が前記ムービーの存在をユーザに見せない値であった場合、当該ムービーを前記選択ステップにおいてユーザに選択させず、かつ、当該ムービーの前記第１の参照情報が参照する前記ＡＶデータを前記再生ステップにおいて再生させないことを特徴とするデータ再生方法。
3. 請求項２に記載のデータ再生方法を、コンピュータに実行させるプログラム。
4. 請求項３に記載のプログラムを記録したコンピュータ読み取り可能な記録媒体。
   

Images