JP2005020320A - 情報処理装置および方法、記録媒体、並びにプログラム - Google Patents

Abstract

【課題】記録媒体の利便性を向上させ、より容易に編集処理を行うことができるようにする。
【解決手段】エディットリスト編集部５５のＵＭＩＤ編集部５５ａは、クリップデータ編集部５４において行われる編集処理に伴って生成される各種の情報に基づいて、編集結果に関する情報であるエディットリストを生成し、記憶部６３に記憶させる。なお、その際、エディットリスト編集部５５は、編集対象となるクリップの、リアルタイム性を要求されないメタデータであるクリップメタデータに含まれるＵＭＩＤ変換テーブル等に基づいて、編集後の画像データに対応するＵＭＩＤの不連続点とそのフレーム番号とのＵＭＩＤ変換テーブルを含むエディットリスト用クリップメタデータを生成する。本発明は、映像プログラム製作支援システムに適用することができる。
【選択図】 図２

Description

【０００１】
【発明の属する技術分野】
本発明は情報処理装置および方法、プログラム、並びに記録媒体に関し、特に、例えば、より容易に編集処理を行うこと等ができるようにする情報処理装置および方法、プログラム、並びに記録媒体に関する。
【０００２】
【従来の技術】
近年、撮影等により取得された画像データや音声データが記録媒体に記録される際に、画像データや音声データに編集用の情報として、付加情報が付加される方法が普及してきた（例えば、特許文献１参照）。
【０００３】
【特許文献１】
特開２００１−２９２４２１号公報（第１４−１５ページ、図８）
【０００４】
【発明が解決しようとする課題】
しかしながら、上述したような方法において、元のクリップのデータに影響させずに、クリップの合成等の編集を行いたい場合（非破壊的に編集を行いたい場合）、不都合が生じてしまう恐れがある。
【０００５】
本発明はこのような状況に鑑みてなされたものであり、より容易に編集処理を行うことができるようにする等の、記録媒体の利便性を向上させることができるようにするものである。
【０００６】
【課題を解決するための手段】
本発明の情報処理装置は、第１のデータのメタデータである第１のメタデータに基づいて、第２のデータに対応するメタデータである第２のメタデータを生成する生成手段と、生成手段により生成された第２のメタデータを第１のメタデータのファイルと異なるファイルに登録する登録手段とを備え、第１のメタデータは、第１のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第１の識別情報と、第１のデータに含まれる、画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、第２のメタデータは、第２のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第３の識別情報と、第２のデータに含まれる画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含むことを特徴とする。
【０００７】
前記第１のメタデータおよび第２のメタデータは、再生時に再生時間に無関係に読み出せるメタデータとするようにすることができる。
【０００８】
前記第３の識別情報は、第２のデータに含まれる画像データの先頭のフレームのＵＭＩＤとの相対的な位置におけるＵＭＩＤとするようにすることができる。
【０００９】
前記第３の識別情報は、第２のデータに含まれる画像データの先頭のフレームのＫＬＶデータとの相対的な位置におけるＫＬＶデータとするようにすることができる。
【００１０】
前記第２のテーブルは、第３の識別情報の値が、直前のフレームと連続しないフレームである不連続点における、第３の識別情報と第４の識別情報とを関連付けるテーブルとするようにすることができる。
【００１１】
前記第１のメタデータを含むファイルは、第１のデータを含むファイルと同じディレクトリに配置されるようにすることができ、第２のメタデータを含むファイルは、第２のデータを含むファイルと同じディレクトリに配置されるようにすることができる。
【００１２】
本発明の情報処理方法は、第１のデータのメタデータである第１のメタデータに基づいて、第２のデータに対応するメタデータである第２のメタデータを生成する生成ステップと、生成手段により生成された第２のメタデータを第１のメタデータのファイルと異なるファイルに登録する登録ステップとを含み、第１のメタデータは、第１のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第１の識別情報と、第１のデータに含まれる、画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、第２のメタデータは、第２のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第３の識別情報と、第２のデータに含まれる画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含むことを特徴とする。
【００１３】
本発明の記録媒体のプログラムは、第１のデータのメタデータである第１のメタデータに基づいて、第２のデータに対応するメタデータである第２のメタデータを生成する生成ステップと、生成手段により生成された第２のメタデータを第１のメタデータのファイルと異なるファイルに登録する登録ステップとを含み、第１のメタデータは、第１のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第１の識別情報と、第１のデータに含まれる、画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、第２のメタデータは、第２のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第３の識別情報と、第２のデータに含まれる画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含むことを特徴とする。
【００１４】
本発明のプログラムは、第１のデータのメタデータである第１のメタデータに基づいて、第２のデータに対応するメタデータである第２のメタデータを生成する生成ステップと、生成手段により生成された第２のメタデータを第１のメタデータのファイルと異なるファイルに登録する登録ステップとを含み、第１のメタデータは、第１のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第１の識別情報と、第１のデータに含まれる、画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、第２のメタデータは、第２のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第３の識別情報と、第２のデータに含まれる画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含む処理をコンピュータに実行させることを特徴とする。
【００１５】
本発明の情報処理装置および方法、並びにプログラムにおいては、第１のデータのメタデータである第１のメタデータに基づいて、第２のデータに対応するメタデータである第２のメタデータが生成され、生成された第２のメタデータが第１のメタデータのファイルと異なるファイルに登録され、第１のメタデータには、第１のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第１の識別情報と、第１のデータに含まれる、画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルが含まれ、第２のメタデータには、第２のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第３の識別情報と、第２のデータに含まれる画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルが含まれる。
【００１６】
本発明の情報処理装置は、独立した装置であっても良いし、情報処理を行うブロックであっても良い。
【００１７】
【発明の実施の形態】
以下に本発明の実施の形態を説明するが、請求項に記載の構成要件と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、構成要件に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その構成要件に対応するものではないことを意味するものではない。逆に、具体例が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。
【００１８】
さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。
【００１９】
請求項１に記載の情報処理装置は、第１のデータ（例えば、図１１の画像データ２１０および２２０）の編集処理を行い、前記編集処理により生成される編集後の前記第１のデータである第２のデータ（例えば、図１１の画像データ２３０）を、前記第１のデータのファイルと異なるファイルとして（例えば、図４に示されるように、画像データが含まれるファイルと異なる、エディットリストのファイルとして）管理する情報処理装置（例えば、図１の編集用端末装置１６）であって、前記第１のデータのメタデータである第１のメタデータ（例えば、図３Ａのクリップメタデータ９１）に基づいて、前記第２のデータに対応するメタデータである第２のメタデータ（例えば、図２１のＵＭＩＤ変換テーブル３８０）を生成する生成手段（例えば、図８のステップＳ１乃至Ｓ３の処理を実行する図２のエディットリスト編集部５５）と、前記生成手段により生成された前記第２のメタデータを前記第１のメタデータのファイルと異なるファイル（例えば、図６のエディットリスト用クリップメタデータファイル１７２）に登録する登録手段（例えば、図８のステップＳ３の処理を実行する図２のエディットリスト編集部５５）とを備え、前記第１のメタデータは、前記第１のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第１の識別情報と、前記第１のデータに含まれる、前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブル（例えば、図３のＵＭＩＤ変換テーブル９２）を含み、前記第２のメタデータは、前記第２のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第３の識別情報（例えば、図２１のフレーム番号３８１）と、前記第２のデータに含まれる前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第４の識別情報（例えば、図２１のＵＭＩＤ番号３８２）とを、それぞれに関連付けた第２のテーブル（例えば、図２１のＵＭＩＤ変換テーブル３８０）を含むことを特徴とする。
【００２０】
本発明の情報処理方法は、第１のデータ（例えば、図１１の画像データ２１０および２２０）の編集処理を行い、前記編集処理により生成される編集後の前記第１のデータである第２のデータ（例えば、図１１の画像データ２３０）を、前記第１のデータのファイルと異なるファイルとして（例えば、図４に示されるように、画像データが含まれるファイルと異なる、エディットリストのファイルとして）管理する情報処理装置（例えば、図１の編集用端末装置１６）の情報処理方法であって、前記第１のデータのメタデータである第１のメタデータ（例えば、図３Ａのクリップメタデータ９１）に基づいて、前記第２のデータに対応するメタデータである第２のメタデータ（例えば、図１３の変換テーブル２８０）を生成する生成ステップ（例えば、図８のステップＳ２）と、前記生成ステップの処理により生成された前記第２のメタデータを前記第１のメタデータのファイルと異なるファイル（例えば、図６のエディットリスト用クリップメタデータファイル１７２）に登録する登録ステップ（例えば、図８のステップＳ３）とを含み、第１のメタデータは、第１のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第１の識別情報と、第１のデータに含まれる、画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、第２のメタデータは、第２のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第３の識別情報と、第２のデータに含まれる画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含むことを特徴とする。
【００２１】
尚、記録媒体、および、プログラムに関するクレームとの対応関係については、方法クレームと同様であるので、省略する。
【００２２】
以下に、本発明の実施の形態について図面を参照して説明する。
【００２３】
図１は、本発明を適用した映像プログラム制作支援システムの構成例を示す図である。
【００２４】
図１において、映像プログラム制作支援システム１は、例えば、テレビジョン信号を放送するテレビジョン放送局や、ビデオや映画等の映像コンテンツの制作会社等において設けられるシステムであり、テレビジョン番組や映画等の映像作品である映像プログラムを制作するためのシステムである。この映像プログラム制作支援システム１は、映像プログラムの制作を分担する複数の部署間で、電子ファイル形式で構成される、映像プログラムに付加されたメタデータ等を一貫して利用できるようにし、映像プログラムを効率よく作成するためのシステムである。
【００２５】
映像プログラム制作支援システム１は、図１に示されるように、映像プログラムの企画を行う企画用端末装置１１、企画用端末装置１１が接続されたネットワーク１２、ネットワーク１２に接続された取材用端末装置１３、取材用端末装置１３を構成する撮像装置１４およびフィールドＰＣ／ＰＤＡ（Ｐｅｒｓｏｎａｌ Ｃｏｍｐｕｔｅｒ／Ｐｅｒｓｏｎａｌ Ｄｉｇｉｔａｌ Ａｓｓｉｓｔａｎｔｓ）１５（以下、フィールドＰＣ１５と称する）、同様に、ネットワーク１２に接続される編集用端末装置１６、並びに、記録媒体である光ディスク１７により構成される。
【００２６】
企画用端末装置１１は、例えば、パーソナルコンピュータ等の情報処理装置およびその周辺装置等により構成され、映像プログラムの企画が行われる企画構成部署等に設けられる。この企画構成部署は、映像プログラムの制作全体を統括する部署であり、制作する映像プログラムの企画および構想を行って、映像プログラムのシナリオ（筋書き）を作成するとともに、後述する取材部署および編集部署等の他部署に制作作業内容を指示する部署である。企画用端末装置１０は、例えば、映像プログラムのシナリオに対応する政策指示情報等を含む、電子ファイル形式の構成表メタデータを映像プログラム毎に作成する等の処理を行う。企画用端末装置１１は、生成した構成表メタデータを、ネットワーク１２を介して取材用端末装置１３等に供給する。これにより、企画構成部署は、取材部署等に対して、取材または撮影すべき場面や内容の指示を行う。
【００２７】
取材用端末装置１３は、取材を行う取材部署によって用いられる端末装置群であり、例えば、撮像装置１４とフィールドＰＣ１５により構成される。この取材部署は、例えば、企画構成部署からの制作指示やシナリオに従って、制作現場で実際に取材を行う部署であり、映像プログラムを構成する各場面の映像を撮影するとともに、撮影状況を取材する部署である。
【００２８】
撮像装置１４は、例えば、カムコーダ（登録商標）等のビデオカメラであり、放送用のニュース番組の取材や、スポーツ等の試合の模様、映画などの映像コンテンツの撮影に使用される装置である。この撮像装置１４は、ネットワーク１２に接続されており、例えば、上述した企画用端末装置１１から、ネットワーク１２を介して構成表メタデータを取得する。そして、撮像装置１４は、その取得した構成表メタデータを所定の表示部等に表示し、カメラマン等の撮影スタッフに撮影すべき内容を認識させる。また、撮像装置１４は、撮影スタッフに操作され、取得した構成表メタデータの制作指示情報に基づいて、映像プログラムを構成する各場面の撮影を行う。そして、撮影により得られた画像データや音声データを光ディスク１７等の記録媒体に記録する。
【００２９】
また、撮像装置１４は、例えば、撮像により得られた画像データであるオリジナルの画像データだけでなく、ローレゾリューション（ｌｏｗ ｒｅｓｏｌｕｔｉｏｎ：低解像度）画像データ（以下、ローレゾデータと称する）を光ディスク１７に記録することができる。オリジナルの画像データは、データ量が大きいが、高画質な画像データであるので、映像プログラムの完成品に用いられる。一方、ローレゾデータは、オリジナルの画像データから各フレームの画素数が間引かれること等によって生成された、画素数の少ないフレームの画像に対応する画像データである。また、ローレゾデータは、さらに、例えば、ＭＰＥＧ４方式等でエンコードされているようにしてもよい。このローレゾデータは、オリジナルの画像データと比較して低画質であるが、データ量が小さいので、送信や再生など処理の負荷が軽く、主に粗編集処理等に利用される。
【００３０】
撮像装置１４により、画像データや音声データ等を記録された光ディスク１７は、例えば、後述する編集部署やフィールドＰＣ１５等に搬送され、利用される。しかしながら、光ディスク１７の搬送にはある程度の時間を要するため、撮像装置１４は、ネットワーク１２を介して、企画用端末装置１１、フィールドＰＣ１５、または編集端末装置１６等に、映像コンテンツを供給できるようにしてもよい。その場合、撮像装置１４は、転送時間を短縮するために（転送処理の負荷を軽減するために）、撮像により得られた画像データの代わりに、その画像データに対応する、データ量の小さいローレゾデータを供給するようにするのが望ましい。
【００３１】
なお、撮像装置１４によるローレゾデータの転送処理は、どのようなタイミングで行うようにしてもよく、撮像処理と並行して行うようにしてもよいし、撮像処理の終了後に一括して行うようにしてもよい。
【００３２】
このように、光ディスク１７の搬送に先駆けて、ローレゾデータを転送することにより、編集部署は、搬送された光ディスク１７が到着していなくても、比較的早い段階で（例えば、撮像処理と同時並行して）、編集作業を行うことができるので、映像プログラムの制作効率を高めることができる。なお、上述のように、ローレゾデータがネットワーク１２を介して伝送される場合、撮像装置１４は、たとえば、オリジナルの画像データや音声データのみを光ディスク１７に記録するようにしてもよい（ローレゾデータを光ディスク１７に記録しないようにしてもよい）。
【００３３】
なお、撮像装置１４が映像コンテンツ等を記録する記録媒体としては、例えば、ＭＤ（Ｍｉｎｉ−Ｄｉｓｃ）（登録商標）やＭＯ（Ｍａｇｎｅｔｏ Ｏｐｔｉｃａｌ ｄｉｓｋ）を含む光ディスクであってもよい。また、撮像装置１４が映像コンテンツ等を記録する記録媒体としては、上述した光ディスク１７の例に限定されず、どのような記録媒体であってもよく、例えば、フレキシブルディスクを含む磁気ディスク、ＤＶ（Ｄｉｇｉｔａｌ Ｖｉｄｅｏ）やＶＨＳ（Ｖｉｄｅｏ Ｈｏｍｅ Ｓｙｓｔｅｍ）に用いられる磁気テープ、フラッシュメモリ等を含む半導体メモリ等であってもよい。
【００３４】
フィールドＰＣ１５は、例えば、ノート型パーソナルコンピュータやＰＤＡ等の携帯可能な情報処理装置および周辺装置などで構成される。このフィールドＰＣ１５は、撮像装置１４と各種の有線または無線回線等により接続されており、例えば、構成表メタデータや映像コンテンツなどを撮像装置１４と共有することができる。
【００３５】
このフィールドＰＣ１５は、例えば、ネットワーク１２を介して、企画用端末装置１０から構成表メタデータを取得したり、撮像装置１４から構成表メタデータを取得したりする。フィールドＰＣ１５は、取得した構成表メタデータを所定の表示部に表示し、取材部署担当者に取材、撮影すべき内容を認識させる。
【００３６】
さらに、フィールドＰＣ１５は、ユーザである取材部署担当者の入力に基づいて、取材・撮影状況に関する情報である撮影状況情報を生成し、生成した撮影状況情報を構成表メタデータ内の該当欄に追加する。この撮影状況情報は、例えば、テイクごとや取材場所ごとに多様な観点で記載されたテキストデータ等であり、後段の編集処理時に有用となる情報である。このように、フィールドＰＣ１５は、撮影状況情報を書き込むことにより、構成表メタデータを編集する。また、フィールドＰＣ１５は、撮影状況情報をメタデータとして撮像装置１４に供給し、撮像装置１４において得られた画像データや音声データに付加させる。
【００３７】
編集用端末装置１６は、例えば、パーソナルコンピュータ等の情報処理装置および周辺装置により構成され、映像コンテンツの編集処理を行う編集部署に設けられる。編集部署は、企画構成部署による制作指示やシナリオ、取材部署における取材状況を反映した構成表メタデータ等に基づいて、撮像装置１４により得られた画像データや音声データを編集し、映像プログラムを完成させる部署である。
【００３８】
編集用端末装置１６は、例えば、撮像装置１４から、ネットワーク１２を介して、構成表メタデータやローレゾデータを取得する。また、編集用端末装置１６は、撮像装置１４において画像データや音声データが記録された光ディスク１７より、オリジナルの画像データや音声データを取得する。さらに、編集用端末装置１６は、企画用端末装置１１またはフィールドＰＣ１５等より、ネットワーク１２を介して、直接制作指示（編集に関する指示）を取得することも可能である。
【００３９】
編集用端末装置１６は、以上のように取得した構成表メタデータに基づいて、取得した映像コンテンツデータを好適に再生して表示する。例えば、編集用端末装置１６は、ユーザに操作され、ネットワーク１２を介して取得したローレゾデータや、光ディスク１７に記録されているオリジナルの画像データや音声データを、シナリオに従った順序で連続的に表示したり、所望のクリップの画像データのみを表示したりする。なお、光ディスク１７に記録されているオリジナルの画像データを再生する場合、編集用端末装置１６は、例えば、光ディスク１７に記録されているデータを読み出したり、光ディスク１７にデータを書き込んだりする記録再生装置であるディスク装置等を利用する。
【００４０】
また、編集用端末装置１６は、例えば、構成表メタデータに基づいて必要な画像データ等を好適な順序で再生し、表示するだけでなく、取材により得られた画像データ等の編集処理を行う。この編集処理としては、粗編集処理と本編集処理がある。
【００４１】
粗編集処理は、画像データや音声データに対する簡易的な編集処理である。例えば、編集用端末装置１６は、粗編集処理において、例えば、１回の撮像処理を示す単位であるクリップに対応する、画像データや音声データ等を含む映像コンテンツに関するデータ（以下、クリップデータと称する）を複数取得した場合に、それらのクリップデータの中から、本編集で使用すべきクリップデータを選択し、選択されたクリップデータの中から、さらに必要な映像部分を選択（Ｌｏｇｇｉｎｇ）し、その選択された映像部分に対応する編集開始位置（Ｉｎ点）および編集終了位置（Ｏｕｔ点）を例えば、タイムコード等を利用して設定し、上述したクリップデータの中から、対応する部分を抽出（Ｉｎｇｅｓｔｉｎｇ）する。
【００４２】
なお、クリップは、１回の撮像処理だけでなく、その撮像処理の撮像開始から撮像終了までの時間を示す単位でもあり、その撮像処理により得られた各種のデータの長さを示す単位でもあり、その撮像処理により得られた各種のデータのデータ量を示す単位でもある。さらに、クリップは、その各種のデータの集合体そのものも示す場合もある。
【００４３】
本編集処理は、粗編集処理が施された各クリップデータを繋ぎ合わせ、その画像データに対して、最終的な画質調整等を行い、番組などで放送するためのデータである完全パッケージデータを作成する処理である。
【００４４】
なお、上述した企画用端末装置１１、撮像装置１４、フィールドＰＣ１５、編集用端末装置１６等の各装置は、それぞれ、複数台により構成されるようにしてもよい。例えば、複数台の撮像装置１４において得られた画像データ等を、１台の編集用端末装置１６が光ディスク１７やネットワーク１２を介して取得し、そのデータに対して編集処理を行うようにしてもよいし、１台の撮像装置１４より供給されたデータが、複数台の編集用端末装置１６により編集されるようにしてもよい。
【００４５】
逆に、上述した企画用端末装置１１、撮像装置１４、フィールドＰＣ１５、および編集用端末装置１６等の各装置は、それぞれ、別体として構成されるように説明したが、これに限らず、各装置の機能の一部または全部が互いに一体化して構成されるようにしてもよい。
【００４６】
また、映像プログラム制作支援システム１は、例えば、上述した企画用端末装置１１、撮像装置１４、フィールドＰＣ１５、および編集用端末装置１６とは別に、ネットワーク１２に接続されたセンタサーバ（図示せず）を設け、企画用端末装置１１、撮像装置１４、フィールドＰＣ１５、および編集用端末装置１６等をクライアントとした、クライアント／サーバ（Ｃｌｉｅｎｔ／Ｓｅｒｖｅｒ）システムとして構成するようにしてもよい。
【００４７】
図２は、図１の編集用端末装置１６の詳細な構成例を示している。
【００４８】
図２において、編集用端末装置１６のＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）５１は、ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）５２に記憶されているプログラムに従って各種の処理を実行する。ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）５３には、ＣＰＵ５１が各種の処理を実行する上において必要なデータやプログラムなどが適宜記憶される。
【００４９】
クリップデータ編集部５４は、出力部６２を制御してディスプレイ等にＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示させ、入力部６１を介してユーザからの操作入力を受け付け、その操作入力等に基づいて、ドライブ６５に装着された光ディスク１７に記録されている画像データ、音声データ、ローレゾデータ、またはメタデータ等、または、通信部６４を介して取得したローレゾデータ等に対して、編集処理を行い、編集内容に関する情報や、編集後のデータに関する情報等を生成し、エディットリスト編集部５５に供給する。なお、クリップデータ編集部５４は、編集対象となる各種のデータを更新せずに、非破壊的な編集処理を行う。
【００５０】
エディットリスト編集部５５は、クリップデータ編集部５４において行われる編集処理に伴って生成される各種の情報に基づいて、編集結果に関する情報であるエディットリストを生成し、記憶部６３に記憶させる。なお、その際、エディットリスト編集部５５は、後述するように、編集対象となるクリップの、リアルタイム性を要求されないメタデータであるクリップメタデータに基づいて、エディットリスト用のクリップメタデータであるエディットリスト用クリップメタデータを生成する。例えば、エディットリスト編集部５５は、編集対象となるクリップのクリップメタデータに含まれる変換テーブルに基づいて、編集後のクリップの画像データ等に対応するＬＴＣの不連続点と、そのフレーム番号との変換テーブルを生成し、エディットリスト用クリップメタデータとして記録する。
【００５１】
より詳細には、エディットリスト編集部５５は、ＵＭＩＤ編集部５５ａ、ＫＬＶデータ編集部５５ｂ、および、ＬＴＣ編集部５５ｃより構成されており、それぞれがクリップデータ編集部５４において行われるクリップデータの編集処理に伴って生成される各種の情報に基づいて、編集結果に関する情報であるエディットリストを生成し、記憶部６３に記憶させる。
【００５２】
なお、その際、エディットリスト編集部５５のＵＭＩＤ編集部５５ａ、ＫＬＶデータ編集部５５ｂ、および、ＬＴＣ編集部５５ｃは、後述するように、編集対象となるクリップの、リアルタイム性を要求されないメタデータであるクリップメタデータに基づいて、エディットリスト用のクリップメタデータであるエディットリスト用クリップメタデータを生成する。
【００５３】
例えば、ＵＭＩＤ編集部５５ａ、ＫＬＶデータ編集部５５ｂ、および、ＬＴＣ編集部５５ｃは、それぞれ編集対象となるクリップのクリップメタデータに含まれるＵＭＩＤ変換テーブル、ＫＬＶデータ変換テーブル、および、ＬＴＣ変換テーブル（例えば、後述する図３のクリップのクリップメタデータ９１に含まれるＵＭＩＤ変換テーブル９２、ＫＬＶデータ変換テーブル９３、および、ＬＴＣ変換テーブル９４）に基づいて、編集後のクリップの画像データ等に対応するＵＭＩＤ、ＫＬＶデータ、およびＬＴＣのそれぞれの不連続点と、そのフレーム番号との変換テーブルである、ＵＭＩＤ変換テーブル、ＫＬＶデータ変換テーブル、および、ＬＴＣ変換テーブル（例えば、後述する図３のＵＭＩＤ変換テーブル１１２−１乃至１１２−３、ＫＬＶデータ変換テーブル１１３−１乃至１１３−３、および、ＬＴＣ変換テーブル１１４−１乃至１１４−３）を生成し、エディットリスト用クリップメタデータ（例えば、後述する図３のクリップメタデータ１１１−１乃至１１１−３）として記録する。
【００５４】
ＣＰＵ５１、ＲＯＭ５２、ＲＡＭ５３、クリップデータ編集部５４、およびエディットリスト編集部５５は、バス５６を介して相互に接続されている。このバス５６にはまた、入出力インタフェース６０も接続されている。
【００５５】
入出力インタフェース６０は、キーボードやマウスから構成される入力部６１が接続され、入力部６１に入力された信号をＣＰＵ５１に出力する。また、入出力インタフェース６０には、ディスプレイやスピーカなどから構成される出力部６２も接続されている。
【００５６】
さらに、入出力インタフェース６０には、ハードディスクやＥＥＰＲＯＭ（Ｅｌｅｃｔｒｏｎｉｃａｌｌｙ Ｅｒａｓａｂｌｅ ａｎｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）などから構成される記憶部６３、および、ネットワーク１２などを介して他の装置とデータの通信を行う通信部６４も接続されている。ドライブ６５は、磁気ディスク、光ディスク、光磁気ディスク、または半導体メモリなどの記録媒体からなるリムーバブルメディア７１よりデータを読み出したり、データを書き込んだりするときに用いられる。
【００５７】
次に、このような編集用端末装置１６が編集処理において用いる、光ディスク１７、および光ディスク１７に記録されたデータの構成例について説明する。
【００５８】
光ディスク１７は、例えば、ＤＶＤ−ＲＡＭ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ−Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ），ＤＶＤ−Ｒ（ＤＶＤ−Ｒｅｃｏｒｄａｂｌｅ），ＤＶＤ−ＲＷ（ＤＶＤ−ＲｅＷｒｉｔａｂｌｅ），ＤＶＤ＋Ｒ（ＤＶＤ＋Ｒｅｃｏｒｄａｂｌｅ），ＤＶＤ＋ＲＷ（ＤＶＤ＋ＲｅＷｒｉｔａｂｌｅ），ＣＤ−Ｒ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅｃｏｒｄａｂｌｅ），またはＣＤ−ＲＷ（ＣＤ−ＲｅＷｒｉｔａｂｌｅ）等が適用できる。
【００５９】
上述したように、記録媒体である光ディスク１７には、撮像装置１４により、画像データや音声データ等からなる複数のクリップデータが、例えば、図３Ａのように記録されている。
【００６０】
図３Ａにおいて、光ディスク１７には、撮像装置１４により得られた所定の時間単位（例えば２秒）に対応する音声年輪データ８１、画像年輪データ８２、ローレゾ年輪データ８３、およびフレームメタ年輪データ８４により構成される年輪データ８０が、１クリップ分連続して記録され、最後の年輪データ８０に続いて、そのクリップに対応するクリップメタデータ９１が記録され、さらに、その後に他のクリップに対応する年輪データやクリップメタデータ等が記録される。
【００６１】
音声年輪データ８１および画像年輪データ８２は、互いに再生時間が同一のデータであり、互いに対応するデータである。すなわち、音声年輪データ８１は、画像年輪データ８２が再生された動画像に対応する音声データである。また、ローレゾ年輪データ８３は、画像年輪データ８２に対応するデータであり、画像年輪データ８２と同一の再生時間のデータである。すなわち、ローレゾ年輪データ８３は、画像年輪データ８２が再生された動画像の画像サイズを縮小した、小画像サイズの動画像に対応する。フレームメタ年輪データ８４は、画像年輪データ８２に対応する動画像の各フレーム（１画面分の画像データ）に付加されたメタデータ（以下、フレームメタデータと称する）により構成される。すなわち、フレームメタ年輪データは、画像年輪データ８２の全フレームに対応する複数のフレームメタデータにより構成される。
【００６２】
なお、フレームメタデータは、付加されたフレームに対応するデータであり、画像信号の再生時等においてリアルタイム性を要求されるデータである。すなわち、フレームメタデータとしては、例えば、そのフレームに対応する画像信号を日時（年、月、日、時、分、秒）等の所定の時間情報により特徴付けるタイムコードであるＬＴＣ（Ｌｉｎｅａｒ Ｔｉｍｅ Ｃｏｄｅ）や、そのフレームの画像信号の信号特性を示すユーザビット（ＵＢ：Ｕｓｅｒ Ｂｉｔ）、ＵＭＩＤ（Ｕｎｉｑｕｅ Ｍａｔｅｒｉａｌ Ｉｄｅｎｔｉｆｉｅｒ）、ビデオカメラによる撮像が行われた位置を表すＧＰＳ（Ｇｌｏｂａｌ Ｐｏｓｉｔｉｏｎｉｎｇ Ｓｙｓｔｅｍ）の情報、画像信号や音声信号等のエッセンスデータの内容に関する情報であるエッセンスマーク、ＡＲＩＢ（Ａｓｓｏｃｉａｔｉｏｎ ｏｆ Ｒａｄｉｏ Ｉｎｄｕｓｔｒｉｅｓ ａｎｄ Ｂｕｓｉｎｅｓｓｅｓ）メタデータ、撮像が行われたビデオカメラの設定／制御情報などがある。なお、ＡＲＩＢメタデータとは、ＡＲＩＢで標準化され、ＳＤＩ（Ｓｅｒｉａｌ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ）等の標準の通信インタフェースに重畳されるメタデータである。また、ビデオカメラの設定／制御情報とは、例えば、ＩＲＩＳ（アイリス）制御値や、ホワイトバランス／ブラックバランスのモード、レンズのズームやフォーカスなどに関するレンズ情報などである。
【００６３】
従って、フレームメタ年輪データ８４には、実際の時刻（リアルタイム）や、所定の時刻を基準とするリアルタイムとは独立した時刻を利用した、フレームの時刻情報であるＬＴＣ８５が含まれている。このＬＴＣ８５は、各フレームに付加されたＬＴＣの集合であり、同じ年輪データ８０に含まれる画像年輪データ８２の、全てのフレームに対応するＬＴＣが含まれており、音声年輪データ８１や画像年輪データ８２の再生時に、それらとともに再生される。
【００６４】
光ディスク１７は、螺旋状または同心円状に、その内周側から外周側の方向に、データが記録されていく。従って、光ディスク１７において、同一の再生時間に対応する音声データ８１および画像データ８２、並びに、それらに対応するローレゾデータ８３およびフレームメタデータ８４からなる年輪データ８０が、撮像して得られた順番に記録されていくことにより、互いに対応する各データは、光ディスク１７の物理的に近傍の位置に記録（配置）される。このように光ディスク１７は、データ再生の際（読み出し処理の際）に、シーク時間を減らすことができ、処理時間および処理に必要な負荷を軽減させることができるようになっている。
【００６５】
このように１クリップ分記録された複数の年輪データ８０に続いて、クリップメタデータ９１が記録される。
【００６６】
クリップメタデータ９１としては、付加されたクリップ全体に対応するデータであり、画像信号の再生時等においてリアルタイム性を要求されないデータである。すなわち、クリップメタデータとしては、例えば、各フレームに対応するＬＴＣをフレーム番号に対応させた変換テーブル９２があり、さらに、ＵＭＩＤ、ＧＰＳの情報、またはその他の情報などがある。クリップメタデータ９１は、主に、音声データや画像データの編集時、または、検索時等において利用されるデータであり、通常、画像データ等の再生時には必要としない種類のデータにより構成される。
【００６７】
なお、フレームメタデータおよびクリップメタデータとして、上述した以外のデータを含めるようにしてもよい。また、フレームメタデータとクリップメタデータで同じ内容のデータを含めるようにしてもよいし、上述したフレームメタデータとしての各データをクリップメタデータとしてもよいし、逆に、クリップメタデータとして上述した各データをフレームメタデータとしてもよい。例えば、エッセンスマーク、ＡＲＩＢメタデータ、または、ビデオカメラの設定／制御情報等をクリップメタデータとしてもよいし、フレームメタデータおよびクリップメタデータの両方に含めるようにしてもよい。また、ＵＭＩＤやＧＰＳの情報等をフレームメタデータに含めるようにしてもよいし、フレームメタデータおよびクリップメタデータの両方に含めるようにしてもよい。
【００６８】
また、クリップメタデータ９１には、図３Ａで示されるように、ＵＭＩＤ変換テーブル９２、ＫＬＶデータ変換テーブル９３、および、ＬＴＣ変換テーブル９４が含まれている。
【００６９】
ＵＭＩＤ変換テーブル９２は、最初の年輪データ、または、１つ前に記録されたクリップメタデータの次に記録された年輪データから、直前に記録された年輪データに含まれるＵＭＩＤに対応するテーブルである。従って、ＵＭＩＤ変換テーブル９２は、ＵＭＩＤ変換テーブル９２が対応する音声年輪データ８１および画像年輪データ８２の、ある程度（後述する図３Ｂの場合と比較して、）近傍に記録されることになる。クリップメタデータ８１に含まれるメタデータは、基本的にリアルタイム性を要求されないメタデータであるが、例えば、ユーザがＵＭＩＤ変換テーブル９２を用いて特定のフレームの再生を指示する場合、再生する音声年輪データ８１および画像年輪データ８２がＵＭＩＤ変換テーブル９２の近傍に記録されている方が、シーク時間を短縮することができ、音声年輪データ８１および画像年輪データ８２の読み込み速度を向上させることができ、好適である。
【００７０】
ＫＬＶデータ変換テーブル９３は、最初の年輪データ、または、１つ前に記録されたクリップメタデータの次に記録された年輪データから、直前に記録された年輪データに含まれるＫＬＶデータに対応するテーブルである。従って、ＫＬＶデータ変換テーブル９３は、ＫＬＶ変換テーブル９３が対応する音声年輪データ８１および画像年輪データ８２の、ある程度（後述する図３Ｂの場合と比較して、）近傍に記録されることになる。クリップメタデータ８１に含まれるメタデータは、基本的にリアルタイム性を要求されないメタデータであるが、例えば、ユーザがＫＬＶデータ変換テーブル９３を用いて特定のフレームの再生を指示する場合、再生する音声年輪データ８１および画像年輪データ８２がＫＬＶデータ変換テーブル９３の近傍に記録されている方が、シーク時間を短縮することができ、音声年輪データ８１および画像年輪データ８２の読み込み速度を向上させることができ、好適である。
【００７１】
ＬＴＣ変換テーブル９４は、最初の年輪データ、または、１つ前に記録されたクリップメタデータの次に記録された年輪データから、直前に記録された年輪データに含まれるＬＴＣに対応するテーブルである。従って、ＬＴＣ変換テーブル９４は、ＬＴＣ変換テーブル９４が対応する音声年輪データ８１および画像年輪データ８２の、ある程度（後述する図３Ｂの場合と比較して、）近傍に記録されることになる。クリップメタデータ８１に含まれるメタデータは、基本的にリアルタイム性を要求されないメタデータであるが、例えば、ユーザがＬＴＣ変換テーブル９４を用いて特定のフレームの再生を指示する場合、再生する音声年輪データ８１および画像年輪データ８２がＬＴＣ変換テーブル９４の近傍に記録されている方が、シーク時間を短縮することができ、音声年輪データ８１および画像年輪データ８２の読み込み速度を向上させることができ、好適である。
【００７２】
なお、クリップメタデータは、例えば、図３Ｂに示されるように、年輪データが記憶される領域とは別の領域にまとめて記録されるようにしてもよい。図３Ｂの場合、音声年輪データ１０１−１、画像年輪データ１０２−１、ローレゾ年輪データ１０３−１、およびフレームメタ年輪データ１０４−１からなる年輪データ１００−１、音声年輪データ１０１−２、画像年輪データ１０２−２、ローレゾ年輪データ１０３−２、およびフレームメタ年輪データ１０４−２からなる年輪データ１００−２のように、年輪データが記録される領域と別の領域に、クリップメタデータ１１１−１、クリップメタデータ１１１−２、クリップメタデータ１１１−３のように、クリップメタデータがまとめて記録される。
【００７３】
クリップメタ−データ１１１−１乃至１１１−３には、それぞれ、ＵＭＩＤ変換テーブル９２−１乃至９２−３、ＫＬＶデータ変換テーブル９３−１乃至９３−３、および、ＬＴＣ変換テーブル９４−１乃至９４−３のいずれかが含まれている。
【００７４】
ＵＭＩＤ変換テーブル１１２−１乃至１１２−３は、対応するフレームメタ年輪データに含まれるＵＭＩＤの開始点、変化点、および終了点（すなわち、ＵＭＩＤの値が、直前のフレーム（または直後のフレーム）のＵＭＩＤの値と不連続になるフレーム（ＵＭＩＤの場合、必ずしも連続した値とならないが、異なる画像のフレームとして切り替わる部分の値をここでは、ＵＭＩＤの値の不連続点のフレームとする））が登録されている。なお、ＵＭＩＤ変換テーブル１１２−１乃至１１２−３は、これらに限らず、例えば、所定のフレーム間隔ごとにＵＭＩＤを登録するようにしてもよい。ＵＭＩＤ変換テーブルは、登録したＵＭＩＤの数が多いほど、フレームの検索時に、要求されたフレームのフレーム番号を算出する時間を短縮することができるが、ＵＭＩＤ変換テーブル１１２−１乃至１１２−３のデータサイズが増大し、全体の検索処理時間が延びてしまう場合もある。従って、適度なサイズとなるように、ＵＭＩＤ変換テーブルに用いるＵＭＩＤを選択するようにするのが望ましい。
【００７５】
ＫＬＶデータ変換テーブル１１３−１乃至１１３−３は、対応するフレームメタ年輪データに含まれるＫＬＶデータの開始点、変化点、および終了点（すなわち、ＫＬＶデータの値が、直前のフレーム（または直後のフレーム）のＫＬＶデータの値と不連続になるフレーム）が登録されている。なお、ＫＬＶデータ変換テーブル１１３−１乃至１１３−３は、これらに限らず、例えば、所定のフレーム間隔ごとにＫＬＶデータを登録するようにしてもよい。ＫＬＶデータ変換テーブルは、登録したＫＬＶデータの数が多いほど、フレームの検索時に、要求されたフレームのフレーム番号を算出する時間を短縮することができるが、ＫＬＶデータ変換テーブル１１３−１乃至１１３−３のデータサイズが増大し、全体の検索処理時間が延びてしまう場合もある。従って、適度なサイズとなるように、ＫＬＶデータ変換テーブルに用いるＫＬＶデータを選択するようにするのが望ましい。
【００７６】
ＬＴＣ変換テーブル１１４−１乃至１１４−３は、対応するフレームメタ年輪データに含まれるＬＴＣの開始点、変化点、および終了点（すなわち、ＬＴＣの値が、直前のフレーム（または直後のフレーム）のＬＴＣの値と不連続になるフレーム）が登録されている。なお、ＬＴＣ変換テーブル１１４−１乃至１１４−３は、これらに限らず、例えば、所定の間隔ごとにＬＴＣを登録するようにしてもよい。変換テーブルは、登録したＬＴＣの数が多いほど、フレームの検索時に、要求されたフレームのフレーム番号を算出する時間を短縮することができるが、ＬＴＣ変換テーブル１１４−１乃至１１４−３のデータサイズが増大し、全体の検索処理時間が延びてしまう場合もある。従って、適度なサイズとなるように、ＬＴＣ変換テーブルに用いるＬＴＣを選択するようにするのが望ましい。
【００７７】
図３Ｂの場合、クリップメタデータは、音声データ記録タスク、画像データ記録タスク、ローレゾデータ記録タスク、およびフレームメタデータ記録タスクが終了した後に、年輪データとは別の領域に記録される。
【００７８】
従って、クリップメタデータ１１１−１乃至１１１−３にそれぞれ含まれるＵＭＩＤ変換テーブル１１２−１乃至１１２−３、ＫＬＶデータ変換テーブル１１３−１乃至１１３−３、および、ＬＴＣ変換テーブル１１４−１乃至１１４−３は、それぞれ互いの近傍に記録されることになる。従って、ＵＭＩＤ変換テーブル１１２−１乃至１１２−３、ＫＬＶデータ変換テーブル１１３−１乃至１１３−３、および、ＬＴＣ変換テーブル１１４−１乃至１１４−３のそれぞれについて、複数の変換テーブルを用いて特定のフレームを検索する場合、シーク時間を短縮することができ、目的のフレームを高速に検索することができる。
【００７９】
また、音声データや画像データを再生する場合、それらのデータの間に、再生に不必要なクリップメタデータが存在しないので、読み出し時間を短縮することができ、再生処理を高速化することができる。
【００８０】
さらに、クリップメタデータは、リアルタイム性を要求されないメタデータで構成されており、通常、シーク時間を考慮しなければならないということはないので、光ディスク１７の記憶領域の物理的な位置において、どのような位置に配置してもよく、例えば、１つのクリップメタデータを複数の位置に分散して記録するようにしてもよい。
【００８１】
以上のように、音声データや画像データ等からなるエッセンスデータとともに、ＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣをフレームメタデータとして記録し、さらに、ＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣの開始点、変化点、および終了点等からなるＵＭＩＤ変換テーブル、ＫＬＶデータ変換テーブル、および、ＬＴＣ変換テーブルをクリップメタデータとして記録するようにしているので、上述した光ディスク１７に記録されたデータを編集する場合、ユーザは、ＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣに基づいて、容易に編集処理を行うことができるとともに、ＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣより目的のフレームを検索し、再生させることもできる。
【００８２】
次に、光ディスク１７に記録された各データを管理するファイルシステム、並びにファイルシステムにおけるディレクトリ構造およびファイルについて説明する。
【００８３】
光ディスク１７に記録されたデータを管理するファイルシステムとしては、どのようなファイルシステムを用いてもよく、例えば、ＵＤＦ（Ｕｎｉｖｅｒｓａｌ Ｄｉｓｋ Ｆｏｒｍａｔ）やＩＳＯ９６６０（Ｉｎｔｅｒｎａｔｉｏｎａｌ Ｏｒｇａｎｉｚａｔｉｏｎ ｆｏｒ Ｓｔａｎｄａｒｄｉｚａｔｉｏｎ ９６６０）等を用いてもよい。また、光ディスク１７の代わりにハードディスク等の磁気ディスクを用いた場合、ファイルシステムとして、ＦＡＴ（Ｆｉｌｅ Ａｌｌｏｃａｔｉｏｎ Ｔａｂｌｅｓ）、ＮＴＦＳ（Ｎｅｗ Ｔｅｃｈｎｏｌｏｇｙ Ｆｉｌｅ Ｓｙｓｔｅｍ）、ＨＦＳ（Ｈｉｅｒａｒｃｈｉｃａｌ Ｆｉｌｅ Ｓｙｓｔｅｍ）、またはＵＦＳ（Ｕｎｉｘ（登録商標） Ｆｉｌｅ Ｓｙｓｔｅｍ）等を用いてもよい。また、専用のファイルシステムを用いるようにしてもよい。
【００８４】
このファイルシステムにおいては、光ディスク１７に記録されたデータは図４に示されるようなディレクトリ構造およびファイルにより管理される。
【００８５】
図４において、ルートディレクトリ（ＲＯＯＴ）１３１には、画像データや音声データ等のエッセンスデータに関する情報、および、エッセンスデータの編集結果を示すエディットリスト等が、下位のディレクトリに配置されるＰＲＯＡＶディレクトリ１３２が設けられる。なお、ルートディレクトリ１３１には、図示は省略するが、構成表データ等も設けられる。
【００８６】
ＰＲＯＡＶディレクトリ１３２には、光ディスク１７に記録されている全てのエッセンスデータに対するタイトルやコメント、さらに、光ディスク１７に記録されている全ての画像データの代表となるフレームである代表画に対応する画像データのパス等の情報を含むファイルであるディスクメタファイル（ＤＩＳＣＭＥＴＡ．ＸＭＬ）１３３、光ディスク１７に記録されている全てのクリップおよびエディットリストを管理するための管理情報等を含むインデックスファイル（ＩＮＤＥＸ．ＸＭＬ）１３４、およびインデックスファイル（ＩＮＤＥＸ．ＢＵＰ）１３５が設けられている。なお、インデックスファイル１３５は、インデックスファイル１３４を複製したものであり、２つのファイルを用意することにより、信頼性の向上が図られている。
【００８７】
ＰＲＯＡＶディレクトリ１３２には、さらに、光ディスク１７に記録されているデータ全体に対するメタデータであり、例えば、ディスク属性、再生開始位置、またはＲｅｃｌｎｈｉ等の情報を含むファイルであるディスクインフォメーションファイル（ＤＩＳＣＩＮＦＯ．ＸＭＬ）１３６およびディスクインフォメーションファイル（ＤＩＳＫＩＮＦＯ．ＢＵＰ）１３７が設けられている。なお、ディスクインフォメーションファイル１３７は、ディスクインフォメーションファイル１３６を複製したものであり、２つのファイルを用意することにより、信頼性の向上が図られている。ただし、これらの情報を更新する場合、ディスクインフォメーションファイル１３６のみを更新するようにしてもよい。
【００８８】
また、ＰＲＯＡＶディレクトリ１３２には、上述したファイル以外にも、クリップのデータが下位のディレクトリに設けられるクリップルートディレクトリ（ＣＬＰＲ）１３８、および、エディットリストのデータが下位のディレクトリに設けられるエディットリストルートディレクトリ（ＥＤＴＲ）１３９が設けられる。
【００８９】
クリップルートディレクトリ１３８には、光ディスク１７に記録されているクリップのデータが、クリップ毎に異なるディレクトリに分けて管理されており、例えば、図４の場合、３つのクリップのデータが、クリップディレクトリ（Ｃ０００１）１４１、クリップディレクトリ（Ｃ０００２）１４２、および、クリップディレクトリ（Ｃ０００３）１４３の３つのディレクトリに分けられて管理されている。すなわち、光ディスク１７に記録された最初のクリップの各データは、クリップディレクトリ１４１の下位のディレクトリのファイルとして管理され、２番目に光ディスク１７に記録されたクリップの各データは、クリップディレクトリ１４２の下位のディレクトリのファイルとして管理され、３番目に光ディスク１７に記録されたクリップの各データは、クリップディレクトリ１４３の下位のディレクトリのファイルとして管理される。
【００９０】
また、エディットリストルートディレクトリ１３９には、光ディスク１７に記録されているエディットリストが、その編集処理毎に異なるディレクトリに分けて管理されており、例えば、図４の場合、４つのエディットリストが、エディットリストディレクトリ（Ｅ０００１）１４４、エディットリストディレクトリ（Ｅ０００２）１４５、エディットリストディレクトリ（Ｅ０００３）１４６、およびエディットリストディレクトリ（Ｅ０００４）１４７の４つのディレクトリに分けて管理されている。すなわち、光ディスク１７に記録されたクリップの１回目の編集結果を示すエディットリストは、エディットリストディレクトリ１４４の下位のディレクトリのファイルとして管理され、２回目の編集結果を示すエディットリストは、エディットリストディレクトリ１４５の下位のディレクトリのファイルとして管理され、３回目の編集結果を示すエディットリストは、エディットリストディレクトリ１４６の下位のディレクトリのファイルとして管理され、４回目の編集結果を示すエディットリストは、エディットリストディレクトリ１４７の下位のディレクトリのファイルとして管理される。
【００９１】
上述したクリップルートディレクトリ１３８に設けられるクリップディレクトリ１４１の下位のディレクトリには、最初に光ディスク１７に記録されたクリップの各データが、図５に示されるようなファイルとして設けられ、管理される。
【００９２】
図５の場合、クリップディレクトリ１４１には、このクリップを管理するファイルであるクリップインフォメーションファイル（Ｃ０００１Ｃ０１．ＳＭＩ）１５１、このクリップの画像データを含むファイルである画像データファイル（Ｃ０００１Ｖ０１．ＭＸＦ）１５２、それぞれ、このクリップの各チャンネルの音声データを含む８つのファイルである音声データファイル（Ｃ０００１Ａ０１．ＭＸＦ乃至Ｃ０００１Ａ０８．ＭＸＦ）１５３乃至１６０、このクリップの画像データに対応するローレゾデータを含むファイルであるローレゾデータファイル（Ｃ０００１Ｓ０１．ＭＸＦ）１６１、このクリップのエッセンスデータに対応する、例えば、ＬＴＣとフレーム番号を対応させる変換テーブル等の、リアルタイム性を要求されないメタデータであるクリップメタデータを含むファイルであるクリップメタデータファイル（Ｃ０００１Ｍ０１．ＸＭＬ）１６２、このクリップのエッセンスデータに対応する、例えばＬＴＣ等の、リアルタイム性を要求されるメタデータであるフレームメタデータを含むファイルであるフレームメタデータファイル（Ｃ０００１Ｒ０１．ＢＩＭ）１６３、並びに、画像データファイル１５２のフレーム構造（例えば、ＭＰＥＧ等におけるピクチャ毎の圧縮形式に関する情報や、ファイルの先頭からのオフセットアドレス等の情報）が記述されたファイルであるピクチャポインタファイル（Ｃ０００１Ｉ０１．ＰＰＦ）１６４等のファイルが設けられる。
【００９３】
図５の場合、再生時にリアルタイム性を要求されるデータである、画像データ、ローレゾデータ、およびフレームメタデータは、それぞれ１つのファイルとして管理され、読み出し時間が増加しないようになされている。
【００９４】
また、音声データも、再生時にリアルタイム性を要求されるが、７．１チャンネル等のような音声の多チャンネル化に対応するために、８チャンネル用意され、それぞれ、異なるファイルとして管理されている。すなわち、音声データは８つのファイルとして管理されるように説明したが、これに限らず、音声データに対応するファイルは、７つ以下であってもよいし、９つ以上であってもよい。
【００９５】
同様に、画像データ、ローレゾデータ、およびフレームメタデータも、場合によって、それぞれ、２つ以上のファイルとして管理されるようにしてもよい。
【００９６】
また、図５において、リアルタイム性を要求されないクリップメタデータは、リアルタイム性を要求されるフレームメタデータと異なるファイルとして管理される。これは、画像データ等の通常の再生中に必要の無いメタデータを読み出さないようにするためであり、このようにすることにより、再生処理の処理時間や、処理に必要な負荷を軽減することができる。
【００９７】
なお、クリップメタデータファイル１６２は、汎用性を持たせるためにＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）形式で記述されているが、フレームメタデータファイル１６３は、再生処理の処理時間や処理に必要な負荷を軽減させるために、ＸＭＬ形式のファイルをコンパイルしたＢＩＭ形式のファイルである。
【００９８】
図５に示されるクリップディレクトリ１４１のファイルの構成例は、光ディスク１７に記録されている各クリップに対応する全てのクリップディレクトリにおいて適用することができる。すなわち、図４に示される、その他のクリップディレクトリ１４２および１４３においても、図５に示されるファイルの構成例を適用することができるので、その説明を省略する。
【００９９】
以上において、１つのクリップに対応するクリップディレクトリに含まれる各ファイルについて説明したが、ファイルの構成は上述した例に限らず、各クリップディレクトリの下位のディレクトリに、そのクリップに対応するクリップメタデータファイルが存在すれば、どのような構成であってもよい。
【０１００】
次に、図４のエディットリストルートディレクトリ１３９の下位のディレクトリにおけるファイルの構成例について説明する。上述したエディットリストルートディレクトリ１３９に設けられるエディットリストディレクトリ１４５の下位のディレクトリには、光ディスク１７に記録されたクリップの各データの２回目の編集結果に関する情報であるエディットリストのデータが、図６に示されるようなファイルとして設けられ、管理される。
【０１０１】
図６の場合、エディットリストディレクトリ１４５には、この編集結果（エディットリスト）を管理するファイルであるエディットリストファイル（Ｅ０００２Ｅ０１．ＳＭＩ）１７１、この編集後のエッセンスデータ（編集に用いられた全クリップのエッセンスデータの内、編集後のデータとして抽出された部分）に対応するクリップメタデータ、または、そのクリップメタデータに基づいて新たに生成されたクリップメタデータを含むファイルであるエディットリスト用クリップメタデータファイル（Ｅ０００２Ｍ０１．ＸＭＬ）１７２、この編集結果（エディットリスト）に基づいた、エッセンスデータの再生手順（プレイリスト）等の情報を含むファイルであるプレイリストファイル（Ｅ０００２Ｐ０１．ＳＭＩ）１７３、プレイリストファイル１７３に含まれる再生手順に基づいて再生される画像データのフレーム構造（例えば、ＭＰＥＧ等におけるピクチャ毎の圧縮形式に関する情報や、ファイルの先頭からのオフセットアドレス等の情報）が記述されたファイルであるプレイリスト用ピクチャポインタファイル（Ｃ０００１Ｉ０１．ＰＰＦ）１７４、プレイリストファイル１７３の再生手順（プレイリスト）に基づいた実時間再生を保証するための画像データを含むファイルであるプレイリスト用画像データファイル（Ｂ０００２Ｖ０１．ＢＭＸ）１７５、プレイリストファイル１７３の再生手順（プレイリスト）に基づいた実時間再生を保証するための音声データを含む４つのファイルであるプレイリスト用音声データファイル（Ｂ０００２Ａ０１．ＢＭＸ乃至Ｂ０００２Ａ０４．ＢＭＸ）１７６乃至１７９、プレイリストファイル１７３の再生手順（プレイリスト）に基づいた実時間再生を保証するためのローレゾデータを含むファイルであるプレイリスト用ローレゾデータファイル（Ｂ０００２Ｓ０１．ＢＭＸ）１８０、並びに、プレイリストファイル１７３の再生手順（プレイリスト）に基づいた実時間再生を保証するためのフレームメタデータを含むファイルであるプレイリスト用フレームメタデータファイル（Ｂ０００２Ｒ０１．ＢＢＭ）１８１等のファイルが設けられる。
【０１０２】
図６において、リアルタイム性を要求されないクリップメタデータは、リアルタイム性を要求されるフレームメタデータと異なるファイルとして管理される。これは、再生手順（プレイリスト）を用いて画像データ等を再生中に（編集結果の再現中に）、必要の無いメタデータを読み出さないようにするためであり、このようにすることにより、再生処理の処理時間や、処理に必要な負荷を軽減することができる。
【０１０３】
エディットリスト用クリップメタデータファイル１７２は、後述するように、編集結果に基づいて、編集に使用されたクリップのクリップメタデータ（クリップルートディレクトリ１３８の下位のディレクトリに存在するクリップメタデータファイル）に基づいて生成された新たなクリップメタデータを含むファイルである。例えば、編集が行われると、図５のクリップメタデータファイル１６２に含まれるクリップメタデータから、編集後のエッセンスデータに対応する部分が抽出され、それらを用いて、編集後のエッセンスデータを１クリップとする新たなクリップメタデータが再構成され、エディットリスト用クリップメタデータファイルとして管理される。すなわち、編集後のエッセンスデータには、編集後のエッセンスデータを１クリップとする新たなクリップメタデータが付加され、そのクリップメタデータが１つのエディットリスト用クリップメタデータファイルとして管理される。従って、このエディットリスト用クリップメタデータファイルは、編集毎に生成される。
【０１０４】
なお、このエディットリスト用クリップメタデータファイル１７２は、汎用性を持たせるために、ＸＭＬ形式で記述される。
【０１０５】
プレイリスト用画像データファイル１７５に含まれる画像データ、プレイリスト用音声データファイル１７６乃至１７９に含まれる各音声データ、プレイリスト用ローレゾデータファイル１８０に含まれるローレゾデータ、並びに、プレイリスト用フレームメタデータファイル１８１に含まれるフレームメタデータは、それぞれ、図５のクリップルートディレクトリ１３８の下位のディレクトリにおいて管理されるクリップに対応する画像データ、音声データ、ローレゾデータ、およびフレームメタデータより抽出されたデータであり、編集結果に対応するデータである。これらのデータは、プレイリストファイル１７３に含まれる再生手順（プレイリスト）に基づいて再生処理が行われる場合に読み出される。このような編集結果に対応する各データが用意されることにより、プレイリストに基づいた再生処理において、読み出すファイルの数を減らすことができ、その処理時間および処理に必要な負荷を軽減させることができる。
【０１０６】
なお、画像データ、ローレゾデータ、およびフレームメタデータは、場合によって、それぞれ、複数のファイルとして管理されるようにしてもよい。同様に、音声データに対応するファイルの数は、３つ以下であってもよいし、５つ以上であってもよい。
【０１０７】
なお、プレイリスト用フレームメタデータファイル１８１は、再生処理の処理時間や処理に必要な負荷を軽減させるために、ＸＭＬ形式のファイルをコンパイルしたＢＩＭ形式に対応するＢＢＭ形式のファイルである。
【０１０８】
図６に示されるエディットリストディレクトリ１４５のファイルの構成例は、全てのエディットリスト（編集結果）において適用することができる。すなわち、図４に示される、その他のエディットリストディレクトリ１４４、１４６、または１４７においても、図６に示されるファイルの構成例を適用することができるので、その説明を省略する。
【０１０９】
以上において、１回の編集作業に対応するエディットリストディレクトリに含まれる各ファイルについて説明したが、ファイルの構成は上述した例に限らず、各エディットリストディレクトリの下位のディレクトリに、その編集に対応するエディットリスト用クリップメタデータファイルが存在すれば、どのような構成であってもよい。
【０１１０】
次に、クリップメタデータに含まれるデータについて説明する。クリップメタデータには、上述したように、ＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣとフレーム番号の変換テーブルの他に、ＧＰＳに関する情報、またはその他の情報が含まれる。これらの情報は、フレームメタデータにも記憶される場合もある規格化された情報であり、リアルタイム性を要求される場合もあるので、ＳＤＩ（Ｓｅｒｉａｌ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｆａｃｅ）等の標準インタフェースを用いた同期系の通信を保証するために、図７に示されるように、キーデータ（Ｋｅｙ）１９１、レングスデータ（Ｌｅｎｇｔｈ）１９２、および、バリューデータ（Ｖａｌｕｅ）１９３からなるＫＬＶ符号化されたデータ（以下、ＫＬＶデータと称する）である。このフォーマットは、ＳＭＰＴＥ ３３５Ｍ／ＲＰ２１４に準拠している。
【０１１１】
ＫＬＶデータ１９０のキーデータ１９１は、ＫＬＶ符号化されたデータ項目を示す識別子である。この識別子には、ＳＭＴＰＥのメタデータ辞書に定義された、各種のデータ項目に対応する識別子が用いられる。ＫＬＶデータ１９０のレングスデータ１９２は、バリューデータ１９３の長さをバイト単位で示すデータである。ＫＬＶデータ１９０のバリューデータ１９３は、ＸＭＬ（ｅＸｔｅｎｓｉｂｌｅ Ｍａｒｋｕｐ Ｌａｎｇｕａｇｅ）文書等のように、テキストデータ等のデータ本体からなるデータである。すなわち、ＫＬＶデータ１９０は、キーデータ１９１に示されるデータ項目のデータであり、レングスデータ１９２に示されるデータ長のデータであり、かつ、バリューデータ１９３に示されるデータを符号化したものである。
【０１１２】
このように、実際には、上述したＵＭＩＤ変換テーブル、ＫＬＶデータ変換テーブル、ＬＴＣ変換テーブル、およびＵＭＩＤもＫＬＶデータの１つであるが、以下において、説明を簡略化するために、クリップメタデータに含まれる各種の変換テーブルおよびＵＭＩＤ以外のメタデータ（ＫＬＶデータ）をＫＬＶデータと称する。
【０１１３】
なお、上述した符号化方法は１つの例であり、クリップメタデータに含まれる各情報は、ＫＬＶ符号化以外の方法により符号化されていてもよいし、符号化されていなくてもよい。
【０１１４】
次に、図８を参照して、ＵＭＩＤのフォーマットについて説明する。
【０１１５】
ＵＭＩＤには、基本ＵＭＩＤ（図８中のＢａｓｉｃ ＵＭＩＤ）と、拡張ＵＭＩＤ（図８中のＥｘｔｅｎｄｅｄ ＵＭＩＤ）の２種類のＵＭＩＤが存在する。尚、本明細書においては、拡張ＵＭＩＤはＥｘｔｅｎｄｅｄ ＵＭＩＤ、または、単にＵＭＩＤと称し、基本ＵＭＩＤは、基本ＵＭＩＤ、または、ＢａｓｉｃＵＭＩＤと称するものとする。
【０１１６】
図８で示されるように、ＵＭＩＤ（図８中では、Ｅｘｔｅｎｄｅｄ ＵＭＩＤ）は、６４バイト（ｂｙｔｅｓ）の情報であり、そのうちの先頭（図中の左）から３２バイトが基本ＵＭＩＤであり、残りの３２バイトがソースパック（Ｓｏｕｒｃｅ Ｐａｃｋ）である。
【０１１７】
基本ＵＭＩＤは、マテリアルＩＤ（Ｍａｔｅｒｉａｌ ＩＤ）として機能するものであり、ＵＭＩＤを識別するＩＤである。基本ＵＭＩＤは、固定ヘッダを示すＵｎｉｖｅｒｓａｌ Ｌａｂｅｌ（図中のＵｎｉｖ Ｌａｂｅｌ）、データ長を示すＬｅｎｇｔｈ（図中のＬで表示される部分）、インスタンス番号を示すＩｎｓｔａｎｃｅ Ｎｕｍｂｅｒ（図中のＩｎｓ．Ｎｏ．）、および、画像としての素材を識別するＭａｔｅｒｉａｌ Ｎｕｍｂｅｒ（図中のＭａｔ．Ｎｏ．）から構成される。これらは、先頭からそれぞれ、１２バイト、１バイト、３バイト、および、１６バイトのデータ長のデータとして記憶される。尚、ここでは、Ｕｎｉｖ Ｌａｂｅｌが、Ｋｅｙデータとして、ＬｅｎｇｔｈがＬｅｎｇｔｈデータとして、Ｉｎｓｔ．Ｎｏ．、および、Ｍａｔ．Ｎｏ．がＶａｌｕｅデータとして構成された、ＫＬＶデータとしての構造がなされている。
【０１１８】
また、ソースパックは、先頭から、日付、および、時刻を示すＷｈｅｎデータ（図中のＤａｔｅ／Ｔｉｍｅ）、Ａｌｔｉｔｕｄｅ（高さ）、Ｌａｔｉｔｕｄｅ（経度）、および、Ｌｏｎｇｉｔｕｄｅ（緯度）を示すＷｈｅｒｅデータ（図中のＡｌｔ．／Ｌａｔ．／Ｌｏｎｇ．）、および、撮影者を特定する情報であるＵｓｅｒ Ｉｎｆｏｍａｔｉｏｎを示すＷｈｏデータ（図中では、Ｕｓｅｒ Ｉｎｆｏ．）から構成されており、画像データがいつ（Ｗｈｅｎ）、どこで（Ｗｈｅｒｅ）、誰に（Ｗｈｏ）撮像されたものであるかを示す情報が含まれており、それぞれ、先頭から８バイト、１２バイト、および、１２バイトのデータとして記録されている。
【０１１９】
さらに、上述したＵＭＩＤ変換テーブルについては、Ｅｘｔｅｎｄｅｄ ＵＭＩＤの構造上、それぞれの構成要素毎の変換テーブルが設けられるようになっており、ＵＭＩＤ（Ｅｘｔｅｎｄｅｄ ＵＭＩＤ、および、Ｂａｓｉｃ ＵＭＩＤのそれぞれを含む）変換テーブル、Ｗｈｅｎ変換テーブル、Ｗｈｅｒｅ変換テーブル、および、Ｗｈｏ変換テーブルが含まれる。
【０１２０】
以上のように、図１の編集用端末装置１６は、光ディスク１７に記録されたエッセンスデータ（または、ネットワーク１２を介して供給されたエッセンスデータ）に対して編集処理を行う。その際、編集用端末装置１６は、編集対象となるクリップのエッセンスデータはそのままにして（加工せずに）、編集結果に関する情報であるエディットリストを生成する。
【０１２１】
このようにすることにより、編集用端末装置１６は、編集対象であるクリップのデータを残したまま、非破壊的に編集処理を行うことができる。従って、編集用端末装置１６は、容易に、何度でも編集を最初からやり直すことができるとともに、編集処理による画質の劣化を抑制することができる。
【０１２２】
また、編集用端末装置１６は、編集の際に、生成したエディットリスト（編集結果）に対応する、エディットリスト用クリップメタデータを生成し、保存する。これにより、編集用端末装置１６は、編集の際に編集対象であるクリップメタデータも残したまま、非破壊的に編集処理を行うことができる。また、複数のクリップを合成する編集処理の編集結果についてクリップメタデータを利用する場合、このようにすることにより、編集用端末装置１６は、編集前のクリップに対応する複数のクリップメタデータファイルを読み出さずに、１つのエディットリスト用クリップメタデータファイルを読み出すだけでよいので、その処理時間およびその処理に必要な負荷を軽減させることができる。
【０１２３】
さらに、編集用端末装置１６は、このエディットリスト用クリップメタデータを生成する場合、後述するように、編集結果の画像データに対して、編集結果を１つのクリップとした新たなＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣを付加することができる。すなわち、編集用端末装置１６は、画像データや音声データ等を編集するとともに、その画像データに対応するＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣも編集することができる。これにより、編集用端末装置１６は、複数のクリップを合成するなどして、ＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣの値の変動が複雑になることを避けることができる。
【０１２４】
この場合、編集用端末装置１６は、フレームメタデータに含まれるＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣを利用せずに（フレームメタデータを読み出さずに）、エディットリスト用クリップメタデータに含まれるＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣとフレーム番号の、それぞれの対応テーブルを用いて（エディットリスト用クリップメタデータを読み出して）、ＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣを算出しながら、プレイリストに基づいてエッセンスデータを再生して編集結果を再現するようにしてもよい。
【０１２５】
なお、編集用端末装置１６は、後述するように、エディットリスト用クリップメタデータを生成する際に、編集前のクリップに含まれるＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣを用いるか、新たなＵＭＩＤ、ＫＬＶデータ、および、ＬＴＣを用意するかを選択することができる。
【０１２６】
次に、このエディットリスト用クリップメタデータを生成する（クリップメタデータを再構成する）処理の例について説明する。
【０１２７】
図２の編集用端末装置１６による編集処理において、クリップデータ編集部５４は、入力部６１を介して入力されたユーザの指示等に基づいて、ドライブ６５に装着された光ディスク１７に記録された画像データや音声データ、または、通信部６４を介して取得したローレゾデータに対して、非破壊的に編集処理を行い、編集内容に関する情報や編集後のデータに関する情報を生成する。
【０１２８】
エディットリスト編集部５５は、クリップデータ編集部５４の編集処理に伴って生成される各種の情報を、バス５６を介して取得し、１回の編集作業が終了すると、その編集結果に基づいて、エディットリスト（エディットリストに含まれる各種のデータ）を生成し、生成したエディットリストを記憶部６３、または、ドライブ６５に装着された光ディスク１７に記録する。
【０１２９】
エディットリスト編集部５５は、エディットリストを生成する際に、エディットリスト用クリップメタデータ処理を実行し、編集対象となるクリップのクリップメタデータを用いて、編集後のエッセンスデータを１クリップとした、エディットリスト用クリップメタデータを生成する。
【０１３０】
次に、エディットリスト編集部５５によるエディットリスト用クリップメタデータ処理について、図９のフローチャートを参照して説明する。
【０１３１】
エディットリスト用クリップメタデータ処理を開始したエディットリスト編集部５５のＬＴＣ編集部５５ｃは、最初に、ステップＳ１において、ユーザの指示に基づいてＬＴＣ編集処理を行い、エディットリスト用のＬＴＣ変換テーブルを生成し、エディットリスト用クリップメタデータとして記録する。
【０１３２】
ここで、図１０および図１１のフローチャートを参照して、エディットリスト編集部５５のＬＴＣ編集部５５ｃにより、図９のステップＳ１において実行されるＬＴＣ編集処理の詳細について説明する。なお、以下において、説明を簡略化するために、編集対象となる各クリップの画像データや音声データに付加されるＬＴＣは、クリップ内において、その値が全て連続しており、クリップの値が前後のフレームにおいて不連続となる変化点が存在しないものとする。
【０１３３】
ＬＴＣ編集処理を開始したエディットリスト編集部５５のＬＴＣ編集部５５ｃは、ステップＳ２１において、後述する処理において用いられる各変数の値を、例えば値「０」を代入する等して初期化する。
【０１３４】
変数の初期化が終了するとＬＴＣ編集部５５ｃは、ステップＳ２２に処理を進め、ユーザ入力に基づいて、編集後の画像データに対して１本化された新たなＬＴＣを対応させるようなＬＴＣ変換テーブルを生成するか否かを判定する。
【０１３５】
ＬＴＣ編集部５５ｃは、出力部６２を制御してディスプレイ等にＧＵＩ（Ｇｒａｐｈｉｃａｌ Ｕｓｅｒ Ｉｎｔｅｒｆａｃｅ）等を表示させ、入力部６１を制御し、ユーザに、エディットリスト用クリップメタデータに含まれるＬＴＣ変換テーブルを生成する際の条件を入力させる。具体的には、ＬＴＣ編集部５５ｃは、編集後の画像データに対して、１本化された新たなＬＴＣを対応させるように変換テーブルを生成するか否かの条件をユーザに入力させる。
【０１３６】
ＬＴＣ編集部５５ｃは、このように入力されたユーザ入力に基づいて、編集後の画像データに対して１本化された新たなＬＴＣを対応させるようなＬＴＣ変換テーブルを生成するか否かを判定し、そのようなＬＴＣ変換テーブルを生成すると判定した場合、ステップＳ２３に処理を進め、入力部６１を制御して、ＬＴＣの初期値の入力を受け付ける。
【０１３７】
編集後の画像データに対して１本化された新たなＬＴＣを対応させる場合、ユーザは、先頭のフレームに対応するＬＴＣの値である初期値を設定することができ、初期値を設定する場合、入力部６１を操作することにより、初期値を入力する。
【０１３８】
ＬＴＣ編集部５５ｃは、ステップＳ２４に処理を進め、入力部６１を制御し、このユーザからの入力に基づいて、初期値が入力されたか否かを判定する。初期値が入力されたと判定した場合、ＬＴＣ編集部５５ｃは、ステップＳ２５に処理を進め、ＬＴＣの初期値を示す変数ＬｔｃＳｔａｒｔに、入力された初期値を代入し、ステップＳ２７に処理を進める。
【０１３９】
なお、ステップＳ２４において、ＬＴＣの初期値が入力されていないと判定した場合、ＬＴＣ編集部５５ｃは、ステップＳ２６に処理を進め、変数ＬｔｃＳｔａｒｔに値「０」を代入し、ステップＳ２７に処理を進める。
【０１４０】
ステップＳ２７において、ＬＴＣ編集部５５ｃは、ＬＴＣ変換テーブルに登録するＬＴＣの値を示す変数ＬｔｃＮｕｍに変数ＬｔｃＳｔａｒｔの値を代入し、ＬＴＣ変換テーブルに登録するフレーム番号を示す変数ＦｒａｍｅＮｕｍに値「０」を代入し、変数ＬｔｃＮｕｍおよび変数ＦｒａｍｅＮｕｍの各値を互いに関連付けて記憶部６３に記憶させることにより、それらの値を開始点として編集後の画像データに対応するＬＴＣ変換テーブルに登録する。
【０１４１】
ところで、編集後の画像データに対して、１本化された新たなＬＴＣを対応させるようにする場合、ＬＴＣの値の増加は全て連続し、開始点以外のフレームにおいて不連続点が発生しない。すなわち、従って、ＬＴＣ編集部５５ｃは、ステップＳ２７の処理により、編集後の画像データに対して、１本化された新たなＬＴＣを付加するようなＬＴＣ変換テーブルには、開始点におけるＬＴＣの値、および開始点におけるフレーム番号（すなわち、「０」）のみが登録される。
【０１４２】
従って、ステップＳ２７の処理を終了し、開始点をＬＴＣ変換テーブルに登録したＬＴＣ編集部５５ｃは、ＬＴＣ編集処理を終了する。
【０１４３】
なお、図１０のステップＳ２２の処理において、編集後の画像データに対して１本化された新たなＬＴＣを付加するようなＬＴＣ変換テーブルを生成しないと判定した場合、ＬＴＣ編集部５５ｃは、図１１のステップＳ３１に処理を進め、処理の対象とするクリップを選択するための変数ＣｌｉｐＮｕｍに値「１」を代入する。
【０１４４】
ステップＳ３２において、ＬＴＣ編集部５５ｃは、ＣｌｉｐＮｕｍ番目のクリップのクリップメタデータに含まれる、ＬＴＣとフレーム番号とのＬＴＣ変換テーブルを参照し、指定された範囲の開始点のＬＴＣと、指定された範囲のフレーム数を算出してその値を変数ＣｌｉｐＦｒａｍｅに代入し、指定された範囲の開始点のＬＴＣを変数ＬｔｃＮｕｍに代入する。すなわち、ＬＴＣ編集部５５ｃは、例えば、光ディスク１７に記録されたクリップの内、ＣｌｉｐＮｕｍ番目のクリップの画像データに注目し、その画像データの全フレームの内、編集結果として採用される部分のフレームのフレーム数を算出し、その値を変数ＣｌｉｐＦｒａｍｅに代入する。また、ＬＴＣ編集部５５ｃは、クリップデータのＬＴＣ変換テーブルを参照し、その編集結果として採用される部分の最初のフレームの、編集結果である画像データにおけるフレーム番号を算出し、その算出結果を変数ＬｔｃＮｕｍに代入する。
【０１４５】
ステップＳ３２の処理を終了したＬＴＣ編集部５５ｃは、ステップＳ３３に処理を進め、変数ＬｔｃＮｕｍおよび変数ＦｒａｍｅＮｕｍを互いに関連付けて記憶部６３に記憶させることにより、それらの値を編集後の画像データに対応するＬＴＣ変換テーブルに登録する。
【０１４６】
指定された範囲内におけるＬＴＣの開始点をＬＴＣ変換テーブルに登録したＬＴＣ編集部５５ｃは、ステップＳ３４に処理を進め、処理対象としたクリップが最後のクリップであるか否かを判定し、また未処理のクリップが存在し、最後のクリップではないと判定した場合、ステップＳ３５に処理を進める。
【０１４７】
ＬＴＣ編集部５５ｃは、ステップＳ３５において、変数ＦｒａｍｅＮｕｍの値に変数ＣｌｉｐＦｒａｍｅの値を加算し、ステップＳ３６において、変数ＣｌｉｐＮｕｍに値「１」を加算し、次のクリップに対する演算処理が行えるように準備する。
【０１４８】
ステップＳ３６の処理を終了したＬＴＣ編集部５５ｃは、ステップＳ３２に処理を戻し、それ以降の処理を繰り返す。
【０１４９】
ＬＴＣ編集部５５ｃは、以上のように、ステップＳ３２乃至ステップＳ３６の処理を繰り返し、全てのクリップに対して、このような処理を行う。そして、全てのクリップに対して上述した処理を終了し、ステップＳ３４において、最後のクリップであると判定した場合、ＬＴＣ編集部５５ｃは、ＬＴＣ編集処理を終了する。
【０１５０】
以上のようにして、ＬＴＣ編集部５５ｃは、図１０および図１１のフローチャートを参照して説明したＬＴＣ編集処理を行い、エディットリストに対応するＬＴＣ変換テーブルを生成することができる。
【０１５１】
なお、上述した各種の変数は、１つの例であり、上述した以外の変数を用いるようにしても良い。
【０１５２】
また、以上においては、編集対象となるクリップの画像データや音声データに対応させられるＬＴＣは、クリップ内において、その値が連続している場合のＬＴＣ編集処理について説明した。しかしながら、ＬＴＣの値がクリップ内において不連続となる（クリップ内にＬＴＣの変化点が存在する）場合もある。そのような場合、上述したＬＴＣ編集処理において、各クリップの指定された範囲の開始点におけるＬＴＣの値と、そのＬＴＣが対応するフレームの、エディットリスト上の画像データ（編集後の画像データ）におけるフレーム番号を対応付けてＬＴＣ変換テーブルに登録するとともに、各クリップのＬＴＣの変化点（直前のフレームのＬＴＣの値と不連続となる値のＬＴＣが付加されたフレーム）に対しても、同様に、ＬＴＣの値と、そのＬＴＣが対応するフレームの、エディットリスト上の画像データ（編集後の画像データ）におけるフレーム番号を対応付けてＬＴＣ変換テーブルに登録するようにすればよい。
【０１５３】
なお、図１０のステップＳ２４の処理において、ユーザよりＬＴＣの初期値に関する入力が無いと判定した場合、ＬＴＣ編集部５５ｃは、ステップＳ２６において、変数ＬｔｃＳｔａｒｔに値「０」を代入する処理を行うように説明したが、これに限らず、例えば、通信部６４を介す等して現在の実際の時刻に関する情報を取得し、その取得した現在の実際の時刻の値を変数ＬｔｃＳｔａｒｔに登録するようにしてもよい。
【０１５４】
次に、複数のクリップを合成して１つのクリップを再生する編集作業における、エディットリスト上のエッセンスデータ（編集後のエッセンスデータ）に対応するＬＴＣであるエディットリスト用ＬＴＣの変換テーブルが生成される様子の具体的な例について説明する。なお、以下においては、編集対象のデータとして、画像データについてのみ説明するが、実際には、音声データ、ローレゾデータ、およびフレームメタデータについても同様に編集される。
【０１５５】
図１２は、編集結果としての画像データに対して１本化された新たなＬＴＣを対応させるようなＬＴＣ変換テーブルを生成しない場合の編集処理において、エディットリスト用のＬＴＣ（エディットリスト用のＬＴＣ変換テーブル）が生成される様子の例を示す図である。
【０１５６】
図１２において、クリップ１およびクリップ２は、例えば、光ディスク１７に記録されているクリップであり、編集対象となるクリップである。すなわち、この編集処理により、クリップ１の画像データ２１０およびクリップ２の画像データ２２０は、それぞれ、その一部分が抽出され、編集後のエディットリスト上の画像データ２３０として、１つの画像データに合成される。
【０１５７】
画像データ２１０および画像データ２２０には、それぞれ、ＬＴＣ（クリップ用ＬＴＣ）が付加されている。クリップ用ＬＴＣとは、編集前のクリップのフレームメタデータに含まれるＬＴＣのことである。図１２において、画像データ２１０の全フレームの内、編集後の画像データ（エディットリスト上の画像データ２３０）として抽出される部分の最初のフレーム（ＩＮ点）のＬＴＣ２１１の値は、「００：１０：００：００」である。
【０１５８】
また、画像データ２１０の全フレームの内、編集後の画像データ（エディットリスト上の画像データ２３０）として抽出される部分の最後のフレーム（ＯＵＴ点）のＬＴＣ２１２の値は、「００：４０：００：００」である。同様に、画像データ２２０のＩＮ点のＬＴＣ２２１の値は、「００：０５：００：００」であり、ＯＵＴ点のＬＴＣ２２２の値は、「００：３５：００：００」である。
【０１５９】
通常、図１２に示されるような、光ディスク１７等に記録されたクリップの画像データや音声データは、撮像装置１４における撮像処理により得られたデータであり、編集処理が施されていないデータである。すなわち、そのような場合、編集対象となるクリップの画像データや音声データに付加されたクリップ用ＬＴＣは、その値が前後のフレームで不連続となる不連続点（変化点）が存在しないことが多い。従って、図１２において、説明を簡略化するために、画像データ２１０または画像データ２２０において、ＬＴＣの値が不連続となる変化点は存在しないものとするが、変化点が含まれるようにしてももちろんよい。
【０１６０】
ＬＴＣ編集部５５ｃが、このような画像データ２１０および２２０を用いて、上述したように、編集後のエディットリスト上の画像データ２３０に対して１本化された新たなＬＴＣを対応させるような変換テーブルを生成しない編集処理を行った場合、図１０および図１１のフローチャートのような処理が行われ、ＦＴＣ（フレーム番号）とＬＴＣ（エディットリスト用ＬＴＣ）が関連付けられて登録された、エディットリスト上の画像データ２３０に対応するＬＴＣ変換テーブルが生成される。
【０１６１】
すなわち、このＬＴＣ変換テーブルには、画像データ２１０におけるＩＮ点のエディットリスト用ＬＴＣおよびフレーム番号（ＦＴＣ）、および、画像データ２２０におけるＩＮ点のエディットリスト用ＬＴＣおよびフレーム番号（ＦＴＣ）が登録される。
【０１６２】
図１２の場合、画像データ２１０のＩＮ点においては、ＦＴＣ２３１の値は、画像データ２３０の先頭フレームでもあるので、「００：００：００：００」となり、エディットリスト用ＬＴＣ２３４の値は、画像データ２１０のクリップ用ＬＴＣの値と同一の「００：１０：００：００」となる。
【０１６３】
また、画像データ２２０のＩＮ点においては、ＦＴＣ２３２の値は、抽出された画像データ２１０のフレーム数がＦＴＣ２３１の値に加算され、「００：３０：００：００」となり、エディットリスト用ＬＴＣ２３５の値は、画像データ２２０のクリップ用ＬＴＣの値と同一の「００：０５：００：００」となる。
【０１６４】
なお、ＬＴＣ変換テーブルには登録されないが、画像データ２２０より抽出された部分における最後のフレームである、画像データ２２０におけるＯＵＴ点に対応するＦＴＣ２３３の値は、抽出された画像データ２２０のフレーム数がＦＴＣ２３２の値に加算され、「０１：００：００：００」となる。
【０１６５】
以上のように、編集結果としての画像データに対して１本化された新たなＬＴＣを対応させるようなＬＴＣ変換テーブルを生成せずに、編集前のデータに対応するクリップＬＴＣを利用して、エディットリストに対応するＬＴＣ変換テーブルを生成する場合、エディットリスト用ＬＴＣの値は不連続となる場合がある。
【０１６６】
図１３は、編集結果としての画像データに対して１本化された新たなＬＴＣを対応させるような変換テーブルを生成する場合の編集処理において、エディットリスト用のＬＴＣ（エディットリスト用の変換テーブル）が生成される様子の例を示す図である。
【０１６７】
図１３において、クリップ１およびクリップ２は、図１２と同様に、編集対象となるクリップである。すなわち、この編集処理により、クリップ１の画像データ２５０およびクリップ２の画像データ２６０は、それぞれ、その一部分が抽出され、編集後のエディットリスト上の画像データ２７０として、１つの画像データに合成される。
【０１６８】
画像データ２５０および画像データ２６０には、それぞれ、ＬＴＣ（クリップ用ＬＴＣ）が付加されている。クリップ用ＬＴＣとは、編集前のクリップのフレームメタデータに含まれるＬＴＣのことである。図１３において、画像データ２５０のＩＮ点のＬＴＣ２５１の値は、「００：１０：００：００」である。
【０１６９】
また、画像データ２５０のＯＵＴ点のＬＴＣ２５２の値は、「００：４０：００：００」である。同様に、画像データ２６０のＩＮ点のＬＴＣ２６１の値は、「００：０５：００：００」であり、ＯＵＴ点のＬＴＣ２６２の値は、「００：３５：００：００」である。なお、図１３において、説明を簡略化するために、図１２と同様に、画像データ２５０または画像データ２６０において、ＬＴＣの値が不連続となる変化点は存在しないものとするが、変化点が含まれるようにしてももちろんよい。
【０１７０】
ＬＴＣ編集部５５ｃが、このような画像データ２５０および２６０を用いて、上述したように、編集後のエディットリスト上の画像データ２７０に対して１本化された新たなＬＴＣを付加するようなＬＴＣ変換テーブルを生成する編集処理を行った場合、図１０、および、図１１のフローチャートのような処理が行われ、ＦＴＣ（フレーム番号）とＬＴＣ（エディットリスト用ＬＴＣ）が関連付けられて登録された、エディットリスト上の画像データ２７０に対応するＬＴＣ変換テーブルが生成される。
【０１７１】
すなわち、このＬＴＣ変換テーブルには、画像データ２５０におけるＩＮ点に対応するエディットリスト用ＬＴＣおよびフレーム番号（ＦＴＣ）のみが登録される。
【０１７２】
図１３の場合、画像データ２７０の先頭フレームであり、画像データ２５０のＩＮ点に対応するフレームにおけるＦＴＣ２７１の値は「００：００：００：００」となり、エディットリスト用ＬＴＣ２７４の値は、ユーザにより設定された初期値となっており、画像データ２５０のクリップ用ＬＴＣ２５１の値とは異なる「００：３０：００：００」となる。
【０１７３】
また、画像データ２６０のＩＮ点においては、ＦＴＣ２７２の値は、抽出された画像データ２５０のフレーム数がＦＴＣ２７１の値に加算され、「００：３０：００：００」となる。
【０１７４】
なお、ＬＴＣ変換テーブルには登録されないが、画像データ２６０のＩＮ点およびＯＵＴ点にそれぞれ対応するＦＴＣ２７２およびＦＴＣ２７３の値は、それぞれ、「００：３０：００：００」および「０１：００：００：００」となる。
【０１７５】
以上のように、編集結果としての画像データに対して１本化された新たなＬＴＣを対応させるようなＬＴＣ変換テーブルを生成する場合、生成されたエディットリストに対応するＬＴＣ変換テーブルには、上述した開始点以外の不連続点（変化点）が登録されていないので、エディットリスト上の画像データ２７０に対応するエディットリスト用ＬＴＣは、値が連続する（不連続点が存在しない）ＬＴＣとなる。
【０１７６】
図１２および図１３による編集により生成された、エディットリスト用クリップメタデータに含まれるＬＴＣ変換テーブル（エディットリスト用ＬＴＣに対応する変換テーブル）の構成例について、図１４Ａ，Ｂを参照して説明する。
【０１７７】
図１４Ａは、図１１の編集により生成されたＬＴＣ変換テーブルの構成例を示す模式図である。このＬＴＣ変換テーブルは、編集処理ごとに生成される、リアルタイム性を要求されないメタデータであるので、エディットリストディレクトリ以下に設けられるエディットリスト用クリップメタデータファイルに記録される。
【０１７８】
図１４Ａの場合、ＬＴＣ変換テーブル２８０は、図６を参照して説明したエディットリスト用クリップメタデータファイル（Ｅ０００２Ｍ０１．ＸＭＬ）１７２に記録される。ＬＴＣ変換テーブル２８０は、上述したように、フレーム番号（ＦＴＣ）２８１およびＬＴＣ不連続点２８２の項目からなるテーブルであり、この場合、開始点（図１２のクリップ１のＩＮ点）の他に、変化点（図１２のクリップ２のＩＮ点）が不連続点として登録されている。
【０１７９】
図１４Ｂは、図１３の編集により生成された変換テーブルの構成例を示す模式図である。この変換テーブルは、編集処理ごとに生成される、リアルタイム性を要求されないメタデータであるので、エディットリストディレクトリ以下に設けられるエディットリスト用クリップメタデータファイルに記録される。
【０１８０】
図１４Ｂの場合、ＬＴＣ変換テーブル２８０は、図６を参照して説明したエディットリスト用クリップメタデータファイル（Ｅ０００２Ｍ０１．ＸＭＬ）１７２に記録される。ＬＴＣ変換テーブル２８０は、上述したように、フレーム番号（ＦＴＣ）２８１およびＬＴＣ不連続点２８２の項目からなるテーブルであり、この場合、開始点（図１３のクリップ１のＩＮ点）のみが不連続点として登録されている。ただし、この場合、ＬＴＣ不連続点２８２には、ユーザが編集の際に設定した初期値が登録されている。
【０１８１】
次に、ＬＴＣ変換テーブルのＸＭＬでの記述例について説明する。
【０１８２】
例えば、図１５で示されるように縦軸にＬＴＣの値をとり、横軸にフレーム番号（Ｆｒａｍｅ Ｃｏｕｎｔ）（ＦＴＣに対応する値）を取ったときに示されるような再生される画像が存在する場合、ＦＴＣに対応したＬＴＣ不連続点を示すＬＴＣ変化点テーブルは、図１６で示されるように記述される。
【０１８３】
図１６においては、第０１行目には＜ＬｔｃＣｈａｎｇｅＴａｂｌｅ ｔｃＦｐｓ＝”３０”＞と記述されており、第１３行目に記述された＜／ＬｔｃＣｈａｎｇｅＴａｂｌｅ＞により、この範囲の記述がＬＴＣ変換テーブルであることが示されている。
【０１８４】
第０２行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”０” ｖａｌｕｅ＝”５５３００２０１” ｓｔａｔｕｓ＝”ｉｎｃ”／＞」と記述されており、＜ＬｔｃＣｈａｎｇｅ・・・＞の記述により、ＬＴＣ変換テーブルであることが示されている。また、「ｆｒａｍｅＣｏｕｎｔ＝”０” ｖａｌｕｅ＝”５５３００２０１”」との記述により、ＦＴＣが「０」であるとき、ＬＴＣ不連続点が「５５３００２０１」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｎｃ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、１フレーム分のＬＴＣがインクリメントされることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が０となるフレームからは、各フレームについて順次１フレーム分のＬＴＣがインクリメントされることが示されている。尚、図１５においては、第０フレームから第３フレームまでの間隔が１フレームである。
【０１８５】
第０３行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”３” ｖａｌｕｅ＝”４８２５２００１” ｓｔａｔｕｓ＝”ｓｔｉｌｌ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”３” ｖａｌｕｅ＝”４８２５２００１”」との記述により、ＦＴＣが「３」であるとき、ＬＴＣ不連続点が「４８２５２００１」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｎｃ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、１フレーム分のＬＴＣがインクリメントされることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が３となるフレームからは、各フレームについて同じＬＴＣが維持されることが示されている。
【０１８６】
第０４行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”５” ｖａｌｕｅ＝”４８２５２００１” ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”５” ｖａｌｕｅ＝”４８２５２００１”」との記述により、ＦＴＣが「５」であるとき、ＬＴＣ不連続点が「４８２５２００１」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、ＬＴＣが減少するか、または、１フレーム分以上増加されることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が５となるフレームからは、各フレームについて１フレーム分以上の間隔でＬＴＣが変化されることが示されている。
【０１８７】
第０５行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”６” ｖａｌｕｅ＝”５３００１５００” ｓｔａｔｕｓ＝”ｓｔｉｌｌ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”６” ｖａｌｕｅ＝”５３００１５００”」との記述により、ＦＴＣが「６」であるとき、ＬＴＣ不連続点が「５３００１５００」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｓｔｉｌｌ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、１フレーム分のＬＴＣがインクリメントされることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が６となるフレームからは、各フレームについて同じＬＴＣが維持されることが示されている。
【０１８８】
第０６行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”８” ｖａｌｕｅ＝”４２２５４３１５” ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”８” ｖａｌｕｅ＝”４２２５４３１５”」との記述により、ＦＴＣが「８」であるとき、ＬＴＣ不連続点が「４２２５４３１５」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、ＬＴＣが減少するか、または、１フレーム分以上増加されることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が８となるフレームからは、各フレームについて１フレーム分のＬＴＣが減少されることが示されている。
【０１８９】
第０７行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”１１” ｖａｌｕｅ＝”４３２５４３１５” ｓｔａｔｕｓ＝”ｉｎｃ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”１１” ｖａｌｕｅ＝”４３２５４３１５”」との記述により、ＦＴＣが「１１」であるとき、ＬＴＣ不連続点が「４３２５４３１５」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｎｃ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、１フレーム分のＬＴＣがインクリメントされることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が１１となるフレームからは、各フレームについて順次ＬＴＣが１インクリメントされることが示されている。
【０１９０】
第０８行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”１４” ｖａｌｕｅ＝”４２２５４５１５” ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”１４” ｖａｌｕｅ＝”４２２５４３１５”」との記述により、ＦＴＣが「１４」であるとき、ＬＴＣ不連続点が「４２２５４３１５」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、ＬＴＣが減少するか、または、１フレーム分以上増加されることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が１４となるフレームからは、各フレームについて１フレーム分以上のＬＴＣが増加されることが示されている。
【０１９１】
第０９行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”１５” ｖａｌｕｅ＝”４３２５４３１５” ｓｔａｔｕｓ＝”ｉｎｃ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”１５” ｖａｌｕｅ＝”４３２５４３１５”」との記述により、ＦＴＣが「１５」であるとき、ＬＴＣ不連続点が「４３２５４３１５」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｎｃ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、１フレーム分のＬＴＣがインクリメントされることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が１５となるフレームからは、各フレームについて１インクリメントされることが示されている。
【０１９２】
第１０行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”１７” ｖａｌｕｅ＝”４２２５４５１５” ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”１７” ｖａｌｕｅ＝”４２２５４５１５”」との記述により、ＦＴＣが「１７」であるとき、ＬＴＣ不連続点が「４２２５４３１５」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、ＬＴＣが減少するか、または、１フレーム分以上増加されることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が１７となるフレームからは、各フレームについてＬＴＣが減少されることが示されている。
【０１９３】
第１１行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”１８” ｖａｌｕｅ＝”４２２５４５１５” ｓｔａｔｕｓ＝”ｉｎｃ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”１８” ｖａｌｕｅ＝”４２２５４５１５”」との記述により、ＦＴＣが「１８」であるとき、ＬＴＣ不連続点が「４３２５４３１５」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｎｃ”」と記述されており、このＦＴＣの変化点の以降の処理としてフレームが進むにつれて、１フレーム分のＬＴＣがインクリメントされることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が１８となるフレームからは、各フレームについて１インクリメントされることが示されている。
【０１９４】
第１２行目には、「＜ＬｔｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”２０” ｖａｌｕｅ＝”４２２５４５１５” ｓｔａｔｕｓ＝”ｅｎｄ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”２０” ｖａｌｕｅ＝”４２２５４５１５”」との記述により、ＦＴＣが「２０」であるとき、ＬＴＣ不連続点が「４３２５４３１５」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｅｎｄ”」と記述されており、このＦＴＣの変化点のフレーム処理が終了されることが示されている。結果として、図１５で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が２０となるフレームで処理が終了される。
【０１９５】
以上のように、非破壊的な編集処理の際に、エディットリストに対応するクリップメタデータを生成することにより、編集対象のデータを更新することなく、容易に、編集結果のエッセンスデータに対して新たなＬＴＣを付加させることができる。
【０１９６】
これにより、ユーザは、その新たなＬＴＣを用いることにより、編集結果より所望のフレームを検索する処理が容易になるので、その後の編集処理を容易に行うことができる。また、エディットリストを用いて編集後のエッセンスデータを再生する（編集結果を再現する）場合において、再生処理を行う装置は、その新たなＬＴＣに対応する変換テーブルを読み出すだけで、再生データにＬＴＣを付加させることができるので、再生処理時間、および再生処理の負荷を軽減させることができる。
【０１９７】
ここで、図９のフローチャートの説明に戻る。
【０１９８】
ステップＳ１において、ＬＴＣ編集処理が終了すると、ステップＳ２において、ＵＭＩＤ編集部５５ａは、ＵＭＩＤ編集処理を実行する。
【０１９９】
ここで、図１７および図１８のフローチャートを参照して、エディットリスト編集部５５のＵＭＩＤ編集部５５ａにより、図９のステップＳ２において実行されるＵＭＩＤ編集処理の詳細について説明する。なお、以下において、説明を簡略化するために、クリップの値が前後のフレームにおいて不連続となる変化点が存在しないものとする。
【０２００】
ステップＳ４１において、ＵＭＩＤ編集部５５ａは、ＵＭＩＤ編集処理に用いられる変数ＵＭＩＤをＥｘｔｅｎｄｅｄＵＭＩＤに設定する。すなわち、ここでは、ＵＭＩＤの編集のうち、ＥｘｔｅｎｄｅｄＵＭＩＤの編集がなされることが宣言される。
【０２０１】
ＵＭＩＤ編集部５５ａは、ステップＳ４２において、後述する処理において用いられる各変数のうち、上述した変数ＵＭＩＤ以外の変数の値を、例えば値「０」を代入する等して初期化する。
【０２０２】
変数の初期化が終了するとＵＭＩＤ編集部５５ａは、ステップＳ４３に処理を進め、ユーザ入力に基づいて、編集後の画像データに対して１本化された新たなＵＭＩＤを対応させるようなＵＭＩＤ変換テーブルを生成するか否かを判定する。
【０２０３】
ＵＭＩＤ編集部５５ａは、出力部６２を制御してディスプレイ等にＧＵＩ等を表示させ、入力部６１を制御し、ユーザに、エディットリスト用クリップメタデータに含まれるＵＭＩＤ変換テーブルを生成する際の条件を入力させる。具体的には、ＵＭＩＤ編集部５５ａは、編集後の画像データに対して、１本化された新たなＬＴＣを対応させるように変換テーブルを生成するか否かの条件をユーザに入力させる。
【０２０４】
ＵＭＩＤ編集部５５ａは、このように入力されたユーザ入力に基づいて、編集後の画像データに対して１本化された新たなＵＭＩＤを対応させるようなＵＭＩＤ変換テーブルを生成するか否かを判定し、そのようなＵＭＩＤ変換テーブルを生成すると判定した場合、ステップＳ４４に処理を進め、ＵＭＩＤの初期値を生成する。
【０２０５】
ＵＭＩＤ編集部５５ａは、ステップＳ４５に処理を進め、ＵＭＩＤの初期値を示す変数ＵｍｉｄＳｔａｒｔに、入力された初期値を代入し、ステップＳ４６に処理を進める。
【０２０６】
ステップＳ４６において、ＵＭＩＤ編集部５５ａは、ＵＭＩＤ変換テーブルに登録するＵＭＩＤの値を示す変数ＵｍｉｄＮｕｍに変数ＵｍｉｄＳｔａｒｔの値を代入し、ＵＭＩＤ変換テーブルに登録するフレーム番号を示す変数ＦｒａｍｅＮｕｍに値「０」を代入し、変数ＵｍｉｄＮｕｍおよび変数ＦｒａｍｅＮｕｍの各値を互いに関連付けて記憶部６３に記憶させることにより、それらの値を開始点として編集後の画像データに対応するＵＭＩＤ変換テーブルに登録する。
【０２０７】
ところで、編集後の画像データに対して、１本化された新たなＵＭＩＤを対応させるようにする場合、ＵＭＩＤの値の増加は全て連続し、開始点以外のフレームにおいて不連続点が発生しない。すなわち、従って、ＵＭＩＤ編集部５５ａは、ステップＳ４６の処理により、編集後の画像データに対して、１本化された新たなＵＭＩＤを付加するようなＵＭＩＤ変換テーブルには、開始点におけるＵＭＩＤの値、および開始点におけるフレーム番号（すなわち、「０」）のみが登録される。
【０２０８】
従って、ステップＳ４６の処理を終了し、開始点をＵＭＩＤ変換テーブルに登録したＵＭＩＤ編集部５５ａは、ステップＳ４７にその処理を進める。すなわち、今の場合、以上の処理により、ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブルが生成されることになる。
【０２０９】
ステップＳ４７において、ＵＭＩＤ編集部５５ａは、ＢａｓｉｃＵＭＩＤ変換テーブルが生成されたか否かを判定し、ＢａｓｉｃＵＭＩＤ変換テーブルが生成されていないと判定された場合、ステップＳ４８において、変数ＵＭＩＤをＢａｓｉｃＵＭＩＤに設定し、その処理は、ステップＳ４２に戻り、それ以降の処理を繰り返す。すなわち、ステップＳ４８の処理により、これ以降の処理で、ＢａｓｉｃＵＭＩＤ変換テーブルを生成することが宣言される。
【０２１０】
さらに、ステップＳ４７において、再びＢａｓｉｃＵＭＩＤ変換テーブルが生成されたか否かが判定される。今の場合、ＢａｓｉｃＵＭＩＤ変換テーブルが生成されていることになる。このようにＢａｓｉｃＵＭＩＤ変換テーブルが生成されていると判定された場合、その処理は、ステップＳ４９に進む。
【０２１１】
ステップＳ４９において、ＵＭＩＤ編集部５５ａは、Ｗｈｅｎ変換テーブルが生成されたか否かを判定し、Ｗｈｅｎ変換テーブルが生成されていないと判定された場合、ステップＳ５０において、変数ＵＭＩＤをＷｈｅｎに設定し、その処理は、ステップＳ４２に戻り、それ以降の処理を繰り返す。すなわち、ステップＳ５０の処理により、これ以降の処理で、Ｗｈｅｎ変換テーブルを生成することが宣言される。
【０２１２】
さらに、ステップＳ４９において、再びＷｈｅｎ変換テーブルが生成されたか否かが判定される。今の場合、Ｗｈｅｎ変換テーブルが生成されていることになる。このようにＷｈｅｎ変換テーブルが生成されていると判定された場合、その処理は、ステップＳ５１に進む。
【０２１３】
ステップＳ５１において、ＵＭＩＤ変換部５５ａは、Ｗｈｅｒｅ変換テーブルが生成されているか否かを判定し、Ｗｈｅｒｅ変換テーブルが生成されていないと判定された場合、ステップＳ５２において、変数ＵＭＩＤをＷｈｅｒｅに設定し、その処理は、ステップＳ４２に戻り、それ以降の処理を繰り返す。すなわち、ステップＳ５２の処理により、これ以降の処理で、Ｗｈｅｒｅ変換テーブルを生成することが宣言される。
【０２１４】
さらに、ステップＳ５３において、再びＷｈｏ変換テーブルが生成されたか否かが判定される。今の場合、Ｗｈｏ変換テーブルが生成されていることになる。このようにＷｈｏ変換テーブルが生成されていると判定された場合、その処理は、ステップＳ５４に進む。
【０２１５】
ステップＳ５３において、ＵＭＩＤ変換部５５ａは、Ｗｈｏ変換テーブルが生成されているか否かを判定し、Ｗｈｏ変換テーブルが生成されていないと判定された場合、ステップＳ５４において、変数ＵＭＩＤをＷｈｏに設定し、その処理は、ステップＳ４２に戻り、それ以降の処理を繰り返す。すなわち、ステップＳ５４の処理により、これ以降の処理で、Ｗｈｏ変換テーブルを生成することが宣言される。
【０２１６】
さらに、ステップＳ５３において、再びＷｈｏ変換テーブルが生成されたか否かが判定される。今の場合、Ｗｈｏ変換テーブルが生成されていることになる。このようにＷｈｏ変換テーブルが生成されていると判定された場合、その処理は、終了する。
【０２１７】
すなわち、ステップＳ４１，Ｓ４８，Ｓ５０，Ｓ５２，Ｓ５４の処理により、ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブル、ＢａｓｉｃＵＭＩＤ変換テーブル、Ｗｈｅｎ変換テーブル、Ｗｈｅｒｅ変換テーブル、および、Ｗｈｏ変換テーブルが生成されることが順次宣言され、その宣言に応じて、ステップＳ４２乃至Ｓ４６の処理により、生成される。
【０２１８】
なお、図１７のステップＳ４３の処理において、編集後の画像データに対して１本化された新たなＵＭＩＤを付加するようなＵＭＩＤ変換テーブル（ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブル、ＢａｓｉｃＵＭＩＤ変換テーブル、Ｗｈｅｎ変換テーブル、Ｗｈｅｒｅ変換テーブル、および、Ｗｈｏ変換テーブルのうち、変数ＵＭＩＤに宣言されているテーブル）を生成しないと判定した場合、ＵＭＩＤ編集部５５ａは、図１８のステップＳ６１に処理を進め、処理の対象とするクリップを選択するための変数ＣｌｉｐＮｕｍに値「１」を代入する。
【０２１９】
ステップＳ６２において、ＵＭＩＤ編集部５５ａは、ＣｌｉｐＮｕｍ番目のクリップのクリップメタデータに含まれる、ＵＭＩＤとフレーム番号とのＵＭＩＤ変換テーブルを参照し、指定された範囲の開始点のＵＭＩＤと、指定された範囲のフレーム数を算出してその値を変数ＣｌｉｐＦｒａｍｅに代入し、指定された範囲の開始点のＵＭＩＤを変数ＵｍｉｄＮｕｍに代入する。すなわち、ＵＭＩＤ編集部５５ａは、例えば、光ディスク１７に記録されたクリップの内、ＣｌｉｐＮｕｍ番目のクリップの画像データに注目し、その画像データの全フレームの内、編集結果として採用される部分のフレームのフレーム数を算出し、その値を変数ＣｌｉｐＦｒａｍｅに代入する。また、ＵＭＩＤ編集部５５ａは、クリップデータのＵＭＩＤ変換テーブルを参照し、その編集結果として採用される部分の最初のフレームの、編集結果である画像データにおけるフレーム番号を算出し、その算出結果を変数ＵｍｉｄＮｕｍに代入する。
【０２２０】
ステップＳ６２の処理を終了したＵＭＩＤ編集部５５ａは、ステップＳ６３に処理を進め、変数ＵｍｉｄＮｕｍおよび変数ＦｒａｍｅＮｕｍを互いに関連付けて記憶部６３に記憶させることにより、それらの値を編集後の画像データに対応するＵＭＩＤ変換テーブルに登録する。
【０２２１】
指定された範囲内におけるＵＭＩＤの開始点をＵＭＩＤ変換テーブルに登録したエディットリスト編集部５５は、ステップＳ６４に処理を進め、処理対象としたクリップが最後のクリップであるか否かを判定し、また未処理のクリップが存在し、最後のクリップではないと判定した場合、ステップＳ６５に処理を進める。
【０２２２】
ＵＭＩＤ編集部５５ａは、ステップＳ６５において、変数ＦｒａｍｅＮｕｍの値に変数ＣｌｉｐＦｒａｍｅの値を加算し、ステップＳ６６において、変数ＣｌｉｐＮｕｍに値「１」を加算し、次のクリップに対する演算処理が行えるように準備する。
【０２２３】
ステップＳ６６の処理を終了したＵＭＩＤ編集部５５ａは、ステップＳ６２に処理を戻し、それ以降の処理を繰り返す。
【０２２４】
ＵＭＩＤ編集部５５ａは、以上のように、ステップＳ６２乃至ステップＳ６６の処理を繰り返し、全てのクリップに対して、このような処理を行う。そして、全てのクリップに対して上述した処理を終了し、ステップＳ６４において、最後のクリップであると判定した場合、その処理は、ステップＳ４７に戻りそれ以降の処理が繰り返される。
【０２２５】
以上のようにして、ＵＭＩＤ編集部５５ａは、図１７および図１８のフローチャートを参照して説明したＵＭＩＤ編集処理を行い、エディットリストに対応するＵＭＩＤ変換テーブルを生成することができる。
【０２２６】
なお、上述した各種の変数は、１つの例であり、上述した以外の変数を用いるようにしても良い。
【０２２７】
また、以上においては、編集対象となるクリップの画像データや音声データに対応させられるＵＭＩＤは、クリップ内において、その値が連続している場合のＵＭＩＤ編集処理について説明した。しかしながら、ＵＭＩＤの値がクリップ内において不連続となる（クリップ内にＵＭＩＤの変化点が存在する）場合もある。そのような場合、上述したＵＭＩＤ編集処理において、各クリップの指定された範囲の開始点におけるＵＭＩＤの値と、そのＵＭＩＤが対応するフレームの、エディットリスト上の画像データ（編集後の画像データ）におけるフレーム番号を対応付けてＵＭＩＤ変換テーブルに登録するとともに、各クリップのＵＭＩＤの変化点（直前のフレームのＵＭＩＤの値と不連続となる値のＵＭＩＤが付加されたフレーム）に対しても、同様に、ＵＭＩＤの値と、そのＵＭＩＤが対応するフレームの、エディットリスト上の画像データ（編集後の画像データ）におけるフレーム番号を対応付けてＵＭＩＤ変換テーブルに登録するようにすればよい。
【０２２８】
次に、複数のクリップを合成して１つのクリップを再生する編集作業における、エディットリスト上のエッセンスデータ（編集後のエッセンスデータ）に対応するＵＭＩＤであるエディットリスト用ＵＭＩＤの変換テーブルが生成される様子の具体的な例について説明する。なお、以下においては、編集対象のデータとして、画像データについてのみ説明するが、実際には、音声データ、ローレゾデータ、およびフレームメタデータについても同様に編集される。また、以下の図１９乃至図２２でいうＵＭＩＤ変換テーブルは、ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブル、ＢａｓｉｃＵＭＩＤ変換テーブル、Ｗｈｅｎ変換テーブル、Ｗｈｅｒｅ変換テーブル、および、Ｗｈｏ変換テーブルを総称するものであって、それぞれに同様の構成であり、図１９乃至図２２の説明において、ＵＭＩＤというとき、上述したＥｘｔｅｎｄｅｄ ＵＭＩＤを示すのみならず、ＥｘｔｅｎｄｅｄＵＭＩＤ、ＢａｓｉｃＵＭＩＤ変換テーブル、Ｗｈｅｎデータ、Ｗｈｅｒｅデータ、または、Ｗｈｏデータのいずれかを示すものでもある。
【０２２９】
図１９は、編集結果としての画像データに対して１本化された新たなＵＭＩＤを対応させるようなＵＭＩＤ変換テーブルを生成しない場合の編集処理において、エディットリスト用のＵＭＩＤ（エディットリスト用のＵＭＩＤ変換テーブル）が生成される様子の例を示す図である。
【０２３０】
図１９において、クリップ１およびクリップ２は、例えば、光ディスク１７に記録されているクリップであり、編集対象となるクリップである。すなわち、この編集処理により、クリップ１の画像データ３１０およびクリップ２の画像データ３２０は、それぞれ、その一部分が抽出され、編集後のエディットリスト上の画像データ３３０として、１つの画像データに合成される。
【０２３１】
画像データ３１０および画像データ３２０には、それぞれ、ＵＭＩＤ（クリップ用ＵＭＩＤ）が付加されている。クリップ用ＵＭＩＤとは、編集前のクリップのフレームメタデータに含まれるＵＭＩＤのことである。図１９において、画像データ３１０の全フレームの内、編集後の画像データ（エディットリスト上の画像データ３３０）として抽出される部分の最初のフレーム（ＩＮ点）のＵＭＩＤ３１１の値は、「０００１０００００００」である。
【０２３２】
また、画像データ３１０の全フレームの内、編集後の画像データ（エディットリスト上の画像データ３３０）として抽出される部分の最後のフレーム（ＯＵＴ点）のＵＭＩＤ３１２の値は、「０００４０００００００」である。同様に、画像データ３２０のＩＮ点のＬＴＣ３２１の値は、「００００５００００００」であり、ＯＵＴ点のＵＭＩＤ３２２の値は、「０００３５００００００」である。
【０２３３】
通常、図１９に示されるような、光ディスク１７等に記録されたクリップの画像データや音声データは、撮像装置１４における撮像処理により得られたデータであり、編集処理が施されていないデータである。すなわち、そのような場合、編集対象となるクリップの画像データや音声データに付加されたクリップ用ＵＭＩＤは、その値が前後のフレームで不連続となる不連続点（変化点）が存在しないことが多い。従って、図１９において、説明を簡略化するために、画像データ３１０または画像データ３２０において、ＵＭＩＤの値が不連続となる変化点は存在しないものとするが、変化点が含まれるようにしてももちろんよい。
【０２３４】
ＵＭＩＤ編集部５５ａが、このような画像データ３１０および３２０を用いて、上述したように、編集後のエディットリスト上の画像データ３３０に対して１本化された新たなＵＭＩＤを対応させるような変換テーブルを生成しない編集処理を行った場合、図１７および図１８のフローチャートのような処理が行われ、ＦＴＣ（フレーム番号）とＵＭＩＤ（エディットリスト用ＵＭＩＤ）が関連付けられて登録された、エディットリスト上の画像データ２３０に対応するＵＭＩＤ変換テーブルが生成される。
【０２３５】
すなわち、このＵＭＩＤ変換テーブルには、画像データ３１０におけるＩＮ点のエディットリスト用ＵＭＩＤおよびフレーム番号（ＦＴＣ）、および、画像データ３２０におけるＩＮ点のエディットリスト用ＵＭＩＤおよびフレーム番号（ＦＴＣ）が登録される。
【０２３６】
図１９の場合、画像データ３１０のＩＮ点においては、ＦＴＣ３３１の値は、画像データ３３０の先頭フレームでもあるので、「００：００：００：００」となり、エディットリスト用ＵＭＩＤ３３４の値は、例えば、「００１１０００００００」となる。
【０２３７】
また、画像データ３２０のＩＮ点においては、ＦＴＣ３３２の値は、抽出された画像データ３１０のフレーム数がＦＴＣ３３１の値に加算され、「００：３０：００：００」となる。また、エディットリスト用ＵＭＩＤ３３５の値は、例えば、「００１０５００００００」となる。
【０２３８】
なお、ＵＭＩＤ変換テーブルには登録されないが、画像データ３２０より抽出された部分における最後のフレームである、画像データ３２０におけるＯＵＴ点に対応するＦＴＣ３３３の値は、抽出された画像データ３２０のフレーム数がＦＴＣ３３２の値に加算され、「０１：００：００：００」となる。
【０２３９】
以上のように、編集結果としての画像データに対して１本化された新たなＵＭＩＤを対応させるようなＵＭＩＤ変換テーブルを生成せずに、編集前のデータに対応するクリップＵＭＩＤを利用して、エディットリストに対応するＵＭＩＤ変換テーブルを生成する場合、エディットリスト用ＵＭＩＤの値は不連続となる場合がある。
【０２４０】
図２０は、編集結果としての画像データに対して１本化された新たなＵＭＩＤを対応させるような変換テーブルを生成する場合の編集処理において、エディットリスト用のＵＭＩＤ（エディットリスト用の変換テーブル）が生成される様子の例を示す図である。
【０２４１】
図２０において、クリップ１およびクリップ２は、図１９と同様に、編集対象となるクリップである。すなわち、この編集処理により、クリップ１の画像データ３５０およびクリップ２の画像データ３６０は、それぞれ、その一部分が抽出され、編集後のエディットリスト上の画像データ３７０として、１つの画像データに合成される。
【０２４２】
画像データ３５０および画像データ３６０には、それぞれ、ＵＭＩＤ（クリップ用ＵＭＩＤ）が付加されている。クリップ用ＵＭＩＤとは、編集前のクリップのフレームメタデータに含まれるＵＭＩＤのことである。図２０において、画像データ３５０のＩＮ点のＵＭＩＤ３５１の値は、「０００１０００００００」である。
【０２４３】
また、画像データ３５０のＯＵＴ点のＵＭＩＤ３５２の値は、「０００４０００００００」である。同様に、画像データ３６０のＩＮ点のＵＭＩＤ３６１の値は、「００００５００００００」であり、ＯＵＴ点のＵＭＩＤ３６２の値は、「０００３５００００００」である。なお、図２０において、説明を簡略化するために、図１９と同様に、画像データ３５０または画像データ３６０において、ＵＭＩＤの値が不連続となる変化点は存在しないものとするが、変化点が含まれるようにしてもよい。
【０２４４】
ＵＭＩＤ編集部５５ａが、このような画像データ３５０および３６０を用いて、上述したように、編集後のエディットリスト上の画像データ３７０に対して１本化された新たなＵＭＩＤを付加するようなＵＭＩＤ変換テーブルを生成する編集処理を行った場合、図１７および図１８のフローチャートのような処理が行われ、ＦＴＣ（フレーム番号）とＵＭＩＤ（エディットリスト用ＵＭＩＤ）が関連付けられて登録された、エディットリスト上の画像データ３７０に対応するＵＭＩＤ変換テーブルが生成される。
【０２４５】
すなわち、このＵＭＩＤ変換テーブルには、画像データ３５０におけるＩＮ点に対応するエディットリスト用ＵＭＩＤおよびフレーム番号（ＦＴＣ）のみが登録される。
【０２４６】
図２０の場合、画像データ３７０の先頭フレームであり、画像データ３５０のＩＮ点に対応するフレームにおけるＦＴＣ３７１の値は「００：００：００：００」となり、エディットリスト用ＵＭＩＤ３７４の値は、画像データ３５０のクリップ用ＵＭＩＤ３５１の値とは異なる「０００３０００００００」となる。
【０２４７】
また、画像データ３２０のＩＮ点においては、ＦＴＣ３３２の値は、抽出された画像データ３１０のフレーム数がＦＴＣ３３１の値に加算され、「００：３０：００：００」となる。
【０２４８】
なお、ＵＭＩＤ変換テーブルには登録されないが、画像データ２６０のＩＮ点およびＯＵＴ点にそれぞれ対応するＦＴＣ３７２およびＦＴＣ３７３の値は、それぞれ、「００：３０：００：００」および「０１：００：００：００」となる。
【０２４９】
以上のように、編集結果としての画像データに対して１本化された新たなＵＭＩＤを対応させるようなＬＴＣ変換テーブルを生成する場合、生成されたエディットリストに対応するＬＴＣ変換テーブルには、上述した開始点以外の不連続点（変化点）が登録されていないので、エディットリスト上の画像データ３７０に対応するエディットリスト用ＵＭＩＤは、値が連続する（不連続点が存在しない）ＵＭＩＤとなる。
【０２５０】
図１７および図１８による編集により生成された、エディットリスト用クリップメタデータに含まれるＵＭＩＤ変換テーブル（エディットリスト用ＵＭＩＤに対応するＵＭＩＤ変換テーブル）の構成例について、図２１，図２２を参照して説明する。
【０２５１】
図２１は、図１７の編集により生成されたＵＭＩＤ変換テーブル、すなわち、ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブル、ＢａｓｉｃＵＭＩＤ変換テーブル、Ｗｈｅｎ変換テーブル、Ｗｈｅｒｅ変換テーブル、および、Ｗｈｏ変換テーブルのそれぞれの構成例を示す模式図である。このＵＭＩＤ変換テーブルは、編集処理ごとに生成される、リアルタイム性を要求されないメタデータであるので、エディットリストディレクトリ以下に設けられるエディットリスト用クリップメタデータファイルに記録される。
【０２５２】
図２１の場合、ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブル３８０は、図６を参照して説明したエディットリスト用クリップメタデータファイル（Ｅ０００２Ｍ０１．ＸＭＬ）１７２に記録される。ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブル３８０は、上述したように、フレーム番号（ＦＴＣ）３８１およびＥｘｔｅｎｄｅｄＵＭＩＤ不連続点３８２の項目からなるテーブルであり、この場合、開始点（図１９のクリップ１のＩＮ点）の他に、変化点（図１９のクリップ２のＩＮ点）が不連続点として登録されている。
【０２５３】
同様に、ＢａｓｉｃＵＭＩＤ変換テーブル３９０、Ｗｈｅｎ変換テーブル４００、Ｗｈｅｒｅ変換テーブル４１０、およびＷｈｏ変換テーブル４２０は、上述したように、それぞれ、フレーム番号（ＦＴＣ）３９１，４０１，４１１、および４２１、並びに、ＢａｓｉｃＵＭＩＤ不連続点３９２、Ｗｈｅｎ不連続点４０２、Ｗｈｅｒｅ不連続点４１２、およびＷｈｏ不連続点４２２の項目からなるテーブルである。
【０２５４】
また、図２２は、図１８の編集により生成された変換テーブルの構成例を示す模式図である。この変換テーブルは、編集処理ごとに生成される、リアルタイム性を要求されないメタデータであるので、エディットリストディレクトリ以下に設けられるエディットリスト用クリップメタデータファイルに記録される。
【０２５５】
図２２の場合、ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブル４３０は、図６を参照して説明したエディットリスト用クリップメタデータファイル（Ｅ０００２Ｍ０１．ＸＭＬ）１７２に記録される。ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブル４３０は、上述したように、フレーム番号（ＦＴＣ）４３１およびＥｘｔｅｎｄｅｄＵＭＩＤ不連続点４３２の項目からなるテーブルであり、この場合、開始点（図２０のクリップ１のＩＮ点）のみが不連続点として登録されている。
【０２５６】
同様に、ＢａｓｉｃＵＭＩＤ変換テーブル４４０、Ｗｈｅｎ変換テーブル４５０、Ｗｈｅｒｅ変換テーブル４６０、およびＷｈｏ変換テーブル４７０は、上述したように、それぞれ、フレーム番号（ＦＴＣ）４４１，４５１，４６１、および４７１、並びに、ＢａｓｉｃＵＭＩＤ不連続点４４２，Ｗｈｅｎ不連続点４５２、Ｗｈｅｒｅ不連続点４６２、およびＷｈｏ不連続点４７２の項目からなるテーブルである。尚、図１９乃至図２２においては、説明の便宜上、ＥｘｔｅｎｄｅｄＵＭＩＤが１１バイト、ＢａｓｉｃＵＭＩＤが２バイト、Ｗｈｅｎ、Ｗｈｅｒｅ、およびＷｈｏがそれぞれ３バイトであるものとする。
【０２５７】
次に、ＵＭＩＤ変換テーブルのＸＭＬでの記述例について説明する。
【０２５８】
例えば、図２３で示されるように縦軸にＵＭＩＤのＥｘｔｅｎｄｅｄＵＭＩＤ、Ｗｈｅｎ、Ｗｈｅｒｅ、および、Ｗｈｏのそれぞれについてデータの有無を示し、横軸にフレーム番号（Ｆｒａｍｅ Ｃｏｕｎｔ）（ＦＴＣに対応する値）を取ったときに示されるような再生される画像が存在する場合、ＦＴＣに対応したＵＭＩＤ不連続点を示すＵＭＩＤ変換テーブルは、図２４で示されるように記述される。
【０２５９】
図２４においては、第０１行目には＜ＢｏｄｙＵｍｉｄＢａｓｉｃＣｈａｎｇｅＴａｂｌｅ＞と記述されており、第１５行目に記述された＜／ＢｏｄｙＵｍｉｄＢａｓｉｃＣｈａｎｇｅＴａｂｌｅ＞により、この範囲の記述がＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブルであることが示されている。
【０２６０】
第０２行目、および、第０３行目には、「＜ＢｏｄｙＵｍｉｄＢａｓｉｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”１００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｖａｌｕｅ＝”０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１１１４１１１９９９９０８００４６８Ｅ１３０Ｂ”／＞」と記述されており、＜ＢｏｄｙＵｍｉｄＢａｓｉｃＣｈａｎｇｅ・・・／＞の記述により、ＥｘｔｅｎｄｅｄＵＭＩＤ変換テーブルであることが示されている。また、「ｆｒａｍｅＣｏｕｎｔ＝”１００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｖａｌｕｅ＝”０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１１１４１１１９９９９０８００４６８Ｅ１３０Ｂ”」との記述により、ＦＴＣが「１００」であるとき、ＵＭＩＤ不連続点が「０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１１１４１１１９９９９０８００４６８Ｅ１３０Ｂ」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｓｔａｒｔ”」と記述されており、このＦＴＣの変化点の以降のフレームが、そのＥｘｔｅｎｄｅｄＵＭＩＤの開始であることが示されている。結果として、図２３で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が１００となるフレームからは、ＥｘｔｅｎｄｅｄＵＭＩＤが記録されているされることが示されている。
【０２６１】
第０４行目、および、第０５行目には、「＜ＢｏｄｙＵｍｉｄＢａｓｉｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”２００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｖａｌｕｅ＝”０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１１１４１１１９９９９０８００４６８Ｅ１３０Ｂ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”２００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｖａｌｕｅ＝”０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１１１４１１１９９９９０８００４６８Ｅ１３０Ｂ”」との記述により、ＦＴＣが「２００」であるとき、ＵＭＩＤ不連続点が「０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１１１４１１１９９９９０８００４６８Ｅ１３０Ｂ」であることが示されている。結果として、図２３で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が２００となるフレームからは、ＥｘｔｅｎｄｅｄＵＭＩＤが記録されているされることが示されている。
【０２６２】
第０６行目、および、第０７行目には、「＜ＢｏｄｙＵｍｉｄＢａｓｉｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”３００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｖａｌｕｅ＝”０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１３１１１１１９９９９０８００４６８Ｅ１３０Ｂ”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”３００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｖａｌｕｅ＝”０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１１１４１１１９９９９０８００４６８Ｅ１３０Ｂ”」との記述により、ＦＴＣが「２００」であるとき、ＵＭＩＤ不連続点が「０６０Ａ２Ｂ３４０１０１０１０５０１０１０Ｄ１２１３００００００００００００１０１１１１４１１１９９９９０８００４６８Ｅ１３０Ｂ」であることが示されている。結果として、図２３で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が２００となるフレームからは、ＥｘｔｅｎｄｅｄＵＭＩＤが記録されているされることが示されている。
【０２６３】
第０８行目乃至第１１行目、並びに、第１３行目乃至第１４行目については、第０２行目乃至第０７行目までの記述と同様であるので説明は省略する。また、第１２行目は、「＜ＢｏｄｙＵｍｉｄＢａｓｉｃＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”６００” ｓｔａｔｕｓ＝”ｎｏｎｅ” ／＞」と記述されており、「ｓｔａｔｕｓ＝”ｎｏｎｅ”」との記述により、ＵＭＩＤが設定されていないことが示されている。
【０２６４】
結果として、図２３で示されるように、図中のＢａｓｉｃで示されるＥｘｔｅｎｄｅｄＵＭＩＤは、ＦＴＣが１００乃至６００まで、および、７００乃至８００までのＦＴＣに対して設定されることになる。
【０２６５】
また、図２４においては、第１７行目には＜ＢｏｄｙＵｍｉｄＷｈｅｎＣｈａｎｇｅＴａｂｌｅ＞と記述されており、第２９行目に記述された＜／ＢｏｄｙＵｍｉｄＷｈｅｎＣｈａｎｇｅＴａｂｌｅ＞により、この範囲の記述がＷｈｅｎ変換テーブルであることが示されている。
【０２６６】
第１８行目には、「＜ＢｏｄｙＵｍｉｄＷｈｅｎＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”２００” ｓｔａｔｕｓ＝”ｉｎｃ” ｖａｌｕｅ＝”４４９１５Ｂ００４４４４４４８４”／＞」と記述されており、＜ＢｏｄｙＵｍｉｄＷｈｅｎＣｈａｎｇｅ・・・／＞の記述により、Ｗｈｅｎ変換テーブルであることが示されている。また、「ｆｒａｍｅＣｏｕｎｔ＝”２００” ｓｔａｔｕｓ＝”ｉｎｃ” ｖａｌｕｅ＝”４４９１５Ｂ００４４４４４４８４”」との記述により、ＦＴＣが「２００」であるとき、Ｗｈｅｎ不連続点が「４４９１５Ｂ００４４４４４４８４」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｎｃ”」と記述されており、このＦＴＣの変化点の以降のフレームが、順次１インクリメントされることが示されている。
【０２６７】
さらに、第１９行目、および、第２０行目には、「＜ＢｏｄｙＵｍｉｄＷｈｅｎＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”２９９” ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ” ｖａｌｕｅ＝”４４９１５Ｂ００４４４４４４８４”／＞」と記述されており、「ｆｒａｍｅＣｏｕｎｔ＝”２９９” ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ” ｖａｌｕｅ＝”４４９１５Ｂ００４４４４４４８４”」との記述によりＦＴＣが「２９９」であるとき、Ｗｈｅｎ不連続点が「４４９１５Ｂ００４４４４４４８４」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｉｒｒｅｇｕｌａｒ”」と記述されており、このＦＴＣの変化点でＷｈｅｎ情報が終了することが示されている。
【０２６８】
結果として、第１８行目乃至第２０行目の記述により、図２３で示されるように、ＦＴＣが２００乃至２９９までは、同一のＷｈｅｎの情報が記録されていることが示されている。
【０２６９】
以下、第２１行目乃至第２３行目、並びに、第２５行目乃至第２７行目の記述も第１８行目乃至第２０行目の記述と同様にして、図２３で示されるように、ＦＴＣが３００乃至３９９まで、および、５００乃至５９９は、同一のＷｈｅｎの情報が記録されていることが示されている。
【０２７０】
また、第２４行目には、「＜ＢｏｄｙＵｍｉｄＷｈｅｎＣｈａｎｇｅ ｆｒａｍｅＣｏｕｎｔ＝”４００” ｓｔａｔｕｓ＝”ｎｏｎｅ”／＞」との記述があり、「ｓｔａｔｕｓ＝”ｎｏｎｅ”」の記述によりＦＴＣが４００の場合、図２３で示されるように、Ｗｈｅｎの情報が存在しない（ＦＴＣが４００乃至４９９では存在しない）ことが示されている。
【０２７１】
同様に、第２８行目の記述により、図２３で示されるように、ＦＴＣが６００の場合、Ｗｈｅｎの情報が存在しない（ＦＴＣが６００乃至６９９では存在しない）ことが示されている。
【０２７２】
さらに、図２４で示されるように、第３１行目には＜ＢｏｄｙＵｍｉｄＷｈｅｒｅＣｈａｎｇｅＴａｂｌｅ＞と記述されており、第３８行目に記述された＜／ＢｏｄｙＵｍｉｄＷｈｅｒｅＣｈａｎｇｅＴａｂｌｅ＞により、この範囲の記述がＷｈｅｒｅ変換テーブルであることが示されている。
【０２７３】
尚、第３２行目乃至第３７行目の記載は、上述の記載と同様であり、第３２行目乃至第３４行目の記述により、ＦＴＣが２００乃至３００のとき、Ｗｈｅｒｅの情報が記載されていることが示されており、第３５行目乃至第３７行目の記載により、ＦＴＣが５００乃至６００のとき、Ｗｈｅｒｅの情報が記載されていることが示されている。
【０２７４】
同様に、第４０行目には＜ＢｏｄｙＵｍｉｄＷｈｏＣｈａｎｇｅＴａｂｌｅ＞と記述されており、第４９行目に記述された＜／ＢｏｄｙＵｍｉｄＷｈｏＣｈａｎｇｅＴａｂｌｅ＞により、この範囲の記述がＷｈｏ変換テーブルであることが示されている。
【０２７５】
従って、第４１行目乃至第４５行目の記述により、ＦＴＣが２００乃至４００のとき、Ｗｈｏの情報が記載されていることが示されており、第４６行目乃至第４８行目の記載により、ＦＴＣが５００乃至６００のとき、Ｗｈｏの情報が記載されていることが示されている。
【０２７６】
このように記述されることにより、図２３で示されるようにＦＴＣをＵＭＩＤ変換テーブルで検索することが可能となる。
【０２７７】
以上のように、非破壊的な編集処理の際に、エディットリストに対応するクリップメタデータを生成することにより、編集対象のデータを更新することなく、容易に、編集結果のエッセンスデータに対して新たなＵＭＩＤを付加させることができる。
【０２７８】
これにより、ユーザは、その新たなＵＭＩＤを用いることにより、編集結果より所望のフレームを検索する処理が容易になるので、その後の編集処理を容易に行うことができる。また、エディットリストを用いて編集後のエッセンスデータを再生する（編集結果を再現する）場合において、再生処理を行う装置は、その新たなＵＭＩＤに対応する変換テーブルを読み出すだけで、再生データにＵＭＩＤを付加させることができるので、再生処理時間、および再生処理の負荷を軽減させることができる。
【０２７９】
ここで、図９のフローチャートの説明に戻る。
【０２８０】
ステップＳ２において、ＵＭＩＤ編集処理が終了すると、ステップＳ３において、ＫＬＶデータ編集部５５ｂは、ＫＬＶデータ編集処理を実行する。
【０２８１】
ここで、図２５および図２６のフローチャートを参照して、エディットリスト編集部５５のＫＬＶデータ編集部５５ｂにより、図９のステップＳ３において実行されるＫＬＶデータ編集処理の詳細について説明する。なお、以下において、説明を簡略化するために、編集対象となる各クリップの画像データや音声データに付加されるＫＬＶデータは、クリップ内において、その値が全て連続しており、クリップの値が前後のフレームにおいて不連続となる変化点が存在しないものとする。また、ＫＬＶデータの変換テーブルにおいては、ＦＴＣ、Ｋｅｙデータ、および、ＬＶデータ（Ｌｅｎｇｔｈ および Ｖａｌｕｅからなるデータ）により変換テーブルが生成される。このうち、Ｋｅｙデータは、クリップメタデータものものをそのまま使用するため、変換テーブルには、ＬＶデータのみを変化させて用いる。
【０２８２】
ＫＬＶデータ編集処理を開始したエディットリスト編集部５５のＫＬＶデータ編集部５５ｂは、ステップＳ７１において、後述する処理において用いられる各変数の値を、例えば値「０」を代入する等して初期化する。
【０２８３】
変数の初期化が終了するとＫＬＶデータ編集部５５ｂは、ステップＳ７２に処理を進め、ユーザ入力に基づいて、編集後の画像データに対して１本化された新たなＬＶデータを対応させるようなＫＬＶデータ変換テーブルを生成するか否かを判定する。
【０２８４】
ＫＬＶデータ編集部５５ｂは、出力部６２を制御してディスプレイ等にＧＵＩ等を表示させ、入力部６１を制御し、ユーザに、エディットリスト用クリップメタデータに含まれるＫＬＶデータ変換テーブルを生成する際の条件を入力させる。具体的には、ＫＬＶデータ編集部５５ｂは、編集後の画像データに対して、１本化された新たなＬＶデータを対応させるように変換テーブルを生成するか否かの条件をユーザに入力させる。
【０２８５】
ＫＬＶデータ編集部５５ｂは、このように入力されたユーザ入力に基づいて、編集後の画像データに対して１本化された新たなＬＶデータを対応させるようなＫＬＶデータ変換テーブルを生成するか否かを判定し、そのようなＫＬＶデータ変換テーブルを生成すると判定した場合、ステップＳ７３に処理を進め、入力部６１を制御して、ＬＶデータの初期値の入力を受け付ける。
【０２８６】
編集後の画像データに対して１本化された新たなＬＶデータを対応させる場合、ユーザは、先頭のフレームに対応するＬＶデータの値である初期値を設定することができ、初期値を設定する場合、入力部６１を操作することにより、初期値を入力する。
【０２８７】
ＫＬＶデータ編集部５５ｂは、ステップＳ７４に処理を進め、入力部６１を制御し、このユーザからの入力に基づいて、初期値が入力されたか否かを判定する。初期値が入力されたと判定した場合、ＫＬＶデータ編集部５５ｂは、ステップＳ７５に処理を進め、ＬＶデータの初期値を示す変数ＬｖＳｔａｒｔに、入力された初期値を代入し、ステップＳ７７に処理を進める。
【０２８８】
なお、ステップＳ７４において、ＬＴＣの初期値が入力されていないと判定した場合、ＫＬＶデータ編集部５５ｂは、ステップＳ７６に処理を進め、変数ＬｖＳｔａｒｔに値「０」を代入し、ステップＳ７７に処理を進める。
【０２８９】
ステップＳ７７において、ＫＬＶデータ編集部５５ｂは、ＫＬＶデータ変換テーブルに登録するＬＶデータの値を示す変数ＬｖＮｕｍに変数ＬｖＳｔａｒｔの値を代入し、ＫＬＶ変換テーブルに登録するフレーム番号を示す変数ＦｒａｍｅＮｕｍに値「０」を代入し、変数ＬｖＮｕｍ、変数ＦｒａｍｅＮｕｍ、および、Ｋｅｙデータの各値を互いに関連付けて記憶部６３に記憶させることにより、それらの値を開始点として編集後の画像データに対応するＫＬＶデータ変換テーブルに登録する。
【０２９０】
ところで、編集後の画像データに対して、１本化された新たなＬＶデータを対応させるようにする場合、ＬＶデータの値の増加は全て連続し、開始点以外のフレームにおいて不連続点が発生しない。すなわち、従って、ＫＬＶデータ編集部５５ｂは、ステップＳ７７の処理により、編集後の画像データに対して、１本化された新たなＬＶデータを付加するようなＫＬＶ変換テーブルには、開始点におけるＫＬＶデータの値、および開始点におけるフレーム番号（すなわち、「０」）と、対応するＫｅｙデータが登録される。
【０２９１】
従って、ステップＳ７７の処理を終了し、開始点をＫＬＶデータ変換テーブルに登録したＫＬＶデータ編集部５５ｂは、ＫＬＶデータ編集処理を終了する。
【０２９２】
なお、図２５のステップＳ７２の処理において、編集後の画像データに対して１本化された新たなＬＶデータを付加するようなＫＬＶデータ変換テーブルを生成しないと判定した場合、ＫＬＶデータ編集部５５ｂは、図２６のステップＳ８１に処理を進め、処理の対象とするクリップを選択するための変数ＣｌｉｐＮｕｍに値「１」を代入する。
【０２９３】
ステップＳ８２において、ＫＬＶデータ編集部５５ｂは、ＣｌｉｐＮｕｍ番目のクリップのクリップメタデータに含まれる、ＬＶデータ、フレーム番号、および、ＫｅｙデータとのＫＬＶデータ変換テーブルを参照し、指定された範囲の開始点のＬＶデータと、指定された範囲のフレーム数を算出してその値を変数ＣｌｉｐＦｒａｍｅに代入し、指定された範囲の開始点のＬＶデータを変数ＬｖＮｕｍに代入する。すなわち、ＫＬＶデータ編集部５５ｂは、例えば、光ディスク１７に記録されたクリップの内、ＣｌｉｐＮｕｍ番目のクリップの画像データに注目し、その画像データの全フレームの内、編集結果として採用される部分のフレームのフレーム数を算出し、その値を変数ＣｌｉｐＦｒａｍｅに代入する。また、ＫＬＶデータ編集部５５ｂは、クリップデータのＫＬＶ変換テーブルを参照し、その編集結果として採用される部分の最初のフレームの、編集結果である画像データにおけるフレーム番号を算出し、その算出結果を変数ＬｖＮｕｍに代入する。
【０２９４】
ステップＳ８２の処理を終了したＫＬＶデータ編集部５５ｂは、ステップＳ８３に処理を進め、変数ＬｖＮｕｍ、変数ＦｒａｍｅＮｕｍ、および、Ｋｅｙデータを互いに関連付けて記憶部６３に記憶させることにより、それらの値を編集後の画像データに対応するＫＬＶデータ変換テーブルに登録する。
【０２９５】
指定された範囲内におけるＬＶデータの開始点をＫＬＶデータ変換テーブルに登録したＫＬＶデータ編集部５５ｂは、ステップＳ８４に処理を進め、処理対象としたクリップが最後のクリップであるか否かを判定し、また未処理のクリップが存在し、最後のクリップではないと判定した場合、ステップＳ８５に処理を進める。
【０２９６】
ＫＬＶデータ編集部５５ｂは、ステップＳ８５において、変数ＦｒａｍｅＮｕｍの値に変数ＣｌｉｐＦｒａｍｅの値を加算し、ステップＳ８６において、変数ＣｌｉｐＮｕｍに値「１」を加算し、次のクリップに対する演算処理が行えるように準備する。
【０２９７】
ステップＳ８６の処理を終了したＫＬＶデータ編集部５５ｂは、ステップＳ８２に処理を戻し、それ以降の処理を繰り返す。
【０２９８】
ＫＬＶデータ編集部５５ｂは、以上のように、ステップＳ８２乃至ステップＳ８６の処理を繰り返し、全てのクリップに対して、このような処理を行う。そして、全てのクリップに対して上述した処理を終了し、ステップＳ８４において、最後のクリップであると判定した場合、ＫＬＶデータ編集部５５ｂは、ＫＬＶデータ編集処理を終了し、図９のエディットリスト用クリップメタデータ処理を終了する。
【０２９９】
以上のようにして、ＫＬＶデータ編集部５５ｂは、図２５および図２６のフローチャートを参照して説明したＫＬＶデータ編集処理を行い、エディットリストに対応するＫＬＶデータ変換テーブルを生成することができる。
【０３００】
なお、上述した各種の変数は、１つの例であり、上述した以外の変数を用いるようにしても良い。
【０３０１】
また、以上においては、編集対象となるクリップの画像データや音声データに対応させられるＬＶデータは、クリップ内において、その値が連続している場合のＫＬＶデータ編集処理について説明した。しかしながら、ＬＶデータの値がクリップ内において不連続となる（クリップ内にＬＶデータの変化点が存在する）場合もある。そのような場合、上述したＫＬＶデータ編集処理において、各クリップの指定された範囲の開始点におけるＬＶデータの値と、そのＬＶデータが対応するフレームの、エディットリスト上の画像データ（編集後の画像データ）におけるフレーム番号に加えて、Ｋｅｙデータを対応付けてＫＬＶデータ変換テーブルに登録するとともに、各クリップのＬＶデータの変化点（直前のフレームのＬＶの値と不連続となる値のＬＶデータが付加されたフレーム）に対しても、同様に、ＬＶデータの値と、そのＬＶデータが対応するフレームの、エディットリスト上の画像データ（編集後の画像データ）におけるフレーム番号とＫｅｙデータを対応付けてＫＬＶデータ変換テーブルに登録するようにすればよい。
【０３０２】
なお、図２５のステップＳ７４の処理において、ユーザよりＬＶデータの初期値に関する入力が無いと判定した場合、ＫＬＶデータ編集部５５ｂは、ステップＳ７６において、変数ＬｖＳｔａｒｔに値「０」を代入する処理を行うように説明したが、これに限らず、例えば、通信部６４を介す等して現在の実際の時刻に関する情報を取得し、その取得した現在の実際の時刻の値を変数ＬｖＳｔａｒｔに登録するようにしてもよい。
【０３０３】
次に、複数のクリップを合成して１つのクリップを再生する編集作業における、エディットリスト上のエッセンスデータ（編集後のエッセンスデータ）に対応するＬＶデータであるエディットリスト用ＫＬＶデータの変換テーブルが生成される様子の具体的な例について説明する。なお、以下においては、編集対象のデータとして、画像データについてのみ説明するが、実際には、音声データ、ローレゾデータ、およびフレームメタデータについても同様に編集される。
【０３０４】
図２７は、編集結果としての画像データに対して１本化された新たなＬＴＣを対応させるようなＬＴＣ変換テーブルを生成しない場合の編集処理において、エディットリスト用のＫＬＶデータ（Ｋｅｙデータとあわせたエディットリスト用のＫＬＶデータ変換テーブル）が生成される様子の例を示す図である。
【０３０５】
図２７において、クリップ１およびクリップ２は、例えば、光ディスク１７に記録されているクリップであり、編集対象となるクリップである。すなわち、この編集処理により、クリップ１の画像データ５１０およびクリップ２の画像データ５２０は、それぞれ、その一部分が抽出され、編集後のエディットリスト上の画像データ５３０として、１つの画像データに合成される。
【０３０６】
画像データ５１０および画像データ５２０には、それぞれ、ＬＶデータ（クリップ用ＬＶデータ）が付加されている。クリップ用ＬＶデータとは、編集前のクリップのフレームメタデータに含まれるＬＶデータのことである。図２７において、画像データ５１０の全フレームの内、編集後の画像データ（エディットリスト上の画像データ５３０）として抽出される部分の最初のフレーム（ＩＮ点）のＬＶデータ５１１の値は、「０００１０００００００」である。
【０３０７】
また、画像データ５１０の全フレームの内、編集後の画像データ（エディットリスト上の画像データ５３０）として抽出される部分の最後のフレーム（ＯＵＴ点）のＬＴＣ５１２の値は、「００：４０：００：００」である。同様に、画像データ５２０のＩＮ点のＬＴＣ５２１の値は、「００：０５：００：００」であり、ＯＵＴ点のＬＴＣ５２２の値は、「００：３５：００：００」である。
【０３０８】
通常、図２７に示されるような、光ディスク１７等に記録されたクリップの画像データや音声データは、撮像装置１４における撮像処理により得られたデータであり、編集処理が施されていないデータである。すなわち、そのような場合、編集対象となるクリップの画像データや音声データに付加されたクリップ用ＬＶデータは、その値が前後のフレームで不連続となる不連続点（変化点）が存在しないことが多い。従って、図２７において、説明を簡略化するために、画像データ５１０または画像データ５２０において、ＬＶデータの値が不連続となる変化点は存在しないものとするが、変化点が含まれるようにしてももちろんよい。
【０３０９】
ＫＬＶデータ編集部５５ｂが、このような画像データ５１０および５２０を用いて、上述したように、編集後のエディットリスト上の画像データ５３０に対して１本化された新たなＬＶデータ（とＫｅｙデータ）を対応させるようなＫＬＶデータ変換テーブルを生成しない編集処理を行った場合、図２５および図２６のフローチャートのような処理が行われ、ＦＴＣ（フレーム番号）、ＬＶデータ（エディットリスト用ＬＶデータ）、および、Ｋｅｙデータが関連付けられて登録された、エディットリスト上の画像データ５３０に対応するＫＬＶデータ変換テーブルが生成される。
【０３１０】
すなわち、このＫＬＶデータ変換テーブルには、画像データ５１０におけるＩＮ点のエディットリスト用ＬＶデータおよびフレーム番号（ＦＴＣ）、並びに、画像データ５２０におけるＩＮ点のエディットリスト用ＬＶデータおよびフレーム番号（ＦＴＣ）が登録される。
【０３１１】
図２７の場合、画像データ５１０のＩＮ点においては、ＦＴＣ５３１の値は、画像データ５３０の先頭フレームでもあるので、「０００００００００００」となり、エディットリスト用ＬＶデータ５３４の値は、画像データ５１０のクリップ用ＬＶデータの値と同一の「０００１０００００００」となる。
【０３１２】
また、画像データ５２０のＩＮ点においては、ＦＴＣ５３２の値は、抽出された画像データ５１０のフレーム数がＦＴＣ５３１の値に加算され、「００：３０：００：００」となり、エディットリスト用ＬＶデータ５３５の値は、画像データ５２０のクリップ用ＬＶデータの値と同一の「００００５００００００」となる。
【０３１３】
なお、ＫＬＶデータ変換テーブルには登録されないが、画像データ５２０より抽出された部分における最後のフレームである、画像データ５２０におけるＯＵＴ点に対応するＦＴＣ５３３の値は、抽出された画像データ５２０のフレーム数がＦＴＣ５３２の値に加算され、「０１：００：００：００」となる。
【０３１４】
以上のように、編集結果としての画像データに対して１本化された新たなＬＶデータを対応させるようなＫＬＶデータ変換テーブルを生成せずに、編集前のデータに対応するクリップＬＶデータを利用して、エディットリストに対応するＫＬＶデータ変換テーブルを生成する場合、エディットリスト用ＬＶデータの値は不連続となる場合がある。
【０３１５】
図２８は、編集結果としての画像データに対して１本化された新たなＬＶデータを対応させるようなＫＬＶデータ変換テーブルを生成する場合の編集処理において、エディットリスト用のＬＶデータ（Ｋｅｙデータとあわせたエディットリスト用のＫＬＶデータ変換テーブル）が生成される様子の例を示す図である。
【０３１６】
図２８において、クリップ１およびクリップ２は、図２７と同様に、編集対象となるクリップである。すなわち、この編集処理により、クリップ１の画像データ５５０およびクリップ２の画像データ５６０は、それぞれ、その一部分が抽出され、編集後のエディットリスト上の画像データ５７０として、１つの画像データに合成される。
【０３１７】
画像データ５５０および画像データ５６０には、それぞれ、ＬＶデータ（クリップ用ＬＶデータ）が付加されている。クリップ用ＬＶデータとは、編集前のクリップのフレームメタデータに含まれるＬＶデータのことである。図２８において、画像データ５５０のＩＮ点のＬＶデータ５５１の値は、「０００１０００００００」である。
【０３１８】
また、画像データ５５０のＯＵＴ点のＬＴＣ５５２の値は、「００：４０：００：００」である。同様に、画像データ５６０のＩＮ点のＬＴＣ５６１の値は、「００：０５：００：００」であり、ＯＵＴ点のＬＴＣ５６２の値は、「００：３５：００：００」である。なお、図２８において、説明を簡略化するために、図２７と同様に、画像データ５５０または画像データ５６０において、ＬＶデータの値が不連続となる変化点は存在しないものとするが、変化点が含まれるようにしてももちろんよい。
【０３１９】
ＫＬＶデータ編集部５５ｂが、このような画像データ５５０および５６０を用いて、上述したように、編集後のエディットリスト上の画像データ５７０に対して１本化された新たなＬＶデータを付加するようなＫＬＶデータ変換テーブルを生成する編集処理を行った場合、図２５、および、図２６のフローチャートのような処理が行われ、ＦＴＣ（フレーム番号）とＬＶデータ（エディットリスト用ＬＶデータ）が関連付けられて登録された、エディットリスト上の画像データ５７０に対応するＫＬＶデータ変換テーブルが生成される。
【０３２０】
すなわち、このＫＬＶデータ変換テーブルには、画像データ５５０におけるＩＮ点に対応するエディットリスト用ＬＶデータ、フレーム番号（ＦＴＣ）、および、Ｋｅｙデータが登録される。
【０３２１】
図２８の場合、画像データ５７０の先頭フレームであり、画像データ５５０のＩＮ点に対応するフレームにおけるＦＴＣ５７１の値は「００：００：００：００」となり、エディットリスト用ＬＶデータ５７４の値は、ユーザにより設定された初期値となっており、画像データ５５０のクリップ用ＬＴＣ５５１の値とは異なる「００：３０：００：００」となる。
【０３２２】
また、画像データ５６０のＩＮ点においては、ＦＴＣ５７２の値は、抽出された画像データ５５０のフレーム数がＦＴＣ５７１の値に加算され、「００：３０：００：００」となる。
【０３２３】
なお、ＫＬＶデータ変換テーブルには登録されないが、画像データ５６０のＩＮ点およびＯＵＴ点にそれぞれ対応するＦＴＣ５７２およびＦＴＣ５７３の値は、それぞれ、「００：３０：００：００」および「０１：００：００：００」となる。
【０３２４】
以上のように、編集結果としての画像データに対して１本化された新たなＬＶデータを対応させるようなＫＬＶデータ変換テーブルを生成する場合、生成されたエディットリストに対応するＫＬＶデータ変換テーブルには、上述した開始点以外の不連続点（変化点）が登録されていないので、エディットリスト上の画像データ５７０に対応するエディットリスト用ＬＶデータは、値が連続する（不連続点が存在しない）ＬＶデータとなる。
【０３２５】
図２５および図２６による編集により生成された、エディットリスト用クリップメタデータに含まれるＫＬＶデータ変換テーブル（エディットリスト用ＬＶデータとＫｅｙデータに対応する変換テーブル）の構成例について、図２９Ａ，Ｂを参照して説明する。
【０３２６】
図２９Ａは、図２７の編集により生成されたＫＬＶデータ変換テーブルの構成例を示す模式図である。このＫＬＶデータ変換テーブルは、編集処理ごとに生成される、リアルタイム性を要求されないメタデータであるので、エディットリストディレクトリ以下に設けられるエディットリスト用クリップメタデータファイルに記録される。
【０３２７】
図２９Ａの場合、ＫＬＶデータ変換テーブル５８０は、図６を参照して説明したエディットリスト用クリップメタデータファイル（Ｅ０００２Ｍ０１．ＸＭＬ）１７２に記録される。ＫＬＶデータ変換テーブル５８０は、上述したように、フレーム番号（ＦＴＣ）５８１、ＬＶデータ不連続点５８２、および、Ｋｅｙデータの項目からなるテーブルであり、この場合、開始点（図２７のクリップ１のＩＮ点）の他に、変化点（図２７のクリップ２のＩＮ点）が不連続点として登録されている。
【０３２８】
図２９Ｂは、図２８の編集により生成された変換テーブルの構成例を示す模式図である。この変換テーブルは、編集処理ごとに生成される、リアルタイム性を要求されないメタデータであるので、エディットリストディレクトリ以下に設けられるエディットリスト用クリップメタデータファイルに記録される。
【０３２９】
図２９Ｂの場合、ＫＬＶデータ変換テーブル５８０は、図６を参照して説明したエディットリスト用クリップメタデータファイル（Ｅ０００２Ｍ０１．ＸＭＬ）１７２に記録される。ＫＬＶデータ変換テーブル５８０は、上述したように、フレーム番号（ＦＴＣ）５８１、ＬＶデータ不連続点５８２、および、Ｋｅｙデータの項目からなるテーブルであり、この場合、開始点（図２８のクリップ１のＩＮ点）のみが不連続点として登録されている。ただし、この場合、ＬＶデータ不連続点５８２には、ユーザが編集の際に設定した初期値が登録されている。尚、図２７乃至図２９においては、説明の便宜上、ＬＶデータが１１バイト、Ｋｅｙデータが５バイトであるものとする。
【０３３０】
次に、ＫＬＶデータ変換テーブルのＸＭＬでの記述例について説明する。
【０３３１】
例えば、図３０で示されるようにＫＬＶデータについて、横軸にフレーム番号（Ｆｒａｍｅ Ｃｏｕｎｔ）（ＦＴＣに対応する値）を取ったときに示されるような再生される画像が存在する場合、ＦＴＣに対応したＫＬＶデータ不連続点を示すＫＬＶデータ変換テーブルは、図３１で示されるように記述される。
【０３３２】
図３１においては、第０１行目には＜ＫｌｖＰａｃｋｅｔＴａｂｌ＞と記述されており、第１５行目に記述された＜／ＫｌｖＰａｃｋｅｔＴａｂｌｅ＞により、この範囲の記述がＫＬＶデータ変換テーブルであることが示されている。
【０３３３】
第０２行目、および、第０３行目には、「＜ＫｌｖＰａｃｋｅｔ ｆｒａｍｅＣｏｕｎｔ＝”０” ｓｔａｔｕｓ＝”ｓｐｏｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”０９５Ｆ５２６５６３５３７４６１７２７４”／＞」と記述されており、＜ＫｌｖＰａｃｋｅｔ・・・／＞の記述により、ＫＬＶデータ変換テーブルであることが示されている。また、「ｆｒａｍｅＣｏｕｎｔ＝”０” ｓｔａｔｕｓ＝”ｓｐｏｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”０９５Ｆ５２６５６３５３７４６１７２７４”」との記述により、ＦＴＣが「０」であるとき、ＫＬＶデータ不連続点におけるＫｅｙデータが「０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００」であり、ここではＴｅｒｍ Ｖａｌｕｅであることが示され、ＬＶデータが、「０９５Ｆ５２６５６３５３７４６１７２７４」であり、ここでは、ＲｅｃＳｔａｒｔであることが示されている。さらに、「ｓｔａｔｕｓ＝”ｓｐｏｔ”」と記述されており、このＦＴＣの変化点にのみ関係するものであることが示されている。結果として、図３０で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が１００となるフレームにおいて、ＲｅｃＳｔａｒｔであることが示される。
【０３３４】
第０４行目、および、第０５行目には、「＜ＫｌｖＰａｃｋｅｔ ｆｒａｍｅＣｏｕｎｔ＝”２００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０１０３０２０１０２０５００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”０５４Ａ６１７０６１６Ｅ”／＞」と記述されており「ｆｒａｍｅＣｏｕｎｔ＝”２００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０１０３０２０１０２０５００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”０５４Ａ６１７０６１６Ｅ”」との記述により、ＦＴＣが「２００」であるとき、ＫＬＶデータ不連続点におけるＫｅｙデータが「０６０Ｅ２Ｂ３４０１０１０１０１０３０２０１０２０５００００００」であり、ここではＫｅｙ Ｗｏｒｄであることが示され、ＬＶデータが、「０５４Ａ６１７０６１６Ｅ」であり、ここでは、「Ｊａｐａｎ」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｓｔａｒｔ”」と記述されており、このＦＴＣの変化点から開始するものであることが示されている。結果として、図３０で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が２００となるフレームから、Ｋｅｙ Ｗｏｒｄとして「Ｊａｐａｎ」となる情報が記録されていることが示される。
【０３３５】
第０６行目には、「＜ＫｌｖＰａｃｋｅｔ ｆｒａｍｅＣｏｕｎｔ＝”３００” ｓｔａｔｕｓ＝”ｎｏｎｅ”／＞」と記述されており、ＦＴＣが「２００」から記録されているＫｅｙ ＷｏｒｄのＪａｐａｎは、ＦＴＣが「３００」まで記録されていることが示されている。
【０３３６】
第０７行目、および、第０８行目には、「＜ＫｌｖＰａｃｋｅｔ ｆｒａｍｅＣｏｕｎｔ＝”４００” ｓｔａｔｕｓ＝”ｓｐｏｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”８３０００００６５Ｆ４６６Ｃ６１７３６８”／＞」と記述されており「ｆｒａｍｅＣｏｕｎｔ＝”４００” ｓｔａｔｕｓ＝”ｓｐｏｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”８３０００００６５Ｆ４６６Ｃ６１７３６８”」との記述により、ＦＴＣが「４００」であるとき、ＫＬＶデータ不連続点におけるＫｅｙデータが「０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００」であり、ここではＴｅｒｍ Ｖａｌｕｅであることが示され、ＬＶデータが、「８３０００００６５Ｆ４６６Ｃ６１７３６８」であり、ここでは、「Ｆｌａｓｈ」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｓｐｏｔ”」と記述されており、このＦＴＣの変化点にのみ関係するものであることが示されている。結果として、図３０で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が４００となるフレームにおいて、Ｆｌａｓｈであることが示される。
【０３３７】
第０９行目、および、第１０行目には、「＜ＫｌｖＰａｃｋｅｔ ｆｒａｍｅＣｏｕｎｔ＝”５００” ｓｔａｔｕｓ＝”ｓｐｏｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２０１００００” ｌｅｎｇｔｈＶａｌｕｅ＝”８３０００００６６５Ｅ５６７２Ｃ８Ａ９Ｅ”／＞」と記述されており「ｆｒａｍｅＣｏｕｎｔ＝”５００” ｓｔａｔｕｓ＝”ｓｐｏｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２０１００００” ｌｅｎｇｔｈＶａｌｕｅ＝”８３０００００６６５Ｅ５６７２Ｃ８Ａ９Ｅ”」との記述により、ＦＴＣが「５００」であるとき、ＫＬＶデータ不連続点におけるＫｅｙデータが「０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２０１００００」であり、ここではＴｅｒｍ Ｖａｌｕｅであることが示され、ＬＶデータが、「８３０００００６６５Ｅ５６７２Ｃ８Ａ９Ｅ」であり、ここでは、「日本語」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｓｐｏｔ”」と記述されており、このＦＴＣの変化点にのみ関係するものであることが示されている。結果として、図３０で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が５００となるフレームにおいて、「日本語」であることが示される。
【０３３８】
第１１行目、および、第１２行目には、「＜ＫｌｖＰａｃｋｅｔ ｆｒａｍｅＣｏｕｎｔ＝”６００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０１０３０２０１０２０５００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”０２５５５３”／＞」と記述されており「ｆｒａｍｅＣｏｕｎｔ＝”６００” ｓｔａｔｕｓ＝”ｓｔａｒｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０１０３０２０１０２０５００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”０２５５５３”」との記述により、ＦＴＣが「６００」であるとき、ＫＬＶデータ不連続点におけるＫｅｙデータが「０６０Ｅ２Ｂ３４０１０１０１０１０３０２０１０２０５００００００」であり、ここではＫｅｙ Ｗｏｒｄであることが示され、ＬＶデータが、「０２５５５３」であり、ここでは、「ＵＳ」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｓｔａｒｔ”」と記述されており、このＦＴＣの変化点から開始するものであることが示されている。結果として、図３０で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が６００となるフレームから、Ｋｅｙ Ｗｏｒｄとして「ＵＳ」となる情報が記録されていることが示される。
【０３３９】
第１３行目には、「＜ＫｌｖＰａｃｋｅｔ ｆｒａｍｅＣｏｕｎｔ＝”７００” ｓｔａｔｕｓ＝”ｎｏｎｅ”／＞」と記述されており、ＦＴＣが「６００」から記録されているＫｅｙ ＷｏｒｄのＵＳは、ＦＴＣが「７００」まで記録されていることが示されている。
【０３４０】
第１４行目乃至第１６行目には、「ＫｌｖＰａｃｋｅｔ ｆｒａｍｅＣｏｕｎｔ＝”８００” ｓｔａｔｕｓ＝”ｓｐｏｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”８３０００００７５Ｆ５２６５６３４５６Ｅ６４”／＞」と記述されており「ｆｒａｍｅＣｏｕｎｔ＝”８００” ｓｔａｔｕｓ＝”ｓｐｏｔ” ｋｅｙ＝”０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００” ｌｅｎｇｔｈＶａｌｕｅ＝”８３０００００７５Ｆ５２６５６３４５６Ｅ６４”」との記述により、ＦＴＣが「８００」であるとき、ＫＬＶデータ不連続点におけるＫｅｙデータが「０６０Ｅ２Ｂ３４０１０１０１０５０３０１０２０Ａ０２００００００」であり、ここではＴｅｒｍ Ｖａｌｕｅであることが示され、ＬＶデータが、「８３０００００７５Ｆ５２６５６３４５６Ｅ６４」であり、ここでは、「ＲｅｃＥｎｄ」であることが示されている。さらに、「ｓｔａｔｕｓ＝”ｓｐｏｔ”」と記述されており、このＦＴＣの変化点にのみ関係するものであることが示されている。結果として、図３０で示されるように、ＦＴＣ（Ｆｒａｍｅ Ｃｏｕｎｔ）が８００となるフレームにおいて、「ＲｅｃＥｎｄ」であることが示される。
【０３４１】
このように記述されることにより、図３０で示されるようにＦＴＣをＵＭＩＤ変換テーブルで検索することが可能となる。
【０３４２】
以上のように、非破壊的な編集処理の際に、エディットリストに対応するクリップメタデータを生成することにより、編集対象のデータを更新することなく、容易に、編集結果のエッセンスデータに対して新たなＫＬＶデータを付加させることができる。
【０３４３】
これにより、ユーザは、その新たなＫＬＶデータを用いることにより、編集結果より所望のフレームを検索する処理が容易になるので、その後の編集処理を容易に行うことができる。また、エディットリストを用いて編集後のエッセンスデータを再生する（編集結果を再現する）場合において、再生処理を行う装置は、その新たなＫＬＶデータに対応する変換テーブルを読み出すだけで、再生データにＫＬＶデータを付加させることができるので、再生処理時間、および再生処理の負荷を軽減させることができる。
【０３４４】
なお、実際には、上述した以外にも、早送り再生、巻き戻し再生、一時停止、コマ送り再生等、様々な再生動作の方法が存在するが、上述した読み出し処理を用いて読み出し開始位置（フレーム）を決定し、それらの再生動作を行うように読み出し制御を行えばよいので、それらについての説明は省略する。
【０３４５】
また、以上においては、リアルタイム性を要求されるメタデータを、フレーム毎のメタデータであるフレームメタデータとするように説明したが、これに限らず、どのような単位のエッセンスデータに対するメタデータであってもよく、例えば、複数のフレーム毎のメタデータとしてもよい。
【０３４６】
さらに、リアルタイム性を要求されないメタデータを、クリップ毎のメタデータであるクリップメタデータとするように説明したが、これに限らず、どのような単位のエッセンスデータに対するメタデータであってもよく、例えば、複数のクリップ毎のメタデータとしてもよいし、予め定められた所定の時間分のエッセンスデータに対するメタデータであってもよい。
【０３４７】
また、以上においては、画像データ、音声データ、ローレゾデータ、フレームメタデータ、クリップメタデータ、およびエディットリスト等のデータを光ディスクに記録する場合について、説明したが、これらの各データを記録する記録媒体としては、光ディスクに限らず、例えば、光磁気ディスク、フレキシブルディスクやハードディスク等の磁気ディスク、磁気テープ、または、フラッシュメモリ等の半導体メモリであってもよい。
【０３４８】
さらに、以上においては、編集用端末装置１６において、編集を行う場合について説明したが、編集を行う情報処理装置としては、これに限らず、例えば、図１の企画用端末装置１１、撮像装置１４、またはフィールドＰＣ１５であってもよいし、それ以外の情報処理装置であってもよい。
【０３４９】
以上のように、本発明を適用した情報処理装置は、第１のデータのメタデータである第１のメタデータに基づいて、第２のデータに対応するメタデータである第２のメタデータを生成し、生成した第２のメタデータを第１のメタデータのファイルと異なるファイルに登録し、第１のメタデータには、第１のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第１の識別情報と、第１のデータに含まれる、画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含むようにし、第２のメタデータには、第２のデータに含まれる、画像データの各フレームの制御情報を識別する複数の第３の識別情報と、第２のデータに含まれる画像データの各フレームの、先頭のフレームを基準として相対的に制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含むようにすればよく、このような内容の処理と同様の処理であれば、どのような方法で処理を行ってもよいし、このような処理以外の処理をさらに行ってもよい。また、本発明を適用した情報処理装置の構成は、このような処理を実行可能であれば、図２に示される構成以外の構成であってももちろんよい。
【０３５０】
上述した一連の処理は、ハードウェアにより実行させることもできるし、上述したようにソフトウェアにより実行させることもできる。一連の処理をソフトウェアにより実行させる場合には、そのソフトウェアを構成するプログラムが専用のハードウェアに組み込まれているコンピュータ、または、各種のプログラムをインストールすることで、各種の機能を実行することが可能な、例えば汎用のパーソナルコンピュータなどに、記録媒体等からインストールされる。
【０３５１】
記録媒体は、図２に示されるように、編集用端末装置１６とは別に、ユーザにプログラムを提供するために配布される、プログラムが記録されている磁気ディスク（フレキシブルディスクを含む）、光ディスク（ＣＤ−ＲＯＭ（Ｃｏｍｐａｃｔ Ｄｉｓｃ−Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ），ＤＶＤ（Ｄｉｇｉｔａｌ Ｖｅｒｓａｔｉｌｅ Ｄｉｓｃ）、光磁気ディスクを含む）、若しくは半導体メモリなどよりなるパッケージメディアを含むリムーバブルメディア７１により構成されるだけでなく、コンピュータに予め組み込まれた状態でユーザに提供される、プログラムが記憶されているＲＯＭ５２や記憶部６３が含まれるハードディスクなどで構成される。
【０３５２】
なお、本明細書において、媒体により提供されるプログラムを記述するステップは、記載された順序に従って、時系列的に行われる処理は勿論、必ずしも時系列的に処理されなくとも、並列的あるいは個別に実行される処理をも含むものである。
【０３５３】
また、本明細書において、システムとは、複数の装置により構成される装置全体を表すものである。
【０３５４】
【発明の効果】
以上のように、本発明によれば、画像データや音声データ等を記録媒体に記録することができる。特に、ＬＴＣ、ＵＭＩＤ、および、ＫＬＶデータを用いて、より容易に編集処理を行うことができるようにする等の、記録媒体の利便性を向上させることができる。
【図面の簡単な説明】
【図１】本発明を適用した映像プログラム制作支援システムの構成例を示す図である。
【図２】図１の編集用端末装置の内部の構成例を示すブロック図である。
【図３】図１の光ディスクに記録されたデータの構成例を示す模式図である。
【図４】ファイルシステムによるデータを管理するためのディレクトリ構造の例を示す図である。
【図５】図４に示されるディレクトリ構造のさらに詳細な構成例を示す図である。
【図６】図４に示されるディレクトリ構造のさらに詳細な構成例を示す図である。
【図７】ＫＬＶ符号化されたデータのデータ構造を説明する模式図である。
【図８】ＵＭＩＤのデータ構造を説明する模式図である。
【図９】図２のエディット編集部によるエディットリスト用クリップメタデータ処理について説明するフローチャートである。
【図１０】図８のステップＳ１において実行されるＬＴＣ編集処理について説明するフローチャートである。
【図１１】図８のステップＳ１において実行されるＬＴＣ編集処理について説明する、図１０に続くフローチャートである。
【図１２】エディットリスト用ＬＴＣ変換テーブルを生成する様子の例を説明する図である。
【図１３】エディットリスト用ＬＴＣ変換テーブルを生成する様子の、他の例を説明する図である。
【図１４】エディットリストに対応するＬＴＣ変換テーブルの構成例を示す模式図である。
【図１５】ＬＴＣの変化を示す図である。
【図１６】図１５に対応したＬＴＣ変換テーブルの記述例を示す図である。
【図１７】図８のステップＳ２において実行されるＵＭＩＤ編集処理について説明するフローチャートである。
【図１８】図８のステップＳ１において実行されるＵＭＩＤ編集処理について説明する、図１７に続くフローチャートである。
【図１９】エディットリスト用ＵＭＩＤ変換テーブルを生成する様子の例を説明する図である。
【図２０】エディットリスト用ＵＭＩＤ変換テーブルを生成する様子の、他の例を説明する図である。
【図２１】エディットリストに対応するＵＭＩＤ変換テーブルの構成例を示す模式図である。
【図２２】エディットリストに対応するＵＭＩＤ変換テーブルの構成例を示す模式図である。
【図２３】ＵＭＩＤの変化を示す図である。
【図２４】図２３に対応したＵＭＩＤ変換テーブルの記述例を示す図である。
【図２５】図８のステップＳ３において実行されるＫＬＶデータ編集処理について説明するフローチャートである。
【図２６】図８のステップＳ３において実行されるＫＬＶデータ編集処理について説明する、図２５に続くフローチャートである。
【図２７】エディットリスト用ＫＬＶデータ変換テーブルを生成する様子の例を説明する図である。
【図２８】エディットリスト用ＫＬＶデータ変換テーブルを生成する様子の、他の例を説明する図である。
【図２９】エディットリストに対応するＫＬＶデータ変換テーブルの構成例を示す模式図である。
【図３０】ＫＬＶデータの変化を示す図である。
【図３１】図３０に対応したＵＭＩＤ変換テーブルの記述例を示す図である。
【符号の説明】１ 映像プログラム制作支援システム， １１ 企画用端末装置， １２ ネットワーク， １３ 取材用端末装置， １４ 撮像装置，１５ フィールドＰＣ， １６ 編集用端末装置， １７ 光ディスク， ５４クリップデータ編集部， ５５ エディットリスト編集部， ５５ａ ＵＭＩＤ編集部， ５５ｂ ＫＬＶデータ， ５５ｃ ＬＴＣ編集部， １６２ クリップメタデータファイル， １７２ エディットリスト用クリップメタデータファイル， １９０ ＫＬＶデータ

Claims (9)

1. 画像データを含む第１のデータの編集処理を行い、前記編集処理により生成される編集後の前記第１のデータである第２のデータを、前記第１のデータのファイルと異なるファイルとして管理する情報処理装置において、
   前記第１のデータのメタデータである第１のメタデータに基づいて、前記第２のデータに対応するメタデータである第２のメタデータを生成する生成手段と、
   前記生成手段により生成された前記第２のメタデータを前記第１のメタデータのファイルと異なるファイルに登録する登録手段とを備え、
   前記第１のメタデータは、前記第１のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第１の識別情報と、前記第１のデータに含まれる、前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、
   前記第２のメタデータは、前記第２のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第３の識別情報と、前記第２のデータに含まれる前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含む
   ことを特徴とする情報処理装置。
2. 前記第１のメタデータおよび前記第２のメタデータは、再生時に再生時間に無関係に読み出せるメタデータである
   ことを特徴とする請求項１に記載の情報処理装置。
3. 前記第３の識別情報は、前記第２のデータに含まれる前記画像データの先頭のフレームのＵＭＩＤとの相対的な位置におけるＵＭＩＤである
   ことを特徴とする請求項１に記載の情報処理装置。
4. 前記第３の識別情報は、前記第２のデータに含まれる前記画像データの先頭のフレームのＫＬＶデータとの相対的な位置におけるＫＬＶデータである
   ことを特徴とする請求項１に記載の情報処理装置。
5. 前記第２のテーブルは、前記第３の識別情報の値が、直前のフレームと連続しないフレームである不連続点における、前記第３の識別情報と前記第４の識別情報とを関連付けるテーブルである
   ことを特徴とする請求項１に記載の情報処理装置。
6. 前記第１のメタデータを含むファイルは、前記第１のデータを含むファイルと同じディレクトリに配置され、
   前記第２のメタデータを含むファイルは、前記第２のデータを含むファイルと同じディレクトリに配置される
   ことを特徴とする請求項１に記載の情報処理装置。
7. 画像データを含む第１のデータの編集処理を行い、前記編集処理により生成される編集後の前記第１のデータである第２のデータを、前記第１のデータのファイルと異なるファイルとして管理する情報処理装置の情報処理方法において、
   前記第１のデータのメタデータである第１のメタデータに基づいて、前記第２のデータに対応するメタデータである第２のメタデータを生成する生成ステップと、
   前記生成手段により生成された前記第２のメタデータを前記第１のメタデータのファイルと異なるファイルに登録する登録ステップとを含み、
   前記第１のメタデータは、前記第１のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第１の識別情報と、前記第１のデータに含まれる、前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、
   前記第２のメタデータは、前記第２のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第３の識別情報と、前記第２のデータに含まれる前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含む
   ことを特徴とする情報処理方法。
8. 画像データを含む第１のデータの編集処理を行い、前記編集処理により生成される編集後の前記第１のデータである第２のデータを、前記第１のデータのファイルと異なるファイルとして管理する情報処理装置を制御するプログラムであって、
   前記第１のデータのメタデータである第１のメタデータに基づいて、前記第２のデータに対応するメタデータである第２のメタデータを生成する生成ステップと、
   前記生成手段により生成された前記第２のメタデータを前記第１のメタデータのファイルと異なるファイルに登録する登録ステップとを含み、
   前記第１のメタデータは、前記第１のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第１の識別情報と、前記第１のデータに含まれる、前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、
   前記第２のメタデータは、前記第２のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第３の識別情報と、前記第２のデータに含まれる前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含む
   ことを特徴とするコンピュータが読み取り可能なプログラムが記録されていることを特徴とする記録媒体。
9. 画像データを含む第１のデータの編集処理を行い、前記編集処理により生成される編集後の前記第１のデータである第２のデータを、前記第１のデータのファイルと異なるファイルとして管理する情報処理装置を制御するプログラムであって、
   前記第１のデータのメタデータである第１のメタデータに基づいて、前記第２のデータに対応するメタデータである第２のメタデータを生成する生成ステップと、
   前記生成手段により生成された前記第２のメタデータを前記第１のメタデータのファイルと異なるファイルに登録する登録ステップとを含み、
   前記第１のメタデータは、前記第１のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第１の識別情報と、前記第１のデータに含まれる、前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第２の識別情報とを、それぞれに関連付けた第１のテーブルを含み、
   前記第２のメタデータは、前記第２のデータに含まれる、前記画像データの各フレームの制御情報を識別する複数の第３の識別情報と、前記第２のデータに含まれる前記画像データの各フレームの、先頭のフレームを基準として相対的に前記制御情報を識別する複数の第４の識別情報とを、それぞれに関連付けた第２のテーブルを含む
   処理をコンピュータに実行させることを特徴とするプログラム。

Images