N.Yamazaki's blog

主に音声合成について思ったことを書いてみようと思います。
サンプリング周波数変換(リサンプリング)技術 - 応用編

keyword: サンプリング周波数変換、リサンプリング、サンプリングレート変換、アルゴリズム・方況

 

前記事(基本編)では、sinc関数を使ったサンプリング周波数の変換方法を紹介しました。
ただ、sinc関数は無限長(時間軸上で-∞から∞までの長さ)のため、そのままでは実装できません。今回は、これを有限長にする時のいくつかのテクニックを紹介します。


 

■sinc関数に窓関数をかけて有限長にする


sinc関数は、xが大きくなるにつれて次第に振幅が小さくなる関数なので、まずは適当な長さで打ち切った場合を考えてみます。

 

図1は打ち切る長さ(LW)を128、32、8と変えたときの周波数特性です。

長さを短くするほど、sinc関数の本来の周波数特性(理想のLPF)からずれていきます。遷移域(通過域から阻止域に向かう途中の徐々に減衰する部分)は短くするほど広くなり、阻止域の大きさは、短くするほど大きくなっているのがわかります。

 

図1 打ち切り長さによるsinc関数の特性の変化

 

阻止域の大きさ(サイドローブのゲイン)が大きいと、アップサンプリングの場合はナイキスト周波数で折り返した位置にエイリアシング(折り返し雑音)が現れます。ダウンサンプリングの場合は阻止域にあった信号が変換後に帯域内にエイリアシングとして出現します。これらのエイリアシングを少なくするためには、阻止域のゲインを小さくする必要があります。

 

遷移域の幅が大きいとナイキスト周波数付近の信号成分によるエイリアシングが現れます。通常、これは阻止域のより大きなエイリアシングが現れるので注意が必要です。このエイリアシングを少なくするためには、遷移域の幅を狭くする必要があります。

 

リサンプリング処理は上記2つのポイントを考慮して設計します。この2つを同時に満たすには窓長を長くします。ほかに方法はありません。しかし、窓長を長くすると、処理量の増加、遅延、プリエコーという問題が生じます。これについては後述します。

 

ところで、固定の長さでsinc関数を打ち切るというのは、sinc関数に矩形の窓関数をかけることと等価です。

矩形窓の代わりにブラックマン窓をかけた場合は図2のようになります。矩形窓と比べると、阻止域のゲインがより小さく、遷移域の幅はより広くなっていることが分かります。

このように窓関数によって特性のバランスを変えることができます。

 


図2. ブラックマン窓をかけた場合

 


■窓関数の選び方


世の中には多種の窓関数があります。Wikiの窓関数の説明では20種類以上の窓関数が示されています。なぜこんなにたくさんの種類があるのでしょうか。


窓関数には、阻止域のゲインは大きいけれど遷移幅は狭い、あるいは、阻止域のゲインは小さいけど遷移幅は広いなどがあり、いずれの窓関数もそれぞれ一長一短で、また、その周波数特性のカーブも微妙に異なります。
そのため、サンプリング周波数変換においては入力信号の特性や変換に要求される精度によって窓関数を選択することがあります。

 

例えば、入力信号に高域(ナイキスト周波数付近)の信号成分が多く重要視される場合は、阻止域が大きくても遷移域が狭いものが望ましく、24bitデータなど全帯域のエイリアシングを少なくする場合はその逆の阻止域のゲインが小さい窓関数を選択します。

 

また、阻止域のゲインも窓関数に応じて傾きが異なるため、これも選択の基準にすることもあります。

 

表1. 代表的な窓関数の遷移域幅と阻止域ゲイン
窓の種類 阻止域の大きさ 遷移域の幅
矩形         -13db 1(これを基準)
Hanning         -32db  2
Hamming         -41db  2
Kaiser         -46db(β=6.3) 2.2

 

 

■fcを下げる


リサンプリング処理は、遮断周波数(fc)をナイキスト周波数としたLPFフィルタリングと考えることができます。
そこで、fcをナイキスト周波数よりわずかに下げて遷移域を全体的に低域側にずらせば、遷移域のエイリアシングを少なくすることができます。


    sinc(x) ⇒ sinc(rx)  r:ナイキスト周波数に対するfcの割合

 

図3. fcを90%にしたときの周波数特性


デメリットは、ナイキスト周波数付近の信号レベルが小さくなります。例えば、fcを90%にした場合、fi48K fc24k*0.9=21.6KHz 21.6KHzの信号ゲインが3db小さくなります。

 

このテクニックは、入力ソースの信号にナイキスト周波数付近の信号成分が小さかったり無視できる場合に有効です。もっとも、この帯域を無視できるのであれば、それ以上高い周波数の折り返し雑音があっても無視してよいのではという考え方もできますが...。

 


■最小位相化


エイリアシングを少なくするには窓長を長くする必要がありますが、窓長を長くすると今度は遅延やプリエコーの問題が生じます。

 

遅延は通信や放送などのリアルタイムの変換が求められるときに問題となります。窓関数の長さをtwとすると、時刻tの変換値を得るには入力のt+tw/2までの値を使います。したがって、理論上tw/2(窓長の半分)の時間の遅延が生じ、窓長が長いほどその影響が大きくなります。

 

プリエコーとは、遅延と同様に、時刻tの変換値は入力のt+tw/2までの値を使うため、未来の信号の影響が先立って現れる現象をいいます。特に無音の後にアタックの強い信号が来るときに目立ちます。これも窓長が長いほど影響が大きくなり、例えば、窓長が4msのリサンプル処理にパルス状の信号を与えた場合、その2ms前から振幅が始まります。

 

この遅延やプリエコーは、"最小位相化"によって(理論上)なくすことができます。
これまで示した窓かけsinc関数は、すべて左右対称の時間波形です。これは線形位相(またはリニア位相)と呼ばれ、フーリエ変換したときの位相がすべて0になります。
これに対して、最小位相は時間波形では時刻0を中心に片側だけの波形となります。これは因果的な応答特性です。これにより時刻tの変換値を過去の入力値だけから求めることができ、遅延やプリエコーが無くなります。

 


図4.線形位相と最小位相化の時間特性


最小位相化は、窓かけsinc関数をケプストラムに変換後、時系列の片側を0で埋め、元の時間領域に戻すことで得られます。最小位相化を行っても周波数の振幅特性は変わりません。変化するのは位相だけです。

 

ちなみに、すべての位相がゼロなのが最小位相ではなく線形位相というのはややこしいですね。最小位相は本来は群遅延が最小という意味です。

 

リサンプリングにおける線形位相と最小位相の特徴をまとめると次のようになります。

 

●ゼロ位相:左右対称
・変換後の位相が変化しない
・遅延やプリエコーがある


●最小位相:片側のみ
・原理的な遅延が無い
・位相が変化する(波形の形が変化する)
・ゼロ位相より窓長を短くできる


SoXは、オプションの指定で最小位相を用いることができます。SoXのサイトには、オプション毎のさまざまな窓長や位相のサンプルが示されています。このなかで、-vsM -vM -vMa オプションが最小位相です。

 


■各種リサンプラーの実際のパラメータ


各リサンプラーで、44.1KHz⇒96KHzにリサンプリングするときのパラメータを調べてみました。

 

表2.各種Resamplerの分析パラメータ例
窓長 窓の種類 fc     処理量(参考値)
FFmpeg 32 Kaiser(beta=9) 1.0 1(これを基準)
SoX  156 Kaiser(beta=14) 0.96 2.6
AqResample  16 一般化ハミング  1.0 0.5

 

測定条件:

  • オプションは指定せずデフォルトでの値、
  • 窓長は入力サンプリング周期を1とした時の長さ、
  • fcはナイキスト周波数に対する比、
  • 処理量はWindows PC (CPU:Intel Haswell) で実データを変換したときの処理時間の実測(FFmpegを1に正規化)

 

処理量については、それぞれSIMDを使うなどの高速化を行っているため、動作環境によって大きく変わります。また、サンプリング周波数比によっても大きく変わり、特にSoXは比が大きい場合、急激に処理量が増える傾向があるようです。あくまでPC環境での目安にしてください。

 

インパルスレスポンスから求めたそれぞれの周波数特性は図5のようになりました(44.1KHz⇒96KHz)。

 

図5. FFmeg/SoX/AqResampleの周波数特性

SoXは遷移域の幅が狭く、ナイキスト周波数以下に収まっています。これによりナイキスト周波数付近のエイリアシングは無く理想LPFに近いことが分かります。阻止域の大きさはFFmpegより大きくなっています。窓長が長いのにこれはちょっと不思議な結果です。スイープ音を変換した場合はエイリアシングの抑制が-100db以上あったので、インパルス応答を用いた測定が適当でないのかもしれません。AqResampleは、窓長が短いため、遷移域の幅が広く、折り返し雑音がかなり目立ちます。FFmpegはその中間の特性です。

 

 

■最後に


ここまで、サンプリング周波数変換の特性について書いてきましたが、最終的なパラメータ等の選定基準は、実際に聴いてみて判断することが大切です。

 

今回3種類のResamplerを取り上げましたが、各々で変換したオーディオデータを実際に聴き比べてほしいと思います。Windows版 AqResampleは組み込み用のため処理量を優先し窓長をぎりぎりまで短くしています。数値上の特性では品質の劣化が激しそうですが、実際に聴取したらどう感じるでしょうか。

 

驚いたことに、高精度な処理でエイリアシングをなくしたものより、エイリアシングが残っているほうが、きらびやかでよりリアルに聞こえるなどという高評価が得られたことがありました。

数値だけを追い求め、人間が知覚できないレベルの品質にこだわったり、それを喧伝することについて、もっと考えるべきだと思います。
 

 

■おまけ - FFmpegの使い方(いろいろなオプション)


FFmpegでサンプリング周波数変換をするときの各種パラメータの指定方法です。

 

●窓長を指定
 filter_sizeに窓長を指定します。

>ffmpeg -i in.wav -af aresample=filter_size=64 -ar 48000 out.wav

 

●カットオフ周波数(fc)の指定
 resample_cutoffにカットオフ周波数を指定します。値は出力側のナイキスト周波数に対する比率です。

 下の例では、fc=48K/2*0.9=21.6KHzとなります。

>ffmpeg -i in.wav -af aresample=resample_cutoff=0.9 -ar 48000 out.wav

 

●Kaiser窓のβパラメータを指定
 kaiser_betaにβ値を指定します(2-16の間)。
 なお、βを変更すると窓長も変化するようです。このあたりの挙動は未確認です。

>ffmpeg -i in.wav -af aresample=kaiser_beta=12 -ar 48000 out.wav

 

●FFmpegでSoXと同等の変換を行うときの指定(44.1KHz->48KHzの場合)
 なお、以下は44.1KHz->48KHzの場合となります。
 fcは出力側のサンプリング周波数に合わせます fc=0.96*44.1/48=0.882
 また、複数のパラメータは':'で区切って指定します

>ffmpeg -i in.wav -af aresample=filter_size=156:resample_cutoff=0.882 -ar 48000 out.wav

 

●FFmpegでSoXのリサンプルエンジン(soxr)を使うときの指定
 resampler=soxr を指定します。

>ffmpeg -i in.wav  -af aresample=resampler=soxr -ar 48000 out.wav

 

 

■LINK


| 音声合成一般 | 15:32 | - | - |
サンプリング周波数変換(リサンプリング)技術 - 基本編

Keyword: サンプリング周波数変換、リサンプリング、サンプリングレート変換、アルゴリズム・方法

 

サンプリング周波数変換とは、オーディオデータなどのデジタル信号を、異なるサンプリング周波数の信号に変換する処理のことです。例えば、CD規格の44.1 kHzのデータをDVDの48kHzへ変換するときに使用します。

 

■原理



ここで、サンプリング周波数 fiからfoへの変換を考えます。fiとfoは単純な整数比である必要はありません。
Wikiでは、fiとfoの最小公倍数を求め、ゼロ値の内挿によるアップサンプリングを行い、LPFを通し、間引きする といった方法が示されています。しかし、以下の方法を使えば任意のサンプリング周波数にダイレクトに(ワンパスで)変換できます。

 

サンプリング周波数 fiからfoへ変換するということは、入力サンプルのfi/foおきに入力サンプルの補間値を求めることといいかえることができます。

 

ここで、
 Xn:入力信号のn番目の値
 Ym:出力信号のm番目の値
 X'(t):入力信号の時刻tの補間値(tは実数)
とすると、

formula

 

ここで、m x fi / foを、整数部(n)と小数部(dn)に分ける。

fomrmula

 

このとき、Ymは次式で求められます

formula

 

ここで、

sinc_func

 

 

upsampling

 

 

downsampling

 

 

■解説



繰り返しになりますが、サンプリング周波数 fiからfoへ変換するということは、入力サンプルのfi/foおきに入力サンプルの補間値を求めることです。

 

ただ、ここでの補間は、見かけの滑らかさとは違うことに注意が必要です。直線補間やスプライン補間などは折り返し雑音(エイリアシング)が酷くて実際には使えません。サンプリング周波数変換では式(1.1)と式(1.2)のようにsinc関数というもので補間します。

sinc関数の周波数特性は矩形特性で、カットオフ周波数がナイキスト周波数(fs/2)で急峻に減衰する理想のLPF特性です。

 

sinc関数の周波数特性

sinc_spec

 

ところで、sinc関数ってとても美しい式だと思いませんか。矩形の周波数特性の応答波形を、こんなシンプルな式で表現できます。しかも、いきなり原点が0で割るという、おちゃめな部分もあります。私がこれまでデジタル信号処理に携わってた中で一番お気に入りの関数です。

 

閑話休題。
式(1.1)と式(1.2)は、FIRデジタルフィルタの畳みこみ演算と似ています。違いはフィルタの係数列が固定ではなく、dnによって出力サンプル点毎に変化(シフト)する点です。これにより、フィルタをかけながら入力サンプル間の途中の値を求めているのです。

 

アップサンプリングとダウンサンプリングで式が異なるのは、sinc関数のカットオフ周波数(fc)を、アップサンプリングの場合は入力側のナイキスト周波数(fi/2)、ダウンサンプリングの場合は出力側のナイキスト周波数(fo/2)に合わせるためです。ダウンサンプリングの場合は、sinc関数がfiとfoの比によって横に伸長されたイメージです。

 

ここで、もうお気づきかもしれませんが、sinc関数は無限長のため、このままでは実装できません。なんらかの方法で有限長にする必要があります。

 

sinc関数はxが大きくなるにつれ振幅が次第に減少していく関数なので、適当な時点で打ち切ればよさそうですが、この部分はもう少しテクニックがあります。次回は応用編として、sinc関数を有限長にする方法について書こうと思います。

 

 

■おまけ(実践)


 

ここにWAVフォーマットのファイル in.wavがあるとします(このサンプリング周波数は任意です)。
これを、各種のコマンドプログラムで、44.1KHzのサンプリング周波数のout.wavに変換してみます。

 

FFmpegの場合
> ffmpeg -i in.wav -ar 44100 -y out.wav

 

SoXの場合
> sox in.wav -D out.wav rate 44100

 

AqResampleの場合
> AqResampleCmd in.wav 44100 out.wav

 

なお、最近のFFmpegはSoXのリサンプリングエンジンlibsoxrを内包しています。
以下のように"-af aresample=resampler=soxr"を指定することでlibsoxrを使用できます。

 

> ffmpeg -i in.wav  -af aresample=resampler=soxr -ar 44100 out.wav

 

基本的に、各プログラムの変換結果の違いは、使用している補間の関数(フィルタ係数)の違いとなります。


■リンク


 

| 音声合成一般 | 11:44 | - | - |
音声合成の人気の声種は?

どんな声種が好まれているか、音声合成 AquesTalk pico LSIの出荷実績をもとに分析。
ごめんなさい。一般的な音声合成についての話じゃないです。
単にAQUEST社の、しかも1製品の話です。

一番人気のF4は、半年くらい先行して出したので、その影響が大きいかな。
R4ロボットは、もっと頑張って欲しい。
声の高さやアクセントを変えられる隠しコマンドがあるので、チューニングの楽しみもあるので・・・。
ちなみに、Make Tokyo 2011などで頒布された ATP3010F4-PU は、380個しか生産されなかった希少品ですよ。

| 音声合成一般 | 19:31 | - | - |
音声合成にガ行鼻濁音は必要か?
ガ行鼻濁音、
簡単に言ってしまえば、語中のガ行の音が鼻にかかった音になり、語頭とは異なる音であるってこと(かな)。
発声の立場からは、ガ行の破裂する手前の舌による閉鎖期間に、鼻から息が漏れていて、これに伴い声帯が振動する現象。
音響的には、破裂音の手前が無音にならず、鼻音の周波数特性を持つ有ピッチ成分が生じていること。

これまで個人的には、ガ行鼻濁音にこだわって、これを区別した音声合成エンジンを開発してきましたが、今回改めて考えてみました。そもそも合成音声でもこれを意識する必要があるのだろうかと・・・。

自然とか肉声感を目指す音声合成技術なら別かもしれませんが、
『機械的な声だって綺麗な声であればいいじゃない!』
と基本的に考えている私は、音韻の弁別(合成音を聞いたときの明瞭性みたいなもの)に影響が無いのであれば、ガ行鼻濁音は本来こだわるべき事象ではなかったかも知れません。

というわけで、新版AquesTalkでは、ガ行鼻濁音は無視してみます。
もちろん互換性から、音声記号列仕様上はガ行鼻濁音のよみ記号も残しますが、合成音はガ行もガ行鼻濁音の指定も同じ結果になります。

こんなことすると、日本語が乱れるじゃないか!
まれにそういったご意見もありますね。
一介の音声合成エンジンの開発者が日本語の乱れについて発言するのはおこがましいですが・・・
昔、漢字が24x24のドットで表現されていた時、画数の多い文字は横棒を減らすなど簡略表示してたけど、だからといって、現代の漢字の画数に変化はなかったですよね。同じアナロジーで、合成音声でガ行鼻濁音を無視したって、特に何も変わらないんじゃないかと。実際それよりも、若い人たちの日々の会話による、いわゆる時代の流れのほうがガ行鼻濁音の存続に大きな影響を与えていますよねぇ。
そんなわけで、ガ行鼻濁音にこだわる方々、しばし大目に見てくださいね!

| 音声合成一般 | 00:47 | - | - |
VoiceOverの音声合成エンジンは?
新しい iPod shuffle の目玉の機能の VoiceOver
規則音声合成技術って、これまであまり目立った存在ではなかったのですが、Appleのこの製品によって、今まで触れることのなかった非常に多くの方々がこの技術に触れることは間違いないでしょうね。

さて、Appleはこの音声合成に何処製のエンジンを使っているのでしょう?
(ということは、少なくともウチのエンジンではないということ。残念!)
Appleのホームページによれば、iTunesのMac OS X Leopard版とWindows版では前者のほうが『非常に優れた英語の音声』と書いてあるので、英語のエンジンは少なくとも2種類存在するのですが、日本語の場合もMacとWindowsでは異なるのでしょうか?

今回は、Windows版の日本語のエンジンだけをざっくり調べてみました。

で、判定結果は
 Nuance製 "REALSPEAK" 声種:Kyoko

ここは多言語に強い会社なので、ある程度の予想はついていました。
ということは、他の言語も REALSPEAK なのかも。
なお、聴取して判断しただけですので、もしかしたら間違っているかもしれません。
その際はご指摘ください。


ところで、日本語の合成品質について、色々言われているようですが、
たしかに残念なレベル。
音質云々ってこともあるのですが、それ以前に正しい読みとアクセントがついていないので、何を言っているか判らない。

この分野のエンジニアの立場から言うと、アーチスト名や曲名を正しく読ませるのは至難の業です。文脈から判断することもできませんし、アーチスト名などは、かなり突飛な命名をしてますし・・・
結局のところ、他の知識やルールで読むのは難しく、個々の読み方を辞書に持たせない限りまともに読めないということ。

そこで、
エンジニアリング的に現実的な解決方法として、CDDBに曲名などと共に"よみ"(できればアクセントも) のプロパティ情報を加えるのが簡単かなと考えています。データベースの構築は大変でしょうが、VoiceOverみたいな機能があちこちで使われるようになれば、みんなの協力でなんとかなるんじゃない?

| 音声合成一般 | 15:18 | - | - |
合成音声における『不気味の谷現象』
不気味の谷現象 Wikipediaより
ロボットがその外観や動作においてより人間らしく作られるようになるにつれ、より好感的、共感的になっていくが、ある時点で突然強い嫌悪感に変わると予想した。人間の外観や動作と見分けがつかなくなると再びより強い好感に転じ、人間と同じような親近感を覚えるようになると考えた。

最近になって、この言葉を知りました。
提唱されたのが1970年ということですから、今更ですね。

経験的に、音声合成にも似たアナロジーがあると感じています。
音声合成の技術が未熟だったころは、
 「うん、何を言っているかわかるじゃない!」
のような良い評価も多かったのですが、
技術が進歩して自然音声(人間の発声した音声のこと)に近づくほど、
 「なんか不自然だよね」
という意見が多く聞かれるようになってきました。

個人的には、不気味の谷でいわれる"嫌悪感"というより、むしろ"違和感"という感覚なのですが、人が合成音声を評価するとき、それが自然音声に近づくほど、その差に敏感になっているように思います。

この不気味の谷の概念によれば、今の音声合成の技術は谷の部分にいるということかな。だとすると、音声合成の技術は、いつ、この谷を抜け出すことができるでしょうか?

以前にもちょっと書きましたが、私自身は合成音声に人間の声を目指していないので、
そもそもこの開発競争からは脱落してます。⇒自然な合成音声
| 音声合成一般 | 10:23 | - | - |
音声読み合わせをエクセルで行う
SAPI5に対応したフリーのTTS音声合成エンジンが公開されました。

「ドキュメントトーカ Plus V2.1」 クリエートシステム開発(株)

多少制限があるようですが、これまでフリーのSAPI5対応日本語TTSエンジンは無かったことを考えると、とても画期的だと思うんです。でも、あまり知られていないようなので、ここにちょっとした使い方を書いてみます。

機能的には、AquesTalkに日本語処理を加えてインターフェースをSAPI対応にしたTTSエンジンとなっています。これをインストールすればMicrosoft Officeなどに含まれている音声機能をすぐに利用できます。
入力した表データの音声読み合わせチェックなどができるようになり、これはかなり便利な機能なので機会があれば一度お試しください。

では、インストールから表の読み上げまでを実際にやってみましょう!

今回の動作環境は WindowsXP(Professional)SP2, Excel2003 です。他でも問題ないと思いますが、Vistaはメニューがだいぶ変わっているかと...

1.Excel の読み上げ機能を追加セットアップ
Excelの標準セットアップでは、読み上げ機能がインストールされていませんのでインストールします。もし、Excelの「ツール」メニューに「音声」が表示されるならば、すでにインストールされています。

Excel の読み上げ機能を追加セットアップする方法(Microsoft)

2.ドキュメントトーカ Plus V2.1のインストール
下記から DTALKERPV21.EXE をダウンロードし実行します。
http://www.createsystem.co.jp/DTalkerSapi1.html
インストール先を聞いてきますが、これは一時的な解凍先ディレクトリなのでどこでも良いでしょう。

kaitosaki

次に、解凍した DTalkerPlusV21フォルダ中のsetup.exe を実行してインストールします。
最初に.NETのインストール画面が出ますが、これは「同意する」しかないですね。
それ以降の、選択項目は、デフォルトのままでOKです。

netinstall

インストールが完了したら、ためしに、ドキュメントトーカのアプリを起動してみます。
スタート/ドキュメントトーカ/ドキュメントトーカPlusV2 を実行します。
スプラッシュ画面のあとに次のような画面が出ればOKです。

dtalkerapp

「開始/停止」メニュー /「読み上げの開始」で、音声が出力されます。
デフォルトでは、男声のゆっくりした発声でした。
音が出ないときは、そもそもサウンドを出力できる環境なのかから確認してください。
ここで、ドキュメントトーカのアプリは、いったん終了します。
次は、Microsoft Officeで使用する声の種類と話速を設定します。


3.声種と話速の設定
「コンロトールパネル」/「音声認識」/「音声認識のプロパティ」ダイアログボックスを開きます。
私は、デフォルトの声種を「AquesTalk_女声1」にし、音声の速度を、かなり速めに設定しました。「音声の再生」ボタンを押すと音声が再生されますので、自分の好みの声と速さに調整して「OK」ボタンを押します。

setseisyu

4.Excelで読み上げ
いよいよ、Excelで音声合成を使った読み合わせをしてみましょう。
Excelを起動し、読み上げ対象の文書を開きます。
「ツール」メニューに「音声」/「[読み上げ]ツールバーの表示」をクリックします。

toolbar

あとは、読み上げる最初のセルを選択、あるいは、読み上げるセル範囲を選択し、
「読み上げ」ツールバーの「セルの読み上げ」ボタンをクリックすれば、読み上げを開始します。

playbtn

いかがですか? 音声を聞きながら、目で、元の入力データを確認できるので、楽にチェックができますね!
なお、読み上げの方向を列ごと/行ごとに変更する場合は、「読み上げ」ツールバーのボタンで切り替えます。
| 音声合成一般 | 17:38 | - | - |
自然な合成音声
合成音声の品質について述べるとき、
「より自然な合成音声」とか「もっと自然に」などと
「自然」という単語が頻繁に使われています。

ところで、この「音声」の部分を別の単語に置き換えてみると・・・
「自然な合成食品」 「自然な合成素材」
どうもピンときませんね。
自然と合成ってのが対立しているように感じませんか?

では、「自然な合成音声」って、どういう意味で使ってるのでしょう?
まず、一番近いところが、
人の声に似ている(人間の声っぽい、人間的)
あたりではないかと思います。

そのほかにも、
明瞭である、美しい声、滑らか、などの意味にも使われることもあります。

しかし、
自然な音声は、必ずしも美しく明瞭とは限らないですね。
電話の会話や、会議のやり取りを録音して後で聞いてみれば、
通常、人間が発声している音声が、いかに不明瞭であるかわかるでしょう。

ここからわかることは、
「明瞭な声」とか「美しい声」という表現は、あきらかに「人間的な声」とは異なるベクトルであるということです。

このような理由により、普段何気なく使っている「自然な合成音声」という表現ですが、合成音声の品質を云々するときに「自然」って単語は、あまり使わないほうが良いかなとも思ってます。
「より人の声に近づいた」とか「明瞭さを向上した」などと言ったほうが間違いが無いのではないかな。
もっとも、いろんな理由で、あえて曖昧にしておきたい場合には便利な表現ですが・・・


この話に関連して、人間的では無いけど、美しい、明瞭な合成音声の存在の可能性もでてきます。
人間っぽい声を目指すだけが、音声合成の研究開発の方向性ではないようです。
この話題はまた別の機会に・・・

| 音声合成一般 | 14:58 | - | - |
コーパスベースの音声合成
このところ、コーパスベースの音声合成というのがブームです。
とはいえ、これが世の中に現れてから、すでに10年くらい経っていますが・・・。

コーパスベースの音声合成とは、テキスト音声合成の技術的な方式のひとつで、大雑把に言えば、人間の声を大量に録音してデータベース化しておき、合成するときには、ここから出来るだけ長くマッチする部分を切り出して、それを連結して文章を生成するというものです。

ですから、合成したい文がデータベース中に完全に一致したなら、単に録音して再生しているだけですので、そりゃもう高品質な音声になります。単純な話、この方式では、より高品質な合成音声にするには、データベースを大きくすれば良いのです。

というわけで、コーパスベースでは、どうしても音声合成システムに必要なデータサイズは大きくなってしまいます。普通のシステムでも数100Mbyteはあるでしょうか。現在のコンピュータのHDD容量を考えれば、どうってことないサイズですが、これを数10秒程度のメッセージのアプリケーションで使うには、ちょっともったいない気がしますね。


ここからは、すこし専門的な話。

■データサイズの削減

ところで、コーパスベース方式をやっていると、お客さんから、「データ量を削減できないか!?」という要求が必ずくるようです。
そこで、音声波形をコーデックで圧縮する、あるいは、コーパスのサイズ(文章の量)を少なくしよう考えるわけです。
前者の方法は、全体的な音質の劣化と処理量の増大を考慮する必要がありますが、まぁ正しい選択かと思います。
一方で、後者の方法は、コーパスベースの本質に逆行するアプローチではないかと・・・。

ここで、もし、コーパスサイズをどんどん小さくしていき、マッチする平均長さが音節くらいの長さまで短くなったとしたら、これはもう古典的なCVを合成単位とした音声合成と変わらなくなります。
このように合成単位の観点から考えると、コーパスベースの音声合成とそれ以外の音声合成の明確な線引きって非常にあいまいなものなんですね。
コーパスベースの音声合成の定義は『合成時に"比較的大量の"コーパスから音声を合成する』というあいまいな定義ってことになるのかな?


■もっと、音韻について探求しようよ!

私は、このコーパスベースの音声合成方式を、一つの良いアプローチ方法だと思っています。
しかし、この方式では、技術的課題が「高速な検索手法」、「滑らかに接続する手法」、「コーパスの文の選定方法」などになるため、研究者たちが音声の物理的な側面を見つめることから遠ざかってしまうのが、とても残念に思われます。

このことは、多くの音声認識の研究者が、HMM方式の発明、そしてHTKの普及により、やることは言語レベルのテキスト処理が中心になってしまい、音響分析部分は、そこあるものを適当に使用するみたいな感じになった状況に似ていると思うのです。

しかし、この分野に携わる研究者は、未だに音韻を弁別する物理的特徴が明確になっていないという事実を、常に頭の片隅に置いておく必要があると思います。
例えば、/p/、/t/、/k/のこれら音韻の物理的特長の違いを示せといわれて、ちゃんと答えられる人がいるのかな?どこからも歯切れの悪い答えしか得られないのが現状ではないでしょうか。

音声合成でも、音声認識でも、もっともっと音韻の物理的特長について探求する必要がありますね。
がんばりましょう!

| 音声合成一般 | 15:39 | - | - |
カーナビの音声メッセージ
車を買い換え、カーナビも新しくなりました。

今度のものはエンジンをかけると
「6月11日、日曜日です」
などと言ってくれます。
いずれは、この機能は切ることになるだろうけど、音声合成の見地からしばらくはそのままにしておく予定。

ちなみに、これらカーナビの音声は規則音声合成でなくて録音した音声です。明瞭度もすばらしく、とても規則音声合成には太刀打ちできませんね。
10年位前は規則音声合成を使ったカーナビもありましたが、合成音声の品質と、記録メディアのコストの関係で使われなくなってしまいました。

ところで、ネット上をちょっと検索するだけで、
「ナビの音声を、お気に入りの声優の声にしたい」という要望が多数あるのがわかります。でも実現するのはなかなか大変なのでしょうね。

みんなの好みが同じなら、その声優の声で収録すればよいのですが、
皆それぞれこだわりを持っていて「私は誰々の声がいい」と意見が分かれるに違いない。
たくさん声種を用意したら、ビジネス的に採算が取れないのでしょうね。

| 音声合成一般 | 16:32 | - | - |
PROFILE
Follow
CATEGORIES
LATEST ENTRIES
SEARCH THIS SITE
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND
SONY MDR-CD900ST
SONY MDR-CD900ST (JUGEMレビュー »)

普段これで開発しています。
RECOMMEND
RECOMMEND
RECOMMEND
RECOMMEND