Python与C语言汉明窗处理帧数据的一致性差异问询

核心原因：数据类型截断差异 #

你的代码中最大的差异在于窗函数应用阶段的数据类型处理逻辑：

1. Python端的强制类型截断

   • scipy.io.wavfile.read读取16位PCM音频时，返回的data是np.int16类型
   • 分帧后的framedata继承了int16类型，执行frames[i][j] *= window[j]时，浮点运算的结果会被强制转换回int16，触发向零取整的截断操作，直接丢失小数部分。

2. C语言端的浮点精度保留

   • C代码中data_frames是double类型的二维数组，从short类型的data赋值时会自动转换为double，后续与double类型的汉明窗相乘后，结果始终保持double精度，无任何截断损失。

中间帧差值稳定的原因 #

中间区域的帧（180-220帧）对应的音频信号幅值和分布，恰好使得窗函数运算后的浮点结果普遍处于整数边界附近（例如计算结果为x.99或x+0.01）：

• Python端截断后得到整数x，C端保留浮点值x.99，两者的绝对差值就会稳定在0.99~1.0之间；
• 其他帧的信号幅值分布分散，运算结果的小数部分无集中规律，因此差值波动较大。

验证与修复方案 #

验证方法 #

修改Python分帧步骤，将数组转换为浮点类型后再应用窗函数，对比结果：

# 修改分帧代码
framedata = data[stpt:stpt+datalen].astype(np.float64).copy()

若修改后与C语言结果的差值回到1e-7级的浮点精度差异，即可确认是类型截断导致的问题。

修复方案 #

将Python中的音频数据全程以浮点类型处理，避免不必要的类型转换截断：

import scipy.io.wavfile as wavfile
import numpy as np

samplerate, data = wavfile.read(filename)
# 读取后立即转为浮点类型
data = data.astype(np.float64)
window = np.hamming(int(winlen*samplerate))

# Pre-Emphasis
for i in range(1, len(data)):
    data[i] = data[i] - 0.97 * data[i-1]

# Framing
dlen = int((len(data)/samplerate - winlen)/stride)+1
frames = []
for i in range(dlen):
    stpt = int(samplerate*stride)*i
    datalen = int(winlen*samplerate)
    framedata = data[stpt:stpt+datalen].copy()
    frames.append(framedata)

# Apply Window
for i in range(len(frames)):
    frames[i] *= window

内容的提问来源于stack exchange，提问作者FloopyBeep