Holden MyLink and the cover art conundrum

My Holden car has a MyLink music system with a colour display in the console. One of the things it does is show the cover art of MP3 tracks as it plays them from an attached device. It seems that it gets the cover art from an embedded database of coverart (sourced from GraceNote) or from the MP3 file itself.

I put together a USB drive with my favourite MP3 tracks, but the conundrum was that for some tracks, the cover art would display correctly, and for other tracks, a generic image (based on the track’s genre) would display. There seemed to be no rhyme or reason why some would work and others not work, as most of the tracks had cover art embedded  in the file.

This weekend curiosity got the better of me. Using the TagInspector ID3 editing program I observed the pattern that tracks where the cover art image DID display, had the text encoding of the APIC frame set to ISO8859_1 …

ID3ISO… whereas all the tracks that DIDN’T display the cover art had the text encoding of the APIC frame set to UTF_16_BOM (Unicode) …

ID3UTFUsing the UltraID3Lib library I did a test by changing the text encoding of a track with UTF_16_BOM over to the ISO8859_1 encoding. After doing this, the cover art displayed correctly on the MyLink system. What’s curious about this is the encoding value is the text encoding of the Description field of the image (not the encoding of the image). The text description of the image isn’t displayed at all by the MyLink system, so it’s kind of odd that the encoding type of the text field would prevent the display of the image.

A short bit of coding later and I had a utility that changed the text encoding on the APIC frame of all my MP3’s that I play in the car, and the cover art conundrum is closed.

ID3EncodingCorrect