JP5162589B2

JP5162589B2 - 音声復号化

Info

Publication number: JP5162589B2
Application number: JP2009524878A
Authority: JP
Inventors: ヨウ、ユリ
Original assignee: デジタルライズテクノロジーシーオー．，エルティーディー．
Priority date: 2006-08-18
Filing date: 2007-08-17
Publication date: 2013-03-13
Anticipated expiration: 2027-08-17
Also published as: EP2054881A1; JP5162588B2; EP2054883B1; KR101401224B1; KR101168473B1; KR20120032039A; JP2010501090A; US7895034B2; ATE486346T1; US20070124141A1; DE602007010158D1; JP2010501089A; DE602007010160D1; EP2054881B1; EP2054883A4; WO2008022564A1; KR20090042972A; EP2054881A4; EP2054883A1; KR20090041439A

Description

本願は、２００７年１月３１日付の米国特許出願１１／６６９，３４６「音声符号化システム(Audio Encoding System)」（‘３４６出願）の一部係属出願であり、２００６年１１月１２日付の米国特許出願１１／５５８，９１７「フレームベースデータの可変解像処理（Variable-Resolution Processing of Frame-Based Data）」（’９１７出願）の一部係属出願であり、２００５年１月４日付の米国特許出願１１／０２９，７２２「多チャンネルデジタル音声コーディング用装置および方法（Apparatus and Methods for Multichannel Digital Audio Coding）」（‘７２２出願）の一部係属出願であり、２００４年９月７日付の米国暫定特許出願６０／６１０，６７４「多チャンネルデジタル音声コーディング用装置および方法」の特典を請求しており、また、２００６年８月１８日付の米国暫定特許出願６０／８２２，７６０「可変解像度フィルタリング（Variable-Resolution Filtering）」（’７６０出願）の特典を請求している。これら先行する出願は、それぞれ全文を記述する代わりに番号で本文中に挿入されている。
本発明は、通信チャンネル全体で受信されるかまたは記憶装置から読み出されたデジタル音声信号等の音声信号を復号化するシステム、方法および技術に関する。

音声信号を符号化した後に復号化するための様々な種類の技術が存在する。しかしながら、性能、品質および効率の改善は常に必要とされる。

本発明はなによりもまず、コードブックを量子化インデックスの指定された範囲に適用し（場合によっては量子化ユニットの境界を越えることすらある）、そのビットストリーム内のウィンドウ情報に基づく音声データの１フレーム内に適用される別々のウィンドウのシーケンスを表示することによって、ビットストリームから音声データを検索する復号化システム、方法および技術を提供することにより、この必要性に応えるものである。

よって、代表的な実施態様によれば、本発明はフレームベースのビットストリームから音声信号を復号化するためのシステム、方法および技術に関する。各フレームは、フレームに関与するおよび、フレーム内の音声データを表すエントロピー符号化済みの量子化インデックス処理情報を含む。その処理情報は、（ｉ）エントロピーコードブックインデックス、（ｉｉ）そのコードブックが適用されるエントロピー符号化済みの量子化インデックスの範囲を指定するコードブック適用情報、および（ｉｉｉ）ウィンドウ情報、を含む。エントロピー符号化済みの量子化インデックスは、識別されたコードブックをエントロピー符号化済みの量子化インデックスの対応範囲に適用することにより復号化される。その後、その復号化された量子化インデックスを逆量子化することによりサブバンドサンプルが生成され、音声データの１つのフレーム内に適用された異なるウィンドウ関数のシーケンスが、ウィンドウ情報に基づいて識別される。サブバンドサンプルを逆変換し、そのウィンドウ情報により表示された複数の異なるウィンドウ関数を用いることにより、時間領域音声データが得られる。

前述の配置のおかげで、効率が一層向上すると同時にオリジナルの音声信号のより良好な(acceptable)再生が可能になることが多い。

前述要約は、本発明の局面の一部を簡単に説明しているにすぎない。請求項および以下の好ましい実施態様を添付図面と共に参照すれば、本発明をより完璧に理解することが可能であろう。

図１は、復号器を用いることも可能な、本発明の代表的な実施態様による様々な環境を示すブロック図である。

図２Ａ〜２Ｂは、本発明の代表的な実施態様による、フレームをカバーするための１つのロングブロックの使用および、フレームをカバーするための多数のショートブロックの使用を示す図である。

図３Ａ〜３Ｃは、本発明の代表的な実施態様による、過渡フレームの別々の例を示す。

図４は、本発明の代表的な実施態様による、音声信号復号化システム１０のブロック図である。

本発明は、例えば記憶装置からの復元または通信チャンネル全体(across)での受信後に、音声信号を復号化するためのシステム、方法および技術に関与する。本発明の適用例としては、デジタル音声放送、デジタルテレビ（衛星、地上波および／または有線放送）、ホームシアター、デジタルシアター、レーザービデオディスクプレーヤー、インターネットのコンテンツストリーミングおよびパーソナルオーディオプレーヤーが挙げられるが、本発明はこれらに限定されるものではない。本発明の音声復号化システム、方法および技術は、例えば‘３４６出願の音声符号化システム、方法および技術と組み合わせて用いることも可能である。

本発明の復号器１００が使用可能な包括的な環境が、図１に例示されている。一般的に言って、本発明の復号器１００は自身の入力としてフレームベースのビットストリーム２０を受信し、そのフレームベースのビットストリーム２０は、各フレームについて、そのフレーム内に実音声データ（通常はエントロピー符号化済みの量子化インデックス）および様々な種類の処理情報（例えば、制御、書式設定および／または補助情報）を含む。ビットストリーム２０は普通、ハードワイヤード接続または脱着式コネクタを介して復号器１００に入力されるであろう。

上記のように、ビットストリーム２０は多様なソースのいずれから発信されてもよいはずである。そのようなソースの例としては、アンテナ３２で受信され復調器３４でビットストリームに変換されるデジタル無線周波数（またはその他の電磁気）伝送(transmission)、適当な読出器３８によってビットストリーム２０が得られる（半導体、磁気あるいは光学等の）記憶装置３６、復調器４４でビットストリームが取り出されるケーブル接続４２、または、ビットストリーム２０を直接提供するケーブル接続４８が挙げられる。例えば‘３４６出願に記載の技術のいずれかを用いてビットストリーム２０を生成してもよい。上記のように、本発明の実施態様によっては、ビットストリーム２０自体は、多重ビットストリーム等の他の信号、例えばＭＰＥＧ２システムプロトコル等にしたがって多重化された信号からも得られるはずである。その場合その音声ビットストリームは、様々なフォーマットの映像ビットストリーム、他のフォーマットの音声ビットストリーム、およびメタデータをもって、あるいは、音声データのビットを表す冗長符号化済みでインターリービングおよび／または絶縁破壊済みのシンボルで（公知の技術のいずれかを用いて）変調された受信済み無線周波信号をもって多重化される。

'３４６出願でさらに詳細に記載されているように、本発明の好ましい実施態様では、ビットストリーム２０内の音声データは（好ましくは単体正弦波ベース変換技術(unitary sinusoidal-based transform technique)を用いて）既にサブバンドサンプルに変換され、量子化されてからエントロピー符号化されている。好ましい実施態様では、音声データは変形離散コサイン変換（ＭＤＣＴ）を用いて変換され、量子化されてから適当なハフマン符号化を用いてエントロピー符合化されている。しかしながら、別の実施態様では、それ以外の変換および／またはエントロピー符号化技術を用いてもよく、ＭＤＣＴまたはハフマンに関する以下の説明は典型例を示すにすぎないという点を理解する必要がある。音声データはパルス符号変調（ＰＣＭ）サンプルまたは音声サンプルとしてここで様々に言及されているが、その変換が単一であるのが好ましいため、サンプル数は時間領域および変換領域内では同一である。

またここでは、音声データならびに制御、書式設定および補助情報の大部分がハフマン符号化済みとして記載されているが、そのような符号化が一般的には任意であり、好ましい実施態様ではデータサイズの縮小目的で用いられているにすぎない点を理解しなくてはならない。使用の際、復号器１０は符号器により用いられているのと同じコードブックを記憶するのが好ましい。好ましいハフマンコードブックについては‘７６０出願で説明されており、それによればその「コード(Code)」は十進法フォーマットのハフマンコードであり、「ビットインクレメント(Bit Increment)」は現在のコードに先行するライン上のコードと比較するにあたって必要な（十進法での）追加ビット数であり、「インデックス(Index)」は十進法での非符号化値である。

好ましい実施態様では、入力音声データはフレームベースであり、各フレームは特定の時間間隔を規定し、その時間間隔内に各多重音声チャンネルに対応するサンプルを含む。そのようなフレームがそれぞれ比較的小さいフレームサイズのセットから選択される固定数のサンプルを持ち、サンプリング率およびフレーム間で許容可能な遅延量等次第で特定の時間間隔にあわせて選択されるのが好ましい。より好ましくは、各フレームが１２８、２５６、５１２、または１０２４個のサンプルを含み、遅延を減らすことが重要であるという状況でなければ長いフレームのほうが好まれる。以下に記す実施例の大部分では、各フレームは１０２４個のサンプルで構成されると推定される。しかしながら、本発明がそのような実施例に限定されるとみなすべきではない。

処理（主としてＭＤＣＴまたは他の変換処理）目的で、フレームを多数のより小さい、好ましくは同一サイズのブロックに分割する（ここでは、通常はもっと長いＭＤＣＴまたはその他の変換ブロックと区別するために「一次ブロック」と記す）こともある。この分割を図２Ａおよび２Ｂに示す。図２Ａでは、フレーム５０全体が１つの（例えば１０２４個の音声データサンプルを含む）一次ブロック５１で覆われている。図２Ｂでは、フレーム５０は隣接する８個の一次ブロック５２〜５９（例えばそれぞれが１２８個の音声データサンプルを含む）で覆われている。

サンプルのフレームをそれぞれ過渡フレーム（すなわち、信号過渡を含むもの）または準定常フレーム（すなわち、過渡を含まないもの）として分類してもよい。この点において、信号過渡は、信号エネルギーの唐突かつ迅速な立上がり（動作開始）または立下がりとして規定されるのが好ましい。過渡信号はまばらにしか発生せず、本発明の目的からいえば、各フレームで３つ以上の過渡信号は発生しないであろうと推定される。

ここで用いられている「過渡セグメント」という用語は、あるフレーム全体または、信号が同一または類似の統計学的性質を有するフレームのセグメントを指す。よって、準定常フレームは一般的に１個の過渡セグメントで構成され、一方で過渡フレームは普通、２個または３個の過渡セグメントで構成されるであろう。例えば、フレーム内で過渡の動作開始または立下がりのみが起こった場合、過渡フレームは通常２個の過渡セグメントを持つことになる。内１つはその動作開始または立下がり前にフレームのその部分を覆うもので、もう１つはその動作開始または立下がり後にフレームのその部分を覆うものである。１つの過渡フレーム中で動作開始と立下がりの両方が起こるとき、通常３つの過渡セグメントが存在することになる。それらは、その動作開始または立下がりによってセグメント化されたフレームのその部分をそれぞれ覆うものである。

これらの実施例を図３Ａ〜３Ｃに示す。これらの図はそれぞれ、同サイズの８個の一次ブロック６１〜６８に分割済みであるサンプルの１つのフレーム６０を示す。図３Ａでは、過渡信号７０が第２ブロック６２で発生するため、過渡セグメントが２つ存在する。１つはブロック６１単独で構成されるもので、もう１つはブロック６２〜６８で構成される。図３Ｂでは、過渡信号７１がブロック６４で発生し、別の過渡信号７２がブロック６６で発生するので、３つの過渡セグメントが存在する。内１つはブロック６１〜６３で構成され、別の１つはブロック６４〜６５で構成され、残る１つはブロック６６〜６８で構成される。図３Ｃでは、過渡信号７３がブロック６８で発生するので、過渡セグメントが２つ存在する。１つはブロック６１〜６７で構成され、もう１つはブロック６８のみで構成される。

図４は、本発明の代表的な実施態様によるところの音声信号復号化システム１００のブロック図である。図４中、実線の矢印は音声データの流れを示し、破線の矢印は制御、書式設定および／または補助情報の流れを示し、破線の箱は、ビットストリーム２０中の対応する制御データ内で示される場合に限り本実施態様の構成要素がインスタンス化されることを示す。詳細を以下に記す。代表的な副次的実施態様では、以下に記載する通り、図４中の個々のセクション、モジュールまたは構成要素は、コンピュータ実行可能コードで完全に実現される。しかしながら、実施態様によっては、そのようなセクションまたは構成要素のいずれかまたは全てを、ここで説明されている他の方法のいずれかで実現してもよい。

ビットストリーム２０はまず、デマルチプレクサ１１５に入力される。デマルチプレクサ１１５はビットストリーム２０をデータのフレームに分割し、各フレームのデータをアンパックすることにより、処理情報と音声−信号情報とを分離する。第１のタスクについて、ビットストリーム２０のデータをフレームのシーケンスとして解釈するのが好ましい。ここで、新フレームが各自同じ「同期語」（好ましくは0x7FFF）で始まる。本発明の代表的な実施態様による、これらの機能を実施するためのコンピュータプログラムリスティングは、‘７６０出願（引例として記載済み）で説明されており、例えばその中で記載されているような、Bit#Stream()、Frame()、FrameHeader()およびUnpackWinSequence()、さらにそのように列挙されたモジュールにより呼び出されたり参照されたりした他のモジュール、またはそれらの記載を含む。

各データフレームの構造は以下のようになっているのが好ましい。

ヘッダ情報
フレームヘッダ内部に、想定される２種類のフレームのうち１つを表示するシングルビットフィールド「nFrmHeaderType」、汎用フレーム（例えばnFrmHeaderType=0で表示される）または拡張フレーム（例えばnFrmHeaderType=1で表示される）が含まれるのが好ましい。このフラッグに続くビットがヘッダ情報の残りを構成する。好ましい実施態様では、そのフレームが汎用として指示されたかあるいは拡張として指示されたかにもよるが、その情報は以下のように要約される。

よって、例えば、nFrmHeaderTypeが汎用フレームヘッダを指すのであれば、nFrmHeaderTypeに続く最初の１０ビットはnNumWord（以下に規定）として解釈され、次の３ビットはnNumNormalCh（以下に規定）、といったように解釈される。しかしながら、nFrmHeaderTypeが拡張フレームヘッダを指すのであれば、nFrmHeaderTypeに続く最初の１３ビットは、nNumWord（以下に規定）として解釈され、次の６ビットはnNumNormalCh（以下に規定）、といったように解釈される。本発明の実施態様で用いられる様々なヘッダフィールドを以下に説明する。

フィールド「nNumWord」は、同期化語の始まり（その第１バイト）から現在のフレーム用エラー検出語の最後までの、現在のフレーム（３２ビット語）中の音声データの長さを指す。

フィールド「nNumBlocksPerFrm」は、音声データの現在のフレームに対応するショートウィンドウ変形離散コサイン変換（ＭＤＣＴ）ブロックの数を指す。本発明の好ましい実施態様では、１つのショートウィンドウＭＤＣＴブロックが１２８個の一次音声データサンプル（好ましくはエントロピー符号化済みの量子化サブバンドサンプル）を含むので、音声データの１フレームに対応する一次音声データサンプルの数は128*nNumBlocksPerFrmである。

ところで、境界効果を防止するためには、ＭＤＣＴブロックが一次ブロックより大きいのが好ましく、一次ブロックの倍のサイズにするのがより好ましい。それにより、ショート一次ブロックサイズが１２８個の音声データサンプルで構成されるとすると、ショートＭＤＣＴブロックが２５６個のサンプルで構成されるのが好ましい。そして、ロング一次ブロックが１０２４個の音声データサンプルで構成されるとすると、ロングＭＤＣＴブロックが２０４８個のサンプルで構成される。各一次ブロックが新しい（後続の）音声データサンプルで構成されるのがより好ましい。

フィールド「nSampleRateIndex」は、音声信号に用いられたサンプリング周波数のインデックスを指す。インデックスおよびそれに対応するサンプル周波数の組み合わせ例を以下の表に示す。

フィールド「nNumNormalCh」は、正規チャンネル数を指す。このフィールドを表すビット数は、フレームヘッダのタイプにより決定される。本実施態様では、nFrmHeaderTypeが汎用フレームヘッダを指すのであれば、３ビットが用いられ正規チャンネルの数は１から８の範囲になり得る。一方、nFrmHeaderTypeが拡張フレームヘッダを指すのであれば、６ビットが用いられ正規チャンネルの数は１から６４の範囲になり得る。

フィールド「nNumLfeCh」は、ＬＦＥチャンネル数を指す。本実施態様では、nFrmHeaderTypeが汎用フレームヘッダを指すのであれば、１ビットが用いられ正規チャンネルの数は０から１の範囲になり得る。一方で、nFrmHeaderTypeが拡張フレームヘッダを指すのであれば、２ビットが用いられ正規チャンネルの数は０から３の範囲になり得る。

フィールド「bAuxChCfg」は、現在のフレームの末端に、例えば追加のチャンネル構成情報を含む補助データがあるかどうかを指す。bAuxChCfg=0がｎｏを、bAuxChCfg=1がｙｅｓを意味するのが好ましい。

フィールド「bUseSumDiff」は、和差符号化が現在のフレームで既に適用されているかどうかを指す。このフィールドは汎用フレームヘッダ内でのみ提示され、拡張フレームヘッダには現れないのが好ましい。bUseSumDiff=0がｎｏを、bUseSumDiff=1がｙｅｓを意味するのが好ましい。

フィールド「bUseJIC」は、結合強度(joint intensity)符号化が現在のフレームに既に適用されているかどうかを指す。ここでも、このフィールドが汎用フレームヘッダにのみ提示され拡張フレームヘッダには現れないのが好ましい。bUseJIC=0がｎｏを、bUseJIC=1がｙｅｓを意味するのが好ましい。

フィールド「nJicCb」は、結合強度符号化が現在のフレームに既に適用されている場合の結合強度符号化の開始臨界帯域を指す。ここでもこのフレームが汎用フレームヘッダにのみ存在し拡張フレームヘッダには現れないのが好ましい。

上記のように、ヘッダ内のデータは全て処理情報である。以下で明らかにされるように、チャンネル特定(specific)データは、そのようなデータの大部分が音声データサンプルであるものの、その一部が処理情報である。
チャンネルデータ構造
好ましい実施態様では、各正規チャンネルの汎用データ構造は以下のようになっている。

しかしながら、実施態様によっては、正規チャンネルが全てウィンドウシーケンス情報を含むわけではない。ウィンドウシーケンス情報が１つまたは複数のチャンネルに提供されない場合、このデータ群がチャンネル０（Ch0）用に提供されたウィンドウシーケンス情報から複写されるのが好ましい。ただし実施態様によっては、その代わりに指示された他のチャンネルから情報が複写される。

好ましい実施態様では、各ＬＦＥチャンネルの汎用データ構造は以下のようになっている。

上記のように、ウィンドウシーケンス情報（正規チャンネルのみに提供）が、ＭＤＣＴウィンドウ関数インデックスを含むのが好ましい。本実施態様では、そのインデックスは「nWinTypeCurrent」として指示され、以下の値および意味を有する。

nWinTypeCurrent＝０、１、２、３、４、５、６、７または８のとき、ロングＭＤＣＴウィンドウ関数が表示され、１つのロングウィンドウ関数がフレーム全体に用いられる。nWinTypeCurrentの他の値（nWinTypeCurrent＝９、１０、１１または１２）は、ショートＭＤＣＴウィンドウ関数を指す。後者の場合、現在のフレームはnNumBlockPerFrm（例えば８まで）ショートＭＤＣＴで構成され、nWinTypeCurrentはこれらnNumBlockPerFrmショートＭＤＣＴの最初と最後のウィンドウ関数のみを指す。フレーム内の他のショートウィンドウ関数は、完全(perfect)復元要件との関連で(in conjunction with)、過渡が現れる位置により決定されるのが好ましい（詳細は‘９１７出願に記載）。いずれにせよ、受信されたデータが、符号器側で用いられたウィンドウシーケンス全体を全面的に識別するのに適したウィンドウ情報を含むのが好ましい。

この点に関して、本実施態様では、フィールド「nNumCluster」が、現在のフレーム中の過渡セグメント数を指す。ウィンドウ関数インデックスnWinTypeCurrentが、ロングウィンドウ関数が現在のフレーム（nWinTypeCurrent＝０、１、２、３、４、５、６、７または８）中で適用されることを指すとき、現在のフレームが準定常であるため、過渡セグメントの数は必然的に(implicit)１となり、nNumClusterがビットストリームに現れる必要はない（だから送信されないのが好ましい）。

一方で、好ましい実施態様では、ショートウィンドウ関数が表示されその値がそれぞれ１〜３の過渡セグメントに対応して０〜２の範囲であるときに、２ビットがnNumClusterに割り振られる。ショートウィンドウ関数は、準定常フレーム（すなわち１つの過渡セグメント）中でも使用可能である。このようなことは、例えば符号器が低コーディング遅延を達成しようとするときにも起こり得る。そのような低遅延モードでは、１フレーム内の音声データサンプルの数が１０２４（すなわちロング一次ブロックの長さ）未満ということもあり得る。たとえば、符号器が１フレーム内にちょうど２５６ＰＣＭのサンプルを含むように選択されることも考えられる。その場合、そのフレーム内でこれらのサンプルを２個のショートブロック（それぞれが、２５６サンプルＭＤＣＴブロックにより覆われた１２８個のＰＣＭサンプルを含む）で覆うことになり、それはつまり、復号器もまた２つのショートウィンドウを適用するということを意味する。このモードのメリットは、バッファサイズに比例したコーディング遅延が、（他の条件が同じであるなら）例えばこの例では４分の１（１０２４／２５６＝４）だけ減少させられるということである。

現在のフレームが過渡フレーム（すなわち、nNumClusterが２個以上の過渡セグメントを表示するようよう、過渡信号の少なくとも一部を含む）である場合、フィールド「anNumBlocksPerFrmCluster[nCluster]」が受信されたデータに含まれ、自身が占有するショートＭＤＣＴブロックの数に換算して各過渡セグメントnClusterの長さを表示するのが好ましい。そのような語はそれぞれ、（例えば‘７６０出願の表Ｂ．２８のHuffDec1_7×1を用いて）ハフマン符号化されるのが好ましく、したがって、過渡セグメントの位置を復元する目的で各過渡セグメント長を復号化してもよい。

一方で、現在のフレームが（１つのロングウィンドウ関数あるいは所定数のショートウィンドウ関数を持つ）準定常フレームである場合、anNumBlocksPerFrmCluster[nCluster]がビットストリーム内に現れない（つまり送信されない）のが好ましい。過渡セグメント長とはすなわち、ロングウィンドウ関数（例えば２０４８個のＭＤＣＴサンプル）を有するフレーム内の１つのロングブロック、または多重（例えば８まで）のショートウィンドウ関数（例えばそれぞれ２５６個のＭＤＣＴサンプルを含む）内の全ブロックということを暗示するからである。

上記のように、フレームが１つのロングブロックにより覆われているとき、そのブロックがnWinTypeCurrentによって指示されている。しかしながら一般的に、そのフレームが多重ショートブロックで覆われているときにはこの状況はより複雑になる。より複雑化するというその理由は、完全な復元要件のために、現在のブロック用のウィンドウ関数が直前および直後のブロックで用いられたウィンドウ関数に依存するからである。したがって、本実施態様では、ショートブロックが表示されるときには適切なウィンドウシーケンスを識別する目的で追加の処理が実施される。この追加の処理については、モジュール１３４の説明に関連して以下にさらに詳しく記載されている。

ハフマンコードブックインデックスおよび適用範囲情報もマルチプレクサ１１５から抽出される。この情報およびその処理について、以下に記す。

上記のようにフレームデータが一旦アンパックされると、変換係数が検索され適当な順序で配置されてから、逆変換が実施されることによりオリジナルの時間領域データが生成される。これらの一般的なステップについて、以下図４を見ながら詳細に説明する。
係数検索
図４に関して、デマルチプレクサ１５で抽出された対応する情報に基づいて、モジュール１１８で適切なコードブックおよび適用範囲が選択される。より具体的に言えば、上で参照したハフマンコードブックインデックスおよび適用範囲情報が以下のフィールドを含むのが好ましい。

フィールド「anHSNumBands[nCluster]」は、過渡セグメントnCluster中のコードブックセグメント数を指す。フィールド「mnHSBandEdge[nCluster][nBand]*4」は、過渡セグメントnCluster内のコードブックセグメントnBand（つまり、ハフマンコードブックの適用範囲）の長さを（量子化インデックス換算で）指す。それらの値自体がそれぞれ、モジュール１８によって、HuffDec2#64×1で（‘７６０出願で記載されているように）準定常化フレーム用の値を復号化するために用いられ、また過渡フレーム用の値を復号化する目的で用いられているHuffDec3_32×1（これも‘７６０出願で記載）でハフマン符号化されているのが好ましい。フィールド「mnHS[nCLuster][nBand]」は、過渡セグメントnCluster内のコードブックnBandのハフマンコードブックインデックスを表示する。それらの値それ自体は、‘７６０出願で準定常フレーム用の値を復号化する目的で用いられるHuffDec4_18×1、および‘７６０出願で過渡フレーム用の値を復号化する目的で用いられるHuffDec5_18×1によって、それぞれハフマン符号化されているのが好ましい。

実サブバンドサンプル量子化インデックスを復号化するためのコードブックは、復号化されたmnHS[nCluster][nBand]コードブックインデックスに基づき以下のように検索される。

ここで、次元とは、１つのハフマンコードによって符号化された量子化インデックスの数を指し、参照対象となったハフマン復号化表は‘７６０出願で明記されているようなものであるのが好ましい。

ところで、本実施態様においては、各コードブック適用範囲（すなわち各コードブックセグメント）の長さが指定されている。そのようなコードブックセグメントはそれぞれ、１つあるいは複数の量子化ユニットの境界を越えるものであってもよい。また、そのコードブックセグメントを他の方法、例えば各コードブック適用範囲用の起点を指定することによって指定することも可能である。しかしながら、（起点よりもむしろ）長さが指定されるような場合は、ビット数の合計がより少ないほうを用いて符号化することも通常は可能であろう。

いずれにせよ、受信された情報が、各コードブックが適用されるべき適用範囲を単独で識別し、復号器１００が実量子化インデックスを復号化する目的でこの情報を用いるのが好ましい。このアプローチは従来のアプローチとは大幅に異なる。従来のアプローチでは各量子化ユニットが１つのコードブックに割り当てられるため、その適用範囲は送信されない。しかしながら、‘７６０出願で詳細に述べたとおり、追加のオーバーヘッドは普通は、柔軟に適用範囲を指定することによって得られる追加の効率によって補われるレベルを上回る。

モジュール１２０では、デマルチプレクサ１５によって抽出された量子化インデックスが、モジュール１８で識別されたコードブックを量子化インデックスの対応する適用範囲に適用することによって復号化される。その結果、量子化インデックスが完全に復号化される。

モジュール１２２では、量子化ユニットの数が復元される。これに関して、「量子化ユニット」がそれぞれ、周波数領域での臨界帯域および時間領域での過渡セグメントによって結合された量子化インデックスの矩形によって規定されるのが好ましい。この矩形内部の量子化インデックスは全て、同じ量子化ユニットに属する。過渡セグメントは、上記のような方法で、マルチプレクサ１１５によって抽出された過渡セグメント情報に基づき識別されるのが好ましい。「臨界帯域」とは、人間の耳の周波数分解能、すなわち人間の耳が異なる周波数を区別できない範囲の帯域幅(ｆのことである。帯域幅(ｆは、ｆと(ｆとがほぼ指数関数的な関係で周波数ｆと共に上昇するのが好ましい。各臨界帯域はフィルタバンクの隣接するサブバンドサンプル数として表すこともできる。ショートウィンドウおよびロングウィンドウに対する、また異なるサンプリング率に対する臨界として好ましい臨界帯域が、‘７６０出願の表Ｂ．２〜Ｂ．２７で決められている。換言すれば、臨界帯域の境界は、同じ臨界帯域を用いた符号器および復号器を用いて各ＭＤＣＴブロックサイズおよびサンプリング率について前もって決定される。前述の情報より、量子化ユニットの数が以下のように復元される。

ここで、anHSNumBandsfnCluster]は過渡セグメントnClusterのコードブック数であり、mnHSBandEdge[nCluster][nBand]は過渡セグメントnClusterのコードブックnBand用コードブック適用範囲の上限境界であり、pnCBEdge[nBand]は臨界帯域nBandの上限境界であり、さらにanMaxActCb[nCluster]は過渡セグメントnCluster用の量子化ユニット数である。

量子化器モジュール１２４において、各量子化ユニットに適用できる量子化ステップサイズがビットストリーム２０から復号化され、そのようなステップサイズは、復号化モジュール１２０より受信した量子化インデックスからサブバンドサンプルを復元する目的で用いられる。好ましい実施態様では、「mnQStepIndex[nCluster][nBand]」は、量子化ユニット（nCluster、nBand）の量子化ステップサイズインデックスを指し、準定常フレームについてはハフマンコードブックHuffDec6_l16×1によって、過渡フレームについてはハフマンコードブックHuffDec7_l16×1によって復号化される。これらはいずれも‘７６０出願中で説明されている。

一旦量子化ステップサイズが識別されると、各サブバンドサンプル値が、（線形量子化を符号器として用いると仮定して）、サブバンドサンプル＝量子化ステップサイズ＊量子化インデックス、より得られるのが好ましい。本発明の別の実施態様では、非線形量子化技術が用いられる。

モジュール１２８での結合強度復号化は、bUseJICの値により表示された場合に限り実施されるのが好ましい。そのような場合、結合強度復号器１２８がソースチャンネルよりサブバンドサンプルを複写してから、スケールファクタでそれらを乗算することにより結合チャンネルのサブバンドサンプル、すなわち、『結合チャンネルサンプル＝スケールファクタ＊ソースチャンネルサンプル』を復元する。代表的な実施態様では、ソースチャンネルは左前チャンネルで、各正規チャンネルが互いに結合チャンネルとして符号化済みである。同じ量子化ユニット内の全サブバンドサンプルが同じスケールファクタを有するのが好ましい。

モジュール１３０での和差復号化は、bUseSumDiffの値によって表示された場合に限って実施されるのが好ましい。その場合、左／右のチャンネルにおけるサブバンドサンプルの復元が以下のように実施されるのが好ましい。
左チャンネル＝和チャンネル＋差チャンネル
右チャンネル＝和チャンネル−差チャンネル
‘３４６出願に記載されているように、好ましい実施態様では、符号器は、インターリービングと呼ばれるプロセスにおいて、現在のチャンネルの現在のフレーム用サブバンドサンプルを再配置することによって、同一の過渡セグメント内にあり同じサブバンドに対応するサンプルをまとめる。それにより、デインターリービングモジュール１３２において、サブバンドサンプルが再配置されて自然な順序に戻る。そのような再配置を実施するための技術の一つを以下に記す。

ここで、nNumClusterは過渡セグメント数であり、anNumBlocksPerFrmPerCluster[nCluster]は過渡セグメントnClusterについての過渡セグメント長であり、nClusterBinO[nCluster]は過渡セグメントnClusterの第１サブバンドサンプル位置であり、afBinlnterleaved[q]はインターリービングされた順序で配置されたサブバンドサンプルの配列であり、また、afBinNatural[p]は自然な順序で配置されたサブバンドサンプルの配列である。

したがって、デインターリービングモジュール１３２によって実施された処理に従い、各チャンネルの各フレームのサブバンドサンプルが自然な順序で出力される。

時間ベースのサンプルへの変換
モジュール１３４では、データの現行(present)フレームの変換ブロック用に（符号器側で）用いられたウィンドウ関数のシーケンスが識別される。上記のように、本実施態様では、ＭＤＣＴ変換は符号器側で用いられた。しかしながら、他の実施態様では、他のタイプ（好ましくは単一(unitary)で正弦波ベース）の変換が用いられてもよく、本発明の復号器１００によって十分に収容され得る。本実施態様では、上記の通り、ロング変換ブロックフレームについては、受信されたフィールドnWinTypeCurrentが、フレーム全体について用いられた１つのロングウィンドウ関数を識別する。したがって、本実施態様では、ロング変換ブロックフレームについてのモジュール１３４での追加の処理を実施する必要がない。

一方、ショート変換ブロックフレームについては、本実施態様のフィールドnWinTypeCurrentが最初と最後の変換ブロックに用いられたウィンドウ関数を指定しているのみである。したがって、ショート変換ブロックフレームについては、以下の処理を実施するのが好ましい。

フレームでショートブロックが用いられているとき、nWinTypeCurrentに関する受信値が、現在のフレームの第１ブロックと次のフレームの第１ブロックが過渡信号を含有しているかどうか識別する。この情報ならびに、（受信された過渡セグメント長より識別された）過渡セグメントの位置および完全な復元要件のおかげで、フレームの各ブロックでどのウィンドウ関数を用いればよいのかを復号器１００が決定できるようになる。

本実施態様では過渡を備えたブロック用としてWIN_SHORT_BRIEF2BRIEFウィンドウ関数が用いられているため、この情報を伝達(convey)するために以下の名称集を用いることができる。それはWIN_SHORT_Current2Subsであって、現在のフレームの第１ブロック中に過渡があるかどうかをCurrent（SHORT=no、BRIEF=yes）が識別する。また、後続のフレームの第１ブロックに過渡があるかどうかをSubs（SHORT=no、BRIEF=yes）が識別する。例えば、WIN_SHORT_BRIEF2BRIEFは、現在のフレームの第１ブロックおよび後続のフレームの第１ブロックに過渡が存在することを指す。また、WIN_SHORT_BRIEF2SHORTは、現在のフレームの第１ブロックには過渡が存在するが後続のフレームの第１ブロックには存在しないことを指す。

よって、Currentは（フレームの第１ブロックが過渡信号を含むかどうかを表示することによって）フレームの第１ブロックにおけるウィンドウ関数の決定を支援し、Subsは、（後続フレームの第１ブロックが過渡信号を含むかどうかを表示することによって）フレームの最後のブロックに関するウィンドウ関数の識別を助ける。特に、CurrentがSHORTであれば、第１ブロック用のウィンドウ関数をWIN_SHORT_Last2SHORTとする必要がある。その場合、「Last」は、完全復元性(perfect reconstruction property)を介して最後のフレームの最後のウィンドウ関数により決定される。一方で、CurrentがBRIEFであれば、第１ブロックに関するウィンドウ関数はWIN_SHORT_Last2BRIEFでなければならない。その場合も、Lastは完全復元性を介して最後のフレームの最後のウィンドウ関数によって決定される。フレームの最後のブロックに関して、それが過渡を含むとするなら、そのウィンドウ関数はWIN_SHORT_BRIEF2BRIEFでなければならない。このブロックに過渡が存在しないとき、SubsがSHORTであれば、そのフレームの最後のブロック用のウィンドウ関数はWIN_SHORT_Last2SHORTでなければならず、その場合にLastは完全復元性を介してフレームの最後から２番目のブロックのウィンドウ関数により決定される。一方、もしSubsがBRIEFであれば、そのフレームの最後のブロック用のウィンドウ関数はWIN_SHORT_Last2BRIEFでなければならず、その場合にもLastは完全復元性を介してフレームの最後から２番目のウィンドウ関数によって決定される。最終的に、そのフレーム中の残りのブロックに関するウィンドウ関数を過渡位置によって決定することが可能である。これは、完全復元性を介し、１つの過渡セグメントの開始によって表示される。この工程についての詳細は‘９１７出願により提示されている。

モジュール１３６では、現在のフレームの各変換ブロックについて、そのようなブロックが（符号化の過程で紛れ込んだかもしれない量子化ノイズやその他の数値誤差の影響を受けた）オリジナルのデータ値を回復するよう、モジュール１３４によって識別されたウィンドウ関数を用いてサブバンドサンプルが逆変換される。

モジュール１３６の出力は、符号器に入力されたＰＣＭサンプルの復元シーケンスである。

システム環境
一般的に言って、特に断りのない限り、ここに記載されているシステム、方法および技術は全て、１つまたは複数のプログラム式汎用計算機器の使用により実行可能である。そのような機器は通常、例えば共通バス等を介して相互に接続された以下のような構成要素の幾つかを少なくとも備えるであろう。すなわちそれらは、１つあるいは複数の中央処理装置（ＣＰＵ）、読出し専用メモリ（ＲＯＭ）、ランダムアクセスメモリ（ＲＡＭ）、（例えば、シリアルポート、パラレルポート、ＵＳＢ接続やファイアワイヤ接続といったハードワイヤード接続を用いるかブルートゥースまたは８０２．１１プロトコルのような無線プロトコルを用いて）他のデバイスとインターフェイシングするための入力／出力ソフトウェアおよび回路機構、（例えば、イーサネットカードのようなハードワイヤード接続、または符号分割多元接続（ＣＤＭＡ）のような無線プロトコル、移動通信用グローバルシステム（ＧＳＭ）、ブルートゥース、８０２．１１プロトコル、あるいはそれ以外のセルラーシステムもしくは非セルラーシステムを用いて）１つあるいは複数のネットワークに接続するためのソフトウェアおよび回路機構であり、これらのネットワークは本発明の多くの実施態様において互いに(in turn)インターネットまたはその他のネットワークに接続している）。さらなる例は、ディスプレイ（例えば陰極線管ディスプレイ、液晶ディスプレイ、有機発光ディスプレイ、重合性発光ディスプレイ、またはその他の薄膜ディスプレイ）、その他の出力装置（例えば１つあるいは複数のスピーカ、ヘッドフォンセットおよびプリンタ）、１つあるいは複数の入力装置（例えばマウス、タッチパッド、タブレット、タッチセンスディスプレイまたはその他の位置決め装置、キーボード、マイクロフォン、およびスキャナ）、大容量記憶装置(mass storage unit)（例えばハードディスクドライブ）、実時間時計、（例えばＲＡＭ、磁気ディスク、磁気テープ、光磁気ディスク、光学ディスクその他からの読出しおよび書込みをするための）リムーバブル記憶読出し／書込み装置、および、（例えばファックス送信用または、インターネットやダイアルアップ接続を介したコンピュータネットワークへの接続用の）モデムである。動作の際、上記方法と機能を実現するためにプロセスステップは、通常はそのような汎用コンピュータにより実施される程度まで、まず大容量記憶装置（例えばハードディスク）に記憶されており、ＲＡＭにダウンロードされた後にＲＡＭを出てＣＰＵにより実行される。しかしながら、場合によってはそのプロセスステップは最初にＲＡＭかＲＯＭに記憶される。

本発明を実現するのに適した装置は、様々な業者から入手できる。様々な実施態様では、タスクのサイズと複雑度に応じて異なるタイプの装置が用いられる。適切な装置の例としては、メインフレームコンピュータ、マルチプロセッサコンピュータ、ワークステーション、パーソナルコンピュータおよび、ＰＤＡ等のより小型のコンピュータ、無線電話またはその他の機器や装置が含まれる。それらは独立型であっても、または、ネットワークにハードワイヤード接続されたり、ネットワークに無線接続されたものであってもよい。

それに加えて、汎用プログラム式装置については上記の通りであるが、代替的に（あるいは追加で）、１つあるいは複数の特殊用途のプロセッサまたはコンピュータが用いられる。一般に、特に断りがなければ、上記の機能のいずれかが、ソフトウェア、ハードウェア、ファームウェア、またはその組み合わせで実現されてもよく、具体的な実施例は公知のエンジニアリングトレードオフに基づいて選択される。より具体的に述べるなら、上記の機能は、固定した、所定の、あるいは論理的な方法で実現される場合、当業者であれば用意に思いつくように、プログラミング（ソフトウェアやハードウェア等）、論理構成要素（ハードウェア）の適切な配置、またはそれら２つの組み合わせにより達成可能であろう。

言うまでもないことであるが、本発明は、本発明の方法および機能を実施するためのプログラム命令が記憶されている機械可読の媒体にも関連がある。そのような媒体の例としては、磁気ディスク、磁気テープ、ＣＤ−ＲＯＭやＤＶＤ−ＲＯＭといった光学式読取媒体、または、ＰＣＭＣＩＡカードのような半導体メモリ、様々なタイプのメモリカード、ＵＳＢメモリ装置等が挙げられる。そのような場合、その媒体がミニディスクドライブまたはスモールディスク、ディスケット、カセット、カートリッジ、カード、スティック等の携帯可能なアイテムの形態であっても、ハードディスクドライブ、コンピュータまたは他の装置に設けられたＲＯＭやＲＡＭといった、比較的大型の、または固定式アイテムの形態であってもよい。

上記の内容は何よりもまず電子コンピュータおよび装置に重点を置いたものである。しかしながら、代わりに例えば電子、光学、生物学および化学的処理を用いた装置等、他の計算または他のタイプの装置を用いてもよいことは言うまでもない。

追加の考察
上記実施態様は音声データの処理に関与する。しかしながら、言うまでもないことであるが、本発明の技術を他のタイプのデータ、例えば映像データ、センサデータ（地震学、気象、放射線等）、経済データ、またはその他の観測・測定可能なデータと関連させて用いることもできる。

本発明の異なる実施態様が幾つか上記に示されているが、それらはそれぞれ所定の特徴を持つものとして述べられている。しかしながら、いずれか１つの実施態様に関連付けて記載された特徴であってもその実施態様に限定されることを意図したものではなく、それ以外の実施態様における様々な組み合わせに含まれている、および／または配置され得ることは、当業者であれば理解できるであろう。

同様に、上記の通り、機能が特定のモジュールまたは構成要素に起因することもある。しかしながら、機能は一般的に、異なるモジュールまたは構成要素の中から用途に合わせて再区分(redistribute)されてもよい。場合によっては特定の構成要素またはモジュールが完全に不要となる、および／または新たな構成要素またはモジュールの追加が必要となることがある。当業者であれば、本発明の具体的な実施態様を参照しつつ公知のエンジニアリングトレードオフに従って機能の精確な区分がなされることが好ましいことを、理解するであろう。

よって、実施態様および添付図面の例を参照しながら本発明について詳細に述べてきたが、当業者にとっては、本発明の精神および発明の請求範囲から外れることなく本発明の様々な改善および部分的な変更が成し遂げられることは明白なはずである。したがって、本発明は、上記の内容および図面に示された精確な実施態様に限定されない。むしろ、本発明の精神から外れないそのような変形例の全てが、添付の請求項によってのみ限定されるようなそれらの請求範囲内にあると考えられるべきであろう。

Claims

音声信号を復号化する方法であって、
（ａ）複数のフレームを含み、フレームがそれぞれ、前記フレームに関与する処理情報および前記フレーム内の音声データを表すエントロピー符号化済みの量子化インデックスを含むビットストリームを取得するステップであって、前記処理情報が、
（ｉ）各自が１つのコードブックを識別する複数のコードブックインデックスと、
（ｉｉ）そのコードブックが適用されるエントロピー符号化済みの量子化インデックスの範囲を指定するコードブック適用情報と、
（ｉｉｉ）ウィンドウ情報とを含むステップと、
（ｂ）前記コードブック適用情報によって指定された範囲のエントロピー符号化済みの量子化インデックスに前記コードブックインデックスにより識別されたコードブックを適用することによって、前記エントロピー符号化済みの量子化インデックスを復号化するステップと、
（ｃ）前記復号化した量子化インデックスを逆量子化することによりサブバンドサンプルを生成するステップと、
（ｄ）前記ウィンドウ情報に基づいて前記音声データの１フレーム内で複数の同一サイズの変換ブロックにおいて適用された複数の異なるウィンドウ関数のシーケンスを識別するステップと、
（ｅ）前記サブバンドサンプルを逆変換し、前記音声データの前記１フレーム内で、前記ウィンドウ情報によって表示される前記複数の異なるウィンドウ関数を用いることによって時間領域音声データを取得するステップと、
を有し、
前記エントロピー符号化済みの量子化インデックスの範囲のうちの少なくとも１つが、周波数領域の臨界帯域および時間領域の過渡セグメントによって区切られた量子化インデックスの矩形によって規定された量子化ユニットの境界を越え、
前記ウィンドウ情報は、前記フレーム内の過渡の位置を示し、ステップ（ｄ）で、該過渡の位置に関連する所定の規則に基づいて、複数の異なるウィンドウ関数のシーケンスが識別され、
前記所定の規則は、過渡を含む変換ブロックで特定のウィンドウ関数が用いられたことを規定する
ことを特徴とする方法。
前記コードブック適用情報は、前記コードブックインデックスによって識別される各コードブックに関してエントロピー符号化済みの量子化インデックスの１つの範囲を識別する請求項１に記載の方法。
前記コードブック適用情報は、前記コードブックインデックスによって識別される各コードブックに関してエントロピー符号化済みの量子化インデックスの長さを指定する請求項１に記載の方法。
前記所定の規則は完全復元要件に準拠する請求項１に記載の方法。
前記特定のウィンドウ関数は、前記音声データの前記１フレーム内にある前記複数の異なるウィンドウ関数の中で、他のどのウィンドウ関数よりも狭い請求項１に記載の方法。
前記特定のウィンドウ関数は、シンメトリックであり、自身の変換ブロックの各末端部で複数の０価を持ちつつ変換ブロック全体の中心部分のみを占有する請求項１に記載の方法。
（ｉ）前記複数のコードブックインデックス、（ｉｉ）前記コードブック適用情報および、（ｉｉｉ）前記ウィンドウ情報がそれぞれエントロピー符号化される請求項１に記載の方法。
音声信号を復号化するためのコンピュータ実行プロセスステップを記憶するコンピュータ可読媒体であって、前記プロセスステップは、
（ａ）複数のフレームを含み、フレームがそれぞれ、前記フレームに関与する処理情報および前記フレーム内の音声データを表すエントロピー符号化済みの量子化インデックスを含むビットストリームを取得するステップであって、前記処理情報が、
（ｉ）各自が１つのコードブックを識別する複数のコードブックインデックスと、
（ｉｉ）そのコードブックが適用されるエントロピー符号化済みの量子化インデックスの範囲を指定するコードブック適用情報と、
（ｉｉｉ）ウィンドウ情報とを含むステップと、
（ｂ）前記コードブック適用情報によって指定された範囲のエントロピー符号化済みの量子化インデックスに前記コードブックインデックスにより識別されたコードブックを適用することによって、前記エントロピー符号化済みの量子化インデックスを復号化するステップと、
（ｃ）前記復号化した量子化インデックスを逆量子化することによりサブバンドサンプルを生成するステップと、
（ｄ）前記ウィンドウ情報に基づいて前記音声データの１フレーム内で複数の同一サイズの変換ブロックにおいて適用された複数の異なるウィンドウ関数のシーケンスを識別するステップと、
（ｅ）前記サブバンドサンプルを逆変換し、前記音声データの前記１フレーム内で、前記ウィンドウ情報によって表示される前記複数の異なるウィンドウ関数を用いることによって時間領域音声データを取得するステップと、
を有し、
前記エントロピー符号化済みの量子化インデックスの範囲のうちの少なくとも１つが、周波数領域の臨界帯域および時間領域の過渡セグメントによって区切られた量子化インデックスの矩形によって規定された量子化ユニットの境界を越え、
前記ウィンドウ情報は、前記フレーム内の過渡の位置を示し、ステップ（ｄ）で、該過渡の位置に関連する所定の規則に基づいて、複数の異なるウィンドウ関数のシーケンスが識別され、
前記所定の規則は、過渡を含む変換ブロックで特定のウィンドウ関数が用いられたことを規定し、該所定の規則は完全復元要件に準拠する
ことを特徴とするコンピュータ可読媒体。
前記特定のウィンドウ関数は、シンメトリックであり、自身の変換ブロックの各末端部で複数の０価を持ちつつ変換ブロック全体の中心部分のみを占有する請求項８に記載のコンピュータ可読媒体。
（ｉ）前記複数のコードブックインデックス、（ｉｉ）前記コードブック適用情報および、（ｉｉｉ）前記ウィンドウ情報がそれぞれエントロピー符号化される請求項８に記載のコンピュータ可読媒体。
音声信号を復号化する装置であって、
（ａ）複数のフレームを含み、フレームがそれぞれ、前記フレームに関与する処理情報および前記フレーム内の音声データを表すエントロピー符号化済みの量子化インデックスを含むビットストリームを取得する手段であって、前記処理情報が、
（ｉ）各自が１つのコードブックを識別する複数のコードブックインデックスと、
（ｉｉ）そのコードブックが適用されるエントロピー符号化済みの量子化インデックスの範囲を指定するコードブック適用情報と、
（ｉｉｉ）ウィンドウ情報とを含む手段と、
（ｂ）前記コードブック適用情報によって指定された範囲のエントロピー符号化済みの量子化インデックスに前記コードブックインデックスにより識別されたコードブックを適用することによって、前記エントロピー符号化済みの量子化インデックスを復号化する手段と、
（ｃ）前記復号化した量子化インデックスを逆量子化することによりサブバンドサンプルを生成する手段と、
（ｄ）前記ウィンドウ情報に基づいて前記音声データの１フレーム内で複数の同一サイズの変換ブロックにおいて適用された複数の異なるウィンドウ関数のシーケンスを識別する手段と、
（ｅ）前記サブバンドサンプルを逆変換し、前記音声データの前記１フレーム内で、前記ウィンドウ情報によって表示される前記複数の異なるウィンドウ関数を用いることによって時間領域音声データを取得する手段と、
を有し、
前記エントロピー符号化済みの量子化インデックスの範囲のうちの少なくとも１つが、周波数領域の臨界帯域および時間領域の過渡セグメントによって区切られた量子化インデックスの矩形によって規定された量子化ユニットの境界を越え、
前記ウィンドウ情報は、前記フレーム内の過渡の位置を示し、手段（ｄ）で、該過渡の位置に関連する所定の規則に基づいて、複数の異なるウィンドウ関数のシーケンスが識別され、
前記所定の規則は、過渡を含む変換ブロックで特定のウィンドウ関数が用いられたことを規定し、該所定の規則は完全復元要件に準拠する
ことを特徴とする装置。
前記特定のウィンドウ関数は、シンメトリックであり、自身の変換ブロックの各末端部で複数の０価を持ちつつ変換ブロック全体の中心部分のみを占有する請求項１１に記載の装置。
（ｉ）前記複数のコードブックインデックス、（ｉｉ）前記コードブック適用情報および、（ｉｉｉ）前記ウィンドウ情報がそれぞれエントロピー符号化される請求項１１に記載の装置。