Ryuichi Yamamoto
Ryuichi Yamamoto
I guess people already have done several experiments with enunu though, I'd like to try it and make reproducible recipes in nnsvs. It should be conceptually pretty easy to implement.
https://wenet.org.cn/opencpop/ It would be great if we can support Mandarin SVS using opencpop database.
This is an umbrella issue to track progress and discuss priority items. Comments and requests are always welcome. ## MIlestones - [x] ~ 4/26 (Sun): Refactor my jupyter-based code to...
Inspired by https://arxiv.org/abs/2110.08813 From their abstract: > Finally, to improve the singing rhythm, we modify the duration predictor to specifically predict the phoneme to note duration ratio, helped with singing...
Samples: https://soundcloud.com/r9y9/sets/nnsvs-and-neutrino-comparison While I was looking into the differences from nnsvs and neutrino samples, I noticed that there are MUCH room for improvement in the acoustic model. I will put...
I don't have any ideas yet, but I'd like to explore some speech-to-singing methods as a research project (IF I HAVE TIME). It would be very nice if we can...
https://r9y9.github.io/blog/2017/10/05/ganvc/
このリポジトリの目的
このリポジトリのコードが提供する目的を、明確にしませんか？という話です。僕は主に、研究者がコードを公開する上で、以下の２つの意義があると思っています。 ## 再現性の保証 Code to reproduce XX paperといったように、論文の実験結果を再現するためのコード、という位置付けです。例えば深層学習の分野では、`xxxNet`などという名前で、日々アップロードされています。ベースラインとして他の研究の役に立つので、とても価値があると思います。 ## 汎用的なツールの提供 他の研究の役に立つ汎用的なツールとして、 の位置づけです。音声分野では、SPTK, HTSなどが相当します。例えばSPTKは、小さな音声処理のプログラムを（シェルのパイプによって）組み合わせることによって、音声処理における多くの問題に汎用的に使用できるように設計されています。他の研究の役に立つので、これもとても価値があると思います。 ## 現状の整理 で、何が言いたいかと言いますと、今後コードを改善していく上で、まず、どちらにどの程度着目するのか、という点について明確にしませんか、ということです（その他の目的があれば、補足お願いします）。それによって、今度どうすべきかが変わってくると思います。 もし前者全振りならば、考えることはそんなに多くないと思うのですが、もし後者も目的に設定する場合（できればそうしたいとは思いますが）、メンテも必要になってきますし、やることも多くなってくると思うので、大きな実装を始める前に、設計について議論すべきだと思います。考えるべき点について、いくつか挙げると、 - そもそもどういう使用方法を想定するのか？ライブラリとしての使用（`import hoge` のような使い方）？それともコマンドラインツールとしての使用？ or 両方？ - 現状GMMベースの方法以外では使えないような設計になっているので（GMMTrainerありきですよね）、変換モデルに対する抽象化が必要ではないか - 特徴量にメルケプストラム以外使えない設計になっているので（FeatureExtractorにベタ書きされています）、特徴量に対する抽象化が必要ではないか - 分析合成系にはWORLDしか使えないようになっているので（昔Analyzer/Syntehsizerという共通インタフェースを作ったけど、使われていないので…）、STRAIGHTなりSPTK（のF0抽出手法各種）なり、その他分析合成系が使えるよう、抽象化が必要ではないか -...
機能の実装に比べて重要ではないけど、パフォーマンスを上げるためにやっておいたほうがよいことの一つ。 参考: - http://d.hatena.ne.jp/sleepy_yoshi/20120513/p1 このあたり https://github.com/TakedaLab/sprocket/blob/6acb52ef3bdf2172253b5c6fac4bf1a874bf61b0/sprocket/model/GMM.py#L183-L203
address #10