Album ARt

[jdoe]

can anyone tell me the tag for album art? i've looked through some other wps's but i cant seem to find anything.

[bluebrother]

Rockbox does not support album art.

[Angyman]

You need a custom build for album art...

If youve got that... Take a look at the %Cl and %C Tags found in the album art themes...

[robin0800]

Try this page

http://www.rockbox.org/twiki/bin/view/Main/AlbumArt

[Dr Schlong]

Rockbox does not support album art.

Why is it so difficult to get album art into Rockbox (followed the forum advice but apparently my laptop doesn't have enough memory to run the Patch programs)?
I've seen numerous posts asking about album art and they usual terse response is as above; is any album art support in the pipeline?

Cheers for any helpful responses!

Dr S

[bascule]

Part of it is that the patch may or may not be stable and/or not efficiently coded and no core dev has yet seen fit to commit it. In addition, it is often (perhaps almost always) used in conjuction with other, non-committed, patches such as scrolling margins.

Above all of that, a major upcoming (don't ask when ) feature, metadata on buffer, will immediately render the patch obsolete, AFAIK, because there would then be a much better way of achieving the Album Art functionality.

[Dr Schlong]

Thanks for clearing that up, btw I love the crossfade option!  

[Nate!]

Somewhat off topic, but to clear it up for me.  The implementation of album art in the official build is dependant on two things, Metadata on Buffer and Viewports.  

Viewports, from what I gather, is how data gets displayed in a WPS.  Seems like the display is divided into sections and display data, i.e. track name, file info, and etc, don't overlap outside of their "section" of the display.  This should take care of the scrolling margins patch, multifont, and other similiar patches.

Metadata on buffer, is pretty self explanatory.  Sounds like it reads the metadata of a file into a buffer for extraction and use.   Information in metadata can include Album Art.

The viewport implementation is huge, from what I have seen in searching the forums.  It will determine precisely where text/images will get displayed at the pixel/cell level and how it gets displayed.  So all of the other patches will become moot.

Is this the jist?

[NicolasP]

Although you seem to have gotten the idea, I feel like a few clarifications are needed.
First, album art (AA) is dependent on metadata on buffer (MoB), but not really on viewports. Without MoB, it's not possible to implement AA in a clean way, whereas viewports will provide more flexibility for WPS creators, but are not really related.

What Nate! said about viewports seems about right to me, although the concept is still not very well defined. It seems amiconn has a clear idea about it but doesn't explain it in very much detail. They are very promising but aren't needed to do a clean AA implementation.

MoB, on the other hand, is a real requirement: we put track metadata on the main buffer (currently it is only used to store compressed music data waiting to be decoded). This will remove the limit of what quantity of metadata we can store for a track, and therefor allow crazy things like album art. In no way it makes the AA patch obsolete. The patch will be practically the same, only the location where it takes the bitmaps to be displayed will have changed, that's all. Without it, we'd have to allocate a fixed amount of memory for bitmap storage, and for some it would be wasted, whereas for others it would be too small.

[bascule]

...In no way it makes the AA patch obsolete. The patch will be practically the same, only the location where it takes the bitmaps to be displayed will have changed, that's all...

Thanks. I stand corrected.

[ruster]

would the metadata buffer apply to all media? or just audio? i might not even be this right at all...but what exactly would that mean (dumbed down please)?

[Llorean]

It's just a more flexible way of storing the extra data associated with music files (album art, track, title, date, etc). From a user's perspective, it won't change anything. From a programmer's perspective, it adds more flexibility to what we can load with tracks, and how many tracks we can load at once (right now even if the tracks are very small, you can only load so many even if it doesn't quite fill up the RAM).

[saintalan]

Please excuse the ramblings of an ipod video user who has only just found Rockbox!

I have it working and like the OP was disappointed at not having AA, which having read a bit I can understand (not the technical but the reason!).

However I would like to try an alternative build like Senab's build but dont quite understand how it would work. I accept that AA has to be BMP and sized correctly and renamed.

OK so how do I put it in the right directory, does this mean I have to find the directory name from the changed itunes name and can I still then use Database mode, if that makes sense?

Cheers

Alan

[lights0ut]

Saintalan, if your music is organized by itunes it is in folders F00 etc. and this would make it very difficult to organize your album art. It is easiest if you load your music by drag and drop and in the format music>artist>album. Then put your album art in that folder with the name cover.bmp, then you won't need to worry about the tags' album name matching the filename.
Also, if you're worried about correct size you could use a build that has the BMP resize patch applied to it, like my build (link on my sig) or the jbuild. Another method is to use a program like ifranview to do a batch resize of your images.

[saintalan]

... It is easiest if you load your music by drag and drop and in the format music>artist>album. Then put your album art in that folder with the name cover.bmp, ...

Thanks evilg123,

So I drag my music dir from my PC to the ipod? At root or rockbox root or?

Thanks Alan