首先下下来后，先用把整个文件夹直接拖进cuetools，选择verify,点击GO！
泡好茶后，回来发现扫描结束了，开始人工分析下日志
1. 多专辑的分析结果全部挤在cuetools底下小框里，太难看了。一般我会全选复制到文本浏览器(比如notepad++/vscode)上查看
2. 绝大部分形如 "AR: rip accurate (x/y), CTDB: verified OK, confidence xx". confidence 就是常说的置信度，越高说明你手上的专辑和越多人抓轨的完全一致。同时越多也说明这个歌手/专辑当年发行的热门程度，像Yui当年因为动漫爆红，其置信度一眼望去都在50以上，热门专更是上百。记住这点
3. 所以我们把"verified ok, confidence xx"这种置信度40以上的日志直接从文本中删去，目标是保留可能有问题的日志。
4. 删完高置信度的日志条目后，剩下以下5个可疑专辑:
No.1: \Albums\[2010.07.14] HOLIDAYS IN THE SUN\01. YUI — to Mother.flac: AR: disk not present in database, CTDB: disk not present in database.
No.2: \Singles\[2004.12.24] It's happy line\01. YUI — It's happy line.flac: AR: disk not present in database, CTDB: disk not present in database.
No.3: \Singles\[2007.01.17] Rolling star\01. YUI — Rolling star.flac: AR: disk not present in database, CTDB: disk not present in database.
No.4: \Singles\[2007.06.13] My Generation／Understand\01. YUI — My Generation.flac: AR: rip accurate (1/1), CTDB: verified OK, confidence 1.
No.5: \Singles\[2011.01.26] It's My Life／Your Heaven\01. YUI — It's My Life.flac: AR: rip not accurate (0/11), CTDB: differs in 13819 samples, confidence 50, or verified OK, confidence 1.
No.1-3的问题是"not present in database"
No.4的问题是置信度太低，只有1
No.1-3的问题是"differs in xx sample, confidence 50 ， or ..."，即和50置信度的版本有不少区别
我们逐个具体分析下

No.1-3专辑的accurip日志显示:“AR: disk not present in database, CTDB: disk not present in database”
意思是这个专辑的校验码无法在[AR]和[CTDB]这两个cd抓轨校验码数据库中找到,有以下可能:
A. 可能这个专辑不是cdrip而是来自web(比如qobuz/mora/tidal....)
B. 可能这个专辑最近刚刚发行，抓轨人极少，而且这一版抓轨用的软件没有向那两个数据库汇报
C. 可能这个专辑极其冷门或者珍稀，抓轨人极少，而且这一版抓轨用的软件没有向那两个数据库汇报

首先A排除，这几个专辑里面几乎都有抓轨log，甚至是100%log(用之前帖子提到的cambia logtools网站检测)
其次根据我对Yui的了解（她属于人气歌手，销量常年上榜，而且也是老专辑了），以及前面提到其置信度50以上， B/C也可以排除。显然这3个专辑是有问题的，我们一个个看看:

No.1 HOLIDAYS IN THE SUN
进入文件夹，用文本编辑器打开.accurip文件，可以看到如下报告(我只截取重点)：
...
[CTDB TOCID: F6oRgf4F9lkUchCdwut0izl9ZhQ-] disk not present in database.
[AccurateRip ID: 0016ab34-00e278ca-b10b310d] disk not present in database.
...
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100.0 [A4D4774A] [C0CC18C8]
01 100.0 [1624692A] [06E875B1] CRC32
02 100.0 [2D78F9DE] [C0C18080] CRC32
...

解释下表格部分(参考 wiki/CUETools_log）
Track表示曲目编号，Peak是频响峰值, 后面那几列都代表了校验码，其中[crc32]列代表利用了静音部分(空采样,null sample)的校验码，[W/O NULL]列代表不用静音部分的校验码。而[log]列代表当专辑包含抓轨log时，该曲目抓轨时的校验码。
上面表格中[log]列全部是CRC32, 表示抓轨日志的校验码和当前文件利用了静音部分计算的校验码一致(即[CRC32]列)，说明文件来源和log一致
根据我们前面推测，这个抓轨应该至少有50左右置信度才正常。那么大概率这个抓轨是有问题的(因为Log100%抓轨质量较高，很可能是盘本身的问题），并且此次抓轨校验码没有上传到db。

验证:
1. 打开此专辑目录下的.log文件，可以发现没有accurip相关内容，说明本次抓轨确实没有上传db，抓轨用户没有启用EAC的accurip功能！
2. 去别的地方下一个这个专辑，利用cuetools检测一下，其置信度其实高达479
这就是我放弃保存这个专辑的来龙去脉

No.3 Rolling Star
打开.accurip文件，可以看到如下报告：
...
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100.0 [755516A0] [D6C981BB]
01 100.0 [0C497563] [479B7398] [8E6A2431]
02 100.0 [9CBABC5F] [BA50A7A7] [63631AAF]
03 99.0 [80B4E19D] [7D54A223] [FDD8A2D2]
04 100.0 [39A9FB91] [D2E9CC98] [C53803F4]
...
[LOG]列和当前计算出来的两列校验码完全不一致，显然音频文件和抓轨的都未必是同源的了。所以提供报酬请求别人提供带日志的cd抓轨的朋友们，一定要用cuetools检查一下。可能有的人会伪造日志，拼凑资源，蒙混过关。
这个档显然留不得
去rutrack下了一份同专辑，能发现其置信度高达67

No.2 It's happy line
打开.accurip文件，可以看到如下报告：
...
Track Peak [ CRC32 ] [W/O NULL]
-- 100.0 [9470CB00] [022E3CDE]
01 100.0 [F0C0DDD6] [1AA82DBD]
02 100.0 [AAE4027E] [60B97438]
...
简体题，这份没有log，自然accurip报告也没有log校验码列。
可能是web源，也可能是问题抓轨，不得而知。

No.4 My Generation／Understand
有意思的题目。打开.accurip文件，可以看到如下报告：
...
Track | CTDB Status
1 | (1/1) Accurately ripped
2 | (1/1) Accurately ripped
3 | (1/1) Accurately ripped
4 | (1/1) Accurately ripped
[AccurateRip ID: 00028fed-000a3770-25037e04] found.
Track [ CRC | V2 ] Status
01 [6b28aeac|4090ae10] (1+0/1) Accurately ripped
02 [52234d3b|c964a079] (1+0/1) Accurately ripped
03 [b34640dd|005f4e15] (1+0/1) Accurately ripped
04 [4a9954c2|024bbcde] (1+0/1) Accurately ripped
...
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 100.0 [6CA245A3] [742A1EF7]
01 100.0 [DE8408A5] [63291193] CRC32
02 100.0 [F92F15AE] [589B12C7] CRC32
03 100.0 [A9B633D8] [4D90F008] CRC32
04 100.0 [176D1B6F] [8D48ADCD] CRC32
...
置信度为1，有100%log且和log校验码一致！也就是说这次问题抓轨是上报到数据库了！
但是为何不是(1/50以上)，而是(1/1)？难道就他抓轨？
利用cambia logtools, 在cuetools栏我们能进入其数据库页面，tocid=G8HjxjNgrZnsqJTI_Je9ecMmtL4-(链接我就不发了，度娘吞的话又要重搞)
然后另外在其它地方下同专辑，置信度为41，根据[tocid=G8HjxjNgrZnsqJTI_Je9ecMmtL4-]进入数据库页面
能发现这俩本应归入同一专辑，但是置信度为1的这个档在db里的专辑名称是[My Generation], 而高置信度的是[My Generation / Understand]，导致它的accurip报告是(1/1)而不是(1/42)--被误认为不同专辑
如果不是抓轨人中奖了，那可能就是CD-R之类的，里面专辑名都是错误的

No.5 It's My Life／Your Heaven
最后一个了。“differs in 13819 samples, confidence 50, or verified OK, confidence 1”
意思是和置信度50的那个版本有13819 samples有区别。

简单说下CTDB的特点:
记录Disc ID，以此为唯一索引，根据校验码区分各个版本。同时记录各个版本的RS纠错码(Reed-Solomon eraser code)，以180kb的额外数据来提供一定的纠错&修复能力。
Reference:ctdb wiki 或者 hydroaudi 论坛cuetools置顶帖子

CTDB既能识别出你这个极低置信度版本和高置信度版本是同专辑，也能通过算法恢复出来。
方法:(百度有图文教程)
cuetools选择左上角模式改为fix, Action栏目下拉选择框选择repair, 上面圆圈勾选encode
cuetools就会为修复出一份置信度50的版本！
可靠性如何？
你把修复完毕的版本重新过一遍accurip就知道了。
CTDB在14年前就加入了这个重磅功能，我利用这个修复了很多可疑的CDrip，而且开发者坚持免费提供服务，真是太有爱了

哥，能给个nyaa网址么

补充案例:
专辑 [相鉄都心直通記念ムービー「100 YEARS TRAIN」テーマソング] by [yui (FLOWER FLOWER) × ミゾベリョウ (odol)] 从亚麻下下来后，无聊用cuetools过了一下，出现了以下结果
Padded some input files to a frame boundary.
(如果是CD源，很有可能来自有损转码。)
且该专辑和q音版本对比过，[W/O NULL] 这行校验码完全一致。

这样就发现了cuetools一个新用途，不用另外对amazon删掉null sample就可以和其它web源做对比了~
可惜仅限16-44

现在看频谱的软件很多
缺的事验证bit真假的软件
总不能拉开数采样数吧.
目前急需开发一个能严重bit真假的软件。频谱一眼就能看真假，还是后期升的，

audio-4U看了一下，就是博客形式发布了，博文主题有公司名、年代名、歌手名……感觉还是有个人化比较散漫的管理色彩的。