話速の変更とピッチの変更は、ピッチとセマンティクスが変更されないままで、話速が速くなったり遅くなったりすることを意味します。この過程は、スペクトログラムが時間軸上でアコーディオンのように圧縮または拡大することで表されます。つまり、同じピッチに対応する基本周波数の値はほとんど変化せず、時間経過全体が圧縮または拡張され、声門サイクルの数が減少または増加、つまり声道の移動速度が変化し、それに応じて発話速度も変化します。 .
予備調査の結果、可変速度と一定のチューニングの機能を実現できる 2 つのソリューションがあります。sonic、soundTouch のいずれも、pcm オーディオ ファイルの処理に使用され、wav 形式をサポートし、pcm データ処理のデコードに適しています。
オプション 1: ソニック
- 処理後のファイルサイズは倍速値に反比例します。
- 音響処理単位はフレームであり、一部のデータが失われる可能性がありますが、これはアルゴリズムが原因であると推定されます。
- 導入は比較的簡単です。メイン関数は c 言語で記述されており、使用する c ファイルと .h ヘッダー ファイルをインポートするだけで済みます。
- 加速後の音質はsoundTouchより悪いです。
ソニックはオーディオストリームをリアルタイムで処理します
Sonic はストリームを定義し、まずストリームを作成し、サンプリング レートとチャンネル数を入力します。次に、フローの関連パラメータ (速度、ピッチ、レート) を設定します。オーディオ ストリームをリアルタイムで処理する場合は、入力と出力のsonicWriteToStream()
2 つの関数を使用します。sonicReadShortFromStream()
質問:
- 音質の損失の問題については、実験により、元の 2048 バイトのデータは 2 倍に加速された後に 1024 バイトのデータになるはずですが、実際の出力は 480 または 1380 である可能性があり、データはは等しくありません。
参照:
解決策 2: サウンドタッチ
- 処理されるファイル サイズは、速度の値に反比例します。
- リアルタイムのオーディオ データを処理できますが、入出力遅延は約 100ms です。
- インポートはソニックよりも複雑で、ライブラリをインポートして使用する必要があります。
- 加速後の音質低下は基本的になく、聴覚の効果はソニックよりも優れています。
SoundTouch はオーディオストリームをリアルタイムで処理します
ST のオーディオ処理は、入力関数 putSamples() と出力関数 receiveSamples() です。オーディオ ストリームをリアルタイムで処理するという考え方は、オーディオ データ セグメントを周期的に読み取り、出力用に ST に入れ、処理されたデータ セグメントを再生用に出力することです。
soundTouch にバッファリングされたデータは、取り出す前に処理する必要があります.異なる sequence_ms と overLap_ms の時間の長さは矛盾していますが、最初に soundTouch に入るデータには判断があり、一部のデータが TDStretch で傍受されます。
SoundTouch:feature: リアルタイムオーディオストリーム処理が可能:
- 入力/出力遅延最大。〜100ミリ秒。
- 44.1kHz/16bit ステレオ サウンドをリアルタイムで処理するには、400 Mhz Intel Pentium プロセッサ以上が必要です。
リアルタイムオーディオ処理にSoundTouchを使用するには?
リアルタイム入力サンプルが利用可能になるとリアルタイム システムによって呼び出される処理関数を作成し、この関数が「 putSamples 」関数呼び出しでリアルタイム入力サンプルを SoundTouch パイプラインに入れ、リアルタイム出力処理のために結果の出力サンプルを抽出するために「 receiveSamples 」関数を使用します。 .
質問:
- 重要な問題は、パケットをフェッチする間隔で毎回パケットをフェッチすることができないことです. 特定のバッファがあり、その加速されたオーディオデータは、0, 2048, 0, 2048, 0 ... のように不連続です.この場合、高速化されたデータをフェッチする際に 1 対 1 の対応が得られない場合があります。
- soundTouch のサンプリング レートを入力オーディオの半分に変更すると、不連続性がなくなり、毎回取り出されるデータは 1024、1024、1024、1024、1024、... と表示され、トーンは変化しません。
- いくつかの短いフレームの加速では、効果を高めるためにスムージングが必要になる場合があります。
参照:
考える:
- ジッターと遅延を判断できるかどうか、ジッター遅延が比較的大きい場合にオーディオ アクセラレーションを使用すると、それ以外の場合は使用されなくなります。
- soundTouch でサンプリングレートを半分に設定することはできますか? さらにテストが必要です。
- 1対1の対応は厳格な指標であるため、他の実行可能な解決策を見つける必要がありますか?
入れたデータと取り出したデータが対応するデータであることを確認するには?
-
カウントによって加速する空のデータを入れ、現在のカウント値で加速されたオーディオを取得し、同時にファイルに書き込み、ファイル内のオーディオが空であるかどうかを観察します (無音として表現されます)。
-
結果:
- テスト後、各加速後のソニックのサイズに一貫性がなく、データに一貫性がない場合、加速されたデータは元のデータに対応できません。
- 各加速後のsoundtouchのデータサイズは安定していますが、間隔があり、観測とテストの結果、間隔は1パケットです。対応調整によりsoundTouchのデータは対応していますが、加速したオーディオの前後の位置が融合していない問題と、それによるノイズ問題の解決方法です。
- テスト後、各加速後のソニックのサイズに一貫性がなく、データに一貫性がない場合、加速されたデータは元のデータに対応できません。
-
ノート:
SoundTouch の設定を調整するには、soundtouch のヘッダー ファイル SoundTouch.h に設定項目があり、soundTouch のいくつかのパラメーターも解析され、公式 Web サイトに記載されています。TimeStretch を使用してテンポを変更するだけでよいため、必要に応じて sequence_ms、seekWindow_ms、および overLap_ms を変更して、独自のニーズを実現できます. TimeStretch 自体にも、サンプル ポイントの精度を達成するために変更できるパラメーターがいくつかあります.
バッファリングが完了した兆候は何ですか?
- 高速化されたデータが空でない場合は、バッファリングが完了し、データをフェッチできることを意味します。
補充:
可変速度一定チューニング アルゴリズム:
時間領域法 | 周波数領域法 | パラメトリック法 |
---|---|---|
クリッピング | LSEE-MSTFTM | フェイズボコーダー |
SOLA、SOLA-FS | 正弦波モデル | |
TD-プソラ | ||
WSOLA |
ピッチブレイクと位相不連続の問題を軽減するために、VerhelstとRoelands はPSOLAよりも計算量が少なく、同時に出力音声品質が高い波形類似度重ね合わせ法 ( WSOLA ) を提案しました。Grofit はこの方法を改良し、音楽信号の可変速度処理にも適しているようにしました。
SoundTouch は WSOLA アルゴリズムを使用します
結論は:
sonic ではデータが不均等であるという問題があるため、リアルタイム アクセラレーションのシナリオには適していません. soundTouch は、バッファ内のすべてのフレームに対して波形類似性重ね合わせアルゴリズムを実行することを考慮して、取得されたデータの先頭は、通常のオーディオと加速されたオーディオがインターリーブされると、ピッチブレイクが発生します。そのため、次の 3 つのスキームが設定されました。
-
高速化する音声フレームのみをsoundTouchに入れ、取り出した後に通常の音声と一緒に再生キューに入れると、ピッチが崩れます
-
すべてのオーディオをsoundTouchに入れて加速し、必要なデータのみを取り出しますが、必要なデータは加速されたオーディオの融合を参照し、元のファイルが書き込まれるため、ピッチブレイクの現象が発生します。スムージング ディールを使用するにはまだ必要です。
-
すべてのオーディオをsoundTouchに必要な加速度分入れ、不要なテンポを1に設定すると、ピッチブレイクの現象はなくなりますが、テンポの頻繁な変更により音質が低下する場合があります。
スキーム 1 波形図:
オプション 1 スペクトル周波数: (図の明らかな垂直バーは、ピッチが途切れる場所です)
スキーム 2 波形図:
シナリオ 2 スペクトル周波数:
スキーム 3 波形図:
シナリオ 3 スペクトル周波数:
補充:
Soundtouch は TDStretch を使用して速度を変更します. TDStretch では、初期化中に判断が行われることがわかります. TDStretch では、データの後半部分が最初に soundtouch に入力されます (具体的な量は、設定されたテンポやその他のパラメーターによって異なります)。 midBuffer の最初の 1 つの入力中に出力されるサンプル ポイントの数は、期待される出力サンプル ポイントの数と等しくないため、次の出力の前半として midBuffer が使用されます。 、および overload_ms を使用すると、midBuffer のサイズを縮小することしかできません。
テンポの変更について考える方法は、すべてのオーディオを soundTouch に渡し、テンポを通常のオーディオの場合は 1 に設定し、加速されたオーディオの場合は 2 に設定することです。出力時、最初に 1024 サンプル ポイントを入れたので、512 サンプル ポイントが取り出されるはずでしたが、320 サンプル ポイントしか取り出されなかったので、192 サンプル ポイントは、次に取り出される高速化されたキャッシュに残っています (波形類似アルゴリズムによって次の入力データ スライスと重ね合わせられます)、最初が通常のオーディオの場合、soundTouch の後の通常のオーディオの最後で 192 サンプル ポイントが欠落し、192 サンプル ポイントが欠落します。データ間の連続性が維持されるため、加速されたオーディオ サンプル ポイントの先頭でピッチ ブレークが発生しません。ただし、入れたデータと同時に取り出したデータは1対1で対応するわけではなく、いつでも出し入れすることはできず、前後のデータの連続性を確保することしかできません。 .