Believe me, this is really strange: Yesterday I bought 4 albums MP3 from allofmp3 in freeformat MP3 (384 kbps), converted them all to .wav with LamedropXP and wanted to burn them as audio CD with Nero 6.6.0.6. The first two CDs were OK, no errors. The next one (Joni Mitchell, "Ladies of the Canyon") showed a lot of CU error spikes. Since it was some crap Plasmon disc, I thought,well, crap media and tried a Verbatim DLP (burned at 32x). What is really strange: I got the CU spikes in exactly the same place like with the Plasmon disc Moreover, the place of the CU errors coincides with the track boundaries of the album (Yes, I burned in DAO mode!). I blamed it on Nero, restarted my system and burned the same wav-files with Plextools as an audio CD, this time using a Philips (Ritek) disc. Can you believe it, the same error spikes recurred, in the same places! At this time I was convinced that my PX 716A is dying. But then I tried to burn 2 other audio CDs (again the one from allofmp3 which showed no errors and a completely different one ripped from original CD). These discs showed no C2 or CU errors at all. I thought I was going crazy so I retried the Joni Mitchell album, this time with a Verbatim CD-RW. And AGAIN I got the ugly CU spikes

I retried it various times: No matter what disc or burn speed I never get CU errors with other albums, but always with this blasted Joni Mitchell album. This seems to indicate that my hardware is all right. But WTF is the problem with these Joni Mitchell files?? The wav files play normally on all players, Nero or Plextools didn't complain about them and also the burn itself went without error messages. Strangely, also the resulting audio CDs play normal on my standalone player - no clicks at the track boundaries.
So let's assume the wav files are somehow corrupted. This would mean that the audio data is damaged and written in this state to the CD, but is it technically possible that they can cause CU errors on the disc?? What is more, also the beta curve shows strange spikes at these places.
I'm completely confused about this strange behaviour. If anyone has only the slightest idea what the problem could be, please let me know.

Here are the scans of two different burns (1st: Ritek/Philips, 2nd: Verbatim DLP) and a beta scan of the Verbatim. I think I burned the Philips with 2 seconds gap between the tracks and the Verbatim without gaps so they have a slightly different length.

This problem seems to be related to the audio files and not your drive. I will move your thread to our Audio Forum. Maybe someone there will be able to tell you what's causing the C2 error spikes.

I do know it's fairly easy to sabotage MP3 files so it can be difficult to convert them or burn them...not sure why you're getting so many C2 errors.

I suggest you try burning at 4x (32x is too fast for CDDA) and try a different writer. I can't think of any mp3 corruption off hand that would do that. If the mp3 isn't too big e-mail me it and I'll give it a try for you.

The burn speed was not a deciding factor - I burned the Joni Mitchell files with 4x, 16x and 32x with identical results. The other wav files worked perfectly even at 32x. The MP3s are 384k freeformat, so they are pretty big (~10 MB each) If you'd like to have a sample MP3, PM me your e-mail address.

Anyway, I tried a different strategy and downloaded the MAD MP3 decoder bundle from rarewares.org and decoded the same Joni Mitchell MP3s with MAD instead of LamedropXP - and, surprise, no more errors in the burn! So LamedropXP must have fucked up the wav files so badly as to somehow cause these errors. I am still interested in how such a damaged wav file can lead to C2/CU errors in a burn. If anyone can solve this mystery, please tell me.
I am also not sure if the error is really with LamedropXP (it decoded the other freeformat MP3s from allofmp3 flawlessly) or with the MP3 files themselves. MAD at least didn't complain about them during decoding.

After converting to WAV, what does the beginning and end of each file look like when viewed with a hex viewer/editor? Go to the end of the file and then start backing up until you see lots of random numbers. Then start going forward and see if the random numbers seem to change to any repeating patterns such as 0005000500050005 etc... (check the beginning of the files for this too). Some repeating patterns cause DSV problems when burned and this can cause CUs.

Thank you for your suggestion. I viewed the files with a hex editor and that's what I found:
The beginning of the files looked unsuspicious and rather similar for the problematic files decoded with LameDropXPd and the working MAD decodes. The end, however, looks very different. The MAD decodes look pretty random until the very end. The LameDropXPd decodes, on the other hand, have lots of zeros at the end and then this pattern starts: 00010001 which is repeated hundreds of times. Then further up this turns into 00020002 (also repeated hundreds of times) and so on until 00090009. Then the pattern becomes a bit more irregular, but basically it goes on with 000A000A. The after 000E000E it gets more and more random.
Does that look like a pattern that is likely to cause problems?
BTW, does someone know of e.g. an article that explains these DSV problems in detail?

Greetings, sTisTi

Another question regarding the connection between DSV problems and CUs: Are there really physical CU errors on the discs due to this or is the pattern of data correctly written and just (wrongly) interpreted as a CU error by the drive?

It's me again
I think I've gotten a lot closer as to what caused the corruption in the first place: I looked at the MP3 files themselves with the hex editor. The files which did not cause problems after decoding had a pattern of AAAAAA repeated several times at the end. Somewhere embedded in this there was the string "Lame3.91" which reported the Lame version used for encoding - so I guess that's the Lame tag. The problematic MP3s, however, had not one of these patterns with "Lame3.91" but several (10 or more) of them. So I guess that's what caused LameDropXPd to choke on these files and to somehow produce defective output.

nice detective work on such an odd occurence.

I know that certain patterns are difficult to manage DSV with. Even commercial mastering encoders that make the original glass master can have problems with certain repeating patterns (00050005... being one of them I can think of).

All of my articles are in printed form. I'm not sure what Google would turn up but it's worth a try if you're interested. But, it can be very technical...

Not sure why you get two different results from two different programs. I guess it's how they manage 'analog silence'.

I would have to say NO. There are not really physical CU errors on the disc. Only CDs with some form of copy protection will contain actual CU errors. But, the concept of a CU is if a particular drive can read the data from the CD. So, the written data is wrongly interpreted I would say. The DSV gets too bad for the reader to determine right from wrong....

Thanks again, RichMan. 00050005 was definitely in there hundreds of times at the end of the file between 00040004 and 00060006. So I guess we've found the culprit
Since the MAD decodes did not produce this pattern, I guess the problem behind all this is a decoding bug of Lame.

Update: Now I'm sure the multiple 00050005 patterns at the end of the files were responsible for the CU errors. As a test, I deleted all 00050005 patterns of a problematic wav file in a hex editor and burned the file on an audio CD. I also burned the original problematic file on the same CD - and guess what, there were no more CU errors at the track boundaries of the "repaired" file, while the end of the original file still showed a high number of CU errors. Mystery solved!

Good job sTisTi and thanks for the update. I'm glad you did that test so I would know if that was the cause. Maybe this will help many other folks too.

The problem is not with LAME - it decodes just like it is supposed to. The problem is that the regular patterns incidentally created in its output expose the drive's chipset's weakness.

See the article Magic of Figures, or Detective Story about Unreadable CDs on Digit-life.com for a detailed look at the issue.

That's really an interesting and insightful article. So if Lame is innocent, I still wonder what exactly was so strange about the MP3s that all of them were decoded with this pattern at the end. As I said, all other MP3s were unproblematic, but it happened with every single Joni Mitchell MP3. Viewed in the hex editor, they seemed different (see earlier post) but I couldn't really make sense of it. Does anyone know of a program that analyses MP3s and reports any anomalies? The problem is it would need to support 384k freeformat...

I contacted the authors of the above article. Yury Malich answered me and explained that the cause of my problem is different from the one they encountered because audio data is not scrambled. He thinks that the cause is bad DSV due to some regular patterns. These could be caused some copyright protection (unlikely in case of this old album) or pink noise.
I took a snapshot of the part which contained the 00050005 pattern (the highlighted section) in Nero Wav-Editor in spectrogram view. Note the high magnification (5000%). I don't hear anything directly in this section, but shortly before there is very very faint noise that is gradually fading out. I've no idea how pink noise looks like. Can anyone make sense of this?