JPH08511148A - ソフトウェア担体の再生時の選択された言語での映画サブタイトルの表示 - Google Patents

Abstract

(57)【要約】 光ディスク（２３）上で、記録されている複数のサブタイトル・トラックのうちの選択されたトラックを映画と同期させて再生するシステム。複数のサウンドトラックを含むか否かにかかわらず、同じ映画に多数の言語の個別のサブタイトル・トラックを提供することができる。ユーザは、自分の言語が利用できる場合はその言語のサウンドトラックを選択することができる。そうでない場合は、選択した言語でサブタイトルを表示することができる。

Description

【発明の詳細な説明】 ソフトウェア担体の再生時の選択された言語での映画サブタイトルの表示 本発明は、ソフトウェア（たとえば映画）担体の再生時のサブタイトル（字幕 ）の表示に関し、詳細には、表示すべき１つの言語を選択する構造を含む、複数 の言語のサブタイトルを同じ担体上に記録する技法に関する。発明の背景 映画を配給するために最も広く使用されている媒体はビデオカセットである。 従来の慣習では、各ビデオカセット上に１つの言語サウンドトラックしか提供さ れない。同様に、サブタイトル、たとえば、フランスで配給すべき「英語」映画 用のフランス語サブタイトルを提供する場合は、その言語のサブタイトルしか表 示されない（２つの言語のサブタイトルは可能ではあるが、この場合、ビデオが さらに大きな妨害を受けることは自明である）。これは、それぞれの異なる国で 映画を配給するには、同じ「外国」映画のそれぞれの異なるオーディオ・バージ ョンおよびサブタイトル・バージョンを作成しなければならないことを意味する 。 ダイアローグ言語とサブタイトル言語の各組合せごとに同じ映画のそれぞれの 異なるダイアログ言語・サブタイトル言語バージョンを作成するのではなく（２ ０個のダイアローグ言語のそれぞれが他の１９個の言語のサブタイトルを有する 場合、３８０個の異なるダイアローグ／サブタイトル・バージョンが必要になる ）、それぞれの異なるダイアローグ言語を含む複数のサウンドトラック、および 複数の言語サブタイトル・キャプションを同じ担体上に提供する方がずっと有利 である。この場合、同じ映画の作成する必要があるバージョンの数はずっと少な くなる。しかし、記憶要件が高いために、これが実際的であることは立証されて いない。 ディジタル的にコード化された光ディスクは理論上、映画およびその他の形態 の表現の配給に関してはビデオカセットよりもずっと優れている。特に「圧縮ビ デオ」を使用すると有利であり、これによって、今日のオーディオＣＤ以下の大 きさのディスク上に映画をディジタル的にコード化することができる。圧縮ビデ オ・システムの開発には多大な努力が払われているが、複数のサウンドトラック および複数のサブタイトルを同じソフトウェア担体上に提供することに関する研 究はほとんど行われていない。 したがって、本発明の目的は、複数の言語のサブタイトルを伴う映画が記録さ れた、光ディスクなどのソフトウェア担体を再生するシステムおよび方法を提供 することである（本明細書では、複数のダイアローグ言語サウンドトラックを提 供することについて説明するが、これは、複数のサブタイトル言語を提供するこ とと組み合わせる場合を除いて請求の範囲には含まれない）。発明の概要 本発明を要約する前に、本発明が、それぞれの異なる言語映画サウンドトラッ クおよびサブタイトルだけでなく、様々なオーディオ表現およびサブタイトル表 現のデータ効率的な記憶および回復をも構想するものであることを理解されたい 。たとえば、複数のサウンドトラックおよびサブタイトル・キャプションに同じ マテリアルの教育バージョンおよびテスト・バージョンを含めることができ、お そらく複数の専門知識レベルに関する教育バージョンおよびテスト・バージョン が存在することができる。したがって、本発明の目的が、映画（ビデオおよびオ ーディオ）に同期し、言語に関してのみ異なるとは限らない、複数のサブタイト ル・シーケンスを提供することであることを理解されたい。本発明が特定の媒体 に限らず、本発明の例示的な実施例の光ディスクだけでなくテープ担体およびす べてのディジタル記憶媒体にも応用できることも理解されたい。本発明は、映画 の配給にも限らない。たとえば、極端なケースでは、本発明は「動き」のない静 止画像のライブラリの配給に応用することができる。したがって、「サブタイト ル・トラック」および「サブタイトル・シーケンス」の語は、それぞれの異なる 言語の映画サブタイトルよりもずっと多くのものを包含し、したがって、「ソフ トウェア出版社」は映画会社よりもずっと多くのものを包含し、「担体」の語は ディジタル・コード化光ディスクよりもずっと多くのものを包含する。「サブタ イトル」の語は、本明細書では、画像上の任意の位置に表示される任意のテキス トを指す。 本発明の例示的な実施例は、映画トラックに同期する複数のオーディオ・トラ ックおよび複数のサブタイトル・トラックを含む光ディスクである。ユーザは、 １つのオーディオ・トラックを選択し、たとえば、映画のフランス語バージョン を聞きたい場合はフランス語トラックを選択する。ユーザの言語のオーディオ・ トラックがない場合、この選択は特に重要ではない。そのような場合により重要 なことは、サブタイトル言語の選択である。 ディスクは、利用可能なサブタイトル言語を識別する一連のコードを導入区域 内に含む。提供することができるサブタイトル・トラックは最大で９９個である 。ユーザが再生装置を、選択されたトラック中のサブタイトル・シーケンスを読 み取ることによって所望の言語のサブタイトルを生成するように制御できるよう に、ディスク上でどの言語が利用できるかを識別する必要がある。 ソフトウェア担体上に記録される情報は、別々に識別できるブロックに記録さ れる。これは、ビデオにも、すべての同期オーディオにも、すべてのサブタイト ルにも当てはまる。各ブロックは、ブロック中のどのサブタイトル・トラックが 更新情報を含むかを示すものを含む。一般に、サブタイトル・キャプションは、 生成された後、表示されたままになる。新しいサブタイトルで置き換えられるか どうかにかかわらず、サブタイトル・キャプションが削除されるのは、担体から 新しいサブタイトル・データが読み取られたときだけである。それぞれの言語特 有のサブタイトル情報が処理中のブロック内にあるかどうかを再生装置が判定で きるようにするのに必要なのは、ブロックの始めにある各サブタイトル・トラッ クごとの単一のビットだけである。 下記で本発明の他の特徴について説明する。たとえば、スペイン語再生装置お よび光ディスクを購入するスペイン国民は、「外国」映画のスペイン語サブタイ トルを見たいと仮定することができる。したがって、スペインで販売される再生 装置は、ディスク上でスペイン語サブタイトル・トラックが利用できる場合、デ フォルトではこのスペイン語サブタイトル・トラックを再生すべきである（とも かくサブタイトルは必要であると仮定する）。デフォルト言語が利用できず、あ るいはユーザが実際に、異なる言語のサブタイトルを見たい場合にのみ、利用可 能な言語のうちの１つを選択することをユーザに要求すべきである。データをど のようにソフトウェア担体上に記憶するかと、どのようにデータにアクセスし、 それを再生するかについて下記で詳しく論じる。 本発明は数多くの優れた特徴を提供するシステム全体に亙る前後文脈の中に開 示されている。添付の請求の範囲は特別な特徴に向けられているが、全体システ ムは以下説明する。以下の説明において特に関心のある特徴の全リストは： ・ビデオ標準及び領域的ロックアウト。 ・多重アスペクト比での再生。 ・多重バージョン、例えば、同一ディスクからの同一映画のＰＧ（ パーレンタルガイダンス：親同伴）等級及びＲ（制限付き）等級 での再生であり、選択的なＲ等級再生の自動的なパーレンタル不 能化を伴っての再生。 ・認定（検定）が済んでいない出版社又は不当と認められる出版社 が再生可能なディスクを生産することを防止する認定符号又は認 定済み符号の符号化。 ・多重言語のオーディオトラック及び多重言語のサブタイトル（説 明字幕）トラックとを、ユーザの言語選択の特定化機能を伴って 単一ディスク上に装備。 ・多重「他の」オーディオトラック、例えばその各々トラックがオ ーケストラ音楽の幾つかの構成要素を有しており、ユーザがその 所望の混合を選択する機能を伴っての装備。 ・単一担体上の上述機能の全てを可能とすべく、データブロックの 可変等級符号化、そしてトラックスイッチング及び／又はミキシ ングによるビット容量の効率使用。 本発明の更なる目的、特徴及び長所等は、図面と関連しての以下の詳細な説明 を検討することによって漸次明らかになり、その図面とは： 図１は先行技術に係るシステムを示し、現行下において入手可能な媒体再生装 置の柔軟性が欠如しており、乏しい性能の典型を示し、 図２は本発明の例証的実施例を示し、 図３は図２のシステムで再生可能な光ディスクのディジタルデータトラックの 導入部分における複数フィールドを列挙したチャートであり、 図４は図３の導入トラック区域に続くデータブロック各々における複数フィー ルドを列挙した同様なチャートであり、 図５Ａ〜図５Ｅは再生中の光ディスクの導入部トラック区域に含まれたデータ の図２のシステムによる処理を説明するフローチャートを含み、 図６はトラックの導入区域に続く図４に示されたフォーマットでのデータブロ ックの処理を説明するフローチャートであり、 図７Ａは、本発明の再生装置が映画或いは他のビデオ表出の選択されたバージ ョンの再生のために必要とされるディスクトラック上のそうしたデータブロック のみを読み出す方法を特徴付ける状態流れ図及び凡例（説明文）であり、図７Ｂ は２つの代替バージョンの一方が、図７Ａの状態流れ図によって説明されたルー ルに従ってどのように再生され得るかを示し、 図８はビデオ信号のディジタル表現の圧縮に使用される先行技術を象徴的に示 し、 図９は３つの異なる像アスペクト比間の関係を示す。 先行技術 先行技術の複数の限定は図１のシステムによって例証される。こうしたシステ ムは、通常ＶＨＳビデオカセットであるプログラムデータの単一ソースを再生し て多重標準の内の選択された１つに合致したビデオ信号を発生すべく、現在入手 可能である。このタイプのシステムは多重標準ＶＣＲとして呼称されており、図 中には複数の独立構成要素が示されている。典型的には、ＶＨＳテープ７はその 上にＮＴＳＣ（アナログ）ビデオ信号を記録しており、そのテープがＶＨＳ再生 装置又はプレヤー５で再生される。このアナログ信号はＡ／Ｄコンバータ９でデ ィジタル形態に変換され、そして、複数の連続的なフレームのディジタル表現が ビデオフレームストア１１内に読み込まれる。それで回路１３は余分なフレーム を削除するか、或いは、選択された標準、例えばＰＡＬに合致するために必要な 追加フレームを概算して追加する。１つの標準から他の標準へ変換するために、 一般にフィールド又はフレーム内の水平ラインの数を変更する必要がある（イメ ージスケーリング又は画像拡大縮小）。これは、通常、幾つかのラインを削減す る こと、及び／又は、連続的なラインの幾つかを繰り返すか或いは平均することに よってそれらの間に挿入されるべき新しいラインを引き出すことによって達成さ れる。回路１３の主要機能は、勿論、ディジタルフレーム表現をビデオ出力とし てのアナログ形態に変換することである。 図１に示されたタイプのシステムは、一般に、ビデオ出力を劣化する。従来の ビデオカセットは、それらが１つ以上のビデオ標準をサポートしている場合、低 減された品質のビデオを送出する。１つの理由は、アナログからディジタルへ、 そして再度戻すという二重変換があるからである。他の理由としては、イメージ スケーリングが、通常、粗雑なやり方（複数ラインの削除、複数ラインの繰り返 し及び平均化）で行われるからである。しかしながら、画像を劣化させることな く、ディジタル領域内でイメージスケーリングを実行する複数の方法が知られて いる。一般的には用いられないが、その技法は先行技術であるが、本発明の例証 的実施例においても用いられるので簡単に説明することにする。 具体例を挙げると、ＰＡＬ標準は１フレームに６２５本のライン数であり、Ｎ ＴＳＣ標準は１フレームに５２５本のライン数である。画像の何れの部分も垂直 帰線期間には形成されることがないので、何れのシステムにおいても水平ライン スキャンの全てが画像情報の表示のために使用されることはない。ＰＡＬ標準に おける画像情報には１フレームにつき公称５７６本のライン数があり、ＮＴＳＣ の場合における画像情報には公称４８３本のライン数がある。 １つの標準から他の標準への変換のためには、引き続くフィールドを先ずデイ ンターレースする又はインターレース解除する。５７６本のライン数を４８３本 へ変換し或いはその逆変換して、レインターレース又は再インターレースを実行 する。これがどのようにしてなされるかは概念的に心に描くことは容易である。 例えば、ＰＡＬフレームを通る非常に薄いスライスを考える。このスライスはそ の３つのカラー成分に分解される。ＰＡＬからＮＴＳＣへの変換のためのイメー ジスケーリングは、概念上の観点から、カラーデータの５７６の複数のＰＡＬピ ース又はＰＡＬ片に基づく曲線を描いて、ＮＴＳＣ信号の各水平ラインのための データのピース又は一片を引き出すために、その曲線を４８３の複数パーツに分 割する以上の何物でもない。実際上、これは補間処理によって達成され、ディジ タル的になされる。（イメージスケーリングは、一般に、例えばＨＤＴＶからＮ ＴＳＣへ向かう場合、アスペクト比の変更をも伴う可能性があり、そして、各水 平ラインの両端での情報は刈り込まれ可能性がある。）こうして先行技術に係る システムは標準変換の準備を行い、それは柔軟性の程度に関わる。一方、図２の システムは先行技術において企図すらされなかった複数の方法に空前無比の柔軟 性を提供するものである。 本発明の例証的システム 図２のシステムは、光ディスク２３を再生するディスクドライブ２１を含む。 ディスク上に記憶されたディジタルデータはデータアウト導体２５上に現れる。 ディスクドライブの作動又はオペレーションはマイクロプロセッサディスクドラ イブコントローラ２７によって制御される。読取りヘッドはヘッド位置（ポジシ ョン）コントロール用リード線２９を通じて発せられるコマンドによって位置付 けられ、ディスク回転のスピードは速度コントロール導体３１を通じて発せられ るコマンドによって制御される。光ディスクは、通常、一定の線形速度或いは定 角速度の何れかで駆動される。（他の可能性は、複数の定角速度の内の飛び飛び の数の使用を含む。）本発明のディスクは一定線形速度で駆動されることができ て、各ビットによって取られるトラックの線形長は、１ビットがトラックの内側 部分或いは外側部分に記録されようが同一である。これは最大データの記憶に備 えるものである。定線形速度は、外側トラックが読取られ状態にある時、ディス クの回転速度は減少することを要求している。光ディスク制御のこのタイプのも のは従来技術である。例えば、ＣＤオーディオ標準もまた、ディスクが定線形速 度で回転することを要求する。 マイクロプロセッサ４１はこのシステムのマスターコントローラである。こう して、ディスクドライブコントローラにコマンドが導体４３を通じて発せられ、 そして、ディスクドライブコントローラの状態を導体４５を通じて決定する。デ ィスクドライブコントローラには他の２つの入力が設けられている。ブロック番 号／ポインタアナライザ４７は導体４９を通じてコマンドをディスクドライブコ ントローラに発し、そして、バッファフル導体５１はオア（ＯＲ）ゲート５４か ら ディスクドライブコントローラまで制御信号を引き延ばしている。此等の２つの 入力については下述することにする。（一般に、個々の導体を参照しているが、 前後関係上、此等の導体の幾つかは実は複数ビットを平行に引き延ばすためのケ ーブルであることを理解して戴きたい。例えば、オアゲート５４の出力は単一導 体５１を通じてディスクドライブコントローラまで引き延ばすことができ、ブロ ック番号／ポインタアナライザ４７はケーブル４９によってディスクドライブコ ントローラに接続されることができ、マルチビットデータが、シリアルよりかは むしろ、平行して送出され得る。） 図２のシステムの重要な特徴は、符号化資料又は符号化データの複雑さに従っ て変化する速度又はレートで、ビット情報がディスク上に記憶されることである 。これによって、データアウト導体２５上に実際に現れるビット数／秒が変化す るということを意味せず、むしろ毎秒使用されるビット数が変化することを意味 する。ビデオ情報は圧縮ディジタル形態で記憶される。図８は複数のビデオフレ ームがＭＰＥＧ１及びＭＰＥＧ２基準又は標準に従って符号化される方法を示す 。独立Ｉフレームはその全体が符号化されている。予測されたフレーム又はＰ− フレームは先行する独立フレームに基づいて予測されたフレームであり、Ｐフレ ームのために実際に要求されるディジタル情報は、実際のフレームとその予測と の間の差を単に表わす。双方向的に予測されたＢ−フレームはＩ及び／又はＰフ レームから予測されるフレームであり、この場合もまた、そうしたフレームのた めに要求される情報を伴い、実際形態と予測形態との間の差を表わす。（理解さ れ得るように、早送り及び早戻し機能は、もしも所望されれば、Ｉ−フレームを 用いることによって最良の状態で実現される。）フレームの表現に要求されるビ ット数は、そのタイプばかりではなく、表現されるべき実際のビジュアル情報に も依存する。明らかに、花のある原野を表現するよりも青空を表現する方がはる かに少ないビット数が要求される。ＭＰＥＧ標準は、画像フレームが最少限のビ ット数で符号化されることを可能とすべく設計されている。フレーム情報は一定 速度で要求される。例えば、もしも映画フィルムがディスク上においてディジタ ル形態で表現されれば、２４フレームが再生の１秒毎に表現されることとなる。 １フレームに要求されるビット数は、フレーム毎に根本的に異なる。フレームは 一 定速度で処理されていくので、１秒毎に処理（使用）されるビット数は非常に低 い値から非常に高い値まで変化し得る。こうして、複数ビットがディスクから実 際に読取られる時、それらはディスクから一定速度で読取られるかもしれないが 、それらは一定速度で処理される必然性はない。 同様な考え方は、ディスク上に記憶された如何なるオーディオに対しても適応 される。如何なるデータブロックも像フレームの可変数に要求されるビット情報 を含み得る。如何なるデータブロックも、多数のオーディオトラックまでの可変 数の可変持続時間に要求されるビット情報を含み得る。（まさに１つの物理的ト ラックがある。多重オーディオトラックの基準は個々のオーディオ資料を含む時 分割スライス列とは異なる。）オーディオトラックはディジタル情報を含み、そ れはまた圧縮形態でもあり得る。これは、もしも特定のオーディオトラック用の 何れかのデータブロックに情報が記憶されていれば、それらのビット数は同一持 続時間を表わすとは限らないことを意味する。あるブロック内に表現された複数 の画像フレームに対応する任意のオーディオトラックのために記録された音声の 持続時間は、その画像フレームの持続時間である、と考え得る。これは、オーデ ィオ情報が実際に必要となる前に読取られるということを意味し、充分な量が既 に蓄積された時には、更なるオーディオ情報の読取りを停止するか、或いは、先 行しての供給過多を補償すべく、幾つかのデータブロックにはオーディオが含ま れないということを付帯条件としている。これはバッファリングの概念に至り、 即ち、オーディオバッファ５３、ビデオバッファ５５、パンスキャンバッファ５ ７、サブタイトルバッファ５９、そして上記バッファフル（又はバッファ一杯） 信号を発生するオアゲート５４に至る。 ディスクから各データブロックが読取られると、ゲート６１がもしも開であれ ば該ゲート６１を通過し、そのビットフィールドがデマルチプレクサ６３によっ て種々のバッファ及びコマンド／データ線６５を通じてマスターコントローラ４ １へ分配される。本発明の例証的実施例における各データブロックは、画像フレ ームの可変数に対応しているビデオビット情報を含んでいる。上述したように、 そこには、多量のビット数、少量のビット数、或いはビット数ではないものまで あり得る（例えば、再生される特別なディスクが如何なるビデオをも表現しない 場合）。ビデオデータの引き続くグループはビデオバッファ５５内にマーカーに よって分離されて記憶される。ビデオデコーダ６７は、導体７１を通じてデータ の新しいバッチが供給されることを欲した時に、導体６９を通じてコマンドを発 する。コマンドは安定速度で発せられるが、返答として供給されるビット数は、 処理される特定フレームに要求されるビット数に従って変化する。ディスクドラ イブからビット数が読取られる速度は、殆どのフレームに関してはそうではない が、最大限の情報を要求するフレームを融通するために充分に高速である。これ は、データブロックが実際に読取られる速度は、それらが使用される速度よりも 高速であることを意味する。しかしこれは、良好に設計されたシステムは、デー タが処理のために実際に要求されるまでは、データブロックの読取りを遅延すべ きであることを意味しない。１つの事柄のために、データが実際に要求された時 、読取りヘッドはその所望のデータブロックの最初に位置し得ないこともある。 この理由のためにバッファリングは設けられている。ビデオバッファ５５はかな りの数の引き続くフレームのためのビット情報を含み（実際の数は、当業界で公 知なように、ビット数の読取り速度や、フレームの処理速度等に依存している） 、ビデオデータブロック情報はビデオデコーダ６７によって決定される一定フレ ーム速度でビデオバッファから読取られる。ビデオデータはそのバッファだけに 、該バッファが一杯（ＦＵＬＬ）になるまで送出される。一度、バッファが一杯 になると、記憶することが不可能となるので、それ以上の情報が送出されるべき ではない。ビデオバッファが一杯のとき、導体６９上の信号はオアゲート５４の 出力をハイ（ＨＩＧＨ）として、ディスクドライブコントローラ２７に複数のバ ッファの内の１つが一杯であることを知らせる。 同様の所見は他の３つのタイプのバッファに適用される。（単一のサブタイト ルバッファ５９、単一のパンスキャンバッファ５７、多数のオーディオバッファ ５３があり、これら全ての目的は下述する。）此等バッファの何れかが一杯にな った時、その対応する出力はオアゲート５４にそのバッファフル導体を制御させ てハイとさせて、複数のバッファの内の１つが一杯である旨をディスクドライブ コントローラに知らせるようにする。オーディオバッファ５３及びサブタイトル バッファ５９は、ビデオバッファ５５のための説明と同等の態様又は方法をもっ て作 動する。オーディオプロセッサデコーダ７１は、オーディオトラックデータを要 求する時にオーディオバッファに対してコマンドを発し、その時に該オーディオ バッファはそうしたデータを供給する。同様に、グラフィックスゼネレータ７３ はサブタイトルバッファ５９からデータを検索し、パンスキャンプロセッサ／垂 直スケーラ８７は、下述するように、パンスキャンバッファ５７からデータを受 け取る。 ４つのバッファの内の任意の１つが一杯になったとき（上記ブロック５３内の 個々別々のバッファの任意の１つも含む）、ディスクドライバコントローラ２７ はディスクドライブのデータ読取りを停止させる。バッファの全てがそれを受け 付けることができるまで、即ちバッファの何れもが一杯ではなく且つ導体５１が ロー（ＬＯＷ）となるまで、再度のデータの読取りは行われない。（逆に、もし もバッファがあまりにも急速に空乏状態となるのであるなら、導体上３１の速度 制御信号を調整して、ディスク速さ及びそれによるバッファが満たされる速度を 増大する。） バッファリングのこの議論は、ディスクドライブコントローラ２７へのバッフ ァフル入力５１の検討から起こった。説明を加えるべく残された他の入力は、ケ ーブル４９によって表されるものである。下述するように、各データブロックは 、その始めにおけるポインタ情報と共に、連続的なブロック番号を有する。回路 ４７は連続的なブロック番号を読取り、そのポインタ情報を解析する。ポインタ は、即ち連続的なブロック番号は、読取れるべき次のデータブロックを指向する 。この情報はケーブル４９を通じてディスクドライブコントローラに供給される 。この様にして、ディスクドライブコントローラはディスクドライブの読取りヘ ッドの位置付けを制御できるので、所望のデータブロックにアクセスされ得る。 しばしば、間違ったブロックが読取られることがあり、これは、例えば、ＣＤオ ーディオディスクの再生中に１つのトラックから他のトラックへジャンプをなす 際の場合のように、新しいブロックへのジャンプの場合に経験されるものである 。もしもディスクドライブが、あまりにも高いか或いはあまりにも低いかする連 続的ブロック番号のデータブロックを読取ろうとしたならば、これはブロック番 号／ポインタアナライザ４７によって決定されてから、ケーブル４９を通じて新 しいコ マンドがディスクドライブコントローラに発せられ、より低いブロック番号か或 いはより高いブロック番号の他のブロックを読取るようさせる。新しいブロック を読取るために読取りヘッドがそれ自体を位置付けしている間、読取られるデー タは実際には使用されない。ゲート６１は閉状態を保持しているので、４つのバ ッファと、コマンド／データリード線を通じてのマスターコントローラ４１とに 対する分配のために、情報はデマルチプレクサ６３へは送出されない。連続的な ブロック番号をそのブロックの最初に解析する回路４７によって決定されるよう に、正しいデータブロックに到達された時のみ、導体７５はパルス状に脈動して ハイとなってゲート６１を開とする。 ブロックの残りはそれからデマルチプレクサへ送出される。また、ディスクか ら読取られたデータビットは、導体７７を通じてマイクロプロセッサマスターコ ントローラ４１へも送出される。各データブロックは、種々のバッファへ分配さ れるべきビット情報だけではなく、例えば、そのブロック内に実際に見出される べきデータの種類を識別するビット等の制御情報をも含む。こうした識別ビット （フラッグ等の下述するもの）はマスターコントローラへ供給されることによっ て、常にシステムの制御下にある。識別ビットはデマルチプレクサによって使用 され、種々のバッファに対するデータ分配を制御する。（マスターコントローラ は、導体７６を通じてコマンドをブロック番号／ポインタアナライザ４７に対し て発し、該アナライザ４７はこの要素に対して一般制御のみを実行するばかりか 、たくさんのデータブロックが、もしも引き続く処理が要求されていなけば、デ マルチプレクサに入ることを防止することが適切であるように、該要素４７をし て導体７５上のイネーブル信号をターンオフさせることによる特殊な制御を実行 する。） マスターコントローラはシステムの心臓であり、実際、下述するような処理の 大部分を実行する。再生装置のユーザは、典型的にはキーボードであるインター フェース７９を介してマスターコントローラと通信する。またユーザにはキー及 びロック機構が備えられ、此等を象徴的に符号８１で示し、ここでは「パーレン タルロック"PARENTAL LOCK"」オプションとして呼称する。もしもこのロックが ターンオンされれば、Ｒ（制約付き）等級映画は再生しないことになる。ディス ク上に実際に表現されたビットによって制御されるこの方法又は手法は下述する 。もしもロックがオンで、Ｒ等級画像だけがディスク上であれば、パーレンタル ロック制御導体８３上のディスエーブル信号はゲート６１を閉じる。データビッ トはゲートを通じて何等伝達されず、ディスクは再生され得ない。以下の説明で 明らかになるように、もしもディスクがその上にＲ等級でないフィルム（映画） バージョンを有すれば、観賞者又は視聴者によっての選択があればそれが再生さ れることになる。パーレンタルロックの特徴は、実際のキー及びロックの使用を 要求しているように示されているが、この特徴は子供の両親（パーレンツ"PAREN TS"）だけに知られたキーボード入力が要求されることによって実現又は履行さ れ得ることを理解して戴きたい。マスターコントローラに映画のＲ等級バージョ ンは見られるべきものではないことを知らせる方法又は手法は何れか１つの形態 に限定されない。ちょうど物理的キー及び符号化キーのようなものを代替的に使 用してコンピュータへのアクセスを制御するようにすれば、それらは図２のシス テム中に入ることができる。重要なことは、２つの異なるバージョンを同一ディ スク上に表現させ得る（各々の全バージョンを要求することなく）方法であり、 選択されたバージョンが先ず再生され得るかをシステムがどのようにして決定す るかである。これは下述することにする。 マスターコントローラ４１は、これまで説明しなかった他の幾つかの出力を含 む。導体８５は図２に示されたサブシステムの全てまで延びるマスタークロック バスを表す。如何なるディジタルシステムにおいても、マスタークロック信号は 種々の回路の適切な同調を制御するために要求される。マスターコントローラの 他の６つの出力は、デマルチプレクサ６３、オーディオプロセッサ７１、パンス キャンプロセッサ／垂直スケーラ８７、ビデオフレームストア・インターレース ・３：２プルダウン回路８９、グラフィックスゼネレータ７３、並びに、シンク ゼネレータ・ＤＶＡコンバータ９２までに延びている。此等は個々別々の回路ブ ロックの作動を制御するための制御リード線である。 オーディオプロセッサデコーダ７１はバッファ５３内のデータを処理し、個々 別々のオーディオアナログ信号を引き出し、此等は符号９１で象徴的に示された アンプ／スピーカシステムへ引き延ばされる。ビデオデコーダ６７はバッファ５ ５から読取られた圧縮ビデオデータから導体９３上にディジタルビデオ信号を引 き出す。ディジタルビデオは、フレーム毎に、パンスキャンプロセッサ／垂直ス ケーラ８７へ供給される。採用されている特別なビデオ符号化／復号化は本発明 の特徴の１つではない。好ましい基準又は標準は、ＭＰＥＧ１及びＭＰＥＧ２の 方針に従ったものとなるであろうが、此等は例証的なものでしかない。同じこと は、オーディオトラック符号化についても当てはまる。本発明は特別な符号化方 法に限定されない。 回路５７及び８７の作動は、図９の象徴的図面を先ず検討することによって最 も良く理解され得る。本発明の好適実施例における光ディスク上に記憶されたデ ィジタル情報は、１６：９の「マスター」アスペクト比を有するフレーム、いわ ゆる「ワイドスクリーン」像を特徴付ける。マスターアスペクト比は図９の左上 方に示されたものである。もしも、ユーザのテレビ受像機に表示されるべき究極 的又は根本的なアナログ信号がこのアスペクト比を要求し、（垂直帰線の間に生 じる水平走査ラインと対立するものとして）画像情報を伴う水平走査ライン数が ディスク上に記憶されたビデオビット情報によって表現される水平ラインの数と 一致するものであれば、ビデオアナログ信号の発生は簡単なものである。しかし 、ユーザのテレビ受像機が４：３アスペクト比を有するＴＶ信号に適応し、そし てディスク上のマスターアスペクト比が４：３でなくむしろ１６：９であれば、 ２つの選択肢がある。一方がオリジナル画像を「レターボックス」形態で表示す ることである。図９の右側に示されるように、この場合でなされていることは、 マスターイメージを垂直方向に均一に圧縮することによって、その水平寸法がテ レビ受像機の範囲内に嵌合する。これは、垂直寸法が同時に短縮されて、それが ＴＶ表示領域の全体高さより小さく充満することになる。これが意味するものは 、各全体フレームの上部及び下部における水平ライン走査が消去されなければな らず、それらの場所に形成された暗帯又はダークバンドを付帯条件とするが、オ リジナルアスペクト比は保存される。他のオプションは、「パンスキャン」の圧 縮アスペクト比用である。これが意味するものは、４：３アスペクト比を有する ボックスをオリジナルのワイドスクリーンイメージ上に添えることである。その 結果、画像の左側、右側、或いは両側が切り取られる。（全ての場合、たとえ１ ６：９ のマスターアスペクト比に対応するワイドスクリーン像が示されたとしても、デ ィスク上に表現された水平ラインの数とは異なる水平ライン走査の数を形成する 必要があり得る。水平ラインの数は、ビデオ出力が合致しなければならないビデ オ信号標準の関数である。ライン数を変更することは、上述したように、垂直ス ケーリングとしての公知の処理である。） パンスキャン処理に関して、図９から明らかなことは、パンスキャン圧縮アス ペクト比画像を形成するために用いられるべき１６：９マスターアスペクト比画 像のその部分を識別するために要求される全ては、使用されるべき情報の各水平 ライン走査毎の出発点を特定することである。単一番号を特定することで（例え ば、合計９６０コラムからのコラム２００）、この目的には充分である。しかし ながら、問題は常に同一コラムが使用されるものかどうかである。ある場合では 、再生装置に対して、もしも４：３アスペクト比が所望であれば、常にワイドス クリーン像の真ん中から取り出すように命令される可能性もある。他の場合では 、可変的なコラム出発点が所望される可能性がり、その場合、データブロックは 他の変更が実行されるまではその点から使用されるべき出発コラム番号を表す情 報を実際に含むことになる。 以下の説明から明らかなように、各データブロックのビデオ情報は、パンスキ ャンコラム情報が更新されるべき否かを表すフラッグを含む。もしもそうしたフ ラッグがあれば、ビデオデコーダ６７は導体９５を通じてコマンドをパンスキャ ンバッファ５７に発する。この時、そのバッファはパンスキャン更新をデマルチ プレクサ６３から受入れる。連続するフレームに伴うパンスキャンプロセッサ／ 垂直スケーラ８７による使用に供すべく、その更新は他の変更が生ずるまでその バッファ中に残存する。 パンスキャンプロセッサ／垂直スケーラ８７において、水平ラインの数は調整 され、アスペクト比は変更される。ディジタルビデオがビデオデコーダ６７によ って供給され、そして要求されれば、パンスキャン情報がバッファ５７によって 提供される。回路８７の出力は、所望されたアスペクト比であり且つ選択された テレビジョン標準用に要求された水平ライン数によって表される非圧縮ディジタ ルビデオから成る。 一度、ビデオフレーム情報がフレームストア８９内にディジタル的に記憶され ると、それは、もしも選択された標準が要求すれば、複数のインターレース状フ ィールドに解体される。また、３：２プルダウンは毎秒２４フレームの映画を毎 秒６０フィールドのビデオに変換するために用いられる技術であり（公称値２４ 及び６０は、実際には２３．９７及び５９．９４である）、映画を表すデータを ＮＴＳＣフォーマットに変換することであり、フレーム情報（データブロック） が毎秒２４のレート又は速度で読取られる必要がある。（当業界では標準である ように、そうした変換をソース資料のフレーム１に適用してビデオ信号のフィー ルド１、２並びに３にし、ソース資料のフレーム２をビデオ信号のフィールド４ 及び５にし、ソース資料のフレーム３をビデオ信号のフィールド６、７並びに８ にする等、２４のオリジナルフレームから６０フィールドをもたらす。）一方、 ＰＡＬ標準への変換は相対的に簡単であり、３：２プルダウンは要求されない。 ＰＡＬ標準は毎秒５０フィールドを要求する。フレームは毎秒２５のレートで処 理され、各フレームは２つのフィールドを形成するために使用される。（映画フ ィルムは毎秒２４フレームのレートで撮影されるにもかかわらず、ＰＡＬに変換 された際に毎秒２５のレートで処理されるので、ＴＶスクリーン上で生ずる凡ゆ ることは合衆国におけるよりはヨーロッパにおいて４％だけより速く生ずる。） フレームが毎秒２５のレート或いは毎秒２４のレートで処理されようが、バス８ ５上のマスタークロック信号の周波数を変更することによって制御される。 ブロック８９の出力はディジタルであり、シンクゼネレータ・Ｄ／Ａコンバー タ９２まで引き延ばされる。この要素内において、適当なシンク（同調）パルス が複数フィールド内に挿入され、ディジタル情報がアナログへ変換される。要求 される任意のサブタイトルはバッファ５９に含まれている。マイクロプロセッサ ４１の制御下、コマンドが制御リード線９７を通じてグラフィックスゼネレータ ７３へ発せられる。この従来的な回路はサブタイトルバッファから符号化キャラ クタ情報を検索し、そうしたサブタイトルを示すビデオ信号を導体９９上に発生 する。キー信号は導体９８上で発生され、此等の２つの信号は従来のキーヤ回路 ９６まで引き延ばされる。この装置はビデオイメージにサブタイトルを合併し（ 当業界では公知なように、製造業者のオプションとしてハードキー或いは線形 キーを利用する）、そしてそのコンポジット信号を従来のＴＶ表示装置９４まで 引き延ばす。 導入部トラックフィールド 詳細処理の説明に進む前に、ディスクトラックの導入部分に記憶された情報を 検討することが参考になるであろう。この情報は図３の示された個々のフィール ドに記憶されており、ディスクから読取られたデータの引き続く処理を制御する のがこの情報である。データブロックのフォーマットは図４に示されているが、 このブロックのデータがどのようにして使われるかを理解するために、最初に読 取られたセットアップ情報を評価することが必要である。 図３において、トラックの最初に多くの導入シンクビットがある。他の全ての 記載項目又はエントリーのためにビットの最少数及び最大数がその適切なコラム に示されているが、そうした数は導入シンクビットには設けられていない。トラ ックの始めに要求されるシンクビットの数は採用されたハードウェアに依存する 。もしも特定のハードウェア及びディスクスピードの範囲が包含されたならば、 充分な数のシンクビットがトラックの最初に設けられて、ディスクドライブ、コ ントローラ２７並びにブロック番号／ポインタアナライザ４７等を含む各種回路 がディスク読取りに関係させられ、それら自体をデータアウト導体２５上のビッ トストリームに同期させるようにする。ビット同期はディジタルシステムにおい て良く知られた技術である。 第２フィールドは認定（検定）済み領域を表す４０ビットから成る。ソフトウ ェア出版社が彼等のソフトウェアの再生を締め出すこと又はロックアウトするこ とができる幾つかの方法がある。最も重要なことは、Ｒ等級映画が再生され得る かどうか（上記パーレンタルロックアウト・オプション）、そして、最終のアナ ログ出力ビデオ信号はユーザによって選択された標準を仮定しているかどうか、 を制御することを含む。このようにして、例えば、ソフトウェア出版社は映画を ＮＴＳＣ受像機では再生され得るが、ＰＡＬ受像機では再生され得ないようにす ることができる。しかし、再生装置にこの種のロックアウト制御が設けられてい る限り、複数の領域に達し得る。本発明のディスクが用いられる全ての再生装置 は、 規格書の同一セットと合致する。その設計の１つの特徴は、各再生装置には販売 のために意図された領域或いは複数領域の表示が設けられている。例えば、その 領域或いは複数領域は、ＤＩＰスイッチ、マイクロプロセッサＲＯＭ（例えば、 マスターコントローラ４１）内に記憶された符号（コード）等の設定によって表 現され得る。合計４０通りの領域があるものと仮定する。各ディスクはその導入 区域に４０ビットフィールドを有し、その各ビットは上記４０領域の１つと関連 する。任意のビット位置での１は、ディスクはそれぞれの領域内での再生が認定 （検定）済み又は正しいものと認められていることを指示し、０（ゼロ）はその 否定を指示する。中国での販売用を指示するコード又は符号の再生装置は、例え ば、もしもその４０ビット領域における中国関連の位置が０であれば、ディスク を再生できないことになる。 そうした特徴の使用例として、特定の国での販売用として意図された再生装置 を考えよう。ソフトウェア出版社が、契約上の理由からその国に配給すべきでは ないある映画フィルムを出版しようとする。この理由によって、トラック導入区 域の認定領域フィールドにおけるその国に関連するビット位置には、０が記憶さ れることとなる。このビットを検知するに及んで、マスターコントローラ４１は 回路４７に禁止信号を導体７５上に発生させるようにして、ゲート６１をしてそ こを通過する全てのデータを恒久的にブロックさせるようにする。 第３フィールドはフラッグに関する単一ビットであり、該フラッグは次のフィ ールドに何か情報があるか否かを示す。この情報はここでは「特殊ソフトウェア 」と言われる。図２の再生装置は、通常、リードオンリーメモリに典型的には含 まれる同一ソフトウェアコード（符号）を実行する。図面における各種フローチ ャートに関連して説明されることになるのがこのコードである。しかしながら、 再生装置はマイクロプロセッサで制御されているので、幾らかですら全体的に無 関係の目的のためになぜ使用され得ないのかの理由がなく、そして、これはディ スクからソフトウェアを単にロードする（読み込む）ことによって可能となる。 もしも上記特殊ソフトウェアフラッグが１であれば、マスターコントローラ４１ は、導体７７上でフィールド４に即座に従うソフトウェアを読取る。こうして、 特殊ソフトウェアフラッグが０或いは１かに依存して、第４フィールドは空か或 いは 未決定長のソフトウェアを含むかである。このソフトウェアの最後にはシンクワ ードがあり、このワードは全データストリームの何処においても生ずることが許 容されていないという意味合いで独特である。シンクワードパターンが現れたと きは、先行するデータフィールドは終りにきた、そして新しいフィールドが追従 することを示している。（データがシンクワードパターンを有するにも拘らずデ ータストリーム中に現われて、シンクワードとして誤解された場合、公知の技術 を用いて回避することができる。例えば、もしもシンクワードが所定パターンの ３２ビットから構成され、そして何等かの総体的なデータシーケンスがこのパタ ーンをその中に含むものとすれば、３１ビットのデータパターンが記憶された後 に、シンクワードパターン中の最終ビットとは反対の値を有する余剰ビットをそ のビットストリーム中に挿入させ得る。再生装置はこのビットを見たとき、それ を捨てて、続くビットをシンクワードの最終ビットの代りにデータビットとして 取り扱う。） 特殊ソフトウェアの例はビデオゲームを制御するソフトウェアであるかもしれ ない。再生装置に映画及びマルチトラックオーディオの再生のための設計された オペレーティングシステムが設けられていれば、ビデオゲーム再生に含まれる追 加的及び／又は異なる複数機能を実行する再生が確かに可能である。もしもユー ザ用インターフェースが着脱自在であり、ジョイスティック（操縦桿）及びその 類が、キーボードの代りに、ゲーム再生周辺機器を適合させるべく接続できれば 、以上のことがは特に当てはまる。このシステムは、ディスクから読取られる必 須のソフトウェアを単に記憶することによってビデオゲーム再生装置に変換され 得る。下述されるフローチャートには上記特殊ソフトウェアが自己充足又は独立 した形であるが標準的な処理ステップを含まない形で示されている一方、このソ フトウェアは内蔵されたコード（符号）を利用するために実行されるオペレーテ ィングシステムのサブルーチンを確実に呼出すことができる。 第５フィールドは１２ビットの位置から成り、その各々は異なる標準に対応し ている。此等の標準とは、１２５０ラインのヨーロッパ型ＨＤＴＶ、１１２５ラ イン日本型ＨＤＴＶ、１０５０ラインで提案されたアメリカ型ＨＤＴＶ（１０８ ０ライン及び７８７ラインも共に標準として提案されている）、６２５ラインの ＰＡＬ、５２５ラインのＮＴＳＣ、６２５ラインのＳＥＣＡＭ、３６０ラインの 「レターボックス」等を含む。更なる標準を収容することも可能ですらあるが、 そうした場合には適切なビデオ信号を形成するために異なるソフトウェアが要求 されることになる。しかしながらそれは、内蔵オペレーティングシステムを増補 すべく、ディスクに対してのソフトウェアの提供を単に伴うだけである。 １つの例として、もしも上記１２ビットフィールドの第１ビット位置がＮＴＳ Ｃ標準に対応していて、更に、もしもユーザが彼のＴＶ受像機での再生用として ＮＴＳＣ標準を選択するか、或いはそれが彼の（下述する）デフォルト（既定値 ）設定であれば、認定済み標準フィールド内の第１ビットが１である時のみにＮ ＴＳＣ信号が発生されることになる。 フィールド６は常に１００ビットを含む。此等のビットは、映画用のダイアロ ーグ又は会話（対話）であるそれぞれのオーディオ言語を表す。同一映画に相当 多くの外国語バージョンが用意されることは稀であり、相当多くのバージョンを １つのディスク上に実際に含ませようとは意図されない。事実、異なる言語のダ イアローグを含むことができるオーディオトラックは最大１６のオーディオトラ ックである。上記１００ビットの第１番目を除く各々は、９９言語の１つを表す 。もしもその対応するビット位置に１があれば、その対応する言語でのダイアロ ーグに関するオーディオトラックがあることを指示している。 上記１００ビット位置の第１番目は現実には言語に対応していない。代りに、 第１ビット位置の１は、音楽及び効果（「Ｍ＆Ｅ」）トラックがあることを意味 する。（「効果」によって意味されるものは、雷、射撃及びその類に関連するサ ウンド又は音響のようなものである。）図３におけるコメント（備考）フィール ドに指示されているように、全トラックの導入区域のフィールド６にはＮ個の「 １」があり、Ｎは最大値１６を有する（１つのＭ＆Ｅトラック及び１５個までの ダイアローグトラック、或いはＭ＆Ｅ無しで１６個までのダイアローグトラック ）。１つの例として、第３ビット位置がフランス語に対応し、第５番目がギリシ ャ語に対応し、上記１００ビットフィールドが１０１０１０００．．．．０であ ることを想定しよう。これは、１つのＭ＆Ｅトラックが、フランス語及びギリシ ャ語のダイアローグトラックと共にあることを意味する。ディスク上の単一デ ータブロック各々がＭ＆Ｅや、フランス語及びギリシャ語を表すビット情報を含 む意味ではない。以上のことが意味するものは、如何なるデータブロックもＭ＆ Ｅ及び／又はダイアローグを伴うせいぜい３つのオーディオトラックを有するこ とである。また、そうしたオーディオトラック情報を有する如何なるデータブロ ックも、Ｍ＆Ｅ、フランス語、ギリシャ語の順番でそうした情報を含むことも意 味する。ただどのようにしてシステムは、どの特殊なデータブロックが上記１０ ０ビットフィールド内に表わされている言語のためのオーディオ情報を含むのか を決定するかは、データブロック内に含まれる種々のフィールドに関連させて下 述する。 言語オーディオトラックは、単なるダイアローグを必然的には含むものではな いことは理解されるべきである。簡単に説明されるように、Ｍ＆Ｅをフランス語 ダイアローグトラックに混合して、その結果がフランスでの再生に適した完全な オーディオトラックと成るようにすることは可能である。しかし、特別なオーデ ィオトラックが予め混合されたＭ＆Ｅ及びオリジナルダイアローグを含むことは 確かに可能である。例えば、もしも上記１００ビットフィールドのビット位置１ ０が英語ダイアローグを表わし、そこに１が記憶されていれば、ディスク上には オーディオの英語バージョンがあることを意味する。しかしながら、その対応す るオーディオトラック内に英語ダイアローグばかりではなく、Ｍ＆Ｅを含むフル サウンドトラックもあるようにすることは可能である。同時に、もしも上記１０ ０ビットフィールドの第１ビット位置に１があれば、別のトラックにＭ＆Ｅを設 けることもできる。任意の言語での再生用として完全なサウンドトラックを引き 出すために、種々のトラックをどのように処理するかは、その後に続く情報に依 存する。フィールド６は単に、どのオーディオ言語が有効又は利用可能であるの かを、別にＭ＆Ｅがあるのか否か（如何なるダイアローグも無しで）と共に表わ している。 オーディオ機構又は構成を機能させるために必要な情報の他のピース又は一片 があり、その情報はフィールド７に表現されている。上記したＮ個の利用可能オ ーディオトラック（最大１６個まで）の各々のために、第７フィールドには３ビ ットコード又は３ビット符号がある。此等のコードを説明する前に、理解しても ら うべきは、此等のコードが特定トラック及び言語とどのように関連させられるか である。フィールド６は、Ｍ＆Ｅトラック、フランス語トラック、ギリシャ語ト ラック並びに英語トラックがあることを意味すると理解される１０１０１０００ ０１００．．．．０であると想定する。この情報だけからは、フランス語トラッ ク、ギリシャ語トラック、並びに英語トラックの中に何等かのＭ＆Ｅでさえもあ るのかどうかを見分ける方法ない。言語に関して知られることの全ては、ダイア ローグは３つの言語のみで利用可能であることである。この例の場合、フィール ド７には１２ビットがあることになる。第１の３ビットはＭ＆Ｅトラックに関連 し、第２の３ビットはフランス語トラックに関連し、第３及び第４の３ビットコ ードはギリシャ語トラック及び英語トラックにそれぞれ関連する。３ビットコー ドは次の通りである： ０００−−ミキシングマスター（Ｍ＆Ｅ） ００１−−スイッチングマスター（Ｍ＆Ｅ） ０１０−−ダイアローグ＋（Ｍ＆Ｅ）、完全オーディオトラック ０１１−−ミキシングマスターと混合されるべきトラック １００−−スイッチングマスターと混合されるべきトラック 此等５つのコードは３つの利用可能言語、フランス語、ギリシャ語、並びに英語 での完全なサウンドトラックを形成するのに必要な全てである。此等のトラック をどのようにして組合わせるかは下述されるが、心に留めるべきことは、この全 体構成の目的は、何が各々のために２時間のオーディオ記録となり得るかを要求 することなく、多くの言語（１５まで）でのサウンドトラックを提供することで ある。実際、もしも映画が２時間の長さであるが、実際のダイアローグはたった ３０分であれば、その行き着く先は１つの全トラック（Ｍ＆Ｅ或いはオリジナル サウンドトラック）を特定言語のダイアローグが録音されたたった３０分のオー ディオで記録することである。 フィールド８はＮ×４ビット、即ち、フィールド６におけるＮ個の「１」の各 々に対して４ビットを含む。ディスク上で利用可能な各オーディオ言語に対して 、フィールド８ではこうして４ビットコードがある。この４ビットコードはトラ ックタイプを表わし、最大１６の可能性がある。典型的なトラックタイプは、単 一チャネルのモノ、２−チャネルのドルビー、５．１−チャネルのミュージィカ ム等々である。［用語５．１−チャネルとは、左、右、中央、左後方並びに右後 方の各チャネルに当てはまる。］この４ビットトラックタイプコードは、マスタ ーコントローラが、オーディオプロセッサデコーダ７１をして上記１６までのオ ーディオトラック内のデータ上で、スピーカシステム９１のためのアナログ出力 を引き出すために、どのようにオペレーションするかのやり方を決定することを 可能にするものである。 再度フィールド７を考えれば、そこには、選択された言語での完全なサウンド トラックをディスクから引き出し得る幾つかの方法がある。ミキシングのオペレ ーションは、２つのサウンドトラックをミキシング（相互加算）することを含む 。スイッチングのオペレーションは、２つのサウンドトラック間の交換を含むん で、任意の時点においてそれらの内の一方を再生する。第１トラックは、もしも 利用可能であれば、常にＭ＆Ｅである。第１トラックのためのコードは０００或 いは００１である。もしもコードが０００であれば、トラック内にはダイアロー グがなく、そのＭ＆Ｅは選択された言語トラックと混合されることを意味する。 もしもコード０１１が例えばフランス語に関連していれば、第１及び第３トラッ クが常に混合されるべきことを意味する。ダイアローグがあった時のダイアロー グはフランス語トラックに現われ、それはミキシングマスターと混合されて完全 なフランス語サウンドトラックを提供する。一方、第１トラックはスイッチング マスターであり得る。これが意味するものは、音楽及び効果はこのトラックに、 ダイアローグを伴って或いはダイアローグを伴わずに、記録されることである。 この場合のフランス語トラックは１００コードによって表わされることとなる。 それはＭ＆Ｅ及びダイアローグを含むが、ダイアローグがあった時だけである。 Ｍ＆Ｅトラック、即ち第１トラックはダイアローグがない時にだけ再生されるが 、第 ５トラックはあった時だけ再生される。此等のトラックは交換されるが、混合さ れない。フランス語トラックは、ダイアローグがその中に記録されていれば、ダ イアローグばかりではなくＭ＆Ｅも共に含むことになり、これは交換されたタイ プのオペレーションにおけるＭ＆Ｅの唯一のソースとなるからである。 第５の可能性（０１０）は、特定のトラックがたまたま、オリジナル言語での ダイアローグを伴うＭ＆Ｅであるオリジナルサウンドトラックを含んでいること である。もしもダイアローグが選択された言語であれば、そのトラックがそれ自 体によって始めから終りまで再生され得る。また、このトラックは他の言語用に スイッチングマスター（００１）としての役割も果たすことができる。 ミキシングトラックに至ったとき、その２つの特定トラック（ミキシングマス ター及びそれと混合されるべきトラック）にあるどのようなオーディオであろう が、常に此等を単純に相互に加算し、その２つのトラックにあるどのようなオー ディオであろうが再生状態となる。スイッチングマスター及びそれと交換又はス イッチされるトラックのスイッチングの時のみ、一方のトラックが他方のトラッ クの代りに再生状態となる。その他のものがオーディオ情報を含まない時にだけ （混合を許容している）、各トラックがオーディオ情報を含むことが可能である が、スイッチングマスターはダイアローグをも含む、即ちもしもそれが映画のオ リジナルサウンドトラックのレコーディング又は記録であればダイアローグをも 含むことも想像できる。それがなぜスイッチング、即ち任意の時点で一方のトラ ックのみが聞こえるようにするスイッチングが採用されるかの理由である。下述 するように、各データブロックは、マスターコントローラに対して、何れのオー ディオトラックが実際にそのブロック内にデータを含むのかを知らせるビットを 含む。もしもオリジナル１００トラックコードを伴う選択されたオーディオ言語 トラックが、任意のデータブロック内にデータを有すれば、オーディオプロセッ サデコーダ７１はスイッチングマスタートラック内にあるであろう如何なるデー タをも除外して、そのオーディオトラック内のデータを処理する。 図３のフィールド９は、ナンバーＭを表わすべくコード化又は符号化された６ ビットを含む。これは、上記１６までのオーディオ言語とは別離及び分離した「 他の」オーディオトラックの数である。此等のトラックの通常用途は、圧縮ディ ジタル形態で、個々別々の楽器或いは種々の楽器の混合を表現することであり、 ユーザ用にそれらを組合わせるオプションを伴っている。極端な形態では、６３ の分離した楽器トラックがあり得て、ユーザが所望の如何なるトラックをも組合 わせることができ、混合前にそれらの相対的レベルをセットすることができる。 先ず第一に、もしも此等トラックの１つが組合わせサウンドを含むものであれば 、オーケストラ混合から１つの楽器を削除することは、その情報内容がそのオー ケストラ混合から削除されるべきことを指定することによって可能である。これ はユーザが例えばピアノを、ピアノ演奏が削除されたコンチェルト（協奏曲）を 演奏するオーケストラの伴奏で、演奏することを可能にする。これはまたユーザ が特定の楽器をえり抜いて、練習を促進することをも可能にする。正確には、ユ ーザがその「他の」オーディオトラックを用いて行う何かは、ユーザに提供され 得るメニュー選択によって決定される。フィールド８はディスク上に幾つの「他 の」オーディオトラックが存在するのかを単に識別する。（用語「他の」オーデ ィオトラックはむしろ無描写又は非記述的なように見えるが、これは違う。趣旨 は、この用語は映画用のサウンドトラックの用途等以外の任意のオーディオトラ ック用途を包含している。此等の「他の」オーディオトラックにオーケストラ音 楽を含ませることよりはむしろ、例えば、個々の声楽家又は歌手を含ませること が可能であり、ユーザをして異なるハーモニーを学ばさせることが可能になる。 ）明らかなことは、実に６３の「他の」オーディオトラックがあり、それで、も しもディスク容量の殆どでなければ、多くのものをオーディオデータに割り当て ることができる。しかしそれは厳密には、何故にそんなに多くのオーディオトラ ックが利用可能とされるのか、である。確かに、図２のシステムで再生可能な幾 つかのディスクはビデオを含まないことは確かである。事実、フィールド１９は 、下述するものであるが、１ビットフィールドであり、マスターコントローラに 対して、ディスク上には、一体、ビデオデータは存在するのか否かを通知してい る。 Ｍ個の「他の」オーディオトラックの存在が、一度、決定されたならば、次の フィールドは各トラックをどのようにコード化するを指定する。フィールド８の 場合のように、４ビットコードを此等の「他の」オーディオトラックの各々に用 いる。こうして、フィールド１０内のビット数は０と言うように低いか（もしも 「他の」オーディオトラックが全くなければ）、或いは２５２と言うように高い （６３×４）ことがあり得る。 再生装置はフィールド９及び１０を読取ることから、そこには幾つの「他の」 オーディオトラックが存在するのかを決定することができる一方、ユーザには、 それらを用いて何をすべきかを知るために、此等のトラックには何があるのかを 告げられなければならない。各トラックには説明があり、それは多重言語である 。再生装置に与えられなければならない第１のことは、その「他の」オーディオ トラックの説明がなされている複数の言語のリストである。この目的のためには 、１００ビットフィールドが使用される。図３に示されたように、フィールド１ １は１００ビットを有する。任意のビット位置における１は、トラック定義がそ れぞれの言語によって利用可能であることを示す。フィールド１１におけるビッ ト位置と言語との間の対応は、フィールド６におけるものと同一である。思い出 されるように、フィールド６の第１ビット位置はＭ＆Ｅが対応しており、因襲的 な「言語」ではない。フィールド１１の第１ビット位置はこうして使用されず、 フィールド１１にはせいぜい９９個の「１」が存在することが可能である。 トラック定義が実際に読取られて処理される前に、再生装置はユーザに提供す べきメニュー選択を決定しなければならない。例えば、１０個の「他の」オーデ ィオトラックであって、その各々が異なるオーケストラ楽器のサウンドを有する ことを仮定しよう。選択言語でのトラック定義が、一度、オペレーティングシス テムで利用可能となれば、ユーザに対して標準メニューを表示することができる 。それでユーザは、共に再生させるべく特定の複数トラックを、削除すべく特定 の複数トラックを、それらの相対的サウンドレベルを、更には、他の「標準」選 択を、等々、選ぶことができる。しかしながら、その「他の」オーディオトラッ クがオーケストラ音楽を表現しない場合、或いはそれは表現するのであるが、そ の方法として普通ではないメニュー選択を要求するような場合、システムがその 「他の」オーディオトラックによって為されるべき何かを決定できるようにする ために、ユーザとのインターフェース用の標準オペレーティングシステムのソフ トウェアは充分ではないであろう。普通ではない状況に適応するために、オペレ ーティングシステムには、ユーザの選択に従ってどのようにしてその選択された トラックの混合／削除を制御するかの目的と共に、メニューを創作する目的のた めの特殊なソフトウェアを設けなければならない。使用される技術は、（フィー ルド３及び４での）再生装置の全体オペレーションを変更するための特殊なソフ トウェアのローディング又は装填と関連して上述した技術と同一である。フィー ルド１２は単一ビットである。もしもそれが１であれば、特殊混合／削除ソフト ウェアを含むフィールド１３の存在を示す。図３に示されるように、フィールド １３はこうして何処かにビット無しから、ディスクから機器にロードされる特殊 ソフトウェアの長さに依存した未決定の数までを有する。この特殊ソフトウェア はシンクワードで終了するので、再生装置は次のフィールドがいつ始まるかを知 ることになる。 次のフィールドであるフィールド１４はトラック定義自体から成る。Ｍ個の「 他の」オーディオトラックがあり、使用のためにそれらを定義するＰ個の言語が あるので、Ｐ×Ｍのキャラクタストリング又は文字ストリングがフィールド１４ 内に表現されている。各ストリングは次のストリングとはエスケープ（ＥＳＣ） キャラクタによって分離されている。先ず、フィールド１１の１を含む第１位置 に対応する第１言語でのＭ個のキャラクタストリング（トラック定義）があり、 それから、フィールド１１の１を含む第２ビット位置に対応する第２言語でのＭ 個のストリングがあり、等々である。下述するように、ユーザは再生装置に対し て、複数の利用可能言語の何れかで、トラック定義を有するメニューを表示すべ きあることを知らせる。ディスクドライブからの全データアウトビットストリー ムは図２のシステムにおけるマスターコントローラまで延び、選択された言語に 対応したキャラクタストリングのみが処理される。それらは、標準ソフトウェア に従ってか、或いは、フィールド１２でまさに読取られた特殊混合／削除ソフト ウェアであって、もしもそうしたものがディスクに含まれていれば、そのソフト ウェアに従って処理及び表示される。（注目されるべきことは、幾つかのバッフ ァに対してそれらのために意図されたそれぞれのデータビットのみを分配するデ マルチプレクサ６３の機能である。コントローラ４１が導入セクション及び個々 のデータブロックの両方における情報を解釈した後にデマルチプレクサに対して 何 をすべきかを教えるのはコントローラ４１である。） 図２に関連して説明されたように、サブタイトルの挿入に対しての備えが為さ れている。以下に説明されるようにユーザによって言語が選択されるが、再生装 置に対しては、その言語でサブタイトルが利用可能である旨を告げられなければ ならない。他の１００ビットフィールドがこの目的のために使用される。図３の ライン１５に示されるように、このフィールドでの複数の「１」はサブタイトル 用として利用可能な個々の言語を表現する。利用可能表示言語の場合と同様に、 最大９９個があり、これは第１ビット位置が厳密に言えば「言語」ではないＭ＆ Ｅに対応しているためである。 フィールド１６は４ビットマルチバージョンコードである。再生装置には、デ ィスクには同一ビデオ表出のための２つのバージョンが存在するかどうかばかり ではなく、それらに関してどのような選択があるのかが、告げられる。第１ビッ トが０であれば、ディスク上にはたった１つのバージョンがあり、その場合、第 ２及び第４ビットは無視される。ビット１が１の値を有すれば、ディスク上に２ つのバージョンがある。コード内の第２ビットは再生装置に対して、パーレンタ ルロックオプションは履行されるべきか否かを告げるか、或いは、再生のバージ ョンは何れかを選択するために異なる標準を用いるべきか否かを告げる。通常の 状況では、パーレンタルロックオプションは履行され、その場合、この４ビット コードの第２位置におけるビットは０である。これは再生装置に対して、パーレ ンタルロックオプションは「オン」であるか否かを決定すべきであることを告げ る。もしそうであれば、Ｒ等級（或いは、より広い意味でのアダルト等級）のバ ージョンは再生されるべきではない。コードの第３位置におけるビットは、バー ジョンＡ（第１或いは唯一バージョン）はＲ等級か否か（０＝いいえ、１＝はい ）を示し、コードの第４ビットは、もしも２つのバージョンがあればバージョン Ｂ用に同一情報を提供するものであるが、もしもただ１つのバージョンしかなけ れば、この第４ビットは無視される。これが、２つのバージョンの一方或いは両 方が再生され得るか否かを再生装置が決定するために必要な情報の全てである。 ディスク上に同一映画の２つのバージョンが存在したとき、ユーザはその内の一 方の選択を問われる。しかし、もしもパーレンタルロックオプションが「オン」 であり 且つその２つのバージョンの内の一方がＲ等級であれば、ユーザには、下述する ように、非アダルトバージョンを再生するか、或いは両方共に再生しないかの選 択だけが与えられる。もしも両バージョンがＲ等級であり且つパーレンタルロッ クオプションが「オン」であれば、ユーザは何れのバージョンも見ることができ ない。 一方、ディスク上に同一資料の２つのバージョンが存在するが、その内の一方 はアダルト等級であり且つ他方が違うこともあり得る。例えば、一方のバージョ ンが質疑応答を含む教育用フィルムであり、他方がちょうど質問を含む主題のテ ストを含むような場合がある。殆どの部分に関して此等２つのバージョンは同一 となる。そうした場合、フィールド１６の第１ビットは依然として１であり、２ つのバージョンが利用可能であることを示すが、第２ビットは今度は０の代りに １となり、それら２つのバージョン間の選択はそれらがＲ等級か否かに依存しな いことを示す。第２ビット位置の１は、第３及び第４ビットはそれら２つのバー ジョンに対して等級付け以外の特性に関してそれぞれ特徴付けすることを示す。 この場合における第３及び第４ビットが実際に意味すること、及びユーザに提 供されるメニュー選択は、異なる基準を頼ることによって決定されなければなら ない。先行して二度使用された同一技術がもう一度ここで用いられる、即ちバー ジョンコードに伴って特殊ソフトウェアが提供される。フィールド１７は、特殊 ソフトウェアは利用可能であるか否かを示すフラッグとしての役割を果たす単一 ビットから成る。もしもそのビットが１であれば、フィールド１８はそのソフト ウェアにアクセスすべく読取られる。２つの先行するソフトウェアフィールドの 場合のように、フィールド１８は、次のフィールドの開始を示すシンクワードを もって終了する。この特殊ソフトウェアはその特定のディスクにとって独特なメ ニュー表示を制御する。 次のフィールドは単一ビットから成る。図３に示されるように、それは再生装 置に、ビデオデータは利用可能か否かを知らせる。もしも否定されれば、それは 単に、図４に関連して説明される全体に亙るデータブロックにおいてビデオデー タブロックフィールドが存在しないことを意味する。 フィールド２０は単一ビットであり、基本或いはマスターアスペクト比を識別 する。もしもそのビットが０の値を有すれば、それはディスク上の如何なるビデ オをも、図９に示されるような１６：９の「ワイドスクリーン」のアスペクト比 を有することをことを示す。一方、もしもそのビットが１であれば、それはディ スク上のビデオのアスペクト比は４：３であることを示す。 上述したように、もしもオリジナルビデオが「ワイドスクリーン」のアスペク ト比を有すれば、４：３縮小アスペクト比を引き出し得る２つの方法がある。一 方の方法は、「ワイドスクリーン」オリジナルの中央部分からビデオ像を形成す ることである。他方の方法は、実際に利用されるオリジナル像の部分又はセクシ ョンは必ずしも常に中央部分ではないと言う意味での「パンスキャン」すること である。事実、図９はオリジナル像の右側よりは左側により多くの情報が用いら れていることを示している。フィールド２１はパンスキャン可用性を示す単一ビ ットである。もしもフィールド２０が１であれば、基本アスペクト比は４：３で あるので、パンスキャン可用性は無関係となり、即ち、フィールド２１における 単一ビットは単純に無視される。しかし基本アスペクト比が１６：９であれば（ フィールド２０は０を有する）、フィールド２１のビットの値は再生装置に対し て、続くデータブロックは図２におけるパンスキャンバッファ５７にロードされ 得る出発コラム情報を提供するか否かを告げる。もしもフィールド２１における ビットが０であれば、そうしたデータブロックはコラム番号情報を含まず、もし もビデオが「ワイドスクリーン」オリジナルから４：３アスペクト比で再生され るのであれば、ビデオ像は各オリジナルフレームの中央部分から形成される。一 方、もしもパンスキャン情報がそうしたデータブロック内で利用可能又は有効で あれば、図２におけるバッファ５７は所望に応じて更新され、形成された最終ビ デオは変化性の度合いが追加されたものとなる。 フィールド２２は、ディスク上のデータブロックの合計数を表わす２０ビット 数である。しかしながら、もしも２つの異なるバージョンが存在するなら、それ らは共通する多くのデータブロックを有する一方、２つのバージョンの残りのブ ロック数は異なることもある。例えば、１シーン又は１場面が一方のバージョン から完全に省略されていることもあり、その場合、データブロックの合計数はよ り少なくなる。この理由のため、もしもフィールド１６がディスク上の１つの映 画或いは他のソース資料に２つのバージョンが存在することを示すものであれば 、フィールド２３はバージョンＡに関するデータブロックの合計数を提供し、フ ィールド２４はバージョンＢに関するデータブロックの合計数を提供する。此等 両フィールドは、もしもディスク上にたった１つのバージョンしかなければ、省 略される。 各データブロックは、複数のフレームの可変的な数のためのビデオ情報を含む 可能性がある。このシステムは、ただもしもオリジナルのフレームレートと、デ ィスク全体として、各ブロック内に表現されたフレームの平均数とが知らされて いれば、データブロック数から合計再生時間を決定することができるであろう（ もしも単一バージョンのみが存在するのであればその合計数から、或いはもしも ２つのバージョンが存在するのであればその２つの異なる数から）。同一数のデ ータブロックを伴う２つのディスクは、もしもそれらの内の一方のオリジナルソ ース資料が毎秒２４のレートで発生するフレームの映画であり、他方のものが毎 秒３０フレームのビデオカメラから引き出されたオリジナルソース資料を有すれ ば、異なる運転時間を有することになる。フィールド２５は４ビット値であり、 オリジナルフレームレート（２４、３０、等々）、即ちビデオ信号の適切な発生 に必要な数を識別するものである。各データブロックによって表わされる時間は 、もしも各データブロックがただ１つのフレームを含むものであれば、フレーム レートから決定可能であるかもしれないが、各データブロックには１フレーム以 上或いは１フレーム以下のデータを記憶することが可能である。また、フレーム 情報が全くないこともあり得、即ちフィールド１９におけるビデオ可用性フラッ グが０であるかもしれない。当然の結果として、フィールド２６が設けられてい る。このフィールドは１０ビット数であり、ブロック時間ファクター、即ち各ブ ロックによる平均持続時間を表わす。このブロック時間ファクターの合計ブロッ ク数（或いは特定バージョンに関する合計数）による乗算は、運転時間をもたら す。（実用上、ブロック時間ファクターは１つのディスク上での両バージョンに 関して略々同一である。所望に応じて、ここのブロック時間ファクターを設ける ことができる。） 一般の光ディスクの共通慣習として、本発明のディスクには、ユーザが再生の 特定部分を選択できるように、或いはディスク上に一体何があるのか、そして各 部分の再生時間はどの程度であるのかを単に知らせるための目次を設けることが できる。フィールド２７は、もしも含まれるのであれば、目次である。もしもソ ース資料がたった１つのバージョンの形でディスク上にあれば、ただ１つの目次 である。さもなければ、第２のバージョンのための目次から成る追加的なフィー ルド２８が存在する。図３はフィールド２７の複数のサブフィールドを詳述して いる。 より良い用語の欠如のため、ビデオ表出は「チャプター"chapters"」と言われ るものにまで分割されている。各チャプターに対してこの目次は８ビットのチャ プター数を含んで、最大２５５の個々のチャプターを許容している。各チャプタ ー数に続いて、２０ビットの出発ブロックの連続ブロック番号が存在する。思い 出されるように、ディスク上の全てのデータブロックは連続的に番号付けされて いる。言換えれば、データブロックはバージョンＡ及びＢの両方に共通であるか 、或いはそれらの一方のみに唯一独特であり得るかであり、その多数のデータブ ロックはディスクトラックに沿って通し番号順である。この目次は、各チャプタ ーの出発ブロックであるデータブロックの連続ブロック番号を含む。 同様にして、各チャプターの再生時間を決定するために、システムは各チャプ ターにはブロックが幾つ含まれているのかを知らねばならない。この理由のため 、情報の次のピース又は次の情報ピースは２０ビットのブロック持続時間である 。この数をブロック時間ファクターで乗算することで、各チャプターの再生時間 を決定させることができる。代替的には、ブロック持続時間の代りに各チャプタ ーの実際の運転時間が設けられるであろう。（そうした情報は異なるバージョン 及び標準毎に設けられるであろう。） 各チャプターのタイトルを再生するために、複数の言語ストリングが設けられ なければならない。再度、システムには、チャプタータイトルの表示のために利 用可能な複数の言語が通知されねばならないので、ユーザはそれらの内の１つを 選択することができる。利用可能言語又は可用性言語を識別するために、１００ ビットブロックを提供する通常の技術が採用される。 最後に、個々のチャプターを識別するための実際の言語ストリングが提供され る。各ストリングは、エスケープキャラクタをもって次のストリングとは分離し て終了する。これは、フィールド１４に関連して先に議論した「他の」オーディ オトラック定義に関連して用いた技術と同一である。 フィールド２９は最小１００ビット及び最大１２００ビットを有する。思い出 されるように、１２個の認定（検定）済み標準又は基準があり得ること、即ち最 終ビデオ出力は１２の異なるフォーマットであり得ることである。仕様又は規格 が共通したセットを供給すべく同意した全ての再生装置製造業者及び全てのソフ トウェア出版社によって同意された品質基準又は品質規格の準拠を保証するため に、認定が済んでいない又は未認定と認められるソフトウェア出版社が本発明の 再生装置で再生されるディスクを出版することを防止又は排除することは可能で ある。更に、１２の標準の内のサブセット又は一部のみに従って再生するような ディスクを製造することを特定の出版社に限定することも可能である。例えば、 もしも同意された仕様に従って製造された各ディスクに対してロイヤリティを支 払うべきであり、そのロイヤリティはディスクが再生され得る標準数に従って変 化すれば、あるソフトウェア製造業者に対しては彼等が支払に同意したサブセッ ト標準のみに限定することが可能である。この理由のため、各標準用に暗号化さ れた認定済みコードが存在し、此等コードはフィールド２９に全て記憶されてい る。ディスクは、該ディスク上に適切な暗号化された認定コードが含まれている 時にのみ、特定の標準に従って再生することになる。フィールド２９はフィール ド５で認定された標準毎に１００ビットずつ含む。少なくとも１つの標準が認定 されなければならないので、そこには少なくとも１００ビットが存在する。最大 ビット数は、もしも１２標準全てが認定された場合、１２００である。 暗号化構成又は機構は公開鍵（パブリックキー）暗号術の原則に基づくもので ある。公開鍵暗号術は現在では公知であり、そして、その題材の明確な解説は１ ９７９年８月出版のサイエンティフィック・アメリカン ”Scientific American ”に見出され、ヘルマン（Hellmann）による「公開鍵暗号術の数学”The Mathem atics of Pub1ic-Key Cryptography”」と題された論文がある。公開鍵暗号術を 使用することによって、１つのメッセージがＡ側では秘密鍵に従って暗号化され 、Ｂ側に伝送され、そしてＢ側では公開鍵又はパブリックキーによって復号化さ れる ことを可能としている。メッセージを暗号化する秘密鍵は伝送側のみに知られて いる。こうした構成は、典型的には、メッセージの真贋鑑定のために使用される 。受信側での伝送された暗号化メッセージの復号化に及んで、そのメッセージは 、それが一対となった私的鍵又はプライベートキーによって暗号化されたもので あれば、理解できるようになる。そして、このプライベートキーは私的なもので あるので、もしも復号化メッセージが理解できれば、それはプライベートキーの 所有者によるものであることに違いない。 公開鍵暗号術は本発明では以下の方法をもって使用される。トラック上の実際 のデータは、ソフトウェア出版社を介して所定のアルゴリズム又は演算規則に従 って処理されている。処理の詳細は重要ではない。例えばディスクデータに基づ く１００ビット結果を提供する何等かの少なからぬ重要な処理で充分である。１ ００ビットの結果は、ディスクを介して、１から１２までの暗号化形態で伝送さ れる。１２の暗号システムの鍵対又はキーペアが、上記標準のそれぞれに各一対 又は各ペアが関連した形で存在する。ディスク上で認定された第１標準のプライ ベートキーは１００ビットメッセージを暗号化するために用いられ、その１００ ビット暗号はフィールド２９に記憶されている。この暗号化はその特定の標準の ための認定コードである。同一のことがそのディスクで認定された他の標準の全 てに対して為され、此等標準の各々に関連したプライベートキーが各場合におい て使用されることとなる。 再生装置のオペレーティングシステムは、ソフトウェア出版社によって元々は 演算された同一の１００ビット結果又はメッセージを演算する。そして再生装置 はそのディスクで認定された標準の各々に関連したパブリックキー又は公開鍵を 用いて、その標準用の暗号化認定コード毎を復号化する。復号化されたメッセー ジは、ディスクデータの処理の後のオペレーティングシステムによって演算され たメッセージに合致すべきである。もしもそれらが合致しなければ、ソフトウェ ア出版社はその特定の標準のための認定されたコードを暗号化するプライベート キーを持っておらず、再生装置はその標準に従ってビデオ信号を提供しないこと となる。 これを他の方法で説明するために、ディスク上で認定された標準Ｎのためのプ ライベートキーは、暗号化メッセージとして、Ｘは暗号化されるメッセージとし た場合にＰｒｉN（Ｘ）を生じさせると仮定しよう。同様にして、関数ＰｕｂN（ Ｘ）は、関数Ｘを一対の片方であるパブリックキーを用いての復号化を表わして いる。更に、ディスク上のデータを処理する所定アルゴリズムは、再生装置の製 造業者及びソフトウェア出版社の全てに知られており、ディスクデータに依存す る内容（値）を有する「メッセージ」Ｍとして取り扱われる１００ビット結果を 生じさせると仮定しよう。標準Ｎの場合、ソフトウェア出版社は、先ずＭを引き 出した後、ディスク上に１００ビットの暗号化された認定コードＰｒｉN（Ｍ） を記憶させる。再生装置は、ソフトウェア出版社が為したと同一の方法で、値Ｍ を先ず引き出す。それから、再生装置のソフトウェアは暗号化された認定コード を復号化するために標準Ｎに関連したパブリックキーを用いる。こうしてオペレ ーティングシステムは、ＰｕｂN（ＰｒｉN（Ｍ））を引き出す。暗号化メッセー ジの復号化はオリジナルメッセージとなるはずであるので、この復号化の結果は 、ディスクデータを処理することによってオペレーティングシステムが引き出し た同一値Ｍになるべきである。もしそうであれば、この特定の標準は認定された ものであるばかりか、出版社もそれを認定する権利を有する。一方、もしも暗号 化認定コードＭの復号化が再生装置によって引き出されたアルゴリズム結果Ｍと 合致しなければ（ソフトウェア出版社がＰｒｉN（Ｍ）を引き出すために用いら れるプライベートキーを持たないので）、その特定の標準はロックアウト（又は 締め出し）されることになる。 そうした構成は理論上又は観念上では作動する一方、克服されねばならない１ つの実際上の問題がある。例えば、オリジナル「メッセージ」Ｍを引き出すべく 使用されるアルゴリズムは、所定の連続ブロック番号を有するディスク上の２０ のデータブロックを処理することを想像しよう。（この処理は、各々が１００ビ ットである連続グループを相互に乗算し、各乗算の結果としてその１００の最小 の意味あるビットだけを次の乗算用に用いることと同様に簡単なものであるかも しれない。）ディスク上の標準Ｎを認定する権限が与えられていない出版社は、 それにも拘らず、そうしたことを為すことを望む可能性がある。彼は、彼のソフ トウェアに適用できる引き出された値Ｍを暗号化するためのプライベートキーを 知 らない。結果として、彼はディスクに記入すべき１００ビット暗号化コードであ って、再生装置内で値Ｍへ復号化することになる１００ビット暗号化コードはど のようなものであるかを彼は知らない。しかし彼ができることは、他の何等かの 合法的なディスクから２０の所定データブロックをコピーして、彼自身のディス クにそれらを記入することであり、またフィールド２９内の暗号化認定コードを コピーすることである。それら２０のデータブロックは、再生装置内で処理され れば、値Ｍとなり、それは再生装置で復号化された後に「盗用」暗号化認定コー ドと合致することになる。勿論、そのソフトウェア出版社は著作権侵害を犯すこ となるが、単に重罪の私和となる。そのソフトウェア出版社が直面する実際上の 問題は、彼が有するデータブロックは「再生」され、彼の映画に関する限りは前 後関係が全体的になくなることである。しかしながら、先ず第１に映画の多重バ ージョンを同一ディスクに記憶させることができる方法は、再生装置はあるデー タブロックを下述するようにスキップする又は飛び越えるように制御され得るの で、ソフトウェア出版社は、コピーされたデータブロックが再生されることがな いように、彼の他のデータブロックをコード化することができる。こうして、暗 号化保護は無効化され得る。 解決策は、「メッセージ」を先ず第１に引き出すアルゴリズムは所定データブ ロック上でもオペレート又は動作するかもしれないが、それはトラックの少なく とも導入区域上で動作すべきであることである。未認定の出版社が他のディスク から導入部トラックフィールドをコピーできる方法はなく、その理由は、再生装 置にその未認定出版社のディスク上のビデオ及びオーディオに関する誤情報を与 えてしまうからである。導入部データはディスクの特定の主題の関数であり、デ ィスクを適切に再生するためにトラック内に現われなければならない。こうして 、図３上に表現された情報は「メッセージ」Ｍとして取り扱うことができ、認定 された標準毎に１つあるその暗号化は、それぞれのプライベートキーを用いて引 き出され、導入部フィールド２９内に記憶される。（厳密に言えば、「メッセー ジ」Ｍはフィールド２９を除く全てのフィールドの処理の結果である。また、ソ フトウェアを含むようなより長いフィールドはその処理から省略され得る。）再 生装置は同一「メッセージ」を引き出し、暗号化された認定コードをそれぞれの 標準 に関連したパブリックキーで復号化し、それからそれら２つを比較する。もしも それらが合致しなければ、再生装置はその特定標準はその特定ディスク出版社に は認定されていないと決定する。 暗号化された認定コードフィールドは図３の末端近くに示され、その対応する 処理は、下述する図５Ａ〜図５Ｃのフローチャートの末端近くに示されている。 暗号化された認定コードフィールドの図示された位置付けは、その処理の説明を 促進するものであるが、実際のところこのフィールドは処理の最初に配置される ことが有利である可能性がある。思い出されるように、特殊なソフトウェアが、 正規の再生装置シーケンスを変更すべく、ディスクから読取られることがある。 よって、偽造者が認定コード処理をバイパスさせるよう特殊ソフトウェアを書き 得ることが想像できる。如何なる特殊ソフトウェアもまさに読取られる前にそう した処理を行うことによって、その処理はバイパスされることができなくなる。 導入トラックフィールドの説明に戻って、フィールド３０は１ビットデータブ ロックのコマンド／データフラッグである。このビットはオペレーティングシス テムに対して、データブロックはディスクの再生中に読取られるべきコマンド情 報或いはデータを含むか否かを知らせる。システムがどのようにして、特定デー タブロックがコマンド或いはデータを含むか否かを決定するかは下述することに なる。フィールド３０は、何かそうした情報が一体あるのか否かを単に示す。最 後に、フィールド３１及び３２は雑品入れフィールドであり、再生装置がディス ク上の情報を処理する普通ではない方法をディスクに制御させることを許容する ものである。思い出されるように、フィールド３は、フィールド４が通常採用さ れるものとは全体的に異なるプログラムに従って再生装置をオペレートさせる特 殊ソフトウェアを含むか否かを示すフラッグを含み、フィールド１２はフィール ド１３が「他の」オーディオトラックに使用する特殊混合／削除ソフトウェアを 含むか否かを示し、フィールド１７は、フィールド１８は４ビットの多重バージ ョンコードを処理するための特殊バージョンソフトウェアを含むか否かを示すフ ラッグを含む。フィールド３１はフィールド３２内に「補助」ソフトウェアがあ るか否かを示す。この補助ソフトウェアはフィールド４の特殊ソフトウェアとは ことなるものであり、フィールド４のソフトウエアは、基本的には、通常用いら れる 処理の代替品である一方、補助ソフトウェアは一般にデータブロック内に見出さ れるべきコマンド及びデータと共にそのコードを扱う。 典型的には、この補助ソフトウェアはビデオゲームの再生を許容することなり 、データブロック内の関連されたコマンド及びデータで再生コースを決定するこ とが付随されている。この技術は他の複数の用途もある。補助ソフトウェア、デ ータブロック内のコマンド及びデータが使用され得る方法の他の例として、サブ タイトル（字幕）付きのクラシックな映画であるが、サブタイトルの代りに周期 的に表示されるような評論的実況解説であって、おそらくは該評論的な実況解説 を除いてはスクリーンが空白又はブランクとなる瞬間の実況解説をも設けれられ ているクラシック映画を考えよう。可能性ある柔軟性を示すために、その評論的 実況解説は異なる言語であるとの場合をも考慮することにしよう。そうした場合 に要求されることは、図２上のバッファ５９には幾つかのデータブロックの再生 中に一方言語でのサブタイトルが、そして他のデータブロックの再生中には他方 言語でのサブタイトルがロードされることである（こうして、その幾つかのデー タブロックはオリジナル映画に対応するサブタイトルを含み、他方は他方言語で の評論的な実況解説を含む）。そうした場合、言語サブタイトルに関して一方か ら他方へ他方から一方へと切り換えるように、システムに対してどうにかして知 らせる必要があり、即ち、異なるサブタイトルトラックは異なるデータブロック で処理されなければならない。これはデータブロック自体内でコマンドを発する ことによって従来的には制御され得る。同様にして、もしもスクリーンをブラン クにして画像を実況解説の表示の間妨害することが望まれたならば、あるデータ ブロックはブランク状態の持続時間を表わすあるデータ値を含むこととなるであ ろう。代替的に、もしも実況解説が異なる言語で行われるべきであれば、その目 的のために選択された異なるオーディオトラックとなることであろう。如何なる 場合でも、フィールド３２からロードされた特殊ソフトウェアはデータブロック 内に含まれたコマンド及びデータの処理を制御し、再生装置のオペレーティング システムと共に動作することとなるであろう。 導入部トラックフィールドの処理 図５Ａ乃至図５Ｅは、導入部トラックフィールドにおける情報処理を示す。こ の予備的な処理の説明を個々のフィールドの機能を念頭においてこの時点で提示 する。データブロックの処理と共にデータブロックにおける此等のフィールドを 以下に説明する。 図５Ａの上部に示されるようにデフォルト設定又は設定状態の読取りによって システム処理は始まる。此等は、ＤＩＰスイッチ、ＲＯＭコード、或いは電源投 入時にシステムを構成する任意の他の装置又は技術等によって確定された設定で ある。マイクロプロセッサに基づくシステムにおいて典型的なように、電源の最 初の投入時に、全てのフラッグをリセットし、デフォルト設定状態を読取る。 こうして、此等はシステムを構成するために決定される４つのデフォルト設定 状態がある。第１は標準であり、例えば合衆国で販売される再生装置は典型的に は、デフォルト状態又は既定値設定状態で、ＮＴＳＣビデオ信号を提供すべく構 成される。 次のデフォルト設定は言語であり、サウンドトラックのダイアローグ言語、サ ブタイトル言語（もしもあれば）、ディスプレイ上に提示されるべきメニューの 言語等々である。例えば合衆国において、デフォルト言語は英語となるであろう 。もしもユーザが再生装置に対して、英語以外の言語を此等の機能の１つ以上の ために望まれることを知らせなければ、オーディオ言語トラック１０が使用され てサウンドトラックを発生し、英語のキャラクタストリングが「他の」オーディ オトラック及び目次のための混合／削除メニューをセットアップするために使用 される。サブタイトルに関しての通常のデフォルトは「言語なし」である。 第３デフォルトはアスペクト比であり、合衆国では４：３である。アスペクト 比は、最終ビデオ出力信号によって表わされるディスプレイの相対的寸法を決定 する。 最後に、パーレンタルロック状態が決定される。これは図２のシステムにおい てロック８１の設定の決定を単に課するだけである。しかし物理的ロック及びキ ーをなしで済ませ、そして、ロック機能の制御を実行する人間だけに知られたパ スワードをキーボードで先ず入力した後に、このパーレンタルロック状態を不揮 発性のメモリーに記憶することも可能である。 多くの消費者用電子機器におけるように、キーボードは再生装置との質疑応答 用或いは制御用としてユーザに随時使用され得る。当業界では標準的なルーチン 制御シーケンスは、ここでのフローチャートには示されていない。例えば、キー ボード、或いは関連の遠隔操作装置等は、ボリューム、早送り、特定チャプター へのジャンプ等々を制御するために使用され得る。当業界では周知のように、メ ニューキーを操作することによって表示を制御すべく、正規の処理は中断される （割込み）。図５Ａの処理のスタートでは、メニューキーは操作されたか否かを 決定するテストが示される。ディスク再生中の任意の他の時間とは対照的に、処 理のスタート時にメニューキーが操作されたか否かの質疑応答を示す理由は、こ れはデフォルト設定状態を変更できる機構であるからである。もしも電源の最初 の投入時にメニューキーを操作すれば、システムは１つのメニューを表示する。 フローチャートに示されるように、ユーザには、デフォルト変更、ディスク目次 の検分、及び／又は（メニューキーを誤って操作した場合）何等変更することな く元の処理への単なる戻し（リターン）の選択肢が与えられる。図示されている ように、メニュー選択に応じて、デフォルトが変更され、全メニュー選択工程が 中止されるか或いはＴＯＣ（目次）フラッグが１にセットされる。このフラッグ は、目次が表示されるべきか否かを決定するために、追って確かめられることに なる。 今までのところ、ディスクからの情報は何等処理されていない。（この説明に おいて、しばしばフィールドの読取りを参照したり、しばしばフィールドの処理 を参照したりする。理解して戴きたいことは、ある処理ステップの後にフィール ドが読取られると言われた時でさえ、そのフィールドは、後の使用のためにバッ ファ内に記憶されている以外、実際には先行して読取られていることもあると言 うことである。その文脈に依存して、フィールドを読取るとは、実際にそれを読 取ってそのビットが図２のデータアウト導体２５上に現われることを意味するか 、或いはそれが先行して読取られてバッファされていればそのデータによって何 等かを行うことを意味する。）図３において、導入トラック区域から読取られた 第１の情報フィールドは、認定された領域を表わしている。次に、再生装置の使 用が意図された領域は、ディスク上で認定されたものの内の１つであるか否かを 見 るための検査又はチェックが為される。また、再生装置領域はデフォルト設定の 一種でもあるが、それはユーザによって変更され得ないので他のものとは一団と はならない。（１つの領域から他の領域への移動する購入者に彼の再生装置の使 用を可能ならしめるべく、その再生装置領域は認定された技術者によって変更さ れ得る。）もしも再生装置が、例えば、中国向けの使用として設計され、そして 中国はディスク上で認定された領域の１つでなければ、ディスクの再生は中止さ れる。 一方、もしもディスクが再生装置領域内での再生用に認定されていれば、この 単一ビットはシステムに対して、特殊ソフトウェアは存在するか否か単に告げる 。フローチャートに示されているように、もしも存在すれば、その特殊ソフトウ ェアがフィールド４から読取られて実行される。この処理は「特殊ソフトウェア の実行」ステップで終了する。これは、フィールド４の特殊ソフトウェアは基本 的には内蔵オペレーティングシステムと入れ替わることを示すべく意図されてい る。そうしたソフトウェアは、再生装置の全体的な用途の抜本的変更が必要とさ れる時に採用されることとなる。（上述したように、こうだからといって、この 特殊ソフトウェアが、オペレーティングシステムを含むＲＯＭからのＢＩＯＳ（ 内蔵オペレーティングシステム）ルーチン及びその類と呼ばれるわけではない。 ） もしも特殊ソフトウェアが存在しなければ、システムはデフォルト標準を読取 り、例えばＮＴＳＣ標準を採用すべきことを決定する。もしもユーザがメニュー 選択を通じてこのデフォルト標準を変更していれば、例えばＰＡＬへ変更してい れば、ＰＡＬが新しいデフォルト標準となる。システムはそれから、１２標準ま で認定しているフィールド５にアクセスする。実行されるテストは、デフォルト 標準（オリジナルのもの、或いは処理のスタート時に変更されたもの）が認定さ れているか否かを決定することである。もしもそうでなければ（認定されていな ければ）、ユーザに認定されている標準を示すべくメニューが表示されて、彼は その内の１つを選択する。適切な選択が為された後、或いはもしもデフォルト標 準が認定されていれば、システムはフィールド６及び７を処理する。フィールド ６の読取りは、再生装置に利用可能なオーディオ言語（Ｍ＆Ｅ及び１５言語を含 む１６まで）を知らせる。 もう一度、デフォルト値が、許容されたオプションのセットに対抗して、テス トされる。先行して、ディスクから読取られた認定標準に対抗してテストされた のは、デフォルト標準であった。今回は、利用可能な全てのものと比較されるの は、デフォルトオーディオ言語（電源投入時のデフォルト言語、或いは、もしも メニューキーが操作されたならばユーザによって選択された異なる言語の何れか 一方）である。フローチャートに示されるように、もしもデフォルト言語が利用 可能でなければ、利用可能なオーディオ言語を列挙した１つの表示が形成されて 、ユーザがその内の１つを選択する。それからシステムはフィールド７における トラックタイプを読取る。これは、Ｍ＆Ｅトラックは存在するか否か、ミキシン グマスター或いはスイッチングマスターとして使用されるべきものか否か、更に 、選択された言語トラックは完全なオーディオトラックで、ミキシングマスター と混合されるべきか否か或いはスイッチングマスターとスイッチング又は交換さ れるべきか否かを、オペレーティングシステムに知らせるフィールドである。次 に、トラックコーディング（コード化）をフィールド８から読取る。もしも選択 言語、そのトラックタイプ及びトラックコーディングが、Ｍ＆Ｅ、ミキシング（ 混合）及びスイッチング（交換）に関しての情報と共に与えられれば、オペレー ティングシステムは、視聴者のニーズに合致する、映画に付随するためのサウン ドトラックを発生するに必要な全ての情報を有する。 実行される次なることは、フィールド９を読取ってディスク上にある「他の」 オーディオトラックのゼロから６３までの数を決定することである。もしも「他 の」オーディオトラックが本当になければ、それらによって為されるべき事柄を 決定する処理の全てはバイパスされる。しかし、もしもそうしたトラックがあれ ば、フィールド１０が先ず読取られてそれらをどのようにコード化するかを決定 する。ユーザはそれらで為されるべきことを決定する前にトラック内に何がある のかを知らされていなければならないので、システムはフィールド１１を読取る ことから、ディスク上の「他の」トラックメニュー言語を次に決定しなければな らない。通常タイプのチェックは、メニューがデフォルト言語で利用可能か否か を見ることである。もしそうでなければ、利用可能言語が表示されてユーザはそ れらの内の１つを選択する。 先に説明したように、オペレーティングシステムは、メニューを読み込むこと 、それを表示すること、並びに「他の」オーディオトラックによって為されるべ き事柄のユーザの決定に伴ってユーザとの相互作用すること、のための標準ルー チンを実行する可能性がある。しかし、特殊混合（ミキシング）或いは削除が達 成されるべきことであった場合には、特殊混合／削除ソフトウェアが要求される 。フィールド１２が読み込まれて、そうしたソフトウェアが利用可能であるのか 否かが見られ、そしてフローチャートに示されるように、ディスク上にある何等 かの特殊混合／削除ソフトウェアがフィールド１３から読取られる。その後にだ け実際のメニュー項目（選択された言語で）がフィールド１４から読取られて、 ユーザのために表示される。オペレーティングシステムによって利用可能となっ たメニューを用いて、ユーザは「他の」オーディオトラックのための再生モード を選択する。例えば、彼は任意の許容された方法でそれを混合したり、トラック 内にあるものを他のより多くのいっさいを含むトラックから削除する（位相反転 によって）ために用いたり、独占的な再生のために１つのトラックを調整したり 、相対的なオーディオレベルを調整したり、等々することができる。特殊混合／ 削除ソフトウェアは、勿論、此等のオプションを慣習的には提示されていない他 のものと共に提供できる。 図５Ｂに示されるように、サブタイトル情報は設定されたパターンに従ってこ こで処理される。先ずシステムは、サブタイトルが本当に望まれているのか否か を決定する。図５Ａのほんの始めのところで思い出されるように、デフォルト設 定の１つはサブタイトル言語である。通常のデフォルト設定は、サブタイトルは 望まれていないことになっている。もしもそれが、事実、当てはまれば、サブタ イトル処理は完全にスキップされる。しかし、もしもサブタイトルが望まれてい るのであれば、利用可能サブタイトル言語がフィールド１５から読取られる。そ れから、デフォルトサブタイトル言語は利用可能であるか否かを見るテストが行 われる。もしもそうでなければ、利用可能サブタイトル言語が表示されて、ユー ザはそれらの内の１つを選択する。 次に、フィールド１６の４ビット多重バージョンコードが読取られる。第１ビ ットは、２つのバージョンが利用可能であるか否か、或いはただ１つであるかを 示 す。この点において選択肢は設けられることがなく、その理由は、先ずシステム は特殊ソフトウェアが利用可能であるのか否かを決定しなければならず、これは フィールド１７から決定される。もしも特殊バージョンソフトウェアが利用可能 であれば、フィールド１８から読取られて実行される。このソフトウェアは多重 バージョンが利用可能であるか否かと、第３及び第４ビット位置におけるコード が表わす事柄とを知らねばならないと言う限り、それは既に決定されている。ユ ーザのための表示された選択は認定されたバージョンの内からの選択か、或いは 退去（exit）がフローチャートに示されているが、理解して戴きたいことは、表 示選択は、もしも特殊バージョンソフトウェアが実行されたならば、一般には異 なる。また、理解されるべきは、もしも再生され得るバージョンがたった１つ存 在するとしても、特殊バージョンソフトウェアは存在し得ることである。例えば 、特別なプログラムは非常に未設定状態であり得ることを視聴者に対して警告し て、再生開始前に「続ける」返答を請求することが適切であるかもしれなく、此 等の全てはＲ等級とは別であり且つ分離したものである。 もしも特殊バージョンソフトウェアが利用可能でなければ、上記４ビット多重 バージョンコードフィールドのビット３及び４は等級付け目的のために使用され ない。パーレンタルロックがオンとなっているか否かを見るためにテストが実行 される。もしもそうでなければ、バージョンＡ及びＢの再生には何等制限がなく 、両バージョンは認定される。もしもそれがたった１つ存在するバージョンであ ると先行して決定されていたならば、そのバージョンはバージョンＡであると考 えられて、認定される。 一方、もしもパーレンタルロックがオンであれば、ディスク上のバージョンは Ｒ等級であるのか否かを見るためにテストが実行されなければならない。図５Ｃ に示されるように、もしもバージョンあがＲ等級であり、且つバージョンＢもそ うであれば、システムの再生は中止され、図示されてはいないが、適切なメッセ ージがユーザに表示されて、なぜ再生が停止したかを通知する。一方、もしもバ ージョンＡはＲ等級ではないが、バージョンＢがそうであれば、バージョンＡの みが認定される。最後に、例えばパーレンタルロックがオンであっても、もしも 両バージョンともにＲ等級でなければ、両バージョンは認定される。 次にシステムはユーザに利用可能な選択を表示する。彼は認定されたバージョ ンの内から選択でき、或いは退去してディスクの再生を停止することができる。 （この後者の場合は発生し得るものであり、例えば、もしも子供がＲ等級バージ ョンを見ようとすると、その再生は不可能であることが告げられ、なにか他のよ り興味あるものに進むことの決定が為される。） もしもたった１つのバージョンが利用可能であれば、もしもそれがＲ等級でな ければ、そしてもしも特殊バージョンソフトウェアが何等なければ、再生のため の必要要件が全くない可能性があり、即ち、再生可能な唯一の映画があり、それ を見ることができる者に対して制約が何等ない。それにも拘らず、フローチャー トに示されるように、ユーザには依然としてディスクの再生と再生中止との間の 選択が与えられている。システムは、そうした場合に再生をスキップし、そして ユーザはディスク上にあるその唯一の映画バージョンを見ることを欲していると 単純に仮定するように設計され得る。一方、表示を発生することはユーザに、彼 が再生装置に入れたディスクは本当に彼が欲しているディスクであるのかを照合 することを可能としている。 ここまで、本発明は、１つのディスク上に１つの映画に関して１つ或いは２つ のバージョンがあると言うことで説明してきたが、理解して戴きたいことは、３ つ或いは４つのバージョンがあり得ることである。これは、先ず第１に、特殊バ ージョンソフトウェアを読取る機能を提供する主要理由の１つである。このソフ トウェアは、ユーザが再生すべき何かを選択できるようにメニュー表示形成の基 礎となる複数バージョンに関して要求される情報の全てを含むことができる。上 記したように、特殊バージョンソフトウェアは、教育モード及びテストモードの 間での選択を可能にしており、そして他のオプションは特別な映画がアダルト等 級であるか否かに少しも関係がない。 次に、システムはフィールド１１のビデオ可用性ビットを読取って、続いて処 理されるであろうデータブロックはビデオデータを含むか否かを決定する。もし もビデオデータが存在すれば、それがディスク上に記憶されている状態である基 本或いはマスターアスペクト比が決定されなければならない。次のステップはフ ィールド２０の読取りを含み、基本或いはマスターアスペクト比は１６：９か或 い は４：３の何れかを確かめる。もしもマスターアスペクト比が４：３であれば、 次の５つのステップは、パンスキャン可用性が無関係であるので、スキップされ る。もしもデフォルトアスペクト比が４：３であれば、記憶されたフレームと表 示されたフレームとの間には１対１の対応があり、もしもデフォルトアスペクト 比が１６：９であれば、４：３フレームがワイドスクリーン上に何れか片側にダ ークバンドを伴って表示される。（代替的には、この４：３像は１６：９スクリ ーン一杯に拡張され得るが、上部及び／又は下部の情報が損失する結果を伴う。 ）しかし図９に示されるように、もしも基本アスペクト比が１６：９であれば、 探究されるべき幾つかの可能性がある。 処理のまさしくスタート時に決定されるデフォルト値の１つがアスペクト比で ある。オペレーティングシステムは、デフォルトアスペクト比がパンスキャン４ ：３であるか否かをチェックする。図９において、もしもマスターアスペクト比 が「ワイドスクリーン」であれば（そのフローチャート分岐が処理される）、可 能性はレターボックス、ワイドスクリーン像上の中央に置かれてたパンスキャン （図９に図示されず）、或いはパンスキャン可変的なもの（即ち、可変的な出発 コラム番号を伴う）である。もしもデフォルトがパンスキャンでなければ、もは やユーザによって為されるべき選択はない。デフォルトがワイドスクリーン或い はレターボックスの何れかであると、続く処理は既に決定されたデフォルトに従 う。 一方、デフォルトがパンスキャン４：３であれば、問題は可変パンスキャン情 報がディスク上にあるか否かである。フィールド２１におけるパンスキャン可用 性ビットが読取られる。もしもパンスキャンが利用可能であれば、そのデータブ ロックはオペレーティングシステムに対して、パンスキャンのための出発コラム 番号を指定することを意味し、この時点でユーザは何等選択する必要はない。一 方、もしもパンスキャンが利用可能でなく、これはユーザのデフォルトであった ならば、彼は２つの可能性、即ち、各ワイドスクリーンフレームの中央部分が再 生されるセンターカット、或いは、各フレームの全体が見られるが、その表示は 上部及び下部にダークバンドを有するレターボックスの何れかを決定しなければ ならない。メニュー表示が形成されて、ユーザはその２つのモードの内の１つを 選択する。 ユーザに多くの異なる種類の再生を選択させることを許容するにも拘らず、デ ィスク上の共通又は共用アスペクト比のこうした使用は、本発明の設計アプロー チを例証するものである。基本的な考えは、要求されるデータの全てを大ざっぱ にいって従来のＣＤの大きさの光ディスク上に記憶させるにも拘らず、最大限の 柔軟性を提供することにある。一度、ワイドスクリーン映画がディスク上に記憶 されれば、更なる不動産又は物的財産は殆ど要求されずに、ユーザは幾つかの他 のアスペクト比を有するビデオ出力を発生させることが可能になる。１５言語ま であり得て、それでダイアローグが聞こえるが、再生装置に内蔵されたミキシン グ（混合）及びスイッチング（交換）機能と、冗長な情報をオーディオトラック から除去する方法又は態様との故に、１５近くフルサウンドトラックは何処にも ない。同じことがビデオ標準に対して当てはまる。これまでの高品質なビデオは 、ＮＴＳＣ或いはＰＡＬ等々だけで再生可能である媒体を要求してきたが、本発 明では同一ディスクが１２までの標準でのビデオ信号を生じさせることを可能に している。本発明の長所の１つは、例えば、映画を世界中に配給する映画会社に よって制作されねばならない異なるディスクの数を著しく低減することである。 幾つかのフィールドは、時々、変更される必要があるかもしれなく、例えば、ビ デオがＮＴＳＣとＰＡＬとで異なる時にリリースされた時に、そうした変更は比 較的ささいなことであり且つ容易に行われることではあるのだが、異なる標準が 認定されなければならない。 一度、再生モードの決定が為されると、フィールド２２が読取られて、ディス ク上のデータブロックの合計数を決定する。もしも多重バージョンがあれば、各 バージョンのデータブロックの合計数を決定するために、フィールド２３及び２ ４も読取られる。フィールド２５がそれから読取られて、オリジナルフレームレ ート又はフレーム速度を決定し、フィールド２６が読取られて、ブロック時間フ ァクターを決定する。 そうして、フィールド２７が処理される。図３から思い出されるように、これ は、目次の再生のために必要な情報の全てを含むフィールドである。選択された バージョン（もしも唯一のバージョンであればフィールド２７であるが、もしも ２つのバージョンがあって、第２バージョンが選択されたならば、フィールド２ ８である）のための目次は、利用可能のチャプターの再生言語の１００ビット表 示を含む。デフォルトメニュー言語が利用可能な言語と突き合されてチェックさ れる。もしもデフォルトメニュー言語が利用可能でなければ、ユーザにはチャプ タータイトルを表示可能な複数の言語が知らされて、彼はそれらの内の１つを選 択する。一度、チャプター情報を表示すべき言語が決定されたならば、種々の目 次の持続時間が計算される。各チャプター内のブロック数は知らされているので 、各チャプターの持続時間は、ブロック数にブロック時間ファクターを乗算する ことによって決定され得る。 目次は必然的には表示されない。それは、処理のスタート時にＴＯＣ（目次） フラッグがセットされていたときにのみであり、ユーザが目次は表示すべきと指 摘したときにのみ表示される。もしもＴＯＣフラッグが０であれば、目次を表示 する必要はない。システムは、出発点として、第１データブロックを自動的に選 択する、即ち、ディスクの再生はその始めでスタートする。一方、もしもＴＯＣ フラッグが１であれば、目次が表示されて、ユーザには出発点の選択のオプショ ンが与えられる。 ディスク上の表或いは目次に続いては、フィールド５内で認定された標準のた めの暗号化認定コードである。オペレーティングシステムは、選択された標準用 の暗号化認定コードを読取る。それからその選択標準のための所定データを読取 る。思い出されるように、１２通りあり得る標準の各々のために、ディスク上の 所定データが処理されて、認定コードとしての役割を果たす「メッセージ」Ｍを 引き出すことである。それが、各標準に関連するプライベートキーを用いてディ スク上に暗号形態で記憶されたこの認定コードである。ディスクから読取られた データは、同一データが読取られて、暗号化工程の間や再生装置がそれ自体の「 メッセージ」Ｍを引き出す時との両方で同一データが読取られて処理される限り 、各標準毎に異なる可能性がある。先に議論したように、このデータは導入部フ ィールドの少なくとも一部を含むことが好ましく、その理由は、このデータをコ ピーすることを認定された出版社にとって自滅的となるからである。 選択された標準のための所定データが読取られた後、認定コード（「メッセー ジ」Ｍ）はそのデータより計算される。選択された標準に関連すると共に、オペ レーティングシステムに内蔵されたパブリックキーを用いて、その選択された標 準のためにディスク上に記憶された認定コードが復号化される。ソフトウェア出 版社は、その選択された標準でのビデオ信号として再生されることになるディス クを出版することが認定されているのか否かのテストは、復号化認定コードの計 算認定コードとの比較を含む。もしもそれらが合致しなければ、再生は中止され る。 もしもそれらの２つのコードが合致すれば、フィールド３０が読取られる。こ の単一ビットはマスタープロセッサに対して、下述する図４に示された正規の補 数以外に、何等かのコマンド或いはデータがディスク上に記憶されているか否か を単に知らせる。もしもフラッグが０であれば、オペレーティングシステムはデ ータブロック内のそうした追加コマンド或いはデータを捜すことすらしない。も しもフラッグが１であれば、コマンド或いはデータがデータブロック内に存在す る可能性があることを意味するが、必然的にそうであることではない。 最後に、補助ソフトウェアが利用可能か否かを決定するためにフィールド３１ が読取られる。もしもそうであれば、フィールド３２から読取られる。上述した ように、補助ソフトウェアはオペレーティングシステムの代りに使用されること はなく、むしろそれを補助するために用いられる。これは、フィールド４とフィ ールド３２とのソフトウェアの間の基本的な差である。おおまかにいえば、補助 ソフトウェアは、補助ソフトウェアフラッグによって存在が指摘されたフィール ドのデータブロック内に含まれるコマンド及びデータに基づいてオペレートする （必ずしもことごとくのデータブロック内についてではないが、以下の説明から 明らかになる）。 フィールド３２の読取り及びオペレーティングシステムとの調和によって、デ ィスクドライブの読取りヘッドはその出発点まで移動されることになる。先に説 明したように、出発点は第１データブロック或いはその第１データブロック以外 のチャプターが選択されていた場合には、ユーザによって決定されたあるデータ ブロックの何れかである。データブロックは順次読取られて、図２のデマルチプ レクサ６３がそれらデータフィールドを種々のバッファに分配する。フローチャ ー トに示されるように、１つのデータブロックの読取りは、何等バッファが一杯で ないときにのみ生ずる。更に、新しいデータブロックが読取られる前に、システ ムは手助けされるべき何等かの割込みがあるか否かをチェックする。コントロー ラ４１は全ての割込みのソースである。例えば、もしもユーザはキーボードを操 作したとすれば、コントローラは図２のライン４３上に割込みを発生させ、デー タブロックの読取りを一時的に停止する。その割込みが処理された後、或いはも しも手助けすべき割込みが何等なければ、次のデータブロックが読取られる。ブ ロック番号／ポインタアナライザ４７は、要求された次のブロックの番号を知っ ている。殆どの場合、これは単に連続的な順番又はシーケンスの次のブロックと なる。しかしながら、そのブロック番号はそうしたシーケンスから外れているこ ともあり得、例えば、もしも新しいチャプターへジャンプすべきであったり、或 いは以下に説明されるように、映画の多重バージョンの１つを再生する際にある 複数のブロックがディスク上でスキップされねばならない場合がある。何れの場 合においても、システムは読取られるそのブロックが正しいものか否かをチェッ クする。もしもそうでなければ、フローチャートの分岐はブロック読取り工程の スタート時に戻されて、異なるブロックが読取られことができる。図２のゲート ６１は閉じられて、導体２５上の「誤り」データはデマルチプレクサ６３まで延 びない。 もしもブロック読取りが要求されたブロックであれば、ブロック番号の直後に 読取られた第１の事柄の１つはポインタデータである。ポインタデータはブロッ ク番号／ポインタアナライザ４７によって用いられて、このフローチャートの最 後あたりで示されているように、要求された次のデータブロックのブロック番号 を決定する。このブロック番号は、ケーブル４９を通じてマイクロプロセッサデ ィスクドライブコントローラ２７へ伝送され、現行のデータブロックの読取りの 完了時にこのデータブロックとアクセスする。フローチャートの最後に示される ように、現時点で処理されるべきデータブロックの残りが読取られて、上記複数 のバッファへロードされ、これに続いて他のデータブロックが読取られ得る。 これまで見てきたフローチャートは、再生装置の処理を制御している。データ ブロックから読取られたデータによって実際に為されることは、図６のフローチ ャ ートに示されており、このフローチャートは、図４に列挙されたようなデータブ ロック内の複数のフィールドが理解された後に、説明する。しかし、データブロ ック内に含まれたポインタデータの機能を理解するために、図７Ａ及び図７Ｂを 先ず説明する。此等の図面は、１つの映画の個々のバージョン或いは両バージョ ンに関連するデータブロックが相互にどのように関連しているか、そして、選択 された１つのバージョンを再生するためにあるデータブロックをスキップするに はシステムがどのように制御されるか、を示している。 図７Ａ及び図７Ｂ−−ポインタデータの機能 本発明の例証的実施例において、１つのディスク上には同一映画の２つのバー ジョンがあり得る。データブロックの殆どは、此等の２つのバージョンに共通の ビデオ及びオーディオを表わすこととなる。しかしながら、一方のバージョン或 いは他方のバージョンに独特な他のブロックもあり得る。問題は、２つのバージ ョンの内の選択された一方に要求されたデータブロックの連続的な読取りを如何 に制御するかである。 これからの説明の目的のために、文字Ａ、Ｂ並びにＣは、上記映画のバージョ ンＡに独特なデータブロック、バージョンＢに独特なデータブロック、並びに両 バージョンに共通（Common）するデータブロックを、それぞれ識別するために使 用されることになる。図７Ｂはトラックの一部を示し、Ａ、Ｂ或いはＣにラベル 表示された連続的なデータブロックを有する。理解されるように、実際上、何千 という同一タイプの連続したデータブロックがあり得て、ディスク上のデータブ ロックの殆どはタイプＣである。しかしながら、システムが要求されていないデ ータブロックをジャンプする方法を説明するために、図７Ｂは連続した同一タイ プのせいぜい２つのブロックを示す。 図７Ｂに示される２つのシーケンスは、バージョンＢ再生用の上部の一方と、 バージョンＡ再生用の下部の他方とから成る。もしも選択されたのがバージョン Ｂであり、ともかくも左側のＢブロックが再生中にあることを仮定すれば、第４ のブロック、即ちＢブロックへ行くために、次なる２つのＡブロックはジャンプ されねばならないことは明らかである。このブロックが再生された後、次なるＡ ブロックはジャンプされなければならない。それから２つの共通ブロックＣが再 生され、その後に、他のＣへ向かって１つのＡブロックをジャンプしなければな らない。次のブロックであるＢはそれで再生され、それからＢ、Ｃ並びにＢブロ ックが続く。最後に、１つのＡブロックをジャンプして、図７Ｂに示される最後 のブロックであるＣブロックへ向かう。 もしもバージョンＡが再生中であって、２つの連続するＡブロックが再生され るのであれば、１つのＢブロックをジャンプし、次の５つのブロック、即ち、Ａ 、Ｃ、Ｃ、Ａ、Ｃが再生され、次に２つのＢブロックをジャンプしてＣブロック へ向かい、そして最後に他のＢブロックをジャンプしてＡ及びそれに従うＣへ向 かう。 ここに浮び上がるパターンは、一方ブロックから他方ブロックへの３種類の移 行があることである。第１として、先行するブロックの再生に直ちに続く又は従 う１ブロックの再生がある。図７Ｂに示されたこれの７つの例があり、即ち、Ａ Ａ、ＢＢ、ＣＣ、ＣＡ、ＣＢ、ＡＣ並びにＢＣである。除外される２つの可能性 は、ＡＢ及びＢＡであり、これは２つのバージョンに独特である此等ブロックは 決して同一ディスクの再生中に再生されることはなく、ましてや続々と再生され ることはない。ブロックタイプからブロックタイプへの移行には７種類がある一 方、まさにちょうど３つの基本操作又はオペレーション、即ち、任意タイプの１ ブロックから任意タイプの次なるブロックへ行くものと、ＡからＡ又はＣへジャ ンプか或いはＢからＢ又はＣへのジャンプかの何れかと、Ｃブロックから隣接す るＡ又は隣接するＢへの分岐か或いはＣブロックからそのラインを下っての何処 かのＢ又はＡへの分岐かの何れかと、がある。殆どの移行が第１タイプのもので ある。第２タイプはＡにＢが従ったときに生じ（此等２つのブロックは決して連 続して再生されない）、そのＡから他のＡ又はＣの何れかへのジャンプが行われ る必要がある。同様の所見はＡが随伴するＢに対して当てはまる。第３タイプは Ｃブロックの再生の最後で生ずるものであり、再生されるべき共通データがもは や全くない場合で且つ一方バージョン或いは他方バージョンへのスイッチが行わ れる必要があるときで、即ち、次なるブロックはもしも選択されたバージョンの 一部であれば再生され、さもなければ、幾つかのブロックはもしもその分岐が他 方バージョンの１ブロックへ向かうものであればジャンプされねばならないであ ろう。 図７Ａは一方のブロックから他方のブロックへの各種の移行がどのように且つ いつ行われるかを定義する状態図である。以下に説明されるように、各々のデー タブロックは２ビットポインタフラッグを含み、もしかしたら２０ビットポイン タを含むフィールドが随伴される。（１つのポインタがあるとき、それは他のデ ータブロックの連続ブロック番号を常に指向している。）図７Ａに付与されたコ ードに言及すれば、もしも２ビットポインタフラッグが００であれば、それは、 処理が次のブロックについて続行されるべきを示し、この場合、ポインタは全く 必要ない。もしも２ビットポインタフラッグが０１コードであれば、それは、何 処か遠ざかった同一バージョンのブロックへのジャンプか、或いは何処か遠ざか ったＣブロックへのジャンプかがなされるべきことを示している。何れの場合に おいても、ポインタは必要である。 コード１０及び１１は、共通Ｃブロックから分岐が取り行われるべきときに用 いられる。どちらのコードも、次のブロックがＡ或いはＢであるか否かに依存し て用いられる。もしもそのＣの後のブロックがＡであれば、コード１０が用いら れて、そのポインタはそのラインを更に下ってのＢ或いはＣへ向かっている。も しもコードが１１であれば、次のブロックはＢであり、そのポインタはトラック に更に沿ってのＡ或いはＣへ向かっていることを意味する。オペレーションシス テムはどのバージョンが再生中であるかを知っている。もしもバージョンＡが再 生中であり、現行ブロックが１０のポインタフラッグを有していれば、次のブロ ック、即ちＡは現在のものの後に再生されるべきであることを意味する。そのポ インタは必要ない。ポインタが必要となるのは、バージョンＢが再生中である場 合である。この場合、次のブロックがＡであるので、それは再生されるべきでは ない。再生装置はポインタによって識別されるブロックへ、即ち他のＣか或いは 再生中のバージョンＢに独特のＢかの何れかへジャンプすべきである。 同様にして、もしもバージョンＡが再生中であり且つ現行ブロックがＣで、そ のポインタフラッグがコード１１であったならば、次のブロックはＢであること を意味する。バージョンＡが再生中であるので、次のブロックが現行のものの後 に再生されるべきではない。代りに、ポインタによって識別されるＡ或いはＣブ ロックへのジャンプが行われることを意味する。一方、バージョンＢが再生中で あれば、システムは次のブロックへ単に続く。 図７Ａの凡例は、１０及び１１のポインタフラッグがＣブロック内に見出され た際、ポインタが用いられるか否かを示す。表示１０（Ｐ）はポインタが用いら れるべきことを示し、そして表示１０［Ｐ］はポインタが無視されるべきことを 示す。思い出されるように、１０のコードは次のブロックＡである際のＣブロッ クのために用いられる。もしもバージョンＡが再生中であれば、ポインタは必要 とされない。それが、Ｃブロックからそれに続くブロックへ、即ちＡへの移行を 記号１０［Ｐ］によって示す理由である。一方、バージョンＢが再生中であれば 、次のブロックはＡであるので、現行Ｃの後にそれが再生され得ない。代りに、 ポインタによって識別されるブロックへのジャンプと、それ故に表示１０（Ｐ） の使用とがなければならず、このポインタはＢブロック或いは他のＣの何れかを 指す。 同様な所見が表示１１（Ｐ）及び１１［Ｐ］に対して適用される。此等両方の 場合、再生中はＣブロックであり、次のブロックはＢである。もしもバージョン Ａが再生中であれば、次のブロックは再生されるべきではなく、それ故に記号１ １（Ｐ）が状態移行を示すべく要求される。一方、もしもバージョンＢが再生中 であれば、再生させられるべきは次に続くＢブロックであり、それ故に記号１１ ［Ｐ］が適切である。 用法（Ｐ）及び［Ｐ］と共に、４つのコードが図７Ｂに示されている。再生Ｂ の移行シーケンスに言及すれば、示される第１移行は０１（Ｐ）である。思い出 されるように、０１コードは一方バージョンから同一バージョンのブロックへ或 いは共通ブロックへのジャンプを表現し、ポインタが要求される。示された移行 は０１（Ｐ）であり、Ｂブロックから他のＢブロックへのジャンプである。再生 Ｂライン上の次の移行は０１（Ｐ）であり、ＢからＣへジャンプである。次は全 てに対して最も共通する移行例である００であり、現行ブロックの後に次のブロ ックを規則的に又は順序正しく再生する。 再生Ｂラインにおける第４移行は、１０（Ｐ）記号によって表現されている。 １０コードは次のブロックがＡである際のＣブロックからの分岐を表わし、図７ Ｂに図示された例である。そうした場合、図７Ａに示されるように、もしもバー ジョンＢが再生中であれば、ジャンプがポインタによって識別されたブロックへ 、この場合、次のＣへ為される。 １１コードは次のブロックがＢである際にＣブロックからの分岐を識別する。 もしもバージョンＢが再生中であれば、考慮されている場合において、ポインタ は不必要であり、その理由として次のブロックは再生されるべきであるからであ る。それが、示された次のコードが１１［Ｐ］である理由である。隣接ブロック への明らかな移行を表わす２つの００コードが続き、これに１１［Ｐ］コードが 従っており、Ｃブロックからそれに続くＢであるブロックへの分岐である。最後 に、ジャンプがこのＢブロックから次のＡブロックを越えてＣブロックへ行われ る。これは０１（Ｐ）コードを要求し、そのコードは、何れかのバージョンのブ ロックからそれと同一バージョンのブロックへ或いは共通ブロックへジャンプす るために用いられる。 図７Ｂにおける再生Ａシーケンスは、再生中であるのがバージョンＡであるこ とを想定している。最初の４つのコードは、隣接ブロックへの移行、或いは一方 バージョンのブロックからそれと同一バージョンのブロックへのジャンプを表わ している。次のコードである１０［Ｐ］は、Ｃブロックから隣接するＡブロック へのジャンプを示すべく用いられている。ポインタはバージョンＡが再生中であ るので用いられなく、コード１０は次のブロックがＡブロックであるが為に採用 されている。次の００コードはＡブロックから連続するＣブロックへの移行を記 号化又は象徴化している。 次はＣブロックから他のＣブロックへのジャンプであり、２つのＢブロックを スキップしている。この１１コードが用いられる理由は、これはＢブロックがＣ ブロックに従っている又は続いている際に採用されるコードであるからである。 用いられた記号が１１（Ｐ）であり、１１［Ｐ］ではない理由は、１つのＣブロ ックからそのラインを更に下ってのＣブロックへ行く際にポインタが要求される からである。同様にして、次のコードは、再度、１１（Ｐ）コードであり、Ｃブ ロックからそのラインを更に下ってのＡブロックへの分岐を記号化している。図 ７Ｂにおけるシーケンスは、Ａブロックから次のブロックであるＣへの移行によ って 終了しており、この為にコード００が用いられている。 図７Ａの状態図は、全ての可能性を要約している。先ず、その左上方における サークルＡによって表わされるＡブロックが処理中である状態を考えよう。Ａブ ロック内の２ビットポインタフラッグは、もしも次のブロックがまたＡであれば 、００である（ＡからＡへ戻る移行によって示されている）。一方、もしも次の ブロックがＢであれば、それは明らかに再生されるべきではない。そのＡブロッ クからＢを越えて、他のＡ或いはＣの何れかへのジャンプでなければならない。 何れの場合でもそのコードは０１（Ｐ）である。図面は、Ｂを越えてのジャンプ （他のＡまで）と、Ｂを越えてＣへのジャンプとの両方を示している。Ａブロッ クからのただ１つの他の移行は、もしも次のブロックがＣであれば、当該次のブ ロックへの移行である。これがコード００によって示されている。 ４つの同様な移行が状態Ｂ、即ちバージョンＢのデータブロックが読取られて いる時の状態Ｂについて示されている。００コードは、次のブロックがＢ或いは Ｃであれば用いられる。０１（Ｐ）は次のブロックがＡである際に用いられ、そ れがジャンプによって越えられることによって、システムは他のＢ或いはＣを次 に読取ることができる。 Ｃブロックからの移行はより複雑であり、その理由は、Ａブロック及びＢブロ ックの各々についての４つのみというよりは、それらの内の７つがある。もしも 次のブロックが更にＣであれば、そのコードは単に００であり、当該次のブロッ クを読取る。もしも次のブロックがＢであり、且つ他のＣへのジャンプが必要で あれば、コード１０（Ｐ）はＡを越えるジャンプを制御する。同様に、コード１ １（Ｐ）はＢを越えて他のＣへのジャンプを制御する。思い出されるように、此 等２つのコードはＣブロックからの分岐を、次のブロックがＡか或いはＢか否か に依存して制御すべく用いられる。何れの場合も、もしも次のブロックが読取ら れるべきものでなければ、そのブロック（及びそれに類似の１つ以上のブロック ）がジャンプによって越えられて次のＣへ向かう。 しかしながら、Ｃブロックの読取りの後、Ａ或いはＢを読取ることも可能であ る。Ａを読取るために、コード１１（Ｐ）或いは１０［Ｐ］の内の一方が用いら れる。１１コードは次のブロックがＢである際に採用され、その場合にはポイン タが要求される。１０コードは次のブロックがＡである際に採用され、その場合 にはポインタは用いられない。同様に、次にＢブロックを読取るために、コード １０（Ｐ）或いは１１［Ｐ］の内の一方が用いられる。前者はディスク上の次の ブロックがＡである際に採用され、このブロックがジャンプによって越えられる 必要があるので、ポインタが要求される。一方、もしも次のブロックがＢであれ ば、コード１１はシステムに対してこの次なるブロックへ行くことを告げて、ポ インタは必要ないので処理中にそのポインタが無視される。 多分、認識すべき最も重要な点は、図面からは明確ではないことであり、殆ど のブロックは００ポインタフラッグを含み、ポインタがないことである。（この ００コードは随伴するポインタフィールドなしの唯一のものである。）それは、 一度、何れかのバージョンのフレームが再生中となれば、或いは一度、共通デー タのフレームが再生中となれば、殆どの場合に、次のフレームは同一タイプのも のとなるであろう。その結果、００コードだけで仕事を行う。正味の結果は、同 一映画の２つのバージョンがディスク上に記憶されることが可能であることであ って、ユーザ用の何れかの再生のためのオプションと（もしもそれがパーレンタ ルロックによって許可されたならば）、全体的又は総計的なディスク不動産のほ んのちっちゃな小部分を、１ブロックから該ブロックの後に読取られるべき次の ブロックへの移行を制御する家政的又は家計的なビット数によって浪費されるこ ととを伴っている。再度、これは、処理において過度に或いは不当にビット数を 浪費することなく、最大限の柔軟性やできる限り多くのオプションを提供すると 言う、根底をなす設計哲学に調和するものである。 また、注目されるべきことは、本発明は１つの映画のちょうど２つのバージョ ンを１つのディスク上に据えることに限定されるものではないことである。同一 の技術を３つ或いはそれ以上のバージョンについて用いることが可能である（そ うした多数バージョンの需要はおそらくより少ないであろうが）。そうした場合 、共通ブロックは１つのポインタだけではなく、２つのポインタを要求すること になるであろう。もしもディスク上に３つのバージョンがあれば、Ｃブロックに 追従する次のブロックはＡ、Ｂ或いはＤであることなるであろう。２つのポイン タが要求されることになって、そのラインを更に下って見出されるべき２つのブ ロッ クを指示する。明らかにこれは、実行される必要のある変更の内のまさに１つと なる。ポインタは、たとえより多くの家計的又は家計的なビット数の消費となっ ても、多重的なバージョンに便宜を図ることができる。それにも拘らず、このタ イプのポインタビットの全体的な数は、オーディオ／ビデオビット数の全体的な 数と比べて、依然として、とるに足らないものである。 データブロックフィールド 図４はデータブロックの複数フィールドを示し、フォーマットは、図３の導入 部トラックの複数フィールドの為に示したものと同じである。先に議論したよう に、シンクワードパターンはデータ中に現われることができず、それ故にそれが 検出された際に、オペレーティングシステムが新しいデータブロックが開始され ようとしていることを知る。 第２フィールドは２０ビットの連続ブロック番号である。ディスク上のブロッ クの全ては連続順で番号付けがされている。ブロック番号は読取られる第１のこ とであり、それが図２のブロック番号／ポインタアナライザ４７によって用いら れるからである。ブロック番号は、例えば、１つのブロックから他のブロックへ のジャンプの時に必須のものである。読取りヘッドは、通常、その所望ブロック 近くの点に位置付けられているが、第１の試みでは正しいブロックが選択される ことは殆どないであろう。複数ブロック中のビット数が可変的であり、システム がそれらブロック中の一体幾つのビット数がスキップされたかを知る術がないの で、上記のことはまさに真実である。データブロックの最初にブロック番号を読 取ることによって、システムはヘッドが再度位置付けされる必要があるのか否か を迅速に決定する。 第３フィールドは２ビットコードであり、ブロックがＡバージョンの一部か、 Ｂバージョンの一部か、或いは両方に共通するものか否かを表わす。（４つの可 能性があるコードの内の３つだけが使用されている。）一度、バージョンＡ或い はバージョンＢの再生が開始されれば、図７Ａ及び図７Ｂで議論されたポインタ は常に１つのブロックが、再生中に、共通するものか或いはある特定バージョン の一部かを識別することとなるのが、どうして１つの特定ブロックのバージョン について絶えずチェックしなければならないのであろうか。その答えは早送り及 び早戻しの操作又はオペレーションに関係している。此等は全体的には従来技術 であるので長い間議論されてこなかった、例えば早送りの際、読取りヘッドは多 少なりとも随意に位置付けされ得る。ビデオはもしもそれが誤ったバージョンで あれば見せるべきではない。１つのブロックのバージョンを、ブロック番号或い はポインタを見ることによって単純に決定することは不可能である。何れもバー ジョンを識別しない。システムがブロックを最初に読取った時にそのバージョン を決定できるのはこの理由の為のである。 フィールド４及び５は、図７Ａ及び図７Ｂに関連させてくどくどと長い間説明 してきた２ビットポインタフラッグ及び２０ビットポインタを含む。 フィールド６は、存在し得るか否かの１ビットフラッグである。図３に言及す れば、フィールド１９のビデオ可用性フラッグはオペレーションシステムに対し て、データブロック中に何等かのビデオがあるか否かを知らせる。しかしながら 、もしもあったとしても、めいめいのデータブロックがビデオを含むことを意味 しない。めいめいのデータブロックに単一のフレームが表現されていて、データ ブロックが固定されたレートで処理されるシステムでは、たとえそれが「変更な し」を表わす１つのコードから成る「最小」ビデオであっても、めいめいのデー タブロックにビデオがあるであろう。しかし、１つのデータブロックで単一フレ ーム以上或いは以下を表現し得るシステムがある可能性がある。例えば、１デー タブロックのビデオ情報が、もしも本当に存在するのであれば、常に同一ビット 数であることがあり得る。圧縮に依存して、多くのフレームを単一データブロッ ク内に表現させることは可能である。そうした場合、ブロックの内の幾つかはビ デオビットが欠如することになるであろう。採用されたコード化機構に依存して 、フィールド６のビットはオペレーティングシステムに対して、フィールド７は 一体あるのか否かを通知する。もしもビデオがあれば、フィールド７はビデオ情 報を含み、シンクワードをもって終了する。先に述べたように、ビデオ及びオー ディオブロックの実際のコード化は本発明の部分を構成しない。ＭＰＥＧ機構は 好ましいが、他のものが使用可能である。 フィールド８はビットなしから１６までの何れかを含む。思い出されるように 、 導入部トラックのフィールド６は１００ビット位置を含むが、ディスク上にはせ いぜい１６のオーディオトラックが存在し得るので（その内、Ｍ＆Ｅはその内の １つと考えられる）、此等の内のたったＮ個（最大のＮは１６）が値１のビット を表わし得る。此等Ｎトラックの各々について、フィールド８はオペレーション システムに対して、現行のデータブロックには何等かのオーディオがあるか否か を通知する。こうして、最大ＮまでのＸ個（なにがしか又は変数）の「１」が存 在する。Ｎビットフィールド８の第１ビット位置は、導入部トラックのフィール ド６内に識別された第１オーディオ言語トラックに対応する。１データブロック のフィールド８内の第２ビットは、導入部トラックのフィールド６内に表現され た第２オーディオ言語に関連する、等々である。図４のフィールド８内に、１０ ０ではなく、たったＮ個（最大＝１６）しか存在しない理由は、データブロック に存在し得るのはどの言語であるかは導入部トラックから通知されるからである 。対応する言語がディスク上に見出されるべき何処にもないことを導入部トラッ クから通知された際に、それが存在しないことを指摘すべく８４或いはそれ以上 のビット位置を各データブロックに設ける理由はない。心に留めておかなければ いけないことは、図４における値Ｘは図３における値Ｎと等しいものではないこ とである。後者は、ディスク上の何れかにあるオーディオ言語の総数を表わし、 その最大値は１６である。記号ＸはそれらＮの内の幾つのものが現行データブロ ック内に実際に表現されているかを表わしている。 図９はＸ個のオーディオ言語ブロックを含む。ディスク上には１０個のオーデ ィオ言語が表現されているが、その内の６個だけが現行データブロック内に表現 されていることを想定しよう。この場合、そうしたオーディオ言語に対応してい るＸビットシーケンスがあることになり、各々がエスケープ（ＥＳＣ）キャラク タで終了している。エスケープキャラクタは複数のオーディオブロックを相互に 分離すべく使用される。もしも、オーディオトラックが存在する時いつもそれが 固定された持続時間を有すれば、フィールド８から１データブロックに存在する オーディオブロックは幾つかが通知されるので、フィールドの終端にシンクワー ドを提供する必要はない。可変長のオーディオブロックはフィールドの末端にシ ンクワードを要求するであろう。 導入部トラックにおけるフィールド９は、０から６３までの「他の」オーディ オトラックを表わす値を含んでいる。図３に示されるように、Ｍ個のそうした「 他の」オーディオトラックがあり得る一方、それらの各々は現行データブロック 内に表現されることを意味しない。各データブロックにおけるフィールド１０は Ｍビットを含み、ディスク上の「他の」オーディオトラックの各々に１つずつで ある。現行データブロックが、此等Ｍ個のトラックの何れかの為にビット情報を 実際に含むか否かは、フィールド１０の対応するビット位置が１を有するか否か に依存する。もしもＹ個の「１」があり且つＹはＭより少なければ、「他の」オ ーディオトラックの全てが現行データブロック内に表現されているとは限らない 、ことを意味する。フィールド１１はＹ個の「他の」オーディオトラックブロッ クを含み、各々がエスケープキャラクタをもって終了している。理解されるよう に、オーディオトラック及び「他の」オーディオトラックがデータブロック内に 表現される方法は比較できる。 図２に戻れば、思い出されるように、データブロックのデータビットは、オー ディオバッファ、ビデオバッファ、パンスキャンバッファ並びにサブタイトルバ ッファに対してと共に、コマンド／データライン６５を通じてマスターコントロ ーラ４１に対して分配される。ここまで、オーディオブロック、「他の」オーデ ィオブロック並びにビデオブロックの表現は、図４の複数フィールドの分析で考 えられてきた。サブタイトルデータの表現に進む前に理解されるべきは、全ての オーディオ及びビデオデータとは異なって、サブタイトルが表現される方法には 差があることである。後者はブロック毎をベースとして補充され、バッファには 新しいオーディオ及びビデオデータが連続的に補充される。一方、サブタイトル はフレーム毎に変える必要がない。事実上、サブタイトルは、もしもそれが１フ レーム以上の間スクリーン上に残存しなければ、知覚すらされないこととなる。 結果として、一度、サブタイトルデータが図２のバッファ５９に補充されたなら ば、サブタイトルはディスプレイ上に形成させられ、新しいサブタイトル情報が 当該バッファ内にロードされるまで、そこに残存させられる。タイトルを新しい ものを導入することなく除去するためには、ブランクフィールドから成る新しい サブタイトルがそのバッファ内にロードされる。 データブロック内のフィールド１２はＰビットから成り、その各々は導入部ト ラックのフィールド１５内で識別されたＰ個のサブタイトル言語の異なる１つに 対応している。（思い出されるように、複数言語に対応するあらゆる１００ビッ トフィールドは現実には言語を表わしておらず、むしろＭ＆Ｅを表わすことによ って、最大９９個のサブタイトル言語がある。）現行データブロック内に更新が 必要な如何なるサブタイトルも、フィールド１２内のその対応する位置に１を有 する。Ｚの最大値がＰである場合、Ｚ個までの「１」があり得る。 現行データブロックに更新が必要な各サブタイトル言語について、フィールド １３内にその更新が現われる。Ｚ個の更新ブロックがあり、各々がエスケープキ ャラクタをもって終了している。更新ブロックがブランクフィールドであり得る ことを理解することが重要である。これが、１つのサブタイトルが新しいサブタ イトルがまだ生じていない時に除去される方法である。 フィールド１４は存在し得るか否かの１ビットから成る。このフィールドは、 導入部トラックのフィールド２１が１であるときにのみ存在する。そうした場合 、パンスキャン情報はデータブロック内に利用可能である。もしもパンスキャン 情報が利用可能であれば、各データブロックはオペレーティングシステムに対し て、それがパンスキャンの為の新しい出発コラムを実際に含むか否かを告げねば ならない。フィールド１４は単一ビットであって、１つのフラッグであり、パン スキャン更新があるか否かを示す。もしもそのビットが１であれば、フィールド １５は９ビットのコラム番号、即ちパンスキャン更新である。 最後に、フィールド１６は存在し得るか否かの単一ビットであり、導入部トラ ック内のフィールド３０の値に依存する。導入部トラックのこの１ビットフラッ グはオペレーティングシステムに対して、補助コマンド及びデータがデータブロ ックのフィールド１７内に存在し得る否かを告げる。もしもコマンド／データフ ラッグが１であれば、コマンド／データブロックはフィールド１７から読取られ る。このフィールドはエスケープキャラクタをもって終了する。 こうして、１つのデータブロックフィールドは、オーディオ、「他の」オーデ ィオ、ビデオ、パンスキャン情報、サブタイトル並びにコマンド／データブロッ クの、６つまでの異なるタイプのデータを含む。此等は図２に関連されて先に議 論 された６タイプの情報であり、デマルチプレクサ６３が情報の異なるブロックを 、オーディオバッファ、ビデオバッファ、パンスキャンバッファ、サブタイトル バッファ並びにマスターコントローラに分配することを付随する。 データブロックフィールドの処理 １データブロック内のデータの処理は相対的に簡単である。図６のフローチャ ートに示された処理は図４に示されたデータブロックフィールド自体に蟻継ぎし ている。 図２のブロック番号／ポインタアナライザ４７が、データブロックのフィール ド２〜５内に含まれる、連続ブロック番号、バージョン、２ビットポインタフラ ッグ並びにポインタをどのように処理するかは既に説明した。次のフィールドは ビデオ存在フラッグである。図６に示されるように、もしもビデオデータは存在 すると決定されたなら、図２のビデオバッファ５５にはフィールド７のビデオが ロードされる。もしもビデオデータが存在しなければ、バッファはそれにロード されたマーカーを単に有する。 マーカーの必要性を理解することは重要である。オペレーティングシステムが 、ビデオ、オーディオ、サブタイトル等々の情報と常に調和できるようにするた めには、同一データブロックからの情報が幾つかの異なるバッファ内の何処にあ るかを告げることができなければならない。言換えれば、オペレーティングシス テムは、オーディオバッファ内のオーディオデータのどの部分がビデオバッファ 内のビデオデータのどの部分と同伴又は調和するかを知らなくてはならない。さ もなければ、種々の情報項目は相互に調和され得ない。データブロック内に存在 しないデータの為にバッファ内にマーカーを提供することによって、オペレーテ ィングシステムは相互に調和された情報の種々の項目を維持することができる。 次に、オペレーティングシステムはフィールド８を見て、ディスク上のＮ個のオ ーディオトラック（図３を参照）の内の幾つが現行データブロック内に実際に表 現されているかを決定する。同一のことが、フィールド１０内に表現されたＭ個 の「他の」オーディオトラックに対して当てはまる。オーディオ及び「他の」オ ーディオトラックデータの全てはそれらの個々のバッファ内にロードされる。フ ローチャートはオーディオトラックの第１のものと最後のもののためだけのシー ケンスを示している。各場合において、テストが実行されて、オーディオトラッ ク或いは「他の」オーディオトラックは現行データブロック内に存在するデータ を有するか否かを見る。此等トラックの各々のために、何等かが、即ちマーカー が追従された実際のデータか或いはマーカーのみの何れかがその個々のバッファ 内にロードされる結果となる。ビデオ及びオーディオ情報の後、データブロック はサブタイトル更新を含む。もしも選択された言語でのサブタイトル用の更新情 報があれば、それはサブタイトルバッファ内にロードされ、さもなければマーカ ーのみが記憶される。サブタイトルに関係する３つのブロックは、選択されたサ ブタイトル言語に対応している単一トラックのみに関係している。 次にフィールド１４内のパンスキャン更新フラッグが読取られる。もしもパン スキャン更新情報が存在すれば、それが今回はパンスキャンバッファにまたロー ドされる。もしも新しい情報が利用可能でなければ、マーカーがパンスキャンバ ッファ内に単純に据えられ、新しいパンスキャン更新情報がない状態で他のデー タブロックが立ち寄っていることを示す。 最後に、システムはコマンド或いはデータが利用可能であるか否かを決定する （もしも導入部フィールド３０がデータブロック内にまさしく見出されるべきで あれば）。もしも、コマンド／データが存在すれば、即ちデータブロックのフィ ールド１６が１であれば、それはフィールド１７から図２のマスターコントロー ラ４１内のメモリにロードされる。もしもコマンド或いはデータがなければ、マ ーカーだけがマイクロプロセッサメモリにロードされる。 注目すべきことは、図６の処理シーケンスの何れもが、先ず第一に情報のそれ ぞれのタイプがディスク上に利用可能であるか否かのチェックを示していないこ とである。しかし理解されるべきことは、「コマンド／データは存在するか？」 等のテストは実際には２つの部分から成ることである。先ず、導入部トラックの フィールド３０においてデータブロックのコマンド／データフラッグは０か或い は１かどちらか。もしもそれが０であれば、コマンド及びデータはデータブロッ クの処理の間に捜索すらされない。一方、もしも導入部トラックのフィールド３ ０におけるデータフラッグが１である結果として、コマンド或いはデータがデー タブロックに存在し得れば、各データブロックはそのフィールド１６をチェック させて、コマンド／データの存在フラッグは１であるか否かを見る。それはデー タブロックフィールド内のフラッグの値であり、それは、マーカーだけがロード されるか、マーカーが追従したデータビットであるか否かを決定する。同様の所 見がその他のシーケンスに適用される。例えば、もしも導入部トラックからパン スキャン情報がディスク上の何処にも存在しないと決定されれば、パンスキャン 更新は存在するか否かをチェックする理由はない。 本発明は特別な実施例を参照して説明されたが、この実施例は本発明の原理に 関する応用を例証するものであることが理解されるべきである。本発明の精神及 び範囲から逸脱することなく、そうした中に数々の変更等を為すことが可能であ り、他の構成等が工夫し得る。

【手続補正書】 【提出日】１９９６年４月２６日 【補正内容】 請求の範囲 １．ソフトウェア担体の再生時にサブタイトルの表示を制御するシステムであ って、前記ソフトウェア担体上に、 （ｉ）画像プログラムと、 （ｉｉ）前記画像プログラムに同期する少なくとも１つのオーディオ・トラッ クと、 （ｉｉｉ）それぞれ、それぞれの言語にサブタイトルを表すサブタイトル・デ ータを含む、複数のサブタイトル・トラックと、 （ｉｖ）利用可能なサブタイトル言語を示す１組のサブタイトル・コードが記 録され、前記システムが、 （ａ）前記ソフトウェア担体を再生し、前記ソフトウェア担体から前記サブタ イトル・コード、前記サブタイトル・データ、画像信号、オーディオ信号を導く 手段と、 （ｂ）表示すべきサブタイトル言語を選択する手段と、 （ｃ）前記サブタイトル・コードおよび選択された言語に応答して、選択され た言語のサブタイトルを表すサブタイトル・データを処理し、そのようなサブタ イトルの表示を前記画像信号および前記オーディオ信号に同期するように制御す る手段とを備え、 前記画像プログラム、少なくとも１つのオーディオ・トラック、前記複数のサ ブタイトル・トラックがすべて、前記ソフトウェア担体上の別々に識別できるブ ロックに記憶され、個別の担体ブロックに複数の異なるタイプのデータを記録す ることができ、各担体ブロックが、それぞれの異なるタイプのデータ用の可変長 区域を有し、かつブロック中のどのサブタイトル・トラックがサブタイトル・デ ータを含むかを示すものを含み、前記処理手段が、選択された言語のサブタイト ルを表すデータを含むブロック中のサブタイトル・トラックのみを処理すること を特徴とするシステム。 ２．さらに、デフォルト言語を表現する手段と、前記デフォルト言語が前記利 用可能な言語のどれにも合致しないことに応答して、ユーザが、利用可能な言語 のうちの１つを選択できるようにする手段とを含むことを特徴とする請求項１に 記載のシステム。 ３．ソフトウェア担体の再生時にサブタイトルの表示を制御するシステムであ って、前記ソフトウェア担体上に、 （ｉ）画像プログラムと、 （ｉｉ）それぞれ、それぞれの言語にサブタイトルを表すサブタイトル・デー タを含む、複数のサブタイトル・トラックが記録され、前記システムが、 （ａ）前記ソフトウェア担体を再生し、前記ソフトウェア担体から前記サブタ イトル・データおよび画像信号を導く手段と、 （ｂ）表示すべきサブタイトル言語を選択する手段と、 （ｃ）選択された言語のサブタイトルを表すサブタイトル・データを処理し、 そのようなサブタイトルの表示を前記画像信号およびオーディオ信号に同期する ように制御する手段とを備え、 前記画像プログラムおよび前記複数のサブタイトル・トラックがすべて、前記 ソフトウェア担体上の別々に識別できるブロックに記憶され、個別の担体ブロッ クに複数の異なるタイプのデータを記録することができ、各担体ブロックが、そ れぞれの異なるタイプのデータ用の可変長区域を有し、かつブロック中のどのサ ブタイトル・トラックがサブタイトル・データを含むかを示すものを含み、前記 処理手段が、選択された言語のサブタイトルを表すデータを含むブロック中のサ ブタイトル・トラックのみを処理することを特徴とするシステム。 ４．さらに、デフォルト言語を表現する手段と、前記デフォルト言語が前記担 体上でサブタイトルが表現される言語のどれにも合致しないことに応答して、ユ ーザが、利用可能な言語のうちの１つを選択できるようにする手段とを含むこと を特徴とする請求項３に記載のシステム。 ５．ソフトウェア担体の再生時にサブタイトルの表示を制御する方法であって 、前記ソフトウェア担体上に、 （ｉ）画像プログラムと、 （ｉｉ）前記画像プログラムに同期する少なくとも１つのオーディオ・トラッ クと、 （ｉｉｉ）それぞれ、それぞれの言語にサブタイトルを表すサブタイトル・デ ータを含む、複数のサブタイトル・トラックと、 （ｉｖ）利用可能なサブタイトル言語を示す１組のサブタイトル・コードが記 録され、前記方法が、 （ａ）前記ソフトウェア担体を再生し、前記ソフトウェア担体から前記サブタ イトル・コード、前記サブタイトル・データ、画像信号、オーディオ信号を導く ステップと、 （ｂ）表示すべきサブタイトル言語を選択するステップと、 （ｃ）前記サブタイトル・コードおよび選択された言語に応じて、選択された 言語のサブタイトルを表すサブタイトル・データを処理し、選択された言語によ るそのようなサブタイトルの表示を制御し前記画像信号および前記オーディオ信 号に同期するように制御するステップとを含み、 前記画像プログラム、少なくとも１つのオーディオ・トラック、前記複数のサ ブタイトル・トラックがすべて、前記ソフトウェア担体上の別々に識別できるブ ロックに記憶され、個別の担体ブロックに複数の異なるタイプのデータを記録す ることができ、各担体ブロックが、それぞれの異なるタイプのデータ用の可変長 区域を有し、かつブロック中のどのサブタイトル・トラックがサブタイトル・デ ータを含むかを示すものを含み、前記処理ステップが、選択された言語のサブタ イトルを表すデータを含むブロック中のサブタイトル・トラックのみを処理する ことを特徴とする方法。 ６．さらに、デフォルト言語を表現するステップと、前記デフォルト言語が前 記利用可能な言語のどれにも合致しないことに応答して、ユーザが、利用可能な 言語のうちの１つを選択できるようにするステップとを含むことを特徴とする請 求項５に記載の方法。 ７．ソフトウェア担体の再生時にサブタイトルの表示を制御する方法であって 、前記ソフトウェア担体上に、 （ｉ）画像プログラムと、 （ｉｉ）それぞれ、それぞれの言語にサブタイトルを表すサブタイトル・デー タを含む、複数のサブタイトル・トラックが記録され、前記方法が、 （ａ）前記ソフトウェア担体を再生し、前記ソフトウェア担体から前記サブタ イトル・データおよび画像信号を導くステップと、 （ｂ）表示すべきサブタイトル言語を選択するステップと、 （ｃ）選択された言語のサブタイトルを表すサブタイトル・データを処理し、 そのようなサブタイトルの表示を前記画像信号に同期するように制御するステッ プとを含み、 前記画像プログラムおよび前記複数のサブタイトル・トラックがすべて、前記 ソフトウェア担体上の別々に識別できるブロックに記憶され、個別の担体ブロッ クに複数の異なるタイプのデータを記録することができ、各担体ブロックが、そ れぞれの異なるタイプのデータ用の可変長区域を有し、かつブロック中のどのサ ブタイトル・トラックがサブタイトル・データを含むかを示すものを含み、前記 処理ステップが、選択された言語のサブタイトルを表すデータを含むブロック中 のサブタイトル・トラックのみを処理することを特徴とする方法。 ８．さらに、デフォルト言語を表現するステップと、前記デフォルト言語が前 記利用可能な言語のどれにも合致しないことに応答して、ユーザが、利用可能な 言語のうちの１つを選択できるようにするステップとを含むことを特徴とする請 求項７に記載の方法。

───────────────────────────────────────────────────── フロントページの続き (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，ＬＵ，Ｍ Ｃ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ，ＣＧ ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ，ＳＮ， ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＭＷ，ＳＤ，ＳＺ)，ＡＭ， ＡＴ，ＡＵ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，Ｃ Ｎ，ＣＺ，ＤＥ，ＤＫ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，ＨＵ ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ，ＬＫ，ＬＴ， ＬＵ，ＬＶ，ＭＤ，ＭＧ，ＭＮ，ＭＷ，ＮＬ，ＮＯ，Ｎ Ｚ，ＰＬ，ＰＴ，ＲＯ，ＲＵ，ＳＤ，ＳＥ，ＳＩ，ＳＫ ，ＴＪ，ＴＴ，ＵＡ，ＵＺ，ＶＮ (72)発明者 クックソン、クリストファー・ジェイ アメリカ合衆国、カリフォルニア州 90046、ロサンジェルス、トリソン・ドラ イブ 7825 (72)発明者 ライバーファーブ、ワレン・エヌ アメリカ合衆国、カリフォルニア州 90077、ロサンジェルス、マルホランド・ ドライブ 15147

Claims (1)

1. 【特許請求の範囲】 １．ソフトウェア担体の再生時にサブタイトルの表示を制御するシステムであ って、前記ソフトウェア担体上に、 （ｉ）画像プログラムと、 （ｉｉ）前記画像プログラムに同期する少なくとも１つのオーディオ・トラッ クと、 （ｉｉｉ）それぞれ、それぞれの言語にサブタイトルを表すデータを含む、複 数のサブタイトル・トラックと、 （ｉｖ）利用可能なサブタイトル言語を示す１組のコードが記録され、前記シ ステムが、 （ａ）前記ソフトウェア担体を再生し、前記ソフトウェア担体から前記サブタ イトル・コード、前記サブタイトル・データ、画像信号、オーディオ信号を導く 手段と、 （ｂ）表示すべきサブタイトル言語を選択する手段と、 （ｃ）前記サブタイトル・コードおよび選択された言語に応答して、選択され た言語のサブタイトルを表すサブタイトル・データを処理し、そのようなサブタ イトルの表示を前記画像信号および前記オーディオ信号に同期するように制御す る手段とを備えることを特徴とするシステム。 ２．前記ソフトウェア担体上に記憶される情報が、別々に識別できるブロック に記憶され、各ソフトウェア担体ブロックが、ブロック中のどのサブタイトル・ トラックがサブタイトル・データを含むかを示すものを含み、前記処理手段が、 選択された言語のサブタイトルを表すデータを含むブロック中のサブタイトル・ トラックのみを処理することを特徴とする請求項１に記載のシステム。 ３．さらに、デフォルト言語を表現する手段を含み、前記選択手段が、表現さ れるデフォルト言語およびソフトウェア担体上で利用できるサブタイトル言語に 応じて動作することを特徴とする請求項２に記載のシステム。 ４．さらに、前記デフォルト言語が前記利用可能な言語のどれにも合致しない ことに応答して、ユーザが、利用可能な言語のうちの１つを選択できるようにす る手段を含むことを特徴とする請求項３に記載のシステム。 ５．さらに、デフォルト言語を表現する手段を含み、前記選択手段が、表現さ れるデフォルト言語およびソフトウェア担体上で利用できるサブタイトル言語に 応じて動作することを特徴とする請求項１に記載のシステム。 ６．さらに、前記デフォルト言語が前記利用可能な言語のどれにも合致しない ことに応答して、ユーザが、利用可能な言語のうちの１つを選択できるようにす る手段を含むことを特徴とする請求項５に記載のシステム。 ７．ソフトウェア担体の再生時にサブタイトルの表示を制御するシステムであ って、前記ソフトウェア担体上に、 （ｉ）画像プログラムと、 （ｉｉ）それぞれ、それぞれの言語にサブタイトルを表すデータを含む、複数 のサブタイトル・トラックが記録され、前記システムが、 （ａ）前記ソフトウェア担体を再生し、前記ソフトウェア担体から前記サブタ イトル・データおよび画像信号を導く手段と、 （ｂ）表示すべきサブタイトル言語を選択する手段と、 （ｃ）選択された言語のサブタイトルを表すサブタイトル・データを処理し、 そのようなサブタイトルの表示を前記画像信号に同期するように制御する手段と を備えることを特徴とするシステム。 ８．前記ソフトウェア担体上に記憶される情報が、別々に識別できるブロック に記憶され、各ソフトウェア担体ブロックが、ブロック中のどのサブタイトル・ トラックがサブタイトル・データを含むかを示すものを含み、前記処理手段が、 選択された言語のサブタイトルを表すデータを含むブロック中のサブタイトル・ トラックのみを処理することを特徴とする請求項７に記載のシステム。 ９．さらに、デフォルト言語を表現する手段を含み、前記選択手段が、表現さ れるデフォルト言語およびソフトウェア担体上で利用できるサブタイトル言語に 応じて動作することを特徴とする請求項８に記載のシステム。 １０．さらに、前記デフォルト言語が前記利用可能な言語のどれにも合致しな いことに応答して、ユーザが、利用可能な言語のうちの１つを選択できるように する手段を含むことを特徴とする請求項９に記載のシステム。 １１．さらに、デフォルト言語を表現する手段を含み、前記選択手段が、表現 されるデフォルト言語およびソフトウェア担体上で利用できるサブタイトル言語 に応じて動作することを特徴とする請求項７に記載のシステム。 １２．さらに、前記デフォルト言語が前記利用可能な言語のどれにも合致しな いことに応答して、ユーザが、利用可能な言語のうちの１つを選択できるように する手段を含むことを特徴とする請求項１１に記載のシステム。 １３．ソフトウェア担体の再生時にサブタイトルの表示を制御する方法であっ て、前記ソフトウェア担体上に、 （ｉ）画像プログラムと、 （ｉｉ）前記画像プログラムに同期する少なくとも１つのオーディオ・トラッ クと、 （ｉｉｉ）それぞれ、それぞれの言語にサブタイトルを表すデータを含む、複 数のサブタイトル・トラックと、 （ｉｖ）利用可能なサブタイトル言語を示す１組のコードが記録され、前記方 法が、 （ａ）前記ソフトウェア担体を再生し、前記ソフトウェア担体から前記サブタ イトル・コード、前記サブタイトル・データ、画像信号、オーディオ信号を導く ステップと、 （ｂ）表示すべきサブタイトル言語を選択するステップと、 （ｃ）前記サブタイトル・コードおよび選択された言語に応じて、選択された 言語のサブタイトルを表すサブタイトル・データを処理し、そのようなサブタイ トルの表示を前記画像信号および前記オーディオ信号に同期するように制御する ステップとを含むことを特徴とする方法。 １４．前記ソフトウェア担体上に記憶される情報が、別々に識別できるブロッ クに記憶され、各ソフトウェア担体ブロックが、ブロック中のどのサブタイトル ・トラックがサブタイトル・データを含むかを示すものを含み、前記処理ステッ プで、動作が、選択された言語のサブタイトルを表すデータを含むブロック中の サブタイトル・トラックに対してのみ実行されることを特徴とする請求項１３に 記載の方法。 １５．さらに、デフォルト言語を表現するステップを含み、前記選択ステップ で、表現されるデフォルト言語およびソフトウェア担体上で利用できるサブタイ トル言語に応じて言語が選択されることを特徴とする請求項１４に記載の方法。 １６．さらに、前記デフォルト言語が前記利用可能な言語のどれにも合致しな いことに応答して、ユーザが、利用可能な言語のうちの１つを選択できるように するステップを含むことを特徴とする請求項１５に記載の方法。 １７．さらに、デフォルト言語を表現するステップを含み、前記選択ステップ で、表現されるデフォルト言語およびソフトウェア担体上で利用できるサブタイ トル言語に応じて言語が選択されることを特徴とする請求項１３に記載の方法。 １８．さらに、前記デフォルト言語が前記利用可能な言語のどれにも合致しな いことに応答して、ユーザが、利用可能な言語のうちの１つを選択できるように するステップを含むことを特徴とする請求項１７に記載の方法。 １９．ソフトウェア担体の再生時にサブタイトルの表示を制御する方法であっ て、前記ソフトウェア担体上に、 （ｉ）画像プログラムと、 （ｉｉ）それぞれ、それぞれの言語にサブタイトルを表すデータを含む、複数 のサブタイトル・トラックが記録され、前記方法が、 （ａ）前記ソフトウェア担体を再生し、前記ソフトウェア担体から前記サブタ イトル・データおよび画像信号を導くステップと、 （ｂ）表示すべきサブタイトル言語を選択するステップと、 （ｃ）選択された言語のサブタイトルを表すサブタイトル・データを処理し、 そのようなサブタイトルの表示を前記画像信号に同期するように制御するステッ プとを備えることを特徴とする方法。 ２０．前記ソフトウェア担体上に記憶される情報が、別々に識別できるブロッ クに記憶され、各ソフトウェア担体ブロックが、ブロック中のどのサブタイトル ・トラックがサブタイトル・データを含むかを示すものを含み、前記処理ステッ プで、動作が、選択された言語のサブタイトルを表すデータを含むブロック中の サブタイトル・トラックに対してのみ実行されることを特徴とする請求項１９に 記載の方法。 ２１．さらに、デフォルト言語を表現するステップを含み、前記選択ステップ で、表現されるデフォルト言語およびソフトウェア担体上で利用できるサブタイ トル言語に応じて言語が選択されることを特徴とする請求項２０に記載の方法。 ２２．さらに、前記デフォルト言語が前記利用可能な言語のどれにも合致しな いことに応答して、ユーザが、利用可能な言語のうちの１つを選択できるように するステップを含むことを特徴とする請求項２１に記載の方法。 ２３．さらに、デフォルト言語を表現するステップを含み、前記選択ステップ で、表現されるデフォルト言語およびソフトウェア担体上で利用できるサブタイ トル言語に応じて言語が選択されることを特徴とする請求項１９に記載の方法。 ２４．さらに、前記デフォルト言語が前記利用可能な言語のどれにも合致しな いことに応答して、ユーザが、利用可能な言語のうちの１つを選択できるように するステップを含むことを特徴とする請求項２３に記載の方法。 ２５．（ｉ）画像プログラムと、 （ｉｉ）前記映画に同期する少なくとも１つのオーディオ・トラックと、 （ｉｉｉ）それぞれ、それぞれの言語のサブタイトルを表すデータを含む、複 数のサブタイトル・トラックと、 （ｉｖ）利用可能なサブタイトル言語を示す１組のコードが記録されるソフト ウェア担体。 ２６．前記ソフトウェア担体上に記憶される情報が、別々に識別できるブロッ クに記憶され、各ソフトウェア担体ブロックが、ブロック中のどのサブタイトル ・トラックがサブタイトル・データを含むかを示すものを含むことを特徴とする 請求項２５に記載のソフトウェア担体。 ２７．（ｉ）画像プログラムと、 （ｉｉ）それぞれ、それぞれの言語のサブタイトルを表すデータを含む、複数 のサブタイトル・トラックと、 （ｉｉｉ）利用可能なサブタイトル言語を示す１組のコードが記録されるソフ トウェア担体。 ２８．前記ソフトウェア担体上に記憶される情報が、別々に識別できるブロッ クに記憶され、各ソフトウェア担体ブロックが、ブロック中のどのサブタイトル ・ トラックがサブタイトル・データを含むかを示すものを含むことを特徴とする請 求項２７に記載のソフトウェア担体。