リサンプリング処理をrubatoのものに置き換える

[qryxip]

内容

リサンプリング処理をrubatoのものに置き換えます。

議論: #713 (comment)

Pros 良くなる点

• 24kHzの倍数以外に対応できる
• コード削減

Cons 悪くなる点

実現方法

rubatoを導入し、現在のリサンプリング処理を置き換える。

ENGINEではresampyのfilter="kaiser_best" (デフォルト)でやっているのでそれに合わせる。

https://github.com/VOICEVOX/voicevox_engine/blob/1968353a95d5b93ee27dab8f610b957a9c3edfd3/voicevox_engine/tts_pipeline/tts_engine.py#L189-L192

VOICEVOXのバージョン

N/A

OSの種類/ディストリ/バージョン

• Windows
• macOS
• Linux

その他

同時にhoundも導入してもいいかもしれません。

[Hiroshiba]

ぶっちゃけ信号処理全然知らないので、何をどうすればエンジンと同じ処理になるのかわからないです･････ 😇
まあ･････rubatoのデフォルト設定で良い･･･のかなぁ･･･。

[qryxip]

この話、v0.16かv0.17で実装しちゃってRust APIのpub struct SamplingRateを消し去ってしまいたくなりましたが、まあ必須ではなさそうという思考に至りました。

ちなみに実装は一瞬になるであろうという認識です。品質の評価と、判断のコストが主になりそう。

[qryxip]

0.17で例の「素朴な」リサンプリングを一度消してしまって、リサンプリング機構は存在しないことにしていいかもしれません。これなら判断コストは要らないはず。

その際は「判断コストを割くのすら面倒でやってないだけで、外部からPRをいただけるのであればその限りではない」みたいなフォローを入れたほうがいいかも。
[追記] PRというよりは、要望かな。issueへのコメントでも可。

[Hiroshiba]

なぜ一旦素朴なリサンプリングを消したいのかがわからなかったです！（whyがない）
「何も変えない」が一番コスト低そう？

[qryxip]

滅茶苦茶話が飛んでしまったのですが、このissueのタイトルを「リサンプリング処理をrubotoのものに置き換える」から「リサンプリング処理を実装する（rubotoで）」にして、話をシンプルにできないかなと思ってのことでした。判断コストは要らないと言ったのは、「素朴な」方法は良くないということで合意が取れてる認識だったからです。

ちなみに機構を消し飛ばす場合でもSamplingRate型は存続します。24000以外の値を受け入れてはならないので。

[Hiroshiba]

issueのタイトルを仮に変更しても、このisuseでリサンプリングを消すとこまでやると、後から追った人が混乱するだろうなーという気はしてます。
破壊的変更をした理由がissueタイトルから想像できないので（「リサンプリング処理を実装する」isuseでリサンプリング処理が消されているように見える）。理想は別issueだろうなと。
まあchangelog等に理由を書くんだったら、別にissueがわかりにくくなってても良さそう。

それはさておき、既存の素朴なリサンプリングを消すのはどっちかという賛成です！
must/should/want/canのwantとcanの間くらい。

[Hiroshiba]

評価方法をちょっと考えたのでメモまで！
ここに音声をアップロードして @Hiroshiba が判断する、が手っ取り早そう。

• rubatoの設定を頑張る（これが一番難しそう、ChatGPTに聞くのが確実そう。。。）
• ずんだもんと青山龍星のノーマル音声を24kHzで生成、12kHz・16kHz・44100Hz・48kHzにリサンプリング
• 元音声とともに、librosaとかでspectrogramにする
• 元音声のスペクトログラムの差だとかを可視化する