尧图网页设计 
别再纠结了mdx_q 与 mdx_extra_q量化音频分离模型到底选哪个【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs打开 Demucs 的模型列表mdx_q和mdx_extra_q两个名字挨在一起配置里都是 4 个模型、44 秒段长看起来几乎一样。想上量化模型省显存又担心选错白费部署时间这篇就用项目里的真实配置和官方口径把两个模型拆开对比帮你一次选对。读完你将获得两个模型在组合机制上的本质区别、官方口径下的质量与成本依据、两套可直接照抄的落地命令以及一条如果还不放心怎么自己验证的路径。痛点开场两个量化模型看着像用起来差在哪你有没有遇到过这种情况照着网上的命令部署量化模型跑是能跑但心里没底——mdx_q和mdx_extra_q到底差在哪儿哪个更准哪个更快更坑的是两者都带_q后缀很多人默认带 extra 就是加强版选它准没错结果在低配机器上被多出来的计算量卡住。先给个官方彩蛋在 demucs/pretrained.py 里项目方留了一行提示——在 htdemucs 成为默认模型之前Demucs 的老默认值正是mdx_extra_q。也就是说带 extra 的更接近默认体验这句话有官方出处但更准就一定更好可不一定成立。下面把两个模型的底细翻出来看。差异剖析同源不同命组合策略是分水岭mdx_q和mdx_extra_q是一对孪生兄弟它们分别是 MDX 竞赛模型mdx与mdx_extra的量化版本量化方式都是 DiffQ在 demucs/grids/mdx.py 里能看到quant.diffq的训练参数目标都是把模型压小、把推理变快。但打开各自的配置文件差异立刻现形demucs/remote/mdx_q.yaml 里有一个 4×4 的weights权重矩阵[1,1,0,0]、[1,0,1,1]这些行说明不同声源由不同子模型分工负责且加权方式不同demucs/remote/mdx_extra_q.yaml 里没有 weights 字段4 个模型对全部声源等权组合。对应到原始模型的家族谱docs/training.mdTrack A 的mdx里时域模型0d19c1c6专门负责鼓和贝斯7ecf8ec1只负责贝斯其余混合模型按声源分配权重而 Track B 的mdx_extra则是 4 个 48 通道混合模型其中两个用 CaC、两个用幅度谱掩蔽全等权叠加。换句话说mdx_q是分工明确、按声源特调的精细化组合mdx_extra_q是人多力量大的平权堆叠。前者省算力、结构讲究后者靠数据集优势硬扛。另一个关键差异藏在数据来源里。官方在 README.md 写得很直白mdx是 MDX 竞赛 Track A 的获胜模型只在 MusDB-HQ 上训练而mdx_extra用了额外训练数据其中包含 MusDB 测试集在 Track B 排名第 2。数据量上的不平等是mdx_extra_q质量兜底的最硬理由。配置项mdx_qmdx_extra_q出处基础模型mdxMDX Track A 冠军mdx_extraTrack B 第 2README.md子模型数量4 个4 个对应 yaml权重策略多组权重矩阵按声源分工加权无权重字段全模型等权对应 yaml段长 segment44 秒44 秒对应 yaml训练数据仅 MusDB-HQ额外数据含 MusDB 测试集README.md量化方式DiffQDiffQgrids/mdx.py、training.md上图是 Demucs 系模型的整体架构STFT 频谱分支与波形分支并行编码经由跨域 Transformer 融合后再解码出 4 个声源。两个量化模型本质上都是这套架构的 DiffQ 量化实现区别只在用几个模型、怎么组合。数据验证官方口径下的真实差距先说结论官方没有单独公布mdx_q与mdx_extra_q的逐声源 NSDR 数字docs/mdx.md 给的也主要是 MDX 竞赛的参赛与评测流程不是现成的分数表。所以在谁更准这件事上最靠谱的依据是官方一句原话量化版质量可能略差但下载与存储更小README.md。不过官方在 README 里公布了一张完整的 SDR 榜单MusDB-HQ 测试集Overall SDR 为 4 声源均值可以帮你定位 mdx 家族在整个生态里的段位由此可以得出两条关键结论mdx 家族属于竞赛级但非顶级的定位它拿到过 Track A 冠军但在官方总榜上低于后来居上的 Band-Split RNN 与 HT Demucs f.t.9.0 dB——如果你对质量极其敏感、显存也不紧张不如直接上默认的htdemucs。mdx_extra_q大概率优于mdx_q但差距没到质变它的底气来自额外训练数据含测试集而mdx_q的底气来自更精细的权重分配。官方只承诺质量略差于原版两者之间的相对差距官方未量化别指望天差地别。成本盘点量化到底帮你省了什么体积和速度上的硬指标官方同样没有给出精确到 MB 的数字但有两组明确口径量化目的mdx_q、mdx_extra_q是smaller download and storage更小的下载与存储体积质量可能略降README.md硬件门槛官方在 README.md 注明 GPU 分离至少需要 3GB 显存默认参数下约需 7GB可调--segment压低CPU 处理时间约为音频时长的 1.5 倍-j并行任务会把内存占用按倍数放大。综合两个配置文件的实际情况成本对比可以归纳如下指标mdx_qmdx_extra_q适配环境存储体积更小官方口径更小官方口径两者都远小于非量化版计算开销权重矩阵按声源裁剪理论更省全模型等权前向开销略高低配 GPU / CPU 选 mdx_q显存需求官方建议 3GB 起步默认参数约 7GB同左均可通过--segment下探CPU 速度约 1.5× 实时时长同左略慢无 GPU 时都能跑质量兜底结构精巧数据更足追求稳妥选 mdx_extra_q一句话总结mdx_q是省字派mdx_extra_q是稳字派。如果你的机器连 3GB 显存都吃力或者干脆纯 CPU 跑优先mdx_q如果显存够、想要尽量接近原版的质量mdx_extra_q更合适。落地实操两种场景两套命令前置条件两者通用已安装 Demucspip install demucs即可仅分离场景装requirements_minimal.txt就够量化模型首次运行会自动下载权重需要能访问模型仓库。场景一实时性优先 / 低配设备 —— 首选 mdx_q直播降噪、批量处理大量短音频这类场景mdx_q的按声源裁剪组合能省下不必要的计算。只抽人声时加--two-stemsvocals还想更快就把重叠率从默认 0.25 降到 0.1官方在 README 中认可这个做法# 环境Linux / macOS 终端已安装 demucsPython 3.8 python3 -m demucs -n mdx_q --two-stemsvocals --overlap 0.1 input.mp3 # 机器实在太弱强制 CPU 并缩短段长压内存 python3 -m demucs -n mdx_q -d cpu --segment 30 input.mp3场景二质量优先 / 有 GPU —— 首选 mdx_extra_q做播客精修、母带级后期时用mdx_extra_q配合官方推荐的--shifts平移技巧多预测取平均官方注明除非你有 GPU否则别用再配合--clip-mode clamp防止分轨削波# 环境NVIDIA GPU CUDA显存建议 4GB 以上 python3 -m demucs -n mdx_extra_q --shifts 3 --clip-mode clamp input.wav # 只要人声伴奏两分进一步提速 python3 -m demucs -n mdx_extra_q --two-stemsvocals --overlap 0.1 input.wav顺带提醒如果是从老版本升上来的用户想找回曾经的默认手感官方在 demucs/pretrained.py 里明确说过——用-n mdx_extra_q即可切回旧默认这个细节写进了源码注释里。总结与进阶验证选型结论不玩虚的实时、低配、批量处理→ 选mdx_q。它的权重矩阵组合在保证 MDX Track A 冠军底子的同时把计算压在最小范围。质量优先、有 GPU、能接受更多计算→ 选mdx_extra_q。额外训练数据含 MusDB 测试集是它质量兜底的来源也是老默认模型的传承。显存充足且追求极致质量→ 两个都别选直接用默认的htdemucs官方 SDR 9.0 dB榜单封顶。最后如果你还是想在自家数据集上拿实数说话项目给你留好了两条路一是按 docs/mdx.md 的流程在 MusDB-HQ 上自测二是用 tools/test_pretrained.py 对指定模型做评测对比。跑一轮比任何道听途说都靠谱。去把你的音频丢给mdx_q试试跑不动再换mdx_extra_q——这次不用纠结了。【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 别再纠结了：mdx_q 与 mdx_extra_q，量化音频分离模型到底选哪个？
别再纠结了mdx_q 与 mdx_extra_q量化音频分离模型到底选哪个【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs打开 Demucs 的模型列表mdx_q和mdx_extra_q两个名字挨在一起配置里都是 4 个模型、44 秒段长看起来几乎一样。想上量化模型省显存又担心选错白费部署时间这篇就用项目里的真实配置和官方口径把两个模型拆开对比帮你一次选对。读完你将获得两个模型在组合机制上的本质区别、官方口径下的质量与成本依据、两套可直接照抄的落地命令以及一条如果还不放心怎么自己验证的路径。痛点开场两个量化模型看着像用起来差在哪你有没有遇到过这种情况照着网上的命令部署量化模型跑是能跑但心里没底——mdx_q和mdx_extra_q到底差在哪儿哪个更准哪个更快更坑的是两者都带_q后缀很多人默认带 extra 就是加强版选它准没错结果在低配机器上被多出来的计算量卡住。先给个官方彩蛋在 demucs/pretrained.py 里项目方留了一行提示——在 htdemucs 成为默认模型之前Demucs 的老默认值正是mdx_extra_q。也就是说带 extra 的更接近默认体验这句话有官方出处但更准就一定更好可不一定成立。下面把两个模型的底细翻出来看。差异剖析同源不同命组合策略是分水岭mdx_q和mdx_extra_q是一对孪生兄弟它们分别是 MDX 竞赛模型mdx与mdx_extra的量化版本量化方式都是 DiffQ在 demucs/grids/mdx.py 里能看到quant.diffq的训练参数目标都是把模型压小、把推理变快。但打开各自的配置文件差异立刻现形demucs/remote/mdx_q.yaml 里有一个 4×4 的weights权重矩阵[1,1,0,0]、[1,0,1,1]这些行说明不同声源由不同子模型分工负责且加权方式不同demucs/remote/mdx_extra_q.yaml 里没有 weights 字段4 个模型对全部声源等权组合。对应到原始模型的家族谱docs/training.mdTrack A 的mdx里时域模型0d19c1c6专门负责鼓和贝斯7ecf8ec1只负责贝斯其余混合模型按声源分配权重而 Track B 的mdx_extra则是 4 个 48 通道混合模型其中两个用 CaC、两个用幅度谱掩蔽全等权叠加。换句话说mdx_q是分工明确、按声源特调的精细化组合mdx_extra_q是人多力量大的平权堆叠。前者省算力、结构讲究后者靠数据集优势硬扛。另一个关键差异藏在数据来源里。官方在 README.md 写得很直白mdx是 MDX 竞赛 Track A 的获胜模型只在 MusDB-HQ 上训练而mdx_extra用了额外训练数据其中包含 MusDB 测试集在 Track B 排名第 2。数据量上的不平等是mdx_extra_q质量兜底的最硬理由。配置项mdx_qmdx_extra_q出处基础模型mdxMDX Track A 冠军mdx_extraTrack B 第 2README.md子模型数量4 个4 个对应 yaml权重策略多组权重矩阵按声源分工加权无权重字段全模型等权对应 yaml段长 segment44 秒44 秒对应 yaml训练数据仅 MusDB-HQ额外数据含 MusDB 测试集README.md量化方式DiffQDiffQgrids/mdx.py、training.md上图是 Demucs 系模型的整体架构STFT 频谱分支与波形分支并行编码经由跨域 Transformer 融合后再解码出 4 个声源。两个量化模型本质上都是这套架构的 DiffQ 量化实现区别只在用几个模型、怎么组合。数据验证官方口径下的真实差距先说结论官方没有单独公布mdx_q与mdx_extra_q的逐声源 NSDR 数字docs/mdx.md 给的也主要是 MDX 竞赛的参赛与评测流程不是现成的分数表。所以在谁更准这件事上最靠谱的依据是官方一句原话量化版质量可能略差但下载与存储更小README.md。不过官方在 README 里公布了一张完整的 SDR 榜单MusDB-HQ 测试集Overall SDR 为 4 声源均值可以帮你定位 mdx 家族在整个生态里的段位由此可以得出两条关键结论mdx 家族属于竞赛级但非顶级的定位它拿到过 Track A 冠军但在官方总榜上低于后来居上的 Band-Split RNN 与 HT Demucs f.t.9.0 dB——如果你对质量极其敏感、显存也不紧张不如直接上默认的htdemucs。mdx_extra_q大概率优于mdx_q但差距没到质变它的底气来自额外训练数据含测试集而mdx_q的底气来自更精细的权重分配。官方只承诺质量略差于原版两者之间的相对差距官方未量化别指望天差地别。成本盘点量化到底帮你省了什么体积和速度上的硬指标官方同样没有给出精确到 MB 的数字但有两组明确口径量化目的mdx_q、mdx_extra_q是smaller download and storage更小的下载与存储体积质量可能略降README.md硬件门槛官方在 README.md 注明 GPU 分离至少需要 3GB 显存默认参数下约需 7GB可调--segment压低CPU 处理时间约为音频时长的 1.5 倍-j并行任务会把内存占用按倍数放大。综合两个配置文件的实际情况成本对比可以归纳如下指标mdx_qmdx_extra_q适配环境存储体积更小官方口径更小官方口径两者都远小于非量化版计算开销权重矩阵按声源裁剪理论更省全模型等权前向开销略高低配 GPU / CPU 选 mdx_q显存需求官方建议 3GB 起步默认参数约 7GB同左均可通过--segment下探CPU 速度约 1.5× 实时时长同左略慢无 GPU 时都能跑质量兜底结构精巧数据更足追求稳妥选 mdx_extra_q一句话总结mdx_q是省字派mdx_extra_q是稳字派。如果你的机器连 3GB 显存都吃力或者干脆纯 CPU 跑优先mdx_q如果显存够、想要尽量接近原版的质量mdx_extra_q更合适。落地实操两种场景两套命令前置条件两者通用已安装 Demucspip install demucs即可仅分离场景装requirements_minimal.txt就够量化模型首次运行会自动下载权重需要能访问模型仓库。场景一实时性优先 / 低配设备 —— 首选 mdx_q直播降噪、批量处理大量短音频这类场景mdx_q的按声源裁剪组合能省下不必要的计算。只抽人声时加--two-stemsvocals还想更快就把重叠率从默认 0.25 降到 0.1官方在 README 中认可这个做法# 环境Linux / macOS 终端已安装 demucsPython 3.8 python3 -m demucs -n mdx_q --two-stemsvocals --overlap 0.1 input.mp3 # 机器实在太弱强制 CPU 并缩短段长压内存 python3 -m demucs -n mdx_q -d cpu --segment 30 input.mp3场景二质量优先 / 有 GPU —— 首选 mdx_extra_q做播客精修、母带级后期时用mdx_extra_q配合官方推荐的--shifts平移技巧多预测取平均官方注明除非你有 GPU否则别用再配合--clip-mode clamp防止分轨削波# 环境NVIDIA GPU CUDA显存建议 4GB 以上 python3 -m demucs -n mdx_extra_q --shifts 3 --clip-mode clamp input.wav # 只要人声伴奏两分进一步提速 python3 -m demucs -n mdx_extra_q --two-stemsvocals --overlap 0.1 input.wav顺带提醒如果是从老版本升上来的用户想找回曾经的默认手感官方在 demucs/pretrained.py 里明确说过——用-n mdx_extra_q即可切回旧默认这个细节写进了源码注释里。总结与进阶验证选型结论不玩虚的实时、低配、批量处理→ 选mdx_q。它的权重矩阵组合在保证 MDX Track A 冠军底子的同时把计算压在最小范围。质量优先、有 GPU、能接受更多计算→ 选mdx_extra_q。额外训练数据含 MusDB 测试集是它质量兜底的来源也是老默认模型的传承。显存充足且追求极致质量→ 两个都别选直接用默认的htdemucs官方 SDR 9.0 dB榜单封顶。最后如果你还是想在自家数据集上拿实数说话项目给你留好了两条路一是按 docs/mdx.md 的流程在 MusDB-HQ 上自测二是用 tools/test_pretrained.py 对指定模型做评测对比。跑一轮比任何道听途说都靠谱。去把你的音频丢给mdx_q试试跑不动再换mdx_extra_q——这次不用纠结了。【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考