ISRC embedded in 24bit Wav PCM masters

So here is a new question:

I have a WAV file that was generated by HOFA DDP Player which now embeds ISRC codes directly into the WAV files when you export WAVs from the Player (assuming the DDP has ISRC codes). The ISRC codes show up in the new Sonoris ISRC Editor with no problems.

However, when I load the WAV into Wavelab, I see ZERO WAV metadata, not even the ISRC code that Sonoris ISRC Editor can see.

Will this also be fixed in the next patch along when the proper amxl field?

PG, the Hofa, Sonoris, and BWFMetaEdit files are all ISRC unreadable if you open them in Wavelab. Apparently because they’re all using “axml”.

The easiest way to test this is with the Sonoris:

Or I could send you test files of all of them.

I’d also like to ask if it would be possible to decode the xml that’s displayed when you open a wav file and look at the metadata properties. The axml and ixml would be much easier to read if the xml was decoded to just display the relevant metadata, rather than having to look through a paragraph of xml code for the metadata inside.

I’d also like to ask if it would be possible to decode the xml that’s displayed when you open a wav file and look at the metadata properties. The axml and ixml would be much easier to read if the xml was decoded to just display the relevant metadata, rather than having to look through a paragraph of xml code for the metadata inside.

Where would you like to see it displayed?

I agree that the meta-data box for single files in the editor could be cleaned up a bit. I agree that I don’t need to see all the behind the scenes code, I would just like to see the relevant titles for artist, song, album, ISRC etc.

I imagine it looking something like how the CD-Text box looks in the montage. It’s nice and clean. The meta-data boxes (both in the montage and edit mode) get a little too detailed with coding in my opinion.

I think the XML should be decoded in this view pictured by jperkinski:

Metadata display of an audio file open in the audio file or montage workspace.

I don’t think it should necessarily be decoded in the main metadata tab editor, because a user might need to add more AXML or IXML user code. Unless that’s what you’ve already done with IXML with the split windows. (decoded and raw split view?). I can’t remember if that’s what you’ve done with the IXML windows. But if it could be split raw and decoded for the AXML in the tab editor it seems that would be ideal I would think.

As it is now, IXML and AXML in the tab editor is very similar to BWFmetaEdit, which is fine with me, but maybe could be better if it displayed XML raw and decoded, split window, the decoded being read-only?

Or maybe the XML decoded being editable with just the metadata fields defined in the raw XML displayed for editing in the split window?

ISRC:________________
Other AXML User Field:___________

I don’t know what’s possible or practical.

Is the lowercase letter isues (aXML vs axml) fixed in the 8.5.10 release?

It doesn’t appear to be. Here’s a screen shot of a WAV encoded with an ISRC via HOFA DDP Player. The code is readable by Sonoris ISRC Editor but nothing appears in Wavelab 8.5.10

The update was released before this axml diagnostics. A fix will happen in next minor patch.

Any idea when we can expect the update? Or is it already fixed in 8.5.1? I’m about to embed some isrc codes in wav files for a customer so I need to know what the satus is.

ISRC support in WAV files using the new standard is definitely not in the 8.5.10 update. Wavelab will be able to read the codes you embed in the WAVs but it won’t quite comply with the new standard used by other software. I suggest using Sonoris and/or HOFA to double check your codes. They seem to be up to date regarding this.

I think your best bet is to use the new/free Sonoris ISRC Editor:

This will be fixed in 8.5.20, targeted about end of the summer.

OK, thanks! I’ll stock to sonoris then. I also have DDP creator pro, so I will use that to embed the isrc in the wav files.
Too bad this issue wasn’t fixed in the latest update since I think it was known before the update and it was a small issue IIRC.