WO2004109697A1

WO2004109697A1 - データ記録方法、データ記録装置、およびデータ記録媒体

Info

Publication number: WO2004109697A1
Application number: PCT/JP2004/006970
Authority: WO
Inventors: Ayumi Kida; Jiro Kiyama; Takayoshi Yamaguchi
Original assignee: Sharp Kabushiki Kaisha
Priority date: 2003-06-06
Filing date: 2004-05-21
Publication date: 2004-12-16
Also published as: JP3895305B2; US7835614B2; JP2004362719A; US20060120687A1

Abstract

　オリジナルプログラムを外部参照したユーザプログラムを作成し、それにアフレコデータを記録するにあたって、アフレコデータのユーザプログラムからの参照回数を示すref_counterを設定する（Ｓ１５０５）。設定されたref_counterは、作成されたユーザプログラムと共に光ディスクに記録される（Ｓ１５０７）。

Description

明細書

データ記録方法、データ記録装置、およびデータ記録媒体

技術分野

[0001] 本発明は、映像データ、音声データをハードディスク、光ディスク等のランダムァクセス可能な記録媒体に対して記録'再生するデータ記録方法及びデータ記録装置に関するものである。

^景技術

[0002] ディスクメディアや半導体媒体を用いたビデオや音声のディジタル記録再生装置が普及しつつある。それらにおいて、テープメディアと同様アフターレコーディング（ァフレコ）機能を安価に実現する技術が求められている。アフレコ機能は、既に記録したオーディオやビデオに対し、後から情報、特にオーディオやグラフィックを追記する機能である。

[0003] ここで、テープメディアにはないディスクメディアにおける特徴機能である、非破壊編集機能あるいはノンリニア編集機能と呼ばれる機能がある。すなわち、非破壊編集機能あるいはノンリニア編集機能では、ディスク上に記録した AVストリームを移動あるいはコピーすることなぐ AVストリームの任意の区間を任意の順番で再生できる。この機能においては、単に再生順番を変えるだけではなぐ同一のシーンを使って複数のユーザプログラムを作る、つまり同一のシーンを複数のユーザプログラムで共有すること力 S可能となる。このときのユーザの要望としては、それぞれのユーザプロダラムで個別にアフレコがしたレ、、というものがある。

[0004] 例えば、ユーザプログラム Aではあるシーンに対して BGMをアフレコし、同じシーンを共有するユーザプログラム Bではアナウンスをアフレコしたレ、、とレ、つた要望である。そのような要望に対して、日本国公開特許公報である特許文献 1では、アフレコ用領域割り当てを管理する情報を備えることで、複数のユーザプログラムからアフレコした場合に、異なるユーザプログラム間で共有される同一のシーンのアフレコに対して、意図しない上書きをすることを防ぐことができる。

[0005] 上記特許文献 1におけるディスクの記録フォーマットを図 27に示す。ディスクにおける記録領域は、 ECC (Error Correcting Code)ブロックの列で構成される。 ECCブロックは符号ィヒを行う際の最小単位であり、データに加えエラー補正用のパリティが付加され、符号化が行われている。ディスク内のデータを読み込む際は、この ECCプロックの単位で読み込み誤り訂正をしてから、必要なデータを取り出す。

[0006] 一方、ディスクに対してデータの書き換えを行う際は、まず ECCブロック単位で読み込み、誤り訂正をしたデータに対して必要な部分を書き換え、再度誤り符号を付与し、ディスクに記録を行う。

[0007] ビデオ（映像）データやオーディオ（音声）データは、 ECCブロック中で、アフレコデ一タブロック、オリジナルオーディオブロック、オリジナルビデオブロックの順に配置される。それぞれのブロックにはほぼ同じ時間に対応するアフレコデータ、オリジナルォ一ディォデータ、オリジナルビデオデータが含まれてレ、る。

[0008] 尚、オリジナルオーディオブロックとオリジナルビデオブロックとを合わせてオリジナルブロックと呼ぶことにする。オリジナルプログラム（アフレコデータを記録する前の映像）を記録する際は、アフレコデータブロックにダミーのデータを書き込んでおく。

[0009] アフレコデータの記録の際は、アフレコデータブロックへデータの書込みを行う。このとき、アフレコデータブロック中の記録を行った領域については既割り当て領域とし、残りを未割り当て領域としてオリジナルプログラム中の管理情報内で別々に管理する。この管理情報を参照することで、異なるユーザプログラム間でのアフレコデータの上書きを防止することができる。新たなアフレコデータが記録された際には、それぞれの領域における管理情報の書き換えを行う。

[0010] ところが、上記従来の構成では、ユーザプログラムを削除する場合を考えると、削除されるユーザプログラムに対応して不要となったアフレコデータを削除して領域を開放し、アフレコデータブロック領域を有効に再利用したいという要求に対しては、以下のような問題が生じる。

[0011] すなわち、同一のシーンを複数のユーザプログラムで共有する場合、各アフレコデータは複数のユーザプログラムから参照されている可能性があり、これを安易に削除することはできない。これを、より具体的に説明すると以下のとおりである。

[0012] つまり、あるユーザプログラムを削除するにあたって、この削除されるユーザプロダラムで参照されているアフレコデータを併せて削除しょうとする場合には、削除されるべきアフレコデータは削除されるユーザプログラムのみで参照されるものであり、他のュ一ザプログラムにおいて共有されていないことが必要である。

[0013] し力、しながら、従来では、ユーザプログラムの削除を行った場合、参照していたァフレコデータが他のどのユーザプログラムからも参照されておらず削除可能であると判断されるためには、すべてのユーザプログラムの管理情報をチェックする必要が生じる。このようなチェック動作は、シーク時間の長い光ディスクにおいては処理時間の面で問題となる。

特許文献 1：特開 2002—373480号公報 (公開日平成 14年 12月 26日）

発明の開示

[0014] 本発明は、上記の問題点を解決するためになされたもので、その目的は、ユーザプログラムの削除時、該ユーザプログラムにおいて参照していたアフレコデータが削除可能であるか否かの判断を容易にすることができるデータ記録方法およびデータ記録装置を提供することにある。

[0015] 上記の目的を達成するために、本発明に係るデータ記録方法は、記録媒体に、 A Vデータと、該 AVデータと同期するアフレコデータとを記録するデータ記録方法であつて、記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成可能であり、かつ、アフレコデータが複数のユーザプ

ログラムから参照可能であり、ユーザプログラムとアフレコデータとの関係を管理する管理情報を上記記録媒体上に記録することを特徴としている。

[0016] 上記の構成によれば、記録媒体に、 AVデータと、該 AVデータと同期するアフレコデータと記録するにあたって、記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成可能であり、かつ、アフレコデータが複数のユーザプログラムから参照可能となっている。

[0017] このため、例えば、あるユーザプログラムを削除するにあたって、この削除されるュ一ザプログラムで参照されているアフレコデータを併せて削除しょうとする場合には、削除されるべきアフレコデータは削除されるユーザプログラムのみで参照されるものであることを確認することが必要となる力 S、このような確認が上記管理情報によって容易に行える。

[0018] 本発明のさらに他の目的、特徴、および優れた点は、以下に示す記載によって十分に理解されるであろう。また、本発明の利益は、添付図面を参照した次の説明で明白になるであろう。

図面の簡単な説明

[0019] [図 1]本発明の一実施形態を示すものであり、アフレコデータ記録時の処理の流れを示したフローチャートである。

[図 2]本発明に係るデータ記録装置の概略構成を示すブロック図である。

[図 3(a)]QuickTimeファイルフォーマットにおける管理情報と AVストリームとの関係を示す図である。

[図 3(b)]QuickTimeファイルフォーマットにおける管理情報と AVストリームとの関係を示す図である。

[図 3(c)]QuickTimeファイルフォーマットにおける管理情報と AVストリームとの関係を示す図である。

[図 4]QuickTimeファイルフォーマットにおける Movie atomの概要を示す図である。

[図 5]QuickTimeファイルフォーマットにおける Track atomの概要を示す図である。

[図 6]QuickTimeファイルフォーマットにおける Track header atomの構成を示す図でめる。

[図 7]QuickTimeファイルフォーマットにおける Media atomの構成を示す図である。

[図 8]QuickTimeフアイノレフォーマットにおける Media information atomの構成を示す図である。

[図 9]Sample table atomによるデータ管理の例を示す図である。

[図 10]QuickTimeファイルフォーマットにおける Sample table atomの構成を示す図でめる。

[図 l l(a)]QuickTimeファイルフォーマットにおける Sample description atomの構成を示す図である。

[図 l l(b)]Sound Sample description Tableの構成を示す図である。

[図 12]QuickTimeファイルフォーマットにおける Edit atomの構成を示す図である。 [図 13(a)]Edit atomによる再生範囲指定の例を示す図である。

[図 13(b)]Edit atomによる再生範囲指定の例を示す図である。

[図 13(c)]Edit atomによる再生範囲指定の例を示す図である。

[図 14]QuickTimeファイルフォーマットにおける User data atomの構成を示す図である

[図 15]AVストリームの構成を示す図である。

[図 16(a)]UDFにおける管理情報の関係を示す図である。

[図 16(b)]UDFにおける管理情報の関係を示す図である。

[図 17]本発明の第 1の実施例における、 QuickTimeファイルフォーマットにおける User data atomの構成を示す図である。

[図 18]本発明の実施の形態 1における、記録直後のオリジナルプログラムの管理情報を示す図である。

[図 19(a)]本発明の実施の形態 1における、ユーザプログラム作成時の未割り当てトラックの変更を示す図である。

[図 19(b)]本発明の実施の形態 1における、ユーザプログラム作成時の未割り当てトラックの変更を示す図である。

[図 20]本発明の実施の形態 1における、ディスク上でのデータ配置とファイルとの関係を示した図である。

[図 21]本発明の実施の形態 1における、ユーザプログラムの編集の例を示した図である。

[図 22]本発明の実施の形態 1における、ユーザプログラム削除の処理の流れを示したフローチャートである。

[図 23]本発明の実施の形態 1における、ユーザプログラムの削除直前の参照関係を示した図である。

[図 24]本発明の実施の形態 1における、ユーザプログラムの削除直後の参照関係を示した図である。

[図 25]本発明の実施の形態 2における、ディスク上でのデータの配置とファイルの関係を示す図である。 [図 26]本発明の実施の形態 2における、ユーザプログラムの参照関係とインデックスフアイルとの関係を示した図である。

[図 27]従来技術におけるディスク上での記録形態を示す図である。

発明を実施するための最良の形態

[0020] 以下、本発明の実施形態について、図面を参照しながら詳細に説明する。ここでの説明は、本発明において共通に用いる構成、個々の実施形態に固有の内容という順に行っていく。

[0021] くシステム構成 >

図 2は、本実施の形態において共通に用いる、アフレコ可能なビデオディスクレコーダの構成である。

[0022] このビデオディスクレコーダは、図 2に示すように、バス 100、ホスト CPU (Central Processing Unit) 101、 RAM (Random Access Memory) 102、 ROM (Read Only Memory) 103、ユーザインタフェース 104、システムクロック 105、光ディスク 106、ピックアップ 107、 ECC (Error Correcting Code)デコーダ 108、 ECCエンコーダ 109、再生用バッファ 110、記録/アフレコ用バッファ 111、デマルチプレクサ 112、マルチプレクサ 113、多重化用バッファ 114、オーディオデコーダ 115、ビデオデコーダ 11 6、オーディオエンコーダ 117、ビデオエンコーダ 118および図示されないカメラ、マイク、スピーカ、ディスプレイ等で構成される。

[0023] ホスト CPU101は、バス 100を通じてデマルチプレクサ 112、マルチプレクサ 113、ピックアップ 107、また図示していないが、オーディオデコーダ 115、ビデオデコーダ 116、オーディオエンコーダ 117、ビデオエンコーダ 118との通信を行う。

[0024] 再生時には、ピックアップ 107を通じて光ディスク 106から読み出されたデータは、 ECCデコーダ 108によって誤り訂正され、再生用バッファ 110にー且蓄えられる。デマルチプレクサ 112は、オーディオデコーダ 115、ビデオデコーダ 116からのデータ送信要求に従って、再生用バッファ 110中のデータをその種別によって適切なデコーダに振り分ける。

[0025] 一方、記録時には、オーディオエンコーダ 117とビデオエンコーダ 1 18によって圧縮符号化されたデータは、マルチプレクサ 113を介して多重化用バッファ 1 14に一旦送られ、さらに、マルチプレクサ 113によって AV多重化されて多重化用バッファ 114 力記録/アフレコ用バッファ 111に送られる。記録/アフレコ用バッファ 111中のデータは、 ECCエンコーダ 109によって誤り訂正符号を付加され、ピックアップ 107を通じて光ディスク 106に記録される。

[0026] オーディオデータの符号化方式には MPEG-I Layer_IIを、ビデオデータの符号ィ匕方式には MPEG-2をそれぞれ用いることができる。

[0027] 光ディスク 106は、外周から内周に向かって螺旋状に記録再生の行われるものであり、ビデオディスクレコーダに対して脱着可能な記録媒体とする。また、光ディスク 10 6は、 2048byteを 1セクタとし、誤り訂正のため 16セクタで ECCブロックを構成する。

ECCブロック中のデータを書き換える場合には、そのデータが含まれる ECCブロック全体を読み込み、誤り訂正を行い、対象のデータを書き換え、再び誤り訂正符号を付加し、 ECCブロックを構成して光ディスク 106に記録する必要がある。また、光ディスク 106では、記録効率を上げるため ZCAV (ゾーン角速度一定）を採用しており、記録領域は回転数の異なる複数のゾーンで構成される。

[0028]

本実施の形態に係るビデオディスクレコーダでは、光ディスク 106上の各種情報を管理するためにファイルシステムを用い、このファイルシステムをデータ（アフレコデータ、オーディオデータ、ビデオデータ）と共に光ディスク 106に記録する。ファイルシステムには、パーソナルコンピュータ（以下、 PCと略称する）との相互運用を考慮して U DF (Universal Disk Format)を使用することができる。ファイルシステム上では、各種管理情報や AVストリームはファイルとして扱われる。

[0029] ファイルシステムのユーザエリアは、 2048byteの論理ブロック (セクタと一対一に対応)で管理される。ユーザエリア上の各ファイルは、整数個のエクステント (連続した論理ブロック)で構成され、エクステント単位で分散して記録してもよい。ユーザエリア内の空き領域は、 Space Bitmapを用いて論理ブロック単位で管理される。

[0030] <フアイノレフォーマット >

AVストリーム管理のためのフォーマットとして、ここでは QuickTimeファイルフォーマットを用レ、る。 QuickTimeファイルフォーマットとは、 Apple社が開発したマルチメディアデータ管理用フォーマットであり、 PCの世界では広く用いられている。

[0031] QuickTimeファイルフォーマットは、ビデオデータやオーディオデータ等 (これらを総称してメディアデータとも呼ぶ)と管理情報とで構成される。メディアデータと管理情報とを合わせてここでは、 QuickTimeムービー (略してムービー)と呼ぶ。メディアデータと管理情報とは、同じファイル中に存在しても、別々のファイルに存在してもよい。

[0032] メディアデータと管理情報とが同じファイル中に存在する場合は、図 3 (a)に示すようなファイル構成をとる。各種情報は atomという共通の構造に格納される。ファイル 20 1において、管理情報は Movie atomという構造に格納され、メディアデータの AVストリームは Movie data atomとレ、う構造に格納される。また、 Movie data atomの最初には、 Atom Header (AH)が配置される。尚、 Movie atom中の管理情報には、メディアデータ中の任意の時間に対応する AVストリームのファイル中での相対位置を導くためのテーブルや、メディアデータの属性情報や、後述する外部参照情報等が含まれている。

[0033] 一方、管理情報とメディアデータとを別々のファイルに格納した場合は、図 3 (b)に示すような構成をとる。この場合、管理情報はファイル 202において Movie atomという構造に格納されるが、 AVストリームは atomには格納される必要はなぐファイル 203 に格納される。このとき、 Movie atomは AVストリームを格納したファイル 203を「外部参照」している、という。

[0034] 外部参照では、図 3 (c)に示すように、管理情報を格納する一つのファイル 204によつて複数の AVストリームファイル（この図ではファイル 205 · 206)を参照することが可能である。この仕組みにより、 AVストリーム自体を物理的に移動することなぐ見かけ上編集を行ったように見せる、いわゆる「ノンリニア編集」「非破壊編集」が可能になる。また、光ディスク 106上に記録した AVストリームの同一のシーンを使って複数のュ一ザプログラムを作成することが可能であり、かつ、同一のアフレコデータを複数のュ一ザプログラムにて参照することも可能である。

[0035] 次に、図 4ないし図 14を用いて、 QuickTimeの管理情報のフォーマットについて説明する。まず、共通の情報格納フォーマットである atomについて説明する。 atomの先頭には、その atomのサイズである Atom size,その atomの種別情報である Typeが必ず存在する。 Typeは 4文字で区別され、例えば Movie atomでは' moov'、 Movie data atomでは mdat となってレヽる。

[0036] atom間には階層構造があり、各 atomは別の atomを含むことができる。 Movie atomの構成を図 4に示す。 Movie header atomは、その Movie atomが管理するムービーの全体的な属性を管理する。 Track atomは、そのムービーに含まれるビデオやオーディォ等のトラックに関する情報を格納する。 User data atomは、ユーザが独自に定義可能な atomである。

[0037] Track atomの構成を図 5に示す。 Track header atomはそのトラックの全体的な属性を管理する。 Edit atomは、メディアデータのどの区間をムービーのどのタイミングで再生するかを管理する。 Track reference atomは、別のトラックとの関係を管理する。

Media atomは、実際のビデオやオーディオといったデータを管理する。

[0038] Track header atomの構成を図 6に示す。ここでは、後での説明に必要なもののみ説明する。 Flagsは属性を示すフラグの集合である。代表的なものとして、 Track enabled フラグがあり、このフラグ力 1 'であればそのトラックは再生され、 ' 0 'であれば再生されない。 Track IDはトラック固有の IDである。 Layerはそのトラックの空間的な優先度を表しており、画像を表示するトラックが複数あれば、 Layerの値が小さいトラックほど画像が前面に表示される。

[0039] Media atomの構成を図 7に示す。 Media header atomは、その Media atomの管理するメディアデータに関する全体的な属性等を管理する。 Handler reference atomは、メディアデータをどのデコーダでデコードするかを示す情報を格納する。 Media information atomは、ビデオやオーディオ等のメディア固有の属性情報を管理する。

[0040] Media information atomの構成を図 8に示す。 Media information header atomは、ビデォゃオーディオ等のメディア固有の属性情報を管理する。 Handler reference atom は、 Media atomの項で説明した通りである。 Data information atomは、その

QuickTimeムービーが参照するメディアデータを含むファイルの名前を管理する atom である Data reference atomを含む。 Sample table atomは、データのサイズや再生時間等を管理している。

[0041] 次に Sample table atomにつレ、て説明する力 S、その前に、 QuickTimeにおけるデータの管理方法について、図 9を用いて説明する。 QuickTimeでは、データの最小単位（例えばビデオフレーム)をサンプル（sample)と呼ぶ。個々のトラック毎に、サンプルには再生時間順に 1から番号 (サンプル番号)がついている。

[0042] また、 QuickTimeフォーマットでは、個々のサンプルの再生時間長およびデータサィズを管理している。また、同一トラックに属するサンプルが再生時間順にファイル中で連続的に配置された領域をチャンク（chunk)と呼ぶ。チャンクにも再生時間順に、 1 力、ら番号がついている。すなわち、 QuickTimeフォーマットでは、このようにチャンクが連続して配置されることにより一つのファイル 901が形成される。

[0043] さらに、 QuickTimeフォーマットでは、個々のチャンクにおけるファイル先頭からのァドレスおよび個々のチャンクが含むサンプノレ数を管理している。これらの情報に基づき、任意の時間に対応するサンプノレの位置を求めることが可能となっている。

[0044] Sample table atomの構成を図 10に示す。 Sample description atomは、個々のチヤンクのデータフォーマット (Data format)やサンプルが格納されてレ、るファイルのチャンクのインデックス等を管理する。さらに、 Sample description atomの構成を図 11 (a)に示す。 number-of-entriesは使用されているデータフォーマットの数を表し、その数だけ Sample description table力ィ子す。図 11 (b)はォーティォの Sample description tableの例である。

[0045] 図 10の Sample table atomにおいて、 Time-to-sample atomは、個々のサンプルの再生時間を管理する。 Sync sample atomは、個々のサンプルのうち、デコード開始可能なサンプルを管理する。 Sample-to-chunk atomは、個々のチャンクに含まれるサンプル数を管理する。 Sample size atomは、個々のサンプルのサイズを管理する。

Chunk offset atomは、個々のチャンクのファイル先頭からのアドレスを管理する。

[0046] Edit atomは、図 12に示すように 1個の Edit list atomを含む。 Edit list atomは

Number of entriesで指定される個数分の、 Track duration, Media time, Media rateの値の組 (エントリ)を持つ。各エントリは、トラック上で連続的に再生される区間に対応し、そのトラック上での再生時間順に並んでレ、る。

[0047] Track durationは、そのエントリが管理する区間のトラック上での再生時間、 Media timeは、そのエントリが管理する区間の先頭に対応するメディアデータ上での位置、 Media rateは、そのエントリが管理する区間の再生スピードを表す。尚、 Media timeがの場合は、そのエントリの Track duration分、そのトラックでのサンプルの再生を停止する。この区間のことを empty editと呼ぶ。

[0048] 図 13に Edit listの使用例を示す。ここでは、 Edit list atomの内容が図 13 (a)に示す内容であり、さらにサンプルの構成が図 13 (b)に示す構成であるとする。尚、ここでは i番目のエントリの Track durationを D(i)、 Media timeを T(i)、 Media rateを R(i)として示している。このとき、実際のサンプルの再生は、図 13 (c)に示す順に行われる。このことについて簡単に説明する。

[0049] まず、エントリ #1は、 Track durationが 13000、 Media timeが 20000、 Media rateが 1であるため、そのトラックの先頭から 13000の区間はサンプル中の時刻 20000から 33000 の区間を再生する。次に、エントリ #2は、 Track durationが 5000、 Media timeが— 1であるため、トラック中の時刻 13000から 18000の区間、何も再生を行わなレ、。そして、ェントリ #3は、 Track durationが 10000、 Media timeが 0、 Media rateが 1であるため、トラック中の時刻 18000から 28000の区間において、サンプル中の時刻 0から 10000の区間を再生する。

[0050] 図 14に、 User data atomの構成を示す。この atomには、 QuickTimeフォーマットで定義されてなレ、独自の情報を任意個数格納することができる。 1個の独自情報は 1個のエントリで管理され、 1個のエントリは Atom sizeと Typeと User dataとで構成される。

Atom sizeはそのエントリ自体のサイズを表し、 Typeは独自情報をそれぞれ区別するための識別情報、 User dataは実際のデータを表す。

[0051]

ディスク内に含まれる QuickTimeムービーを管理するため、インデックスファイルという特別な QuickTimeムービーファイルをディスク内に 1個置く。

[0052] インデックスファイルには、ディスク内のファイル (QuickTimeムービーや QuickTimeム一ビーから参照されている静止画等)に関するサムネイルや各種属性が登録されている。各種属性の中には、そのファイルが外部参照されている回数を示す link count 力 Sある。

[0053] link countを参照することで、そのファイルを参照しているファイルがあるかどうかを容易に知ることができ、他から参照されているファイルを不用意に削除してしまうことを防ぐことができる。

[0054] く AVストリームの形態 >

AVストリームの形態を図 15に示す。 AVストリームは整数個の Continuous Unit (C U)で構成される。 CUはディスク上で連続的に記録される単位である。 CUの境界は ECCブロック境界と一致するようにストリームが構成されている。また CUは、一つの Post Record Unit (PRU)と整数個の Video Unit (VU)とで構成される。 VUは独立に再生可能な単位であり、 VUの集合が前述のオリジナルブロックに対応する。 PRUは前述のアフレコデータブロックに対応する。 PRUの領域サイズは、 CUの再生時間にオーディオの最大ビットレートをかけたものである。

[0055] くファイルシステムフォーマット〉

本発明の説明において用いるファイルシステムのフォーマットである、 UDF ( Universal Disk Format)について図 16を用いて説明する。図 16(a)に示すディレクトリ /ファイル構成を UDFで記録した例を図 16(b)に示す。図中の AVDP602は Anchor Volume Descriptor Pointerの略であり、 UDFの管理情報を探すためのエントリポイントに相当し、通常 256セクタ目、 Nセクタ目、あるいは N— 256セクタ目（Nは最大論理セクタ番号）に記録される。 VDS601は Volume Descriptor Sequenceの略であり、 UD Fが管理する領域であるボリュームに関する管理情報を記録する。ボリュームは一般に一枚のディスクに 1個存在し、その中にパーティションを一般に 1個含む。 FSD60 3は File Set Descriptorの略であり、パーティションに 1個存在する。パーティションの中での位置情報はパーティションの先頭からのセクタ番号に相当する論理ブロック番号で示される。なお、 1個の論理ブロックは 1セクタに対応する。また、各パーティションには図示しないが Space Bitmapと呼ばれる各論理ブロックがファイルにすでに割り当てられているかそうでないかを示すテーブルが存在する。

[0056] FSD603は、ルートディレクトリの File Entry (FE)である FE604の位置情報（論理ブロック番号と論理ブロック数で構成され extentと呼ばれる）を含む。 FEは、 extentの集合を管理しており、 extentを書き換えたり、追加したり、削除することで、ファイルを構成する実データの順番を変えたり、データを揷入したり削除したりすることが可能である。 FE604はルートディレクトリの直下のファイルやディレクトリの名称等を格納する File Identifier Descriptor (FID)の集合を格納する領域 605を管理する。領域 605中の FID611、 FID612は、それぞれフアイノレ 621、ファイル 622のファイル名や extent の集合を管理する FE606、 FE608の位置情報を含む。 FE606はファイル 621の実データを構成する領域である領域 607、領域 610を extentとして管理する。 FE608 はファイル 622の実データを構成する領域である領域 609を extentとして管理する。このときファイル 621の実データにアクセスするためには、 AVDP602、 VDS601、 F SD603、 FE604、 FID611、 FE606、領域 607、領域 610の匿 (こリンクを迪つてレヽけばよい。

[0057] 〔実施の形態 1〕

本発明の実施の形態 1について、図 1、図 17ないし図 24を用いて説明する。

[0058] ここでは、アフレコに関する処理を中心に説明し、オリジナルプログラムの AVストリームの処理については特に説明しない。

[0059] <初期記録時の処理 >

PRUはオリジナルプログラムの記録の際にアフレコデータ用として確保される領域であり、 AVストリームの記録時にアフレコファイルが作成されて、この領域はダミーデータとして管理される。

[0060] オリジナルプログラムの管理情報内には、 PRU領域内のアフレコデータが記録されていない領域を管理するための未割り当てトラックを作成し、初期記録の際は、 CU 単位の PRU領域を 1サンプルとしてすベての PRU領域についての位置、サイズ、時間情報を管理する sample tableを作成する。この未割り当てトラックについては、 Track header atomの Track Enabledフラグを 0にセットし、再生対象ではないことを示す。

[0061] <アフレコデータ記録時の処理 >

次に、オリジナルプログラムを外部参照したユーザプログラムを作成し、それにァフレコデータを記録する際の手順を説明する。ここでは、作成するユーザプログラムが、オリジナルプログラムの一部を抜き出して再生するというものである場合を考える。

[0062] ユーザプログラムの作成は、オリジナルプログラムの管理情報力、ら AVストリームのトラックのユーザが指定した区間の sample tableをコピーすればよい。

[0063] このユーザプログラムにアフレコデータを追加するときの処理について図 1に基づいて説明する。まず、ユーザプログラムの QuickTime管理情報を RAM102に読み込む。また、ユーザプログラムの管理情報の Data reference atomに記述されたファイル名からオリジナルプログラムを特定し、参照先のオリジナルプログラムの QuickTime管理情報も RAM102に読み込む（S1501)。

[0064] 次に、ユーザが指定した区間におけるアフレコデータを記録すべき PRUの位置を、オリジナルプログラムの未割り当てトラックの sample tableから、アフレコ対象のビデォと時間的に対応する部分を探すことで特定する。そして、これから記録しょうとするアフレコがオーディオの場合、ビットレートからデータ量を計算し、未割り当てトラックで管理してレ、る PRUの size内に収まるかどうかを判定する（S 1502)。

[0065] また、アフレコがグラフィックの場合は、記録するグラフィックデータのサイズが PRU の size内に収まるかどうかを判定する。具体的には、アフレコデータは、 CU単位のストリーム再生時間分ずつ、ディスク上に均等に配置されている PRU領域に分けて記録されるため、ユーザが指定したアフレコ区間全ての PRU未割り当て領域の sizeを調べて判定を行う。

[0066] アフレコデータを記録する領域が決定すれば、実際にその領域にアフレコデータを記録する。

[0067] アフレコデータの記録が終了すると、次に、オリジナルプログラム側にアフレコしたデータを管理するトラックを新規に作成し (S 1503)、記録したアフレコデータを管理する sample tableを作成する（S I 504)。

[0068] ここで、データの参照回数を管理するため、 Track atom中の User data atom( 'udta'

)内に、図 17に示すような、独自の Atom typeである reference management atom( ' rfmg を定 " 。この reference management atomの中に、丁' ~タ； 0、参照、されている回数を示すフィールド 'ref_counter'を定義する。

[0069] すなわち、 Sample tableを作成した後、 User data atom内に上記 reference

management atomを作成し、 ref_counterフィーノレドに参照、回数 3 1回であること表 1

' 1，をセットする（S1505)。 [0070] 次に、オリジナルプログラムの未割り当てトラックの sample tableの chunk offsetと size を、アフレコデータ記録後の PRUの残り領域に対応するよう更新する（S1506)。

[0071] 次に、記録したアフレコデータを再生するためのトラックをユーザプログラム側にも新規に作成し、先程作成したオリジナルプログラムと同様、アフレコトラックの sample tableを作成する。

[0072] 最後に、 RAMI 02上のオリジナルプログラムおよびユーザプログラムの QuickTime 管理情報を光ディスク 106に記録する（S 1507)。

[0073] 上記フローにおいて、 S1502 S1506の処理は、図 2に示す構成のビデオデイスクレコーダでは、ホスト CPU101が、 RAM102内に読み込まれたオリジナルプログラムおよびユーザプログラムの QuickTime管理情報に対して行う。そして、 S1502—S1 506の処理が施されたオリジナルプログラムおよびユーザプログラムの QuickTime管理情報が、ホスト CPU101に制御によって RAM102から読み出されバス 100およびピックアップ 107を介して光ディスク 106に書き込まれる。

[0074] 一方、 S 1502で未割り当て領域がな力た場合、アフレコ用のビットレートを下げることで割り当てる領域のサイズを小さくし、割り当て領域があるかどうかを再度調べるようにすることができる。それでも未割り当て領域がなければ、 AVストリームの PRU領域とは別の領域に記録を行うことも可能である。アフレコする区間について、部分的に記録する領域がない場合、その区間のみ PRU領域とは別の領域に記録するようにしても良い。

[0075] アフレコデータ記録後のオリジナルプログラムは図 18のようになる。アフレコが記録された区間の PRUは、アフレコデータが記録された領域 (既割り当て領域)と未割り当て領域で構成される。オリジナルプログラムの管理情報である Movie atomには Videoトラック、 Main Audioトラック、アフレコトラック (図中 PR Audio),未割り当てトラックの 4つのトラックがあり、それぞれのデータのアドレスやサイズ、再生時間等の情報を持つ。

[0076] 既にアフレコデータが記録されている後に別の種類のアフレコデータを追加するときの処理も、新規にファイルを作成しないこと以外は同様である。図 19 (a)はアフレコデータ追加前の PRUの状態であり、図 19 (b)はアフレコデータ追加後の PRUの状態を示す。図 19 (b)では、既に記録されているアフレコ #Aトラックの後ろに、追加されるアフレコデータ用に新規にアフレコ #Bトラックを作成し、アフレコデータ毎に 1トラックで管理を行う。 Chunk offsetの値は PRU中の新規アフレコデータ開始位置をセットする。図では既にあったアフレコデータのすぐ後に新しいアフレコデータを記録している力未割り当て領域のどの位置でも記録を行って良レ、。新規データが追加される度に、残り領域に応じて未害 ijり当てトラックの Chunk offsetおよび Sample sizeの更新を行う。

[0077] また、ファイルシステム上では図 20に示すように、オリジナルブロックで 1ファイル（ストリームファイル）、アフレコデータブロックで 1ファイル（アフレコファイル）の外部参照フアイノレとして扱う。すなわち、アフレコファイル中に複数のアフレコデータが混在する形になる。

[0078] アフレコファイル中に複数のアフレコデータが存在している場合でも、アフレコデータの種類毎にトラックを分け、トラック毎に retcounterを持つことで、容易に参照回数を管理すること力 Sできる。

[0079] <ユーザプログラム作成時の処理 >

次に、アフレコデータを持つユーザプログラムをさらに非破壊編集する場合の処理を説明する。例えば図 21のようにユーザプログラム 1とユーザプログラム 2をつなぎ合わせたユーザプログラム 3を作成するときを考える。

[0080] まず、ユーザプログラム 1および 2の管理情報を RAM102に読み込み、新たなユーザプログラム 3として結合する。また、このユーザプログラム 3の Data reference atomに記述された参照ファイル名からオリジナルプログラムを特定し、オリジナルプログラムに関する管理情報を RAM 102上に読み込む。

[0081] 次に、オリジナルプログラムの管理情報に関して、ユーザプログラム 3のアフレコトラックの chunk offset情報から、 offsetが同一のアフレコ済みサンプルをサーチすることで、複数あるアフレコデータの中からユーザプログラム 3が参照しているアフレコデータを特定し、それにメ寸 J心する track atom内の udta atomの reference management atom i, rfmg' )にある red_counterを li曾やす。

[0082] 最後に、 RAMI 02上のオリジナルプログラムおよびユーザプログラム 3の管理情報を光ディスク 106に記録する。 [0083] <ユーザプログラム削除時の処理 >

ユーザから、ユーザプログラムの削除が指示された場合の処理について図 22に沿つて説明する。尚、はじめに削除指示されたユーザプログラムの管理情報を RAM10 2上に読み込んでおく。

[0084] まず、ユーザプログラムの管理情報中のトラックを調べ、そのユーザプログラムが参照しているアフレコデータを管理しているオリジナルプログラムをリストアップする（S2 101)。アフレコデータを管理するトラックがない場合は処理を終了する。

[0085] 次に、リストアップした各オリジナルプログラムに関して、以下の処理を行う。まず、オリジナルプログラムの管理情報を RAM102に読み込む。そして、ユーザプログラムのアフレコトラックの chunk offset情報からオリジナルプログラム内の対応するアフレコトラックを検索し、検索されたトラックの ref_counterを 1減らす（S2102)。

[0086] ここで ref_counterが 0かどうかの判定を行い（S2103)、 0であれば、削除を行ってこの部分の領域を開放し (S2104)、開放した領域を未割り当て領域に返却するように、未割り当てトラックのサンプル管理情報の更新を行う（S2105)。また、オリジナルプログラムの管理情報から削除を行ったアフレコデータに対応する Track atomを削除する（S2106)。この処理はアフレコデータ記録時の処理の逆に相当する。

[0087] 最後に、ユーザプログラムを格納しているファイルを光ディスク 106から削除し（S21 07)、オリジナルプログラムの管理情報を光ディスク 106に記録する（S2108)。

[0088] また、 S2103におレヽて、 ref_counterが 0でない場合には、上記アフレコデータを参照している他のユーザプログラムを存在していることを示しているので、 S2104— 21 06の処理、すなわちアフレコデートの削除処理を行わずに S2107に移行する。

[0089] 例えば、図 23に示すような参照関係を持つファイルがあり、このうちユーザプロダラム 3を削除する場合を考える。ここでユーザプログラム 3においては、アフレコデータ A とアフレコデータ Bとが参照されている。ユーザプログラム 3を削除するにあたって、ァフレコデータ Aおよびアフレコデータ Bの retcounter数を 1減らすと、図 24に示すように、アフレコデータ Aの retcounter数は 1になり、アフレコデータ

Bの retcounter数は 0になる。

[0090] すなわち、アフレコデータ Bはユーザプログラム 3にのみ参照されていたデータであるため、ユーザプログラム 3と同時にアフレコデータ Bも削除される力アフレコデータ Aは他のユーザプログラム力らも参照されている（ここでは、ユーザプログラム 2から参照されてレ、る）ため削除されなレ、。

[0091] <実施の形態 1における変形例 >

本実施の形態 1では、 udta atom中に参照回数を示すフィールドを設けた力 S、本発明はそれに限定されるものではない。

[0092] 例えば、この参照回数を示す情報を Sample description atom中の Sample

description table内に設けても良レ、。すなわち、アフレコデータ毎に Sample descriptionを作成するという方法である。これにより、アフレコデータ毎にトラックを分割することを前提としなくても、 Sample description atomで管理可能であるため、管理ファイルのデータ量の節約に繋がる。ただし、 QuickTimeでは、一つのトラックに再生時間の重なるサンプノレを同時に置くことはできないため、その場合はトラックを分割する必要がある。そうした場合でも、 Sample description table内に参照回数を示す情報を持たせることで、より詳細にアフレコデータを管理することが可能になる。

[0093] 例えば、 1つのアフレコデータの前半と後半とで異なるコーデックが使われており、 Sample descriptionが分かれている場合などで、アフレコデータを記録したユーザプログラムを削除する場合、たとえ他のユーザプログラムからこのアフレコデータが参照されていたとしても、その参照範囲が前半部分のみであれば、後半部分のアフレコデータのみを削除して、そのデータが記録されていた領域を開放することができる。

[0094] ま 7こ、 reference management atom内におレヽて、照回数の†青芊艮を不す ref— counter だけでなぐ参照しているユーザプログラムのファイル名の情報を持たせてもよい。これによって、ユーザによってアフレコデータの削除が指示された場合に、該アフレコデータが他のユーザプログラムファイルから参照されているか否かの情報の他に、どのファイルから参照されているかをユーザに提示することが可能になる。

[0095] さらに、各ユーザプログラムからアフレコデータのどの部分が参照されているかを示す参照範囲の情報を持たせることもできる。このような参照範囲情報により、アフレコデータ自体は複数のユーザプログラムから参照されてレ、ても要らなくなった部分のみを削除できるため、より有効に PRU領域を活用することができる。 [0096] 〔実施の形態 2〕

次に、本発明の実施の形態 2について説明する。実施の形態 1と異なり、たデータ毎にファイルを分けて管理する。尚、本実施の形態 2は上述の実施の形態 1 と類似するため、相違点に絞って説明する。

[0097] 先ず、アフレコデータが 2種類あるときのディスク上の配置とファイルの関係を図 25 に示す。光ディスク 106上の物理的な記録では、 CU毎にアフレコ—データブロックおよびオリジナルブロック（すなわちオリジナルオーディオブロックおよびオリジナルビデォブロック）が配置されており、アフレコデータブロックはアフレコデータ # Aを記録する領域、アフレコデータ # Bを記録する領域、未割り当て領域からなっている。そして、アフレコデータ # Aに係る各データはアフレコ Aファイルに、アフレコデータ # Bに係る各データはアフレコ Bファイルに、未割り当て領域はダミーファイルにて管理されている。

[0098] <初期記録時の処理 >

実施の形態 2における初期記録時の処理は、実施の形態 1と共通であるので、説明を省略する。

[0099] <アフレコデータ記録時の処理 >

実施の形態 2におけるアフレコデータ記録時の処理を説明する。まず、アフレコデータを追加するユーザプログラムの QuickTime管理情報を RAM102に読み込み、ォリジナルプログラムを特定してオリジナルプログラムの QuickTime管理情報を RAMI 02に読み込む。さらに、ファイルシステム管理情報を RAM102に読み込む。 PRUの位置の特定とアフレコデータ記録領域判定は実施の形態 1と同じであるので説明を省く。

[0100] 次に、アフレコデータをディスク上の PRU領域に記録し、新規にアフレコ用のフアイルを作成してファイルシステム管理情報を更新する。このとき、新規に作成したァフレコデータのサイズに応じて未割り当て領域で構成されるダミーファイルのサイズを小さくし、ファイルシステム管理情報を更新する。

[0101] 次に、オリジナルプログラムの QuickTime管理情報に関して、アフレコデータ用のトラックを新規に作成し、ユーザが指定した区間の sample tableを作成し、 ref_counterフィールドに' 1，をセットする。また、 data reference atomには先程作成したアフレコファィル名をセットする。

[0102] 次に、オリジナルプログラムの未割り当てトラックの sample tableの chunk offsetと size を、アフレコデータ記録後の PRUの残り領域に対応するよう更新する。

[0103] 次に、ユーザプログラム側の管理情報に、先程作成したオリジナルプログラムのァフレコトラックの sample tableをコピーする。

[0104] 最後に、 RAMI 02上のオリジナルプログラムおよびユーザプログラムの QuickTime 管理情報、及びファイルシステム管理情報を光ディスク 106に記録する。

[0105] 別の種類のアフレコデータを追加するときの処理も上記と同様である。すなわちァフレコデータの種類の数だけファイルが作成される。

[0106] <ユーザプログラム作成時の処理 >

実施の形態 2では、複数のアフレコデータを持つオリジナルプログラムの中からュ一ザプログラムが参照しているアフレコデータのトラックを特定する際、ユーザプログラムのアフレコトラックの Data reference atomに書かれているファイル名と同じファイル名を参照してレ、るトラックをオリジナルプログラムの中からサーチする。オリジナルプログラムは、ユーザプログラムで参照するオーディオビデオファイルから特定する。それ以外の処理は実施の形態 1と共通である。

[0107] <ユーザプログラム削除時の処理 >

実施の形態 2では、削除するユーザプログラムのアフレコデータ力オリジナルプログラムのどのトラックで管理されているかを特定する際、上記ユーザプログラム作成時の処理で説明したのと同様に、 data reference atomの参照ファイル名を用いて行う。

[0108] また、ユーザプログラムを削除することによって、 retcounterが 0になった場合、このアフレコデータを PRU領域から削除し、開放した領域を未割り当て領域に返却するが、 QuickTime管理情報の書き換えに加え、該アフレコデータのファイルも削除し、未割り当て領域で構成されるダミーファイルのサイズを削除したファイルサイズに応じて大きくし、ファイルシステム管理情報の更新をする。それ以外の処理は実施の形態 1 と共通である。

[0109] このように、実施の形態 1では、アフレコファイルのサイズとアドレスは常に変わらないため、アフレコデータの削除が管理情報の書き換えのみで行うことができ、ファイルシステムの書き換えを必要としないものの、アフレコデータを特定する際に、サンプルの chunk offset値からアフレコファイル中の特定データを探索せねばならなかった。

[0110] これに対し、本実施の形態 2によると、アフレコデータ毎にファイルが分かれているため、 data reference atomの参照ファイル名から一発でアフレコデータを特定することができ、データの特定がより簡便に、より迅速に行うことができる。ただし、管理情報の操作の他、ファイルシステムの操作も必要になる。

[0111]

<実施の形態 2における変形例 >

実施の形態 2では、オリジナルプログラムの管理情報内で、アフレコデータの種類毎にトラックを分け、その中で参照回数を管理していたが、ディスク上に 1個存在する管理情報ファイルであるインデックスファイル内にて管理する構成であっても良レ、。この場合、図 26に示すように、ファイル名などのアフレコデータファイルを特定するための情報と参照回数情報を関連つけて管理する。

[0112] 尚、上記実施の形態 1および 2において、用いられる記録媒体は光ディスクとしたが、本発明を適用できる記録媒体は光ディスクに限定されるものではなぐランダムァクセス可能な記録媒体 (例えばハードディスク）であればょレ、。

[0113] 以上のように、本発明のデータ記録方法は、記録媒体に、 AVデータと、該 AVデータと同期するアフレコデータとを記録するデータ記録方法であって、記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成可能であり、かつ、アフレコデータが複数のユーザプログラムから参照可能であり、ユーザプログラムとアフレコデータとの関係を管理する管理情報を上記記録媒体上に記録することを特徴としている。

[0114] 上記の構成によれば、記録媒体に、 AVデータと、該 AVデータと同期するアフレコデータと記録するにあたって、記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成可能であり、かつ、アフレコデータが複数のユーザプログラムから参照可能となっている。

[0115] このため、例えば、あるユーザプログラムを削除するにあたって、この削除されるュ一ザプログラムで参照されているアフレコデータを併せて削除しょうとする場合には、削除されるべきアフレコデータは削除されるユーザプログラムのみで参照されるものであることを確認することが必要となる力 S、このような確認が上記管理情報によって容易に行える。

[0116] また、上記データ記録方法では、上記アフレコデータは、複数のユーザプログラムにおいて参照されるアフレコデータ群を含む領域中の部分領域であり、前記領域はひとつのアフレコファイルとして記録されており、上記管理情報は、オリジナルプログラムに対して 1つ存在する管理情報ファイル中にアフレコデータ毎に記録される構成とすることができる。

[0117] また、上記データ記録方法では、上記アフレコデータは、同一のユーザプログラムにおいて参照されるアフレコデータ群ごとにアフレコファイルとして記録されており、上記管理情報は、複数のオリジナルプログラムに対して 1つ存在する管理情報フアイル中にアフレコファイル毎に記録される構成とすることができる。

[0118] 上記の構成によれば、アフレコファイルのサイズとアドレスとが常に変わらないような管理が可能であり、アフレコデータの削除が管理情報の書き換えのみで行うことができるため、ファイルシステムの書き換えを必要としない。

[0119] また、上記データ記録方法では、上記アフレコデータは、同一のユーザプログラムにおいて参照されるアフレコデータ群ごとにアフレコファイルとして記録されており、上記管理情報は、オリジナルプログラムに対して 1つ存在する管理情報ファイル中にアフレコファイル毎に記録される構成とすることができる。

[0120] 上記の構成によれば、アフレコデータ毎にアフレコファイルが分かれているため、ァフレコデータを特定する際、データのオフセットなどから検索しなくとも、各アフレコフアイルの参照ファイル名から即座に特定できるため、データの特定がより簡便に、より迅速に行うことができる。

[0121] また、上記データ記録方法では、上記管理情報は、アフレコデータが複数のユーザプログラムから参照されている場合における参照回数を含む構成とすることができる。

[0122] 上記の構成によれば、例えば、あるユーザプログラムを削除するにあたって、この削除されるユーザプログラムで参照されているアフレコデータにおいて、該アフレコデータがユーザプログラムから参照されている参照回数が 1減らされる。そして、この参照回数を減らす処理によって参照回数が 0となったアフレコデータは、削除されるュ一ザプログラムのみで参照されるものであることが容易に確認できる。

[0123] また、上記データ記録方法では、上記管理情報は、アフレコデータを参照しているユーザプログラム名を含む構成とすることができる。

[0124] 上記の構成によれば、あるユーザプログラムを削除するにあたって、この削除されるユーザプログラムで参照されているアフレコデータの削除が指示された場合に、該ァフレコデータが他のユーザプログラムファイル力、ら参照されているか否かの情報の他に、どのファイルから参照されているかをユーザに提示することができる。

[0125] また、上記データ記録方法では、上記管理情報は、ユーザプログラムによって参照されているアフレコデータの参照範囲の情報を含む構成とすることができる。

[0126] 上記の構成によれば、各ユーザプログラムからアフレコデータのどの部分が参照されているかを示す参照範囲の情報を持たせることで、このような参照範囲情報により、アフレコデータ自体は複数のユーザプログラムから参照されてレ、ても要らなくなった部分のみを削除できるため、より有効に記録媒体の記録領域を活用することができる

産業上の利用の可能性

[0127] 映像データ、音声データをハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して記録 ·再生するデータ記録方法及びデータ記録装置において、ュ一ザプログラムの削除時、該ユーザプログラムにおいて参照していたアフレコデータが削除可能であるか否かの判断を容易にすることができる。

Claims

請求の範囲

[1] 記録媒体に、 AVデータと、該 AVデータと同期するアフレコデータとを記録するデータ記録方法であって、

記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成可能であり、かつ、アフレコデータが複数のユーザプ

ログラムから参照可能であり、

ユーザプログラムとアフレコデータとの関係を管理する管理情報を上記記録媒体上に記録するデータ記録方法。

[2] 上記アフレコデータは、複数のユーザプログラムにおいて参照されるアフレコデータ群を含む領域中の部分領域であり、前記領域はひとつのアフレコファイルとして記録されており、

上記管理情報は、オリジナルプログラムに対して 1つ存在する管理情報ファイル中にアフレコデータ毎に記録される請求の範囲第 1項に記載のデータ記録方法。

[3] 上記アフレコデータは、同一のユーザプログラムにおいて参照されるアフレコデータ群ごとにアフレコファイルとして記録されており、

上記管理情報は、複数の

オリジナルプログラムに対して 1つ存在する管理情報ファイル中にアフレコファイル毎に記録される請求の範囲第 1項に記載のデータ記録方法。

[4] 上記アフレコデータは、同一のユーザプログラムにおいて参照されるアフレコデータ群ごとにアフレコファイルとして記録されており、

上記管理情報は、オリジナルプログラムに対して 1つ存在する

管理情報ファイル中にアフレコファイル毎に記録される請求の範囲第 1項に記載のデータ記録方法。

[5] 上記管理情報は、アフレコデータが複数のユーザプログラムから参照されている場合における参照回数を含む請求の範囲第 1項に記載のデータ記録方法。

[6] 上記管理情報は、アフレコデータを参照しているユーザプログラム名を含む請求の範囲第 1項に記載のデータ記録方法。

[7] 上記管理情報は、ユーザプログラムによって参照されているアフレコデータの参照範囲の情報を含む請求の範囲第 1項に記載のデータ記録方法。

[8] 記録媒体に、 AVデータと、該 AVデータと同期するアフレコデータとを記録するデータ記録装置であって、

記録媒体上に、 AVデータの同一のシーンを使って複数のユーザプログラムを作成可能であり、かつ、アフレコデータが複数のユーザプログラムから参照可能であり、ユーザプログラムとアフレコデータとの参照関係を管理する管理情報を上記記録媒体上に記録するデータ記録装置。

[9] AVデータと、該 AVデータと同期するアフレコデータとが記録されたデータ記録媒体であって、

記録媒体上に記録した AVデータの同一のシーンを使って作成された複数のユーザプログラム力複数のユーザプログラムによって同一のアフレコデータを参照可能とするように記録されており、

さらに、ユーザプログラムとアフレコデータとの参照関係を管理する管理情報が記録されてレ、るデータ記録媒体。