Refactor: 合成系モジュール群のディレクトリ構造統一

[tarepan]

内容

要望: 合成系モジュール群のディレクトリ統一によるリファクタリング

現在の voicevox_engine は合成（日本語文/kana <-> アクセント句系列 -> 音素長・音高 -> 音声波形）機能をステップごとのモジュール（.pyファイル）に集約して管理している。
以下はモジュールのディレクトリ構造に基づいた一覧である：

• voicevox_engine
  • synthesis_engine
    • core_wrapper
    • synthesis_engine_base
    • synthesis_engine
  • acoustic_feature_extractor
  • mora_list
  • kana_parser
  • full_context_label

一方でこれらのモジュールの依存関係は以下になる：

`synthesis_engine` <-------------------- `acoustic_feature_extractor`
                             ,----------`full_context_label`
`synthesis_engine_base` <----'------.--- `mora_list`
`run.py` API <-- `kana_parser` <----'

すなわちcaller側の synthesis_engine / synthesis_engine_base が深い階層に、callee側のモジュールが分類の無い浅い階層に存在している。
このモジュール階層構造には依存関係の識別性を向上させる余地がまだある。

このような背景から、合成系モジュール群のディレクトリ統一によるリファクタリングを提案します。

Pros 良くなる点

• 機能ベースのモジュール構造による見通し改善
• import文の簡略化

Cons 悪くなる点

• 無し

実現方法

以下のディレクトリ構造を提案（module_nameは名称変更)：

• voicevox_engine
  • synthesis
    • core_wrapper
    • synthesis_engine_base
    • synthesis_engine
    • acoustic_feature_extractor
    • mora_list
    • kana_parser
    • full_context_label

VOICEVOXのバージョン

0.14.10

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

• Windows
• macOS
• Linux

[Hiroshiba]

良いと思いました！
今はvoicevox_engineディレクトリに結構いろんなファイルが入っているので、synthesis_engine系のをまとめて何かのディレクトリに入れるのは賛成です。

ディレクトリ名称について5分くらい考えてみました。
これらの群はテキストを解析する機能（TextAnalyze）、コアを使う機能（CoreWrap）、AquesTalk風記法を解析する機能（？）、音声を合成する機能（Synthesis）などが備わっています。
これらの機能をうまく分離した名前が思いつかないでいます･･･。
とりあえずひっくるめてsyhthesis_engineかengineあたりも候補なのかなと思いました。
ただまあそうすると今のsyhthesis_engine.pyが被りますが、まあ良いかなと！
（これがJSとかならindex.jsにするのですが）

[tarepan]

まとめて何かのディレクトリに入れるのは賛成

👍

音声を合成する機能（Synthesis）

（CoreWrapperはTTS以外の機能も担っているので一旦除外して考えます）
特徴量から音声波形を生成するサブプロセスの名称は「合成（Synthesis）」というより「Vocoding」がズバリかと思います。
音声合成の一種であるTTSという語が一般的に「TextAnalyze-pitchEstimation-Vocoding の流れ全体」を指してる的な考えです。

ひっくるめてsyhthesis_engineかengineあたりも候補

engine という語からかなり曖昧な印象を受けます。
キャラクター音声合成系出身のコントリビューターさんだと engine という語が「音声合成エンジン」とすんなりわかる的な背景があったり…？

この議論を経て私が妥当そうに感じるディレクトリ名称案が以下になります：

• synthesis
• text_to_speech
• synthesis_engine

（ディレクトリ名称の議論は短期的に無意味でも長期的なリーダビリティに大きく影響するので、慎重めに議論したいです）

[Hiroshiba]

（ディレクトリ名称の議論は短期的に無意味でも長期的なリーダビリティに大きく影響するので、慎重めに議論したいです）

なるほどです、賛成よりです！

---

名称に関してですが、確かにエンジンという言葉は何でもかんでもありで、managerくらいの汎用性を持ってしまっているだろうなとは感じます。
ただまぁ正直なところ、このディレクトリの中に入る全ての機能をうまく言葉にすることはできなそうに思います。
なのでまあ、その区分に何が含まれるべきなのかをドキュメント化する（コメントで書く）しかないのかなという気持ちです。

あとは代表的な機能の名前をファイル名にするか、逆に汎用的な名前をファイル名にするかですが、この二択だったら後者かなと･･･。（特にそういう指南を受けたわけじゃないですが･･･。）

---

synthesis

個人的にはこれは音を作るものなイメージがあって、テキストを解析する能力を持ってないイメージがあります。

text_to_speech

AudioQueryを返せるより汎用的な概念であるということが分からないかもと思いました。

synthesis_engine

この三択だとこちらが一番無難かなと思いました。

音声合成の一種であるTTSという語が一般的に「TextAnalyze-pitchEstimation-Vocoding の流れ全体」を指してる的な考えです。

こちらも賛成です！　tts_engineでも良いかも･･･？

[tarepan]

正直なところ ... 全ての機能をうまく言葉にすることはできなそう

はい、同意です。この新モジュールが多数のAPIから利用されるのもその証左だと感じます。

逆に汎用的な名前をファイル名にする ... かなと･･･。

👍

synthesis_engine

「synthesis ... これは音を作るものなイメージ」という意見と「汎用的な名前をファイル名」という意見がコンフリクトしているように見えます。
synthesis_engine == 「音を作るエンジン」であるため、むしろ「代表的な機能の名前をファイル名」に近い命名と感じます。

AudioQueryを返せるより汎用的な概念であるということが分からないかも

「パイプライン」という概念はどうでしょうか？
End-to-End時代以前のTTSだと、音声合成を5つくらいの副問題/サブモジュールに切って解く的な考えが一般的だったかと思います。
こういう「ブロックの組み合わせで流れを作って、途中のブロックから入出力したりもやろうと思えばできる」のをパイプラインと呼ぶ気がします（wikipedia/音声合成#パイプラインモデル）（bashのpipelineも同じか）。
text-to-speech が中間要素の入出力を想起できないという問題をこの概念で緩和できたりします...？

これらの議論を経て（議論しても最高の結論は存在しなそうという合意も見つつ）次の名称を提案します：

• tts_engine
• tts_pipeline

[Hiroshiba]

「synthesis ... これは音を作るものなイメージ」という意見と「汎用的な名前をファイル名」という意見がコンフリクトしているように見えます。
synthesis_engine == 「音を作るエンジン」であるため、むしろ「代表的な機能の名前をファイル名」に近い命名と感じます。

確かにです！　（なぜかsynthesis_engineをsynthesis+engineだと感じていました）

「パイプライン」という概念はどうでしょうか？

なるほどです、結構直感に合いそうです！！

tts_engine
tts_pipeline

どちらも良いと思います！
ディレクトリ名をtts_pipelineに、今のSynthesisEngineを（大文字どうするのが良いか不明ですが）TTSEngineと呼ぶのもありかもと思いました。

[tarepan]

結構直感に合いそうです！！

👍

ディレクトリ名をtts_pipelineに、今のSynthesisEngineを（大文字どうするのが良いか不明ですが）TTSEngineと呼ぶのもありかもと思いました。

👍
ディレクトリ構造変更のissue/PRなので、一旦ディレクトリ構造/モジュール名に絞った変更をPRします。
新ディレクトリ/モジュール構造は現時点で以下の予定です：

• voicevox_engine
  • tts_pipeline
    • core_wrapper
    • tts_engine_base (from synthesis_engine_base)
    • tts_engine (from synthesis_engine)
    • acoustic_feature_extractor
    • mora_list
    • kana_parser
    • full_context_label

依存PR一覧

以下のPRsに依存しているため、これらマージ後に着手します：

• 整理: Coreロードの型付け・変数名 #805
• 廃止: OjtPhoneme start / end #811
• 整理: .mutex 移植 #813
• 整理: docstring追加 #817
• 整理: グローバル特徴量適用の関数化 #819
• 整理: Query全体パラメータ適用の移植 #840
• 整理: pre_process の細分化 #851

[tarepan]

追記:

#840, #851 が新依存になっているため、これら解消後に着手します。
また #825 と合体した PR を提出する予定です。