音频资料(音频资料下载)

推荐整理分享音频资料(音频资料下载)，希望有所帮助，仅作参考，欢迎阅读内容。

文章相关热门搜索词:书记员听打100音频资料,吕新国居士全部音频资料,牛津树音频资料,东方睡功音频资料,反诈宣传音频资料,书记员听打80字音频资料,牛津树音频资料,书记员听打100音频资料,内容如对您有帮助，希望把文章链接给更多的朋友！

4.jpg(. KB, 下载次数: 0)

下载附件 保存到相册

-9-5 : 上传

从图中可以看出，原始波形分4段5个采样点（包括首尾），如果整数倍转换，采用了8个分段9个采样点（采样率翻倍），波形是没有改变的。但是，如果新的采样率是原来的1.5倍，采用6个分段7个采样点，新的波形就会和原波形相差很远，造成很大的误差，换言之，这是一个有损转换过程。同样，.1KHz和KHz之间的转换也是属于非整数倍转换，会带来可观的音质损失。android系统之所以不适合多媒体，是因为android系统会把所有非.1KHz的音频强制转换成.1KHz再输出。但是这问题也不大——你听到的多数音乐文件都是用.1KHz，无非是多数视频文件的音频被改变了——谁管呢。但是android一旦碰上高通，毁灭性的就来了：高通的CPU，会把.1KHz的先转换成KHz（一次有损），然后android系统再把KHz转换成.1KHz。这是最悲惨的过程。注意，这两次转换不是说效果相互抵消，而是相互叠加——你看看上图最后一个折线图，你采用原始的采样率看看，波形变化有多恐怖。所以，采用高通芯片组的android手机，无一例外音质方面都是大悲剧——包括主打音质的G，soomal评测结果：这完全是个戳头，虚假广告欺诈顾客。

3、wav文件&#;式分析详解一、综述 E文件作为多媒体中使用的声波文件&#;式之一，它是以RIFF&#;式为标准的。RIFF是英文Resource Interchange File Format的缩写，每个WAVE文件的头四个字节便是“RIFF”。 WAVE文件是由若干个Chunk组成的。按照在文件中的出现位置包括：RIFF WAVEChunk, Format Chunk, Fact Chunk(可选), Data Chunk。具体见下图：------------------------------------------------| RIFF WAVE Chunk || ID = 'RIFF' || RiffType = 'WAVE' |------------------------------------------------| Format Chunk || ID = 'fmt ' |------------------------------------------------| Fact Chunk(optional) || ID = 'fact' |------------------------------------------------| Data Chunk || ID = 'data' |------------------------------------------------ 图1 Wav&#;式包含Chunk示例 其中除了Fact Chunk外，其他三个Chunk是必须的。每个Chunk有各自的ID，位于Chunk最开始位置，作为标示，而且均为4个字节。并且紧跟在ID后面的是Chunk大小（去除ID和Size所占的字节数后剩下的其他字节数目），4个字节表示，低字节表示数&#;低位，高字节表示数&#;高位。下面具体介绍各个Chunk内容。PS： 所有数&#;表示均为低字节表示低位，高字节表示高位。二、具体介绍RIFF WAVE Chunk ================================== | |所占字节数| 具体内容 | ================================== | ID | 4 Bytes | 'RIFF' | ---------------------------------- | Size | 4 Bytes | | ---------------------------------- | Type | 4 Bytes | 'WAVE' | ---------------------------------- 图2 RIFF WAVE Chunk 以'FIFF'作为标示，然后紧跟着为size字段，该size是整个wav文件大小减去ID和Size所占用的字节数，即FileLen - 8 = Size。然后是Type字段，为'WAVE'，表示是wav文件。 结构定义如下： struct RIFF_HEADER { char szRiffID[4]; // 'R','I','F','F' DWORD dwRiffSize; char szRiffFormat[4]; // 'W','A','V','E' };Format Chunk ==================================================================== | | 字节数 | 具体内容 | ==================================================================== | ID | 4 Bytes | 'fmt ' | -------------------------------------------------------------------- | Size | 4 Bytes | 数&#;为或，则最后又附加信息 | -------------------------------------------------------------------- ---- | FormatTag | 2 Bytes | 编码方式，一般为0x | | -------------------------------------------------------------------- | | Channels | 2 Bytes | 声道数目，1--单声道；2--双声道 | | -------------------------------------------------------------------- | | SamplesPerSec | 4 Bytes | 采样频率 | | -------------------------------------------------------------------- | | AvgBytesPerSec| 4 Bytes | 每秒所需字节数 | |===> WAVE_FORMAT -------------------------------------------------------------------- | | BlockAlign | 2 Bytes | 数据块对齐单位(每个采样需要的字节数) | | -------------------------------------------------------------------- | | BitsPerSample | 2 Bytes | 每个采样需要的bit数 | | -------------------------------------------------------------------- | | | 2 Bytes | 附加信息（可选，通过Size来判断有无） | | -------------------------------------------------------------------- ---- 图3 Format Chunk 以'fmt '作为标示。一般情况下Size为，此时最后附加信息没有；如果为则最后多了2个字节的附加信息。主要由一些软件制成的wav&#;式中含有该2个字节的附加信息。 结构定义如下： struct WAVE_FORMAT { WORD wFormatTag; WORD wChannels; DWORD dwSamplesPerSec; DWORD dwAvgBytesPerSec; WORD wBlockAlign; WORD wBitsPerSample; }; struct FMT_BLOCK { char szFmtID[4]; // 'f','m','t',' ' DWORD dwFmtSize; WAVE_FORMAT wavFormat; };Fact Chunk ================================== | |所占字节数| 具体内容 | ================================== | ID | 4 Bytes | 'fact' | ---------------------------------- | Size | 4 Bytes | 数&#;为4 | ---------------------------------- | data | 4 Bytes | | ---------------------------------- 图4 Fact Chunk Fact Chunk是可选字段，一般当wav文件由某些软件转化而成，则包含该Chunk。 结构定义如下： struct FACT_BLOCK { char szFactID[4]; // 'f','a','c','t' DWORD dwFactSize; };Data Chunk ================================== | |所占字节数| 具体内容 | ================================== | ID | 4 Bytes | 'data' | ---------------------------------- | Size | 4 Bytes | | ---------------------------------- | data | | | ---------------------------------- 图5 Data Chunk Data Chunk是真正保存wav数据的地方，以'data'作为该Chunk的标示。然后是数据的大小。紧接着就是wav数据。根据Format Chunk中的声道数以及采样bit数，wav数据的bit位置可以分成以下几种形式： --------------------------------------------------------------------- | 单声道 | 取样1 | 取样2 | 取样3 | 取样4 | | |-------------------------------------------------------- | 8bit量化 | 声道0 | 声道0 | 声道0 | 声道0 | --------------------------------------------------------------------- | 双声道 | 取样1 | 取样2 | | |-------------------------------------------------------- | 8bit量化 | 声道0(左) | 声道1(右) | 声道0(左) | 声道1(右) | --------------------------------------------------------------------- | | 取样1 | 取样2 | | 单声道 |-------------------------------------------------------- | bit量化 | 声道0 | 声道0 | 声道0 | 声道0 | | | (低位字节) | (高位字节) | (低位字节) | (高位字节) | --------------------------------------------------------------------- | | 取样1 | | 双声道 |-------------------------------------------------------- | bit量化 | 声道0(左) | 声道0(左) | 声道1(右) | 声道1(右) | | | (低位字节) | (高位字节) | (低位字节) | (高位字节) | --------------------------------------------------------------------- 图6 wav数据bit位置安排方式 Data Chunk头结构定义如下： struct DATA_BLOCK { char szDataID[4]; // 'd','a','t','a' DWORD dwDataSize; };

下图是用工具ultraedit工具打开的wav文件开头数据

文件数据部分内容，数据来源于Android话筒录音生成的PCM文件转换为WAV文件。

2、有损vs无损：什么叫做有损音乐？我们可以看到，之前说过，Wav文件的比特率在Kbit/s，意味着一首5分钟的音乐大小将要达到MB。这样的大小显然难以接受，而传统的压缩方法（rar/zip）对于wav文件收效甚微。为了传输效率，音频编码的压缩算法成了热点。音频编码压缩分为两种，一种是有损，类&#;MP3之类的，特点是压缩过的文件如果解压缩成wav，波形发生了改变，虽然改变很细小，实际播放出的效果人耳难以分别；一种是无损，类&#;FLAC之类的，特点是如果转换成wav，波形和源文件毫无差异，也就是说，完全无损的记录了原始数据，好比rar/zip的压缩，解压之后的文件和源文件一模一样。比如，我们手里有一张CD，先转录成wav（文件A），A转换成flac（B）和MP3（C），C再转换成ape（D）。我们说文件A相对于CD无损，B相对于A和CD无损，C相对于A和CD是有损的，D相对于C无损，但是相对于CD有损。所以，你现在可以理解，什么叫做假无损——以有损的音源无损转换之后的文件，带着无损的面纱，长着有损的脸。

3、MP3&#;式：最老牌的音乐&#;式。MP3如何起源的不多介绍了，有兴趣的自己百度一下。MP3的特点是兼容性广阔，支持成熟，常见的MP3比特率在KBit/s左右，言下之意，WAV大小的1/6。早些时候，网络流传很多都是KBit/s，后来随着网速增加，储存介质越来越便宜，现在流行的MP3多半是以最高码率编码——恒定Kbit/s但是MP3毕竟太古老了，如果你需要做有损转换，还是建议采用aac编码吧。4、wma&#;式：微软一手养大的孩子，可惜终究不成主流。WMA全称是Windows Media Audio，是微软主打的一个封闭的&#;式。论效果，和MP3倒是不相上下，还能提供无损音质（WMA-LossLess），可惜封闭的&#;式注定难成主流。随着aac流行，和flac等无损编码崛起，wma被越来越多的人抛弃。目前也只有在VC-1&#;式的高清（wmv）中还能见到它。5、AAC&#;式：新时代的有损压缩王者。优点：相对于mp3，AAC&#;式的音质更佳，文件更小。不足：AAC属于有损压缩的&#;式，与时下流行的APE、FLAC等无损&#;式相比音质存在“本质上”的差距。加之，目前传输速度更快的USB3.0和G以上大容量MP3正在加速普及，也使得AAC头上“小巧”的光环不复存在了。前景：以发展的&#;光来看，正如“高清”正在被越来越多的人所接受一样，“无损”必定是未来音乐&#;式的绝对主流。AAC这种“有损”&#;式的前景不容乐观。AAC是开放的&#;式，因为出生就带有相当强的技术背景，表现不俗，加上被MP4规范支持，现在多数设备都具备了解码AAC音频的能力。所以对于有损压缩，aac是毫无争议的第一选择，可以说，相同音质下，AAC仅需要MP3 %的大小足以。AAC有两种分&#;式：LC-AAC和HE-AAC。LC（Low Complexity），适合用于高码率（>=KBit/s），也是常用的&#;式；HE（High Efficiency），适用于低码率，尤其是HE-AAC配备了SBR&#;PS技术，让HE-AAC在低于KBit/s的码率下无可匹敌，适合于极致压缩。6、AC3&#;式：多声道的工业选择。年，日本先锋公司宣布与美国杜比实验室合作研制成功一种崭新的环绕声制式，并命名为“杜比AC-3”。杜比数字AC-3提供的环绕声系统由五个全频域声道加一个超低音声道组成，所以被称作5.1个声道。五个声道包括前置的"左声道"、"中置声道"、"右声道"、后置的"左环绕声道"和"右环绕声道"。这些声道的频率范围均为全频域响应3-Hz。第六个声道也就是超低音声道包含了一些额外的低音信息，使得一些场景如爆炸、撞击声等的效果更好。由于这个声道的频率响应为3-Hz，所以称".1"声道。6个声道的信息在制作和还原过程中全部数字化，信息损失很少，全频段的细节十分丰富AC-3发展当初是为了应用在电影院上的，AC-3音效因为胶卷的空间实在有限，所以AC-3音效的资料是存放在胶卷上，齿孔与齿孔的中间，这部分的空间实在太小了，所以杜比的工程师只好将他们认为人耳听不到的地方加以删除，藉以节省空间，这种破坏性的压缩还是会造成失真的，但是为了迁就原有器材上的限制，这也是&#;不得已的做法。电脑上，你可以使用各式各样的&#;式，你的软件和CPU都能帮你搞定。但是对于DVD/BD，能接受的编码十分有限。AC3就是工业运用的多声道&#;式，你可以从很多蓝光文件中直接找到它。7、FLAC：最优秀的无损&#;式。FLAC即是Free Lossless Audio Codec的缩写，中文可解为无损音频压缩编码。FLAC是一套著名的自由音频压缩编码，其特点是无损压缩。不同于其他有损压缩编码如MP3 及 AAC，它不会破坏任何原有的音频资讯，所以可以还原音乐光盘音质。尽管有损压缩在失真率方面已经做得很不错了，但是%永远是一个不完美的数字——我们希望原始数据得以保留，任何丢失或者错误，终究不能被还原。而且有损转换的效果是指数级别叠加的。一个文件连续被转换成K的MP 次，音质方面就已经有可观的劣化了；而如果采用无损，再多的重加工也不怕。在网速和储存介质日益发展的今天，我们不再吝啬保留所有的原始数据——无损压缩必然成为主流。FLAC的优点主要有这三点：1、它提供了还算不错的压缩效果，基本上能节省wav %的码率；2、它是一套完全开放的&#;式，你可以出于任何目的是用。MKV这种&#;式就提供了封装flac的功能；所有字幕组毫不吝啬的使用了这个&#;式；3、它的编码算法简单高效，解码也同样省运算。因为开放，很多设备提供了硬解flac的功能。实测M9在播放ape和flac的时候，前者耗电速度是后者的%。......可以说，如果你想在你的MP3、手机里听无损，flac是最佳选择。8、APE&#;式：你真的无损了么？ape是现在你能见到的最强悍的无损压缩&#;式，主要在于它能提供最大的压缩比。好比7z比起rar和zip的优势。只不过，这个封闭的&#;式，仿佛rmvb一般，最后的阵地只在中国。以下转载《你真的无损了吗？APE的最后阵地：中国！》：全球的无损资源，按区域算，分4个大区，分别是欧美区、日韩区、台港和新家坡区、中国区。年无损资源在全球网上流行和萌芽，随着带宽的增大和提速，到年，无损资源已在全球拥有众多的粉丝和不记其数的保源站和论坛。但，有个很严重的问题摆在&#;前。在4大区里，前3个区已毫不留情的把APE抛弃了，而且弃得是那么地彻底、那么地干脆！FLAC和WV已变成前3区的绝对无 损主流，PCM的WAV其次。据查，在国外，谁上传APE，谁扣分或头衔，或直接被BAN，APE变得不受欢迎。在我们国内，情况相反，无孔不入随处开花的APE&#;式音源遍布大街小巷，它反而是绝对主流！可怜的部分无知新手网友见到FLAC和WV的作品在中国还要大惊小怪并到处翻查资料解惑！中国的人口基数大，自然按比例，APE的粉丝也多，但不意味着APE安枕无忧或适合长期保存。也许不久的将来或到洗版的那天，你们手上的APE都要被无情的&#;掉。在国外，APE说白些，已经被淘汰了，FLAC和WV两兄弟已是绝对霸主。国人还怀抱着APE&#;式死死不放，原因如下几条：1，羊群心理，一窝蜂，打个比方，街上出个交通事故，国人就爱看热闹，人越聚越多。APE的制作也是，带头的用了APE来压码，随后的为了方便，纷纷效仿和跟风，人越积越多。。。一直到现在，不用APE压码，有些人还不下载你的作品！养成习惯了。。2，很多人说APE的体积小，上传方便，其它&#;式体积大，上传耗些时间，总之APE上传省时间！ 和大家举个例，一个APE整轨压缩包是MB，另一个FLAC压缩包大些是MB，你真会为了多出来的这一点点百分比而放弃上传后者吗？或者举个反例，你的饭量是1碗，我多给你吃一汤匙，这人不会撑死吧？而且现在的网络提速已不是当初的慢如蜗牛，很多上传的作者本身就是专线的享用者，这些还是问题吗？？3，有些人说APE的音质好听，音感好，有质感、雄厚有力，人听人爱。也可以这样说，国内的听音器材太先进了，外国人都听不出好坏的东西，中国人听出来了也感觉到了，呵呵。所以用它来编码。可是，有谁回过头来看下自己的器材或播放设备？？更多的是怀抱着集成声卡和几十块的2.1音箱轰隆隆去了，也许，真把K-MP3塞进去，这占主流的人群还真听不出来。这就是盲目的认同度，先入为主了，难以扭转。4，做假的人也爱APE，发布假无损的人也爱APE。为什么呢？？分轨的K-Mp3升频后用APE来隐藏隐敝性高，很难发现，至少中国的多数菜鸟不会发现，用其它&#;式，别人不喜欢，这虚荣还怎么满足？广大的散装DJ充斥着大量MP3升频温床APE，你如要用FLAC来装，也行，但你的绝对用户会少。一句话评论，APE做假也方便,因太多用户了。5，网上二道贩子的美妙宣传，APE和WAV音质无异，APE的资源容易找，我店里最多，有APE等于有了CD，做这个的网上有好几十万人，购买的何止千万？APE便车水马龙川流不溪。可谁想过，当APE满足了上面的4点后，不说APE好，客人何在？这又是一群绝对的APE粉丝。可这是被绑着的粉丝。6，在编码软件的支持上，那铺天盖地的小猴子是太方便了，又可以批量转，又可以批量解，而FLAC呢？哎。。。百度、谷歌要找到它的官方软件是有点难，还是英文的。。怎办？用上后，还没有懒人模式？算了，不用了。到正题了，国外为什么要淘汰楼上的东西？原因也有如下几条，但这几条，相信很多人都忍受不了。1，相对于FLAC，APE太耗电了，播放时间太短。这个问题，对于拥有智能手机的、数字随身听等等要用到电池的用户，不用我说，也会站出来支持我。本人用着的是新上市的七彩虹C4，同一个整轨，APE的要比FLAC多用1半的电，本来可用8小时电的东西，4小时就要完蛋了。为什么会这样？很简单，APE的运算方式落后些，单位时间内较吃力比对手慢%，单位时间慢，解码的芯片自然功耗高，它吃力嘛，谁叫APE不是整数运算呢？2，相对于FLAC，APE的编码速度实在不敢恭维，同样的整轨，APE比FLAC解压或降压慢%--%，其它以此类推，对时间如生命的西方人，怎么忍受？当然这点在国内有个怪现像：国内的电脑都比国外的先进，都是高主频的新生代多线程机器，再慢，在国内，我们也可以等！！我们都是i7嘛。。 3，相对于FLAC，APE的播放也叫解码速度要慢%！这就牵涉到2个问题：1，烧友最恨的时基抖动（Jitter失真）在这%里加重了，（后端的器材再好，前端的微小失真都是可怕的）举个例子--不管是什么CPU或无损解码器在解压APE还原PCM时，这个%的解码延时，你们喜欢吗？能忍受吗？同样的计算圆周率万位，FLAC（秒完成了）APE（秒完成）。这多出来的Jitter失真你们一只&#;开一只&#;闭吗？当然，WAV是Jitter失真最少的，人总要完美吧？越接近完美越好吧？还有人会再认为APE的音质好些吗？（很多老烧用APE做音源和CD机拼，拼来拼去都是输，为什么呢？呵呵）2，关于听整轨APE时，很多用户都会选择定位选歌，别忘了，这%的慢速困扰同样存在，你们也可以自己体验下，用同样的整轨选歌，FLAC可比它快多了，但是最快还是WAV，还是那句话，越接近完美，不好吗？难道阁下抗拒完美？？4，老话题了，防纠错和容错能力。相对于FLAC和WV，APE太落后了（也存在严重的BUG）。一报错，等于整轨作废，又不能解压又不能播放（起码在错误的轨道是放不了），你能忍受吗？别忘了，你的这歌报错的，其它下载了这个专辑的APE用户也是一样命运，如找不回原来的压制人讨回WAV原抓来修复，你认倒霉吧！FLAC相反，基本是零出错。在这方面，我就不细说了，本人不爱转帖和转别人说过的话。一句话概括-连还原都成问题的东西，还谈什么无损？难道你会用这&#;式把你喜欢的专辑长久保存？等要解压的那天哭笑不得？？题外话：以本人的经验：本人原有T国内的APE资源（共5.2万张华语专辑），后来全转成FLAC了，耗时2年，APE的出错概率（就是不能正确还原WAV的，而且无法修复的）如按T（5.2万张）来计算损坏比例约是：7%，也就是说，张整轨，会有7张报废，应很有权威的数据了。5，FLAC和WV是开源的东西，APE呢，到现在还闭着那程序代码和版权不给人。造成全球所有操作系统对FLAC全默认支持，硬件也是，但APE就算支持，也是软件支持多，硬件支持少；问题也多，更多的是软件解码不是真正芯片原生解码（这里就产生了影响音质的二次转换问题）。这里有个识别窍门：你装好系统后，就裸机，什么播放软件不装，你看看是FLAC能放还是APE能放？好了，说得很多了，各位爱好者，醒醒吧？睁大你们的&#;睛，看看你们的硬盘，看看有多少外国人淘汰的东西！难道每个玩APE的人你们的&#;光比外国人更敏锐更洞查先机？？？？是否停留不前还是搬着那陈年的旧课本，大家权衡吧。本文观点已尽量做到客观公正、不偏不倚，直白生动！也是本人年到现在的独到见解和客观分析，把别人不敢说的或想说的话题论证的总结出来。和论坛立场无关总结：ape是一个极致压缩的&#;式，但是不是一个好的&#;式。如果你是音乐发烧友，还是建议你转投FLAC,wv,tak之流。9、新生代无损&#;式：tta/tak两者算是flac的更高效压缩版本，但是远不如flac来的那么普及。比如，能原生支持这两种&#;式的播放器少之又少，强行软件实现软解又不如flac/mp3/aac硬解那么省电。因此，只建议收藏用，不建议实际使用。比如你电脑里一堆wav的，你就可以转成tak&#;式。后文会介绍tak如何用foobar编码。、行走于有损和无损之间：奇妙的WV&#;式。WV既是WavPack，一种相当有特点的音频压缩&#;式。WavPack不仅仅是一个无损压缩&#;式，它还能同时作为有损压缩&#;式。在其独特的“hybrid”模式下，WavPack可以压缩成wv文件（有损压缩&#;式，大小一般相当于WAV文件的%左右）&#;wvc文件（修正文件，大小一般相当于WAV文件的%左右）的组合。有了对应的wvc文件，有损压缩&#;式的wv文件就变成了无损&#;式，播放时和普通的无损压缩&#;式完全一样。如果为了减少文件体积，你可以去掉这个wvc文件，这时wv文件就变成有损&#;式了,播放起来和高比特率的MP3完全一样！WavPack同时包容了无损&#;式和有损&#;式。这样的设计使得WV&#;式风靡互联网：同一个音乐，up主只要上传wv&#;wvc，下载者就可以各取所需。需要无损的，费点带宽两者都下载；否则只要下载wv就行，效果好比下载K MP3。作为收藏，哪天你硬盘吃紧了，只需要把更大的WVC删除掉，保留WV文件，就相当于将K无损的转码成K MP3。WV编码解码速度很快，容错性也较好，多种优势使得它迅速成为互联网上音乐爱好者的新宠。以上都不代表我的观念，仅转载供大家参考之用。&#;&#;

判断手机网络连接状态 有时做Android开发需要用到网络来连接服务器，如果没有网络则进行提示。代码很简单，代码如下：publicstaticbooleanisNetworkAvailable(Contextcontext){ConnectivityMana

boost全平台编译方法 0.通用规则boost自带一套编译工具bjam，bjam本身是跨平台的，并且也要自行编译出来。在boost目录下有bootstrap.sh和bootstrap.bat两个脚本分别用来编译*nix和wind

Android实现两次按下返回键退出 说明:exitTime的定义:定义成全局变量privatelongexitTime=0;下面给出onKeyDown方法的代码@OverridepublicbooleanonKeyDown(intkeyCode,KeyEventevent){if(keyCode==KeyEvent.KEYCODE_BACKevent