简介这份资源是面向音乐学习者、作曲者与音乐教育者的MusicXML乐谱源文件合集共收录140个文件涵盖94个musicxml、31个xml、14个mxl及1个base64文件压缩包约284KB。MusicXML作为开放标准的乐谱标记语言可被MuseScore、Sibelius、Finale等主流软件读取与编辑方便查看、修改、打印乐谱或生成音轨。从内容预览看既有莫扎特单簧管五重奏、G大调弦乐四重奏等古典作品片段也包含鼓组连音、和弦符号、隐形音符等制谱功能测试文件兼顾经典曲目与格式特性演示。这些文件记录了音符、节奏、力度、乐器指定与分谱等细节可用于分析作品结构、编排练习或作为创作参考。目前已有665人学习下载适合需要标准化乐谱素材的读者按需取用。1. 拿到 140 个 MusicXML 乐谱源文件先别急着解压如果你手头正好有一批 MusicXML 格式的乐谱源文件比如 140 个.musicxml或.xml文件打包在一个.7z压缩包里第一反应可能是“先解压看看里面有什么”。但真正做过乐谱数据处理的人会告诉你解压只是最不重要的一步。MusicXML 是一种基于 XML 的乐谱交换格式它记录的不只是音符还有谱号、调号、拍号、连音线、力度记号、歌词、和弦标记甚至排版信息。140 个文件意味着你可能面对的是 140 首不同风格、不同来源、不同完整度的乐谱它们可能来自不同制谱软件遵循不同版本的 MusicXML schema内部结构差异极大。这批文件能解决的问题很具体批量分析旋律走向、构建乐谱数据集、做自动配器实验、训练符号音乐生成模型或者单纯把纸质谱数字化后做统一管理。适合谁做音乐信息检索的研究生、搞自动作曲的算法工程师、需要批量处理乐谱的音乐科技从业者以及任何想把乐谱当结构化数据来用的人。这一篇不讲空泛概念只讲怎么把这 140 个文件从压缩包变成能跑通分析流程的干净数据。2. MusicXML 文件结构拆解从 score-partwise 到 note 节点2.1 为什么 MusicXML 比 MIDI 更适合做乐谱分析MIDI 记录的是演奏事件音高、力度、时长但它不关心你用的是高音谱号还是低音谱号也不记录连音线怎么画、歌词怎么对齐。MusicXML 不一样它是为“乐谱”本身设计的。一个典型的score-partwise文档里part下面挂measuremeasure里面才是note、backup、forward、direction这些元素。note节点里又有pitch、duration、voice、type、stem、lyric等子节点。这种层级结构让你能精确还原乐谱的视觉和逻辑信息。比如你要做和声分析可以直接读harmony节点要做旋律提取就遍历所有part里的note按voice分组。MIDI 做不到这些因为 MIDI 没有“声部”这个概念也没有调号变化的时间点。所以如果你的目标是乐谱级别的分析MusicXML 是更合适的起点。常见做法是先用 Python 的music21或partitura库把 MusicXML 解析成内部对象再转成音符序列或和弦序列。我一般会先用music21快速看一眼文件能不能正常解析因为有些从 PDF 转出来的 MusicXML 会有非法嵌套或缺失的duration直接读会抛异常。2.2 用 Python 批量解析 140 个文件的最小代码框架假设你已经把.7z解压到了一个目录里面是 140 个.musicxml文件。下面这段代码用music21批量读取并输出每个文件的基本信息调号、拍号、声部数、音符总数。注意music21对文件名和路径比较敏感最好用绝对路径。import os from music21 import converter, stream # 替换成你解压后的实际目录 score_dir /path/to/your/musicxml_folder results [] for fname in os.listdir(score_dir): if not fname.lower().endswith((.musicxml, .xml)): continue fpath os.path.join(score_dir, fname) try: score converter.parse(fpath) # 获取第一个 part 的调号与拍号 key_sig score.parts[0].getElementsByClass(KeySignature) time_sig score.parts[0].getElementsByClass(TimeSignature) key_str key_sig[0].sharps if key_sig else N/A time_str time_sig[0].ratioString if time_sig else N/A note_count len(score.recurse().notes) results.append({ file: fname, parts: len(score.parts), key_sharps: key_str, time_sig: time_str, notes: note_count }) except Exception as e: print(f解析失败: {fname}, 错误: {e}) # 打印前 5 条看看 for r in results[:5]: print(r)这段代码的逻辑很直接遍历目录用converter.parse把每个文件读成stream.Score对象然后从第一个part里提取调号和拍号最后统计所有音符数量。参数说明score.parts[0]取的是第一个声部如果你的文件是总谱第一个声部通常是小提琴或主旋律getElementsByClass是music21的通用查询方法返回一个列表所以取[0]之前要判断是否为空。score.recurse().notes会递归遍历所有层级的音符包括和弦里的音符。如果你只想要单音旋律可以用score.parts[0].flat.notes。注意music21解析大文件时内存占用会比较高140 个文件如果每个都很大建议分批处理每批 20 个处理完手动del score并调用gc.collect()。2.3 处理压缩包时的目录结构与文件命名规范.7z解压后常见的情况是所有文件平铺在一个目录里文件名可能是001.musicxml、002.musicxml也可能是song_title.musicxml。如果文件名是中文或包含空格music21在 Windows 上有时会报编码错误。稳妥的做法是先用脚本把文件名统一成 ASCII 字符加序号同时保留一份映射表。另外有些 MusicXML 文件会附带一个同名的.mxl压缩格式.mxl本质是 zip 包music21也能直接读但如果你用os.listdir过滤后缀记得把.mxl也加进去。我一般会先跑一个file命令或者用 Python 的zipfile检查一下文件头确认没有损坏的压缩包混在里面。140 个文件不算多但手动检查不现实写个循环打印每个文件的os.path.getsize和解析状态能快速定位问题文件。3. 批量转 MIDI 与 CSV把乐谱变成可计算数据3.1 用 music21 批量导出 MIDI 并控制量化精度把 MusicXML 转成 MIDI 是为了后续用深度学习框架处理比如用pretty_midi读成 piano-roll。但直接转会有一个坑MusicXML 里的连音线、装饰音、延音踏板在 MIDI 里表达方式不同如果不做量化导出的 MIDI 会有大量极短音符或重叠音符。下面这段代码在转换时做了三件事先解析再量化到十六分音符最后写出 MIDI。from music21 import converter, stream, tempo def xml_to_midi(xml_path, midi_path, quantize_div4): score converter.parse(xml_path) # 量化到十六分音符quantize_div4 表示以四分音符为 1分成 4 份 score.quantize([16], processOffsetsTrue, processDurationsTrue, inPlaceTrue) # 设置一个统一的 tempo避免 MIDI 速度混乱 mm tempo.MetronomeMark(number120) score.insert(0, mm) score.write(midi, fpmidi_path) # 批量转换 import os xml_dir /path/to/musicxml_folder midi_dir /path/to/midi_output os.makedirs(midi_dir, exist_okTrue) for fname in os.listdir(xml_dir): if fname.lower().endswith((.musicxml, .xml)): xml_path os.path.join(xml_dir, fname) midi_path os.path.join(midi_dir, os.path.splitext(fname)[0] .mid) try: xml_to_midi(xml_path, midi_path) except Exception as e: print(f转换失败: {fname}, {e})逻辑说明quantize方法把音符的起始时间和持续时间对齐到最近的十六分音符网格processOffsets和processDurations分别控制是否调整起始点和时长。参数quantize_div4对应十六分音符如果你要更细的精度可以改成8三十二分音符但太细会导致 MIDI 文件里音符碎片化。tempo.MetronomeMark插入一个统一的 120 BPM是因为很多 MusicXML 文件没有显式速度标记不插入的话music21会默认用 120但有些文件会继承上一个文件的设置导致批量转换时速度不一致。注意score.write(midi)在 Windows 上路径不要有中文否则可能写不出来。3.2 提取音符序列到 CSV 的字段设计与代码如果你要做统计分析比如音高分布、音程跳进、节奏密度把音符导出成 CSV 是最灵活的。字段设计我一般用file_name, part_id, measure_num, offset, pitch_name, midi_pitch, duration, voice, lyric。下面是对应的提取代码。import csv from music21 import converter def extract_notes_to_csv(xml_path, csv_writer, file_name): score converter.parse(xml_path) for part in score.parts: part_id part.id for note in part.recurse().notes: # 获取音符所在的小节号 measure note.getContext(Measure) measure_num measure.number if measure else -1 # 音名和 MIDI 音高 if note.isNote: pitch_name note.nameWithOctave midi_pitch note.pitch.mid elif note.isChord: pitch_name ..join(p.nameWithOctave for p in note.pitches) midi_pitch ..join(str(p.mid) for p in note.pitches) else: continue # 歌词 lyric note.lyric if note.lyric else csv_writer.writerow([ file_name, part_id, measure_num, float(note.offset), pitch_name, midi_pitch, float(note.duration.quarterLength), note.voice, lyric ]) # 主流程 xml_dir /path/to/musicxml_folder csv_path /path/to/output_notes.csv with open(csv_path, w, newline, encodingutf-8) as f: writer csv.writer(f) writer.writerow([file, part, measure, offset, pitch, midi, duration, voice, lyric]) for fname in os.listdir(xml_dir): if fname.lower().endswith((.musicxml, .xml)): try: extract_notes_to_csv(os.path.join(xml_dir, fname), writer, fname) except Exception as e: print(f提取失败: {fname}, {e})这段代码的关键点note.getContext(Measure)能拿到音符所属的小节对象但前提是 MusicXML 里正确标记了measure元素有些非标准文件会缺失。note.offset是相对于所在part的偏移量单位是四分音符。note.duration.quarterLength也是以四分音符为 1。note.voice可能是None在 CSV 里会写成空字符串。如果你要分析复调音乐voice字段很重要因为同一时间可能有多个音符属于不同声部。注意note.isChord的处理和弦会输出多个音高用点号连接后续分析时可能需要拆开。3.3 用 pandas 做初步质量检查缺失值与异常时长导出 CSV 之后别急着跑模型。先用 pandas 做一轮质量检查看看有没有缺失的拍号、异常短的音符、或者某个文件的音符数量明显偏少。下面这段代码输出每个文件的音符数、平均时长、以及是否存在时长为 0 的音符。import pandas as pd df pd.read_csv(/path/to/output_notes.csv) # 按文件分组统计 stats df.groupby(file).agg( note_count(pitch, count), avg_duration(duration, mean), min_duration(duration, min), max_duration(duration, max) ).reset_index() # 找出音符数少于 10 的文件可能是解析失败或空谱 suspicious stats[stats[note_count] 10] print(可疑文件) print(suspicious) # 检查时长为 0 的音符 zero_dur df[df[duration] 0] print(f时长为 0 的音符数量: {len(zero_dur)}) print(zero_dur.head())参数说明groupby(file)按文件名聚合agg里可以放多个统计函数。note_count用pitch列计数因为每个音符至少有一个音高。min_duration为 0 说明有音符时长为零这在 MusicXML 里通常是装饰音或 grace notemusic21会把它们标记为duration0。如果你不想要装饰音可以在提取时加一个判断if note.duration.quarterLength 0: continue。suspicious里如果出现你认识的曲名但音符数很少那多半是文件本身有问题比如只写了前几个小节或者解析时因为 XML 命名空间问题漏掉了内容。4. 避坑与排查140 个文件里最常见的 5 个翻车点4.1 现象解析时报“XML syntax error”原因文件头有 BOM 或非法字符有些 MusicXML 文件是从文本编辑器里保存的开头带了 UTF-8 BOM字节顺序标记music21底层的 lxml 解析器会直接报错。解决方法是先用 Python 读一遍文件去掉 BOM 再写回临时文件或者用codecs模块以utf-8-sig编码打开。更稳妥的做法是在批量解析前统一做一次清洗读入原始字节如果前三个字节是\xef\xbb\xbf就跳过它们然后重新写入。这个坑在 140 个文件里可能只出现两三个但一旦出现就会中断整个循环所以异常捕获一定要写。4.2 现象转 MIDI 后音符全部堆在第一个小节原因缺少 backup 或 forward 导致时间轴错乱MusicXML 里多声部是通过backup和forward元素来调整时间轴的。如果制谱软件导出时漏掉了backupmusic21解析时会把所有声部的音符都按顺序累加结果就是所有音符挤在第一小节。排查方法是打开原始 XML搜索backup标签看看每个measure里是否有成对的backup和forward。如果没有可以在music21里手动调用score.makeMeasures(inPlaceTrue)或者用score.parts[0].flat强制展平。但更好的做法是换一个解析库比如partitura它对时间轴的处理更鲁棒。4.3 现象CSV 里 duration 全是 0原因音符是 grace note 或解析时未展开连音线duration为 0 有两种可能一是装饰音二是连音线tie的第二个音符。music21对连音线的处理是保留两个音符对象但第二个音符的duration可能被设为 0实际时长要合并到第一个音符上。如果你直接统计时长会得到错误结果。解决方法是遍历时检查note.tie如果note.tie.type stop就跳过这个音符把它的时长加到前一个start音符上。或者用score.flat.notes并调用stripTies()方法music21会自动合并连音线。4.4 现象中文歌词变成乱码原因XML 声明编码与实际编码不一致MusicXML 文件头通常有?xml version1.0 encodingUTF-8?但有些文件实际保存成了 GBK 编码导致歌词乱码。排查时用chardet检测文件编码或者直接用二进制模式读入看 XML 声明里的 encoding 是否和实际字节匹配。解决方法是统一转成 UTF-8用open(fpath, rb)读入decode(gbk, errorsignore)再encode(utf-8)写回。注意errorsignore会丢弃无法解码的字符如果歌词很重要建议用errorsreplace并人工检查替换后的问号。4.5 现象批量处理到第 80 个文件时内存溢出原因music21 缓存未释放music21在解析每个文件时会创建大量对象并且默认会缓存一些解析结果。140 个文件如果每个都很大内存会持续增长。解决方法是在循环里显式删除score对象并调用gc.collect()。另外可以设置music21.environment.set(autoDownload, allow)为deny避免它去下载不必要的外部资源。如果还是不够就分批处理每 20 个文件重启一次 Python 进程用 shell 脚本包一层循环。5. 进阶用这批乐谱做旋律相似度检索的一个具体技巧当你把 140 个 MusicXML 都转成了音符序列一个很自然的进阶需求是找出其中旋律相似的曲子。直接比较原始音高序列会受调性影响比如 C 大调和 G 大调的同一段旋律音高数字完全不同。我一般会先做调性归一化再把音符转成音程序列最后用编辑距离或 n-gram 余弦相似度来算。下面这个技巧的核心是只取每个文件的主旋律声部转成相对于第一个音的音程然后截取前 32 个音作为指纹。from music21 import converter, interval def melody_fingerprint(xml_path, max_notes32): score converter.parse(xml_path) # 取第一个 part 的最高声部作为主旋律 part score.parts[0] notes part.flat.notes # 过滤掉和弦只保留单音 melody [n for n in notes if n.isNote] if len(melody) 2: return None # 转成音程序列 intervals [] for i in range(1, min(len(melody), max_notes)): try: iv interval.Interval(melody[i-1].pitch, melody[i].pitch) intervals.append(iv.semitones) except: intervals.append(0) return intervals # 计算两个指纹的余弦相似度 import numpy as np def cosine_sim(a, b): if len(a) ! len(b): # 补齐到相同长度 min_len min(len(a), len(b)) a, b a[:min_len], b[:min_len] a, b np.array(a), np.array(b) if np.linalg.norm(a) 0 or np.linalg.norm(b) 0: return 0.0 return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b)) # 示例比较前两个文件 import os xml_dir /path/to/musicxml_folder files [f for f in os.listdir(xml_dir) if f.lower().endswith((.musicxml, .xml))] fp1 melody_fingerprint(os.path.join(xml_dir, files[0])) fp2 melody_fingerprint(os.path.join(xml_dir, files[1])) if fp1 and fp2: print(f相似度: {cosine_sim(fp1, fp2):.3f})这段代码的逻辑part.flat.notes把声部展平n.isNote过滤掉和弦和休止符。interval.Interval计算两个音之间的半音数正数表示上行负数表示下行。max_notes32限制指纹长度避免长曲子计算量过大。cosine_sim在长度不一致时截断到较短的长度这在实际比较中够用因为旋律的开头往往最具辨识度。注意interval.Interval对同音返回 0对八度返回 12这些都在后续相似度计算中保留。如果你要更鲁棒可以把音程序列转成相对音高轮廓比如只保留上行/下行/保持三种状态再用 Jaccard 相似度。这个技巧我用了很久最大的教训是不要直接比较绝对音高哪怕两个文件都是 C 大调移调后的旋律也会被误判为不相似。另外music21的flat属性会改变音符的 offset如果你需要保留节奏信息就不要用flat而是用recurse().notes并手动按 offset 排序。希望帮到你。本文还有配套的精品资源点击获取