JP2001076433A - データ再生方法及びデータ再生装置 - Google Patents

Abstract

(57)【要約】 【課題】 上記したように、任意の位置からの再生を行
う場合、その位置が上記ユニットの中間である場合であ
っても、ユニット毎に読み込み及びデコードを行う必要
がある。再生位置がユニットの先頭に近い位置であれ
ば、あまり無駄はないが、再生位置がユニットの後半で
ある場合には、ユニット全体を読み込んでデコードを行
ってもその大部分は無駄なデータとなってしまう。 【解決手段】 アフレコデータに対するオリジナルデー
タはさらに複数個の小ユニットに分割し、その各小ユニ
ット毎に再生開始可能とすることにより、無駄なデータ
の読み込み、デコードを行うことがなく、再生時には、
ユニットの先頭に近い位置から再生する場合は、ユニッ
ト全体を読み込んでデコードした後、再生を行い、ユニ
ットの後端に近い位置から再生する場合は、アフレコデ
ータは全体を読み出し、オリジナルデータは、読み出し
を小ユニット単位で読み出す。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】本発明は、映像データ、音声
データをハードディスク、光ディスク等のランダムアク
セス可能な記録媒体に対して再生する処理に関する。

【０００２】

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

【０００３】ディスクメディアでアフレコ機能を実現す
る場合の一般的なデータ構造を以下に説明する。

【０００４】記録媒体であるディスク上でのデータ構造
を図１０に示す。ディスクは所定再生時間単位のユニッ
トの列で構成される。データを読み込む際は、このユニ
ット単位で読み込みを行い、必要なデータを取り出す。

【０００５】ビデオやオーディオはユニット中で、図１
０（ｂ）のように、アフレコオーディオブロック、オリ
ジナルオーディオブロック、オリジナルビデオブロック
の順に配置される。それぞれのブロックにはほぼ同じ時
間に対応するアフレコオーディオ、オリジナルオーディ
オ、オリジナルビデオが含まれている。なお、オリジナ
ルオーディオブロックとオリジナルビデオブロックを合
わせてオリジナルブロックと呼ぶことにする。オリジナ
ルプログラム（アフレコオーディオを記録する前の映
像）を記録する際は、アフレコオーディオブロックにダ
ミーのデータを書き込んでおく。

【０００６】次に、従来技術におけるアフレコ時の動作
について図１１に沿って説明する。図中、上段のグラフ
は各手段と、その各手段と記録媒体上の関係を示してい
る。中段は、ディスク中でのヘッドの位置を、下段のグ
ラフはバッファメモリに占めるプログラムデータの割合
を模式的に示したものである。

【０００７】ここではプログラムが、ディスク中のs11
〜s18〜の連続的な領域に配置され、s11〜s13、s13〜s1
5、s15〜s17がそれぞれ１つのユニットに対応し、s11〜
s12、s13〜s14、s15〜s16、s17〜s18がそれぞれアフレ
コオーディオブロックに対応しているとする。

【０００８】時刻ｔ１の時点ですでにｓ13までの領域が
バッファメモリに格納されており、ｓ11〜ｓ13に記録さ
れていたデータがデコードされ提示（再生）されるとと
もに、そのデータのアフレコ音声の入力、エンコードが
行われている。

【０００９】時刻ｔ１〜ｔ３において、領域ｓ13〜ｓ15
のデータをディスクから読み込み、バッファメモリ及び
アフレコバッファへの格納を行う。アフレコバッファは
読み込んだ１ユニット分のデータをそのまま記憶し、図
１０（ｂ）と同様の構成をとるものである。

【００１０】時刻ｔ２は、時刻ｔ１の時点で行われてい
たs11〜s13に記録されていたデータのデコード、再生が
終了する時刻である。時刻ｔ２以降は、時刻ｔ１〜ｔ３
で読み込まれるs13〜s15のデータをデコード、再生する
とともに、そのデータのアフレコ音声の入力、エンコー
ドが行われる。このs13〜s15のデータのデコード、再生
はｔ５まで行われる。

【００１１】ｔ２までに入力されたアフレコ音声は、少
なくともｔ３までにエンコードが終了する。時刻ｔ３に
おいて、ｔ２までに入力されたアフレコ音声をディスク
媒体に記録する。このときに、s11にアクセスする際
に、ディスクの回転待ちの時間を要するが、ディスクの
読み書きの時間に比べると、短時間であるので、ここで
は考慮しない。

【００１２】アフレコ音声のディスクへの書き込みは、
時刻ｔ３〜ｔ４で行われる。このディスクへの書き込み
がｔ４で終了すると、ｔ４からs15〜s17のデータをディ
スクから読み込む。このように以下同様の処理を繰り返
す。

【００１３】この従来技術では、情報圧縮を行うことに
より、データの再生時間よりも読み込み時間が短くなる
ことを利用し、記録再生手段を、記録と再生で時分割し
て利用することで、１つの記録再生手段だけでアフレコ
を実現している。

【００１４】このようなデータ構造において、任意の位
置からの再生を行う場合、上記ユニット毎にデータが読
み出されて再生が行われる。ユニットの先頭の位置から
再生する場合は、ユニット全体のデータを読み出し、デ
コードを行って、再生を行うことができる。

【００１５】次に、ユニットの途中から再生を行いたい
場合を考える。この場合も、ユニット全体のデータを読
み出し、デコードを行った後に、再生を開始したい位置
に対応するアフレコブロック、オリジナルブロックの位
置を求めてその位置からの再生を行うことで、ユニット
の途中からの再生を行うことができる。

【００１６】

【発明が解決しようとする課題】上記したように、任意
の位置からの再生を行う場合、その位置が上記ユニット
の中間である場合であっても、ユニット毎に読み込み及
びデコードを行う必要がある。

【００１７】再生位置がユニットの先頭に近い位置であ
れば、あまり無駄はないが、再生位置がユニットの後半
である場合には、ユニット全体を読み込んでデコードを
行ってもその大部分は無駄なデータとなってしまう。

【００１８】上記したユニットが十分に小さい単位であ
れば、無駄なデータとなる部分は少なくなるが、ユニッ
トが小さくなると、所定時間におけるユニットの数が増
えるために、アフレコ時にヘッドを現在の読み込み位置
からアフレコブロックへ移動させるオーバーヘッドの占
める割合が大きくなり、データの読み込みが表示に追い
つかなくなりビデオやオーディオの再生が途切れてしま
うという問題がある。

【００１９】そこで、本発明は上記課題を解決するもの
であり、アフレコデータに対するオリジナルデータはさ
らに複数個の小ユニットに分割し、その各小ユニット毎
に再生開始可能とすることにより、無駄なデータの読み
込み、デコードを行うことがなく、再生時には、ユニッ
トの先頭に近い位置から再生する場合は、ユニット全体
を読み込んでデコードした後、再生を行い、ユニットの
後端に近い位置から再生する場合は、アフレコデータは
全体を読み出し、オリジナルデータは、読み出しを小ユ
ニット単位で読み出すことによって、無駄な読み出しを
少なくするよう、再生開始位置に応じて適応的に読み出
し方法を変えることによって、データ処理の無駄を少な
くする。

【００２０】

【課題を解決するための手段】本発明における第１の発
明によれば、映像または音声からなるオリジナルデータ
と、前記オリジナルデータと同期して再生されるアフレ
コデータをEUと呼ばれるユニットとし、前記オリジナル
データは独立して再生可能な単位であるVUの集合として
記録された記録媒体のデータ再生方法であって、再生開
始位置が指定されると、該再生開始位置を含むVUの記録
媒体上での位置を算出し、前記アフレコデータととも
に、求められた該再生開始位置を含むVUの記録媒体上で
の位置から前記オリジナルデータを読み出し、前記読み
出されたオリジナルデータ及びアフレコデータを復号し
前記再生開始位置からの同期再生を行うことにより、上
記課題を解決する。

【００２１】本発明における第２の発明によれば、映像
または音声からなるオリジナルデータと、前記オリジナ
ルデータと同期して再生されるアフレコデータをEUと呼
ばれるユニットとし、前記オリジナルデータは独立して
再生可能な単位であるVUの集合として記録された記録媒
体のデータ再生方法であって、再生開始位置が指定され
ると、該再生開始位置を含む第VUの記録媒体上での位置
を算出し、前記アフレコデータとともに、求められた該
再生開始位置を含むVUの記録媒体上での位置以降のオリ
ジナルデータのみを読み出す第１の読み出し時間を算出
し、前記第１の読み出し時間が所定時間より短い場合、
前記アフレコデータとともに、求められた該再生開始位
置を含むVUの記録媒体上での位置以降のオリジナルデー
タのみを読み出し、前記読み出されたオリジナルデータ
及びアフレコデータを復号し前記再生開始位置からの同
期再生を行うことにより、上記課題を解決する。

【００２２】本発明における第3の発明によれば、映像
または音声からなるオリジナルデータと、前記オリジナ
ルデータと同期して再生されるアフレコデータをEUと呼
ばれるユニットとし、前記オリジナルデータは独立して
再生可能な単位であるVUの集合として記録された記録媒
体のデータ再生方法であって、再生開始位置が指定され
ると、該再生開始位置を含むVUの記録媒体上での位置を
算出し、前記アフレコデータとともに、求められた該再
生開始位置を含むVUの記録媒体上での位置以降の前記オ
リジナルデータのみを読み出す第１の読み出し時間と、
前記再生開始位置を含むEU全体を記録順に読み出す第２
の読み出し時間とを算出し、前記第１の読み出し時間が
前記第２の読み出し時間より短い場合、前記アフレコデ
ータとともに、求められた該再生開始位置を含むVUの記
録媒体上での位置以降の前記オリジナルデータのみを読
み出し、前記読み出されたアフレコデータ及びオリジナ
ルデータを復号し前記再生開始位置からの同期再生を行
うことを特徴とするデータ再生方法。

【００２３】本発明における第４の発明によれば、映像
または音声からなるオリジナルデータと、前記オリジナ
ルデータと同期して再生されるアフレコデータをEUと呼
ばれるユニットとし、前記オリジナルデータは独立して
再生可能な単位であるVUの集合として記録された記録媒
体のデータ再生方法であって、再生開始位置が指定され
ると、該再生開始位置を含むVUの記録媒体上での位置を
算出し、前記オリジナルデータの先頭位置から、求めら
れた該再生開始位置を含むVUの直前のVUまでをスキップ
するのにかかる第１の時間と、オリジナルデータの先頭
位置から、求められた該再生開始位置を含むVUの直前の
VUまでを読み出すのにかかる第２の時間とを算出し、前
記第１の時間が前記第２の時間より短い場合、前記アフ
レコデータとともに、求められた該再生開始位置を含む
VUの記録媒体上での位置以降の前記オリジナルデータの
みを読み出し、前記読み出されたアフレコデータ及びオ
リジナルデータを復号し前記再生開始位置からの同期再
生を行うことを特徴とするデータ再生方法。

【００２４】

【発明の実施の形態】本発明の第1の実施形態を説明す
る。図 1は、第1の実施形態におけるアフレコ可能なビ
デオディスクレコーダの構成である。図に示すように、
この装置は、操作部101、CPU102、RAM103、ROM104，シ
ステムクロック105、バッファメモリ108、エンコーダ10
6、マルチプレクサ107、ディスクドライブ109、バス11
0、デマルチプレクサ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/IE
C 13818-1で規定されたパケットの開始コードである。s
tream-idはこのパケットの種類を表わす。PES-packet-l
engthはこのフィールド以降のデータのサイズを表わ
す。PES-header-data-lengthはパケットヘッダのサイズ
を表わす。PTS(プレゼンテーション・タイム・スタン
プ)は、多重化したオーディオやビデオといったエレメ
ンタリ・ストリーム間の同期情報であり、パケット中に
先頭が含まれるアクセスユニット(ビデオの場合1フレー
ム)が再生されるタイミングを90kHzのクロックでカウン
トした値を33ビットで表わしたものである。DTS(デコー
ディング・タイム・スタンプ)は、そのパケット中に先
頭があるアクセスユニットがデコードされるタイミング
をPTSと同じ時間軸で表わしたものである。stuffing-by
tesは、次に説明するようにパケットのサイズを調整す
るために用いられる。

【００３２】もし、パケットが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 138
18-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は他のVUより短くてもよい。つま
り、１つのEUSにおけるVUの再生間隔は常に同一となっ
ている。なお、VUの提示時間は、そのVUがビデオデータ
を含む場合は、そのVUに含まれるビデオフィールド数あ
るいはビデオフレーム数にそれぞれビデオフィールド周
期あるいはビデオフレーム周期をかけたものとして定義
する。

【００３５】1個のEUSを構成するEUは、すべてPRUを含
むか、すべてPRUを含まないかのいずれかにする。EUを
構成するVUの個数Nvuは、EUSの最後のEUを除きEUS内で
は一定にする。つまり、１つのEUSにおいて、EUの提示
時間間隔は常に一定となる。PRUを持たないEUSの場合、
Nvu=1とする。一方、PRUを持つEUSの場合、VUあたりの
提示時間をTpv、回転待ち時間をTv、現在読込中のトラ
ックからアフレコ領域のあるトラックへジャンプする時
間をTk、ディスクからのデータ転送速度をRs、EUS全体
のビットレートをRo、アフレコ音声のチャンネルあたり
のビットレートをRa、アフレコ音声のチャンネル数をNc
hとしたとき、

【００３６】

【数１】

【００３７】とする。なお、ceiling(x)はx以上の最小
の整数を、floor(x)はx以下の最大の整数を求める関数
である。PRUを持つEUSの場合にデータ転送速度などに基
づきNvuの最小値を設定する理由は、EUあたりの時間が
十分に大きくないと、図 23のように逐次的にアフレコ
を行なう際、ヘッドを現在の読込位置からアフレコ領域
へ移動させるオーバーヘッドの占める割合が大きくな
り、データの読込が表示に追いつかなくなりビデオやオ
ーディオの再生が途切れてしまうからである。

【００３８】次にVUについて説明を行なう。VUは、sequ
ence-headerおよびそれに続くGOP-headerを直前に置い
た1個以上の整数個のGOP(グループ・オブ・ピクチャ)か
らなるビデオデータと、それと同期する整数個のAAU(オ
ーディオ・アクセス・ユニット)からなるオーディオデ
ータを含む。GOPは、MPEGビデオ圧縮の単位で、複数の
フィールド群あるいはフレーム群で構成される。AAU
は、オーディオサンプルを0.024秒毎にセグメント化し
それぞれのセグメントを圧縮したものである。GOP、AAU
ともにそれぞれの単位の先頭からデコードする必要があ
るが、VUはそれぞれを整数個含んでいるためVU単位で独
立再生可能である。1VUあたりのビデオフィールド数はN
TSCの場合、24フィールドから60フィールド、PALの場合
は20フィールドから50フィールドの範囲にする。

【００３９】VUは図 6のように、先頭にVU Header Bloc
k(VH-BLK)、次に前述のオーディオデータを格納したA-B
LKの列を置き、最後に前述のビデオデータを格納したV-
BLKの列の順に配置する。A-BLKの個数は、前述のオーデ
ィオデータを格納するのに必要十分なものにする。最後
のA-BLKに余りが出た場合には前述のようにP-PKTあるい
はスタッフィングバイトで調整する。V-BLKも同様の構
成とする。

【００４０】上記のように独立再生が可能な単位である
VUの集合でEUを構成することによって、EUの途中から再
生を開始する場合のオーバーヘッドが小さくなる。転送
速度がデータのビットレートに比べ余裕が無い場合、Nv
uを大きく、すなわちEUあたりの提示時間を長く設定す
る必要があるが、その場合にVUのような単位を設けなけ
れば、例えばEUの終端付近から再生を始める場合でも、
EUの先頭から読み込まなければならず、ユーザに対する
レスポンスの低下を招くことになる。また、VUを整数個
のblock、すなわちセクタで構成することで、VUの先頭
へのアクセスが簡略化される。

【００４１】VH-PKTの構造を図 7に示す。図中のBP(バ
イト・ポジション)は先頭からの相対的なバイト位置で
あり、バイト数はそれぞれのフィールドのバイト数を示
す。packet-start-code-prefix、stream-id、PES-packe
t-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は

【００４３】

【数２】

【００４４】として規定される。なお、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-star
t-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は、各S
AUのPRUの先頭からのblock数を表わす。

【００４８】上記のように、PRUを整数個のBlockすなわ
ちセクタで構成される整数個のAAUを含む単位(SAU)の集
合とすることで、PRUをバッファメモリ108に読み込んだ
後、その中のアフレコデータをSAU単位で部分的に書き
換えることが容易になる。なぜなら、各SAUに含まれるA
AUは他のSAU中のAAUとは独立したパケットに格納されて
いるため、SAU単位で書き換えるのであれば、その他のS
AUには影響を与えることはないからである。もし、この
ような構成を取らなければ、1つのパケットに異なるSAU
に含まれるAAUが存在することになり、すでにアフレコ
済みのPRUに対してその途中からアフレコを行なう際
に、パケットを解いてAAUの先頭を探し、データを書き
換え再度パケット化するという手順を踏まねばならず、
処理が複雑化する。

【００４９】さらに、それぞれのSAUの先頭位置を示す
情報をストリーム中に挿入しているため、PRUをSAU単位
で書き換えする場合に、どの位置から書き換えを開始し
たらよいかが即座にわかる。

【００５０】また、PRU中のデータをVU中のオーディオ
データと同様の構造にしておくことで、例えば、PRU中
のオーディオデータをVU中に部分的にコピーする等、PR
Uと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個分存在する。EU
SIはさらに図 13のように構成される。図中のStart PT
およびEnd PTは、このEUSIが管理するEUSファイル中の
の開始PTSおよび終了PTSの最上位ビットを省略したもの
である。なお、以後このようにPTSの最上位ビットを省
略した形式をPTフォーマットと呼ぶことにする。Post R
ecording Unit SizeはこのEUSIが管理するEUSファイル
中のPRUのサイズを表わす。

【００５５】Address LUT(ルックアップ・テーブル)
は、PTフォーマットで記述されたタイムコードからその
タイムコードに対応するデータが記録されているアドレ
スを検索するためのテーブルである。Address LUTの構
成を図 14に示す。フィールドPBTime of EUは、EUあた
りの提示時間を1/90000[秒]単位で表わしたものであ
り、PTフォーマットと同じスケールとなっている。PB T
ime of VUも、同様にVUあたりの提示時間を1/90000[秒]
単位で表わしたものである。Number of PRU Informatio
nはAddress LUT中のPRU Informationの数であると同時
に、EUS中のPRUの個数も表わす。Number of VU Informa
tionも同様に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を用いて、あるタイムコードP
Tに対応する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.12
5[Mbps/チャンネル]、2[チャンネル]とし、オリジナル
およびアフレコで共通に用いることにする。このとき、
VUあたりの提示時間Tpvは約0.5秒となる。また、アフレ
コが可能なEUあたりのVU数Nvuの範囲は、7≦Nvu≦20と
なる。本実施形態では、Nvu=8、すなわちEUあたりの提
示時間は約4秒となる。

【００５９】オリジナルプログラム記録時のCPU102の処
理の流れを図 17に沿って説明する。すでに、ディスク
からEUS Managementファイルやファイルシステム管理情
報がRAM103に読み込まれているものとする。CPU102はエ
ンコーダ106を起動し、次にファイルシステム管理情報
を基に1EU分のデータを記録するのに十分な連続領域が
ディスク上にあるかどうか調べる(ステップ1)。もし、
なければ録画を停止する。

【００６０】もし十分な領域があれば、記録対象のVUが
EU中の何番目のVUかを表わす変数iを0にリセットし、空
き領域先頭アドレスを変数addrに記憶させる(ステップ
2)。次に、マルチプレクサ107から1VU分のデータがバッ
ファメモリ108にバッファリングされたことの通知を待
つ(ステップ3)。マルチプレクサ107から通知が来たら、
変数iが0のときは、変数addrがECCブロック境界かどう
かを判断し(ステップ9)、もし、ECCブロック境界でなけ
れば、次のECCブロック境界までバッファメモリ108中の
VUデータをディスクに記録する(ステップ10)。次に、PH
-PKTおよびP-PKTでPRUをRAM103中に構成し、それをディ
スクに記録する(ステップ11)。次に、バッファメモリ10
8中の先頭のVUデータをディスクに記録する(ステップ
6)。記録が終わったら変数iをインクリメントする(ステ
ップ7)。変数iがEU中のVU数を表わす変数Nvuより小さけ
ればステップ4にジャンプし(ステップ8)、等しくなれば
ステップ2にジャンプする。以上の処理を、操作部101か
ら停止指令がきたり、ディスク中に十分な連続領域が無
くなるまで、EU単位に行なっていく。

【００６１】以上のCPU102の処理と並行して、マルチプ
レクサ107は、オーディオ、ビデオそれぞれのエンコー
ダ106から送られるデータにPTS等を付与しパケット化し
バッファメモリ108に貯えていく。1GOP分のV-PKTとそれ
に同期するA-PKTがバッファメモリ108に貯えられたらCP
U102にVU分のデータをバッファリングしたことを通知す
る。

【００６２】以上の手順で記録を行なったオリジナルプ
ログラムの再生時にユーザからアフレコ開始の指示が与
えられた場合の処理の流れを説明する。すでに、ディス
クからEUS Managementファイルおよびファイルシステム
管理情報がRAM103に読み込まれているものとする。CPU1
02はデコーダ112を起動し、ファイルシステム管理情報
を基に、指定されたEUSファイルを先頭から読み込むよ
うにディスクドライブ109に指令を出す。ディスクドラ
イブ109はECCデコーダ112を経由してデマルチプレクサ1
11に読み込んだデータを送り、デマルチプレクサ111
は、バッファメモリ108にデータを蓄積していく。デコ
ーダ112は、ビデオやオーディオの再生に必要なデータ
をデマルチプレクサ111に要求し、デマルチプレクサ111
はその要求に応じてバッファメモリ108に蓄積したデー
タを、パケットヘッダ中のstream-idに基づき適切なデ
コーダ112に送る。デコーダ112はデマルチプレクサ111
から十分なデータを受け取りビデオやオーディオを出力
可能になった時点でそのデータに対応するPTSでシステ
ムクロック105を初期化し、以後は、システムクロック1
05の値を基準にして出力の同期を取る。

【００６３】デマルチプレクサ111は、ユーザからアフ
レコが指示されたときのために現在再生中のデータに対
応するPRUと、その次に再生するEUに対応するPRUの合計
2個のPRUを常にバッファメモリ108内に保持する。さら
に、それらのPRUを管理するためのテーブル(PRU管理テ
ーブル)をRAM103中に作成する。

【００６４】PRU管理テーブルの構成を図 18に示す。PR
U管理テーブルは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が22
8228だった場合を例に取って説明する。まず、SAU-PTS
[i][j]中でアフレコ開始PTSを超えない最大のSAU開始PT
Sを持つSAU番号、PRU番号の組を検索する。図 18の場
合、PRU番号=0、SAU番号=5となる。次にその番号に対応
するRLBN[0][5]の値を見る。その結果、SAU#5のアドレ
ス41が得られる。したがって、バッファメモリ108中のP
RU#0の先頭から第41 block目に存在するSAU#5からアフ
レコデータを記録していくことになる。

【００６７】アフレコデータを格納中のPRUのインデッ
クスをnとしたとき、そのPRUの最後までデータを格納し
た時点で、i=0から7までのRLBN[n][i]の値をを現在のPR
U中のPH-PKTのフィールドStart RLBN of Data for VUに
順に格納し、PRUの最後までデータが格納されたことをC
PU102に通知する。その際、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の個数をV
H-PKT中のStart RLBN of Videoから求め、その個数がSA
Uに含まれるA-BLKの個数と同じことを利用して、SAU先
頭アドレステーブルを構築し、同時にVU中の最初のA-PK
TのPTSを抜き出しSAU先頭PTSテーブルを構築することに
ある。まず、VH-PKTの直後であることを表わすフラグで
あるVH-flgをリセットし、バッファメモリ108中のPRU番
号を指すインデックスであるjを1にセットする(ステッ
プ1)。デマルチプレクサ111に到着したパケットがVH-PK
Tの場合(ステップ2)、ステップ3にジャンプし、そうで
ないならステップ7にジャンプする。

【００６９】パケットがVH-PKTの場合、VH-PKT中のFirs
t VU of EUフィールドが1かどうか検査し(ステップ3)、
1なら、それ以降のデータを格納する領域を現在のPRUか
らもう一方のPRUを変更するために、jをインクリメント
する。同時に、RLBN[j][0]に1をセットする。さらに、
一時変数tmpに現在のVH-PKT中のStart RLBN of Videoフ
ィールドの値をセットし、iに0をセットする(ステップ
4)。もし、FirstVU ofEUフィールドが0なら、RLBN[j]
[i]に一時変数tmpをセットし、さらにtmpに現在のVH-PK
T中のStart RLBN of Videoフィールドの値から1引いた
ものを加える(ステップ6)。ここで1を引くのは、VU中の
A-BLKの個数にVH-BLKの個数1を加えた値であるStart RL
BN 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-fl
gが1ならば、そのパケットのパケットヘッダ中のPTSをS
AU-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中のフィールドSt
art RLBN of Data for VUをアフレコ時に記録している
が、固定の値であるためオリジナルデータ記録時に予め
記録してもよい。さらに、PH-PKT中に各SAUの先頭PTSを
記録するフィールドを追加することも考えられる。その
場合、オリジナルデータ記録時に予めそのフィールドに
値を記録しておくことで、アフレコ時には、PH-PKTを読
み込むだけで、PRU管理テーブルを構築するのに必要な
情報を得ることができ、図 19の処理が不要になる。

【００８０】また、本実施形態では、EUの先頭を表わす
情報としてVH-PKT中のFirst VU ofEUフィールドを用い
たが、EUの境界を表わすパケットをEUの先頭に挿入して
もよい。

【００８１】本実施形態ではSAUとVUの提示時間を同一
にしているが、そのことは必須ではない。特に、SAUの
提示時間をVUより短く、例えば半分や1/4にすること
で、アフレコ開始終了時間をより細かい精度にすること
ができる。例えば、本実施例では、アフレコデータ記録
済みのEUSの途中からアフレコを開始した場合、最悪の
場合、アフレコ区間の前後のそれぞれ1SAU分(=1VU分)近
く記録済みのアフレコデータを無音で上書きしてしまう
ことになる。しかし、SAUをVUより時間的に短くすれ
ば、無音で上書きしてしまう範囲を小さくすることが可
能となる。

【００８２】以上の手順でアフレコを行なったプログラ
ムの途中から再生する場合の手順を説明する。すでに、
ディスクからファイルシステム管理情報およびEUS Mana
gementファイルがRAM103に読み込まれているものとす
る。ユーザに指定されたプログラムとタイミングからCP
U102は、対応する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 Siz
eで示されるPRUのデータサイズのデータを前記PRU先頭
アドレスから読み込むよう指令を出し、次に前記VU先頭
アドレスからの読込を指示する。このようにする理由
は、EUの後部のVUから再生を始める場合、その前に位置
するVUをスキップした方が無駄なデータの読込がなくな
りユーザに対するレスポンスが早くなるためである。

【００８４】このように、ＶＵをスキップせずにＰＲＵ
及びＶＵをＥＵ単位で読み込んでデコード、再生を行う
場合と、ＰＲＵを読みこんだあと、ＶＵは再生開始点を
含むＶＵまでスキップしてから読み込む場合とは、どち
らがレスポンスが早いかを算出して、レスポンスの早い
手法を選択する。

【００８５】具体的な算出の例を示すと、例えば、１つ
のVUを読み込む時間をRvu、EUを構成するVUの数をNvu、
再生開始点を含むVUの先頭からの位置（個数）をNrs、V
Uのスキップにかかる時間をTskとすると、 Rvu × Nvu＞ Tsk + Rvu×(Nvu−Nrs +1) であれば、PRUを読み出した後に、再生開始点を含むVU
までスキップを行い読み込みを行う。

【００８６】また、他の例としては、ＶＵの先頭から再
生開始点を含むＶＵまでスキップを行うのにかかる時間
と、同じ区間をスキップせずに読み出すのにかかる時間
を比較することによって、どちらの手法を用いるかを判
断することも可能である。この場合、 Rvu ×(Nrs−1)＞ Tsk であれば、PRUを読み出した後に、再生開始点を含むVU
までスキップを行い読み込みを行うようにすればよい。

【００８７】また別の手法としては、スキップを行った
場合の所要時間が所定時間以内であればスキップを行う
などの判断基準を用いてもよい。

【００８８】再生開始点を含むVUの先頭位置は、再生開
始点のタイムコードをTsとすると、TsからEUS Informat
ion中のStart PTを引いたものを、VU Information中のP
B time of VUで割り、小数部を切り捨てた値に対応する
インデックスのVU Information中のRLBN of VUを参照す
ることで得ることができる。このようにして得られた再
生開始点を含むVUの先頭位置を用いて、PRUを読み込ん
だ後に、この再生開始点を含むVUの先頭位置までスキッ
プを行い、EUを構成するVUの最後までを読み出す。

【００８９】デマルチプレクサ111は、ディスクドライ
ブ109からECCデコーダ112を経由して送られてくるデー
タをバッファメモリ108に蓄積し、デコーダ112からデー
タの要求があればデコーダ112に応じたデータを順にに
送る。デコーダ112は、デマルチプレクサ111に要求し、
受け取ったデータのデコードを行なう。再生開始PTSがG
OPの途中に相当する場合、ビデオデコーダ112はそのGOP
の最初からデコードを行ない、再生開始PTSのタイミン
グから映像の出力を行なう。オーディオデコーダ112も
同様に、デマルチプレクサ111から受け取ったデータの
デコードを行ない、再生開始PTSのタイミングから音声
の出力を行なう。ビデオデコードの方が時間がかかるた
め、オーディオデコーダ112はビデオデコーダ112が再生
開始PTSの映像出力が可能になるのを待ち、その時点で
システムクロック105を再生開始PTSにセットし、提示を
開始する。

【００９０】

【発明の効果】本発明によれば、オリジナルデータと対
応するアフレコデータとを対応づけて記録し、オリジナ
ルデータを記録する領域を独立して再生可能な単位に分
割して記録するため、途中から再生を行う際に、オリジ
ナルデータ全体を読み込む必要がなく、高速に再生を開
始することが可能となる。

【図面の簡単な説明】

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

【図２】本発明の一実施形態におけるのディスク中のデ
ータ配置である。

【図３】本発明の一実施形態におけるのEUSファイルの
概要を示す図である。

【図４】パケットの構造を示す図である。

【図5】本発明の一実施形態におけるのEUの構造を示す
図である。

【図６】本発明の一実施形態におけるのVUの構造を示す
図である。

【図７】本発明の一実施形態におけるのVU Header Pack
etの構造を示す図である。

【図８】本発明の一実施形態におけるのアフレコ前のPR
Uの構造を示す図である。

【図９】本発明の一実施形態におけるのアフレコ後のPR
Uの構造を示す図である。

【図１０】本発明の一実施形態におけるのPRU Header P
acketの構造を示す図である。

【図１１】本発明の一実施形態におけるのPRUの配置に
関する図である。

【図１２】本発明の一実施形態におけるのEUS Manageme
ntファイルの構造を示す図である。

【図１３】本発明の一実施形態におけるのEUSIの構造を
示す図である。

【図１４】本発明の一実施形態におけるのAddress LUT
の構造を示す図である。

【図１５】本発明の一実施形態におけるのAddress LUT
中のPRU Informationの構造を示す図である。

【図１６】本発明の一実施形態におけるのVU Informati
onの構造を示す図である。

【図１７】本発明の一実施形態におけるのオリジナルデ
ータ記録のフローチャートである。

【図１８】本発明の一実施形態におけるのPRU管理テー
ブルの構造を示す図である。

【図１９】本発明の一実施形態におけるのPRU管理テー
ブル作成のフローチャートである。

【図２０】アフレコ時のヘッドの動きとバッファメモリ
108におけるデータの占有率の変化の模式図である。

【図２１】本発明の一実施形態におけるのEUの途中から
再生を始める場合のアクセス方法を示す図である。

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

【図２３】従来技術におけるアフレコ時のヘッドの動き
とバッファメモリ108におけるデータの占有率の変化の
模式図である。

【符号の説明】

１０１ 操作部 １０２ CPU １０３ RAM １０４ ROM １０５ システムクロック １０６ エンコーダ １０７ マルチプレクサ １０８ バッファメモリ １０９ ディスクドライブ １１０ バス １１１ デマルチプレクサ １１２ デコーダ １１３ ディスク １１４ ECCエンコーダ・デコーダ

───────────────────────────────────────────────────── フロントページの続き Ｆターム(参考） 5C052 AA02 AA03 AC08 AC10 CC11 CC12 DD04 DD06 DD10 5C053 FA14 FA23 GB01 GB11 GB37 GB38 HA29 HA40 JA02 JA07 KA24 5D044 AB05 AB07 DE03 DE17 DE57 EF07 FG18 FG21 GK11

Claims (8)

【特許請求の範囲】
1. 【請求項１】 映像または音声からなる第１のデータ
   と、前記第１のデータと同期して再生される第２のデー
   タを第１のユニットとし、 前記第１のデータは独立して再生可能な単位である第２
   のユニットの集合として記録された記録媒体のデータ再
   生方法であって、 再生開始位置が指定されると、該再生開始位置を含む第
   ２のユニットの記録媒体上での位置を算出し、 前記第２のデータとともに、求められた該再生開始位置
   を含む第２のユニットの記録媒体上での位置から前記第
   １のデータを読み出し、 前記読み出された第１及び第２のデータを復号し前記再
   生開始位置からの同期再生を行うことを特徴とするデー
   タ再生方法。
2. 【請求項２】 映像または音声からなる第１のデータ
   と、前記第１のデータと同期して再生される第２のデー
   タを第１のユニットとし、 前記第１のデータは独立して再生可能な単位である第２
   のユニットの集合として記録された記録媒体のデータ再
   生方法であって、 再生開始位置が指定されると、該再生開始位置を含む第
   ２のユニットの記録媒体上での位置を算出し、 前記第２のデータとともに、求められた該再生開始位置
   を含む第２のユニットの記録媒体上での位置以降の前記
   第１のデータのみを読み出す第１の読み出し時間を算出
   し、 前記第１の読み出し時間が所定時間より短い場合、前記
   第２のデータとともに、求められた該再生開始位置を含
   む第２のユニットの記録媒体上での位置以降の前記第１
   のデータのみを読み出し、 前記読み出された第１及び第２のデータを復号し前記再
   生開始位置からの同期再生を行うことを特徴とするデー
   タ再生方法。
3. 【請求項３】 映像または音声からなる第１のデータ
   と、前記第１のデータと同期して再生される第２のデー
   タを第１のユニットとし、 前記第１のデータは独立して再生可能な単位である第２
   のユニットの集合として記録された記録媒体のデータ再
   生方法であって、 再生開始位置が指定されると、該再生開始位置を含む第
   ２のユニットの記録媒体上での位置を算出し、 前記第２のデータとともに、求められた該再生開始位置
   を含む第２のユニットの記録媒体上での位置以降の前記
   第１のデータのみを読み出す第１の読み出し時間と、前
   記再生開始位置を含む第１のユニット全体を記録順に読
   み出す第２の読み出し時間とを算出し、 前記第１の読み出し時間が前記第２の読み出し時間より
   短い場合、前記第２のデータとともに、求められた該再
   生開始位置を含む第２のユニットの記録媒体上での位置
   以降の前記第１のデータのみを読み出し、 前記読み出された第１及び第２のデータを復号し前記再
   生開始位置からの同期再生を行うことを特徴とするデー
   タ再生方法。
4. 【請求項４】 映像または音声からなる第１のデータ
   と、前記第１のデータと同期して再生される第２のデー
   タを第１のユニットとし、 前記第１のデータは独立して再生可能な単位である第２
   のユニットの集合として記録された記録媒体のデータ再
   生方法であって、 再生開始位置が指定されると、該再生開始位置を含む第
   ２のユニットの記録媒体上での位置を算出し、 第１のデータの先頭位置から、求められた該再生開始位
   置を含む第２のユニットの直前の第２のユニットまでを
   スキップするのにかかる第１の時間と、第１のデータの
   先頭位置から、求められた該再生開始位置を含む第２の
   ユニットの直前の第２のユニットまでを読み出すのにか
   かる第２の時間とを算出し、 前記第１の時間が前記第２の時間より短い場合、前記第
   ２のデータとともに、求められた該再生開始位置を含む
   第２のユニットの記録媒体上での位置以降の前記第１の
   データのみを読み出し、 前記読み出された第１及び第２のデータを復号し前記再
   生開始位置からの同期再生を行うことを特徴とするデー
   タ再生方法。
5. 【請求項５】 映像または音声からなる第１のデータ
   と、前記第１のデータと同期して再生される第２のデー
   タを第１のユニットとし、 前記第１のデータは独立して再生可能な単位である第２
   のユニットの集合として記録された記録媒体を再生する
   データ再生装置であって、 データ中の再生開始位置を指定する手段と、 前記再生開始位置を含む第２のユニットの記録媒体上で
   の位置を算出する手段と、 前記第２のデータとともに、求められた該再生開始位置
   を含む第２のユニットから前記第１のデータを読み出す
   手段と、 前記読み出された第１及び第２のデータを復号し前記再
   生開始位置からの同期再生を行う手段とを備えることを
   特徴とするデータ再生装置。
6. 【請求項６】 映像または音声からなる第１のデータ
   と、前記第１のデータと同期して再生される第２のデー
   タを第１のユニットとし、 前記第１のデータは独立して再生可能な単位である第２
   のユニットの集合として記録された記録媒体を再生する
   データ再生装置であって、 データ中の再生開始位置を指定する手段と、 該再生開始位置を含む第２のユニットの記録媒体上での
   位置を算出する手段と、 前記第２のデータとともに、求められた該再生開始位置
   を含む第２のユニットの記録媒体上での位置以降の前記
   第１のデータのみを読み出す第１の読み出し時間を算出
   する手段と、 前記第１の読み出し時間が所定時間より短い場合、前記
   第２のデータとともに、求められた該再生開始位置を含
   む第２のユニットの記録媒体上での位置以降の前記第１
   のデータのみを読み出す手段と、 前記読み出された第１及び第２のデータを復号し前記再
   生開始位置からの同期再生を行う手段とを備えることを
   特徴とするデータ再生装置。
7. 【請求項７】 映像または音声からなる第１のデータ
   と、前記第１のデータと同期して再生される第２のデー
   タを第１のユニットとし、 前記第１のデータは独立して再生可能な単位である第２
   のユニットの集合として記録された記録媒体を再生する
   データ再生装置であって、 再生開始位置を指定する指定手段と、 該再生開始位置を含む第２のユニットの記録媒体上での
   位置を算出する手段と、 前記第２のデータとともに、求められた該再生開始位置
   を含む第２のユニットの記録媒体上での位置以降の前記
   第１のデータのみを読み出す第１の読み出し時間と、前
   記再生開始位置を含む第１のユニット全体を記録順に読
   み出す第２の読み出し時間とを算出する手段と、 前記第１の読み出し時間と前記第２の読み出し時間を比
   較する手段と、 前記第１の読み出し時間が前記第２の読み出し時間より
   短い場合、前記第２のデータとともに、求められた該再
   生開始位置を含む第２のユニットの記録媒体上での位置
   以降の前記第１のデータのみを読み出す手段と、 前記読み出された第１及び第２のデータを復号し前記再
   生開始位置からの同期再生を行う手段とを備えるを特徴
   とするデータ再生装置。
8. 【請求項８】 映像または音声からなる第１のデータ
   と、前記第１のデータと同期して再生される第２のデー
   タを第１のユニットとし、 前記第１のデータは独立して再生可能な単位である第２
   のユニットの集合として記録された記録媒体を再生する
   データ再生装置であって、 再生開始位置を指定する指定手段と、 該再生開始位置を含む第２のユニットの記録媒体上での
   位置を算出する手段と、 第１のデータの先頭位置から、求められた該再生開始位
   置を含む第２のユニットの直前の第２のユニットまでを
   スキップするのにかかる第１の時間と、第１のデータの
   先頭位置から、求められた該再生開始位置を含む第２の
   ユニットの直前の第２のユニットまでを読み出すのにか
   かる第２の時間とを算出する手段と、 前記第１の時間と前記第２の時間を比較する手段と、 前記第１の時間が前記第２の時間より短い場合、前記第
   ２のデータとともに、求められた該再生開始位置を含む
   第２のユニットの記録媒体上での位置以降の前記第１の
   データのみを読み出す手段と、 前記読み出された第１及び第２のデータを復号し前記再
   生開始位置からの同期再生を行う手段とを備えるを特徴
   とするデータ再生装置。