关于webui界面源音频参数的问题 about so-vits-svc HOT 4 CLOSED

经过多次实践，多个样本实践，大致摸索出一个规律。如果音频文件有静音的地方，比如电平为0的部分，在一段10秒的音频里，讲话人不说话时，电平为0的部分存在，就会出错无法转换。当一个人讲话第一句低沉沙哑，也有出错的概率，但不是100%出错，感觉这个问题不是项目团队能够解决的，是否是trochaudio的问题。当我把一个不能正常转换的文件通过au剪切分段，一个音频文件中不存在电平为0的停顿后，这个文件就可以被正常的转换了。

from so-vits-svc.

Audio data cannot be converted to 16-bit int format
应该是你输入的音频解码器不支持

from so-vits-svc.

gradio 版本问题
该问题已在gradio-app/gradio#2545 中修复
更新gradio到包含这个改动的版本(3.7)即可解决问题
pip install --upgrade gradio>=3.7

from so-vits-svc.

训练了一个模型大改2400步后我试了一下发现可以用，在转换过程中我发现有些音频转成wav 44100 16bit后可以正常转换，但是有个wav源文件明明自己是16bit，转换就报错ValueError: Audio data cannot be converted to 16-bit int format.哪怕我在au里切一小段下来另存为44100 16bit也是这个报错。wav的参数只有这些，还有什么因素会影响这个源文件无法被转换？

报错中提到的是16-bit int，也就是int_16类型变量，指的是cpu的位数，和音频的比特深度无关

经过多次实践，多个样本实践，大致摸索出一个规律。如果音频文件有静音的地方，比如电平为0的部分，在一段10秒的音频里，讲话人不说话时，电平为0的部分存在，就会出错无法转换。当一个人讲话第一句低沉沙哑，也有出错的概率，但不是100%出错，感觉这个问题不是项目团队能够解决的，是否是trochaudio的问题。当我把一个不能正常转换的文件通过au剪切分段，一个音频文件中不存在电平为0的停顿后，这个文件就可以被正常的转换了。

事实上这个问题是由gradio引起的。在早期版本的gradio中，函数convert_to_16_bit_wav并没有支持np.float64类型的转换，而上传到gradio的音频处理后就是这个类型。所幸这个问题已经在5个月前被修复，而他们修复的方式也很简单——增加了if的判断条件

from so-vits-svc.