Embedded Album Art Enabled In Rockbox
 

I was doing my weekly check of the Since 4 Weeks changes page when I ran across this. I've tested it with a few themes I regularly use and it works very well for me. If you're a fan of album art this will give you the chance to save quite a bit of space on your disc. In checking my internal and external memory for folder.jpg files I discovered enough that I can remove to add several more tunes. I use fairly small picture files but enough small files can add up to quite a bit.

My thanks once again to everyone whose contributions continue to improve this all ready fantastic project.

WHAT??!! Really??!? I had no idea - I have not followed Flyspray for a while. This is great news! Thanks for the heads up skip252!

Now I must update my ancient build ;)

THANKS RB PEOPLE!

Kinda thought that might make your day a bit brighter. For some reason I tested it with Boselhack first. Works great.

:confused:
Could you explain this? If you have one single jpg per folder it will take much less space than an image that is redundantly embedded into each and every file.

True, but there are some of us that have a single library of .mp3s with embedded art and an additional folder.jpg included so that AA shows in Rockbox. Eliminating that additional folder.jpg is where the space saving comes in.

As an example, I have a couple of Sony players that don't show AA when it's as folder or cover.jpg. Neither does my Fuze in the OF. Trying to maintain multiple .mp3 libraries with one having embedded AA and one not is a real PIA. Now I can go through and dump all the folder.jpgs and the AA will show on every player.

I agree that the greatest savings in space would be if .folder/.cover.jpg was honored across the board. A single .jpeg would take up considerably less space than embedding. However since it's not in my case I'll take the savings I can get from this.

Oh, okay, now I understand what you mean. :o

Personally I use the folder.jpg approach exclusively as it works virtually everywhere - on each PC OS, under Rockbox and even when using the OF. Perhaps the file attributes of your folder.jpgs include the hidden flag, it think that's set by default if you let Windows generate these files. I use MP3Tag to download covers and they're automatically renamed to "folder.jpg", but without the hidden attribute.

Its funny you say that Progweed - this is exactly my own logic with regards to embedding album art. :D I have not yet come across any AArt capable player [using stock FW] that did not support embedded AArt whereas I have heard/read stories of folks having problems with folder.jpg and specific nomenclature [folder vs cover.jpg]

That Rockbox didn't until now for Fuze was an incredibly small price to pay for everything else I got.

This is indeed a red letter day for me and my RB'd Fuzes.

Noob question, but is this new embedded AArt support solely for Fuze RB builds or for RB across the board? If so, my Toshiba Gigabeat RB will be joyous as well.

That sneaky saratoga - he had mentioned a while back that embedded AArt support was not really on the horizon ;) :D

Very true, of course. ;) If you own several players embedded album art is the safest bet. But I only have a Fuze atm, so I can save quite a bit of space by not embedding anything.

It's hardware independent and should work on every player that is able to display some graphics.

Is just plain wrong. I just checked and folder.jpg does work in the OF on my Fuze. As long as I keep the size to something reasonable and it's not a progressive .jpg it shows up just fine. Good info Progweed, I won't be needing to use it but it's nice to know.

All I can think is that I've used the OF so little my memories of it are flawed. Actually had to think for a moment which key combo to use to make the OF boot.:D I removed the embedded AA from a few albums and left the folder.jpg file in place. They all displayed OK.

Thanks guys! :)

Cool! Just discovered this by accident. I was trying to figure out why some of my cover.jpg images were working as album art and some weren't, and went to check the docs to see if any insight could be found there, saw that embedded aa had been added, updated my rockbox, and yes it works! YAY! Great work!

Yep, that's exactly why I visit the 4 Week Changes page at least once a week. I've had a few times when I thought something was broken or malfunctioning and discovered it had been either changed or improved. Saved me quite a few "What the...?" moments.:D

Well, this is unfortunately a fail for me, a first for me and Rockbox. :(

Tried to update to the last archived build, r29305, which should have included the embedded art support. Some themes were broken [as I expected since my existing build is waaaaay old - don't laugh Marv: r26906] but not a problem.

What is a concern was RB reporting that the DB was not updated/Ready and apparently refusing to do so. I initialized/Updated and checked the progress under the debug screen. When completed, there, under the DB menu the database continued to read as NOT READY no matter what I tried and how long I left the device on [over the course of 2 hours].

Bummer for me - not sure what went wrong. Am reverting back to previous build as I type... :(

26906, how old is that? Older or newer than the 3.7.1 release?

Metadata logging is available as a troubleshooting tool now. You can activate it in the Debug menu. It logs the metadata of the files as the database updates. If you see the database hanging on the same file that's probably your problem. Yes, I know you are very meticulous about your metadata but it may have been altered by a disc problem.

The other obvious thing to do would be to check your discs for errors. No need to tell a old pro like you how to do that.:D If after checking everything out it turns out to be a reproducible error I'd file a bug report. The developers need to know about bugs in order to work on them.

^ Heya Marv. r26906 looks like its from June 18 2010. RB 3.7.1 looks like Nov 26, 2010 so yes, my build pre-dates 3.7.1 by quite a lot.

I did grab the latest RB Utility though to install on this new laptop.

So I gather I might not be able to as in past simply unzip the r29305 build .rockbox folder and copy/overwriting my existing install on the Fuze?

EDIT:
Thanks a ton skip252. Actually, yes, I did run chkdsk and some files did appear to be corrupted somehow [about 10, mostly WPS screen files it seemed, along with a couple .jpg album art pics]. I allowed chkdsk to correct to no avail. This corruption in itself is kinda odd as well in that issues suddenly cropped up as I do actually run chkdsk on my Fuze approximately 1 every 4-6 weeks as part of my overall PC maintenance and no issues at all have cropped up before.

I did notice the metadata logging and activated it - sadly I have already dumped that .rockbox folder and rolled back so that log is gone.

However, if I have a chance, I will certainly try again, possibly this weekend - if the issue persists I will indeed file a bug report.

Though now that I think about it a little, if there are issues with my tags, wouldn't my old build also choke? As of right now, build r26906 is back and everything is 100% again, no issues at all with the DB.

Still, I wonder if Marv's angle might have something to do with it, that my build predates RB 3.7.1?

If you were going to roll back, then at least update as far as 3.7.1 so your music would play the proper speed! :rolleyes::p:D

I'd just use the current build. No need for the installer. Just unzip the current build to the root of the player. Those "stable" builds are just everything that had been added to the current builds up to that time. Actually they are they are very old and very outdated. Absolutely nothing special about them. The last time one was issued I had no need to update. I all ready had everything that was included in the "stable" build.

You can unzip the current build over the older build. However if you're having significant problems it may be better to save the older build to someplace else if you want to preserve those setting and just drop in a fresh build. You can just create a folder on the player and put it there to preserve it. The bootloader stops looking once it finds the first .rockbox folder.

Also I've found unzipping newer theme files over older ones doesn't work very well. There seems to be enough similarity between them that the newer files don't always replace the older ones properly. Once you're sure every thing's OK you can then import your older .cfg files. I don't know if over writing your newer database with the older one will preserve your playcounts and such. You could try copy/pasting from the older one and see if that works, idk. Part of me tends to doubt that would work but you may find it actually works out OK. Worth a shot I'm guessing.

Well baring the obvious "someone broke one of the metadata parsers" reply, as we add new formats, theres actually more files being parsed. Its possible theres additional files on your player that don't get parsed because theres nothing associated with their file extension on the older build. But someone breaking something is more likely I think.

^ Thanks saratoga. I wouldn't be too quick to file a bug report though as it seems I am alone with this issue.

I will try skip's suggestions again at some point soon and get back here. If the issue persists in my environment and my Fuze file system is clean then maybe a bug report should be in order. Your call of course! :)