官方前兩次更新提到對(duì)RVC有了進(jìn)一步的提升，今天我才更新了版本試了下，確實(shí)有新選項(xiàng)可用，效果好像還挺好。 簡(jiǎn)要地說，f0 det多了兩個(gè)選項(xiàng)：crepe_full、crepe_tiny，分別對(duì)應(yīng)兩個(gè)onnx模型。

經(jīng)過簡(jiǎn)單測(cè)試（統(tǒng)一參數(shù)：256/32768，降低參數(shù)可以降低延遲直至兩位數(shù)），我個(gè)人評(píng)價(jià)如下： dio、crepe：個(gè)人感覺效果比不上harvest，不予測(cè)試。 harvest：效果不錯(cuò)，延遲400ms左右。 crepe_full：效果略比harvest好，延遲250ms左右。 crepe_tiny：效果和上一個(gè)差不多，延遲200ms左右。 可見，確實(shí)是有巨大的提升，在效果沒有下降的情況延遲可以降低一半。

目前鏡像已經(jīng)提交審核，鏡像版本為v9，對(duì)應(yīng)官方的v1.5.3.8a版本。 下面開始講廢話，不感興趣的可以劃走了。 晚上忙到十一點(diǎn)半才有時(shí)間，開始準(zhǔn)備鏡像。 按往常的步驟重新reclone了項(xiàng)目，一啟動(dòng)馬上就報(bào)錯(cuò)了。

一開始我不想麻煩去看代碼，直接把downloadweight一行給pass掉了，項(xiàng)目成功啟動(dòng)，但是一選新增的f0 det直接報(bào)錯(cuò)，還是要去改代碼。 看錯(cuò)誤應(yīng)該是路徑變量是none，看看代碼。

就是這行if報(bào)錯(cuò)，里面的crepe_onnx_full是none，直接引發(fā)了異常。 我在if前加了個(gè)判none，是none同樣執(zhí)行if。保存之后，項(xiàng)目啟動(dòng)成功，但是并沒有下載模型文件。 于是查看再下一層文件，應(yīng)該是在weightdownloader中準(zhǔn)備參數(shù)，然后到downloader里執(zhí)行下載。

問題應(yīng)該就出在download函數(shù)里，新的兩個(gè)模型要在這下載，但是沒有執(zhí)行到try。 再次翻看了幾個(gè)py文件，我大致得出結(jié)論：?jiǎn)?dòng)參數(shù)里必須要有crepe_full和tiny。 然后我去查看了官方開發(fā)文檔，里面并沒有對(duì)參數(shù)進(jìn)行更新。 我修改了啟動(dòng)腳本，手動(dòng)指定了兩個(gè)參數(shù)，隨便給了個(gè)文件名。

保存腳本，再次啟動(dòng)，這次開始下載full和tiny模型了，作者給出的模型如下：

下完模型后項(xiàng)目啟動(dòng)，現(xiàn)在選擇crepe_full和crepe_tiny就沒有出錯(cuò)了。 收工，睡覺