精华内容
下载资源
问答
  • 对于特殊的格式如OGG、AAC、AC3、MP2、FLAC等各种音频格式都可以完美转换WAV文件。当然如果您手头有WAV文件需要转换为其他音频格式,本软件同样可以轻易完成,比如将WAV转换为MP3、WAV转WMA、WAV转AAC、WAV转无损...
  •  另外,在不少参数当中看到PCM格式的存在,实际上PCM只是模拟音频信号经过数模转换之后形成的二进制序列,它代表着数字音乐的最高保真标准,它和 WAV的关系实际上是本质与形式的关系,WAV文件的采样一般就采用PCM...

    无论是MP3还是MP4,甚至手机和多媒体DC,产品所支持的各种格式往往让人眼花缭乱。特别是对于刚上手的新手玩家来说,各种格式都有哪些特性,在实际 使用当中有多少格式实用或者必须,其实有很多方面需要我们来系统的了解。这一次我们为大家带来了目前常见的多媒体格式(音频和视频)的介绍和解析,我们会 尽可能的面面俱到,并且将客观地进行总结和提供建议,为大家的使用提供参考。

    MP3(MPEG Audio Layer 3)

    实用指数:★★★★★(总分为★★★★★,下同。)

     


    常用指数:★★★★★

    音质指数:★★★

    体积指数:★★★★☆(体积最小为★★★★★,下同。)

     

        MP3自然是目前数码播放器第一大标准,它有着最为广泛的应用,以致于格式名称都成为了播放器约定俗成的名字。这个格式采用了MPEG Audio Layer 3技术,将音乐以1:10甚至更高的压缩比进行压缩,因而节省了大量的存储空间,符合数码时代多数用户对于数码音乐的需要,是一种有损的音频压缩编码技 术。同时在音乐压缩当中,这项技术保留了人耳最为灵敏的频段,而去掉了那些人耳听觉系统所无法察觉的声音,达到最大限度保证了声音还原真实的效果。一般来 说我们衡量MP3的标准就是比特率,常见的诸如128kpbs、192kpbs、256kpbs、320kpbs等,越高的数值会有越高的音乐质量,文件 大小也会相应增加,这样也为玩家保留了一定的音质可玩性和提升潜力。

     

    人耳等响度曲线图

        实际上,对于不太发烧的用户来说,MP3格式已经完全能够满足日常的使用。MP3压缩编码技术已经相当成熟,优势非常明显。MP3格式音乐文件的来源最为 广泛,制作也非常简单,和PC以及其它媒介有着完善的交互和兼容性,同时它的音乐质量和文件体积之间形成了完美的均衡,因此哪怕现在大容量播放器越来越 多,MP3格式也仍然是我们的首选,并且从现在的市场发展来看,这样的情况还将持续相当长的时间。

    WMA(Windows Media Audio)

    实用指数:★★★★★

    常用指数:★★★★★

    音质指数:★★★☆

    体积指数:★★★★★

     

    WMA的微软背景足够强大

        微软凭借其在软件系统方面的绝对优势,能够很好的推广普及自己的技术标准,WMA就是一个出名的例子。它是微软专门推出为对抗MP3格式的音频格式,它所 应用的解码和压缩技术使得WMA格式在多个方面相比MP3格式有着一定的优势,它以减少数据流量来达到压缩目的,在较低的采样率下也能够得到良好的音乐质 量,最大程度地保证音质效果,1:18的压缩比让WMA文件比同类MP3文件小了将近一半,特别是在数码播放器普及的早期,WMA凭借这一特性得到了用户 的广泛支持和采用。而在现在虽然体积的优势越来越被人忽略,但在应用方面,WMA格式有着微软Windows Media Player的鼎力支持,天生有着其它格式所不能及的发展土壤,在网络传输和在线播放方面WMA的表现也是非常出色。

     

    Windows Media Player未来广大

        WMA格式的普及率不亚于MP3格式,不过并非是所有播放器都对WMA格式买账,比如苹果iPod就从来不支持WMA格式,微软和苹果在系统平台方面的对 立让这样的情况不难理解,而消费者可要注意这一点了。另外WMA格式还有相当的潜力,它的可保护性能够有效地进行版权控制,同时WMA在低采样率的情况下 有着比MP3格式好很多的音质表现,如果播放器的存储空间不大,WMA将会是最佳选择。

    WAV(WAVE)

    实用指数:★★

    常用指数:★★

    音质指数:★★★★★

    体积指数:★

     

        WAV是微软开发的又一种音频格式,它主要应用在高端或专业领域,它有着浓重的工业化特征,它来源于对声音模拟波形的采样,支持多种压缩算法,支持多种音 频采样率和声道,采用44.1kHz的采样频率,16位量化位数,音质与CD相差无几(44.1k×16×2=1411.2kbps,2为双声道),实际 上在多数时候被玩家直接称为了CD格式,文件体积也基本上和CD碟片一致,当然,这就大大影响了WAV格式的普及,加之WAV格式一向给人以“毛坯”的感 觉,专业的录音设备基本都默认WAV格式,但作为无损格式却没有APE和FLAC那样有光鲜的包装,因此虽然现在几乎所有数码播放器产品都支持WAV格 式,但用户用到的非常少,网络资源当中直接以WAV格式共享的也较为少见。不过,从CD碟片直接提取制作WAV文件却比较方便,这算是留给用户在后期自由 发挥的空间。

     

    说到WAV就让人想起这些波形

        另外,在不少参数当中看到PCM格式的存在,实际上PCM只是模拟音频信号经过数模转换之后形成的二进制序列,它代表着数字音乐的最高保真标准,它和 WAV的关系实际上是本质与形式的关系,WAV文件的采样一般就采用PCM编码。不过在Hi-MD当中,索尼提出的线性PCM格式,就使得PCM文件能够 直接应用,其实和WAV应用在MP3播放器上是一个道理。

    OGG(Ogg Vorbis)

    实用指数:★★★

    常用指数:★★★

    音质指数:★★★★

    体积指数:★★★★

     

    OGG的标志鱼

        支持OGG格式曾经一度是MP3播放器的卖点,这是一种先进的有损音频压缩技术,因为开发的时间较晚,在诸多方面对应MP3格式都有明显优势,它能够在相 对较低的数据速率下实现比MP3更好的音质效果,同时它支持VBR(可变比特率)和ABR(平均比特率)两种编码方式,比MP3的CBR(固定比特率)相 比能够保留更多声音细节,同时应用和扩展方面有着更广大的发挥空间,比如它有灵活的ID3设置,还具有比特率缩放功能,可以不用重新编码来调节音频文件的 比特率,一切都非常人性化。

     

    iriver的N11较早支持OGG格式

        OGG格式的人性化贯穿于它出现和发展的始终,这源于它的开源性质,OGG一个开源的技术标准,它完全免费,没有MP3格式方面的专利限制,另外它在后期 可以有各种自由并且独立的二次开发,因而得到了许多音频软件和服务商的支持。不过在我们的日常使用当中,OGG仍然不是一个常用选择,虽然它有着体积小音 质好的特性,但制作比较麻烦,网络共享更是少之又少,OGG的优势还没有完全发挥出来。

    AAC

    实用指数:★★★★

    常用指数:★★★

    音质指数:★★★★

    体积指数:★★★★☆

     

    iPod一直支持AAC

        AAC出现的时间其实非常早,但由于各方面的原因一直未能普及,虽然iPod都一直支持AAC格式(iTunes Store的选择),但这实在不是国内用户的选择(在手机上应用反而更多一些)。不过AAC终归与其它多数格式不同,AAC格式虽然有技术专利限制,不过 它的技术掌握在多家厂商手中,彼此没有秘密可言,这也使得它拥有了众多的编码器,给用户的选择非常多。

        算法方面,AAC是一种高压缩比的音频压缩技术,压缩比达到1:20,但AAC的高解析力特性让它在音质方面很有保障,它的多声道特性能够支持1-48个 全音域音轨和15个低频音轨。换句话说,AAC能够在较小的文件体积下达到更好的音质表现,这符合现在数码音乐的发展趋势,加之AAC有着多种规格版本和 多家厂商进行持续研发,未来还有相当的发展空间。

    APE

    实用指数:★★★★☆

    常用指数:★★★★★

    音质指数:★★★★★

    体积指数:★★☆

     

    APE的猴子也升级成科技猴了

        APE格式是目前流行的几种无损格式的一种,它的出现颇具传奇色彩,这完全是一个独立的个人行为,但却正好投合了数码音乐时代发烧级用户追求高音质的需 要,成为了行业领域当中用户的主要选择,特别是在国内,APE有着超高的人气,虽然文件体积巨大,但网络共享同样不少。一般我们可以将音频CD上的音频数 据文件压缩成整张APE,也能够以单独的曲目分开,或者还原成原来的CD音频文件。APE格式的文件大小一般为CD文件的一半,作为无损格式来说,30多 MB的大小完全在用户可以接受的范围,加上现在大容量播放器成为趋势,APE得到音乐爱好者的追捧也就不难理解。

     

    昂达VX939率先支持APE

        APE格式给了很多从CD随身听过渡到MP3播放器的用户以美好的回忆,不少音乐爱好者硬盘里面只留APE音乐就是一个例证,同时APE格式给了不少崇尚 DIY的玩家足够的发挥空间,压制APE文件或者单曲分离虽然烦琐但足够有趣。总的来说,APE应用广泛,音质出色,体积的问题瑕不掩瑜,毕竟世上没有完 美的东西。它有着庞大的保有量和在玩家群当中已经建立起的良好口碑,MP3播放器支持APE格式确实是非常实用的。

    FLAC(Free Lossless Audio Codec)

    实用指数:★★★★★

    常用指数:★★★★☆

    音质指数:★★★★★

    体积指数:★★☆

     

        从FLAC的全称(Free Lossless Audio Codec/免费无损音频格式)我们就知道它的性质,这是一个专门为数码音频处理而设计的压缩方式,提供了更大的压缩比率,同时保持了接近CD水平的音乐 质量。作为一个新兴的无损格式,FLAC的技术完全开放,同时对于硬件播放的良好支持为它的发展提供了最大契机,能够直接在PC播放器或者数码播放器当中 播放,兼容性极佳,并且它的编码技术还在不断完善,而在国外FLAC的使用率已经超过了APE,算得上是未来无损音频格式的首选。

     

    COWON的U3也较早支持FLAC

        FLAC文件的体积同样约等于普通音频CD的一半,并且也能够自由地互相转换,所以它也是音乐光盘存储在电脑上的最好选择之一,它会完整保留音频的原始资 料,用户可以随时将其转回光盘,音乐质量不会有任何改变,而在播放当中,FLAC文件的每个数据帧都包含了解码所需的全部信息,中间的错误不会影响其它帧 的正常播放,这保证了它的实用有效和最小的网络时间延迟。目前在国内市场上,FLAC已经是和APE齐名的两大最常用无损音频格式之一,并且它的编码技术 原理使得它在未来有超过APE的巨大的发展空间。

     

    本文来自CSDN博客,转载请标明出处:http://blog.csdn.net/yueyihua/archive/2010/04/20/5508346.aspx

    展开全文
  • 这是我在网上看到的关于各种音频格式最全的一个帖子,特地转载过来,供大家参考。在些对收集者和各位作者表示真诚的感谢。...Wav全称是Wave,就是将音频文件的波形完整记录。而波形的存在,可以想象为是折线
    这是我在网上看到的关于各种音频格式最全的一个帖子,特地转载过来,供大家参考。在些对收集者和各位作者表示真诚的感谢。
    

    http://www.pt80.net/thread-663924-1-1.html

    1、WAV文件:采样率(Sample Rate),深度(bit-depth)WAV文件可以说是最原始的数字化音频格式了。Wav全称是Wave,就是将音频文件的波形完整记录。而波形的存在,可以想象为是折线图一般的东西。想记录波形,就需要两个最基本的参数:

    1、采样率,我们以怎样的频率记录波形的变化。44.1KHz,意味着每秒选取44100个采样点;48KHz意味着每秒选取48000个采样点。

    出于历史原因,所有CD一律采用44.1KHz,而DVD/BD视频音轨一律采用48KHz。所以不出意外,你听到的那些音乐都是44.1KHz,而你看的视频,它们的音频一般都采用48KHz的采样率。

    如下图所示,原则上更高的采样率更为精准,但是一般认为44.1KHz就接近人耳极限了。
     


    2、深度,我们用多少字节的储存量来储存音频波形。下图是在图像领域16色深和4色深的区别,音频领域同样适用。一般采用的是16bit,及更高的24bit,再高的深度意义不大。


       


    有了这些信息不难回答,为什么常见的WAV比特率是1141KBit/s了:44.1KHz * 32bit =1141.2
    题外话:非整数倍SRC(Sample Rate Convert,采样率转换)带来的毁灭性后果。

    既然原则上采样率越高越好,是不是意味着我们可以随便改变采样率呢?答案是否定的:

     

    从图中可以看出,原始波形分4段5个采样点(包括首尾),如果整数倍转换,采用了8个分段9个采样点(采样率翻倍),波形是没有改变的。但是,如果新的采样率是原来的1.5倍,采用6个分段7个采样点,新的波形就会和原波形相差很远,造成很大的误差,换言之,这是一个有损转换过程。同样,44.1KHz和48KHz之间的转换也是属于非整数倍转换,会带来可观的音质损失。


    android系统之所以不适合多媒体,是因为android系统会把所有非44.1KHz的音频强制转换成44.1KHz再输出。但是这问题也不大——你听到的多数音乐文件都是用44.1KHz,无非是多数视频文件的音频被改变了——谁管呢。

    但是android一旦碰上高通,毁灭性的就来了:
    高通的CPU,会把44.1KHz的先转换成48KHz(一次有损),然后android系统再把48KHz转换成44.1KHz。这是最悲惨的过程。注意,这两次转换不是说效果相互抵消,而是相互叠加——你看看上图最后一个折线图,你采用原始的采样率看看,波形变化有多恐怖。

    所以,采用高通芯片组的android手机,无一例外音质方面都是大悲剧——包括主打音质的G18,soomal评测结果:这完全是个戳头,虚假广告欺诈顾客。
    2、有损vs无损:什么叫做有损音乐?
    我们可以看到,之前说过,Wav文件的比特率在1411Kbit/s,意味着一首5分钟的音乐大小将要达到52MB。这样的大小显然难以接受,而传统的压缩方法(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比特率在200KBit/s左右,言下之意,WAV大小的1/6。
    早些时候,网络流传很多都是128KBit/s,后来随着网速增加,储存介质越来越便宜,现在流行的MP3多半是以最高码率编码——恒定320Kbit/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和16G以上大容量MP3正在加速普及,也使得AAC头上“小巧”的光环不复存在了。

    前景:以发展的眼光来看,正如“高清”正在被越来越多的人所接受一样,“无损”必定是未来音乐格式的绝对主流。AAC这种“有损”格式的前景不容乐观。

    AAC是开放的格式,因为出生就带有相当强的技术背景,表现不俗,加上被MP4规范支持,现在多数设备都具备了解码AAC音频的能力。所以对于有损压缩,aac是毫无争议的第一选择,可以说,相同音质下,AAC仅需要MP3 60%的大小足以。

    AAC有两种分格式:LC-AAC和HE-AAC。LC(Low Complexity),适合用于高码率(>=96KBit/s),也是常用的格式;HE(High Efficiency),适用于低码率,尤其是HE-AAC配备了SBR+PS技术,让HE-AAC在低于48KBit/s的码率下无可匹敌,适合于极致压缩。
    6、AC3格式:多声道的工业选择。1994年,日本先锋公司宣布与美国杜比实验室合作研制成功一种崭新的环绕声制式,并命名为“杜比AC-3”。

    杜比数字AC-3提供的环绕声系统由五个全频域声道加一个超低音声道组成,所以被称作5.1个声道。五个声道包括前置的"左声道"、"中置声道"、"右声道"、后置的"左环绕声道"和"右环绕声道"。这些声道的频率范围均为全频域响应3-20000Hz。第六个声道也就是超低音声道包含了一些额外的低音信息,使得一些场景如爆炸、撞击声等的效果更好。由于这个声道的频率响应为3-120Hz,所以称".1"声道。6个声道的信息在制作和还原过程中全部数字化,信息损失很少,全频段的细节十分丰富

    AC-3发展当初是为了应用在电影院上的,AC-3音效因为胶卷的空间实在有限,所以AC-3音效的资料是存放在胶卷上,齿孔与齿孔的中间,这部分的空间实在太小了,所以杜比的工程师只好将他们认为人耳听不到的地方加以删除,藉以节省空间,这种破坏性的压缩还是会造成失真的,但是为了迁就原有器材上的限制,这也是逼不得已的做法。

    电脑上,你可以使用各式各样的格式,你的软件和CPU都能帮你搞定。但是对于DVD/BD,能接受的编码十分有限。AC3就是工业运用的多声道格式,你可以从很多蓝光文件中直接找到它。
    7、FLAC:最优秀的无损格式。
    FLAC即是Free Lossless Audio Codec的缩写,中文可解为无损音频压缩编码。FLAC是一套著名的自由音频压缩编码,其特点是无损压缩。不同于其他有损压缩编码如MP3 及 AAC,它不会破坏任何原有的音频资讯,所以可以还原音乐光盘音质。

    尽管有损压缩在失真率方面已经做得很不错了,但是99%永远是一个不完美的数字——我们希望原始数据得以保留,任何丢失或者错误,终究不能被还原。而且有损转换的效果是指数级别叠加的。一个文件连续被转换成320K的MP31 10次,音质方面就已经有可观的劣化了;而如果采用无损,再多的重加工也不怕。在网速和储存介质日益发展的今天,我们不再吝啬保留所有的原始数据——无损压缩必然成为主流。

    FLAC的优点主要有这三点:
    1、它提供了还算不错的压缩效果,基本上能节省wav 40%的码率;
    2、它是一套完全开放的格式,你可以出于任何目的是用。MKV这种格式就提供了封装flac的功能;所有字幕组毫不吝啬的使用了这个格式;
    3、它的编码算法简单高效,解码也同样省运算。因为开放,很多设备提供了硬解flac的功能。实测M9在播放ape和flac的时候,前者耗电速度是后者的150%。......

    可以说,如果你想在你的MP3、手机里听无损,flac是最佳选择。


    8、APE格式:你真的无损了么?ape是现在你能见到的最强悍的无损压缩格式,主要在于它能提供最大的压缩比。好比7z比起rar和zip的优势。

    只不过,这个封闭的格式,仿佛rmvb一般,最后的阵地只在中国。

    以下转载《你真的无损了吗?APE的最后阵地:中国!》:

    全球的无损资源,按区域算,分4个大区,分别是欧美区、日韩区、台港和新家坡区、中国区。04年无损资源在全球网上流行和萌芽,随着带宽的增大和提速,到2011年,无损资源已在全球拥有众多的粉丝和不记其数的保源站和论坛。但,有个很严重的问题摆在眼前。在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整轨压缩包是400MB,另一个FLAC压缩包大些是409MB,你真会为了多出来的这一点点百分比而放弃上传后者吗?或者举个反例,你的饭量是1碗,我多给你吃一汤匙,这人不会撑死吧?而且现在的网络提速已不是当初的慢如蜗牛,很多上传的作者本身就是专线的享用者,这些还是问题吗??
    3,有些人说APE的音质好听,音感好,有质感、雄厚有力,人听人爱。也可以这样说,国内的听音器材太先进了,外国人都听不出好坏的东西,中国人听出来了也感觉到了,呵呵。所以用它来编码。可是,有谁回过头来看下自己的器材或播放设备??更多的是怀抱着集成声卡和几十块的2.1音箱轰隆隆去了,也许,真把320K-MP3塞进去,这占主流的人群还真听不出来。这就是盲目的认同度,先入为主了,难以扭转。
    4,做假的人也爱APE,发布假无损的人也爱APE。为什么呢??分轨的320K-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的运算方式落后些,单位时间内较吃力比对手慢30%,单位时间慢,解码的芯片自然功耗高,它吃力嘛,谁叫APE不是整数运算呢?
    2,相对于FLAC,APE的编码速度实在不敢恭维,同样的整轨,APE比FLAC解压或降压慢40%--50%,其它以此类推,对时间如生命的西方人,怎么忍受?当然这点在国内有个怪现像:国内的电脑都比国外的先进,都是高主频的新生代多线程机器,再慢,在国内,我们也可以等!!我们都是i7嘛。。 3,相对于FLAC,APE的播放也叫解码速度要慢30%!这就牵涉到2个问题:1,烧友最恨的时基抖动(Jitter失真)在这30%里加重了,(后端的器材再好,前端的微小失真都是可怕的)举个例子--不管是什么CPU或无损解码器在解压APE还原PCM时,这个30%的解码延时,你们喜欢吗?能忍受吗?同样的计算圆周率100万位,FLAC(10秒完成了)APE(13秒完成)。这多出来的Jitter失真你们一只眼开一只眼闭吗?当然,WAV是Jitter失真最少的,人总要完美吧?越接近完美越好吧?还有人会再认为APE的音质好些吗?(很多老烧用APE做音源和CD机拼,拼来拼去都是输,为什么呢?呵呵)2,关于听整轨APE时,很多用户都会选择定位选歌,别忘了,这30%的慢速困扰同样存在,你们也可以自己体验下,用同样的整轨选歌,FLAC可比它快多了,但是最快还是WAV,还是那句话,越接近完美,不好吗?难道阁下抗拒完美??
    4,老话题了,防纠错和容错能力。相对于FLAC和WV,APE太落后了(也存在严重的BUG)。一报错,等于整轨作废,又不能解压又不能播放(起码在错误的轨道是放不了),你能忍受吗?别忘了,你的这歌报错的,其它下载了这个专辑的APE用户也是一样命运,如找不回原来的压制人讨回WAV原抓来修复,你认倒霉吧!FLAC相反,基本是零出错。在这方面,我就不细说了,本人不爱转帖和转别人说过的话。一句话概括-连还原都成问题的东西,还谈什么无损?难道你会用这格式把你喜欢的专辑长久保存?等要解压的那天哭笑不得??题外话:以本人的经验:本人原有12T国内的APE资源(共5.2万张华语专辑),后来全转成FLAC了,耗时2年,APE的出错概率(就是不能正确还原WAV的,而且无法修复的)如按12T(5.2万张)来计算损坏比例约是:7%,也就是说,100张整轨,会有7张报废,应很有权威的数据了。
    5,FLAC和WV是开源的东西,APE呢,到现在还闭着那程序代码和版权不给人。造成全球所有操作系统对FLAC全默认支持,硬件也是,但APE就算支持,也是软件支持多,硬件支持少;问题也多,更多的是软件解码不是真正芯片原生解码(这里就产生了影响音质的二次转换问题)。这里有个识别窍门:你装好系统后,就裸机,什么播放软件不装,你看看是FLAC能放还是APE能放?好了,说得很多了,各位爱好者,醒醒吧?睁大你们的眼睛,看看你们的硬盘,看看有多少外国人淘汰的东西!难道每个玩APE的人你们的眼光比外国人更敏锐更洞查先机????是否停留不前还是搬着那陈年的旧课本,大家权衡吧。 

    本文观点已尽量做到客观公正、不偏不倚,直白生动!也是本人04年到现在的独到见解和客观分析,把别人不敢说的或想说的话题论证的总结出来。和论坛立场无关



    总结:ape是一个极致压缩的格式,但是不是一个好的格式。如果你是音乐发烧友,还是建议你转投FLAC,wv,tak之流。
    9、新生代无损格式:tta/tak
    两者算是flac的更高效压缩版本,但是远不如flac来的那么普及。比如,能原生支持这两种格式的播放器少之又少,强行软件实现软解又不如flac/mp3/aac硬解那么省电。因此,只建议收藏用,不建议实际使用。比如你电脑里一堆wav的,你就可以转成tak格式。后文会介绍tak如何用foobar编码。

    10、行走于有损和无损之间:奇妙的WV格式。

    WV既是WavPack,一种相当有特点的音频压缩格式。

    WavPack不仅仅是一个无损压缩格式,它还能同时作为有损压缩格式。在其独特的“hybrid”模式下,WavPack可以压缩成wv文件(有损压缩格式,大小一般相当于WAV文件的23%左右)+wvc文件(修正文件,大小一般相当于WAV文件的41%左右)的组合。有了对应的wvc文件,有损压缩格式的wv文件就变成了无损格式,播放时和普通的无损压缩格式完全一样。如果为了减少文件体积,你可以去掉这个wvc文件,这时wv文件就变成有损格式了,播放起来和高比特率的MP3完全一样!WavPack同时包容了无损格式和有损格式。

    这样的设计使得WV格式风靡互联网:同一个音乐,up主只要上传wv+wvc,下载者就可以各取所需。需要无损的,费点带宽两者都下载;否则只要下载wv就行,效果好比下载320K MP3。作为收藏,哪天你硬盘吃紧了,只需要把更大的WVC删除掉,保留WV文件,就相当于将700K无损的转码成320K MP3。

    WV编码解码速度很快,容错性也较好,多种优势使得它迅速成为互联网上音乐爱好者的新宠。
    展开全文
  •  另外,在不少参数当中看到PCM格式的存在,实际上PCM只是模拟音频信号经过数模转换之后形成的二进制序列,它代表着数字音乐的最高保真标准,它和 WAV的关系实际上是本质与形式的关系,WAV文件的采样一般就采用PCM...

    无论是MP3还是MP4,甚至手机和多媒体DC,产品所支持的各种格式往往让人眼花缭乱。特别是对于刚上手的新手玩家来说,各种格式都有哪些特性,在实际 使用当中有多少格式实用或者必须,其实有很多方面需要我们来系统的了解。这一次我们为大家带来了目前常见的多媒体格式(音频和视频)的介绍和解析,我们会 尽可能的面面俱到,并且将客观地进行总结和提供建议,为大家的使用提供参考。

    MP3(MPEG Audio Layer 3)

    实用指数:★★★★★(总分为★★★★★,下同。)

     



    常用指数:★★★★★

    音质指数:★★★

    体积指数:★★★★☆(体积最小为★★★★★,下同。)

     

        MP3自然是目前数码播放器第一大标准,它有着最为广泛的应用,以致于格式名称都成为了播放器约定俗成的名字。这个格式采用了MPEG Audio Layer 3技术,将音乐以1:10甚至更高的压缩比进行压缩,因而节省了大量的存储空间,符合数码时代多数用户对于数码音乐的需要,是一种有损的音频压缩编码技 术。同时在音乐压缩当中,这项技术保留了人耳最为灵敏的频段,而去掉了那些人耳听觉系统所无法察觉的声音,达到最大限度保证了声音还原真实的效果。一般来 说我们衡量MP3的标准就是比特率,常见的诸如128kpbs、192kpbs、256kpbs、320kpbs等,越高的数值会有越高的音乐质量,文件 大小也会相应增加,这样也为玩家保留了一定的音质可玩性和提升潜力。

    点击查看原图

    人耳等响度曲线图

        实际上,对于不太发烧的用户来说,MP3格式已经完全能够满足日常的使用。MP3压缩编码技术已经相当成熟,优势非常明显。MP3格式音乐文件的来源最为 广泛,制作也非常简单,和PC以及其它媒介有着完善的交互和兼容性,同时它的音乐质量和文件体积之间形成了完美的均衡,因此哪怕现在大容量播放器越来越 多,MP3格式也仍然是我们的首选,并且从现在的市场发展来看,这样的情况还将持续相当长的时间。

    WMA(Windows Media Audio)

    实用指数:★★★★★

    常用指数:★★★★★

    音质指数:★★★☆

    体积指数:★★★★★

    点击查看原图

    WMA的微软背景足够强大

        微软凭借其在软件系统方面的绝对优势,能够很好的推广普及自己的技术标准,WMA就是一个出名的例子。它是微软专门推出为对抗MP3格式的音频格式,它所 应用的解码和压缩技术使得WMA格式在多个方面相比MP3格式有着一定的优势,它以减少数据流量来达到压缩目的,在较低的采样率下也能够得到良好的音乐质 量,最大程度地保证音质效果,1:18的压缩比让WMA文件比同类MP3文件小了将近一半,特别是在数码播放器普及的早期,WMA凭借这一特性得到了用户 的广泛支持和采用。而在现在虽然体积的优势越来越被人忽略,但在应用方面,WMA格式有着微软Windows Media Player的鼎力支持,天生有着其它格式所不能及的发展土壤,在网络传输和在线播放方面WMA的表现也是非常出色。

    点击查看原图

    Windows Media Player未来广大

        WMA格式的普及率不亚于MP3格式,不过并非是所有播放器都对WMA格式买账,比如苹果iPod就从来不支持WMA格式,微软和苹果在系统平台方面的对 立让这样的情况不难理解,而消费者可要注意这一点了。另外WMA格式还有相当的潜力,它的可保护性能够有效地进行版权控制,同时WMA在低采样率的情况下 有着比MP3格式好很多的音质表现,如果播放器的存储空间不大,WMA将会是最佳选择。

    WAV(WAVE)

    实用指数:★★

    常用指数:★★

    音质指数:★★★★★

    体积指数:★

    点击查看原图

        WAV是微软开发的又一种音频格式,它主要应用在高端或专业领域,它有着浓重的工业化特征,它来源于对声音模拟波形的采样,支持多种压缩算法,支持多种音 频采样率和声道,采用44.1kHz的采样频率,16位量化位数,音质与CD相差无几(44.1k×16×2=1411.2kbps,2为双声道),实际 上在多数时候被玩家直接称为了CD格式,文件体积也基本上和CD碟片一致,当然,这就大大影响了WAV格式的普及,加之WAV格式一向给人以“毛坯”的感 觉,专业的录音设备基本都默认WAV格式,但作为无损格式却没有APE和FLAC那样有光鲜的包装,因此虽然现在几乎所有数码播放器产品都支持WAV格 式,但用户用到的非常少,网络资源当中直接以WAV格式共享的也较为少见。不过,从CD碟片直接提取制作WAV文件却比较方便,这算是留给用户在后期自由 发挥的空间。

    点击查看原图

    说到WAV就让人想起这些波形

        另外,在不少参数当中看到PCM格式的存在,实际上PCM只是模拟音频信号经过数模转换之后形成的二进制序列,它代表着数字音乐的最高保真标准,它和 WAV的关系实际上是本质与形式的关系,WAV文件的采样一般就采用PCM编码。不过在Hi-MD当中,索尼提出的线性PCM格式,就使得PCM文件能够 直接应用,其实和WAV应用在MP3播放器上是一个道理。

    OGG(Ogg Vorbis)

    实用指数:★★★

    常用指数:★★★

    音质指数:★★★★

    体积指数:★★★★

    点击查看原图

    OGG的标志鱼

        支持OGG格式曾经一度是MP3播放器的卖点,这是一种先进的有损音频压缩技术,因为开发的时间较晚,在诸多方面对应MP3格式都有明显优势,它能够在相 对较低的数据速率下实现比MP3更好的音质效果,同时它支持VBR(可变比特率)和ABR(平均比特率)两种编码方式,比MP3的CBR(固定比特率)相 比能够保留更多声音细节,同时应用和扩展方面有着更广大的发挥空间,比如它有灵活的ID3设置,还具有比特率缩放功能,可以不用重新编码来调节音频文件的 比特率,一切都非常人性化。

    点击查看原图

    iriver的N11较早支持OGG格式

        OGG格式的人性化贯穿于它出现和发展的始终,这源于它的开源性质,OGG一个开源的技术标准,它完全免费,没有MP3格式方面的专利限制,另外它在后期 可以有各种自由并且独立的二次开发,因而得到了许多音频软件和服务商的支持。不过在我们的日常使用当中,OGG仍然不是一个常用选择,虽然它有着体积小音 质好的特性,但制作比较麻烦,网络共享更是少之又少,OGG的优势还没有完全发挥出来。

    AAC

    实用指数:★★★★

    常用指数:★★★

    音质指数:★★★★

    体积指数:★★★★☆

    点击查看原图

    iPod一直支持AAC

        AAC出现的时间其实非常早,但由于各方面的原因一直未能普及,虽然iPod都一直支持AAC格式(iTunes Store的选择),但这实在不是国内用户的选择(在手机上应用反而更多一些)。不过AAC终归与其它多数格式不同,AAC格式虽然有技术专利限制,不过 它的技术掌握在多家厂商手中,彼此没有秘密可言,这也使得它拥有了众多的编码器,给用户的选择非常多。

        算法方面,AAC是一种高压缩比的音频压缩技术,压缩比达到1:20,但AAC的高解析力特性让它在音质方面很有保障,它的多声道特性能够支持1-48个 全音域音轨和15个低频音轨。换句话说,AAC能够在较小的文件体积下达到更好的音质表现,这符合现在数码音乐的发展趋势,加之AAC有着多种规格版本和 多家厂商进行持续研发,未来还有相当的发展空间。

    APE

    实用指数:★★★★☆

    常用指数:★★★★★

    音质指数:★★★★★

    体积指数:★★☆

    点击查看原图

    APE的猴子也升级成科技猴了

        APE格式是目前流行的几种无损格式的一种,它的出现颇具传奇色彩,这完全是一个独立的个人行为,但却正好投合了数码音乐时代发烧级用户追求高音质的需 要,成为了行业领域当中用户的主要选择,特别是在国内,APE有着超高的人气,虽然文件体积巨大,但网络共享同样不少。一般我们可以将音频CD上的音频数 据文件压缩成整张APE,也能够以单独的曲目分开,或者还原成原来的CD音频文件。APE格式的文件大小一般为CD文件的一半,作为无损格式来说,30多 MB的大小完全在用户可以接受的范围,加上现在大容量播放器成为趋势,APE得到音乐爱好者的追捧也就不难理解。

    点击查看原图

    昂达VX939率先支持APE

        APE格式给了很多从CD随身听过渡到MP3播放器的用户以美好的回忆,不少音乐爱好者硬盘里面只留APE音乐就是一个例证,同时APE格式给了不少崇尚 DIY的玩家足够的发挥空间,压制APE文件或者单曲分离虽然烦琐但足够有趣。总的来说,APE应用广泛,音质出色,体积的问题瑕不掩瑜,毕竟世上没有完 美的东西。它有着庞大的保有量和在玩家群当中已经建立起的良好口碑,MP3播放器支持APE格式确实是非常实用的。

    FLAC(Free Lossless Audio Codec)

    实用指数:★★★★★

    常用指数:★★★★☆

    音质指数:★★★★★

    体积指数:★★☆

    点击查看原图

        从FLAC的全称(Free Lossless Audio Codec/免费无损音频格式)我们就知道它的性质,这是一个专门为数码音频处理而设计的压缩方式,提供了更大的压缩比率,同时保持了接近CD水平的音乐 质量。作为一个新兴的无损格式,FLAC的技术完全开放,同时对于硬件播放的良好支持为它的发展提供了最大契机,能够直接在PC播放器或者数码播放器当中 播放,兼容性极佳,并且它的编码技术还在不断完善,而在国外FLAC的使用率已经超过了APE,算得上是未来无损音频格式的首选。

    点击查看原图

    COWON的U3也较早支持FLAC

        FLAC文件的体积同样约等于普通音频CD的一半,并且也能够自由地互相转换,所以它也是音乐光盘存储在电脑上的最好选择之一,它会完整保留音频的原始资 料,用户可以随时将其转回光盘,音乐质量不会有任何改变,而在播放当中,FLAC文件的每个数据帧都包含了解码所需的全部信息,中间的错误不会影响其它帧 的正常播放,这保证了它的实用有效和最小的网络时间延迟。目前在国内市场上,FLAC已经是和APE齐名的两大最常用无损音频格式之一,并且它的编码技术 原理使得它在未来有超过APE的巨大的发展空间。

    展开全文
  • android音频编辑之音频转换PCM与WAV

    万次阅读 2018-01-12 14:15:48
    转载请标明出处: ... 本文出自:hesong的专栏 前言 本篇开始讲解在Android平台上进行的音频编辑开发,首先需要对音频相关概念有基础的认识。所以本篇要讲解以下内容...2. WAV和PCM的区别和联系 3. WAV文件头信息 4.

    转载请标明出处:
    http://blog.csdn.net/hesong1120/article/details/79043482
    本文出自:hesong的专栏

    前言

    本篇开始讲解在Android平台上进行的音频编辑开发,首先需要对音频相关概念有基础的认识。所以本篇要讲解以下内容:
    1. 常用音频格式简介
    2. WAV和PCM的区别和联系
    3. WAV文件头信息
    4. 采样率简介
    5. 声道数和采样位数下的PCM编码
    6. 音频文件解码
    7. PCM文件转WAV文件

    现在先给出音频编辑的效果图,看看能不能提高大家的积极性~,哈哈



    常用音频格式简介

    在Android平台上进行音频开发,首先需要对常用的音频格式有个大致的了解。在Android平台上,常用的音频格式有:

    • WAV

    WAV格式是微软公司开发的一种声音文件格式,也叫波形声音文件,是最早的数字音频格式,被Windows平台及其应用程序广泛支持。

    WAV格式支持许多压缩算法,支持多种音频位数、采样频率和声道,采用44.1kHz的采样频率,16位量化位数,因此WAV的音质与CD相差无几,但WAV格式对存储空间需求太大不便于交流和传播。

    补充:无损格式,缺点:体积十分大!

    • MP3

    MP3的全称是Moving Picture Experts Group Audio Layer III。简单的说,MP3就是一种音频压缩技术,由于这种压缩方式的全称叫MPEG Audio Layer3,所以人们把它简称为MP3。
    MP3是利用 MPEG Audio Layer 3 的技术,将音乐以1:10 甚至 1:12 的压缩率,压缩成容量较小的file,换句话说,能够在音质丢失很小的情况下把文件压缩到更小的程度。而且还非常好的保持了原来的音质。

    正是因为MP3体积小,音质高的特点使得MP3格式几乎成为网上音乐的代名词。每分钟音乐的MP3格式只有1MB左右大小,这样每首歌的大小只有3-4MB。使用MP3播放器对MP3文件进行实时的解压缩(解码),这样,高品质的MP3音乐就播放出来了。

    补充:最高比特率320K,高频部分一刀切是他的缺点。音质不高!

    • AMR

    全称Adaptive Multi-Rate 和 Adaptive Multi-Rate Wideband,主要用于移动设备的音频,压缩比比较大,但相对其他的压缩格式质量比较差,多用于人声,通话,效果还是很不错的。

    • Ogg

    Ogg全称应该是OGG Vobis(ogg Vorbis) 是一种新的音频压缩格式,类似于MP3等现有的音乐格式。
    但有一点不同的是,它是完全免费、开放和没有专利限制的。OGG Vobis有一个很出众的特点,就是支持多声道,随着它的流行,以后用随身听来听DTS编码的多声道作品将不会是梦想。

    Vorbis 是这种音频压缩机制的名字,而Ogg则是一个计划的名字,该计划意图设计一个完全开放性的多媒体系统。目前该计划只实现了OggVorbis这一部分。

    Ogg Vorbis文件的扩展名是.OGG。这种文件的设计格式是非常先进的。现在创建的OGG文件可以在未来的任何播放器上播放,因此,这种文件格式可以不断地进行大小和音质的改良,而不影响旧有的编码器或播放器。
    补充:目前最好的有损格式之一,MP3部分支持,智能手机装软件部分可以支持,最高比特率500kbps。

    • AAC

    AAC(Advanced Audio Coding),中文称为“高级音频编码”,出现于1997年,基于 MPEG-2的音频编码技术。

    优点:相对于mp3,AAC格式的音质更佳,文件更小。

    不足:AAC属于有损压缩的格式,与时下流行的APE、FLAC等无损格式相比音质存在“本质上”的差距。加之,目前传输速度更快的USB3.0和16G以上大容量MP3正在加速普及,也使得AAC头上“小巧”的光环不复存在了。

    前景:以发展的眼光来看,正如“高清”正在被越来越多的人所接受一样,“无损”必定是未来音乐格式的绝对主流。AAC这种“有损”格式的前景不容乐观

    • FLAC

    FLAC即是Free Lossless Audio Codec的缩写,中文可解为无损音频压缩编码。

    FLAC是一套著名的自由音频压缩编码,其特点是无损压缩。不同于其他有损压缩编码如MP3 及 AAC,它不会破任何原有的音频资讯,所以可以还原音乐光盘音质。现在它已被很多软件及硬件音频产品所支持。简而言之,FLAC与MP3相仿,但是是无损压缩的,也就是说音频以FLAC方式压缩不会丢失任何信息。这种压缩与Zip的方式类似,但是FLAC将给你更大的压缩比率,因为FLAC是专门针对音频的特点设计的压缩方式,并且你可以使用播放器播放FLAC压缩的文件,就象通常播放你的MP3文件一样。

    补充:为无损格式,较ape而言,他体积大点,但是兼容性好,编码速度快,播放器支持更广。

    WAV和PCM的区别和联系

    在Android平台上要进行音频编辑操作(比如裁剪,插入,合成等),通常都是需要将音频文件解码为WAV格式的音频文件或者PCM文件。那么WAV和PCM之间有什么关系,这里有必要了解一下。

    PCM(Pulse Code Modulation—-脉码调制录音)。所谓PCM录音就是将声音等模拟信号变成符号化的脉冲列,再予以记录。PCM信号是由[1]、[0]等符号构成的数字信号,而未经过任何编码和压缩处理。与模拟信号比,它不易受传送系统的杂波及失真的影响。动态范围宽,可得到音质相当好的影响效果。也就是说,PCM就是没有压缩的编码方式,PCM文件就是采用PCM这种没有压缩的编码方式编码的音频数据文件。

    WAV是由微软开发的一种音频格式。WAV符合 PIFF Resource Interchange File Format规范。所有的WAV都有一个文件头,这个文件头音频流的编码参数。WAV对音频流的编码没有硬性规定,除了PCM之外,还有几乎所有支持ACM规范的编码都可以为WAV的音频流进行编码。WAV也可以使用多种音频编码来压缩其音频流,不过我们常见的都是音频流被PCM编码处理的WAV,但这不表示WAV只能使用PCM编码,MP3编码同样也可以运用在WAV中,和AVI一样,只要安装好了相应的Decode,就可以欣赏这些WAV了。

    在Windows平台下,基于PCM编码的WAV是被支持得最好的音频格式,所有音频软件都能完美支持,由于本身可以达到较高的音质的要求,因此,WAV也是音乐编辑创作的首选格式,适合保存音乐素材。因此,基于PCM编码的WAV被作为了一种中介的格式,常常使用在其他编码的相互转换之中,例如MP3转换成WMA。

    如上引用的描述,也就是说我们对音频进行编辑操作,其实就是音频解码后的PCM音频采样数据进行操作,因为PCM记录的就是采样后的音频信息,而我们常说的WAV文件是在PCM数据的基础上添加一组头信息,用于描述这个WAV文件的采样率,声道数,采样位数,音频数据大小等信息,这样这个WAV就可以被音频播放器正确读取并播放,而单纯的PCM文件因为只有编码的音频数据,没有其他描述信息,所以无法被音频播放器识别播放。

    WAV文件头信息

    接下来有必要了解一下WAV文件头信息是什么样的格式信息。

    WAV文件头信息由大小44个字节的数据组成:

    1. 4字节数据,内容为“RIFF”,表示资源交换文件标识
    2. 4字节数据,内容为一个整数,表示从下个地址开始到文件尾的总字节数
    3. 4字节数据,内容为“WAVE”,表示WAV文件标识
    4. 4字节数据,内容为“fmt ”,表示波形格式标识(fmt ),最后一位空格。
    5. 4字节数据,内容为一个整数,表示PCMWAVEFORMAT的长度
    6. 2字节数据,内容为一个短整数,表示格式种类(值为1时,表示数据为线性PCM编码)
    7. 2字节数据,内容为一个短整数,表示通道数,单声道为1,双声道为2
    8. 4字节数据,内容为一个整数,表示采样率,比如44100
    9. 4字节数据,内容为一个整数,表示波形数据传输速率(每秒平均字节数),大小为 采样率 * 通道数 * 采样位数
    10. 2字节数据,内容为一个短整数,表示DATA数据块长度,大小为 通道数 * 采样位数
    11. 2字节数据,内容为一个短整数,表示采样位数,即PCM位宽,通常为8位或16位
    12. 4字节数据,内容为“data”,表示数据标记符
    13. 4字节数据,内容为一个整数,表示接下来声音数据的总大小

    由以上信息可知,对于一个PCM文件来说,只要知道它的大小,采样率,声道数,采样位数,就可以通过添加一个WAV文件头得到一个WAV文件了。

    采样率简介

    那么采样率是什么意思,我们来了解下。

    音频采样率是指录音设备在一秒钟内对声音信号的采样次数,采样频率越高声音的还原就越真实越自然。在当今的主流采集卡上,采样频率一般共分为22.05KHz、44.1KHz、48KHz三个等级,22.05KHz只能达到FM广播的声音品质,44.1KHz则是理论上的CD音质界限,48KHz则更加精确一些。

    在数字音频领域,常用的采样率有:

    8,000 Hz - 电话所用采样率, 对于人的说话已经足够
    11,025 Hz

    22,050 Hz - 无线电广播所用采样率

    32,000 Hz - miniDV 数码视频 camcorder、DAT (LP mode)所用采样率

    44,100 Hz - 音频 CD, 也常用于 MPEG-1 音频(VCD, SVCD, MP3)所用采样率

    47,250 Hz - 商用 PCM 录音机所用采样率

    48,000 Hz - miniDV、数字电视、DVD、DAT、电影和专业音频所用的数字声音所用采样率

    50,000 Hz - 商用数字录音机所用采样率

    96,000 或者 192,000 Hz - DVD-Audio、一些 LPCM DVD 音轨、BD-ROM(蓝光盘)音轨、和 HD-DVD (高清晰度 DVD)音轨所用所用采样率

    2.8224 MHz - Direct Stream Digital 的 1 位 sigma-delta modulation 过程所用采样率。

    通常歌曲的采样率是44100,而Android平台的人声录音支持8000,16000,32000三种采样率。

    声道数和采样位数下的PCM编码

    接下来再了解下声道数和采样位数代表什么意思,在PCM编码中是如何应用的。

    声道通常可以分为单声道和双声道,双声道又分为左声道和右声道。

    采样位数表示一个采样数据用多少位来表示,通常为8位和16位,对于8位表示一个字节来表示一个采样数据,16位表示用两个字节表示一个采样数据,两个字节为低位字节和高位字节,通常低位字节在前,高位字节在后。

    因此结合声道和采样字节数(采样位数),可以组成下图的PCM数据格式:

    PCM编码格式

    可以看到8位单声道的PCM数据,只需要一个字节就能表示一个采样数据,而16位双声道(立体声)的PCM数据,需要4个字节来表示一个采样数据。那么计算一个PCM大小的方法就很简单了。

    对于8位单声道,采样率为8000,1分钟的PCM音频来说,大小是

    //采样率 * 通道数 * 采样位数/8 * 秒数
    8000 * 1 * 8/8 * 60 = 480000,大约480k

    对于16位双声道,采样率为44100,1分钟的PCM音频来说,大小是

    //采样率 * 通道数 * 采样位数/8 * 秒数
    44100 * 2 * 16/8 * 60 = 10584000,大约10M

    而WAV文件的大小就是比PCM多出44个字节数。

    音频文件解码

    有了以上音频相关知识的了解之后,现在可以来对android上常用音频文件进行解码和信息提取了。这里涉及了三个音频相关的类:
    - MediaExtractor 媒体文件数据提取器,负责媒体文件数据的提取操作。
    - MediaFormat 媒体文件格式信息,负责读取媒体文件的格式(如采样率,时长,声道数等)信息。
    - MediaCodec 媒体文件编解码类,负责媒体文件数据的编解码操作。

    解码器支持解码常用的音频格式,如mp3, wav, 3gpp, 3gp, amr, aac, m4a, ogg, flac等,解码后的数据是PCM编码的数据。下面用代码实现下如何用上述类实现音频文件的解码操作,得到一个PCM数据文件

      /**
       * 将音乐文件解码
       *
       * @param musicFileUrl 源文件路径
       * @param decodeFileUrl 解码文件路径
       * @param startMicroseconds 开始时间 微秒
       * @param endMicroseconds 结束时间 微秒
       * @param decodeOperateInterface 解码过程回调
       */
      private boolean decodeMusicFile(String musicFileUrl, String decodeFileUrl,
          long startMicroseconds, long endMicroseconds, DecodeOperateInterface decodeOperateInterface) {
    
        //采样率,声道数,时长,音频文件类型
        int sampleRate = 0;
        int channelCount = 0;
        long duration = 0;
        String mime = null;
    
        //MediaExtractor, MediaFormat, MediaCodec
        MediaExtractor mediaExtractor = new MediaExtractor();
        MediaFormat mediaFormat = null;
        MediaCodec mediaCodec = null;
    
        //给媒体信息提取器设置源音频文件路径
        try {
          mediaExtractor.setDataSource(musicFileUrl);
        }catch (Exception ex){
          ex.printStackTrace();
          try {
            mediaExtractor.setDataSource(new FileInputStream(musicFileUrl).getFD());
          } catch (Exception e) {
            e.printStackTrace();
            LogUtil.e("设置解码音频文件路径错误");
          }
        }
    
        //获取音频格式轨信息
        mediaFormat = mediaExtractor.getTrackFormat(0);
    
        //从音频格式轨信息中读取 采样率,声道数,时长,音频文件类型
        sampleRate = mediaFormat.containsKey(MediaFormat.KEY_SAMPLE_RATE) ? mediaFormat.getInteger(
            MediaFormat.KEY_SAMPLE_RATE) : 44100;
        channelCount = mediaFormat.containsKey(MediaFormat.KEY_CHANNEL_COUNT) ? mediaFormat.getInteger(
            MediaFormat.KEY_CHANNEL_COUNT) : 1;
        duration = mediaFormat.containsKey(MediaFormat.KEY_DURATION) ? mediaFormat.getLong(
            MediaFormat.KEY_DURATION) : 0;
        mime = mediaFormat.containsKey(MediaFormat.KEY_MIME) ? mediaFormat.getString(MediaFormat.KEY_MIME)
                : "";
    
        LogUtil.i("歌曲信息Track info: mime:"
            + mime
            + " 采样率sampleRate:"
            + sampleRate
            + " channels:"
            + channelCount
            + " duration:"
            + duration);
    
        if (TextUtils.isEmpty(mime) || !mime.startsWith("audio/")) {
          LogUtil.e("解码文件不是音频文件mime:" + mime);
          return false;
        }
    
        if (mime.equals("audio/ffmpeg")) {
          mime = "audio/mpeg";
          mediaFormat.setString(MediaFormat.KEY_MIME, mime);
        }
    
        if (duration <= 0) {
          LogUtil.e("音频文件duration为" + duration);
          return false;
        }
    
        //解码的开始时间和结束时间
        startMicroseconds = Math.max(startMicroseconds, 0);
        endMicroseconds = endMicroseconds < 0 ? duration : endMicroseconds;
        endMicroseconds = Math.min(endMicroseconds, duration);
    
        if (startMicroseconds >= endMicroseconds) {
          return false;
        }
    
        //创建一个解码器
        try {
          mediaCodec = MediaCodec.createDecoderByType(mime);
    
          mediaCodec.configure(mediaFormat, null, null, 0);
        } catch (Exception e) {
          LogUtil.e("解码器configure出错");
          return false;
        }
    
        //得到输出PCM文件的路径
        decodeFileUrl = decodeFileUrl.substring(0, decodeFileUrl.lastIndexOf("."));
        String pcmFilePath = decodeFileUrl + ".pcm";
    
        //后续解码操作
        getDecodeData(mediaExtractor, mediaCodec, pcmFilePath, sampleRate, channelCount,
            startMicroseconds, endMicroseconds, decodeOperateInterface);
    
        return true;
      }

    以上操作创建了MediaExtractor,获取MediaFormat用于读取音频文件的相关信息如采样率,文件类型,声道数等。然后创建了MediaCodec用于后续和MediaExtractor一起进行音频的解码操作。接下来看看具体的解码过程:

      /**
       * 解码数据
       */
      private void getDecodeData(MediaExtractor mediaExtractor, MediaCodec mediaCodec,
          String decodeFileUrl, int sampleRate, int channelCount, final long startMicroseconds,
          final long endMicroseconds, final DecodeOperateInterface decodeOperateInterface) {
    
        //初始化解码状态,未解析完成
        boolean decodeInputEnd = false;
        boolean decodeOutputEnd = false;
    
        //当前读取采样数据的大小
        int sampleDataSize;
        //当前输入数据的ByteBuffer序号,当前输出数据的ByteBuffer序号
        int inputBufferIndex;
        int outputBufferIndex;
        //音频文件的采样位数字节数,= 采样位数/8
        int byteNumber;
    
        //上一次的解码操作时间,当前解码操作时间,用于通知回调接口
        long decodeNoticeTime = System.currentTimeMillis();
        long decodeTime;
    
        //当前采样的音频时间,比如在当前音频的第40秒的时候
        long presentationTimeUs = 0;
    
        //定义编解码的超时时间
        final long timeOutUs = 100;
    
        //存储输入数据的ByteBuffer数组,输出数据的ByteBuffer数组
        ByteBuffer[] inputBuffers;
        ByteBuffer[] outputBuffers;
    
        //当前编解码器操作的 输入数据ByteBuffer 和 输出数据ByteBuffer,可以从targetBuffer中获取解码后的PCM数据
        ByteBuffer sourceBuffer;
        ByteBuffer targetBuffer;
    
        //获取输出音频的媒体格式信息
        MediaFormat outputFormat = mediaCodec.getOutputFormat();
    
        MediaCodec.BufferInfo bufferInfo;
    
        byteNumber = (outputFormat.containsKey("bit-width") ? outputFormat.getInteger("bit-width") : 0) / 8;
    
        //开始解码操作
        mediaCodec.start();
    
        //获取存储输入数据的ByteBuffer数组,输出数据的ByteBuffer数组
        inputBuffers = mediaCodec.getInputBuffers();
        outputBuffers = mediaCodec.getOutputBuffers();
    
        mediaExtractor.selectTrack(0);
    
        //当前解码的缓存信息,里面的有效数据在offset和offset+size之间
        bufferInfo = new MediaCodec.BufferInfo();
    
        //获取解码后文件的输出流
        BufferedOutputStream bufferedOutputStream =
            FileFunction.getBufferedOutputStreamFromFile(decodeFileUrl);
    
        //开始进入循环解码操作,判断读入源音频数据是否完成,输出解码音频数据是否完成
        while (!decodeOutputEnd) {
          if (decodeInputEnd) {
            return;
          }
    
          decodeTime = System.currentTimeMillis();
    
          //间隔1秒通知解码进度
          if (decodeTime - decodeNoticeTime > Constant.OneSecond) {
            final int decodeProgress =
                (int) ((presentationTimeUs - startMicroseconds) * Constant.NormalMaxProgress
                    / endMicroseconds);
    
            if (decodeProgress > 0) {
              notifyProgress(decodeOperateInterface, decodeProgress);
            }
    
            decodeNoticeTime = decodeTime;
          }
    
          try {
    
            //操作解码输入数据
    
            //从队列中获取当前解码器处理输入数据的ByteBuffer序号
            inputBufferIndex = mediaCodec.dequeueInputBuffer(timeOutUs);
    
            if (inputBufferIndex >= 0) {
              //取得当前解码器处理输入数据的ByteBuffer
              sourceBuffer = inputBuffers[inputBufferIndex];
              //获取当前ByteBuffer,编解码器读取了多少采样数据
              sampleDataSize = mediaExtractor.readSampleData(sourceBuffer, 0);
    
              //如果当前读取的采样数据<0,说明已经完成了读取操作
              if (sampleDataSize < 0) {
                decodeInputEnd = true;
                sampleDataSize = 0;
              } else {
                presentationTimeUs = mediaExtractor.getSampleTime();
              }
    
              //然后将当前ByteBuffer重新加入到队列中交给编解码器做下一步读取操作
              mediaCodec.queueInputBuffer(inputBufferIndex, 0, sampleDataSize, presentationTimeUs,
                  decodeInputEnd ? MediaCodec.BUFFER_FLAG_END_OF_STREAM : 0);
    
              //前进到下一段采样数据
              if (!decodeInputEnd) {
                mediaExtractor.advance();
              }
    
            } else {
              //LogUtil.e("inputBufferIndex" + inputBufferIndex);
            }
    
            //操作解码输出数据
    
            //从队列中获取当前解码器处理输出数据的ByteBuffer序号
            outputBufferIndex = mediaCodec.dequeueOutputBuffer(bufferInfo, timeOutUs);
    
            if (outputBufferIndex < 0) {
              //输出ByteBuffer序号<0,可能是输出缓存变化了,输出格式信息变化了
              switch (outputBufferIndex) {
                case MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED:
                  outputBuffers = mediaCodec.getOutputBuffers();
                  LogUtil.e(
                      "MediaCodec.INFO_OUTPUT_BUFFERS_CHANGED [AudioDecoder]output buffers have changed.");
                  break;
                case MediaCodec.INFO_OUTPUT_FORMAT_CHANGED:
                  outputFormat = mediaCodec.getOutputFormat();
    
                  sampleRate =
                      outputFormat.containsKey(MediaFormat.KEY_SAMPLE_RATE) ? outputFormat.getInteger(
                          MediaFormat.KEY_SAMPLE_RATE) : sampleRate;
                  channelCount =
                      outputFormat.containsKey(MediaFormat.KEY_CHANNEL_COUNT) ? outputFormat.getInteger(
                          MediaFormat.KEY_CHANNEL_COUNT) : channelCount;
                  byteNumber =
                      (outputFormat.containsKey("bit-width") ? outputFormat.getInteger("bit-width") : 0)
                          / 8;
    
                  LogUtil.e(
                      "MediaCodec.INFO_OUTPUT_FORMAT_CHANGED [AudioDecoder]output format has changed to "
                          + mediaCodec.getOutputFormat());
                  break;
                default:
                  //LogUtil.e("error [AudioDecoder] dequeueOutputBuffer returned " + outputBufferIndex);
                  break;
              }
              continue;
            }
    
            //取得当前解码器处理输出数据的ByteBuffer
            targetBuffer = outputBuffers[outputBufferIndex];
    
            byte[] sourceByteArray = new byte[bufferInfo.size];
    
            //将解码后的targetBuffer中的数据复制到sourceByteArray中
            targetBuffer.get(sourceByteArray);
            targetBuffer.clear();
    
            //释放当前的输出缓存
            mediaCodec.releaseOutputBuffer(outputBufferIndex, false);
    
            //判断当前是否解码数据全部结束了
            if ((bufferInfo.flags & MediaCodec.BUFFER_FLAG_END_OF_STREAM) != 0) {
              decodeOutputEnd = true;
            }
    
            //sourceByteArray就是最终解码后的采样数据
            //接下来可以对这些数据进行采样位数,声道的转换,但这是可选的,默认是和源音频一样的声道和采样位数
            if (sourceByteArray.length > 0 && bufferedOutputStream != null) {
              if (presentationTimeUs < startMicroseconds) {
                continue;
              }
    
              //采样位数转换,按自己需要是否实现
              byte[] convertByteNumberByteArray =
                  convertByteNumber(byteNumber, Constant.ExportByteNumber, sourceByteArray);
    
              //声道转换,按自己需要是否实现
              byte[] resultByteArray = convertChannelNumber(channelCount, Constant.ExportChannelNumber,
                  Constant.ExportByteNumber, convertByteNumberByteArray);
    
              //将解码后的PCM数据写入到PCM文件
              try {
                bufferedOutputStream.write(resultByteArray);
              } catch (Exception e) {
                LogUtil.e("输出解压音频数据异常" + e);
              }
            }
    
            if (presentationTimeUs > endMicroseconds) {
              break;
            }
          } catch (Exception e) {
            LogUtil.e("getDecodeData异常" + e);
          }
        }
    
        if (bufferedOutputStream != null) {
          try {
            bufferedOutputStream.close();
          } catch (IOException e) {
            LogUtil.e("关闭bufferedOutputStream异常" + e);
          }
        }
    
        //重置采样率,按自己需要是否实现
        if (sampleRate != Constant.ExportSampleRate) {
          Resample(sampleRate, decodeFileUrl);
        }
    
        notifyProgress(decodeOperateInterface, 100);
    
        //释放mediaCodec 和 mediaExtractor
        if (mediaCodec != null) {
          mediaCodec.stop();
          mediaCodec.release();
        }
    
        if (mediaExtractor != null) {
          mediaExtractor.release();
        }
      }

    以上操作是在一个循环中,不断取得源音频输入数据,加入到输入队列中,交给MediaCodec处理,然后再从解码后的输出队列中取得输出数据,写入到文件中,其中要判断源音频输入数据是否读取完毕,解码后的输出数据是否完成,来终止这个循环。后续的采样位数转换,声道数转换,以及采样率转换都是可选的,不是必须的,默认不实现的话,输出的PCM数据和源音频是一样的采样位数,声道数,和采样率。

    PCM文件转WAV文件

    现在我们得到了解码后的PCM文件,但是它是不可直接播放的,因为不带音频相关的格式信息,下面我们将PCM和指定的音频相关格式信息去转换得到一个可播放的WAV文件:

      /**
       * PCM文件转WAV文件
       * @param inPcmFilePath 输入PCM文件路径
       * @param outWavFilePath 输出WAV文件路径
       * @param sampleRate 采样率,例如44100
       * @param channels 声道数 单声道:1或双声道:2
       * @param bitNum 采样位数,8或16
       */
      public static void convertPcm2Wav(String inPcmFilePath, String outWavFilePath, int sampleRate,
          int channels, int bitNum) {
    
        FileInputStream in = null;
        FileOutputStream out = null;
        byte[] data = new byte[1024];
    
        try {
          //采样字节byte率
          long byteRate = sampleRate * channels * bitNum / 8;
    
          in = new FileInputStream(inPcmFilePath);
          out = new FileOutputStream(outWavFilePath);
    
          //PCM文件大小
          long totalAudioLen = in.getChannel().size();
    
          //总大小,由于不包括RIFF和WAV,所以是44 - 8 = 36,在加上PCM文件大小
          long totalDataLen = totalAudioLen + 36;
    
          writeWaveFileHeader(out, totalAudioLen, totalDataLen, sampleRate, channels, byteRate);
    
          int length = 0;
          while ((length = in.read(data)) > 0) {
            out.write(data, 0, length);
          }
        } catch (Exception e) {
          e.printStackTrace();
        } finally {
          if (in != null) {
            try {
              in.close();
            } catch (IOException e) {
              e.printStackTrace();
            }
          }
          if (out != null) {
            try {
              out.close();
            } catch (IOException e) {
              e.printStackTrace();
            }
          }
        }
      }
    
    
      /**
       * 输出WAV文件
       * @param out WAV输出文件流
       * @param totalAudioLen 整个音频PCM数据大小
       * @param totalDataLen 整个数据大小
       * @param sampleRate 采样率
       * @param channels 声道数
       * @param byteRate 采样字节byte率
       * @throws IOException
       */
      private static void writeWaveFileHeader(FileOutputStream out, long totalAudioLen,
          long totalDataLen, int sampleRate, int channels, long byteRate) throws IOException {
        byte[] header = new byte[44];
        header[0] = 'R'; // RIFF
        header[1] = 'I';
        header[2] = 'F';
        header[3] = 'F';
        header[4] = (byte) (totalDataLen & 0xff);//数据大小
        header[5] = (byte) ((totalDataLen >> 8) & 0xff);
        header[6] = (byte) ((totalDataLen >> 16) & 0xff);
        header[7] = (byte) ((totalDataLen >> 24) & 0xff);
        header[8] = 'W';//WAVE
        header[9] = 'A';
        header[10] = 'V';
        header[11] = 'E';
        //FMT Chunk
        header[12] = 'f'; // 'fmt '
        header[13] = 'm';
        header[14] = 't';
        header[15] = ' ';//过渡字节
        //数据大小
        header[16] = 16; // 4 bytes: size of 'fmt ' chunk
        header[17] = 0;
        header[18] = 0;
        header[19] = 0;
        //编码方式 10H为PCM编码格式
        header[20] = 1; // format = 1
        header[21] = 0;
        //通道数
        header[22] = (byte) channels;
        header[23] = 0;
        //采样率,每个通道的播放速度
        header[24] = (byte) (sampleRate & 0xff);
        header[25] = (byte) ((sampleRate >> 8) & 0xff);
        header[26] = (byte) ((sampleRate >> 16) & 0xff);
        header[27] = (byte) ((sampleRate >> 24) & 0xff);
        //音频数据传送速率,采样率*通道数*采样深度/8
        header[28] = (byte) (byteRate & 0xff);
        header[29] = (byte) ((byteRate >> 8) & 0xff);
        header[30] = (byte) ((byteRate >> 16) & 0xff);
        header[31] = (byte) ((byteRate >> 24) & 0xff);
        // 确定系统一次要处理多少个这样字节的数据,确定缓冲区,通道数*采样位数
        header[32] = (byte) (channels * 16 / 8);
        header[33] = 0;
        //每个样本的数据位数
        header[34] = 16;
        header[35] = 0;
        //Data chunk
        header[36] = 'd';//data
        header[37] = 'a';
        header[38] = 't';
        header[39] = 'a';
        header[40] = (byte) (totalAudioLen & 0xff);
        header[41] = (byte) ((totalAudioLen >> 8) & 0xff);
        header[42] = (byte) ((totalAudioLen >> 16) & 0xff);
        header[43] = (byte) ((totalAudioLen >> 24) & 0xff);
        out.write(header, 0, 44);
      }

    上面操作其实也很简单,只要你知道了WAV文件头信息的格式,将采样率,声道数,采样位数,PCM音频数据大小等信息填充进去,然后将这个44个字节数据拼接到PCM文件的开头,就得到了一个可播放的WAV文件了。

    总结

    上文讲解了常用音频文件的格式,采样率,声道,采样位数概念,以及PCM数据是如何构成等内容。然后是如何从音频文件解码为PCM数据文件,以及得到PCM编码的WAV文件,有了以上的理解后,后续进行音频文件的裁剪,插入,合成等编辑操作就更容易理解了。请继续关注后续的音频编辑操作处理。

    需要源码的亲们请关注我的微信公众号【hesong】,那里有源码地址。创作不易,前进的路上需要亲们的支持哦。

    我的博客
    GitHub
    我的简书
    群号:194118438,欢迎入群
    微信公众号 hesong ,微信扫一扫下方二维码即可关注:

    展开全文
  • tak是一种无损音频格式,有着较好的性能,但能完美支持的播放器不多(虽然tak官方说vlc、potplayer、ffplay支持,但其实都是半吊子) 最近收藏了一张CD的音频资源,文件恰好是tak格式,我最终用foobar顺利的播放了...
  • 可以实现格式转换、视频编辑、视频压缩、录屏、CD刻录等功能。简直就是 Mac 上的「格式工厂」。万兴优转视频、音频、图片转格式转格式是这款软件的看家本领,几乎常用的视频、音频、图片格式都可以转。视频格式转出...
  • ... 本文出自:hesong的专栏 前言 本篇开始讲解在Android平台上进行的音频编辑开发,首先需要对音频相关概念有基础的认识。所以本篇要讲解以下内容: ...2. WAV和PCM的区别和联系 3. WAV文...
  • MP4是目前最流行的视频格式,MP3是目前最流行的音频格式,有时候我们需要将MP4文件中提出其中的音频制作成mp3音频,在mp3播放...可以在各种主流音频声音文件间相互转换,(如mp3、wav、wma、cd音轨、ac3、ogg、aac、m...
  • AnyMP4 MP3 Converter for Mac版是一款完美的mp3格式转换器,可将任何音频格式(包括AAC,AIFF,ALAC,WAV,M4A和其他通用音频格式)转换为MP3.反过来,该软件也可以将MP3音频文件转换为其他音频格式,如AAC / AIFF / ...
  • 转换的视频和音频可以在Android智能手机、平板电脑、液晶电视、智能电视上完美播放,需要视频转换的用户赶快来下载试试吧!软件功能说明超快的转换速度,完美转换质量。采用顶级音频编码,转换速度和质量完美平衡...
  • 转换速度超快,同时转换质量完美平衡,转换的视频和音频可以在各种移动设备上播放,比如mp3、4、5播放器以及电脑、平板、手机等,还支持批量转换,有需要的就赶紧下载使用吧~软件功能超快的转换速度,完美转换质量...
  • 本期小编给大家推荐一款大众喜爱的系统软件,名字叫《佳佳AVI MP4格式...软件介绍超快的转换速度,完美转换质量。采用顶级音频编码,转换速度和质量完美平衡。转换后的视频和音频可以在DVD、SVCD、VCD上播放。转...
  • 同样支持WAV、WMA、RA、OGG、MP2、AAC、AC3、FLAC等流行音频格式转换MP3格式。使用本MP3全能格式转换器,您就相当于拥有了AVI转MP3转换器,wav转MP3转换器,WMA转MP3转换器,RM转MP3转换器,WMV转MP3转换器,MP4转...
  • 软件可将MP3, WMA, OGG, WAV , AAC, FLAC , AC3等等音频之间都可以完美相互转换。软件同时支持从视频格式中提取音频格式,具有转换好之后音质好,转换效率高,支持格式多等特点,此外,软件还能够在高级设置中设置...
  • 还能把RM、RMVB格式转换成MP3、WAVWAV、AC3、AAC、OGG、Flac、MP2、RM、MP2等等常见的音频格式。 本软件是全功能、高集成的MPEG4/H264格式转换器,它可以带给您超高速和超高质量视频转换体验。 佳佳RMVB转换器...
  • 如可以在常见音频MP3、WAV、WMA、CD、AC3、OGG、AAC、MP2、FLAC、RM、RA、AMR等音频格式之间相互随意转换。最为强大的是,本转换器可以从各种视频格式中提取出音频文件,支持从RM、RMVB、AVI、VOB、DAT、VCD、SVCD、...
  • 通过使用本软件,您可以轻松将WMA格式的音频转换为您需要MP3等流行音频格式,比如将微软的WMA转换为MP3格式、WMA转WAV、WMA转AAC、WMA转换FLAC、WMA转OGG等等都可以实现。 当然软件同样支持将各种流行的音频格式...
  • 2、专业的音频格式转换器 - 转换各种流行的音频文件作为一个专业的音频转换器,《佳佳3GP格式转换器》可以转换各种流行的音频格式,支持转换AAC,CDA,AC3,MP2,OGG,WAV,WMA,WAV,3、3、MP3,M4A和Flac音频格式...
  • 闪电全能格式转换器官方版是一款十分出色的全能视频转换软件,闪电全能格式转换器官方版界面美观大方,功能强劲实用,能够实现MP3,WAV,CD,WMA,OGG,AAC,AC3,FLAC,APE等转换。还支持各种视频文件的播放预览。使用起来...
  • 2、专业的音频格式转换器 - 转换各种流行的音频文件作为一个专业的音频转换器,《佳佳3GP格式转换器》可以转换各种流行的音频格式,支持转换AAC,CDA,AC3,MP2,OGG,WAV,WMA,WAV,3、3、MP3,M4A和Flac音频格式...
  • 还可以完美转换(优酷、土豆、酷6网的视频格式)SWF、FLV这类的FLASH网络视频格式。还可以从视频格式中提取音频MP3、WAV、WMA、OGG、AC3、FLAC、AAC等流行的音频格式(及以上的音频格式互转)。本软件因为采用了最...
  • 凡人iPad视频转换器预设了各种iPad常用输出格式,可以让您实现一键式完美转换。软件可以转换所有流行的音视频格式,如:RM、RMVB、AVI、VOB、DAT、MKV、MP4、MPG、MOV、VCD、DVD、SVCD、ASF、QT、MPEG、WMV、3GP、...
  • 它可以把RM、RMVB视频格式转换成我们经常使用的视频格式,比如MP4、AVI、FLV、SWF、M4V、WMV、ASF、VOB、MPG、MPEG、MKV、MOV、DivX、XviD等常用视频格式都可以完美转换。软件还能把RM、RMVB格式转换成各种流行设备...

空空如也

空空如也

1 2 3 4 5 ... 20
收藏数 419
精华内容 167
关键字:

wav完美转换flac