Hi, i hope some of the experts around here can help me and tell me if it was right what i did or if theres any other (better) way to get to my perfect-CDA-copy

I've got this:
a pressed original Audio-CD with just Audio-Tracks (no Data-track, no copy-protection etc.) it is not damaged and has no scratches - it's brandnew

And want to do this:
create a copy of this CD wich is most exact and where nothing gets lost

I did the following:
- start EAC
- Action -> Detect Gaps
- Action -> Copy Image & Create CUE Sheet -> Uncompressed...
after that process was finished and i had a .cue and a .wav-file
- Tools -> Write CDA...
I selected the .cue-file i just created and burned that image with 4x Speed

Have i made an exact copy of my CD? I cant imagine that with creating a .wav-file wich is just all of the tracks in one (and creating a.cue-sheet) i can make a perfect copy. What about Audio-Subchannel-Data etc.? Don't some things of the original CD get lost in that process?

You can skip over the second step (detecting gaps) since EAC does it automatically when creating an image.

If you are really paranoid, you also have to get a real Plextor drive or a device that can overread its offset and also an older LG burner that has a 0 sample write offset. However, since we are talking about a few samples here, which usually are silence anyways, you won't lose anything.

1. So is my copy really exact?

2. What about those Subchannel-Data or is there any other data wich isn't added to the .wav-image which EAC made?

There is very little chance of a single bit of data being mislayed if EAC reports no error with its normal, checked reading methods. Using a correct method, its a vanishingly small chance due to the integrety data stored in the cds format, which will practicaly always highlight any damage to the cd, and most often be well enough to use to reconstruct the damage data with great certainty of total correctness.
Only when attempting to read badly damaged cds, or using poorly performing cd readers does the native error correction capability fail and the ripper program has to retry and start guessing, but EAC will indicate when this happens.

The reason for such certainty is that cd's are a digital medium, there is no subtle hints involved only 1's and 0's. If a single 1 is read that should be a 0, the integrety data also stored dissagrees, and is part of a mathematical system that can cleverly be used to precisley correct. Everything is done precisely, because if a single bit is wrong in a program file, that can well lead to a total crash, and in your computer, trillions of bits are communicated absolutely perfectly every single minute (until it crashes).

Excpetion to the rule, could be the precise length of silences at the start and end of the CD. iirc subchannel data, if it is included, should be mixed in with the rest of the integrety checked data and therefore no more susceptable to error than normal data.

In short, If the CD rips cleanly with EAC in normal mode, it is definitely 100% secure.

hth

Thanks for that explanation.
What about this integrity-data? Is the integrety-data (as i understood it is used for error-correction) and the subchannel-data also copied when i make up a copy with EAC? I think EAC only copies the soundwave (into the .wav-file), so any other information would be lost during the copying-process, right?! (even though there is no data-track on my CD there could be informations like error-correction-things etc. stored who aren't being included in the .wav-image which EAC creates)

The data is the same but the encoding, the form that the data takes, is quite different. When CD audio data is written to wav the data is reformatted to the wav format. When it is rewritten to CD, the date is reformatted to CD format. The error correction information, which is written on the CD, is calculated at that time; it is not part of a wav file.

I've never used the "Copy Image & Create CUE Sheet" approach for audio and have never paid attention to whatever it is that it does. However, making an 'image' file on hard drive of a data disk, as part of the process of copying it, makes a single file containing everything on the CD. It is not in any form that can be utilized directly by Windows (as can a wav file). I believe there are programs that can extract the data from such an image file, but this is some steps way from the CD data having been converted directly to a hard drive format as has apparently been done with your EAC process.

I don't know the cause of your interest or concern so maybe my comments are not relevant. As far as making music with the data, whether it exists on a CD or a hard drive is irrelevant. The same music signal will be created by the playback system. What is it about the process, or the product, that you should care whether or not the distribution and the error correction codes are identical or not if you get the same music out of it?

Then, please refrain from answering



EAC's image files are one big wav (or any codec you might want to use) with a "cue sheet", which is a text file that contains all the track positions and (if you want to) the CD info, such as artist, album and track names.

And therefore my reply is completly valid and on point

So when i burn that EAC-wav-image is there any error-correction and sub-channel data on my copy or does it get complete lost by the EAC-image-creation-process?

New error correction data is calculated by the program. Otherwise it wouldn't be a real CD-Audio. This was already mentioned by AndyH-ha.

Restating, the error detection/correction data can be recreated precisely from the audiodata, and the audiodata can be precisely repaired from the error correction data as long as theres not too much damage to either - the values of each are implied by the values of the other.
So the error correction data, is not normaly retrieved, just utilitised or created on-the-fly by the drive during reading and writing process.
The payload is the audio data, which is ostensibly a stream of bits grouped in 16bit words like the audio data in a wav file. Thats how its meant to be normaly interpreted, but you could write any data into it, like a bitmap or exe, as long as you know how to read it out again. Although Im not aware of any standard way of indicating how the data should be read differently, other than using the 'data' CD format, its still a stream of bits at the end of the day with just different implied way of reading the bits...

Any extra info like subchannel data, included in an Audio CD format, can ony be written into the standard payload space, which the waveform is meant to occupy, so it will be mixed into the waveform. Players aware of the channel, will be able to interpret it, players unaware wont and it will express as a small amount noise during the waveforms normal interpretation. Its possible to encrypt hidden information into a wavfile for example, by multiplying all the normal audio values by 3, and then using the remainder space to store info. Or using limitless more elaborate mathematical mechanisms. If you know whats been done you can extract the info easily, if not it will just be a kind of noise included in the wavform.

But whatever extra implications included in the audio data, its all digitaly stored and checked, so a clean rip means its securely included with the rest.

hth

And EAC is able to store those "extra implications" into the .wav-image it creates when selecting "Copy image and create cue-sheet"?

Sorry, but this isn't correct... When extracting from an audio CD into WAVE file format, then the WAVE file dosen't include any subchannel information, but consists only of the mainchannel data from the CD. When burning the WAVE file back to CD in DAO mode(SAO writing mode + close disc), then the drives firmware regenerates the control,tracking and timming P-Q subchannel information nedded and since a cuesheet is used, then additional subchannel data like INDEX 00 entries, ISRC/Catalog numbers and CD-TEXT can also be regenerated...

is this the error-correction?

And is it also regenerated when i burn the image with EAC's writing-engine without using the CDRDAO-"plugin" which comes with the newer versions? (my drive is a Plextor PX-712A, so it's supported by EAC)

No, but the audio data also gets CIRC/EFM encoded, so you don't need to worry about the error correction being left out This is always done during the burning process no matter if you make images or separate tracks with or without cuesheets...


Yes, and the only reason to enable cdrdao as external writing engine in EAC, is if your drive isn't supported by EAC's internal writing routines...

Thanks for the correction and more detailed description.
I thought it was a kind of audio channel.

@ FinalFn: I was too lazy to follow the whole discussion, but...

If you rip with EAC secure mode with correctly working accurate rip feature (so you have set-up correct read offset correction and your rip is compared to rips of others) and no errors occured, you can be sure your rip was perfect...

But, have in mind, that not every reader / burner can overread into lead-in/out so you can lose some information (in most cases there's digital silence, but not in all).

Now you have to burn what you've ripped, use EAC or Burrrn! and set-up a correct write offset so the result will be an exact copy of your CD (except the offset which possibly couldn't have been read)...

AFAIK almost every optical drive can retrieve UPC / ISRC code from Audio CD, so no sub-channel information have to be lost.

EDIT: The above about UPC / ISRC is true when burning from CUE Sheet with those information. I'm sorry!

Another thing i dont understand is if there's any quality loss since the audio-data from the CD is "converted" into .wav by EAC (the data on the CD is originally not .wav, isnt it?)

Think of it as the exact same data written out two different ways, like roman numerals instead of arabic. There is no loss introduced by the conversion.



Andy, your post made it sound like you were confusing EAC's Copy Image function with programs that create image files like .isos. You said:



AtaqueEG was just stating that EAC's Copy Image function does indeed create a wav file.