JP2000514929A - オーディオファイル配信および生成システム - Google Patents

Abstract

(57)【要約】 データファイル配信システム（10）は、ローカルネットワーク、ISDN接続などを経て配信サブシステム（14）と通信するプロダクションサブシステム（12）をヘッドエンドに有している。配信サブシステム（14）は、テールエンドで、衛星リンク、ISDNリンクなどを経て加入者サブシステム（16）と通信する。プロダクションサブシステム（12）は、プロデューサが別のオーディオイベントが発生する前に完成に向けてプレイされるオーディオを作り出すことを可能にする。オーディオイベントはオーディオファイルとして格納される。各オーディオイベントは、１つ又はそれ以上のオーディオシーケンス、テスト情報、配信指示、及びコンタクトクロージャー情報などを持つ属性リストを有することができる。任意に、多数のオーディオイベントは、プロダクションサブシステム（12）でプレイリストを形成するために組立てることができる。オーディオファイルは配信サブシステム（14）に移される。配信サブシステム（14）は、配信エンベロップのオーディオファイルを置いており、加入者端末にエンベロップを伝送する。加えて、配信サブシステム（14）は、ライブオーディオ及び関連コンタクトディスクロージャー情報を加入者端末（16）に送信することができる。加入者端末（16）はユーザーサイトに設けることができる。加入者端末（16）は、これらのイベントをハードドライブに格納し、イベントをリアルタイムでプレイし、又は他の加入省端末（16）に転送することができる。加入者端末（16）は、格納されたイベントを後でプレイすることができる。

Description

【発明の詳細な説明】 オーディオファイル配信および生成システム アメリカ合衆国の国民であり、ニュージャージー州ホルムディル市の住人であ る私、Tim Chase(ティム チェイス)は、以下が明細書である、オーディオファ イル配信および生成システム、というある新規かつ有効な改良物を発明したこと は知られるべきである。 参照物として組み入れられる参照資料およびソフトウエア 本発明は1995年７月１日出願の仮特許出願第60／003,164号に基づく優先権を 主張をし、その全ての内容は前記’164号仮出願とともに出願されたソフトウエ ア付録および添付された論文を含んで参照物としてここに明確に組み入れられる 。 本発明の望ましい実施例を組み込むために使用されるソフトウエアは、以下の ようにラベル付けされた５−３ 1／2”デスケットの付録Ａ−Ｅ中に添付されて いる。本発明の望ましい実施例の加入者コントローラを組み込むために使用され るソフトウエアは、“DAXソース”と名付けられたソフトウエア付録Ａとして添 付されている。ディジタルオーディオカードに接続するために加入者コントロー ラによって使用されるソフトウエアは、“Driverソース”と名付けられたソフト ウエア付録Ｂ、および“DAC DSPソース”と名付けられたソフトウエア付録Ｃ中 に収録さられている。ディジタルオーディオカードの機能は、“DAC Driver設計 ”、“DAX オーディオサーバ設計”、“設計ノート”および“要求”と名付けら れた前記’164号仮出願に添付された論文中に記述されている。リモートコント ロール端末と加入者コントローラの間の協調を提供するソフトウエアは、 “Jock Box端末ソースコード”と名付けられたソフトウエア付録Ｄ中に収録さら れている。配信サブシステムを制御するために分配管理システムによって使用さ れるソフトウエアは、“DMSソース”と名付けられたソフトウエア付録Ｅ中に収 録さられている。 望ましい実施例に関連して配信サブシステム中で使用されるマルチプレクサは 、仮出願第 ／ （弁理士書類10872US0l）として1995年８月16日に、お よび仮出願第 ／ （弁理士書類10872US02）として1996年８月16日に出 願された“伝送帯域幅資源の動的割り付けのための方法および装置”と題する出 願人の係属中の出願に開示されているものであってよい。 上記で参照されたソフトウエア付録ＡからＥの全ては、上記で参照された論文 、仮出願および非仮出願とともに、明確にここにそのまま参照物として組み込ま れる。 発明の分野 本発明は、一般的には生および記録されたオーディオの配信に係わり、特にデ ィジタル化された生オーディオ、単一のオーディオファイルおよび／またはオー ディオファイルの組ならびに先頭端トランスミッタから１または複数の最終ユー ザレシーバへの再生命令の配信を提供する一体化された配信および再生システム に関連する。 発明の背景 全国的にシンジケート組織化されたラジオプログラムおよび全国的な広告キャ ンペーンは、ラジオ放送業の大部分を構成している。現状のこれらのプログラム の配信方法ならびに地方放送局およびその後の製作に対する広告は驚くほど扱い 難く非効率的である。 １つの共通の筋書きにおいて、全国的な放送局は、地方放送局に 対してラジオプログラムを提供するであろう。地方局はプログラムを取得し、そ の代わりに全国局は全国的な広告スポットに対して使用される地方局の付加的な 放送時間を提供される。そして、全国的な放送局はコンパクトディスク、ディジ タルオーディオテープ等上にラジオプログラムおよび全国的な広告を含む全ての 番組を記録する。記録された番組のコンパクトディスクまたはテープは種々の局 に、通常夜行配信サービスによって物理的に配信される。記録された番組はセグ メントに分割され、各セグメント間には地方局が地方広告、局識別符号または地 方ニュースのような地方スポットを放送することを許容するギャップが存在する 。地方局オペレータはいつこれらのギャップが発生し、どのくらい長く継続する かを知ることが必要であるため、全国的な放送局は印刷された番組フォーマット を提供しなければならない。この番組フォーマットは、地方局オペレータに全番 組継続長さ、出口キューおよびセグメントギャップの長さのような情報を提供す る。 番組を放送するために、地方局オペレータは出口キューを聞いている間予め記 録された番組を含むコンパクトディスクを再生する。彼は出口キューを聞くと、 地方スポットの記録を含む再生装置の再生開始を押下するか、または地方ニュー ス記者に発言を開始するための合図を与える。セグメントギャップが終わったと き、地方スポットは終了時間と定められる。 種々の課題が、そのような番組配信の方法を使用している全国的な放送局に対 して惹起される。各地方局のためのコンパクトディスクの製造および録音は高価 であり、ディスクは通常一回だけ使用され、そして破壊されるので、この処理は 不経済である。コンパクトディスクの準備およびそれに引き続く配送は１週間か かり得る。この時間遅れは、最新の番組の配送を妨げる。録音物は物理的に各地 方局に送付されなければならないので、運送価格は高くなる。もし全国的な広告 者がある広告によって国のある１地域だけを目標にしたいと望んだときは、異な った録音がなされ、その地方の局に送付されねばならない。 地方ラジオ局において、予め録音された番組の非柔軟性および印刷された番組 フォーマットおよび聞き取り可能なキューに基づく放送中の地方スポットの実時 間継ぎ重ねによって課題が引き起こされる。これらの課題は不経済な無駄な放送 時間、聴覚的な不快、全国および地方のセグメント間の突然の変更を発生させ得 る。 発明の目的 先行技術の課題および制限を克服するために、開示された発明は、１または複 数の下記の特徴または目的を達成する種々の実施例を有する。 本発明の目的は、高品質の生オーディオ、単一のオーディオファイルおよび複 数のオーディオファイルの配信および引き続く再生のための一体化されたシステ ムを提供することである。 本発明のさらなる目的は、生オーディオ、単一のオーディオファイルおよび複 数のオーディオファイルを選択されたエンドユーザまたは例えば地理的地域に基 づく複数のエンドユーザに選択的に配信するためのシステムを提供する。 本発明の他のさらなる目的は、顕著なオーディオ品質の損失なしに生オーディ オ、単一のオーディオファイルおよび複数のオーディオファイルの価格的に効率 のよい伝送を許容するオーディオ信号のデータ圧縮を達成することである。 本発明の他のさらなる目的は、配信センタにいるユーザが遠隔の再生装置によ って再生される複数のオーディオファイルの順序を制 御することを許容する一体化されたオーディオ配信再生システムを提供すること である。 本発明の他のさらなる目的は、先頭端のユーザが地方ラジオ局で放送するため の完全な番組を製作することを許容する一体化されたオーディオ配信再生システ ムを提供することである。 本発明の他のさらなる目的は、地方オーディオセグメントがオーディオセグメ ントの全国配信者によって製作される番組中に組み込まれることを許容する一体 化されたオーディオ配信再生システムを提供することである。 本発明の他のさらなる目的は、聴覚的な快感および１つのオーディオファイル またはセグメントから他のオーディオファイルまたはセグメントへの円滑な移行 を生成する再生システムを提供することである。 本発明の他のさらなる目的は、製造者によって経済的であり、既存の装置と交 換可能であるシステム要素を提供することである。 本発明の他のさらなる目的は、容易かつ柔軟なプログラム可能性を具備するユ ーザの使い易いシステムを提供することである。 発明の要約 本発明の望ましい実施例は、先頭端において、地域情報通信網、ISDN接続等を 介して配信サブシステムと交信する製作サブシステムを有するオーディオ配信シ ステムを含んでいる。この配信サブシステムは、衛星接続、ISDN接続等を介して 末端において加入者サブシステムと交信する。製作サブシステムは、他のオーデ ィオイベントが発生する前に完全に再生されるオーディオシーケンスを表すオー ディオイベントを、プロデューサが製作することを可能とする。オーディオイベ ントは、オーディオファイルとして記憶される。各オ ーディオイベントは、１またはそれ以上のオーディオシーケンス、テキスト情報 、配信命令および接点閉止情報等を有する加入者リストを含んでいるかもしれな い。付加的に、多重オーディオイベントは、再生リストを形成するために製作サ ブシステムにおいて集められるかもしれない。オーディオファイルは配信サブシ ステムに転送される。配信サブシステムは、オーディオファイルを配信エンベロ ープ中に置き、このエンベロープを加入者端末に転送する。さらに、配信サブシ ステムは、生オーディオおよび関連する接点閉止情報を加入者端末に転送するか もしれない。加入者端末は、ユーザ側に配置されるかもしれない。加入者端末は 、これらのイベントをハードドライブに記憶し、実時間でイベントを再生し、イ ベントを他の加入者端末に送るかもしれない。加入者端末は、後刻、記憶された オーディオイベントを再生するかもしれない。 望ましい実施例のオーディオ配信システムは、少なくとも７つの基本的なサー ビスを提供する。オーディオ配信システムは、交通情報、フォーマティック、入 口キュー等のような各ファイルに関する補助的な情報とともにオーディオファイ ルがシステム内に導入されることを可能とする。さらに、オーディオ配信システ ムは、オーディオイベントの束ねおよび１塊の配信パッケージ中に番組表のよう な文書のサポートを可能とする。束ねられたオーディオイベントおよび文書は、 単一のパッケージまたはエンベロープとして所定の加入者端末に転送される。各 パッケージは、特定の加入者端末、および／または複数の加入者端末宛に個別に 宛名が書かれる。この宛名が書かれた情報は、配信命令として参照される。この オーディオ配信システムは、さらに、パッケージが適切に配信されることを確か めるための完全性検査をサポートしている。 図面の簡単な説明 図１は、本発明の望ましい実施例に係るオーディオ配信システムのブロック線 図を一般的に示す。 図２は、本発明の望ましい実施例において使用される製作サブシステムのブロ ック線図を一般的に示す。 図３は、本発明の望ましい実施例において使用される配信サブシステムのブロ ック線図を一般的に示す。 図４は、本発明の望ましい実施例に関連して使用される加入者端末を一般的に 示す。 図５は、本発明の望ましい実施例に関連して使用される遠隔加入者遠隔コント ロール端末の斜視図を示す。 図６は、本発明の望ましい実施例に関連して使用されるディジタルオーディオ カードのブロック線図を示す。 図７は、本発明の望ましい実施例において使用されるディジタルオーディオカ ードに関連して使用されるプロセッサの機能的表現のブロック線図を示す。 図８は、本発明の望ましい実施例に関連して使用されるディジタルオーディオ カードに関連して操作したときの、加入者コントローラの機能的ブロック線図を 示す。 図９は、オーディオファイル、カートファイルおよび番組表ファイルフォーマ ットのブロック線図を示す。 図10Ａおよび10Ｂは、再生操作のためにディジタルオーディオカードおよび加 入者端末によって実行される処理順序のフローチャートを示す。 図11は、本発明の望ましい実施例に係る加入者端末に記憶されていない地方的 なセグメントの再生によって実行される２つの記憶されたセグメント間の典型的 なクロスフェード操作を示す。 図12は、本発明のファイル配信システムの代案の実施例を示す。 好適な実施例の詳細な説明 定義 最初に、共通的に用いられる用語について、定義のリストが提供される。 音声のプログラム―プレイリスト上でグループ化され少なくとも１つの提携の端 末へ供給される１つまたはそれより多い音声の区分（セグメント）。例示として は、音声のプログラムはハワード スターン ショウ、ケーシー カッシムズト ップ 40（Casey Cassims Top 40）、等がある。 音声の区分―規定された始点と終点をもつ音声信号の連続的系列を包含する音声 の事象（イベント）。音声の事象は、他の１つの事象（音声または命令）が発生 する前に、開始から終了まで、提携の端末によりプレイされる。例示としては、 音声の事象は音響のバイト、歌唱、歌唱の一部、コマーシャルの間のシンジケー トにされたショウ、１つのコマーシャル等をあらわすことが可能である。 オーディション音声―音声プログラムの内容をあらわす短かい音声の系列。例え ば、オーディション音声信号は歌唱の最初の数秒をあらわすことが可能であり、 提携の端末の使用者に対しプレイされ使用者に関連する音声の区分または音声プ ログラムが通知されようにすることが可能である。 カート機械―提携の端末における音声のプレイバックの装置であって、例えばテ ープからのようなローカルの音声区分をプレイすることに用いられる。カート機 械は、コマーシャルおよびニューススポットを記録しプレイバックするためにし ばしば用 いられる。 カートファイル―音声ファイルに独特に協働するファイル。カートファイルは、 音声ファイルの名前、音声ファイルへの開始および終末のオフセット、マーカの 属性、開始の合図（インキュー）終末の合図（アウトキュー）消滅の日付、およ び最初の使用の日付を包含する。 接点閉路の命令―提携の端末に接点の開路または閉路を命令する指示であって、 例えばカート機械をオンにしまたはオフにするもの。 データパケット―個別のユニットとしてマルチプレクサを通過するデータの区分 であって、それに対し、変調および伝送に先立ってヘッダ情報が付加されるもの 。例示としては、音声の区分および音声プログラムはマルチプレクサによりデー タパケットへ更に分割され提携の端末へ時分割多重の態様で伝送されることが可 能である。 消滅の日付―提携の端末が、提携の端末の記憶装置から音声の区分および／また は音声プログラムを自動的に抹消する、予め付与される日付。 分配の指示―分配の期間に、どの提携の端末が各データファイルを受理すべきか を、分配のサブシステムへ通知する指示。 フォーマテイックス―放送ショウの代表となる可能性のある音声プログラムの形 式または配置。例えば、該形式は、音声プログラム内の場所であって、ローカル の提携の局がローカルのコマーシャルスポットを挿入する可能性のあるもの、を 識別することが可能である。さらに、該形式または配置は、転換区分用のインキ ューおよびアウトキューおよび音声区分のプレイの時間を包含することが可能で ある。 帯域はずれの制御―マルチプレクサの内部通信として提携の端末へ指示されるこ とが可能な制御命令であって、例えば、単一のメッセージが伝送されつつあるチ ャンネルを識別する情報である。 プレイバックの表―特定の音声プログラムと協働する概要または業務記録であっ て、協働する音声プログラム内の各音声の区分／クリップ／事象を独特に識別す る情報を包含するもの。 音声のファイル―内部構造をもたない記録された音声。音声ファイルは、個別の コマーシャルまたは短いまたは長い形式のプログラム区分をあらわすことが可能 である。 なまの音声―放送されるショウであって、提携の端末においてショウを記録する ことなく受信されるもの。なまの音声は、補助のデータの流れ内に埋込まれる同 期化された命令を包含することが可能である。同期化された命令は、提携の機能 、例えば提携の端末においてカード機械によりコマーシャルの再プレイの開始、 を作動開始させることに用いられることが可能である。 遅延プレイの音声―ディスクに記録されるが大抵直ちに（例えば５ないし10秒以 内）再プレイされるショウ。該ショウは、受信されるとともに記録されるが、デ ィスク空間はショウがプレイされている間は、解放されている。 システムの概観 第１図は本発明の好適な実施例による音声分配システム10のブロック線図を示 す。音声分配システム10は少なくとも１つの制作のサブシステム12、少なくとも １つの分配のサブシステム14、および少なくとも１つの提携の端末16を包含する 。第１図に示されるように、各制作のサブシステム12は、デジタルデータの伝送 を支持する任 意の従来形の媒体を通って１つまたはそれより多い分配のサブシステム14と通信 することが可能である。例示としては、制作のサブシステム12と分配のサブシス テム14の間の相互接続（ライン13で示される）は、ローカルエリアの回路網、IS DNの連系（リンク）、従来形の電話連系、衛星連系、等であることが可能である 。さらなる選択肢として、各分配のサブシステム14は１つまたはそれより多い制 作のサブシステム12と通信することが可能である。 各制作のサブシステム12は、使用者がデータファイルを制作することを可能に し、該データファイルは、一般的には、音声の事象／区分／クリップ、音声のフ ァイル、カートのファイル、プレイバックのリストのファイル、文書のファイル 、映像のファイル、および分配の指示のファイル（定義の項において定義される ような）と称される。分配および制作のサブシステムは機能的に別個のユニット として第２図に示されるが、両方のサブシステムは、共通の場所（および共通の システム）において実現され、接続13の必要性を回避するようにされることが可 能である。 分配のサブシステム14は、連系13を通して分配のサブシステム14から、音声の 区分と音声のプログラムを包含する音声のファイルと音声のファイルの系列を受 理する。さらに、分配のサブシステムは連系15を通してなまの音声の信号を受理 する。分配のサブシステム14は連系15を通して接点閉路の命令をも受理すること が可能である。分配のサブシステム14は、連系13および連系15上で受理する信号 を組合わせ、該組合わせを連系17を通して提携の端末16へ出力する。連系17は衛 星連系、ISDN連系、等であることが可能である。選択肢として、分配のサブシス テムは、連系17または連系19を通して提携の端末から情報を受理することが可能 である。 選択肢として、分配のサブシステム14は、データファイル（例え ば、音声のファイル、カートのファイル、命令、プレイリストのファイル、文書 のファイル、映像のファイル、等）を単一の「包絡体（エンベロープ）」内へ集 合させることが可能である。この「包絡体」は、宛先の提携の端末に関するアド レス情報を包含することが可能である。分配のサブシステムは音声ファイルの外 向けの包絡体を、アドレス情報にもとづいて個々の提携の端末へ指向する。選択 肢として、アドレス情報は、提携の端末の１つの群を包絡体用の宛先として指定 することが可能である（例えば、シンジケートのショウ用の米国中西部のラジオ 放送局）。 提携の端末16は分配のサブシステム14から到来する包絡体を受理し、該包絡体 を希望される態様で処理する。選択肢として、提携の端末16は、連系19を通して 分配のサブシステム14へ、いつ提携の端末16が期待した音声のファイルを受理し なかったかを通知する。提携の端末16は、到来する音声のファイルをハードディ スクに記憶させ、包絡体とともに受理した指示（例えば、プレイバックのリスト ）にもとづいて、または提携の端末における操作者からの指示にもとづいて、こ れらの音声ファイルを、後に、再プレイすることが可能である。その代りに、提 携の端末16は、例えばなまのプログラム（例えば、ニュース）の放送の期間に、 到来する音声のデータを受理し再プレイすることが可能である。さらにその代り に、提携の端末16は、再プレイの期間に、ローカルのプログラム（ローカルのカ ート機械上のテープによりプレイされるもの）と分配のシステム14から受理する 音声のプログラム（ハードの駆動装置に記憶されているもの）を挿入編成するこ とが可能である。提携の端末16は、１つの音声セグメントの終末部分と次位の音 声セグメントの開始部分を混合するとき、自動化された交差状のフェーディング の操作を利用することが可能である。 補助の端末16は、連系19を通してアナログの音声信号を出力し、ラジオ放送局 から放送されるようにする。ライン21および23は、外方へ向かう接点閉路の命令 を支持し、該命令は例えば提携の端末16からカート機械へ送出されるものである 。ライン23は検出器入力信号を受理し、該信号は提携の端末へカート機械等の現 在状態を通知するものである。提携の端末16は、ライン25を通して提携の端末に おける使用者へオーディション音声信号を出力する。 データの形式（フォーマット） 第９図は一般的に本発明の好適な実施例に接続されて使用される例示的なデー タの形式（フォーマット）を示す。本発明が音声のデータの制作および伝送に限 定されないことは理解されるべきであるが、説明の便宜のために、音声のプログ ラムが制作され伝送されることが仮定される。第11図は、プレイリストのファイ ル400を示し、該ファイルは、音声の区分のプログラムを規定する。プレイリス トのファイルにおける音声の区分は、１つのアウトラインのフォーマットにおい て使用者に対し表示されることが可能である。プレイリストのファイル400は、 プレイされるべき各音声の区分を識別するファイル名称（例えば、404、420、お よび436）のプレイバックのリスト402を包含することが可能である。ファイル名 称404、420、および436は、ファイルの名称およびカートファイル406、422、お よび438への指令の通路をそれぞれあらわす。各カートファイル406、422、およ び436は、音声の区分414、432、および434をそれぞれ独特に識別する。各カート ファイル406、422、および438は、対応する音声の区分を包含する音声のファイ ル415および430への通路の名称408、424、および440をそれぞれ包含する。音声 のファイル430は、カートのファイル422および438用の音声の区分432および434 を包含する。 各カートのファイル(406、422、および438)はまた、開始の(410、426、および 442)および終末の(412、428、および444)データフレーム番号を対応する音声の ファイルのなかへ包含させる。開始のおよび終末のデータフレーム番号は、対応 する音声の区分の開始および終末の点を識別する。各カートのファイルはまた、 対応する音声の区分用の属性、例えば、マーカ（後述されるようなDACの事象を 開始させることに用いられる）、インキュー、アウトキュー（使用者にいつ区分 が終了するかを通知する）、文書の記述（音声の区分を記述するコメント）、消 滅の日付（提携の端末が音声のファイルを自動的に抹消する日付）、および最初 の使用の日付（提携の端末が音声の区分へのアクスセスを最初に許容される日付 ）、を包含することが可能である。 操作の期間において、文書、アウトキュー、コメント等は、音声のファイル、 カートのファイル、およびプレイリストのファイルから取得され使用者に対し表 示されることが可能である。この表示は、プレイバックのリストの表示を包含す ることが可能であり、該プレイバックのリストの表示は、音声の区分の標題およ びそれにともなうローカルのスポットの中断および区分のプレイの時間の表示に よるものである。 制作のサブシステム 第２図は制作のサブシステム12をより詳細に図解する。制作のサブシステム12 は、制作のプロセッサ24を包含し、該制作のプロセッサは分配指示入力のユニッ ト32、トラフィックおよびフォーマテイックスの入力のユニット28、音声入力の ユニット26、および接点閉路入力のユニット30と通信する。分配のサブシステム はハード駆動装置35を包含し、該ハード駆動装置は、分配のサブシステム14への 伝送に先立って音声の区分および音声のプログラムと協働する音声 のファイルを記憶するためのものである。音声および接点閉路の入力26および30 は、音声および接点情報の信号をCODEC31へ供給するが、該CODECは例えば、Holm del、New JerseyのCorporate Computer Systems、Inc.から商業的に利用可能なC DQプリーマ符号化／復号化装置である。CODEC31は、幾つかの従来形の「ロッシ イ形」の符号化アルゴリズムにもとづいて到来する音声の信号を符号化すること が可能であり、該符号化アルゴリズムは例えば、Corporate Computer Systems、 Inc.から商業的に利用可能なMUSICAMアルゴリズムである。選択肢として、CODEC 31には他の符号化アルゴリズムが使用されることが可能である。 CODEC31はさらに、入力30から接点閉路の指示を受理し、この接点閉路の指 示を出力の符号化音声の信号へと統合する。CODEC31の出力はデジタル音声のカ ード(DAC)31に供給され、該デジタル音声のカードは後述のデジタル音声のカー ドの項においてより詳細に説明される。DAC33は、符号化された音声のデータお よび接点閉路のデータを分配のサブシステム12のプロセッサへリレーするが、こ れは分配の指示およびトラフイック／フォーマテイックスの情報が生成され付加 される期間における一時的記憶のためのものである。DAC33はCODEC31からの出力 信号を復号し該復号された音声の信号を使用者に対しプレイすることが可能であ り、それにより使用者が現行の圧縮パラメータの組に従いいったん符号化されそ して復号された結果としての音声の信号を聴取することが可能になる。 選択肢として、制作者は、CODEC31からの符号化された音声の信号を記録する ことなく、DAC33の復号された出力を当初に聴取することが可能であり、この聴 取は、例えば、CODEC31の現行のパラメータ設定を変更する必要があるか否かを 決定するためのものである。CODEC31のパラメータがひとたび生成者に満足され るよう設定さ れると、該制作者は記録の選択肢を選択することが可能である。それに応答して 制作のプロセッサ24とDAC33は、協力してCODEC31からの符号化音声出力の信号を 分配のサブシステム12のハード駆動装置に記録する。さらなる選択肢として、記 録の期間において、DAC33はプレイバックの操作をオフにするよう切換えられる ことが可能である。 さらにその代りに、DAC33はCODEC31からの新しく到来する符号化音声の信号を プロセッサ34へ進行させハード駆動装置に記憶させ、それとともに分配のサブシ ステム12のハード駆動装置からの以前に符号化された音声の信号を同時に読取る ことが可能である。DAC33は、新しい音声のプログラムがCODEC31により符号化さ れハード駆動装置に記憶される間に、以前に記憶された音声のプログラムを制作 者に対し復号することが可能である。この態様で、好適な実施例の分配のシステ ムは、第１および第２の音声のプログラムの同時の記録および編集の操作を支持 する。 選択肢として、プロセッサ24は、分配の指示およびトラフイックおよびフォー マテイックスを、データベース35に記憶されるときに、音声の区分および音声の 記録に付与することが可能である。音声の区分またはプログラムがひとたび完了 すると、制作者は、音声の区分またはプログラムを連系13を通して分配のサブプ ログラムへ伝送することを、プロセッサ24に指示する。 単に例示としてのみであるが、制作のサブシステム12は、全国的な放送事業者 用のコマーシャルを制作する広告代理業者内に位置することが可能である。この 手法を用いて、広告代理業者は制作の機能を遂行することが可能であり、結果と しての音声のプログラムは、全国的な放送事業者のさらなる介入なしに、ISDN連 系等を通して分配のサブシステム14へ直接に送付される。 単に例示としてのみであるが、音声の入力26はデジタル音声テープのプレーヤ 、コンパクトディスクのプレーヤ等をあらわすことが可能である。このシステム はまた、直接的デジタル入力例えばAES／EBUを支持することが可能である、トラ フイックの入力は、単純なプレイの指示、またはインキュー、アウトキュー等を 包含する音声のプログラムの複雑な形態を入力するためのキイボードを構成する ことが可能である。接点の閉路は、後述されるようにカート機械等を始動し停止 するために用いられることが可能である。分配の指示の入力32は、プログラマが 、音声のプログラムを希望される提携の端末または端末の群へ供給するに必要な すべての情報を入力することを可能にする。分配の指示は、意図される提携の端 末の名称、提携の端末の群、送出者の名前、該当する経理の情報、終了のデータ 等を包含することが可能である。 単に例示としてのみであるが、制作のサブシステムは、PACEシステムを包含す ることが可能であり、該PACEシステムはNew Jerseyから商業的に利用可能であっ たが、現在はCBSにより使用されている。 配信サブシステム 図３は一般に配信サブシステムをより詳細に描いたものである。配信サブシス テム14は、プロダクションサブシステム16からオーディオファイル、カートファ イル(cart file)、プレイリストファイル、コマンドファイル、テキストファイ ル、ビデオファイルなどのような、データファイルを受ける分配管理システム34 (DMS)を有しているDMS34はライン42により加入者端末から状態レポート、請求書 レポート（billing report）、データファイルの配信確認などのような通信を受 けることができる。任意に、DMS34はプロダクションサブシステムから配信命令 を受けることができる。配信サブシス テム14は入ってくるデータファイルを集め、そしてこれらのデータファイルを、 共通にアドレスされたデータファイル、宛て先加入者及び／又はハブ端末のため のアドレス情報、加入者及び／又は端末の宛て先グループのためのアドレス情報 、エンベロップの最新の配信時間に関する優先配信情報、すでにエンベロップを 受けた各加入者／ハブ端末を識別する配送経路リストなどを含む「エンベロップ 」に集めることができる。 DMS34はデータライン34ａによりマルチプレクサ22にエンベロップを転送す る。マルチプレクサ22は伝送のため、１つ又はそれ以上のチャンネルによってエ ンベロップをレコードに分割することができる。任意に、DMSはタイムスロット コントロールライン34ｂを経てマルチプレクサ22の動作を制御できる。DMS34は 、加入者及び／又はハブ端末のためを意図して、バンドコントロールライン34ｃ の外側でマルチプレクサ22にコマンドを転送することができる。 代わりに、マルチプレクサ22は別個のプロセッサにより制御することができる 。その場合、DMS34はデータ出力ライン34ａを通って単独でマルチプレクサ22と 結合する。バンドコントロールライン34ｃ及びタイムスロット割当ライン34ｂの 外側は、マルチプレクサ22を制御する別個のプロセッサにより駆動される。 さらなる選択として、プロダクションシステム12は直接配信サブシステム14の アドレッシングを制御することができる。その場合、DMS34は、アドレッシング 情報なしに、そしてデータファイルを「エンベロップ」にグループ化することな しに、マルチプレクサ22にデータファイルを転送する。 配信システム14は、ライン40によりライブのアナログオーディオ信号を受け、 そして幾つかの既知の符号化アルゴリズムの１つに基づいてこれを符号化するた め、少なくとも１つのCODEC18を含める ことができる。DMS34は、コントロールライン34ｄを経てCODEC18の動作を制御す る。マルチプレクサ22はCODEC18からディジタル的に符号化されたオーディオ信 号を受ける。マルチプレクサ22は、変調器44に１つ又はそれ以上の伝送チャンネ ルによって入ってくるデータを転送するため、上記参照した共通ペンディングア プリケーション（参照に組み入れられた）において設定されたように動作する。 変調器44はマルチプレクサ22から受けた信号を衛星に伝送する。 前述のように、配信サブシステム14は、オーディオファイル、カートファイル 、プレイリストファイル、コマンドファイル、テキストファイル、ビデオファイ ル、及びプロダクションサブシステムからの分配情報を有するデータファイルを 集める。配信サブシステム14はさらに、CODEC18を介して、コンタクトクロージ ャー情報のようなライブオーディオ信号及びANCデータを受ける。データは望ま しい媒体を介して加入者及び／又はハブ端末に伝送される。好ましい実施形態に おいては、配信サブシステムは加入者端末にデータを伝送するため、衛星コネク ションを利用しているが、本発明はそれに限定されない。代わりに、配信サブシ ステム14は、個々のアプリケーションにより要求された伝送レートでディジタル 的に符号化されたデータの伝送を支持する媒体に沿ってデータを伝送することが できる。例えば、配信サブシステム14は、ISDNラインなどによってディジタル的 に符号化されたデータを伝送することができる。低伝送レートが受け入れられる 時、配信サブシステム14はディジタルデータを伝送するため従来の電話線を利用 することができる。 加入者端末 図４は、加入者端末16をより詳細に描いたものである。加入者端末16は受信局 又はエンドユーザに配置できる。加入者端末16は、配信サブシステム14から衛星 20を経て入ってくるライブデータラケッ ト(live data rackets)、データファイル及びエンベロップを受けるためにアン テナ51を有している。任意に、アンテナ51は、オーディオプログラムが受信され た又は受信されなかったという配信情報のような戻り情報を伝送することができ る。入力情報はRFデコーダ53において復調され、デマルチプレクサ50に転送され る。デマルチプレクサ50は配信サブシステム14のマルチプレクサ22と両立するよ うに構成される。デマルチプレクサ50は、少なくとも１つのエンベロップで再組 立するため、１つ又はそれ以上のチャンネルから入ってくるデータレコードを分 離(demultiplex)する。デマルチプレクス50は、ライン66よりのバンドコマンド からの出力を分離することができる。任意に、デコーダ53は、符号化されている が、しかし、オーディオファイル（上記の）にフォーマットされていないリアル タイムのライブオーディオデータを受けるために制御することができる。符号化 されたオーディオデータは、データフレームのデータポケットの連続したデータ の流れとして受けられる。デマルチプレクサ53がライブオーディオデータの流れ を受けるように構成されているとき、DAC52はデータの流れを受けるために「ラ イブモード」に設定される。この様にライブオーディオデータの符号化されたデ ータの流れは復号され、リアルタイムにプレイバックされる。 加入者端末はさらに、オーディオファイル、カートファイル、プレイリストフ ァイル、テキストファイル、ビデオファイル、及びデマルチプレクサ50からのコ マンドのようなデータファイルを受ける加入者コントローラ46を有している。加 入者コントローラ46は、マイクロソフトのウインドウ95のような従来のオペレー ションシステムを動かすパーソナルコンピュータに相当する。加入者コントロー ラ46は、メモリ48に入ってくるデータを蓄えることができる。加入者コントロー ラ46は、以下により詳細に説明される少なくとも１つ のディジタルオーディオカード(DAC)を有する。 加入者端末16は、局による放送のためのアナログ出力ライン56又はAES／EBUラ インを経たディジタル出力ラインの少なくとも１つにオーディオ信号を出力する 。加入者端末16は、加入者がメモリ48に格納されたオーディオセグメント又はオ ーディオプログラムの少なくとも一部を聞くことを可能にする、DAC52からの聴 取オーディオ出力ライン58を含めることができる。リモートコントロール端末54 は、加入者コントローラ46により実行される機能の少なくとも１つのサブセット に加入者リモートコントロールを与えるために設けられる。例として、リモート コントロール端末54及び聴取オーディオヘッドホーン59は、DJが試聴し、聴取し 、メモリ48に格納されたオーディオセグメント又はプログラムのプレイをコント ロールすることを可能にするため、ラジオ局のDJのブースに位置することができ る。リモートコントロール端末54は、加入者コントローラ46がDJのブースから離 れて位置しても、DJのブース内からメモリ48に格納された望ましいオーディオセ グメント及びプログラムを選択することを可能にする。 ライン60と62はコンタクト出力コントロールライン及びセンサ入力ラインにそ れぞれ相当し、DAC52により駆動されそして検出される。センサ入力ライン62は 任意に入力ラインを分離することができる。DAC52はコンタクト出力ライン60に コンタクトオープン及びクローズ信号を出力する。DAC52はリモート装置の状態 （即ち、オープン又はクローズ）の変化を検出するため、センサ入力ライン62を モニタする。リモート装置はカートマシン、リモートコントロール端末などに相 当させることができる。例として、センサ入力62は、カートマシンがローカルプ ログラムのプレイを完成させる時、DAC52に伝えるためにカートマシンをモニタ してもよい。 ユーザインタフェース57は、加入者コントローラ46をコントロールするために 設けられる。例として、ユーザインタフェース57はキーボード、マウス及びディ スプレイを設けてもよい。一方、加入者コントローラ46は、アイコンがオーディ オセグメント及び／又はプログラム、及び機能（例えば、レコード、プレイ、フ ェード、停止など）を表すことができるウインドウ環境において動作する。ユー ザは関連アイコンをクリックし、ドラッグし、ドロッピングすることによりオー ディオセグメント又はプログラムに望みの機能を実行できる。 ディジタルオーディオカード 図６は本発明の好ましい実施形態と関連して利用されるディジタルオーディオ カード(DAC)52を描いたものである。DAC52は、加入者端末16のマザーボードと接 続するため相互接続ポート102を持ったプリント回路ボードに設けられる。DACは 、以下に説明するように動作するディジタル信号プロセッサ(DSP)104を備えるこ とができる。好ましい実施形態はDSPを用いているが、Intel、Motorola、CYRIX 、AMDなどから商業的に利用可能な専用チップ又は一般目的のマイクロプロセッ サで行うことができる。メモリ106はディジタル信号プロセッサ(DSP)104の動作 を制御するコマンドソフトウエアを格納する。DSP104は入って来るデータファイ ルを受け、ライン108(図４のデマルチプレクサ50からのライン64と66)に指令す る。DSP104はライン110に沿って復号化されたオーディオ信号を出力する。DSP10 4は、「マーカー」がセグメントのプレイの間に生じた時（マーカーは以下に説 明する）、加入者コントローラ46に伝える。もしマーカーがコンタクトクロージ ャーコマンドに応答するなら、加入者コントローラ46はライン112に沿ってリレ ー出力信号（例えば、コンタクトクロージャー信号）をセットするため、DSP104 に 指示する。DSP104はセンサ入力114に沿ってセンサ状態情報を受け、このセンサ の情報を加入者コントローラ46に供給する。DSP104はライン116に沿って加入者 コントローラ46と通信する。 次に、DAC52においてDSPにより実行される動作を表す機能的図式を描いた図７ に移る。DSP104の機能は、オーディオファイル、カートファイル、プレイリスト ファイル、コマンドファイル、ライブデータフレームなどを含んだ、ライン108 に沿って入力するエンベロップ、データファイル、及びフレームを受けるデータ スイッチング動作120を有する。データスイッチ120は、特定のDACカード52にア ドレスされたエンベロップ、データファイル、及びフレームのみを受け入れる。 データスイッチ120は特定のDACカード52にアドレスされない入力情報を無視する 。データスイッチ120は、エンベロップとデータファイルをライン128に出力し、 ライブデータフレームを１つ又はそれ以上のライン124及び126に出力する。デー タスイッチ120はカードコントローラ122により制御される。ライン128を転送さ れたエンベロップとデータファイルは、DACドライバー132を通ってライン134に より加入者コントローラ46（図４）に伝送する前に、データバッファ130に一時 的に蓄積される。DACドライバ132は、ライン134、136、138、140及び142によっ てDSP104と通信する。DACドライバ132は、図８と関連して説明される加入者コン トローラ46と通信する。DACドライバ132は、アプリケーションと共にDAC52と接 続している低レベルハードドライブインタフェースに相当しており、アプリケー ションに依存して省かれ又は変更される。 データスイッチ120は、ライブの符号化したオーディオデータの流れをライン1 24と126によりフレームバッファ146と148に配信する。ライブプレイモードの間 、フレームバッファ146と148の１ つは符号化された入力オーディオデータを一時的に格納し、一方、個々のデータ フレームをライン150ａと152ａによりデコーダ150と152に出力する（ファースト −イン ファースト−アウト態様）。デコーダは次にオーディオデータのデータ フレームを復号し、復号化されたオーディオデータをライン154と156によりミキ サ158に出力する。ミキサ158はライン154と156のディジタルオーディオデータを 組み合わせ、ライン159に合成されたオーディオ信号を出力する。データフレー ムは符号化されたディジタルオーディオデータの予め決められた分離された量に 対応する。例えば、エンコーダはディジタル化されたオーディオ情報の24ミリ秒 間隔で符号化を実行できる。ディジタル化されたオーディオデータの24ミリ秒分 離した区分は、符号化されたデータフレームとしてエンコーダにより出力される 。データの多重フレームは、オーディオの流れを形成するため組み合わせられる 。 以下に説明するように、カードコントローラ122は、メモリ48に格納されたオ ーディオファイルからデータフレームのセットをライン150ｂと152ｂによりデコ ーダ150と152に供給する。 デコーダ150と152ににより復号されたデータフレームはANCデータを含むこと ができ、その場合、デコーダ150と152はANCデータをライン160と162でANCデータ バッファ164に出力する。データバッファ164は、加入者コントローラ46にDACド ライバを通ってライン140により出力するまで、一時的にANCデータを格納する。 DACイベントバッファ DACイベントバッファ166は、加入者コントローラ46に関連するメッセージを 格納する。例として、DACイベントバッファ166は、オーディオセグメントが終了 した時を表示し、イベント番号によりセグメントを識別するメッセージを格納す ることができる。任意に 、イベントバッファは、オーディオセグメントのプレイバックの間にマーカーが 生じた時を表示するメッセージを格納することができる。マーカーはプロダクシ ョンサブシステムにより予め割り当てられたフラッグに対応させることができる 。マーカーを含むオーディオセグメントがプレイされる時、プレイバックの間の マーカーの検出により、DSPはイベントバッファにマーカーが生じたことを表示 するメッセージを格納する。マーカーはコンタクトクロージャーをオン、オフす るために用いることができる。このように、マーカーは、オーディオプログラム にマーカーを導入することによりロ一カルカートマシンを自動的に制御するため に加えられる。プログラムのプレイの間、マーカーが検出された時、加入者コン トローラ46はマーカーを伝えられ、そして加入者コントローラ46は対応するコン タクトクロージャー信号を出力する。例として、マーカー＃１は加入者コントロ ーラ46にコンタクトを閉じるよう指示することができ、一方、マーカー＃２はDS P104にクロスフェード動作を開始するよう指示することができる。 加えて、DACイベントバッファ166は、DACカードによりセンサ入力ライン62（ 図４）で受けたセンサ入力メッセージを格納する。カートマシンが自動的にコン タクト閉じることにより自動プレイを開始することを指示された時、コンタクト に最も近いセンサは、カートマシンによりプレイされたオーディオセグメントが 終了した時を検出する。 DACプロセッサの動作 次に、DSPの動作についてさらに詳しく説明する。 最初に、入力がいつ与えられたかを判定するために、データスイッチ120はラ イン108を監視する。この条件が満足されると、データスイッチ120は入力データ をアクセスし、この入力データ内のＤ ACアドレスを判定する。データスイッチ120は、この入力DACアドレスと、カード コントローラ122からライン122ａに沿って与えられたアドレスとを比較する。も し、与えられたDACのDACアドレスが、入力データのアドレスに対応するならば、 データスイッチ120は、該入力データがこのDAC向けのものであると判定する。選 択的には、入力データのアドレスがグループアドレスを表しているときは、デー タスイッチ120は、与えられたDACが既に該グループに割り当てられているかどう か判定する。カードコントローラ122は、データスイッチ120に対し、既に該DAC が割り当てられているグループアドレスを伝える。もし入力メッセージが、与え られたDACまたは与えられたDACを含むグループに宛てられていないならば、デー タスイッチは当該データを無視する。 入力メッセージが、与えられたDACまたは与えられたDACを含むグループに宛て られているときは、データスイッチ120は、カードコントローラ122からのコント ロール信号に基づいて、当該データを１またはそれ以上のライン124、126、およ び128へ転送する。例えば、ライブプレイ動作中は、データスイッチ120は入力オ ーディオデータをライン124に沿って、一時記憶のために、フレームバッファ146 に転送する。フレームバッファ146は、各データフレームをデコードするために デコーダ150に転送し、ｎディジタルオーディオ信号として出力する。デコーダ1 50の出力はディジタル−アナログコンバータを通してライン160へ出力すること ができ、究極は加入(affiliate)コントローラ46からライン56（図４）に、一斉 送信されるアナログオーディオ信号として、出力することができる。 あるいは、記憶動作中は、入力データファイルが、データスイッチ120を介し ライン128に沿ってデータバッファ130に転送される 。データバッファ130は、オーディオデータをライン134に沿ってそしてDACドラ イバ132を介して究極は加入コントローラのメモリ48に転送するまで、一時的に データファイルを記憶する。選択的には加入ユーザは、カードコントローラ122 を介してDSP104に対し、入力オーディオデータをライン128および124へ送出する ように指令することができ、これにより、オーディオデータを（データバッファ 130を介して）記録し、そして同時に（フレームバッファ146およびデコーダ150 を介し）ユーザに聴取させることができる。 図８はDAC52との関速で使用される加入コントローラ46のモジュールの機能を 概括的に示す図である。加入コントローラ46は、仮想DACドライバ132を介し、DA C52と通信を行う。加入コントローラ46は、上述したごとくDSP104とインタフェ ースする複数の内部モジュールを具備したオーディオサーバ180、を含むように 構成することができる。 オーディオサーバ180は、入力データ処理モジュール181を含むことができ、こ の入力データ処理モジュール181は、データバッファ130(図７)から受信したデー タファイル（例えば、オーディオファイル、カート（cart）ファイル、プレイリ ストファイル、ビデオファイル、テキストファイル）を処理する。入力データ処 理モジュール181はこれらのファイルをメモリ46に格納する。オーディオサーバ1 92は、カードコントローラ122と通信するためのカードコントロールモジュール1 82を含むことができる。カードコントロールモジュール182とカードコントロー ラ122は、リクエスト、レスポンス、ポーリングコマンド等のコマンドを、これ らの間でやりとりする。オーディオリクエスト処理モジュール184は、カードコ ントローラ122からのデータリクエストを提供するために設けることができる。 以下にさらに詳しく説明するように、オーディオリクエス ト処理モジュール184は、メモリ48からデータフレームを得、そしてこれらのデ ータフレームを、再生動作中に、デコーダ150および152の一方に対して送出する 。補助データマネジャーモジュール186およびイベントマネジャー（管理）モジ ュール190はまた、補助データバッファ164およびイベントバッファ166からの補 助データおよびイベントデータ、をそれぞれ受信する。補助データおよびイベン トマネジャーモジュール186および190は、入力データおよびメッセージを、記憶 および処理のためのオーディオサーバ180内の適当なモジュールに、送出する。 オーディオサーバ180は、再生、センサ入力、接点閉止出力等に対する制御を 行う。オーディオサーバ180は、通信リンク188を介しての加入ユーザとのインタ フェースに供する。このようにして、加入ユーザはオーディオサーバ180に対し 、加入端末によりなされる前述の機能を果たすように指令することができる。選 択的には、リンク188は、リモートコントロール端末54に対ししたがって加入端 末16に対し、オーディオサーバ180からのコントロールリクエストを入力可能に することができる。 オーディオリクエスト処理モジュール184は、加入端末のメモリ上に格納され たオーディオファイルとDAC52との間のインタフェースをなす。以下にさらに詳 しく述べるように、オーディオリクエスト処理モジュール184はバッファを含み 、このバッファは、オーディオファイルからのデータフレームをDAC52に送出す るために、メモリ48上に格納されたオーディオファイルからのデータフレームを 記憶する。 オーディオサーバ180は、加入端末との会話を行う全てのインタフェースアプ リケーションのためのコモンポイントをなす。オーディオサーバ180は、ユーザ に対しいくつかのリンク（例えば、LAN 、シリアル等）を介してそれに付属することを可能にするところの多機能サーバ を代表している。ユーザはオーディオサーバにリクエストを送信し、そしてそこ からリンク188介しレスポンスを受信する。オーディオサーバ180は、端末リソー ス（例えば、オーディオファイル、カートマシンやリレイ閉止等の再生装置）の 集合における同一のプール（pool）をアクセスする複数のユーザを管理する。仮 想DACドライバ132は、記憶動作中においては、データフレームをDAC52からメモ リ48へ、再生動作中においては、メモリ48からDAC52へそれぞれ転送する。ドラ イバ132はまた、両方向へコマンドを送出する。再生動作中に関連して、DAC52は 、付加的データを必要とするとき、ドライバに信号を送る。DAC52は、当該デー タを、ユニークな識別子（セグメントハンドル）によって特定する。 記憶されたセグメントの再生 図10ａおよび10ｂに戻ると、これらの図は、再生動作に関連して、加入コント ローラ46およびDAC52によって遂行される処理シーケンスを示す。オーディオサ ーバ180は、再生指令を受信する（この指令は、リンク188を介したユーザからの ものまたはセンサ入力62を介したリモート装置からの如きものである）。初めに 、オーディオリクエスト処理モジュール184は、ドライバリクエスト信号を待ち 受けるためのリード（read）ステートにセットされる。オーディオサーバ180は 、オーディオリクエスト処理モジュール184と共に１またはそれ以上のオーディ オセグメントを登録する（ステップ202）。登録を行うために、オーディオサー バ180はカートファイル内の情報のごときデータファイル情報を、オーディオリ クエスト処理モジュール184に転送し,、そのデータファイル情報は、オーディオ セグメントまたはプレイすべきセグメントを収容するデータファイルの名前を含 む。加えてオーディオサーバ180は、オーディオフ ァイルへのスタートオフセットおよびエンドオフセットを、オーディオリクエス ト処理モジュール184に転送する。データファイル情報は、セグメントリクエス トとして、オーディオリクエスト処理モジュール184に転送され、このオーディ オリクエスト処理モジュール184は、オーディオセグメントテーブル上のオーデ ィオリクエストを記憶しそしてユニークなセグメントハンドル（例えばユニーク ナンバー）を当該セグメントリクエストに割り付ける。セグメントハンドルは、 セグメントリクエストと共にオーディオセグメントテーブル内に格納される（ス テップ204）。 オーディオリクエスト処理モジュール184は、ユニークなセグメントハンドル をオーディオサーバ180に返送する。その後、オーディオサーバ180は、セグメン トハンドルおよび付加的コントロール情報を、ロードセグメント情報リクエスト 信号として、DAC52に転送する（ステップ206）。その付加的コントロール情報は 、例えば、どのデコーダを指定するかの識別子やセグメントスタートオプション やスタートフェーディング時間やエンドフェーディング時間やイベントマーカー やスタートトリガ等を含むことができる。ロードセグメントリクエストは、カー ドコントローラ122に転送され（図７）、そしてカードコントローラ122は少なく ともユニークセグメントハンドルを格納する。 ステップ208において、DSP104は、セグメントハンドルを含むリクエストオー ディオデータメッセージを、オーディオリクエスト処理モジュール184に返送す る。このメッセージを受け取ると、オーディオリクエスト処理モジュール184は 、セグメントハンドルによってオーディオセグメント内で特定されるオーディオ ファイルを、アクセスする（ステップ210）。オーディオリクエスト処理モジュ ール184は、オーディオファイルからのデータフレームのセットを 読み出し、そしてこれらのデータフレームをDAC52へ送信する。ステップ212にお いて、オーディオリクエスト処理モジュール184はDAC52からの次のデータリクエ ストを待ち受ける。 図10ｂに戻ると、DAC52は、オーディオリクエスト処理モジュール184から受信 したデータフレームを、指定されたデコーダ入力バッファにロードする（ステッ プ214）。DACはその後、デコード動作を開始する前のスタートメッセージを待ち 受ける。ステップ216において、オーディオサーバ180は、DAC52へデコーダプレ イリクエストを送る。デコーダはそのデコードを開始し、ディジタルオーディオ 信号を出力する（ステップ218）。このデコーダが、デコーダ入力バッファ内の データフレームの予め定めた部分をデコードし終えたとき、DAC52は、リクエス トオーディオデータメッセージを、オーディオリクエスト処理モジュール182に 送出する。ステップ220において、オーディオリクエスト処理モジュール184は、 ハードドライブからデータフレームの次のセットを読み出し、この新しいデータ フレームのセットをDAC52に書き込む。オーディオリクエスト処理モジュール184 は再びウェイト（wait）ステートに入り、DAC52からの次のデータリクエストを 待ち受ける。ステップ218および220は、要求されたセグメントまたはオーディオ ファイルからのセグメントがオーディオリクエスト処理モジュール184によって 読み出され、DAC52に転送され、オーディオ信号として出力されるまで、または 、ユーザが介在するまで、繰り返される。 ステップ226において、DAC52は、デコーダ入力バッファ内に格納された最後の データフレームがデコードされそしてプレイされると、セグメントイベントの終 了を送出する。セグメントイベントの終了がオーディオリクエスト処理モジュー ル184によって受け取られると、オーディオリクエストプロセッサは（ステップ2 28）、そ のバッファからのデータフレームの最後のセットをクリアし、オーディオファイ ルをクローズする。加えてオーディオサーバ180は、オーディオセグメントの再 生動作が終了したときに必要ないくつかの付加的な処理を行う。これらの付加的 な動作には、テーブルのクリーニングアップやユーザへの通知や、コンタクトリ レーの開閉等があろう。 記憶されたセグメントを有するローカルスポットの自動再生 次に具体例を述べる。メモリ48上に記憶されたオーディオプログラムの再生中 は、ローカルオーディオセグメントがカートマシンにより自動的にプレイされる 。メモリ48上に記憶されたオーディオセグメントは、上述の再生動作に従って、 DSP104によりプレイされる。提示した一例にのみよると、記憶されたオーディオ プログラムは、２つのオーディオセグメント（ナショナルセグメント＃１および ナショナルセグメント＃２）を含むことができ、これらは、２つのローカルセグ メント（ローカルセグメント＃１およびローカルセグメント＃２）によって区分 される。 初めに、ナショナルセグメント＃１がメモリ48より読み出され、そしてデータ フレームのセットとしてDSP104に供給される。マーカー（marker）属性が、ナシ ョナルセグメント＃１が終了したときにローカルマシン（これはローカルセグメ ント＃１を含む）を起動するために接点が閉止されるべきことを表示するナショ ナルセグメント＃１、に割り付けられる。DSP104が第１ナショナルセグメントを 処理するとき、これは適当なオフセット時間後にマーカー属性を特定し、マーカ ーナンバーのようなマーカー属性メセージをDACイベントバッファ166に書き込む 。加入コントローラ46はマーカー属性メセージ（マーカーナンバー）をイベント バッファ166から読み出し、そしてこれに応答して、DAC52に対し、接点閉止信号 をライン 60（図４）上に出力すべきことを指示する。ここにその接点閉止信号は、第１カ ートマシン（ローカルセグメント＃１を含む）のプレイを開始させる信号である 。DAC52は次にカートマシン１からのセンサ入力ライン62をポーリングする。カ ード＃１内のローカルセグメントが終了したら、カートマシンは停止され、そし て接点開成信号はセンサ入力信号62に返送される。センサ入力62からの返送信号 は、加入コントローラ46に対し、カートマシンはローカルセグメントのプレイを 終了したことまたはローカルセグメントのプレイを終了しつつある（例えば30秒 以内に）ことを通知する。センサ入力ライン62に沿った入力に応答して、加入コ ントローラ46は、DSP104に対し、次のナショナルセグメント＃２のプレイを開始 すべきことを指示する。加入コントローラ46は、第１ローカルセグメントが終了 したとき、上記のように、DSP104に対しナショナルセグメント＃２をロードする 。 この具体例においては、マーカー属性＃２がナショナルセグメント＃２に割り 付けられ、このナショナルセグメント＃２は、第２ローカルセグメントが第２ナ ショナルセグメントの終了の後に続くべきこと表示する。DSP104が第２ナショナ ルセグメントを処理するとき、DSP104は、第２マーカー属性メッセージを、第２ ナショナルセグメントのプレイ中の所定の時に、データイベントバッファ166内 に書き込む。加入コントローラ46は、バッファ166より第２マーカー属性を読み 出し、そしてDSP104に対し、ライン60ｂ上に第２接点閉止信号を出力すべきこと を指示する。ライン60ｂ上の接点閉止信号は第２カートマシンに対し、第２ロー カルセグメントのプレイを開始すべきことを指示する。上記のとおり、第２カー トマシンが第２ローカルセグメントの終わりに至ったとき、第２カートマシンは ライン62ｂ上にセンサ入力信号を出力し、DSP104に対し第２ローカ ルセグメントの終了を指示する。付加的には、第２カートマシンは、第２ローカ ルセグメントの終了前の所定時間（例えば30秒）、ライン62ｂに沿ってセンサ入 力を供給することができる。このように、加入コントローラ46は自動的に、ナシ ョナルおよびローカルセグメントをクロスーフェイド（cross-fade）することが できる。 図11は、メモリ48に格納された２つのオーディオセグメント間のクロス・フェ ード動作の代表的なブロック図であり、カート装置によりプレイされるローカル スポットにより引き継がれる。本例の目的のために、プレイリストは次のカート ファイル名及びカートファイルのプレイを開始するときの指示を含むと仮定する 。 Segment #1‐Start Option，Manual Segment #2‐Start Option，Marker 2 Local Spot #1‐Start Option，Marker 1 さらに、セグメント＃１及び＃２及びローカルスポット＃１のためのカートフ ァイルは少なくとも次の属性を含むと仮定する。 Segment #1 Start Offset 0 End Offset 2000 Marker 2，1900 Audio File Name #1 Segment #2 Start Offset 400 End Offset 3000 Marker 1，3000 Audio File Name #2 Local Spot #1 Contact Closure，Cart 1 Sence Play End，Cart１ 図７及び図８に戻り、動作中、オーディオリクエスト処理モジュール184は、 初期においてカードコントロール122セグメントハンドル及びセグメント＃１及 び＃２の属性の対応リストに進む。セグメント＃１はオーディオファイル＃１（ 例えば、各位置はデータフレームに対応）にて位置０から2000に広がり、セグメ ント＃２はオーディオファイル＃２にて位置400と3000の間に広がる。 オーディオリクエスト処理モジュール184は、メモリ48からセグメント＃１及 び＃２に対するデータフレームの第１の組を得、その組をカードコントロール12 ：21に通す。データフレームの組は第１及び第２のデコーダ150及び152にてバッ ファに格納される。第１のデコーダ150はセグメント＃１からデータフレームを 処理する。オーディオリクエスト処理モジュール184は、第１のデコーダ150で必 要とされるとして、セグメント＃１から新たなデータフレームを提供する。第１ のデコーダ150が位置（例えばデータフレーム）1900に到達すると、DSP10はマー カ＃２を検出する。それに応答して、第２のデコーダ152は、セグメント＃２か らデータフレームの第１の組をデコードする。この方法で、図11のクロスフェー ド範囲500で示すように、第１及び第２のデコーダ150及び152は同時にデジタル データを出力する。クロスフェード範囲500において、ミキサ158は、ポイント16 0にて放送局に提供され及び／又はAES／EBU出力に提供されるように、２つのセ グメント出力を混合するため、オーディオセグメント＃１の大きさを減少し、オ ーディオセグメント＃２の大きさを増大する。 随時、第２のマーカイベント（例えば、マーカ１，1600）は、ミキサ158に指 示するためにセグメント＃１に対するカートファイルに加えられ、クロスフェー ド範囲500を減少させる前にセグメント ＃１の大きさの減少を開始する。この例では、ミキサ158はポイント504(ライン5 06で示す)ポイント504にてセグメント＃１の大きさを減少を開始する。第２のデ コーダ152はポイント508にてセグメント＃２を開始し、混合動作は上述のように 続けられる。 図11への続きとして、第２のデコーダ152は位置3000に到達するまで、処理セ グメント＃２を続ける。位置3000はセグメント＃２の端部に対応しマーカ＃１に 対応する。マーカ＃１は、対応するセグメントハンドルに沿ってイベントバッフ ァ166にて格納される。イベント管理モジュール190は、このイベントメッセージ をオーディオサーバ180に中継する。これに応答して、オーディオサーバ180は、 カート装置＃１へライン60（図４）上にて接点閉止信号を出力するために、カー ドコントロールモジュール182を経て、指示が目指すDAC52に戻る。接点閉止信号 は、ローカルスポット＃１のプレイを開始するためにカート装置＃１を指示する 。 オーディオサーバ180は、センサ入力信号がカート装置＃１からライン62に沿 って受信されるときを決めるためにDAC52にポールする。センサ入力信号はロー カルスポットが完全にプレイしたことを示す。DAC52はセンサ入力信号の受信を オーディオサーバ180に通知する。オーディオサーバ180はプレイリストにおける 次のカートファイルに基づきプレイを継続する。 ハブ端子を持つ記事配信システム 図12は本発明の記事配信システムの他の実施形態のブロック図である。記事配 信システム600は、データファイルを作るために上述の方法にて動作する少なく とも１つの生成サブシステム602を含む。随時、プロデューサ602はエンベロープ にデータファイルをアセンブルし、ライン618にそってハブ604にエンベロープを 通す。各エンベロープは後述の「エンベロープ・フォーマット」で述べるよ うに構成される。各ハブは上述した構成の加入者端子を含む。さらに加えて、各 ハブは、上述したような衛星受信機、及び／又はISDNリンクや電話回線リンク等 のデジタルデータの伝送を支援する１つ又はそれ以上の通信リンクを含む。 図12において、ハブ604がプロデューサ602からエンベロープを受信すると、ハ ブ604はエンベロープ内のアドレス情報を読み取りエンベロープを経路化する。 もしエンベロープがハブ604に指向しているならば、ハブ604は、受信データファ イルの格納とプレイバックのために、加入者端子に関連して上述の方法で動作す る。もしエンベロープがISDN系列606に指向していれば、ハブ604はリンク620に そってISDN系列606へエンベロープを経路化する。随時、ISDN系列は系列端子16 に関連して上述した方法で形成するが、しかしエンベロープ、ライブデータその 他の受信及び送信に対してISDNリンクを中継する。 ハブ604はマスタ・アップリンクハブ608に入力エンベロープを経路化する。ハ ブ608は、配信サブシステム14に関連して上述したようなアップリンク装置を含 む。ハブ608は衛星アップリンク624にそって衛星610へエンベロープを送信する 。衛星610はダウンリンク626，628及び632にそって入力エンベロープを送信する 。衛星加入者612は加入者端子16に類似する。衛星加入者612は上述した加入者端 子16として入力エンベロープを処理する。もしISND系列616がエンベロープ内で アドレス情報にて識別されるならば、ハブ614は、エンベロープを受信すると、I SDN系列616へエンベロープを経路化する。 衛星610は、視界の衛星ライン内で、全てのハブ、衛星加入者等に、全ての入 力衛星を送信する。受信に際しては、各ハブ及び衛星加入者はアドレス情報を識 別するためにエンベロープをアクセスす る。もしエンベロープが受信する衛星加入者及び／又はハブにアドレスされるな らば、それらはエンベロープを処理する。もし、エンベロープがハブ又は受信す るハブに接続されたISDN系列にアドレスされるならば、受信ハブはそこへのエン ベロープを経路化する。しかしながら、衛星加入者又はハブが、そこへアドレス していないか、又は受信ハブ又は衛星加入者に接続されたハブ又は加入者へ、エ ンベロープを受信するときは、受信する衛星加入者又はハブはエンベロープを無 視する。 例示の方法によれば、プロデューサ602は衛星加入者612へ指向されるエンベロ ープを発生すると、エンベロープは、エンベロープがハブ604又は加入者606へ指 向されないことを判断するハブ604に渡される。結論として、ハブ604は、マスタ 衛星アップリンクハブを示すハブ608へエンベロープを通す。マスタ衛星アップ リンクハブ608は衛星610を経てエンベロープを全ての衛星加入者及び衛星受信機 を持つハブへ中継する。ハブ614はエンベロープを受信し、エンベロープがハブ6 14又はISDN系列616へ指向されないことを判断する。結論として、ハブ614はエン ベロープを無視する。衛星加入者612はエンベローブを受信し、エンベロープが 衛星加入者612へ指向されていることを判断する。そこへの応答として、衛星加 入者612は上述の方法でエンベロープを処理する。 随時、全てのハブは衛星受信機を含む。 エンベロープ・フォーマット 各エンベロープは、記録部分に分割された多重データファイルから構成される 。各記録部分は、その対応するエンベロープとともに記録部を連合する特定のI. D.を含む。加えて、各記録部は、エンベロープが作られた生成サブシステムを特 定するプロデューサ・サブシステムI.D.を含む。プロデューサ及びエンベロープ I.D.は、特定 の識別及び配信システムを経て各エンベロープのトラッキングを可能にする。 随時、各エンベロープは、エンベロープが経路化されたハブ及び加入者のリス トを含むルーティング経路記録部を含む。ルーティング経路記録部は、エンベロ ープを受信し経路化する各プロデューサ及び加入者により更新される。例示のみ として、プロデューサ602がエンベロープを生成すると、ルーティング経路記録 部は、エンプティを開始する。エンベロープがハブ604に渡されると、ハブ604の I.D.はルーティング経路記録部に加えられる。このプロセスはエンベロープが宛 先に到達するまで繰り返される。従って、プロデューサ602から加入者616に進む エンベロープは、ルーティング経路記録部にて、加入者616における配信のとき 、ハブ604のハブI.D.、マスタハブアップリンク608、及びハブ614を含む。 ルーティング経路記録部は、単一のハブを経て経路化するサーキュラを防止す るためにシステムにより利用される。例示として、ハブ604は、衛星610からの衛 星送信を受信するための衛星受信機を含む。 次に、サーキュラ・ルーティングがルーティング経路記録部を使用して防止さ れる例を説明する。プロデューサ602は衛星加入者６12の指向されるエンベロー プを生成する。エンベロープはハブ604、ハブ608、及び衛星610を経て通る。こ の点において、ルーティング経路記録部は、ハブ604のハブ608のハブI.D.を含む ために更新される。衛星610がエンベロープを送信すると、加入者612及びハブ60 4と614はエンベロープを受信する。ハブ604はルーティング経路記録部をアクセ スし、エンベロープが既にハブ604を経て経路化されたことを判断する。結論と して、ハブ604はエンベロープを無視し経路を再ルーティングしない。 配信照合 随時、配信システムは配信照合を含む。配信照合によれば、パッケージが加入 者に送られると、プロデューサはトラッキング番号を提供される。プロデューサ の考えで、幾つかの異なるエンベロープ（各々異なる内容と配信アドレスを持つ ）を、ユーザに供給された宛先をもつ「グループ」にグループ分けする「ワーク オーダ」を作成する。ワークオーダは、単に実現可能性をもって異なる時間に提 出されたエンベロープの組を追跡するためのユーザへの方法である。プロデュー サには、プロデューサのエンベロープの配信のチェックのために800番をコール 可能にするモデム装着PCから使用されるソフトウェアが与えられる。掲示システ ムの一部として、ユーザには、エンベロープが配信され、どこに配信されなかっ たかの詳細が提供される。プロデューサに提供されるソフトウェアは、多くの受 け取り人に各々アドレスされた、多くの未処理のパッケージの管理を可能にする 。加えて、情報は、ワークオーダ宛先により検索される。システムへのアクセス は、ダイヤルアップダイレクト（800番）によるかインターネットを経由して行 われる。配合照合システムは次の機能を提供する。システムは配信ステータス情 報の集中を行う。システムの構成は集中化されていないが、しかしプロデューサ はエンベロープのステータスを見出す１つの位置に接触しようとする。配信情報 は集中化される。システムは共有のステータス情報を提供する。配信ステータス ・データベースは幾つかの「バックオフィス」アプリケーションの間で共有され る。このデータベースの幾つかの潜在的なユーザは次を含む。 ・掲示：掲示記録を発生するために使用される。 ・品質管理：性能を判断するための回顧的学習はこの情報を使用して行われる 。 ・追跡：ユーザはコールされとエンベロープがどこにあり、なぜ到達しないか を見出す助力を要求する。 ステータスデータベースは予測的であり、ユーザには配信が生じる時点に関し て正確な予測が与えられる。予測は配信が発出されるように更新される。トラッ キングシステムは、配信の異なる方法及び配信照合の関連機構を扱うことができ る。各配信は、それが配信される（ハブに送られる、FedExにエンターされる、 配信される）ように、潜在的に数個の異なるステータスを通過しなけばならない 。各配信装置は異なる照合要件を持つ。 ・ISDN：送信側にて配信時間に照合される． ・衛星：配信の時間にて受信機により照合される。受信機はその成功又は失敗 を中央機能に通信する。 ・ FedEx：FedExシステムは、パッケージが適切に配信されたことを見るため に問合せを行う。 ・組合せ：幾つかの配信は上述の組合せである。システムを経ての配信の進行 の照合は重要である。もしパッケージが紛失し、最後に適切に配信された位置に 追跡されるならば、これは真実である。 配信照合構成 配信ステータスコンピュータ(DSC)が規定されている。DSCではTCP／IPを経て 、ローカルLAN、マイクロソフトのRAS又はインターネットからの通信が行われる 。DSCはODBCを介してアクセスする共有のデータベースを保持する。データベー スは、現状及び履歴的な配信の全てのステータスを格納する。全てのパッケージ はハブに配信されると仮定される。これはシステムの設計を簡素化し、いずれか 所定の加入者の受信した資源上の制御を可能にする。この方法で、管理は、加入 者通信資源のスケージューリング上での制御を保持する。 ハブがエンベロープを受信すると、ハブはエンベロープのアドレスラベルを検 査しDSCへ進める「積出しリスト」を作成する。積出しリストは、DSCにおける配 信ステータスのデータベースを保持するためにエンベロープから全ての情報を含 む。 ・エンベロープの追跡番号：この番号は、全てのプロデューサ間の唯一のプロ デューサ指定者、及びそのプロデューサに唯一のエンベロープ番号で構成される 。 ・プロデューサにより割り当てられるエンベロープの英語名。 ・エンベロープが配信されるに必要な宛先のリスト。 ・エンベロープと共に連合されるいずれかのワークオーダ。 ・ハブにて受信されたエンベロープのデータと時間。 積出しリストは、どのようにしてエンベロープが経路化されるかをハブが判断 するのとは無関係に、DSCへ送られる。言い換えれば、例えエンベロープがアッ プリンクハブ（全てのローカル配信）に送られるとしても、積出しリストは、DS Cに送られる。積出しリストは、ダイヤルアップRAS又はインターネットを介して DSCに送られる。他のイベントとして、TCP／IPプロトコルが使用され、それによ り、受信ハブはDSCへの積出しリストの配信のポジティブな完全な確実性を持つ 。DSCは配信ステータスのデータベース(DSD)におけるエントリーを構成するため に積出しリストを使用する。必要なら、DSCは迅速なメッセージを、DSDへの変更 を示すためにDSCとともに「登録された」ものを持つバックオフィスアップリケ ーションに送る。DSCは、どのようにして種々の宛先に配信されるかを判断する ために、このデータベースにて情報を使用する。これは初期の配信予測を判断し 、各配信イベントに「状態図」を設定することを可能にする。各配信イベントの １つのエントリはDSDにて作られる。配信イベントは単一のエンベロープ／宛先 対である。状態図 は、配信に必要な論理経路にそってエンベロープの遷移を追跡する（例えば、衛 星へ、Wilmingtonへ、FedExへ、のアップリンク配信）。 ・衛星ダイレクト：衛星を介して直接加入者へのアップリンクハブ。 ・ISDNダイレクト：ISDN加入者は同じエリアに位置し、エンベロープを受信し たポストオフィスハブである。 ・IDSNへの衛星：アップリンクハブは、エンベロープを加入者に配信するハブ に、エンベロープを配信する。 ・オフリンク：Wilmington加入者へ、FedExへアップリンクハブの宛先。 配信経路の各脚部は完了を報告する。報告を完了するために使用されるメカニ ズムは、アクティブ（配信処理の幾つかの要素はDSCへの完了をアクティブに報 告する）又はパッシブ(DSCは完了を判断するために幾つかのアクションを起こす )である。完了を判断するメカニズムは配信技術に依存する。次がサポートされ ている。 ・ISDN：送信（ハブ）は、エンベロープが適切に配信されたことを報告する。 報告はDSCへ直接なされる。報告は互いに束にされ、失敗は直ちに報告される。 ・衛星：以下に述べる特定のポーリング技術が使用される。 ・ FedEx：FedExコンピュータは完了を判断するためにDSCによりポールされ る。ポーリングは、Divine Guidance及びファスチング(fasting)にそってFedEx 予測配信時間に基づく。 DSCはプロデューサ及びたの利害関係者からのコールを受け、発呼者の問合せ を可能にするTCP／IP基準規約と、配信ステータスに属する情報のDSDを提供する 。DSCは、DSD上での家事雑用を実行することを話して他のバックオフィスアプリ ケーションからのメッ セージを受ける。 衛星配信の確認 衛星が送信のみの媒体であったとしても衛星ベースのエンベロープの配信を確 認することができる。この場合、レシーバが情報を正しく受けとらなかったこと をレシーバが報告するための戻りチャネルがない。多数の潜在的なレシーバが使 用されるならば、配信が行なわれたかどうかを決めるために単純なポーリングを することは望ましくない。DSCは異なった形式のポーリング機構を使用すること ができる。衛星配信は通常は成功するものである。レシーバのみがエンベロープ を受け取ったかどうかを気にしている。エンベロープは一部のみが失われて部分 的に受信されるかもしれない。 上記の結果として、DSCは次の確認機構を実現する。規則的な周知の間隔でDSC はデータベースを走査しどの配信イベントが衛星配信を必要としているかを決定 する。DSCは最近配信したエンベロープのリストを含む「目録パッケージ」を組 み上げる。目録パッケージは上りリンクハブを経て衛星へ送出される。パッケー ジの宛先の加入者は目録パッケージを受け取りそれらの目録をパッケージ内の目 録と比較する。不一致があれば加入者はPOTSラインを使用してリセンドマネージ ャ(RSM)を呼び出す。不一致がなければ加入者は何もしない。エンベロープの受 信のどんなときでもレコードが失われているエラーがあると加入者が決定したら 加入者はRSMにコンタクトをとる。期待されるときに加入者が目録パッケージを 受け取らなかったら（エンベロープが受け取らなかった局に対するプレースホル ダとしてヌルパッケージが使用される）その加入者はRSPを呼び出す。DSCが同じ ファイル内に２つの目録パッケージを送って局側から何の苦情も受け取らなけれ ばDSCはそのファイルに対して配信されたとの記しを付ける。配信されたファイ ルはその後の目録パッ ケージには含まれない。 配布状態データベース DSCは配信過程の状態を定めるために使用されるテーブルの集まりである。次 のようなテーブルが定義される。 １．加入者データベース。このテーブルは局識別子とその局に達するパスとの 関係を定める。これは基本的に配信の形式（衛星、ISDN等）である。このテーブ ルはDSCがパッケージを追跡するために使われるであろう状態図を決定するため に使われる。 ２．プロデューサデータベース。プロデューサ番号とプロデューサの住所、電 話番号、ネームコンタクトのようなプロデューサ情報との関係を定める。 ３．配信イベントデータベース。このデータベースは各配信イベントのエント リを含んでいる。それらは次の様な欄を含んでいる。 ＊エンベローブ識別子。これはプロデューサ番号を含む。 ＊宛先指定。エンベローブがどこに配信されるべきか。 ＊処理順優先度。エンベローブがいつ配信されるか。エンベローブは配信の優 先度により各ハブと加入者によるルーチングのため並べ替えられる（例えば最優 先度のエンベローブは最初にルーチングされる）。 ＊処理順指定。これはオプションでありユーザから与えられる。 ＊現在の状態。 ＊配信に対する現在の最良の評価。 ＊配信状態図内の状態。 ＊DSCが完了アルゴリズムを実行するために必要な付加スタッフ。 リモートコントロール端末 図５はオンエアインター・フェースのような例示的なリモートコン トロール端末の概略斜視図である。リモートコントロール端末58はDJのブース内 からのような加入者端末の遠隔制御を提供する。リモートコントロール端末58は 加入者のコントローラ46において利用可能なすべての機能もしくはその一部のみ を可能にする。例えば、リモートコントロール端末58は与えられた曲目リストの オンエア製作のみについて関わる。リモートコントロール端末58はディスプレイ 70と制御キー72を含んでいる。制御キーは与えられた曲目リストなどの中でいく つかの様々なオーディオ選択肢の中からオンエアオペレータが選択することを可 能にする。加入者コントローラ46はリモートコントロール端末58においてどのオ ーディオ選択肢がオンエアオペレータに提示されオンエアオペレータがどれを選 択したかを決定する。一般にリモートコントロール端末58の介在がなければ、１ つのプログラム内からのオーディオセグメントの再生は曲目リストに基づく順番 で行なわれる。リモートコントロール端末58はオンエアオペレータが順番からは ずれたオーディオプログラムを選択することによりオーディオセグメントの通常 の順序を無視することを可能にしている。 制御キー72はオンエアオペレータが曲目リスト内から所望のプログラムを選択 することを可能にするための上下矢印を含んでいる。キー72は次のもしくは所望 のオーディオ選択物の再生を開始および終了させるためのスタートおよびストッ プキーを含んでいる。ディスプレイ70は現在再生されているイベントの終了まで をカウントするカウントダウンタイマを表示することができる。ディスプレイ70 はまた現在のオーディオイベントに対してアウトキューを提供する。ディスプレ イ70は各オーディオファイルと関連付けられた形式を含む、現在のプログラムを 制御するために使われる曲目リスト情報の一部またはすべてを表示することもで きる。 センサ入力62はDJからの再生要求を得るためにリモートコントロール端末を監 視する。この様にして、DJはDAC52が通常の再生リスト順序からはずれたプログ ラムを再生することを要求することができる。DJはまた、リモートコントロール 端末を介して、DAC52がDAC52にキュー記憶されている次のセグメントの再生を開 始し、現在のセグメントの再生を停止し、現在のセグメントをとばしてまたは次 の／以前のセグメントまで早送り／巻戻しすることも要求することができる。DJ はまたリモートコントロール端末上の上下矢印を使ってDJに対して表示されてい る曲目リストをスクロールし、順番を無視して曲目リストからセグメントを選択 することができる。DJはまたセンサ入力62を介してDAC52へ通知される試聴オプ ションを選択することによりセグメントを試聴することもできる。 加入者オーディオサーバ 加入者端末はプログラムディレクター、オンエアDJ、トラフィックユーザ及び 国外システムとのインターフェースを含む様々なユーザとの多数のインターフェ ースをサポートしている。プログラムディレクターインターフェースはプログラ ムディレクターに対して加入者コントローラ46を介してシステムが提供できる機 能のすべてを提供するためのものである。オンエアDJにはリモートコントロール 端末を介してアクセスすることができ曲目リストからのプログラムの再生、停止 および試聴のような限られた１組の機能が提供される。トラフィックユーザはロ ーカルプログラムスポットの利用可能性に関するドキュメントを調査することに 関心がある。トラフィックユーザはオーディオの再生に関する制御はできないが 、その代わりとして単に曲目リストなどを見ることができる。国外システムのユ ーザはRS232ポート、ローカルエリアネットワークなどを介して加入者コントロ ーラにアクセスすることができる。各国外ユーザはオ ーディオサーバ180(図８)を介して加入者端末と通信する。オーディオサーバは ユーザのタイプとユーザがアクセスした潜在機能の集合を特定する。上記のユー ザのタイプの各々は１以上のプロトコルを介してオーディオサーバへ通知される 。例示にすぎないが、ユーザとサーバの間の通信はTCP／IPソケットなどを経て 行なわれる。TCP／IPチャネルはASCII形式のテキストおよびバイナリデータの伝 送をサポートしている。 オーディオサーバ180は多数の異なるオブジェクトに対して有効である。ユー ザはプロトコルを介してオブジェクトにアクセスすることができる。例えば、１ つのオブジェクトはプレイヤーである。プロトコルメッセージはユーザがシステ ム内のプレイヤーの数を数えあげ（例えばそれらがいくつかあるか）、オーディ オをプレイヤーにロードし、プレイヤーに再生などをさせることを可能にする。 各オブジェクトはそれに関する状態を待っている。いくつかの状態情報はブー トアップからブートアップまで持続する（持続状態情報）のに対して、他の状態 情報はオーディオサーバが実行を開始するごとにセットされなければならない（ 一時的状態情報）。持続状態情報の例は或るスタジオに対する或るプレイヤーの 関連付けであり、一時的状態情報の例は或るプレイヤーが実際に再生しているか どうかである。プロトコルメッセージの或るものはオブジェクトの持続状態を変 更して他のメッセージはオブジェクトの一時的状態を変更する。 持続オブジェクトはオブジェクトの状態情報を含んでいるファイルを有してい る。ファイルはASCII形式のファイルで良い。ファイル内の各レコードはキーワ ードと値を含んでいる。 オーディオサーバのユーザはTCP／IPコネクションを確立することによりアプ リケーションへ接続することができる。２つのパスす なわちメッセージパスとイベントパスがサーバに対して確立される。メッセージ パスは双方向でありインターフェースクライアントとオーディオサーバの間の“ マスタスレーブ”モードの通信のために使用される。インターフェースクライア ントはマスターでありオーディオサーバへのメッセージを送る。オーディオサー バはレスポンスを戻す。イベントパスについては、オブジェクトはイベントおよ びオブジェクト内の状況（例えば、プレイヤーがオーディオを再生し終わった、 ユーザがボタンを押したなど）に関してクライアントに警告するためインタフェ ースクライアントへメッセージを送る必要がある。これらのメッセージはインタ フェースクライアントのイベントパスを経て送られる。 オブジェクトはまた“コンテナ”オブジェクトも表現する。これらのオブジェ クトは他のものを含んでおり、例えば、“テープラック”はオーディオファイル 、再生リストおよびカートファイルを含んでいるコンテナオブジェクトである。 再生リストは再生リストを構成するオーディオセグメントのリストを収容するコ ンテナである。コンテナはファイルディレクトリとして実現できる。デスクトッ プは最上位のディレクトリである。ユーザがシステムにログインするとユーザの は現在の作業ディレクトリはデスクトップとなる。これはそのディレクトリ内の オブジェクトを数え上げる目的で他のディレクトリへ移動できる。 オブジェクトはそれらが参照される前に“オープンされる”。オブジェクトの オープンはOPNメッセージで達成される。オブジェクトに対する参照が完了する とCLOメッセージがオブジェクトをクローズする。オブジェクトはリードオンリ ーモードまたはリード／ライトモードのどちらかでオープンされる。任意の数の ユーザがオブジェクトをリードオンリーモードでオープンすることができるが、 リード／ライトモードでは１人のユーザがオブジェクトをオープンすることがで きる。 オーディオサーバが実現することができるメッセージのリストを以下に示す。 呼び出し：CON＜user password＞ 戻 り ：AOK＜handle＞ コメント：この呼び出しによりユーザとオーディオサーバの間にコネクションが 確立される。オーディオサーバからの戻りはサーバからのアプリケーションへ戻 るイベントパスを確立するためにユーザが使用することができるハンドルを提供 する。 呼び出し：EVN（handle）CONの呼び出しで戻ったハンドルが使用される。 コメント：この呼び出しはメッセージをインターフェースクライアントへ送るた めにオーディオユーザが使用することができる同期イベントハンドルを生成する 。 呼び出し：RFE〔＜name＞〕オプション：読み出すべきラックの英語バージョン 。これが与えられなければデスクトップがオブジェクトのソースとして使用され ることに注意。 応 答 ：ERRまたはAOK＜name＞＜type＞ ＜name＞ エレメントの名前。これは“英語名”であってファイル名ではない 。引用記号で囲まれたスペースを含んで良い。この名前はオブジェクトを参照す るための他の呼び出しに使っても良い。このように使う場合、ここで戻ったよう に正確に再現されなければならない。 ＜type＞ エレメントのタイプ（例えば、カート、ラック、再生リスト、プレ イヤーおよびログ）。 コメント：この関数は現在の作業ディレクトリの第１エレメントを戻す。通常、 現在の作業ディレクトリの内容を確立するためにRNE（read next element）要求 が続く。内容は受信オーディオ及び他のユーザ対話に応じて変わるかもしれない ことに注意。これらの変化はユーザに対してユーザのコネクション内の“イベン トパス”を経て送られる。 呼び出し：RNE 戻 り ：ERRまたはAOK＜name＞＜type＞； AOKの引数の定義についてはRFEを参照。 コメント：ディレクトリに“次の”エレメントを戻す。 呼び出し：ONP＜how＞＜name＞＜type＞｛＜container＞＜type＞｝0-n ＜how＞オブジェクトをどのようにオープンするか（例えばリードオンリーモ ードかリード／ライトモードか）。 ＜name＞ オープンすべきオブジェクトの英語名。 ＜type＞ オブジェクトのタイプ（例えば、カート、ラック、再生リスト、プ レイヤーまたはログ）。 ＜container＞ オプション：“コンテナ”名。 ＜type＞ コンテナのタイプ（例えば、ラックまたは再生リスト）。 注 意 ：引き数＜container＞＜type＞は入れ子形式のコンテナ内のカートを 特定するために必要なだけ引き数が繰り返されても良い。 戻 り ：ERRまたはAOK＜handle＞ コメント：この関数はオブジェクトを排他的に使用するものとしてオープンする 。オープンが許されるたらそれらを操作す るためにハンドルを必要とする関数とともに使用されるオブジェクトへハンドル が戻される。ユーザがログオフしたときまたはユーザがCLOコマンドを発行した ときオブジェクトは解放されハンドルはさらなる意味を持たない。 呼び出し：HAS＜ename＞＜type＞； ＜ename＞ デスクトップオブジェクトの英語名。 ＜type＞ オブジェクトのタイプ。 戻 り ：AOK＜container＞またはERR。 コメント：これは主に、オブジェクトがその内容に基づき異なって描かれる場合 に、どのようにユーザインタフェースオブジェクトが描かれるかをチェックする のに使われる。 呼び出し：CLO＜handle＞ ＜handle＞ 成功したOPNリクエストによって与えられる処理。 応 答 ：AOK又はERR コメント：この機能はオープンされたオブジェクトを開放する。 呼び出し：RIN＜handle＞＜key1＞...＜keyn＞ ＜処理＞ オブジェクトに対するOPN処理。 ＜keyn＞ 読み出しキーワード 戻 り ：ERRエラーの場合、又は AOK＜value1＞...＜valuen＞ ＜valuen＞ リクエストされた＜keyn＞の現在値 呼び出し：WIN＜handle＞＜key1＞＜value1＞...＜keyn＞＜valuen＞ ＜handle＞ オブジェクトに対するOPN処理。オブジェクトは読み出し／書き 込みモードでオープンされなければならない。 ＜keyn＞ 更新する値のキーワード ＜valuen＞ 変更するキーワードの値 戻 り ：AOK又はERR コメント：全ての読み込み可能なキーワードが変更されなくてもよく、例えばカ ート演奏時間は物理的なプロパティにもとづき変更できない。 呼び出し：IRP＜object＞ ＜object＞ 読まれるべき演奏リストのオープンされたオブジェクト。ここで は、プレーヤ又は演奏リストのいずれかである。 戻 り ：AOK又はERR 呼び出し：RPR 戻 り ：AOK＜handle＞＜type＞＜arguments＞（コメント参照） ERR ＜handle＞ 演奏リストにおいて所定モードに対する独自の処理。現在のもの をSCEの演奏及びエレメントの削除に設定するのに使われる。 コメント：演奏リストレコードは、＜type＞引数に続く一連の引数である。それ らのフォーマットは以下の通りである： Remark：REM＜remark＞ ＜remark＞ 演奏リストについての注を含む文字列。 On Air Note：ONA＜remark＞ ＜remark＞ 演奏リストについての注を含む文字列。 Start Track：TRK＜title＞＜playtime＞＜outcue＞ ＜title＞ トラックに対する名称。通常“Segl”のようにつけられるが思い 付きのものでもよい。 ＜playtime＞ MSにおけるトラック演奏時間長。 ＜outcue＞ トラックのアウトキュー。 End Track：ENT トラックの終了 Cart：CRT＜type＞＜title＞＜playtime＞＜outcue＞ ＜type＞ ショー（例えば、コマーシャル、プログラム）のトラックにおける カートの使われ方。 ＜title＞ カートの英語タイトル。演奏リストディレクトリにおけるカート ファイルは発見されるのにこのカートタイトルと一致する必要がある。 ＜playtime＞ MSにおけるカート演奏時間。 ＜outcue＞ カートのアウトキュー。 Local Break：BRK＜time＞ ＜time＞ MSにおけるローカルブレーク継続時間。 呼び出し：GPS＜player＞ ＜player＞ ステータスを得るプレーヤのオープン処理。 戻 り ：ERR又は AOK＜state＞＜loaded＞＜cur＞ ＜state＞ プレーヤの現在の状態（例えば、演奏中、停止）。 ＜loaded＞ プレーヤに負荷が与えられているか又は空きであるかを示す。 １ 負荷中 ０ 空き ＜cur＞ 現時点の無線の処理 呼び出し：LOD＜player＞＜element＞＜type＞〔＜location＞〕 ＜player＞ 負荷が与えられるプレーヤのオープン処理。 ＜element＞ プレーヤ上に負荷されるエレメントのASCII名。 演奏リストのカートのいずれかでなければならない。 ＜type＞ 負荷するエレメントのタイプ（例えば、オーディオカ ート、オーディオ演奏リスト）。 ＜location＞ プレーヤのスタックにエレメントを負荷する位置。これはオプ ション事項である。与えなければ、通常の位置であり最初の位置である０へ負荷 される。 戻 り ：AOK又はERR コメント：負荷されるエレメントは、デスクトップ上になければならない。一度 、エレメントがプレーヤに負荷されたなら、二度とデスクトップ上に現れないこ とに注意すべきである。それは、プレーヤのディレクトリに移動する。 このコマンドを実行するにはプレーヤは書き込みアクセスによってオープンさ れる必要がある。 呼び出し：PLY＜player＞ ＜player＞ 演奏を開始するためのプレーヤのオープン処理。読み出し／書き 込みモードにおいてオープンされなければならない。 戻 り ：AOK又はERR。イベントは現在エレメントの終了時点で送られる。 コメント：プレーヤは複数のオーディオエレメントを有し、演奏を開始すると次 のオーディオ演奏を実行する。 呼び出し：CUE＜player＞ ＜player＞ オーディオ開始をキューさせるプレーヤのオープン処理。プレー ヤは読み出し／書き込みモードにおいてオープンされなければならない。 戻 り ：AOK又はERR。 コメント：CUE機能は、演奏動作の呼び出し時間を少なくする。CUEを使わない場 合にはCUEは演奏において暗黙される。CUEを実行するとPLYは直ちに実行される 。PLYとオー ディオ演奏の間の呼び出し時間は現時点におけるプレーヤ演奏リストの機能であ る。 呼び出し：STP＜player＞ ＜player＞ 停止させるプレーヤのオープン処理。プレーヤは読み出し／書き 込みモードにおいてオープンされなければならない。 戻 り ：AOK又はERR。 コメント：現時点で特定プレーヤの再生を停止させる。プレイの発行によってそ のプレーヤを停止時点から続けて演奏させる。 呼び出し：REM＜player＞〔＜player＞〕 ＜player＞ そこからエレメントを取り除くプレーヤのオープン処理。プレー ヤは読み出し／書き込みモードにおいてオープンされなければならない。 ＜player＞ 取り除くエレメントの処理。この引数はオプションである。省略 した場合には“最初の”エレメントが取り除かれる。 戻 り ：ERR又はAOK コメント：この機能により、クライアントはプレーヤスタックからエレメントを 取り除くことができる。 呼び出し：SCE＜player＞＜handle＞ ＜player＞ オープンされたプレーヤ処理。 ＜handle＞ エレメントに対する処理。読み込んだ演奏リスト内容から得られ る。 戻 り ：AOK又はERR コメント：プレーヤの現在のエレメントを確立する。次の演奏やオーディション 動作はこのエレメントを参照する。 呼び出し：RCE＜player＞ ＜player＞ プレーヤのオープン処理。プレーヤは読み出し／書き込みモード においてオープンされなければならない。 戻 り ：ERR又はAOK＜handle＞ ＜handle＞ エレメントに割り当てられた独自の処理。この処理は独立してお り、システムがリブートされるまで変えられない。 コメント：プレーヤのプレイスタックにおける現在の位置に関する情報を提供す る。 呼び出し：AUD＜player＞＜end＞ ＜player＞ オーディションに対するプレーヤのオープン処理。 プレーヤは読み出し／書き込みモードにおいてオープンされなければならない 。 ＜end＞ オーディションに対する現在のエレメントの終了時点。 ＜handle＞ エレメントに対する処理。読み込んだ演奏リスト内容から選択は ： ＋ｎ：エレメントの始めの“ｎ”秒オーディションし、それからエレメン トの開始位置へ；そして ｎ：エレメントの最後の“ｎ”秒オーディションし、それからエレメント の開始位置へ。 応 答 ：AOK又はERR。演奏が停止したとき送られるイベント。 呼び出し：MTR＜element＞＜type＞＜rack＞ ＜element＞ ラックに移動するデスクトップ上のエレメントの英語名。 ＜type＞ 移動するエレメントタイプ（例えば、カート、ラック、演奏リスト 、プレーヤ、ログ）。 ＜rack＞ ラックの英語名。ラックはデスクトップ上でなければ ならない。 戻 り ：AOK又はERR 呼び出し：MFR＜rack＞＜element＞＜type＞ ＜rack＞ ラックの英語名。ラックはデスクトップ上でなければならない。 ＜element＞ ラックに移動するデスクトップ上のエレメントの英語名。 ＜type＞ 移動するエレメントタイプ（例えば、カート、ラック、演奏リスト 、プレーヤ、ログ）。 戻 り ：AOK又はERR 呼び出し：DEL＜element＞＜type＞ ＜element＞ 削除するエレメントの英語名。 ＜type＞ 削除するエレメントタイプ（例えば、カート、ラック、演奏リスト 、ログ）。 戻 り ：AOK又はERR 呼び出し：MKR＜name＞ ＜name＞ ラックの英語名。 戻 り ：AOK又はERR コメント：この機能は同一名をチェックしてそれを許可しない。 呼び出し：CEN＜old-name＞＜new-name＞＜type＞ ＜old-name＞ デスクトップ上のエレメントの旧英語名。 ＜new-name＞ デスクトップ上のエレメントの新英語名。 ＜type＞ エレメントタイプ（例えば、カート、ラック、演奏リスト、プレー ヤ、ログ）。 戻 り ：AOK又はERR コメント：この機能は同一名をチェックしてそれを許可しない。 イベント・アーキテクチャ しばしば、サーバは、それに接続された１つ又はそれ以上のクライアントに情 報を送信しなければならない。例えば、クライアントリクエストによりサーバが 所定のオブジェクトを削除した場合には、全ての接続クライアントへ表示画面が 更新し得ることを通知する必要がある。他のイベント例では、プレーヤが演奏リ クエストされている全てのオーディオを演奏する時である。クライアントにはこ のことが通知されなければならず、それによって表示画面を更新し前記オーディ オ演奏が終了したことを示すことができる。 クライアントとサーバとの間の通信にTCP／IPが用いられるとき、第２のTCPコ ネクションとしてイベントが実行される。クライアントがサーバに接続すると、 クライアントはサーバ内に登録するようCONリクエストを発行する。サーバは、 サーバに対するクライアントの接続を識別する特別の“コネクション処理(conne ction handle)”を返答する。一度、サーバコネクションが確率されると、サー バに対し第２のTCPコネクションと第１のクライアントコネクションとを関連づ けるEVNリクエストが発行される。CONリクエストに応じて返されたコネクション 処理は、クライアントコネクションとイベントコネクションとを関連づけるのに 使われる。 一度、イベントコネクションが確率されると、着信情報をウェイトするのはク ライアントの責任である。DAXにおいて、これは“aserver.cpp”ソース・モジュ ールで実行される。スレッドが生成され、イベント状態で受信される全ての着信 メッセージをウェイトするのに使われる。メッセージは全て同じフォーマットで ある。 フォーマット：イベントをクライアントに報告する。 呼び出し：EVN＜id＞｛＜source＞｝｛＜argument＞｝ ＜id＞ イベント識別子。これはイベントを識別する十進数である。サーバに よって生成されたイベントはイベント定義という名 のセクションに記録される。 ＜source＞ イベントのソース。これはイベントのソースを示す。＜id＞との 関係においてのみ意味をなし、ソースは＜id＞において暗黙し得ることからオプ ション事項である。例えば、サーバが“ダウンしたこと”を示すイベントにソー スは必要ない。“プレーヤの停止”のような他のイベントではソースをもち得る 。この場合、ソースはプレーヤ名となろう。 ＜argument＞ ＜id＞に基づきスペースで分けられた１つ又はそれ以上の引数 でもよい。引数は＜id＞に含まれる情報を増大させる。 コメント：クライアントはイベントチャネル上にレスポンスを送出し、イーブン （even）メッセージには応答しない。その代わりに、クライアントはイベントに 対する適当なアクションを実行することで応答する。 演奏リストデザイン DAXオーディオ再生の核心は“演奏リスト”である。演奏リストは、互いに 関連性を有し様々なイベントに従って演奏されるオーディオカット（カート）の シーケンスを示すのに使われる。演奏リストは、基本的にはプログラムであって それをDAXプレーヤが翻訳して要求されたオーディオを生成する。 演奏リストは、ディスク上で拡張された“PLS”を伴うディレクトリによって 表される。前記ディレクトリにおいて、ファイルは常にディレクトリ名と同じ名 前がつけられる。但し、拡張子“TXT”をもつ。これは、演奏リストのASCII表現 である。また、ディレクトリにおいてカートファイルは演奏リストのオーディオ コンポーネントを構成する。通常、演奏リストを表すカートは演奏リストディレ クトリに置かれる。しかしながら、演奏リストは他に位置するカート を参照することも可能である。 演奏リストのテキスト表現は、次のセクションで述べられる多数のレコードで 構成される。 プレイリストレコード プレイリストは、一連のレコードである。全ての空白のライン及び「＊」文字 で始まるラインは、無視され、またコメントとして使用されることができる。各 レコードは、そのレコードを識別するキーワードで始まる。そのキーワードには 、１以上の空白で分離された０以上のフィールドが続く。次のレコードは、プレ イリストを構成する： レコード：REM＜remark＞ ＜remark＞ 各プレイリストについての注釈（remark）を含むストリング。 機 能 ：プレイリストが表示されるとき注釈がユーザに提供される。プレイリ スト内の注釈の位置は、どこに注釈が表示されるかを決定するために使用される 。トラックの外の注釈が最高位レベルで表示される一方、トラック内の注釈は最 高位レベルで表示され、トラックが表示されるときのみトラック内の注釈は表示 される。注釈は、ジョックボックス上には表示されない。 レコード：ONAIR＜remark＞ ＜remark＞ 各プレイリストについての注釈（remark）を含むストリング。 機 能 ：オンエア注釈は、注釈と同一であるが、ジョックボックス上に表示さ れる。 レコード：TRACK＜title＞ ＜title＞ トラックに関連するタイトル。これは、通常、“Segl”と類似し たものであるが、要求通りに想像的たりうる。 機 能 ：トラックを構成する要素のグループのスタートをマークする。なお、 システムがトラックのプレイ時間を自動的に計算することに留意する。 レコード：ENDTRACK 機 能 ：トラックのエンドをマークする。 レコード：CART＜type＞＜title＞＜start＞＜signal＞＜fadeout＞ ＜type＞ ショー（例えば、コマーシャル、プログラム）のこのトラックにお いてカート（cart）がどのように使用されるか。 ＜title＞ カート用英語タイトル。プレイリストディレクトリ内のカートフ ァイルは、発見されるべきカートのこのタイトルに一致しなければならない。 ＜start＞ どのようにカートがスタートされるべきか。そのオプションは、 以下のとおりである： MANUAL−ジョックボックスボタン押下又はスタート光学的入力のいずれかによ ってカートがスタートされる。 PREV −前のカートのエンドにてカートがスタートされる。 MARK1 −前のカートのマーク１によってカートがスタートされる。前のカート のエンドとこのカートのスタートとが混合される。 MARK2 −前のカートのマーク２によってカートがスタートされる。前のカート のエンドとこのカートのスタートとが混合される。 ＜signal＞ システムが生成すべき信号を指定する。この信号は、「信号リレ ー」上のパルスである。該＜signal＞フィールドに関する有効値は、以下のとお りである： NONE カート用に何の信号も生成されない。 END カートのエンドで信号を生成する。 MARK1 −マーク１ロケーションで信号を生成する。 MARK2 −マーク２ロケーション場所で信号を生成する。 ＜fadeout＞ カートのエンドで使用するフェードパターンの数。フェードパ ターンが決定されるべきである。 機 能 ：このレコードは、オーディオの要素を定義し、どのようにオーディオ がショーにおいてプレイされるべきかを決定する。 レコード：BREAK＜time＞ ＜time＞ ローカルブレークの期間。MM：SSとして指定される。 機 能 ：このレコードは、ショーにおけるローカルブレークを指示する。それ は、「スタートローカルブレーク」リレーを活性化せしめる。「スタート」リレ ーが作動せしめられるまで又はジョックボックス上でスタートボタンが押される までオーディオはこのポイントで休止する。 レコード：END 機 能 ：プレイリストのエンド。 リレー及び光学的入力の定義 加入者は、DACカード当たり、４つのリレー出力及び４つの光学的入力を有す ることができる。各カードは、リレーを次のように定義する： リレー出力 １．プレイタリ このリレーは、DAXがオーディオをプレイするときにはいつ でもクローズされる。 ２．スタートローカルブレーク このリレーは、ノーマルオープンであり、ロ ーカルブレークのスタートを指示すべくパルス的にクローズする。 ３．信号出力 このリレーは、ノーマルオープンであり、カートからの信号を 指示すべくパルス的にクローズする（CARTレコード＜signal＞定義を参照）。 ４．未割当て 光学的入力 １．スタートプレイ パルスが次のマニュアルカートプレイを開始させる。 ２．ポーズ 現オーディオイベントが休止しスタートプレイボタン押下を待つ ようにパルスが誘発する。 ３．オーディション 現オーディオトラックの最後の４秒がプレイされるよう にパルスが誘発する。 ４．未割当て ジョックボックス ジョックボックスは、スタジオに置かれたDACカートの物理的表示である。そ れは、８個のプッシュボタン各々にLED及び小さなLCDディスプレイを提供する。 概念的には、ジョックボックスは、自動化されたチェンジャーを有するCDプレー ヤである。多くのオーディオ要素がチェンジャー内に置かれうるのと全く同じ方 法で、多くのオーディオ要素がジョックボックスにおいて「ラケット」たりうる 。オーディオ要素は、単純なカート又はプレイリストのいずれかたりうる。プレ イリストが内部構造を有するため、ジョックボックスは、ジョックがディスプレ イ上で「ズーム」インするのを可能とするモードキーを有する。そのモードキー を押下することによって、ジョックボックスはトリーの多くを表示する。そのモ ードキーの連続押下によって、ジョックボックスは３つのレベルを巡回する。現 在、３つのレベルは以下のものを含む。 １．チェンジャーの内容を示す。これは、個々のカート及び個々のプレイリス トを表示する。 ２．チェンジャーの内容を示し、加えて、プレイリストにおけるトラックを表 示する。 ３．レベル２と同様であるが、トラックについてより詳細を提供する。 いずれの時においても、表示されたトリーにおいてエントリの１つが強調され る。このエントリは、現エントリであると言われる。オーディオがプレイしてい ないとき、この現エントリインディケータは、ジョックボックス上のフォワード キー及びバックワードキーを押下することによって移動されることができる。プ レイ中、ジョックボックスは、ストップを除く全てのキー押下をロックアウトす る。次の表は、各キー及び各種レベルでのそれらの効果の概略である。 DAX転送エージェント 通信機構にかかわらず、情報を転送する方法は、本質的に同一のままである。 ヘッドエンドは、リモートへの接続を確立する。LANバージョンにおいては、こ れは、TCP／IPソケット接続である。ヘッドエンドは、“FIL”コマンドを送って ファイルを導入する。ヘッドエンドは、０以上の“ATR”コマンドを送り、現在 送られているファイルの属性を確立する。属性は、ファイルに関連する「データ ベース」値である。ヘッドエンドは、１以上の“DTA”コマンドを送ることで、 ファイルそれ自体を送る。ヘッドエンドは、“END”マンドを送ることで、ファ イル転送を終結させる。ヘッドエンドは、次 のファイルをスタートするか、又は（リンクタイプでは）「ディスコネクト」す る。どんなときでも、“ABT”アボートファイル転送コマンドを送ることによっ て、転送を取り消すことができる。 転送エージェントコマンドセット ヘッドエンドと通信するソフトウェアのピースは、転送エージェントと呼ばれ る。転送エージェントは、ヘッドエンドに送られ又はそれから送られるコマンド を解釈する。それが応答するコマンドは、以下のとおりである： 呼び出し：COM＜blocksize＞ ＜blocksize＞ 送られる最大メッセージバッファのバイトによるサイズ。こ れは、次のDTAコマンドに関してレシーバを構成するために使用される。 戻 り ：ERR又はAOK コメント：このメッセージは、通常、転送セッションの始めに送られる。それは 、送信プログラムが使用しようとするブロックサイズについての、受信プログラ ムへの情報を提供する。 呼び出し：FIL＜title＞＜type＞＜〔＜collection＞〕 ＜title＞ オーディオに関する英語タイトル。 ＜type＞ オーディオのタイプ（例えば、オーディオのアート、プレイリスト ）。 ＜collection＞ このオーディオがその一部となるところのコレクションの名 称。コレクションの一部でないならば、このフィールドは、“−”に設定される 。 戻 り ：AOK又はERR コメント：このレコードは、ファイル伝送のスタートを表示するために送られる 。なお、＜title＞フィールドは、ファイルを一義的に識別するものであれば何 でもよいことに留意すべきである。それ は、必ずしもDMS内のファイル名である必要はない。さらに、ファイルは、「コ レクション」内に寄せ集められることができる。＜collection＞フィールドは、 そのコレクションを一義的に識別するASCIIストリングである。その観念は、コ レクションが、「ショー」すなわち、多分、オーディオのライブラリイを実現す るために使用されるということである。 呼び出し：ATR＜keyl＞＜value1＞...＜keyn＞＜valuen＞ ＜keyn＞ 属性を識別するキーワード。 ＜valuen＞ 属性の値。全ての値がASCIIストリングで表される。そのため、 例えば、属性がバイナリ値100を有するならば、それは、単一のバイナリバイト としてではなく、ストリング“100として送られるであろう。その値が埋め込み 型スペース文字を有するならば、その値は、引用符で囲まれる。 戻 り ：AOK又はERR コメント：ファイルは、そのファイルを記述するために使用される属性情報を有 する可能性がある。１以上のATRコマンドが、FILコマンドの後に送られる可能性 がある。ATRコマンドには、いくつかの属性キーワード対が存在しうる。その限 界は、やがて決定されるべきである。 呼び出し：DTA＜data＞ ＜data＞ そのファイルに適したデータバイト（例えば、オーディオファイル はオーディオバイトを有する一方、テキストファイルは同様にテキストを有する ）。 戻 り ：AOK又はERR コメント：ファイル内のデータは、テキスト又はバイナリのいずれかが可能であ る。転送の最初の４バイトは、ASCII文字の‘Ｄ’，‘Ｔ’，‘Ａ’及び‘ ’ を収容する。転送の第５バイトは、最初のデ ータバイトである。ブロックのエンドまでデータが継続する。 呼び出し：END 戻 り ：AOK又はERR コメント：現ファイル伝送のエンドをマークする。前のFIL，ATR及びDTAコマン ドによって命名されたファイルが成功裏に送られた。 呼び出し：ABT 戻 り ：AOK又はERR コメント：現ファイル転送をアボートする。このポイントに送られた全ての情報 が転送エージェントによって廃棄される。 加入者／DSPプロトコル 加入者コントローラによって制御されることができるDSPには、“Ｎ”ユニッ トが（概念的に）存在する。全ての通信が、加入者コントローラ／DSPインタフ ェースを横断して発生しなければならない。論理的に、「ユニット」は、加入者 コントローラによってアクセスされることができるDSP機能である。これらのユ ニットは、加入者コントローラからのメッセージを受入れ、かつ、加入者コント ローラに送られるメッセージを生成する。ユニットの１例はデコーダ０であり、 他の例はデコーダ１であり、また更なる他の例は入力衛星データである。加入者 コントローラは、所与のユニットへメッセージを送り、そのユニットの作動を制 御する。加入者コントローラのVxDドライバは、DSPのユニットを加入者コントロ ーラ内に「反映」し、加入者コントローラの所与の処理がこれらのユニットにア クセスする。当該プロトコルは、加入者コントローラとDSPとの間で任意のバイ ト列を移動せしめるように設計されている。当該プロトコルを実現するために使 用されるハードウェアに関して作られたいくつかの仮定が存在する。これらの仮 定は、以下のとおりである： １．加入者コントローラ／DSPリンクは、全二重である。加入者コントローラ とDSPとの間のパスは、２つの分離したパスからなる。加入者コントローラは、D SPが加入者コントローラにデータを送るのと同時に、DSPにデータを送ることが できる。 ２． DSPは、常に、加入者コントローラからのメッセージを受け入れること ができる。加入者コントローラがDSPにメッセージを送ることを望むとき、その 仮定は、直ちに受け入れることができるということである。加入者コントローラ は、DSPがそれを受け入れるのに「長い時間をとる」ことがないという仮定の下 で、メッセージを送ろうと試みるドライバ内で時間を費やす（加入者コントロー ラ上の割り込みはそのままであるが）。しかし、加入者コントローラは、加入者 コントローラからDSPへのデータバッファへオーバライトしないように、「ホス トFIFOビジー」ビットを尊重する。 ３．加入者コントローラは、“Ｉ”ビットがクリアされる限り、DSPにホスト ベクトルを送ることができる。DSPソフトウェアは、“Ｉ”ビット（ホストベク トルビジー）がセットされない限りいつでもホストベクトルを受け入れる。さら に、DSPは、長時間“Ｉ”ビットをセットされたままにしない（上記仮定＃２の 変形）。 ４．加入者コントローラ／DSP通信チャネルは、エラーフリーである。加入者 コントローラとDSPとの間には、エラー検出及び訂正が存在しない。この仮定は 、加入者コントローラバックプレーンがエラーフリーであるということである。 加入者コントローラからDSPへ及びDSPから加入者コントローラへ送られた各メッ セージは、同一の３つの基本的部分を含む。 １．ユニットメンバー これは、メッセージの「デスティネーション」の数で ある。「ユニット」の正確な意味は、異なるドライバの機能である。加入者コン トローラにおいては、例えば、ユニット は、１以上の加入者コントローラスレッドの通信を制御するＣ++オブジェクトで ある。DSPにおいては、ユニットは、DSPにおける所与のバッファ又は機能に対す るレファレンスになる。ユニット数は、メッセージの「アドレス」になる可能性 がある。 ２．長さ これは、メッセージを構成するバイトの数である。 ３．データ これは、メッセージの実際の内容である。 リンクの加入者コントローラとリンクのDSPサイドとの双方において、メッセ ージを管理するために使用される２つの原始的なオペレーション、すなわちリー ド及びライトが存在する。通信論理の全てが、加入者コントローラ及びDSPの双 方についてのこれら２つのルーチンに収容される。リードルーチン及びライトル ーチンの現オペレーションは、DMAを使用せずにデータを伝送することである。 付加的に、伝送されているメッセージバッファのサイズに依存することなく、DM Aを使用することを選択することができる複雑なルーチンを書くことができる。 DACクラス VxDドライバは、数個の異なるDACカードをサポートしなければならない。こ の理由のために、DACクラスが定義される。VxDドライバを何時ロードするかは、 何個のDACカードインスタンスを作る必要があるか、およびIRQ(および、その後D MA)割り当てが何であるかを決定するために、SYSTEM.INTファイルを調べる必要 がある。DACクラスのアウトラインは次の通りである： DACクラスの基本的機能は、VxDからパスされたIOCTL要求を処理することであ る。VxD中のIOCTLハンドラはリング３からパスされた制御コードを調べ、何をす べきかを決定する。制御コードの上位８ビットは、誰がIOCTLを処理するかを決 定する。０ｘ00から０ｘ03の値は、システム上の第１から第４のDACカードを選 択する（我々は一般に４個のDACカードのみをサポートするであろう）。０ ｘFFの上位バイトはVxDドライバそれ自身を選択する。ドライバはアーギュメン トをアンパックし、DACクラスの適正なインスタンスを呼び出す。VxD”OnW32Dev iceIoControl”のアウトラインは以下の通りである： この構造は、DACクラスに、自身が所有する個々のユニット上に送信されたメ ッセージに関してIOCTLコードが何を意味するかを見 出させる。DACのその他のメンバーの機能は、”HardwareInterrupt”を除いては 、単純である。問題は、VxDがDSPから割り込みを受ける事である。これは、DAC クラスインスタンスと関連付けられる必要がある。これは次のようにする事によ って実行される：によってIrqメンバー機能を初期化する。 さて、割り込みが在った場合、特定化されたIRQのためのハンドラーが呼び出 される。このハンドラーは、そのプライベートな”Mycard”メンバー変数として 、その割り込みが属するDACインスタンスへのポインターを有する。ハンドラー が成す全ては： である。 これによって、DACクラスの正しいインスタンスに対して、適正なハードウエ ア割り込みルーチンが呼び出される。（Ｃ++で書かれた）PCプロトコルの操作に 対するキイは、“ユニット”クラスの定義である。PCおよびDSP間の異なるタイ プの通信は、そのコードにおいて同一である部分が大きいが、しかし同様に送信 された情報のタイプに依存する部分を持つことが予想される。例えば、PCが衛星 情報を受信すると、リング３が情報要求を処理するまで、それをバッファしてお く必要がある。しかしながら、入力光アイソレータの現在の状態をバッファする 必要はなく、単に記憶するだけで良い。ユニットベースクラスから異なるクラス を導出することによって、これらの固有の機能は容易に達成できる。DACクラス がそのコンストラクタへの呼出しによって始まると、それはユニットクラスの全 てのインスタンスを形成し、それらをユニットテーブル中に記憶する。同様に、 DACクラスが削除されると、ユニットテーブル（アレイ）中を歩き回り、各メン バーを削除する。このユニットクラスは以下のように見える： 種々の部分の機能は以下の通りである： ユニット−クラスの１インスタンスを形成する。アーギュメントは“ユニット 番号”であって、これらはPCからDSPに送られた全てのメッセージ上で、および このユニットを“所有する”DACクラスのインスタンス上で使用される。このイ ンスタンスは、このユニットのインスタンスによってカードチャンネルへの専用 アクセスを獲得するために使用される。 〜ユニット−クリーンアップルーチン。VxDはダイナミックにロード可能であ るので、それがアンロードされると、ルーチンはこのユニットによって使用され たリソースをクリーンアップする。 リード−対応するDSPユニットからメッセージを読み取る。この機能は、メッ セージが入手可能と成るまでスレッド呼出しをブロックする。更に、もしスレッ ド待機が無い場合にメッセージが受信されると、そのメッセージはバッファされ 、記憶され、あるいは特定のユニット定義に因っては放棄される。 ライト−対応するDSPユニットにメッセージを書き込む。 ロック−所定のスレッドがユニットをロックすることを許可し、それによって 第２のスレッド介入無しにライト／リード対操作を実行することを可能とする。 アンロック−スレッドがユニットを手放すことを許可する。 フラッシュ−ユニットに対して受信されかつバッファされた全てのメッセージ を放棄する。 割り込み−ユニットに対して特注された割り込み機能。この機能は割り込み時 間においてユニット特定コードが実行されることを許可する。 リードセマ−DSPの対応するユニットからの入力に対してスレッド待機を制御 するために使用される、セマフォ(Semaphore)。 ユニットセマ−ユニットのロックを制御するために使用されるセマフォ。 クラスDaxSemaphoreは、Vsemaphoreが供給しない幾つかの付加的な特徴を提供 する“リアルVxD”セマフォの回りの“ラッパー(wrapper)”である事に注意する 必要がある。それが提供する最も重要な特徴の一つは、DaxSemaphoreオブジェク トが削除された場合に待機タスクを開放する方法である。これは、タスクがセマ フォを待っている場合であっても、整然としたシャットダウン（の試み）を許可 する。ライト(Write)機能によって、スレッドはDSPへのアクセスを待ち、一旦そ れが獲得されると、メッセージをdspに書き込みDSPを開放する。ライト操作が出 力ループにおいて“スタック”しないことを保証するために、タイムアウトを使 用する必要のある事に注意すべきである。DSPがそれへの書き込みを行っている 間に不足する事があり、その結果“生きビット(busy bit)”はアップし、これに よってスレッドはドライバ中でハングすることがあることに注意すべきである。 ライトループを中止する方法を見いだすことは素敵なことである（タイマー？我 々がDSPを待つ時間をカウントする？）。 ユニットの“リード”セマフォをブロックするルーチン。このアイデアは、こ こでは、ユニット上でスタックした各“バッファ”に対してリードセマフォを増 分することである。これらのバッファは、ユニットの“データ”メンバーからス レッドオフ（リンクされたリスト？）される。 注意：上記コードにおいて、幾つかの微妙な（かつあまり微妙でない）理由か ら、割り込みはオフ状態とされる： １．ユニット上のデータバッファリストは、リストが割り込みサービスルーチ ンによって変更されないことを保証する割り込みサービスルーチンによって、臨 界領域を形成する。単にDSP割り込みをマスクする事によって、これと同じ結果 を達成する事が可能である。これは全ての他の割り込みをオンのままとするが（ 良いことである）、しかし... ２．割り込みをオフ状態とすることによって、別のスレッドがこのリードルー チン中に入り込みこのスレッドを追い越さない事を保証する。この場合：リスト 上には２個のバッファがある。割り込みシステム(CLI)をオフ状態とする代わり に、我々はIRQを単にマスクする。我々がセマフォチェックを送ると、割り込み 量(quantum interrupt)が終わりになり、別のスレッドが実行される。このスレ ッドはまたリードを呼出し、セマフォを送り出しさらにその後我々が第１のスレ ッドにおいて半分を有したバッファを獲得する。両方のスレッドがそのバッファ を有していると考えるため、バッファキューは混乱する（夜間において一方が遅 いことを見いだそうと試みる）。 ロックルーチンは、スレッドがユニットを保持していることを保証するのみで ある。スレッドはユニットのセマフォとDSPのセマフォを得ようとすることに注 意すべきである。デッドロックにたいするチャンスが此処にある。保護のために 、次の様なロック／アンロックシーケンスを実行する： このロックユニット、ロックdsp、アンロックdsp、アンロックユニットシーケ ンスは、デッドロックが無いことを保証する。 これは割り込みルーチンである。ここでの仮定は即ち： １．我々が二回目のISVに入るようにDSPが強要しないための予防を割り込みハ ンドラにおいて我々が取るかぎりにおいて、割り込みシステムがオン状態となる ことが許可でき、さらに... ２．セマフォ“信号”ルーチンは、実際、割り込み時間において呼出し可能で ある。 若し上記＃２が真で無い場合、その後のコードはとにかくグローバルイベント に設定されるべきであり、その後そのイベントから呼び出される。コードがユニ ットのメンバー機能であると言う事実によって、これは幾分複雑となる。我々は 、このユニットのポインタをグローバルイベントのハンドラに送る必要がある（ これは、ユニットポインタに対するコンストラクタ中の一個の場所を含む、グロ ーバルイベントのサブクラスを定義し、その後ポインタを導出されたハンドラ機 能中のプライベートな変数中に記憶することによって行われる--）。次のコード はDacクラスの一部分であり、ハードウエア割り込みが所定のカードに対して受 信された場合、呼び出される。これがどの様にして起きるかは、“Dacクラス” のセクションを 参照されたい。このコードは割り込み時間において呼び出され、以下を実行する ： １． DSPからの更なる割り込みを禁止する。 ２． DSPからメッセージが在るか否かを見るためにチェックする。もし無い 場合、次にDSP割り込みを可能とし（次のメッセージの準備において）、そして 出る。 ３．もしメッセージがあれば、DSPからユニット番号を読み出す（使用するユ ニットのインデックス）。さらに、ユニットの割り込み機能を呼び出す。 これはそのユニットクラスの“デフォルト”割り込みプロセッサである。これ はDSP中にまだ存在する“長さ”ワードによって呼び出される。そのジョブは： １． DSPからのデータを入れる場所を割り当てる。 ２．データをバッファ中にコピーする。 ３．ユニットバッファキュー上にバッファをスレッドする。 ４．バッファがそれによってセマフォを定義する信号待機スレッド DSPプロトコル このセクションでは、DSPのためのプロトコルの実行について議論する。この 設計は、Ｃ−ライク擬似コードによって表現される。DSPにおいて、ユニットは 、バッファのリンクされたリストを表す実際のデータ構造である。DSPは異なる ユニットに対してバッファの異なるタイプを維持する。例えば、デコーダユニッ トは、MUSIC AMフレームの特定数を保持するに十分な大きさのバッファを維持する。各バッフ ァは次の様なものである： DSPにおいて数個のキイルーチンが存在する。これらは WritePC−このルーチンはバッファを要し、PCへの書き込みを開始する。 WriteInt−これはPCルーチンへの書き込みの半分の割り込みである。これは、 DSPのデータポートからのワードをPCがロードする毎に割り込みを介して呼び出 される。 ReadPC−受信メッセージルーチン。PCがNEW＿MESSAGEホスト割り込みを送信す る場合、このルーチンに入る。 ReadInt−これはリードPCルーチンの半分の割り込みである。PCがDSPのデータ ポートに書き込む毎に割り込みを介して呼び出される。 PCInt−このルーチンはPC割り込みを生成するためおよびPC割り込みを禁止す るために呼び出される。キイとなる仮定は以下の通りである：もしPCがPICチッ プをマスクさせ(DSP IRQに対して割り込みを禁止する)かつDSPかPC中への割り込 みを主張すると(PCInt(ON))、PICチップが次にアンマスクされた時この割り込み が発生する。 追加の仮定は、PCがDSPデータバッファ中にワードを挿入した時 に発生する割り込みは、禁止され得ることである。更にPCがDSPデータバッファ からワードを除去した時発生する割り込みもまた、禁止され得ることである。 WritePC WritePCおよびWriteIntルーチンは同時に働く。このルーチンのための擬似 コードは以下の通りである： TransferInProgress=FALSE; struct buf^*SendList=0; WritePCルーチンはPCにメッセージを送るために使用される。メッセージは それらが受信された状態でSendList中で待機させられる。 WriteIntルーチンはワードがDSP出力バッファから取り出される毎に呼び出さ れる。 ReadPC ReadPCとReadIntのルーチンは共にPCからデータを得てDSPへ入力する動作をす る。PCからメッセージを受け取ったとき、定められたユニットになるためのメッ セージのリストが並べられる。DSPの状況では、“ユニット”は実際には同じユ ニット番号の付いた受け取られたメッセージのリストである。PCがメッセージを DSPへ送りたいとき、それはNEW MESSAGEホスト割り込み（host interrupt）を 送出する。このことによってメッセージがReadIntルーチンに よってDSPに読み込まれるようになる。メッセージバッファは適切なユニットで 列が作られる。ユニットはその後マスタールーチン（master routine）によって 得られ、メッセージはそれによって処理される。この処理によって応答が発生す る。これらの応答はWritePCルーチンを経由して送られる。 メッセージ（Message） このセクションではDSPとPCとの間を通る各メッセージについて議論する。メ ッセージは２つの一般的なカテゴリーに分類される。 １．肯定応答（Acknowledged） これらのメッセージは応答が必要である。例 えば、デコーダの状態をリクエストするメッセージは、デコーダからの応答（状 態）が必要である。このようなトランザクション（transactions）はリクエスト メッセージと応答メッセージとの対になる。肯定応答メッセージは“書き出し／ 読み込み”型ユニットへのみ送られる。 ２．否定応答（Unacknowledged） これらのメッセージは送られるが、応答は 期待されない。 肯定応答メッセージの問題は、それを送るスレッドは、スレッド（thread）が 応答を待ち受けている間、他のスレッドが通信チャン ネルを使わないことを保証するということである。この理由は、メッセージとそ れらの応答が適切にシーケンスされることを保証するために、Unit::Lock( )とU nit::Unlock( )のルーチンの呼び出しをスレッドは全てしなければならないから である。リクエストのために応答が生成されたとき、該応答はオリジナルのリク エストの場合と同じメッセージ番号を使う。たとえば、もしREAD＿OPTICALメッ セージがDACに送られたなら、それはREAD＿OPTICALがそのメッセージ番号である ように応答する。 ユニット割り付け（Unit Assignments） 潜在的に、いずれのユニットもPCとDSPとの間の双方向通信をサポートできる 。実現を簡単化するために、どのような方法でも、ユニットは３つの違った方法 でのみ利用される。 １．読み出し専用(read only) これらのユニットのタイプでは、DSPからPCへ 各メッセージを伝送するのに使われる。読み出し専用ユニット（read only unit ）の例としては、“衛星データ(Satellite data)”ユニットがある。衛星から衛 星データを受け取ったときDSPはそれをこのユニットへ書き込む。PCは衛星デー タユニットへはメッセージを決して書き込まない。 ２．書き込み専用（Write only） これらのユニットのタイプでは、PCからDS Pへ各メッセージを伝送するのに使われる。DSPはこれらのユニットにわたってPC に情報を決して送らない。このユニットのタイプの例としては“コントロール” ユニットがある。 ３．書き込み／読み出し（Write/Read） これらのタイプのユニットは、PCか らDSPへ情報を伝達することとDSPから戻ってくる情報を受け取ることに使われる 。“ラド光学的入力(rad optical inputs)”ユニットはこのタイプのユニットの 例である。書き込み／読み出しユニットに対して、PCはメッセージをDSPへ書き 込み、その 後PCはDSPの応答に対する待ち受けをブロックする。 ユニットのタイプ（読み出し専用、書き込み専用、書き込み読み出し）を知る ことによって、ユニットを実現するために使われる導き出されたクラスが、ユニ ットがシステムコードから適切に呼び出されることを保証するようなエラーチェ ック（例えば、書き込み専用ユニットの読み込みルーチンがエラーをひっかける こと）を実行することが許される。以下のユニットはDAXプロトコルとして定義 される。“読み出しと書き込み”の指示はPCの斜視図（例えば、読み出し専用は PCがユニットからのみ読み出すことを意味する）に関係することに注意する。 コントロール−〔Unit #0、書き込み専用〕コントロールユニットはPCからDSP へ応答の必要のない全メッセージを送るのに使われる。 イベント−〔Unit #1、読み出し専用〕DSPからPCへのイベントメッセージ（Ev ent messages）はイベントユニット（Event unit）へ書き込まれる。PCはイベン トメッセージを待ち受けるためにこのユニットを読み込む。 補助データ（Ancillary Data）−〔Unit #2、読み出し専用〕デコーダからの あらゆる補助データはこのユニットに書き込まれる。 衛星データ（Sat Data）−〔Unit #3、読み出し専用〕受け取られた衛星の情 報(MUSICAM記録とコマンド記録)はこのユニットで読み出される。 光学的入力(Optical input)−〔Unit #4、書き込み／読み出し〕PCはカードの 光学的入力のステートをリクエストでき、このユニットからの応答を読み出すこ とができる。 デコーダ・ステート（Decorder State）−〔Unit #5、書き込み／読み出し〕P Cはカードのデコーダのステートをリクエストでき、 このユニットからの応答を読み出すことができる。 リクエストオーディオ(Request Audio)−〔Unit #6、読み出し専用〕このユニ ットにわたってより多くのオーディオを得るようにDSPはPCにリクエストを送る 。 ユニット割り付けの原理は次の通りである。 １．もしメッセージが応答を持たなければ、それをコントロールユニットに割 り付ける。このことはコントロールメッセージは別のスレッドによって応答に対 する待ち受けがブロックされないことを保証する。 ２．もしメッセージが応答を必要とするならば、それを自身のユニットに割り 付ける。このことはそれら自身で応答に応対しているスレッドを待ち受けること がブロックされないことを保証する。 ３． DSPが非同期に生成するあらゆるメッセージは、それ自身のユニットに 割り付けられる。 PCからDACへのメッセージ このセクションは、PCからDACへ送られるすべてのメッセージを含む。それは 各メッセージにユニット割り付けを供給する。任意に各バイトは２つの方法のう ち１つで送られる。 １．できるだけタイトに各バイトをパックする。このことは各バイトを転送す るためにDSPが応答しなければならない割り込みの数を最大限に利用するが、し かしそれによってDSPが受け取った各バイトをアンパックすることが必要となる 。 ２．オリジナルのサイズに関係なく24ビット語として全ての引数を送る。この ことによってDSPがより簡単にアンパックのジョブ(unpacking job)ができるよう になるが、しかし、転送されるバイト数は著しく増加する。最大のバイト数はMU SICAMフレームあるいは受け取られた衛星の情報として送られる。これらは完全 にパックさ れた24バイト語として送られる。 どのようにしてデータを送るかについての決定を遅らせるために、“メッセー ジクラス(message class)”は以下のサービス（services）を提供するよう定義 される。 メッセージクラスは実際のメッセージのフォーマットをカプセルに入れる(enc apsulate)。それはより上位レベルのルーチンから呼び出され、メッセージバッ ファを構成するのに使われる。前記バッファはその後カードへ送られる。しかし ながら、これら全てが与えられると、各メッセージ、データの長さと引数は、ユ ニークにそれであると識別するためのメッセージ番号を持たなければならない。衛星データ選択スイッチ(satellite data selection switch)をセット ユニット（Unit）：コントロール、ユニット＃０ 引数（Argument）：スイッチポジションコード(Switch position code)(１バイ ト） 応答（Response）：なし コメント（Comments）：スイッチの各ポジションは次の表に示される。 これらの値のみ有効である点に注意する。 スイッチポジションの他のあらゆる値は無効である。局アドレス(station address)をセット ユニット：コントロール、ユニット＃０ 引数：局アドレス値(Station address value)(２バイト) 応答：なし コメント：16ビットの引数は局アドレスとして使用される。局をグループに加える ユニット：コントロール、ユニット＃０ 引数：局を加えるグルーブの番号(Group number to add station to)(２バイト) 応答：なし コメント：局を特定のグループに加える。本システムには最大512の全く異なっ たグループがあり得る。すべてのブートアップ（boot up）の後は、DACのカード はどのグループの番号でもない。引数の下位９ビットだけ試験される。もし局が すでに特定のグループの番号であれば、そのときはリクエストは無 視される。局をグループから取り除く ユニット：コントロール、ユニット＃０ 引数：局が取り除かれるグループの番号(Group number to remove station from )(２バイト) 応答：なし コメント：局を特定のグループから取り除く。引数の下位９ビットだけグループ 番号を決定するのに使用される。もし局が特定のグループの番号でなければ、呼 び出しは無視される。光学的入力を読み出す ユニット：光学的入力、ユニット＃４ 引数：引数なし 応答：下位４ビットの光学的入力の値（１バイト） コメント：これは光学的入力の値を読み出す。リレイのコントロール ユニット：コントロール、ユニット＃０ 引数：上位ニブルはリレイ番号（０−３）下位ニブルは次の表から得られる動作 である。（１バイト） パルス継続時間（MS）。もしパルス動作がないならば、０にセットする。（２ バイト）応答（Response）：なし コメント（Comments）：セグメント情報をロードする ユニット（Unit）：コントロール、ユニット＃０ 引数（Argument）：以下の引数はメッセージの順に示される。 １．セグメントID（Segment ID）．これはセグメントを識別するためにDSPが 使用できるユニークな番号である。（２バイト） ２．デコーダ（Decorder）：このセグメントをどのデコーダにロードするか。 これは０あるいは１のいずれかである。（１バイト） ３．スタートフェード（Start Fade）：セグメントの再生(play back)が開始 するとき使われるフェードパターン（fade pattern）の番号。０のパターン番号 はフェードしないことを意味する。（１バイト） ４．エンドフェード（End Fade）：セグメントの再生が終了するとき使われる フェード・パターンの番号。０のパターン番号はフェードしないことを意味する 。（１バイト） ５．マーカー１ポジション(Marker 1 Position). セグメントのスタートから のフレームのマーカー１の位置。ポジションはセグメントの終わりを越えること ができない点に注意。０という値はマーカー１が存在しないことを意味する。（ ３バイト） ６．マーカー２ポジション(Marker２Position). マーカー１と同じ定義。（ ３バイト） ７．スタートオピニオン(Start opinion)：セグメントがプレイを開始するイ ベント。値は以下から得られる。（１バイト） ０：PCからのスタートコマンド １：本チャンネルにおける前のセグメントの終わり ２：別のチャンネルにおける最も新しくロードされたセグメン トの終わり ３．別のチャンネルにおける最も新しくロードされたセグメントのマーカー ＃１ ４．別のチャンネルにおける最も新しくロードされたセグメントのマーカー ＃２ ８．イベント信号（Event signal）次の状態の下のPCに対してイベントを生成 する。各値は１つ以上のイベントを生成するために結合されることに注意する。 （１バイト） ９．ミュート（mute）するフレーム時間の番号。もしゼロでないならば、これ は時間ミュートを生成する疑似セグメントである。（３バイト） 応答：なし コメント： DSPは、セグメントIDに基づいて再生するためのデータリクエスト する割り込みリクエストを生成し、そのリクエストはデータに対応するセグメン トIDに基づいて行われる。セグメントプレイスタック（segment play stack）をリセット ユニット：コントロール、ユニット＃０ 引数：リセットするデコーダの番号（１バイト） １：デコーダ−０ ２：デコーダ−１ ３：両デコーダ 応答：なし コメント：もしデコーダがプレイしているのならば、そのときははじめにストッ プし、その後リセットする。デコーダ・プレイ（Decoder Play） ユニット：コントロール、ユニット＃０ 引数：プレイを開始するテコーダの番号（１バイト） １：デコーダ−０ ２：デコーダ−１ ３：両デコーダ 応答：なし コメント：デコーダをストップする ユニット：コントロール、ユニット＃０ 引数：プレイをストップするデコーダの番号（１バイト） １：デコーダ−０ ２：デコーダ−１ ３：両デコーダ 応答：なし コメント：ライブレイ（live lay）を開始する ユニット：コントロール、ユニット＃０ 引数：なし 応答：なし コメント：セレクタスイッチに接続されたデコーダがライブ再生を開始する。デコーダステート(decoder state)を得る ユニット：デコーダステート、ユニット＃５ 引数：興味のあるデコーダの番号（１バイト） １：デコーダ−０ ２：デコーダ−１ 応答：３つの値 １．デコーダのステート：これは０：ストップ、１：プレイ、２：ライブプレ イ（１バイト） ２．プレイされているセグメント番号。もしステートが０（ストップ）あるい は２（ライブ動作）ならば、０という値が戻される。（１バイト） ３．プレイされているフレーム番号。もしデコーダがストップさせられている のなら戻り値は０。（３バイト）デコーダゲインのセット ユニット：コントロール、ユニット＃０ 引数：デコーダ番号（１バイト） ０：デコーダ−０ １：デコーダ−１ ２：両デコーダの同時のゲイン変更。 ゲインレベル（２バイト） レスポンス：なし コメント：特定のデコーダに対するゲインレベルの変更。 MUSICAM データ ユニット：コントロール、ユニット＃０ 引数：データをプレイするデコーダ番号。これは０又は１となる。 送られるフレームの数（０は、セグメント中にフレームが存在しないことを意 味する）。 MUSICAMフォーマットされたフレームの全数。 レスポンス：なし コメント：このメッセージは、DSPの「オーディオデータのリクエスト」に応答 して送られる。 DACからPCへのメッセージ このセクションは、DACがPCに送ることができるメッセージを概説する。オーディオデータのリクエスト ユニット：オーディオのリクエスト、ユニット＃６ 引数：セグメント番号（１バイト） デコーダ番号（１バイト） DSPが受入れ可能なMUSICMフレームの最大数（２バイト） レスポンス：後でPCは新たなデータと共にMUSICAMデータメッセージを送る（リ クエストに対する厳密なレスポンスでない、即ち、DSPはレスポンスを持たない ）。 コメント： DSPは、もっとMUSICAMデータが必要であると感じたときは、このリ クエストを送る。衛星データ ユニット：衛星データ、ユニット＃３ 引数：衛星からのデータ。これは、バイトのシーケンスである。 レスポンス：なし コメント：衛星データのレシーバは、そのデータの意味を理解する。DSPはデー タと同期し、データが特定のDACカードにアドレスされるように決定するに十分 なヘッダを認識する。データのフォーマットは後日決定される。イベントデータ ユニット：イベント、ユニット＃１ 引数：イベントメッセージ。各メッセージは同一フォーマットを有する。各メッ セージ中に送られたイベントの全体の数がある。 レスポンス：なし コメント：イベントメッセージは以下のようにフォーマットされる： １．デバイスID（１バイト）。これはイベントのソースを識別する。現在定義 されたデバイスは： ０：デコーダ−０ １：デコーダ−１ ２：光学的絶縁体 ２．イベントID（１バイト）。これはイベントのタイプを識別する。現在定義 されたタイプは： ０：セグメントの終わり。データはオーディオのセグメント番号である。 １：プレイされたマーカ＃１。データはオーディオのセグメント番号であ る。 ２：プレイされたマーカ＃２。データはオーディオのセグメント番号であ る。 ３：光学的絶縁体の変更。データは絶縁体の現在のセッティングである。 ３．データ値（３バイト）。データの内容はイベントに依存する。補助データ ユニット：補助データ、ユニット＃２ 引数：補助データはパケット化される。各パケットは、２バイトのヘッダを有し 、これにデータが続く。この２バイトのヘッダは： １．データが来たデコーダの番号。 ２．ヘッダに続くデータのバイト数。 レスポンス：なし コメント：光学的入力の読み取り ユニット：光入力、ユニット＃４ 引数：４ビットの低い順位の現在の光学的入力値（１バイト） レスポンス：なし コメント：このメッセージは、PCからの「読み取り光入力メッセージ」に応答し てDSPにより送られる。デコーダ状態の獲得 ユニット：デコーダ状態、ユニット＃５ 引数：３つの値： １：デコーダの状態：これは０：停止、１：プレイ、２：プレイ中のライ ブ。（１バイト） ２：プレイされるセグメント番号。状態が０（停止）又は２（プレイ中の ライブ）であれば、値が０に戻される。（１バイト） ３：フレーム番号は、プレイされているものである。デコーダが停止する と、戻る値は０である。（３バイト） レスポンス：なし コメント：このメッセージは、PCにより送られる「デコーダ状態の獲得メッセー ジ」に応答してDSPにより送られる。 演算要求 このセクションは、加入者端末により提供される演算機能について説明する。 本システムにより配信され、管理されるオーディオは、４つの異なるタイプがあ る。 １．地域スポットを含む記録されたショー ２．地域スポットを含むライブショー ３．地域スポットを含む遅延プレイショー ４．コマーシャルと他のオーディオ 加入者端末は、各タイプのオーディオの受入れ、準備、プレイ及びプレイの認 証を許可するフィーチャーを提供する。以下のセクションは、これらのオーディ オタイプとそれぞれの管理に対してシス テムが供給するフィーチャーを説明する。オーディオタイプの各々は、現在のと ころ無限に契約されているビジネスの商品を表す。このビジネスの詳細及び関連 する課題は、付録Ａに紹介されている。オーディオタイプの各タイプに提供され るフィーチャーを理解するキーは、プレイリストの構造を理解することである。 プレイリストは次のセクションで説明される。 プレイリスト及びイベント 加入者端末は、オーディオの個々の部分をプレイする能力があるが、これはめ ったに実行されない。オーディオの単純なプレイを生み出す単一のアプリケーシ ョンは、配信されたコマーシャルがカートテープにダビングされた時である。通 常、加入者端末はプレイリストの制御のもとでオーディオを連続してプレイする 。プレイリストはオーディオイベントの順番付けたシーケンスである。オーディ オイベントは、他のオーディオイベントが発生する前に完了するようにプレイす るオーディオのシーケンスである。ラジオはオーディオイベントの管理である。 各オーディオイベントは、潜在的なユーザに興味を持たせる５つの特性である： １．イベントのクラス（内部／外部） ２．開始トリガ ３．終了信号 ４．アウトキュー ５．イベント期間 これらのうち、最初の３つは、イベントのユーザにより特定されても良いが、 最後の２つは与えられたオーディオイベントに関連する本質的な特性である。 イベントクラス 〔MEx DAX-Affiliate〕端末は２つのイベントクラスを提供す る： １．内部。内部イベントは、〔DAX-Affiliate〕端末それ自身内に発生するも のである。これらは、例えば、〔DAX-Affiliate〕端末内に蓄積されたケーシー 、カッサムのトップ40ショーのセグメント、又はコマーシャルである。 ２．外部。外部イベントは、〔DAX-Affiliate〕端末の外部で発生されるもの である。これらは、例えば、カートマシン上にあるコマーシャル、その時間の最 初にニュースを読むライブアナウンサー、又はステーションコールレターサウン ダである。 開始トリガ プレイリスト上の各イベントは、イベントの開始をさせるトリガを有すると言 える。〔DAX-Affiliate〕端末は以下のトリガをサポートする： １．接触閉止。接触閉止によりトリガされるイベントは、〔DAX-Affiliate〕 端末で閉止が受信されたときにプレイを開始する。 ２．偽の接触閉止。これは、１つのプレイリストが他のプレイリストの実行を 開始させることを許可する内部ソフトウエア信号である。これは、第１に、ライ ブオーディオがプレイリストにストアされた他のオーディオイベントをカットで きるようにするために使用される。 ３．先行イベント終了(PET)。PETイベントトリガは、オーディオイベントを、 それに先行するイベントに直ちに従わせる。これは、中止又は外部入力なしに１ つのイベントから他への流れをもたらす。 異なるイベントトリガを有するプレイリスト中の多数のイベントを有すること は、豊かな演算フィーチャーセットをもたらす。例えば、接触閉止に続いて３つ のコマーシャルが連続してプレイバック されることを仮定する。このプレイリストは、オーディオイベント１（第１のコ マーシャル）が２つのイベントがPETトリガされる間に閉止トリガされるために セットアップされる。さらに、最初の２つのイベントは、第３が接触閉止の終了 を発生するように選択される間に、終了信号を発生させない。この結果は、閉止 がコマーシャルのプレイを開始させることであり、各コマーシャルが連続してプ レイをし、そして接触閉止はコマーシャルセットの完了を表示するため活性化さ れる。 終了信号 オーディオイベントが実行されるとき、オプションとして、完了信号を発生で きる。完了信号は以下にリストされた２つのタイプがある。いずれか又は両方の 終了信号は、いくつかの与えられたオーディオイベントのために特定される： １．接触閉止。これは、オーディオイベントが完了したときに、特定の接触を 閉じる結果となる。 ２．偽の接触閉止。これは、停止されたプレイリストの再開に使用できるソフ トウエア表示である。 ユーザレコードイベント MExフィーチャーリスト中に最初に提供されることが予定されていなかったと しても、加入局がそれ自身のオーディオイベントを記録できない理由はない。こ の能力を与えると、外部イベントであるものを内部イベントへ変換することが可 能となる。最終的な結果は、局をより自動化する。それは、外部局と相互作用な しに、最初から最後までショーをプレイさせることを可能とする。 プレイリスト 全てのリクエストされたMEx機能は適切に構成されたオーディオイベントのリ ストにより獲得される。このようなリストは、MExプ レイリストと呼ばれる。以下のセクションはプレイリスト管理の有利な点からME xシステムの種々の要求を説明する。プレイリストはDAX端末内のいくつかの異な る状態中に存在することができるということを注意されたい。これらの状態は： １．休止。休止リストは、生成されるが、現在どのオーディオ出力へも指定さ れていないリストである。このリストは聴取できるがプレイはされない。 ２．活動。活動プレイリストは、所定のオーディオ出力が指定されたリストで ある。いくつかの活動プレイリストがあり、そこでは、各活動プレイリストに対 する現在のオーディオイベントは異なるトリガを持たなければならない。 ３．プレイ。所定の出力オーディオポートに関連するただ１つの活動プレイリ ストは直ちにプレイされる。 地域スポットを含む記録されたショー 地域スポットを含む記録されたショーは、実際には、オーディオファイルの集 積であり、単一の活動プレイリストである。最初に、MExは、局地に有効なスポ ットに対して外部オーディオイベントをサポートするのみである。言い換えると 、局地コマーシャルは局のカートマシン上にある。MExは、以下のシーケンスを 使用して記録されたショーを配信する： １．ヘッドエンドシステムは、MExアドレス配信を使用して、指定された局に 地域コマーシャルを配信する。コマーシャルは、関連するショー中の位置のため に名付けられる。例えば、「トップ40スポット12」。 ２．ヘッドエンドシステムは、ショーイベントを配信する。各コンポーネント は、「トップ40セグメント15」のような特有の名前を有する。 ３．ヘッドエンドシステムは、プレイリストを配信する。プレイリストは、局 地に有効なスポットとともに、セグメントとコマーシャルを連続させる。 以下のものは、プレイリストの例である： イベント１ トップ40セグメント１ イベント２ トップ40スポット１ イベント３ トップ40スポット２ イベント４ ローカルスポット イベント５ トップ40セグメント２ イベント６ トップ40スポット３ イベント７ ローカルスポット イベント８ トップ40セグメント３ このシステムは、イベント１に接触閉止をトリガさせるためセットアップされ る。これはショーのプレイを開始する。イベント２とイベント３は、先行するイ ベントの終了でトリガされる。これは、イベント１からイベント２、イベント３ へと円滑に流れさせる。イベント３はその終了信号として接触閉止を有する。こ れは、局地スポットの開始を意味し、イベント４を開始させる局自動化システム へのインターフェースに使用される。イベント５は、イベント４により表示され る局地に有効なスポットの終りを表示する接触閉止をトリガする。DAX端末にダ ウンロードされる特定のファイルと共に、プレイリストは、その局に対するフォ ーマットされたシートを作成するために要求される全てのものである。加入局マ ネージャが試験又はプリントアウトできるフォーマットは、プレイリスト及びコ ンポーネントオーディオファイルから発展させることができる。各オーディオイ ベントがそれに関連する期間とアウトキューを有するわけではない。これは、（ 局地化されたコマーシャルからの異なる アウトキューにより）局地化が各局において異なるフォーマットの結果となった としても、各ショーのためのフォーマットの内部発生を許可する。

【手続補正書】 【提出日】平成１２年３月２１日（２０００．３．２１） 【補正内容】 明細書 オーディオファイル配信および生成システム アメリカ合衆国の国民であり、ニュージャージー州ホルムディル市の住人であ る私、Tim Chase(ティム チェイス)は、以下が明細書である、オーディオファ イル配信および生成システム、というある新規かつ有効な改良物を発明したこと は知られるべきである。 参照物として組み入れられる参照資料およびソフトウエア 本発明は1995年７月１日出願の仮特許出願第60／003,164号に基づく優先権を 主張をし、その全ての内容は前記’164号仮出願とともに出願されたソフトウエ ア付録および添付された論文を含んで参照物としてここに明確に組み入れられる 。 本発明の望ましい実施例を組み込むために使用されるソフトウエアは、以下の ようにラベル付けされた５−３ 1／2”デスケットの付録Ａ−Ｅ中に添付されて いる。本発明の望ましい実施例の加入者コントローラを組み込むために使用され るソフトウエアは、“DAXソース”と名付けられたソフトウエア付録Ａとして添 付されている。ディジタルオーディオカードに接続するために加入者コントロー ラによって使用されるソフトウエアは、“Driverソース”と名付けられたソフト ウエア付録Ｂ、および“DAC DSPソース”と名付けられたソフトウエア付録Ｃ中 に収録さられている。ディジタルオーディオカードの機能は、“DAC Driver設計 ”、“DAXオーディオサーバ設計”、“設計ノート”および“要求”と名付けら れた前記’164号仮出願に添付された論文中に記述されている。リモートコント ロール端末と加入者コントローラの間の協調を提供するソフトウエアは、“Jock Box端末ソースコード”と名付けられたソフトウエア付録Ｄ中に収録さられてい る。配信サブシステムを制御するために分配管理システムによって使用されるソ フトウエアは、“DMSソース”と名付けられたソフトウエア付録Ｅ中に収録さら れている。 望ましい実施例に関連して配信サブシステム中で使用されるマルチプレクサは 、仮出願第 ／ （弁理士書類10872US01）として1995年８月16日に、お よび仮出願第 ／ （弁理士書類10872US02）として1996年８月16日に出 願された“伝送帯域幅資源の動的割り付けのための方法および装置”と題する出 願人の係属中の出願に開示されているものであってよい。 上記で参照されたソフトウエア付録ＡからＥの全ては、上記で参照された論文 、仮出願および非仮出願とともに、明確にここにそのまま参照物として組み込ま れる。 発明の分野 本発明は、一般的には生（ライブ）および記録されたオーディオの配信に係わ り、特にディジタル化された生オーディオ、単一のオーディオファイルおよび／ またはオーディオファイルの組ならびにヘッドエンドトランスミッタから１また は複数のエンドユーザレシーバへの再生命令の配信を提供する一体化された配信 および再生システムに関連する。 発明の背景 全国的にシンジケート組織化されたラジオプログラムおよび全国的な広告キャ ンペーンは、ラジオ放送業の大部分を構成している。現状のこれらのプログラム の配信方法ならびに地方放送局およびその後の製作に対する広告は驚くほど扱い 難く非効率的である。 １つの共通の筋書きとして、全国的な放送局は、地方放送局に対してラジオプ ログラムを提供する。地方局はラジオプログラムを取得し、取得した代わりに全 国局には全国的な広告スポットのために使用できる付加的な放送時間を地方局か ら提供される。そして、全国的な放送局はコンパクトディスク、ディジタルオー ディオテープ等にラジオプログラムおよび全国的な広告を含む全ての番組を記録 する。記録された番組のコンパクトディスクまたはオーディオテープは種々の地 方局に、通常、夜通しの配信サービスによって物理的に配信される。記録された 番組はセグメントに分割され、各セグメント間には、地方局が地方広告、局識別 符号または地方ニュースのような地方スポットを放送することができる間隙（ギ ャップ）が存在する。地方局オペレータはいつこれらのギャップが発生し、どの くらい長く継続するかを知ることが必要であるため、全国的な放送局は印刷され た番組フォーマットを提供しなければならない。この番組フォーマットは、地方 局オペレータに全番組の継続する長さ、出口キューおよびセグメントギャップの 長さのような情報を提供する。 番組を放送するために、地方局オペレータは出口キューを聞いている間、予め 記録された番組を含むコンパクトディスクを再生する。地方局オペレータは出口 キューを聞くと、地方スポットの記録を含む再生装置の再生開始を押下するか、 または地方ニュース記者に発言を開始するための合図を与える。セグメントギャ ップが終わったとき、地方スポットは終了時間と定められる。 種々の課題が、そのような番組配信の方法を使用している全国的な放送局に対 して惹起される。各地方局のためのコンパクトディスクの製造および録音は高価 であり、ディスクは通常一回だけ使用され、そして破壊されるので、この処理は 不経済である。コンパクトディスクの準備およびそれに引き続く配送は１週間ほ ど必要とする。この時間遅れは、最新の番組の配信を妨げることになる。録音さ れたものは物理的に各地方局に送付されなければならないので、運送価格は高く なる。もし全国的な広告者がある広告によって国内のある１地域だけを目標にし たいと望んだときは、異なった録音がなされ、その地方の局に送付されねばなら ない。 地方ラジオ局において、予め録音された番組の非柔軟性および印刷された番組 フォーマットおよび聞き取り可能なキューに基づく放送中の地方スポットの実時 間継ぎ重ねによって課題が引き起こされる。これらの課題は不経済な無駄な放送 時間、聴覚的な不快、全国および地方のセグメント間の突然の変更を発生させる 。 発明の目的 先行技術における課題および種々の制限を克服するために、開示された発明は 、１または複数の下記の特徴または目的を達成するための種々の実施例を有する 。 本発明の目的は、高品質のライブ（生）オーディオ、単一のオーディオファイ ルおよび複数のオーディオファイルの配信および引き続く再生のための一体化さ れたシステムを提供することである。 本発明のさらなる目的は、生オーディオ、単一のオーディオファイルおよび複 数のオーディオファイルを選択されたエンドユーザまたは例えば地理的地域に基 づく複数のエンドユーザに選択的に配信するためのシステムを提供する。 本発明の他のさらなる目的は、オーディオ品質の重大な損失なしに生オーディ オ、単一のオーディオファイルおよび複数のオーディオファイルの価格的に効率 のよい伝送ができるオーディオ信号のデータ圧縮を達成することである。 本発明の他のさらなる目的は、配信センタにいるユーザが遠隔の再生装置によ って再生される複数のオーディオファイルの順序を制御することができる一体化 されたオーディオ配信再生システムを提供することである。 本発明の他のさらなる目的は、ヘッドエンドのユーザが地方ラジオ局で放送す るための完全な番組を製作することができる一体化されたオーディオ配信再生シ ステムを提供することである。 本発明の他のさらなる目的は、地方オーディオセグメントがオーディオセグメ ントの全国配信者によって製作される番組中に組み込まれることを許容する一体 化されたオーディオ配信再生システムを提供することである。 本発明の他のさらなる目的は、聴覚的な快感および１つのオーディオファイル またはセグメントから他のオーディオファイルまたはセグメントへの円滑な移行 を生成する再生システムを提供することである。 本発明の他のさらなる目的は、製造者によって経済的であり、既存の装置と交 換可能であるシステム要素を提供することである。 本発明の他のさらなる目的は、容易かつ柔軟なプログラム可能性を具備するユ ーザの使い易いシステムを提供することである。 発明の要約 本発明の望ましい実施例は、ヘッドエンドにおいて、地域情報通信網、ISDN接 続等を介して配信サブシステムと交信する生成サブシステムを有するオーディオ 配信システムを含んでいる。この配信サブシステムは、衛星接続、ISDN接続等を 介して末端（テールエンド）において加入者サブシステムと交信する。生成サブ システムは、他のオーディオイベントが発生する前に完全に再生されるオーディ オシーケンスを表すオーディオイベントを、プロデューサが製作することを可能 とする。オーディオイベントは、オーディオファイルとして記憶される。各オー ディオイベントは、１またはそれ以上のオーディオシーケンス、テキスト情報、 配信命令およびコンタクトクロージャ(contact closure)情報等を有する加入者 リストを含んでいるかもしれない。付加的に、多重オーディオイベントは、再生 リストを形成するために生成サブシステムにおいて集められるかもしれない。オ ーディオファイルは配信サブシステムに転送される。配信サブシステムは、オー ディオファイルを配信エンベロープ中に置き、このエンベロープを加入者端末に 転送する。さらに、配信サブシステムは、生オーディオおよび関連するコンタク トクロージャ情報を加入者端末に転送するかもしれない。加入者端末は、ユーザ 側に配置されるかもしれない。加入者端末は、これらのイベントをハードドライ ブに記憶し、実時間でイベントを再生し、イベントを他の加入者端末に送るかも しれない。加入者端末は、後刻、記憶されたオーディオイベントを再生するかも しれない。 望ましい実施例のオーディオ配信システムは、少なくとも７つの基本的なサー ビスを提供する。オーディオ配信システムは、交通情報、フォーマティック、入 口キュー(incues)等のような各ファイルに関する補助的な情報とともにオーディ オファイルがシステム内に導入されることを可能とする。さらに、オーディオ配 信システムは、オーディオイベントの束ねおよび１塊の配信パッケージ中に番組 表のような文書のサポートを可能とする。束ねられたオーディオイベントおよび 文書は、単一のパッケージまたはエンベロープとして所定の加入者端末に転送さ れる。各パッケージは、特定の加入者端末、および／または複数の加入者端末宛 に個別に宛名が書かれる。この宛名が書かれた情報は、配信命令として参照され る。このオーディオ配信システムは、さらに、パッケージが適切に配信されるこ とを確かめるための完全性検査(integrity check)をサポートしている。 図面の簡単な説明 図１は、本発明の望ましい実施例に係るオーディオ配信システムのブロック線 図を一般的に示す。 図２は、本発明の望ましい実施例において使用される生成サブシステムのブロ ック線図を一般的に示す。 図３は、本発明の望ましい実施例において使用される配信サブシステムのブロ ック線図を一般的に示す。 図４は、本発明の望ましい実施例に関連して使用される加入者端末を一般的に 示す。 図５は、本発明の望ましい実施例に関連して使用される遠隔加入者遠隔コント ロール端末の斜視図を示す。 図６は、本発明の望ましい実施例に関連して使用されるディジタルオーディオ カードのブロック線図を示す。 図７は、本発明の望ましい実施例において使用されるディジタルオーディオカ ードに関連して使用されるプロセッサの機能的表現のブロック線図を示す。 図８は、本発明の望ましい実施例に関連して使用されるディジタルオーディオ カードに関連して操作したときの、加入者コントローラの機能的ブロック線図を 示す。 図９は、オーディオファイル、カートファイルおよび番組表ファイルフォーマ ットのブロック線図を示す。 図10Ａおよび10Ｂは、再生操作のためにディジタルオーディオカードおよび加 入者端末によって実行される処理順序のフローチャートを示す。 図11は、本発明の望ましい実施例に係る加入者端末に記憶されていない地方的 なセグメントの再生によって実行される２つの記憶されたセグメント間の典型的 なクロスフェード(cross fade)操作を示す。 図12は、本発明のファイル配信システムの代案の実施例を示す。 好適な実施例の詳細な説明 定義 最初に、共通的に用いられる用語について、定義のリストが提供される。 オーディオプログラム―プレイリスト上でグループ化され少なくとも１つの提携 の端末へ供給される１つまたはそれより多い音声の区分（セグメント）。例 示としては、オーディオプログラムはハワード スターン ショウ、ケーシ ー カッシムズトップ 40（Casey Cassims Top 40）、等がある。 オーディオセグメント―規定された始点と終点をもつ音声信号の連続的系列を包 含する音声の事象（イベント）。オーディオイベントは、他の１つの事象（ 音声または命令）が発生する前に、開始から終了まで、提携の端末によりプ レイされる。例示としては、オーディオイベントは音響のバイト、歌唱、歌 唱の一部、コマーシャルの間のシンジケートにされたショウ、１つのコマー シャル等を表すことが可能である。 オーディションオーディオ―オーディオプログラムの内容をあらわす短かい音声 の系列。例えば、オーディションオーディオ信号は歌唱の最初の数秒をあら わすことが可能であり、加入者の端末の使用者に対しプレイされ使用者に関 連するオーディオセグメントまたはオーディオプログラムが通知されように することが可能である。 カート機械―加入者の端末におけるオーディオのプレイバックの装置であって、 例えばテープからのようなローカルのオーディオセグメントをプレイするこ とに用いられる。カート機械は、コマーシャルおよびニューススポットを記 録しプレイバックするためにしばしば用いられる。 カートファイル―オーディオファイルに固有に関係するファイル。カートファイ ルは、オーディオファイルの名前、オーディオファイルへの開始および終末 のオフセット、マーカの属性、開始の合図（インキュー）終末の合図（アウ トキュー）消滅の日付、および最初の使用の日付を包含する。 コンタクトクロージャ(contact closure)の命令―加入者の端末に接点の開路ま たは閉路を命令する指示であって、例えばカート機械をオンにし、またはオ フにするもの。 データパケット―個別のユニットとしてマルチプレクサを通過するデータのセグ メントであって、変調および伝送に先立ってヘッダ情報が付加されるも の。例示としては、オーディオセグメントおよびオーディオプログラムはマ ルチプレクサによりデータパケットへ更に分割され加入者の端末へ時分割多 重の態様で伝送されることが可能である。 消滅の日付―加入者の端末が、加入者の端末の記憶装置からオーディオセグメン トおよび／またはオーディオプログラムを自動的に抹消する、予め付与され る日付。 配信の指示―配信の期間に、どの加入者の端末が各データファイルを受理すべき かを、配信サブシステムへ通知する指示。 フォーマテイックス―放送ショウの代表となる可能性のあるオーディオプログラ ムの形式または配置。例えば、該形式は、オーディオプログラム内の場所で あって、ローカルの加入者の局がローカルのコマーシャルスポットを挿入す る可能性のあるもの、を識別することが可能である。さらに、該形式または 配置は、移り変わるセグメント用のインキューおよびアウトキューおよびオ ーディオセグメントのプレイの時間を包含することが可能である。 帯域はずれの制御―マルチプレクサの内部通信として加入者の端末へ指示される ことが可能な制御命令であって、例えば、単一のメッセージが伝送されつつ あるチャンネルを識別する情報である。 プレイバックの表―特定のオーディオプログラムと関連する概要または業務記録 であって、関連するオーディオプログラム内の各オーディオセグメント／ク リップ／イベントを独特に識別する情報を包含するもの。 オーディオファイル―内部構造をもたない記録された音声。オーディオファイル は、個別のコマーシャルまたは短いまたは長い形式のプログラムセグメント をあらわすことが可能である。 ライブオーディオ―放送されるショウ（番組）であって、加入者の端末において 番組を記録することなく受信されるもの。ライブオーディオは、補助的なデ ータの流れ内に埋込まれた同期化命令を含むことが可能である。同期化命令 は、加入者の機能、例えば加入者の端末においてカード機械によりコマーシ ャルの再プレイの開始を作動開始させることに用いられることが可能である 。 遅延プレイのオーディオ―ディスクに記録されるが大抵直ちに（例えば５ないし 10分以内）再プレイされるショウ。該ショウは、受信されるとともに記録さ れるが、ディスク空間はショウがプレイされている間は、解放されている。 システムの概観 第１図は本発明の好適な実施例によるオーディオ配信システム10のブロック線 図を示す。オーディオ配信システム10は少なくとも１つの生成サブシステム12、 少なくとも１つの配信サブシステム14、および少なくとも１つの加入者の端末16 を含む。第１図に示されるように、各生成サブシステム12は、デジタルデータの 伝送を支持する任意の従来形の媒体を通って１つまたはそれより多い配信サブシ ステム14と通信することが可能である。例示としては、生成サブシステム12と配 信サブシステム14の間の相互接続（ライン13で示される）は、ローカルエリアの 回路網、ISDNの連系（リンク）、従来形の電話連系、衛星連系、等であることが 可能である。さらなる選択肢として、各配信サブシステム14は１つまたはそれよ り多い生成サブシステム12と通信することが可能である。 各生成サブシステム12は、使用者がデータファイルを制作することを可能にし 、該データファイルは、一般的には、オーディオイベント／セグメント／クリッ プ、オーディオファイル、カートファイル、プレイバックのリストファイル、文 書のファイル、映像のファイル、および配信指示のファイル（定義の項において 定義されるような）と称される。配信サブシステムおよび生成サブシステムは機 能的に別個のユニットとして第２図に示されるが、両方のサブシステムは、共通 の場所（および共通のシステム）において実現され、接続13の必要性を回避する ようにされることが可能である。 配信サブシステム14は、リンク13を通して配信サブシステム14から、オーディ オセグメントとオーディオプログラムを包含するオーディオファイルとオーディ オファイルの系列を受信する。さらに、配信サブシステムはリンク15を通して生 のオーディオ信号を受信する。配信サブシステム14はリンク15を通して接点閉路 （コンタクトクロージャ）命令をも受信することが可能である。配信サブシステ ム14は、リンク13およびリンク15上で受信する信号を組合わせ、該組合わせをリ ンク17を通して加入者の端末16へ出力する。リンク17は衛星リンク、ISDNリンク 、等であることが可能である。選択肢として、配信サブシステムは、リンク17ま たはリンク19を通して加入者の端末から情報を受信することが可能である。 選択肢として、配信サブシステム14は、データファイル（例えば、オーディオ ファイル、カートファイル、命令、プレイリストのファイル、文書のファイル、 映像のファイル、等）を単一の「エンベロープ」内へ集合させることが可能であ る。この「エンベロープ」は、宛先の加入者の端末に関するアドレス情報を包含 することが可能である。配信サブシステムはオーディオファイルの外向けのエン ベロープを、アドレス情報にもとづいて個々の加入者の端末へ指向する。選択肢 として、アドレス情報は、加入者の端末の１つのグループをエンベロープ用の宛 先として指定することが可能である（例えば、シンジケートの番組用の米国中西 部のラジオ放送局）。 加入者の端末16は配信サブシステム14から到来するエンベロープを受信し、該 エンベロープを希望される態様で処理する。選択肢として、加入者の端末16は、 リンク19を通して配信サブシステム14へ、いつ加入者の端末16が期待したオーデ ィオファイルを受信しなかったかを通知する。加入者の端末16は、到来するオー ディオファイルをハードディスクに記憶させ、エンベロープとともに受信した指 示（例えば、プレイバックのリスト）にもとづいて、または加入者の端末におけ るオペレータからの指示にもとづいて、これらのオーディオファイルを、後に、 再プレイすることが可能である。その代りに、加入者の端末16は、例えば生のプ ログラム（例えば、ニュース）の放送の期間に、到来するオーディオデータを受 信し再プレイすることが可能である。さらにその代りに、加入者の端末16は、再 プレイの期間に、ローカルのプログラム（ローカルのカート機械上のテープによ りプレイされるもの）と配信システム14から受信するオーディオプログラム（ハ ードウェアの駆動装置に記憶されているもの）を挿入編成することが可能である 。加入者の端末16は、１つのオーディオセグメントの終末部分と次位のオーディ オセグメントの開始部分を混合するとき、自動化された交差状のフェーディング の操作を利用することが可能である。 加入者端末16は、リンク19を通してアナログの音声信号を出力し、ラジオ放送 局から放送されるようにする。ライン21および23は、外方へ向かう接点閉路の命 令を支持し、該命令は例えば加入者の端末16からカート機械へ送出されるもので ある。ライン23は検出器入力信号を受信し、該信号は加入者端末へカート機械等 の現在状態を通知するものである。加入者端末16は、ライン25を通して加入者端 末における使用者へオーディションオーディオ信号を出力する。 データのフォーマット 第９図は一般的に本発明の好適な実施例に接続されて使用される例示的なデー タの形式（フォーマット）を示す。本発明がオーディオデータの生成および伝送 に限定されないことは理解されるべきであるが、説明の便宜のために、オーディ オプログラムが生成され伝送されることが仮定される。第11図は、プレイリスト のファイル400を示し、該ファイルは、オーディオセグメントのプログラムを規 定する。プレイリストのファイルにおけるオーディオセグメントは、１つのアウ トラインのフォーマットにおいて使用者に対し表示されることが可能である。プ レイリストのファイル400は、プレイされるべき各オーディオセグメントを識別 するファイル名称（例えば、404、420、および436）のプレイバックのリスト402 を包含することが可能である。ファイル名称404、420、および436は、ファイル の名称およびカートファイル406、422、および438への指令の通路をそれぞれあ らわす。各カートファイル406、422、および436は、オーディオセグメント414、 432、および434をそれぞれ独特に識別する。各カートファイル406、422、および 438は、対応するオーディオセグメントを包含するオーディオファイル415および 430への通路の名称408、424、および440をそれぞれ包含する。オーディオファイ ル430は、カートファイル422および438用のオーディオセグメント432および434 を包含する。 各カートファイル(406、422、および438)はまた、開始の(410、426、および44 2)および終末の(412、428、および444)データフレーム番号を対応するオーディ オファイルのなかへ包含させる。開始のおよび終末のデータフレーム番号は、対 応するオーディオセグメントの開始および終末の点を識別する。各カートファイ ルはまた、対応するオーディオセグメント用の属性、例えば、マーカ（後述され るようなDACの事象を開始させることに用いられる）、インキュー、ア ウトキュー（使用者にいつ区分が終了するかを通知する）、文書の記述（音声の 区分を記述するコメント）、消滅の日付（加入者端末がオーディオファイルを自 動的に抹消する日付）、および最初の使用の日付（加入者端末がオーディオセグ メントへのアクスセスを最初に許容される日付）、を包含することが可能である 。 操作の期間において、文書、アウトキュー、コメント等は、オーディオファイ ル、カートファイル、およびプレイリストのファイルから取得され使用者に対し 表示されることが可能である。この表示は、プレイバックのリストの表示を包含 することが可能であり、該プレイバックのリストの表示は、オーディオセグメン トの標題およびそれにともなうローカルのスポットの中断およびセグメントプレ イの時間の表示によるものである。 生成サブシステム 第２図は生成サブシステム12をより詳細に図解する。生成サブシステム12は、 生成プロセッサ24を包含し、該生成プロセッサは配信命令の入力ユニット32、ト ラフィックおよびフォーマテイックスの入力ユニット28、音声入力のユニット26 、および接点閉路入力のユニット30と通信する。配信サブシステムはハード駆動 装置35を包含し、該ハード駆動装置は、配信サブシステム14への伝送に先立って オーディオセグメントおよびオーディオプログラムと関連するオーディオファイ ルを記憶するためのものである。オーディオおよび接点閉路の入力26および30は 、オーディオおよび接点情報の信号をCODEC31へ供給するが、該CODECは例えば、 Holmdel、New JerseyのCorporate Computer Systems、Inc.から商業的に利用可 能なCDQプリマ符号化／復号化装置である。CODEC31は、幾つかの従来形の「ロッ シイ形」の符号化アルゴリズムにもとづいて到来するオーディオ信号を符号化す ることが可能であり、該ロッシイ形符号化アルゴリズムは例えば、Corporate Co mputer Systems、Inc.から商業的に利用可能なMUSICAMアルゴリズムである。選 択肢として、CODEC31には他の符号化アルゴリズムが使用されることが可能であ る。 CODEC31はさらに、入力30から接点閉路の指示を受理し、この接点閉路の指示 を出力の符号化オーディオ信号へと統合する。CODEC31の出力はデジタルオーデ ィオカード(DAC)31に供給され、該デジタルオーディオカードは後述のデジタル オーディオカードの項においてより詳細に説明される。DAC33は、符号化された オーディオデータおよび接点閉路のデータを配信サブシステム12のプロセッサへ リレーするが、これは配信命令およびトラフイック／フォーマテイックスの情報 が生成され付加される期間における一時的記憶のためのものである。DAC33はCOD EC31からの出力信号を復号し該復号されたオーディオ信号を使用者に対しプレイ することが可能であり、それにより使用者が現行の圧縮パラメータの組に従い、 一旦符号化されそして復号された結果としてのオーディオ信号を聴取することが 可能になる。 選択肢として、制作者は、CODEC31からの符号化された音声の信号を記録する ことなく、DAC33の復号された出力を当初に聴取することが可能であり、この聴 取は、例えば、CODEC31の現行のパラメータ設定を変更する必要があるか否かを 決定するためのものである。CODEC31のパラメータがひとたび生成者に満足され るよう設定されると、該生成者は記録の選択肢を選択することが可能である。そ れに応答して生成プロセッサ24とDAC33は、協力してCODEC31からの符号化オーデ ィオ出力の信号を配信サブシステム12のハード駆動装置に記録する。さらなる選 択肢として、記録の期間において、DAC33はプレイバックの操作をオフにするよ う切換えられることが可能である。 さらにその代りに、DAC33はCODEC31からの新しく到来する符号化オーディオ信 号をプロセッサ34へ進行させハード駆動装置に記憶させ、それとともに配信サブ システム12のハード駆動装置からの以前に符号化されたオーディオ信号を同時に 読取ることが可能である。DAC33は、新しいオーディオプログラムがCODEC31によ り符号化されハード駆動装置に記憶される間に、以前に記憶されたオーディオプ ログラムを制作者に対し復号することが可能である。この態様で、好適な実施例 の配信サブシステムは、第１および第２の音声のプログラムの同時の記録および 編集の操作を指示する。 選択肢として、プロセッサ24は、配信命令およびトラフイックおよびフォーマ テイックスを、データベース35に記憶されるときに、オーディオセグメントおよ びオーディオの記録に付与することが可能である。オーディオセグメントまたは プログラムがひとたび完了すると、制作者は、オーディオセグメントまたはプロ グラムをリンク13を通して配信サブプログラムへ伝送することを、プロセッサ24 に指示する。 単に例示としてのみであるが、生成サブシステム12は、全国的な放送事業者用 のコマーシャルを制作する広告代理業者内に位置することが可能である。この手 法を用いて、広告代理業者は制作の機能を実行することが可能であり、結果とし てのオーディオプログラムは、全国的な放送事業者のさらなる介入なしに、ISDN リンク等を通して配信サブシステム14へ直接に送付される。 単に例示としてのみであるが、オーディオ入力26はデジタルオーディオテープ のプレーヤ、コンパクトディスクのプレーヤ等をあらわすことが可能である。こ のシステムはまた、直接的デジタル入力例えばAES／EBUを支持することが可能で ある、トラフイックの入力は、単純なプレイの指示、またはインキュー、アウト キュー等を包含するオーディオプログラムの複雑な形態を入力するためのキイボ ードを構成することが可能である。接点の閉路は、後述されるようにカート機械 等を始動し停止するために用いられることが可能である。配信命令の入力32は、 プログラマが、オーディオプログラムを希望される加入者端末または端末のグル ープへ供給するに必要なすべての情報を入力することを可能にする。配信命令は 、意図される加入者端末の名称、加入者端末のグループ、送出者の名前、該当す る経理の情報、終了のデータ等を包含することが可能である。 単に例示としてのみであるが、生成サブシステムは、PACEシステムを包含する ことが可能であり、該PACEシステムはNew Jerseyから商業的に利用可能であった が、現在はCBSにより使用されている。 配信サブシステム 図３は一般に配信サブシステムをより詳細に描いたものである。配信サブシス テム14は、生成サブシステム16からオーディオファイル、カートファイル(cart file）、プレイリストファイル、コマンドファイル、テキストファイル、ビデオ ファイルなどのような、データファイルを受ける分配管理システム34(DMS)を有 しているDMS34はライン42により加入者端末から状態レポート、請求書レポート （billing report）、データファイルの配信確認などのような通信を受けること ができる。任意に、DMS34は生成サブシステムから配信命令を受けることができ る。配信サブシステム14は入ってくるデータファイルを集め、そしてこれらのデ ータファイルを、共通にアドレスされたデータファイル、宛て先加入者及び／又 はハブ端末のためのアドレス情報、加入者及び／又は端末の宛て先グループのた めのアドレス情報、エンベロープの最新の配信時間に関する優先配信情報、すで にエンベロープを受けた各加入者／ハブ端末を識別する配送経路リストなどを含 む「エンベロープ」に集めることができる。 DMS34はデータライン34ａによりマルチプレクサ22にエンベロープを転送する 。マルチプレクサ22は伝送のため、１つ又はそれ以上のチャンネルによってエン ベロープをレコードに分割することができる。任意に、DMSはタイムスロットコ ントロールライン34ｂを経てマルチプレクサ22の動作を制御できる。DMS34は、 加入者及び／又はハブ端末のためを意図して、バンドコントロールライン34ｃの 外側でマルチプレクサ22にコマンドを転送することができる。 代わりに、マルチプレクサ22は別個のプロセッサにより制御することができる 。その場合、DMS34はデータ出力ライン34ａを通って単独でマルチプレクサ22と 結合する。バンドコントロールライン34ｃ及びタイムスロット割当ライン34ｂの 外側は、マルチプレクサ22を制御する別個のプロセッサにより駆動される。 さらなる選択として、生成サブシステム12は直接配信サブシステム14のアドレ ッシングを制御することができる。その場合、DMS34は、アドレッシング情報な しに、そしてデータファイルを「エンベロープ」にグループ化することなしに、 マルチプレクサ22にデータファイルを転送する。 配信サブシステム14は、ライン40によりライブのアナログオーディオ信号を受 け、そして幾つかの既知の符号化アルゴリズムの１つに基づいてこれを符号化す るため、少なくとも１つのCODEC18を含めることができる。DMS34は、コントロー ルライン34ｄを経てCODEC18の動作を制御する。マルチプレクサ22はCODEC18から ディジタル的に符号化されたオーディオ信号を受ける。マルチプレクサ22は、変 調器44に１つ又はそれ以上の伝送チャンネルによって入ってくるデータを転送す るため、上記参照した共通ペンディングアプリケーション（参照に組み入れ られた）において設定されたように動作する。変調器44はマルチプレクサ22から 受けた信号を衛星に伝送する。 前述のように、配信サブシステム14は、オーディオファイル、カートファイル 、プレイリストファイル、コマンドファイル、テキストファイル、ビデオファイ ル、及び生成サブシステムからの分配情報を有するデータファイルを集める。配 信サブシステム14はさらに、CODEC18を介して、コンタクトクロージャ情報のよ うなライブオーディオ信号及びANCデータを受ける。データは望ましい媒体を介 して加入者及び／又はハブ端末に伝送される。好ましい実施形態においては、配 信サブシステムは加入者端末にデータを伝送するため、衛星コネクションを利用 しているが、本発明はそれに限定されない。代わりに、配信サブシステム14は、 個々のアプリケーションにより要求された伝送レートでディジタル的に符号化さ れたデータの伝送を支持する媒体に沿ってデータを伝送することができる。例え ば、配信サブシステム14は、ISDNラインなどによってディジタル的に符号化され たデータを伝送することができる。低伝送レートが受け入れられる時、配信サブ システム14はディジタルデータを伝送するため従来の電話線を利用することがで きる。 加入者端末 図４は、加入者端末16をより詳細に描いたものである。加入者端末16は受信局 又はエンドユーザに配置できる。加入者端末16は、配信サブシステム14から衛星 20を経て入ってくるライブデータラケット(live data rackets)、データファイ ル及びエンベロープを受けるためにアンテナ51を有している。任意に、アンテナ 51は、オーディオプログラムが受信された又は受信されなかったという配信情報 のような戻り情報を伝送することができる。入力情報はRFデコーダ53において復 調され、デマルチプレクサ50に転送される。デマルチプレクサ50は配信サブシス テム14のマルチプレクサ22と両立するように構成される。デマルチプレクサ50は 、少なくとも１つのエンベロープで再組立するため、１つ又はそれ以上のチャン ネルから入ってくるデータレコードを分離(demultiplex)する。デマルチプレク ス50は、ライン66よりのバンドコマンドからの出力を分離することができる。任 意に、デコーダ53は、符号化されているが、しかし、オーディオファイル（上記 の）にフォーマットされていないリアルタイムのライブオーディオデータを受け るために制御することができる。符号化されたオーディオデータは、データフレ ームのデータポケットの連続したデータの流れとして受けられる。デマルチプレ クサ53がライブオーディオデータの流れを受けるように構成されているとき、DA C52はデータの流れを受けるために「ライブモード」に設定される。この様にラ イブオーディオデータの符号化されたデータの流れは復号され、リアルタイムに プレイバックされる。 加入者端末はさらに、オーディオファイル、カートファイル、プレイリストフ ァイル、テキストファイル、ビデオファイル、及びデマルチプレクサ50からのコ マンドのようなデータファイルを受ける加入者コントローラ46を有している。加 入者コントローラ46は、マイクロソフトのウインドウ95のような従来のオペレー ションシステムを動かすパーソナルコンピュータに相当する。加入者コントロー ラ46は、メモリ48に入ってくるデータを蓄えることができる。加入者コントロー ラ46は、以下により詳細に説明される少なくとも１つのディジタルオーディオカ ード(DAC)を有する。 加入者端末16は、局による放送のためのアナログ出力ライン56又はAES／EBUラ インを経たディジタル出力ラインの少なくとも１つにオーディオ信号を出力する 。加入者端末16は、加入者がメモリ48に格納されたオーディオセグメント又はオ ーディオプログラムの少なくとも一部を聞くことを可能にする、DAC52からの聴 取オーディオ出力ライン58を含めることができる。リモートコントロール端末54 は、加入者コントローラ46により実行される機能の少なくとも１つのサブセット に加入者リモートコントロールを与えるために設けられる。例として、リモート コントロール端末54及び聴取オーディオヘッドホーン59は、DJが試聴し、聴取し 、メモリ48に格納されたオーディオセグメント又はプログラムのプレイをコント ロールすることを可能にするため、ラジオ局のDJのブースに位置することができ る。リモートコントロール端末54は、加入者コントローラ46がDJのブースから離 れて位置しても、DJのブース内からメモリ48に格納された望ましいオーディオセ グメント及びプログラムを選択することを可能にする。 ライン60と62はコンタクト出力コントロールライン及びセンサ入力ラインにそ れぞれ相当し、DAC52により駆動されそして検出される。センサ入力ライン62は 任意に入力ラインを分離することができる。DAC52はコンタクト出力ライン60に コンタクトオープン及びクローズ信号を出力する。DAC52はリモート装置の状態 （即ち、オープン又はクローズ）の変化を検出するため、センサ入力ライン62を モニタする。リモート装置はカート機械（マシン）、リモートコントロール端末 などに相当させることができる。例として、センサ入力62は、カートマシンがロ ーカルプログラムのプレイを完成させる時、DAC52に伝えるためにカートマシン をモニタしてもよい。 ユーザインタフェース57は、加人者コントローラ46をコントロールするために 設けられる。例として、ユーザインタフェース57はキーボード、マウス及びディ スプレイを設けてもよい。一方、加入者コントローラ46は、アイコンがオーディ オセグメント及び／又はプログラム、及び機能（例えば、レコード、プレイ、フ ェード、停止など）を表すことができるウインドウ環境において動作する。ユー ザは関連アイコンをクリックし、ドラッグし、ドロッピングすることによりオー ディオセグメント又はプログラムに望みの機能を実行できる。 ディジタルオーディオカード 図６は本発明の好ましい実施形態と関連して利用されるディジタルオーディオ カード(DAC)52を描いたものである。DAC52は、加入者端末16のマザーボードと接 続するため相互接続ポート102を持ったプリント回路ボードに設けられる。DACは 、以下に説明するように動作するディジタル信号プロセッサ（DSP）104を備える ことができる。好ましい実施形態はDSPを用いているが、Intel、Motorola、CYRI X、AMDなどから商業的に利用可能な専用チップ又は一般目的のマイクロプロセッ サで行うことができる。メモリ106はディジタル信号プロセッサ（DSP）104の動 作を制御するコマンドソフトウエアを格納する。DSP104は入って来るデータファ イルを受け、ライン108(図４のデマルチプレクサ50からのライン64と66)に指令 する。DSP104はライン110に沿って復号化されたオーディオ信号を出力する。DSP 104は、「マーカー」がセグメントのプレイの間に生じた時（マーカーは以下に 説明する）、加入者コントローラ46に伝える。もしマーカーがコンタクトクロー ジャ命令に応答するなら、加入者コントローラ46はライン112に沿って リレー出力信号（例えば、コンタクトクロージャ信号）をセットするため、DSP1 04に指示する。DSP104はセンサ入力114に沿ってセンサ状態情報を受け、このセ ンサの情報を加入者コントローラ46に供給する。DSP104はライン116に沿って加 入者コントローラ46と通信する。 次に、DAC52においてDSPにより実行される動作を表す機能的図式を描いた図７ に移る。DSP104の機能は、オーディオファイル、カートファイル、プレイリスト ファイル、コマンドファイル、ライブデータフレームなどを含んだ、ライン108 に沿って入力するエンベロープ、データファイル、及びフレームを受けるデータ スイッチング動作120を有する。データスイッチ120は、特定のDACカード52にア ドレスされたエンベロープ、データファイル、及びフレームのみを受け入れる。 データスイッチ120は特定のDACカード52にアドレスされない入力情報を無視する 。データスイッチ120は、エンベロープとデータファイルをライン128に出力し、 ライブデータフレームを１つ又はそれ以上のライン124及び126に出力する。デー タスイッチ120はカードコントローラ122により制御される。ライン128を転送さ れたエンベロープとデータファイルは、DACドライバー132を通ってライン134に より加入者コントローラ46（図４）に伝送する前に、データバッファ130に一時 的に蓄積される。DACドライバ132は、ライン134、136、138、140及び142によっ てDSP104と通信する。DACドライバ132は、図８と関連して説明される加入者コン トローラ46と通信する。DACドライバ132は、アプリケーションと共にDAC52と接 続している低レベルハードドライブインタフェースに相当しており、アプリケー ションに依存して省かれ又は変更される。 データスイッチ120は、ライブの符号化したオーディオデータの流れをライン1 24と126によりフレームバッファ146と148に配信する。ライブプレイモードの間 、フレームバッファ146と148の１つは符号化された入力オーディオデータを一時 的に格納し、一方、個々のデータフレームをライン150ａと152ａによりデコーダ 150と152に出力する（ファースト−イン ファースト−アウト態様）。デコーダ は次にオーディオデータのデータフレームを復号し、復号化されたオーディオデ ータをライン154と156によりミキサ158に出力する。ミキサ158はライン154と156 のディジタルオーディオデータを組み合わせ、ライン159に合 成されたオーディオ信号を出力する。データフレームは符号化されたディジタル オーディオデータの予め決められた分離された量に対応する。例えば、エンコー ダはディジタル化されたオーディオ情報の24ミリ秒間隔で符号化を実行できる。 ディジタル化されたオーディオデータの24ミリ秒分離した区分は、符号化された データフレームとしてエンコーダにより出力される。データの多重フレームは、 オーディオの流れを形成するため組み合わせられる。 以下に説明するように、カードコントローラ122は、メモリ48に格納されたオ ーディオファイルからデータフレームのセットをライン15Oｂと152ｂによりデコ ーダ150と152に供給する。 デコーダ150と152ににより復号されたデータフレームはANCデータを含むこと ができ、その場合、デコーダ150と152はANCデータをライン160と162でANCデータ バッファ164に出力する。データバッファ164は、加入者コントローラ46にDACド ライバを通ってライン140により出力するまで、一時的にANCデータを格納する。 DACイベントバッファ DACイベントバッファ166は、加入者コントローラ46に関連するメッセージを格 納する。例として、DACイベントバッファ166は、オーディオセグメントが終了し た時を表示し、イベント番号によりセグメントを識別するメッセージを格納する ことができる。任意に、イベントバッファは、オーディオセグメントのプレイバ ックの間にマーカーが生じた時を表示するメッセージを格納することができる。 マーカーは生成サブシステムにより予め割り当てられたフラッグに対応させるこ とができる。マーカーを含むオーディオセグメントがプレイされる時、プレイバ ックの間のマーカーの検出により、DSPはイベントバッファにマーカーが生じた ことを表示するメッセージを格納する。マーカーはコンタクトクロージャをオン 、オフするために用いることができる。このように、マーカーは、オーディオプ ログラムにマーカーを導入することによりローカルカートマシンを自動的に制御 するために加えられる。プログラムのプレイの間、マーカーが検出された時、加 入者コントローラ46はマーカーを伝えられ、そして加入者コントローラ46は対応 するコンタクトクロージャー信号を出力する。例として、マーカー＃１は加 入者コントローラ46にコンタクトを閉じるよう指示することができ、一方、マー カー＃２はDSP104にクロスフェード動作を開始するよう指示することができる。 加えて、DACイベントバッファ166は、DACカードによりセンサ入力ライン62（ 図４）で受けたセンサ入力メッセージを格納する。カートマシンが自動的にコン タクト閉じることにより自動プレイを開始することを指示された時、コンタクト に最も近いセンサは、カートマシンによりプレイされたオーディオセグメントが 終了した時を検出する。 DACプロセッサの動作 次に、DSPの動作についてさらに詳しく説明する。 最初に、入力がいつ与えられたかを判定するために、データスイッチ120はラ イン108を監視する。この条件が満足されると、データスイッチ120は入力データ をアクセスし、この入力データ内のDACアドレスを判定する。データスイッチ120 は、この入力DACアドレスと、カードコントローラ122からライン122ａに沿って 与えられたアドレスとを比較する。もし、与えられたDACのDACアドレスが、入力 データのアドレスに対応するならば、データスイッチ120は、該入力データがこ のDAC向けのものであると判定する。選択的には、入力データのアドレスがグル ープアドレスを表しているときは、データスイッチ120は、与えられたDACが既に 該グループに割り当てられているかどうか判定する。カードコントローラ122は 、データスイッチ120に対し、既に該DACが割り当てられているグループアドレス を伝える。もし入力メッセージが、与えられたDACまたは与えられたDACを含むグ ループに宛てられていないならば、データスイッチは当該データを無視する。 入力メッセージが、与えられたDACまたは与えられたDACを含むグループに宛て られているときは、データスイッチ120は、カードコントローラ122からのコント ロール信号に基づいて、当該データを１またはそれ以上のライン124、126、およ び128へ転送する。例えば、ライブプレイ動作中は、データスイッチ120は入力オ ーディオデータをライン124に沿って、一時記憶のために、フレームバッファ146 に転送する。フレームバッファ146は、各データフレームをデコードするために デコーダ150に転送し、ｎディジタルオーディオ信号として出力する 。デコーダ150の出力はディジタル−アナログコンバータを通してライン160へ出 力することができ、究極は加入(affiliate)コントローラ46からライン56（図４ ）に、一斉送信されるアナログオーディオ信号として、出力することができる。 あるいは、記憶動作中は、入力データファイルが、データスイッチ120を介し ライン128に沿ってデータバッファ130に転送される。データバッファ130は、オ ーディオデータをライン134に沿ってそしてDACドライバ132を介して究極は加入 コントローラのメモリ48に転送するまで、一時的にデータファイルを記憶する。 選択的には加入ユーザは、カードコントローラ122を介してDSP104に対し、入力 オーディオデータをライン128および124へ送出するように指令することができ、 これにより、オーディオデータを（データバッファ130を介して）記録し、そし て同時に（フレームバッファ146およびデコーダ150を介し）ユーザに聴取させる ことができる。 加入者コントローラ 図８はDAC52との関連で使用される加入者コントローラ46のモジュールの機能 を概括的に示す図である。加入者コントローラ46は、仮想DACドライバ132を介し 、DAC52と通信を行う。加入者コントローラ46は、上述したごとくDSP104とイン タフェースする複数の内部モジュールを具備したオーディオサーバ180、を含む ように構成することができる。 オーディオサーバ180は、入力データ処理モジュール181を含むことができ、こ の入力データ処理モジュール181は、データバッファ130(図７)から受信したデー タファイル（例えば、オーディオファイル、カート（cart）ファイル、プレイリ ストファイル、ビデオファイル、テキストファイル）を処理する。入力データ処 理モジュール181はこれらのファイルをメモリ46に格納する。オーディオサーバ1 92は、カードコントローラ122と通信するためのカードコントロールモジュール1 82を含むことができる。カードコントロールモジュール182とカードコントロー ラ122は、リクエスト、レスポンス、ポーリングコマンド等のコマンドを、これ らの間でやりとりする。オーディオリクエスト処理モジュール184は、カードコ ントローラ122からのデータリクエストを提供するために設けることが できる。以下にさらに詳しく説明するように、オーディオリクエスト処理モジュ ール184は、メモリ48からデータフレームを得、そしてこれらのデータフレーム を、再生動作中に、デコーダ150および152の一方に対して送出する。補助データ マネジャーモジュール186およびイベントマネジャー（管理）モジュール190はま た、補助データバッファ164およびイベントバッファ166からの補助データおよび イベントデータ、をそれぞれ受信する。補助データおよびイベントマネジャーモ ジュール186および190は、入力データおよびメッセージを、記憶および処理のた めのオーディオサーバ180内の適当なモジュールに送出する。 オーディオサーバ180は、再生、センサ入力、接点閉止（コンタクトクロージ ャ）出力等に対する制御を行う。オーディオサーバ180は、通信リンク188を介し ての加入ユーザとのインタフェースに供する。このようにして、加入ユーザはオ ーディオサーバ180に対し、加入端末によりなされる前述の機能を果たすように 指令することができる。選択的には、リンク188は、リモートコントロール端末5 4に対ししたがって加入端末16に対し、オーディオサーバ180からのコントロール リクエストを入力可能にすることができる。 オーディオリクエスト処理モジュール184は、加入者端末のメモリ上に格納さ れたオーディオファイルとDAC52との間のインタフェースをなす。以下にさらに 詳しく述べるように、オーディオリクエスト処理モジュール184はバッファを含 み、このバッファは、オーディオファイルからのデータフレームをDAC52に送出 するために、メモリ48上に格納されたオーディオファイルからのデータフレーム を記憶する。 オーディオサーバ180は、加入端末との会話を行う全てのインタフェースアプ リケーションのためのコモンポイントをなす。オーディオサーバ180は、ユーザ に対しいくつかのリンク（例えば、LAN、シリアル等）を介してそれに付属する ことを可能にするところの多機能サーバを代表している。ユーザはオーディオサ ーバにリクエストを送信し、そしてそこからリンク188介しレスポンスを受信す る。オーディオサーバ180は、端末リソース（例えば、オーディオファイル、カ ートマシンやリレイ閉止等の再生装置）の集合における同一のプール（pool）を アクセスする複数のユーザを管理する。仮想DACドライバ132は、記憶動作中に おいては、データフレームをDAC52からメモリ48へ、再生動作中においては、メ モリ48からDAC52へそれぞれ転送する。ドライバ132はまた、両方向へコマンドを 送出する。再生動作中に関連して、DAC52は、付加的データを必要とするとき、 ドライバに信号を送る。DAC52は、当該データを、ユニークな識別子（セグメン トハンドル）によって特定する。 格納されたセグメントの再生 図10ａおよび10ｂに戻ると、これらの図は、再生動作に関連して、加入コント ローラ46およびDAC52によって実行される処理シーケンスを示す。オーディオサ ーバ180は、再生指令を受信する（この指令は、リンク188を介したユーザからの ものまたはセンサ入力62を介したリモート装置からの如きものである）。初めに 、オーディオリクエスト処理モジュール184は、ドライバリクエスト信号を待ち 受けるためのリード（read）ステートにセットされる。オーディオサーバ180は 、オーディオリクエスト処理モジュール184と共に１またはそれ以上のオーディ オセグメントを登録する（ステップ202）。登録を行うために、オーディオサー バ180はカートファイル内の情報のごときデータファイル情報を、オーディオリ クエスト処理モジュール184に転送し、そのデータファイル情報は、オーディオ セグメントまたはプレイすべきセグメントを収容するデータファイルの名前を含 む。加えてオーディオサーバ180は、オーディオファイルへのスタートオフセッ トおよびエンドオフセットを、オーディオリクエスト処理モジュール184に転送 する。データファイル情報は、セグメントリクエストとして、オーディオリクエ スト処理モジュール184に転送され、このオーディオリクエスト処理モジュール1 84は、オーディオセグメントデーブル上のオーディオリクエストを記憶しそして ユニークなセグメントハンドル（例えばユニークナンバー）を当該セグメントリ クエストに割り付ける。セグメントハンドルは、セグメントリクエストと共にオ ーディオセグメントテーブル内に格納される（ステップ204）。 オーディオリクエスト処理モジュール184は、ユニークなセグメントハンドル をオーディオサーバ180に返送する。その後、オーディオサーバ180は、セグメン トハンドルおよび付加的コントロール情報を、ロードセグメント情報リクエスト 信号として、DAC52に転送する（ステップ206）。その付加的コントロール情 報は、例えば、どのデコーダを指定するかの識別子やセグメントスタートオプシ ョンやスタートフェーディング時間やエンドフェーディング時間やイベントマー カーやスタートトリガ等を含むことができる。ロードセグメントリクエストは、 カードコントローラ122に転送され（図７）、そしてカードコントローラ122は少 なくともユニークセグメントハンドルを格納する。 ステップ208において、DSP104は、セグメントハンドルを含むリクエストオー ディオデータメッセージを、オーディオリクエスト処理モジュール184に返送す る。このメッセージを受け取ると、オーディオリクエスト処理モジュール184は 、セグメントハンドルによってオーディオセグメント内で特定されるオーディオ ファイルを、アクセスする（ステップ210）。オーディオリクエスト処理モジュ ール184は、オーディオファイルからのデータフレームのセットを読み出し、そ してこれらのデータフレームをDAC52へ送信する。ステップ212において、オーデ ィオリクエスト処理モジュール184はDAC52からの次のデータリクエストを待ち受 ける。 図10ｂに戻ると、DAC52は、オーディオリクエスト処理モジュール184から受信 したデータフレームを、指定されたデコーダ入力バッファにロードする（ステッ プ214）。DACはその後、デコード動作を開始する前のスタートメッセージを待ち 受ける。ステップ216において、オーディオサーバ180は、DAC52へデコーダプレ イリクエストを送る。デコーダはそのデコードを開始し、ディジタルオーディオ 信号を出力する（ステップ218）。このデコーダが、デコーダ入力バッファ内の データフレームの予め定めた部分をデコードし終えたとき、DAC52は、リクエス トオーディオデータメッセージを、オーディオリクエスト処理モジュール182に 送出する。ステップ220において、オーディオリクエスト処理モジュール184は、 ハードドライブからデータフレームの次のセットを読み出し、この新しいデータ フレームのセットをDAC52に書き込む。オーディオリクエスト処理モジュール184 は再びウェイト（wait）ステートに入り、DAC52からの次のデータリクエストを 待ち受ける。ステップ218および220は、要求されたセグメントまたはオーディオ ファイルからのセグメントがオーディオリクエスト処理モジュール184によって 読み出され、DAC52に転送され、オーディオ信号として出力される まで、または、ユーザが介在するまで、繰り返される。 ステップ226において、DAC52は、デコーダ入力バッファ内に格納された最後の データフレームがデコードされそしてプレイされると、セグメントイベントの終 了を送出する。セグメントイベントの終了がオーディオリクエスト処理モジュー ル184によって受け取られると、オーディオリクエストプロセッサは（ステップ2 28）、そのバッファからのデータフレームの最後のセットをクリアし、オーディ オファイルをクローズする。加えてオーディオサーバ180は、オーディオセグメ ントの再生動作が終了したときに必要ないくつかの付加的な処理を行う。これら の付加的な動作には、テーブルのクリーニングアップやユーザへの通知や、コン タクトリレーの開閉等があろう。 格納されたセグメントを有するローカルスポットの自動再生 次に具体例を述べる。メモリ48上に記憶されたオーディオプログラムの再生中 は、ローカルオーディオセグメントがカートマシンにより自動的にプレイされる 。メモリ48上に記憶されたオーディオセグメントは、上述の再生動作に従って、 DSP104によりプレイされる。提示した一例にのみよると、記憶されたオーディオ プログラムは、２つのオーディオセグメント（ナショナルセグメント＃１および ナショナルセグメント＃２）を含むことができ、これらは、２つのローカルセグ メント（ローカルセグメント＃１およびローカルセグメント＃２）によって区分 される。 初めに、ナショナルセグメント＃１がメモリ48より読み出され、そしてデータ フレームのセットとしてDSP104に供給される。マーカー（marker）属性が、ナシ ョナルセグメント＃１が終了したときにローカルマシン（これはローカルセグメ ント＃１を含む）を起動するために接点が閉止されるべきことを表示するナショ ナルセグメント＃１、に割り付けられる。DSP104が第１ナショナルセグメントを 処理するとき、これは適当なオフセット時間後にマーカー属性を特定し、マーカ ーナンバーのようなマーカー属性メセージをDACイベントバッファ166に書き込む 。加入コントローラ46はマーカー属性メセージ（マーカーナンバー）をイベント バッファ166から読み出し、そしてこれに応答して、DAC52に対し、接点閉止信号 をライン60（図４）上に出力すべきことを指示する。ここにその接点閉止信 号は、第１カートマシン（ローカルセグメント＃１を含む）のプレイを開始させ る信号である。DAC52は次にカートマシン１からのセンサ入力ライン62をポーリ ングする。カード＃１内のローカルセグメントが終了したら、カートマシンは停 止され、そして接点開成信号はセンサ入力信号62に返送される。センサ入力62か らの返送信号は、加入コントローラ46に対し、カートマシンはローカルセグメン トのプレイを終了したことまたはローカルセグメントのプレイを終了しつつある （例えば30秒以内に）ことを通知する。センサ入力ライン62に沿った入力に応答 して、加入コントローラ46は、DSP104に対し、次のナショナルセグメント＃２の プレイを開始すべきことを指示する。加入コントローラ46は、第１ローカルセグ メントが終了したとき、上記のように、DSP104に対しナショナルセグメント＃２ をロードする。 この具体例においては、マーカー属性＃２がナショナルセグメント＃２に割り 付けられ、このナショナルセグメント＃２は、第２ローカルセグメントが第２ナ ショナルセグメントの終了の後に続くべきこと表示する。DSP104が第２ナショナ ルセグメントを処理するとき、DSP104は、第２マーカー属性メッセージを、第２ ナショナルセグメントのプレイ中の所定の時に、データイベントバッファ166内 に書き込む。加入コントローラ46は、バッファ166より第２マーカー属性を読み 出し、そしてDSP104に対し、ライン60ｂ上に第２接点閉止信号を出力すべきこと を指示する。ライン60ｂ上の接点閉止信号は第２カートマシンに対し、第２ロー カルセグメントのプレイを開始すべきことを指示する。上記のとおり、第２カー トマシンが第２ローカルセグメントの終わりに至ったとき、第２カートマシンは ライン62ｂ上にセンサ入力信号を出力し、DSP104に対し第２ローカルセグメント の終了を指示する。付加的には、第２カートマシンは、第２ロ一カルセグメント の終了前の所定時間（例えば30秒）、ライン62ｂに沿ってセンサ入力を供給する ことができる。このように、加入コントローラ46は自動的に、ナショナルおよび ローカルセグメントをクロス−フェイド（cross-fade）することができる。 図11は、メモリ48に格納された２つのオーディオセグメント間のクロス・フェ ード動作の代表的なブロック図であり、カート装置によりプレイされるローカル スポットにより引き継がれる。本例の目的のために、プレイリストは次のカート ファイル名及びカートファイルのプレイを開始するときの指示を含むと仮定する 。 segment #1-Start Option，Manual Segment #2-Start Option，Marker 2 Local Spot #1-Start Optic]n，Marker 1 さらに、セグメント＃１及び＃２及びローカルスポット＃１のためのカートフ ァイルは少なくとも次の属性を含むと仮定する。 Segment #1 Start Offset 0 End Offset 2000 Marker 2，1900 Audio File Name #1 Segment #2 Start Offset 400 End Offset 3000 Marker 1，3000 Audio File Name #2 Local Spot #1 Contact Closure，Cart 1 Sence Play End，Cart 1 図７及び図８に戻り、動作中、オーディオリクエスト処理モジュール184は、 初期においてカードコントロール122セグメントハンドル及びセグメント＃１及 び＃２の属性の対応リストに進む。セグメント＃１はオーディオファイル＃１（ 例えば、各位置はデータフレームに対応）にて位置0から2000に広がり、セグメ ント＃２はオーディオファイル＃２にて位置400と3000の間に広がる。 オーディオリクエスト処理モジュール184は、メモリ48からセグメント＃１及 び＃２に対するデータフレームの第１の組を得、その組をカードコントロール12 21に通す。データフレームの組は第１及び第２のデコーダ150及び152にてバッフ ァに格納される。第１のデコーダ150はセグメント＃１からデータフレームを 処理する。オーディオリクエスト処理モジュール184は、第１のデコーダ150必要 とされるとして、セグメント＃１から新たなデータフレームを提供する。第１の デコーダ150が位置（例えばデータフレーム）1900に到達すると、DSP10はマーカ ＃２を検出する。それに応答して、第２のデコーダ152は、セグメント＃２から データフレームの第１の組をデコードする。この方法で、図11のクロスフェード 範囲500で示すように、第１及び第２のデコーダ150及び152は同時にデジタルデ ータを出力する。クロスフェード範囲500において、ミキサ158は、ポイント160 にて放送局に提供され及び／又はAES／EBU出力に提供されるように、２つのセグ メント出力を混合するため、オーディオセグメント＃１の大きさを減少し、オー ディオセグメント＃２の大きさを増大する。 随時、第２のマーカイベント（例えば、マーカ１，1600）は、ミキサ158に指 示するためにセグメント＃１に対するカートファイルに加えられ、クロスフェー ド範囲500を減少させる前にセグメント＃１の大きさの減少を開始する。この例 では、ミキサ158はポイント504(ライン506で示す)ポイント504にてセグメント＃ １の大きさを減少を開始する。第２のデコーダ152はポイント508にてセグメント ＃２を開始し、混合動作は上述のように続けられる。 図11への続きとして、第２のデコーダ152は位置3000に到達するまで、処理セ グメント＃２を続ける。位置3000はセグメント＃２の端部に対応しマーカ＃１に 対応する。マーカ＃１は、対応するセグメントハンドルに沿ってイベントバッフ ァ166にて格納される。イベント管理モジュール190は、このイベントメッセージ をオーディオサーバ180に中継する。これに応答して、オーディオサーバ180は、 カート装置＃１へライン60（図４）上にて接点閉止信号を出力するために、カー ドコントロールモジュール182を経て、指示が目指すDAC52に戻る。接点閉止信号 は、ローカルスポット＃１のプレイを開始するためにカート装置＃１を指示する 。 オーディオサーバ180は、センサ入力信号がカート装置＃１からライン62に沿 って受信されるときを決めるためにDAC52にポールする。センサ入力信号はロー カルスポットが完全にプレイしたことを示す。DAC52はセンサ入力信号の受信を オーディオサーバ180に通知する。オーディオサーバ180はプレイリストにおけ る次のカートファイルに基づきプレイを継続する。 ハブ端子を持つ記事配信システム 図12は本発明の記事配信システムの他の実施形態のブロック図である。記事配 信システム600は、データファイルを作るために上述の方法にて動作する少なく とも１つの生成サブシステム602を含む。随時、プロデューサ602はエンベロープ にデータファイルをアセンブルし、ライン618にそってハブ604にエンベロープを 通す。各エンベロープは後述の「エンベロープ・フォーマット」で述べるように 構成される。各ハブは上述した構成の加入者端子を含む。さらに加えて、各ハブ は、上述したような衛星受信機、及び／又はISDNリンクや電話回線リンク等のデ ジタルデータの伝送を支援する１つ又はそれ以上の通信リンクを含む。 図12において、ハブ604がプロデューサ602からエンベロープを受信すると、ハ ブ604はエンベロープ内のアドレス情報を読み取りエンベロープを経路化する。 もしエンベロープがハブ604に指向しているならば、ハブ604は、受信データファ イルの格納とプレイバックのために、加入者端子に関連して上述の方法で動作す る。もしエンベロープがISDN系列606に指向していれば、ハブ604はリンク620に そってISDN系列606へエンベロープを経路化する。随時、ISDN系列は系列端子16 に関連して上述した方法で形成するが、しかしエンベロープ、ライブデータその 他の受信及び送信に対してISDNリンクを中継する。 ハブ604はマスタ・アップリンクハブ608に入力エンベロープを経路化する。ハ ブ608は、配信サブシステム14に関連して上述したようなアップリンク装置を含 む。ハブ608は衛星アップリンク624にそって衛星610へエンベロープを送信する 。衛星610はダウンリンク626，628及び632にそって入力エンベロープを送信する 。衛星加入者612は加入者端子16に類似する。衛星加入者612は上述した加入者端 子16として入力エンベロープを処理する。もしISND系列616がエンベロープ内で アドレス情報にて識別されるならば、ハブ614は、エンベロープを受信すると、I SDN系列616へエンベロープを経路化する。 衛星610は、視界の衛星ライン内で、全てのハブ、衛星加入者等に、全ての入 力衛星を送信する。受信に際しては、各ハブ及び衛星加入者はアドレス情報を識 別するためにエンベロープをアクセスする。もしエンベロープが受信する衛星加 入者及び／又はハブにアドレスされるならば、それらはエンベロープを処理する 。もし、エンベロープがハブ又は受信するハブに接続されたISDN系列にアドレス されるならば、受信ハブはそこへのエンベロープを経路化する。しかしながら、 衛星加入者又はハブが、そこへアドルスしていないか、又は受信ハブ又は衛星加 入者に接続されたハブ又は加入者へ、エンベロープを受信するときは、受信する 衛星加入者又はハブはエンベロープを無視する。 例示の方法によれば、プロデューサ602は衛星加入者612へ指向されるエンベロ ープを発生すると、エンベロープは、エンベロープがハブ604又は加入者606へ指 向されないことを判断するハブ604に渡される。結論として、ハブ604は、マスタ 衛星アップリンクハブを示すハブ608へエンベロープを通す。マスタ衛星アップ リンクハブ608は衛星610を経てエンベロープを全ての衛星加入者及び衛星受信機 を持つハブへ中継する。ハブ614はエンベロープを受信し、エンベロープがハブ6 14又はISDN系列616へ指向されないことを判断する。結論として、ハブ614はエン ベロープを無視する。衛星加入者612はエンベロープを受信し、エンベロープが 衛星加入者612へ指向されていることを判断する。そこへの応答として、衛星加 入者612は上述の方法でエンベロープを処理する。 随時、全てのハブは衛星受信機を含む。 エンベロープ・フォーマット 各エンベロープは、記録部分に分割された多重データファイルから構成される 。各記録部分は、その対応するエンベロープとともに記録部を連合する特定のI. D.を含む。加えて、各記録部は、エンベロープが作られた生成サブシステムを特 定するプロデューサ・サブシステムI.D.を含む。プロデューサ及びエンベロープ I.D.は、特定の識別及び配信システムを経て各エンベロープのトラッキングを可 能にする。 随時、各エンベロープは、エンベロープが経路化されたハブ及び加入者のリス トを含むルーティング経路記録部を含む。ルーティング経路記録部は、エンベロ ープを受信し経路化する各プロデューサ及び加入者により更新される。例示のみ として、プロデューサ602がエンベロープを生成すると、ルーティング経路記録 部は、エンプティを開始する。エンベロープがハブ604に渡されると、ハブ604 のI.D.はルーティング経路記録部に加えられる。このプロセスはエンベロープが 宛先に到達するまで繰り返される。従って、プロデューサ602から加入者616に進 むエンベロープは、ルーティング経路記録部にて、加入者616における配信のと き、ハブ604のハブI.D.、マスタハブアップリンク608、及びハブ614を含む。 ルーティング経路記録部は、単一のハブを経て経路化するサーキュラを防止す るためにシステムにより利用される。例示として、ハブ604は、衛星610からの衛 星送信を受信するための衛星受信機を含む。 次に、サーキュラ・ルーティングがルーティング経路記録部を使用して防止さ れる例を説明する。プロデューサ602は衛星加入者612の指向されるエンベロープ を生成する。エンベロープはハブ604、ハブ608、及び衛星610を経て通る。この 点において、ルーティング経路記録部は、ハブ604のハブ608のハブI.D.を含むた めに更新される。衛星610がエンベロープを送信すると、加入者612及びハブ604 と614はエンベロープを受信する。ハブ604はルーティング経路記録部をアクセス し、エンベロープが既にハブ604を経て経路化されたことを判断する。結論とし て、ハブ604はエンベロープを無視し経路を再ルーティングしない。 配信照合 随時、配信システムは配信照合を含む。配信照合によれば、パッケージが加入 者に送られると、プロデューサはトラッキング番号を提供される。プロデューサ の考えで、幾つかの異なるエンベロープ（各々異なる内容と配信アドレスを持つ ）を、ユーザに供給された宛先をもつ「グループ」にグループ分けする「ワーク オーダ」を作成する。ワークオーダは、単に実現可能性をもって異なる時間に提 出されたエンベロープの組を追跡するためのユーザへの方法である。プロデュー サには、プロデューサのエンベロー-プの配信のチェックのために800番をコール 可能にするモデム装着PCから使用されるソフトウェアが与えられる。掲示システ ムの一部として、ユーザには、エンベロープが配信され、どこに配信されなかっ たかの詳細が提供される。プロデューサに提供されるソフトウェアは、多くの受 け取り人に各々アドレスされた、多くの未処理のパッケージの管理を可能にする 。加えて、情報は、ワークオーダ宛先により検索される。システムへのアクセス は、ダイヤルアップダイレクト(800番)によるかインターネットを経由して行わ れる。配合照合システムは次の機能を提供する。システムは配信ステータス情報 の集中を行う。システムの構成は集中化されていないが、しかしプロデューサは エンベロープのステータスを見出す１つの位置に接触しようとする。配信情報は 集中化される。システムは共有のステータス情報を提供する。配信ステータス・ データベースは幾つかの「バックオフィス」アプリケーションの間で共有される 。このデータベースの幾つかの潜在的なユーザは次を含む。 ・掲示：掲示記録を発生するために使用される。 ・品質管理：性能を判断するための回顧的学習はこの情報を使用して行われる 。 ・追跡：ユーザはコールされとエンベロープがどこにあり、なぜ到達しないか を見出す助力を要求する。 ステータスデータベースは予測的であり、ユーザには配信が生じる時点に関し て正確な予測が与えられる。予測は配信が発出されるように更新される。トラッ キングシステムは、配信の異なる方法及び配信照合の関連機構を扱うことができ る。各配信は、それが配信される（ハブに送られる、FedExにエンターされる、 配信される）ように、潜在的に数個の異なるステータスを通過しなけばならない 。各配信装置は異なる照合要件を持つ。 ・ISDN：送信側にて配信時間に照合される． ・衛星：配信の時間にて受信機により照合される。受信機はその成功又は失敗 を中央機能に通信する。 ・FedEx：FedExシステムは、パッケージが適切に配信されたことを見るために 問合せを行う。 ・組合せ：幾つかの配信は上述の組合せである。システムを経ての配信の進行 の照合は重要である。もしパッケージが紛失し、最後に適切に配信された位置に 追跡されるならば、これは真実である。 配信照合構成 配信ステータスコンピュータ(DSC)が規定されている。DSCではTCP／IPを経て 、ローカルLAN、マイクロソフトのRAS又はインターネットからの通信が行わ れる。DSCはODBCを介してアクセスする共有のデータベースを保持する。データ ベースは、現状及び履歴的な配信の全てのステータスを格納する。全てのパッケ ージはハブに配信されると仮定される。これはシステムの設計を簡素化し、いず れか所定の加入者の受信した資源上の制御を可能にする。この方法で、管理は、 加入者通信資源のスケージューリング上での制御を保持する。 ハブがエンベロープを受信すると、ハブはエンベロープのアドレスラベルを検 査しDSCへ進める「積出しリスト」を作成する。積出しリストは、DSCにおける配 信ステータスのデータベースを保持するためにエンベロープから全ての情報を含 む。 ・エンベロープの追跡番号：この番号は、全てのプロデューサ間の唯一のプロ デューサ指定者、及びそのプロデューサに唯一のエンベロープ番号で構成される 。 ・プロデューサにより割り当てられるエンベロープの英語名。 ・エンベロープが配信されるに必要な宛先のリスト。 ・エンベロープと共に連合されるいずれかのワークオーダ。 ・ハブにて受信されたエンベロープのデータと時間。 積出しリストは、どのようにしてエンベロープが経路化されるかをハブが判断 するのとは無関係に、DSCへ送られる。言い換えれば、例えエンベロープがアッ プリンクハブ（全てのローカル配信）に送られるとしても、積出しリストは、DS Cに送られる。積出しリストは、ダイヤルアップRAS又はインターネットを介して DSCに送られる。他のイベントとして、TCP／IPプロトコルが使用され、それによ り、受信ハブはDSCへの積出しリストの配信のポジティブな完全な確実性を持つ 。DSCは配信ステータスのデータベース(DSD)におけるエントリーを構成するため に積出しリストを使用する。必要なら、DSCは迅速なメッセージを、DSDへの変更 を示すためにDSCとともに「登録された」ものを持つバックオフィスアップリケ ーションに送る。DSCは、どのようにして種々の宛先に配信されるかを判断する ために、このデータベースにて情報を使用する。これは初期の配信予測を判断し 、各配信イベントに「状態図」を設定することを可能にする。各配信イベントの １つのエントリはDSDにで作られる。配信イベントは単一のエンベロー プ／宛先対である。状態図は、配信に必要な論理経路にそってエンベロープの遷 移を追跡する（例えば、衛星へ、Wilmingtonへ、FedExへ、のアップリンク配信 ）。 ・衛星ダイレクト：衛星を介して直接加入者へのアップリンクハブ。 ・ISDNダイレクト：ISDN加入者は同じエリアに位置し、エンベロープを受信し たポストオフィスハブである。 ・IDSNへの衛星：アップリンクハブは、エンベロープを加入者に配信するハブ に、エンベロープを配信する。 ・オフリンク：Wilmington加入者へ、FedExへアップリンクハブの宛先。 配信経路の各脚部は完了を報告する。報告を完了するために使用されるメカニ ズムは、アクティブ（配信処理の幾つかの要素はDSCへの完了をアクティブに報 告する）又はパッシブ(DSCは完了を判断するために幾つかのアクションを起こす )である。完了を判断するメカニズムは配信技術に依存する。次がサポートされ ている。 ・ISDN：送信（ハブ）は、エンベロープが適切に配信されたことを報告する。 報告はDSCへ直接なされる。報告は互いに束にされ、失敗は直ちに報告される。 ・衛星：以下に述べる特定のポーリング技術が使用される。 ・FedEx：FedExコンピュータは完了を判断するためにDSCによりポールされる 。ポーリングは、Divine Guidance及びファスチング(fasting)にそってFed Ex予 測配信時間に基づく。 DSCはプロデューサ及びたの利害関係者からのコールを受け、発呼者の問合せ を可能にするTCP／IP基準規約と、配信ステータスに属する情報のDSDを提供する 。DSCは、DSD上での家事雑用を実行することを話して他のバックオフィスアプリ ケーションからのメッセージを受ける。 衛星配信の照合 衛星が送信のみの媒体であったとしても衛星ベースのエンベロープの配信を照 合することができる。この場合、レシーバが情報を正しく受けとらなかったこと をレシーバが報告するための戻りチャネルがない。多数の潜在的なレシーバが使 用されるならば、配信が行なわれたかどうかを決めるために単純なポーリングを することは望ましくない。DSCは異なった形式のポーリング機構を使用すること ができる。衛星配信は通常は成功するものである。レシーバのみがエンベロープ を受け取ったかどうかを気にしている。エンベロープは一部のみが失われて部分 的に受信されるかもしれない。 上記の結果として、DSCは次の照合機構を実現する。規則的な周知の間隔でDSC はデータベースを走査しどの配信イベントが衛星配信を必要としているかを決定 する。DSCは最近配信したエンベロープのリストを含む「目録パッケージ」を組 み上げる。目録パッケージは上りリンクハブを経て衛星へ送出される。パッケー ジの宛先の加入者は目録パッケージを受け取りそれらの目録をパッケージ内の目 録と比較する。不一致があれば加入者はPOTSラインを使用してリセンドマネージ ャ(RSM)を呼び出す。不一致がなければ加入者は何もしない。エンベロープの受 信のどんなときでもレコードが失われているエラーがあると加入者が決定したら 加入者はRSMにコンタクトをとる。期待されるときに加入者が目録パッケージを 受け取らなかったら（エンベロープが受け取らなかった局に対するプレースホル ダとしてヌルパッケージが使用される）その加入者はRSPを呼び出す。DSCが同じ ファイル内に２つの目録パッケージを送って局側から何の苦情も受け取らなけれ ばDSCはそのファイルに対して配信されたとの記しを付ける。配信されたファイ ルはその後の目録パッケージには含まれない。 配信状態データベース DSCは配信過程の状態を定めるために使用されるテーブルの集まりである。次 のようなテーブルが定義される。 １．加入者データベース。このテーブルは局識別子とその局に達するパスとの 関係を定める。これは基本的に配信の形式（衛星、ISDN等）である。このテーブ ルはDSCがパッケージを追跡するために使われるであろう状態図を決定するため に使われる。 ２．プロデューサデータベース。プロデューサ番号とプロデューサの住所、電 話番号、ネームコンタクトのようなプロデューサ情報との関係を定める。 ３．配信イベントデータベース。このデータベースは各配信イベントのエント リを含んでいる。それらは次の様な欄を含んでいる。 ＊エンベローブ識別子。これはプロデューサ番号を含む。 ＊宛先指定。エンベローブがどこに配信されるべきか。 ＊処理順優先度。エンベローブがいつ配信されるか。エンベローブは配信の優 先度により各ハブと加入者によるルーチングのため並べ替えられる（例えば最優 先度のエンベローブは最初にルーチングされる）。 ＊処理順指定。これはオプションでありユーザから与えられる。 ＊現在の状態。 ＊配信に対する現在の最良の評価。 ＊配信状態図内の状態。 ＊DSCが完了アルゴリズムを実行するために必要な付加スタッフ。 リモートコントロール端末 図５はオンエアインターフェースのような例示的なリモートコントロール端末 の概略斜視図である。リモートコントロール端末58はDJのブース内からのような 加入者端末の遠隔制御を提供する。リモートコントロール端末58は加入者のコン トローラ46において利用可能なすべての機能もしくはその一部のみを可能にする 。例えば、リモートコントロール端末58は与えられた曲目リストのオンエア製作 のみについて関わる。リモートコントロール端末58はディスプレイ70と制御キー 72を含んでいる。制御キーは与えられた曲目リストなどの中でいくつかの様々な オーディオ選択肢の中からオンエアオペレータが選択することを可能にする。加 入者コントローラ46はリモートコントロール端末58においてどのオーディオ選択 肢がオンエアオペレータに提示されオンエアオペレータがどれを選択したかを決 定する。一般にリモートコントロール端末58の介在がなければ、１つのプログラ ム内からのオーディオセグメントの再生は曲目リストに基づく順番で行なわれる 。リモートコントロール端末58はオンエアオペレータが順番からはずれたオーデ ィオプログラムを選択することによりオーディオセグメントの通常の順序を無視 することを可能にしている。 制御キー72はオンエアオペレータが曲目リスト内から所望のプログラムを選択 することを可能にするための上下矢印を含んでいる。キー72は次のもしくは所望 のオーディオ選択物の再生を開始および終了させるためのスタートおよびストッ プキーを含んでいる。ディスプレイ70は現在再生されているイベントの終了まで をカウントするカウントダウンタイマを表示することができる。ディスプレイ70 はまた現在のオーディオイベントに対してアウトキューを提供する。ディスプレ イ70は各オーディオファイルと関連付けられた形式を含む、現在のプログラムを 制御するために使われる曲目リスト情報の一部またはすべてを表示することもで きる。 センサ入力62はDJからの再生要求を得るためにリモートコントロール端末を監 視する。この様にして、DJはDAC52が通常の再生リスト順序からはずれたプログ ラムを再生することを要求することができる。DJはまた、リモートコントロール 端末を介して、DAC52がDAC52にキュー記憶されている次のセグメントの再生を開 始し、現在のセグメントの再生を停止し、現在のセグメントを飛ばしてまたは次 の／以前のセグメントまで早送り／巻戻しすることも要求することができる。DJ はまたリモートコントロール端末上の上下矢印を使ってDJに対して表示されてい る曲目リストをスクロールし、順番を無視して曲目リストからセグメントを選択 することができる。DJはまたセンサ入力62を介してDAC52へ通知される試聴オプ ションを選択することによりセグメントを試聴することもできる。 加入者オーディオサーバ 加入者端末はプログラムディレクター、オンエアDJ、トラフィックユーザ及び 国外システムとのインターフェースを含む様々なユーザとの多数のインターフェ ースをサポートしている。プログラムディレクターインターフェースはプログラ ムディレクターに対して加入者コントローラ46を介してシステムが提供できる機 能のすべてを提供するためのものである。オンエアDJにはリモートコントロール 端末を介してアクセスすることができ曲目リストからのプログラムの再生、停止 および試聴のような限られた１組の機能が提供される。トラフィックユーザはロ ーカルプログラムスポットの利用可能性に関するドキュメントを調査することに 関心がある。トラフィックユーザはオーディオの再生に関する制御はできないが 、その代わりとして単に曲目リストなどを見ることができる。国外システムのユ ーザはRS232ポート、ローカルエリアネットワークなどを介して加入者コントロ ーラにアクセスすることができる。各々国外ユーザはオーディオサーバ180(図８ )を介して加入者端末と通信する。オーディオサーバはユーザのタイプとユーザ がアクセスした潜在機能の集合を特定する。上記のユーザのタイプの各々は１以 上のプロトコルを介してオーディオサーバへ通知される。例示にすぎないが、ユ ーザとサーバの間の通信はTCP／IPソケットなどを経て行なわれる。TCP／IPチャ ネルはASCII形式のテキストおよびバイナリデータの伝送をサポートしている。 オーディオサーバ180は多数の異なるオブジェクトに対して有効である。ユー ザはプロトコルを介してオブジェクトにアクセスすることができる。例えば、１ つのオブジェクトはプレイヤーである。プロトコルメッセージはユーザがシステ ム内のプレイヤーの数を数えあげ（例えばそれらがいくつかあるか）、オーディ オをプレイヤーにロードし、プレイヤーに再生などをさせることを可能にする。 各オブジェクトはそれに関する状態を待っている。いくつかの状態情報はブー トアップ(boot up)からブートアップまで持続する（持続状態情報）のに対して 、他の状態情報はオーディオサーバが実行を開始するごとにセットされなければ ならない（一時的状態情報）。持続状態情報の例は或るスタジオに対する或るプ レイヤーの関連付けであり、一時的状態情報の例は或るプレイヤーが実際に再生 しているかどうかである。プロトコルメッセージの或るものはオブジェクトの持 続状態を変更して他のメッセージはオブジェクトの一時的状態を変更する。 持続オブジェクトはオブジェクトの状態情報を含んでいるファイルを有してい る。ファイルはASCII形式のファイルで良い。ファイル内の各レコードはキーワ ードと値を含んでいる。 オーディオサーバのユーザはTCP／IPコネクションを確立することによりアプ リケーションへ接続することができる。２つのパスすなわちメッセージパスとイ ベントパスがサーバに対して確立される。メッセージパスは双方向でありインタ ーフェースクライアントとオーディオサーバの間の“マスタ スレーブ”モード の通信のために使用される。インターフェースクライアントはマスターでありオ ーディオサーバへのメッセージを送る。オーディオサーバはレスポンスを戻す。 イベントパスについては、オブジェクトはイベントおよびオブジェクト内の状況 （例えば、プレイヤーがオーディオを再生し終わった、ユーザがボタンを押した など）に関してクライアントに警告するためインタフェースクライアントへメッ セージを送る必要がある。これらのメッセージはインタフェースクライアントの イベントパスを経て送られる。 オブジェクトはまた“コンテナ”オブジェクトも表現する。これらのオブジェ クトは他のものを含んでおり、例えば、“テープラック”はオーディオファイル 、再生リストおよびカートファイルを含んでいるコンテナオブジェクトである。 再生リストは再生リストを構成するオーディオセグメントのリストを収容するコ ンテナである。コンテナはファイルディレクトリとして実現できる。デスクトッ プは最上位のディレクトリである。ユーザがシステムにログインするとユーザの は現在の作業ディレクトリはデスクトップとなる。これはそのディレクトリ内の オブジェクトを数え上げる目的で他のディレクトリへ移動できる。 オブジェクトはそれらが参照される前に“オープンされる”。オブジェクトの オープンはOPNメッセージで達成される。オブジェクトに対する参照が完了する とCLOメッセージがオブジェクトをクローズする。オブジェクトはリードオンリ ーモードまたはリード／ライトモードのどちらかでオープンされる。任意の数の ユーザがオブジェクトをリードオンリーモードでオープンすることができるが、 リード／ライトモードでは１人のユーザがオブジェクトをオープンすることがで きる。 オーディオサーバが実現することができるメッセージのリストを以下に示す。 呼び出し：CON＜user password＞ 戻り：AOK＜handle＞ コメント：この呼び出しによりユーザとオーディオサーバの間にコネクションが 確立される。オーディオサーバからの戻りはサーバからのアプリケー ションへ戻るイベントパスを確立するためにユーザが使用することが できるハンドルを提供する。 呼び出し：EVN（handle）CONの呼び出しで戻ったハンドルが使用される。 コメント：この呼び出しはメッセージをインターフェースクライアントへ送るた めにオーディオユーザが使用することができる同期イベントハンドル を生成する。 呼び出し：RFE〔＜name＞〕オプション：読み出すべきラックの英語バージョン 。これが与えられなければデスクトップがオブジェクトのソースとし て使用されることに注意。 応 答 ： ERRまたはAOK＜name＞＜type＞ ＜name＞ エレメントの名前。これは“英語名”であってファイル名ではない 。引用記号で囲まれたスペースを含んで良い。この名前はオブジェクトを参照 するための他の呼び出しに使っても良い。このように使う場合、ここで戻った ように正確に再現されなければならない。 ＜type＞ エレメントのタイプ（例えば、カート、ラック、再生リスト、プレ イヤーおよびログ）。 コメント：この関数は現在の作業ディレクトリの第１エレメントを戻す。通常、 現在の作業ディレクトリの内容を確立するためにRNE（read next ele ment）要求が続く。内容は受信オーディオ及び他のユーザ対話に応じ て変わるかもしれないことに注意。これらの変化はユーザに対してユ ーザのコネクション内の“イベントパス”を経て送られる。 呼び出し：RNE 戻 り ： ERRまたはAOK＜name＞＜type＞； AOKの引数の定義についてはRFEを参照。 コメント：ディレクトリに“次の”エレメントを戻す。 呼び出し：ONP＜how＞＜name＞＜type＞｛＜container＞＜type＞｝O-n ＜how＞ オブジェクトをどのようにオープンするか（例えばリードオンリー モードかリード／ライトモードか）。 ＜name＞ オープンすべきオブジェクトの英語名。 ＜type＞ オブジェクトのタイプ（例えば、カート、ラック、再生リスト、プ レイヤーまたはログ）。 ＜container＞ オプション：“コンテナ”名。 ＜type＞ コンテナのタイプ（例えば、ラックまたは再生リスト）。 注 意 ：引き数＜container＞＜type＞は入れ子形式のコンテナ内のカートを 特定するために必要なだけ引き数が繰り返されても良い。 戻 り ：ERRまたはAOK＜handle＞ コメント：この関数はオブジェクトを排他的に使用するものとしてオープンする 。オープンが許されるたらそれらを操作するためにハンドルを必要と する関数とともに使用されるオブジェクトへハンドルが戻される。ユ ーザがログオフしたときまたはユーザがCLOコマンドを発行したとき オブジェクトは解放されハンドルはさらなる意味を持たない。 呼び出し：HAS＜ename＞＜type＞； ＜ename＞ デスクトップオブジェクトの英語名。 ＜type＞ オブジェクトのタイプ。 戻 り ：AOK＜container＞またはERR。 コメント：これは主に、オブジェクトがその内容に基づき異なって描かれる場合 に、どのようにユーザインタフェースオブジェクトが描かれるかをチ ェックするのに使われる。 呼び出し：CLO＜handle＞ ＜handle＞ 成功したOPNリクエストによって与えられる処理。 応答：AOK又はERR コメント：この機能はオープンされたオブジェクトを開放する。 呼び出し：RIN＜handle＞＜keyl＞...＜keyn＞ ＜処理＞ オブジェクトに対するOPN処理。 ＜keyn＞ 読み出しキーワード 戻 り ：ERRエラーの場合、又は AOK＜valuel＞...＜valuen＞ ＜valuen＞ リクエストされた＜keyn＞の現在値 呼び出し：WIN＜handle＞＜keyl＞＜valuel＞...＜keyn＞＜valuen＞ ＜handle＞ オブジェクトに対するOPN処理。オブジェクトは読み出し／書き 込みモードでオープンされなければならない。 ＜keyn＞ 更新する値のキーワード ＜valuen＞ 変更するキーワードの値 戻 り ：AOK又はERR コメント：全ての読み込み可能なキーワードが変更されなくてもよく、例えばカ ート演奏時間は物理的なプロパティにもとづき変更できない。 呼び出し：IRP＜object＞ ＜object＞ 読まれるべき演奏リストのオープンされたオブジェクト。ここで は、プレーヤ又は演奏リストのいずれかである。 戻 り ：AOK又はERR 呼び出し：RPR 戻 り ：AOK＜handle＞＜type＞＜arguments＞（コメント参照） ERR ＜handle＞ プレイ（演奏）リストにおいて所定モードに対する独自の処理。 現在のものをSCEの演奏及びエレメントの削除に設定するのに使われる。 コメント：演奏リストレコードは、＜type＞引数に続く一連の引数である。それ らのフォーマットは以下の通りである： リマーク：REM＜remark＞ ＜remark＞ 演奏リストについての注を含む文字列。 オンエアノート：ONA＜remark＞ ＜remark＞ 演奏リストについての注を含む文字列。 スタートトラック：TRK＜title＞＜playtime＞＜outcue＞ ＜title＞ トラックに対する名称。通常“Segl”のようにつけられるが思い 付きのものでもよい。 ＜playtime＞ MSにおけるトラック演奏時間長。 ＜outcue＞ トラックのアウトギュー。 エンドトラック：ENT トラックの終了 カート：CRT＜type＞＜title＞＜playtime＞＜outcue＞ ＜type＞ ショー（例えば、コマーシャル、プログラム）のトラックにおける カートの使われ方。 ＜title＞ カートの英語タイトル。演奏リストディレクトリにおけるカート ファイルは発見されるのにこのカートタイトルと一致する必要がある。 ＜playtime＞ MSにおけるカート演奏時間。 ＜outcue＞ カートのアウトキュー。 ローカル ブレイク：BRK＜time＞ ＜time＞ MSにおけるローカルブレーク継続時間。 呼び出し：GPS＜player＞ ＜player＞ ステータスを得るプレーヤのオープン処理。 戻 り ：ERR又は AOK＜state＞＜loaded＞＜cur＞ ＜state＞ プレーヤの現在の状態（例えば、演奏中、停止）。 ＜loaded＞ プレーヤに負荷が与えられているか又は空きであるかを示す。 １ 負荷中 ０ 空き ＜cur＞ 現時点の無線の処理 呼び出し：LOD＜player＞＜element＞＜type＞〔＜location＞〕 ＜player＞ 負荷が与えられるプレーヤのオープン処理。 ＜element＞ プレーヤ上に負荷されるエレメントのASCII名。演奏リストのカ ートのいずれかでなければならない。 ＜type＞ 負荷するエレメントのタイプ（例えば、オーディオカート、オーデ ィオ演奏リスト）。 ＜location＞ プレーヤのスタックにエレメントを負荷する位置。これはオプ ション事項である。与えなければ、通常の位置であり最初の位置である０へ負 荷される。 戻 り ：AOK又はERR コメント：負荷されるエレメントは、デスクトップ上になければならない。一度 、エレメントがプレーヤに負荷されたなら、二度とデスクトップ上に 現れないことに注意すべきである。それは、プレーヤのディレクトリ に移動する。 このコマンドを実行するにはプレーヤは書き込みアクセスによってオープンさ れる必要がある。 呼び出し：PLY＜player＞ ＜player＞ 演奏を開始するためのプレーヤのオープン処理。読み出し／書き 込みモードにおいてオープンされなければならない。 戻 り ：AOK又はERR。イベントは現在エレメントの終了時点で送られる。 コメント：プレーヤは複数のオーディオエレメントを有し、演奏を開始すると次 のオーディオ演奏を実行する。 呼び出し：CUE＜player＞ ＜player＞ オーディオ開始をギューさせるプレーヤのオープン処理。プレー ヤは読み出し／書き込みモードにおいてオープンされなければならない。 戻 り ：AOK又はERR。 コメント：CUE機能は、演奏動作の呼び出し時間を少なくする。CUEを使わない場 合にはCUEは演奏において暗黙される。CUEを実行するとPLYは直ちに 実行される。PLYとオーディオ演奏の間の呼び出し時間は現時点にお けるプレーヤ演奏リストの機能である。 呼び出し：STP＜player＞ ＜player＞ 停止させるプレーヤのオープン処理。プレーヤは読み出し／書き 込みモードにおいてオープンされなければならない。 戻 り ：AOK又はERR。 コメント：現時点で特定プレーヤの再生を停止させる。プレイの発行によってそ のプレーヤを停止時点から続けて演奏させる。 呼び出し：REM＜player＞〔＜player＞〕 ＜player＞ そこからエレメントを取り除くプレーヤのオープン処理。プレー ヤは読み出し／書き込みモードにおいてオープンされなければならない。 ＜player＞ 取り除くエレメントの処理。この引数はオプションである。省略 した場合には“最初の”エレメントが取り除かれる。 戻 り ：ERR又はAOK コメント：この機能により、クライアントはプレーヤスタックからエレメントを 取り除くことができる。 呼び出し：SCE＜player＞＜handle＞ ＜player＞ オープンされたプレーヤ処理。 ＜handle＞ エレメントに対する処理。読み込んだ演奏リスト内容から得られ る。 戻 り ：AOK又はERR コメント：プレーヤの現在のエレメントを確立する。次の演奏やオーディション 動作はこのエレメントを参照する。 呼び出し：RCE＜player＞ ＜player＞ プレーヤのオープン処理。プレーヤは読み出し／書き込みモード においてオープンされなければならない。 戻 り ：ERR又はAOK＜handle＞ ＜handle＞ エレメントに割り当てられた独自の処理。この処理は独立してお り、システムがリブートされるまで変えられない。 コメント：プレーヤのプレイスタックにおける現在の位置に関する情報を提供す る。 呼び出し：AUD＜player＞＜end＞ ＜player＞ オーディションに対するプレーヤのオープン処理。プレーヤは読 み出し／書き込みモードにおいてオープンされなければならない。 ＜end＞ オーディションに対する現在のエレメントの終了時点。 ＜handle＞ エレメントに対する処理。読み込んだ演奏リスト内容から選択は ： ＋ｎ：エレメントの始めの“ｎ”秒オーディションし、それからエレメン トの開始位置へ；そして ｎ：エレメントの最後の“ｎ”秒オーディションし、それからエレメント の開始位置へ。 応 答 ：AOK又はERR。演奏が停止したとき送られるイベント。 呼び出し：MTR＜element＞＜type＞＜rack＞ ＜element＞ ラックに移動するデスクトップ上のエレメントの英語名。 ＜type＞ 移動するエレメントタイプ（例えば、カート、ラック、演奏リスト 、プレーヤ、ログ）。 ＜rack＞ ラックの英語名。ラックはデスクトップ上でなければならない。 戻 り ：AOK又はERR 呼び出し：MFR＜rack＞＜element＞＜type＞ ＜rack＞ ラックの英語名。ラックはデスクトップ上でなければならない。 ＜element＞ ラックに移動するデスクトップ上のエレメントの英語名。 ＜type＞ 移動するエレメントタイプ（例えば、カート、ラック、演奏リスト 、プレーヤ、ログ）。 戻 り ：AOK又はERR 呼び出し：DEL＜element＞＜type＞ ＜element＞ 削除するエレメントの英語名。 ＜type＞ 削除するエレメントタイプ（例えば、カート、ラック、演奏リスト 、ログ）。 戻 り ：AOK又はERR 呼び出し：MKR＜name＞ ＜name＞ ラックの英語名。 戻 り ：AOK又はERR コメント：この機能は同一名をチェックしてそれを許可しない。 呼び出し：CEN＜old-name＞＜new-name＞＜type＞ ＜old-name＞ デスクトップ上のエレメントの旧英語名。 ＜new-name＞ デスクトップ上のエレメントの新英語名。 ＜type＞ エレメントタイプ（例えば、カート、ラック、演奏リスト、プレー ヤ、ログ）。 戻 り ：AOK又はERR コメント：この機能は同一名をチェックしてそれを許可しない。 イベント・アーキテクチャ しばしば、サーバは、それに接続された１つ又はそれ以上のクライアントに情 報を送信しなければならない。例えば、クライアントリクエストによりサーバが 所定のオブジェクトを削除した場合には、全ての接続クライアントへ表示画面が 更新し得ることを通知する必要がある。他のイベント例では、プレーヤが演奏リ クエストされている全てのオーディオを演奏する時である。クライアントにはこ のことが通知されなければならず、それによって表示画面を更新し前記オーディ オ演奏が終了したことを示すことができる。 クライアントとサーバとの間の通信にTCP／IPが用いられるとき、第２のTCPコ ネクションとしてイベントが実行される。クライアントがサーバに接続すると、 クライアントはサーバ内に登録するようCONリクエストを発行する。サーバは、 サーバに対するクライアントの接続を識別する特別の“コネクション処理(conne ction handle)”を返答する。一度、サーバコネクションが確率されると、サー バに対し第２のTCPコネクションと第１のクライアントコネクションとを関連づ けるEVNリクエストが発行される。CONリクエストに応じて返されたコネクション 処理は、クライアントコネクションとイベントコネクションとを関連づけるのに 使われる。 一度、イベントコネクションが確立されると、着信情報をウェイトするのはク ライアントの責任である。DAXにおいて、これは“aserver.cpp”ソース・モジュ ールで実行される。スレッドが生成され、イベント状態で受信される全ての着信 メッセージをウェイトするのに使われる。メッセージは全て同じフォーマットで ある。 フォーマット：イベントをクライアントに報告する。 呼び出し：EVN＜id＞｛＜source＞｝｛＜argument＞｝ ＜id＞ イベント識別子。これはイベントを識別する十進数である。サーバに よって生成されたイベントはイベント定義という名のセクションに記録される 。 ＜source＞ イベントのソース。これはイベントのソースを示す。＜id＞との 関係においてのみ意味をなし、ソースは＜id＞において暗黙し得ることからオ プション事項である。例えば、サーバが“ダウンしたこと”を示すイベントに ソースは必要ない。“プレーヤの停止”のような他のイベントではソースをも ち得る。この場合、ソースはプレーヤ名となろう。 ＜argument＞ ＜id＞に基づきスペースで分けられた１つ又はそれ以上の引数 でもよい。引数は＜id＞に含まれる情報を増大させる。 コメント：クライアントはイベントチャネル上にレスポンスを送出し、イーブン （even）メッセージには応答しない。その代わりに、クライアントは イベントに対する適当なアクションを実行することで応答する。 演奏リストデザイン DAXオーディオ再生の核心は“演奏リスト”である。演奏リストは、互いに関 連性を有し様々なイベントに従って演奏されるオーディオカット（カート）のシ ーケンスを示すのに使われる。演奏リストは、基本的にはプログラムであってそ れをDAXプレーヤが翻訳して要求されたオーディオを生成する。 演奏リストは、ディスク上で拡張された“PLS”を伴うディレクトリによって 表される。前記ディレクトリにおいて、ファイルは常にディレクトリ名と同じ名 前がつけられる。但し、拡張子“TXT”をもつ。これは、演奏リストのASCII表現 である。また、ディレクトリにおいてカートファイルは演奏リストのオーディオ コンポーネントを構成する。通常、演奏リストを表すカートは演奏リストディレ クトリに置かれる。しかしながら、演奏リストは他に位置するカートを参照する ことも可能である。 演奏リストのテキスト表現は、次のセクションで述べられる多数のレコードで 構成される。 プレイリストレコード プレイリストは、一連のレコードである。全ての空白のライン及び「＊」文字 で始まるラインは、無視され、またコメントとして使用されることができる。各 レコードは、そのレコードを識別するキーワードで始まる。そのキーワードには 、１以上の空白で分離された０以上のフィールドが続く。次のレコードは、プレ イリストを構成する： レコード：REM＜remark＞ ＜remark＞ 各プレイリストについてのリマークを含むストリング。 機 能 ：プレイリストが表示されるときリマークがユーザに提供される。プレ イリスト内のリマークの位置は、どこにリマークが表示されるかを決 定するために使用される。トラックの外のリマークが最高位レベルで 表示される一方、トラック内のリマークは最高位レベルで表示され、 トラックが表示されるときのみトラック内のリマークは表示される。 リマークは、ジョックボックス上には表示されない。 レコード：ONAIR＜remark＞ ＜remark＞ 各プレイリストについてのリマークを含むストリング。 機 能 ：オンエアリマークは、リマークと同一であるが、ジョックボックス上 に表示される。 レコード：TRACK＜title＞ ＜title＞ トラックに関連するタイトル。これは、通常、“Seg 1”と類似し たものであるが、要求通りに想像的たりうる。 機 能 ：トラックを構成する要素のグループのスタートをマークする。なお、 システムがトラックのプレイ時間を自動的に計算することに留意する 。 レコード：ENDTRACK 機 能 ：トラックのエンドをマークする。 レコード：CART＜type＞＜title＞＜start＞＜signal＞＜fadeout＞ ＜type＞ 番組（例えば、コマーシャル、プログラム）のこのトラックにおい てカートがどのように使用されるか。 ＜title＞ カート用英語タイトル。プレイリストディレクトリ内のカートフ ァイルは、発見されるべきカートのこのタイトルに一致しなければならない。 ＜start＞ どのようにカートがスタートされるべきか。そのオプションは、 以下のとおりである： MANUAL−ジョックボックスボタン押下又はスタート光学的入力のいずれかによ ってカートがスタートされる。 PREV−前のカートのエンドにてカートがスタートされる。 MARK1−前のカートのマーク１によってカートがスタートされる。前のカート のエンドとこのカートのスタートとが混合される。 MARK2−前のカートのマーク２によってカートがスタートされる。前のカート のエンドとこのカートのスタートとが混合される。 ＜signal＞ システムが生成すべき信号を指定する。この信号は、「信号リレ ー」上のパルスである。該＜signal＞フィールドに関する有効値は、以下のとお りである： NONE−カート用に何の信号も生成されない。 END−カートのエンドで信号を生成する。 MARK1−マーク１ロケーションで信号を生成する。 MARK2−マーク２ロケーション場所で信号を生成する。 ＜fadeout＞ カートのエンドで使用するフェードパターンの数。フェードパ ターンが決定されるべきである。 機 能 ：このレコードは、オーディオの要素を定義し、どのようにオーディオ がショーにおいてプレイされるべきかを決定する。 レコード：BREAK＜time＞ ＜time＞ ローカルブレークの期間。MM：SSとして指定される。 機 能 ：このレコードは、ショーにおけるローカルブレークを指示する。それ は、「スタートローカルブレーク」リレーを活性化せしめる。「スタ ート」リレーが作動せしめられるまで又はジョックボックス上でスタ ートボタンが押されるまでオーディオはこのポイントで休止する。 レコード：END 機 能 ：プレイリストのエンド。 リレー及び光学的入力の定義 加入者は、DACカード当たり、４つのリレー出力及び４つの光学的入力を有す ることができる。各カードは、リレーを次のように定義する： リレー出力 １．プレイタリ(play tally)このリレーは、DAXがオーディオをプレイすると きにはいつでもクローズされる。 ２．スタートローカルブレーク(start local break)このリレーは、ノーマル オープンであり、ローカルブレークのスタートを指示すべくパルス的にクローズ する。 ３．信号出力(signal output)このリレーは、ノーマルオープンであり、カー トからの信号を指示すべくパルス的にクローズする（CARTレコード＜signal＞定 義を参照）。 ４．未割当て(unassigned) 光学的入力 １．スタートプレイ(start play)パルスが次のマニュアルカートプレイを開始 させる。 ２．ポーズ(pause)現オーディオイベントが休止しスタートプレイボタン押下 を待つようにパルスが誘発する。 ３．オーディション(audition)現オーディオトラックの最後の４秒がプレイさ れるようにパルスが誘発する。 ４．未割当て（unassigned） ジョックボックス ジョックボックス(jock box)は、スタジオに置かれたDACカートの物理的表示 である。それは、８個のプッシュボタン各々にLED及び小さなLCDディスプレイを 提供する。概念的には、ジョックボックスは、自動化されたチェンジャーを有す るCDプレーヤである。多くのオーディオ要素がチェンジャー内に置かれ得るのと 全く同じ方法で、多くのオーディオ要素がジョックボックスにおいて「ラケット 」足り得る。オーディオ要素は、単純なカート又はプレイリストのいずれかで足 り得る。プレイリストが内部構造を有するため、ジョックボックスは、ジョック (JOCK)がディスプレイ上で「ズーム」インするのを可能とするモードキーを有す る。そのモードキーを押下することによって、ジョックボックスはツリー(tree) の多くを表示する。そのモードキーの連続押下によって、ジョックボックスは３ つのレベルを巡回する。現在、３つのレベルは以下のものを含む。 １．チェンジャーの内容を示す。これは、個々のカート及び個々のプレイリス トを表示する。 ２．チェンジャーの内容を示し、加えて、プレイリストにおけるトラックを表 示する。 ３．レベル２と同様であるが、トラックについてより詳細を提供する。 いずれの時においても、表示されたトリーにおいてエントリの１つが強調され る。このエントリは、現エントリであると言われる。オーディオがプレイしてい ないとき、この現エントリインディケータは、ジョックボックス上のフォワード キー及びバックワードキーを押下することによって移動されることができる。プ レイ中、ジョックボックスは、ストップを除く全てのキー押下をロックアウトす る。次の表は、各キー及び各種レベルでのそれらの効果の概略である。 DAX転送エージェント 通信機構にかかわらず、情報を転送する方法は、本質的に同一のままである。 ヘッドエンドは、リモートへの接続を確立する。LANバージョンにおいては、こ れは、TCP／IPソケット接続である。ヘッドエンドは、“FIL”コマンドを送って ファイルを導入する。ヘッドエンドは、０以上の“ATR”コマンドを送り、現在 送られているファイルの属性を確立する。属性は、ファイルに関連する「データ ベース」値である。ヘッドエンドは、１以上の“DTA”コマンドを送ることで、 ファイルそれ自体を送る。ヘッドエンドは、“END”コマンドを送ることで、フ ァイル転送を終結させる。ヘッドエンドは、次のファイルをスタートするか、又 は（リンクタイプでは）「ディスコネクト」する。どんなときでも、“ABT”ア ボートファイル転送コマンドを送ることによって、転送を取り消すことができる 。 転送エージェントコマンドセット ヘッドエンドと通信するソフトウェアのピースは、転送エージェントと呼ばれ る。転送エージェントは、ヘッドエンドに送られ又はそれから送られるコマンド を解釈する。それが応答するコマンドは、以下のとおりである： 呼び出し：COM＜blocksize＞ ＜blocksize＞送られる最大メッセージバッファのバイトによるサイズ。これ は、次のDTAコマンドに関してレシーバを構成するために使用される。 戻 り ：ERR又はAOK コメント：このメッセージは、通常、転送セッションの始めに送られる。それは 、送信プログラムが使用しようとするブロックサイズについての、受信プログラ ムへの情報を提供する。 呼び出し：FIL＜title＞＜type＞＜〔＜collection＞〕 ＜title＞ オーディオに関する英語タイトル。 ＜type＞ オーディオのタイプ（例えば、オーディオのアート、プレイリスト ）。 ＜collection＞ このオーディオがその一部となるところのコレクションの名 称。コレクションの一部でないならば、このフィールドは、“−”に設定される 。 戻 り ：AOK又はERR コメント：このレコードは、ファイル伝送のスタートを表示するために送られる 。なお、＜title＞フィールドは、ファイルを一義的に識別するものであれば何 でもよいことに留意すべきである。それは、必ずしもDMS内のファイル名である 必要はない。さらに、ファイルは、「コレクション」内に寄せ集められることが できる。＜collection＞フィールドは、そのコレクションを一義的に識別するAS CIIストリングである。その観念は、コレクションが、「ショー」すなわち、多 分、オーディオのライブラリイを実現するために使用されるということである。 呼び出し：ATR＜keyl＞＜valuel＞...＜keyn＞＜valuen＞ ＜keyn＞ 属性を識別するキーワード。 ＜valuen＞ 属性の値。全ての値がASCIIストリングで表される。そのため、 例えば、属性がバイナリ値100を有するならば、それは、単一のバイナリバイト としてではなく、ストリング“100として送られるであろう。その値が埋め込み 型スペース文字を有するならば、その値は、引用符で囲まれる。 戻 り ：AOK又はERR コメント：ファイルは、そのファイルを記述するために使用される属性情報を有 する可能性がある。１以上のATRコマンドが、FILコマンドの後に送られる可能性 がある。ATRコマンドには、いくつかの属性キーワード対が存在しうる。その 限界は、やがて決定されるべきである。 呼び出し：DTA＜data＞ ＜data＞ そのファイルに適したデータバイト（例えば、オーディオファイル はオーディオバイトを有する一方、テキストファイルは同様にテキストを有する ）。 戻 り ：AOK又はERR コメント：ファイル内のデータは、テキスト又はバイナリのいずれかが可能であ る。転送の最初の４バイトは、ASCII文字の‘Ｄ’，‘Ｔ’，‘Ａ’及び‘ ’ を収容する。転送の第５バイトは、最初のデータバイトである。ブロックのエン ドまでデータが継続する。 呼び出し：END 戻 り ：AOK又はERR コメント：現ファイル伝送のエンドをマークする。前のFIL，ATR及びDTAコマン ドによって命名されたファイルが成功裏に送られた。 呼び出し：ABT 戻 り ：AOK又はERR コメント：現ファイル転送をアボートする。このポイントに送られた全ての情報 が転送エージェントによって廃棄される。 加入者／DSPプロトコル 加入者コントローラによって制御されることができるDSPには、“Ｎ”ユニッ トが（概念的に）存在する。全ての通信が、加入者コントローラ／DSPインタフ ェースを横断して発生しなければならない。論理的に、「ユニット」は、加入者 コントローラによってアクセスされることができるDSP機能である。これらのユ ニットは、加入者コントローラからのメッセージを受入れ、かつ、加入者コント ローラに送られるメッセージを生成する。ユニットの１例はデコーダ０であり、 他の例はデコーダ１であり、また更なる他の例は入力衛星データである。加入者 コントローラは、所与のユニットへメッセージを送り、そのユニットの作動を制 御する。加入者コントローラのVxDドライバは、DSPのユニットを加入者コントロ ーラ内に「反映」し、加入者コントローラの所与の処理がこれらのユニットに アクセスする。当該プロトコルは、加入者コントローラとDSPとの間で任意のバ イト列を移動せしめるように設計されている。当該プロトコルを実現するために 使用されるハードウェアに関して作られたいくつかの仮定が存在する。これらの 仮定は、以下のとおりである： １．加入者コントローラ／DSPリンクは、全二重である。加入者コントローラ とDSPとの間のパスは、２つの分離したパスからなる。加入者コントローラは、D SPが加入者コントローラにデータを送るのと同時に、DSPにデータを送ることが できる。 ２．DSPは、常に、加入者コントローラからのメッセージを受け入れることが できる。加入者コントローラがDSPにメッセージを送ることを望むとき、その仮 定は、直ちに受け入れることができるということである。加入者コントローラは 、DSPがそれを受け入れるのに「長い時間をとる」ことがないという仮定の下で 、メッセージを送ろうと試みるドライバ内で時間を費やす（加入者コントローラ 上の割り込みはそのままであるが）。しかし、加入者コントローラは、加入者コ ントローラからDSPへのデータバッファへオーバライトしないように、「ホストF IFOビジー」ビットを尊重する。 ３．加入者コントローラは、“Ｉ”ビットがクリアされる限り、DSPにホスト ベクトルを送ることができる。DSPソフトウェアは、“Ｉ”ビット（ホストベク トルビジー）がセットされない限りいつでもホストベクトルを受け入れる。さら に、DSPは、長時間“Ｉ”ビットをセットされたままにしない（上記仮定＃２の 変形）。 ４．加入者コントローラ／DSP通信チャネルは、エラーフリーである。加入者 コントローラとDSPとの間には、エラー検出及び訂正が存在しない。この仮定は 、加入者コントローラバックプレーンがエラーフリーであるということである。 加入者コントローラからDSPへ及びDSPから加入者コントローラヘ送られた各メ ッセージは、同一の３つの基本的部分を含む。 １．ユニットメンバー：これは、メッセージの「デスティネーション」の数で ある。「ユニット」の正確な意味は、異なるドライバの機能である。加入者コン トローラにおいては、例えば、ユニットは、１以上の加入者コントローラスレッ ドの通信を制御するＣ++オブジェクトである。DSPにおいては、ユニットは、DSP における所与のバッファ又は機能に対するレファレンスになる。ユニット数は、 メッセージの「アドレス」になる可能性がある。 ２．長さ：これは、メッセージを構成するバイトの数である。 ３．データ：これは、メッセージの実際の内容である。 リンクの加入者コントローラとリンクのDSPサイドとの双方において、メッセ ージを管理するために使用される２つの原始的なオペレーション、すなわちリー ド及びライトが存在する。通信論理の全てが、加入者コントローラ及びDSPの双 方についてのこれら２つのルーチンに収容される。リードルーチン及びライトル ーチンの現オペレーションは、DMAを使用せずにデータを伝送することである。 付加的に、伝送されているメッセージバッファのサイズに依存することなく、DM Aを使用することを選択することができる複雑なルーチンを書くことができる。 DACクラス VxDドライバは、数個の異なるDACカードをサポートしなければならない。この 理由のために、DACクラスが定義される。VxDドライバを何時ロードするかは、何 個のDACカードインスタンスを作る必要があるか、およびIRQ(および、その後DMA )割り当てが何であるかを決定するために、SYSTEM.INTファイルを調べる必要が ある。DACクラスのアウトラインは次の通りである： DACクラスの基本的機能は、VxDからパスされたIOCTL要求を処理することであ る。VxD中のIOCTLハンドラはリング３からパスされた制御コードを調べ、何をす べきかを決定する。制御コードの上位８ビットは、誰がIOCTLを処理するかを決 定する。0ｘ00から0ｘ03の値は、システム上の第１から第４のDACカードを選択 する（我々は一般に４個のDACカードのみをサポートするであろう）。OｘFFの上 位バイトはVxDドライバそれ自身を選択する。ドライバは引き数をアンパックし 、DACクラスの適正なインスタンスを呼び出す。VxD”OnW32DeviceIoControl”の アウトラインは以下の通りである： この構造は、DACクラスに、自身が所有する個々のユニット上に送信されたメ ッセージに関してIOCTLコードが何を意味するかを見出させる。DACのその他のメ ンバーの機能は、”HardwareInterrupt”を除いては、単純である。問題は、VxD がDSPから割り込みを受けることである。これは、DACクラスインスタンスと関連 付けられる必要がある。これは次のようにする事によって実行される： DACインスタンスが形成されると、ステートメント Irq＝new CardIRQ(IrqNum，this)； によってIrqメンバー機能を初期化する。 ところで、割り込みが在った場合、特定化されたIRQのためのハンドラーが呼 び出される。このハンドラーは、そのプライベートな”Mycard”メンバー変数と して、その割り込みが属するDACインスタンスへのポインターを有する。ハンド ラーが成す全ては： である。 これによって、DACクラスの正しいインスタンスに対して、適正なハードウエ ア割り込みルーチンが呼び出される。（Ｃ++で書かれた）PCプロトコルの操作に 対するキイは、“ユニット”クラスの定義である。PCおよびDSP間の異なるタイ プの通信は、そのコードにおいて同一である部分が大きいが、しかし同様に送信 された情報のタイプに依存する部分を持つことが予想される。例えば、PCが衛星 情報を受信すると、リング３が情報要求を処理するまで、それをバッファしてお く必要がある。しかしながら、入力光アイソレータの現在の状態をバッファする 必要はなく、単に記憶するだけで良い。ユニットベースクラスから異なるクラス を導出することによって、これらの固有の機能は容易に達成できる。DACクラス がそのコンストラクタへの呼出しによって始まると、それはユニットクラスの全 てのインスタンスを形成し、それらをユニットテーブル中に記憶する。同様に、 DACクラスが削除されると、ユニットテーブル（アレイ）中を歩き回り、各メン バーを削除する。このユニットクラスは以下のように見える： 種々の部分の機能は以下の通りである： ユニット−クラスの１インスタンスを形成する。引き数（アーギュメント）は “ユニット番号”であって、これらはPCからDSPに送られた全てのメッセージ上 で、およびこのユニットを“所有する”DACクラスのインスタンス上で使用され る。このインスタンスは、このユニットのインスタンスによってカードチャンネ ルへの専用アクセスを獲得するために使用される。 〜ユニット−クリーンアップルーチン。VxDはダイナミックにロード可能であ るので、それがアンロードされると、ルーチンはこのユニットによって使用され たリソースをクリーンアップする。 リード−対応するDSPユニットからメッセージを読み取る。この機能は、メッ セージが入手可能と成るまでスレッド呼出しをブロックする。更に、もしスレッ ド待機が無い場合にメッセージが受信されると、そのメッセージはバッファされ 、記憶され、あるいは特定のユニット定義に因っては放棄される。 ライト−対応するDSPユニットにメッセージを書き込む。 ロック−所定のスレッドがユニットをロックすることを許可し、それによって 第２のスレッド介入無しにライト／リード対操作を実行することを可能とする。 アンロック−スレッドがユニットを手放すことを許可する。 フラッシュ−ユニットに対して受信されかつバッファされた全てのメッセージ を放棄する。 割り込み−ニットに対して特注された割り込み機能。この機能は割り込み時 間においてユニット特定コードが実行されることを許可する。 リードセマ(ReadSema)−DSPの対応するユニットからの入力に対してスレッド 待機を制御するために使用される、セマフォ(Semaphore)。 ユニットセマ(UnitSema)−ユニットのロックを制御するために使用されるセマ フォ。 クラスDaxSemaphoreは、Vsemaphoreが供給しない幾つかの付加的な特徴を提供 する“リアル Vx”セマフォの回りの“ラッパー(wrapper)”である事に注意する 必要がある。それが提供する最も重要な特徴の一つは、DaxSemaphoreオブジェク トが削除された場合に待機タスクを開放する方法である。これは、タスクがセマ フォを待っている場合であっても、整然としたシャットダウン（の試み）を許可 する。ライト(Write)機能によって、スレッドはDSPへのアクセスを待ち、一旦そ れが獲得されると、メッセージをdspに書き込みDSPを開放する。ライト操作が出 力ループにおいて“スタック”しないことを保証するために、タイムアウトを使 用する必要のある事に注意すべきである。DSPがそれへの書き込みを行っている 間に不足する事があり、その結果“生きビット(busy bit)”はアップし、これに よってスレッドはドライバ中でハングすることがあることに注意すべきである。 ライトループを中止する方法を見いだすことは素晴らしいことである（タイマー ？我々がDSPを待つ時間をカウントする？）。 ユニットの“リード”マフォをブロックするルーチン。このアイデアは、ここ では、ユニット上でスタックした各“バッファ”に対してリードセマフォを増分 することである。これらのバッファは、ユニットの“データ”メンバーからスレ ッドオフ（リンクされたリスト？）される。 注意：上記コードにおいて、幾つかの微妙な（かつあまり微妙でない）理由か ら、割り込みはオフ状態とされる： １．ユニット上のデータバッファリストは、リストが割り込みサービスルーチ ンによって変更されないことを保証する割り込みサービスルーチンによって、ク リティカル領域を形成する。単にDSP割り込みをマスクする事によって、これと 同じ結果を達成することが可能である。これは全ての他の割り込みをオンのまま とするが（良いことである）、しかし... ２．割り込みをオフ状態とすることによって、別のスレッドがこのリードルー チン中に入り込みこのスレッドを追い越さないことを保証する。この場合：リス ト上には２個のバッファがある。割り込みシステム(CLI)をオフ状態とする代わ りに、我々はIRQを単にマスクする。我々がセマフォチェックを送ると、割り込 み量(quantum interrupt)が終わりになり、別のスレッドが実行される。このス レッドはまたリードを呼出し、セマフォを送り出しさらにその後我々が第１のス レッドにおいて半分を有したバッファを獲得する。両方のスレッドがそのバッフ ァを有していると考えるため、バッファキューは混乱する（夜間において一方が 遅いことを見いだそうと試みる）。 ロックルーチンは、スレッドがユニットを保持していることを保証するのみで ある。スレッドはユニットのセマフォとDSPのセマフォを得ようとすることに注 意すべきである。デッドロックに対するチャンスがここにある。保護のために、 次の様なロック／アンロックシーケンスを実行する： Lock( )； //ユニットを保持 Read/write Requests( )； //DSPをロック／アンロックする Unlock( )； //ユニットをアンロックする このロックユニット、ロックdsp、アンロックdsp、アンロックユニットシーケ ンスは、デッドロックが無いことを保証する。 これは割り込みルーチンである。ここでの仮定は即ち： １．我々が２回目のISVに入るようにDSPが強要しないための予防を割り込みハ ンドラにおいて我々が取るかぎりにおいて、割り込みシステムがオン状態となる ことが許可でき、さらに... ２．セマフォ“信号”ルーチンは、実際、割り込み時間において呼出し可能で ある。 もし上記＃２が真で無い場合、その後のコードはとにかくグローバルイベント に設定されるべきであり、その後そのイベントから呼び出される。コードがユニ ットのメンバー機能であると言う事実によって、これは幾分複雑となる。我々は 、このユニットのポインタをグローバルイベントのハンドラに送る必要がある（ これは、ユニットポインタに対するコンストラクタ中の１個の場所を含む、グロ ーバルイベントのサブクラスを定義し、その後ポインタを導出されたハンドラ機 能中のプライベートな変数中に記憶することによって行われるー-）。次のコー ドはDacクラスの一部分であり、ハードウエア割り込みが所定のカードに対して 受信された場合、呼び出される。これがどの様にして起きるかは、“Dacクラス ”のセクションを参照されたい。このコードは割り込み時間において呼び出され 、以下を実行する： １．DSPからの更なる割り込みを禁止する。 ２．DSPからメッセージが在るか否かを見るためにチェックする。もし無い場 合、次にDSP割り込みを可能とし（次のメッセージの準備において）、そして出 る。 ３．もしメッセージがあれば、DSPからユニット番号を読み出す（使用するユ ニットのインデックス）。さらに、ユニットの割り込み機能を呼び出す。 これはそのユニットクラスの“デフォルト”割り込みプロセッサである。これ はDSP中にまだ存在する“長さ”ワードによって呼び出される。そのジョブは： １．DSPからのデータを入れる場所を割り当てる。 ２．データをバッファ中にコピーする。 ３．ユニットバッファキュー上にバッファをスレッドする。 ４．バッファがそれによってセマフォを定義する信号待機スレッド DSPプロトコル このセクションでは、DSPのためのプロトコルの実行について議論する。この 設計は、Ｃ−ライク擬似コードによって表現される。DSPにおいて、ユニットは 、バッファのリンクされたリストを表す実際のデータ構造である。DSPは異なる ユニットに対してバッファの異なるタイプを維持する。例えば、デコーダユニッ トは、MUSICAMフレームの特定数を保持するに十分な大きさのバッファを維持す る。各バッファは次の様なものである： DSPにおいて数個のキイルーチンが存在する。これらは writePC−このルーチンはバッファを要し、PCへの書き込みを開始する。 WriteInt−これはPCルーチンへの書き込みの半分の割り込みである。これは、 DSPのデータポートからのワードをPCがロードする毎に割り込みを介して呼び出 される。 ReadPC−受信メッセージルーチン。PCがNEW＿MESSAGEホスト割り込みを送信す る場合、このルーチンに入る。 ReadInt−これはリードPCルーチンの半分の割り込みである。PCがDSPのデータ ポートに書き込む毎に割り込みを介して呼び出される。 PCInt−このルーチンはPC割り込みを生成するためおよびPC割り込みを禁止す るために呼び出される。キイとなる仮定は以下の通りである：もしPCがPICチッ プをマスクさせ(DSP IRQに対して割り込みを禁止する)かつDSPがPC中への割り込 みを主張すると(PCInt(ON))、PICチップが次にアンマスクされた時この割り込み が発生する。 追加の仮定は、PCがDSPデータバッファ中にワードを挿入した時に発生する割 り込みは、禁止され得ることである。更にPCがDSPデータバッファからワードを 除去した時発生する割り込みもまた、禁止され得ることである。 ライトPC writePCおよびWriteIntルーチンは同時に働く。このルーチンのための擬似コ ードは以下の通りである： TransferInProgress=FALSE； struct buf^*SendList=0； WritePCルーチンはPCにメッセージを送るために使用される。メッセージはそ れらが受信された状態でSendList中で待機させられる。 WriteIntルーチンはワードがDSP出力バッファから取り出される毎に呼び出さ れる。 リードPC ReadPCとReadIntのルーチンは共にPCからデータを得てDSPへ入力する動作をす る。PCからメッセージを受け取ったとき、定められたユニットになるためのメッ セージのリストが並べられる。DSPの状況では、“ユニット”は実際には同じユ ニット番号の付いた受け取られたメッセージのリストである。PCがメッセージを DSPへ送りたいとき、それはNEW MESSAGEホスト割り込み（host interrupt）を 送出する。このことによってメッセージがReadIntルーチンによってDSPに読み込 まれるようになる。メッセージバッファは適切なユニットで列が作られる。ユニ ットはその後マスタールーチン（master routine）によって得られ、メッセージ はそれによって処理される。この処理によって応答が発生する。これらの応答は WritePCルーチンを経由して送られる。 メッセージ（Message） このセクションではDSPとPCとの間を通る各メッセージについて議論する。メ ッセージは２つの一般的なカテゴリーに分類される。 １．肯定応答（Acknowledged）これらのメッセージは応答が必要である。例え ば、デコーダの状態をリクエストするメッセージは、デコーダからの応答（状態 ）が必要である。このようなトランザクション（transactions）はリクエストメ ッセージと応答メッセージとの対になる。肯定応答メッセージは“書き出し／読 み込み”型ユニットへのみ送られる。 ２．否定応答（Unacknowledged）これらのメッセージは送られるが、応答は期 待されない。 肯定応答メッセージの問題は、それを送るスレッドは、スレッド（thread）が 応答を待ち受けている間、他のスレッドが通信チャンネルを使わないことを保証 するということである。この理由は、メッセージとそれらの応答が適切にシーケ ンスされることを保証するために、Unit::Lock( )とUnit::Unlock( )のルーチン の呼び出しをスレッドは全てしなければならないからである。リクエストのため に応答が生成されたとき、該応答はオリジナルのリクエストの場合と同じメッセ ージ番号を使う。たとえば、もしREAD OPTICALメッセージがDACに送られたなら 、それはREAD OPTICALがそのメッセージ番号であるように応答する。 ユニット割り付け（Unit Assignments） 潜在的に、いずれのユニットもPCとDSPとの間の双方向通信をサポートできる 。実現を簡単化するために、どのような方法でも、ユニットは３つの違った方法 でのみ利用される。 １．読み出し専用(read only):これらのユニットのタイプでは、DSPからPCへ 各メッセージを伝送するのに使われる。読み出し専用ユニット（read only unit ）の例としては、“衛星データ(Satellite data)”ユニットがある。衛星から衛 星データを受け取ったときDSPはそれをこのユニットへ書き込む。PCは衛星デー タユニットへはメッセージを決して書き込まない。 ２．書き込み専用（Write only）：これらのユニットのタイプでは、PCからDS Pへ各メッセージを伝送するのに使われる。DSPはこれらのユニットにわたってPC に情報を決して送らない。このユニットのタイプの例としては“コントロール” ユニットがある。 ３．書き込み／読み出し（Write/Read）：これらのタイプのユニットは、PCか らDSPへ情報を伝達することとDSPから戻ってくる情報を受け取ることに使われる 。“ラド光学的入力(rad optical inputs)”ユニットはこのタイプのユニットの 例である。書き込み／読み出しユニットに対して、PCはメッセージをDSPへ書き 込み、その後PCはDSPの応答に対する待ち受けをブロックする。 ユニットのタイプ（読み出し専用、書き込み専用、書き込み読み出し）を知る ことによって、ユニットを実現するために使われる導き出されたクラスが、ユニ ットがシステムコードから適切に呼び出されることを保証するようなエラーチェ ック（例えば、書き込み専用ユニットの読み込みルーチンがエラーをひっかける こと）を実行することが許される。以下のユニットはDAXプロトコルとして定義 される。“読み出しと書き込み”の指示はPCの斜視図（例えば、読み出し専用は PCがユニットからのみ読み出すことを意味する）に関係することに注意する。 コントロール−〔Unit ♯0、書き込み専用〕コントロールユニットはPCからDS Pへ応答の必要のない全メッセージを送るのに使われる。 イベント−〔unit #1、読み出し専用〕DSPからPCへのイベントメッセージ（Ev ent messages）はイベントユニット（Event unit）へ書き込まれる。PCはイベン トメッセージを待ち受けるためにこのユニットを読み込む。 補助データ（Ancillary Data）−〔unit #2、読み出し専用〕デコーダからの あらゆる補助データはこのユニットに書き込まれる。 衛星データ（Sat Data）−〔unit #3、読み出し専用〕受け取られた衛星の情 報(MUSICAM記録とコマンド記録)はこのユニットで読み出される。 光学的入力(Optical input)−〔Unit #4、書き込み／読み出し〕PCはカードの 光学的入力のステートをリクエストでき、このユニットからの応答を読み出すこ とができる。 デコーダ・ステート（Decorder State）−〔Unit #5、書き込み／読み出し〕P Cはカードのデコーダのステートをリクエストでき、このユニットからの応答を 読み出すことができる。 リクエストオーディオ(Request Audio)−〔Unit #6、読み出し専用〕このユニ ットにわたってより多くのオーディオを得るようにDSPはPCにリクエストを送る 。 ユニット割り付けの原理は次の通りである。 １．もしメッセージが応答を持たなければ、それをコントロールユニットに割 り付ける。このことはコントロールメッセージは別のスレッドによって応答に対 する待ち受けがブロックされないことを保証する。 ２．もしメッセージが応答を必要とするならば、それを自身のユニットに割り 付ける。このことはそれら自身で応答に応対しているスレッドを待ち受けること がブロックされないことを保証する。 ３．DSPが非同期に生成するあらゆるメッセージは、それ自身のユニットに割 り付けられる。 PCからDACへのメッセージ このセクションは、PCからDACへ送られるすべてのメッセージを含む。それは 各メッセージにユニット割り付けを供給する。任意に各バイトは２つの方法のう ち１つで送られる。 １．できるだけタイトに各バイトをパックする。このことは各バイトを転送す るためにDSPが応答しなければならない割り込みの数を最大限に利用するが、し かしそれによってDSPが受け取った各バイトをアンパックすることが必要となる 。 ２．オリジナルのサイズに関係なく24ビット語として全ての引き数を送る。こ のことによってDSPがより簡単にアンパックのジョブ(unpacking job)ができるよ うになるが、しかし、転送されるバイト数は著しく増加する。最大のバイト数は MUSICAMフレームあるいは受け取られた衛星の情報として送られる。これらは完 全にパックされた24バイト語として送られる。 どのようにしてデータを送るかについての決定を遅らせるために、“メッセー ジクラス(message class)”は以下のサービス(services)を提供するよう定義さ れる。 メッセージクラスは実際のメッセージのフォーマットをカプセルに入れる(enc apsulate)。それはより上位レベルのルーチンから呼び出され、メッセージバッ ファを構成するのに使われる。前記バッファはその後カードへ送られる。しかし ながら、これら全てが与えられると、各メッセージ、データの長さと引数は、ユ ニークにそれであると識別するためのメッセージ番号を持たなければならない。衛星データ選択スイッチをセット ユニット（Unit）：コントロール、ユニット＃０ 引き数（Argument）：スイッチポジションコード(１バイト) 応答（Response）：なし コメント：スイッチの各ポジションは次の表に示される。 これらの値のみ有効である点に注意する。 スイッチポジションの他のあらゆる値は無効である。局アドレスをセット ユニット：コントロール、ユニット＃０ 引数：局アドレス値（２バイト） 応答：なし コメント：16ビットの引数は局アドレスとして使用される。局をグループに加える ユニット：コントロール、ユニット＃０ 引き数：局を加えるグループの番号（２バイト) 応答：なし コメント：局を特定のグループに加える。本システムには最大512の全く異なっ たグループがあり得る。すべてのブートアップ(boot up)の後は、DACのカ ードはどのグループの番号でもない。引き数の下位９ビットだけ試験され る。もし局がすでに特定のグループの番号であれば、そのときはリクエス トは無視される。局をグループから取り除く ユニット：コントロール、ユニット＃０ 引き数：局が取り除かれるグループの番号(２バイト) 応答：なし コメント：局を特定のグループから取り除く。引数の下位９ビットだけグループ 番号を決定するのに使用される。もし局が特定のグループの番号でなけれ ば、呼び出しは無視される。光学的入力を読み出す ユニット：光学的入力、ユニット＃４ 引き数：引き数なし 応答：下位４ビットの光学的入力の値（１バイト） コメント：これは光学的入力の値を読み出す。リレイのコントロール ユニット：コントロール、ユニット＃０ 引き数：上位ニブル(nibble)はリレイ番号（０−３）下位二ブルは次の表から得 られる動作である。（１バイト） パルス継続時間（MS）。もしパルス動作がないならば、０にセットする。（２ バイト）応答：なし コメント：セグメント情報をロードする ユニット：コントロール、ユニット＃０ 引き数：以下の引数はメッセージの順に示される。 １．セグメントID．これはセグメントを識別するためにDSPが使用できるユニ ークな番号である。（２バイト） ２．デコーダ：このセグメントをどのデコーダにロードするか。これは０ある いは１のいずれかである。（１バイト） ３．スタートフェード（Start Fade）：セグメントの再生を開始するとき使わ れるフェードパターンの番号。０のパターン番号はフェードしないことを意味す る。（１バイト） ４．エンドフェード（End Fade）：セグメントの再生が終了するとき使われる フェード・パターンの番号。０のパターン番号はフェードしないことを意味する 。（１バイト） ５．マーカー１ポジション(Marker 1 Position)．セグメントのスタートから のフレームのマーカー１の位置。ボジションはセグメントの終わりを越えること ができない点に注意。０という値はマーカー１が存在しないことを意味する。（ ３バイト） ６．マーカー２ポジション(Marker 2 Position)．マーカー１と同じ定義。（ ３バイト） ７．スタートオピニオン：セグメントがプレイを開始するイベント。値は以下 から得られる。（１バイト） ０：PCからのスタートコマンド １：本チャンネルにおける前のセグメントの終わり ２：別のチャンネルにおける最も新しくロードされたセグメントの終わり ３．別のチャンネルにおける最も新しくロードされたセグメントのマーカー ＃１ ４．別のチャンネルにおける最も新しくロードされたセグメントのマーカー ＃２ ８．イベント信号次の状態の下のPCに対してイベントを生成する。各値は１つ 以上のイベントを生成するために結合されることに注意する。（１バイト） ９．ミュート（mute）するフレーム時間の番号。もしゼロでないならば、これ は時間ミュートを生成する疑似セグメントである。（３バイト） 応答：なし コメント：DSPは、セグメントIDに基づいて再生するためのデータリクエストす る割り込みリクエストを生成し、そのリクエストはデータに対応するセグ メントIDに基づいて行われる。セグメントプレイスタックをリセット ユニット：コントロール、ユニット＃０ 引き数：リセットするデコーダの番号（１バイト） １：デコーダ−０ ２：デコーダ−１ ３：両デコーダ 応答：なし コメント：もしデコーダがプレイしているのならば、そのときははじめにストッ プし、その後リセットする。デコーダ・プレイ ユニット：コントロール、ユニット＃０ 引き数：プレイを開始するデコーダの番号（１バイト） １：デコーダ−０ ２：デコーダ−１ ３：両デコーダ 応答：なし コメント：デコーダをストップする ユニット：コントロール、ユニット＃０ 引き数：プレイをストップするデコーダの番号（１バイト） １：デコーダ−０ ２：デコーダ−１ ３：両デコーダ 応答：なし コメント：ライブ レイ（live lay）を開始する ユニット：コントロール、ユニット＃０ 引き数：なし 応答：なし コメント：セレクタスイッチに接続されたデコーダがライブ再生を開始する。デコーダステート(decoder state)を得る ユニット：デコーダステート、ユニット＃５ 引き数：興味のあるデコーダの番号（１バイト） １：デコーダ−０ ２：デコーダ−１ 応答：３つの値 １．デコーダのステート：これは０：ストップ、１：プレイ、２：ライブプレ イ（１バイト） ２．プレイされているセグメント番号。もしステートが０（ストップ）あるい は２（ライブ動作）ならば、０という値が戻される。（１バイト） ３．プレイされているフレーム番号。もしデコーダがストップさせられている のなら戻り値は０。（３バイト）デコーダゲインのセット ユニット：コントロール、ユニット＃０ 引数：デコーダ番号（１バイト） ０：デコーダ−０ １：デコーダ−１ ２；両デコーダの同時のゲイン変更。 ゲインレベル（２バイト） レスポンス：なし コメント：特定のデコーダに対するゲインレベルの変更。ミュージカム(MUSICAM)データ ユニット：コントロール、ユニット＃０ 引き数：データをプレイするデコーダ番号。これは０又は１となる。送られるフ レームの数（０は、セグメント中にフレームが存在しないことを意味する）。 MUSICAMフォーマットされたフレームの全数。 レスポンス：なし コメント：このメッセージは、DSPの「オーディオデータのリクエスト」に応答 して送られる。 DACからPCへのメッセージ このセクションは、DACがPCに送ることができるメッセージを概説する。オーディオデータのリクエスト ユニット：オーディオのリクエスト、ユニット＃６ 引き数：セグメント番号（１バイト） デコーダ番号（１バイト） DSPが受入れ可能なMUSICMフレームの最大数（２バイト） レスポンス：後でPCは新たなデータと共にMUSICAMデータメッセージを送る（リ クエストに対する厳密なレスポンスでない、即ち、DSPはレスポンスを 持たない）。 コメント：DSPは、もっとMUSICAMデータが必要であると感じたときは、このリク エストを送る。衛星データ ユニット：衛星データ、ユニット＃３ 引き数：衛星からのデータ。これはバイトのシーケンスである。 レスポンス：なし コメント：衛星データのレシーバは、そのデータの意味を理解する。DSPはデー タと同期し、データが特定のDACカードにアドレスされるように決定す るに十分なヘッダを認識ずる。データのフォーマットは後日決定される 。イベントデータ ユニット：イベント、ユニット＃１ 引き数：イベントメッセージ。各メッセージは同一フォーマットを有する。各メ ッセージ中に送られたイベントの全体の数がある。 レスポンス：なし コメント：イベントメッセージは以下のようにフォーマットされる： １．デバイスID（１バイト）。これはイベントのソースを識別する。現在定義 されたデバイスは： ０：デコーダ−０ １：デコーダ−１ ２：光学的絶縁体 ２．イベントID（１バイト）。これはイベントのタイプを識別する。現在定義 されたタイプは： ０：セグメントの終わり。データはオーディオのセグメント番号である。 １：プレイされたマーカ＃１。データはオーディオのセグメント番号であ る。 ２：プレイされたマーカ＃２。データはオーディオのセグメント番号であ る。 ３：光学的絶緑体の変更。データは絶緑体の現在のセッティングである。 ３．データ値（３バイト）。データの内容はイベントに依存する。補助データ ユニット：補助データ、ユニット＃２ 引き数：補助データはパケット化される。各パケットは、２バイトのヘッダを有 し、これにデータが続く。この２バイトのヘッダは： １．データが来たデコーダの番号。 ２．ヘッダに続くデータのバイト数。 レスポンス：なし コメント：光学的入力の読み取り ユニット：光入力、ユニット＃４ 引き数：４ビットの低い順位の現在の光学的入力値（１バイト） レスポンス：なし コメント：このメッセージは、PCからの「読み取り光入力メッセージ」に応答し てDSPにより送られる。デコーダ状態の獲得 ユニット：デコーダ状態、ユニット＃５ 引き数：３つの値： １：デコーダの状態：これは０：停止、１：プレイ、２：プレイ中のライ ブ。（１バイト） ２：プレイされるセグメント番号。状態が０（停止）又は２（プレイ中の ライブ）であれば、値が０に戻される。（１バイト） ３：フレーム番号は、プレイされているものである。デコーダが停止する と、戻る値は０である。（３バイト） レスポンス：なし コメント：このメッセージは、PCにより送られる「デコーダ状態の獲得メッセー ジ」に応答してDSPにより送られる。 動作要件 このセクションは、加入者端末により提供される動作機能について説明する。 本システムにより配信され、管理されるオーディオは、４つの異なるタイプがあ る。 １．地域スポットを含む記録された番組(ショー) ２．地域スポットを含むライブショー ３．地域スポットを含む遅延プレイショー ４．コマーシャルと他のオーディオ 加入者端末は、各タイプのオーディオの受入れ、準備、プレイ及びプレイの認 証を許可するフィーチャーを提供する。以下のセクションは、これらのオーディ オタイプとそれぞれの管理に対しでシステムが供給するフィーチャーを説明する 。オーディオタイプの各々は、現在のところ無限に契約されているビジネスの商 品を表す。このビジネスの詳細及び関連する課題は、付録Ａに紹介されている。 オーディオタイプの各タイプに提供されるフィーチャーを理解するキーは、プレ イリストの構造を理解することである。プレイリストは次のセクションで説明さ れる。 プレイリスト及びイベント 加入者端末は、オーディオの個々の部分をプレイする能力があるが、これはめ ったに実行されない。オーディオの単純なプレイを生み出す単一のアプリケーシ ョンは、配信されたコマーシャルがカートテープにダビングされた時である。通 常、加入者端末はプレイリストの制御のもとでオーディオを連続してプレイする 。プレイリストはオーディオイベントの順番付けたシーケンスである。オーディ オイベントは、他のオーディオイベントが発生する前に完了するようにプレイす るオーディオのシーケンスである。ラジオはオーディオイベントの管理である。 各オーディオイベントは、潜在的なユーザに興味を持たせる５つの特性である： １．イベントのクラス（内部／外部） ２．開始トリガ ３．終了信号 ４．アウトキュー ５．イベント期間 これらのうち、最初の３つは、イべントのユーザにより特定されても良いが、 最後の２つは与えられたオーディオイベントに関連する本質的な特性である。 イベントクラス 〔MEx DAX-加入者〕端末は２つのイベントクラスを提供する： １．内部。内部イベントは、〔DAX-加入者〕端末それ自身内に発生するもので ある。これらは、例えば、〔DAX-加入者〕端末内に蓄積されたケーシー、カッサ ムのトップ40ショーのセグメント、又はコマーシャルである。 ２．外部。外部イベントは、〔DAX-加入者〕端末の外部で発生されるものであ る。これらは、例えば、カートマシン上にあるコマーシャル、その時間の最初 にニュースを読むライブアナウンサー、又はステーションコールレターサウンダ である。 開始トリガ プレイリスト上の各イベントは、イベントの開始をさせるトリガを有すると言 える。〔DAX-加入者〕端末は以下のトリガをサポートする： １．接触閉止。接触閉止(contact closure)によりトリガされるイベントは、 〔DAX-加入者〕端末で閉止が受信されたときにプレイを開始する。 ２．疑似的な接触閉止。これは、１つのプレイリストが他のプレイリストの実 行を開始させることを許可する内部ソフトウエア信号である。これは、第１に、 ライブオーディオがプレイリストにストアされた他のオーディオイベントをカッ トできるようにするために使用される。 ３．先行イベント終了(PET)。PETイベントトリガは、オーディオイベントを、 それに先行するイベントに直ちに従わせる。これは、中止又は外部入力なしに１ つのイベントから他への流れをもたらす。 異なるイベントトリガを有するプレイリスト中の多数のイベントを有すること は、豊かな演算フィーチャーセットをもたらす。例えば、接触閉止に続いて３つ のコマーシャルが連続してプレイバックされることを仮定する。このプレイリス トは、オーディオイベント１（第１のコマーシャル）が２つのイベントがPETト リガされる間に閉止トリガされるためにセットアップされる。さらに、最初の２ つのイベントは、第３が接触閉止の終了を発生するように選択される間に、終了 信号を発生させない。この結果は、閉止がコマーシャルのプレイを開始させるこ とであり、各コマーシャルが連続してプレイをし、そして接触閉止はコマーシャ ルセットの完了を表示するため活性化される。 終了信号 オーディオイベントが実行されるとき、オプションとして、完了信号を発生で きる。完了信号は以下にリストされた２つのタイプがある。いずれか又は両方の 終了信号は、いくつかの与えられたオーディオイベントのために特定される： １．接触閉止。これは、オーディオイベントが完了したときに、特定の接触を 閉じる結果となる。 ２．疑似的な接触閉止。これは、停止されたプレイリストの再開に使用できる ソフトウエア表示である。 ユーザレコードイベント MExフィーチャーリスト中に最初に提供されることが予定されていなかったと しても、加入局がそれ自身のオーディオイベントを記録できない理由はない。こ の能力を与えると、外部イベントであるものを内部イベントへ変換することが可 能となる。最終的な結果は、局をより自動化する。それは、外部局と相互作用な しに、最初から最後までショーをプレイさせることを可能とする。 プレイリスト 全てのリクエストされたMEx機能は適切に構成されたオーディオイベントのリ ストにより獲得される。このようなリストは、MExプレイリストと呼ばれる。以 下のセクションはプレイリスト管理の有利な点からMExシステムの種々の要求を 説明する。プレイリストはDAX端末内のいくつかの異なる状態中に存在すること ができるということを注意されたい。これらの状態は： １．休止(dormant)。休止リストは、生成されるが、現在どのオーディオ出力 へも指定されていないリストである。このリストは聴取できるがプレイはされな い。 ２．活動(active)。活動プレイリストは、所定のオーディオ出力が指定された リストである。いくつかの活動プレイリストがあり、そこでは、各活動プレイリ ストに対する現在のオーディオイベントは異なるトリガを持たなければならない 。 ３．プレ(playing)イ。所定の出力オーディオポートに関連するただ１つの活 動プレイリストは直ちにプレイされる。 地域スポットを含む記録された番組 地域スポットを含む記録された番組(ショー)は、実際には、オーディオファイ ルの集積であり、単一の活動プレイリストである。最初に、MExは、局地に有効 なスポットに対して外部オーディオイベントをサポートするのみである。言い換 えると、局地コマーシャルは局のカートマシン上にある。MExは、以下のシーケ ンスを使用して記録されたショーを配信する： １．ヘッドエンドシステムは、MExアドレス配信を使用して、指定された局に 地域コマーシャルを配信する。コマーシャルは、関連するショー中の位置のため に名付けられる。例えば、「トップ40スポット12」。 ２．ヘッドエンドシステムは、ショーイベントを配信する。各コンポーネント は、「トップ40セグメント15」のような特有の名前を有する。 ３．ヘッドエンドシステムは、プレイリストを配信する。プレイリストは、局 地に有効なスポットとともに、セグメントとコマーシャルを連続させる。 以下のものは、プレイリストの例である： イベント１ トップ40セグメント１ イベント２ トップ40スポット１ イベント３ トップ40スポット２ イベント４ ローカルスポット イベント５ トップ40セグメント２ イベント６ トップ40スポット３ イベント７ ローカルスポット イベント８ トップ40セグメント３ このシステムは、イベント１に接触閉止をトリガさせるためセットアップされ る。これはショーのプレイを開始する。イベント２とイベント３は、先行するイ ベントの終了でトリガされる。これは、イベント１からイベント２、イベント３ へと円滑に流れさせる。イベント３はその終了信号として接触閉止を有する。こ れは、局地スポットの開始を意味し、イベント４を開始させる局自動化システム へのインターフェースに使用される。イベント５は、イベント４により表示され る局地に有効なスポットの終りを表示する接触閉止をトリガする。DAX端末にダ ウンロードされる特定のファイルと共に、プレイリストは、その局に対するフォ ーマットされたシートを作成するために要求される全てのものである。加入局マ ネージャが試験又はプリントアウトできるフォーマットは、プレイリスト及びコ ンポーネントオーディオファイルから発展させることができる。各オーディオイ ベントがそれに関連する期間とアウトキューを有するわけではない。これは、（ 局地化されたコマーシャルからの異なるアウトキューにより）局地化が各局にお いて異なるフォーマットの結果となったとしても、各ショーのためのフォーマッ トの内部発生を許可する。 請求の範囲 １．データ配信システムであって、 衛星と、 データファイル及びアドレス情報を収納するエンベロープを生成するための生 成サブシステムと、 前記衛星が前記エンベロープを中継するように前記衛星に前記エンベロープを 送信するためのアップリンクトランスミッタと、 前記衛星からエンベロープを受け、加入者サブシステムへアドレスされたエン ベロープからデータファイルをストアするための、少なくとも１つの加入者サブ システムであって、アドレス情報に基づいてアドレスされたエンベロープを識別 し、ストアされたデータファイル読み取り、前記データファイルに収納されたイ ンストラクションに基づいて前記データファイルを処理する加入者サブシステム と、 を具備するデータ配信システム。 ２．前記生成サブシステムが、エンコードされたオーディオデータを収納する データファイルと、オーディオファイルにストアされたオーディオセグメントと 関連した属性を収納するカートファイルと、オーディオプログラムでプレイされ るオーディオセグメントのリストを識別してカートファイルのリストを収納する プレイリストファイルと、を生成する請求項１に記載のデータ配信システム。 ３．生成サブシステムから離れた１つ又はそれ以上の所定のテールエンドユー ザグループに、前記生成サブシステムから少なくともオーディオ情報を送信する 方法であって、前記方法は、 ａ．第１の生成サブシステムで少なくとも第１のアナログオーディオ信号 を受信し、かつ第２の生成サブシステムで少なくとも第２のアナログオーディオ 信号を受信し、 ｂ．前記第１及び第２のオーディオ信号を、ロッシイ形オーディオ情報の 第１及び第２のロッシイ形符号化ファイルを生成するために、単一のロッシイ形 圧縮アルゴリズムと共にデジタルで符号化し、 ｃ．前記第１のロッシイ形符号化ファイルを使用するために第１のテール エンドユーザ装置の第１のグループを決定し、かつ前記第２のロッシイ形符号化 ファイルを使用するために第２のテールエンドユーザ装置の第２のグループを決 定し、 ｄ．前記テールエンドユーザ装置の前記第１及び第２のグループへ、前記 第１及び第２のロッシイ形符号化ファイルをハブにより自動的に転送するために 、前記第１及び第２の生成サブシステムからハブへ、ロッシイ形符号化ファイル を自動的に送信し、そして、 ｅ．前記テールエンドユーザ装置の前記第１及び第２のグループで前記第 １及び第２のロッシイ形符号化ファイルを受信し、復号化し、再生放送し、かつ 前記復号化では、前記単一のロッシイ形符号化アルゴリズムで符号化された前記 ロッシイ形符号化ファイルを復号化するために復号化アルゴリズムを使用する、 各段階を具備するオーディオ情報を送信する方法。 ４．生成サブシステムから離れた１つ又はそれ以上の所定のテールエンドユー ザグループに、前記生成サブシステムから少なくともオーディオ情報を送信する 方法であって、前記方法は、 ａ．前記生成サブシステムで第１のアナログオーディオ信号を受信し、 ｂ．前記第１のアナログオーディオ信号を、ロッシイ形オーディオ情報の ロッシイ形符号化ファイルを生成するために、単一のロッシイ形圧縮アルゴリズ ムと共にデジタルで符号化し、 ｃ．テールエンドユーザ装置グループの中の選択されたエンドユーザ装置 が前記ロッシイ形符号化ファイルを受信し使用するように選択し、 ｄ．選択されたテールエンドユーザ装置の各々に対して、ロッシイ形圧縮 デジタルファイルを衛星リンク又は他のリンクを経て送信するかどうか決定し、 ｅ．選択されたテールエンドユーザ装置の各々に対して、各々決定された リンクを経て各々選択されたテールエンドユーザ装置へ、ロッシイ形符号化ファ イルを自動的に送信し、そして、 ｆ．前記選択されたエンドユーザ装置においてのみオンデマンドで前記ロ ッシイ形符号化ファイルを連続的に復号化し使用するために、前記選択されたテ ールエンドユーザ装置で前記ロッシイ形符号化を受信し格納し、かつ前記復号化 では、前記単一のロッシイ形符号化アルゴリズムで符号化された前記ロッシイ形 符号化ファイルを復号化するために復号化アルゴリズムを使用する、 各段階を具備するオーディオ情報を送信する方法。 ５．生成サブシステムから離れた１つ又はそれ以上の所定のテールエンドユー ザグループに、前記生成サブシステムから少なくともオーディオ情報を送信する 方法であって、前記方法は、 ａ．前記生成サブシステムで第１のアナログオーディオ信号を受信し、 ｂ．前記第１のアナログオーディオ信号を、ロッシイ形オーディオ情報の 第１のロッシイ形符号化ファイルを生成するために、単一のロッシイ形圧縮アル ゴリズムと共にデジタルで符号化し、 ｃ．プレイリストを含む非オーディオ情報の個別のデータファイルを生成 し、 ｄ．前記テールエンドユーザ装置グループの中の選択されたテールエンド ユーザ装置が前記第１のロッシイ形符号化ファイルと前記データファイルを受信 し使用するように決定し、 ｅ．前記生成サブシステムから大気圏外の衛星を経て決定されたテールエ ンドユーザ装置へ、第１のロッシイ形符号化ファイル及びデータファイルを自動 的に送信し、 ｆ．前記決定されたテールエンドユーザ装置で、第１のロッシイ形符号化 ファイル及びデータファイルを、オンデマンド又はプレイリストにて前記決定さ れたテールエンドユーザ装置によってのみ、ロッシイ形符号化ファイルを連続的 に復号化し使用するために、さらなるロッシイ形圧縮や、ロッシイ形デコンプレ ッションや、又は第１のロッシイ形符号化ファイルでロッシイ形オーディオ情報 を編集することなく、自動的に受信し、格納し、かつ前記復号化では、前記単一 のロッシイ形符号化アルゴリズムで符号化された前記第１のロッシイ形符号化フ ァイルを復号化するために復号化アルゴリズムを使用する、 各段階を具備するオーディオ情報を送信する方法。 ６．生成サブシステムから離れた１つ又はそれ以上の所定のテールエンドユー ザグループに、前記生成サブシステムから少なくともオーディオ情報を送信する 方法であって、前記方法は、 ａ．前記生成サブシステムで第１のアナログオーディオ信号を受信し、 ｂ．前記第１のアナログオーディオ信号を、ロッシイ形オーディオ情報の 第１のロッシイ形符号化ファイルを生成するために、単一のロッシイ形圧縮アル ゴリズムと共にデジタルで符号化し、 ｃ．前記第１のロッシイ形符号化ファイルと関連するプレイリストを含む 非オーディオ情報の個別のデータファイルを生成し、 ｄ．前記テールエンドユーザ装置グループの中の選択されたテールエンド ユーザ装置が前記第１のロッシイ形符号化ファイルと前記データファイルを受信 し使用するように決定し、 ｅ．前記第１のロッシイ形圧縮デジタルファイル及び関連データファイル を、選択されたテールエンドユーザ装置へ、衛星リンク又は他のリンクを経て、 送信するかを自動的に決定し、 ｆ．前記第１のロッシイ形符号化ファイル及び関連データファイルを選択 されたテールエンドユーザ装置へ、決定されたリンクを経て送信し、 ｇ．前記選択されたテール・エンドユーザ装置で、第１のロッシイ形符号 化ファイル及び関連データファイルを、オンデマンドにて前記選択されたテール エンドユーザ装置によってのみ、前記データファイルを連続的に使用しロッシイ 形符号化ファイルを連続的に復号化し使用するために、自動的に受信し、格納し 、かつ前記復号化では、前記単一のロッシイ形符号化アルゴリズムで符号化され た前記第１のロッシイ形符号化ファイルを復号化するために復号化アルゴリズム を使用する、 各段階を具備するオーディオ情報を送信する方法。 ７．生成サブシステムから離れた１つ又はそれ以上の所定のテールエンドユー ザグループに、前記生成サブシステムから少なくともオーディオ情報を送信する 方法であって、前記方法は、 ａ．前記生成サブシステムで第１及び第２のアナログオーディオ信号を受 信し、 ｂ．前記第１及び第２ののアナログオーディオ信号を、オーディオ情報の 第１及び第２の符号化ファイルを生成するために、単一のル圧縮アルゴリズムと 共にデジタルで符号化し、 ｃ．テールエンドユーザグループの中から１つ又はそれ以上のテールエン ドユーザを決定し、前記第１及び第２の符号化ファイルを復号化し再生するため に、デジタルの符号化指令をエンドユーザ装置へ発生し、 ｄ．前記第１及び第２の符号化ファイル及び符号化プレイリストを、多重 化データストリームに自動的に多重化し、 ｅ．前記多重化データストリームを決定されたテールエンドユーザ装置へ 、大気圏外衛星を経て自動的に送信し、 ｆ．テールエンドユーザ装置において自動的に格納し、符号化インストラ クションにより符号化ファイルを連続的で自動的に復号化し使用するために、符 号化ファイル及び符号化プレイリストを含む出力を提供するように、多重化され 送信されたデータストリーム及び多重分離されたデータストリームを受信する、 各段階を具備するオーディオ情報を送信する方法。 ８．請求項３の方法において、（１）前記送信段階（ｄ）は、さらなるロッシ イ形圧縮がなく、ロッシイ形デコンプレッションもなく、又はロッシイ形符号化 ファイルでのロッシイ形オーディオ情報を編集することなく発生する段階を含み 、（２）前記送信段階は、前記ロッシイ形符号化ファイルと共にオーディオデー タストリームを自動的に多重化し送信することにより、ライブの符号化オーディ オデータストリームを送信する段階を含み、（３）前記受信段階（ｅ）は、テー ルエンドユーザ装置によりオーディオデータストリームのライブな復号化及び使 用のために、受信した多重化オーディオデータストリーム及びロッシイ形符号化 ファイルを自動的に多重分離する段階を含む。 ９．請求項４の方法において、（１）前記送信段階（ｅ）は、さらなるロッシ イ形圧縮がなく、ロッシイ形デコンプレッションもなく、又はロッシイ形符号化 ファイルでのロッシイ形オーディオ情報を編集することなく発生する段階を含み 、（２）前記送信段階は、前記ロッシイ形符号化ファイルと共にオーディオデー タストリームを自動的に多重化し送信することにより、ライブの符号化オーディ オデータストリームを送信する段階を含み、（３）前記受信段階（ｆ）は、テー ルエンドユーザ装置によりオーディオデータストリームのライブな復号化及び使 用のために、受信した多重化オーディオデータストリーム及びロッシイ形符号化 ファイルを自動的に多重分離する段階を含む。 １０．請求項５の方法において、（１）前記送信段階（ｅ）は、さらなるロッ シイ形圧縮がなく、ロッシイ形デコンプレッションもなく、又はロッシイ形符号 化ファイルでのロッシイ形オーディオ情報を編集することなく発生する段階を含 み、（２）前記送信段階は、前記ロッシイ形符号化ファイル及びデータファイル と共にオーディオデータストリームを自動的に多重化することにより、ライブの 符号化オーディオデータストリームを送信する段階を含み、（３）前記受信段階 （ｆ）は、テールエンドユーザ装置によりオーディオデータストリームのライブ な復号化及び使用のために、受信した多重化オーディオデータストリーム及びロ ッシイ形符号化ファイルを自動的に多重分離する段階を含む。 １１．請求項６の方法において、（１）前記送信段階（ｆ）は、さらなるロッ シイ形圧縮がなく、ロッシイ形デコンプレッションもなく、又はロッシイ形符号 化ファイルでのロッシイ形オーディオ情報を編集することなく発生する段階を含 み、（２）前記送信段階は、前記ロッシイ形符号化ファイル及びデータファイル と共にオーディオデータストリームを自動的に多重化することにより、ライブの 符号化オーディオデータストリームを送信する段階を含み、（３）前記受信段階 （ｇ）は、テールエンドユーザ装置によりオーディオデータストリームのライブ な復号化及び使用のために、受信した多重化オーディオデータストリーム、ロッ シイ形符号化ファイル及びデータファイルの自動的な多重分離を含む。 １２．請求項７の方法において、（１）前記送信段階（ｅ）は、さらなるロッ シイ形圧縮がなく、ロッシイ形デコンプレッションもなく、又はロッシイ形符号 化ファイルでのロッシイ形オーディオ情報を編集することなく発生する段階を含 み、（２）前記送信段階は、前記ロッシイ形符号化ファイルと共にオーディオデ ータストリームを多重化することにより、ライブの符号化オーディオデータスト リームを自動送信する段階を含み、（３）前記受信段階（ｆ）は、テールエンド ユーザ装置によりオーディオデータストリームのライブな復号化及び使用のため に、受信した多重化オーディオデータストリーム及びロッシイ形符号化ファイル を自動的に多重分離する段階を含む。 １３．ヘッドエンドから離れた１つ又はそれ以上の所定のテールエンドユーザ グループに、前記ヘッドエンドから少なくともオーディオ情報を送信する方法で あって、前記方法は、 ａ．生成サブシステムで第１のアナログオーディオ信号を受信し、 ｂ．ロッシイ形オーディオ情報のロッシイ形復号化ファイルを生成するた めに、単一のロッシイ形圧縮アルゴリズムと共にオーディオ信号をデジタルで符 号化し、 ｃ．テールエンドユーザの中のから１つ又はそれ以上のテールエンドユー ザを決定し、 ｄ．前記ヘッドエンドから所定のテールエンドユーザ装置へロッシイ形符 号化ファイルを送信し、 ｅ．前記所定のテールエンドユーザ装置によってのみオンデマンドで前記 ロッシイ形符号化ファイルを連続的に復号化し使用するために、前記ロッシイ形 符号化ファイルを受信し格納し、かつ復号化では、前記単一のロッシイ形符号化 アルゴリズムで符号化された前記ロッシイ形符号化ファイルを復号化するために 復号化アルゴリズムを使用し、 ｆ．前記所定のテールエンドユーザ装置により発生された再生ブロードキ ャストに、スポットセグメントを局部的に格納し自動的に挿入する、 各段階を具備するオーディオ情報を送信する方法。 １４．請求項１３の方法において、前記送信段階（ｄ）は、さらなるロッシイ 形圧縮がなく、ロッシイ形デコンプレッションもなく、又はロッシイ形符号化フ ァイルでのロッシイ形オーディオ情報を編集することなく、大気圏外の衛星を経 て送信する段階を含む。 １５．請求項１４の方法において、前記送信段階（ｄ）は、大気圏外の衛星を 経て、又は他のリンクを経て送信するかどうかを決定し、前記決定されたリンク を経て送信する段階を含む。 １６．請求項１５の方法において、前記デジタル符号化段階（ｂ）は、段階（ ｄ）におけるロッシイ形符号化ファイルと共にデータを送信するために、及び段 階（ｅ）におけるロッシイ形符号化ファイルと共にデータファィルを受信するた めに、非オーディオデータファイルを作成し前記ロッシイ形符号化ファイルとデ ータファイルとを束ねる段階を含む。 １７．請求項４の方法において、前記方法は、復号化ファイルを再生し、テー ルエンドユーザ装置で第２のオーディオファイルの再生と共に復号化ファイルの 再生を自動的にクロスフェージングする段階を含む。 １８．請求項５の方法において、前記送信段階（ｅ）は、さらなるロッシイ形 圧縮がなく、ロッシイ形デコンプレッションもなく、又はロッシイ形符号化ファ イルでのロッシイ形オーディオ情報を編集することなく発生する段階を含み、そ して、前記方法は、復号化ファイルを再生し、テールエンドユーザ装置で第２の オーディオファイルの再生と共に復号化ファイルの再生を自動的にクロスフェー ジングする段階を含む。 １９．請求項６の方法において、前記送信段階（ｅ）及び受信及び格納段階（ ｆ）は、さらなるロッシイ形圧縮がなく、ロッシイ形デコンプレッションもなく 、又はロッシイ形符号化ファイルでのロッシイ形オーディオ情報を編集すること なく発生する段階を含み、そして、前記方法は、復号化ファイルを再生し、テー ルエンドユーザ装置で第２のオーディオファイルの再生と共に復号化ファイルの 再生を自動的にクロスフェージングする段階を含む。 ２０．請求項７，８，９，１０，１１又は１２の方法において、復号化ファイ ルを再生し、テールエンドユーザ装置で第２のオーディオファイルの再生と共に 復号化ファイルの再生を自動的にクロスフェージングする段階を含む。 ２１．請求項１３，１４，１５又は１６の方法において、テールエンドユーザ 装置にて再生ブロードキャストの間に、スポットセグメント再生と共に復号化フ ァイルの再生を自動的にクロスフェージングする段階を含む。 ２２．請求項５，６，１０，１１，１４，１８，１９又は２０の方法において 、段階（ａ）は生成サブシステムもしくはヘッドエンドで第２のアナログオーデ ィオ信号を受信する段階を含み、段階（ｂ）はロッシイ形オーディオ情報の第２ のロッシイ形符号化ファイルを発生するために、単一のロッシイ形圧縮アルゴリ ズムと共に第２のオーディオ信号をデジタルで符号化する段階を含み、段階（ｃ ）はプレイリストをデータファイルに合体する段階を含み、段階（ｄ）はデータ ファイルにそって第１及び第２のロッシイ形符号化ファイルを送信する段階を含 み、そして段階（ｆ）は所定のテールエンドユーザ装置で第１及び第２のロッシ イ形符号化ファイルを受信し格納し、プレイリストにおけるインストラクション に従って符号化ファイルを使用する段階を含む。 ２３．請求項３，４，５，６，７，８，９，１０又は１１の方法において、送 信段階（ｄ）はロッシイ形符号化ファイルと関連して接点閉路情報を送信する段 階を含み、受信段階（ｅ）は前記接点閉路情報で具体化されたテールエンドユー ザへのインストラクションに従って、ロッシイ形符号化ファイルを使用するため に、デマンドを自動的に起動する段階を含む。 ２４．請求項１３又は１４の方法において、送信段階（ｄ）はロッシイ形符号 化ファイルと関連して接点閉路情報を送信する段階を含み、受信段階（ｅ）は前 記接点閉路情報で具体化されたインストラクションに従って、ロッシイ形符号化 ファイルを使用するために、デマンドを自動的に起動する段階を含み、段階（ｅ ）は前記接点閉路情報で具体化されたインストラクションに従って、挿入を自動 的に起動する段階を含む。 ２５．請求項１５，１６，１７，１８，１９，２０又は２２の方法において、 送信段階（ｅ）はロッシイ形符号化ファイルと関連して接点閉路情報を送信する 段階を含み、受信段階（ｆ）は前記接点閉路情報で具体化されたテールエンドユ ーザへのインストラクションに従って、ロッシイ形符号化ファイルを使用するた めに、デマンドを自動的に起動する段階を含む。 ２６．請求項３乃至１５，２０，２１，２２，２３又は２５の方法において、 送信段階（ｄ）は符号化ファイルを最初に中央のハブに送信し、次に前記ハブに より供される所定のエンドユーザ装置に送信する段階を含む。

───────────────────────────────────────────────────── フロントページの続き (51)Int.Cl.⁷ 識別記号 ＦＩ テーマコート゛(参考） Ｈ０４Ｌ 27/00 Ｈ０４Ｌ 27/00 Ｚ (81)指定国 ＥＰ(ＡＴ，ＢＥ，ＣＨ，ＤＥ， ＤＫ，ＥＳ，ＦＩ，ＦＲ，ＧＢ，ＧＲ，ＩＥ，ＩＴ，Ｌ Ｕ，ＭＣ，ＮＬ，ＰＴ，ＳＥ)，ＯＡ(ＢＦ，ＢＪ，ＣＦ ，ＣＧ，ＣＩ，ＣＭ，ＧＡ，ＧＮ，ＭＬ，ＭＲ，ＮＥ， ＳＮ，ＴＤ，ＴＧ)，ＡＰ(ＫＥ，ＬＳ，ＭＷ，ＳＤ，Ｓ Ｚ，ＵＧ)，ＥＡ(ＡＭ，ＡＺ，ＢＹ，ＫＧ，ＫＺ，ＭＤ ，ＲＵ，ＴＪ，ＴＭ)，ＡＬ，ＡＭ，ＡＴ，ＡＵ，ＡＺ ，ＢＢ，ＢＧ，ＢＲ，ＢＹ，ＣＡ，ＣＨ，ＣＮ，ＣＵ， ＣＺ，ＤＥ，ＤＫ，ＥＥ，ＥＳ，ＦＩ，ＧＢ，ＧＥ，Ｈ Ｕ，ＩＬ，ＩＳ，ＪＰ，ＫＥ，ＫＧ，ＫＰ，ＫＲ，ＫＺ ，ＬＫ，ＬＲ，ＬＳ，ＬＴ，ＬＵ，ＬＶ，ＭＤ，ＭＧ， ＭＮ，ＭＷ，ＭＸ，ＮＯ，ＮＺ，ＰＬ，ＰＴ，ＲＯ，Ｒ Ｕ，ＳＤ，ＳＥ，ＳＧ，ＳＩ，ＳＫ，ＴＪ，ＴＭ，ＴＴ ，ＵＡ，ＵＧ，ＵＳ，ＵＺ，ＶＮ 【要約の続き】 ム（14）は、ライブオーディオ及び関連コンタクトディ スクロージャー情報を加入者端末（16）に送信すること ができる。加入者端末（16）はユーザーサイトに設ける ことができる。加入者端末（16）は、これらのイベント をハードドライブに格納し、イベントをリアルタイムで プレイし、又は他の加入省端末（16）に転送することが できる。加入者端末（16）は、格納されたイベントを後 でプレイすることができる。

Claims (1)

1. 【特許請求の範囲】 １．衛星と、 データファイル及びアドレス情報を収納するエンベロープを生成するための生 成サブシステムと、 前記衛星が前記エンベロープを伝達するために前記エンベロープを前記衛星に 送るアップリンクトランスミッタと、 前記衛星からエンベロープを受け、前記加入者サブシステムへアドレスされた エンベロープからデータファイルをストアするための、少なくとも１つの加入者 サブシステムであって、前記アドレス情報に基づいてそこにアドレスされたエン ベロープを識別し、ストアされたデータファイル読み取り、そして、前記データ ファイルに収納されたインストラクションに基づいて前記データファイルを処理 する加入者サブシステムと を具備するデータ配信システム。 ２．前記生成サブシステムがエンコードされたオーディオデータを収納するデ ータファイルを生成し、カートが、前記オーディオファイルにストアされたオー ディオセグメントと関連した属性を収納してファイルし、そして、カートのリス トを収納するプレイリストファイルがオーディオプログラムでプレイされるオー ディオセグメントのリストを識別してファイルすることを特徴とする請求項１に 記載のデータ配信システム。