JP4201034B2 - 映像記録ビデオカメラ装置および映像記録方法、並びにプログラム - Google Patents

Description

本発明は、映像記録ビデオカメラ装置および映像記録方法、並びにプログラムに関し、特に、記録制御中の電源遮断等が起因となってファイルシステムが壊されたような場合にも、その適切な修復を可能にする映像記録ビデオカメラ装置および映像記録方法、並びにプログラムに関する。

従来のビデオカメラは、動画記録時に、FAT（File Allocation Table）形式のファイルルシステム（以下、ファイルシステムを適宜FSと略記する）を記録していた。また、従来のビデオカメラは、動画撮影中には、MPEG（Moving Picture Experts Group）やMPEG4/AVC（MPEG-4 /Advanced Video Coding）で所定数のGOP（Group Of Pictures）を1単位として、即ち、例えばRUV（Recording Unit of Video Recording）単位で、ファイルボディの書き込みを行っていた。このように、動画ファイルの長さは例えばRUV単位で更新される。従って、従来のビデオカメラは、動画撮影途中に電源遮断が発生したとき、RUV単位でファイルボディのバックアップを取って、電源遮断発生時点までのファイル長さを演算してFSを更新して復活させていた（例えば特許文献１参照）。

特開平１１−２４２５６３号公報

しかしながら、復旧させるべき管理データをファイルとして書き込むFSそのものが壊れた場合には、復旧の手段や方法が失われてしまう。即ち、電源遮断というトラブルは何時発生するかわからず、FS更新中に発生する可能性もあり、その電源遮断の起因によりFSが壊れた場合には、電源遮断直近に記録した動画撮影データだけでなく、過去に録りためた撮影ファイル全てに対するアクセス手段が失われてしまう。

特に、FS更新中にFAT１が壊れて読めなかった場合、FAT１のコピーであるFAT２を読むことは行われてきたが、FS更新中に電源遮断があって、一律にFAT１とFAT２が異なる場合にFAT２をFAT１の代わりに読んでコピー処理することはできない。なぜならば、FAT２の書き込み途中に電源遮断がなされてFAT２が壊れてしまったならば、復旧の際にそのFAT２を読んで使用するとFSが壊れていることになるからである。また、正常に更新書き込みされたFAT１もディレクトリエントリが更新されていないのでそのままでは使えないからである。

このように、従来では、記録制御中の電源遮断等が起因となってFSが壊されたような場合には、その修復をすることは非常に困難であった。なお、このことは、FAT形式以外の別のFSについても同様である。

本発明は、このような状況に鑑みてなされたものであり、自身の更新中の電源遮断等が起因となってFSが壊されたような場合にも、その適切な修復を可能にするものである。

本発明の一側面の映像記録ビデオカメラ装置は、所定のアプリケーションフォーマットと所定のファイルシステムに従って、映像音声ストリームデータを前記アプリケーションフォーマットの記録映像ストリームデータ単位毎に記録ハードディスクにファイルとして記録する映像記録ビデオカメラ装置において、所定のファイルの前記記録ハードディスクへの記録制御として、前記映像音声ストリームデータを前記記録映像ストリームデータ単位毎に前記記録ハードディスクへ記録していく映像音声ストリーム本体データ記録制御と、前記記録ハードディスクにおける前記ファイルシステムの１以上の管理情報データテーブルを更新する管理情報データ更新制御とを行う記録制御手段と、前記記録制御手段による前記記録制御中において、前記記録映像ストリームデータ単位と前記ファイルシステムの最小記録クラスタ単位の最小公倍数の整数倍を差分情報生成データ単位として、前記差分情報生成データ単位毎に、前記アプリケーションフォーマットの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成するアプリケーションフォーマット差分生成手段と、前記記録制御手段による前記記録制御中において、前記差分情報生成データ単位毎に、前記ファイルシステムの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成するファイルシステム差分生成手段と、前記ファイルシステム差分生成手段により生成された前記ファイルシステムの属性情報についての差分情報を、前記ファイルシステムの修復に使うバックアップ情報として記憶するバックアップ記憶手段と、前記管理情報データ更新制御における前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークを記憶する進捗マーク記憶手段と、前記記録制御手段による前記記録制御が異常終了した場合、前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークの前記進捗マーク記憶手段への記憶有無に応じて、前記バックアップ記憶手段に記憶された前記バックアップ情報で所定の前記管理情報データテーブルを修復する制御を行う修復制御手段とを備える。

前記進捗マーク記憶手段は、さらに、前記記録映像ストリーム本体データ記録制御中を示す第２のマークを記憶する。

前記修復制御手段は、前記第１のマークが進捗マーク記憶手段に記憶されている場合、所定の前記管理情報データテーブルを修復する制御を行う。

前記ファイルシステムは、FAT（File Allocation Table）形式ファイルルシステムであり、前記ファイルシステムの管理情報データテーブルは、FAT1，FAT2，Directory Entryから構成されている。

前記修復制御手段は、前記FAT1，前記FAT2，前記Directory Entryの一括修復を行う。

前記ファイルシステムは、FAT（File Allocation Table）形式ファイルルシステムであり、前記ファイルシステムの管理情報データテーブルは、FAT1，FAT2，Directory Entryから構成され、前記記録制御手段による前記管理情報データ更新制御として、前記FAT1の更新制御，前記FAT2の更新制御，前記Directory Entryの更新制御がその順番で行われ、前記進捗マーク記憶手段は、前記第１のマークとして、前記FAT1の書き込み開始を示す第１−０のマークを記憶し、前記FAT2の書き込み開始を示す第１−１のマークを記憶し、前記Directory Entryの書き込み開始を示す第１−２のマークを記憶し、前記修復制御手段は、前記第１−０のマークが前記進捗マーク記憶手段に記憶されている場合、前記FAT1，前記FAT2，前記Directory Entryの修復を行い、前記第１−１のマークが前記進捗マーク記憶手段に記憶されている場合、前記FAT2，前記Directory Entryの修復を行い、前記第１−２のマークが前記進捗マーク記憶手段に記憶されている場合、前記Directory Entryの修復を行う。
前記記録映像ストリームデータ単位は、ＲＵＶ（Recording Unit of Video Recording）である。

本発明の一側面の映像記録方法は、所定のアプリケーションフォーマットと所定のファイルシステムに従って、映像音声ストリームデータを前記アプリケーションフォーマットの記録映像ストリームデータ単位毎に記録ハードディスクにファイルとして記録する映像記録ビデオカメラ装置の映像記録方法において、所定のファイルの前記記録ハードディスクへの記録制御として、前記映像音声ストリームデータを前記記録映像ストリームデータ単位毎に前記記録ハードディスクへ記録していく映像音声ストリーム本体データ記録制御と、前記記録ハードディスクにおける前記ファイルシステムの１以上の管理情報データテーブルを更新する管理情報データ更新制御とを行い、前記記録制御中において、前記記録映像ストリームデータ単位と前記ファイルシステムの最小記録クラスタ単位の最小公倍数の整数倍を差分情報生成データ単位として、前記差分情報生成データ単位毎に、前記アプリケーションフォーマットの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成し、前記記録制御中において、前記差分情報生成データ単位毎に、前記ファイルシステムの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成し、生成された前記ファイルシステムの属性情報についての差分情報を、前記ファイルシステムの修復に使うバックアップ情報としてバックアップ記憶手段に記憶し、前記管理情報データ更新制御における前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークを進捗マーク記憶手段に記憶し、前記記録制御が異常終了した場合、前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークの前記進捗マーク記憶手段への記憶有無に応じて、前記バックアップ記憶手段に記憶された前記バックアップ情報で所定の前記管理情報データテーブルを修復する制御を行うステップを含む。

本発明の一側面のプログラムは、上述した本発明の一側面の映像記録方法に対応するプログラムである。

本発明の一側面においては、所定のアプリケーションフォーマットと所定のファイルシステムに従って、映像音声ストリームデータを前記アプリケーションフォーマットの記録映像ストリームデータ単位毎に記録ハードディスクにファイルとして記録する記録制御として、前記映像音声ストリームデータを前記記録映像ストリームデータ単位毎に前記記録ハードディスクへ記録していく映像音声ストリーム本体データ記録制御と、前記記録ハードディスクにおける前記ファイルシステムの１以上の管理情報データテーブルを更新する管理情報データ更新制御とが行なわれ、前記記録制御中において、前記記録映像ストリームデータ単位と前記ファイルシステムの最小記録クラスタ単位の最小公倍数の整数倍を差分情報生成データ単位として、前記差分情報生成データ単位毎に、前記アプリケーションフォーマットの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報が順次生成され、前記記録制御中において、前記差分情報生成データ単位毎に、前記ファイルシステムの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報が順次生成され、生成された前記ファイルシステムの属性情報についての差分情報が、前記ファイルシステムの修復に使うバックアップ情報としてバックアップ記憶手段に記憶され、前記管理情報データ更新制御における前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークが進捗マーク記憶手段に記憶され、前記記録制御が異常終了した場合、前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークの前記進捗マーク記憶手段への記憶有無に応じて、前記バックアップ記憶手段に記憶された前記バックアップ情報で所定の前記管理情報データテーブルを修復する制御が行われる。

以上のごとく、本発明の一側面によれば、ファイルシステムを利用した記録制御ができる。特に、その記録制御中の電源遮断等が起因となってファイルシステムが壊されたような場合にも、その適切な修復を可能にすることができる。

以下に本発明の実施の形態を説明するが、本発明の構成要件と、明細書又は図面に記載の実施の形態との対応関係を例示すると、次のようになる。この記載は、本発明をサポートする実施の形態が、明細書又は図面に記載されていることを確認するためのものである。従って、明細書又は図面中には記載されているが、本発明の構成要件に対応する実施の形態として、ここには記載されていない実施の形態があったとしても、そのことは、その実施の形態が、その構成要件に対応するものではないことを意味するものではない。逆に、実施の形態が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その実施の形態が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。

次に、図面を参照して、本発明の実施の形態について説明する。

図１は、本発明が適用される情報処理装置としての記録再生装置１の機能的構成例を示している。

図１の例では、記録再生装置１は、システム制御部１１乃至Backupメモリ１９を含むように構成されている。

システム制御部１１は、記録再生制御部２１乃至バックアップメモリ制御部２５を含むように構成されている。

記録再生制御部２１は、映像音声データの記録または再生に必要な一連の処理の総括制御を行う。なお、記録再生制御部２１の記録制御の具体例については、図４を参照して後述する。

アプリケーションフォーマット制御部２２は、例えば映像音声データとして静止画データが記録再生装置１に与えられた場合、その圧縮された静止画データを、静止画のアプリケーションフォーマット、例えば、JPEG（Joint Graphics Experts Group）、JFIF（Jpeg File Interchange Format）、EXIF（Exchangeable Image file Format）、TIFF（Tag Image File Format）等に変換するためのファイルヘッダ等の管理情報を生成する。また例えば映像音声データとしてSD（Standard Definition）動画像が記録再生装置１に与えられた場合、アプリケーションフォーマット制御部２２は、その圧縮された動画像を、動画像のアプリケーションフォーマット、例えば、MPEG等に構成するためのシステムストリーム管理情報を生成する。また例えば、映像音声データとしてHD（High Definition）動画像が記録再生装置１に与えられた場合、アプリケーションフォーマット制御部２２は、その圧縮されたHD動画像を、HD動画像のアプリケーションフォーマット、例えば、Ｈ２６４／ＡＶＣ等のHDアプリケーションフォーマットに構成するシステムストリーム管理情報を生成する。

FATファイルシステム制御部２３は、FATファイル形式での映像音声データの記録再生を制御する。なお、FATファイルシステム制御部２３の記録制御の具体例については、図４を参照して後述する。

メモリカード／HDDドライブ制御部２４は、例えばハードディスクドライブ１６に対する制御として、ATAPIプロトコルに従い、ドライブ内部ファーム情報を取得してドライブメディア状態を監視し、ドライブメディア状態に応じて、ハードディスクドライブ１６への記録再生開始を指示する。また、メモリカード／HDDドライブ制御部２４は、リムーバブルメディア５等に対しても同様に制御を行い、その記録再生開始を指示する。

なお、実際には、ハードディスクドライブ１６内のハードディスク４１（図１には図示せず、図３参照）にデータが記録されることになるが、適宜、ハードディスクドライブ１６にデータが記録されると略記する。

バックアップメモリ制御部２５については、後述するBackupメモリ１９の説明と併せて説明する。

映像音声入出力I/F１２は、外部機器との間で映像音声データの入出力を行う。外部機器としては、図１の例では、カメラやマイク等で構成される映像音声出力装置４が映像音声入出力I/F１２に接続されている。その他、映像音声入出力I/F１２から出力される音声データに対応する音声を出力するスピーカや、映像音声入出力I/F１２から出力される映像データに対応する映像を表示するモニタ等も、外部機器として映像音声入出力I/F１２に接続され得る。

エンコード／デコード部１３は、映像音声入出力I/F１２から提供された映像音声データを圧縮して、その結果得られる圧縮映像音声データをデータ制御部１４に提供する。また、エンコード／デコード部１３は、データ制御部１４から提供された圧縮映像音声データを伸張して、その結果得られる映像音声データを映像音声入出力I/F１２に提供する。

データ制御部１４は、記録時には、エンコード／デコード部１３から提供された圧縮映像音声データと、アプリケーションフォーマット制御部２２により生成された映像音声データの管理情報とを蓄積し、記録開始に備える。

ドライブ制御部１５は、記録対象の圧縮映像音声データが、システムストリームとして、エンコード／デコード部１３からSCR時刻情報付の2kバイトの空パケット単位で順次提供されてくると、それらから、GOP単位で格納されたビデオオブジェクト単位（VOBU）を生成し、VOBUが１個ないし複数個集合されたセル（CELL）またはRUV（Recording Unit Video Object）をデータ制御部１４に蓄積し、CELLまたはRUVをまとめて、ハードディスクドライブ１６やリムーバブルメディア５等のメディアに記録する制御を行っている。例えばデータ制御部１４に数１０MB分のCELLまたはRUVが蓄積されると、ドライブ制御部１５は、それらのCELLまたはRUVをまとめてハードディスクドライブ１６に記録する制御を繰り返し行っている。本実施の形態ではでは、１記録チャプタにつき１ファイルが生成され、ハードディスクドライブ１６やリムーバブルメディア５等のメディアに記録される、としている。

User I/F１７は、ユーザにより操作される操作装置２からの入力を受け付けるユーザインタフェースである。操作装置２は、例えばリモートコントローラや、記録再生装置１に内蔵されるパネルを利用したタッチパネル装置等により構成される。

PC入出力I/F１８は、パーソナルコンピュータ３との間で情報の入出力を受け付けるユーザインタフェースである。

Backupメモリ１９には、例えば図２に示されるように、アプリケーションフォーマットバックアップテーブル３１（以下、BUp Table_App３１と記述する）、および、ファイルシステムバックアップテーブル３２（以下、BUp Table_FS３２と記述する）が記録される。かかるBUp Table_App３１とBUp Table_FS３２とへの情報の記述や更新がバックアップメモリ制御部２５（図１）によりなされる。

即ち、バックアップメモリ制御部２５は、VOBUの集合であるRUV単位のハードディスクドライブ１６への書き込み処理（以下、RUV書き込み処理と称する）ＳＲ−Ｋ（Ｋは、整数値であって、図２の例ではＫ＝１乃至３のみ図示されている）毎に、アプリケーションフォーマットの更新差分情報をBUp Table_App３１にバックアップする処理（以下、BUp Table_App更新処理と称する）ＳＡ−Ｋと、ファイルシステムの更新差分情報をBUp Table_FS３２にバックアップする処理（以下、BUp Table_FS更新処理と称する）ＳＦ−Ｋとを実行する。

なお、ここで、更新処理とは、各テーブル（BUp Table_App３１やBUp Table_FS３２）の構成によって、各更新差分情報自体を、前に記録されていた各更新差分情報の上に上書きしていく処理をいうこともあるし、前に記録されていた各更新差分情報の削除を行わずに、各更新差分情報を別の領域に記憶していくことで、複数の更新差分情報を蓄積する処理をいう場合もある。かかる両者の処理の差異については、後述する。

また、本実施の形態では、アプリケーションフォーマットの更新差分情報としては、アプリケーションフォーマットの属性管理情報データの更新前後の差分情報が採用されており、一方、ファイルシステムの更新差分情報とは、FATファイルシステムの属性管理情報データの更新前後の差分情報が採用されている。

より具体的には、ファイルのオープン（以下、fopenと記述する）時においては、これから記録する新規記録ファイル用のエントリ（ファイル名、エントリ、アプリ属性のビデオ属性、オーディオ属性、アプリケーションフォーマット形式属性情報など記録開始時に定まる初期属性情報）が作成され、BUp Table_App３１に記述される。

また、fopen時においては、これから記録する新規記録ファイル用のエントリ（ファイル名、ディレクトリ、エントリ情報、ファイル生成日時、FATファイル形式属性情報など記録開始時に定まるファイルシステムの初期属性情報）が作成され、BUp Table_FS３２に記述される。

換言すると、新規ファイルが生成される毎に、その新規ファイル用のBUp Table_App３１とBUp Table_FS３２とが生成される、と捉えてもよい。

その後、動画のMPEG圧縮データのアプリケーションフォーマットストリームであるファイルボディデータの１RUVの書き込みが完了する毎に、即ち、RUV書き込み処理ＳＲ−Ｋ毎に、ファイルボディデータの更新属性情報（エントリＩＤ、時刻、サイズなどの更新属性情報）が、BUp Table_App３１に順次バックアップされる。即ち、BUp Table_App更新処理ＳＡ−Ｋが順次実行される。

また、RUV書き込み処理ＳＲ−Ｋ毎に、ファイルシステムデータの更新属性情報（エントリＩＤ、時刻、サイズなどの更新属性情報、ファイルサイズ境界超えの場合につづいて新規に生成されるファイルエントリＩＤやファイル生成日時、FATファイル形式属性情報など記録開始時に定まるファイルシステムの初期属性情報のバックアップエントリ）が、BUp Table_FS３２に順次バックアップされる。即ち、BUp Table_FS更新処理ＳＦ−Ｋが順次実行される。

図１のバックアップメモリ制御部２５は、アプリケーションフォーマット制御部２２がドライブのメディアを認識しない状態では、BUp Table_App３１とBUp Table_FS３２との内容またはそれ自体をクリアする。

また、バックアップメモリ制御部２５は、例えば記録先がメモリカードドライブとして構成されるリムーバブルメディア５であった場合には、取り出し時にこれを検出して、存在しなくなるメモリカードドライブ内部に対応するバックアップ情報が記憶されているBUp Table_App３１とBUp Table_FS３２との内容またはそれ自体をクリアする。

また、バックアップメモリ制御部２５は、PC入出力I/F１８でドライブがシステム制御部１１のFATファイルシステム制御部２３やアプリケーションフォーマット制御部２２と論理的に切り離されてドライブとして接続される状態に入る際には、書き換え可能性のあるハードディスクドライブ１６あるいはリムーバブルメディア５の内部に対応するバックアップ情報が記憶されているBUp Table_App３１とBUp Table_FS３２との内容またはそれ自体をクリアする。

このようなBUp Table_App３１やBUp Table_FS３２にバックアップされた更新差分情報は、記録再生装置１の電源遮断後等の復旧制御に使用される。また、かかる復旧制御には、処理進捗ステップを示すバックアップマーク（以下、BUp Markと記述する）も使用される。そこで、BUp Markも、BUp Table_App３１とBUp Table_FS３２とのうちの少なくとも一方（本実施の形態では両方）に記述される。ただし、復旧制御やBUp Markの詳細については、図５以降を参照して後述する。

ここで、高画質長時間撮影でのBackupメモリ１９のサイズ（以下、適宜バックアップメモリサイズと称する）と、BUp Table_FS更新処理ＳＦ−Ｋの回数Ｋ（以下、適宜ＦＳ差分バックアップ回数）について説明する。

映像音声ストリーム撮影用の記録メディアとして例えばハードディスクドライブ１６を使用する場合、１ファイルで連続長時間記録が実現可能になってしまうことから、ＦＳ差分バックアップ回数は、バックアップメモリサイズを考慮して決定する必要がある。

１連続長時間記録では、その記録終了時にはじめて、ハードディスクドライブ１６に対してFSの管理情報の更新書き込みが発生する。換言すると、その記録中は、１RUV分の書き込みデータについてのFSの更新差分情報のハードディスクドライブ１６への書き込みは行えず、その記録終了時までは、FSの更新差分情報のBackupメモリ１９へのバックアップはそのまま続けなければならない。

ここで、次のように単純化した場合を考える。即ち、単純にFATの管理情報についての更新差分情報だけを考慮する。また、後述するBUp Markのセットおよびクリアに必要なバイト数８バイト程度は誤差であると考える。記録開始マーク、記録ストリームファイルのオープン情報、ファイル生成情報なども誤差範囲であると考える。連続記録で１チャプタがファイルシステムの１ファイルサイズ上限に到達することを考慮せず、１ファイルで長時間大量データファイルサイズを作成できるとする。このように単純化した場合を考える。

この場合、FSの更新差分情報のBackupメモリ１９へのRUV書き込み処理ＳＲ−Ｋ毎のバックアップに必要なバックアップメモリサイズとして、例えばＨＤ−ＸＰの１RUV（時間５秒前後）の映像音声圧縮ストリームデータ記録書き込み発生毎のバックアップに必要なバックアップメモリサイズと、ＳＤ−ＬＰの１RUV（時間３０秒余り）記録書き込み発生毎のバックアップに必要なバックアップメモリサイズを考える。

具体的には例えば、前者については、ヘッダ６バイト、データ１０バイト、合わせて１６バイトを想定し、さらに、ＨＤ−ＸＰの１RUVを５秒として、６０Ｇバイトで８時間撮影できるとすると、バックアップメモリサイズは、１６バイト＊５７６０（２８８００秒／５秒）＝９２１６０バイトとなる。即ち、約９０ｋバイトがバックアップメモリサイズとして必要になる。

また、後者については、ＳＤ−ＬＰの１RUVを３０秒として、６０Ｇバイトで４０時間撮影できるとすると、バックアップメモリサイズは、１６バイト＊４８００（１４４０００秒／３０秒）＝７６８００バイトとなる。即ち、約７５ｋバイトがバックアップメモリサイズとして必要になる。

ここで、例えば、Backupメモリ１９として６４ｋバイトのフラッシュメモリが採用された場合を考える。また、その連続使用中に使用量がいっぱいに近づいたときには別領域に切り替え使用が必要になってくること、FSだけがそのBackupメモリ１９を占有使用できるシステム仕様は稀なことを考慮する。そして例えば、割当て１単位が３２ｋバイトの２領域交互使用とされたときには、１RUVデータ相当の映像音声表示時間が短いＨＤ−ＸＰでは直前約５秒の１RUVは捨ててよいとし、また、２日間の長時間連続撮影で電源遮断があったら直前の３０秒分のデータは捨ててよいなどの仕様割り切りの判断をしたとする。このような場合には、FSの更新差分情報のBackupメモリ１９へのバックアップ回数は、図２のように１RUV毎とするのではなく、２乃至３RUV毎程度に１回とする、などの工夫処置の必要に迫られる。

以下、より一般的な仕様として、Backupメモリ１９のサイズを節約すべく、連続撮影記録中に各RUVの撮影途中での書き込みエラーが発生した時点で記録中断し、その時点までの映像記録を１チャプタとして記録メディア（以下、説明の簡略上、ハードディスクドライブ１６とする）に記録して、撮影記録終了してしまう、といった仕様を考える。

さらに、直前の最終RUVと、念のためにその前の２乃至３RUV分のストリームデータの記録によるFSの更新差分情報をBackupメモリ１９に保持させ、それ以前のFSの更新差分情報はBackupメモリ１９に既に書きこまれていても、それに対する上書きを可能な運用にする、といった仕様とする。

換言すると、RUV書き込み処理ＳＲ−Ｋ毎に、即ち、１RUV分のデータの書き込み毎に、バックアップメモリ制御部２５は、FSの更新差分情報を順次バックアップしていく制御を行うとする。ただし、Backupメモリ１９側では、所定の記憶割当て領域サイズのアドレス範囲内で、FSの更新差分情報のアドレス位置を順次送って、新たなFSの更新差分情報を順次記憶していくが、割り当てられた領域をいっぱい最後まで使い切ったら、記憶のアドレス位置を最初に戻して上書きしていくとする。即ち、リングバッファ的記憶制御仕様とする。

ここで、ハードディスクドライブ１６側では、撮影１ファイルの書き込みでFSの管理情報の更新（以下、適宜FSの書き込み更新とも称する）を必要とするタイミングは、撮影停止または電源遮断修復の結果として、その１ファイルの書き込みが完成したときの１度だけであるとする。

この場合、目的とするFSの書き込み更新中の電源遮断が発生して、FSの管理情報が壊れたときに、次のようにすることで、FSの管理情報の復活が可能になる。即ち、電源遮断が発生するまでにハードディスクドライブ１６にRUV単位で連続記録されていたRUVの集合体であって、その電源遮断が発生する直前に最後にハードディスクドライブ１６に記録されたRUVまでの集合体を１ファイルとする。この１ファイルの最終的なトータルデータサイズやアドレス位置を確定でき、かつ、FSの書き込み更新ができるのに十分なFSの更新差分情報が、Backupメモリ１９に保持されていれば、電源遮断発生時に最終的にBackupメモリ１９にバックアップされたFSの更新差分情報から、FSの管理情報の復活が可能になる。

そこで以下、連続撮影記録中のFSの更新差分情報（FSの管理情報の差分データ）に対するバックアップ制御仕様について説明する。

連続撮影記録中の１ファイルの最終的なトータルデータサイズとトータルなファイルアドレス位置を確定でき、かつ、FSの書き込み更新ができるのに十分なFSの更新差分情報を、Backupメモリ１９に保持させるためには、次のようにすればよい。即ち、この１ファイルの最終的なトータルデータサイズデータを、FSの更新差分情報のひとつ（バックアップ情報）としてBackupメモリ１９に記憶させる。そして、ハードディスクドライブ１６への最終のRUVデータの書き込み成功後のFSの書き込み更新に使用されるFSの更新差分情報については、上書き消去されないように、Backupメモリ１９の書き込みアドレス位置管理制御を行うべく、リングバッファ的記憶制御を行うとする。或いは、FSの上位層であり、電源遮断があった場合にFS修復確認より先行して、修復確認するアプリケーションフォーマットの修復処理制御の都合があればその都合に合わせた上で、書き込み成功した最終RUVおよびその数RUV前までのRUVデータ書き込みについて、上書き消去されないように、同様なリングバッファ的記憶制御を行うようにしてもよい。これにより、Backupメモリ１９のサイズを例えば３２ｋバイトに収めることができる。

なお、３２ｋバイトといったように、Backupメモリ１９がある程度の大きなサイズを必要とする理由は、次の通りである。即ち、FSの更新差分情報のBackupメモリ１９へのバックアップ書き込み動作は、1RUV分のデータが記録メディアへ書き込まれる毎に行われるとする。また、Backupメモリ１９がフラッシュメモリで構成されているとする。この場合、その書き込み回数の耐久性は、およそ１書き込みブロックに対して３０万回程度である。従って、あまりに頻繁な書換えが同一ブロックに対して局所的に発生すると、ブロックの大きな集合体で構成されているフラッシュメモリ全体のチップ寿命が早く尽きてしまう。そこで、リングバッファ的アドレス制御により平均的に使用していき、局所的書き込みによるブロック劣化が招くBackupメモリ１９全体の使用不可状態に陥るのを回避する必要がある。これを実現するためには、ある程度の数のブロックが必要になるから、即ち、ある程度の大きさのメモリサイズが必要になるからである。

次に、連続長時間撮影記録中の場合に複数ファイルを１チャプタとして記録する仕様に本実施の形態を適用する例について説明する。

例えば、FSの１ファイルデータの最大データサイズを超えた連続長時間撮影記録中に限る仕様であって、所定の大容量データを超えて記録が進んだ場合には、１ファイルを１チャプタとして取り扱うのではなく、所定のデータサイズごとに、例えばアプリケーションフォーマット制御部２２に実装制御として予め実装されたサイズごとに、即ち、定められた数１００メガバイトや数Ｇ（ギガ）バイトごとに１ファイルとして、それらの各ファイルの集合体を１チャプタとして記録する仕様、即ち、１チャプタ内で複数ファイルを分割して記録する仕様が考えられる。

例えば以下、ＭＰＥＧ−ＰＳの再生技術を用いて、即ち、時間連続する複数ＭＰＥＧストリーム間のシームレス接続再生技術を用いて、アプリケーションフォーマット制御部２２等が、長時間記録の場合に限って、時間連続する複数ファイルを、１チャプタ内部の分割ファイル記録されたファイルであるとみなして、その１チャプタを再生する制御仕様が採用された場合について考える。

この場合、ＨＤ−ＸＰでハードディスクドライブ１６が６０ＧＢ容量で、８時間撮影の場合に１Ｇバイトごとに１ファイル記録されるとすれば、６０分割されたファイルが連続的にハードディスクドライブ１６に記録されることになる。

その際、順次生成される各ファイルのそれぞれについて、FSの更新差分情報が存在することになる。また、連続撮影時間中（１チャプタ記録中）、順次ファイルオープンされハードディスクドライブ１６への書き込みがなされてファイルが完成されていく度に、完成されたファイルについてのFSの管理情報は確定することになる。

そこで、記録再生装置１は、撮影中のチャプタに属する１ファイルの書き込み処理が確定した時点で、そのファイルのFSの更新差分情報を利用してFSの書き込み更新を行い、それに引き続き、次のファイルをオープンして、同一チャプタの次の１ファイル書き込み処理にうつる、といった一連の処理を繰り返し実行すればよい。

また、別仕様として、長時間撮影中にファイル単位毎のFSの書き込み更新を行わずに、長時間撮影が終了したときにだけ、それら各ファイル全てについてのFSの管理情報をまとめてFSの書き込み更新を行う、といった仕様を記録再生装置１に適用する例について説明する。

この場合、時間連続した撮影１チャプタ内で、時間連続したストリームの入った各ファイル全てについてのFSの更新差分情報を利用して、FSの書き込み更新の処理を実行する必要になる。従って、この処理中に電源遮断が発生したら、次の電源投入時にFSの修復を実行する際に、Backupメモリ１９内のFSの更新差分情報の読出し処理が必要となる。

この場合、長時間撮影中には各１ファイルが完成する度に、完成された１ファイルデータは確定されて、以後更新されない。そこで、記録再生装置１は、完成された１ファイルのFSの更新差分情報については、Backupメモリ１９内で上書き禁止扱いに設定して、以後のリングバッファでのBackupメモリ１９へのFSの更新差分情報の書き込み対象アドレス指定位置範囲から外す。

即ち、連続する長時間撮影中の１チャプタ書き込み期間中においては、順次完成された書き込み済みファイルについてのFSの更新差分情報は、これ以上更新不要な完成されたFSのバックアップ情報として取扱い、Backupメモリ１９側では、現在の連続長時間撮影続行中は上書き禁止属性として取り扱う、といった制御を記録再生装置１が行えばよい。

このような制御を記録再生装置１が行うことによって、長時間撮影のため記録データのサイズがFSの１ファイルの最大データサイズよりも結果的に大きく超えてしまうために、長時間撮影による１チャプタが複数ファイルで構成される撮影状況となってしまうような場合であっても、FSの管理情報を復活させるために必要な複数ファイルの各FSの更新差分情報は問題なくBackupメモリ１９に保存される。従って、長時間撮影がかなり進行した後のFSの書き込み更新中に電源遮断が発生しても、FSの修復が可能になる。

次に、図３を参照して、図１の記録再生装置１が、動画データを１つのファイル（1チャプタ）としてハードディスクドライブ１６に記録するまでの一連の処理例について説明する。

ステップＳ１において、操作装置２等から動画記録開始命令が発行されると、記録再生装置１は、ステップＳ２において、ハードディスクドライブ１６のハードディスク４１に対して、fopen（ファイルのオープン）を行う。

このステップＳ２のとき、上述したように、これから記録する新規記録ファイル用のエントリ（ファイル名、エントリ、アプリ属性のビデオ属性、オーディオ属性、アプリケーションフォーマット形式属性情報など記録開始時に定まる初期属性情報）が作成され、図２のBUp Table_App３１に記述される。また、これから記録する新規記録ファイル用のエントリ（ファイル名、ディレクトリ、エントリ情報、ファイル生成日時、FATファイル形式属性情報など記録開始時に定まるファイルシステムの初期属性情報）が作成され、図２のBUp Table_FS３２に記述される。

記録再生装置１は、ステップＳ３において、ハードディスク４１に対して、ファイルの書き込み開始（以下、fwriteと記述する）を行い、ステップＳ４において、ファイルボディデータを例えば１RUV単位でハードディスク４１の領域４１−１に順次書き込む処理（以下、ファイルボディ書き込み処理と称する）を実行する。

即ち、ステップＳ４のファイルボディ書き込む処理とは、図２のRUV書き込み処理ＳＲ−Ｋの繰り返し処理の集合体をいう。従って、このステップＳ４の処理では、RUV書き込み処理ＳＲ−Ｋ毎に、上述したBUp Table_App更新処理ＳＡ−ＫとBUp Table_FS更新処理ＳＦ−Ｋとがそれぞれ順次実行される。

ステップＳ５において、操作装置２等から動画記録終了命令が発行されると、記録再生装置１は、最終RUVデータのハードディスク４１への書き込みを完了させ、システム制御部１１の後述する図４のMovie Rec制御部６１により取得された各種情報から、ファイルエントリ情報、生成時刻、サイズなどの情報を生成して、これらの情報から、ステップＳ６において、ハードディスク４１の領域４１−２に対するFAT１の更新書き込み処理（以下、FAT1更新処理と称する）を実行し、ステップＳ７において、ハードディスク４１の領域４１−３に対するFAT２の更新書き込み処理（以下、FAT2更新処理と称する）を実行し、ステップＳ８において、ハードディスク４１の領域４１−４に対するDirectory Entryの更新書き込み処理（以下、Directory Entry更新処理と称する）を実行する。

そして、ステップＳ９において、記録再生装置１は、ハードディスク４１に対して、ファイルのクローズ（以下、fcloseと記述する）を行う。

このように、図３の例では、最終RUVの書き込み終了後に、ステップＳ６乃至Ｓ８の処理が実行されたが、即ち、ファイルボディの全ての書き込み終了後にFAT1，FAT2，Directory Entryの更新が行われたが、FAT1，FAT2，Directory Entryの更新タイミングは図３の例に限定されず、ファイルボディの所定単位の書き込みが行われる毎に、FAT1，FAT2，Directory Entryの更新がその都度行われてもいい。

ただし、ファイルボディの所定単位の書き込みが行われる毎にFAT1，FAT2，Directory Entryの更新がその都度行われることについては後述することにする。即ち、ここでは、図３の例と同様に、ファイルボディの全ての書き込み終了後にFAT1，FAT2，Directory Entryの更新が行われるとして、以下話を進めていく。

図４は、図３のステップＳ５の動画記録終了命令が発行された以降の処理の詳細例を説明するフローチャートである。

図４の例では、記録再生制御部２１には、Movie Rec制御部６１乃至Encoder Driver制御部６４のそれぞれが設けられており、それらの下方の点線矢印に示される処理がそれぞれ実行される。また、FATファイルシステム制御部２３には、File System制御部６５が設けられており、その下方の点線矢印に示される処理が実行される。

ステップＳ５の動画記録終了命令が発行されると、MovieRec 制御部６１は、RUV Data Buffer制御部６３に、その動画記録終了命令を通知する。

すると、RUV Data Buffer制御部６３は、ステップＳ３１において、Encoder Driver制御部６４に対して、終了最終RUVの作成を開始させる。ステップＳ３２において、Encoder Driver制御部６４は、図１のエンコード／デコード部１３乃至ドライブ制御部１５を制御して、終了最終RUVの一連のVOBUとVOBU_Table情報の作成を行う。即ち、VOBU毎にRUVデータとして、RUV Data Buffer制御部６３により制御されるデータ制御部１４のバッファに蓄積されていくことで、終了最終RUVの一連のVOBUが順次生されてゆき、また、そのVOBU_Table情報もデータ制御部１４のバッファに蓄積される。

このようにして、終了最終RUVの一連のVOBUとVOBU_Table情報がデータ制御部１４のバッファに蓄積されると、RUV Data Buffer制御部６３は、ステップＳ３３において、終了最終RUV作成完了の応答を、Movie Rec制御部６１に通知する。

この通知を受けたMovie Rec制御部６１は、ステップＳ３４において、MovieInfo部６２を制御して、アプリケーションフォーマットに基づく情報データ（以下、Info情報と称する）を、終了最終RUVに付加させる制御を行い、ステップＳ３５において、終了最終RUV書き込みをFileSystem制御部６５に対して指示する。

即ち、ステップＳ３４において、MovieInfo部６２は、アプリケーションフォーマット制御部２２やFATファイルシステム制御部２３を制御して、データ制御部１４のバッファに蓄積されているデータにアプリケーション情報をInfo情報として付加することで、記録システムストリームとしての書き込み用終了最終RUVデータを完成させる。そして、ステップＳ３５において、終了最終RUV書き込みの命令がFileSystem制御部６５に対して発行される。

すると、ステップＳ３６において、FileSystem制御部６５は、メモリカード／HDDドライブ制御部２４とドライブ制御部１５とを制御して、終了最終RUVを、ファイルボディとしてハードディスクドライブ１６のハードディスク４１の領域４１−１（図３）に引き続き書き込む。

以上のステップＳ５による動画記録終了命令発行後のステップＳ３１乃至Ｓ３６の処理制御が、アプリケーションフォーマットとしての書き込み制御である。

かかるアプリケーションフォーマットとしての書き込み制御が終了すると、ステップＳ３７において、FileSystem制御部６５は、終了最終RUVのハードディスクドライブ１６への書き込みが完了したことを、RUV Data Buffer制御部６３を介してMovie Rec制御部６１に通知する。

すると、Movie Rec制御部６１は、ファイルクローズ処理を、FileSystem制御部６５に通知する。この通知を受けて、FileSystem制御部６５は、上述したステップＳ６乃至Ｓ８の処理、即ち、FAT1，FAT2，Directory Entryの各更新処理を実行する。

ここで、図３と図４とを用いて説明した動画データの記録処理中に、記録再生装置１の電源遮断が発生した場合を考える。

図３の例では、ステップＳ６のFAT1更新処理の期間Ｔ２、ステップＳ７のFAT2更新処理の期間Ｔ３、および、ステップＳ８のDirectory Entry更新処理の期間Ｔ４のそれぞれは、ステップＳ４のファイルボディ書き込み処理の期間Ｔ１とほぼ同等の長さで描画されている。しかしながら、実際には、期間Ｔ２、期間Ｔ３、および、期間Ｔ４のそれぞれは、期間Ｔ１と比較すると遥かに短い。従って、期間Ｔ２、期間Ｔ３、および、期間Ｔ４における電源遮断の発生確率は、期間Ｔ１におけるその確率に比較して遥かに低い。

具体的には例えば、図３のFAT1の領域４１−２のサイズはマイクロソフトの WhitePaper で規定される。通常、例えば FAT １つあたり約3MByte程度が標準的なサイズとなる。ただし、ステップＳ６のFAT1更新処理で１RUV分の差分情報データの更新だけを行うとすれば、1個のFAT１につき、４セクタ（2kByte）の更新書き込みとなる。即ち、FAT2についても1個につき、４セクタの更新書き込みとなる。また、Directory Entryの更新も、標準的には４セクタの更新になり、メディアへの書き込み時間もFATと同程度となる。

小型のハードディスク４１をメディアとした場合、１コマンド書き込み時間のうちの、FS の更新タイミングの経過時間を見積もると、メディアの書き込みレートは 180Mbps 乃至80Mbps なので、４セクタ（2kByte）単位更新でのFSの差分情報のメディアの実際の書き込み時間はコマンドレスポンス分の50 乃至150μ秒程度に収まる。他方、１コマンド書き込み時間中の、シーク動作（図３中ハードディスク４１内の実線または点線で示される動作）の占める経過時間が最も長い。コマンドを受けてからシークして、４セクタの更新がなされて書き込みが完了するので、１シークで10乃至20 msec 程度かかることになる。

従って、期間T2乃至T4のFS更新期間中を狙った任意の電源遮断が発生した場合、FSの更新情報書き込み時間、即ち、期間T2乃至T4のうち、メディアにFSの更新情報を書き込みしているタイミングの時間が占める割合は、1/100 乃至1/200 程度となる。そして例えば１チャプタ撮影時間、即ち期間T1乃至T4全体の時間を200秒とすると、撮影時間中のFSの更新期間T2乃至T4が占める時間割合は 1/10000 となる。従って、メディアにFSの更新情報を書き込みしているタイミングに電源遮断が発生する確率は、 1/1000000 程度の確率になる。このように、たとえ記録中を狙った電源遮断が発生したとしても、その電源遮断がFSの更新期間中に発生することは稀である。

そこで、従来は、電源遮断が発生するタイミングとして、発生確率の低いFS更新期間T2乃至T4は考慮せずに、ステップＳ４のファイルボディ書き込み処理の期間T1に発生する第１のタイミングと、ステップＳ８のDirectory Entry更新処理の期間T4経過後以降に発生する第２のタイミングとを考慮して、図５に示されるように、ステップＳ３のfwrite前のステップＳ５１の処理でBUp Mark1を付与し、ステップＳ８のDirectory Entry更新処理の期間Ｔ４終了後のステップＳ５２の処理で、そのBUp Markをクリアする、という手法が採用されていた。なお、BUp Mark1の符号「１」は、後述するBUp Mark2等の符号「２」と区別するために付されている。

このような従来の手法では、電源遮断が発生した場合に、BUp Mark1が存在するときには、その電源遮断の発生タイミングは、期間T1内の第１のタイミングであるとみなしていた。かかる第１のタイミングでは、［FATは更新前の正常状態］なので、アプリケーション層からデータ差分情報を元に再度FAT差分更新を行うことで修復が可能である。一方、BUp Mark1が存在しないときは、期間T4終了後以降の第２のタイミングとみなしていた。かかる第２のタイミングならば、［FATとファイルは更新後の正常状態］なので FS に問題ない。第１のタイミングと第２のタイミングの両者とも、FS は正常動作状態なので、記録再生装置１は FS を使ってデータを修正して fclose しなおすことができる。

しかしながら、電源遮断が発生した場合にBUp Mark1が存在するときとは、実際には、期間T1内の第１のタイミングで電源遮断が発生したときのみならず、FSの更新期間T2乃至T4内の第３のタイミングで電源遮断が発生したときも可能性として存在する。かかる第３のタイミングとなる可能性は、第２のタイミングとなる可能性と比較して、上述したように遥かに低いとはいえ、０ではない。従って、第３のタイミングに電源遮断が発生した場合には［FAT は更新途中の不正状態］なので、FATの修復ができない可能性がある。FATが修復できなければ、アプリケーション層からは不可視な未使用領域がメディア上に残り、その未使用領域が再フォーマットまで使えないことになってしまう。

このように、BUp Mark1だけでは、電源遮断が発生したタイミングは、ファイルボディ書き込み中の期間T1内の第１のタイミングと、FSの更新期間T2乃至T4中の第３のタイミングとの何れであるのか、といった切り分けができない。即ち、電源遮断は、FSの更新期間T2乃至T4となる第３のタイミングで発生する確率が低いとはいえ存在するにも係らず、そのFSの更新期間T2乃至T4での電源遮断に対する対処は従来の技術では考慮されていなかった。

そこで、本発明人は、第３のタイミングで電源遮断が発生しても、即ち期間T2乃至T4内の何れのタイミングで電源遮断が発生しても、ファイルシステムを修復し、かつ、アプリケーションフォーマットで記録データを修復すべく、図６に示されるように、BUp Markとして、BUp Mark1以外にBUp Mark2-0乃至2-2を追加する手法を発明した。

より具体的には、図６に示されるように、fwrite前のステップＳ５１の処理でBUp Mark1を付与し、さらに、ステップＳ４のファイルボディ書き込み処理の期間Ｔ１終了時点のステップＳ６０の処理でBUp Mark2-0を付与し、ステップＳ６のFAT1更新処理の期間Ｔ２終了時点のステップＳ６１の処理でBUp Mark2-1を付与し、ステップＳ７のFAT2更新処理の期間Ｔ３終了時点のステップＳ６２の処理でBUp Mark2-2を付与し、ステップＳ８のDirectory Entry更新処理の期間Ｔ４終了時点のステップＳ５２の処理で、そのBUp Markをクリアする、という手法を本発明人は発明した。

ここに、BUp Mark1,2-0,2-1,2-2のそれぞれの付与とは、上述した図２のBackupメモリ１９のBUp Table_App３１とBUp Table_FS３２とのうちの少なくとも一方（本実施の形態では両方）にBUp Mark1,2-0,2-1,2-2のそれぞれを上書き（更新）することをいう。また、BUp Markのクリアとは、BUp Table_App３１とBUp Table_FS３２とに記述されているBUp Mark、図６の例では主にBUp Mark2-2を消去することをいう。

これにより、電源遮断タイミングは、BUp Mark1が存在するときには期間Ｔ１であり、BUp Mark2-0が存在するときには期間Ｔ２であり、BUp Mark2-1が存在するときには期間Ｔ３であり、BUp Mark2-2が存在するときには期間Ｔ４である、といったように電源遮断タイミングの切り分けが容易にできるようになる。

従って、記録再生装置１は、例えば電源遮断発生後に電源が再投入されたときなどに、かかるBUp Mark1,2-0,2-1,2-2の有無を利用して電源遮断タイミングを認識し、その認識結果に基づいて必要に応じてFS層を修復し、必要に応じてアプリケーション層（以下適宜アプリ層と略記する）を修復する処理を実行できる。なお、以下、かかる処理を、FS層／アプリ層確認修復処理と称する。BUp Mark1,2-0,2-1,2-2の有無を利用したFS層／アプリ層確認修復処理の一例が、図７のフローチャートに示されている。

ステップＳ８１において、記録再生装置１は、図２のBackupメモリ１９のBUp Table_App３１とBUp Table_FS３２とのそれぞれにBUp Markが存在するか否かを判定する。

BUp Markが存在しない場合とは、図６のステップＳ５２のBUp Markクリアが行われたこと、即ち、動画データのファイルボディデータの書き込みが完了し（ステップＳ４）、ファイルシステムの更新情報の書き込みも完了し（ステップＳ６乃至Ｓ８）、その結果正常完了した場合を意味している。このような場合、FS層やアプリ層の確認修復は不要である。従って、BUp Markが存在しない場合、ステップＳ８１の処理でＮＯであると判定されて、FS層／アプリ層確認修復処理は終了となる。

これに対して、BUp Mark1,2-0,2-1,2-2のうちの何れかがBUp Table_App３１とBUp Table_FS３２とに記述されている場合、ステップＳ８１の処理でＹＥＳであると判定されて、処理はステップＳ８２に進む。

ステップＳ８２において、記録再生装置１は、BUp Mark1であるか否かを判定する。

BUp Mark1である場合とは、動画データのファイルボディデータの書き込み中、即ち、図６の期間Ｔ１中に電源遮断が発生したことを意味する。この場合、ファイルボディデータは、図１のアプリケーションフォーマット制御部２２よって修復されなければならない状態である一方、FS層は更新前であってかつそのFS層が正常動作可能状態であることが保証されていて、FS層の更新差分情報は最終のRUVデータが書き込み開始する一つ前の状態までしかバックアップされていないので、FS層の更新差分情報からFS層を修復処理することは不要である。従って、BUp Mark1である場合には、ステップＳ８２の処理でＹＥＳであると判定されて、アプリ層の確認や修復を行うべく、ステップＳ９４以降の処理が実行される。ただし、ステップＳ９４以降の処理については後述する。

これに対して、BUp Mark1ではない場合には、FS層が壊れている可能性がある。そこで、このような場合には、記録再生装置１は、ステップＳ８２の処理でＮＯであると判定して、ステップＳ８３において、FS層は正常であるか否かを判定する。

FS層が正常である場合には、アプリ層の確認や修復を行うべく、ステップＳ８３の処理でＹＥＳであると判定されて、ステップＳ９４以降の処理が実行される。ただし、ステップＳ９４以降の処理については後述する。

これに対して、FS層が不正状態の場合には、ステップＳ８３の処理でＮＯであると判定されて、処理はステップＳ８４に進む。

ステップＳ８４において、記録再生装置１は、BUp Mark2-0であるか否かを判定する。

BUp Mark2-0である場合とは、動画データのファイルボディデータの更新書き込みはすでに完了済みで、FAT FSのFAT1の更新情報書き込み中に電源遮断が発生したこと、即ち、期間Ｔ２中に電源遮断が発生したことを意味している。この場合、FS層は壊れている可能性があるため、上述したステップＳ８３の処理でFS層の状態が確認され、FS層が不正状態であるときには、ステップＳ８３においてＮＯであると判定され、さらにステップＳ８４の処理でＹＥＳであると判定されて、処理はステップＳ８５に進む。

ステップＳ８５において、記録再生装置１は、図３のハードディスク４１の領域４１−２，４１−３のFAT1とFAT2とをBUpで修復する。さらに、ステップＳ８６において、記録再生装置１は、ハードディスク４１の領域４１−４のDirectory EntryをBUpで修復する。

ここにBUpとは、図２のBackupメモリ１９のBUp Table_FS３２に記述されているFAT1,FAT2, Directory Entryのそれぞれについての更新差分情報である。

なお、ステップＳ８５とＳ８６の処理の理由は次の通りである。即ち、FAT1が壊れたまま放置されると、読み取り対象のFSが、読み取られてみてファイルがみあたらないことによってFAT1が壊れていると判断され、その後でFAT2が代替使用として読み取り使用され、これによりそのFSが正常状態で動作する仕組みになっているが、読み取り代替判断処理に時間がかかり処理も冗長でFAT自体もその後の正常FS前提でのFS差分修正に不都合が発生するので、FAT1を直すことにしているのである。

その後、処理はステップＳ９２に進む。ステップＳ９２において、記録再生装置１は、FS層の修復に成功したか否かを判定する。

FSのFAT1の修復が成功したならばFSは正常状態で動作するので、このような場合には、アプリ層の確認や修復を行うべく、ステップＳ９２の処理でＹＥＳであると判定されて、ステップＳ９４以降の処理が実行される。ただし、ステップＳ９４以降の処理については後述する。

これに対して、修復に失敗した場合には、記録再生装置１は、ファイルシステムエラーとして再フォーマットを促すべく、ステップＳ９２の処理でＮＯであると判定して、ステップＳ９３において、データエラーをユーザに通告する。これにより、FS層／アプリ層確認修復処理は終了となる。

また、BUp Mark2-1である場合とは、動画データのファイルボディデータの更新書き込みはすでに完了済みで、さらに、FAT FSのうちのFAT１の更新書き込みは済んで、FAT2側の情報更新の書き込み中に電源遮断が発生したこと、即ち、期間Ｔ３中に電源遮断が発生したことを意味している。この場合、FAT2が更新中であって壊れている可能性があり、Directory EntryはFAT1と不一致な更新前の状態なので、この結果、FS層が壊れた状態になっている可能性がある。そこで、上述したステップＳ８３の処理でFS層の状態が確認され、FS層が不正状態であるときには、ステップＳ８３においてＮＯであると判定され、さらにステップＳ８４の処理でＮＯであると判定され、ステップＳ８７の処理でＹＥＳであると判定されて、処理はステップＳ８８に進む。

ステップＳ８８において、記録再生装置１は、図３のハードディスク４１の領域４１−３のFAT2をBUpで修復する。さらに、ステップＳ８９において、記録再生装置１は、ハードディスク４１の領域４１−４のDirectory EntryをBUpで修復する。

ここにBUpとは、図２のBackupメモリ１９のBUp Table_FS３２に記述されているFAT2, Directory Entryのそれぞれについての更新差分情報である。

その後、処理はステップＳ９２に進む。ステップＳ９２において、記録再生装置１は、FS層の修復に成功したか否かを判定する。

FS層の修復に成功した場合には、アプリ層の確認や修復を行うべく、ステップＳ９２の処理でＹＥＳであると判定されて、ステップＳ９４以降の処理が実行される。ただし、ステップＳ９４以降の処理については後述する。

これに対して、修復に失敗した場合には、記録再生装置１は、ファイルシステムエラーとして再フォーマットを促すべく、ステップＳ９２の処理でＮＯであると判定して、ステップＳ９３において、データエラーをユーザに通告する。これにより、FS層／アプリ層確認修復処理は終了となる。

また、BUp Mark2-2である場合とは、動画データのファイルボディデータの更新書き込みはすでに完了済みで、さらに、FAT FSのうちのFAT１とFAT2の更新書き込みは済んで、Directory Entry側の情報更新の書き込み中に電源遮断が発生したこと、即ち、期間Ｔ４中に電源遮断が発生したことを意味している。この場合、更新中であるDirectory EntryはFAT1，FAT2と不一致な更新前の状態なので、この結果、FS層が壊れた状態になっている可能性がある。そこで、上述したステップＳ８３の処理でFS層の状態が確認され、FS層が不正状態であるときには、ステップＳ８３においてＮＯであると判定され、さらにステップＳ８４,Ｓ８７の各処理でそれぞれＮＯであると判定されて、処理はステップＳ９１に進む。

ステップＳ９１において、記録再生装置１は、図３のハードディスク４１の領域４１−４のDirectory EntryをBUpで修復する。

ここにBUpとは、図２のBackupメモリ１９のBUp Table_FS３２に記述されているDirectory Entryの更新差分情報である。

その後、処理はステップＳ９２に進む。ステップＳ９２において、記録再生装置１は、FS層の修復に成功したか否かを判定する。

FS層の修復に成功した場合には、アプリ層の確認や修復を行うべく、ステップＳ９２の処理でＹＥＳであると判定されて、ステップＳ９４以降の処理が実行される。ただし、ステップＳ９４以降の処理については後述する。

これに対して、修復に失敗した場合には、記録再生装置１は、ファイルシステムエラーとして再フォーマットを促すべく、ステップＳ９２の処理でＮＯであると判定して、ステップＳ９３において、データエラーをユーザに通告する。これにより、FS層／アプリ層確認修復処理は終了となる。

以下、アプリ層の確認や修復を行うための処理、即ち、ステップＳ９４以降の処理について説明する。

上述したように、ステップＳ９４の処理に入るときには、FS層は正常動作状態で入ってくる。

そこで、ステップＳ９４において、記録再生装置１は、図３のハードディスク４１の領域４１−１のアプリ層は正常であるか否かを判定する。

ステップＳ９４において、アプリ層は正常であると判定した場合、記録再生装置１は、ステップＳ９７において、BUp Markをクリアする。これにより、FS層／アプリ層確認修復処理は終了となる。

これに対して、ステップＳ９４において、アプリ層は不正状態であると判定した場合、記録再生装置１は、ステップＳ９５において、アプリ層を修復する。そして、ステップＳ９６において、記録再生装置１は、アプリ層の修復に成功したか否かを判定する。

具体的には、記録再生装置１は、アプリ層においてRUV単位での最終書き込みアドレスの一致を確認し、異なる場合はRUV単位で記録時間を縮小する方向でファイルボディデータを削除して揃える。

そして、記録再生装置１は、アプリケーションフォーマットの長さとFSのデータ長さが一致していれば、ステップＳ９６の処理で、アプリ層の修復に成功したと判定し、ステップＳ９７において、BUp Markをクリアする。これにより、FS層／アプリ層確認修復処理は終了となる。

これに対して、アプリケーションフォーマットの長さとFSのデータ長さが不一致ならば、記録再生装置１は、RUV単位でアプリケーションデータ長さに合わせて再度正常動作のFSを修復処理して、あわせることを試みる。

この試みに成功した場合、ステップＳ９６の処理で、アプリ層の修復に成功したと判定され、ステップＳ９７の処理で、BUp Markがクリアされる。これにより、FS層／アプリ層確認修復処理は終了となる。

これに対して、この試みに失敗した場合、ステップＳ９６の処理でＮＯであると判定されて、即ち、アプリ層の修復処理はファイルシステムエラーで終了して、処理はステップＳ９３に進む。そして、ステップＳ９３の処理で、再フォーマット（再初期化）をユーザに促すべく、データエラーがユーザに通告される。これにより、FS層／アプリ層確認修復処理は終了となる。

以上説明したように、図６と図７の例では、BUp Mark1,2-0,2-1,2-2を利用しているので、FS層更新期間である時間T2乃至T4に電源遮断が発生しても、FS層を正常動作状態に修復でき、無効容量（上述したアプリ層から不可視の未使用領域）も発生しない、という効果を奏することが可能になる。さらに、FS層の修復の際、そのFS層を構成しているFAT1，FAT2，Directory Entryのうちの修復が必要な箇所のみ修復できるという効果、即ち、修復が不要な箇所についてはFS更新情報の再度書き込み更新処理は不要となるという効果を奏することが可能になる。

ただし、正常記録中であっても、常にBUp Mark1,2-0,2-1,2-2を細かく付与していくという処理が必要であり、その分だけ記録処理の速度にも影響を及ぼす場合がある。従って、例えば記録処理のさらなる高速化が要求されている場合には、図８に示されるように２つのBUp Mark1,2のみを付与するようにすればよい。

即ち、図８は、図６とは別の手法が適用された記録処理を説明するフローチャートである。より具体的には、図８に示されるように、fwrite前のステップＳ５１の処理でBUp Mark1を付与し、その後は、ステップＳ４のファイルボディ書き込み処理の期間Ｔ１終了時点のステップＳ１１１の処理でBUp Mark2のみを付与し、ステップＳ８のDirectory Entry更新処理の期間Ｔ４終了時点のステップＳ５２の処理で、そのBUp Markをクリアする、という手法が本発明人により発明された別の手法である。

この場合のFS層/アプリ層確認修復処理は、例えば図９のフローチャートに従って実行される。

即ち、ステップＳ１２１において、記録再生装置１は、図２のBackupメモリ１９のBUp Table_App３１とBUp Table_FS３２とのそれぞれにBUp Markが存在するか否かを判定する。

BUp Markが存在しない場合とは、図８のステップＳ５２のBUp Markクリアが行われたこと、即ち、動画データのファイルボディデータの書き込みが完了し（ステップＳ４）、ファイルシステムの更新情報の書き込みも完了し（ステップＳ６乃至Ｓ８）、その結果正常完了した場合を意味している。このような場合、FS層やアプリ層の確認修復は不要である。従って、BUp Markが存在しない場合、ステップＳ１２１の処理でＮＯであると判定されて、FS層／アプリ層確認修復処理は終了となる。

これに対して、BUp Mark1,2のうちの何れかがBUp Table_App３１とBUp Table_FS３２とに記述されている場合、ステップＳ１２１の処理でＹＥＳであると判定されて、処理はステップＳ１２２に進む。

ステップＳ１２２において、記録再生装置１は、BUp Mark1であるか否かを判定する。

BUp Mark1である場合とは、動画データのファイルボディデータの書き込み中、即ち、図８の期間Ｔ１中に電源遮断が発生したことを意味する。この場合、ファイルボディデータは、図１のアプリケーションフォーマット制御部２２よって修復されなければならない状態である一方、FS層は更新前であってかつそのFS層が正常動作可能状態であることが保証されていて、FS層の更新差分情報は最終のRUVデータが書き込み開始する一つ前の状態までしかバックアップされていないので、FS層の更新差分情報からFS層を修復処理することは不要である。従って、BUp Mark1である場合には、ステップＳ１２２の処理でＹＥＳであると判定されて、アプリ層の確認や修復を行うべく、ステップＳ１２７以降の処理が実行される。

なお、ステップＳ１２７以降の処理は、上述した図７のステップＳ９４以降の処理と基本的に同様であるので、ここではその説明は省略する。

これに対して、BUp Mark1ではない場合、即ち、BUp Mark2である場合とは、図８の期間T2乃至T4内、即ち、FS更新期間内に電源遮断が発生した場合を意味する。このような場合、図７を用いて上述したように、FS層が壊れている可能性がある。そこで、BUp Mark2である場合には、記録再生装置１は、ステップＳ１２２の処理でＮＯであると判定して、ステップＳ１２３において、FS層は正常であるか否かを判定する。

FS層が正常である場合には、アプリ層の確認や修復を行うべく、ステップＳ１２３の処理でＹＥＳであると判定されて、ステップＳ１２７以降の処理が実行される。

これに対して、FS層が不正状態の場合には、ステップＳ１２３の処理でＮＯであると判定されて、処理はステップＳ１２４に進む。

即ち、BUp Mark2である場合とは、繰り返しになるが、動画データのファイルボディデータの更新書き込みはすでに完了済みで、その後のFAT FSのFAT1，FAT2，Directory Entryのうちの何れかの更新情報書き込み中に電源遮断が発生したこと、即ち、期間T2乃至T4中に電源遮断が発生したことを意味している。この場合、FS層は壊れている可能性があるため、上述したステップＳ１２３の処理でFS層の状態が確認され、FS層が不正状態であるときには、ステップＳ１２３の処理でＮＯであると判定され、処理はステップＳ１２４に進む。

ステップＳ１２４において、記録再生装置１は、図３のハードディスク４１の領域４１−２，４１−３，４１−４のFAT1，FAT2，Directory EntryをBUpで修復する。

ここにBUpとは、図２のBackupメモリ１９のBUp Table_FS３２に記述されているFAT1,FAT2, Directory Entryのそれぞれについての更新差分情報である。

即ち、図９の例では、図７の例と異なり、期間T3やT4中に電源遮断が発生した場合であっても、FAT1,FAT2, Directory Entryの一括修復が行われるのである。

その後、処理はステップＳ１２５に進む。ステップＳ１２５において、記録再生装置１は、FS層の修復に成功したか否かを判定する。

FSの修復に成功した場合には、アプリ層の確認や修復を行うべく、ステップＳ１２５の処理でＹＥＳであると判定されて、ステップＳ１２７以降の処理が実行される。

これに対して、修復に失敗した場合には、記録再生装置１は、ファイルシステムエラーとして再フォーマットを促すべく、ステップＳ１２５の処理でＮＯであると判定して、ステップＳ１２６において、データエラーをユーザに通告する。これにより、FS層／アプリ層確認修復処理は終了となる。

以上説明したように、図８と図９の例では、BUp Mark1,2を利用しているので、FS層更新期間である時間T2乃至T4に電源遮断が発生しても、FS層を正常動作状態に修復でき、無効容量（上述したアプリ層からの不可視の未使用領域）も発生しない、という効果を奏することが可能になる。さらに、図８の例の記録処理では、図６の例と比較して、BUp Markを付与する処理数を削減できるので、その分だけ記録処理全体の処理が高速化されるという効果を奏することが可能になる。

ところで、図７または図９のFS層／アプリ層確認修復処理の実行タイミングとして、動画記録中に電源遮断が発生して、その後電源復旧されたタイミングを例として上述してきたが、その実行タイミングは、上述した例に特に限定されない。

そこで、図７または図９のFS層／アプリ層確認修復処理の実行タイミングの別の例について、図１０を参照して説明する。図１０は、図１の記録再生装置１が取り得る各動作状態のうちの一部の例を示している。ここで、「一部」と記述したのは、説明の簡略上、記録処理に関する動作状態の一部の例のみが、図１０には図示されているからである。即ち、記録再生装置１は、例えば、動画データ等の記録処理のみならず再生処理も実行できるので、当然ながら再生に関する動作状態も存在するが、説明の簡略上、かかる動作状態は省略されているからである。

図１０において、各状態は、１つの楕円で示されており、その楕円内に記述された名称、例えば「マウント状態」等により判別される。１つの状態から１つの状態への状態遷移は、所定の条件（以下、状態遷移条件と称する）が満たされると実行される。このような状態遷移条件は、図１０おいては、１つの状態から１つの状態への遷移を表す矢印に、“Ｃ”を含む符号を付して表されている。

例えば記録再生装置１の電源が投入されると、即ち、電源状態がオン状態になると、記録再生装置１は、状態遷移条件Ｃ１が満たされたと判定し、その状態をマウント状態に遷移させる。

マウント状態とは、各ドライブや記録メディアのチェック動作、即ち、いわゆるマウント動作を行い、その後、記録再生装置１の動作を待機させる状態をいう。

かかるマウント動作において、所定の記録メディアのチェック時に異常が発生すると、例えば、図１のハードディスクドライブ１６の図３のハードディスク４１のFSが読めなかった等の異常が発生すると、記録再生装置１は、状態遷移条件Ｃ２が満たされたと判定し、その状態をマウント状態からFS層／アプリ層確認修復状態に遷移させる。

このFS層／アプリ層確認修復状態が、図７または図９のFS層／アプリ層確認修復処理が実行されている状態である。即ち、図１０の例では、状態遷移条件Ｃ２が満たされると、異常が発生している所定の記録メディアに対して、図７または図９のFS層／アプリ層確認修復処理が開始される。

状態遷移条件Ｃ２が満たされたことをトリガとして、図７または図９のFS層／アプリ層確認修復処理が開始され、その処理が終了すると、状態遷移条件Ｃ３が満たされたと判定されて、記録再生装置１の状態はFS層/アプリ層確認修復状態からマウント状態に遷移する。

また、図示はしないが、例えば図１の操作装置２により「記録」、「中立」、「再生」等の切替操作が可能であるとして、かかる切替操作により「記録」への切替が指示されると、状態遷移条件Ｃ４が満たされたと判定されて、記録再生装置１の状態はマウント状態から記録開始準備状態に遷移する。

なお、記録開始準備状態において、上述した切替操作により「中立」や「再生」等への切替が指示されると、状態遷移条件Ｃ５が満たされたと判定されて、記録再生装置１の状態は記録開始準備状態からマウント状態に遷移する。

記録開始準備状態とは、上述した図６または図８の記録処理を何時でも開始できる状態、即ちいわゆる待機状態をいう。従って、図１の操作装置２により動画記録開始命令が発行されると、状態遷移条件Ｃ６が満たされたと判定されて、記録再生装置１の状態は記録開始準備状態から記録状態に遷移する。この記録状態が、図６または図８の記録処理が実行されている状態である。即ち、図１０の例では、状態遷移条件Ｃ６が満たされると、図６または図８の記録処理が開始される。

その後、図６または図８の記録処理が最後まで終了すると、即ち、ステップＳ９のfcloseが行われると、状態遷移条件Ｃ７が満たされたと判定されて、記録再生装置１の状態は記録状態からFS層／アプリ層確認修復状態に遷移する。即ち、図１０の例では、記録処理が最後まで終了した場合にも、図７または図９のFS層／アプリ層確認修復処理が開始される。即ち、記録処理が最後まで終了した場合であっても、FS層やアプリ層が１００％正常であるとは断言できず、その正常性をチェックするため、図７または図９のFS層／アプリ層確認修復処理が実行されるのである。

状態遷移条件Ｃ７が満たされたことをトリガとして、図７または図９のFS層／アプリ層確認修復処理が開始され、その処理が終了すると、状態遷移条件Ｃ８が満たされたと判定されて、記録再生装置１の状態はFS層/アプリ層確認修復状態から記録開始準備状態に遷移する。

なお、記録状態中に電源遮断が発生し、その後、電源が再投入されると、状態遷移条件Ｃ１が満たされてマウント状態に遷移し、さらに、状態遷移条件Ｃ２が満たされてFS層／アプリ層確認修復状態に遷移する。そして、電源遮断が発生したときに記録対象であった記録メディアに対して、図７または図９のFS層／アプリ層確認修復処理が開始される。

ところで、以上の説明では、アプリケーションが管理可能なファイルボディデータの単位、即ち、アプリケーションフォーマットの動画データ書き込み最小記録単位は、１RUV 単位であるとしてきたが、1RUV単位に特に限定されず、例えばVOBU等を単位としてもよい。ただし、上述した例の１RUV単位が好適である。なぜならば、サーチ情報含まれた RUV 単位での修復が、サーチ情報を作り直す必要がなくて、アプリケーションフォーマットとして、図７や図９を用いて説明した修復処理が容易となるからである。

より具体的には例えば、1RUVが 1GOP ならばサーチデータの再生成は不要だが、複数GOP、VOBU単位で長さ修正しようとする場合には、サーチデータの入っている VOBU_TABLE から再生成が必要になることからエンコード／デコード部１３の処理が重く複雑となり、その結果、処理時間がかかってしまうからである。例えば、いわゆるHQ（High Quality）モード撮影の場合、映像音声の１GOP（0.5秒）でストリームデータレート上限が10.08Mbpsになり、１RUVはVOBU １０個構成で、5秒単位となる。エンコードはVBRでどのような撮影対象の場合でも、１RUVの上限は、320パック、740kByte、1480セクタまでとなる。なお、FATの１クラスタが32Kバイトの場合、24クラスタ（正確には23.125クラスタ）使用までとする。この場合、これより小さな区間で、ちょうどFSの書き込み更新タイミングでの電源遮断が繰り返されると、アプリケーションフォーマットにとって不可視な未使用領域が増大することになる。しかしながら、本実施の形態では、上述した図６または図８の記録処理を実行できるので、即ち、BUp Mark2-0乃至2-2やBUp Mark2が付加されるので、上述したようにFSの修復が可能になる、その結果、未使用領域は発生せず、ファイルがFAT的に壊れることもなくなるのである。

また、上述した例では、図２に示されるように、１ファイルの記録処理のときに、1RUVのファイルボディの記録メディア（例えば図３のハードディスク４１）への記録ごと（例えば５秒ごと）に、FSの更新差分情報をBackupメモリ１９（図１）にバックアップしてゆき、撮影完了したときに、即ち図３等のように動画記録終了命令がなされたときに、記録メディアへのFSの更新を行うとした。

このような場合には、バックアップするFSの更新差分情報は、その名の通り差分情報であるため、そのデータ量は高々2kByte の２倍、4kByte と、比較的少なくて済む。そこで、例えば仮に、FSの更新差分情報を格納するBUp Table_FS３２（図２）の容量を2kByteとして、1RUVの記録ごとに、FS の更新差分情報を上書きしていく、即ち、バックアップ更新していく案も考えられる。ただし、このような案を採用する場合であって、Backupメモリ１９がフラッシュメモリで構成されている場合には、そのフラッシュメモリの書き込み更新回数が頻繁になり、書き込み回数上限（通常は数１０万回とされている）の書き換え更新寿命に早期に到達してしまう恐れがある。

一方で、上述した例では、記録処理途中の全RUVについての更新差分情報、即ちアプリケーションフォーマットの更新差分情報がBackupメモリ１９にバックアップされているので、ファイル記録が電源遮断で終わった場合に、アプリケーションフォーマットで記録完成したRUV単位での任意の長さまでの動画撮影記録ファイルに調整可能に構成することができる。この場合には、FSの更新差分情報も RUV 単位で全て持っているのが好都合である。ただし、この場合、 FAT の記録１ファイル最長 2GByte 長であるとすると、全RUVについてのFSの更新差分情報を格納するBUp Table_FS３２（図２）のサイズは例えば次のようになる。即ち、例えば 1RUV ５秒で24クラスタ未満、740kByte 以下であることから、2GByte 長のファイルが含む RUV 個数は約2639個以上になり、各々の RUV ごとに4kByte分の FS の更新差分情報をBUp Table_FS３２に削除せずに順次蓄積していくと、動画１ファイルの記録長さが2GByte ファイルに達する場合には、BUp Table_FS３２の容量は最大で 10.3MByteにもなる。

そこで、Backupメモリ１９の書き換え更新寿命と容量とのバランスを考慮して、即ち、より一段と効率のよいバックアップを考慮して、例えば次のようなFS更新手法を採用することもできる。

即ち、大容量フラッシュの１セクタは 64kByte なので、Backupメモリ１９のうちのBUp Table_FS３２に割り当てるサイズは１セクタの整数倍のデータサイズとし、RUV単位毎のFSの更新差分情報の全てを消去せずに（上書きせずに）BUp Table_FS３２に蓄積していき、１セクタの整数倍のデータサイズ以下に収まる所定のRUV個数のFSの更新差分情報が蓄積された段階で、記録メディアに対するFSの更新処理を行い、即ち、図３等のステップＳ６乃至Ｓ８の処理を実行し、BUp Table_FS３２をクリアした後、そのままファイル録画を継続する、というFS更新手法を採用してもよい。即ち、図３のステップＳ４の処理とは、上述した図３等の説明では、ファイルボディデータとして動画記録終了命令がなされるまでの全てのRUVを記録メディア（図３の例ではハードディスク４１）に記録するまでの一連の処理であるとした。これに対して、本FS更新手法が適用されたステップＳ４の処理とは、１セクタの整数倍のデータサイズ以下に収まる所定のRUV個数のみを記録メディアに記録するまでの一連の処理となる。換言すると、本FS更新手法では、１セクタの整数倍のデータサイズ以下に収まる所定のRUVを単位として、その単位毎に、ステップＳ４乃至Ｓ８の処理が繰り返し実行されることになる。

さらにまた、FSの差分を取るための単位は、上述した例ではRUVとされたが、より一般的にいえば、記録メディアの種類やFSの種類といった各種類に対するアプリケーションフォーマットの取り扱う最小単位（適宜、FSに基づくアプリケーションフォーマットの最小単位、或いは単にFSの最小単位とも称する）と、アプリケーションフォーマット規格のひとつとしての映像音声圧縮ストリーム規格の記録最小単位（以下、アプリケーションフォーマットの動画データ書き込み最小記録単位と適宜称する）との最小公倍数のＬ倍（Ｌは、1以上の整数値）とすればよい。

詳細には、FSに基づくアプリケーションフォーマットの最小単位と、映像音声圧縮ストリーム規格の記録最小単位とは、必ずしも一致することはなく、相互の最小単位の最小公倍数で単位が揃えられて、その揃えられた単位がファイルの記録単位として、ファイルの生成と記録が行われる。

例えば、アプリケーションフォーマット規格の記録メディアでの最小記録単位、即ち、FSに基づくアプリケーションフォーマットの最小単位は、記録メディアがハードディスクスクドライブ（以下、適宜HDDと略記する）１６やメモリのFSの場合には、５１２バイト１セクタとして取り扱われる。ただし、上述した例のように、生成後のファイルの記録メディア上での汎用性を考慮して、５１２バイトの整数倍集合である３２ｋバイト１ＥＣＣの整数倍を、FSに基づくアプリケーションフォーマットの最小単位として採用してもよい。

他方、映像音声圧縮ストリーム規格の記録最小単位は次のようになる。即ち、例えば、映像音声圧縮ストリーム規格のうちのＳＤ方式の映像音声圧縮ストリーム規格では、ＭＰＥＧ−ＰＳストリームが規定されており、その最小記録単位は２ｋバイトパックの整数倍であり、映像音声連続ストリームデータとしての記録最小単位は、この最小データ単位の整数倍となるＭＰＥＧの１ＧＯＰを含む１ＶＯＢＵ（ビデオオブジェクトユニット）の０．５秒時間分の可変長圧縮データサイズとなる。

また例えば、映像音声圧縮ストリーム規格のうちのＨＤ方式の映像音声圧縮ストリーム規格では、Ｈ２６４／ＡＶＣ方式のＭＰＥＧ−ＴＳストリームが規定されており、１８８バイト＋同期データ数バイトを最小データ単位とし、上述した実施例の場合は、１９２バイトを１パックとして、映像音声連続ストリームデータとしての記録最小単位は、この最小データ単位の整数倍となるＭＰＥＧの１ＧＯＰを含む１ＶＯＢＵ（ビデオオブジェクトユニット）の０．５秒時間分の可変長圧縮データサイズとなる。

従って、ファイルの記録単位は、ＳＤ映像ＭＰＥＧ−ＰＳストリームの場合には、３２ｋバイトの整数倍であってかつ最小公倍数である３２ｋバイト単位の整数倍となり、ＨＤ映像Ｈ２６４／ＡＶＣのＭＰＥＧ−ＴＳストリームの場合は１９２バイトと５１２バイトの最小公倍数である６ｋバイトの整数倍で、かつ３２ｋバイトの整数倍の最小公倍数である１９２ｋバイト単位の整数倍となる。これらの各記録単位が、例えば１RUVとなる。

即ち、ＳＤ映像ＭＰＥＧ−ＰＳストリームの場合には、映像圧縮ＭＰＥＧ−ＰＳであって内部にＳＣＲ連続時刻情報をもつ２ｋバイト１パックが単位となり、その１パック単位の整数倍である３２ｋバイトがＥＣＣ単位を構成し、かかるＥＣＣ単位が、映像音声圧縮ストリーム規格の記録最小単位となる。一方、上述したようにFSのメディア１セクタ５１２バイトが、FSに基づくアプリケーションフォーマットの最小単位である。従って、この５１２バイトとＥＣＣ３２ｋバイトとの最小公倍数の整数倍のサイズが、記録ファイルの記録単位となり、この記録単位で揃えられて（すなわちアライン処理されて）記録メディアに記録されることで、１RUVサイズになる。

また、ＨＤ映像Ｈ２６４／ＡＶＣのＭＰＥＧ−ＴＳストリームの場合には、映像圧縮ＭＰＥＧ−ＴＳであって例えばＡＶＣＨＤやＢｌｕ−Ｒａｙで定められるごとくＨ２６４／ＡＶＣの１８８ｋＢｙｔｅと同期データ４バイトを合わせた１パケットが基本パケットとなり、かかる基本パケットのサイズ、即ち、１９２バイトが映像音声圧縮ストリーム規格の記録最小単位となる。従って、１９２バイトと、FSのメディア１セクタ５１２バイトとの公倍数は６ｋバイトとなり、この６ｋバイトと、アプリケーションフォーマットのメディア汎用的なＥＣＣ３２ｋバイト指定サイズとの最小公倍数の整数倍が、記録ファイルの記録単位となり、この記録単位で揃えられて（すなわちアライン処理されて）記録メディアに記録されることで、１RUVサイズになる。

即ち、アプリケーションフォーマット規格によるＳＤ方式映像音声圧縮ストリームとＨＤ方式の映像音声圧縮ストリームとのそれぞれは、無限の長さの圧縮ストリームがバッファメモリに蓄積されてから記録メディアに書き込まれるのではなく、バッファメモリにおいて、RUV単位の圧縮ストリームが生成されて記録メディアに書き込まれる。即ち、所定サイズの圧縮ストリームがバッファメモリに蓄積された場合、例えば数Ｍバイト乃至数１０Ｍバイトを超えたサイズの圧縮ストリームがバッファメモリに蓄積された場合、それがRUV（ビデオ記録１単位）として記録メディアに記録されつつ、撮影中の圧縮ストリームが並列処理により次の別RUVとしてバッファメモリに蓄積される、という処理が繰り返し行われる。このように、RUVは時間長さではなくデータサイズで決められる。

従って、本実施の形態では、上述したように、FSの差分を取るための単位として、RUVを採用するようにしたのである。

次に、FSのバックアップとその書き込み制御との全体処理について説明する。

ただし、以下の説明では、図１の記録再生装置１は、図１１に示されるようなビデオ一体型カメラとして構成されているとする。

即ち、以下の例では、記録再生装置１は、ＳＤ動画記録、ＨＤ動画記録、および、静止画記録のそれぞれを実行できるとする。

この場合、ＳＤ動画記録、ＨＤ動画記録、および、静止画記録は、例えば、次のような動画または静止画のストリームデータのアプリケーションフォーマットに基づいて行われる。

即ち、ＨＤ動画記録についてのアプリケーションフォーマットとしては、例えば、ＡＶＣＨＤやＢｌｕ−Ｒａｙで定められるごとくＨ２６４／ＡＶＣの１パケット１８８ｋＢｙｔｅと同期データ４バイトを合わせたパケットを基本パケットとして持つトランスポートストリームを使用する規格の映像記録アプリケーションフォーマットが採用される。

また、ＳＤ動画記録についてのアプリケーションフォーマットとしては、例えば、ＭＰＥＧ２−ＰＳのごとくＳＣＲ時刻連続データ情報を内在してもつ２ｋバイトの基本パックデータとしてもつプログラムストリームを使用する規格の映像記録アプリケーションフォーマットが採用される。かかるアプリケーションフォーマットでは、ＸＰ、ＨＱ＋、ＨＱ、ＳＰ、ＬＰという映像圧縮率、即ち記録映像品質をあらわす画質モードと、また映像の縦横比サイズである映像アスペクト比の選択設定が可能であり、かかる選択設定の結果として、圧縮映像音声データのそれぞれ相違する記録目標の平均あるいは最大平均の記録データ転送レートが実現される。

ここに、平均的または最大平均的な記録時間量とは、圧縮映像記録再生装置（ここでは記録再生装置１）側の設計仕様に存在する量である。かかる設計仕様としては、被写体内容によって変わるもので、通常の家庭内や自然風景の細かさと動きの映像を平均的な操作で映像記録する使い方での平均的な記録残量時間を用いる設計仕様でもよく、或いは、通常のスポーツや特殊作業環境で使用するユーザの使用状況下で予測されるかなり細かい映像で動きの激しい被写体映像を短く何度も記録停止を繰り返す使われ方での最大平均的な記録時間量を用いる設計仕様でもよい。

また、静止画記録では、ＤＣＦ静止画が記録対象となる。ＤＣＦ（Design rule for Camera File system）は、デジタルカメラの標準的な画像ファイルとして、ＪＥＩＴＡ：電子情報技術産業協会によって決められたものである。Ｅｘｉｆ（Exchangeable Image File Format）の仕様はこのＤＣＦによって決められているので、Ｅｘｉｆ対応ＪＰＥＧがＤＣＦとなる。

即ち、本例で取り扱うＤＣＦ静止画は、デジタルカメラとして機能する記録再生装置１によって撮影された画像のことであって、ＪＰＥＧ圧縮で記録され、Ｅｘｉｆによってさらに日付や撮影場所などの撮影情報が付加情報として加えられ、ＤＣＦ画像ファイルとして記録メディア（ハードディスクドライブ１６やリムーバブルメディア５等）に保存される。なお、記録再生装置１のみならず、現在のデジタル静止画撮影カメラはほとんどがＤＣＦ対応となっている。

従って、静止画記録についてのアプリケーションフォーマットとしては、例えば、静止画ＤＣＦのアプリケーションフォーマットが採用される。かかる静止画ＤＣＦのアプリケーションフォーマットにおいては、機器側（ここでは記録再生装置１側）で、自分の撮影仕様に基づいて撮影画像ピクセルサイズが設定される。撮影画像ピクセルサイズとは、撮影画像の縦横に並ぶ画像ピクセルサイズであって、例えば搭載カメラ静止画撮影解像度の選択機能によって、４Ｍ（メガ、以下同じ）、３Ｍワイドアスペクト、１．９Ｍ、ＶＧＡ（０．３Ｍ）などが選択される。さらには、記録再生装置１がＣＭＯＳ撮像素子を有する場合には、動画像と同時撮影可能な静止画サイズとして、例えば２．３Ｍワイドアスペクト静止画があり、４：３動画映像と同時撮影可能な静止画サイズとして１．７Ｍ静止画（４：３標準アスペクト）があり、かかる静止画を取り扱える仕様とすることも可能である。

ここで、図１２の一番上のタイミングチャートに示されるようなユーザ操作について考える。即ち、ユーザは、ステップＳＵ１において、ＳＤ動画記録を開始させ、ステップＳＵ２において、ＳＤ動画記録（例えばＭＰＥＧ２ プログラムストリームでの記録）を進行させ、ステップＳＵ３において、そのＳＤ動画記録を停止させる。そして、ステップＳＵ４の撮影休止中を経て、即ち、所定の撮影休止時間をおいて、ユーザは、ステップＳＵ５において、ＨＤ動画記録を開始させ、ステップＳＵ６において、ＨＤ動画記録（例えばＭＰＥＧ４ トランスポートストリーム ＡＶＣＨＤフォーマットでの記録）を進行させ、ステップＳＵ７において、そのＨＤ動画記録を停止させる。さらに、ステップＳＵ８の撮影休止中を経て、即ち、所定の撮影休止時間をおいて、ユーザは、ステップＳＵ９において、ＤＣＦ静止画の撮影開始と記録完了を行わせる。即ち、ステップＳＵ９においては、記録再生装置１は、静止画モードとなっており、図示せぬシャッタボタンがユーザにより押下されたとき、ＤＣＦ静止画の撮影処理を開始して、それをファイルとして記録メディア（ハードディスクドライブ１６やリムーバブルメディア５等）に書き込み、その書き込み完了時間を待って、静止画記録処理を完了とする。

このようなステップＳＵ１乃至ＳＵ９のユーザの操作によりＳＤ動画、ＨＤ動画、およびＤＣＦ静止画のデータが書き込まれる場所、即ち、記録メディア（ハードディスクドライブ１６やリムーバブルメディア５等）上のデータ位置が、図１２の下部に示されている。なお、図１２の例では、矢印の右方に向かって、ＬＢＡアドレス値が大きくなるとされている。

この場合、例えば、記録メディア上のデータ位置としてＬＢＡアドレス値の小さいメディア位置に存在する領域７１に対して、FSの管理情報のFAT部分が書き込まれる。また、このFSの管理情報のFAT部分の登録更新の差分情報が、上述したFSの更新差分情報として図１のBackupメモリ１９にバックアップされる。

このBackupメモリ１９へのFSの更新差分情報のバックアップタイミングは、次の通りとなる。即ち、映像音声圧縮ストリーム規格の記録最小単位と、FSに基づくアプリケーションフォーマットの最小単位（FSの最小単位）との最小公倍数を整数倍したデータサイズが１RUVデータサイズであり、このRUV単位でデータが記録メディアに記録されていく。そこで、上述したように、１RUVの１倍を含む整数倍のデーが記録メディアに記録される毎に、FSの更新差分情報がBackupメモリ１９にバックアップされていく。

即ち、図１２の例では、記録メディアの領域７２に対して、ＳＤ動画ストリームファイルが1RUV単位で記録されていくので、かかる１RUVの整数倍の記録がなされる毎に、FSの更新差分情報がBackupメモリ１９にバックアップされていく。なお、領域７２を区分している複数の四角のそれぞれに、１RUV分のデータが順次記録されていく。

また、図１２の例では、記録メディアの領域７３に対して、ＨＤ動画ストリームファイルが1RUV単位で記録されていくので、かかる１RUVの整数倍の記録がなされる毎に、FSの更新差分情報がBackupメモリ１９にバックアップされていく。なお、領域７３を区分している複数の四角のそれぞれに、１RUV分のデータが順次記録されていく。

ここで、ＳＤ動画ストリームファイルとＨＤ動画ストリームファイルとの各１RUVの内部構成について説明する。

ＳＤ動画ストリームファイルの1RUVの内部構造は、次のようになる。即ち、上述したように、映像圧縮ＭＰＥＧ−ＰＳであって内部にＳＣＲ連続時刻情報をもつ２ｋバイト１パックが単位となり、その１パック単位の整数倍の３２ｋバイトがＥＣＣ単位を構成し、かかるＥＣＣ単位が、映像音声圧縮ストリーム規格の記録最小単位でとなる。一方、上述したようにFSのメディア１セクタ５１２バイトが、FSに基づくアプリケーションフォーマットの最小単位である。従って、この５１２バイトとＥＣＣ３２ｋバイトとの最小公倍数の整数倍が、記録ファイルの記録単位となり、この記録単位に揃えられて（即ちアライン処理されて）記録メディアに記録されることで、１RUVサイズになる。なお、図１２の例では、領域７２の先頭のRUVが記録される領域７２−１において、複数に区分されている小領域のサイズが、５１２バイトとＥＣＣ３２ｋバイトとの最小公倍数とされている。

また、ＨＤ動画ストリームファイルの1RUVの内部構造は、次のようになる。即ち、映像圧縮ＭＰＥＧ−ＴＳであって例えばＡＶＣＨＤやＢｌｕ−Ｒａｙで定められるごとくＨ２６４／ＡＶＣの１８８ｋＢｙｔｅと同期データ４バイトを合わせた１パケットが基本パケットとなり、かかる基本パケットのサイズ、即ち、１９２バイトが映像音声圧縮ストリーム規格の記録最小単位となる。従って、１９２バイトと、FSのメディア１セクタ５１２バイトとの最小公倍数は６ｋバイトとなり、この６ｋバイトとアプリケーションフォーマットのメディア汎用的なＥＣＣ３２ｋバイト指定サイズとの最小公倍数の整数倍が、記録ファイルの記録単位となり、この記録単位に揃えられて（すなわちアライン処理されて）記録メディアに記録されることで、１RUVサイズになる。なお、図１２の例では、領域７３の先頭のRUVが記録される領域７３−１において、複数に区分されている小領域のサイズが、６ｋバイトとＥＣＣ３２ｋバイトとの最小公倍数とされている。

ここで、ＳＤ、ＨＤの動画記録が進行する際におけるFSの更新差分情報のBackupメモリ１９へのバックアップの頻度を考える。

即ち、ＳＤ、ＨＤの動画記録が進行する際には、Backupメモリ１９においては、先ずBUp Markが設定され、その後、所定の１RUVまたは複数RUVの記録メディアに対する記録処理毎に生成されたFSの更新差分情報が、順次バックアップされていく。

このバックアップの頻度の程度は、例えばＨＤ動画のＸＰ画質では１RUVの記録時間が５秒程度であることから、1RUV記録毎のバックアップでは頻繁に過ぎるので、１０秒乃至２０秒間隔毎、即ち、2乃至4RUV記録毎に１度のバックアップが適当であると思われる。

また、ＨＤ動画のＬＰ画質では１RUVの記録時間が３０秒を越えるので、1RUV記録毎のバックアップで問題なく、逆に、複数RUV記録毎のバックアップにすると、それまでの記録を失う危険性がありうる（ただし、FSの更新タイミングに合致したFS書き込み中のデータ破壊はかなり稀である）。従って、1RUV記録毎に１度のバックアップが適当であると思われる。

ＨＤ動画のその他の画質や、ＳＤ動画についても全く同様に、１RUVの記録時間に応じて、バックアップの頻度を設定するとよい。

なお、静止画には圧縮サイズ単位の指定は特にないが、記録メディアの汎用性から１ＥＣＣ３２ｋバイトの整数倍が、記録ファイルの記録単位となり、この記録単位に揃えられて（すなわちアライン処理されて）記録メディアに記録される。即ち、この記録単位のデータの集合体が、ＤＣＦ静止画ファイルとなる。即ち、図１２の例では、記録メディアの領域７４に対して、ＤＣＦ静止画ファイルが、上述した記録単位で記録されていくので、かかる記録単位分のデータの整数倍の記録がなされる毎に、即ち、領域７４を区分している複数の四角のそれぞれにかかる記録単位分のデータが順次記録されていく毎に、FSの更新差分情報がBackupメモリ１９にバックアップされていく。

この場合、静止画についてのFSの更新差分情報のバックアップは、記録開始と記録完了の操作はシャッタの押下タイミングといった１タイミングだけなので、上述した記録単位分のデータが記録される毎のバックアップ、即ち毎回バックアップが適当である。

このようにして、ＳＤ記録、ＨＤ記録、静止画記録のそれぞれの最中においては、FSの更新差分情報はBackupメモリ１９に順次バックアップされていく。そして、それぞれの記録完了のときに、最終にバックアップされたFSの更新差分情報を用いて、FSの管理情報のストリームファイル登録情報の記録メディアへの更新書き込み処理（図１２の例でいうFS差分情報書き込み更新処理）が実行される。即ち、図１２の例では、ステップＳＵ３の記録停止操作がなされて、ＳＤ動画の記録が完了するとき、ステップＳ２０１Ｓにおいて、FS差分情報書き込み更新処理が実行される。また、ステップＳＵ７の記録停止操作がなされて、ＨＤ動画の記録が完了するとき、ステップＳ２０１Ｈにおいて、FS差分情報書き込み更新処理が実行される。そして、ステップＳＵ９の静止画の撮影開始と記録完了操作がなされて、即ち、シャッタボタンが押下された後静止画の記録が完了するとき、ステップＳ２０１Ｄにおいて、FS差分情報書き込み更新処理が実行される。

次に、編集（削除）におけるFSのバックアップについて説明する。

記録再生装置１が図１１のカメラ一体型ビデオで構成される場合には、１チャプタを１ファイルとして記録されたファイル群から、１つのチャプタを選択して削除したり、複数チャプタを選択してまとめて削除したり、選択されたアプリケーションフォーマット方式で記録されたチャプタを全て削除したり、或いはプレイリスト上の編集処理としての移動、消去、全消去をしたり、という編集処理を実現する機能が備えられている場合がある。以下、かかる場合について説明する。

先ず、前提事項として、本実施の形態の編集仕様としては、例えばオリジナル編集とプレイリスト編集があるとする。

本実施の形態のオリジナル編集では、動画チャプタのストリームファイルと、そのファイルを管理するアプリケーション管理情報ファイルとが更新修正される。また、本実施の形態のプレイリスト編集では、動画チャプタのストリームファイルそのものには変更を加えずに、アプリケーション管理情報ファイルの登録リスト情報が更新修正される。

１動画記録ストリームファイルはアプリケーションフォーマットに登録されて動画１チャプタとなる。このチャプタを、編集機能仕様上、オリジナル（以下、ORGと略記する）チャプタと称することにする。

これに対して、アプリケーションフォーマット方式の情報管理ファイルは、各動画チャプタを再生リストに登録削除して再生順序を編集制御するための機能を有しており、その再生リストに登録された指定順番で再生させる機能を有している。このようなファイルを、編集機能仕様上、プレイリストと称し、また、プレイリストをPLと略記することにする。

このPL編集機能情報を記憶するファイル内部領域も予約され、そのPL編集機能情報の予約領域とともにPLは、記録メディア上に記録される。例えば後述する図１３乃至図１７の例では、PLは領域８１に記録される。即ち、編集処理の登録処理は、撮影の際にアプリケーションフォーマットが各チャプタに１つずつ自動的に付属生成したチャプタ情報ファイルを、PLへ追加（PLへの登録）、消去（PLから登録を消去する、という意味）、移動（PLの登録順序を書き替える、という意味）、全消去（PLの登録リストを初期化状態に書き換える）することにより行われる。

以下、図１３乃至図１７を参照して、オリジナル編集のひとつとして、ORGチャプタを選択削除する編集（削除）が行われる場合のFSのバックアップについて説明する。

図１３は、ORGチャプタの選択削除前の状態を示している。この図１３の状態で、図１のアプリケーションフォーマット制御部２２は、削除指定されたORGチャプタである動画ストリームファイルについて、記録メディア上からのデータ削除指定を行う。図１３の例では、ステップＳ２１１の処理として、チャプタ２であるファイルＮｏ．２とチャプタ３であるファイルＮｏ．３とがデータ削除対象として指定される。

図１４は、アプリケーションフォーマット登録削除更新の状態を示している。即ち、ステップＳ２１２において、アプリケーションフォーマット制御部２２は、チャプタ２であるファイルＮｏ．２とチャプタ３であるファイルＮｏ．３との各アプリケーションフォーマット登録管理情報の領域８１上の登録（エントリ）を削除する。即ち、チャプタ２であるファイルＮｏ．２とチャプタ３であるファイルＮｏ．３についての登録（エントリ）がPLから削除される。また、そのステップＳ２１２の処理中に、アプリケーションフォーマット制御部２２は、管理情報部分の書換え更新も行う。

図１５は、FSの登録の削除前の状態を示している。即ち、図１４のアプリケーションフォーマットの登録管理情報部分（PL部分）の削除更新が済んだら、図１５に示されるように、FSのファイル登録の削除のステップに進む。即ち、ステップＳ２１３の処理で、Backupメモリ１９のFSバックアップ記憶割当て領域（例えば図２のBUp Table_FS３２等）にFS BUp Markがセットされる。これにより、FSの管理情報の登録の削除処理が開始される。次に、ステップＳ２１４の処理で、ファイルＮｏ．２とファイルＮｏ．３のそれぞれについて、FSの管理情報の登録（エントリ）を削除するための更新情報が、FSの更新差分情報として生成され、Backupメモリ１９のFSバックアップ記憶割当て領域のFS差分情報領域（例えば図２のBUp Table_FS３２等）にバックアップされる。

図１６は、FSの登録の削除中の状態を示している。即ち、FSの更新差分情報のBackupメモリ１９へのバックアップが完了すると、記録メディア上の領域７１に対するFSの管理情報の更新書き込みが実行される。図１６の例では、ステップＳ２１５の処理で、Backupメモリ１９にバックアップされたFSの更新差分情報を用いて、FSの管理情報の登録が削除更新される。即ち、この例では、削除更新されるFSの管理情報の登録とは、削除対象のファイルＮｏ．２とファイルＮｏ．３の各FSの管理情報の登録（エントリ）を指す。また、この削除更新とは、具体的には、FSの更新差分情報が、FSの管理情報のFAT部分とDirectory Entry部分とのそれぞれに更新書き込みされることをいう。

この図１６の状態で記録再生装置１に電源遮断が発生した場合を考える。この場合、記録再生装置１は、Backupメモリ１９にFS BUp Markがセットされたままであることを判別して、Backupメモリ１９からFSの更新差分情報を読み取って、これを代わりに使用して、FSの管理情報のFAT部分とDirectory Entry部分とのそれぞれに更新書き込みを行えばよい。これによって、FSの管理情報の書き込み更新の最中に電源遮断が発生して、FSが管理情報不整合となり壊れてしまったような場合であって、Backupメモリ１９にバックアップされたFSの更新差分情報から安全にFSの管理情報を復旧して、このタイミングの電源遮断が原因で壊れたFSを復旧させることができる。

図１７は、FSの管理情報登録から削除完了までの状態が示されている。即ち、図１７に示される状態になると、ファイルＮｏ．２とファイルＮｏ．３とのFSの管理情報の登録（エントリ）の削除は完了しているので、ステップＳ２１６の処理で、ファイルＮｏ．２とファイルＮｏ．３の削除が行われ、ステップＳ２１７の処理で、Backupメモリ１９のFS BUp Markがクリアされる。これにより、FSの管理情報からファイルのエントリの削除処理が終了することになる。

以上の図１３乃至図１７におけるステップＳ２１１乃至Ｓ２１７の処理によって、FSの管理情報の登録（エントリ）を削除するためのFSの更新差分情報を用いて、記録メディア上のFSの管理情報の更新書き込みが可能となる。さらに、かかる更新書き込み中に電源遮断が発生した場合であっても、Backupメモリ１９のFSのバックアップ記憶割当て領域への書き込みと読出し制御が上述したように行われ、かかる制御の活用によって、電源遮断が原因で壊れたFSの復旧が可能となる。

なお、プレイリスト編集の削除更新においては、実ファイルの削除やサイズ変更は発生しないので、PLチャプタ登録、PLチャプタの選択消去、PLチャプタの選択移動、PLチャプタの全消去といった編集は、記録メディア上の領域８１における情報管理ファイル（PL）の内部にすでに予約確保されている領域への登録とリストの登録順が修正編集されて、その情報更新が行われる。このため、FSが更新書き込みで壊れることはない。

次に、上述したFS BUp Markを、記録メディアのフォーマット初期化でのFSバックアップ制御との共用使用する手法について説明する。具体的にはここではFS BUp Markの設定とクリアは、記録メディアのアプリケーションフォーマット初期化の際のFS初期化フォーマットと共用できることについて説明する。

この場合の処理（以下、フォーマット処理と称する）は、例えば図１８のフローチャートに示されるようになる。

即ち、ステップＳ３１１において、記録再生装置１は、アプリケーションフォーマットのアンロード処理を実行する。ここに、アンロード処理とは、アプリケーションフォーマット管理情報の制御をシステムの制御管理負荷から降ろし、アプリケーションフォーマット管理を終了させる処理を意味する。

ステップＳ３１２において、記録再生装置１は、ファイルシステムをアンマウントする。ここに、アンマウントとは、ドライブボリュームのFSの管理情報をドライブハードウエア認識情報の上に載せて読書き制御の情報処理インタフェースを管理する状態をいう。即ち、アンマウントするとは、ドライブハードウエア認識情報の上に載せたFSの管理情報の管理状態を終了させる、という意味である。

ステップＳ３１３において、記録再生装置１は、Backupメモリ１９にFS BUp Markをセットする。

ステップＳ３１４において、記録再生装置１は、FSのフォーマット初期化論理イメージ書き込み処理を行う。

即ち、FS BUp Markがセットされてから、FSのフォーマット初期化処理（フォーマット初期化論理イメージ書き込み処理）が開始される。このFSのフォーマット初期化処理としては、最初にメディアの物理フォーマットが実行され、その後、FSの論理フォーマットが実行される。ここで、FSの管理部分のみ初期化データを書きこむクイックフォーマットあるいはディスク全面をユーザデータで書き込み直すフルフォーマットが実行される。

なお、クイックフォーマットとフルフォーマットとのそれぞれについての、FSのアクセスアドレスとメディアセクタのアクセス順番との関係が、図１９に示されている。

図１８に戻り、ステップＳ３１５において、記録再生装置１は、Backupメモリ１９からFS BUp Markをクリアする。

その後、記録再生装置１は、ステップＳ３１６において、アプリケーションフォーマットの初期化イメージを生成して、ステップＳ３１７において、そのアプリケーションフォーマットの初期化イメージを記録メディアに書き込む。これにより、記録メディアのフォーマット初期化処理が完了する。

ステップＳ３１８において、記録再生装置１は、記録メディアに対するFSのマウント処理を実行する。

ステップＳ３１９において、記録再生装置１は、FSのマウント処理が成功したか否かを判定する。

FSのマウント処理に失敗した場合、ステップＳ３１９の処理でＮＯであると判定されて、処理はステップＳ３１３に戻され、それ以降の処理が繰り返される。

これに対して、FSのマウント処理に成功した場合、ステップＳ３１９の処理でＹＥＳであると判定されて、処理はステップＳ３２０に進む。

ステップＳ３２０において、記録再生装置１は、アプリケーションフォーマットのロード確認処理を実行する。

ステップＳ３２１において、記録再生装置１は、ロード確認処理が成功したか否かを判定する。

ロード確認処理に失敗した場合、ステップＳ３２１の処理でＮＯであると判定されて、処理はステップＳ３１３に戻され、それ以降の処理が繰り返される。

これに対して、ロード確認処理に成功した場合、ステップＳ３２１の処理でＹＥＳであると判定されて、フォーマット処理全体が終了となる。

以上の図１８のフローチャートに従った処理が、正常状態でのフォーマット処理である。これに対して、このフォーマット処理中に記録再生装置１の電源遮断が発生し、その後に電源が再投入された後に実行されるフォーマット処理（以下、電源遮断後の再フォーマット処理と称する）の一例が、図２０のフローチャートに示されている。

ステップＳ４１１において、記録再生装置１は、Backupメモリ１９からFS BUp Markがクリアされているか否かを判定する。

ステップＳ４１１において、FS BUp Markがクリアされていないと判定された場合、処理はステップＳ４１２に進む。記録再生装置１は、ステップＳ４１２において、FS BUp Markをセットし、ステップＳ４１３において、FSのフォーマット初期化論理イメージ書き込み処理を行い、ステップＳ４１４において、FS BUp Markをクリアする。その後、記録再生装置１は、ステップＳ４１５乃至Ｓ４２０の処理として、図１８のステップＳ３１６乃至Ｓ３２１と同様の処理を実行する。

これに対して、ステップＳ４１１において、FS BUp Markがクリアされていると判定された場合、処理はステップＳ４１５に進み、ステップＳ４１５乃至Ｓ４２０の処理として、図１８のステップＳ３１６乃至Ｓ３２１と同様の処理が実行される。

即ち、図１８のステップＳ３１４のFSのフォーマット初期化論理イメージ書き込み処理の実行中に電源遮断が発生した場合には、Backupメモリ１９にFS BUp Markがセットされたままとなる。従って、このような場合、ステップＳ４１１の処理でＮＯであると判定され、FSのフォーマット初期化論理イメージ書き込み処理から再開されるのである。

これに対して、Backupメモリ１９からFS BUp Markがクリアされている場合とは、FSのフォーマット初期化処理（FSのフォーマット初期化論理イメージ書き込み処理）の完了後に電源遮断が発生したこと、即ち、図１８のステップＳ３１５の処理後に電源遮断が発生したことを意味する。従って、このような場合、ステップＳ４１１の処理でＹＥＳであると判定され、アプリケーションフォーマット初期化処理以降から再開されるのである。

以上説明したように、通常の記録、オリジナル編集でのFSのバックアップ制御に対して、Backupメモリ１９にセットされるFS BUp Markを、システム（ここでは記録再生装置１）として統合的に使用することができる。

なお、フォーマット処理では、FSの更新差分情報のBackupメモリ１９へのバックアップは不要である。初期化が一旦開始されれば、後戻りはできないからである。

以上説明したように、本実施の形態の記録再生装置１は、アプリケーションフォーマットの動画データ書き込み最小記録単位とファイルシステムの最小単位の最小公倍数の整数倍を単位としてFSの更新差分情報を生成し、それをバックアップ情報としてBackupメモリ１９（図１）に記憶する。また、記録再生装置１は、記録処理の進捗を示す情報として、ファイルボディ書き込み中を示すBUp Mark1を付与し、FS更新書き込み中を示すBUp Mark2を付与する。従って、記録再生装置１の電源遮断が発生した際に、記録再生装置１は、ファイルシステムとディレクトリの更新情報とファイルシステム更新書き込み開始タイミングをアプリケーションフォーマットと整合とったバックアップ情報を、電源供給再開時等に実施する修復処理に効率よく用いることができる。

また、アプリケーションフォーマットレベルでは、記録再生装置１は、従来と同様に、バックアップ情報を使い、内蔵されている他パッケージ情報を読み出し活用し、修復をおこなうことができる。ただし、従来、アプリケーションフォーマットがベースにしているFS自体が壊れた場合には、どうすることもできなかった。これに対して、記録再生装置１は、図７や図９等を用いて説明したFS層／アプリ層確認修復処理を実行することができるので、電源遮断がFS更新書き込み中に発生した場合に破壊されるFSの修復を容易かつ的確に行うことができる。

ところで、上述した一連の処理は、ハードウエアにより実行させることもできるし、ソフトウエアにより実行させることもできる。一連の処理をソフトウエアにより実行させる場合には、そのソフトウエアを構成するプログラムが、専用のハードウエアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、プログラム記録媒体からインストールされる。

図２１は、上述した一連の処理をプログラムにより実行するパーソナルコンピュータの構成の例を示すブロック図である。

図２１において、CPU（Central Processing Unit）２０１は、ROM（Read Only Memory）２０２、または記憶部２０８に記憶されているプログラムに従って各種の処理を実行する。RAM（Random Access Memory）２０３には、CPU２０１が実行するプログラムやデータなどが適宜記憶される。これらのCPU２０１、ROM２０２、およびRAM２０３は、バス２０４により相互に接続されている。

CPU２０１にはまた、バス２０４を介して入出力インタフェース２０５が接続されている。入出力インタフェース２０５には、キーボード、マウス、マイクロホンなどよりなる入力部２０６、ディスプレイ、スピーカなどよりなる出力部２０７が接続されている。CPU２０１は、入力部２０６から入力される指令に対応して各種の処理を実行する。そして、CPU２０１は、処理の結果を出力部２０７に出力する。

入出力インタフェース２０５に接続されている記憶部２０８は、例えばハードディスクからなり、CPU２０１が実行するプログラムや各種のデータを記憶する。通信部２０９は、インターネットやローカルエリアネットワークなどのネットワークを介して外部の装置と通信する。

また、通信部２０９を介してプログラムを取得し、記憶部２０８に記憶してもよい。

入出力インタフェース２０５に接続されているドライブ２１０は、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア２１１が装着されたとき、それらを駆動し、そこに記録されているプログラムやデータなどを取得する。取得されたプログラムやデータは、必要に応じて記憶部２０８に転送され、記憶される。

コンピュータにインストールされ、コンピュータによって実行可能な状態とされるプログラムを格納するプログラム記録媒体は、図２１に示されるように、磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disc-Read Only Memory),DVD(Digital Versatile Disc)を含む）、光磁気ディスク、もしくは半導体メモリなどよりなるパッケージメディアであるリムーバブルメディア２１１、または、プログラムが一時的もしくは永続的に格納されるROM２０２や、記憶部２０８を構成するハードディスクなどにより構成される。プログラム記録媒体へのプログラムの格納は、必要に応じてルータ、モデムなどのインタフェースである通信部２０９を介して、ローカルエリアネットワーク、インターネット、デジタル衛星放送といった、有線または無線の通信媒体を利用して行われる。

即ち、図２１の例では、リムーバブルメディア２１１や記憶部２０８に含まれるハードディスクが、動画データ等の記録対象となる記録メディアとして利用される。従って、本発明を図１１のパーソナルコンピュータに適用することで、リムーバブルメディア２１１や記憶部２０８に含まれるハードディスクにおけるファイルシステムの修復が可能になる。

なお、本明細書において、プログラム記録媒体に格納されるプログラムを記述するステップは、記載された順序に沿って時系列的に行われる処理はもちろん、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。

また、本明細書において、システムとは、複数の装置または回路により構成される装置または回路全体を表すものである。

また、上述した例では、FSとして、FAT（File Allocation Table）形式のFSが採用されていたが、本発明はFAT形式以外の別のFSに適用することもできる。

本発明が適用される情報処理装置の一実施の形態の記録再生装置の機能的構成例を示す機能ブロック図である。 図１のバックアップメモリ制御部２５の制御例を説明する図である。 図１の記録再生装置の記録処理例の概略を説明するフローチャートである。 図３の記録処理のうちの動画記録終了命令が発行された後の詳細処理例を説明するフローチャートである。 従来の記録処理例を説明するフローチャートである。 本発明が適用される記録処理例を説明するフローチャートである。 本発明が適用されるFS層/アプリ層確認修復処理であって、図６に対応する処理例を説明するフローチャートである。 本発明が適用される記録処理例であって、図６とは別の例を説明するフローチャートである。 本発明が適用されるFS層/アプリ層確認修復処理であって、図８に対応する処理例を説明するフローチャートである。 記録動作に着目した図１の記録再生装置が採り得る状態一例を示す状態遷移図である。 図１の記録再生装置をビデオ一体型カメラとして構成した場合の外観構成例を示す図である。 図１１の記録再生装置が実行するFSのバックアップとその書き込み制御との全体処理例を説明する図である。 オリジナル編集のひとつとして、ORGチャプタを選択削除する編集（削除）が行われる場合のFSのバックアップ例を説明する図である。 オリジナル編集のひとつとして、ORGチャプタを選択削除する編集（削除）が行われる場合のFSのバックアップ例を説明する図である。 オリジナル編集のひとつとして、ORGチャプタを選択削除する編集（削除）が行われる場合のFSのバックアップ例を説明する図である。 オリジナル編集のひとつとして、ORGチャプタを選択削除する編集（削除）が行われる場合のFSのバックアップ例を説明する図である。 オリジナル編集のひとつとして、ORGチャプタを選択削除する編集（削除）が行われる場合のFSのバックアップ例を説明する図である。 本発明が適用されるフォーマット処理例を説明するフローチャートである。 クイックフォーマットとフルフォーマットとのそれぞれについての、FSのアクセスアドレスとメディアセクタのアクセス順番との関係例を示す図である。 本発明が適用される電源遮断後再フォーマット処理例を説明するフローチャートである。 本発明が適用される情報処理装置としてのパーソナルコンピュータの構成例を示すブロック図である。

符号の説明

１ 記録再生装置， ２ 操作装置， ３ パーソナルコンピュータ， ４ 映像音声出力装置， ５ リムーバブルメディア， １１ システム制御部， １２ 映像音声入出力I/F， １３ エンコード／デコード部， １４ データ制御部， １５ ドライブ制御部， １６ ハードディスクドライブ， ２１ 記録再生制御部， ２２ アプリケーションフォーマット制御部， ２３ FATファイルシステム制御部， ２４ メモリカード/HDDドライブ制御部， ３１ BUp Table_App， ３２ BUp Table_FS， ４１ ハードディスク， ４１−１乃至４１−４ ハードディスクの領域， ２０１ CPU， ２０２ ROM， ２０８ 記憶部， ２１１ リムーバブルメディア

Claims (9)

1. 所定のアプリケーションフォーマットと所定のファイルシステムに従って、映像音声ストリームデータを前記アプリケーションフォーマットの記録映像ストリームデータ単位毎に記録ハードディスクにファイルとして記録する映像記録ビデオカメラ装置において、
   所定のファイルの前記記録ハードディスクへの記録制御として、前記映像音声ストリームデータを前記記録映像ストリームデータ単位毎に前記記録ハードディスクへ記録していく映像音声ストリーム本体データ記録制御と、前記記録ハードディスクにおける前記ファイルシステムの１以上の管理情報データテーブルを更新する管理情報データ更新制御とを行う記録制御手段と、
   前記記録制御手段による前記記録制御中において、前記記録映像ストリームデータ単位と前記ファイルシステムの最小記録クラスタ単位の最小公倍数の整数倍を差分情報生成データ単位として、前記差分情報生成データ単位毎に、前記アプリケーションフォーマットの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成するアプリケーションフォーマット差分生成手段と、
   前記記録制御手段による前記記録制御中において、前記差分情報生成データ単位毎に、前記ファイルシステムの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成するファイルシステム差分生成手段と、
   前記ファイルシステム差分生成手段により生成された前記ファイルシステムの属性情報についての差分情報を、前記ファイルシステムの修復に使うバックアップ情報として記憶するバックアップ記憶手段と、
   前記管理情報データ更新制御における前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークを記憶する進捗マーク記憶手段と、
   前記記録制御手段による前記記録制御が異常終了した場合、前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークの前記進捗マーク記憶手段への記憶有無に応じて、前記バックアップ記憶手段に記憶された前記バックアップ情報で所定の前記管理情報データテーブルを修復する制御を行う修復制御手段と
   を備える映像記録ビデオカメラ装置。
2. 前記進捗マーク記憶手段は、さらに、前記記録映像ストリーム本体データ記録制御中を示す第２のマークを記憶する
   請求項１に記載の映像記録ビデオカメラ装置。
3. 前記修復制御手段は、前記第１のマークが進捗マーク記憶手段に記憶されている場合、所定の前記管理情報データテーブルを修復する制御を行う
   請求項２に記載の映像記録ビデオカメラ装置。
4. 前記ファイルシステムは、FAT（File Allocation Table）形式ファイルルシステムであり、前記ファイルシステムの管理情報データテーブルは、FAT1，FAT2，Directory Entryから構成されている
   請求項３に記載の映像記録ビデオカメラ装置。
5. 前記修復制御手段は、前記FAT1，前記FAT2，前記Directory Entryの一括修復を行う
   請求項４に記載の映像記録ビデオカメラ装置。
6. 前記ファイルシステムは、FAT（File Allocation Table）形式ファイルルシステムであり、前記ファイルシステムの管理情報データテーブルは、FAT1，FAT2，Directory Entryから構成され、
   前記記録制御手段による前記管理情報データ更新制御として、前記FAT1の更新制御，前記FAT2の更新制御，前記Directory Entryの更新制御がその順番で行われ、
   前記進捗マーク記憶手段は、
   前記第１のマークとして、
   前記FAT1の書き込み開始を示す第１−０のマークを記憶し、
   前記FAT2の書き込み開始を示す第１−１のマークを記憶し、
   前記Directory Entryの書き込み開始を示す第１−２のマークを記憶し、
   前記修復制御手段は、
   前記第１−０のマークが前記進捗マーク記憶手段に記憶されている場合、前記FAT1，前記FAT2，前記Directory Entryの修復を行い、
   前記第１−１のマークが前記進捗マーク記憶手段に記憶されている場合、前記FAT2，前記Directory Entryの修復を行い、
   前記第１−２のマークが前記進捗マーク記憶手段に記憶されている場合、前記Directory Entryの修復を行う
   請求項４に記載の映像記録ビデオカメラ装置。
7. 前記記録映像ストリームデータ単位は、ＲＵＶ（Recording Unit of Video Recording）である
   請求項１に記載の映像記録ビデオカメラ装置。
8. 所定のアプリケーションフォーマットと所定のファイルシステムに従って、映像音声ストリームデータを前記アプリケーションフォーマットの記録映像ストリームデータ単位毎に記録ハードディスクにファイルとして記録する映像記録ビデオカメラ装置の映像記録方法において、
   所定のファイルの前記記録ハードディスクへの記録制御として、前記映像音声ストリームデータを前記記録映像ストリームデータ単位毎に前記記録ハードディスクへ記録していく映像音声ストリーム本体データ記録制御と、前記記録ハードディスクにおける前記ファイルシステムの１以上の管理情報データテーブルを更新する管理情報データ更新制御とを行い、
   前記記録制御中において、前記記録映像ストリームデータ単位と前記ファイルシステムの最小記録クラスタ単位の最小公倍数の整数倍を差分情報生成データ単位として、前記差分情報生成データ単位毎に、前記アプリケーションフォーマットの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成し、
   前記記録制御中において、前記差分情報生成データ単位毎に、前記ファイルシステムの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成し、
   生成された前記ファイルシステムの属性情報についての差分情報を、前記ファイルシステムの修復に使うバックアップ情報としてバックアップ記憶手段に記憶し、
   前記管理情報データ更新制御における各前記管理情報データテーブルの書き込み開始を示す第１のマークを進捗マーク記憶手段に記憶し、
   前記記録制御が異常終了した場合、前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークの前記進捗マーク記憶手段への記憶有無に応じて、前記バックアップ記憶手段に記憶された前記バックアップ情報で所定の前記管理情報データテーブルを修復する制御を行う
   ステップを含む映像記録方法。
9. 所定のアプリケーションフォーマットと所定のファイルシステムに従って、映像音声ストリームデータを前記アプリケーションフォーマットの記録映像ストリームデータ単位毎に記録ハードディスクにファイルとして記録する制御をコンピュータに実行させるプログラムであって、
   所定のファイルの前記記録ハードディスクへの記録制御として、前記映像音声ストリームデータを前記記録映像ストリームデータ単位毎に前記記録ハードディスクへ記録していく映像音声ストリーム本体データ記録制御と、前記記録ハードディスクにおける前記ファイルシステムの１以上の管理情報データテーブルを更新する管理情報データ更新制御とを行い、
   前記記録制御中において、前記記録映像ストリームデータ単位と前記ファイルシステムの最小記録クラスタ単位の最小公倍数の整数倍を差分情報生成データ単位として、前記差分情報生成データ単位毎に、前記アプリケーションフォーマットの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成し、
   前記記録制御中において、前記差分情報生成データ単位毎に、前記ファイルシステムの属性情報の、前記差分情報生成データ単位の書き込みの前後での差分情報を順次生成し、
   生成された前記ファイルシステムの属性情報についての差分情報を、前記ファイルシステムの修復に使うバックアップ情報としてバックアップ記憶手段に記憶し、
   前記管理情報更新制御における前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークを進捗マーク記憶手段に記憶し、
   前記記録制御が異常終了した場合、前記１以上の管理情報データテーブルのそれぞれの書き込み開始を示す第１のマークの前記進捗マーク記憶手段への記憶有無に応じて、前記バックアップ記憶手段に記憶された前記バックアップ情報で所定の前記管理情報データテーブルを修復する制御を行う
   ステップを含むプログラム。

Images