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