This article is categorized as "Garbage" . It should NEVER be appeared in your search engine's results.一篇很长的PhD毕业论文，所以涉及很多和score following/audio alighment有关的方向/方法/内容，包括别人的和作者自己实现的。
🔗 [[2205.03247] Musical Score Following and Audio Alignment] https://arxiv.org/abs/2205.03247
以及🔗 [TuneApp] https://tuneapp.co/
很长，有待后续补充...先占个位置。
2024年2月补充：
论文阅读烂尾了（原本就是烂尾的，因为根本没时间读完）
挑选一些论文的图片来帮助快速回忆这篇论文有什么关键部分，但由于已经远离这个研究方向太久了，重点内容有可能挑不对/漏掉很多关键东西：
论文结构：
前半部分：介绍市面上的各种主流music score following方法，比如对比了这3种实现方法：
- audio-to-audio
- audio-to-symbolic
- symbolic-to-symbolic
后半部分：在Chapter 9：A Beat Tracking Approach: The TuneApp Conductor这里介绍了作者自己写的工具：TuneApp：🔗 [TuneApp] https://tuneapp.co/
和预想的不一样，本篇论文大部分内容是【综述常见方法】，而非【自己是如何实现某些功能的】
论文里除了TuneApp明确为作者的项目，其余的很多图片是总结/文献综述的内容，所以下面的这些图片未必就是TuneApp/作者 所采用的策略：
用电子显示屏+自动翻页来展示：
从演奏声音（audio）和乐谱（non-audio）两个层面提取特征并进行特征对齐，从而达到music score following的功能：
阅读到这里的一些想法：（注意：论文的前半部分算是背景/研究方法综述，阐述了各种常见方法，阅读到这里的时候似乎还并不知道作者到底最后用了什么方法）
主要是好奇作者写的TuneApp的sheet music feature是什么类型（以及是否要用到ocr），如果是提前准备好了对应的musicXML格式则可能简单很多；但如果用了musicXML/MIDI，如何把它们和乐谱进行对齐也是一个挑战（这部分内容是否是手工制作？）
然后开始读Chapter 9：A Beat Tracking Approach: The TuneApp Conductor
注意：基于musicXML的版本并未放出来（作者说是移动端浏览器延迟严重）：
和我预想的不一样（我原本以为作者会让我们提供MIDI和演奏音频，然后现场对齐MIDI和音频的内容），但现在看来这个TuneApp Conductor就是一个beat tracking工具（而不是music score following工具）：上传一段音频或者MIDI，然后分析并提取音乐的beat（并显示），然后可以根据用户的点击控制playback的快慢。
没找到其他作者写的公开的music score following工具了（原本期待的是一个能实时读取麦克风并对齐PDF乐谱/musicXML乐谱的工具）
作者还写了个基于python的CQT-DTW Score Follower（使用offline或者online的DTW进行对齐），但我简单翻了一下没找到是否引入了可视化乐谱，似乎这只是一个数字化乐谱对齐（大大降低了难度）。但无论如何，online DTW的实现还是挺难的。
