I have been inserting this in the description field over the last year in lieu of not official meta data tag.
Does broadcast .wav standard have a new meta data field specific to ISRC now ?
Also is this specific to Wavelab 8 only or possible in WL7?
cheers
Wavelab is mentioned here and I wonder if support for a new Bwav data chunk has been made in any Wavelab version thus far:
https://www.youtube.com/watch?v=lDGpcGEHcqE
cheers
It is already available in WaveLab 8.0.3 through this preset from the meta-data dialog editor:
Thanks, can you explain how to add this ISRC option to an existing preset that I currently use?
Do I just past this text into the AXML field?
<ebucore:ebuCoreMain xmlns:dc=" http://purl.org/dc/elements/1.1/"
xmlns:ebucore=“urn:ebu:metadata-schema:ebuCore_2012”>
ebucore:coreMetadata
<ebucore:identifier typeLabel=“GUID” typeDefinition=“Globally Unique Identifier”
formatLabel=“ISRC” formatDefinition=“International Standard Recording Code”
formatLink=“http://www.ebu.ch/metadata/cs/ebu_IdentifierTypeCodeCS.xml#3.7”>
dc:identifierISRC:@ISRC@</dc:identifier>
</ebucore:identifier>
</ebucore:coreMetadata>
</ebucore:ebuCoreMain>
Ok thanks for heads up will this work in WL7? or WL8 only functionality?
Only WaveLab >= 8.0.3
I have read that there is an incompatibility with the ISRC embedding in Wavelab. As I gather this is not 100pct compatible with the new standard due to capitalization of the A in AXML instead of aXML
Is this correct ?
http://www.gearslutz.com/board/mastering-forum/712223-isrc-code-embedding.html
I quote from GS mastering forum:
"If you test the WAVs from Wavelab using Sonoris ISRC Editor or any HOFA products, you’ll notice that they cannot read the codes. There is something about the capitalization of aXML that causes it to not be 100% compatible, but it should be in Wavelab 8.5.20 later this summer. As for now, Wavelab will be able to read ISRCs embedded by Wavelab, but won’t be compatible with other apps adopting the new standard.
Wavelab 8.5.10 is very close, but not quite there."
What I am finding is that using the Sonoris tool Wavelab does not see any Axml data, if I add the data using Wavelab it sees it. If I insert ISRC using WL Sonoris cannot see the ISRC code.
Is the problem confirmed as being the fault of WL code and when will it be fixed ?
cheers
This information is correct. The problem will be fixed in 8.5.20.
It is possible to correct the problem with a file binary editor, if necessary, to change xAML to xaml.
Thanks for confirming…did you mean aXML ?
If I was programming this I would have had it corrected and a new version released overnight such is the importance of it’s correct inclusion. It is lucky Sonoris has a freeware tool that does it correctly.
That ofcourse is every user’s thought about their own particular flaws. I, for instance, couldn’t care less about ISRC coding in broadcast wave. A functioning ‘stay on top’ recording dialog however, would qualify for overnight improvement in my book 
I appreciate your sentiment but this could potentially effect musicians releases and potentially their incomes, it is not just some engineer user preference. (although it is arguable that such a new implementation has not yet been incorporated into many systems that can actually read the chunk so it is likely to not be a major issue yet)
This is extremely important to get right, I am actually very disappointed. I know everyone makes mistakes especially with very new implementation but there is no viable excuse for leaving this with immediate correction.
It is also depending on how much you care about your work. I am sending new masters with immediate effect to the few clients who it might effect. There is a right and wrong way to go about these things and anything less than an overnight fix on this is not commendable.
SafeandSound, I think it’s a drag too, but the Wavelab codes as already encoded can be read by BWFMetaEdit, which is the FADGI standard that would probably be used by any organization needing it at this point. And the Wavelab files are also easily “fixed” for use in other programs during the BWFMetaEdit verification process. I don’t think the record labels are in any huge rush to start asking for this and even when they do there would be checkpoints to ensure that codes flowed through.
The “fix” is the Sonoris freeware editor. The fact that only WL encoded chunk is not compatible with other professional ISRC capable software is not leaning in it’s favour right now.
I am waiting for the true WL fix, the speed of that forthcoming will determine my next move.
SafeandSound I understand your point having supplied clients with files already. I’m not discounting your concern. Just trying to add a little information. The problem wasn’t found until the Sonoris came out, which is fairly recent. Before that all that was available for interchange was BWFMetaEdit and Sequoia I believe, and BWFMetaEdit reads the Wavelab files. Possibly also Sequoia, I don’t know. The EBU didn’t supply any kind of utility AFAIK. And there was even a formatting mistake in the EBU document in the comment line that PG luckily removed. I think Steinberg is doing this as quickly as they can, given any other updates, and it will be in the next update. Someday maybe they’ll do nightly builds but…
Sonoris is the slow fix for existing Wavelab files, because you’re individually re-entering each ISRC. BWFMetaEdit can fix a hundred of the Wavelab files at once after individually enabling them (by double clicking each aXML box in the aXML column), because it automatically changes “aXML” to “axml” in the files during it’s verify check, rewriting just that info back to the files, and retaining the original Wavelab entered ISRCs. After enabling all the files, click Save (on the left), and then the files will be fixed, readable in Sonoris, Hofa, etc.
I have purchased HOFA CD/DDP tools, I am investigating them. WL never let me down on the DDP front, it’s great but I am keeping an open mind when it comes to support and speed of correction of mistakes.
I think it’ll be helpful to have a means to double check with the HOFA stuff as this is still a fairly new concept.
Hopefully, when WL 8.5.20 is out, then you can be sure that your rendered WAV files will contain the ISRC codes in a place that other software can recognize it based on the new standard.
So, do I get this correct ? The ISRC, using the AXML preset PG pointed out, should be in the “Description” field ?
If you mean the “Description” field on the BWF tab, no.
You enter the ISRCs in the CD montage on the CD Tab just like you do when making a CD master with ISRC. I usually enter the first ISRC in the CD Wizard, but you can do it in the CD tracklist as well. Then when you render “Regions/CD Tracks” files from the CD montage, the files will contain the AXML and ID3 ISRC if you select the “ISRC (AXML and ID3)” metadata preset. But there won’t be any other metadata. (Maybe it would be nice to have a “Complete plus AXML ISRC” factory preset?). If you want other metadata as well, you have to put together your own custom metadata preset. (Copying and pasting the AXML block that appears in the “ISRC” preset into the “Complete” preset would do it. And add the @ISRC@ variable to the ID3v2 section.). Even then you may want to add more field variables to your preset.
Regardless, the AXML will still have the compatibility problem until the next Wavelab update, so would be preferred to fix with Sonoris or BWFMetaEdit after the fact until then.
Yes, except there’s no way to get to CD Montage with higher rez files. My concern here is to tag hi-rez files with ISRC. Will this be possible with the next WL revision ?
Yes, except there’s no way to get to CD Montage with higher rez files.
You can create montages with hi resolution files. What do you mean?
My concern here is to tag hi-rez files with ISRC.
You can do that already. There is this BWF tag issue that will be fixed, but apart that, this is possible.