Retrieval-based-Voice-Conversion-WebUI
Retrieval-based-Voice-Conversion-WebUI copied to clipboard
RVC-Project
Support choosing speech encoder(feature extractor)
I add a new option, PPGLarge. We may also add more option of speech encoder if there is one that perform the best.
In addition, I add a projection in the network at the beginning if the output dim of speech encoder is different from what we have now(768 and 256, because the PPGLarge is 1280). The data will not be passed into the projection if the output dims of speech encoder is the same as the input dims of netG.
一下这么多，瑟瑟发抖 PPG去年就试过，跑垃圾数据跑不起来的
我觉得不只是PPG，主要是提供了一个扩展的空间吧。（嗯，毕竟是可选，可以让用户默认hubert就好）。 我自己测试了一下，在inference用错模型了（这里我忘记做了，可以后面再说） 用ppg训练，然后inference的时候实际上是用hubert转换的，然后效果也就差一点点，因为inference用错模型了，所以我还是没法断定ppg就是不行，我可能还要再做点实验。 但主要还是通过一个point wise的投影层来让模型可以符合更多的speech representation模型。也增加了扩展性吧。 如果这个功能没问题的话我可以继续维护一下更多的speech representation模型加到里面。 然后请问您有没有了解过隔壁的diffusion model提升音质，我也在考虑整合进去，您怎么看？
你在缝的功能大多是已经经过了实验证明没用的，增加选项除了让用户懵逼外没啥大用，目前对于RVC来说基本是最优配置 diff是唯一可能和baseline互有优劣的选项 符合更多模型：没用的，用A训，用B推理本来也是魔幻行为；多encoder一起上：音色泄露的强度只会挑泄露最多的那个来；单encoder：直接对上输入通道就行了，没必要多加卷积层 可以提交到RVC-Project或者RVC的其他分支，但是肯定不会一起合并到主分支
你在缝的功能大多是已经经过了实验证明没用的，增加选项除了让用户懵逼外没啥大用，目前对于RVC来说基本是最优配置 diff是唯一可能和baseline互有优劣的选项 符合更多模型：没用的，用A训，用B推理本来也是魔幻行为；多encoder一起上：音色泄露的强度只会挑泄露最多的那个来；单encoder：直接对上输入通道就行了，没必要多加卷积层 可以提交到RVC-Project或者RVC的其他分支，但是肯定不会一起合并到主分支
好，我先关掉这个PR了