Skip to main content
Topic: Repairing audible glitch with CueTools (Read 437 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Repairing audible glitch with CueTools

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?



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:

Code: [Select]
[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]          

Re: Repairing audible glitch with CueTools

Reply #1
Change the pulldown menu on the right from default to repair.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Repairing audible glitch with CueTools

Reply #2
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?

Code: [Select]
[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]          


Re: Repairing audible glitch with CueTools

Reply #3
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.
korth

Re: Repairing audible glitch with CueTools

Reply #4
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.

Code: [Select]
[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.

Re: Repairing audible glitch with CueTools

Reply #5
Besides the log statistics it may be more important in what version you hear the glitch or not.
Is troll-adiposity coming from feederism?
With 24bit music you can listen to silence much louder!

Re: Repairing audible glitch with CueTools

Reply #6
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:




Re: Repairing audible glitch with CueTools

Reply #7
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.

Quote
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.
Quote
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
Quote
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.



Quote
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.
korth

Re: Repairing audible glitch with CueTools

Reply #8
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.

 

Re: Repairing audible glitch with CueTools

Reply #9
Is there a way to compare the "Repair"-ed files against what is in the AccurateRip database?


 
SimplePortal 1.0.0 RC1 © 2008-2019