Album Art for BandCamp MP3s (WORKAROUND)

Hi all,

TLDR: If album art is not showing up for MP3s from BandCamp, use Kid3 to change the “text encoding” for the APIC id3 frame that holds the album art, from UTF-16 to ISO-8859-1.

I have an issue in Engine Prime (1.3.4) on macOS with album art not showing up for tracks purchased on BandCamp (tried multiple imports, “Re-import Track Information”, etc. to no avail). Here’s the workaround that worked for me, with technical details that I can see.

From BandCamp, I download tracks in “MP3 320” CBR format. I use Kid3 software to inspect/edit id3 tags. In freshly downloaded BandCamp MP3s, only id3v2.3.0 tags are present, and album art is there (and visible in other software, in Finder, etc.) in the APIC frame. However if you go to “edit” the picture tag, you can see that the frame’s “text encoding” is set to “UTF-16”. I think this confuses Engine Prime. After changing the “text encoding” of the APIC frame and saving the file, album art will successfully import in Engine Prime (both re-adding the track and the “re-import track information” option work).

Hopefully devs can fix this issue and read the APIC frame correctly!


You should let band amp know that their album art doesn’t appear when everyone else’s album art does. They’re clearly doing something wrong

I’m not convinced that BandCamp are doing anything wrong per se:

According to there are 4 possible text encoding types in ID3v2, with only two of them supported in ID3v2.3: ISO-8859-1 and UCS-2 (which I suspect Kid3 mistakenly calls UTF-16; they sound like similar/related encodings). The other two encodings (UTF-16BE and UTF-8) are only supported in ID3v2.4; I didn’t test those.

I have no idea why non-ascii text is needed in the album art tag (perhaps for the original image filename, which seems to be preserved?), so I’ll reach out to BandCamp in case they want to maximize the compatibility of their files, but it seems to me that Engine Prime should be able to read the album art from their files as-is; all other software I’ve tried is able to.

It’s all down to the path of least resistance

If two dozen major sources can all supply paid for tracks with album art that works, then why can’t one source, who’s somewhere shown in the 3rd tenth of major suppliers, adjust their “against the grain” way of doing things. I agree that you could inform them of a way that they can make their service appeal to more people. for them it’s probably just ticking the 3rd box on the left instead of the 4th one … no biggie

I was wondering why the album art wasn’t showing up. Hope a future update will fix this, but thanks for the workaround!

I’m gonna try this next time I get a new cart of tunes.

Finally got around to trying this out, not exactly sure how to use this so I’m doing trial and error. First off, I have multiple albums in here with different cover art. What I did was I clicked open and highlighted only the mp3 files I downloaded, excluding cover art files and whatnot, all the mp3’s show up in kid3 on the left and are highlighted. Then I went to the center and selected Picture then edit, changed the text encoding to ISO-8859-1 and when I saved it, all the cover art changed to one picture, I deleted everything and extracted all the downloads back into the folder so now I’m at the starting point again. Do I have to do this album by album?

I only tried one album at a time, only had a couple of albums with this issue. Must be a limitation of Kid3, when you’re editing multiple files, it overwrites the tag to have the exact same value everywhere, meaning the picture, not just the encoding… Probably takes the first picture from all the selected files.

Should be possible to come up with a script to do this more carefully in bulk over entire folders, but who has time for that…

P.S. I filed an issue with BandCamp about this too, but never received any response. I’m still of the opinion that this needs to be fixed in the Engine Prime software.


It seems to be using whatever is at the top yeah. my knowledge of script writing is extremely limited, like baby level, I’ll do it the meticulous way, still faster than the method I used with Mp3tag. I believe Denon is more capable of fixing this to where it’ll read whatever text encoding you throw at it.

Any simple fixes for this when trying to get the artwork for AIFF files?

Keep bugging the hell out of bandcamp.

If everyone else can sell Songs with working artwork, so should they.

Itll be down the artist/label, I have LOTS of bandcamp stuff, i subscribe to shall not fade, for example. All of mine has working artwork.

Nice findings regarding the encoding here :smiley: Just a few cents: When importing directly on the player through Engine OS, artwork from Bandcamp tracks show up fine. When importing tracks on my laptop through Engine Prime, the art does not show up.

Clearly then, Engine Prime is the problem.

Thanks so much IgsterKicks, you are a legend!!! The kid3 trick works for my Bandcamp aiff files too!!!

PS: UTF8 also works with Denon Engine and Denon DJ playes. so converting the text encoding to ISO-8859-1 or UTF8 would be fine

I had high hopes this issue would have been fixed with the new version 2.0 of Engine DJ. But unfortunatly not :frowning:

1 Like

@denon is this on your to do list?

2022 and stiil happening.

I use Illustrate’s dbPoweramp Music File converter. When you install the app in Windows it adds an option in the right-click menu that lets you edit the ID3 tag on the fly. There’s an option in the menu that allows you to resize the art. Bandcamp’s album art is set to 700x700. I resize to 600x600 and import or re-import into Engine DJ.

You have to do this for each file though unless the files are part of the same album. Then you can do all files in the album at once.

Maybe one of the Engine software programmers can take a look at an album art file from Bandcamp to see why engine is not reading the art without manipulation using third-party tools.