wav封装格式

wav文件格式作为一种常用的多媒体音频文件格式,其由MS在1991年8月在Windows 3.1上推出,文件扩展名为WAV,是WaveFom的简写。通常存储未压缩的pcm数据,也可存储压缩的pcm数据(G711a/u,G726,ADPCM)。WAV文件格式简称WAV格式,是一种存储声音波形的数字音频格式,是由微软公司和IBM联合设计的,经过了多次修订,可用于Windows,Macintosh,Linix等多种操作系统,详述如下。

波形文件的基础知识

1.1 波形文件的存储过程

声源发出的声波通过话筒被转换成连续变化的电信号,经过放大、抗混叠滤波后,按固定的频率进行采样,每个样本是在一个采样周期内检测到的电信号幅度值;接下来将其由模拟电信号量化为由二进制数值;最后编码并存储为音频流数据。有的应用为了节省存储空间,存储前,还要对采样数据先进行压缩(G711/G726)。其过程如下:

采样->模拟信号->量化->压缩->存储。

1.2 WAV文件的编码

编码包括了两方面内容:一是按一定格式存储数据;二是采用一定的算法压缩数据。WAV格式对音频流的编码没有硬性规定,既支持非压缩的PCM(Puls Code Modulation)脉冲编码调制格式,又支持压缩型的数据,如微软自适应分脉冲编码调制Microsoft ADPCM(Adaptive Differential Puls Code Modulation)、国际电报联盟(International Telegraph Union)制定的语音压缩标准ITUG.711 a-law、ITU G.711 u-law、IMA ADPCM和其它压缩算法。

1.3 WAV文件存储格式

       封装格式主要包括三部分:"RIFF" chunk,"fmt " sub-chunk,"data" sub-chunk。

每个chunk的格式如下:

块标识 4Bytes "RIFF"/"fmt "/"data"
块长度 4Bytes 接下来“数据”到文件尾的size
数据 X Bytes 具体内容

 

 

 

 

其中,对“块长度”进行详细解释,其大小为从接下来“数据”部分开始,一直到文件尾结束,其以字节为单位的大小。但是,"fmt " sub-chunk则有些特别。

例如,"RIFF" chunk,其“块长度”=file_size - 8Bytes,因为要排除“块标识”+本“块长度”的8Bytes。

"fmt " sub-chunk(注意t后面有个空格,必须由4Bytes组成),其大小为该sub-chunk的大小=16Bytes。

"data" sub-chunk,其大小为接下来“数据”部分的size,即pcm数据的大小=file_size - 44Bytes(wav头大小)。

1.4 WAV文件实例分析

通过winhex查看二进制数据如下:

 

PCM基础知识

(1)采样频率(sample rate):又称取样频率。是单位时间内的采样次数(一秒钟采样多少次信号),决定了数字化音频的质量。采样频率越高,数字化音频的质量越好、声音越真实,当然所占的资源、存储空间也越多。根据奎特采样定理,要从采样中完全恢复原始信号的波形,采样频率要高于声音中最高频率的两倍。人耳可听到的声音的频率范围是在16Hz-20kHz之间。因此,要将听到的原声音真实地还原出来,采样频率必须大于4 0k H z 。常用的采样频率有8 k H z 、1 1 . 02 5 k H z 、22.05kHz、44.1kHz、48kHz等几种。22.05KHz相当于普通FM广播的音质,44.1KHz理论上可达到CD的音质。对于高于48KHz的采样频率人耳很难分辨,没有实际意义。录像设备采集人声时,通常用16kHz采样,使用8kHz的则声音回放时有些闷,使用16k以上时跟16k的分不出区别。而专业录音棚中录制时,则通常使用44.1k/48k/96k的采样率,因为不仅要采集人声,还要采集乐器声。


(2)采样位数(bit width):也叫量化位数(单位:比特),是存储每个采样值所用的二进制位数。采样值反应了声音的波动状态。采样位数决定了量化精度。采样位数越长,量化的精度就越高,还原的波形曲线越真实,产生的量化噪声越小,回放的效果就越逼真。常用的量化位数有4、8、12、16、24。量化位数与声卡的位数和编码有关。如果采用PCM编码时使用16位声卡,可将音频信号幅度划分成了64K个音量等级,取值范围为-32768至32767。网络上音频文件基本上都是16位采样精度。


(3)声道数(channel count):是使用的声音通道的个数,也是采样时所产生的声音波形的个数。我们通常接触到的是单声道(mono)和立体声(stereo)。立体声在采集时,使用两个mic,两个mic处于不同的位置,其采集时所量化到的二进制值有些差别,因此在回放时会感觉到两个耳朵里信号有些差异,给人以立体感。

 

WAV实例练习

为了学习wav封装格式,特写了一个工具,用于读取/写wav文件,检查sample_rate/channel_cnt/duration。已上传GitHub:https://github.com/Dreaming-in-Gottingen/AudioTools

wav_utils文件生成libwav_ops.so库文件,tests用于测试libwav_ops.so中对wav读/写的实现,CStdWavGenerator用于生成标准的音频文件(如正弦波,方波,三角波)。

码了这么多字,实在太费时间了,朋友们可以下载下来测试一下。有问题,欢迎留言。

以后有时间了,再整一篇文章介绍一下关于pcm增益、采样率、频率等问题。

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 dio@foxmail.com 举报,一经查实,本站将立刻删除。

相关推荐


一年前写了一个demo,用于生成几种标准的波形,如正弦波、方波、三角波。之前写的只有这几个功能:波形/通道/时长/频率的控制选择,这几天抽了些时间又加了增益控制功能。为了避免东西丢失或意外删除,特上传
wav文件格式作为一种常用的多媒体音频文件格式,其由MS在1991年8月在Windows 3.1上推出,文件扩展名为WAV,是WaveFom的简写。通常存储未压缩的pcm数据,也可存储压缩的pcm数据
mpeg2ts文件格式中有pcr和pts的概念,其代码含义如下: PCR(Program Clock Reference)——指示系统时钟本身的瞬时值的时间标签称为节目参考时钟标签(PCR)。 PTS
我的月经贴博客该更新了!!!已经有许多博文需要补了! 去年开始的jpeg解码项目,中间停止更新了大半年时间,上个月想起这事还没完工,就又做了更多兼容性和性能上的改进,目前终于接近尾声了。有需要参考的可
花了两天时间做了个h264裸流nal类型和frame类型检测的工具,已上传至github,有需要的自行下载(其中包含构建出来的可执行文件exe)。 1.NAL类型检测 nal类型检测非常容易,对照下表
随着工作业务的开展,对视频编解码的理解更加深入了一些,记录一些心得体会,以便后面回味。 某天突然有个好的想法略过心头,可以形象的向别人介绍视频编码和解码。 1.编解码像一场考试,编码就像做主观题,解码
承接昨天写的《JPEG软解码实现介绍》,今天介绍其使用方法和一些细节说明。 1.仓库下已经包含了几个jpeg文件,以方便直接校验。 2.使用命令分为两种模式。 一种是直接解码为yuv文件,另外一种是解
x264编码器,提供了两个demo来验证编码功能:一个是大而全的x264.c,另外一个是简洁版的example.c。 其中,前者demo,可以配置很多编码参数,但太冗长繁杂,对初学者不太友好。 后者d
本博文为概览性介绍。后面有空了再分几篇博文分别介绍所用到的技术细节。 1.编解码目标 编码和解码是个逆过程。jpeg编码的目的在于图形去冗余,进行数据压缩,解码的目的在于还原图像,使能够进行预览。 2
今天使用公司开发手机,调研一下当下很火的抖音客户端,其使用的视频编码类型。 在调研前,有个初步判断: 1.从抖音服务器推送到客户端的视频流要么是avc码流,要么是hevc码流(具体要视平台解码硬件支持
最近对抖音有点上瘾,经常看到这样的视频列表: 由于抖音平台的限制,用户最多只能上传60s的视频,因此分段为3个视频。而在视频列表的缩略图模式下,三个视频的封面恰好组合成一张图像。这种方式比较符合审美标
自己在学习h264的路上,欢迎讨论交流。 前段时间研究JM出品的h264编码器,代码实在看不下去,因此换了个角度来研究诸多算法——逆向方式(解码),本系列文章记录一些遇到的东西和思考。 1. JM介绍
h264裸码流,根据nalu_header可以知道类型,例如该帧是I帧,P帧/B帧。 例如,常见的0x65代表I帧,0x41代表非关键帧,即P帧或B帧,但是只根据nalu_header是无法区分P帧和