热点科技

标题: 论CD机芯对音质的影响 [打印本页]

作者: zgmfx10akira    时间: 2012-4-30 14:33
标题: 论CD机芯对音质的影响

刚才在好友的帖子里看见几位兄弟聊起CD机芯的重要性,其中一些观点,在烧友中有一定的代表性。所以我觉得有必要就我对CD的了解,为大家做一个简单的介绍。
本人不才,在1998年的时候因工作需要,作为为美国Highpoint公司光盘刻录软件开发项目的负责人,对CD机芯、ISO9660、CD-DA、CD-XA等有过比较深入的了解。当时我们对刻录机和光驱的读盘性能进行过测试,刻录机是台湾OEM的产品,机芯是Philips CDM12.1,CD-ROM光驱是Sony的,型号记不起来了。测试软件是我们自己开发的。我们的软件可以设定读取速率、读取次数、读取错误时是忽略错误继续往下读还是尝试重复读取,并能显示读出的数据以及错误之处。我们发现对于大多数质量不算太差的盘,不论是CD-ROM(数据光盘)还是CD-DA(即激光唱片),不论是用刻录机还是光驱,都可以一次准确读出来。但对于质量较差的盘,采用Philips机芯的刻录机读出的正确率通常要高一些,但也有例外情况。
另外,与很多人的想象不通,光头读取的数据,并不是直接输出,而是要经过纠错和解码,才能得到需要的数据,因而机芯的性能并不是特别重要,因为一张CD的实际数据量,并不是区区650M,而大约是这个数的3倍。CD光盘上的数据,采用的是里德-索罗门编码,这多出来的数据,就是用于纠错编码,以保证光盘在受到一定程度的损害时,上面的数据仍然能够通过纠错,100%正确的读出。
很多人以为机芯的转速一定要很准很稳,否则输出数据流的码率和Jetter就会出问题,其实这也是一个误解。因为从光盘上直接读出的数据,还要经过相关电路的解码和纠错,光盘上读出的数据,是先送到一个缓冲区(RAM),然后解码和纠错电路对其进行处理以后才输出到后级。因此CD转盘输出的数字信号的好坏,与机芯的机械部分关系很小,主要在后面数字电路的处理部分。数字电路的时钟的好坏,以及数字输出电路的设计,直接影响到数字输出信号的质量。
当然,好的CD机芯在读取质量差一点的光盘时有一些优势,但对于质量较好的盘,如果采用的相同的控制电路,数字输出信号的质量没有什么区别。
***************************************************************************************

我这个帖子想说明的是,高级CD机芯(指的是光学机械部分)对于音乐的重放几乎没有意义(风花兄说的什么看得舒服、心理踏实、结实耐用、机械噪音低这几点除外)。因为不管机芯高级与否,只要它能够把“有效数据一个字节都不差”地再现出来,剩下的Jitter问题是电路部分应该解决的。
所以那些说什么高级机芯如VRDS比普通塑料机芯音质好、原版CD比刻录的音质好的人,完全是在误导他人。如果高级机芯配普通电路、塑料机芯配上优秀的电路,塑料机芯出来的声音完全可以超过高级机芯。
我发这贴的目的,是为了提醒大家不要因为某台机器采用了所谓的高级机芯就一定是好机器,就一味地去追捧,它采用好机芯的目的很可能是缺乏技术实力的厂商为了赚钱而搞的噱头而已。评价一台机器的好坏应该去考察它的综合设计水平。
设计的好,普通机芯也能出好声。至于为何顶级CD都用好机芯,我想除了可靠性和耐用性的因素外,品味、形象、市场策略这些与音质毫不相干的东西才是它考虑的最主要的原因。
****************************************************************************************

看到这篇老帖子又被顶出来,我决定将我在此论坛对这个问题的发言做一个汇总,以便感兴趣的朋友查阅(2009年6月22日)。

普通的音频CD格式,称为CD Digital Audio(CD数字音频),简称为CD-DA。这种格式的标准,俗称为“红皮书”,由飞利浦公司和索尼公司联合制定。“红皮书”规定了存放在CD中的音频数据是将原始音频采样编码而成。CD-DA音频使用44.1KHz的采样率,大约是人耳听觉上限频率的2倍。每个采样量化为16bits(2字节),而且是立体声采样。所以,每秒音频数据量为(44100*2*2 )176400字节。

音频数据存放在光盘的数据块(block)中,每个数据块存放2352字节音频数据和用于纠错的一些额外字节。所以,一秒钟的音频需要 75个数据块。在一张标准的74分钟CD上,存储总量为(2352*75*74*60)783216000字节,大约747MB 。

普通存放数据的CD-ROM使用的是ISO9660标准,也称为“黄皮书”,是1983年发布的,格式与CD-DA基本相 同,除了将每数据块的存储量降低为2048字节,多出的304字节用于ECC纠错。在一张标准的74分钟CD上,存储总量为 (2048*75*74*60)681984000 字节,大约650MB。

以下关于CD唱机纠错机制的说明摘录自Sony公司的技术资料:
Error Correction
In the CD format, one 8-bit data contains two error correction codes, C1 and C2.
For C1 correction, the code is created with 28-byte information and 4-byte C1 parity.
For C2 correction, the code is created with 24-byte information and 4-byte parity.
Both C1 and C2 are Reed Solomon codes with a minimum distance of 5.
The correction status can be monitored externally. See Table 3-2.
When the C2 pointer is high, the data in question was uncorrectable. Either the pre-value was held or an
average value interpolation was made for the data.

错误纠正:
在CD格式,每个8-bit 数据都包含两个纠错机制:C1 和 C2。
对于C1 纠错, 该码包含28字节的信息以及4字节的校验和。
对于C2纠错, 该码包含24字节的信息以及4字节的校验和。
C1和C2都是里德所罗门编码并且最小间隔是5。
纠错状态可通过外部检测,见表3-2。
当C2指针为高, 表明有问题的数据无法纠正。那么先前的数值或者平均值将被用来取代出错的数据。

所以普通CD机对于读取时出错的数据,只要在C1、C2的纠错范围之类,都可以实时纠正并还原,如果不行,则用先前的数值或者平均值代替。并非象有些人推测的那样重新进行读取(当然现在也有一些高端产品和车载CD具有重读机制)。
还有一些烧友认为CD机芯的转速不稳会影响数据流的Jitter,他们依据在模拟LP唱盘系统的经验,去揣测数字唱盘系统,这种想法看似有道理,其实是非常荒谬的。要知道刻在CD光盘上的那些小坑本身就是经过编码处理,已经不再是原始的“0”和“1”(见下图),如果没有数字电路的处理,根本得不到后面解码电路所需的音频数据。音频数据的Jitter,只受时钟和电路性能影响,与转盘没有关系。
  
不同的CD读取机构,读取CD光盘的能力也有所不同。不同的盘片(例如不同的刻录盘),其反射能力也不同。因此理论上说,CD读取机构的读盘能力是有差异性的,但是因为有C1、C2纠错机制的存在,根据我多年前从事相关项目的测试经验,只要盘片质量良好,即使是低端CD唱机也能100%重现原始的音乐数据。
至于为何同样的解码器搭配不同的CD转盘,声音也会不同,我认为主要是由于Jitter以及数码输出与解码器输入之间的匹配(归根结底也还是影响到Jitter)造成的。

关于重读机制,一般家用CD机都不具备,这需要额外的硬件和软件(或韧体)来支持。简单的说是需要主控CPU去读取DSP的标志位,检查当前这个Block的数据是否出错且无法纠正,然后再发读取命令重读这一Block。硬件上要实现这个功能,则要求CD机芯支持CDDA精确定位,也就是可以根据Block的地址直接寻址读取数据,读取速度也要比普通CD快一些;另外,还要有一定的RAM做缓存。这些技术,早已不是啥商业机密。
目前采用重读机制的CD机,主要是随身听和车载机。一般家用机并没有采用,因为意义不大,只要盘片没问题,基本上通过C1、C2纠错都能改正过来,这点已通过大量实践证实。有些厂家的DSP芯片具有出错指示输出,具有单片机开发能力的朋友可以做一个很简单的小系统,读取这个信号,看看播放一张CD到底有几次错误。我也确实听说一些顶级CD机种采用电脑主机+CD-ROM方式,也具有重读机制。

作者: 风谷希雨    时间: 2012-4-30 20:39
围观一下~:a41:
作者: zgmfx10akira    时间: 2012-4-30 21:31
风谷希雨 发表于 2012-4-30 20:39
围观一下~

好不容易把第一版给整干净了。。。
作者: zgmfx10akira    时间: 2012-4-30 21:32
风谷希雨 发表于 2012-4-30 20:39
围观一下~

好不容易把第一版给整干净了。。。




欢迎光临 热点科技 (http://itheat.com/activity/) Powered by Discuz! X3.2