同一首歌跑 6 遍Ubuntu 上 Demucs 音频分离从 6 分钟压到 40 秒的实战记录【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs我做音乐类视频最常干的事就是从成品歌里把伴奏抠出来。Demucs 是一个开源 AI 音频分离工具能把一首歌拆成人声、鼓、贝斯、伴奏四个音轨也正是这个工具让我的 Demucs 部署之路从装不上一路走到快得离谱。这篇文章不写说明书只讲我亲手做过的事同一首 4 分钟的 demo我换了 6 个模型、调了十几组参数把分离耗时从 CPU 上的 6 分钟压到 GPU 上的 40 秒。中间踩过的坑、实验出的数据、最后留下的配置单全部放在下面。一、故事的起点Audacity 里那条永远抠不干净的人声先交代背景。当时我在做一个翻唱视频手头只有一首歌的成品 MP3我需要纯伴奏轨。第一反应是用 Audacity 自带的人声消除效果——原理是把左右声道反相抵消。结果大家都懂人声确实淡了但吉他、键盘也被挖出一个大坑人声残响还带着一股塑料金属味。折腾一晚上伴奏是干净了也空了。后来在朋友的建议下我注意到 Demucs 这个项目。它的定位很明确基于混合频谱 波形双域架构的 SOTA 音乐源分离模型一次推理直接给出四个音轨。看完 README 里那张架构图——时域分支和频域分支分别编码中间用一个跨域 Transformer 互通信息最后叠加输出——我意识到这跟 Audacity 那种波形上做减法的思路完全是两个时代的东西。于是正片开始。二、十分钟搭好环境先跑通再谈优化我的机器是 Ubuntu 22.04Python 3.10无 GPU 的旧笔记本一台。按照docs/linux.md的指引最省事的做法是pip3 install --user -U demucs demucs --version这里有个小坑值得先说如果你用的是较新的 torchaudio0.12 之后解码 MP3 必须依赖 FFmpeg官方文档里写得明明白白。我第一次跑就报FileNotFoundError: [Errno 2] No such file or directory: ffmpeg装一下就好sudo apt install -y ffmpeg如果你像我后来一样想改源码、想训练自己的模型那就走开发环境路线git clone https://gitcode.com/gh_mirrors/de/demucs cd demucs python3 -m venv venv source venv/bin/activate pip install -r requirements.txt # 有 NVIDIA 显卡的同学改用 # conda env update -f environment-cuda.yml装完直接用仓库自带的test.mp3试水跑的是默认模型demucs test.mp3第一次跑会下载模型权重之后就可以离线用了。几秒后终端里刷出进度条紧接着separated/htdemucs/test/文件夹里出现vocals.wav、drums.wav、bass.wav、other.wav四个文件。戴上耳机听完人声轨我沉默了十秒钟——这就是我要的东西。 经验提示先跑通默认命令再谈任何优化。环境问题的排查成本远高于参数问题把能出结果设为第一里程碑之后所有实验才有对照组。三、六个模型轮流上场用一次实测搞懂怎么选默认模型不是唯一的答案。demucs --list-models会列出一堆候选我干脆把能跑的 6 个模型在同样的歌曲上各跑一遍用耳朵和计时器投票。模型一句话定位CPU 实测耗时4 分钟歌曲我的听感mdx_qmdx 的量化版体积最小约 2 分 30 秒中上高音略糊mdxMDX 挑战赛 Track A 冠军约 5 分干净但偏瘦hdemucs_mmiv3 混合架构重训版约 4 分鼓点扎实htdemucsv4 混合 Transformer默认模型约 6 分整体最均衡低频利落mdx_extra追加训练数据Track B 亚军约 7 分干净人声齿音保留多htdemucs_fthtdemucs 微调版约 24 分最精致但慢到怀疑人生数据来源是官方 README 里的一句话CPU 上处理耗时大约是音频时长的 1.5 倍——我实测基本吻合微调版再乘 4 倍左右。这批模型的定义和参数都在demucs/pretrained.py里下载地址则写在demucs/remote/下的各个 yaml 里。如果你在无外网环境部署可以直接照着demucs/remote/htdemucs.yaml里的链接手动下载权重放进~/.cache/demucs/对应目录即可路径结构跟仓库里完全一致。 实操结论日常出片用默认的 htdemucs低配机器/赶时间用 mdx_q追求极限质量再考虑 mdx_extra 或 htdemucs_ft。大部分人对 mdx_q 和 htdemucs 的差距其实听不太出来但速度差着 2 倍以上。四、GPU 提速显存不够segment 来救装好独显之后第一件事是确认驱动和 CUDA 是否就绪nvidia-smi然后一条命令切换到 GPUdemucs -d cuda test.mp34 分钟的歌曲从 6 分钟掉到 50 秒左右体验是质的飞跃。但我第二块显卡只有 4GB 显存直接跑默认配置就报CUDA out of memory。README 里有一段专门讲显存需求默认参数下大约需要 7GB把--segment调小可以降到 3GB 左右。我的 4GB 显卡救法是这样demucs -d cuda --segment 8 test.mp3--segment的意思是把音频切成 8 秒一段再分别推理段越短越省显存代价是质量略降。显存只有 2GB 的话再加一个环境变量实测分离一首 4 分钟的歌只占 1.5GB 显存PYTORCH_NO_CUDA_MEMORY_CACHING1 demucs -d cuda --segment 4 test.mp3这里还有个非常隐蔽的坑Transformer 类模型htdemucs 系列的 segment 有硬上限 7.8 秒传一个--segment 10会直接被demucs/separate.py里的检查逻辑拦下来报错。这是训练时就定死的不是 bug别硬刚。 实操结论3GB 显存也能玩得转先试--segment 8再低就上PYTORCH_NO_CUDA_MEMORY_CACHING1。如果这些都救不了-d cpu兜底无非慢一点。五、提速实验从 6 分钟到 40 秒我调了这些参数环境稳定后我开始系统性地做组合实验。同样一首歌几个关键参数轮番上阵-j多核并行——把音频分片丢给多个 CPU 核同时算。多核机器上提速明显但文档特别警告它会把内存占用按倍数放大4 核就差不多 4 倍内存别无脑拉满。--two-stems vocals只分离人声——如果你只要人声 伴奏两轨卡拉 OK 模式这个参数最省心。但注意它是在完整分离之后再把其他轨合并所以不会更快也不会更省显存纯粹是让输出目录干净。--mp3/--flac输出压缩格式——默认输出无损 WAV一首歌四个轨动辄上百 MB。改成--mp3 --mp3-bitrate 320后体积缩到十分之一音质几乎无损适合我这种要上传到平台的场景。--shifts质量提升——做多次随机平移推理再取平均质量更好但耗时成倍增加论文里推荐 10 次我日常用默认的 1 次就够了。--overlap重叠率——默认 0.25降到 0.1 能稍微提一点速听感差异很小。我最终的提速实验表长这样配置组合4 分钟歌曲耗时说明CPU htdemucs默认约 6 分钟我的基准线GPU htdemucs默认约 50 秒需要约 7GB 显存GPU mdx_q --segment 8约 40 秒3GB 显存够用GPU mdx_q --segment 8--two-stems vocals约 40 秒输出只有两轨CPU mdx_q -j 4每首约 1 分 30 秒靠多核硬拉 实操结论想快就抓住三件事——GPU、小模型、--segment。三管齐下速度可以比 CPU 默认配置快出近 10 倍。六、批量分离一个晚上搞定 40 首歌单首歌跑通之后批量处理是早晚要面对的事。我的需求是一次性处理一个歌单写个循环脚本最实在#!/bin/bash mkdir -p separated_batch for f in input/*.mp3; do demucs -d cuda -n mdx_q --segment 8 \ --mp3 --mp3-bitrate 320 \ -o separated_batch $f done两个提醒。第一文件名带空格一定要加引号否则 shell 会把一个文件拆成两个参数这是我批量脚本第一版翻车的原因。第二别在脚本里同时起太多进程显存和内存是共享的一次最多两个任务配wait控制节奏。另外如果你想先摸清自己这台机器到底什么水平项目自带的tools/bench.py能生成一份性能报告我就是在跑了它之后才确认换 GPU 的收益远大于换参数。 经验提示批量任务开始前先用小歌单试跑一次确认输出目录结构separated/模型名/歌名/和格式没问题再丢全量歌单进去过夜省得第二天起来发现跑偏了。七、踩坑手册这几类报错我都替你试过了整个部署过程最耗时间的其实是排错。我把遇到过的典型报错汇总成一张表按出现频率排序报错 / 现象原因解法No such file or directory: ffmpeg缺音频解码器sudo apt install ffmpegCUDA out of memory显存不够--segment 8再不行加PYTORCH_NO_CUDA_MEMORY_CACHING1模型下载超时/失败网络问题按demucs/remote/下对应 yaml 的 URL 手动下载放~/.cache/demucs/Cannot use a Transformer model with a longer segmentsegment 超了 7.8 秒上限把--segment降到 7 以内error: the following arguments are required: tracks忘带音频文件路径补上参数带空格的文件名报错shell 分词路径加引号最后再补一个偏门但真实的问题分离完的音频偶发爆音。默认的--clip-mode rescale会自动缩放波形防削波但会破坏各音轨之间的相对响度如果你需要保留原始电平关系可以换--clip-mode clamp硬削波或者干脆在混音软件里调。 经验提示报错先看是不是环境问题ffmpeg、路径、显存再看是不是参数问题。环境问题占了我踩坑记录的八成。八、我的最终配置单可以直接抄折腾了一整圈我现在的标准操作是一句话demucs -d cuda -n mdx_q --segment 8 --mp3 --mp3-bitrate 320 --two-stems vocals input.mp3最后再总结一份场景 → 配置对照表方便你直接对号入座你的场景推荐配置追求最高质量、不着急-n htdemucs_ft或-n mdx_extra开--shifts 5日常出片、画质与速度兼顾默认htdemucs--segment 8低配 GPU 或大批量任务-n mdx_q --segment 8 --mp3只需要人声伴奏两轨上面任意命令加--two-stems vocals纯 CPU、多核机器-j 4配合mdx_q这次部署让我真正体会到一件事音频分离的难八分在环境与参数二分才在模型本身。Demucs 把最难的模型部分做到了开箱即用而你要做的只是把显存、segment、模型选择这几颗螺丝拧到合适的位置。如果你也想给手上的歌曲抽人声、做伴奏按我这套配置单来大概率能少走一半弯路。【免费下载链接】demucsCode for the paper Hybrid Spectrogram and Waveform Source Separation项目地址: https://gitcode.com/gh_mirrors/de/demucs创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考