📄 MusPyExpress: Extending MusPy with Enhanced Expression Text Support

标签：#音乐理解 #Transformer #开源工具 #数据集 #音乐生成

8.7/10 | 创新 1.5/2 | 严谨 1.2/1.5 | 实验 1.3/1.5 | 清晰 0.9/1 | 影响 1.1/1.5 | 开源 1.5/1.5 | 复现 0.4/0.5 | 工程 0.8/1.5

🔥 8.7/10 | 前25% | 文档类型：系统技术报告 | 评分置信度：中 | #音乐理解 | #Transformer | #开源工具 #数据集 | arxiv

👥 作者与机构

第一作者：Phillip Long（Computer Science & Engineering Department, University of California, San Diego） 通讯作者：正文未明确标注 作者列表：Phillip Long、Hao-Wen Dong、Julian McAuley、Zachary Novack（机构：Computer Science & Engineering Department, University of California, San Diego；Department of Performing Arts Technology, University of Michigan, Ann Arbor）

💡 毒舌点评

这项工作的长期价值更可能来自数据结构，而不是当前生成分数。28 类对象、作用域与 spanner 语义把长期被 MIDI 管线丢掉的表达信息送进统一建模接口，大规模 PDMX 统计又证明它不是稀有注释。实验诚实展示可学性和排列敏感性，但还没有主观质量证据。若后续扩展全谱、多传统记谱并建立听评，MusPyExpress 会成为表现力符号音乐的重要基础层。

📌 核心摘要

多数符号音乐建模工具围绕 MIDI 音符事件设计，能够表示音高、时值和力度，却常丢掉 MusicXML 中对演奏至关重要的表达文字：速度术语、渐强、连奏、踏板、排练号、自然语言指示以及跨时段的 spanner。MusPyExpress 扩展 MusPy 的通用 Music/Annotation 数据结构，把常见西方谱面中的 28 类 expression text 变成可解析、可存储和可序列化的 Python 对象，并同时改进 MIDI/WAV 渲染，让局部速度与动态信息真正作用到输出。

作者用 PDMX 验证这不是边缘信息：222820 个 MusicXML 中有 212406 个含表现文本，占 95.33%，总标记超过 3500000 项、平均每曲 20.1 项；随后在含标注轨道上做 3 类能力演示：音符与表现联合生成、表现条件音符生成、从音符预测表现标注。统一的约 20000000 个参数的 Transformer 在 metrical/real time 和 prefix/anticipation 编排下训练，显示表现 token 能参与建模，且稀疏标注任务对序列排列非常敏感。

论文的核心贡献是基础设施和数据层，而不是新的生成主干或主观音乐质量突破；客观 PCE、SC、GC 只衡量统计接近，生成配置也没有全面胜出；real-time 表示截到 60 秒会改变标签分布。MusPyExpress 为表达感知研究打开了统一入口，但现有实验仍局限西方谱面、单轨建模和自动指标。

这项扩展还把表示和播放连接起来：连奏可延长音符到下一音，重音提高力度，渐慢与渐强分别变成局部速度和力度变化；默认映射常数由作者设定且可配置，因此渲染展示的是 1 套明确实现，不是对所有演奏风格的唯一解释。

🔗 开源详情

MusPyExpress 作为 MusPy 的 expressive 分支公开于 https://github.com/salu133445/muspy/tree/expressive。论文还公开引用 PDMX、给出 357749 轨道划分、6 层 8 头的 512 维模型、80000 步训练和硬件信息。仓库可核验解析实现，但模型实验权重与完整复现包是否同步发布需以分支内容为准。

🏗️ 方法概述和架构

数据表示。MusPy 原有 Music 对象可保存布局、元数据、轨道、调号、拍号、速度、音符和小节，却无法系统解析大多数 expression text。MusPyExpress 在通用 Annotation 内增加 28 类 Python 对象，并区分 score-wide 与 track-specific 存储。瞬时 Tempo、Dynamic 等对象记录单个时间点；TempoSpanner、TextSpanner 等同时记录显式持续区间，因而能表示 accelerando、跨音连奏或延伸文字，而不把它们压成普通标签。

请在下图中分开辨认瞬时 Annotation 与跨时段 spanner，并观察它们依附总谱或轨道后如何与音符共同序列化。

图中表现文本被拆成带时间位置、数值或持续区间的对象，而非普通歌词字符串；这种结构支持 prefix 与 anticipation 编排，但结论仍限于论文定义的稀疏表现字段。

解析与序列化。输入是 MusicXML，总谱层结构和每轨表达标记被映射成统一 annotation；之后与 note 事件一起转换为离散 token。作者准备 metrical time 与 real time 2 种时间域，并比较 2 种表达条件注入：prefix 把稀疏 expression 序列集中放在音符序列前，anticipation 则把控制 token 插到即将受影响的事件附近。输出既可还原 MusicXML 层信息，也可供生成模型消费；渲染路径把动态和局部速度应用到 MIDI/WAV。

三项任务。联合生成直接建模 p(n,e)，同时输出音符和表达；表达条件生成建模 p(n|e)，输入表达控制、输出音符；表现标注建模 p(e|n)，输入已有音符、输出速度、力度、奏法等字段。前两项用 PCE、scale consistency、groove consistency 和只对音符计算的 perplexity 评价，第三项按 beat/position/time/value/duration 字段准确率评价。

训练配置。含至少 1 个 annotation 的 357749 条轨道按 80/10/10 分割。所有任务使用相同 decoder-only Transformer：6 层、8 头、隐藏维 512、约 20000000 参数，训练 80000 步。real-time 序列截断为 60 秒，metrical 表示保留拍点结构。最终系统输出表达感知的音符序列或结构化表达标注，而非直接生成带主观演奏评分的音频。

事件编码沿用多轨音乐 Transformer 的元组结构。metrical 版本包含类型、拍、拍内位置、取值、时长与乐器等字段；作者把原音高字段扩展为可容纳 128 个 MIDI 音高和近 700 个表现取值的 value 字段，并增加速度字段。real-time 版本以秒级时间替换拍与位置，便于表达速度变化和延音。2 种版本都保留结构前导事件，模型看到的是统一事件序列而不是原始 XML 树。

prefix 与 anticipation 改变的是控制事件在序列中的位置。前者把全部表现控制放在待生成音符之前，结构简单但需要长距离注意；后者把控制提前到它即将作用的音符附近，局部对齐更短，却必须处理稀疏控制和音符的交织顺序。联合生成时音符与表现都计算后继 token 的损失；条件生成和标注任务会把作为控制一侧的 token 损失置零，只监督目标序列。

训练的最大序列长度为 1024，批量 8，学习率 5×10^-4，Adam 默认参数，1 张 RTX 3090 完成。生成评测每种配置采样 256 条，条件表现序列从测试集随机抽取。标注准确率忽略在单轨表现事件中天然恒定的类型、乐器和速度字段，避免把无需预测的常量算成虚高成绩。

💡 核心创新点

1. 对象层的核心变化，是把 MusicXML 表现文字从深层对象和自由文本中提炼为轻量通用类型。28 类对象涵盖文本、结构控制、音符级标注和通用抽象，并保留 score/track 作用域及瞬时/spanner 时长差异。这样下游模型无需各自重写 MusicXML 解析器，也不必把丰富标记退化为 MIDI 的少数控制事件。

2. 在对象统一之后，基础设施与可学习任务开始闭环。作者没有只发布解析库，而是定义 p(n,e)、p(n|e)、p(e|n) 3 个方向，证明同一结构既能作为生成目标、控制条件，也能作为自动标注输出。它为给大规模“无表现” MIDI 自动补标，以及更细粒度表达条件音乐生成提供了统一接口。

3. 序列建模实验接着比较稀疏控制的放置方式。prefix 对表达标注明显优于 anticipation，尤其 real-time 总准确率为 33.90 对 27.75；结果提示表达 token 很稀疏时，局部提前插入会增加长距离和排序难度。这个发现属于数据表示与训练协议贡献，而不是证明 prefix 在所有控制生成任务都最优。

4. 双时间域与无损 JSON 往返继续补齐工程闭环。节拍时间对速度无关，适合保留谱面结构；秒级时间能直接表示速度变化、延音等实际时长。MusPyExpress 在两者转换时纳入时间相关表现标记，并支持从 JSON 导入导出而不丢失对象字段，使同一份数据可在解析、学习和渲染环节传递。

5. 这套对象体系还保留作用域：排练号与时间相关控制可位于总谱层，力度和具体文字指令可位于轨道层。下游因而能够区分全曲共同控制与单一声部表达，而不是把所有 token 无差别塞进 1 个列表。

📊 实验结果

表现标注表要比较的关键问题是：不同时间表示与 prefix/anticipation 编排对位置、Value、Duration 和完整事件准确率产生何种差异？

联合/条件生成没有单一配置全面支配。metrical joint-prefix 的 note perplexity 最低为 2.64 点，低于 note-only baseline 的 2.80 点，支持表达 token 提供局部信息；但它的 PCE 1.75 距 ground truth 2.68 较远。metrical joint-anticipation 的 PCE 2.72 最接近真值，却有 3.58 perplexity。PDMX 资源统计本身也很重要：在 222820 个 MusicXML 中，212406 个含 expression text，占 95.33%；标记总数超过 3500000 项，平均 20.1 项/曲。

标注总准确率难以只看单个字段。metrical prefix 的位置准确率 93.55%，但 value 和 duration 约为 55%，完整事件同时正确只有 29.41%；baseline 即使位置字段达到 86.34%，完整事件仍接近零。real-time prefix 的位置较低，却因 value 和 duration 较高取得 33.90% 的最好总分，说明不同时间表示改变了错误分布，而非简单地让所有字段一起变好。

生成指标也呈现互换：joint-prefix 的音符困惑度最好，却在音高类别熵上离真值较远；joint-anticipation 的熵最接近真值，困惑度反而更高。尺度一致性和律动一致性同样各有赢家。因而结果证明表现事件可以参与序列学习、prefix 对稀疏标注更有效，但没有确定 1 个在结构、可控性和音乐统计上全面支配的配置。

🔬 细节详述

表达类型难以简单当作统一自然语言标签。TempoSpanner 与 Tempo 的作用区间不同，动态、踏板、连线、排练号和文本指令也分属轨道或全谱。MusPyExpress 用 annotation 包装不同对象，既维持 MusPy 的通用 Music API，又让类型特有字段保留。MusicXML 对自由表达没有严格枚举，所以作者实现的是常见集合，而非穷尽所有厂商或作曲软件写法。

PDMX 分析显示标记间绝对平均距离约 17.21 beats；速度、力度和普通文本可能密集，结构性控制相对稀疏，排练号尤其少。作曲家统计观察到浪漫主义作品比巴洛克、古典作品包含更多显式表达标记，但这是数据描述，应避免扩张为跨版本的历史因果结论。训练子集按“轨道含至少一项标注”筛选，会改变无标注音乐的分布。

生成评估中的 PCE、SC、GC 只比较音高熵、调式一致性和律动统计与 ground truth 的接近度；统计量更接近 ground truth，并不表示听者会认为演奏更有表现力。perplexity 又只在 note token 上计算，难以单独判断 expression 预测质量。多指标各自最佳落在不同配置，正说明当前模型实验是 capability demonstration，而非确定的最佳建模方案。

real-time 表示截断到 60 秒，长曲后半段表达标记被排除，字段频率和 baseline 都会改变；因此 real-time prefix 的总准确率优势难以完全归因于时间表示。工程上，库公开、对象和训练规模清楚，但跨 MusicXML 生产器兼容性、全谱多轨依赖和真实渲染质量仍需要单独测试。

渲染实现通过可配置数值把谱面文字落到 MIDI/WAV：例如延音连接相邻音符，重音可提高约 1.5 倍力度，延长记号可把速度放慢约 3 倍。默认值是工程选择，不是从演奏数据学习的物理定律。库还可解析与 MusicXML 结构相近的 MuseScore 文件，说明对象层不完全绑定单一扩展名；但跨制谱软件的自由文本兼容仍需逐项测试。

⚖️ 评分理由

• 创新性 (1.5/2)：把 28 类表现文本纳入 MusPy 数据结构，并区分瞬时标记与跨时段标记，使音符、奏法、力度和段落信息能归并为张量，基础设施贡献明确。

• 技术严谨性 (1.2/1.5)：库设计和训练设置较完整，但主要面向西方谱面与 PDMX 子集。

• 实验充分性 (1.3/1.5)：基于 357749 条含标注轨道的资源统计，并以联合生成、条件生成和自动标注 3 类任务验证可建模性；统一实验还采用 6 层 8 头解码器检验事件序列，但所有序列截断为 60 秒且缺少主观听测。

• 清晰度 (0.9/1)：表现文本对象、时间方案和指标口径描述清楚，结论比较克制。

• 影响力 (1.1/1.5)：为表现力符号音乐建模提供可复用数据层，模型收益仍属初步。

• 开源 (1.5/1.5)：作者公开 MusPy expressive 分支及数据接口，核心库可直接核验，但独立模型权重和完整生成资产没有另行交付。

• 可复现性 (0.4/0.5)：公开实现、数据和超参数较齐，60 秒截断影响实验再现口径。

• 工程/实践价值 (0.8/1.5)：库可直接接入既有 MusPy 工作流并把表现文本纳入渲染；模型实验仍缺主观听测与跨谱式部署证据。

🚨 局限与问题

实验仅在含至少 1 个标注的 PDMX 子集和西方谱面表现文本上进行；60 秒截断、稀疏标签和自动指标限制了结论。未来工作才计划自动标注无表现 MIDI 与细粒度文本到音乐生成。

进一步审视

对象集合针对常见西方符号音乐，MusicXML 自由文本、非西方记谱法和不同制谱软件的私有写法可能落在覆盖范围外。实验只建模带 annotation 的单条轨道，不处理完整总谱中的声部互动；real-time 截断 60 秒，训练分布因此偏向曲目前段和较短作品。

自动 PCE、SC、GC 与字段准确率难以证明主观表现力、可演奏性或控制服从。该统一架构规模较小且各指标无全面赢家，未做人类听评或跨库泛化。自动标注普通 MIDI 和细粒度文字到音乐仍是未来计划，不是已经验证的应用。

模型只在至少含一项标注的 357749 条轨道上训练，控制稀疏度与完整 PDMX 明显不同；单轨设置也切断了总谱中声部之间共享的速度、力度和配器关系。标注字段里某些常量被评测排除是合理的，却意味着总准确率难以代表完整 MusicXML 对象的无损重建。

渲染采用手工默认常数把文字映射为速度和力度，尚未依据演奏者、乐器或历史风格校准。表达标记的存在无法保证其语义唯一，诸如自由文本和渐变范围可能依赖上下文。未来若用于自动补标，还需防止模型生成互相冲突或不可演奏的控制序列，并通过听者与乐谱专家评价。

← 返回 2026-08-25 语音/音乐/音频论文速递