Print

Please login or register.
1 Hour 1 Day 1 Week 1 Month Forever
Login with username, password and session length

[Araj]

Rockbox finally (officially) supports album art. As there were inofficial builds to display album art until recently, I could never be bothered to convert all my album art to a format supported by whatever theme, as it was then impossible to update Rockbox and keep the art.

Anyway, what I'm looking for now is a way of batch-processing all the image files I have (name convention <Artist> - <Album>.jpg) and converting them to 60x60px bmps. Perfect would be a utility which would find all the jpgs in my the subdirs of my /music dir and save each new bmp version to the same subdir as the original jpg. The name for the bmps would be either cover.bmp or even better <Album>.bmp

Anyone done this and found a quick solution?

Thanks for your input !

[JimH]

We might be able to help.  I'll move this to the portable device board.  Bump if necessary.

[Araj]

We might be able to help

Sounds hopeful 

[skeeterfood]

It would be wonderful if the type, dimensions, and name of the coverart files could be specified in the handheld options somewhere.  Probably can be defaulted to jpeg, 120x120 (?), and Folder.jpg.

-John

[Araj]

Bump if necessary.

bump 

[RhinoBanga]

I gave up on Rockbox on the iPod.

When I first loaded it onto my iPod a few months back it did not generate the tag database properly.   After hunting around the code I found out they fixed their internal tag buffer size to 300 bytes which meant anyone with a reasonable amount of tag information in a file would "lose" anything after this.   I fixed this and got them to introduce a #define so people could change this to a more usable number.   However subsequent builds "broke" as people still hard coded the 300 value.

They stated that the new official album art code, which would use a dynamic buffer for tag information, would solve this.   Do you know if it's now possible to have more than 300 bytes of tag info?

[RhinoBanga]

Dynamic buffer tag still not implemented and as such RB completely loses loads of my correctly tagged tracks.

The newer builds look really good though so I am going to roll my own with a larger static buffer size and play around with it.

[Araj]

I haven't noticed any problems with tags, though I did once have an issue a couple of times where the database had everything double (fixed easily with a rebuild). I'm sure I must have tracks with more than 300 bytes info - but I'd have to check. What happens in this case exactly? The tracks aren't in the database at all? Only some of the tags appear in the db ?

[Araj]

We might be able to help....  Bump if necessary.

bump again 

Jim, it'd be great just to know if anything is likely to happen here. I'd hate to give up waiting, spend days manually resizing, converting and copying over all the BMPs and then have an automated solution appear shortly afterwards.

[JimH]

Araj, If you can provide the details of what it would take, we'll consider making minor changes to make it work better.

Rhino, Let them know we'd like to support them.  If you have a contact, please pass it on to Matt.

[Araj]

Hi Jim

I appreciate your interest in finding a solution. Here's a rundown of the current status quo:

Rockbox only supports BMPs (may change one day). The pixel size depends on the theme (skin). Official builds don't support on-the-fly resizing during playback (yet), though unofficial builds do. Here's the Rockbox Wiki page with more info:

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

You may notice the list of links to utilities listed at the bottom of the above page for converting formats and size. I've checked them all out and not managed to find any way to make them work efficiently with MC/Rockbox

Perfect would be a MC on-the-fly conversion of cover art during handheld sync that converts the format to BMP, changes the pixel size (currently needs to be user/Rb theme specific), renames it to something supported by Rb and then stores the BMP appropriately for a sync so it lands somewhere that Rb will find it. Here are the options:
  ./ filename .bmp - same filename as currently playing music file
  ./ albumtitle .bmp - name of the album, found in metadata of the music file
  ./cover.bmp
  /.rockbox/albumart/ artist-albumtitle .bmp
  ../ albumtitle .bmp
  ../cover.bmp

In fact, the utility would be a very similar function to the current sync file conversion for audio formats.

Let me know if anything's not clear.

[RhinoBanga]

I haven't noticed any problems with tags, though I did once have an issue a couple of times where the database had everything double (fixed easily with a rebuild). I'm sure I must have tracks with more than 300 bytes info - but I'd have to check. What happens in this case exactly? The tracks aren't in the database at all? Only some of the tags appear in the db ?

It depends in the order of the tags in the file.   If you have your artist, album, etc, at the beginning of the ID3v2 tag section then everything works fine however if you have something like COMM (the comments field) first then depending on the size you could get partial tagging or (in a few cases I have) tracks are marked as unassigned since it can't "see" the tags.   

I have rolled my own build increasing the static buffer to 600 bytes and I get a reasonable amount of my tracks logged, but not all.   However I also discovered a bug which causes RB to crash in certain tag situations.   I have fixed it in my version of the code but I need to let the RB guys know so they can implement it in the mainline.

I am now looking for an application that will allow me to re-order tags to put the comment field last.

[Araj]

Hi Rhino

I couldn't find any similar problems in my db, despite having some pretty bulky tags - but from your experience and comments, it's well possible that's because we're using different tags, or the same ones in different ways. I never use the comments tag for example.

I have never had Rockbox crash so far (touch wood). However, this and the tag issue may be handheld specific, as you have an Rb build for your iPod and I have one for my iAudio

[RhinoBanga]

Hi Araj,

You are right in that it could be compiler specific.   Check out apps/tagcache.c at around line 1631:

    if (length > TAG_MAXLEN)
    {
        logf("over length tag: %s", *tag);
        length = TAG_MAXLEN;
        *tag[length] = '\0';
    }


Should read:

    if (length > TAG_MAXLEN)
    {
        logf("over length tag: %s", *tag);
        length = TAG_MAXLEN;
        (*tag)[length] = '\0';
    }

[RhinoBanga]

An update, I have been in contact with the RB guys and they agree that it's a bug and that I should submit this fix (and others I have found) tonight.

[Araj]

Check out apps/tagcache.c

I don't have tagcache.c, nor the apps directory, so I guess it's specific to the iPod port

[Araj]

Erm, bump 

Is anything cooking in this (Album Art conversion) particular part of the MC kitchen, Jim ?

[SwellGuy]

Nothing right now. There have been a lot of similar requests so it's definitely on the list of things to do - but that's a long list.

[Tolga]

This topic was inactive for a while. It seems to require only very little support from MC.

bump 

[Araj]

Bump if necessary.

...two years later....