Kazuhiro KOBAYASHI

MLPGの逆行列計算のところで使って，どの程度早くなるか確認してみます．その後，GMM周りの逆行列計算の修正も実施するかと思います．

いえ，このままissueを残して，論文に対応する数式番号のコメントを追記しましょう．

librosaのドキュメントとてもいい感じだね．Themeも選べる様なので，読みやすいやつを探すと良さそう．librosaのドキュメントのドメインが，librosa.github.ioになってるのは，pages.github.comをホスティングとして利用しているからなのかな？ librosaは，古参サービスっぽいけど，よくまとまってる様にみえるので積極的に真似していきたいね．

コメントを比較的追加したcleanブランチでmakeして生成されたdocsを下記のブランチにpushしましたhttps://github.com/TakedaLab/sprocket/tree/docs． themeは， デフォルトが読みにくい感じで，https://github.com/guzzle/guzzle_sphinx_theme が見やすそうだったのでGuzzleに変更しました．

毎回，適当なところからコピーして使いまわしているので雛形を作っておきたいと思います．オススメの雛形があればレコメンドください． コメントテンプレート for function '''処理の説明. Parameters ---------- arguments1 : np.ndarray [shape=(`T`,)] 説明 arguments2 : scalar, int > 0 max of row of `arguments1` Returns ------- return1 : np.ndarray [shape=(`T`, `dim`)]...

Thanks. 一通り目を通してみます．

ご意見ありがとうございます．このレポジトリの今後の方向性を考えるのに非常に重要な意見かとおもいます． そもそも何故sprocketの開発を始めたかというと，Voice Conversion Challenge 2018(予定)のベースラインシステム（VCC2016のチャンピオンシステムを少し改良した手法 [Kobayashi et al., SLT 2016]）として，再現性のあるコードを提供する事が目的です．第一に，私が重要だと思っていた点として以下があります． 1. VCC2018のために．SLTで提案した手法を再現出来る事 2. 動的時間伸縮で結合特徴量を作成出来る事 3. 現状の高品質な分析合成系を使える事 とりわけ，2に関しては，最近の論文には，記載されていないノウハウ（e.g., 変換特徴量と目標特徴量を用いた再アライメント，パワーが小さい部分の削除してのDTW）などを入れる事で，声質変換の研究の裾やを広げる上で重要かと思いました．また，最近の研究では，Model部分に関する研究が多く行われており，sprocketで得られた結合特徴量を用いて，Modelの研究に取り組めるのではないかと考えております． 3.に関しては，sprocketでは，上を満たすものであれば，どの分析合成系を用いても良いかと考えています．とりわけ，sprocket内で，様々な分析合成系を切り替えて用いる予定も現状はありません．一方で，例えば，world mcepで学習を実行し，中間ファイルとして得られたtwfを用いて，任意の音響特徴量の結合特徴量を作成するインターフェースは，用意出来ればと考えております． --- - そもそもどういう使用方法を想定するのか？ライブラリとしての使用（import hoge のような使い方）？それともコマンドラインツールとしての使用？ or 両方？ import hogeの様な使い方を想定していました．イメージとしては，scripts/src/train_GMM.pyのGMMTrainerの部分をDNNTrainerなりNMFTrainerみたいなのをユーザが実装して，結合特徴量jntを使って学習すれば良い様にしたいです． -...

> 今後の方向性として、一つの案としては、このリポジトリでは2にフォーカスする、というのがいいと思いました。1は、そのライブラリを活用した一例として、再現性を担保する目的で、別リポジトリに切り分ける、という方法です。現状、両者を一緒にしてしまっていることが良くないように思います。特に、リポジトリトップ/sprocket と リポジトリトップ/scripts/src の2つを整理する必要があると思います。この方針は、汎用性を担保しやすい一方で、声質変換におけるごく一部のパートのみを提供することになり、ユーザが自分で書かないといけないコードはそれなりに多くなります（特徴抽出、モデル学習、変換、合成、etc）。研究者向けなら、何の問題もないとは思いますが、一般ユーザも対象にする場合は、優しくないかもしれません。3は、WORLDを使うことで自然と達成されると思います。 今，リポジトリトップ/scripts/srcの中にあるスクリプトは，特徴抽出やモデル学習などの，それぞれ独立した処理となっています．想定してるユースケースとしては，このスクリプトの一部（例えば，extract_feature.py）をユーザが自前で書き換えて，新たな特徴量に新たなラベル'mcep_refined'をつけてh5に入れる事で，その後の処理が動けばよいと考えています． > この部分をもっと具体的にする必要があると思います。GMMTrainerに関しては、モデルと変換を分けるのはもちろん、ファイル入出力も切り離すべきだと思いますが、 おっしゃる通りです． > それはさておきとして、現状では、XXXTrainerを作るにしても、何のメソッドを実装すればいいのか非自明 XXXTrainerの名前が悪かったかもしれません．jntを使ってユーザがDNN.train(jnt)やDNN.convert(x)などの関数を実装して，ユーザの領域で学習と変換を実現すれば良いと考えています．言い換えると，sprocketは，ユーザにjntやxを提供する機能だけを持つという事です． > GMMTrainerはJointFeatureExtractorでも使われているので、例えばGMMではなくDNNを使いたい場合は、JointFeatureExtractorを修正する必要がある ここで，仮にDNNを変換モデルとした場合でも，JointFeatureExtractorは，GMMによる変換特徴量を使ってtwfを抽出しjntを得る事を考えています．その後，ユーザがDNNなどで学習変換して，その変換特徴量をJointFeatureExtractorやそれに準ずる未作成の関数に渡す（e.g., jnt.twf_refine(cv_x, tar)）と新しいtwfが作成され，それに基いてjntを再抽出できるインターフェースを用意すれば良いと考えています．もしくは，JointFeatureExtractorクラスを削除して，ユーザ側（つまり, scripts/src/estimate_twf.py）に全ての処理をsprocketの関数を利用して実装すれば，DNNによる学習・変換は容易かと思います． > 僕ならBaseTrainerのようなクラスを作り、ユーザはそのクラスを継承していくつかメソッドを実装すればOK、といった設計にします。JointFeatureExtractorは、GMMTrainerではなくBaseTrainerなら何でも動くように実装します。 JointFeatureExtractorに異なるTrainerClassやConverterClassを与えるのは，色々と変換システムを切り替えられるので良いアイディアと感じましたが，ユーザに，sprocket内の流儀に従うコードの実装を出来る限りさせたくないと考えています（実際，その様に実装は出来てないと思いますが）．

> なるほど理解しました。ただ、sprocketの機能を結合特徴量の提供にフォーカスするのは良いと思いますが、その場合、scipts/src内のスクリプトを書き換えて使用する、というユースケースは、ふさわしくないのではないでしょうか。スクリプトには結合特徴量の抽出以外の処理が多くあり、それを使わせるということは、（結合特徴量の抽出以外の機能を提供しているという点で）そもそもの目的に反するように思います。また、ユーザにsprocket内の流儀に出来る限り従わせたくないという意味でも、スクリプトの使用を想定する場合、決まったディレクトリ構造、ファイルフォーマット等をユーザに強制することになってしまいます。 その通りですね．そもそもの弊害は，一連のVCを動作させるために各要素（特徴抽出やGMMの学習変換）を密結合して実装していった事にあると思います．加えて，confの様な処理に必要なパラメータを謎のクラスにまとめてしまった事もかなり良くなかったと思います．前言のjntの抽出に焦点を当てたものとは異なりますが，sprocketに関しては，VCの基盤となる関数やクラスを提供する枠組みとして捉え，他のレポジトリでsprocketを利用した差分VCの実装を実施するべきな気がしてきました．とても良くいうとsklearnのVC専門の様な感じが理想的かもしれません． たとえば，import sprocket as spr と宣言して，gmm = spr.model.GMM(混合数など）を読み込むと，gmm.train(jnt)やgmm.convert(x)が出来るような枠組みをsprocketでは提供出来ればと思います．他にも，feat = spr.feature(fs = 16000)みたいなf0= feat.f0analysis(x, mode='sptk')とユーザに簡単に分析処理が実現できる様なクラスを提供出来ればと思います．（特徴量に関してはラッパーにがほとんどになると思いますが）．JointFeatureExtractorをsprocket内に用意するかに関してはかなり微妙なラインですが，デフォルトをGMMとして，sprocket内にspr.model.DNNが実装された場合に変換システムを変更出来る様な枠組みのクラスと捉えると，ユーザー側には不便に感じるかもしれませんが，そういったクラスを用意出来るかもしれません．また，dtwなどは，現在は，xとyのフレームの重複を許す仕様になってますが，どちらか片方の重複を許さない場合（つまりjoint featureの長さがlen(x) or len(y)になる）様な関数も用意しておけば，深く使う人にとっても有意義なframeworkになる気がします． あとは，他のレポジトリにsprocketを使った1-to-1VCやEVCなどを実現出来るコードを用意すると良いかと思います．

とりあえず，script内は結合テストのコードの様にみなして，本番公開時には別レポジトリにわけると良いと思います．