以下、本発明のデータ記録再生装置の実施形態について、図1乃至図17とともに詳細に説明する。
図1は本実施形態のデータ記録再生装置における概略構成を示すブロック図である。図1において、1は記録媒体2へデータの書き込みを行う記録部、2は記録媒体、3は記録媒体2からデータの読み込みを行う再生部、4はデータブロックの管理情報内のデータブロックサイズより後続のデータブロックの位置を求め、データブロックの種類により、任意のデータブロックを検索する検索手段である。
5は再生データが正しく再生されているかを検出する異常検出手段、6はオフセットデータブロックのオフセット値を用いて、データブロックの種類により、任意のデータブロックを検索する異常時検索手段である。
上記のように構成されたデータ記録再生装置においては、入力された記録データをデータブロック単位で記録するため、ファイルをオープンし、記録部1を通して記録媒体2に記録する。このとき、データブロックの管理情報のサイズとして任意の値を格納した上でデータブロックを記録し、データブロックを記録し終えてデータブロックサイズが確定してからデータブロックの管理情報の位置へ移動し、実際のデータブロックサイズを記録する。
ファイル内に任意のデータブロックを記録し終えたら、ファイルをクローズして、記録媒体2への記録を終了する。また、記録データのデータブロックのサイズがメモリ上のサイズからあらかじめ把握できている場合は、初めからデータブロックサイズを正しく付加して記録することにより、図1における記録部1のフィードバック処理は不要となる。
次に、記録媒体2へ記録したファイルを読み出す場合は、再生部3によりファイルをオープンし、データブロックを読み出す。通常検索手段4で読み出したいファイル内のデータブロックを検索する。
ここでは、AVデータを再生するために、AVデータの再生に関する管理情報データブロックを検索し、見つかった場合は、その管理情報データブロックからAVデータが格納されているデータブロックを参照し、AVデータを再生する。
このとき、管理情報データブロックの登録情報にデータ再生時間やAVデータのデータブロックへのオフセット値が、AVデータのデータブロックサイズを越えている場合など矛盾が生じるときや、ユーザーによる再生データの不具合の要求があった場合は、異常検出手段5により再生データの異常検出が行われる。
そして、異常時検索手段6において、ファイル内の任意の基準位置からファイル内のデータブロックへのオフセット値が格納されているオフセットデータブロックより、そのオフセット値を利用して、AVデータの管理情報のバックアップデータブロックへアクセスし、データの再生を行う。
この場合においても、異常検出手段5で再生データが異常であると検出された場合はエラーとなる。また、通常検索手段4の検索において、AVデータの再生に関する管理情報データブロックや他のデータブロックが見つからなかった場合は、異常時検出手段6により前述のオフセットデータブロックを用いて、目的のデータブロックを検索する。
このとき、AVデータの再生に関する管理情報データブロックを検索した場合は、その管理情報データブロックからAVデータが格納されているデータブロックを参照し、AVデータを再生する。そして、前述と同じように、異常時検出手段5で再生データの異常検出を行い、不具合が生じた場合は、再度図異常時検索手段6において、オフセットデータブロックからAVデータの管理情報のバックアップデータブロックへアクセスし、データ再生を行う。
さらに、この場合においても、異常検出手段5で再生データの異常が検出された場合はエラーとなる。そして、記録媒体2からの読み出しが終了したらファイルをクローズする。
ここで、ファイル内にある任意のデータブロックを検索する処理を、図2のフローチャートとともに説明する。まず、ステップS80において、ファイルの先頭位置へ移動し、次にステップS81において、目的のデータブロックをファイル内の位置まで検索するため、現在の位置が目的データブロックの位置であるかの判定を行う。
ステップS81での判定の結果、現在の位置が目的データブロックであった場合は、ステップS82へ進み、目的データブロックにアクセスを行い終了する。ステップS81で現在の位置が目的データブロックでなかった場合は、ステップS83へ進み、現在のデータブロックの先頭に格納されているデータブロックサイズ分だけ移動し、次のデータブロックの先頭位置へ移動する。
そして、ステップS84において、移動した位置がファイル終了位置であるかの判定を行う。ファイルの終了位置かの判定には、ファイルの終了位置を表すEOFを検出することにより、現在のファイル位置がファイルの最後かを判定する。
ファイルの終了位置に到達した場合は、目的データブロックを検索できなかったということになり、ステップS85において、エラーを出力し終了する。移動した位置がファイルの終了位置でなかった場合は、ステップS81に戻り、現在の位置が目的データブロックの位置であるかの判定を行い、ファイルの終了位置へ到達するか、目的データブロックが見つかるまで、これらの処理を繰り返す。
光ディスクを用いたカムコーダなどリムーバブルな記録媒体を用いて、記録・再生を行う場合は、記録面に付着したほこりや傷により、記録されたデータを正しく読み出せなくなる場合がある。また、PCのような据え置き型の機器の場合は、常に固定して設置されているために、PC本体に対し強い衝撃が加わる可能性は低いと考えられるが、前記カムコーダのようなポータブル機器の場合は、手に保持し、走りながら撮影を行ったり、撮影中に物にぶつかることや不注意で機器を落とすなどの強い衝撃が加わる可能性が据え置き型機器に比べ高い。
ポータブル機器において、このような使用環境中では、記録中に機器に衝撃が加わることで書き込みレーザーが振動によりずれ、別のデータ領域に誤って記録してしまうことにより、そのデータ領域が間違ったデータで上書きされることとなり、そのデータ領域を読み出す場合に、正しい値が読み出せなくなる。
このように、データブロックの先頭にあるデータサイズが読み取り不能となったり、正しい値が読み出せない場合、上記検索手段4を用いた検索では、このデータブロックを含め、後続するデータブロックを正しく読み出せなくなる。
これは、図21、図22とともに上述したように、正しいデータブロックサイズが読み出せないことにより、正しく読み出せないデータブロックの先頭アドレスから間違ったデータサイズだけ移動したファイル位置を次のデータブロックの先頭位置と誤認識するためである。
さらに、その正しく読み出せないデータブロック内や次のデータブロック内のファイル位置を次のデータブロックのサイズ部分とみなし、間違った次のデータサイズだけ読み飛ばすことから、後続する正しいデータブロックが読み出せなくなる。
上述のデータブロックの先頭にあるデータサイズが正しく読み出せない場合に、後続するデータブロックに対しても正しく読み出せないことを回避するため、本実施形態においては、図3、図4に示すように、ファイルの最後にファイル内の基準となる位置(ファイルの先頭や最後など)から各々のデータブロックの先頭位置へのオフセット値を格納するデータブロック(以下、オフセットデータブロック)を用意する。
ここでは、このオフセットデータブロックをファイルの最後に設けている。これは、データサイズなどの管理情報が正しく読み出せないと、前述の検索手段4ではオフセットデータブロック自体も検索できなくなるので、確実にオフセットデータブロックを検索するためである。
すなわち、ファイルシステムの機能であるシークを用いて、ファイルの終了位置へシークする方法や、ファイル終了フラグであるEOFを検出するまで、ファイル内データを次々に読み出していく方法などを用いることにより、ファイルの最後へ移動することは容易であるので、データサイズ情報が正しく読み出せないことに関係なく確実にオフセットデータブロックにアクセスすることが可能となる。
尚、前述の説明では、オフセットデータブロックをファイルの最後に登録することとしているが、ファイルの先頭にオフセットデータブロックを設ける場合は、記録媒体2にデータブロックを保存する際、あらかじめ仮の値の入ったオフセットデータブロックを記録し、その後にデータブロックを保存する。
そして、各々のデータブロックへのオフセット情報が確定した段階でオフセットデータブロックを更新するという方法を用いることにより、ファイルの先頭にオフセットデータブロックを設けることが可能となる。このように、オフセットデータブロックは必ずしもファイルの最後に配置する必要はなく、ファイルの先頭など、任意の決まった位置に設けても、ファイルの先頭と最後との両方に設けても良い。
次に、図3、図4に示すように、オフセットデータブロックをファイルの最後に設定した場合のデータブロックへのアクセス方法を、図5のフローチャートとともに説明する。
まず、ステップS90において、ファイルの任意の基準位置からファイル内のデータブロックへのオフセット値を格納したファイルの最後にあるオフセットデータブロックへアクセスを行うため、ファイルの終了位置へ移動し、ファイルの任意の基準位置からオフセットデータブロックの先頭位置へのオフセット値が格納されているオフセットデータブロックの最後のフィールド情報を取得する。
ここで、ファイルの終了位置へ移動するには、ファイルシステムの機能であるシークを用いて、ファイルの終了位置へシークする方法と、ファイル終了フラグであるEOFを検出するまで、ファイル内データを次々に読み出していく方法とが考えられる。
次に、ステップS91において、任意の基準位置から取得したオフセット値の位置へ移動することにより、オフセットデータブロックの先頭へ移動し、ヘッダ情報を読み飛ばす。そして、ステップS92において、オフセットデータブロックの現在のフィールドが読み出したいデータのオフセット値のフィールドであるかの判定を行う。
現在のフィールドが読み出したいデータのオフセット値のフィールドであった場合は、ステップS93へ進み、そのオフセット値を取得する。そして、ステップS94において、ファイルの任意の基準位置から取得したオフセット値への位置へ移動し、ステップS95で読み出したいデータブロックへアクセスする。
また、ステップS92での判定結果が現在のフィールドが読み出したいデータのオフセット値のフィールドでなかった場合は、ステップS96へ進み、次のフィールド情報へ移動する。
そして、ステップS97にて、ステップS96で移動した位置がファイルの終わりを示すEOFを検出した場合は、ステップS98へ進み、読み出したいデータブロックへのオフセット値が格納されていなかったことになり、エラーを出力し終了する。
ステップS97で現在のファイル位置がファイルの終了でなかった場合には、ステップS92へ戻り、読み出したいデータブロックへのオフセットのフィールドが見つかるかファイルの終了位置へ到達するまで、上述の処理を繰り返す。
次に、AVファイルフォーマットの1つであるQuickTimeファイルにおいて、ファイル内の任意のatomを検索する処理の流れを、図6のフローチャートを用いて説明する。まず、ステップS20において、現在のファイル位置をファイルの先頭に設定し、ステップS21において、現在のファイル位置から8バイトのデータであるatomヘッダを読み出す。
そして、ステップS22において、読み出したヘッダの後半部の4バイトであるatomの種類が目的のatomであるか判定する。例えば、moov atom内に存在し、音声や画像などを再生するために必要な情報を保持しているTrack header atomを検索する場合は、読み出したヘッダの後半部4バイトが"tkhd"のASCIIコードであるかを判定する。
もし、目的のatomであった場合は、ステップS26へ進み、目的atomデータへアクセスを行い終了する。しかし、目的のatomでなかった場合は、ステップS23へ進み、ステップS21で取得した8バイトの前半部4バイトであるatomのデータサイズだけ現在の位置から読み飛ばし、読み飛ばし後の位置を現在のファイル位置に設定する。
例えば、ファイルシステムの機能を利用して、atomのデータサイズ分だけ現在位置からシークすることで移動が可能となる。ステップS24において、ステップS23で読み飛ばした結果、ファイルの終了位置を表すEOFを検出することにより、現在のファイル位置がファイルの最後かを判定する。
現在のファイル位置がファイルの最後であった場合は、目的のatomが検索ファイル内に見つからなかったこととなり、ステップS25により、エラー処理を行い検索を終了する。
現在のファイル位置がファイルの最後でなかった場合は、ステップS21へ戻り、現在のファイル位置から8バイトのデータであるatomヘッダを読み出す。そして、ステップS22に進み、ファイルの最後までの範囲を目的のatomが見つかるまで上述の検索処理を繰り返す。
前述したカムコーダの例のような場合に、atomのヘッダ部分の読み取り不能が生じると、上記検索手段4では、正しくないヘッダ情報を読み込んだことになり、それ以降のatomへのアクセスが不可能となる。
これは、図19とともに上述したように、moov atomのsize情報が正しく読み出せない場合、moov atomの途中のファイル位置を終了位置とみなし、正しくないmoov atomの終了位置の次の8バイトをいくつかの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のヘッダ情報が正しい値でないことを検出する方法について説明する。これは、図6におけるステップS22の直前に、図7に示すフローチャートの検出処理を付加することにより、ヘッダ情報が正しい値であるという検出を付加した検索処理が可能となる。
取得したatomヘッダ情報の先頭4バイトであるatomのsizeが現在のQuickTimeファイルサイズより大きいか、または負の値など明らかに正しくない値を示している場合は、正しいatomのsizeとみなさずヘッダが正しい値でないと判断するため、図7におけるステップS50において、atom sizeがヘッダ情報領域サイズである8より大きく、ファイルサイズより小さいかの判定を行っている。
atom sizeがこの範囲外の値であった場合は、ステップS52へ進みエラー処理を行い、検索を終了する。この場合は、後述するatomの復旧処理を行うことにより、atomデータの復旧およびアクセスが可能となる。atomのsizeが正しい値を示しているならば、ステップS51に進み、後続する4バイトであるatomのtypeがアルファベット、数字、記号などのASCIIコードである4バイトの文字列であるかの判定を行う。
この条件を満たさない場合は、ヘッダ情報が正しく読み出せないと判断し、ステップS52へ進みエラー処理を行い、検索を終了する。ステップS51の条件を満たし、正しいatomのtypeであった場合は、正しいatomのヘッダ情報が取得できたこととなり、図6におけるステップS22以降の処理を行うことにより、目的のatomを検索する。
以上のように、正しく読み出せないヘッダ情報を含んでいるQuickTimeファイルを再生した場合、atom検索において必要なatomが見つからなかったり、再生に必要な正しいデータを取得できないことから、再生システムがエラーを発生するか、再生している映像や音声に不具合が生じ、ユーザーが正しくないAVデータを再生していると判断することになる。この場合は、ユーザーが後述する復旧処理を選択することにより、正しく読み出せないatomを復旧させることが可能となる。
以上のように、atomのヘッダ情報が正しく読み出せない場合、そのQuickTimeファイルを正しく再生できなくなるという不具合が生じる。これを回避する方法について説明する。
再生を行うシステムが前述の検出手段4により、atomヘッダのsizeを正しく読み出せないと検出した場合は、目的のatomのtypeをQuickTimeファイルの先頭より、1バイトづつ検索していき、目的のatomのtypeのASCIIコードがファイル内で見つかるまで検索するという手法が考えられる。
しかしながら、これはQuickTimeファイルを1バイトづつ比較するため、検索速度が遅く効率が悪い。また、必ずしも目的のatomのヘッダ情報中のtypeを検索できるとは限らず、偶然にatom中のデータ領域に存在するatom typeと同じASCIIコードを持つデータを検索してしまうことが考えられる。さらに、atomヘッダ情報のtypeが正しく読み出せない場合は、検索する手段を失う。
このため、本実施形態においては、以下に説明する手法をQuickTimeファイルに適用する。QuickTimeファイルを記録媒体に記録するときに、ファイルの最後に前述のオフセットデータブロックに相当するoffset atomと呼ばれる管理情報を記録する。
このoffset atomは、ファイル内の基準アドレス(ファイルの先頭、最後やoffset atomの先頭アドレスなどファイル内の任意の箇所で良い)から想定するatomの先頭アドレスへのオフセット値を、図8に示すように管理している。
図8の例では、オフセット値を管理するatomとして、offset atomのsize、offset atomの種類であるtype、moov atomへのオフセット値、mdat atomへのオフセット値、moov atomのコピーであるバックアップmoov atomへのオフセット値の順番により、4バイト単位で格納するものである。
図8のoffset atomのヘッダ情報をぬかした1つ目のフィールドは、ファイル内の基準アドレスからmoov atomの先頭アドレスまでのオフセット値を格納する。2つ目のフィールドには、同様にmdat atomまでのオフセット値を格納する。さらに、3つ目のフィールドには、バックアップmoov atomまでのオフセット値を格納する。
尚、オフセット値を管理するatomは、これらのatomに限定されるものではなく、必要に応じて設定することが可能である。バックアップmoov atomについての詳細な説明は後述する。
atomのヘッダ情報であるsizeが正しく読み出せない場合は、それ以降のatomの検索が不可能であるというのは、前述した通りであるが、ヘッダ情報が正しく読み出せないと前述の検索手段4では、offset atom自体も検索することができなくなる。
そのため、確実にoffset atomを検索するために、offset atomをQuickTimeファイルの最後のatomとして登録する。これは、ファイルの最後の位置へ移動することが容易であることから、ヘッダ情報が正しく読み出せないことに関係なく、確実にoffset atomにアクセス可能とするためである。
また、前述の説明では、offset atomをファイルの最後に設けるとしているが、ファイルの先頭にoffset atomを設ける場合は、記録媒体2にatomデータを保存する際、あらかじめ仮の値の入ったoffset atomを記録し、その後にatomデータ(moovやmdat atomなど)を保存する。
そして、各々のatomデータへのオフセット情報が確定した段階でoffset atomを更新するという方法を用いることにより、ファイルの先頭にoffset atomを設けることが可能となる。このように、offset atomは必ずしもファイルの最後におく必要はなく、ファイルの先頭など任意の決まった位置に設けたり、ファイルの先頭と最後との両方に設けても良い。
atomのヘッダ情報が正しく読み出せない場合は、目的のatomを検索するために、ファイルの終了位置にあるoffset atomへアクセスするため、図9に示すフローチャートの検索処理を行う。
ステップS30において、QuickTimeファイルの終了位置へ移動し、その位置からファイルの先頭側へoffset atomの大きさである20バイトのアドレスへ移動する。この位置がoffset atomが存在する場合のoffset atomの先頭位置となる。
そして、ステップS31において、そのアドレスから8byteのヘッダ情報を取得する。取得したヘッダ情報が正しいoffset atomであるかの判定を行うため、ステップS32において、ヘッダ情報の先頭4バイトの内容がoffset atomのsizeを示す"20"であり、後続する4バイトの内容がoffset atomのtypeを示す"ofst"であるかの判定を行う。
正しいoffset atomのヘッダでなかった場合は、ステップS41に進みエラー処理を行って終了する。正しいoffset atomのヘッダであった場合は、ステップS33へ進む。ここで、moov atomを検索する場合は、ステップS34へ進み、offset atomの先頭から8バイトの位置へ移動し、この位置より4バイトのデータを取得して、ステップS39へ進む。
また、ステップS33において、他のatomを検索する場合は、ステップS35へ進み、ここでmdat atomを検索する場合は、ステップS36へ進み、offset atomの先頭から12バイトの位置へ移動し、この位置より4バイトのデータを取得して、ステップS39へ進む。
さらに、ステップS35において、他のatomを検索する場合は、ステップS37へ進み、ここでバックアップmoov atomを検索する場合は、ステップS38へ進み、offset atomの先頭から16バイトの位置へ移動し、この位置より4バイトのデータを取得して、ステップS39へ進む。
ステップS37で他のatomを検索する場合は、QuickTimeファイル内に登録されていないatomデータを検索しようとしたことになり、ステップS41へ進み、エラー処理を行って終了する。
ステップS34、S36、S38の処理後に、ステップS39へ進んだ場合、ファイル内の任意の基準位置から取得したオフセット位置へ移動する。そして、ステップS40において、移動した位置より目的の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ストリームなどの動画データの場合、例えば1時間分のデータサイズは、ビットレートが8Mbpsであると、約3.5Gバイトものデータサイズとなる。
図10に示すように、moov atom、mdat atom、バックアップmoov atomの順番で記録した場合は、mdat atomのサイズが3.5Gバイトのサイズになると、オリジナルとバックアップのmoov atomが共に損傷を受ける可能性は低いことから、バックアップmoov atomをQuickTimeファイル内に設けても、オリジナルのバックアップとしての機能を果たす可能性は高い。
上述のことから、mdat atom内の素材データやAVデータが正しくファイルに存在しているにもかかわらず、moov atomの破損により再生が正しく行われないことを回避するために、図10の例では、mdat atomの次にmoov atomのコピーをバックアップとして、QuickTimeファイル内に追加する。
再生に関する管理情報を二重化して登録することで、元のmoov atomが破損を受けた場合であっても、バックアップのmoov atomにアクセスすることにより、正しい再生を可能とし、さらに、破損したmoov atomを復旧させることが可能となる。
ただし、バックアップmoov atomを記録したとしても、前述のように、このバックアップmoov atomにアクセスするまでの間にatomのsize情報が正しく読み出せない場合、結局バックアップmoov atomへアクセスできなくなる。
そこで、前述したように、そのmoovのバックアップの位置情報もoffset atom内に登録する。これは、バックアップmoov atomを登録する時に、図11に示すように、ファイル内の任意の基準位置からバックアップmoov atomの先頭位置までのオフセット値を、前述の図8に示したoffset atomの最後の4バイトに登録する。
このバックアップmoov atomを登録するのと同様に、QuickTimeファイルフォーマット以外のファイルフォーマットを用いた場合でも、データの管理情報が存在する場合は、この管理情報のコピーをバックアップとして、ファイル内の任意の場所へ登録し、その位置をoffset atomに相当する情報で管理しても良い。
moov atomデータが正しいデータでないことを検出する方法として、前述のatomヘッダ情報が正しくないことを検出する方法の他に、以下に挙げる手法がある。これは、システムの検出によるものと、ユーザーによるものとが挙げられる。
システムの検出によるものは、moov atomで管理されている情報のうち、全体の再生時間よりも、あるtrackの再生時間が長い時やmdat atomデータ内の参照を表すオフセット値やサイズがmdat atomデータサイズを超えてしまっている時などのように管理情報のつじつまが合わなくなり、システムよりエラーが生じた場合である。
一方、ユーザーの検出によるものは、再生している映像や音声に不具合を感じた時に、ユーザーがQuickTimeファイルが損傷していると判断し、その旨をシステムに伝えることにより検出される。
前述のmoov atomが正しいデータでないと検出された場合の処理について説明する。atomのヘッダ情報が正しく読めない場合や、moov atomが正しいデータでないと検出された場合は、QuickTimeファイルの最後にあるoffset atomを用いて前述の検索手段6により、バックアップのmoov atomへアクセスを行う。
これをAVデータの管理情報として、AVデータの再生を行う。ここで、バックアップのmoov atomを用いた場合でも、この管理情報が正しいデータでないと検出された場合は、mdat atomデータが正しく読み出せないか、オリジナルとバックアップのmoov atomが共に正しいデータでないことが考えられる。
また、moov atomが正しいデータでないと検出され、バックアップmoov atomを検索する場合、図6とともに上述したatomの検索方法を用いて、ファイルの先頭から後続するatomを順に検索していき、バックアップmoov atomが見つかるまでQuickTimeファイル内を検索しても良い。
moov atomが正しいデータでないと検出された場合は、正しいデータでないmoov atomを復旧する処理を行っても良い。これは、前述のバックアップmoov atomをoffset atomの情報により検索してアクセスを行い、バックアップmoov atomに対して異常がないかを検出するか、バックアップmoov atomによりAVデータを再生し、異常がないことを確認する。
問題がなければ、offset atomによる異常時検索手段6により、異常のあるmoov atomの位置を検索し、バックアップmoov atomの内容をmoov atomの先頭へコピーすることにより、異常のあったオリジナルのmoov atomを復旧させる。
また、前述のatomヘッダのsize情報のみが正しく読み出せない場合は、offsetatomのオフセット値を用いて、正しく読み出せないヘッダ情報を持つatomと後続するatomのオフセット値の差より、正しく読み出せないヘッダ情報を持つatomのサイズを算出し、offset atomが指している正しく読み出せないヘッダ情報を持つatomの先頭アドレスへこのサイズとatomの種類を8バイト書き込むことにより、正しく読み出せないヘッダ情報を持つatomのヘッダ情報を復旧させることが可能である。
さらに、atomヘッダのatomの種類のみが破損している場合は、offset atomのオフセット値を用いて、該atomヘッダの位置にアクセスし、検索しようとしたatomの種類を破損したatomの種類とみなして、該atomヘッダの後半4バイトに書き込むことにより、破損したatomの種類を持つatomのヘッダ情報を復旧させることができる。
moov atomのバックアップ情報をファイル内に設ける方法は、QuickTimeファイルに限定したものではなく、他のファイルフォーマットにおいてもデータのバックアップを有する場合は、データのバックアップを保持し、ファイルの最後にこのバックアップ情報へのオフセット値を保持することによって、バックアップデータへアクセスが可能となり、元のデータの復旧も行うことが可能となる。
QuickTime File内に格納するatomは、前述のように、moov atom、mdat atom、バックアップmoov atomだけではなく、様々な種類が存在する。よって、固定個数のatomのoffset情報ではなく、任意の個数のoffset情報を管理したい場合が考えられる。
前述のoffset atomでは、atomのsizeが固定長であるため、想定するatom以外は管理することができない。そのため、ファイルの最後に記録するoffset atomを、図12に示すように規定する。
この場合のoffset atomは、atom sizeを可変長とし、ヘッダ領域に後続して、ファイル内に登録されているatomの数だけのファイルの任意の基準位置からのオフセット値をフィールドにもつ。
図12の例では、ヘッダ情報に後続してバックアップmoov atomへのオフセット値をフィールドに持ち、いくつかのファイル内atomへのオフセット値のフィールドが格納された後、mdat atom、moov atomのオフセット値を格納している。
そしてまた、いくつかのファイル内atomへのオフセット値をフィールドに持ち、最後にoffset atom自身へのオフセット値を格納している。さらに、QuickTimeのatomは入れ子の形態もとることができるため、atom内部にあるatomに対してもオフセット値を登録して良い。
offset atomに登録するフィールドを全て登録し終えたら、後続する4バイト(offset atomの最後の4バイト。この4バイトを書き終えるとファイルエンドとなる)にoffset atomへの基準アドレスからのオフセット値を格納する。
尚、offset atomの最後の4バイトとして、offset atomへの基準アドレスからのオフセット値ではなく、offset atomのsizeであるatom sizeを格納しても良い。このoffset atomを用いて、ファイル内に任意の個数のatomの位置情報を登録することが可能となる。
前述の決まったatomのoffset情報を管理するoffset atomの場合と異なり、本実施形態では、offset情報だけではどのatomの情報を管理しているかが分からない。このような場合のoffset atomから目的のatomにアクセスする方法を、図13のフローチャートを用いて説明する。尚、この図13では、offset atomの最後の4バイトとして、offset atomへの基準アドレスからのオフセット値が格納された場合を示している。
ステップS60において、ファイルの終了位置へ移動し、ファイルの終了部分の4バイトのデータを取得する。この値は、offset atomの先頭アドレスへの任意の基準位置からのオフセット値である。
そこで、ステップS61において、ファイル内の任意の基準位置から取得したオフセットのアドレスへ移動することにより、offset atomの先頭へ移動したことになる。
ステップS62において、現在のアドレスから8バイトのデータであるoffsetatomのヘッダ情報を取得する。ステップS63にて、取得したヘッダ情報の先頭4バイトの値がファイルサイズからoffset atomの先頭位置を引いた値(offset atomのsizeの計算値)と一致し、後続する4バイトのtypeがoffset atomの種類を示す"ofst"であるとき、取得したヘッダ情報がoffset atomであると判定する。
offset atomと判定されなかった場合は、ステップS70へ進みエラー処理をして終了する。offset atomと判定された場合は、ステップS64へ進み、現在のアドレスがoffset atomのフィールド情報の最後でないかの判定を行う。
現在のアドレスが最後のアドレス(offset atomへのオフセット値が格納されているアドレス)であった場合は、目的のatomが見つからなかったことになり、ステップS70へ進みエラー処理をして終了する。そうでなかった場合は、ステップS65へ進み、現在のアドレスから4バイトのオフセット値を取得し、任意の基準位置からオフセット値のアドレスへ移動する。
次に、ステップS66において、移動したアドレスより8バイトのヘッダ情報を取得する。そして、ステップS67において、ヘッダ情報の後半4byteのtype情報が目的のatomのtype情報であるかASCIIコードの比較を行い、目的のatomであった場合は、ステップS68により、目的atomへアクセスを行って終了する。
目的atomでなかった場合は、ステップS69にて現在のアドレスに4を加えて、次のオフセットのフィールド情報の位置に移動し、ステップS64へ戻り、目的atomが見つかるまでかoffset atomの終了位置まで前記処理を繰り返して、目的atomを検索する。
また、前記検索の場合、オリジナルのmoov atomとバックアップのmoov atomのtypeを違う名前にしてあれば良いが、そうでない場合は区別がつかなくなるため、バックアップ情報のオフセット値は、offset atom内の任意の場所に規定して登録するようにする。例えば、offset atomの先頭や最後のフィールドにバックアップデータへのオフセット値を格納する(図11、図12では、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は、図14に示すように、最初の4バイトにatom size、次の4バイトにatom typeとしてatomヘッダを記録する。後続するフィールドは、moov atomのバックアップデータの所在を示すPointフィールドであり、moov atomのバックアップデータが格納されているQuickTimeファイル名を外部ファイル名としてパスも含めて記録する。そして、最後のフィールドに、optr atomのエンド位置からoptr atom内のPointフィールドへのオフセット値を格納する。
このoptr atomを用いたQuickTimeファイルの例を図15に示す。図15においては、オリジナルのQuickTimeファイルがmoov atom、mdat atomの順番で記録され、moov atomのバックアップが格納されている外部QuickTimeファイルのファイル名を格納しているoptr atomがファイルの最後に記録されている。この図15は、optr atom内のPointフィールドが指しているQuickTimeファイルに、moov atomのバックアップのみが記録されている例であり、Pointフィールドに格納されているファイル名のQuickTimeファイルには、他のatomが複数個、記録されていても良い。
前述のoptr atomを用いたmoov atomのバックアップへアクセスする方法を説明する。オリジナルのmoov atomへのアクセスが不能となった場合は、ファイルエンドへシークした後、ファイルエンド(optr atomのエンド)の4バイトにあるoptr atom内のPointフィールドへのオフセット値により、Pointフィールドへアクセスを行い、moov atomのバックアップが登録されているQuickTimeファイル名を取得する。
そして、取得したファイル名のファイルをオープンし、異常時検索手段6によってこの外部QuickTimeファイル内のmoov atomを検索する。このように、moov atomのバックアップデータへアクセスを行うことにより、AVデータの再生を行うことが可能となる。また、前述と同じように、moov atomのバックアップデータをオリジナルのmoov atomへコピーすることにより、不具合が生じているオリジナルのQuickTimeファイル内のmoov atomを復旧することも可能となる。
また、外部に存在するmoov atomのバックアップがQuickTimeファイル形式で記録されている必要はなく、任意のデータフォーマットで記録されていても良い。この場合は、図16に示すようなoptr atomを用いて、外部にあるmoov atomのバックアップへアクセスを行う。
図16においては、最初の4バイトにatom size、次の4バイトに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ファイルの例を図17に示す。図17においては、オリジナルのQuickTimeファイルがmoov atom、mdat atomの順番で記録され、moov atomのバックアップが格納されている外部ファイルのファイル名およびその外部ファイル内におけるmoov atomのバックアップデータへのオフセット値を格納しているoptr atomがファイルの最後に記録されている。
このoptr atomは、ファイルエンド(optr atomエンド)の4バイトのoffset値がoptr atom内のPoint Offsetフィールドを指しており、このPoint Offsetフィールドが外部ファイル内のmoov atomのバックアップデータ部分を指している。そして、後続するPointフィールドがその外部ファイルを指している。また、この図17は、optr atom内のPointフィールドが指しているファイル(外部ファイル)内におけるPoint Offsetフィールドのオフセット値の位置にmoov atomのバックアップが記録されている例であり、外部ファイル内には、他のデータが記録されていても良い。
前述の外部データ内にmoov atomのバックアップデータが存在する場合のアクセス方法について説明する。オリジナルのmoov atomへのアクセスが不能となった場合は、ファイルエンドへシークした後、ファイルエンド(optr atomエンド)の4バイトにある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を復旧することも可能となる。
前述の図14乃至図17に示したoptr atomは、moov atomのバックアップデータの所在を記録してあれば良く、外部参照ファイル名に限定されるものではない。例えば、メモリ上にmoov atomのバックアップを格納した場合は、そのデータの存在するアドレスを格納しても良く、また、ネットワーク上に存在する場合は、そのデータへのURLを記録すれば良い。つまり、optr atom内には、moov atomのバックアップデータが存在している場所の所在を記録すれば良い。
また、前述のoptr atomのPointフィールドには、moov atomのバックアップ情報への所在だけでなく、例えば別ファイルに格納されているmdat atom等の任意のatomの所在を格納しても良い。
さらに、1つの外部データ内の1つのatomのみを参照するのではなく、複数の外部データ内の複数のatomを参照しても良い。その場合は、optr atomには、外部データを示す所在(例えば、ファイル名)とその外部データ内におけるある定めた基準位置から参照したいatomへのoffset値を1セットとして、必要な数だけこのセットを登録すれば良い。
前述の外部データ参照(例えば、moov atomのバックアップデータ参照)は、QuickTimeファイルに限定されたものではなく、データの先頭にデータサイズを記録した前述のデータブロックにも適用可能であり、参照するデータの所在を格納した外部参照データブロックをオリジナルのファイル内に用意することにより、外部のデータにアクセスが可能である。
以上詳述したように、あるまとまったデータにそのデータのサイズなどを表す管理情報を付加したデータブロックが記録媒体内のファイル内に1つ以上記録されている場合に、ファイル内のどこかのデータブロックの管理情報が読み取り不能となると、後続するデータブロックにアクセスできなくなる。
そのため、本実施形態のデータ記録再生装置においては、確実にアクセス可能なファイル内の最後の位置に、各々のデータブロックへアクセスするためのファイル内の任意の基準位置からのオフセット値を登録するオフセットデータブロックを設ける、或いは、このファイルとは別のデータ(例えば、外部ファイル)内に必要なバックアップデータを保持し、そのバックアップデータを持った別データの所在を登録する外部参照データブロックを設けることにより、確実に全てのデータブロックやデータブロックのバックアップへのアクセスが可能となり、読み取り不能となったデータブロックに後続するデータブロックにアクセスできないといった問題を解決することができる。
また、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を表すデータを用いて復旧させることが可能であることは明らかである。