データ記録装置およびデータ再生装置
【課題】確実に全てのデータブロックへのアクセスが可能となり、読み取り不能となったデータブロックに後続するデータブロックにアクセスすること。
【解決手段】データ及び該データのサイズや個数、種類などの管理情報からなるデータブロック単位で様々なデータが登録されたファイルを記録媒体２に記録する記録部１と、前記データブロック中の管理情報内のデータサイズに基づき、後続するデータブロックの先頭位置を得て、後続するデータブロックを読み出す再生部３と、前記再生部３により読み出されたデータブロック中の管理情報内のデータ種類に基づき、ファイル内のデータブロックを検索する通常検索手段４とを備えたデータ記録再生装置において、前記ファイル内の任意の基準位置から該ファイル内に含まれるいくつかのデータブロックの先頭位置へのオフセット値が登録されたオフセットデータブロックをファイルの任意の位置に登録したものである。
【解決手段】データ及び該データのサイズや個数、種類などの管理情報からなるデータブロック単位で様々なデータが登録されたファイルを記録媒体２に記録する記録部１と、前記データブロック中の管理情報内のデータサイズに基づき、後続するデータブロックの先頭位置を得て、後続するデータブロックを読み出す再生部３と、前記再生部３により読み出されたデータブロック中の管理情報内のデータ種類に基づき、ファイル内のデータブロックを検索する通常検索手段４とを備えたデータ記録再生装置において、前記ファイル内の任意の基準位置から該ファイル内に含まれるいくつかのデータブロックの先頭位置へのオフセット値が登録されたオフセットデータブロックをファイルの任意の位置に登録したものである。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データブロック単位で様々なデータが登録されたファイルを読み書きする記録媒体用のデータ記録再生装置に関するものである。
【背景技術】
【０００２】
様々なデータを記録媒体に記録、ネットワークを介した転送、配信などを行う場合、データそのものとそのデータがどのようなデータであるか、またはそのデータにアクセスするために、全データ中のどこにどのような形態で存在しているかを表す、そのデータを管理する管理情報が必要となる。
【０００３】
管理情報には、例えば図１８に示すように、記録されたデータのファイル名を管理することを目的として、１つの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データの管理情報のバックアップデータブロックへアクセスすることを可能とし、AVデータの記録・再生に対する不具合を回避することができるデータ記録再生装置を提供するものである。
【課題を解決するための手段】
【００２２】
本願の第１の発明は、データ及び該データのサイズや個数、種類を含む管理情報からなるデータブロック単位で、各種データが登録されたファイルを記録媒体に記録する記録手段と、前記データブロック中の管理情報内のデータサイズに基づき、後続するデータブロックの先頭位置を得て、後続するデータブロックを読み出す再生手段と、前記再生手段により読み出されたデータブロック中の管理情報内のデータ種類に基づき、ファイル内のデータブロックを検索する検索手段とを備えたデータ記録再生装置において、前記ファイル内の任意の基準位置から該ファイル内に含まれるいくつかのデータブロックの先頭位置へのオフセット値が登録されたオフセットデータブロックをファイルの任意の位置に登録したことを特徴とする。
【００２３】
本願の第２の発明は、前記オフセットデータブロックのサイズが固定長であることを特徴とする。
【００２４】
本願の第３の発明は、前記オフセットデータブロックのサイズが可変長であることを特徴とする。
【００２５】
本願の第４の発明は、前記データブロックが、AVデータが登録されているデータブロックと、そのAVデータのデータブロックの記録・再生の形態を管理する管理情報が登録されているデータブロックとを含むことを特徴とする。
【００２６】
本願の第５の発明は、前記AVデータの管理情報が登録されているデータブロックのコピーを、バックアップとしてファイル内に登録するとともに、ファイル内の任意の基準位置からこの管理情報のバックアップのデータブロックへのオフセット値を前記オフセットデータブロックへ登録することを特徴とする。
【００２７】
本願の第６の発明は、前記再生手段により読み出された再生データの異常を検出する異常検出手段と、前記異常検出手段により再生データの異常が検出された時、前記オフセットデータブロックに登録されたオフセット値に基づき、任意のデータブロックを検索する異常時検索手段とを備えたことを特徴とする。
【００２８】
本願の第７の発明は、前記異常検出手段によりAVデータの管理情報が登録されているオリジナルのデータブロックに異常が検出された時、前記異常時検索手段が、前記オフセットデータブロックに登録されたオフセット値に基づき、該AVデータの管理情報が登録されているバックアップのデータブロックを検索し、この管理情報のバックアップのデータブロックに基づいて、AVデータを再生することを特徴とする。
【００２９】
本願の第８の発明は、前記AVデータの管理情報が登録されているバックアップのデータブロックを用いて、前記異常が検出されたAVデータの管理情報が登録されているオリジナルのデータブロックを復旧することを特徴とする。
【００３０】
本願の第９の発明は、前記異常検出手段によりデータブロックの管理情報に異常が検出された時、前記異常時検索手段が、前記オフセットデータブロックに登録されたオフセット値を用いて、前記異常が検出されたデータブロックの管理情報を復旧させることを特徴とする。
【００３１】
本願の第１０の発明は、データ及び該データのサイズや個数、種類を含む管理情報からなるデータブロック単位で、各種データが登録されたファイルを記録媒体に記録する記録手段と、前記データブロック中の管理情報内のデータサイズに基づき、後続するデータブロックの先頭位置を得て、後続するデータブロックを読み出す再生手段と、前記再生手段により読み出されたデータブロック中の管理情報内のデータ種類に基づき、ファイル内のデータブロックを検索する通常検索手段とを備えたデータ記録再生装置において、前記ファイル外に存在するデータの所在が登録された外部参照データブロックをファイルの任意の位置に登録したことを特徴とする。
【００３２】
本願の第１１の発明は、前記データブロックが、AVデータが登録されているデータブロックと、そのAVデータのデータブロックの記録・再生の形態を管理する管理情報が登録されているデータブロックとを含むことを特徴とする。
【００３３】
本願の第１２の発明は、前記AVデータの管理情報が登録されているデータブロックのコピーを、バックアップとしてファイル外に登録するとともに、この管理情報のバックアップのデータブロックの所在を前記外部参照データブロックへ登録することを特徴とする。
【発明の効果】
【００３４】
本発明によれば、各々のデータブロックへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録したオフセットデータブロックを設けているので、確実に全てのデータブロックへのアクセスが可能となり、読み取り不能となったデータブロックに後続するデータブロックにアクセスすることが可能となる。
【００３５】
また、AVデータの管理情報のデータブロックのコピーを、バックアップデータブロックとしてファイル内に設けるとともに、ファイル内の任意の基準位置からこのバックアップデータブロックの先頭位置へのオフセット値を登録したオフセットデータブロックを設ける、或いは、このバックアップデータブロックをこのファイルとは別の外部データ内に設けるとともに、この外部データの所在を示すデータブロックを設けることで、確実にAVデータの管理情報のバックアップデータブロックへアクセスが可能となり、AVデータの記録・再生に対する不具合を回避することができる。
【００３６】
さらに、オリジナルのAVデータの管理情報データブロックの破損が検出された場合は、バックアップのAVデータの管理情報データブロックをオリジナルの管理情報データブロックへコピーすることにより、前記破損したAVデータの管理情報データブロックを復旧させることができる。また、データブロックの管理情報の破損が検出された場合も、オフセットデータブロックのオフセット値を用いて、前記破損したデータブロックの管理情報を復旧させることができる。
【図面の簡単な説明】
【００３７】
【図１】本発明のデータ記録再生装置の実施形態における概略構成を示すブロック図である。
【図２】本発明のデータ記録再生装置の実施形態における任意のデータブロックの検索処理を示すフローチャートである。
【図３】本発明のデータ記録再生装置の実施形態におけるオフセットデータブロックをファイルの最後に記録した場合を示す概略説明図である。
【図４】本発明のデータ記録再生装置の実施形態におけるオフセットデータブロックをファイルの最後に記録した場合を示す概略説明図である。
【図５】本発明のデータ記録再生装置の実施形態におけるオフセットデータブロックを用いた任意のデータブロックの検索処理を示すフローチャートである。
【図６】本発明のデータ記録再生装置の実施形態におけるQuickTimeファイル内の任意のatomデータの検索処理を示すフローチャートである。
【図７】本発明のデータ記録再生装置の実施形態におけるQuickTimeファイルの読み出したatomのヘッダ情報が正しい値か否かの検出処理を示すフローチャートである。
【図８】本発明のデータ記録再生装置の実施形態における固定長のoffset atomを示す概略説明図である。
【図９】本発明のデータ記録再生装置の実施形態におけるoffset atomが固定長である場合の任意のatomデータの検索処理を示すフローチャートである。
【図１０】本発明のデータ記録再生装置の実施形態における固定長のoffset atomをファイルの最後に記録した場合を示す概略説明図である。
【図１１】本発明のデータ記録再生装置の実施形態における可変長のoffset atomをファイルの最後に記録した場合を示す概略説明図である。
【図１２】本発明のデータ記録再生装置の実施形態における可変長のoffset atomを示す概略説明図である。
【図１３】本発明のデータ記録再生装置の実施形態におけるoffset atomが可変長である場合の任意のatomデータの検索処理を示すフローチャートである。
【図１４】本発明のデータ記録再生装置の実施形態における外部QuickTimeファイル名を指すoptr atomを示す概略説明図である。
【図１５】本発明のデータ記録再生装置の実施形態における外部QuickTimeファイル名を指すoptr atomをファイルの最後に記録した場合を示す概略説明図である。
【図１６】本発明のデータ記録再生装置の実施形態における外部ファイル名とそのファイル内でのoffset値を指すoptr atomを示す概略説明図である。
【図１７】本発明のデータ記録再生装置の実施形態における外部ファイル名とそのファイル内でのoffset値を指すoptr 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ファイルは、管理情報のバックアップであるmoov atomを同一ファイル内に格納している例であるが、バックアップのmoov atomを別ファイル内に保存しても良い。
【０１４７】
動画や静止画などを記録したQuickTimeファイルの管理情報のバックアップ（以下、moov atomのバックアップ）を外部のQuickTimeファイルに作成する場合、オリジナルのQuickTimeファイルの任意の位置に、moov atomのバックアップデータが格納されている外部QuickTimeファイルの所在位置（パス）およびファイル名を保持しているoptr atom（外部参照データブロックに相当）を記録する。
【０１４８】
この場合のoptr atomは、図１４に示すように、最初の４バイトにatom size、次の４バイトにatom typeとしてatomヘッダを記録する。後続するフィールドは、moov atomのバックアップデータの所在を示すPointフィールドであり、moov atomのバックアップデータが格納されているQuickTimeファイル名を外部ファイル名としてパスも含めて記録する。そして、最後のフィールドに、optr atomのエンド位置からoptr atom内のPointフィールドへのオフセット値を格納する。
【０１４９】
このoptr atomを用いたQuickTimeファイルの例を図１５に示す。図１５においては、オリジナルのQuickTimeファイルがmoov atom、mdat atomの順番で記録され、moov atomのバックアップが格納されている外部QuickTimeファイルのファイル名を格納しているoptr atomがファイルの最後に記録されている。この図１５は、optr atom内のPointフィールドが指しているQuickTimeファイルに、moov atomのバックアップのみが記録されている例であり、Pointフィールドに格納されているファイル名のQuickTimeファイルには、他のatomが複数個、記録されていても良い。
【０１５０】
前述のoptr atomを用いたmoov atomのバックアップへアクセスする方法を説明する。オリジナルのmoov atomへのアクセスが不能となった場合は、ファイルエンドへシークした後、ファイルエンド（optr atomのエンド）の４バイトにあるoptr atom内のPointフィールドへのオフセット値により、Pointフィールドへアクセスを行い、moov atomのバックアップが登録されているQuickTimeファイル名を取得する。
【０１５１】
そして、取得したファイル名のファイルをオープンし、異常時検索手段６によってこの外部QuickTimeファイル内のmoov atomを検索する。このように、moov atomのバックアップデータへアクセスを行うことにより、AVデータの再生を行うことが可能となる。また、前述と同じように、moov atomのバックアップデータをオリジナルのmoov atomへコピーすることにより、不具合が生じているオリジナルのQuickTimeファイル内のmoov atomを復旧することも可能となる。
【０１５２】
また、外部に存在するmoov atomのバックアップがQuickTimeファイル形式で記録されている必要はなく、任意のデータフォーマットで記録されていても良い。この場合は、図１６に示すようなoptr atomを用いて、外部にあるmoov atomのバックアップへアクセスを行う。
【０１５３】
図１６においては、最初の４バイトにatom size、次の４バイトにatom typeとしてatomヘッダを記録する。次に、moov atomのバックアップが格納されているデータ内における任意に定めた基準位置からmoov atomのバックアップデータへのオフセット値であるPoint Offsetフィールドを格納する。尚、図中の括弧では、moov atomのバックアップが格納されているデータをファイルとしており、このファイル内における基準位置からのオフセット値となる。
【０１５４】
次の後続するフィールドは、moov atomのバックアップデータの所在を示すPointフィールドである。この場合においても、図中の括弧は、moov atomのバックアップが格納されているデータをファイルとしており、moov atomのバックアップデータが格納されているファイル名を外部ファイル名として記録している。そして、最後のフィールドに、optr atomエンドからoptr atom内のPoint Offsetフィールドへのオフセット値を格納する。
【０１５５】
このようなmoov atomのバックアップが外部ファイルに存在する場合のoptr atomを用いたQuickTimeファイルの例を図１７に示す。図１７においては、オリジナルのQuickTimeファイルがmoov atom、mdat atomの順番で記録され、moov atomのバックアップが格納されている外部ファイルのファイル名およびその外部ファイル内におけるmoov atomのバックアップデータへのオフセット値を格納しているoptr atomがファイルの最後に記録されている。
【０１５６】
このoptr atomは、ファイルエンド（optr atomエンド）の４バイトのoffset値がoptr atom内のPoint Offsetフィールドを指しており、このPoint Offsetフィールドが外部ファイル内のmoov atomのバックアップデータ部分を指している。そして、後続するPointフィールドがその外部ファイルを指している。また、この図１７は、optr atom内のPointフィールドが指しているファイル（外部ファイル）内におけるPoint Offsetフィールドのオフセット値の位置にmoov atomのバックアップが記録されている例であり、外部ファイル内には、他のデータが記録されていても良い。
【０１５７】
前述の外部データ内にmoov atomのバックアップデータが存在する場合のアクセス方法について説明する。オリジナルのmoov atomへのアクセスが不能となった場合は、ファイルエンドへシークした後、ファイルエンド（optr atomエンド）の４バイトにあるoptr atom内のPoint Offsetフィールドへのオフセット値により、Point Offsetフィールドへアクセスを行い、Point Offsetの値を取得する。
【０１５８】
そして、次のPointフィールドへアクセスを行い、moov atomのバックアップが登録されているデータの所在（例えば、外部ファイル名）を取得する。また、取得した所在データ（外部ファイル）内における読み込み済みであるPoint Offsetの位置にあるデータにアクセスし、moov atomのバックアップデータを取得する。
【０１５９】
このように、moov atomのバックアップデータへアクセスを行うことにより、AVデータの再生を行うことが可能となる。また、前述と同じように、moov atomのバックアップデータをオリジナルのmoov atomへコピーすることにより、不具合が生じているオリジナルのQuickTimeファイル内のmoov atomを復旧することも可能となる。
【０１６０】
前述の図１４乃至図１７に示したoptr atomは、moov atomのバックアップデータの所在を記録してあれば良く、外部参照ファイル名に限定されるものではない。例えば、メモリ上にmoov atomのバックアップを格納した場合は、そのデータの存在するアドレスを格納しても良く、また、ネットワーク上に存在する場合は、そのデータへのURLを記録すれば良い。つまり、optr atom内には、moov atomのバックアップデータが存在している場所の所在を記録すれば良い。
【０１６１】
また、前述のoptr atomのPointフィールドには、moov atomのバックアップ情報への所在だけでなく、例えば別ファイルに格納されているmdat atom等の任意のatomの所在を格納しても良い。
【０１６２】
さらに、１つの外部データ内の１つのatomのみを参照するのではなく、複数の外部データ内の複数のatomを参照しても良い。その場合は、optr atomには、外部データを示す所在（例えば、ファイル名）とその外部データ内におけるある定めた基準位置から参照したいatomへのoffset値を１セットとして、必要な数だけこのセットを登録すれば良い。
【０１６３】
前述の外部データ参照（例えば、moov atomのバックアップデータ参照）は、QuickTimeファイルに限定されたものではなく、データの先頭にデータサイズを記録した前述のデータブロックにも適用可能であり、参照するデータの所在を格納した外部参照データブロックをオリジナルのファイル内に用意することにより、外部のデータにアクセスが可能である。
【０１６４】
以上詳述したように、あるまとまったデータにそのデータのサイズなどを表す管理情報を付加したデータブロックが記録媒体内のファイル内に１つ以上記録されている場合に、ファイル内のどこかのデータブロックの管理情報が読み取り不能となると、後続するデータブロックにアクセスできなくなる。
【０１６５】
そのため、本実施形態のデータ記録再生装置においては、確実にアクセス可能なファイル内の最後の位置に、各々のデータブロックへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録するオフセットデータブロックを設ける、或いは、このファイルとは別のデータ（例えば、外部ファイル）内に必要なバックアップデータを保持し、そのバックアップデータを持った別データの所在を登録する外部参照データブロックを設けることにより、確実に全てのデータブロックやデータブロックのバックアップへのアクセスが可能となり、読み取り不能となったデータブロックに後続するデータブロックにアクセスできないといった問題を解決することができる。
【０１６６】
また、QuickTimeファイルでは、AVデータの記録・再生を管理しているmoov atom内のデータが読み取り不能となった場合、AVデータを正しく記録・再生ができなくなる。
【０１６７】
このために、moov atomのコピーをバックアップmoov atomとして、ファイル内に設けることにより、この問題を解決することができるが、前記と同様に、バックアップmoov atomまでに存在するatomのヘッダ情報が読み取り不能となると、バックアップmoov atomへアクセスができなくなる。
【０１６８】
そのため、本実施形態のデータ記録再生装置においては、バックアップmoov atomへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録するoffset atomを設ける、或いは、このQuickTimeファイルとは別の外部のデータ内にmoov atomのバックアップを保存し、この外部データの所在を登録するoptr atomを設けることにより、確実にバックアップmoov atomへアクセスが可能となり、AVデータの記録・再生に対する不具合が生じる問題を抑制することが可能となる。
【０１６９】
尚、本発明は、QuickTimeファイル以外のファイルフォーマットにおいても、ファイルの最後か任意の場所にoffsetを表すデータ領域を設けることで適用可能であり、そのoffsetを表すデータ領域へのオフセット値をファイル内の任意の箇所に格納すれば良い。
【０１７０】
また、QuickTimeファイル以外のファイルフォーマットにおいても、AVデータの管理情報のバックアップが登録されている場合、offsetを表すデータ領域やそのバックアップが登録されている外部データの所在を示す領域から、オリジナルのAVデータの管理情報を復旧させることができ、さらには、データブロックの管理情報（データ長や種類）を、offsetを表すデータを用いて復旧させることが可能であることは明らかである。
【符号の説明】
【０１７１】
１ 記録部
２ 記録媒体
３ 再生部
４ 通常検索手段
５ 再生データ異常検出手段
６ 異常時検索手段
【技術分野】
【０００１】
本発明は、データブロック単位で様々なデータが登録されたファイルを読み書きする記録媒体用のデータ記録再生装置に関するものである。
【背景技術】
【０００２】
様々なデータを記録媒体に記録、ネットワークを介した転送、配信などを行う場合、データそのものとそのデータがどのようなデータであるか、またはそのデータにアクセスするために、全データ中のどこにどのような形態で存在しているかを表す、そのデータを管理する管理情報が必要となる。
【０００３】
管理情報には、例えば図１８に示すように、記録されたデータのファイル名を管理することを目的として、１つの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データの管理情報のバックアップデータブロックへアクセスすることを可能とし、AVデータの記録・再生に対する不具合を回避することができるデータ記録再生装置を提供するものである。
【課題を解決するための手段】
【００２２】
本願の第１の発明は、データ及び該データのサイズや個数、種類を含む管理情報からなるデータブロック単位で、各種データが登録されたファイルを記録媒体に記録する記録手段と、前記データブロック中の管理情報内のデータサイズに基づき、後続するデータブロックの先頭位置を得て、後続するデータブロックを読み出す再生手段と、前記再生手段により読み出されたデータブロック中の管理情報内のデータ種類に基づき、ファイル内のデータブロックを検索する検索手段とを備えたデータ記録再生装置において、前記ファイル内の任意の基準位置から該ファイル内に含まれるいくつかのデータブロックの先頭位置へのオフセット値が登録されたオフセットデータブロックをファイルの任意の位置に登録したことを特徴とする。
【００２３】
本願の第２の発明は、前記オフセットデータブロックのサイズが固定長であることを特徴とする。
【００２４】
本願の第３の発明は、前記オフセットデータブロックのサイズが可変長であることを特徴とする。
【００２５】
本願の第４の発明は、前記データブロックが、AVデータが登録されているデータブロックと、そのAVデータのデータブロックの記録・再生の形態を管理する管理情報が登録されているデータブロックとを含むことを特徴とする。
【００２６】
本願の第５の発明は、前記AVデータの管理情報が登録されているデータブロックのコピーを、バックアップとしてファイル内に登録するとともに、ファイル内の任意の基準位置からこの管理情報のバックアップのデータブロックへのオフセット値を前記オフセットデータブロックへ登録することを特徴とする。
【００２７】
本願の第６の発明は、前記再生手段により読み出された再生データの異常を検出する異常検出手段と、前記異常検出手段により再生データの異常が検出された時、前記オフセットデータブロックに登録されたオフセット値に基づき、任意のデータブロックを検索する異常時検索手段とを備えたことを特徴とする。
【００２８】
本願の第７の発明は、前記異常検出手段によりAVデータの管理情報が登録されているオリジナルのデータブロックに異常が検出された時、前記異常時検索手段が、前記オフセットデータブロックに登録されたオフセット値に基づき、該AVデータの管理情報が登録されているバックアップのデータブロックを検索し、この管理情報のバックアップのデータブロックに基づいて、AVデータを再生することを特徴とする。
【００２９】
本願の第８の発明は、前記AVデータの管理情報が登録されているバックアップのデータブロックを用いて、前記異常が検出されたAVデータの管理情報が登録されているオリジナルのデータブロックを復旧することを特徴とする。
【００３０】
本願の第９の発明は、前記異常検出手段によりデータブロックの管理情報に異常が検出された時、前記異常時検索手段が、前記オフセットデータブロックに登録されたオフセット値を用いて、前記異常が検出されたデータブロックの管理情報を復旧させることを特徴とする。
【００３１】
本願の第１０の発明は、データ及び該データのサイズや個数、種類を含む管理情報からなるデータブロック単位で、各種データが登録されたファイルを記録媒体に記録する記録手段と、前記データブロック中の管理情報内のデータサイズに基づき、後続するデータブロックの先頭位置を得て、後続するデータブロックを読み出す再生手段と、前記再生手段により読み出されたデータブロック中の管理情報内のデータ種類に基づき、ファイル内のデータブロックを検索する通常検索手段とを備えたデータ記録再生装置において、前記ファイル外に存在するデータの所在が登録された外部参照データブロックをファイルの任意の位置に登録したことを特徴とする。
【００３２】
本願の第１１の発明は、前記データブロックが、AVデータが登録されているデータブロックと、そのAVデータのデータブロックの記録・再生の形態を管理する管理情報が登録されているデータブロックとを含むことを特徴とする。
【００３３】
本願の第１２の発明は、前記AVデータの管理情報が登録されているデータブロックのコピーを、バックアップとしてファイル外に登録するとともに、この管理情報のバックアップのデータブロックの所在を前記外部参照データブロックへ登録することを特徴とする。
【発明の効果】
【００３４】
本発明によれば、各々のデータブロックへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録したオフセットデータブロックを設けているので、確実に全てのデータブロックへのアクセスが可能となり、読み取り不能となったデータブロックに後続するデータブロックにアクセスすることが可能となる。
【００３５】
また、AVデータの管理情報のデータブロックのコピーを、バックアップデータブロックとしてファイル内に設けるとともに、ファイル内の任意の基準位置からこのバックアップデータブロックの先頭位置へのオフセット値を登録したオフセットデータブロックを設ける、或いは、このバックアップデータブロックをこのファイルとは別の外部データ内に設けるとともに、この外部データの所在を示すデータブロックを設けることで、確実にAVデータの管理情報のバックアップデータブロックへアクセスが可能となり、AVデータの記録・再生に対する不具合を回避することができる。
【００３６】
さらに、オリジナルのAVデータの管理情報データブロックの破損が検出された場合は、バックアップのAVデータの管理情報データブロックをオリジナルの管理情報データブロックへコピーすることにより、前記破損したAVデータの管理情報データブロックを復旧させることができる。また、データブロックの管理情報の破損が検出された場合も、オフセットデータブロックのオフセット値を用いて、前記破損したデータブロックの管理情報を復旧させることができる。
【図面の簡単な説明】
【００３７】
【図１】本発明のデータ記録再生装置の実施形態における概略構成を示すブロック図である。
【図２】本発明のデータ記録再生装置の実施形態における任意のデータブロックの検索処理を示すフローチャートである。
【図３】本発明のデータ記録再生装置の実施形態におけるオフセットデータブロックをファイルの最後に記録した場合を示す概略説明図である。
【図４】本発明のデータ記録再生装置の実施形態におけるオフセットデータブロックをファイルの最後に記録した場合を示す概略説明図である。
【図５】本発明のデータ記録再生装置の実施形態におけるオフセットデータブロックを用いた任意のデータブロックの検索処理を示すフローチャートである。
【図６】本発明のデータ記録再生装置の実施形態におけるQuickTimeファイル内の任意のatomデータの検索処理を示すフローチャートである。
【図７】本発明のデータ記録再生装置の実施形態におけるQuickTimeファイルの読み出したatomのヘッダ情報が正しい値か否かの検出処理を示すフローチャートである。
【図８】本発明のデータ記録再生装置の実施形態における固定長のoffset atomを示す概略説明図である。
【図９】本発明のデータ記録再生装置の実施形態におけるoffset atomが固定長である場合の任意のatomデータの検索処理を示すフローチャートである。
【図１０】本発明のデータ記録再生装置の実施形態における固定長のoffset atomをファイルの最後に記録した場合を示す概略説明図である。
【図１１】本発明のデータ記録再生装置の実施形態における可変長のoffset atomをファイルの最後に記録した場合を示す概略説明図である。
【図１２】本発明のデータ記録再生装置の実施形態における可変長のoffset atomを示す概略説明図である。
【図１３】本発明のデータ記録再生装置の実施形態におけるoffset atomが可変長である場合の任意のatomデータの検索処理を示すフローチャートである。
【図１４】本発明のデータ記録再生装置の実施形態における外部QuickTimeファイル名を指すoptr atomを示す概略説明図である。
【図１５】本発明のデータ記録再生装置の実施形態における外部QuickTimeファイル名を指すoptr atomをファイルの最後に記録した場合を示す概略説明図である。
【図１６】本発明のデータ記録再生装置の実施形態における外部ファイル名とそのファイル内でのoffset値を指すoptr atomを示す概略説明図である。
【図１７】本発明のデータ記録再生装置の実施形態における外部ファイル名とそのファイル内でのoffset値を指すoptr 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ファイルは、管理情報のバックアップであるmoov atomを同一ファイル内に格納している例であるが、バックアップのmoov atomを別ファイル内に保存しても良い。
【０１４７】
動画や静止画などを記録したQuickTimeファイルの管理情報のバックアップ（以下、moov atomのバックアップ）を外部のQuickTimeファイルに作成する場合、オリジナルのQuickTimeファイルの任意の位置に、moov atomのバックアップデータが格納されている外部QuickTimeファイルの所在位置（パス）およびファイル名を保持しているoptr atom（外部参照データブロックに相当）を記録する。
【０１４８】
この場合のoptr atomは、図１４に示すように、最初の４バイトにatom size、次の４バイトにatom typeとしてatomヘッダを記録する。後続するフィールドは、moov atomのバックアップデータの所在を示すPointフィールドであり、moov atomのバックアップデータが格納されているQuickTimeファイル名を外部ファイル名としてパスも含めて記録する。そして、最後のフィールドに、optr atomのエンド位置からoptr atom内のPointフィールドへのオフセット値を格納する。
【０１４９】
このoptr atomを用いたQuickTimeファイルの例を図１５に示す。図１５においては、オリジナルのQuickTimeファイルがmoov atom、mdat atomの順番で記録され、moov atomのバックアップが格納されている外部QuickTimeファイルのファイル名を格納しているoptr atomがファイルの最後に記録されている。この図１５は、optr atom内のPointフィールドが指しているQuickTimeファイルに、moov atomのバックアップのみが記録されている例であり、Pointフィールドに格納されているファイル名のQuickTimeファイルには、他のatomが複数個、記録されていても良い。
【０１５０】
前述のoptr atomを用いたmoov atomのバックアップへアクセスする方法を説明する。オリジナルのmoov atomへのアクセスが不能となった場合は、ファイルエンドへシークした後、ファイルエンド（optr atomのエンド）の４バイトにあるoptr atom内のPointフィールドへのオフセット値により、Pointフィールドへアクセスを行い、moov atomのバックアップが登録されているQuickTimeファイル名を取得する。
【０１５１】
そして、取得したファイル名のファイルをオープンし、異常時検索手段６によってこの外部QuickTimeファイル内のmoov atomを検索する。このように、moov atomのバックアップデータへアクセスを行うことにより、AVデータの再生を行うことが可能となる。また、前述と同じように、moov atomのバックアップデータをオリジナルのmoov atomへコピーすることにより、不具合が生じているオリジナルのQuickTimeファイル内のmoov atomを復旧することも可能となる。
【０１５２】
また、外部に存在するmoov atomのバックアップがQuickTimeファイル形式で記録されている必要はなく、任意のデータフォーマットで記録されていても良い。この場合は、図１６に示すようなoptr atomを用いて、外部にあるmoov atomのバックアップへアクセスを行う。
【０１５３】
図１６においては、最初の４バイトにatom size、次の４バイトにatom typeとしてatomヘッダを記録する。次に、moov atomのバックアップが格納されているデータ内における任意に定めた基準位置からmoov atomのバックアップデータへのオフセット値であるPoint Offsetフィールドを格納する。尚、図中の括弧では、moov atomのバックアップが格納されているデータをファイルとしており、このファイル内における基準位置からのオフセット値となる。
【０１５４】
次の後続するフィールドは、moov atomのバックアップデータの所在を示すPointフィールドである。この場合においても、図中の括弧は、moov atomのバックアップが格納されているデータをファイルとしており、moov atomのバックアップデータが格納されているファイル名を外部ファイル名として記録している。そして、最後のフィールドに、optr atomエンドからoptr atom内のPoint Offsetフィールドへのオフセット値を格納する。
【０１５５】
このようなmoov atomのバックアップが外部ファイルに存在する場合のoptr atomを用いたQuickTimeファイルの例を図１７に示す。図１７においては、オリジナルのQuickTimeファイルがmoov atom、mdat atomの順番で記録され、moov atomのバックアップが格納されている外部ファイルのファイル名およびその外部ファイル内におけるmoov atomのバックアップデータへのオフセット値を格納しているoptr atomがファイルの最後に記録されている。
【０１５６】
このoptr atomは、ファイルエンド（optr atomエンド）の４バイトのoffset値がoptr atom内のPoint Offsetフィールドを指しており、このPoint Offsetフィールドが外部ファイル内のmoov atomのバックアップデータ部分を指している。そして、後続するPointフィールドがその外部ファイルを指している。また、この図１７は、optr atom内のPointフィールドが指しているファイル（外部ファイル）内におけるPoint Offsetフィールドのオフセット値の位置にmoov atomのバックアップが記録されている例であり、外部ファイル内には、他のデータが記録されていても良い。
【０１５７】
前述の外部データ内にmoov atomのバックアップデータが存在する場合のアクセス方法について説明する。オリジナルのmoov atomへのアクセスが不能となった場合は、ファイルエンドへシークした後、ファイルエンド（optr atomエンド）の４バイトにあるoptr atom内のPoint Offsetフィールドへのオフセット値により、Point Offsetフィールドへアクセスを行い、Point Offsetの値を取得する。
【０１５８】
そして、次のPointフィールドへアクセスを行い、moov atomのバックアップが登録されているデータの所在（例えば、外部ファイル名）を取得する。また、取得した所在データ（外部ファイル）内における読み込み済みであるPoint Offsetの位置にあるデータにアクセスし、moov atomのバックアップデータを取得する。
【０１５９】
このように、moov atomのバックアップデータへアクセスを行うことにより、AVデータの再生を行うことが可能となる。また、前述と同じように、moov atomのバックアップデータをオリジナルのmoov atomへコピーすることにより、不具合が生じているオリジナルのQuickTimeファイル内のmoov atomを復旧することも可能となる。
【０１６０】
前述の図１４乃至図１７に示したoptr atomは、moov atomのバックアップデータの所在を記録してあれば良く、外部参照ファイル名に限定されるものではない。例えば、メモリ上にmoov atomのバックアップを格納した場合は、そのデータの存在するアドレスを格納しても良く、また、ネットワーク上に存在する場合は、そのデータへのURLを記録すれば良い。つまり、optr atom内には、moov atomのバックアップデータが存在している場所の所在を記録すれば良い。
【０１６１】
また、前述のoptr atomのPointフィールドには、moov atomのバックアップ情報への所在だけでなく、例えば別ファイルに格納されているmdat atom等の任意のatomの所在を格納しても良い。
【０１６２】
さらに、１つの外部データ内の１つのatomのみを参照するのではなく、複数の外部データ内の複数のatomを参照しても良い。その場合は、optr atomには、外部データを示す所在（例えば、ファイル名）とその外部データ内におけるある定めた基準位置から参照したいatomへのoffset値を１セットとして、必要な数だけこのセットを登録すれば良い。
【０１６３】
前述の外部データ参照（例えば、moov atomのバックアップデータ参照）は、QuickTimeファイルに限定されたものではなく、データの先頭にデータサイズを記録した前述のデータブロックにも適用可能であり、参照するデータの所在を格納した外部参照データブロックをオリジナルのファイル内に用意することにより、外部のデータにアクセスが可能である。
【０１６４】
以上詳述したように、あるまとまったデータにそのデータのサイズなどを表す管理情報を付加したデータブロックが記録媒体内のファイル内に１つ以上記録されている場合に、ファイル内のどこかのデータブロックの管理情報が読み取り不能となると、後続するデータブロックにアクセスできなくなる。
【０１６５】
そのため、本実施形態のデータ記録再生装置においては、確実にアクセス可能なファイル内の最後の位置に、各々のデータブロックへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録するオフセットデータブロックを設ける、或いは、このファイルとは別のデータ（例えば、外部ファイル）内に必要なバックアップデータを保持し、そのバックアップデータを持った別データの所在を登録する外部参照データブロックを設けることにより、確実に全てのデータブロックやデータブロックのバックアップへのアクセスが可能となり、読み取り不能となったデータブロックに後続するデータブロックにアクセスできないといった問題を解決することができる。
【０１６６】
また、QuickTimeファイルでは、AVデータの記録・再生を管理しているmoov atom内のデータが読み取り不能となった場合、AVデータを正しく記録・再生ができなくなる。
【０１６７】
このために、moov atomのコピーをバックアップmoov atomとして、ファイル内に設けることにより、この問題を解決することができるが、前記と同様に、バックアップmoov atomまでに存在するatomのヘッダ情報が読み取り不能となると、バックアップmoov atomへアクセスができなくなる。
【０１６８】
そのため、本実施形態のデータ記録再生装置においては、バックアップmoov atomへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録するoffset atomを設ける、或いは、このQuickTimeファイルとは別の外部のデータ内にmoov atomのバックアップを保存し、この外部データの所在を登録するoptr atomを設けることにより、確実にバックアップmoov atomへアクセスが可能となり、AVデータの記録・再生に対する不具合が生じる問題を抑制することが可能となる。
【０１６９】
尚、本発明は、QuickTimeファイル以外のファイルフォーマットにおいても、ファイルの最後か任意の場所にoffsetを表すデータ領域を設けることで適用可能であり、そのoffsetを表すデータ領域へのオフセット値をファイル内の任意の箇所に格納すれば良い。
【０１７０】
また、QuickTimeファイル以外のファイルフォーマットにおいても、AVデータの管理情報のバックアップが登録されている場合、offsetを表すデータ領域やそのバックアップが登録されている外部データの所在を示す領域から、オリジナルのAVデータの管理情報を復旧させることができ、さらには、データブロックの管理情報（データ長や種類）を、offsetを表すデータを用いて復旧させることが可能であることは明らかである。
【符号の説明】
【０１７１】
１ 記録部
２ 記録媒体
３ 再生部
４ 通常検索手段
５ 再生データ異常検出手段
６ 異常時検索手段
【特許請求の範囲】
【請求項１】
ＡＶデータおよび該ＡＶデータを再生するための再生情報が格納された、複数のデータブロックと、オフセットデータブロックとを含んで構成されるファイルを、記録媒体に記録するデータ記録装置において、
上記ファイルにおける、上記複数のデータブロックのいずれかの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第１の情報を、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに少なくとも１つ以上格納し、
上記ファイルにおける、上記オフセットデータブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報を、上記オフセットデータブロックの最後に格納することを特徴とする、データ記録装置。
【請求項２】
ＡＶデータおよび該ＡＶデータを再生するための再生情報が格納された、複数のデータブロックと、オフセットデータブロックとを含んで構成されるファイルを、記録媒体に記録するデータ記録装置において、
上記ファイルにおける、上記複数のデータブロックのいずれかの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第１の情報を、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに少なくとも１つ以上格納し、
上記ファイルにおける、上記オフセットデータブロックのデータサイズを示す第２の情報を、上記オフセットデータブロックの上記オフセットデータブロックの最後に格納することを特徴とする、データ記録装置。
【請求項３】
ＡＶデータおよび該ＡＶデータを再生するための再生情報が格納された、複数のデータブロックと、オフセットデータブロックとを含んでより構成されるファイルより、上記ＡＶデータおよび上記再生情報を読出し、上記ＡＶデータを再生するデータ再生装置において、
上記ファイルにおける、上記複数のデータブロックのいずれかの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第１の情報が、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに少なくとも１つ以上格納されており、
上記ファイルにおける、上記オフセットデータブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報が、上記オフセットデータブロックの最後に格納されており、
上記ファイルより上記第２の情報を取得し、
上記取得した上記第２の情報に基づいて、上記第１の情報を取得し、
上記取得した第１の情報に基づき、上記ＡＶデータおよび上記再生情報を読み出すことを特徴とする、データ再生装置。
【請求項４】
ＡＶデータおよび該ＡＶデータを再生するための再生情報が格納された、複数のデータブロックと、オフセットデータブロックとを含んで構成されるファイルより、上記ＡＶデータおよび上記再生情報を読出し、上記ＡＶデータを再生するデータ再生装置において、
上記ファイルにおける、上記複数のデータブロックのいずれかの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第１の情報が、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに少なくとも１つ以上格納されており、
上記ファイルにおける、上記オフセットデータブロックのデータサイズを示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報が、上記オフセットデータブロックの最後に格納されており、
上記ファイルより上記第２の情報を取得し、
上記取得した上記第２の情報に基づいて、上記第１の情報を取得し、
上記取得した第１の情報に基づき、上記ＡＶデータおよび上記再生情報を読み出すことを特徴とする、データ再生装置。
【請求項１】
ＡＶデータおよび該ＡＶデータを再生するための再生情報が格納された、複数のデータブロックと、オフセットデータブロックとを含んで構成されるファイルを、記録媒体に記録するデータ記録装置において、
上記ファイルにおける、上記複数のデータブロックのいずれかの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第１の情報を、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに少なくとも１つ以上格納し、
上記ファイルにおける、上記オフセットデータブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報を、上記オフセットデータブロックの最後に格納することを特徴とする、データ記録装置。
【請求項２】
ＡＶデータおよび該ＡＶデータを再生するための再生情報が格納された、複数のデータブロックと、オフセットデータブロックとを含んで構成されるファイルを、記録媒体に記録するデータ記録装置において、
上記ファイルにおける、上記複数のデータブロックのいずれかの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第１の情報を、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに少なくとも１つ以上格納し、
上記ファイルにおける、上記オフセットデータブロックのデータサイズを示す第２の情報を、上記オフセットデータブロックの上記オフセットデータブロックの最後に格納することを特徴とする、データ記録装置。
【請求項３】
ＡＶデータおよび該ＡＶデータを再生するための再生情報が格納された、複数のデータブロックと、オフセットデータブロックとを含んでより構成されるファイルより、上記ＡＶデータおよび上記再生情報を読出し、上記ＡＶデータを再生するデータ再生装置において、
上記ファイルにおける、上記複数のデータブロックのいずれかの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第１の情報が、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに少なくとも１つ以上格納されており、
上記ファイルにおける、上記オフセットデータブロックの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報が、上記オフセットデータブロックの最後に格納されており、
上記ファイルより上記第２の情報を取得し、
上記取得した上記第２の情報に基づいて、上記第１の情報を取得し、
上記取得した第１の情報に基づき、上記ＡＶデータおよび上記再生情報を読み出すことを特徴とする、データ再生装置。
【請求項４】
ＡＶデータおよび該ＡＶデータを再生するための再生情報が格納された、複数のデータブロックと、オフセットデータブロックとを含んで構成されるファイルより、上記ＡＶデータおよび上記再生情報を読出し、上記ＡＶデータを再生するデータ再生装置において、
上記ファイルにおける、上記複数のデータブロックのいずれかの先頭位置を示す、上記ファイル内の任意の基準位置からのオフセット値である第１の情報が、上記記録媒体に記録される上記ファイルの上記オフセットデータブロックに少なくとも１つ以上格納されており、
上記ファイルにおける、上記オフセットデータブロックのデータサイズを示す、上記ファイル内の任意の基準位置からのオフセット値である第２の情報が、上記オフセットデータブロックの最後に格納されており、
上記ファイルより上記第２の情報を取得し、
上記取得した上記第２の情報に基づいて、上記第１の情報を取得し、
上記取得した第１の情報に基づき、上記ＡＶデータおよび上記再生情報を読み出すことを特徴とする、データ再生装置。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図１６】
【図１７】
【図１８】
【図１９】
【図２０】
【図２１】
【図２２】
【図２３】
【公開番号】特開２０１０−２３８３５２（Ｐ２０１０−２３８３５２Ａ）
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願番号】特願２０１０−１２４６３１（Ｐ２０１０−１２４６３１）
【出願日】平成２２年５月３１日（２０１０．５．３１）
【分割の表示】特願２００８−１０５１７７（Ｐ２００８−１０５１７７）の分割
【原出願日】平成１３年１月１５日（２００１．１．１５）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
【公開日】平成２２年１０月２１日（２０１０．１０．２１）
【国際特許分類】
【出願日】平成２２年５月３１日（２０１０．５．３１）
【分割の表示】特願２００８−１０５１７７（Ｐ２００８−１０５１７７）の分割
【原出願日】平成１３年１月１５日（２００１．１．１５）
【出願人】（０００００５０４９）シャープ株式会社 (33,933)
【Ｆターム（参考）】
[ Back to top ]