Skip to main content ↑ ↓

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: EAC and Cuetools disagree...for just one track? (Read 2293 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC and Cuetools disagree...for just one track?

I have recently been using CueTools 2.1.6 to verify old rips on my computer. I've run into an issue that I've never seen before, and I am hoping perhaps somebody here can explain. The EAC log reported no errors at the time, and the AR plug-in was able to verify all of the tracks except Track 1. Yesterday, when I used CueTools to verify the rip, I was greeted with a message saying that Track 1 differs by 12 samples. I've certainly run into the issue where none of the tracks can be verified as accurate (which usually means the CD is a different pressing from the one on the AR database), but I've never run into the issue where only a single track does not match. Any ideas?

Re: EAC and Cuetools disagree...for just one track?

Reply #1 –
disagree?
Quote
EAC log
Track  1

     Filename C:\Music\Beck - Mutations\01 - Cold Brains.wav

     Pre-gap length  0:00:02.00

     Peak level 99.9 %
     Track quality 100.0 %
     Test CRC C00205CD
     Copy CRC C00205CD
     Cannot be verified as accurate (confidence 36)  [878C7C90], AccurateRip returned [A4507D4C]
     Copy OK
Quote
CUETools (accurip) log
[AccurateRip ID: 0011a13c-0099c5a8-8f0b8d0b] found.
Track   [  CRC   |   V2   ] Status
 01     [878c7c90|4f354e6d] (000+000/516) No match
 02     [40e9023e|54e2a4af] (037+037/521) Accurately ripped

Track Peak [ CRC32  ] [W/O NULL] [  LOG   ]
 --   99.9 [796EFEAE] [6EB8F6BF]          
 01   99.9 [C00205CD] [E1436DB1]   CRC32 
 02   99.9 [01FC10C2] [C717654F]   CRC32  
That's the same. No Match for Track 1 {ARv1} in AccurateRip DB for your rip. Copy CRC matches the file.

Quote
CUETools (accurip) log
[CTDB TOCID: 2DYHA5XGlQact4Fbr0NHKZmWBTA-] found.
Track | CTDB Status
  1   | (325/340) Differs in 12 samples @03:05:62 {same as No match but might be repairable if you know your rip had errors}
  2   | (338/340) Accurately ripped
No Match for Track 1 in CTDB

All you know from the EAC log Test & Copy CRC is that the same data was read multiple times.
Another thread to look at
https://hydrogenaud.io/index.php/topic,110979.msg914271.html#msg914271
korth

Re: EAC and Cuetools disagree...for just one track?

Reply #2 –
Thank you korth. Your analysis was very enlightening. One further question: do you think this implies that the track has an error?

Re: EAC and Cuetools disagree...for just one track?

Reply #3 –
Quote from: Mike457 on
do you think this implies that the track has an error?
You can be fairly sure that if if you (backup the track first and) try to repair and get something that verifies nicely, then your repaired version is what they have sold to others.

If so, then that is what most likely what you want to have.

Then for the nitpickery: It cannot be ruled out that you have a correct rip from what is actually on some (rare, probably not-so-good) pressing of the CD: imagine that a pressing batch has an error, something which happens every now and then. In that case, you may have "a correct rip of an incorrect content". Or sometimes with defective pressings, there is really nothing such as a "correct rip". (They write content, they write a checksum that does not match - obviously something is wrong, but there is no way to tell from that what was right.)