简介：面向人工智能音乐创作与深度学习开发者的完整工程包，聚焦以歌词生成旋律、以旋律生成伴奏两条独立训练链路，覆盖从环境搭建、数据预处理到模型训练与推理部署的全流程。压缩包共85个文件，包含22个Python源码、12个示例样本、4个MIDI文件、2个Jupyter Notebook以及环境配置文档和Shell脚本等，整体约226.19MB，目录按evaluation、training、inference等模块划分，便于按阶段检索。该资源在CSDN已有409人浏览学习，适合具备Python基础、希望复现歌词到旋律及旋律到伴奏生成流程的研究者或开发者参考。工程内提供质量评估工具（如DTW、相似度、准确率计算脚本），配套歌词与旋律样例数据支撑快速跑通实验，并附带环境搭建教程，可帮助读者减少配置与冷启动成本，专注模型调优与音乐生成实践。
1. 深度学习生成旋律与伴奏：这套代码把「歌词到旋律到伴奏」拆成了两个可独立训练的模型
我拆过不少所谓「AI 音乐生成」的压缩包，大多数是拿别人的 Demo 换个壳，真正能跑通的不多。这份资源不一样的地方在于，它把整条链路明确切成两个模块：以歌词为输入生成旋律，以旋律为输入生成伴奏，两个模型各自独立训练、独立推理，最后拼起来用。也就是说，你可以只训练歌词转旋律，把伴奏模块暂时放一边；也可以拿现成的旋律直接喂给第二个模型。它面向的不是「看热闹」的读者，而是打算在 MIR（音乐信息检索）或音乐生成方向动手做实验的人。包里的 training、inferrence、evaluation 三个目录对应着从训练到推理再到评估的完整闭环，README_.md 里还带了环境搭建的说明。
2. GPU 训练环境搭建：Python、PyTorch 和 miditoolkit 的组合最容易翻车
2.1 环境版本清单与 conda 安装
很多人在这一步卡住，不是缺这个库就是版本冲突。我建议直接用 conda 建独立环境，别装到 base 里，因为后面调试代码时你大概率会反复 pip install，污染了 base 环境想哭都来不及。这份代码核心依赖就三块：深度学习框架（PyTorch 或 TensorFlow）、MIDI 处理库（miditoolkit）、音频分析库（librosa）。我推荐 PyTorch，因为后续看训练循环和推理代码都更直观。以下是常用安装命令：
conda create -n telemelody python=3.8 conda activate telemelody pip install torch>=1.9.0 pip install miditoolkit librosapython=3.8是我刻意选的——很多音乐生成相关的开源库对 3.9 以上的兼容性问题还没完全解决，3.8 比较稳。miditoolkit是 MIDI 解析库，负责把.mid文件读成 note 序列；librosa用来分析音频特征，在数据预处理阶段会用到。装完跑一下验证：
import miditoolkit import librosa # 读一个 MIDI 文件验证环境 mid = miditoolkit.MidiFile('demo.mid') print(mid.instruments) print(librosa.__version__)如果demo.mid能正常打印出乐器列表，说明环境基本可用。注意这里只是验证导入，真正处理数据还要靠训练脚本的预处理逻辑。GPU 支持方面，torch.cuda.is_available()返回 True 才代表显卡生效，这一步没确认就直接开训，你会发现在 3090 上跑出和 CPU 一样的速度，白等半天。
2.2 数据准备：MIDI 和歌词对齐
训练数据的核心格式是 MIDI 文件加对应的歌词文本。你需要把旋律转成 token 序列，而不是直接拿原始音频喂模型。我这里说的预处理逻辑和包里data目录的职责一致：把每首歌的旋律按时间切片，提取 pitch、duration、velocity，再把歌词按音节对齐到时间轴上。
import miditoolkit # 读取 MIDI 并提取 note 序列 mid = miditoolkit.MidiFile('song.mid') notes = [] for inst in mid.instruments: if not inst.is_drum: for note in inst.notes: notes.append({ 'pitch': note.pitch, # MIDI 音高 0-127 'start': note.start, # tick 单位 'end': note.end, 'velocity': note.velocity # 力度 })start和end的单位是 tick，不是秒。这是最容易踩的坑——后面评估阶段如果混用秒和 tick，DTW 计算会直接爆炸。歌词对齐这一步，常见做法是用音素级对齐工具把歌词音素标到对应音符的时间点上，生成一个(歌词, 旋律序列)的配对文件。中文歌词还要额外考虑多音字，这个我在第 5 章会细说。
2.3 目录结构导读：training、inferrence、evaluation 分别管什么
拿到压缩包后先别急着看代码，先把目录结构认清楚。training目录下有两个子目录：lyric2rhythm和template2melody，这就是标题里说的两个独立模型。lyric2rhythm学的是歌词到节奏模板的映射，template2melody学的是模板到旋律的映射。节奏模板是中间产物，不是最终结果——它定义了每个音素的节奏位置和音高走向，可以理解成给旋律画了一个骨架。inferrence目录放推理脚本，注意原始包里写的是inferrence（多了一个 r），不是inference，这种细节往往就是外人跑不通的原因。evaluation目录里是cal_dtw.py、cal_similarity.py、cal_acc.py三个评估脚本，分别算动态时间规整距离、相似度和准确率。
3. lyric2rhythm：歌词转节奏模板的模型长什么样，怎么训练
3.1 lyric2rhythm 到底在学什么
从歌词直接生成音符序列是难做的，因为歌词和旋律之间不是一一对应的关系——同一句歌词可以配完全不同的旋律。所以这份代码采取了一个更聪明的折中路线：先把歌词转成节奏模板，再从模板生成旋律。节奏模板是一个序列，每个元素对应歌词的一个音素，包含该音素应该唱多长、音高大致落在哪个范围。这一步是典型序列到序列建模，模型层面用 LSTM 或 Transformer 都很常见。从工程角度看，Transformer 的训练收敛更快，但小数据集上 LSTM 更稳。我一般会先跑 LSTM 做一个 baseline，再上 Transformer 对比。
这个模型输入的 token 是歌词的音素编码。词嵌入用的是随机初始化加训练，没有直接套用预训练语言模型，因为音乐数据集里的歌词文本和通用语料分布不太一样，预训练向量在这里增益有限。输出端是节奏模板的 token 序列，包括时长和音高轮廓两类 token，所以描述时常用「双层解码」这个词。
import torch import torch.nn as nn class LyricToRhythm(nn.Module): def __init__(self, vocab_size, d_model, nhead, num_layers): super().__init__() self.embedding = nn.Embedding(vocab_size, d_model) encoder_layer = nn.TransformerEncoderLayer(d_model, nhead, batch_first=True) self.encoder = nn.TransformerEncoder(encoder_layer, num_layers) self.fc = nn.Linear(d_model, vocab_size) # 输出节奏 token def forward(self, lyrics_tokens): # lyrics_tokens: (batch, seq_len) x = self.embedding(lyrics_tokens) x = self.encoder(x) logits = self.fc(x) return logits这段代码是简化版的核心结构：词嵌入把音素 token 变成向量，Transformer 编码器捕捉上下文关系，全连接层输出每个位置的节奏 token 概率。vocab_size取决于你预处理时用多少种音素和节奏类型，d_model设为 256 或 512 都行。注意这里用了batch_first=True，输入形状是(batch, seq_len)，别搞成(seq_len, batch)不然数据管线和模型对不上。
3.2 训练循环的核心结构与参数
训练这份代码推荐的还是标准的 cross-entropy + teacher forcing。Teacher forcing 的意思是训练时解码器每一步输入的是 ground truth 的上一个 token，而不是模型自己预测的 token；推理时没有 ground truth 可用，只能靠自己预测的东西往后走。这两者的差距就是后面会遇到的「训练指标好看、生成结果很烂」的根源。
optimizer = torch.optim.Adam(model.parameters(), lr=1e-3) for epoch in range(30): for batch in dataloader: lyrics, rhythm = batch optimizer.zero_grad() logits = model(lyrics) # 忽略 padding 位置的 loss loss = nn.CrossEntropyLoss(ignore_index=0)(logits.view(-1, vocab_size), rhythm.view(-1)) loss.backward() nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step()lr=1e-3对 Transformer 来说属于常见起点，如果 loss 震荡就降到5e-4。clip_grad_norm设成 1.0 是我个人的固定习惯，序列生成任务里梯度爆炸几乎必然出现，不裁剪的话每隔几十步 loss 就会跳一次inf。ignore_index=0很重要，因为 padding 位置不参与 loss 计算，否则模型会浪费时间学「怎么预测空位」。训练到后期如果过拟合，每隔 5 个 epoch 在验证集上算一次困惑度（perplexity），比 loss 更直观。
3.3 损失函数和评估方式的选择
代码里损失函数就是交叉熵，没有用 MSE。原因是节奏模板是离散 token 序列，不是连续数值，MSE 在这里不合适。评估阶段主要靠第 6 章要讲的cal_acc.py——它算的是节奏模板的逐 token 准确率，但真实业务里你更关心的是生成的旋律好不好听，这个大家心里都清楚，准确率只是工程门槛。我个人的习惯是训练中期每 5 个 epoch 人工听一次生成结果，别等全部训完再听，否则花了一天训练后发现方向错了，后悔药都没有。
4. template2melody：节奏模板生成旋律的建模细节与推理调用
4.1 template2melody 的输入输出表示
第二个模型拿节奏模板当输入，输出的是真正的旋律 note 序列。这一步要解决的是「从骨架到血肉」的过程。节奏模板已经定好了每个音应该在什么时间点出现、持续多久，模型要补的是具体音高。所以输入序列的每个元素是「时间 + 时长 + 音高范围」的编码，输出序列的每个元素是 MIDI 音高和时长的组合 token。这里用的模型结构往往比第一阶段更复杂，因为旋律的连贯性和和声搭配对长距离依赖非常敏感，Transformer 的自注意力机制在这种场景下优势明显。
输入到模型的表示可以用一个表格总结：
| 字段 | 类型 | 示例 | 说明 |
|---|---|---|---|
| position | 离散 token | 0-127 | 音符在模板中的序号 |
| duration | 离散 token | 32/64/128 tick | 音符时长 |
| pitch_range | 离散 token | 60-72 | 音高限制区间 |
训练集里的每个 MIDI 文件都要转换成这种三元组序列。你可以在预处理阶段自己提取，也可以直接使用包里data目录下已经处理好的数据。前者的好处是自己控制采样精度，比如把量化粒度从 16 分音符改成 32 分音符；后者的好处是省时间，直接开训。
4.2 训练和推理：从模板到旋律
训练环节和 lyric2rhythm 的流程几乎一样，区别只在数据集的形状上。这里给一个推理阶段的示例，这对理解整个系统更有价值。
from inferrence.infer_zh import generate_melody # 输入一句歌词，得到节奏模板，然后生成旋律 lyrics = "明月几时有 把酒问青天" melody = generate_melody(lyrics, model_path="checkpoints/template2melody.pt") print(melody[:10]) # 输出示例: [(64, 0.5), (67, 0.25), (72, 0.5), ...] # 每个元素是 (pitch, duration)，时长单位是秒generate_melody这个函数内部把两个模型串起来了：先调用 lyric2rhythm 把歌词变成节奏模板，再调用 template2melody 把模板生成旋律。这一步的输出是(音高, 时长)的元组列表，叫旋律序列。如果你不想走歌词输入，也可以只喂节奏模板，直接把第二段模型单独跑起来，这正是标题里说的「两个模型可以分别训练」在工程上的体现。注意model_path要指向训练时保存的权重路径，保存时建议同时存optimizer和epoch，方便断点续训。
4.3 infer_zh 与 infer_en：中英文歌词走的是同一套管线吗
这个包很有意思的一点是提供了infer_zh.py和infer_en.py两个推理入口。两者核心流程一致，区别在预处理阶段：英文歌词按空格拆词、按音节映射音素；中文歌词要按字符拆，还要处理多音字——比如「长」在「长夜」和「成长」里发音完全不同。做中文模型时，音素映射表里必须包含多音字消歧规则，否则同一句歌词换一个人声朗读，生成旋律可能完全变样。
python infer_zh.py --lyrics "床前明月光" --output melody.mid python infer_en.py --lyrics "A gentle breeze in the summer night" --output melody_en.mid第一个命令里--lyrics是输入歌词，--output指定 MIDI 输出路径。英文命令的格式一样，这说明两个入口的接口设计保持了一致，方便切换。实际跑的时候，English 效果通常会比中文好一点，因为英文数据集大、音素体系成熟，这个差距不是模型问题，是数据积累问题。
5. 实操避坑：数据对齐、训练策略和推理阶段最常见的五个坑
5.1 目录名 inferrence 是故意的，拼写别改
现象：按 README 里的路径from inference.infer_zh import generate_melody导入，直接 ModuleNotFoundError。
原因：包作者把目录名写成了inferrence，多了个 r，这是历史遗留问题。你去查这个项目的源码和文档，会发现这个拼写从头到尾保持一致。
解决：导入路径用inferrence.infer_zh，不要自作主张改成inference。这个坑在 git 仓库里非常典型——作者写错后大家都将错就错。如果后续 fork 到自己仓库想修正，记得把推理脚本里所有内部 import 路径一起改。
5.2 训练 loss 一直在降，生成的旋律却是乱的
现象：训练集和验证集 loss 都正常下降，但推理生成的旋律和歌词内容毫无关系，节奏也是散的。
原因：这是 teacher forcing 导致的经典问题。训练时每一步都给了真实 token 作为下文，模型没学会「自己错了之后怎么从错误状态恢复」。一旦推理时前两步预测偏了，后面的 token 跟着漂移，整个序列就崩了。另一个原因是上面说的，第二步生成旋律时对节奏模板过度拟合，损失函数没有捕捉旋律的连贯性。
解决：训练时用 scheduled sampling，以一定概率喂模型自己的预测而不是真实 token。具体做法是训练前期概率小，后期逐步增大。另外可以在推理时用 beam search，每步保留前 5 个候选，最后挑整体概率最高的序列，这比贪心解码稳很多。
5.3 评估时 DTW 距离异常大：时长单位混用
现象：cal_dtw.py跑出来的距离高达几千，完全没法用，但生成结果人工听感没有这么差。
原因：MIDI 里 note 的start和end单位是 tick，而模型推理输出的 duration 单位是秒，两个序列直接算 DTW 距离，数值失真是必然的。DTW 对齐的是时间轴，单位混了，距离就会被放大一个数量级。
解决：统一换算。先用 MIDI 文件的ticks_per_beat把 tick 转成节拍数，再乘上速度（BPM）转成秒。常见做法是写一个统一的工具函数，数据预处理、训练、推理、评估都用它，不要在四个环节各写一份换算逻辑。单位统一后 DTW 距离才有横向比较意义。
5.4 中文歌词的韵律对齐比英文更难，别直接套音素映射
现象：中文歌词生成的旋律，每个字符对应的音符时长几乎一样，听起来像机器人念诗。
原因：英文有天然的单词重音和音节划分，音素映射到节奏模板时信息丰富。中文按字拆分后，每个字都是单音节，没有英文那样的重音层级，直接把每个字对应一个固定时长，模板就退化成等间隔序列。
解决：在源头上用「拼音 + 声调」联合表征，声调可以大致对应音高的起伏方向——一声偏高、三声转折、四声下降。这个映射关系不一定精确，但比完全不管声调要好得多。如果你手上只有纯文本数据，可以花一下午写一个脚本用 pypinyin 做注音，这是快准狠的成本最低的做法。
5.5 GPU 显存溢出和 beam search 的取舍
现象：训练没显存溢出，推理时反而 OOM。
原因：beam search 的 batch size 被乘以 beam width 之后，序列长度又长，显存迅速吃满。Transformer 的自注意力占显存是二次方增长，序列翻倍，显存翻四倍。
解决：推理时把 beam width 从 10 降到 3，或者按长度分批处理，每批最多 16 个序列。如果还要省显存，可以用torch.no_grad()包裹推理逻辑，并调用torch.cuda.empty_cache()及时释放缓存。我更倾向的做法是推理阶段直接用 CPU，生成旋律本来就不是高并发场景，速度慢点没关系，显存留着训练用。
6. 用 cal_dtw、cal_similarity 和 cal_acc 验证生成效果
6.1 三个评估脚本怎么跑
生成结果不能只靠耳朵验收，量化指标至少能说明系统没跑偏。evaluation目录下三个脚本各有分工：cal_dtw算生成旋律和参考旋律的时序对齐距离；cal_similarity算音高/节奏分布相似度；cal_acc算逐 token 准确率。三者组合起来，基本覆盖了「对齐、分布、精读」三个层面的验证。
python evaluation/cal_dtw.py --generated generated.mid --reference reference.mid python evaluation/cal_similarity.py --generated generated.mid --reference reference.mid python evaluation/cal_acc.py --generated generated.mid --reference reference.mid三个脚本的参数接口一致，都是两个 MIDI 文件路径。cal_dtw输出一个距离值，越小越好；cal_similarity输出 0-1 之间的数值，越接近 1 表示分布越像；cal_acc输出百分比准确率。我看结果时会先盯 DTW，因为它最敏感——如果 DTW 距离在正常范围内，说明节奏结构基本保住了；再看相似度，判断旋律走向和音符密度是否合理；最后看 acc，评估精确匹配程度。
6.2 指标怎么看：三个维度合起来才是完整结论
单个指标都有误导性。acc 高但 DTW 差，说明音符序列相近但节奏对齐完全跑偏，这种情况下听感往往很怪；DTW 好但相似度低，说明时间上对齐了但音高选择乏味，缺少变化；相似度高但 acc 低，可能只是音高分布接近但顺序乱了。我一般按这个流程验收：先跑 DTW 排除结构性问题，再跑相似度听感预判，最后用 acc 做工程底线检查。完整跑一遍三个脚本，大约一分钟。从那次之后，我每次训练完模型都强制走一遍三件套，宁可多花一分钟，也不在评审现场被一句「你的指标呢」问住。希望这份代码和这套流程帮到你。
本文还有配套的精品资源，点击获取
