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…

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.

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…

The Dreaded Butterfly Keyboard: trying to postpone the inevitable

In a nutshell: If you have an Apple MacBook Pro or other machine with the dreaded ‘butterfly’ keyboard and it starts to exhibit problems, you options are:

• If you experience the problem of a certain key sometimes not reacting, try detaching the keycap (important: do not try this without first reading the “How to” section below for instructions). After looking—with a magnifying glass—for obvious dust, hairs, or crumbs and carefully removing any with precise tweezers, blast the mechanism with air from multiple directions, and reassemble the key.
• If you experience the problem of a key producing multiple keystrokes per press, first do the above, and after reassembling the key, hit it many times as hard as you're comfortable with. Just type a piece of text like a madman, and there's a good chance that the key will behave afterwards.
• If the above doesn't help, or problems occur too often, or you are not comfortable with taking the keys apart, and you have bought the machine less than 4 years ago, your better option is to go for the Keyboard Service Program.

The full story

A few years ago I was kind of forced to buy a new MacBook Pro, because my previous one, a 2011 model, had the dreaded GPU failure—another design flaw by Apple albeit lesser known than the keyboard debacle. Given the high price and the rumours about the bad keyboard, I seriously considered buying a Thinkpad or other PC laptop, but it looks like I am still too much locked into the Apple ecosystem to take that step. I hoped that the newer design with the extra silicone ‘flaps’ built into the keyboard, would make it reliable enough that it wouldn't develop problems in the situation where the MacBook Pro would be sitting 95% of its lifetime. But that was too much wishful thinking.

Even despite the fact that this laptop sits on a Griffin Elevator in a normal room with regular levels of dust, some keys did develop problems within less than one year. The down arrow key was first, it would sometimes miss a press. Then the same started happening with the Return key. I found a very useful page on iFixit Answers that showed how both thes keys were assembled, and this allowed me to detach them without destroying them. I then blasted the insides of the mechanism with air like crazy, and that has effectively remedied this problem.

A while later however, another problem started showing up: some keys, especially the ‘E,’ started producing double and sometimes even triple presses. The extra press would often come late enough that typing ‘bed’ could result in ‘bede.’ I again took off the ‘E’ key and inspected the internals, but all I found was a tiny hair that was only visible with a 10× magnifying glass. I gave the key the same treatment as the others, but it kept on exhibiting the multiple keystrokes problem.

It seems to me that this key repeating problem is not caused by dust particles. It rather looks like the contacts become unreliable, maybe due to an oxide layer forming on them? The keyboard can become pretty hot when the machine is under heavy load during an extended period, like when running a modern game. Maybe this degrades the contact surfaces? This theory is further corroborated by the fact that I eventually did manage to make this problem go away, by simply punching the key much harder than usual. Percussive maintenance does work, even on delicate modern machines…

The good news is, after a class-action lawsuit, Apple has started a repair program that allows to bring in your machine if it obviously exhibits these problems with the keyboard. They will then replace the keyboard, which usually means replacing the whole top assembly. As explained in this video by Louis Rossmann, theoretically it is possible to replace only the keyboard, but only with very specialised tools because the thing is actually riveted into the case and in many machines you need to detach the glued-in batteries without rupturing them and setting your workshop on fire.

And by the way, I fully agree with Rossman that I expected a machine this expensive to at least be as reliable as a much cheaper one with similar specs, and also much more serviceable. Where are the days when Macs were modular machines that could be entirely taken apart without even needing a screwdriver?

Even though the repair program is free, the downside of course is that you will have to do without your computer for a few weeks. So if you are only having mild problems with the keyboard, it may be a better option to first try to remedy it yourself, but only if you feel confident enough that you won't make things worse.

How to detach the keycaps without destroying them

If you want to have an attempt at detaching the keycaps yourself, BE VERY CAREFUL. Do not simply yank on the caps from any direction, or you will break little hooks and the cap will be forever loose. The trick is to slide a thin piece of plastic in between the cap and the butterfly mechanism (see SHOVE in the pictures below). Do not go too deep, try to keep the plastic as horizontal as possible to ensure it does not go under the butterfly hinges themselves. Then shift the plastic towards the clips (called slide in the pictures) to detach them. For most of the regular keys, the cap is attached with two clips at its top end, and two hooks at the bottom. For these keycaps, start the SHOVE in the middle of the left and/or right edge, as indicated with the arrows in the photo below, then slide upwards. Once one of the clips is detached, you can usually keep sliding across the upper zone of the cap to detach the other clip as well.

A piece of cut-up blister packaging works well for this purpose, but a thin guitar pick (plectrum) should also work well. The longer keys like backspace will typically have 3 clips instead of 2.

For other keys, the procedure differs only in the place where you have to shove the pick and in which direction you should then slide it. For the ‘up’ arrow key, the clips are at the right. For the ‘down’ key, the clips are at the left. For the tall European style of Return key, the clips are at the left, and there are 3 of them. I have borrowed the photos from the iFixit page to illustrate this. Note how the whole mechanism of the return key has been detached in this photo, this is not how it is supposed to be.

To reassemble, slide the hooks back in their place, then re-engage the clips by pressing on the zone where they reside.

The space bar is notoriously difficult. If you feel you need to take it apart, consider going for the Apple repair program instead. If you break things, you won't be able to benefit from the free repair.

And of course, the usefulness of the repair program is very debatable. The replaced keyboard will suffer from the same flaws. I wish there would be a replacement program where I could exchange my inherently flawed MacBook Pro for a considerable rebate on a late 2019 MacBook Pro with its reliable scissor keyboard.

A final piece of advice

If it isn't already obvious: never do anything in the vicinity of your butterfly keyboard equipped machine, that could cause any small particles to fly around. Or, cover the keyboard with a sheet of paper if there is any such risk.

Recently, the backspace key started acting up. Something had obviously got inside the mechanism, but with the naked eye I couldn't see anything suspicious. Even after repeated sessions of removing the key cap and blowing air, it kept feeling strange and sometimes did not respond to presses. I then took a flashlight and magnifying glass, and finally saw that some tiny piece of something had got under the mechanism. It was a pain to remove because Apple's silicone flaps that were supposed to keep junk from getting inside, now made it hard to get the junk out. I eventually managed it with extra fine tweezers, and it proved to be a tiny piece of clipped fingernail any other keyboard wouldn't care about. So, don't clip your fingernails in the vicinity of the keyboard…

True Tone display abruptly changing tint? Try not covering the sensor!

On various forums, one can find complaints about the True Tone display of the more recent MacBook Pro models suddenly changing tint, or the intensity of the screen flickering. Some of those forums will tell you to disable the True Tone or Night Shift feature. If you don't care about those features, it's an effective workaround, but it is kind of stupid to buy a machine with all these advanced features and then disabling them.

I have also experienced this, and found no rhyme or reason behind it—until now.
I'm pretty sure there are some other causes for this problem, including hardware or software faults, but before you go bringing your MacBook Pro to a service center, you might want to check the following first.

Many people cover the camera built into laptop screens with a sticker or something else, for reasons of privacy and/or security. The problem is that the True Tone sensor is very close to the camera. If your sticker is large enough, it will partially or fully cover the sensor. Even if that's not the case, maybe you often do use the camera, and then have to park the sticker somewhere, and a convenient place is right next to the camera—possibly right on top of the sensor.

When covered, the sensor will receive much less light than it should, possibly filtered in some strange way, and this can cause the True Tone system to react wildly to tiny changes in ambient light. I still don't understand why the adaptation algorithm allows such quick changes at all, but one can't really blame the system for starting to act weirdly in a very poorly conditioned situation.

The sensor is very hard to see, which is why most people are unaware that it exists at all, let alone avoid covering it. On my MacBook Pro model (2018 15 inch), the sensor proves to be at 17 mm to the right of the (more visible) camera, as can be seen by shining a strong flashlight across it. You may want to verify on you particular machine where the sensor really is situated.

So the morale of this story is: if you have any thingamajig that covers the camera, make sure it stays well away from the sensor. If you then still have strange variations in the tint of the display, then you may start worrying about a deeper problem. As a matter of fact, in my case the problem still occurs occasionally. It looks like the sensor gets confused in situations where there is little light, or rather weak light coming from a direction mostly parallel with the screen surface. What usually helps in such cases, is to provide a stable source of light closer to the computer, so just turn on a lamp.

Making Prosoft Hear work again with iTunes 12.6

The only reason why I stick with iTunes is that I have been suckered into it from the start when it still was a pretty good application for managing an offline collection of music files. Lately, the app has shifted towards cloud-based stuff and artificial stupidity algorithms that try to suck all the joy out of being your own virtual DJ. It is still usable for its original intent however so I haven't tried to move to an alternative… yet.

Lately, Apple has done two more stabs at endlessly annoying me and making me regret that even my alarm clock is tightly coupled to iTunes by means of Koingo's Alarm Clock Pro. The first thing they did was break the visualizer plug-ins, in the typical Apple fashion that has since many years made me shy away from developing anything specific for OS X. This fashion is of course doing it in total silence, without warning anyone or even mentioning it in the release notes. Starting with iTunes 12.6 the visualizer menu simply only shows the two built-in visualisers, ignoring any installed plugins. I am pretty glad I never took the effort to polish up my now obsolete Spectrograph plug-in. Maybe I unconsciously saw it coming.

The second thing they did, and what this post really is about, is that they also broke the Hear audio enhancer from Prosoft. I heavily rely on Hear to make listening with headphones more enjoyable. When properly set up, Hear can make even the cheapest headphones sound like expensive Sennheisers. Or in my case, make mid-priced Sennheisers sound like an explosion of aural bliss. It can also squeeze extra fidelity out of simple Bluetooth speakers or other sound systems. Great was my frustration when I noticed the controls had no effect anymore after iTunes had sneakily upgraded itself to 12.6.1, and it was even greater when I saw on the Hear product page that Prosoft officially does not support iTunes anymore. That's right, they admit that their product primarily geared towards enhancing your music experience, does not work with the de facto standard for music playback in Mac OS. I commend them for that, but it doesn't make the fact less annoying.

My guess is that iTunes has become yet another application in the row of ‘sandboxed’ apps like Safari, which are nailed shut to avoid exploits from malware and the like. After all, iTunes is linked to a store and the store is linked to credit card details. Why this also has to break the ability to manipulate the audio stream, beats me. I contacted Prosoft and they are looking if the problem can be fixed, but I'm not sure if they'll be able to circumvent the sandbox restriction.

However, I noticed that applications like Nicecast still work fine with iTunes. This made me pretty confident that I can still make the audio go through Hear after all, albeit by means of a pretty clumsy roundabout. And indeed, after the necessary cursing and kludging I made it work as follows.

Making it work

The strategy is quite simple: re-route iTunes' audio output through another non-sandboxed program that plays the stream on standard output. We can do this by means of two different free, open source projects: SoundFlower and Audacity.

1. First install SoundFlower, the current 2.0b2 release from mattingalls' GitHub seems to work fine, at least in El Capitan. Don't bother with trying to get the Soundflowerbed application to work, you don't need it.
2. In your Sound system preferences, set the ‘Soundflower (2ch)’ device as output device.
3. Open Audacity and select the ‘Soundflower (2ch)’ device as the microphone device. Select the ‘Built-in Output’ as your output device.
   
4. In Audacity's preferences, Recording, enable ‘Software Playthrough’.
   
5. Drag both the input and output volume sliders in the top-right corner of Audacity's main window to maximum. Now press ‘Click to Start Monitoring’ and start playing some music. You should see Audacity's VU meter start to move, and hear the sound as usual. You may need to give the Hear control panel a kick by toggling the on/off button or nudging a slider to make it hook itself to the audio output, but it should work.
   

Of course this has some disadvantages, like needing to keep Audacity open, and a noticeable extra delay on the audio as well. You will have no sound at all if you break any component in the whole chain. This can be pretty annoying if like me, you use your Mac as an alarm clock (it will be trying to wake you with silence which results in you being late for work). Moreover, when you switch back to direct playback through internal speakers, two things require attention. First, your volume will be at 100%, which can lead to unpleasant surprises if you forget to turn it down. Next, when you have switched back to internal speakers in the Sound control panel and plug or unplug something from the headphone jack, OS X will once more switch back to Soundflower output, and you must again select internal speakers.
In other words, not only do you need a whole ritual to set up this workaround, you also need to do a little dance to tear it down. For all these reasons I hope Prosoft manages to find a solution. I wouldn't mind if it would simply implement this workaround under the hood and have some extra delay, if only it is reliable.

This hack does have some extra advantages however, for instance Hear will also work with Safari or any other sandboxed application's audio. And, if at any time you would want to record what's playing, all you have to do is hit the record button in Audacity.

iTunes 12: hacking the playlist font sizes

In iTunes 11, there were only two options for the font size in list views. The ‘small’ size corresponded to a font size of 12, the ‘large’ size was 15. It was possible to change these font sizes by editing the TextStyles.plist file (for your specific language) inside the iTunes app bundle. The two relevant keys were 9002 and 9003.

In iTunes 12, the old choice between three list sizes was reintroduced. However, the font sizes associated with ‘small’, ‘medium’, and ‘large’ have been assigned dubious values: they are 11, 12, and 13 respectively. There is even less difference between smallest and largest than in iTunes 11. The row heights do change quite drastically, resulting in an overly spacious display for the large size.

Editing the same keys in the plist as before has no effect. After looking around a bit, I found the keys that are currently used: they are respectively #17920, named “Label” (this is actually the large size), #18688, named “Label_Medium”, and #18944, named “Label_Small”. It may be necessary to edit the other keys with similar names to get a consistent result. For instance, to revert the ‘large’ size back to its former 15 point size, you would need to ensure the Label, Label_Emphasized, etc. entries look like this:

        <key>17920</key>
        <dict>
                <key>- loc hint -</key>
                <string>Label</string>
                <key>font</key>
                <string>_HelveticaNeueSystem</string>
                <key>size</key>
                <integer>15</integer>
        </dict>

Of course, this hack needs to be re-applied after every iTunes update. You may want to keep a backup of the edited plist file so you can simply copy it (although you should check whether no other values have changed in the update).

Watch Phones, Smartwatches, and the iWatch

Recently some rumours about an Apple “iWatch” have popped up, and many people thought the idea of an internet-enabled communication device on one's wrist is something novel. Not really: so-called watch phones have existed for more than ten years. Of course, the first ones were clunky and barely went beyond prototype stage, but there have been widely available and quite usable watch phones for more than five years. Most of them originate from China, and can be bought in various places for reasonable prices. My main cell phone has been a watch phone since June 2008.

The main problem with pretty much every watch phone that currently exists however, is that it severely lacks in a certain way. And for some reason, whenever a manufacturer produces a new model that improves upon certain features, it gets worse in other features — I dubbed this “the law of conservation of suckiness”.

In a new article on my site, I shortly discuss the history of watch phones, what is good and bad about past and current models, why the concept of smartwatches that need a smartphone makes no sense from an economical point-of-view, and last but not least: a concept of a watch phone which I believe could become popular, and which I would really like to see manufactured in the near future.

One of the biggest problems is that whenever I tell someone that my watch is also a phone, they will immediately ask if it isn't uncomfortable to make calls with it and if I need to hold my arm in silly poses. The answer is: no. Yet, most current models do effectively suffer from this problem. My proposal contains a solution to get rid of this misconception. Watch phones will not become a commercial success as long as people have this Knight Rider-inspired mental image about them.

Uurwerktelefoons, Smartwatches en de iWatch

Recent zijn er geruchten over een Apple “iWatch” opgedoken, en velen dachten dat het idee van een communicatietoestel met internetverbinding dat op de pols gedragen kan worden baanbrekend was. Niet echt: zogenaamde watch phones of uurwerktelefoons bestaan al langer dan tien jaar. Natuurlijk waren de eerste modellen lomp en kwamen nauwelijks voorbij het prototypestadium, maar sinds vijf jaar zijn er wijd verspreide en behoorlijk bruikbare uurwerktelefoons. De meeste hiervan komen uit China, en kunnen op verschillende websites gekocht worden aan democratische prijzen. Sinds mei 2008 was mijn GSM voor dagelijks gebruik een uurwerktelefoon.

Het grootste probleem met elk model uurwerktelefoon dat nu bestaat is echter dat het zwaar tekortschiet op een of meerdere gebieden. En om een of andere reden vinden fabrikanten het nodig om telkens ze iets verbeteren aan een nieuw model, het te verslechteren op andere gebieden. Ik heb dit “de wet van behoud van onbruikbaarheid” gedoopt.

In een nieuw artikel op mijn website geef ik een korte geschiedenis van uurwerktelefoons, beschrijf ik de goede en slechte punten van vroegere en huidige modellen, waarom het idee van smartwatches die een smartphone nodig hebben om te werken op niets slaat, en tenslotte: een concept voor een uurwerktelefoon waarvan ik geloof dat hij wél populair zou kunnen worden, en waarvan ik hoop dat iemand hem kan produceren in de nabije toekomst.

Een van de grootste problemen is dat telkens ik iemand vertel dat mijn uurwerk ook een telefoon is, zij ogenblikkelijk vragen of het niet oncomfortabel is om te bellen en of ik mijn arm niet in een idiote pose moet houden. Het antwoord is: nee. Desondanks lijden de meeste huidige modellen effectief onder dit probleem. Mijn voorstel bevat een oplossing om dit misverstand uit de weg te ruimen. Uurwerktelefoons zullen nooit een commercieel succes worden zolang mensen er dit door Knight Rider geïnspireerde idee over hebben.

Approximating iTunes DJ in iTunes 11

iTunes 11 has generated both praise and revolt in the online community because it is a mix of both improvements and regressions. One of the most annoying things for me and many others is the omission of the iTunes DJ feature. Apple's idea was to replace it with the “Up Next” feature, but it is not the same. What I liked a lot about iTunes DJ is that it was a regular playlist that I could easily tweak and I could see all the desired information about upcoming songs at a glance. The Up Next feature requires a click on a button to temporarily view a severely limited list of what is coming next, and manipulating it is a hassle.
It is possible however to create a smart playlist that more or less behaves like the good old iTunes DJ.

The screenshot is pretty straightforward, it shows the most basic setup but you can tailor it to your needs with additional rules. The only essential things are the fixed limit “selected by random”, the “Live updating”, and the “Last played not in the last …”. All these things combined will automatically remove a played song and cause a new one to be added to the queue, just like in iTunes DJ. The time span for the “last played” rule is not essential, anything starting from 5 seconds should work. You can use a larger value if you want to avoid hearing the same song twice within a certain time span.

Next, make sure the playlist is sorted on the very first column (the one with the numbers and no header title), and disable shuffle. Then you can arrange the songs to your liking, and start playing. You will notice that whenever you remove songs, new ones will be added at the bottom just like in iTunes DJ. The only aspects in which this differs are:

• The biggest drawback is that it is impossible to add specific songs to the playlist. If you want to play one or more specific songs that were not randomly picked, your best option is to use “Up Next” after all.
• There is no practical way I know of to increase the chance that higher rated songs are played more often. Not a big deal for me since I never used this.
• One cannot see the played songs, you will need to use a separate “recently played” smart playlist for this.
• Of course the feature to let people vote for upcoming songs is still missing.

Weak TOSLINK (S/PDIF) output on recent MacBook Pros

I have been using a surround receiver with a 10m optical TOSLINK cable and a 2006 model MacBook Pro without any problems for years. With my early 2011 17" MacBook Pro however, as well as someone else's 13" MacBook Pro from the same era, the receiver started producing frequent bleeping sounds, subtle audio drop-outs, and sometimes even downright refusing to work until it was ‘rebooted’.

I suspected all kinds of causes, including the cable or degrading components in the receiver. However, with a totally different receiver and cable of similar length, occasional drop-outs were also noticeable although this receiver was more robust and able to resume fast enough that it wasn't too jarring. After some more tests it became obvious that the light output from the new MacBook Pro is simply weaker than on older models and many other recent devices with S/PDIF outputs. This is especially visible when simply looking at the end of the cable when first plugging it into the new MacBook Pro and then one of those other devices. The photo shows the output of the MacBook Pro (top) and of a TOSLink repeater (bottom) through identical cables.
The 10m cable causes a considerable attenuation of the signal no matter what (Wikipedia mentions 10m as the limit for cable length). But with the old MacBook Pro, apparently the end result was still strong enough. The data sheet for the detectors in the receiver states that they expect at least -24dBm. My guess is that with the new MacBook Pro + the long cable, the output drops slightly below this, which is why it is just on the edge between working and not working. Some solutions are: a TOSLINK repeater to drive the long cable, a more sensitive detector with coax connection to the receiver, or a USB sound card with a stronger optical output. I settled for a repeater for which I made a USB power cable for extra convenience.
Another example where newer is not always better…

OS X Lion: fixing stuck wallpaper

One of the many small annoying bugs in OS X 10.7 ‘Lion’ that seem of too low priority to get fixed by Apple is that sometimes the desktop wallpaper gets stuck at the same image. When changing it in System Preferences, everything indicates that it has changed but still the same image stays on the desktop. A reboot fixes this and for some people (I suppose especially those used to working with Windows) this seems a satisfactory solution, but the more seasoned Mac users frown upon rebooting for something as trivial as this.

There is a more elegant solution, being only restarting the process that is responsible for the desktop wallpaper. This process is the Dock, and it can be restarted by either typing “killall Dock” in a terminal, or by using Activity Monitor. Mind that this could have some side effects. Eventually you will probably end up rebooting anyway to get everything right, but this fix will work if for some reason you badly need to change the wallpaper.

OS X Lion: oplossing voor vastgelopen bureaubladafbeelding

Een van de vervelende kleine bugs in OS X 10.7 ‘Lion’ dat blijkbaar van te lage prioriteit is om door Apple opgelost te worden, is dat de bureaubladafbeelding soms blijft steken. Als deze veranderd wordt in de systeemvoorkeuren wijst alles erop dat er een andere afbeelding moet verschijnen, maar de oude blijft staan op het bureaublad. Het ganse systeem herstarten is een ‘oplossing’ maar voor wie dit niet gewend is vanuit Windows lijkt het overkill voor zo'n triviaal probleem.

Er is een elegantere oplossing, namelijk enkel het proces herstarten dat verantwoordelijk is voor de bureaubladafbeelding. Dit process is Dock, en het kan herstart worden door ofwel “killall Dock” te typen in een terminal, ofwel door Activiteitenweergave (Activity Monitor) te gebruiken. Het is mogelijk dat dit wat neveneffecten geeft, maar deze oplossing is bruikbaar als u om een of andere reden dringend de afbeelding wil veranderen.

Magic Mouse battery management

If you have a wireless Mighty Mouse and you're tired of the scroll ball getting clogged with gunk, you may consider buying a new fancy Magic Mouse. In many aspects it will be a step forward, except one.
The battery management of the Mighty Mouse was very good: it could run on a single cell, which means that when it told you its batteries were empty they were both guaranteed to be empty. The mouse would always keep drawing power from whatever battery still had some juice left. This made it possible to run for weeks even on a set of old worn-out rechargeable cells.
The battery management of the new Magic Mouse is not so mighty, nor is it magical. In fact it is absent. The people at Softpedia have already discovered this but they did not explain the root cause of the problem. I do not believe the Magic mouse draws much more current than the Mighty Mouse. The problem is that it treats the two cells in series like any primitive battery-powered device. It expects a total voltage of more than about 2 Volts. This means that if one battery is still going strong at 1.2V and the other one is dead at 0.8V, the mouse will shut off. The Mighty Mouse would still be going at that point because it would ignore the empty battery and draw current from the other one.
Especially with Apple now selling their own NiMH batteries and charger, their decision to drop the advanced battery management is puzzling. If there is any type of battery that benefits enormously from the separate treatment it is rechargeable ones. Contrary to alkaline batteries, NiMH batteries will maintain a quite steady voltage until they're empty, at which point they exhibit a very quick voltage drop. If one battery has less capacity than the other, this leaves no margin for the higher-capacity battery to further discharge because the series voltage plummets below the threshold. With alkalines the steadily dropping voltage provides more spring-action between the two cells.
I tried using 2300mAh cells in a Magic Mouse and they lasted less than two weeks of non-intensive usage. The scenario was as described above: at the end of the run one cell was empty and the other one still had quite a lot of juice left.
If you have multiple pairs of rechargeable batteries and a means to measure their actual capacity (e.g. with an advanced charger), try to match the batteries in pairs of equal capacity. They will give you more mileage. This does not only apply to the Magic Mouse but to any device that connects its cells in series (i.e. practically every device).
P.S.: Anyone who had a wireless Mighty Mouse might remember reading the mysterious notice “3Vdc Agency approvals inside” on its underside. Whatever it meant (I never found any ‘approvals’ while disassembling the mouse), I think the 3Vdc Agency would not approve of the Magic Mouse.