从RecordRTC Blob计算音频时长：两种方法哪个更可靠？

针对你的场景，方法2（基于字节数计算）是更准确可靠的方案，而方法1存在明显的误差风险，具体分析如下：

方法1的问题：timeSlice累加不可靠 #

你设置的timeSlice=500ms是浏览器触发ondataavailable事件的期望间隔，但实际录制的音频切片时长并不严格等于500ms：

• 浏览器事件循环可能被其他任务阻塞，导致切片生成延迟，实际时长会略长于500ms
• 录制结束时的最后一个切片，时长必然小于500ms（除非录制时长刚好是500ms的整数倍）
• RecordRTC内部的音频处理逻辑也可能对切片时长产生微小偏差

直接用切片数量×500ms计算总时长，会出现不可控的误差，无法得到精准结果。

方法2的正确性：字节数计算需处理WAV头 #

你实际得到的是audio/wav格式的Blob，标准PCM编码的WAV文件包含44字节的文件头（存储格式信息、采样率等元数据），音频数据紧跟在头之后。计算时长的步骤如下：

1. 先从Blob的总字节数中减去44字节的WAV头长度
2. 用剩余的音频数据字节数代入公式计算：

   时长(秒) = (总字节数 - 44) / (采样率 × 声道数 × (位深/8))
   

   结合你的配置：
   • 采样率=16000Hz
   • 声道数=1
   • PCM编码默认位深为16位（RecordRTC未指定时采用此标准）
     代入后公式简化为：

   时长(秒) = (总字节数 - 44) / (16000 × 1 × 2)
   

验证WAV头的方法：可以读取Blob的前4个字节，若为RIFF（ASCII码对应十六进制52 49 46 46），则说明是标准44字节头的WAV文件。

补充说明 #

你配置的mimeType='audio/webm;codecs=pcm'实际输出audio/wav，是因为RecordRTC在部分浏览器环境下，对PCM编码的WebM支持有限，会自动 fallback 到兼容性更好的WAV格式，这属于正常的内部适配逻辑。

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