I have a known problematic disc that causes a split second glitch when ripped with EAC secure or dbpoweramp secure. So I decided to give CueTools a try since it has a repair feature, but I'm not seeing that option?
(https://i.imgur.com/xXM94ov.png)
For the above I made a new rip using CueTools selecting tracks since I prefer that to having a single flac file with cue sheet.
Here is the verify log:
[CUETools log; Date: 11/28/2018 12:25:32 PM; Version: 2.1.6]
[CTDB TOCID: HUg17t81nRbTeiKEWh5nW8ddyLk-] found.
Track | CTDB Status
1 | (18/18) Accurately ripped
2 | (18/18) Accurately ripped
3 | (18/18) Accurately ripped
4 | (18/18) Accurately ripped
5 | (18/18) Accurately ripped
6 | (18/18) Accurately ripped
7 | (18/18) Accurately ripped
8 | (18/18) Accurately ripped
9 | (18/18) Accurately ripped
10 | (18/18) Accurately ripped
11 | (18/18) Accurately ripped
12 | ( 6/18) Accurately ripped, or (12/18) differs in 2948 samples @02:05:26-02:05:27,02:07:67,02:09:31-02:09:32,02:09:50,02:10:71-02:10:72,02:11:15-02:11:16,02:11:53-02:11:54,02:11:72,02:12:35
[AccurateRip ID: 001c3f5d-010e519d-9b0fa00c] found.
Track [ CRC | V2 ] Status
01 [30d56f86|4d20c4cf] (00+00/19) No match
02 [7bda4f12|173017c1] (00+00/20) No match
03 [296fd89a|78b91638] (00+00/20) No match
04 [3e365711|91cd8131] (00+00/20) No match
05 [1c6432de|4df536f1] (00+00/20) No match
06 [a0d777f3|67ed279d] (00+00/20) No match
07 [3b12cbae|59d1ae8f] (00+00/20) No match
08 [b8ce794e|09a27ee5] (00+00/19) No match
09 [e27c1448|5f5d9ce5] (00+00/19) No match
10 [9700b2d6|0c924e62] (00+00/19) No match
11 [811bcf02|a0b6010c] (00+00/19) No match
12 [f7b2dd87|ce16126b] (00+00/18) No match
Offsetted by -92:
01 [d37514ef] (03/19) Accurately ripped
02 [9056c194] (03/20) Accurately ripped
03 [a8485ba9] (03/20) Accurately ripped
04 [906a8cbf] (03/20) Accurately ripped
05 [37289ebc] (03/20) Accurately ripped
06 [dcb36159] (03/20) Accurately ripped
07 [09286d65] (03/20) Accurately ripped
08 [c202faff] (03/19) Accurately ripped
09 [cb0f9417] (03/19) Accurately ripped
10 [5eef9fef] (03/19) Accurately ripped
11 [34449aac] (03/19) Accurately ripped
12 [024022dd] (00/18) No match (V2 was not tested)
Offsetted by -6:
01 [5f37901e] (05/19) Accurately ripped
02 [753392eb] (05/20) Accurately ripped
03 [19370e1a] (05/20) Accurately ripped
04 [3d4af5ac] (05/20) Accurately ripped
05 [1717a93e] (05/20) Accurately ripped
06 [9fd98b1a] (05/20) Accurately ripped
07 [7ea63d23] (05/20) Accurately ripped
08 [34e71f9e] (05/19) Accurately ripped
09 [e7d15efc] (05/19) Accurately ripped
10 [8617c67c] (05/19) Accurately ripped
11 [cc5ca7ad] (05/19) Accurately ripped
12 [ccc5d86a] (00/18) No match (V2 was not tested)
Track Peak [ CRC32 ] [W/O NULL]
-- 99.9 [CA6EDF36] [26CFB5CC]
01 67.9 [50309B21] [2B7BBC3D]
02 56.1 [B7CDCC85] [9DE5FF45]
03 73.0 [5BE6D2A3] [FD5EDBDC]
04 77.1 [8DE060E8] [699B3D32]
05 81.1 [3EAF01C1] [32B2B370]
06 88.5 [29B95190] [C7F037B5]
07 72.1 [C93793AA] [626AED85]
08 65.4 [95A515B0] [310DCED4]
09 99.9 [960ACAFE] [9765AAC5]
10 86.6 [3DEFD43A] [E54FC1A2]
11 80.1 [4E346361] [EF649ECB]
12 77.6 [013C3DE7] [12B26873]
Change the pulldown menu on the right from default to repair.
Change the pulldown menu on the right from default to repair.
Ahh, thank you! Amazing it fixed the glitch.
Here is the .accurip file I opened in Notepad after the Repair. Does this look alright?
If I am reading that right it is compared the "Repair"-ed files with a rip done with offset offset of -92 and verified it as Accurate against it. And compared against a rip done with an offset of -6 and verified it as Accurate against it?
[CUETools log; Date: 11/28/2018 4:21:59 PM; Version: 2.1.6]
CUETools DB: corrected 2948 errors.
[AccurateRip ID: 001c3f5d-010e519d-9b0fa00c] found.
Track [ CRC | V2 ] Status
01 [30d56f86|4d20c4cf] (00+00/19) No match
02 [7bda4f12|173017c1] (00+00/20) No match
03 [296fd89a|78b91638] (00+00/20) No match
04 [3e365711|91cd8131] (00+00/20) No match
05 [1c6432de|4df536f1] (00+00/20) No match
06 [a0d777f3|67ed279d] (00+00/20) No match
07 [3b12cbae|59d1ae8f] (00+00/20) No match
08 [b8ce794e|09a27ee5] (00+00/19) No match
09 [e27c1448|5f5d9ce5] (00+00/19) No match
10 [9700b2d6|0c924e62] (00+00/19) No match
11 [811bcf02|a0b6010c] (00+00/19) No match
12 [fbb5240d|d7406d1f] (00+00/18) No match
Offsetted by -92:
01 [d37514ef] (03/19) Accurately ripped
02 [9056c194] (03/20) Accurately ripped
03 [a8485ba9] (03/20) Accurately ripped
04 [906a8cbf] (03/20) Accurately ripped
05 [37289ebc] (03/20) Accurately ripped
06 [dcb36159] (03/20) Accurately ripped
07 [09286d65] (03/20) Accurately ripped
08 [c202faff] (03/19) Accurately ripped
09 [cb0f9417] (03/19) Accurately ripped
10 [5eef9fef] (03/19) Accurately ripped
11 [34449aac] (03/19) Accurately ripped
12 [00d65ddb] (02/18) Accurately ripped
Offsetted by -6:
01 [5f37901e] (05/19) Accurately ripped
02 [753392eb] (05/20) Accurately ripped
03 [19370e1a] (05/20) Accurately ripped
04 [3d4af5ac] (05/20) Accurately ripped
05 [1717a93e] (05/20) Accurately ripped
06 [9fd98b1a] (05/20) Accurately ripped
07 [7ea63d23] (05/20) Accurately ripped
08 [34e71f9e] (05/19) Accurately ripped
09 [e7d15efc] (05/19) Accurately ripped
10 [8617c67c] (05/19) Accurately ripped
11 [cc5ca7ad] (05/19) Accurately ripped
12 [bfbb825c] (05/18) Accurately ripped
Track Peak [ CRC32 ] [W/O NULL]
-- 99.9 [93E383FB] [509950B9]
01 67.9 [50309B21] [2B7BBC3D]
02 56.1 [B7CDCC85] [9DE5FF45]
03 73.0 [5BE6D2A3] [FD5EDBDC]
04 77.1 [8DE060E8] [699B3D32]
05 81.1 [3EAF01C1] [32B2B370]
06 88.5 [29B95190] [C7F037B5]
07 72.1 [C93793AA] [626AED85]
08 65.4 [95A515B0] [310DCED4]
09 99.9 [960ACAFE] [9765AAC5]
10 86.6 [3DEFD43A] [E54FC1A2]
11 80.1 [4E346361] [EF649ECB]
12 77.6 [58B1612A] [38426FA1]
The pressing might have a manufacturing flaw. The checksums for track 12 were consistent in EAC, dBpoweramp and CUERipper plus 4 previous rips submitted/confirmed in the CUETools DB (I'm looking at the database).
You're reading the .accurip file correctly. However note that .accurip file is written during the process and the new audio files aren't re-verified after all are written. Shouldn't matter, just making you aware.
The pressing might have a manufacturing flaw. The checksums for track 12 were consistent in EAC, dBpoweramp and CUERipper plus 4 previous rips submitted/confirmed in the CUETools DB (I'm looking at the database).
Any chance this would have been my rip, I did rip it with EAC, dbpoweramp and Cueripper all within 2 days using 2 different drives. One with offset of 102 and other offset 103.
The disc is new and visually pristine so you could be right about it being a manufacturing defect.
I just did Verify on the files that were repaired and this is the log file that CueTools generated.
[CUETools log; Date: 11/29/2018 9:17:06 AM; Version: 2.1.6]
[CTDB TOCID: HUg17t81nRbTeiKEWh5nW8ddyLk-] found.
Track | CTDB Status
1 | (18/18) Accurately ripped
2 | (18/18) Accurately ripped
3 | (18/18) Accurately ripped
4 | (18/18) Accurately ripped
5 | (18/18) Accurately ripped
6 | (18/18) Accurately ripped
7 | (18/18) Accurately ripped
8 | (18/18) Accurately ripped
9 | (18/18) Accurately ripped
10 | (18/18) Accurately ripped
11 | (18/18) Accurately ripped
12 | (12/18) Accurately ripped, or (6/18) differs in 2948 samples @02:05:26-02:05:27,02:07:67,02:09:31-02:09:32,02:09:50,02:10:71-02:10:72,02:11:15-02:11:16,02:11:53-02:11:54,02:11:72,02:12:35
[AccurateRip ID: 001c3f5d-010e519d-9b0fa00c] found.
Track [ CRC | V2 ] Status
01 [30d56f86|4d20c4cf] (00+00/19) No match
02 [7bda4f12|173017c1] (00+00/20) No match
03 [296fd89a|78b91638] (00+00/20) No match
04 [3e365711|91cd8131] (00+00/20) No match
05 [1c6432de|4df536f1] (00+00/20) No match
06 [a0d777f3|67ed279d] (00+00/20) No match
07 [3b12cbae|59d1ae8f] (00+00/20) No match
08 [b8ce794e|09a27ee5] (00+00/19) No match
09 [e27c1448|5f5d9ce5] (00+00/19) No match
10 [9700b2d6|0c924e62] (00+00/19) No match
11 [811bcf02|a0b6010c] (00+00/19) No match
12 [fbb5240d|d7406d1f] (00+00/18) No match
Offsetted by -92:
01 [d37514ef] (03/19) Accurately ripped
02 [9056c194] (03/20) Accurately ripped
03 [a8485ba9] (03/20) Accurately ripped
04 [906a8cbf] (03/20) Accurately ripped
05 [37289ebc] (03/20) Accurately ripped
06 [dcb36159] (03/20) Accurately ripped
07 [09286d65] (03/20) Accurately ripped
08 [c202faff] (03/19) Accurately ripped
09 [cb0f9417] (03/19) Accurately ripped
10 [5eef9fef] (03/19) Accurately ripped
11 [34449aac] (03/19) Accurately ripped
12 [00d65ddb] (02/18) Accurately ripped
Offsetted by -6:
01 [5f37901e] (05/19) Accurately ripped
02 [753392eb] (05/20) Accurately ripped
03 [19370e1a] (05/20) Accurately ripped
04 [3d4af5ac] (05/20) Accurately ripped
05 [1717a93e] (05/20) Accurately ripped
06 [9fd98b1a] (05/20) Accurately ripped
07 [7ea63d23] (05/20) Accurately ripped
08 [34e71f9e] (05/19) Accurately ripped
09 [e7d15efc] (05/19) Accurately ripped
10 [8617c67c] (05/19) Accurately ripped
11 [cc5ca7ad] (05/19) Accurately ripped
12 [bfbb825c] (05/18) Accurately ripped
Track Peak [ CRC32 ] [W/O NULL]
-- 99.9 [93E383FB] [509950B9]
01 67.9 [50309B21] [2B7BBC3D]
02 56.1 [B7CDCC85] [9DE5FF45]
03 73.0 [5BE6D2A3] [FD5EDBDC]
04 77.1 [8DE060E8] [699B3D32]
05 81.1 [3EAF01C1] [32B2B370]
06 88.5 [29B95190] [C7F037B5]
07 72.1 [C93793AA] [626AED85]
08 65.4 [95A515B0] [310DCED4]
09 99.9 [960ACAFE] [9765AAC5]
10 86.6 [3DEFD43A] [E54FC1A2]
11 80.1 [4E346361] [EF649ECB]
12 77.6 [58B1612A] [38426FA1]
Why would the log still show a difference in 2948 samples when the log in reply #2 doesn't show that? The glitch is no longer audible.
Happy to upload the problematic file in question if anyone else wants to see.
Besides the log statistics it may be more important in what version you hear the glitch or not.
Besides the log statistics it may be more important in what version you hear the glitch or not.
I hear the glitch in the rip before Repair. I do not hear the glitch after Repair. It's a very distinct click.
I'm just curious why the exact same number of samples differ (2948) in before Repair and after Repair when the files are clearly not the same since I can't hear the glitch with the file that was repaired.
I've zoomed far in so you can see where the glitch is and the second image is the file after CueTools Repair:
(https://i.imgur.com/PNMYX9b.png)
(https://i.imgur.com/bbC5s1e.png)
Any chance this would have been my rip, I did rip it with EAC, dbpoweramp and Cueripper all within 2 days using 2 different drives. One with offset of 102 and other offset 103.
CTDB is showing a total of six previous rips now of this variation of the CD starting 22 months ago. One recent EAC and one CUERipper rip of yours included using a (GUE0N) drive plus a third that could be yours from 15 months ago using EAC but a different drive (GT33N). Re-rips using same drive, same software, same result are not uploaded.
dBpoweramp doesn't submit to CTDB and CUERipper doesn't submit to AccurateRip. EAC can submit to both.
Why would the log still show a difference in 2948 samples when the log in reply #2 doesn't show that? The glitch is no longer audible.
The .accurip file generated during repair as in reply #2 shows AccurateRip only (no CTDB results). You need to compare to the one from the top post.
12 | (6/18) Accurately ripped, or (12/18) differs in 2948 samples @02:05:26-02:05:27,02:07:67,02:09:31-02:09:32,02:09:50,02:10:71-02:10:72,02:11:15-02:11:16,02:11:53-02:11:54,02:11:72,02:12:35
after repair
12 | (12/18) Accurately ripped, or (6/18) differs in 2948 samples @02:05:26-02:05:27,02:07:67,02:09:31-02:09:32,02:09:50,02:10:71-02:10:72,02:11:15-02:11:16,02:11:53-02:11:54,02:11:72,02:12:35
Notice the reversal. The original rip matched
(6/18) but differs with
(12/18). After the repair matched
(12/18) but differs with
(6/18).
The
(6/18) results are from the rip where you hear a glitch. At least 2 of the 6 are from your rips. A recovery record exists for this variation as well so you could 'repair' back to what you had before.
Happy to upload the problematic file in question if anyone else wants to see.
If you do upload a sample for someone - no longer than necessary and under 30 seconds - per TOS#9 (https://hydrogenaud.io/index.php/topic,3974.0.html).
Thank you very much korth, this has been educational. 15 months ago would coincide roughly when I bought this disc according to my emails, I probably did not notice the glitch when listening on speakers. I will have to check if one of my older laptops had a GT33N drive.
I suppose one of the things that was causing me some confusion is that CTDB and AccurateRip use similar nomenclature in "accurately ripped".
There is no need for me to upload the sample as your post clears it all up.
Is there a way to compare the "Repair"-ed files against what is in the AccurateRip database?
?
See .accurip in Reply #2 (https://hydrogenaud.io/index.php/topic,116955.msg965386.html#msg965386) and Reply #4 (https://hydrogenaud.io/index.php/topic,116955.msg965406.html#msg965406) under
[AccurateRip ID: 001c3f5d-010e519d-9b0fa00c] found.
http://cue.tools/wiki/CUETools_log