本地音频源分离实战：用Demucs提取贝斯音轨全流程解析

在 DAW 里反复听一首歌却听不清贝斯在哪，很多第一次扒带的人都会遇到这个问题。尤其是编曲层次比较密的歌曲，贝斯往往被鼓组和吉他盖住，单独靠耳朵去分辨音符会很吃力。如果手头没有官方分轨，本地音频源分离就是一条比较实用的路。这次我们用万能青年旅店《杀死那个石家庄人》作为素材示例，完整演示如何通过 Demucs、UVR5 这类本地工具，把混音里的贝斯音轨单独提取出来。这不会提供任何音轨下载，而是一套可复制的本地处理流程，包含环境准备、命令启动、批量任务、效果验证和常见坑位排查。

这个方案的核心价值在于：它不需要昂贵的专业软件，也不依赖在线服务，音频文件在本地处理，不会把素材上传到第三方服务器。CPU 可以跑，有 NVIDIA 显卡会更稳；命令行适合批量操作，也有 GUI 工具适合不想碰代码的用户。整个流程跑通之后，不仅能提取贝斯，还能顺带拿到鼓组、人声、其他乐器等分轨，后续扒带、混音对照、Remix 练习都用得上。

1. 核心能力速览

需要注意一点：这里的核心是模型推理，不是“无损还原”。分离出来的 bass 轨在听感上比原混音中的低频要突出，但不能等同于录音室分轨文件，细节和动态会有一定损耗。

2. 适用场景与使用边界

这个流程真正适合三类人：

一类是扒带学习者。想练贝斯翻弹或者写贝斯谱，频繁倒带、开大音量去听低频，不仅累，而且容易听错音；把 bass 轨单独提出来之后，根音走向、时值长短会清楚很多。

第二类是混音练习者。听原曲的低频布局，分析贝斯和底鼓在频段上是如何让开的，通过分轨观察波形和相位，比单纯猜更有依据。

第三类是 Remix 和二创用户。本地把原曲拆成人声、鼓、贝斯、其他乐器，重新编排、换鼓、改贝斯线，工作流会更接近“有工程文件”的效果。

使用边界也必须说清楚。音频源分离技术本身没有错，但使用对象和发布行为会涉及版权问题。下面几条要特别注意：

• 用于技术测试的音频素材，必须是自己已经合法获取的文件，例如正版购买、流媒体已下载并允许本地离线处理的曲目，或者自行录制、已获授权的作品。
• 分离后得到的音轨，不能当作“原创内容”公开传播，更不能直接分享给第三方作为素材库使用。
• 如果要把处理结果用于公开混音作品、教学视频、商业用途，需要提前获得词曲著作权方和录音版权方的授权。
• 涉及大量歌曲批量处理时，不要抱有“只要我不说就没有问题”的心态，合规边界与处理数量无关。

技术演示只在本地测试环境内完成，尽量不要把完整的分离音频直接传到公开网络。这篇文章也只讨论处理流程，不讨论任何歌词含义和歌曲背景。

3. 本地处理环境准备与前置条件

在开始安装之前，先确认三件事：操作系统、Python 版本、音频解码器。

Demucs 依赖 PyTorch，官方给出的兼容范围通常集中在 Python 3.9 到 3.11 附近，更稳妥的做法是新建一个虚拟环境，不要和系统 Python 混装。判断自己的 Python 版本：

python --version

如果版本不对，建议直接用 pyenv、conda 或系统包管理器安装一个 3.10 或 3.11，这样最省事。

音频解码方面，MP3 和部分 FLAC 文件需要 FFmpeg 支持，否则 Demucs 可能报“无法读取音频”的错误。FFmpeg 的安装方式取决于操作系统：

# Ubuntu / Debian sudo apt update && sudo apt install ffmpeg # macOS brew install ffmpeg

Windows 上可以选择从 FFmpeg 官网下载压缩包，解压后把bin目录加入系统 PATH，然后在新的终端窗口里验证：

ffmpeg -version

磁盘空间也值得提前规划。一首五分钟左右的歌，四轨 WAV 输出加起来可能在 150MB 以上；如果批量处理几十首歌，就很需要独立目录来管理。建议建立这样的工作区结构：

bass-demo/ ├── input/ # 原始音频 ├── separated/ # 分离结果 └── scripts/ # 批量脚本和日志

这里不写死具体版本号，是因为 PyTorch 和 Demucs 的依赖关系会随时间变化。安装前，最好去对应开源项目的文档页确认当前推荐版本，避免因为过时信息踩坑。

4. 安装部署与启动方式

4.1 Demucs 命令行安装

Demucs 是目前社区里使用面很广的开源音频源分离工具，用 PyTorch 训练，默认模型能输出四轨：bass、drums、other、vocals。安装命令如下：

cd ~/bass-demo python3.10 -m venv venv source venv/bin/activate pip install --upgrade pip pip install demucs

Windows PowerShell 下的激活命令略有不同：

py -3.10 -m venv venv .\venv\Scripts\Activate.ps1 pip install --upgrade pip pip install demucs

如果你的系统同时存在多个 Python 版本，最好用明确的python3.10命令来创建虚拟环境，避免误用其他版本。

安装完成后，检查帮助信息：

demucs --help

看到-n MODEL、--two-stems、--out这些参数，说明安装成功。

4.2 UVR5 GUI 安装

如果不想碰代码，可以选 UVR5 这类带图形界面的音频分离工具。它把多个分离模型集成在同一个界面里，也支持直接输出多个 stem 文件，使用门槛比命令行低很多。

UVR5 的启动原理比较简单：下载对应系统版本，解压后在电脑上运行主程序，界面里选择模型种类、输入音频、输出目录，再设置需要的分轨类型即可。比较常见的模型族包括 Demucs 系和 MDX-Net 系，不同模型对不同曲风的表现不同。初次使用建议保留默认的分离模型，先拿一首歌测试输出质量，不要一上来就同时跑十几个模型。

UVR5 对显卡驱动有一定要求，如果启动闪退，优先排查 GPU 驱动、Visual C++ 运行库和音频解码组件。后面第 8 节会集中讲排查思路。

5. 功能测试与效果验证

5.1 基础贝斯音轨提取测试

先拿一首歌做基础测试。假设本地已经有一份合法获取的《杀死那个石家庄人》音频文件，把它放到input目录下，然后执行：

mkdir -p ~/bass-demo/input ~/bass-demo/separated cp your_song.mp3 ~/bass-demo/input/song.mp3 cd ~/bass-demo source venv/bin/activate demucs --out separated input/song.mp3

这条命令会调用默认的 htdemucs 模型，输出四个分轨文件。完成后检查目录结构：

separated/ └── htdemucs/ └── song/ ├── bass.wav ├── drums.wav ├── other.wav └── vocals.wav

看到bass.wav出现，说明提取流程已经跑通。

5.2 分离质量验证

拿到bass.wav之后，不要急着直接当成品用，先做四步验证：

第一步，单独播放 bass 轨，听低频旋律线是否连续。如果经常出现断音、空洞，可能是原始混音中贝斯本身被编曲掩盖严重，也可能是分离模型对该曲目频率分配不理想。

第二步，观察频谱。用 Audacity 或 Sonic Visualizer 打开 bass.wav，重点看 40Hz 到 300Hz 区间的能量分布。贝斯轨在低频段应该有一条相对连续的横向能量带，如果高频部分出现大量毛刺，说明模型混入了其他乐器残留。

第三步，和原曲对齐对拍。在 DAW 里同时放原曲和 bass 轨，检查音量包络和节奏是否一致。分离模型偶尔会在乐句起始处产生预回声或拖尾，听感上类似“彗星声”。

第四步，用耳朵判断是否存在明显失真。如果 bass 轨低频发闷、动态怪异，可以换一个模型重新测试。

5.3 最容易踩的误区：two-stems 参数

很多第一次用 Demucs 的人会跑这样一条命令：

demucs --two-stems=vocals input/song.mp3

这条命令的结果只会生成vocals.wav和no_vocals.wav，不会生成单独的bass.wav。如果目标是提取贝斯，就不要加--two-stems，让模型默认输出四轨。四轨分离虽然计算量稍大，但能得到更细的分轨结果。

如果你想要的只是“去人声伴奏”，那才用--two-stems=vocals；如果目标是贝斯音轨，切记用默认四轨输出，否则你会一直在输出目录里找不存在的 bass 文件。

6. 接口 API 与批量任务

Demucs 本身没有公开的 HTTP 接口，但命令行工具非常适合写成批量任务。这里分别给两个层次的用法：目录批量处理，以及自封装 FastAPI 服务。

6.1 目录批量处理脚本

最简单的批量方式就是遍历一个目录下所有音频文件，逐首调用 Demucs：

from pathlib import Path import subprocess input_dir = Path("./input") output_dir = Path("./separated") for audio_file in sorted(input_dir.glob("*.mp3")): cmd = [ "demucs", "--out", str(output_dir), str(audio_file) ] print("RUN:", " ".join(cmd)) result = subprocess.run(cmd, capture_output=True, text=True) print(audio_file.name, "exit:", result.returncode) if result.returncode != 0: print(result.stderr[-500:])

这段脚本会逐个处理input目录下的 MP3 文件，每首歌的输出放在separated目录下。加日志和捕获错误后，即使中途某首歌失败，也不会导致整个批量中断。批量任务建议遵循一个原则：目录不要套太深，文件名尽量用英文和数字，避免中文路径和特殊字符造成命令解析问题。

6.2 自封装 API 服务

如果你的目标是给前端或其他业务系统提供音频分离能力，可以在 Demucs 外面套一层 FastAPI。下面是一个本地演示级别的封装，生产环境要按需增加鉴权和文件清理逻辑：

from pathlib import Path import shutil import subprocess from fastapi import FastAPI, UploadFile app = FastAPI() INPUT_DIR = Path("./upload_input") OUTPUT_DIR = Path("./separated") INPUT_DIR.mkdir(parents=True, exist_ok=True) OUTPUT_DIR.mkdir(parents=True, exist_ok=True) @app.post("/separate/bass") def separate_bass(file: UploadFile): source_path = INPUT_DIR / file.filename with source_path.open("wb") as f: shutil.copyfileobj(file.file, f) subprocess.run( ["demucs", "--out", str(OUTPUT_DIR), str(source_path)], check=True, ) stem_dir = OUTPUT_DIR / "htdemucs" / source_path.stem bass_path = stem_dir / "bass.wav" if not bass_path.exists(): return {"code": 500, "message": "bass.wav not generated"} return {"code": 0, "bass_file": str(bass_path)}

启动接口服务：

pip install fastapi uvicorn python-multipart uvicorn app:app --host 127.0.0.1 --port 8000

这里用普通def而不是async def，是为了让 FastAPI 把耗时任务放进线程池，避免阻塞整个事件循环。实际调用测试：

curl -X POST http://127.0.0.1:8000/separate/bass \ -F "file=@song.mp3"

接口返回类似{"code": 0, "bass_file": "..."}就说明链路已经跑通。这只是演示层级的代码，不是某个项目的官方 API，实际接入时还需要补充文件下载接口、任务队列、超时控制和磁盘清理机制。

7. 资源占用与性能观察

音频源分离是典型的计算密集型任务。虽然 short 音频片段不用太大显存，但完整歌曲的推理仍需观察资源使用情况。

观察 GPU 显存最直接的办法是看nvidia-smi：

nvidia-smi --query-gpu=memory.used,memory.total --format=csv -l 1

这条命令会每秒刷新一次显存占用和总量。在 Linux 或 WSL 下还可以用：

watch -n 1 nvidia-smi

CPU 用户怎么看？Windows 打开任务管理器，macOS 打开活动监视器，重点关注 CPU 占用率。Demucs 在纯 CPU 模式下也会多核跑满，体感速度取决于核心数和音频长度。

模型推理的耗时受四个因素影响最大：

• 音频时长。时间越短越快，所以批量处理前先拿一段 30 到 60 秒的片段测试，最稳妥。
• 模型复杂度。htdemucs_ft 通常会比基础型号慢一些，但某些曲风下分离质量更好。
• 是否使用 GPU。有 NVIDIA 显卡时，CUDA 加速可以减少等待时间；没有 GPU 就只能靠 CPU。
• 分块参数。Demucs 支持按片段长度切分处理，比如通过--segment调整每次送入模型的音频长度，取值越小，峰值显存通常越低，但处理速度可能变化。

显存不足时，优先降低--segment取值，而不是直接放弃 GPU。如果显存仍然不够，就退回 CPU 推理，或者换一个更轻量的分离模型。

UVR5 这类 GUI 工具同样可以在设置里观察当前使用的 GPU 设备。任务跑起来时如果界面卡顿，不代表死机，可以先看任务管理器里的 CPU 和 GPU 占用曲线，再判断是否真的出了问题。

8. 常见问题与排查方法

遇到问题时，先看日志再改参数。AI 音频处理的错误提示大多已经指明问题方向，不要凭感觉反复乱试。

9. 最佳实践与使用建议

第一次跑通整个流程后，建议按下面的方式组织你的工作习惯。

第一，先用小片段验证，不要一上来就对全曲跑重型模型。取目标歌曲中贝斯比较明显的副歌或主歌段落，裁出 30 到 60 秒，测试不同模型的效果。这样能把一轮实验时间控制在可接受范围内，也能更快对比模型差异。

第二，保留一份最小可运行配置。把环境创建命令、demucs 参数、输入输出路径写进一个 README 或 shell 脚本。以后换电脑，或者隔了很长时间再回来用，不用重新从网上翻教程。

第三，规范文件命名。原始音频、分离输出、手动整理的贝斯谱、混音工程分开存放，并加日期前缀。批量任务跑完以后，要在日志里记录哪首歌用了什么模型、什么时间处理完。这样如果某个输出文件效果不理想，能快速回溯到当时的运行条件。

第四，批量任务要加失败重试。网络下载的音频文件偶尔会损坏，分离模型也可能对极短或极空白的音频报错。批量脚本遇到非零退出码时，不要立刻终止整个队列，先把失败文件记录到日志，等任务结束后统一处理。

第五，用 DAW 做最终判断。只靠播放器听 bass 轨不客观，把 bass.wav 拖进 DAW，配上 EQ、压缩器观察波形和音高，再与原曲逐小节对齐，才能确定这个分离结果是否够用。对扒带来说，贝斯音轨的“音高清晰度”比“音质纯净度”更重要。

第六，涉及版权素材时，多问自己一句：我现在要发布的是什么？学习笔记、混音过程截图、Remix 作品、还是直接分享音轨？只有个人学习用途的本地处理最安全；任何公开传播行为都要提前确认授权边界。

10. 总结与下一步

这篇文章从“想把一首歌里的贝斯单独提取出来”这个非常具体的需求出发，走了一条完整的本地路径：用 Demucs 做四轨分离、用 UVR5 做 GUI 替代、用 Python 脚本做批量任务、用 FastAPI 做接口封装。最先验证的功能是demucs input/song.mp3之后能在separated目录下看到bass.wav。最容易踩的坑有两个：一是以为--two-stems=vocals也能输出 bass 轨，二是看到没有 bass 文件就怀疑模型坏了，其实只是参数理解不对。

下一步建议做什么？把刚提取出来的 bass 轨导入 DAW，先对拍，再做简单的低通滤波，然后对照原曲标记贝斯音符，尝试写一份自己的贝斯谱。等这套流程稳定了，再去试不同分离模型，或者把批量脚本扩展成带失败重试的服务端任务。

如果只是偶尔听清某一首歌的贝斯，命令行就够用了；如果要持续处理大量曲目，就值得把 API 封装和环境配置固定下来。音频源分离不是万能钥匙，却能把很多扒带和混音分析的工作从“靠耳朵硬扛”变成“先提取再细听”。后面再遇到类似问题，至少不用到处求分轨了。