JP4172500B2 - 記録装置および方法、プログラム、並びに記録媒体 - Google Patents

Description

本発明は、記録装置および方法、プログラム、並びに記録媒体に関し、特に、記録処理の異常終了においてもファイルシステムを容易に正しく保存することができるようにした記録装置および方法、プログラム、並びに記録媒体に関する。

従来、ヘッダ部、ボディ部、およびフッタ部の各部からなるファイルストリームを光ディスク等の記録媒体に記録する際に、シークの発生を抑制するために、時間軸上のデータ発生順であるボディ部、フッタ部、ヘッダ部の順で記録媒体の記録領域に配置（記録）する方法があった（例えば、特許文献１参照）。

この記録方法の場合、フッタ部を記録するフッタ領域と、ヘッダ部を記録するヘッダ領域は、記録媒体の記録領域内の、ボディ部を記録するボディ領域の直後の位置に記録される。従って、ボディ部の記録が終了するまでヘッダ領域の最終的な位置が確定しないという特徴があった。

つまり、ファイル記録中において、そのファイルの記録領域に関する情報は記録装置内のメモリに保持され、全ての記録操作が終了した時点で、その情報が、書き込みが行われた記録媒体（メディア）のファイルシステム管理領域に反映されていた。例えば、ヘッダ領域、ボディ領域、およびフッタ領域の各領域の書き込み先のアドレス情報が、メモリに保持され、それらの記録が終了した後、メモリに保持されているアドレス情報が、メディアに記録されているファイルシステムの管理ファイルに書き込まれていた（ファイルシステム管理領域の情報が更新される）。

従って、例えば、ボディ部が記録媒体に書き込まれている時に、記録装置自体の電源あるいはシステムハングアップなど続行不可能な異常が発生し、その記録処理が異常終了した場合、上述した記録方法では、ファイルシステム上妥当な形式で「記録途中のファイル」をメディア上のファイルシステムに反映する事はできなかった。つまり、記録が途中で終了されてしまったファイルは、ファイルシステム上「記録されていないファイル」と判定されてしまっていた。

この場合、ファイルシステム規格にはない独自のサルベージ手段によりファイルとして復旧する必要があった（例えば特許文献２参照）。この方法の場合、記録媒体にデータを記録する際に、サルベージマーカという所定の情報を所定の感覚で記録しておき、記録処理が異常終了した後のデータ復旧作業の際に、そのマーカの記録状況に基づいて、ファイルシステムに未だ反映されていないデータを検索し、その情報をファイルシステムに反映させていた。

このような復旧方法は、記録装置自体の電源あるいはシステムハングアップなど続行不可能な異常が発生した場合（異常終了時に記録に関する情報をファイルシステムに反映することができない場合）に特に効果的である。
特開２００５−４８５３号公報 特開２００６−６５９１２号公報

ところで、汎用のパーソナルコンピュータ等において、OS（Operating System）上で動作するアプリケーションやファイルシステムドライバなどにより同様の記録を実現する場合、記録の異常終了はアプリケーションの異常終了が原因となることが多い。このようなアプリケーションの異常終了のとき、ファイルシステムドライバ(FSD（File System Driver）)がそのアプリケーションの異常終了を検知することは難しいが、OSは動作している（終了していない）ので、FSDは、通常の記録方法であれば、その途中までの記録に関する情報を記録媒体の記録領域のファイルシステム（ファイルシステム管理情報）に反映させることにより、その途中まで記録されたデータを、記録媒体の記録領域のファイルシステムの規格に準拠した形式にする事は可能である。

つまり、異常終了においても、再起動後のアプリケーション（または他のパーソナルコンピュータで実行される同様のアプリケーション）が、上述したデータ復旧を行わずに、容易に、そのファイルの記録を再開することができるように、データを記録することができる。

そのためには、ヘッダ部については、ファイルストリーム上、ボディ部の前に位置するため、ファイルシステム上領域を宣言しておく必要があるが、記録方法が特許文献１に記載の方法の場合、上述したように、ボディ部の記録が終了するまでヘッダ領域の最終的な位置が確定しないため、ボディ部の書き込みが終了するまで、領域を宣言することができなかった。

従って、アプリケーションのバグや、パーソナルコンピュータのリソース不足等によってアプリケーションが異常終了した場合、途中まで記録されたデータを、記録媒体の記録領域のファイルシステムの規格に準拠した形式にする事ができない恐れがあった。つまり、このような異常終了により、ファイルの記録が途中で終了した場合、上述したファイルシステムには無い独自の特許文献２の方法によりデータを復旧するしかなく、正常なデータを得ることができるまでに、処理の負荷や時間が増大する恐れがあった。また、この復旧処理が特殊なため、パーソナルコンピュータ等の環境要因によって実行できない恐れもあった。

本発明は、このような状況に鑑みてなされたものであり、記録処理の異常終了においてもファイルシステムを容易に正しく保存することができるようにするものである。

本発明の一側面は、ヘッダ、ボディ、フッタにより構成されるファイルストリームを記録媒体に記録する記録装置であって、アプリケーションを実行し、アプリケーションの命令によって、ボディの記録前に、ヘッダを記録媒体とは異なる記憶媒体に保持させることにより、記録媒体の記録領域内に、仮想的な領域である仮想ヘッダ領域を確保する仮想ヘッダ領域確保手段と、アプリケーションを実行し、アプリケーションの命令によって、ボディ、フッタ、およびヘッダを、この順に、記録媒体の記録領域内の、仮想ヘッダ領域確保手段により確保された仮想ヘッダ領域以外の領域に記録する記録手段と、記録手段による記録処理が正常終了した場合、記録媒体の記録領域内の、記録手段によりヘッダが実際に記録された領域であるヘッダ領域の情報を記録媒体のファイルシステムに反映させ、アプリケーションの異常終了により記録手段による記録処理が異常終了した場合、仮想ヘッダ領域確保手段により確保された仮想ヘッダ領域の情報を記録媒体のファイルシステムに反映させる反映手段とを備える記録装置である。
前記記録手段は、ボディおよびフッタを記録した後、記憶媒体に保持されたヘッダを更新し、更新後のヘッダをヘッダ領域に記録することができる。

前記記録手段は、ボディ及びフッタを記録する前に、仮想ヘッダ領域確保手段により確保された仮想ヘッダ領域にヘッダを記録し、ボディおよびフッタを記録した後、ヘッダを更新し、更新後のヘッダをヘッダ領域に記録することができる。

前記仮想ヘッダ領域確保手段は、仮想ヘッダ領域を、記録領域の空き領域の先頭に設定することができる。

前記仮想ヘッダ領域確保手段は、仮想ヘッダ領域を、記録領域の空き領域の末尾に設定することができる。

前記仮想ヘッダ領域確保手段は、仮想ヘッダ領域を、記録領域に複数設けられたパーティション領域の内、ボディおよびフッタが記録されるパーティションと異なるパーティションに設定することができる。

前記ファイルシステムは、UDF（Universal Disk Format）であり、仮想ヘッダ領域確保手段は、仮想ヘッダ領域を、UDFにおける未記録未確保領域に配置することができる。

本発明の一側面はまた、ヘッダ、ボディ、フッタにより構成されるファイルストリームを記録媒体に記録する記録装置の記録方法であって、アプリケーションを実行する仮想ヘッダ領域確保手段が、ボディの記録前に、ヘッダを記録媒体とは異なる記憶媒体に保持させることにより、記録媒体の記録領域内に、仮想的な領域である仮想ヘッダ領域を確保し、アプリケーションを実行する記録手段が、ボディ、フッタ、およびヘッダを、この順に、記録媒体の記録領域内の、仮想ヘッダ領域以外の領域に記録し、反映手段が、記録処理が正常終了した場合、記録媒体の記録領域内の、ヘッダが実際に記録された領域であるヘッダ領域の情報を記録媒体のファイルシステムに反映させ、アプリケーションの異常終了により記録処理が異常終了した場合、仮想ヘッダ領域の情報を記録媒体のファイルシステムに反映させる記録方法である。

本発明の一側面はさらに、ヘッダ、ボディ、フッタにより構成されるファイルストリームを記録媒体に記録する処理を行うコンピュータを、アプリケーションを実行し、アプリケーションの命令によって、ボディの記録前に、ヘッダを記録媒体とは異なる記憶媒体に保持させることにより、記録媒体の記録領域内に、仮想的な領域である仮想ヘッダ領域を確保する仮想ヘッダ領域確保手段、アプリケーションを実行し、アプリケーションの命令によって、ボディ、フッタ、およびヘッダを、この順に、記録媒体の記録領域内の、仮想ヘッダ領域確保手段により確保された仮想ヘッダ領域以外の領域に記録する記録手段、記録手段による記録処理が正常終了した場合、記録媒体の記録領域内の、記録手段によりヘッダが実際に記録された領域であるヘッダ領域の情報を記録媒体のファイルシステムに反映させ、アプリケーションの異常終了により記録手段による記録処理が異常終了した場合、仮想ヘッダ領域確保手段により確保された仮想ヘッダ領域の情報を記録媒体のファイルシステムに反映させる反映手段として機能させるためのプログラムである。

本発明の一側面はまた、請求項９に記載のプログラムが記録されている記録媒体とすることができる。

本発明の一側面においては、アプリケーションの命令によって、ボディの記録前に、ヘッダを記録媒体とは異なる記憶媒体に保持させることにより、記録媒体の記録領域内に、仮想的な領域である仮想ヘッダ領域が確保され、アプリケーションの命令によって、ボディ、フッタ、およびヘッダが、この順に、記録媒体の記録領域内の仮想ヘッダ領域以外の領域に記録され、記録処理が正常終了した場合、記録媒体の記録領域内の、ヘッダが実際に記録された領域であるヘッダ領域の情報が記録媒体のファイルシステムに反映され、アプリケーションの異常終了により記録処理が異常終了した場合、仮想ヘッダ領域の情報が記録媒体のファイルシステムに反映される。

本発明の側面によれば、ファイルを記録することができる。特に、ファイルを記録媒体に記録する際に、ファイル内のデータを所定の順序で記録させるとき、記録処理が異常終了しても、ファイルシステムに準拠して、ファイルを容易に正しく保存することができる。

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

図１は、本発明を適用した光ディスク記録装置を用いたシステムの構成例を示すブロック図である。

図１において、光ディスク記録装置１１は、例えば、画像や音声などのデータを、CD（Compact Disc）やDVD（Digital Versatile Disc）等の光ディスク（記録媒体）に記録する装置であり、ネットワークケーブル１２を介して接続されたビデオカメラ１３より供給される画像データや音声データ等のAV（Audio Visual）データを含むファイルを、所定のファイルフォーマットで光ディスクに記録する。

ネットワークケーブル１２は、例えばUSB（Universal Serial Bus）やIEEE（Institute of Electrical and Electronic Engineers）1394等の所定の規格に準拠した通信ケーブルであり、光ディスク記録装置１１とビデオカメラ１３を通信可能に（データの授受を可能とするように）接続する。つまり、ネットワークケーブル１２は光ディスク記録装置１１とビデオカメラ１３との間の有線の通信媒体である。なお、このネットワークケーブル１２の代わりに、例えば、赤外線通信やIEEE802.11x等に代表される何らかの無線通信によって光ディスク記録装置１１とビデオカメラ１３が互いに通信を行うようにしてもよい。

ビデオカメラ１３は、カメラ部やマイク部を有しており、カメラ部において撮像して得られた動画像や静止画像の画像データ、および、マイク部で集音して得られた音声データよりなるAVデータ、並びに、その関連情報よりなる関連データを、所定のファイルシステム上で、ファイルとして、ネットワークケーブル１２を介して光ディスク記録装置１１に供給する。なお、ビデオカメラ１３は、AVファイルを記録媒体に記録する記録機能をさらに有するカムコーダ（登録商標）であってもよい。その場合、ビデオカメラ１３は、記録媒体に記録されたファイルを、ネットワークケーブル１２を介して光ディスク記録装置１１に供給することもできる。また、図１においてはビデオカメラ１３として説明するが、AVデータを含むファイルを光ディスク記録装置１１に供給する装置であれば、どのような装置であってもよい。

光ディスク記録装置１１は、例えば、汎用のパーソナルコンピュータにより構成される。光ディスク記録装置１１は、図１に示されるように、CPU（Central Processing Unit）２１、I/Oブリッジ２２、メインメモリ２３、ROM２４、バスI/F２５を有している。

CPU２１は、I/O（Input/Output）ブリッジを介して、DRAM（Dynamic Random Access Memory）等の半導体メモリにより構成されるメインメモリ２３、不揮発性のROM（Read Only Memory）２４、内部バス３０のインタフェース処理を行うバスインタフェース（バスI/F（InterFace））２５に接続されており、ROM２４に記憶されているプログラム、または後述する記憶部３５からメインメモリ２３にロードされたプログラムに従って各種の処理を実行する。メインメモリ２３にはまた、CPU２１が各種の処理を実行する上において必要なデータなども適宜記憶される。

バスインタフェース２５は、内部バス３０にも接続されている。内部バス３０は、例えば、ISAバス（Industry Standard Architecture bus）やPCIバス（Peripheral Components Interconnect bus）等に代表される所定の規格のバスであり、後述する各部とバスインタフェース２５を互いに接続し、各部間で行われる通信の通信媒体として機能する。

内部バス３０には、バスインタフェース２５の他に、ネットワークインタフェース（ネットワークI/F）３１、光ディスクドライブ３２、入力部３３、出力部３４、記憶部３５、およびドライブ３６が接続されている。

ネットワークインタフェース３１は、インターネットを含むネットワークを介しての通信処理を行い、光ディスク記録装置１１の外部の装置との情報の授受を行う。光ディスクドライブ３２は、所定の位置に装着された光ディスクメディア５１に対してデータの書き込みや読み出しを行うドライブ装置である。例えば、光ディスクドライブ３２は、内部バス３０を介して供給されるデータを、所定の位置に装着された、例えばCD-R（Compact Disc - Recordable）やDVD-R（Digital Versatile Disc - Recordable）のように書き込み可能な光ディスクメディア５１に書き込んだり、光ディスクメディア５１に記録されているデータを読み出し、内部バス３０を介してメインメモリ２３に供給したりする。

光ディスクドライブ３２は、その内部に、バスインタフェース（バスI/F）４１、キャッシュメモリ４２、およびメディア入出力制御部４３を有している。バスインタフェース４１は、内部バス３０のインタフェース処理を行う。キャッシュメモリ４２は、データ入出力の速度差によるオーバフローを低減させるために、バスインタフェース４１やメディア入出力制御部４３より供給されるデータを一時的に保持する。メディア入出力制御部４３は、図示せぬピックアップを制御し、光ディスクドライブ３２の所定の位置に装着された光ディスクメディア５１に対して、キャッシュメモリ４２より取得したデータを書き込んだり、光ディスクメディア５１に記録されているデータを読み出してキャッシュメモリ４２に供給したりする。

光ディスクメディア５１は、光ディスクドライブ３２に対応する記録媒体（メディア）である。光ディスクメディア５１は、例えば、UDF（Universal Disk Format）などの所定のファイルシステムでフォーマットされている。このファイルシステムのフォーマットに準拠する方法で光ディスクメディア５１に情報を記録する処理が行われるが、その処理は、CPU２１上で動作するソフトウェア（アプリケーションプログラムやドライバ）がそれを行うので、光ディスクドライブ３２はCPU２１からの命令を実行するだけで、その光ディスクメディア５１のファイルシステムのフォーマットを解析し、操作する事は行わない。

なお、以下において、記録媒体の例として、この光ディスクメディア５１を用いて説明するが、記録媒体としては、後述するようなAVデータを含むファイルを記録可能な記録媒体であれば、どのようなものであってもよく、例えば、磁気テープやハードディスクに代表される磁気記録媒体、MD（Mini-Disk（登録商標））等の光磁気ディスク、またはフラッシュメモリに代表される半導体メモリ等であってもよい。

図１に戻り、内部バス３０に接続される入力部３３は、例えば、キーボードやマウスなどの入力デバイスを含み、その入力デバイスを介してユーザからの指示を受け付け、その指示を、内部バス３０を介してCPU２１等に供給する。出力部３４は、例えば、CRT（Cathode Ray Tube）やLCD（Liquid Crystal Display）などよりなるディスプレイやスピーカ等の出力デバイスを有し、内部バス３０を介して供給されるAVデータ等を、画像や音声等として出力する。記憶部３５は、ハードディスク等の記録媒体を有し、例えば、CPU２１において実行されるプログラムやデータ等を記憶し、それらの情報を、適宜、内部バス３０を介して供給する。ドライブ３６には、磁気ディスク、光ディスク、光磁気ディスク、或いは半導体メモリなどのリムーバブルメディア３７が所定の位置に適宜装着され、それらから読み出されたコンピュータプログラムが、必要に応じて記憶部３５にインストールされる。

以上の様な構成を有する光ディスク記録装置１１のCPU２１は、内部バス３０を介してネットワークインタフェース３１に命令を送信し、ネットワークインタフェース３１に、ネットワークケーブル１２を介して接続されたビデオカメラ１３を制御させ、ビデオカメラ１３より映像音声信号（AVデータ）を同期的に取得させる。ネットワークインタフェース３１内にはバッファメモリがあり、取得した信号を一時的に蓄積し、内部バス３０を介した通信とネットワークケーブル１２を介した通信の速度差を緩和することができる。ネットワークインタフェース３１は、取得したAVデータを、内部バス３０を介してメインメモリ２３に保持させる。

CPU２１は、メインメモリ２３に保持されたAVデータ（ファイル）に対して、適宜、信号処理やフォーマット変換処理を行い、そのファイルを、内部バス３０を介して光ディスクドライブ３２に供給し、光ディスクメディア５１に書き込ませる。

図２は、図１のCPU２１において実行されるソフトウェアの構成例を示す模式図である。

図２において、ソフトウェア構成は、最上位層のユーザモード１００、中間層のカーネルモード１０１、最下位層のハードウェア抽象化層１０２に分けられる。まず、ユーザモード１００で動作するキャプチャアプリケーション１１１は、その下層のカーネルモード１０１で動作する、ネットワークインタフェース３１を制御するネットワークインタフェース制御用デバイスドライバ（ネットワークI/F制御用デバイスドライバ）１２１に対して、その先に接続された図１のビデオカメラ１３からの映像音声信号読込み命令を発行し、ネットワークインタフェース３１内のバッファメモリからメインメモリ２３へ映像音声信号を転送させる。その後、メインメモリ２３上で必要な信号変換処理やフォーマット変換処理を行う。ここでネットワークインタフェース制御用デバイスドライバ１２１は、バスインタフェース２５を制御する内部バスドライバ１２４、さらにその下層のハードウェア抽象化層１０２のインタフェースを利用してI/Oブリッジ２２のレジスタなどにアクセスし、内部バス３０経由でネットワークインタフェース３１に読込み転送命令を発行する。

さらにこのキャプチャアプリケーション１１１は上述のメインメモリ２３上でフォーマット変換を行った映像及び音声データについて、カーネルモード１０１で動作するファイルシステムドライバ１２２にそれぞれファイル書込み命令を発行する。この命令もファイルシステムドライバ１２２から、光ディスクドライブ３２を制御する光ディスクドライブ用デバイスドライバ１２３と、内部バスドライバ１２４を経て、内部バス３０経由で光ディスクドライブ３２に書き込み命令が伝達される。ただし、ここでは光ディスクメディア５１上の（記録領域の）何処のアドレスにそのデータストリームを(ファイルのデータとして)書き込むかを設定する必要があるが、本システムではキャプチャアプリケーション１１１が、ファイルシステムドライバ１２２に対しその書き込み先アドレスを設定（指定）することができるものとする。

図３は、図１に示されるシステムが、光ディスクメディア５１に映像音声信号を書き込む為のファイルフォーマットの例を示している。図３に示されるように、光ディスクメディア５１に記録される映像音声信号は、ファイルとして、ビデオデータ、オーディオデータ、およびその関連データが、それぞれまとめて配置されたファイルとされる。図３の例の場合、映像音声信号は、メインメモリ２３において、配下のファイルへのポインタが記述されたマスタファイル２００の下に構成される、ビデオファイル（Video）２０１、オーディオファイル（Audio1）２０２、およびオーディオファイル（Audio2）２０３の３つのファイルとして管理されている。

ビデオファイル２０１は、MXF(Material eXchange Format)に準拠したファイルであり、ヘッダ部２１１、ボディ部２１２、およびフッタ部２１３により構成される。ヘッダ部２１１は、例えば６４キロバイトのデータであり、その内部においてデータが、キー(Key)、レングス(Length)、バリュー(Value)の順で配置される、所謂KLV(Key,Length,Value)構造に配置されている。キーには、バリューに配置されるデータがどのようなデータであるかを表す、SMPTE 298Mの規格に準拠した１６バイトのラベルが配置される。レングスには、バリューに配置されるデータのデータ長が配置される。バリューには、実データが配置される。

つまり、図３の例の場合、ビデオファイル２０１のヘッダ部２１１においては、KLデータ（KL）２２１の後に、そのバリューとしてヘッダ（Header）２２２が配置され、KLデータ（KL）２２５の後に、そのバリューとしてヘッダメタデータ（Header Metadata）２２６が配置されている。なお、ヘッダ部２１１は、固定長であるので、スタッフィング(stuffing)のためのデータとしてのフィラー(Filler)が、やはりKLV構造とされて配置される。つまり、KLデータ（KL）２２３の後にフィラー(Filler)２２４が配置され、KLデータ（KL）２２７の後にフィラー(Filler)２２８が配置されている。

ボディ部２１２は、AVデータであるビデオデータが、例えば６４キロバイトの、KLV構造の連なり（アライメント）として構成される。各KLV構造のバリューは、MPEG(Moving Picture Experts Group)方式で符号化されたビデオデータのエレメンタリストリーム（MPEG ES（MPEG Elementary Stream））、若しくはフィラーにより構成される。図３の例の場合、KLデータ（KL）２３１の後に、そのバリューとしてエレメンタリストリーム（MPEG ES）２３２が配置されており、KLデータ（KL）２３３の後に、そのバリューとしてフィラー（Filler）２３４が配置されている。その後、同様にKLV構造が配置されており、KLデータ（KL）２３５の後に、そのバリューとしてエレメンタリストリーム（MPEG ES）２３６が配置されており、KLデータ（KL）２３７の後に、そのバリューとしてフィラー（Filler）２３８が配置されている。

フッタ部２１３は、ヘッダ部２１１と同様に、例えば６４キロバイトの、KLV構造のデータとして構成される。つまり、図３の例の場合、フッタ部２１３においては、KLデータ（KL）２４１の後に、そのバリューとしてフッタ（Footer）２４２が配置されており、KLデータ（KL）２４３の後に、フィラー（Filler）２４４が配置されている。

オーディオファイル２０２も、MXFに準拠したファイルであり、ビデオファイル２０１の場合と基本的に同様の構造を有しており、ヘッダ部２５１、ボディ部２５２、およびフッタ部２５３により構成される。

このヘッダ部２５１とボディ部２５２は、図３に示されるように、記録上のヘッダ部２５１Ａおよびボディ部２５２Ａの場合と、MXF形式上におけるヘッダ部２５１Ｂおよびボディ部２５２Ｂの場合とで構成が異なる。つまり、図３の例において、MXF形式上のヘッダ部２５１Ｂは、順に、KLデータ（KL）２６１、ヘッダ（Header）２６２、KLデータ（KL）２６３、フィラー（Filler）２６４、KLデータ（KL）２６５、ヘッダメタデータ（Header Metadata）２６６、KLデータ（KL）２６７、およびフィラー（Filler）２６８により構成される。また、MXF形式上のボディ部２５２Ｂは、AVデータであるオーディオデータが、KLV構造の連なり（アライメント）として構成される。各KLV構造のバリューは、AES(Audio Engineering Society)3方式（LPCM(Linear Pulse Code Modulation)方式）で符号化されたオーディオデータのエレメンタリストリーム（AES3（LPCM））、若しくはフィラー（Filler）により構成される。つまり、ボディ部２５２Ｂには、KLデータ（KL）２７１の後に、そのバリューとしてエレメンタリストリーム（AES3（LPCM））２７２が配置されている。その後、同様にKLV構造が配置され、エレメンタリストリーム（AES3（LPCM））２７３の後に、KLデータ（KL）２７４およびフィラー（Filler）２７５が配置されている。

これに対して、記録上のヘッダ部２５１Ａは、ヘッダ部２５１Ｂの構成に加え、ボディ部２５２ＢのKLデータ２７１までを含む。当然、記録上のボディ部２５２Ａには、エレメンタリストリーム２７２からフィラー（Filler）２７５までが配置されている。

なお、フッタ部２５３は、ビデオファイル２０１のフッタ部２１３の場合と同様に、例えば６４キロバイトの、KLV構造のデータとして構成される。図３の例の場合、フッタ部２５３には、KLデータ（KL）２８１、フッタ（Footer）２８２、KLデータ（KL）２８３、およびフィラー（Filler）２８４が順に配置されている。

オーディオファイル２０３は、オーディオファイル２０２と互いに異なるチャンネルのオーディオデータを含むファイルであり、その構成は、オーディオファイル２０２の場合と同様である。従って、オーディオファイル２０３は、MXFに準拠し、ヘッダ部２９１、ボディ部２９２、およびフッタ部２９３により構成される。

MXF形式上では、ヘッダ部２５１Ｂは、順に、KLデータ（KL）３０１、ヘッダ（Header）３０２、KLデータ（KL）３０３、フィラー（Filler）３０４、KLデータ（KL）３０５、ヘッダメタデータ（Header Metadata）３０６、KLデータ（KL）３０７、およびフィラー（Filler）３０８により構成され、ボディ部２９２Ｂは、順にKLデータ（KL）３１１、エレメンタリストリーム（AES3（LPCM））３１２、・・・、エレメンタリストリーム（AES3（LPCM））３１３、KLデータ（KL）３１４、フィラー（Filler）３１５により構成される。

これに対して、記録上のヘッダ部２９１Ａは、ヘッダ部２９１Ｂの構成に加え、ボディ部２９２ＢのKLデータ３１１までを含む。当然、記録上のボディ部２９２Ａには、エレメンタリストリーム３１２からフィラー（Filler）３１５までが配置されている。

なお、フッタ部２９３は、オーディオファイル２０２のフッタ部２５３の場合と同様に、例えば６４キロバイトの、KLV構造のデータとして構成される。図３の例の場合、フッタ部２９３には、KLデータ（KL）３２１、フッタ（Footer）３２２、KLデータ（KL）３２３、およびフィラー（Filler）３２４が順に配置されている。

図３においては、映像音声信号が１つのビデオファイルと２つのオーディオファイルにより構成されるように説明したが、ビデオファイルやオーディオファイルの数はいくつであってもよく、また、例えばメタデータにより構成されるファイルや、ローレゾデータを含むファイル等、その他のファイルを含むようにしてももちろんよい。

図２のキャプチャアプリケーション１１１（図１のCPU２１）は、映像音声信号をビデオカメラ１３から取得し、メインメモリ２３に保持させながら、図３に示されるようなファイルフォーマットに変換し、各ファイルを、順次、光ディスクドライブ３２経由で光ディスクメディア５１に書き込ませる。

その際、キャプチャアプリケーション１１１（CPU２１）は、各ファイルのヘッダ部の書き込みを、フッタ部の書き込みの後に実行させる。つまり、各ファイルのヘッダ部には、そのファイルの総記録長などを記載する必要がある。しかしながら、その総記録長などは書き込みが終了しないと決定しないパラメータである。つまり、通常のように、ヘッダ、ボディ、フッタの順でメディア上に書き込みを行う場合、少なくとも最終ボディ部の書き込みの後、総記録長などを修正するために、再度ヘッダ部を書き込む必要が生じるが、その場合、光ディスクメディア５１の記録領域内において大きく離れた場所へシークする必要があり、書き込み性能を著しく低下させる可能性がある。

そこで上述した引用文献１に記載の方法ではファイルフォーマット上論理的に前方に位置するヘッダを、配置上フッタの後方に領域確保し、フッタ部の記録後、それに連続した領域にヘッダ部の情報を記録する事で、シークの発生を抑制し、書き込み性能を低下させないようにした。

しかしながら、この方法では、ヘッダ部が最後まで書き込まれないので、例えば、キャプチャアプリケーション１１１がファイルの書き込み途中で異常終了した場合、そのファイルが光ディスクメディア５１のファイルシステム上において認識されない（全く記録されていないとされる）恐れがある。

例えば、図２のソフトウェア構成において、カーネルモード１０１の層以下においてこの予期せぬ異常が発生した場合や、ビデオカメラ１３からの入力映像音声信号が異常であった場合は、他の対処法が要求されるが、図２のユーザモード１００の層のキャプチャアプリケーション１１１のみが異常終了した場合であれば、ファイルシステムドライバ１２２によって、それまでの書き込みに関する情報をファイルシステムに反映させ、ファイルシステムにおいて認識可能なファイルにすることができる。

そこで、キャプチャアプリケーション１１１は、このような、発生の可能性が最も高い、ユーザモード１００の層のキャプチャアプリケーション１１１のみが異常終了した場合においても、この「書き込み処理」の正常終了(ファイルクローズ)させ、書き込み途中のデータを認識可能なファイルとすることができるように、ボディ部の書き込みの前に、ヘッダ部を記録するヘッダ領域を暫定的に確保するようにする。

図４は書き込み処理における動作モデルを模式的に示したものである。この書き込み処理においては、まず、各ファイルのヘッダ部を書き込むヘッダ領域が仮に（暫定的に）確保される（処理４０１）。

次に、連続的にオーディオデータ（Audio1）２０２、オーディオデータ（Audio2）２０３、およびビデオデータ（Video）２０４の、それぞれのボディ部のエレメンタリストリームが書き込まれるボディフラグメント領域が順に確保され、各データが記録されていき、最終ボディフラグメントの確保およびデータ記録が終了した時点で、次にフッタ部が書き込まれるフッタ領域が確保されて、それぞれのフッタ部が記録される。そして、その後に、ヘッダ部が書き込まれるヘッダ領域が、ボディ領域およびフッタ領域に基づいて再度確保され、そこにそれぞれのヘッダ部が記録される（処理４０２）。

以上のように、処理４０１において確保されたヘッダ領域は、処理４０２により、光ディスクメディア５１の記録領域における位置が更新される。つまり、図４に示されるように、処理４０１において確保されたオーディオファイル２０２の仮のヘッダ領域（”Audio1”ヘッダ（仮））４１１は、処理４０２によって、ヘッダ領域（”Audio1”ヘッダ）４１４に変更され、処理４０１において確保されたオーディオファイル２０３の仮のヘッダ領域（”Audio2”ヘッダ（仮））４１２は、処理４０２によって、ヘッダ領域（”Audio2”ヘッダ）４１５に変更され、処理４０１において確保されたビデオファイル２０１の仮のヘッダ領域（”Video”ヘッダ（仮））４１３は、処理４０２によって、ヘッダ領域（”Video”ヘッダ）４１６に変更される。

このようにボディ部の記録前に予めヘッダ領域を暫定的に確保することにより、キャプチャアプリケーション１１１の書き込み処理において、何らかの異常が発生し、処理を終了させた場合（ユーザモード１００のキャプチャアプリケーション１１１のみが異常終了した場合）、カーネルモード１０１で動作するファイルシステムドライバ１２２がそこまでの領域確保情報及び記録済位置を光ディスクメディア５１のファイルシステムに反映させる事が出来る。従って、この書き込み途中のファイルも、ファイルシステム上においてファイルとして認識させることができる。

以下に、具体的な処理の流れを説明する。

最初に、キャプチャアプリケーション１１１を実行するCPU２１（以下においてキャプチャアプリケーション１１１と称する）により実行される、映像音声信号（AVデータ）をビデオカメラ１３より取得しメインメモリ２３に保持させるキャプチャ処理の流れの例を、図５のフローチャートを参照して説明する。

キャプチャアプリケーション１１１は、このキャプチャ処理を実行することにより、ネットワークインタフェース制御用デバイスドライバ１２１を利用し、メインメモリ２３にビデオカメラ１３からの映像音声信号（AVデータ）を転送し、さらにそれに対して信号処理やフォーマット変換処理を行う。

例えば、入力部３３を介してユーザに映像音声信号のキャプチャ（取得）を指示されると、キャプチャアプリケーション１１１は、キャプチャ処理を開始し、ステップＳ１において、ネットワークインタフェース制御用デバイスドライバ１２１にキャプチャ開始命令を発行する。ネットワークインタフェース制御用デバイスドライバ１２１はこの命令に従い、ネットワークインタフェース３１に、ビデオカメラ１３から映像音声信号の取り込みを開始させる。ネットワークインタフェース３１は、この制御に従い、ビデオカメラ１３より映像音声信号を取得し、図示せぬ内部バッファに一時的に保持する。

キャプチャアプリケーション１１１は、ステップＳ２において、メインメモリ２３の記憶領域に、映像音声信号を保持するための、所定のデータサイズ分の領域、例えば時間軸上の固定量(２秒分や６０フレーム分など)に相当するサイズを確保する。

ステップＳ３において、キャプチャアプリケーション１１１は、ネットワークインタフェース３１の内部バッファにおける映像音声信号のデータ蓄積量を確認し、ステップＳ２においてメインメモリ２３に確保した領域のサイズに相当する量の映像音声信号のデータが溜まったか否かを判定し、溜まったと判定するまで待機する。

ネットワークインタフェース３１の内部バッファに映像音声信号のデータが、メインメモリ２３に確保された領域のサイズに相当するデータ量だけ溜まったと判定した場合、キャプチャアプリケーション１１１は、処理をステップＳ４に進め、ネットワークインタフェース制御用デバイスドライバ１２１を介してネットワークインタフェース３１に映像音声信号のデータのメインメモリ２３への転送を指示する。ネットワークインタフェース３１は、その指示に従い、内部バッファに蓄積された映像音声信号のデータを、内部バス３０を介してメインメモリ２３に転送する。

キャプチャアプリケーション１１１は、ステップＳ５において、メインメモリ２３に転送された映像音声信号に対して信号処理およびフォーマット変換処理を行い、図３に示されるような、ビデオファイル２０１、オーディオファイル２０２、オーディオファイル２０３のボディフラグメントとして書き込まれるデータを作成する。

ステップＳ６において、キャプチャアプリケーション１１１は、キャプチャ処理の停止が要求されたか否かを判定し、要求されていないと判定した場合、処理をステップＳ２に戻し、それ以降の処理を繰り返す。つまり、ネットワークインタフェース３１によってビデオカメラ１３より新たに取得され、その内部バッファに蓄積された新たなデータに対して、上述したような処理を行う。以上のステップＳ２乃至ステップＳ６を繰返し実行し、ステップＳ６において、例えばユーザにより入力部３３が操作され、キャプチャ処理の停止が要求されたと判定した場合、キャプチャアプリケーション１１１は、処理をステップＳ７に進め、ネットワークインタフェース制御用デバイスドライバ１２１を介してネットワークインタフェース３１にキャプチャ停止命令を発行する。キャプチャ停止命令が発行されるとネットワークインタフェース３１は、ビデオカメラ１３からの映像音声信号の取得を停止する。キャプチャアプリケーション１１１は、キャプチャ停止命令を発行後、キャプチャ処理を終了する。

以上のようなキャプチャ処理により、メインメモリ２３には、図３を参照して説明したような構成の、映像音声信号のファイルが生成される。

キャプチャアプリケーション１１１は、以上のようなキャプチャ処理と独立して、キャプチャ処理によりメインメモリ２３に蓄積された映像音声信号の各ファイルを光ディスクドライブ３２の光ディスクメディア５１に記録する記録処理を実行する。すなわち、この記録処理は、キャプチャ処理と同時並行的に実行可能である。

この記録処理の流れの例を、図６のフローチャートを参照して説明する。

例えば入力部３３を介して受け付けられたユーザ指示に基づいて、記録処理が開始されると、キャプチャアプリケーション１１１は、ステップＳ２１において、ファイルシステムドライバ１２２に仮のヘッダ領域を確保させる。ここで確保される仮のヘッダ領域の位置は任意である。詳細については後述する。また、この「領域の確保」は、この時点で光ディスクメディア５１上のファイルシステムに反映される訳ではなく（光ディスクメディア５１に記録されている管理情報に、ヘッダ領域のアドレス情報が記録されるのではなく）、CPU２１に実行されるファイルシステムドライバ１２２（以下、ファイルシステムドライバ１２２と称する）が、そのヘッダ領域に関する領域情報を仮想的にメインメモリ２３上に保持するものとする。

つまり、キャプチャアプリケーション１１１は、ファイルシステムドライバ１２２に、ボディ部の記録の前に、ヘッダ領域を、光ディスクメディア５１の記録領域内の、任意の領域（位置）に、仮想的に設定させ、その仮のヘッダ領域の領域情報をメインメモリ２３上に保持させることにより、暫定的にヘッダ領域を確保させる（仮のヘッダ領域を確保させる）。

仮のヘッダ領域が確保されると、キャプチャアプリケーション１１１は、ステップＳ２２において、メインメモリ２３においてアクセスするアドレスについて、ヘッダサイズ分のシークを行う。つまり、キャプチャアプリケーション１１１は、ファイルシステムドライバ１２２が、メインメモリ２３より処理対象のファイルのボディ部を取得するように、ヘッダ部の分のシークを行う。つまり、実際には、光ディスクメディア５１への、ヘッダ部の書き込みは行われておらず、次に光ディスクメディア５１に書き込まれるボディ部に対応する光ディスクメディア５１上の領域も確定していないので、実質的な光ディスクドライブ３２でのシークは発生しない。なお、ヘッダ部の仮のヘッダ領域への書き込みを実際に行うようにしてももちろんよい。

ステップＳ２３において、キャプチャアプリケーション１１１は、メインメモリ２３にアクセスし、上述したキャプチャ処理によって、メインメモリ２３に、次に記録すべきボディフラグメント・データが生成されているか否かを判定する。記録すべきボディフラグメント・データが生成されており、光ディスクメディア５１への記録が必要であると判定した場合、キャプチャアプリケーション１１１は、処理をステップＳ２４に進め、ファイルシステムドライバ１２２を制御し、オーディオファイル２０１、オーディオファイル２０２、およびビデオファイル２０３の各ファイルのボディフラグメントサイズ分のボディフラグメント領域を、光ディスクメディア５１上の連続的な空き領域に、その順で連続的に確保させる。

ボディフラグメント領域を確保すると、キャプチャアプリケーション１１１は、ステップＳ２５において、ファイルシステムドライバ１２２を制御し、その確保したボディフラグメント領域に対してボディフラグメントのデータ記録を行わせる。ステップＳ２５の処理を終了すると、キャプチャアプリケーション１１１は、処理をステップＳ２２に戻し、それ以降の処理を、キャプチャ処理によってメインメモリ２３上に生成された未書き込みのボディフラグメント・データが無くなるまで繰り返す。

そして、ステップＳ２３において、例えば未記録のボディフラグメントがメインメモリ２３上に存在しない等の理由から、次のボディフラグメントの記録が必要ないと判定した場合、キャプチャアプリケーション１１１は、処理をステップＳ２６に進める。

ステップＳ２６において、キャプチャアプリケーション１１１は、キャプチャ処理が停止したか否かを判定し、キャプチャ処理が停止していないと判定した場合、メインメモリ２３上に生成されたボディフラグメントが一時的に不足しただけであり、今後ボディフラグメントの記録が再度必要になると予想し、またボディフラグメントの記録を行うように、処理をステップＳ２２に戻し、それ以降の処理を繰り返す。

ステップＳ２６において、キャプチャ処理が停止したと判定した場合、キャプチャアプリケーション１１１は、ボディフラグメントの書き込みを正常終了し、処理をステップＳ２７に進め、ファイルシステムドライバ１２２を制御し、フッタ部について、光ディスクメディア５１上の最終ボディフラグメント領域に続く連続的な空き領域に、その順で連続的にフッタ領域を確保させ、ステップＳ２８において、そのフッタ領域に対してフッタ部のデータ記録を行わせる。

ここまでの処理により、ヘッダ部に記録すべき総記録長は決定される。従って、キャプチャアプリケーション１１１は、ステップＳ２９において、ファイルシステムドライバ１２２を制御し、光ディスクメディア５１上のフッタ領域に続く連続的な空き領域に、各ファイルのヘッダ部を記録するヘッダ領域を、同順で連続的な領域として再確保させる。つまり、キャプチャアプリケーション１１１は、ファイルシステムドライバ１２２に対して、ステップＳ２１において暫定的に確保され、メインメモリ２３に保持されている仮のヘッダ領域の領域情報を、フッタ領域に続く連続的な空き領域に更新させる（ヘッダ領域を変更させる）。

ヘッダ領域を再確保させると、キャプチャアプリケーション１１１は、ステップＳ３０において、ファイルシステムドライバ１２２を制御し、確保したヘッダ領域にヘッダ部の記録を行わせる。ヘッダ部の記録指示が終了すると、キャプチャアプリケーション１１１は、記録処理を正常終了する。

以上のように、記録処理の最初の処理において、キャプチャアプリケーション１１１は、ファイルシステムドライバ１２２を制御し、仮のヘッダ領域を確保させた後、光ディスクメディア５１上のボディフラグメント領域を確保させてボディフラグメントを書き込み、フッタ領域を確保させてフッタ部を書き込ませた後、そのフッタ領域に続く領域をヘッダ領域として再確保（ヘッダ領域を変更）させ、その新たなヘッダ領域にヘッダ部を書き込ませる。

なお、この記録処理が途中で異常終了した場合、その異常終了時以降の処理は実行されない。ファイルシステムドライバ１２２は、記録処理が正常終了または異常終了すると(OSよりファイルクローズを受け取ると)、終了処理を行い、光ディスクメディア５１上のファイルシステムに、上述した各ファイルに関するファイル情報、および、その各ファイルを書き込んだ各領域に関する領域情報を反映させる。

図７のフローチャートを参照して終了処理の流れの例を説明する。

終了処理が開始されるとファイルシステムドライバ１２２は、ステップＳ５１において、確保したヘッダ領域を光ディスクメディア５１上のファイルシステム（管理情報）に反映し、ステップＳ５２において、その他の領域について、記録済み位置をファイルシステムに反映する。ステップＳ５２の処理を終了すると、ファイルシステムドライバ１２２は、終了処理を終了する。

このように、記録処理が正常終了された場合、ファイルシステムドライバ１２２は、終了処理を実行し、実際にヘッダ部が書き込まれたヘッダ領域の位置をファイルシステムに書き込む。これに対して記録処理が異常終了された場合も、ファイルシステムドライバ１２２は、正常終了の場合と同様に終了処理を実行する。ただし、この異常終了の場合、その異常終了の時点においては仮のヘッダ領域が確保されているので、ファイルシステムドライバ１２２は、その確保されている仮のヘッダ領域を光ディスクメディア５１上のファイルシステムに反映することになる。

すなわち、ユーザモード１００で動作するキャプチャアプリケーション１１１が、記録処理において、ボディ部の書き込みの前に仮のヘッダ領域を確保することにより、その後、異常終了が発生した場合であっても、その仮のヘッダ領域をファイルシステムに反映することができるので、上述した特許文献２（特開２００６−６５９１２号公報）に記載の方法のようなデータ復旧処理を行わなくても、書き込み途中のデータをファイルとして認識させることができる。

つまり、異常終了したキャプチャアプリケーション１１１を再起動するだけで、光ディスク記録装置１１は、光ディスクメディア５１のファイルシステムに準拠しないような特別なデータ復旧処理を行わなくても、光ディスクメディア５１上の、書き込み途中であったデータをファイルとして扱うことができる。従って、その後、光ディスク記録装置１１は、再起動されたキャプチャアプリケーション１１１によって、中断された書き込み処理の再開や、そのファイルの削除等の対処を容易に行うことができる。

また、以上のように記録処理が異常終了した場合であってもファイルシステムが正しく保存され、書き込み途中であったデータもファイルシステムに、ファイルとして認識されるので、その光ディスクメディア５１のファイルシステムに対応する装置であれば、他の装置であっても（装置によらず）、その書き込み途中のデータをファイルとして扱うことができる。つまり、例えば、記録処理の異常終了後に、この光ディスクドライブ３２より光ディスクメディア５１が取り出され、他の光ディスクドライブ（他の装置）に装着されても、書き込み途中のデータは、他の装置においてファイルとして処理可能である（他の装置がデータ復旧機能を有していなくてもよい）。

なお、キャプチャアプリケーション１１１による、仮のヘッダ領域の確保は、メインメモリ２３に仮想的にヘッダ領域の情報を作成して保持させるだけで容易に実現可能である。また、実際に、この仮のヘッダ領域にヘッダ部を書き込んだとしても、ヘッダ領域のデータ量は、通常、ボディ部よりも十分に小さく、その処理の負荷は小さい。

また、記録処理が正常終了した場合、キャプチャアプリケーション１１１は、ヘッダ部を書き込んだヘッダ領域を再確保する（確保するヘッダ領域を更新する）が、メインメモリ２３上の情報を更新するだけでよく、その処理の負荷も小さく容易に行うことができる。

さらに、キャプチャアプリケーション１１１がこのように処理することにより、ファイルシステムドライバ１２２は、記録処理が正常終了した場合と、異常終了した場合のいずれの場合であっても、同様の終了処理を行うことができる。

以上のように、光ディスク記録装置１１は、特別な構成も復旧処理も必要なく、ボディ、フッタ、ヘッダの順で記録する記録領域確保ルールを守りながら、記録処理が正常終了する場合も異常終了する場合も同様に光ディスクメディア５１のファイルシステムに準拠するように、容易に、データ記録を行うことができる。また、このように記録されたデータは、書き込みが途中で終了したデータであっても、ファイルシステム上ファイルとして認識可能である。従って、光ディスク記録装置１１は、そのデータに対して、容易に、書き込みを再開したり、削除したりすることができる。

以上において、記録処理のステップＳ２１において確保される仮のヘッダ領域は、任意の領域であるように説明したが、その具体的な例を図８に示す。なお、図８において記録領域５０１は、光ディスクメディア５１の記録領域を帯状に示しており、左側が内周側であり、右側が外周側である。記録領域５０１の内周側には光ディスクメディア５１のファイルシステムが記録されるファイルシステム（FS）管理領域５１１が設けられている。通常の場合、書き込みは内周側から外周側に向かって行われ、映像音声信号等のデータを書き込み可能な空き領域は、そのファイルシステム管理領域５１１よりも外周側に設けられる。

図８Ａは、書き込みを行う空き領域の先頭に仮ヘッダ領域を確保する場合の例を示している。図８Ａにおいて、仮のヘッダ領域（ヘッダ（仮））５１２は、空き領域の最も内周側（先頭）に確保されている。その仮のヘッダ領域５１２に連続するように、ボディ部が書き込まれるボディ領域（ボディ）５１３、フッタ部が書き込まれるフッタ領域（フッタ）５１４、および、ヘッダ部が書き込まれるヘッダ領域（ヘッダ）５１５が、この順で確保される。従って、この場合、記録の最初に、仮のヘッダ領域５１２にヘッダ部の書き込みを行っても、光ディスクドライブ３２において実質的なシークは発生しない。ただし、図８Ａに示される方法の場合、仮のヘッダ領域５１２に実際にヘッダ部を書き込んでも書き込まなくても、ヘッダ５１５が確保された後も、この仮のヘッダ領域５１２が実質的に使用不可能な領域となる恐れがある。

また、例えば、図８Ｂに示されるように、仮のヘッダ領域５１２を、空き領域の最も外周側（末尾）に確保するようにしてもよい。この方法の場合、ボディ領域５１３、フッタ領域５１４、およびヘッダ領域５１５を、空き領域の先頭から外周側に向かって連続するように確保することができ、例えば、空き領域をボディ領域５１３およびフッタ領域５１４により全て使い切った場合、仮のヘッダ領域５１２をヘッダ領域５１５とすることができ、ヘッダ領域の再確保の必要が無くなる。ただし、この場合、仮のヘッダ領域５１２を確保する際に、その仮のヘッダ領域５１２にヘッダ部を実際に書き込みを行うと、実質的に光ディスクドライブ３２において実質的なシークが発生する。

さらに、例えば、図８Ｃに示されるように、仮のヘッダ領域を他のAVデータと異なるパーティションに確保するようにしてもよい。例えば、光ディスクメディア５１からのデータの読み出しと、読み出されたデータの再生を、並行して行う必要があるファイル（例えば、ビデオデータやオーディオデータのように読み出し速度を所定の速度以上に保つ必要があるデータのファイル）であるリアルタイム系のファイルと、データの読み出しと再生を並行して行う必要が無いファイル（例えば、テキストデータのように読み出し速度を所定の速度以上に保つ必要が無いデータのファイル）である非リアルタイム系のファイルとが、記録領域５０１の内周側と外周側などに分けられた複数のパーティションの互いに異なる方に記録される場合、ボディ領域５１３、フッタ領域５１４、およびヘッダ領域５１５は、全てリアルタイム系ファイルを記録するパーティションＡに確保されるが、仮のヘッダ領域５１２のみ、非リアルタイム系のファイルが記録されるパーティションＢに確保されるようにする。このようにすることにより、仮のヘッダ領域５１２の確保によって、ボディ領域５１３、フッタ領域５１４、およびヘッダ領域５１５の記録可能な領域の削減を抑制することができる。つまり、リアルタイム系ファイルが記録されるパーティションに仮ヘッダ部のデータが残る事がなく、書き込みが途中で異常終了したファイルは容易に発見可能になる。つまり、記録途中における異常終了の発生の有無の判定が容易になる。

また、例えば、図８Ｄに示されるように、スパースファイル（Sparse File）などに用いられる未記録未確保領域を利用するようにして、仮のヘッダ領域５１２を確保するようにしてもよい。例えばUDFでは未記録未確保領域として領域確保記述子(Allocation Descriptor)５２１を設定することができる。この領域確保記述子を利用することにより、キャプチャアプリケーション１１１は、実際に光ディスクメディア５１の記録領域を占有せずに、仮のヘッダ領域５１２を確保することができる。なお、この仮のヘッダ領域５１２に書き込みを行う場合、実際に光ディスクメディア５１には記録せずに、例えばメインメモリ２３に仮想的な領域を設け、その領域にデータを格納する（擬似的な書き込みを行う）ようにしてもよい。また、図８Ｃに示される場合の様に、非リアルタイム系のファイルが書き込まれるパーティションに仮のヘッダ領域５１２を再確保し（一時的に退避し）、その旨を光ディスクメディア５１のファイルシステム（ファイルシステム管理領域５１１）に反映し、ボディ部およびフッタ部の記録が終了した後、フッタ領域５１４の末尾に（外周側に領域が連続するように）ヘッダ領域５１５をさらに再確保し、その旨を光ディスクメディア５１のファイルシステム（ファイルシステム管理領域５１１）に反映するようにしてもよい。

以下に、光ディスクメディア５１のファイルフォーマットがUDFの場合における記録モデルの例を説明する。

図９は、UDFファイルシステムにおいて、上述した記録処理が正常終了した場合の記録モデルである。図９においては、連続したアドレス(LSN（Logical Sector Number）)が割り当てられた光ディスクメディア５１の記録領域の一部が、２本の垂直方向の帯状に示されている。図９中左側の記録領域６０１Ａは、主にファイルシステム管理用の情報（ファイルシステム管理領域）を記録する領域であり、そして図９中右側の記録領域６０１Ｂは、ファイルの実体(Extent)を記録する領域である。

図９において、例えば、確保しているヘッダ領域をファイルシステムに反映させるとは、記録領域６０１Ａに対し、ファイル管理情報を書き込む事である。オーディオファイル（Audio1）、オーディオファイル（Audio2）、およびビデオファイル（Video）の各ファイルの親ディレクトリの管理情報（Parent Directory）６１１に、各ファイルを識別するファイル識別子(File Identifier Descriptor)を書き込む（図９の例の場合、ファイル識別子は、親ディレクトリの管理情報（Parent Directory）６１１のファイルエントリ内(FileEntry)の領域に書き込まれる）。

そのファイル識別子にはファイル名やファイルエントリ(FileEntry)のアドレスが記録されている。さらに、そのファイル識別子が指し示す領域に、該当するオーディオファイル（Audio1）のファイルエントリ６１２、オーディオファイル（Audio2）のファイルエントリ６１３、ビデオファイル（Video）のファイルエントリ６１４がそれぞれ記録される。これらのファイルエントリ６１２乃至ファイルエントリ６１４のそれぞれには、そのファイルのデータの記録長や記録領域情報(Allocation Descriptor)が記録される。

記録領域６０１Ｂには、ファイルの実体であるボディフラグメント#1乃至ボディフラグメント#nが、オーディオファイル（Audio1）、オーディオファイル（Audio2）、ビデオファイル（Video）の各ボディフラグメントを１つずつまとめた年輪データ（年輪データ#1乃至年輪データ#2）として記録される。そして、そのボディ領域に続くフッタ領域にフッタ部（フッタ６３３乃至フッタ６３５）が記録され、そのフッタ領域に続くヘッダ領域にヘッダ部（ヘッダ６３６乃至ヘッダ６３８）が記録される（確保するヘッダ領域のアドレスが変更される（矢印６５１））。記録処理が正常終了すると、ファイルシステムドライバ１２２は、終了処理を実行し、上述した記録領域６０１Ａのファイルシステム管理情報（ファイルエントリ６１１乃至ファイルエントリ６１４）に対して、更新の為の書き込みを行う。

このとき、ファイルシステムドライバ１２２は、例えば、ファイルエントリ６１２に含まれる記録長や記録領域情報を、最初に確保していた仮のヘッダ領域６２１ではなく、確保し直したヘッダ領域６３６に更新する。すなわち、ファイルエントリ６１２とヘッダ領域の対応関係は、矢印６４１ではなく、矢印６４２のようになる。

なお、ファイルシステムドライバ１２２は、ファイルエントリ６１３の場合も同様に、記録長や記録領域情報を仮のヘッダ領域６２２ではなくヘッダ領域６３７に更新する。また、ファイルシステムドライバ１２２は、ファイルエントリ６１４の場合も同様に、記録長や記録領域情報を仮のヘッダ領域６２３ではなくヘッダ領域６３８に更新する。

図１０は、UDFファイルシステムにおいて、上述した記録処理が異常終了した場合の記録モデルである。図１０の場合も図９の場合と同様に、ファイルエントリ６１２乃至ファイルエントリ６１４のそれぞれには、そのファイルのデータの記録長や記録領域情報(Allocation Descriptor)が記録される。

記録処理が例えばボディ部書き込み中に異常終了したとすると、ファイルシステムドライバ１２２は、正常処理の場合と同様に終了処理を実行し、上述した記録領域６０１Ａのファイルシステム管理情報（ファイルエントリ６１１乃至ファイルエントリ６１４）に対して、更新の為の書き込みを行う。

このとき、ファイルシステムドライバ１２２は、例えば、ファイルエントリ６１２に含まれる記録長や記録領域情報を、異常終了の時点で確保している仮のヘッダ領域６２１に更新する。すなわち、ファイルエントリ６１２とヘッダ領域の対応関係は、矢印６４１のようになる。

なお、ファイルシステムドライバ１２２は、ファイルエントリ６１３の場合も同様に、記録長や記録領域情報を仮のヘッダ領域６２２に更新する。また、ファイルシステムドライバ１２２は、ファイルエントリ６１４の場合も同様に、記録長や記録領域情報を仮のヘッダ領域６２３に更新する。

この場合、ヘッダ領域に対して記録が行われなかった為、ファイルシステムドライバ１２２はそのファイルのヘッダ部読み出し要求に対しは全てゼロ(０)を返す。これにより途中までの記録をファイルシステム上に反映させる事が出来る。

その後再起動したキャプチャアプリケーション１１１は、一度ファイルの記録データを検証する事で途中までの記録を検出し、それにより記録の再開、またはその時点でそれぞれのファイルのヘッダを再確保して「記録処理」を正常終了することが出来る。

図１１は、この記録直後にヘッダ領域を再確保する手段を応用したUDFファイルシステムへの記録モデルの例である。ここでは、ヘッダ部は記録開始直後に連続記録領域の先頭に確保し（仮のヘッダ部６２１乃至仮のヘッダ部６２３）、一度適当なデータが記録される。その後図９の場合と同様に、連続領域にボディ領域およびフッタ領域を確保し、各領域にデータを記録する。その記録が終了した後、各ファイルのヘッダ部は、それぞれ、図１１の記録領域６０１Ａの、各ファイルエントリ（ファイルエントリ６１２乃至ファイルエントリ６１２）の直前の位置に再確保されたヘッダ領域（ヘッダ領域６３６乃至ヘッダ領域６３８）に記録される。その記録後、ファイルシステムドライバ１２２は、続いて各ファイルエントリを記録する（ファイル毎に、ヘッダ部書き込みおよびファイルエントリの更新を連続して行うようにしてもよい）。これにより記録時のシーク距離は図９のモデルとあまり変わらないが、再生の際ファイルオープン時にファイルエントリにアクセスし、それに続いてヘッダ部を読む様な場合、シーク距離が短縮し、性能の向上を望むことができる。

上述した一連の処理は、ハードウェアにより実行させることもできるし、ソフトウェアにより実行させることもできる。上述した一連の処理をソフトウェアにより実行させる場合には、そのソフウェアを構成するプログラムが、ネットワークや記録媒体からインストールされる。

この記録媒体は、例えば、図１に示されるように、装置本体とは別に、ユーザにプログラムを配信するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（CD-ROM(Compact Disk-Read Only Memory),DVD(Digital Versatile Disk)を含む）、光磁気ディスク（ＭＤ（Mini-Disk）（登録商標）を含む）、もしくは半導体メモリなどよりなるリムーバブルメディア３７により構成されるだけでなく、装置本体に予め組み込まれた状態でユーザに配信される、プログラムが記録されているROM２４や、記憶部３５に含まれるハードディスクなどで構成される。

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

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

なお、以上において、一つの装置として説明した構成を分割し、複数の装置として構成するようにしてもよい。逆に、以上において複数の装置として説明した構成をまとめて一つの装置として構成されるようにしてもよい。また、各装置の構成に上述した以外の構成を付加するようにしてももちろんよい。さらに、システム全体としての構成や動作が実質的に同じであれば、ある装置の構成の一部を他の装置の構成に含めるようにしてもよい。つまり、本発明の実施の形態は、上述した実施の形態に限定されるものではなく、本発明の要旨を逸脱しない範囲において種々の変更が可能である。

本発明は、記録装置に適用することが可能である。

本発明を適用した光ディスク記録装置の構成例を示すブロック図である。 ソフトウェアの構成例を示す模式図である。 ファイルフォーマットの例を示す図である。 書き込み処理における動作モデルを示す模式図である。 キャプチャ処理の流れの例を説明するフローチャートである。 記録処理の流れの例を説明するフローチャートである。 終了処理の流れの例を説明するフローチャートである。 仮のヘッダ領域の例を示す模式図である。 記録処理が正常終了した場合の記録モデルを示す図である。 記録処理が異常終了した場合の記録モデルを示す図である。 記録モデルの他の例を示す図である。

符号の説明

１１ 光ディスク記録装置， ２１ CPU， ２３ メインメモリ， ３２ 光ディスクドライブ， ５１ 光ディスクメディア， １１１ キャプチャアプリケーション， １２１ ネットワークインタフェース制御用デバイスドライバ， １２２ ファイルシステムドライバ， １２３ 光ディスクドライブ用デバイスドライバ， １２４ 内部バスドライバ， ５１１ ファイルシステム管理領域， ５１２ 仮のヘッダ領域

Claims (10)

1. ヘッダ、ボディ、フッタにより構成されるファイルストリームを記録媒体に記録する記録装置であって、
   アプリケーションを実行し、前記アプリケーションの命令によって、前記ボディの記録前に、前記ヘッダを前記記録媒体とは異なる記憶媒体に保持させることにより、前記記録媒体の記録領域内に、仮想的な領域である仮想ヘッダ領域を確保する仮想ヘッダ領域確保手段と、
   前記アプリケーションを実行し、前記アプリケーションの命令によって、前記ボディ、前記フッタ、および前記ヘッダを、この順に、前記記録媒体の記録領域内の、前記仮想ヘッダ領域確保手段により確保された前記仮想ヘッダ領域以外の領域に記録する記録手段と、
   前記記録手段による記録処理が正常終了した場合、前記記録媒体の記録領域内の、前記記録手段により前記ヘッダが実際に記録された領域であるヘッダ領域の情報を前記記録媒体のファイルシステムに反映させ、前記アプリケーションの異常終了により前記記録手段による記録処理が異常終了した場合、前記仮想ヘッダ領域確保手段により確保された前記仮想ヘッダ領域の情報を前記記録媒体のファイルシステムに反映させる反映手段と
   を備える記録装置。
2. 前記記録手段は、前記ボディおよび前記フッタを記録した後、前記記憶媒体に保持された前記ヘッダを更新し、更新後の前記ヘッダを前記ヘッダ領域に記録する
   請求項１に記載の記録装置。
3. 前記記録手段は、前記ボディ及び前記フッタを記録する前に、前記仮想ヘッダ領域確保手段により確保された前記仮想ヘッダ領域に前記ヘッダを記録し、前記ボディおよび前記フッタを記録した後、前記ヘッダを更新し、更新後の前記ヘッダを前記ヘッダ領域に記録する
   請求項１に記載の記録装置。
4. 前記仮想ヘッダ領域確保手段は、前記仮想ヘッダ領域を、前記記録領域の空き領域の先頭に設定する
   請求項１に記載の記録装置。
5. 前記仮想ヘッダ領域確保手段は、前記仮想ヘッダ領域を、前記記録領域の空き領域の末尾に設定する
   請求項１に記載の記録装置。
6. 前記仮想ヘッダ領域確保手段は、前記仮想ヘッダ領域を、前記記録領域に複数設けられたパーティション領域の内、前記ボディおよび前記フッタが記録されるパーティションと異なるパーティションに設定する
   請求項１に記載の記録装置。
7. 前記ファイルシステムは、UDF（Universal Disk Format）であり、
   前記仮想ヘッダ領域確保手段は、前記仮想ヘッダ領域を、前記UDFにおける未記録未確保領域に配置する
   請求項１に記載の記録装置。
8. ヘッダ、ボディ、フッタにより構成されるファイルストリームを記録媒体に記録する記録装置の記録方法であって、
   アプリケーションを実行する仮想ヘッダ領域確保手段が、前記ボディの記録前に、前記ヘッダを前記記録媒体とは異なる記憶媒体に保持させることにより、前記記録媒体の記録領域内に、仮想的な領域である仮想ヘッダ領域を確保し、
   前記アプリケーションを実行する記録手段が、前記ボディ、前記フッタ、および前記ヘッダを、この順に、前記記録媒体の記録領域内の、前記仮想ヘッダ領域以外の領域に記録し、
   反映手段が、記録処理が正常終了した場合、前記記録媒体の記録領域内の、前記ヘッダが実際に記録された領域であるヘッダ領域の情報を前記記録媒体のファイルシステムに反映させ、前記アプリケーションの異常終了により前記記録処理が異常終了した場合、前記仮想ヘッダ領域の情報を前記記録媒体のファイルシステムに反映させる
   記録方法。
9. ヘッダ、ボディ、フッタにより構成されるファイルストリームを記録媒体に記録する処理を行うコンピュータを、
   アプリケーションを実行し、前記アプリケーションの命令によって、前記ボディの記録前に、前記ヘッダを前記記録媒体とは異なる記憶媒体に保持させることにより、前記記録媒体の記録領域内に、仮想的な領域である仮想ヘッダ領域を確保する仮想ヘッダ領域確保手段、
   前記アプリケーションを実行し、前記アプリケーションの命令によって、前記ボディ、前記フッタ、および前記ヘッダを、この順に、前記記録媒体の記録領域内の、前記仮想ヘッダ領域確保手段により確保された前記仮想ヘッダ領域以外の領域に記録する記録手段、
   前記記録手段による記録処理が正常終了した場合、前記記録媒体の記録領域内の、前記記録手段により前記ヘッダが実際に記録された領域であるヘッダ領域の情報を前記記録媒体のファイルシステムに反映させ、前記アプリケーションの異常終了により前記記録手段による記録処理が異常終了した場合、前記仮想ヘッダ領域確保手段により確保された前記仮想ヘッダ領域の情報を前記記録媒体のファイルシステムに反映させる反映手段
   として機能させるためのプログラム。
10. 請求項９に記載のプログラムが記録されている記録媒体。

Images