SongKong Jaikoz

SongKong and Jaikoz Music Tagger Community Forum

SongKong ignores track number in Naim metadata?

Having created ID tags from Naim metadata files (only), I’m finding many errors where the song titles are in the wrong order in the WAV file ID tag. From what I can tell, this error appears only when the sequence of the song titles is not sequential in the metadata. For some reason the track numbers in the naim metadata files are not always sequential, and where they are out of order these errors appear. SongKong appears to ignore the track number embedded in the metadata and instead follows the order of appearance in the metadata file. With tens of thousands of songs, I need a way to correct this automatically. I don’t want to have SongKong go off to the internet, because that has produced too many errors also. All I need is for SongKong to pay attention to the track number in the metadata when assigning titles to tracks. This seems to be a bug.

Okay not aware of this problem, but you may have found an issue.

But I expect it will be for a particular situation (i.e is it only for some cbbinfo.txt, amginfo.xml or meta.naim files ?). So what I need is for you to give an example of where this has happened, I need both the metadata files and the audio files so probably need to use Google Drive or Dropbox rather than email.

SongKong doesn’t get this wrong very often at all, so if you could give an actual example I should be able to clear that up.

Paul, I am ready to send you some files. WeTransfer is easiest, but I need an email address for you, please.
Cheers,
-Phil

Hi can use support@jthink.net

Screenshots and sample files on the way . . . Watch for an email from etransfer.com.

Haven’t received anything yet.

Thanks for letting me know. The WeTransfer failed. Resent, and this time it said it was successful.

Okay thanks I understand i understand now

So for example in the meta.naim file for Up by Great Big Sea the track The Old Black Rum is the 9th track on the album but it is listed i the meta.naim file as the second file.

    "tracks": [
        {
            "id": "MT0001843150",
            "title": "Run Runaway",
            "index": "1",
            "artist": [
                {
                    "id": "MN0000184208",
                    "name": "Great Big Sea",
                    "role": "primary",
                    "attributes": ""
                },
                {
                    "id": "MN0000184208",
                    "name": "Great Big Sea",
                    "role": "trackartist",
                    "attributes": ""
                }
            ]
        },
        {
            "id": "MT0000816359",
            "title": "The Old Black Rum",
            "index": "9",
            "artist": [
                {
                    "id": "MN0000184208",
                    "name": "Great Big Sea",
                    "role": "primary",
                    "attributes": ""
                },
                {
                    "id": "MN0000184208",
                    "name": "Great Big Sea",
                    "role": "trackartist",
                    "attributes": ""
                }
            ]
        },

But its index value is 9 so we can get in the right order if we use the value of index rather than the order they are listed. In the example files that I have there is no difference so I havent encountered this problem.

Okay I will endeavour to get this fixed for next release - https://jthink.atlassian.net/browse/SONGKONG-2374

Yes, that’s exactly it, Paul. Please notify me directly when the fix is available because I’m holding up my project pending your fix.

For some unknown reason, a significant percentage of my (thousands of) meta.Naim files have the track list sequence not matching the album sequential track order (Metadata lists them 1, 9, 2, 3, 5, etc - but the Index number is correct for each track). I have found this situation in every instance I’ve looked at where SongKong has mis-labeled the WAV tracks after tagging with the box ticked "For Naim WAV files read the accompanying metadata (Melco License Only). The Naim audio server (in my Naim Uniti Core, for example) handles it just fine, but this will be a massive improvement where Naim-ripped WAV libraries are used with non-Naim audio servers.

Okay this is now fixed, please let me know how you get on.

Paul,
That’s an awesomely fast turn-around on the software fix, thanks. I tested a number of un-tagged albums where I know the naim metadata had the tracks listed out of sequence, and it got them all right.

However, it appears that if an album had been previously tagged with incorrect track title metadata, it is not being replaced by the new correct track title ID tags. I tried setting For Songs Already Fully Matched “Update Metadata and FIle Name Only”. No success there. How can I get SongKong to over-write existing WAV ID tags?

In my case, because I was lucky or smart enough to make a copy of the library, I can just delete my old copy and re-do everything. But if someone has run the prior version of SongKong on their library, they will need a way to remove the old tags, or have SongKong over-write them.

Not normally an issue because Wav files are blank to start with and usually would only need to run once but tried it and hit the same problem, do you have Ignore songs previously checked that could not be matched on the Basic tab checked, if so so uncheck and try again, if not please run Create Support Files so i can see your reports and logs.

No, that “Ignore songs…” box was unchecked.

Okay I need your support files then so I can check your config.

Support files are uploading now.

For your testing, Paul, I’m sending you by WeTransfer a couple of albums where the WAVs are incorrectly tagged.

Okay the problem is first we use the meta.naim file to add the album information (e.g Album Artist, Year of Release), then we map the tracks to the right songs and add the track info (e.g TrackNo, Title, Artist). But this second part is failing because we take into account existing metadata in case user has manually entered some data to prevent incorrect mapping messing up existing data, but because the data is messed up from previous run the bad data prevents adding the right data and actually if you click on the Errors and Warnings tab of your report it shows you this.

I have figured out a workaround

You need to remove Title and Track No from the existing data to allow the track match to work, so if you start Fix Songs and add Title and Track No (and Instrument explain later on) to Delete all metadata from these fields

then this data will be removed.

This wont allow the match this time because the data is removed after the Naim match, but if you now start Fix Songs again and remove all those fields from Delete all metadata from these fields it will now work

I noticed there is a minor problem that it re-adds the data for the Instrument field so you end up with the data added twice, we can avoid that we add Instrument to the list of fields to be deleted as well.

Hi, I looked at your errors and warnings for report 7 and found a couple of errors that I have not encountered before

Could you please send me these folders:

F:\Naim Rips - Phil\MQ\Jack Nitzsche\Performance
F:\Naim Rips - Phil\MQ\Lorin Maazel\Wagner The Ring Without Words

so I can replicate and fix issue.

OK, so if I understand this correctly, the way to replace track title errors created by the previous version requires a two-pass process. In the first pass, I set “Delete all metadata from these fields” to “Instrument, Title, Track No”. On the second pass I remove all the fields from the “Delete all metadata from these fields”. That seems straightforward enough - I’ll give it a try.

Re the errors you noticed in my log, the requested folders are on their way to you.

Paul, I have to say, your support is outstanding. Thank you!

Thats correct

Thanks, what is really helping is I ask you for something and you do it or send it and this just makes it so much easier to fix issues, often the main problem is working out what is causing the issue rather than fixing issue, and this usually requires a bit of help from the customer.