简介面向深度学习音乐生成场景这份资料包教你用歌词生成旋律、用旋律生成伴奏两个模型可独立训练涉及LSTM、Transformer、VAE等模型思路适合人工智能或音乐信息检索方向的开发者入门。压缩包共85个文件约226.19MB包含22个Python脚本、12个sample示例数据还有MIDI/XML音乐文件、3个lyric歌词、3个sh运行脚本、2个ipynb notebook和文本说明目录按evaluation、training、inferrence划分可从数据到评估分模块学习。已有409人学习内容覆盖环境搭建、数据预处理、模型训练、评估与部署全流程。具体提供了DTW相似度评估脚本、中英文推理脚本、多模态训练代码等可直接运行的工具另有环境搭建教程和目录结构说明便于读者复现实验并扩展到自己的歌词-旋律-伴奏数据集。配套的README和notebook能够引导逐步复现从歌词到旋律、旋律到伴奏的完整实验流程帮助理解对齐、特征提取等关键细节。1. 歌词进旋律出、旋律进伴奏出双模型生成链路到底难在哪把歌词变成能唱的旋律再把旋律变成能听的伴奏——这条双模型链路看起来是两个独立的深度学习生成任务但真正动过手的人都知道模型训练只占最后10%的工程量前面90%的时间都耗在词曲对齐、音符量化和数据清洗上。这套方案最大的价值是解耦歌词模型和伴奏模型分开训练、分开调参哪个环节不行就单独重来不用整条流水线推倒。适合做量贩式作曲工具、歌手Demo辅助和编曲工作流预研的开发者。如果你正打算用深度学习做音乐生成又不想一上来就碰端到端整曲生成这种黑匣子这个方向是最值得先复现的。2. 歌词到旋律模型词曲对齐、音符token化与最小训练循环2.1 歌词侧输入按「字声调」转拼音序列而不是按词中文歌词和英文歌词的处理路径不一样。英文是按音素phoneme切一个单词可能对应多个音素旋律基本跟着音节走中文是单音节语言一个字对应一个音节天然跟音符形成一一映射。所以中文项目我强烈建议按字转拼音而不是按词切分。按词切会带来两个现实问题词表膨胀导致embedding矩阵变大在几千首量级的数据下学不充分歌词里的词边界与音乐里的音符边界经常错位比如「喜欢你」三个字可能落在三个不同的八分音符上按词建模等于额外增加一层对齐负担模型要同时学词边界和音边界难度翻倍。拼音的声调信息不要丢。中文四声加轻声的调型与旋律走向存在统计相关性把wo3作为一个完整token输入模型有机会学到「三声后面旋律更容易往下走」这类规律。具体做法是用 pypinyin 库把歌词转成带声调的拼音序列再建立拼音到整数的映射表。带声调拼音的词表规模在 400 左右相比常用汉字 3500 的量级embedding 参数少了一个数量级小数据下更友好。2.2 旋律侧输出MIDI音符怎么拆成模型能吞的token旋律侧不能直接拿 MIDI 音符数字裸奔。MIDI 音高是 0 到 127 的整数时值是浮点秒数直接把(pitch, duration)当回归目标模型会输出一片模糊的平均值——这是很多音乐生成项目翻车的根源拿分类模型去预测连续值生成结果全是中间态。正确做法是把旋律量化成 token 序列每个 token 同时编码音高和时值。我一般把音高范围限定在 C2MIDI 36到 B5MIDI 83共 48 个半音覆盖流行歌曲人声主旋律的绝大多数音域。时值按十六分音符为最小单位从 1 到 16超长音直接截断。这样联合词表是 48×16768 个有效 token加一个休止符 token 和一个结束符 token总共 770 左右。组织方式有两种每个 token 表示一个「音高时值」对序列长度等于音符数或者把音高序列和时值序列分成两个输出头序列长度翻倍。前者解码阶段更简单配合交叉熵损失直接训练后者生成时能灵活控制节奏但实现复杂度成倍上升。对小规模项目选前者先把链路跑通再说。2.3 模型结构选型Encoder-Decoder比纯Decoder更适合词曲映射歌词到旋律本质是条件序列生成输入歌词 token 序列输出音符 token 序列。最常见的做法是 Encoder-Decoder 结构Encoder 读完整句歌词Decoder 在歌词语义约束下逐个生成音符。为什么不用纯 Decoder像 GPT 那样把歌词和旋律拼成一个序列生成因为歌词和旋律不是简单续写关系两者长度也不一致Encoder-Decoder 对「变长映射」的表达更直接。Transformer 和 LSTM 怎么选我的经验是训练数据在几千首以下时LSTM 或 GRU 反而不容易过拟合、收敛也快数据量上万Transformer 的优势才明显。但考虑做这个方向的人大概率会逐步扩充数据直接用 Transformer 少走弯路。d_model 设 256、注意力头数 4、Encoder 和 Decoder 各 3 层参数量大约 30M16G 显存的单卡随便训低显存设备也能通过梯度累积跑起来。2.4 从MIDI提取训练对量化、对齐与清洗三件套训练对从哪来常见做法是使用带人声轨和歌词标注的 MIDI 数据集比如社区流传的 LMD即 Lakh MIDI Dataset或者从卡拉 OK MIDI 里筛选带歌词轨的文件。关键是把歌词和音符按时间对齐这个环节直接决定模型上限。import pretty_midi def extract_melody_events(midi_path): midi pretty_midi.PrettyMIDI(midi_path) notes [] for inst in midi.instruments: if inst.is_drum: continue # 鼓轨不是旋律 for note in inst.notes: notes.append((note.start, note.pitch, note.end - note.start)) notes.sort(keylambda x: x[0]) # 用曲速估计值把秒换算成十六分音符 spb 60.0 / midi.estimate_tempo() # 每拍的秒数 unit spb / 4.0 # 十六分音符的秒长 quantized [] for start, pitch, dur in notes: start_q int(round(start / unit)) dur_q max(1, int(round(dur / unit))) quantized.append((start_q, pitch, dur_q)) return quantized这段代码用estimate_tempo()估计全曲速度再除以 4 得到十六分音符的秒长把浮点时间转成整数网格位置。量化是必须的模型输出的序列是离散位置如果训练数据里时间轴是连续的解码时模型无法决定输出多少个 token 才对应一个四分音符。def align_lyrics_to_notes(lyrics, note_onsets): 把歌词按字拆分硬对齐到音符起始序列上 chars list(lyrics.replace(\n, )) if len(chars) ! len(note_onsets): # 长度不一致时按短的那一方截断并丢弃超长样本 n min(len(chars), len(note_onsets)) return chars[:n], note_onsets[:n] return chars, note_onsets硬对齐是起步做法一个汉字对应一个音符起始点。真实 MIDI 里会有装饰音、连音、长音拖尾导致字数少于音符数或多于音符数所以对齐后必须做清洗——只保留严格等长的样本偏差超过一个十六分音符的样本直接丢弃。别心疼数据量脏对齐样本会让模型学会「错位生成」后期无法弥补。2.5 最小训练循环能跑起来的代码与关键参数模型定义和训练循环分开写便于替换调试。下面是一个标准的 Encoder-Decoder 最小实现import torch import torch.nn as nn class LyricToMelodyModel(nn.Module): def __init__(self, lyric_vocab, note_vocab, d_model256, nhead4, num_layers3): super().__init__() self.embed_lyric nn.Embedding(lyric_vocab, d_model) self.embed_note nn.Embedding(note_vocab, d_model) self.pos nn.Parameter(torch.randn(1, 512, d_model)) enc_layer nn.TransformerEncoderLayer( d_model, nhead, batch_firstTrue) self.encoder nn.TransformerEncoder(enc_layer, num_layers) dec_layer nn.TransformerDecoderLayer( d_model, nhead, batch_firstTrue) self.decoder nn.TransformerDecoder(dec_layer, num_layers) self.fc nn.Linear(d_model, note_vocab) def forward(self, lyric_ids, note_ids): src self.embed_lyric(lyric_ids) self.pos[:, :lyric_ids.shape[1], :] memory self.encoder(src) tgt self.embed_note(note_ids) self.pos[:, :note_ids.shape[1], :] tgt_mask torch.triu( torch.ones(note_ids.shape[1], note_ids.shape[1]), diagonal1).bool() # 因果掩码 out self.decoder(tgt, memory, tgt_masktgt_mask) return self.fc(out)位置编码直接用可学习参数序列长度上限设 512覆盖绝大多数四句歌词加旋律的长度。tgt_mask是因果掩码保证解码时只能看到已生成的音符防止信息泄漏。batch_firstTrue让数据形状是(batch, seq, d_model)调试时更直观。def train_step(lyric_ids, note_ids, model, opt): note_in note_ids[:, :-1] note_out note_ids[:, 1:] logits model(lyric_ids, note_in) loss nn.functional.cross_entropy( logits.reshape(-1, logits.shape[-1]), note_out.reshape(-1)) opt.zero_grad() loss.backward() opt.step() return loss.item()训练参数我的习惯是AdamW 优化器初始学习率 1e-4batch_size 在 160G 显存机器上设 32低显存设 8 并用梯度累积补足标签平滑设为 0.1音乐生成任务上能明显减少「生成音符过于确定」导致的旋律呆板。warmup 步数 4000之后按余弦退火衰减。交叉熵损失直接作用于音符 token 分类模型学会的是「在歌词条件下下一个音符是什么」的概率分布。3. 旋律到伴奏模型先和弦后编曲分段生成才稳3.1 伴奏生成不是创作是在调性约束下的配合旋律到伴奏如果直接训练一个「旋律进、多轨 MIDI 出」的端到端模型大概率翻车。原因在于伴奏的合规性约束比旋律强得多和弦进行必须连贯、低音和旋律要有音程关系、打击乐要踩在节拍网格上。模型自由发挥的空间越大踩雷的概率越高。所以行业里更常见的做法是把它拆成两阶段管线先用一个模型从旋律预测和弦进行再把「旋律和弦」拼成条件序列用第二个模型生成贝斯、琶音和打击乐轨。这样每一步的输出空间都被收窄生成质量在同样参数量下明显更高两个阶段还能分别迭代——和弦错了只换和弦模型伴奏织体不满意只换伴奏模型排查问题也容易。3.2 先从旋律预测和弦一个简单的逐拍分类任务和弦预测本质是逐拍分类每个四分音符位置给一个和弦标签。我用的标签体系是根音12 个半音× 性质大三、小三、属七、小七共 48 类覆盖流行音乐 90% 以上的用法。class ChordPredictor(nn.Module): def __init__(self, note_vocab, d_model128, num_chords48): super().__init__() self.embed nn.Embedding(note_vocab, d_model) encoder_layer nn.TransformerEncoderLayer( d_model, 4, batch_firstTrue) self.encoder nn.TransformerEncoder(encoder_layer, 2) self.fc nn.Linear(d_model, num_chords) def forward(self, melody_ids): # melody_ids: (batch, seq)每个位置是一个音符token src self.embed(melody_ids) out self.encoder(src) return self.fc(out) # (batch, seq, num_chords)输入按十六分音符网格的旋律 token输出在每一个时间步上给一个和弦标签。训练数据从公开 MIDI 数据集里带和弦标注的曲目来如果没有标注可以用自动和弦识别工具先跑一遍再人工抽检。这个模型的参数量很小2 层 Transformer Encoder、d_model 128 就够重点在训练数据的和弦标注质量。3.3 旋律和弦→多轨伴奏怎么组织序列伴奏生成模型的输入要把旋律和和弦拼进同一个序列。我用的序列模板是[BOS] [MEL] 旋律token... [CHORD] 和弦token... [BASS] 低音token... [DRUM] 打击乐token... [EOS]用轨道标记 token 分隔不同声部Decoder 按顺序生成整个序列。生成阶段可以用轨道标记控制想只生成贝斯轨就在[BASS]之后截断想生成完整伴奏就一路生成到[EOS]。序列组织上有个细节和弦 token 不是每个时间步一个而是「一个和弦标记生效若干拍」。我在编码时把一个和弦重复展开到它覆盖的每个十六分音符网格上这样 Decoder 在生成旋律对应位置的伴奏时能直接看到当前拍的和弦不需要额外的对齐逻辑。展开后序列长度等于旋律的网格长度方便后续按位置对应。3.4 训练数据提取从多轨MIDI里拆旋律、和弦、贝斯与鼓def extract_accomp_data(midi_path): midi pretty_midi.PrettyMIDI(midi_path) melody_notes, bass_notes, chord_notes, drum_notes [], [], [], [] for inst in midi.instruments: if inst.is_drum: drum_notes.extend( (n.start, n.pitch, n.end - n.start) for n in inst.notes) continue avg_pitch sum(n.pitch for n in inst.notes) / max(1, len(inst.notes)) if avg_pitch 70: melody_notes.extend( (n.start, n.pitch, n.end - n.start) for n in inst.notes) elif avg_pitch 40: # 中间音域可能是和弦垫底也可能贝斯需要按音域细分 chord_notes.extend( (n.start, n.pitch, n.end - n.start) for n in inst.notes) else: bass_notes.extend( (n.start, n.pitch, n.end - n.start) for n in inst.notes) # 按起始时间排序并量化到同一网格 melody_q quantize(melody_notes, midi.estimate_tempo()) chord_q quantize(chord_notes, midi.estimate_tempo()) bass_q quantize(bass_notes, midi.estimate_tempo()) drum_q quantize(drum_notes, midi.estimate_tempo()) return melody_q, chord_q, bass_q, drum_q按乐器音域粗分轨道是逼不得已的做法——MIDI 文件里的音轨命名五花八门Lead、Vocal、Melody、Guitar混着来按名字匹配不可靠。音域分轨的准确率在七八成左右剩下的靠清洗时检查旋律轨的音符数量不能太少贝斯轨的音符时值不能全是十六分音符鼓轨必须是打击乐通道。抽检比例建议 10%这一步偷懒后续生成的全是怪东西。3.5 训练代码关键段与损失函数设计伴奏生成模型同样用 Encoder-Decoder但输入和输出的 token 表统一为一个词表。训练时把旋律和和弦放在 Encoder 侧伴奏目标放在 Decoder 侧class AccompanimentModel(nn.Module): def __init__(self, vocab_size, d_model256, nhead4, num_layers4): super().__init__() self.embed nn.Embedding(vocab_size, d_model) self.pos nn.Parameter(torch.randn(1, 1024, d_model)) enc_layer nn.TransformerEncoderLayer( d_model, nhead, batch_firstTrue) self.encoder nn.TransformerEncoder(enc_layer, num_layers) dec_layer nn.TransformerDecoderLayer( d_model, nhead, batch_firstTrue) self.decoder nn.TransformerDecoder(dec_layer, num_layers) self.fc nn.Linear(d_model, vocab_size) def forward(self, cond_ids, tgt_ids): src self.embed(cond_ids) self.pos[:, :cond_ids.shape[1], :] memory self.encoder(src) tgt self.embed(tgt_ids) self.pos[:, :tgt_ids.shape[1], :] tgt_mask torch.triu( torch.ones(tgt_ids.shape[1], tgt_ids.shape[1]), diagonal1).bool() out self.decoder(tgt, memory, tgt_masktgt_mask) return self.fc(out)损失函数除了主交叉熵我额外加了轨间损失把序列按轨道标记切段要求每个轨道段内的音符平均音高落在对应音域贝斯在低音区、琶音在中音区。这个约束不需要额外标注直接用轨道标记的位置就能算能有效避免伴奏轨互相串音域。训练参数与歌词模型一致但 batch_size 设小一半因为伴奏序列更长显存占用翻倍。4. 环境搭建教程从显卡驱动到跑通前向传播4.1 先看显卡与驱动nvidia-smi输出怎么读装环境之前先确认硬件否则装完 CUDA 跑不起来才排查浪费一整天。打开终端执行nvidia-smi输出里重点看右上角的CUDA Version这是当前驱动支持的最高 CUDA 版本不是已装的 CUDA Toolkit 版本。PyTorch 的 cu 版本比如 cu118 表示 CUDA 11.8必须不高于这个数字否则会报CUDA driver version is insufficient。比如驱动显示 CUDA 12.2装 cu118、cu121、cu124 都行驱动显示 11.8就只能装 cu118 或更低。如果没有 NVIDIA 显卡也不是不能做——用 CPU 训练小模型完全可以跑通流程数据量大再考虑云主机。只是 Transformer 在 CPU 上训练速度慢 20 倍以上建议先用 500 首歌的小数据集验证链路再上 GPU。4.2 conda环境、Python版本与PyTorch安装conda create -n musicgen python3.10 -y conda activate musicgen pip install torch --index-url https://download.pytorch.org/whl/cu118Python 版本用 3.10兼容性最好。PyTorch 的安装命令建议直接去 PyTorch 官网的 install 页面按你的 CUDA 版本复制对应命令这里给的是 cu118 的示例。装完后立刻验证 GPU 是否可用python -c import torch; print(torch.cuda.is_available())输出True说明 CUDA 版本匹配成功。如果输出False先别急着重装 PyTorch用nvcc -V看本机 CUDA Toolkit 版本很多情况是环境变量LD_LIBRARY_PATH指错了目录。4.3 音乐处理依赖清单与安装pip install pretty_midi numpy tqdm matplotlib pypinyin这四个库是本项目的最小依赖集。pretty_midi负责 MIDI 文件读写和音符提取pypinyin负责中文歌词转拼音numpy做数组操作tqdm显示训练进度matplotlib后面画 loss 曲线和音高分布图用。如果要做数据可视化分析再装pandas、seaborn也不迟。4.4 最小验证一个前向传播1分钟内跑通环境装完别急着开训先跑一个最小前向传播确认模型定义、数据流水线和 MIDI 读写三个环节都正常import torch import pretty_midi # 1. 验证模型前向 from model import LyricToMelodyModel model LyricToMelodyModel(lyric_vocab400, note_vocab770) lyric_ids torch.randint(0, 400, (2, 16)) note_ids torch.randint(0, 770, (2, 32)) with torch.no_grad(): logits model(lyric_ids, note_ids) print(logits shape:, logits.shape) # 2. 验证MIDI写入 pm pretty_midi.PrettyMIDI() inst pretty_midi.Instrument(program0) inst.notes.append(pretty_midi.Note( velocity100, pitch60, start0.0, end1.0)) pm.instruments.append(inst) pm.write(test.mid) print(MIDI write OK)logits的形状是(2, 31, 770)——batch 2、序列 31、词表 770说明模型结构正确。test.mid能写出来说明 pretty_midi 的 IO 链路正常。这一分钟验证能排除 80% 的环境问题之后再进训练环节心态会稳很多。5. 训练避坑5个翻车现场与对应修法5.1 现象loss在1.5附近纹丝不动训练到第 10 个 epochloss 停在 1.5 附近不降了生成结果全是重复音符。原因这是典型的数据量不足导致的欠拟合。歌词到旋律的映射本身是弱对齐关系同样的歌词可以有无数种旋律唱法模型在几千首数据下学不到稳定的统计规律只能退化成「输出训练集里最常见的音高」。解决先别加模型复杂度优先扩数据。最少 5000 首对齐良好的样本再谈训练效果。如果数据扩不动就缩小序列长度——把歌词截断到前 8 个字、旋律截断到前 32 个 token让模型在短序列上先把映射学到手再逐步加长。5.2 现象歌词和旋律错位生成像「数来宝」生成的旋律每个字都踩在一个八分音符上一字一音没有任何连音和休止听起来像念歌词而不是唱歌。原因训练数据清洗太狠把所有装饰音、长音、连音都截掉了模型看到的数据里节奏模式单一学不会真实的歌唱节奏。解决重新检查清洗规则不要按音符个数去对齐而是按「音节中心」对齐——把每个字的中心时间点和音符的起始时间匹配允许一个字对应多个音符装饰音也允许一个音符跨多个字长音拖腔。这种对齐需要半自动标注工具辅助但它是词曲模型效果的分水岭。5.3 现象旋律翻来覆去就三个音生成的旋律音高集中在两三个音上而且全部在 C 大调的主三和弦内听起来非常无聊。原因两个因素叠加。训练时标签平滑没用模型对概率分布过于自信生成时 beam search 的 beam 太小导致每次选中的都是最高概率路径而最高概率路径往往是最保守的音符组合。解决生成阶段改用温度采样temperature 设 1.2 到 1.5输出概率在指数运算时被摊平低概率音高也有机会被选中。训练阶段把标签平滑从 0.1 提到 0.2强迫模型不要对任何单一 token 过于自信。这两个调整立竿见影旋律丰富度肉眼可见提升。5.4 现象伴奏跟主旋律打架全是和弦外音伴奏生成的低音和琶音跟旋律撞在一起产生大量不协和音程听感刺耳。原因伴奏模型直接「旋律进、多轨出」没有显式的和弦约束模型学不到「旋律音要在和弦构成音上」这个规则。解决回到两阶段管线先把和弦预测模型的准确率做上去——和弦预测准确率低于 80% 时伴奏生成质量不会好因为伴奏模型把错误和弦当成了真值条件。另外在数据清洗时检查同一时间点的旋律音和和弦构成音如果冲突超过 20%这首曲子直接丢弃。5.5 现象显存溢出、换台机器结果对不上batch_size 32 一跑就 OOM而群里有人说同样配置能跑自己电脑训练的结果换到服务器推理生成质量明显下滑。原因OOM 大概率是序列长度没对齐同一批数据里有的样本序列 500 长、有的 50 长PyTorch 按最长序列分配显存浪费严重。换机器结果对不上是随机种子和 GPU 算子差异——CUDA 的某些卷积和注意力实现不保证完全一致。解决训练时按序列长度分桶bucket长度相近的样本放同一个 batch显存占用能降一半。复现问题在代码开头固定所有随机种子并用torch.use_deterministic_algorithms(True)开启确定性算法代价是训练速度慢 5% 左右但换机器结果一致。6. 把两个模型串起来生成一首歌的验证路径6.1 先过客观指标音高分布、节拍误差与音符密度训练完先别急着听用三个客观指标筛掉明显不合格的模型。音高分布用 JS 散度Jensen-Shannon Divergence对比生成集和训练集的音符音高直方图低于 0.1 算合格超过 0.3 说明生成音域明显偏离训练分布。节拍误差是生成音符的起始位置到最近网格线的偏移量均值以十六分音符为单位大于 0.3 说明节奏学歪了。音符密度是每个四分音符里的平均音符数密度过高听起来像乱弹过低会空洞无物。这三个指标能过滤掉七八成的烂模型剩下三成必须靠耳朵。指标计算方法合格线音高分布 JS 散度生成集 vs 训练集的音高直方图 0.1节拍误差音符起始位置到量化网格的均方误差 0.3音符密度音符总数 ÷ 总拍数1.0 ~ 3.06.2 耳朵验收生成结果要听的5个检查点客观指标过了戴上耳机听生成结果按这五个顺序检查第一歌词断句和旋律乐句是否对齐乐句结束处有没有呼吸感第二旋律音高是否落在当前和弦的构成音上尤其关注小节强拍位置第三贝斯低音是否稳定低音应该以四分音符为主频繁十六分音符跳进会显得慌张第四打击乐是否踩在正拍上底鼓和大鼓错位基本就废了第五整体有没有乐句起伏连续八小节完全一样的节奏模式说明模型偷懒了。五个检查点能过三个以上这条生成链路就值得继续投入调优。6.3 端到端推理代码歌词进、MIDI出两个模型独立训练推理时串成一条流水线from model import LyricToMelodyModel, AccompanimentModel # 加载各自权重 lyric_model LyricToMelodyModel(lyric_vocab400, note_vocab770) lyric_model.load_state_dict(torch.load(lyric.pt, map_locationcpu)) accomp_model AccompanimentModel(vocab_size1024) accomp_model.load_state_dict(torch.load(accomp.pt, map_locationcpu)) # 歌词转拼音token from pypinyin import lazy_pinyin lyrics 你出现在我诗的每一页 pinyin_tokens [f{p}{tone} for p, tone in ...] # 带声调编码 # 第一步歌词生成旋律 melody_tokens generate_melody(lyric_model, pinyin_tokens, temperature1.2, beam_size3) # 第二步旋律加和弦生成伴奏 cond_tokens [melody_tokens, chord_tokens] # 和弦由ChordPredictor先算 accomp_tokens generate_accompaniment(accomp_model, cond_tokens, temperature1.1) # 写MIDI export_to_midi(melody_tokens, accomp_tokens, output.mid)我现在的习惯是把「歌词→旋律」模型和「旋律→伴奏」模型的推理结果分开保存旋律先导出 MIDI人工听一遍确定没问题再送进伴奏模型。这比全自动端到端生成靠谱得多——两个模型的误差会叠加先人工卡一道关能省大量返工时间。用这套双模型方案在歌词和旋律对齐上下够功夫再配合温度采样和两阶段管线生成结果已经能当编曲 Demo 的底稿。希望帮到你。本文还有配套的精品资源点击获取
