简介面向AI音乐创作开发者的实战型PDF文档聚焦DeepSeek与MIDI技术结合生成原创音乐这一主题旨在解决传统作曲流程耗时费力、风格受限等痛点。文档共26页资源包为单个PDF文件大小约1.97MB内容按“背景—原理—预处理—建模—生成—评估—案例”递进展开先介绍AI作曲发展脉络与DeepSeek模型特性再讲解MIDI基础、文件结构、解析工具继而细化音符、节奏、和弦特征提取以及模型架构设计、训练数据准备、超参数调优、音乐种子处理、MIDI事件生成与保存等完整环节。文中特别给出游戏配乐、影视配乐、个性化音乐推荐等应用案例并结合主观与客观评估方法说明调优策略可帮助读者从零搭建可运行的DeepSeek作曲流程。资源已有377人学习适合希望借助大模型提升音乐创作效率的开发者、算法工程师及音乐科技爱好者。1. AI作曲不是黑匣子DeepSeek和MIDI到底怎么配合第一次把DeepSeek用在作曲上时我和多数人一样以为要自己训练一个音乐生成模型。真正跑通流程才发现核心思路远没有那么玄把乐谱转成文本让DeepSeek这类大语言模型做结构生成和续写再把这些文本解析回MIDI事件。换句话说AI作曲不是让模型“哼唱”而是让模型学会用格式正确的文本描述音乐然后由程序把它翻译成计算机能演奏的指令。这份《AI作曲实战DeepSeekMIDI生成原创音乐》解决的就是这条完整链路从DeepSeek模型加载、MIDI文件解析到数据清洗、特征提取、文本化表示再到生成MIDI并评估优化。它面向的是有一定Python基础、想用大模型做自动配乐、游戏音效或音乐创作辅助的开发者。你不需要是音乐理论专家但最好对音高、时长这些基础概念有直觉否则后面调参时会有一点吃力。下面我按自己拆解和复现这套流程的顺序把关键技术点和踩过的坑讲一遍。2. DeepSeek模型加载与推理先把大模型的“音乐脑”跑起来2.1 DeepSeek不是音乐模型但能当乐理结构生成器DeepSeek本质上是基于Transformer架构变体的大语言模型擅长文本理解和生成。音乐场景里它并不直接输出音频波形而是承担“乐理结构生成器”的角色。你可以给它输入“一段神秘的冒险音乐钢琴音色4/4拍速度90”它会生成一段结构化的音乐描述文本包括音符序列、和弦走向、力度变化等。为什么非要用DeepSeek而不是专门训练一个音乐模型两个原因。第一DeepSeek的多语言和通用知识让它能理解“神秘”“冒险”“温馨”这类抽象形容词并映射到具体的音乐元素上比如小调、减和弦、慢速第二它的生成能力让我们可以用自然语言控制音乐风格不用写复杂的规则引擎。这也是文档里最核心的设计思路文本是中间语言MIDI是最终产物。2.2 环境搭建与模型加载transformers三行代码使用DeepSeek的第一步是搭环境。文档里走的是本地加载路线依赖Python和transformers库。pip install torch transformers如果机器没有GPUtorch会自动装CPU版本推理会慢很多但小规模测试足够。接着加载分词器和模型from transformers import AutoTokenizer, AutoModelForCausalLM model_name deepseek-ai/deepseek-llm-7b-chat tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, device_mapauto, torch_dtypeauto )这段代码做了两件事分词器把文本切成token id序列模型把token id序列映射成概率分布并生成新token。device_mapauto让transformers自动把层分配到GPU或CPUtorch_dtypeauto自动选择fp16或fp32省得手动指定。这里有个现实问题7B模型至少需要14GB显存才能舒服地跑推理。如果你的机器扛不住可以换更小的量化版本或者在Hugging Face上找GGUF格式用llama.cpp加载。文档后面也提到了如果走DeepSeek API直接把from_pretrained换成requests.post调用接口即可提示词逻辑完全一样只是不需要本地显存。2.3 输入处理与推理参数num_beams、no_repeat_ngram_size怎么调模型加载完下一步是把音乐提示词转成输入。文档里给的生成参数值得细看input_text 生成一段神秘氛围的冒险音乐使用钢琴音色4/4拍速度90包含主旋律和低音和弦 input_ids tokenizer.encode(input_text, return_tensorspt) output model.generate( input_ids, max_length200, num_beams5, no_repeat_ngram_size2, early_stoppingTrue, temperature0.8, do_sampleTrue ) generated_text tokenizer.decode(output[0], skip_special_tokensTrue) print(generated_text)max_length200控制生成的最大token数对一段16小节的钢琴曲来说基本够用。num_beams5表示用beam search每步保留5个最优候选质量比贪心解码高但速度慢不少。no_repeat_ngram_size2禁止2-gram重复出现防止模型陷入“啦啦啦”式的死循环。early_stoppingTrue配合beam search在候选收敛后提前停止。注意一个关键点如果你设置了do_sampleTruetemperature才会起作用。temperature0.8让概率分布变陡峭一些输出更稳定想要更有创意的旋律可以调到0.9甚至1.0但风险是音符越界或结构松散。如果do_sampleFalsetemperature会被忽略此时只走beam search输出确定性高但容易单调。实际跑的时候我一般先用beam search验证流程通不通再开sampling做风格试听。3. MIDI解析与数据清洗把乐谱变成可训练的事件流3.1 MIDI不是音频是演奏指令协议MIDI全称是Musical Instrument Digital Interface它不记录波形只记录“在什么时间、用什么音符、多大力度、持续多久”这些指令。一个MIDI文件可能只有几十KB却能完整描述一首交响曲的每个声部。对AI作曲来说MIDI是最理想的中间格式体积小、无版权音频干扰、结构清晰可解析。文档里强调了一个容易混淆的点MIDI文件不包含音色本身音色由播放设备或SoundFont音色库决定。所以在生成链路里MIDI负责“写谱”音色库负责“演奏”两者分离。3.2 用mido解析文件头、轨道、事件Python生态里mido是轻量级MIDI库pretty_midi则更高层。文档主推mido因为它更贴近底层协议方便我们精确控制事件。import mido mid mido.MidiFile(example.mid) print(f格式类型: {mid.type}) print(f轨道数量: {len(mid.tracks)}) print(f时间划分: {mid.ticks_per_beat}) for i, track in enumerate(mid.tracks): print(f轨道 {i}:) for msg in track: print(msg)这段代码能让你一眼看穿MIDI内部结构。mid.type有0、1、2三种0表示单轨1表示多轨同步2表示多轨独立。ticks_per_beat是每四分音符的滴答数常见值有480、960这个值直接影响时长的换算。轨道里的事件是核心。最常见的note_on和note_off成对出现note_on带音符编号0-127和力度0-127。60号音符是中央C每高一个数字就是高半音。还有control_change控制踏板、音量等program_change切换乐器。3.3 提取音符特征音高、时长、力度一个不能少解析MIDI的最终目的是提取特征。下面这个函数来自文档思路做了我补充的边界处理def extract_note_features(midi_file): mid mido.MidiFile(midi_file) note_features [] note_on_time {} for track in mid.tracks: current_time 0 for msg in track: current_time msg.time if msg.type note_on and msg.velocity 0: note_on_time[msg.note] current_time elif msg.type note_off or (msg.type note_on and msg.velocity 0): if msg.note in note_on_time: pitch msg.note duration current_time - note_on_time[msg.note] velocity msg.velocity if msg.type note_off else 0 note_features.append((pitch, duration, velocity)) del note_on_time[msg.note] return note_features这里有个非常关键的细节MIDI规范允许用note_on且velocity0来代替note_off很多编曲软件导出的文件就是这么干的。如果你只判断msg.type note_off那些用0力度表示结束的音符就永远不会被配对解析出来的时值会错乱。所以条件里必须加上(msg.type note_on and msg.velocity 0)。current_time是事件在全局时间轴上的绝对位置通过累加每个msg.time得到。duration是note_off时的绝对时间减去note_on时的绝对时间单位是tick不是秒。换算成秒需要秒 tick / (ticks_per_beat * (BPM / 60))。4. 数据文本化与生成实战从音符序列到完整MIDI4.1 数据清洗与统一格式去冗余、统一ticks_per_beat从互联网收集的MIDI文件鱼龙混杂直接喂给模型会出各种问题。第一步是清洗。文档给出的清洗函数很实用def clean_midi_file(input_file, output_file, ticks_per_beat480): mid mido.MidiFile(input_file) mid.ticks_per_beat ticks_per_beat new_tracks [] for track in mid.tracks: new_track [] prev None for msg in track: if msg.type control_change and prev is not None \ and prev.type control_change and prev.value msg.value: continue new_track.append(msg) prev msg new_tracks.append(new_track) mid.tracks new_tracks mid.save(output_file)这个函数做两件事统一所有文件的ticks_per_beat为480并删除连续重复的control_change事件。重复控制变更对音乐没有实际影响但会让文本化后的序列变长干扰模型学习。注意直接修改ticks_per_beat会把原有音符时值按比例缩放如果你只是想让所有文件统一基准这个操作没问题。但如果你改完后不重新计算时长原有的note_off时间就会错位。所以更稳妥的做法是先解析出音符特征再按目标ticks_per_beat重新计算时长最后重建MIDI。4.2 文本化表示把音符序列变成大模型能懂的字符串DeepSeek只认文本所以MIDI特征得翻译成字符串。文档里给了一种最直接的方案def midi_to_text(note_features): tokens [] for pitch, duration, velocity in note_features: tokens.append(fP:{pitch} D:{duration} V:{velocity}) return .join(tokens)输出效果像这样P:60 D:480 V:80 P:64 D:240 V:72 P:67 D:480 V:75这种表示法把每个音符编码成三个属性音高P、时长Dtick数、力度V。模型学到的是“P:60 D:480 V:80”这样的token组合规律生成时也会模仿这个格式。但这里有个取舍直接用tick数会让模型很难区分“480”是四分音符还是其他值因为不同文件的ticks_per_beat可能不同。我一般会在文本化之前把时长归一化先通过duration duration / mid.ticks_per_beat * 480统一到480基准再转成文本。如果想让模型学习节奏型还可以加上节拍位置比如用B:{beat}表示当前音符在小节内的位置。4.3 生成实战从种子到MIDI的完整链路生成环节是整个流程的临门一脚。核心思路是给定一个提示词种子让DeepSeek续写出完整音符序列文本然后用正则解析重建MIDI文件。import re import mido def parse_generated_text(text): pattern re.compile(rP:(\d) D:(\d) V:(\d)) matches pattern.findall(text) return [(int(p), int(d), int(v)) for p, d, v in matches] def text_to_midi(notes, output_file): mid mido.MidiFile() mid.ticks_per_beat 480 track mido.MidiTrack() mid.tracks.append(track) time 0 for pitch, duration, velocity in notes: pitch max(0, min(127, pitch)) duration max(1, duration) velocity max(1, min(127, velocity)) track.append(mido.Message(note_on, notepitch, velocityvelocity, timetime)) track.append(mido.Message(note_off, notepitch, velocity0, timeduration)) time 0 # 上一个note_off已经占用了时长 mid.save(output_file)这段代码有几个关键约束。第一pitch必须夹在0-127之间否则MIDI文件不合法第二time是delta时间表示距离上一事件多少tick第一个note_on的time是0后续每个note_on的time都应为0因为前一个note_off已经把音符时值占掉了如果中间要插休止符得在note_off的time上加上休止长度第三velocity同样要限制在1-1270力度会被误判为note_off。这一串整合起来就是文档里的完整生成流程音乐种子提示词→ DeepSeek生成文本 → 正则解析 → 音符三元组 → MIDI文件。整个过程不需要训练任何模型DeepSeek只负责“写谱”解析和成曲交给代码。5. 常见问题与避坑五个实测翻车点及修复方法5.1 生成的音符音高越界P:128直接报错现象DeepSeek生成文本里出现P:128、P:200这类音符编号程序解析时创建MIDI消息直接抛出ValueError: note number out of range。原因大模型不理解MIDI音符编号有0-127的硬边界它在自由生成时完全可能编出128以上的数字。解决解析后强制夹取边界或者直接丢弃越界音符。我在上面text_to_midi里已经写了max(0, min(127, pitch))。更稳妥的是在解析函数里加一个过滤逻辑如果pitch不在0-127范围内整条记录丢弃而不是修正因为把128硬改成127会产生不自然的半音跳跃。5.2 时值混乱四分音符变成几千tick现象生成的MIDI播放出来忽快忽慢同一个乐句里四分音符的时值有时是480有时是2400节奏完全没法听。原因训练数据里混合了不同ticks_per_beat的MIDI文件有的480有的960甚至有的1920。模型把这些数字混在一起学自然分不清“一个四分音符到底该多长”。解决在清洗阶段把所有文件统一到ticks_per_beat480并且文本化之前重新计算时长。具体做法是提取音符特征时记录原文件的ticks_per_beat然后duration_new duration_old / ticks_per_beat_old * 480。生成后的解析阶段也要检查时长是否在一个合理范围比如16-1920超出就按最近的合法值修正。5.3 力度0被误判为无效音符长音被拆散现象解析结果里出现大量时长为0或很短的音符原先的持续长音变成了同音反复。原因部分MIDI文件的note_off事件被编码成了note_on且velocity0。解析时如果在note_on分支里直接忽略velocity0那这个音符永远不会关闭后面再遇到同音高的note_on时前面的音符被强制终止或漏掉。解决统一按note_off处理即同时判断msg.type note_off或msg.type note_on and msg.velocity 0。这个坑我复现文档代码时踩过一次检查特征提取条件就能发现。5.4 多轨道合并后和声错位现象把几个轨道合并成一首曲子后原本同时发声的和弦变成了前后错开的琶音声部全乱了。原因MIDI格式1中每个轨道都有自己的delta time计数器不同轨道的音符事件起始时间不能直接用轨道内的时间递增来比较。直接按轨道顺序插入新文件会丢失全局时间对齐信息。解决合并前先把每个轨道的事件转换成绝对时间然后按绝对时间排序再统一写到单个轨道同时把delta time计算为当前绝对时间减上一个事件的绝对时间。mido里有个MidiFile.merge_tracks()方法可以直接用但前提是解析时已经处理了力度0的note_off。5.5 生成文本突然中断旋律戛然而止现象DeepSeek生成到一半就停止最离谱一次只输出了两个小节就没了而且没有正常结束的标记。原因max_length设得太小或者early_stoppingTrue在beam search时判定收敛过早另一种可能是模型自己生成了eostoken提前结束了。解决把max_length调大比如从200调到512early_stopping保持False让模型走完固定的步数。如果担心模型过早生成EOS可以在generate时设置eos_token_idNone强制不截断然后靠max_new_tokens做硬限制。生成后再检查文本末尾是不是完整的三元组缺了就补一个随机休止符或重复前一小节收尾。6. 进阶评估生成效果、渲染音频、定义专属风格当你能稳定生成MIDI文件后下一个问题就是“怎么判断这段音乐好不好”。客观评估有三个简单指标音域分布、节奏多样性、音符密度。音域可以统计生成音符的pitch范围如果全部挤在60-72之间说明模型输出过于保守节奏多样性统计duration值的种类理想情况下应该同时包含四分音符、八分音符、附点音符而不是清一色480音符密度看每小节音符数密度过高像噪音过低像呆板的长音。主观评估最直接的方式是渲染成音频听。文档里给了fluidsynth一行命令搞定fluidsynth -ni SoundFont.sf2 example.mid -F output.wav-n表示不循环播放-i表示安静模式SoundFont.sf2是音色库文件你可以去网上找免费的GeneralUser GS音色库或者FluidR3_GM。渲染出来的WAV可以用任何播放器试听比在DAW里导入MIDI快速得多。这一步强烈推荐每次生成后都跑一遍因为有些结构问题光看MIDI事件很难发现一听就原形毕露。想让生成风格更可控可以在提示词里加入更具体的要求比如“使用C小调”“副歌部分加入切分节奏”“力度从弱到强”。DeepSeek对这类音乐术语的理解力相当不错但需要你把它当作“乐理助手”而不是“自动作曲机”。我还试过用midi转简谱的方式检查旋律线把生成的P:60 D:480 V:80转成1 - - -这样的简谱符号快速扫一眼就能发现音程跳跃是否合理。最后说一个我自己养成的习惯每次拿到生成结果先跑一遍边界检查——pitch是否在0-127、duration是否为正、velocity是否为0然后用fluidsynth渲染出WAV最后用midi转简谱扫一眼旋律轮廓。这三步走完再谈优化和入库。虽然麻烦但确实帮我避免了好几次把越界音符直接写进游戏配乐项目的尴尬。希望帮到你。本文还有配套的精品资源点击获取 DeepSeek+MIDI实战：从文本到原创音乐的完整链路
简介面向AI音乐创作开发者的实战型PDF文档聚焦DeepSeek与MIDI技术结合生成原创音乐这一主题旨在解决传统作曲流程耗时费力、风格受限等痛点。文档共26页资源包为单个PDF文件大小约1.97MB内容按“背景—原理—预处理—建模—生成—评估—案例”递进展开先介绍AI作曲发展脉络与DeepSeek模型特性再讲解MIDI基础、文件结构、解析工具继而细化音符、节奏、和弦特征提取以及模型架构设计、训练数据准备、超参数调优、音乐种子处理、MIDI事件生成与保存等完整环节。文中特别给出游戏配乐、影视配乐、个性化音乐推荐等应用案例并结合主观与客观评估方法说明调优策略可帮助读者从零搭建可运行的DeepSeek作曲流程。资源已有377人学习适合希望借助大模型提升音乐创作效率的开发者、算法工程师及音乐科技爱好者。1. AI作曲不是黑匣子DeepSeek和MIDI到底怎么配合第一次把DeepSeek用在作曲上时我和多数人一样以为要自己训练一个音乐生成模型。真正跑通流程才发现核心思路远没有那么玄把乐谱转成文本让DeepSeek这类大语言模型做结构生成和续写再把这些文本解析回MIDI事件。换句话说AI作曲不是让模型“哼唱”而是让模型学会用格式正确的文本描述音乐然后由程序把它翻译成计算机能演奏的指令。这份《AI作曲实战DeepSeekMIDI生成原创音乐》解决的就是这条完整链路从DeepSeek模型加载、MIDI文件解析到数据清洗、特征提取、文本化表示再到生成MIDI并评估优化。它面向的是有一定Python基础、想用大模型做自动配乐、游戏音效或音乐创作辅助的开发者。你不需要是音乐理论专家但最好对音高、时长这些基础概念有直觉否则后面调参时会有一点吃力。下面我按自己拆解和复现这套流程的顺序把关键技术点和踩过的坑讲一遍。2. DeepSeek模型加载与推理先把大模型的“音乐脑”跑起来2.1 DeepSeek不是音乐模型但能当乐理结构生成器DeepSeek本质上是基于Transformer架构变体的大语言模型擅长文本理解和生成。音乐场景里它并不直接输出音频波形而是承担“乐理结构生成器”的角色。你可以给它输入“一段神秘的冒险音乐钢琴音色4/4拍速度90”它会生成一段结构化的音乐描述文本包括音符序列、和弦走向、力度变化等。为什么非要用DeepSeek而不是专门训练一个音乐模型两个原因。第一DeepSeek的多语言和通用知识让它能理解“神秘”“冒险”“温馨”这类抽象形容词并映射到具体的音乐元素上比如小调、减和弦、慢速第二它的生成能力让我们可以用自然语言控制音乐风格不用写复杂的规则引擎。这也是文档里最核心的设计思路文本是中间语言MIDI是最终产物。2.2 环境搭建与模型加载transformers三行代码使用DeepSeek的第一步是搭环境。文档里走的是本地加载路线依赖Python和transformers库。pip install torch transformers如果机器没有GPUtorch会自动装CPU版本推理会慢很多但小规模测试足够。接着加载分词器和模型from transformers import AutoTokenizer, AutoModelForCausalLM model_name deepseek-ai/deepseek-llm-7b-chat tokenizer AutoTokenizer.from_pretrained(model_name) model AutoModelForCausalLM.from_pretrained( model_name, device_mapauto, torch_dtypeauto )这段代码做了两件事分词器把文本切成token id序列模型把token id序列映射成概率分布并生成新token。device_mapauto让transformers自动把层分配到GPU或CPUtorch_dtypeauto自动选择fp16或fp32省得手动指定。这里有个现实问题7B模型至少需要14GB显存才能舒服地跑推理。如果你的机器扛不住可以换更小的量化版本或者在Hugging Face上找GGUF格式用llama.cpp加载。文档后面也提到了如果走DeepSeek API直接把from_pretrained换成requests.post调用接口即可提示词逻辑完全一样只是不需要本地显存。2.3 输入处理与推理参数num_beams、no_repeat_ngram_size怎么调模型加载完下一步是把音乐提示词转成输入。文档里给的生成参数值得细看input_text 生成一段神秘氛围的冒险音乐使用钢琴音色4/4拍速度90包含主旋律和低音和弦 input_ids tokenizer.encode(input_text, return_tensorspt) output model.generate( input_ids, max_length200, num_beams5, no_repeat_ngram_size2, early_stoppingTrue, temperature0.8, do_sampleTrue ) generated_text tokenizer.decode(output[0], skip_special_tokensTrue) print(generated_text)max_length200控制生成的最大token数对一段16小节的钢琴曲来说基本够用。num_beams5表示用beam search每步保留5个最优候选质量比贪心解码高但速度慢不少。no_repeat_ngram_size2禁止2-gram重复出现防止模型陷入“啦啦啦”式的死循环。early_stoppingTrue配合beam search在候选收敛后提前停止。注意一个关键点如果你设置了do_sampleTruetemperature才会起作用。temperature0.8让概率分布变陡峭一些输出更稳定想要更有创意的旋律可以调到0.9甚至1.0但风险是音符越界或结构松散。如果do_sampleFalsetemperature会被忽略此时只走beam search输出确定性高但容易单调。实际跑的时候我一般先用beam search验证流程通不通再开sampling做风格试听。3. MIDI解析与数据清洗把乐谱变成可训练的事件流3.1 MIDI不是音频是演奏指令协议MIDI全称是Musical Instrument Digital Interface它不记录波形只记录“在什么时间、用什么音符、多大力度、持续多久”这些指令。一个MIDI文件可能只有几十KB却能完整描述一首交响曲的每个声部。对AI作曲来说MIDI是最理想的中间格式体积小、无版权音频干扰、结构清晰可解析。文档里强调了一个容易混淆的点MIDI文件不包含音色本身音色由播放设备或SoundFont音色库决定。所以在生成链路里MIDI负责“写谱”音色库负责“演奏”两者分离。3.2 用mido解析文件头、轨道、事件Python生态里mido是轻量级MIDI库pretty_midi则更高层。文档主推mido因为它更贴近底层协议方便我们精确控制事件。import mido mid mido.MidiFile(example.mid) print(f格式类型: {mid.type}) print(f轨道数量: {len(mid.tracks)}) print(f时间划分: {mid.ticks_per_beat}) for i, track in enumerate(mid.tracks): print(f轨道 {i}:) for msg in track: print(msg)这段代码能让你一眼看穿MIDI内部结构。mid.type有0、1、2三种0表示单轨1表示多轨同步2表示多轨独立。ticks_per_beat是每四分音符的滴答数常见值有480、960这个值直接影响时长的换算。轨道里的事件是核心。最常见的note_on和note_off成对出现note_on带音符编号0-127和力度0-127。60号音符是中央C每高一个数字就是高半音。还有control_change控制踏板、音量等program_change切换乐器。3.3 提取音符特征音高、时长、力度一个不能少解析MIDI的最终目的是提取特征。下面这个函数来自文档思路做了我补充的边界处理def extract_note_features(midi_file): mid mido.MidiFile(midi_file) note_features [] note_on_time {} for track in mid.tracks: current_time 0 for msg in track: current_time msg.time if msg.type note_on and msg.velocity 0: note_on_time[msg.note] current_time elif msg.type note_off or (msg.type note_on and msg.velocity 0): if msg.note in note_on_time: pitch msg.note duration current_time - note_on_time[msg.note] velocity msg.velocity if msg.type note_off else 0 note_features.append((pitch, duration, velocity)) del note_on_time[msg.note] return note_features这里有个非常关键的细节MIDI规范允许用note_on且velocity0来代替note_off很多编曲软件导出的文件就是这么干的。如果你只判断msg.type note_off那些用0力度表示结束的音符就永远不会被配对解析出来的时值会错乱。所以条件里必须加上(msg.type note_on and msg.velocity 0)。current_time是事件在全局时间轴上的绝对位置通过累加每个msg.time得到。duration是note_off时的绝对时间减去note_on时的绝对时间单位是tick不是秒。换算成秒需要秒 tick / (ticks_per_beat * (BPM / 60))。4. 数据文本化与生成实战从音符序列到完整MIDI4.1 数据清洗与统一格式去冗余、统一ticks_per_beat从互联网收集的MIDI文件鱼龙混杂直接喂给模型会出各种问题。第一步是清洗。文档给出的清洗函数很实用def clean_midi_file(input_file, output_file, ticks_per_beat480): mid mido.MidiFile(input_file) mid.ticks_per_beat ticks_per_beat new_tracks [] for track in mid.tracks: new_track [] prev None for msg in track: if msg.type control_change and prev is not None \ and prev.type control_change and prev.value msg.value: continue new_track.append(msg) prev msg new_tracks.append(new_track) mid.tracks new_tracks mid.save(output_file)这个函数做两件事统一所有文件的ticks_per_beat为480并删除连续重复的control_change事件。重复控制变更对音乐没有实际影响但会让文本化后的序列变长干扰模型学习。注意直接修改ticks_per_beat会把原有音符时值按比例缩放如果你只是想让所有文件统一基准这个操作没问题。但如果你改完后不重新计算时长原有的note_off时间就会错位。所以更稳妥的做法是先解析出音符特征再按目标ticks_per_beat重新计算时长最后重建MIDI。4.2 文本化表示把音符序列变成大模型能懂的字符串DeepSeek只认文本所以MIDI特征得翻译成字符串。文档里给了一种最直接的方案def midi_to_text(note_features): tokens [] for pitch, duration, velocity in note_features: tokens.append(fP:{pitch} D:{duration} V:{velocity}) return .join(tokens)输出效果像这样P:60 D:480 V:80 P:64 D:240 V:72 P:67 D:480 V:75这种表示法把每个音符编码成三个属性音高P、时长Dtick数、力度V。模型学到的是“P:60 D:480 V:80”这样的token组合规律生成时也会模仿这个格式。但这里有个取舍直接用tick数会让模型很难区分“480”是四分音符还是其他值因为不同文件的ticks_per_beat可能不同。我一般会在文本化之前把时长归一化先通过duration duration / mid.ticks_per_beat * 480统一到480基准再转成文本。如果想让模型学习节奏型还可以加上节拍位置比如用B:{beat}表示当前音符在小节内的位置。4.3 生成实战从种子到MIDI的完整链路生成环节是整个流程的临门一脚。核心思路是给定一个提示词种子让DeepSeek续写出完整音符序列文本然后用正则解析重建MIDI文件。import re import mido def parse_generated_text(text): pattern re.compile(rP:(\d) D:(\d) V:(\d)) matches pattern.findall(text) return [(int(p), int(d), int(v)) for p, d, v in matches] def text_to_midi(notes, output_file): mid mido.MidiFile() mid.ticks_per_beat 480 track mido.MidiTrack() mid.tracks.append(track) time 0 for pitch, duration, velocity in notes: pitch max(0, min(127, pitch)) duration max(1, duration) velocity max(1, min(127, velocity)) track.append(mido.Message(note_on, notepitch, velocityvelocity, timetime)) track.append(mido.Message(note_off, notepitch, velocity0, timeduration)) time 0 # 上一个note_off已经占用了时长 mid.save(output_file)这段代码有几个关键约束。第一pitch必须夹在0-127之间否则MIDI文件不合法第二time是delta时间表示距离上一事件多少tick第一个note_on的time是0后续每个note_on的time都应为0因为前一个note_off已经把音符时值占掉了如果中间要插休止符得在note_off的time上加上休止长度第三velocity同样要限制在1-1270力度会被误判为note_off。这一串整合起来就是文档里的完整生成流程音乐种子提示词→ DeepSeek生成文本 → 正则解析 → 音符三元组 → MIDI文件。整个过程不需要训练任何模型DeepSeek只负责“写谱”解析和成曲交给代码。5. 常见问题与避坑五个实测翻车点及修复方法5.1 生成的音符音高越界P:128直接报错现象DeepSeek生成文本里出现P:128、P:200这类音符编号程序解析时创建MIDI消息直接抛出ValueError: note number out of range。原因大模型不理解MIDI音符编号有0-127的硬边界它在自由生成时完全可能编出128以上的数字。解决解析后强制夹取边界或者直接丢弃越界音符。我在上面text_to_midi里已经写了max(0, min(127, pitch))。更稳妥的是在解析函数里加一个过滤逻辑如果pitch不在0-127范围内整条记录丢弃而不是修正因为把128硬改成127会产生不自然的半音跳跃。5.2 时值混乱四分音符变成几千tick现象生成的MIDI播放出来忽快忽慢同一个乐句里四分音符的时值有时是480有时是2400节奏完全没法听。原因训练数据里混合了不同ticks_per_beat的MIDI文件有的480有的960甚至有的1920。模型把这些数字混在一起学自然分不清“一个四分音符到底该多长”。解决在清洗阶段把所有文件统一到ticks_per_beat480并且文本化之前重新计算时长。具体做法是提取音符特征时记录原文件的ticks_per_beat然后duration_new duration_old / ticks_per_beat_old * 480。生成后的解析阶段也要检查时长是否在一个合理范围比如16-1920超出就按最近的合法值修正。5.3 力度0被误判为无效音符长音被拆散现象解析结果里出现大量时长为0或很短的音符原先的持续长音变成了同音反复。原因部分MIDI文件的note_off事件被编码成了note_on且velocity0。解析时如果在note_on分支里直接忽略velocity0那这个音符永远不会关闭后面再遇到同音高的note_on时前面的音符被强制终止或漏掉。解决统一按note_off处理即同时判断msg.type note_off或msg.type note_on and msg.velocity 0。这个坑我复现文档代码时踩过一次检查特征提取条件就能发现。5.4 多轨道合并后和声错位现象把几个轨道合并成一首曲子后原本同时发声的和弦变成了前后错开的琶音声部全乱了。原因MIDI格式1中每个轨道都有自己的delta time计数器不同轨道的音符事件起始时间不能直接用轨道内的时间递增来比较。直接按轨道顺序插入新文件会丢失全局时间对齐信息。解决合并前先把每个轨道的事件转换成绝对时间然后按绝对时间排序再统一写到单个轨道同时把delta time计算为当前绝对时间减上一个事件的绝对时间。mido里有个MidiFile.merge_tracks()方法可以直接用但前提是解析时已经处理了力度0的note_off。5.5 生成文本突然中断旋律戛然而止现象DeepSeek生成到一半就停止最离谱一次只输出了两个小节就没了而且没有正常结束的标记。原因max_length设得太小或者early_stoppingTrue在beam search时判定收敛过早另一种可能是模型自己生成了eostoken提前结束了。解决把max_length调大比如从200调到512early_stopping保持False让模型走完固定的步数。如果担心模型过早生成EOS可以在generate时设置eos_token_idNone强制不截断然后靠max_new_tokens做硬限制。生成后再检查文本末尾是不是完整的三元组缺了就补一个随机休止符或重复前一小节收尾。6. 进阶评估生成效果、渲染音频、定义专属风格当你能稳定生成MIDI文件后下一个问题就是“怎么判断这段音乐好不好”。客观评估有三个简单指标音域分布、节奏多样性、音符密度。音域可以统计生成音符的pitch范围如果全部挤在60-72之间说明模型输出过于保守节奏多样性统计duration值的种类理想情况下应该同时包含四分音符、八分音符、附点音符而不是清一色480音符密度看每小节音符数密度过高像噪音过低像呆板的长音。主观评估最直接的方式是渲染成音频听。文档里给了fluidsynth一行命令搞定fluidsynth -ni SoundFont.sf2 example.mid -F output.wav-n表示不循环播放-i表示安静模式SoundFont.sf2是音色库文件你可以去网上找免费的GeneralUser GS音色库或者FluidR3_GM。渲染出来的WAV可以用任何播放器试听比在DAW里导入MIDI快速得多。这一步强烈推荐每次生成后都跑一遍因为有些结构问题光看MIDI事件很难发现一听就原形毕露。想让生成风格更可控可以在提示词里加入更具体的要求比如“使用C小调”“副歌部分加入切分节奏”“力度从弱到强”。DeepSeek对这类音乐术语的理解力相当不错但需要你把它当作“乐理助手”而不是“自动作曲机”。我还试过用midi转简谱的方式检查旋律线把生成的P:60 D:480 V:80转成1 - - -这样的简谱符号快速扫一眼就能发现音程跳跃是否合理。最后说一个我自己养成的习惯每次拿到生成结果先跑一遍边界检查——pitch是否在0-127、duration是否为正、velocity是否为0然后用fluidsynth渲染出WAV最后用midi转简谱扫一眼旋律轮廓。这三步走完再谈优化和入库。虽然麻烦但确实帮我避免了好几次把越界音符直接写进游戏配乐项目的尴尬。希望帮到你。本文还有配套的精品资源点击获取