登录
推荐 文章 Go 技术 课程 下载 专题 AI
首页 >  文章 >  python教程

Python wave 以不可定位输出写文件时怎样确定帧数

来源:17golang原创

时间:2026-10-31 02:19:56 292浏览 收藏

不可定位输出写WAV时,总帧数必须在第一块音频数据写出时就准确。有两种常用做法:提前用 setnframes() 或 setparams() 声明最终总帧数,再分块调用 writeframesraw();或者把全部最终PCM数据一次交给 writeframes(),由它按数据长度确定帧数。不能先写一个估计长度,再指望关闭时回头修改。

我会把这类选择理解为“先确定长度,再输出”的模式:普通文件允许回写头部,管道一类只能向前写的目标则要求提前掌握长度。本文以Python 3.14文档和对应实现为依据,只讨论未压缩整数PCM,不混用后续版本新增格式能力。

Python官方文档地址:https://docs.python.org/3.14/library/wave.html

nframes数的是多声道帧,不是样本总数

在交错PCM中,一帧包含同一采样时刻的全部声道样本。每帧字节数由声道数乘样本宽度得到;PCM字节总量除以每帧字节数,才是 nframes。样本宽度使用字节,例如16位整数样本的宽度为2字节。

# pcm仅包含音频载荷,不包含WAV头;参数必须与实际编码一致。
frame_bytes = channels * sample_width
if frame_bytes 

双声道、16位、9600字节的PCM载荷对应2400帧,而不是4800帧。采样率描述每秒帧数,不能把预计播放秒数直接填入nframes。若根据时长估算会发生舍入,应以实际生成或读取到的完整帧数为准。

声道数样本宽度每帧字节与总帧数文件头关系
图1:PCM帧宽、总字节数和WAV头部元信息的静态关系说明图。

预声明总帧数,再分块写入

这个模式适合上游已经有可靠长度的任务。setnframes 提供声明总帧数,writeframesraw 接收PCM分块,Wave_write 负责容器写入,而不可定位输出不承担头部修补能力。参数应在写入数据前设置。官方文档:不可定位输出的长度要求。

setnframes和writeframesraw与不可定位输出的静态契约
图2:预声明长度和分块数据与写入器的静态接口关系图,不是执行时间轴。

下面的独立示例用一个拒绝tell和seek的包装对象,明确模拟只能向前写的输出接口。三个内存块是有限演示数据;函数的blocks参数约定为可重复遍历的字节块列表,不接受只消费一次的生成器。示例没有在本轮实际运行。

import io
import wave


class ForwardOnly:
    """适配已有二进制输出,只允许向前写,所有权仍归调用者。"""

    def __init__(self, raw):
        self.raw = raw

    def write(self, data):
        return self.raw.write(data)

    def flush(self):
        self.raw.flush()

    def tell(self):
        raise io.UnsupportedOperation("输出不支持定位")

    def seek(self, *args):
        raise io.UnsupportedOperation("输出不支持回写")


def write_known_blocks(sink, blocks):
    # 示例固定为双声道、16位整数PCM、48000帧/秒。
    channels, sample_width, rate = 2, 2, 48000
    frame_bytes = channels * sample_width
    # 仅用于已在内存中的有限演示数据,写头前核对所有块。
    if any(len(block) % frame_bytes for block in blocks):
        raise ValueError("每块字节数必须对齐完整音频帧")
    total_frames = sum(len(block) // frame_bytes for block in blocks)
    if total_frames 

按输入计算,400、800、1200帧相加为2400帧;输出文件的音频内容为50毫秒静音。这里预先核对每块长度,是为了让分块边界不拆开一帧。实际服务若从一次性数据源读取,不能照抄“先遍历核对、再遍历写入”而不处理可重复读取的问题。

完整数据已准备好时,一次writeframes更直接

当音频载荷已经完整放在内存里,可以省略setnframes,让第一次writeframes拿到全部最终数据。不要在这次调用后再追加新块:一旦累计长度改变,就可能需要修补已发送的头部。

import wave


def write_complete_pcm(sink, pcm):
    # pcm必须是已经完整准备好的双声道16位整数PCM字节数据。
    channels, sample_width = 2, 2
    if not isinstance(pcm, bytes):
        raise TypeError("本例要求bytes输入")
    if len(pcm) % (channels * sample_width):
        raise ValueError("PCM字节长度没有对齐完整帧")
    with wave.open(sink, "wb") as writer:
        writer.setnchannels(channels)
        writer.setsampwidth(sample_width)
        writer.setframerate(48000)
        # 不预设错误的nframes;第一次调用就传入全部最终数据。
        writer.writeframes(pcm)
    # 不关闭调用者提供的sink。

此函数接受上层准备好的sink与bytes,不执行网络连接,也不打开文件。调用者仍负责底层输出的关闭。文件式对象应提供可靠的二进制写入与flush行为;如果底层可能短写或处于非阻塞模式,需要另做适配,不能把裸套接字直接视为本例的sink。

为什么未知长度持续输出是反例

第一次只传一个小块,然后反复调用writeframes,不能让普通WAV自动变成未知长度的流式格式。CPython对应实现会比较头部声明的数据长度和累计已写字节数,不一致时进入头部修补;修补依赖tell与seek。writeframesraw只是避免每次写块立即修补,不会取消最终长度一致的要求。依据:CPython 3.14的写入及头部修补实现。

如果上游确实不知道最终长度,我倾向先把数据暂存到可定位介质,完成WAV头部后再发送;音频很短且内存预算明确时,也可以先缓冲完整载荷。另一种选择是由系统设计采用适合未知长度传输的协议或容器,但那已超出此处wave写法的范围。三者分别付出临时存储、内存或协议改造成本,没有一个setnframes参数能消除这些取舍。

结束与失败时的责任

使用with让wave完成关闭,不代表底层外部对象也自动关闭。若实际写出的长度与声明不同,不可定位输出在结束时可能报错;已经向外发送的前缀也无法撤回。读取上游失败、传输失败或长度不符时,应让调用层把这次产物认定为不完整,不能仅因为曾经写出WAV开头就宣布完成。

实现前可以逐项确认:声道和样本宽度是否匹配载荷;总长度是否可信;分块是否保持完整帧;sink是否可靠写入全部数据;参数是否在首块前确定;底层对象由谁关闭。文件头包含长度信息,因此声明正确与实际完整写入需要同时成立。

常见问题

setnframes会自动补齐缺少的静音帧吗?

不会。它声明长度,不会生成载荷。若业务要补静音,应实际产生符合编码的静音样本,并把它们计入总帧数。

双声道要把每个声道的帧数再乘2吗?

不要。双声道改变的是一帧占用的字节数,nframes仍按采样时刻计数。

已知总量但分块很大,要一次性拼接吗?

不必为了writeframes而拼接。总量可靠时,可预声明后分块writeframesraw。真正需要在第一块前确定的是最终帧数及编码参数,而非所有载荷都同时驻留内存。

声明:本文转载于:17golang原创 如有侵犯,请联系study_golang@163.com删除
相关阅读
更多>
最新阅读
更多>
课程推荐
更多>