JP2005243072A - 変換装置、変換補助方法、およびプログラム - Google Patents

Abstract

【課題】 複数のデータが多重化されたファイルの編集や転送等に対して、容易なユーザインタフェースを提供することができるようにする。
【解決手段】 光ディスクに記録されている各ファイルのうちの、ファイル単体または複数のファイル組合せからなる処理対象候補毎に、対応する処理対象候補を構成する全データが含まれる１つの仮想ファイルが生成され、所定の仮想ディレクトリ構造に含まれる１以上の仮想ディレクトリのうちの所定の１つに配置され、１以上の仮想ファイルのそれぞれを示すシンボル（例えば、図中のシンボル１６２）、および、１以上の仮想ディレクトリのそれぞれを示すシンボル（例えば、図中のシンボル１６１）が、上述した仮想ディレクトリ構造に従って羅列された画像が、表示部１７に表示される。本発明は、ビデオデータとオーディオデータを取り扱う装置に適用可能である。
【選択図】 図２６

Description

本発明は、変換装置、変換補助方法、および、プログラムに関し、特に、例えば、ビデオデータとオーディオデータが多重化されたファイルについて、互換性を保持しつつ、容易なユーザインタフェースで編集や転送等をすることができるようにする変換装置、変換補助方法、およびプログラムに関する。

近年においては、通信プロトコル等の標準化や、通信機器の低価格化等が進み、通信I/F(Interface)を標準で装備しているパーソナルコンピュータが一般的になってきている。

さらに、パーソナルコンピュータの他、例えば、AV(Audio Visual)サーバやVTR(Video Tape Recorder)などの業務用放送機器についても、通信I/Fが標準装備されているもの、あるいは装備可能なものが一般的になっており、そのような放送機器どうしの間では、ビデオデータやオーディオデータ（以下、適宜、両方まとめて、AVデータと称する）のファイル交換が行われている（例えば、特許文献１参照）。

ところで、従来においては、放送機器どうしの間で交換されるファイルのフォーマットとしては、一般に、例えば、機種ごとやメーカごとに、独自のフォーマットが採用されていたため、異なる機種やメーカの放送機器どうしの間では、ファイル交換を行うことが困難であった。

そこで、ファイル交換のためのフォーマットとして、例えば、MXF(Material eXchange Format)が提案され、現在標準化されつつある。

MXFは、ファイル交換に加えて、ストリーミングを考慮したフォーマットであり、非特許文献１に記載されているように、ビデオデータとオーディオデータがフレームごと等の細かい単位で多重化されている。
国際公開第02/21845号パンフレット Bruce Devlin, Snell & Wilcox, G-FORS MXF document controller, "MXF information centre"、[online]、［平成１４年９月２０日検索］、インターネット,URL:http://www.g-fors.com/mxf.htm

MXFは、上述したように、ストリーミングを考慮して、ビデオデータとオーディオデータがフレームごとに多重化されている。従って、放送機器において、MXFのファイルをストレージに取り込んでから、ビデオデータとオーディオデータを別々に編集（AV独立編集）するのが困難である課題があった。

そこで、放送機器において、MXFのファイルを取り込んだ後、それを、独自のフォーマットのファイルに変換する方法がある。しかしながら、放送機器において、MXFのファイルを、MXFとは全く関係のない独自フォーマットのファイルに変換し、ストレージに記録してしまうと、そのファイルを、他の放送機器において扱うことが困難となる。

即ち、例えば、ある放送機器のストレージに記録された独自フォーマットのファイルに対して、他の放送機器から、例えば、IEEE(Institute of Electrical and Electronics Engineers)1394やUSB(Universal Serial Bus)等の通信I/Fを介してアクセスしても、他の放送機器において、その独自フォーマットを理解することができない場合には、独自フォーマットのファイルを扱うこと（ここでは、例えば、読み出すこと）ができない。

また、ある放送機器において、独自フォーマットのファイルが記録されるストレージが、例えば、光ディスク等のリムーバブルな記録媒体である場合に、そのリムーバブルな記録媒体を、他の放送機器に装着しても、やはり、他の放送機器において、独自フォーマットを理解することができない場合には、その独自フォーマットのファイルを扱うことができない。

そこで、本願出願人は、例えば、ビデオデータとオーディオデータ等が多重化されたファイルについて、互換性を保持しつつ、容易に編集等をすることができる変換装置を既に発明し、特願2002-273080号として出願している。

現状、本願出願人が既に発明し出願したこの変換装置よりも、さらに容易なインタフェースでデータを編集したり、編集されたそのデータを他の装置に転送したいという要求が挙げられ始めている。

本発明はこのような状況に鑑みてなされたものであり、ビデオデータとオーディオデータが多重化されたファイルについて、互換性を保持しつつ、容易なユーザインタフェースで、編集や転送等をすることができるようにするものである。

本発明の変換装置は、ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する変換装置であって、ボディに第１と第２のデータが多重化されて配置された第１のフォーマットの第１のファイルと、ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方が供給された場合、それを他方に変換する変換手段と、ボディに第１のデータがまとめて配置された第２のフォーマットの第１のファイルと、ボディに第２のデータがまとめて配置された第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体が装着される装着手段と、装着手段に装着された記録媒体に記録されている２以上のファイルの中から、変換手段の処理対象候補として、第１のファイルと第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せを１組以上特定する特定手段と、特定手段により特定された１以上の処理対象候補のそれぞれを示すシンボルが羅列された画像を生成する生成手段と、生成手段により生成された画像を表示装置に表示させることを制御する表示制御手段と、表示制御手段の制御により表示装置に表示された画像に含まれる１以上のシンボルの中から、変換手段の次の処理対象として所望する処理対象候補を示すシンボルを指定するときにユーザによって操作される操作手段と、装着手段に装着された記録媒体に記録されている２以上のファイルのうちの、ユーザが操作手段を操作することで指定したシンボルに対応する処理対象候補を読み出し、読み出された処理対象候補が第１のファイルと第２のファイルとの組合せの場合、第１のファイルと第２のファイルを変換手段に供給する読み出し手段とを備えることを特徴とする。

特定手段は、特定された１以上の処理対象候補毎に、対応する処理対象候補を構成する全データを含ませた１つの仮想ファイルを生成し、生成された１以上の仮想ファイルのそれぞれを、予め構成されている仮想ディレクトリ構造に含まれる１以上の仮想ディレクトリのうちの所定の１つに配置させ、生成手段は、１以上の仮想ファイルのそれぞれを示すシンボル、および、１以上の仮想ディレクトリのそれぞれを示すシンボルが、仮想ディレクトリ構造に従って羅列された画像を生成するようにすることができる。

特定手段は、１以上の仮想ファイルのそれぞれの名称をさらに生成し、生成手段は、１以上の仮想ファイルのそれぞれを示すシンボルの近傍に、対応する仮想ファイルの生成された名称が配置された画像を生成するようにすることができる。

本発明の変換装置においては、ヘッダ、ボディ、フッタからなるフォーマットのファイルが変換される。即ち、ボディに第１と第２のデータが多重化されて配置された第１のフォーマットの第１のファイルと、ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方が供給された場合、それが他方に変換される。このような変換処理の前処理のうちの一処理として、ボディに第１のデータがまとめて配置された第２のフォーマットの第１のファイルと、ボディに第２のデータがまとめて配置された第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体が装着されると、その記録媒体に記録されている２以上のファイルの中から、上述した変換処理の処理対象候補として、第１のファイルと第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せが１組以上特定され、特定された１以上の処理対象候補のそれぞれを示すシンボルが羅列された画像が生成されて、表示装置に表示される。そして、表示装置に表示された画像に含まれる１以上のシンボルの中から、変換処理の次の処理対象としてユーザが所望する処理対象候補を示すシンボルがそのユーザにより指定された場合、先の記録媒体に記録されている２以上のファイルのうちの、ユーザが指定したシンボルに対応する処理対象候補が読み出される。このとき、読み出された処理対象候補が第１のファイルと第２のファイルとの組合せであると、第１のファイルと第２のファイルが、上述した変換処理を実行する部位に供給され、その部位により、第１のフォーマットの第３のファイルに変換される。

なお、記録媒体が装着される装着手段は、記録媒体が固定装着される装着手段であってもよいし、記録媒体が装着自在な装着手段であってもよい。即ち、記録媒体は、記録装置に内蔵されている記録媒体であってもよいし、記録装置の外部の記録媒体であってもよい。

本発明の変換補助方法は、ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する変換装置（詳細には、ボディに第１と第２のデータが多重化されて配置された第１のフォーマットのファイルと、ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方が供給された場合、他方に変換する変換手段と、ボディに第１のデータがまとめて配置された第２のフォーマットの第１のファイルと、ボディに第２のデータがまとめて配置された第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体が装着される装着手段と、表示装置に表示された画像に含まれるシンボルを指定するときにユーザによって操作される操作手段とを少なくとも備える変換装置）の変換補助方法であって、装着手段に装着された記録媒体に記録されている２以上のファイルの中から、変換手段の処理対象候補として、第１のファイルと第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せを１組以上特定する特定ステップと、特定ステップの処理により特定された１以上の処理対象候補のそれぞれを示す１以上のシンボルが羅列された画像を生成する生成ステップと、生成ステップの処理により生成された画像を表示装置に表示させることを制御する表示制御ステップと、ユーザが、操作手段を操作して、表示制御ステップの制御により表示装置に表示された画像に含まれる１以上のシンボルの中から、変換手段の次の処理対象として所望する処理対象候補を示すシンボルを指定した場合、装着手段に装着された記録媒体に記録されている２以上のファイルのうちの、ユーザが指定したシンボルに対応する処理対象候補を読み出し、読み出された処理対象候補が第１のファイルと第２のファイルとの組合せのときには、第１のファイルと第２のファイルを変換手段に供給する読み出しステップとを含むことを特徴とする。

本発明のプログラムは、ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する情報処理装置（詳細には、ボディに第１と第２のデータが多重化されて配置された第１のフォーマットのファイルと、ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方を、他方に変換する変換手段と、ボディに第１のデータがまとめて配置された第２のフォーマットの第１のファイルと、ボディに第２のデータがまとめて配置された第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体が装着される装着手段と、表示装置に表示された画像に含まれるシンボルを指定するときにユーザによって操作される操作手段とを少なくとも備える情報処理装置）を制御するコンピュータに実行させるプログラムであって、装着手段に装着された記録媒体に記録されている２以上のファイルの中から、変換手段の処理対象候補として、第１のファイルと第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せを１組以上特定する特定ステップと、特定ステップの処理により特定された１以上の処理対象候補のそれぞれを示す１以上のシンボルが羅列された画像を生成する生成ステップと、生成ステップの処理により生成された画像を表示装置に表示させることを制御する表示制御ステップと、ユーザが、操作手段を操作して、表示制御ステップの制御により表示装置に表示された画像に含まれる１以上のシンボルの中から、変換手段の次の処理対象として所望する処理対象候補を示すシンボルを指定した場合、装着手段に装着された記録媒体に記録されている２以上のファイルのうちの、ユーザが指定したシンボルに対応する処理対象候補を読み出し、読み出された処理対象候補が第１のファイルと第２のファイルとの組合せのときには、第１のファイルと第２のファイルを変換手段に供給する読み出しステップとを含むことを特徴とする。

本発明の変換補助方法、および、プログラムにおいては、ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する変換装置または情報処理装置（詳細には、ボディに第１と第２のデータが多重化されて配置された第１のフォーマットのファイルと、ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方を、他方に変換する変換手段と、ボディに第１のデータがまとめて配置された第２のフォーマットの第１のファイルと、ボディに第２のデータがまとめて配置された第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体が装着される装着手段と、表示装置に表示された画像に含まれるシンボルを指定するときにユーザによって操作される操作手段とを少なくとも備える変換装置または情報処理装置）が対象とされている。そして、装着手段に装着された記録媒体に記録されている２以上のファイルの中から、変換手段の処理対象候補として、第１のファイルと第２のファイルとの組合せを少なくとも含む、1組以上のファイルの組合せが１以上特定され、特定された１以上の処理対象候補のそれぞれを示す１以上のシンボルが羅列された画像が生成されて、表示装置に表示される。そして、表示装置に表示された画像に含まれる１以上のシンボルの中から、変換処理の次の処理対象としてユーザが所望する処理対象候補を示すシンボルがそのユーザにより指定された場合、先の記録媒体に記録されている２以上のファイルのうちの、ユーザが指定したシンボルに対応する処理対象候補が読み出される。このとき、読み出された処理対象候補が第１のファイルと第２のファイルとの組合せであると、第１のファイルと第２のファイルが、上述した変換処理を実行する部位に供給され、その部位により、第１のフォーマットの第３のファイルに変換される。

以上のごとく、本発明によれば、データが多重化されたファイルについて、互換性を保持しつつ、容易に編集等をすることが可能となる。特に、例えば、ビデオデータとオーディオデータが多重化されたファイルについて、互換性を保持しつつ、容易なユーザインタフェースで編集したり、編集後に他の装置に転送することができる。

以下に本発明の実施の形態を説明するが、請求項に記載の構成要件と、発明の実施の形態における具体例との対応関係を例示すると、次のようになる。この記載は、請求項に記載されている発明をサポートする具体例が、発明の実施の形態に記載されていることを確認するためのものである。従って、発明の実施の形態中には記載されているが、構成要件に対応するものとして、ここには記載されていない具体例があったとしても、そのことは、その具体例が、その構成要件に対応するものではないことを意味するものではない。逆に、具体例が構成要件に対応するものとしてここに記載されていたとしても、そのことは、その具体例が、その構成要件以外の構成要件には対応しないものであることを意味するものでもない。

さらに、この記載は、発明の実施の形態に記載されている具体例に対応する発明が、請求項に全て記載されていることを意味するものではない。換言すれば、この記載は、発明の実施の形態に記載されている具体例に対応する発明であって、この出願の請求項には記載されていない発明の存在、すなわち、将来、分割出願されたり、補正により追加される発明の存在を否定するものではない。

本発明によれば、変換装置が提供される。この変換装置（例えば、図１のディスク装置１）は、ヘッダ、ボディ、フッタからなるフォーマット（例えば、図２と図３に示されるフォーマット）のファイルを変換する変換装置であって、前記ボディに第１と第２のデータ（例えば、第１のデータは後述するビデオデータであり、第２のデータは後述する音声データである）が多重化されて配置された第１のフォーマット（例えば、図２に示される、後述する標準AV多重フォーマット）のファイルと、前記ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマット（例えば、図３に示される、後述するAV独立フォーマット）のファイルとのうちの一方が供給された場合、それを他方に変換する変換手段（例えば、図１のフォーマット変換部１２）と、前記ボディに前記第１のデータがまとめて配置された前記第２のフォーマットの第１のファイル（例えば、後述するビデオファイル）と、前記ボディに前記第２のデータがまとめて配置された前記第２のフォーマットの第２のファイル（例えば、後述する音声ファイル）とを少なくとも含む２以上のファイルが記録されている記録媒体（例えば、図１の光ディスク７）が装着される装着手段（例えば、図１のディスク駆動部１１）と、前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルの中から、前記変換手段の処理対象候補として、前記第１のファイルと前記第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せを１組以上特定する特定手段（例えば、図２３のステップＳ２０１の処理のうちの、「光ディスクの記録内容を解析して、処理対象を特定するまでの処理を実行する図１の主制御部１４）と、特定手段により特定された１以上の前記処理対象候補のそれぞれを示すシンボル（例えば、図２６のシンボル１６２）が羅列された画像（例えば、図２６に示される、後述する処理対象指定画像）を生成する生成手段（例えば、図２３のステップＳ２０１の処理のうちの、特定手段の処理以降の処理を実行する図１の主制御部１４）と、生成手段により生成された前記画像を表示装置（例えば、図１の表示部１７）に表示させることを制御する表示制御手段（例えば、図１の表示制御部１６）と、前記表示制御手段の制御により前記表示装置に表示された前記画像に含まれる１以上の前記シンボルの中から、前記変換手段の次の処理対象として所望する前記処理対象候補を示す前記シンボルを指定するときにユーザによって操作される操作手段（例えば、図１の操作部１５）と、前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルのうちの、前記ユーザが前記操作手段を操作することで指定した前記シンボルに対応する前記処理対象候補を読み出し、読み出された前記処理対象候補が前記第１のファイルと前記第２のファイルとの組合せの場合、前記第１のファイルと前記第２のファイルを前記変換手段に供給する読み出し手段（例えば、図２３のステップＳ２０５の処理を実行する図１の主制御部１４）とを備えることを特徴とする。

この変換装置において、前記特定手段は、特定された１以上の前記処理対象候補毎に、対応する処理対象候補を構成する全データを含ませた１つの仮想ファイルを生成し、生成された１以上の仮想ファイルのそれぞれを、予め構成されている仮想ディレクトリ構造（例えば、図２６に示されるようなディレクトリ構造）に含まれる１以上の仮想ディレクトリのうちの所定の１つに配置させ、前記生成手段は、１以上の前記仮想ファイルのそれぞれを示す前記シンボル、および、１以上の前記仮想ディレクトリのそれぞれを示すシンボル（例えば、図２６のシンボル１６１）が、前記仮想ディレクトリ構造に従って羅列された前記画像（例えば、図２６に示される処理対象指定画像）を生成するようにすることができる。

この変換装置において、前記特定手段は、１以上の前記仮想ファイルのそれぞれの名称をさらに生成し、前記生成手段は、１以上の前記仮想ファイルのそれぞれを示す前記シンボルの近傍に、対応する前記仮想ファイルの生成された前記名称が配置された（例えば、図２６に示されるように、シンボル１６２の右方に「C00001.MXF」という名称を配置させた）前記画像を生成するようにすることができる。

本発明によれば、変換補助方法が提供される。この変換補助方法（例えば、図２３の転送処理のうちの、ステップＳ２０１乃至Ｓ２０４までの処理）は、ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する変換装置（例えば、図１のディスク装置１）であって、前記ボディに第１と第２のデータが多重化されて配置された第１のフォーマットのファイルと、前記ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方が供給された場合、それを他方に変換する変換手段（例えば、図１のフォーマット変換部１２）と、前記ボディに前記第１のデータがまとめて配置された前記第２のフォーマットの第１のファイルと、前記ボディに前記第２のデータがまとめて配置された前記第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体（例えば、図１の光ディスク７）が装着される装着手段（例えば、図１のディスク駆動部１１）と、表示装置（例えば、図１の表示部７）に表示された画像に含まれるシンボルを指定するときにユーザによって操作される操作手段（例えば、図１の操作部１５）とを少なくとも備える前記変換装置の変換補助方法である。即ち、この変換補助方法は、前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルの中から、前記変換手段の処理対象候補として、前記第１のファイルと前記第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せを１組以上特定する特定ステップ（例えば、図２３のステップＳ２０１の処理のうちの、「光ディスクの記録内容を解析して、処理対象を特定するまでの処理）と、特定された１以上の前記処理対象候補のそれぞれを示すシンボルが羅列された画像を生成する生成ステップ（例えば、図２３のステップＳ２０１の処理のうちの、特定ステップの処理以降の処理）と、生成ステップの処理により生成された前記画像を前記表示装置に表示させることを制御する表示制御ステップ（例えば、図２３のステップＳ２０２の処理）と、前記ユーザが、前記操作手段を操作して、前記表示制御ステップの制御により前記表示装置に表示された前記画像に含まれる１以上の前記シンボルの中から、前記変換手段の次の処理対象として所望する前記処理対象候補を示す前記シンボルを指定した場合（例えば、図２３のステップＳ２０３でＹＥＳの判定がなされた場合）、前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルのうちの、前記ユーザが指定した前記シンボルに対応する前記処理対象候補を読み出し、読み出された前記処理対象候補が前記第１のファイルと前記第２のファイルとの組合せのときには、前記第１のファイルと前記第２のファイルを前記変換手段に供給する読み出しステップ（例えば、ステップＳ２０４の処理）とを含むことを特徴とする。

本発明によれば、プログラムが提供される。このプログラムは、ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する情報処理装置（例えば、図１のディスク装置１）であって、前記ボディに第１と第２のデータが多重化されて配置された第１のフォーマットのファイルと、前記ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方が供給された場合、それを他方に変換する変換手段（例えば、図１のフォーマット変換部１２）と、前記ボディに前記第１のデータがまとめて配置された前記第２のフォーマットの第１のファイルと、前記ボディに前記第２のデータがまとめて配置された前記第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体（例えば、図１の光ディスク７）が装着される装着手段（例えば、図１のディスク駆動部１１）と、表示装置（例えば、図１の表示部７）に表示された画像に含まれるシンボルを指定するときにユーザによって操作される操作手段（例えば、図１の操作部１５）とを少なくとも備える前記情報処理装置を制御するコンピュータ（例えば、図１の主制御部１４そのものである、または、それに内蔵される、若しくは、それが一構成要素として設けられる、図２７のコンピュータ）に実行させるプログラムであって、上述した変換補助方法に対応するプログラムである。

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

図１は、本発明を適用したAVネットワークシステム（システムとは、複数の装置が論理的に集合した物をいい、各構成の装置が同一筐体中にあるか否かは問わない）の一実施の形態の構成例を示している。

ディスク装置１は、ディスク駆動部１１、フォーマット変換部１２、通信I/F１３、主制御部１４、操作部１５、表示制御部１６、および、表示部１７で構成され、ネットワーク４を介して伝送されてくるAVデータのファイルを受信し、光ディスク７に記録し、また、光ディスク７に記録されたAVデータのファイルを読み出し、ネットワーク４を介して伝送する。

即ち、ディスク駆動部１１には、光ディスク７が着脱される。ディスク駆動部１１は、そこに装着された光ディスク７を駆動することにより、フォーマット変換部１２から供給される、後述するAV独立フォーマットのファイルを光ディスク７に記録し（書き込み）、また、光ディスク７からAV独立フォーマットのファイルを読み出して、フォーマット変換部１２に供給する。

フォーマット変換部１２は、ディスク駆動部１１から供給されるAV独立フォーマットのファイルを、後述する標準AV多重フォーマットのファイルに変換し、通信I/F１３に供給する。また、フォーマット変換部１２は、通信I/F１３から供給される標準AV多重フォーマットのファイルを、AV独立フォーマットのファイルに変換し、ディスク駆動部１１に供給する。

通信I/F１３は、例えば、IEEE(Institute of Electrical and Electronics Engineers)1394ポートや、USB(Universal Serial Bus)ポート、LAN(Local Area Network)接続用のNIC(Network Interface Card)、あるいは、アナログモデムや、TA(Terminal Adapter)およびDSU(Digital Service Unit)、ADSL(Asymmetric Digital Subscriber Line)モデム等で構成され、例えば、インターネットやイントラネット等のネットワーク４を介して、標準AV多重フォーマットのファイルをやりとりする。即ち、通信I/F１３は、フォーマット変換部１２から供給される標準AV多重フォーマットのファイルを、ネットワーク４を介して伝送し、また、ネットワーク４を介して伝送されてくる標準AV多重フォーマットのファイルを受信して、フォーマット変換部１２に供給する。

主制御部１４は、ディスク装置１全体の制御を行う。即ち、主制御部１４には、上述した、ディスク駆動部１１、フォーマット変換部１２、および、通信I/F１３の他さらに、操作部１５、および表示制御部１６が接続されており、主制御部１４は、例えば、操作部１５から供給される信号に基づいて、自分自身で処理を行ったり、これらのブロック（ディスク駆動部１１乃至表示制御部１６）のうちの対応するブロックが実行する処理の制御を行う。

操作部１５は、ユーザにより操作され、その操作に対応する信号（指令）を主制御部１４に供給する。

表示制御部１６は、それに接続された表示部１７に画像を表示させるように制御する。即ち、主制御部１４から供給される各種の画像データを、表示部１７に対応するフォーマットの画像信号に変換して、表示部１７に供給する。表示部１７は、表示制御部１６から供給された画像信号に対応する画像（例えば、後述する図２６に示される処理対象指定画像）を表示する。

以上のように構成されるディスク装置１では、通信I/F１３が、ネットワーク４を介して伝送されてくる標準AV多重フォーマットのファイルを受信し、フォーマット変換部１２に供給する。フォーマット変換部１２は、通信I/F１３からの標準AV多重フォーマットのファイルを、AV独立フォーマットのファイルに変換し、ディスク駆動部１１に供給する。そして、ディスク駆動部１１は、フォーマット変換部１２からのAV独立フォーマットのファイルを、そこに装着された光ディスク７に記録する。

また、ディスク装置１では、ディスク駆動部１１が、そこに装着された光ディスク７からAV独立フォーマットのファイルを読み出し、フォーマット変換部１２に供給する。フォーマット変換部１２は、ディスク駆動部１１からのAV独立フォーマットのファイルを、標準AV多重フォーマットのファイルに変換し、通信I/F１３に供給する。そして、通信I/F１３は、フォーマット変換部１２からの標準AV多重フォーマットのファイルを、ネットワーク４を介して伝送する。

さらに、このような一連の処理の前処理として、ディスク装置１では、表示制御部１６が、後述する図２６に示されるようなユーザインタフェース用の画像を表示部１７に表示させることができる。従って、ユーザは、表示部１７に表示された画像を見ながら操作部１５を操作する、といった簡単な操作を行うだけで、上述した一連の処理をディスク装置１に実行させることができる。なお、このようなユーザインタフェース用の画像（即ち、図２６に示されるような、後述する処理対象指定画像）や、その画像を用いるユーザ操作（それに伴うディスク装置１の処理）の詳細については後述する。

ここで、標準AV多重フォーマットのファイルは、例えば、MXFの規格に準拠したファイルであり、ヘッダ、ボディ、フッタからなる。そして、標準AV多重フォーマットのファイルは、MXFの規格に準拠したファイルであるから、そのボディには、AVデータであるビデオデータとオーディオデータとが、例えば、１フレーム単位で多重化されて配置されている。

図１において、ネットワーク４に接続されているAV装置５や６は、MXFの規格に準拠したファイルを取り扱うことができるMXFの規格に準拠した装置であり、従って、AV装置５や６は、標準AV多重フォーマットのファイルを、ネットワーク４を介して、ディスク装置１に伝送することができる。さらに、AV装置５や６は、ネットワーク４を介して、ディスク装置１から伝送されてくる標準AV多重フォーマットのファイルを受信することができる。即ち、ディスク装置１と、AV装置５や６との間では、ネットワーク４を介して、標準AV多重フォーマットのファイルのファイル交換を行うことができる。さらに、AV装置５や６は、受信した標準AV多重フォーマットのファイルを対象に、そのストリーミング再生等の各種の処理を行うことができる。

ここで、AV装置５や６のように、現行のMXFの規格に準拠した装置を、以下、適宜、標準装置という。

一方、AV独立フォーマットのファイルは、標準AV多重フォーマットのファイルと同様に、ヘッダ、ボディ、フッタからなるが、そのボディの形式だけは、標準AV多重フォーマットとは異なるものとなっている。即ち、AV独立フォーマットのファイルでは、ビデオデータとオーディオデータとが別々のファイルとされている。そして、ビデオデータのファイルであるビデオファイルは、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを有するが、そのボディには、ビデオデータがまとめて配置されている。また、オーディオデータのファイルであるオーディオファイルも、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを有するが、そのボディには、オーディオデータがまとめて配置されている。

従って、仮に、ディスク装置１からAV装置５や６に対して、AV独立フォーマットのビデオファイルやオーディオファイルを伝送した場合、標準装置であるAV装置５や６では、AV独立フォーマットに対応していない限り、そのAV独立フォーマットのビデオファイルやオーディオファイルのボディに配置されたビデオデータやオーディオデータを扱うことはできないが、そのAV独立フォーマットのビデオファイルやオーディオファイル自体を扱うことはできる。即ち、AV独立フォーマットのビデオファイルやオーディオファイルは、標準AV多重フォーマットのファイルと同様に、ヘッダ、ボディ、フッタで構成され、そのヘッダとフッタとして、標準AV多重フォーマットのファイルと同一形式のものを採用しているから、そのボディの「中身」（ボディに配置されたデータ）を参照しない限り、AV独立フォーマットのビデオファイルやオーディオファイル自体は、標準AVフォーマット
のファイルと等価である（標準AVフォーマットに準拠したファイルになっている）。従って、標準装置であるAV装置５や６が、AV独立フォーマットに対応していない場合であっても、AV独立フォーマットのビデオファイルやオーディオファイル自体を扱うことはできる。

即ち、ディスク装置１と、標準装置であるAV装置５や６との間においては、AV独立フォーマットのファイルのファイル交換だけであれば、行うことが可能である。

以上のように、AV独立フォーマットのファイルは、そのボディの「中身」を参照しない限り、標準AV多重フォーマットのファイルと等価であり、この観点からは、AV独立フォーマットのファイルは、標準AV多重フォーマットのファイルと互換性があるということができる。

次に、図１において、ディスク装置２には、光ディスク７を着脱することができるようになっている。ディスク装置２は、例えば、AV装置５や６と同様に、標準装置であり、そこに装着された光ディスク７から、AV独立フォーマットのビデオファイルやオーディオファイルを読み出し、編集装置３に供給する。

即ち、上述したように、AV独立フォーマットのビデオファイルやオーディオファイルは、そのボディの「中身」を参照しない限り、標準AV多重フォーマットのファイルと等価であるから、標準装置であるディスク装置２は、光ディスク７から、AV独立フォーマットのビデオファイルやオーディオファイルを読み出すことができる。

編集装置３は、AV独立フォーマットのファイルを取り扱うことができる、AV独立フォーマットに対応した装置であり、ディスク装置２から供給されるAV独立フォーマットビデオファイルやオーディオファイルを対象に、例えば、AV独立編集を行い、その編集結果としてのAV独立フォーマットのビデオファイルやオーディオファイルを、ディスク装置２に供給する。

そして、ディスク装置２は、そこに装着された光ディスク７に、編集装置３から供給されるAV独立フォーマットのビデオファイルやオーディオファイルを記録する。

即ち、上述したように、AV独立フォーマットのビデオファイルやオーディオファイルは、そのボディの「中身」を参照しない限り、標準AV多重フォーマットのファイルと等価であるから、標準装置であるディスク装置２は、光ディスク７に、AV独立フォーマットのビデオファイルやオーディオファイルを記録することができる。

上述したように、標準AV多重フォーマットのファイルにおいては、そのボディに、ビデオデータとオーディオデータとが、例えば、１フレーム単位で多重化されて配置されているのに対して、AV独立フォーマットのビデオファイルやオーディオファイルにおいては、そのボディに、ビデオデータやオーディオデータがまとめて配置されているので、AV独立編集等の編集を容易に行うことができる。そして、AV独立フォーマットのファイルは、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを有するから、ボディの「中身」を参照しない限り、標準AV多重フォーマットのファイルと互換性があり、これにより、標準装置で扱うことができる。

図２は、標準AV多重フォーマットの例を示している。

ここで、図２では、ボディに配置されるビデオデータとオーディオデータとして、D10と呼ばれるMPEG(Moving Picture Experts Group) IMX方式で符号化されたビデオデータと、AES(Audio Engineering Society)3形式の非圧縮のオーディオデータを、それぞれ採用した場合の標準AV多重フォーマットを示している。

なお、ボディには、その他、DV(Digital Video)等の各種のフォーマットのビデオデータとオーディオデータを配置することが可能である。

標準AV多重フォーマットのファイルは、その先頭から、ヘッダ(File Header)、ボディ(File Body)、フッタ(File Footer)が順次配置されて構成される。

ヘッダには、その先頭から、ヘッダパーティションパック(Header Partition Pack)、ヘッダメタデータ(Header Metadata)、インデックステーブル(Index Table)が順次配置される。ヘッダパーティションパックには、ヘッダを特定するためのデータや、ボディに配置されるデータの形式、ファイルフォーマットを表す情報などが配置される。ヘッダメタデータには、例えば、ファイルの作成日や、ボディに配置されたデータに関する情報などのファイル単位のメタデータが配置される。インデックステーブルには、ボディに配置される、後述するエディットユニットの位置を表すテーブルが配置される。

なお、インデックステーブルは、オプションであり、ヘッダに含めても、含めなくても良い。また、前述の非特許文献１に記載されているように、ヘッダには、インデックステーブルの他、種々のオプションのデータを配置することができる。

また、ヘッダパーティションパックに配置されるファイルフォーマットを表す情報としては、標準AV多重フォーマットのファイルでは、標準AV多重フォーマットを表す情報が採用されるが、AV独立フォーマットのファイルでは、AV独立フォーマットを表す情報が採用される。但し、ヘッダパーティションパックの形式自体は、標準AV多重フォーマットとAV独立フォーマットにおいて同一である。

フッタは、フッタパーティションパック(Footer Partition Pack)で構成され、フッタパーティションパックには、フッタを特定するためのデータなどが配置される。

ボディは、１以上のエディットユニット(Edit Unit)で構成される。エディットユニットは、１フレームの単位であり、そこには、１フレーム分のAVデータその他が配置される。

即ち、エディットユニットは、その先頭から、システムアイテム(Sytem Item)、ピクチャアイテム(Picture Item)、サウンドアイテム(Sound Item)、オグジュアリアイテム(Auxiliary Item)が配置されて構成される。

システムアイテムには、その後段のピクチャアイテムに配置されるビデオデータのフレームについてのメタデータ（フレーム単位のメタデータ）が配置される。ここで、フレーム単位のメタデータとしては、例えば、タイムコードなどがある。

ピクチャアイテムには、１フレーム分のビデオデータが配置される。図２では、上述したD10形式のビデオデータが配置される。

ここで、ピクチャアイテムには、１フレームのビデオデータがKLV(Key,Length,Value)構造にKLVコーディングされて配置される。

KLV構造とは、その先頭から、キー(Key)、レングス(Length)、バリュー(Value)が順次配置された構造であり、キーには、バリューに配置されるデータがどのようなデータであるかを表す、SMPTE 298Mの規格に準拠した１６バイトのラベルが配置される。レングスには、バリューに配置されるデータのデータ長が配置される。バリューには、実データ、即ち、ここでは、１フレームのビデオデータが配置される。

また、ピクチャアイテムは、そのデータ長が、KAG(KLV Alignment Grid)を基準とする固定長となっている。そして、ピクチャアイテムを固定長とするのに、スタッフィング(stuffing)のためのデータとしてのフィラー(Filler)が、やはりKLV構造とされて、ピクチャアイテムのビデオデータの後に配置される。

なお、ピクチャアイテムのデータ長であるKAGを基準とする固定長は、例えば、光ディスク７のセクタ長の整数倍（例えば、５１２バイトや２Ｋバイトなど）とされている。この場合、光ディスク７とピクチャアイテムとの、いわば親和性が高くなり、光ディスク７に対するピクチャアイテムの読み書き処理の高速化を図ることができる。

また、上述のシステムアイテム、並びに後述するサウンドアイテムおよびオグジュアリアイテムにおいても、ピクチャアイテムと同様に、KLV構造が採用されているとともに、そのデータ長がKAGを基準とする固定長になっている。

サウンドアイテムには、ピクチャアイテムに配置されたビデオデータのフレームにおける１フレーム分のオーディオデータが、上述のピクチャアイテムにおける場合と同様にKLV構造で配置される。

また、サウンドアイテムには、複数としての、例えば８チャネルのオーディオデータが多重化されて配置される。

即ち、サウンドアイテムにおいて、KLV構造のバリューには、その先頭から、エレメントヘッダEH(Element Header)、オーディオサンプルカウントASC(Audio Sample Count)、ストリームバリッドフラグSVF(Stream Valid Flags)、多重化された８チャネルのオーディオデータが順次配置される。

ここで、サウンドアイテムにおいて、８チャネルのオーディオデータは、１フレームにおける８チャネルそれぞれのオーディオデータの第１サンプル、第２サンプル、・・・といった順番に、オーディオデータのサンプルが配置されることにより多重化されている。図２の最下部に示したオーディオデータにおいて、括弧付きで示してある数字は、オーディオデータのサンプルが何サンプル目かを表している。

また、エレメントヘッダEHには、そのエレメントヘッダを特定するためのデータなどが配置される。オーディオサンプルカウントASCには、サウンドアイテムに配置されているオーディオデータのサンプル数が配置される。ストリームバリッドフラグSVFは、８ビット（１バイト）のフラグで、各ビットは、そのビットに対応するチャネルのオーディオデータが有効か、無効かを表す。即ち、ストリームバリッドフラグSVFの各ビットは、そのビットに対応するチャネルのオーディオデータが有効である場合に、例えば１とされ、無効である場合に、例えば０とされる。

オグジュアリアイテムには、必要なユーザデータが配置される。従って、オグジュアリアイテムは、ユーザが任意のデータを配置することができるエリアである。

以上のように、標準AV多重フォーマットでは、フレーム単位のメタデータが配置されるシステムアイテム、ビデオデータが配置されるピクチャアイテム、オーディオデータが配置されるサウンドアイテム、ユーザデータが配置されるオグジュアリアイテムが、１フレーム単位で多重化されており、さらに、サウンドアイテムでは、８チャネルのオーディオデータが、１サンプル単位で多重化されている。

このため、ビデオデータとオーディオデータが、別々にまとめて配置されているファイルでは、そのまとまったビデオデータのファイルとオーディオデータのファイルをすべて受信してからでないと、そのビデオデータおよびオーディオデータの再生を開始することができないが、標準AV多重フォーマットでは、ビデオデータとオーディオデータとがフレーム単位で多重化されているため、１フレーム分のビデオデータとオーディオデータを受信すれば、そのフレームのビデオデータおよびオーディオデータを、即座に再生することができる。従って、標準AV多重フォーマットは、ストリーミングに適しているということができる。

以上のように、標準AVフォーマットは、ビデオデータとオーディオデータとがフレーム単位で多重化されているので、ストリーミングには適している。しかしながら、その反面、ビデオデータとオーディオデータそれぞれを別々に編集するAV独立編集がしにくい。

さらに、ファイル単位のメタデータも、エディットユニットのシステムアイテムに散在しており、編集時等において扱いにくい。

また、標準AVフォーマットで採用可能なAES3形式では、オーディオデータの１サンプルに、少なくとも４バイトを割り当てる仕様になっており、ファイルの全体の大きさが大になる。

そこで、図３は、AV独立フォーマットの例を示している。

AV独立フォーマットでは、標準AV多重フォーマットにおいて多重化されているビデオデータ、オーディオデータ、ファイル単位のメタデータ、ユーザデータが、それぞれまとめて配置されたファイルとされる。

即ち、AV独立フォーマットでは、標準AV多重フォーマットにおいてビデオデータが配置されるピクチャアイテムがまとめてボディに配置され、さらに、そのボディに、標準AV多重フォーマットと同一形式のヘッダとフッタが付加されて、ビデオファイルが構成される。

なお、AV独立フォーマットのビデオファイルのボディには、光ディスク７のセクタ長の整数倍のピクチャアイテムがまとめて配置されているため、そのボディ全体の大きさも、光ディスク７のセクタ長の整数倍になっている。即ち、AV独立フォーマットのビデオファイルのボディは、セクタアラインメント(sector alignment)がとれた大きさとなっている。

また、図２では、標準AV多重フォーマットのファイルのヘッダに、インデックステーブルを図示してあるが、MXFでは、上述したように、インデックステーブルはオプションであり、図３のビデオファイルでは（後述するオーディオファイルでも同様）、インデックステーブルを採用していない。

AV独立フィーマットでは、標準AV多重フォーマットにおいてサウンドアイテムに配置される、多重化された８チャンネルのオーディオデータを、各チャンネルごとのオーディオデータに分離したものであって、AES3形式からWAVE形式に変換したものが、各チャネルごとのファイルのボディに、KLV構造で配置され、さらに、そのボディに、標準AV多重フォーマットと同一形式のヘッダとフッタが付加されて、オーディオファイルが構成される。

即ち、AV独立フォーマットでは、８チャンネルのオーディオデータについて、各チャネルのオーディオファイルが、独立に構成される。各チャネルのオーディオファイルは、そのチャネルのオーディオデータをWAVE形式にし、かつまとめてKLV構造化したものが、ボディに配置され、さらに、そのボディに、標準AV多重フォーマットと同一形式のヘッダとフッタが付加されて構成される。

なお、AV独立フォーマットのオーディオファイルのボディには、上述したように、あるチャネルのWAVE形式のオーディオデータをまとめてKLV構造化したものが配置されるが、このオーディオデータ全体の大きさが、光ディスク７のセクタ長の整数倍になるとは限らない。そこで、セクタアラインメントをとるために、AV独立フォーマットのオーディオファイルのボディには、KLV構造のオーディオデータの後に、セクタアライメントをとるのに必要な分のKLV構造のフィラーが配置される。

AV独立フォーマットでは、以上のようなビデオファイル、８チャネルそれぞれごとのオーディオファイルの他、標準AV多重フォーマットにおいてヘッダメタデータに配置されるファイル単位のメタデータがまとめて配置されたファイル単位のメタデータファイルと、標準AV多重フォーマットにおいてフレーム単位のメタデータが配置されたシステムアイテムがまとめて配置されたフレーム単位のメタデータファイルが構成される。さらに、AV独立フォーマットでは、標準AV多重フォーマットにおいてユーザデータが配置されたオグジュアリアイテムがまとめて配置されたオグジュアリファイルが構成される。

そして、AV独立フォーマットでは、ビデオファイル、８チャネルそれぞれごとのオーディオファイル、ファイル単位のメタデータファイル、フレーム単位のメタデータファイル、オグジュアリファイルそれぞれへのポインタが記述されたマスタファイル(master File)が構成される。

即ち、マスタファイルは、例えば、XML(Extensible Markup Language)で記述され、そこには、ビデオファイル、８チャネルそれぞれごとのオーディオファイル、ファイル単位のメタデータファイル、フレーム単位のメタデータファイル、オグジュアリファイルそれぞれへのポインタとして、例えば、各ファイルのファイル名が記述される。

従って、マスタファイルから、ビデオファイル、８チャネルそれぞれごとのオーディオファイル、ファイル単位のメタデータファイル、フレーム単位のメタデータファイル、オグジュアリファイルを参照することができる。

なお、例えば、オグジュアリファイルは、オプショナルなファイルとすることができる。

また、図３では、ファイル単位のメタデータファイル、フレーム単位のメタデータファイル、オグジュアリファイルは、標準AV多重フォーマットと同一形式のヘッダとフッタを有していないが、これらのファイル単位のメタデータファイル、フレーム単位のメタデータファイル、オグジュアリファイルも、標準AV多重フォーマットと同一形式のヘッダとフッタを付加して構成することができる。

さらに、AV独立フォーマットのビデオファイルとオーディオファイルのヘッダを構成するヘッダメタデータには、最小セットのファイル単位のメタデータが配置される。

即ち、AV独立フォーマットでは、標準AV多重フォーマットにおいてヘッダメタデータに配置されるファイル単位のメタデータがまとめて配置されたファイル単位のメタデータファイルが存在するので、そのメタデータファイルに配置されるファイル単位のメタデータを、ビデオファイルとオーディオファイルのヘッダを構成するヘッダメタデータに重複して配置するのは、冗長であり、また、AV独立フォーマットのファイル全体の大きさを大にすることになる。

しかしながら、MXFにおいて、ヘッダメタデータは、ヘッダに必須の項目であり、ヘッダメタデータをまったく配置せずにヘッダを構成したのでは、そのヘッダは、標準AV多重フォーマットと同一形式のヘッダでなくなることとなる。

一方、MXFにおいて、ヘッダメタデータに配置すべきファイル単位のメタデータには、種々の項目があるが、その項目の中には、必須のものと、オプショナルなものとがある。

そこで、ファイルの大きさが大になるのを抑制するとともに、標準AV多重フォーマットとの互換性を維持するために、AV独立フォーマットのビデオファイルとオーディオファイルのヘッダを構成するヘッダメタデータには、最小セットのファイル単位のメタデータ、即ち、MXFにおいて、ヘッダメタデータに配置することが必須とされている項目のメタデータのみが配置される。

以上のように、AV独立フォーマットでは、ビデオデータがまとめてビデオファイルに配置されるとともに、各チャネルのオーディオデータがまとめて、そのチャネルのオーディオファイルに配置されるので、ビデオデータとオーディオデータそれぞれを別々に編集するAV独立編集などの編集を、容易に行うことができる。

さらに、AV独立フォーマットでは、オーディオデータが、WAVE形式とされるので、標準AV独立フォーマットのように、AES3形式のオーディオデータを採用する場合に比較して、データ量を小さくすることができる。その結果、AV独立フォーマットのファイルを、光ディスク７等のストレージに記録する場合には、標準AV多重フォーマットのファイルを記録する場合に比較して、その記録に必要なストレージの容量を抑制することができる。

また、AV独立フォーマットのビデオファイルとオーディオファイルは、標準AV多重フォーマットのファイルと同様に、先頭から、ヘッダ、ボディ、フッタが配置されて構成され、さらに、ヘッダとフッタは、標準AV多重フォーマットと同一形式のものであるので、ディスク装置１において、AV独立フォーマットのビデオファイルやオーディオファイルを、リムーバブルな光ディスク７に記録し、その光ディスク７を、ディスク装置２に装着した場合に、ディスク装置２が、標準装置（MXFのファイルを扱うことのできる装置）であれば、光ディスク７から、AV独立フォーマットのビデオファイルやオーディオファイルを読み出すことができる。

さらに、AV独立フォーマットでは、ファイル単位のメタデータと、フレーム単位のメタデータとは、それぞれ別々にまとめられ、いずれも、１つのファイルとされるので、メタデータを使用した検索処理が容易となる。

次に、図４は、図１のディスク装置１が有するフォーマット変換部１２の構成例を示している。

フォーマット変換部１２は、標準／独立変換部２１と、独立／標準変換部２２とから構成されている。

標準／独立変換部２１は、通信I/F１３から供給される図２の標準AV多重フォーマットのファイルを、図３のAV独立フォーマットのファイルに変換し、ディスク駆動部１１に供給する。独立／標準変換部２２は、ディスク駆動部１１から供給される図３のAV独立フォーマットのファイルを、図２の標準AV多重フォーマットのファイルに変換し、通信I/F１３に供給する。

次に、図５は、図４の標準／独立変換部２１の構成例を示している。

バッファ３１には、通信I/F１３から標準AV多重フォーマットのファイルが供給されるようになっている。バッファ３１は、そこに供給される標準AV多重フォーマットのファイルを一時記憶する。

マスタファイル生成部３２は、バッファ３１に、標準AV多重フォーマットのファイルが記憶されると、その標準AV多重フォーマットのファイルについて、AV独立フォーマットのマスタファイルを生成し、バッファ４４に供給する。

ヘッダ取得部３３は、バッファ３１に記憶された標準AV多重フォーマットのファイルからヘッダを抽出することで取得し、そのヘッダを、ヘッダメタデータ抽出部３５に供給する。

ボディ取得部３４は、バッファ３１に記憶された標準AV多重フォーマットのファイルからボディを抽出することで取得し、そのボディを、システムアイテム抽出部３６、オグジュアリアイテム抽出部３８、ピクチャアイテム抽出部４０、およびサウンドアイテム抽出部４２に供給する。

ヘッダメタデータ抽出部３５は、ヘッダ取得部３３から供給されるヘッダから、ヘッダメタデータを抽出し、そのヘッダメタデータに配置されたファイル単位のメタデータを、メタデータファイル生成部３７に供給する。システムアイテム抽出部３６は、ボディ取得部３４から供給されるボディの各エディットユニットから、フレーム単位のメタデータが配置されたシステムアイテムを抽出し、メタデータファイル生成部３７に供給する。メタデータファイル生成部３７は、ヘッダメタデータ抽出部３５から供給されるファイル単位のメタデータを配置したファイル単位のメタデータファイルを生成するとともに、システムアイテム抽出部３６から供給される各エディットユニットのシステムアイテムをまとめて（シーケンシャルに）配置したフレーム単位のメタデータファイルを生成し、そのファ
イル単位とフレーム単位のメタデータファイルを、バッファ４４に供給する。

オグジュアリアイテム抽出部３８は、ボディ取得部３４から供給されるボディの各エディットユニットから、フレーム単位のユーザデータが配置されたオグジュアリアイテムを抽出し、オグジュアリファイル生成部３９に供給する。オグジュアリファイル生成部３９は、オグジュアリアイテム抽出部３８から供給される各エディットユニットのオグジュアリアイテムをまとめて配置したオグジュアリファイルを生成し、バッファ４４に供給する。

ピクチャアイテム抽出部４０は、ボディ取得部３４から供給されるボディの各エディットユニットから、フレーム単位のビデオデータが配置されたピクチャアリアイテムを抽出し、ビデオファイル生成部４１に供給する。ビデオファイル生成部４１は、ピクチャアイテム抽出部４０から供給される各エディットユニットのピクチャアイテムをまとめてボディに配置し、さらに、そのボディに、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを付加したビデオファイルを生成し、バッファ４４に供給する。

サウンドアイテム抽出部４２は、ボディ取得部３４から供給されるボディの各エディットユニットから、フレーム単位のオーディオデータが配置されたサウンドアイテムを抽出し、オーディオファイル生成部４３に供給する。オーディオファイル生成部４３は、サウンドアイテム抽出部４２から供給される各エディットユニットのサウンドアイテムに配置された各チャネルのオーディオデータを、各チャネルごとにまとめてボディに配置し、さらに、そのボディに、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを付加した各チャネルごとのオーディオファイルを生成し、バッファ４４に供給する。

バッファ４４は、マスタファイル生成部３２から供給されるマスタファイル、メタデータファイル生成部３７から供給されるファイル単位とフレーム単位それぞれのメタデータファイル、オグジュアリファイル生成部３９から供給されるオグジュアリファイル、ビデオファイル生成部４１から供給されるビデオファイル、およびオーディオファイル生成部４３から供給される各チャネルごとのオーディオファイルを一時記憶し、それらのファイルを、AV独立フォーマットのファイルとして、ディスク駆動部１１に供給する。

次に、図６は、図５のビデオファイル生成部４１の構成例を示している。

ピクチャアイテム抽出部４０から供給される各エディットユニットのピクチャアイテムは、結合部５１に供給される。結合部５１は、そこに供給される各エディットユニットのピクチャアイテムを順次結合（連結）し、ヘッダ／フッタ付加部５２に供給する。ヘッダ／フッタ付加部５２は、結合部５１から供給される、各エディットユニットのピクチャアイテムが結合されたものをボディとして、そのボディに、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを付加し、これにより、AV独立フォーマットのビデオファイルを構成して出力する。

次に、図７は、図５のオーディオファイル生成部４３の構成例を示している。

サウンドアイテム抽出部４２から供給される各エディットユニットのサウンドアイテムは、KLVデコーダ６１に供給される。KLVデコーダ６１は、各エディットユニットのサウンドアイテムに配置されたオーディオデータのKLV構造を分解し、その結果得られる、８チャネルが多重化されたオーディオデータ（以下、適宜、多重化オーディオデータという）を、チャネル分離部６２に供給する。

チャネル分離部６２は、KLVデコーダ６１から供給される、各サウンドアイテムごとの多重化オーディオデータから、各チャネルのオーディオデータを分離し、その各チャネルのオーディオデータを、チャネルごとにまとめて、データ変換部６３に供給する。

データ変換部６３は、チャネル分離部６２から供給される各チャネルのオーディオデータの符号化方式を変換する。即ち、標準AV多重フォーマットでは、オーディオデータは、AES3形式で符号化されたものとなっているが、AV独立フォーマットでは、オーディオデータはWAVE方式で符号化されたものとなっている。このため、データ変換部６３は、チャネル分離部６２から供給される、AES3方式で符号化されたオーディオデータ（AES3方式のオーディオデータ）を、WAVE方式で符号化されたオーディオデータ（WAVE方式のオーディオデータ）に変換する。

なお、ここでは、データ変換部６３において、AES3方式のオーディオデータを、WAVE方式のオーディオデータに変換するようにしたが、データ変換部６３では、オーディオデータを、WAVE方式以外のオーディオデータに変換することが可能である。即ち、データ変換部６３でのオーディオデータの変換は、AES3方式のオーディオデータのデータ量を抑制することを目的として行うものであり、その目的を達成することができる符号化方式であれば、データ変換部６３では、どのような符号化方式を採用しても良い。

また、オーディオデータのデータ量が問題とならない場合は、オーディオファイル生成部４３は、データ変換部６３を設けずに構成することが可能である。

データ変換部６３で得られたWAVE方式の各チャネルごとのオーディオデータは、KLVエンコーダ６４に供給される。KLVエンコーダ６４は、データ変換部６３から供給されるチャネルごとにまとめられたオーディオデータそれぞれを、KLV構造にKLVコーディングし、さらに、そのKLV構造とされた各チャネルのオーディオデータに、セクタアラインメントをとるための必要なフィラー（図３）を付加して、ヘッダ／フッタ付加部６５に供給する。

ヘッダ／フッタ付加部６５は、KLVエンコーダ６４から供給される各チャネルのオーディオデータそれぞれをボディとして、各チャネルのボディに、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを付加し、これにより、AV独立フォーマットの各チャネルごとのオーディオファイルを構成して出力する。

次に、図５の標準／独立変換部２１では、AV独立フォーマットのファイルとしてのマスタファイルを生成するマスタファイル生成処理、ファイル単位とフレーム単位のメタデータファイルそれぞれを生成するメタデータファイル生成処理、オグジュアリファイルを生成するオグジュアリファイル生成処理、ビデオファイルを生成するビデオファイル生成処理、オーディオファイルを生成するオーディオファイル生成処理が行われる。

そこで、図８乃至図１３のフローチャートを参照して、標準／独立変換部２１が行うマスタファイル生成処理、メタデータファイル生成処理、オグジュアリファイル生成処理、ビデオファイル生成処理、およびオーディオファイル生成処理について説明する。

まず最初に、図８のフローチャートを参照して、マスタファイル生成処理について説明する。

例えば、バッファ３１（図５）に、標準AVフォーマットのファイルが供給されて記憶されると、マスタファイル生成処理が開始され、まず最初に、ステップＳ１において、マスタファイル生成部３２（図５）は、ファイル単位とフレーム単位それぞれのメタデータファイル、オグジュアリファイル、ビデオファイル、各チャネルそれぞれのオーディオファイルのファイル名を生成し、ステップＳ２に進む。ステップＳ２では、マスタファイル生成部３２は、ステップＳ１で生成した各ファイル名のファイルへのリンクを、XMLで記述したマスタファイルを生成し、バッファ４４に供給して記憶させ、マスタファイル生成処理を終了する。

次に、図９のフローチャートを参照して、ファイル単位のメタデータファイルを生成するファイル単位のメタデータファイル生成処理について説明する。

例えば、バッファ３１（図５）に、標準AVフォーマットのファイルが供給されて記憶されると、ファイル単位のメタデータファイル生成処理が開始され、まず最初に、ステップＳ１１において、ヘッダ取得部３３は、バッファ３１に記憶された標準AVフォーマットのファイルからヘッダを取得し、ヘッダメタデータ抽出部３５に供給して、ステップＳ１２に進む。ステップＳ１２では、ヘッダメタデータ抽出部３５が、ヘッダ取得部３３から供給されるヘッダから、ヘッダメタデータを抽出し、そのヘッダメタデータに配置されたファイル単位のメタデータを、メタデータファイル生成部３７に供給して、ステップＳ１３に進む。ステップＳ１３では、メタデータファイル生成部３７が、ヘッダメタデータ抽出部３５から供給されるファイル単位のメタデータを配置したファイル単位のメタデータフ
ァイルを生成し、バッファ４４に供給して記憶させ、ファイル単位のメタデータファイル生成処理を終了する。

次に、図１０のフローチャートを参照して、フレーム単位のメタデータファイルを生成するフレーム単位のメタデータファイル生成処理について説明する。

例えば、バッファ３１（図５）に、標準AVフォーマットのファイルが供給されて記憶されると、フレーム単位のメタデータファイル生成処理が開始され、まず最初に、ステップＳ２１において、ボディ取得部３４は、バッファ３１に記憶された標準AV多重フォーマットのファイルからボディを取得し、システムアイテム抽出部３６に供給して、ステップＳ２２に進む。ステップＳ２２では、システムアイテム抽出部３６は、ボディ取得部３４から供給されるボディの各エディットユニットから、フレーム単位のメタデータが配置されたシステムアイテムを抽出し、メタデータファイル生成部３７に供給して、ステップＳ２３に進む。ステップＳ２３では、メタデータファイル生成部３７は、システムアイテム抽出部３６から供給される各エディットユニットのシステムアイテムを結合することにより
、その各エディットユニットのシステムアイテムまとめて配置したフレーム単位のメタデータファイルを生成し、バッファ４４に供給して記憶させ、フレーム単位のメタデータファイル生成処理を終了する。

次に、図１１のフローチャートを参照して、オグジュアリファイルを生成するオグジュアリファイル生成処理について説明する。

例えば、バッファ３１（図５）に、標準AVフォーマットのファイルが供給されて記憶されると、オグジュアリファイル生成処理が開始され、まず最初に、ステップＳ３１において、ボディ取得部３４は、バッファ３１に記憶された標準AV多重フォーマットのファイルからボディを取得し、オグジュアリアイテム抽出部３８に供給して、ステップＳ３２に進む。ステップＳ３２では、オグジュアリアイテム抽出部３８は、ボディ取得部３４から供給されるボディの各エディットユニットからオグジュアリアイテムを抽出し、オグジュアリファイル生成部３９に供給して、ステップＳ３３に進む。ステップＳ３３では、オグジュアリファイル生成部３９は、オグジュアリアイテム抽出部３８から供給される各エディットユニットのオグジュアリアイテムを結合することにより、その各エディットユニット
のオグジュアリアイテムまとめて配置したオグジュアリファイルを生成し、バッファ４４に供給して記憶させ、オグジュアリファイル生成処理を終了する。

次に、図１２のフローチャートを参照して、ビデオファイルを生成するビデオファイル生成処理について説明する。

例えば、バッファ３１（図５）に、標準AVフォーマットのファイルが供給されて記憶されると、ビデオファイル生成処理が開始され、まず最初に、ステップＳ４１において、ボディ取得部３４は、バッファ３１に記憶された標準AV多重フォーマットのファイルからボディを取得し、ピクチャアイテム抽出部４０に供給して、ステップＳ４２に進む。ステップＳ４２では、ピクチャアイテム抽出部４０は、ボディ取得部３４から供給されるボディの各エディットユニットからピクチャアイテムを抽出し、ビデオファイル生成部４１に供給して、ステップＳ４３に進む。ステップＳ４３では、ビデオファイル生成部４１（図６）において、結合部５１が、ピクチャアイテム抽出部４０から供給される各エディットユニットのピクチャアイテムを結合することにより、その各エディットユニットのピクチャ
アイテムまとめて配置したボディを生成し、ヘッダ／フッタ付加部５２に供給して、ステップＳ４４に進む。

ステップＳ４４では、ヘッダ／フッタ付加部５２は、結合部５１から供給されるボディに、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを付加し、これにより、AV独立フォーマットのビデオファイルを構成し、バッファ４４に供給して記憶させ、ビデオファイル生成処理を終了する。

次に、図１３のフローチャートを参照して、オーディオファイルを生成するオーディオファイル生成処理について説明する。

例えば、バッファ３１（図５）に、標準AVフォーマットのファイルが供給されて記憶されると、オーディオファイル生成処理が開始され、まず最初に、ステップＳ５１において、ボディ取得部３４は、バッファ３１に記憶された標準AV多重フォーマットのファイルからボディを取得し、サウンドアイテム抽出部４２に供給して、ステップＳ５２に進む。ステップＳ５２では、サウンドアイテム抽出部４２は、ボディ取得部３４から供給されるボディの各エディットユニットからサウンドアイテムを抽出し、オーディオファイル生成部４３に供給して、ステップＳ５３に進む。ステップＳ５３では、オーディオファイル生成部４３（図７）において、KLVデコーダ６１が、各エディットユニットのサウンドアイテムに配置されたオーディオデータのKLV構造を分解し、その結果得られる、８チャネルが
多重化されたオーディオデータ（多重化オーディオデータ）を、チャネル分離部６２に供給して、ステップＳ５４に進む。

ステップＳ５４では、チャネル分離部６２が、KLVデコーダ６１から供給される、各サウンドアイテムごとの多重化オーディオデータから、各チャネルのAES3形式のオーディオデータを分離し、その各チャネルのAES3形式のオーディオデータを、チャネルごとにまとめて配置して、データ変換部６３に供給する。

そして、ステップＳ５５に進み、データ変換部６３は、チャネル分離部６２から供給される各チャネルのAES3形式のオーディオデータを、WAVE方式のオーディオデータに変換し、KLVエンコーダ６４に供給して、ステップＳ５６に進む。ステップＳ５６では、KLVエンコーダ６４が、データ変換部６３から供給されるチャネルごとにまとめられたWAVE形式のオーディオデータそれぞれを、KLV構造にKLVコーディングし、さらに、そのKLV構造とされた各チャネルのオーディオデータに、セクタアラインメントをとるための必要なフィラー（図３）を付加する。

これにより、KLVエンコーダ６４は、各チャネルのWAVE形式のオーディオデータをまとめて配置するとともに、必要なフィラーを配置した各チャネルのボディを生成し、ヘッダ／フッタ付加部６５に供給して、ステップＳ５７に進む。

ステップＳ５７では、ヘッダ／フッタ付加部６５が、KLVエンコーダ６４から供給される各チャネルのボディに、標準AV多重フォーマットのファイルと同一形式のヘッダとフッタを付加し、これにより、AV独立フォーマットの各チャネルごとのオーディオファイルを構成し、バッファ４４に供給して記憶させ、オーディオファイル生成処理を終了する。

次に、図１４は、図４の独立／標準変換部２２の構成例を示している。

バッファ１０１は、ディスク駆動部１１（図１）から供給されるAV独立フォーマットのファイル（マスタファイル、ファイル単位のメタデータファイル、フレーム単位のメタデータファイル、オグジュアリファイル、ビデオファイル、８チャネルそれぞれのオーディオファイル）を一時記憶する。

ファイル取得部１０２は、バッファ１０１に記憶されたマスタファイルを参照することにより、ファイル単位のメタデータファイル、フレーム単位のメタデータファイル、オグジュアリファイル、ビデオファイル、８チャネルそれぞれのオーディオファイルのファイル名を認識し、そのファイル名に基づき、ファイル単位のメタデータファイル、フレーム単位のメタデータファイル、オグジュアリファイル、ビデオファイル、８チャネルそれぞれのオーディオファイルを、バッファ１０１を介し、ディスク駆動部１１に光ディスク７から読み出させることで取得する。さらに、ファイル取得部１０２は、取得したファイル単位のメタデータファイルとフレーム単位のメタデータファイルをメタデータファイル処理部１０３に、オグジュアリファイルをオグジュアリファイル処理部１０４に、ビデオフ
ァイルをビデオファイル処理部１０５に、８チャネルそれぞれのオーディオファイルをオーディオファイル処理部１０６に、それぞれ供給する。

メタデータファイル処理部１０３は、ファイル取得部１０２から供給されるファイル単位のメタデータファイルからファイル単位のメタデータを抽出するとともに、フレーム単位のメタデータファイルからフレーム単位のメタデータが配置されたシステムアイテムを抽出し、データ合成部１０７に供給する。

オグジュアリファイル処理部１０４は、ファイル取得部１０２から供給されるオグジュアリファイルからオグジュアリアイテムを抽出し、データ合成部１０７に供給する。

ビデオファイル処理部１０５は、ファイル取得部１０２から供給されるビデオファイルからピクチャアイテムを抽出し、データ合成部１０７に供給する。

オーディオファイル処理部１０５は、ファイル取得部１０２から供給される８チャネルそれぞれのオーディオファイルから、各チャネルのオーディオデータを抽出し、さらに、その各チャネルのオーディオデータを多重化して配置したサウンドアイテムを構成して、データ合成部１０７に供給する。

データ合成部１０７は、メタデータファイル処理部１０３から供給されるファイル単位のメタデータおよびシステムアイテム、オグジュアリファイル処理部１０４から供給されるオグジュアリアイテム、ビデオファイル処理部１０５から供給されるピクチャアイテム、並びにオーディオファイル処理部１０６から供給されるサウンドアイテムを用いて、標準AV多重フォーマットのファイルを構成し、バッファ１０８に供給する。

バッファ１０８は、データ合成部１０７から供給される標準AV多重フォーマットのファイルを一時記憶し、通信I/F１３（図１）に供給する。

次に、図１５は、図１４のビデオファイル処理部１０５の構成例を示している。

ファイル取得部１０２から供給されるビデオファイルは、ヘッダ／フッタ除去部１１１に供給される。ヘッダ／フッタ除去部１１１は、そこに供給されるビデオファイルからヘッダとフッタを除去し、残ったボディを、分解部１１２に供給する。分解部１１２は、ヘッダ／フッタ除去部１１１から供給されるボディに配置されたピクチャアイテムのシーケンスを分離することにより、そのシーケンスから、他のアイテム（システムアイテム、サウンドアイテム、オグジュアリアイテム）と多重化する単位、即ち、ここでは、フレーム単位のビデオデータが配置された個々のピクチャアイテムを抽出し、データ合成部１０７（図１４）に供給する。

次に、図１６は、図１４のオーディオファイル処理部１０６の構成例を示している。

ファイル取得部１０２から供給される８チャネルそれぞれのオーディオファイルは、ヘッダ／フッタ除去部１２１に供給される。ヘッダ／フッタ除去部１２１は、そこに供給される８チャネルそれぞれのオーディオファイルから、ヘッダとフッタを除去し、その結果残る各チャネルのボディを、KLVデコーダ１２２に供給する。

KLVデコーダ１２２は、ヘッダ／フッタ除去部１２１から供給される各チャネルのボディのKLV構造を分解し、これにより得られる各チャネルのWAVE形式のオーディオデータを、データ変換部１２３に供給する。

データ変換部１２３は、KLVデコーダ１２２から供給されるオーディオデータに対して、図７のデータ変換部６３における場合と逆の変換処理を施す。即ち、データ変換部１２３は、KLVデコーダ１２２から供給されるWAVE形式の各チャネルのオーディオデータを、AES3形式の各チャネルのオーディオデータに変換し、チャネル多重化部１２４に供給する。

チャネル多重化部１２４は、データ変換部１２４から供給される各チャネルのオーディオデータを、サンプル単位で多重化し、その結果得られる多重化オーディオデータを、KLVエンコーダ１２５に供給する。

KLVエンコーダ１２５は、チャネル多重化部１２４から供給される多重化オーディオデータを、ビデオデータの各フレームに対応する単位に区切り、その各フレームに対応する多重化オーディオデータをKLV構造にKLVコーディングする。さらに、KLVエンコーダ１２５は、各フレームに対応する多重化オーディオデータのKLV構造に対して、固定長のサウンドアイテムのデータ長に足りない分のフィラーのKLV構造を付加し、これにより、サウンドアイテムを構成して、データ合成部１０７（図１４）に供給する。

次に、図１７は、図１４のデータ合成部１０７の構成例を示している。

ヘッダ／フッタ生成部１３１には、メタデータファイル処理部１０３が出力するファイル単位のメタデータが供給される。ヘッダ／フッタ生成部１３１は、標準AV多重フォーマットのファイルのヘッダとフッタを生成し、さらに、そのヘッダのヘッダメタデータに、メタデータファイル処理部１０３からのファイル単位のメタデータを配置して、そのヘッダとフッタを、ヘッダ／フッタ付加部１３３に供給する。

多重化部１３２には、メタデータファイル処理部１０３が出力するシステムアイテム、オグジュアリファイル処理部１０４が出力するオグジュアリアイテム、ビデオファイル処理部１０５が出力するピクチャアイテム、オーディオファイル処理部１０６が出力するサウンドアイテムが供給される。多重化部１３２は、そこに供給されるシステムアイレム、ピクチャアイテム、サウンドアイテム、オグジュアリアイテムを、その順で、順次多重化することにより、エディットユニットのシーケンスを構成し、そのエディットユニットのシーケンスを、ボディとして、ヘッダ／フッタ付加部１３３に供給する。

ヘッダ／フッタ付加部１３３は、多重化部１３２から供給されるボディに、ヘッダ／フッタ生成部１３１から供給されるヘッダとフッタを付加し、これにより、標準AV多重フォーマットのファイルを構成して出力する。

次に、図１４の独立／標準変換部２２では、メタデータファイルを処理するメタデータファイル処理、オグジュアリファイルを処理するオグジュアリファイル処理、ビデオファイルを処理するビデオファイル処理、オーディオファイルを処理するオーディオファイル処理、これらの処理結果を用いて標準AV多重フォーマットのファイルを合成（生成）する合成処理が行われる。

そこで、図１８乃至図２２のフローチャートを参照して、独立／標準変換部２２が行うメタデータファイル処理、オグジュアリファイル処理、ビデオファイル処理、オーディオファイル処理、および合成処理について説明する。

まず最初に、図１８のフローチャートを参照して、メタデータファイル処理について説明する。

メタデータファイル処理は、例えば、ディスク駆動部１１によって光ディスク７から、マスタファイルが読み出され、バッファ１０１に記憶されると開始される。

即ち、まず最初に、ステップＳ１０１において、ファイル取得部１０２は、バッファ１０１に記憶されたマスタファイルを参照することにより、ファイル単位とフレーム単位それぞれのメタデータファイルのファイル名を認識する。さらに、ステップＳ１０１では、ファイル取得部１０２は、そのファイル名に基づき、ファイル単位とフレーム単位それぞれのメタデータファイルを、バッファ１０１を介し、ディスク駆動部１１に光ディスク７から読み出させることで取得し、メタデータファイル処理部１０３に供給して、ステップＳ１０２に進む。ステップＳ１０２では、メタデータファイル処理部１０３は、ファイル取得部１０２から供給されるファイル単位のメタデータファイルからファイル単位のメタデータを抽出するとともに、フレーム単位のメタデータファイルからフレーム単位のメタ
データが配置されたシステムアイテムを抽出し、データ合成部１０７に供給して、メタデータファイル処理を終了する。

次に、図１９のフローチャートを参照して、オグジュアリファイル処理について説明する。

オグジュアリファイル処理は、例えば、ディスク駆動部１１によって光ディスク７から、マスタファイルが読み出され、バッファ１０１に記憶されると開始される。

即ち、まず最初に、ステップＳ１１１において、ファイル取得部１０２は、バッファ１０１に記憶されたマスタファイルを参照することにより、オグジュアリファイルのファイル名を認識する。さらに、ステップＳ１１１では、ファイル取得部１０２は、そのファイル名に基づき、オグジュアリファイルを、バッファ１０１を介し、ディスク駆動部１１に光ディスク７から読み出させることで取得し、オグジュアリファイル処理部１０４に供給して、ステップＳ１１２に進む。

ステップＳ１１２では、オグジュアリファイル処理部１０４は、ファイル取得部１０２から供給されるオグジュアリファイルをオグジュアリアイテム単位に分解することで、オグジュアリファイルからオグジュアリアイテムを抽出（取得）し、データ合成部１０７に供給して、オグジュアリファイル処理を終了する。

次に、図２０のフローチャートを参照して、ビデオファイル処理について説明する。

ビデオファイル処理は、例えば、ディスク駆動部１１によって光ディスク７から、マスタファイルが読み出され、バッファ１０１に記憶されると開始される。

即ち、まず最初に、ステップＳ１２１において、ファイル取得部１０２は、バッファ１０１に記憶されたマスタファイルを参照することにより、ビデオファイルのファイル名を認識する。さらに、ステップＳ１２１では、ファイル取得部１０２は、そのファイル名に基づき、ビデオファイルを、バッファ１０１を介し、ディスク駆動部１１に光ディスク７から読み出させることで取得し、ビデオファイル処理部１０５に供給して、ステップＳ１２２に進む。

ステップＳ１２２では、ビデオファイル処理部１０５（図１５）のヘッダ／フッタ除去部１１１が、ファイル取得部１０２から供給されるビデオファイルからヘッダとフッタを除去し、その結果残ったボディを、分解部１１２に供給して、ステップＳ１２３に進む。ステップＳ１２３では、分解部１１２は、ヘッダ／フッタ除去部１１１から供給されるボディに配置されたピクチャアイテムのシーケンスを、個々のピクチャアイテムに分解し、データ合成部１０７に供給して、ビデオファイル処理を終了する。

次に、図２１のフローチャートを参照して、オーディオファイル処理について説明する。

オーディオファイル処理は、例えば、ディスク駆動部１１によって光ディスク７から、マスタファイルが読み出され、バッファ１０１に記憶されると開始される。

即ち、まず最初に、ステップＳ１３１において、ファイル取得部１０２は、バッファ１０１に記憶されたマスタファイルを参照することにより、８チャネルそれぞれのオーディオファイルのファイル名を認識する。さらに、ステップＳ１３１では、ファイル取得部１０２は、そのファイル名に基づき、８チャネルそれぞれのオーディオファイルを、バッファ１０１を介し、ディスク駆動部１１に光ディスク７から読み出させることで取得し、オーディオファイル処理部１０６に供給して、ステップＳ１３２に進む。

ステップＳ１３２では、オーディファイル処理部１０６（図１６）のヘッダ／フッタ除去部１２１が、ファイル取得部１０２から供給される８チャネルそれぞれのオーディオファイルから、ヘッダとフッタを除去し、その結果残る各チャネルのボディを、KLVデコーダ１２２に供給して、ステップＳ１３３に進む。ステップＳ１３３では、KLVデコーダ１２２は、ヘッダ／フッタ除去部１２１から供給される各チャネルのボディのKLV構造を分解し、これにより得られる各チャネルのWAVE形式のオーディオデータを、データ変換部１２３に供給して、ステップＳ１３４に進む。

ステップＳ１３４では、データ変換部１２３は、KLVデコーダ１２２から供給されるWAVE形式の各チャネルのオーディオデータを、AES3形式の各チャネルのオーディオデータに変換し、チャネル多重化部１２４に供給して、ステップＳ１３５に進む。ステップＳ１３５では、チャネル多重化部１２４は、データ変換部１２４から供給される各チャネルのオーディオデータを多重化し、その結果得られる多重化オーディオデータを、KLVエンコーダ１２５に供給して、ステップＳ１３６に進む。

ステップＳ１３６では、KLVエンコーダ１２５は、チャネル多重化部１２４から供給される多重化オーディオデータを、ビデオデータの各フレームに対応する単位に区切り、そのフレームに対応する多重化オーディオデータをKLV構造にKLVコーディングして、ステップＳ１３７に進む。さらに、ステップＳ１３７では、KLVエンコーダ１２５は、各フレームに対応する多重化オーディオデータのKLV構造に対して、必要なフィラーのKLV構造を付加し、これにより、サウンドアイテムを構成して、データ合成部１０７に供給し、オーディオファイル処理を終了する。

次に、図２２のフローチャートを参照して、合成処理について説明する。

合成処理は、例えば、データ合成部１０７に対して、メタデータファイル処理部１０３からファイル単位のメタデータおよびシステムアイテムが、オグジュアリファイル処理部１０４からオグジュアリアイテムが、ビデオファイル処理部１０５からピクチャアイテムが、オーディオファイル処理部１０６からサウンドアイテムが、それぞれ供給されると開始される。

即ち、まず最初に、ステップＳ１４１において、データ合成部１０７（図１７）のヘッダ／フッタ生成部１３１が、標準AV多重フォーマットのファイルのヘッダとフッタを生成し、さらに、そのヘッダのヘッダメタデータに、メタデータファイル処理部１０３からのファイル単位のメタデータを配置する。さらに、ステップＳ１４１では、ヘッダ／フッタ生成部１３１が、以上のようにして得られたヘッダとフッタを、ヘッダ／フッタ付加部１３３に供給して、ステップＳ１４２に進む。

ステップＳ１４２では、多重化部１３２が、メタデータファイル処理部１０３が出力するシステムアイテム、オグジュアリファイル処理部１０４が出力するオグジュアリアイテム、ビデオファイル処理部１０５が出力するピクチャアイテム、オーディオファイル処理部１０６が出力するサウンドアイテムを多重化し、その多重化の結果得られるエディットユニットのシーケンスを、ボディとして、ヘッダ／フッタ付加部１３３に供給して、ステップＳ１４３に進む。

ステップＳ１４３では、ヘッダ／フッタ付加部１３３は、多重化部１３２から供給されるボディに、ヘッダ／フッタ生成部１３１から供給されるヘッダとフッタを付加し、これにより、標準AV多重フォーマットのファイルを構成して出力し、合成処理を終了する。

次に、図２３のフローチャートを参照して、ディスク装置１（図１）が実行する処理のうちの、光ディスク７に記録されているAV独立フォーマットのファイルを１以上読み出し、それらのフォーマットを標準AV多重フォーマットに変換して、ネットワーク４を介して他の装置（図１の例ではAV装置５または６）に転送する処理（以下、転送処理と称する）について説明する。

例えば、いま、光ディスク７には、図２４に示されるようなディレクトリ構造で各種のデータ（AV独立フォーマットのデータ）がファイルとして記録されているとする。

図２４において、シンボル１５１は、１つのディレクトリを表している。なお、符号は付していないが、シンボル（ディレクトリ）１５１と同一のその他のシンボルも、１つのディレクトリを表している。また、シンボル１５２は、１つのファイルを示している。なお、符号は付していないが、シンボル（ファイル）１５２と同一のその他のシンボルも、１つのファイルを示している。

なお、以下、特に断りの無い限り、ディレクトリとディレクトリのシンボルとは同一であるとみなして説明する。同様に、ファイルとファイルのシンボルとは同一であるとみなして説明する。また、各ディレクトリのそれぞれ、および、各ファイルのそれぞれの識別を容易なものとするために、以下、ファイルまたはディレクトリの後方に括弧（ ）書きでその名称を記載する。

図２４の例では、光ディスク７には、PROAVディレクトリ１５１と、Generalディレクトリ（図中、その右方にGeneralと記述されているディレクトリ）とが設けられている。

PROAVディレクトリには、光ディスク７に記録されている全てのクリップ（クリップの詳細については後述する）とエディットリスト（エディットリストの詳細については図２５を参照して後述する）とを管理するための管理情報等を含むインデックスファイル（INDEX.XML）、および、それと同一内容のバックアップ用のインデックスファイル（INDEX.RSV）が設けられている。

PROAVディレクトリには、さらに、光ディスク７に記録されているデータ全体に対するメタデータであり、例えば、再生履歴等の情報を含むファイルであるディスクインフォメーションファイル（DISCINFO.XML）、および、それと同一内容のバックアップ用のディスクインフォメーションファイル（DISKINFO.RSV）が設けられている。

また、PROAVディレクトリには、上述したファイル以外にも、クリップのデータが下位のディレクトリに設けられるクリップルートディレクトリ（CLPR）、および、エディットリストのデータが下位のディレクトリに設けられるエディットリストルートディレクトリ（EDTR）が設けられる。

クリップルートディレクトリ(CLPR)には、光ディスク７に記録されているクリップのデータが、クリップ毎に異なるディレクトリに分けて管理されている。

なお、クリップとは、図示せぬ撮像装置（例えば、デジタルビデオレコーダ等）の撮像処理の回数の単位である。またそれ以外にも、クリップは、その撮像処理の撮像開始から撮像終了までの時間を示す単位を示したり、その撮像処理により得られた各種のデータの長さを示す単位を示したり、その撮像処理により得られた各種のデータのデータ量を示す単位を示したりする。さらに、クリップは、その各種のデータの集合体そのものも示す場合もある。

ここでは、クリップとは、例えば、１回の撮像処理（撮像開始から撮像終了までの撮像処理）により得られた画像データおよびその画像データに対応する音声データ、並びに、メタデータ等の集合体を指す。

即ち、ここでは、光ディスク７に記録される１つのクリップとは、上述した図３に示されるような、マスタファイル（Master File）、ビデオファイル(Video)、１乃至８チャンネルのそれぞれのオーディオファイル（Audio1乃至8）、および、メタデータ（Metadata）の集合体を指す。

具体的には、例えば、図２４は、光ディスク７に３つのクリップのデータが記録されている場合の例を示しており、３つのクリップのデータのそれぞれは、第１のクリップディレクトリ（C0001）、第２のクリップディレクトリ（C0002）、および、第３のクリップディレクトリ（C0003）といった３つのディレクトリのそれぞれに分けられて管理されている。

即ち、例えば、光ディスク７に記録された最初のクリップの各データは、第１のクリップディレクトリ（C0001）以下のファイルとして管理されている。

具体的には、例えば、図２４に示されるように、この第１のクリップディレクトリ（C0001）には、このクリップを管理するファイルであるマスタファイル（C0001C01.SMI）、このクリップの画像データを含むファイルであるビデオファイル（C0001V01.MXF）、このクリップの各チャンネルの音声データのそれぞれを含む８つのファイルであるオーディオファイル（C0001A01.MXF乃至C0001A08.MXF）、このクリップのサブストリームデータを含むファイルであるローレゾデータファイル（C0001S01.MXF）、このクリップのエッセンスデータに対応する、リアルタイム性を要求されないメタデータ（以下、ノンリアルタイムメタデータと称する）を含むファイルであるノンリアルタイムメタデータファイル（C0001M01.XML）、このクリップのエッセンスデータに対応する、リアルタイム性を要求されるメタデータ（以下、リアルタイムメタデータと称する）を含むファイルであるリアルタイムメタデータファイル（C0001R01.BIM）が設けられている。

このように、図２４の例では、再生時にリアルタイム性を要求されるデータである、画像（ビデオ）データ、ローレゾデータ、およびリアルタイムメタデータは、それぞれ１つのファイルとして管理され、読み出し時間が増加しないようになされている。なお、ローレゾデータとは、例えば、ビデオファイルに含まれる画像データと内容は同一の（各画像自体は同一の）画像データであるが、解像度が下げられたりしている画像データ等を指す。

また、上述したように、音声データも、再生時にリアルタイム性を要求されるが、7.1チャンネル等のような音声の多チャンネル化に対応するために、８チャンネル用意され、それぞれ異なるファイルとして管理されている。即ち、ここでは、音声データは８つのファイルとして管理されるように説明したが、これに限らず、音声データに対応するファイルは、７つ以下であってもよいし、９つ以上であってもよい。

同様に、画像データ、ローレゾデータ、およびリアルタイムメタデータも、場合によって、それぞれ、２つ以上のファイルとして管理されるようにしてもよい。

また、図２４の例では、ノンリアルタイムメタデータファイル（C0001M01.XML）は、汎用性を持たせるためにXML形式で記述されているが、リアルタイムメタデータファイル（C0001R01.BIM）は、再生処理の処理時間や処理に必要な負荷を軽減させるために、XML形式のファイルをコンパイルしたBIM（BInary format for MPEG-7 data）形式のファイルとされている。

上述したような第１のクリップディレクトリ（C0001）のファイルの構成例は、全てのクリップディレクトリ、即ち、図２４の例では、第２のクリップディレクトリ（C0002）および第３のクリップディレクトリ（C0003）においても、同様のファイルの構成例を適用することができる。従って、それらの説明については省略する。

図２４において、このようなクリップルートディレクトリ（CLPR）の下方に示される、エディットリストルートディレクトリ（EDTR）には、光ディスク７に記録されているエディットリストが、その編集処理毎に異なるディレクトリに分けて管理されている。例えば、図２４の例の場合、４つのエディットリストのそれぞれが、第１のエディットリストディレクトリ（E0001）、第２のエディットリストディレクトリ（E0002）、第３のエディットリストディレクトリ（E0003）、および、第４のエディットリストディレクトリ（E0004）といった４つのディレクトリのそれぞれに分けられて管理されている。

即ち、例えば、光ディスク７に記録されたクリップの１回目の編集結果を示すエディットリストは、第１のエディットリストディレクトリ(E0001)以下のファイルとして管理される。

具体的には、例えば、図２４に示されるように、この第１のエディットリストディレクトリ(E0001)には、この編集結果（エディットリスト）を管理するファイルであるエディットリストファイル（E0001E01.SMI）、この編集後の素材データ（編集に用いられた全クリップの素材データの内、編集後のデータとして抽出された部分）に対応するメタデータ、または、そのメタデータに基づいて新たに生成されたメタデータを含むファイルであるエディットリスト用メタデータファイル（E0001M01.XML）が設けられている。

なお、素材データとは、各クリップを構成するデータのうちの、編集の対象となるデータ、即ち、画像データ（ビデオファイル）や音声データ（オーディオファイル）等を指す。

エディットリストファイル（E0001E01.SMI）は、例えば、図２５に示されるように記述される。即ち、図２５は、XMLで記述されたエディットリストファイルの具体的な記述例を示す図である。なお、図２５において、各行頭の数字は、説明の便宜上付加したものであり、XML記述の一部ではない。

エディットリストファイルは、クリップの非破壊編集の編集情報を含むファイルであり、その編集結果の再生方法についても記述されている。

図２５に示されるように、エディットリストファイルのXML記述は、主にボディタグ（<body> </body>）で囲まれるボディ部により構成される。図２５の例では、このボディ部は、７乃至２１行目に記述されている。なお、１乃至６行目には、このファイルがProfessioanal DiscのEdit List（エディットリスト）であることを示す情報が記述されている。

詳細には、ボディ部には、編集記述の時間的振る舞いと関係する情報が記述される。図２５の例では、８行目の開始タグ「<par>」と２０行目の終了タグ「</par>」の間に記述されるpar要素は、時間コンテナであり、複数の要素を同時に再生する単純時間グループを定義する。図２５の例では、第１のクリップ（図２５の例では、Clip１と記述されており、例えば、図２４の第１のクリップディレクトリ（C0001）で管理されているクリップであるとする）と第２のクリップ（図２５の例では、Clip2と記述されており、例えば、図２４の第２のクリップディレクトリ（C0002）で管理されているクリップであるとする）が同時に再生されるように示されている。ただし、図２５の例の場合、後述するように、２つのクリップの再生開始時間が互いにずれており、実際には、この２つのクリップが連続して再生されるように為されている。

図２５において、１０行目乃至１３行目のref要素には、参照するファイルおよび参照するファイルを再生する際の条件等が記述されている。１１行目の「src="urn:smpte:umid:060A2B340101010501010D1213000000FEDCBA9876543210FEDCBA9876543210"」の記述は、参照先のファイルに割り当てられたUMID（Unique Material IDentifier）が「060A2B340101010501010D1213000000FEDCBA9876543210FEDCBA9876543210」であることを示している。

なお、UMIDとは、各クリップをグローバルユニークに識別するためのクリップ固有の識別子であって、SMPTE（Society of Motion Picture and Television Engineers）により定められる識別子を指す。

また、１２行目の「begin="smpte-30=00:00:00:00"」の記述は、この第１のクリップが開始される時刻、すなわち、素材が開始されるエディットリストのFTC（File Time Code）上での位置を示しており、単位はフレーム数である。なお、「smpte-30」は、使用するタイムコードが、SMPTEで定義される３０フレーム毎秒のSMPTEタイムコードであることを示す記述である。

また、１３行目の「clipBegin="smpte-30=00:00:00:00"」記述は、この第１のクリップの、再生を開始する位置、すなわち、素材の切り出し開始地点をこの第１のクリップのFTC上で示しており、単位はフレーム数である。その記述に続く（１３行目の）「clipEnd="smpte-30=00:10:00:00"」は、この第１のクリップの再生を終了する位置、すなわち、素材の切り出し終了地点をこの第１のクリップのFTC上で示している。

以上のように、図２５の例では、第１のクリップは、時刻「00:00:00:00」に、フレーム番号「00:00:00:00」の位置から再生が開始され、フレーム番号「00:10:00:00」の位置まで再生されることが、このエディットリストに記述されている。

また、第２のクリップについても、１５行目乃至１９行目において、第１のクリップの場合と同様に記述されている。図２５の例では、第２のクリップは、時刻「00:10:00:00」に、フレーム番号「00:00:00:00」の位置から再生され、フレーム番号「00:05:30:00」の位置まで再生されることが、このエディットリストに記述されている。

そして、このエディットリストにおいては、以上のような第１のクリップの再生と第２のクリップの再生がpar要素により、同時に行われるように指定されている。従って、結果として、時刻「00:00:00:00」に、第１のクリップがフレーム番号「00:00:00:00」の位置からフレーム番号「00:10:00:00」まで再生される。これにより、時刻「00:10:00:00」になると、今度は、第２のクリップがフレーム番号「00:00:00:00」の位置からフレーム
番号「00:05:30:00」の位置まで再生される。以上のように、図２５に示されるエディットリストにおいては、第１のクリップと第２のクリップが、連続して再生されるように編集されていることが示されている。

換言すると、このエディットリストは、第１のクリップ（Clip1）を10分再生し、その後に第２のクリップ（Clip2）を5分30秒再生することを示している。

以上のように、エディットリストファイルのXML記述には、クリップの非破壊編集の編集情報が記述されており、参照するクリップが記述されている。すなわち、ディスク装置１や編集装置３等（図１）は、このエディットリストファイルを参照することにより、エディットリストが参照するクリップを特定することができる。

なお、図２５において、各データを示すUMIDの例が上述したように記述してあるが、これらは、エディットリスト内のUMIDの記述位置等を示すだけのものであり、それらの値が意味を持たない仮想のUMIDである。即ち、図２５に記載されているUMIDは、実際のUMIDとは異なる意味の無いシンボルの組合せであり、実際には、SMPTEの定める方法に基づいて作成された正当なUMIDが上述した仮想UMIDの代わりに各位置に記述される。

図２４に戻り、以上説明した第１のエディットリストディレクトリ(E0001)のファイルの構成例は、全てのエディットリスト（編集結果）、即ち、図２４の例では、第２のエディットリストディレクトリ（E0002）乃至第４のエディットリストディレクトリ（E0004）においても、同様のファイルの構成例を適用することができる。従って、それらの説明については省略する。

以上において、１回の編集作業に対応するエディットリストディレクトリ（E0001乃至E0004）に含まれる各ファイルについて説明したが、ファイルの構成は上述した例に限らず、どのような構成であってもよい。

以上、PROAVディレクトリ１５１の構成例について説明した。次に、Generalディレクトリの構成例について説明する。

Generalディレクトリには、AVデータ以外のファイルが設けられる。具体的には、例えば、図２４の例では、ファイル（一般ファイル）が設けられている。

図２３に戻り、以上説明したようなディレクトリ構成（図２４）で各データがファイルとして記録されている光ディスク７を対象とする転送処理について、以下、説明していく。

操作部１５（図１）から転送処理を起動させる指令（ユーザの操作に対応する信号）が主制御部１４に入力されると、主制御部１４は、転送処理を開始する（起動する）。

即ち、ステップＳ２０１において、主制御部１４は、ディスク駆動部１１を制御して、光ディスク７にアクセスし、光ディスク７の記録内容を解析し、その解析結果に基づいて、「光ディスク７に記録されている各ファイルの中から、処理対象のファイル単体または複数のファイルの組合せをユーザに容易に指定させるための、ユーザインタフェース用画像（以下、このような画像を、処理対象指定画像と称する）」のデータを生成する。

なお、ステップＳ２０１は、一つの処理としてまとめられているが、実際には、図示はしないが、次のような第１の実行部と第２の実行部とのそれぞれにより実行される処理とすることができる。即ち、第１の実行部（特定部）とは、ディスク駆動部１１を制御して、光ディスク７にアクセスし、光ディスク７の記録内容を解析し、その解析結果に基づいて、処理対象を特定するまでの処理（後述する図２５に示されるような仮想ディレクトリ構造を生成するまでの処理）を実行するブロックである。これに対して、第２の実行部（生成部）は、特定された処理対象を羅列した画像（処理対象指定画像であって、例えば、図２５に示される画像）に対応する画像データを生成するブロックである。なお、第１の実行部と第２の実行部のそれぞれは、ソフトウェアで構成することもできるし、ハードウェアで構成することもできるし、或いは、それらの組合せで構成することもできる。

そして、ステップＳ２０２において、主制御部１４は、表示制御部１６を制御して、ステップＳ２０１で生成された画像データに対応する画像、即ち、処理対象指定画像を表示部１７に表示させる。

具体的には、例えば、いまの場合、光ディスク７の記録内容は、上述したように図２４に示されるような内容（データ構造）とされているので、主制御部１４は、例えば、図２６に示されるような処理対象指定画像を表示部１７に表示させる。

即ち、図２６は、図２４に示される光ディスク７の記録内容に基づいて生成された処理対象指定画像の例を示している。

図２６において、その右方にClipと記述されているシンボル１６１は、光ディスク７に設けられている実際のディレクトリ（図２４）のうちの、クリップルートディレクトリ（CLPR）に対応する仮想ディレクトリを示す。なお、符号は付していないが、シンボル（仮想ディレクトリ）１６１と同一のその他のシンボルも、所定の１つの仮想ディレクトリを示す。

シンボル１６２は、ユーザが操作部１５を操作して指定することができる、１つの仮想ファイル（処理対象候補）を表している。なお、符号は付していないが、シンボル（仮想ファイル）１６２と同一のその他のシンボルも、所定の１つの仮想ファイルを示す。

ここで、仮想ファイル（処理対象候補）について説明する。

例えば、後述するように、転送処理においては、光ディスク７に記録されている各ファイルのうちの１つのクリップ（複数のファイルの組合せ）が光ディスク７から読み出され、フォーマット変換がなされた後、ネットワーク４を介して他の装置（図１の例では、AV装置５または６）に転送される。従って、この転送処理においては、転送される１つのクリップが処理対象となる。

このような一連の処理の前処理、即ち、処理対象のクリップをユーザに指定させるための処理の一つとして、例えば仮に、従来の様に、図２４に示される画像（即ち、光ディスク７のデータ構造そのものを示す画像）が表示部１７に表示されたとする。

この場合、ユーザは、例えば、上述した第１のクリップを処理対象として指定する場合、第１のクリップディレクトリ（C0001）の下に設けられているファイルの中から、第１のクリップを構成する全てのファイルを指定しなければならない。即ち、図２４の例では、ユーザは、操作部１５を操作して、クリップディレクトリ（C0001）の下に設けられている全てのファイル（ビデオファイル(C0001C01.SMI)乃至リアルタイムメタデータファイル(C0001R01.BIM)を処理対象として指定する、といった煩雑で時間のかかる操作をしなければならない。

さらに、図２４の例では、たまたま、クリップディレクトリ（C0001）の下に設けられている全てのファイルが、第１のクリップを構成するために必要なファイルとされているが、実際には、第１のクリップとは関係ないファイルが、クリップディレクトリ（C0001）の下に設けられている可能性もある。このような場合、ユーザは、ファイルの右方に表示されるその名称（例えば、C0001C01.SMI等）だけを頼りに、第１のクリップを構成するために必要なファイルを見つけ出した後はじめて、見つけ出したそれらのファイルを処理対象として指定する、といったさらに煩雑で時間のかかる操作をしなければならない。

そこで、本実施の形態では、このような処理対象を指定するユーザ操作の負担を軽減させるために、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、ユーザが処理対象として指定する可能性のある1以上のファイルの組合せ、即ち、ファイル単体または複数のファイル組合せ（上述した例では、ビデオファイル(C0001C01.SMI)乃至リアルタイムメタデータファイル(C0001R01.BIM)の組合せである第１のクリップ）を１組以上特定する。なお、以下、ユーザが処理対象として指定し得る1以上のファイル組合せを、処理対象候補と称する。

次に、主制御部１４は、このようにして特定された１以上の処理対象候補毎に、対応する処理対象候補を構成する全データを含ませた１つの仮想ファイルを生成する。そして、主制御部１４は、生成された１以上の仮想ファイルのそれぞれを、予め構成されている仮想ディレクトリ構造（例えば、図２６に示されるようなディレクトリ構造）に含まれる１以上の仮想ディレクトリのうちの所定の１つに配置させ、１以上の仮想ファイルのそれぞれを示すシンボル（例えば、図２６のシンボル１６２）、および、１以上の仮想ディレクトリのそれぞれを示すシンボル（例えば、図２６のシンボル１６１）が、上述した仮想ディレクトリ構造に従って羅列された画像（データ）を（例えば、図２６の画像を）、処理対象指定画像として生成し、表示部１７に表示させるのである。

なお、仮想ファイルや仮想ディレクトリの名称は、ユーザが認識可能な名称であれば限定されないが、本実施の形態では、光ディスク７内の実際のファイルやディレクトリの名称そのものか、或いは、その実際の名称を容易に推定可能（ユーザにとって）な類似名称とされる。また、仮想ファイル（表示されるシンボル）は、上述したように、ユーザが処理対象を指定するためのシンボルであるので、その名称を表示させることは必須ではない。ただし、本実施の形態では、図２６に示されるように、仮想ファイルに対応する実際のファイル（光ディスク７に記録されている実際の１以上のファイル）が如何なるファイルであるのかをユーザに容易に視認させることを目的として、その仮想ファイルを示すシンボルの図中右方には、その仮想ファイルの名称が配置されている（表示される）のでる。

さらに、本実施の形態では、仮想ファイルに対応する実際のファイルが如何なるファイルであるのかをユーザにさらに容易に視認させることを目的として、その仮想ファイルの名称には、対応する実際のファイルの拡張子（実際のファイルが複数の場合、主要なファイルの拡張子）がつけられている（そのように表示されている）。

以下、図２６に示されている、仮想ディレクトリ（シンボル）と仮想ファイル（シンボル）について、個別に順次（図中上から順番に）説明していく。

なお、以下、特に断りの無い限り、仮想ディレクトリと仮想ディレクトリのシンボルとは同一であるとみなして説明する。同様に、仮想ファイルと仮想ファイルのシンボルとは同一であるとみなして説明する。また、各仮想ディレクトリのそれぞれ、および、各仮想ファイルのそれぞれの識別を容易なものとするために、以下、仮想ファイルまたは仮想ディレクトリの後方に括弧（ ）書きでその名称を記載する。

図２６中、一番上の仮想ファイル（INDEX.XML）は、図２４のインデックスファイル（INDEX.XML）およびインデックスファイル（INDEX.RSV）の２つに対応する。即ち、ユーザが、この仮想ファイル（INDEX.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、インデックスファイル（INDEX.XML）およびインデックスファイル（INDEX.RSV）の２つを処理対象として指定する。

仮想ファイル（INDEX.XML）の下方に示される仮想ファイル（DISCINFO.XML）は、図２４のディスクインフォメーションファイル（DISCINFO.XML）およびディスクインフォメーションファイル（DISKINFO.RSV）の２つに対応する。即ち、ユーザが、この仮想ファイル（DISCINFO.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、ディスクインフォメーションファイル（DISCINFO.XML）およびディスクインフォメーションファイル（DISKINFO.RSV）の２つを処理対象として指定する。

仮想ファイル（INDEX.XML）の下方に示される仮想ディレクトリ（Clip）１６１は、上述したように、図２４のクリップルートディレクトリ（CLPR）に対応する。

図２６の例では、この仮想ディレクトリ（Clip）１６１には、６つの仮想ファイル（C0001.MXF乃至C0003M01.XML）が設けられている。

仮想ファイル（C0001.MXF）１６２は、上述したように、第１のクリップを構成するファイル、即ち、図２４の第１のクリップディレクトリ（C0001）に含まれる全てのファイルに対応する。具体的には、仮想ファイル（C0001.MXF）１６２は、図２４に示される、マスタファイル（C0001C01.SMI）、ビデオファイル（C0001V01.MXF）、８つのオーディオファイル（C0001A01.MXF乃至C0001A08.MXF）、ローレゾデータファイル（C0001S01.MXF）、ノンリアルタイムメタデータファイル（C0001M01.XML）、およびリアルタイムメタデータファイル（C0001R01.BIM）といった総計１３のファイルに対応する。即ち、ユーザが、この仮想ファイル（C0001.MXF）１６２を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、第１のクリップを構成するこれら１３のファイルを処理対象として指定する。

これに対して、仮想ファイル（C0001M01.XML）は、図２４のノンリアルタイムメタデータファイル（C0001M01.XML）１つに対応する。即ち、ユーザが、この仮想ファイル（C0001M01.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、ノンリアルタイムメタデータファイル（C0001M01.XML）１つを処理対象として指定する。

このように、クリップそのものではなく、クリップを構成する各ファイルのうちの任意のファイルを任意の数だけ対応させた仮想ファイルを生成することも可能である。即ち、ユーザが処理対象として指定する可能性のある組合せ（考え得る全ての処理対象候補）のいずれも仮想ファイルとして生成することが可能である。

仮想ファイル（C0002.MXF）は、第２のクリップを構成するファイル、即ち、図２４の第２のクリップディレクトリ（C0002）に設けられている全ての（１３個の）ファイル（図２４には図示せず）に対応する。即ち、ユーザが、この仮想ファイル（C0002.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、第２のクリップを構成するこれら１３のファイルを処理対象として指定する。

仮想ファイル（C0002M01.XML）は、図２４には図示されていないが、図２４のクリップディレクトリ（C0002）に設けられているノンリアルタイムメタデータファイル（C0002M01.XML）１つに対応する。即ち、ユーザが、この仮想ファイル（C0002M01.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、ノンリアルタイムメタデータファイル（C0002M01.XML）１つを処理対象として指定する。

同様に、仮想ファイル（C0003.MXF）は、第３のクリップを構成するファイル、即ち、図２４のクリップディレクトリ（C0003）に設けられている全ての（１３個の）ファイル（図２４には図示せず）に対応する。即ち、ユーザが、この仮想ファイル（C0003.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、第３のクリップを構成するこれら１３のファイルを処理対象として指定する。

仮想ファイル（C0003M01.XML）は、図２４には図示されていないが、図２４のクリップディレクトリ（C0003）に設けられているノンリアルタイムメタデータファイル（C0003M01.XML）１つに対応する。即ち、ユーザが、この仮想ファイル（C0003M01.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、ノンリアルタイムメタデータファイル（C0003M01.XML）１つを処理対象として指定する。

この仮想ファイル（C0003M01.XML）の下方に示される仮想ディレクトリ（Edit）は、図２４のエディットリストルートディレクトリ（EDTR）に対応する。

図２６の例では、この仮想ディレクトリ（EDTR）には、１２の仮想ファイル（E0001.MXF乃至E0004M01.XML）が設けられている。

仮想ファイル（E0001.MXF）は、図２４の第１のエディットリストディレクトリ（E0001）に設けられている全てのファイル、即ち、図２５に示されるようなエディットリストファイル（E0001E01.SMI）、および、エディットリスト用メタデータファイル（E0001M01.XML）といった２つのファイルに対応する。即ち、ユーザが、この仮想ファイル（E0001.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリストファイル（E0001E01.SMI）に記述されている編集情報に基づいて再構成されたクリップ(例えば、エディットリストファイルE0001E01.SMIが図25に示されるエディットファイルデアルであるとすると、第１のクリップ（C0001.MXF）の00:00:00:00〜00:10:00:00と第２のクリップ（C0002.MXF）の00:00:00:00〜00:05:30:00までの部分を繋ぎ合わせたもの)、および、エディットリスト用メタデータファイル（E0001M01.XML）を処理対象として指定する。

これに対して、仮想ファイル（E0001E01.SMI）は、エディットリストファイル（E0001E01.SMI）の１つに対応する。即ち、ユーザが、この仮想ファイル（E0001E01.SMI）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリストファイル（E0001E01.SMI）に記述されている編集情報に基づいて再構成されたクリップを処理対象として指定する。

また、仮想ファイル（E0001M01.XML）は、エディットリスト用メタデータファイル（E0001M01.XML）の１つに対応する。即ち、ユーザが、この仮想ファイル（E0001M01.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリスト用メタデータファイル（E0001M01.XML）の１つを処理対象として指定する。

以下、同様に、仮想ファイル（E0002.MXF）は、図２４の第２のエディットリストディレクトリ（E0002）に設けられている全てのファイル、即ち、図２４には図示はされていないが、エディットリストファイル（E0002E01.SMI）、および、エディットリスト用メタデータファイル（E0002M01.XML）といった２つのファイルに対応する。即ち、ユーザが、この仮想ファイル（E0002.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリストファイル（E0002E01.SMI）に記述されている編集情報に基づいて再構成されたクリップ、および、エディットリスト用メタデータファイル（E0002M01.XML）を処理対象として指定する。

仮想ファイル（E0002E01.SMI）は、図２４の第２のエディットリストディレクトリ（E0002）に設けられている２つのファイルのうちの、エディットリストファイル（E0002E01.SMI）の１つに対応する。即ち、ユーザが、この仮想ファイル（E0002E01.SMI）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリストファイル（E0002E01.SMI）に記述されている編集情報に基づいて再構成されたクリップを処理対象として指定する。

仮想ファイル（E0002M01.XML）は、図２４の第２のエディットリストディレクトリ（E0002）に設けられている２つのファイルのうちの、エディットリスト用メタデータファイル（E0002M01.XML）の１つに対応する。即ち、ユーザが、この仮想ファイル（E0002M01.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリスト用メタデータファイル（E0002M01.XML）の１つを処理対象として指定する。

仮想ファイル（E0003.MXF）は、図２４の第３のエディットリストディレクトリ（E0003）に設けられている全てのファイル、即ち、図２４には図示はされていないが、エディットリストファイル（E0003E01.SMI）、および、エディットリスト用メタデータファイル（E0003M01.XML）といった２つのファイルに対応する。即ち、ユーザが、この仮想ファイル（E0003.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリストファイル（E0003E01.SMI）に記述されている編集情報に基づいて再構成されたクリップ、および、エディットリスト用メタデータファイル（E0003M01.XML）を処理対象として指定する。

仮想ファイル（E0003E01.SMI）は、図２４の第３のエディットリストディレクトリ（E0003）に設けられている２つのファイルのうちの、エディットリストファイル（E0003E01.SMI）の１つに対応する。即ち、ユーザが、この仮想ファイル（E0003E01.SMI）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリストファイル（E0003E01.SMI）に記述されている編集情報に基づいて再構成されたクリップを処理対象として指定する。

仮想ファイル（E0003M01.XML）は、図２４の第３のエディットリストディレクトリ（E0003）に設けられている２つのファイルのうちの、エディットリスト用メタデータファイル（E0003M01.XML）の１つに対応する。即ち、ユーザが、この仮想ファイル（E0003M01.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリスト用メタデータファイル（E0003M01.XML）の１つを処理対象として指定する。

仮想ファイル（E0004.MXF）は、図２４の第４のエディットリストディレクトリ（E0004）に設けられている全てのファイル、即ち、図２４には図示はされていないが、エディットリストファイル（E0004E01.SMI）、および、エディットリスト用メタデータファイル（E0004M01.XML）といった２つのファイルに対応する。即ち、ユーザが、この仮想ファイル（E0004.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリストファイル（E0004E01.SMI）に記述されている編集情報に基づいて再構成されたクリップ、および、エディットリスト用メタデータファイル（E0004M01.XML）を処理対象として指定する。

仮想ファイル（E0004E01.SMI）は、図２４の第４のエディットリストディレクトリ（E0004）に設けられている２つのファイルのうちの、エディットリストファイル（E0004E01.SMI）の１つに対応する。即ち、ユーザが、この仮想ファイル（E0004E01.SMI）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリストファイル（E0004E01.SMI）に記述されている編集情報に基づいて再構成されたクリップを処理対象として指定する。

仮想ファイル（E0004M01.XML）は、図２４の第４のエディットリストディレクトリ（E0004）に設けられている２つのファイルのうちの、エディットリスト用メタデータファイル（E0004M01.XML）の１つに対応する。即ち、ユーザが、この仮想ファイル（E0004M01.XML）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、エディットリスト用メタデータファイル（E0004M01.XML）の１つを処理対象として指定する。

ところで、上述した例では、仮想ディレクトリは、光ディスク７に実際に設けられている（図２４に図示されている）ディレクトリと対応させていたが、特に対応させる必要はなく、ユーザの操作性が向上するように、任意の仮想ディレクトリを設けることができる。

例えば、図２６の例では、仮想ファイル（E0004M01.XML）の下方に、ローレゾデータを処理対象として指定するために生成される仮想ファイル（C0001S01.MXF乃至C0003S01.MXF）が配置される仮想ディレクトリ（Sub）が設けられている。

即ち、図２６の例では、この仮想ディレクトリ（EDTR）には、３の仮想ファイル（C0001S01.MXF乃至C0003S01.MXF）が設けられている。

仮想ファイル（C0001S01.MXF）は、実際には、図２４のクリップルートディレクトリ（CLPR）の第１のクリップディレクトリ（C0001）内に設けられているローレゾデータファイル（C0001S01.MXF）１つに対応する。即ち、ユーザが、この仮想ファイル（C0001S01.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、ローレゾデータファイル（C0001S01.MXF）１つを処理対象として指定する。

同様に、仮想ファイル（C0002S01.MXF）は、実際には（図２４には図示されていないが）、図２４のクリップルートディレクトリ（CLPR）の第２のクリップディレクトリ（C0002）内に設けられているローレゾデータファイル（C0002S01.MXF）１つに対応する。即ち、ユーザが、この仮想ファイル（C0002S01.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、ローレゾデータファイル（C0002S01.MXF）１つを処理対象として指定する。

仮想ファイル（C0003S01.MXF）は、実際には（図２４には図示されていないが）、図２４のクリップルートディレクトリ（CLPR）の第３のクリップディレクトリ（C0003）内に設けられているローレゾデータファイル（C0003S01.MXF）１つに対応する。即ち、ユーザが、この仮想ファイル（C0003S01.MXF）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、ローレゾデータファイル（C0003S01.MXF）１つを処理対象として指定する。

この仮想ファイル（C0003S01.MXF）の下方に示される仮想ディレクトリ（General）は、図２４の同一名称の実ディレクトリ（General）に対応する。

図２６の例では、この仮想ディレクトリ（General）には、仮想ファイル（一般ファイル）が設けられている。

仮想ファイル（一般ファイル）は、図２４の同一名称のファイル（一般ファイル）の１つに対応する。即ち、ユーザが、この仮想ファイル（一般ファイル）を選択した場合、主制御部１４は、光ディスク７に記録されている各ファイルのうちの、同一名称のファイル（一般ファイル）の１つを処理対象として指定する。

図２３に戻り、ステップＳ２０２の処理で、このような処理対象指定画像（図２６）を表示部１７（図１）に表示させると、主制御部１４は、ステップＳ２０３において、処理対象のクリップが選択されたか否かを判定する。

この間、ユーザは、操作部１５を操作しながら、表示部１７に表示された処理対象指定画像（図２６）の中から、処理対象のクリップ、即ち、転送を所望するクリップを示す仮想ファイルを選択する。

即ち、ユーザにより仮想ファイルが選択されるまで、ステップＳ２０３において、処理対象のクリップが選択されていないと判定され、処理はステップＳ２０３に戻され、処理対象のクリップが選択されたか否かが再度判定される、といったループ処理が繰り返される。

例えば、いま、上述したように、ユーザが、操作部１５を操作して、第１のクリップを示す仮想ファイル(C0001.MXF)１６２（図２６）を選択したとする。即ち、操作部１５が、仮想ファイル(C0001.MXF)が選択されたことを示す信号を主制御部１４に供給したとする。

主制御部１４は、この信号を取得すると、ステップＳ２０３において、処理対象のクリップが選択されたと判定し、ステップＳ２０４において、ディスク駆動部１１を制御して、光ディスク７からそのクリップ（処理対象）を読み出し、フォーマット変換部１２に供給する。

即ち、上述したように、いま選択された仮想ファイル（C0001.MXF）１６２は、第１のクリップを構成するファイル、即ち、図２４の第１のクリップディレクトリ（C0001）に含まれる全てのファイルに対応する。具体的には、仮想ファイル（C0001.MXF）１６２は、図２４に示される、マスタファイル（C0001C01.SMI）、ビデオファイル（C0001V01.MXF）、８つのオーディオファイル（C0001A01.MXF乃至C0001A08.MXF）、ローレゾデータファイル（C0001S01.MXF）、ノンリアルタイムメタデータファイル（C0001M01.XML）、およびリアルタイムメタデータファイル（C0001R01.BIM）といった総計１３のファイルに対応する。従って、ステップＳ２０４の処理で、光ディスク７に記録されている各ファイルのうちの、第１のクリップを構成するこれら１３のファイルがディスク駆動部１１により読み出され、フォーマット変換部１２に供給される。

すると、ステップＳ２０５において、フォーマット変換部１２は、主制御部１４の制御に基づいて、ディスク駆動部１１から供給されたこのクリップ（第１のクリップ）のフォーマットを変換する。即ち、ステップＳ２０５の処理として、上述した図１８乃至図２２のそれぞれのフローチャートに従った処理が実行されて、第１のクリップのフォーマットが、上述したように、AV独立フォーマットから標準AV多重フォーマットに変換される。

そして、この標準AV多重フォーマットのクリップ（第１のクリップ）は、フォーマット変換部１２から通信I/F１３に供給される。

すると、ステップＳ２０６において、通信I/F１３は、主制御部１３の制御に基づいて、フォーマット変換部１２から供給されたクリップ（標準AV多重フォーマットの第１のクリップ）をネットワーク４を介して他の装置（図１の例では、AV装置５または６）に転送する。

これにより、転送処理は終了となる。

ところで、上述した一連の処理は、ハードウェアにより行うこともできるし、ソフトウェアにより行うこともできる。一連の処理をソフトウェアによって行う場合には、そのソフトウェアを構成するプログラムが、汎用のコンピュータ等にインストールされる。

そこで、図２７は、上述した一連の処理を実行するプログラムがインストールされるコンピュータの一実施の形態の構成例を示している。

プログラムは、コンピュータに内蔵されている記録媒体としてのハードディスク２０５やＲＯＭ２０３に予め記録しておくことができる。

あるいはまた、プログラムは、フレキシブルディスク、CD-ROM(Compact Disc Read Only Memory)，MO(Magneto Optical)ディスク，DVD(Digital Versatile Disc)、磁気ディスク、半導体メモリなどのリムーバブル記録媒体２１１に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体２１１は、いわゆるパッケージソフトウエアとして提供することができる。

なお、プログラムは、上述したようなリムーバブル記録媒体２１１からコンピュータにインストールする他、ダウンロードサイトから、ディジタル衛星放送用の人工衛星を介して、コンピュータに無線で転送したり、LAN(Local Area Network)、インターネットといったネットワークを介して、コンピュータに有線で転送し、コンピュータでは、そのようにして転送されてくるプログラムを、通信部２０８で受信し、内蔵するハードディスク２０５にインストールすることができる。

コンピュータは、CPU(Central Processing Unit)２０２を内蔵している。CPU２０２には、バス２０１を介して、入出力インタフェース２１０が接続されており、CPU２０２は、入出力インタフェース２１０を介して、ユーザによって、キーボードや、マウス、マイク等で構成される入力部２０７が操作等されることにより指令が入力されると、それにしたがって、ROM(Read Only Memory)２０３に格納されているプログラムを実行する。あるいは、また、CPU２０２は、ハードディスク２０５に格納されているプログラム、衛星若しくはネットワークから転送され、通信部２０８で受信されてハードディスク２０５にインストールされたプログラム、またはドライブ２０９に装着されたリムーバブル記録媒体２１１か
ら読み出されてハードディスク２０５にインストールされたプログラムを、RAM(Random Access Memory)２０４にロードして実行する。これにより、CPU２０２は、上述したフローチャートにしたがった処理、あるいは上述したブロック図の構成により行われる処理を行う。そして、CPU２０２は、その処理結果を、必要に応じて、例えば、入出力インタフェース２１０を介して、LCD(Liquid Crystal Display)やスピーカ等で構成される出力部２０６から出力、あるいは、通信部２０８から送信、さらには、ハードディスク２０５に記録等させる。

ここで、本明細書において、コンピュータに各種の処理を行わせるためのプログラムを記述する処理ステップは、必ずしもフローチャートとして記載された順序に沿って時系列に処理する必要はなく、並列的あるいは個別に実行される処理（例えば、並列処理あるいはオブジェクトによる処理）も含むものである。

また、プログラムは、１のコンピュータにより処理されるものであっても良いし、複数のコンピュータによって分散処理されるものであっても良い。さらに、プログラムは、遠方のコンピュータに転送されて実行されるものであっても良い。

以上のように、ビデオデータとオーディオデータとが多重化されてボディに配置される標準AV多重フォーマットのファイルと、ビデオデータまたはオーディオデータそれぞれがまとめてボディに配置されるAV独立フォーマットのファイルとの間の相互変換を行うようにしたので、例えば、ネットワーク４を介してのファイルの伝送（ファイル交換やストリーミング）を行う場合には、標準AV多重フォーマットを使用し、光ディスク７へのファイルの記録を行う場合には、AV独立フォーマットを使用することが可能となる。

そして、光ディスク７に、AV独立フォーマットのファイルを記録する場合には、例えば、AV独立編集を容易に行うことが可能となる。

また、AV独立フォーマットでは、フレーム単位のメタデータを、１つのファイル（フレーム単位のメタデータファイル）に集めて（まとめて）配置するようにしたので、フレーム単位のメタデータの検索を、高速で行うことが可能となる。

さらに、AV独立フォーマットでは、オーディオデータの符号化方式として、WAVEを採用しているので、AES3を採用する標準AV多重フォーマットの場合に比較して、オーディオデータのデータ量を低減することができる。

また、AV独立フォーマットでは、標準AV多重フォーマットと同一のヘッダ、ボディ、フッタという形を採用し、さらに、ヘッダとフッタについては、標準AV多重フォーマットと同一形式のヘッダとフッタを採用することとしたので、標準AV多重フォーマットに対応している標準装置であれば、AV独立フォーマットのファイルの送受信や、記録媒体に対する読み書きを行うことができる。

さらに、標準AV多重フォーマットのファイルでは、そのボディに、ビデオデータや、オーディオデータ、ユーザデータ、フレーム単位のメタデータといった複数のエッセンスが多重化されて配置されているのに対して、AV独立フォーマットのファイル（のビデオファイルとオーディオファイル）では、そのボディに、ビデオデータまたはオーディオデータだけが配置されている。従って、AV独立フォーマットのファイルは、単一エッセンスをボディとしたMXFのファイルということができる。そして、この単一エッセンスをボディとしたMXFのファイルであるビデオファイルやオーディオファイルについては、単一エッセンスをボディとしたMXFを理解することができる装置であれば、その内容を読み出すことができる。

なお、本実施の形態では、ディスク装置１において、光ディスク７に対して、AV独立フォーマットのファイルを読み書きするようにしたが、AV独立フォーマットのファイルは、光ディスク７などのディスク状の記録媒体に限らず、磁気テープなどのテープ状の記録媒体や、半導体メモリ等に対して読み書きすることが可能である。

また、図１の実施の形態では、ディスク駆動部１１、フォーマット変換部１２、通信I/F１３、主制御部１４、操作部１５、表示制御部１６、および、表示部１７によって、１つの装置であるディスク装置１を構成するようにしたが、ディスク駆動部１１、フォーマット変換部１２、通信I/F１３、主制御部１４、操作部１５、表示制御部１６、および、表示部１７のそれぞれは、独立した１つの装置とすることが可能である。

さらに、本実施の形態では、標準AV多重フォーマットのファイルとして、MXFに準拠したファイルを採用することとしたが、標準AV多重フォーマットのファイルとしては、MXFに準拠したファイルの他、ヘッダ、ボディ、フッタからなり、ボディに、任意の２つのデータ（以上）が多重化されて配置されるファイルを採用することが可能である。

また、本実施の形態では、標準AV多重フォーマットのファイルのボディに、ビデオデータとオーディオデータとを多重化したものが配置されることとしたが、標準AV多重フォーマットのファイルのボディには、その他、例えば、２以上のビデオデータ（のストリーム）を多重化したものや、２以上のオーディオデータ（のストリーム）を多重化したものを配置するようにすることが可能である。

本発明を適用したAVネットワークシステムの一実施の形態の構成例を示すブロック図である。 標準AV多重フォーマットを示す図である。 AV独立フォーマットを示す図である。 フォーマット変換部１２の構成例を示すブロック図である。 標準／独立変換部２１の構成例を示すブロック図である。 ビデオファイル生成部４１の構成例を示すブロック図である。 オーディオファイル生成部４３の構成例を示すブロック図である。 マスタファイル生成処理を説明するフローチャートである。 ファイル単位のメタデータファイル生成処理を説明するフローチャートである。 フレーム単位のメタデータファイル生成処理を説明するフローチャートである。 オグジュアリファイル生成処理を説明するフローチャートである。 ビデオファイル生成処理を説明するフローチャートである。 オーディオファイル生成処理を説明するフローチャートである。 独立／標準変換部２２の構成例を示すブロック図である。 ビデオファイル処理部１０５の構成例を示すブロック図である。 オーディオファイル処理部１０６の構成例を示すブロック図である。 データ合成部１０７の構成例を示すブロック図である。 メタデータファイル処理を説明するフローチャートである。 オグジュアリファイル処理を説明するフローチャートである。 ビデオファイル処理を説明するフローチャートである。 オーディオファイル処理を説明するフローチャートである。 合成処理を説明するフローチャートである。 転送処理を説明するフローチャートである。 光ディスク７の記録内容（データ構造）の例を示す図である。 エディットリストの記述例を示す図である。 表示部１７に表示される、図２４の光ディスク７の記述内容に対応する処理対象指定画像の例を示す図である。 本発明を適用したコンピュータの一実施の形態の構成例を示すブロック図である。

符号の説明

１，２ ディスク装置， ３ 編集装置， ４ ネットワーク， ５，６ AV装置， １１ ディスク駆動部， １２ フォーマット変換部， １３ 通信I/F， ２１ 標準／独立変換部， ２２ 独立／標準変換部， ３１ バッファ， ３２ マスタファイル生成部， ３３ ヘッダ取得部， ３４ ボディ取得部， ３５ ヘッダメタデータ抽出部， ３６ システムアイテム抽出部， ３７ メタデータファイル生成部， ３８ オグジュアリアイテム抽出部， ３９ オグジュアリファイル生成部， ４０ ピクチャアイテム抽出部， ４１ ビデオファイル生成部， ４２ サウンドアイテム抽出部， ４３ オーディオファイル生成部， ４４ バッファ， ５１ 結合部， ５２ ヘッダ／フッタ付加部， ６１ KLVデコーダ， ６２ チャネル分離部， ６３ データ変換部， ６４ KLVエンコーダ， ６５ ヘッダ／フッタ付加部， １０１ バッファ， １０２ ファイル取得部， １０３ メタデータファイル処理部， １０４ オグジュアリファイル処理部， １０５ ビデオファイル処理部， １０６ オーディオファイル処理部， １０７ データ合成部， １０８ バッファ， １１１ ヘッダ／フッタ除去部， １１２ 分解部， １２１ ヘッダ／フッタ除去部， １２２ KLVデコーダ， １２３ データ変換部， １２４ チャネル多重化部， １２５ KLVエンコーダ， １３１ ヘッダ／フッタ生成部， １３２ 多重化部， １３３ ヘッダ／フッタ付加部， １５１ ディレクトリ（を示すシンボル）, １５２ ファイル（を示すシンボル）， １６１ 仮想ディレクトリ（を示すシンボル）， １６２ 仮想ファイル（を示すシンボル）， ２０１ バス， ２０２ CPU， ２０３ ROM， ２０４ RAM， ２０５ ハードディスク， ２０６ 出力部， ２０７ 入力部， ２０８ 通信部， ２０９ ドライブ， ２１０ 入出力インタフェース， ２１１ リムーバブル記録媒体

Claims (5)

1. ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する変換装置であって、
   前記ボディに第１と第２のデータが多重化されて配置された第１のフォーマットのファイルと、前記ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方が供給された場合、それを他方に変換する変換手段と、
   前記ボディに前記第１のデータがまとめて配置された前記第２のフォーマットの第１のファイルと、前記ボディに前記第２のデータがまとめて配置された前記第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体が装着される装着手段と、
   前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルの中から、前記変換手段の処理対象候補として、前記第１のファイルと前記第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せを１組以上特定する特定手段と、
   前記特定手段により特定された１以上の前記処理対象候補のそれぞれを示すシンボルが羅列された画像を生成する生成手段と、
   前記生成手段により生成された前記画像を表示装置に表示させることを制御する表示制御手段と、
   前記表示制御手段の制御により前記表示装置に表示された前記画像に含まれる１以上の前記シンボルの中から、前記変換手段の次の処理対象として所望する前記処理対象候補を示す前記シンボルを指定するときにユーザによって操作される操作手段と、
   前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルのうちの、前記ユーザが前記操作手段を操作することで指定した前記シンボルに対応する前記処理対象候補を読み出し、読み出された前記処理対象候補が前記第１のファイルと前記第２のファイルとの組合せの場合、前記第１のファイルと前記第２のファイルを前記変換手段に供給する読み出し手段と
   を備えることを特徴とする変換装置。
2. 前記特定手段は、特定された１以上の前記処理対象候補毎に、対応する前記処理対象候補を構成する全データを含ませた１つの仮想ファイルを生成し、生成された１以上の前記仮想ファイルのそれぞれを、予め構成されている仮想ディレクトリ構造に含まれる１以上の仮想ディレクトリのうちの所定の１つに配置させ、
   前記生成手段は、１以上の前記仮想ファイルのそれぞれを示すシンボル、および、１以上の前記仮想ディレクトリのそれぞれを示すシンボルが、前記仮想ディレクトリ構造に従って羅列された前記画像を生成する
   ことを特徴とする請求項１に記載の変換装置。
3. 前記特定手段は、１以上の前記仮想ファイルのそれぞれの名称をさらに生成し、
   前記生成手段は、１以上の前記仮想ファイルのそれぞれを示す前記シンボルの近傍に、対応する前記仮想ファイルの生成された前記名称が配置された前記画像を生成する
   ことを特徴とする請求項２に記載の変換装置。
4. ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する変換装置であって、
   前記ボディに第１と第２のデータが多重化されて配置された第１のフォーマットのファイルと、前記ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方が供給された場合、それを他方に変換する変換手段と、
   前記ボディに前記第１のデータがまとめて配置された前記第２のフォーマットの第１のファイルと、前記ボディに前記第２のデータがまとめて配置された前記第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体が装着される装着手段と、
   表示装置に表示された画像に含まれるシンボルを指定するときにユーザによって操作される操作手段と
   を少なくとも備える前記変換装置の変換補助方法において、
   前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルの中から、前記変換手段の処理対象候補として、前記第１のファイルと前記第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せを１組以上特定する特定ステップと
   前記特定ステップの処理により特定された１以上の前記処理対象候補のそれぞれを示すシンボルが羅列された画像を生成する生成ステップと、
   前記生成ステップの処理により生成された前記画像を前記表示装置に表示させることを制御する表示制御ステップと、
   前記ユーザが、前記操作手段を操作して、前記表示制御ステップの制御により前記表示装置に表示された前記画像に含まれる１以上の前記シンボルの中から、前記変換手段の次の処理対象として所望する前記処理対象候補を示す前記シンボルを指定した場合、前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルのうちの、前記ユーザが指定した前記シンボルに対応する前記処理対象候補を読み出し、読み出された前記処理対象候補が前記第１のファイルと前記第２のファイルとの組合せのときには、前記第１のファイルと前記第２のファイルを前記変換手段に供給する読み出しステップと
   を含むことを特徴とする変換補助方法。
5. ヘッダ、ボディ、フッタからなるフォーマットのファイルを変換する情報処理装置であって、
   前記ボディに第１と第２のデータが多重化されて配置された第１のフォーマットのファイルと、前記ボディに第１または第２のデータそれぞれがまとめて配置された第２のフォーマットのファイルとのうちの一方が供給された場合、それを他方に変換する変換手段と、
   前記ボディに前記第１のデータがまとめて配置された前記第２のフォーマットの第１のファイルと、前記ボディに前記第２のデータがまとめて配置された前記第２のフォーマットの第２のファイルとを少なくとも含む２以上のファイルが記録されている記録媒体が装着される装着手段と、
   表示装置に表示された画像に含まれるシンボルを指定するときにユーザによって操作される操作手段と
   を少なくとも備える前記情報処理装置を制御するコンピュータに実行させるプログラムであって、
   前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルの中から、前記変換手段の処理対象候補として、前記第１のファイルと前記第２のファイルとの組合せを少なくとも含む、1以上のファイルの組合せを１組以上特定する特定ステップと
   前記特定ステップの処理により特定された１以上の前記処理対象候補のそれぞれを示すシンボルが羅列された画像を生成する生成ステップと、
   前記生成ステップの処理により生成された前記画像を前記表示装置に表示させることを制御する表示制御ステップと、
   前記ユーザが、前記操作手段を操作して、前記表示制御ステップの制御により前記表示装置に表示された前記画像に含まれる１以上の前記シンボルの中から、前記変換手段の次の処理対象として所望する前記処理対象候補を示す前記シンボルを指定した場合、前記装着手段に装着された前記記録媒体に記録されている２以上の前記ファイルのうちの、前記ユーザが指定した前記シンボルに対応する前記処理対象候補を読み出し、読み出された前記処理対象候補が前記第１のファイルと前記第２のファイルとの組合せのときには、前記第１のファイルと前記第２のファイルを前記変換手段に供給する読み出しステップと
   を含むことを特徴とするプログラム。

Images