Size limit for album art

[dnewhous]

Is there a size limit or a resolution limit for the album art that is embedded with flac files that Winamp will find displayable?

[Aminifu]

Hi dnewhous,

In my experience, Winamp has been able to scale (up or down) every image I have tried to use. I prefer high resolution images because they look better scaled to fit in relatively large windows. I have a 23" wide screen monitor, 16:9 aspect ratio, and full 1080i/p HD resolution. However, there are some practical concerns dependent on how you use Winamp.

Since file storage space is no longer an issue, the only limit I'm aware of is RAM memory. Winamp is a 32-bit app and subject to the maximum memory addressing limit for all 32-bit apps. So when using high resolution images (especially when displaying many at the same time), you need to be aware of the memory needs of the images and of all the other things you have Winamp doing so that the 32-bit memory addressing limit (2 GB) is not exceeded. Exceed this limit and Winamp will crash leading to various results. Some harmless and some very bad, it depends on what was going on when the memory limit was exceeded.

Unfortunately, Winamp also holds all relevant image data in memory once an image has been displayed, even if that image is no longer being displayed. This is done to avoid having to render the image again, if the user decides to display it again. This is a holdover from when the rendering process was slow. Winamp is over 15 years old and hardware was not as powerful back then.

So, memory use grows as more images are displayed. The only way to free the memory, holding image data, is to shutdown Winamp. This is the major reason to use relatively low resolution images if you use skins and/or skin views that display many images at the same time. Hopefully, going forward, something will be done to free the memory holding data for images not actively being displayed.

The Flac specs allow for extremely large images, especially when you consider image formats that allow for data compression. Link to Flac specs below, look for information associated with "METADATA_BLOCK_PICTURE".

http://flac.sourceforge.net/format.h..._block_picture

[MrSinatra]

i would add that there is speculation that the more images you embed (as opposed to folder base), and the bigger they are, the more likely winamp is to crash on scans or in general. but nothing has been proven, its based on observation and guesswork.

[Aminifu]

Originally Posted by MrSinatra

i would add that there is speculation that the more images you embed (as opposed to folder base), and the bigger they are, the more likely winamp is to crash on scans or in general. but nothing has been proven, its based on observation and guesswork.

Some users have this speculation. The developer who has looked at this issue, so far does not share this speculation.

Embedding the same album image in each track from that album will use up more drive storage space, but it will not use any more RAM memory space when displayed multiple times (at the same time) or displayed once, than if it was stored once in an album folder.

Once an image is rendered, there should be no need to re-render the same image, already being displayed, just because it was read again from a storage device. Even if it is re-rendered, there should be no need to keep multiple copies of the same data in RAM memory.

The pros and cons of using embedded images and whether this use is prudent considering the stated speculation is a valid discussion. But that has doing to do with the OP's question, imo.

For what it's worth, my collection contains 6,227 mp3s (not flac), each with a medium to high resolution embedded image. I have never had a WA crash during a scan. The few crashes I have had were due to outdated plug-ins. I have seen my WA RAM memory usage exceed 800 MB with this small collection due to the resolution of these images, when I have taken the time to scroll thru each unique image (over 4,000) in the media library, during the same WA session.

IMO, the crash danger is not in how images are stored. This danger is in the memory needs of the images held in memory, along with WA's other memory needs, exceeding the 2 GB addressing limit!

[DrO]

can we not de-rail another thread about this again.

[MrSinatra]

not sure anything is derailed? not sure there was/is a concrete answer either (to the OPs question, outside the 32bit issue).

~6k of songs is not normally enough to provoke the issue imo. i think its a matter of all the things... # of songs, images loaded, kb size of image, resolution of image, etc... and the crash[es] could be on scan or just in normal use, but as mentioned, might be totally unrelated to these factors, altho personally i doubt it.

[Aminifu]

Originally Posted by MrSinatra

... not sure there was/is a concrete answer either (to the OPs question, outside the 32bit issue).

...

What more can be said?

The Flac specs for the image size/resolution that is allowed to be embedded in a file is provided. WA's only image size/resolution limit is the available RAM memory within the total installed on the computer that it is allowed to use (no more than 2 GB minus what WA is using for non-image related things). Unless the computer's installed RAM is very limited and/or being used by other apps, WA should have no problem displaying the largest image, allowed by spec, embedded in a flac file.

The number of images that can be displayed is a different concern. There is no restriction on the number of images allowed to be used to fill up the available RAM memory allocation. WA does nothing to prevent a user from exceeding what is available, except crash. The image storage location has nothing to do with exceeding available RAM and therefore does not matter in this regard.

[MrSinatra]

Originally Posted by Aminifu

What more can be said?

that was my point, it had been answered as well as it could be afaict. you seem to be seeking an argument that i am not.

Originally Posted by Aminifu

The image storage location has nothing to do with exceeding available RAM and therefore does not matter in this regard.

says you. and you may be right, but i would point to the number of people who seem to have a problem with it, and as i suggested in the other thread, it would not surprise me if winamp does things under the hood that aren't obvious. it may load an image for each track instead of each album, etc... again, just speculation to attempt to explain the given facts. (imagine an 8 track album, with 8 different artworks, one embedded in each track. winamp only shows ONE in album view, but are we sure it only loads one? if you deleted the shown one, i am fairly sure the next in line would immediately show)

why not try an experiment? take your current collection and once again slowly load all the artwork into winamp as you have it, as you did before, and see what ram usage you get.

then copy your library, and use mp3tag to delete all embeds, but place one folder jpeg in the album folder, reboot, and see if winamp uses less ram.

i'm only interested in solving the issue, so i'd be happy to hear it was no different, if you said it was so. you could also dupe your embedded library 20 times or so, and see if you could break the scans in.

[Aminifu]

No, I do not wish to start an argument. I really want to mend the rift I helped make between us. I took your post the wrong way. The "was/is" and reading quickly caused me to miss your true meaning. I took the 'was' to mean I did not provide a sufficient answer to what has, as you say, no "concrete" answer.

I agree with DrO that the rest of this post is OT. But not to seem rude, I will answer the part of your post quoted below.

Originally Posted by MrSinatra

why not try an experiment? take your current collection and once again slowly load all the artwork into winamp as you have it, as you did before, and see what ram usage you get.

then copy your library, and use mp3tag to delete all embeds, but place one folder jpeg in the album folder, reboot, and see if winamp uses less ram.

i'm only interested in solving the issue, so i'd be happy to hear it was no different, if you said it was so. you could also dupe your embedded library 20 times or so, and see if you could break the scans in.

The main reason I accept the cons of embedding art is because I do not use the artist - album file storage structure. What I use and why is stated in other posts in other threads.

To conduct the experiments you suggest would require a lot of rearranging and folder creation on my end, so I'm going to decline at this time.

I too would like to know what is going on. But, I'm content (easy cause I don't have the problem) to wait on DrO to take time to dig into it, and to let others, who already have the storage structure and large collections, help with experiments. I'm willing to do what I can that will not seriously disrupt my current setup or take several hours to complete.

You could probably do the 1st experiment yourself faster than me. Copy 6,000 mp3 tracks, spread between 27 folders. Use MP3Tag to embedded a high resolution image in each track (the same or random images, they don't need to be correct) and you will basically have my setup. You already have these files in an artist - album structure, although your folder images may be of lower resolution.

If embedded images, which are never displayed, are being rendered while reading tags during scans, then that should be stopped instead of discouraging the use of embedded images. Although that could be a work-a-round for those with large collections until such a practice, if occurring, is stopped.

I believe holding images in memory that are no longer being displayed, to keep from possibly having to re-render them, is the major issue. Current hardware is so much faster at rendering that this should no longer be a performance concern, imo. I also believe that this, along with other things like re-writing files that do not need to be re-written, will not be changed in the near term. In the meantime, we users have to learn, and use, whatever work-a-rounds there are.

[MrSinatra]

Originally Posted by Aminifu

The main reason I accept the cons of embedding art is because I do not use the artist - album file storage structure. What I use and why is stated in other posts in other threads.

To conduct the experiments you suggest would require a lot of rearranging and folder creation on my end, so I'm going to decline at this time.

it would be very easy to construct an action in mp3tag to automate all that based on tags. since you always say storage is plentiful, you could copy your library and experiment on the copy.

Originally Posted by Aminifu

You could probably do the 1st experiment yourself faster than me. Copy 6,000 mp3 tracks, spread between 27 folders. Use MP3Tag to embedded a high resolution image in each track (the same or random images, they don't need to be correct) and you will basically have my setup. You already have these files in an artist - album structure, although your folder images may be of lower resolution.

my whole contention is based on the art. the vast majority of my images are 200x200 and so i can't setup a real world test. i'd have to use a few fake images that may or may not represent what people really use.

i'd also have to embed them, which is time consuming. its a lot easier (and pertinent) for you to have mp3tag rearrange your files, then me fake images in.

Originally Posted by Aminifu

If embedded images, which are never displayed, are being rendered while reading tags during scans, then that should be stopped instead of discouraging the use of embedded images. Although that could be a work-a-round for those with large collections until such a practice, if occurring, is stopped.

i agree, but i also do things to avoid issues in general. to me, embedding not only is generally unnecessary, (and needlessly redundant) but it also seems to find trouble more often then not. reminds me of APE tags.

Originally Posted by Aminifu

I believe holding images in memory that are no longer being displayed, to keep from possibly having to re-render them, is the major issue. Current hardware is so much faster at rendering that this should no longer be a performance concern, imo. I also believe that this, along with other things like re-writing files that do not need to be re-written, will not be changed in the near term. In the meantime, we users have to learn, and use, whatever work-a-rounds there are.

prob true, altho there is the swollen ram issue, and the scanning issue, and they may or may not be related. i just find it notable that given my ~63k ML, i don't have such crashes of either type, while others who do use HQ images, and embed, do. doesn't mean its the cause, but again, i avoid trouble.

EDIT:

ps. just fyi, strictly speaking i prob interpreted the OP's question wrong. he may have been asking about a limit for art per one individual file, which u answered via the spec/winamps 32bit limitations. but i took his question to mean "given a library of some size" since why would anyone only care about one file, since they are likely to have at least a handful of files, and more likely to have a few hundred to a few thousand. so thats the POV i was making my comments from. given the variable of # of multiple files, thats why i said no concrete answer. but in any case i had np with your answer.

[Aminifu]

Originally Posted by MrSinatra

my whole contention is based on the art. the vast majority of my images are 200x200 and so i can't setup a real world test. i'd have to use a few fake images that may or may not represent what people really use.

i'd also have to embed them, which is time consuming. its a lot easier (and pertinent) for you to have mp3tag rearrange your files, then me fake images in.

After thinking about it some more, I don't think either of us need to do the experiments.

The chances of having more unique images when embedding is higher than when using folder album art. With folder art, one image is used for all the tracks in the folder (usually one folder per album). I agreed that when embedding art, it is more likely that all the tracks from the same album will not have the same image in them, unless they were all embedded at the same time. This is what has happened over time in my collection.

So, I'm pretty sure more RAM would be used faster when embedding as opposed to using folder art, for a given size/resolution of image.

I decided to start a separate thread:

http://forums.winamp.com/showthread.php?t=348677

[Aminifu]

Hi dnewhous,

A little supplement for post #2.

Due to the total about of RAM in a computer and the number of apps running (including the OS), an app may not have the maximum amount of allowable RAM (2 GB in Winamp's case) available to it. If an app attempts to use more RAM than what is available for it (intrudes on another app's RAM) it will also crash, even if it's RAM usage is below it's allowable maximum.

Windows will normally prevent apps from exceeding their RAM limits (allowable or available) by swapping data from RAM to drive storage and back again as needed. Drive storage used in this way is called virtual memory. Virtual memory is a lot slower than RAM, so apps that use a lot of it perform slower. All apps use some virtual memory from time to time during their normal execution.

However, Winamp appears to prevent image data in RAM from being swapped to virtual memory.

In summary, virtual memory does not help Winamp free up RAM used for album art and the total RAM available for Winamp to use can vary a great deal. So, the best answer I can give to your question is to use the smallest size/resolution suitable for the size the artwork will normally be displayed at. Since almost available will fit, set the limit to whatever is practical for your needs.

[MrSinatra]

Originally Posted by Aminifu

After thinking about it some more, I don't think either of us need to do the experiments.

The chances of having more unique images when embedding is higher than when using folder album art. With folder art, one image is used for all the tracks in the folder (usually one folder per album). I agreed that when embedding art, it is more likely that all the tracks from the same album will not have the same image in them, unless they were all embedded at the same time. This is what has happened over time in my collection.

So, I'm pretty sure more RAM would be used faster when embedding as opposed to using folder art, for a given size/resolution of image.

I decided to start a separate thread:

http://forums.winamp.com/showthread.php?t=348677

i am posting in your other thread, but i wanted to address this here. i think you are making assumptions that may or may not be true. in other words, everything you say is plausible, but i don't know if any of it is true or even probable. i'm not even sure if what i said in previous posts is true or not.

if the contention is that winamp is in someway loading EVERY embed as opposed to one per album, then IF true, i don't think it necessarily matters if the art is "the same" or not. the pertinent issue is that each embed is loaded, period. obviously, it all depends on whats going on under the hood.

winamp only shows one art per album (in album views). that much is certain. but it may load more, and certainly does when playing the invdividual tracks. and that would likely have nothing to do with "sameness" b/c winamp makes no art comparisons. it compares text tags, not art.

[for the sake of this hypothetical, i would not be surprised to find out "relevant art file" is a "per track" attribute in BOTH cases, ie folder/embed, but only a problem for embeds b/c that is the case where actual multiple located art files exist, same or not]

for my part, i may or may not be off when i say "if you deleted the shown one, i am fairly sure the next in line would immediately show"

an art refresh might always be required, and then depending WHERE you do it from, (in ML might be different behavior from alt+3), it might be manually or automatically done. and again, its ambiguous as to what really goes on under the hood.

i think an experiment is needed to prove if winamp is indeed using more RAM with embeds than folder art. at this point, i think its a 50/50 shot. it would explain a lot.

it would also be interesting to see if people with a lot of files who have trouble scanning them in, still had the trouble if they deleted the embeds and tried it?

[Aminifu]

I prefer to discuss this in the other thread, but again not to appear rude I'll make a few quick comments here

Originally Posted by MrSinatra

i think you are making assumptions that may or may not be true. in other words, everything you say is plausible, but i don't know if any of it is true or even probable. i'm not even sure if what i said in previous posts is true or not.

Granted. Like I said in the other thread, speculation is fun but the true of things depend on the facts.

Originally Posted by MrSinatra

winamp only shows one art per album (in album views). that much is certain. but it may load more, and certainly does when playing the invdividual tracks. and that would likely have nothing to do with "sameness" b/c winamp makes no art comparisons. it compares text tags, not art.

Not sure what you mean by album views. Views that show albums or album folders? On my system I do not have album folders. When I select a single album for viewing in the media library (based on metadata), more than 1 image is shown if my files for that album (same album tag data) include different embedded images.

Originally Posted by MrSinatra

[for the sake of this hypothetical, i would not be surprised to find out "relevant art file" is a "per track" attribute in BOTH cases, ie folder/embed, but only a problem for embeds b/c that is the case where actual multiple located art files exist, same or not]

As a former programmer, my point about same/unique is that I know that only 1 copy of unique image data needs to be saved in memory (RAM or virtual) no matter how many times that image is displayed at the same time or how many times it is read from another file that uses it. Of course, I do not know if WA follows this design approach.

I also know that image data could be discarded and recreated as needed and/or swapped to and from virtual memory as needed. WA's design does not discard image data in RAM once it is created and appears not to allow it to be swapped to virtual memory.

[MrSinatra]

Originally Posted by Aminifu

On my system, more than 1 image is shown if my files for the same album (same album tag data) include different embedded images.

you need to elaborate here. any given album will ONLY have ONE artwork in the artwork views, assuming it is tagged correctly.

are you saying, that just by virtue of two tracks from the same album having everything in common, except title, track number, and embedded album art, that TWO separate artworks are simultaneously shown for that ONE album in winamp? (ie. two placeholders?)

this would mean that a 20 track album with 20 different embedded artworks would show 20 times!!! is that what you see???

Originally Posted by Aminifu

As a former programmer, my point about same/unique is that I know that only 1 copy of unique image data needs to be saved in memory (RAM or virtual) no matter how many times that image is displayed at the same time or how many times it is read from another file that uses it. Of course, I do not know if WA follows this design approach.

of course! but thats the whole contention isn't it? what i am suggesting and have been suggesting to you and this forum, is that winamp doesn't attempt to determine if one piece of art is "unique" or not from any other one! i am almost certain it does not. ergo, even if the art is the same across all tracks, if it is embedded, it will be seen as multiple uniques imo, b/c it is multiple located, whereas folder art would be seen as one, since it is one location.

Originally Posted by Aminifu

I also know that image data could be discarded and recreated as needed and/or swapped to and from virtual memory as needed. WA's design does not discard image data in RAM once it is created and appears not to allow it to be swapped to virtual memory.

i agree but that isn't speaking to what i said.

[Aminifu]

Originally Posted by MrSinatra

you need to elaborate here. any given album will ONLY have ONE artwork in the artwork views, assuming it is tagged correctly.

Sorry, I was editing that part while you were posting. Please reread that part of the previous post.

By tagged correctly, you mean having the same embedded image. I agreed in the ideal case.

For example, I have 10 files for an album (based on the album tag), 8 have the same embedded image and 2 have different images. I see 3 images when I display a view of this ablum.

[MrSinatra]

Originally Posted by Aminifu

Sorry, I was editing that part while you were posting. Please reread that part of the previous post.

By tagged correctly, you mean having the same embedded image. I agreed in the ideal case.

i'm not sure what you edited, or what you meant at this point. i don't see where the confusion is? i've been talking about views in winamp, not windows folders.

i also have no idea what your last sentence there means?

Originally Posted by Aminifu

Not sure what you mean by album views. Views that show albums or album folders? On my system I do not have album folders.

thats b/c no one does. the whole time i have been discussing views in winamp, where winamp shows album art in the ML. thats where you scroll album art in winamp. where is the confusion?

Originally Posted by Aminifu

When I select a single album for viewing in the media library (based on metadata), more than 1 image is shown if my files for that album (same album tag data) include different embedded images.

For example, I have 10 files for an album (based on the album tag), 8 have the same embedded image and 2 have different images. I see 3 images when I display a view of this ablum.[/

again, explain this.

where/how exactly do you see this? pinpoint the view in ML.

[Aminifu]

Originally Posted by MrSinatra

i agree but that isn't speaking to what i said.

I was not trying to respond point by point in this thread. Just making some quick comments that came to mind.

[MrSinatra]

i'd love for you to upload example files, b/c i'd like to try to recreate.

[Aminifu]

Originally Posted by MrSinatra

again, explain this.

where/how exactly do you see this? pinpoint the view in ML.

Last post by me on this topic in this thread, if that's rude so be it.

In a 3 panel media library view, list of artists on the top left (and whatever other data is shown in that panel), album images on the top right (with album names under the images, some truncated), and list of tracks in the bottom panel (with associated data in the columns selected for that panel).

If I do a directed 'album tag' search for a particular album name (exactly as written in an album tag), I get the album's artist name on the top left, the album's image(s) on the top right, and the list of the album's tracks in the bottom panel. If those listed tracks all have the same embedded image, I see 1 image. If those listed tracks have different embedded images, I see 1 of each image that is different.

Or in the same 3 panel view, if I select an artist in the top left panel, I get all the tracks by that artist listed in the bottom panel. 1 image for each of the different images embedded in those tracks is shown in the top right panel. In one case, I had 14 tracks listed for tracks from 3 albums and 4 images were displayed. 4 instead of 3 were displayed because the embedded image in one of the tracks was a different resolution of the same cover used in the other tracks from the associated album. After I replaced the embedded image that was a different resolution, I now get 3 images displayed (1 for each album).

[MrSinatra]

i'll reply in the other thread:

http://forums.winamp.com/showthread.php?t=348677

i'd appreciate it if you would reply to my points from this thread there, b/c so far you haven't addessed some of them at all.