JP5306526B2 - ストリーム情報記録に用いる情報記憶媒体、情報記録方法、情報再生方法、および情報再生装置 - Google Patents

Description

この発明は、デジタル放送などのビットストリーム情報あるいはパケット構造をもって伝送されるストリームデータを処理する技術に関する。

近年、ＴＶ放送はデジタル放送の時代に突入してきた。それに伴い、デジタルＴＶ放送のデジタルデータをその内容を問わずデジタルデータのままで保存する装置、いわゆるストリーマが要望されるようになってきた。

現在放送されているデジタルＴＶ放送では、ＭＰＥＧのトランスポートストリームが採用されている。今後も、動画を使用したデジタル放送の分野では、ＭＰＥＧトランスポートストリームが標準的に用いられると考えられる。

このデジタル放送データを記録するストリーマとして、現在市販されているものとしては、Ｄ−ＶＨＳ（デジタルＶＨＳ）などの家庭用デジタルＶＣＲがある（特許文献１参照）。このＤ−ＶＨＳを利用したストリーマでは、放送されたビットストリームがそのままテープに記録される。そのため、ビデオテープには、複数の番組が多重されて記録されることになる。

再生時には、最初から再生する場合、あるいは途中から再生する場合にも、そのまま全てのデータが、ＶＣＲからセットトップボックス（デジタルＴＶの受信装置：以下ＳＴＢと略記する）に送り出される。このＳＴＢにおいて、ユーザ操作等により、送り出されたデータ内から所望の番組が選択される。選択された番組情報は、ＳＴＢからデジタルＴＶ受像機等に転送されて、再生（ビデオ＋オーディオ等の再生）がなされる。

このＤ−ＶＨＳストリーマでは、記録媒体にテープが用いられるため、素早いランダムアクセスが実現できず、所望の番組の希望位置に素早くジャンプして再生することが困難となる。

このようなテープの欠点（ランダムアクセスの困難性）を解消できる有力な候補として、ＤＶＤ−ＲＡＭなどの大容量ディスクメディアを利用したストリーマが考えられる。その場合、ランダムアクセスおよび特殊再生などを考えると、必然的に、管理データを放送データとともに記録する必要性が出てくる。

特開平９−３２２１４８号公報

この発明の課題は、ストリーム情報記録の処理に関する改善を図ることである。

この発明の実施の形態では、ＭＰＥＧトランスポートストリームのストリームデータを記録したデータブロックを有するデータエリアおよびこのストリームデータの管理情報を記録した管理エリアを持つ情報記憶媒体が用いられる。前記データブロックには前記ストリームデータを格納する部分が含まれ、前記ストリームデータを格納する部分がタイムスタンプ付きトランスポートパケットにより埋められ、前記ストリームデータはユーザに認識できない内部情報を記録できるように構成され、前記タイムスタンプが、前記タイムスタンプ付きトランスポートパケットの到着時間情報を記述するように構成される。ここで、前記管理情報はタイムマップ情報を含み、前記タイムマップ情報が、所望のパケットを見つけるために前記トランスポートパケットに付された前記到着時間情報を相対論理アドレスに変換するように構成される。

ストリーム情報記録の処理に関する改善を図ることができる。

この発明の一実施の形態に係るストリームデータのデータ構造を説明する図。 この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図。 この発明の一実施の形態に係る情報媒体（ＤＶＤ録再ディスク）上の記録データ構造を説明する図。 この発明におけるストリームオブジェクト（ＳＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の関係を説明する図。 タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容を説明する図。 オリジナルセルおよびユーザ定義セルにおけるセル範囲指定方法を説明する図。 この発明の一実施の形態に係るストリームデータ記録再生装置（ストリーマ）の構成を説明する図。 デジタル放送のコンテンツとＩＥＥＥ１３９４における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図。 ＭＰＥＧにおける映像情報圧縮方法とトランスポートパケットとの関係、およびＭＰＥＧにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図。 図１、図８、図９等に示されたＰＥＳヘッダの内部構造を説明する図。 図１に示されたストリームブロックヘッダの内部構造を説明する図。 図１に示されたセクタデータヘッダの内部構造を説明する図。 この発明の一実施の形態に係るストリームデータのエンコード手順および録画手順を説明するフローチャート図。 この発明の一実施の形態に係るストリームデータのデコード手順および再生手順を説明するフローチャート図。 この発明の一実施の形態に係るストリームデータの部分消去方法を説明する図（例１）。 この発明の他の実施の形態に係るストリームデータの部分消去方法説明図を説明する図（例２）。 この発明の一実施の形態に係るストリームデータの部分消去手順を説明するフローチャート図。 ＭＰＥＧエンコードされた映像データ（部分消去前あるいは仮消去前）に対する時間管理情報設定方法を説明する図。 図１８の映像データに対応したオリジナルセル情報（部分消去前あるいは仮消去前）における時間情報とフィールド情報との関係を説明する図。 ＭＰＥＧエンコードされた映像データ（部分消去後あるいは仮消去後）に対する時間管理情報設定方法を説明する図。 図２０の映像データに対応したオリジナルセル情報（部分消去後あるいは仮消去後）における時間情報とフィールド情報との関係を説明する図。 図１５の変形例であって、全ストリームブロックが一定サイズ（３２セクタ＝２ＥＣＣブロック）のＳＯＢＵで構成される場合におけるストリームデータの部分消去方法の一例を説明する図。 図２２の変形例であって、全ストリームブロックが一定サイズ（３２セクタ＝２ＥＣＣブロック）のＳＯＢＵで構成される場合におけるストリームデータの仮消去方法の一例を説明する図。 図１６の変形例であって、全ストリームブロックが一定サイズ（３２セクタ＝２ＥＣＣブロック）のＳＯＢＵで構成される場合におけるストリームデータの部分消去方法の他例を説明する図。 図２４の変形例であって、全ストリームブロックが一定サイズ（３２セクタ＝２ＥＣＣブロック）のＳＯＢＵで構成される場合におけるストリームデータの仮消去方法の他例を説明する図。 ストリームブロック（ＳＯＢＵ）を構成するセクタの内部構成（アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック）の一例を説明する図。 ストリーマの管理情報（図２のＳＴＲＥＡＭ．ＩＦＯまたはＳＲ＿ＭＡＮＧＲ．ＩＦＯに対応）の内部データ構造を説明する図。 ＰＧＣ情報（図３のＯＲＧ＿ＰＧＣＩ／ＵＤ＿ＰＧＣＩＴまたは図２７のＰＧＣＩ＃ｉ）の内部データ構造を説明する図。 ストリームファイル情報テーブル（図３または図２７のＳＦＩＴ）の内部データ構造を説明する図。 あるプログラム＃ｊの一部が部分的に消去（仮消去および本消去）された場合における、セルと対応時間情報（ＳＣ＿Ｓ＿ＡＰＡＴ／ＳＣ＿Ｅ＿ＡＰＡＴ；ＥＲＡ＿Ｓ＿ＡＰＡＴ／ＥＲＡ＿Ｅ＿ＡＰＡＴ）との関係例（その１）を説明する図。 あるプログラム＃ｊの一部が部分的に消去（仮消去および本消去）された場合における、セルと対応時間情報（ＳＣ＿Ｓ＿ＡＰＡＴ／ＳＣ＿Ｅ＿ＡＰＡＴ）との関係例（その２）を説明する図。 オリジナルＰＧＣあるいはユーザ定義ＰＧＣで指定されるセルと、これらのセルに対応するＳＯＢＵとが、タイムマップ情報によってどのように関係付けられるかを例示する図。 各ストリームオブジェクト（ＳＯＢ）を構成するＳＯＢＵの内容が、図３のデータエリア２０７（図１ではデータエリア２１〜２３）にどのように記録されるかを例示する図。

以下、図面を参照して、この発明の一実施の形態に係るストリームデータの生成方法、その記録方法、および記録されたストリームデータの部分消去処理方法その他を説明する。

図１は、この発明の一実施の形態に係るストリームデータのデータ構造を説明する図である。

ＤＶＤ−ＲＡＭディスク等の情報記憶媒体上に記録されるストリームデータは、ストリームデータ内の映像情報のコンテンツ毎にストリームオブジェクト（以下、適宜ＳＯＢと略記する）としてまとめられている。各ＳＯＢは、１つのリアルタイムな連続記録により得られたストリームデータにより形成される。

図１（ｆ）は、１以上あるストリームオブジェクトのうち１個のＳＯＢ＃Ａ・２９８について示している。ＤＶＤ−ＲＡＭディスクにこのストリームデータが記録される場合には、各々が２０４８ｋバイトのセクタを最小単位として記録される。さらに、１６個のセクタをまとめて１個のＥＣＣブロックとし、同一ＥＣＣブロック内でインターリーブ（データ配列順序の並び替え）とエラー訂正用の訂正コードの付加が行われる。

この実施の形態では、１個または複数のＥＣＣブロックを単位としてストリームブロックが構成され、このストリームブロック単位でストリーム情報の記録あるいは部分消去が行われる。

この実施の形態では、何個のＥＣＣブロックでストリームブロックが構成されるかは、転送されるストリームデータの転送レートに応じて決めることができる。たとえば、図１（ｅ）の例では、ストリームブロック＃１は２つのＥＣＣブロック＃α、＃βで構成され、ストリームブロック＃２は３つのＥＣＣブロック＃γ、＃δ、＃εで構成されている。ＤＶＤストリーマでは、２個のＥＣＣブロック（３２セクタ）で１つのストリームブロック（ストリームオブジェクトユニットＳＯＢＵ）が構成される。

各ＥＣＣブロックは、図１（ｄ）に示すように、１６セクタで構成される。したがって、図１（ｄ）（ｅ）から分かるように、２ＥＣＣブロックで構成されるストリームブロック（あるいはＳＯＢＵ）＃１は、３２セクタ（セクタＮｏ．０〜セクタＮｏ．３１）に相当する。

つまり、１セクタ＝２ｋバイトとすれば、ストリームブロック（ＳＯＢＵ）は、６４ｋバイト（３２セクタ）の固定サイズとして、この発明を実施することができる。

各セクタの内容はストリームパック（詳細は図９等を参照して後述）に対応している。そして、たとえばセクタＮｏ．０（図１（ｄ））に対応するストリームパックは、図１（ｃ）に示すように、パックヘッダ１と、ＰＥＳヘッダ６と、ストリームブロックヘッダ（図１１を参照して後述）１１と、データエリア２１とを含んでいる。また、セクタＮｏ．１（図（ｄ））に対応するストリームパックは、図１（ｃ）に示すように、パックヘッダ２と、ＰＥＳヘッダ７と、セクタデータヘッダ（図１２を参照して後述）１２と、データエリア２２とを含んでいる。

なお、図１（ｃ）のＰＥＳヘッダ６、７の内部構成例は、図１０を参照して後述する。

図１（ｃ）のデータエリア２１は、図１（ｂ）に示すように、タイムスタンプとトランスポートパケットとのペアの配列（タイムスタンプａ、トランスポートパケットａ、タイムスタンプｂ、………トランスポートパケットｄ）を含んでいる。同様に、データエリア２２は、タイムスタンプとトランスポートパケットとのペアの別配列を含んでいる。一方、後方のデータエリア２３は、図１（ｂ）に示すように、トランスポートパケットｆ、エンドコード３１、およびパディングエリア３６を含んでいる。

図１（ｂ）のタイムスタンプとトランスポートパケットの複数ペアは、図１（ａ）に示すような配列のビットストリームとなる。

ＳＯＢ＃Ａ・２９８（図１（ｆ））の前方のストリームブロック＃１（図１（ｅ））のデータ構造は図１（ｄ）〜（ｂ）のようになるが、ＳＯＢ＃Ａ・２９８の後方のストリームブロック＃２（図１（ｇ））のデータ構造は、次のようになる。

すなわち、ストリームブロック＃２の末尾ＥＣＣブロック＃εの後方セクタＮｏ．７８（図１（ｈ））は、図１（ｉ）に示すように、パックヘッダ３と、ＰＥＳヘッダ８と、セクタデータヘッダ１３と、データエリア２４とを含んでいる。また、ＥＣＣブロック＃εの最終セクタＮｏ．７９（図１（ｈ））は、図１（ｉ）に示すように、パックヘッダ４とパディングパケット４０を含んでいる。

セクタＮｏ．７８のデータエリア２４は、図１（ｊ）に示すように、トランスポートパケットｚと、エンドコード３２と、パディングエリア３７とを含んでいる。また、最終セクタＮｏ．７９のパディングパケット４０は、図１（ｊ）に示すように、ＰＥＳヘッダ９とパディングエリア３８を含んでいる。

なお、パディングエリア３８の内容については、図２６を参照して後述する。

図２は、この発明の一実施の形態に係るデータファイルのディレクトリ構造を説明する図である。

ＤＶＤーＲＡＭディスク等の情報記憶媒体に記録される情報は、各情報毎に階層ファイル構造を持っている。この実施の形態において説明される映像情報とストリームデータ情報は、ＤＶＤ＿ＲＴＲディレクトリ（またはＤＶＤ＿ＲＴＡＶ）１０２と言う名のサブディレクトリ１０１内に入っている。

ＤＶＤ＿ＲＴＲ（ＤＶＤ＿ＲＴＡＶ）ディレクトリ１０２内には、以下の内容のデータファイル１０３が格納される。

すなわち、管理情報（ナビゲーションデータ）のグループとして、ＲＴＲ．ＩＦＯ（またはＶＲ＿ＭＡＮＧＲ．ＩＦＯ）１０４と、ＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５と、ＳＲ＿ＰＲＩＶＴ．ＤＡＴ／ＳＲ＿ＰＲＩＶＴ．ＢＵＰ１０５ａとが格納される。

また、データ本体（コンテンツ情報）として、ＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６と、ＲＴＲ＿ＭＯＶ．ＶＲＯ（ＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７と、ＲＴＲ＿ＳＴＯ．ＶＲＯ（またはＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８と、ＲＴＲ＿ＳＴＡ．ＶＲＯ（またはＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９とが格納される。

上記データファイル１０３を含むサブディレクトリ１０１の上位階層にあるルートディレクトリ１００には、その他の情報を格納するサブディレクトリ１１０を設けることができる。

このサブディレクトリの内容としては、ビデオプログラムを収めたビデオタイトルセットＶＩＤＥＯ＿ＴＳ１１１、オーディオプログラムを収めたオーディオタイトルセットＡＵＤＩＯ＿ＴＳ１１２、コンピュータデータ保存用のサブディレクトリ１１３等がある。

有線または無線のデータ通信経路上をパケット構造の形で伝送されたデータに対して、パケット構造を保持したまま情報記憶媒体に記録したデータを、「ストリームデータ」と呼ぶ。

そのストリームデータそのものはＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６と言うファイル名でまとめて記録される。そのストリームデータに対する管理情報が記録されているファイルが、ＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯとそのバックアップファイルＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５である。

また、ＶＣＲ（ＶＴＲ）あるいは従来ＴＶなどで扱われるアナログ映像情報をＭＰＥＧ２規格に基づきデジタル圧縮して記録されたファイルが、ＲＴＲ＿ＭＯＶ．ＶＲＯ（またはＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７であり、アフターレコーディング音声あるいはバックグランド音声等を含む静止画像情報を集めたファイルがＲＴＲ＿ＳＴＯ．ＶＲＯ（またはＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８であり、そのアフレコ音声情報ファイルがＲＴＲ＿ＳＴＡ．ＶＲＯ（またはＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９である。

図３は、この発明の一実施の形態に係る情報媒体、たとえばＤＶＤーＲＡＭディスク等の録再可能光ディスク２０１上の記録データ構造を説明する図である。

図３（ａ）の情報記憶媒体２０１の内周方向２０２の端部と外周方向２０３の端部とで挟まれた領域には、図３（ｂ）に示すように、リードインエリア２０４と、ファイルシステム情報が記録されているボリューム＆ファイル構造情報２０６と、データエリア２０７と、リードアウトエリア２０５が存在する。リードインエリア２０４はエンボスおよび書替可能データゾーンで構成され、リードアウトエリア２０５は書替可能データゾーンで構成されている。データエリア２０７も書替可能データゾーンで構成されている。

データエリア２０７内は、図３（ｃ）に示すように、コンピュータデータとオーディオ＆ビデオデータとが混在記録可能となっている。この例では、コンピュータデータエリア２０８およびコンピュータデータエリア２０９の間に、オーディオ＆ビデオデータエリア２１０が、挟まれる形態となっている。

オーディオ＆ビデオデータエリア２１０内は、図３（ｄ）に示すように、リアルタイムビデオ記録エリア２２１およびストリーム記録エリア２２２の混在記録が可能となっている。（リアルタイムビデオ記録エリア２２１あるいはストリーム記録エリア２２２の一方だけを使用することも可能である。）
図３（ｅ）に示すように、リアルタイムビデオ記録エリア２２１には、図２に示された、ＲＴＲのナビゲーションデータＲＴＲ．ＩＦＯ（ＶＲ＿ＭＡＮＧＲ．ＩＦＯ）１０４と、ムービーリアルタイムビデオオブジェクトＲＴＲ＿ＭＯＶ．ＶＲＯ（ＶＲ＿ＭＯＶＩＥ．ＶＲＯ）１０７と、スチルピクチャリアルタイムビデオオブジェクトＲＴＲ＿ＳＴＯ．ＶＲＯ（ＶＲ＿ＳＴＩＬＬ．ＶＲＯ）１０８と、アフターレコーディング等のオーディオオブジェクトＲＴＲ＿ＳＴＡ．ＶＲＯ（ＶＲ＿ＡＵＤＩＯ．ＶＲＯ）１０９とが記録される。

同じく図３（ｅ）に示すように、ストリーム記録エリア２２２には、図２に示された、ストリーマのナビゲーションデータＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＢＵＰ）１０５と、トランスポートビットストリームデータＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＶＲＯ）１０６とが記録される。

なお、図３（ｄ）（ｅ）では図示しないが、ストリーム記録エリア２２２には、図２に示したアプリケーション固有のナビゲーションデータＳＲ＿ＰＲＩＶＴ，ＤＡＴ／ＳＲ＿ＰＲＩＶＴ．ＢＵＰ１０５ａを記録することもできる。

このＳＲ＿ＰＲＩＶＴ，ＤＡＴ１０５ａは、ストリーマに接続（供給）された個々のアプリケーションに固有のナビゲーションデータであり、ストリーマにより認識される必要のないデータである。

ストリームデータに関する管理情報であるＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、図３（ｆ）〜（ｉ）に示すようなデータ構造を有している。

すなわち、図３（ｆ）に示すように、ＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、ビデオマネージャ（ＶＭＧＩまたはＳＴＲ＿ＶＭＧＩ）２３１と、ストリームファイル情報テーブル（ＳＦＩＴ）２３２と、オリジナルＰＧＣ情報（ＯＲＧ＿ＰＧＣＩ）２３３と、ユーザ定義ＰＧＣ情報テーブル（ＵＤ＿ＰＧＣＩＴ）２３４と、テキストデータマネージャ（ＴＸＴＤＴ＿ＭＧ）２３５と、製造者情報テーブル（ＭＮＦＩＴ）またはアプリケーション固有のナビゲーションデータＳＲ＿ＰＲＩＶＴ．ＤＡＴ１０５ａを管理するアプリケーションプライベートデータマネージャ（ＡＰＤＴ＿ＭＧ）２３６とで構成されている。

図３（ｆ）のストリームファイル情報テーブル（ＳＦＩＴ）２３２は、図３（ｇ）に示すように、ストリームファイル情報テーブル情報（ＳＦＩＴＩ）２４１と、１以上のストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、＃Ｂ・２４３、………と、オリジナルＰＧＣ情報一般情報２７１と、１以上のオリジナルセル情報＃１・２７２、＃２・２７３………とを含むことができるようになっている。

図３（ｇ）の各ストリームオブジェクト情報（たとえばＳＯＢＩ＃Ａ・２４２）は、図３（ｈ）に示すように、ストリームオブジェクト一般情報（ＳＯＢＩ＿ＧＩ）２５１、タイムマップ情報２５２、その他を含むことができる。

また、図３（ｇ）の各オリジナルセル情報（たとえば＃１・２７２；後述するが図２８で示されるＳＣＩに対応）は、図３（ｈ）に示すように、セルタイプ２８１（後述するが図２８で示されるＣ＿ＴＹに対応）と、セルＩＤ２８２と、該当セル開始時間（後述する図１５（ｌ）、図２８その他で示されるＳＣ＿Ｓ＿ＡＰＡＴに対応）２８３と、該当セル終了時間（後述する図１５（ｌ）、図２８その他で示されるＳＣ＿Ｅ＿ＡＰＡＴに対応）２８４とを含むことができる。

なお、図３（ｆ）の情報内容については、図２７を参照して後述する。

図３（ｇ）のＳＯＢＩ＃Ａに含まれる図３（ｈ）のタイムマップ情報２５２は、図３（ｉ）に示すように、ストリームブロック番号２６１、第１ストリームブロックサイズ２６２、第１ストリームブロック時間差２６３、第２ストリームブロックサイズ２６４、第２ストリームブロック時間差２６５、………を含むことができる。タイムマップ情報２５２を構成する各ストリームブロック時間差の内容については、図５を参照して後述する。

図４は、この発明におけるストリームオブジェクト（ＳＯＢ）、セル、プログラムチェーン（ＰＧＣ）等の間の関係を説明する図である。以下、図４の例示を用いてこの発明におけるＳＯＢとＰＧＣの関係について説明する。

ストリームデータ（ＳＴＲＥＡＭ．ＶＲＯまたはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６内に記録されたストリームデータは、１個以上のＥＣＣブロックの集まりとしてストリームブロックを構成し、このストリームブロック単位で記録、部分消去処理がなされる。このストリームデータは、記録する情報の内容毎（たとえばデジタル放送での番組毎）にストリームオブジェクトと言うまとまりを作る。

このＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６内に記録されたストリームオブジェクト（ＳＯＢ＃Ａ、ＳＯＢ＃Ｂ）毎の管理情報（オリジナルＰＧＣ情報２３３、ユーザ定義ＰＧＣ情報テーブル２３４等）は、ナビゲーションデータＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５（図４の最下部および図３（ｅ）（ｆ）参照）内に記録されている。

図４の各ストリームオブジェクト＃Ａ・２９８、＃Ｂ・２９９毎の管理情報（ＳＴＲＥＡＭ．ＩＦＯ１０５）は、図３（ｆ）（ｇ）に示すように、ストリームファイル情報テーブル（ＳＦＩＴ）２３２内のストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、＃Ｂ・２４３として記録されている。

ストリームオブジェクト情報（ＳＯＢＩ）＃Ａ・２４２、（ＳＯＢＩ）＃Ｂ・２４３それぞれの内部は、主にストリームブロック毎のデータサイズおよび時間情報等が記載されているタイムマップ情報２５２を含んでいる。

ストリームデータの再生時には、１個以上のセルの連続で構成されるプログラムチェーン（ＰＧＣ）の情報（後述する図２８のＰＧＣＩ＃ｉに対応）が利用される。このＰＧＣを構成するセルの設定順にしたがって、ストリームデータを再生することができる。

ＰＧＣには、ＳＴＲＥＡＭ．ＶＲＯ（ＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６に記録された全ストリームデータを連続して再生することのできるオリジナルＰＧＣ２９０（図３（ｆ）ではＯＲＧ＿ＰＧＣＩ・２３３）と、ユーザが再生したいと希望する場所と順番を任意に設定できるユーザ定義ＰＧＣ＃ａ・２９３、＃ｂ・２９６（図３（ｆ）ではＵＤ＿ＰＧＣＩＴ・２３４の中身に対応）の２種類が存在する。

オリジナルＰＧＣ２９０を構成するオリジナルセル＃１・２９１、＃２・２９２は、基本的にストリームオブジェクト＃Ａ・２９８、＃Ｂ・２９９と一対一に対応して存在する。

それに対して、ユーザ定義ＰＧＣを構成するユーザ定義セル＃１１・２９４、＃１２・２９５、＃３１・２９７は、１個のストリームオブジェクト＃Ａ・２９８または＃Ｂ・２９９の範囲内では任意の位置を設定することができる。

なお、各ストリームブロックのセクタサイズは種々に設定可能であるが、好ましい実施の形態としては、図４のストリームブロック＃１のように、２ＥＣＣブロック（３２セクタ）で一定サイズ（６４ｋバイト）のストリームオブジェクトユニット（ＳＯＢＵ）を、ストリームブロックとして採用するとよい。

このようにストリームブロックを一定サイズ（たとえば２ＥＣＣブロック＝３２セクタ＝６４ｋバイト）のＳＯＢＵに固定すれば、次の利点が得られる：
（０１）ＳＯＢＵ単位でストリームデータの消去あるいは書替を行っても、そのＳＯＢＵのＥＣＣブロックが、消去あるいは書替対象以外のＳＯＢＵのＥＣＣブロックに影響しない。そのため、消去あるいは書替に伴う（消去あるいは書替の対象でないＳＯＢＵに対する）ＥＣＣのデインターリーブ／インターリーブのやり直しが、生じない；
（０２）任意のＳＯＢＵ内部の記録情報に対するアクセス位置を、セクタ数（あるいはセクタ数に対応した他のパラメータ；たとえば後述する図９のストリームパックおよびその内部のアプリケーションパケット群の情報）で特定できる。たとえば、あるＳＯＢＵ＃ｋの中間位置にアクセスする場合は、ＳＯＢＵ＃ｋー１とＳＯＢＵ＃ｋとの境界から１６セクタ目（あるいは１６セクタ目に対応するアプリケーションパケットの位置）を指定すればよい。

図５は、タイムマップ情報におけるストリームブロックサイズ、ストリームブロック時間差の内容を説明する図である。以下、図５を用いてタイムマップ情報２５２内の各データの内容について説明する。

図５（ｆ）（ｇ）（ｈ）に例示するように、ストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は２つのストリームブロック＃１、＃２で構成されている。

図５（ｆ）（ｈ）の例では、ＳＯＢ＃Ａ・２９８を構成するストリームブロック＃１のデータサイズは２ＥＣＣブロック（＃α、＃β）で構成され、３２セクタ分（図５（ｅ）（ｉ））のサイズを持っている。すなわち、タイムマップ情報２５２（図５（ａ）（ｋ））内の第１ストリームブロックサイズ２６２（図５（ｊ））は、３２セクタ（６４ｋバイト）となる。

ＳＯＢ＃Ａ・２９８（図５（ｇ））の先頭にあるストリームブロック＃１（図５（ｆ））はその先頭にセクタＮｏ．０（図５（ｅ））を持ち、セクタＮｏ．０に含まれるデータエリア２１（図５（ｄ））の先頭にはタイムスタンプａが記録されている。

また、ＳＯＢ＃Ａ・２９８（図５（ｇ））の後続ストリームブロック＃２（図５（ｆ））はその先頭にセクタＮｏ．３２（図５（ｅ））を持ち、セクタＮｏ．３２に含まれるデータエリア３１１（図５（ｄ））の先頭にはタイムスタンプｐが記録されている。

図５（ｃ）に示すように、ストリームブロック＃１の最初のストリームデータのタイムスタンプ値はタイムスタンプａであり、次のストリームブロック＃２の最初のストリームデータのタイムスタンプ値はタイムスタンプｐとなっている。

図５（ｂ）（図３（ｉ）のストリームブロック時間差２６３に対応）の第１ストリームブロック時間差２６３の値は、上記タイムスタンプｐとタイムスタンプａとの差分値（［タイムスタンプｐ］−［タイムスタンプａ］）で与えられる。

なお、図５（ａ）のタイムマップ情報２５２は、図２９を参照して後述するストリームオブジェクト情報ＳＯＢＩ内のアクセスデータユニットＡＵＤも含むものとして、取り扱うことができる。このＡＵＤに含まれる情報（アクセスユニット開始マップＡＵＳＭ等）により、アクセスしたい情報を含むＳＯＢＵを特定できる。

図６は、オリジナルセルおよびユーザ定義セルにおけるセルの範囲指定方法を説明する図である。

それぞれのセルの範囲指定は、開始時刻と終了時刻の時間指定により行なうことができる。

具体的には、図１５以降を参照して後述する部分消去の実行前（ストリームデータの録画直後）のオリジナルセルにおける該当セルの開始時間２８３および該当セルの終了時間２８４（図６（ｂ））の時間として、該当するストリームオブジェクト＃Ａ・２９８（図６（ｆ））内の最初のタイムスタンプａの値および最後のタイムスタンプｚ（図６（ｃ））の値が使用される。

それに対して、ユーザ定義セル＃１２・２９５（図６（ｋ））での時間範囲指定は、任意時刻を指定できる。たとえば、図６（ｉ）（ｊ）に示すように指定されたトランスポートパケットｄ、ｎに対応したタイムスタンプｄ、ｎの値を、該当セルの開始時間３３１と該当セルの終了時間３３２の値として設定することができる。

図６（ｆ）は、ストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は２つのストリームブロック＃１および＃２で構成されている場合を例示している。

図６（ｅ）（ｇ）の例では、ストリームブロック＃１は３２セクタ（セクタＮｏ．０〜Ｎｏ．３１）で構成され、ストリームブロック＃２は４８セクタ（セクタＮｏ．３２〜Ｎｏ．７９）で構成されている。

ストリームブロック＃１の先頭セクタＮｏ．０は、図６（ｅ）（ｄ）に示すように、パックヘッダ１、ＰＥＳヘッダ６、ストリームブロックヘッダ１１、データエリア２１等で構成されている。

また、ストリームブロック＃２の後方セクタＮｏ．７８は、図６（ｅ）（ｄ）に示すように、パックヘッダ３、ＰＥＳヘッダ８、セクタデータヘッダ１３、データエリア２４等で構成されている。

さらに、図６（ｇ）のセクタＮｏ．１には図６（ｈ）に示すようにパックヘッダ２、セクタデータヘッダ１２、データエリア２２その他が記録され、図６（ｇ）のセクタＮｏ．３３には図６（ｈ）に示すようにセクタデータヘッダ３２１、データエリア３１２その他が記録されている。

図６（ｄ）（ｈ）のデータエリア２１には、図６（ｃ）（ｉ）に示すように、タイムスタンプａとトランスポートパケットａとのペアないしタイムスタンプｄとトランスポートパケットｄとのペアが記録されている。

また、図６（ｄ）のデータエリア２４の領域には、複数のタイムスタンプおよびトランスポートパケットのペアと、最後のタイムスタンプｚ＋トランスポートパケットｚのペアの後に続くエンドコード３２と、パディングエリア３７（図１（ｊ）のパディングエリア３７に対応）が記録されている。

また、図６（ｈ）のデータエリア２２には、図６（ｉ）に示すように、データエリア２１のトランスポートパケットｄの後続内容を含むトランスポートパケットｄが含まれている。つまり、この例では、トランスポートパケットｄの内容が、データエリア２１とデータエリア２２とで分断されて記録されている。

図６（ｉ）のトランスポートパケットｄの前半部分（データエリア２１側）は、後述する図８（ｆ）の末尾側部分パケットに対応し、図６（ｉ）のトランスポートパケットｄの後半部分（データエリア２２側）は、後述する図８（ｇ）の先頭側部分パケットに対応している。

さらに、図６（ｈ）のデータエリア３１２には、図６（ｉ）に示すように、タイムスタンプｎとトランスポートパケットｎとのペアおよびその他の同様なペアが記録されている。

ここで、ユーザ等が再生開始時間を指定した箇所に該当するセルの開始時間３３１（図６（ｊ））は、データエリア２１および２２に分断された２つのトランスポートパケットｄ全体に対するタイムスタンプｄ（図６（ｉ））により指定される。

トランスポートパケットをアプリケーションパケットと読み替え、アプリケーションパケット到着時間をＡＰＡＴとした場合に、上記セル開始時間３３１は、セル開始ＡＰＡＴとして表現できる。

また、ユーザ等が再生終了時間を指定した箇所に該当するセルの終了時間３３２（図６（ｊ））は、データエリア３１２のトランスポートパケットｎに対するタイムスタンプｎ（図６（ｉ））により指定される。このセル終了時間３３２は、セル終了ＡＰＡＴとして表現できる。

以上のセル開始時間（セル開始ＡＰＡＴ）３３１およびセル終了時間（セル終了ＡＰＡＴ）３３２は、図６（ｋ）に示すように、ユーザ定義セル情報＃１２・２９５内部に記録される。

このユーザ定義セル情報＃１２・２９５は、図３（ｆ）または図４下段に示すユーザ定義ＰＧＣ情報テーブル２３４内に記録することができる。

以上はユーザ定義セル情報（ユーザ定義ＰＧＣの情報）に関するセル開始／終了時間情報についてであるが、オリジナルセル情報（オリジナルセルの情報）に関するセル開始／終了時間情報については、次のような例示ができる。

すなわち、図６（ｃ）の先頭側タイムスタンプａにより図６（ｂ）の該当セルの開始時間２８３を示すことができ、末尾側タイムスタンプｚにより該当セルの終了時間２８４を示すことができる。

図６（ｂ）の該当セルの開始時間２８３は、セル開始ＡＰＡＴ（後述するストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）または消去開始ＡＰＡＴ（ＥＲＡ＿Ｓ＿ＡＰＡＴ）も含む）に対応させることができる。

また、図６（ｂ）の該当セルの終了時間２８４は、セル終了ＡＰＡＴ（後述するストリームセル終了ＡＰＡＴ（ＳＣ＿Ｅ＿ＡＰＡＴ）または消去終了ＡＰＡＴ（ＥＲＡ＿Ｅ＿ＡＰＡＴ）も含む）に対応させることができる。

以上のセル開始時間（セル開始ＡＰＡＴ）２８３およびセル終了時間（セル終了ＡＰＡＴ）２８４は、図６（ａ）に示すように、オリジナルセル情報＃１・２７２内部に記録される。

このオリジナルセル情報＃１・２７２は、図３（ｆ）または図４下段に示すオリジナルＰＧＣ情報２３３内に記録することができる。

なお、上記セル開始ＡＰＡＴおよびセル終了ＡＰＡＴについては、後述する図１８〜図２１、図３０〜図３３の説明において具体例を示す。

図７は、この発明の一実施の形態に係るストリームデータ記録再生装置（ストリーマ）の構成を説明する図である。

以下、図７を用いて、この発明の好ましい実施形態としてのストリームデータ記録再生装置（ストリーマ）の内部構造の説明を行う。

この実施の形態におけるストリームデータ記録再生装置は、エンコード部４０１、デコード部４０２、ＳＴＢ部４０３、主ＭＰＵ部４０４、Ｖ（ビデオ）ミキシング部４０５、フレームメモリ部４０６、キー入力部４０７、表示部４０８、ＤＶＤ−ＲＡＭディスク２０１に対して情報記録あるいは情報再生を行なうディスクドライブ部４０９、データプロセサ（Ｄ−ＰＲＯ）部４１０、一時記憶部４１１、Ａ／Ｖ（オーディオ・ビデオ）入力部４１２、ＴＶチューナ部４１３を備えている。

このストリームデータ記録再生装置はさらに、ＳＴＢ部４０３に接続された衛星アンテナ４２１、システムタイムカウンタ（ＳＴＣ）部４２４、Ｖミキシング部４０５からパーソナルコンピュータ（ＰＣ）４３５へデジタルビデオ信号を送るインターフェイス（Ｉ／Ｆ）４３４、アナログＴＶ４３７用Ｄ／Ａ変換部４３６を備えている。

ここで、Ｖミキシング部４０５は、デコード部４０２のＶ−ＰＲＯ部４３８からのデジタルビデオ信号と、ＳＴＢ部４０３からのデジタルビデオ信号４２３とを、適宜ミキシングする機能を持っている。このミキシング機能により、たとえばＴＶ４３７の表示画面の左側にＳＴＢ部４０３からの放送画像を表示し、ＴＶ４３７の表示画面の右側にディスク２０１から再生した画像を表示することができる。

あるいは、ＳＴＢ部４０３からの放送画像とディスク２０１からの再生画像とを、ＰＣ４３５のモニタ画面において、オーバーラッピングウインドウに重ねて表示することもできる。

以上の構成において、エンコード部４０１内は、ビデオおよびオーディオ用のＡ／Ｄ変換部４１４、Ａ／Ｄ変換部４１４からのデジタルビデオ信号またはＳＴＢ分０３からのデジタルビデオ信号４２３を選択してビデオエンコード部４１６に送るセレクタ４１５、セレクタ４１５からのビデオ信号をエンコードするビデオエンコード部４１６、Ａ／Ｄ変換部４１４からのオーディオ信号をエンコードするオーディオエンコード部４１７、ＴＶチューナ部４１３からのクローズドキャプション（ｃｃ）信号あるいは文字放送信号等を副映像（ＳＰ）にエンコードするＳＰエンコード部４１８、フォーマッタ部４１９、バッファメモリ部４２０より構成される。

一方、デコード部４０２内は、メモリ４２６を内蔵する分離部４２５、縮小画像（サムネールピクチャ）生成部４３９を内蔵するビデオデコード部４２８、ＳＰデコード部４２９、オーディオデコード部４３０、ＴＳパケット転送部４２７、ビデオプロセサ（Ｖ−ＰＲＯ）部４３８、オーディオ用Ｄ／Ａ変換部４３２より構成されている。

デコード部４３０でデコードされたデジタルオーディオ信号は、インターフェイス（Ｉ／Ｆ）４３１を介して外部出力可能となっている。また、このデジタルオーディオ信号をＤ／Ａ変換部４３２でアナログ化したアナログオーディオ信号により、外部のオーディオアンプ（図示せず）を介してスピーカ４３３が駆動されるようになっている。

なお、Ｄ／Ａ変換部４３２は、オーディオデコード部４３０からのデジタルオーディオ信号のみならず、ＳＴＢ部４０３からのデジタルオーディオ信号４２２のＤ／Ａ変換もできるように構成される。

なお、ディスク２０１からの再生データをＳＴＢ部４０３に転送する場合は、ＴＳパケット転送部４２７において分離部４２５からの再生データ（ビットストリーム）をトランスポートパケット（ＴＳパケット）に変更し、ＳＴＣ４２４からの時間情報に転送時間を合わせて、ＴＳパケットをＳＴＢ部４０３に送ればよい。

図７の主ＭＰＵ部４０４は、作業用メモリとしてのワークＲＡＭ部４０４ａと、ストリームデータ作成制御部４０４ｂという名の制御プログラムと、ストリームデータ再生制御部４０４ｃという名の制御プログラムと、ストリームデータの部分消去／仮消去制御部４０４ｄという名の制御プログラム等を含んでいる。

ここで、ファイルの管理領域（図２あるいは図３（ｅ）のナビゲーションＲＴＲ．ＩＦＯ１０４、ＳＴＲＥＡＭ．ＩＦＯ１０５）などを読み書きするために、主ＭＰＵ部４０４は、Ｄ−ＰＲＯ部４１０に、専用のマイクロコンピュータバスを介して接続されている。

ストリームデータ記録再生装置における録画時の制御は、上記制御プログラム（シーケンシャルな制御プログラム）を用い主ＭＰＵ部４０４により行われる。

まず、図７の装置における録画時のビデオ信号の流れについて説明をする。録画時には、主ＭＰＵ部４０４内のストリームデータ作成制御部４０４ｂという名のシーケンシャルプログラムにしたがって、一連の処理が行われる。

すなわち、ＩＥＥＥ１３９４規格に準拠した伝送経路を経由してＳＴＢ部４０３からエンコード部４０１へ送出されたストリームデータは、まずフォーマッタ部４１９に転送される。

フォーマッタ部４１９のＩＥＥＥ１３９４受信側は、ＳＴＣ４２４のタイムカウント値に基づいて、ストリームデータ転送開始からの時間を読み込む。読み込んだ時間情報は、管理情報として主ＭＰＵ部４０４へ送られ、ワークＲＡＭ部４０４ａに保存される。

主ＭＰＵ部４０４は、上記時間情報に基づいて、ストリームデータをストリームブロック毎（リアルタイムＲＴＲレコーダではＶＯＢＵ毎、ストリーマではＳＯＢＵ毎）に切り分ける区切れ情報を作成するとともに、この区切れ情報に対応したセルの切り分け情報およびプログラムの切り分け情報、さらにはＰＧＣの切り分け情報を作成し、主ＭＰＵ部４０４内のワークＲＡＭ部４０４ａに逐次記録する。

フォーマッタ部４１９は、主ＭＰＵ部４０４のストリームデータ作成制御部４０４ｂからの指示にしたがって、図１（ａ）の形でＳＴＢ部４０３から送られてきたストリームデータを図１（ｃ）（ｉ）の形（後述する図８（ｈ）のストリームパックの列）に変換し、変換されたストリームパック列をＤ−ＰＲＯ部４１０へ入力する。入力されたストリームパックはセクタと同じ２０４８バイトの一定サイズを持っている。Ｄ−ＰＲＯ部４１０は、入力されたストリームパックを１６セクタ毎にまとめてＥＣＣブロックにして、ディスクドライブ部４０９へ送る。

ここで、ディスクドライブ部４０９においてＲＡＭディスク（情報記憶媒体）２０１への記録準備ができていない場合には、Ｄ−ＰＲＯ部４１０は、記録データを一時記憶部４１１に転送して一時保存し、ディスクドライブ部４０９においてデータ記録準備ができるまで待つ。

ディスクドライブ部４０９において記録準備ができた段階で、Ｄ−ＰＲＯ部４１０は一時記憶部４１１に保存されたデータをディスクドライブ部４０９に転送する。これにより、ディスク２０１への記録が開始される。一時記憶部４１１に保存されたデータの記録が済むと、その続きのデータはフォーマッタ部４１９からＤ−ＰＲＯ部４１０へシームレスに転送されるようになっている。

ここで、一時記憶部４１１は、高速アクセス可能で数分以上の記録データを保持できるようにするため、大容量メモリを想定している。

次に、再生時のデータ処理について説明する。ストリームデータ記録再生装置における再生時の制御は、ストリームデータ再生制御部４０４ｃという名のシーケンシャルプログラムにしたがい、主ＭＰＵ部４０４によって、一連の処理が行われる。

まず、ディスクドライブ部４０９により、ＲＡＭディスク（情報記憶媒体）２０１からストリームデータが再生される。再生されたストリームデータは、Ｄ−ＰＲＯ部４０９を経由してデコーダ部４０２に転送される。

デコーダ部４０２内部では、再生されたストリームデータ中のトランスポートパケットを分離部４２５が受け取る。

分離部４２５は、図１０を参照して後述するストリームＩＤ６０３およびサブストリームＩＤに従って、ビデオパケットデータ（ＭＰＥＧビデオデータ）はビデオデコード部４２８へ転送し、オーディオパケットデータはオーディオデコード部４３０へ転送し、副映像パケットデータはＳＰデコード部４２９へ転送する。

ビデオデコード部４２８でデコードされたビデオデータは、Ｖミキシング部４０５およびＤ／Ａ変換部４３６を介してアナログＴＶ信号に変換され、ＴＶ４３７に転送されて画像表示される。

同時に、オーディオデコード部４３０でデコードされたデジタル音声データは、Ｉ／Ｆ４３１を介して外部オーディオ機器（図示せず）のデジタル入力に転送される。あるいは、デコードされたデジタル音声データは、Ｄ／Ａ変換部４３２によりアナログ音声信号に変換され、図示しないオーディオアンプを介して、スピーカ４３３に送られる。

以上この発明の実施の形態におけるストリームデータ記録再生装置（ストリーマ）内での信号の流れを説明した。

以上説明したように、ＤＶＤ−ＲＡＭディスク（情報記憶媒体）２０１へ記録するストリームデータは、フォーマッタ部４１９内で図１（ｃ）（ｉ）の構造に変換される。この変換プロセスを中心にしたストリームデータ録画手順は、図１３のフローチャートを参照して後述する。

また、ストリームデータの再生手順については、図１４のフローチャートを参照して後述する。

図８は、デジタル放送のコンテンツとＩＥＥＥ１３９４における映像データ転送形態とストリーマにおけるストリームパックとの対応関係を説明する図である。

デジタル放送では、ＭＰＥＧ２規格に従って圧縮された映像情報がトランスポートパケットに乗って転送されてくる。このトランスポートパケット内は、図８（ｂ）に示すように、トランスポートパケットヘッダ５１１と、記録情報のデータ本体が記録されているペイロード５１２とで構成されている。

トランスポートパケットヘッダ５１１は、図８（ａ）に示すように、ペイロードユニット開始インジケータ５０１、パケットＩＤ（ＰＩＤ）５０２、ランダムアクセスインジケータ５０３、プログラムクロックリファレンス５０４等で構成されている。

ＭＰＥＧ圧縮された映像情報は、Ｉピクチャ情報、Ｂピクチャ情報、およびＰピクチャ情報を含んでいる。Ｉピクチャ情報（後述する図９の５７１）が記録されている最初のトランスポートパケットには、図８（ａ）のランダムアクセスインジケータ５０３に”１”のフラグが立つ。また、各Ｂ、Ｐピクチャ情報（後述する図９の５７３、５７４、５７２）の最初のトランスポートパケットには、図８（ａ）のペイロードユニット開始インジケータ５０１に”１”のフラグが立つ。

これらのランダムアクセスインジケータ５０３およびペイロードユニット開始インジケータ５０１の情報を利用して、Ｉ−ピクチャマッピングテーブル（後述する図１１の６４１）およびＢ、Ｐ−ピクチャ開始位置マッピングテーブル（後述する図１１の６４２）の情報が作成される。

たとえば、図８（ａ）に示したペイロードユニット開始インジケータ５０１に”１”のフラグが立ったトランスポートパケットに対して、Ｂ、Ｐ−ピクチャ開始位置マッピングテーブル（図１１の６４２）内の該当個所のビットが”１”になる。

デジタル放送では、ビデオ情報とオーディオ情報がそれぞれ異なるトランスポートパケットに入って転送される。そして、それぞれの情報の区別が、図８（ａ）のパケットＩＤ（ＰＩＤ）５０２で識別される。このＰＩＤ５０２の情報を用いて、ビデオパケットマッピングテーブル（後述する図１１の６４３）とオーディオパケットマッピングテーブル（後述する図１１の６４４）が作成される。

図８（ｃ）に示すように、デジタル放送では、１個のトランスポンダに複数の番組（この例では番組１〜番組３）がパケット化された形で時分割されて転送されてくる。

たとえば、図８（ｂ）のトランスポートパケットヘッダ５１１およびペイロード（記録情報）５１２の情報は、図８（ｃ）に示される番組２のトランスポートパケットｂ・５２２、ｅ・５２５により転送される。

いま、たとえばデジタル放送受信者（図７のＳＴＢのユーザ等）の操作により、図８（ｃ）に示される番組２が、図３または図７の情報記憶媒体２０１に記録される場合を想定してみる。この場合、図７のＳＴＢ部４０３において、図８（ｃ）の番組２のトランスポートパケットｂ、ｅのみが抽出される。

そのとき、ＳＴＢ部４０３では、図８（ｄ）に示すように、各トランスポートパケットｂ・５２２、ｅ・５２５を受信した時刻情報がタイムスタンプ５３１、５３２の形で付加される。

その後、ＩＥＥＥ１３９４の転送方式によって図７のＳＴＢ部４０３からフォーマッタ部４１９へデータを転送する場合には、図８（ｅ）に示すように、上記タイムスタンプ５３１とトランスポートパケット５２２との組が細かく分割されて転送されることになる。

図７のフォーマッタ部４１９では、ＳＴＢ部４０３からＩＥＥＥ１３９４で転送されてきたストリームデータが、図８（ｄ）の形（図１（ａ）の形あるいは図８（ｆ）（ｇ）（ｈ）の形に相当）に一旦戻される。そして、図１（ａ）あるいは図８（ｆ）（ｇ）（ｈ）の形式のビットストリーム（図８（ｈ）のストリームパック列）が、情報記憶媒体２０１に記録される。

具体的には、この発明の一実施の形態においては、各セクタ（図１（ｄ）（ｈ））の先頭には、システムクロック情報などが記録されたパックヘッダ１、２、３、４とＰＥＳヘッダ６、７、８、９が配置される（図１（ｃ）（ｉ）、図６（ｄ）参照）。その直後には、セクタデータヘッダ１２、１３（図１（ｃ）（ｉ）、図６（ｄ））が記録されるが、各ストリームブロック先頭のセクタのみ、セクタデータヘッダではなく、ストリームブロックヘッダ１１が記録される（図１（ｃ）、図６（ｄ））。

データエリア２１、２２、２３、２４（図１（ｃ）（ｉ））には複数のタイムスタンプおよびトランスポートパケット（図１（ａ））が逐次詰め込まれるが、１個のトランスポートパケット（図１（ｂ）ではパケットｄ；図８（ｅ）ではパケットｂ）が複数のセクタ（図１（ｄ）ではＮｏ．０とＮｏ．１；図８（ｆ）（ｇ）では部分パケット）に跨って記録される。

この特徴を生かしたデータ構造を用いることにより、セクタサイズ（例えば２０４８バイト）よりも大きなサイズを持つパケットを記録することができる。この点について、さらに説明する。

デジタル放送では図８（ｃ）に示すようにトランスポートストリームと呼ばれるマルチプログラム対応の多重・分離方式を採用しており、１個のトランスポートパケットｂ・５２２のサイズが１８８バイト（または１８３バイト）の場合が多い。

前述したように１セクタサイズは２０４８バイトであり、各種ヘッダサイズを差し引いても１個のデータエリア２１、２２、２３、２４（図１（ｃ）（ｉ））内にはデジタル放送用のトランスポートパケットが１０個前後記録できる。

それに対して、ＩＳＤＮなどのデジタル通信網では１パケットサイズが４０９６バイトある大きなロングパケットが転送される場合がある。

デジタル放送などのように１個のデータエリア２１、２２、２３、２４（図１（ｃ）（ｉ））内に複数個のトランスポートパケットを記録するだけでなく、ロングパケットのようにパケットサイズの大きなパケットの場合でも記録できるよう、前記特徴を生かしたデータ構造（１パケットのデータを複数パケットに跨って記録できる特徴）を用いることにより、１個のパケットを複数のデータエリア２１、２２、２３、２４に連続して跨るように記録する。

そうすれば、デジタル放送用のトランスポートパケットやデジタル通信用のロングパケットなどは、パケットサイズに依ることなく、全てのパケットをストリームブロック内に端数なく記録することができる。

また、通常のパケットにはタイムスタンプが付いているが、図８（ｇ）に示すように、部分パケットではタイムスタンプを省略することができる。

このようにすると、２つの隣接ストリームパック（図８（ｈ））の境界で分断された部分パケット（パケット１つあたり１８８バイトとすれば部分パケットのサイズは１〜１８７バイト；平均して１００バイト弱）を情報記録に有効利用できる。のみならず、部分パケットに対して省略されたタイムスタンプの分（タイムスタンプ１つあたり例えば４バイト）、媒体２０１に対する記憶容量を増やすことができる。

なお、図８（ｇ）の先頭部分パケットの直後にくるタイムスタンプの位置は、後述する図１２（ｂ）のファーストアクセスポイント６２５あるいは図１２（ｃ）のＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴにより、特定することができる。

ところで、ストリームブロック内に余り部分が生じた場合には、パディングデータ（データが未記録である領域と認識できる情報）が記録される。たとえば、図１（ｂ）のようにストリームブロック＃１内の最後のトランスポートパケットｆの後ろにはエンドコード３１が配置され、残りの部分はパディングエリア３６としている。図１（ｊ）のパディングエリア３７、３８も同様なパディングデータ用のエリアである。

なお、パディングエリアの具体的な内部データ構造については、図２６を参照して後述する。

図９は、ＭＰＥＧにおける映像情報圧縮方法とトランスポートパケットとの関係、およびＭＰＥＧにおけるトランスポートパケットとストリーマにおけるアプリケーションパケットとの関係を説明する図である。

前述したように、デジタル放送では、映像情報はＭＰＥＧ２の規格に従って圧縮された情報が転送されてくる。

図９に示すように、Ｉピクチャ５５１の圧縮情報５６１はＩピクチャ情報５７１としてトランスポートパケットａ、ｂ、…に記録される。Ｂピクチャ５５３の差分情報５６３、５６４はＢピクチャ情報５７３としてトランスポートパケットｄ、…に記録される。また、Ｂピクチャ５５４の差分情報５６５、５６６はＢピクチャ情報５７３、５７４としてトランスポートパケットｄ、ｆ、…に記録される。そして、Ｐピクチャ５５２の差分情報５６２がＰピクチャ情報５７２としてトランスポートパケットｈ、…に記録される。

このように各Ｉ、Ｂ、Ｐピクチャ情報は異なるトランスポートパケットに記録されている。

このようなトランスポートパケットがストリーマに記録されるときは、トランスポートパケットの内容はアプリケーションタイムスタンプ（ＡＴＳ）というタイムスタンプ付きのパケット（アプリケーションパケット）に移し替えられる。

そして、ＡＴＳ付きアプリケーションパケットの一群（通常１０パケット前後）がストリームＰＥＳパケット内のアプリケーションパケットエリアに格納される。

このストリームＰＥＳパケットにパックヘッダを付したものが図８（ｈ）で例示した１つのストリームパックになる。

ストリームＰＥＳパケットは、ＰＥＳヘッダと、サブストリームＩＤと、アプリケーションヘッダと、アプリケーションヘッダエクステンション（オプション）と、スタッフィングバイト（オプション）と、上記ＡＴＳ付きアプリケーションパケット群を格納するアプリケーションパケットエリアとで、構成される。

なお、ＰＥＳヘッダ（ストリームＰＥＳパケットヘッダ）の内容については、図１０を参照して後述する。また、アプリケーションヘッダ（ストリームブロックヘッダ１１またはセクタデータヘッダ１２に対応）については、図１１および図１２を参照して、後述する。

図１０は、図１、図８、図９等に示されたＰＥＳヘッダの内部構造を説明する図である。

図１０（ａ）のＰＥＳヘッダ６０１は、図１０（ｂ）に示すように、パケット開始コードプリフィックス６０２、ストリームＩＤ６０３、再生タイムスタンプ６０４等を含んでいる。このＰＥＳヘッダ６０１は、図１（ｃ）（ｉ）（ｊ）のＰＥＳヘッダ６〜９、図８（ｈ）のＰＥＳヘッダ６〜７、図９のＰＥＳヘッダ６等に対応している。

また、図１０（ｄ）のストリームＰＥＳヘッダは、パケット開始コードプリフィックス、ストリームＩＤ（プライベートストリーム２）、ＰＥＳパケット長、サブストリームＩＤ等を含んでいる。このストリームＰＥＳヘッダは、図９のストリームＰＥＳヘッダと同じもので、図１０（ａ）のＰＥＳヘッダ６０１に対応する内容を持つ。

図１（ｊ）のＰＥＳヘッダ９が図１０（ａ）に示すＰＥＳヘッダ６０１の内部構造を持つときは、ＭＰＥＧの規格では、このＰＥＳヘッダのストリームＩＤ６０３（図１０（ｂ））が”１０１１１１１０”のときに、このＰＥＳヘッダを持つパケットを、パディングパケット４０（図１（ｉ））にすると定義されている。

一方、ストリームＩＤ６０３（図１０（ｃ）のサブストリームＩＤ）が”００００００１０”のときは、そのＰＥＳパケットの付いたパケットは、ストリーム記録データを含むことになる。

図１（ｅ）のストリームブロック＃１では、最後のトランスポートパケットｆ（図１（ａ））が最後のセクタＮｏ．３１（図１（ｄ））内に存在している。しかし、ストリームブロック＃２（図１（ｅ）（ｇ））では、ユーザ等により途中で録画が終了されたために、最後のトランスポートパケットｚ（図１（ｊ））がセクタＮｏ．７８（図１（ｈ））に配置され、セクタＮｏ．７９（図１（ｈ））内はストリームデータが記録されいない空き領域となっている。このため、セクタＮｏ．７９は、パディングパケット４０（図１（ｉ））として記録されている。

図１１は、図１（ｃ）に示されたストリームブロックヘッダの内部構造を説明する図である。

ストリームブロックヘッダ１１は、図１１（ａ）に示すように、図９下段のサブストリームＩＤ、アプリケーションヘッダ、スタッフィングバイト等に対応した内容を持つ。

ストリームブロックヘッダ１１は、図１１（ｂ）に示すように、トランスポートパケット情報６１１、ストリームブロック情報６１２、セクタデータヘッダ情報６１３等を含んでいる。

図１１（ｂ）のトランスポートパケット情報６１１は図１１（ｃ）のトランスポートパケット情報６１１とおなじものを指す。

ストリームブロック全体に関する情報が記録されている図１１（ｂ）のストリームブロック情報６１２は、図１１（ｃ）の記録時間６２２（情報記憶媒体２０１に記録した年月日と時刻情報）、トランスポートパケット属性６２３（トランスポートパケットに関する属性情報）、ストリームブロックサイズ６２４（該当するストリームブロックのデータサイズ（たとえばＥＣＣブロック数で記載できる））、ストリームブロック時間差６２５等に対応する。

ここで、図１（ｂ）を例にとれば、該当ストリームブロック内の時間範囲情報は、［ストリームブロック時間差］＝［ストリームブロック＃２内の最初にくるタイムスタンプ値］−［タイムスタンプａの値］として計算される。この［ストリームブロック時間差］が、ストリームブロック時間差６２５となる。

また、図１１（ｂ）のセクタデータヘッダ情報６１３は、図１１（ｃ）のファーストアクセスポイント６２６およびトランスポートパケット接続フラグ６２７に対応する。このセクタデータヘッダ情報６１３は、後述する図１２のセクタデータヘッダ１２と同様な情報を含んでいる。

図１１（ｃ）のトランスポートパケット情報６１１は、図１１（ｄ）に示すように、トランスポートパケットの数（アプリケーションパケットの数）６３１、トランスポートパケットマッピングテーブル６３２等を含んでいる（図１１（ｄのアプリケーションパケットの数は、後述する図１２（ｃ）のＡＰ＿Ｎｓに対応する）。

図１１（ｄ）のトランスポートパケット（アプリケーションパケット）の数６３１は、図１１（ｅ）に示すように、Ｉピクチャマッピングテーブル６４１、Ｂ，Ｐピクチャマッピングテーブル６４２等を含むことができる。

また、図１１（ｄ）のトランスポートパケットマッピングテーブル６３２は、ビデオパケットマッピングテーブル６４３、オーディオパケットマッピングテーブル６４４、プログラム固有情報マッピングテーブル６４５等を含むことができる。

トランスポートパケットマッピングテーブル６３２内の各マッピングテーブル（図１１（ｅ））は、ビットマップ形式で構成されている。

たとえば、１個のストリームブロック内にｎ個のトランスポートパケット（アプリケーションパケット）が記録されている場合には、図１１（ｄ）のトランスポートパケット数（アプリケーションパケット数）６３１の値は”ｎ”となる。

さらに、各マッピングテーブル６４３〜６４５は”ｎビットデータ”からなり、ストリームブロック内に前から並んでいる個々のトランスポートパケット（アプリケーションパケット）に対してそれぞれ１ビットずつが割り当てられている。

図１２は、図１に示されたセクタデータヘッダの内部構造を説明する図である。

図１（ｃ）（ｉ）のセクタデータヘッダ１２、１３は、データエリア２１、２２、２３、２４内のデータ配列情報を示し、図１２に示すように、ファーストアクセスポイント６５１およびトランスポートパケット接続フラグ６５２を含む内部構造を持っている。

ところで、図１２（ｄ）（および図９下段）に示すように、１セクタと同じく２０４８バイトのサイズを持つ１つのストリームパックは、パックヘッダおよびストリームＰＥＳヘッダで構成されている。そして、このストリームＰＥＳパケット内に、図１２（ａ）のセクタデータヘッダ１２あるいは図１１（ａ）のストリームブロックヘッダ１１の一部に対応した、アプリケーションパケットヘッダが含まれている。

このアプリケーションパケットヘッダは、図１２（ｃ）に示すように、以下のものを含んでいる：
＊アプリケーションパケットヘッダ形式のバージョン記載；
＊該当ストリームパック内で開始するアプリケーションパケット（トランスポートパケット）の数ＡＰ＿Ｎｓ；
＊該当ストリームパック内で開始する先頭アプリケーションパケットのタイムスタンプの位置をそのストリームパックの最初のバイトからの相対値で記述した、先頭アプリケーションパケット・タイムスタンプ位置ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ；
＊ヘッダエクステンションおよび／またはスタッフィングバイトが存在するか否かを示すエクステンションヘッダ情報ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ；
＊該当ストリームを生成したサービスの識別子ＳＥＲＶＩＣＥ＿ＩＤ。

上記図１２（ｄ）のアプリケーションパケットに含まれるＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴは、図１２（ａ）のセクタデータヘッダ１２に含まれるファーストアクセスポイント６５１に対応する。

図１（ｂ）に示すように、トランスポートパケットｄは２個のセクタに跨って記録されている。ここで、セクタ内の最後のタイムスタンプ、またはトランスポートパケットが次のセクタへ跨った場合には、トランスポートパケット接続フラグ６５２が”１”に設定される。また図１（ｂ）の例では、次のセクタへ跨ったトランスポートパケットｄの次にくるタイムスタンプ先頭位置のデータエリア２２内のアドレスが、ファーストアクセスポイント６５１内に記録（ビット単位の表現）されている。

図１（ｄ）に示すセクタＮｏ．１（またはその対応ストリームパック）のファーストアクセスポイント値を、セクタＮｏ．１のデータエリア２２（図１（ｃ））のサイズよりも大きな値に設定することができる。そうすることにより、セクタＮｏ．１内に記録されたパケットの次にくるパケットに対応するタイムスタンプの位置が、次以降のセクタに存在することが示される。

この発明の一実施の形態では、ファーストアクセスポイント６５１の値としてデータエリア２１、２２、２３、２４のサイズよりも大きな値を指定可能にすることで、セクタサイズ（あるいはストリームパックサイズ＝２０４８バイト）よりも大きなサイズを有するパケットに対しても、タイムスタンプ先頭位置を指定することができる。

たとえば、図１（ｄ）のデータ構造において、１個のパケットがセクタＮｏ．０からセクタＮｏ．２まで跨って記録されているとする。さらに、そのパケットに対するタイムスタンプはセクタＮｏ．０のデータエリア２１内の最初の位置に記録されるとともに、その次のパケットに対するタイムスタンプがセクタＮｏ．２のデータエリア内のＴビット目に配置されている場合を考える。

この場合、セクタＮｏ．０のファーストアクセスポイントの値は”０”、セクタＮｏ．１のファーストアクセスポイントの値は”セクタＮｏ．１のデータエリア２２サイズ＋Ｔ”、セクタＮｏ．２のファーストアクセスポイントの値は”Ｔ”となる。

図１３は、この発明の一実施の形態に係るストリームデータのエンコード手順および録画手順を説明するフローチャートである。

まず、図７のエンコード部４０１において、パケット化されたデータが、タイムスタンプ（図１（ｂ）、図８（ｆ）等のタイムスタンプ、あるいは図９のＡＴＳ）と一緒に、バッファメモリ部４２０に一時記憶される（ステップＳ０１）。

別の言い方をすると、ステップＳ０１において、図７の装置（ストリーマ）により、連続するストリームブロック（ＳＯＢＵ）のセクタに格納される再生データのエリアが、タイムスタンプ（ＡＴＳ）付きトランスポートパケット（アプリケーションパケット）により埋められる。ここで付加されるタイムスタンプには、図７のＳＴＣ部４２４から得たローカルクロック値が用いられる。

次に、バッファメモリ部４２０に一時記憶されたタイムスタンプとパケットデータとのビット列が、ストリームブロック（あるいはＳＯＢＵ）毎に切り分けられる（ステップＳ０２）。

この実施の形態では、図１（ｂ）に示すように同一のトランスポートパケット（ｄ）が異なるストリームブロック（＃１、＃２）に跨って記録されることを禁止できる。この場合、図７のバッファメモリ部４２０に一時記録されたタイムスタンプとパケットデータをストリームブロック毎に切り分けるＳ０２のステップでは、タイムスタンプとトランスポートパケットの組が完全に１個のストリームブロック内に収まるように切り分けを行なう必要がある。

切り分けられた各ストリームブロック（ＳＯＢＵ）内のデータ末尾には、エンドコード（図１（ｊ））と、必要に応じてパディングエリアが追記される（ステップＳ０３）。

こうしてバッファメモリ部４２０内でストリームブロック（ＳＯＢＵ）毎に切り分けられたタイムスタンプとパケットデータのビット列の内部が、さらに、セクタ毎（あるいは２０４８バイトのストリームパック毎）に分割される（ステップＳ０４）。

この実施の形態では、同一のトランスポートパケット（ｄ）を、異なるセクタ（図１（ｄ）のＮｏ．０とＮｏ．１）に跨って記録させることもできる。この場合は、セクタ毎に分割するＳ０４のステップでは、各データエリア２１、２２、２３、２４に割り当てられた所定サイズに従って、無造作に分割が行われる。

その後、バッファメモリ部４２０内で各セクタ（ストリームパック）の先頭位置に、図１（ｃ）、図９その他に示すような、パックヘッダおよびＰＥＳヘッダの情報が挿入される（ステップＳ０５）。

なお、ステップＳ０５において挿入されるパックヘッダおよびＰＥＳヘッダの情報は、トランスポートパケット（アプリケーションパケット）を生成したデバイス（アプリケーションデバイス）が任意に出力するシーケンスヘッダの情報でもある。

次に、ストリームブロック（ＳＯＢＵ）内の最後にあるパディングエリアサイズがセクタ記録サイズ（ストリームパックサイズ２０４８バイト）より大きいかどうかチェックされる（ステップＳ０６）。

たとえば図１（ｆ）のストリームオブジェクト＃Ａ・２９８の最後のストリームブロック＃２では、ユーザ等により任意の位置での録画終了処理が行われる可能性がある。そのため、ストリームブロック＃２内の記録可能領域のサイズに対して記録すべきストリームデータのサイズの方が大幅に小さい場合が生じる。

この場合には、ステップＳ０６の判定結果として、トータルのパディングエリアサイズがセクタ記録サイズより大きい状況になる。（図１（ｆ）〜（ｊ）の例では、ストリームデータはセクタＮｏ．７８の途中まで記録され、セクタＮｏ．７９内は実質的に記録されない状態になっている。この場合、図１（ｊ）のパディングエリア３７、３８のトータルサイズがセクタＮｏ．７９内サイズより大きくなる。）
この場合（ステップＳ０６イエス）には、図１０（ｂ）のストリームＩＤ６０３の値が前述したように”１０１１１１１０”に設定され、セクタＮｏ．７９（全てがパディングエリアで埋められるセクタ）がパディングパケット４０に変換される（ステップＳ０７）。

ステップＳ０６においてパディングエリアサイズがセクタ記録サイズ以下と判定されれば（ステップＳ０６ノー）、あるいはステップＳ０７においてパディングパケットへの変換処理が済めば、バッファメモリ部４２０に記録されているストリームブロック（ＳＯＢＵ）内のパケットデータ列が解析される。この解析結果から、トランスポートパケット情報の関連情報（図１１（ｂ）〜（ｅ）、図１２（ｂ）〜（ｄ））が作成される。そして、ストリームブロック内で最初のセクタのＰＥＳヘッダの直後に図１１（ａ）のストリームブロック１１が挿入される（ステップＳ０８）。

あるいは、ストリームブロック（ＳＯＢＵ）内で最初のセクタ（最初のストリームパック）のＰＥＳヘッダの後に図９、図１１その他で示したアプリケーションヘッダが挿入される（ステップＳ０８）。

さらに、ストリームブロック内の先頭セクタとパディングパケットを除いた全てのセクタに対して、そのＰＥＳヘッダの直後に図１２（ａ）のセクタデータヘッダ１２が挿入される（ステップＳ０９）。

あるいは、ストリームブロック（ＳＯＢＵ）内の先頭セクタ（最初のストリームパック）とパディングエリアを除いた全てのセクタ（ストリームパック）に対して、そのＰＥＳヘッダの後に図９、図１２その他で示したアプリケーションヘッダが挿入される（ステップＳ０９）。

上記ステップＳ０８およびステップＳ０９でのヘッダ挿入は、バッファメモリ部４２０内で行われる。

以上の工程（ステップＳ０１〜ステップＳ０９）によりエンコードされたビットストリーム（バッファメモリ部４２０上で作成したデータ構造を持つストリーム情報）が、図７の装置により、ＤＶＤ−ＲＡＭディスク等の情報記憶媒体（図３または図７の２０１）に記録される。

なお、ステップＳ０８では、ストリームブロック（ＳＯＢＵ）内の全トランスポートパケットヘッダ５１１（図８（ｂ））を検索し、図８（ａ）のペイロードユニット開始インジケータ５０１、ＰＩＤ５０２、ランダムアクセスインジケータ５０３の値を利用して、図１１（ｅ）のトランスポートパケットマッピングテーブル６３２内の各データを作成することができる。

また、次のストリームブロック（ＳＯＢＵ）内の最初にくるタイムスタンプの値と現行のストリームブロック（ＳＯＢＵ）内の最初にくるタイムスタンプの値との差を計算して、図８（ｃ）のストリームブロック時間差６２５の値を求めることもできる。

図１４は、この発明の一実施の形態に係るストリームデータのデコード手順および再生手順を説明するフローチャートである。

以下、図１（ｃ）（ｉ）あるいは図８（ｈ）の構造で情報記憶媒体（ＤＶＤ−ＲＡＭディスク）２０１上に記録されたストリーム情報から、図７の分離部４２５内部でトランスポートパケットを抽出するプロセスを中心に、ストリームデータの再生手順を説明する。

ユーザ等からは再生すべき範囲が時間情報で指定される。この場合の再生時には、指定された時間情報に対応する、再生すべきストリームブロック（またはＳＯＢＵ）を探す処理が必要となる。

まず、図１３で例示した方法で情報記録がなされたＲＡＭディスク（図３あるいは図７の情報記憶媒体）２０１が、図７のディスクドライブ部４０９に装填される。その後、例えば装置ユーザが、希望する再生範囲を、「再生開始時間」と「再生終了時間」で指定したとする。この指定がなされたあと図７のキー入力部４０７（あるいは図示しないリモートコントローラ）のプレイキー（再生ボタン）が押されたとする。

すると、図７の主ＭＰＵ部４０４は、制御プログラム「ストリームデータ再生制御部４０４ｃ」に従い図３（ｆ）のストリームファイル情報テーブル（ＳＦＩＴ）２３２にアクセスして、図３（ｈ）のタイムマップ情報２５２の内容を読み取る。読み取られた情報内容から、主ＭＰＵ部４０４は、指定された「再生開始時間」の位置（再生開始時刻位置）が含まれるストリームブロック（ＳＯＢＵ）の番号とそのストリームブロック（ＳＯＢＵ）の先頭位置アドレスを割り出す（ステップＳ１１）。

ここで、図３（ｉ）の実施の形態では、タイムマップ情報２５２内には各ストリームブロック毎の差分時間情報しか記録されていない。この場合、主ＭＰＵ部４０４内のストリームデータ再生制御部（再生制御プログラム）では、各ストリームオブジェクト情報（ＳＯＢＩ）２４２、２４３（図３（ｇ））毎にタイムマップ情報２５２内の各ストリームブロックの時間差（図５（ｂ）参照）２６３、２６５の値を逐次加算し、ユーザが指定した時刻に到達するか比較する。その比較結果を元に、ユーザが指定した時刻はどのストリームオブジェクト（ＳＯＢ）内の何番目のストリームブロック（ＳＯＢＵ）の中に含まれるタイムスタンプ値と一致するかを割り出す。これにより、アクセスしようとするストリームブロック（ＳＯＢＵ）の先頭位置アドレスを割り出すことができる。

あるいは、後述する図２９に示すようなデータ構造を持つストリームオブジェクト情報（ＳＯＢＩ）が用いられるときは、このＳＯＢＩに含まれる情報（タイムマップ情報ＭＡＰＬ、ＭＡＰＬのエントリ数ＭＡＰＬ＿ＥＮＴ＿Ｎｓ等）を用いて、アクセスしようとするストリームブロック（ＳＯＢＵ）の先頭位置アドレスを割り出すことができる。

ステップＳ１１で割り出された先頭位置アドレスは、ディスクドライブ部４０９に通知される。こうしてアクセス先のアドレス情報を得たデスクドライブ部４０９は、このアドレス情報に対応する所定のストリームブロック（ＳＯＢＵ）の先頭位置にアクセスする。そして、このストリームブロック（ＳＯＢＵ）の先頭を起点として、ディスクドライブ部４０９は、装填されたディスク２０１から、ストリームブロック（ＳＯＢＵ）単位で、記録済みのストリームデータを読み込む（ステップＳ１２）。

ステップＳ１２の処理により、パケット到着時間（またはアプリケーションパケット到着時間ＡＰＡＴ）を伴う個別のトランスポートパケット（またはアプリケーションパケット）が検索され、検索されたパケットの回収（その記録内容の再生）が可能になる。

こうして読み込まれたストリームデータは、Ｄ−ＰＲＯ部４１０を介して、ディスクドライブ部４０９からデコード部４０２内の分離部４２５へ転送される。転送されたストリームデータは、分離部４２５の内部メモリ４２６に一時的に保管される（ステップＳ１３）。

分離部４２５の内部メモリ４２６に保管されたストリームデータが一定量を越えると、そこからパディングエリア（図１（ｊ）の３７、３８等）のパケットが自動的に検索される。パディングパケットであるかどうかは、図１０（ｃ）のサブストリームＩＤをチェックすることで分かる。

分離部４２５の内部メモリ４２６上でパディングパケットが見つかると、パディングパケットが含まれるパディングエリアが、分離部４２５の内部メモリ４２６上で消去される（ステップＳ１４）。

こうしてパディングパケットが除かれたストリームデータから、分離部４２５の内部メモリ４２６上で、各種ヘッダ（パックヘッダ、ＰＥＳヘッダ、ストリームブロックヘッダ、セクタデータヘッダ、その他）が消去される。こうして、分離部４２５の内部メモリ４２６上のストリームデータが、タイムスタンプ（ＡＴＳ）およびパケットデータだけの列情報（ビットストリーム）に変換される（ステップＳ１５）。

次に、変換されたビットストリームデータを、通信回線（ＩＥＥＥ１３９４シリアルバス等）を用いて外部装置（図７のＳＴＢ部４０３等）に転送する必要があるかどうか、チェックされる（ステップＳ１６）。

ステップＳ１６のチェックは、例えば次のような方法で行なうことができる。すなわち、図７の装置ユーザが装置の初期設定において「再生したビットストリームを外部装置に転送しますか？…イエス／ノー」という設定画面（図示せず）でイエスを選択している場合に、そのイエスのフラグが立っているかどうかで判定できる。

情報記憶媒体２０１から再生したストリームデータを図７のＳＴＢ部４０３に送る必要がある場合には（ステップＳ１６イエス）、各トランスポートストリームに付いているタイムスタンプのタイミングに同期させて、再生したストリームデータをＳＴＢ部４０３へ逐次転送する（ステップＳ１７）。このＳＴＢ部４０３への転送手段としてＩＥＥＥ１３９４が利用される場合は、再生したストリームデータは図８（ｅ）に示すようなデータ構造に変換されて転送される。

上記ＩＥＥＥ１３９４転送が不要なら（ステップＳ１６ノー）、あるいは上記ＩＥＥＥ１３９４転送が実施されたあと、分離部４２５の内部メモリ４２６上で、ステップＳ１５で変換されたビットストリームからタイムスタンプ（ＡＴＳ）が消去され、パケットデータのみのデータ列に変換される（ステップＳ１８）。

こうして変換されたデータ列中のパケットデータには、記録時の内容に応じて、ビデオパケット、副映像（ＳＰ）パケット、オーディオパケット等が含まれている。これらのパケットを含むデータパックはパックヘッダを持ち、そのパックヘッダ内のストリームＩＤ（図示せず）により、データの種類（ビデオか副映像かオーディオか等）が区別できるようになっている。

このストリームＩＤの内容を参照することで、ビデオパケットは図７のビデオデコード部４２８に転送され、副映像パケットはＳＰデコード部４２９に転送され、オーディオパケットはオーディオデコード部４３０に転送される。こうして、各デコード部（４２８〜４３０）において、該当する記録内容が、それぞれ個別にデコードされる（ステップＳ１９）。

以上のようにして記録された各種情報（ビデオ、副映像、オーディオ等）のデコードが個別に開始されると、図７のＳＴＣ（システムタイムカウンタ）４２４にセットされた再生タイムスタンプに基づいて、ビデオ情報、副映像情報、および／またはオーディオ情報等が、所定のタイミングで再生される（モニタＴＶに画面表示されあるいはスピーカから音声再生される）（ステップＳ２０）。

ここで、ステップＳ２０の再生タイムスタンプは、図１、図１０その他に例示されたＰＥＳヘッダに格納されたもの（図１０（ｂ）では６０４）を用いることができる。

あるいは、ステップＳ２０の再生タイムスタンプとして、図８（ｈ）その他に例示されたパックヘッダ内のＳＣＲ（システムクロックリファレンス）ベース（図示せず）を用いることも可能である。

図１５および図１６は、この発明の一実施の形態に係るストリームデータの部分消去方法を説明する図である。

図１５は部分消去後の見かけ上の前半残存領域７４３について詳細を示しており、図１６は部分消去後の見かけ上の後半残存領域７４４について詳細を示している。

また、図２２および図２４は、この発明の他実施の形態に係るストリームデータの部分消去方法を説明するもので、各ストリームブロックが一定サイズ（３２セクタ６４ｋバイト）のストリームオブジェクトユニットＳＯＢＵで構成される場合を示している。

図２２は部分消去後の見かけ上の前半残存領域７４３について詳細を示しており、図２４は部分消去後の見かけ上の後半残存領域７４４について詳細を示している。

さらに、図２３および図２５は、この発明の他実施の形態に係るストリームデータの仮消去方法を説明するもので、各ストリームブロックが一定サイズ（３２セクタ６４ｋバイト）のストリームオブジェクトユニットＳＯＢＵで構成される場合を示している。

図２３は、図２２（ｇ）（ｈ）の消去領域（７４１、７４２）が仮消去領域（７４７、７４８）である場合のデータ構造を例示している。また、図２５は、図２４（ｇ）（ｈ）の消去領域（７４１、７４２）が仮消去領域（７４７、７４８）である場合のデータ構造を例示している。

以下では、図３または図７の情報記憶媒体２０１上に既に記録してあるストリームデータの一部を部分的に消去する場合（あるいは仮消去する場合）について説明を行う。

ストリームデータの記録再生装置（ストリーマ）では、部分消去処理（仮消去処理）は、図７の主ＭＰＵ部４０４の制御プログラム「ストリームデータ部分消去／仮消去制御部」４０４ｄにより実行される。

この発明の一実施の形態では、データ消去（あるいは仮消去）は常にストリームブロック単位（あるいはＳＯＢＵ単位）で行なわれる。さらに、オリジナルセル範囲を指定した時間情報（セル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ／ＥＲＡ＿Ｓ＿ＡＰＡＴ）；セル終了ＡＰＡＴ（ＳＣ＿Ｅ＿ＡＰＡＴ／ＥＲＡ＿Ｅ＿ＡＰＡＴ））を利用して、細かい部分消去範囲（あるいは仮消去範囲）をユーザが指定できるようにしている。ここにもこの発明の特徴がある。

この発明の一実施の形態では、図１（ｂ）（ｊ）に示すようにストリームブロック（あるいはＳＯＢＵ）の最後をパディングエリア３６、３８とし、同一のトランスポートパケットが異なるストリームブロック（ＳＯＢＵ）を跨って記録できないような構造になっている。

このようにすると、常にトランスポートパケットの切れ目とストリームブロック（ＳＯＢＵ）の切れ目が一致するため、ストリームブロック（ＳＯＢＵ）単位での部分消去が容易に実行可能になる。

図１７は、この発明の一実施の形態に係るストリームデータの部分消去の手順（記録情報の一部を完全消去する手順）を説明するフローチャートである。このフローチャートを利用して仮消去の手順（記録情報の一部があたかも消去されたかの如く管理情報を変更するが、情報本体そのものは消去されずに残す手順）についても説明する。

図１７では図示を省いているが、図７の主ＭＰＵ部４０４により「ストリームデータ部分消去／仮消去制御部」４０４ｄという制御プログラムがスタートすると、まず、図７のディスクドライブ部４０９に装填された情報記憶媒体２０１から、ストリームデータに関する管理情報が記載されているＳＴＲＥＡＭ．ＩＦＯ１０５（図２、図３（ｅ）等参照）の情報が読み込まれる。読み込まれた管理情報は、主ＭＰＵ部４０４内のワークＲＡＭ部４０４ａに一時保管される。

図７のディスクドライブ部４０９に装填された情報記憶媒体２０１には、消去前（あるいは仮消去前）の状態として、ストリームオブジェクト（ＳＯＢ）＃Ｂ・２９９が記録されている。このＳＯＢ＃Ｂは、ストリームブロック（またはＳＯＢＵ）＃３〜＃５から構成され、その中に記録されている全トランスポートパケット（あるいはアプリケーションパケット）が再生可能な状態になっている場合を考える。

この場合の消去処理では、ＳＯＢ＃Ｂ・２９９に対応するオリジナルセル情報＃２・２７３（図３（ｇ）；このオリジナルセル情報は、ワークＲＡＭ部４０４ａに一時保管された管理情報ＳＴＲＥＡＭ．ＩＦＯ１０５の一部に含まれる）の指定範囲として、以下の指定がなされる：
（１ａ）該当セルの開始時間７５１（図１５（ｌ）または図２２（ｌ））の時刻をトランスポートパケットｒ（図１５（ｋ）または図２２（ｋ））に対応したタイムスタンプｒの時刻（トランスポートパケットｒの到着時刻を表す）に指定し、
（２ａ）該当セルの終了時間７５６（図１６（ｌ）または図２４（ｌ））の時刻をトランスポートパケットｗ（図１６（ｋ）または図２４（ｋ））に対応したタイムスタンプｗの時刻（トランスポートパケットｗの到着時刻を表す）に指定する。

一方、仮消去処理の場合には、ＳＯＢ＃Ｂ・２９９に対応するオリジナルセル情報＃２・２７３（図３（ｇ）；ＳＴＲＥＡＭ．ＩＦＯ１０５の一部）の指定範囲として、以下の指定がなされる：
（１ｂ）該当セルの開始時間７５２（図２３（ｌ））の時刻をトランスポートパケットｒｒ（図２３（ｋ））に対応したタイムスタンプｒｒの時刻（トランスポートパケットｒｒの到着時刻を表す）に指定し、
（２ｂ）該当セルの終了時間７５８（図２５（ｌ））の時刻をトランスポートパケットｊ（図２５（ｋ））に対応したタイムスタンプｊの時刻（トランスポートパケットｊの到着時刻を表す）に指定する。

以下の部分消去手順（または仮消去手順）の説明において、部分消去前後（仮消去前後）で図２のＳＴＲＥＡＭ．ＩＦＯ１０５およびＳＴＲＥＡＭ．ＶＲＯ１０６の内容がどのように変化するかを、図１５、図１６および図２２〜図２５を適宜参照しながら説明する。

初めは、部分消去の場合を説明し、その後に仮消去の場合を説明する。

［部分消去の場合］
いま、図１５（ｆ）、図１６（ｆ）、図２２（ｆ）あるいは図２４（ｆ）に示すストリームオブジェクト（ＳＯＢ）＃Ｂ・２９９の中央部を部分消去するものとし、図１５（ｇ）、図１６（ｇ）、図２２（ｇ）あるいは図２４（ｇ）に示すように見かけ上の消去領域７４１が設定される場合を想定して、図１７のフローチャートの説明に入る。

まず、ユーザ等により、部分消去範囲が、時間情報（部分消去の開始時刻と部分消去の終了時刻）等により指定される（ステップＳ２１）。

この指定により、図１５（ｇ）等に示した「見かけ上の消去領域７４１」の範囲が特定される。この消去範囲指定操作後は、図１５（ｆ）等のＳＯＢ＃Ｂ・２９９内に、見かけ上の前半残存領域７４３および見かけ上の後半残存領域７４４が残る（図１５（ｇ）、図１６（ｇ）、図２２（ｇ）あるいは図２４（ｇ）参照）。

上記ステップＳ２１により「見かけ上の消去領域７４１」の範囲が特定されると、図７のストリームデータ部分消去／仮消去制御部４０４ｄを実行する主ＭＰＵ部４０４により、タイムマップ情報（図３（ｈ）の２５２あるいは後述する図２９のＳＯＢＩ）が読み出される。読み出されたタイムマップ情報の内容に基づいて、ユーザが指定した部分消去の範囲に完全に含まれるストリームブロック（１または複数のＳＯＢＵあるいは１以上のＳＯＢＵを含んだＳＯＢ；代表的にはストリームブロック＝ＳＯＢＵ）が、検索される。そして、検索されたストリームブロック（換言すると該当ＳＯＢに含まれるトランスポートパケットあるいはアプリケーションパケットのうち消去終了位置より前の全てのパケット）が消去される（ステップＳ２２）。

こうして消去されたストリームブロック（あるいはＳＯＢＵ）は、図２の管理情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５により、ファイルＳＴＲＥＡＭ．ＶＲＯ１０６にないものとして扱われる（つまり、ファイルシステムは、消去されたストリームブロック／ＳＯＢＵを無視する）。

なお、消去されたストリームブロック／ＳＯＢＵの情報が記録されていた情報記憶媒体２０１上の物理アドレス位置には、図２のＤＶＤ＿ＲＴＲディレクトリ１０２以外のディレクトリ（管理情報１０５が関与できないところ、たとえば図２のコンピュータデータ保存用サブディレクトリ１１３）の下に存在する別ファイルを記録することもできる。この場合も、サブディレクトリ１１３の下に存在する別ファイルを記録した情報記憶媒体２０１上の物理的な記録場所は、ファイルシステム上は、ファイルＳＴＲＥＡＭ．ＶＲＯ１０６から外される。

次に、図１５（ｇ）等に示す部分消去範囲に対する前半残存領域７４３と後半残存領域７４４とでストリームオブジェクト（ＳＯＢ）を分割する。続いて、この分割により生じた新たなストリームオブジェクト（図１５（ｈ）等のＳＯＢ＃Ｂ＊７４５、ＳＯＢ＃Ｃ・７４６）に対するＳＯＢ情報（ＳＯＢＩ）が作成され、作成されたＳＯＢＩが図７の主ＭＰＵ部４０４内のワークＲＡＭ部４０４ａに一時記憶される。その際、分割前のＳＯＢ＃Ｂに対して記録されていたタイムマップ情報２５２内の該当個所を転記する形で、新たなＳＯＢ＃Ｂ＊７４５およびＳＯＢ＃Ｃ・７４６に対するタイムマップ情報も作成される（ステップＳ２３）。

上記タイムマップ情報の内容変更（転記・作成）の具体的な対象は、たとえば図３（ｉ）に示す各種情報（２６１〜２６５）、あるいは図２９に示すストリームオブジェクト情報（ＳＯＢＩ）の内容（ＭＡＰＬ、ＭＡＰＬ＿ＥＮＴ＿Ｎｓ等）である。

なお、部分消去によりタイムマップ情報（ＭＡＰＬ）が短くなったときは、短くなったタイムマップ情報（ＭＡＰＬ）を含むＳＯＢＩの後にくる「１以上の後続ＳＯＢＩおよび全ての後続情報テーブル」は、変更された（短くなった）ＳＯＢＩにアラインされる。こうすることで、隣接ＳＯＢＩ間にギャップが生じることを防止できる。

その場合、図２９のＳＯＢＩ＿ＳＲＰ＃、ＳＦＩＴの一部、図３（ｆ）または図２７のＳＴＲ＿ＶＭＧＩ（ＳＦＩＴ以降の情報テーブルの開始アドレス全て）等も、上記ＳＯＢＩアラインに対応して修正される。

上記ステップＳ２３の処理内容について、さらに説明する。

図７の主ＭＰＵ部４０４は、ストリームデータ部分消去／仮消去制御部４０４ｄに関するシーケンシャルプログラムに従って処理を実行し、ディスクドライブ部４０９に対してデータ読み出しの指示を出す。これにより、情報記憶媒体２０１上でストリームデータが記録されているファイルＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６（図２）内から、ストリームブロック＃５のデータ（図１６または図２４の（ｉ）〜（ｌ））が再生され、そのデータが主ＭＰＵ部４０４内のワークＲＡＭ部４０４ａに一時保管される。

次に、主ＭＰＵ部４０４は、その一時保管したデータ内を検索し、図１６（ｇ）または図２４（ｇ）で示す見かけ上の後半残存エリア７４４の開始時刻に最も近い値を持つタイムスタンプの値を、検索する。

その検索結果が図１６（ｉ）〜（ｋ）で示すようにセクタＮｏ．１１２内にあるタイムスタンプｋ（あるいは図２４（ｉ）〜（ｋ）で示すようにセクタＮｏ．１４４内にあるタイムスタンプｋ）の値と一致しあるいは近似していた場合には、このタイムスタンプｋの値が、オリジナルセル情報＃３・７６２の該当セルの開始時間７５２の値に設定される。

こうして設定された該当セルの開始時間（ＳＣ＿Ｓ＿ＡＴＡＰ等）７５２が、主ＭＰＵ部４０４内のワークＲＡＭ部４０４ａに一時保管された、ストリームデータの管理情報ＳＴＲＥＡＭ．ＩＦＯ（またはＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５内に追記される。

同様に、オリジナルセル情報＃３・７６２の該当セルの終了時間（ＳＣ＿Ｅ＿ＡＴＡＰ等）７５６の値としては、部分消去前のオリジナルセル情報＃２・２７３の該当セルの終了時間７５６の値が転記される。

ところで、図１５、図１６、図２２あるいは図２４の実施の形態では、ストリームブロック＃４が部分消去の範囲内に完全に含まれるので、その部分が実質上の消去領域７４２として実質的に消去される。

このとき、ストリームブロック＃３とストリームブロック＃５は実質的には消去されずにそのまま残存するが、図１５、図１６、図２２あるいは図２４の（ｅ）〜（ｇ）に示すように、ストリームブロック＃３の末尾側およびストリームブロック＃５の先頭側の一部は、ユーザ等により指定された見かけ上の消去領域７４１に含まれている。

この発明の一実施の形態では、部分消去の範囲７４１に対する前半残存エリア７４３および後半残存エリア７４４において、ストリームオブジェクト（ＳＯＢ＃Ｂ）が分割・分離されるとともに、それに対応してオリジナルセル範囲も分割・分離される。

この分割・分離に対応して、図１５、図１６、図２２あるいは図２４の実施の形態では、ストリームブロック＃５の位置を新たにストリームオブジェクト＃Ｃ・７４６と定義される。

一方、消去前のストリームオブジェクト（ＳＯＢ）＃Ｂ・２９９に対応するストリームオブジェクト情報（ＳＯＢＩ）＃Ｂ・２４３（図３（ｇ））内に記載されたタイムマップ情報（その内容は図３（ｉ）と同様であり、図２９のＳＯＢＩの内容に対応する）の中で、ストリームブロック＃５に対するストリームブロックサイズおよびストリームブロック時間差の値は、部分消去前後で変化しない。

そこで、図１７のステップＳ２３に示すように、このタイムマップ情報がそっくりそのまま、ＳＴＲＥＡＭ．ＩＦＯ１０５内に新規に作成されるストリームオブジェクト＃Ｃ・７４６（図１６（ｈ）、図２４（ｈ）等）に対応するストリームオブジェクト情報＃Ｃ内のタイムマップ情報情報として、転記される。

この新たに定義されたストリームオブジェクト＃Ｃ・７４６に対応した部分消去後のオリジナルセル情報＃３・７６２（図１６（ｍ）または図２４（ｍ））が指定する表示範囲は、ユーザが指定した見かけ上の後半残存エリア７４４の範囲と一致する。

ステップＳ２３の処理によりタイムマップ情報の作成が済むと、新たに定義されたＳＯＢ（ＳＯＢ＃＃Ｂ＊、ＳＯＢ＃Ｃ）に対するオリジナルセル情報が作成される（ステップＳ２４）。

このオリジナルセル情報の作成において、対応オリジナルセル＃３・７６２（図１６（ｍ）、図２４（ｍ））の指定範囲が設定される。

この設定は、ユーザ等により指定された部分消去終了時刻に該当セルの開始時刻を合わせることで、（あるいはユーザ等により指定された部分消去開始時刻に該当セルの終了時刻を合わせることで）行われる。

具体的には、後述する図３１下段の図解を例に採れば、完全消去後（部分消去が完全に実行された後）の新たなＳＯＢのセル＃ｋ＋１（完全消去前はセル＃ｋ＋２）の開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴｋ＋１）を、ユーザ等により指定された消去終了時刻（完全消去前のセル＃ｋ＋１のＳＣ＿Ｅ＿ＡＰＡＴｋ＋１）に合わせることになる。

あるいは、完全消去後のＳＯＢのセル＃ｋ（完全消去前もセル＃ｋ）の終了時刻（ＳＣ＿Ｅ＿ＡＰＡＴｋ）を、ユーザ等により指定された消去開始時刻（完全消去前のセル＃ｋ＋１のＳＣ＿Ｓ＿ＡＰＡＴｋ＋１）に合わせてもよい。

なお、図３１下段の図解例において、完全消去の前後で変更のないセル＃ｋについては、その開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴｋ）および終了時刻（ＳＣ＿Ｅ＿ＡＰＡＴｋ）に変更はない。

上記ステップＳ２４の処理により、前述した「ＳＯＢＩアライン」がなされる（これにより隣接ＳＯＢＩ間にギャップが生じることを防止できる）。

次に、元の（消去前の）ストリームオブジェクト情報（ＳＯＢＩ）＃Ｂ・２４３（図３（ｇ））に関する情報（タイムマップ情報等）が書き替えられる（ステップＳ２５）。

具体的には、実質上の消去領域７４２（図１６（ｈ）、図２４（ｈ））の部分および新たに定義されたＳＯＢ領域７４６（図１６（ｈ）、図２４（ｈ））の部分を元のタイムマップ情報から除去した内容に、タイムマップ情報が書き替えられる。

そうする理由は、部分消去後にはＳＯＢ＃Ｂ＊７４５（図１５（ｈ）、図２２（ｈ））を構成するストリームブロックは＃３のみとなったので、部分消去前のＳＯＢＩ＃Ｂ・２４３内のタイムマップ情報から、実質的に消去されたストリームブロック＃４の部分、および別のストリームオブジェクト（ＳＯＢ＃Ｃ）の所属になったストリームブロック＃５の情報を削除する必要があるからである。

この情報削除がステップＳ２５の情報書替処理である。この削除処理は、図７の主ＭＰＵ部４０４内のワークＲＡＭ部４０４ａに一時保管された管理情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５に対してなされる。

このステップＳ２５における情報（タイムマップ情報等）の書き替えにおいても、前述した「ＳＯＢＩアライン」がなされる（これにより隣接ＳＯＢＩ間にギャップが生じることを防止できる）。

次に消去前のオリジナルセル情報＃２・２７３に関する情報内容の変更処理が行なわれる。ここでは、ステップＳ２４におけるオリジナルセル情報＃３・７６２の作成と同様な処理が実行される。

まず、タイムマップ情報が書き替えられたＳＯＢに対応したオリジナルセルの時刻範囲が変更される（ステップＳ２６）。

この変更は、ユーザ等により指定された部分消去開始時刻に該当セルの終了時刻を合わせることで、（あるいはユーザ等により指定された部分消去終了時刻に該当セルの開始時刻を合わせることで）行われる。

具体的には、後述する図３１下段の図解を例に採れば、セル＃ｋ（完全消去前もセル＃ｋ）の終了時刻（ＳＣ＿Ｅ＿ＡＰＡＴｋ）を、ユーザ等により指定された消去開始時刻（完全消去前のセル＃ｋ＋１のＳＣ＿Ｓ＿ＡＰＡＴｋ＋１）に合わせることになる。

あるいは、完全消去後のセル＃ｋ＋１（完全消去前はセル＃ｋ＋２）の開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴｋ＋１）を、ユーザ等により指定された消去終了時刻（完全消去前のセル＃ｋ＋１のＳＣ＿Ｅ＿ＡＰＡＴｋ＋１）に合わせてもよい。

次に、図７の主ＭＰＵ部４０４は、ストリームデータ部分消去／仮消去制御部４０４ｄに関するシーケンシャルプログラムに従って処理を実行し、ディスクドライブ部４０９に対してデータ読み出しの指示を出す。これにより、情報記憶媒体２０１上でストリームデータが記録されているファイルＳＴＲＥＡＭ．ＶＲＯ（またはＳＲ＿ＴＲＡＮＳ．ＳＲＯ）１０６（図２）内から、ストリームブロック＃３のデータ（図１５または図２２の（ｉ）〜（ｌ））が再生され、そのデータが主ＭＰＵ部４０４内のワークＲＡＭ部４０４ａに一時保管される。

主ＭＰＵ部４０４は、その一時保管したデータ内を検索し、図１５（ｇ）または図２２（ｇ）で示される見かけ上の前半残存エリア７４３の終了時刻にもっとも近い値を持つタイムスタンプの値を、検索する。

その検索結果が図１５または図２２の（ｉ）〜（ｋ）で示すようにセクタＮｏ．９０内にあるタイムスタンプｖの値と一致しあるいは近似していた場合には、このタイムスタンプｖの値が、部分消去後のオリジナルセル情報＃２・７６１（図１５（ｍ）、図２２（ｍ））の該当セルの終了時間７５７（図１５（ｌ）、図２２（ｌ））の値として設定される。

こうして設定された値が、主ＭＰＵ部４０４内のワークＲＡＭ部４０４ａ内に一時保管された管理情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５に追記される。

なお、部分消去後のオリジナルセル情報＃２・７６１の該当セルの開始時間７５１の値（ＳＣ＿Ｓ＿ＡＰＡＴ）は、部分消去前のオリジナルセル情報＃２・２７３の該当セルの開始時間７５１の値（ＳＣ＿Ｓ＿ＡＰＡＴ）と同じなので、変更されずにそのままの値が管理情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５内に残される。

以上一連の処理が終了すると、図７のワークＲＡＭ部４０４ａ内で変更されたストリームデータの管理情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５の情報を元に、主ＭＰＵ部４０４からディスクドライブ部４０９へ指示が出される。

これにより、情報記憶媒体２０１上のＳＴＲＥＡＭ．ＩＦＯ／ＳＲ＿ＭＡＮＧＲ．ＩＦＯ１０５の情報が書き替えられる（ステップＳ２７）。

この情報書き替えの結果、削除されたストリームブロック（ＳＯＢＵ）は図２のファイルシステム（ＤＶＤ＿ＲＴＡＶのファイルシステム）から無視されるようになる。

最後に、Ｓ２８で情報記憶媒体２０１上に記録されたボリューム＆ファイル構造情報２０６（図３（ｂ））の情報が書き替えられて、ファイルシステム情報が更新される（ステップＳ２８）。

ストリームブロック毎のデータサイズと時間情報（時間差）が記録されているストリームオブジェクト情報（ＳＯＢＩ）による指定範囲に対して、この指定範囲に対応した再生範囲を示すオリジナルセル情報の指定範囲を、等しいかあるいは狭くすることができる（図１５、図１６、図２２あるいは図２４の（ｆ）〜（ｈ）参照）。このようにすれば、ユーザは、見かけ上、ストリームブロックよりも細かな任意の範囲で、記録済みＳＯＢ情報の部分消去が可能となる。

なお、各ストリームブロック毎のデータサイズを加算することで、特定のストリームブロックが記録されている位置（＝アドレス情報）を算出することができる。

上記のように部分消去処理を行った後に情報記憶媒体２０１から再生が行われると、図４に示すように１個のオリジナルＰＧＣ２９０ではオリジナルセル＃２とオリジナルセル＃３が連続して再生される。

つまり、部分消去処理が実行された情報記憶媒体２０１からユーザ等により再生が行われる場合には、オリジナルセル情報＃２・７６１（図１５（ｍ）等）内の該当セルの開始時間７５１から該当セルの終了時間７５７の時刻まで再生された直後に、オリジナルセル情報＃３・７６２（図１６（ｍ）等）内の該当セルの開始時間７５２の位置から、続けて（通常はシームレスに）再生が始まる。

［仮消去の場合］
ＤＶＤストリーマでは、２種類の消去が可能となっている。第１は上述したストリームの一部を完全に消去するものであり、第２は以下に述べるストリームの一部を仮に消去する（仮消去またはテンポラリ・イレーズ；これを適宜ＴＥと略記する）ものである。

仮消去に関しては：
（１１）ストリームの仮消去部分は完全に構成し直すことができる；
（１２）仮消去部分の開始位置および終了位置は、アプリケーションパケット到着時間（ＡＰＡＴ）の精度で、時間情報によりマークできる（ストリーマのユーザは、ＳＯＢ、ＳＯＢＵ、ＳＯＢＩ／ＭＡＰＬ等の内部情報を認識できないが、記録時間は認識できる。そこで、仮消去の範囲、すなわち仮消去部分の開始位置および終了位置を、ユーザが時間ベースでマークできるようにしている。）；
（１３）記録中、ストリーマのフォーマットは、ストリーム内に配慮せず、仮消去部分を完全消去状態にすることができる（これにより、仮消去部分をリアルタイムでリサイクル利用できるようになる）。

上記（１１）〜（１３）は、図３（ｆ）、図４、図２７または図３２に示すオリジナルＰＧＣ（ユーザ定義ＰＧＣに非ず）内のストリームセル情報ＳＣＩ（図２８）に含まれるプロテクトフラグＴＥ（図２８）を利用して、実現できる。このＴＥフラグは仮消去されたセルを示すものである。

次に、図２３（ｆ）あるいは図２５（ｆ）に示すストリームオブジェクト（ＳＯＢ）＃Ｂ・２９９の中央部を仮消去するものとし、図２３（ｇ）あるいは図２５（ｇ）に示すように見かけ上の仮消去領域７４７が設定される場合を想定して、図１７のフローチャートの説明に入る。

仮消去の処理においては、図１７のステップＳ２１〜Ｓ２３の「部分消去範囲」あるいは「消去範囲」を「仮消去範囲」と読み替えれば、処理内容の手順は同様である。また、図１７のステップＳ２７〜Ｓ２８も、処理手順としては、部分消去の場合も仮消去の場合も変わらない。

以下では、図１７のステップＳ２４〜Ｓ２６に関して、仮消去の場合の手順を、図２３および図２５を参照しながら、説明する。

ステップＳ２３の処理によりタイムマップ情報の作成が済むと、新たに定義されたＳＯＢ（ＳＯＢ＃＃Ｂ＊、ＳＯＢ＃Ｃ）に対するオリジナルセル情報が作成される（ステップＳ２４）。

このオリジナルセル情報の作成において、対応オリジナルセルの指定範囲が設定される。

具体的には、後述する図３０（ｂ）の図解を例に採れば、仮消去フラグＴＥが”１０ｂ”に設定されたセル＃ｋ＋１の開始時刻は、ユーザ等により指定された仮消去開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ；仮消去の開始マーク）となる。また、仮消去フラグＴＥが”１０ｂ”に設定されたセル＃ｋ＋１の終了時刻は、ユーザ等により指定された仮消去終了時刻（ＥＲＡ＿Ｅ＿ＡＰＡＴ；仮消去の終了マーク）となる。

あるいは、後述する図３１上段の図解を例に採れば、仮消去フラグＴＥが”１０ｂ”に設定されたセル＃ｋ＋１の開始時刻はＳＣ＿Ｓ＿ＡＰＡＴｋ＋１となり、このセル＃ｋ＋１の終了時刻はＳＣ＿Ｅ＿ＡＰＡＴｋ＋１となる。

次に、元の（仮消去前の）ストリームオブジェクト情報（ＳＯＢＩ）に関する情報（タイムマップ情報等）が、前述した部分消去と同様な方法で書き替えられる（ステップＳ２５）。

この仮消去では、仮消去対象のデータ自体が消去されるのではなく、消去対象のデータの管理情報が「仮消去」状態に書き替えられるだけである。しかし、仮消去対象のデータ（図３０（ｂ）あるいは図３１上段の例ではセル＃ｋ＋１のデータ）が完全消去されると、以下の処理がなされる。

まず、タイムマップ情報が書き替えられたＳＯＢに対応したオリジナルセルの時刻範囲が変更される（ステップＳ２６）。

具体的には、後述する図３０の図解を例に採れば、図３０（ｂ）の仮消去セル＃ｋ＋１の開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ）が図３０（ｃ）の完全消去後のセル＃ｋの終了時刻（ＳＣ＿Ｅ＿ＡＰＡＴ）に合わせられ、図３０（ｂ）の仮消去セル＃ｋ＋１の終了時刻（ＥＲＡ＿Ｅ＿ＡＰＡＴ）が図３０（ｃ）の完全消去後のセル＃ｋ＋１（完全消去前はセル＃Ｋ＋２）の開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）に合わせられることになる。

以上の仮消去処理の要点を纏めると、次のようになる。

（ａ）仮消去の開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ）および仮消去の終了時刻（ＥＲＡ＿Ｅ＿ＡＰＡＴ）によって、ストリームオブジェクト（ＳＯＢ）に含まれるビットストリーム情報の一部（図２３または図２５の仮消去領域７４７）に対する仮の消去範囲が指定される（ステップＳ２１において、「部分消去範囲」を「仮消去範囲」に読み替える）。

開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）がストリームブロック（ＳＯＢＵ）内で開始するトランスポートパケット（アプリケーションパケット）の先頭に一致するときに、開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）を伴うトランスポートパケット（アプリケーションパケット）を含むところのストリームブロック（ＳＯＢＵ）内で開始するトランスポートパケット（アプリケーションパケット）のうちの最初のものの開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）に、仮消去の開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ）を合わせる（ステップＳ２６において、「部分消去」を「仮消去」に読み替える）。そして、ストリーマ情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＴＲＩ）を書き替える（ステップＳ２７）。

（ｂ）あるいは、仮消去の開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ）および仮消去の終了時刻（ＥＲＡ＿Ｅ＿ＡＰＡＴ）によって、ストリームオブジェクト（ＳＯＢ）に含まれるビットストリーム情報の一部（図２３または図２５の仮消去領域７４７）に対する仮の消去範囲が指定される（ステップＳ２１において、「部分消去範囲」を「仮消去範囲」に読み替える）。

仮の消去範囲が指定された部分に相当するセル（ＴＥセル）がストリームオブジェクト（ＳＯＢ）の先頭を含むときに、開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）を伴うトランスポートパケット（アプリケーションパケット）を含むところのストリームブロック（ＳＯＢＵ）内で開始するトランスポートパケット（アプリケーションパケット）のうちの最初のものの開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）に、仮消去の開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ）を合わせる（ステップＳ２６において、「部分消去」を「仮消去」に読み替える）。そして、ストリーマ情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＴＲＩ）を書き替える（ステップＳ２７）。

（ｃ）あるいは、仮消去の開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ）および仮消去の終了時刻（ＥＲＡ＿Ｅ＿ＡＰＡＴ）によって、ストリームオブジェクト（ＳＯＢ）に含まれるビットストリーム情報の一部（図２３または図２５の仮消去領域７４７）に対する仮の消去範囲が指定される（ステップＳ２１において、「部分消去範囲」を「仮消去範囲」に読み替える）。

開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）を伴うトランスポートパケット（アプリケーションパケット）を含むところのストリームブロック（図３０（ｂ）のＳＯＢＵ＃３）が直後に続く他のストリームブロック（図３０（ｂ）のＳＯＢＵ＃２）内で開始するトランスポートパケット（アプリケーションパケット）のうちの最初のものの開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）に、仮消去の開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ）を合わせる（ステップＳ２６において、「部分消去」を「仮消去」に読み替える）。そして、ストリーマ情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＴＲＩ）を書き替える（ステップＳ２７）。

（ｄ）あるいは、仮消去の開始時刻（ＥＲＡ＿Ｓ＿ＡＰＡＴ）および仮消去の終了時刻（ＥＲＡ＿Ｅ＿ＡＰＡＴ）によって、ストリームオブジェクト（ＳＯＢ）に含まれるビットストリーム情報の一部（図２３または図２５の仮消去領域７４７）に対する仮の消去範囲が指定される（ステップＳ２１において、「部分消去範囲」を「仮消去範囲」に読み替える）。

仮の消去範囲が指定された部分に相当するセル（ＴＥセル）の直後に続くトランスポートパケット（アプリケーションパケット）を含むところのストリームブロック（図３０（ｃ）のセル＃ｋ＋１のＳＯＢＵ＃１）内で開始するトランスポートパケット（アプリケーションパケット）のうちの最初のものの開始時刻（ＳＣ＿Ｓ＿ＡＰＡＴ）に、仮消去の終了時刻（ＥＲＡ＿Ｅ＿ＡＰＡＴ）を合わせる（ステップＳ２６において、「部分消去」を「仮消去」に読み替える）。そして、ストリーマ情報（ＳＴＲＥＡＭ．ＩＦＯ／ＳＴＲＩ）を書き替える（ステップＳ２７）。

図１８は、ＭＰＥＧエンコードされた映像データ（部分消去前あるいは仮消去前）に対する時間管理情報設定方法を説明する図である。

また、図１９は、図１８の映像データに対応したオリジナルセル情報（部分消去前あるいは仮消去前）における時間情報とフィールド情報との関係を説明する図である。

前述した実施の形態では、特定のデータサイズ（たとえば３２セクタ／６４ｋバイト）毎に分割したストリームブロック（ＳＯＢＵ）毎に実質的な部分消去を行い、詳細な見かけ上の部分消去範囲を、オリジナルセル範囲で定義できるようになっている。

しかし、この発明はそれだけに限られない。映像データなどの特定のデータをユニットもしくはブロックに分割管理し、そのユニットもしくはブロック単位で消去を行なうとともに、再生情報（セルなど）の範囲指定により「ユーザによる詳細な再生範囲を指定できる」あらゆる方法に対して、この発明を適用することができる。

たとえば、ＭＰＥＧ２により記録された映像情報を管理する管理情報ファイルであるＲＴＲ．ＩＦＯ１０４（図２）では、図１８に示すようにＭＰＥＧ２の動画圧縮に特有なＩピクチャから次のＩピクチャの手前までがユニット化されて取り扱われる。このユニットは、ビデオオブジェクトユニット（ＶＯＢＵ）と呼ばれる。このＶＯＢＵは、ストリームオブジェクトユニット（ＳＯＢＵ）に対応させて考えることができる。

ＮＴＳＣのＴＶ規格では、１秒間に約３０枚の画像（フレーム）を表示している。各画像をピクチャと呼び、インターレース方式では１枚のピクチャ（フレーム）を２回のフィールド走査（奇数フィールド走査と偶数フィールド走査）で表現している。

ストリーマでは、ストリームデータが受信機に到達した時刻情報が記録されているタイムスタンプ情報を、時間（時刻）情報として利用している。しかし、この発明の一実施の形態においては、映像情報に対しては、図１８に示す最初のＩピクチャａから数えたフィールド数で、時間（時刻）情報を表わすことも可能としている。

この実施の形態でのタイムマップ情報は、ＶＯＢＵ（あるいはＳＯＢＵ）毎のユニットとして管理される。たとえば、図３（ｉ）のストリームブロックサイズ２６２に対しては、１個のＶＯＢＵ（あるいはＳＯＢＵ）のデータサイズが対応する。また、ストリームブロック時間差２６３に対応する時間情報としては、１個の対応するＶＯＢＵ（あるいはＳＯＢＵ）内に含まれるフィールド数が当てはまる。

このとき、オリジナルセル＃１の情報（図２８のＳＣＩ）７６３（図１９）における該当セルの開始時間（ＳＣ＿Ｓ＿ＡＰＡＴあるいはＥＲＡ＿Ｓ＿ＡＰＡＴ）７５３および該当セルの終了時間（ＳＣ＿Ｅ＿ＡＰＡＴあるいはＥＲＡ＿Ｅ＿ＡＰＡＴ）７５８の情報は、図１８の先頭Ｉピクチャａから数えたフィールド数で表現できる。

たとえば、図１８のｎ枚目のピクチャの時間情報は、２ｎ番目のフィールドとして表現できる。

図２０は、ＭＰＥＧエンコードされた映像データ（部分消去後あるいは仮消去後）に対する時間管理情報設定方法を説明する図である。

また、図２１は、図２０の映像データに対応したオリジナルセル情報（部分消去後あるいは仮消去後）における時間情報とフィールド情報との関係を説明する図である。

図１８の映像情報に対して部分消去の処理を行った場合には、図２０に示すように、ＶＯＢＵ＃２（ＳＯＢＵ＃２）のみが実質的に部分消去される。ユーザ等が指定した細かい部分消去の範囲は、図１５その他を参照して説明したストリームデータの部分消去の場合と同様、セルの範囲設定で規定できる。

すなわち、図２０において、ユーザ等がＢピクチャｆからＢピクチャｓまで部分消去を指定した場合、部分消去指定範囲に完全に含まれるＶＯＢＵ＃２（ＳＯＢＵ＃２）は完全に消去される。このとき、一部のみ部分消去の指定範囲に含まれるＶＯＢＵ＃１（ＳＯＢＵ＃１）およびＶＯＢＵ＃３（ＳＯＢＵ＃３）は、ＶＯＢＵ単位（ＳＯＢＵ単位）で実質的に残存する。

ストリームデータの場合と同様に、部分消去した部分の前後でＶＯＢ（あるいはＳＯＢ）が分割されてＶＯＢ＃１（ＳＯＢ＃１）とＶＯＢ＃２（ＳＯＢ＃２）になる。これに対応して、部分消去前のセルは、オリジナルセル＃１とオリジナルセル＃２に分かれる。

このとき、図２１に示すように、オリジナルセル＃１の情報（ＳＣＩ）７６４の該当セルの終了時間（ＳＣ＿Ｅ＿ＡＰＡＴあるいはＥＲＡ＿Ｅ＿ＡＰＡＴ）７５９としてＢピクチャｆに対応した２ｆ番目のフィールドを指定し、オリジナルセル＃２の情報（ＳＣＩ）７６５の該当セルの開始時間（ＳＣ＿Ｓ＿ＡＰＡＴあるいはＥＲＡ＿Ｓ＿ＡＰＡＴ）７５４としてＢピクチャｓに対応した２（ｓ―ｑ）番目のフィールドを指定することができる。

たとえば、図２０のｆ枚目のピクチャの時間情報は、２ｆ番目のフィールドとして表現できる。

図２０、図２１の実施の形態では、フィールド数は、必ずＶＯＢ（ＳＯＢ）毎にＶＯＢの先頭ピクチャから数えたフィールド数で表わしている。さらに、セル情報（ＳＣＩ）内で、フィールド数により、対応するＶＯＢ（ＳＯＢ）を指定できるようにしている。ここにこの実施の形態の特徴がある。

図２６は、ストリームブロック（ＳＯＢＵ）を構成するセクタの内部構成（アプリケーションパケットを含むストリームパックおよびスタッフィングパケットを含むストリームパック）の一例を説明する図である。

図２６（ｄ）のストリームオブジェクト（ＳＯＢ）＃Ａ・２９８は、図２６（ｃ）（ｅ）に示すように、複数のストリームブロック＃１、＃２、…で構成されている。

各ストリームブロック＃１、＃２、…は全て、２ＥＣＣブロックサイズ（＝３２セクタ＝６４ｋバイト）のストリームオブジェクトユニット（ＳＯＢＵ）で構成される。

このようにすると、たとえばストリームブロック（ＳＯＢＵ）＃２を削除しても、ストリームブロック（ＳＯＢＵ）＃１のＥＣＣブロックはこの削除に影響されない。

ＳＯＢ＃Ａ・２９８の先頭ストリームブロック（ＳＯＢＵ）＃１は、図２６（ｂ）に示すように、セクタＮｏ．０〜セクタＮｏ．３１（３２セクタ／６４ｋバイト）で構成されている。

ストリームブロック（ＳＯＢＵ）＃１の各セクタは、同様なデータ構造を持っている。、たとえばセクタＮｏ．０についていうと、図２６（ａ）に示すようになっている。

すなわち、セクタＮｏ．０は２０４８バイト（２ｋバイト）のストリームパックにより構成される。このストリームパックは、１４バイトのパックヘッダと、２０３４バイトのストリームＰＥＳパケットとで構成される。

ストリームＰＥＳパケットは、６バイトのＰＥＳヘッダと、１バイトのサブストリームＩＤと、２０２７バイトのストリームデータエリアとで構成される。

ストリームデータエリアは、９バイトのアプリケーションヘッダと、アプリケーションヘッダエクステンション（オプション）と、スタッフィングバイト（オプション）と、アプリケーションパケットエリアとで構成される。

アプリケーションパケットエリアは、おのおのがアプリケーションタイムスタンプ（ＡＴＳ）を先頭に持つアプリケーションパケット群で構成される。

たとえば１８８バイトサイズのトランスポートパケットがアプリケーションパケットとしてアプリケーションパケットエリアに格納されるときは、１０個程度のアプリケーションパケットがアプリケーションパケットエリアに格納できる。

ストリーム記録においては、記録内容を生成するアプリケーションは、パック長の調整を別途行なう必要がないように、自身でスタッフィングを行なう。このため、ストリーム記録においては、ストリームパックが常に必要な長さ（たとえば２０４８バイト）を持つものとして扱うことができる。

図２６（ａ）のスタッフィングバイトは、ストリームパックを常に所定長（２０４８バイト）に保つために利用できる。

ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプＡＴＳの先頭バイトは、ストリームオブジェクトＳＯＢの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。

一方、ＳＯＢ内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割（スプリット）されてもよい。図９の下段に例示した部分パケットは、この分割（スプリット）により生じたアプリケーションパケットを示している。

ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。

こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。

図２６（ａ）のパックヘッダは、図示しないが、パック開始コードの情報、ＳＣＲベースの情報、ＳＣＲエクステンションの情報、プログラム最大レートの情報、マーカビット、パックスタッフィング長の情報等を含んでいる。

ＳＣＲベースは３２ビットで構成され、その３２ビット目はゼロとされる。また、プログラム最大レートとしては、１０．０８Ｍｂｐｓが採用される。

図２６（ａ）のＰＥＳヘッダおよびサブストリームＩＤは、図１０（ｃ）に示したような内容を持っている。

図２６（ａ）のアプリケーションヘッダは、図１２（ｃ）に示したように、バージョン情報、アプリケーションパケット数ＡＰ＿Ｎｓ、先頭アプリケーションパケットのタイムスタンプ位置ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ、エクステンションヘッダ情報ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ、サービスＩＤ等を含んでいる。

ここで、バージョンには、アプリケーションヘッダフォーマットのバージョン番号が記述される。

アプリケーションヘッダのＡＰ＿Ｎｓは、該当ストリームパック内で開始するアプリケーションパケットの数を記述したものである。該当ストリームパック内にＡＴＳの先頭バイトが格納されているときは、このストリームパック内でアプリケーションパケットが開始すると見なすことができる。

ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴには、該当ストリームパケット内で開始される最初のアプリケーションパケットのタイムスタンプ位置が、このストリームパケットの最初のバイトからの相対値として、バイト単位で、記述される。もしストリームパケット内で開始するアプリケーションパケットがないときは、ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴには「０」が記述される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯには、該当ストリームパケット内にアプリケーションヘッダエクステンションおよび／またはスタッフィングバイトが存在するか否かが、記述される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が００ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションもスタッフィングバイトも存在しないことが示される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が１０ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションがあるが、スタッフィングバイトは存在しないことが示される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が１１ｂの場合は、アプリケーションヘッダの後にアプリケーションヘッダエクステンションが存在し、かつアプリケーションヘッダエクステンションの後にスタッフィングバイトも存在することが示される。

ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯの内容が０１ｂとなることは禁止されている。

アプリケーションパケットエリアの前のスタッフィングバイト（オプション）は、「ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯ＝１１ｂ」によりアクティブになる。こうすることで、アプリケーションヘッダエクステンション内のバイト数と、アプリケーションパケットエリア内に格納できるアプリケーションパケット数との間に矛盾が生じた場合に「パッキングパラドクス」が起きるのを防止できる。

ＳＥＲＶＩＣＥ＿ＩＤには、ストリームを生成するサービスのＩＤが記述される。このサービスが未知のものであれば、ＳＥＲＶＩＣＥ＿ＩＤに０ｘ００００が記述される。

図２６（ａ）のアプリケーションパケットエリアは、図９の下段に示したと同様に構成できる（図９のパケットを図２６ではアプリケーションパケットに読み替える）。

すなわち、アプリケーションパケットエリアの先頭に部分アプリケーションパケットが記録され、その後に、アプリケーションタイムスタンプＡＴＳとアプリケーションパケットとのペアが複数ペア、シーケンシャルに記録され、末尾に部分アプリケーションパケットが記録される。

別の言い方をすると、アプリケーションパケットエリアの開始位置には、部分アプリケーションパケットが存在できる。アプリケーションパケットエリアの終了位置には、部分アプリケーションパケットあるいは予約されたバイト数のスタッフィングエリアが存在できる。

各アプリケーションパケットの前に配置されたアプリケーションタイムスタンプ（ＡＴＳ）は３２ビット（４バイト）で構成される。このＡＴＳは、２つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は９０ｋＨｚユニット値と呼ばれる部分であり、拡張部分は２７ＭＨｚで測った細かい値（less significant value）を示す。

図２６（ａ）において、アプリケーションヘッダエクステンションは、アプリケーションパケット〜アプリケーションパケット間で異なり得る情報を格納するのに用いることができる。このような情報は、必ずしも全てのアプリケーションに必要なものではない。

それゆえ、アプリケーションヘッダのデータフィールドは、ストリームデータエリア内にオプションのアプリケーションヘッダエクステンションが存在することを（前述したＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＮＦＯにおいて）記述できるように定義されている。

ストリームの記録時において、最初のアプリケーションパケットのアプリケーションタイムスタンプＡＴＳの先頭バイトは、ストリームオブジェクトＳＯＢの始まりにおける最初のストリームパケット内のアプリケーションパケットエリアの開始位置に、アラインされている必要がある。

一方、ＳＯＢ内のその後のストリームパケットについては、隣接ストリームパケット境界で、アプリケーションパケットが分割（スプリット）されてもよい。図８（ｆ）（ｇ）あるいは図９に示した部分アプリケーションパケットは、この分割（スプリット）により生じたアプリケーションパケットを示している。

ストリームパケット内で開始される最初のアプリケーションタイムスタンプのバイトオフセット、およびそのストリームパケット内で開始されるアプリケーションパケットの数は、そのアプリケーションヘッダに記述される。

こうすることにより、あるストリームパケット内において、最初のアプリケーションタイムスタンプの前および最後のアプリケーションパケットの後におけるスタッフィングが、自動的に行われる。

すなわち、上記自動化メカニズムにより、「アプリケーションが自分でスタッフィングを行なう」ことが実現される。この自動スタッフィングにより、ストリームパケットは常に必要な長さを持つことになる。

アプリケーションヘッダエクステンション（オプション）はエントリのリストからなる。ここには、該当ストリームパケット内で開始する各アプリケーションパケットに対する１バイト長の１エントリがある。これらエントリのバイトは、アプリケーションパケット毎に異なり得る情報を格納するのに利用できる。

なお、１バイトのアプリケーションヘッダエクステンション（オプション）には、１ビットのＡＵ＿ＳＴＡＲＴと、１ビットのＡＵ＿ＥＮＤと、２ビットのＣＯＰＹＲＩＧＨＴとが、記述される。

ＡＵ＿ＳＴＡＲＴが”１”にセットされると、関連アプリケーションパケットが、ストリーム内にランダムアクセスエントリポイント（ランダムアクセスユニットの開始）を含むことが示される。

ＡＵ＿ＥＮＤが”１”にセットされると、関連アプリケーションパケットがランダムアクセスユニットの最終パケットであることが示される。

ＣＯＰＹＲＩＧＨＴには、関連アプリケーションパケットの著作権の状態が記述される。

図２６（ａ）のパケット構造は、ＳＯＢ＃Ａ・２９８の最終セクタ以外に適用できるが、最終セクタには必ずしも適用されない。

たとえば、ＳＯＢ＃Ａ・２９８の末尾が図２６（ｆ）のセクタＮｏ．６３であり、このセクタが図２６（ｇ）に示すようにパディングパケット４０（図１（ｉ）参照）で構成されるときは、そのパディングエリア３８（図２６（ｈ））の内容が、図２６（ａ）と違ったものになる。

すなわち、図２６（ｉ）に示すように、パディングパケット４０としてのスタッフィングパケットは、１４バイトのパックヘッダと、６バイトのＰＥＳヘッダと、１バイトのサブストリームＩＤと、９バイトのアプリケーションヘッダと、２０１８バイトのアプリケーションパケットエリアとで構成される。

スタッフィングパケットの先頭を含むパックでは、このアプリケーションパケットエリアは、４バイトのアプリケーションタイムスタンプＡＴＳおよび２０１４バイト分のゼロバイトデータ（実質的な記録内容を持たないデータ）で構成される。

一方、その後続スタッフィングパケットを含むパックでは、このアプリケーションパケットエリアは、２０１８バイト分のゼロバイトデータ（ＡＴＳなし）で構成される。

ビットレートが極めて低い記録がなされる場合、タイムマップ情報（図３（ｈ）の２５２；あるいは図２９のＳＯＢＩ内ＭＡＰＬ）の回復（再生）を確実にするためにスタッフィングが必要になる。図２６（ｉ）のスタッフィングパケットは、そのための概念的な単位として定義されている。このスタッフィングパケットの目的は、スタッフィングエリアを含め夫々のＳＯＢＵが少なくとも１つのＡＴＳ値を含むようにすることで、達成される。

スタッフィングパケットには、以下の条件が付く：
＊１または複数のスタッフィングパケットは、常に、実際のアプリケーションパケットデータを含むパックの後のパックのアプリケーションパケットエリアから開始する；
＊１または複数のスタッフィングパケットは、１つの４バイトＡＴＳと、該当ＳＯＢＵの残りパックのアプリケーションデータエリアを埋め尽くすのに必要なだけのゼロバイトデータ（ＡＴＳの後に続く）とで構成される。いま、ＳＯＢＵ１個あたりのセクタ数をＳＯＢＵ＿ＳＩＺとしたときに、０≦ｎ≦ＳＯＢＵ＿ＳＩＺー１とすれば、スタッフィングパケットの全長は、「４＋２０１４＋ｎ×２０１８」バイトとなる。

スタッフィングパケットのＡＴＳは、次のように設定される：
＊少なくとも１個のパックが実際のアプリケーションパケットデータを含んでいるＳＯＢＵ内では、スタッフィングパケットのＡＴＳは、スタッフィングパケットに先行するアプリケーションパケットのＡＴＳに設定される；
＊実際のアプリケーションパケットデータを含まないＳＯＢＵ内では、スタッフィングパケットのＡＴＳはタイムマップ情報等の内容に応じて決定される。

スタッフィングパケットあるいはスタッフィングパケットの一部を含む全てのパックは、次のように構成される：
＊パックヘッダのＳＣＲは、先行パックのＳＣＲに「２０４８×８ビット÷１０．０８Ｍｂｐｓ」を加えたものとする；
＊ＰＥＳパケットヘッダおよびサブストリームＩＤは、他の全てのＰＥＳパケットに対するものと同じにする；
＊アプリケーションヘッダ（図１２（ｃ）（ｄ）参照）内において、ＡＰ＿Ｎｓ＝０、ＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ＝０、ＥＸＴＥＮＳＩＯＮ＿ＨＥＡＤＥＲ＿ＩＦＯ＝００ｂ、ＳＥＲＶＩＣＥ＿ＩＤ＝０（アプリケーションヘッダ内のその他のパラメータも０）とする。

図２７は、ストリーマの管理情報（図２のＳＴＲＥＡＭ．ＩＦＯまたはＳＲ＿ＭＡＮＧＲ．ＩＦＯに対応）の内部データ構造を説明する図である。

図２あるいは図３（ｅ）に示した管理情報（ナビゲーションデータ）であるＳＴＲＥＡＭ．ＩＦＯ（ＳＲ＿ＭＡＮＧＲ．ＩＦＯ）１０５は、図２７に示すように、ストリーマ情報ＳＴＲＩを含んでいる。

このストリーマ情報ＳＴＲＩは、図３（ｆ）あるいは図２７に示すように、ストリーマビデオマネージャ情報ＳＴＲ＿ＶＭＧＩと、ストリームファイル情報テーブルＳＦＩＴと、オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩ（より一般的に表現すればＰＧＣ情報ＰＧＣＩ＃ｉ）と、ユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴと、テキストデータマネージャＴＸＴＤＴ＿ＭＧと、アプリケーションプライベートデータマネージャＡＰＤＴ＿ＭＧとで、構成されている。

ストリーマビデオマネージャ情報ＳＴＲ＿ＶＭＧＩは、図２７に示すように、ＳＴＲＩ、ＳＴＲ＿ＶＭＧＩに関する管理情報等が記述されたビデオマネージャ情報管理情報ＶＴＳＩ＿ＭＡＴと、ストリーム内のプレイリストをサーチするためのサーチポインタが記述されたプレイリストサーチポインタテーブル（ＰＬ＿ＳＲＰＴ）とを含んでいる。

ここで、プレイリストとは、プログラムの一部のリストである。このプレイリストにより、（プログラムの内容に対して）任意の再生シーケンスをユーザが定義できる。

ストリームファイル情報テーブルＳＦＩＴは、ストリーマ動作に直接関係する全てのナビゲーションデータを含むものである。ストリームファイル情報テーブルＳＦＩＴの詳細については、図２９を参照して後述する。

オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩは、オリジナルＰＧＣ（ＯＲＧ＿ＰＧＣ）に関する情報を記述した部分である。ＯＲＧ＿ＰＧＣはプログラムセットを記述したナビゲーションデータを示す。ＯＲＧ＿ＰＧＣはプログラムの連なり（チェーン）であり、図２または図３２の「．ＳＲＯ」ファイル（図２ではＳＲ＿ＴＲＡＮＳ．ＳＲＯ１０６）内に記録されたストリームデータを含む。

ここで、プログラムセットとは、情報記憶媒体２０１の記録内容全体（全てのプログラム）を示すものである。プログラムセットの再生においては、任意のプログラムが編集されオリジナル記録に対してその再生順序が変更されている場合を除き、再生順序としてはそのプログラムの記録順序と同じ再生順序が用いられる。このプログラムセットは、オリジナルＰＧＣ（ＯＲＧ＿ＰＧＣ）と呼ばれるデータ構造に対応している。

また、プログラムは、ユーザにより認識されあるいはユーザにより定義されるところの、記録内容の論理単位である。プログラムセット中のプログラムは、１以上のオリジナルセルにより構成される。プログラムはオリジナルＰＧＣ内でのみ定義されるものである。

さらに、セルは、プログラムの一部を示すデータ構造である。オリジナルＰＧＣ内のセルは「オリジナルセル」と呼ばれ、後述するユーザ定義ＰＧＣ内のセルは「ユーザ定義セル」と呼ばれる。

プログラムセット内の各々のプログラムは、少なくとも１個のオリジナルセルで構成される。また、各々のプレイリスト中のプログラムの一部それぞれは、少なくとも１個のユーザ定義セルで構成される。

一方、ストリーマでは、ストリームセル（ＳＣ）だけが定義される。各ストリームセルは、記録されたビットストリームの一部を参照するものである。この発明の実施の形態においては、特に断り無く「セル」と述べた場合は、「ストリームセル」のことを意味している。

なお、プログラムチェーン（ＰＧＣ）とは、上位概念的な単位を示す。オリジナルＰＧＣでは、ＰＧＣはプログラムセットに対応したプログラムの連なり（チェーン）を指す。また、ユーザ定義ＰＧＣでは、ＰＧＣはプレイリストに対応するプログラムの一部の連なり（チェーン）を指す。

また、プログラムの一部のチェーンを指すユーザ定義ＰＧＣは、ナビゲーションデータだけを含む。そして、各プログラムの一部が、オリジナルＰＧＣに属するストリームデータを参照するようになっている。

図２７のユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴは、ユーザ定義ＰＧＣ情報テーブル情報ＵＤ＿ＰＧＣＩＴＩと、１以上のユーザ定義ＰＧＣサーチポインタＵＤ＿ＰＧＣ＿ＳＲＰ＃ｎと、１以上のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩ＃ｎとを含むことができる。

ユーザ定義ＰＧＣ情報テーブル情報ＵＤ＿ＰＧＣＩＴＩは、ユーザ定義ＰＧＣサーチポインタＵＤ＿ＰＧＣ＿ＳＲＰの数を示すＵＤ＿ＰＧＣ＿ＳＲＰ＿Ｎｓと、ユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴの終了アドレスを示すＵＤ＿ＰＧＣＩＴ＿ＥＡとを含む。

ＵＤ＿ＰＧＣ＿ＳＲＰ＿Ｎｓが示すＵＤ＿ＰＧＣ＿ＳＲＰの数は、ユーザ定義ＰＧＣ情報（ＵＤ＿ＰＧＣＩ）の数と同じであり、ユーザ定義ＰＧＣ（ＵＤ＿ＰＧＣ）の数とも同じである。この数は、最大「９９」まで許されている。

ＵＤ＿ＰＧＣＩＴ＿ＥＡは、該当ＵＤ＿ＰＧＣＩＴの終了アドレスを、そのＵＤ＿ＰＧＣＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）で記述したものである。

ここで、Ｆ＿ＲＢＮとは、ファイル内において、定義されたフィールドの先頭バイトからの相対バイト数を示すもので、ゼロから始まる。

オリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩあるいはユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴ内のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩを一般的に表現したＰＧＣＩ＃ｉについては、図２８を参照して後述する。

図２７のテキストデータマネージャＴＸＴＤＴ＿ＭＧは、補足的なテキスト情報である。このＴＸＴＤＴ＿ＭＧは、図２８のプライマリテキスト情報ＰＲＭ＿ＴＸＴＩとともに、プレイリストおよびプログラム内に格納できる。

図２７のアプリケーションプライベートデータマネージャＡＰＤＴ＿ＭＧは、図示しないが、アプリケーションプライベートデータマネージャ一般情報ＡＰＤＴ＿ＧＩと、１以上のＡＰＤＴサーチポインタＡＰＤＴ＿ＳＲＰ＃ｎと、１以上のＡＰＤＴエリアＡＰＡＤＴＡ＃ｎとを含むことができる。

ここで、アプリケーションプライベートデータＡＰＤＴとは、ストリーマに接続されたアプリケーションデバイスが任意の非リアルタイム情報（リアルタイムストリームデータに加えさらに望まれる情報）を格納できるような概念上のエリアである。

図２８は、ＰＧＣ情報（図３のＯＲＧ＿ＰＧＣＩ／ＵＤ＿ＰＧＣＩＴまたは図２７のＰＧＣＩ＃ｉ）の内部データ構造を説明する図である。

図２８のＰＧＣ情報ＰＧＣＩ＃ｉは、図２７のオリジナルＰＧＣ情報ＯＲＧ＿ＰＧＣＩあるいはユーザ定義ＰＧＣ情報テーブルＵＤ＿ＰＧＣＩＴ内のユーザ定義ＰＧＣ情報ＵＤ＿ＰＧＣＩを一般的に表現したものである。

図２８に示すように、ＰＧＣ情報ＰＧＣＩ＃ｉは、ＰＧＣ一般情報ＰＧＣ＿ＧＩと、１以上のプログラム情報ＰＧＩ＃ｍと、１以上のストリームセル情報サーチポインタＳＣＩ＿ＳＲＰ＃ｎと、１以上のストリームセル情報ＳＣＩ＃ｎとで構成されている。

ＰＧＣ一般情報ＰＧＣ＿ＧＩは、プログラムの数ＰＧ＿Ｎｓと、ストリームセル情報サーチポインタＳＣＩ＿ＳＲＰの数ＳＣＩ＿ＳＲＰ＿Ｎｓとを含んでいる。

各プログラム情報ＰＧＩ（たとえばＰＧＩ＃１）は、プログラムタイプＰＧ＿ＴＹと、該当プログラム内のセルの数Ｃ＿Ｎｓと、該当プログラムのプライマリテキスト情報ＰＲＭ＿ＴＸＴＩと、アイテムテキストのサーチポインタ番号ＩＴ＿ＴＸＴ＿ＳＲＰＮとを含んでいる。

ここで、プログラムタイプＰＧ＿ＴＹは、該当プログラムの状態を示す情報を含む。とくに、そのプログラムが誤消去などから保護された状態にあるかどうかを示すフラグ、すなわちプロテクトフラグを含む。

このプロテクトフラグが「０ｂ」のときは該当プログラムは保護されておらず、「１ｂ」のときは保護された状態にある。

セルの数Ｃ＿Ｎｓは、該当プログラム内のセルの数を示す。ＰＧＣの全プログラムおよび全セルの全体に渡り、セルは、その昇順に従い、プログラムに（暗黙のうちに）付随している。

たとえば、ＰＧＣ内でプログラム＃１がＣ＿Ｎｓ＝１を持ち、プログラム＃２がＣ＿Ｎｓ＝２を持つとすれば、そのＰＧＣの最初のストリームセル情報ＳＣＩはプログラム＃１に付随するものとなり、第２、第３のＳＣＩはプログラム＃２に付随するものとなる。

プライマリテキスト情報ＰＲＭ＿ＴＸＴＩは、情報記憶媒体（ＤＶＤ−ＲＡＭディスク）２０１を世界中で利用可能とするために、１つの共通キャラクタセット（ＩＳＯ／ＩＥＣ６４６：１９８３（ＡＳＣＩＩコード））を持ったテキスト情報を記述したものである。

アイテムテキストのサーチポインタ番号ＩＴ＿ＴＸＴ＿ＳＲＰＮは、アイテムテキスト（該当プログラムに対応するテキストデータ）ＩＴ＿ＴＸＴに対するサーチポインタ番号を記述したものである。該当プログラムがアイテムテキストを持たないときは、ＩＴ＿ＴＸＴ＿ＳＲＰＮは「００００ｈ」にセットされる。

各ストリームセル情報サーチポインタＳＣＩ＿ＳＲＰ（たとえばＳＣＩ＿ＳＲＰ＃１）は、対応ストリームセル情報ＳＣＩの開始アドレスを示すＳＣＩ＿ＳＡを含んでいる。このＳＣＩ＿ＳＡは、ＰＧＣＩの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）で記述される。

各ストリームセル情報ＳＣＩ（たとえばＳＣＩ＃１）は、ストリームセル一般情報ＳＣ＿ＧＩと、１以上のストリームセルエントリポイント情報ＳＣ＿ＥＰＩ＃ｎとで構成される。

ストリームセル一般情報ＳＣ＿ＧＩは、仮消去（テンポラリイレーズ；ＴＥ）状態を示すフラグＴＥを含むセルタイプＣ＿ＴＹと、ストリームセルのエントリポイント情報の数ＳＣ＿ＥＰＩ＿Ｎｓと、ストリームオブジェクト番号ＳＯＢ＿Ｎと、ストリームセル開始ＡＰＡＴ（図６他で示したＳＣ＿Ｓ＿ＡＰＡＴ）と、ストリームセル終了ＡＰＡＴ（図６他で示したＳＣ＿Ｅ＿ＡＰＡＴ）と、セルが仮消去状態（ＴＥ＝０１ｂ）にあるときにその仮消去セルの開始ＡＰＡＴを示す消去開始ＡＰＡＴ（図６他で示したＥＲＡ＿Ｓ＿ＡＰＡＴ）と、セルが仮消去状態（ＴＥ＝１０ｂ）にあるときにその仮消去セルの終了ＡＰＡＴを示す消去終了ＡＰＡＴ（図６他で示したＥＲＡ＿Ｅ＿ＡＰＡＴ）とを含んでいる。

セルタイプＣ＿ＴＹは、該当ストリームセルの形式およびその仮消去状態を記述するものである。

すなわち、セルの形式Ｃ＿ＴＹ１＝「０１０ｂ」は全てのストリームセルの形式に記述される（このＣ＿ＴＹ１＝「０１０ｂ」によりストリームセルとそれ以外のセルの区別ができる）。

一方、フラグＴＥが「００ｂ」であれば該当セルは通常の状態にあることが示され、フラグＴＥが「０１ｂ」あるいは「１０ｂ」であれば該当セルは仮消去の状態にあることが示される。

フラグＴＥ＝「０１ｂ」は、該当セル（仮消去状態にあるセル）が、ＳＯＢＵ内で開始する最初のアプリケーションパケットの後から開始し、同じＳＯＢＵ内の最終アプリケーションパケットの前で終了する場合を示す。

また、フラグＴＥ＝「１０ｂ」は、該当セル（仮消去状態にあるセル）が、少なくとも１つのＳＯＢＵ境界（先頭アプリケーションパケットあるいは最終アプリケーションパケットがそのＳＯＢＵ内で開始する）を含む場合を示す。

なお、プログラムのプロテクトフラグと、そのプログラム内のセルのＴＥフラグとは、同時に設定できないようになっている。それゆえ、
（ａ）プロテクト状態にあるプログラム内のセルは何れも仮消去状態に設定できず；
（ｂ）仮消去状態にあるセルを１以上含むプログラムはプロテクト状態に設定できない。

ストリームセルのエントリポイント情報の数ＳＣ＿ＥＰＩ＿Ｎｓは、該当ストリームセル情報ＳＣＩ内に含まれるストリームセルエントリポイント情報の数を記述したものである。

図２８の各ストリームセルエントリポイント情報ＳＣ＿ＥＰＩ（たとえばＳＣ＿ＥＰＩ＃１）は、２種類（タイプＡとタイプＢ）存在する。

タイプＡのＳＣ＿ＥＰＩは、エントリポイントタイプＥＰ＿ＴＹとエントリポイントのアプリケーションパケット到着時間ＥＰ＿ＡＰＡＴとを含む。タイプＡは、エントリポイントタイプＥＰ＿ＴＹ１＝「００ｂ」により示される。

タイプＢのＳＣ＿ＥＰＩは、タイプＡのＥＰ＿ＴＹおよびＥＰ＿ＡＰＡＴの他に、プライマリテキスト情報ＰＲＭ＿ＴＸＴＩを含む。タイプＢは、エントリポイントタイプＥＰ＿ＴＹ１＝「０１ｂ」により示される。

任意のストリームセルにおいて、記録内容の一部をスキップする道具として、エントリポイントを利用することができる。全てのエントリポイントはアプリケーションパケット到着時間（ＡＰＡＴ）により特定できる。このＡＰＡＴにより、どこからデータ出力が開始されるのかを特定できる。

ストリームオブジェクト番号ＳＯＢ＿Ｎは、該当セルが参照するＳＯＢの番号を記述したものである。

ストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）は、該当セルの開始ＡＰＡＴを記述したものである。

ストリームセル終了ＡＰＡＴ（ＳＣ＿Ｅ＿ＡＰＡＴ）は、該当セルの終了ＡＰＡＴを記述したものである。

消去開始ＡＰＡＴ（ＥＲＡ＿Ｓ＿ＡＰＡＴ）は、少なくとも１個のＳＯＢＵ境界を含む仮消去セル（そのＣ＿ＴＹのＴＥフィールドが「１０ｂ」）において、この仮消去セルに先頭が含まれる最初のＳＯＢＵ内で開始する最初のアプリケーションパケットの到着時間（ＡＰＡＴ）を記述したものである。

消去終了ＡＰＡＴ（ＥＲＡ＿Ｅ＿ＡＰＡＴ）は、少なくとも１個のＳＯＢＵ境界を含む仮消去セル（そのＣ＿ＴＹのＴＥフィールドが「１０ｂ」）において、仮消去セルのすぐ後に続くアプリケーションパケットを含むＳＯＢＵ内で開始する最初のアプリケーションパケットの到着時間（ＡＰＡＴ）を記述したものである。

図２９は、ストリームファイル情報テーブル（図３（ｆ）または図２７のＳＦＩＴ）の内部データ構造を説明する図である。

図２９に示すように、ストリームファイル情報テーブルＳＦＩＴは、ストリームファイル情報テーブル情報ＳＦＩＴＩと、１以上のストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩ＃ｎと、ストリームファイル情報ＳＦＩとで構成される。

ストリームファイル情報テーブル情報ＳＦＩＴＩは、情報記憶媒体（ＤＶＤ−ＲＡＭディスク）２０１上のストリームファイル情報の数ＳＦＩ＿Ｎｓと、ＳＦＩＴＩに続くストリームオブジェクトストリーム情報の数ＳＯＢ＿ＳＴＩ＿Ｎｓと、ＳＦＩＴの終了アドレスＳＦＩＴ＿ＥＡと、ＳＦＩの開始アドレスＳＦＩ＿ＳＡとで構成される。

ＳＦＩＴ＿ＥＡは、ＳＦＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）でＳＦＩＴの終了アドレスを記述したものである。

また、ＳＦＩ＿ＳＡは、ＳＦＩＴの先頭バイトからの相対バイト数（Ｆ＿ＲＢＮ）でＳＦＩの開始アドレスを記述したものである。

ストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩは、３種類のパラメータを含む。各パラメータは箇々のビットストリーム記録に対して固有な値を持つことができる。しかしながら、通常は、多くのビットストリーム記録においてこれらのパラメータセットは等しいものにできる。それゆえ、ＳＯＢ＿ＳＴＩは、ストリームオブジェクト情報（ＳＯＢＩ）のテーブルとは別のテーブルに格納され、幾つかのストリームオブジェクト（ＳＯＢ）が同じＳＯＢ＿ＳＴＩを共有する（つまり同じＳＯＢ＿ＳＴＩをポイントする）ことが認められている。したがって、通常は、ＳＯＢの数よりもそＢ＿ＳＴＩの数の方が少なくなる。

図２７の各ストリームオブジェクトストリーム情報ＳＯＢ＿ＳＴＩ（たとえばＳＯＢ＿ＳＴＩ＃１）は、アプリケーションパケットサイズＡＰ＿ＳＩＺと、サービスＩＤの数ＳＥＲＶ＿ＩＤ＿Ｎｓと、サービスＩＤ（ＳＥＲＶ＿ＩＤｓ）と、アプリケーションパケットデバイスユニークＩＤ（ＡＰ＿ＤＥＶ＿ＵＩＤ）とを含んでいる。

ＡＰ＿ＳＩＺは、アプリケーションデバイスからストリーマへ転送されたビットストリーム内のパケットのバイト長で、アプリケーションパケットサイズを記述したものである。

なお、ＤＶＤストリーマではアプリケーションパケットサイズは、各ビットストリーム記録において、一定とされている。そのため各々の中断のない記録中においてアプリケーションパケットサイズが変化するようなことがあれば、現在のストリームオブジェクト（現ＳＯＢ）はそこで終了され、新たなストリームオブジェクト（新ＳＯＢ）が、新たなＡＰ＿ＳＩＺを伴って開始される。その際、現ＳＯＢおよび新ＳＯＢの双方は、オリジナルＰＧＣ情報（ＯＲＧ＿ＰＧＣＩ）内の同じプログラムに属するものとなる。

ＳＥＲＶ＿ＩＤ＿Ｎｓは、後続パラメータに含まれるサービスＩＤの数を記述したものである。

ＳＥＲＶ＿ＩＤｓは、サービスＩＤのリストを任意の順序で記述したものである。

ＡＰ＿ＤＥＶ＿ＵＩＤは、記録されたビットストリームを供給したアプリケーションデバイスに固有の、ユニークなデバイスＩＤを記述したものである。

ストリームファイル情報ＳＦＩは、図２９に示すように、ストリームファイル一般情報ＳＦ＿ＧＩと、１以上のストリームオブジェクト情報（ＳＯＢ情報）サーチポインタ（ＳＯＢＩ＿ＳＲＰ）＃ｎと、１以上のＳＯＢ情報（ＳＯＢＩ）＃ｎとで構成されている。

ストリームファイル一般情報ＳＦ＿ＧＩは、ＳＯＢＩの数ＳＯＢＩ＿Ｎｓと、ＳＯＢＵ１個あたりのセクタ数ＳＯＢＵ＿ＳＩＺと、タイムマップ情報の一種であるＭＴＵ＿ＳＨＦＴとを含んでいる。

ここで、ＳＯＢＵ＿ＳＩＺは、ＳＯＢＵのサイズをセクタ数で記述したもので、このサイズは３２（３２セクタ＝６４ｋバイト）で一定となっている。このことは、各タイムマップ情報（ＭＡＰＬ）内において、最初のエントリが、ＳＯＢの最初の３２セクタ内に含まれるアプリケーションパケットに関係していることを意味する。同様に、２番目のエントリは、次の３２セクタに含まれるアプリケーションパケットに関係する。３番目以降のエントリについても以下同様である。

各ＳＯＢ情報サーチポインタ（たとえばＳＯＢＩ＿ＳＲＰ＃１）は、ＳＯＢＩの開始アドレスＳＯＢＩ＿ＳＡを含んでいる。このＳＯＢＩ＿ＳＡは、ストリームファイル情報ＳＦＩの先頭バイトから相対バイト数（Ｆ＿ＲＢＮ）でもって関連ＳＯＢＩの開始アドレスを記述したものである。

各ＳＯＢ情報（たとえばＳＯＢＩ＃１）は、ストリームオブジェクト一般情報ＳＯＢ＿ＧＩと、タイムマップ情報ＭＡＰＬと、アクセスユニットデータＡＵＤ（オプション）とで構成される。

ストリームオブジェクト一般情報ＳＯＢ＿ＧＩは、ストリームオブジェクトのタイプＳＯＢ＿ＴＹと、ストリームオブジェクト記録時間ＳＯＢ＿ＲＥＣ＿ＴＭと、ストリームオブジェクトのストリーム情報番号ＳＯＢ＿ＳＴＩ＿Ｎと、アクセスユニットデータフラグＡＵＤ＿ＦＬＡＧＳと、ストリームオブジェクトの開始アプリケーションパケット到着時間ＳＯＢ＿Ｓ＿ＡＰＡＴと、ストリームオブジェクトの終了アプリケーションパケット到着時間ＳＯＢ＿Ｅ＿ＡＰＡＴと、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットＳＯＢ＿Ｓ＿ＳＯＢＵと、タイムマップ情報のエントリ数ＭＡＰＬ＿ＥＮＴ＿Ｎｓとを含んでいる。

ストリームオブジェクトのタイプＳＯＢ＿ＴＹは、仮消去状態（ＴＥ状態）を示すビットおよび／またはコピー世代管理システムのビットを記述できる部分である。

ストリームオブジェクト記録時間ＳＯＢ＿ＲＥＣ＿ＴＭは、関連ストリームオブジェクト（ＳＯＢ）の記録時間を記述したものである。

ストリームオブジェクトのストリーム情報番号ＳＯＢ＿ＳＴＩ＿Ｎは、該当ストリームオブジェクトに対して有効なＳＯＢ＿ＳＴＩのインデックスを記述したものである。

アクセスユニットデータフラグＡＵＤ＿ＦＬＡＧＳは、該当ストリームオブジェクトにたいしてアクセスユニットデータ（ＡＵＤ）が存在するか否か、また存在するならどんな種類のアクセスユニットデータなのかを記述したものである。

アクセスユニットデータ（ＡＵＤ）が存在する場合は、ＡＵＤ＿ＦＬＡＧＳにより、ＡＵＤの幾つかの特性が記述される。

アクセスユニットデータ（ＡＵＤ）自体は、図２９に示すように、アクセスユニット一般情報ＡＵ＿ＧＩと、アクセスユニットエンドマップＡＵＥＭと、再生タイムスタンプリストＰＴＳＬとで構成される。

アクセスユニット一般情報ＡＵ＿ＧＩは、該当ＳＯＢに対して記述されたアクセスユニットの数を示すＡＵ＿Ｎｓと、該当ＳＯＢに属するＳＯＢＵのどれがアクセスユニットを含むのかを示すアクセスユニット開始マップＡＵＳＭとを含んでいる。

アクセスユニットエンドマップＡＵＥＭは、（もし存在するときは）ＡＵＳＭと同じ長さのビットアレイであり、該当ＳＯＢのアクセスユニットに付随するビットストリームセグメントの終端をどのＳＯＢＵが含むのかを示す。

再生タイムスタンプリストＰＴＳＬは、該当ＳＯＢに属する全てのアクセスユニットの再生タイムスタンプのリストである。このリストに含まれる１つのＰＴＳＬエレメントは、対応アクセスユニットの再生タイムスタンプ（ＰＴＳ）を含む。

なお、アクセスユニット（ＡＵ）とは、記録されたビットストリームのうちの任意の単一連続部分を指し、個別の再生に適するように構成されている。たとえばオーディオ・ビデオのビットストリームにおいては、アクセスユニットは、通常は、ＭＰＥＧのＩピクチャに対応する部分となる。

ここで再びＳＯＢ＿ＧＩの内容説明に戻る。

ＡＵＤ＿ＦＬＡＧＳは、フラグＲＴＡＵ＿ＦＬＧと、フラグＡＵＤ＿ＦＬＧと、フラグＡＵＥＭ＿ＦＬＧと、フラグＰＴＳＬ＿ＦＬＧとを含んでいる。

フラグＲＴＡＵ＿ＦＬＧが０ｂのときは、該当ＳＯＢのリアルタイムデータ内にアクセスユニットフラグはないことが示される。

フラグＲＴＡＵ＿ＦＬＧが１ｂのときは、図２６（ａ）のアプリケーションヘッダエクステンション内に記述されるＡＵフラグ（ＡＵ＿ＳＴＡＲＴ、ＡＵ＿ＥＮＤ）が、該当ＳＯＢのリアルタイムデータ内に存在可能なことが示される。この状態は、下記ＡＵＤ＿ＦＬＧが０ｂの場合にも許される。

フラグＡＵＤ＿ＦＬＧが０ｂのときは、該当ＳＯＢに対してアクセスユニットデータ（ＡＵＤ）がないことが示される。

フラグＡＵＤ＿ＦＬＧが１ｂのときは、該当ＳＯＢに対してアクセスユニットデータ（ＡＵＤ）が存在し得ることが示される。

フラグＡＵＥＭ＿ＦＬＧが０ｂのときは、該当ＳＯＢにＡＵＥＭが存在しないことが示される。

フラグＡＵＥＭ＿ＦＬＧが１ｂのときは、該当ＳＯＢにＡＵＥＭが存在することが示される。

フラグＰＴＳＬ＿ＦＬＧが０ｂのときは、該当ＳＯＢにＰＴＳＬが存在しないことが示される。

フラグＰＴＳＬ＿ＦＬＧが１ｂのときは、該当ＳＯＢにＰＴＳＬが存在することが示される。

ＳＯＢ＿Ｓ＿ＡＰＡＴは、ストリームオブジェクトの開始アプリケーションパケット到着時間を記述したものである。つまり、ＳＯＢ＿Ｓ＿ＡＰＡＴにより、該当ＳＯＢに属する最初のアプリケーションパケット到着時間が示される。

このパケット到着時間（ＰＡＴ）は、２つの部分、すなわち基本部分と拡張部分に分けられる。基本部分は９０ｋＨｚユニット値と呼ばれる部分であり、拡張部分は２７ＭＨｚで測った細かい値（less significant value）を示す。

ＳＯＢ＿Ｅ＿ＡＰＡＴは、ストリームオブジェクトの終了アプリケーションパケット到着時間を記述したものである。つまり、ＳＯＢ＿Ｅ＿ＡＰＡＴにより、該当ＳＯＢに属する最後のアプリケーションパケット到着時間が示される。

ＳＯＢ＿Ｓ＿ＳＯＢＵは、該当ストリームオブジェクトの先頭ストリームオブジェクトユニットを記述したものである。つまり、ＳＯＢ＿Ｓ＿ＳＯＢＵにより、ストリームオブジェクトの先頭アプリケーションパケットの開始部分を含むＳＯＢＵが示される。

ＭＡＰＬ＿ＥＮＴ＿Ｎｓは、ＳＯＢＩ＿ＧＩの後に続くタイムマップ情報（ＭＡＰＬ）のエントリ数を記述したものである。

タイムマップ情報ＭＡＰＬは、図３（ｈ）のタイムマップ情報２５２に対応する内容を持つ。

図３０は、あるプログラム＃ｊの一部が部分的に消去（仮消去および本消去）された場合における、セルと対応時間情報（ＳＣ＿Ｓ＿ＡＰＡＴ／ＳＣ＿Ｅ＿ＡＰＡＴ；ＥＲＡ＿Ｓ＿ＡＰＡＴ／ＥＲＡ＿Ｅ＿ＡＰＡＴ）との関係例（その１）を説明する図である。

この発明の一実施の形態に係るストリーマは、図１７のところで前述したように、ストリームの一部を完全に消去する部分消去と、ストリームの一部を仮に消去（テンポラリイレーズ；ＴＥ）する仮消去とを扱うことができる。

いま、図３０（ａ）に示すようにオリジナルプログラム（ＳＯＢ＃ｎに対応）のプログラム＃ｊがセル＃ｋで構成され、このセル＃ｋがＳＯＢＵ＃１〜ＳＯＢＵ＃６で構成されているとする。このとき、セル＃ｋの開始時間がＳＣ＿Ｓ＿ＡＰＡＴで示され、その終了時間がＳＣ＿Ｅ＿ＡＰＡＴで示されている。

このようなプログラム＃ｊにおいて、ストリーマのユーザが、図３０（ｂ）に示すように、ＳＯＢＵ＃３〜ＳＯＢＵ＃４を完全に含むエリア（ＳＣ＿Ｓ＿ＡＰＡＴから始まりＳＣ＿Ｅ＿ＡＰＡＴで終わる）を仮消去セル＃ｋ＋１として設定したとする。このとき、セル＃ｋ＋１の仮消去フラグＴＥは「１０ｂ」となる。

この場合、仮消去前（図３０（ａ））のセル＃ｋのＳＯＢＵ＃１〜ＳＯＢＵ＃２に対応する部分は、仮消去後（図３０（ｂ））も変わらずセル＃ｋとなる。また、仮消去セル（ＴＥセル）＃ｋ＋１に含まれるＳＯＢＵ＃３〜ＳＯＢＵ＃４の後のＳＯＢＵ＃５〜ＳＯＢＵ＃６に対応する部分は、仮消去後（図３０（ｂ））のセル＃ｋ＋２となる。

図３０（ｂ）に示すように、仮消去セル（ＴＥセル）＃ｋ＋１は、ＳＯＢＵ＃３とＳＯＢＵ＃４との間にできるＳＯＢＵ境界を含んでいる。この場合、ＳＯＢＵ＃３内で開始する先頭アプリケーションパケットのアプリケーションパケット到着時間が、ＴＥセル＃ｋ＋１のＥＲＡ＿Ｓ＿ＡＰＡＴで示される。また、ＴＥセル＃ｋ＋１の直ぐ後に続くアプリケーションパケットを含むＳＯＢＵ＃５内で開始する先頭アプリケーションパケットのアプリケーションパケット到着時間が、ＴＥセル＃ｋ＋１のＥＲＡ＿Ｅ＿ＡＰＡＴで示されている。

図３０（ｂ）のプログラム＃ｊからＴＥセル＃ｋ＋１が本当に消去（完全消去）されると、オリジナルプログラム（図３０（ａ））ではＳＯＢ＃ｎに属していたプログラム＃ｊは、図３０（ｃ）に示すように、ＳＯＢ＃ｎとＳＯＢ＃ｎ＋１とに分かれる。

この場合、完全消去後のセル＃ｋのＳＣ＿Ｅ＿ＡＰＡＴを、ＴＥセル＃ｋ＋１のＥＲＡ＿Ｓ＿ＡＰＡＴに合わせることができる。また、完全消去後のセル＃ｋ＋１のＳＣ＿Ｓ＿ＡＰＡＴは、ＴＥセル＃ｋ＋１のＥＲＡ＿Ｅ＿ＡＰＡＴに合わせることができる。

このようにＳＣ＿Ｓ＿ＡＰＡＴおよびＳＣ＿Ｅ＿ＡＰＡＴだけでなくＥＲＡ＿Ｓ＿ＡＰＡＴおよびＥＲＡ＿Ｅ＿ＡＰＡＴも用いる理由を以下に述べる。

ＴＥセルは、２種類の特別なＡＰＡＴ、すなわちＳＣ＿Ｓ＿ＡＰＡＴ／ＳＣ＿Ｅ＿ＡＰＡＴとＥＲＡ＿Ｓ＿ＡＰＡＴ／ＥＲＡ＿Ｅ＿ＡＰＡＴを持つことができる。それは、ＴＥセル内のＳＯＢＵ（図３０（ｂ）ではＳＯＢＵ＃３〜ＳＯＢＵ＃４）を、記録中に再利用できるようにするためである。

換言すれば、記録中に媒体（ＤＶＤ−ＲＡＭディスク）２０１が満杯になってしまったとき、ストリーマは、ＴＥセルを完全消去することにより新たな未記録状態のＳＯＢＵ（図３０（ｂ）ではＳＯＢＵ＃３〜ＳＯＢＵ＃４）を獲得し、このＳＯＢＵを用いて記録を中断なく継続する。

この「新たな未記録状態のＳＯＢＵの獲得」という目的に対しては、ＴＥセルのＳＣ＿Ｓ＿ＡＰＡＴおよびＳＣ＿Ｅ＿ＡＰＡＴだけでは不十分である。というのも、タイムマップ情報（ＭＡＰＬ）を介した検索において、割り当てられたＳＯＢＵには２つの可能な検索位置ができてしまうためである。しかし、ＥＲＡ＿Ｓ＿ＡＰＡＴおよびＥＲＡ＿Ｅ＿ＡＰＡＴを用いれば、ストリームに何ら関与することなく正確なＳＯＢＵ位置を特定できるようになる。

図３１は、あるプログラム＃ｊの一部が部分的に消去（仮消去および本消去）された場合における、セルと対応時間情報（ＳＣ＿Ｓ＿ＡＰＡＴ／ＳＣ＿Ｅ＿ＡＰＡＴ）との関係例（その２）を説明する図である。

図３１において、オリジナル記録のプログラム＃ｊは、ＴＥフラグが「００ｂ」のセル＃ｋ（開始時間はＳＣ＿Ｓ＿ＡＰＡＴ；終了時間はＳＣ＿Ｅ＿ＡＰＡＴ）で構成されている。

ここでは、仮消去セルがＳＯＢＵ境界を含まない場合（ＥＲＡ＿Ｓ＿ＡＰＡＴ／ＥＲＡ＿Ｅ＿ＡＰＡＴを）を想定している。

このプログラム＃ｊの途中の一部（ＡＰＡＴ＝ＡからＡＰＡＴ＝Ｂまでの範囲）に対して仮消去が実行されると、オリジナル記録のセル＃ｋは、セル＃ｋ（ＴＥフラグが「００ｂ」；開始時間はＳＣ＿Ｓ＿ＡＰＡＴｋ；終了時間はＳＣ＿Ｅ＿ＡＰＡＴｋ）と、セル＃ｋ＋１（ＴＥフラグが「１０ｂ」；開始時間はＳＣ＿Ｓ＿ＡＰＡＴｋ＋１；終了時間はＳＣ＿Ｅ＿ＡＰＡＴｋ＋１）と、セル＃ｋ＋２（ＴＥフラグが「００ｂ」；開始時間はＳＣ＿Ｓ＿ＡＰＡＴｋ＋２；終了時間はＳＣ＿Ｅ＿ＡＰＡＴｋ＋２）に３分割される。

仮消去（ＴＥ）実行後、オリジナルセルを再編成すると、図３１の中段に示すように、プログラム＃ｊは再びＴＥフラグが「００ｂ」のセル＃ｋ（開始時間はＳＣ＿Ｓ＿ＡＰＡＴ；終了時間はＳＣ＿Ｅ＿ＡＰＡＴ）となる。

ここで、仮消去（ＴＥ）動作はオリジナルＰＧＣ情報の内容には影響せず、ストリームファイル情報ＳＦＩの内容は変更されず残される。

一方、ユーザ定義ＰＧＣ情報は、変更されないか、あるいはユーザ定義セルがＴＥセルを参照しないように修正できる。

仮消去の主な動作は、プログラム＃ｊ内で実行される。仮消去は、プログラム＃ｊのセルを、通常のストリーム部（消去されていない部分）および仮消去部をカバーする部分に分割することで実行される。

ユーザ定義ＰＧＣ情報の内容を変更せずにそのままにしておく場合は、ＴＥ動作の再構成後も、ナビゲーションデータは仮消去前の状態と全く変わらない。

情報記憶媒体２０１の未記録領域を使いきり記録スペースが不足すると、仮消去セル＃ｋ＋１は完全消去される。すると、図３１の下段に示すように、仮消去時のセル＃ｋは完全消去後にも変更されずセル＃ｋとなるが、仮消去時のセル＃ｋ＋２は完全消去後にセル＃ｋ＋１となる。

図３２は、オリジナルＰＧＣあるいはユーザ定義ＰＧＣで指定されるセルと、これらのセルに対応するＳＯＢＵとが、タイムマップ情報によってどのように関係付けられるかを例示する図である。

ユーザ定義ＰＧＣは自身のＳＯＢを含まないが、オリジナルＰＧＣ内のＳＯＢを参照する。それゆえ、ユーザ定義ＰＧＣはＰＧＣ情報を用いることのみで記述できる。このことは、ＳＯＢデータを何らいじることなく任意の再生シーケンスが実現可能なことを意味する。

ユーザ定義ＰＧＣはまた、プログラムを含まず、オリジナルＰＧＣ内のプログラムの一部に対応したセルの連なり（チェーン）で構成される。

このようなユーザ定義ＰＧＣの一例が、図３２に示されている。この例は、ＰＧＣ内のセルがオリジナルＰＧＣ内のＳＯＢを参照するようにユーザ定義ＰＧＣ＃ｎが作成されている場合を示す。

図３２において、ＰＧＣ＃ｎは４つのセル＃１〜＃４を持っている。そのうち２つはＳＯＢ＃１を参照し、残りの２つがＳＯＢ＃２を参照している。

ユーザ定義ＰＧＣ内のセルからオリジナルＰＧＣへ（ＳＯＢＩのタイムマップ情報へ）の実線矢印は、該当セルに対する再生期間を示している。ユーザ定義ＰＧＣ内のセル再生順序は、オリジナルＰＧＣにおける再生順序と全く異なってもよい。

任意のＳＯＢおよびそのＳＯＢＵの再生は、図３２の開始ＡＰＡＴ（Ｓ＿ＡＰＡＴ）および終了ＡＰＡＴ（Ｅ＿ＡＰＡＴ）により特定される。

ＳＯＢあるいはＳＯＢＵのＳ＿ＡＰＡＴは、該当ＳＯＢのストリームパックのペイロード（図８（ｂ）参照）内に記録されたタイムスタンプに関係して定義される。ＳＯＢの記録中、各到来アプリケーションパケットには、ストリーマ内のローカルクロックリファレンスによりタイムスタンプが付される。これが、アプリケーションパケット到着時間（ＡＰＡＴ）である。

ＳＯＢの先頭アプリケーションパケットのＡＰＡＴはＳＯＢ＿Ｓ＿ＡＰＡＴとして記憶される。全てのＡＰＡＴの４最下位バイト（4 least significant bytes）は、〜．ＳＲＯファイル内の対応アプリケーションパケット用に予め固定されている。

ＳＯＢあるいはＳＯＢＵのデータを再生するために、ストリーマ内部のリファレンスクロックはＳＣＲ値にセットされ、その後クロックが自動的にカウントされる。このＳＣＲ値は、再生が始まる最初のストリームパック内（パックヘッダ内）に記述されている。このクロックに基づいて、ＳＯＢあるいはＳＯＢＵからの全ての後続アプリケーションパケットの再生・出力が、実行される。

任意のストリームセル（ＳＣ）が、そのＳＣがポイントするＳＯＢのＳＯＢ＿Ｓ＿ＡＰＡＴとＳＯＢ＿Ｅ＿ＡＰＡＴとの間の任意の値を持つストリームセル開始ＡＰＡＴ（ＳＣ＿Ｓ＿ＡＰＡＴ）を規定しているときは、所望のＡＰＡＴを伴うアプリケーションパケットを含んだＳＯＢＵを見つけるためのアドレスが必要となる。

ＳＯＢＵ１個あたりのストリームパックの数は一定であるが、各ＳＯＢＵにより捕らえられた到着時間の間隔はフレキシブルである。それゆえ、各ＳＯＢは、該当ＳＯＢのＳＯＢＵの到着時間間隔が記述されたタイムマップ情報（ＭＡＰＬ）を持つ。つまり、タイムマップ情報（ＭＡＰＬ）により実現されるアドレス方式は、任意のＡＰＡＴをファイル内の相対論理ブロックアドレスに変換して、所望のアプリケーションパケットを見つけることができるＳＯＢＵをポイントする。

図３３は、各ストリームオブジェクト（ＳＯＢ）を構成するＳＯＢＵの内容が、図３のデータエリア２０７（図１ではデータエリア２１〜２３）にどのように記録されるかを例示する図である。ここでは、ＳＯＢが記録されるときにＳＯＢをどのようにアロケートするかを説明する。

情報記憶媒体（ＤＶＤ−ＲＡＭディスク）２０１のフリースペースを有効活用するため、図３３に示すように、媒体（ディスク）全体に分散したデータエリア内にＳＯＢをアロケートすることができる。

このようなＳＯＢを媒体（ディスク）から読み取るときは、あるデータエリアから次のデータエリアにジャンプする間、媒体（ディスク）からのデータ供給が中断する。このような場合でもＳＯＢデータの連続供給を保証するためには、ＳＯＢデータのアロケーションは次のような条件で行なう。

すなわち、ＳＯＢは連続データエリア（以下適宜ＣＤＡと略記する）のチェーン内にアロケートする。ＣＤＡは基本的には媒体（ディスク）内の連続物理セクタのシーケンスとなる。

ＤＣＡの最小長およびＣＤＡ内のデータアロケーションは、各ＳＯＢを連続再生できるような再生装置モデルにより制限を受ける。

連続データエリア（ＣＤＡ）は媒体（ディスク）内の連続物理セクタである。ＣＤＡは複数のＥＣＣブロックからなる。ＣＤＡ内では、ＣＤＡ内で幾つかの物理セクタが記録時にスキップするような場合を除き、ＳＯＢデータが連続的にアロケートされる。

ＳＯＢデータがＣＤＡ内に記録される際の制限としては、以下のものがある：
（２１）ＳＯＢデータとその他のデータは、同じＥＣＣブロック内に記録しない；
（２２）ＳＯＢデータの記録中に欠陥セクタに出くわしたとしても、交替処理（リニアリプレイスメント）は用いない。

ここで、複数アプリケーションパケットを含むあるＳＯＢＵ内にセル開始ＡＰＡＴがある場合の再生について、説明を補足しておく。

セルは、ＳＯＢＵ境界に一致しないセル開始ＡＰＡＴあるいはセル終了ＡＰＡＴを持つことができる。いま、２つの連続ＳＯＢＵ＃Ｋ−１およびＳＯＢＵ＃ｋがあり、ＳＯＢＵ＃ｋ内の中間部分にセル開始ＡＰＡＴがある場合を考えてみる。

上記セル開始ＡＰＡＴにより特定されるアプリケーションパケットから一連のアプリケーションパケットの再生を開始する場合には、まず、目的のアプリケーションパケット（所望のＡＰＡＴに対応）を含むＳＯＢＵ＃ｋにアクセスする必要がある。いきなり目的のアプリケーションパケットにアクセスしないのは、タイムマップ情報（ＭＡＰＬ）によるアドレス方式がＳＯＢＵの開始アドレスしか与えない場合を想定しているからである。

所望のＡＰＡＴを見つけるためには、上記ＳＯＢＵ＃ｋ内の全てのアプリケーションパケットを初め（ＳＯＢＵ＃ｋ−１とＳＯＢＵ＃ｋとの境界）からスキャンしなければならない。このスキャンにより所望のＡＰＡＴが見つかれば、見つかった位置から以後のアプリケーションパケットの再生出力が、それらのアプリケーションパケットのタイムスタンプ（ＡＴＳ）にしたがって開始される。

以上説明したように、この発明の実施の形態における効果をまとめると、以下のようになる。

１．情報記憶媒体上に記録するストリームデータを所定サイズのストリームブロック単位（あるいはＳＯＢＵ単位）で構成し、そのストリームブロック単位で記録・消去するため、ストリームブロック先頭位置のアドレス割り出しが非常に容易となり、再生時のアクセス制御がしやすくなる。（図１４のＳ１２に示すように再生時には、ストリームブロック先頭位置から再生を開始する。）
２．情報記憶媒体上に記録するストリームデータを所定サイズ（たとえば３２セクタ６４ｋバイト）のストリームブロックで構成し、同一ストリームブロック内ではタイムスタンプやデータパケット（トランスポートパケット）が異なるセクタを跨いで記録できるため、セクタサイズ（２０４８ｋバイト）よりも大きなサイズのデータパケット（トランスポートパケット）を記録することができる。

３．情報記憶媒体としてＤＶＤ−ＲＡＭディスクが用いられる場合には、１６セクタ毎にＥＣＣブロックが構成され、そのＥＣＣブロック内ではデータのインターリーブ（並び替え）とエラー訂正用コードが付加されている。そのため、ＥＣＣブロック内の特定のセクタのみを消去し、あるいは書き換え、もしくは追記するためには、一度ＥＣＣブロック内の全データを読み取り（リード）、バッファメモリ内で再並び替え（デインターリーブ）を行った後、特定セクタ分のデータを消去あるいは書き換え、追記を行い（モディファイ）、再度インターリーブ（並び替え）とエラー訂正用コードを付加して記録する（リード・モディファイ・ライト）と言う処理が必要となる。この処理は非常に時間が掛かりストリームデータの記録や部分消去が実時間で行えないと言う問題がある。

それに対してストリームブロックサイズをＥＣＣブロックサイズの整数倍（たとえばＳＯＢＵ＝２ＥＣＣブロックサイズ）にして、ストリームブロック単位（ＳＯＢＵ単位）で記録、部分消去を行う。このため、リード・モディファイ・ライト処理が不要となり、直接ＥＣＣブロック単位で情報記憶媒体上に上書きが可能となる。その結果、ストリームデータの記録あるいは部分消去の処理が高速で行え、実時間処理（リアルタイム処理）が可能となる。

４．ストリームブロック毎に独自のヘッダ情報（ストリームブロックヘッダあるいはアプリケーションヘッダ）を持たせることにより、ストリームデータ再生時にはストリームブロック先頭位置から再生を開始することが可能となる。そのため、ストリームデータ記録再生装置（ストリーマ）では早い時期にストリームブロックヘッダを読み取ることで再生したストリームデータ処理を容易にすることができる。

５．上述したように基本的にストリームブロック先頭位置から再生を開始するが、希なケースとしてストリームブロック内の２番目以降のＥＣＣブロック先頭位置から再生を開始する場合があり得る。

図１において同一のトランスポートパケットｄが２個のセクタ（セクタＮｏ．０とセクタＮｏ．１）に跨って記録されている例に示すように、２番目以降のＥＣＣブロック先頭位置から再生を開始した場合には、何処に次のタイムスタンプ情報が記録されているかを知る必要がある。

各セクタの先頭位置に独自のヘッダ情報（セクタデータヘッダあるいはアプリケーションヘッダ）を配置させ、その中にファーストアクセスポイント６５１（あるいは図１２（ｃ）のＦＩＲＳＴ＿ＡＰ＿ＯＦＦＳＥＴ）を記録することで、ストリームブロック内の２番目以降のＥＣＣブロックの先頭位置から再生開始を容易にすることができる。

６．図１（ｊ）に示すように、ストリームブロック＃２内に記録するストリームデータの最後にはエンドコード３２が付けられている。しかし、情報記憶媒体からのデータ再生時にＥＣＣブロック毎のエラー訂正ミスあるいはストリームデータ記録再生装置内でのデータ転送エラーによりエンドコード３２が読めない場合、パディングエリア３８内にもストリームデータが記録されていると誤解釈されて間違った映像が表示される危険性がある。

図１０のＰＥＳヘッダ６０１（あるいはストリームＰＥＳパケットヘッダ）のストリームＩＤ６０３（あるいはサブストリームＩＤ）を”１０１１１１１０”にしてセクタＮｏ．７９をパディングパケット４０とした場合には、パディングエリア３８内にもストリームデータが記録されていると誤解釈されてデータ転送された場合でもエンコード部（ビデオエンコード部４１６、オーディオエンコード部４１７、ＳＰエンコード部４１８）でパディングパケット４０と理解され、読み飛ばしてくれる。

以上のようにパディングパケット４０（あるいは図２６（ｉ）のスタッフィングパケット）を設定することで、エンドコード３２が読めずにパディングエリア３８を誤認識した場合でも間違った映像を表示する危険性を大幅に低下させることができる。

７．オリジナルセルで指定される領域範囲を、ストリームオブジェクトで指定される領域範囲と等しいか、それより小さくする。このように部分消去後の残存したストリームオブジェクト内の再生範囲を指定することで、ユーザは、見かけ上、任意の範囲を、精度良く、部分消去の範囲として設定できる。

なお、この発明は上記各実施の形態に限定されるものではなく、その実施の段階ではその要旨を逸脱しない範囲で種々な変形・変更が可能である。また、各実施の形態は可能な限り適宜組み合わせて実施されてもよく、その場合組み合わせによる効果が得られる。

さらに、上記実施の形態には種々な段階の発明が含まれており、この出願で開示される複数の構成要件における適宜な組み合わせにより種々の発明が抽出され得る。たとえば、実施の形態に示される全構成要件から１または複数の構成要件が削除されても、この発明の効果あるいはこの発明の実施に伴う効果のうち少なくとも１つが得られるときは、この構成要件が削除された構成が発明として抽出され得るものである。

２０１…情報媒体、４０１…エンコード部、４０２…デコード部、４０４…メインＭＰＵ、４０９…ディスクドライブ部。

Claims (4)

1. ＭＰＥＧトランスポートストリームのストリームデータを記録したデータブロックを有するデータエリアおよびこのストリームデータの管理情報を記録した管理エリアを持つ情報記憶媒体において、
   前記データブロックには前記ストリームデータを格納する部分が含まれ、
   前記ストリームデータを格納する部分がタイムスタンプ付きトランスポートパケットにより埋められ、前記ストリームデータはユーザに認識できない内部情報を記録できるように構成され、
   前記タイムスタンプが、前記タイムスタンプ付きトランスポートパケットの到着時間情報を記述するように構成され、
   前記管理情報はタイムマップ情報を含み、
   前記タイムマップ情報が、所望のパケットを見つけるために前記トランスポートパケットに付された前記到着時間情報を相対論理アドレスに変換するように構成された情報記憶媒体。
2. ＭＰＥＧトランスポートストリームのストリームデータを記録するデータブロックを有するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、前記データブロックには前記ストリームデータを格納する部分が含まれ、前記ストリームデータを格納する部分がタイムスタンプ付きトランスポートパケットにより埋められ、前記ストリームデータはユーザに認識できない内部情報を記録できるように構成され、前記タイムスタンプが前記タイムスタンプ付きトランスポートパケットの到着時間情報を記述するように構成され、前記管理情報はタイムマップ情報を含み、前記タイムマップ情報が所望のパケットを見つけるために前記トランスポートパケットに付された前記到着時間情報を相対論理アドレスに変換するように構成された情報記憶媒体を用いる記録方法において、
   前記データエリアに前記ストリームデータを記録し、前記管理エリアに前記管理情報を記録する記録方法。
3. ＭＰＥＧトランスポートストリームのストリームデータを記録したデータブロックを有するデータエリアおよびこのストリームデータの管理情報を記録する管理エリアを持つものであって、前記データブロックには前記ストリームデータを格納する部分が含まれ、前記ストリームデータを格納する部分がタイムスタンプ付きトランスポートパケットにより埋められ、前記ストリームデータはユーザに認識できない内部情報を記録できるように構成され、前記タイムスタンプが前記タイムスタンプ付きトランスポートパケットの到着時間情報を記述するように構成され、前記管理情報はタイムマップ情報を含み、前記タイムマップ情報が所望のパケットを見つけるために前記トランスポートパケットに付された前記到着時間情報を相対論理アドレスに変換するように構成された情報記憶媒体を用いる再生方法において、
   前記管理エリアから前記管理情報を再生し、前記データエリアから前記ストリームデータを再生する再生方法。
4. ＭＰＥＧトランスポートストリームのストリームデータを記録したデータブロックを有するデータエリアおよびこのストリームデータの管理情報を記録した管理エリアを持つものであって、前記データブロックには前記ストリームデータを格納する部分が含まれ、前記ストリームデータを格納する部分がタイムスタンプ付きトランスポートパケットにより埋められ、前記ストリームデータはユーザに認識できない内部情報を記録できるように構成され、前記タイムスタンプが前記タイムスタンプ付きトランスポートパケットの到着時間情報を記述するように構成され、前記管理情報はタイムマップ情報を含み、前記タイムマップ情報が所望のパケットを見つけるために前記トランスポートパケットに付された前記到着時間情報を相対論理アドレスに変換するように構成された情報記憶媒体を用いる再生装置において、
   前記管理エリアから前記管理情報を再生する手段と、前記データエリアから前記ストリームデータを再生する手段を具備した再生装置。

Images