Go go-mp3 解码后的Length为何不是MP3文件大小

这个结果是正常的：go-mp3 的 Decoder.Length() 面向“解码后的流”，统计的是 PCM 输出总字节数；MP3 文件大小属于压缩输入层，两者本来就不是同一个单位。对文件输入可以读取 Length()，对网络流或管道要把 Read 返回的解码字节累计起来，不能把原始文件大小当作音频样本数。

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

先把文件大小和解码长度放回两层数据

MP3 文件里的字节经过压缩、帧封装和可能存在的标签后才交给解码器。NewDecoder 接收的是 io.Reader，它向调用方暴露的是一个按需产生 PCM 的 Decoder。因此，文件系统的 Stat().Size() 与 Decoder.Length() 分别回答“压缩输入占多少空间”和“解码后要输出多少字节”，不能互换。

还要注意，MP3 压缩帧和 PCM 采样帧不是同一种帧。即使两个输入的文件大小接近，编码参数不同也可能得到不同的解码长度；反过来，解码长度相近也不代表压缩文件大小相同。

可寻址输入用 Length 判断总解码字节

本地文件通常实现了 io.Seeker，这类输入适合在创建解码器后读取总解码长度。下面的函数只负责解释长度，不把它误当成原始文件大小；返回 -1 时立即交给流式策略。

package main

import (
    "errors"
    "fmt"
    "os"

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

func decodedBytes(path string) (int64, int, error) {
    f, err := os.Open(path)
    if err != nil {
        // 打开失败时不创建半初始化的 Decoder。
        return 0, 0, fmt.Errorf("open MP3: %w", err)
    }
    defer f.Close() // 文件由本函数打开，因此由本函数释放。

    decoder, err := mp3.NewDecoder(f)
    if err != nil {
        // 将格式错误保留给调用方，不把它伪装成零长度。
        return 0, 0, fmt.Errorf("create decoder: %w", err)
    }
    length := decoder.Length()
    if length 

这段代码的关键不是“文件一定能得到长度”，而是显式区分成功值、未知值和解码错误。不要把 -1 直接转换成无符号整数，也不要用它分配大切片。SampleRate() 是首个压缩帧提供的采样率，单独拿到它也不能推出总时长。

Length 返回 -1 时，在 Read 中累计解码字节

网络响应、管道或自定义实时输入可能只实现 io.Reader。此时总长度并非零，而是无法在开始读取前知道。只要业务允许读到流尾，就可以累计每次 Read 返回的 n：

func countDecoded(decoder io.Reader) (int64, error) {
    buf := make([]byte, 32*1024)
    var total int64
    for {
        n, err := decoder.Read(buf)
        // n 是本次有效的PCM字节，只能使用 buf[:n]。
        total += int64(n)
        if err == io.EOF {
            return total, nil
        }
        if err != nil {
            // 非EOF错误意味着不能把累计值当成完整结果。
            return total, fmt.Errorf("read decoded PCM: %w", err)
        }
        if n == 0 {
            // 防止异常的零字节无错误返回导致无限循环。
            return total, io.ErrNoProgress
        }
    }
}

示例中的 io.Reader、fmt 和 io 需要在完整程序中导入。若下游还要异步处理，回调或队列必须复制 buf[:n]，因为下一次读取会复用这块缓冲区。

按 go-mp3 的输出格式换算采样数量

官方接口说明 NewDecoder 的输出固定为 16 位小端双声道，即左右声道各 2 字节，一个完整采样占 4 字节。于是只有在解码字节数已经确定时，才可以用下面的关系换算：

采样数量 = 解码后字节数 / 4
音频秒数 = 采样数量 / SampleRate()

这里的“4 字节”是该库当前输出格式的契约，不是所有 MP3 解码器的通用常量。不要把 MP3 压缩帧按 4 字节切分，也不要把一整个立体声采样误当成一个 32 位振幅。

按下游目标选择文件大小还是解码长度

如果只是上传、归档或计算传输进度，文件大小更适合，因为任务针对的是压缩输入；如果要做波形、音频分析或交给 PCM 消费者，就应围绕 Decoder 的输出字节处理。需要立即展示可寻址文件时长，可以用 Length()；需要边读边分析的流，则接受“读到EOF后才知道完整时长”的代价。

• 先确认当前指标属于压缩输入还是解码输出。
• 遇到 Length() == -1 时切换为累计 Read 字节，不把它当成空文件。
• 发生非EOF错误时，累计值只能表示部分进度，不能标记为完整音频。
• 跨读取边界解析 PCM 时，保留不足 4 字节的尾部，和下一次读取拼接。

相关问题

为什么同样时长的两个MP3文件大小不同？

比特率、编码方式、标签和压缩参数会影响输入文件大小，而解码播放时长主要由采样数量和采样率决定。

Length() 返回 -1 是解码失败吗？

不是。它表示底层输入不是可用于提前确定总长度的 io.Seeker；可以继续读取并在到达EOF后累计解码字节。

为什么不能直接用 os.File.Stat().Size() 计算PCM长度？

因为 Size() 统计的是MP3压缩字节，不能代表解码后固定格式的PCM字节数量。

事实依据：https://pkg.go.dev/github.com/hajimehoshi/go-mp3 的 Decoder 文档，页面记录的 v0.3.4 接口说明包含 Length、Read、SampleRate 与固定输出格式边界。