标准pcm数据(正弦波、方波、三角波)解读

一年前写了一个demo,用于生成几种标准的波形,如正弦波、方波、三角波。之前写的只有这几个功能:波形/通道/时长/频率的控制选择,这几天抽了些时间又加了增益控制功能。为了避免东西丢失或意外删除,特上传到github,有需要的可以自己下载验证。

在测量板子信号时,我们根据需要生成波形(wav封装),将得到的文件放到板子存储设备中进行播放。记得以前调试时都是找一个同事(一个好耍的憨厚朴实纯真的兄弟,名字叫jiawei)临时要的,然而数量毕竟有限,因为我可能需要不同采样率/通道/增益/频率组合的信号。。。

下面结合git仓库中的CStandardWaveGenerator和Adobe Audition来介绍声音的一些概念。像声道、采样率、增益、频率、时长等概念。以后有时间了再另起博文补充傅里叶变换,利用这个demo生成所需要的信号源。

 

示例介绍

生成信号:正弦波 + 时长100ms + 周期10ms(频率100Hz) + 单声道 + 8k采样率 + 单声道 + 6dB

执行命令:./StandardWaveGenerator.exe 0 100 10 8000 1 -6

附带信息:get sin.wav with sample_rate=8000,channle=1,duration=100 ms,period=10 ms,gain=-6 dB,pcmLen:1600

得到文件sin.wav,用Audition解读:

 

 

信号解读

1.单双声道(channel)

这个通俗讲,你用几个mic去采集信号。如果是双声道,则上图有两个波形。双声道每次采样数据量为:2chn * 16bit(s16le) = 4Bytes

 

2.采样频率(sample_rate)

这个要与信号频率(周期信号的频率)做下区别。这个是指:每秒钟的采样次数。

就如上面示例图示,采样频率是8k,代表着1s内进行了8000次采样,而只保留了100ms的信号,因此数据量大小:8000 * 2Bytes * (100/1000) = 1600Bytes,从命令输出信息也可看到。

 

3.时长(duration)

这个文件的时间长度,示例中是100ms

 

4.信号频率/信号周期(frequence/period)

这个值代表信号多长时间后又开始重复,上面示例中使用了这个“period=10 ms”来控制,即T=10ms,那么f=1/T=100Hz,从图示下半部分可以看出信号的频率是100(明显的一条黄带)。

 

5.增益(gain)

这个可以表示声音的响度,其具体含义是信号与某一个值对比:20lg(V1/V2),在音频里则与最大值V2=215=32768进行对比,那么-6dB的信号可以算出来其值为:214=16384

例如,如果我们从文件中去找出最大值是多少来确认是否属实,可以按以下这么操作:

step1. 半波最大pcm值采样序号:10ms * (1/4) / 1000ms * 8000 = 20

step2. 在文件中的offset:44 + 20*2 = 84 = 0x54,其中44为wav_header,20*2中的2代表每次采样的2Bytes

step3. 用winhex进行查找(alt+g):得到 25 40

 

 step4. 25 40代表值多少呢?由于存储格式为S16LE,S(signed)代表有符号,LE(little endian)为小端存储(先存低字节,再存高字节),那么这个采样值为0x4025 = 16421,大体上接近理论值16384。

 

版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 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帧和