PDA

View Full Version : Embed art vs folder.jpg?



flimflam
2013-06-19, 05:52
Possibly a dumb question, but if I embed folder.jpg into each file of, for example, a 10 track album (to make life easier outside of Squeezebox), does this cause ten times the work for LMS artwork resizing and caching (and use up ten times the cache storage)?

Thanks. (I use iPeng, if this makes any difference.)

Roland0
2013-06-19, 10:45
Possibly a dumb question, but if I embed folder.jpg into each file of, for example, a 10 track album (to make life easier outside of Squeezebox), does this cause ten times the work for LMS artwork resizing and caching (and use up ten times the cache storage)?

It will be processed / stored only once if it's the same picture for all the tracks.
Note, however, that LMS always prefers the embedded picture, so if you embed a low-quality version into the file, and have an additional separate high-quality folder.jpg, the latter will be ignored.

flimflam
2013-06-20, 16:38
It will be processed / stored only once if it's the same picture for all the tracks.

Thanks. So when scanning the library, LMS cross-checks the embedded art for each track and if it is a repeat of another track, they share the same cached files? And therefore once scanning is complete, there is no difference in storage or workload compared to a single folder.jpg with no embedded artwork?

I looked long and hard for some basic info in layman's terms about this but couldn't find much. I think LMS when scanning the library makes one small and one large pre-cached image (potentially up to two cached images per track if they were all embedded with different images) - is that right? And these are ready-made for the thumbnail and Now Playing views in Players? I was wondering then what exact resolution are these images and where/in what form does the server store them?

thanks again

Mnyb
2013-06-20, 17:03
I can't recall all sizes used , touch uses 3 different sizes so does radio and ,controller wants 2 sizes and the web UI has several sizes to .

But all are not pre cached , some are converted on the fly and stored temporarily .

In the later LMs version the artwork is stored in the artwork.dB file in the cache folder.

lrossouw
2013-06-21, 02:44
Another way too answer your question:
I store embedded and folder.jpg for all music (mainly flac and mp3). I tend to try to find the highest resolution artwork I can (typically in the 800x800 to 1500x1500 range unless it's obscure). It doesn't cause me any performance issues AFAIK.

What is your server? If it's is very slow/underpowered then you might have issues. I'm running this on an HP microserver, but used to also run it on an aged XP box. It was also OK on that.
Are you looking at using the Touch in "standalone" mode? If you are then you need to consider what to do as the touch is apparently slow with art. There are threads about this, but haven't tried/experienced this myself.

HeadBanger
2013-06-21, 05:15
Embedding artwork into every track rather than storing one single cover.jpg must increase the storage size required for your library? Granted they are not big files but over time and many CDs I would have thought that they would add up to a relatively significant amount of HDD space.

Roland0
2013-06-21, 05:53
Thanks. So when scanning the library, LMS cross-checks the embedded art for each track and if it is a repeat of another track, they share the same cached files?

only if they are from the same album



And therefore once scanning is complete, there is no difference in storage or workload compared to a single folder.jpg with no embedded artwork?

In practice, there shouldn't be.



I looked long and hard for some basic info in layman's terms about this but couldn't find much. I think LMS when scanning the library makes one small and one large pre-cached image (potentially up to two cached images per track if they were all embedded with different images) - is that right? And these are ready-made for the thumbnail and Now Playing views in Players? I was wondering then what exact resolution are these images and where/in what form does the server store them?

Well, it's not really a topic the average user cares much about, I'd guess.

Pre-generated sizes are:


"100x100_o", # Web UI large thumbnails
'75x75_p', # iPeng
'64x64_m', # Fab4 10'-UI Album list
'50x50_o', # Web UI small thumbnails
'41x41_m', # Jive/Baby Album list
'40x40_m', # Fab4 Album list

Recent versions of LMS 7.8 allow 3rd party extensions to register additional sizes, see the thread "Registering custom resizing specifications to be pre-cached" in the Developer's forum.
Additionally, if another size is requested by an application (e.g. SqueezePlay uses 240x240px, the web GUI 96x96px), it will be generated on-the-fly and cached as well.

As mentioned, the images are stored in a database (artwork.db), which can grow to a large size (see this (http://forums.slimdevices.com/showthread.php?98776-Registering-custom-resizing-specificiations-to-be-pre-cached&p=749287&viewfull=1#post749287) and subsequent posts for a detailed analysis an why this is happening).

Short version: Due to an issue in LMS, full-sized pictures will also be cached. Additionally, if the image isn't perfectly square (e.g. 801x800 instead of 800x800), it will be (under certain circumstances) cached as a png, no matter what the original format is (see above linked thread for details), effectively doubling the size. This happens both for embedded and standalone artwork.

That being said, the size of the database shouldn't really affect performance (my artwork.db at one point was 5.3 GB, and I never noticed any issues). What is noticeable for large full-size covers, though, is the increase in network transmission time, as a 1.5mb jpg gets converted to a 12mb png, which is then sent from the LMS server to your browser.

flimflam
2013-06-21, 11:15
Thank you everyone, especially Roland0 for your brilliant answer - v helpful, really.

flimflam
2013-06-21, 11:26
Embedding artwork into every track rather than storing one single cover.jpg must increase the storage size required for your library? Granted they are not big files but over time and many CDs I would have thought that they would add up to a relatively significant amount of HDD space.

Given I use lossless encoding, and the average length of a track - it would be about 1% of my library with 'hi-res' artwork, which I think isn't too bad of a hit.

I am contemplating this approach for reasons outside of Squeezebox. For example, in iTunes on my Mac I can't find any other way for the tracks in one album to display the Now Playing artwork other than to embed each and every file (any clever person know how to do this?) It also means I can just copy files to my USB stick which I still use in my car and other places, and artwork shows up without fuss mostly

garym
2013-06-21, 15:45
Given I use lossless encoding, and the average length of a track - it would be about 1% of my library with 'hi-res' artwork, which I think isn't too bad of a hit.

I am contemplating this approach for reasons outside of Squeezebox. For example, in iTunes on my Mac I can't find any other way for the tracks in one album to display the Now Playing artwork other than to embed each and every file (any clever person know how to do this?) It also means I can just copy files to my USB stick which I still use in my car and other places, and artwork shows up without fuss mostly

I use a single file in album directory for my lossless but I embed the art in each mp3 file (i.e., the mp3 copies I make of my lossless FLAC files for use on iphone, etc.). In terms of embedding art in each file (I assume you use Apple Lossless if using itunes), you can use mp3tag or dbpoweramp to embed art in a batch manner. But these run on Windows machines. On a manual basis, within itunes, just right click the file(s), [and from memory] go to file properties, etc. click on the artwork tab, then right click and paste the art you want to be embedded.

JJZolx
2013-06-21, 19:51
Possibly a dumb question, but if I embed folder.jpg into each file of, for example, a 10 track album (to make life easier outside of Squeezebox), does this cause ten times the work for LMS artwork resizing and caching (and use up ten times the cache storage)?

I'm not positive, but I believe that it does increase both the work done by the server when pre-caching resized artwork during a scan, plus the amount of storage required for the cached images. Like I say, I'm not 100% certain, but it would take some effort to tell if images embedded in different files are the same, and it would have had to have been done specifically to decrease the cache size and/or the work done. Does Andy still read the forums?

I've always preferred to simply use a cover.jpg image in album folders. It's easy to maintain, easy to see how big the existing artwork is, requires less space. The only time that I ever _had_ to use embedded images was when I owned an iPod. Thankfully, I've long since gotten rid of that thing.

Roland0
2013-06-22, 11:02
I'm not positive, but I believe that it does increase both the work done by the server when pre-caching resized artwork during a scan, plus the amount of storage required for the cached images.


It doesn't increase storage size - the size of the cached image is the same, no matter what the source.



Like I say, I'm not 100% certain, but it would take some effort to tell if images embedded in different files are the same, and it would have had to have been done specifically to decrease the cache size and/or the work done.

It doesn't take additional effort for this, as LMS has to check each file for artwork in any case, since it's possible to have different artwork for tracks from the same album. The comparison if it's the same image is done using the path and the embedded art length, and both are known at this point of the processing.

JJZolx
2013-06-22, 11:21
It doesn't increase storage size - the size of the cached image is the same, no matter what the source.

It doesn't take additional effort for this, as LMS has to check each file for artwork in any case, since it's possible to have different artwork for tracks from the same album. The comparison if it's the same image is done using the path and the embedded art length, and both are known at this point of the processing.

How can the cache check use the path, since the path for different audio files will always be unique? Have you looked at the code? The only proper way to check for matches would be to calculate some type of hash value for the binary image data and to store that value in the cache database. But unless that value is already stored in the audio file's metadata that would require calculating it for every single embedded image encountered. That's a lot of additional effort.

Roland0
2013-06-22, 11:48
How can the cache check use the path, since the path for different audio files will always be unique? Have you looked at the code?

see Artwork.pm:


# Find all tracks with un-cached artwork:
# * All distinct cover values where cover isn't 0 and cover_cached is null
# * Tracks share the same cover art when the cover field is the same
# * (same path or same embedded art length).