JP2005301641A - 映像撮影装置 - Google Patents

Abstract

【課題】記録中に媒体を突然抜く、突然電源が落ちるなどの異常終了が起きたときにデータを修復して再生を再び可能とする。
【解決手段】ファイルフォーマット検出手段２４１は、異常ファイルのファイルフォーマットを検出する。検出したフォーマットに基づいて、有効データ長検出手段２４４は、異常ファイルのうち記録完了している部分の映像、音声データを検出する。エッセンスファイルメタデータ修復手段２４５は、検出した有効データ長をもとにファイルフォーマットに適合するようにファイルを修正する。
【選択図】図８

Description

本発明は、映像や音声等の素材を記録媒体に記録中に突然記録媒体を抜く、電源が落ちる等の異常終了が起きた場合に、素材を修復して再生することを再び可能にする映像撮影装置に関する。

ビデオカメラやデジタルスチルカメラといった撮影装置やディスクレコーダのような記録装置において、メモリカードやハードディスク、光ディスク等のランダムアクセス可能な記録媒体にデータを記録するには、利用性等の観点からデータをファイルとして記録するのが一般的である。記録媒体にファイルを記録するためには、記録媒体上のファイルを管理するためのファイルシステムと呼ばれるモジュールが用いられる。ファイルシステムの動作は複雑であるため、撮影装置や記録装置にオペレーティングシステム（ＯＳ）を搭載して、ソフトウェアとしてファイルシステムを実装するのが一般的である。

メモリカードで採用されているファイルシステムには、ＦＡＴ（非特許文献１）がある。図１を用いて概略を説明する。メモリカードやハードディスク等の物理ドライブ６００は、通常、領域の先頭に置かれるマスターブートレコード１０２と１個以上の論理ドライブ１０１から構成される。１個の論理ドライブ１０１は、１種類のファイルシステムでフォーマットされる。ＦＡＴフォーマットの場合、領域の先頭からパーティションブートセクタ１０３、ファイルアロケーションテーブル（ＦＡＴ）１０４、ＦＡＴのバックアップ１０４ｂ、ルートディレクトリエントリ１０５というシステム領域が配置され、システム領域の後ろにユーザデータ領域１０６が配置される。パーティションブートセクタ１０３には、パーティションのセクタ数といったパーティションを起動するのに必要な情報が記録される。ＦＡＴ１０４には、ファイルの記録情報が配置される。ユーザデータ領域１０６には、ファイルのデータ自体が置かれる。ファイルはクラスタと呼ばれる単位（通常４ＫＢ〜３２ＫＢ）で記録される。

ルートディレクトリエントリ１０５には、ルートディレクトリに置かれているファイル又はディレクトリの情報がエントリとして記録される。階層構造のディレクトリにおいて、全てのファイル及びディレクトリは、図２のようなディレクトリエントリ１０７として記録される。図２は、ＦＬＯＷＥＲ０２．ＡＶＩというファイル名を持つファイルのディレクトリエントリを示している。このようにＦＡＴフォーマットにおいては、ファイルはファイル名が８文字、拡張子が３文字の８．３形式で記録される。ディレクトリエントリ１０７には、ファイルのデータが置かれる先頭のクラスタ番号１０８が含まれる。この先頭のクラスタ番号１０８によりファイルのデータにアクセスできる。

ＤＶＤで採用されているファイルシステムは、米国のＯＳＴＡ（Ｏｐｔｉｃａｌ Ｓｔｏｒａｇｅ Ｔｅｃｈｎｏｌｏｇｙ Ａｓｓｏｃｉａｔｉｏｎ）によって定められているＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａｔ）である。ＵＤＦでは、ディレクトリ及びファイルの管理情報を実際の記録位置（実アドレス）として直接管理するかわりに、ファイル識別記述子（ＦＩＤ；Ｆｉｌｅ Ｉｄｅｎｔｉｆｉｅｒ Ｄｅｓｃｒｉｐｔｏｒ）、仮想割り当てテーブル（ＶＡＴ；Ｖｉｒｔｕａｌ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅ）、ファイルエントリＩＣＢ（ＦｉｌｅＥｎｔｒｙ Ｉｎｆｏｒｍａｔｉｏｎ Ｃｏｎｔｒｏｌ Ｂｌｏｃｋ）等を用いて間接的に管理している。

ＶＡＴとは、記録媒体に対して追記録方式で記録を行う際に、あたかも媒体上の任意のアドレスにアクセスしてデータの更新や再生ができるかのように扱うための技術であり、ファイルが実際に記録されている実アドレスと、この実アドレスに対応する仮想アドレス
を対応テーブルとして管理するものである。

また、ＵＤＦでは、データの書き込み／読み出しが行われる一纏まりの論理セクタ列をエクステントと呼称し、それぞれのエクステントの開始アドレスをファイル情報として保持し、更新するファイルシステム情報とともに追記している。

撮影装置を用いてファイルをリムーバブルな記録媒体に記録する場合、突然の抜き取りやバッテリーの停止などによりファイルが不正な状態で残存してしまうため、再生できないデータが記録媒体上に残ってしまうことになる。このような障害時にファイルシステムにおいてファイルを修復する方法は多く提案されている。特許文献１は、消去済みファイルのコードをＦＡＴのディレクトリエントリに記録し、障害時に残る断片データやファイル消去時に残存する未消去領域を消去する方法を提案している。特許文献２は、ＵＤＦに対するファイルの修復を示しており、データの記録が中断した際、エクステントのファイル名、ファイルのディレクトリ情報ファイルエントリＩＣＢ、ＶＡＴなどを修復用ファイル情報として所定領域に記録し、その修復用ファイル情報を元にファイルを修復する方法を提案している。特許文献３は、ユーザ領域とは別のシステム領域に番組の記録履歴の情報を記録し、記録が終了していない番組のファイルの先頭アドレスから順に修復を行う方法を提案している。
特開平９−２５２４４７号公報 特開２００３−１６９２９３号公報 特開２００１−１４３４３９号公報 Ｓｔａｎｄａｒｄ ＥＣＭＡ−１０７： Ｖｏｌｕｍｅ ａｎｄ Ｆｉｌｅ Ｓｔｒｕｃｔｕｒｅ ｏｆ Ｄｉｓｋ Ｃａｒｔｒｉｄｇｅｓ ｆｏｒ Ｉｎｆｏｒｍａｔｉｏｎ Ｉｎｔｅｒｃｈａｎｇｅ

しかしながら、このような従来の映像撮影装置はファイルシステムの修復のみに注目していたため、ファイルフォーマットの整合性の修復（ファイルとして読み書きができるようにする）まではできるが、そのファイルに含まれる映像データや音声データのフォーマットの修復（映像データや音声データとして再生できるようにする）までは行えなかった。また、音声、映像データを別ファイルに記録する場合にそれらの整合性を取って修復することもできなかった。

上記課題に鑑み本発明の映像撮影装置は、映像、音声の素材データを記録媒体に記録中に突然記録媒体を抜く、電源が落ちる等の異常終了が起きた場合にも、データを修復して再生を再び可能とすることを目的とする。

上記課題を解決するために本発明の映像撮影装置は、記録を中断された異常ファイルのファイルフォーマットを検出するファイルフォーマット検出手段と、前記ファイルフォーマット検出手段により検出したフォーマットに基づいて異常ファイルに含まれるデータのうち記録完了しているデータの長さを検出する有効データ長検出手段と、前記有効データ長検出手段により検出した有効データ長に基づいて前記異常ファイルのメタデータを修正するメタデータ修復手段とを具備する構成としたものである。

本発明の映像撮影装置によれば、異常終了が起きた場合でも素材中で記録完了した部分のデータ長を検出して修復し、素材を再生できるようになる。

以下、本発明の実施の形態を、図面を参照しながら説明する。
（実施の形態１）
以下に示す実施の形態では、撮影装置は編集との親和性を考慮して映像、音声のデータ等を別ファイルで記録することとする。つまり、撮影時に複数のファイルが同時生成されることになる。このように同時に生成された映像、音声のファイルをまとめてクリップと呼ぶ。このクリップには、映像、音声以外に、クリップに付随するメタデータを別途ファイルとして記録する。それをクリップメタデータと呼ぶ。クリップには、これ以外にサムネール画像などのメタデータファイルが関連付けられることもある。クリップの構成要素である映像、音声のファイルをエッセンスファイルと呼ぶ。

メタデータとは、データについての情報を記述したデータである。クリップに関するメタデータには、コーデックのタイプやサンプリングレートなどクリップを再生するときに必要なデータや、撮影者や撮影時間などクリップを検索するときに必要なデータなどがある。本実施の形態のクリップメタデータは図３に示すようなＸＭＬ形式のファイルで記録する。ＥｓｓｅｎｃｅＬｉｓｔ２０１が再生に必要なメタデータ、ＣｌｉｐＭｅｔａｄａｔａ２０２が検索などに使用されるメタデータである。

エッセンスファイルはＭＸＦファイル（ＳＭＰＴＥ３７７Ｍ参照）で記録される。ＭＸＦファイルは図４に示すようなフォーマットであり、大きくヘッダ部２１０、ボディ部２１１、フッタ部２１２に分かれている。ヘッダ部２１０、フッタ部２１１にはコーデックのタイプなどのメタデータが記録されており、ボディ部２１１に音声、映像データが含まれている。映像データはＤＩＦデータ（ＳＭＰＴＥ３１４で規定された圧縮データ）と呼ばれるフレーム内圧縮の形式で記録されている。またＤＩＦでは音声ファイルに記録されているデータと同一の音声データをフレームに多重して記録することができる。すなわち、映像データファイル２１３には、音声ファイル２１４と音声ファイル２１５と同じデータが音声データＡ２１６、音声データＢ２１７のように映像に多重されて記録される。

本実施の形態の撮影装置が映像を撮影する流れを図５に示す。まず、ファイル格納場所管理手段２２０は図６に示すディレクトリ構成に基づいて映像、音声およびメタデータを記録すべきファイルのファイル名を決定し、クリップメタデータ作成手段２２１、映像ファイル作成手段２２２、音声ファイル作成手段２２３に記録すべきファイル名を通知する。図６のファイル名は、ファイル間の対応関係を取ることができるよう、Ｃｌｉｐ１＿０．ｍｘｆやＣｌｉｐ１．ｘｍｌなどファイル中にクリップ名（図６ではＣｌｉｐ１）を含めている。

クリップメタデータ作成手段２２１はクリップメタデータファイルを作成する手段であり、撮影時にはコーデックタイプやサンプリングレートなど撮影前に決定している情報をメタデータファイルへ記録し、撮影終了時にわかるクリップの長さや撮影終了時刻などは記録せずに無効なデータとしておく。例えば図７のように、
＜Ｄｕｒａｔｉｏｎ＞０＜／Ｄｕｒａｔｉｏｎ＞
として０のクリップ長を記録しておく。ＸＭＬのスキーマ上は０のクリップ長を指定することができないため、これは異常のクリップであるとの判断に使用することができる。映像ファイル作成手段２２２、音声ファイル作成手段２２３は撮影前に決定している情報をエッセンスファイルのヘッダ部２１０に記録する。

これらの準備をした後、映像や音声を取り込み、記録媒体にデータを記録する。映像入力手段２２４で取り込んだ映像は映像ファイル作成手段２２２で圧縮され、記録手段２２６を通して記録媒体２２７に記録される。同様に、音声入力手段２２５で取り込んだ音声は音声ファイル作成手段２２３、記録手段２２６を通して記録媒体２２７に記録される
撮影停止時は、映像入力手段２２４、音声入力手段２２５はそれぞれ映像、音声の取り込みを中断し、クリップメタデータ作成手段２２１、映像ファイル作成手段２２２、音声ファイル作成手段２２３はクリップの撮影終了処理を行う。映像ファイル作成手段２２２、音声ファイル作成手段２２３はＭＸＦファイルのフッタ部２１２を作成し、クリップの長さや撮影終了時刻などのメタデータを書き込むとともに、ヘッダ部２１０に撮影前には記録していなかったデータを書き込み、ファイルを閉じる。クリップメタデータ作成手段２２１は同様の情報をメタデータファイルに書き込む。

この撮影停止時の処理が終わる前に記録媒体２２７を抜かれたり、異常終了などで機器が止まったりすると、フレームの途中で途切れた異常な映像データのファイルや音声データのファイル、そしてクリップの長さや撮影終了時間が書かれていない不完全なクリップができてしまう。

異常なクリップを構成するファイルはデータが読めない状態、つまりファイルシステムの異常が発生することがある。このようなファイルシステムの異常を修復するには従来技術として開示されている方法を用いることで、ファイルの読み書きが正常にでき、撮影時までのデータを参照することができる状態になる。

しかし、このようなファイルシステムの修復が行われたとしても、クリップの情報は不正なままであり、ファイルとしては読み書きできるが依然として再生装置等では映像や音声として再生できないなどの不具合が残る。またメタデータがＸＭＬのスキーマに合致しない状態であるため、読み込みに失敗してしまう不具合もある。

このような不具合を修復する方法を、図８を用いて説明する。まず、異常クリップ検出手段２４０はクリップメタデータ内の有効データ長（図７のＤｕｒａｔｉｏｎに相当）を参照し、図７のように０であるものを異常クリップであると認識する。ファイルフォーマット検出手段２４１はメタデータに記録されているエッセンスファイルのフォーマットとエッセンスファイルのヘッダに書かれているフォーマットを比較し、同一であればそれをエッセンスファイルのファイルフォーマットとする。異なっていたら、フォーマット確認手段２４２にユーザへのフォーマットの確認を指示する。フォーマット確認手段２４２は図９に示すようなフォーマット一覧２８０からユーザにフォーマットを指定させる。映像再生手段２４３は指定フォーマットでの再生を画面２８１上で行う。

有効データ長検出手段２４４は、検出または指定されたフォーマットを元に、各ファイルの有効データ長を設定する。有効データ長とは、異常ファイルに含まれるデータのうち、正しく記録が完了しているデータの長さである。例えば書き込み処理の性能を向上するために、３２ＫＢ単位でエッセンスデータの書き込みを行う撮影機器に異常終了が起きたとき、エッセンスファイルは３２ＫＢの整数倍のサイズになっている。映像データのファイル長が１８，８７４，３６８バイト（＝１８ＭＢ＝３２ＫＢ×５７６）、音声データのファイル長が５２４，２８８バイト（＝５１２ＫＢ＝３２ＫＢ×１６）であり、ともにヘッダのサイズが３２，７６８バイト（３２ＫＢ）であった場合を例にとって有効データ長検出手段２４４の有効データ長の検出方法を説明する。

映像データの有効データサイズは下式により、全データからヘッダサイズを引いて、１８，８４１，６００バイトになる。

１８，８７４，３６８（バイト） − ３２，７６８（バイト）
＝ １８，８４１，６００（バイト）

フォーマット検出手段２４１で、このデータがＤＶＣＰＲＯ（ＳＭＰＴＥ ３０６Ｍ参照）で記録されていると検出されたとすると、ＤＶＣＰＲＯの１フレームのデータサイズは１２０，０００バイトであるため、下式により１５７フレームの映像データが正常に記録され、１５８フレーム目の記録途中で異常終了したことがわかる。

１８，８４１，６００（バイト） ÷ １２０，０００（バイト／フレーム）
＝ １５７．０１３３３（フレーム）

一方、音声データの有効サイズは下式により、全データからヘッダサイズを引いて、４９１，５２０バイトになる。

５２４，２８８（バイト） − ３２，７６８（バイト）
＝ ４９１，５２０（バイト）

フォーマット検出手段２４１で、このデータが４８Ｋサンプリングの１６ビット／サンプル（＝２バイト／サンプル）のデータであることが検出されたとすると、下式により５．１２秒に相当するデータが格納されていることがわかる。

４９１，５２０（バイト） ÷ ２（バイト／サンプル）
÷ ４８，０００（サンプル／秒） ＝ ５．１２（秒）

これを２９．９７フレーム／秒のフレームレートでフレーム換算すると、１５３フレームのデータが記録され、１５４フレーム目の記録途中で異常終了したことがわかる。

５．１２ × ２９．９７ ＝ １５３．４４６４（フレーム）

以上のように、映像データの有効データ長は１５７フレーム、音声データの有効データ長は１５３フレームであることが検出できる。

エッセンスファイルメタデータ修復手段２４５は、映像データ、音声データのそれぞれ末尾１，６００バイト、１，４３０バイトを無効データとし、その後ろにフッタを書く。そして映像、音声それぞれのファイルのヘッダおよびフッタに上記で求めたフレーム数を記録することでエッセンスファイルを修復する。

有効データ長調整手段２４６は、各エッセンス中一番短いものを抽出し、それをクリップに関連付けられたすべての素材ファイルの有効データ長とする。先例の映像ファイルが１５７フレーム、映像ファイルが１５３フレームのときは１５３フレームをクリップのフレーム数として採用し、クリップメタデータファイル中のＤｕｒａｔｉｏｎに記録する。

ＤＩＦ上にはフレームに多重されて、ＵＭＩＤ（Ｕｎｉｖｅｒｓａｌ Ｍａｔｅｒｉａｌ Ｉｄｅｎｔｉｆｉｅｒ、ＳＭＰＴＥ３３０Ｍ参照）が書かれている。ＵＭＩＤとは、編集前の素材をグローバルユニークに特定することができる識別子であり、グローバルユニークな識別子である基本ＵＭＩＤ２５０とメタデータを表すソースパック２５１からなる（図１０）。基本ＵＭＩＤ２５０はＫＬＶ（Ｋｅｙ−Ｌｅｎｇｔｈ−Ｖａｌｕｅ ＳＭＰＴＥ３３６Ｍ参照）形式のキーに相当するユニバーサルラベル２５２、有効データ長２５３、インスタンスＮｏ２５４および時刻、乱数、機器ＩＤなどから作成されるマテリアルＮｏ２５５により構成される。ソースパック２５１には時刻２５６、場所２５７、国２５８、組織２５９、ユーザ２６０のメタデータを入れることができる。最終フレームメタデータ抽出手段２４７は、ＤＩＦにＵＭＩＤのソースパックが入っている場合に、クリップの最終フレームに相当するＤＩＦからＵＭＩＤの時刻情報を抜き出して撮影終了時刻とし、記録手段２２６を通して、エッセンスファイル、メタデータファイルに記録する。

以上により、クリップメタデータおよびエッセンスファイルは正常終了したのと等価な状態となり，再生可能になる。修復されたクリップは編集や検索に使用することが可能である。

なお、本実施の形態のファイルフォーマットはヘッダ、ボディ、フッタにより構成されるものとして示したが、ヘッダ、フッタのいずれかあるいは両方がなくても構わない。圧縮方式もＤＩＦ形式を例にとったがＭＰＥＧのようなフレーム間圧縮方式でも構わない。ＭＰＥＧの場合は、サイズから一意に有効データ長を求めるのではなく、ＧＯＰの先頭の識別子（００００１Ｂ８）を調べるあるいはデコードしてデコード成功したところまでを有効データ長にするなどの方法で求めることができる。圧縮音声に関しても同様である。

有効データ長が０であるものをエラーとしたが、図１１のＲｅｃｏｒｄｉｎｇ属性のようにＸＭＬ中に特別な定義を追加してもよい。Ｒｅｃｏｒｄｉｎｇ属性は真のときはまだ記録中のクリップの意味であり、再起動後に記録中のクリップであることが異常状態であることを示している。また、図１２のＣｌｉｐ１．ｘｍｌ〜のように記録中のファイル名を記録完了後のファイル名と異なるものとし、ファイル名の一部で作成中である旨を識別しても良い。

また、クリップのメタデータとしてクリップメタデータファイルを設けたが、別ファイルではなく、エッセンスファイルのヘッダまたはフッタにクリップの情報が記録されていても構わない。その場合の異常クリップ検出手段２４０の動作は、ＸＭＬファイルを見るかＭＸＦファイルを見るかの違いだけで検出方法は同様である。

本実施の形態ではクリップメタデータをＸＭＬとしたが、その他の形式でも構わない。
（実施の形態２）
実施の形態１では、クリップの修復時に音声データの有効フレーム数に合わせてクリップのフレーム数が決定されるため、４フレーム分の映像データが再生可能にもかかわらずクリップとして参照されることはなく、記録できている映像データが無駄になっている。一般に特定バイトずつデータを書き込む記録方法においては、音声のデータのほうが特定バイト中に多くの時間のデータを格納できるため、実施の形態１の修復方法では記録されている映像データが切り取られる傾向にある。本実施の形態では、映像に音声を多重して記録することにより、無駄のないクリップの修復を行う方法を示す。

本実施の形態で示しているＤＩＦは図４に示すように、音声を映像に多重して記録することが可能である。しかし、アフレコなどを考慮すると、映像に多重している音声が、音声ファイルと常に一致しているという保証はない。 そこで、メタデータに図１３に示すようなＶａｌｉｄＡｕｄｉｏＦｌａｇという映像内音声データ識別フラグを追加する。ＶａｌｉｄＡｕｄｉｏＦｌａｇが真の時は、音声ファイルと映像に多重して記録されている音声データが同一のデータであることを示す。この情報は記録時にクリップメタデータ作成手段２２１がクリップメタデータに記録する。

ＶａｌｉｄＡｕｄｉｏＦｌａｇが真の時に、上記障害が起きた場合にクリップを修正する方法を図１４に示す。有効データ調整手段２４６は、例えば実施の形態１と同様に、映像ファイルが１５７フレーム、音声ファイルが１５３フレームのように音声ファイルが映像ファイルに比べて短いことを検知すると、クリップメタデータ内のＶａｌｉｄＡｕｄｉｏＦｌａｇの真偽を調べる。ＶａｌｉｄＡｕｄｉｏＦｌａｇが真の場合にはこのクリップが障害により記録が途中で終了していると認識し、有効データ調整手段２４６は、音声データ抽出手段２７０に不足分のデータを映像データから抽出することを指示する。音声データ抽出手段２７０は１５４フレーム目から１５７フレーム目までの映像データから音声データの不足分４フレームのデータを抽出し、音声データの１５３フレーム目の後ろに追加する。エッセンスファイルメタデータ修復手段２４５は音声ファイルのヘッダ、フッタ中の有効データ長に関する個所を１５７フレームに書き換える。有効データ調整手段２４６は、映像から抽出したデータを含め、１５７フレームのクリップ長としてクリップメタデータに記録し、修復を完了する。

上記の方法で記録および修復をすることで、映像データを無駄にしないクリップの修復をおこなうことができるようになる。また、音声データをすべて映像データから抽出するのに比べて、映像データから音声データの抽出の範囲を狭めることができるため、高速に修復処理を完了することができる。

本発明は、後工程として編集作業が想定されるような、ランダムアクセスメディアに撮影したデータを記録する撮影装置等に適用可能である。

ＦＡＴフォーマット解説図 ディレクトリエントリ解説図 実施の形態１のクリップメタデータの例を示す図 実施の形態１、２のエッセンスファイルの構造を示す図 実施の形態１の撮影装置の構成図 実施の形態１の撮影装置のディレクトリ構成図 実施の形態１のクリップメタデータの異常状態の解説図 実施の形態１のクリップ修復の構成図 実施の形態１のフォーマット確認手段を示す図 ＵＭＩＤの解説図 実施の形態１のクリップメタデータの異常状態の別例１を示す図 実施の形態１のクリップメタデータの異常状態の別例２を示す図 実施の形態２の音声多重情報の例を示す図 実施の形態２のクリップ修復の構成図

符号の説明

１００ 物理ドライブ
１０１ 論理ドライブ
１０２ マスターブートレコード
１０３ パーティションブートセクタ
１０４ ファイルアロケーションテーブル＃１
１０４ｂ ファイルアロケーションテーブル＃２
１０５ ルートディレクトリエントリ
１０６ ユーザデータ
１０７ ディレクトリエントリ
１０８ 先頭のクラスタ番号
２０１ ＥｓｓｅｎｃｅＬｉｓｔ
２０２ ＣｌｉｐＭｅｔａｄａｔａ
２１０ ファイルヘッダ
２１１ ファイルボディ
２１２ ファイルフッタ
２１３ 映像ファイル
２１４ 音声ファイル１
２１５ 音声ファイル２
２１６ 映像ファイルに多重されている音声データＡ
２１７ 映像ファイルに多重されている音声データＢ
２２０ ファイル格納場所管理手段
２２１ クリップメタデータ作成手段
２２２ 映像ファイル作成手段
２２３ 音声ファイル作成手段
２２４ 映像入力手段
２２５ 音声入力手段
２２６ 記録手段
２２７ 記録媒体
２４０ 異常クリップ検出手段
２４１ ファイルフォーマット検出手段
２４２ ファイルフォーマット確認手段
２４３ 映像再生装置
２４４ 有効データ長検出装置
２４５ エッセンスファイルメタデータ修復手段
２４６ 有効データ長調整手段
２４７ 最終フレームメタデータ抽出手段
２５０ 基本ＵＭＩＤ
２５１ ソースパック
２５２ ユニバーサルラベル
２５３ 長さ（有効データ長）
２５４ インスタンスＮｏ
２５５ マテリアルＮｏ
２５６ 時間
２５７ 場所
２５８ 国
２５９ 組織
２６０ ユーザ
２７０ 音声データ抽出手段
２８０ フォーマット選択手段
２８１ 画像表示部

Claims (6)

1. １つ以上の映像および音声データをそれぞれファイルとして記録媒体に記録する映像撮影装置であって、
   ファイルのファイルフォーマットを検出するファイルフォーマット検出手段と、
   前記ファイルフォーマット検出手段により検出したフォーマットに基づいて前記ファイルに含まれるデータのうち記録完了しているデータの長さを検出する有効データ長検出手段と、
   前記有効データ長検出手段により検出した有効データ長に基づいて前記ファイルのメタデータを修復するメタデータ修復手段とを具備する映像撮影装置。
2. １つ以上の映像および音声データをそれぞれファイルとして記録媒体に記録し、記録された複数のファイルを一単位（クリップ）として取り扱う映像撮影装置であって、
   前記有効データ長検出手段により検出した前記映像および音声データそれぞれの有効データ長から前記クリップの有効フレーム数を計算して前記映像および音声データのメタデータに記録する有効データ長調整手段を具備する請求項１記載の映像撮影装置。
3. １つ以上の映像および音声データをそれぞれファイルとして記録媒体に記録するとともに前記映像および音声データについての情報であるクリップメタデータファイルをファイルとして記録し、記録された複数のファイルを一単位（クリップ）として取り扱う映像撮影装置であって、
   前記有効データ長検出手段により検出した前記映像および音声データそれぞれの有効データ長から前記クリップの有効フレーム数を計算して前記クリップメタデータファイルに記録する有効データ長調整手段を具備する請求項１記載の映像撮影装置。
4. 前記クリップは正常に記録が完了されたか否かの正常記録成否情報を保持しており、前記正常記録成否情報をもとに異常クリップを検出する異常クリップ検出手段を具備する請求項２および３のいずれかに記載の映像撮影装置。
5. 前記ファイルフォーマット検出手段で検出したファイルフォーマットをユーザに確認するフォーマット確認手段と、
   確認の際にユーザが指定したフォーマットで映像および音声データの再生を行う映像再生手段を具備する請求項１記載の映像撮影装置。
6. ファイルとして記録された音声データと同一の音声データが多重されている映像ファイルから音声データを抜き出す音声抽出手段を具備し、
   前記有効データ長調整手段は、ファイルとして記録された音声データと同一の音声データが映像データに多重されていることを示す情報を参照して前記音声抽出手段に映像ファイルからの音声の抽出を命令する請求項２および３のいずれかに記載の映像撮影装置。

Images