用Python把一首ED变成数据：音频分析、特征提取与相似度检索实战

很多开发者听歌的状态，和普通用户没什么区别：打开播放器，循环一首 ED，然后继续写代码。但如果你恰好对音乐技术感兴趣，或者正在做音频、推荐、标签类的项目，就不能只靠耳朵了。你需要把一首歌当成文件、当成数据、当成信号来处理。

《Fate/strange Fake》开播之后，片尾曲的关注度一直不低。标题里那句“茧本塔人的潜在的なあい”既像歌词又像某种中二病发作的章节名，配合“坊主团”这个有点玩梗气质的署名，让技术党有了一个很合适的下手对象。我的判断很直接：音乐审美是主观的，但文件的采样率、频谱能量分布、BPM 曲线、音色特征是客观的。前者交给耳朵，后者完全可以交给 Python。

这篇文章不做乐评，也不会告诉你“这首歌表达了什么感情”。我会用一套可复用的音频分析流程，从读取文件开始，带你绘制波形图、频谱图，检测 BPM，做伴奏与人声分离，提取 MFCC 音色特征，最后用一个最简单的余弦相似度，把这首 ED 放到动漫歌曲库里做相似度检索。跑通之后，这套流程可以复用到任何一首歌上。

1. 为什么要把一首 ED 当成技术对象？

如果你只把 ED 当成“每集结尾响起的背景音乐”，那它确实只是一个四分钟左右的音频片段。但换到开发者视角，事情会变得完全不同：一首歌的文件里，藏着时间、频率、响度、节奏位置、音色分布、和声结构，甚至可以被拆成“人声轨”和“伴奏轨”。这些信息不是玄学，而是可以被读取、计算、比较的数据。

很多实际开发场景都需要这种能力。比如做音乐播放器想给歌曲自动打标签，需要判断一首歌是快歌还是慢歌，这时 BPM 检测就有用；想做一个“听歌识曲”的玩具，需要提取音频指纹；想做动漫曲库的相似推荐，需要把每首歌转换成长度一致的特征向量；想分析 ED 里哪一段副歌最“燃”，则需要看频谱能量随时间的变化。

传统做法是听。但人的耳朵很容易被主观情绪带偏，歌词、演唱、编曲习惯都会影响判断。而程序可以做到同一首歌无论听十遍还是跑一百遍，输出结果都一样。这不代表技术分析能取代听感，而是说，技术分析能帮我们发现容易被忽略的客观信息。

对刚接触音频分析的开发者来说，最大的误区是以为音频分析需要很强的机器学习基础。其实从信号处理层面就能做很多事：读取波形、画频谱、检测节拍、提取 MFCC，这些都属于音乐信息检索（MIR）的基础操作，用 Python 的 librosa 库几百行代码就能跑通。这篇文章会从零开始，不假设你有任何音频处理背景。

2. 一首 ED 在文件里究竟是什么？

动手写代码之前，先理解音频文件的底层逻辑。你听到的歌曲在计算机里不是连续的声音，而是一串按固定频率采样的数值。

2.1 采样率、位深度与声道

CD 音质的标准是 44100 Hz 采样率，也就是每秒采集 44100 个样本点。位深度决定了每个样本点的动态范围，常见的 16-bit 能表示 65536 个响度等级。声道则是单声道或立体声，立体声相当于左右两个独立信号通道。

这三者的组合直接决定了文件大小。一分钟单声道、44100 Hz、16-bit 的 WAV 文件大约占用 5 MB 左右，立体声翻倍，约 10 MB。这就是为什么无损格式体积大，而有损压缩格式如 MP3 可以减到十分之一以下。

2.2 文件格式与编码

音频文件的格式只是“容器”，真正决定音质的是编码方式。表格里整理了日常开发最常遇到的几种格式。

在音频分析里，最理想的输入是 WAV 或 FLAC，因为无损格式不丢高频信息。如果只有 MP3，也可以分析，但你要知道高频段可能已经被裁剪过，频谱图在高频位置会比无损源文件暗淡一些。这不算致命问题，做节奏检测和情感分析基本不受影响。

用 Python 加载音频时，库会统一帮你解码，所以多数情况下你不用关心原始编码，只需要关心最后拿到的采样率和声道数。

3. 环境准备与依赖安装

现在开始搭建环境。以下步骤假设你已经安装了 Python，版本要求不严格，Python 3.9 及以上即可。为了隔离依赖，建议使用虚拟环境。

3.1 创建虚拟环境

mkdir ed_analyzer && cd ed_analyzer python -m venv .venv # macOS / Linux 激活 source .venv/bin/activate # Windows 激活 # .venv\Scripts\activate

激活后记得查看命令行前缀是否出现(.venv)。如果后续安装的库找不到，八成是忘了激活虚拟环境。

3.2 安装依赖

音频分析主要依赖 librosa 和 matplotlib，人声分离推荐 demucs。第一条命令先装核心库：

pip install librosa matplotlib numpy

如果你打算用 demucs 做伴奏与人声分离，再执行：

pip install demucs

demucs 依赖 PyTorch，默认安装的是 CPU 版。如果你的电脑有 NVIDIA GPU，想用 GPU 加速，建议去 PyTorch 官网复制对应 CUDA 版本的安装命令，再安装 demucs。没有 GPU 也能跑，只是慢一点。

3.3 安装 FFmpeg

librosa 读取 MP3 等压缩格式需要依赖 FFmpeg 解码。没有 FFmpeg 时，加载 MP3 会直接报错。

• macOS：brew install ffmpeg
• Ubuntu / Debian：sudo apt install ffmpeg
• Windows：可以用winget install ffmpeg或从官网下载后配置 PATH

安装完成后，先验证：

ffmpeg -version

能输出版本信息就说明环境没问题。

3.4 准备测试文件

在ed_analyzer目录下放一首音频文件，文件名暂时用fate_sf_ed.mp3。注意：请确保你有权使用这个文件，仅在本地学习分析，不要传播提取出来的人声或伴奏。

4. 第一步：读取音频并绘制波形与频谱

环境就绪后，开始写第一段 Python 代码。新建一个analyze.py文件，或者直接在 Jupyter Notebook 里逐段执行。

4.1 加载音频文件

librosa 的load函数是整个分析流程的入口。它会自动解码文件，并转换成 float 类型的数组。

import librosa AUDIO_PATH = "fate_sf_ed.mp3" # mono=True 会把多声道混合成单声道，方便后续分析 # sr=22050 是重采样到 22050Hz，不是越高越好，对大多数分析来说够用 y, sr = librosa.load(AUDIO_PATH, mono=True, sr=22050) # y 是一维数组，每 22050 个点代表 1 秒音频 # sr 是采样率，这里等于 22050 print("音频数据形状:", y.shape) print("采样率:", sr) print("时长（秒）:", y.shape[0] / sr)

这里有两个容易踩坑的点。第一，mono=False会返回二维数组，形状是(声道数, 样本数)，如果后续不小心用单声道算法处理立体声数组，会报维度错误。第二，librosa 默认会把采样率重采样到 22050 Hz，这是为了分析速度，代价是损失超过 11kHz 的高频信息。大部分音乐的主要信息都在中低频，所以这个默认值在开发阶段很合适。

4.2 绘制波形图

波形图展示的是声音幅度随时间的变化。它能直观看到歌曲的响度起伏，比如前奏安静、副歌响亮的段落对比。

import matplotlib.pyplot as plt plt.figure(figsize=(14, 6)) librosa.display.waveshow(y, sr=sr, alpha=0.5) plt.title("Waveform - Fate Strange Fake ED") plt.xlabel("Time (s)") plt.ylabel("Amplitude") plt.tight_layout() plt.savefig("waveform.png", dpi=150) print("波形图已保存为 waveform.png")

注意，新版本 librosa 推荐使用librosa.display.waveshow，旧版本的waveplot已经弃用。如果你在报错信息里看到waveplot，说明你的 librosa 版本比较旧，建议升级。

4.3 绘制频谱图

波形图只能看到响度，频谱图则能看到不同时间点的频率分布。热力图的横轴是时间，纵轴是频率，颜色深浅代表能量强弱。

import numpy as np # 计算短时傅里叶变换 D = librosa.amplitude_to_db( np.abs(librosa.stft(y, n_fft=2048, hop_length=512)), ref=np.max ) plt.figure(figsize=(14, 6)) librosa.display.specshow(D, sr=sr, x_axis="time", y_axis="log", hop_length=512) plt.colorbar(format="%+2.0f dB") plt.title("Spectrogram - Fate Strange Fake ED") plt.xlabel("Time (s)") plt.ylabel("Frequency (Hz)") plt.tight_layout() plt.savefig("spectrogram.png", dpi=150) print("频谱图已保存为 spectrogram.png")

频谱图对判断歌曲风格很有帮助。如果你看到高频区域有持续亮线，说明这首歌的编排里有明显的镲片或合成器高频铺底；如果低频区域能量集中且规律性强，说明鼓点或贝斯线很突出。这些视觉信息是耳朵不太容易量化的。

5. 第二步：BPM 检测与节拍跟踪

BPM 是每分钟节拍数，是歌曲节奏快慢最直接的量化指标。动漫 ED 的 BPM 范围通常在 80 到 180 之间，高于 160 会明显感觉“快”，低于 90 则偏“缓”。用代码检测 BPM 并不神秘，librosa 内部会先计算频谱包络，再通过自相关函数找出节拍周期性最强的频率。

5.1 检测整首歌的 BPM

import librosa AUDIO_PATH = "fate_sf_ed.mp3" y, sr = librosa.load(AUDIO_PATH, mono=True, sr=22050) tempo, beat_frames = librosa.beat.beat_track(y=y, sr=sr) # 注意：新版 librosa 返回的 tempo 可能是 numpy 数组 print(f"估计 BPM: {float(tempo):.2f}") # 将节拍所在的帧索引换算成秒数 beat_times = librosa.frames_to_time(beat_frames, sr=sr) print("前 8 个节拍时间点（秒）:", beat_times[:8])

如果输出显示 BPM 为 120，意味着每隔 0.5 秒一个节拍。检查beat_times的相邻差值是否稳定，也能侧面验证检测结果。实际项目中，一首歌的前奏可能有变速或者无鼓点段落，这时算法容易误判。稳妥做法是分段检测，把歌曲切成几段分别估计 BPM，再取众数或中位数。

5.2 节拍跟踪的用途

节拍时间点不只是数字，它可以直接服务于切分与对齐。比如你想把 ED 的每个副歌段落自动切出来，可以先用节拍点对齐到小节；想用这首歌做视频踩点剪辑，节拍时间戳就是现成的“剪辑标记”。很多音乐可视化项目的基础功能，就是靠这步实现的。

但要注意一点：BPM 检测结果不等于歌曲的“情绪速度快感”。有的歌虽然 BPM 只有 100，但因为用了十六分音符的密集编排，听起来可能比 140 BPM 的歌更紧凑。算法看到的是底层脉冲，编曲密度要靠其他特征弥补。

6. 第三步：人声与伴奏分离

人声和伴奏分离，是从音频中提取“清唱轨”和“纯伴奏轨”的过程。过去实现难度很高，需要大量手工音频编辑；现在深度学习模型已经能做得比较干净，比如 Demucs 就是开源社区里效果靠前的方案。

6.1 为什么不直接用原始混音

很多分析任务需要把人声和伴奏分开。比如你想分析 ED 的和声走向，混音里乐器会干扰人声基频检测；你想做人声唱腔的特征比对，伴奏里的贝斯和鼓会在低频段造成大量干扰。分离之后，人声轨和伴奏轨各自的特征才更干净。

6.2 使用 Demucs 分离

Demucs 是命令行工具，安装后就能直接使用。下面命令把音频分离成人声和伴奏两部分：

demucs --two-stems=vocals -n htdemucs fate_sf_ed.mp3 -o separated

参数说明：

• --two-stems=vocals：只输出两轨，即人声和伴奏。
• -n htdemucs：使用官方推荐的混合 Transformer 模型，效果较好。
• -o separated：指定输出目录。

执行完成后，输出目录结构如下：

separated/ └── htdemucs/ └── fate_sf_ed/ ├── vocals.wav └── no_vocals.wav

打开vocals.wav仔细听，能明显听到演唱者的声音被单独出来。如果仍有少量乐器残留，属于正常现象，距离源文件越远的部分通常越难分干净。如果你的音频片段不是标准四分钟长度，分离速度不会太慢；但 CPU 跑整首歌可能需要一分钟到几分钟，GPU 会快很多。

6.3 分离后可以做什么

拿到人声轨后，可以继续做基频检测，提取歌手的主旋律线；拿到伴奏轨后，可以更准确地分析调性和和弦进行。在情感识别类项目里，人声轨通常比混音轨更容易提取出“情绪特征”，因为人的歌声本身就是情绪表达的主要载体。

不过要提醒一句：分离得到的音轨属于数字处理产物，如果原曲有版权，分离后的人声轨依然受版权保护。你可以拿来做学习、实验，但不适合公开传播或商用。

7. 第四步：MFCC 特征提取

MFCC 是 Mel 频率倒谱系数，在语音识别、音色识别、音乐流派分类里出镜率极高。它模拟人耳对频率的非线性感知，把频谱压缩成一组系数，每个系数代表声音在不同感观频段上的能量分布特征。可以把它理解成一段声音的“音色指纹”。

7.1 提取 MFCC

import librosa AUDIO_PATH = "fate_sf_ed.mp3" y, sr = librosa.load(AUDIO_PATH, mono=True, sr=22050) # 提取 13 维 MFCC mfcc = librosa.feature.mfcc(y=y, sr=sr, n_mfcc=13) # 输出形状 print("MFCC 形状（n_mfcc, 时间帧）:", mfcc.shape) # 对时间维度取平均，得到整首歌的特征向量 mfcc_mean = mfcc.mean(axis=1) print("MFCC 均值向量:", mfcc_mean)

得到的mfcc是二维数组，第一维是 13 个系数，第二维是时间轴上的帧数。因为每帧 512 个采样点，22050 Hz 采样率下大约每秒会产生 43 帧，一首四分钟的歌会有上万帧。取均值后，我们就得到 13 个数字，这 13 个数字可以代表整首歌的音色特征。

7.2 特征怎么理解

MFCC 的第一维通常代表整体能量，其他维则刻画频谱形状。你可以把 13 维向量想象成一个 13 维空间里的坐标：每首歌都对应这个空间里的一个点。音色相似的歌，点与点之间的距离会比较近；风格差异大的歌，距离会比较远。这就是第 8 章相似度检索的基础。

当然，用均值向量会损失时间信息。动态一点的方案是把整个 MFCC 时间序列拼接起来，或对每个系数分别求方差、峰度等统计量。对相似度检索这种轻量任务，均值向量已经够用，做原型验证时不用一上来就上复杂模型。

8. 第五步：构建一个简单的 ED 相似度检索系统

有了特征向量，相似度检索就顺理成章。原理是计算向量之间的余弦相似度，值越接近 1，表示方向越一致，歌曲音色越相似。代码结构并不复杂，我会用一个小函数遍历整个曲库，对比目标歌曲和曲库中其他歌曲的 MFCC 均值向量。

8.1 批量提取特征

先建立一个songs目录，放入多首动漫相关的歌曲，格式建议统一用 WAV 或 MP3。然后批量读取特征并缓存到字典里。

import os import librosa import numpy as np SONG_DIR = "songs" def extract_mfcc_feature(path, sr=22050, n_mfcc=13, duration=120): # duration 限制只取前 120 秒，避免文件过长导致特征偏散 y, sr = librosa.load(path, sr=sr, mono=True, duration=duration) mfcc = librosa.feature.mfcc(y=y, sr=sr, n_mfcc=n_mfcc) return mfcc.mean(axis=1) database = {} for fname in os.listdir(SONG_DIR): if fname.lower().endswith((".mp3", ".wav", ".flac")): path = os.path.join(SONG_DIR, fname) database[fname] = extract_mfcc_feature(path) print(f"已提取特征: {fname}")

如果文件是 m4a 格式，librosa 默认也支持，但要求本机有正确的解码器。为了减少不必要的环境问题，建议先把 m4a 转成 wav 或 mp3 再分析。

8.2 余弦相似度计算

def cosine_sim(v1, v2): return float(np.dot(v1, v2) / (np.linalg.norm(v1) * np.linalg.norm(v2))) target = "fate_sf_ed.mp3" target_vec = extract_mfcc_feature(target) results = [] for name, vec in database.items(): if name == target: continue score = cosine_sim(target_vec, vec) results.append((name, score)) results.sort(key=lambda x: x[1], reverse=True) print("相似度 Top 5:") for name, score in results[:5]: print(f"{score:.3f} {name}")

这个系统确实很简陋，但它已经具备检索系统的核心结构：特征提取、向量化、相似度度量、排序输出。如果你想更进一步，可以把 MFCC 均值替换成深度学习模型提取的语义向量，比如用 CLAP 这类模型，相似度结果会更接近“听感上的相似”。

8.3 可视化特征空间

装了 scikit-learn 的话，可以把所有歌曲的 13 维特征降维到二维平面，直观看看分布。

from sklearn.decomposition import PCA import matplotlib.pyplot as plt names = list(database.keys()) matrix = np.vstack([database[n] for n in names]) pca = PCA(n_components=2) coords = pca.fit_transform(matrix) plt.figure(figsize=(10, 8)) for i, name in enumerate(names): plt.scatter(coords[i, 0], coords[i, 1]) plt.text(coords[i, 0] + 0.02, coords[i, 1] + 0.02, name, fontsize=9) plt.title("MFCC Feature Space (PCA)") plt.tight_layout() plt.savefig("mfcc_pca.png", dpi=150)

如果聚类效果明显，说明这批歌曲的音色差异已经被特征向量拆开了；如果点分布很散乱，可能是曲库风格太杂，也可能是 MFCC 均值信息量不够。这本身就是实验结论，不代表代码有问题。

9. 常见问题与排查方法

音频分析项目第一次跑不顺，大多数不是算法问题，而是环境和解码问题。下面这张表整理了最容易遇到的几类情况。

最常忽视的是 FFmpeg 问题。很多人报错后第一反应是查 librosa 代码，其实错误日志里明确写了解码失败。另一个常见坑是音频文件路径包含中文或空格，Windows 下容易出现字符集问题，建议开发阶段先用纯英文路径。

如果 demucs 在 Windows 上提示找不到模型文件，基本上是因为第一次运行需要从网上下载预训练权重，网络不稳定时下载中断。可以多试几次，或者手动下载对应权重放到模型缓存目录。

10. 最佳实践与工程建议

前面五步流程，单看每一步都很简单，但放到真实项目里，有几个工程细节值得提前规划。

10.1 统一采样率与声道数

分析流程的第一步永远是统一参数。建议所有音频在加载时都使用mono=True和固定采样率22050，这样能避免声道、采样率不一致导致的维度错误。真实项目中，不同来源的音频可能混着各种采样率和声道，如果不做统一，批量任务很容易在中途崩溃。

10.2 为批量任务添加缓存

MFCC 提取是有计算成本的。如果曲库有几百首歌，每次跑检索都重新提取一遍特征，会浪费大量时间。更好的做法是把特征保存成npy文件或 JSON，文件名与音频名对应，下次直接读取缓存。

cache_file = "features_cache.json" import json if not os.path.exists(cache_file): cache = {name: feat.tolist() for name, feat in database.items()} with open(cache_file, "w", encoding="utf-8") as f: json.dump(cache, f, ensure_ascii=False, indent=2)

如果是更大的曲库，建议改用 SQLite 或向量数据库，像 Milvus、Chroma 这类工具本身就支持向量索引和相似度检索，Python 里直接调用即可。

10.3 关于版权

音频分析领域特别容易忽略版权边界。你可以下载或翻录音源用于个人学习、算法实验，但不要把分离出来的人声或伴奏公开发布，不要用这些音轨做二次传播，更不要用受版权保护的音乐训练商用模型。很多音乐机器学习项目使用的是开放数据集或者已经授权的资源，业余项目也要养成记录来源、限制用途的习惯。

10.4 记录实验环境

音频库的接口变化比较频繁，今天能跑的代码，半年后可能因为 librosa 升级而报错。建议把关键依赖写进requirements.txt：

librosa==0.10.2.post1 numpy==1.26.4 matplotlib==3.8.4 demucs==4.0.1

需要注意，这里给出的版本只是示例，实际安装前请以当前环境兼容版本为准。固定依赖，才能保证实验结果可复现。

10.5 分析结果的解读要留有余地

BPM 检测给出的数字、相似度检索给出的排名，都有误差和不确定性。不要把一个数字当成绝对答案。更合理的做法是用多个特征交叉验证：BPM 结合节拍跟踪结果看，MFCC 相似度结合频谱图看，人声分离效果结合试听判断。技术分析的本质是提供证据，不是出具判决书。

11. 总结：用技术重新听一遍 ED

这篇文章从零开始，讲完了对一首动漫 ED 做基础音频分析的全流程：使用 librosa 读取音频，绘制波形图和频谱图，检测 BPM 与节拍信息，使用 Demucs 分离人声和伴奏，提取 MFCC 特征，最后用余弦相似度构建了一个迷你歌曲检索系统。

这套流程本身并不难，难的是建立“把音乐当成数据”的思维。当你再听到一首上头的 ED，第一反应不再是“真好听”三个字，而是“这首 BPM 大概多少、频谱图中高频亮不亮、MFCC 特征和哪些歌更接近”，这本身就是一种技术能力。

下一步可以根据兴趣继续深入。想做音乐情绪识别，可以在 MFCC 基础上加一个简单分类模型；想做完整曲库管理工具，可以把缓存结构升级成向量数据库；想分析副歌结构，可以结合频谱能量曲线做段落切分。甚至可以尝试用 CLAP 这类多模态模型，为歌曲生成更接近人类听觉语义的嵌入向量。

技术能量化节奏、频谱、音色这些客观属性，但它解释不了感动。你完全可以先听一遍歌，再跑一遍代码。两者兼得，才是程序员享受动漫音乐的正确姿势。