JP5064531B2 - データ記録装置およびデータ再生装置 - Google Patents

Description

本発明は、データブロック単位で様々なデータが登録されたファイルを読み書きする記録媒体用のデータ記録装置およびデータ再生装置に関するものである。

様々なデータを記録媒体に記録、ネットワークを介した転送、配信などを行う場合、データそのものとそのデータがどのようなデータであるか、またはそのデータにアクセスするために、全データ中のどこにどのような形態で存在しているかを表す、そのデータを管理する管理情報が必要となる。

管理情報には、例えば図１４に示すように、記録されたデータのファイル名を管理することを目的として、１つのEntryにファイル名を格納する場合を考える。この場合、存在するファイルの数により、ファイル名を格納する管理情報の領域（データブロック）が可変長となるため、管理情報のデータ領域を把握することが必要となる。

このため、管理情報内の任意の決まった位置（図１４の例では、管理情報の先頭の位置）にファイルの個数を格納することにより、ファイル名を管理している情報領域を把握することが可能となる。ここで、データブロックとは、ファイル名などのいくつかのデータ群とそれを管理するデータ数などの管理情報とを１まとまりにしたものをいう。

また、図１５に示すように、複数の画像データを１つのファイルで管理する場合を考える。この時、可変長符号化アルゴリズムを利用して画像データを圧縮する場合、個々の画像データのデータサイズが異なることになる。よって、それぞれの画像データにアクセスするためには、各データのデータサイズを示す管理情報が必要となる。

上記２つの例では、データ数やデータサイズが可変長となっている。そのため、ファイルの任意の位置に付加したデータの個数や、データのサイズなどの管理情報によって、そのデータブロックの終了位置を知ることができるため、後続するデータブロックのデータの先頭位置を知ることが可能である。

このように、データ長をデータブロックの先頭に付加する形態をとることにより、複数のデータブロックを連続して記録する場合、ファイルの先頭からデータブロックのサイズだけ読み飛ばすことで、後続するデータブロックにアクセスすることが可能となる。これをファイル内で繰り返すことにより、ファイル内のデータブロックを検索することができる。

AVデータのファイルフォーマットであるQuickTimeの場合は、図１６に示すように、１つのまとまったデータブロックをatomという単位で表し、そのatomでは、先頭の４バイトにそのatomのバイト単位のサイズ、後続する４バイトにそのatomの種類を格納するヘッダをデータの先頭に付加している。

そのため、QuickTimeファイルの先頭の8バイトで最初のatomのサイズと種類を知ることができ、ファイルの先頭からその最初のatomのサイズだけシーク（atomの先頭アドレスにatomのサイズを加算したアドレスへ移動）することにより、後続するatomにアクセスすることが可能となる。

また、atomはファイル内に連続して記録できるだけでなく、図１６におけるmoov atom内のtrak atomのように、atom内にさらにいくつかのatomをもつことが可能であり、atomを入れ子にすることができる。

ここで、moov atomとは、いくつかのAVデータが記録されているmdat atom内データの管理情報が登録されているatomである。また、trak atomは、moov atom内に存在し、音声や画像などを再生するために必要な管理情報を保持しているatomである。

ファイル内の任意のatomを検索するには、ファイルの先頭より、atomのヘッダを読み出し、最初のatomの種類が目的のatomであるか確認する。もし、最初のatomの種類が目的のatomでなかった場合は、最初のatomのデータサイズだけファイルの先頭より読み飛ばし、後続するatomのヘッダ情報を取得する。

取得したatomのヘッダ情報より、atomの種類が目的のatomであるかの確認を行う。これをファイルの最後まで繰り返すことにより、目的のatomを検索することができる。以上のアクセス方法により、QuickTimeファイル内の任意のatomを検索することが可能となる。

しかしながら、上述した従来の技術においては、データの個数やサイズを表した管理情報によって、後続するデータの管理情報やデータにアクセスするが、光ディスクなどのリムーバブルな記録媒体の場合、記録面にほこりや傷が付着したり、記録中に加わった衝撃などにより、データが誤った箇所へ上書きされることが考えられる。

このような場合、図１７、図１８に示すように、本来登録されているデータと異なった値が管理情報として読み出されてしまい、後続するデータブロックにアクセスすることが不可能となる。

図１７においては、１つのデータブロック内に持っているデータ数を表す管理情報が正しく読み出せなくなり、このデータブロックの終了位置を間違った箇所に示している例である。

これは、データブロックの先頭から登録されている個数分のデータの次に、次のデータブロックが存在し、データの個数を表す値が正しくないと、その誤った個数分を有効なデータであるとして扱うことから、次のデータブロックのヘッダ領域を誤認識してしまうことになり、後続するデータブロックのデータを正しく読み出せないためである。

また、図１８においては、画像データのデータブロックの管理情報であるデータサイズが正しく読み出せなくなったことにより、画像データの途中までをデータブロックの終了位置としている例である。これは、画像データのサイズが正しくないと、後続するデータの読み出し位置が正しくないため、後続するデータを正しく読み出せないことになる。

さらに、図１９に示すように、QuickTimeファイル内のatomのヘッダ情報が正しく読み出せないと、上記と同様に後続するatomのヘッダやデータが正しい値であっても、後続するatomへのアクセスが正しく行えなくなる。

これは、atomのヘッダ情報であるsizeが正しく読み出せなくなることにより、注目しているatomの先頭アドレスから正しくないsizeだけの位置を次のatomのヘッダ情報として扱うためである。

本発明は、上記課題に鑑みてなされたものであり、AVデータの記録・再生に対する不具合を回避することができるデータ記録装置およびデータ再生装置を提供するものである。

本発明に係るデータ記録装置は、
ＡＶデータが格納された少なくとも１つの第１のデータブロックと、該ＡＶデータを再生するための再生情報が格納された少なくとも１つの第２のデータブロックと、オフセットデータブロックとを含んで構成されるファイルを、記録媒体に記録するデータ記録装置において、
上記ファイルにおける、上記第１および第２のデータブロックのうち少なくともいずれかを対象にして、当該対象にしたデータブロックごとに、上記ファイルにおける当該データブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である１つの第１の情報を算出し、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに格納し、
上記ファイルにおける、上記オフセットデータブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報を算出し、上記オフセットデータブロックの最後に格納することを特徴とする。

本発明に係るデータ記録装置は、
ＡＶデータが格納された少なくとも１つの第１のデータブロックと、該ＡＶデータを再生するための再生情報が格納された少なくとも１つの第２のデータブロックと、オフセットデータブロックとを含んで構成されるファイルを、記録媒体に記録するデータ記録装置において、
上記ファイルにおける、上記第１および第２のデータブロックのうち少なくともいずれかを対象にして、当該対象にしたデータブロックごとに、上記ファイルにおける当該データブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である１つの第１の情報を算出し、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに格納し、
上記ファイルにおける、上記オフセットデータブロックのデータサイズを示す第２の情報を算出し、上記オフセットデータブロックの最後に格納することを特徴とする。

本発明に係るデータ記録装置では、さらに、
上記ファイル内の任意の基準位置は、上記ファイルの先頭位置であることが好ましい。

本発明に係るデータ記録装置では、さらに、
上記オフセットデータブロックは、上記ファイルの最後に設けられていることが好ましい。

本発明に係るデータ記録装置では、さらに、
上記対象にしたデータブロックは、上記第２のデータブロックであることが好ましい。

本発明に係るデータ再生装置は、
ＡＶデータが格納された少なくとも１つの第１のデータブロックと、該ＡＶデータを再生するための再生情報が格納された少なくとも１つの第２のデータブロックと、オフセットデータブロックとを含んで構成されるファイルより、上記ＡＶデータおよび上記再生情報を読出し、上記ＡＶデータを再生するデータ再生装置において、
上記ファイルにおける、上記第１および第２のデータブロックのうち少なくともいずれかを対象にして、当該対象にしたデータブロックごとに、上記ファイルにおける当該データブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である１つの第１の情報が、上記ファイルのオフセットデータブロックに格納されており、
上記ファイルにおける、上記オフセットデータブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報が、上記オフセットデータブロックの最後に格納されており、
上記ファイルより上記第２の情報を取得し、
上記取得した上記第２の情報に基づいて、上記第１の情報を取得し、
上記取得した第１の情報に基づき、当該第１の情報に対応する上記対象にしたデータブロックに格納されている上記ＡＶデータまたは上記再生情報を読み出すことを特徴とする。

本発明に係るデータ再生装置は、
ＡＶデータが格納された少なくとも１つの第１のデータブロックと、該ＡＶデータを再生するための再生情報が格納された少なくとも１つの第２のデータブロックと、オフセットデータブロックとを含んで構成されるファイルより、上記ＡＶデータおよび上記再生情報を読出し、上記ＡＶデータを再生するデータ再生装置において、
上記ファイルにおける、上記第１および第２のデータブロックのうち少なくともいずれかを対象にして、当該対象にしたデータブロックごとに、上記ファイルにおける当該データブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である１つの第１の情報が、上記ファイルのオフセットデータブロックに格納されており、
上記ファイルにおける、上記オフセットデータブロックのデータサイズを示す第２の情報が、上記オフセットデータブロックの最後に格納されており、
上記ファイルより上記第２の情報を取得し、
上記取得した上記第２の情報に基づいて、上記第１の情報を取得し、
上記取得した第１の情報に基づき、当該第１の情報に対応する上記対象にしたデータブロックに格納されている上記ＡＶデータまたは上記再生情報を読み出すことを特徴とする。

本発明に係るデータ再生装置では、さらに、
上記ファイル内の任意の基準位置は、上記ファイルの先頭位置であることが好ましい。

本発明に係るデータ再生装置では、さらに、
上記オフセットデータブロックは、上記ファイルの最後に設けられていることが好ましい。

本発明に係るデータ再生装置では、さらに、
上記対象にしたデータブロックは、上記第２のデータブロックであることが好ましい。

本発明によれば、ファイル内の特定のデータブロックに確実にアクセスできる効果を奏する。

本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態における概略構成を示すブロック図である。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態における任意のデータブロックの検索処理を示すフローチャートである。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態におけるオフセットデータブロックをファイルの最後に記録した場合を示す概略説明図である。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態におけるオフセットデータブロックをファイルの最後に記録した場合を示す概略説明図である。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態におけるオフセットデータブロックを用いた任意のデータブロックの検索処理を示すフローチャートである。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態におけるQuickTimeファイル内の任意のatomデータの検索処理を示すフローチャートである。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態におけるQuickTimeファイルの読み出したatomのヘッダ情報が正しい値か否かの検出処理を示すフローチャートである。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態における固定長のoffset atomを示す概略説明図である。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態におけるoffset atomが固定長である場合の任意のatomデータの検索処理を示すフローチャートである。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態における固定長のoffset atomをファイルの最後に記録した場合を示す概略説明図である。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態における可変長のoffset atomをファイルの最後に記録した場合を示す概略説明図である。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態における可変長のoffset atomを示す概略説明図である。 本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態におけるoffset atomが可変長である場合の任意のatomデータの検索処理を示すフローチャートである。 複数のentryを持ち、そのentryの個数を示す管理情報を含んだデータブロックをファイル内に複数記録した場合を示す概略説明図である。 画像データとそのサイズを表す管理情報を含んだデータブロックをファイル内に複数記録した場合を示す概略説明図である。 QuickTimeファイル内のatomデータの構成を示した概略説明図である。 図１４のあるデータブロックの管理情報が読み取り不能となった場合に、後続するデータブロックにアクセスが不可能となることを示す概略説明図である。 図１５のあるデータブロックの管理情報が読み取り不能となった場合に、後続するデータブロックにアクセスが不可能となることを示す概略説明図である。 QuickTimeファイル内のatomデータのヘッダ情報が読み取り不能となった場合に、後続するatomデータにアクセスが不可能となることを示す概略説明図である。

以下、本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置の実施形態について、図１乃至図１３とともに詳細に説明する。

図１は本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置における概略構成を示すブロック図である。図１において、１は記録媒体２へデータの書き込みを行う記録部、２は記録媒体、３は記録媒体２からデータの読み込みを行う再生部、４はデータブロックの管理情報内のデータブロックサイズより後続のデータブロックの位置を求め、データブロックの種類により、任意のデータブロックを検索する通常検索手段である。

５は再生データが正しく再生されているかを検出する再生データ異常検出手段、６はオフセットデータブロックのオフセット値を用いて、データブロックの種類により、任意のデータブロックを検索する異常時検索手段である。

上記のように構成されたデータ記録再生装置においては、入力された記録データをデータブロック単位で記録するため、ファイルをオープンし、記録部１を通して記録媒体２に記録する。このとき、データブロックの管理情報のサイズとして任意の値を格納した上でデータブロックを記録し、データブロックを記録し終えてデータブロックサイズが確定してからデータブロックの管理情報の位置へ移動し、実際のデータブロックサイズを記録する。

ファイル内に任意のデータブロックを記録し終えたら、ファイルをクローズして、記録媒体２への記録を終了する。また、記録データのデータブロックのサイズがメモリ上のサイズからあらかじめ把握できている場合は、初めからデータブロックサイズを正しく付加して記録することにより、図１における記録部１のフィードバック処理は不要となる。

次に、記録媒体２へ記録したファイルを読み出す場合は、再生部３によりファイルをオープンし、データブロックを読み出す。通常検索手段４で読み出したいファイル内のデータブロックを検索する。

ここでは、AVデータを再生するために、AVデータの再生に関する管理情報データブロックを検索し、見つかった場合は、その管理情報データブロックからAVデータが格納されているデータブロックを参照し、AVデータを再生する。

このとき、管理情報データブロックの登録情報にデータ再生時間やAVデータのデータブロックへのオフセット値が、AVデータのデータブロックサイズを越えている場合など矛盾が生じるときや、ユーザーによる再生データの不具合の要求があった場合は、再生データ異常検出手段５により再生データの異常検出が行われる。

そして、異常時検索手段６において、ファイル内の任意の基準位置からファイル内のデータブロックへのオフセット値が格納されているオフセットデータブロックより、そのオフセット値を利用して、AVデータの管理情報のバックアップデータブロックへアクセスし、データの再生を行う。

この場合においても、再生データ異常検出手段５で再生データが異常であると検出された場合はエラーとなる。また、通常検索手段４の検索において、AVデータの再生に関する管理情報データブロックや他のデータブロックが見つからなかった場合は、異常時検索手段６により前述のオフセットデータブロックを用いて、目的のデータブロックを検索する。

このとき、AVデータの再生に関する管理情報データブロックを検索した場合は、その管理情報データブロックからAVデータが格納されているデータブロックを参照し、AVデータを再生する。そして、前述と同じように、再生データ異常検出手段５で再生データの異常検出を行い、不具合が生じた場合は、再度図異常時検索手段６において、オフセットデータブロックからAVデータの管理情報のバックアップデータブロックへアクセスし、データ再生を行う。

さらに、この場合においても、再生データ異常検出手段５で再生データの異常が検出された場合はエラーとなる。そして、記録媒体２からの読み出しが終了したらファイルをクローズする。

ここで、ファイル内にある任意のデータブロックを検索する処理を、図２のフローチャートとともに説明する。まず、ステップＳ８０において、ファイルの先頭位置へ移動し、次にステップＳ８１において、目的のデータブロックをファイル内の位置まで検索するため、現在の位置が目的データブロックの位置であるかの判定を行う。

ステップＳ８１での判定の結果、現在の位置が目的データブロックであった場合は、ステップＳ８２へ進み、目的データブロックにアクセスを行い終了する。ステップＳ８１で現在の位置が目的データブロックでなかった場合は、ステップＳ８３へ進み、現在のデータブロックの先頭に格納されているデータブロックサイズ分だけ移動し、次のデータブロックの先頭位置へ移動する。

そして、ステップＳ８４において、移動した位置がファイル終了位置であるかの判定を行う。ファイルの終了位置かの判定には、ファイルの終了位置を表すEOFを検出することにより、現在のファイル位置がファイルの最後かを判定する。

ファイルの終了位置に到達した場合は、目的データブロックを検索できなかったということになり、ステップＳ８５において、エラーを出力し終了する。移動した位置がファイルの終了位置でなかった場合は、ステップＳ８１に戻り、現在の位置が目的データブロックの位置であるかの判定を行い、ファイルの終了位置へ到達するか、目的データブロックが見つかるまで、これらの処理を繰り返す。

光ディスクを用いたカムコーダなどリムーバブルな記録媒体を用いて、記録・再生を行う場合は、記録面に付着したほこりや傷により、記録されたデータを正しく読み出せなくなる場合がある。また、PCのような据え置き型の機器の場合は、常に固定して設置されているために、PC本体に対し強い衝撃が加わる可能性は低いと考えられるが、前記カムコーダのようなポータブル機器の場合は、手に保持し、走りながら撮影を行ったり、撮影中に物にぶつかることや不注意で機器を落とすなどの強い衝撃が加わる可能性が据え置き型機器に比べ高い。

ポータブル機器において、このような使用環境中では、記録中に機器に衝撃が加わることで書き込みレーザーが振動によりずれ、別のデータ領域に誤って記録してしまうことにより、そのデータ領域が間違ったデータで上書きされることとなり、そのデータ領域を読み出す場合に、正しい値が読み出せなくなる。

このように、データブロックの先頭にあるデータサイズが読み取り不能となったり、正しい値が読み出せない場合、上記通常検索手段４を用いた検索では、このデータブロックを含め、後続するデータブロックを正しく読み出せなくなる。

これは、図１７、図１８とともに上述したように、正しいデータブロックサイズが読み出せないことにより、正しく読み出せないデータブロックの先頭アドレスから間違ったデータサイズだけ移動したファイル位置を次のデータブロックの先頭位置と誤認識するためである。

さらに、その正しく読み出せないデータブロック内や次のデータブロック内のファイル位置を次のデータブロックのサイズ部分とみなし、間違った次のデータサイズだけ読み飛ばすことから、後続する正しいデータブロックが読み出せなくなる。

上述のデータブロックの先頭にあるデータサイズが正しく読み出せない場合に、後続するデータブロックに対しても正しく読み出せないことを回避するため、本発明においては、図３、図４に示すように、ファイルの最後にファイル内の基準となる位置（ファイルの先頭や最後など）から各々のデータブロックの先頭位置へのオフセット値を格納するデータブロック（以下、オフセットデータブロック）を用意する。

ここでは、このオフセットデータブロックをファイルの最後に設けている。これは、データサイズなどの管理情報が正しく読み出せないと、前述の通常検索手段４ではオフセットデータブロック自体も検索できなくなるので、確実にオフセットデータブロックを検索するためである。

すなわち、ファイルシステムの機能であるシークを用いて、ファイルの終了位置へシークする方法や、ファイル終了フラグであるEOFを検出するまで、ファイル内データを次々に読み出していく方法などを用いることにより、ファイルの最後へ移動することは容易であるので、データサイズ情報が正しく読み出せないことに関係なく確実にオフセットデータブロックにアクセスすることが可能となる。
尚、前述の説明では、オフセットデータブロックをファイルの最後に登録することとしているが、ファイルの先頭にオフセットデータブロックを設ける場合は、記録媒体２にデータブロックを保存する際、あらかじめ仮の値の入ったオフセットデータブロックを記録し、その後にデータブロックを保存する。
そして、各々のデータブロックへのオフセット情報が確定した段階でオフセットデータブロックを更新するという方法を用いることにより、ファイルの先頭にオフセットデータブロックを設けることが可能となる。このように、オフセットデータブロックは必ずしもファイルの最後に配置する必要はなく、ファイルの先頭など、任意の決まった位置に設けても、ファイルの先頭と最後との両方に設けても良い。

次に、図３、図４に示すように、オフセットデータブロックをファイルの最後に設定した場合のデータブロックへのアクセス方法を、図５のフローチャートとともに説明する。

まず、ステップＳ９０において、ファイルの任意の基準位置からファイル内のデータブロックへのオフセット値を格納したファイルの最後にあるオフセットデータブロックへアクセスを行うため、ファイルの終了位置へ移動し、ファイルの任意の基準位置からオフセットデータブロックの先頭位置へのオフセット値が格納されているオフセットデータブロックの最後のフィールド情報を取得する。

ここで、ファイルの終了位置へ移動するには、ファイルシステムの機能であるシークを用いて、ファイルの終了位置へシークする方法と、ファイル終了フラグであるEOFを検出するまで、ファイル内データを次々に読み出していく方法とが考えられる。

次に、ステップＳ９１において、任意の基準位置から取得したオフセット値の位置へ移動することにより、オフセットデータブロックの先頭へ移動し、ヘッダ情報を読み飛ばす。そして、ステップＳ９２において、オフセットデータブロックの現在のフィールドが読み出したいデータのオフセット値のフィールドであるかの判定を行う。

現在のフィールドが読み出したいデータのオフセット値のフィールドであった場合は、ステップＳ９３へ進み、そのオフセット値を取得する。そして、ステップＳ９４において、ファイルの任意の基準位置から取得したオフセット値への位置へ移動し、ステップＳ９５で読み出したいデータブロックへアクセスする。

また、ステップＳ９２での判定結果が現在のフィールドが読み出したいデータのオフセット値のフィールドでなかった場合は、ステップＳ９６へ進み、次のフィールド情報へ移動する。

そして、ステップＳ９７にて、ステップＳ９６で移動した位置がファイルの終わりを示すEOFを検出した場合は、ステップＳ９８へ進み、読み出したいデータブロックへのオフセット値が格納されていなかったことになり、エラーを出力し終了する。

ステップＳ９７で現在のファイル位置がファイルの終了でなかった場合には、ステップＳ９２へ戻り、読み出したいデータブロックへのオフセットのフィールドが見つかるかファイルの終了位置へ到達するまで、上述の処理を繰り返す。

次に、AVファイルフォーマットの１つであるQuickTimeファイルにおいて、ファイル内の任意のatomを検索する処理の流れを、図６のフローチャートを用いて説明する。まず、ステップＳ２０において、現在のファイル位置をファイルの先頭に設定し、ステップＳ２１において、現在のファイル位置から８バイトのデータであるatomヘッダを読み出す。

そして、ステップＳ２２において、読み出したヘッダの後半部の４バイトであるatomの種類が目的のatomであるか判定する。例えば、moov atom内に存在し、音声や画像などを再生するために必要な情報を保持しているTrack header atomを検索する場合は、読み出したヘッダの後半部４バイトが"tkhd"のASCIIコードであるかを判定する。 もし、目的のatomであった場合は、ステップＳ２６へ進み、目的atomデータへアクセスを行い終了する。しかし、目的のatomでなかった場合は、ステップＳ２３へ進み、ステップＳ２１で取得した８バイトの前半部４バイトであるatomのデータサイズだけ現在の位置から読み飛ばし、読み飛ばし後の位置を現在のファイル位置に設定する。

例えば、ファイルシステムの機能を利用して、atomのデータサイズ分だけ現在位置からシークすることで移動が可能となる。ステップＳ２４において、ステップＳ２３で読み飛ばした結果、ファイルの終了位置を表すEOFを検出することにより、現在のファイル位置がファイルの最後かを判定する。

現在のファイル位置がファイルの最後であった場合は、目的のatomが検索ファイル内に見つからなかったこととなり、ステップＳ２５により、エラー処理を行い検索を終了する。

現在のファイル位置がファイルの最後でなかった場合は、ステップＳ２１へ戻り、現在のファイル位置から８バイトのデータであるatomヘッダを読み出す。そして、ステップＳ２２に進み、ファイルの最後までの範囲を目的のatomが見つかるまで上述の検索処理を繰り返す。

前述したカムコーダの例のような場合に、atomのヘッダ部分の読み取り不能が生じると、上記通常検索手段４では、正しくないヘッダ情報を読み込んだことになり、それ以降のatomへのアクセスが不可能となる。

これは、図１５とともに上述したように、moov atomのsize情報が正しく読み出せない場合、moov atomの途中のファイル位置を終了位置とみなし、正しくないmoov atomの終了位置の次の８バイトをいくつかのAVデータが記録されているmdat atomのヘッダ領域と把握するためである。

そのため、mdat atomのヘッダ情報が正しい値としても、moov atomからmdat atomへアクセスに行くことが不可能であるため、後続するatomへアクセスができない。

このように、正しくないatomのヘッダ情報を読み込んだ場合、正しいatomのsizeとtypeが読み出せなくなることにより、atomの種類を誤認識し、さらにatomの先頭アドレスから間違ったsizeだけ移動したファイル位置を次のatomのヘッダ情報と誤認識することから、そのatom内や次のatom内である正しいヘッダ情報でないファイル位置を次のatomのヘッダ部分とみなし、次のatomの種類についても誤認識を行い、間違った次のatomのサイズだけシークするために、後続するatomデータが問題ない場合であっても、読み出せなくなるわけである。

読み出したatomのヘッダ情報が正しい値でないことを検出する方法について説明する。これは、図６におけるステップＳ２２の直前に、図７に示すフローチャートの検出処理を付加することにより、ヘッダ情報が正しい値であるという検出を付加した検索処理が可能となる。

取得したatomヘッダ情報の先頭４バイトであるatomのsizeが現在のQuickTimeファイルサイズより大きいか、または負の値など明らかに正しくない値を示している場合は、正しいatomのsizeとみなさずヘッダが正しい値でないと判断するため、図７におけるステップＳ５０において、atom sizeがヘッダ情報領域サイズである８以上か、ファイルサイズ以下かの判定を行っている。

atom sizeがこの範囲外の値であった場合は、ステップＳ５２へ進みエラー処理を行い、検索を終了する。この場合は、後述するatomの復旧処理を行うことにより、atomデータの復旧およびアクセスが可能となる。atomのsizeが正しい値を示しているならば、ステップＳ５１に進み、後続する４バイトであるatomのtypeがアルファベット、数字、記号などのASCIIコードである４バイトの文字列であるかの判定を行う。

この条件を満たさない場合は、ヘッダ情報が正しく読み出せないと判断し、ステップＳ５２へ進みエラー処理を行い、検索を終了する。ステップＳ５１の条件を満たし、正しいatomのtypeであった場合は、正しいatomのヘッダ情報が取得できたこととなり、図６におけるステップＳ２２以降の処理を行うことにより、目的のatomを検索する。

以上のように、正しく読み出せないヘッダ情報を含んでいるQuickTimeファイルを再生した場合、atom検索において必要なatomが見つからなかったり、再生に必要な正しいデータを取得できないことから、再生システムがエラーを発生するか、再生している映像や音声に不具合が生じ、ユーザーが正しくないＡＶデータを再生していると判断することになる。この場合は、ユーザーが後述する復旧処理を選択することにより、正しく読み出せないatomを復旧させることが可能となる。

以上のように、atomのヘッダ情報が正しく読み出せない場合、そのQuickTimeファイルを正しく再生できなくなるという不具合が生じる。これを回避する方法について説明する。

再生を行うシステムが前述の通常検索手段４により、atomヘッダのsizeを正しく読み出せないと検出した場合は、目的のatomのtypeをQuickTimeファイルの先頭より、１バイトづつ検索していき、目的のatomのtypeのASCIIコードがファイル内で見つかるまで検索するという手法が考えられる。

しかしながら、これはQuickTimeファイルを１バイトづつ比較するため、検索速度が遅く効率が悪い。また、必ずしも目的のatomのヘッダ情報中のtypeを検索できるとは限らず、偶然にatom中のデータ領域に存在するatom typeと同じASCIIコードを持つデータを検索してしまうことが考えられる。さらに、atomヘッダ情報のtypeが正しく読み出せない場合は、検索する手段を失う。

このため、本発明においては、以下に説明する手法をQuickTimeファイルに適用する。QuickTimeファイルを記録媒体に記録するときに、ファイルの最後に前述のオフセットデータブロックに相当するoffset atomと呼ばれる管理情報を記録する。

このoffset atomは、ファイル内の基準アドレス（ファイルの先頭、最後やoffset atomの先頭アドレスなどファイル内の任意の箇所で良い）から想定するatomの先頭アドレスへのオフセット値を、図８に示すように管理している。

図８の例では、オフセット値を管理するatomとして、offset atomのsize、offset atomの種類であるtype、moov atomへのオフセット値、mdat atomへのオフセット値、moov atomのコピーであるバックアップmoov atomへのオフセット値の順番により、４バイト単位で格納するものである。

図８のoffset atomのヘッダ情報をぬかした１つ目のフィールドは、ファイル内の基準アドレスからmoov atomの先頭アドレスまでのオフセット値を格納する。２つ目のフィールドには、同様にmdat atomまでのオフセット値を格納する。さらに、３つ目のフィールドには、バックアップmoov atomまでのオフセット値を格納する。

尚、オフセット値を管理するatomは、これらのatomに限定されるものではなく、必要に応じて設定することが可能である。バックアップmoov atomについての詳細な説明は後述する。

atomのヘッダ情報であるsizeが正しく読み出せない場合は、それ以降のatomの検索が不可能であるというのは、前述した通りであるが、ヘッダ情報が正しく読み出せないと前述の通常検索手段４では、offset atom自体も検索することができなくなる。

そのため、確実にoffset atomを検索するために、offset atomをQuickTimeファイルの最後のatomとして登録する。これは、ファイルの最後の位置へ移動することが容易であることから、ヘッダ情報が正しく読み出せないことに関係なく、確実にoffset atomにアクセス可能とするためである。

また、前述の説明では、offset atomをファイルの最後に設けるとしているが、ファイルの先頭にoffset atomを設ける場合は、記録媒体２にatomデータを保存する際、あらかじめ仮の値の入ったoffset atomを記録し、その後にatomデータ（moovやmdat atomなど）を保存する。

そして、各々のatomデータへのオフセット情報が確定した段階でoffset atomを更新するという方法を用いることにより、ファイルの先頭にoffset atomを設けることが可能となる。このように、offset atomは必ずしもファイルの最後におく必要はなく、ファイルの先頭など任意の決まった位置に設けたり、ファイルの先頭と最後との両方に設けても良い。

atomのヘッダ情報が正しく読み出せない場合は、目的のatomを検索するために、ファイルの終了位置にあるoffset atomへアクセスするため、図９に示すフローチャートの検索処理を行う。

ステップＳ３０において、QuickTimeファイルの終了位置へ移動し、その位置からファイルの先頭側へoffset atomの大きさである２０バイトのアドレスへ移動する。この位置がoffset atomが存在する場合のoffset atomの先頭位置となる。

そして、ステップＳ３１において、そのアドレスから8byteのヘッダ情報を取得する。取得したヘッダ情報が正しいoffset atomであるかの判定を行うため、ステップＳ３２において、ヘッダ情報の先頭４バイトの内容がoffset atomのsizeを示す"20"であり、後続する４バイトの内容がoffset atomのtypeを示す"ofst"であるかの判定を行う。

正しいoffset atomのヘッダでなかった場合は、ステップＳ４１に進みエラー処理を行って終了する。正しいoffset atomのヘッダであった場合は、ステップＳ３３へ進む。ここで、moov atomを検索する場合は、ステップＳ３４へ進み、offset atomの先頭から８バイトの位置へ移動し、この位置より４バイトのデータを取得して、ステップＳ３９へ進む。

また、ステップＳ３３において、他のatomを検索する場合は、ステップＳ３５へ進み、ここでmdat atomを検索する場合は、ステップＳ３６へ進み、offset atomの先頭から１２バイトの位置へ移動し、この位置より４バイトのデータを取得して、ステップＳ３９へ進む。

さらに、ステップＳ３５において、他のatomを検索する場合は、ステップＳ３７へ進み、ここでバックアップmoov atomを検索する場合は、ステップＳ３８へ進み、offset atomの先頭から１６バイトの位置へ移動し、この位置より４バイトのデータを取得して、ステップＳ３９へ進む。

ステップＳ３７で他のatomを検索する場合は、QuickTimeファイル内に登録されていないatomデータを検索しようとしたことになり、ステップＳ４１へ進み、エラー処理を行って終了する。

ステップＳ３４、Ｓ３６、Ｓ３８の処理後に、ステップＳ３９へ進んだ場合、ファイル内の任意の基準位置から取得したオフセット位置へ移動する。そして、ステップＳ４０において、移動した位置より目的のatomのデータへアクセスする。

QuickTime Fileでは、AVデータを再生するために、再生の順番や同期制御、長さ、各素材データの情報などを管理するmoov atomが存在する。そして、このmoov atomは、様々なAVデータをまとめて格納しているmdat atom内のデータの位置やサイズを管理している。

もし、前記atomヘッダが正しく読み出せないことと同様に、moov atom内データの読み取り不能が生じると、このmoov atomのデータを正しく読み出せなくなることから、再生の順番や長さなどを管理している情報や、mdat atom内に格納されている様々な素材データを表すオフセット値も正しく把握できなくなり、正しい再生が行われなくなる。

これは、光ディスクを用いたリムーバブルなカムコーダで大事なイベントなどの撮影を行う場合、ディスクの記録面に付着したほこりや傷、および撮影時の振動などにより、記録した大切な撮影データを読み出せなくなる場合などに生じる。

このような問題が生じる可能性を低くするために、管理情報のバックアップを用意する必要性が高い。また、オリジナルのmoov atomとバックアップのmoov atomとの記録媒体中の記録されている距離が近いと、オリジナルのmoov atomが読み出せなくなった場合に、バックアップのmoov atomも読み出せなくなる可能性が高い。

これは、例えば光ディスク等が傷により損傷を受けた場合、データサイズが小さいQuickTimeファイルであると、オリジナルとバックアップのmoov atomの両方が読み出せなくなるということである。しかし、記録しているAVデータがMPEGストリームなどの動画データの場合、例えば１時間分のデータサイズは、ビットレートが８Mbpsであると、約３．５Ｇバイトものデータサイズとなる。

図１０に示すように、moov atom、mdat atom、バックアップmoov atomの順番で記録した場合は、mdat atomのサイズが３．５Ｇバイトのサイズになると、オリジナルとバックアップのmoov atomが共に損傷を受ける可能性は低いことから、バックアップmoov atomをQuickTimeファイル内に設けても、オリジナルのバックアップとしての機能を果たす可能性は高い。

上述のことから、mdat atom内の素材データやAVデータが正しくファイルに存在しているにもかかわらず、moov atomの破損により再生が正しく行われないことを回避するために、図１０の例では、mdat atomの次にmoov atomのコピーをバックアップとして、QuickTimeファイル内に追加する。

再生に関する管理情報を二重化して登録することで、元のmoov atomが破損を受けた場合であっても、バックアップのmoov atomにアクセスすることにより、正しい再生を可能とし、さらに、破損したmoov atomを復旧させることが可能となる。

ただし、バックアップmoov atomを記録したとしても、前述のように、このバックアップmoov atomにアクセスするまでの間にatomのsize情報が正しく読み出せない場合、結局バックアップmoov atomへアクセスできなくなる。

そこで、前述したように、そのmoovのバックアップの位置情報もoffset atom内に登録する。これは、バックアップmoov atomを登録する時に、図１１に示すように、ファイル内の任意の基準位置からバックアップmoov atomの先頭位置までのオフセット値を、前述の図８に示したoffset atomの最後の４バイトに登録する。

このバックアップmoov atomを登録するのと同様に、QuickTimeファイルフォーマット以外のファイルフォーマットを用いた場合でも、データの管理情報が存在する場合は、この管理情報のコピーをバックアップとして、ファイル内の任意の場所へ登録し、その位置をoffset atomに相当する情報で管理しても良い。

moov atomデータが正しいデータでないことを検出する方法として、前述のatomヘッダ情報が正しくないことを検出する方法の他に、以下に挙げる手法がある。これは、システムの検出によるものと、ユーザーによるものとが挙げられる。

システムの検出によるものは、moov atomで管理されている情報のうち、全体の再生時間よりも、あるtrackの再生時間が長い時やmdat atomデータ内の参照を表すオフセット値やサイズがmdat atomデータサイズを超えてしまっている時などのように管理情報のつじつまが合わなくなり、システムよりエラーが生じた場合である。

一方、ユーザーの検出によるものは、再生している映像や音声に不具合を感じた時に、ユーザーがQuickTimeファイルが損傷していると判断し、その旨をシステムに伝えることにより検出される。

前述のmoov atomが正しいデータでないと検出された場合の処理について説明する。atomのヘッダ情報が正しく読めない場合や、moov atomが正しいデータでないと検出された場合は、QuickTimeファイルの最後にあるoffset atomを用いて前述の異常時検索手段６により、バックアップのmoov atomへアクセスを行う。

これをAVデータの管理情報として、AVデータの再生を行う。ここで、バックアップのmoov atomを用いた場合でも、この管理情報が正しいデータでないと検出された場合は、mdat atomデータが正しく読み出せないか、オリジナルとバックアップのmoov atomが共に正しいデータでないことが考えられる。

また、moov atomが正しいデータでないと検出され、バックアップmoov atomを検索する場合、図６とともに上述したatomの検索方法を用いて、ファイルの先頭から後続するatomを順に検索していき、バックアップmoov atomが見つかるまでQuickTimeファイル内を検索しても良い。

moov atomが正しいデータでないと検出された場合は、正しいデータでないmoov atomを復旧する処理を行っても良い。これは、前述のバックアップmoov atomをoffset atomの情報により検索してアクセスを行い、バックアップmoov atomに対して異常がないかを検出するか、バックアップmoov atomによりAVデータを再生し、異常がないことを確認する。

問題がなければ、offset atomによる異常時検索手段６により、異常のあるmoov atomの位置を検索し、バックアップmoov atomの内容をmoov atomの先頭へコピーすることにより、異常のあったオリジナルのmoov atomを復旧させる。

また、前述のatomヘッダのsize情報のみが正しく読み出せない場合は、offsetatomのオフセット値を用いて、正しく読み出せないヘッダ情報を持つatomと後続するatomのオフセット値の差より、正しく読み出せないヘッダ情報を持つatomのサイズを算出し、offset atomが指している正しく読み出せないヘッダ情報を持つatomの先頭アドレスへこのサイズとatomの種類を８バイト書き込むことにより、正しく読み出せないヘッダ情報を持つatomのヘッダ情報を復旧させることが可能である。

さらに、atomヘッダのatomの種類のみが破損している場合は、offset atomのオフセット値を用いて、該atomヘッダの位置にアクセスし、検索しようとしたatomの種類を破損したatomの種類とみなして、該atomヘッダの後半４バイトに書き込むことにより、破損したatomの種類を持つatomのヘッダ情報を復旧させることができる。

moov atomのバックアップ情報をファイル内に設ける方法は、QuickTimeファイルに限定したものではなく、他のファイルフォーマットにおいてもデータのバックアップを有する場合は、データのバックアップを保持し、ファイルの最後にこのバックアップ情報へのオフセット値を保持することによって、バックアップデータへアクセスが可能となり、元のデータの復旧も行うことが可能となる。

QuickTime File内に格納するatomは、前述のように、moov atom、mdat atom、バックアップmoov atomだけではなく、様々な種類が存在する。よって、固定個数のatomのoffset情報ではなく、任意の個数のoffset情報を管理したい場合が考えられる。

前述のoffset atomでは、atomのsizeが固定長であるため、想定するatom以外は管理することができない。そのため、ファイルの最後に記録するoffset atomを、図１２に示すように規定する。

この場合のoffset atomは、atom sizeを可変長とし、ヘッダ領域に後続して、ファイル内に登録されているatomの数だけのファイルの任意の基準位置からのオフセット値をフィールドにもつ。

図１２の例では、ヘッダ情報に後続してバックアップmoov atomへのオフセット値をフィールドに持ち、いくつかのファイル内atomへのオフセット値のフィールドが格納された後、mdat atom、moov atomのオフセット値を格納している。

そしてまた、いくつかのファイル内atomへのオフセット値をフィールドに持ち、最後にoffset atom自身へのオフセット値を格納している。さらに、QuickTimeのatomは入れ子の形態もとることができるため、atom内部にあるatomに対してもオフセット値を登録して良い。

offset atomに登録するフィールドを全て登録し終えたら、後続する４バイト（offset atomの最後の４バイト。この４バイトを書き終えるとファイルエンドとなる）にoffset atomへの基準アドレスからのオフセット値を格納する。

尚、offset atomの最後の４バイトとして、offset atomへの基準アドレスからのオフセット値ではなく、offset atomのsizeであるatom sizeを格納しても良い。このoffset atomを用いて、ファイル内に任意の個数のatomの位置情報を登録することが可能となる。

前述の決まったatomのoffset情報を管理するoffset atomの場合と異なり、本発明では、offset情報だけではどのatomの情報を管理しているかが分からない。このような場合のoffset atomから目的のatomにアクセスする方法を、図１３のフローチャートを用いて説明する。尚、この図１３では、offset atomの最後の４バイトとして、offset atomへの基準アドレスからのオフセット値が格納された場合を示している。

ステップＳ６０において、ファイルの終了位置へ移動し、ファイルの終了部分の４バイトのデータを取得する。この値は、offset atomの先頭アドレスへの任意の基準位置からのオフセット値である。

そこで、ステップＳ６１において、ファイル内の任意の基準位置から取得したオフセットのアドレスへ移動することにより、offset atomの先頭へ移動したことになる。

ステップＳ６２において、現在のアドレスから８バイトのデータであるoffsetatomのヘッダ情報を取得する。ステップＳ６３にて、取得したヘッダ情報の先頭４バイトの値がファイルサイズからoffset atomの先頭位置を引いた値（offset atomのsizeの計算値）と一致し、後続する４バイトのtypeがoffset atomの種類を示す"ofst"であるとき、取得したヘッダ情報がoffset atomであると判定する。

offset atomと判定されなかった場合は、ステップＳ７０へ進みエラー処理をして終了する。offset atomと判定された場合は、ステップＳ６４へ進み、現在のアドレスがoffset atomのフィールド情報の最後でないかの判定を行う。

現在のアドレスが最後のアドレス（offset atomへのオフセット値が格納されているアドレス）であった場合は、目的のatomが見つからなかったことになり、ステップＳ７０へ進みエラー処理をして終了する。そうでなかった場合は、ステップＳ６５へ進み、現在のアドレスから４バイトのオフセット値を取得し、任意の基準位置からオフセット値のアドレスへ移動する。

次に、ステップＳ６６において、移動したアドレスより８バイトのヘッダ情報を取得する。そして、ステップＳ６７において、ヘッダ情報の後半４byteのtype情報が目的のatomのtype情報であるかASCIIコードの比較を行い、目的のatomであった場合は、ステップＳ６８により、目的atomへアクセスを行って終了する。

目的atomでなかった場合は、ステップＳ６９にて現在のアドレスに４を加えて、次のオフセットのフィールド情報の位置に移動し、ステップＳ６４へ戻り、目的atomが見つかるまでかoffset atomの終了位置まで前記処理を繰り返して、目的atomを検索する。

また、前記検索の場合、オリジナルのmoov atomとバックアップのmoov atomのtypeを違う名前にしてあれば良いが、そうでない場合は区別がつかなくなるため、バックアップ情報のオフセット値は、offset atom内の任意の場所に規定して登録するようにする。例えば、offset atomの先頭や最後のフィールドにバックアップデータへのオフセット値を格納する（図１１、図１２では、offset atomの先頭フィールドに設定している）。

ファイルの最後の位置へ移動することは、容易であることから、offset atomの登録する位置は、QuickTimeファイルの最後のatomとして登録した方が、確実にoffset atomにアクセスすることが可能となる。しかし、offset atomはファイルの最後におく必要はなく、offset atomへのアクセスする手段さえ存在すれば、ファイルの先頭などの任意の位置でも良い。さらに、当該ファイル内ではなく、任意の場所に登録するようにしても良い。

以上詳述したように、あるまとまったデータにそのデータのサイズなどを表す管理情報を付加したデータブロックが記録媒体内のファイル内に１つ以上記録されている場合に、ファイル内のどこかのデータブロックの管理情報が読み取り不能となると、後続するデータブロックにアクセスできなくなる。

そのため、本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置においては、確実にアクセス可能なファイル内の最後の位置に、各々のデータブロックへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録するオフセットデータブロックを設けることにより、確実に全てのデータブロックやデータブロックのバックアップへのアクセスが可能となり、読み取り不能となったデータブロックに後続するデータブロックにアクセスできないといった問題を解決することができる。

また、QuickTimeファイルでは、AVデータの記録・再生を管理しているmoov atom内のデータが読み取り不能となった場合、AVデータを正しく記録・再生ができなくなる。

このために、moov atomのコピーをバックアップmoov atomとして、ファイル内に設けることにより、この問題を解決することができるが、前記と同様に、バックアップmoov atomまでに存在するatomのヘッダ情報が読み取り不能となると、バックアップmoov atomへアクセスができなくなる。

そのため、本発明のデータ記録装置およびデータ再生装置を兼ね備えたデータ記録再生装置においては、バックアップmoov atomへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録するoffset atomを設けることにより、確実にバックアップmoov atomへアクセスが可能となり、AVデータの記録・再生に対する不具合が生じる問題を抑制することが可能となる。

尚、本発明は、QuickTimeファイル以外のファイルフォーマットにおいても、ファイルの最後か任意の場所にoffsetを表すデータ領域を設けることで適用可能であり、そのoffsetを表すデータ領域へのオフセット値をファイル内の任意の箇所に格納すれば良い。

また、QuickTimeファイル以外のファイルフォーマットにおいても、AVデータの管理情報のバックアップが登録されている場合、offsetを表すデータ領域から、オリジナルのAVデータの管理情報を復旧させることができ、さらには、データブロックの管理情報（データ長や種類）を、offsetを表すデータを用いて復旧させることが可能であることは明らかである。

１ 記録部
２ 記録媒体
３ 再生部
４ 通常検索手段
５ 再生データ異常検出手段
６ 異常時検索手段

Claims (10)

1. ＡＶデータが格納された少なくとも１つの第１のデータブロックと、該ＡＶデータを再生するための再生情報が格納された少なくとも１つの第２のデータブロックと、オフセットデータブロックとを含んで構成されるファイルを、記録媒体に記録するデータ記録装置において、
   上記ファイルにおける、上記第１および第２のデータブロックのうち少なくともいずれかを対象にして、当該対象にしたデータブロックごとに、上記ファイルにおける当該データブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である１つの第１の情報を算出し、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに格納し、
   上記ファイルにおける、上記オフセットデータブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報を算出し、上記オフセットデータブロックの最後に格納することを特徴とする、データ記録装置。
2. ＡＶデータが格納された少なくとも１つの第１のデータブロックと、該ＡＶデータを再生するための再生情報が格納された少なくとも１つの第２のデータブロックと、オフセットデータブロックとを含んで構成されるファイルを、記録媒体に記録するデータ記録装置において、
   上記ファイルにおける、上記第１および第２のデータブロックのうち少なくともいずれかを対象にして、当該対象にしたデータブロックごとに、上記ファイルにおける当該データブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である１つの第１の情報を算出し、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに格納し、
   上記ファイルにおける、上記オフセットデータブロックのデータサイズを示す第２の情報を算出し、上記オフセットデータブロックの最後に格納することを特徴とする、データ記録装置。
3. 上記ファイル内の任意の基準位置は、上記ファイルの先頭位置であることを特徴とする請求項１または２に記載のデータ記録装置。
4. 上記オフセットデータブロックは、上記ファイルの最後に設けられていることを特徴とする請求項１〜３のいずれか１項に記載のデータ記録装置。
5. 上記対象にしたデータブロックは、上記第２のデータブロックであることを特徴とする請求項１〜４に記載のデータ記録装置。
6. ＡＶデータが格納された少なくとも１つの第１のデータブロックと、該ＡＶデータを再生するための再生情報が格納された少なくとも１つの第２のデータブロックと、オフセットデータブロックとを含んで構成されるファイルより、上記ＡＶデータおよび上記再生情報を読出し、上記ＡＶデータを再生するデータ再生装置において、
   上記ファイルにおける、上記第１および第２のデータブロックのうち少なくともいずれかを対象にして、当該対象にしたデータブロックごとに、上記ファイルにおける当該データブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である１つの第１の情報が、上記ファイルの上記オフセットデータブロックに格納されており、
   上記ファイルにおける、上記オフセットデータブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報が、上記オフセットデータブロックの最後に格納されており、
   上記ファイルより上記第２の情報を取得し、
   上記取得した上記第２の情報に基づいて、上記第１の情報を取得し、
   上記取得した第１の情報に基づき、当該第１の情報に対応する上記対象にしたデータブロックに格納されている上記ＡＶデータまたは上記再生情報を読み出すことを特徴とする、データ再生装置。
7. ＡＶデータが格納された少なくとも１つの第１のデータブロックと、該ＡＶデータを再生するための再生情報が格納された少なくとも１つの第２のデータブロックと、オフセットデータブロックとを含んで構成されるファイルより、上記ＡＶデータおよび上記再生情報を読出し、上記ＡＶデータを再生するデータ再生装置において、
   上記ファイルにおける、上記第１および第２のデータブロックのうち少なくともいずれかを対象にして、当該対象にしたデータブロックごとに、上記ファイルにおける当該データブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である１つの第１の情報が、上記ファイルの上記オフセットデータブロックに格納されており、
   上記ファイルにおける、上記オフセットデータブロックのデータサイズを示す第２の情報が、上記オフセットデータブロックの最後に格納されており、
   上記ファイルより上記第２の情報を取得し、
   上記取得した上記第２の情報に基づいて、上記第１の情報を取得し、
   上記取得した第１の情報に基づき、当該第１の情報に対応する上記対象にしたデータブロックに格納されている上記ＡＶデータまたは上記再生情報を読み出すことを特徴とする、データ再生装置。
8. 上記ファイル内の任意の基準位置は、上記ファイルの先頭位置であることを特徴とする請求項６または７に記載のデータ再生装置。
9. 上記オフセットデータブロックは、上記ファイルの最後に設けられていることを特徴とする請求項６〜８のいずれか１項に記載のデータ再生装置。
10. 上記対象にしたデータブロックは、上記第２のデータブロックであることを特徴とする請求項６〜９のいずれか１項に記載のデータ再生装置。
    

Images