(57)【要約】【課題】ＯＳがサポートしていないファイルシステムによるファイルを、そのＯＳがサポートしているファイルシステム上で容易に扱うことが可能なオーサリング方法、オーサリング装置及びプログラムを提供する。【解決手段】素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、素材データ自体を含まずに、素材データの記録位置を参照する第一の実体化用ファイルを生成するステップと、第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージをマウントするため、素材データ自体を含まずに、素材データの記録位置を参照する第二の実体化用ファイルを生成するステップと、第一の実体化用ファイル及び第二の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して第一の仮想イメージを生成するステップとを備える。【選択図】図１８
2011216013.tif 000002
【特許請求の範囲】
【請求項１】
素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、前記素材データ自体を含まずに、前記素材データの記録位置を参照する第一の実体化用ファイルを生成するステップと、
前記素材データが時分割多重化された前記第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージをマウントするため、前記素材データ自体を含まずに、前記素材データの記録位置を参照する第二の実体化用ファイルを生成するステップと、
前記第一の実体化用ファイル及び前記第二の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して前記第一の仮想イメージを生成するステップと
を備える、オーサリング方法。
【請求項２】
前記第一の仮想イメージが選択されたとき、前記第一の実体イメージを前記第一のファイルシステムに、又は前記第二の実体イメージを前記第二のファイルシステムにマウントするステップと、
マウントされた前記第一の実体イメージ又は前記第二の実体イメージのディレクトリ下に前記素材データを配置するステップと
を更に備える、請求項１に記載のオーサリング方法。
【請求項３】
前記第一の実体イメージを前記第一のファイルシステムに、又は前記第二の実体イメージを前記第二のファイルシステムにマウントするステップは、
オペレーティングシステムが、前記第一のファイルシステムのみに対応しているときは、前記第一の実体イメージを前記第一のファイルシステムにマウントし、オペレーティングシステムが、前記第一のファイルシステムと前記第二のファイルシステムの両方に対応しているときは、前記第二の実体イメージを前記第二のファイルシステムにマウントする、請求項２に記載のオーサリング方法。
【請求項４】
素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、前記素材データが時分割多重化された前記第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージ自体と前記素材データ自体を含まずに、前記素材データ及び前記第二の実体イメージの記録位置を参照する第三の実体化用ファイルを生成するステップと、
前記第三の実体化用ファイルを前記第一の仮想イメージのディレクトリ下に配置して前記第二の仮想イメージを生成するステップと
を備える、オーサリング方法。
【請求項５】
前記第二の仮想イメージが選択されたとき、前記第一の実体イメージを前記第一のファイルシステムにマウントするステップと、
マウントされた前記第一の実体イメージのディレクトリ下に前記第二の実体イメージと前記素材データを配置するステップと
を更に備える、請求項４に記載のオーサリング方法。
【請求項６】
素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、前記素材データ自体を含まずに、前記素材データの記録位置を参照する第一の実体化用ファイルを生成する第一の実体化用ファイル生成部と、
前記素材データが時分割多重化された前記第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージをマウントするため、前記素材データ自体を含まずに、前記素材データの記録位置を参照する第二の実体化用ファイルを生成する第二の実体化用ファイル生成部と、
前記第一の実体化用ファイル及び前記第二の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して前記第一の仮想イメージを生成する第一の仮想イメージ生成部と
を備える、オーサリング装置。
【請求項７】
素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、前記素材データが時分割多重化された前記第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージ自体と前記素材データ自体を含まずに、前記素材データ及び前記第二の実体イメージの記録位置を参照する第三の実体化用ファイルを生成する第三の実体化用ファイル生成部と、
前記第三の実体化用ファイルを前記第一の仮想イメージのディレクトリ下に配置して前記第二の仮想イメージを生成する第二の仮想イメージ生成部と
を備える、オーサリング装置。
【請求項８】
素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、前記素材データ自体を含まずに、前記素材データの記録位置を参照する第一の実体化用ファイルを生成する手段、
前記素材データが時分割多重化された前記第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージをマウントするため、前記素材データ自体を含まずに、前記素材データの記録位置を参照する第二の実体化用ファイルを生成する手段、
前記第一の実体化用ファイル及び前記第二の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して前記第一の仮想イメージを生成する手段
としてコンピュータを機能させるためのプログラム。
【請求項９】
素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、前記素材データが時分割多重化された前記第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージ自体と前記素材データ自体を含まずに、前記素材データ及び前記第二の実体イメージの記録位置を参照する第三の実体化用ファイルを生成する手段、
前記第三の実体化用ファイルを前記第一の仮想イメージのディレクトリ下に配置して前記第二の仮想イメージを生成する手段
としてコンピュータを機能させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、オーサリング方法、オーサリング装置及びプログラムに関する。
【背景技術】
【０００２】
オーサリングシステムは、例えばブルーレイディスク（Blu-ray  Disc（登録商標）：以下「ＢＤ」)における再生専用光ディスク（ＢＤ-ＲＯＭ）等の製造において、光ディスクに記録されるコンテンツを作成する。
【０００３】
図３１を参照して、ＢＤ−ＲＯＭ等の再生専用光ディスクの製造までの流れを説明する。まず素材製作として、映像素材の撮影、音声素材の録音、編集等が行われる（ステップＳ１）。この撮影・編集等で得られたデータは、制作するコンテンツの素材データ（映像素材、音声素材、字幕データ等）として記憶媒体に格納される（ステップＳ２）。
【０００４】
記憶媒体に格納された各種素材データは、オーサリングスタジオに持ち込まれ、ディスクデータ（コンテンツ）制作に使用される。オーサリングスタジオでは、オーサリング処理用のプログラムがインストールされたパーソナルコンピュータや所要のハードウェアが用いられて、各種素材データを利用したコンテンツが制作される。
【０００５】
映像素材、音声素材はビデオエンコード、オーディオエンコードの各処理により、それぞれ所定の形式に符号化される。また、字幕データ等から、メニューデータ、字幕データ等が作成される（ステップＳ３）。次に、コンテンツの一部であるシナリオやメニューが作成される（ステップＳ４）。また、各種データが編集される（ステップＳ５）。
【０００６】
その後、マルチプレクサ処理（ステップＳ６）によって、コンテンツを構成するストリームデータが生成される。マルチプレクサ処理は、符号化された映像データや音声データ、メニューなどを多重化する。例えば、ハードディスク内等に格納された画像、音声、字幕などの符号化された素材データをインターリーブし、各種フォーマットファイルと合わせて多重化されたデータが作成される。後述するが、ここではクリップが作成されたり、ＵＤＦ（Universal  Disk  Format）イメージが作成されたりする。
【０００７】
最終的に作成された多重化データは、ディスク製造用のカッティングマスタとして、例えばパーソナルコンピュータ内のハードディスク等に格納される。そのカッティングマスタは、ディスク製造のために工場に送られる（ステップＳ７）。
【０００８】
工場では、プリマスタリング（ステップＳ８）として、データの暗号化やディスク記録データとしてのエンコード等の各種のデータ処理がされ、マスタリングデータが作成される。そして、マスタリング（ステップＳ９）として、ディスク原盤のカッティングからスタンパ作成までの工程が行われる。最後に、リプリケーション（ステップＳ１０）として、スタンパを用いてディスク基板が制作されて、ディスク基板上へ所定の層構造が形成され、完成品として光ディスク（ＢＤ−ＲＯＭ）が得られる。
【０００９】
オーサリングスタジオで行われている従来のオーサリング工程（ステップＳ３〜Ｓ６）を図３２に示す。このフローチャートは、特にマルチプレクサ処理（ステップＳ６）を詳しく示したものである。
【００１０】
上述のように、素材データ処理として、エンコード（ステップＳ３）が行われる（ステップＦ１）。また、オーサリング用アプリケーションによって、データが作成される。これは、上記ステップＳ４，Ｓ５のメニュー作成や編集等に該当する。そして、マルチプレクサ処理（ステップＳ６）として、ステップＦ３〜Ｆ１０が行われる。
【００１１】
まず、クリップが作成される（ステップＦ３）。ここで、クリップとは、素材データを時分割多重化したストリームデータである。
【００１２】
次に、クリップの再生が確認される（ステップＦ４）。即ち、クリップ段階で映像／音声がソフトウエアプレーヤで再生され、クリップの適否、素材選択の適否、メニュー等の適否等が確認される。
【００１３】
クリップの再生確認がＯＫとなったら、次に、ＵＤＦイメージが作成される（ステップＦ５）。ＵＤＦイメージは、クリップに、各種管理情報であるメタデータ等を付加したものである。図３３に、ＢＤ−ＲＯＭにおけるＵＤＦ（Universal  Disk  Format）イメージのディレクトリ構成例を示す。ここで「STREAM」ディレクトリにおけるm2tsファイルが、クリップである。
【００１４】
ＵＤＦイメージが作成されたら、エラーがチェックされる（ステップＦ６）。例えば、ＰＣ上でベリファイヤによる論理チェックなどが行われる。
【００１５】
エラーチェックがＯＫであれば、ＵＤＦイメージの再生が確認される（ステップＦ７）。即ち、ＵＤＦイメージがソフトウエアプレーヤ又はハードウエアエミュレータで再生され、ＵＤＦイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
【００１６】
ＵＤＦイメージの再生確認がＯＫであれば、ＢＤ−Ｒ（書込可能型ブルーレイディスク）に、ＵＤＦイメージによるコンテンツが書き込まれる（ステップＦ８）。これにより、実際に生産するＢＤ−ＲＯＭに近い光ディスクの状態をチェックできる。そして、ＢＤ−Ｒが再生され、内容が確認される（ステップＦ９）。ＢＤ−Ｒの再生確認がＯＫであれば、工場に転送するマスターデータであるカッティングマスタが作成される（ステップＦ１０）。
【００１７】
以上の処理において、ステップＦ４，Ｆ６，Ｆ７，Ｆ９の各段階で内容がチェックされる。もし、やり直しが必要と判断されたら、その修正を要する状況に応じて、ステップＦ１の素材データ段階、又はステップＦ２のシナリオ、メニュー等の作成、編集段階から、処理をやり直す。
【先行技術文献】
【特許文献】
【００１８】
【特許文献１】特開平７−７８１０２号公報
【発明の概要】
【発明が解決しようとする課題】
【００１９】
上記のオーサリング作業、特にマルチプレクサ処理においては、作業の効率化、高速化が求められている。
【００２０】
図３４にクリップ作成、ＵＤＦイメージ作成の作業を模式的に示している。ここで、Ｌドライブは、作業を行うパーソナルコンピュータによって用いられるハードディスク等である。Ｌドライブは、ＥＳ（Elementary  Stream）ファイル群を格納する。ＥＳファイルは、素材データのファイルである。また、Ｃドライブは、パーソナルコンピュータ内部のワーク領域である。
【００２１】
上述のように、クリップを作成する際、符号化された素材データ（ＥＳファイルの素材データ）が時分割多重化される。クリップ１００は、例えばＭＰＥＧ２方式のストリームデータである。クリップ１００は、図３４に示すように、４バイトのＴＰエクストラヘッダ（TP  extra  header）１０２と、管理情報である４バイトのパケットインフォメーション（Packet  information）１０３と、１８４バイトのアダプテーションフィールド／データフィールド（adaptation  field/data  field）１０１を含む。
【００２２】
アダプテーションフィールド／データフィールド（adaptation  field  /  data  field）１０１のデータフィールドには、ＥＳファイルの素材データがＰＥＳ（Packetized  Elementary  Stream）パケットで転送され、コピーされる。これらのコピーされる素材データは、かなり大容量となることが多く、マルチプレクサの処理時間は、データコピーに多く費やされて膨大なものとなる。
【００２３】
また、ＵＤＦイメージ２００は、クリップ１００にメタデータ２０１等を付加して作成される。そのため、ＵＤＦイメージ２００が作成される際も、大容量のクリップ１００がコピーされるため、膨大な時間を要する。
【００２４】
更に、図３２のフローチャートで示したようにクリップ１００やＵＤＦイメージ２００の再生を確認して、再生結果に不具合などがあれば、再度マルチプレクサの工程前まで戻ることも多々ある。すると、上記の素材データのコピーを何度もやり直す状況が発生することになる。このコピー処理時間は、データ量に比例し、１つの工程に数時間を要することもあった。
【００２５】
このようなことからオーサリング作業の長時間化が問題となっており、作業の効率化が求められている。なお、上記した特許文献１には、シミュレーションのターンアラウンドを短縮する技術が開示されているが、ディスク等に記録する実データの作成に関しての効率化は解決されていない。
【００２６】
そこで、本願の発明者らは、実体を持たない仮想ＵＤＦイメージを、ファイルシステムドライバによって、あたかも実体を持つＵＤＦイメージであるかのように扱える技術を発明し別途出願した。この技術では、実体を持つクリップやＵＤＦイメージ等のファイルは作成されず、ファイル作成のために大容量の素材データが加工されることもない。
【００２７】
一方、マルチプレクサ処理によって、仮想クリップや仮想ＵＤＦイメージを作成する。その結果、素材データのコピーが不要となり、従来、コピー処理のために長時間を要していた作業時間を著しく短縮する。そのため、マルチプレクサ処理にかかる時間を従来に比べて短縮できる。また、仮想クリップや仮想ＵＤＦイメージは、素材参照テーブルや仮想クリップ参照テーブルを利用して、テーブルで示される素材を直接読み取っていくことで実体化され再生される。このように、本技術によれば、オーサリング作業が格段に効率化された。
【００２８】
ところで、ＵＤＦ（Universal  Disk  Format）には、ＵＤＦ2.01やＵＤＦ2.5などの複数のバージョンが存在する。しかし、既存のあらゆるＯＳが、全てのファイルシステムやファイルシステムの全てのバージョンをサポートしているわけではなく、ファイルシステムやバージョンによってはＯＳによってサポートされていない場合がある。例えば、WindowsXP（登録商標）は、ＵＤＦ2.01までサポートしており、ＵＤＦ2.5をサポートしてない。
【００２９】
そのため、WindowsXP（登録商標）では、上記技術を用いてＵＤＦ2.5でファイルアロケーション処理されて生成された仮想ＵＤＦイメージ（以下、「仮想ＵＤＦ2.5イメージ」ともいう。）を扱うことができず再生できなかった。
【００３０】
WindowsXP（登録商標）上で仮想ＵＤＦ2.5イメージを扱えるようにするには、別途新たにデバイスドライバを開発し、そのデバイスドライバをWindowsXP（登録商標）が搭載されたＰＣ（パーソナルコンピューター）等にインストールする必要がある。しかし、ＯＳ毎の仕様に合わせて、デバイスドライバを開発すると、多大な手間やコストがかかる。また、ＰＣのＯＳ上に複数のＵＤＦ2.5に関するデバイスドライバがインストールされた場合、互換性を保証する必要が生じるなど、信頼性を維持するための技術が必要となる。
【００３１】
そこで、本発明は、上記問題に鑑みてなされたものであり、本発明の目的とするところは、ＯＳがサポートしていないファイルシステムによるファイルを、そのＯＳがサポートしているファイルシステム上で容易に扱うことが可能な、新規かつ改良されたオーサリング方法、オーサリング装置及びプログラムを提供することにある。
【課題を解決するための手段】
【００３２】
上記課題を解決するために、本発明のある観点によれば、素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、素材データ自体を含まずに、素材データの記録位置を参照する第一の実体化用ファイルを生成するステップと、素材データが時分割多重化された第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージをマウントするため、素材データ自体を含まずに、素材データの記録位置を参照する第二の実体化用ファイルを生成するステップと、第一の実体化用ファイル及び第二の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して第一の仮想イメージを生成するステップとを備えるオーサリング方法が提供される。
【００３３】
上記第一の仮想イメージが選択されたとき、第一の実体イメージを第一のファイルシステムに、又は第二の実体イメージを第二のファイルシステムにマウントするステップと、マウントされた第一の実体イメージ又は第二の実体イメージのディレクトリ下に素材データを配置するステップとを更に備えてもよい。
【００３４】
上記第一の実体イメージを第一のファイルシステムに、又は第二の実体イメージを第二のファイルシステムにマウントするステップは、オペレーティングシステムが、第一のファイルシステムのみに対応しているときは、第一の実体イメージを第一のファイルシステムにマウントし、オペレーティングシステムが、第一のファイルシステムと第二のファイルシステムの両方に対応しているときは、第二の実体イメージを第二のファイルシステムにマウントしてもよい。
【００３５】
また、上記課題を解決するために、本発明の別の観点によれば、素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、素材データが時分割多重化された第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージ自体と素材データ自体を含まずに、素材データ及び第二の実体イメージの記録位置を参照する第三の実体化用ファイルを生成するステップと、第三の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して第二の仮想イメージを生成するステップとを備えるオーサリング方法が提供される。
【００３６】
上記第二の仮想イメージが選択されたとき、第一の実体イメージを第一のファイルシステムにマウントするステップと、マウントされた第一の実体イメージのディレクトリ下に第二の実体イメージと素材データを配置するステップとを更に備えてもよい。
【００３７】
また、上記課題を解決するために、本発明の別の観点によれば、素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、素材データ自体を含まずに、素材データの記録位置を参照する第一の実体化用ファイルを生成する第一の実体化用ファイル生成部と、素材データが時分割多重化された第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージをマウントするため、素材データ自体を含まずに、素材データの記録位置を参照する第二の実体化用ファイルを生成する第二の実体化用ファイル生成部と、第一の実体化用ファイル及び第二の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して第一の仮想イメージを生成する第一の仮想イメージ生成部とを備えるオーサリング装置が提供される。
【００３８】
また、上記課題を解決するために、本発明の別の観点によれば、素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、素材データが時分割多重化された第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージ自体と素材データ自体を含まずに、素材データ及び第二の実体イメージの記録位置を参照する第三の実体化用ファイルを生成する第三の実体化用ファイル生成部と、第三の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して第二の仮想イメージを生成する第二の仮想イメージ生成部とを備えるオーサリング装置が提供される。
【００３９】
また、上記課題を解決するために、本発明の別の観点によれば、素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、素材データ自体を含まずに、素材データの記録位置を参照する第一の実体化用ファイルを生成する手段、素材データが時分割多重化された第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージをマウントするため、素材データ自体を含まずに、素材データの記録位置を参照する第二の実体化用ファイルを生成する手段、第一の実体化用ファイル及び第二の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して第一の仮想イメージを生成する手段としてコンピュータを機能させるためのプログラムが提供される。
【００４０】
また、上記課題を解決するために、本発明の別の観点によれば、素材データが時分割多重化された第一のファイルシステムのストリームデータ構造を有する第一の実体イメージをマウントするため、素材データが時分割多重化された第一のファイルシステムと異なる第二のファイルシステムのストリームデータ構造を有する第二の実体イメージ自体と素材データ自体を含まずに、素材データ及び第二の実体イメージの記録位置を参照する第三の実体化用ファイルを生成する手段、第三の実体化用ファイルを第一の仮想イメージのディレクトリ下に配置して第二の仮想イメージを生成する手段としてコンピュータを機能させるためのプログラムが提供される。
【発明の効果】
【００４１】
以上説明したように本発明によれば、ＯＳがサポートしていないファイルシステムによるファイルを、そのＯＳがサポートしているファイルシステム上で容易に扱うことができる。
【図面の簡単な説明】
【００４２】
【図１】本発明の一実施形態に係る仮想クリップ及び仮想ＵＤＦイメージを示す説明図である。
【図２】同実施形態に係るオーサリング工程を示すフローチャートである。
【図３】同実施形態に係るマルチプレクサモジュールを示す説明図である。
【図４】同実施形態で用いる素材データのディレクトリ構成例を示す説明図である。
【図５】同実施形態に係るクリップ生成時のディレクトリ構成例を示す説明図である。
【図６】同実施形態に係るＥＳ参照テーブルを構成するファイルを示す説明図である。
【図７】同実施形態に係るシークリストを示す説明図である。
【図８】ＵＤＦファイルシステムを示す説明図である。
【図９】従来のＵＤＦイメージ生成時のディレクトリ構成例を示す説明図である。
【図１０】従来のクリップ及びＵＤＦイメージを示す説明図である。
【図１１】本発明の一実施形態に係るＵＤＦイメージ生成時のディレクトリ構成例を示す説明図である。
【図１２】同実施形態に係る仮想クリップと仮想ＵＤＦイメージを示す説明図である。
【図１３】同実施形態に係るエクステントマップ例及びソースファイルリストを示す説明図である。
【図１４】同実施形態に係る仮想ＵＤＦイメージを実体のあるＵＤＦイメージにデコードした状態を示す説明図である。
【図１５】ＵＤＦイメージを示す説明図である。
【図１６】同実施形態に係るＣＰＴＢＬファイルを示す説明図である。
【図１７】同実施形態に係るカッティングマスタファイルを示す説明図である。
【図１８】同実施形態に係るVirtual  UDF  Imageの生成処理のフローチャートである。
【図１９】同実施形態に係るVirtual  Wrapping  UDF  Imageの生成処理のフローチャートである。
【図２０】同実施形態に係る仮想ＵＤＦイメージ生成時のディレクトリ構成例を示す説明図である。
【図２１】同実施形態に係るマウントサービスの構成を示す説明図である。
【図２２】ディスプレイ上のＵＩ画面を示す説明図である。
【図２３】同実施形態に係るマウント処理を示すフローチャートである。
【図２４】ディスプレイの画面上に表示されるウインドウを示す説明図である。
【図２５】ディスプレイの画面上に表示されるウインドウを示す説明図である。
【図２６】ディスプレイの画面上に表示されるウインドウを示す説明図である。
【図２７】同実施形態に係る実体化システムを示す説明図である。
【図２８】同実施形態に係る仮想イメージ実体化処理を示すフローチャートである。
【図２９】同実施形態に係る仮想クリップ実体化処理を示すフローチャートである。
【図３０】Virtual  UDF  Image及びVirtual  Wrapping  UDF  Imageの実体化処理を示すフローチャートである。
【図３１】ディスク製造の流れの説明図である。
【図３２】従来のオーサリング工程の説明図である。
【図３３】ＢＤ−ＲＯＭのディレクトリ構成例の説明図である。
【図３４】従来のクリップ・ＵＤＦイメージ作成の説明図である。
【発明を実施するための形態】
【００４３】
以下に添付図面を参照しながら、本発明の好適な実施の形態について詳細に説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複説明を省略する。
【００４４】
なお、説明は以下の順序で行うものとする。
１．システム動作概要
２．オーサリング工程
３．仮想クリップ
４．仮想ＵＤＦイメージ
５．カッティングマスタファイル
６．仮想ＵＤＦイメージの生成
７．ＵＤＦイメージのマウント
８．仮想クリップ・仮想ＵＤＦイメージの実体化
【００４５】
［１．システム動作概要］
本発明の一実施形態において、ディスク製造の全体の流れは、図３１で説明したものと同様である。本実施形態では、特にクリップを仮想化し、ＵＤＦイメージを仮想化することで、マルチプレクサ処理（図３１のＳ６）の効率化を実現する。
【００４６】
図１にマルチプレクサ処理の際に生成する仮想クリップ、仮想ＵＤＦイメージを模式的に示す。Ｌドライブは、作業を行うパーソナルコンピュータによって用いるハードディスク等である。Ｌドライブは、ＥＳ（Elementary  Stream）ファイル群を格納する。
【００４７】
マルチプレクサ処理の際には、まず仮想クリップ１０を作成する。従来は図３４で述べたように、実際の素材データがコピーされて、クリップ１００が生成されるが、本実施形態の場合、素材データを含まない仮想クリップ１０が生成される。
【００４８】
仮想クリップ１０は、図１に示すように、管理情報である４バイトのＴＰエクストラヘッダ（TP  extra  header）１２と、４バイトのパケットインフォメーション（Packet  information）１３と、ＥＳ参照テーブル１１とを有するファイル構造で形成される。本来、クリップは、ＭＰＥＧ２方式のストリームデータであり、ＰＥＳパケット単位の実データの集合である。しかし、本実施形態では、各ＰＥＳパケットは、そのＴＰエクストラヘッダ１２とパケットインフォメーション１３のみで表現されていると言える。そして、ＴＰエクストラヘッダ１２に対応する実素材データのポインタ情報が、ＥＳ参照テーブル１１に格納されている。つまり、仮想クリップ生成処理では、ＥＳファイルの実データはコピーされない。
【００４９】
仮想クリップ１０を実体化し再生する場合に、ＥＳ参照テーブル１１を用いて実際の素材データを特定し、ＥＳファイル群の中から読み取ってくる。
【００５０】
仮想ＵＤＦイメージ２０は、図１に示すように、管理情報であるメタデータ２２と、仮想クリップ参照テーブル２１とを有する。この仮想ＵＤＦイメージ２０も、素材データである実データはコピーされない。仮想クリップ参照テーブル２１によって、仮想的に実データが表現される。仮想ＵＤＦイメージ２０を実体化し再生する場合に、仮想クリップ参照テーブル２１を用いて、仮想クリップ１０のＥＳ参照テーブル１１を参照し、そのＥＳ参照テーブル１１を用いて実際のＥＳファイルを指定して、読み取る。
【００５１】
このように本実施形態では、大容量の素材データを加工したファイルを生成しない。本実施形態では、エンコードした素材データ（ＥＳファイル）を含まない仮想クリップ１０と仮想ＵＤＦイメージ２０を生成することでマルチプレクサ処理をする。そして、生成した仮想クリップ１０、仮想ＵＤＦイメージ２０を実体化し再生する際に、素材データ（ＥＳファイル）を直接読み取る。これにより、ハードディスク（Ｌドライブ）などの媒体のＩ／Ｏ部分で入出力されるデータ量を極力減らしてマルチプレクサ処理できる。
【００５２】
［２．オーサリング工程］
図３１のＳ３〜Ｓ６として示したオーサリングスタジオで行われる工程として、本実施形態のオーサリング工程を図２に示す。素材データ処理として、映像、音声等の素材データをエンコードして、素材データが符号化される（ステップＦ１０１）。符号化された素材データは、ＥＳファイルとして図１のＬドライブに格納される。
【００５３】
次に、オーサリングアプリケーションによってデータが作成される（ステップＦ１０２）。これは、図３１のＳ４，Ｓ５のメニュー作成や編集等に該当する。そして、マルチプレクサ処理（図３１のステップＳ６）として、ステップＦ１０３〜Ｆ１１０が行われる。
【００５４】
マルチプレクサ処理は、マルチプレクサモジュールとして機能するプログラムに基づいて行われる。このプログラムは、オーサリング作業に用いられるパーソナルコンピュータにおいて起動される。
【００５５】
なお、従来のマルチプレクサモジュールは、オーサリングスタジオに配布され、実際のディスクタイトル製作のために運用されている。そのため、たとえ処理速度が高速化したとしても、互換性がないものや、置き換えによって信頼性が落ちるものは、許容されない。そのため、本実施形態で導入する新たなマルチプレクサモジュールは、従来のマルチプレクサモジュールをコールしていたものと同じオーサリングアプリケーションや再生装置、ベリファイヤ（Verifier）が利用できるシステム設計を行うことが適切である。
【００５６】
本実施形態におけるマルチプレクサモジュールは、図３（ａ）に示すように、例えば、仮想クリップ生成部１と、メタデータ生成部２と、仮想ＵＤＦイメージ／カッティングマスタ生成部３から構成される。
【００５７】
仮想クリップ生成部１は、ＭＰＥＧ２トランスポートストリームフォーマットのクリップファイルを仮想的に生成する。
【００５８】
メタデータ生成部２は、ディスクに記録するメタデータを生成する。
【００５９】
仮想ＵＤＦイメージ／カッティングマスタ生成部３は、仮想的にＵＤＦイメージを作成し、またカッティングマスタを作成する。マルチプレクサモジュールは、ＤＬＬ（ダイナミックリンクライブラリ）であり、オーサリングアプリケーションと動的にリンクして実行される。オーサリングアプリケーションは、オーサリングスタジオで使用されるソフトウェアである。従来のマルチプレクサモジュールからこのＤＬＬを置き換えるだけで、使用中のシステムへ本実施形態に係るシステムを導入できる。
【００６０】
なお、本実施形態のマルチプレクサモジュールとして機能するプログラムは、パーソナルコンピュータ等の機器に内蔵されている記録媒体であるＨＤＤ、ＲＯＭ、フラッシュメモリ等に予め記録されている。または、フレキシブルディスク、ＣＤ−ＲＯＭ(Compact  Disc  Read  Only  Memory)、ＭＯ(Magneto-optical)ディスク、ＤＶＤ、ブルーレイディスク、磁気ディスク、半導体メモリ、メモリカードなどのリムーバブル記録媒体に、一時的あるいは永続的に格納（記録）される。このようなリムーバブル記録媒体は、いわゆるパッケージソフトウェアとして提供されてもよい。また、プログラムは、リムーバブル記録媒体からパーソナルコンピュータ等にインストールされてもよいし、ダウンロードサイトから、ＬＡＮ(Local  Area  Network)、インターネットなどのネットワークを介してダウンロードされてインストールされてもよい。
【００６１】
そして、仮想クリップ生成部１によって、仮想クリップ１０が作成される（ステップＦ１０３）。本来、クリップとは、素材データを時分割多重したストリームデータである。例えば図３（ｂ）に示すように、エレメンタリストリーム（ＥＳ）である素材データ（映像、音声、ＩＧ（Interactive  Graphics）、ＰＧ（Presentation  Graphics）、テキストサブタイトル）等がマルチプレクスされて、トランスポートストリーム（ＴＳ）であるクリップが生成される。
【００６２】
本実施形態の場合、実際の素材データはコピーされずに、図１に示したように、ＴＰエクストラヘッダ１２と、パケットインフォメーション１３と、ＥＳ参照テーブル１１とを有するファイル構造で、仮想クリップ１０が生成される。
【００６３】
次に、仮想クリップ１０の再生が確認される（ステップＦ１０４）。即ち、クリップ段階で映像／音声がソフトウエアプレーヤで再生され、クリップの適否、素材選択の適否、メニュー等の適否等が確認される。
【００６４】
仮想クリップ１０によるクリップ内容の再生確認がＯＫとなったら、次に、仮想ＵＤＦイメージ／カッティングマスタ生成部３によって、仮想ＵＤＦイメージ２０が作成される（ステップＦ１０５）。本来のＵＤＦイメージは、クリップに、各種管理情報であるメタデータ等を付加したものである。本実施形態では、ＵＤＦイメージを仮想的に生成する。メタデータはメタデータ生成部２によって作成される。
【００６５】
仮想ＵＤＦイメージ２０は、図１に示すようにメタデータ２２と、仮想クリップ参照テーブル２１を含む。なお、仮想ＵＤＦイメージ／カッティングマスタ生成部３によって、カッティングマスタファイル（ＣＭＦ）の一部のデータも同時に作成される。例えば、コントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどが作成される。
【００６６】
仮想ＵＤＦイメージ２０が作成されたら、エラーがチェックされる（ステップＦ１０６）。例えば、ＰＣ上でベリファイヤによる論理チェックなどが行われる。
【００６７】
エラーチェックがＯＫであれば、仮想ＵＤＦイメージ２０の再生が確認される（ステップＦ１０７）。即ち、仮想ＵＤＦイメージ２０における仮想クリップ参照テーブル２１、及びＥＳ参照テーブル１１に基づいて、仮想ＵＤＦイメージ２０が実体化され、ＵＤＦイメージファイルの適否、素材選択の適否、メニュー等の適否等が確認される。
【００６８】
本実施形態では、ＰＣ上のＯＳがサポートしているＵＤＦのバージョンに合わせて、仮想ＵＤＦイメージ２０が実体化されるように、仮想ＵＤＦイメージ２０が生成されている。例えば、WindowsXP（登録商標）で仮想ＵＤＦイメージ２０を実体化した場合、ＵＤＦ2.01のファイルシステムにＵＤＦイメージがマウントされる。このとき、WindowsVISTA（登録商標）で仮想ＵＤＦイメージを生成する場合でも、WindowsXP（登録商標）で仮想ＵＤＦイメージ２０を実体化できる。
【００６９】
なお、本実施形態では、２種類の仮想ＵＤＦイメージ２０、即ち（１）Virtual  UDF  Imageと（２）Virtual  Wrapping  UDF  Imageについて説明する。（１）のVirtual  UDF  ImageがＵＤＦ2.01のみに対応したＯＳで実体化された場合、ＵＤＦ2.01のファイルシステムにＵＤＦイメージがマウントされる。そして、実体化されたＵＤＦイメージ下の実体化されたクリップを扱うことができる。なお、（１）のVirtual  UDF  ImageがＵＤＦ2.5に対応したＯＳで実体化された場合、ＵＤＦ2.5のファイルシステムにＵＤＦイメージがマウントされる。そして、実体化されたＵＤＦイメージ下の実体化されたクリップを扱うことができるようにしている。
【００７０】
また、（２）のVirtual  Wrapping  UDF  Imageが、ＵＤＦ2.01のみに対応したＯＳで実体化された場合、ＵＤＦ2.01のファイルシステムにＵＤＦイメージがマウントされる。そして、実体化されたＵＤＦイメージ下の実体化されたクリップ及びＵＤＦ2.5のＵＤＦイメージを扱うことができる。
【００７１】
次に、仮想ＵＤＦイメージ２０の再生確認がＯＫであれば、ＢＤ−Ｒ（書込可能型ブルーレイディスク）に、仮想ＵＤＦイメージ２０によるコンテンツが書き込まれる（ステップＦ１０８）。これにより、実際に生産するＢＤ−ＲＯＭに近い光ディスクの状態をチェックできる。この場合、仮想クリップ参照テーブル２１及びＥＳ参照テーブル１１に基づいて、書き込みデータとしてのストリームが形成され、ＢＤ−Ｒへストリームが書き込まれる。そして、ＢＤ−Ｒが再生され、内容が確認される（ステップＦ１０９）。
【００７２】
ＢＤ−Ｒの再生確認がＯＫであれば、仮想ＵＤＦイメージ／カッティングマスタ生成部３によって、工場に転送するマスターデータであるカッティングマスタが作成される（ステップＦ１１０）。即ち、仮想ＵＤＦイメージから実体化されたＵＤＦイメージが作成され、さらに上記のコントロールデータファイル、暗号化テーブルファイル、物理情報ファイルなどが付加されて、カッティングマスタファイルが作成される。
【００７３】
以上の処理において、ステップＦ１０４，Ｆ１０６，Ｆ１０７，Ｆ１０９の各段階で内容がチェックされる。もし、やり直しが必要と判断されたら、内容修正を行う。即ち、その修正を要する状況に応じて、ステップＦ１０１の素材データ段階、又はステップＦ１０２のシナリオ、メニュー等の作成又は編集段階から、処理をやり直すことになる。
【００７４】
以下では、この図２の処理で作成される仮想クリップ１０、仮想ＵＤＦイメージ２０の内容、さらにはこれらの再生動作、ＢＤ−Ｒへの書込について説明する。
【００７５】
［３．仮想クリップ］
先に述べたように従来では、クリップとして素材データの実体をコピーしたクリップが生成されていたところ、本実施形態では、素材データの実体を含まない仮想クリップ１０が生成される。従来のクリップファイルと比較しながら、本実施形態の仮想クリップ１０について説明する。
【００７６】
まず、図４は、図１のＬドライブにＥＳファイルとして格納される素材データに関するディレクトリの構成を示している。図４のように、「ESData」ディレクトリ下に「VIDEO」「AUDIO」ディレクトリが配置される。そして「VIDEO」下に「MPEG2」「AVC」ディレクトリが配置され、「MPEG2」下に「MOVIE1」「MOVIE2」等のディレクトリが配置される。「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」が、図１に示したＥＳ参照テーブル１１を構成する。
【００７９】
各ファイルを説明する。
・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ファイルに示される。
【００８３】
・Packetinfo（パケットインフォファイル）
図６（ｃ）にパケットインフォファイル（Packetinfo）を示す。パケットインフォファイルは、先頭から１バイトずつがパケットベースファイル中のＴＳパケットのサイズを示す。
実データとしてのＴＳパケットは、図６（ａ）のように１９２バイトである。しかし、図６（ｂ）のようにパケットベースにはデータフィールドが存在しないＴＳパケットもある。ＴＳパケットの最小サイズは、図６（ｂ）の３行目のようにＴＰエクストラヘッダとパケットインフォメーションを合わせた８バイトである。このため、パケットインフォファイルの各バイトは、８〜１９２バイトの範囲で、パケットベースファイル中の各ＴＳパケットのサイズを示す。
【００８４】
・ES.list（ＥＳリストファイル）
ＥＳリストには、ＴＳパケットのパケットベース以外のデータ部分の参照元のファイル名とＰＩＤの関係を示すテキストファイルが記述される。
フォーマットは、
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」ファイルに至るパスが記述される。
【００８６】
つまり、パケットベース内の或るＴＳパケットにおけるパケットインフォメーションに示されているＰＩＤに対応して、例えば図６（ａ）、図６（ｅ）の関係のように、本来データフィールドにコピーされるべきＥＳファイルが示される。つまり、仮想クリップを再生する時に読み出されるべき、ＥＳファイルが示される。
【００８７】
・Seek.lst（シークリストファイル）
シークリストファイルは、シーク用の情報を示すファイルである。上記の他の３つのファイルでもデコードは可能であるが、シーク情報を追加することによって高速シークに対応できる。実際に、仮想クリップ１０の映像などを再生するときには、このシーク情報がないと再生が間に合わない場合も生ずる。
【００８８】
シークリストファイルには、ＰＩＤごとの対応のフォーマットで例えば、１００ＳＰＮ（Source  Packet  Number）として１９２００バイトごとのポジション情報が記述されている。例えば図７に示すように、先頭に「version」として、この構成（フォーマット）のバージョン番号（例えば「0x00000001」）が示される。次に、「SPN  interval」としてインターバル値が示される。ここで「0x0064」＝１００であり、１００ＳＰＮ間隔であることが示されている。また「PID  Count」としてＰＩＤ（素材に割り振られる個体番号）の個数が示される。以降は、１００ＳＰＮ毎のリストが続く。
【００８９】
リスト内では、ＴＳパケットのヘッダファイル(パケットベース)のポジションが示される。例えば図では「０Ａ１８」としているが、これによってパケットベースの位置が示される。また、ＰＩＤに対応するＥＳファイルのポジションが示される。例えば図のように「００Ａ５」として、ＰＩＤ＝１０１１とされた素材ファイル内の位置が示される。
【００９０】
シークの例を説明する。
仮に１９２００ｂｙｔｅからデータを読み出したい場合、シークリストファイルの２つめのリストを読み込む。そしてパケットベースの位置「０Ａ１８」に基づいてパケットベースファイルを参照する。またＰＩＤに対応するＥＳファイルのポジションを読み込む。そして例えば「００Ａ５」として、素材ファイル内の位置を確認し、素材ファイル（ＥＳファイル）を読み出す。
【００９１】
以上の各ファイルで構成される仮想クリップ１０に基づくデータの読み込みは次の（Ｐ１）〜（Ｐ６）のように行われる。
（Ｐ１）パケットインフォファイルを１バイト読む。（「Ａ」とする）
（Ｐ２）パケットベースファイルから（Ａ）バイト数読み込む。（「Ｂ」とする）
（Ｐ３）（（Ｂ）［５］＆１Ｆ）＜＜８＋（Ｂ）［６］（ＴＳパケット中のＰＩＤの位置）（「Ｃ」とする）
（Ｐ４）ＥＳリストファイルのＰＩＤと（Ｃ）が一致するファイルから、１パケットサイズは１９２バイト固定であることから、（１９２-（Ａ））バイト読み込む。（「Ｄ」とする）
（Ｐ５）（Ｂ）のバイト列と（Ｄ）のバイト列を結合したものをファイルとして出力する。
（Ｐ６）上記（Ｐ１）に戻る。
これをパケットインフォファイルの終了まで繰り返す。
よって、復元されたファイルのサイズは、ファイルのサイズ＝（パケットベースファイルサイズ）×１９２となる。
【００９２】
以上のように仮想クリップ１０は、ＴＰエクストラヘッダ１２と、パケットインフォメーション１３と、ＥＳ参照テーブル（「Packetbase」「Packetinfo」「Seek.lst」「ES.List」）１１とを有するファイル構造で形成される。この場合、ＭＰＥＧ２方式のストリームデータであり、ＰＥＳパケット単位の実データの集合であるクリップが、仮想的に表現される。そして、仮想クリップ生成時には大容量のＥＳファイルデータのコピーは行われないため、作成時間は非常に短縮される。また、仮想クリップ１０の再生時には、ＥＳ参照テーブル１１が用いられて、実際のＥＳファイルデータが特定され、ＥＳファイル群の中から実際のデータが読み取られ仮想クリップ１０が再生される。
【００９３】
［４．仮想ＵＤＦイメージ］
次に仮想ＵＤＦイメージ２０について説明する。
図３（ａ）に示したマルチプレクサモジュールは、仮想クリップ生成部１によって生成された仮想クリップ１０や、メタデータ生成部２によって生成されたメタデータ２２に基づいて、仮想ＵＤＦイメージ／カッティングマスタ生成部３が仮想ＵＤＦイメージ２０を生成する。これは、図２のステップＦ１０５の処理である。
【００９４】
一例としてＵＤＦ1.02ブリッジファイルシステムを図８に示す。ＵＤＦは、管理情報（メタデータ）とファイル実体に分けて考える。
【００９５】
まず比較のため、従来のＵＤＦイメージが生成されたときのＰＣ上のディレクトリの構成の一例を図９に示す。
図９において実体ファイルである「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」のディレクトリ下に配置される。
【００９７】
ここで図９に示す構成において、「ImageFile0」「ImageFile1」「CPTBL0」「CPTBL1」「UCD0」「UCD1」といった各ファイルは、実体ファイルである「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」の各ファイルが配置される。以下、「ImageFile0」「ImageFile1」ディレクトリ下のこれらのファイルを総称して実体化用ファイル群ともいう。「Extent.map」「SourceFileList.map」が、図１を用いて説明した仮想クリップ参照テーブル２１を構成する。
【０１０１】
なお、仮想ＵＤＦイメージ２０は、上述したように（１）Virtual  UDF  Imageと（２）Virtual  Wrapping  UDF  Imageがある。Virtual  UDF  Imageは、下記のように、ＵＤＦ2.01とＵＤＦ2.5のそれぞれの実体化用ファイル群を含む。
0201_Extent.map
0201_SourceFileList.map
0201_UDF_Footer.map
0201_UDFHeader.map
0201_UDFMetadata.map
0201_UDFMetadataMirror.map
0250_Extent.map
0250_SourceFileList.map
0250_UDF_Footer.map
0250_UDFHeader.map
0250_UDFMetadata.map
0250_UDFMetadataMirror.map
【０１０２】
一方、Virtual  Wrapping  UDF  Imageは、ＵＤＦ2.01のみの実体化用ファイル群を含む。
0201_Extent.map
0201_SourceFileList.map
0201_UDF_Footer.map
0201_UDFHeader.map
0201_UDFMetadata.map
0201_UDFMetadataMirror.map
上記ファイルでは、0201であればＵＤＦ2.01に対応し、0250であればＵＤＦ2.50に対応することを示す。
【０１０３】
また、「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」ファイルが物理的にインターリーブされて配置される場合などにおける各ブロックの論理アドレスとバイトサイズが記録されている。
【０１０７】
「m2ts」ファイルが物理的にインターリーブされて配置されない場合、再生パスのあるxxxxx.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
【０１１０】
なお、（１）Virtual  UDF  Imageと（２）Virtual  Wrapping  UDF  Imageについて説明する。（１）のVirtual  UDF  Imageは、光ディスクドライブ（例えばＢＤ−ＲＯＭ，ＢＤ−Ｒ又はＢＤ−ＲＥ等）に最終的に書き込むためのイメージファイルであり、光ディスク上で再生されることを前提としている。そのため、Virtual  UDF  Imageでは、ファイルの物理的配置を考慮する必要がある。従って、各ファイルがインターリーブされて交互にレイアウトされている場合、上述したエクステント情報が実体化ファイル群に含まれる。
【０１１１】
一方、（２）のVirtual  Wrapping  UDF  Imageは、Virtual  UDF  Imageと異なり、実体化されマウントされた各ファイルがディレクトリ展開されＰＣのＨＤＤ上に配置され、ソフトウエアプレーヤなどで再生されることを目的としている。そのため、ファイルの物理的配置を考慮する必要がなく、ＵＤＦ2.5のＵＤＦイメージ以外のクリップ等の各ファイルの位置情報は不要である。Virtual  Wrapping  UDF  Imageでは、ＵＤＦ2.5のＵＤＦイメージ以外のクリップ（「m2ts」ファイル）等の各ファイルは、一つのエクステントとして実体化ファイル群に含まれる。Virtual  Wrapping  UDF  Imageがディレクトリに展開されたときは、ＰＣ上のディスク上でのレイアウトは問題でなく、クリップはxxxxx.m2tsという、ひとつのファイルとして扱われるためである。
【０１１２】
・SourceFileList.map（ソースファイルリストマップ）
ソースファイルリストマップは、ファイルそれぞれの実体データについてＰＣ上の絶対ファイルパスが記録されている。ソースファイルリストマップの例を図１３（ｂ）に示す。ソースファイルリストマップには、図１３（ｂ）に示すように、ファイルバージョン、リスト数が記述され、「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
【０１１４】
ソースファイルリストマップには、実体化されて生成されるファイル、例えばクリップ等がリストアップされている。２種類の仮想ＵＤＦイメージ２０、（１）Virtual  UDF  Imageと（２）Virtual  Wrapping  UDF  Imageのうち、（１）のVirtual  UDF  Imageでは、リストアップされたファイル群の中にクリップ等は含まれるが、ＵＤＦ2.5のＵＤＦイメージが含まれない。一方、（２）のVirtual  Wrapping  UDF  Imageには、リストアップされたファイル群の中にクリップ等に加えてＵＤＦ2.5のＵＤＦイメージが含まれる。
例えば、ＵＤＦ2.5のＵＤＦイメージの情報として、次のように記述される。
SAMPLEIMAGE：C:\SAMPLEIMAGE\ImageFile0
【０１１５】
これにより、（１）のVirtual  UDF  Imageが実体化され、ＵＤＦイメージがマウントされたとき、実体化されたＵＤＦイメージ下には実体化されたクリップは含まれるがＵＤＦ2.5のＵＤＦイメージが含まれない。一方、（２）のVirtual  Wrapping  UDF  Imageが実体化されるとき、ＵＤＦ2.5のＵＤＦイメージが参照される。その結果、ＵＤＦイメージがマウントされたとき、実体化されたＵＤＦイメージ下には実体化されたクリップに加えてＵＤＦ2.5のＵＤＦイメージが含まれる。その結果、ＵＤＦ2.01のファイルシステムにおいて、ＵＤＦ2.5のＵＤＦイメージを扱うことができる。
【０１１６】
なお、仮想ＵＤＦイメージ２０を実体化する際、リストアップされたファイル、例えばxxxxx.m2tsやSAMPLEIMAGEが実体のあるファイルではなく、ディレクトリであるとき、実体のあるファイルではなく、仮想ファイルであると判断できる。
【０１１７】
「ImageFile0」「ImageFile1」等のディレクトリ下に配置される「UDFHeader.map」「UDFFooter.map」「UDFMetadata.map」「UDFMetadataMirror.map」の各ファイルは、ＵＤＦの管理情報用ファイルである。これらのファイルには、図１４に示す例ではxxxxx.m2ts以外の仮想化されていない情報が入る。図１５にＵＤＦイメージファイルを示す。図示しないが、ＵＤＦ2.01イメージファイルは、図１５と異なる構成を有している。
【０１１８】
「UDFHeader.map」ファイルは、ＵＤＦイメージ内のボリュームシーケンス（Volume  Sequence）（Anchorを含む）のデータである。
「UDFFooter.map」ファイルは、ＵＤＦイメージ内のリザーブボリュームシーケンス（Reserve  Volume  Sequence）（Anchorを含む）のデータである。
「UDFMetadata.map」ファイルは、ＵＤＦイメージ内のメタデータ（Metadata）のファイルである。
「UDFMetadataMirror.map」は、ＵＤＦイメージ内のメタデータミラー（Metadata  Mirror）のファイルである。
【０１１９】
仮想ＵＤＦイメージ２０を再生する場合、エクステントマップファイルによって各ファイルが指定され、ソースファイルリストマップによって、各ファイルのパスが判別される。各ファイルのパスは、仮想クリップ１０内のディレクトリ（「00001.m2ts」「00002.m2ts」「00003.m2ts」等）を指す。上述したように、これらの仮想クリップ１０内のディレクトリ（「00001.m2ts」「00002.m2ts」「00003.m2ts」等）には、ＥＳ参照テーブル１１を構成するファイルが配置されている。このため、上述した（Ｐ１）〜（Ｐ６）の手順で仮想クリップ１０に基づいて素材データが読み出される。
【０１２０】
なお、「UCD0」「UCD1」ディレクトリ下の「Extent.map」ファイルは図１６（ａ）のように構成される。「Extent.map」ファイルには、ＵＣＤマップＩＤ、バージョンナンバ、ＵＣＤファイルサイズ、レイヤオフセットＬＳＮ、ＵＣＤアイテムサイズが記述される。そして、ＵＣＤのエクステント情報として、エクステントナンバー毎に、開始ＬＳＮ、ブロック数、データが記述される。
【０１２１】
また、「CPTBL0」「CPTBL1」ディレクトリ下の「Extent.map」ファイルは図１６（ｂ）のように構成される。「Extent.map」ファイルには、ＣＰＴマップＩＤ、バージョンナンバ、ＣＰＴＢＬファイルサイズ、ヘッダーサイズ、レイヤオフセットＬＳＮが記述される。そして、ＣＰＴのエクステント情報として、エクステントナンバー毎に、開始ＬＳＮ、ブロック数、クリップナンバ等が記述される。
【０１２２】
「CPTBL0」「CPTBL1」ディレクトリ下の「Header」ファイルは、図１７に示すように、ジェネラルブロックデータ、ロケーションブロックデータを含む。
【０１２３】
以上のように、仮想ＵＤＦイメージ２０は、仮想クリップ参照テーブル（「Extent.map」「SourceFileList.map」）２１によって、仮想的に実データが表現される。仮想ＵＤＦイメージ作成時にはＥＳファイルの実データはコピーされない。従って、仮想ＵＤＦイメージ２０の作成時間は著しく短縮される。仮想ＵＤＦイメージ２０を再生すると、仮想クリップ参照テーブル２１から、仮想クリップ１０のＥＳ参照テーブル１１が参照され、そのＥＳ参照テーブル１１から実際のＥＳファイルが指定されて、データが読み出される。
【０１２４】
［５．カッティングマスタファイル］
本実施形態のマルチプレクサモジュールでは、仮想ＵＤＦイメージ／カッティングマスタ生成部３は、ＵＤＦイメージのほかに、ディスクプラントでディスク生成に必要なカッティングマスタファイルも生成する。
カッティングマスタの例としては、次のようなファイルがある。
・ＵＤＦイメージファイル
・コントロールデータファイル
・暗号化テーブルファイル
・物理情報ファイル
【０１２５】
ＵＤＦイメージファイルは上述のように高速化処理が行われる。コントロールデータファイル、暗号化テーブルファイルも、圧縮した形でマルチプレクサから出力することによって高速化を行う。例えば、コントロールデータファイルは、イメージファイルの１０２４分の１８のサイズがあるが、全てゼロデータであるとき、ファイルサイズ４バイトまで圧縮を行うことができる。これらのカッティングマスタファイルへの復号は、次の工程のディスクプラント転送（通称ダウンローダ）によって行われる。ダウンローダは、ディスクプラントへの出荷時１回だけ実施されるため、この工程によるオーサリングスタジオでのワークフロー全体から見るとオーバーヘッドは少ない。
【０１２６】
［６．仮想ＵＤＦイメージの生成］
次に、仮想ＵＤＦイメージ２０の生成について説明する。
ここでは、２種類の仮想ＵＤＦイメージ２０、即ち（１）Virtual  UDF  Imageと（２）Virtual  Wrapping  UDF  Imageの生成について説明する。
【０１２７】
まず、「FSImage0.img」という名称のディレクトリのVirtual  UDF  Imageが生成される場合について説明する。図１８は、本実施形態に係るVirtual  UDF  Imageの生成処理のフローチャートである。
【０１２８】
Virtual  UDF  Imageの生成が開始されると、素材データを参照して、ＵＤＦ2.01のファイルシステムでファイルアロケーション処理がされる（ステップＳ１０１）。そして、ＵＤＦ2.01に実体化するときに必要な実体化用ファイル群が生成され、FSImage0.imgディレクトリ下にコピーされる（ステップＳ１０２）。また、素材データを参照して、ＵＤＦ2.5のファイルシステムでファイルアロケーション処理がされる（ステップＳ１０３）。そして、ＵＤＦ2.5に実体化するときに必要な実体化用ファイル群が生成され、FSImage0.imgディレクトリ下にコピーされる（ステップＳ１０４）。
【０１２９】
その結果、FSImage0.imgディレクトリは、下記のように、ＵＤＦ2.01とＵＤＦ2.5のそれぞれの実体化用ファイル群を含む。
0201_Extent.map
0201_SourceFileList.map
0201_UDF_Footer.map
0201_UDFHeader.map
0201_UDFMetadata.map
0201_UDFMetadataMirror.map
0250_Extent.map
0250_SourceFileList.map
0250_UDF_Footer.map
0250_UDFHeader.map
0250_UDFMetadata.map
0250_UDFMetadataMirror.map
【０１３０】
上記ファイルでは、0201であればＵＤＦ2.01に対応し、0250であればＵＤＦ2.50に対応することを示す。Virtual  UDF  Imageが、ＵＤＦ2.01のみに対応したＯＳで実体化されると、ＵＤＦ2.01のファイルシステムにＵＤＦイメージがマウントされる。また、Virtual  UDF  Imageが、ＵＤＦ2.01とＵＤＦ2.5の両方に対応したＯＳで実体化されると、ＵＤＦ2.5を優先するようにして、ＵＤＦ2.5のファイルシステムにＵＤＦイメージがマウントされる。
【０１３１】
次に、「Wrapping.img」という名称のディレクトリのVirtual  Wrapping  UDF  Imageが生成される場合について説明する。図１９は、本実施形態に係るVirtual  Wrapping  UDF  Imageの生成処理のフローチャートである。
【０１３２】
Virtual  Wrapping  UDF  Imageの生成が開始されると、素材データを参照して、ＵＤＦ2.01のファイルシステムでファイルアロケーション処理がされる（ステップＳ２０１）。そして、ＵＤＦ2.01に実体化するときに必要な実体化用ファイル群が生成され、Wrapping.imgディレクトリ下にコピーされる（ステップＳ２０２）。
【０１３３】
その結果、Wrapping.imgディレクトリは、下記のように、ＵＤＦ2.01のみの実体化用ファイル群を含む。
0201_Extent.map
0201_SourceFileList.map
0201_UDF_Footer.map
0201_UDFHeader.map
0201_UDFMetadata.map
【０１３４】
Wrapping.imgディレクトリ下の0201_SourceFileList.mapには、リストアップされたファイル群の中にＵＤＦ2.5のＵＤＦイメージが含まれる。そのため、Virtual  Wrapping  UDF  Imageが実体化されて、ＵＤＦ2.01のファイルシステムにＵＤＦイメージがマウントされたとき、実体化されたＵＤＦイメージ下にはＵＤＦ2.5のＵＤＦイメージが含まれる。
【０１３５】
以上、説明した処理によって、例えば、Ｃドライブには、図２０に示すように、仮想クリップ１０として、0001.m2ts等のVirtual  m2ts  fileが生成され、仮想ＵＤＦイメージ２０として、Virtual  UDF  ImageとVirtual  Wrapping  UDF  Imageが生成される。図２０は、仮想ＵＤＦイメージ生成時のディレクトリ構成例を示す説明図である。
【０１３６】
［７．ＵＤＦイメージのマウント］
次に、ＵＤＦイメージのマウントについて説明する。
本実施形態に係るマウントサービス（Mount  Service）は、図２１に示すように、デバイスドライバと、ＤＬＬと、サービスプログラムと、アプリケーションから構成される。ここで、ＤＬＬは、図示しないが、デバイスドライバとアプリケーションを仲介するものである。そして、ＤＬＬとアプリケーションとの間にサービスプログラムが配置される。
【０１３７】
すなわち、アプリケーション→サービスプログラム→マウントサービスのＤＬＬ→デバイスドライバという構成になる。なお、サービスプログラムを含まず、アプリケーション→マウントサービスのＤＬＬ→デバイスドライバという構成でもよい。デバイスドライバは、Administrator権限を持つユーザー以外を制限する機能を用いて動作するため、サービスプログラムを独立させてある。そのため、後者の構成では、アプリケーションは、Administrator権限を持つユーザーでしか実行できない。一方、前者の構成では、サービスプログラムをAdministrator権限で動作させることにより、Administrator権限を持たないユーザーでもアプリケーションを実行できる。
【０１３８】
次に、マウントサービスによるマウント動作について説明する。
まず、マウントサービスを実施するアプリケーションにおいて、仮想ＵＤＦイメージ２０が指定されることで開始される。図２２に、仮想ＵＤＦイメージ２０をマウントするために使用されるＰＣ等に接続されたディスプレイ上のＵＩ画面を示す。
【０１３９】
まず、ＰＣ上にマウントするＵＤＦイメージのパスが欄１０１内に指定される。そして、図２２のプルダウンメニュー１０２による選択で、ＵＤＦイメージのマウント先が指定される。図２２では、Ｍドライブが指定された例であり、マウントが実行されると、ＵＤＦイメージはＭドライブにマウントされる。
【０１４０】
マウント先が指定されたのちは、Mountボタン１０３がユーザーによってクリックされる。この一連の操作によって、マウントが開始される。図２３は、本実施形態に係るマウント処理を示すフローチャートである。
【０１４１】
マウントサービスによるマウントが開始されると、指定されたＵＤＦイメージが仮想ＵＤＦイメージであるか否かがアプリケーションによって判断される（ステップＳ３０１）。
【０１４２】
指定されたＵＤＦイメージが仮想ＵＤＦイメージである場合、図２１のReader/SSDLLによって実体化処理がされる（ステップＳ３０２）。Reader/SSDLLは、アプリケーションと動的にリンクして実行され、実体化処理を行う。実体化処理については後述する。そして、指定されたＵＤＦイメージが仮想ＵＤＦイメージである場合は、実体化されたＵＤＦイメージをマウントする（ステップＳ３０３）。
【０１４３】
一方、指定されたＵＤＦイメージが実体のあるＵＤＦイメージである場合も、指定されたドライブにそのＵＤＦイメージをマウントする（ステップＳ３０３）。
【０１４４】
なお、図２２に示すマウントサービスを実施するアプリケーションのＵＩ画面では、ボタン１０３に現在の状態から次に起こすことになるアクションが表示されている。従って、ボタン１０３がクリックされると、ボタン１０３に表示されたアクションが実行される。即ち、図２２に示すように、マウントされている状態では、ボタン１０３には「UnMount  Image」と表示されていて、ボタン１０３がクリックされるとアンマウントが実施される。逆に、アンマウントされている状態では、ボタン１０３には「Mount  Image」と表示されていて、ボタン１０３がクリックされるとマウントが実施される。
【０１４５】
次に、図２４〜２６を参照して、（１）Virtual  UDF  Image又は（２）Virtual  Wrapping  UDF  Imageのマウント例について説明する。図２４〜２６は、ＰＣ等に接続されたディスプレイの画面上に表示されるウインドウを示す説明図である。
【０１４６】
仮想ＵＤＦイメージ２０がマウントされると、ＰＣ上には、実体のあるＵＤＦイメージがマウントされる。図２４に示すように、Virtual  UDF  Imageをマウント処理すると、Real  ImageがＰＣ上にマウントされ、Virtual  Wrapping  UDF  Imageをマウント処理すると、Wrapping  Real  ImageがＰＣ上にマウントされる。そして、図２５に示すように、Real  Image  Wrapping又はReal  Image下には、実体のあるディレクトリと、そのディレクトリに含まれる実体のあるファイルが配置される。
【０１４７】
また、Virtual  Wrapping  UDF  Imageがマウント処理された結果、マウントされるWrapping  Real  Image下には、図２６に示すように、実体のあるファイルを含む実体のあるディレクトリと、実体のあるＵＤＦイメージ（Real  Image  file）が配置される。
【０１４８】
［８．仮想クリップ・仮想ＵＤＦイメージの実体化］
上述した仮想クリップ１０、仮想ＵＤＦイメージ２０の実体化の具体例を説明する。
【０１４９】
図２７に構成を示す。なお、図２７において太線で示すＶＦＳインターフェース(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というカーネルモジュールを利用するとファイルシステムをユーザランドで実装することができる。
【０１５１】
ＤＬＬ３５は、ユーザスペースとカーネル部のフューズモジュール３２との橋渡しをする。
【０１５２】
フューズモジュール３２は、任意のディレクトリをユーザー指定のファイルシステムとして参照する。フューズモジュール３２は、ＯＳへはデバイスドライバとして登録される。
【０１５３】
アザーファイルシステム３１は、指定外のファイルへのリクエストに対応するファイルシステムであり、ＯＳで決められたファイルシステム（例えばＦＡＴ３２，ＮＴＦＳ）などでファイルを参照する。
【０１５４】
この構成においてカーネル部では、ＯＳからのファイルのCREATE、READなどのサービスをユーザスペースのアプリケーションプログラムへ通知を行う。
【０１５５】
アプリケーションプログラムは、仮想ファイルシステムを各サービスに対して処理し、カーネル部に完了通知を行う。
【０１５６】
ＵＤＦイメージの実体化手順を図２８に示す。
【０１５７】
例えばソフトウエアプレーヤなどのアプリケーションからＵＤＦイメージのアクセスがリクエストされることで、ステップＦ２０１からの処理が行われる。
【０１５８】
まず、リクエストされたイメージファイルが仮想ＵＤＦイメージ２０として仮想化されているものであるか否かを判別する（ステップＦ２０１）。
【０１５９】
リクエスト対象が仮想化されたＵＤＦイメージの場合は、ファイルシステムアプリケーション３６が、リクエストされたＵＤＦイメージと同じ名前のディレクトリ下の仮想クリップ参照テーブル２１を参照する。そして、仮想ＵＤＦイメージ２０を実イメージに変換する（ステップＦ２０２）。
【０１６０】
例えばアプリケーションが、「ImageFile0」を実体ファイルとしてリクエストしたとする。本実施形態の場合、図１１で示したように同じ名前の「ImageFile0」ディレクトリが形成され、そのディレクトリ下にエクステントマップファイル、ソースファイルリストマップによる仮想クリップ参照テーブル２１が形成されている。
【０１６１】
ファイルシステムアプリケーション３６は、仮想クリップ参照テーブル２１、及びそこから参照されるＥＳ参照テーブル１１を用いて、ローカル（例えばＬドライブ）、あるいはネットワーク上の素材ファイルを参照しつつ、元のイメージファイルへ実体化する。
【０１６２】
なお、仮想化されていない実体のＵＤＦイメージがリクエスト対象であれば、そのまま当該ＵＤＦイメージファイルを再生すればよい（Ｆ２０１→ＮＯ）。
【０１６３】
ここで、ＵＤＦイメージ内でクリップファイル「xxxxx.m2ts」が含まれている場合、ステップＦ２０３からＦ２０４に進み、当該リクエストされたクリップが仮想化されたクリップであるか否かを判断する。
【０１６４】
仮想化されたクリップである場合は、ファイルシステムアプリケーション３６はステップＦ２０５で、アプリケーションなどでリクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のＥＳ参照テーブル１１を読み出す。そしてＥＳ参照テーブル１１をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、元のクリップファイルへ実体化する。
【０１６５】
なお、ＵＤＦイメージファイル内に実体があるクリップとして「xxxxx.m2ts」ファイルが含まれているときは、当該「xxxxx.m2ts」をそのままアプリケーションなどのリクエストに応じて再生できる（Ｆ２０４→ＮＯ）。
【０１６６】
クリップの実体化手順は図２９のようになる。
アプリケーションからクリップファイルのアクセスがリクエストされることで、ステップＦ２５０からの処理が行われる。
【０１６７】
リクエストされたクリップが仮想クリップ１０として仮想化されているものであるか否かを判別する（ステップＦ２５０）。
【０１６８】
仮想化されていない実体クリップであれば、そのまま当該クリップファイルを再生すればよい（Ｆ２５０→ＮＯ）。
【０１６９】
リクエストが仮想化されたクリップであった場合は、ファイルシステムアプリケーション１６は、リクエストされた「xxxxx.m2ts」ファイルと同名の「xxxxx.m2ts」ディレクトリ以下のＥＳ参照テーブル１１を読み出す。そして、ＥＳ参照テーブル１１をもとにローカル、あるいはネットワーク上の素材ファイルを参照しつつ、実クリップに変換し、元のクリップファイルを実体化する（ステップＦ２５１）。
【０１７０】
次に、図３０を参照して、仮想ＵＤＦイメージ２０が（１）Virtual  UDF  Image又は（２）Virtual  Wrapping  UDF  Imageであるときの実体化処理について説明する。図３０は、Virtual  UDF  Image及びVirtual  Wrapping  UDF  Imageの実体化処理を示すフローチャートである。
【０１７１】
図２３のステップＳ３０２で、（１）Virtual  UDF  Image又は（２）Virtual  Wrapping  UDF  Imageの実体化処理が開始される。（１）Virtual  UDF  Image又は（２）Virtual  Wrapping  UDF  Imageの実体化処理が開始されると、仮想ＵＤＦイメージ２０に登録されたファイルリスト中のファイル又はディレクトリ、具体的にはxxxx_SourceFileList.mapにリストアップされたファイル又はディレクトリがサーチされる（ステップＳ４０１）。
【０１７２】
次に、xxxx_SourceFileList.mapにリストアップされたファイル又はディレクトリのうちサーチ対象となったファイル又はディレクトリが、ＵＤＦ2.5のＵＤＦイメージであるか否かが判断される（ステップＳ４０２）。
【０１７３】
サーチ対象となったファイル又はディレクトリがＵＤＦ2.5のＵＤＦイメージである場合は、ＵＤＦイメージを実体化するための前処理を行う（ステップＳ４０３）。なお、ＵＤＦ2.5のＵＤＦイメージがxxxx_SourceFileList.mapにリストアップされているのは、Virtual  Wrapping  UDF  Imageの場合に限られる。実体化するための前処理とは、参照しているファイル、即ちＵＤＦ2.5のＵＤＦイメージが仮想のファイル形式であることを示すフラグを立てる処理である。
【０１７４】
また、xxxx_SourceFileList.mapにリストアップされたファイル又はディレクトリのうちサーチ対象となったファイル又はディレクトリが、仮想のm2tsファイルであるか否かが判断される（ステップＳ４０４）。
【０１７５】
サーチ対象となったファイル又はディレクトリが仮想のm2tsファイルである場合は、仮想のm2tsファイルを実体化するための前処理を行う（ステップＳ４０５）。ここでの前処理とは、仮想のm2tsファイルが仮想のファイル形式であることを示すフラグを立てる処理である。サーチ対象となったファイル又はディレクトリのうち、「BDMV」→「STREAM」ディレクトリ下の「xxxx.m2ts」という名称のものがファイルではなく、ディレクトリであれば、Reader/SSDLLは、「xxxx.m2ts」という名称のものが、仮想のm2tsファイルであると判断する。
【０１７６】
そして、ファイルサーチが全て終わるまで、サーチされたファイルの前処理を繰り返す（ステップＳ４０６）。
【０１７７】
ファイルサーチがすべて終了したときに、ＵＤＦイメージを実体化する（ステップＳ４０７）。即ち、実体化の前処理が行われたファイルについて、それぞれのファイルに対応した処理が実施される。具体的には、ステップＳ４０３，Ｓ４０５でフラグが立ったファイルについて、実体化用ファイル群をもとに、素材データ（ＥＳファイル群）などから、実体のあるファイルを生成する。このとき、メタデータなどの情報などが、実体化用ファイル群の中から取り出され、ファイルリストを参照元として、ＥＳファイルと、そのオフセット値、サイズが取り出される。そして、各種ファイルが実体化されるＵＤＦイメージ上にコピーされてＵＤＦイメージの実体化が完了する。
【０１７８】
以上、本実施形態によれば、デバイスドライバをインストールすることなく、ＯＳがサポートしていないファイルシステムによるファイルを、そのＯＳがサポートしているファイルシステム上で容易に扱うことができるようになる。
【０１７９】
本実施形態のマウントサービスによって、仮想ファイルがマウント処理され、ＯＳがサポートしていないＵＤＦ2.5のファイルシステムのファイル群や、ＵＤＦ2.5のイメージファイルがＰＣ上にマウントされる。そのため、ＯＳがファイルシステムをサポートしていない場合でも、ＵＤＦ2.5のファイルシステムのファイル群や、ＵＤＦ2.5のイメージファイルをＰＣ上で容易に扱うことができるようになる。例えば、ＯＳがファイルシステムをサポートしていないファイルを再生することができ、ＯＳがファイルシステムをサポートしていないイメージファイルについても、ＰＣ上でベリファイヤによる論理チェックなどを行うことができる。
【０１８０】
以上、添付図面を参照しながら本発明の好適な実施形態について詳細に説明したが、本発明はかかる例に限定されない。本発明の属する技術の分野における通常の知識を有する者であれば、特許請求の範囲に記載された技術的思想の範疇内において、各種の変更例又は修正例に想到し得ることは明らかであり、これらについても、当然に本発明の技術的範囲に属するものと了解される。
【０１８１】
例えば、上記実施形態では、ＵＤＦファイルシステムの場合について説明したが、本発明はこの例に限定されず、いずれのファイルシステムでも適用可能である。
【０１８２】
すなわち、任意のファイルシステムの仮想ファイルを作成する。そして、実体化するときのファイルシステムにおいては、例えばＵＤＦ2.01ファイルシステムを使用する。任意のファイルシステム下のファイル群は、その任意のファイルシステムの復号によって実体化を行うのではなく、例えば、ＵＤＦ2.01ファイルシステムによって実体化を行う。また、任意のファイルシステムのイメージファイルの実体化も行う。
【０１８３】
また、Mount  Serviceでは、ファイルシステムドライバをフューズモジュール（FUSE  Module）ではなく、カーネルモジュールによるデバイスドライバによっても構築できる。
【０１８４】
また、SSDLLによる実体化処理で、仮想ファイルシステムから、任意のファイルシステム下のファイル群の実体化を行ってもよい。
【符号の説明】
【０１８５】
１      仮想クリップ生成部
２      メタデータ生成部
３      仮想ＵＤＦイメージ／カッティングマスタ生成部
１０      仮想クリップ
１１      ＥＳ参照テーブル
２０      仮想ＵＤＦイメージ
２１      仮想クリップ参照テーブル
【図１】
2011216013.tif 000003
【図２】
2011216013.tif 000004
【図３】
2011216013.tif 000005
【図４】
2011216013.tif 000006
【図５】
2011216013.tif 000007
【図６】
2011216013.tif 000008
【図７】
2011216013.tif 000009
【図８】
2011216013.tif 000010
【図９】
2011216013.tif 000011
【図１０】
2011216013.tif 000012
【図１１】
2011216013.tif 000013
【図１２】
2011216013.tif 000014
【図１３】
2011216013.tif 000015
【図１４】
2011216013.tif 000016
【図１５】
2011216013.tif 000017
【図１６】
2011216013.tif 000018
【図１７】
2011216013.tif 000019
【図１８】
2011216013.tif 000020
【図１９】
2011216013.tif 000021
【図２０】
2011216013.tif 000022
【図２１】
2011216013.tif 000023
【図２２】
2011216013.tif 000024
【図２３】
2011216013.tif 000025
【図２４】
2011216013.tif 000026
【図２５】
2011216013.tif 000027
【図２６】
2011216013.tif 000028
【図２７】
2011216013.tif 000029
【図２８】
2011216013.tif 000030
【図２９】
2011216013.tif 000031
【図３０】
2011216013.tif 000032
【図３１】
2011216013.tif 000033
【図３２】
2011216013.tif 000034
【図３３】
2011216013.tif 000035
【図３４】
2011216013.tif 000036