DDP isrc problem

Hi there, I have used WL ddp generator for the first time and the manufacturer is getting problems when ‘duplicating’ small quanities. Using WL 8.5.20 (build 868)

When a CD is burned from WL ddp the isrc codes are correct. When a CD is then burned from that first CD (as done in some duplicating situations), the isrc codes are all messed up!

No one is sure if it’s WL causing problem, but they haven’t had this problem before and this is the first ddp I’ve done with WL

Anyone had this problem, any suggestions from wavelab?

Stewart Peters

Is it the country code or company code in the ISRC that’s messed up (the first 5 characters)? I had that problem a long time ago in another program with a secondary copy. And it was specific to the country or company code (can’t remember which). Most country/company translated fine, but the one I was testing was not translated correctly (turned it into XXX or something). Don’t know if it was burner or program related. If that’s where your issue is, have they ever gotten your country or company codes before?

… it seems to be just the very last digit. Everything else, country code, artist code etc are okay. So the code might be AUJ941500001, and it becomes AUJ941500004 - just the last digit

Hi …

Do you have a 3rd party DDP player … like Sonoris or HOFA? Load the DDP into that and see what it thinks it sees.

Also, did you do a ‘copy and paste’ of the ISRCs from a text file etc into WL?

I have encountered an obscure issue (twice) with a copy and paste from a OSX generated text note sent to me by a client. My mastering computer is a PC.

In the course of our QC procedure (ie before it was sent out), we discovered that for some reason CD Text displayed some ordinary characters in bold and others were replaced by symbols. This was revealed when we imported the WL DDP into a third party DDP player for verification and generated a PQ sheet from that application.

I wonder if something like this has happened.

The work around of course is just to manually enter the data. But we also found that you could copy the text from the source and paste that onto a note/word document on your system and in turn copy from that.

I do not think this had anything to do with WL.

Good luck with resolution.

stewartpeters, I should have asked before, but this is my understanding from what I read:

You sent the manufacturer a Wavelab DDP.
They loaded the DDP in a DDP program and made an Audio CD.
That Audio CD checked back fine with correct ISRCs.
They then cloned that Audio CD (like they usually do with their other projects without problem).
The Audio CD clone had incorrect ISRCs .

Is that correct?

Yes, that’s right. The second generation copy from their first burnt disc (from my ddp) has the errors. They are doing a work around by burning straight from my ddp.

But I need to know if it’s my problem (WL) or theirs. Either way it’s my problem :slight_smile:

Also, I wonder if I burned a CD instead of sending them a ddp, would that CD have errors when they try to duplicte it. I my send them a burned CD for them to test. They use Sonoris apparanetly.


stewartpeters … I can send you a Sonoris DDP Player if you want (we have the OEM version).

the Sonoris oem version might be handy. Windows? As a download? I’m in Australia.

I could at least have a look at what sonoris is doing with the WL ddp.


Also, I have found this link Creativity First | Steinberg which talks of WL generated isrc codes not reading in sonoris. Apparently because WL writes them as aXML instead of axml which sonoris dosn’t recognise. I’m a bit out of my depth here, but maybe that is part of the problem (if WL does have a problem).

Here is part of that post “…After verification, I see that WaveLab stores the data with the “aXML” signature, rather than the “axml” signature. Some programs read both signatures, but the official signature is “axml” and WaveLab should be updated to comply to this…”

Any other suggestions?

The axml problem only affected ISRC metadata in WAV files, and has been corrected in 8.5.20. The axml problem had nothing to do with ISRC in DDP or CDR, only in WAV files.
According to what you wrote, the Sonoris program at the manufacturer appears to have read your DDP ISRC correctly, since a correct Audio CD was burned from it. I think that possibly removes Wavelab as a factor in the problem. It’s worth trying with Sonoris yourself though.
It seems more likely to me it’s an issue reading from that Audio CD to make the clone, or writing to the clone, or media, or burner, or burning software. Even if they tried more than once, it still seems most likely to me to be on their end. But I’ve been wrong before.

Yes, I noticed the problem was pre WL 8.5.20 I just thought it was worth mentioning. Your suggestion that if the first CD is okay, then that removes WL from the problem.

So do you think I shouldn’t be worried about using WL for ddp’s? I have tried Hofa (importing both the WL ddp and with HOFA generating it’s own ddp) and can’t find ny problems with that either.

Is there some way I can get old of the oem Sonoris?

Sending to you now … to soundshed. I am up the road a bit on the Fabulous Gold Coast.

FWIW, I have never had this issue with WL and ISRCs and I always do QC in the Sonoris.

Did the CD-Text song names include special characters like accents or tildes?
I had problems with file names written on mac with accents and tildes (ñ) e.g…
Even on windows explorer the show up corrupted.
Also, I had a problem with copy/pasting names and accidentally leaving a space at the end of the name.
I could not extract the CD with EAC e.g. it would grey out the extract WAV Image on EAC.
Now I double check the spaces at the end of names in Cd-Text.
Accents and tildes written on windows show up fine on Mac…

Similar issue to that I described above.