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 …
… 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) …
Using 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.
Aha…many thanks for this more thorough explanation of exactly what
the description field needs to look like.
So, to solve my specific situation, I’ll go off and do some fiddling and
report back. My symptoms are identical to what you describe. However,
instead of “MyLink” platform, I have a “StarLink” system to deal with,
which indeed DOES do lookups from a ‘Gracenote’ repository of
popular cover-art. (The “StarLink” system in the dashboard of
my (2015?) Subaru Outback.) So, if anyone reading here has
already solved this for StarLink, please comment back with your
Btw, I found THIS writeup, via a similar Internet article here:
Its author coded a similar-sounding tweaker that he calls “bliss” (written
in Java). Since I’m quite familiar with Java, I’m reasonably optomistic
that I can get his ‘bliss’ running on (Win-10) laptop. (He distributes his
‘bliss’ for 4 platforms…NONE of which mentions ‘Windows’. However,
if you just grab his ‘Linux’ choice, you’ll have a Windows-compatible
‘executable JAR’ file that will run on any Windows platform, once
you first install a Java-execution environment (i.e. a ‘JRE” aka Java
runtime environment, which is available from Oracle.). e.g. https://www.oracle.com/technetwork/java/javase/downloads/index.html
(Note: A JRE is a subset of a full JDK (developer kit), but if you can’t
figure out how to install just the JRE, go ahead and install the full JDK,
as it contains the JRE, and will auto-install that too.
Cheers…hope this helps someone.
This week I was again frustrated to find that some songs were not displaying artwork in the car MyLink screen, even though the MP3 track had valid album art embedded in the file. I eventually tracked down that it was not displaying on tracks where the album art was too large, for example recent tracks I had purchased from iTunes where the cover art was 1400×1400 pixels.
I didn’t test to see what the exact limitation is, all I know is that 600×600 artwork is fine, but 1400×1400 artwork doesn’t display. Replacing the large cover art with reduced sized versions using the Mp3Tag utility fixed the problem.
Hi Lachlan, thanks for this. I did some online research to combine all the hints about MyLink album art into one place. The consensus seemed to be no larger than 600×600 so I think you are right on that; there was some suggestion that larger was also supported, but would display slower. I collected all the tips here: http://www.blisshq.com/music-library-management-blog/2016/08/02/mylink-album-art/
What you found about encoding is a strange one. As far as an encoding _name_ goes, “UTF_16_BOM” is non standard, although it does describe, if you like, the UTF-16 encoding utilising a byte order mark. I’m guessing that TagInspector used that label? Anyway, the encodings supported in ID3 are listed here: https://en.wikipedia.org/wiki/ID3#ID3v2 . It might be that MyLink simply doesn’t obey the entire spec. I would hope UTF-8 worked at least, because just supporting ISO-8859-1 might cause some problems (these days!).