High Quality Album Art?

[James77]

Frost,
That sounds cool. What size image does Freebox use now when displaying albums?  Will the Cache size be the same as the freebox size?  I like that, since I have found some covers that are pretty big 

[frosty]

It's not as complicated as it sounds.  THe cache is basically a folder with thumbnails for each album that has a cover.  The image sizes run between 5 and 20 K and are sized at 150 x 150 with 90% compression.  I may add the ability to change these two parameters in the config for those with speedier systems.

Frosty

[bzpilot]

It's not as complicated as it sounds.  THe cache is basically a folder with thumbnails for each album that has a cover.  The image sizes run between 5 and 20 K and are sized at 150 x 150 with 90% compression.  I may add the ability to change these two parameters in the config for those with speedier systems.

Frosty

I have been playing around with this a little myself.  I did some calculations with the now standard BnB screen size of 1024x768.  At this resolution the cover art on the main page is currently displayed at approximately 170x130 give or take a couple pixels useing a 4x3 (12 album cover) setup.

I was originally thinking of creating a coverthumb.jpg in all the album folders at 170x170 to be displayed on the main page (any higher resolution useing the current BnB skin would be wasted).  Then useing cover.jpg (at the highest resolution you could find the cover at) to use for the track selection screen, now playing screen, etc.

Barcrest would have to put an option in to look for the two seperate .jpg's, but it should definitely be doable.

Frosty's idea may be the better way to go though for speed, cacheing should be faster.  Although if you have thousands of albums the cache will start to get pretty large.  If this is the way it goes I would suggest a 170x170 standard for it (if the size option isn't implemented right away).

The 170x170 thumbs should be about half the size or less of what people are currently useing for cover art on the main screen, this should definitely show some speed improvement, even without the cacheing.

[Barcrest]

BZPilot has a point. Would involve a small change to the code but using 2 seperate images, (Hi-res for now playing and track listing) low res for browsing.. at 170x170 there would be a decent speed increase.

[frosty]

When I use the term caching, I'm saying that all the thumbnails are stored in a cache folder, and the full sized image is stored in the album folder.  The thumbnails are not stored in memory at startup, but read from disk as needed.  The reasons for this are as follows.

1) I got tired of having high res images and having to down-sample them to make page flips faster.  This was both time intensive and created artwork that was blurry on the track selection/now playing screens.  The fix was to incorporate the resizing of the artwork into the config so that the user wouldn't need to do it manually, and to change the jukebox to read the thumbnail or full size image as bzpilot describes.

2) as originally coded, I was storing the thumbnails in the album folders. Spudgunman pointed out that he has spent hundreds of hours getting his music folders built and doesn't like the idea of any media program changing things.  He went so far as to set his media folder read only to prevent data from changing or being lost.  This seemed perfectly logical to me which is why the thumbnails are now stored in the freebox\cache folder.  If you don't want the cache, run the build and un-check the "build artwork cache" option.  If the cache is already built and you don't want it, just delete the cache folder.  Either way it doesn't affect the way the jukebox handles the artwork.

So in short, the  new artwork model as coded follows bzpilots exact description with the exception of the thumbnails being stored in the cache folder (where its easier to manage) instead of the album folders.

Hope this clears things up

Frosty

[James77]

I think Frostys idea of having the program create a cache folder in the Freebox directory would be the way to go.  Trying to go through  hundred's if not thousands of folders and create a smaller .jpgs would be a pain, plus it would start to clutter the media directory.

[Barcrest]

I think Frostys idea of having the program create a cache folder in the Freebox directory would be the way to go.  Trying to go through  hundred's if not thousands of folders and create a smaller .jpgs would be a pain, plus it would start to clutter the media directory.

This isn't an issue if you have your artwork all named the same. I could just a search for cover.jpg on my media drive then drag the results to the bulk re-sizer to make them 170 x 170 and save the new image as coversmall.jpg

It would not be too hard to do, frosty's method is basically the same thing really however doing it via the config will probably mean it will take longer to build the library. Then depending how these are stored it may have to do it evertime if you kill your database i am not sure...

Either way involves changing the current code. I am currently working on 4.0.8 and the focus of that is to increase speed. Maybe i will try this out at some point i don't know.

[bzpilot]

Current BnB skin:

Track Listing Album Art: 440x340
Now Playing Album Art: 410x320

So currently anything over about 450x450 even on the high resolution side would be wasted.

[kizer]

Like I mentioned up above some where I use a command line looking app and it will bulk resize all images. Basically you just drag your MP3 folder on it and it scans every folder looking for images. Anything that is an image over the preset size it resizes it automaticallly. Super fast as well.

Here it is.... Way easier than doing one file at a time or using XP's image resize addon.
http://www.rw-designer.com/picture-resize

[draginit]

I think Frostys idea of having the program create a cache folder in the Freebox directory would be the way to go.  Trying to go through  hundred's if not thousands of folders and create a smaller .jpgs would be a pain, plus it would start to clutter the media directory.

not so sure...i used the program kizer mentioned above a long while back and literally it went thru 4116 albums covers in i believe under a minute.  its really easy!!  thats gong thru the entire folder i keep my music in with over 70,000files. it only looks for the jpegs and resizes and replaces them instantly. and just keep the program on your desktop so when just before you add new music, drag that folder over the icon and your done! all images are the same.
-ive seen no instances in my artwork where theres blurring or stretching unless the image was already smaller than 300x300.  and i know i cant blame speed issues on my album art cuz i know there all the same suggested size.

[bzpilot]

I have all my art work embeded within my .mp3s and still find it very easy to extract all images in the album art folders.  Useing Media Monkey and a script within it that will extract (actually the option I use just extracts a copy of the album art image out and keeps the original embeded) the image out to any size I would like and save it as any name.

I just ran it once with over 1500 album covers for a 450x450 cover.jpg for each album and it took under a minute.  Then ran it again for a 170x170 coversmall.jpg and again under a minute.  Or I could have ran the program draginit mentions to just resize and rename the 450x450 images.

So there are definitely ways to do this that take no time at all and are user friendly.

I think if Barcrest can just add an option to look for the seperate images within Freebox people can either use it or not at there own discretion.

To see what kind of performance increase I would get with this, I deleted all my cover.jpg's I originally had been using which were at 300x300 and used 170x170 images and noticed a considerable speed difference when paging through and skipping around through the album art pages!!

[Barcrest]

I will add this as an option in the next release, it is something i like the sound of.

[spacefractal]

In MultiJuke I use a thumbnail folder (in MultiJuke folder) with a md5 hash for each coverart (includning path and such), that have been scaled down. That is done when building library.

MultiJuke use then thumbnails under tableview. when open a album, it then use high quality (I user around 800x800 pixels for most coverart).

That is what I do with coverart in my application. Freebox could do the same.... The only downside is the building of database take some longer time.

[kizer]

Maybe a cover.jpg for album view and a cover2.jpg for full size. Could you have it upscale cover.jpg for larger if said cover2.jpg doesn't exist?

I don't mind haveing 2 image sets, but I really like the idea of everything residing in the albums folder for ease of maintenance.

That just means I'd personally would have to rename all my cover.jpg's to cover2.jpg then resize them down to whatever is deemed the fastest and name those to cover.jpg.

I hope I'm not sounding to confusing.

[Barcrest]

anyone know how to use kizers tool to also rename the files? I wanted to create a cover_small for all my albums.