Go go-mp3 怎样从MP3读取解码后的PCM字节

将MP3输入交给mp3.NewDecoder，再调用解码器的Read，读出的才是PCM字节。直接读取os.File只能得到压缩文件内容。go-mp3 v0.3.4的输出固定为16位小端双声道，即每个立体声音频帧占4字节；采样率通过SampleRate获取。

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

先区分压缩输入与PCM输出

如果我要给波形统计模块接入一段MP3，我会先明确它需要哪一层数据：文件读取器面对的是压缩输入，统计模块通常需要解码后的振幅样本。这是本文的设计取舍，并非一次实测项目记录。

容易混淆的写法是把文件读进byte切片，然后直接按16位数值解释。切片类型虽然相同，语义却不同。加入Decoder不是新版本的语法变更，而是把数据边界放对位置；本文只讨论已核实的v0.3.4接口。

图中输入文件关联压缩字节，Decoder关联输入Reader和输出PCM块，回调关联有效区buf[:n]。这些是对象之间的静态关系，不表示文件内容可以直接交给PCM消费者。

把文件包装成Decoder再逐块消费

对长音频，我倾向于先给同步消费者一块块数据，避免默认把整个解码结果保存在内存。下面是原创辅助函数，调用方可在consume中写文件或进行增量计算。示例未执行，不包含虚构输出。

package pcmread

import (
    "fmt"
    "io"
    "os"

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

// ReadMP3逐块交给同步消费者；consume若要异步保留数据，必须先复制。
// 返回采样率和已交付PCM字节数；错误时字节数只代表部分结果。
func ReadMP3(path string, consume func([]byte) error) (rate int, delivered int64, err error) {
    if consume == nil {
        return 0, 0, fmt.Errorf("consume is nil")
    }
    f, err := os.Open(path)
    if err != nil {
        return 0, 0, fmt.Errorf("open MP3: %w", err)
    }
    defer func() {
        // 保留主要读取错误；仅在没有其他错误时报告关闭失败。
        if closeErr := f.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close MP3: %w", closeErr)
        }
    }()
    d, err := mp3.NewDecoder(f)
    if err != nil {
        return 0, 0, fmt.Errorf("create decoder: %w", err)
    }
    rate = d.SampleRate()
    buf := make([]byte, 16*1024)
    for {
        n, readErr := d.Read(buf)
        // 遵循io.Reader约定：先消费有效字节，再处理本次错误。
        if n > 0 {
            if err := consume(buf[:n]); err != nil {
                return rate, delivered, fmt.Errorf("consume PCM: %w", err)
            }
            delivered += int64(n)
        }
        if readErr != nil {
            if readErr == io.EOF {
                return rate, delivered, nil
            }
            return rate, delivered, fmt.Errorf("decode MP3: %w", readErr)
        }
        if n == 0 {
            // 避免异常的零字节无错误返回造成无限空转。
            return rate, delivered, io.ErrNoProgress
        }
    }
}

函数拥有输入文件，因此负责Close；Decoder本身没有Close方法。回调接收到的是复用缓冲区中的有效字节，不能直接存进异步队列后等下一次读取覆盖。需要保留时，回调内先复制，再交给其他任务。

delivered只在回调成功接收整块后增加。回调若已经做了部分副作用再报错，这个数字不能精确反映那部分副作用，调用方应采用自己的提交或回滚策略。返回非nil错误时也不能把已消费部分当作完整解码成果。

按四字节音频帧理解PCM

输出按左右声道交错组织：左声道低字节、左声道高字节、右声道低字节、右声道高字节，组成一个立体声帧。不要把4字节整体转成一个32位振幅，也不要把一帧误认为一个字节。

第二张图把左右声道各自的两个字节放入同一个4字节PCM帧分组；采样率用于解释每秒音频帧数量。这里的PCM帧与MP3压缩帧不是同一层概念。

如果下游要逐帧读取，应先累计跨Read边界的剩余字节，再取4的整数倍作为完整帧。缓冲区容量是4的倍数，不等于任意Reader每次返回长度都天然满足下游帧边界。上面的回调是字节消费者，因此不在每个回调中强制解析振幅。

完整且帧对齐的PCM总字节数除以4，才是立体声帧数；再除以采样率得到对应时长。PCM没有WAV容器头，保存为.raw不会自动携带采样率、声道与位深元数据。写成.wav也不能只改扩展名，需要正确封装。

长度未知和读取失败怎样处理

Length返回解码流的总字节数；不可获知时可能为-1，例如底层不是io.Seeker。流式读取不依赖这个长度，因此不要拿-1直接分配切片。底层文件可Seek也不代表应该预先分配整个PCM结果。

读取循环先处理n大于0的数据，再处理错误，符合io.Reader语义。非EOF错误必须向上返回。不过，该版本源码会把某些内部UnexpectedEOF映射为io.EOF，所以“读取循环没有非EOF错误”不能证明源文件绝对完整。若业务要求完整性，需要在输入协议或业务层有独立的长度、摘要或完整性依据，本文示例不承担该任务。

SampleRate来自首个压缩帧，它不是重采样操作。下游若要求固定采样率，应另行转换，不能只把元数据中的数值改掉。一个Decoder也不应被多个goroutine同时调用Read来瓜分未经协调的状态。

哪些任务适合直接消费PCM

我的选择标准是下游是否真正需要采样值：波形计算、增量分析、交给匹配格式的音频输出接口，适合逐块消费；只需要上传、归档原始MP3时，保留压缩数据更直接。如果只是很短的小文件且内存预算明确，一次读完也是可选方案，但不能把它当成长音频默认方案。

单声道源会输出单声道PCM吗？该版本接口约定输出仍为双声道，不能直接沿用源文件声道数解释输出。

得到PCM就能直接播放吗？还需要音频设备或播放库，并确保采样率、位深、端序、声道布局匹配；本例只解码和消费字节。

一定要先把MP3全部读到内存吗？不必，NewDecoder接收io.Reader。但可Seek输入在初始化时可能涉及长度和帧索引扫描，不宜仅凭“逐块Read”断言初始化完全无扫描成本。

参考：go-mp3接口文档、该版本解码器源码、io.Reader契约。