背景音乐

天使动漫论坛 - 梦开始的地方

查看: 206|回复: 4

[其他] EAC的纠错品质到底应该怎么调比较好 [复制链接]

dengxiaochu

梦幻天使
UID:1895760
精华:0
主题:11
帖子:172
威望:743
天使币:1588
宣传度:100
天然°:50
腹黑°:50
精灵:0
原石:0
阅读权限:130
注册时间:2019-9-25
状态: 不在线

  • TA的每日心情

    签到天数: 37天[LV.5]常住居民I

  • dengxiaochu 发表于 2019-12-2 19:31:31 来自手机 |显示全部楼层
    本帖最后由 dengxiaochu 于 2019-12-2 19:51 编辑

    国内的大部分帖子都是要调高。但是在国外的这个网页
    http://wiki.hydrogenaud.io/index.php?title=EAC_Options
    上面却说要把它调低比较好。
    原文是这样的:
    Error recovery quality
    (Default: Medium, Recommended: Low)
    When an error is detected after reading a frame, EAC re-reads the frame 16 times in an attempt to get at least 8 identical results. The error recovery quality setting determines the maximum number of times EAC will do the 16 re-reads:
    Low = one batch of 16 re-reads
    Medium = up to three batches of 16 re-reads (16, 32, or 48, total)
    High = up to five batches of 16 re-reads (16, 32, 48, 64, or 80, total)
    For each batch of 16 re-reads, there's a row of red error correction "lights" in the extraction status window. If no batch of 16 re-reads produced 8 identical results, EAC considers whatever data it got to be "suspicious" rather than correct. EAC continues reading the entire batch of 16, even if it has already obtained 8 identical reads.
    Setting this option to medium or high may or may not result in a reduction of errant data in the event that re-read sets are required. Unfortunately, errors can occur with consistency and as such, more aggressive settings can result in errant data going unreported as being suspicious. While medium may be of some benefit to lightly damaged discs, high generally leads to diminishing returns. A section of audio that can't be ripped correctly through three sets of re-reads is likely not going to be ripped correctly after two additional sets. It is also unlikely that the two additional re-read sets offered by the high setting will deliver an audibly superior result. Furthermore, ignoring the additional ripping time required before EAC finishes, forcing the drive to perform additional re-read sets increases wear. However, because EAC chooses the most consistent data over all the re-reads performed in the event that 8 identical results aren't found in any given re-read set, increasing the total number of re-reads might be of some benefit (provided that the most consistent data also happens to be error-free). It is recommended that high be reserved for use in the event that an accurate result can't be obtained otherwise. Correction through the CUETools database is a far more effective way to handle ripping errors than EAC's archaic method of using re-read sets which has never really worked that well on the whole.
    用百度翻译翻译之后是这样的:
    错误恢复质量
    (默认值:中,建议值:低)
    当读取帧后检测到错误时,EAC重新读取帧16次,以尝试获得至少8个相同的结果。错误恢复质量设置确定EAC将做16次重读的最大次数:
    低=一批16次重新读取
    介质=最多三批16次重新读取(总共16、32或48次)
    高=最多5批16次重新读取(总共16、32、48、64或80次)
    对于每批16次重新读取,在提取状态窗口中有一行红色的错误纠正“指示灯”。如果没有一批16次重读产生8个相同的结果,EAC认为它得到的任何数据是“可疑的”,而不是正确的。EAC继续读取整批16个,即使它已经获得8个相同的读取。
    如果需要重新读取集合,则将此选项设置为“中”或“高”可能会或可能不会导致错误数据的减少。不幸的是,错误会随着一致性而发生,因此,更激进的设置可能导致错误数据未报告为可疑数据。虽然介质可能对轻微损坏的圆盘有一定的好处,但较高的介质通常会导致收益递减。如果一段音频不能通过三组重读正确地翻录,那么在另外两组重读之后就很可能无法正确地翻录。另外,高设置提供的两个额外的重读集也不太可能产生明显的优越结果。此外,忽略在EAC完成之前所需的额外剥离时间,强制驱动器执行额外的重新读取设置会增加磨损。但是,由于在任何给定的重新读取集中都没有找到8个相同结果的情况下,EAC选择的是最一致的数据,因此增加重新读取的总数可能会有一些好处(前提是最一致的数据碰巧也是无错的)。建议在无法获得准确结果的情况下保留high以供使用。通过CUETools数据库进行更正是处理翻录错误的一种更有效的方法,而不是EAC使用重新读取集的古老方法,这种方法在整体上从未真正起到那么好的作用。


    大佬们说说该怎么调比较好?


    dengxiaochu于2019-12-2 19:50补充以下内容:
    还有关于缓存的设定。原文是这样的。
    Drive caches audio data[edit]
    In order for secure mode to work properly, every read request made by EAC must cause the drive to seek data from the CD. If your drive caches audio, subsequent requests for the same data may result in the drive only fetching this data from its buffer, rather than from the physical disc. To prevent this from happening, EAC has a routine to ensure previously requested data gets flushed from drive's cache. This is done by having the drive read extra data from the disc—more data than the cache can store.
    If the "Detect Read Features..." function reports "Caching : Yes", it is important that you enable the cache flushing routine by checking the "Drive caches audio data" box.
    If the "Detect Read Features..." function reports "Caching : No", it is not necessary to enable the flushing routine. Checking the "Drive caches audio data" box with drives that are reported by EAC as not caching will not improve EAC's accuracy. It won't improve EAC's ability to detect errors nor EAC's ability to correct them. What it will do however, is reduce your ripping speed and shorten the life of your drive.
    Tip #1: If you're concerned that your drive caches audio data even though EAC is saying otherwise, try ripping a scratched disc (one known to produce errors easily). Make sure you uncheck the "Drive caches audio data" setting AND uncheck the "Drive is capable of retrieving C2 error information" setting. Make sure you also set the error recovery quality to "Low" (this setting can be found under the Extraction tab in the EAC Options dialog). If EAC is capable of displaying a read error then cache flushing isn't necessary. Ignore any sync errors that may be displayed; they are irrelevant to this test.
    Tip #2: Tip #1 is all you need to know, but if you're still paranoid that your drive caches audio, feel free to try Feurio's audio caching test (Ctrl+Alt+P\Test device\Cache test) or spath's cache explorer. If either determine that your drive doesn't cache or caches less than 64 KB of data, then cache flushing isn't necessary (ignore the reported buffer size when using cache explorer). The reason for the 64 KB barrier is that EAC will never request less than this amount while ripping (link).
    Note: If "Drive has 'Accurate Stream' feature" is deselected, then "Drive caches audio data" is automatically checked, regardless of whether the drive actually caches audio data.

    实在有些看不懂。不过看样子我的驱动器好像不支持这个功能。
    tyj518
    tyj518

    梦幻天使
    UID:706372
    精华:0
    主题:1
    帖子:232
    威望:528
    天使币:2055
    宣传度:51
    天然°:10
    腹黑°:10
    精灵:0
    原石:0
    阅读权限:130
    注册时间:2013-6-1
    来自:杭州
    状态: 不在线

  • TA的每日心情
    奋斗

    签到天数: 45天[LV.5]常住居民I

  • tyj518 发表于 2019-12-3 08:26:11 |显示全部楼层
    根据那个网页的说法,error recovery quality设得越高,EAC从坏区中重复读取数据的次数会越高,那么读出数据的可能性也就越大,但读出的数据不保证“正确”。
    不过EAC官方也说了,一旦发生了从坏区中重复读取取数据的情况,那么抓轨的log文件中Track Quality一项便不会是100%,即使你把error recovery quality设高。一般来说,如果你希望尽可能完整地把数据抓下来,那么把error recovery quality设得高一些比较好,事后可以检查log里的Track Quality来判断整体抓轨质量。但如果愿意放弃数据的完整性而追求读出数据的正确性,那么把error recovery quality设得低一些比较好。

    后面关于缓存的设定是说,部分光驱带有缓存功能,读盘时会将读取的数据放入缓存来加快再次访问的速度,这会使得EAC重复抓取失去其效果。EAC自己有Detect Read Features的功能,它会帮你检查你的光驱是否有缓存功能,有的话需要在Drive Options里面做相应的设置。

    使用道具 举报

    wanghao1111

    LEVEL 7 调停者
    UID:257472
    精华:0
    主题:1
    帖子:5138
    威望:10213
    天使币:23869
    宣传度:35
    天然°:1619
    腹黑°:1600
    精灵:0
    原石:0
    阅读权限:110
    注册时间:2012-4-15
    状态: 不在线

  • TA的每日心情
    无聊

    签到天数: 1640天[LV.Master]伴坛终老

  • wanghao1111 发表于 2019-12-3 09:31:42 |显示全部楼层
    升级
    谢谢分享

    使用道具 举报

    myocytebd
    相信魔法和奇迹的祈手

    梦幻天使★
    UID:1912457
    头衔:弯弯曲曲
    精华:0
    主题:0
    帖子:10
    威望:3009
    天使币:1208
    宣传度:500
    天然°:200
    腹黑°:200
    精灵:0
    原石:0
    阅读权限:135
    注册时间:2019-12-3
    来自:里世界
    状态: 不在线

  • TA的每日心情
    郁闷

    签到天数: 8天[LV.3]偶尔看看II

  • myocytebd 发表于 2019-12-4 01:22:18 |显示全部楼层
    一般的盘根本不会出错,何谈纠错。
    除非是特别古老或者保存状态恶劣的。

    那个英文网页说的是符合逻辑的。
    因为实际上根本就没有足够的冗余信息校验纠正,多次读取(用来"纠错")只是自欺欺人。

    使用道具 举报

    gyxingzhizi
    蓝屏帝

    LEVEL 1 断罪
    UID:1396861
    精华:0
    主题:1
    帖子:171
    威望:186
    天使币:521
    宣传度:0
    天然°:92
    腹黑°:92
    精灵:0
    原石:0
    阅读权限:15
    注册时间:2016-1-1
    状态: 不在线

  • TA的每日心情
    郁闷

    签到天数: 48天[LV.5]常住居民I

  • gyxingzhizi 发表于 2019-12-4 14:49:24 |显示全部楼层
    没试过,纯支持

    使用道具 举报

    您需要登录后才可以回帖 登录 | 注册

    加天使同城QQ群,有威望奖励~

    Archiver|手机版|WAP| 天使动漫论坛   

    声明:本站所有内容资源均来自网络&网友分享,仅供学习试用。如侵犯您的权益请告知,将会第一时间删除。广告联系我的邮箱

    GMT+8, 2019-12-14 13:16 , Processed in 0.139008 second(s), 31 queries , Gzip On, Memcache On.

    Powered by Discuz! X2

    © 2001-2011 Comsenz Inc.

    回顶部