是吃螃蟹还是刀口上舔血 歌诗德U16数字界面 外加HELEN DIGIGRAME LYNX 实测

笑嘻嘻1

这个测试说明不了什么。如果真的是误码造成IMD+N达到百分之6、7，这就不是声音散，糙，空的问题了，根本没法听了。我估计主要原因还是U16的大缓存，同时大概固件和驱动什么的多少还是有点bug，播放头段里多输出了一堆0，被RMAA同样加到结果里进行统计了。或者也有可能的头段可能会有缓存里前次的数据，不过如果这样的话用U16听音乐应该会在头段听到一声前次播放的末尾的声音，目前看没有这样的现象，所以我估计是多输出了一堆0.
另外，我估计楼主的测试过程里没有加DA和AD，就是纯数字的循环，加了DA和AD的话其它项目得不到这么好的结果，在纯数字的循环里，IMD+N并不能体现jitter性能。

笑嘻嘻1

阿斯兰君 发表于 2018-10-22 18:14
其实你没有了解这个测试的意义，在数字上这个并不代表噪音的，数字没有办法测噪音的，这个10次测试法测的 ...

不是这样的。IMD+N重要是由于在DA过程中，jitter会在最终的模拟结果中被表现为IMD+N这个指标，这是一个业余条件下比较方便的查看界面jitter性能的指标.而在纯数字过程中，理论上这个指标不该有任何波动。如果有波动，那么结合其他指标，因为界面性能问题的话这里不会孤立的表现为只有这一个指标有波动，既然其他指标都处于理论极限，因此只能考虑软件问题。

笑嘻嘻1

阿斯兰君 发表于 2018-10-22 19:54
正在做录音，佐证问题，软件问题也不可能就一个设备有问题，除非是问题出在驱动上

所以我怀疑是播放的头段多了一段0，听起来就是多了零点几秒的静音，所以实际上不影响听感，但是影响IMD+N的计算结果。新方案，驱动啊，固件啊什么的有点小问题难免。

笑嘻嘻1

阿斯兰君 发表于 2018-10-22 22:09
我发这个帖子，实际不是用这个测试结果去推断音质，而是反向推断的，就是听完以后发现问题，再去逐步反过 ...

但是方法用错了，测试界面是否BIT PERFECT，可以用纯数字LOOP，播放文件，然后对比录回来的文件，对比的时候要去掉头尾，看有效数据是否完全一致。如果要测试jitter,要加入DA，用模拟LOOP来看IMD+N，但是这时候测量结果受到DA，AD性能的限制，所以你的DA和AD必须十分给力。

笑嘻嘻1

阿斯兰君 发表于 2018-10-22 23:18
原理是肯定没有错的，如果一个东西测试有问题，一个没有没有问题，那么100%是没有问题的声音在好于有问题 ...

你的结果我还没听，太晚了在床上了，不过DD录音我做过了，去掉头尾，有效数据和原始文件数据完全一致，录入用的就是主板集成声卡的SPDIF输入，结果一个BIT都没差。惊讶不惊讶？其实只要软件设置正确，BIT PERFECT并不是一个很难达成状态。假如你设置正确，按道理你的两个录音文件也应该是完全一致的，因为HELEN应该是只处理JITTER，不改变数据的。JITTER只有在DA过程中才会体现出来，没有DAAD，纯数字流程里，INT204和主板集成数字输出的性能是完全一样的。有没有觉得很颠覆？不幸的是这才是真相。

笑嘻嘻1

阿斯兰君 发表于 2018-10-23 00:14
理论上是完全一样的啊，问题就在这里，我测过很多东西，就是10次里有几次严重不一样，这种产品的声音也是 ...

我主板带SPDIF IN的。RMAA经常会由于头部对不上，导致测量结果算不对，只要去掉头尾，只对比有效数据，正确性不会有问题的。现在的技术，搞音频数据那几百K的频率，要保证正确真的跟玩似的 。瓶颈还就在DA的过程上，现代的DA对JITTER太敏感 。

笑嘻嘻1

阿斯兰君 发表于 2018-10-23 00:46
那个也是因为误差大，我碰到过的，有个界面，能测出来的是实话都是正常的，然而，10次有8次出错，你这个 ...

我就直接用windiff对比文件，异步界面录音由于缓存原因头部经常会多出不知道什么东西，所以找到有效部分的活要手工做，大部分软件不能自动有效数据对齐。找到有效部分，截掉头尾，剩下的就一样了。