No Cover Art in Ogg Vorbis Files

Zoey365

New member
I've noticed that Android seems unable to read / display the artwork embedded in my ogg vorbis files. This is a real shame, as I love the sound quality Vorbis offers. So I started thinking of a way around it.

I found that if I create and album in MP3 with embedded artwrok, Android caches the art in albumthumbs (albeit in some kind of format I don't understand). Now if I delete the MP3 copy of the album and replace it with a vorbis copy (with the same album and artist tags), Android happily displays the cached artwork even when playing vorbis.

So, what I am asking is - is there a better way to solve this problem? Does anyone understand the format and naming system used on 'albumthumbs'?

Thanks guys!

Tony
 
This has been a little annoyance for me too. I was prepared to accept no art for Ogg even though it's my format of choice, since my understanding was that there was no officially accepted way to embed images in Ogg metadata (although various developers have settled on various more or less usable approaches). But I've got plenty of MP3s that should have valid images embedded, and I've never seen Android pick up any of them. Fortunately, your post motivated me to do a little searching and see if I could answer both your questions, and I think I can.

Second question first: "Does anyone understand the format and naming system used on 'albumthumbs'?" Yes, but you're not going to like the answer. I tracked down the source code for Android's "MusicUtils" class, which you can read yourself in their version control system if you wish. Apparently, when the system finds art embedded in a media file that it does not already have cached, it copies it out to the albumthumbs folder with a filename generated from a call to Java's System.currentTimeMillis() method. (You can see this around line 909.) It then stores a reference to this file along with an "album_id" that was generated when the library first recognized the album in the internal database.

So the filenames are completely arbitrary and depend on when the system first found art for an album. Only the internal database knows which file goes to which album. A nice efficient process for the software, but fairly opaque and un-hackable for the user. It does, however, explain why your trick works: Since the MP3 and Ogg versions of the files have the same metadata, the library will recognize them as belonging to the same album that it already cached artwork for.

Now, the other question: "Is there a better way to solve this problem?" Well, maybe. Depends on how you structure your audio files on your SD card. Further down in the "getArtworkFromFile" method (starts around 997), I spotted a little secret. If the system fails to find cached art, and it fails to find embedded art, it will look in one more place: A file in the same folder as the audio file named "AlbumArt.jpg".

Now, for me, this is not completely good news. I do have album art as separate files for almost all of my albums, but it's named "Folder.jpg" to take advantage of Windows' folder thumbnail feature. (I use foobar2000 as my PC player, and it apparently will recognize either name.) Also, it's been my habit to date to dump audio into Android's "Music" folder with no subfolders, although I do keep them scrupulously organized on the PC. I usually delete a song after one or two listens and constantly refresh the pool so it didn't seem worthwhile to structure them. It's going to take a little work for me to figure out how to make foobar2000 put fairly random selections onto the SD card and retain the folder structure and include the artwork file and (if possible) rename the file to "AlbumArt.jpg" for me. If anyone's got any tips on that, speak up.

Nevertheless, I did a test and verified that this will work. I put one of my album art files into the Music folder and named it "AlbumArt.jpg", and this artwork then showed up on every song I played.
 
That was one hell of an answer, thank you very much. AlbumArt.jpg satisfies my needs almost completely. I also would have preferred folder.jpg, but hey, you can't win them all.

Again, many thanks for such a detailed answer, it's very much appreciated.
 
Sorry for bringing this old topic back, but every where else I've turned has not been able to figure out how to fix my problem.

I've tried the OP's method of letting the phone (Optimus M, btw) cache the embedded album art from an mp3 version and then replacing it with an ogg version with identical metadata, and it worked. The issue is that it is extremely inconvenient.

I've seen a few posts in other forums etc. saying to place the album art as AlbumArt.jpg in the album's corresponding folder. This, unfortunately, has never worked for me. General googling led me to this blog that says

I'm guessing the Optimus M is one of those phones that needs a unique naming scheme. How can I find out what it is?
 
to someone like me this makes sense, as i am doing it the "windows way" (drag & drop) anyway, so might as well have the album art in the folder too.

what bugs me is that android music can handle different formats but not all the tagging which come with each. the tagging seems capable if i drag & drop albums, not so good if they're compilations, or even worse if i synced from say, itunes playlist instead of drag & drop.

i think what we need is a major overhaul of the andoid media app. it is way too basic by todays standards.

not to mention some people have problems clearing the playlist in their *chosen* music app (connected music, poweramp etc), when these are just front ends for the android media app!
 
Back
Top