Go flac 怎样按音频帧遍历解码样本

使用github.com/mewkiz/flac的Stream.ParseNext()逐帧解析，成功后遍历Frame.Subframes，再访问每个子帧的Samples。每个子帧对应一个声道，Samples是解码后的int32切片；遇到io.EOF结束，其他错误应向上返回。

官方地址：https://pkg.go.dev/github.com/mewkiz/flac

本文固定以v1.0.14接口为讨论范围，处理对象是该库接受的FLAC流，不外推所有带.flac扩展名的容器都可直接打开。

让帧读取与样本消费各自负责一件事

逐帧消费适合波形概览、声道统计、分块写入下游等任务：读取层负责文件和解码错误，消费层只接收已经解析好的帧。这种边界能避免统计逻辑同时承担文件位置与资源关闭责任。

它也有代价。帧并不等于固定时间长短的任务单元，消费方不能硬编码“每帧一定有某个数量的样本”。如果应用把每帧都永久保存在数组里，逐帧读取最终仍可能变成全量缓存，失去控制内存占用的意义。

用ParseNext取得完整帧，再遍历子帧

下面是原创同步辅助代码。WalkFrames把每个成功解码的帧交给visit，CountChannelSamples演示如何遍历声道与样本。代码没有执行，不提供虚构的文件输出或性能数据。

package flacwalk

import (
    "fmt"
    "io"

    "github.com/mewkiz/flac"
    "github.com/mewkiz/flac/frame"
)

// WalkFrames同步消费完整解码帧；visit不能再从同一个stream读取。
// 返回成功交付的FLAC帧数，不是采样数、声道数或字节数。
func WalkFrames(path string, visit func(*frame.Frame) error) (blocks int64, err error) {
    if visit == nil {
        return 0, fmt.Errorf("visit is nil")
    }
    stream, err := flac.ParseFile(path)
    if err != nil {
        return 0, fmt.Errorf("open FLAC: %w", err)
    }
    defer func() {
        // 保留更早的解析或消费错误。
        if closeErr := stream.Close(); err == nil && closeErr != nil {
            err = fmt.Errorf("close FLAC: %w", closeErr)
        }
    }()
    for {
        f, readErr := stream.ParseNext()
        if readErr == io.EOF {
            return blocks, nil
        }
        if readErr != nil {
            return blocks, fmt.Errorf("decode FLAC frame: %w", readErr)
        }
        // 只把成功解析的完整帧交给下游，失败帧不作为有效数据。
        if visitErr := visit(f); visitErr != nil {
            return blocks, fmt.Errorf("consume frame: %w", visitErr)
        }
        blocks++
    }
}

// CountChannelSamples展示声道遍历，每个元素是一个解码后的整数样本。
// 该计数把所有声道样本相加，不能直接除以采样率作为播放时长。
func CountChannelSamples(f *frame.Frame) []int {
    counts := make([]int, len(f.Subframes))
    for channel, sub := range f.Subframes {
        for range sub.Samples {
            counts[channel]++
        }
    }
    return counts
}

visit接收的是当前完整帧，可在里面调用CountChannelSamples，也可直接在声道循环中对样本值做增量计算。示例统计数组仅展示层级访问，不会播放音频或写出PCM字节。

返回的blocks只累计回调成功处理的FLAC帧。回调如果做了一部分外部写入后失败，需要调用方自己管理那部分副作用，不能把blocks当成事务提交计数。也不要把解析失败的f继续交给下游。

理解帧、声道与样本下标的关系

FLAC帧携带一段音频块。Frame.Subframes按声道组织，每个Samples切片保存该声道这一块中的样本。因此在双声道情况下，相同下标的两个声道值对应同一采样时刻；它不是一个左右交错的byte切片。

第二张图按双声道例子说明结构，不把“两声道”当作所有输入的限制。实际处理时应按Subframes数量遍历，不能固定索引第二声道而不考虑单声道输入。

样本存储类型为int32，不代表原始音频一定是32位，也不是已经归一化到-1至1的浮点数。下游若需要特定位深的字节或浮点振幅，应依据音频格式另做转换，明确端序、位深和通道布局。

一段假设的双声道块如果每声道有1024个值，则包含1024个采样时刻、2048个声道样本值。前者才与采样率共同决定这段音频的时长；这些数字只是计量示例，并非某个文件的实测结果。

不要把只读帧头当成完成解码

Stream.Next只解析下一个帧头，完整样本需要进一步调用Frame.Parse。Stream.ParseNext则直接完成整帧解析，因此更适合本文的“拿样本做统计”任务。不要调用Next后就假设Samples已经填满，也不要在ParseNext之后再对同一帧重复Parse。

该版本完整解析还会恢复声道间去相关后的样本关系；通常不需要调用方再次手动Correlate。重复处理可能破坏已经还原的值。

同步回调让帧消费与读取节奏一致。如果需要异步排队，先明确数据所有权和可变性：可在任务边界复制需要的样本切片，或保证独占且不修改共享数据，并为队列设置容量。不能让解码速度无限超过消费速度。

采用逐帧方式前确认这些条件

能只读取一个声道吗？可以在成功解码的帧中选择某个子帧消费，但不应据此声称库只解码了那个声道。完整帧解析与选择性业务消费是两件事。

逐帧遍历就等于校验了所有音频内容吗？不应作此承诺。本例关注样本访问和错误传播，没有实现独立的全流摘要核对，也不把成功结束视为额外完整性保证。

一次回调拿到的帧长度是否固定？不能硬编码，应使用当前帧各声道Samples长度；如果下游要求固定大小块，需要自己拼接或切分，并保留采样时刻对齐。

参考：flac流接口、Frame与Subframe说明。