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 rips cannot be verified as accurate after burning and ripping again (Read 3646 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

EAC rips cannot be verified as accurate after burning and ripping again

Hi,

Currently I am ripping my CDs with EAC. I have a problem and don't know what I'm doing wrong.

When I rip the original CD everything is fine. Always I have good results:
"All tracks accurately ripped
No errors occurred"

I'm ripping with the often recommended procedure:
1. Collect metadatas and correct them if necessary
2. Detect Gaps (F4)
3. Remove Unwanted Spaces
4. Create a CUE-Sheet with the option "Multiple WAV Files With Gaps... (Noncompliant)
5. Start ripping with "Test & Copy selected Tracks, Compressed" (Shift+F6)

So I'm sure that the ripped tracks are ok. Now I burned CDs and when I rip the burned CDs with EAC again, no tracks could be verified as accurate. I also get the message "You may have a different pressing from the one(s) in the database". The tracks self are ok, they have all a quality of 100.0 %, e.g.:

Code: [Select]
     Peak level 63.0 %
     Extraction speed 5.7 X
     Track quality 100.0 %
     Test CRC 0B8CEC79
     Copy CRC 0B8CEC79
     Cannot be verified as accurate (confidence 5)  [87BFF1B8], AccurateRip returned [C4D56D30]  (AR v2)
     Copy OK

I burned the CDs with Burrrn:
- All settings default.
- Before opening the CUE-Sheet in Burrrn I replaced the .wav-endings with .flac-endings

What do I wrong? The goal is to get burned CDs which are recognized as accurate rips from EAC. Or is this not possible?

Thanks in advance and regards!

Re: EAC rips cannot be verified as accurate after burning and ripping again

Reply #1 –
'write offset' correction needed.
korth

Re: EAC rips cannot be verified as accurate after burning and ripping again

Reply #2 –
Thanks, that makes sense.

I tried it, but my problem is not solved. My drive has an offset of +6. So I created with CUETools an Image (and CUE) with an offset of -6 (I thougt: +6-(-6)=0). After burning and ripping: "no tracks could be verified as accurate". After that I tried an offset of +6, same again: "no tracks could be verified as accurate".

Is this what I tried correct or wrong?

Re: EAC rips cannot be verified as accurate after burning and ripping again

Reply #3 –
What differences does CUETools show when you Verify the original CD rip and the rip from the uncorrected burned copy (post both CUETools logs if unsure, preferably from a CD with a single pressing in the AccurateRip section)?
korth
 

Re: EAC rips cannot be verified as accurate after burning and ripping again

Reply #4 –
Quote from: Hanomoku on
I'm ripping with the often recommended procedure:
...
3. Remove Unwanted Spaces
What exactly are you doing during this step?

Re: EAC rips cannot be verified as accurate after burning and ripping again

Reply #5 –
Quote from: shaboo on
Quote from: Hanomoku on
I'm ripping with the often recommended procedure:
...
3. Remove Unwanted Spaces
What exactly are you doing during this step?
That is an option in EAC (Database -> Transform current CD information). I've read that this should be done... it removes unwanted spaces at the beginning or end of titel, artist, composer, etc.

Quote from: korth on
What differences does CUETools show when you Verify the original CD rip and the rip from the uncorrected burned copy (post both CUETools logs if unsure, preferably from a CD with a single pressing in the AccurateRip section)?

My problem is solved, it was my mistake. I've entered my desired offset AND used the "fix offset"-script of CUETools. I misunderstood that: the fix-offset-script removes offests (to zero offset), so my offset was not considered.. The input file (with zero offset) was identically to the output file.
Without the fix-offset-script the given offset is considered. After burning and ripping again, the log-files of EAC and CUETools are identically.

Thanks for your support!