律动踩在拍上

1. ①
   画面早了半秒以上RhythmAnalyzer 通过 TeeAudioProcessor 取样，取的是还没写进 AudioTrack 的 PCM。Media3 1.11.1 的 DefaultAudioTrackBufferSizeProvider 把 PCM 缓冲定死在 500ms（targetPcmBufferDurationUs = 500000，已从依赖的 aar 里核对过），正常播放时这块缓冲一直是满的，再加上设备输出延迟，分析出的结果比耳朵听到的早 0.5–0.8 秒。上一版方案页里的原型分析的是“正在听到”的那一段，所以原型里对得上，App 里对不上。
2. ②
   早多少不固定，偶尔还会恰好对上一拍的长度是 60/BPM 秒。提前量正好接近一拍时（比如 104 BPM 配手机扬声器），看起来只差几十毫秒；换一首速度不同的歌，或者戴上蓝牙耳机，脉冲就落到两拍中间了。ITU-R BT.1359 给的可察觉门限是：声音比画面早 45ms，或比画面晚 125ms。下表算的是画面上的一次反应离最近的拍点有多远，正数表示比拍点晚：

3. ③
   每一拍的变化太小上一轮为了不让整屏闪，几处跟拍的量都压低了。现在能随单拍变化的只剩下表里这些，上面还压着一层 12%–84% 的固定遮罩：

4. ④
   鼓点检测本身没有规律检测只看 0–690Hz 的谱通量，贝斯音符也会触发；不应期是 280ms。遇到“底鼓在正拍、贝斯在反拍”的电子乐，常常会锁到反拍上：仿真用的 128 BPM 电子曲里，56 次检测有 33 次落在反拍。另外检测没有“拍子”的概念，漏一下、多一下都会直接出现在画面上，人眼看不出规律。

1. 1
   每个分析帧带上 pts新增 RhythmAudioSink，它是包住 DefaultAudioSink 的 ForwardingAudioSink。它在 handleBuffer 里拿到每个缓冲的 presentationTimeUs，分析器再按样本数推出每个分析窗口末尾的 pts。
2. 2
   知道“此刻听到哪儿”渲染线程每次调用 getCurrentPositionUs 时，记下（位置、nanoTime、速度）；界面线程按 nanoTime 往后推算。这个位置 ExoPlayer 已经扣掉了 AudioTrack 缓冲和设备上报的延迟。pause、flush 时推算冻结。
3. 3
   排队，播到才用分析帧放进 64 帧（约 2 秒）的环形缓冲，界面每帧取走 pts 不晚于“此刻”的那些。原来的 StateFlow 只保留最新一帧，做不到这一点。段落呼吸（swell）也跟着对齐了，鼓点进来、过门安静下来，不会再提前半秒。
4. 4
   估速度先把最近 8 秒的起拍曲线（低频谱通量 + 0.3×中频谱通量，都按频点数平均，再减去滑动基线）做一次高斯平滑。然后在 60–180 BPM 之间每隔 0.25 BPM 取一个候选，算错开一拍和两拍的自相关，乘上一个偏向 100 BPM 的先验，取峰值后再插值。平滑这一步是仿真里发现的：不平滑的话，30 帧/秒下整数帧的间隔会占便宜，比如 150 BPM 正好 12 帧，会把 76 BPM 的慢歌认成两倍速。
5. 5
   找相位在最近 4 秒里找一组等间隔的位置，让落在上面的起拍最多，越近的拍权重越大。网格每 0.27 秒向测量值靠 35%，拍号保持连续。
6. 6
   判断有没有拍置信度由两部分相乘：一是起拍曲线错开一拍（或两拍，重拍轻拍交替时）后与自己的相关程度；二是相位梳的峰有多突出。置信度到 0.5 以上才按网格起拍。仿真里的氛围曲，置信度始终是 0。
7. 7
   不乱换速度新速度要连续 3 次都比当前好 12% 以上才换；差距在 3% 以内的只做微调。刚锁上的前 6 秒历史还短，换速度的门槛放低一些。
8. 8
   小节首拍每一拍附近的低频起拍强度，按拍号除以 4 的余数分别累加，最重的一组当首拍。四拍一样重（四拍底鼓）的歌没有明显的首拍，这时光环仍然每 4 拍出现一次，但不保证落在第一拍上。
9. 9
   跳转和切歌同一首歌里拖进度条、单曲循环回到开头时，保留速度，1.5 秒后重新对相位。切到另一首则全部清掉，新歌前 4 秒只有段落呼吸。无缝衔接时，分析会先进入下一首：跟踪器从分界那一帧重新开始，界面在播到分界之前继续用旧网格。
10. 10
    没有网格时置信度低的时候，改用对齐过时间的低频起拍，力度减半；连低频起拍也没有，就只剩段落呼吸。

上表来自 node 仿真：用的是内置的合成曲目、App 同款分析参数，提前量 0.53 秒，每首播两遍，统计的是第二遍（包含循环回开头后重新锁定的那几秒）。命中指的是真实拍点 ±60ms 内有一次起拍。

已确认（2026-10-29）