简介面向深度学习音乐生成领域的完整实践资源适用于人工智能算法工程师、音乐技术爱好者和相关专业学生。内容围绕歌词到旋律、旋律到伴奏两条生成链路展开两个模型可分别独立训练与推理并附有环境搭建教程帮助读者快速搭建主流深度学习框架运行环境。压缩包共八十五个文件主要包含Python源码、Notebook、训练样本、MIDI数据、歌词文本、说明文档及Shell运行脚本整体大小约226.19MB目录按训练、推理、评估等模块组织便于按需查阅。目前已获409人学习适合希望快速构建音乐生成原型的开发者。资源不仅提供可运行的代码、样例数据集和模型配置文件还覆盖数据预处理、损失函数设计、训练验证与性能评估等完整流程通过阅读和实践可深入理解LSTM、Transformer等模型在歌词—旋律—伴奏生成中的应用并将其迁移到个人音乐创作或研究项目中。1. 歌词进、旋律出再让旋律长出伴奏在音乐生成方向歌词到旋律、旋律到伴奏这条链路最接近真实的创作流程。这套资源把任务拆成两个独立模型一个以歌词为输入生成旋律一个以旋律为输入生成伴奏。两个模型各自训练不需要端到端调一个巨型网络先解决「歌词变成调子」再解决「调子长出和声与低音」。适合做AI作曲、MIR音乐信息检索研究的人也适合刚入门深度学习想用NLP和序列生成技术实战的开发者。资源里不仅有训练和推理代码还带着环境搭建教程和评估脚本对照着能省下不少排查编译环境、版本冲突的时间。2. 数据与预处理歌词向量化、旋律编码与DTW对齐2.1 歌词如何变成模型能吃的序列歌词是自然语言模型没法直接吃字符。常见做法是先分词再映射成词索引。中文歌词按字切分或按词切分都有人用英文按空格分词即可。然后做embedding可以直接用预训练word2vec也可以让模型自己学嵌入层。我一般会先建vocab表把训练集里出现频率低于阈值的词替换成UNK避免模型遇到没见过的词时输出崩溃。import jieba from collections import Counter def build_vocab(lyrics, max_size5000, min_freq2): counter Counter() for line in lyrics: tokens list(jieba.cut(line)) # 中文按词切分 counter.update(tokens) vocab {PAD: 0, UNK: 1, BOS: 2, EOS: 3} for word, freq in counter.most_common(max_size): if freq min_freq: vocab[word] len(vocab) return vocab这个函数的作用是构建歌词词表。max_size限制词表大小min_freq过滤低频词。注意这里没做特殊符号清洗如果训练数据里有大量表情符号或乱码最好在分词前先处理。BOS和EOS是序列生成模型的开始符和结束符生成旋律时也会用到对应的起始标记确保模型知道从哪里开始、在哪里结束。2.2 旋律编码用miditoolkit把MIDI转成token序列旋律不能直接用MIDI文件喂给模型。资源里带了miditoolkit工具库作用是把MIDI解析成音符列表再转成固定格式的token。常见编码有REMI、MIDI-Like。对旋律生成来说最实用的字段是音高(pitch)、节拍(beat)、持续时间(duration)。建议把音符表示为(pitch, duration, beat)三元组再映射成整数token。import miditoolkit def midi_to_tokens(midi_path): m miditoolkit.MidiFile(midi_path) notes [] for inst in m.instruments: for note in inst.notes: notes.append((note.pitch, note.duration, note.start)) notes.sort(keylambda x: x[2]) # 按起始时间排序 tokens [] for pitch, duration, start in notes: # 简化处理只保留音高和时值 tokens.append(fp{pitch}_d{duration}) return tokens排序这步很重要。MIDI文件里不同音轨的note顺序不一定按时间排好不排序会导致模型学到混乱的时序关系。duration这里用的是tick单位如果要和歌词对齐还需要换算成小节和拍子。资源里的template2melody应该内置了这套解析逻辑你需要保证输入MIDI的格式统一比如统一到四分音符为120 tick。如果混用了不同分辨率的MIDI同一个音长会被编码成不同token模型学到的时值分布会乱。2.3 对齐问题DTW与相似度计算歌词和旋律不是天然一一对齐的一句歌词可能对应多个音符一个音符也可能跨多个字。资源里带了cal_dtw.py就是用来算DTW距离的。DTW能衡量两个序列在时间轴上非线性对齐的相似度比直接算欧氏距离合理得多。训练前可以用它检查数据对齐质量也能在推理后评估生成结果离参考旋律有多远。import numpy as np from dtw import dtw def cal_dtw(seq_a, seq_b): dist lambda x, y: abs(x - y) alignment dtw(seq_a, seq_b, distdist) return alignment.normalizedDistancedist定义为绝对差适合音高序列。如果用时长序列建议用比例差比如abs(x-y)/max(y,1e-6)避免长时值音符产生过大权重。normalizedDistance越小代表两个序列越相似。做训练集清洗时如果一个歌词旋律对的平均DTW距离远超其他样本大概率是数据标注错了建议人工检查。还有cal_similarity.py它通常用来算生成旋律与参考旋律的相似度可能综合了DTW、音高准确率、节奏一致性等多个指标最终得到一个0到1之间的分数越高越好。数据增强方面常见操作有音高平移整体升降调、速度缩放时值整体延长或缩短、随机微小扰动。注意不要改变情感和结构否则模型学到的歌词到旋律的映射会失真。比如流行歌曲整体升4个半音还是同一种情绪但加上不和谐的音程装饰就不行了。我一般只做半音阶内的平移和0.9~1.1倍的速度缩放。3. 歌词到旋律模型从LSTM到Transformer用template2melody3.1 为什么选sequence-to-sequence歌词是变长序列旋律也是变长序列最自然的做法是Encoder-Decoder架构。LSTM、GRU、Transformer都可以用。LSTM的优势是参数量小、在中小数据集上不容易过拟合Transformer需要更多数据但更能捕捉长距离依赖。这个资源把两个模型拆开歌词到旋律这部分可以单独选择Encoder-Decoder LSTM或Transformer。我一般先跑LSTM做baseline数据量够大再切到Transformer。歌词语义和旋律之间的映射并不是简单的一一对应需要模型在Encoder里把整句歌词的语义压成上下文向量再在Decoder里逐步展开成旋律token。如果用朴素Seq2Seq不加注意力长歌词的语义信息很容易在编码末端丢失这也是早期歌词生成旋律效果差的主要原因。3.2 训练脚本与参数学会解读资源里training目录下有lyric2rhythm推断目录下有infer_en.py和infer_zh.py说明它支持中英文歌词。训练时把歌词token序列输入Encoder把旋律token序列作为Decoder目标输出用交叉熵损失。评估时用cal_similarity.py算生成旋律和参考旋律的相似度不能只看loss。Loss降得很好但相似度不高通常意味着模型学会了复制训练集里频率最高的旋律模板没有真正理解歌词。python train_lyric2melody.py \ --data_dir ./data/lyric_melody \ --vocab_size 5000 \ --hidden_size 256 \ --num_layers 2 \ --batch_size 32 \ --epochs 50 \ --device cuda这里hidden_size256是LSTM隐层维度数字越大表示能力越强显存消耗也越大。num_layers2是堆叠两层LSTM加深能提升表达能力但训练初期梯度容易消失建议配合gradient clipping比如把梯度范数限制在5.0。devicecuda开启GPU没有GPU就改成cpu训练会慢一个量级。如果你只有CPU建议把batch_size降到8hidden_size降到128否则一个epoch就够你等半天。训练完成后模型保存一般在checkpoints目录。加载模型做推理时要保证vocab一致不能用不同训练轮的vocab文件。资源里的infer_zh.py和infer_en.py分别处理中英文输入核心流程是预处理歌词 - 转token - 输入Encoder - Decoder自回归生成 - 把token转回MIDI。import torch def generate_melody(model, lyrics_tokens, max_len64): model.eval() with torch.no_grad(): encoder_out model.encode(lyrics_tokens) decoder_input torch.tensor([[2]]) # BOS generated [] for _ in range(max_len): logits model.decode(decoder_input, encoder_out) next_token logits.argmax(dim-1)[0, -1].item() if next_token 3: # EOS break generated.append(next_token) decoder_input torch.cat([decoder_input, torch.tensor([[next_token]])], dim1) return generated这段代码是自回归生成的标准写法。max_len是最大生成长度防止模型陷入死循环生成几千个token。argmax是贪心策略生成的旋律可能缺乏多样性。想要多样一点可以用torch.multinomial按概率采样同时加temperature参数控制峰值。比如logits / 0.8温度越低采样越保守越高越随机。还有一个常见问题生成的旋律和输入歌词完全不相关。原因通常是歌词编码的信息没有有效传递到Decoder。解决办法是启用注意力机制在Decoder每一步都关注Encoder不同位置的输出。资源里的template2melody应该已经实现了这种模板条件机制相当于给Decoder一个结构先验生成的旋律在句式上会更接近真实歌曲。如果你要自己加注意力LSTM里就是常规的BahdanauAttention记住注意力权重也要参与反向传播不要用detach。4. 旋律到伴奏用VAE和自注意力捕获和声结构4.1 任务建模与模型选型旋律是主音伴奏是和声与节奏的填充。把旋律映射到伴奏本质是条件生成。可以用条件VAE把旋律编码成潜在向量再解码出伴奏也可以用Transformer Decoder直接以旋律为条件自回归生成伴奏。VAE的好处是能控制多样性自注意力则能更好地感知旋律中相隔较远的两个音之间的和声关系。比如主旋律在高音区出现一个长音伴奏的低音往往会在根音上持续没有注意力机制很难学到这种跨小节的关系。用VAE做这个任务典型的结构是旋律token序列经过Encoder得到潜在变量zDecoder以z和当前已生成的伴奏token为条件预测下一个伴奏token。训练时用ELBO损失包含重建损失和KL散度。重建损失用交叉熵KL散度用来让潜在空间正则化。python train_melody2accomp.py \ --data_dir ./data/melody_accomp \ --model vae \ --latent_dim 128 \ --hidden_dim 256 \ --epochs 60 \ --batch_size 16latent_dim是潜在向量维度太小会信息瓶颈生成的伴奏和旋律贴合度差太大容易过拟合采样生成时多样性反而下降。hidden_dim是解码器隐层维度通常和潜在维度保持2倍关系。modelvae也可以用transformer替代这时latent_dim参数会失效因为Transformer的条件是直接用Encoder输出的序列向量不再压缩成一个固定维度向量。4.2 独立训练可以分别调参不用互相迁就这个资源最值得借鉴的设计就是两个模型分开训练。精力可以集中在单一任务上数据准备独立GPU预算也独立。当你只有一张卡时可以先训练歌词到旋律跑完再训练旋律到伴奏互不干扰。反过来如果旋律到伴奏的效果不好不用怀疑是歌词到旋律模型拖后腿。但独立训练有一个要注意的点两个模型的token体系不一致。歌词到旋律输出的token要能作为旋律到伴奏输入的token。如果你的两个阶段用了不同的编码方式中间需要加一个转换层。资源里的命名lyric2rhythm和template2melody表明它们有各自的tokenizer如果你要串联使用建议在推理脚本里统一把旋律token转成MIDI音符事件再重新解析成伴奏模型需要的格式。否则会出现音高偏移或时值丢失的问题。训练伴奏生成时条件数据是旋律序列。数据集中每一条需要包含旋律和对应的伴奏MIDI。做数据预处理时我通常会把旋律和伴奏分开导出然后逐小节对齐。如果原曲在某个小节只有旋律而没有伴奏那就直接跳过一个空伴奏序列不要让模型去学着生成静音。伴奏生成的质量评估比旋律更难因为和弦进行是否合理需要主观判断。我一般会看两类指标一是和弦覆盖率即生成的伴奏中是否覆盖了旋律的主要音级二是节拍一致性伴奏的低音是否落在强拍上。资源里的cal_similarity.py如果用来评估伴奏可能只对比旋律轨建议你自己额外写一个和弦匹配度统计脚本。5. 环境搭建与训练避坑PyTorch、GPU与常见翻车现场5.1 环境搭建清单环境搭建是这套资源最容易卡住的地方。不是代码难写而是版本兼容问题会消耗大量时间。资源里提到了用pip或conda安装TensorFlow、Keras或PyTorch实际跑这套代码我建议统一用PyTorch因为miditoolkit和dtw的生态更配PyTorch而且写自回归生成时不用处理TensorFlow的静态图。下面是推荐环境conda create -n melody python3.8 conda activate melody conda install pytorch torchvision torchaudio cudatoolkit11.3 -c pytorch pip install miditoolkit dtw jieba numpy scipyPython 3.8是稳妥选择3.11太新会导致一些旧版PyTorch轮子装不上。cudatoolkit11.3对应PyTorch 1.10左右的版本如果你用PyTorch 2.x可以按官网选择对应CUDA版本。显卡驱动对应CUDA版本别搞错否则显存可以检测到但torch.cuda.is_available()一直返回False。装完后跑这条命令验证python -c import torch; print(torch.__version__, torch.cuda.is_available())5.2 六个高频踩坑记录现象ImportError: cannot import name dtw from dtw原因装错库了PyPI上有个叫dtw的包和原始的dtw-python重名。解决先pip uninstall dtw再pip install dtw-python代码里改成from dtw import dtw。现象miditoolkit读取MIDI时报错KeyError: note_off或Pitch wheel解析失败原因某些DAW导出的MIDI里包含了控制信号比如弯音轮或CC事件旧版miditoolkit不能完整解析。解决建议更新miditoolkit到最新版或者在解析时用m.instruments只取音轨忽略其他信息。如果还不行就用MIDI转换工具先清洗一遍文件。现象训练过程中显存持续增长最后OOM原因Pytorch计算图中保存了所有用于反向传播的中间变量序列长度越长存储越多。另外batch_size设置太大也会直接爆显存。解决增大batch_size之前先看每个batch的最大序列长度。如果是自回归Decoder可以把max_len限制成固定长度或者在反向传播前调用optimizer.zero_grad()确保梯度不会累积。现象训练Loss能降到很低但生成的旋律每个音都一样或者全是固定音高原因这是自回归模型的典型退化。由于训练时用Teacher ForcingDecoder每一步都看到了真实token但是推理时如果上一个预测错一步错误会传播。另外如果训练集里大多数歌词很相近模型倾向于输出低频词对应的旋律模板。解决推理时用Beam Search不只取argmax维护多个候选序列。代码里设置beam_width5最终分数需要按长度归一化否则短序列永远占便宜。现象训练到第20轮左右loss开始震荡验证集损失不断升高原因过拟合学习率过大。小数据集上训练deep模型如果从第20轮到第60轮都只盯着训练loss必然泛化失败。解决把学习率从1e-3降低到5e-4增加早停机制当验证集loss连续3轮不降就停止。保存最佳模型时以验证集loss为准不要保存最后一轮参数。现象运行infer_zh.py时中文歌词输入报错UnicodeDecodeError原因文本文件保存编码不是UTF-8Windows记事本默认ANSI。解决使用utf-8编码保存所有歌词文本代码读取时指定encodingutf-8。5.3 显存不够怎么办如果你只有6GB显存又想训练Transformer模型有几个实际手段。第一减小hidden_size和num_layers先让代码跑通。第二使用gradient accumulation把有效batch size扩大但不增加单次推理的显存。第三开启混合精度训练PyTorch自带torch.cuda.amp.autocast和GradScaler能把显存占用降低一半左右。资源里的训练脚本如果没写AMP你可以自己加上。python train_lyric2melody.py \ --data_dir ./data/lyric_melody \ --hidden_size 128 \ --num_layers 1 \ --batch_size 8 \ --accumulate_steps 4 \ --fp16accumulate_steps4表示每4个小batch做一次参数更新等效batch size是8*432。fp16开启混合精度。这样6GB显存和24GB显存的训练效果可以拉近但注意学习率可能需要同步调大一点因为更新的频率变低了。6. 把模型用起来推理生成、相似度校验与接口化技巧6.1 用infer_en.py和infer_zh.py走通一次推理训练完模型后最快验证效果的方式是跑推理脚本。资源里的infer_zh.py接受中文歌词infer_en.py接受英文歌词。先把输入歌词保存成txt文件然后执行python infer_zh.py \ --ckpt ./checkpoints/lyric2melody_best.pt \ --input_text 夜风轻轻吹 星光落进窗台 \ --output_midi ./generated/output.mid \ --max_len 64这个脚本会加载模型把歌词转成token生成旋律再写回MIDI文件。--max_len控制旋律最大长度比如64个token。第一次跑通后你可以用cal_dtw.py对比生成的output.mid和参考旋律的DTW距离python cal_dtw.py --ref ./data/test/ref.mid --gen ./generated/output.midDTW距离小于0.2说明旋律结构与参考曲目接近但这不代表好听只能说明算法没有跑偏。6.2 写一个最小可用的API接口如果你想让非技术用户也能使用把推理脚本包装成一个HTTP接口是最便捷的。用FastAPI可以快速实现核心逻辑就是加载模型、接收歌词文本、返回MIDI文件流。from fastapi import FastAPI, Request from fastapi.responses import FileResponse import tempfile app FastAPI() model load_checkpoint(checkpoints/lyric2melody_best.pt) app.post(/generate/melody) async def generate(request: Request): data await request.json() lyrics data.get(lyrics) out_path tempfile.mktemp(suffix.mid) generate_melody(model, lyrics, out_path, max_len64) return FileResponse(out_path, media_typeaudio/midi)接口返回的是MIDI文件前端拿到后需要调用音源库播放。如果想直接生成音频还得接一个MIDI合成器比如fluidsynth。资源里没带这部分你可以自己装。回到模型本身我最深的教训是数据质量不解决模型再复杂也是白搭。第一次跑通时我拿了一个没有做任何清洗的数据集直接训练生成结果里大量乱码和跨八度跳进后来把DIW距离值大的样本筛掉效果立刻上一个台阶。从那以后我每次训练前都会强制把数据统计、对齐检查、token化一致性走一遍再启动显卡。希望这两步能帮你在自己的数据上省掉同样的弯路。本文还有配套的精品资源点击获取