(57)【要約】  記録済みの情報の消去の最小単位がブロックである記録領域を有する記録メモリ（１１１）に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録再生装置（１００）であって、ファイルの記録開始要求および記録停止要求を受け付ける入力部（１３０）と、記録開始要求が受け付けられた場合、ファイルのヘッダ部とヘッダ部に続くデータ部とを記録領域内のブロックの先頭から記録し、記録停止要求が受け付けられた場合、ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録するシステム制御部（１０１）とを備え、システム制御部（１０１）はさらに、更新後のヘッダ部が他のクラスタに記録される場合、更新後のヘッダ部にデータ部が続くように、記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する。
2008146475.tif 000002
【特許請求の範囲】
【請求項１】
記録済みの情報の消去の最小単位がブロックである記録領域を有する記録媒体に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録装置であって、  ファイルの記録開始要求および記録停止要求を受け付ける受付手段と、  前記受付手段により前記記録開始要求が受け付けられた場合、前記ファイルのヘッダ部と前記ヘッダ部に続くデータ部とを前記記録領域内のブロックの先頭から記録し、前記受付手段により前記記録停止要求が受け付けられた場合、前記ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録する記録手段と、  前記記録手段により前記更新後のヘッダ部が前記他のクラスタに記録される場合、前記更新後のヘッダ部に前記データ部が続くように、前記記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する修正手段と  を備える記録装置。
【請求項２】
前記記録手段は、前記受付手段により前記記録停止要求が受け付けられた場合、前記更新前のヘッダ部を記録したブロックとは異なるブロックに含まれる前記他のクラスタに、更新後のヘッダ部を記録する  請求項１記載の記録装置。
【請求項３】
前記記録手段は、前記受付手段により前記記録開始要求が受け付けられた場合、クラスタサイズの整数倍のサイズである前記更新前のヘッダ部を前記記録領域内のブロックに記録する  請求項１記載の記録装置。
【請求項４】
前記記録手段は、前記更新前のヘッダ部が複数のクラスタにまたがって記録されている場合、前記受付手段により前記記録停止要求が受け付けられると、前記複数のクラスタに記録されている情報の全てを、前記複数のクラスタとは異なる、前記他のクラスタを含む複数のクラスタに記録する  請求項３記載の記録装置。
【請求項５】
前記記録手段は、前記更新前のヘッダ部が複数のクラスタにまたがって記録されている場合、前記受付手段により前記記録停止要求が受け付けられると、前記更新前のヘッダ部の中の更新すべき部分を記録しているクラスタのみから情報を読み出して更新し、更新した情報を前記他のクラスタに記録する  請求項３記載の記録装置。
【請求項６】
前記修正手段は、前記記録手段により前記更新後のヘッダ部が前記他のクラスタに記録される場合、さらに、前記更新前のヘッダ部が記録されていたクラスタが未使用のクラスタであることを前記管理情報が示すように前記管理情報を修正することで、前記更新前のヘッダ部が記録されたクラスタを解放する  請求項１記載の記録装置。
【請求項７】
前記管理情報は、前記更新前のヘッダ部が記録されたクラスタを特定する情報を含むファイルエントリと、前記接続順序を示す複数のＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅｓ）エントリとを含み、  前記修正手段は、前記管理情報を修正する場合、（１）前記他のクラスタに対応するＦＡＴエントリの確保、（２）前記ＦＡＴエントリの変更、（３）前記ファイルエントリの変更、（４）前記更新前のヘッダ部が記録されたクラスタの解放という順番で処理を行う  請求項６記載の記録装置。
【請求項８】
前記記録媒体は、不揮発性半導体メモリ媒体である  請求項１記載の記録装置。
【請求項９】
前記記録手段はさらに、前記記録媒体の残量がなくなったことを検出した場合、前記更新前のヘッダ部を更新し、前記他のクラスタに前記更新後のヘッダ部を記録する  請求項１記載の記録装置。
【請求項１０】
記録済みの情報の消去の最小単位がブロックである記録領域を有する記録媒体に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録装置における記録方法であって、  ファイルの記録開始要求および記録停止要求を受け付ける受付ステップと、  前記受付ステップにおいて前記記録開始要求が受け付けられた場合、前記ファイルのヘッダ部と前記ヘッダ部に続くデータ部とを前記記録領域内のブロックの先頭から記録し、前記受付ステップにおいて前記記録停止要求が受け付けられた場合、前記ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録する記録ステップと、  前記記録ステップにおいて前記更新後のヘッダ部が前記他のクラスタに記録される場合、前記更新後のヘッダ部に前記データ部が続くように、前記記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する修正ステップと  を含む記録方法。
【請求項１１】
記録済みの情報の消去の最小単位がブロックである記録領域を有する記録媒体に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録装置を制御するためのプログラムであって、  ファイルの記録開始要求および記録停止要求を受け付ける受付ステップと、  前記受付ステップにおいて前記記録開始要求が受け付けられた場合、前記ファイルのヘッダ部と前記ヘッダ部に続くデータ部とを前記記録領域内のブロックの先頭から記録し、前記受付ステップにおいて前記記録停止要求が受け付けられた場合、前記ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録する記録ステップと、  前記記録ステップにおいて前記更新後のヘッダ部が前記他のクラスタに記録される場合、前記更新後のヘッダ部に前記データ部が続くように、前記記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する修正ステップと  をコンピュータに実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】  本発明は、フラッシュメモリ等の記録媒体に対して映像ファイル等を記録する技術に関する。
【背景技術】
【０００２】  データが不揮発なメモリ素子を内蔵した半導体メモリカードは、パーソナル・コンピュータやデジタルスチルカメラだけでなく、デジタルビデオカメラ等の記録媒体としても普及してきている。【０００３】  近年、テレビ放送のデジタル化やＨＤ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）化に伴い、半導体メモリカードの更なる大容量化や高速化が求められている。【０００４】  一般に、多くの半導体メモリカードでは内部にフラッシュメモリが使用されている。フラッシュメモリは消去の最小単位がブロックである記録媒体である。具体的には、フラッシュメモリは、消去ブロックと呼ばれる一定のサイズのデータが電気的に一括消去される特徴を持っている。【０００５】  このような消去の最小単位がブロックである記録媒体に記録された、ブロックのサイズに満たないデータを更新する場合、以下の動作が発生する。【０００６】  すなわち、一度そのデータを含むブロック全体のデータを読み出して保持しておき、そのブロックに記録されているデータを一括消去する。さらに、保持しておいたデータを部分的に更新して、更新したデータをブロックに書き戻す。【０００７】  このような動作はリード・モディファイ・ライトと呼ばれる。リード・モディファイ・ライトは、記録動作が複雑になり、記録の転送レートが低下する原因となる。【０００８】  一方、デジタルビデオカメラのような映像信号及び音声信号を記録する装置において、映像信号等をファイル化して記録媒体に記録することが一般的になってきている。【０００９】  デジタルビデオカメラで採用されているデータ形式としては、例えば、ＳＭＰＴＥ３７０Ｍ規格に準拠したＤＶＣＰＲＯ−ＨＤ圧縮データがあり、ファイル形式としてはＳＭＰＴＥ−３７７Ｍに準拠したＭＸＦファイルがある。【００１０】  ＭＸＦ（Ｍａｔｅｒｉａｌ  ｅＸｃｈａｎｇｅ  Ｆｏｒｍａｔ）とは、ＳＭＰＴＥによって規格化された素材交換用のフォーマットであり、メーカー独自のデジタル機器と他のメーカーの機器間でデータの受け渡しを可能とするものである。【００１１】  図１は、映像ファイル及び音声ファイルの構成を示す図である。【００１２】  図１（ａ）に映像データ形式がＤＶＣＰＲＯ−ＨＤの映像ＭＸＦファイルの構造を示す。【００１３】  圧縮映像データ（ＤＩＦ）は、ファイルヘッダの後のＫＬＶ構造のＢｏｄｙ内に格納される。ＤＶＣＰＲＯ−ＨＤでは１フレーム分のＤＩＦ符号量は４８０，０００Ｂｙｔｅである。従って、Ｎフレーム記録時のＢｏｄｙの符号量は上記１フレームあたりの符号量のＮ倍となる。【００１４】  図１（ｂ）に音声データ形式がＷａｖｅ形式の音声ＭＸＦファイルの構造を示す。【００１５】  １サンプルあたり１６ｂｉｔの音声データは、ファイルヘッダの後のＫＬＶ構造のＢｏｄｙ内に格納される。従って、Ｍサンプル記録時のＢｏｄｙの符号量はＭ×２Ｂｙｔｅとなる。【００１６】  また、ＫＬＶ構造のＫ（Ｋｅｙ）部には記録したデータの種類が格納され、Ｌ（Ｌｅｎｇｔｈ）部にはデータのサイズが格納される。【００１７】  映像ＭＸＦファイルのＫｅｙ部には、データの種類、およびフレーム周波数が格納される。音声ＭＸＦファイルのＫｅｙ部には、データの種類、サンプリング��波数、およびビット数が格納される。【００１８】  例えば、映像ファイルの場合は、Ｋｅｙ部に、ＤＶＣＰＲＯ−ＨＤ、ＮＴＳＣ、およびインタレースを示す情報が格納される。また、音声ファイルの場合は、Ｋｅｙ部に、Ｗａｖｅ形式、４８ｋＨｚ、および１６ｂｉｔを示す情報が格納される。【００１９】  以降、ファイルヘッダとＫＬ部を合わせてヘッダ部と呼び、ＫＬ部以降のＢｏｄｙをデータ部と呼び、ファイルフッタをフッタ部と呼ぶ。【００２０】  前述のように、ヘッダ部のＬｅｎｇｔｈ部にはそのファイルのデータサイズを格納する。しかし、デジタルビデオカメラのように信号ストリームを記録する場合、記録が終了するまでデータサイズが確定しない。【００２１】  よって、Ｌｅｎｇｔｈ部への書き込みは記録終了時に行う必要がある。一方、ヘッダ部はファイル先頭に存在するものであるため、記録開始時に最初に記録されなければならない。【００２２】  そこで、Ｌｅｎｇｔｈ部を“０”としてヘッダ部をデータ部よりも先に記録しておき、記録中に電源遮断が起こっても、途中まで記録したデータをヘッダ部の情報に基づいて復旧させるということも行われている。【００２３】  このようにした場合、映像及び音声ファイルの記録終了時にはヘッダ部のＬｅｎｇｔｈ部の正しい値への書き換えが起こる。つまり、前述のリード・モディファイ・ライトが発生してしまう。【００２４】  なお、ヘッダ部以外の部分については、消去ブロックの整数倍の単位で書き込みをしているので、リード・モディファイ・ライトは発生しない。【００２５】  図２は、特許文献１に開示されている記録方法を示す図である。【００２６】  ここでは、物理ブロックの状態および論理／物理テーブルそれぞれの一例が示されている。図２（ａ）に示されるように、物理アドレス１０のブロックにクラスタ１およびクラスタ２が存在し、それぞれのクラスタにはデータが記録されている。【００２７】  物理アドレス１０のブロックは論理アドレス“０ｘ２４０”と関連付けられていることが論理／物理テーブルに記載されている。【００２８】  ここで、クラスタ１についてデータの書き込み命令が出された場合を想定する。この場合、クラスタ１が存在する物理ブロック１０にはクラスタ２も存在する。そのため、図２（ｂ）に示されるように、物理アドレス１１のフリーブロックに新しいクラスタ１のデータを書き込む。【００２９】  そして、クラスタ２のデータを物理ブロック１０から物理ブロック１１にコピーし、論理／物理テーブルの論理アドレス“０ｘ２４０”に対応する物理アドレスを“１０”から“１１”に更新する。さらに、物理ブロック１０のデータを消去してフリーブロックにする。【特許文献１】特開２００６−０４８２２７号公報
【発明の開示】
【発明が解決しようとする課題】
【００３０】  特許文献１に開示されている記録方法によると、上記のように、ブロックの一部だけを書き換える場合でもそのブロックすべてのデータをフリーブロックに移動させることになる。【００３１】  そのため、余分なデータの読み出しが発生し、実質的にリード・モディファイ・ライトと同じ動作になって、記録速度が低下してしまうという課題がある。【００３２】  本発明は、上記課題を解決するものであって、ブロックサイズよりも小さなデータを書き換える場合でもリード・モディファイ・ライトの発生を回避することができる記録装置および記録方法を提供することを目的とする。
【課題を解決するための手段】
【００３３】  前記目的を達成するために、本発明に係る記録装置は、記録済みの情報の消去の最小単位がブロックである記録領域を有する記録媒体に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録装置であって、ファイルの記録開始要求および記録停止要求を受け付ける受付手段と、前記受付手段により前記記録開始要求が受け付けられた場合、前記ファイルのヘッダ部と前記ヘッダ部に続くデータ部とを前記記録領域内のブロックの先頭から記録し、前記受付手段により前記記録停止要求が受け付けられた場合、前記ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録する記録手段と、前記記録手段により前記更新後のヘッダ部が前記他のクラスタに記録される場合、前記更新後のヘッダ部に前記データ部が続くように、前記記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する修正手段とを備える。【００３４】  この構成により、ブロックサイズよりも小さいファイルのヘッダ部を更新する場合、既に確保されているクラスタではなく新たに確保されたクラスタに更新後のヘッダ部が記録される。【００３５】  ここで、データ部を移動させることなく上記処理を行った場合、記録媒体内において、ヘッダ部とデータ部とがこの順に連続するという当初の物理的な位置関係は崩れる。しかし、クラスタ単位の情報の接続順を示す管理情報が修正されることにより、ヘッダ部にデータ部が続くという当該ファイル本来の論理的な接続順序は維持される。そのため、当該ファイルを読み出す場合に、当該ファイルは正しく再構成される。【００３６】  このように、本発明の記録装置は、ヘッダ部の更新処理において、更新後のヘッダ部を新たに確保したクラスタに記録し、かつ、クラスタ単位で情報の接続順序を修正する。【００３７】  これにより、余分な情報の読み出しを発生させずに、ヘッダ部を更新することが可能である。【００３８】  つまり、本発明の記録装置は、消去の最小単位がブロックである記録領域に、記録終了時にヘッダ部の更新処理が必要なファイルを記録する場合に、リード・モディファイ・ライトを発生させず、かつ、論理的なファイル構成を維持したまま当該ファイルを記録することができる。【００３９】  また、前記記録手段は、前記受付手段により前記記録停止要求が受け付けられた場合、前記更新前のヘッダ部を記録したブロックとは異なるブロックに含まれる前記他のクラスタに、更新後のヘッダ部を記録するとしてもよい。【００４０】  これにより、例えば、記録動作の頻度を抑制するために１ブロック分のデータがバッファメモリに蓄積されるごとに蓄積されたデータを空きブロックに書き込むように記録装置の記録動作を制御した場合であっても、この制御内容に従った上で、リード・モディファイ・ライトを発生させずにファイルの記録を行うことができる。【００４１】  また、前記記録手段は、前記受付手段により前記記録開始要求が受け付けられた場合、クラスタサイズの整数倍のサイズである前記更新前のヘッダ部を前記記録領域内のブロックに記録するとしてもよい。【００４２】  これにより、ヘッダ部の更新の際に、クラスタ単位でデー���の読み出しを行った場合であっても、ヘッダ部以外のデータの読み出しを抑えることが可能となる。【００４３】  また、前記記録手段は、前記更新前のヘッダ部が複数のクラスタにまたがって記録されている場合、前記受付手段により前記記録停止要求が受け付けられると、前記複数のクラスタに記録されている情報の全てを、前記複数のクラスタとは異なる、前記他のクラスタを含む複数のクラスタに記録するとしてもよい。【００４４】  これにより、更新前のヘッダ部が複数のクラスタにまたがる場合でも、新たに確保された複数のクラスタに、更新後のヘッダ部の全てを記録することができる。【００４５】  また、前記記録手段は、前記更新前のヘッダ部が複数のクラスタにまたがって記録されている場合、前記受付手段により前記記録停止要求が受け付けられると、前記更新前のヘッダ部の中の更新すべき部分を記録しているクラスタのみから情報を読み出して更新し、更新した情報を前記他のクラスタに記録するとしてもよい。【００４６】  これにより、更新前のヘッダ部が複数のクラスタにまたがる場合、更新すべきデータの置かれたクラスタ部分だけを読み出して更新し、他のクラスタに記録すればよい。つまり、記録動作の効率がさらに向上する。【００４７】  また、前記修正手段は、前記記録手段により前記更新後のヘッダ部が前記他のクラスタに記録される場合、さらに、前記更新前のヘッダ部が記録されていたクラスタが未使用のクラスタであることを前記管理情報が示すように前記管理情報を修正することで、前記更新前のヘッダ部が記録されたクラスタを解放するとしてもよい。【００４８】  これにより、更新前のヘッダ部が記録された領域は、当該更新処理に伴い未使用領域とされる。そのため、記録媒体の容量を無駄に消費することがない。【００４９】  また、前記管理情報は、前記更新前のヘッダ部が記録されたクラスタを特定する情報を含むファイルエントリと、前記接続順序を示す複数のＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅｓ）エントリとを含み、前記修正手段は、前記管理情報を修正する場合、（１）前記他のクラスタに対応するＦＡＴエントリの確保、（２）前記ＦＡＴエントリの変更、（３）前記ファイルエントリの変更、（４）前記更新前のヘッダ部が記録されたクラスタの解放という順番で処理を行うとしてもよい。【００５０】  これにより、ファイルとファイルシステムの破壊を防止することが可能となる。すなわち、更新前のヘッダ部が記録されたクラスタの解放を他のどの処理よりも先に行った場合は、その解放直後に電源遮断が発生すると、ヘッダ部の情報が消えてしまう、次のデータ部への接続順序の情報がなくなるといったファイル破壊の可能性がある。【００５１】  また、ファイルエントリの変更を他のどの処理よりも先に行った場合は、ファイルエントリが、まだ確保されていないＦＡＴエントリを指すなどの異常状態になる可能性がある。【００５２】  従って、修正手段が、上記の順番で各種の処理を行うことにより、これらファイルの破壊等の発生が防止される。【００５３】  また、前記記録媒体は、不揮発性半導体メモリ媒体であるとしてもよい。【００５４】  また、前記記録手段はさらに、前記記録媒体の残量がなくなったことを検出した場合、前記更新前のヘッダ部を更新し、前記他のクラスタに前記更新後のヘッダ部を記録するとしてもよい。【００５５】  これによって、記録媒体の残量がなくなった場合も記録停止要求が受け付けられた場合と同様の効果を得ることが可能となる。【００５６】  なお、本発明は、このような記録装置として実現することができるだけでなく、このような記録装置が備える特徴的な手段により実行される動作内容をステップとする記録方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。
【発明の効果】
【００５７】  本発明に係る記録装置によれば、ブロックサイズよりも小さいファイルのヘッダ部を更新する場合でも、既に確保されているクラスタではなく新たに確保されたクラスタに更新後のヘッダ部が記録される。【００５８】  また、クラスタ単位の情報の接続順序を示す管理情報が修正されることにより、ヘッダ部にデータ部が続くという当該ファイル本来の論理的な接続順序は維持される。【００５９】  これにより、リード・モディファイ・ライトの発生が回避され、高速に記録処理を行うことが可能となる。【００６０】  また、更新前の古いヘッダ部を未使用領域とすることにより、半導体メモリの容量を無駄に消費することはない。【００６１】  さらに、映像や音声データの終端部が記録されるブロックには、新しいヘッダ部を記録するのに十分な空きがある可能性が高い。【００６２】  そのため、１ブロック分のデータがバッファメモリに蓄積されるごとに蓄積されたデータを記録媒体に記録するように動作が制御される場合、映像や音声データの終端部と同じブロックに新しいヘッダ部を記録することによって、新たにブロックを確保する必要がなくなり、半導体メモリの空き領域を効率よく使用することが可能となる。
【図面の簡単な説明】
【００６３】
【図１】図１（ａ）は、映像ファイルの構成を示す図であり、図１（ｂ）は、音声ファイルの構成を示す図である。
【図２】図２（ａ）は、特許文献１に開示されている記録方法を示す第一の図であり、図２（ｂ）は、当該記録方法を示す第二の図である。
【図３】図３は、本実施の形態における記録再生装置の概観図である。
【図４】図４は、本実施の形態の映像記録再生装置の構成を示す図である。
【図５】図５は、本実施の形態において記録される映像フレームと音声サンプル数との関係を示す図である。
【図６】図６（ａ）は、本実施の形態における表示部の一例を示す図であり、図６（ｂ）は、本実施の形態における入力部の一例を示す図である。
【図７】図７は、ＦＡＴファイルシステムにおける記録媒体の記録フォーマットを示す図である。
【図８】図８は、ＦＡＴ１６ファイルシステムのブートセクタに記述される情報を示す図である。
【図９】図９は、ファイルとファイル管理情報の関係、及びファイル記録方法を示す図である。
【図１０】図１０（ａ）は、本実施の形態における記録開始時のファイルイメージと記録メモリの状態の一例を示す図であり、図１０（ｂ）は、本実施の形態における記録終了時のファイルイメージと記録メモリの状態の一例を示す図である。
【図１１】図１１は、本実施の形態における記録手順を示すフローチャートである。
【図１２】図１２は、本実施の形態おけるファイルエントリとクラスタとのつながりの変化の一例を示す図である。
【図１３】図１３（ａ）は、ファイルとファイルシステム破壊状態の一例を示す図であり、図１３（ｂ）は、ファイルとファイルシステム破壊状態の別の一例を示す図である。
【図１４】図１４（ａ）は、本実施の形態における表示部の一例を示す図であり、図１４（ｂ）は、本実施の形態における入力部の一例を示す図である。
【図１５】図１５は、本実施の形態における修復手順を示すフローチャートである。
【図１６】図１６は、本実施の形態における音声サンプル数算出手順を示すフローチャートである。
【図１７】図１７は、ヘッダ部が複数のクラスタにまたがる場合のヘッダ部更新方法の説明図である。
【図１８】図１８は、ヘッダ部が複数のクラスタにまたがる場合のヘッダ部更新手順を示すフローチャートである。
【図１９】図１９は、ヘッダ部が複数のクラスタにまたがる場合のヘッダ部更新方法の説明図である。
【図２０】図２０は、ヘッダ部が複数のクラスタにまたがる場合のヘッダ部更新手順を示すフローチャートである。
【図２１】図２１は、ヘッダサイズがクラスタサイズの整数倍でない場合の処理の説明図である。
【図２２】図２２は、ヘッダ部とヘッダ以外のデータとが混在するクラスタの扱いを示す図である。
【図２３】図２３は、本実施の形態における記録再生装置と編集機の概観図である。
【符号の説明】
【００６４】  １００  記録再生装置  １０１  システム制御部  １０２  映像ファイル処理部  １０３  音声ファイル処理部  １０４  記録メモリ処理部  １０５  ファイルシステム  １０６  ファイルシステム用メモリ  １０７  記録バッファメモリ  １０８  再生バッファメモリ  １０９  ファイル修復処理部  １１０  記録メモリＩ／Ｆ部  １１１  記録メモリ  １２０  Ｉ／Ｏバス  １３０  入力部  １３１  映像エンコーダ  １３２  映像入力部  １３３  映像デコーダ  １３４  映像出力部  １３５  音声エンコーダ  １３６  音声入力部  １３７  音声デコーダ  １３８  音声出力部  １３９  表示部  ７０１  ユーザデータ領域に書き込まれるファイルＦｉｌｅ１  ７０２  Ｆｉｌｅ１を記録するディレクトリのディレクトリエントリ  ７０３  Ｆｉｌｅ１のファイルエントリ  ７０４  Ａ番目のクラスタに対応するＦＡＴエントリ  ７０５  Ｂ番目のクラスタに対応するＦＡＴエントリ  ７０６  Ｃ番目のクラスタに対応するＦＡＴエントリ  ７０７  Ｄ番目のクラスタに対応するＦＡＴエントリ  １１０２  十字キー  １１０３  停止ボタン  １１０４  再生ボタン  １１０５  メニューボタン
【発明を実施するための最良の形態】
【００６５】  以下、本発明の実施の形態について図面を用いて説明する。なお、図面において、実質的に同一の要素には同一の符号を付している。【００６６】  まず、本発明の概要を説明する。【００６７】  上記特許文献１に開示されている記録方法は、クラスタに記録されたデータの更新を行う場合、当該クラスタを含むブロックすべてのデータをフリーブロックに移動させるという方法を採用している。これは、フラッシュメモリの階層に特徴を備えた技術であるといえる。【００６８】  それに対して、本発明では、クラスタに記録されたヘッダ部の更新を行う場合、更新したヘッダ部だけを空きクラスタに書き込み（記録し）、辻褄があうようにファイル管理情報（後述する）を修正するようにしている。言い換えると、本発明は、ファイルシステムの階層に特徴を備えた技術である。【００６９】  以下、本発明の実施の形態について詳細に説明する。【００７０】  図３は、本発明の実施の形態における記録再生装置１００の概観図である。ここでは、記録再生装置１００として、映像信号及び音声信号を記録するデジタルビデオカメラを例示している。デジタルビデオカメラには、記録メモリ１１１が着脱可能となっている。デジタルビデオカメラは、映像信号等をファイル化して記録媒体である記録メモリ１１１に記録することができる。【００７１】  図４は、本発明の実施の形態における記録再生装置１００の構成を示す図である。この記録再生装置１００は、本発明に係る記録装置の一例である。【００７２】  記録再生装置１００は、システム制御部１０１と、Ｉ／Ｏバス１２０と、着脱可能な記録メモリ１１１と、記録メモリ１１１と接続する記録メモリＩ／Ｆ部１１０と、ユーザによるファイルの記録や再生の指示を受け付ける入力部１３０と、記録再生の様子や素材の状態を表示する表示部１３９と、映像信号を入力する映像入力部１３２と、映像信号を符号化する映像エンコーダ１３１と、映像信号を復号化する映像デコーダ１３３と、復号化された映像信号を出力する映像出力部１３４と、音声信号を入力する音声入力部１３６と、音声信号を符号化する音声エンコーダ１３５と、音声信号を復号化する音声デコーダ１３７と、復号化された音声信号を出力する音声出力部１３８とを含む。【００７３】  システム制御部１０１は、本発明に係る記録手段及び修正手段の一例であって、例えば、ＣＰＵとメモリとを含むコンピュータによって実現される。【００７４】  システム制御部１０１には、映像ファイル処理部１０２と、音声ファイル処理部１０３と、記録メモリ処理部１０４と、ファイルシステム１０５と、ファイルシステム用メモリ１０６と、記録バッファメモリ１０７と、再生バッファメモリ１０８と、ファイル修復処理部１０９とが含まれる。【００７５】  システム制御部１０１に含まれる各処理部の機能は、ＣＰＵが各種のプログラムを実行することによって実現される。また、システム制御部１０１に含まれる各メモリの実現形態は限定されるものではない。例えば、用途ごとにそれぞれメモリを用いるようにしてもよいし、単一のメモリを用途ごとに領域を分けて使うようにしてもよい。【００７６】  映像エンコーダ１３１は、映像入力部１３２から入力された映像信号に対して映像フレーム単位で圧縮処理を行い、ＳＭＰＴＥ−３７０Ｍ規格に準拠したＤＶＣＰＲＯ−ＨＤ圧縮データを出力する。【００７７】  映像ファイル処理部１０２は、１フレーム単位を基準として、圧縮されたＳＭＰＴＥ−３７０Ｍに準拠した圧縮データをＳＭＰＴＥ−３７７Ｍに準拠したＭＸＦファイルに変換する。【００７８】  映像ＭＸＦファイルの構造は、図１（ａ）に示した通りである。すなわち、圧縮映像データ（ＤＩＦ）は、ファイルヘッダの後のＫＬＶ構造のＢｏｄｙ内に格納される。ＤＶＣＰＲＯ−ＨＤでは１フレーム分のＤＩＦ符号量は４８０，０００Ｂｙｔｅであるので、Ｎフレーム記録時のＢｏｄｙの符号量は上記１フレームあたりの符号量のＮ倍となる。【００７９】  なお、ＤＩＦ構造データの中には音声８チャンネルを格納することができるが、本実施の形態ではＤＩＦデータ内の音声データは使用せず、別ファイルとして記録する。これは、放送局などの業務用途の編集作業では映像と音声を独立して編集する事が多く、業務用途のノンリニア編集機では映像と音声を別ファイルとするのが一般的なためである。【００８０】  音声入力部１３６から入力された音声データは、音声ファイル処理部１０３によってＳＭＰＴＥ−３７７Ｍに準拠したＭＸＦファイルに変換される。【００８１】  音声ＭＸＦファイルの構造は、図１（ｂ）に示した通りである。すなわち、１サンプルあたり１６ｂｉｔの音声データは、ファイルヘッダの後のＫＬＶ構造のＢｏｄｙ内に格納される。従って、Ｍサンプル記録時のＢｏｄｙの符号量はＭ×２Ｂｙｔｅとなる。【００８２】  また、ＫＬＶ構造のＫ（Ｋｅｙ）部には記録したデータの種類が格納され、Ｌ（Ｌｅｎｇｔｈ）部にはデータのサイズが格納される。【００８３】  また、音声ファイルはチャンネルごとに独立して記録される。従って、記録される音声のチャンネル数が２チャンネルの場合は、チャンネル毎に独立したＭＸＦファイルが２個記録される。【００８４】  記録メモリ１１１は、例えばＰＣＭＣＩＡの形状で着脱可能な構成となっている。この場合、記録メモリＩ／Ｆ部１１０はカードバス規格に準拠したものとする。記録メモリ１１１は、記録再生装置１００に設けられた記録媒体装着部としてのカードスロットに挿入することにより、記録メモリＩ／Ｆ部１１０と接続される。【００８５】  記録メモリ１１１は、例えばフラッシュメモリと、ＭＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）といった性質の異なる２種類の記録領域を備えている。そして、ＭＲＡＭ領域に設けられた、小サイズのデータ更新に適した第１領域と、フラッシュメモリ領域に設けられた、大サイズのデータ更新に適した第２領域とを有する。また、第１領域にＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅｓ）やディレクトリエントリ等のファイル管理情報が配置される。【００８６】  なお、記録メモリ１１１は、本発明の記録装置が情報の書き込み等を行う記録媒体の一例である。【００８７】  記録メモリ１１１は、ＦＡＴ１６等のファイルシステムでフォーマットされている。システム制御部１０１内のファイルシステム１０５は、ファイル管理情報の更新と、記録メモリ１１１へのデータ��き込み動作とにより、記録メモリ１１１へファイルを書き込む。【００８８】  なお、ファイルシステム１０５による上記処理は、例えば、記録メモリ１１１に対するファイルの読み書きを管理するソフトウェアをＣＰＵが実行することにより実現される。【００８９】  本実施の形態では、記録メモリ１１１のセクタサイズを５１２Ｂｙｔｅ、クラスタサイズを３２ＫＢ、第１領域の記録ブロックサイズを３２ＫＢ、第２領域の記録ブロックサイズを１ＭＢとする。記録メモリ１１１の空き容量は、記録メモリ処理部１０４がファイルシステム１０５を介して認識している。【００９０】  なお、上記の第２領域における“記録ブロック”は、消去の最小単位でもあるため、以下、“消去ブロック”とも表現される。【００９１】  入力部１３０は、本発明に係る受付手段の一例である。すなわち、映像と音声の記録動作は、入力部１３０からの指示に従って行われる。本発明に係る記録動作の詳細については後述することとし、ここでは概要を説明する。【００９２】  まず、記録開始の指示があった場合は、ファイルシステム１０５は、映像を記録する１個の映像ＭＸＦファイルと、音声を記録する２個の音声ＭＸＦファイルとをＯｐｅｎし、記録メモリ１１１へデータを記録していく。【００９３】  なお、映像ＭＸＦファイルと音声ＭＸＦファイルのヘッダ部にはデータを記録するが、Ｌｅｎｇｔｈ部に格納される値は記録終了しなければ決まらないので“０”にしておく。【００９４】  こうすることで、記録途中で電源遮断が発生した場合も、ファイル情報がヘッダ部に格納されているためファイル修復が可能になる。ファイル修復方法の詳細については後述する。【００９５】  続いて、入力部１３０からの指示があった時刻の映像と音声を先頭として、それぞれのファイルのデータを記録する。このように、ファイルのデータの先頭を同時刻にしておけば、映像のフレームサイズやフレーム周波数、音声のサンプリング周波数、およびファイル先頭からの経過時間などから、映像ファイルと音声ファイルの同期を取ることが可能である。【００９６】  また、記録メモリ１１１へのデータ書き込みは、記録動作の停止指示があった場合に終了し、各ファイルのヘッダ部とフッタ部を記録する処理を行ってファイルをＣｌｏｓｅする。【００９７】  この一連の記録動作の実行により映像ＭＸＦファイル１個と音声ＭＸＦファイル２個が新規に作成される。このように作成された映像ＭＸＦファイル１個と音声ＭＸＦファイル２個は１つの素材として管理される。【００９８】  図５は、本発明の実施の形態において記録される映像フレームと音声サンプル数との関係を示す図である。図５を用いて、記録時における映像ファイルと音声ファイルの同期の一例を説明する。【００９９】  フレーム周波数２９．９７ＨｚのＮＴＳＣ方式の場合、音声のサンプリング周波数を４８ｋＨｚとすると、１フレーム時間での音声サンプル数は１，６０１．６サンプルとなる。つまり、音声サンプル数は、５フレーム時間で整数となる。【０１００】  音声のＷａｖｅ形式ファイルでは、映像のフレーム周期は記述しないが、映像との同期をとる為、フレームあたりのサンプル数を、１，６００、１，６０２、１，６０２、１，６０２、１，６０２と５フレーム周期で変化させてカウントし、記録開始から終了までのサンプル数をこの５フレームを基準に算出する。【０１０１】  この５フレームの繰り返しの位相をシーケンス番号で表すことにすると、シーケンス番号は０〜４の繰り返しとなる。従って、１フレームあたりのデータサイズは音声２チャンネル分では以下のようになる。【０１０２】    １，６００×２  Ｂｙｔｅ  （シーケンス番号＝０）    １，６０２×２  Ｂｙｔｅ  （シーケンス番号＝１、２、３、４）【０１０３】  図６は、本発明の実施の形態における表示部と入力部の一例を示す図である。表示部１３９は、例えば液晶の表示装置により実現される。【０１０４】  表示部１３９には、図６（ａ）に示されるように、２個の素材があることをユーザに示し、各素材の縮小画像をアイコンとして表示する。縮小画像は、例えば素材映像の先頭フレームのみデコードして作成することができる。【０１０５】  入力部１３０は、図６（ｂ）に示されるように、十字キー１１０２と各種のキースイッチ（１１０３〜１１０５）で構成される。ユーザは、十字キー１１０２により素材を選択し、選択した素材を再生ボタン１１０４により再生することができる。さらに、停止ボタン１１０３で再生を停止することができる。【０１０６】  また、ユーザは、メニューボタン１１０５により操作メニューを表示し、選択した素材について削除や修復の指示を行うことができる。【０１０７】  次に、ＦＡＴファイルシステムについて説明する。【０１０８】  図７は、ＦＡＴファイルシステムにおける記録媒体の記録フォーマットを示す図である。【０１０９】  通常、ＩＳＯ／ＩＥＣ９２９２に規定されたＦＡＴファイルシステムでは、ファイルシステムの管理情報とユーザデータ領域は、記憶媒体の論理ボリューム上、図７に示されるように配置されている。【０１１０】  図７の最上部は論理セクタ０番を表している。論理セクタ０番には、ブートセクタが記録されている。ブートセクタには、ボリューム全体に関する情報と、ユーザデータ領域に書かれたファイルを読み出すために必要となるＦＡＴやルートディレクトリといった管理情報の所在に関する情報とが記録されている。【０１１１】  図８は、ＦＡＴ１６ファイルシステムのブートセクタに記述される情報を示す図である。【０１１２】  ＦＡＴ１６ファイルシステムは、ＩＳＯ／ＩＥＣ９２９２により定められたＦＡＴファイルシステムである。ここでは、ブートセクタに記述されるべき情報としてＩＳＯ／ＩＥＣ９２９３で定められたものを例示している。【０１１３】  ユーザデータ領域は、ひとつもしくは複数の連続したセクタをまとめたクラスタと呼ばれる単位で管理される。すべてのクラスタには先頭から順に通し番号が割り当てられている。【０１１４】  ユーザデータ領域におけるファイルの配置情報を記述するＦＡＴとブートセクタとの間には予約領域が設けられていることがある。予約領域のセクタ数はブートセクタに記述される。【０１１５】  また、ＦＡＴファイルシステムにおいてはしばしば複数のＦＡＴを記録することが許されている。ＦＡＴの数とＦＡＴひとつ当たりのセクタ数はブートセクタに記述されている。【０１１６】  ひとつあるいは複数のＦＡＴの���後のセクタ以降には、ルートディレクトリに記録されたディレクトリやファイルに関する情報が列挙される。また、ルートディレクトリエントリの直後のセクタ以降がユーザデータ領域となる。【０１１７】  ディレクトリに関する情報をディレクトリエントリ、ファイルに関する情報をファイルエントリと呼ぶ。ディレクトリエントリの中には、ディレクトリ名、ディレクトリ作成日時、およびクラスタ番号が記録されている。【０１１８】  ディレクトリエントリのクラスタ番号に対応する、第１領域内のユーザデータ領域には、そのディレクトリに所属するディレクトリエントリやファイルエントリが記録されている。【０１１９】  ファイルエントリの中には、ファイル名、ファイル作成時刻、ファイルサイズ、ファイル長、ファイルが保存されている最初のクラスタ番号が記録されている。【０１２０】  図９は、ＦＡＴファイルシステムにおけるファイルとファイル管理情報の関係、及びファイル記録方法を示す図である。【０１２１】  ＦＡＴの中には、それぞれのクラスタに対応したＦＡＴエントリが用意されている。以下、ユーザデータ領域で４クラスタ分に相当するサイズを持っているファイル７０１をユーザデータ領域へ記録する方法を説明する。【０１２２】  まず、ファイルシステム１０５は、記録先のディレクトリのディレクトリエントリ７０２にＦｉｌｅ１のファイルエントリ７０３を作成する。次に、ファイルシステムは、未割り当てを表す特殊なビット列（ＦＡＴ１６ファイルシステムの場合は“０ｘ００”）が記録されているＦＡＴエントリを、ＦＡＴに含まれる複数のＦＡＴエントリの中から４つ探し出す。【０１２３】  仮に、Ａ番目、Ｂ番目、Ｃ番目、Ｄ番目の４つのクラスタに対応するＦＡＴエントリ（７０４〜７０７）に未割り当てのビット列が記録されている場合を想定する。この場合、ファイルシステム１０５は、ファイルをユーザデータ領域のこの４つのクラスタに分割して記録する。【０１２４】  ファイルシステム１０５はさらに、ファイルエントリ７０３と４つのクラスタとの関係を記録するため、ファイルエントリ７０３の先頭クラスタ番号の欄に番号“Ａ”を記録する。それとともに、クラスタＡに対応するＦＡＴエントリ７０４には、ファイルが記録されている次のクラスタの番号、すなわち番号“Ｂ”を記録する。【０１２５】  ファイルシステム１０５は、同様に、クラスタＢに対応するＦＡＴエントリ７０５には番号“Ｃ”を記録し、クラスタＣに対応するＦＡＴエントリ７０６には番号“Ｄ”を記録する。【０１２６】  ファイルシステム１０５は、ファイルが記録された最後のクラスタ（本例ではクラスタＤ）に対応するＦＡＴエントリ７０７には、ファイル終端を表す特殊なビット列（ＦＡＴ１６ファイルシステムでは“０ｘＦＦ”）を記録する。【０１２７】  このように、ファイルシステム１０５は、一つのファイルの記録に使用された各クラスタに対応するそれぞれのＦＡＴエントリに、次のクラスタを特定するリンク情報を記録する。【０１２８】  つまり、ファイルエントリ７０３およびＦＡＴエントリ７０４〜７０７により、各クラスタに記録された情報の接続順序が示される。【０１２９】  ユーザデータ領域から当該ファイルを読み出す場��は、これらファイルエントリ７０３等のファイル管理情報に示されるクラスタの繋がりをたどることによってファイル終端まで到達することができる。【０１３０】  なお、ＦＡＴエントリひとつ当たりに１２ビット使用するファイルシステムをＦＡＴ１２ファイルシステム、１６ビット使用するファイルシステムをＦＡＴ１６ファイルシステム、３２ビット使用するファイルシステムをＦＡＴ３２ファイルシステムと呼ぶ。【０１３１】  ここで、本発明に係る記録動作の詳細、特にファイルＣｌｏｓｅ時のヘッダ部の記録動作について、図１０〜図１２を用いて説明する。【０１３２】  図１０は、本発明の実施の形態における記録開始時及び記録終了時のファイルイメージと記録メモリの状態の一例を示す図である。【０１３３】  図１１は、本発明の実施の形態における記録手順を示すフローチャートである。【０１３４】  図１２は、本発明の実施の形態おけるファイルエントリとクラスタとのつながりの変化の一例を示す図である。【０１３５】  なお、本実施の形態においてはヘッダ部のサイズを３２ＫＢ（＝１クラスタサイズ）、フッタ部のサイズを２２４Ｂｙｔｅの固定長で扱い、空きはＦｉｌｌｅｒで埋めることとする。【０１３６】  映像と音声の記録動作は、ユーザからの記録開始要求を入力部１３０が受け付けることで開始する。【０１３７】  すなわち、入力部１３０が記録開始の指示を受けると、映像ファイル処理部１０２と音声ファイル処理部１０３は、映像を記録する１個の映像ＭＸＦファイルと、音声を記録する２個の音声ＭＸＦファイルをＯｐｅｎするようファイルシステム１０５に指示する。【０１３８】  ファイルシステム１０５は、映像ファイル処理部１０２と音声ファイル処理部１０３からのＯｐｅｎ命令を受けると、それぞれのファイルのファイルエントリを作成する。【０１３９】  なお、映像ファイルおよび音声ファイルそれぞれの記録動作は実質的に同じであるので、以下、映像ファイルについてのみ説明する。【０１４０】  次に、映像ファイル処理部１０２は、Ｌｅｎｇｔｈ部に“０”が記録されたヘッダ部のデータを作成してヘッダ部の記録命令をファイルシステム１０５に発行する。【０１４１】  この段階では、ファイルシステム１０５は、ヘッダ部のデータを記録メモリ１１１へ書き込まず、一旦ファイルシステム用メモリ１０６に保存する。これは記録メモリ１１１に対して記録ブロック単位で書き込みを行うためである。【０１４２】  すなわち、ヘッダ部以降の映像データと合わせて１ＭＢのデータがファイルシステム用メモリ１０６に蓄積されて初めて記録メモリ１１１に記録する。但し、常に１ＭＢのデータを蓄積して記録するのではなく、記録停止時や映像ファイル処理部１０２から指示があった時は、１ＭＢに満たないデータを記録メモリ１１１に記録する場合もある。【０１４３】  次に、映像ファイル処理部１０２は、ヘッダ部に続いて映像データの記録命令をファイルシステム１０５に発行する。ファイルシステム１０５は、ファイルシステム用メモリ１０６に１ＭＢ分のデータがたまると、ＦＡＴ内のＦＡＴエントリを参照することで、空いている記録ブロックを探す。【０１４４】  ファイルシステム１０５は、空き記録ブロックが見つかると��その記録ブロックに対応するＦＡＴエントリすべてに、記録ブロックの先頭に当たるクラスタから末尾のクラスタまでつながるようにクラスタ番号を記録する。【０１４５】  ファイルシステム１０５は、さらに、ファイルエントリ内の、ファイルの先頭クラスタの番号の欄に、その記録ブロックの先頭のクラスタの番号を記録する。そして、ため込んだデータを確保した空き記録ブロックに記録する。この記録開始時のファイルイメージと記録メモリの状態を図１０（ａ）に示す。【０１４６】  以降は、ユーザからの記録停止要求を受けるまで、もしくは、記録メモリ１１１の残量がなくなるまで、前記と同様の処理を繰り返す。すなわち、１ＭＢ分のデータの蓄積、空き記録ブロックの確保、記録ブロックへのデータの書き込み、という処理を繰り返す。【０１４７】  ここで、記録メモリ１１１の残量がなくなるとは、新しいヘッダ部を記録するための１ブロック分を除いて、記録メモリ１１１の記録ブロックがすべて使用されている状態を意味する。【０１４８】  また、例えば、１クラスタ分のデータがファイルシステム用メモリ１０６に蓄積されるごとに、蓄積されたデータを記録メモリ１１１に記録する場合、記録メモリ１１１の残量がなくなるとは、新しいヘッダ部を記録するための１クラスタ分を除いて、記録メモリ１１１のクラスタがすべて使用されている状態を意味する。【０１４９】  なお、上述のように、記録メモリ１１１の空き容量は、記録メモリ処理部１０４がファイルシステム１０５を介して認識している。そのため、例えば記録メモリ処理部１０４により、記録メモリ１１１の残量がなくなったことが検出される。【０１５０】  映像ファイル処理部１０２は、ユーザからの記録停止要求を受けるか、もしくは、記録メモリ１１１の残量がなくなると、ファイルＣｌｏｓｅ処理を行う。【０１５１】  つまり、映像ファイル処理部１０２は、記録メモリ１１１の空き容量が所定の容量以下になったことが検出された場合、ファイルＣｌｏｓｅ処理を行う。【０１５２】  映像ファイル処理部１０２は、Ｃｌｏｓｅ処理に際し、まずフッタ部のデータをファイル末尾に付与するようファイルシステム１０５に命令する。【０１５３】  ファイルシステム１０５は、空き記録ブロックを確保してフッタ部のデータを最後の映像データの直後に配置するようにＦＡＴエントリにクラスタ番号を記録する。但し、フッタ部を記録したクラスタのＦＡＴエントリには終端ビット列を書き込む。【０１５４】  もし、ファイルシステム用メモリ１０６にたまったデータがフッタ部のデータを合わせて１ＭＢに達していたら、この時点で確保した記録ブロックに記録を行う。１ＭＢに満たない場合は、以下のヘッダ部の記録が行われるまでデータをためておく。【０１５５】  続いて、映像ファイル処理部１０２は、既に記録されているヘッダ部を読み出し、そのヘッダ部に含まれるＬｅｎｇｔｈ部を、記録されたデータ部のサイズに更新する。つまり、映像ファイル処理部１０２は、記録の終了により確定するデータ部のサイズがＬｅｎｇｔｈ部に格納された新たなヘッダ部を生成する。【０１５６】  映像ファイル処理部１０２はさらに、ファイルシステム１０５にヘッダ部の更新命令を発行する。【０１５７】  ファイルシステム１０５は、映像ファイル処理部１０２からヘッダ部の更新命令を受けると、既にヘッダ部が記録されている領域ではなく、新たに更新後のヘッダ部を記録するための空きクラスタ（「未使用のクラスタ」ともいう。）を確保して、更新後のヘッダ部、つまり新しいヘッダ部をそのクラスタに書き込む。【０１５８】  そして、新しいヘッダ部がファイルの先頭となるようにＦＡＴやファイルエントリを変更して、更新前のヘッダ部が記録されていたクラスタを未使用のクラスタに変更する処理、つまり、古いヘッダ部の領域を解放する処理を行う。【０１５９】  このファイルシステム１０５が行うヘッダ部更新方法について、図１１のフローチャートを用いて説明する。【０１６０】  まず、ファイルシステム１０５は、新しいヘッダ部を記録するための空きクラスタを確保し、そのクラスタに新しいヘッダ部の情報を書き込む（Ｓ３０１）。【０１６１】  ここで、データ部の末尾およびフッタ部が１ＭＢに満たずにため込まれていた場合、ファイルシステム１０５は、データ部の末尾等の記録のために確保されていたクラスタを含む記録ブロックと同じ記録ブロック内に空きクラスタを確保し、データ部の末尾等と共に新しいヘッダ部を記録メモリ１１１に記録する。【０１６２】  そうでない場合は、新しいヘッダ部のために新たに記録ブロックを確保し、ファイルシステム用メモリ１０６にため込むことなく新しいヘッダ部を即座に記録メモリ１１１に書き込む。【０１６３】  次に、ファイルシステム１０５は、新しいヘッダ部に対応するＦＡＴエントリに、古いヘッダ部のＦＡＴエントリに記録されている、次のクラスタ番号、つまりデータ部の最初のクラスタ番号の値を書き込む（Ｓ３０２）。こうすることで、新しいヘッダ部の次にデータ部が続くようになる。【０１６４】  続いて、ファイルシステム１０５は、新しいヘッダ部をファイル先頭にするために、ファイルエントリの先頭クラスタ番号の欄に新しいヘッダ部のクラスタ番号を書き込む（Ｓ３０３）。【０１６５】  最後に、ファイルシステム１０５は、古いヘッダ部に対応するＦＡＴエントリに未割り当てビット列を書き込んで、空きクラスタにして処理を終了する（Ｓ３０４）。【０１６６】  以上のファイルエントリやクラスタのつながりの変化の例を図１２を用いて説明する。【０１６７】  まず、図１２（ａ）に示されるように、新しいヘッダ部の記録のためにクラスタ１１を確保する。次いで、図１２（ｂ）に示されるように、クラスタ１１のＦＡＴエントリの値を古いヘッダ部のクラスタＡと同じ番号“Ｂ”にする。【０１６８】  次いで、図１２（ｃ）に示されるように、ファイルエントリの先頭クラスタ番号を新しいヘッダ部が記録されたクラスタの番号である“１１”に変更する。【０１６９】  最後に、図１２（ｄ）に示されるように、古いヘッダ部が記録されていたクラスタＡを解放する。具体的には、クラスタＡに対応するＦＡＴエントリにクラスタＡが未使用クラスタであることを示す“０ｘ００”を記録する。【０１７０】  なお、クラスタ１１は空きクラスタであり、図１２中の点線で示されるように、記録開始時とは異なる消去ブロックにおけるクラスタである。【０１７１】  すなわち、図１２では、ク��スタＡ及びクラスタＢは消去ブロック１に含まれ、クラスタＣは消去ブロック２に含まれ、クラスタ１０は消去ブロック３に含まれ、クラスタ１１は消去ブロック４に含まれている様子を示している。【０１７２】  図１２に示されるように、ディレクトリエントリを除く全ての領域は、いずれかの消去ブロックに含まれる。もちろん、各消去ブロックに含まれる内容は、図１２に示される内容に限定されるものではない。【０１７３】  例えば、図１２では、消去ブロック４にはクラスタ１１しか含まれていないが、この消去ブロック４には、その直前のデータ部やフッタ部が含まれる可能性がある。【０１７４】  ここで、従来の一般的な記録方法であれば、古いヘッダ部（クラスタＡ）を書き換える場合、クラスタＡのデータが書かれている消去ブロック１に対してリード・モディファイ・ライトを行うことになる。【０１７５】  また、図２に示す、特許文献１に開示されている記録方法であれば、クラスタＢを含む消去ブロック１全体のデータを読み出して保持し、当該データ内のクラスタＡを新しいヘッダ部の内容に更新した後に、当該データを消去ブロック４に書き込むことになる。【０１７６】  つまり、あるブロック内のデータ全体を読み出してその一部を更新し、さらに更新後のデータを記憶媒体に書き込むという、実質的にリード・モディファイ・ライトと同じ動作が発生することになる。【０１７７】  それに対して本発明では、ブロック１全体ではなく、クラスタＡからのみ読み出したヘッダ部を更新し、更新後の新たなヘッダ部を未使用のクラスタ１１に記録する。また、クラスタ１１のデータが書かれるべき消去ブロック４内の領域も未使用である。従ってリード・モディファイ・ライトは発生しない。【０１７８】  また、新たなヘッダ部が記録されたクラスタ１１に、データ部の先頭のクラスタＢが続くように、ファイル管理情報であるＦＡＴおよびディレクトリエントリを修正する。【０１７９】  これにより、当該ファイルを読み出す場合に、当該ファイルを構成する全てのデータを読み出すことができ、かつ、当該ファイルを正しく再構成することができる。【０１８０】  この処理により、Ｃｌｏｓｅ後のファイルの論理イメージは、図１０（ｂ）の記録終了時のファイルイメージになる。一方、物理的なデータの並びは、図１０（ｂ）の記録終了時の記録メモリに示されるように、図１０（ａ）の記録開始時とは違って通常はヘッダ部が一番後ろに配置されることになる。【０１８１】  なお、ＦＡＴエントリおよびファイルエントリは記録メモリ１１１の第１領域に配置されているので、内容の書き換えによるオーバヘッドは小さく、映像データの記録に影響を及ぼさない。【０１８２】  また、仮に、記録メモリ１１１の記録領域の全体がフラッシュメモリで構成されている場合を想定する。この場合、ＦＡＴエントリ等のファイル管理情報もフラッシュメモリ領域に記憶されることになる。これにより、記録再生装置１００であっても、ファイル管理情報の書き換えに伴うリード・モディファイ・ライトが発生することになる。【０１８３】  しかしながら、特許文献1記載のものも含み、従来の記録方法を実施した場合でも、ファイルの記録の終了時においてファイルサイズの更新等の���めにファイル管理情報の書き換えは発生する。【０１８４】  つまり、従来の記録方法を、全てがフラッシュメモリで構成された記録媒体に対して実施した場合、ファイル管理情報の書き換えに伴うリード・モディファイ・ライト、および、上述の、ヘッダ部の更新に伴うリード・モディファイ・ライトの両方が発生することになる。【０１８５】  従って、ヘッダ部の更新に伴うリード・モディファイ・ライトが発生しない本実施の形態の記録再生装置１００の方が、従来の記録方法よりも処理効率が高い。そのため、例えば記録速度を従来よりも高速化することが可能である。【０１８６】  ここで、上記ヘッダ部更新方法においては、ＦＡＴエントリの確保（Ｓ３０１）、ＦＡＴエントリの変更（Ｓ３０２）、ファイルエントリの変更（Ｓ３０３）、ＦＡＴエントリの解放（Ｓ３０４）という処理の順番になっている。【０１８７】  なお、ＦＡＴエントリの解放とは、当該ＦＡＴエントリに対応するクラスタを未使用のクラスタとすることであり、当該クラスタを解放することをも意味する。【０１８８】  このような順番になっているのは、ファイルとファイルシステム１０５の破壊を防止するためである。すなわち、ＦＡＴエントリの解放を他のどの処理よりも先に行った場合、エントリ解放直後に電源遮断が発生すると、ヘッダ部の情報が消えてしまう、または次のデータ部へのリンク情報がなくなるといったファイル破壊の発生の可能性がある。【０１８９】  また、ファイルエントリの変更を他のどの処理よりも先に行った場合は、ファイルエントリが、まだ確保されていないＦＡＴエントリを指すなどの異常状態になる可能性がある。【０１９０】  図１３は、ファイルとファイルシステム破壊状態の一例を示す図である。前記した通り、先にＦＡＴエントリの解放を行った場合、具体的には、図１３（ａ）に示されるように、古いヘッダ部に対応するＦＡＴエントリへの“０ｘ００”の記録を先に行った場合、ヘッダ部の情報が消えてしまう等の異常状態になる可能性がある。【０１９１】  また、先にファイルエントリの変更を行った場合、具体的には、図１３（ｂ）に示されるように、ファイルエントリへの“０ｘ１１”の記録を先に行った場合、まだ確保されていないＦＡＴエントリ１１を指すなどの異常状態になる可能性がある。【０１９２】  以上のように、本発明によれば、あるクラスタに記録されたヘッダ部の更新を行う場合、そのクラスタを含むブロック全体を読み出すのではなく、そのクラスタのみからヘッダ部を読み出して更新する。さらに、他の空きクラスタに更新後のヘッダ部を書き込む。【０１９３】  具体的には、本実施の形態においては、ファイルのヘッダ部を更新する際、既に確保されているブロックではなく新たに確保されたブロック内のクラスタに更新後のヘッダ部が記録される。【０１９４】  これにより、リード・モディファイ・ライト動作が発生しなくなり高速に記録処理を行うことが可能である。【０１９５】  また、本発明では、ファイル記録の際にヘッダ部を最初に記録しておくので、記録途中で電源遮断等が発生してもファイル修復でき、電源遮断直前まで記録していたデータを取り出すことが可能になる。【０１９６】  また、本発明では、新しいヘッダ部が��録メモリでの物理上の位置でデータ部よりも後ろに配置されたとしても、ファイルエントリ等のファイル管理情報を修正することにより、論理的には先頭に配置される。そのため、正しいファイル構成を保つことができる。【０１９７】  また、本発明では、古いヘッダ部の記録領域を解放するため、無駄に記録メモリの容量を消費することはない。【０１９８】  ここで、ファイル修復について説明する。【０１９９】  図１４は、本発明の実施の形態における表示部と入力部の一例を示す図である。ファイル修復動作は、ユーザの入力部１３０からの指示により行われる。【０２００】  図１４（ａ）に示されるように、表示部１３９には、記録された素材１および素材２が表示されている。修復が必要な異常ファイルを含む素材２には、その旨を表す「×」マークが素材２のアイコンの下に表示されている。【０２０１】  素材２のような異常ファイルを含む素材であるかどうかは、素材の各ファイルについてデータ部のサイズとヘッダ部のＬｅｎｇｔｈ情報とを比較することによって判定する。【０２０２】  ここで、データ部のサイズは、ファイルサイズからヘッダ部のサイズを引くことで求められる。データ部のサイズを求める際にフッタ部のサイズを考慮しないのは、フッタ部はファイルを正常に記録した場合にのみ付加されるからである。【０２０３】  データ部のサイズがヘッダ部のＬｅｎｇｔｈの値と一致していれば正常ファイルと判定し、一致していなければ異常ファイルと判定する。この判定の正しさは、前述した映像と音声の記録動作の説明から明らかである。【０２０４】  ユーザは、修復したい素材を十字キー１１０２により選択し、メニューボタン１１０５を押して操作メニューを表示させる。さらに、ユーザは、操作メニューから修復を選択してファイル修復動作の指示を行う。【０２０５】  図１５は、本発明の実施の形態におけるＦＡＴエントリとファイルサイズの修復手順を示すフローチャートである。以下、図１５を用いてＦＡＴエントリとファイルサイズの修復について説明する。【０２０６】  まず、ファイル修復処理部１０９は、ユーザからの修復指示を受けると、ファイルシステム１０５を用いて、修復するＭＸＦファイルのＦＡＴエントリを先頭から辿って行く。【０２０７】  図１５中に示す変数ＣＥは、ファイル修復処理部１０９が現在見ているＦＡＴエントリの番号を示しており、初めに修復するファイルの先頭のＦＡＴエントリの番号をＣＥに代入する（Ｓ１３０１）。【０２０８】  次に、ＣＥのＦＡＴエントリを見て終端ビット列が入っているか否を調べる（Ｓ１３０２）。当該ＦＡＴエントリに終端ビット列が入っている場合は、先頭から終端までのＦＡＴエントリ数×クラスタサイズから得られる値にファイルサイズを変更して（Ｓ１３０３）、処理を終了する。【０２０９】  Ｓ１３０２にて当該ＦＡＴエントリに終端ビット列が入っていない場合は、未割り当てビット列が入っているか否かを調べる（Ｓ１３０４）。当該ＦＡＴエントリに未割り当てビット列が入っている場合は、当該ＦＡＴエントリを終端ビット列に書き換えて（Ｓ１３０５）、Ｓ１３０３に移る。【０２１０】  各ＦＡＴエントリを辿って未割り当てのＦＡＴエントリに到達したということは、記録メモリ１１１にそのＦＡＴエントリを確保したことを記録する前に電源遮断等が発生し、そのＦＡＴエントリに対応するクラスタに電源遮断直前までデータが記録された可能性があることを意味する。【０２１１】  よって、この場合は、未割り当てのＦＡＴエントリに終端ビット列を書き込んで当該ファイルの一部にする処理を行う。【０２１２】  Ｓ１３０４にて未割り当てビット列ではない場合は、今まで辿って来たＦＡＴエントリ数と総クラスタ数が等しいかどうか調べる（Ｓ１３０６）。これはＦＡＴエントリの繋がりがループ状になっているか否かを調べるためである。【０２１３】  ここで総クラスタ数とは、記録メモリ１１１に確保することができるクラスタの総数のことである。この総数は、ブートセクタに記述されているクラスタ当たりのセクタ数と全セクタ数から求めることができる。【０２１４】  Ｓ１３０６にて辿ったＦＡＴエントリ数と総クラスタ数が等しい場合、ＦＡＴエントリがループ状になっているので、修復不可能である旨を通知して処理を終了する（Ｓ１３０７）。【０２１５】  Ｓ１３０６にて辿ったＦＡＴエントリ数と総クラスタ数が異なる場合、現在見ているエントリに書かれている次のＦＡＴエントリの番号を変数ＣＥに代入して、Ｓ１３０２に戻る（Ｓ１３０８）。【０２１６】  以上により、異常ファイルに関するＦＡＴエントリとファイルサイズの修復が可能である。しかし、この処理の結果、ファイルサイズがクラスタサイズの整数倍となってしまう。【０２１７】  修復したファイルの有効なデータサイズはクラスタサイズの整数倍とは限らないため、ファイルを読み出す際に末尾の無意味なデータまで取り出してしまう可能性がある。さらに、ファイルのヘッダ部のＬｅｎｇｔｈ部、およびフッタ部も正しく記録されていないので、その箇所の修復も必要である。【０２１８】  以下、ファイルサイズの修正と、ヘッダ部およびフッタ部の修復について述べる。【０２１９】  ファイル修復処理部１０９は、ＦＡＴエントリとファイルサイズの修復を終えたら、そのファイルのヘッダ部からファイル情報を読み込み、映像ファイルであるか音声ファイルであるかを判断する。【０２２０】  まず、修復するファイルが映像ファイルである場合を説明する。ファイル修復処理部１０９は、映像ファイルのヘッダ部のファイル情報にあるデータの種類やフレーム周波数により、１フレーム分のＤＩＦ符号量を得る。【０２２１】  このＤＩＦ符号量は、ＤＶＣＰＲＯ−ＨＤ  ＮＴＳＣの場合は４８０，０００Ｂｙｔｅとなり、ＤＶＣＰＲＯ−ＨＤ  ＰＡＬの場合は５７６，０００Ｂｙｔｅとなる。このＤＩＦ符号量により、修復するファイルの有効データサイズがわかる。すなわち、修正ファイルサイズは、下記数式によって算出することができる。【０２２２】    修正ファイルサイズ＝ＤＩＦ符号量×Ｉｎｔ（（ファイルサイズ−ヘッダ部サイズ）／ＤＩＦ符号量）＋ヘッダ部サイズ＋フッタ部サイズ    但し、Ｉｎｔ（）は括弧内の数値の整数部分を返す関数とする。【０２２３】  ファイル修復処理部１０９は、上記修正ファイルサイズを修復ファイルのファイルエントリに書き込み、修正ファイルサイズから得られるデータ部サイズをヘッダ部のＬｅｎｇｔｈ部に書き込み���修復ファイルにフッタ部を付加して、ファイル修復作業を終了する。【０２２４】  次に、修復するファイルが音声ファイルである場合を説明する。ファイル修復処理部１０９は、音声ファイルのヘッダ部のファイル情報にあるデータの種類・ビット数・サンプリング周波数、および映像ファイルのヘッダ部のファイル情報にあるフレーム周波数により、１フレーム時間での音声サンプル数を得る。【０２２５】  例えば、音声ファイルの形式がＷａｖｅ形式、サンプリング周波数が４８ｋＨｚ、ビット数が１６ｂｉｔであり、映像ファイルのフレーム周波数が２９．９７Ｈｚ、フォーマットがＮＴＳＣである場合、音声サンプル数は１，６０１．６サンプルとなる。【０２２６】  また、音声ファイルの形式がＷａｖｅ形式、サンプリング周波数が４８ｋＨｚ、ビット数が１６ｂｉｔであり、映像ファイルのフレーム周波数が２５Ｈｚ、フォーマットがＰＡＬである場合、音声サンプル数は１，９２０サンプルとなる。【０２２７】  前述した映像ファイルの修復と同様に、音声サンプル数より有効データサイズを求めることができる。しかし、映像ファイルフレーム周波数２９．９７Ｈｚ  ＮＴＳＣの場合は整数でないため、５フレーム（＝サンプル数８，００８）を基準にサンプル数を算出する。【０２２８】  図１６は、本発明の実施の形態における音声サンプル数算出手順を示すフローチャートである。以下、映像ファイルフレーム周波数２９．９７Ｈｚ  ＮＴＳＣの場合のサンプル数算出方法について説明する。【０２２９】  変数Ｓｆは、求めるサンプル数を示し、変数Ｓｎは、修正前のファイルサイズから算出したサンプル数を示し、変数Ｍｓは、Ｓｎを８，００８で割った余りを示す。変数Ｓｎは、以下の数式によって求めることができる。【０２３０】    Ｓｎ＝Ｉｎｔ（（ファイルサイズ−ヘッダ部サイズ）／（１６ｂｉｔ／８））【０２３１】  まず、変数Ｓｆに変数Ｓｎ−Ｍｓの値を代入する（Ｓ１４０１）。次に、変数Ｍｓと１，６００とを比較する（Ｓ１４０２）。Ｍｓが１，６００以下の場合は現在のＳｆが求めるサンプル数となるので、処理を終了する。【０２３２】  Ｓ１４０２にてＭｓ＞１，６００の場合、フレーム数がシーケンス番号０よりも大きいのでＳｆに１，６００を加える（Ｓ１４０３）。以降、同様にしてフレーム数がどのシーケンス番号まで到達しているかを調べてＳｆを修正していく（Ｓ１４０４〜Ｓ１４０９）。【０２３３】  上記サンプル数算出方法で得られたＳｆより、修正ファイルサイズは、Ｓｆ×（１６ｂｉｔ／８）＋ヘッダ部サイズ＋フッタ部サイズとなる。【０２３４】  映像ファイルのフレーム周波数が２５ＨｚでありＰＡＬの場合は、音声サンプル数は１，９２０サンプルと整数になるので、修正ファイルサイズは、Ｓｆ×（１６ｂｉｔ／８）＋ヘッダ部サイズ＋フッタ部サイズとなる。【０２３５】  以上のように、ＦＡＴエントリとファイルサイズの修復とファイルサイズの修正とヘッダ部およびフッタ部の修復処理とによりＭＸＦファイルが修復される。【０２３６】  ファイル修復処理部１０９は、修復処理を完了すると、図１４（ａ）にあるメニュー表示と素材２の下に表示されていた「×」マークとを消してユーザに修復処理が完了したことを通知する��【０２３７】  なお、本実施の形態では、映像データの圧縮方式をＤＶＣＰＲＯ−ＨＤとし、音声データの圧縮方式をＷａｖｅ形式としたが、別の圧縮方式であってもよい。【０２３８】  また、本実施の形態では、ファイル形式をＭＸＦとしたが、ファイル構成として先頭にヘッダ部を持つファイル形式なら別の形式であってもよい。【０２３９】  また、本実施の形態では、ヘッダ部のサイズを固定長としたが可変長であっても構わない。この場合、そのサイズがヘッダ部内等に格納されていて、システム制御部１０１がそのサイズを知ることができるようにしておく。【０２４０】  また、本実施の形態では、ヘッダ部のサイズが１つのクラスタに収まるサイズである場合の、ヘッダ部の更新に係る処理を説明した。しかしながら、ヘッダ部が複数のクラスタにまたがった場合であっても、本発明により、効率のよい記録処理がなされる。【０２４１】  以下、図１７〜図１９を用いて、ヘッダ部が複数のクラスタにまたがる場合におけるヘッダ部の更新に係る処理を説明する。【０２４２】  図１７は、ヘッダ部が複数のクラスタにまたがる場合におけるヘッダ部更新方法を説明するための図である。【０２４３】  図１７では消去ブロック１〜３を例示しているが、各消去ブロックに含まれる内容は限定されるものではない。【０２４４】  この図に示されるように、ヘッダ部が複数のクラスタにまたがる場合は、そのヘッダ部全てを空きクラスタに移動させてもよい。このヘッダ部更新方法について、図１８のフローチャートを用いて説明する。【０２４５】  図１８における各ステップの内容は、以下に説明するように、ステップＳ３１２を除き図１１と同じである。【０２４６】  すなわち、ファイルシステム１０５は、新しいヘッダ部を記録するための空きクラスタを確保し、そのクラスタに新しいヘッダ部の情報を書き込む（Ｓ３０１）。【０２４７】  次に、ファイルシステム１０５は、新しいヘッダ部の最後のクラスタのＦＡＴエントリに、古いヘッダ部のＦＡＴエントリに記録されている、次のクラスタ番号の値を書き込む（Ｓ３１２）。【０２４８】  次に、ファイルシステム１０５は、新しいヘッダ部をファイル先頭にするために、ファイルエントリの先頭クラスタ番号に新しいヘッダ部のクラスタ番号を書き込む（Ｓ３０３）。【０２４９】  最後に、ファイルシステム１０５は、古いヘッダ部のＦＡＴエントリに未割り当てビット列を書き込んで、空きクラスタにして処理を終了する（Ｓ３０４）。【０２５０】  図１９は、ヘッダ部が複数のクラスタにまたがる場合におけるヘッダ部更新方法の別の一例を説明するための図である。【０２５１】  図１９では消去ブロック１〜３を例示しているが、各消去ブロックに含まれる内容は限定されるものではない。【０２５２】  この図に示されるように、ヘッダ部が複数のクラスタにまたがる場合は、ヘッダ部のうち更新すべきデータの置かれたクラスタ部分（以下、「書き換えるクラスタ」という場合がある。）だけを更新して空きクラスタに移動させてもよい。【０２５３】  このヘッダ部更新方法について、図２０のフローチャートを用いて説明する。図２０における各ステップの内容は、以下に説明するように、ステップＳ３２３を除き図１１と同じ���ある。【０２５４】  すなわち、ファイルシステム１０５は、新しいヘッダ部を記録するための空きクラスタを確保し、そのクラスタに新しいヘッダ部の情報を書き込む（Ｓ３０１）。【０２５５】  次に、ファイルシステム１０５は、新しいヘッダ部のＦＡＴエントリに、古いヘッダ部のＦＡＴエントリに記録されている、次のクラスタ番号の値を書き込む（Ｓ３０２）。【０２５６】  次に、ファイルシステム１０５は、書き換えるクラスタが先頭でない場合（ここでは、先頭から２番目の場合を例示している。）は、書き換えるクラスタの１つ前のクラスタのＦＡＴエントリに、新しいヘッダ部のクラスタ番号を書き込む（Ｓ３２３）。【０２５７】  なお、これらＦＡＴエントリについての処理（Ｓ３０２およびＳ３２３）により、更新後のヘッダ部にデータ部が続くようにファイル管理情報が修正されることになる。【０２５８】  最後に、ファイルシステム１０５は、古いヘッダ部のＦＡＴエントリに未割り当てビット列を書き込んで、空きクラスタにして処理を終了する（Ｓ３０４）。【０２５９】  ここでは、書き換えるクラスタが先頭でない場合（先頭から２番目の場合）を例示しているが、書き換えるクラスタが先頭の場合におけるヘッダ部更新方法は図１１に示す通りである。【０２６０】  また、更新すべきデータ（例えばＬｅｎｇｔｈ部）が１つのクラスタに置かれている場合を例示しているが、更新すべきデータ（例えばＬｅｎｇｔｈ部）が複数のクラスタにまたがる場合は、これら複数のクラスタを空きクラスタに移動させればよい。【０２６１】  以上のように、本発明によれば、更新前のヘッダ部が複数のクラスタにまたがる場合でも、これらクラスタ以外の複数または１つのクラスタに、新たなヘッダ部を記録する。【０２６２】  具体的には、本実施の形態においては、既に確保されているブロックではなく新たに確保されたブロック内の１以上のクラスタに更新後のヘッダ部が記録される。これにより、リード・モディファイ・ライト動作が発生しなくなり高速に記録処理を行うことが可能である。【０２６３】  特に、図１９に示されるヘッダ部更新方法を採用すれば、ヘッダ部の書き換えとは無関係な余分なデータの読み出しを極力抑えることができるという効果がある。【０２６４】  なお、本実施の形態では、ヘッダサイズがクラスタサイズの整数倍であることを前提に説明したが、本発明はこれに限定されるものではない。【０２６５】  図２１は、ヘッダサイズがクラスタサイズの整数倍でない場合のヘッダ部の更新に係る処理を説明するための図である。【０２６６】  この図に示されるように、ヘッダサイズがクラスタサイズの整数倍でない場合の処理方法としては２通りの方法がある。【０２６７】  １つ目の方法は、クラスタ内の領域のうちヘッダ部が記録されていない部分（以下、「残部」という。）をデータ部で埋める方法である。２つ目の方法は、残部をパディングビット等の無意味なデータで埋める方法である。【０２６８】  ２つ目の方法を採用した場合は、次のクラスタからデータ部が記録されることになる。いずれの方法を採用しても、ヘッダ部のデータとヘッダ部以外のデータとが混在するクラスタが生じるので、そのクラスタの扱いが問題となる。【０２６���】  図２２は、ヘッダ部のデータとヘッダ部以外のデータとが混在するクラスタの扱いを示す図である。【０２７０】  このデータ混在クラスタを扱う方法としては２通りの方法がある。１つ目の方法は、ヘッダ部のデータとヘッダ部以外のデータとをＲＡＭ等のファイルシステム用メモリ１０６に一時記憶しておき、このファイルシステム用メモリ１０６からヘッダ部のデータとヘッダ部以外のデータとを読み出す方法である（図中の（ｉ）参照）。【０２７１】  ２つ目の方法は、フラッシュメモリ等の記録メモリ１１１からヘッダ部のデータとヘッダ部以外のデータとを読み出す方法である（図中の（ｉｉ）参照）。ファイルシステム用メモリ１０６または記録メモリ１１１から読み出されたヘッダ部が更新されて空きクラスタに書き込まれる点は上述した通りである。【０２７２】  図２２では消去ブロック１〜３を例示しているが、各消去ブロックに含まれる内容は限定されるものではない。【０２７３】  以上のように、本発明は、ヘッダサイズがクラスタサイズの整数倍でない場合にも適用することができる。また、このような場合はヘッダとヘッダ以外のデータとが混在するクラスタが生じることになるが、このデータ混在クラスタを上記した２通りの方法によって扱うことが可能である。【０２７４】  なお、本実施の形態では、記録再生装置１００が記録するデータは、映像及び音声を含むデータであるとしたが、映像及び音声のうちいずれか一方のみを含むようなデータであってもよい。【０２７５】  また、本実施の形態では、記録媒体として半導体メモリを例示して本発明の特徴を説明した。しかしながら、光ディスクやハードディスク等の記録媒体を採用した場合でも、本発明の記録装置および記録方法により、リード・モディファイ・ライトを行わずに情報を記録できる効果が得られることは明らかである。【０２７６】  また、本実施の形態において、更新後のヘッダ部は、更新前のヘッダ部が記録されたブロック以外のブロック内のクラスタに記録されるとした。【０２７７】  しかしながら、更新後のヘッダ部を、更新前のヘッダ部が記録されたブロックと同じブロック内のクラスタに記録してもよい。【０２７８】  例えば、記録再生装置１００が、記録ブロックサイズである１ＭＢごとにデータを記録メモリ１１１に記録するという動作を行わず、１クラスタ分のデータが蓄積されるごとに、蓄積されたデータを空きクラスタに記録する動作を行う場合を想定する。【０２７９】  この場合、仮にファイルサイズが１ＭＢより小さなファイルであれば、そのファイルの記録終了の時点では、更新前のヘッダ部が記録されているブロックには空きクラスタが存在する。【０２８０】  そこで、更新後のヘッダ部をその空きクラスタに記録し、図１１を用いて説明したように、ＦＡＴエントリ等のファイル管理情報の修正を行う。【０２８１】  これにより、リード・モディファイ・ライトを発生させることなく、論理的なファイル構成を維持したまま当該ファイルを記録メモリ１１１に記録することができる。【０２８２】  また、本実施の形態では、デジタルビデオカメラが映像信号等をファイル化して記録媒体に記録する場面を例示して説明したが、本発明の適用場面はこれに限定されるものではない。【０２８３】  すなわち、図２３に示されるように、デジタルビデオカメラ（記録再生装置１００）によって生成されたファイルを記録メモリ１１１経由でパーソナル・コンピュータ等に移動させて編集する場合がある。【０２８４】  この編集処理において何らかの理由でファイルのヘッダ部を更新する必要が生じた場合にも、前記と同様に本発明を適用することができる。つまり、パーソナル・コンピュータ等に本発明の記録方法を実行させることで、リード・モディファイ・ライトを発生させずにヘッダ部の更新が行われる。【０２８５】  また、本実施の形態において前述した各ステップを、コンピュータに実行させる記録プログラムとしてもよい。さらに、この記録プログラムをコンピュータ読み取り可能な記録媒体に記録してもよい。記録媒体としてはメモリカード等の半導体メモリ、ＣＤ−Ｒ、ＤＶＤ等の光記録媒体、ＭＯ等の光磁気記録媒体、フレキシブルディスク等の磁気記録媒体等のいずれであってもよい。【０２８６】  上記のようにコンピュータに実行させる記録プログラム及び該記録プログラムを記録した記録媒体から記録プログラムを読み出して実行することによって、コンピュータを記録装置の制御部として駆動させることができる。
【産業上の利用可能性】
【０２８７】  本発明に係る記録装置及び記録方法は、ブロックサイズよりも小さいファイルのヘッダ部を更新する場合、リード・モディファイ・ライトを行わずに更新することができる。そのため、半導体メモリ等への高速記録を実現するのに有用である。
【図１】
2008146475.tif 000003
【図２】
2008146475.tif 000004
【図３】
2008146475.tif 000005
【図４】
2008146475.tif 000006
【図５】
2008146475.tif 000007
【図６】
2008146475.tif 000008
【図７】
2008146475.tif 000009
【図８】
2008146475.tif 000010
【図９】
2008146475.tif 000011
【図１０】
2008146475.tif 000012
【図１１】
2008146475.tif 000013
【図１２】
2008146475.tif 000014
【図１３】
2008146475.tif 000015
【図１４】
2008146475.tif 000016
【図１５】
2008146475.tif 000017
【図１６】
2008146475.tif 000018
【図１７】
2008146475.tif 000019
【図１８】
2008146475.tif 000020
【図１９】
2008146475.tif 000021
【図２０】
2008146475.tif 000022
【図２１】
2008146475.tif 000023
【図２２】
2008146475.tif 000024
【図２３】
2008146475.tif 000025
【手続補正書】
【提出日】平成21年7月7日(2009.7.7)
【手続補正１】
【補正対象書類名】明細書
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、フラッシュメモリ等の記録媒体に対して映像ファイル等を記録する技術に関する。
【背景技術】
【０００２】
データが不揮発なメモリ素子を内蔵した半導体メモリカードは、パーソナル・コンピュータやデジタルスチルカメラだけでなく、デジタルビデオカメラ等の記録媒体としても普及してきている。
【０００３】
近年、テレビ放送のデジタル化やＨＤ（Ｈｉｇｈ  Ｄｅｆｉｎｉｔｉｏｎ）化に伴い、半導体メモリカードの更なる大容量化や高速化が求められている。
【０００４】
一般に、多くの半導体メモリカードでは内部にフラッシュメモリが使用されている。フラッシュメモリは消去の最小単位がブロックである記録媒体である。具体的には、フラッシュメモリは、消去ブロックと呼ばれる一定のサイズのデータが電気的に一括消去される特徴を持っている。
【０００５】
このような消去の最小単位がブロックである記録媒体に記録された、ブロックのサイズに満たないデータを更新する場合、以下の動作が発生する。
【０００６】
すなわち、一度そのデータを含むブロック全体のデータを読み出して保持しておき、そのブロックに記録されているデータを一括消去する。さらに、保持しておいたデータを部分的に更新して、更新したデータをブロックに書き戻す。
【０００７】
このような動作はリード・モディファイ・ライトと呼ばれる。リード・モディファイ・ライトは、記録動作が複雑になり、記録の転送レートが低下する原因となる。
【０００８】
一方、デジタルビデオカメラのような映像信号及び音声信号を記録する装置において、映像信号等をファイル化して記録媒体に記録することが一般的になってきている。
【０００９】
デジタルビデオカメラで採用されているデータ形式としては、例えば、ＳＭＰＴＥ３７０Ｍ規格に準拠したＤＶＣＰＲＯ−ＨＤ圧縮データがあり、ファイル形式としてはＳＭＰＴＥ−３７７Ｍに準拠したＭＸＦファイルがある。
【００１０】
ＭＸＦ（Ｍａｔｅｒｉａｌ  ｅＸｃｈａｎｇｅ  Ｆｏｒｍａｔ）とは、ＳＭＰＴＥによって規格化された素材交換用のフォーマットであり、メーカー独自のデジタル機器と他のメーカーの機器間でデータの受け渡しを可能とするものである。
【００１１】
図１は、映像ファイル及び音声ファイルの構成を示す図である。
【００１２】
図１（ａ）に映像データ形式がＤＶＣＰＲＯ−ＨＤの映像ＭＸＦファイルの構造を示す。
【００１３】
圧縮映像データ（ＤＩＦ）は、ファイルヘッダの後のＫＬＶ構造のＢｏｄｙ内に格納される。ＤＶＣＰＲＯ−ＨＤでは１フレーム分のＤＩＦ符号量は４８０，０００Ｂｙｔｅである。従って、Ｎフレーム記録時のＢｏｄｙの符号量は上記１フレームあたりの符号量のＮ倍となる。
【００１４】
図１（ｂ）に音声データ形式がＷａｖｅ形式の音声ＭＸＦファイルの構造を示す。
【００１５】
１サンプルあたり１６ｂｉｔの音声データは、ファイルヘッダの後のＫＬＶ構造のＢｏｄｙ内に格納される。従って、Ｍサンプル記録時のＢｏｄｙの符号量はＭ×２Ｂｙｔｅとなる。
【００１６】
また、ＫＬＶ構造のＫ（Ｋｅｙ）部には記録したデータの種類が格納され、Ｌ（Ｌｅｎｇｔｈ）部にはデータのサイズが格納される。
【００１７】
映像ＭＸＦファイルのＫｅｙ部には、データの種類、およびフレーム周波数が格納される。音声ＭＸＦファイルのＫｅｙ部には、データの種類、サンプリング周波数、およびビット数が格納される。
【００１８】
例えば、映像ファイルの場合は、Ｋｅｙ部に、ＤＶＣＰＲＯ−ＨＤ、ＮＴＳＣ、およびインタレースを示す情報が格納される。また、音声ファイルの場合は、Ｋｅｙ部に、Ｗａｖｅ形式、４８ｋＨｚ、および１６ｂｉｔを示す情報が格納される。
【００１９】
以降、ファイルヘッダとＫＬ部を合わせてヘッダ部と呼び、ＫＬ部以降のＢｏｄｙをデータ部と呼び、ファイルフッタをフッタ部と呼ぶ。
【００２０】
前述のように、ヘッダ部のＬｅｎｇｔｈ部にはそのファイルのデータサイズを格納する。しかし、デジタルビデオカメラのように信号ストリームを記録する場合、記録が終了するまでデータサイズが確定しない。
【００２１】
よって、Ｌｅｎｇｔｈ部への書き込みは記録終了時に行う必要がある。一方、ヘッダ部はファイル先頭に存在するものであるため、記録開始時に最初に記録されなければならない。
【００２２】
そこで、Ｌｅｎｇｔｈ部を“０”としてヘッダ部をデータ部よりも先に記録しておき、記録中に電源遮断が起こっても、途中まで記録したデータをヘッダ部の情報に基づいて復旧させるということも行われている。
【００２３】
このようにした場合、映像及び音声ファイルの記録終了時にはヘッダ部のＬｅｎｇｔｈ部の正しい値への書き換えが起こる。つまり、前述のリード・モディファイ・ライトが発生してしまう。
【００２４】
なお、ヘッダ部以外の部分については、消去ブロックの整数倍の単位で書き込みをしているので、リード・モディファイ・ライトは発生しない。
【００２５】
図２は、特許文献１に開示されている記録方法を示す図である。
【００２６】
ここでは、物理ブロックの状態および論理／物理テーブルそれぞれの一例が示されている。図２（ａ）に示されるように、物理アドレス１０のブロックにクラスタ１およびクラスタ２が存在し、それぞれのクラスタにはデータが記録されている。
【００２７】
物理アドレス１０のブロックは論理アドレス“０ｘ２４０”と関連付けられていることが論理／物理テーブルに記載されている。
【００２８】
ここで、クラスタ１についてデータの書き込み命令が出された場合を想定する。この場合、クラスタ１が存在する物理ブロック１０にはクラスタ２も存在する。そのため、図２（ｂ）に示されるように、物理アドレス１１のフリーブロックに新しいクラスタ１のデータを書き込む。
【００２９】
そして、クラスタ２のデータを物理ブロック１０から物理ブロック１１にコピーし、論理／物理テーブルの論理アドレス“０ｘ２４０”に対応する物理アドレスを“１０”から“１１”に更新する。さらに、物理ブロック１０のデータを消去してフリーブロックにする。
【先行技術文献】
【特許文献】
【００３０】
【特許文献１】特開２００６−０４８２２７号公報
【発明の概要】
【発明が解決しようとする課題】
【００３１】
特許文献１に開示されている記録方法によると、上記のように、ブロックの一部だけを書き換える場合でもそのブロックすべてのデータをフリーブロックに移動させることになる。
【００３２】
そのため、余分なデータの読み出しが発生し、実質的にリード・モディファイ・ライトと同じ動作になって、記録速度が低下してしまうという課題がある。
【００３３】
本発明は、上記課題を解決するものであって、ブロックサイズよりも小さなデータを書き換える場合でもリード・モディファイ・ライトの発生を回避することができる記録装置および記録方法を提供することを目的とする。
【課題を解決するための手段】
【００３４】
前記目的を達成するために、本発明に係る記録装置は、記録済みの情報の消去の最小単位がブロックである記録領域を有する記録媒体に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録装置であって、ファイルの記録開始要求および記録停止要求を受け付ける受付手段と、前記受付手段により前記記録開始要求が受け付けられた場合、前記ファイルのヘッダ部と前記ヘッダ部に続くデータ部とを前記記録領域内のブロックの先頭から記録し、前記受付手段により前記記録停止要求が受け付けられた場合、前記ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録する記録手段と、前記記録手段により前記更新後のヘッダ部が前記他のクラスタに記録される場合、前記更新後のヘッダ部に前記データ部が続くように、前記記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する修正手段とを備える。
【００３５】
この構成により、ブロックサイズよりも小さいファイルのヘッダ部を更新する場合、既に確保されているクラスタではなく新たに確保されたクラスタに更新後のヘッダ部が記録される。
【００３６】
ここで、データ部を移動させることなく上記処理を行った場合、記録媒体内において、ヘッダ部とデータ部とがこの順に連続するという当初の物理的な位置関係は崩れる。しかし、クラスタ単位の情報の接続順を示す管理情報が修正されることにより、ヘッダ部にデータ部が続くという当該ファイル本来の論理的な接続順序は維持される。そのため、当該ファイルを読み出す場合に、当該ファイルは正しく再構成される。
【００３７】
このように、本発明の記録装置は、ヘッダ部の更新処理において、更新後のヘッダ部を新たに確保したクラスタに記録し、かつ、クラスタ単位で情報の接続順序を修正する。
【００３８】
これにより、余分な情報の読み出しを発生させずに、ヘッダ部を更新することが可能である。
【００３９】
つまり、本発明の記録装置は、消去の最小単位がブロックである記録領域に、記録終了時にヘッダ部の更新処理が必要なファイルを記録する場合に、リード・モディファイ・ライトを発生させず、かつ、論理的なファイル構成を維持したまま当該ファイルを記録することができる。
【００４０】
また、前記記録手段は、前記受付手段により前記記録停止要求が受け付けられた場合、前記更新前のヘッダ部を記録したブロックとは異なるブロックに含まれる前記他のクラスタに、更新後のヘッダ部を記録するとしてもよい。
【００４１】
これにより、例えば、記録動作の頻度を抑制するために１ブロック分のデータがバッファメモリに蓄積されるごとに蓄積されたデータを空きブロックに書き込むように記録装置の記録動作を制御した場合であっても、この制御内容に従った上で、リード・モディファイ・ライトを発生させずにファイルの記録を行うことができる。
【００４２】
また、前記記録手段は、前記受付手段により前記記録開始要求が受け付けられた場合、クラスタサイズの整数倍のサイズである前記更新前のヘッダ部を前記記録領域内のブロックに記録するとしてもよい。
【００４３】
これにより、ヘッダ部の更新の際に、クラスタ単位でデータの読み出しを行った場合であっても、ヘッダ部以外のデータの読み出しを抑えることが可能となる。
【００４４】
また、前記記録手段は、前記更新前のヘッダ部が複数のクラスタにまたがって記録されている場合、前記受付手段により前記記録停止要求が受け付けられると、前記複数のクラスタに記録されている情報の全てを、前記複数のクラスタとは異なる、前記他のクラスタを含む複数のクラスタに記録するとしてもよい。
【００４５】
これにより、更新前のヘッダ部が複数のクラスタにまたがる場合でも、新たに確保された複数のクラスタに、更新後のヘッダ部の全てを記録することができる。
【００４６】
また、前記記録手段は、前記更新前のヘッダ部が複数のクラスタにまたがって記録されている場合、前記受付手段により前記記録停止要求が受け付けられると、前記更新前のヘッダ部の中の更新すべき部分を記録しているクラスタのみから情報を読み出して更新し、更新した情報を前記他のクラスタに記録するとしてもよい。
【００４７】
これにより、更新前のヘッダ部が複数のクラスタにまたがる場合、更新すべきデータの置かれたクラスタ部分だけを読み出して更新し、他のクラスタに記録すればよい。つまり、記録動作の効率がさらに向上する。
【００４８】
また、前記修正手段は、前記記録手段により前記更新後のヘッダ部が前記他のクラスタに記録される場合、さらに、前記更新前のヘッダ部が記録されていたクラスタが未使用のクラスタであることを前記管理情報が示すように前記管理情報を修正することで、前記更新前のヘッダ部が記録されたクラスタを解放するとしてもよい。
【００４９】
これにより、更新前のヘッダ部が記録された領域は、当該更新処理に伴い未使用領域とされる。そのため、記録媒体の容量を無駄に消費することがない。
【００５０】
また、前記管理情報は、前記更新前のヘッダ部が記録されたクラスタを特定する情報を含むファイルエントリと、前記接続順序を示す複数のＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅｓ）エントリとを含み、前記修正手段は、前記管理情報を修正する場合、（１）前記他のクラスタに対応するＦＡＴエントリの確保、（２）前記ＦＡＴエントリの変更、（３）前記ファイルエントリの変更、（４）前記更新前のヘッダ部が記録されたクラスタの解放という順番で処理を行うとしてもよい。
【００５１】
これにより、ファイルとファイルシステムの破壊を防止することが可能となる。すなわち、更新前のヘッダ部が記録されたクラスタの解放を他のどの処理よりも先に行った場合は、その解放直後に電源遮断が発生すると、ヘッダ部の情報が消えてしまう、次のデータ部への接続順序の情報がなくなるといったファイル破壊の可能性がある。
【００５２】
また、ファイルエントリの変更を他のどの処理よりも先に行った場合は、ファイルエントリが、まだ確保されていないＦＡＴエントリを指すなどの異常状態になる可能性がある。
【００５３】
従って、修正手段が、上記の順番で各種の処理を行うことにより、これらファイルの破壊等の発生が防止される。
【００５４】
また、前記記録媒体は、不揮発性半導体メモリ媒体であるとしてもよい。
【００５５】
また、前記記録手段はさらに、前記記録媒体の残量がなくなったことを検出した場合、前記更新前のヘッダ部を更新し、前記他のクラスタに前記更新後のヘッダ部を記録するとしてもよい。
【００５６】
これによって、記録媒体の残量がなくなった場合も記録停止要求が受け付けられた場合と同様の効果を得ることが可能となる。
【００５７】
なお、本発明は、このような記録装置として実現することができるだけでなく、このような記録装置が備える特徴的な手段により実行される動作内容をステップとする記録方法として実現したり、それらのステップをコンピュータに実行させるプログラムとして実現したりすることもできる。そして、そのようなプログラムは、ＣＤ−ＲＯＭ等の記録媒体やインターネット等の伝送媒体を介して配信することができるのは言うまでもない。
【発明の効果】
【００５８】
本発明に係る記録装置によれば、ブロックサイズよりも小さいファイルのヘッダ部を更新する場合でも、既に確保されているクラスタではなく新たに確保されたクラスタに更新後のヘッダ部が記録される。
【００５９】
また、クラスタ単位の情報の接続順序を示す管理情報が修正されることにより、ヘッダ部にデータ部が続くという当該ファイル本来の論理的な接続順序は維持される。
【００６０】
これにより、リード・モディファイ・ライトの発生が回避され、高速に記録処理を行うことが可能となる。
【００６１】
また、更新前の古いヘッダ部を未使用領域とすることにより、半導体メモリの容量を無駄に消費することはない。
【００６２】
さらに、映像や音声データの終端部が記録されるブロックには、新しいヘッダ部を記録するのに十分な空きがある可能性が高い。
【００６３】
そのため、１ブロック分のデータがバッファメモリに蓄積されるごとに蓄積されたデータを記録媒体に記録するように動作が制御される場合、映像や音声データの終端部と同じブロックに新しいヘッダ部を記録することによって、新たにブロックを確保する必要がなくなり、半導体メモリの空き領域を効率よく使用することが可能となる。
【図面の簡単な説明】
【００６４】
【図１】図１（ａ）は、映像ファイルの構成を示す図であり、図１（ｂ）は、音声ファイルの構成を示す図である。
【図２】図２（ａ）は、特許文献１に開示されている記録方法を示す第一の図であり、図２（ｂ）は、当該記録方法を示す第二の図である。
【図３】図３は、本実施の形態における記録再生装置の概観図である。
【図４】図４は、本実施の形態の映像記録再生装置の構成を示す図である。
【図５】図５は、本実施の形態において記録される映像フレームと音声サンプル数との関係を示す図である。
【図６】図６（ａ）は、本実施の形態における表示部の一例を示す図であり、図６（ｂ）は、本実施の形態における入力部の一例を示す図である。
【図７】図７は、ＦＡＴファイルシステムにおける記録媒体の記録フォーマットを示す図である。
【図８】図８は、ＦＡＴ１６ファイルシステムのブートセクタに記述される情報を示す図である。
【図９】図９は、ファイルとファイル管理情報の関係、及びファイル記録方法を示す図である。
【図１０】図１０（ａ）は、本実施の形態における記録開始時のファイルイメージと記録メモリの状態の一例を示す図であり、図１０（ｂ）は、本実施の形態における記録終了時のファイルイメージと記録メモリの状態の一例を示す図である。
【図１１】図１１は、本実施の形態における記録手順を示すフローチャートである。
【図１２】図１２は、本実施の形態におけるファイルエントリとクラスタとのつながりの変化の一例を示す図である。
【図１３】図１３（ａ）は、ファイルとファイルシステム破壊状態の一例を示す図であり、図１３（ｂ）は、ファイルとファイルシステム破壊状態の別の一例を示す図である。
【図１４】図１４（ａ）は、本実施の形態における表示部の一例を示す図であり、図１４（ｂ）は、本実施の形態における入力部の一例を示す図である。
【図１５】図１５は、本実施の形態における修復手順を示すフローチャートである。
【図１６】図１６は、本実施の形態における音声サンプル数算出手順を示すフローチャートである。
【図１７】図１７は、ヘッダ部が複数のクラスタにまたがる場合のヘッダ部更新方法の説明図である。
【図１８】図１８は、ヘッダ部が複数のクラスタにまたがる場合のヘッダ部更新手順を示すフローチャートである。
【図１９】図１９は、ヘッダ部が複数のクラスタにまたがる場合のヘッダ部更新方法の説明図である。
【図２０】図２０は、ヘッダ部が複数のクラスタにまたがる場合のヘッダ部更新手順を示すフローチャートである。
【図２１】図２１は、ヘッダサイズがクラスタサイズの整数倍でない場合の処理の説明図である。
【図２２】図２２は、ヘッダ部とヘッダ以外のデータとが混在するクラスタの扱いを示す図である。
【図２３】図２３は、本実施の形態における記録再生装置と編集機の概観図である。
【発明を実施するための形態】
【００６５】
以下、本発明の実施の形態について図面を用いて説明する。なお、図面において、実質的に同一の要素には同一の符号を付している。
【００６６】
まず、本発明の概要を説明する。
【００６７】
上記特許文献１に開示されている記録方法は、クラスタに記録されたデータの更新を行う場合、当該クラスタを含むブロックすべてのデータをフリーブロックに移動させるという方法を採用している。これは、フラッシュメモリの階層に特徴を備えた技術であるといえる。
【００６８】
それに対して、本発明では、クラスタに記録されたヘッダ部の更新を行う場合、更新したヘッダ部だけを空きクラスタに書き込み（記録し）、辻褄があうようにファイル管理情報（後述する）を修正するようにしている。言い換えると、本発明は、ファイルシステムの階層に特徴を備えた技術である。
【００６９】
以下、本発明の実施の形態について詳細に説明する。
【００７０】
図３は、本発明の実施の形態における記録再生装置１００の概観図である。ここでは、記録再生装置１００として、映像信号及び音声信号を記録するデジタルビデオカメラを例示している。デジタルビデオカメラには、記録メモリ１１１が着脱可能となっている。デジタルビデオカメラは、映像信号等をファイル化して記録媒体である記録メモリ１１１に記録することができる。
【００７１】
図４は、本発明の実施の形態における記録再生装置１００の構成を示す図である。この記録再生装置１００は、本発明に係る記録装置の一例である。
【００７２】
記録再生装置１００は、システム制御部１０１と、Ｉ／Ｏバス１２０と、着脱可能な記録メモリ１１１と、記録メモリ１１１と接続する記録メモリＩ／Ｆ部１１０と、ユーザによるファイルの記録や再生の指示を受け付ける入力部１３０と、記録再生の様子や素材の状態を表示する表示部１３９と、映像信号を入力する映像入力部１３２と、映像信号を符号化する映像エンコーダ１３１と、映像信号を復号化する映像デコーダ１３３と、復号化された映像信号を出力する映像出力部１３４と、音声信号を入力する音声入力部１３６と、音声信号を符号化する音声エンコーダ１３５と、音声信号を復号化する音声デコーダ１３７と、復号化された音声信号を出力する音声出力部１３８とを含む。
【００７３】
システム制御部１０１は、本発明に係る記録手段及び修正手段の一例であって、例えば、ＣＰＵとメモリとを含むコンピュータによって実現される。
【００７４】
システム制御部１０１には、映像ファイル処理部１０２と、音声ファイル処理部１０３と、記録メモリ処理部１０４と、ファイルシステム１０５と、ファイルシステム用メモリ１０６と、記録バッファメモリ１０７と、再生バッファメモリ１０８と、ファイル修復処理部１０９とが含まれる。
【００７５】
システム制御部１０１に含まれる各処理部の機能は、ＣＰＵが各種のプログラムを実行することによって実現される。また、システム制御部１０１に含まれる各メモリの実現形態は限定されるものではない。例えば、用途ごとにそれぞれメモリを用いるようにしてもよいし、単一のメモリを用途ごとに領域を分けて使うようにしてもよい。
【００７６】
映像エンコーダ１３１は、映像入力部１３２から入力された映像信号に対して映像フレーム単位で圧縮処理を行い、ＳＭＰＴＥ−３７０Ｍ規格に準拠したＤＶＣＰＲＯ−ＨＤ圧縮データを出力する。
【００７７】
映像ファイル処理部１０２は、１フレーム単位を基準として、圧縮されたＳＭＰＴＥ−３７０Ｍに準拠した圧縮データをＳＭＰＴＥ−３７７Ｍに準拠したＭＸＦファイルに変換する。
【００７８】
映像ＭＸＦファイルの構造は、図１（ａ）に示した通りである。すなわち、圧縮映像データ（ＤＩＦ）は、ファイルヘッダの後のＫＬＶ構造のＢｏｄｙ内に格納される。ＤＶＣＰＲＯ−ＨＤでは１フレーム分のＤＩＦ符号量は４８０，０００Ｂｙｔｅであるので、Ｎフレーム記録時のＢｏｄｙの符号量は上記１フレームあたりの符号量のＮ倍となる。
【００７９】
なお、ＤＩＦ構造データの中には音声８チャンネルを格納することができるが、本実施の形態ではＤＩＦデータ内の音声データは使用せず、別ファイルとして記録する。これは、放送局などの業務用途の編集作業では映像と音声を独立して編集する事が多く、業務用途のノンリニア編集機では映像と音声を別ファイルとするのが一般的なためである。
【００８０】
音声入力部１３６から入力された音声データは、音声ファイル処理部１０３によってＳＭＰＴＥ−３７７Ｍに準拠したＭＸＦファイルに変換される。
【００８１】
音声ＭＸＦファイルの構造は、図１（ｂ）に示した通りである。すなわち、１サンプルあたり１６ｂｉｔの音声データは、ファイルヘッダの後のＫＬＶ構造のＢｏｄｙ内に格納される。従って、Ｍサンプル記録時のＢｏｄｙの符号量はＭ×２Ｂｙｔｅとなる。
【００８２】
また、ＫＬＶ構造のＫ（Ｋｅｙ）部には記録したデータの種類が格納され、Ｌ（Ｌｅｎｇｔｈ）部にはデータのサイズが格納される。
【００８３】
また、音声ファイルはチャンネルごとに独立して記録される。従って、記録される音声のチャンネル数が２チャンネルの場合は、チャンネル毎に独立したＭＸＦファイルが２個記録される。
【００８４】
記録メモリ１１１は、例えばＰＣＭＣＩＡの形状で着脱可能な構成となっている。この場合、記録メモリＩ／Ｆ部１１０はカードバス規格に準拠したものとする。記録メモリ１１１は、記録再生装置１００に設けられた記録媒体装着部としてのカードスロットに挿入することにより、記録メモリＩ／Ｆ部１１０と接続される。
【００８５】
記録メモリ１１１は、例えばフラッシュメモリと、ＭＲＡＭ（Ｍａｇｎｅｔｏｒｅｓｉｓｔｉｖｅ  Ｒａｎｄｏｍ  Ａｃｃｅｓｓ  Ｍｅｍｏｒｙ）といった性質の異なる２種類の記録領域を備えている。そして、ＭＲＡＭ領域に設けられた、小サイズのデータ更新に適した第１領域と、フラッシュメモリ領域に設けられた、大サイズのデータ更新に適した第２領域とを有する。また、第１領域にＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅｓ）やディレクトリエントリ等のファイル管理情報が配置される。
【００８６】
なお、記録メモリ１１１は、本発明の記録装置が情報の書き込み等を行う記録媒体の一例である。
【００８７】
記録メモリ１１１は、ＦＡＴ１６等のファイルシステムでフォーマットされている。システム制御部１０１内のファイルシステム１０５は、ファイル管理情報の更新と、記録メモリ１１１へのデータ書き込み動作とにより、記録メモリ１１１へファイルを書き込む。
【００８８】
なお、ファイルシステム１０５による上記処理は、例えば、記録メモリ１１１に対するファイルの読み書きを管理するソフトウェアをＣＰＵが実行することにより実現される。
【００８９】
本実施の形態では、記録メモリ１１１のセクタサイズを５１２Ｂｙｔｅ、クラスタサイズを３２ＫＢ、第１領域の記録ブロックサイズを３２ＫＢ、第２領域の記録ブロックサイズを１ＭＢとする。記録メモリ１１１の空き容量は、記録メモリ処理部１０４がファイルシステム１０５を介して認識している。
【００９０】
なお、上記の第２領域における“記録ブロック”は、消去の最小単位でもあるため、以下、“消去ブロック”とも表現される。
【００９１】
入力部１３０は、本発明に係る受付手段の一例である。すなわち、映像と音声の記録動作は、入力部１３０からの指示に従って行われる。本発明に係る記録動作の詳細については後述することとし、ここでは概要を説明する。
【００９２】
まず、記録開始の指示があった場合は、ファイルシステム１０５は、映像を記録する１個の映像ＭＸＦファイルと、音声を記録する２個の音声ＭＸＦファイルとをＯｐｅｎし、記録メモリ１１１へデータを記録していく。
【００９３】
なお、映像ＭＸＦファイルと音声ＭＸＦファイルのヘッダ部にはデータを記録するが、Ｌｅｎｇｔｈ部に格納される値は記録終了しなければ決まらないので“０”にしておく。
【００９４】
こうすることで、記録途中で電源遮断が発生した場合も、ファイル情報がヘッダ部に格納されているためファイル修復が可能になる。ファイル修復方法の詳細については後述する。
【００９５】
続いて、入力部１３０からの指示があった時刻の映像と音声を先頭として、それぞれのファイルのデータを記録する。このように、ファイルのデータの先頭を同時刻にしておけば、映像のフレームサイズやフレーム周波数、音声のサンプリング周波数、およびファイル先頭からの経過時間などから、映像ファイルと音声ファイルの同期を取ることが可能である。
【００９６】
また、記録メモリ１１１へのデータ書き込みは、記録動作の停止指示があった場合に終了し、各ファイルのヘッダ部とフッタ部を記録する処理を行ってファイルをＣｌｏｓｅする。
【００９７】
この一連の記録動作の実行により映像ＭＸＦファイル１個と音声ＭＸＦファイル２個が新規に作成される。このように作成された映像ＭＸＦファイル１個と音声ＭＸＦファイル２個は１つの素材として管理される。
【００９８】
図５は、本発明の実施の形態において記録される映像フレームと音声サンプル数との関係を示す図である。図５を用いて、記録時における映像ファイルと音声ファイルの同期の一例を説明する。
【００９９】
フレーム周波数２９．９７ＨｚのＮＴＳＣ方式の場合、音声のサンプリング周波数を４８ｋＨｚとすると、１フレーム時間での音声サンプル数は１，６０１．６サンプルとなる。つまり、音声サンプル数は、５フレーム時間で整数となる。
【０１００】
音声のＷａｖｅ形式ファイルでは、映像のフレーム周期は記述しないが、映像との同期をとる為、フレームあたりのサンプル数を、１，６００、１，６０２、１，６０２、１，６０２、１，６０２と５フレーム周期で変化させてカウントし、記録開始から終了までのサンプル数をこの５フレームを基準に算出する。
【０１０１】
この５フレームの繰り返しの位相をシーケンス番号で表すことにすると、シーケンス番号は０〜４の繰り返しとなる。従って、１フレームあたりのデータサイズは音声２チャンネル分では以下のようになる。
【０１０２】
１，６００×２  Ｂｙｔｅ  （シーケンス番号＝０）
１，６０２×２  Ｂｙｔｅ  （シーケンス番号＝１、２、３、４）
【０１０３】
図６は、本発明の実施の形態における表示部と入力部の一例を示す図である。表示部１３９は、例えば液晶の表示装置により実現される。
【０１０４】
表示部１３９には、図６（ａ）に示されるように、２個の素材があることをユーザに示し、各素材の縮小画像をアイコンとして表示する。縮小画像は、例えば素材映像の先頭フレームのみデコードして作成することができる。
【０１０５】
入力部１３０は、図６（ｂ）に示されるように、十字キー１１０２と各種のキースイッチ（１１０３〜１１０５）で構成される。ユーザは、十字キー１１０２により素材を選択し、選択した素材を再生ボタン１１０４により再生することができる。さらに、停止ボタン１１０３で再生を停止することができる。
【０１０６】
また、ユーザは、メニューボタン１１０５により操作メニューを表示し、選択した素材について削除や修復の指示を行うことができる。
【０１０７】
次に、ＦＡＴファイルシステムについて説明する。
【０１０８】
図７は、ＦＡＴファイルシステムにおける記録媒体の記録フォーマットを示す図である。
【０１０９】
通常、ＩＳＯ／ＩＥＣ９２９２に規定されたＦＡＴファイルシステムでは、ファイルシステムの管理情報とユーザデータ領域は、記憶媒体の論理ボリューム上、図７に示されるように配置されている。
【０１１０】
図７の最上部は論理セクタ０番を表している。論理セクタ０番には、ブートセクタが記録されている。ブートセクタには、ボリューム全体に関する情報と、ユーザデータ領域に書かれたファイルを読み出すために必要となるＦＡＴやルートディレクトリといった管理情報の所在に関する情報とが記録されている。
【０１１１】
図８は、ＦＡＴ１６ファイルシステムのブートセクタに記述される情報を示す図である。
【０１１２】
ＦＡＴ１６ファイルシステムは、ＩＳＯ／ＩＥＣ９２９２により定められたＦＡＴファイルシステムである。ここでは、ブートセクタに記述されるべき情報としてＩＳＯ／ＩＥＣ９２９３で定められたものを例示している。
【０１１３】
ユーザデータ領域は、ひとつもしくは複数の連続したセクタをまとめたクラスタと呼ばれる単位で管理される。すべてのクラスタには先頭から順に通し番号が割り当てられている。
【０１１４】
ユーザデータ領域におけるファイルの配置情報を記述するＦＡＴとブートセクタとの間には予約領域が設けられていることがある。予約領域のセクタ数はブートセクタに記述される。
【０１１５】
また、ＦＡＴファイルシステムにおいてはしばしば複数のＦＡＴを記録することが許されている。ＦＡＴの数とＦＡＴひとつ当たりのセクタ数はブートセクタに記述されている。
【０１１６】
ひとつあるいは複数のＦＡＴの直後のセクタ以降には、ルートディレクトリに記録されたディレクトリやファイルに関する情報が列挙される。また、ルートディレクトリエントリの直後のセクタ以降がユーザデータ領域となる。
【０１１７】
ディレクトリに関する情報をディレクトリエントリ、ファイルに関する情報をファイルエントリと呼ぶ。ディレクトリエントリの中には、ディレクトリ名、ディレクトリ作成日時、およびクラスタ番号が記録されている。
【０１１８】
ディレクトリエントリのクラスタ番号に対応する、第１領域内のユーザデータ領域には、そのディレクトリに所属するディレクトリエントリやファイルエントリが記録されている。
【０１１９】
ファイルエントリの中には、ファイル名、ファイル作成時刻、ファイルサイズ、ファイル長、ファイルが保存されている最初のクラスタ番号が記録されている。
【０１２０】
図９は、ＦＡＴファイルシステムにおけるファイルとファイル管理情報の関係、及びファイル記録方法を示す図である。
【０１２１】
ＦＡＴの中には、それぞれのクラスタに対応したＦＡＴエントリが用意されている。以下、ユーザデータ領域で４クラスタ分に相当するサイズを持っているファイル７０１をユーザデータ領域へ記録する方法を説明する。
【０１２２】
まず、ファイルシステム１０５は、記録先のディレクトリのディレクトリエントリ７０２にＦｉｌｅ１のファイルエントリ７０３を作成する。次に、ファイルシステムは、未割り当てを表す特殊なビット列（ＦＡＴ１６ファイルシステムの場合は“０ｘ００”）が記録されているＦＡＴエントリを、ＦＡＴに含まれる複数のＦＡＴエントリの中から４つ探し出す。
【０１２３】
仮に、Ａ番目、Ｂ番目、Ｃ番目、Ｄ番目の４つのクラスタに対応するＦＡＴエントリ（７０４〜７０７）に未割り当てのビット列が記録されている場合を想定する。この場合、ファイルシステム１０５は、ファイルをユーザデータ領域のこの４つのクラスタに分割して記録する。
【０１２４】
ファイルシステム１０５はさらに、ファイルエントリ７０３と４つのクラスタとの関係を記録するため、ファイルエントリ７０３の先頭クラスタ番号の欄に番号“Ａ”を記録する。それとともに、クラスタＡに対応するＦＡＴエントリ７０４には、ファイルが記録されている次のクラスタの番号、すなわち番号“Ｂ”を記録する。
【０１２５】
ファイルシステム１０５は、同様に、クラスタＢに対応するＦＡＴエントリ７０５には番号“Ｃ”を記録し、クラスタＣに対応するＦＡＴエントリ７０６には番号“Ｄ”を記録する。
【０１２６】
ファイルシステム１０５は、ファイルが記録された最後のクラスタ（本例ではクラスタＤ）に対応するＦＡＴエントリ７０７には、ファイル終端を表す特殊なビット列（ＦＡＴ１６ファイルシステムでは“０ｘＦＦ”）を記録する。
【０１２７】
このように、ファイルシステム１０５は、一つのファイルの記録に使用された各クラスタに対応するそれぞれのＦＡＴエントリに、次のクラスタを特定するリンク情報を記録する。
【０１２８】
つまり、ファイルエントリ７０３およびＦＡＴエントリ７０４〜７０７により、各クラスタに記録された情報の接続順序が示される。
【０１２９】
ユーザデータ領域から当該ファイルを読み出す場合は、これらファイルエントリ７０３等のファイル管理情報に示されるクラスタの繋がりをたどることによってファイル終端まで到達することができる。
【０１３０】
なお、ＦＡＴエントリひとつ当たりに１２ビット使用するファイルシステムをＦＡＴ１２ファイルシステム、１６ビット使用するファイルシステムをＦＡＴ１６ファイルシステム、３２ビット使用するファイルシステムをＦＡＴ３２ファイルシステムと呼ぶ。
【０１３１】
ここで、本発明に係る記録動作の詳細、特にファイルＣｌｏｓｅ時のヘッダ部の記録動作について、図１０〜図１２を用いて説明する。
【０１３２】
図１０は、本発明の実施の形態における記録開始時及び記録終了時のファイルイメージと記録メモリの状態の一例を示す図である。
【０１３３】
図１１は、本発明の実施の形態における記録手順を示すフローチャートである。
【０１３４】
図１２は、本発明の実施の形態におけるファイルエントリとクラスタとのつながりの変化の一例を示す図である。
【０１３５】
なお、本実施の形態においてはヘッダ部のサイズを３２ＫＢ（＝１クラスタサイズ）、フッタ部のサイズを２２４Ｂｙｔｅの固定長で扱い、空きはＦｉｌｌｅｒで埋めることとする。
【０１３６】
映像と音声の記録動作は、ユーザからの記録開始要求を入力部１３０が受け付けることで開始する。
【０１３７】
すなわち、入力部１３０が記録開始の指示を受けると、映像ファイル処理部１０２と音声ファイル処理部１０３は、映像を記録する１個の映像ＭＸＦファイルと、音声を記録する２個の音声ＭＸＦファイルをＯｐｅｎするようファイルシステム１０５に指示する。
【０１３８】
ファイルシステム１０５は、映像ファイル処理部１０２と音声ファイル処理部１０３からのＯｐｅｎ命令を受けると、それぞれのファイルのファイルエントリを作成する。
【０１３９】
なお、映像ファイルおよび音声ファイルそれぞれの記録動作は実質的に同じであるので、以下、映像ファイルについてのみ説明する。
【０１４０】
次に、映像ファイル処理部１０２は、Ｌｅｎｇｔｈ部に“０”が記録されたヘッダ部のデータを作成してヘッダ部の記録命令をファイルシステム１０５に発行する。
【０１４１】
この段階では、ファイルシステム１０５は、ヘッダ部のデータを記録メモリ１１１へ書き込まず、一旦ファイルシステム用メモリ１０６に保存する。これは記録メモリ１１１に対して記録ブロック単位で書き込みを行うためである。
【０１４２】
すなわち、ヘッダ部以降の映像データと合わせて１ＭＢのデータがファイルシステム用メモリ１０６に蓄積されて初めて記録メモリ１１１に記録する。但し、常に１ＭＢのデータを蓄積して記録するのではなく、記録停止時や映像ファイル処理部１０２から指示があった時は、１ＭＢに満たないデータを記録メモリ１１１に記録する場合もある。
【０１４３】
次に、映像ファイル処理部１０２は、ヘッダ部に続いて映像データの記録命令をファイルシステム１０５に発行する。ファイルシステム１０５は、ファイルシステム用メモリ１０６に１ＭＢ分のデータがたまると、ＦＡＴ内のＦＡＴエントリを参照することで、空いている記録ブロックを探す。
【０１４４】
ファイルシステム１０５は、空き記録ブロックが見つかると、その記録ブロックに対応するＦＡＴエントリすべてに、記録ブロックの先頭に当たるクラスタから末尾のクラスタまでつながるようにクラスタ番号を記録する。
【０１４５】
ファイルシステム１０５は、さらに、ファイルエントリ内の、ファイルの先頭クラスタの番号の欄に、その記録ブロックの先頭のクラスタの番号を記録する。そして、ため込んだデータを確保した空き記録ブロックに記録する。この記録開始時のファイルイメージと記録メモリの状態を図１０（ａ）に示す。
【０１４６】
以降は、ユーザからの記録停止要求を受けるまで、もしくは、記録メモリ１１１の残量がなくなるまで、前記と同様の処理を繰り返す。すなわち、１ＭＢ分のデータの蓄積、空き記録ブロックの確保、記録ブロックへのデータの書き込み、という処理を繰り返す。
【０１４７】
ここで、記録メモリ１１１の残量がなくなるとは、新しいヘッダ部を記録するための１ブロック分を除いて、記録メモリ１１１の記録ブロックがすべて使用されている状態を意味する。
【０１４８】
また、例えば、１クラスタ分のデータがファイルシステム用メモリ１０６に蓄積されるごとに、蓄積されたデータを記録メモリ１１１に記録する場合、記録メモリ１１１の残量がなくなるとは、新しいヘッダ部を記録するための１クラスタ分を除いて、記録メモリ１１１のクラスタがすべて使用されている状態を意味する。
【０１４９】
なお、上述のように、記録メモリ１１１の空き容量は、記録メモリ処理部１０４がファイルシステム１０５を介して認識している。そのため、例えば記録メモリ処理部１０４により、記録メモリ１１１の残量がなくなったことが検出される。
【０１５０】
映像ファイル処理部１０２は、ユーザからの記録停止要求を受けるか、もしくは、記録メモリ１１１の残量がなくなると、ファイルＣｌｏｓｅ処理を行う。
【０１５１】
つまり、映像ファイル処理部１０２は、記録メモリ１１１の空き容量が所定の容量以下になったことが検出された場合、ファイルＣｌｏｓｅ処理を行う。
【０１５２】
映像ファイル処理部１０２は、Ｃｌｏｓｅ処理に際し、まずフッタ部のデータをファイル末尾に付与するようファイルシステム１０５に命令する。
【０１５３】
ファイルシステム１０５は、空き記録ブロックを確保してフッタ部のデータを最後の映像データの直後に配置するようにＦＡＴエントリにクラスタ番号を記録する。但し、フッタ部を記録したクラスタのＦＡＴエントリには終端ビット列を書き込む。
【０１５４】
もし、ファイルシステム用メモリ１０６にたまったデータがフッタ部のデータを合わせて１ＭＢに達していたら、この時点で確保した記録ブロックに記録を行う。１ＭＢに満たない場合は、以下のヘッダ部の記録が行われるまでデータをためておく。
【０１５５】
続いて、映像ファイル処理部１０２は、既に記録されているヘッダ部を読み出し、そのヘッダ部に含まれるＬｅｎｇｔｈ部を、記録されたデータ部のサイズに更新する。つまり、映像ファイル処理部１０２は、記録の終了により確定するデータ部のサイズがＬｅｎｇｔｈ部に格納された新たなヘッダ部を生成する。
【０１５６】
映像ファイル処理部１０２はさらに、ファイルシステム１０５にヘッダ部の更新命令を発行する。
【０１５７】
ファイルシステム１０５は、映像ファイル処理部１０２からヘッダ部の更新命令を受けると、既にヘッダ部が記録されている領域ではなく、新たに更新後のヘッダ部を記録するための空きクラスタ（「未使用のクラスタ」ともいう。）を確保して、更新後のヘッダ部、つまり新しいヘッダ部をそのクラスタに書き込む。
【０１５８】
そして、新しいヘッダ部がファイルの先頭となるようにＦＡＴやファイルエントリを変更して、更新前のヘッダ部が記録されていたクラスタを未使用のクラスタに変更する処理、つまり、古いヘッダ部の領域を解放する処理を行う。
【０１５９】
このファイルシステム１０５が行うヘッダ部更新方法について、図１１のフローチャートを用いて説明する。
【０１６０】
まず、ファイルシステム１０５は、新しいヘッダ部を記録するための空きクラスタを確保し、そのクラスタに新しいヘッダ部の情報を書き込む（Ｓ３０１）。
【０１６１】
ここで、データ部の末尾およびフッタ部が１ＭＢに満たずにため込まれていた場合、ファイルシステム１０５は、データ部の末尾等の記録のために確保されていたクラスタを含む記録ブロックと同じ記録ブロック内に空きクラスタを確保し、データ部の末尾等と共に新しいヘッダ部を記録メモリ１１１に記録する。
【０１６２】
そうでない場合は、新しいヘッダ部のために新たに記録ブロックを確保し、ファイルシステム用メモリ１０６にため込むことなく新しいヘッダ部を即座に記録メモリ１１１に書き込む。
【０１６３】
次に、ファイルシステム１０５は、新しいヘッダ部に対応するＦＡＴエントリに、古いヘッダ部のＦＡＴエントリに記録されている、次のクラスタ番号、つまりデータ部の最初のクラスタ番号の値を書き込む（Ｓ３０２）。こうすることで、新しいヘッダ部の次にデータ部が続くようになる。
【０１６４】
続いて、ファイルシステム１０５は、新しいヘッダ部をファイル先頭にするために、ファイルエントリの先頭クラスタ番号の欄に新しいヘッダ部のクラスタ番号を書き込む（Ｓ３０３）。
【０１６５】
最後に、ファイルシステム１０５は、古いヘッダ部に対応するＦＡＴエントリに未割り当てビット列を書き込んで、空きクラスタにして処理を終了する（Ｓ３０４）。
【０１６６】
以上のファイルエントリやクラスタのつながりの変化の例を図１２を用いて説明する。
【０１６７】
まず、図１２（ａ）に示されるように、新しいヘッダ部の記録のためにクラスタ１１を確保する。次いで、図１２（ｂ）に示されるように、クラスタ１１のＦＡＴエントリの値を古いヘッダ部のクラスタＡと同じ番号“Ｂ”にする。
【０１６８】
次いで、図１２（ｃ）に示されるように、ファイルエントリの先頭クラスタ番号を新しいヘッダ部が記録されたクラスタの番号である“１１”に変更する。
【０１６９】
最後に、図１２（ｄ）に示されるように、古いヘッダ部が記録されていたクラスタＡを解放する。具体的には、クラスタＡに対応するＦＡＴエントリにクラスタＡが未使用クラスタであることを示す“０ｘ００”を記録する。
【０１７０】
なお、クラスタ１１は空きクラスタであり、図１２中の点線で示されるように、記録開始時とは異なる消去ブロックにおけるクラスタである。
【０１７１】
すなわち、図１２では、クラスタＡ及びクラスタＢは消去ブロック１に含まれ、クラスタＣは消去ブロック２に含まれ、クラスタ１０は消去ブロック３に含まれ、クラスタ１１は消去ブロック４に含まれている様子を示している。
【０１７２】
図１２に示されるように、ディレクトリエントリを除く全ての領域は、いずれかの消去ブロックに含まれる。もちろん、各消去ブロックに含まれる内容は、図１２に示される内容に限定されるものではない。
【０１７３】
例えば、図１２では、消去ブロック４にはクラスタ１１しか含まれていないが、この消去ブロック４には、その直前のデータ部やフッタ部が含まれる可能性がある。
【０１７４】
ここで、従来の一般的な記録方法であれば、古いヘッダ部（クラスタＡ）を書き換える場合、クラスタＡのデータが書かれている消去ブロック１に対してリード・モディファイ・ライトを行うことになる。
【０１７５】
また、図２に示す、特許文献１に開示されている記録方法であれば、クラスタＢを含む消去ブロック１全体のデータを読み出して保持し、当該データ内のクラスタＡを新しいヘッダ部の内容に更新した後に、当該データを消去ブロック４に書き込むことになる。
【０１７６】
つまり、あるブロック内のデータ全体を読み出してその一部を更新し、さらに更新後のデータを記憶媒体に書き込むという、実質的にリード・モディファイ・ライトと同じ動作が発生することになる。
【０１７７】
それに対して本発明では、ブロック１全体ではなく、クラスタＡからのみ読み出したヘッダ部を更新し、更新後の新たなヘッダ部を未使用のクラスタ１１に記録する。また、クラスタ１１のデータが書かれるべき消去ブロック４内の領域も未使用である。従ってリード・モディファイ・ライトは発生しない。
【０１７８】
また、新たなヘッダ部が記録されたクラスタ１１に、データ部の先頭のクラスタＢが続くように、ファイル管理情報であるＦＡＴおよびディレクトリエントリを修正する。
【０１７９】
これにより、当該ファイルを読み出す場合に、当該ファイルを構成する全てのデータを読み出すことができ、かつ、当該ファイルを正しく再構成することができる。
【０１８０】
この処理により、Ｃｌｏｓｅ後のファイルの論理イメージは、図１０（ｂ）の記録終了時のファイルイメージになる。一方、物理的なデータの並びは、図１０（ｂ）の記録終了時の記録メモリに示されるように、図１０（ａ）の記録開始時とは違って通常はヘッダ部が一番後ろに配置されることになる。
【０１８１】
なお、ＦＡＴエントリおよびファイルエントリは記録メモリ１１１の第１領域に配置されているので、内容の書き換えによるオーバヘッドは小さく、映像データの記録に影響を及ぼさない。
【０１８２】
また、仮に、記録メモリ１１１の記録領域の全体がフラッシュメモリで構成されている場合を想定する。この場合、ＦＡＴエントリ等のファイル管理情報もフラッシュメモリ領域に記憶されることになる。これにより、記録再生装置１００であっても、ファイル管理情報の書き換えに伴うリード・モディファイ・ライトが発生することになる。
【０１８３】
しかしながら、特許文献１記載のものも含み、従来の記録方法を実施した場合でも、ファイルの記録の終了時においてファイルサイズの更新等のためにファイル管理情報の書き換えは発生する。
【０１８４】
つまり、従来の記録方法を、全てがフラッシュメモリで構成された記録媒体に対して実施した場合、ファイル管理情報の書き換えに伴うリード・モディファイ・ライト、および、上述の、ヘッダ部の更新に伴うリード・モディファイ・ライトの両方が発生することになる。
【０１８５】
従って、ヘッダ部の更新に伴うリード・モディファイ・ライトが発生しない本実施の形態の記録再生装置１００の方が、従来の記録方法よりも処理効率が高い。そのため、例えば記録速度を従来よりも高速化することが可能である。
【０１８６】
ここで、上記ヘッダ部更新方法においては、ＦＡＴエントリの確保（Ｓ３０１）、ＦＡＴエントリの変更（Ｓ３０２）、ファイルエントリの変更（Ｓ３０３）、ＦＡＴエントリの解放（Ｓ３０４）という処理の順番になっている。
【０１８７】
なお、ＦＡＴエントリの解放とは、当該ＦＡＴエントリに対応するクラスタを未使用のクラスタとすることであり、当該クラスタを解放することをも意味する。
【０１８８】
このような順番になっているのは、ファイルとファイルシステム１０５の破壊を防止するためである。すなわち、ＦＡＴエントリの解放を他のどの処理よりも先に行った場合、エントリ解放直後に電源遮断が発生すると、ヘッダ部の情報が消えてしまう、または次のデータ部へのリンク情報がなくなるといったファイル破壊の発生の可能性がある。
【０１８９】
また、ファイルエントリの変更を他のどの処理よりも先に行った場合は、ファイルエントリが、まだ確保されていないＦＡＴエントリを指すなどの異常状態になる可能性がある。
【０１９０】
図１３は、ファイルとファイルシステム破壊状態の一例を示す図である。前記した通り、先にＦＡＴエントリの解放を行った場合、具体的には、図１３（ａ）に示されるように、古いヘッダ部に対応するＦＡＴエントリへの“０ｘ００”の記録を先に行った場合、ヘッダ部の情報が消えてしまう等の異常状態になる可能性がある。
【０１９１】
また、先にファイルエントリの変更を行った場合、具体的には、図１３（ｂ）に示されるように、ファイルエントリへの“０ｘ１１”の記録を先に行った場合、まだ確保されていないＦＡＴエントリ１１を指すなどの異常状態になる可能性がある。
【０１９２】
以上のように、本発明によれば、あるクラスタに記録されたヘッダ部の更新を行う場合、そのクラスタを含むブロック全体を読み出すのではなく、そのクラスタのみからヘッダ部を読み出して更新する。さらに、他の空きクラスタに更新後のヘッダ部を書き込む。
【０１９３】
具体的には、本実施の形態においては、ファイルのヘッダ部を更新する際、既に確保されているブロックではなく新たに確保されたブロック内のクラスタに更新後のヘッダ部が記録される。
【０１９４】
これにより、リード・モディファイ・ライト動作が発生しなくなり高速に記録処理を行うことが可能である。
【０１９５】
また、本発明では、ファイル記録の際にヘッダ部を最初に記録しておくので、記録途中で電源遮断等が発生してもファイル修復でき、電源遮断直前まで記録していたデータを取り出すことが可能になる。
【０１９６】
また、本発明では、新しいヘッダ部が記録メモリでの物理上の位置でデータ部よりも後ろに配置されたとしても、ファイルエントリ等のファイル管理情報を修正することにより、論理的には先頭に配置される。そのため、正しいファイル構成を保つことができる。
【０１９７】
また、本発明では、古いヘッダ部の記録領域を解放するため、無駄に記録メモリの容量を消費することはない。
【０１９８】
ここで、ファイル修復について説明する。
【０１９９】
図１４は、本発明の実施の形態における表示部と入力部の一例を示す図である。ファイル修復動作は、ユーザの入力部１３０からの指示により行われる。
【０２００】
図１４（ａ）に示されるように、表示部１３９には、記録された素材１および素材２が表示されている。修復が必要な異常ファイルを含む素材２には、その旨を表す「×」マークが素材２のアイコンの下に表示されている。
【０２０１】
素材２のような異常ファイルを含む素材であるかどうかは、素材の各ファイルについてデータ部のサイズとヘッダ部のＬｅｎｇｔｈ情報とを比較することによって判定する。
【０２０２】
ここで、データ部のサイズは、ファイルサイズからヘッダ部のサイズを引くことで求められる。データ部のサイズを求める際にフッタ部のサイズを考慮しないのは、フッタ部はファイルを正常に記録した場合にのみ付加されるからである。
【０２０３】
データ部のサイズがヘッダ部のＬｅｎｇｔｈの値と一致していれば正常ファイルと判定し、一致していなければ異常ファイルと判定する。この判定の正しさは、前述した映像と音声の記録動作の説明から明らかである。
【０２０４】
ユーザは、修復したい素材を十字キー１１０２により選択し、メニューボタン１１０５を押して操作メニューを表示させる。さらに、ユーザは、操作メニューから修復を選択してファイル修復動作の指示を行う。
【０２０５】
図１５は、本発明の実施の形態におけるＦＡＴエントリとファイルサイズの修復手順を示すフローチャートである。以下、図１５を用いてＦＡＴエントリとファイルサイズの修復について説明する。
【０２０６】
まず、ファイル修復処理部１０９は、ユーザからの修復指示を受けると、ファイルシステム１０５を用いて、修復するＭＸＦファイルのＦＡＴエントリを先頭から辿って行く。
【０２０７】
図１５中に示す変数ＣＥは、ファイル修復処理部１０９が現在見ているＦＡＴエントリの番号を示しており、初めに修復するファイルの先頭のＦＡＴエントリの番号をＣＥに代入する（Ｓ１３０１）。
【０２０８】
次に、ＣＥのＦＡＴエントリを見て終端ビット列が入っているか否を調べる（Ｓ１３０２）。当該ＦＡＴエントリに終端ビット列が入っている場合は、先頭から終端までのＦＡＴエントリ数×クラスタサイズから得られる値にファイルサイズを変更して（Ｓ１３０３）、処理を終了する。
【０２０９】
Ｓ１３０２にて当該ＦＡＴエントリに終端ビット列が入っていない場合は、未割り当てビット列が入っているか否かを調べる（Ｓ１３０４）。当該ＦＡＴエントリに未割り当てビット列が入っている場合は、当該ＦＡＴエントリを終端ビット列に書き換えて（Ｓ１３０５）、Ｓ１３０３に移る。
【０２１０】
各ＦＡＴエントリを辿って未割り当てのＦＡＴエントリに到達したということは、記録メモリ１１１にそのＦＡＴエントリを確保したことを記録する前に電源遮断等が発生し、そのＦＡＴエントリに対応するクラスタに電源遮断直前までデータが記録された可能性があることを意味する。
【０２１１】
よって、この場合は、未割り当てのＦＡＴエントリに終端ビット列を書き込んで当該ファイルの一部にする処理を行う。
【０２１２】
Ｓ１３０４にて未割り当てビット列ではない場合は、今まで辿って来たＦＡＴエントリ数と総クラスタ数が等しいかどうか調べる（Ｓ１３０６）。これはＦＡＴエントリの繋がりがループ状になっているか否かを調べるためである。
【０２１３】
ここで総クラスタ数とは、記録メモリ１１１に確保することができるクラスタの総数のことである。この総数は、ブートセクタに記述されているクラスタ当たりのセクタ数と全セクタ数から求めることができる。
【０２１４】
Ｓ１３０６にて辿ったＦＡＴエントリ数と総クラスタ数が等しい場合、ＦＡＴエントリがループ状になっているので、修復不可能である旨を通知して処理を終了する（Ｓ１３０７）。
【０２１５】
Ｓ１３０６にて辿ったＦＡＴエントリ数と総クラスタ数が異なる場合、現在見ているエントリに書かれている次のＦＡＴエントリの番号を変数ＣＥに代入して、Ｓ１３０２に戻る（Ｓ１３０８）。
【０２１６】
以上により、異常ファイルに関するＦＡＴエントリとファイルサイズの修復が可能である。しかし、この処理の結果、ファイルサイズがクラスタサイズの整数倍となってしまう。
【０２１７】
修復したファイルの有効なデータサイズはクラスタサイズの整数倍とは限らないため、ファイルを読み出す際に末尾の無意味なデータまで取り出してしまう可能性がある。さらに、ファイルのヘッダ部のＬｅｎｇｔｈ部、およびフッタ部も正しく記録されていないので、その箇所の修復も必要である。
【０２１８】
以下、ファイルサイズの修正と、ヘッダ部およびフッタ部の修復について述べる。
【０２１９】
ファイル修復処理部１０９は、ＦＡＴエントリとファイルサイズの修復を終えたら、そのファイルのヘッダ部からファイル情報を読み込み、映像ファイルであるか音声ファイルであるかを判断する。
【０２２０】
まず、修復するファイルが映像ファイルである場合を説明する。ファイル修復処理部１０９は、映像ファイルのヘッダ部のファイル情報にあるデータの種類やフレーム周波数により、１フレーム分のＤＩＦ符号量を得る。
【０２２１】
このＤＩＦ符号量は、ＤＶＣＰＲＯ−ＨＤ  ＮＴＳＣの場合は４８０，０００Ｂｙｔｅとなり、ＤＶＣＰＲＯ−ＨＤ  ＰＡＬの場合は５７６，０００Ｂｙｔｅとなる。このＤＩＦ符号量により、修復するファイルの有効データサイズがわかる。すなわち、修正ファイルサイズは、下記数式によって算出することができる。
【０２２２】
修正ファイルサイズ＝ＤＩＦ符号量×Ｉｎｔ（（ファイルサイズ−ヘッダ部サイズ）／ＤＩＦ符号量）＋ヘッダ部サイズ＋フッタ部サイズ
但し、Ｉｎｔ（）は括弧内の数値の整数部分を返す関数とする。
【０２２３】
ファイル修復処理部１０９は、上記修正ファイルサイズを修復ファイルのファイルエントリに書き込み、修正ファイルサイズから得られるデータ部サイズをヘッダ部のＬｅｎｇｔｈ部に書き込み、修復ファイルにフッタ部を付加して、ファイル修復作業を終了する。
【０２２４】
次に、修復するファイルが音声ファイルである場合を説明する。ファイル修復処理部１０９は、音声ファイルのヘッダ部のファイル情報にあるデータの種類・ビット数・サンプリング周波数、および映像ファイルのヘッダ部のファイル情報にあるフレーム周波数により、１フレーム時間での音声サンプル数を得る。
【０２２５】
例えば、音声ファイルの形式がＷａｖｅ形式、サンプリング周波数が４８ｋＨｚ、ビット数が１６ｂｉｔであり、映像ファイルのフレーム周波数が２９．９７Ｈｚ、フォーマットがＮＴＳＣである場合、音声サンプル数は１，６０１．６サンプルとなる。
【０２２６】
また、音声ファイルの形式がＷａｖｅ形式、サンプリング周波数が４８ｋＨｚ、ビット数が１６ｂｉｔであり、映像ファイルのフレーム周波数が２５Ｈｚ、フォーマットがＰＡＬである場合、音声サンプル数は１，９２０サンプルとなる。
【０２２７】
前述した映像ファイルの修復と同様に、音声サンプル数より有効データサイズを求めることができる。しかし、映像ファイルフレーム周波数２９．９７Ｈｚ  ＮＴＳＣの場合は整数でないため、５フレーム（＝サンプル数８，００８）を基準にサンプル数を算出する。
【０２２８】
図１６は、本発明の実施の形態における音声サンプル数算出手順を示すフローチャートである。以下、映像ファイルフレーム周波数２９．９７Ｈｚ  ＮＴＳＣの場合のサンプル数算出方法について説明する。
【０２２９】
変数Ｓｆは、求めるサンプル数を示し、変数Ｓｎは、修正前のファイルサイズから算出したサンプル数を示し、変数Ｍｓは、Ｓｎを８，００８で割った余りを示す。変数Ｓｎは、以下の数式によって求めることができる。
【０２３０】
Ｓｎ＝Ｉｎｔ（（ファイルサイズ−ヘッダ部サイズ）／（１６ｂｉｔ／８））
【０２３１】
まず、変数Ｓｆに変数Ｓｎ−Ｍｓの値を代入する（Ｓ１４０１）。次に、変数Ｍｓと１，６００とを比較する（Ｓ１４０２）。Ｍｓが１，６００以下の場合は現在のＳｆが求めるサンプル数となるので、処理を終了する。
【０２３２】
Ｓ１４０２にてＭｓ＞１，６００の場合、フレーム数がシーケンス番号０よりも大きいのでＳｆに１，６００を加える（Ｓ１４０３）。以降、同様にしてフレーム数がどのシーケンス番号まで到達しているかを調べてＳｆを修正していく（Ｓ１４０４〜Ｓ１４０９）。
【０２３３】
上記サンプル数算出方法で得られたＳｆより、修正ファイルサイズは、Ｓｆ×（１６ｂｉｔ／８）＋ヘッダ部サイズ＋フッタ部サイズとなる。
【０２３４】
映像ファイルのフレーム周波数が２５ＨｚでありＰＡＬの場合は、音声サンプル数は１，９２０サンプルと整数になるので、修正ファイルサイズは、Ｓｆ×（１６ｂｉｔ／８）＋ヘッダ部サイズ＋フッタ部サイズとなる。
【０２３５】
以上のように、ＦＡＴエントリとファイルサイズの修復とファイルサイズの修正とヘッダ部およびフッタ部の修復処理とによりＭＸＦファイルが修復される。
【０２３６】
ファイル修復処理部１０９は、修復処理を完了すると、図１４（ａ）にあるメニュー表示と素材２の下に表示されていた「×」マークとを消してユーザに修復処理が完了したことを通知する。
【０２３７】
なお、本実施の形態では、映像データの圧縮方式をＤＶＣＰＲＯ−ＨＤとし、音声データの圧縮方式をＷａｖｅ形式としたが、別の圧縮方式であってもよい。
【０２３８】
また、本実施の形態では、ファイル形式をＭＸＦとしたが、ファイル構成として先頭にヘッダ部を持つファイル形式なら別の形式であってもよい。
【０２３９】
また、本実施の形態では、ヘッダ部のサイズを固定長としたが可変長であっても構わない。この場合、そのサイズがヘッダ部内等に格納されていて、システム制御部１０１がそのサイズを知ることができるようにしておく。
【０２４０】
また、本実施の形態では、ヘッダ部のサイズが１つのクラスタに収まるサイズである場合の、ヘッダ部の更新に係る処理を説明した。しかしながら、ヘッダ部が複数のクラスタにまたがった場合であっても、本発明により、効率のよい記録処理がなされる。
【０２４１】
以下、図１７〜図１９を用いて、ヘッダ部が複数のクラスタにまたがる場合におけるヘッダ部の更新に係る処理を説明する。
【０２４２】
図１７は、ヘッダ部が複数のクラスタにまたがる場合におけるヘッダ部更新方法を説明するための図である。
【０２４３】
図１７では消去ブロック１〜３を例示しているが、各消去ブロックに含まれる内容は限定されるものではない。
【０２４４】
この図に示されるように、ヘッダ部が複数のクラスタにまたがる場合は、そのヘッダ部全てを空きクラスタに移動させてもよい。このヘッダ部更新方法について、図１８のフローチャートを用いて説明する。
【０２４５】
図１８における各ステップの内容は、以下に説明するように、ステップＳ３１２を除き図１１と同じである。
【０２４６】
すなわち、ファイルシステム１０５は、新しいヘッダ部を記録するための空きクラスタを確保し、そのクラスタに新しいヘッダ部の情報を書き込む（Ｓ３０１）。
【０２４７】
次に、ファイルシステム１０５は、新しいヘッダ部の最後のクラスタのＦＡＴエントリに、古いヘッダ部のＦＡＴエントリに記録されている、次のクラスタ番号の値を書き込む（Ｓ３１２）。
【０２４８】
次に、ファイルシステム１０５は、新しいヘッダ部をファイル先頭にするために、ファイルエントリの先頭クラスタ番号に新しいヘッダ部のクラスタ番号を書き込む（Ｓ３０３）。
【０２４９】
最後に、ファイルシステム１０５は、古いヘッダ部のＦＡＴエントリに未割り当てビット列を書き込んで、空きクラスタにして処理を終了する（Ｓ３０４）。
【０２５０】
図１９は、ヘッダ部が複数のクラスタにまたがる場合におけるヘッダ部更新方法の別の一例を説明するための図である。
【０２５１】
図１９では消去ブロック１〜３を例示しているが、各消去ブロックに含まれる内容は限定されるものではない。
【０２５２】
この図に示されるように、ヘッダ部が複数のクラスタにまたがる場合は、ヘッダ部のうち更新すべきデータの置かれたクラスタ部分（以下、「書き換えるクラスタ」という場合がある。）だけを更新して空きクラスタに移動させてもよい。
【０２５３】
このヘッダ部更新方法について、図２０のフローチャートを用いて説明する。図２０における各ステップの内容は、以下に説明するように、ステップＳ３２３を除き図１１と同じである。
【０２５４】
すなわち、ファイルシステム１０５は、新しいヘッダ部を記録するための空きクラスタを確保し、そのクラスタに新しいヘッダ部の情報を書き込む（Ｓ３０１）。
【０２５５】
次に、ファイルシステム１０５は、新しいヘッダ部のＦＡＴエントリに、古いヘッダ部のＦＡＴエントリに記録されている、次のクラスタ番号の値を書き込む（Ｓ３０２）。
【０２５６】
次に、ファイルシステム１０５は、書き換えるクラスタが先頭でない場合（ここでは、先頭から２番目の場合を例示している。）は、書き換えるクラスタの１つ前のクラスタのＦＡＴエントリに、新しいヘッダ部のクラスタ番号を書き込む（Ｓ３２３）。
【０２５７】
なお、これらＦＡＴエントリについての処理（Ｓ３０２およびＳ３２３）により、更新後のヘッダ部にデータ部が続くようにファイル管理情報が修正されることになる。
【０２５８】
最後に、ファイルシステム１０５は、古いヘッダ部のＦＡＴエントリに未割り当てビット列を書き込んで、空きクラスタにして処理を終了する（Ｓ３０４）。
【０２５９】
ここでは、書き換えるクラスタが先頭でない場合（先頭から２番目の場合）を例示しているが、書き換えるクラスタが先頭の場合におけるヘッダ部更新方法は図１１に示す通りである。
【０２６０】
また、更新すべきデータ（例えばＬｅｎｇｔｈ部）が１つのクラスタに置かれている場合を例示しているが、更新すべきデータ（例えばＬｅｎｇｔｈ部）が複数のクラスタにまたがる場合は、これら複数のクラスタを空きクラスタに移動させればよい。
【０２６１】
以上のように、本発明によれば、更新前のヘッダ部が複数のクラスタにまたがる場合でも、これらクラスタ以外の複数または１つのクラスタに、新たなヘッダ部を記録する。
【０２６２】
具体的には、本実施の形態においては、既に確保されているブロックではなく新たに確保されたブロック内の１以上のクラスタに更新後のヘッダ部が記録される。これにより、リード・モディファイ・ライト動作が発生しなくなり高速に記録処理を行うことが可能である。
【０２６３】
特に、図１９に示されるヘッダ部更新方法を採用すれば、ヘッダ部の書き換えとは無関係な余分なデータの読み出しを極力抑えることができるという効果がある。
【０２６４】
なお、本実施の形態では、ヘッダサイズがクラスタサイズの整数倍であることを前提に説明したが、本発明はこれに限定されるものではない。
【０２６５】
図２１は、ヘッダサイズがクラスタサイズの整数倍でない場合のヘッダ部の更新に係る処理を説明するための図である。
【０２６６】
この図に示されるように、ヘッダサイズがクラスタサイズの整数倍でない場合の処理方法としては２通りの方法がある。
【０２６７】
１つ目の方法は、クラスタ内の領域のうちヘッダ部が記録されていない部分（以下、「残部」という。）をデータ部で埋める方法である。２つ目の方法は、残部をパディングビット等の無意味なデータで埋める方法である。
【０２６８】
２つ目の方法を採用した場合は、次のクラスタからデータ部が記録されることになる。いずれの方法を採用しても、ヘッダ部のデータとヘッダ部以外のデータとが混在するクラスタが生じるので、そのクラスタの扱いが問題となる。
【０２６９】
図２２は、ヘッダ部のデータとヘッダ部以外のデータとが混在するクラスタの扱いを示す図である。
【０２７０】
このデータ混在クラスタを扱う方法としては２通りの方法がある。１つ目の方法は、ヘッダ部のデータとヘッダ部以外のデータとをＲＡＭ等のファイルシステム用メモリ１０６に一時記憶しておき、このファイルシステム用メモリ１０６からヘッダ部のデータとヘッダ部以外のデータとを読み出す方法である（図中の（ｉ）参照）。
【０２７１】
２つ目の方法は、フラッシュメモリ等の記録メモリ１１１からヘッダ部のデータとヘッダ部以外のデータとを読み出す方法である（図中の（ｉｉ）参照）。ファイルシステム用メモリ１０６または記録メモリ１１１から読み出されたヘッダ部が更新されて空きクラスタに書き込まれる点は上述した通りである。
【０２７２】
図２２では消去ブロック１〜３を例示しているが、各消去ブロックに含まれる内容は限定されるものではない。
【０２７３】
以上のように、本発明は、ヘッダサイズがクラスタサイズの整数倍でない場合にも適用することができる。また、このような場合はヘッダとヘッダ以外のデータとが混在するクラスタが生じることになるが、このデータ混在クラスタを上記した２通りの方法によって扱うことが可能である。
【０２７４】
なお、本実施の形態では、記録再生装置１００が記録するデータは、映像及び音声を含むデータであるとしたが、映像及び音声のうちいずれか一方のみを含むようなデータであってもよい。
【０２７５】
また、本実施の形態では、記録媒体として半導体メモリを例示して本発明の特徴を説明した。しかしながら、光ディスクやハードディスク等の記録媒体を採用した場合でも、本発明の記録装置および記録方法により、リード・モディファイ・ライトを行わずに情報を記録できる効果が得られることは明らかである。
【０２７６】
また、本実施の形態において、更新後のヘッダ部は、更新前のヘッダ部が記録されたブロック以外のブロック内のクラスタに記録されるとした。
【０２７７】
しかしながら、更新後のヘッダ部を、更新前のヘッダ部が記録されたブロックと同じブロック内のクラスタに記録してもよい。
【０２７８】
例えば、記録再生装置１００が、記録ブロックサイズである１ＭＢごとにデータを記録メモリ１１１に記録するという動作を行わず、１クラスタ分のデータが蓄積されるごとに、蓄積されたデータを空きクラスタに記録する動作を行う場合を想定する。
【０２７９】
この場合、仮にファイルサイズが１ＭＢより小さなファイルであれば、そのファイルの記録終了の時点では、更新前のヘッダ部が記録されているブロックには空きクラスタが存在する。
【０２８０】
そこで、更新後のヘッダ部をその空きクラスタに記録し、図１１を用いて説明したように、ＦＡＴエントリ等のファイル管理情報の修正を行う。
【０２８１】
これにより、リード・モディファイ・ライトを発生させることなく、論理的なファイル構成を維持したまま当該ファイルを記録メモリ１１１に記録することができる。
【０２８２】
また、本実施の形態では、デジタルビデオカメラが映像信号等をファイル化して記録媒体に記録する場面を例示して説明したが、本発明の適用場面はこれに限定されるものではない。
【０２８３】
すなわち、図２３に示されるように、デジタルビデオカメラ（記録再生装置１００）によって生成されたファイルを記録メモリ１１１経由でパーソナル・コンピュータ等に移動させて編集する場合がある。
【０２８４】
この編集処理において何らかの理由でファイルのヘッダ部を更新する必要が生じた場合にも、前記と同様に本発明を適用することができる。つまり、パーソナル・コンピュータ等に本発明の記録方法を実行させることで、リード・モディファイ・ライトを発生させずにヘッダ部の更新が行われる。
【０２８５】
また、本実施の形態において前述した各ステップを、コンピュータに実行させる記録プログラムとしてもよい。さらに、この記録プログラムをコンピュータ読み取り可能な記録媒体に記録してもよい。記録媒体としてはメモリカード等の半導体メモリ、ＣＤ−Ｒ、ＤＶＤ等の光記録媒体、ＭＯ等の光磁気記録媒体、フレキシブルディスク等の磁気記録媒体等のいずれであってもよい。
【０２８６】
上記のようにコンピュータに実行させる記録プログラム及び該記録プログラムを記録した記録媒体から記録プログラムを読み出して実行することによって、コンピュータを記録装置の制御部として駆動させることができる。
【産業上の利用可能性】
【０２８７】
本発明に係る記録装置及び記録方法は、ブロックサイズよりも小さいファイルのヘッダ部を更新する場合、リード・モディファイ・ライトを行わずに更新することができる。そのため、半導体メモリ等への高速記録を実現するのに有用である。
【符号の説明】
【０２８８】
１００  記録再生装置
１０１  システム制御部
１０２  映像ファイル処理部
１０３  音声ファイル処理部
１０４  記録メモリ処理部
１０５  ファイルシステム
１０６  ファイルシステム用メモリ
１０７  記録バッファメモリ
１０８  再生バッファメモリ
１０９  ファイル修復処理部
１１０  記録メモリＩ／Ｆ部
１１１  記録メモリ
１２０  Ｉ／Ｏバス
１３０  入力部
１３１  映像エンコーダ
１３２  映像入力部
１３３  映像デコーダ
１３４  映像出力部
１３５  音声エンコーダ
１３６  音声入力部
１３７  音声デコーダ
１３８  音声出力部
１３９  表示部
７０１  ユーザデータ領域に書き込まれるファイルＦｉｌｅ１
７０２  Ｆｉｌｅ１を記録するディレクトリのディレクトリエントリ
７０３  Ｆｉｌｅ１のファイルエントリ
７０４  Ａ番目のクラスタに対応するＦＡＴエントリ
７０５  Ｂ番目のクラスタに対応するＦＡＴエントリ
７０６  Ｃ番目のクラスタに対応するＦＡＴエントリ
７０７  Ｄ番目のクラスタに対応するＦＡＴエントリ
１１０２  十字キー
１１０３  停止ボタン
１１０４  再生ボタン
１１０５  メニューボタン
【手続補正２】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
記録済みの情報の消去の最小単位がブロックである記録領域を有する記録媒体に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録装置であって、
ファイルの記録開始要求および記録停止要求を受け付ける受付手段と、
前記受付手段により前記記録開始要求が受け付けられた場合、前記ファイルのヘッダ部と前記ヘッダ部に続くデータ部とを前記記録領域内のブロックの先頭から記録し、前記受付手段により前記記録停止要求が受け付けられた場合、前記ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録する記録手段と、
前記記録手段により前記更新後のヘッダ部が前記他のクラスタに記録される場合、前記更新後のヘッダ部に前記データ部が続くように、前記記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する修正手段と
を備える記録装置。
【請求項２】
前記記録手段は、前記受付手段により前記記録停止要求が受け付けられた場合、前記更新前のヘッダ部を記録したブロックとは異なるブロックに含まれる前記他のクラスタに、更新後のヘッダ部を記録する
請求項１記載の記録装置。
【請求項３】
前記記録手段は、前記受付手段により前記記録開始要求が受け付けられた場合、クラスタサイズの整数倍のサイズである前記更新前のヘッダ部を前記記録領域内のブロックに記録する
請求項１記載の記録装置。
【請求項４】
前記記録手段は、前記更新前のヘッダ部が複数のクラスタにまたがって記録されている場合、前記受付手段により前記記録停止要求が受け付けられると、前記複数のクラスタに記録されている情報の全てを、前記複数のクラスタとは異なる、前記他のクラスタを含む複数のクラスタに記録する
請求項３記載の記録装置。
【請求項５】
前記記録手段は、前記更新前のヘッダ部が複数のクラスタにまたがって記録されている場合、前記受付手段により前記記録停止要求が受け付けられると、前記更新前のヘッダ部の中の更新すべき部分を記録しているクラスタのみから情報を読み出して更新し、更新した情報を前記他のクラスタに記録する
請求項３記載の記録装置。
【請求項６】
前記修正手段は、前記記録手段により前記更新後のヘッダ部が前記他のクラスタに記録される場合、さらに、前記更新前のヘッダ部が記録されていたクラスタが未使用のクラスタであることを前記管理情報が示すように前記管理情報を修正することで、前記更新前のヘッダ部が記録されたクラスタを解放する
請求項１記載の記録装置。
【請求項７】
前記管理情報は、前記更新前のヘッダ部が記録されたクラスタを特定する情報を含むファイルエントリと、前記接続順序を示す複数のＦＡＴ（Ｆｉｌｅ  Ａｌｌｏｃａｔｉｏｎ  Ｔａｂｌｅｓ）エントリとを含み、
前記修正手段は、前記管理情報を修正する場合、（１）前記他のクラスタに対応するＦＡＴエントリの確保、（２）前記ＦＡＴエントリの変更、（３）前記ファイルエントリの変更、（４）前記更新前のヘッダ部が記録されたクラスタの解放という順番で処理を行う
請求項６記載の記録装置。
【請求項８】
前記記録媒体は、不揮発性半導体メモリ媒体である
請求項１記載の記録装置。
【請求項９】
前記記録手段はさらに、前記記録媒体の残量がなくなったことを検出した場合、前記更新前のヘッダ部を更新し、前記他のクラスタに前記更新後のヘッダ部を記録する
請求項１記載の記録装置。
【請求項１０】
記録済みの情報の消去の最小単位がブロックである記録領域を有する記録媒体に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録装置における記録方法であって、
ファイルの記録開始要求および記録停止要求を受け付ける受付ステップと、
前記受付ステップにおいて前記記録開始要求が受け付けられた場合、前記ファイルのヘッダ部と前記ヘッダ部に続くデータ部とを前記記録領域内のブロックの先頭から記録し、前記受付ステップにおいて前記記録停止要求が受け付けられた場合、前記ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録する記録ステップと、
前記記録ステップにおいて前記更新後のヘッダ部が前記他のクラスタに記録される場合、前記更新後のヘッダ部に前記データ部が続くように、前記記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する修正ステップと
を含む記録方法。
【請求項１１】
記録済みの情報の消去の最小単位がブロックである記録領域を有する記録媒体に対して、ブロックよりも小さな単位であるクラスタ単位で情報を記録可能な記録装置を制御するためのプログラムであって、
ファイルの記録開始要求および記録停止要求を受け付ける受付ステップと、
前記受付ステップにおいて前記記録開始要求が受け付けられた場合、前記ファイルのヘッダ部と前記ヘッダ部に続くデータ部とを前記記録領域内のブロックの先頭から記録し、前記受付ステップにおいて前記記録停止要求が受け付けられた場合、前記ヘッダ部を更新し、更新後のヘッダ部を、更新前のヘッダ部を記録したクラスタとは異なる他のクラスタに記録する記録ステップと、
前記記録ステップにおいて前記更新後のヘッダ部が前記他のクラスタに記録される場合、前記更新後のヘッダ部に前記データ部が続くように、前記記録媒体が有する、各クラスタに記録された情報の接続順序を示す管理情報を修正する修正ステップと
をコンピュータに実行させるためのプログラム。
【手続補正３】
【補正対象書類名】図面
【補正対象項目名】全図
【補正方法】変更
【補正の内容】
【図１】
2008146475.tif 000026
【図２】
2008146475.tif 000027
【図３】
2008146475.tif 000028
【図４】
2008146475.tif 000029
【図５】
2008146475.tif 000030
【図６】
2008146475.tif 000031
【図７】
2008146475.tif 000032
【図８】
2008146475.tif 000033
【図９】
2008146475.tif 000034
【図１０】
2008146475.tif 000035
【図１１】
2008146475.tif 000036
【図１２】
2008146475.tif 000037
【図１３】
2008146475.tif 000038
【図１４】
2008146475.tif 000039
【図１５】
2008146475.tif 000040
【図１６】
2008146475.tif 000041
【図１７】
2008146475.tif 000042
【図１８】
2008146475.tif 000043
【図１９】
2008146475.tif 000044
【図２０】
2008146475.tif 000045
【図２１】
2008146475.tif 000046
【図２２】
2008146475.tif 000047
【図２３】
2008146475.tif 000048
【国際調査報告】
2008146475.tif 000049
2008146475.tif 000050