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.

HDR photos with a smartphone, built-in versus my own method

On this blog, I have published some examples of HDR photos before, which I created manually by relying on auto-bracketing features in digital cameras and combining the multiple exposure photos using Luminance HDR. One could argue that this is obsolete because pretty much every smartphone camera app nowadays has a HDR feature built-in. As I will show below however, this often leaves much to be desired and it still makes a lot of sense to produce HDR photos the manual way, be it with the smartphone camera or a ‘real’ camera.

My most recent smartphone is a OnePlus Nord, but its built-in HDR is a general nuisance. It only engages when it believes there to be a need for it according to some vague heuristic. Even when it claims to be enabled, sometimes the result shows no HDR at all, probably because it failed to find matches between the images. The latter usually happens when HDR is most needed, when taking photos of sunsets that result in high contrast.

This made me look for an alternative camera app that offers exposure bracketing, such that not only could I make HDR photos when I want to, I can also make them the way I want instead of having to rely on the half-baked algorithm built into the native camera app. I found Open Camera, which proved a great solution.

In this blog post I will compare some HDR photos taken with both the OnePlus camera app (and one with Open Camera's HDR), and HDR photos of the same scene produced with my own workflow, as explained in the article on my website which I recently updated.

Example 1: OnePlus' HDR versus mine. As usual with the built-in HDR tonemapping in smartphones, it tries hard to show details everywhere by pretty much steamrollering the intensities into one flat dull result. The overall image is too bright, lacks saturation, and does not represent the scene how I experienced it. My HDR image might look a bit dark in comparison, but it much better represents the sensation of the actual scene when viewed in its own on a big screen.

Example 2: again, the OnePlus HDR makes things too bright and it looks more like a daytime shot with some colour filter than a shot taken at sunset.

Example 3: same remarks as above.

Example 4: again, the OnePlus HDR makes the sky a dull mess, while all the interesting things are happening there.

Example 5: this time, the OnePlus HDR has roughly the same overall brightness as mine, but local details are lacking, especially in the darker areas where everything is just clipped to black.

Example 6: here I first show the result from the OnePlus camera app, then the built-in HDR of the Open Camera app, and finally my own HDR. The first 2 are similar although the Open Camera result has some artefacts that I sometimes also experience with Luminance HDR when I didn't use a sufficiently large range of exposures to capture all intensities in the scene. But again, the automated HDRs are too bright and have a yellowish tint that does not correspond with how I experienced the scene.

Example 7: again OnePlus versus mine, and again the colours in the OnePlus image are washed out and despite its overall higher brightness, details in the darker areas are lacking compared to my image.

Example 8: (added 2022/08/14) this was a particularly challenging image due to the enormous dynamic range. Obviously, the OnePlus app only takes 2 or maybe 3 photos with a rather limited exposure range, and lost the subtleties in the sky colours. The result looks harsh and overly bright. I switched OpenCamera to 5 shots with an exposure range of ±3 stops, which allowed to capture the scene as it was. I had to tweak saturaton more than usual to end up with a result that matches how I experienced this scene in the real world.

Conclusion

Again, if you want to make HDR photos the same way as I do, check out the article on my website. One of the things that makes it fun to process one's own HDR photos, is the fact that it brings back a bit of the magic that used to be experienced when taking photos on film, and only seeing the results later on when the film had been developed. It is not exactly the same thing, but producing the HDR image from the raw bracketed photos does have a bit of a feel of “developing” the images.

Making G'MIC Qt GIMP plug-in work in the 2.10.30 Mac version

If you are using the G'MIC-Qt plug-in for GIMP on Mac OS, especially the one from aferrero2707, you may have encountered this error after upgrading to a recent GIMP build:

GIMP says: “Plug-in crashed: "gmic_gimp_qt",” and warns about the dying plug-in possibly messing up GIMP's internal state.

Running GIMP from the Terminal yields a bit more information:

dyld: Library not loaded: @rpath/libintl.9.dylib

  Referenced from: /Users/username/Library/Application Support/GIMP/2.10/plug-ins/gmic_gimp_qt

  Reason: image not found

The Resynthesizer plug-in build from the same author suffers from the same problem.

It seems that these builds of the plug-ins rely on the presence of a dynamic library file ‘libintl.9.dylib,’ most likely in the GIMP application bundle itself. But, my current build of GIMP only includes libintl.8.dylib. Judging from a related issue report on GitLab, there never has been a true version 9 of this library and the number 9 was due to a mistake in the gettext library, which explains why the version number seemingly decreased.

Until someone creates a new build of the plug-ins, there is a relatively straightforward workaround: shove a copy of the libintl file into the G'MIC and Resynthesizer plug-in library folders, and give it the expected name. This ensures the plug-ins will always find this library regardless of what is in the particular build of GIMP.

There are 2 ways to obtain the dylib file:

1. [Slightly harder for those unfamiliar with low-level workings of Mac OS]
   Open your GIMP application bundle (either by right-clicking the app icon, or by using the Terminal), and find the libintl.8.dylib file, normally in Contents/Resources/lib/.
   Copy this file and rename the copy to libintl.9.dylib.
   This works because there is no significant difference between the version 8 and purported version 9 of the file.
2. [Easier but not that safe]
   Directly download it from wherever you find it on the web, and hope it is trustworthy. (This particular one works for me, it is 77584 bytes in size and has an MD5sum of 2a88ed7a2d8901fd0e75401e761b24d2.)

Place the libintl.9.dylib file inside the GMIC/lib folder where you installed the G'MIC plug-in, most likely ~/Library/Application Support/GIMP/2.10/plug-ins/GMIC/lib/, then restart GIMP and it might work.
Same for ResynthesizerPlugin/lib/.

Black & Decker 90515265 blade clamp can be used on the POW 1004

In a nutshell: you can use the Black & Decker 90515265 blade clamp as a spare part for the Powerplus (Varo) POW 1004 jigsaw.

This blade clamp on my old POW 1004 crumbled into pieces when I tried to use the saw after it had been sitting idle for many years. The part is made from the typical cheap metal alloy that is often used for casted parts. I don't know what metal this is, but it is like the equivalent of papier mâché and it seems to degrade over the years.

I was about to toss the whole saw because it was very cheap anyway, but I did a quick search for spare parts anyhow. I didn't find any spares for it, but this 90515265 Black & Decker part kept popping up amidst the results and it looked awfully similar in shape. I took the gamble and ordered two. Lo and behold: it just fits. It has an extra protrusion that makes it a tight fit and I milled just a tiny bit off the saw's body just to be sure, but this is not actually necessary.

I guess the reason why this fits is because many of these cheaper saws use the same internal components from some generic Chinese manufacturer. Not sure if this poorly made clamp part is a case of planned obsolescence or just poor design, but anyhow now we know how to avoid another piece of e-waste.

The B&D part looks much better designed with some extra reinforcements, but I still recommend not to overdo the tightening of the saw.

(and now in Dutch…)

B&D 90515265 zaagklem past op de POW 1004

In een notendop: u kan de Black & Decker 90515265 klem voor zaagblad gebruiken als vervangstuk voor de Powerplus (Varo) POW 1004 decoupeerzaag.

Deze klem op mijn oude POW 1004 verbrokkelde totaal toen ik de zaag probeerde te gebruiken nadat hij een paar jaar ongebruikt was gebleven. Dit onderdeel is gemaakt van de typische goedkope metaallegering die vaak gebruikt wordt om gegoten vormen te maken. Geen idee wat voor metaal het is, maar het lijkt het equivalent van papier-maché en schijnt bros te worden over de jaren.

Ik stond op het punt de ganse zaag weg te smijten omdat hij toch goedkoop was, maar ik besloot desalniettemin een snelle zoektocht te doen naar reserve-onderdelen. Ik vond niks voor dit model, maar dat 90515265 Black & Decker onderdeel bleef terugkeren in de resultaten en leek wel heel hard in vorm op het kapotte deel. Ik deed de gok en bestelde er twee. En kijk eens aan: het past gewoon. Er is een extra uitstulping waardoor het erg dicht bij de behuizing komt, en voor de zekerheid heb ik een klein beetje van de plastiek weggedremeld, maar dat was eigenlijk niet nodig.

Ik denk dat dit past omdat veel van deze goedkope toestellen dezelfde ingewanden gebruiken van een of andere generieke Chinese fabrikant. Ik kan niet zeggen of deze slechte klem een geval is van geplande veroudering, dan wel of het gewoon een slecht ontwerp is, maar nu weten we in elk geval hoe we nog een stuk e-afval kunnen vermijden.

Het B&D onderdeel lijkt veel beter ontworpen met extra verstevigingen, maar ik raad toch aan om het niet te hard aan te vijzen.

Apple made system calls horribly slow in the 10.14.6 update. Thank you, Apple!

After installing the Mac OS 10.14.6 update from the end of September 2020, I noticed something wasn't right. A simple Perl script that scanned a directory for all files and that invoked the stat system command for every file, had become way slower than before. I'm not sure if the same would have happened if it had relied on Perl's own stat() call, but this script needed the shell command because it can offer information that Perl's own stat couldn't provide.

Also when running a homebrew update, it seemed way slower than usual. It looks like Apple had messed something up w.r.t. system calls from within scripts, and perhaps other programs as well, although I didn't notice anything in regular apps. I knew this was likely to be reported by a gazillion developers and fixed soon, so I didn't bother. That horribly slow script of mine was annoying though, so I started seeing if it couldn't be improved.

The problem here was that the Perl script did the obvious thing of invoking a new instance of stat through backticks, for every single file it encountered. That's a lot of overhead. Until now the overhead wasn't bad enough for me to be sufficiently annoyed, but Apple's “update” had now pushed this way into the zone of bad words and gnashing teeth. The solution was pretty obvious: reduce the overhead by reducing the number of system commands. Luckily this could be done: the stat command does accept multiple files as argument, and returns the results as multiple lines in the same order as the arguments.

So, all I had to do was postpone the invocation of `stat` and build a queue of file paths, and execute the aggregated system command whenever it reached a certain size. In theory I could wait until the command line was about to exceed 262144 bytes (minus some margin to allow environment handling), which is the maximum system command length as reported by “getconf ARG_MAX.” In practice, I used a lower limit of 16 kBytes because above a certain threshold, the gain becomes pretty negligible anyway.

The result was that for a particular run, the script went from a 120 second runtime to 3 seconds. After Apple fixed the performance issue in a supplemental 10.14.6 update, the runtime became sub-second. So in the end I guess I should thank Apple for forcing me to refactor my script and making it way more efficient. Maybe every operating system should now and then introduce a temporary penalty on certain operations, or a limit on resources, just to force developers to be less lazy and actually improve their software instead of writing sloppy code and letting the machine just brute force it…