(57)【特許請求の範囲】
【請求項１】
記録再生手段を用いて、映像データまたは音声データからなる第１のデータユニットと、前記第１のデータユニットと同期して再生されるデータからなる第２のデータユニットとを光ディスクである記録媒体に記録する記録方法であって、
複数からなる前記第１のデータユニットと、該第１のデータユニットに対して後から追記された場合の前記第２のデータユニットとを編集ユニットとして管理し、
前記第１のデータユニットを再生しながら前記第２のデータユニットを記録する際、前記編集ユニットを構成する前記第１のデータユニットの全再生時間を、
記録媒体に対する前記記録再生手段のデータ入出力におけるデータ転送速度、前記記録再生手段が記録媒体にアクセスするときのシーク時間、前記記録再生手段がアクセスする際の記録媒体の回転待ち時間、前記記録再生手段における第１のデータユニットの再生ビットレート及び第２のデータユニットの記録ビットレートのうちの少なくとも１つに基づいて、前記第１のデータユニットの再生や前記第２のデータユニットの記録に途切れがない最小値を求め、該最小値以上になるように決定することを特徴とする記録方法。
【請求項２】
記録再生手段を用いて、映像データまたは音声データからなる第１のデータユニットと、前記第１のデータユニットと同期して再生されるデータからなる第２のデータユニットとを光ディスクである記録媒体に記録する記録媒体であって、
複数からなる前記第１のデータユニットと、該第１のデータユニットに対して後から追記された場合の前記第２のデータユニットとを編集ユニットとして管理し、
前記第１のデータユニットを再生しながら前記第２のデータユニットを記録する際、前記編集ユニットを構成する前記第１のデータユニットの全再生時間を、
記録媒体に対する前記記録再生手段のデータ入出力におけるデータ転送速度、前記記録再生手段が記録媒体にアクセスするときのシーク時間、前記記録再生手段がアクセスする際の記録媒体の回転待ち時間、前記記録再生手段における第１のデータユニットの再生ビットレート及び第２のデータユニットの記録ビットレートのうちの少なくとも１つに基づいて、前記第１のデータユニットの再生や前記第２のデータユニットの記録に途切れがない最小値を求め、該最小値以上になるように決定し記録することを特徴とする記録媒体。
【請求項３】
映像データまたは音声データからなる第１のデータユニットと、前記第１のデータユニットと同期して再生されるデータからなる第２のデータユニットとを入力する入力手段と、
複数からなる前記第１のデータユニットと、該第１のデータユニットに対して後から追記された場合の前記第２のデータユニットとを編集ユニットとして管理して符号化する符号化手段と、
前記編集ユニットを記録媒体に記録再生する記録再生手段とを備えた記録再生装置であって、
前記符号化手段は、
前記第１のデータユニットを再生しながら前記第２のデータユニットを記録する際、前記編集ユニットを構成する前記第１のデータユニットの全再生時間を、
記録媒体に対する前記記録再生手段のデータ入出力におけるデータ転送速度、前記記録再生手段が記録媒体にアクセスするときのシーク時間、前記記録再生手段がアクセスする際の記録媒体の回転待ち時間、前記記録再生手段における第１のデータユニットの再生ビットレート及び第２のデータユニットの記録ビットレートのうちの少なくとも１つに基づいて、前記第１のデータユニットの再生や前記第２のデータユニットの記録に途切れがない最小値を求め、該最小値以上になるように決定することを特徴とする記録再生装置。
【発明の詳細な説明】
【０００１】
【発明の属する技術分野】
本発明は、映像データ、音声データをハードディスク、光ディスク等のランダムアクセス可能な記録媒体に対して記録・再生する処理に関する。
【０００２】
【従来の技術】
ディスクメディアを用いたビデオや音声のディジタル記録再生装置が普及しつつある。それらにおいて、テープメディアと同様アフターレコーディング（アフレコ）機能を安価に実現する技術が求められている。アフレコ機能は、既に記録したオーディオやビデオに対し、後から情報、特にオーディオを追記する機能である。
【０００３】
ディスクメディアでアフレコ機能を実現している従来技術として、特開平5-234084号公報がある。この技術は、プログラム提示期間よりデータの読込期間が短いことを利用して、現在提示しているディスクからメモリにデータを読み込んでから次のデータを読み込むまでの間に、入力されたアフレコ音声データをディスクに書き込むというもので、ディスク記録再生手段が１つであってもアフレコを実現することが可能である。
【０００４】
ここでプログラム提示期間とは、ビデオや音楽などプログラムそれぞれが持つ固有の再生期間のことである。例えば１分間のビデオは、再生手段が変わったとしても１分間で再生されなければ正確に再生されたとは言えない。
【０００５】
従来技術におけるディスクの記録フォーマットを図２２に示す。ディスクはECC（エラー・コレクション・コーディング）ブロックの列で構成される。ECCブロックは符号化を行う際の最小単位であり、データに加えエラー補正用のパリティが付加され、符号化がおこなわれている。データを読み込む際は、この単位で読み込み誤り訂正をしてから、必要なデータを取り出す。一方、データを書き換える際は、まずECCブロック単位で読み込み、誤り訂正をしたデータに対し、必要な部分を書き換え、再度誤り符号の付与を行ない、ディスクに記録を行なう。このことは、1バイト書き換える場合でも、そのバイトが含まれるECCブロック全体を読み込み書き込む必要があることを意味する。
【０００６】
ビデオやオーディオはECCブロック中で、図２２ (b)のように、アフレコオーディオブロック、オリジナルオーディオブロック、オリジナルビデオブロックの順に配置される。それぞれのブロックにはほぼ同じ時間に対応するアフレコオーディオ、オリジナルオーディオ、オリジナルビデオが含まれている。なお、オリジナルオーディオブロックとオリジナルビデオブロックを合わせてオリジナルブロックと呼ぶことにする。オリジナルプログラム（アフレコオーディオを記録する前の映像）を記録する際は、アフレコオーディオブロックにダミーのデータを書き込んでおく。
【０００７】
次に、従来技術におけるアフレコ時の動作について図２３に沿って説明する。図中、上段のグラフは各手段と、その各手段と記録媒体上の関係を示している。中段は、ディスク中でのヘッドの位置を、下段のグラフはバッファメモリ108に占めるプログラムデータの割合を模式的に示したものである。
【０００８】
ここではプログラムが、ディスク中のs11〜s18〜の連続的な領域に配置され、s11〜s13、s13〜s15、s15〜s17がそれぞれＥＣＣブロックに対応し、s11〜s12、s13〜s14、s15〜s16、s17〜s18がそれぞれアフレコオーディオブロックに対応しているとする。
【０００９】
時刻ｔ１の時点ですでにｓ13までの領域がバッファメモリ108に格納されており、ｓ11〜ｓ13に記録されていたデータがデコードされ提示（再生）されるとともに、そのデータのアフレコ音声の入力、エンコードが行われている。
【００１０】
時刻t1〜t3において、領域ｓ13〜ｓ15のデータをディスクから読み込み、バッファメモリ108及びアフレコバッファへの格納を行う。アフレコバッファは読み込んだECCブロックをそのまま記憶し、図２２ (b)と同様の構成をとる。
【００１１】
時刻t2は、時刻t1の時点で行われていたs11〜s13に記録されていたデータのデコード、再生が終了する時刻である。時刻t2以降は、時刻t1〜t3で読み込まれるs13〜s15のデータをデコード、再生するとともに、そのデータのアフレコ音声の入力、エンコードが行われる。このs13〜s15のデータのデコード、再生はt5まで行われる。
【００１２】
t2までに入力されたアフレコ音声は、少なくともt3までにエンコードが終了する。時刻t3において、t2までに入力されたアフレコ音声をディスク媒体に記録する。このときに、s11にアクセスする際に、ディスクの回転待ちの時間を要するが、ディスクの読み書きの時間に比べると、短時間であるので、ここでは考慮しない。
【００１３】
アフレコ音声のディスクへの書き込みは、時刻t3〜t4で行われる。このディスクへの書き込みがt4で終了すると、t4からs15〜s17のデータをディスクから読み込む。このように以下同様の処理を繰り返す。
【００１４】
この従来技術では、情報圧縮を行うことにより、データの再生時間よりも読み込み時間が短くなることを利用し、記録再生手段を、記録と再生で時分割して利用することで、１つの記録再生手段だけでアフレコを実現している。
【００１５】
【発明が解決しようとする課題】
上記したように、ECCブロック毎に誤り訂正符号化が行われるため、ECCブロック中の１バイトを書き換える場合であっても、そのバイトが含まれるECCブロック全体を読み込み書き込む必要がある。上記した従来技術のようにアフレコオーディオデータがECCブロックに分散して配置されていた場合、アフレコオーディオデータを記録するためには、ほとんどのECCブロック、つまりはデータの全てを書き換える必要がある。このように、多くのECCブロックを書き換えてアフレコを行う場合には、読み書き速度の高いディスクドライブを使用するか、読み書きするデータ量を削減することになる。
【００１６】
読み書き速度の高いディスクドライブは低いものに比べて高価なものになる。また、ディスクの回転数を高くする必要があるため、消費電力も高くなる。一方、もし速度の低いディスクドライブでアフレコを実現しようとすると、画質を落としてデータ量を削減することになる。
【００１７】
本発明は、かかる従来技術の問題点に鑑みてなされたものであり、ECCブロック単位でしか記録再生できない場合に、データ転送速度の比較的低いディスクドライブでも、オリジナルビデオとの時間的ずれがなくしかも画質を落とさずにアフレコを実現することを目的とする。
【００１８】
【課題を解決するための手段】
本発明は、記録再生手段を用いて、映像データまたは音声データからなる第１のデータユニットと、前記第１のデータユニットと同期して再生されるデータからなる第２のデータユニットとを光ディスクである記録媒体に記録する記録再生方法であって、
複数からなる前記第１のデータユニットと、該第１のデータユニットに対して後から追記された場合の前記第２のデータユニットとを編集ユニットとして管理し、
前記第１のデータユニットを再生しながら前記第２のデータユニットを記録する際、前記編集ユニットを構成する前記第１のデータユニットの全再生時間を、
記録媒体に対する前記記録再生手段のデータ入出力におけるデータ転送速度、前記記録再生手段が記録媒体にアクセスするときのシーク時間、前記記録再生手段がアクセスする際の記録媒体の回転待ち時間、前記記録再生手段における第１のデータユニットの再生ビットレート及び第２のデータユニットの記録ビットレートのうちの少なくとも１つに基づいて、前記第１のデータユニットの再生や前記第２のデータユニットの記録に途切れがない最小値を求め、該最小値以上になるように決定するものである。
【００１９】
また、本発明は、記録再生手段を用いて、映像データまたは音声データからなる第１のデータユニットと、前記第１のデータユニットと同期して再生されるデータからなる第２のデータユニットとを光ディスクである記録媒体に記録する記録媒体であって、
複数からなる前記第１のデータユニットと、該第１のデータユニットに対して後から追記された場合の前記第２のデータユニットとを編集ユニットとして管理し、
前記第１のデータユニットを再生しながら前記第２のデータユニットを記録する際、前記編集ユニットを構成する前記第１のデータユニットの全再生時間を、
記録媒体に対する前記記録再生手段のデータ入出力におけるデータ転送速度、前記記録再生手段が記録媒体にアクセスするときのシーク時間、前記記録再生手段がアクセスする際の記録媒体の回転待ち時間、前記記録再生手段における第１のデータユニットの再生ビットレート及び第２のデータユニットの記録ビットレートのうちの少なくとも１つに基づいて、前記第１のデータユニットの再生や前記第２のデータユニットの記録に途切れがない最小値を求め、該最小値以上になるように決定し記録するものである。
【００２０】
さらに、本発明は、映像データまたは音声データからなる第１のデータユニットと、前記第１のデータユニットと同期して再生されるデータからなる第２のデータユニットとを入力する入力手段と、
複数からなる前記第１のデータユニットと、該第１のデータユニットに対して後から追記された場合の前記第２のデータユニットとを編集ユニットとして管理して符号化する符号化手段と、
前記編集ユニットを記録媒体に記録再生する記録再生手段とを備えた記録再生装置であって、
前記符号化手段は、
前記第１のデータユニットを再生しながら前記第２のデータユニットを記録する際、前記編集ユニットを構成する前記第１のデータユニットの全再生時間を、
記録媒体に対する前記記録再生手段のデータ入出力におけるデータ転送速度、前記記録再生手段が記録媒体にアクセスするときのシーク時間、前記記録再生手段がアクセスする際の記録媒体の回転待ち時間、前記記録再生手段における第１のデータユニットの再生ビットレート及び第２のデータユニットの記録ビットレートのうちの少なくとも１つに基づいて、前記第１のデータユニットの再生や前記第２のデータユニットの記録に途切れがない最小値を求め、該最小値以上になるように決定するものである。
【００２２】
本発明は、映像または音声からなる第１のデータ（オリジナルデータ）と、前記第１のデータと同期して再生される第２のデータ（アフレコデータ）とを、記録媒体に記録する記録方法であって、所定の再生時間分の前記第１のデータと、該第1のデータに同期して再生される前記第２のデータを第１のユニット（ＥＵ(Editable Unit)）として管理し、複数の前記第１のユニットから構成されるデータストリームにおいて、前記第１のユニットの再生時間を同一とし、前記第１のユニットの再生時間を、記録媒体への入出力時におけるデータ転送時間、シーク時間、回転待ち時間、第１のデータ或いは第２のデータのビットレートのうちの１に基づいて決定するものである。
【００２５】
【発明の実施の形態】
本発明の第1の実施形態を説明する。図 1は、第1の実施形態におけるアフレコ可能なビデオディスクレコーダの構成である。図に示すように、この装置は、操作部101、CPU102、RAM103、ROM104，システムクロック105、バッファメモリ108、エンコーダ106、マルチプレクサ107、ディスクドライブ109、バス110、デマルチプレクサ111、デコーダ112、ディスク113 、ECCエンコーダ/デコーダ114から構成される。
【００２６】
ディスク113は、外周から内周に向かって螺旋状に記録再生の行われる脱着可能な光ディスクとする。2048byteを1セクタとし、誤り訂正のため16セクタでECCブロックを構成する。ECCブロック中のデータを書き換える場合、そのデータが含まれるECCブロック全体を読み込み、誤り訂正を行い、対象のデータを書き換え、再び誤り訂正符号を付加し、ECCブロックを構成し記録媒体に記録する必要がある。
【００２７】
ディスク113の構成を図 2に示す。ディスク中の先頭にはファイルシステム管理情報があり、その残りがファイルシステムによってファイル単位に管理されるユーザ領域となっている。ユーザ領域は管理情報領域とAVストリーム領域に分けられる。管理情報領域には管理情報に関するファイルが含まれ、AVストリーム領域には、EUS(エディタブル・ユニット・シーケンス)ファイルがある。EUSファイルは、ビデオの記録を開始してから終了するまでの一連のビデオ・オーディオデータを記録したデータストリーム単位のファイルである。一方、管理情報領域のファイルには、EUSファイルに関する情報を格納したEUS Managementファイルなどが含まれる。
【００２８】
本実施形態では、ファイルシステム管理情報によって管理されるファイルシステムを通して各ファイルのアクセスを行なう。そのため、図中のEUSファイル＃2のようにディスク中で分散して配置されたファイルを、連続した論理アドレスでアクセスすることが可能である。論理アドレスでのアクセスの際の単位はセクタ単位である。なお、本実施例では、発明に直接関係しないためファイルシステムに関する説明は省略する。また、以下の説明におけるアドレスは特に断りが無い限り論理アドレスのことを指すこととする。
【００２９】
本実施例で用いる符号化方法に関して説明する。オリジナルビデオは、MPEG-2符号化により5Mbps前後の可変レートで符号化し、オーディオはオリジナル、アフレコともに、48kHzでサンプリングし、MPEG-1/LayerII符号化により2チャンネル256kbpsの固定レートで符号化する。
【００３０】
EUSファイルは、ビデオおよびオーディオ情報の多重化データストリームの単位であるEUSを格納するファイルである。EUSのおおまかな構成を図 3に示す。EUSを構成する主な要素について、以下にまとめる。
【００３１】
Block:セクタに対応した2048byteの固定長の単位であり、ISO/IEC 13818-2に規定されるビデオデータおよびISO/IEC 13818-3に規定されるオーディオデータおよび他のデータを、ISO/IEC 13818-1で規定されるPES  Packetにパケット化したもので構成される
VU (Video Unit):再生時におけるランダムアクセスの単位であり、VUの先頭からアクセスすればEUSの途中であってもオーディオ、ビデオが正しくデコードされることが保証される。Blockで構成される
PRU (Post Recording Unit):複数のVUに関連するポストレコーディングデータ（アフレコデータ）を記録するための領域である。Blockで構成される
EU (Editable Unit):複数のVUとそれに対応する0個または1個のPRUで構成される。1つのEUはディスク中で連続的に記録する
EUS (Editable Unit Sequence): Rec Start〜StopあるいはPauseの区間に相当する単位であり、整数個のEUで構成される。
【００３２】
図中のblockは、2048byteの固定長の単位であり、1blockは1セクタに格納される。1個のblockは原則として1個のパケットで構成される。ここでのパケットは、ISO/IEC 13818-1で規定されるPES packetに準拠する。パケットの構成を図 4に示す。パケットは、そのパケットに関する属性等を格納するパケットヘッダとビデオデータ等の実際のデータを格納するパケットデータで構成される。パケットヘッダに含まれる主な情報は以下の通りである。packet-start-code-prefixはISO/IEC 13818-1で規定されたパケットの開始コードである。stream-idはこのパケットの種類を表わす。PES-packet-lengthはこのフィールド以降のデータのサイズを表わす。PES-header-data-lengthはパケットヘッダのサイズを表わす。PTS(プレゼンテーション・タイム・スタンプ)は、多重化したオーディオやビデオといったエレメンタリ・ストリーム間の同期情報であり、パケット中に先頭が含まれるアクセスユニット(ビデオの場合1フレーム)が再生されるタイミングを90kHzのクロックでカウントした値を33ビットで表わしたものである。DTS(デコーディング・タイム・スタンプ)は、そのパケット中に先頭があるアクセスユニットがデコードされるタイミングをPTSと同じ時間軸で表わしたものである。stuffing-bytesは、次に説明するようにパケットのサイズを調整するために用いられる。
【００３３】
もし、パケットが2048byteに満たず、不足分が7byte未満のときはパケットヘッダにスタッフィング・バイトを入れる。一方不足分が8byte以上のときは不足分に相当するパディングパケットをそのパケットの後に置く。このスタッフィング・バイト、パディングパケットは実際に処理を行わないいわゆるダミーデータである。本実施例で用いるパケットを以下にまとめる。
【００３４】
V-PKT (Video Packet): ISO/IEC 13818-2で規定されるビデオデータを格納したパケット
A-PKT (Audio Packet): ISO/IEC 13818-3で規定されるオーディオデータを格納したパケット
P-PKT (Padding Packet): ISO/IEC 13818-1で規定されるパディング用パケット
VH-PKT (VU Header Packet): VUに関するヘッダを格納したパケット
PH-PKT (PRU Header Packet): PRUに関するヘッダを格納したパケット
V-PKT、A-PKTおよびP-PKTのフォーマットはISO/IEC 13818-1の規定に準拠する。その他のパケットのフォーマットについては後述する。また、EUSを構成するblockを以下にまとめる。
【００３５】
V-BLK (Video Block): V-PKTを格納したblock
A-BLK (Audio Block): A-PKTを格納したblock
P-BLK (Padding Block): P-PKTを格納したblock
VH-BLK (VU Header Block): VH-PKTを格納したblock
PH-BLK (PRU Header Block): PH-PKTを格納したblock
まず、EUについて説明する。EUの構造を図 5に示す。EUは1個以上の整数個のVUと0個または1個のPRUを含む。1個のEUSを構成するVUの提示時間は同一にする。つまり、１つのEUSにおけるVUの再生間隔は常に同一となっている。ただし、EUSの最後のVUは他のVUより短くてもよい。
【００３６】
なお、VUの提示時間は、そのVUがビデオデータを含む場合は、そのVUに含まれるビデオフィールド数あるいはビデオフレーム数にそれぞれビデオフィールド周期あるいはビデオフレーム周期をかけたものとして定義する。
【００３７】
1個のEUSを構成するEUは、すべてPRUを含むか、すべてPRUを含まないかのいずれかにする。EUを構成するVUの個数Nvuは、EUSの最後のEUを除きEUS内では一定にする。つまり、１つのEUSにおいて、EUの提示時間間隔は常に一定となる。PRUを持たないEUSの場合、VU を多数設ける必要がないので、Nvu=1とする。一方、PRUを持つEUSの場合、VUあたりの提示時間をTpv、回転待ち時間をTv、現在読込中のトラックからアフレコ領域のあるトラックへジャンプする時間をTk、ディスクからのデータ転送速度をRs、EUS全体のビットレートをRo、アフレコ音声のチャンネルあたりのビットレートをRa、アフレコ音声のチャンネル数をNchとしたとき、
【００３８】
【数１】
0004169569.tif 000002
【００３９】
とする。なお、ceiling(x)はx以上の最小の整数を、floor(x)はx以下の最大の整数を求める関数である。PRUを持つEUSの場合にデータ転送速度などに基づきNvuの最小値を設定する理由は、EUあたりの時間が十分に大きくないと、図 23のように逐次的にアフレコを行なう際、ヘッドを現在の読込位置からアフレコ領域へ移動させるオーバーヘッドの占める割合が大きくなり、データの読込が表示に追いつかなくなりビデオやオーディオの再生が途切れてしまうからである。
【００４０】
次にVUについて説明を行なう。VUは、sequence-headerおよびそれに続くGOP-headerを直前に置いた1個以上の整数個のGOP(グループ・オブ・ピクチャ)からなるビデオデータと、それと同期する整数個のAAU(オーディオ・アクセス・ユニット)からなるオーディオデータを含む。GOPは、MPEGビデオ圧縮の単位で、複数のフィールド群あるいはフレーム群で構成される。AAUは、オーディオサンプルを0.024秒毎にセグメント化しそれぞれのセグメントを圧縮したものである。GOP、AAUともにそれぞれの単位の先頭からデコードする必要があるが、VUはそれぞれを整数個含んでいるためVU単位で独立再生可能である。1VUあたりのビデオフィールド数はNTSCの場合、24フィールドから60フィールド、PALの場合は20フィールドから50フィールドの範囲にする。
【００４１】
VUは図 6のように、先頭にVU Header Block(VH-BLK)、次に前述のオーディオデータを格納したA-BLKの列を置き、最後に前述のビデオデータを格納したV-BLKの列の順に配置する。A-BLKの個数は、前述のオーディオデータを格納するのに必要十分なものにする。最後のA-BLKに余りが出た場合には前述のようにP-PKTあるいはスタッフィングバイトで調整する。V-BLKも同様の構成とする。
【００４２】
上記のように独立再生が可能な単位であるVUの集合でEUを構成することによって、EUの途中から再生を開始する場合のオーバーヘッドが小さくなる。転送速度がデータのビットレートに比べ余裕が無い場合、Nvuを大きく、すなわちEUあたりの提示時間を長く設定する必要があるが、その場合にVUのような単位を設けなければ、例えばEUの終端付近から再生を始める場合でも、EUの先頭から読み込まなければならず、ユーザに対するレスポンスの低下を招くことになる。また、VUを整数個のblock、すなわちセクタで構成することで、VUの先頭へのアクセスが簡略化される。
【００４３】
VH-PKTの構造を図 7に示す。図中のBP(バイト・ポジション)は先頭からの相対的なバイト位置であり、バイト数はそれぞれのフィールドのバイト数を示す。packet-start-code-prefix、stream-id、PES-packet-lengthは前述の通りである。VU Propertyは1byteのビットフィールドで、このVU headerが含まれるVUに関する情報を格納する。その中の1つであるFirst VU of EUはそのVH-PKTを含むVUがEU中の先頭のVUであれば1それ以外は0に設定される。このフィールドは、後述するように、アフレコ時に同期を取るのに用いる。Length of VUはこのVU headerが含まれるVU中のblock数を表わす。Start RLBN of Video Dataは、VUの先頭からビデオデータが始まるまでのblock数を表わす。
【００４４】
次にPRUについて説明を行なう。PRUは、1以上整数個のVUに対するオーディオを格納するための領域であり、1個のEUに0個あるいは1個存在する。PRUのサイズは、EUあたりの提示時間に対応するオーディオデータとPRUヘッダ・ブロックを含むことのできる最小の整数個のECCブロックである。PRUを構成するECCブロックの数NPRU,ECCは
【００４５】
【数２】
0004169569.tif 000003
【００４６】
として規定される。なお、PRU中に記録するオーディオデータは、そのPRUが含まれるEU中のVUのオーディオと同じデータレート、同じサンプリング周波数で記録する。
【００４７】
オリジナルデータ記録直後のPRUの構成を図 8に示す。先頭にPRU Header Block (PH-BLK)を1個記録し、残りの領域をPadding Block (P-BLK)で埋めておく。つまり、オリジナルデータ記録直後の時点では、オーディオデータは記録されていない。
【００４８】
PRUにオーディオをアフレコした後のPRUの構成を図 9に示す。先頭にPRU Header Block (PH-BLK)を1個記録し、その後にはそのEUに同期したオーディオデータをA-BLKの列として記録し、残りの領域をP-BLKで埋めておく。このとき、PRU中のA-BLKは、同じEU中のそれぞれのVUに含まれるA-BLK数の合計と同じ数にする。さらに、PRU中のそれぞれのA-BLKの持つPTSの値が同EU中のそれぞれのVUに含まれるA-BLKのPTSと同じ順番でかつ、同じ値を取るように、ポストレコーディングのオーディオデータを記録する。すなわち、アフレコ後PRU中には、各VUに含まれるA-BLKの列に対応するA-BLKの列が存在することになる。このような、VUに対応したPRU中のA-BLKの列をSAU(サブ・オーディオ・ユニット)と呼ぶことにする。なお、言うまでもないが、SAUには、VUと同様整数個のAAUが含まれることになる。
【００４９】
PH-PKTの構造を図 10に示す。packet-start-code-prefix、stream-id、PES-packet-lengthについてはVUヘッダ・パケットと同様である。Length of PRUは、このPH-PKTの含まれるPRUを構成するblock数を記述する。Number of VUはこのPH-BLKの含まれるEUを構成するVUの数を表わす。Start RLBN of Data for VUは、各SAUのPRUの先頭からのblock数を表わす。
【００５０】
上記のように、PRUを整数個のBlockすなわちセクタで構成される整数個のAAUを含む単位(SAU)の集合とすることで、PRUをバッファメモリ108に読み込んだ後、その中のアフレコデータをSAU単位で部分的に書き換えることが容易になる。なぜなら、各SAUに含まれるAAUは他のSAU中のAAUとは独立したパケットに格納されているため、SAU単位で書き換えるのであれば、その他のSAUには影響を与えることはないからである。もし、このような構成を取らなければ、1つのパケットに異なるSAUに含まれるAAUが存在することになり、すでにアフレコ済みのPRUに対してその途中からアフレコを行なう際に、パケットを解いてAAUの先頭を探し、データを書き換え再度パケット化するという手順を踏まねばならず、処理が複雑化する。
【００５１】
さらに、それぞれのSAUの先頭位置を示す情報をストリーム中に挿入しているため、PRUをSAU単位で書き換えする場合に、どの位置から書き換えを開始したらよいかが即座にわかる。
【００５２】
また、PRU中のデータをVU中のオーディオデータと同様の構造にしておくことで、例えば、PRU中のオーディオデータをVU中に部分的にコピーする等、PRUとVUの間でのデータのやり取りが容易になる。
【００５３】
EU中でのPRUの配置について説明する。PRUは、それが含まれるEUの先頭の15セクタ以内のECC境界、つまりEU中の最初に現れるECC境界に置く。例えば、あるEUの先頭がECCブロック境界だった場合、図 11 (a)のように、そのEUの先頭の直後にPRUを配置する。また、EUの先頭がECCブロック境界でなかった場合は、(b)のように、EUの境界の直後から15論理ブロック以内のECCブロック境界、つまりEU中の最初に現れるECCブロック境界に配置する。この場合、EU中の先頭のVUはPRUによって分断されることになる。
【００５４】
上記のように、PRUのサイズをECCブロックサイズの整数倍にし、なおかつPRUをECCブロック境界に配置することで、アフレコの際は、記録媒体上で書き換えるデータはPRUだけになり、書き換えを行なう領域が最小限で済むという利点がある。
【００５５】
上記実施例において、PRUがEUの先頭付近にある理由は、あるEUを再生する場合に、PRU全体と1つのVUを読み込んだ時点でVUとPRUの同期再生が可能になるためである。もし、PRUがEUの終端付近にあった場合、そのEUのほとんどのデータを読み終わるまでプログラムの再生ができず、しかもほぼEU全体を記憶するためのバッファメモリが必要となる。
【００５６】
EUS Managementファイルの構造を図 12に示す。EUS Managementファイルは、ディスク中に記録されたすべてのEUSファイルを管理するための情報を格納したものである。以下、本実施形態の説明に必須な項目のみについて説明を行なう。フィールドNumber of EUSIは、このファイルで管理するEUSファイルの個数を表わす。フィールドEUSI(EUS Information)は各EUSファイルに関する情報であり、Number of EUSI個分存在する。EUSIはさらに図 13のように構成される。図中のStart PTおよびEnd PTは、このEUSIが管理するEUSファイル中のの開始PTSおよび終了PTSの最上位ビットを省略したものである。なお、以後このようにPTSの最上位ビットを省略した形式をPTフォーマットと呼ぶことにする。Post Recording Unit SizeはこのEUSIが管理するEUSファイル中のPRUのサイズを表わす。
【００５７】
Address LUT(ルックアップ・テーブル)は、PTフォーマットで記述されたタイムコードからそのタイムコードに対応するデータが記録されているアドレスを検索するためのテーブルである。Address LUTの構成を図 14に示す。フィールドPB Time of EUは、EUあたりの提示時間を1/90000[秒]単位で表わしたものであり、PTフォーマットと同じスケールとなっている。PB Time of VUも、同様にVUあたりの提示時間を1/90000[秒]単位で表わしたものである。Number of PRU InformationはAddress LUT中のPRU Informationの数であると同時に、EUS中のPRUの個数も表わす。Number of VU Informationも同様にAddress LUT中のVU Informationの数およびEUS中のVU数を表わしている。
【００５８】
図 15は、PRU Informationの内容を表わす。図中のRLBN of PRUはそのPRU Informationが管理するPRUのアドレスを表わす。図 16は、VU Informationの内容を表わす。図中のRLBN of VUはそのVU Informationが管理するVUのアドレスを表わす。
【００５９】
Address LUTを用いて、あるタイムコードPTに対応するPRUのアドレスを求める手順を以下に示す。まず、PTからEUSI中のStartPTを引くことで相対PTを求め、次に相対PTをPB Time of EUで割り、小数部を切り捨てることで、そのPTに対応するPRUを管理するPRU Informationのインデックスが求まる。次に、そのインデックスに対応するPRU Information中のRLBN of PRUで与えられるアドレスが、目的とするPTに対応するPRUのアドレスである。時刻PTに対応するVUのアドレスも同様に、PTからStart PTを引いたものをPB Time of VUで割り、小数部を切り捨てた値に対応するインデックスのVU Information中のRLBN of VUを参照することで得られる。このように単純な処理でVUやPRUの先頭アドレスが得られるのは、EUおよびVUあたりの提示時間を一定にしているためである。
【００６０】
上記ディスクフォーマットで記録、再生およびアフレコを行なう際の手順を以下に示す。なお、以下の説明ではビデオはNTSCで記録し、VUを30フィールドからなる1個のGOPで構成し、ビデオ最大ビットレートを8[Mbps]とする。ディスク転送レートRsは12[Mbps]、アフレコ領域への最大ジャンプ時間Tkを0.3[秒]、最大回転待ち時間Tvを0.2[秒]とする。また、オーディオビットレートおよびオーディオチャンネル数をそれぞれ0.125[Mbps/チャンネル]、2[チャンネル]とし、オリジナルおよびアフレコで共通に用いることにする。このとき、VUあたりの提示時間Tpvは約0.5秒となる。また、アフレコが可能なEUあたりのVU数Nvuの範囲は、7≦Nvu≦20となる。本実施形態では、Nvu=8、すなわちEUあたりの提示時間は約4秒となる。
【００６１】
オリジナルプログラム記録時のCPU102の処理の流れを図 17に沿って説明する。すでに、ディスクからEUS Managementファイルやファイルシステム管理情報がRAM103に読み込まれているものとする。CPU102はエンコーダ106を起動し（ステップ1）、次にファイルシステム管理情報を基に1EU分のデータを記録するのに十分な連続領域がディスク上にあるかどうか調べる(ステップ2)。もし、なければ録画を停止する（ステップ12）。
【００６２】
もし十分な領域があれば、記録対象のVUがEU中の何番目のVUかを表わす変数iを0にリセットし、空き領域先頭アドレスを変数addrに記憶させる(ステップ3)。次に、マルチプレクサ107から1VU分のデータがバッファメモリ108にバッファリングされたことの通知を待つ(ステップ4)。マルチプレクサ107から通知が来たら、変数iが0のときは（ステップ5）、変数addrがECCブロック境界かどうかを判断し(ステップ9)、もし、ECCブロック境界でなければ、次のECCブロック境界までバッファメモリ108中のVUデータをディスクに記録する(ステップ10)。
【００６３】
次に、PH-PKTおよびP-PKTでPRUをRAM103中に構成し、それをディスクに記録する(ステップ11)。次に、バッファメモリ108中の先頭のVUデータをディスクに記録する(ステップ6)。記録が終わったら変数iをインクリメントする(ステップ7)。変数iがEU中のVU数を表わす変数Nvuより小さければステップ4にジャンプし(ステップ8)、等しくなればステップ2にジャンプする。以上の処理を、操作部101から停止指令がきたり、ディスク中に十分な連続領域が無くなるまで、EU単位に行なっていく。
【００６４】
以上のCPU102の処理と並行して、マルチプレクサ107は、オーディオ、ビデオそれぞれのエンコーダ106から送られるデータにPTS等を付与しパケット化しバッファメモリ108に貯えていく。1GOP分のV-PKTとそれに同期するA-PKTがバッファメモリ108に貯えられたらCPU102にVU分のデータをバッファリングしたことを通知する。
【００６５】
以上の手順で記録を行なったオリジナルプログラムの再生時にユーザからアフレコ開始の指示が与えられた場合の処理の流れを説明する。すでに、ディスクからEUS Managementファイルおよびファイルシステム管理情報がRAM103に読み込まれているものとする。CPU102はデコーダ112を起動し、ファイルシステム管理情報を基に、指定されたEUSファイルを先頭から読み込むようにディスクドライブ109に指令を出す。ディスクドライブ109はECCデコーダ112を経由してデマルチプレクサ111に読み込んだデータを送り、デマルチプレクサ111は、バッファメモリ108にデータを蓄積していく。デコーダ112は、ビデオやオーディオの再生に必要なデータをデマルチプレクサ111に要求し、デマルチプレクサ111はその要求に応じてバッファメモリ108に蓄積したデータを、パケットヘッダ中のstream-idに基づき適切なデコーダ112に送る。デコーダ112はデマルチプレクサ111から十分なデータを受け取りビデオやオーディオを出力可能になった時点でそのデータに対応するPTSでシステムクロック105を初期化し、以後は、システムクロック105の値を基準にして出力の同期を取る。
【００６６】
デマルチプレクサ111は、ユーザからアフレコが指示されたときのために現在再生中のデータに対応するPRUと、その次に再生するEUに対応するPRUの合計2個のPRUを常にバッファメモリ108内に保持する。さらに、それらのPRUを管理するためのテーブル(PRU管理テーブル)をRAM103中に作成する。
【００６７】
PRU管理テーブルの構成を図 18に示す。PRU管理テーブルは2個のテーブル、SAU開始PTS(SAU-PTS[j][i])とSAU開始アドレス(RLBN[j][i])とで構成される。SAU-PTS[j][i]は2次元の配列であり、1番目のインデックスがバッファメモリ108中のPRUの番号、2番目のインデックスがPRU中のSAUの番号を表わしており、その2つのインデックスでSAUの先頭のPTSを得ることができる。RLBN[j][i]も同様の構造を持ち、PRUの番号とPRU中のSAUの番号をインデックスとし、そのPRUの先頭を基準としたSAUの相対アドレスを得ることが可能である。この2つのテーブルを用いることで、あるPTSに対応するデータをバッファメモリ108中のどのSAUに記録すればよいかがわかる。
【００６８】
以上の再生処理を行なっている最中に、ユーザから操作部101を通じてアフレコを行なう指示が与えられた場合の処理を説明する。まず、CPU102がオーディオのエンコーダ106を起動する。デマルチプレクサ111は、システムクロック105からアフレコが開始された時点のタイムスタンプ(アフレコ開始PTS)を得、前述のSAU-PTS[j][i]の中から、アフレコ開始PTSを超えない最大のPTSを持つインデックスを検索する。検索の結果得られたPRU番号n、SAU番号mをデマルチプレクサ111はアフレコ開始PTSとともにマルチプレクサ107に通知する。マルチプレクサ107は、エンコーダ106から送られるAAUをバッファメモリ108中のn番目のPRUのRLBN[n][m]の位置から記憶していく。記録を開始するSAUの先頭PTSとアフレコ開始PTSの差に応じて、パケット化の前にマルチプレクサ107はオーディオエンコーダ106から送られるAAUの前に、無音のAAUを差に相当する分挿入してタイミングを調整する。
【００６９】
ユーザからアフレコが指示された時点のシステムクロック105の値、すなわちアフレコ開始PTSが228228だった場合を例に取って説明する。まず、SAU-PTS[i][j]中でアフレコ開始PTSを超えない最大のSAU開始PTSを持つSAU番号、PRU番号の組を検索する。図 18の場合、PRU番号=0、SAU番号=5となる。次にその番号に対応するRLBN[0][5]の値を見る。その結果、SAU＃5のアドレス41が得られる。したがって、バッファメモリ108中のPRU＃0の先頭から第41 block目に存在するSAU＃5からアフレコデータを記録していくことになる。
【００７０】
アフレコデータを格納中のPRUのインデックスをnとしたとき、そのPRUの最後までデータを格納した時点で、i=0から7までのRLBN[n][i]の値を現在のPRU中のPH-PKTのフィールドStart RLBN of Data for VUに順に格納し、PRUの最後までデータが格納されたことをCPU102に通知する。その際、SAU-PTS[n][0]、すなわちそのPRUを含むEUの先頭PTSも知らせる。一方、CPU102は、前記のオリジナルプログラムの再生を行ないながら、マルチプレクサ107からの通知があったら、その際に得られるEUの先頭PTSを基に、Address LUTを参照して、そのアフレコオーディオデータを記録すべきディスク113上のPRUのアドレスを求め、ディスクドライブ109に、バッファメモリ108中のn番目のPRUを前記アドレスに記録するように指令を出す。以降は、バッファメモリ中のPRUに入力されるアフレコデータを交互に格納していくことになる。
【００７１】
PRU管理テーブルの作成手順を図 19に示す。基本的な考え方は、各VUに含まれるA-BLKの個数をVH-PKT中のStart RLBN of Videoから求め、その個数がSAUに含まれるA-BLKの個数と同じことを利用して、SAU先頭アドレステーブルを構築し、同時にVU中の最初のA-PKTのPTSを抜き出しSAU先頭PTSテーブルを構築することにある。まず、VH-PKTの直後であることを表わすフラグであるVH-flgをリセットし、バッファメモリ108中のPRU番号を指すインデックスであるjを1にセットする(ステップ1)。デマルチプレクサ111に到着したパケットがVH-PKTの場合(ステップ2)、ステップ3にジャンプし、そうでないならステップ7にジャンプする。
【００７２】
パケットがVH-PKTの場合、VH-PKT中のFirst VU of EUフィールドが1かどうか検査し(ステップ3)、1なら、それ以降のデータを格納する領域を現在のPRUからもう一方のPRUを変更するために、jをインクリメントする。同時に、RLBN[j][0]に1をセットする。さらに、一時変数tmpに現在のVH-PKT中のStart RLBN of Videoフィールドの値をセットし、iに0をセットする(ステップ4)。もし、FirstVU of EUフィールドが0なら、RLBN[j][i]に一時変数tmpをセットし、さらにtmpに現在のVH-PKT中のStart RLBN of Videoフィールドの値から1引いたものを加える(ステップ6)。ここで1を引くのは、VU中のA-BLKの個数にVH-BLKの個数1を加えた値であるStart RLBN of Videoから、ここで必要となるVU中のA-BLKの個数を求めるために、VH-BLKの分を差し引くことを意味する。First VU of EUフィールドがいずれの場合も次に、VH-flgに1をセットし、iをインクリメントする(ステップ5)。
【００７３】
ステップ7では、デマルチプレクサ111に到着したパケットがA-PKTかどうか検査し、A-PKTならステップ8へジャンプし、A-PKTでないならステップ2にジャンプする。ステップ8では、変数VH-flgを検査し、VH-flgが1ならば、そのパケットのパケットヘッダ中のPTSをSAU-PTS[j][i]にセットし、VH-flgを0にリセットする(ステップ9)。以上の処理をblock毎に行なうことで、EUをすべて読み込んだ時点で、そのEU中のPRUに対するPRU管理テーブルを作成することができる。
【００７４】
以上のアフレコの際のディスク中のヘッド位置とバッファメモリ108中に占めるオリジナルデータ量の時間的変化について図 20に沿って説明する。ここではプログラムが、ディスク中のs11〜s18〜の連続的な領域に配置され、s11〜s13、s13〜s15、s15〜s17がそれぞれEUに対応し、s11〜s12、s13〜s14、s15〜s16、s17〜s18がそれぞれPRUに対応しているとする。
【００７５】
時刻t1の時点では、既にs13までの領域をすべてバッファメモリ108に読み込み、領域s11〜s13のビデオの提示およびそれを見ながらのアフレコオーディオの入力を行っているとする。入力されたアフレコオーディオはバッファメモリ108中の一方のPRU(PRU＃0)に格納されているとする。
【００７６】
時刻t1〜t3では、ディスクドライブ109が領域s13〜s15を読み込む。時刻t2は、時刻t1までに読み込まれた領域s12〜s13のVUがビデオ再生のために使い果たされる時間に対応する。
【００７７】
時刻t3は、領域s12〜s13のVUの提示を見て入力されたアフレコオーディオのエンコーディングが終了する時刻に相当する。この時点で、PRU＃0の最後までデータが記録され、マルチプレクサ107はそのPRUの先頭PTSをCPU102に通知し、アフレコオーディオの格納先をもう一方のPRU(PRU＃1)に切り替える。
【００７８】
ここでは、時刻t3でディスクからの読み込みと、アフレコオーディオのエンコーディングが同時に終了するようになっているが、必ずしも同時である必要はないことは言うまでもない。
【００７９】
CPU102はマルチプレクサ107から送られた先頭PTSからPRU＃0の内容を記録すべきアドレス、すなわち領域s11〜s12のアドレスを求め、時刻t3〜t4でPRU＃0の内容をディスク113に記録する。
【００８０】
時刻t5では次の領域s15〜s17の読み込みを行う。このタイミングはｔ4で書き込み終了後であればよく、バッファメモリ108がオーバーフローを起こさず、またバッファメモリ108のデータがすべてなくなる（アンダーフロー）しないタイミング（ｔ4〜ｔ6の間）で読み込みを開始すればよい。以下同様の処理を繰り返す。
【００８１】
本実施形態によれば、アフレコデータの書き込みにおける時間が従来技術に比して短くなるために、図 20におけるt4〜t5間を短くすることができる。このことは、ディスクの読み込み時間に対する提示時間が短い場合（単位時間中に多くの情報量を割り当てた場合やディスクの読み込み転送レートが低い場合）であっても、ビデオやオーディオが途切れることがないという効果がある。
【００８２】
本実施形態では、PH-PKT中のフィールドStart RLBN of Data for VUをアフレコ時に記録しているが、固定の値であるためオリジナルデータ記録時に予め記録してもよい。さらに、PH-PKT中に各SAUの先頭PTSを記録するフィールドを追加することも考えられる。その場合、オリジナルデータ記録時に予めそのフィールドに値を記録しておくことで、アフレコ時には、PH-PKTを読み込むだけで、PRU管理テーブルを構築するのに必要な情報を得ることができ、図 19の処理が不要になる。
【００８３】
また、本実施形態では、EUの先頭を表わす情報としてVH-PKT中のFirst VU of EUフィールドを用いたが、EUの境界を表わすパケットをEUの先頭に挿入してもよい。
【００８４】
本実施形態ではSAUとVUの提示時間を同一にしているが、そのことは必須ではない。特に、SAUの提示時間をVUより短く、例えば半分や1/4にすることで、アフレコ開始終了時間をより細かい精度にすることができる。例えば、本実施例では、アフレコデータ記録済みのEUSの途中からアフレコを開始した場合、最悪の場合、アフレコ区間の前後のそれぞれ1SAU分(=1VU分)近く記録済みのアフレコデータを無音で上書きしてしまうことになる。しかし、SAUをVUより時間的に短くすれば、無音で上書きしてしまう範囲を小さくすることが可能となる。
【００８５】
以上の手順でアフレコを行なったプログラムの途中から再生する場合の手順を説明する。すでに、ディスクからファイルシステム管理情報およびEUS ManagementファイルがRAM103に読み込まれているものとする。ユーザに指定されたプログラムとタイミングからCPU102は、対応するEUSファイルとPTS(再生開始PTS)を求め、その値をデマルチプレクサ111とデコーダ112に送る。次に、Address LUTを用いて、再生開始PTSから対応するデータの含まれるVUの先頭アドレス(VU先頭アドレス)とPRUの先頭アドレス(PRU先頭アドレス）を計算する。
【００８６】
このとき、図 21(a)のようにPRUとVUのアドレスの差が小さい場合には、前記VUとPRUのアドレスのうち小さい方のアドレスから読込を始めるようにディスクドライブ109に指令を出す。一方、図 21(b)のようにPRUに比べVUのアドレスがある程度以上大きい、すなわちEU中の後半のVUから再生する場合、CPU102はディスクドライブ109にまずEUSI中のPost Recording Unit Sizeで示されるPRUのデータサイズのデータを前記PRU先頭アドレスから読み込むよう指令を出し、次に前記VU先頭アドレスからの読込を指示する。このようにする理由は、EUの後部のVUから再生を始める場合、その前に位置するVUをスキップした方が無駄なデータの読込がなくなりユーザに対するレスポンスが早くなるためである。
【００８７】
デマルチプレクサ111は、ディスクドライブ109からECCデコーダ112を経由して送られてくるデータをバッファメモリ108に蓄積し、デコーダ112からデータの要求があればデコーダ112に応じたデータを順に送る。デコーダ112は、デマルチプレクサ111に要求し、受け取ったデータのデコードを行なう。再生開始PTSがGOPの途中に相当する場合、ビデオデコーダ112はそのGOPの最初からデコードを行ない、再生開始PTSのタイミングから映像の出力を行なう。オーディオデコーダ112も同様に、デマルチプレクサ111から受け取ったデータのデコードを行ない、再生開始PTSのタイミングから音声の出力を行なう。ビデオデコードの方が時間がかかるため、オーディオデコーダ112はビデオデコーダ112が再生開始PTSの映像出力が可能になるのを待ち、その時点でシステムクロック105を再生開始PTSにセットし、提示を開始する。
【００９１】
【発明の効果】
本願発明によれば、データストリームにおけるユニットの再生時間は、記録媒体の入出力にかかわるシーク時間や、転送レートなどによって求められるため、第２のデータ書き込み時に、再生或いは記録が途切れてしまうという問題がない。
【図面の簡単な説明】
【図１】本発明の一実施形態における構成を示すブロック図である。
【図２】本発明の一実施形態におけるのディスク中のデータ配置である。
【図３】本発明の一実施形態におけるのEUSファイルの概要を示す図である。
【図４】パケットの構造を示す図である。
【図５】本発明の一実施形態におけるのEUの構造を示す図である。
【図６】本発明の一実施形態におけるのVUの構造を示す図である。
【図７】本発明の一実施形態におけるのVU Header Packetの構造を示す図である。
【図８】本発明の一実施形態におけるのアフレコ前のPRUの構造を示す図である。
【図９】本発明の一実施形態におけるのアフレコ後のPRUの構造を示す図である。
【図１０】本発明の一実施形態におけるのPRU Header Packetの構造を示す図である。
【図１１】本発明の一実施形態におけるのPRUの配置に関する図である。
【図１２】本発明の一実施形態におけるのEUS Managementファイルの構造を示す図である。
【図１３】本発明の一実施形態におけるのEUSIの構造を示す図である。
【図１４】本発明の一実施形態におけるのAddress LUTの構造を示す図である。
【図１５】本発明の一実施形態におけるのAddress LUT中のPRU Informationの構造を示す図である。
【図１６】本発明の一実施形態におけるのVU Informationの構造を示す図である。
【図１７】本発明の一実施形態におけるのオリジナルデータ記録のフローチャートである。
【図１８】本発明の一実施形態におけるのPRU管理テーブルの構造を示す図である。
【図１９】本発明の一実施形態におけるのPRU管理テーブル作成のフローチャートである。
【図２０】アフレコ時のヘッドの動きとバッファメモリ108におけるデータの占有率の変化の模式図である。
【図２１】本発明の一実施形態におけるのEUの途中から再生を始める場合のアクセス方法を示す図である。
【図２２】従来技術におけるディスク上での記録形態を示す図である。
【図２３】従来技術におけるアフレコ時のヘッドの動きとバッファメモリ108におけるデータの占有率の変化の模式図である。
【符号の説明】
１０１  操作部
１０２  CPU
１０３  RAM
１０４  ROM
１０５  システムクロック
１０６  エンコーダ
１０７  マルチプレクサ
１０８  バッファメモリ
１０９  ディスクドライブ
１１０  バス
１１１  デマルチプレクサ
１１２  デコーダ
１１３  ディスク
１１４  ECCエンコーダ・デコーダ
【図１】
0004169569.tif 000004
【図２】
0004169569.tif 000005
【図３】
0004169569.tif 000006
【図４】
0004169569.tif 000007
【図５】
0004169569.tif 000008
【図６】
0004169569.tif 000009
【図７】
0004169569.tif 000010
【図８】
0004169569.tif 000011
【図９】
0004169569.tif 000012
【図１０】
0004169569.tif 000013
【図１１】
0004169569.tif 000014
【図１２】
0004169569.tif 000015
【図１３】
0004169569.tif 000016
【図１４】
0004169569.tif 000017
【図１５】
0004169569.tif 000018
【図１６】
0004169569.tif 000019
【図１７】
0004169569.tif 000020
【図１８】
0004169569.tif 000021
【図１９】
0004169569.tif 000022
【図２０】
0004169569.tif 000023
【図２１】
0004169569.tif 000024
【図２２】
0004169569.tif 000025
【図２３】
0004169569.tif 000026