SherkeyXD
SherkeyXD
> 训练了一个模型大改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的判断条件
就我印象中是没有小写关卡名的 可关键是ocr识别错了啊）
> 对，我的意思是可以直接换成大写的（） 我也这么想的）
现在还有这个问题吗
https://github.com/MaaAssistantArknights/libWSAController 等待集成（
更新到最新版本试试，还有这个问题吗？
更新到最新内测版试试
相关讨论移至 #5418，该 issue 先关闭
Fixed in b637f7b2b89e1e29d2deaee3ee9ef18a1ee06eac
同样遇到此问题，看了日志发现也是卡在上报