SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

Problems with Qobuz metadata for downloaded wav files

I do have some problems with Songkong and for a better understanding I’d like to use this opportunity to go into more detail:
I’m a listener of classical music and I use Qobuz to download albums in WAV format. Now, as it turns out Qobuz uses metadata with a mix of ID3 and ‘wavelist’-chunks.
Now, the real problem is, that Qobuz always leaves the ‘album artist’-tag field blank.

As a consequence, most tagging software products (including Songkong) seem to be unable to read ANY tagging information und my music library sotware is in many case unable to recognize the album correctly (i.e. assigning the tracks to one album).

The only software I found so far as being able to read and update the metadata is dbpoweramp (which is primarily a ripping software). The huge disadvantage however is, that I am able to only update track by track, which is quite cumbersome.
Interestingly enough, as soon as the metadata contains the ‘album artist’ tag, every tagging sotware seems to be able to read the metadata. But that’s of no use for me anymore.
Basically, the one and only one task I have is:
I need a function where ONLY the ‘album artist’ field is added but nothing else changed !!
For this, I I tried the ‘Edit Songs metadata’ function of Songkong:
With this I got a spreadsheet of all my tracks of the album and I also can add the ‘album artist’ for all the tracks at once.
However, although the ‘album artist’ will now be automatically added to all the tracks, other unfavourable changes will be done by Songkong, too, like:

  • other tagging fields like the ‘artist’ and ‘tltle’ will be blanked out
  • tagging fields and physical file information containing special characters (like accents, ä/ö/ü, etc.) in the text will be replaced (with unreadable ones)

So, I would be very happy to get a Songkong solution allowing me to add the ‘album artist’ field WITHOUT ANY OTHER CHANGE .
Sounds quite simple but I didn’t find a solution yet.

Highly appreciate your help.

It doesnt make any sense that the simple omission of album-artist value would prevent SongKong reading any information or being able to match the album. Can you try an automatch of one album then immediately after run Create Support Files so I can see the results.

It sounds to me as if Quobuz is adding metadata using wavlist chunk, then when you edit album in SongKong it adds Album Artist to a new ID3 chunk, then because that is the only thing added to ID3 chunk now that becomes the only field that can be read.

But that is just a guess, could you please email (or use dropbox or similar) a quobuz file so I can test this theory out.

Great idea - granted you access to some data for analysis on dropbox.
Question: what precisely do you mean by ‘automatch’ of one album ? To run the ‘fix songs’ action for an album ?

Thanks for the files, okay the basic problem is the ID3 tags in the Quobuz files are corrupt

The first field is the Album field, but this incorrectly has its length as much longer than it actually is

From logs:

18/01/2023 09.05.00:GMT:AbstractID3v2Tag:seek:CONFIG: ByteBuffer pos:0:limit922:cap922
18/01/2023 09.05.00:GMT:ID3v23Tag:read:CONFIG: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav:Reading ID3v23 tag
18/01/2023 09.05.00:GMT:ID3v23Tag:readHeaderFlags:WARNING: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav Invalid or unknown bit flag 0x16 set in ID3 tag header
18/01/2023 09.05.00:GMT:ID3v23Tag:read:CONFIG: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav Tag size is 902 according to header (does not include header size, add 10)
18/01/2023 09.05.00:GMT:ID3v23Tag:readFrames:CONFIG: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav:Looking for next frame at:0
18/01/2023 09.05.00:GMT:AbstractID3v2FrameBody:read:CONFIG: Reading body forTALB:341
18/01/2023 09.05.00:GMT:NumberFixedLength:readByteArray:CONFIG: Read NumberFixedlength:0
18/01/2023 09.05.00:GMT:ID3v23Tag:readFrames:CONFIG: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav:Found TALB at frame at:0
18/01/2023 09.05.00:GMT:ID3v23Tag:readFrames:CONFIG: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav:Looking for next frame at:351
18/01/2023 09.05.00:GMT:ID3v23Frame:read:CONFIG: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav:Invalid identifier:onia
18/01/2023 09.05.00:GMT:ID3v23Tag:readFrames:WARNING: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav:Invalid Frame Identifier:E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav:onia:is not a valid ID3v2.30 frame
18/01/2023 09.05.00:GMT:ID3v23Tag:read:CONFIG: E:\MusicTest\Isabelle-Faust\Isabelle-Faust\Stravinsky-The-Soldiers-Tale-English-version-Elegie-Duo-concertant\1_10_Isabelle-Faust_The-Devil-appears_13.wav:Loaded Frames,there are:1

So SongKong reads other fields as if part of Album field, if you just run Status Report on the files you can see this

The workaround is as follows:

Run Fix Songs with Search for a MusicBrainz match, Update from Discogs and Search for a Discogs match unchecked because we dont want to find a match wihen we have this existing bad data and everything added to Delete all metadata from these fields (Important except Duration field), this has the affect of deleting the corrupt data added by Quobuz.

so you end up with

Then rerun Fix Songs with match option back to usual (with the MusicBrainz and Discogs options checked) and everything removed from Delete all metadata from these fields so now SongKong can use its matching algorithm to find a good match

and now SongKong matches the album correctly

thank you so much - will try and give you feedback

Thankyou , what would be good to know is how widespread this problem is. Does this problem occur with all Quobuz albums, or just a few, or just this one.

If you run Status report on a random Quobuz album, and use the Browse menu to navigate to a track on the song does it show the same corrupted Album field problem?

First of all let me say that this problem is iMHO indeed widespread with Qobuz albums (at least regarding classical music albums). Having a representative number of downloads (few hundreds) I would guess it’s roughly 20% of them with this problem.
Now to my feedback:
I followed your 2-step instructions and the final result looks quite fine. Unfortunately, my main problem still persists. Special characters are still misspelled und unreadable. Did I miss something ?
Here are two screenshots - the first is how titles are displayed in my windows explorer list and the second one is the tagging infos for the first track.

Howvever, the ID3 tag information it self looks perfect:

Any explanation ?

Okay I think have found problem.

Original file from Quobuz contained corrupted ID3 tag and valid Info tag, the Info tag writes the data using the IS0-8859-1 so É is written as 0xC9 and this is okay.

When the file is modified by SongKong it writes a new valid ID3 tag, it also writes new Info tag but encodes the bytes as UTF-8, for [a-zA-Z] characters this makes no difference but for characters that use accents it changes what is written , and É is written as two bytes 0xC3 0x89 which is incorrect. SongKong should not be using UTF-8 encoding to write to LIST chunk. There is no encoding field in LIST chunk, the spec says it uses ASCII but this supports no accents so I think in reality IS0-8859-1 is okay.

For applications that understand ID3 in Wavs this doesn’t matter much because the ID3 tag is correct, but some applications such as Windows Explorer only understand the older Info tag and ignore the ID3 tag , so that is why Windows Explorer is showing the wrong information

But in usual case you wouldn’t be using WIndows Explorer for playing your music would you ?

I will look at this further tomorrow, although the questions remain as to what to do if a want to write a value that cannot be encoded in ISO-8859-1, for example what to do if the information is in Mandarin !

Made a fix to underlying tag read/write lib jaudiotagger so it encodes as ISO-8859-1 instead of UTF-8 (and handles unmappable chars), and that fixed it

However I noticed that Album Artist was also empty, and I assume this is what you were actually referring to when you said album artist was always empty. I think this is because there is not actually an official Info field for this but we write to an iaar field (which was introduced by Media Monkey and became a defacto standard), but Windows Explorer uses its own IAAR field that we dont write to.

I am going to see if feasible to write to both fields

FYI, Quobuz writes its own non-standard fields that nobody else understands, saw this in lib code https://bitbucket.org/ijabz/jaudiotagger/src/master/src/org/jaudiotagger/audio/wav/chunk/WavInfoIdentifier.java

    QOBUZ_TRACKNO("IPRT", null, 17),
    QOBUZ_TRACK_TOTAL("IFRM", null, 18),
    QOBUZ_ALBUMARTIST("ISTR", null, 19),

and when I checked the files you sent me I see they do indeed have these fields defined.

Writing IAAR field doesn’t help, cannot work out any way to get Album Artist shown by WIndows Explorer. If you have any Wav files that do show this value in Windows Explorer please send me file and I will reverse engineer solution, but as it is I will just have to leave this part as found no solutions on the Web, and think maybe not possible with the problem residing with Windows Explorer itself.

Probably do a new release of SongKong next week that will fix the encoding part.

Please Note: The Duration field should not be in the Delete all metadata from these fields list because it is not actually a metadata field written to the file, it is derived from the files audio header. So we have fixed this for new release so that it is not in list, therefore when new release is available you can then simply add all fields.

Paul,
first of all let me thank you for your outstanding support and your ‘groundbreaking research’ on Qobuz tagging/metadata. My suggestion is:
I’ll wait for the new release (including your patch) and will run your suggested 2-step procedure again with the new release. I will then import the processed album into Lightning and we will see what will happen.

I’m really wondering that Lightning DS may not regognize ID3 tags. I’ll clarify this tomorrow by contacting the technical Auralic support. Will let you know.
Anyway, as the functions provided by Lightning DS will be absolutely fine for me (as I don’t need a sophisticated library management like the one Roon provides) I will definitely stick with Lightning DS.

Will you give a short update when the release is ready for download ?
Thanks a lot.

Now fixed in SongKong 8.9 Bleach released 24th January 2023

newest 8.9 release indeed fixed the problem ! THANK YOU

1 Like

Hi, did you find out if Lightning DS only read the older LIST tags ?

Hi, according to the Auralic technical support Lightning DS will read and use the ID3 tag information if available. In case there are additional metadata info in place like the LIST tags they won’t be used.

So you are saying if audio file has both will use the limited LIST instead of ID3, very counter intuitive that, unfortunately we dont currently offer a way to configure to just write one or the other to test it out.

Sorry, my comment was not clear enough. If the ID3 tag is available it will be used by LightningDS exclusively no matter what other/additional tags (like LIST tag) are there.
So, LIST tags seem to be used just in case these are the only tags available.

SongKong always adds ID3 tag so if that was case a corrupt LIST tag should be invisible to you, but anyway if things are now working for you I guess it doesn’t really matter.