JP2003022621A

JP2003022621A - データ記録方法、データ変更方法及びその装置

Info

Publication number: JP2003022621A
Application number: JP2001207244A
Authority: JP
Inventors: Jiro Kiyama; 次郎木山; Hirotoshi Iwano; 裕利岩野; Takayoshi Yamaguchi; 孝好山口
Original assignee: Sharp Corp
Current assignee: Sharp Corp
Priority date: 2001-07-09
Filing date: 2001-07-09
Publication date: 2003-01-24

Abstract

(57)【要約】【課題】 AVストリームに多重化した管理情報の更新を
容易にする。【解決手段】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニット（Record Unit）と、前記第
１のユニットを管理する管理情報（Movie fragment ato
m）とを、記録媒体に記録するデータ記録方法であっ
て、前記第１のユニットと前記管理情報とを、前記記録
媒体上で近傍に配置するものである。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、ハードディスク、
光ディスク等のランダムアクセス可能な記録媒体に対し
て、映像データ、音声データを記録・変更するデータ記
録方法、データ変更方法及びその装置に関するものであ
る。

【０００２】

【従来の技術】ディスクメディアを用いたビデオのディ
ジタル記録再生装置が普及しつつある。ディスクメディ
アではテープメディアと異なり、任意の箇所へのアクセ
スが短時間で可能であり、その性質を利用して、データ
をコピーすることなく１枚のディスク上で管理情報の書
換のみにより編集を行う非破壊編集あるいはノンリニア
編集と呼ばれる機能や、記録済みのデータを上書きする
ことなく、削除した後の分散した空き領域にまたがるビ
デオを記録する機能を実現することができる。

【０００３】ディスクメディアを用いたビデオ録画装置
においては、録画時に管理情報を最後にまとめて記録す
ることが一般的である。しかし、録画中に不意に電源が
切れたりして管理情報を記録することができなかった場
合、それまでに録画したデータを管理することができな
くなってしまう、すなわち再生不能になってしまうとい
う問題がある。

【０００４】この問題に対応するため、例えばMotion J
PEG 2000では、Fragmented movieという概念が導入され
ている。ここでは、Fragmented movieについてその概略
を説明する。Fragmented movieを含むMotion JPEG 2000
ファイルの典型的な構成を図３２に示す。

【０００５】先頭にそのファイル全体に共通する情報を
管理するMovie atomが配置され、その後に、部分AVスト
リームデータ（Movie fragmentと呼ぶ）を格納するMovi
e data atomと、そのMovie fragmentを管理するMovie f
ragment atomとが交互に配置される。

【０００６】録画時にはこの順番で記録を行なっていく
ことにより、仮に録画中に電源が切れた場合でも直前に
記録したMovie fragment atomと、それが管理するMovie
fragmentまではディスクに残っており、後で再生する
ことが可能となる。

【０００７】

【発明が解決しようとする課題】ディスクメディアにお
いても、テープメディアと同様、アフレコ機能が要求さ
れる。アフレコ機能に対応したAVストリームとして、図
３３に示すように、アフレコ時にデータを格納するため
の領域を多重化したものが考えられる。

【０００８】アフレコしたデータに関してもユーザの資
産であり、管理情報のバックアップにより極力保護する
ことが望まれる。しかしながら、上述のMotion JPEG200
0規格においては、このようなストリームに関する管理
情報の構成がない。

【０００９】本発明は、上記課題に鑑みてなされたもの
であり、アフレコデータに関する管理情報の保護を可能
にするデータ記録方法、データ変更方法を提供すること
を目的とする。

【００１０】

【課題を解決するための手段】本願の第１の発明は、映
像又は音声からなる第１のデータと、前記第１のデータ
と同期して再生される第２のデータとを格納する第１の
ユニットと、前記第１のユニットを管理する管理情報と
を、記録媒体に記録するデータ記録方法であって、前記
第１のユニットと前記管理情報とを前記記録媒体上で近
傍に配置することを特徴とする。

【００１１】本願の第２の発明は、映像又は音声からな
る第１のデータと、前記第１のデータと同期して再生さ
れる第２のデータとを格納する第１のユニットと、前記
第１のデータを管理する第１の管理情報と、前記第２の
データを管理する第２の管理情報とを、記録媒体に記録
するデータ記録方法であって、前記第２の管理情報と前
記第１の管理情報とを前記記録媒体上で分離して配置す
るとともに、１個以上の前記第２の管理情報を互いに前
記記録媒体上で近傍に配置することを特徴とする。

【００１２】本願の第３の発明は、映像又は音声からな
る第１のデータと、前記第１のデータと同期して再生さ
れる第２のデータとを格納する第１のユニットと、前記
第１のユニットを管理する管理情報とが、近傍に配置さ
れて記録された記録媒体に対し、前記第２のデータと前
記管理情報とを書き換えるデータ変更方法であって、前
記第２のデータと前記管理情報とを連続的に書き換える
ことを特徴とする。

【００１３】本願の第４の発明は、映像又は音声からな
る第１のデータと、前記第１のデータと同期して再生さ
れる第２のデータとを格納する第１のユニットと、前記
第１のデータを管理する第１の管理情報とが記録され、
さらに、前記第２の管理情報が１個以上互いに近傍に配
置されて記録された記録媒体に対し、前記第２のデータ
と前記第２の管理情報とを書き換えるデータ変更方法で
あって、前記第２の管理情報を連続して書き換えること
を特徴とする。

【００１４】本願の第５の発明は、映像又は音声からな
る第１のデータと、前記第１のデータと同期して再生さ
れる第２のデータとを格納する第１のユニットと、前記
第１のユニットを管理する管理情報とを、記録媒体に記
録するデータ記録装置であって、前記管理情報を前記記
録媒体上で前記第１のユニットの近傍に配置して記録す
る手段を備えたことを特徴とする。

【００１５】本願の第６の発明は、映像又は音声からな
る第１のデータと、前記第１のデータと同期して再生さ
れる第２のデータとを格納する第１のユニットと、前記
第１のデータを管理する第１の管理情報と、前記第２の
データを管理する第２の管理情報とを、記録媒体に記録
するデータ記録装置であって、前記第２の管理情報と前
記第１の管理情報とを前記記録媒体上で分離して配置す
るとともに、１個以上の前記第２の管理情報を互いに前
記記録媒体上で近傍に配置して記録する手段を備えたこ
とを特徴とする。

【００１６】本願の第７の発明は、映像又は音声からな
る第１のデータと、前記第１のデータと同期して再生さ
れる第２のデータとを格納する第１のユニットと、前記
第１のユニットを管理する管理情報とが、近傍に配置さ
れて記録された記録媒体に対し、前記第２のデータと前
記管理情報とを書き換えるデータ変更装置であって、前
記管理情報を前記第２のデータと連続的に書き換える手
段を備えたことを特徴とする。

【００１７】本願の第８の発明は、映像又は音声からな
る第１のデータと、前記第１のデータと同期して再生さ
れる第２のデータとを格納する第１のユニットと、前記
第１のデータを管理する第１の管理情報とが記録され、
さらに、前記第２の管理情報が１個以上互いに近傍に配
置されて記録された記録媒体に対し、前記第２のデータ
と前記第２の管理情報とを書き換えるデータ変更装置で
あって、前記第２の管理情報を連続して書き換える手段
を備えたことを特徴とする。

【００１８】

【発明の実施の形態】以下、本発明の実施形態につい
て、図面を参照しながら詳細に説明する。

【００１９】＜システム構成＞図１は本実施形態におい
て共通に用いる、アフレコ可能なビデオディスクレコー
ダの構成図である。この装置は、図１に示すように、バ
ス100、ホストCPU101、RAM102、ROM103、ユーザインタ
フェース104、システムクロック105、光ディスク106、
ピックアップ107、ECCデコーダ108、ECCエンコーダ10
9、再生用バッファ110、記録/アフレコ用バッファ111、
デマルチプレクサ112、マルチプレクサ113、多重化用バ
ッファ114、オーディオデコーダ115、ビデオデコーダ11
6、オーディオエンコーダ117、ビデオエンコーダ118、
および図示しないカメラ、マイク、スピーカ、ディスプ
レイ等で構成される。

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

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

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

【００２３】オーディオデータの符号化方式にはMPEG-1
Layer-IIを、ビデオデータの符号化方式にはMPEG-2を
それぞれ用いる。

【００２４】光ディスク106は、外周から内周に向かっ
て螺旋状に記録再生が行われる脱着可能な光ディスクと
する。2048byteを1セクタとし、誤り訂正のため16セク
タでECCブロックを構成する。ECCブロック中のデータを
書き換える場合、そのデータが含まれるECCブロック全
体を読み込み、誤り訂正を行って、対象のデータを書き
換え、再び誤り訂正符号を付加し、ECCブロックを構成
して、記録媒体に記録する必要がある。また、光ディス
ク106は、記録効率を上げるためZCAV（ゾーン角速度一
定）を採用しており、記録領域は回転数の異なる複数の
ゾーンで構成される。

【００２５】＜ファイルシステム＞光ディスク106上の
各種情報を管理するためにファイルシステムを用いる。
ファイルシステムには、パーソナルコンピュータ（PC）
との相互運用を考慮してUDF（Universal Disk Format）
を使用する。ファイルシステム上では、各種管理情報や
AVストリームはファイルとして扱われる。

【００２６】ユーザエリアは、2048byteの論理ブロック
（セクタと一対一対応）で管理される。各ファイルは、
整数個のエクステント（連続した論理ブロック）で構成
され、エクステント単位で分散して記録しても良い。空
き領域は、Space Bitmapを用いて論理ブロック単位で管
理される。

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

【００２８】QuickTimeファイルフォーマットは、ビデ
オデータやオーディオデータ等（これらを総称してメデ
ィアデータとも呼ぶ）と管理情報とで構成される。両者
を合わせてここでは、QuickTimeムービー（略してムー
ビー）と呼ぶ。両者は同じファイル中に存在しても、別
々のファイルに存在しても良い。

【００２９】同じファイル中に存在する場合は、図２
（a）に示すような構成をとる。各種情報はatomという
共通の構造に格納される。管理情報はMovie atomという
構造に格納され、AVストリームはMovie data atomとい
う構造に格納される。尚、Movieatom中の管理情報に
は、メディアデータ中の任意の時間に対応するAVデータ
のファイル中での相対位置を導くためのテーブルや、メ
ディアデータの属性情報や、後述する外部参照情報等が
含まれている。

【００３０】一方、管理情報とメディアデータを別々の
ファイルに格納した場合は、図２（b）に示すような構
成をとる。管理情報はMovie atomという構造に格納され
るが、AVストリームはatomには格納される必要はない。
このとき、Movie atomはAVストリームを格納したファイ
ルを「外部参照」している、という。

【００３１】外部参照は、図２（c）に示すように、複
数のAVストリームファイルに対して行うことが可能であ
り、この仕組みにより、AVストリーム自体を物理的に移
動することなく、見かけ上編集を行ったように見せる、
いわゆる「ノンリニア編集」「非破壊編集」が可能にな
る。

【００３２】それでは、図３乃至図１２を用いて、Quic
kTimeの管理情報のフォーマットについて説明する。ま
ず、共通の情報格納フォーマットであるatomについて説
明する。atomの先頭には、そのatomのサイズであるAtom
size、そのatomの種別情報であるTypeが必ず存在す
る。Typeは4文字で区別され、例えばMovie atomでは'mo
ov'、Movie data atomでは'mdat'となっている。

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

【００３４】Track atomの構成を図４に示す。Track he
ader atomは、そのトラックの全体的な属性を管理す
る。Edit atomは、メディアデータのどの区間を、ムー
ビーのどのタイミングで再生するかを管理する。Track
reference atomは、別のトラックとの関係を管理する。
Media atomは、実際のビデオやオーディオといったデー
タを管理する。

【００３５】Track header atomの構成を図５に示す。
ここでは、後での説明に必要なもののみについて説明す
る。flagsは属性を示すフラグの集合である。代表的な
ものとして、Track enabledフラグがあり、このフラグ
が1であれば、そのトラックは再生され、0であれば再生
されない。layerはそのトラックの空間的な優先度を表
しており、画像を表示するトラックが複数あれば、laye
rの値が小さいトラックほど画像が前面に表示される。

【００３６】Media atomの構成を図６に示す。Media he
ader atomは、そのMedia atomの管理するメディアデー
タに関する全体的な属性等を管理する。Handler refere
nceatomは、メディアデータをどのデコーダでデコード
するかを示す情報を格納する。Media information atom
は、ビデオやオーディオ等メディア固有の属性情報を管
理する。

【００３７】Media information atomの構成を図７に示
す。Media information header atomは、ビデオやオー
ディオ等メディア固有の属性情報を管理する。Handler
reference atomは、Media atomの項で説明した通りであ
る。Data information atomは、そのQuickTimeムービー
が参照するメディアデータを含むファイルの名前を管理
するatomであるData reference atomを含む。Sample ta
ble atomは、データのサイズや再生時間等を管理してい
る。

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

【００３９】また、QuickTimeフォーマットでは、個々
のサンプルの再生時間長およびデータサイズを管理して
いる。また、同一トラックに属するサンプルが再生時間
順にファイル中で連続的に配置された領域をチャンクと
呼ぶ。チャンクにも再生時間順に、1から番号がついて
いる。

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

【００４１】Sample table atomの構成を図９に示す。S
ample description atomは、個々のチャンクのデータフ
ォーマット（Data format）やサンプルが格納されてい
るファイルのチャンクのインデックス等を管理する。Ti
me-to-sample atomは、個々のサンプルの再生時間を管
理する。

【００４２】Sync sample atomは、個々のサンプルのう
ち、デコード開始可能なサンプルを管理する。Sample-t
o-chunk atomは、個々のチャンクに含まれるサンプル数
を管理する。Sample size atomは、個々のサンプルのサ
イズを管理する。Chunk offset atomは、個々のチャン
クのファイル先頭からのアドレスを管理する。

【００４３】Edit atomは、図１０に示すように、1個の
Edit list atomを含む。Edit listatomはNumber of ent
riesで指定される個数分の、Track duration、Media ti
me、Media rateの値の組（エントリ）を持つ。各エント
リは、トラック上で連続的に再生される区間に対応し、
そのトラック上での再生時間順に並んでいる。

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

【００４５】図１１にEdit listの使用例を示す。ここ
では、Edit list atomの内容が図１１（a）に示す内容
であり、さらにサンプルの構成が図１１（b）であった
とする。尚、ここではi番目のエントリのTrack duratio
nをD(i)、Media timeをT(i)、Media rateをR(i)とす
る。このとき、実際のサンプルの再生は、図１１（c）
に示す順に行われる。このことについて簡単に説明す
る。

【００４６】まず、エントリ#1はTrack durationが1300
0、Media timeが20000、Media rateが1であるため、そ
のトラックの先頭から13000の区間はサンプル中の時刻2
0000から33000の区間を再生する。次に、エントリ#2はT
rack durationが5000、Mediatimeが-1であるため、トラ
ック中の時刻13000から18000の区間、何も再生を行わな
い。

【００４７】最後に、エントリ#3はTrack durationが10
000、Media timeが0、Media rateが1であるため、トラ
ック中の時刻18000から28000の区間において、サンプル
中の時刻0から10000の区間を再生する。

【００４８】図１２にUser data atomの構成を示す。こ
のatomには、QuickTimeフォーマットで定義されてない
独自の情報を任意個数格納することができる。1個の独
自情報は1個のエントリで管理され、1個のエントリはSi
zeとTypeとUser dataで構成される。Sizeはそのエント
リ自体のサイズを表し、Typeは独自情報をそれぞれ区別
するための識別情報、User dataは実際のデータを表
す。

【００４９】次に、録画中の電源遮断等に対応するため
に、QuickTimeファイルフォーマットに導入された概念
であるFragmented Movieについて説明する。Fragmented
movieは、QuickTime フォーマットの1アプリケーショ
ンであるMotion JPEG2000で導入された概念であり、上
述のSample table atomに相当する情報を、部分的なAV
ストリーム毎に管理することが可能となっている。

【００５０】Fragmented movieを導入したQuickTimeフ
ァイルの全体構成を図１３に示す。先頭に、そのファイ
ル全体に共通する情報を管理するMovie atomが配置さ
れ、その後に、Movie fragmentを格納するMovie data a
tomと、そのMovie fragmentを構成するサンプルのアド
レスやサイズ、再生時間等を管理するMovie fragment a
tomとが交互に配置される。尚、AVストリームデータ
は、通常のQuickTimeファイルと同様、別ファイルに存
在しても構わない。

【００５１】録画時にはこの順番で記録を行なっていく
ことにより、録画時の電源切断による被害を最小限に防
ぐことが可能となっている。Movie atomには、そのQuic
kTimeムービーがFragmented movieであることを示すた
めのMovie extends atomが含まれる。Movie extends at
omには、そのムービーに含まれる各トラックに関するデ
フォルト値が格納される。

【００５２】また、Movie fragment atomには、そのMov
ie fragment atomが管理するMoviefragmentに関する管
理情報が含まれている。管理情報には、その管理するMo
viefragment全体に関する情報を格納するMovie fragmen
t header atoｍと、Movie fragment中の各トラックに関
する情報を格納するTrack fragment atomとがある。

【００５３】Track fragment atomは、それが管理する
トラックに属するMovie fragmentに関する情報を格納す
るTrack fragment header atomと、そのトラックに属す
るMovie fragmentを構成する論理的な連続領域（Track
runと呼ばれる）をそれぞれ管理するTrack fragment ru
n atomとを含む。以下に、各atomについて詳しく説明す
る。

【００５４】Movie extends atomの構成を図１４に示
す。Movie extends atomは、前述のように、このatomを
含むQuickTimeムービーがFragmented movieであること
を示す役割を持つ。

【００５５】Track extends atomの構成を図１５に示
す。Track extends atomは、このQuickTimeムービーに
含まれる各トラックのサンプルのデフォルト値を設定す
るために存在する。track IDはMovie atom中で定義され
ているトラックのtrack IDを参照する。default-sample
-で始まるフィールドは、このatomで管理されるtrack f
ragmentのデフォルト値を設定する。

【００５６】Movie fragment atomの構成を図１６に示
す。録画中に逐次記録される管理情報はこのatomであ
る。このatomは、前述のとおり、このatomの管理するMo
vie fragmentに関する実際の情報を格納するatomである
Movie fragment header atomやTrack fragment atomを
含む。

【００５７】Movie fragment header atomの構成を図１
７に示す。このatomに格納されている主な情報はsequen
ce-numberである。sequence-numberは、このatomが含ま
れるMovie fragment atomが管理するMovie fragmentの
先頭からの順番を表す。

【００５８】Track fragment atomの構成を図１８に示
す。Track fragment atomは、Moviefragmentに含まれる
特定のトラックのサンプルに関する管理情報であるTrac
k fragment header atomやTrack fragment run atomを
格納する。

【００５９】Track fragment header atomの構成を図１
９に示す。このatomは、Movie fragmentに含まれる特定
のトラックのサンプルに関するデフォルト値等を格納す
る。track-IDは、Movie atom中で定義されているトラッ
クのtrack IDとの対応を示す。sample-description-ind
exは、このatomが管理するサンプルの参照するsamplede
scription tableのインデックス番号、default-sample
で始まるフィールドは、それぞれこのatomが管理するサ
ンプルのデフォルト値である。

【００６０】Track fragment run atomの構成を図２０
に示す。このatomは、Track runと呼ばれる、このatom
の管理する連続領域や個々のサンプルの管理情報を格納
する。sample-countはTrack runに含まれるサンプルの
個数を示す。data-offsetはbase-data-offsetからのTra
ck runのオフセット値を示す。sample-で始まるフィー
ルドはこのatomが管理するサンプルの再生時間等の値を
格納する。ただし、上述のデフォルト値と同じであれ
ば、省略してデータサイズを縮小することが可能となっ
ている。

【００６１】＜インデックス・ファイル＞ディスク内に
含まれるQuickTimeムービーを管理するため、AVインデ
ックス・ファイルという特別のQuickTimeムービーファ
イルをディスク内に１個置く。

【００６２】AVインデックス・ファイルには、ディスク
内のファイル（QuickTimeムービーやQuickTimeムービー
から参照されている静止画等）に関するサムネイルや各
種属性が登録されている。各種属性の中には、そのファ
イルが外部参照されている回数を示すlink countがあ
る。

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

【００６４】＜実施例＞本発明の一実施例について、図
２１乃至図３１を用いて説明する。

【００６５】＜AVストリームの形態＞まず、本実施例に
おけるAVストリームの構成について、図２１及び図２２
を用いて説明する。AVストリームは整数個のRecord Uni
t（RU）で構成される。RUはディスク上で連続的に記録
する単位である。RUの長さは、AVストリームを構成する
RUをどのようにディスク上に配置してもシームレス再生
（再生中に画像や音声が途切れないで再生できること）
やリアルタイムアフレコ（アフレコ対象のビデオをシー
ムレス再生しながらオーディオを記録すること）が保証
されるように設定される。この設定方法については後述
する。

【００６６】また、RU境界がECCブロック境界と一致す
るようにストリームを構成する。RUのこれらの性質によ
って、AVストリームをディスクに記録した後も、シーム
レス再生を保証したまま、ディスク上でRU単位の配置を
容易に変更することができる。

【００６７】RUは、整数個のVideo Unit（VU）とPost R
ecording Unit（PRU）で構成される。VUは単独再生可能
な単位であり、そのことから再生の際のエントリ・ポイ
ントとなりうる。PRUは同じRUに含まれるVUと同期再生
するデータを記録するための領域である。

【００６８】VU構成を図２２に示す。VUは、1秒程度の
ビデオデータを格納した整数個のGOP（グループ・オブ
・ピクチャ）と、それらと同じ時間に再生されるメイン
オーディオデータを格納した整数個のAAU（オーディオ
・アクセス・ユニット）とから構成される。

【００６９】尚、GOPは、MPEG-2ビデオ規格における画
像圧縮の単位であり、複数のビデオフレーム（典型的に
は15フレーム程度）で構成される。AAUはMPEG-1 Layer-
II規格における音声圧縮の単位で、1152点の音波形サン
プル点により構成される。サンプリング周波数が48kHz
の場合、AAUあたりの再生時間は0.024秒となる。VU中で
は、AV同期再生のために必要となる遅延を小さくするた
め、AAU、GOPの順に配置する。

【００７０】また、VU単位で独立再生を可能とするため
に、VU中のビデオデータの先頭にはSequence Header（S
H）を、末尾にはSequence End Code（SEC）を置く。VU
の再生時間は、VUに含まれるビデオフレーム数にビデオ
フレーム周期をかけたものと定義する。さらに、VUを整
数個組み合わせてRUを構成する場合、RUの始終端をECC
ブロック境界に合わせるため、VUの末尾を0で埋める。

【００７１】PRUの領域サイズは、ここではRUの再生時
間にオーディオの最大ビットレートをかけたものとす
る。

【００７２】＜AVストリーム管理方法＞上記のAVストリ
ームの管理情報の構成について説明する。ＡＶストリー
ムは、図２３に示すように、ムービーファイル2401と、
ムービーファイル2401の管理情報のバックアップに相当
する管理情報バックアップファイル2402とで管理され
る。

【００７３】ムービーファイル2401は、Movie data ato
mに格納されたＡＶストリームと、ＡＶストリームを構
成するサンプルのアドレスやサイズ、再生時間等を管理
するMovie atomとで構成される。ＡＶストリームは、前
述のように、ＲＵで構成され、各ＲＵは必ずディスク上
で連続的に配置されるように記録される。

【００７４】一方、管理情報バックアップファイル2402
は、ムービーファイル2401中の各ＲＵを管理するMovie
fragment atomで構成される。この２つのファイルを、
図２３に示すように、ディスク上においてＲＵ単位で多
重化する。このような構成を取る理由を以下に説明す
る。

【００７５】図１３のような構成を取った場合、光ディ
スクにおいては録画時には都合が良いが再生時には都合
が悪い。なぜならば、録画時にはシークを行うことな
く、その時点までの管理情報をMovie fragment atomに
記録できるのに対し、再生時には、Movie data atom#1
を再生するためには、まずMovie fragment atom#1を読
み込む必要があるため、ピックアップを行ったり来たり
させなければならず、読み込みの効率が悪くなるからで
ある。

【００７６】このとき、図２３に示すような構成を取る
ことで、録画中の電源断やムービーファイル2401のMovi
e atomの破損時のバックアップが可能となると同時に、
Movie fragment atomを用いない場合と同様、再生時の
効率的な管理情報の読み込みが可能となる。

【００７７】尚、上記の2ファイルはディスク上で多重
化して記録するが、全体をディスク上で連続的に記録す
る必要はなく、各Record Unitと直前のMovie fragment
とが連続的に記録されていれば良い。つまり、図２４に
示す不連続可能点以外ではディスク上で連続的に記録す
る。このような連続記録を行う理由は、アフレコ時にお
いてPRUへの記録の直前に、アフレコに伴って必要とな
るMovie fragmentの更新を、シークが加わることなく可
能にするためである。

【００７８】また、図２３においては、Movie fragment
atomとＲＵとが接しているように記載されているが、
実際にはMovie fragment atomとＲＵとの間には、Movie
fragment atomの先頭からＲＵの直前までのバイト数が
1ＥＣＣブロックサイズの整数倍になるように、パディ
ングとしてFree space atomを挿入する。Free spaceato
mとは、QuickTimeファイルフォーマットで規定されてい
るatomで、領域の確保に利用される。

【００７９】次に、ムービーファイル2401の管理情報の
構成について説明する。ムービーファイル2401の管理情
報は、ビデオデータ用のビデオトラック、メインオーデ
ィオ用のメインオーディオトラック、アフレコ領域管理
用のアフレコ領域トラックおよび実際にアフレコされた
データを管理するためのアフレコオーディオトラックで
構成される。

【００８０】ビデオトラックは、Sequence headerからS
equence end codeまでのビデオデータを1サンプル、VU
中のビデオの塊を1チャンクとして管理する。メインオ
ーディオトラックは、AAUを1サンプル、VU中のオーディ
オの塊を1チャンクとして管理する。アフレコ領域トラ
ックは、PRUに所定のビットレートでオーディオデータ
を記録したものとして、AAUを1サンプル、PRUを1チャン
クとして管理する。

【００８１】ただし、このトラックはどのタイミングの
オーディオデータをどこに記録するかを知らせるための
ものであり、誤って再生しないよう、Track header ato
mのflagを再生不可に設定する。アフレコオーディオト
ラックは、PRUに実際に記録されているオーディオデー
タに関して１AAUを1サンプル、PRU中の連続記録データ
を1チャンクとして管理する。

【００８２】次に、管理情報バックアップファイル2402
の管理情報の構成について説明する。ムービーファイル
2401と同様、ビデオトラック、メインオーディオトラッ
ク、アフレコ領域トラック、アフレコオーディオトラッ
クで構成し、AAUを1サンプル、Sequence headerからSeq
uence end codeまでのビデオデータを1サンプルとして
管理する。

【００８３】バックアップ管理情報ファイルにおけるPR
Uの管理方法について、図２５に示す構成のＲＵを例に
とって説明する。ここでは、ＲＵはムービーファイルの
先頭からＬバイトの位置にあるとする。また、ＰＲＵ
は、10個のAAUで構成され、先頭から4個のAAUは未アフ
レコ、後半の6個のAAUはアフレコ済みとする。そしてま
た、各AAUは再生時間0.024秒、サイズは768バイトであ
るとする。

【００８４】このとき、図２６に示すように、Movie ex
tends atom中のアフレコ領域トラックおよびアフレコオ
ーディオトラックのdefault-sample-sizeは768、defaul
t-sample-durationは2160（1秒の細かさであるTimescal
eを90000とした場合）となる。

【００８５】また、このMovie fragmentを管理するMovi
e fragment atom中のアフレコ領域トラックおよびアフ
レコオーディオトラックの内容は、図２７に示すとおり
になる。まず、アフレコ領域トラックに関しては、PRU
中の全サンプルを管理するため、sample-countは10とな
る。

【００８６】次に、アフレコオーディオトラックに関し
ては、アフレコ済みのサンプルのみを管理するため、sa
mple-countは6となり、data-offsetはPRUの先頭からア
フレコ済みの先頭サンプルまでのバイト数となる。アフ
レコを行う際には、アフレコオーディオトラックのこれ
らの値を書き換えることになる。

【００８７】＜Record Unit再生時間決定方法＞まず、
アフレコ対応ストリームにおけるRU再生時間の決定方法
について説明する。この決定方法では、機器間での互換
性確保のため、基準となるデバイス（リファレンス・デ
バイス・モデル）と基準となるアフレコアルゴリズム
（リファレンス・アフレコ・アルゴリズム）とを想定
し、次にそれらを用いてアフレコを行った際にシームレ
ス再生が破綻しないように、RU再生時間を決める。

【００８８】それではまず、リファレンス・デバイス・
モデルについて、図２８を用いて説明する。リファレン
ス・デバイス・モデルは、1個のピックアップとそれに
つながるECCエンコーダ・デコーダ501、トラックバッフ
ァ502、デマルチプレクサ503、アフレコ用バッファ50
4、オーディオエンコーダ509、ビデオバッファ505、オ
ーディオバッファ506、ビデオデコーダ507、オーディオ
デコーダ508より構成される。

【００８９】本モデルでは、ピックアップが1個である
ため再生用データのディスクからの読み出しとアフレコ
用データのディスクへの記録は時分割で行う。ディスク
から再生用データを読み出す際、PRUと直前のMovie fra
gment atomを含めて読み出す。読み出されたMovie frag
ment atomとPRUを含むECCブロック（PRUブロック）は、
トラックバッファ502からアフレコ用バッファ504に送ら
れる。

【００９０】オーディオエンコーダ509は、AAU周期でア
フレコ用バッファ504に出力する。この出力によって、
アフレコ用バッファ504中の対応するPRUブロックを上書
きする。アフレコデータの記録は、PRUブロックを所定
のECCブロックに記録することで行う。

【００９１】本モデルにおいて、Movie fragment atom
とPRUブロックをトラックバッファ502からアフレコ用バ
ッファ504に送ることを想定しているのは、Movie fragm
ent atomおよびPRUの書き換えに伴うECCブロックの再度
読み出しを省略するためである。

【００９２】本モデルにおけるシームレス再生は、VUの
デコード開始時にトラックバッファ502上に少なくとも1
個VUが存在すれば保証されるものとする。ECCデコーダ5
01からデータの出力速度はRsとする。また、アクセスに
よる読み出し、記録の停止する最大期間をTaとする。

【００９３】尚、これら期間にはシーク時間、回転待ち
時間、アクセス後に最初にディスクから読み出したデー
タがECCから出力されるまでの時間が含まれる。本実施
例ではRs=20Mbps、Ta=1秒とする。

【００９４】本実施例におけるリファレンス・アフレコ
・アルゴリズムについて、図２９を用いて説明する。
尚、図２９中の（１）から（８）までの番号は、以下の
説明中の（１）から（８）までの番号に対応する。アル
ゴリズムの概要は次の通りである。

【００９５】（１）再生用データの読み出しを行う。
（２）N番目のPRUであるPRU#Nに対応するオーディオデ
ータのエンコードが終了すると同時にMovie fragment a
tom#N-1へのアクセスを行う。（３）Movie fragment at
om#N-1とPRU#Nに対応するPRUブロックをディスクに記録
する。（４）元の読み出し位置に戻る。（５）再生用デ
ータの読み出しを行う。読み出しの際にRU境界を跨ぎ、
分断のジャンプが発生するが、そのまま読み出しを続け
る。

【００９６】（６）N+1番目のPRUであるPRU#N+1に対応
するオーディオデータのエンコードが終了すると同時
に、Movie fragment atom#Nへのアクセスを行う。
（７）Moviefragment atom#NとPRU#N+1に対応するPRUブ
ロックをディスクに記録する。（８）元の読み出し位置
に戻る。以上の動作を繰り返す。

【００９７】前記リファレンス・デバイス・モデルにお
いて、前記リファレンス・アフレコ・アルゴリズムを用
いてアフレコを行った場合、次のような条件を満たせ
ば、トラックバッファ502のアンダーフローがないこと
を保証することができる。

【００９８】その条件とは、AVストリーム中の任意のRU
であるRU#iについて最大再生時間をT(i)、分断ジャンプ
を含めた最大読み出し時間をTr(i)、RU#i中のPRUの最大
記録時間をTw(i)としたとき、 Te(i)≧Tr(i)+Tw(i) ・・・＜式 1＞が成立することである。

【００９９】なぜなら、この式は、シームレス再生の十
分条件である任意のnにおける

【０１００】

【数１】

【０１０１】を満たす十分条件であるためである。

【０１０２】また、PRUエンコード完了に同期してアフ
レコデータのディスクへの記録を行っているため、アフ
レコ用バッファ504中のデータが累積していくことはな
く、アフレコ用バッファ504のオーバーフローもない。

【０１０３】＜式１＞中のTr(i)は、AVストリーム中の
メインオーディオとサブオーディオ、ビデオの最大ビッ
トレートをそれぞれRa、Rp、Rv、ECCブロックサイズをL
yとしたとき、 Tr(i)=Te(i)×(Rv+Ra+Rp)/Rs+Ta+Ly/Rs ・・・＜式３＞となる。

【０１０４】右辺第1項はRU#iの読み出し時間を表す。
右辺第2項はRU#i読み出し直後に発生する分断ジャンプ
による最大アクセス時間を表す。右辺第3項は、Movie f
ragment atom読み出し時間を表す。

【０１０５】尚、Movie fragment atomのサイズはRU再
生時間と比例関係にあるが、録画時の電源断に対応した
10秒程度ではそのサイズが１ECCブロックを越えること
はないため、Movie fragment atomの読み出し時間は１E
CCブロック読み出し時間とした。

【０１０６】また、Tw(i)は、 Tw(i)=2Ta+Te(i)×Rp/Rs+Ly/Rs+Ly/Rs・・・＜式４＞である。

【０１０７】ここで、右辺第1項はRUへの往復アクセス
時間を示す。PRUへの往復のアクセス時間に最大アクセ
ス時間Taを用いているのは、以下の理由に基づく。

【０１０８】現在読み出しているトラックと記録すべき
PRUの存在するトラックの距離は、そのときの再生用バ
ッファによる遅延時間に依存する。しかし、遅延時間は
再生用バッファサイズによって異なり、また同じバッフ
ァサイズであっても、直前に衝撃によって読み出しが一
時的に停止した場合にも異なる。

【０１０９】すなわち、アクセスする距離は不定であ
り、そのため最悪値で見積もる必要がある。右辺第２項
は、RU#iに含まれるPRUをディスクに記録するための時
間の合計を表す。右辺第３項はPRU両端が含まれるECCブ
ロック中のアフレコデータ以外の記録時間の最大値を表
している。このような項が必要な理由は、PRUの両端はE
CCブロック境界と一致しているとは限らないため、PRU
記録時には、PRUのサイズより最大１ECCブロック分多く
記録することになるためである。右辺第4項はMovie fra
gment atomの記録に要する時間を表す。

【０１１０】このとき、＜式１＞に＜式３＞と＜式４＞
を代入して、Te(i)で解くと、リアルタイムアフレコを
保証可能なTe(i)の条件 Te(i)≧(3Ta×Rs+3Ly)/(Rs-Rv-Ra-2Rp) ・・・＜式５＞が得られる。

【０１１１】つまり、アフレコ保証可能なRU再生時間下
限値Teminは、 Temin=(3Ta×Rs+3Ly)/(Rs-Rv-Ra-2Rp) ・・・＜式６＞となる。

【０１１２】このとき、RU再生時間の上限値Temaxを次
のように設定する。 Temax=Temin+Tvmax・・・＜式７＞ここで、TvmaxはVUの最大再生時間である。上限値を設
定するのは、次の理由に基づく。Teが大きくなるにした
がって、アフレコ時において図２９の（２）から（８）
までの期間が長くなる。この間は再生用データのディス
クからの読み出しができないため、再生を継続するため
には、Teの増加に応じて、トラックバッファ502のサイ
ズを増やす必要がある。

【０１１３】上限値を設定するのは、このとき必要とな
るトラックバッファ502のサイズを見積り可能にするた
めである。また、下限値と上限値の間にVUの最大再生時
間分のマージンがあることにより、任意の再生時間の組
み合わせでRUを構成することが可能である。

【０１１４】尚、ここでは最大再生時間をAVストリーム
のビットレートに応じて設定しているが、可能な最大の
ビットレートに基づき、AVストリームのビットレートに
関わらず一定としても良い。

【０１１５】＜記録時の処理＞ユーザから録画が指示さ
れた場合の処理を、図３０とともに説明する。このとき
記録するAVストリームは、ビデオのビットレートRv=5Mb
ps、メインオーディオのビットレートRa=256kbps、アフ
レコオーディオのビットレートRp=256kbpsで、VU再生時
間Tv=約0.5秒固定アフレコ対応ストリームとする。ま
た、ファイルシステムの管理情報はすでにRAM上に読み
込まれているものとする。

【０１１６】まず、ストリームの構成や連続領域の構成
を決定する（ステップ701）。1VUを1GOP15フレームで構
成するとしたとき、＜式６＞＜式７＞にRs=20Mbps、Ta=
1秒、Rv=5Mbps、Ra=256kbps、Rp=256kbps 、Tvmax=約0.
5秒を代入し、Te(i)の範囲4.4秒以上4.9秒以下が得られ
る。

【０１１７】Tvmax=約0.5秒でこの条件を満たすのは、T
e(i)=4.5 秒のときとなり、9個のVU毎にPRUが挿入され
ることになる。MPEG-1 audio layer-IIにおいて、ビッ
トレート256kbpsのとき、AAUの再生時間Tafは0.024秒、
サイズは768byteとなり、このときのPRUの領域サイズ
は、144384byteとなる。また、連続領域には1個のPRUと
9個のVUと1個のMovie fragment atomとが含まれるよう
にする。

【０１１８】まず、9個のVUと1個のPRUを連続的に記録
可能な空き領域を探す。Movie fragment atomを考慮し
ない理由は、先頭のRUだけはMovie fragment atomと連
続的に記録する必要がないためである。具体的には、9
×Tvmax×(Ra+Rv)+9×Tav×Ra、つまり24.8Mbit以上の
連続的な空き領域をRAM102上のSpace Bitmapを参照して
探す。存在しなければ、録画を中止し、録画できないこ
とをユーザに知らせる（ステップ702）。

【０１１９】また、オーディオエンコーダ117、ビデオ
エンコーダ118をそれぞれ起動する（ステップ703）。そ
して、記録用バッファに1ECCブロック分(32KB)以上のデ
ータが蓄積されているかどうかをチェックし（ステップ
704）、蓄積されている間、ステップ705からステップ70
8を繰り返す。

【０１２０】蓄積されていれば、次に記録するディスク
上のECCブロックの空き状況をRAM上のSpace Bitmapを参
照して調べる（ステップ705）。空きがなれば、9個のVU
とPRUと1個のMovie fragment atomを記録可能な連続的
な空き領域を探し（ステップ707）、その空き領域の先
頭へピックアップを移動する（ステップ708）。

【０１２１】そして、記録用バッファ111中の1ECCブロ
ック分のデータをディスクに記録する（ステップ70
6）。記録用バッファ111にデータが蓄積されていなけれ
ば、記録終了が指示されているかどうかをチェックし
（ステップ709）、記録終了でなければ、ステップ704を
実行する。

【０１２２】記録終了が指示されていた場合、以下のス
テップを実行する。まず、記録用バッファ中の32KBに満
たないデータに関して、末尾にダミーデータを付加し32
KBにする（ステップ710）。次に、そのデータをディス
ク上に記録する（ステップ711〜ステップ714）。RAM102
上のQuickTime管理情報とファイルシステム管理情報と
を光ディスク106に記録する（ステップ715〜ステップ71
6）。

【０１２３】以上の処理と並行するオーディオエンコー
ダ117、ビデオエンコーダ118やマルチプレクサ113の動
作について説明する。それぞれのエンコーダはマルチプ
レクサ113にエンコード結果を送り、マルチプレクサは
それらを多重化用バッファ114に格納する。

【０１２４】1VU分のデータ、つまり1GOPとそれに同期
して再生されるAAUが多重化用バッファ114に蓄積された
ら、マルチプレクサ113は記録用バッファ111に1VUのデ
ータを送る。このとき、そのVUが9×i番目（iは0以上の
整数）のVUであったら、上述のサイズを持ったPRUを先
に記録用バッファ111に送る。

【０１２５】さらに、ホストCPU101に1VU分のデータが
エンコードできたことを通知し、ホストCPU101はVUを構
成するGOPやAAUの数およびサイズを基にRAM102上のQuic
kTime管理情報を更新する。＜アフレコ時の処理＞ユーザからアフレコが指示された
場合の処理を図３１とともに説明する。ここで、アフレ
コの対象となるAVストリームに関するQuickTime管理情
報は、すでにRAM102に読み込まれているものとする。

【０１２６】まず、アフレコ開始位置を含むディスク上
のVUの先頭から再生用データの読み出しを行う（ステッ
プ802）。このとき、十分な再生時間分のデータを読み
出すまでステップ802を繰り返す（ステップ803）。ここ
で十分とは、再生用データ読み出しの中断期間が最大の
場合でも再生が途切れないだけのデータ量を意味する。

【０１２７】また、PRUを読み出した際には、Movie fra
gment atomおよびPRUを含むECCブロックをアフレコ用バ
ッファ111に送る。このとき、アフレコ用バッファ111中
のPRUを管理するために、アフレコ用バッファ111中の各
PRUの再生開始時間（AVストリームの先頭からの相対時
間）とアフレコ用バッファ111中でのアドレスの組をテ
ーブルとしてRAM102に保持する。

【０１２８】次に、ビデオデコーダ116とオーディオデ
コーダ115および、オーディオエンコーダ117を起動する
（ステップ804）。オーディオエンコーダ117は、サンプ
リングされた音声波形をAAUにエンコードし、AAUの周期
でマルチプレクサ113に送る。その際に、各AAUについて
AVストリームの先頭からの相対時間を付加する。

【０１２９】マルチプレクサ113は、AAUに付加された時
間に基づき、AAUをアフレコ用バッファ111中のPRUに格
納する。また、ステップ802で読み出したMovie fragmen
t atom中のアフレコオーディオトラックの内容を更新
し、アフレコ用バッファ111に格納する。RU中の最後のP
RUにAAUを最後まで格納し終わったら、ホストCPU101にR
Uのエンコード終了を通知する。

【０１３０】次に、ユーザからアフレコ終了を指示され
ていないかチェックする（ステップ805）。指示されて
いなければ、PRUのエンコードが終了するまで、ステッ
プ802と同様に、再生用データの読み出しを行う（ステ
ップ809）。

【０１３１】マルチプレクサ部からRUエンコード終了が
通知されたら（ステップ806）、RAM102上のテーブルに
保持しているそのRUに含まれるPRUの再生開始時間か
ら、QuickTime管理情報を用いて、そのPRUを記録すべき
光ディスク106上のアドレス、つまり元々そのPRUが記録
されていたアドレスを求める。

【０１３２】アフレコを開始したRUのPRU記録の時以外
は、求めたPRUのアドレスから１ECC分の引くことで直前
のMovie fragment atomのアドレスを求める。そのアド
レスにピックアップ107を移動させ（ステップ807）、Mo
vie fragment atomとPRUを含むECCブロックを光ディス
ク107に記録する（ステップ808）。

【０１３３】アフレコ終了が指示されていれば、現在エ
ンコード中のPRUのエンコード完了を待って（ステップ8
10）、そのPRUの直前のMovie fragment atomの記録アド
レスを求めピックアップを移動し（ステップ811）、Mov
ie fragment atomとPRUを記録する（ステップ812）。最
後にQuickTime管理情報をディスクに記録する（ステッ
プ813）。

【０１３４】尚、本実施例においては、PRU中のアフレ
コ済みデータの管理を、Movie fragment atomで行って
いるが、バックアップ管理情報ファイル2402のMovie at
om#2で行うことも考えられる。すなわち、バックアップ
管理情報ファイル2402において、アフレコオーディオト
ラックのみ通常のSample table atomで管理することに
なる。

【０１３５】この構成においても、ムービーファイル24
01のアフレコ済みデータの管理情報と同様の内容は、バ
ックアップ管理情報ファイル2402に存在するため、ムー
ビーファイル2401が破損した場合も、バックアップ管理
情報ファイル2402を参照することで、どの領域がアフレ
コ済みかを知ることが可能である。

【０１３６】また、アフレコ済みデータの管理情報は、
バックアップ管理情報ファイル2402のMovie atomにまと
まって存在するため、管理情報の更新は短時間で可能で
ある。ただしこの構成では、PRUとPRU中のアフレコ済み
データの管理情報とがディスク上で離れた位置に存在す
ることになるため、アフレコ時に管理情報を更新するこ
とは困難となり、本実施例のようにアフレコ時の電源切
断に対応することはできない。

【０１３７】しかし、本実施例に比べて、次のようなメ
リットがある。すなわち、このような構成を取ること
で、アフレコ時のMovie fragment atomの挿入間隔とPRU
の挿入間隔を独立に設定することが可能となる。例え
ば、Movie fragment atomをPRUの挿入間隔より短い間隔
で挿入することで、初回ビデオ記録時の電源切断に対す
るユーザデータ保護を強力にすることが可能となる。

【０１３８】また、フラグメンテーションを解消するた
め、ディスク上でデータの再配置を行うことを考慮した
場合、本実施例ではムービーファイル2401中のRecord U
nitとバックアップ管理情報ファイル2402のMovie fragm
ent atomとがディスク上で連続であることを保つ必要が
あるが、このような構成の場合、ムービーファイル2401
がRecord Unit単位に連続的に記録されることだけを気
にすればよく、バックアップ管理情報ファイル2402に関
しては気にする必要がない。

【０１３９】

【発明の効果】以上説明したように、本発明によれば、
アフレコ用領域とバックアップ管理情報をディスク上で
連続的に配置することにより、アフレコ時においてバッ
クアップ管理情報を更新することが容易となる。

【図面の簡単な説明】

【図１】本発明の実施形態における概略構成を示すブロ
ック図である。

【図２】QuickTimeファイルフォーマットにおける管理
情報とAVストリームとの関係を示す説明図である。

【図３】QuickTimeファイルフォーマットにおけるMovie
atomの概要を示す説明図である。

【図４】QuickTimeファイルフォーマットにおけるTrack
atomの概要を示す説明図である。

【図５】QuickTimeファイルフォーマットにおけるTrack
header atomの構成を示す説明図である。

【図６】QuickTimeファイルフォーマットにおけるMedia
atomの構成を示す説明図である。

【図７】QuickTimeファイルフォーマットにおけるMedia
information atomの構成を示す説明図である。

【図８】Sample table atomによるデータ管理の例を示
す説明図である。

【図９】QuickTimeファイルフォーマットにおけるSampl
e table atomの構成を示す説明図である。

【図１０】QuickTimeファイルフォーマットにおけるEdi
t atomの構成を示す説明図である。

【図１１】Edit atomによる再生範囲指定の例を示す説
明図である。

【図１２】QuickTimeファイルフォーマットにおけるUse
r data atomの構成を示す説明図である。

【図１３】QuickTimeファイルフォーマットにおけるFra
gmented movieの全体構成を示す説明図である。

【図１４】QuickTimeファイルフォーマットにおけるMov
ie extends atomの構成を示す説明図である。

【図１５】QuickTimeファイルフォーマットにおけるTra
ck extends atomの構成を示す説明図である。

【図１６】QuickTimeファイルフォーマットにおけるMov
ie fragment atomの構成を示す説明図である。

【図１７】QuickTimeファイルフォーマットにおけるMov
ie fragment header atomの構成を示す説明図である。

【図１８】QuickTimeファイルフォーマットにおけるTra
ck fragment atomの構成を示す説明図である。

【図１９】QuickTimeファイルフォーマットにおけるTra
ck fragment header atomの構成を示す説明図である。

【図２０】QuickTimeファイルフォーマットにおけるTra
ck fragment run atomの構成を示す説明図である。

【図２１】本発明の一実施例におけるアフレコ対応スト
リームの構成を示す説明図である。

【図２２】本発明の一実施例におけるVUの構造を示す説
明図である。

【図２３】本発明の一実施例におけるムービーファイル
とバックアップ管理情報の関係を示す説明図である。

【図２４】本発明の一実施例における連続記録制限を示
す説明図である。

【図２５】本発明の一実施例におけるバックアップ管理
情報によるアフレコ領域の管理方法を示す説明図であ
る。

【図２６】本発明の一実施例におけるバックアップ管理
情報のMovie dataの例を示す説明図である。

【図２７】本発明の一実施例におけるバックアップ管理
情報のMovie fragmentの例を示す説明図である。

【図２８】本発明の一実施例におけるリファレンス・デ
バイス・モデルを示す説明図である。

【図２９】本発明の一実施例におけるリファレンス・ア
フレコ・アルゴリズムを示す説明図である。

【図３０】本発明の一実施例における記録動作を示すフ
ローチャートである。

【図３１】本発明の一実施例におけるアフレコ動作を示
すフローチャートである。

【図３２】従来技術における管理情報とAVストリームと
の配置を示す説明図である。

【図３３】従来技術におけるアフレコ対応AVストリーム
を示す説明図である。

【符号の説明】

100 バス 101 ホストCPU 102 RAM 103 ROM 104 ユーザインタフェース 105 システムクロック 106 光ディスク 107 ピックアップ 108 ECCデコーダ 109 ECCエンコーダ 110 再生用バッファ 111 記録/アフレコ用バッファ 112 デマルチプレクサ 113 マルチプレクサ 114 多重化用バッファ 115 オーディオデコーダ 116 ビデオデコーダ 117 オーディオエンコーダ 118 ビデオエンコーダ

───────────────────────────────────────────────────── フロントページの続き (72)発明者山口孝好大阪府大阪市阿倍野区長池町22番22号シャープ株式会社内Ｆターム(参考） 5C053 FA23 FA30 GA11 GB05 GB37 5D044 AB05 AB07 BC01 BC04 CC04 DE17 DE27 DE48 DE57 EF05 EF07 5D110 AA13 AA19 BB06 DA04 DA06 DA12 DA15 DB02 DD13

Claims

【特許請求の範囲】

【請求項１】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニットと、前記第１のユニットを管
理する管理情報とを、記録媒体に記録するデータ記録方
法であって、前記第１のユニットと前記管理情報とを前記記録媒体上
で近傍に配置することを特徴とするデータ記録方法。
【請求項２】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニットと、前記第１のデータを管理
する第１の管理情報と、前記第２のデータを管理する第
２の管理情報とを、記録媒体に記録するデータ記録方法
であって、前記第２の管理情報と前記第１の管理情報とを前記記録
媒体上で分離して配置するとともに、１個以上の前記第
２の管理情報を互いに前記記録媒体上で近傍に配置する
ことを特徴とするデータ記録方法。
【請求項３】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニットと、前記第１のユニットを管
理する管理情報とが、近傍に配置されて記録された記録
媒体に対し、前記第２のデータと前記管理情報とを書き
換えるデータ変更方法であって、前記第２のデータと前記管理情報とを連続的に書き換え
ることを特徴とするデータ変更方法。
【請求項４】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニットと、前記第１のデータを管理
する第１の管理情報とが記録され、さらに、前記第２の
管理情報が１個以上互いに近傍に配置されて記録された
記録媒体に対し、前記第２のデータと前記第２の管理情
報とを書き換えるデータ変更方法であって、前記第２の管理情報を連続して書き換えることを特徴と
するデータ変更方法。
【請求項５】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニットと、前記第１のユニットを管
理する管理情報とを、記録媒体に記録するデータ記録装
置であって、前記管理情報を前記記録媒体上で前記第１のユニットの
近傍に配置して記録する手段を備えたことを特徴とする
データ記録装置。
【請求項６】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニットと、前記第１のデータを管理
する第１の管理情報と、前記第２のデータを管理する第
２の管理情報とを、記録媒体に記録するデータ記録装置
であって、前記第２の管理情報と前記第１の管理情報とを前記記録
媒体上で分離して配置するとともに、１個以上の前記第
２の管理情報を互いに前記記録媒体上で近傍に配置して
記録する手段を備えたことを特徴とするデータ記録装
置。
【請求項７】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニットと、前記第１のユニットを管
理する管理情報とが、近傍に配置されて記録された記録
媒体に対し、前記第２のデータと前記管理情報とを書き
換えるデータ変更装置であって、前記管理情報を前記第２のデータと連続的に書き換える
手段を備えたことを特徴とするデータ変更装置。
【請求項８】映像又は音声からなる第１のデータと、
前記第１のデータと同期して再生される第２のデータと
を格納する第１のユニットと、前記第１のデータを管理
する第１の管理情報とが記録され、さらに、前記第２の
管理情報が１個以上互いに近傍に配置されて記録された
記録媒体に対し、前記第２のデータと前記第２の管理情
報とを書き換えるデータ変更装置であって、前記第２の管理情報を連続して書き換える手段を備えた
ことを特徴とするデータ変更装置。