从MusicXML到歌声合成：中文乐谱数据集的预处理与工程实践-育师

简介：本资源是面向歌声合成与音乐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 version="1.0" encoding="UTF-8"?> <!DOCTYPE score-partwise PUBLIC "-//Recordare//DTD MusicXML 3.1 Partwise//EN" "http://www.musicxml.org/dtds/partwise.dtd"> <score-partwise version="3.1"> <part-list> <score-part id="P1"> <part-name>旋律</part-name> </score-part> </part-list> <part id="P1"> <measure number="1"> <attributes> <divisions>24</divisions> <!-- 定义一拍被分成多少份，用于计算音符时长 --> <key> <fifths>0</fifths> <!-- C大调 --> </key> <time> <beats>4</beats> <!-- 每小节4拍 --> <beat-type>4</beat-type> <!-- 以四分音符为一拍 --> </time> <clef> <sign>G</sign> <line>2</line> <!-- 高音谱号 --> </clef> </attributes> <note> <pitch> <step>C</step> <!-- 音名 --> <octave>4</octave> <!-- 音区 --> </pitch> <duration>24</duration> <!-- 持续时长，基于divisions --> <type>quarter</type> <!-- 音符类型：四分音符 --> <lyric> <syllabic>single</syllabic> <text>你</text> <!-- 歌词 --> </lyric> </note> <!-- 更多音符... --> </measure> </part> </score-partwise>

关键标签解析：

<divisions>: 这是理解时值的核心。它定义了“一拍”被等分成多少份。例如<divisions>24</divisions>表示1拍=24个“tick”。后面音符的<duration>值就是基于这个tick数。一个<duration>24</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 ... encoding="UTF-8"?>。如果是GB2312或GBK，后续解析需要指定编码。
格式一致性：是否所有文件都是有效的MusicXML？有没有夹杂其他自定义XML格式或损坏的文件？可以用xmllint命令快速验证。
```
xmllint --noout *.musicxml 2>&1 | 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_bpm=72): """ 解析单个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', encoding='utf-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_ok=True) 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, style=Style.TONE3, neutral_tone_with_five=True) 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_path='filelist.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', encoding='utf-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_dur=0.1, max_dur=2.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(y=y, sr=sr) 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_transcript='transcript.txt'): """ 生成类似DiffSinger所需的转录文件。 格式：音频ID|音素序列|音符序列|时长序列 这里我们先生成一个简化版：音频路径|拼音序列 """ transcripts = [] with open(label_list_file, 'r', encoding='utf-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', encoding='utf-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', encoding='utf-8') as f: f.write('\n'.join(transcripts)) print(f"DiffSinger转录文件已生成，共 {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%以上。一份干净、一致、标注准确的数据集，是项目成功的基石。最后一个小技巧：在解析和处理过程中，务必为每个步骤生成详细的日志和中间文件，这样当出现问题时，你可以快速定位到是哪个文件、哪个环节出了错，而不是从头再来。

本文还有配套的精品资源，点击获取