JP2010538515A - Ａｍｒ−ｗｂｄｔｘ同期化を提供するためのシステムおよび方法 - Google Patents

Abstract

改良型適応多重レート広帯域（adaptive multi-rate wideband; AMR-WB）不連続伝送（discontinuous transmission; DTX）同期化を提供するためのシステムおよび方法。種々の実施形態によると、非アクティブスピーチ期間の開始に関する表示子が、DTX期間が開始する前の所定数のフレームに、すなわち、SID_FIRSTフレームを受信する前の所定数のフレームに、音声区間検出（voice activity detection; VAD）フラグを用いて復号器に届けられる。VADフラグがアクティブスピーチを示す場合、またはVADフラグが所定数のフレームより最近にゼロに設定された場合、受信したNO_DATAフレームは、高い信頼性をもってアクティブスピーチに分類することが可能であり、すなわち、送信機、ネットワーク、または端末が開始したシグナリングと考えることが可能であり、SPEECH_LOSTに置換可能である。VADフラグが、8フレーム以前にゼロに設定された場合、NO_DATAフレームは、DTXに分類される。
【選択図】図１

Description

本発明は、主にスピーチ符号化に関し、より具体的には、タンデムフリーオペレーション（Tandem free operation; TFO）等の回線交換ネットワーク、また、トランスコーダフリーオペレーション（Transcoder free operation; TrFO）ネットワークやボイスオーバIP（Voice over IP; VoIP）ネットワーク等のパケット交換ネットワークにおける、スピーチ符号化、エラー耐性、スピーチの伝送に関する。

発明の背景

本項は、請求項に列挙する本発明の背景または内容を提供することを意図する。本項における説明は、追求されうる概念を含むかもしれず、必ずしも過去に着想または追求された概念ではない。したがって、本明細書において別途明示されない限り、本項に説明されるものは、本願明細書及び特許請求の範囲に対する従来技術ではなく、本項に含められていることだけで従来技術であると認められるものではない。

第3世代パートナーシッププロジェクト（3rd Generation Partnership Project; 3GPP）コアネットワークにおけるTFOおよびTrFOxや、VoIPサービス等のサービスにおける受信機ロジックは、伝送コードRX_NO_DATAによりスピーチ符号器に伝えられる空フレームまたはパケットを、適応多重レート広帯域（adaptive multi-rate wideband; AMR-WB）ビットストリームに追加する。すなわち、アクティブスピーチビットストリームは、空フレームまたはパケットを含む場合がある。これらの空フレームまたはパケットは、通常は別の目的に使用される。例えば、このようなフレームまたはパケットは、TFO/TrFOシグナリングや、他のシステムレベルのシグナリングなどの、急を要するシグナリングにしばしば置き換えられる。このような「非スピーチ」データフレームやパケットをスピーチフレームやパケットとして復号器が処理することを避けるために、このようなフレームは、RX_NO_DATAと標識される。RX_NO_DATAフレームの受信の別の例では、伝送路に沿って損失または破損したフレームが、例えば、ある中間エンティティによって、RX_NO_DATAフレームと取り替えられうる。

不連続伝送（discontinuous transmission; DTX）オペレーションの有効時に、AMR-WB復号器が、アクティブスピーチのセグメント内にRX_NO_DATAフレームを受信する場合、TS 26.173 v7.0.0（固定小数点実装）およびTS 26.204 v7.0.0（浮動小数点実装）に準拠するAMR-WB復号器実装は、場合により最大100ミリ秒間、スピーチ合成の出力を無音としたり小さくしたりする。このような出力のミュートまたは減衰によって、スピーチの大幅な品質悪化に関する問題が生じる。

TS 26.193 v7.0.0「Source controlled rate operation」に準拠する対象のAMR-WB復号器機能は、復号器のSPEECHモード時に受信するNO_DATAフレームを、DTXハンドラの観点から、SPEECH_LOSTフレームとして処理すべきことを注意している。具体的には、TS 26.193 v7.0.0は、「RX DTXハンドラがSPEECHモードにある場合、SPEECH_DEGRADED，SPEECH_BAD，SPEECH_LOST，NO_DATAに分類されるフレームは、3GPP TS 26.191に規定されるように置換およびミュートしなければならない」と記述している。NO_DATAに分類されるフレームは、有効なスピーチ情報を含まないSPEECH_LOSTフレームのように対応される。

ネットワークや、端末又はゲートウェイ機能により生成されうるどのようなフレームタイプの入力組み合わせにも対応しうるように、AMR-WB復号器をロバストに構成することが望ましい。しかしながら、DTX同期化の場合には或る問題が発生する。AMR-WB符号器は、非アクティブスピーチを検出する音声区間検出（voice activity detection; VAD）機能性を有し、また、AMR-WB符号器は、非アクティブスピーチを含むフレームを示すために、VADフラグを適宜ゼロに設定する。不連続伝送（discontinuous transmission; DTX）機能は、8フレームのDTXハングオーバ期間の後に起動され、その間に、快適雑音パラメータ（comfort noise parameters）が判断される。復号器は、このDTXハングオーバに関して符号器に同期化する必要がある。復号器が同期化しない場合、復号器における快適雑音が符号器と整合しない。

従来、受信したNO_DATAフレームは、単に、DTX期間に属するフレーム、すなわち、伝送が無いことを示すフレームに分類されることになっている。しかし、この状況では、送信機またはネットワークがシグナリングフレームを送信していたにも関わらず、DTX同期化ロジックがそれに合っていない場合に、問題が発生する。同期化は、快適雑音パラメータを含む最初の無音記述子（Silence Descriptor; SID）フレームの受信後に復旧する。一方、NO_DATAフレームがアクティブスピーチビットストリームの一部に分類され、かつSPEECH_LOSTフレームタイプに（ひいては復号器における誤り隠蔽オペレーションに）置き換えられる場合には、DTX対応に関する問題が発生しうる。例えば、受信機がSID_FIRSTフレーム（DTX期間の最初のフレーム）を損失している場合、NO_DATAフレームは、損失スピーチフレームとして誤って分類される。前述のように、同期化は、次のSID_UPDATEの受信後に復旧する。

固定小数点AMR-WBリファレンス実装（3GPP TS 26.173）では、このDTX同期化への対応は、以下の例１に示すように、cコードで実装される（ソースファイル「dtx.c」における関数「rx_dtx_handler」）。
〔例１〕
1 if ((sub(frame_type, RX_SID_FIRST) == 0) ||
2 (sub(frame_type, RX_SID_UPDATE) == 0) ||
3 (sub(frame_type, RX_SID_BAD) == 0) ||
4 (sub(frame_type, RX_NO_DATA) == 0))
5 {
6 encState = DTX; move16();
7 } else
8 {
9 encState = SPEECH; move16();
10 }

上の1-3行目において、アルゴリズムは、フレームがSID_FIRSTフレームであるか、SID_UPDATEフレームであるか、破損SIDフレームであるかを確認する。4行目では、このフレームがNO_DATAフレームであるか否かを判断する。これらの条件のうちの1つ以上が当てはまる場合、復号器は、DTX状態に切り替える（またはDTX状態のままである）。このようなソースコードの一部に基づくと、アクティブスピーチのセグメントの中で、シグナリングデータ用のスペースを空けるべく取り除いたスピーチフレームの代わりに、NO_DATAフレームが挿入される場合、正しいオペレーションはスピーチ状態に居続けることであっても、復号器が、誤ってDTXモードに切り替えることは明らかである。

上記状況に対応するための従来の一提案について以下の例２に示す。
〔例２〕
1 if ((sub(frame_type, RX_SID_FIRST) == 0) ||
2 (sub(frame_type, RX_SID_UPDATE) == 0) ||
3 (sub(frame_type, RX_SID_BAD) == 0) ||
4 ((sub(frame_type, RX_NO_DATA) == 0) &&
4b (sub(st->dtxGlobalState, SPEECH) != 0)))
5 {
6 encState = DTX; move16();
7 } else
8 {
9 encState = SPEECH; move16();
10 }

上記行4bにおけるテキストによって、アクティブスピーチのセグメントの中に挿入されうるNO_DATAが、誤ってDTX状態に切り替えないことが確保されるが、これは、依然として、挿入されたNO_DATAフレームの誤った対処に関する問題を完全に解決していない。

本発明の種々の実施形態は、改善されたAMR-WB DTX同期機能を提供するシステムおよび方法を提供する。種々の実施形態によると、問題のAMR-WBビットストリームは、伝送されるフレーム毎にVADフラグ情報を含む。つまり、非アクティブスピーチ期間の開始に関する表示子が、DTX期間の開始の8フレーム前、すなわち、SID_FIRSTフレームの受信前に、復号器に届けられる。ゆえに、VADフラグがアクティブスピーチを示すか、このフラグが8フレーム前より最近にゼロに設定された場合、受信したNO_DATAフレームは、高い信頼性をもってアクティブスピーチに分類することが可能となる。すなわち、そのフレームは、送信機やネットワーク、または端末から送信されたシグナリングと考えることが可能であり、SPEECH_LOSTに置換可能である。VADフラグが、8フレームより前にゼロに設定された場合、NO_DATAフレームはDTXに分類される。本発明の種々の実施形態では、AMR-WB受信機は、NO_DATAフレームの対処に関してよりロバストである。本発明の種々の実施形態は、AMR-WB復号器に適用可能であり、具体的には、DTX快適雑音発生および同期化に適用可能である。

本発明に関するこれらの利点および特徴ならびにその他の利点および特徴や、その処理の機構や方式は、添付の図面を併用して、以下の詳細説明によって、より明らかになる。添付の図面において、同一要素は同一の符号を有する。

本発明の種々の実施形態がその内部に実装されうるシステムの概略図である。

本発明の種々の実施形態が実装されうるプロセスを示すフローチャートである。

本発明の種々の実施形態の実装と併用して使用可能である電子デバイスの斜視図である。

図3の電子デバイスに含まれ得る回路の略図である。

本発明の種々の実施形態は、改善されたAMR-WB DTX同期機能を提供するシステムおよび方法を提供する。種々の実施形態によると、問題のAMR-WBビットストリームは、伝送されるフレーム毎にVADフラグ情報を含む。つまり、非アクティブスピーチ期間の開始に関する表示子が、DTX期間の開始の8フレーム前、すなわち、SID_FIRSTフレームの受信前に、復号器に届けられる。ゆえに、VADフラグがアクティブスピーチを示すか、このフラグが8フレーム前より最近にゼロに設定された場合、受信したNO_DATAフレームは、高い信頼性をもってアクティブスピーチに分類することが可能となる。すなわち、そのフレームは、送信機やネットワーク、または端末から送信されたシグナリングと考えることが可能であり、SPEECH_LOSTに置換可能である。VADフラグが、8フレームより前にゼロに設定された場合、NO_DATAフレームはDTXに分類される。

図1は、本発明の種々の実施形態がその内部に実装されうる汎用マルチメディア通信システムのグラフ図である。図1に示すように、データソース100は、アナログフォーマット、非圧縮デジタルフォーマット、または圧縮デジタルフォーマット、あるいはこれらのフォーマットの任意の組み合わせでソース信号を提供する。符号器110は、ソース信号を、符号化メディアビットストリームに符号化する。復号されるビットストリームは、事実上任意のタイプのネットワークに位置するリモートデバイスで直接的または間接的に受信可能であることに留意されたい。さらに、ビットストリームは、ローカルのハードウェアまたはソフトウェアで受信可能である。符号器110は、複数のメディアタイプを符号化可能であってもよく、または符号器110は、異なるメディアタイプのソース信号を符号化するために必要とされてもよい。また、符号器110は、グラフィックスやテキストなどのように、合成的に生成された入力を得てもよく、また、合成メディアの符号化ビットストリームを生成可能であってもよい。以下において、説明を簡略化するために、或るメディアタイプにおける或る符号化メディアビットストリームの処理のみについて考察する。しかしながら、通常、リアルタイムブロードキャストサービスが、いくつかのストリーム（典型的には少なくとも1つの音声や映像、テキストサブタイトルストリーム）を含むことに留意されたい。また、システムが、多数の符号器を含んでもよいが、図1において、一般性を欠如することなく説明を簡略化するために、符号器110を1つだけ示すことに留意されたい。さらに、本明細書に含まれるテキストおよび例は、符号化プロセスを具体的に説明し得るが、同一の概念および原理が、対応する復号プロセスにも適用すること、およびその逆も同様であることを、当業者が理解することを理解されたい。

符号化されたメディアビットストリームはストレージ120に転送される。ストレージ120は、符号化メディアビットストリームを格納するために、任意のタイプの大容量メモリを備えうる。ストレージ120における符号化メディアビットストリームのフォーマットは、エレメンタリ自立型ビットストリームフォーマット（elementary self-contained bitstream format）であってもよく、または符号化メディアビットストリームの1つ以上が、コンテナファイルにカプセル化されてもよい。いくつかのシステムは、「ライブ」で動作する。すなわち、ストレージを省略して、符号化メディアビットストリームを符号器110から送信機130に直接転送する。そして符号化メディアビットストリームは、必要に応じて送信機130（サーバとも呼ばれる）に転送される。伝送に使用するフォーマットは、エレメンタリ自立型ビットストリームフォーマット、パケットストリームフォーマットであってもよく、または符号化メディアビットストリームの1つ以上がコンテナファイルにカプセル化されてもよい。符号器110、ストレージ120、送信機130は、同一の物理的デバイスに存在してもよく、または別々のデバイスに含まれてもよい。符号器110および送信機130は、ライブリアルタイムコンテンツで動作してもよく、この場合、符号化メディアビットストリームは、通常永久的に格納されないが、コンテンツ符号器110および/または送信機130において短期間バッファリングされて、処理遅延、転送遅延、および符号化メディアビットレートにおける変動を平滑化する。

送信機130は、通信プロトコルスタックを使用して符号化メディアビットストリームを送信する。スタックには、リアルタイムトランスポートプロトコル（Real-Time Transport Protocol; RTP）、ユーザデータグラムプロトコル（User Datagram Protocol; UDP）、およびインターネットプロトコル（Internet Protocol; IP）が含まれてもよいが、これらに限定されず、また、本発明の種々の実施形態の内容において、3GPP回線交換型電話も使用してもよいことに留意されたい。通信プロトコルスタックがパケット指向型である場合、送信機130は、符号化メディアビットストリームをパケットにカプセル化する。例えば、RTPを使用する場合、送信機130は、RTFペイロードフォーマットに準拠して、符号化メディアビットストリームをRTPパケットにカプセル化する。通常、各メディアタイプは、専用のRTPペイロードフォーマットを有する。前述のように、システムが、複数の送信機130を含んでもよいが、簡略化するために、以下の説明では1つの送信機130についてのみ考察することに留意されたい。

送信機130は、通信ネットワークを介してゲートウェイ140に接続されてもよく、または接続されなくてもよい。ゲートウェイ140は様々なタイプの機能を実行しうる。その機能には、或る通信プロトコルスタックに準拠するパケットストリームを別の通信プロトコルスタックへ変換することや、データストリームの統合および分岐、ダウンリンクの能力や受信機の能力に従うデータストリームの操作（例えば優勢のダウンリンクネットワーク条件に準拠して転送されるストリームのビットレートの制御）が含まれうる。ゲートウェイ140の例として、MCU、回線交換とパケット交換との間の映像電話のゲートウェイ、プッシュトゥートークオーバーセルラ（Push-to-talk over Cellular; PoC）サーバ、デジタル映像ブロードキャストハンドヘルド（digital video broadcasting-handheld; DVB-H）システムにおけるIPエンカプスレータ、または家庭用無線ネットワークへローカルにブロードキャスト伝送を転送するセットトップボックスが挙げられる。RTPを使用する場合、ゲートウェイ140は、RTP混合器（RTP mixer）またはRTP変換器（RTP translator）と呼ばれ、通常RTP接続の終点としての役割を果たす。

システムは、1つ以上の受信機150を含む。典型的に、受信機150は、伝送された信号を受信し、受信し、復調し、符号化メディアビットストリームに非カプセル化しうる。符号化メディアビットストリームは記録ストレージ155に転送される。記録ストレージ155は、符号化メディアビットストリームを格納するために、任意のタイプの大容量メモリを備えてもよい。記録ストレージ155は、代替的または付加的に、ランダムアクセスメモリ等の計算メモリを備えてもよい。記録ストレージ155における符号化メディアビットストリームのフォーマットは、エレメンタリ自立型ビットストリームフォーマットであってもよい。また、符号化メディアビットストリームの1つ以上は、コンテナファイルにカプセル化されてもよい。相互に関連付けられる多数の符号化メディアビットストリームが存在する場合、典型的にはコンテナファイルを使用し、受信機150は、入力ストリームからコンテナファイルを生成するコンテナファイル生成器を備えるか、またはコンテナファイル生成器に取り付けられる。いくつかのシステムは、「ライブ」でオペレーションし、すなわち、記録ストレージ155を省略して、符号化メディアビットストリームを受信機150から復号器に130に直接転送する。システムによっては、記録されたストリームの直近の部分のみ、例えば、記録されたストリームの直近の10分を抜粋して記録ストレージ155に保持し、一方、それより前に記録された任意のデータを、記録ストレージ155から破棄する。

符号化メディアビットストリームは、記録ストレージ155から復号器160に転送される。相互に関連付けられ、かつコンテナファイルにカプセル化される多数の符号化メディアビットストリームが存在する場合、ファイルパーサ（図示せず）を使用して、コンテナファイルから各符号化メディアビットストリームを非カプセル化する。記録ストレージ155または復号器160は、ファイルパーサを備えてもよく、またはファイルパーサは、記録ストレージ155または復号器160のいずれかに取り付けられる。

符号化メディアビットストリームは、通常、復号器160によってさらに処理され、その出力は、１つ以上の非圧縮メディアストリームである。最後に、レンダラ170は、例えば、スピーカで非圧縮メディアストリームを再生しうる。受信機150、記録ストレージ155、復号器160、およびレンダラ170は、同一の物理的デバイスに存在してもよく、または別々のデバイスに含まれてもよい。

種々の実施形態によると、AMR-WB復号器がNO_DATAフレームやパケットを受信すると、復号器は、VADフラグの状態および対応するDTXハングオーバ状態を確認する。AMR-WBは、8フレームのDTXハングオーバを有する。ゆえに、復号器は、VADフラグがゼロに設定された後に、8番目のフレームとしてSID_FIRSTを受信することを期待する。復号器が既にVADフラグ履歴、すなわち、非アクティブスピーチを有する連続フレームの数を追跡しているため、復号器は、SID_FIRSTおよびNO_DATAフレームを含むべきフレームを推定することが可能である。このプロセスの表現は、以下の通りである。
If vad_hist < 8
NO DATA frame considered as SPEECH LOST
Signalling included in the bit stream
No DTX hangover information update needed
else
NO DATA frame considered as DTX
DTX hangover information needs to be updated

固定小数点3GPP AMR-WBリファレンス実装（3GPP TS 26.173）に上記機能を含めるために、上述の例２のソースコードのセグメントにさらなる修正を使用することが可能であり、以下の例３に示される。
〔例３〕
1 if ((sub(frame_type, RX_SID_FIRST) = = 0) ||
2 (sub(frame_type, RX_SID_UPDATE) = = 0) ||
3 (sub(frame_type, RX_SID_BAD) = = 0) ||
4 ((sub(frame_type, RX_NO_DATA) = = 0) &&
4b ((sub(st->dtxGlobalState, SPEECH) != 0) ||
4c (sub(vad_hist, DTX_HANG_CONST) >= 0))))
5 {
6 encState = DTX; move16();
7 } else
8 {
9 encState = SPEECH; move16();
10 }

行4bおよび行4cのソースコードを使用すると、AMR-WBビットストリームにおいて受信されるVADフラグがハングオーバ期間の終了を示す場合にのみ、すなわち、受信したVAD標示がアクティブスピーチから非アクティブスピーチへ変化した後に、現在のフレームが8番目のフレームである場合、NO_DATAフレームによって、スピーチ状態からDTX状態への切り替えがトリガされる。変数vad_histは、VADフラグがゼロに設定された状態で受信する（連続的）スピーチフレームの数を示す。この値の値を、例えば、（ファイル「dec_main.c」における）関数「decoder」において計算し、追加のパラメータとして関数「rx_dtx handler」に伝える。または、関数「rx_dtx_handler」内で計算して（但し、この値の計算に必要な情報は利用可能であるとする）、例３の行4cの「if」の記述の評価を可能にする。

図2は、本発明の種々の実施形態が実装されうるプロセスを示すフローチャートである。図2における200において、音声コンテンツの個々のフレームがビットストリームに符号化される。これらの複数のフレームの各々は、例えば、VADフラグを使用して、各それぞれのフレームがアクティブスピーチまたは他の音声を表すか否かに関する表示子を含む。210において、複数のフレームが復号器に受信される。220において、その中に含まれるデータが無いという標示、すなわち、NO_DATAフレームであるという表示子を含むフレームが受信される。230において、その前の所定数（図2においてXで表す）のフレームのうちの少なくとも1つが、フレームがアクティブ音声またはスピーチを表すという表示子を含むか否かが判断される。前述のように、この所定数のフレームは、本発明の一実施形態では、8フレームであることを含む。フレームの所定数のフレームのうちの少なくとも1つが、フレームがアクティブ音声を表すという表示子を含む場合、240において、他のフレームもアクティブ音声を表すものとして分類される。この場合、NO_DATAフレームは、250において、SPEECH_LOSTフレームに置き換えられうる。一方、その前の所定数のフレームが、フレームがアクティブ音声を表すという表示子を含まない場合、260において、NO_DATAフレームは、不連続伝送を示すDTXに分類される。

図3および図4は、本発明が実装されうる1つの代表的なモバイルデバイス12を示す。しかしながら、本発明が、1つの特定の型の電子デバイスに限定されるように意図されないことを理解されたい。図3および図4のモバイルデバイス12は、ハウジング30、液晶ディスプレイ形式のディスプレイ32、キーパッド34、マイクロホン36、イヤホン38、バッテリ40、赤外線ポート42、アンテナ44、本発明の一実施形態に従うUICC形式のスマートカード46、カード読み取り器48、無線インターフェース回路52、コーデック回路54、制御器56、およびメモリ58を含む。個々の回路および要素は、全て、当技術分野において、例えば、ノキアのタイプの携帯電話機において周知のタイプである。

本明細書において説明する本発明の種々の実施形態は、方法ステップまたはプロセスの一般的な流れによって説明された。ある実施形態において、これは、ネットワーク環境におけるコンピュータにより実行されるプログラムコード等の、コンピュータにより実行可能な命令を含み、コンピュータ可読媒体に内蔵されるコンピュータプログラムによって実装されうる。概して、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造等を含みうる。コンピュータにより実行可能な命令、関連のデータ構造、およびプログラムモジュールは、本明細書に開示する方法のステップを実行するためのプログラムコードの例を表す。特定の一連のこのような実行可能な命令または関連のデータ構造は、このようなステップまたはプロセスにおいて説明する機能を実装するための対応する処理の例を表す。

本発明の種々の実施形態のソフトウェアおよびウェブ実装は、種々のデータベース検索ステップまたはプロセス、相関ステップまたはプロセス、比較ステップまたはプロセス、ならびに決定ステップまたはプロセスを達成するために、法則ベースのロジックおよび他のロジックを含む標準的なプログラミング技法により達成可能である。本明細書および以下の請求項で使用する際、単語の「構成要素」および「モジュール」は、1つ以上のタイプのソフトウェアコード、および/またはハードウェア実装、および/または手動入力を受信するための設備を使用する実装を包含するように意図されることに留意されたい。

本発明の実施形態に関する前述の説明は、例示目的および説明目的のために提示されている。前述の説明は、包括的であるように、または開示される厳密な形式に本発明の実施形態を限定するように意図されず、また、上記教示を考慮した修正および変形が可能であるか、または、これらの修正および変形は、本発明の実装により得られうる。本明細書において論じられる実施形態は、本発明の種々の実施形態およびその実用的な用途に関する原理および性質を説明して、種々の実施形態における本発明および想定される特定の使用に適合する種々の修正を有する本発明を当業者が利用できるように、選択および説明されている。

Claims (16)

1. それぞれアクティブ音声を表すか否かに関する表示子を含む、複数の音声コンテンツフレームを、ビットストリームから受信することと；
   中に含まれるデータが無いという表示子を含む、追加の音声コンテンツフレームを受信することと；
   前記複数の音声コンテンツフレームのうち、前記追加の音声コンテンツフレームの前の所定数のフレームが、アクティブ音声を表す表示子を含まない場合、前記追加の音声コンテンツフレームを、不連続伝送であるものとして分類することと；
   を含む、方法。
2. 前記追加の音声コンテンツフレームの前の前記所定数のフレームのうち、少なくとも１つのフレームが、アクティブ音声を表す表示子を含む場合、前記追加の音声コンテンツフレームを、アクティブ音声を表すものとして分類すること；
   を含む、請求項１に記載の方法。
3. 前記追加の音声コンテンツフレームの前の前記所定数のフレームのうち、少なくとも１つのフレームが、アクティブ音声を表す表示子を含む場合、前記追加の音声コンテンツフレームを、音声が損失していることを特定するフレームに置換することをさらに含む、請求項２に記載の方法。
4. 前記音声コンテンツがスピーチコンテンツを含む、請求項１に記載の方法。
5. 前記所定数のフレームが８フレームであることを含む、請求項１に記載の方法。
6. 前記ビットストリームが適応多重レート広帯域ビットストリームであることを含む、請求項１に記載の方法。
7. 請求項１に記載のプロセスを実行するように構成されるコンピュータコードを含むコンピュータ可読媒体に具現化されるコンピュータプログラム製品。
8. プロセッサと、前記プロセッサに通信可能に接続されるメモリユニットとを備え、前記メモリユニットが、
   ビットストリームから受信した、それぞれアクティブ音声を表すか否かに関する表示子を含む複数の音声コンテンツフレームを処理するコンピュータコードと；
   中に含まれるデータが無いという表示子を含む、受信した追加の音声コンテンツフレームを処理するコンピュータコードと；
   前記複数の音声コンテンツフレームのうち、前記追加の音声コンテンツフレームの前の所定数のフレームが、アクティブ音声を表す表示子を含まない場合、前記追加の音声コンテンツフレームを、不連続伝送であるものとして分類するコンピュータコードと；
   を含む、装置。
9. 前記追加の音声コンテンツフレームの前の前記所定数のフレームのうち、少なくとも１つのフレームが、アクティブ音声を表す表示子を含む場合、前記追加の音声コンテンツフレームを、アクティブ音声を表すものとして分類するコンピュータコードを前記メモリユニットが含む、請求項８に記載の装置。
10. 前記追加の音声コンテンツフレームの前の前記所定数のフレームのうち、少なくとも１つのフレームが、アクティブ音声を表す表示子を含む場合、前記追加の音声コンテンツフレームを、音声が損失していることを特定するフレームに置換することをさらに含む、請求項８に記載の装置。
11. 前記音声コンテンツがスピーチコンテンツを含む、請求項８に記載の装置。
12. 前記所定数のフレームが８フレームであることを含む、請求項８に記載の装置。
13. 前記ビットストリームが適応多重レート広帯域ビットストリームであることを含む、請求項８に記載の装置。
14. それぞれアクティブ音声を表すか否かに関する表示子を含む、複数の音声コンテンツフレームを、ビットストリームから受信する手段と；
    中に含まれるデータが無いという表示子を含む、追加の音声コンテンツフレームを受信する手段と；
    前記複数の音声コンテンツフレームのうち、前記追加の音声コンテンツフレームの前の所定数のフレームが、アクティブ音声を表す表示子を含まない場合、前記追加の音声コンテンツフレームを、不連続伝送であるものとして分類する手段と；
    を備える、装置。
15. 前記追加の音声コンテンツフレームの前の前記所定数のフレームのうち、少なくとも１つのフレームが、アクティブ音声を表す表示子を含む場合、前記追加の音声コンテンツフレームを、アクティブ音声を表すものとして分類する手段をさらに備える、請求項１４に記載の装置。
16. 前記追加の音声コンテンツフレームの前の前記所定数のフレームのうち、少なくとも１つのフレームが、アクティブ音声を表す表示子を含む場合、前記追加の音声コンテンツフレームを、音声が損失していることを特定するフレームに置換する手段をさらに含む、請求項１５に記載の装置。

Images