Using CUE sheet from EAC with files ripped by dBpowerAMP?

[Rollo]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

What program did you use to burn the CD and to rip the single wav images, was it EAC v0.95 Beta4?

Yes

[fjodor]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

Ripped with both EAC and dBpa, all individual tracks matched when doing a wav compare in EAC.

That was also the case for me with Depeche Mode's Violator album.

When I burned a copy from these individual tracks with a non-compliant cue, and made a single wav rip from both the copy and the original, they again matched.

What program did you use to burn the CD and to rip the single wav images, was it EAC v0.95 Beta4?

[Rollo]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

So, if I have this correct, in some instances:

track based rip from original + cue > burned cd > image rip
did not match
original cd > image rip

Yes.

I found an original disc with a non-standard pre-gap.
Ripped with both EAC and dBpa, all individual tracks matched when doing a wav compare in EAC.

When I burned a copy from these individual tracks with a non-compliant cue, and made a single wav rip from both the copy and the original, they again matched.

This does certainly does not seem to be a dBpoweramp issue, since both sets of individual track files, those made with EAC and dBpa, matched.

[fjodor]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

While WAV doesn't support comprehensive metadata, it isn't a pure PCM stream format: there's a header and the RIFF chunks don't have to have the exact same content or placement in order to store the exact same digital audio content.

True, so therefore MD5 is not the ideal way of comarying two WAVs. Still, if MD5 says there's a match between two WAV files you know that the audio data matches (as well as the headers and RIFF chunks format). However, if MD5 says there isn't a match that does not say anything about whether the actual audio data matches or not (it could just as well be the headers or RIFF chunk format that mismatches). Altough I guess as long as you use the same program to create the WAVs, the same header and RIFF chunk format will probably be used, and in that case it ought to be safe to use MD5. Still, why do that when there are better alternatives...

The recommended method to compare the data is to use a tool built into foobar2000 that allows you to perform a byte-by-byte compare of just the audio portion of the file.

Ok, I did this using foobar2000 v0.9.4.2 as well now. The result was:

Comparing:
"C:\mp3\eac_extract\Depeche Mode - Violator_copy.wav"
"C:\mp3\eac_extract\Depeche Mode - Violator_orig.wav"
differences found: 1180581 sample(s), starting at 140.5597279 second(s), peak: 0.9226379 at 144.7635147 second(s), 2ch

Notice that the position of the first mismatch is the same as what EAC reported (EAC said it was at 2 minutes 20.559 seconds = 140.559 seconds).

BTW: Is there anyone that can reproduce the behaviour I get? No other Depeche Mode fans out there?

[bhoar]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

One additional datapoint -

While WAV doesn't support comprehensive metadata, it isn't a pure PCM stream format: there's a header and the RIFF chunks don't have to have the exact same content or placement in order to store the exact same digital audio content.

I read on HA recently that using file-based checksum/hash tools isn't reliable in this case, as different tools will output the same PCM data into a WAV file using slightly different header and/or RIFF chunks. The recommended method to compare the data is to use a tool built into foobar2000 that allows you to perform a byte-by-byte compare of just the audio portion of the file.

-brendan

[fjodor]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

I ran "md5sums.exe" on the image .wav file ripped from the original and the copy, respectively; and the resulting two MD5 checksums differed, which indicates that the content is not identical. See below:

Depeche Mode - Violator_copy.wav 100% 2db0fff766d84630476a9f708c133de9
Depeche Mode - Violator_orig.wav 100% c9130f7276adf0e5d4e3c5742b7d58cb

I now also compared the .wav files in EAC as you suggested, and got the following result:

Error type: Position:

150 repeated samples 0:02:20.559
150 missing samples 0:02:27.253
390 repeated samples 0:23:45.679
390 missing samples 0:23:52.373

Any idea what could be wrong? Also, are you able to reproduce the behaviour I get?

[Rollo]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

EAC then reported "Error type: position" for all individual file comparisons between the ".wav" files ripped from the original and and the ".wav" files ripped from the copy. However, I'm not sure how to interpret this, since I got the same "error report" when I compared a ".wav" file to itself!

Error type and position are the column headers. If there nothing below that in the larger box, the files are identical. If it was an offset error, it would say "repeated samples" under error type and a numerical value under the position. Which file contained the error would determine which side of the box, left or right, the error are reported. This is the 'old' manual way of determining whether you have the write offset configured correctly.

Bottom line: The files are identical. I cannot explain why the image rips seem to be different, but run those through the 'compare wavs' tool in EAC as well. How exactly did you determine that they were different?

[fjodor]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

<...>
PREGAP 00:00:32
INDEX 01 00:00:00

The pregap statement means its longer than the normal 2 seconds by [I think] 32/100ths of a second.

The CUE-sheet looks like this:

<...>
FILE "01 - World In My Eyes.wav" WAVE
TRACK 01 AUDIO
TITLE "World In My Eyes"
PERFORMER "Depeche Mode"
PREGAP 00:00:33
INDEX 01 00:00:00
FILE "02 - Sweetest Perfection.wav" WAVE
<...>

Also, regarding the format of the timestamp I checked it out at http://en.wikipedia.org/wiki/Cue_sheet , and it's in specified in "MM:SS:FR (minute-second-frame)" format, where frame is 1/75 second. So in this case, it appears that the PREGAP is 33*1/75=0.44 seconds.

Yes. But not only compare the first track, compare the rest as well. I am guessing the 1st one will not match because it is 32/100th of a second longer, but that the rest will.

Ok, I did this (using "Tools->Compare WAVs..." in EAC) and EAC then reported "Error type: position" for all individual file comparisons between the ".wav" files ripped from the original and and the ".wav" files ripped from the copy. However, I'm not sure how to interpret this, since I got the same "error report" when I compared a ".wav" file to itself! Also, when I did an MD5 checksum (see http://www.pc-tools.net/win32/md5sums/ ) on the ".wav" files ripped from the original and the compared that to the ".wav" files ripped from the copy, it indicated that the contents of the files were identical.

It could also be that your read and write offsets are not configured correctly in EAC, but it sounds like you know what you are doing.

This part I have configured correctly, which is also verified by the fact that when performing an "a) image based rip > b) image based write > c) image based rip " using EAC the images in step a) and c) are identical as verified by their MD5 checksums.

[Rollo]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

Is there any easy way to determine if this is the case? Can I for example look in the generated CUE-sheet?

Yes. The first track in the cue sheet will look like this:
FILE "01 - Military Madness.wav" WAVE
TRACK 01 AUDIO
TITLE "Military Madness"
PERFORMER "Graham Nash"
PREGAP 00:00:32
INDEX 01 00:00:00

The pregap statement means its longer than the normal 2 seconds by [I think] 32/100ths of a second.

What should I compare the tracks ripped from the copy with? Should I compare them to the tracks ripped from the original CD?

Yes. But not only compare the first track, compare the rest as well. I am guessing the 1st one will not match because it is 32/100th of a second longer, but that the rest will.

The bottom line is that you have NEARLY a 1:1 copy of the original and the musical content is identical. It could also be that your read and write offsets are not configured correctly in EAC, but it sounds like you know what you are doing.

[fjodor]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

So, if I have this correct, in some instances:

track based rip from original + cue > burned cd > image rip
did not match
original cd > image rip

Yes.

but using the same original disc

image based rip from original + cue > burned cd > image rip
matched
image based rip from original

Yes.

This is a wild, but somewhat informed guess. dBpa does not support pre-gaps of track 1. It could be the non-conforming discs had pre-gaps longer than the standard 2 second variety.

Is there any easy way to determine if this is the case? Can I for example look in the generated CUE-sheet?

Try this. Rip the copy track based. Compare each individual track using EAC's compare wav function.

What should I compare the tracks ripped from the copy with? Should I compare them to the tracks ripped from the original CD?

I am suggesting that only the 1st track does not match. Just remember two things. If you are using EAC, set to "append gaps to previous track" under the action menu [this is also how dBpa performs], and the EAC cue sheet must be non-compliant.

Yepp, those are the settings I'm using.

[Rollo]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

So, if I have this correct, in some instances:

track based rip from original + cue > burned cd > image rip
did not match
original cd > image rip

but using the same original disc

image based rip from original + cue > burned cd > image rip
matched
image based rip from original

This is a wild, but somewhat informed guess. dBpa does not support pre-gaps of track 1. It could be the non-conforming discs had pre-gaps longer than the standard 2 second variety.

Try this. Rip the copy track based. Compare each individual track using EAC's compare wav function. I am suggesting that only the 1st track does not match. Just remember two things. If you are using EAC, set to "append gaps to previous track" under the action menu [this is also how dBpa performs], and the EAC cue sheet must be non-compliant.

[fjodor]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

Well, it not that hard. I performed the following steps:

1. I followed the procedure you described to produce a copy of an original CD.
2. After this I tried to rip the CD copy using "Action->Copy image & create CUE sheet->Uncompressed" in EAC. I got a "image.wav" file and a ".cue" file as a result.
3. I repeated step 2 with the original CD.
4. I compared the contents of the "image.wav" file from step 2 with the one from step 3, and noticed that they differed for some CDs but matched for other CDs.

As an example, one CD where I in step 4 noticed a mismatch between the copy and the original was "Viloator" by Depeche Mode (CDDB Disc ID: 8A0B0809).

I hope this made it somewhat clearer, otherwise please specify which part of my previous post I should clarify.

[Rollo]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

I'm having trouble following your exact procedure.

[fjodor]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

Thanks for the response Rollo.

I investigated this a bit further, and re-tried the track based ripping procedure by following the steps you described. It turned out that everything worked ok for some CDs but not for other CDs. When I say that it didn't "work" for some CDs, I mean that when I afterwards did an "image rip" using EAC from both the original CD and the CD copy the contents of the two resulting "image.wav" files differed. I thought this was strange, so I tried doing all steps of the track based ripping and burning procedure completely in EAC instead, but I got the same result (i.e. for some CDs this worked ok, but for other CDs it didn't work ok)!.

Finally, to see if the problem was related to the "track based ripping with CUE-sheet procedure" I tried the following for the CDs that didn't "work": Using EAC I did a complete "image rip" instead followed by an "image write". Afterwards I did an "image rip" of the CD copy and compared it with the "image rip" of the original, and then they matched!

So to sum it up, it seems like for some CDs you cannot restore an exact copy of the original CD if you've done a "track based rip with CUE-sheet". This problem exists no matter if you use EAC of dBpowerAMP. If this is the case I think it sux, since:

1. If I choose an "image based rip with CUE-sheet", I cannot add all the metadata for the individual tracks that I want my ".flac" files to contain. Also, I cannot easily make compilations of move individual tracks to other devices.

2. If I choose a "track based rip with CUE-sheet", I cannot restore the original CD in some cases (due to issues described above).

Is there any solution to this problem? Otherwise, what ripping stategy do you guys use, i.e. what is the least bad solution... ?

[Rollo]

Re: Using CUE sheet from EAC with files ripped by dBpowerAMP?

@ fjodor: 1st use EAC to make a non-compliant cue. Then, before ripping with dBpa CD Ripper, get the track names from cdplayer.ini [Metatdata > retrieve from > CDPlayer.ini] to assure the file names are the same as those referenced from the EAC cue file.

I have tested and this procedure works flawlessly. You will need to burn the CD with EAC, BuRRRn or other software that supports non-compliant cue files. NOT Nero, for example.

@ Wayne: Providing you have your drive read and write offsets correctly configured in EAC, the files obtained by dBpa CD-Ripper will be identical to those obtained using EAC.