Retrieval-based-Voice-Conversion-WebUI
Retrieval-based-Voice-Conversion-WebUI copied to clipboard
RVC-Project
带音高的特征集实验
开发者们好，我想介绍一下我在我的fork（https://github.com/matthew99a/Retrieval-based-Voice-Conversion-WebUI）上做的一个实验。
我用自己很喜欢的一个偏美声歌手训练的模型，最开始听起来不是很像。然后我发现了一个现象：这个歌声在发同一个元音的时候，高音的发音方式和低音的发音方式会不同（比如高音的ah（啊）听感在ah和oo（乌）之间），而HuBERT模型是不能准确的把它们识别成同一种特征的。我因此意识到模型不准确的原因可能是因为模型里训练的特征是不考虑音高的。这样的实现方式在匹配的时候，高音的特征可能与训练集里的低音特征匹配。由于美声歌手往往不会用这个特征唱高音，因此生成出来的高音也会很奇怪。
在我的实验中，我把特征加了一维（v2版本的768维变769维）表示音高，从而使得匹配的时候能够优先匹配训练集里音高接近的特征。使用两个小时的训练集重新训练特征之后，在我的实验中效果好了一大截，当然代价是咬字略微差了一些。当然我也清楚这样做的坏处是训练集要求太高，因为如果训练集太小，可以用来匹配的音高接近的特征就很少，对咬字的牺牲就会很大，并且也许这种实现只有对美声歌手等特殊的唱法非常有效果（不是很清楚一般的流行唱法的高音和低音HuBERT特征差距多大）。
希望这个实验报告能起到一些抛砖引玉的作用。
你很有想法！ 有一个问题是，预训练的效果会降低，因为少了一层线性层，维度不对加载不进去。 我想针对你的case做对比实验，你是否介意分享数据集给我复现“高低音发音方式不同”这点？
“有一个问题是，预训练的效果会降低，因为少了一层线性层，维度不对加载不进去。”
如果我理解正确的话，这个是没问题的，我把769维的特征拿去检索之后得到最近的特征之后，丢掉音高那一维变成768维向量，再用模型跑。我甚至没有重新训练模型，只重新训练了特征集（因此有一个参数我可以很快做多次实验取我认为最好的那个）。
@matthew99a 我好像理解了，你的意思是不是，假如拿768去匹配，768语义非常接近但是音高差很多，可能就会匹配到音高距离目标音高差很多的训练集口型，然后后面模型强行把音高抬过去 我不太确定音高的度量和768维的度量是不是同样的尺度，就是说他们距离是不是就是简单的加上一维求距离就行，还是说要把音高乘上一个系数再769一起求距离，还是怎么做。你也提到了，假如音高的权重过大的话，咬字的牺牲又太大了。
@RVC-Boss 我把pitch那一维取mel（使用np.log(1 + freq / 700)这个公式），然后乘上一个参数（我的是维数的平方根乘一个常数），直接塞进去求欧几里得距离。
当然这样肯定不是最好的实现，但由于faiss库能用的实现方式有限，我只好采用了这种实现方式。具体实现你可以参考一下我的fork（https://github.com/matthew99a/Retrieval-based-Voice-Conversion-WebUI）。
“假如拿768去匹配，768语义非常接近但是音高差很多，可能就会匹配到音高距离目标音高差很多的训练集口型，然后后面模型强行把音高抬过去” 没错差不多就是这个意思。
