Go go-wav 怎样分批读取WAV的整数PCM缓冲区

处理较长的 WAV 文件时，FullPCMBuffer() 会把全部 PCM 样本放进内存，读取方式简单，却不适合持续分析、转码或流式计算。github.com/go-audio/wav 提供的 Decoder.PCMBuffer 可以把整数 PCM 填入一个固定容量的 audio.IntBuffer，循环消费每批样本即可。

官方资料：https://pkg.go.dev/github.com/go-audio/wav

分批读取的关键是：预先分配可复用的整数缓冲区，用返回的 n 只处理本批有效样本；n == 0 表示数据读完，非空错误才进入失败分支。多声道场景还要按 NumChannels 对齐完整音频帧。

先把 WAV 格式和样本数量分开

WAV 的 PCM 数据按样本存放，16 位单声道每个样本占 2 字节；如果是双声道，一帧包含左右两个样本。因此 PCMBuffer 返回的 n 应理解为整数样本数量，而不是字节数。解码器的 Format() 可提供声道数和采样率，SampleBitDepth() 提供位深，PCMLen() 才是 PCM 数据块的字节长度。

如果只想确认容器可读，可以先调用 ReadInfo() 并检查 Err()。不要把 FullPCMBuffer() 当成分批接口：官方文档明确说明它会把整个 PCM 数据留在内存中。

用 PCMBuffer 把 WAV 数据分批交给处理器

下面的示例把缓冲区容量设为 4096 个整数。容量可以按处理算法调整，但最好是声道数的整数倍，这样多数批次天然按完整帧结束。每轮只读取 buf.Data[:n]，缓冲区剩余位置不能继续使用。

package main

import (
    "fmt"
    "log"
    "os"

    "github.com/go-audio/audio"
    "github.com/go-audio/wav"
)

func readPCMInBatches(path string) error {
    f, err := os.Open(path)
    if err != nil {
        return fmt.Errorf("打开 WAV 失败: %w", err)
    }
    defer f.Close() // 及时释放文件描述符，解码器不会代替我们关闭文件

    dec := wav.NewDecoder(f)
    dec.ReadInfo() // 先解析 fmt 块，便于得到声道、采样率和位深
    if err := dec.Err(); err != nil {
        return fmt.Errorf("读取 WAV 头失败: %w", err)
    }

    format := dec.Format()
    if format == nil || format.NumChannels 

这个循环不依赖每次都填满 4096 个位置。最后一批可能更短，判断依据是 n，不是 len(buf.Data)。另外，PCMBuffer 会在返回前设置 buf.Format 和 SourceBitDepth，下游若需要格式信息，可以直接从缓冲区读取。

按完整音频帧处理尾批并区分 EOF 与 Err

“一批样本”与“一批完整帧”不是同一个概念。双声道每帧需要两个整数；若自定义缓冲区容量不是声道数的整数倍，尾批就可能留下半帧。对音频特征、左右声道配对或写回文件的处理，应先截到 complete，不要让半帧进入下游。

还要注意错误分支：PCMBuffer 将正常的 io.EOF 转成空错误，因此用 n == 0 结束循环；如果返回其他错误，应保留错误上下文并停止处理。不要只看 dec.EOF() 来决定循环，因为一次 PCMBuffer 调用已经把正常结束转换成了返回值。

FullPCMBuffer、Rewind 和 Seek 怎么选

小文件、需要随机访问全部样本时可以用 FullPCMBuffer，但它的内存成本随音频长度增长。长文件分析、实时特征提取和批量转码优先使用 PCMBuffer。同一个解码器要从 PCM 开头重新读取时，用 Rewind()；它会重新定位并重新准备解析器。已经明确知道 PCM 游标偏移时才使用 Seek，并自行保证偏移没有落在样本中间。

实践上，固定容量、按 n 截取、按声道对齐、错误立即返回这四点比盲目调大缓冲区更重要。

常见问题

PCMBuffer 会返回字节数吗？

不会。它返回填入 audio.IntBuffer.Data 的整数样本数；PCM 字节总量用 PCMLen() 查询。

为什么最后一批比缓冲区容量小？

因为文件剩余 PCM 不足以填满固定容量，这是正常尾部。只要 n > 0 且没有错误，就消费这批有效数据。

可以一直调用 FullPCMBuffer 再切片吗？

可以切片，但已经失去分批读取节省内存的意义。长音频应让 PCMBuffer 直接把每批数据交给处理函数。