简介这是一份基于LSTM长短期记忆网络的自动音乐生成项目针对现有Simple RNN与WaveNet模型生成乐曲同质化严重、听感欠佳的问题提供了一套以LSTM为核心的优化实现方案。资源面向机器学习初学者和对音乐生成感兴趣的开发者覆盖从数据准备、模型搭建到乐曲输出的完整流程可作为课程设计或入门实践的有力参考。包体共8个文件压缩包仅466KB其中包含两个Jupyter Notebook分别用于主流程演示与交互界面操作、一个Python脚本、两份Markdown说明文档以及一份详细设计说明书PDF兼顾可运行代码、功能讲解与整体设计。目前已有239人学习下载适合需要了解LSTM在序列生成中如何应用并快速动手尝试的读者。通过该资源可以获取完整实现与设计思路理解利用LSTM改善自动作曲音乐质量的关键操作并在此基础上调整参数、扩展风格或继续优化模型。1. 自动音乐生成到底在生成什么为什么“能响”和“好听”是两回事把“基于机器学习的自动音乐生成优化”做成一个能跑通的项目第一步不是选模型而是先接受一个反直觉的事实机器生成一段 MIDI 很容易难的是让这段音乐在第三秒不被人切掉。标题里的“优化”不是单指把 Loss 调低而是从数据清洗、序列设计、训练策略、采样解码到人工评估一整条链路里每一层都在决定最后那个 midi 文件到底是“像音乐”还是“只是音符堆叠”。做这个方向的从业者通常分两类。一类是手里有音乐播放器、内容平台或创作工具需要低成本生成伴奏和动机另一类是做自然语言生成的开发者手里有 Transformer 的熟练经验想把它迁移到序列数据上。这个标题的技术核心是让模型学会音乐里的时间结构、音高关系、重复与变化而不是让它背诵训练集里的片段。适合你照着做的路线是符号化音乐生成用 MIDI 事件序列作为建模对象用语言模型的思路做生成然后靠解码和解耦手段把结果从“能跑通”推到“能听进去”。2. 数据是音乐生成的地基MIDI 事件序列构建与清洗落地2.1 为什么用 MIDI 而不是直接生成音频自动音乐生成有两条常见路线直接生成波形或频谱以及先生成 MIDI 事件再渲染成音频。标题没有指明技术路线但如果你面向的是“优化”而不是“探索”我一般会建议先走 MIDI。原因很实际音频生成对显存、数据规模、声学特征都有更高的门槛而且训练样本里的噪声远比符号数据难控制。MIDI 序列天然是离散的和语言模型一拍即合训练时用交叉熵生成时用采样整个技术栈顺延下来。另一个理由是可解释性。音乐生成最怕黑匣子当一段输出听上去节奏不对劲你要能定位是数据量化出了问题还是采样温度太高。MIDI 事件可以逐条打印出来检查音频模型做不到这种精细调试。直接音频生成当然也有它的价值特别是当你需要真实音色、人声或环境声时但从“自动音乐生成优化”这个标题出发用符号序列先把布局和结构做对再叠加音色渲染是更可控的路径。2.2 事件序列设计从“音符对”到“时间偏移”拿到一个 MIDI 文件第一步不是喂给模型而是想清楚你希望模型预测什么。最早的做法是把音符表示成“音高 时长 力度”听起来很直接但模型预测时会丢失一个关键信息音符之间的相对时间。两段旋律可能音高完全相同差别全在休止、附点和切分上。常见做法是使用事件序列每一条事件只代表一个原子变化。最基本的四个类型是音符开始、音符结束、时间偏移time-shift以及乐器切换。把“音高 C5、时值 0.5 秒”拆成“Note-On C5”后面跟一个“Time-Shift 0.5”模型就能学会节奏由时间偏移事件驱动而不是把时值塞进某个固定长度的向量里。时间偏移的粒度决定了模型表达的节奏精细度。我一般会把一个四分音符量化成 4 份也就是十六分音符粒度。粒度太粗附点、三连音都会失真粒度太细序列长度成倍上涨模型需要更多容量去学那些极少出现的超短时值。量化完成后节奏就被固定在一组有限的偏移取值里训练分布更稳定采样时也不会出现 0.473 秒这种没法落位的尴尬值。2.3 清洗流程与落地代码去重、过滤、量化数据清洗是这个方向里投入产出比最高的环节。我见过不少训练结果听起来“碎”和“乱”根因不在模型而在训练集里混进了未对齐的节拍轨道、长度不足两小节的碎片、以及大量只有单旋律没有伴奏的元数据。清洗的原则是宁缺毋滥不能让特殊样本主导梯度。下面是我常用的一段清洗脚本重点做了三件事按绝对时间对齐事件、过滤短片段、量化时值。import mido from collections import defaultdict def quantize_time(seconds, ticks_per_beat, beat_quarters4): # 把一个四分音符切成 beat_quarters 份默认 4 对应十六分音符 ticks_per_step ticks_per_beat / beat_quarters return round(seconds / (60 / 120) / ticks_per_step) def midi_to_events(path, min_notes32, pitch_min21, pitch_max108): mid mido.MidiFile(path) events [] abs_sec 0.0 note_accum defaultdict(lambda: None) for track in mid.tracks: for msg in track: abs_sec mido.tick2second(msg.time, mid.ticks_per_beat, 120) if msg.type note_on and msg.velocity 0: pitch msg.note if pitch pitch_min or pitch pitch_max: continue start_step quantize_time(abs_sec, mid.ticks_per_beat) note_accum[(pitch, msg.channel)] start_step elif msg.type note_off or (msg.type note_on and msg.velocity 0): pitch msg.note key (pitch, msg.channel) start_step note_accum.pop(key, None) if start_step is None: continue end_step quantize_time(abs_sec, mid.ticks_per_beat) if end_step start_step: events.append((start_step, end_step, pitch, msg.channel)) if len(events) min_notes: return None events.sort(keylambda e: e[0]) return events这段脚本先把所有轨道的事件换算成绝对时间再按量化步长切分最后把多轨道的音符合并到同一个时间轴上。参数min_notes控制最小音符数过滤掉碎片化片段pitch_min和pitch_max用来裁剪掉钢琴范围之外的高频噪声比如某些 MIDI 文件里控制信号被误写成音符。需要特别说明的是quantize_time里固化了 120 BPM 的假设。如果训练集里 BPM 差异很大先把所有 MIDI 转为同一 BPM 会更干净保留原始速度会引入不必要的节奏分布抖动模型容易学到“速度波动”这种无效特征。2.4 构建成可训练数据集时的边界问题事件序列构造好之后最常见的问题是切分方式。有人直接把整个 MIDI 文件压成一条超长序列训练时随机切一段。这样做的代价是切出来的片段既没有开头也没有结尾模型学到了“任何位置都能开始一段音乐”生成时反而缺少乐句感。我一般会按小节边界切分并保留 2 到 4 小节的上下文窗口。具体做法是先统计每个事件落在哪一小节再以小节为单位拼出固定长度的训练样本。这样做的好处是样本的起点和终点都落在音乐结构上模型学习到的条件分布更接近真实写作习惯。另一个坑是训练集和验证集的划分。如果按文件随机划分同一个 MIDI 的碎片可能同时出现在两边验证 Loss 会虚低。按文件 ID 整体划分才是可靠的评估方式。3. 把音乐变成语言问题事件 Token 设计与模型结构选型3.1 Token 词汇表决定模型能看到什么当音乐被表达成事件序列下一步就是把每一个事件映射成 token id。这一步看起来只是预处理实际却决定了模型能不能学会音乐结构。如果 token 粒度太粗比如直接把“整小节”作为一个 token模型就只能搬运现成节奏型无法自由组合如果粒度太细比如把力度也分成 128 级模型的大部分容量会浪费在学习人类几乎听不出的力度差别上。一套常见的初始词汇表设计如下Token 类型数量说明音符开始音高88钢琴 88 键省略极高和极低音区时间偏移64覆盖从十六分音符到两小节的间隔力度32将 MIDI 力度 0-127 压缩到 32 级乐器音色可选16只保留常用乐器家族特殊 token4开头、结尾、填充、未知这个设计里音符只保留开始事件不单独建模结束事件结束时间由下一个 note-on 之前的 time-shift 表达。好处是序列长度被压缩坏处是和弦同时发声时结束时间会绑定到下一个音符上造成细微的节奏偏移。如果训练数据以钢琴曲为主这种误差通常可以接受。时间偏移为什么需要 64 个档位16 分音符是最小单位从 16 分、8 分、附点 8 分、4 分、2 分到全音符再加上跨小节的连音64 个档位足够覆盖绝大多数流行与古典表达。档位太少会丢失附点节奏档位太多则会稀释 attention 对主体音符的关注。3.2 编解码结构 vs decoder-only怎么选模型结构的选择取决于你是否需要条件控制。无条件生成只给一个起始 token让模型自己往下写用 decoder-only 结构最简单给定和弦进行、风格标签或前 4 小节旋律让它续写编码器-解码器结构更合适因为它能让条件序列和生成序列分开处理。我主观上更倾向用 decoder-only 作为第一版。理由是音乐生成数据通常有限decoder-only 在相同参数量下训练更稳定而且做续写式生成时不需要额外构造条件-目标对。你可以在输入序列的最前面拼上一个风格 token 或和弦 token照样实现条件生成只是条件对生成结果的约束力会比编码器-解码器结构弱一些。如果你的目标是让模型严格跟随给定的和弦那编码器-解码器结构值得多花一倍训练成本。编码器负责理解输入条件和弦解码器负责生成音乐事件两者之间的注意力可以做到严格对齐。这个选型没有绝对优劣取决于你接受多少“可控性损失”。3.3 从事件到 token id 的落地实现代码上tokenizer 不需要像 NLP 那样用 BPE因为事件类型是封闭的。用查表映射就行关键是保证训练和生成时的映射完全一致。class MusicTokenizer: def __init__(self, n_pitches88, n_shifts64, n_velocities32, n_programs16): self.pitch_offset 0 self.shift_offset self.pitch_offset n_pitches self.vel_offset self.shift_offset n_shifts self.prog_offset self.vel_offset n_velocities self.special_offset self.prog_offset n_programs self.pad_id self.special_offset self.start_id self.special_offset 1 self.end_id self.special_offset 2 def encode(self, events): ids [self.start_id] for ev in events: if ev.type note: ids.append(self.pitch_offset ev.pitch) ids.append(self.vel_offset ev.velocity // 4) elif ev.type shift: ids.append(self.shift_offset ev.step) ids.append(self.end_id) return ids这样一个 token 序列里音符和力度被编码成两个连续 token时间偏移单独成 token。注意力度量化用了// 4把 0-127 映射到 0-31这是为了压缩词汇表。参数n_shifts和n_velocities是后期调优的重点如果生成结果节奏单一优先扩大n_shifts如果力度层次不分明考虑缩小力度档位。3.4 一个关键优化点控制序列长度与上下文模型输入长度直接影响它能学到的音乐结构。太短比如 256 token只能覆盖一两小节的内容模型不理解“主题在后文回归”这类结构太长比如 4096 token训练速度下降而且大部分音乐语料的局部相关性很高长依赖未必用得上。我建议以 512 到 1024 token 作为初始配置。对应到十六分音符粒度1024 token 大约覆盖 16 小节的单轨旋律对动机展开和乐句衔接已经足够。生成阶段可以再放宽到 2048因为推理不需要反传梯度显存压力小很多。上下文长度和注意力机制的相对位置编码也有关系下一章的 RoPE 位置编码会直接影响模型在这一长度上的表现。4. 训练优化让 Loss 下降不等于让音乐出彩4.1 交叉熵之外还要看什么训练音乐生成模型时交叉熵 Loss 是一个必要的监控指标但不是充分的验收标准。一个模型可以把 Loss 压得很低方法是学会输出训练集里出现频率最高的音高组合生成结果全是安全却无聊的分解和弦听感单调。我一般把 Loss 分成两个视角看整体 Loss 显示模型是否在稳定学习分 token 类型的 Loss 显示模型学的是不是音乐。比如单独统计 time-shift token 的准确率和召回率如果音符预测很准但 time-shift 经常错说明模型把音符当成了主要记忆对象节奏结构却没有被认真建模。这时候要在数据侧提高节奏多样性而不是加模型层数。4.2 一组可复制的训练超参基线训练参数不需要一开始就做大规模搜索我先给一组经过验证的基线参数建议值说明优化器AdamW权重衰减 0.01 起峰值学习率2e-4配合 warmup 使用warmup 步数1500防止初期不稳定梯度裁剪1.0防止偶发极端 token 拉崩训练Label Smoothing0.02缓解模型过度自信位置编码RoPE相对位置对音乐更好Batch Size视显存选最大受限于序列长度 1024warmup 的作用在音乐数据上尤其明显。音乐 token 分布极端不平衡常用的音高和 time-shift 值占绝大多数冷启动时不加 warmup 容易让学习率冲太高模型会集中在少数高频 token 上反复震荡。梯度裁剪 1.0 是对付 NaN 的最后保险偶尔训练集里混入异常 MIDI 会让某一步 loss 剧烈抬升裁剪后模型还能回调。Label Smoothing 的参数我建议从 0.01 起步。它是对抗“安全却无聊”生成结果的有效手段模型不再把某个音高概率推到 0.99采样时才有空间探索其他音符。但平滑值超过 0.1 后生成结果会开始散乱乐句失去方向感所以这个参数需要根据实际听感回调。4.3 训练循环代码从 batch 到 checkpoint训练循环本身并不复杂关键是在 checkpoint 之外加一个“固定 seed 采样”的旁路验证。每次保存模型时用同一段起始 token 生成 8 小节的音乐再对照上一次生成结果判断是否变好。def train_step(model, batch, optimizer, scheduler, scaler): x, y batch logits model(x) loss F.cross_entropy(logits.view(-1, vocab_size), y.view(-1), label_smoothing0.02) optimizer.zero_grad() scaler.scale(loss).backward() scaler.unscale_(optimizer) torch.nn.utils.clip_grad_norm_(model.parameters(), 1.0) scaler.step(optimizer) scaler.update() scheduler.step() return loss.item()这段代码里使用了混合精度 scaler可以省显存并且微幅提速但在梯度裁剪时必须先调用unscale_再裁剪否则 clip 作用在缩放后的梯度上数值就不对了。这个是新手最容易踩的坑和音乐本身无关但会卡掉一整天的训练进度。4.4 训练中的三个观察窗口只靠一个训练 Loss 曲线做判断你几乎无法定位生成质量问题。我习惯同时开三个观察窗口第一验证集 Loss。这个监控的是模型是否见过这些数据。如果验证 Loss 持续低于训练 Loss先检查数据是否泄漏而不是沾沾自喜。第二固定 seed 的生成样本。每 500 步生成一次哪怕只是 MIDI 渲染成音频快速听一遍都比任何数值指标更能反映节奏结构。第三token 频率直方图。每次评估时对比预测分布和真实数据分布的差距如果预测集中在少数几个 time-shift 值说明时间粒度或采样策略有待调整。这三个窗口不需要每个 epoch 都跑放在验证节点足够了。训练的音乐生成模型很多时候陷入“Loss 不降反升”反而能通过生成样本看出真实原因模型开始尝试更复杂的时间偏移组合验证 Loss 短暂回升这是正常现象不必盲目调低学习率。5. 自动音乐生成常见问题与排查从空洞输出到节奏崩溃5.1 解码参数为什么成了“玄学”训练完成后生成阶段才是翻车高发区。同样的 checkpoint用贪婪解码和用温度采样会得到完全不同的听感甚至temperature0.8和0.9之间都可能有明显差异。这些解码参数说到底是控制概率分布的形态但调参时很难一眼看出因果所以被很多从业者叫成玄学。我更愿意把它拆成三个独立问题随机性、候选集范围、重复抑制。还需要纠正一个常见误区温度值不是越低越稳。在音乐生成里低温度会放大高频 token 的差距导致模型反复输出同一句旋律表现成“复读机”。高温度则会让低概率 token 频繁出现音高之间跳跃性过大听感像即兴乱弹。我一般把temperature放在 0.8 到 1.0 之间再用 top-p 做截断。5.2 五个高频踩坑与对应解决步骤现象一生成结果全是重复动机前 4 小节和后 4 小节几乎一样。原因是采样策略太保守贪心解码或者温度过低导致模型锁定在最高概率路径。解决方法是调高温度到 0.9 以上同时把重复惩罚系数开到 1.2 以上。如果重复仍然严重检查训练数据的多样性很多数据集里同一首歌的多个版本没有做近似去重。现象二生成到一半变成长时间休止符。原因是模型学到了“空着不弹最安全”time-shift token 概率被推高。解决方法是解码时限制连续 time-shift 的步数或者在训练数据里过滤长休止片段。这个现象在无条件生成中尤其明显模型没有外部条件迫使其继续发展主题。现象三节奏崩溃小节内音符密度忽高忽低。原因是事件序列没有显式的小节边界信息模型全靠隐式统计难免在长序列后段失去节拍锚点。解决方法是把小节编号或强拍标记作为额外 token 输入让模型在每个小节开头重新对齐。加了这个 token 后生成内容的节奏稳定性会显著改善。现象四音域失控低频和高频同时出现像噪音一样的音符。原因是数据清洗时只过滤了 MIDI 范围而没有过滤到真实乐器范围。解决方法是把pitch_min和pitch_max收紧到钢琴 88 键的 21 到 108同时检查数据里是否存在鼓轨或效果轨这些轨道通常音高混乱需要单独剔除。现象五训练 Loss 不降或突然变成 NaN。原因是学习率过高、数据中存在重复片段或异常值。解决方法是确认 warmup 和梯度裁剪生效再做一次数据质量复查。另一个隐蔽问题是 token id 映射不一致训练时用的是pitch_offset0生成时却从 1 开始这会直接导致 loss 长期不降。5.3 一份可落地的生成采样函数生成阶段最常用的采样函数要同时支持温度、top-k、top-p 和重复惩罚。下面是一个可以直接嵌入推理脚本的实现def sample_with_config(logits, temperature0.9, top_p0.92, rep_penalty1.2, last_idsNone): logits logits / temperature if rep_penalty and last_ids is not None: for tid in set(last_ids): logits[tid] / rep_penalty probs torch.softmax(logits, dim-1) sorted_probs, sorted_idx torch.sort(probs, descendingTrue) cumsum torch.cumsum(sorted_probs, dim-1) mask cumsum - sorted_probs top_p sorted_probs[mask] 0.0 probs sorted_probs / sorted_probs.sum() idx torch.multinomial(probs, num_samples1) return sorted_idx[idx]代码里先把 logits 除以温度再把已经出现过的 token id 做重复惩罚最后用 top-p 截断低概率候选。rep_penalty的常见范围是 1.1 到 1.5大于 1.5 会让旋律变得卡顿模型想回头呼应主题时反而被惩罚。top-p 的取值 0.9 到 0.95 之间比较稳定太低的 top-p 会让输出失去装饰音。5.4 排查的整体建议用实验记录代替猜解码参数翻车时我通常不会只调一个参数。温度、top-p、重复惩罚存在叠加效应比如把温度从 0.7 调到 1.0重复惩罚从 1.2 调到 1.4结果反而变差了。推荐做法是固定一组 seed对每个参数做三组对照实验生成结果渲染成音频后保持同样的播放顺序用盲听判断。不要相信训练 Loss 的直观判断也不要在没记录的情况下连续调参那会变成纯粹的碰运气。6. 评估与进阶从“能听”到“能满意”的验证方法6.1 一组客观指标先过滤明显问题生成结果用机器指标先筛一遍能省下大量人工试听时间。我常用的四个指标是n-gram 重复率、音符密度分布、音高直方图重合度、time-shift 分布差异。重复率过高说明生成结果复读音符密度偏离真实数据说明节奏结构有问题音高直方图对比可以快速发现音域滥用。指标计算方式发现问题token 级重复率生成序列中连续 4-token 出现比例复读机现象音符密度每小节音符数与真实数据对比节奏混乱音高直方图生成/真实的 KL 散度音域偏移time-shift 分布生成/真实的直方图距离节奏活力不足这四个指标不需要等到训练结束才看每轮验证都能算。它们之间的配合很关键同时看重复率和 time-shift 分布可以区分“采样太保守导致的重复”和“模型没学会休止导致的密集轰炸”。6.2 主观试听评估建立自己的样本对比库客观指标能筛掉 80% 的明显劣质输出但“好不好听”最终还得靠人耳。我会建立二十个固定起始条件每次 checkpoint 生成对应的二十段音乐标注三个维度节奏稳定性、旋律变化度、整体完成度。节奏稳定性回答“能不能打拍子”旋律变化度回答“是否会自我重复”完成度回答“听起来有没有结尾感”。这个过程很枯燥但比找十个人分别听不同版本更可比较。一个有效的小技巧把不同 checkpoint 的同一段条件生成拼成一条音频中间留半秒静音。连续播放时的差异会放大模型改进的细节新版本是否解决了旧版本的重音错位、连接处是否自然在 A/B 对比中比单独听更敏感。6.3 有条件生成与双阶段生成下一步怎么优化到此为止你已经能跑通一条完整的数据、训练、生成、评估链路。如果想继续往“可控生成”方向走下一步是条件生成把风格标签、和弦序列或小节约束作为前缀 token 拼在输入前让模型在给定条件下续写。更进一步是双阶段生成第一阶段只生成和弦级或小节级的概览 token第二阶段基于概览逐小节填充细节这能明显提升长序列的结构感。我第一次把整条链路跑完时最懊悔的一件事是没早做数据可视化。前两周我盯着 Loss 下降沾沾自喜生成结果却像噪音后来把验证样本的 token 频率打出来才知道模型一直在重复同一组高概率转移。现在我每调整一个参数都会保留一组固定的生成 seed 和对应的音频样本所有取舍都靠对照记录而不是印象。这条路没有银弹但把地基打好、把解码和评估做扎实生成结果从“能响”到“能满意”是可以稳定推进的。希望帮到你。本文还有配套的精品资源点击获取