xy1689 发表于 2014-9-24 12:03:57

额刚看到一篇文章关于数字无用论的

http://www.zhihu.com/question/20242424/answer/14560161贴一篇文章,作者认为数字部分不影响声音,如何反驳?

bthans 发表于 2014-9-24 14:55:00

本帖最后由 bthans 于 2014-9-24 15:02 编辑

作者将数据和数据的流输出混为一谈了。正如作者所言,数据本身没什么不同,都是0和1编码而成的文件,弄出来后就像一个乐谱,是有序的。你从C盘拷贝到D盘,再刻录到CD,数据本身都不会有什么变化。但是音频数据的流输出完成是另一回事。如果说数据本身是乐谱,那么音频数据的流输出,就像找个人把乐谱念出来。一般来说这个人不会念错,也就是不会有误码,但是可能发生其他事儿。

比如,这个人念的速度不均匀,原本音符之间的时序是1,结果他念的是1.001、0.998、1.002……虽然不均的程度很轻微,但如果跟着他的速度拉乐器的话,那么乐曲就和原本有些不同了。如果拉乐器的人本身有比较好的时序,那么有可能可以避免这一点。

或者这个人念的没有问题,但是旁边有些干扰,那么听着他声音拉乐器的人就会纠结了。虽然这个干扰一般不会特别大,不会把E调变成C调,但是一些有轻微区别的音符因为干扰听不清楚就要靠猜了,于是两个有细微区别的符号到了乐手那里就变成一样的东西,那么最终的声音在细节上就和乐谱有些不一样了。

当然了,实话实说,数字部分的差异绝对不可能将C大调变成D大调,更多的是细节的丢失,简单的说就是定位不够、层次不清、结像不清、密度不佳。对于大部分非烧友来讲,这些都是细节,平常基本不留意的东西。但对于烧友来讲,这些作不好的话,玩什么HIFI{:1_128:}

SuperFaraday 发表于 2014-9-24 15:24:19

bthans 发表于 2014-9-24 14:55 作者将数据和数据的流输出混为一谈了。正如作者所言,数据本身没什么不同,都是0和1编码而成的文件,弄出来 ...

Data短距离内只要线质量合格不会差异,但是非数字编码的连续时钟的相位左右摇摆会严重影响一个周期内的采样时间准度。

SuperFaraday 发表于 2014-9-24 15:27:42

bthans 发表于 2014-9-24 14:55 作者将数据和数据的流输出混为一谈了。正如作者所言,数据本身没什么不同,都是0和1编码而成的文件,弄出来 ...

作者没有搞清时钟信号其实是本质上一种连续的模拟信号,
也混淆了时钟的不稳在一个采样周期内和整个频段的影响。

Zjokers 发表于 2014-9-24 16:42:18

数字噪声 da转换 都是个大闸门 他nb你让他二进制去啊

来自:中国耳机爱好者俱乐部IOS客户端

Zjokers 发表于 2014-9-24 16:43:44

一般些无用论的基本都是怪咖

来自:中国耳机爱好者俱乐部IOS客户端

kyokyo 发表于 2014-9-24 18:02:42

说的也对,也不对。很多解码设计是从SPDIF中恢复时钟,然后用这个时钟经过PLL或者其它机制产生稳定DA时钟。这种方式,必然受到外部时钟信号精度的影响。另一种方式是只恢复数据,然后用数据和本地时钟进行解码,这种jitter就没有什么影响。但是这个有些其他问题,比如本地时钟要手动设置,不方便。或者要根据输入时钟进行自动切换,但是成本又很高。所以很多解码折衷起来,搞了升频到固定的高频率时钟,但是升频算法不好就会影响音质。

但是,完全去掉输入的jitter技术上是完全可行的。

空壳 发表于 2014-9-24 20:06:14

xx无用功都不是发烧友
理他干嘛

小白 发表于 2014-9-24 22:24:45

缺乏数字音频基本常识的人就喜欢写这些,发烧友只要开始玩,不是YY而是真的开始接触器材,很快就会自己认识到数字部分对声音造成的影响是很明显的。

小白 发表于 2014-9-24 22:27:44

kyokyo 发表于 2014-9-24 18:02 static/image/common/back.gif
说的也对,也不对。很多解码设计是从SPDIF中恢复时钟,然后用这个时钟经过PLL或者其它机制产生稳定DA时钟。 ...

完全去掉输入部分的Jitter,技术上不可行,除非用一个很大的缓存把音乐都灌进去,那样就成为本地存储和播放了。如果不是这样,那么音频流播放时必然要受输入时钟的影响,不可能不管输入信号的时钟而只顾按解码的时钟来工作。这是一个很多人的理想化假设,但实际行不通。

kyokyo 发表于 2014-9-24 22:32:09

小白 发表于 2014-9-24 22:27 static/image/common/back.gif
完全去掉输入部分的Jitter,技术上不可行,除非用一个很大的缓存把音乐都灌进去,那样就成为本地存储和播 ...

不知道你这里很大的缓存值得是多大?44khz的音乐,百分之一秒的缓存足以去掉全部的Jitter了。

小白 发表于 2014-9-24 22:43:32

kyokyo 发表于 2014-9-24 22:32 static/image/common/back.gif
不知道你这里很大的缓存值得是多大?44khz的音乐,百分之一秒的缓存足以去掉全部的Jitter了。

你这真是胡说八道了。没得说了。世界难题一句话轻易解决了。

kyokyo 发表于 2014-9-24 22:50:27

小白 发表于 2014-9-24 22:43 static/image/common/back.gif
你这真是胡说八道了。没得说了。世界难题一句话轻易解决了。

你不懂就别在这误导别人。

kyokyo 发表于 2014-9-24 22:51:05

kyokyo 发表于 2014-9-24 22:50 static/image/common/back.gif
你不懂就别在这误导别人。

另外,你自己翻翻Prismsound的手册,上面写着彻底去掉输入的Jitter。

amex 发表于 2014-9-24 23:00:16

kyokyo 发表于 2014-9-24 22:51 static/image/common/back.gif
另外,你自己翻翻Prismsound的手册,上面写着彻底去掉输入的Jitter。
那说明还有jitter以外的影响
实际上我们做过实验,8xr时钟输出给界面,界面被8xr master了,这时候aes线应该只传输数据了,可是这根线还是有区别,前面的界面是什么,也依然有区别(当然区别会缩小,毕竟8xr时钟太屌)
页: [1] 2 3
查看完整版本: 额刚看到一篇文章关于数字无用论的

耳机俱乐部微信
耳机俱乐部微信