What is a the difference between process of "rip audio CD using EAC" and "save audio CD tracks to RAW file?

If you "rip audio CD using EAC" you will get .WAV and if you "save audio CD tracks to RAW file" you will get headerless .RAW

I know, but almost people say EAC can get more exact copy of audio. Is audio cd same as data cd? Get more exact copy mean the audio data may different from source cd, isn't it? Why?

From the EAC FAQ:
http://www.exactaudiocopy.de/eac11.html

quote:

Q: Why should I use EAC, instead of AudioGrabber, WinDAC, etc.

A: EAC features some special read modes, known as "Secure Modes". Using these secure modes, every sector read will be doublechecked and reread or corrected if necessary. On many drives the extraction is not error free, thus these routines will make sure the track is read correctly.

Q: Audio extraction is purely digital, how could unremarked errors occur?

A: The data transmission itself is purely digital and also the data stored on the CD. But the Red Book standard (standard for audio CDs) is very weak and only little error correction will be performed in the drive. So on bad CD-ROM drives it is possible that you receive erroneous results

Whether you hear any difference you can check out for yourself. But, when I rip a track three times with eac and three times with two other grabbers, I end up with seven different checksums/hashes/md5. Where the three md5's of the eac-rips are equal.
So what's 'exact' ?
And when I calculate the hash/md5 directly from the cdtrack, it's again another one.

/c

It looks like you just answered your own question. EAC is, the other two "grabbers" are not.



Different CRC calculating algorythms at work, that's all. Just because EAC's read CRCs and those produced by AccurateRip or QuickSFV's will not match doesn't mean the track was not ripped perfectly. Now if EAC's read CRCs don't match test CRCs, then you have a cause for alarm.

[quote=Never_Again,Aug 13 2004, 09:59 AM]
So what's 'exact' ? [/quote]

It looks like you just answered your own question. EAC is, the other two "grabbers" are not.

[quote]And when I calculate the hash/md5 directly from the cdtrack, it's again another one. [/quote]

Different CRC calculating algorythms at work, that's all.
Just because EAC's read CRCs and those produced by AccurateRip or QuickSFV's will not match doesn't mean the track was not ripped perfectly. Now if EAC's read CRCs don't match test CRCs, then you have a cause for alarm.
[/quote]

First of all I use EAC and I use one md5 program to calculate all the checksums
So no different algorithms.

I don't bother really about the possible 'inexactness' of the EAC rips since the only true source is the cd and everything else depends on all equipment used playing the cd. And your hearing and the acoustics.

Of all options EAC is the best one I think, since it's consequent in its rips
I just noticed the differences in checksums between the rips and the original track.

/c

I am not entirely sure what method you use to calculate the checksum of the original CD files. Maybe you could elaborate a bit more on how you calculate them.

Most likely the difference you experience is due to the wav headers on the ripped files. A cd only consists of raw audio data. A .wav file has an additional header and so on.

In case you want accurate testing weather your original cd is the same as the ripped version you should use EAC's wave compare function.

When I look at the wav on an audio cd I can see the riff/wav header.
I calculate the md5 with md5sum.exe the same as I would when the file was on a hdd partition.
For instance md5sum.exe -bv Z:\stereo\16bit\44100Hz\track01.wav >> track01.crc
Where Z: is the cdrom drive

About comparing the waves, yes, I shall give EAC wavecompare a try and let you know.

* Mind you I didn`t start this topic and EAC is sufficient for me.

/c

This is unusual. Do you have an alternative cdfs.sys driver installed?
Usually all you (should) see are *.cda files in Z's root directory.

I know it`s (sadly) unusual. Yes, I have an alternative cdfs and it works great.
In win98 that is..
I am very happy with the options it provides. Like playing mono or stereo, in 8 or 16 bits, and the choice of three different samplerates.
But I know cd's are 16/44100 and rip them accordingly.

Did a wave compare and the only difference is the offset value of my drive, being 661 samples. Either way the difference is 661 samples for the one or the other.
When I use +661 offset or -661 samples. I thought the difference on wave compare would be zero, because I set the offfset at +661 in EAC.

Can someone explain this, although it's not the topic.

/c

The alternative cdfs.sys does not use offset correction. To get identical results (if no error occurs) you will have to set an offset of 0 in EAC.

Thanks, I'll do that, and the waves will be identical. I hope.

/c

No errors found with wave compare. And the md5 hashes are identical, so my problem is solved for the moment and EAC is even better -more exact- than I thought it was.

Thanks
/c