How to have a reasonable chance at getting correct album art in Mac OS Apple Music

TL;DR

Ignore the naysayers who claim it has nothing to do with the iTunes music store—they are wrong. Look up the album in iTunes and set the album title for your local files to the exact same title, with junk like “(Remaster)” and so on included. Then clear the artwork and download it again. Afterwards, you can rename the album back to what you want. If this doesn't work, then it will never work for that album, so stop wasting your time.

The Long Story

I still use Apple Music, the former iTunes, to manage an offline music library. I have never bought into the streaming game. It sucks for many reasons that I won't explain here. What also sucks, is how Apple Music handles album art, especially for music that has been ripped from CDs or obtained from somewhere else than the iTunes store. Very often, the album art is plain wrong. It will generally be from the correct artist, but older albums will often get the cover art of a very recent release, or a stupid compilation. I don't care about compilations, I want to know what album a song originally came from.

The cover art matching algorithm has always been bad, from the earlier days of iTunes to the latest Music app release in Mac OS Sonoma. The way in which it makes mistakes has changed over the years, but it has never made any sense. I would like to have a chat with the person who implemented it. I wonder how their mind works—if it works at all. Anyone with some vague sense of logic and a bit of programming experience can come up with a better algorithm than the current one.

And please don't tell me to add my own cover art by pasting it into the info window. Ever since it was first introduced in ID3 tags, I have hated this concept of copy-pasting the same JPEG or PNG file into the metadata tags of every single track of an album. What if I have an album with 50 tracks? Do I really need to duplicate the same image 50 times? That is conceptually idiotic. Album art should be stored once and then linked to the relevant tracks. It does not belong inside the music files themselves. This is one upside from how the artwork download system in iTunes/Music handles it, because it does exactly that: download a single file and then link it to each track. Now if only it would download the correct file…

Anyhow, I'll stop my rant and cut straight to the chase. How can one fix missing or incorrectly matched artwork even when you know the album is in the iTunes music store? After some experiments, I have found a way to fix some of the blatantly wrong album covers. For instance, practically all my Dire Straits albums got the same cover of some recent Mark Knopfler compilation with a red Stratocaster on a blue background. When using the “Show in iTunes Store” option on songs from those albums, it will indeed always send me to that compilation album in iTunes. However, the actual correct albums are also in the store. However, they will often be remasters, or “bonus track editions.” The title of the album in the store is for instance “Communiqué (Remastered),” while in my collection it is simply called “Communiqué” (because I care as much about what particular remaster a track came from as I care about compilations—I don't give a 💩.)

Therefore, despite many people claiming that the cover art matching has nothing to do with the iTunes store, I decided to clear the wrong artwork, rename the album to “Communiqué (Remastered),” and try to download the cover art again. And behold, it works. (Of course afterwards I restored the original album name.) The same worked for Neko Case - “Fox Confessor Brings the Flood,” which I had to rename to the silly “Fox Confessor Brings the Flood (Bonus Track Edition)” because that is the version which is available in the iTunes store.

The bad news is that this does not always work. For the Belgian band dEUS, it is totally hopeless. The matching algorithm gets stuck on linking all albums to Following Sea. I have no clue why. Again, I'd like to see the implementation of this “algorithm”—I really could use a good laugh. How can it be so bad? How can it break on stuff between brackets? Anyone who takes a quick glance at album naming should know that if something doesn't match exactly, but it does match when omitting stuff between brackets, it is likely a good match. And what about just giving the user the option to pick the correct match from multiple options if there is ambiguity? Oh no, that is totally un-Apple of course, because everything needs to be dumb and simple. Apple expects all their users to be dumb and simple.

It is rather obvious that Apple doesn't care about the ever shrinking niche of users who want to manage their own music library. This fares against their streaming income model. I even suspect this is why they subtly break functionality in the Music app, or refuse to fix bugs, like the failure to update the last played status in many cases, or the hiccups that make the whole Mac OS choke every 7 seconds when playing music on older Intel machines—see my older blog post about this.

Anyhow, if you are as masochistic as me and want to stick to the Music app to manage an offline music collection, now you have at least some chance to fix some of your broken artwork. However, it is likely I will not only ditch the Music app for something else, but the whole Apple ecosystem in the near future, because I have figured out that I have switched to open source alternatives for pretty much everything lately. Ironically, iTunes/Music was one of the few remaining things that I liked and kept me on the platform, but since they are now also enshittifying this, it leaves me with no real reason to stick with MacOS…

What is the point of these bots endlessly trying utterly random HTTP requests?

I can't be the only one seeing this kind of garbage in my server logs:

"GET /!?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /HotelInformation/HotelInformation.aspx?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /++?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.cancel?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.specialSubmit?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /img.youtube.com?asdas1230ds0a=da90sue21qh HTTP/1.1"
"GET /.droppable/?asdas1230ds0a=da90sue21qh HTTP/1.1"
"POST /.droppable/ HTTP/1.1"
"GET /_isMasked/?iqi_localization_country=x27f&vst=x27f&gitlab=x27f&1111ef1ee11b=x27f&ocxlaarct7tk=x27f&gad_source=x27f&landcode=x27f&confirmPrivacyStatement=x27f&26=x27f&frm_action=x27f…"

This is just a tiny sampling of endless junk that has been going on for at least the past 2 weeks. The last example is abbreviated, it goes on like that, with exactly 100 of those random query parameters that always have the same value “x27f.” It are several bots, which according to an IP locator service come from different countries, mostly the UK and Hong Kong. However, doing a WHOIS on each of the IP addresses reveals that many of them are hosted by Contabo GmbH, a cheap VPS hosting service in Germany.

Something similar has happened years ago, and then the junk also came from Contabo-hosted addresses. The pattern was similar, but each request then looked like the last example shown above, using a ridiculous number of query parameters with different field names but all the same value “z3re”. I filed an abuse report back then, and the junk stopped for a while, but it has been sporadically returning, and now it is back in a slightly different incarnation, but it still makes no sense at all. NONE.

Often these bots will still perform requests with a ridiculous number of parameters (usually 100), but more often they look like the above: a random string with the same damn query string appended to it. I really mean the same damn string for at least 2 weeks straight, which in the above case was obviously produced by someone bashing their keyboard: “asdas1230ds0a” and “da90sue21qh”. The same bot will keep on doing requests with the same base path like “.specialSubmit” or “London” for a whole day, and then might switch to another string for the next day, if I haven't kicked its ass with an iptables DROP in the meantime. The choice of these strings generally makes no sense. Lately they have also started using random characters next to city names and domains or just random words. Most of the time, the strings don't look like anything a real web app would ever use. It is all totally random. The mind boggles.

I really don't understand what is being tried to achieve with this. It is as if they are trying to brute force the internet in the hopes of finding an exploit, but the chances of this strategy producing anything fruitful is negligibly small, especially when not even varying the query parameters. Also, they do only 1 request about every 10 minutes, maybe to try to stay under the radar of suspicious activity detectors (not mine, obviously). At such slow rate, a Monte Carlo approach is just pointless.

I truly cannot grok what could be going in in the mind of whatever crackpot implemented this piece of junk and then decided to pump Kilowatts into a server farm to unleash this nonsense across the internet. If I see this in my logs, then it probably means they do these requests non-stop on whole IP ranges or a list of domains obtained from wherever. All that electricity is wasted on total nonsense. They had better spent the effort on mining crypto. It must take a very special kind of mental deficiency to believe this strategy will yield any return on investment.

Luckily the incomprehensible act of always using the same strings in the request, makes it easy to ban these bots. The set of IP addresses they work from is also pretty stable, so firing up the firewall is a good option as well.

The Music app in Mac OS 14 Sonoma causes pauses in the whole rest of the system

TL;DR: if you encounter hiccups in the MacOS UI or general sluggishness while playing music, first of all upgrade to Sonoma 14.5 if you can, because this bug seems to be solved REDUCED in that version. The bug will still occur after a while though. To avoid it, close the Music app window, OR open any program that uses 3D acceleration of any kind, OR disable automatic graphics switching in System Settings. it will make the hiccups magically vanish.

My MacBook Pro “upgraded” itself to Mac OS Sonoma during a routine reboot, without my consent. This wouldn't be that bad if this new release of the OS would not be riddled with bugs. One apparent bug was that when the Music app starts playing the next track, and the display is sleeping, there would only be an empty notification temporarily waking the screen, with nothing else in it than the Music icon and the word “Music”. In previous releases this would show full song information as expected. Eventually I figured out that this is a ‘feature’: one needs to give the Music app explicit permission to show information on a “locked” screen, even though the screen is not actually locked in my case. Why it is then still allowed to show a pointless empty notification, beats me. Apple is starting to adopt Microsoft style logic.

Anyhow, on to the true bug that is the main topic of this post, and it is a bad one. It is quite simple:

• Playing local M4A or MP3 files will cause the whole system UI to freeze during about 1 second, approximately every 7 seconds. EXCEPT the Music app itself, which somehow remains immune against theze hiccups. Otherwise you will notice this by things momentarily hanging while scrolling, typing, or doing anything else that requires smooth updating of the screen (even video playback will stutter).
• Playing an internet radio stream will cause same UI freezes, but only when the metadata in the stream causes the status display in the Music app to change. For instance, if the stream contains artist and title information, you can expect everything to choke at the start of every new song. Somehow I have a knack for finding these weird correlations, I don't know why, but it only took about 4 occurrences to figure this out, then I confirmed it by doing some explicit tests.
• These nuisances only occur if the Music app window is open. Close it and the hiccups no longer occur. Of course I mean closing only the window, not quitting the whole app (which would obviously fix any problems caused by the app running).

I don't even know what could cause this. The days when playing an MP3 file required almost all CPU resources of a machine, are way behind us (I still remember one of my friends boasting about this with his 4/86). This seems like some kind of real-time priorities problem, or some UI rendering bug. The 14.3 update mentioned something about a performance problem with UI rendering, but alas, it definitely did not fix this bug because I still encounter it in Sonoma 14.3.1.
I bet it has something to do with all the unwanted security and privacy junk that is being poured into the OS, I wish there was just a big master toggle switch in the control panel “I am not an idiot, don't lock down my computer” to disable all this stuff.

How this kind of bug can have slipped through QA, is beyond me. I guess they don't really test playing local files anymore, assuming everyone will be happy to move to stupid streaming services that produce a steady revenue and that can be manipulated at leisure. However, I find reports in many places of Sonoma being sluggish and unresponsive, and I suspect that the Music app is not the only one causing this. It must be some deeper-level problem of which this is only one manifestation.

Update 2024/03/23: this is definitely some kind of rendering problem.

After some more experimenting, I found out that leaving certain other apps open, will also avoid the problem, even if the Music app window is visible while it is playing music. The magic apps that avoid the problem, are the ones that use OpenGL or some other kind of 3D acceleration. For instance Blender or OpenSCAD will do the trick, and even SheepShaver because it also relies on OpenGL as far as I can remember from when I was remotely involved in its development. Now I can only hope someone at Apple reads this and it gives them a clue about how to fix it…

Update 2024/05/15: it's the Intel Graphics.

With the help of the above, I figured out that the problem only occurs when the Intel Graphics GPU is being used while the Music app is playing music. Yes, it makes no sense from any rational point-of-view that playing music will slow down the GPU, but I have the experimental evidence to prove it. This means there is a simpler workaround than to keep some app running that causes the graphics to switch to the discrete Radeon or NVidia GPU. Go to System Settings and in the Battery section, click the Options button and disable “Automatic graphics switching.” This will cause the discrete GPU to be always used, and the sluggishness will be gone. This will of course affect battery life, so you may want to re-enable that option when battery life matters.

Update 2024/05/23: it's finally fixed… NOT!

After upgrading Audio Hijack to the newest version, it behaved really poorly, with audio regularly cutting out while coreaudiod crash reports appeared. After contacting Rogue Amoeba, they told me that the freshly released Sonoma 14.5 should contain improvements to audio handling. Needless to say, I upgraded right away—things could hardly get any worse. And everything seemed fine at first: not only is Audio Hijack now running smoothly, the main problem explained in this blog post also seemed to be gone! No more hiccups when playing music without doing all kinds of weird workaround dances. Sonoma finally feels usable again.
However, after a few days the problem has returned. This bug will never get fixed, because it's one of those semi-random bugs from hell that only manifest themselves after a certain time in very specific environments. I guess MacOS has become such a massive piece of bloat that it starts producing this type of bugs which are a total ordeal to reliably reproduce, let alone fix. I suspect the actual problem may be some kind of memory leak that eventually causes data to be constantly hauled between the main system and GPU. Luckily the workarounds described above remain effective.