NotaGen技术分享：音乐生成的训练数据构建

1. 引言

1.1 技术背景与问题提出

随着深度学习在序列生成任务中的广泛应用，基于大语言模型（LLM）范式的符号化音乐生成逐渐成为AI艺术创作的重要方向。传统音乐生成方法多依赖于RNN或CNN结构，难以捕捉长距离音符依赖关系，且对复杂作曲风格建模能力有限。近年来，Transformer架构凭借其强大的上下文建模能力，在文本、图像乃至音频生成领域取得突破性进展。

然而，将LLM成功应用于古典音乐生成面临一个核心挑战：高质量、结构化、大规模的训练数据集构建。不同于自然语言文本，音乐具有严格的时序逻辑、和声规则与乐器编配体系，尤其在古典音乐中，这些结构性约束更为显著。因此，如何设计一套系统化的数据预处理流程，将原始乐谱转化为适合LLM学习的token序列，是实现高质量音乐生成的关键前提。

NotaGen正是在此背景下提出的创新方案——它不仅是一个基于LLM范式生成高质量古典符号化音乐的模型，更是一套完整的从数据构建到WebUI交互的端到端系统。本文重点聚焦于其背后的数据工程实践，深入解析训练数据的构建逻辑与关键技术细节。

1.2 核心价值与文章定位

本文属于原理解析类技术文章，旨在揭示NotaGen项目中音乐训练数据的构建机制。我们将回答以下关键问题： - 如何将MIDI/ABC等格式的乐谱统一为可训练的文本序列？ - 音乐语义信息（如时期、作曲家、乐器配置）是如何编码并融入生成过程的？ - 数据预处理过程中如何保持音乐结构完整性？

通过本篇内容，读者将掌握符号化音乐数据构建的核心方法论，并理解其在实际AI音乐生成系统中的工程落地路径。

2. 训练数据构建原理

2.1 符号化音乐表示基础

在进入具体构建流程前，需明确“符号化音乐”（Symbolic Music）的概念。与音频信号不同，符号化音乐以离散事件形式记录音高、节奏、力度、乐器等信息，常见格式包括： -ABC记谱法：轻量级文本格式，适合单声部旋律 -MusicXML：标准交换格式，支持复杂乐谱结构 -MIDI：通用数字接口协议，广泛用于电子音乐

NotaGen选择ABC格式作为中间表示层，原因如下： - 可读性强，便于调试与人工校验 - 支持多声部、调号、拍号、装饰音等基本乐理元素 - 社区有成熟工具链（如abctools,abc2xml）

例如一段贝多芬钢琴奏鸣曲片段的ABC表示如下：

X:1 T:Sonata Pathétique C:Ludwig van Beethoven M:4/4 L:1/8 K:C minor V:1 treble [V:1] z4 | E2 G2 c2 e2 | d2 f2 a2 c'2 | ...

该格式天然具备“文本化”特征，非常适合被LLM直接处理。

2.2 多维度元数据融合策略

单纯将乐谱转为ABC字符串不足以支撑风格可控生成。NotaGen引入了三重元数据嵌入机制，确保模型能根据用户指定的“时期-作曲家-乐器”组合进行定向生成。

元数据编码方式

维度	编码方式	示例
时期	前缀标记	`[PERIOD:Classical]`
作曲家	前缀标记	`[COMPOSER:Mozart]`
乐器	前缀标记	`[INSTRUMENT:Piano]`

最终输入序列构成为：

[PERIOD:Romantic][COMPOSER:Chopin][INSTRUMENT:Keyboard] X:1\nT:Nocturne Op.9 No.2\nK:Eb major\nL:1/8\n...

这种设计使得模型在推理阶段可通过改变前缀实现风格迁移，而无需重新训练。

2.3 分块（Patching）与上下文窗口优化

受限于Transformer的上下文长度限制（通常为2048或4096 tokens），无法将整首交响乐一次性输入模型。NotaGen采用滑动窗口分块策略（Sliding Window Patching）解决此问题。

分块流程

将完整乐谱按小节边界切分为若干段落
每段控制在PATCH_LENGTH（默认512 tokens）以内
添加特殊分隔符[SEP]标识段落边界
在训练时随机采样连续patch作为上下文

例如：

[PATCH_0] ... [SEP] [PATCH_1] ... [SEP] [PATCH_2] ...

提示：PATCH_LENGTH是影响生成质量与速度的关键超参数。较短的patch降低显存需求但削弱长程依赖；较长的patch提升连贯性但增加计算负担。

3. 数据预处理工程实现

3.1 原始数据采集与清洗

NotaGen使用的训练数据来源于多个公开领域的古典音乐数据库，主要包括： -Bach Chorales Dataset-Classical Archives MIDI Collection-Mutopia Project（开放版权乐谱库） -KernScores Repository

清洗步骤

格式标准化：使用music21库将所有MIDI/XML转换为ABC格式
去噪处理：
移除不完整小节
修正异常音符时值
过滤非标准调号（如微分音）
元数据标注：
通过文件路径与标题自动提取作曲家、时期信息
手动补全缺失标签（约5%样本）

清洗后得到约12万首高质量古典音乐作品，覆盖巴洛克至浪漫主义三个主要时期。

3.2 Tokenization 设计

传统NLP tokenizer（如WordPiece）不适合音乐符号。NotaGen自定义了一套音乐感知分词器（Music-Aware Tokenizer），其设计原则如下：

原子单位粒度细：每个音符、休止符、调号均为独立token
保留语法结构：换行符、节拍标记、声部标识均不合并
支持扩展性：预留未来添加表情记号、演奏法的空间

部分token示例：

类型	示例tokens
音符	`C`,`E'`,`G,,`
时值	`_2`,`/4`,`//8`
控制符	`K:C major`,`M:3/4`
特殊标记	`[SEP]`,`[PAD]`

词汇表总大小约为3,200个唯一token，远小于自然语言模型，有利于快速收敛。

3.3 训练样本构造

最终训练样本以(input_ids, labels)对形式组织，采用标准的自回归目标函数。

输入构造示例

假设某段输入为：

[PERIOD:Classical][COMPOSER:Haydn][INSTRUMENT:StringQuartet] X:1\nM:2/4\nK:G major\nV:1\nG>A | B>c | d>e | f>g | [SEP]

对应label为右移一位的目标序列：

[COMPOSER:Haydn][INSTRUMENT:StringQuartet]...f>g | [SEP] <EOS>

注意：period/composer/instrument前缀仅出现在第一个patch，后续patch不再重复，避免信息冗余。

4. 与WebUI系统的协同机制

4.1 推理时数据流还原

当用户在WebUI中选择“浪漫主义-肖邦-键盘”组合时，系统会自动生成对应的prompt前缀，并拼接空乐谱头信息启动生成：

prompt = ( "[PERIOD:Romantic]" "[COMPOSER:Chopin]" "[INSTRUMENT:Keyboard]" "X:1\n" "M:4/4\n" "L:1/8\n" "K:Ab major\n" "V:1\n" )

模型以此为起点逐token生成后续音符序列，直至遇到[SEP]或达到最大长度。

4.2 风格组合有效性验证

为防止无效组合（如“巴赫-摇滚乐队”），系统内置了一个风格兼容性矩阵（Style Compatibility Matrix），本质上是一个查找表：

VALID_COMBINATIONS = { 'Baroque': { 'Bach': ['Keyboard', 'Chamber', 'Orchestra'], 'Vivaldi': ['Chamber', 'Orchestra'] }, 'Romantic': { 'Chopin': ['Keyboard', 'ArtSong'], 'Liszt': ['Keyboard'] } }

该表在启动时加载，用于前端下拉菜单动态更新，确保用户只能选择合法组合。

4.3 输出后处理与格式转换

生成完成后，系统执行以下操作： 1. 提取ABC正文内容 2. 调用abctools验证语法正确性 3. 使用abc2xml生成MusicXML文件 4. 写入/root/NotaGen/outputs/目录并返回下载链接

整个流程完全自动化，保障用户体验一致性。

5. 总结

5.1 技术价值总结

NotaGen的成功不仅体现在生成结果的质量上，更在于其背后严谨的数据工程体系。通过对符号化音乐的结构化解析与元数据融合，实现了真正意义上的“可控生成”。其核心贡献可归纳为三点： -统一表示框架：以ABC为核心媒介，打通多种乐谱格式 -条件生成机制：通过前缀标记实现风格解耦控制 -工程闭环设计：从数据清洗到WebUI交互形成完整链条