dBpoweramp, EAC and CD-DAs with datatracks

[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:
*blooper* 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.

PS: I forgot to write, that if Accurate-Ripe has the CD, then both EACs and dBpoweramps results are identified as accurately ripped, although the files actually differ.

[LtData]

I'm not sure about your question, but regarding the AccurateRip comment, do dMC and EAC have the same checksum in the AccurateRip result? Do they have the same confidence number?

[Spoon]

>the last track has a sector misalignment (mostly, but not always, 2232 bytes).

When ripping a cd you rip in frames, so it should be not possible to get a rip that is not aligned on 2352 bytes, or exactly dividable by 2352 (even with offsets).

[calestyo]

Originally Posted by LtData

I'm not sure about your question, but regarding the AccurateRip comment, do dMC and EAC have the same checksum in the AccurateRip result? Do they have the same confidence number?

Yes checksums were the same. Confidence numbers in some cases yes and in some not (as my own results from the previous rips has been possibliy included in the AR-db in the meantime).

[calestyo]

Originally Posted by Spoon

>the last track has a sector misalignment (mostly, but not always, 2232 bytes).

When ripping a cd you rip in frames, so it should be not possible to get a rip that is not aligned on 2352 bytes, or exactly dividable by 2352 (even with offsets).

So you'll probably say with this that the answer to question 4 is that dbPoweramp is correct, right?
No ideas about the other questions?

Chris.

[Spoon]

Yes, I have no idea why eac is not working as should.

[calestyo]

Hi,...
Just wanted to inform you that this is probably an error in EAC (which is going to be fixed soon). So dbp is very likely right in this issue.

Best wishes,
Chris