スポンサーリンク

T.Ishii's Software Library

HTML5 レトロ風ゲーム館

無料ブログはココログ

« Apple MusicをUbuntuで! | トップページ | ブログのデザインを変更 »

速度変更処理の変更

今は、AmuseGraphics Ver1.4.1の開発フェーズで、macOS版AGMPlayerに続き、macOS版AG-ムービーカッターのリリースも間近な感じなのだが、速度変更機能の音質改善に拘ったりしているので、リリースには、まだ数日かかる。

一昨日書いた様に、現状のAG-ムービーカッターの音声速度変更機能は、速度を0.5倍程度以下にした場合に、iMovieやChromeのYouTubeプレイヤーなんかの速度調整機能と比べると、音質が悪い。

どう悪いのか、というと、例えば、速度を0.5倍にすると、変更後の音の繋がりが悪い感じで、周期的に若干のノイズが乗ったりする事があるし、速度を0.25倍にすると、音が潰れた感じになって、特に、低い周波数の音はブザー音の様に聞こえてしまう様な事もある。

上記の様な現象が何故発生するのか、というと、例えば、速度を0.5倍にすると、そのままだと、音声の周波数も0.5倍になってしまって、聞き取りづらくなるので、ピッチ補正を行なって、速度変更後の音声の周波数を2倍にするのだが、この処理はどうやって行なっているのか、というと、音声データをFFTして周波数領域データに変換し、周波数領域で、各データを周波数が2倍になる位置にシフトし、そのデータを逆FFT変換して時間領域のデータに戻している。

問題は、FFTを行うためには、周波数を分析できる程度の期間のデータが必要になるので、例えば、100Hzの周波数データを分析しようとすると、少なくとも、その周期分の10mSec分のデータは取得する必要が出てくる訳だ。

もっとも、実際の所としては、それでは不十分で、その数倍程度の期間のデータをFFT対象としないと、周波数分析は正しく行えない可能性が高くなるのだが、この期間をあまり長くしすぎると、途中で音声データの周波数が色々と変わってしまうので、ピッチ変更した結果を逆FFT変換して得られるデータは、可笑しな感じになってしまう事が多くなる。

と、いう事で、ピッチ変更するために行うFFTの対象時間は短すぎても駄目だし、長すぎても駄目で、例えば、一昨日書いた、FirefoxのYouTubeプレイヤーの速度変更音声が変な感じになっているのは、多分、FFTの対象期間を長くしすぎているからだ。

で、現行版のAG-ムービーカッターの速度変更機能で音質が悪い理由の1つとしては、上記のFirefoxのYouTubeプレイヤーとは逆で、対象時間が短すぎる、というモノがある。

つまり、前述の様に、速度を落とすと、音声の周波数が低くなるので、その分、FFTの対象時間を伸ばさないと、周波数分析が雑になってしまうのだが、現状のAG-ムービーカッターの速度変更機能では、そのための対処を行なっていないので、速度を低下させた場合には、音質が悪くなってしまう訳だ。

もっとも、問題はそんなに簡単な事ばかりではなくて、FFTでは、分析対象期間の波形は無限に繰り返されている、という事を前提にしているので、何も考えずに、時間領域のデータを採取して、その都度、その領域分をFFT変換/逆変換していると、各時間領域用の出力データの波形の繋がりが悪くなる。

その結果として、定期的にノイズが乗ったりするのだが、一般的には、この問題を解決するためには、窓関数というモノを使う。

具体的には、データを取得する領域の最初と最後のデータの大きさが0に近くなる様に調整したデータをFFT変換する事にする訳だ。

そうすれば、周波数分析としては、かなりの低周波部分に何かしらのデータが出てくる事はあっても、それ以外の領域については、比較的正しいデータが得られる様になるのだが、逆変換すると、当然、前述の様なデータに近いデータしか得られない。

つまり、定期的に音量が0になるので、音が揺れている感じになってしまう訳だ。

もっとも、上記の様な問題を回避する方法もあって、その方法というのは、オーバーラップという手法で、前述の窓関数としてSin窓を使い、オーバーラップFFTとして、データの半分が遅延した別FFTを行い、それらを再度Sin窓にかけた結果を合計する事で、窓関数の悪影響を回避しようとするものだ。

つまり、Sinの二乗+Cosの二乗は1になるので、上記の合計値は、常に、元々のデータの大きさと同じになる事になるので、窓関数の悪影響はなくなる訳だ。

ただし、上記の2つのFFTでは、対象としている時間領域が異なるので、それらから逆FFT変換して得られる時間領域データというのは、正確には、同じ時間データにはならない。

なので、この方法を用いても、完全にマトモな処理結果は得られないのだが、現状のAG-ムービーカッターの速度変更処理では、そもそも、窓関数すら、使っていないので、速度を0.5倍程度にした場合には、各時間領域のデータが不連続な感じになって、ブチブチとノイズが乗ったりする事になる訳だ。

しかし、上記のオーバーラップFFTを用いたとしても、異なる時間領域の解析結果を合算している格好になる分、出力データの音は揺れている感じになってしまう訳だ。

で、上記の様なやり方は、至極一般的に、用いられている筈なのだが、前述のiMovieやChromeのYouTubeプレイヤーでは、速度を0.25倍に変更しても、あまり音質の低下がない訳だ。

まあ、少しは揺れている感じが判るかもしれないのだが、AG-ムービーカッターに上記のオーバーラップFFTを適用した場合と比べると、その揺れている感は少ない訳だ。

もっとも、上記の音を聞いていると、何か変だ、と、感じる人も多い筈で、少なくとも、AG-ムービーカッターの出力音と比較した作者はそう感じたのだが、上記の音には、リバーブがかかっている感じになっている。

で、作者的には、なるほどなあ、と、思ったのだが、リバーブというのは、遅延させた音声と通常音声をミキシングして得られるエフェクト効果の一つなのだが、この効果を適用すると、少し前の音と現在の音を平均化できるので、上記の様な音が揺れている感じをなくす事ができる訳だ。

と、いう事で、AG-ムービーカッターの速度調整機能では、オーバーラップFFTを適用し、かつ、その出力音にはリバーブ相当のエフェクトを入れる事で、周期的な音が揺れている感じを低減させたので、現行版と比べると、速度を低下させた場合の音質は、結構、よくなったのだが、iMovieとChromeのYouTubeプレイヤーと比べると、まだ、少しは劣る感じだ。

なので、もう1日くらいは、調整してみるつもりではあるのだが、実際の所としては、あまり重要な機能でもないので、良い案が出てこない場合には、上記の対応だけで変更は完了、という事にする予定だ。

« Apple MusicをUbuntuで! | トップページ | ブログのデザインを変更 »

2019年10月
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

広告

プライバシーポリシー

  • 当サイトでは、第三者配信による広告(Google Adsense)サービスを利用しています。

    Google を含む第三者配信事業者は、Cookie を使用して、ユーザーのウェブサイトでの閲覧履歴に基づく広告を配信します。 Google 広告 Cookie を使用することにより、Google や Google のパートナーは当サイトや他のサイトへのアクセス情報に基づく広告をユーザーに表示できます。

    収集された情報がGoogleによってどの様に使用されるか、収集される情報をユーザーが管理する方法については、以下のリンクを参照下さい。

    ポリシーと規約 - Google