歌词转旋律与旋律转伴奏：两个模型分开训的工程实践-北京尧图网络

简介这份资源面向对人工智能音乐生成感兴趣的开发者与学习者围绕歌词生成旋律、旋律生成伴奏两条独立技术路线展开涉及自然语言处理与音乐信息检索的交叉应用。包内共85个文件以22个Python脚本为核心辅以midi、lyric、beat等音乐数据样本以及ipynb实验笔记、sh运行脚本和md说明文档压缩包约226.19MB涵盖歌词到节奏、模板到旋律、推理生成等模块并附有环境搭建教程。已有410人学习下载。读者可据此了解LSTM、Transformer、VAE等模型在音乐序列建模中的落地方式掌握歌词向量化、旋律与伴奏编码、数据增强、损失函数定义及模型保存等完整流程同时获得DTW评估、相似度计算等评测脚本便于对照复现与二次开发。1. 歌词转旋律、旋律转伴奏两个模型分开训为什么比端到端更靠谱很多人第一次做「歌词生成旋律」时第一反应是搞一个端到端大模型输入歌词直接吐出一整首歌。我试过翻车得很彻底歌词和音频的时序对齐极难训练时 loss 看着在降生成出来却是一段没有节拍概念的噪声。后来我把任务拆成两段——歌词到旋律、旋律到伴奏——各自独立训练效果立刻可控了。这个思路的核心在于歌词是离散符号序列旋律是带音高和时值的符号序列伴奏是更密集的多轨符号或音频三者的数据分布差异太大硬塞进一个模型里等于让一个学生同时学三门语言还要求他同声传译。这套方案适合谁适合有基础 Python 和 PyTorch 经验、想做音乐生成但不想从零造轮子的开发者也适合做数字音频处理、想了解符号音乐建模的工程师。你不需要乐理博士级别的知识但至少要能看懂 MIDI 事件和音符的 pitch、duration 概念。两个模型分别训练的好处是歌词到旋律的模型可以专注学语义到音高的映射旋律到伴奏的模型专注学和声与节奏的补全各自的数据集、超参、评估指标都能独立调出问题也容易定位。2. 歌词到旋律从文本编码到音符序列的完整链路2.1 为什么选符号音乐表示而不是直接生成音频直接生成音频波形比如用扩散模型或 WaveNet 类结构对数据和算力要求极高而且歌词和音频的对齐需要额外的强制对齐工具链路一长误差就累积。我一般会选符号音乐表示最常见的是 MIDI 事件序列或 ABC 记谱。MIDI 的好处是工具链成熟pretty_midi、mido 这些库能直接读写音符的 pitch、velocity、start、end 都是结构化数据模型学起来干净。具体做法是把旋律表示成三类 token 的序列音高 token比如 note_60 到 note_84、时值 token比如 dur_1 到 dur_16 表示十六分音符到全音符、以及分隔 token。歌词这边按字或按词切分每个字映射成一个 embedding然后和旋律 token 做序列到序列的训练。常见做法是 encoder 用文本 Transformerdecoder 用自回归生成旋律 token。2.2 数据准备歌词-旋律配对数据的清洗与对齐这一步是最脏最累的。我拿到的原始数据往往是歌词文本和 MIDI 文件分开存放需要自己配对。配对逻辑是按歌曲名或编号匹配然后检查 MIDI 的时长和歌词行数是否大致对应。不对齐的直接丢掉别心疼脏数据进模型就是灾难。import pretty_midi import os def load_melody_events(midi_path): 从 MIDI 提取旋律轨的音符事件返回 (pitch, start, end) 列表 pm pretty_midi.PrettyMIDI(midi_path) # 常见做法是取第一个非鼓轨作为旋律轨 melody_track None for inst in pm.instruments: if not inst.is_drum: melody_track inst break if melody_track is None: return [] events [] for note in melody_track.notes: events.append((note.pitch, note.start, note.end)) # 按开始时间排序保证时序正确 events.sort(keylambda x: x[1]) return events def clean_pair(lyric_lines, melody_events, max_len256): 简单清洗歌词行数和音符数比例过大的丢弃 if len(melody_events) 0 or len(lyric_lines) 0: return None ratio len(melody_events) / len(lyric_lines) # 经验值每行歌词对应 4 到 20 个音符比较合理 if ratio 2 or ratio 30: return None if len(melody_events) max_len: melody_events melody_events[:max_len] return lyric_lines, melody_events逻辑说明load_melody_events从 MIDI 里抽旋律轨取第一个非鼓轨是常见做法因为很多 MIDI 文件第一轨就是主旋律。clean_pair用音符数和歌词行数的比例做粗筛比例太离谱的说明配对错了或者编曲太复杂不适合做旋律生成。参数max_len控制序列长度256 是我在单卡 8G 显存下能跑 batch size 8 的经验值显存大可以往上调。2.3 模型结构文本编码器加旋律解码器的最小实现我用的是标准的 Transformer encoder-decoder文本侧用 4 层 encoder旋律侧用 4 层 decoderhidden size 2568 个 attention head。这个规模在单张消费级显卡上就能训不用分布式。import torch import torch.nn as nn class Lyric2Melody(nn.Module): def __init__(self, lyric_vocab, melody_vocab, d_model256, nhead8, num_enc_layers4, num_dec_layers4): super().__init__() self.lyric_embed nn.Embedding(lyric_vocab, d_model) self.melody_embed nn.Embedding(melody_vocab, d_model) self.pos_enc nn.Embedding(512, d_model) # 位置编码最大长度 512 self.transformer nn.Transformer( d_modeld_model, nheadnhead, num_encoder_layersnum_enc_layers, num_decoder_layersnum_dec_layers, dim_feedforward1024, dropout0.1, batch_firstTrue ) self.out_proj nn.Linear(d_model, melody_vocab) def forward(self, lyric_ids, melody_ids): # lyric_ids: (B, L1), melody_ids: (B, L2) pos_l torch.arange(lyric_ids.size(1), devicelyric_ids.device) pos_m torch.arange(melody_ids.size(1), devicemelody_ids.device) l_emb self.lyric_embed(lyric_ids) self.pos_enc(pos_l) m_emb self.melody_embed(melody_ids) self.pos_enc(pos_m) # 因果 mask防止 decoder 看到未来 token tgt_mask nn.Transformer.generate_square_subsequent_mask( melody_ids.size(1)).to(lyric_ids.device) out self.transformer(l_emb, m_emb, tgt_masktgt_mask) return self.out_proj(out)逻辑说明lyric_embed和melody_embed分别把歌词 token 和旋律 token 映射到同一维度。位置编码用可学习 embedding比正弦编码在短序列上更灵活。generate_square_subsequent_mask生成上三角 mask保证 decoder 自回归生成时只能看已生成的 token。out_proj把 decoder 输出映射回旋律词表大小训练时用 cross entropy loss。参数方面d_model256是平衡表达能力和显存的关键再大就得加显存nhead8是 256 除以 8 等于 32每个 head 维度 32比较标准。dim_feedforward1024是 d_model 的 4 倍也是 Transformer 的常见比例。训练时学习率用 1e-4 加 warmupbatch size 根据显存调到 8 或 16。2.4 训练循环与损失函数的关键参数训练时歌词序列和旋律序列都要做 paddingloss 只计算非 padding 部分。我一般用 AdamWweight decay 0.01学习率 1e-4前 1000 步做线性 warmup。def train_step(model, optimizer, lyric_ids, melody_ids, pad_id0): model.train() # 输入旋律序列去掉最后一个 token目标序列去掉第一个 token inp_melody melody_ids[:, :-1] tgt_melody melody_ids[:, 1:] logits model(lyric_ids, inp_melody) loss_fn nn.CrossEntropyLoss(ignore_indexpad_id) loss loss_fn(logits.reshape(-1, logits.size(-1)), tgt_melody.reshape(-1)) optimizer.zero_grad() loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step() return loss.item()逻辑说明inp_melody和tgt_melody错一位是标准的 teacher forcing 做法。ignore_indexpad_id让 padding 不参与 loss。梯度裁剪到 1.0 是防止 Transformer 训练初期梯度爆炸这个血泪经验来自我早期训崩了好几次。学习率 warmup 在 Transformer 上几乎是必须的不然前几百步 loss 会乱跳。3. 旋律到伴奏和声补全与多轨生成的工程做法3.1 伴奏生成的任务定义从单旋律到多轨符号旋律到伴奏的本质是给定一条主旋律生成和弦、贝斯、鼓等伴奏轨。常见做法有两种一种是生成和弦符号序列再用规则或采样合成伴奏另一种是直接生成多轨 MIDI 事件。我选后者因为端到端生成多轨虽然难但可控性更强而且能直接导出 MIDI 试听。数据表示上把伴奏轨的每个音符表示成 (track_id, pitch, start, duration) 四元组然后 flatten 成 token 序列。track_id 区分和弦、贝斯、鼓pitch 是音高start 和 duration 量化到十六分音符网格。这样一条伴奏就变成一个长 token 序列和旋律生成类似用 Transformer 做自回归。3.2 条件注入怎么让模型“听到”旋律旋律到伴奏的模型不能只学伴奏的分布必须条件在旋律上。我的做法是把旋律 token 序列过一遍 encoder然后把 encoder 输出作为 cross-attention 的 key 和 value伴奏 decoder 做 cross-attend。这样模型在生成每个伴奏 token 时都能参考旋律信息。class Melody2Accompaniment(nn.Module): def __init__(self, melody_vocab, acc_vocab, d_model256, nhead8, num_enc_layers4, num_dec_layers6): super().__init__() self.melody_embed nn.Embedding(melody_vocab, d_model) self.acc_embed nn.Embedding(acc_vocab, d_model) self.pos_enc nn.Embedding(1024, d_model) self.transformer nn.Transformer( d_modeld_model, nheadnhead, num_encoder_layersnum_enc_layers, num_decoder_layersnum_dec_layers, dim_feedforward1024, dropout0.1, batch_firstTrue ) self.out_proj nn.Linear(d_model, acc_vocab) def forward(self, melody_ids, acc_ids): pos_m torch.arange(melody_ids.size(1), devicemelody_ids.device) pos_a torch.arange(acc_ids.size(1), deviceacc_ids.device) m_emb self.melody_embed(melody_ids) self.pos_enc(pos_m) a_emb self.acc_embed(acc_ids) self.pos_enc(pos_a) tgt_mask nn.Transformer.generate_square_subsequent_mask( acc_ids.size(1)).to(melody_ids.device) out self.transformer(m_emb, a_emb, tgt_masktgt_mask) return self.out_proj(out)逻辑说明和歌词到旋律的结构几乎一样区别在于 decoder 层数加到 6因为伴奏序列更长、模式更复杂。pos_enc最大长度开到 1024因为伴奏 token 序列通常比旋律长不少。cross-attention 由nn.Transformer自动处理encoder 输出作为 memory 传给 decoder。参数上num_dec_layers6是我试出来在伴奏生成上比 4 层明显好的值再往上加收益递减还容易过拟合。dropout0.1对小数据集很重要我试过 0.3 直接欠拟合。3.3 多轨 token 的编码与解码轨道、音高、时值的联合建模多轨 token 的设计直接决定生成质量。我的方案是每个音符编码成三个连续 tokentrack token、pitch token、duration token。start 时间不单独编码而是用“时间推进 token”表示每过一个十六分音符就插入一个 time_shift token。这样序列里既有音符信息也有时间信息。def encode_accompaniment(notes, grid0.25): notes: list of (track_id, pitch, start, end) 返回 token 序列grid 是十六分音符时长 tokens [] current_time 0.0 notes_sorted sorted(notes, keylambda x: (x[2], x[0])) for track_id, pitch, start, end in notes_sorted: # 插入时间推进 token while current_time start - 1e-6: tokens.append(TIME_SHIFT_TOKEN) current_time grid dur_steps max(1, int(round((end - start) / grid))) tokens.append(TRACK_OFFSET track_id) tokens.append(PITCH_OFFSET pitch) tokens.append(DUR_OFFSET dur_steps) return tokens逻辑说明TIME_SHIFT_TOKEN表示时间推进一个网格TRACK_OFFSET、PITCH_OFFSET、DUR_OFFSET是不同 token 类型的起始偏移避免词表冲突。dur_steps把音符时长量化成网格数最少 1 个网格。解码时反向操作遇到 track token 就新建音符遇到 time_shift 就推进时间。参数grid0.25对应十六分音符是流行音乐最常用的量化精度。再细到三十二分音符会让序列长度翻倍训练成本上升但听感提升有限。这个取舍我踩过坑一开始用 0.125序列太长导致 batch size 只能开到 2训练慢到怀疑人生。3.4 训练策略教师强制、计划采样与曝光偏差伴奏生成的自回归训练有个经典问题训练时用真实前缀teacher forcing推理时用模型自己生成的前缀两者分布不一致导致曝光偏差。我的做法是前 80% 的 epoch 用 teacher forcing后 20% 逐步混入模型自己的预测。def train_step_with_sampling(model, optimizer, melody_ids, acc_ids, step, total_steps, pad_id0): model.train() inp_acc acc_ids[:, :-1] tgt_acc acc_ids[:, 1:] # 计划采样后期以一定概率替换输入为模型预测 if step 0.8 * total_steps: with torch.no_grad(): logits model(melody_ids, inp_acc) preds logits.argmax(dim-1) # 50% 概率用预测替换真实输入 mask torch.rand_like(inp_acc.float()) 0.5 inp_acc torch.where(mask, preds, inp_acc) logits model(melody_ids, inp_acc) loss_fn nn.CrossEntropyLoss(ignore_indexpad_id) loss loss_fn(logits.reshape(-1, logits.size(-1)), tgt_acc.reshape(-1)) optimizer.zero_grad() loss.backward() torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) optimizer.step() return loss.item()逻辑说明step 0.8 * total_steps之后开始计划采样用模型预测替换部分输入。替换概率 0.5 是经验值太高会导致训练不稳定太低起不到缓解曝光偏差的作用。注意替换时要用torch.no_grad()避免梯度回传到预测路径。4. 环境搭建与两个模型的联合调试4.1 依赖安装与目录结构环境搭建是很多人卡住的第一步。我用的核心依赖就几个PyTorch、pretty_midi、mido、numpy、tqdm。Python 版本 3.9 以上PyTorch 1.13 以上都行。# 创建虚拟环境 python -m venv music_gen_env source music_gen_env/bin/activate # Windows 用 music_gen_env\Scripts\activate # 安装核心依赖 pip install torch torchaudio --index-url https://download.pytorch.org/whl/cu118 pip install pretty_midi mido numpy tqdm # 验证安装 python -c import torch; print(torch.__version__, torch.cuda.is_available())逻辑说明PyTorch 的 CUDA 版本根据你的显卡驱动选cu118 对应 CUDA 11.8比较通用。pretty_midi负责 MIDI 读写mido做底层 MIDI 消息处理两个都装上不冲突。验证那行打印版本和 CUDA 是否可用如果False说明驱动或 CUDA 版本不匹配先解决这个再往下走。目录结构我一般这样组织project/ data/ lyrics/ # 歌词文本 midi/ # 原始 MIDI processed/ # 清洗后的配对数据 models/ lyric2melody.py melody2accomp.py train_lyric2melody.py train_melody2accomp.py inference.py checkpoints/4.2 两个模型的训练顺序与数据依赖先训歌词到旋律再训旋律到伴奏。原因很简单旋律到伴奏的训练数据需要旋律而歌词到旋律的模型可以生成旋律虽然训练时用的是真实旋律但调试阶段可以用第一个模型的输出喂给第二个模型验证整条链路。训练命令# 训练歌词到旋律 python train_lyric2melody.py \ --data_dir data/processed \ --batch_size 16 \ --lr 1e-4 \ --epochs 50 \ --d_model 256 \ --save_dir checkpoints/lyric2melody # 训练旋律到伴奏 python train_melody2accomp.py \ --data_dir data/processed \ --batch_size 8 \ --lr 1e-4 \ --epochs 80 \ --d_model 256 \ --save_dir checkpoints/melody2accomp逻辑说明歌词到旋律的 batch size 可以大一点因为序列短旋律到伴奏序列长batch size 降到 8。epochs 方面歌词到旋律 50 轮通常够收敛伴奏 80 轮因为任务更难。学习率都用 1e-4配合 warmup。4.3 推理链路从一行歌词到一段伴奏推理时先加载两个模型歌词过第一个模型生成旋律 token解码成 MIDI 事件再编码成旋律 token 喂给第二个模型生成伴奏 token最后合并导出 MIDI。def generate_song(lyric_text, model_l2m, model_m2a, lyric_vocab, melody_vocab, acc_vocab, max_len200): # 歌词编码 lyric_ids torch.tensor([lyric_vocab.get(c, 0) for c in lyric_text]).unsqueeze(0) # 自回归生成旋律 melody_ids [melody_vocab[BOS]] for _ in range(max_len): inp torch.tensor([melody_ids]) logits model_l2m(lyric_ids, inp) next_id logits[0, -1].argmax().item() if next_id melody_vocab[EOS]: break melody_ids.append(next_id) # 旋律 token 转伴奏 token melody_tensor torch.tensor([melody_ids]) acc_ids [acc_vocab[BOS]] for _ in range(max_len * 2): inp torch.tensor([acc_ids]) logits model_m2a(melody_tensor, inp) next_id logits[0, -1].argmax().item() if next_id acc_vocab[EOS]: break acc_ids.append(next_id) return melody_ids, acc_ids逻辑说明歌词逐字映射成 id未知字用 0 代替。旋律生成用贪心解码每步取 argmax遇到 EOS 停止。伴奏生成同理但最大长度给旋律的两倍因为伴奏 token 更密。实际用的时候可以把贪心换成 top-k 采样k10 左右生成结果更多样。5. 避坑与排查训练不收敛、生成难听、显存爆炸的常见原因5.1 损失降不下去生成全是同一个音现象训练 loss 降到某个值就不动了推理时不管输入什么歌词生成的旋律都是同一个音高反复。原因最常见的是词表设计有问题比如 pitch token 和 duration token 没有分开模型学不到区分。另一个可能是学习率太大模型直接塌缩到高频 token。解决检查词表确保每类 token 有独立区间。把学习率降到 1e-5 试几百步看 loss 是否重新下降。如果还不行检查数据里是不是某类 token 占比超过 80%做一下重采样。5.2 伴奏和旋律打架和声完全不对现象生成的伴奏单独听还行和旋律一起放就刺耳和弦跟旋律音冲突。原因模型没有学到和声约束cross-attention 可能没起作用。也可能是训练数据里旋律和伴奏的配对本身就不对比如旋律轨取错了。解决先验证数据配对随机抽几条把旋律和伴奏一起导出 MIDI 听。如果数据没问题检查 cross-attention 的 mask 是不是把 encoder 输出屏蔽了。我遇到过nn.Transformer的src_mask默认是 None但某些版本会误传导致 cross-attention 失效。显式传src_maskNone确认。5.3 显存爆炸batch size 只能开到 1现象训练时 CUDA out of memory降到 batch size 1 还是爆。原因序列太长或者模型参数量太大。伴奏 token 序列动辄上千attention 的显存是 O(n^2)。解决先量化序列长度把超过 512 的截断或分段。模型层面可以把d_model从 256 降到 128num_dec_layers从 6 降到 4。还可以用 gradient checkpointing用时间换显存。我一般先降序列长度因为这是最有效的。5.4 推理时生成到一半就停了现象生成的旋律或伴奏只有几秒明显没生成完就遇到 EOS。原因训练时 EOS token 占比太高模型过早学会输出 EOS。也可能是 max_len 设太小。解决统计训练数据里 EOS 的比例如果超过 10%说明序列普遍偏短检查数据清洗是不是截断太狠。推理时把 max_len 调大同时用 top-k 采样代替贪心避免模型过早自信地选 EOS。5.5 两个模型单独听都行串起来就崩现象歌词到旋律的模型输出正常旋律到伴奏的模型单独用真实旋律也正常但把第一个模型的输出喂给第二个就崩。原因第一个模型生成的旋律 token 分布和真实旋律有偏差第二个模型没见过这种分布属于分布外输入。解决训练第二个模型时做数据增强把第一个模型生成的旋律按一定比例混入训练集。比例从 10% 开始逐步加到 30%。这个做法本质上是让第二个模型对第一个模型的误差鲁棒。我试过不加增强串起来崩的概率超过一半加了之后明显改善。6. 进阶技巧用温度采样和和弦约束把生成质量再拉一档贪心解码的问题是生成结果太“安全”总是选概率最高的 token导致旋律平淡、伴奏单调。我一般会用温度采样加 top-k 过滤。温度 T 控制分布的平滑程度T 大于 1 更随机小于 1 更保守。旋律生成我常用 T0.9伴奏用 T1.0因为伴奏需要更多变化。def sample_with_temperature(logits, temperature1.0, top_k10): 对 logits 做温度缩放和 top-k 过滤后采样 logits logits / temperature # top-k 过滤 if top_k 0: values, indices torch.topk(logits, top_k) filtered torch.full_like(logits, float(-inf)) filtered.scatter_(-1, indices, values) logits filtered probs torch.softmax(logits, dim-1) return torch.multinomial(probs, num_samples1).item()逻辑说明logits / temperature做温度缩放topk取概率最高的 k 个其余置为负无穷再 softmax 采样。top_k10是经验值太小多样性不够太大容易出噪声。温度参数建议在验证集上试几组我一般试 0.7、0.9、1.0、1.2 四个值选听感最好的。另一个进阶技巧是加和弦约束。伴奏生成时如果当前时间步的和弦是 C 大调就把不属于 C 大调音阶的 pitch token 概率压低。做法是在采样前对 logits 做 mask把非法 pitch 的 logit 减去一个大的常数。def apply_chord_constraint(logits, current_chord_tones, pitch_offset, pitch_range): 把不在和弦内的 pitch token logit 压低 for p in range(pitch_range): if p not in current_chord_tones: logits[pitch_offset p] - 10.0 return logits逻辑说明current_chord_tones是当前和弦包含的音高集合比如 C 大调和弦是 [60, 64, 67]。不在集合里的 pitch token logit 减 10相当于概率压到接近零但不完全禁止保留一点灵活性。这个约束对和声听感提升很明显但别减太狠减 10 是我试出来比较平衡的值减 20 以上会显得死板。最后说个我自己的习惯每次训完模型先不急着听生成结果而是把生成的 MIDI 用钢琴卷帘可视化出来看音高分布和节奏密度。如果音高集中在两三个音上或者节奏全是等分音符说明模型没学好调参比听音频更快定位问题。这个习惯帮我省了很多来回试听的时间。希望帮到你。本文还有配套的精品资源点击获取

歌词转旋律与旋律转伴奏：两个模型分开训的工程实践

相关推荐

ThinkPHP教学系统部署避坑指南：从500错误到稳定200

Docker 安装 Jenkins 实现 Spring Boot 持续集成与手动部署实战

C语言网页爬虫实战：从socket到Windows独立exe

更多资讯

Java面试实录：从JVM到MySQL，那些让面试官崩溃的基础错误

AnyPS5：PS5跨平台兼容性问题的技术本质与工程应对

一文掌握 TypeScript 泛型：约束、推断、条件类型与项目实战封装

群同构同态定理详解：从正规子群到商群的一站式攻克

监控数据丢失？OpenFalcon Transfer 多重备份方案与实战

Unity TMP中文字体Asset生成指南：字符集搭建与参数配置

今日更新

声子晶体仿真：三角晶格与六角晶格的能带计算实战

度假村安保定岗定编：岗位梳理、编制测算与排班设计

COMSOL等离子体模块实战：氩气双层DBD仿真建模全解析

本周精选

交通拥堵预测毕设：基于Python+LSTM的车辆流量预测系统全流程解析

MATLAB/Simulink搭建10机39节点电力系统暂态稳定仿真实战

无人机航拍三维重建全流程：从SfM到网格生成的避坑指南

本月热门

我发现了一个新思路：用 Remotion + Claude Code 像写代码一样自动化生成短视频

Windows下 Codex 中 Chrome 和 Computer Use 插件不可用问题排查及解决参考方式：TaoToken 统一 Key 配置与验证

2026 大模型集体涨价：用 Python 做企业 Token 成本测算与选型避坑（附配置）

读完文章，想聊聊您的网站？