乐谱文件怎么比：用节奏树图做并行比对的 TSM diff

📄 乐谱文件怎么比：用节奏树图做并行比对的 TSM diff

英文题目：TSM diff: A new Parallel-Tree-Traversal Algorithm for the Comparison of Music Score Files

评分：5.7/10 | 创新 1.2/2 | 技术严谨 1/1.5 | 实验充分 0.6/1.5 | 清晰度 0.7/1 | 影响力 0.5/1.5 | 开源 0.2/1.5 | 可复现 0.3/0.5 | 工程/实践 1.2/1.5

👥 作者与机构

• Xiaobo Wang：机构信息未能从 arXiv PDF 文本可靠映射
• Florent Jacquemard：机构信息未能从 arXiv PDF 文本可靠映射

📌 核心摘要

比较对象是已经编码为 MusicXML 或 MEI 的数字乐谱，困难在于乐谱内容按小节、声部、拍子层级组织，直接比文本会丢失音乐时间结构。论文的处理过程是先把两份乐谱都转成树形乐谱模型（Tree Score Model，TSM），再对两个 TSM 做对齐与并行下降比较，输出差异列表、时间距离与表面距离，归一化后合成相似度。树形乐谱模型把整段音乐时间区间逐层划分，内部分支对应等分或特殊划分，叶子存放音高等基本事件，装饰音与附点等结构用分裂与共享节点表达。比较时先按小节用最长公共子序列（Longest Common Subsequence，LCS）跳过相同小节，再匹配小节内声部，然后递归同时走两个子图，标签分叉处停止并记录一次差异。时间距离累加存在差异的区间时值，表面距离用编辑距离比较与时间无关的记谱属性。与基于非结构化 Music21 数据流的 ScoreDiff 和 MusicDiff 相比，关键差异是用图结构显式编码时值，叶子不再需要时值属性。在爵士标准曲 All the Things You Are 的5位演奏者独奏转录的10组比较中，最小差异情形下 TSM-diff 报告差异数323个、相似度0.359、耗时1.26s，相比同一设置下 MusicDiff 差异数858个、耗时333.40s，差异数与耗时均更低。该结论适用于记谱版本管理与语料去重等比对任务，大规模语料与复杂记谱下的稳定性尚未验证；推理部署开销方面，核心比较耗时为1.7ms至28.3ms、平均约5ms，含Music21解析与TSM构建的总耗时至多约4.2s，原文未披露训练成本。

🔗 开源与复现资源

• 第三方资源：https://tsm-diff-lbd-7a7e2a.gitlab.io — 链接可访问（HTTP 200）

• 第三方资源：https://tsm-diff-lbd-7a7e2a.gitlab.io/demo — 链接可访问（HTTP 200）

可达状态仅表示本次链接检查结果，不代表许可证、本文权重或运行复现已验证。

🧭 深度解读

为什么乐谱比文本难比

这篇论文要解决的输入是数字乐谱文件，典型编码是 MusicXML 或 MEI。目标是像 Unix diff 比较文本那样，指出两份乐谱哪里不同，并给出可解释的差异程度。

文本 diff 可以按行对齐，因为行本身就是自然单位。乐谱没有这种单位：一份乐谱同时包含音高、时值、声部、小节、装饰音、力度和演奏记号等多层信息，而且这些信息按小节、拍、声部组织成层级结构。如果直接比较 XML 标签，很容易把编码格式的差别误判为音乐内容的差别，也难以把延长一个音和插入一个音区分开。

读者需要先建立这个预期：本文的方法不是比较 XML 字符串，而是先把两份乐谱转成同一种抽象图，再在图上对齐时间，最后才报告音乐意义上的差异。能否复述这个两步思路，是理解全文的基础。

与 ScoreDiff 和 MusicDiff 是什么关系

论文明确把自己的工作放在两个已有工具之后：ScoreDiff 及其分支 MusicDiff。这两个工具都基于 Music21 的无结构流表示来比较乐谱内容。

本文最大的改动是换了中间表示：不再用无结构的 Music21 流，而用一种称为 Tree Score Model 的标签有向无环图，灵感来自节奏树。比较算法也随之改变，从基于二次编辑距离计算的思路，转向沿图结构的递归并行遍历。

这种对照很重要：后文实验把 TSM diff 和 MusicDiff 放在一起比较，比较的是同一任务下不同中间表示加不同比对策略的效果，而不是不同任务之间的优劣。论文还提到，这种先比较时间、再比较其他记谱属性的分离做法，与转谱评价中主张的分离惩罚原则是一致的。

输入是什么，输出是哪三样东西

方法的输入是两份乐谱文件，经过转换后变成两张 TSM 有向无环图。输出是联合计算的三样结果。

第一是差异列表，每条差异包含两张图中参与比对的节点，以及这些节点对应的时间区间。每份乐谱对应零个、一个或多个节点，多个节点的情况出现在遇到共享节点需要重新同步时，目的是让每条差异在两份乐谱中覆盖相同的时间区间。报告给用户的主要信息是节点标签和时间区间，还可以附一个差异代码帮助解释含义，例如插入、删除、碎化与合并、替换等。

第二是时间距离，即两份乐谱出现差异的时间区间的累计时长。第三是表面距离，即与时间无关的记谱属性的编辑距离。后两个度量经过归一化再合并成乐谱之间的相似度。理解这三者的分工很关键：时间距离回答差了多长，表面距离回答记谱细节差了多少，差异列表回答具体差在哪里。

整体流程：先转图，再分层比对

整个处理可以沿一份样本这样走：原始 MusicXML 或 MEI 文件先用 Music21 做解析，再转成 TSM 图；两张图先按小节对齐，再对不同小节内的声部做匹配，最后对两个声部的内容做递归并行下行。

第一步是小节级对齐，用最长公共子序列算法找出相同的小节并跳过，只留下不同的小节继续处理。第二步是在有差异的小节内部匹配声部，用一个专用算法完成。第三步是核心的声部内容比较，同时从两张子图的根节点向下走，只要标签一致就继续，一旦标签分叉就停下。

停下时要做三件事：向差异列表加一条新差异，把相关区间的时长加入时间距离，把这些节点下方叶子中与时间无关的属性序列之间的编辑距离加入表面距离。如果匹配节点带有注释列表，还会比较注释列表并产生新的插入、删除或替换操作。这种先对齐大结构、再深入细节的顺序，是该方法效率和可解释性的来源。

TSM 图里节点和时间区间如何对应

TSM 图的每个节点都对应一个时间区间。叶子节点标注为基本事件，例如音符、休止符等；内部节点标注为函数，负责把一个时间区间关联到若干子区间，每个子节点对应其中一个。换句话说，每次分叉都对应一次音乐时间区间的划分。

论文用波兰舞曲 BWV Anh II 128 的单声部缩减谱中两个四分之三拍小节为例。根函数 bar 把覆盖全段的顶部时间区间分成两个小节区间；函数 fork 把同一段时间复制成若干并发的同等时长声部，例子中为简单起见只考虑一个声部；函数 div2 和 div3 把一个区间等分成两份或三份，对应按拍号把小节内容规则划分为拍、子拍等，也能表示第二小节中十六分音符三连音那样的不规则划分。

Tree Score Model × 有向无环图： Tree Score Model 是本文的中间表示，有向无环图是它的实现形式：节点表示音符等基本事件或划分时间区间的函数，边表示区间包含关系，二者结合后，时值不再写成音符属性，而是直接由图的分叉结构编码，比对时只要沿结构并行下行就能先对齐时间。

另一个例子是第二小节末尾的 deco 函数，它把跨越最后一拍的区间拆成空区间和有音区间，分别对应由单个倚音组成的装饰和被装饰的音。由于时值已经由图结构本身编码，叶子节点不需要记录音符时值之类的时长属性，例子中音符叶子的唯一属性是音高。力度、 articulation、延长记号、装饰等记谱信息可以附加到节点上，而不改变其时间区间。

共享节点与附点时值是怎么表示的

初学者容易疑惑：图里为什么一个节点可以有两个父节点。论文给了一个具体例子：第一小节最后一个标注为 D5 的节点，同时被它的父节点和祖父节点共享，这两个祖先都标注为 div2。

它的含义是把两个祖先节点各自第二个孩子对应的区间相加：一个是十六分音符的时长，另一个是八分音符的时长，相加后得到附点八分音符的效果。原文用区间并的方式写出这种相加，说明共享节点就是为了表示这种跨层级的时值延长。

div2 × div3： div2 和 div3 都是把一个时间区间等分成若干子区间的内节点函数，div2 分成两份，div3 分成三份，它们分工表示常规节拍划分与三连音等特殊划分，组合起来就能解释一小节内各拍时长如何分配，节奏变化也表现为这类节点的替换。

理解这一点后就能明白，TSM 不是树而是有向无环图的原因正在于此：普通树不允许节点共享，无法紧凑表示附点这类需要合并多个结构区间的时值。共享节点在比对时也有特殊作用，后文比对遇到共享节点时需要重新同步，以保证差异覆盖的时间区间一致。

小节对齐和声部匹配解决什么困难

两份乐谱即使整体相似，也可能在局部插入或删除小节。如果直接从头逐音符比对，一处插入会导致后面全部错位。本文先做小节级最长公共子序列对齐，就是为了解决这种大范围错位：相同的整小节直接对齐跳过，只有不同的小节才进入更细的比较。

fork × bar： bar 负责把整段音乐时间切成小节区间，fork 负责把同一段时间复制成若干并行的声部，二者搭配先解决乐谱的纵向结构问题：先按小节对齐，再在小节内按声部匹配，之后才进入每个声部内部的节奏细节比对。

进入有差异的小节后，还要解决声部对应问题：多声部乐谱中不能随意把第一声部和第二声部混在一起比。论文用专用算法先匹配声部，再比较声部内容。这种分层处理把问题规模逐层缩小，也让差异定位更准确：用户能知道差异发生在哪个小节、哪个声部，而不是得到一串脱离位置的音符编辑操作。

并行下行在什么时候停下并记什么

声部内容的比较是同时沿两张子图向下走的递归过程。标签一致就继续深入，标签分叉就停止并记录。论文用图 1 第二小节与其变体图 2 的比较说明了三次停止，每次停在不同拍上。

第一拍中，一边是 div3 节点，另一边是 div2 节点，产生节奏变化差异，对应两个划分节点的替换操作，时间距离增加两个八分音符的量，表面距离增加与删除 F5 相关的量。第二拍是碎化，即单个 E5 音符被多个音符替换但总时长保持不变。第三拍是 deco 与 div2 的配对，对应装饰倚音 D5 的删除，此时还会继续进入 deco 的右孩子 C5 递归，但没有发现其他差异。

时间距离 × 表面距离： 时间距离累计双方出现差异的时间区间的总时长，表面距离用编辑距离累计与时间无关的记谱属性差异，前者先通过结构分叉是否一致来判定，后者只在时间结构对齐后再比较叶子节点的属性序列，二者归一化后合并为相似度，实现了时间与记谱层面的分离计罚。

最长公共子序列 × 并行下行比对： 最长公共子序列负责小节级别的粗对齐，找出两份乐谱中相同的小节并跳过，剩下不同的小节再做声部匹配；并行下行比对负责声部内部的同时递归遍历，一旦节点标签分叉就停下记一条差异，前者解决大范围错位，后者解决局部节奏与音高细节，组合后避免全量二次编辑距离计算。

这里的关键是区分两种距离的更新时机：时间距离在结构分叉时按区间时长累加，表面距离按叶子属性序列的编辑距离累加。论文强调这种先比较时间相关方面、再处理其他方面的做法，并且差异代码是在后处理阶段加上的，与比对算法本身独立，可以按其他音乐学需求修改。

本文没有训练模型，实际计算是什么

这篇论文没有训练神经网络，也没有学习参数、梯度更新或冻结策略。它的实现是用 C++ 写的 TSM 专用库之上的比对程序，再加 Python 绑定和导入函数，用 Music21 工具包解析 XML 并转成 TSM 图。

实际执行的计算是构造与遍历：解析乐谱、建图、按小节做最长公共子序列、匹配声部、递归并行遍历并累计两种距离。论文称该递归并行下行算法具有线性时间复杂度，因此比完全基于二次编辑距离计算的方法更高效稳健。

对研究生而言，要分清三件事：这里没有需要下载的模型权重，没有训练开销，运行成本主要来自解析建图和图遍历。论文报告的核心比对时间与包含解析建图的总时间是分开的，不能只看其中一个就推断整体延迟。

两个演示各测什么，条件是什么

论文用两个演示作为概念验证。第一个演示取自钢琴奏鸣曲的 5 个乐章，每个乐章与其 3 个人工制作的修改版本比较，修改数量递增。第二个演示是爵士标准曲 All the Things You Are 的 5 位不同演奏者的单声部独奏转谱之间的 10 组比较。

测量对象包括差异条数、相似度、耗时，以及与 MusicDiff 的对照。指标方向需要先说清：差异条数越少通常表示两份乐谱越接近，但它受差异粒度定义影响；相似度是归一化合并后的距离，越接近 1 表示越相似；耗时越短越好，但要区分核心比对时间和包含解析建图的总时间。

论文说明完整结果见演示网页，部分结果放在表 1。需要提醒的是，原文表格是演示摘录，不是完整评测，也没有给出统计显著性或多次运行的方差。这些结论仅适用于这些曲目和人工编辑条件，不能推广为所有风格乐谱都如此。

奏鸣曲修改版本上的差异数与耗时对比

第一个演示要回答的问题是：当修改逐渐增多时，TSM diff 能否给出单调合理的差异数和相似度，并且比 MusicDiff 更快更紧凑。该表在同一组乐谱对上分别用 TSM diff 和 MusicDiff 计算，比较差异条数、相似度和总耗时，耗时单位为秒，相似度越高表示越相似。

表后解释如下：随着人工编辑增多，TSM diff 的差异数从 1 增至 19 再到 73 和 304，相似度从 0.999 下降到 0.796，变化方向符合预期。在差异条数上，TSM diff 明显少于 MusicDiff 的 54 和 772，说明其差异粒度更粗、合并更好；在耗时上，DCML2 改动最多的情况下 TSM diff 总耗时为 2.67s，而 MusicDiff 需要 43.94s，差距很大。但在 DCML1 这种改动很小的情况下，两者总耗时接近，TSM diff 并未胜出，这说明优势主要体现在修改较多或结构较复杂的比较中，不能说所有情况下都更快。

更大改动与爵士独奏上的表现及核心耗时

第二个问题是方法在改动更大和演奏差异更大的数据上是否仍稳定，以及核心比对本身到底多快。该表比较 TSM diff 与 MusicDiff 在相同乐谱对上的差异数、相似度和总耗时，并补充核心比对耗时的单独说明，核心耗时单位为毫秒，总耗时单位为秒。

表后解释如下：DCML3 上 TSM diff 的差异数仍约为 MusicDiff 的一半，耗时也明显更低。FiloSax 是更难的情形：不同演奏者的独奏转谱差异很大，相似度只有 0.359 和 0.378 左右，远低于奏鸣曲演示，说明此时两份乐谱在音乐内容上确实分歧大。MusicDiff 在 FiloSax 改动最少时需要 333.40s，改动最多时超过 15 分钟仍未完成，而 TSM diff 总耗时仅 1.26s 和 1.50s。论文还报告所有情况下核心比对时间为 1.7 ms 至 28.3 ms，平均 5 ms，总时间至多约 4.2s，可见总耗时主要来自 Music21 解析与建图，而非核心比对。但也要看到，FiloSax 相似度很低时，差异数本身已很大，此时相似度的区分意义有限，尚未评测的范围包括多声部复杂总谱和更大规模语料。本表数值与单位依据论文 PDF。

碎化与装饰为什么需要特殊处理

论文没有做神经网络意义上的消融实验，但给出了能说明机制的细粒度例子，值得单独讲。碎化指一个音被多个总时长不变的音替换，装饰删除指倚音消失而主体音保留。如果只算音符个数的编辑距离，这两种情况都会被记成大量插入删除，丢失总时长不变这个重要信息。

TSM diff 因为先对齐时间区间，能把碎化识别为同一时间区间内的替换，把装饰删除识别为 deco 节点的左分支消失而右分支继续比对。这种处理依赖图结构编码时值的设计：一旦时间区间对齐，碎化和装饰就不再是错位问题，而是同一区间内的局部替换。

反例是如果两份乐谱的小节划分本身不一致，小节级最长公共子序列可能无法对齐，后续比对也会受影响。论文没有量化这种失败条件的频率，这是复述时要保留的限制：机制例子支持了设计合理性，但不等于证明所有节奏变化都能正确分类。

结论在什么条件下才成立

首先，实验是演示性质的概念验证，曲目限于莫扎特奏鸣曲选段和一首爵士标准曲的独奏转谱，修改版本是人工制作的，样本量小，不能推广为通用乐谱版本管理的精度结论。

其次，耗时结论要分开看：核心比对确实在毫秒级，但端到端总耗时包含 Music21 解析与建图，最大约 4.2s，且随文件大小和编码复杂度变化。把毫秒级核心时间误读为整体运行时间，会高估实际部署速度。

第三，差异代码是后处理阶段任意选择的，可按需求修改，这意味着差异标签本身不是算法正确性的证明。不同研究若修改标签定义，差异数的多少就不再可比。最后，论文未报告误判率、人工评价一致性或大规模语料上的鲁棒性，也未给出内存占用和硬件配置，因此不能从现有数字推出转谱评价或光学乐谱识别评价中一定更好，只能说相似度提供了一种可尝试的评价思路。

复现第一步做什么，需要哪些资源

复现的第一步不是调参，而是跑通转换链路：用 Python 绑定调用 Music21 解析一份 MusicXML 或 MEI，生成 TSM 图并检查小节与声部是否正确，再运行 C++ 核心比对得到差异列表和两种距离。论文提到实现基于 C++ 的 TSM 专用库，Python 部分负责导入转换。

关于资源可用性要谨慎：论文正文给出的是演示网页链接，属于第三方可达链接，证明论文提到了这些页面，不等于作者已开源完整代码库。是否开源、代码能否运行、权重是否提供是三件不同的事，本文不涉及模型权重，代码运行还依赖 Music21 版本和 C++ 编译环境。

建议从论文的简单例子开始：先复现两个四分之三拍小节的图结构，确认 bar、fork、div2、div3 和 deco 的划分，再复现第二小节变体的三次停止，核对节奏变化、碎化和装饰删除 3 类差异。只有这条链路走通，后续的大规模比较才有意义。

什么时候值得尝试，还缺哪项验证

当任务是管理乐谱版本、维护音乐学语料并找出重复或相似乐谱时，这种方法值得尝试，因为它能定位到小节和时间区间，并区分时长差异与记谱细节差异。当任务是评价自动转谱或光学乐谱识别结果与参考谱的差距时，它的相似度也可以作为候选指标，但必须先在目标数据上验证与人工判断的一致性。

还需要补的验证包括：在多声部总谱和不同编码风格上的对齐准确率、在更大语料上的端到端耗时分布、以及差异代码与音乐学家理解的一致性。缺少这些，就只能说演示支持了高效和紧凑的初步判断，不能说该方法已是通用标准。

总结起来，记住三句话：用图结构编码时间是本文的关键选择，并行下行先比时间再比细节是效率来源，所有数字结论目前只在两个小规模演示和给定的软硬件链路下成立。

⚖️ 评分明细

评分属于系统判断，不是论文实验结果；八维数值与总分见页首，原始审计记录保留在后端。

• 评分规则：type-aware-v1

• 评分模型：muse-spark-1.3-contributor

• 评分请求协议：openai_responses

← 返回 2026-10-30 语音/音乐/音频论文速递