JPH08510850A

JPH08510850A - ソフトウェア担体の複数のオーディオ・トラックの再生を制御するシステムおよび方法

Info

Publication number: JPH08510850A
Application number: JP7512702A
Authority: JP
Inventors: オストローヴァー、ルイス・ジェイ; クックソン、クリストファー・ジェイ; ライバーファーブ、ワレン・エヌ
Original assignee: Time Warner Entertainment Co LP
Current assignee: Time Warner Cable Enterprises LLC
Priority date: 1993-10-29
Filing date: 1994-10-13
Publication date: 1996-11-12
Anticipated expiration: 2014-09-13
Also published as: ES2149891T3; ATE219855T1; CA2175064A1; AU673635B2; DK0729621T3; CA2175064C; ES2178329T3; KR100211554B1; DE69430878T2; EP0967610B1; EP0729621A1; WO1995012180A1; EP0967610A1; DK0967610T3; AU7982394A; DE69425069D1; GR3034384T3; DE69425069T2; US5469370A; PT729621E

Abstract

(57)【要約】位相反転によってフル・ミックスから特定のトラックを減じることを含め、光ディスク（２３）上に記録された多数のオーディオ・トラックを選択的に組み合わせるシステム。各トラックは、個別の楽器または楽器群の録音を含むことができる。ディスク（２３）を再生すると、再生装置は多数の選択肢（７９）、すなわち、どのトラックを再生して混合すべきかをユーザに提示する。このように、ユーザは、ユーザ自体のオーケストラ・ミックスを作成し、おそらく「プレイアロング」アプリケーションにおいて楽器を削除し、あるいは練習のためにまねるべき１つの楽器のみを再生することができる。ディスク（２３）はさらに、同じディスク（２３）を世界全体で配給できるように複数の言語（７９）のトラック定義を含み、メニュー選択肢（７９）は、ユーザが選択した言語で与えられる。

Description

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

【手続補正書】【提出日】１９９６年４月２２日【補正内容】請求の範囲１．ソフトウェア担体のオーディオ・トラックの再生を制御するシステムであって、前記ソフトウェア担体が、相互に同期し、それぞれに、複数のオーディオ・トラック自体のうちの他のトラックに記録されたオーディオ情報と選択的に組み合わせるべきオーディオ情報が記録された、複数のオーディオ・トラックと、前記トラックのオーディオ内容を定義するテキスト・データとを有し、前記システムが、前記ソフトウェア担体を再生し前記ソフトウェア担体から前記テキスト・データおよび前記オーディオ情報を導く手段と、前記テキスト・データから導かれたメニューをユーザに表示し、組み合わせるべき利用可能なオーディオ情報を前記ユーザに通知する手段と、前記ユーザが、表示されたメニュー選択肢に基づいて利用可能なオーディオ情報を組み合わせる方法を入力できるようにする手段と、前記トラックのうちの少なくとも１つのトラック中のオーディオ情報を位相反転する手段と、位相反転されたオーディオ情報を含む選択されたオーディオ情報をユーザ入力に従って組み合わせる手段とを備えることを特徴とするシステム。２．前記ソフトウェア担体上に記録されるオーディオ情報が、別々に識別可能なブロックにディジタル的に記録されることを特徴とする請求項１に記載のシステム。３．各ソフトウェア担体ブロックが、ブロック中のどのオーディオ・トラックがオーディオ情報を含むかを示すものを含み、前記組合せ手段が、前記ユーザ入力に従ってオーディオ情報を組み合わせるために必要なブロック中のオーディオ・トラックにしか作用しないことを特徴とする請求項２に記載のシステム。４．前記ソフトウェア担体上に、各オーディオ・トラックのタイプのＩＤが記録され、システム自体がさらに、前記トラック・タイプＩＤに従って、導かれたオーディオ情報を処理する手段を含むことを特徴とする請求項３に記載のシステム。５．前記ソフトウェア担体上のテキスト・データが複数の言語のデータであり、前記ソフトウェア担体上にさらに、前記各言語に関するコードが記録され、システム自体がさらに、前記メニューが表示される１つの言語を選択する手段を含むことを特徴とする請求項１に記載のシステム。６．さらに、デフォルト言語を表現する手段を含み、１つの言語を選択する前記手段が、前記デフォルト言語と、ソフトウェア担体上に前記テキスト・データを含めるために使用された複数の言語との両方に従って言語を選択するように動作することを特徴とする請求項５に記載のシステム。７．さらに、前記デフォルト言語が前記複数の言語のどれにも合致しないことに応答して、ユーザが利用可能な言語のうちの１つを選択できるようにする手段を含むことを特徴とする請求項６に記載のシステム。８．前記表示手段が、前記トラックのオーディオ内容を定義するテキスト・データに基づいて、標準的な１組のメニュー選択肢を表示することを特徴とする請求項７に記載のシステム。９．前記標準的な１組のメニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項８に記載のシステム。１０．前記レベルが、オーディオ情報のトラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項９に記載のシステム。１１．前記ソフトウェア担体が、非標準メニュー選択肢の表示と、非標準メニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、システム自体がさらに、前記ソフトウェアを処理し、その後前記ソフトウェアに従って動作する手段を含むことを特徴とする請求項１０に記載のシステム。１２．前記ソフトウェア担体上に、各オーディオ・トラックのタイプのＩＤが記録され、システム自体がさらに、前記トラック・タイプＩＤに従って、導かれたオーディオ情報を処理する手段を含むことを特徴とする請求項１に記載のシステム。１３．前記表示手段が、前記トラックのオーディオ内容を定義するテキスト・データに基づいて、標準的な１組のメニュー選択肢を表示することを特徴とする請求項１に記載のシステム。１４．前記標準的な１組のメニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項１３に記載のシステム。１５．前記レベルが、オーディオ情報のトラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項１４に記載のシステム。１６．ソフトウェア担体が、非標準メニュー選択肢の表示と、非標準メニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、システム自体がさらに、前記ソフトウェアを処理し、その後前記ソフトウェアに従って動作する手段を含むことを特徴とする請求項１５に記載のシステム。１７．前記メニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項１に記載のシステム。１８．前記レベルが、あるオーディオ情報トラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項１７に記載のシステム。１９．ソフトウェア担体が、担体特有のメニュー選択肢の表示と、担体特有のメニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、システム自体がさらに、前記ソフトウェアを処理し、その後前記ソフトウェアに従って動作する手段を含むことを特徴とする請求項１８に記載のシステム。２０．ソフトウェア担体が、担体特有のメニュー選択肢の表示と、担体特有のメニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、システム自体がさらに、前記ソフトウェアを処理し、その後前記ソフトウェアに従って動作する手段を含むことを特徴とする請求項１に記載のシステム。２１．ソフトウェア担体のオーディオ・トラックの再生を制御する方法であって、前記ソフトウェア担体が、相互に同期し、それぞれに、複数のオーディオ・トラック自体のうちの他のトラックに記録されたオーディオ情報と選択的に組み合わせるべきオーディオ情報が記録された、複数のオーディオ・トラックと、前記トラックのオーディオ内容を定義するテキスト・データとを有し、前記方法が、前記ソフトウェア担体を再生し前記ソフトウェア担体から前記テキスト・データおよび前記オーディオ情報を導くステップと、前記テキスト・データから導かれたメニューをユーザに表示し、組み合わせるべき利用可能なオーディオ情報を前記ユーザに通知するステップと、前記ユーザが、表示されたメニュー選択肢に基づいて利用可能なオーディオ情報を組み合わせる方法を入力できるようにするステップと、前記トラックのうちの少なくとも１つのトラック中のオーディオ情報を位相反転することを含め、選択されたオーディオ情報をユーザ入力に従って組み合わせるステップとを含むことを特徴とする方法。２２．前記ソフトウェア担体上に記録されるオーディオ情報が、別々に識別可能なブロックにディジタル的に記録され、各ソフトウェア担体ブロックが、ブロック中のどのオーディオ・トラックがオーディオ情報を含むかを示すものを含み、前記組合せステップで、動作が、前記ユーザ入力に従ってオーディオ情報を組み合わせるために必要なブロック中のオーディオ・トラックにしか実行されないことを特徴とする請求項２１に記載の方法。２３．前記ソフトウェア担体上に、各オーディオ・トラックのタイプのＩＤが記録され、方法自体がさらに、前記トラック・タイプＩＤに従って、導かれたオーディオ情報を処理するステップを含むことを特徴とする請求項２２に記載の方法。２４．前記ソフトウェア担体上のテキスト・データが複数の言語のデータであり、前記ソフトウェア担体上にさらに、前記各言語に関するコードが記録され、方法自体がさらに、前記メニューが表示される１つの言語を選択するステップを含むことを特徴とする請求項２１に記載の方法。２５．さらに、デフォルト言語を表現するステップを含み、１つの言語を選択する前記ステップで、前記デフォルト言語と、ソフトウェア担体上に前記テキスト・データを含めるために使用された複数の言語との両方に従って言語が選択されることを特徴とする請求項２４に記載の方法。２６．さらに、前記デフォルト言語が前記複数の言語のどれにも合致しないことに応答して、ユーザが利用可能な言語のうちの１つを選択できるようにするステップを含むことを特徴とする請求項２５に記載の方法。２７．前記表示ステップで、前記トラックのオーディオ内容を定義するテキスト・データに基づいて、標準的な１組のメニュー選択肢が表示されることを特徴とする請求項２１に記載の方法。２８．前記標準的な１組のメニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項２７に記載の方法。２９．前記レベルが、あるオーディオ情報トラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項２８に記載の方法。３０．ソフトウェア担体が、非標準メニュー選択肢の表示と、非標準メニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、方法自体がさらに、前記ソフトウェアを処理し、その後前記ソフトウェアに従って動作するステップを含むことを特徴とする請求項２９に記載の方法。３１．前記メニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項２１に記載の方法。３２．前記レベルが、オーディオ情報のトラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項３１に記載の方法。３３．ソフトウェア担体が、担体特有のメニュー選択肢の表示と、担体特有のメニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、方法自体がさらに、前記ソフトウェアを処理し、その後前記ソフトウェアに従って動作するステップを含むことを特徴とする請求項３２に記載の方法。３４．ソフトウェア担体が、担体特有のメニュー選択肢の表示と、担体特有のメニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、方法自体がさらに、前記ソフトウェアを処理し、その後前記ソフトウェアに従って動作するステップを含むことを特徴とする請求項２１に記載の方法。

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

Claims

【特許請求の範囲】１．ソフトウェア担体のオーディオ・トラックの再生を制御するシステムであって、前記ソフトウェア担体が、相互に同期し、それぞれに、複数のオーディオ・トラック自体のうちの他のトラックに記録されたオーディオ情報と選択的に組み合わせるべきオーディオ情報が記録された、複数のオーディオ・トラックと、前記トラックのオーディオ内容を定義するテキスト・データとを有し、前記システムが、前記ソフトウェア担体を再生し前記ソフトウェア担体から前記テキスト・データおよび前記オーディオ情報を導く手段と、前記テキスト・データから導かれたメニューをユーザに表示し、組み合わせるべき利用可能なオーディオ情報を前記ユーザに通知する手段と、前記ユーザが、表示されたメニュー選択肢に基づいて利用可能なオーディオ情報を組み合わせる方法を入力できるようにする手段と、前記トラックのうちの少なくとも１つのトラック中のオーディオ情報を位相反転する手段と、位相反転されたオーディオ情報を含む選択されたオーディオ情報をユーザ入力に従って組み合わせる手段とを備えることを特徴とするシステム。２．前記ソフトウェア担体上に記録されるオーディオ情報が、別々に識別可能なブロックにディジタル的に記録されることを特徴とする請求項１に記載のシステム。３．各ソフトウェア担体ブロックが、ブロック中のどのオーディオ・トラックがオーディオ情報を含むかを示すものを含み、前記組合せ手段が、前記ユーザ入力に従ってオーディオ情報を組み合わせるために必要なブロック中のオーディオ・トラックにしか作用しないことを特徴とする請求項２に記載のシステム。４．前記ソフトウェア担体上に、各オーディオ・トラックのタイプのＩＤが記録され、システム自体がさらに、前記トラック・タイプＩＤに従って、導かれたオーディオ情報を処理する手段を含むことを特徴とする請求項３に記載のシステム。５．前記ソフトウェア担体上のテキスト・データが複数の言語のデータであり、前記ソフトウェア担体上にさらに、前記各言語に関するコードが記録され、システム自体がさらに、前記メニューが表示される１つの言語を選択する手段を含むことを特徴とする請求項１に記載のシステム。６．さらに、デフォルト言語を表現する手段を含み、１つの言語を選択する前記手段が、前記デフォルト言語と、ソフトウェア担体上に前記テキスト・データを含めるために使用された複数の言語との両方に従って言語を選択するように動作することを特徴とする請求項５に記載のシステム。７．さらに、前記デフォルト言語が前記複数の言語のどれにも合致しないことに応答して、ユーザが利用可能な言語のうちの１つを選択できるようにする手段を含むことを特徴とする請求項６に記載のシステム。８．前記表示手段が、前記トラックのオーディオ内容を定義するテキスト・データに基づいて、標準的な１組のメニュー選択肢を表示することを特徴とする請求項７に記載のシステム。９．前記標準的な１組のメニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項８に記載のシステム。１０．前記レベルが、オーディオ情報のトラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項９に記載のシステム。１１．ソフトウェア担体が、非標準メニュー選択肢の表示と、非標準メニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、システム自体がさらに、前記ソフトウェアを読み取り、その後前記ソフトウェアに従って動作する手段を含むことを特徴とする請求項１０に記載のシステム。１２．前記ソフトウェア担体上に、各オーディオ・トラックのタイプのＩＤが記録され、システム自体がさらに、前記トラック・タイプＩＤに従って、導かれたオーディオ情報を処理する手段を含むことを特徴とする請求項１に記載のシステム。１３．前記表示手段が、前記トラックのオーディオ内容を定義するテキスト・データに基づいて、標準的な１組のメニュー選択肢を表示することを特徴とする請求項１に記載のシステム。１４．前記標準的な１組のメニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項１３に記載のシステム。１５．前記レベルが、オーディオ情報のトラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項１４に記載のシステム。１６．ソフトウェア担体が、非標準メニュー選択肢の表示と、非標準メニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、システム自体がさらに、前記ソフトウェアを読み取り、その後前記ソフトウェアに従って動作する手段を含むことを特徴とする請求項１５に記載のシステム。１７．前記メニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項１に記載のシステム。１８．前記レベルが、あるオーディオ情報トラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項１７に記載のシステム。１９．ソフトウェア担体が、担体特有のメニュー選択肢の表示と、担体特有のメニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、システム自体がさらに、前記ソフトウェアを読み取り、その後前記ソフトウェアに従って動作する手段を含むことを特徴とする請求項１８に記載のシステム。２０．ソフトウェア担体が、担体特有のメニュー選択肢の表示と、担体特有のメニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、システム自体がさらに、前記ソフトウェアを読み取り、その後前記ソフトウェアに従って動作する手段を含むことを特徴とする請求項１に記載のシステム。２１．ソフトウェア担体のオーディオ・トラックの再生を制御する方法であって、前記ソフトウェア担体が、相互に同期し、それぞれに、複数のオーディオ・トラック自体のうちの他のトラックに記録されたオーディオ情報と選択的に組み合わせるべきオーディオ情報が記録された、複数のオーディオ・トラックと、前記トラックのオーディオ内容を定義するテキスト・データとを有し、前記方法が、前記ソフトウェア担体を再生し前記ソフトウエア担体から前記テキスト・データおよび前記オーディオ情報を導くステップと、前記テキスト・データから導かれたメニューをユーザに表示し、組み合わせるべき利用可能なオーディオ情報を前記ユーザに通知するステップと、前記ユーザが、表示されたメニュー選択肢に基づいて利用可能なオーディオ情報を組み合わせる方法を入力できるようにするステップと、前記トラックのうちの少なくとも１つのトラック中のオーディオ情報を位相反転することを含め、選択されたオーディオ情報をユーザ入力に従って組み合わせるステップとを含むことを特徴とする方法。２２．前記ソフトウェア担体上に記録されるオーディオ情報が、別々に識別可能なブロックにディジタル的に記録され、各ソフトウェア担体ブロックが、ブロック中のどのオーディオ・トラックがオーディオ情報を含むかを示すものを含み、前記組合せステップで、動作が、前記ユーザ入力に従ってオーディオ情報を組み合わせるために必要なブロック中のオーディオ・トラックにしか実行されないことを特徴とする請求項２１に記載の方法。２３．前記ソフトウェア担体上に、各オーディオ・トラックのタイプのＩＤが記録され、方法自体がさらに、前記トラック・タイプＩＤに従って、導かれたオーディオ情報を処理するステップを含むことを特徴とする請求項２２に記載の方法。２４．前記ソフトウェア担体上のテキスト・データが複数の言語のデータであり、前記ソフトウェア担体上にさらに、前記各言語に関するコードが記録され、方法自体がさらに、前記メニューが表示される１つの言語を選択するステップを含むことを特徴とする請求項２１に記載の方法。２５．さらに、デフォルト言語を表現するステップを含み、１つの言語を選択する前記ステップで、前記デフォルト言語と、ソフトウェア担体上に前記テキスト・データを含めるために使用された複数の言語との両方に従って言語が選択されることを特徴とする請求項２４に記載の方法。２６．さらに、前記デフォルト言語が前記複数の言語のどれにも合致しないことに応答して、ユーザが利用可能な言語のうちの１つを選択できるようにするステップを含むことを特徴とする請求項２５に記載の方法。２７．前記表示ステップで、前記トラックのオーディオ内容を定義するテキスト・データに基づいて、標準的な１組のメニュー選択肢が表示されることを特徴とする請求項２１に記載の方法。２８．前記標準的な１組のメニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項２７に記載の方法。２９．前記レベルが、あるオーディオ情報トラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項２８に記載の方法。３０．ソフトウェア担体が、非標準メニュー選択肢の表示と、非標準メニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、方法自体がさらに、前記ソフトウェアを読み取り、その後前記ソフトウェアに従って動作するステップを含むことを特徴とする請求項２９に記載の方法。３１．前記メニュー選択肢が、選択されたそれぞれのレベルを有する選択されたトラックから得たオーディオ情報の組合せを含むことを特徴とする請求項２１に記載の方法。３２．前記レベルが、オーディオ情報のトラックを他のトラックから効果的に削除できるようにする値を含むことを特徴とする請求項３１に記載の方法。３３．ソフトウェア担体が、担体特有のメニュー選択肢の表示と、担体特有のメニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、方法自体がさらに、前記ソフトウェアを読み取り、その後前記ソフトウェアに従って動作するステップを含むことを特徴とする請求項３２に記載の方法。３４．ソフトウェア担体が、担体特有のメニュー選択肢の表示と、担体特有のメニュー選択肢に基づくユーザ入力に従って選択されたオーディオ情報の組合せを制御するソフトウェアを含むことができ、方法自体がさらに、前記ソフトウェアを読み取り、その後前記ソフトウェアに従って動作するステップを含むことを特徴とする請求項２１に記載の方法。