トップ :: G 物理学 :: G10 楽器;音響

【発明の名称】 フレーム構造のノイズ除去装置、フレーム構造のノイズ除去方法およびフレーム構造のノイズ除去プログラム
【発明者】 【氏名】勝屋 宏一
【住所又は居所】東京都大田区大森西4丁目15番5号 パイオニア株式会社大森工場内
【課題】CRCによるエラー検出よりもさらにエラー検出能力を高め、かつ、エラー検出時における出力音をより聞きやすい音に改善することを課題の一例としている。

【解決手段】上記の課題を解決するために、請求項1に記載の発明は、符号化された音声データにエラーが発生したかどうかを検出するエラー検出手段と、前記符号化された音声データをデコードする際に窓関数を使用し、その結果を加算するデコード手段を備え、前記デコード手段は、前記エラー検出時にはエラーの発生していない直前の前記符号化された音声データをデコードすることを特徴とする。
【特許請求の範囲】
【請求項1】
符号化された音声データにエラーが発生したかどうかを検出するエラー検出手段と、
前記符号化された音声データをデコードする際に窓関数を使用し、その結果を加算するデコード手段を備え、
前記デコード手段は、前記エラー検出時にはエラーの発生していない直前の前記符号化された音声データをデコードすることを特徴とする、ノイズ除去装置。
【請求項2】
請求項1に記載のノイズ除去装置において、
前記エラー検出手段は、特定の放送仕様に使用される記述子と一致するか否かを判定することを特徴とする、ノイズ除去装置。
【請求項3】
請求項1または2に記載のノイズ除去装置において、
前記エラー検出手段は、前記符号化された音声データに含まれるデータ長記述子を利用し、前記符号化された音声データにエラーが発生したか否かを判定することを特徴とする、ノイズ除去装置。
【請求項4】
請求項1から3のいずれかに記載のノイズ除去装置において、
前記デコード手段は、前記エラー検出時にデコード結果が0となる前記符号化された音声データをデコードすることを特徴とする、ノイズ除去装置。
【請求項5】
符号化された音声データにエラーが発生したかどうかを検出するエラー検出ステップと、
前記符号化された音声データをデコードする際に窓関数を使用し、その結果を加算するデコードステップを備え、
前記デコードステップは、前記エラー検出時にはエラーの発生していない直前の前記符号化された音声データをデコードすることを特徴とする、ノイズ除去方法。
【請求項6】
請求項5に記載のノイズ除去方法において、
前記エラー検出ステップは、特定の放送仕様に使用される記述子と一致するか否かを判定することを特徴とする、ノイズ除去方法。
【請求項7】
請求項5または6に記載のノイズ除去方法において、
前記エラー検出ステップは、前記符号化された音声データに含まれるデータ長記述子を利用し、前記符号化された音声データにエラーが発生したか否かを判定するステップであることを特徴とする、ノイズ除去方法。
【請求項8】
請求項5から7のいずれかに記載のノイズ除去方法において、
前記デコードステップは、前記エラー検出時にデコード結果が0となる前記符号化された音声データをデコードするステップであることを特徴とする、ノイズ除去方法。
【請求項9】
コンピュータに、符号化された音声データにエラーが発生したかどうかを検出するエラー検出機能と、
前記符号化された音声データをデコードする際に窓関数を使用し、その結果を加算するデコード機能を備えさせ、
前記デコード機能は、前記エラー検出時にはエラーの発生していない直前の前記符号化された音声データをデコードすることを実現させるためのプログラム。
【請求項10】
請求項9に記載のプログラムにおいて、
前記エラー検出機能は、特定の放送仕様に使用される記述子と一致するか否かを判定することを特徴とする、プログラム。
【請求項11】
請求項9または10に記載のプログラムにおいて、
前記エラー検出機能は、前記符号化された音声データに含まれるデータ長記述子を利用し、前記符号化された音声データにエラーが発生したか否かを判定する機能であることを特徴とする、プログラム。
【請求項12】
請求項9から11のいずれかに記載のプログラムにおいて、
前記デコード機能は、前記エラー検出時にデコード結果が0となる前記符号化された音声データをデコードすることを特徴とする、プログラム。
【発明の詳細な説明】【0001】
【発明の属する技術分野】
本発明は、デジタルオーディオデータフレーム、圧縮音声データフレームその他のフレーム構造のノイズ除去に関する。
【0002】
【従来の技術】
【特許文献1】特開平8−286698
【特許文献2】特開2000−59231
【特許文献3】特表2001−501063
【特許文献4】特開2002−73091
従来の圧縮音声再生方法においては、圧縮音声ストリーム中のフレームエラーを検出する方法としては、CRC(Cyclic Redundancy Check)によるエラーチェックが一般的である。圧縮音声再生方法の一つであるAAC(Advanced Audio Coding)の場合、CRCでエラー検出対象としている範囲は、圧縮音声ストリームの全体ではなく、一部分である。圧縮音声ストリームはフレームの集合からなるが、ISDB−TSB(Integrated Services Digital Broadcasting−Terrestrial Sound Broadcasting):(国内ディジタル地上波オーディオ放送)ではAACのなかのADTS(Audio Data Transport Stream)フレームを使用している。図1はADTSフレームの構造を示す。ADTSフレームはADTSヘッダー、CRC、Raw_data_blockの3つの部分からなる。ADTSヘッダーにはフレームの各種情報が書き込まれている。CRCにはADTSフレームの一部分についてエラーチェックをした結果が書き込まれている。Raw_data_blockには圧縮音声データおよび圧縮音声データの種類を示す情報が書き込まれている。図2はRaw_data_blockの構造を示す。Raw_data_blockは、圧縮音声データの種類を示すID、圧縮音声データであるSyntactic Element、その他データであるbyte alignmentから構成されている。ISDB−TSBのチャンネルの構成やプロファイルにより、IDの種類や数が異なる。図3にIDの種類を示す。
【0003】
図3には左欄から、Syntactic Elementの名称、IDの名称、IDのコード、略語の順に8種類が記載されている。上から3番目のID_CCEはISDB−TSBでは使用されない。
【0004】
図4に従来のAACデコーダのエラー検出方法のフローチャートを示す。ステップS1では音声圧縮ストリーム中の1フレームが入力される。ステップS2では、ステップS1において入力された1フレーム中のヘッダー部分を取得する。ヘッダー部分には、ID、レイヤ、保護ビット、プロファイル、およびサンプリング周波数等の情報が格納されている。ステップS3では、ステップS2で取得したヘッダー情報がAACの仕様に一致しているかいないかを判断する。ヘッダー情報がAACの仕様に一致している場合にはステップS4へ進み、一致していない場合にはステップS8に進む。
【0005】
ステップS4では、ADTSフレームのうちRaw_Data_Block部分を取得する。ここには図2で説明した各種IDとSyntactic Elementが格納されている。図3に表示したIDと同一のものだけが含まれる場合にはステップS6に進み、図3に表示したIDと異なるものが含まれる場合には、ステップS8に進む。すなわち、各IDの種類を示すコードが0X0〜0X7に該当する場合には、ステップS6に進み、コードが0X0〜0X7に該当しない場合には、ステップS8に進む。
【0006】
ステップS6ではCRCチェックを行う。AACのADTSフレームにおいてCRCチェックの対象となるのは、ADTSヘッダーの全てと、図2のIDのうちSCE、CPE、CCE、LFEの最初の192ビットと、CPE内にある2番目のchannel_pair_elementの最初128ビットと、PCE、DSEの全てのデータである。これらのCRCのチェック対象部分を生成多項式にいれて計算し、ADTSヘッダー直後のCRCの値と比較して、値が一致すればフレーム内にエラーがなかったとしてステップS7に進み、値が一致しなければエラーがフレーム内にあるものとしてステップS8に進む。従って、各ID、fill_element、およびSCE、CPE、CCE、LFEの193ビット以降、CPE内にある2番目のchannel_pair_elementの最初から129ビット以降の部分はエラーチェックの対象とはなっていない。
【0007】
ステップS7ではフレーム内にエラーが発生していないAACフレームについてはデコード処理を行う。
【0008】
ステップS8では、フレーム内でエラーが発生したと判断された場合の処理を行う。フレーム内でエラーが発生したと判断された場合には、デコード処理を行わずにデコード結果のデータを全て“0”で置き換える。
【0009】
この場合に、エラーが発生したフレームは、“0”として出力し、ソフトミュート(フェードイン/フェードアウト)を施すことにより、エラー発生時における聞きにくさを解消しようとする(第1の従来技術)。その他にも、エラー発生時における聞きにくさを解消するために前のデータを繰り返すなどの方法(第2の従来技術)が採用されている。
【0010】
図5および図6を用いてこれらの場合について説明する。図5は第1の従来技術を示す概略図であり、図6は第2の従来技術を示す概略図である。図5の上段は、入力データ、中段は、入力データのデコーダ、下段は出力データを示す。入力はフレーム毎にCRCが付加されており、図1ではフレーム0、フレーム1、フレーム2の3つが図示されている。フレーム1のCRCにおいてエラーが発見された場合、フレーム1をデコードした結果のフレーム1Aのデータは、すべて“0”とされる。その結果、フレーム0Aとフレーム2A間でデータが途切れるので、フレーム0Aのフレーム1Aに近い部分の出力を徐々に小さくしていき(フェードアウト)、フレーム2Aのフレーム1Aに近い部分を小さい出力から徐々に大きくしていく(フェードイン)。このようにして、エラー発生時における聞きにくさを解消する方法がとられる。
【0011】
図6の上段は、入力データ、中段は、入力データのデコーダ、下段は出力データを示す。入力はフレーム毎にCRCが付加されており、図6ではフレーム3、フレーム4、フレーム5の3つが図示されている。フレーム4のCRCにおいてエラーが発見された場合、フレーム4をデコードした結果のフレーム4Aのデータは、エラーが発生していない直前のフレーム3Aのデータにすべて置き換えられる。このようにして、エラー発生時における聞きにくさを解消する方法がとられる。
【0012】
【発明が解決しようとする課題】
図4に示す従来技術のエラー検出方法においては、CRCでエラー検出ができるデータはフレームの一部のみであるので、エラー検出能力が低いという問題点を有していた。また、図5に示すソフトミュート(フェードイン/フェードアウト)によるエラー処理を行っても、出力音が有音(正常フレーム)から無音(エラー発生フレーム)に変化し、更に有音(正常フレーム)に変化することになるので、聴きずらいと感じる場合もあった。また、図6において説明した、エラー検出前のフレームのデータを使用する場合にも、エラー検出フレームの前のフレーム音が間延びしたような感覚や、エラー検出フレームの直後のフレーム音が音飛びしたような感覚を生じる場合があった。
【0013】
そこで、本発明では、CRCによるエラー検出よりもさらにエラー検出能力を高め、かつ、エラー検出時における出力音をより聞きやすい音に改善することを課題の一例としている。
【0014】
【課題を解決するための手段】
上記の課題を解決するために、請求項1に記載の発明は、符号化された音声データにエラーが発生したかどうかを検出するエラー検出手段と、前記符号化された音声データをデコードする際に窓関数を使用し、その結果を加算するデコード手段を備え、前記デコード手段は、前記エラー検出時にはエラーの発生していない直前の前記符号化された音声データをデコードすることを特徴とする。
【0015】
【発明の実施の形態】
−第1の実施形態−
以下、ノイズ除去装置による第1の実施形態について説明する。図7は、本実施形態のエラー検出方法をフローチャートで示したものである。
【0016】
本実施形態ではISDB−TSB(国内デジタル地上波オーディオ放送)において使用されているAACにおけるADTSフレームの処理について説明を行う。
【0017】
ステップS9ではデータストリーム中の1フレームが入力される。ステップS10では、ステップS9において入力された1フレーム中のヘッダー部分を取得する。ヘッダー部分には、ID、レイヤ、保護ビット、ビットレート、およびサンプリング周波数等の情報が格納されている。ステップS11では、ステップS10で取得したヘッダー情報がISDB−TSBの仕様を決めているARIB(Association of Radio Industries and Businesses)の仕様に一致しているかいないかを判断する。ヘッダー情報がARIBの仕様に一致している場合にはステップS12へ進み、一致していない場合にはステップS17に進む。たとえば、サンプリング周波数について、AACの規格では12種類が定義されているが、ISDB−TSBのARIBではそのうち48kHz、32kHz、24kHzの3種類のみしか使用していないので、サンプリング周波数が48kHz、32kHz、24kHzの場合にはステップS12へ進み、サンプリング周波数が48kHz、32kHz、24kHzでない場合にはステップS17へ進むことになる。
【0018】
ステップS12では、ADTSフレームのうちRaw_Data_Block部分を取得する。ここには図3で説明した各種IDとSyntactic Elementが格納されている。ステップS13では各種IDのうちISDB−TSBで使用していないIDをRaw_Data_Block部分にもつ場合にはS9に進み、ISDB−TSBで使用しているIDをRaw_Data_Block部分にもつ場合にはステップS14に進む。
【0019】
ステップS14では、CRC(Cyclic Redundancy Check)によってエラーが発生しているかどうかをチェックする。このCRCチェックは従来から実施されていたものである。CRCによってエラーが検出された場合にはステップS17に進み、CRCによってエラーが検出されなかった場合にはステップS15に進む。
【0020】
ステップS15では、ADTSヘッダーに書き込まれているフレーム長さ情報に基づいて、処理したフレーム全体の長さがフレーム長さ情報どおりか否かを判断している。すなわち、ヘッダーの先頭から処理したビット数をカウントし、図2に示すbyte alignmentの最後のビットまで計算する。そのビット数がADTSヘッダーに書き込まれているフレーム長さ情報と一致するか否かを判断する。一致しない場合は、エラーがあるものとみなして、ステップS17に進み、一致する場合は、エラーがないものとみなして、ステップS16に進む。ステップS16に進む場合には、取得しているフレームの内容をメモリに書き込む。
【0021】
ステップS16では、取得したフレームをデコード処理する。この動作について図8を参照して説明する。図8の上半分はエンコード処理を表わし、下半分はここで説明するデコード処理を表わす。周波数サンプル列9内のフレーム21、22、23がステップS9で取得する各フレームに対応する。デコード処理の最初は、各フレームに逆変形離散コサイン変換IMDCT(Inverse Modified Discrete Cosine Transform)10処理を行う。IMDCT10の変換式は以下のように表わされる。
【0022】
【数1】
Xi,n=2/NΣ(from0 to N/2−1)spec[i][k]cos(2π/N(n+n0)(k+1/2))
0≦n<N、(n:sample index, i:windows index, k:spectral coefficient index, N:window length based on the window sequence value, n0=(N/2+1)/2)
次に、IMDCT10の出力ブロック21A、22A、23Aに窓関数11をかける。この窓関数11は一種のフィルタとして考えることもできる。各フレームは周波数特性をもつが、窓関数11によりこの周波数特性が決定される。また、窓関数11を用いることにより前後のブロックの連続性を確保する。AACでは、窓関数11としてサイン窓と隣接バンドとの分離度の良いガイザー窓の2種類が定義されており、本実施形態ではいずれの窓関数をも選択することが可能である。
【0023】
窓関数11の処理は一のIMDCT10の出力ブロックと、その隣接する両ブロックのブロックサイズの半分ずつをオーバラップさせて行う。図8においてはブロック22Aはその隣接するブロック21Aとブロック23Aのブロックサイズの半分づつをオーバラップさせて窓関数11の処理を行っている。その後、窓関数11の処理を行った出力ブロックの隣接するブロックのブロックサイズの半分ずつを加算12して、信号を再生し、時間サンプル列13を生成する。
【0024】
したがって、フレーム22にエラーがあって、デコード結果が0となっても、フレーム22のデコード結果が一部となる対応する時間サンプル列ブロック25および26には、ブロック21Aの後半部と、ブロック23Aの前半部がデータとして入るので、無音となることはなく、しかも前後のブロック(ブロック21とブロック23)からのデコード処理結果がデータとして入るので、ブロック22と相関した連続性を確保したデータが入ることになる。
【0025】
ステップS17では、ステップS9からステップS15までの間のエラーチェックにおいて、フレーム内にエラーが発生していないと判断されたフレームが記憶される。したがって、フレーム内にエラーが発生した場合に、ステップS16にてデコード処理が行われるフレームは、ステップS17に記憶されている、エラーが発生していない直前のフレームとなる。フレームにエラーが発生した場合でもステップS16のデコード処理について説明したように、窓関数11の処理は前後のフレームのデータを使用しているので、前後のデータの連続性は確保されており、再生された信号の音が突然途切れることはない。
【0026】
AACはブロック符号化を行っていることから、デコーダで時間信号に戻したときに、圧縮歪みはブロック内に歪みとして広がる。ブロックごとに圧縮の仕方が異なれば、時間信号にもどしたときにブロック間で不連続が発生し、ブロック歪みとよばれる歪みが発生する。オーディオの場合、この非連続なブロック歪みの音は人間に不快感を与えやすい。このため、ステップS17において、オーバラップして窓関数11処理をして前後のデータの連続性を確保して滑らかにブロック間をつなぐことにより、ブロック歪みが軽減されることになる。
−第2の実施形態−
以下、ノイズ除去装置による第2の実施形態について説明する。
【0027】
図9は、本実施形態のエラー検出方法をフローチャートで示したものである。第1の実施形態と重複する部分は同一符号を付した。
【0028】
第2の実施形態は、第1の実施形態とステップS18における処理の内容が異なる。ステップS18において記憶されるフレームデータはステップS16のデコード処理の結果が0となるフレームデータである。すなわち、図9中ステップS11、S13、S14、S15においてフレームにエラーがあると判断された場合には、当該フレームのデコード結果は0になる。しかし、ステップS16における窓関数処理は一のIMDCTの出力ブロックと、その隣接する両ブロックのブロックサイズの半分ずつをオーバラップさせた処理を行う。すなわち、図8において、ブロック22Aはその隣接するブロック21Aとブロック23Aのブロックサイズの半分づつをオーバラップさせて窓関数処理を行う。そして、窓関数処理を行った出力ブロックの隣接するブロックのブロックサイズの半分ずつを加算して出力信号を再生する。したがって、当該フレーム出力結果が0であっても、当該フレームの前後のフレームをデコードした結果が当該フレームのデコード結果としての出力信号になる。すなわち、デコードされた信号は、従来技術のように有音(正常フレーム)から無音(エラー発生フレーム)へ、無音(エラー発生フレーム)から有音(正常フレーム)へと変化するのではなく、音量は低下するが有音状態が連続し、しかも相互に関連する信号として取り出すことができる。このように、ステップS18において、デコード結果が0になるようなデータを記憶しておくことにより、オーバラップした窓関数処理を行って、前後のデータの連続性を確保して滑らかにブロック間をつなぎ、ブロック歪みが軽減されることになる。このため、人間に不快感を与えにくくなる。
−第3の実施形態−
以下、ノイズ除去装置による第3の実施形態について説明する。
【0029】
図10は、本実施形態のエラー検出、およびデコード処理をブロック図で示したものである。エラー検出部14、メモリ15〜17、セレクタ部19、デコード処理部20からなる。入力データとして1フレームずつ、エラー検出部14とメモリ16に入力される。エラー検出部では、図9におけるステップS11、S13、S14、S15の処理が順次行われる。もしフレーム中にエラーがあると判断した場合には、入力切替信号18によってセレクタ部19はメモリ15の内容またはメモリ17の内容をデコード処理部20に出力する。メモリ15にはエラーが発生していない直前のフレームのデータが記憶されており、メモリ17にはデコード結果が0になるフレームパターンが記憶されている。エラー検出部においてフレームにエラーが発生していないと判断した場合には、入力切替信号18によってセレクタ部19はメモリ16の値をデコード処理部20に出力する。メモリ16には現在エラー検出を行っているフレームが記憶されているので、フレーム中にエラーが発生していないと判断した場合には、現在のフレームをデコードする通常の処理が行われる。
【0030】
すなわち、入力切替信号18によってセレクタ部19はメモリ15〜17のいずれかの値をデコード処理部20に出力する。
【0031】
デコード処理部20では、取得したフレームをデコード処理する。このデコード処理について図8を参照して説明する。図8の下半分はここで説明するデコード処理をあらわす。周波数サンプル列がメモリ16で取得したフレームに対応する。デコードするフレームに逆変形離散コサイン変換IMDCT処理を行う。
【0032】
次に、IMDCTの出力であるブロックに窓関数をかける。この窓関数は一種のフィルタとして考えることもでき、各フレームは周波数特性をもつが、窓関数によりこの周波数特性が決定される。AACでは、窓関数としてサイン窓と隣接バンドとの分離度の良いガイザー窓の2種類が定義されており、本実施形態ではいずれの窓関数をも選択することが可能である。
【0033】
窓関数処理は一つのIMDCTの出力ブロックと、その隣接する両ブロックのブロックサイズの半分ずつをオーバラップさせて窓関数処理を行う。図8においてブロックは隣接する前後のブロックのブロックサイズの半分づつをオーバラップさせて窓関数処理を行っている。窓関数処理を行った出力ブロックの隣接するブロックのブロックサイズの半分ずつを加算して、信号を再生する。
【0034】
したがって、フレームでエラーが検出された場合、メモリ15の内容(エラーが発生していない直前のフレームデータ)または、メモリ17の内容(デコード処理の結果が“0”となるフレームデータ)をデコード処理するが、いずれの場合もエラーが発生したフレームをデコード処理した結果が無音となることはなく、しかも前後のフレームから出力音を再生するので、前後のデータの連続性が確保されており、エラー検出時における出力音をより聞きやすい音に改善することができる。
【0035】
また、本出願によるノイズ除去方法はノイズ除去装置によって実施される図7および図8において明示されている。
【0036】
さらに、上記図7および図9に示すフローチャートに対応するプログラムをフレキシブルディスクまたはハードディスク等の媒体に記録しておき、或いはインターネット等のネットワークを用いて配信しておき、これをマイクロコンピュータ等により読み出して実行することにより、当該マイクロコンピュータ等をシステムコントローラとして動作させることも可能である。
【0037】
本出願にかかわる実施形態は、MDCTを使用しているMP3、AC−3、MPEG4あるいはATRACなどにも適応することができる。
【図面の簡単な説明】
【図1】ADTSフレームの構造を示す図。
【図2】Raw_data_blockの構造を示す図。
【図3】IDの種類を示す図。
【図4】従来のAACデコーダのエラー検出方法のフローチャート。
【図5】第1の従来技術を示す概略図。
【図6】第2の従来技術を示す概略図。
【図7】第1の実施形態のエラー検出方法フローチャート。
【図8】エンコード処理およびデコード処理の手順。
【図9】第2の実施形態のエラー検出方法のフローチャート。
【図10】第3の実施形態のエラー検出およびデコード処理のブロック図。
【符号の説明】
6、13:時間サンプル列
9:周波数サンプル列
10:IMDCT
11:窓関数
12:加算
14:エラー検出部
15、16、17:メモリ
18:入力切替信号
19:セレクタ部
20:デコード処理部
21、22、23:フレーム
21A、22A、23A:ブロック
24:システムコントローラ
【出願人】 【識別番号】000005016
【氏名又は名称】パイオニア株式会社
【住所又は居所】東京都目黒区目黒1丁目4番1号
【出願日】 平成14年9月17日(2002.9.17)
【代理人】 【識別番号】100083839
【弁理士】
【氏名又は名称】石川 泰男

【公開番号】 特開2004−109362(P2004−109362A)
【公開日】 平成16年4月8日(2004.4.8)
【出願番号】 特願2002−270324(P2002−270324)