Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
|
posted on 6-21-2003 at 07:51 PM
|
|
|
Option "Always save images in the mp3s"
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.
 Pirk |
|
|
Dyno Don
Member
Posts: 275
Registered: 3-12-2003
Member Is Offline
|
|
posted on 6-22-2003 at 02:03 PM
|
|
|
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
|
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
|
posted on 6-22-2003 at 05:02 PM
|
|
|
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.
Pirk |
|
|
junk
Member
Posts: 480
Registered: 5-10-2003
Location: Norway
Member Is Offline
|
|
posted on 6-23-2003 at 12:45 PM
|
|
|
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
|
|
|
jimmydu3
Junior Member
Posts: 4
Registered: 5-29-2003
Member Is Offline
|
|
posted on 6-28-2003 at 12:47 AM
|
|
|
|
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
|
|
|
junk
Member
Posts: 480
Registered: 5-10-2003
Location: Norway
Member Is Offline
|
|
posted on 6-28-2003 at 09:47 AM
|
|
|
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.
|
|
|
Audiosoft
|
|
posted on 6-28-2003 at 08:14 PM
|
|
|
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.
Audiosoft |
|
|
junk
Member
Posts: 480
Registered: 5-10-2003
Location: Norway
Member Is Offline
|
|
posted on 6-29-2003 at 02:13 AM
|
|
|
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?
|
|
|
junk
Member
Posts: 480
Registered: 5-10-2003
Location: Norway
Member Is Offline
|
|
posted on 6-29-2003 at 04:30 PM
|
|
|
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.
junk has attached this image:
|
|
|
Audiosoft
|
|
posted on 6-30-2003 at 12:09 AM
|
|
|
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?
Audiosoft |
|
|
junk
Member
Posts: 480
Registered: 5-10-2003
Location: Norway
Member Is Offline
|
|
posted on 6-30-2003 at 06:09 AM
|
|
|
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.
|
|
|
Audiosoft
|
|
posted on 6-30-2003 at 07:01 AM
|
|
|
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.
Audiosoft |
|
|
junk
Member
Posts: 480
Registered: 5-10-2003
Location: Norway
Member Is Offline
|
|
posted on 6-30-2003 at 12:17 PM
|
|
|
|
Thanks! This sounds very promising, and i am exited towards this development!
|
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
|
posted on 6-30-2003 at 12:55 PM
|
|
|
OK, I'm excited too!
But I want to be sure I understand what Audiosoft says:
| Quote: | Message original : Audiosoft
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. |
I don't want >>ID3 images<< be compressed when added or edited using eJukebox. But maybe I don't understand accurately what
it's planned to do or even already done?
Most of my ID3 images are 300x300 pixels and I don't want they be damaged by a compression.
Of course, I agree for compression anywhere else in the database or browsing cache!
Thanks.
Pirk |
|
|
Demnos
Member
Posts: 207
Registered: 3-11-2003
Location: Berlin, Germany
Member Is Offline
|
|
posted on 6-30-2003 at 03:04 PM
|
|
|
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?
|
|
|
junk
Member
Posts: 480
Registered: 5-10-2003
Location: Norway
Member Is Offline
|
|
posted on 9-16-2003 at 01:30 PM
|
|
|
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...
|
|
|
Pirk
Posting Freak
Posts: 3976
Registered: 3-11-2003
Location: France
Member Is Offline
|
|
posted on 9-16-2003 at 08:10 PM
|
|
|
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.
Pirk |
|
|
