Could you add an option to always save the images in the mp3's, even those that are looked up automatically by eJukebox (when a song is played for the first time and when the CD Ripper CD cover is auto lookedup) or when I use the Editors "Lookup Album/Image" button?

As you know, I'm in the habit of putting ID3 images in my mp3s. As for recent albums the automatic look up work fine, I leave it to comply. But for those which are more problematics I set manually a local image. So I use both way, that depends. However by worry of homogeneity I would like to be able to save images in my mp3s in any case.
Could you add the option "Always save images in the mp3s"?

Thanks.

I too would like to have all my MP3s have their image attached. One concern though. I notice that during a full rebuild (which has to happen once in a while), it takes a LOT longer re-adding the ones that have their own images. You can see it cruising along, the counter adding so fast you can't read it. Then stop. it sticks at one artist or another. These artists have images in some of their albums. The ones that eJ finds on the net reload instantly. It is taking longer and longer to do a rebuild. I would like to have 'em all perfect with their own images though.

Don

Yes you are right Dyno Don,
It's a pity a full rebuild take a long time when images are in the mp3s. But at the end you are sure to recover ALL your album images. In my case (Internet access quite expensive), I think it's more secure doing like this because even if normally that never happen (you know never to say never...) I don't want to put again the RIGHT image for each album.

[EDIT]
However, I don't want to say the automatic lookup is not a great feature, not at all. I even think to start with it's the most bluffing feature of eJukebox! Especially for those who have a lot of shared mp3s, luckys...

Thanks.

I agree, i also love the automagic lookup feature, but i need to be sure the images will pop up also on machine that are not connected to the internet... so that's one of the reasons i use tag&rename to inject the images into the mp3's...

The other reason is that i have many rare albums which just won't be found by any kind of automatic lookup - 'cause no ones ever sumbitted them. So i surfed the net and found some images, others i have even scanned myself... (god, that's really unhealthy .. i think this is growing into an obsession). :p

it would be a HUGE feature if it could "save all images in mp3 id3 tags". I was going to go through one by one and do it, but if there is a possibility of this feature then I'll just wait! Thanks, James

I just discovered one thing... because i've been having problems with after clicking on an artist album, then clicking back into the Album List and scrolling down, the albums are jumping all over the place, scrolling for the next two minutes. Same thing when i start up eJukebox and try to select an artist by scrolling down in the list - it's impossible. it rolls away the second you spot it.

All my albums have their coverart saved in the mp3 itself, and the reason i am having these problems are that not all are in the same size.

I took a quick check in the temporary internet folder, where eJukebox extracts the images from the id3tags, and saw that the sizes varied greatly, from small 80x83 images to bigger 300x300. dang, i even had some 1024x768 images in there (not injected by me, i swear).

No wonder why my eJukebox is taking 100 mb of RAM to start up.

But! And here's my point - at last.
Why doen't eJukebox just resize the images upon database rebuilding, so they are all saved in the perfect size in the temporary internet files?

That way it's won't have to take bucketloads of RAM and huge CPU load to resize all the different sizes realtime.

Actually, eJukebox does already automatically create 3 different sizes for each image on databse building and stores them in the temporary internet files and in eJukebox database. If you or the system deletes the files from the temp internet folder then they will be recreated from the database when needed.

The following applies only to ID3 Tag encoded images - not eJukebox lookup images:
The reason some are 1024x768 images is because that is the orginal size of the image that was in your ID3 tag or that you added to to your ID3 tag. eJukebox does not modify the original size because i am sure that would piss some people off who want the largest size possible and do not want eJukebox making there images in the tag smaller when they were originally larger. These unresized large images are rarely used by eJukebox, never for onscreen display purposes....they are only used for tag writing purposes when you use the eJukebox editor to "Set Image For All" or when you Browse to set the album cover in the editor. Because these original unresized images are never onscreen they do not use any memory.

Great, it sounds like eJukebox is acting the way i want it to... Yet i'd also like an option where eJukebox saves the uplooked coverart in the mp3 tag, like Pirk proposes. (Sorry for taking the focus away from his initial thread, hope we get back to it soon)

But back to my problem, if the eJukebox only uses the images of the correct size, it doesn explain my scrolling problem. (The albums where the images aren't loaded yet, skyrocket when the images are loaded, making it impossible to click them until all images are loaded.)

Because i notice that some albums, before their album art is displayed, is represented with a blank square that is much shorter than the rest, maybe 1/4 of the lenght if the rest if the blank displays. When these album images are loaded, the list expands to fit them, therefore the scrolling.

Is this theory correct?

Here, i'll show you what i mean instead of doing all that akward explaining. Here you can see the short entries, which i believe cause the jumping, as the list naturally expands to make the images fit once they are displayed.

Hmm... How many albums do you have in your album list? Are most of them eJukebox lookedup images or ID3 tag encoded images? Also how much RAM do you have and what speed CPU?

I have 10 000 mp3's, all of them have their image encoded in their id3 tag.

I have 637 mb DDR-ram, and a AMD XP 2500+ CPU.

OK, The only reason eJukebox is using 100MB+ of RAM in your case is because all your images are non-eJukebox images. Non-eJukebox images currently eat up about 7 times more memory than eJukebox lookup images. This is because, when used for display purposes, eJukebox images are highly compressed where as non-eJ images are currently uncompressed. So when you load up your album list it will increase the amout of RAM used a ton.

Because the cached ID3 image files are about 7 times larger than those of the eJukebox lookedup images...it also takes much longer to read these images from disk into memory when they are needed onscreen...and thus apparently can cause the scrolling...slow loading problems you are experiencing.

We realize that many eJukebox users like yourself have allot of mp3s with only ID3 tag images... so we are going to look into a way to get these images compressed for display so that it lowers the amount of ram used and increases the album list loading speed.

A while back, we updated it so that the images were compressed when inserted into the eJukebox database and when inserted into the ID3 tag using the editor. This change greatly reduced the amount of hard disk space used by the mp3s when ID3 tag images were added using the editor and increased the database performance - now we have to work on reducing the diskspace and memory usage associated with the non-eJukebox lookedup image cache files themselves. I will keep you posted on our progress.

Thanks! This sounds very promising, and i am exited towards this development!

OK, I'm excited too!

But I want to be sure I understand what Audiosoft says:

I think that if Audiosoft had put in the oft-requested option to limit the number of album per page to a user-selected value, e.g. 250, then many of these performance issues would not appear.

Audiosoft, any news on this feature that has been promised for a long time?

It's been a while since i wrote my last post in this thread, and i do believe i know a bit more about the way ejukebox handles things since last time. I also fixed the problem with eJukebox eating my memory; it was due to excessive rebuilding.

So i guess, in reply to your question, Pirk, that eJukebox would extract the coverart from the id3 tag of your mp3s as normal, and do the compression when it adds the file to its own database. Therefore, your id3 tag images would be left unhurt, yet the images in the eJukebox database would be compressed and efficient. I look forward to the day i no longer have to wait a couple of minutes before the album list is rebuilt, after having visited an album...

Yes junk,
I am still candidate for Audiosoft compress ID3 images for display purpose!
Since ALL my images are only ID3 tag images... I am highly concerned by the too long time before I can really use the albumlist at each new display.

Quote:
-----------------------------------------------------
Message original: Audiosoft

We realize that many eJukebox users like yourself have allot of mp3s with only ID3 tag images... so we are going to look into a way to get these images compressed for display so that it lowers the amount of ram used and increases the album list loading speed.
------------------------------------------------------


Audiosoft,
ID3 images compression for display purpose is still "on the works" nowadays?

Thanks.