PreGap question with Audio CDs

This pertains to the no-chip playstation disc topic and the EFM/AWS topic, but is a separate question, it is a problem I have come across the past month with copying audio CDs with CloneCD and other DAO RAW 96 compatible programs.

I have a LiteOn LTR-24102B drive and I have burned many a disc and then tested the track CRC values with EAC. The CDs I have been copying are regular audio CDs with no copy protection that I know of, unless they contain some “bad Subchannel data” Audio CD" copy protection" That I am not aware of. (ClonyXXL tells me they are regular audio CDs.)

“Copy protection” is Dr. Evil style, because, in essense, this is not copy protection really at all, because it does not keep anyone from ripping the cd, it only affects creating a 1:1 copy, which I have yet been able to do. I have discerned that it has something to do with the subchannel data or the Pregap data more specifically. My drive will read this information perfectly, because I have used Daemon Tools to verify the CRCs with CloneCD images along with EAC. The image works perfectly and retains the same CRCs as the original, including the same progap information.

The problem comes when I burn a DAO RAW 96 copy with CloneCD. The copy may contain some tracks that have the same CRC, but 3 or 4 may not. This has occurred with more than one CD. I have set the program to “Don’t Repair Subchannel Data” and am writing at the lowest speed possible, and I still produce the same cd time after time with slightly different PreGaps, and of course different CRC values for the tracks.

I assume this has something to do with not being able to write the exact PreGap information that the image contains, as what was said in the PSX topic, we can read the data, but dont have software to write it yet. I figure this has something to do with writers writing RAW/2352 and not the “full” 2448 or something of this sort for which CDs truly contain… but I am not certain.

What is the issue here keeping me from making 1:1 copies of audio cds, and is this the same issue (and roadblock) that is effecting PSX copies, etc?

Update: I forgot to mention that I have tested one CD-Text disc, and many that are not…both give me some different crcs, so I assume this does not just affect cds with extra subchannel data added on purpose (the CD-Text)

Keep in mind that you can’t create 1:1 copies of audio CDs with CloneCD (no matter if the CD is protected or not).
The copy will have a slightly different offset, depending on the drives, you use.
And to make it more complicated, drives can change their offsets if they have to read/write subchannels.
By example my PlexWriter PX-W1210S has a read offset of -98 samples. but if I read with CloneCD and subchannel reading is enabled, my image has an read offset of -686 compared to the original image (read with EAC, offset corrected).
The same occurs when writing with CloneCD:
Normally, the Plextor writes audio-cds with an offset of -30 samples, with CCD it has suddenly -1206 samples.
Really strange. Maybe this issue has something to do with the implemented subchannel/mainchannel offset correction of CloneCD.
Nevertheless, your original CD and your copy still can have the same CRC value for their tracks. This depends on the setting “no use of null samples for CRC calculations” (EAC).
If this is turned on, the CRCs are calculated only for the real main part of your wave file. Because most wave files start and end with pure silence, you can get the same CRC for two different files. Really bad, so I recommend: turn this option off.

But I wonder why your pregaps are different. They should be the same, no matter if offset errors occur. But EAC’s pregap detection isn’t really one of the best.
You should use CloneCD to get a cue sheet from your CD/copy.
Read subchannels from audio tracks, and you’ll get the correct indices in your cue file.
Alternative: Try Cdrwin and set subchannel analysis to “full”

hope this helps …

yes, now I assume the pregap problem occurs because EAC’s does not always hit the nail on the head 100% of the time. I have changed my pregap testing to Method A and Secure, instead of Method B and Inaccurate, and will se if it gives me better results…i think I even remember getting separate values for the same cd, so its kinda touch and go with EAC pregap finding. As for offset correction, I never knew the implications of this now not-so-cryptic setting. This explains the reason for the image to display identical crcs with D-tools, but the same image burned to disc to not have the same crcs. But, given that I did have the setting checked on to ignore silence when calculating crcs, it would seem to me that regardless of the read offset, shouldnt the burned cd still have the same crcs per track if the tracks were copied perfectly? I will test the crc output with this setting off, as it seems that with it off, the accuracy to determine a perfect copy will be more exacting. Another Question…how do I test my read and write offset when reading and writing with subchannel data involved? I used EAC to make a test cd to obtain the read offset, which was +6, but I assume that this test did not apply subchannel data to the cd, and i also figure that the read offset will stay the same regardless of subchannel data being present or not on the cd; subchannel data only affects the write offset, correct? Thanks

Update: After testing the burned cd, the original, and the image with the secure pregap detection, all three turned out to be identical in their pregaps. With the ignore silence option off, and the read offset set to +6, the crc variance still remains. If i can find some temporary webspace, I can post some images of EAC demonstrating my results.

I have come across another interesting occurance. Instead of just using the testing feature in EAC, I decided to actually rip each form of the cd that i have been testing to wav files, and then compare these files in a binary comparison program. The results are really weird. Remember previously I stated that the crcs of the original cd and that of the disc image mounted with D-Tools were identical when using the test feature of EAC, and that the burned CD was the only incarnation of this audio cd with different crcs. Well, get this, once I actually ripped the wav files and compared the trifecta, the crc disparity flipped sides on me. One would suspect that he ripped wavs of the image and the original would be the same, because the test crcs were the same, but this is just not the case. Instead, the identical wav files once extracted were the ones ripped from the disc image, and those ripped from the burned cd. The odd wavs out were from the original cd! Why would the image and the original match in crcs when tested, but when actually ripped, they differ? I assumed that EAC, when using the testing feature, was still ripping the wavs into the backgound, testing the crcs, and the deleting them when finished. Is this not the case?

Another Update: Well, I went back and double checked the test crcs of the image, and come to find out, I now read the same ones as the burned cd, even without actually ripping the image. I do not know how to replicate the values previously, where they instead matched the original. I assume it has something to do with disabling the “crc silence” option. I believe that before I had had it checked, while now I don’t, changing the crc values from one to the other. This brings up another question…could the problem here with making a perfect copy stem from drvies not being able to copy the digital silence the same way it was on the original? This would back up my findings completely. And verifying your earlier idea to test it with CDRWIN (in essence, another program), no this does not help, I get the same results using CDRDAO and CD Raw Copy, both DAO RAW 96 programs as well.

First, pregaps have absolutely no effect on CRCs. CRCs are calculated on audio data only, pregaps are just subchannel data.

Second, I don’t think many CDs have digital silence at the end of tracks. When I needed one for a given test, I discarded all old CDs mastered from analog source, CDs recorded acousticly, and live CDs. I only checked CDs with electronic music tracks separated with silence.
Well I had to check three or four of them until I found one with true digital silence between the tracks ! The others had either analog noise, either dither noise.

So even discarding null samples for CRC calculations, offset will often change CRCs, and the last and/or first track will have special overread/overwrite problems regarding CRCs, because of their very beginning or very end data.

To save you a lot of work, use the “compare wavs” function of EAC to test for audio data instead of CRCs : it will immediately tell you if one file is longer, if there are missing/repeated samples (offset) or different samples, and where (different samples at the begining or end might be caused by unability to overread, different samples in the middle of a track are read or write errors).

When you get differences in the middle of tracks, rip again, because read errors are common on audio CDs. Most of the time, the differences will vanish in the second rip, or move. If they stay, they are likely write errors.

Edit : added “instead of CRC” sentence.

hi mmortal03,

first, you should visit the article The Truth About Offsets.
I think, it will clear up some things for you.
There is also a database available, which shows the features of many drives (offset, C2, caching, etc.). Maybe your drive(s) are listed in there.

But, given that I did have the setting checked on to ignore silence when calculating crcs, it would seem to me that regardless of the read offset, shouldnt the burned cd still have the same crcs per track if the tracks were copied perfectly?
This depends on the offset, which is introduced while writing or reading (in theory it can be so big, that the main audio data is harmed as well). And of course it depends on the content of your wave form (does it start without silence?).

Another Question…how do I test my read and write offset when reading and writing with subchannel data involved? I used EAC to make a test cd to obtain the read offset, which was +6, but I assume that this test did not apply subchannel data to the cd, and i also figure that the read offset will stay the same regardless of subchannel data being present or not on the cd; subchannel data only affects the write offset, correct? Thanks

Keep in mind, that such a test-cd makes sense only if you know exactly the write offset of your burner. Else your displayed read-offset will be wrong if you re-read this CD.
BTW: Subchannel data is applied to every CD. Without subs, no CD would exist. They contain important control information, needed to address audio sectors or to store the TOC and CD-Text (within the lead-in area). Some copy protections use special subchannels, if you don’t read them, standard subs are generated by the software on reading or writing (then done by the burner).

I don’t know, if all burners change their offset on writing with subchannels. At least my burner does so.
And it changes it not only on writing but also on reading.
My UltraPlex doesn’t change the offset at all. It stays @ -676 samples all the time.

To test the offset on writing (with subchannels), simply write a wave file with Cdrwin onto CD (select RAW option). This gives the same results as recording with CloneCD DAO 96.
Then re-read the disc with EAC, correct the read offset of your drive and compare the original wave (before burning) with the one that you have just extracted.
To check the read offset (with subchannels), just read the disc with CloneCD and select "read subchannels from audio tracks).
Because EAC can only compare files with a valid wave header, you have to mount the CCD file from CloneCD with Daemon.
Then extract from the virtual drive to get your wave file. (Daemon doens’t introduce any offset errors, of course).

Why would the image and the original match in crcs when tested, but when actually ripped, they differ?

Please use the “Compare WAVs” function. Just Press Alt+C within EAC. Then post your results again. EAC doesn’t compare the files bit by bit like any other comparisation tool, but can also display offset differences.

good luck …

I appreciate the article, now I understand offsets a lot better. My drive does not overwrite the pregap or the lead-out, but I have determined it to have a write offset of -76, and a read offset of -82 (the read offset correction is +82 of course.) I found this using one reference cd, the only one i have on the list, so it COULD be incorrect. Going by the web listing of the LiteOn LTR-24102B, the read offset is -6 (osc +6) and the write offset is -12, but this is with a completely different firmware 5s07, compared to my 5S5A. Since offsets can change with new firmware, I may flash back to 5s07 to verify my reference cd (and therefore verify my offset findings as compared to what these users reported). According to the aformentioned document, regardless of what my write offset is, and because I cannot overwrite the lead-out, I am going to lose samples at the end, since whether my write offset is -12 or -76, it is still negative. Therefore, the only track effected, and the only track with the possibility of a different crc (depending on whether it ends with digital silence or not) will be the last track. Apparantly then, to test if the write and read settings I have are correct, I should rip and then write a copy of the original cd with my new settings, and then rip the copy and compare the copy’s wavs with that of the original’s. What should happen is that all the wavs are identical, with only a possibility that the last track is different. Please verify this, and i will soon post my results…

yep, it worked. the, copy I made of the original now has the exact crcs (and exact wavs) as the original. There is little chance that between the original 0 read and the new +82 read that i simply lucked out with these offset values and this particular cd, since I am determining the crcs including any digital silence. This makes me happy. :wink: I went ahead and tested one other question of the topic, and wrote the same cd with CD-Text as well, and it too matched its maker, so, I assume my drive does not change the offset when writing extra subchannel data. Lol, the only things I need to look out for now are CDs that don’t end in silence, otherwise, i will be set. When will other software programmers add offset correction to their writer programs? I guess ill just be stuck with the great EAC until then :slight_smile:

You can cut your wave file(s) with an audio editor like Cool Edit, so they don’t contain silence anymore.
By example, my burner can’t overburn into the lead-out.
So, if the CD doesn’t end with digital silence, the last 30 samples will be lost. Either the burner just doesn’t write them anymore and the reader fills these sectors with zeros (the audio image must be a multiple of 2352), or the burner fills them up with silence already on writing - I don’t know.
So it is (in my opinion) better, to not correct the write offset.
Because no data is lost on writing with an offset, you can perfectly correct the written offset on re-reading your CD.
By example my UltraPlex has -676. Because of the written offset of -30 samples, I have to read with -646 (+646 in EAC, of course), to get the real wave file(s). Of course the copy itself on CD won’t be a 1:1 copy, but it is still better than truncating 30 samples.

Adding CD-Text doesn’t change my write offset, too
You have to use Cdrwin’s RAW mode or CloneCDs subchannel writing. If you only add CD-Text, the writer will prepare and generate the whole subchannel data by itself.

i see what you mean, you would rather have all the data on the cd, rather than try for a perfect copy, because if you ever want to extract the wavs again, you will know the offset it was written at, and you can correct it when you extract. You are coming from the standpoint of writing your own perfect audio without any offset correction so that the last 30 samples are not truncated since you cannot overwrite the leadout. You will simply read the next time starting at -646, and you will have all the audio you originally wrote.

But what if you do not have the perfect audio to burn, say that you extracted a pressed cd to get the wav files that you want to now burn again. In this case, no matter which pressed cd you copied, you lost 676 samples at the end when ripping the cd, and in my case I would have lost 82 samples at the end if I ripped that same cd, because neither of us can overread the leadout. With this in mind, and with any ripped cd of yours, when you go to reburn them, the only data that you are losing when you write with your write offset corrected is 30 samples out of the 676 samples at the end of the last track that you didn’t have anyway. (digital silence taking the place of what should have been read off of the original cd.) Hopefully, these 676 samples were all silence anyway, but there is no way to test this on our drives, because we cannot access these samples. To us, the original cd’s last track and and the copied cd’s last track may have the exact crcs, because we cannot read either of them any further. But for someone who CAN read into the leadout, they can easily compare the two cds and tell that the last track is different, even though they both look the same to us. Therefore, for copying cds, there is no reason not to write with an offset, because in our situation, it won’t matter. There will be 646 samples of digital silence written at the end of the last track for you, and 6 samples of digital silence written at the end of the last track for me. Yes, you will be missing 30 samples, and I will be missing 76 samples when writing offset corrected, but these samples are digital silence taking the space of the audio that we never had from the original disc.
So yes, when writing your own cds, you MUST NOT write with an offset, but when copying cds, there is no audio data that you are losing when writing. You already lost all the data you are going to lose when reading.

Update to the first paragraph: After more thought, I asked myself, why would the drive truncate a wav file it is writing at the end? I assume the writer truncates the last wav according the the exact required leadout placement stated in the cue sheet.
But when writing your own cd, I assume EAC would do the truncating of your file when writing, so confirming what I said before, DOT NOT burn your own tracks with write offset correction. I guess you could add digital silence to the end of your last track, and then write it offsetted, and everything would be cool. This is probably your best bet, because then you lose nothing, and can keep your read offset correction standard.

I hope you realize that official CDs are pressed with varying offsets from -2000 to +2000, according to the reports of offset detection failure with reference CDs on the EAC mailing list.

So why bother with 30 missing samples when 2000 were dropped out at the factory to begin with, out of the 80,000 null samples that are added by the mastering engineer to prevent this ?

Here are the main discussions we had about offsets :

Offsets are arbitrary : @EAC mailing list.

Mathematical war between Pio2001 and Matthias trying to figure out ofsets without external reference :
How to figure out your offset @EAC

How to “read” your read offset with noisy CDs : How to find a reference offset Article

Arguments against offset correction :
The use of offsets@EAC

Why can’t two drives read identical images - even when calibrated? @ EAC
…or the relativity of exactness.

Thanks, very helpful stuff.

Re-reading them, I’ve updated the “how to read your offsets” article, as some false info was written about lead-in.

Originally posted by little-endian
I don’t know, if all burners change their offset on writing with subchannels. At least my burner does so.
And it changes it not only on writing but also on reading.

Andre, EAC’s programmer says it’s not possible :confused: :

Andre, EAC’s programmer says it’s not possible :
This is really strange.
But one thing is certain:
If I read a CD with CloneCD (without any subs) and compare this image with the one, created by EAC (offset not corrected), then no differences occur (fc /b). Of course, I deactivated writing the Wave header. If I read again with CloneCD, subs reading enabled, the image won’t match EAC’ s again.
Maybe you can try this yourself.
Perhaps, Andre owns a PlexWriter, too ?

I didn’t try it because I don’t have cloneCD. But you should use EAC to compare wavs (tools/compare wavs), because the FC command won’t tell you if your wavs are offsetted or if there is just a read error in them, or even if the headers are different.

Of course, I used EAC’s wave comparisation, too.
To do this, I added a wave header to both files (with Cool Edit).
The displayed results tell me exact the offset, I already reported.