摘要
黑胶轮滑动画里，播放音乐和让人物跟音乐配合，需要不同的处理。本文以当前电脑端工程为例，拆解拍点、打击起音、音量包络和局部节奏的用途：时间信息参与动作重音，RMS 包络影响轨迹基宽，局部拍速与鼓点密度参与预制动作选择。再说明连续转体和跳跃为何需要限制重定时，以及如何用音频采样位置统一画面。配套素材来自实际 C 渲染器，包含原创器乐预览、真实分析图和冻结编排的音量控制变量对照。
1. 问题：换了音乐，动画却像没有换
我做的轮滑项目以黑胶唱片为舞台，人物会滑行、交叉、转体和跳跃。动作库逐渐丰富后，仍收到一个很具体的反馈：不同音乐，动作没有变化。
这类问题如果只靠"声音一大就跳一下"解决，很快会遇到限制：响度持续很高的段落没有明确动作间隔；一个重鼓也不一定足够完成一次跳跃；整首歌平均速度相同，局部打击却可能疏密不同。
因此，我把控制分成三条：时间安排、视觉强弱、动作内容。它们共享音乐时间轴，但不共用同一个"能量大就全部增强"的规则。
2. 数据流：分析与播放各做什么
导入阶段先把音频转换为 16 kHz、单声道 PCM16，分析结果再参与编排。播放阶段根据音频位置查询相应的姿态和绘制参数。
text
音乐文件 → PCM16 音频
├─ 拍点估计 ───────────────┐
├─ 低中频打击起音候选 ────┤
├─ 20 ms RMS 音量包络 ────┤
└─ 局部节奏与音色特征 ────┘
↓
预制动作选择与编排
↓
音频播放采样位置 → 当前动作 / 有限重定时 / 轨迹强弱
↓
C 渲染画面相关实现分布在 pc/importer/analysis.py、pc/importer/planner.py、pc/studio/runtime.py，以及原生工程的 adaptive_motion.c、adaptive_scene.c。下面的参数和代码表达式都来自这些文件。
| 输入 | 主要用途 | 不能直接代表什么 |
|---|---|---|
| 拍点 | 节奏位置、动作占用拍数 | 每一次实际鼓声 |
| 打击起音候选 | 抬脚和动作强调的时间参考 | 分离出的纯鼓音轨 |
| 音量包络 | 轨迹基宽的强弱变化 | 扬声器音量旋钮 |
| 局部拍速与鼓点密度 | 动作复杂度评分 | 音乐流派或主观情绪 |
3. 拍点和鼓点分别提取
拍点是相对规律的节奏网格。当前默认流程使用 Beat This! small0 估计拍点，也允许填写 BPM 和首拍位置。自动分析失败时会提示处理，而不是静默换成一条假定速度的网格。
以 120 BPM 为例，相邻拍点约隔 60 / 120 = 0.5 秒；在 16 kHz 音频里对应 8000 个采样。这个网格适合确定一段动作占几拍，但音乐可以在两拍之间出现鼓声，也可以在某一拍没有明显打击。
所以程序另行计算低中频正谱通量：观察相邻分析窗口中哪些频率成分明显增加，从中找打击起音候选。当前频段为 30～220 Hz、220～3000 Hz，FFT 窗口为 1024 个采样，步长为 80 个采样。
80 个采样对应 5 ms，这是分析步长，不能据此宣称鼓点时间误差只有 5 ms。旋律乐器的突然起音也可能触发候选，弱鼓则可能漏掉；这里没有做鼓源分离。
图中拍点来自原创配乐已有的作曲时间表，鼓点为程序估算。这份素材用于检查分析数据怎样进入编排和画面，不能证明外部歌曲的自动拍点检测准确率。验证模型效果，仍需要对那首外部歌曲单独试听核对。
4. 用 20 ms RMS 包络控制轨迹基宽
音量包络描述声音随时间的局部强弱。当前实现不对整首歌先做峰值或响度归一化，而是将原始 PCM16 幅值除以 32768，再计算短窗口 RMS，也就是均方根幅值。
extract_audio_reactivity 中的核心表达式如下，chunk 是已经缩放到浮点幅值范围的窗口：
python
rms[index] = np.sqrt(np.mean(chunk.astype(np.float64)**2))
dbfs = 20. * np.log10(np.maximum(rms, 1e-12))
envelope = np.rint(255. * np.clip((dbfs + 60.) / 54., 0., 1.)).astype(np.uint8)窗口和输出步长均为 320 个采样，即 20 ms，每秒约 50 个值。每个已存包络点由此前窗口计算；绘制时在相邻包络点之间线性插值，让强弱变化连续。映射将 −60～−6 dBFS 范围压到 0～255；这个数值是绘制控制量，并非声压级。
adaptive_scene.c 查询包络后，轨迹基宽采用下面的原始表达式：
c
float level=loudness_at(t,sample);entry->base=level<0?2.55f:.85f+4.55f*level;level 有有效包络时是 0～1 的强弱量；负值表示缺少包络，走固定基宽。最终线宽还会叠加脚轮接地和压力等因素，不能把每次变化都解释为音量造成。
调低系统扬声器音量并不会重算这条数据。检查响应时，应区分"播放输出变小"和"源文件幅值降低"。
如何隔离验证这一条映射
本期对照选取同一时刻，将源 PCM 振幅乘以 0.12，按当前算法重算包络；拍点、鼓点、整段动作摆放、人物、场景、唱片和轨迹历史全部冻结，再交给同一个渲染器绘制。
这样比较可以观察包络对线条的影响。若直接导入两首不同的歌，拍点、动作、路径和音色都可能改变，就很难判断究竟是哪项输入改变了结果。
5. 动作复杂度由局部拍速和鼓点密度参与计算
音量适合表达线条轻重，但不适合独自决定动作难度。持续音可以很响却没有密集打击；细碎鼓声也可能出现在较轻的段落。
rhythm_complexity 明确不使用音量。它从局部拍点间隔计算拍速，在当前拍前后约一秒的窗口统计打击候选数量，换算成每秒鼓点密度，再计算评分。函数中的核心表达式为：
python
score = float(.72*np.clip((bpm-65.)/110., 0., 1.) + .28*np.clip(density/6., 0., 1.))
level = int(np.searchsorted((.32, .58, .82), score, side="right"))这些系数是本项目的编排规则，不是通用音乐规律。评分分级后，还要结合剩余拍数、动作可用长度和衔接规则选片段；声音明亮程度、起音密度与切分特征也参与动作倾向。
当前动作库有 55 套预制动作，动作内容事先编写。音频分析负责提供选择和时间依据，不会在导入歌曲时训练新的身体运动。自动排出的结果仍需要人试听，避免把复杂度简单理解为"大动作越多越好"。
查看数据时也不能只凭字段名猜意义：当前响应式编排分支里，部分段落的 energy 来源是复杂度评分，不等同于原始音量包络。调参之前，应先沿赋值链确认它究竟表示什么。
6. 有限重定时：卡点不能破坏完整动作
动作安排进时间轴之后，还需要处理重音。当前 reactive_phase 在候选鼓点附近对整套姿态做有限、单调的时间调整，手脚和躯干一起沿原动作进度变化，避免只把某只脚拉向一个时刻。
不过连续转体对角速度很敏感。部分转体片段若逐鼓点调整，会拉长某些朝向、挤短另一些朝向，看起来像在一个角度滞留。因此，编号 17 和 45 的持续转体跳过逐鼓点重定时，保持自身连续变化。
跳跃则保留原有准备和接地压缩的时间结构，只在空中顶点附近允许有限调整。一个重音适合成为动作的强调位置，但不应把蓄力、离地和落地缓冲全部挤到同一瞬间。
7. 音频采样位置统一画面时间
播放时，我让动画使用音频播放的采样位置查询动作，而不是让动画定时器和音乐各自累计时间。
16 kHz 音频播放到第 80000 个采样，对应约第 5 秒。该位置可以同时查询当前动作、相位和包络；暂停或拖动后，再从新位置计算画面。当前电脑预览的音频传输会结合输出回调的播放锚点确定位置。
实际画面通过 WebAssembly Runtime（WebAssembly 执行环境）复用项目的 C 渲染代码，这便于核对相同动作和绘制逻辑。但程序逻辑一致，不代表电脑与设备拥有相同的刷新速度或延迟。
配套 MP4 是连续 14 秒的实际程序离线渲染，使用原曲 2.25～16.25 秒的对应音频，无变速。视频带音轨，GIF 无声；24 FPS 是视频编码参数，不是设备实测帧率。
8. 排错时先查哪一层
我会沿着数据流依次检查，尽量不要同时改几个参数。
- 先核对时间信息。 听拍点网格有没有整体偏移、半速或倍速问题，再查打击候选是否漏检或被旋律起音触发。
- 再查动作安排。 看动作是否占用了足够拍数，有没有因一段完整动作跨过关键位置；不要先用加大幅度掩盖时间错误。
- 检查强弱数据。 确认包络不是全零或长时间饱和，比较源文件幅值，而非只调扬声器旋钮。
- 隔离绘制影响。 固定动作、路径和画面设置，只替换包络；接地状态不同时，不直接归因于音量。
- 最后检查连续播放。 暂停、前拖、回拖后核对同一音乐位置，再看旋转和起落是否被重定时破坏。
这套方案先把"跟着音乐动"拆成可分别检查的输入与输出，再用预制动作组织一版结果。它能减少从空白时间轴开始的工作，自动检测和动作选择仍在继续打磨。下一篇再展开电脑编排台，讲怎样把不合适的段落拖动、试听并重新衔接。
我是阿白，感谢你的观看。