JP4270868B2 - オーディオ信号の符号化 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、ユーザに提供するためのデジタル符号化されたマテリアルの通信リンクによる配信に関する。
【０００２】
【従来の技術】
明細書および図面の記載は、本出願と同日出願であるＧＢ００３０７０６．６号を優先権の基礎とする国際特許出願［発明の名称「オーディオ信号および、またはビデオマテリアルの配信」］の記載と同様である。
【０００３】
【発明が解決しようとする課題】
本発明は、オーディオ信号を符号化する方法を提供する。
【０００４】
【課題を解決するための手段】
本発明の１特徴によれば、概念的に入力信号を時間的に連続している時間的部分に分割し、
前記入力された時間的部分を第１のフレーム長を有する第１の符号化アルゴリズムを使用して符号化して、符号化された時間的部分の第１の符号化されたシーケンスを生成し、
前記入力された時間的部分を第２のフレーム長を使用して符号化して、符号化された時間的部分の第２のシーケンスを生成し、
符号化ステップの少なくとも１つは、先行する時間的部分の終り、および、またはすぐ後に続く時間的部分の最初と共に１つの入力された時間的部分を符号化して前記時間的部分により整数のフレームを構成するオーディオ信号の符号化方法が提供される。
【０００５】
本発明の別の特徴によれば、第１のフレーム長を有する第１の符号化アルゴリズムによって入力信号の連続する第１の時間的部分のそれぞれを符号化し、それらの時間的部分は前記第１のフレーム長の整数に対応し、第１の符号化されたシーケンスを生成するために連続するか、オーバーラップし、第２のフレーム長を有する第２の符号化アルゴリズムによって入力信号の連続する第２の時間的部分のそれぞれを符号化し、それらの時間的部分は前記第２のフレーム長の整数に対応し、前記第１のフレーム長の整数には対応せず、第２の符号化されたシーケンスを生成するためにオーバーラップし、第２の符号化されたシーケンスの各オーバーラップしている部分は少なくとも部分的に間の境界を含み、或いは入力信号の連続する時間的部分に対応する第１の符号化されたシーケンスの間またはオーバーラップした領域部分を含んでいるオーディオ信号を符号化する方法が提供される。
【０００６】
その他の本願発明の特徴はその他の従属する請求項に記載されている。
【０００７】
【発明の実施の形態】
図面を参照にして本発明のいくつかの実施形態を説明する。
図１に示されたシステムは、デジタル符号化されたオーディオ信号を通信ネットワークを介して対応する音響がユーザに対して再生されるユーザ端末へ配信することを目的としている。しかしながら、以下詳細に説明するように、このシステムはオーディオ信号の代りに、或いはオーディオ信号に付加してビデオ信号を伝送するために使用することもできる。この例では、ネットワークは、原理的には他のデジタルリンクまたはネットワークを使用することが可能であるが、ハイパーテキスト転送プロトコル（詳細はＲＦＣ1945/2068 参照）にしたがって動作するインターネットまたは他のパケットネットワークである。オーディオ信号はＩＳＯ ＭＰＥＧ−１層III 標準方式（ＭＰ３標準方式）を使用する圧縮された形態で記録されていると仮定する。しかしながら、この特定のフォーマットの使用は本質的なことではない。事実、特に利用できるビットレートが制限され、或いは記憶スペースが限定されている場合には圧縮の使用は非常に望ましいことであるが、本質的に必要なことではない。図１ではサーバ1 はインターネット2 を介して１つしか示されていないユーザ端末3 に接続されている。サーバ1 の機能はデータファイルを記憶し、所望のデータファイルの配信のためのリクエストをユーザ端末から受信し、リクエストに応答してそのファイルをネットワークを介してユーザ端末に送信することである。通常そのようなリクエストはネットワーク配信機構（例えば、ハイパーテキスト転送プロトコルまたはファイル転送プロトコルに対してはそれぞれhttp：//またはファイル：//）を指示する第１の部分の形態を取り、それに続いてサーバのネットワークアドレス（例えばｗｗｗサーバ１.com）が付加され、さらにそれに続いてリクエストされているファイル名を付けられている。与えられた例ではそのような名称はタイプ上の理由で//で示されている。
【０００８】
これらの例では、ハイパーテキスト転送プロトコルを使用するものと仮定し、これは本質的なことではないが、そのプロトコルによって与えられた承認およびセキュリティ特徴（秘密ソケット層のような）の使用ができる利点がある。
【０００９】
通常ＭＰ３ファイルの受渡し用のサーバはいわゆるストリーマの形態をとり、それはユーザ端末での応答要求に応じてデータが送信される速度をダイナミックに制御し、パケット損失によるエラーをマスクし、ユーザの介入が許容されている場合にはサーバとクライアントとの間のデータ流を制御する処理装置を含んでいる。しかしながら、ここではサーバ1 はそのような設備を含んでいない。したがって、それは通常の“ウエブサーバ”である。
【００１０】
データファイルがサーバ1 に記憶される方法について説明する。ＭＰ３フォーマットのファイルが生成されてサーバに記憶されると考える。それはＪ．Ｓ．バッハのトッカータとフーガＤ短調（ＢＷＶ565 ）の記録であり、典型的に９分の演奏時間を有する。元来これは単一のデータファイルとして生成され、通常のストリーマではこれは１つの単一のファイルとして記憶される。しかしながら、ここではファイルはサーバ1 に記憶される前に小さいファイルに分割される。これらの小さいファイルはそれぞれ固定された演奏時間、恐らく４秒に対応する大きさである。ＭＰ３のような圧縮されたフォーマットにより、これはそれらのファイルが実際に含んでいるビットの数に対して異なった大きさであることを意味している。したがって９分の期間のバッハのファイルはそれぞれ４秒の演奏時間の１３５の小さいファイルに分割される。この例ではこれらは所定のファイル名を与えられ、それはもとのファイル中のそれらの順序を示す通し番号を含んでおり、例えば、

【００１１】
ファイルのこれらの小さいサブファイルへの分割は典型的にウエブサーバ1 へロードするためのファイルを処理する人によって行われることができる（ここで使用されるサブファイルという用語は、全体の記録を含んでいるもとのファイルと区別するためにここで使用されているが、しかしながらサーバが関係される限りサブファイルは他のファイルと同様のファイルであることを強調しておく）。それらを生成する正確な方法について以下さらに十分に説明する。これらのサブファイルは、一度生成されると、任意の他のファイルがウエブサーバへロードされる通常の方法でサーバにアップロードされる。もちろんファイル名は特定の記録を識別する文字を含むことができる（ＭＰ３ファイルを再生するときサブファイルは著者、著作権等の情報を得る付加的な情報のタグを付けられることもできる）が、この例ではサブファイルはサーバ中で特定の記録、例えばｍｐ３ ｂｗｖ５６５に特定された名簿またはホルダー中に記憶される。したがってサブファイルは必要なとき次の形態でリクエストされることができる。
【００１２】
http：//ｗｗｗサーバ1 ．com/mp3 ｂｗｖ565/000003．ビン
ここで“ｗｗｗサーバ1 ．com ”はサーバ1 のＵＲＬである。
【００１３】
それはまた、各記録に対してリンクページ（典型的にはｈｔｍフォーマットで）を生成するためにサーバにロードするためのサブファイルを処理する人に対して都合がよい。このリンクページもまたサーバに記憶され（恐らくファイルネームｍｐ３ ｂｗｖ565/ｌｉｎｋ．ｈｔｍにより）、その構造および目的については後述する。
【００１４】
また、対応するリンクページに対するハイパーリンクを有する利用可能な記録のリストを含む１以上の（ｈｔｍｌ）メニューページ（例えばｍｅｎｕ．ｈｔｍ）を記憶することも都合のよいことである。
【００１５】
次に、端末について説明すると、これは典型的に通常のデスクトップコンピュータの形態のものでよいが、前述したオーディオファイルの受信を処理するための付加的なソフトウエアを有している。所望ならば端末は、手持ち形コンピュータの形態をとることができ、移動体電話機中に内蔵されてもよい。したがって、図２はそのような端末を示し、それは中央プロセッサ30、メモリ31、ディスク記憶装置32、キーボード33、ビデオディスプレイ34、通信インターフェース35、オーディオインターフェース（音響カード）36を備えている。ビデオ配信のためには、音響カード36の代りに或いはそれに追加してビデオカードが使用される。ディスク記憶装置32には通常の方法でプロセッサ30により実行されるためにメモリ中で検索されることのできるプログラムが記憶されている。これらのプログラムは呼出しおよびｈｔｍページの表示のための通信プログラム37、すなわちNetscape NavigatorまたはMicrosoft Explorerのような“ウエブブラウザ”プログラムおよび本発明のこの実施形態にしたがってオーディオファイルの再生のために必要な機能性を与えるここで“プレイヤープログラム”と呼ばれているような別のプログラム38を含んでいる。また、メモリ31の39で示される領域はバッファとして割当てられている。これは再生されるために待機しているデータを含む復調されたオーディオバッファである（典型的にバッファの動作継続時間は１０秒である）。オーディオインターフェースまたは音響カード36は通常のカードであり、単にＰＣＭオーディオ信号を受信してそれをアナログオーディオ信号に変換するように、例えばスピーカにより再生するように機能する。最初に、ＨＴＴＰおよび内蔵またはプラグインされたクライアント装置を使用するとき、所望の記録を検索して再生する端末装置の動作の概要について簡単に説明する。
【００１６】
１．ユーザはブラウザを使用してサーバ1 からメニューページｍｅｎｕ．ｈｔｍを検索して表示する。
【００１７】
２．ユーザはメニューページ内のハイパーリンクの１つを選択し、それはブラウザにサーバを検索させ、この例ではファイルｍｐ３ ｂｗｖ565 ｌｉｎｋ．ｈｔｍのような所望の記録に対するリンクページを表示させる。このページの実際の表示は重要ではない（恐らくそれがシステムが正確に動作していることをユーザに再確認させるメッセージを含んでいることを除いて）。このページで重要なことは、プレイヤープログラム37が実行される第２のプロセスをプロセッサ30に開始させる命令（または埋設タグ）を含むことである。この方法における第２のプロセスの開始は実際によく知られている（そのようなプロセスはプラグインとしてＮｅｔｓｃａｐｅシステムで、また、“アクチブＸ”としてマイクロソフトシステムで知られている）。このような命令はまた第２のプロセスに送られるパラメータを含むこともでき、図１のシステムで命令は記録のサーバＵＲＬを含んでおり、それはバッハのチピースに対してｈｔｔｐ//ｗｗｗ．サーバ1/ｍｐ３ ｂｗｖ565 である。
【００１８】
３．プレイヤープログラム37はＭＰ３デコーダを含み、その動作自体は通常のものである。この説明でさらに重要なことはプログラムの制御機能であり、それについて以下説明する。
【００１９】
４．ＵＲＬを受信したプレイヤープログラムはこれに第１のサブファイルのファイルネームを付加してサブファイルに対する完全なアドレスを生成する。すなわち、ｗｗｗ．サーバ1/ｍｐ３ ｂｗｖ565/000000．ｂｉｎを生成する。サブファイルが上に示した方法で名前を付けられことに基づいて、このシステムが組織化されることが観察され、その結果端末はファイルネームを報告する必要がない。このプログラムはこのＵＲＬを有するファイルに対するリクエストメッセージを構成し、それを通信インターフェース35およびインターネット2 を介してサーバ1 に送信する（ＵＲＬをＩＰアドレスに変換するプロセス、無効のエラー報告、不完全または利用できないＵＲＬは通常のものであり、ここでは説明しない）。プレイヤープログラムはブラウザを介するのではなく、直接通信インターフェースにリクエストを送信することが予想される。サーバはリクエストされたサブファイルを送信することによって応答する。
【００２０】
５．プレイヤープログラムはファイルからこのサブファイル中で使用されたオーディオ符号化を決定し、関係した標準方式にしたがって（この例ではＭＰ３）粗ＰＣＭ値にファイルをデコードして戻し、このサブファイルの演奏時間のノートを作成する。一般にオーディオファイルは使用された符号化を説明するファイルの最初における識別子を含んでいる。デコードされたオーディオデータはその後オーディオバッファ38に記憶される。
【００２１】
６．プレイヤープログラムは演奏終了時間Ｔ_p と呼ばれるパラメータを有している。この例ではそれは１０秒に設定されている（所望ならばユーザ選択可能にされることができる）。それは端末が行なうバッファの程度を決定する。
【００２２】
７．プレイヤープログラムはファイルネームを000001.binへインクリメントし、リクエストし、受信し、デコードして上記の（４）および（５）で記載したように第２のサブファイルを記憶する。このプロセスはバッファの内容がこの演奏終了時間Ｔ_p に到達するか、それを越えるまで反復される。デコードがバッファの前に行なわれることは実際には重要なことではないが、簡単になることに注意すべきである。それはオーディオはデコードされて粗ＰＣＭに戻され、その後、バッファされたマテリアルの継続時間は明瞭に知られるからである。各サブファイルが同じオーディオ再生サイズであるならばオーディオバッファの制御は簡単にされる。
【００２３】
８．演奏終了時間Ｔ_p に到達したとき、デコードされたデータはバッファからオーディオインターフェース36に送られ、それはスピーカ（図示せず）によって音を再生する。
【００２４】
９．上記（８）で音が再生される一方で、プレイヤープログラムは連続的にバッファの満杯状態について監視し、これがＴ_p より小さくなったときファイルネームを再びインクリメントしてサーバからさらに別のサブファイルを得る。このプロセスは“ファイルはエラーを発見しない”が戻されるまで反復される。
【００２５】
１０．このプロセス中にバッファが空になった場合には、プレイヤープログラムはさらにデータが到着するまで演奏を停止する。
【００２６】
ここで使用される０で開始される数字の簡単な固定長のシーケンスのサブファイルネーミングは構成が簡単であるので好ましいが、任意の他のネーミング方法が第１のサブファイルのネームおよび連続する１を計算することを可能にするアルゴリズムのいずれかを含むか（または送信される）プレイヤープログラムを与えるために或いはファイルネームのリストを送信するために使用することができる。
【００２７】
上述のシステムはユーザの再生プロセスに介入するための機会を何等提供しないことが認められるであろう。また、バッファのアンダーフロー（例えばネットワークの衝突によって）の可能性に対しても何等救済しない。それ故、第２のさらに精巧なこの発明の実施形態について以下説明し、それはさらに次のような特徴を提供する。
【００２８】
ａ）サーバは異なった圧縮率で記録された記録の２以上のバージョンを記憶し［例えば、それぞれ、8 ,16, 24, 32 キロビット／秒の（連続的な）データレートに対応する圧縮率で］、プレイヤープログラムは自動的にそれらの間で切換えることができる。
【００２９】
ｂ）プレイヤープログラムはユーザに対して制御パネルを表示し、それによりユーザは再生を開始し、それを中断し、それを再開し（最初から、或いは中止した点から）、または記録中の異なる点（後方または前方）にジャンプすることが可能になる。
【００３０】
これらの特徴は相互依存性ではなく、ユーザ制御はレートスイッチングなしに或いはその反対に行われることができる。
【００３１】
レートスイッチングを行なうために、サーバにロードするためにファイルを処理する人は、異なったレートで複数回同じＰＣＭファイルを符号化することによって幾つかのソースファイルを処理する。彼は各ソースファイルを前述したようにサブファイルに区分する。これらは異なったレートに対応する別々のディレクトリ（登録簿）でサーバにロードされる。例えば、次の例の構成ではディレクトリネーム中の“008k”“024k”は８キロビット／秒または２４キロビット／秒等のレートを示している。
【００３２】
彼はまたインデックスファイル（例えばindex.htm ）を生成し、その主目的は利用可能なデータレートのリストを提供することである。
【００３３】
【表１】

サブファイルの長さは前に説明したように固定された時間長に対応しているから、サブファイルの数は各ディレクトリに対して同じである。サブディレクトリネームはキロビット／秒のデータレート（３デジット）プラス文字“ｋ”を含んでおり、この例ではオーディオサンプリングレート（11.025kHz ）の指示であって、モノとステレオのフラグが確認のために付加されている。
【００３４】
インデックスファイルはしたがって次のような形態のステートメントを含む。
【００３５】
＜！オーディオ信号＝“024k 11 s 032k 11 s 018k 11 s 016k 11 m 018k 11 m ”…＞
（＜！…... …＞は単にステートメントがｈｔｍｌファイル中のコメント［または簡単なテキストファイルが使用可能である］として埋設されていることを示している。）典型的なインデックスファイルは図３に示されており、それには他の情報が含まれている。すなわち、ＬＦＩは最高のサブファイル数（すなわち４５のサブファイル）であり、ＳＬは全体の再生時間である（１７８秒）。“モード”は“記録された（ここで）”または“ライブ（以下説明する）”を示している。他のエントリは自明であり、或いは標準的なｈｔｍｌコマンドである。
【００３６】
最初に、プレイヤープログラムはリンクファイル、インデックスファイルで特定されたディレクトリからのリクエストにより開始し、将来の基準のために利用可能なデータレートのリストを局部的に記憶する。（このファイルまたは丁度特定したディレクトリの明瞭なリクエストであってもよく、大抵のサーバはファイルネームが特定されていなければindex.htm にデフォルトである。）。その後、インデックスファイル−viz.024k 11 s （または端末はその端末に局部的に設定されたデフォルトレートにこれに修正することによってこれに重ね書きされる）中の最初に挙げた“レート”ディレクトリから前述のようにオーディオサブファイルのリクエストが開始される。それからのプロセスは、プレイヤープログラムがサーバから受信されている実際のデータレートを測定してある期間にわたって（例えば３０秒）平均する。全てのＵＲＬリクエストをタイミング制御することによって、クライアントとサーバとの間で得られる転送レート（毎秒当たりのビット数）が決定される。この図の正確さはリクエスト数が増加するにしたがって改善される。プレイヤーは現在のレートと測定されたレートをそれぞれ示している２つの記憶されたパラメータを維持する。
【００３７】
レート変化の開始がトリガーされる。
ａ）バッファが空であり、かつ、測定されたレートが現在のレートよりも小さく、かつ、測定されたバッファロウ（Ｌ０ｗ）％がステップダウンしきい値（以下説明する）を越える場合には、現在のレートを減少させる（バッファがすでに空であるとき、音響カードは何もプレーしないのが有効であるので時間を変化させ、オーディオサンプリングレート、ステレオ−モノ設定、またはビット幅［サンプル当たりのビット数］が変化された場合にはそれは再構成することが必要である可能性がある）。
【００３８】
ｂ）測定されたレートが現在のレートを越えているだけではなく、所定の期間（例えば１２０秒：これは所望ならばユーザにより調整可能にされることができる）に対して次に高いレートを越えるならば、現在のレートを増加させる。
【００３９】
バッファロウ％はバッファの内容がプレイアウト時間（すなわち、バッファがからに近くなる）の２５％よりも小さい時間の割合である。ステップダウンしきい値が０％に設定され、そのときバッファは空であるならば、システムは他の条件が満足されたときには常にステップダウンする。ステップダウンしきい値を５％に設定する（これは我々の好ましいデフォルト値である）ことは、バッファは空であるが、測定されたバッファロウ％が５％よりも大きければステップダウンは行わないことを意味している。さらに、バッファの空はこの測定されたレートを明らかに増加させ、レートが持続できない場合には、バッファロウ％が５％を越えることにより再びバッファを最終的に空にする。値を１００％に設定することは、クライアントが決してステップダウンを行わないことを意味している。
【００４０】
実際のレート変化は、データレートを８ｋビット／秒から２４ｋビット／秒に増加するために“008k”を“024k”に変更するようにサブファイルアドレスの関係する部分を変更し、現在のレートのパラメータを整合するように変更するプレイヤープログラムによって簡単に行うことができる。その結果、サーバに対する次のリクエストはもっと高い（またはもっと低い）レートに対するリクエストとなり、新しいディレクトリからサブファイルが受信され、デコードされてバッファに入力される。以上説明したプロセスは以下のフローチャートに要約されている。
【００４１】
【表２】

【表３】

【表４】

【表５】

ユーザ制御は、キーボードまたはマウスのようなその他の入力装置を使用してユーザが選択できる以下のオプションをスクリーン上に提供するようにユーザにより行われる。
【００４２】
ａ）スタート：上記の与えられた番号のステップ４から実行される。記録が最初に選択されたとき、プレーが自動的に開始されるか、またはユーザからのスタート指令が必要かは随意であり、事実、所望ならばその選択はリンクファイル中の“自動プレイ”パラメータにより行われることができる。
【００４３】
ｂ）中断：ＭＰ３デコーダへの命令によって実行され、バッファからのデータの読出しを中断する。
【００４４】
ｃ）再開：ＭＰ３デコーダへの命令によって実行され、バッファからのデータの読出しを再開する。
【００４５】
ｄ）ジャンプ：例えば、記録の全期間を表している表示されたバー上の所望の点にカーソルを移動させることによって、ユーザはその希望している記録の部分へジャンプする位置を示すことによってユーザにより実行される。その後、プレーヤはこの点がバーに沿ってｘ％であることを決定して、次のサブファイルが必要としている数を計算し、それは次のリクエストに対して使用される。前記のバッハの例では１２５のサブファイルがあり、２０％の点から演奏することがリクエストされ、２６番目のサブファイル、すなわち、000025.binに対してリクエストを生成する。この計算は、各サブファイルが同じ固定した期間に対応している場合には著しく簡単になることは明らかである。ジャンプの場合には、新しいリクエストがすぐに送られるようにデコードを中断し、バッファをクリアすることが好ましいが、これは実際には重要なことではない。
【００４６】
もとのファイルをサブファイルに区分するプロセスについてさらに議論することは重要である。最初に、もしも、（前述した最初のバージョンのように）もとのシーケンス中にそれにすぐに後続している以外のサブファイルによってサブファイルが後続される場合には期待されるものはなく、サブファイル間の境界が位置している場所は重要ではない。その場合には、サブファイルの大きさは固定数のビットであるか、或いは固定された再生時間長であり（またはそれらのいずれも存在しない場合）、ただ一つの実際の決定はどのような大きさのサブファイルが存在しなければならないかである。ジャンプが予想される場合に（時間的、または異なったデータレートの間）他の考察も存在する。多数のタイプのスピーチまたはオーディオ符号化方式（ＭＰ３を含む）が存在する場合には、信号はフレームで符号化され、サブファイルはフレームの全体数を含んでいなければならない。レートスイッチングの場合には、実際には重要ではないが、サブファイル境界が各レートに対して同じであることは非常に望ましく、そのため、新しいレートで受信された第１のサブファイルは終了した古いレートの最後のサブファイルを記録する同じ地点から連続する。同じ固定時間長（例えば上述の４秒）を表さなければならない全てのサブファイルはこれを解決するただ１つの方法ではないが、たしかに最も便利である。しかしながら、使用する符号化システムに応じて、サブファイルがフレームの全数含んでいなければならないと言う要求は、サブファイルの再生期間が多少変化することを意味することもできる。本発明のこの実施形態では、利用できるデータレートは、異なった量子化程度を使用し、モノで符号化するかステレオで符号化するかで異なっているが、全て同じオーディオサンプリングレートを使用し、結果的に同じフレームサイズである。異なったフレームサイズが使用されるとき、アドレスされる必要について以下説明する。
【００４７】
実際のサブファイル長に対しては、過度に短いサブファイルは、（ａ）より多くのリクエストの形態で余分のネットワークトラヒックを生成するため、および（ｂ）ＩＰネットワークを含むある形式のパケットネットワークにおいて、小さいパケットにより伝送されなければならないので不経済であり、そのためリクエストプロセスにより与えられるオーバーヘッドおよびパケットヘッダが比例して大きくなるために避けることが好ましい。他方で、過度に大きいサブファイルでは、大きいバッファが必要であり、再生を開始するとき、および、またはジャンプ或いはレート変化が求められたときに余分の遅延を生じて不利である。プレイアウト時間の３０％乃至１３０％の範囲のサブファイルサイズ、または好ましくはプレイアウト時間のほぼ半分のサブファイルサイズ（上記の与えられた例のような）が満足できるものであることが認められた。
【００４８】
サブファイルを変換する実際のプロセスは論じられた基準にしたがってプログラムされたコンピュータによって実行されることができる。これはサブファイルがサーバへアップロードされることのできる別のコンピュータで行うことが好ましい。
【００４９】
別の改善方法は、より複雑なサブファイルネーミング方法を置換できて、サブファイルを権限のない人がコピーして別のサーバにそれを提供することを困難にするによりセキュリティを増加させる。１例は疑似ランダムシーケンス発生器を使用してファイルネームを生成することである。例えば、次の形態のファイルネームを生成する。

この場合に、プレイヤープログラムは同一の疑似ランダムシーケンス発生器を含んでいる。サーバは第１のファイルネームまたは４デジットの“シード”を送り、プレイヤー中の発生器はそのときその発生器を同期して正確なシーケンスで要求されたサブファイルネームを生成する。
【００５０】
レートスイッチングの上記の例において、使用される全てのデータレートは同じフレームサイズであり、特に１１．０２５ＫＨｚでサンプリングされたＰＣＭオーディオのＭＰ３コード化および１１５２サンプルの（ＰＣＭ）フレームサイズである。もしも異なったフレームサイズを有するＭＰ３（または他の）記録との間でレートスイッチングを行うことが所望されるならば、フレーム境界がそのとき一致しないためにサブファイルが全体のフレーム数を含まなければならないと言う要求によって問題が生じる。この問題はサブファイルを生成するために以下の修正された手順によって解決することができる。特に、この手順は、レートスイッチングが要求され、上述した特定の受渡し方法に制限がない状態で使用されることができる。
【００５１】
図４はオーディオサンプルのシーケンスを概略的に示している。それにおいて連続する４秒のセグメントは境界マーク（図において）Ｂ1 ，Ｂ2 等によって規定される。１１．０２５ＫＨｚにおいて、各セグメント中には４４，１００のサンプルがある。１．オーディオ信号を符号化し、境界Ｂ1 でスタートし、フレーム毎に、ＭＰ３サブファイルを生成し、少なくとも４秒の全体の期間を有するフレームの全体数が符号化されるまで続けられる。１１５２サンプルのフレームサイズによれば４秒は３８．３フレームに対応し、そのため３９フレームを表すサブファイルＳ１は全体で４．０７５秒の期間を表し、正確に符号化される。
【００５２】
２．オーディオ信号を符号化し、同じように境界Ｂ2 でスタートする。
【００５３】
３．反復的に、４秒の境界でそれぞれスタートし、それ故この方法でオーバーラップするサブファイルのセットが符号化される全体のオーディオシーケンスに対して生成される。最後のセグメント（それは４秒よりも短くてよい）はもちろんそれに後続するものは何もなく、ゼロ（すなわち沈黙）を詰められる。
異なったフレームサイズを使用するその他のデータレートの符号化は同様な方法で行われる。
【００５４】
端末において、制御機構は変更されないが、デコードおよびバッファプロセスは変更される。：
１．サブファイルＳ１を受信する。；
２．サブファイルＳ１をデコードする。；
３．デコードされたオーディオサンプルの最初の４秒だけをバッファに書込む（残りは廃棄する）；
４．サブファイルＳ２を受信する。；
５．サブファイルＳ２をデコードする。；
６．デコードされたオーディオサンプルの最初の４秒だけをバッファに書込む（残りは廃棄する）；
７．サブファイルＳ３等について続ける。
このようにして、全てのレートに対するサブファイルセットはもとのＰＣＭシーケンスの同じ点に対応するサブファイル境界を有する。
【００５５】
したがって最後のものを除いて各４秒の期間は符号化に先立って次の４秒の期間からのオーディオサンプルを詰込まれ、それによりサブファイルサイズをＭＰ３フレームの全体数までにする。所望ならば、詰込むサンプルは後続するものの最初のものの代りに（或いはそれと同様に）先行する４秒の期間の終わりから取ることができる。
【００５６】
ＭＰ３標準はある情報が１つのオーディオフレームから他へキャリーオーバーされることを可能にする（ビット保存として知られている方式により）。これに関連してこれはサブファイル内に受入れることが可能であるが、サブファイルの間で受入れ可能ではない。しかしながら、標準方式は当然記録の終わりまたは始めでそのようなキャリーオーバーを許容しないから、この問題は、あだかも単一の記録であるかのように各サブファイルを別々に符号化することによって容易に解決される。
【００５７】
サンプルレートの変化（および事実モノとステレオの動作の切換え）はオーディオインターフェース36の動作に対して実際的な連携を有する。多くの通常の音響カードは、異なった設定範囲で動作可能であるが、サンプリングレートを変更するために再設定を必要とし、これはそのオーディオ出力に中断を生じさせる必要がある。したがって、さらに別の変形では、予想される最高のサンプリングレートで音響カードを連続的に動作させることを提案する。プレイヤープログラムが低いサンプリングレートでバッファにデータを供給しているとき、このデータはバッファの前、または後でこの最高のレートにアップサンプリングされる。同様に、カードが常にステレオモードで動作されるならば、デコードされたモノ信号は並列に音響カード入力の左右の両チヤンネルに供給される。再び、デコードされた信号のサンプル当たりのビット数がカードによって予測されたよりも低い場合には、ビット数は０を詰めることによって増加されることができる。
【００５８】
自動データレートに対して最初に説明した基準を思い出すと、下方向のスイッチングはバッファのアンダーフローの場合にのみレート減少（それ故出力における中断を含む）を予想させ、この変形により、そのような中断は避けることができ、それ故、アンダーフローを期待する基準を使用することが好ましく、主要な場合にそれを避けることができる。この場合には上述した３つのアンド条件の最初のもの（すなわちバッファが空である）は省略される。
【００５９】
同じ原理は、ビデオ記録または、もちろん添付された音響トラックを有するビデオ記録の受渡しに適用できる。簡単なバージョンではただ１つの記録しかない場合に、システムはオーディオバージョンのみのときとは異なり、ファイルはビデオファイルであり（例えばＨ．２６１またはＭＰＥＧフォーマット）、プイヤープログラムはビデオデコーダを伴っている。ファイルをサブファイルに区分する方法は変更されない。
【００６０】
オーディオの場合のように、すでに説明したように制御機構により選択された異なったデータレートに対応する２以上の記録が存在する可能性がある。また、高速順方向または高速逆方向のような異なった再生モードに対応する付加的な記録を行うことができ、それらはすでに説明したようにユーザの制御装置の拡張によって選択されることができる。再び、ファイルおよびディレクトリネームの系統的なコンベンションにしたがうことができ、プイヤープログラムは例えばサブファイルアドレスを訂正することによって高速順方向命令に応答することができる。
【００６１】
しかしながら、ビデオ記録の受渡しは、スイッチングまたはジャンプが許容されるならばファイル区分に対するさらに別の関係を有する。画像の各フレームが独立に符号化される記録の場合には、サブファイルが画像のフレームの全数を含んでいることで十分である。しかしながら、インターフレーム技術を含む圧縮が使用されている場合には、状態はもっと複雑になる。そのようなシステムの幾つかは（例えばＭＰＥＧ標準方式）独立に符号化されたフレームの混合したもの（“イントラフレーム”）および予測された符号化されたフレームを発生し、この場合には各サブファイルはイントラフレームで開始されることが好ましい。
【００６２】
頻繁で規則的なイントラフレームの含有に対して与えられていないＩＴＵ Ｈ．２６１標準方式のようなインターフレーム符号化システムの場合にはこれは可能ではない。これは例としてレートスイッチングを採用しているために、低いビットレート記録のサブファイルｎ＋１が後続する高いビットレート記録のサブファイルｎをリクエストした場合に、低いビットレートサブファイルの最初のフレームは低いビットレート記録のサブファイルｎの最後にデコードされたフレームを使用してインターフレームベースで符号化されるであろう。それはもちろん端末は勝手な処分はできない。それは高いビットレート記録のサブファイルｎ最後にデコードされたフレームを有している。したがってデコーダの重大なミストラッキングが発生する。
【００６３】
正常の再生と高速再生のモード切換えの場合には、実際の状態は少し異なっている。例えば正常な速度の５倍の高速順方向再生において、５番目毎のフレームだけを符号化する。その結果として、インターフレーム相関は著しく減少され、インターフレーム符号化は魅力的ではなくなり、そのため一般的にイントラフレームとして高速再生シーケンスを符号化することが望まれている。正常速度から高速への切換えはイントラフレームが困難なくデコードされるので問題を生じない。しかしながら、正常再生へ戻るときにミストラッキングの問題が再び発生する。それは端末は先行するフレームでは有していない予測された符号化されたフレームを与えられるからである。
【００６４】
いずれの場合にも、問題は国際特許出願ＷＯ９８／２６６０４号（米国特許６００２４４０号として発行）に記載された原理を使用することによって解決することができる。これは先行するシーケンスの最後のフレームと新しいシーケンスの最初のフレームとの間のギャップをブリッジする中間のフレームシーケンスを符号化することを含んでいる。
【００６５】
この動作について高速順方向再生動作（高速まき戻しは類似しているが逆方向である）について説明する。この例では９分のビデオシーケンスがＨ．２６１標準方式にしたがって９６ｋビット／秒で符号化されており、Ｈ．２６１のインフラフレームで全体的に正常なレートの５倍の速度であり、結果的に得られたファイルは４秒のサブファイルに区分されていると仮定する。したがって４秒はもとのビデオ信号の期間と呼ばれ、高速順方向再生時間ではない。上述した使用に類似したネーミングコンベンションにしたがってサブファイルは次の表で示されている。
【００６６】
【表６】

ここで、“ネーム”は特定の記録を識別するための名前であり、“ｘ１”は正常なレートを示し、“ｘ５”は５倍の正常なレートを示す。すなわち高速順方向レートである。
【００６７】
正常の再生から高速順方向へ切換えるためにはプレイヤープログラムをポイントへのサブファイルアドレスを高速順方向シーケンスへ変更することだけが必要である。例えば、
リクエストmpg name/096K x1/000055.bin に後続して、
リクエストmpg name/096K x5/000055.bin
正常な再生へ戻すように切換えるために、ブリッジングシーケンスを構成するために各可能な転移に対してブリッジサブファイルを構成することが必要である。前述の国際特許出願明細書に記載されているように、一般にブリッジングに対しては３または４フレームのシーケンスで十分であり、それ故、実行する簡単な方法は４フレーム期間だけのブリッジングサブファイルを構成することである。例えば、

それ故、切換えは次のような１連のリクエストによって行われる。
【００６８】
リクエストmpg name/096k x5/000099.bin
リクエストmpg name/096k 5 ＞1/000099.bin
リクエストmpg name/096k x1/000100.bin
ブリッジングサブファイルは次のようにして生成される。
・高速順方向シーケンスをデコードしてサブファイル９９の最後のフレームのデコードされたバージョンを得る（毎秒２５フレームにおいて、これはもとのビデオ信号のフレーム100,000 である）。
【００６９】
・正常のシーケンスをデコードしてサブファイル１００の最初のフレームのデコードされたバージョンを得る（すなわちフレーム100,001 である）。最初の基準フレームとしてこの１フレームをデコードされたフレーム100,000 に基づいてＨ．２６１インターフレームコード化を使用して４回再符号化する。
【００７０】
・したがって、デコーダが高速フォワードサブファイルをデコードしたとき、それに続いてサブファイルをブリッジすることによりフレーム100,000 が正確に再構成され、正常の（ｘ１）フレームをデコードする準備ができる。付随的に、この手順で同じフレームを複数回符号化する理由は、１度しか行わないと、Ｈ．２６１の量的特性により生成される画像の品質が貧弱になるからである。
【００７１】
正確に同じプロセスがレート切換えに対しても使用できる（この場合にはサブファイルのブリッジングは両方向に必要であるが）。しかしながら、説明したようにブリッジングサブファイルは４フレーム期間、すなわち（毎秒２５フレームで）１６０ミリ秒のあいだ画像を凍結する。高速再生から正常の再生への切換えにおいて、これは許容可能である。事実この時点でバッファのクリアを選択する可能性がある。それはレート切換えが許容可能であっても可能でなくてもよい。それ故、代りに４秒ブリッジングシーケンスを構成してもよい。
【００７２】
リクエストシリーズは次のように表される。
【００７３】
mpg name/096k x1/000099.bin
mpg name/096k/128 x1/000100.bin
mpg name/128k x1/000101.bin
ブリッジングサブファイルはその場合に、基準フレームとしてデコードされた９６ｋビット／秒のフレーム100,000 によりスタートしてデコードされた４倍の１２８ｋビット／秒シーケンスの第５のデコードされたフレームを記録するか、或いは基準フレームとしてデコードされた９６ｋビット／秒のフレーム100,000 によりスタートしてデコードされた１２８ｋビット／秒シーケンスの第１、第４フレームを符号化するかのいずれかによって構成されることができる。両方の場合においてブリッジングサブファイルの残りの９６フレームは１２８ｋビット／秒サブファイルのコピーである。
【００７４】
受渡されるファイルは“記録”と呼ばれる。しかしながら、オーディオまたはビデオシーケンス全体が符号化されなければならないこと、または受渡しが開始される前に存在していることは必要ではない。すなわち、コンピュータはライブフィードを受信し、それを選択された符号化方式を使用して符号化してサブファイルを生成し、それらをサーバへアップロードし、それにより幾つかのサブファイルがサーバ上に存在すれば受渡しが開始される。
【００７５】
この受渡しシステムの１つの応用は、図５に示されているような音声メッセージシステムに対するものであり、それにおいては、サーパ1 、ネットワーク2 、および端末3 が示されている。音声メッセージインターフェース4 は例えば公共電話ネットワーク（ＰＳＴＮ）5 を介して電話呼を受信するように機能し、メッセージを記録し、符号化してそれをサブファイルに区分し、それらをサーパ1 へアップロードし、そこにおいてそれらは前述したようにアクセスされる。その代りに第２のインターフェース6 が設けられて、端末3 と同様に動作するが、遠隔の電話5 によってＰＳＴＮを介して遠隔的に制御されて、それに中継されたオーディオ信号が送信されてもよい。
【００７６】
同じシステムはライブオーディオ（またはビデオ）フィードに対して使用されることができる。それは意味的には依然として“記録された”であり、主要な相違点は受渡し、および再生が記録が終了する前に開始することである。もっとも当然ながら、固有の遅延が存在し、それにおいては少なくとも１サブファイルが記録されてサーバ1 にロードされるまで待機しなければならない。
【００７７】
システムは上述のように動作し、最初に再生がスタートすることを除いては全く満足すべきものであり、一方ユーザが最も望無可能性があることは今スタートすることである。すなわち、最も最近に生成されたサブファイルを有することである。
【００７８】
長いオーディオシーケンスによって、記憶量を節約するために古いサブファイルを消去することを選択できる。連続的なフィードにより（すなわち２４時間１日）これは不可避であり、さらに、サブファイルネームを再使用し（我々のプロトタイプのシステムでは、000000.bin乃至009768.binを使用し、それから000000.binでスタートする）、それによって古いサブファイルが一定して新しいもので重書きされる必要がある。最も最近のサブファイルによりスタートする受渡しを確実にする方法は、適当なサブファイルをリクエストすることによってスタートするためにプレイヤープログラムに命令する余分の命令をインデックスファイル中に含めることである。しかしながら、これはそのインデックスファイルが非常に頻繁に変更されなければならない欠点が有り、理想的には新しいサブファイルが生成される都度行われなければならない。それ故、本発明ではプレイヤープログラムがサーバを走査する方法は次のようにしてスタートするサブファイルを発見する。インデックスファイルでは、モードパラメータは“ライブ”に設定され、プレイヤープログラムをトリガーしてこの方法を開始させる。ＬＦＩはサブファイルの最大数を示すように設定され、それは、例えば9768として記憶される。この方法は次のようなステップを含み、（通常のように）各サブファイルの“最後に変更した”時間および日付が決定されたことを予想する。ＨＴＴＰプロトコルを使用するとき、これはヘッドリクエストを使用して達成されることができ、それはリクエストされたサブファイルの受渡しを生じるのではなく、サブファイルがサーバに書込まれた時間を示すヘッダ情報だけを生成し、或いはサブファイルが存在しない場合にはゼロを生成する。
【００７９】
この時間はＧｅｔＵＲＬ（ＬｉｖｅＩｎｄｅｘ）として以下に記載され、ここでＬｉｖｅＩｎｄｅｘは問題としているサブファイルのシーケンス番号である。コメントに先行して“//”が付けられている。
【００８０】
【表７】

ＬｉｖｅＩｎｄｅｘを発見したとき、Ｔp （プレイアウト時間）に慎重にステップバックし、そこからオーディオバッファを満たすためにリクエストを行うことを開始する。再生は正常の方法で開始されることができる。
【００８１】
記録が実際に完了すると、インデックスファイルは所望ならば変更されてモードを“記録された”に設定し、任意の長さのパラメータにすることができる。
【００８２】
所望ならば、プレイヤープログラムは周期的に検査されてインデックスファイルが“ライブ”から“記録された”に変化したか否か観察し、変化していれば、“記録された”モード再生に切換える。
【００８３】
もっと簡単で、ずっと速い“最後のサブファイル”の識別方法について以下説明する。まず、単一の連続的なサブファイルナンバリングシーケンスと仮定する。
【００８４】
１．端末は最初のサブファイル（例えば000000.bin）に対してヘッドリクエストを発行する。
【００８５】
２．サーバはこのファイルのヘッダを送ることによって応答し、ファイルが最後に変更された日付と時間（ＭＯＤＴＩＭＥ）およびこの応答が送られた日付と時間（ＲＥＰＬＹＴＩＭＥ）が含まれる（これらの両者は標準のhttp. フィールドである）。
【００８６】
３．端末は２つを減算することによって経過時間（ＥＬＴＩＭＥ）を計算し（ＥＬＴＩＭＥ＝ＲＥＰＬＹＴＩＭＥ−ＭＯＤＴＩＭＥ）、これをサブファイルの再生時間（この例では４秒）で割算することによってＬＩＶＥＩＮＤＥＸ＝ＥＬＴＩＭＥ／４を得る。
【００８７】
４．端末はこのインデックスを有しているサブファイルのファイルネームを計算する。
【００８８】
５．端末はこのファイルネームによりヘッドリクエストを発行し、必要ならばゼロを受取るまで（ファイルは発見されない）次のファイルネームのヘッドリクエストを発行し、“現在のサブファイル”として発見された最後のサブファイルに関するものである。
【００８９】
６．端末はファイルのリクエストを開始し、前に示したフローチャートのポイントＪ１でスタートする。
【００９０】
この方法は循環式にナンバーを付けたサブファイルに対して上記したものよりかなり速い。古いサブファイルは消去されてもよく、スタートサブファイルが維持されている限り記憶要求を減少させる。しかしながら、この方法はファイルネームの再使用に適合するように変更されることができるが、次のことが要求される。
（ｉ）スタートのサブファイルネーム（例えば00000000.bin）は再使用せず、それ故常にステップ２でヘッダ情報を供給するために利用できる。したがって、009768.binでラップすることにより、サブファイル009768.binはサブファイル000001.binによって後続される。
（ii）ステップ３で計算されたＬＩＶＥＩＮＤＥＸはモジュロ9768を取る（すなわちＥＬＴＩＭＥ／４が9768によって割算されたときの剰余）。
（iii)サブファイルの消去は常に新しいサブファイルの生成に導き、そのため最も新しいサブファイルと最も古い消されていないサブファイルとの間にいくつかのファイルネームは存在しない。そのためにステップ５で期待される“ファイルは発見されない”応答が生じる。
【００９１】
記録動作よりも少し速い、または少し遅い再生動作が行われる危険性が存在する可能性がある。前者に対して保護するために、プレイヤープログラムは以前のものよりも遅い時間でマークされたか否かを確認するために受信する各サブファイルを検査し、もしもサブファイルが廃棄されていなければ、繰返してリクエストし（恐らく３回）、それに続いてこれらのリクエストが成功しないか否かインデックスファイルを検査する。
【００９２】
もしも、再生イングが記録プロセスの後であるならば、現在リクエストされているものよりもさらに最近サブファイルの可なりの数が存在したことについてサーバを検査するプレイヤープログラムによって識別され、そのようなサブファイルが存在していれば、例えば少量のデータを規則的に廃棄することによって“キャッチアップ”プロセスが開始される。
【図面の簡単な説明】
【図１】 記載されたシステムの全体のアーキテクチャを示す概略図。
【図２】 そのようなシステム端末のブロック図。
【図３】 典型的なインデックスファイルの内容を示す図。
【図４】 サブファイル生成の変形された方法を示すタイミング図。
【図５】 変形されたアーキテクチャを示す図。

Claims (3)

1. 第１のフレーム長を有する第１の符号化アルゴリズムによって入力信号の連続する第１の時間的部分のそれぞれを符号化して、第１の符号化されたシーケンスを生成し、
   第２のフレーム長を有する第２の符号化アルゴリズムによって入力信号の連続する第２の時間的部分のそれぞれを符号化して、第２の符号化されたシーケンスの各オーバーラップする部分が第１の符号化されたシーケンスの部分の間の少なくとも境界を含むように第２の符号化されたシーケンスを生成し、
   さらに、出力部に一方の符号化されたシーケンスを供給し、スイッチング命令に応答してもう一方の符号化されたシーケンスを供給するように出力をスイッチングし、
   前記第１の時間的部分は、前記第１のフレーム長の整数に対応し、そして隣接するか、オーバーラップしており、
   前記第２の時間的部分は、前記第２のフレーム長の整数に対応し、前記第１のフレーム長の整数には対応せず、オーバーラップしており、
   前記スイッチングは、１つの符号化された時間的部分と次のものとの間の境界で行われる入力オーディオ信号の符号化方法。
2. 第１および第２の符号化アルゴリズムはそれぞれ異なった出力データレートに対応している請求項１記載の方法。
3. 請求項１乃至２のいずれか１項記載の方法を使用して信号を符号化し、
   ディスクリートな部分をデコードし、
   先行する時間部的分の終りおよび、またはすぐ後に続く時間的部分の始めに対応するデコードされた信号の一部分を廃棄するオーディオ信号の送信方法。

Images