I’ve noticed it’s only with some files purchased from iTunes. Further, even within a single album (all songs purchased at the same time), some tracks will error out this way, some will not. It’s random.
The end result is SongKong skips them. Any idea how to fix this? I use another program called Strawberry (a fork of Clementine) that has no problem with these same tags.
Clementine/Strawberry are music players, they only have to read the file in order to play it so if the metadata is slightly corrupted but the audio can be found it can still play the file. Songkong is a music tagger, and do do anything useful it has to be able to modify the file, and in order to do this it has to be able to be able to read the complete file in order to safely modify it.
So I suspect there is error in the metadata in the file, but m4a is a complex format and it maybe the files are valid but SongKong is not parsing them correctly so can you please email one of these files to support@jthink.net investigation.
I think there may be some issue withe the parser, using 3rd party library (Atomic Parsley), its reads to the end of the file okay (although not clear what the last tag is)
Atom free @ 173667 of size: 428499, ends @ 602166
Atom mdat @ 602166 of size: 5519676, ends @ 6121842
Atom ª²y @ 6121842 of size: 36711, ends @ 6158553
But when SongKong reads it, its read the length of last tag incorrectly as a minus number
So I looked at the file and actually that last atom is invalid (not really an atom) so I think MP4AtomicParsley is just using the length of the file and using that to work out atom length, it is not reading the atom length from the file itself.
I then opened the file in MediaMonkey and modified the value of one field. When I rerun AtomicParsely the end of the file now shows
Atom free @ 173306 of size: 428860, ends @ 602166
Atom mdat @ 602166 of size: 5519676, ends @ 6121842
Atom free @ 6121842 of size: 36711, ends @ 6158553
i.e MediaMonkey converted the invalid atom at end to a free atom (i,e free space), i can now load the file in SongKong and process it.
So in summary, for these problem files you could use MediaMonkey (or probably some other tool) to rewrite the file so it is now valid, then can use SongKong. SongKong is not doing anything wrong but I need to see if there is a way I can safetly read file when encounters a corruption like this without the risk of breaking anything when I write to the file.
I should’ve expected nothing less from Apple. The unfortunate part is the affected songs are sprinkled throughout my collection with no rhyme or reason. One album/subdirectory might have three “bad” songs, yet another might be completely clean.
Maybe MediaMonkey can comb through and re-write these hundreds of randomly distributed files easily, I don’t know (I’m a linux user and would have to setup a VM to try it out). But I’d be up for anything that would save me from having to do it manually.
What gets me is these are files straight from the iTunes store. Apple Music purchases – not all that uncommon. How am I the first one to encounter this?
Oh well. Again, thanks for looking into it. I love SongKong and am finally getting the hang of it. If we can get past this invalid atom thing I think I’ll have finally reached music management nirvana.
You could probably use a linux command line tool to add some arbitary tag (that you dont need) to a file, and then script it to run over your whole .m4a lib, that way it should fix it without modifying any valid metadata. But you need to find a tool that can write to these bad files, I dont use linux that much so I dont know about current linux tagging tools.
You could probably use a linux command line tool to add some arbitary tag (that you dont need) to a file, and then script it to run over your whole .m4a lib, that way it should fix it without modifying any valid metadata. But you need to find a tool that can write to these bad files…
Yeah, maybe.
Also, MediaMonkey seems to work well on linux via CrossOver so I’m going see what’s going on there when I have a chance.
I decided to take the MediaMonkey approach to rewrite the files. Well, I didn’t really decide per se. I started in on it as a test and then didn’t stop till I’d gotten through all 1200+ files with the invalid atom.
A brute force way of solving the problem but you were right, it works.
Man, one thing I’ve noticed about MusicBrainz and certain digital albums coming from iTunes – it can come up with some crazy false matches and thrash the hell out them (as in seriously mis-tag). What it did to my Duran Duran “Rio Collector’s Edition” was unspeakable. I tried manually matching with the eval Jaikoz and even Picard. No dice. I finally went into Strawberry and cleaned it up by hand.
Anyway, thanks for figuring out a way to get these files cleaned up. There’s not a single invalid atom left in my collection.
Regarding Duran Duran album, if you are removing existing valid data that makes it harder for SongKong to match. If this problem occurred in recent run of Fix Songs then if you ran Create Support Files I might be able to work out why there was a problem.
Another example is Tubeway Army “Replicas Redux”. I even tried to match against MusicBrainz album by barcode under Jaikoz. I’d gotten the CD’s barcode off Amazon which matched up perfectly with my iTunes files for the same release. MusicBrainz didn’t seem to have an accurate match even with that.
I’m not too worried about it, except I would hate to have SongKong undo my manual corrections later on down the road if I were to “fix songs” across my entire library again.
Maybe MusicBrainz didn’t have the specific release, or perhaps it did have it but not the barcode info. Barcode info is very much incomplete in MusicBrainz, if you can find the right release in MusicBrainz you can within Jaikoz then use Match to Specified MusicBrainz Id instead.
If you rerun SongKong with the default configuration it wouldn’t match to different album if already matched to album. This is based on there being existing MusicBrainz ids metdata fields as used by SongKong, Jaikoz and Picard.
But it may update existing metdata fields with new values if the release metdata on MusicBrainz is different to the metdata in your music file. But you can configure SongKong to Only modify fields if empty so it only adds data rather than replacing existing data.
Sent you a support file on this one. I’m wondering if Apple Music or the publisher was playing games in how they put this digital album together. I.e., did they borrow songs from other albums to assemble a quasi-Rio Collector’s Edition?
Neither SongKong or Jaikoz, if I try and force a match to the specific release ID, will budge. They insist I’m wrong and the songs don’t all match any single Duran Duran release. Maddening.
So I can see the songs are matched to Rio by Duran Duran, but seem to be split over two versions.
Yo cannot currently force a match to particular release in SongKong, however, what happens if in Jaikoz you use Match to Specified MusicBrainz Release Id - that should work, I’m wondering if you are entering the correct id should be 681c9f3a-9132-48a3-8711-a5e070df5cb5
Okay, i cannot see why that was (sometimes tracks are rejected because of track duration but then it should show track duration). But if you run Advanced:Create Support Files and email me the zip file I should be able to see why.
Sometimes I wonder if the real solution is simply to not run MusicBrainz, via SongKong or anything else, against iTunes digital albums. I’ve noticed numerous instances in which it’s jumbled an album into strange groupings of CDs, incorrectly re-numbered and re-named tracks, etc. It’s actually a real mess.
With that in mind, is there a way to configure SongKong to only go after flac files and ignore m4a?
Thanks, okay I can see the general problem. The algorithm basically compares every song file in the grouping against every track on the album to find the best mapping with consideration given to trackno, title, duration, acoustids ectera. There are some optimizations such as if we get a very good match between particular song file and track on release then we assume that is correct and don’t bother checking all the other song file against that track.
In this case we couldn’t find a mapping for al songs/tracks, i.e mapping where every song has a reasonable score against a track, and looking at the logs I think it is likely to be due to the album having multiple versions of each song and that a wrong version of a song was matched to a track early on, and then the other version of the song could not be matched to that track because already allocated, and could not be matched to other version of track.
I cannot see exactly why it failed but if you would like me to delve further you can do one of the following:
Close Jaikoz
Edit Jaikoz.cfg and change
[ArgOptions]
-l
2
to
[ArgOptions]
-l
7
to increase logging
Rerun Test
Recreate Support Files and send them to me
Or even better upload your music files (using Dropbox or similar) then I can use as a test to replicate the issue and devise solution. I’m wondering if removing the optimizations for Match to Specified Release tasks would fix the issue
Workaround, should be able to match using Remote Correct:Manual Correct from MusicBrainz, a semi-automated matcher.
So I expect the issue has been the atom corruption issue, which you have now resolved. The Duran Duran example is a weird one because of the track duplication, I would need to see other bad matches to comment further, but there is no way within Jaikoz or SongKong to filter out particular file types.
Thanks for looking into this. I don’t think there’s a need to go any further with it.
Until I get more experience with SongKong and MusicBrainz I’m only going to run it against one CD at a time. I.e., I find a new CD, rip it, and then use SongKong to tag it. I’ve actually been doing this (had a great used CD haul from a local Goodwill recently) and it’s worked perfectly.
As for iTunes files, I’m not gonna do anymore of them. They already come tagged, albeit not to the level of the MusicBrainz db, and that’s good enough. Whether it’s corrupted atoms or strange Frankenstein albums being concocted from disparate files on the Music Store, they’re not worth the hassle.
My mistake was turning SongKong loose upon my entire collection without knowing much about MusicBrainz or the potential dangers. I know SongKong has “undo fixes” but I’ve just been restoring individual albums from a NAS snapshot as I discover problems.
