calestyo

Hi.

First of all I'm posting this to both, dbPoweramp and EAC forums, so that both people will read it and might help.

I'm currently archiving all my audio CDs, with about the following procedure:
1) rip with EAC as image.
2) rip with EAC as tracks (via test & copy).
3) rip via dBPoweramp (r12 reference) (as tracks)
4) diff EACs tracks with dbPoweramps tracks (they might differ as dbPoweramp cannot rip track 1 pregap audio, but then I split EACs track 1 and diff that)
4) diff EACs tracks with EACs image version

All files should be equal except for "hidden track one audio" (that is track 1 pregap)...

But that's not always the case:

One problem are some copy-protected CDs (but I will discuss this in a sperate thread) but in general it is similar to this:
Many non-copy-protected CD-DAs have an additional data-track (mostly the last track in a 2nd session).
The following difference happens between EACs and dbPoweramps wav-files (but only and always when there is a data-track!!):
EAC: Image and Track-files are equal, but (always) the last track has a sector misalignment (mostly, but not always, 2232 bytes).
This is one example output from the shninfo-tool:
# shninfo image.wav
-------------------------------------------------------------------------------
file name: image.wav
handled by: wav format module
length: 68:36.25
WAVE format: 0x0001 (Microsoft PCM)
channels: 2
bits/sample: 16
samples/sec: 44100
average bytes/sec: 176400
rate (calculated): 176400
block align: 4
header size: 44 bytes
data size: 726121080 bytes
chunk size: 726121116 bytes
total size (chunk size + 8): 726121124 bytes
actual file size: 726121124
file is compressed: no
compression ratio: 1.0000
CD-quality properties:
CD quality: yes
cut on sector boundary: no
sector misalignment: 2232 bytes
long enough to be burned: yes
WAVE properties:
non-canonical header: no
extra RIFF chunks: no
Possible problems:
file contains ID3v2 tag: no
data chunk block-aligned: yes
inconsistent header: no
file probably truncated: no
junk appended to file: no
odd data size has pad byte: n/a

dBPoweramp: For the same CD (with data-tracks): dBpoweramp as no sector-misalignment.

My questions:
1) Why does this happen (the sector misalignment)?
2) Will it happen for all CD-DAs with data tracks?
3) Will it happen only for CD-DAs with data tracks?
4) Which of the two versions is correct? The one with sector misalignment (EAC) or the one without (dbPoweramp)?
5) What does the sector misalignment "contain"? Is it digital silence (added by dBpoweramp to automatically align to the sector size) or does EAC miss some audio data?

Best wishes,
Chris.

Andre Wiethoff

5) Yes, it will be silent... Do you have "Fill up missing offset bytes with silence" activated ("Overread into lead-out" does not matter)?
4) Both, due to the offset correction (2352 - 2232 = 120 bytes = 30 samples offset)
2)3) With the current settings, yes for all
1) Offset correction

cu, Andre

calestyo

"Fill up missing offset bytes with silence" is not activated.
"Overread into lead-out" is activated and the drive should be capable of it (Plextor PX-760).

Well that would be exactly my read offset,.. but both programs should do offset correction.


Hmm thanks, but I'm still not sure which of the versions I should take.
As both programs correct the offset they should both result in the same data.
And note, that the 120 bytes that dBpoweramp has more are not 0x0's.
Even if I convert both (EAC's and dBpoweramp's) wav files to raw PCM streams (and thus) remove wav stuff,... the data which dBpoweramp has more is not 0x0's (but it's then less than 120 bytes).

Best wishes,
Chris.

calestyo

Ah and one more question: Why if this was an read-offset related problem does it only occur on CDDAs with data track but not "normal" CDDAs?

Andre Wiethoff

Use "Fill up missing offset"...
This probably happens to data CDs, as EAC has to "guess" where the lead-out starts. This is no problem on audio-only CDs.
Please use EACs Compare WAV function between dbPowerAmps and EACs extracted files and post the results.

cu, Andre

calestyo

ok,.. I'm working on it now,.. will take some time as i have about 15? discs or so.
btw: is it ok for you if I'd give you a diff between the hexadecimal views.
Don't have Windows currently here (and thus no EAC) :/

Chris

calestyo

Ah and I forgot,.. would you like to have diffs between the WAV files or the raw PCM files?

Andre Wiethoff

As only some bytes in the header (filelen and data len) will be different, it doesn't matter for me.
But if there is an offset introduced somehow, you will not be able to see it in the diff file (or will it find the offset automatically in a binary file?)
Otherwise best use EAC for this.
Also, just use the data from the one CD which is different (the other are also interesting, but for the start just use the data you already have)...

cu, Andre

calestyo

So here are the diffs...
The red marked text is the that what the dBpoweramp (dbp) version has, but eac's version hasn't.
So it's always the dbp version who is aligned to multiples of 2352 bytes and always eac who is not.
eac's files are always shorter. It's always CDDA's with data tracks.
The differences are always at the end of the file (where dbp's files are longer). Of course there are some differences at the beginning of each couple of files, but these are WAVE header parts.

Hope that helps. Ask me if you need anything else.

Harry Potter 3:
07AE 6000: 00 00 FF FF 00 00 01 00 00 00 FE FF 00 00 01 00 ........ ........
07AE 6010: 00 00 FF FF 00 00 00 00 00 00 00 00 FF FF FF FF ........ ........
07AE 6020: 00 00 01 00 00 00 FE FF 00 00 01 00 00 00 FE FF ........ ........
07AE 6030: 00 00 01 00 FF FF FF FF 01 00 00 00 FE FF 00 00 ........ ........
07AE 6040: 01 00 00 00 FF FF 00 00 00 00 00 00 00 00 00 00 ........ ........
07AE 6050: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
07AE 6060: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
07AE 6070: 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....

Lord of the Rings 1:
02B5 CC70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02B5 CC80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02B5 CC90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02B5 CCA0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02B5 CCB0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02B5 CCC0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02B5 CCD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02B5 CCE0: 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....

Lord of the Rings 2:
02E9 0C30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02E9 0C40: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02E9 0C50: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02E9 0C60: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02E9 0C70: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02E9 0C80: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02E9 0C90: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
02E9 0CA0: 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....

Lord of the Rings 3:
03A7 9DD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
03A7 9DE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
03A7 9DF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
03A7 9E00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
03A7 9E10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
03A7 9E20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
03A7 9E30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
03A7 9E40: 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....

X-Men 2:
That one is unreliable, as there seem to be some severe copy protection problems. Sometimes the CD shows a data track sometimes not, sometimes it even shows to datatracks... etc. I'll probably start a new thread for that issue in the near future.

Star Trek First Contact:
017C 86C0: FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF ........ ........
017C 86D0: FE FF FE FF FE FF FE FF FE FF FE FF FE FF FE FF ........ ........
017C 86E0: FE FF FE FF 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
017C 86F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
017C 8700: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
017C 8710: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
017C 8720: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
017C 8730: 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....

Spiderman 1:
0134 B690: FE FF FE FF 00 00 00 00 FF FF FF FF 00 00 00 00 ........ ........
0134 B6A0: 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00 ........ ........
0134 B6B0: 00 00 00 00 00 00 00 00 FF FF FF FF 00 00 00 00 ........ ........
0134 B6C0: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0134 B6D0: FF FF FF FF 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0134 B6E0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0134 B6F0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
0134 B700: 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....

Star Wars 2:
This one probably has the same copy protection issues thatn X-Men 2, anyway:
01F8 97F0: 00 00 00 00 FF FF FF FF 00 00 00 00 00 00 00 00 ........ ........
01F8 9800: FE FF FE FF 00 00 00 00 FF FF FF FF 00 00 00 00 ........ ........
01F8 9810: 00 00 00 00 FF FF FF FF 00 00 00 00 FE FF FE FF ........ ........
01F8 9820: 01 00 01 00 FD FF FD FF 01 00 01 00 FF FF FF FF ........ ........
01F8 9830: FF FF FF FF 00 00 00 00 FF FF FF FF 00 00 00 00 ........ ........
01F8 9840: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
01F8 9850: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
01F8 9860: 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....

Star Trek Enterprise:
00EC CAD0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00EC CAE0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00EC CAF0: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00EC CB00: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00EC CB10: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00EC CB20: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00EC CB30: 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........
00EC CB40: 00 00 00 00 00 00 00 00 00 00 00 00 ........ ....

Best wishes,
Chris.

Andre Wiethoff

I think I found the problem(?), it is part where EAC decided which blocktype a specific sector has. If the last sector is audio, all further is also audio. If the last track is a data track, from there on all are data. Overreading is (should be) only possible to audio tracks. But of course the lead-out usually is always audio...
I will fix this, can you please test the new version (a closed beta will be out soon - I will announce it in the forum, just send an email then)?
Thanks!

cu, Andre

calestyo

Of course I'll test it. You can send me the beta if you like (and if it should remain closed. (I wrote you an PM for my eMail).

Best wishes,
Chris.