简介本资源是面向歌声合成与音乐AI研究者的中文乐谱数据集专为深度学习模型训练提供结构化乐谱输入解决旋律建模、音高节奏对齐及跨模态歌声生成中的数据瓶颈问题。压缩包共172个纯XML格式乐谱文件总大小仅1.05MB轻量高效每个XML文件完整编码音符序列、节拍、调号、力度及歌词位置等关键音乐要素可直接用于RNN、Transformer等序列建模任务的预处理与特征提取。已有537人学习下载适用于高校科研、AI音乐创业项目及课程实践中的歌声合成系统开发。用户可直接加载解析XML结构构建乐谱到频谱/波形的端到端映射 pipeline或结合MIDI转换工具拓展训练数据亦可支撑音乐信息检索、情感分析等下游任务的基线实验。1. 项目概述一份被低估的中文歌声合成“原料”最近在整理硬盘时翻出了一个老文件名字叫“中文乐谱数据集内含几百首乐谱格式为xml可以作为歌声合成的数据集.zip”。说实话第一眼看到这个标题我内心是有点惊喜又有点怀疑的。惊喜在于对于做歌声合成Singing Voice Synthesis, SVS或者音乐信息检索MIR的朋友来说高质量、成规模、结构化的中文乐谱数据一直是稀缺资源。怀疑则是因为网络上打着“数据集”旗号的压缩包太多了质量参差不齐很多只是文件的简单堆砌缺乏统一的规范和可用的标注。这个数据集的核心价值就在于它提供了几百首以XML格式存储的中文歌曲乐谱。XML格式意味着乐谱是机器可读的它不像一张扫描的图片如PDF或JPG那样需要复杂的OCR和乐符识别算法才能提取信息。在XML文件中音符的时值、音高、歌词、小节线、调号、拍号等信息都以结构化的标签和属性明文存储。这简直就是为歌声合成、自动伴奏生成、音乐分析等任务量身定做的“原料”。它适合谁呢如果你是歌声合成研究者或开发者正在训练或微调如DiffSinger、VISinger等SVS模型急需带精确时间对齐的“歌词-音符”配对数据。音乐科技爱好者想自己动手做一个简单的AI唱歌应用或者进行音乐风格转换、自动编曲的实验。计算机音乐或MIR方向的学生需要真实数据来完成课程项目或毕业论文进行如旋律提取、和弦识别、音乐结构分析等研究。数字音乐教育应用开发者需要乐谱数据来开发智能乐谱跟随、自动评测等工具。这个数据集就像一个未经雕琢的璞玉直接使用可能会遇到编码、格式不一、质量存疑等问题但经过适当的清洗、解析和预处理后它能释放出巨大的能量。接下来我将详细拆解如何“盘活”这个数据集从解压探索到最终转化为可用的训练数据分享我踩过的坑和总结的经验。2. 数据集初探与内部结构解析拿到一个未知的数据集第一步绝不是盲目地写代码。先花点时间进行“人工侦察”了解它的目录组织、文件格式和内容质量能避免后续很多无用功。2.1 解压与目录结构观察首先解压这个ZIP文件。我建议在一个空目录下操作并使用命令行工具如Linux/Mac的tree命令或Windows下安装tree来快速查看结构。unzip 中文乐谱数据集内含几百首乐谱格式为xml可以作为歌声合成的数据集.zip -d chinese_musicxml_dataset cd chinese_musicxml_dataset tree -L 2 # 查看两级目录结构一个理想的数据集可能按歌手、流派或年代分类。但根据这个朴素的文件名我猜测它更可能是一个扁平结构即所有XML文件直接堆放在根目录下或者仅有少数几个文件夹。实际解压后我发现是后者所有XML文件都在一个名为musicxml_scores的文件夹内数量确实有几百个文件名多为歌曲名或数字编号如月亮代表我的心.musicxml、001.xml等。注意立即检查是否有非XML文件如临时文件.DS_Store、Thumbs.db或损坏的压缩包先进行清理。2.2 MusicXML格式深度解读这个数据集使用的.musicxml或.xml后缀极有可能遵循的是MusicXML标准。MusicXML是一种基于XML的开放标准专为交换数字乐谱信息而设计已成为许多专业制谱软件如Finale, Sibelius, MuseScore的通用导出格式。一个典型的MusicXML文件结构如下简化?xml version1.0 encodingUTF-8? !DOCTYPE score-partwise PUBLIC -//Recordare//DTD MusicXML 3.1 Partwise//EN http://www.musicxml.org/dtds/partwise.dtd score-partwise version3.1 part-list score-part idP1 part-name旋律/part-name /score-part /part-list part idP1 measure number1 attributes divisions24/divisions !-- 定义一拍被分成多少份用于计算音符时长 -- key fifths0/fifths !-- C大调 -- /key time beats4/beats !-- 每小节4拍 -- beat-type4/beat-type !-- 以四分音符为一拍 -- /time clef signG/sign line2/line !-- 高音谱号 -- /clef /attributes note pitch stepC/step !-- 音名 -- octave4/octave !-- 音区 -- /pitch duration24/duration !-- 持续时长基于divisions -- typequarter/type !-- 音符类型四分音符 -- lyric syllabicsingle/syllabic text你/text !-- 歌词 -- /lyric /note !-- 更多音符... -- /measure /part /score-partwise关键标签解析divisions: 这是理解时值的核心。它定义了“一拍”被等分成多少份。例如divisions24/divisions表示1拍24个“tick”。后面音符的duration值就是基于这个tick数。一个duration24/duration的音符就正好是一拍。key: 调号。fifths为0表示C大调/Am小调为1表示G大调/Em小调以此类推。time: 拍号。beats每小节拍数beat-type以何种音符为一拍。note: 音符信息容器。pitch: 音高。由step(C,D,E,F,G,A,B)、可选的alter(升降号1为升-1为降)和octave(音区)组成。duration: 以tick为单位的绝对时长。type: 音符类型whole, half, quarter, eighth等是人类可读的时值名称。lyric: 歌词。这是歌声合成的黄金数据text标签内就是对应的歌词文本。一个音符可以对应多个音节通过syllabic标签标识begin, middle, end等这对于中文歌曲处理很重要。2.3 数据质量快速评估在写解析脚本前先手动用文本编辑器或MuseScore软件打开几个不同来源的XML文件检查以下问题编码问题中文歌词是否乱码检查文件头?xml ... encodingUTF-8?。如果是GB2312或GBK后续解析需要指定编码。格式一致性是否所有文件都是有效的MusicXML有没有夹杂其他自定义XML格式或损坏的文件可以用xmllint命令快速验证。xmllint --noout *.musicxml 21 | head -20 # 检查前20个文件的XML语法内容完整性是否每首乐谱都包含旋律声部Part歌词是否齐全是否有大量纯音乐片段音符和歌词的对齐是否准确有时制谱软件导出时多音节字词可能对位不准。元数据缺失MusicXML文件可能缺少歌曲名、歌手、BPM速度信息。这些信息可能藏在movement-title或work标签里也可能完全没有。BPM尤其关键它定义了绝对时间。如果没有我们需要假设一个默认值如72 BPM或从文件中寻找sound tempo.../标签。我的初步评估结果是数据集大部分文件是有效的MusicXML 3.0/3.1格式编码为UTF-8但普遍缺少明确的BPM定义且歌词与音符的对齐质量需要抽样检查。3. 从XML到训练数据完整预处理流水线设计要将这些XML乐谱转化为歌声合成模型如DiffSinger所需的训练数据我们需要一个清晰的预处理流水线。目标输出通常是一个包含多个.lab文件或类似的文本对齐文件的目录以及一个记录了所有音频-标签对关系的元数据文件如train.list。3.1 核心工具链选型Python与music21库解析MusicXML我强烈推荐使用music21这个Python工具包。它是一个功能极其强大的计算机音乐学分析工具库对MusicXML的支持非常友好能帮我们省去大量解析XML树的底层工作。pip install music21为什么选择music21而不是直接使用xml.etree或lxml抽象层级高music21将乐谱元素如音符、小节、声部抽象为Python对象我们可以直接访问note.pitch、note.duration等属性而无需记忆复杂的XPath路径。内置音乐逻辑它能自动计算音符的绝对开始时间以秒为单位只要我们能提供速度BPM。它还能处理连音、休止符、调号转换等复杂音乐现象。社区活跃在音乐信息检索领域应用广泛遇到问题容易找到解决方案。3.2 预处理步骤一解析与时间对齐计算这是最核心的一步。我们需要遍历每个音符获取其音高、起始时间、持续时间和对应的歌词。from music21 import converter, note, tempo import os def parse_musicxml_to_sequence(xml_path, default_bpm72): 解析单个MusicXML文件返回音符序列。 序列中每个元素是一个字典包含起始时间(秒)持续时间(秒)音高(MIDI编号)歌词。 # 加载乐谱 score converter.parse(xml_path) # 1. 寻找速度信息BPM bpm default_bpm for metronome in score.recurse().getElementsByClass(tempo.MetronomeMark): if metronome.number: bpm metronome.number break print(f文件 {os.path.basename(xml_path)} 使用BPM: {bpm}) # 2. 获取主旋律声部这里假设第一个Part是旋律 # 更健壮的做法是寻找包含歌词的Part melody_part score.parts[0] if score.parts else score notes_sequence [] # 3. 遍历所有音符和歌词 # offset是相对于该声部开始的偏移量以拍子计 for element in melody_part.recurse(): if isinstance(element, note.Note) or isinstance(element, note.Rest): # 计算绝对开始时间秒 # music21中offset单位是拍子(quarter length) start_time_beat element.offset start_time_sec (start_time_beat * 60) / bpm # 转换公式秒 (拍子 * 60) / BPM # 计算持续时间秒 duration_beat element.duration.quarterLength duration_sec (duration_beat * 60) / bpm # 获取音高休止符为None pitch_midi element.pitch.midi if isinstance(element, note.Note) else None # 获取歌词一个音符可能对应多个歌词音节 lyric_text if element.lyrics: # 取第一个lyric的文本对于中文通常一个音符对一个字 lyric_text element.lyrics[0].text if element.lyrics[0].text else notes_sequence.append({ start: start_time_sec, dur: duration_sec, pitch: pitch_midi, lyric: lyric_text.strip() }) return notes_sequence, bpm # 测试解析一个文件 seq, bpm parse_musicxml_to_sequence(月亮代表我的心.musicxml) print(f解析出 {len(seq)} 个音符事件。) for i in range(min(5, len(seq))): print(seq[i])关键点与避坑指南BPM的获取很多业余转换的MusicXML文件没有metronome标记。如果找不到必须使用一个合理的默认值如72。你可以尝试从文件名或通过分析音符密度来猜测但最稳妥的方式是人工抽查一批文件确定一个适用于大部分歌曲的全局BPM或者为不同风格快歌/慢歌设置不同默认值。声部识别代码中简单取了第一个Part。但有些乐谱可能包含钢琴伴奏谱旋律声部不一定是第一个。更好的策略是遍历所有Part选择包含歌词最多的那个作为旋律声部。歌词与音符的对齐music21的element.lyrics是一个列表因为一个音符可能对应多个音节如英文单词“hello”配一个八分音符。对于中文通常一字一音但也要处理多音节词如“玻-璃”或装饰音下无歌词的情况。如果lyric_text为空在后续处理中可能需要用特殊符号如SP表示停顿填充。3.3 预处理步骤二生成标准化的标签文件歌声合成模型通常需要特定格式的标签文件。以DiffSinger采用的.lab格式类似HTK标签文件为例每一行代表一个发音单元通常是音素或音节及其起止时间。我们需要将连续的“音符-歌词”序列转换为“时间段-发音内容”序列。对于中文最简单的单元是汉字音节。def sequence_to_lab(notes_sequence, output_lab_path): 将音符序列转换为.lab格式文件。 格式每行 开始时间 结束时间 发音内容 时间单位秒保留3位小数。 with open(output_lab_path, w, encodingutf-8) as f: for note_event in notes_sequence: start note_event[start] end start note_event[dur] lyric note_event[lyric] # 处理无歌词的音符可能是间奏或休止 if not lyric: lyric SP # 静音或停顿标记 # 注意这里直接将汉字作为发音内容。更精细的做法需要做拼音转换如 pypinyin # 例如lyric get_pinyin(lyric) - ni3 f.write(f{start:.3f} {end:.3f} {lyric}\n) # 为每个XML生成对应的.lab文件 dataset_root ./musicxml_scores output_label_dir ./labels os.makedirs(output_label_dir, exist_okTrue) for xml_file in os.listdir(dataset_root): if xml_file.endswith((.musicxml, .xml)): xml_path os.path.join(dataset_root, xml_file) lab_filename os.path.splitext(xml_file)[0] .lab lab_path os.path.join(output_label_dir, lab_filename) try: seq, _ parse_musicxml_to_sequence(xml_path) sequence_to_lab(seq, lab_path) print(f已生成: {lab_path}) except Exception as e: print(f处理文件 {xml_file} 时出错: {e})进阶处理拼音转换直接使用汉字作为发音单元对于某些歌声合成前端可能不够精确。更专业的做法是将汉字转换为带音调的拼音。可以使用pypinyin库。from pypinyin import lazy_pinyin, Style def lyric_to_pinyin(hanzi): 将汉字字符串转换为带数字音调的拼音列表。 # Style.TONE3 返回带数字声调的拼音如 ni3 pinyins lazy_pinyin(hanzi, styleStyle.TONE3, neutral_tone_with_fiveTrue) return pinyins # 在 sequence_to_lab 函数中替换 lyric 处理部分 # lyric note_event[lyric] # if lyric and lyric ! SP: # pinyin_list lyric_to_pinyin(lyric) # # 如果一个汉字对应多个拼音多音字这里需要根据上下文处理是难点。 # # 简单处理取第一个 # lyric pinyin_list[0] if pinyin_list else SP实操心得拼音转换是多音字的重灾区。“音乐”的“乐”和“快乐”的“乐”拼音不同。在歌声合成中多音字唱错会非常明显。对于小数据集手动校对是保证质量最有效但最耗时的方法。对于大数据集可以结合语言模型进行消歧但初期建议先处理无多音字的简单歌词或接受一定错误率。3.4 预处理步骤三构建元数据清单最后我们需要一个文件来告诉训练脚本有哪些数据对可用。假设我们未来会有对应的音频文件.wav放在./wavs目录下且音频文件名与XML文件名不含后缀一致。def generate_metadata_file(label_dir, wav_dir, output_meta_pathfilelist.txt): 生成元数据文件每行格式音频文件路径|标签文件路径|其他信息如音高范围 meta_lines [] for lab_file in os.listdir(label_dir): if lab_file.endswith(.lab): base_name os.path.splitext(lab_file)[0] wav_path os.path.join(wav_dir, base_name .wav) lab_path os.path.join(label_dir, lab_file) # 检查对应的音频文件是否存在如果已有 if os.path.exists(wav_path): # 可以在这里添加一些歌曲级的信息例如估算的音高范围 # 这里先简单写路径 meta_lines.append(f{wav_path}|{lab_path}) else: # 如果没有音频说明我们只处理了标签部分可以只记录标签路径或标记出来 print(f警告: 未找到 {wav_path}跳过。) with open(output_meta_path, w, encodingutf-8) as f: f.write(\n.join(meta_lines)) print(f元数据文件已生成: {output_meta_path}, 共 {len(meta_lines)} 条记录。) # 假设音频还未就绪我们先生成一个只有标签路径的列表用于后续与音频配对 generate_metadata_file(./labels, ./wavs, label_list.txt)至此我们已经将原始的XML乐谱数据集转化为了结构化的、机器可读的标签文件.lab和元数据清单为后续的歌声合成模型训练准备好了“文本端”的数据。4. 数据质量提升与常见问题修复原始数据直接转换后往往不能直接用于训练需要经过一系列的质量检查和清洗。以下是几个最常见的问题及其解决方案。4.1 问题一歌词与音符时间对齐错位现象在生成的.lab文件中可能出现一个字的时长极短如0.05秒或极长数秒或者多个字挤在一个很短的时间内。这通常是因为原始MusicXML文件中歌词文本被错误地绑定到了装饰音、倚音或者制谱时歌词输入的位置不精确。排查与修复可视化检查用music21的show(text)方法将乐谱以文本形式打印出来观察歌词在音符下方的位置。score converter.parse(problem_file) score.show(text)统计分析与过滤计算每个音符事件的持续时间分布。删除或修正那些时长明显超出合理范围如中文单字发音通常介于0.2秒到1秒之间的记录。def filter_abnormal_notes(notes_sequence, min_dur0.1, max_dur2.0): 过滤掉时长异常的音符。对于过长的音符可以考虑按字均分需谨慎。 filtered_seq [] for note in notes_sequence: if min_dur note[dur] max_dur: filtered_seq.append(note) elif note[dur] max_dur and note[lyric]: # 对于超长音符且有歌词的情况警告并可能按字数分割假设歌词无空格 print(f警告: 超长音符 {note[lyric]} 时长 {note[dur]:.2f}s) # 简单处理直接截断到最大时长会影响节奏 note[dur] max_dur filtered_seq.append(note) # 对于过短且有歌词的音符可能是装饰音考虑合并到前一个或后一个音符复杂操作 return filtered_seq手动修正对于问题严重的文件最可靠的方法是使用MuseScore软件打开原始的MusicXML文件直观地检查并修正歌词对齐然后重新导出。虽然耗时但对于构建高质量核心数据集是必要的。4.2 问题二音高Pitch信息异常现象解析出的MIDI音高值超出人声合理范围通常男声E2~C5女声A2~C6或者出现大量不合理的跳变。原因与处理移调问题乐谱可能记录的是适合乐器演奏的调而非人声原调。MusicXML中的transpose标签可能未被正确解析。music21通常能处理移调但需确认score.parts[0].flat.notes得到的音高是实际音高。音区错误检查clef谱号。如果是低音谱号音高解读会完全不同。我们的解析脚本默认寻找高音谱号声部如果旋律写在低音谱号上需要特殊处理。修复策略统计整个数据集的音高分布直方图。如果整体音域偏高或偏低可以考虑对所有音高进行全局平移Transpose。但要注意移调会改变歌曲的调性可能影响和声感觉。对于歌声合成更常见的做法是在数据预处理时将音高规范化为一个相对音高或音高轮廓特征而非绝对MIDI音高。4.3 问题三缺失关键元数据BPM、歌曲名现象所有歌曲都用同一个默认BPM导致快歌慢歌的绝对时长计算全部错误。解决方案外部元数据文件创建一个单独的CSV或JSON文件手动或半自动地为每首歌曲添加BPM和歌曲名。filename,bpm,song_name,singer 001.musicxml,72,示例歌曲1,未知 002.musicxml,108,快歌示例,未知在解析时先查找这个元数据文件如果找不到对应条目再使用默认值。基于音频估计如果你已经拥有对应的演唱音频.wav那么可以使用音频处理库如librosa从音频中直接估计BPM这比乐谱中的标记更准确。import librosa y, sr librosa.load(audio_path) tempo, _ librosa.beat.beat_track(yy, srsr) print(f估计BPM: {tempo[0]:.0f})启发式规则根据歌曲风格文件名可能包含线索如“快”、“慢”、“摇滚”、“ ballad”或音符密度设定不同的默认BPM。4.4 问题四数据集划分与平衡现象几百首歌曲风格、音高、歌手单一导致训练出的模型泛化能力差。处理建议风格分类人工或基于关键词对歌曲进行粗略分类如流行、民谣、儿歌、红歌。划分数据集按照8:1:1的比例随机划分训练集、验证集和测试集。务必确保同一首歌的不同片段如果你后续会切割音频必须放在同一个集合中防止数据泄露。数据增强对于歌声合成在音频-标签配对的前提下可以对音频进行小幅度的音高平移Pitch Shift、时间拉伸Time Stretch来模拟不同歌手或唱法从而在不增加新数据的情况下扩充数据集。但需同步修改标签文件中的音高和时间信息保持对齐。5. 与歌声合成Pipeline的对接实践预处理好的标签数据最终要输入到歌声合成模型中。这里以业界常用的DiffSinger和VISinger的预处理流程为例说明对接方式。5.1 生成DiffSinger所需的训练文件DiffSinger通常需要两种文件转录文件 (transcription.txt)记录了所有训练样本的路径和音素级对齐信息。时长文件 (durations)由强制对齐工具如MFA生成或由模型在训练中预测。我们的.lab文件汉字或拼音可以作为前端文本处理模块的输入。DiffSinger的前端会将这些文本转换为音素序列例如通过一个中文G2P模块将拼音转为音素ni3 - n i3。因此我们需要将.lab文件进一步处理成DiffSinger接受的初始转录格式。假设我们已经有了对应的音频片段例如将每首歌切割成10秒左右的片段并重命名为{song_id}_{segment_id}.wav。def prepare_diffsinger_transcript(label_list_file, audio_dir, output_transcripttranscript.txt): 生成类似DiffSinger所需的转录文件。 格式音频ID|音素序列|音符序列|时长序列 这里我们先生成一个简化版音频路径|拼音序列 transcripts [] with open(label_list_file, r, encodingutf-8) as f: for line in f: lab_path line.strip() # 假设label_list_file每行只有lab路径 base_name os.path.splitext(os.path.basename(lab_path))[0] audio_path os.path.join(audio_dir, base_name .wav) if not os.path.exists(audio_path): continue # 读取.lab文件获取拼音序列 pinyin_seq [] with open(lab_path, r, encodingutf-8) as lab_f: for lab_line in lab_f: _, _, lyric lab_line.strip().split() if lyric ! SP: # 假设lyric已经是拼音如之前处理过 pinyin_seq.append(lyric) # 用空格连接拼音序列 pinyin_str .join(pinyin_seq) # 简化版只写音频路径和拼音 # 实际DiffSinger需要更复杂的格式包括音符、时长等 transcripts.append(f{audio_path}|{pinyin_str}) with open(output_transcript, w, encodingutf-8) as f: f.write(\n.join(transcripts)) print(fDiffSinger转录文件已生成共 {len(transcripts)} 条。)关键点真实的DiffSinger配置需要更复杂的对齐信息音素时长、音符音高和时长。这通常需要通过Montreal Forced Aligner (MFA)这样的工具使用音频和文本转录进行强制对齐来获得。我们的.lab文件为MFA提供了词级或字级的粗略时间边界这能极大提升MFA对齐的准确性和速度。5.2 数据格式的最终检查清单在将数据送入训练前进行最终检查[ ]音频与标签匹配随机抽查10个样本用音频播放器如Audacity加载音频和对应的.lab文件听辨歌词开始和结束时间是否对齐。[ ]标签格式检查.lab文件是否有空行、时间戳是否单调递增、结束时间是否大于开始时间。[ ]覆盖范围确保训练集、验证集、测试集覆盖了不同的歌曲、不同的音高范围。[ ]异常值检查是否有异常长的静音段SP、异常高的音高、或者乱码歌词。5.3 扩展应用不止于歌声合成这份结构化的乐谱数据其用途远不止歌声合成音乐信息检索(MIR)可以直接用于训练旋律提取、和弦识别、音乐分类模型。自动伴奏生成利用和弦和旋律信息可以训练模型生成钢琴或吉他伴奏。乐谱OCR评估作为Ground Truth用于评估从扫描版乐谱图片识别出MusicXML的算法的精度。音乐教育工具开发交互式乐谱学习应用实时高亮当前演奏的音符和歌词。处理这个数据集的过程本质上是一个数据工程项目将非结构化的、杂乱的原始数据通过清洗、解析、转换和标准化变为可用于机器学习的高质量燃料。其中最大的挑战不是代码编写而是对数据本身的理解、对领域知识音乐理论的把握以及处理各种边缘情况的耐心。我个人的体会是在开始任何模型训练之前花在数据准备上的时间至少应该占到整个项目周期的50%以上。一份干净、一致、标注准确的数据集是项目成功的基石。最后一个小技巧在解析和处理过程中务必为每个步骤生成详细的日志和中间文件这样当出现问题时你可以快速定位到是哪个文件、哪个环节出了错而不是从头再来。本文还有配套的精品资源点击获取