Go beep 采样率转换与修改播放速度有什么区别

Go beep 里的“采样率转换”和“修改播放速度”都可能用到 Resampler，但目的不同：采样率转换是把源流适配到另一个播放采样率，目标是让音频按原本的时间关系播放；修改播放速度则是主动改变流被消费的密度，播放时长会随之改变。前者应优先使用 beep.Resample，后者使用 beep.ResampleRatio 或对已有 Resampler 调用 SetRatio。

官方地址：https://pkg.go.dev/github.com/gopxl/beep

判断方法很简单：如果问题来自“源文件和 speaker 的采样率不一致”，用 Resample(quality, old, new, s)；如果需求是“让声音变快或变慢”，用 ResampleRatio(quality, ratio, s)，并把 ratio 当作速度控制量来管理。

先把采样率和播放速度分成两件事

beep.Format 用于描述音频流的格式，其中 SampleRate 表示每秒采样数，NumChannels 表示声道数，Precision 表示每个采样使用的字节数。它们回答的是“这些数据是什么格式”，不是“播放器应该多快消耗它们”。

如果一个 44100 Hz 的源流直接交给只按 48000 Hz 工作的播放设备，播放器会按照自己的节拍读取源数据，可能表现为速度或音高不对。采样率转换会重新组织采样点，让输出流匹配目标播放采样率；它的使用场景是格式适配，而不是给用户做变速特效。

采样率转换应该用 Resample

beep.Resample 接收质量参数、旧采样率、新采样率和源 Streamer，返回一个新的 Resampler。质量参数越高，通常计算成本越高；实时播放可以从较低但可接受的质量开始，离线处理再考虑更高质量。不要把 quality 当作速度倍数。

package main

import (
    "github.com/gopxl/beep"
)

func adaptToSpeaker(source beep.Streamer, sourceRate, speakerRate beep.SampleRate) beep.Streamer {
    // 这里的 old/new 描述格式适配关系，不是播放速度倍数。
    adapted := beep.Resample(3, sourceRate, speakerRate, source)
    // 返回的 Streamer 可继续交给 speaker 或其他 beep 组合器。
    return adapted
}

代码中的 sourceRate 是源数据实际采用的采样率，speakerRate 是播放端期望的采样率。两者都来自格式或设备配置，而不是来自用户拖动的速度滑块。若源流本身已经与播放设备一致，就不应为了“保险”再套一层无意义的重采样。

修改播放速度应该用 ResampleRatio

beep.ResampleRatio 与 Resample 使用同一个重采样器，但把参数换成“旧采样率除以新采样率”的比值。官方文档明确说明：在原播放采样率下使用 ratio 为 2 的 Resampler，会让播放速度变为约两倍。因此这里的 ratio 是效果控制量，不能误读成目标设备的 Hz 数。

package main

import (
    "fmt"

    "github.com/gopxl/beep"
)

func changeSpeed(source beep.Streamer, ratio float64) beep.Streamer {
    // ratio 大于 1 表示提高流的消费密度；小于 1 表示减速。
    fasterOrSlower := beep.ResampleRatio(3, ratio, source)
    // Resampler 仍然实现 beep.Streamer，可继续参与 Seq、Mix 等组合。
    return fasterOrSlower
}

这类变速是基于重采样密度的变速，通常会同时影响播放时长和音高。若产品要求“只改变时长、不改变音高”，那是更高层的变调或时间伸缩问题，不能只把 ratio 当成无音高变化的开关。

需要运行时变速时调用 SetRatio

固定速度可以在创建时调用 ResampleRatio；如果播放过程中要响应滑块、节拍或距离变化，可以保留返回的 *beep.Resampler，再调用 SetRatio 更新比值。文档说明该更新不会给流引入 glitch，但调用方仍要保证对象的并发访问方式符合自己的播放线程模型。

package main

import "github.com/gopxl/beep"

func updateSpeed(resampler *beep.Resampler, ratio float64) error {
    // 业务层先限制 ratio 的范围，避免滑块或外部输入产生异常值。
    if ratio 

上面的片段需要额外导入 fmt；这里把错误处理写在示例中，是为了强调参数边界，不代表 beep 会替调用方完成业务校验。真实播放程序还应处理源流结束、底层输出初始化失败和播放器生命周期。

按需求选择 API

最容易混淆的情况是：为了让 44100 Hz 的源流在 48000 Hz 设备上正常播放，直接把 ratio 写成 48000/44100，再把它当成“加速参数”。这会把格式适配和速度控制混在一起。应先确认设备采样率，再决定是用 Resample 做适配，还是另外叠加 ResampleRatio 做有意的变速。

常见问题

Resample 会不会自动改变播放速度？

它的职责是把源流适配到新采样率。正确使用时，目标是让播放设备按正确的时间关系消费数据；如果把源流直接以错误采样率播放，反而可能出现速度和音高异常。

ratio 应该填 1.25 还是 0.8？

按 beep 的定义，ratio 是旧采样率除以新采样率，官方示例说明 ratio 为 2 会得到约两倍速度。项目中应把“业务速度倍数”和 beep 的 ratio 约定写清楚，并用短音频人工确认方向。

SetRatio 能不能替代 Resample？

不能简单替代。SetRatio 适合在已有 Resampler 上动态调整比值；如果任务是把源流适配到固定的目标采样率，仍应使用 Resample 明确传入 old 和 new。

beep 能不能保证变速后音高不变？

仅使用 ResampleRatio 的基础变速不要这样假设。需要音高保持时，应选择专门的时间伸缩或变调算法，并把它作为独立的音频处理问题评估。

总结来说，采样率转换解决“数据格式与播放设备如何对齐”，播放速度修改解决“流应该被多快消费”。先用 Resample 处理设备边界，再按产品意图决定是否用 ResampleRatio 或 SetRatio 叠加变速，参数含义就不会互相污染。