Greetings -
I am sort of new to high-quality audio extraction and archiving, having started to rip my CD collection last December. My aim is to rip all CDs, keep the original CDs safe in paper jackets, and use copies for day-to-day listening. At the same time, I want separate playable files with lossless compression.
Here are the steps I use so far:
- Rip CD to separate WAV tracks with Exact Audio Copy, using the known read offset of my drive and verifying the integrity of the files with AccurateRip;
- Burn CD to CD-R media with Exact Audio Copy, using the write offset of my drive which I determined by burning an offset test CD;
I also compress the WAV files into FLAC, which I archive and listen to with VLC or Foobar2000.
I have verified that the audio part of the copied CD-Rs is bitwise identical to that of the original CDs. Now I have the following questions:
1) Each sector of CD audio contains 2352 bytes of audio content and 96 bytes of sub-channel data divided into 8 channels P through W. (Only channels P and Q are part of Red Book, while channels R through W are supposed to be unused.) Do I understand correctly that this information is not retrieved by EAC or any other software and hence lost (not identical in the copy)?
2) CD-TEXT is not part of Red Book audio, but part of the CD+G extension. It can be stored either in the lead-in or in subchannels R through W. EAC does have an option to read CD-TEXT information from the CD, but this only seems to be used if the CD is not found in a database (which my CDs usually are). When burning the CD, the CD-TEXT recorded is the one from the cue sheet, which is generally not identical to the original data. Does EAC write CD-TEXT to the lead-in or to the subchannels (or both?)
3) There seems to be an issue with some (but few) CDs having audio content (a "hidden" track) in the pre-gap track of Track 01. None of my CDs seem to be affected, so I have not yet run into this problem.
To summarize, why doesn't there seem to be the possibility to read the entire linear data stream from a CD (including all subchannel data) and writing that stream to recordable media?
Thanks, Couscous
CD/DVD drives will not (to the best of my understanding) report all of the subchannel data in its raw form. Drives can report some subchannel flags, like pre-emphasis.
Some applications (e.g. CloneCD) claim to be able to read raw subchannel data, dependent on the user’s drive (there are varying read modes), and can do so to separate files, but in my experience (long ago) one can read the same disc twice and receive different results.
It’s probably not worth it. When burning the rip back to CD, subchannel data is reconstructed based on the track layout and cue sheet provided, and I imagine it’s close enough to suffice. As for CD-Text, if ityou’ll have to maintain
At its core, it’s a limitation of the CDDA format and the way that CD drives are hard-coded to read discs in a specific way.
Some applications (e.g. CloneCD) claim to be able to read raw subchannel data, dependent on the user’s drive (there are varying read modes), and can do so to separate files, but in my experience (long ago) one can read the same disc twice and receive different results. This is presumably due to absent/reduced error correction for the subchannel data.
It’s probably not worth it. When burning the rip back to CD, subchannel data is reconstructed based on the track layout and cue sheet provided, and I imagine it’s close enough (it certainly won’t affect the important part: the audio).
As for CD-Text, if it’s present you’ll have to abstain from editing its (usually idiosyncratic) formatting in the cue sheet or retain an unedited copy. Also, if you want to be as ‘accurate’ as EAC will allow, if the original disc lacked CD-Text, disable its writing in the preferences.
Thanks @Eli and @dv1989 for your replies and insight. I tend to agree that the bitperfect copy of all audio data (including pre-track gap information) has the highest priority in audio CD ripping/archiving and that sub-channel data is secondary.
Here is another question:
4) I ripped most of my CDs to separate WAV -> FLAC files with noncompliant CUE sheets, but did some tests with single WAV files. I suspect that the single WAV files do not actually contain any additional information (e.g. sub-channel data) as compared with separate tracks. Is this correct?
Thanks, Couscous
No, that isn't correct. EDIT: Sorry, I misread your question.
Let's go back over some of your other assumptions which were not addressed directly:
1) EAC pulls non-01 indices and ISRC data from the sub-code.
2) CD-TEXT is only pulled from the TOC using EAC-compatible drives which are configured as such.
3) HTOA can be extracted using EAC but only with drives that are capable.
Another issue not raised is that pre-emphasis information is only pulled from the TOC when using EAC.
Hi @greynol, thanks for the quick reply and for clarifying some important details. Where does EAC place information on pre-emphasis? Also in the CUE sheet? I have never seen this, maybe none of the CDs I have rippped so far make use of it.
I am not sure whether your statement "No, that isn't correct." refers to my question 4). If so, which information is placed in the single WAV that isn't in the many separate WAVs?
Thanks, Couscous
Where does EAC place information on pre-emphasis? Also in the CUE sheet?
In the GUI and in the CUE sheet.
I am not sure whether your statement "No, that isn't correct." refers to my question 4). If so, which information is placed in the single WAV that isn't in the many separate WAVs?
I'm terribly sorry, I completely misread your question. You're absolutely right, there is nothing present in a CUE for a single-file image that that cannot be present for CUEs created to be used with multiple files.
And nothing in the single WAV file itself either, right?
EAC simply stores 16-bit, 44.1kHz LPCM in a standard wave container without any other information when instructed to rip to an uncompressed file.
HTOA is not extracted automatically when ripping to single tracks, as it is when ripping to an image; in the former case, you would have to extract it manually using Extract Range. Either way, your drive must be able to read HTOA; some can’t.
It is if gaps are prepended to the current track then HTOA will be extracted automatically, though few people do this and I am certainly not advocating it.
Regardless, extracting HTOA to a separate file using EAC is extremely trivial, to the point that I don't believe people should be discouraged from ripping separate tracks (either explicitly or implicitly). Modifying a CUE sheet to include this information isn't all that difficult either.
Also, when extracting HTOA, I think it is easier and more fool-proof to do it by selecting the first track, telling EAC to copy it as index-based and then delete the 01.01 file rather than rip as a range.
Thanks for the additions; I didn’t think of your first and third points. It’s well seeing that I haven’t used EAC for ages and that I used images when I did! But I agree that there’s no reason to discourage the single-track method.