A number of successful rips (as reported by whipper's log) fail during image verification when run immediately afterwards.
I ripped and verified the CD twice and can confirm all outputs are identical (md5sum of the flac files also matches). CUETools also reports the rips as being accurate.
I just finished ripping a large part of my collection and only a handful CDs showed this problem.
Tested using the whipper v0.10.0 docker image.
End of rip log file:
Conclusive status report:
AccurateRip summary: All tracks accurately ripped
Health status: No errors occurred
EOF: End of status report
End of rip terminal output:
INFO:whipper.common.program:18 AccurateRip response(s) found
track 0: unknown (not tracked)
track 1: rip accurate (confidence 77 of 97) v1 [3457efad], v2 [42070b06], DB [3457efad, 42070b06]
track 2: rip accurate (confidence 77 of 98) v1 [06db4f2d], v2 [a3b6f239], DB [06db4f2d, a3b6f239]
track 3: rip accurate (confidence 77 of 96) v1 [f21d64c1], v2 [32a1fa4c], DB [f21d64c1, 32a1fa4c]
track 4: rip accurate (confidence 76 of 98) v1 [2b6ea5a2], v2 [d402d14e], DB [2b6ea5a2, d402d14e]
track 5: rip accurate (confidence 77 of 97) v1 [0886a006], v2 [9f4792bb], DB [0886a006, 9f4792bb]
track 6: rip accurate (confidence 77 of 98) v1 [0cc69c0e], v2 [1799c299], DB [0cc69c0e, 1799c299]
track 7: rip accurate (confidence 77 of 98) v1 [f849b94d], v2 [2e723222], DB [f849b94d, 2e723222]
track 8: rip accurate (confidence 78 of 96) v1 [6c7eae25], v2 [c0324e25], DB [6c7eae25, c0324e25]
whipper image verify <.cue> output:
INFO:whipper.common.program:4 AccurateRip response(s) found
track 1: rip NOT accurate (max confidence 46) v1 [3457efad], v2 [42070b06], DB [ec8d8865]
track 2: rip NOT accurate (max confidence 46) v1 [06db4f2d], v2 [a3b6f239], DB [e2e50a41]
track 3: rip NOT accurate (max confidence 45) v1 [f21d64c1], v2 [32a1fa4c], DB [90c3644c]
track 4: rip NOT accurate (max confidence 46) v1 [2b6ea5a2], v2 [d402d14e], DB [2125592d]
track 5: rip NOT accurate (max confidence 45) v1 [0886a006], v2 [9f4792bb], DB [7c87c32b]
track 6: rip NOT accurate (max confidence 44) v1 [0cc69c0e], v2 [1799c299], DB [03e454df]
track 7: rip NOT accurate (max confidence 45) v1 [f849b94d], v2 [2e723222], DB [306cae39]
track 8: rip NOT accurate (max confidence 45) v1 [6c7eae25], v2 [c0324e25], DB [6e973f9b]
What does the DB column represent? Because that's the part that seems to differ between the rip and verify log.
CUETools output:
[CUETools log; Date: 20/02/2026 21:38:54; Version: 2.2.6]
Pregap length 00:00:32.
[CTDB TOCID: fDGP6NDDm6e_59196CJMIM5w7xE-] found.
Track | CTDB Status
1 | (867/1079) Accurately ripped
2 | (865/1079) Accurately ripped
3 | (865/1079) Accurately ripped
4 | (868/1079) Accurately ripped
5 | (866/1079) Accurately ripped
6 | (868/1079) Accurately ripped
7 | (863/1079) Accurately ripped
8 | (870/1079) Accurately ripped
[AccurateRip ID: 000d2650-0057ac61-59094908] found.
Track [ CRC | V2 ] Status
01 [3457efad|42070b06] (024+077/451) Accurately ripped
02 [06db4f2d|a3b6f239] (024+077/453) Accurately ripped
03 [f21d64c1|32a1fa4c] (024+077/449) Accurately ripped
04 [2b6ea5a2|d402d14e] (024+076/452) Accurately ripped
05 [0886a006|9f4792bb] (024+077/450) Accurately ripped
06 [0cc69c0e|1799c299] (024+077/451) Accurately ripped
07 [f849b94d|2e723222] (024+077/449) Accurately ripped
08 [6c7eae25|c0324e25] (021+078/447) Accurately ripped
Offsetted by 664:
01 [bc05c8ec] (016/451) Accurately ripped
02 [b9e2e80e] (016/453) Accurately ripped
03 [ca1f3155] (016/449) Accurately ripped
04 [4eec0714] (016/452) Accurately ripped
05 [1725feb6] (015/450) Accurately ripped
06 [7d68fad2] (016/451) Accurately ripped
07 [5b22395d] (017/449) Accurately ripped
08 [057f9e5d] (015/447) Accurately ripped
Offsetted by 1214:
01 [48bdb688] (002/451) Accurately ripped
02 [9766492e] (002/453) Accurately ripped
03 [390d4eaa] (002/449) Accurately ripped
04 [6d561585] (002/452) Accurately ripped
05 [938f9002] (002/450) Accurately ripped
06 [96e0107a] (002/451) Accurately ripped
07 [20abea61] (002/449) Accurately ripped
08 [4f0755eb] (002/447) Accurately ripped
Offsetted by 1331:
01 [e2956719] (040/451) Accurately ripped
02 [a91d8df3] (040/453) Accurately ripped
03 [9ebdac9a] (039/449) Accurately ripped
04 [0d2ed98a] (040/452) Accurately ripped
05 [5319d6c7] (040/450) Accurately ripped
06 [ee2ac509] (039/451) Accurately ripped
07 [d654608f] (039/449) Accurately ripped
08 [c2471d8c] (026/447) Accurately ripped
Offsetted by 1452:
01 [fc8570a7] (060/451) Accurately ripped
02 [04e4919e] (061/453) Accurately ripped
03 [3d01bba8] (059/449) Accurately ripped
04 [ca76d486] (059/452) Accurately ripped
05 [625ef4ab] (059/450) Accurately ripped
06 [821932a1] (058/451) Accurately ripped
07 [01c9b595] (057/449) Accurately ripped
08 [0fe4f921] (040/447) Accurately ripped
Offsetted by -12:
01 [de77a2df] (000/451) No match (V2 was not tested)
02 [360d8276] (000/453) No match (V2 was not tested)
03 [302249b1] (000/449) No match (V2 was not tested)
04 [8a819522] (000/452) No match (V2 was not tested)
05 [b8de3c3f] (000/450) No match (V2 was not tested)
06 [f44ec481] (000/451) No match (V2 was not tested)
07 [96e31cc5] (000/449) No match (V2 was not tested)
08 [dd647249] (000/447) No match (V2 was not tested)
Offsetted by 667:
01 [4d82bdc7] (000/451) No match (V2 was not tested)
02 [f234eb66] (000/453) No match (V2 was not tested)
03 [39c7a42c] (000/449) No match (V2 was not tested)
04 [b0f1449f] (000/452) No match (V2 was not tested)
05 [06398dbf] (000/450) No match (V2 was not tested)
06 [c38b6b7d] (000/451) No match (V2 was not tested)
07 [737be07f] (000/449) No match (V2 was not tested)
08 [29462d54] (000/447) No match (V2 was not tested)
Track Peak [ CRC32 ] [W/O NULL] [ LOG ]
-- 82,4 [D78DA391] [C65D3AB7]
01 82,4 [B882933C] [BC3F99AB] CRC32
02 76,0 [35D8AD82] [34D7ED34] CRC32
03 75,6 [3F137718] [958E3B3A] CRC32
04 75,9 [14D52FCB] [E6B1AD76] CRC32
05 65,7 [54D5AC2A] [A899256C] CRC32
06 73,1 [5241ABBF] [3E90EEEA] CRC32
07 76,5 [16876DD4] [E4FFCDED] CRC32
08 44,1 [D41F09F5] [39AD389B] CRC32
Potentially related to these older issues? #339, which supposedly is a duplicate of #239, but the latter seems different from what I'm reporting here, since the initial rip proceeded without any problems.
A number of successful rips (as reported by whipper's log) fail during image verification when run immediately afterwards.
I ripped and verified the CD twice and can confirm all outputs are identical (md5sum of the flac files also matches). CUETools also reports the rips as being accurate.
I just finished ripping a large part of my collection and only a handful CDs showed this problem.
Tested using the whipper v0.10.0 docker image.
End of rip log file:
End of rip terminal output:
whipper image verify <.cue>output:What does the DB column represent? Because that's the part that seems to differ between the rip and verify log.
CUETools output:
Potentially related to these older issues? #339, which supposedly is a duplicate of #239, but the latter seems different from what I'm reporting here, since the initial rip proceeded without any problems.