Go go-mp3 怎样从可定位输入跳到PCM字节位置

Go go-mp3 的定位对象不是 MP3 文件里的压缩帧偏移，而是解码器暴露出来的 PCM 字节流。要从某个 sample 开始读取，输入必须同时满足 io.Reader 和 io.Seeker；偏移则按解码后的 16 位小端双声道数据计算，完整 sample 需要 4 个字节。

官方地址：https://pkg.go.dev/github.com/hajimehoshi/go-mp3

先把定位对象理解成解码后的 PCM 流

go-mp3 的 Decoder 会按需解码底层来源。官方文档规定，输出始终是 16 位小端、双声道，即使原始 MP3 是单声道，也会按双声道格式暴露。因此一个 sample 的字节数是 2 字节 × 2 声道 = 4 字节。

这决定了 Seek 的 offset 应该按 PCM 位置理解。例如要跳到第 44100 个 sample，可以先计算 44100 * 4，再以 io.SeekStart 传给解码器。这个数字不是 MP3 压缩帧在文件中的物理位置，库内部会根据已经建立的帧信息找到对应的解码位置。

用可定位输入创建 Decoder

最直接的可定位输入是 *os.File。它既能作为 io.Reader 提供 MP3 数据，也实现了 io.Seeker。创建解码器后，先检查 NewDecoder 的错误，再读取长度和采样率；示例中的代码路径只展示调用关系，不把示例输出描述成已经运行的结果。

package main

import (
	"fmt"
	"io"
	"os"

	"github.com/hajimehoshi/go-mp3"
)

func openDecoder(path string) (*mp3.Decoder, func() error, error) {
	// 文件同时满足 io.Reader 和 io.Seeker，后续才有条件调用 Decoder.Seek。
	f, err := os.Open(path)
	if err != nil {
		return nil, nil, fmt.Errorf("打开 MP3：%w", err)
	}

	d, err := mp3.NewDecoder(f)
	if err != nil {
		// 创建失败时立即关闭文件，避免把坏输入留下为打开句柄。
		_ = f.Close()
		return nil, nil, fmt.Errorf("创建解码器：%w", err)
	}

	closeFn := func() error {
		// Decoder 不替调用方管理 os.File，文件生命周期仍由调用方负责。
		return f.Close()
	}
	_ = io.SeekStart // 让示例明确后续定位使用标准库的起点常量。
	return d, closeFn, nil
}

这里把关闭动作作为函数返回，是为了让调用方在完成所有读取后显式执行。实际项目也可以直接在打开文件后使用 defer f.Close()；关键不在关闭写法，而在于不要用只实现 io.Reader 的流去期待随机定位。

把时间或 sample 换算成4字节对齐偏移

如果需求来自时间点，先用采样率把秒数换成 sample 序号，再乘以 4。比如采样率为 SampleRate()，想跳到第 sampleIndex 个 sample，就使用：

func seekToSample(d *mp3.Decoder, sampleIndex int64) error {
	const bytesPerSample = int64(4) // 16位小端 × 双声道，每个 sample 占4字节。
	if sampleIndex 

不要把任意字节数直接传入 Seek 后再假设读到的是完整 sample。官方说明允许按字节定位，但完整 sample 的偏移应能被 4 整除；否则下一次 Read 可能从左右声道或 16 位样本的中间开始，调用方就必须自己承担重新拼接的复杂性。

处理不可定位和跳转后的读取边界

创建解码器时，Length() 会尽量计算解码后 PCM 总字节数；如果底层输入不是 io.Seeker，它会返回 -1。这不是“音频长度为负数”，而是当前输入无法提供可定位的总长度。对于网络流、管道或一次性读取器，应改成顺序消费，或者先落盘再用文件创建解码器。

func readFromSample(d *mp3.Decoder, sampleIndex int64, buf []byte) (int, error) {
	const bytesPerSample = int64(4) // 保持16位双声道 sample 的完整边界。
	if _, err := d.Seek(sampleIndex*bytesPerSample, io.SeekStart); err != nil {
		return 0, fmt.Errorf("跳到 sample：%w", err)
	}

	// Read 从新的 PCM 位置继续取数据；io.EOF 仍应交给调用方判断。
	n, err := d.Read(buf)
	if err != nil && err != io.EOF {
		return n, fmt.Errorf("读取 PCM：%w", err)
	}
	return n, err
}

一个实用判断清单是：输入是否实现了 io.Seeker；Length() 是否为 -1；目标偏移是否按 4 字节对齐；跳转后的缓冲区是否按 Read 的实际字节数处理；文件是否在最后一次读取后关闭。Seek 的返回值是新的 PCM 字节位置，适合保存为当前游标，但不要把它误解释成源 MP3 文件的偏移。

常见问题

为什么用 bytes.Buffer 创建 Decoder 后 Length 是 -1？

如果传入的对象没有实现 io.Seeker，go-mp3 无法建立完整的可定位帧信息，Length() 返回 -1 是预期边界。需要跳转时，先把输入保存为文件或使用其他可定位读取器。

Seek 的 offset 是 MP3 文件偏移吗？

不是。它是 Decoder 对外暴露的解码后 PCM 字节位置；MP3 压缩帧的物理位置由库内部处理。

为什么推荐偏移量除以4？

因为该 Decoder 输出 16 位、双声道 PCM，一个 sample 固定占 4 字节。按 4 对齐能让定位从完整 sample 开始，避免半个样本或单侧声道的边界问题。