JP5245940B2 - オーサリング方法、プログラム、編集データ再生装置 - Google Patents
オーサリング方法、プログラム、編集データ再生装置 Download PDFInfo
- Publication number
- JP5245940B2 JP5245940B2 JP2009060397A JP2009060397A JP5245940B2 JP 5245940 B2 JP5245940 B2 JP 5245940B2 JP 2009060397 A JP2009060397 A JP 2009060397A JP 2009060397 A JP2009060397 A JP 2009060397A JP 5245940 B2 JP5245940 B2 JP 5245940B2
- Authority
- JP
- Japan
- Prior art keywords
- virtual
- data
- file
- clip
- image
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Description
本発明は、例えばブルーレイディスク（Blu-ray Disc（登録商標）：以下「ＢＤ」)における再生専用ディスク（ＢＤ-ＲＯＭ）等の製造において、記録するコンテンツを作成するオーサリングシステムにおけるオーサリング方法、プログラムに関する。さらに編集データ再生装置に関する。
図２５により、ＢＤ−ＲＯＭ等の再生専用光ディスクの製造までの流れを説明する。
まず素材製作として、映像素材の撮影、音声素材の録音、編集等が行われる（Ｓ１）。
この撮影・編集等で得られたデータは、制作するコンテンツの素材データ（映像素材、音声素材、字幕データ等）として格納される（Ｓ２）。
まず素材製作として、映像素材の撮影、音声素材の録音、編集等が行われる（Ｓ１）。
この撮影・編集等で得られたデータは、制作するコンテンツの素材データ（映像素材、音声素材、字幕データ等）として格納される（Ｓ２）。
各種素材データは、オーサリングスタジオに持ち込まれ、ディスクデータ（コンテンツ）制作に供される。
オーサリングスタジオでは、オーサリング処理のためのプログラムをインストールしたパーソナルコンピュータや所要のハードウエアを用いて、各種素材データを利用したコンテンツ制作を行う。
映像素材、音声素材はビデオエンコード、オーディオエンコードの各処理により、それぞれ所定の形式に符号化される。また字幕データ等から、メニューデータ、字幕データ等が作成される（Ｓ３）。次にコンテンツの構成としてのシナリオやメニュー作成が行われる（Ｓ４）。また各種データ編集が行われる（Ｓ５）。
オーサリングスタジオでは、オーサリング処理のためのプログラムをインストールしたパーソナルコンピュータや所要のハードウエアを用いて、各種素材データを利用したコンテンツ制作を行う。
映像素材、音声素材はビデオエンコード、オーディオエンコードの各処理により、それぞれ所定の形式に符号化される。また字幕データ等から、メニューデータ、字幕データ等が作成される（Ｓ３）。次にコンテンツの構成としてのシナリオやメニュー作成が行われる（Ｓ４）。また各種データ編集が行われる（Ｓ５）。
その後、マルチプレクサ処理（Ｓ６）として、コンテンツを構成するストリームデータを形成する。マルチプレクサ処理は、符号化された映像データや音声データ、メニュ−などを多重化するためのものである。この場合、例えばハードディスク内等に格納された画像、音声、字幕などの符号化された素材データをインターリーブし、各種フォーマットファイルと合わせて多重化されたデータを作成する多重化処理が行われる。後述するが、ここではクリップ作成、ＵＤＦイメージ作成等が行われる。
最終的に作成された多重化データは、ディスク製造用のカッティングマスタとして、例えばパーソナルコンピュータ内のハードディスク等に格納される。
そのカッティングマスタは、ディスク製造のために工場に送られることになる（Ｓ７）。
最終的に作成された多重化データは、ディスク製造用のカッティングマスタとして、例えばパーソナルコンピュータ内のハードディスク等に格納される。
そのカッティングマスタは、ディスク製造のために工場に送られることになる（Ｓ７）。
工場では、プリマスタリング（Ｓ８）として、データの暗号化やディスク記録データとしてのエンコード等の各種データ処理を行い、マスタリングデータを作成する。そしてマスタリング（Ｓ９）として、ディスク原盤のカッティングからスタンパ作成までの工程を行う。最後にリプリケーション（Ｓ１０）として、スタンパを用いたディスク基板の制作や、ディスク基板上への所定の層構造形成を行い、完成品として光ディスク（ＢＤ−ＲＯＭ）を得る。
オーサリングスタジオで行われている従来のオーサリング工程（Ｓ３〜Ｓ６）を図２６に示す。これは特にマルチプレクサ処理（Ｓ６）を詳しく示したものである。
ステップＦ１として、上述のように素材データ処理としてのエンコード（Ｓ３）がおこなわれ、またステップＦ２として、オーサリングアプリケーションによるデータ作成が行われる。これは上記Ｓ４，Ｓ５のメニュー作成や編集等となる。
そしてマルチプレクサ処理（Ｓ６）として、ステップＦ３〜Ｆ１０が行われる。
ステップＦ１として、上述のように素材データ処理としてのエンコード（Ｓ３）がおこなわれ、またステップＦ２として、オーサリングアプリケーションによるデータ作成が行われる。これは上記Ｓ４，Ｓ５のメニュー作成や編集等となる。
そしてマルチプレクサ処理（Ｓ６）として、ステップＦ３〜Ｆ１０が行われる。
ステップＦ３としてクリップ作成が行われる。クリップとは、素材データを時分割多重したストリームデータである。図２７にＢＤ−ＲＯＭにおけるＵＤＦ（Unversal Disk Format）イメージのディレクトリ構成例を示すが、ここで「STREAM」ディレクトリにおけるｍ２ｔｓファイルが、ここでいうクリップとなる。
ステップＦ４としてクリップの再生確認が行われる。即ちクリップ段階で映像／音声の再生をソフトウエアプレーヤで行い、クリップの適否、素材選択の適否、メニュー等の適否等が確認される。
クリップの再生確認がＯＫとなったら、次にステップＦ５としてＵＤＦイメージの作成が行われる。ＵＤＦイメージは、クリップに、各種管理情報としてのメタデータ等を付加したものである。
ＵＤＦイメージを作成したら、ステップＦ６でエラーチェックが行われる。この場合ＰＣ上でベリファイヤによる論理チェックなどが行われる。
エラーチェックＯＫであれば、ステップＦ７でＵＤＦイメージの再生確認が行われる。この場合ＵＤＦイメージについて、ハードウエアプレーヤで再生を行い、ＵＤＦイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
クリップの再生確認がＯＫとなったら、次にステップＦ５としてＵＤＦイメージの作成が行われる。ＵＤＦイメージは、クリップに、各種管理情報としてのメタデータ等を付加したものである。
ＵＤＦイメージを作成したら、ステップＦ６でエラーチェックが行われる。この場合ＰＣ上でベリファイヤによる論理チェックなどが行われる。
エラーチェックＯＫであれば、ステップＦ７でＵＤＦイメージの再生確認が行われる。この場合ＵＤＦイメージについて、ハードウエアプレーヤで再生を行い、ＵＤＦイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
ＵＤＦイメージの再生確認がＯＫであれば、ステップＦ８でＢＤ−Ｒ（書込可能型ブルーレイディスク）に対して、ＵＤＦイメージによるコンテンツ書込を行う。実際に生産するＢＤ−ＲＯＭに近い光ディスク状態でのチェックを行うためである。そしてステップＦ９でＢＤ−Ｒの再生を行い、内容を確認する。
その段階でＯＫであれば、ステップＦ１０で、工場に転送するマスターデータとしてのカッティングマスタを作成することになる。
その段階でＯＫであれば、ステップＦ１０で、工場に転送するマスターデータとしてのカッティングマスタを作成することになる。
以上の処理において、ステップＦ４，Ｆ６，Ｆ７，Ｆ９の各段階で内容チェックが行われるが、もしやり直しが必要と判断されたら、その修正を要する状況に応じて、ステップＦ１の素材データ段階、またはステップＦ２のシナリオ、メニュー等の作成または編集段階から、処理をやり直すことになる。
上記のオーサリング、特にマルチプレクサ処理においては、作業の効率化、高速化が求められている。
図２８にクリップ作成、ＵＤＦイメージ作成の作業を模式的に示している。
ここで、Ｌドライブは、作業を行うパーソナルコンピュータが用いるハードディスク等であるとし、ここにＥＳ（Elementary Stream）ファイル群が格納されているとする。ＥＳファイルとは、素材データのファイルである。Ｃドライブは、パーソナルコンピュータ内部のワーク領域とする。
図２８にクリップ作成、ＵＤＦイメージ作成の作業を模式的に示している。
ここで、Ｌドライブは、作業を行うパーソナルコンピュータが用いるハードディスク等であるとし、ここにＥＳ（Elementary Stream）ファイル群が格納されているとする。ＥＳファイルとは、素材データのファイルである。Ｃドライブは、パーソナルコンピュータ内部のワーク領域とする。
上述のように、クリップ作成の際には、符号化された素材データ（ＥＳファイルのデータ）の多重化処理が行われる。
クリップ１００は、例えばＭＰＥＧ２方式のストリームデータとされるが、管理情報としての４バイトのＴＰエクストラヘッダ（TP extra header）１０２や４バイトのパケットインフォメーション（Packet information）１０３とともに、１８４バイトのアダプテーションフィールド／データフィールド（adaptation field / data field）１０１が含まれる。データフィールドには、ＥＳファイルの素材データがＰＥＳ（Packetized Elementary Stream）パケットで転送され、コピーされる。
これらのコピーされる素材データは、かなり大容量となることが多く、マルチプレクサの処理時間は、データコピーに多く費やされて膨大なものとなる。
またＵＤＦイメージ２００は、クリップ１００にメタデータ２０１等を付加したものとして生成されるが、大容量のクリップ１００がコピーされるため、ＵＤＦイメージ２００の生成の際も膨大な時間を要する。
クリップ１００は、例えばＭＰＥＧ２方式のストリームデータとされるが、管理情報としての４バイトのＴＰエクストラヘッダ（TP extra header）１０２や４バイトのパケットインフォメーション（Packet information）１０３とともに、１８４バイトのアダプテーションフィールド／データフィールド（adaptation field / data field）１０１が含まれる。データフィールドには、ＥＳファイルの素材データがＰＥＳ（Packetized Elementary Stream）パケットで転送され、コピーされる。
これらのコピーされる素材データは、かなり大容量となることが多く、マルチプレクサの処理時間は、データコピーに多く費やされて膨大なものとなる。
またＵＤＦイメージ２００は、クリップ１００にメタデータ２０１等を付加したものとして生成されるが、大容量のクリップ１００がコピーされるため、ＵＤＦイメージ２００の生成の際も膨大な時間を要する。
さらに、上記のようにクリップ１００やＵＤＦイメージ２００の再生確認が行われて、再生結果に不具合などがあれば、再度マルチプレクサの工程前まで戻ることも多々ある。すると、上記の素材データのコピーを何度もやり直す状況が発生することになる。
このコピー処理時間は、データ量に比例するが、１つの工程に数時間を要することもあった。
このコピー処理時間は、データ量に比例するが、１つの工程に数時間を要することもあった。
一方、作業の高速化の手法としては、処理の分散化なども考慮された。例えばコンテンツの部分毎に並行してマルチプレクサ処理を行うなどである。しかしその場合、データの分割、あるいは接続などが必要となり、分割点や接続点に、これまでの処理との互換性が取れない場合が想定された。
このようなことからオーサリング作業の長時間化が問題となっており、作業の効率化が求められている。
このようなことからオーサリング作業の長時間化が問題となっており、作業の効率化が求められている。
なお、上記した特許文献１には、シミュレーションのターンアラウンドを短縮する技術が開示されているが、ディスク等に記録する実データの作成に関しての効率化は解決されていない。
本発明のオーサリング方法は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程とを有し、さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込／再生工程を有し、さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有し、上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材ＩＤを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材ＩＤについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにする。
本発明のプログラムは、このようなオーサリング方法を情報処理装置において実行させるプログラムである。
本発明の編集データ再生装置は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成手段と、編集結果としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成手段と、上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生手段とを有し、さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込／再生工程を有し、さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有し、上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材ＩＤを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材ＩＤについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにする。
本発明のプログラムは、このようなオーサリング方法を情報処理装置において実行させるプログラムである。
本発明の編集データ再生装置は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成手段と、編集結果としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成手段と、上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生手段とを有し、さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込／再生工程を有し、さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有し、上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材ＩＤを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材ＩＤについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにする。
このような本発明では、クリップやＵＤＦイメージ等として、大容量の素材データを加工したファイルを生成せず、仮想的にマルチプレクサを行うものである。即ち素材データのコピー処理を不要とし、従来コピー処理のために長時間を要していた作業時間を著しく短縮する。
また仮想クリップや仮想イメージの再生は、素材参照テーブルや仮想クリップ参照テーブルを利用し、テーブルで示される素材を直接リードしていくことで実現する。
また仮想クリップや仮想イメージの再生は、素材参照テーブルや仮想クリップ参照テーブルを利用し、テーブルで示される素材を直接リードしていくことで実現する。
本発明により、マルチプレクサの処理が従来に比して著しく時短化できる。例えば実際の使用においては、同等のクリップファイルやＵＤＦイメージファイルを生成する場合において、従来比で約７倍高速とすることができた。このようなマルチプレクス処理の高速化により、オーサリング作業は格段に効率化される。
また、仮想クリップ生成時には、大容量のＥＳファイルデータのコピーが行われないため、作成時間が非常に短縮される。そして、仮想クリップ１０の再生には、ＥＳ参照テーブル１１を用いて実際のＥＳファイルデータを特定し、ＥＳファイル群の中からリードしてくることによって行うことができる。
また、仮想クリップ生成時には、大容量のＥＳファイルデータのコピーが行われないため、作成時間が非常に短縮される。そして、仮想クリップ１０の再生には、ＥＳ参照テーブル１１を用いて実際のＥＳファイルデータを特定し、ＥＳファイル群の中からリードしてくることによって行うことができる。
以下、本発明の実施の形態を次の順序で説明する。
［１．システム動作概要］
［２．オーサリング工程］
［３．仮想クリップ］
［４．仮想ＵＤＦイメージ］
［５．カッティングマスタファイル］
［６．仮想クリップ・仮想ＵＤＦイメージの再生］
［７．編集データ再生装置］
［８．ＢＤ−Ｒ書込］
［９．実施の形態の効果及び変形例］
［１．システム動作概要］
［２．オーサリング工程］
［３．仮想クリップ］
［４．仮想ＵＤＦイメージ］
［５．カッティングマスタファイル］
［６．仮想クリップ・仮想ＵＤＦイメージの再生］
［７．編集データ再生装置］
［８．ＢＤ−Ｒ書込］
［９．実施の形態の効果及び変形例］
［１．システム動作概要］
実施の形態において、ディスク製造の全体の流れは、図２５で説明したものと同様である。本実施の形態では、特にクリップの仮想化、ＵＤＦイメージの仮想化を行うことで、マルチプレクサ処理（図２５のＳ６）の効率化を実現する。
実施の形態において、ディスク製造の全体の流れは、図２５で説明したものと同様である。本実施の形態では、特にクリップの仮想化、ＵＤＦイメージの仮想化を行うことで、マルチプレクサ処理（図２５のＳ６）の効率化を実現する。
図１にマルチプレクサ処理の際に生成する仮想クリップ、仮想ＵＤＦイメージを模式的に示す。
Ｌドライブは、作業を行うパーソナルコンピュータが用いるハードディスク等であるとし、ここにＥＳ（Elementary Stream）ファイル群が格納されている。
マルチプレクサ処理の際には、まず仮想クリップ１０の作成を行う。
従来は図２８で述べたように、クリップ１００が、実際の素材データがコピーされて生成されるが、本例の場合、素材データを含まない仮想クリップ１０が生成される。
Ｌドライブは、作業を行うパーソナルコンピュータが用いるハードディスク等であるとし、ここにＥＳ（Elementary Stream）ファイル群が格納されている。
マルチプレクサ処理の際には、まず仮想クリップ１０の作成を行う。
従来は図２８で述べたように、クリップ１００が、実際の素材データがコピーされて生成されるが、本例の場合、素材データを含まない仮想クリップ１０が生成される。
仮想クリップ１０は、管理情報としての４バイトのＴＰエクストラヘッダ（TP extra header）１２や４バイトのパケットインフォメーション（Packet information）１３とともに、ＥＳ参照テーブル１１を有するファイル構造として形成される。
本来クリップは、ＭＰＥＧ２方式のストリームデータとしてＰＥＳパケット単位の実データの集合であるが、ここでは、各ＰＥＳパケットは、そのＴＰエクストラヘッダ１２とパケットインフォメーション１３のみで表現されているということができる。
そしてＴＰエクストラヘッダ１２に対応する実素材データのポインタ情報が、ＥＳ参照テーブル１１に格納されている。
つまり、仮想クリップ生成処理では、ＥＳファイルの実データコピーは行われない。
また仮想クリップ１０の再生には、ＥＳ参照テーブル１１を用いて実際の素材データを特定し、ＥＳファイル群の中からリードしてくることによって行う。
本来クリップは、ＭＰＥＧ２方式のストリームデータとしてＰＥＳパケット単位の実データの集合であるが、ここでは、各ＰＥＳパケットは、そのＴＰエクストラヘッダ１２とパケットインフォメーション１３のみで表現されているということができる。
そしてＴＰエクストラヘッダ１２に対応する実素材データのポインタ情報が、ＥＳ参照テーブル１１に格納されている。
つまり、仮想クリップ生成処理では、ＥＳファイルの実データコピーは行われない。
また仮想クリップ１０の再生には、ＥＳ参照テーブル１１を用いて実際の素材データを特定し、ＥＳファイル群の中からリードしてくることによって行う。
仮想ＵＤＦイメージ２０は、管理情報としてのメタデータ２２と、仮想クリップ参照テーブル２１を有する。
この仮想ＵＤＦイメージ２０も、素材データとしての実データはコピーされない。仮想クリップ参照テーブル２１によって、仮想的に実データが表現される。
仮想ＵＤＦイメージ２０の再生は、仮想クリップ参照テーブル２１から、仮想クリップ１０のＥＳ参照テーブル１１を参照し、そのＥＳ参照テーブル１１から実際のＥＳファイルを指定して、読み出すことにより実現する。
この仮想ＵＤＦイメージ２０も、素材データとしての実データはコピーされない。仮想クリップ参照テーブル２１によって、仮想的に実データが表現される。
仮想ＵＤＦイメージ２０の再生は、仮想クリップ参照テーブル２１から、仮想クリップ１０のＥＳ参照テーブル１１を参照し、そのＥＳ参照テーブル１１から実際のＥＳファイルを指定して、読み出すことにより実現する。
このように本例では、大容量の素材データを加工したファイルを生成せず、エンコードした素材データ（ＥＳファイル）を直接リードしながら仮想的にマルチプレクサを行い、ハードディスク（Ｌドライブ）などの媒体のＩ／Ｏ部分を極力減らした仮想処理を実行する。
［２．オーサリング工程］
図２５のＳ３〜Ｓ６として示したオーサリングスタジオで行われる工程として、実施の形態のオーサリング工程を図２に示す。
図２のステップＦ１０１として、素材データ処理としてのエンコードがおこなわれ、映像、音声等の素材データが符号化される。符号化された素材データは、ＥＳファイルとして図１のＬドライブに格納された状態となる。
図２５のＳ３〜Ｓ６として示したオーサリングスタジオで行われる工程として、実施の形態のオーサリング工程を図２に示す。
図２のステップＦ１０１として、素材データ処理としてのエンコードがおこなわれ、映像、音声等の素材データが符号化される。符号化された素材データは、ＥＳファイルとして図１のＬドライブに格納された状態となる。
ステップＦ１０２として、オーサリングアプリケーションによるデータ作成が行われる。これは図２５のＳ４，Ｓ５のメニュー作成や編集等となる。
そしてマルチプレクサ処理（図２５のＳ６）として、ステップＦ１０３〜Ｆ１１０が行われる。
そしてマルチプレクサ処理（図２５のＳ６）として、ステップＦ１０３〜Ｆ１１０が行われる。
マルチプレクサ処理は、オーサリング作業に用いるパーソナルコンピュータにおいて起動されるマルチプレクサモジュールとしてのプログラムに基づいて行われる。
なお、従来のマルチプレクサモジュールは、オーサリングスタジオに配布され実際のディスクタイトル製作のために運用されてきている。そのため、たとえ処理速度が高速化したとしても、互換性がないものや、置き換えによって信頼性が落ちるものは、許容されるものでない。そのため、本例で導入する新たなマルチプレクサモジュールは、従来のマルチプレクサモジュールをコールしていたものと同じオーサリングアプリケーションや再生装置、ベリファイヤ（Verifier）が利用できるシステム設計を行うことが適切である。
なお、従来のマルチプレクサモジュールは、オーサリングスタジオに配布され実際のディスクタイトル製作のために運用されてきている。そのため、たとえ処理速度が高速化したとしても、互換性がないものや、置き換えによって信頼性が落ちるものは、許容されるものでない。そのため、本例で導入する新たなマルチプレクサモジュールは、従来のマルチプレクサモジュールをコールしていたものと同じオーサリングアプリケーションや再生装置、ベリファイヤ（Verifier）が利用できるシステム設計を行うことが適切である。
本例におけるマルチプレクサモジュールは、図３（ａ）に示すように、大きくわけて仮想クリップ生成部１，メタデータ生成部２，仮想ＵＤＦイメージ／カッティングマスタ生成部３の３つのパートから構成される。
仮想クリップ生成部１は、ＭＰＥＧ２トランスポートストリームフォーマットのクリップファイル生成を仮想的に行う。
メタデータ生成部２は、ディスクに記録するメタデータ生成を行う。
仮想ＵＤＦイメージ／カッティングマスタ生成部３は、仮想的にＵＤＦイメージを作成し、またカッティングマスタを作成する。これらは、ＤＬＬ（ダイナミックリンクライブラリ）として、オーサリングスタジオで使用される、一般にオーサリングアプリケーションと呼ばれるソフトウェアから動的にリンクして実行される。
従来のマルチプレクサモジュールからの置き換えは、このＤＬＬの入れ替えのみなので、使用中のシステムへの本実施の形態の導入は容易である。
仮想クリップ生成部１は、ＭＰＥＧ２トランスポートストリームフォーマットのクリップファイル生成を仮想的に行う。
メタデータ生成部２は、ディスクに記録するメタデータ生成を行う。
仮想ＵＤＦイメージ／カッティングマスタ生成部３は、仮想的にＵＤＦイメージを作成し、またカッティングマスタを作成する。これらは、ＤＬＬ（ダイナミックリンクライブラリ）として、オーサリングスタジオで使用される、一般にオーサリングアプリケーションと呼ばれるソフトウェアから動的にリンクして実行される。
従来のマルチプレクサモジュールからの置き換えは、このＤＬＬの入れ替えのみなので、使用中のシステムへの本実施の形態の導入は容易である。
なお、本例のマルチプレクサモジュールとしてのプログラムは、パーソナルコンピュータ等の機器に内蔵されている記録媒体としてのＨＤＤ、ＲＯＭ、フラッシュメモリ等に予め記録しておくことができる。
あるいはまた、フレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)、ＭＯ(Magnet optical)ディスク、ＤＶＤ、ブルーレイディスク、磁気ディスク、半導体メモリ、メモリカードなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、プログラムは、リムーバブル記録媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ(Local Area Network)、インターネットなどのネットワークを介してダウンロードすることもできる。
あるいはまた、フレキシブルディスク、ＣＤ−ＲＯＭ(Compact Disc Read Only Memory)、ＭＯ(Magnet optical)ディスク、ＤＶＤ、ブルーレイディスク、磁気ディスク、半導体メモリ、メモリカードなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）しておくことができる。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供することができる。
また、プログラムは、リムーバブル記録媒体からパーソナルコンピュータ等にインストールする他、ダウンロードサイトから、ＬＡＮ(Local Area Network)、インターネットなどのネットワークを介してダウンロードすることもできる。
図２のステップＦ１０３では、仮想クリップ生成部１により仮想クリップ１０の作成が行われる。本来クリップとは、素材データを時分割多重したストリームデータである。例えば図３（ｂ）に示すように、エレメンタリストリームとしての素材データ（映像、音声、ＩＧ（Interactive Graphics）、ＰＧ（Presentation Graphics）、テキストサブタイトル）等をマルチプレクスしてトランスポートストリーム（ＴＳ）としたものである。
本例の場合、実際の素材データはコピーせずに、図１に示したように、ＴＰエクストラヘッダ１２、パケットインフォメーション１３、ＥＳ参照テーブル１１を有するファイル構造として仮想クリップ１０を生成する。
本例の場合、実際の素材データはコピーせずに、図１に示したように、ＴＰエクストラヘッダ１２、パケットインフォメーション１３、ＥＳ参照テーブル１１を有するファイル構造として仮想クリップ１０を生成する。
ステップＦ１０４として仮想クリップ１０を用いた再生確認が行われる。即ちクリップ段階で映像／音声の再生をソフトウエアプレーヤで行い、クリップの適否、素材選択の適否、メニュー等の適否等が確認される。
仮想クリップ１０によるクリップ内容の再生確認がＯＫとなったら、次にステップＦ１０５として、仮想ＵＤＦイメージ／カッティングマスタ生成部３により、仮想ＵＤＦイメージ２０の作成が行われる。本来のＵＤＦイメージは、クリップに、各種管理情報としてのメタデータ等を付加したものであるが、これを仮想的に生成する。
メタデータはメタデータ生成部２が作成する。そして仮想ＵＤＦイメージ／カッティングマスタ生成部３の処理により、仮想ＵＤＦイメージ２０が作成される。
仮想ＵＤＦイメージ２０は、図１に示すようにメタデータ２２と、仮想クリップ参照テーブル２１を含むものとされる。
なお、カッティングマスタファイル（ＣＭＦ）の一部データの作成も同時に行われる。例えばコントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどが作成される。
メタデータはメタデータ生成部２が作成する。そして仮想ＵＤＦイメージ／カッティングマスタ生成部３の処理により、仮想ＵＤＦイメージ２０が作成される。
仮想ＵＤＦイメージ２０は、図１に示すようにメタデータ２２と、仮想クリップ参照テーブル２１を含むものとされる。
なお、カッティングマスタファイル（ＣＭＦ）の一部データの作成も同時に行われる。例えばコントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどが作成される。
仮想ＵＤＦイメージ２０を作成したら、ステップＦ１０６でエラーチェックが行われる。この場合ＰＣ上でベリファイヤによる論理チェックなどが行われる。
エラーチェックＯＫであれば、ステップＦ１０７で仮想ＵＤＦイメージ２０の再生確認が行われる。即ち仮想ＵＤＦイメージ２０における仮想クリップ参照テーブル２１、及びＥＳ参照テーブル１１に基づいて再生を行い、ＵＤＦイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
エラーチェックＯＫであれば、ステップＦ１０７で仮想ＵＤＦイメージ２０の再生確認が行われる。即ち仮想ＵＤＦイメージ２０における仮想クリップ参照テーブル２１、及びＥＳ参照テーブル１１に基づいて再生を行い、ＵＤＦイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
仮想ＵＤＦイメージ２０の再生確認がＯＫであれば、ステップＦ１０８でＢＤ−Ｒ（書込可能型ブルーレイディスク）に対して、仮想ＵＤＦイメージ２０によるコンテンツ書込を行う。実際に生産するＢＤ−ＲＯＭに近い光ディスク状態でのチェックを行うためである。この場合、仮想クリップ参照テーブル２１、及びＥＳ参照テーブル１１に基づいて書込データとしてのストリームが形成され、ＢＤ−Ｒへの書込が行われることになる。
そしてステップＦ１０９でＢＤ−Ｒの再生を行い、内容を確認する。
そしてステップＦ１０９でＢＤ−Ｒの再生を行い、内容を確認する。
その段階でＯＫであれば、ステップＦ１１０で、仮想ＵＤＦイメージ／カッティングマスタ生成部３により、工場に転送するマスターデータとしてのカッティングマスタが作成される。即ち仮想ＵＤＦイメージから実体化されたＵＤＦイメージを作成し、さらに上記のコントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどを付加して、カッティングマスタファイルが作成される。
以上の処理においては、ステップＦ１０４，Ｆ１０６，Ｆ１０７，Ｆ１０９の各段階で内容チェックが行われるが、もしやり直しが必要と判断されたら内容修正を行う。即ちその修正を要する状況に応じて、ステップＦ１０１の素材データ段階、またはステップＦ１０２のシナリオ、メニュー等の作成または編集段階から、処理をやり直すことになる。
以下では、この図２の処理で作成される仮想クリップ１０、仮想ＵＤＦイメージ２０の内容、さらにはこれらの再生動作、ＢＤ−Ｒへの書込について説明する。
以下では、この図２の処理で作成される仮想クリップ１０、仮想ＵＤＦイメージ２０の内容、さらにはこれらの再生動作、ＢＤ−Ｒへの書込について説明する。
［３．仮想クリップ］
先に述べたように従来は、クリップとして素材データの実体をコピーしたクリップを生成していたところ、本例では素材データの実体を含まない仮想クリップ１０を生成するものである。従来のクリップファイルと比較しながら、本例の仮想クリップ１０について説明する。
先に述べたように従来は、クリップとして素材データの実体をコピーしたクリップを生成していたところ、本例では素材データの実体を含まない仮想クリップ１０を生成するものである。従来のクリップファイルと比較しながら、本例の仮想クリップ１０について説明する。
まず図４は、図１のＬドライブにＥＳファイルとして格納される素材データについてのディレクトリ構成を示している。
図のように、「ESData」ディレクトリ下に「VIDEO」「AUDIO」ディレクトリが配置される。そして「VIDEO」下に「MPEG2」「AVC」ディレクトリが配置され、「MPEG2」下の「MOVIE1」「MOVIE2」等のディレクトリ下にＥＳファイルとしての「sample1.ves」等が配置される。また「AVC」下にもＥＳファイルとしての「sample2.ves」等が配置される。
従来では、「sample1.ves」「sample2.ves」等のＥＳファイルがクリップ作成時にコピーされていたものである。
図のように、「ESData」ディレクトリ下に「VIDEO」「AUDIO」ディレクトリが配置される。そして「VIDEO」下に「MPEG2」「AVC」ディレクトリが配置され、「MPEG2」下の「MOVIE1」「MOVIE2」等のディレクトリ下にＥＳファイルとしての「sample1.ves」等が配置される。また「AVC」下にもＥＳファイルとしての「sample2.ves」等が配置される。
従来では、「sample1.ves」「sample2.ves」等のＥＳファイルがクリップ作成時にコピーされていたものである。
図５（ａ）に、従来のクリップのディレクトリ構造を示してる。図のように例えば「SAMPLE」→「BDMV」→「STREAM」のディレクトリ構成下に、「00001.m2ts」「00002.m2ts」「00003.m2ts」等のクリップファイルが配される。この「00001.m2ts」等のクリップファイルが、素材データがマルチプレクスされてコピーされたストリームデータであり、これらはデータサイズが大きなものとなっていた。
本例の場合、従来最も容量を必要としていたクリップファイル(m2tsファイル)を仮想化する。
図５（ｂ）が仮想化した場合のディレクトリ構造の例である。例えば「SAMPLE」→「BDMV」→「STREAM」のディレクトリ構成下に、「00001.m2ts」「00002.m2ts」「00003.m2ts」等のディレクトリを配置する。
即ち従来のファイルが図５（ａ）のように単一ファイル「00001.m2ts」等であったところ、本例の仮想ファイルシステムでは「00001.m2ts」等をディレクトリとして配置する。そして「00001.m2ts」等のディレクトリ下に、「Packetbase」「Packetinfo」「Seek.lst」「ES.List」としての各ファイルを配置する。
この４つのファイル「Packetbase」「Packetinfo」「Seek.lst」「ES.List」が、図１に示したＥＳ参照テーブル１１を構成するものとなる。
図５（ｂ）が仮想化した場合のディレクトリ構造の例である。例えば「SAMPLE」→「BDMV」→「STREAM」のディレクトリ構成下に、「00001.m2ts」「00002.m2ts」「00003.m2ts」等のディレクトリを配置する。
即ち従来のファイルが図５（ａ）のように単一ファイル「00001.m2ts」等であったところ、本例の仮想ファイルシステムでは「00001.m2ts」等をディレクトリとして配置する。そして「00001.m2ts」等のディレクトリ下に、「Packetbase」「Packetinfo」「Seek.lst」「ES.List」としての各ファイルを配置する。
この４つのファイル「Packetbase」「Packetinfo」「Seek.lst」「ES.List」が、図１に示したＥＳ参照テーブル１１を構成するものとなる。
各ファイルを説明する。
・Packetbase （パケットベース）
パケットベースは、ＴＳパケット（TSPacket）のヘッダー／システムパケットの集まりである。
図６（ｂ）にパケットベースを示すが、その説明のため、先に図６（ａ）で仮想化されたクリップを実体のあるクリップにデコードした状態を説明する。
クリップの実体は、１９２バイトのＴＳパケット（図６（ａ）の一行）から構成される。
ここでは１行目、２行目のＴＳパケットには、TP_extra_header（４バイト）、PacketInformation（４バイト）、 adaptation_field（１８４バイト）が含まれるものとし、３行目以降のＴＳパケットには、TP_extra_header（４バイト）、PacketInformation（４バイト）、 data_field（１８４バイト）が含まれるものとしている。データフィールド（data_field）とは、実際にＥＳファイルの一部（素材データの一部）がコピーされているものである。
これは図２８で模式的に示した従来のクリップの構造に相当する。
・Packetbase （パケットベース）
パケットベースは、ＴＳパケット（TSPacket）のヘッダー／システムパケットの集まりである。
図６（ｂ）にパケットベースを示すが、その説明のため、先に図６（ａ）で仮想化されたクリップを実体のあるクリップにデコードした状態を説明する。
クリップの実体は、１９２バイトのＴＳパケット（図６（ａ）の一行）から構成される。
ここでは１行目、２行目のＴＳパケットには、TP_extra_header（４バイト）、PacketInformation（４バイト）、 adaptation_field（１８４バイト）が含まれるものとし、３行目以降のＴＳパケットには、TP_extra_header（４バイト）、PacketInformation（４バイト）、 data_field（１８４バイト）が含まれるものとしている。データフィールド（data_field）とは、実際にＥＳファイルの一部（素材データの一部）がコピーされているものである。
これは図２８で模式的に示した従来のクリップの構造に相当する。
本例の仮想クリップ１０を構成するパケットベースは、図６（ｂ）のようになり、図６（ａ）におけるdata_fieldが無い構成となる。つまりパケットベースは、素材データの実体がない状態でクリップ実体の管理情報を集めたものと言える。
具体的には、図６（ｂ）の１行目、２行目のＴＳパケットには、ＴＰエクストラヘッダ（TP_extra_header：４バイト）、パケットインフォメーション（PacketInformation：４バイト）、アダプテーションフィールド（adaptation_field：１８４バイト）が含まれる。
図６（ｂ）の３行目以降は、それぞれＴＰエクストラヘッダ（TP_extra_header：４バイト）、パケットインフォメーション（PacketInformation：４バイト）の８バイトの構造となる。パケットインフォメーションには、実際のＥＳファイルの一部である実体データのパケットを示すＰＩＤが含まれている。
パケットベースを構成するそれぞれのＴＳパケットのサイズは 次のPacketinfoファイルに示されることになる。
具体的には、図６（ｂ）の１行目、２行目のＴＳパケットには、ＴＰエクストラヘッダ（TP_extra_header：４バイト）、パケットインフォメーション（PacketInformation：４バイト）、アダプテーションフィールド（adaptation_field：１８４バイト）が含まれる。
図６（ｂ）の３行目以降は、それぞれＴＰエクストラヘッダ（TP_extra_header：４バイト）、パケットインフォメーション（PacketInformation：４バイト）の８バイトの構造となる。パケットインフォメーションには、実際のＥＳファイルの一部である実体データのパケットを示すＰＩＤが含まれている。
パケットベースを構成するそれぞれのＴＳパケットのサイズは 次のPacketinfoファイルに示されることになる。
・Packetinfo（パケットインフォファイル）
図６（ｃ）にパケットインフォファイル（Packetinfo）を示す。パケットインフォファイルは、先頭から１バイトずつがパケットベースファイル中のＴＳパケットのサイズを示すものとされる。
実データとしてのＴＳパケットは、図６（ａ）のように１９２バイトであるが、図６（ｂ）のようにパケットベースにはデータフィールドが存在しないＴＳパケットもある。ＴＳパケットの最小サイズは、図６（ｂ）の３行目のようにＴＰエクストラヘッダとパケットインフォメーションの８バイトである。
このためパケットインフォファイルの各バイトは、８〜１９２バイトの範囲で、パケットベースファイル中の各ＴＳパケットのサイズを示す。
図６（ｃ）にパケットインフォファイル（Packetinfo）を示す。パケットインフォファイルは、先頭から１バイトずつがパケットベースファイル中のＴＳパケットのサイズを示すものとされる。
実データとしてのＴＳパケットは、図６（ａ）のように１９２バイトであるが、図６（ｂ）のようにパケットベースにはデータフィールドが存在しないＴＳパケットもある。ＴＳパケットの最小サイズは、図６（ｂ）の３行目のようにＴＰエクストラヘッダとパケットインフォメーションの８バイトである。
このためパケットインフォファイルの各バイトは、８〜１９２バイトの範囲で、パケットベースファイル中の各ＴＳパケットのサイズを示す。
・ES.list（ＥＳリストファイル）
ＥＳリストは、ＴＳパケットのパケットベース以外のデータ部分の参照元のファイル名とＰＩＤの関係を示すテキストファイルが記述される。
フォーマットは、
PID,ファイルパス[改行]
PID,ファイルパス[改行]
・
・
とされる。
ＥＳリストは、ＴＳパケットのパケットベース以外のデータ部分の参照元のファイル名とＰＩＤの関係を示すテキストファイルが記述される。
フォーマットは、
PID,ファイルパス[改行]
PID,ファイルパス[改行]
・
・
とされる。
例えば図６（ｄ）に例を示す。
「PID3,L:\ESData\VIDEO\MOVIE\MPEG-2\sample1.ves」
とは、「ＰＩＤ３」というＰＩＤに対応するデータとしての「sample1.ves」について、図４のディレクトリ構造での「sample1.ves」ファイルに至るディレクトリパスが記述されていることになる。
同様に「PID5,L:\ESData\VIDEO\AVC\sample2.ves」は、「ＰＩＤ５」というＰＩＤに対応するデータとしての「sample2.ves」について、図４のディレクトリ構造での「sample2.ves」ファイルに至るパスが記述されている。
「PID3,L:\ESData\VIDEO\MOVIE\MPEG-2\sample1.ves」
とは、「ＰＩＤ３」というＰＩＤに対応するデータとしての「sample1.ves」について、図４のディレクトリ構造での「sample1.ves」ファイルに至るディレクトリパスが記述されていることになる。
同様に「PID5,L:\ESData\VIDEO\AVC\sample2.ves」は、「ＰＩＤ５」というＰＩＤに対応するデータとしての「sample2.ves」について、図４のディレクトリ構造での「sample2.ves」ファイルに至るパスが記述されている。
つまり、パケットベース内の或るＴＳパケットにおけるパケットインフォメーションに示されているＰＩＤに対応して、例えば図６（ａ）（ｅ）の関係のように、本来データフィールドにコピーされるべきＥＳファイルが示される。つまり仮想クリップ再生時に読み出されるべき、ＥＳファイルが示されることになる。
・Seek.lst（シークリストファイル）
シークリストファイルは、シーク用の情報を示すファイルである。
上記の他の３つのファイルでもデコードは可能であるが、シーク情報を追加することによって高速シークに対応できる。
実際に、仮想クリップ１０の映像などを再生するときには、このシーク情報がないと再生が間に合わない場合も生ずる。
シークリストファイルは、シーク用の情報を示すファイルである。
上記の他の３つのファイルでもデコードは可能であるが、シーク情報を追加することによって高速シークに対応できる。
実際に、仮想クリップ１０の映像などを再生するときには、このシーク情報がないと再生が間に合わない場合も生ずる。
シークリストファイルには、ＰＩＤごとの対応のフォーマットで例えば、１００ＳＰＮ（Source Packet Number）として１９２００バイトごとのポジション情報が記述されている。
例えば図７に示すように、先頭に「version」として、この構成（フォーマット）のバージョン番号（例えば「0x00000001」）が示される。次に、「SPN interval」としてインターバル値が示される。ここで「0x0064」＝１００であり、１００ＳＰＮ間隔であることが示されている。また「PID Count」としてＰＩＤ（素材に割り振られる個体番号）の個数が示される。以降は、１００ＳＰＮ毎のリストが続く。
例えば図７に示すように、先頭に「version」として、この構成（フォーマット）のバージョン番号（例えば「0x00000001」）が示される。次に、「SPN interval」としてインターバル値が示される。ここで「0x0064」＝１００であり、１００ＳＰＮ間隔であることが示されている。また「PID Count」としてＰＩＤ（素材に割り振られる個体番号）の個数が示される。以降は、１００ＳＰＮ毎のリストが続く。
リスト内では、ＴＳパケットのヘッダファイル(パケットベース)のポジションが示される。例えば図では「０Ａ１８」としているが、これによってパケットベースの位置が示される。
また、ＰＩＤに対応するＥＳファイルのポジションが示される。例えば図のように「００Ａ５」として、ＰＩＤ＝１０１１とされた素材ファイル内の位置が示される。
また、ＰＩＤに対応するＥＳファイルのポジションが示される。例えば図のように「００Ａ５」として、ＰＩＤ＝１０１１とされた素材ファイル内の位置が示される。
シークの例を説明する。
仮に１９２００ｂｙｔｅからデータを読み出したい場合、シークリストファイルの２つめのリストを読み込む。そしてパケットベースの位置「０Ａ１８」に基づいてパケットベースファイルを参照する。
またＰＩＤに対応するＥＳファイルのポジションを読み込む。そして例えば「００Ａ５」として、素材ファイル内の位置を確認し、素材ファイル（ＥＳファイル）を読み出す。
仮に１９２００ｂｙｔｅからデータを読み出したい場合、シークリストファイルの２つめのリストを読み込む。そしてパケットベースの位置「０Ａ１８」に基づいてパケットベースファイルを参照する。
またＰＩＤに対応するＥＳファイルのポジションを読み込む。そして例えば「００Ａ５」として、素材ファイル内の位置を確認し、素材ファイル（ＥＳファイル）を読み出す。
以上の各ファイルで構成される仮想クリップ１０に基づくデータの読み込みは次の（Ｐ１）〜（Ｐ６）のように行われる。
（Ｐ１）パケットインフォファイルを１バイト読む。（「A」とする）
（Ｐ２）パケットベースファイルから (A)バイト数読み込む。（「B」とする）
（Ｐ３） ((B)[5]&1F)<<8 + (B)[6] (ＴＳパケット中のＰＩＤの位置) （「C」とする）
（Ｐ４）ＥＳリストファイルのＰＩＤと(C)が一致するファイルから、１パケットサイズは１９２バイト固定であることから、 (192-(A))バイト読み込む 。（「D」とする）
（Ｐ５） (B)のバイト列 と (D)のバイト列 を結合したものをファイルとして出力する。
（Ｐ６）上記（Ｐ１）に戻る。これをパケットインフォファイルの終了まで繰り返す。
よって、復元されたファイルのサイズは、
ファイルのサイズ＝（パケットベースファイルサイズ）×１９２
となる。
（Ｐ１）パケットインフォファイルを１バイト読む。（「A」とする）
（Ｐ２）パケットベースファイルから (A)バイト数読み込む。（「B」とする）
（Ｐ３） ((B)[5]&1F)<<8 + (B)[6] (ＴＳパケット中のＰＩＤの位置) （「C」とする）
（Ｐ４）ＥＳリストファイルのＰＩＤと(C)が一致するファイルから、１パケットサイズは１９２バイト固定であることから、 (192-(A))バイト読み込む 。（「D」とする）
（Ｐ５） (B)のバイト列 と (D)のバイト列 を結合したものをファイルとして出力する。
（Ｐ６）上記（Ｐ１）に戻る。これをパケットインフォファイルの終了まで繰り返す。
よって、復元されたファイルのサイズは、
ファイルのサイズ＝（パケットベースファイルサイズ）×１９２
となる。
以上のように仮想クリップ１０は、ＴＰエクストラヘッダ１２、パケットインフォメーション１３とともに、ＥＳ参照テーブル（「Packetbase」「Packetinfo」「Seek.lst」「ES.List」）１１を有するファイル構造として形成される。
この場合、ＭＰＥＧ２方式のストリームデータとしてＰＥＳパケット単位の実データの集合であるクリップが、仮想的に表現されるものとなる。そして、仮想クリップ生成時には大容量のＥＳファイルデータのコピーは行われないため、作成時間は非常に短縮される。また仮想クリップ１０の再生には、ＥＳ参照テーブル１１を用いて実際のＥＳファイルデータを特定し、ＥＳファイル群の中からリードしてくることによって行うことができる。
この場合、ＭＰＥＧ２方式のストリームデータとしてＰＥＳパケット単位の実データの集合であるクリップが、仮想的に表現されるものとなる。そして、仮想クリップ生成時には大容量のＥＳファイルデータのコピーは行われないため、作成時間は非常に短縮される。また仮想クリップ１０の再生には、ＥＳ参照テーブル１１を用いて実際のＥＳファイルデータを特定し、ＥＳファイル群の中からリードしてくることによって行うことができる。
［４．仮想ＵＤＦイメージ］
次に仮想ＵＤＦイメージ２０について説明する。
図３（ａ）に示したマルチプレクサモジュールでは、仮想クリップ生成部１が生成した上述した仮想クリップ１０や、メタデータ生成部２が生成したメタデータ２２に基づいて、仮想ＵＤＦイメージ／カッティングマスタ生成部３がＵＤＦ２．５イメージを生成する。図２のステップＦ１０５の処理である。
一例としてＵＤＦ１．０２ブリッジファイルシステムを図８に示す。ＵＤＦは、管理情報（メタデータ）とファイル実体に分けて考える。
次に仮想ＵＤＦイメージ２０について説明する。
図３（ａ）に示したマルチプレクサモジュールでは、仮想クリップ生成部１が生成した上述した仮想クリップ１０や、メタデータ生成部２が生成したメタデータ２２に基づいて、仮想ＵＤＦイメージ／カッティングマスタ生成部３がＵＤＦ２．５イメージを生成する。図２のステップＦ１０５の処理である。
一例としてＵＤＦ１．０２ブリッジファイルシステムを図８に示す。ＵＤＦは、管理情報（メタデータ）とファイル実体に分けて考える。
まず比較のため、従来のＵＤＦイメージ生成時のディレクトリ構造例を図９に示す。
図９において実体ファイルである「00001.m2ts」「00002.m2ts」「00003.m2ts」までの構造は上記図５（ａ）と同様である。即ちクリップファイル部分を示している。
ＵＤＦイメージ生成によって、「SAMPLEIMAGE」ディレクトリ下に、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」としての各ファイルが配置される。なお「ImageFile0」「ImageFile1」は、ＵＤＦイメージ変換されたストリームデータである。また「CPTBL0」「CPTBL1」はコピープロテクションテーブルとしてのファイルである。また「UCD0」「UCD1」はユーザコントロールデータとしてのファイルである。
図９において実体ファイルである「00001.m2ts」「00002.m2ts」「00003.m2ts」までの構造は上記図５（ａ）と同様である。即ちクリップファイル部分を示している。
ＵＤＦイメージ生成によって、「SAMPLEIMAGE」ディレクトリ下に、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」としての各ファイルが配置される。なお「ImageFile0」「ImageFile1」は、ＵＤＦイメージ変換されたストリームデータである。また「CPTBL0」「CPTBL1」はコピープロテクションテーブルとしてのファイルである。また「UCD0」「UCD1」はユーザコントロールデータとしてのファイルである。
図１０はクリップからＵＤＦイメージへの変換を模式的に示したものである。例えば記録層が２層のブルーレイディスクのオーサリング工程における例として、第１層用のファイル、第２層用のファイルとしてのＵＤＦイメージ生成時を示している。第１層用のファイルとして、「ImageFile0」「CPTBL0」「UCD0」を生成する。また第２層用のファイルとして「ImageFile1」「CPTBL1」「UCD1」を生成する。
これらのファイルが、図９のように「SAMPLEIMAGE」ディレクトリ下に配置される。
これらのファイルが、図９のように「SAMPLEIMAGE」ディレクトリ下に配置される。
ここで図９の構造において、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」としての各ファイルは、実体ファイルである「00001.m2ts」「00002.m2ts」「00003.m2ts」の各ファイルの実データを用いてＵＤＦ変換するものであり、サイズが大きい。
このため、実体としてＵＤＦイメージ生成を行っていた従来は、その処理時間が長時間化していた。
このため、実体としてＵＤＦイメージ生成を行っていた従来は、その処理時間が長時間化していた。
これに対し、本例の仮想ＵＤＦイメージ２０のディレクトリ構造を図１１に示す。
図１１において「00001.m2ts」「00002.m2ts」「00003.m2ts」等は、上述したように実体ファイルではなく仮想クリップ１０を構成するディレクトリである。これらのディレクトリ下に上述した、ＥＳ参照テーブル１１を構成するパケットベースファイル、パケットインフォファイル、シークリストファイル、ＥＳリストファイルが配されるが、これらのデータサイズは小さい。実際の素材データがコピーされているわけではないためである。
図１１において「00001.m2ts」「00002.m2ts」「00003.m2ts」等は、上述したように実体ファイルではなく仮想クリップ１０を構成するディレクトリである。これらのディレクトリ下に上述した、ＥＳ参照テーブル１１を構成するパケットベースファイル、パケットインフォファイル、シークリストファイル、ＥＳリストファイルが配されるが、これらのデータサイズは小さい。実際の素材データがコピーされているわけではないためである。
ＵＤＦイメージ変換により、「SAMPLEIMAGE」ディレクトリ下に、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」が、それぞれ実体ファイルではなくディレクトリとして配置される。
「ImageFile0」「ImageFile1」ディレクトリ下には、「Extent.map」「SourceFileList.map」「UDFHeader.map」「UDFFooter.map」「UDFMetadata.map」「UDFMetadataMirror.map」の各ファイルが配置される。
特に「Extent.map」「SourceFileList.map」が、図１の仮想クリップ参照テーブル２１を構成するものとなる。
また「CPTBL0」「CPTBL1」ディレクトリ下には、「Extent.map」「Header.map」の各ファイルが配置され、また「UCD0」「UCD1」ディレクトリ下には「Extent.map」ファイルが配置される。
「ImageFile0」「ImageFile1」ディレクトリ下には、「Extent.map」「SourceFileList.map」「UDFHeader.map」「UDFFooter.map」「UDFMetadata.map」「UDFMetadataMirror.map」の各ファイルが配置される。
特に「Extent.map」「SourceFileList.map」が、図１の仮想クリップ参照テーブル２１を構成するものとなる。
また「CPTBL0」「CPTBL1」ディレクトリ下には、「Extent.map」「Header.map」の各ファイルが配置され、また「UCD0」「UCD1」ディレクトリ下には「Extent.map」ファイルが配置される。
図１２にクリップからＵＤＦイメージへの変換を模式的に示すが、例えば記録層が２層のブルーレイディスクのオーサリング工程における例として、第１層（レイヤ０）用のファイル、第２層（レイヤ１）用のファイルとしてのＵＤＦイメージ生成を行う場合である。第１層用のファイルとして、「ImageFile0」「CPTBL0」「UCD0」ディレクトリを生成し、また第２層用のファイルとして「ImageFile1」「CPTBL1」「UCD1」ディレクトリを生成する。そして、各ディレクトリ下に上記「Extent.map」等のファイルを配置して図１１の「SAMPLEIMAGE」ディレクトリ下に配置する。このＵＤＦイメージ変換においては、素材データとしての実データのコピーは伴わない。
ここで図１１において「ImageFile0」「ImageFile1」ディレクトリ下の「Extent.map」「SourceFileList.map」等のファイルは、素材データによるストリームデータがコピーされているものではないためデータサイズは小さいものとなる。「CPTBL0」「CPTBL1」「UCD0」「UCD1」の各ディレクトリ下のファイルも同様にデータサイズは小さい。
つまり、大容量データのコピーを伴わずにＵＤＦイメージ生成が行われる。
つまり、大容量データのコピーを伴わずにＵＤＦイメージ生成が行われる。
形成されるファイルについて説明する。
・Extent.map（エクステントマップファイル）
「ImageFile0」「ImageFile1」等のディレクトリ下に配置されるエクステントマップファイルには、ＵＤＦ上に配置されるファイルそれぞれの論理アドレスであるエクステント情報が記録されている。
エクステント情報では、例えば「m2ts」ファイルが物理的にインターリーブして配置される場合などの、それぞれのブロックの論理アドレスとバイトサイズが記録されている。
・Extent.map（エクステントマップファイル）
「ImageFile0」「ImageFile1」等のディレクトリ下に配置されるエクステントマップファイルには、ＵＤＦ上に配置されるファイルそれぞれの論理アドレスであるエクステント情報が記録されている。
エクステント情報では、例えば「m2ts」ファイルが物理的にインターリーブして配置される場合などの、それぞれのブロックの論理アドレスとバイトサイズが記録されている。
エクステントマップファイルは例えば図１３（ａ）のように構成される。即ちエクステントマップファイルのＩＤ、バージョンナンバ、トータルブロック、レイヤオフセットＬＳＮ（Logical Sector Number)が記述される。トータルブロックは、イメージ内のセクタ数である。２層ディスク（デュアルレイヤディスク）でレイヤが別ファイルになる場合はレイヤ毎のセクタ数となる。レイヤオフセットＬＳＮは、第２記録層（レイヤ１）の論理セクタナンバである。
そしてエクステント情報として、エクステントナンバー毎に、開始ＬＳＮ、エクステントサイズ、登録元ファイル、登録元ファイル内オフセットが記述される。
そしてエクステント情報として、エクステントナンバー毎に、開始ＬＳＮ、エクステントサイズ、登録元ファイル、登録元ファイル内オフセットが記述される。
例えば仮想化されているＵＤＦイメージを実体のあるイメージにデコードした状態を図１４に示すが、イメージ化では図示のように１つのファイルを複数のブロックに分割して配置することができる。図では例えば00001.m2tsファイルを「00001.m2ts(1)」「00001.m2ts(2)」「00001.m2ts(3)」に分割している。
このような例の場合、エクステントマップファイルには、次のように各参照ファイルのエクステント（アドレス）情報が入る。
00001.m2ts：A0, A1, A2
00002.m2ts：B0
00003.m2ts：C0
このような例の場合、エクステントマップファイルには、次のように各参照ファイルのエクステント（アドレス）情報が入る。
00001.m2ts：A0, A1, A2
00002.m2ts：B0
00003.m2ts：C0
・SourceFileList.map（ソースファイルリストマップ）
ソースファイルリストマップは、ファイルそれぞれの実体のＰＣ上の絶対ファイルパスが記録されている。
ソースファイルリストマップの例を図１３（ａ）に示す。
ソースファイルリストマップには、図のようにファイルバージョン、リスト数が記述され、「File0」「File1」「File2」・・・として各ファイルの絶対ファイルパス、サイズ、作成日時、更新日時が記述される。
ソースファイルリストマップは、ファイルそれぞれの実体のＰＣ上の絶対ファイルパスが記録されている。
ソースファイルリストマップの例を図１３（ａ）に示す。
ソースファイルリストマップには、図のようにファイルバージョン、リスト数が記述され、「File0」「File1」「File2」・・・として各ファイルの絶対ファイルパス、サイズ、作成日時、更新日時が記述される。
例えば図１４の例においていえば、各ファイルの情報として、次のように記述される。
00001.m2ts：C:\SAMPLE\BDMV\STREAM\00001.m2ts
00002.m2ts：C:\SAMPLE\BDMV\STREAM\00002.m2ts
00003.m2ts：C:\SAMPLE\BDMV\STREAM\00003.m2ts
00001.m2ts：C:\SAMPLE\BDMV\STREAM\00001.m2ts
00002.m2ts：C:\SAMPLE\BDMV\STREAM\00002.m2ts
00003.m2ts：C:\SAMPLE\BDMV\STREAM\00003.m2ts
「ImageFile0」「ImageFile1」等のディレクトリ下に配置される「UDFHeader.map」「UDFFooter.map」「UDFMetadata.map」「UDFMetadataMirror.map」の各ファイルは、ＵＤＦの管理情報用ファイルである。これらのファイルは、図１４の例ではxxxxx.m2ts以外の仮想化されていない情報が入る。
図１５にＵＤＦイメージファイルを示すが、「UDFHeader.map」ファイルは、ＵＤＦイメージ内のボリュームシーケンス（Anchorを含む）のデータである。
「UDFFooter.map」ファイルは、ＵＤＦイメージ内のリザーブボリュームシーケンス（Anchorを含む）のデータである。
「UDFMetadata.map」ファイルは、ＵＤＦイメージ内のメタデータのファイルである。
「UDFMetadataMirror.map」は、ＵＤＦイメージ内のメタデータミラーのファイルである。
図１５にＵＤＦイメージファイルを示すが、「UDFHeader.map」ファイルは、ＵＤＦイメージ内のボリュームシーケンス（Anchorを含む）のデータである。
「UDFFooter.map」ファイルは、ＵＤＦイメージ内のリザーブボリュームシーケンス（Anchorを含む）のデータである。
「UDFMetadata.map」ファイルは、ＵＤＦイメージ内のメタデータのファイルである。
「UDFMetadataMirror.map」は、ＵＤＦイメージ内のメタデータミラーのファイルである。
仮想ＵＤＦイメージ２０の再生時においては、エクステントマップファイルによって各ファイルが指定され、ソースファイルリストマップによって、各ファイルのパスが判別される。各ファイルのパスは、仮想クリップ１０としてのディレクトリ（「00001.m2ts」「00002.m2ts」「00003.m2ts」等）を示すものとなる。
上述したように、これらの仮想クリップ１０としてのディレクトリには、ＥＳ参照テーブル１１を構成するファイルが配置されている。
このため、上述した（Ｐ１）〜（Ｐ６）の手順で仮想クリップ１０に基づく素材データの読み込みが行われる。
即ち、仮想ＵＤＦイメージ２０の再生では、仮想クリップ参照テーブル（「Extent.map」「SourceFileList.map」）２１から、ＥＳ参照テーブル（「Packetbase」「Packetinfo」「Seek.lst」「ES.List」）１１を参照し、ＥＳ参照テーブル１１に基づいて実体としてのＥＳファイルを読み出すことになる。
上述したように、これらの仮想クリップ１０としてのディレクトリには、ＥＳ参照テーブル１１を構成するファイルが配置されている。
このため、上述した（Ｐ１）〜（Ｐ６）の手順で仮想クリップ１０に基づく素材データの読み込みが行われる。
即ち、仮想ＵＤＦイメージ２０の再生では、仮想クリップ参照テーブル（「Extent.map」「SourceFileList.map」）２１から、ＥＳ参照テーブル（「Packetbase」「Packetinfo」「Seek.lst」「ES.List」）１１を参照し、ＥＳ参照テーブル１１に基づいて実体としてのＥＳファイルを読み出すことになる。
なお、「UCD0」「UCD1」ディレクトリ下の「Extent.map」ファイルは図１６（ａ）のようになる。
ここには、ＵＣＤマップＩＤ、バージョンナンバ、ＵＣＤファイルサイズ、レイヤオフセットＬＳＮ、ＵＣＤアイテムサイズが記述される。
そしてＵＣＤのエクステント情報として、エクステントナンバー毎に、開始ＬＳＮ、ブロック数、データが記述される。
ここには、ＵＣＤマップＩＤ、バージョンナンバ、ＵＣＤファイルサイズ、レイヤオフセットＬＳＮ、ＵＣＤアイテムサイズが記述される。
そしてＵＣＤのエクステント情報として、エクステントナンバー毎に、開始ＬＳＮ、ブロック数、データが記述される。
また「CPTBL0」「CPTBL1」ディレクトリ下の「Extent.map」ファイルは図１６（ｂ）のようになる。
ここには、ＣＰＴマップＩＤ、バージョンナンバ、ＣＰＴＢＬファイルサイズ、ヘッダーサイズ、レイヤオフセットＬＳＮが記述される。
そしてＣＰＴのエクステント情報として、エクステントナンバー毎に、開始ＬＳＮ、ブロック数、クリップナンバ等が記述される。
「CPTBL0」「CPTBL1」ディレクトリ下の「Header」ファイルは図１７のように、ジェネラルブロックデータ、ロケーションブロックデータを含む。
ここには、ＣＰＴマップＩＤ、バージョンナンバ、ＣＰＴＢＬファイルサイズ、ヘッダーサイズ、レイヤオフセットＬＳＮが記述される。
そしてＣＰＴのエクステント情報として、エクステントナンバー毎に、開始ＬＳＮ、ブロック数、クリップナンバ等が記述される。
「CPTBL0」「CPTBL1」ディレクトリ下の「Header」ファイルは図１７のように、ジェネラルブロックデータ、ロケーションブロックデータを含む。
以上のように仮想ＵＤＦイメージ２０は、仮想クリップ参照テーブル（「Extent.map」「SourceFileList.map」）２１によって、仮想的に実データが表現されるものとなる。仮想ＵＤＦイメージ作成時にはＥＳファイルの実データはコピーされない。従って仮想ＵＤＦイメージ２０の作成時間は著しく短縮される。
また仮想ＵＤＦイメージ２０の再生は、仮想クリップ参照テーブル２１から、仮想クリップ１０のＥＳ参照テーブル１１を参照し、そのＥＳ参照テーブル１１から実際のＥＳファイルを指定して、読み出すことにより実現できる。
また仮想ＵＤＦイメージ２０の再生は、仮想クリップ参照テーブル２１から、仮想クリップ１０のＥＳ参照テーブル１１を参照し、そのＥＳ参照テーブル１１から実際のＥＳファイルを指定して、読み出すことにより実現できる。
［５．カッティングマスタファイル］
本例のマルチプレクサモジュールでは、仮想ＵＤＦイメージ／カッティングマスタ生成部３は、ＵＤＦイメージのほかに、ディスクプラントでディスク生成に必要なカッティングマスタファイルも生成する。
カッティングマスタの例としては、次のようなファイルがある。
・ＵＤＦイメージファイル
・コントロールデータファイル
・暗号化テーブルファイル
・物理情報ファイル
本例のマルチプレクサモジュールでは、仮想ＵＤＦイメージ／カッティングマスタ生成部３は、ＵＤＦイメージのほかに、ディスクプラントでディスク生成に必要なカッティングマスタファイルも生成する。
カッティングマスタの例としては、次のようなファイルがある。
・ＵＤＦイメージファイル
・コントロールデータファイル
・暗号化テーブルファイル
・物理情報ファイル
ＵＤＦイメージファイルは上述のように高速化処理が行われる。コントロールデータファイル、暗号化テーブルファイルも、圧縮した形でマルチプレクサから出力することによって高速化を行う。
例えば、コントロールデータファイルは、イメージファイルの１０２４分の１８のサイズがあるが、全てゼロデータであるとき、ファイルサイズ４バイトまで圧縮を行うことができる。
これらのカッティングマスタファイルへの復号は、次の工程のディスクプラント転送（通称ダウンローダ）によって行われる。
ダウンローダは、ディスクプラントへの出荷時１回だけ実施されるため、この工程によるオーサリングスタジオでのワークフロー全体から見るとオーバーヘッドは少ない。
例えば、コントロールデータファイルは、イメージファイルの１０２４分の１８のサイズがあるが、全てゼロデータであるとき、ファイルサイズ４バイトまで圧縮を行うことができる。
これらのカッティングマスタファイルへの復号は、次の工程のディスクプラント転送（通称ダウンローダ）によって行われる。
ダウンローダは、ディスクプラントへの出荷時１回だけ実施されるため、この工程によるオーサリングスタジオでのワークフロー全体から見るとオーバーヘッドは少ない。
［６．仮想クリップ・仮想ＵＤＦイメージの再生］
上述した仮想クリップ１０、仮想ＵＤＦイメージ２０の再生の具体例を説明する。
再生は、ファイルシステムを管理するソフトウェアをバックグラウンドで実行することで行う。仮想ファイルシステムには、以下の第１〜第３の再生システムのいずれかで実現できる。
上述した仮想クリップ１０、仮想ＵＤＦイメージ２０の再生の具体例を説明する。
再生は、ファイルシステムを管理するソフトウェアをバックグラウンドで実行することで行う。仮想ファイルシステムには、以下の第１〜第３の再生システムのいずれかで実現できる。
＜第１の再生システム＞
任意のディレクトリを指定すると、そのディレクトリ以下のファイルが任意のファイルシステムとして見えるようにしたシステムである。
任意のディレクトリを指定すると、そのディレクトリ以下のファイルが任意のファイルシステムとして見えるようにしたシステムである。
図１８に構成を示す。なお図において太線で示すＶＦＳインターフェース(Virtual File System Interface)３０、アザーファイルシステム（Other File System）３１は、ＯＳ（Operating System）のモジュールである。ここではWindows（登録商標）のＯＳとする。また破線で示すシステムサービス（System Service(Client)）３３，システムサービス（System Service(Server)）３４、フューズモジュール（Fuse Module）３２、ＤＬＬ(Dynamic Link Library)３５はオープンソースである。ファイルシステムアプリケーション（File System Application）３６が新規開発したモジュールとなる。
ファイルシステムアプリケーション３６は、仮想化されたクリップやイメージファイルが、あたかも実体のあるクリップやイメージファイルに見えるファイルシステムに変換するモジュールである。即ち素材データのファイルパスやオフセット、サイズなどを参照する。
なお通常のファイルシステムは、ＯＳのカーネルの一部として実装されているが，FUSEというカーネルモジュールを利用するとファイルシステムをユーザランドで実装することができる。
ＤＬＬ３５では、ユーザスペースとカーネル部のフューズモジュール３２との橋渡しが行われる。
フューズモジュール３２では、任意のディレクトリはユーザー指定のファイルシステムとして参照される。フューズモジュール３２はＯＳへはデバイスドライバとして登録する。
アザーファイルシステム３１は、指定外のファイルへのリクエストに対応するファイルシステムであり、ＯＳで決められたファイルシステム（例えばＦＡＴ３２，ＮＴＦＳ）などでファイルを参照する。
なお通常のファイルシステムは、ＯＳのカーネルの一部として実装されているが，FUSEというカーネルモジュールを利用するとファイルシステムをユーザランドで実装することができる。
ＤＬＬ３５では、ユーザスペースとカーネル部のフューズモジュール３２との橋渡しが行われる。
フューズモジュール３２では、任意のディレクトリはユーザー指定のファイルシステムとして参照される。フューズモジュール３２はＯＳへはデバイスドライバとして登録する。
アザーファイルシステム３１は、指定外のファイルへのリクエストに対応するファイルシステムであり、ＯＳで決められたファイルシステム（例えばＦＡＴ３２，ＮＴＦＳ）などでファイルを参照する。
この構成においてカーネル部では、ＯＳからのファイルのCREATE、READなどのサービスをユーザスペースのアプリケーションプログラムへ通知を行う。アプリケーションプログラムでは、仮想ファイルシステムを各サービスに対して処理し、カーネル部に完了通知を行う。
ＵＤＦイメージの再生手順を図１９に示す。
例えばソフトウエアプレーヤなどのアプリケーションからＵＤＦイメージファイルのアクセスがリクエストされることで、ステップＦ２０１からの処理が行われる。
ステップＦ２０１ではリクエストされたイメージファイルが仮想ＵＤＦイメージ２０として仮想化されているものであるか否かを判別する。
例えばソフトウエアプレーヤなどのアプリケーションからＵＤＦイメージファイルのアクセスがリクエストされることで、ステップＦ２０１からの処理が行われる。
ステップＦ２０１ではリクエストされたイメージファイルが仮想ＵＤＦイメージ２０として仮想化されているものであるか否かを判別する。
リクエスト対象が仮想化されたＵＤＦイメージの場合は、ステップＦ２０２で、ファイルシステムアプリケーション３６が、リクエストされたＵＤＦイメージと同じ名前のディレクトリ下の仮想クリップ参照テーブル２１を参照する。そして仮想ＵＤＦイメージ２０を実イメージに変換する。
例えばアプリケーションが、「ImageFile0」を実体ファイルとしてリクエストしたとする。本例の場合、図１１で示したように同じ名前の「ImageFile0」ディレクトリが形成され、そのディレクトリ下にエクステントマップファイル、ソースファイルリストマップによる仮想クリップ参照テーブル２１が形成されている。
ファイルシステムアプリケーション３６は、仮想クリップ参照テーブル２１、及びそこから参照されるＥＳ参照テーブル１１を用いて、ローカル（例えばＬドライブ）、あるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルを再生する。
なお仮想化されていない実体のＵＤＦイメージがリクエスト対象であれば、そのまま当該ＵＤＦイメージファイルを再生すればよい（Ｆ２０１→ＮＯ）。
例えばアプリケーションが、「ImageFile0」を実体ファイルとしてリクエストしたとする。本例の場合、図１１で示したように同じ名前の「ImageFile0」ディレクトリが形成され、そのディレクトリ下にエクステントマップファイル、ソースファイルリストマップによる仮想クリップ参照テーブル２１が形成されている。
ファイルシステムアプリケーション３６は、仮想クリップ参照テーブル２１、及びそこから参照されるＥＳ参照テーブル１１を用いて、ローカル（例えばＬドライブ）、あるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルを再生する。
なお仮想化されていない実体のＵＤＦイメージがリクエスト対象であれば、そのまま当該ＵＤＦイメージファイルを再生すればよい（Ｆ２０１→ＮＯ）。
ここで、ＵＤＦイメージ内でクリップファイル「xxxxx.m2ts」が含まれている場合、ステップＦ２０３からＦ２０４に進み、当該リクエストされたクリップが仮想化されたクリップであるか否かを判断する。
仮想化されたクリップである場合は、ファイルシステムアプリケーション３６はステップＦ２０５で、アプリケーションなどでリクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のＥＳ参照テーブル１１を読み出す。そしてＥＳ参照テーブル１１をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、元のクリップファイルを再生する。
なお、ＵＤＦイメージファイル内に実体があるクリップとして「xxxxx.m2ts」ファイルが含まれているときは、当該「xxxxx.m2ts」をそのままアプリケーションなどのリクエストに応じて再生できる（Ｆ２０４→ＮＯ）。
仮想化されたクリップである場合は、ファイルシステムアプリケーション３６はステップＦ２０５で、アプリケーションなどでリクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のＥＳ参照テーブル１１を読み出す。そしてＥＳ参照テーブル１１をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、元のクリップファイルを再生する。
なお、ＵＤＦイメージファイル内に実体があるクリップとして「xxxxx.m2ts」ファイルが含まれているときは、当該「xxxxx.m2ts」をそのままアプリケーションなどのリクエストに応じて再生できる（Ｆ２０４→ＮＯ）。
クリップの再生手順は図２０のようになる。
アプリケーションからクリップファイルのアクセスがリクエストされることで、ステップＦ２５０からの処理が行われる。
ステップＦ２５０ではリクエストされたクリップが仮想クリップ１０として仮想化されているものであるか否かを判別する。
仮想化されていない実体クリップであれば、そのまま当該クリップファイルを再生すればよい（Ｆ２５０→ＮＯ）。
アプリケーションからクリップファイルのアクセスがリクエストされることで、ステップＦ２５０からの処理が行われる。
ステップＦ２５０ではリクエストされたクリップが仮想クリップ１０として仮想化されているものであるか否かを判別する。
仮想化されていない実体クリップであれば、そのまま当該クリップファイルを再生すればよい（Ｆ２５０→ＮＯ）。
リクエストが仮想化されたクリップであった場合は、ファイルシステムアプリケーション１６はステップＦ２５１で、リクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のＥＳ参照テーブル１１を読み出す。そしてＥＳ参照テーブル１１をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、実クリップに変換し、元のクリップファイルを再生する。
＜第２の再生システム＞
第２の再生システムは、任意のディレクトリ以下のファイルが、ファイルシステムの規格であるＵＤＦ２．５あるいはＵＤＦ２．０１を参照するシステムである。
第２の再生システムは、任意のディレクトリ以下のファイルが、ファイルシステムの規格であるＵＤＦ２．５あるいはＵＤＦ２．０１を参照するシステムである。
図２１に構成を示す。この場合、太線で示すＶＦＳインターフェース(Virtual File System Interface)３０、アザーファイルシステム（Other File System）３１は、ＯＳ（Operating System）のモジュールである。またシステムサービス（System Service(Client)）３３Ａ，システムサービス（System Service(Server)）３４Ａ、フューズモジュール（Fuse Module）３２Ａ、ＤＬＬ(Dynamic Link Library)３５Ａ、ファイルシステムアプリケーション（File System Application）３６が新規開発したモジュールとなる。
ファイルシステムアプリケーション３６は仮想化イメージファイルが実体のある光ディスク（ＢＤ）に見えるファイルシステムに変換する。
ＤＬＬ３５Ａでは、ユーザスペースとカーネル部のフューズモジュール３２との橋渡しが行われる。
フューズモジュール３２Ａでは、任意のＵＤＦ２．５（ＵＤＦ２．０１）のＵＤＦイメージファイルは、ディレクトリに見えるようになる。ＯＳへはデバイスドライバとして登録する。
アザーファイルシステム３１は、指定外のファイルへのリクエストについて、ＯＳで決められたファイルシステム（例ＦＡＴ３２，ＮＴＦＳ）などでファイルを参照する。
ＤＬＬ３５Ａでは、ユーザスペースとカーネル部のフューズモジュール３２との橋渡しが行われる。
フューズモジュール３２Ａでは、任意のＵＤＦ２．５（ＵＤＦ２．０１）のＵＤＦイメージファイルは、ディレクトリに見えるようになる。ＯＳへはデバイスドライバとして登録する。
アザーファイルシステム３１は、指定外のファイルへのリクエストについて、ＯＳで決められたファイルシステム（例ＦＡＴ３２，ＮＴＦＳ）などでファイルを参照する。
ＢＤはＵＤＦ２．５の規定があるため、マルチプレクサが出力するＵＤＦイメージは、この構成においては、ディレクトリとしてＯＳ上見えることになる。
なおWindowsXP（登録商標）のようにＵＤＦ２．５を標準サポートしていないＯＳにおいては、標準サポートしているＵＤＦ２．０１へファイルシステムアプリケーション３６で変換する。
なおWindowsXP（登録商標）のようにＵＤＦ２．５を標準サポートしていないＯＳにおいては、標準サポートしているＵＤＦ２．０１へファイルシステムアプリケーション３６で変換する。
この場合、仮想ＵＤＦイメージの再生手順は上記図１９と同様となる。
仮想クリップ１０については、この構成では再生できない。ＵＤＦではないためである。
再生するときは、仮想化されたクリップを含んだディレクトリで仮想化ＵＤＦイメージ２０、あるいは実体のあるＵＤＦイメージを生成する必要がある。その再生手順は、図１９のステップＦ２０３〜Ｆ２０５によるものとなる。
しかしながら、仮想化ＵＤＦイメージ２０の生成時間は、仮想化されたクリップを生成する時間と比較する非常に速いため、このように仮想ＵＤＦイメージ化してから再生するという方式をとっても、オーサリングの効率化は実現できる。
仮想クリップ１０については、この構成では再生できない。ＵＤＦではないためである。
再生するときは、仮想化されたクリップを含んだディレクトリで仮想化ＵＤＦイメージ２０、あるいは実体のあるＵＤＦイメージを生成する必要がある。その再生手順は、図１９のステップＦ２０３〜Ｆ２０５によるものとなる。
しかしながら、仮想化ＵＤＦイメージ２０の生成時間は、仮想化されたクリップを生成する時間と比較する非常に速いため、このように仮想ＵＤＦイメージ化してから再生するという方式をとっても、オーサリングの効率化は実現できる。
＜第３の再生システム＞
第３の再生システムを図２２に示す。これはハードウェアエミュレータ（Ｈエミュレータ）による再生システムである。
ハードウェアエミュレータとは、ＡＴＡ（ＳＡＴＡ）接続したＰＣホスト、あるいはＣＥプレーヤーから、あたかもドライブが接続したかのように見えるシステムである。本例は、ハードウェアエミュレータのイメージファイルの再生部にフィルタリングを行うことによって、仮想ファイルを実際のイメージファイルとして見せかけるシステムである。
第３の再生システムを図２２に示す。これはハードウェアエミュレータ（Ｈエミュレータ）による再生システムである。
ハードウェアエミュレータとは、ＡＴＡ（ＳＡＴＡ）接続したＰＣホスト、あるいはＣＥプレーヤーから、あたかもドライブが接続したかのように見えるシステムである。本例は、ハードウェアエミュレータのイメージファイルの再生部にフィルタリングを行うことによって、仮想ファイルを実際のイメージファイルとして見せかけるシステムである。
図２２（ａ）（ｂ）に示すように、ホストＰＣ５０とＨエミュレータ用ＰＣ５１が、ＰＣＩ基板５２においてＳＡＴＡ等で接続される。
図２２（ａ）の再生処理前の状態では、ホストＰＣ５０から、Ｈエミュレータ用ＰＣ５１内のＨＤＤ５３において仮想ＵＤＦイメージ構造が認識される。
再生時は、Ｈエミュレータ用ＰＣ５１側で仮想クリップ参照テーブル２１を用いて直接素材ファイルの読み出しを行う。ホストＰＣ５０からは、図２２（ｂ）のように、光ディスクのファイルシステムがあたかもＨエミュレータ用ＰＣ５１側にマウントされたかのように見える。つまり本来のＵＤＦイメージファイルにデコードされて見える。
このシステムでは、ＳＡＴＡなどのインターフェースを持つ専用のＰＣＩ基板５２などのハードウェアの追加が必要となるが、Ｈエミュレータを実現するアプリケーションへの少ない対応で再生システムを実現できる。
図２２（ａ）の再生処理前の状態では、ホストＰＣ５０から、Ｈエミュレータ用ＰＣ５１内のＨＤＤ５３において仮想ＵＤＦイメージ構造が認識される。
再生時は、Ｈエミュレータ用ＰＣ５１側で仮想クリップ参照テーブル２１を用いて直接素材ファイルの読み出しを行う。ホストＰＣ５０からは、図２２（ｂ）のように、光ディスクのファイルシステムがあたかもＨエミュレータ用ＰＣ５１側にマウントされたかのように見える。つまり本来のＵＤＦイメージファイルにデコードされて見える。
このシステムでは、ＳＡＴＡなどのインターフェースを持つ専用のＰＣＩ基板５２などのハードウェアの追加が必要となるが、Ｈエミュレータを実現するアプリケーションへの少ない対応で再生システムを実現できる。
ＵＤＦイメージファイルの再生手順は次のようになる。
仮想化されたＵＤＦイメージファイルをホストＰＣ５０上のアプリケーションなど（例ソフトウェアプレーヤーなど）からリクエストされることで再生処理を行う。この場合、Ｈエミュレータ用ＰＣ５１上で機能しているアプリケーションプログラムでリクエストされたＵＤＦイメージと同じ名前のディレクトリ下の仮想クリップ参照テーブル２１を参照する。そしてローカルあるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルを再生する。
仮想化されたＵＤＦイメージファイルをホストＰＣ５０上のアプリケーションなど（例ソフトウェアプレーヤーなど）からリクエストされることで再生処理を行う。この場合、Ｈエミュレータ用ＰＣ５１上で機能しているアプリケーションプログラムでリクエストされたＵＤＦイメージと同じ名前のディレクトリ下の仮想クリップ参照テーブル２１を参照する。そしてローカルあるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルを再生する。
ＵＤＦイメージファイル内にクリップが含まれているときは次のようになる。例えば「xxxxx.m2ts」ファイルがアプリケーションなどでリクエストされたとき、Ｈエミュレータ用ＰＣ５１上で走るアプリケーションプログラムで「xxxxx.m2ts」ディレクトリ以下のＥＳ参照テーブル１１を参照する。そしてＥＳ参照テーブル１１をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、元のクリップファイルを再生する。
なお、この構成では、ＵＤＦではないので仮想化されたクリップは再生することはできない。仮想クリップ１０を再生するときは、仮想化されたクリップを含んだディレクトリで仮想ＵＤＦイメージ２０、あるいは実体のあるＵＤＦイメージを生成する必要がある。
しかしながら、仮想化ＵＤＦイメージ２０の生成時間は、仮想化されたクリップを生成する時間と比較する非常に速いため、このように仮想ＵＤＦイメージ化してから再生するという方式をとっても、オーサリングの効率化は実現できる。
しかしながら、仮想化ＵＤＦイメージ２０の生成時間は、仮想化されたクリップを生成する時間と比較する非常に速いため、このように仮想ＵＤＦイメージ化してから再生するという方式をとっても、オーサリングの効率化は実現できる。
［７．編集データ再生装置］
ところで、さらに図２２のＨエミュレータ用ＰＣ５１で実行するアプリケーションに、上述した本実施の形態のマルチプレクサ処理を行わせることも可能である。
即ち当該アプリケーションにおけるソフトウエア及びＨエミュレータ用ＰＣ５１におけるハードウエアを用いて、仮想クリップ生成手段と、仮想イメージ生成手段と、仮想イメージ再生手段を形成する。
仮想クリップ生成手段は、図２のステップＦ１０３の処理を行う。即ち仮想クリップ生成手段は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対するＥＳ参照テーブル１１を有する仮想クリップ１０を生成する。
仮想イメージ生成手段は、図２のステップＦ１０５の処理を行う。即ち仮想イメージ生成手段は、編集結果としてのイメージデータの生成において、素材データ自体を含まずに、仮想クリップ１０を参照する仮想クリップ参照テーブル２１を有するイメージファイル構造としての仮想イメージ２０を生成する。
仮想イメージ再生手段は、図２のステップＦ１０７の処理を行う。即ち仮想イメージ再生手段は、仮想イメージ２０の再生を、仮想クリップ参照テーブル２１を用い、ＥＳ参照テーブル１１を介して素材データを読み出すことで実現する。
ところで、さらに図２２のＨエミュレータ用ＰＣ５１で実行するアプリケーションに、上述した本実施の形態のマルチプレクサ処理を行わせることも可能である。
即ち当該アプリケーションにおけるソフトウエア及びＨエミュレータ用ＰＣ５１におけるハードウエアを用いて、仮想クリップ生成手段と、仮想イメージ生成手段と、仮想イメージ再生手段を形成する。
仮想クリップ生成手段は、図２のステップＦ１０３の処理を行う。即ち仮想クリップ生成手段は、素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対するＥＳ参照テーブル１１を有する仮想クリップ１０を生成する。
仮想イメージ生成手段は、図２のステップＦ１０５の処理を行う。即ち仮想イメージ生成手段は、編集結果としてのイメージデータの生成において、素材データ自体を含まずに、仮想クリップ１０を参照する仮想クリップ参照テーブル２１を有するイメージファイル構造としての仮想イメージ２０を生成する。
仮想イメージ再生手段は、図２のステップＦ１０７の処理を行う。即ち仮想イメージ再生手段は、仮想イメージ２０の再生を、仮想クリップ参照テーブル２１を用い、ＥＳ参照テーブル１１を介して素材データを読み出すことで実現する。
通常Ｈエミュレータが再生できるＵＤＦイメージファイルは、ディスクのイメージとして１つのファイルでなければならない。このためマルチプレクサ処理を行ったＵＤＦイメージファイルを再生の対象として、Ｈエミュレータのアプリケーションに登録していた。ここで、ＵＤＦイメージ化する前の多数のフォルダおよびファイルから構成されるコンテンツをアプリケーションに登録し、上述した仮想的なファイル形成を行うマルチプレクサ処理を行って仮想化されたＵＤＦイメージを作成する。すると、それを再生することができるようになる。
このように、Ｈエミュレータのアプリケーションに本実施の形態のマルチプレクサ処理を行わせることにより、フォルダおよびファイルの状態から短時間でＵＤＦイメージファイルに変換することができ、Ｈエミュレータで再生確認を行うことができるようになる。これにより、オーサリング処理で行っていた、映像データ、音声データ、メニューデータ、字幕データ、ＪＡＶＡプログラム等の差し替え作業を、オーサリング処理を介さずにファイルを差し替えるだけで再生確認ができるようになり、オーサリングの効率化が実現できる。
つまり、本発明の編集データ再生装置としてのエミュレータを実現できる。
つまり、本発明の編集データ再生装置としてのエミュレータを実現できる。
［８．ＢＤ−Ｒ書込］
続いて図２のステップＦ１０８のＢＤ−Ｒ書込について説明する。
図２５，図３等で上述してきたように、オーサリングシステムにおけるマルチプレクサは、エンコーダにより符号化された映像データや音声データ、メニュなどを多重化するためのものである。そしてハードディスク内に格納された画像、音声、字幕などの符号化されたデータをインターリーブし、各種フォーマットファイルと合わせて多重化されたデータを作成する多重化処理が行われる。
作成された多重化データは、最終的にはディスク製造用のカッティングマスタとしてハードディスク内に格納される。
続いて図２のステップＦ１０８のＢＤ−Ｒ書込について説明する。
図２５，図３等で上述してきたように、オーサリングシステムにおけるマルチプレクサは、エンコーダにより符号化された映像データや音声データ、メニュなどを多重化するためのものである。そしてハードディスク内に格納された画像、音声、字幕などの符号化されたデータをインターリーブし、各種フォーマットファイルと合わせて多重化されたデータを作成する多重化処理が行われる。
作成された多重化データは、最終的にはディスク製造用のカッティングマスタとしてハードディスク内に格納される。
また、オーサリングスタジオでは、図２のステップＦ１０８として述べたように、カッティングマスタの一部であるＵＤＦイメージデータを市販のＢｕｒｎツールなどでＢＤ−Ｒに記録する。そしてステップＦ１０９で、実際に工場でマスタリングするＢＤ−ＲＯＭと同じような挙動を行うか、任意のプレーヤーで動作確認を行う。
このＢＤ−Ｒに書込を行うプロセスに、従来はいくつかの課題があった。
このＢＤ−Ｒに書込を行うプロセスに、従来はいくつかの課題があった。
まず、ＵＤＦイメージデータのサイズは大きいもので、一旦ハードディスクに出力するだけでも、時間がかかってしまう。
これに対しては上述してきたように、大容量のデータを加工したファイルを生成せず、ＰＣ上のファイルを直接リードしながら、あるいはエンコードした素材を直接リードしながら仮想クリップ１０、仮想ＵＤＦイメージ２０を生成するプロセスを行うことで解決できる。
ＢＤ−Ｒに記録する際は、仮想ＵＤＦイメージ２０に基づいて再生されるデータをデコードすることでデータ書込の際の前処理時間を短縮することができる。
これに対しては上述してきたように、大容量のデータを加工したファイルを生成せず、ＰＣ上のファイルを直接リードしながら、あるいはエンコードした素材を直接リードしながら仮想クリップ１０、仮想ＵＤＦイメージ２０を生成するプロセスを行うことで解決できる。
ＢＤ−Ｒに記録する際は、仮想ＵＤＦイメージ２０に基づいて再生されるデータをデコードすることでデータ書込の際の前処理時間を短縮することができる。
もう１つの課題として、ＢＤ−ＲとＢＤ−ＲＯＭの配置が同じになる保証がないということがある。
例えば２層ＢＤ−Ｒの記録を行うときは、図２３（ａ）に示すように、１層目を全て書き込んでから、２層目に折り返すことになっている。図２３（ａ）において示すように、１層目（レイヤＬ０）の書込は、ディスク内周側から外周側に進行し、外周側において設定されているアンユースドスペースまで達した時点で、レイヤーブレイクＬＢを行って２層目（レイヤＬ１）に折り返す。
例えば２層ＢＤ−Ｒの記録を行うときは、図２３（ａ）に示すように、１層目を全て書き込んでから、２層目に折り返すことになっている。図２３（ａ）において示すように、１層目（レイヤＬ０）の書込は、ディスク内周側から外周側に進行し、外周側において設定されているアンユースドスペースまで達した時点で、レイヤーブレイクＬＢを行って２層目（レイヤＬ１）に折り返す。
一方、最終製品としてのＢＤ−ＲＯＭに関しては、例えばコンテンツ内容などに応じて、レイヤーブレイクＬＢのポイントが設定される。ＢＤ−ＲＯＭ製造段階で１層目に書き込むサイズを任意に指定できるためである。例えば図２３（ｂ）のようにＡ点がレイヤーブレイクＬＢのポイントとして設定される。これによって図の斜線部のようにデータ記録が行われた状態となる。
すると、通常にＢＤ−Ｒ書込を行ってしまうと、図２３（ａ）（ｂ）から分かるように、同じ内容であっても、ＢＤ−ＲはＢＤ−ＲＯＭとは異なる状態で各レイヤに記録が行われてしまう。
すると、通常にＢＤ−Ｒ書込を行ってしまうと、図２３（ａ）（ｂ）から分かるように、同じ内容であっても、ＢＤ−ＲはＢＤ−ＲＯＭとは異なる状態で各レイヤに記録が行われてしまう。
図２のステップＦ１０８、Ｆ１０９のＢＤ−Ｒ書込及び再生確認は、ＢＤ−Ｒを通常のプレーヤで再生することで、最終製品としてのＢＤ−ＲＯＭの挙動を確認するために行うものである。
プレーヤーの再生確認は、データの配置によってシーク時間やレイヤー（層）ジャンプなどのアクセスタイムを考慮して評価を行わなければならないのだが、それができなくなる。たとえば、レイヤ間をまたぐシーク時間は、ＢＤドライブの性能上、同じレイヤでのシーク時間よりも大きくなる。しかし、ＢＤ−ＲとＢＤ−ＲＯＭでレイヤーブレイクＬＢのポイントが異なることとなると、このような点を考慮した再生確認ができないこととなる。
プレーヤーの再生確認は、データの配置によってシーク時間やレイヤー（層）ジャンプなどのアクセスタイムを考慮して評価を行わなければならないのだが、それができなくなる。たとえば、レイヤ間をまたぐシーク時間は、ＢＤドライブの性能上、同じレイヤでのシーク時間よりも大きくなる。しかし、ＢＤ−ＲとＢＤ−ＲＯＭでレイヤーブレイクＬＢのポイントが異なることとなると、このような点を考慮した再生確認ができないこととなる。
そこで本例では、仮想ＵＤＦイメージに基づくＢＤ−Ｒ書込において、ＢＤ−ＲＯＭと同じ配置でＢＤ−Ｒ書込ができるようにする。例えば図２３（ｃ）のように書込を行う。
ＢＤ−Ｒ書込においては、レイヤ０からレイヤ１へのレイヤーブレイクＬＢのポイントは、アンユースドスペースに達した位置である。そこで、図２３（ｃ）のように、ダミデータＤＭを配置し、コンテンツファイル内容から見たレイヤブレイクポイントがＢＤ−ＲＯＭの場合と同じ箇所となるようにする。
なお、最終製品となるＢＤ−ＲＯＭについても、同様にダミーデータを配置し、図２３（ｃ）と同様の配置となるようにするものである。つまり、例えば図２３（ｂ）のようにＢＤ−ＲＯＭのレイヤーブレイクＬＢのポイントがコンテンツ内容等から決められる場合、ＢＤ−Ｒでは、アンユースドスペースに達した位置とされるレイヤーブレイクＬＢのポイントが、そのＢＤ−ＲＯＭの内容的な位置としてのレイヤーブレイクＬＢのポイントと一致するようにする。その上で、最終製品のＢＤ−ＲＯＭは、図２３（ｃ）と同様にダミーデータを付加した配置を行う。結局、図２３（ｃ）のＢＤ−Ｒは、ＢＤ−ＲＯＭと同一の配置とされ、再生確認を適切なものとできる。
ＢＤ−Ｒ書込においては、レイヤ０からレイヤ１へのレイヤーブレイクＬＢのポイントは、アンユースドスペースに達した位置である。そこで、図２３（ｃ）のように、ダミデータＤＭを配置し、コンテンツファイル内容から見たレイヤブレイクポイントがＢＤ−ＲＯＭの場合と同じ箇所となるようにする。
なお、最終製品となるＢＤ−ＲＯＭについても、同様にダミーデータを配置し、図２３（ｃ）と同様の配置となるようにするものである。つまり、例えば図２３（ｂ）のようにＢＤ−ＲＯＭのレイヤーブレイクＬＢのポイントがコンテンツ内容等から決められる場合、ＢＤ−Ｒでは、アンユースドスペースに達した位置とされるレイヤーブレイクＬＢのポイントが、そのＢＤ−ＲＯＭの内容的な位置としてのレイヤーブレイクＬＢのポイントと一致するようにする。その上で、最終製品のＢＤ−ＲＯＭは、図２３（ｃ）と同様にダミーデータを付加した配置を行う。結局、図２３（ｃ）のＢＤ−Ｒは、ＢＤ−ＲＯＭと同一の配置とされ、再生確認を適切なものとできる。
このようなＢＤ−Ｒ書込を実現するために、本例では、例えばマルチプレクサモジュールが図２４の処理を行う。
ステップＦ４０１でパラメータ入力処理を行う。ここでは、ダミーファイルの最大サイズ、アンユース度スペースの最大サイズ、ディスク片面（１つの記録層）の最大サイズ、クリップのインターリーブ用情報等の入力を受け付ける。
ステップＦ４０１でパラメータ入力処理を行う。ここでは、ダミーファイルの最大サイズ、アンユース度スペースの最大サイズ、ディスク片面（１つの記録層）の最大サイズ、クリップのインターリーブ用情報等の入力を受け付ける。
ステップＦ４０２では、ＢＤ−Ｒ書込を行おうとする仮想ＵＤＦイメージ２０についてのディレクトリパスを取得する。
ステップＦ４０３では、入力されたパラメータから、ＵＤＦイメージの配置を決定する。この場合、２層ディスクが対象の場合は、ユーザが指定した位置でレイヤブレイクが行われるようにする。またダミーファイルやアンユースドスペースのサイズと配置を決定する。
この際、クリップのインターリーブをＢＤのジャンプモデルを考慮して決定する。ＢＤ等の光ディスクでは、シークやレイヤージャンプなどの再生時のオーバーヘッドを考慮したクリップを、ＵＤＦイメージ上で配置する必要があるためである。
なおインターリーブは、マルチアングルなどのタイトルで主に使用される。ＢＤやＤＶＤでは、マルチアングル、マルチストリーを編集されることが多く、その場合インターリーブは必須の機能になる。マルチアングルとは、同一時間内に進行する映像を異なるカメラアングルからアングルを記録し、プレイヤーの操作によりユーザーが任意に選択できる機能である。マルチストーリーとはユーザーがメニューで選択したり製作者が分岐先等を指定することにより、見る人の選択によってストーリー展開を自由に選べる機能である。
ステップＦ４０３では、入力されたパラメータから、ＵＤＦイメージの配置を決定する。この場合、２層ディスクが対象の場合は、ユーザが指定した位置でレイヤブレイクが行われるようにする。またダミーファイルやアンユースドスペースのサイズと配置を決定する。
この際、クリップのインターリーブをＢＤのジャンプモデルを考慮して決定する。ＢＤ等の光ディスクでは、シークやレイヤージャンプなどの再生時のオーバーヘッドを考慮したクリップを、ＵＤＦイメージ上で配置する必要があるためである。
なおインターリーブは、マルチアングルなどのタイトルで主に使用される。ＢＤやＤＶＤでは、マルチアングル、マルチストリーを編集されることが多く、その場合インターリーブは必須の機能になる。マルチアングルとは、同一時間内に進行する映像を異なるカメラアングルからアングルを記録し、プレイヤーの操作によりユーザーが任意に選択できる機能である。マルチストーリーとはユーザーがメニューで選択したり製作者が分岐先等を指定することにより、見る人の選択によってストーリー展開を自由に選べる機能である。
以上の処理で、図２３（ｃ）のような書込のためのＵＤＦイメージの配置が決定される。そこでステップＦ４０４で、仮想ＵＤＦイメージ２０の仮想クリップ参照テーブル２１（エクステント情報）を元に、ＢＤ−Ｒ書込のためのストリーム再生を行い、ＢＤ−Ｒ書込プログラムに受け渡して、ＢＤ−Ｒに対する書込を実行する。
即ち本例の場合、仮想ＵＤＦイメージ２０を再生してＢＤ−Ｒ書込ストリームを形成する際に、ダミーファイルサイズ等の入力パラメータを反映された書き込み用ストリームが形成されるようにする。これにより、入力パラメータに応じて図２３のように書込が行われ、結果として、ＢＤ−ＲＯＭと同じ位置（コンテンツ内容から見ての同じ位置）でレイヤーブレイクが行われるようにできるなど、確認用として適切なＢＤ−Ｒ記録を行うことができる。
従来は、記録用のイメージファイルを生成してから、そのイメージファイルをＢＤ−Ｒに書き込むか、或いはディレクトリ指定して、その指定されたディレクトリのファイルを書き込むことが行われていた。ＢＤ−Ｒ記録用のイメージファイルを生成することは、工程の効率を悪化させる。またディレクトリ指定で行う場合は、ＢＤ−Ｒ上での物理的な位置を規定できない。
これに対して本例では、仮想ＵＤＦイメージ２０の再生において、ダミーファイルサイズ、アンユースドスペースのサイズ、１層最大サイズ、インターリーブ用情報等が反映されるようにする。このため、上記のように物理的な位置を任意に設定でき、かつ予めＢＤ−Ｒ書込用のイメージファイルを別に作成するという必要もなくなる。
従来は、記録用のイメージファイルを生成してから、そのイメージファイルをＢＤ−Ｒに書き込むか、或いはディレクトリ指定して、その指定されたディレクトリのファイルを書き込むことが行われていた。ＢＤ−Ｒ記録用のイメージファイルを生成することは、工程の効率を悪化させる。またディレクトリ指定で行う場合は、ＢＤ−Ｒ上での物理的な位置を規定できない。
これに対して本例では、仮想ＵＤＦイメージ２０の再生において、ダミーファイルサイズ、アンユースドスペースのサイズ、１層最大サイズ、インターリーブ用情報等が反映されるようにする。このため、上記のように物理的な位置を任意に設定でき、かつ予めＢＤ−Ｒ書込用のイメージファイルを別に作成するという必要もなくなる。
［９．実施の形態の効果及び変形例］
以上説明してきたように、本実施の形態では、オーサリング工程におけるマルチプレクサ処理が、仮想クリップ１０、仮想ＵＤＦイメージ２０による処理とすることで著しく時短化できる。例えば、従来と同等のサイズのストリームファイルやＵＤＦイメージファイルを生成する場合で比較して、約７倍の高速化（工程時間が１／７への時間短縮）を実現できた。これによって、効率のよいオーサリング工程を実現できる。
以上説明してきたように、本実施の形態では、オーサリング工程におけるマルチプレクサ処理が、仮想クリップ１０、仮想ＵＤＦイメージ２０による処理とすることで著しく時短化できる。例えば、従来と同等のサイズのストリームファイルやＵＤＦイメージファイルを生成する場合で比較して、約７倍の高速化（工程時間が１／７への時間短縮）を実現できた。これによって、効率のよいオーサリング工程を実現できる。
なお実施の形態の変形例として以下のようなものが想定される。
仮想クリップ１０、仮想ＵＤＦイメージ２０等の仮想データを専用のソフトウェアで再生することもできる。即ちオーサリング工程とは独立して再生を行う再生モジュールを形成してもよい。市販の再生用ソフトウェアなどは利用できないが、例えば仮想ファイルシステムによるデータの再構成に所要するオーバーヘッドを考慮した場合に想定される。
仮想クリップ１０、仮想ＵＤＦイメージ２０等の仮想データを専用のソフトウェアで再生することもできる。即ちオーサリング工程とは独立して再生を行う再生モジュールを形成してもよい。市販の再生用ソフトウェアなどは利用できないが、例えば仮想ファイルシステムによるデータの再構成に所要するオーバーヘッドを考慮した場合に想定される。
またマルチプレクサでは、アプリケーションフォーマットに準拠したプレゼンテーションデータに変換加工するが、メニュー画面のナビゲーション等はＳＴＤ（System Target Decoder）のバッファ管理を考慮しないで、オーサリング時に再生確認を行いたいことが多い。この再生システムをシミュレータと一般に呼ぶ。このシミュレータも、マルチプレクサと同様に素材を直接読み出すことで再生することが可能である。この場合、素材の置き換えを行うと、短時間で再生確認を行うことができる。
またＭＰＥＧ２トランスポートフォームのほかに、ＭＰＥＧ２プログラムストリームなど同様のマルチプレクサシステムにおいて、仮想ファイルシステムによる高速化を行うことができる。
また素材の参照テーブルファイル（ＥＳ参照テーブル）のフォーマットは各種変形可能である。再生可能であればサイズが小さい方がマルチプレクサの再生時間は高速になる。
また素材の参照テーブルファイル（ＥＳ参照テーブル）のフォーマットは各種変形可能である。再生可能であればサイズが小さい方がマルチプレクサの再生時間は高速になる。
また、オーサリング工程を並列に行う並列処理を組み合わせることによって、さらなる高速化が可能となる。
また従来マルチプレクサ処理、つまり実データとしてのクリップファイル等を作成するシステムと併用できるシステムとしても実現可能である。即ちユーザ指示により、仮想化処理をするか否かを選択可能とするものである。
また従来マルチプレクサ処理、つまり実データとしてのクリップファイル等を作成するシステムと併用できるシステムとしても実現可能である。即ちユーザ指示により、仮想化処理をするか否かを選択可能とするものである。
１ 仮想クリップ生成部、２ メタデータ生成部、３ 仮想ＵＤＦイメージ／カッティングマスタ生成部、１０ 仮想クリップ、１１ ＥＳ参照テーブル、２０ 仮想ＵＤＦイメージ、２１ 仮想クリップ参照テーブル
Claims (3)
- 素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、
上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、
再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程とを有し、
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込／再生工程を有し、
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有し、
上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材ＩＤを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材ＩＤについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにするオーサリング方法。 - 素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成工程と、
上記仮想クリップの再生を、上記素材参照テーブルを用いて素材データを読み出すことで実現する仮想クリップ再生工程と、
再生専用記録媒体に記録する内容としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成工程と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生工程とを情報処理装置に実行させ、
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込／再生工程を有し、
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有し、
上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材ＩＤを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材ＩＤについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにするプログラム。 - 素材データを時分割多重化したストリームデータ構造の生成において、素材データ自体を含まずに、素材データに対する素材参照テーブルを有する仮想クリップを生成する仮想クリップ生成手段と、
編集結果としてのイメージデータの生成において、素材データ自体を含まずに、上記仮想クリップを参照する仮想クリップ参照テーブルを有するイメージファイル構造としての仮想イメージを生成する仮想イメージ生成手段と、
上記仮想イメージの再生を、上記仮想クリップ参照テーブルを用い、上記素材参照テーブルを介して素材データを読み出すことで実現する仮想イメージ再生手段とを有し、
さらに、入力された所定のパラメータと、上記仮想クリップ参照テーブルを用いて、上記仮想イメージから得られるデータストリームを書込可能型記録媒体に書き込むとともに、当該書込可能型記録媒体の再生を行う書込／再生工程を有し、
さらに、上記仮想イメージに基づいて、再生専用記録媒体の製造のためのマスターデータを生成するマスターデータ生成工程を有し、
上記仮想クリップ生成工程で生成する上記素材参照テーブルには、上記ストリームデータ構造を形成するパケットのパケットヘッダであって実際の素材データを示す素材ＩＤを含むヘッダ情報を集めたパケットベースと、該パケットベースに記述された素材ＩＤについての実際の素材データの参照ファイルパスを記録したリストファイルが含まれるようにする編集データ再生装置。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009060397A JP5245940B2 (ja) | 2009-03-13 | 2009-03-13 | オーサリング方法、プログラム、編集データ再生装置 |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2009060397A JP5245940B2 (ja) | 2009-03-13 | 2009-03-13 | オーサリング方法、プログラム、編集データ再生装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2010218589A JP2010218589A (ja) | 2010-09-30 |
| JP5245940B2 true JP5245940B2 (ja) | 2013-07-24 |
Family
ID=42977275
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2009060397A Expired - Fee Related JP5245940B2 (ja) | 2009-03-13 | 2009-03-13 | オーサリング方法、プログラム、編集データ再生装置 |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP5245940B2 (ja) |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP3637910B2 (ja) * | 2003-04-04 | 2005-04-13 | ソニー株式会社 | データ処理方法およびそのシステム |
| EP1802117B1 (en) * | 2004-09-24 | 2014-06-11 | Panasonic Corporation | Data processor |
| JP2006295732A (ja) * | 2005-04-13 | 2006-10-26 | Matsushita Electric Ind Co Ltd | システムストリーム作成装置、システムストリーム作成方法 |
| US7848621B2 (en) * | 2005-07-01 | 2010-12-07 | Sony Corporation | File format translation |
| US8644682B2 (en) * | 2005-08-29 | 2014-02-04 | Sony Corporation | Playable content |
-
2009
- 2009-03-13 JP JP2009060397A patent/JP5245940B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2010218589A (ja) | 2010-09-30 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| CN102005228B (zh) | 记录方法和再现装置 | |
| JP4491035B2 (ja) | 再生装置、デバッグ装置、システムｌｓｉ、プログラム | |
| US7639923B2 (en) | Reproduction device, optical disc, recording medium, program, and reproduction method | |
| US7653656B2 (en) | Method for splitting a data stream | |
| JP5032510B2 (ja) | 再生装置、記録方法、プログラム | |
| KR20060081330A (ko) | 로컬 스토리지를 이용한 기록매체 재생방법 및 재생장치 | |
| MXPA06014210A (es) | Aparato de reproduccion para realizar reproduccion sincronizada con aplicaciones. | |
| RU2408092C2 (ru) | Способ и устройство воспроизведения данных с носителя записи | |
| US8644682B2 (en) | Playable content | |
| KR20070022580A (ko) | 데이터 재생방법 및 재생장치, 기록매체와 데이터 기록방법및 기록장치 | |
| WO2007117016A1 (ja) | 記録装置、記録方法および記録プログラム | |
| KR20070014945A (ko) | 기록매체, 데이터 재생방법 및 재생장치와 데이터 기록방법및 기록장치 | |
| US20080244407A1 (en) | Abstractions in disc authoring | |
| KR20070052642A (ko) | 데이터 재생방법 및 재생장치와 데이터 전송방법 | |
| KR20060047549A (ko) | 로컬 스토리지를 이용한 기록매체 재생방법 및 재생장치 | |
| JP5245940B2 (ja) | オーサリング方法、プログラム、編集データ再生装置 | |
| US8712223B2 (en) | Authoring method, authoring device and program | |
| EP1596397B1 (en) | Method for splitting a data stream | |
| KR20060063597A (ko) | 로컬 스토리지를 이용한 기록매체 재생방법 및 재생장치 | |
| RU2383949C2 (ru) | Способ и устройство воспроизведения данных с носителя записи с использованием локального запоминающего устройства | |
| KR20080034178A (ko) | 기록매체, 데이터 재생방법 및 재생장치와 데이터 기록방법및 기록장치 | |
| KR20070120001A (ko) | 데이터를 재생하는 방법 및 장치 그리고 기록방법,기록장치 및 기록매체 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| RD02 | Notification of acceptance of power of attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7422 Effective date: 20120118 |
|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20120213 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20121217 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20121225 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20130218 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20130312 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20130325 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20160419 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |