LSTM音乐生成实战：从MIDI预处理到模型调参的完整指南

简介这是一份基于LSTM的Python音乐生成器完整项目资源面向对深度学习、音乐生成感兴趣的开发者与入门学习者。项目围绕MIDI音乐序列建模展开包含数据预处理、模型构建、训练与生成环节能够帮助用户理解LSTM如何捕捉旋律中的时序依赖并动手生成风格化的音乐片段。资源包共56个文件以46个mid数据集文件为主辅以4个py脚本用于训练、生成与网络定义5张png图直观展示乐理知识、处理流程及神经网络结构另有1个md说明文档整体仅723KB轻量易用。已有181人学习浏览适合在Python环境中配合TensorFlow/Keras进行实践。通过这份资源读者可以获得完整的音乐生成流程从语料预处理、音符序列化到模型训练与音乐片段输出同时还能借鉴项目中的目录组织方式与可视化分析思路作为自己开展AI音乐创作或深入学习循环神经网络的入门参考。1. 用 LSTM 续写旋律这个 ai_music 项目到底能做什么训练好的 LSTM 模型拿到一段它从没听过的音符开头能把旋律自己续完续出来的乐句还有模有样——这就是 ai_music 项目最直观的效果。它是一个纯 Python 实现的音乐生成器把 45 个 MIDI 文件解析成音符序列喂给长短期记忆网络 LSTM 去学习旋律里的遣词造句训练结束后用 generate.py 就能生成新的 output.mid。对从业者来说这个项目的价值不只是能生成音乐更是一个完整的序列建模 demo数据预处理、词表构建、滑窗切样本、LSTM 训练、采样生成每一步都能直接抄到自己接手的时序项目里。适合三类人想入门 LSTM 但缺一个真实数据集的人、需要给游戏或短视频批量配乐的人、以及想看看深度学习在非文本序列上怎么落地的人。2. 数据预处理把 MIDI 文件拆成 LSTM 认识的音符序列2.1 MIDI 是符号不是音频为什么训练素材必须用 mid刚开始接触这个项目的人最容易问一句为什么不直接用 mp3 或者 wav 训练答案在于数据形态。音频文件是波形采样每秒几万个采样点模型要先去学频谱、音高这些特征复杂度直接把小项目拖垮。而 MIDI 文件记录的是一系列事件什么时间、按下哪个音高、持续多久、力度多大本质上就是符号序列。一个音符用音高 时长两个数字就能表示这和 LSTM 擅长处理的时间序列天然匹配。这种设计在项目里体现得很明显。midi 文件夹下躺着 45 个 .mid 文件它们就是全部训练语料。你打开项目自带的乐理知识.png把音高、时值、调号这几项过一遍再看 MIDI 文件立刻就能对应上每条 mid 就是一首曲子被符号化之后的乐谱。这种规模的数据对深度学习来说不算多但对付旋律生成绰绰有余前提是预处理别浪费数据。2.2 用 music21 抽取音符与时长核心解析逻辑解析 MIDI 我一般用 music21 这个库它是学术圈做音乐信息检索的事实标准。项目里 utils.py 干的活基本就是下面这段逻辑遍历 MIDI 文件里的所有事件遇到单音就提取音高和时长遇到和弦就取根音最后拼成一个字符串列表。注意这里的编码方式——把音高和时长拼成一个字符串这是我实践下来最稳的做法。from music21 import converter, note, chord, instrument import glob def extract_notes(midi_path): midi converter.parse(midi_path) # 常见做法先按乐器分组取第一个乐器轨通常是主旋律 parts instrument.partitionByInstrument(midi) notes_to_parse parts.parts[0].recurse() if parts else midi.recurse() notes [] for element in notes_to_parse: if isinstance(element, note.Note): # 编码成 音高_时长 字符串便于后续建立词表 notes.append(f{element.pitch.midi}_{element.duration.quarterLength}) elif isinstance(element, chord.Chord): # 和弦取根音避免词表爆炸 notes.append(f{element.pitches[0].midi}_{element.duration.quarterLength}) return notes melody [] for midi_file in glob.glob(midi/*.mid): melody.extend(extract_notes(midi_file)) print(f共解析出 {len(melody)} 个音符事件)这段逻辑的重点在编码方式。把pitch.midi和quarterLength用下划线拼成字符串而不是拆成两个序列分别建模是因为音高和时长在音乐里是联合分布的某个音高后面跟什么时长、某个节奏型里常出现哪些音这是一体的。拆开建模等于强行割裂了旋律的两个维度生成时还得手动对齐很容易出现音高合理但节奏错乱的结果。和弦取根音则是为了控制词表规模一个三和弦拆成三个音会让序列长度暴增而根音已经能保留和声走向的信息对小项目来说这个取舍是划算的。2.3 量化与词表把音符字符串变成整数 ID拿到原始音符字符串还不够quarterLength在 MIDI 里经常是 0.75、1.5 这样的小数直接进词表会把词表撑得很大而且让模型去学0.75 和 0.5 的区别没有意义。我一般会在解析之后做一道量化把时长归一到 0.25、0.5、1.0、2.0 这几个档位。这是预处理里最容易翻车又被忽略的细节——不量化后面生成出来的节奏会极其诡异。def quantize_duration(dur): # 常见做法就近归一到 0.25 的整数倍 return max(0.25, round(dur * 4) / 4) # 对 melody 里每个 token 做量化重写 melody [f{token.split(_)[0]}_{quantize_duration(float(token.split(_)[1]))} for token in melody] unique_notes sorted(set(melody)) note_to_int {note: idx for idx, note in enumerate(unique_notes)} int_to_note {idx: note for idx, note in enumerate(unique_notes)} vocab_size len(unique_notes) print(f词表大小: {vocab_size})提示量化档位不是固定的。要生成更细碎的节奏可以保留 0.125要更规整的旋律就只用 0.5 和 1.0。先看看你的数据集里时长的实际分布再定。词表构建和 NLP 里的做法完全一致每个音符字符串映射成一个整数 ID。项目里的 notesinvert.png 展示的就是这一层转换——左边是音符序列右边是映射后的整数索引方便你核对映射关系有没有错位。到这里原始音乐数据已经变成了和文本语料同构的整数序列接下来就可以用标准的滑窗方式切训练样本了。2.4 滑动窗口切样本让模型学会根据前面猜后面音乐生成任务本质上是一个自监督学习给定前面 N 个音符预测第 N1 个。所以训练样本的构造方式和文本语言模型一模一样用固定长度的滑窗在音符序列上滑动窗口内的前段是输入 X窗口结尾的下一个音符是标签 y。项目里看到的那一堆 1.mid 到 45.mid解析完连成一条长序列之后就是靠这个方式变成几十万条训练样本的。import numpy as np SEQUENCE_LEN 64 # 用前 64 个音符预测下一个覆盖约 4~8 个小节 step 1 # 步长为 1充分利用每条数据 X, y [], [] for i in range(len(melody) - SEQUENCE_LEN): seq_in melody[i : i SEQUENCE_LEN] seq_out melody[i SEQUENCE_LEN] X.append([note_to_int[ch] for ch in seq_in]) y.append(note_to_int[seq_out]) X np.array(X) y np.array(y) print(fX shape: {X.shape}, y shape: {y.shape})序列长度 64 是我在这个项目里常用的起步值相当于让模型每次参考 64 个音符大约 16 拍、4 个小节的上下文来预测下一个音。这个值直接决定了模型能捕捉多长的乐句结构设成 16 模型只能学到短促的动机设成 256 模型可能记住了训练集的整段旋律导致过拟合。步长取 1 是最朴素也最有效的做法虽然会产生大量重叠样本但对小数据集来说每个音符都被充分利用了比跳着切划算得多。3. 模型构建Embedding LSTM Dense 的堆叠里藏着哪些参数3.1 为什么是 LSTM普通 RNN 记不住十个小节前的旋律如果只用普通循环神经网络处理音符序列遇到的问题是梯度消失反向传播时误差信号每经过一个时间步就衰减一次传不到十步之前模型实际上只能学到最近两三个音符的局部关联。但旋律的规律往往横跨更长的距离——主题动机可能在小节 A 出现、隔了八个小节在变奏里再出现这个跨度不是普通 RNN 能扛住的。LSTM 的解决方案是引入记忆单元和三个门控遗忘门决定要不要丢掉记忆单元里的旧信息输入门决定当前音符有多少写入记忆输出门决定记忆里的内容有多少输出到当前隐藏状态。这个结构让模型可以在几十个时间步里保持对某个动机的记忆需要的时候再把它调出来用。音乐生成、股票序列预测、语音识别这些任务本质上都是要在长序列里找到这种跨时间的依赖这也是 LSTM 在过去十年统治序列建模的原因。3.2 网络结构逐层拆解从音符 ID 到下一个音符的概率分布项目的 network.py 里定义的模型结构上就是经典的字符级语言模型改了个输入维度。我把常用的实现写出来每一层的 shape 变化都标清楚from tensorflow.keras.models import Sequential from tensorflow.keras.layers import Embedding, LSTM, Dense, Dropout model Sequential() # 输入: (batch_size, 64) 的整数序列每个整数是音符 ID model.add(Embedding(vocab_size, 256, input_lengthSEQUENCE_LEN)) # 输出 shape: (batch_size, 64, 256)每个音符被映射成 256 维稠密向量 model.add(LSTM(512, return_sequencesTrue)) # 第一层 LSTM 保留所有时间步的输出给第二层使用 model.add(Dropout(0.3)) model.add(LSTM(512)) # 第二层 LSTM 只保留最后一个时间步的输出 model.add(Dropout(0.3)) model.add(Dense(vocab_size, activationsoftmax)) # 输出: (batch_size, vocab_size)每个音符作为下一个音的概率 model.compile(losscategorical_crossentropy, optimizeradam) model.summary()第一层 Embedding 很关键每个音符 ID 查表得到一个 256 维的稠密向量向量里编码了这个音高在旋律中通常和哪些音伴随出现的语义信息。为什么不直接用 one-hot 向量因为词表如果有几百个音符one-hot 的维度就是几百且每个向量之间是正交的学不到音符之间的相似性Embedding 把高维稀疏向量压缩到低维稠密空间让模型自动发现音高相近的音符在向量空间里也相近。两层 LSTM 堆叠的意图是第一层捕捉短促的旋律动机第二层在第一层的输出之上捕捉更长跨度的乐句结构。最后接一个带 softmax 的 Dense 层把 LSTM 的输出压成词表大小的概率分布哪个音符的概率高就是模型认为最可能接在后面的音。3.3 超参数怎么定先跑通再调优这些参数有规律很多人在这一步容易犯选择困难症其实 LSTM 音乐生成器的超参数有比较成熟的起始点。下面这张表是我在这个项目规模几万到几十万训练样本下常用的配置新手可以直接照抄跑通之后再根据自己的数据和生成效果调整参数建议初始值调大时的影响调小时的影响SEQUENCE_LEN64学到更长乐句样本变少易过拟合样本增多但只能学到短动机Embedding 维度256表示能力更强显存和参数量上升可能欠拟合学不到音符间相似关系LSTM 单元数512拟合能力更强训练变慢需加大 Dropout模型容量不足生成旋律呆板Dropout0.3正则化更强但过高会导致欠拟合容易过拟合训练集Batch Size128训练更稳定显存占用上升更新频繁收敛波动大学习率0.001Adam 默认收敛快但不稳loss 可能震荡收敛慢但更稳定提示如果你的机器显存不够 8G把 LSTM 单元数降到 256Embedding 降到 128序列长度降到 32仍然能跑出效果只是生成的旋律会简单一些。先跑通流程比追求指标重要。这几组参数之间是联动的。数据量不大时堆三层 LSTM 或者把单元数加到 1024很快会过拟合Dropout 加到 0.5 以上又会让模型学不动。我自己的习惯是第一版完全照这个表来跑完 100 个 epoch 看生成结果再从序列长度和单元数这两个维度去调。一次只改一个参数否则你根本分不清是哪个改动改善了效果。4. 训练与避坑从 loss 不降到只会重复一个音4.1 train.py 的训练流程与权重保存训练这一步本身不复杂项目里的 train.py 核心就是三件事把标签 y 转成 one-hot 编码、配置模型保存的回调、调用 fit 开始训练。标签 y 之前是整数索引而模型输出是 vocab_size 维的概率分布两者的维度对不上所以必须用to_categorical把整数转成独热向量才能计算交叉熵损失。from tensorflow.keras.utils import to_categorical from tensorflow.keras.callbacks import ModelCheckpoint # 标签转 one-hotshape 从 (N,) 变成 (N, vocab_size) y_onehot to_categorical(y, num_classesvocab_size) # 只保存验证集 loss 最低的那次权重防止最后几个 epoch 过拟合把权重覆盖掉 checkpoint ModelCheckpoint(weights.hdf5, monitorval_loss, save_best_onlyTrue, verbose1) history model.fit( X, y_onehot, batch_size128, epochs200, validation_split0.1, callbacks[checkpoint] )save_best_onlyTrue这个参数值得多说一句。如果不设模型每跑完一个 epoch 就把当前权重覆盖到同一个文件一旦你在第 180 个 epoch 过拟合了前面的好权重就没了这等于没有后悔药。设成按val_loss保存模型会在验证集 loss 最低的那个 epoch 把权重单独留下来。训练集 loss 会一路下降验证集 loss 通常在某个点触底反弹那个触底点才是泛化最好的模型。验证集占 10% 是个合理比例45 个 MIDI 文件里有 4~5 首曲子完全不参与训练专门用来观察模型有没有过拟合。4.2 踩坑一loss 卡在固定值不动现象训练了二三十个 epochloss 稳定在某个数值附近几乎不下降生成出来的音乐完全是噪音。原因这个固定值十有八九是log(vocab_size)。比如词表有 300 个音符交叉熵损失初始值大概在 5.7 左右如果 loss 就卡在 5.7 上下震说明模型输出的是均匀分布——它根本什么都没学到。最常见的原因是标签没做 one-hot 编码就丢进了categorical_crossentropyKeras 会报错或者静默出错另一个常见原因是序列样本没做 shuffle同一个 MIDI 文件的样本连在一起模型在一个 batch 里只看到同一首歌的片段梯度方向来回打架。解决先检查y_onehot.shape是不是(样本数, vocab_size)确认标签维度没问题再看model.fit有没有显式传shuffleTrue默认是 True但如果你自定义了数据生成器就容易漏。最后把学习率从默认的 0.001 临时调到 0.005 跑 20 个 epoch如果 loss 开始动了说明是学习率太低加初始化不好跑通后记得调回来。4.3 踩坑二训练集 acc 很高生成却只会重复同一个音符现象模型在训练集上的准确率到了百分之八九十但用它生成旋律时从某个音符开始就无限循环比如一直输出 60_0.5 这个 token或者几个音符来回跳。原因这几乎是音乐生成项目的头号翻车现场。MIDI 文件里音符的频率极不均衡长音、常用根音出现次数远多于装饰音。模型学到的最优策略是把所有概率都压在出现频率最高的那个音符上这样训练 loss 也能降得很低但生成时毫无音乐性。如果生成代码里用的是np.argmax直接取概率最大的音符那模型每次都会选最高频的音符于是输出陷死在同一个音上。解决生成时永远不要用 argmax改用带温度系数的随机采样。温度大于 1 会平坦化概率分布给低频音符更多被选中的机会温度小于 1 会让分布更尖锐输出更保守。先用 temperature1.0 跑一遍如果还是重复把温度调到 1.2 甚至 1.5。再不行检查数据预处理里是不是某个音符占了大几十个百分点想粗暴点就直接把这种极端高频的音符从词表里去掉。4.4 踩坑三全部 MIDI 混着训练生成风格四不像现象每首 MIDI 单独听都有模有样但混合训练后生成的旋律一会儿像流行歌一会儿像练习曲乐句之间衔接生硬甚至出现极其刺耳的音程跳进。原因这 45 个 MIDI 文件不保证在同一个调上有的 C 大调、有的 G 大调、有的可能是小调。LSTM 学的是音符序列的统计规律当训练数据里混着不同调性的曲子时模型被迫学习多个调的混合分布结果就是哪个调都不像。我见过有人以为模型会自己学会移调实际上对小数据集来说它没那么聪明。解决在预处理阶段把所有 MIDI 统一移调到同一个调通常是 C 大调或 A 小调。music21 里可以用midi.analyze(key)拿到原曲调号然后算偏移量整体 transpose。这样模型只需要学一个调性下的旋律规律生成质量提升非常明显。代价是损失了多调性的多样性但这是值得的——先生成出像样的旋律再考虑用后期处理做移调变化。5. 音乐生成温度采样与 output.mid 的诞生5.1 生成逻辑从一段 seed 开始往后猜下一个音训练完成后generate.py 做的事情本质上是把训练时的预测过程循环执行 N 次拿一段起始音符序列seed喂给模型得到一个概率分布按这个分布采样出下一个音符把它追加到序列末尾同时丢掉序列最前面的一个音符保持输入长度始终是 64然后继续预测。这个滚雪球式的自回归生成是当前所有生成式模型的通用玩法。# 从训练数据里随机截取一段作为 seed保证起始音符是合法的 start_idx np.random.randint(0, len(melody) - SEQUENCE_LEN) seed_notes melody[start_idx : start_idx SEQUENCE_LEN]seed 的选择对生成结果影响巨大。固定同一个 seed同一份权重生成的结果完全一致方便你对比调参前后的差异每次随机选 seed生成的旋律每次都不一样。我一般调试阶段固定 seed确定参数满意了再放开随机。还有一种常见做法是用一个固定的动机作为种子比如贝多芬第五交响曲的噔噔噔噔——让模型在这个动机上继续发展生成的乐句会带着这个动机的痕迹。5.2 温度采样在确定与随机之间找平衡生成音乐和做分类预测最大的区别在于分类要取概率最大的类别而生成需要在稳定和惊喜之间找平衡。如果每次都取最大概率的音符旋律很快就会陷入重复如果完全随机采样那生成的就是噪音。温度采样就是调节这个平衡的旋钮——先对概率分布取对数除以温度再重新归一化成概率分布。def sample_with_temperature(preds, temperature1.0): preds np.asarray(preds).astype(float64) # 加一个极小值防止 log(0) preds np.log(preds 1e-8) / temperature exp_preds np.exp(preds) preds exp_preds / np.sum(exp_preds) # 按概率分布做多项式采样而不是取 argmax probas np.random.multinomial(1, preds, 1) return np.argmax(probas) def generate_notes(model, seed_notes, num_notes200, temperature1.0): generated list(seed_notes) for _ in range(num_notes): # 取最后 64 个音符作为输入 seq [note_to_int[n] for n in generated[-SEQUENCE_LEN:]] pred model.predict(np.array([seq]), verbose0)[0] next_idx sample_with_temperature(pred, temperature) generated.append(int_to_note[next_idx]) return generatedtemperature 的作用可以这样理解等于 1.0 时就是模型自己学到的原始分布小于 1.0 时分布被压扁高概率音符更高低概率音符几乎消失输出稳定但可能无聊大于 1.0 时分布被抹平低频音符被采到的机会增大输出更有变化但更容易跑调。音乐生成里一个靠谱的调节方式是先把温度设成 0.8 听一版再设成 1.2 听一版两个版本都太极端就取中间值。这部分我个人觉得多少带点玄学但温度区间 0.7~1.2 是绝大多数项目的有效范围。5.3 把生成结果写回 output.mid采样得到的是像60_1.0、64_0.5这样的字符串列表写回 MIDI 就是把字符串拆开装回 music21 的 Note 对象再写文件。项目里的 output.mid 就是这一步的产物。from music21 import stream, note midi_stream stream.Stream() for token in generated_notes: pitch_str, dur_str token.split(_) new_note note.Note(int(pitch_str)) new_note.quarterLength float(dur_str) midi_stream.append(new_note) midi_stream.write(midi, fpoutput.mid) print(已生成 output.mid)写完文件之后一定要做两件事一是拿播放器听一遍这一步没有任何指标能替代二是用 music21 重新解析一遍生成的 output.mid确认没有非法音符。我踩过的一个坑是量化后的时长如果是0.25写入 MIDI 的quarterLength必须是浮点数有人从字符串解析时用了int()结果所有音符时长都变成 0生成的旋律变成一坨密集噪音。另外输出的 MIDI 只有一条旋律轨没有伴奏听起来会偏单薄这是所有单轨 LSTM 音乐生成器的通病。6. 进阶调参从能跑通到能听要过的三关6.1 序列长度与数据增强少样本项目的两个杠杆第一关是序列长度。64 起步没问题但如果想生成更有结构的旋律可以试 128。代价是训练样本数量减少总音符数减 128模型容量需求上升。我常用的折中方案是把序列长度从 64 调到 96样本数量损失不大乐句跨度却能覆盖 6 个小节左右这对常见流行旋律的乐句长度刚好够用。第二关是数据增强。45 个 MIDI 实在太少常见做法是把每个文件整体移调——转成 C 大调/A 小调之后再分别上移和下移 2 到 4 个半音。45 个文件瞬间变成两百多个样本量翻几倍过拟合问题明显缓解生成旋律的音域也更开阔。这个操作在预处理阶段做用 music21 的transpose接口几行代码的事。6.2 生成质量的客观验证别只靠耳朵耳朵是最终裁判没错但在调参数的过程中可以加一个客观指标辅助判断统计生成序列里唯一音符的比例以及音高间隔的分布跟训练集做个对比。如果训练集的唯一音符占比是 12%生成结果却只有 4%说明温度太低或模型过拟合如果生成结果的音高跳进平均超过了十度说明温度太高、模型在瞎猜。这个指标不能保证旋律好听但能快速暴露模型是否学到了训练集的统计分布——就像股票预测模型先看残差分布正不正态一样属于验证环节的地基。把这套流程跑熟了之后换个数据集做时间序列预测你会发现除了把音符换成数值、把词表换成归一化窗口整体架构几乎不用动。我后来的习惯是每改一组参数先只训 20 个 epoch 看 val_loss 趋势和这组统计指标确认方向对了才挂长训练省下的时间比那点训练成本值多了。希望帮到你。本文还有配套的精品资源点击获取