Hello all, I have been using CUERipper and CUETools to slowly archive my CD collection. I have come across one CD that I think has some damaged tracks and I don't know if I understand what CUETools is telling me: Ripping with CUERipper gave me the message that the rip was not accurate but could be repaired with CUETools. I tried twice to be sure. Using CUETools I was able to select a repair option with a confidence of 832. After the repair I attempted to verify the rip. Here is the result: It seems like track 9 still has problems, but the track says it's accurately ripped. Do I need to do anything - can I do anything about it? Or is this indicating everything is fine.
According to the CUETools database your rip of track 9 differs a whopping 8 samples at 2:03 with 832 rips by others. This should be completely inaudible. But the question is why it didn't get repaired to (832/981) Accurately ripped. What did the log file look like before the 'repair'? Have you checked the disc for dirt or scratches under a bright light. My first step would be to rip the disc with a different drive. That's why I have two installed in my computer. If the CRC values of track 9 stay the same you might have a unique pressing.
It is most likely that this particular disc was ripped twice and is now verifying against itself. I would try alternate reading modes or other optical drives to see if you continue getting the same result. Otherwise I would correct the rip to the most probable CTDB match. It’s unlikely that your disc matches 900+ others for all tracks except the last. 8 samples may be inaudible or inconsequential but I firmly believe in getting these things done correctly.
Well, this is embarrassing, but I figured out why I wasn't seeing the repair. I had the destination folder setting for CUETools set differently from CUERipper, so I kept going back to and verifying the original flawed rip. The report I posted was the original. Oops. The accurip report for the repair looks better: And yes, the disc is old and definitely scratched - apparently on track 9. Bizarrely, I listened to both the original and the repaired track, and I can barely hear a difference. It must be something not audible on my speakers or just very subtle. Thanks for the help anyway!
The process for fixing a bad rip using CUETools is confusing. It is a process that I am sure makes sense to the developer. But it's a process that is going to be confusing for anyone who doesn't think through the same flowchart as the developer. I'm a software developer. I know how to think through things like this and think through what the software is likely doing. And I still have problems fixing a bad rip using CUETools. I'll try to fix a bad rip and end up doing it wrong the first time before figuring out how to do it right. Then the next time I try fixing a bad rip I'll make a similar mistake the first time and have to figure out how to do it correctly all over again. Part of the problem is the UI for CUETools. The UI (user interface) doesn't help guide you to doing the repair corrections the right way. The UI allows you to do it incorrectly with a combination of options that could never be right. I complain about the UI and how it's confusing. But the feature to fix a bad rip using CUETools is amazing. I love that feature. I just wish the UI didn't allow me to make mistakes every time I need to use that feature. A few bad samples can very easily not be audible. It depends on the music and what values those bad samples have. If it is quiet music, like classical, and the bad samples jump to near full scale then you'll hear a tick or pop at that spot in the recording. As an audiophile, I don't want to hear a tick or pop that isn't in the original mastering. If I hear a tick or pop while listening my reaction is to go back and listen to that part again and try to figure out what happened and what is wrong. If that tick or pop is because of a bad rip that just wastes my time. So I make sure that every track in my library is properly ripped and verified using AccurateRip and/or CTDB.
