We are already storing album covers locally, so I find no harm in changing the way we do it.

I have a large collection and there are quite a few albums which have the wrong cover grabbed. I\'m sure others have experienced this too. I then must go and manually set the right one by having it search for similar, or just find the correct one on the internet and use that one.

Now the problem arises when multiple computers are involved. I have more than one computer connect / use the database. They all subsequently have the wrong covers for these albums and you must manually set them...... how annoying. Especially if its like 4 or 5 computers that have this problem. It gets tedious.

If we store the covers in the mysql database then we have the problem solved: every new computer that connects to amaroK doesnt have to fetch covers and it has the fixed ones for those that were incorrect.


Thoughts?



-Feld

I agree,

Another solution would be to add them to the metadate in the file. id3 v2.x provides a facility for this, however I don\'t know if taglib allows it.

There is also the problem that not all formats can be tagged the same way.

Maybe a combination of bath (database and tag when it is possible) would provide the best solution. Adding the cover to the file itself, although increasing the amount of filespace used, would allow the files to be moved from one computer to another (one for home and one for work) where you cannot share the same database.

Hi,

I agree, too.

I think there must be changed something. Storing the cover images in the SQL database might be an option, but I doubt it will work with sqlite due to the amount of data stored.

I don\'t like the idea of storing an image in every mp3/ogg/... file. Just imagine the needed disc space for thousands of tracks.

I\'d suggest that the already present \"images\" table in the database is used for that. AFAIK it currently stores *any* image filename found in your collection folder(s). Don\'t ask me why...
This table already holds the artist/album/path(=image filename) combinations. But I really wonder why it contains *all* images found. Would it make more sense to only store the actual cover image filenames?

Alternatively a new column in the \"tags\" table could be introduced to hold the cover image filename.

Feedback welcome!

Regards,
Andreas

\"Just imagine the needed disc space for thousands of tracks.\"

In my experience, the size of album art is less than 1% the size of an average music file.

I have nearly 20K mp3 files taking up nearly 100G, and the total size of the embedded art in them comes in at around 400Mb. 400Mb of space in this day and age costs a few cents (and my collection, while not as large as some people\'s, is probably above average). Even if you use larger sizes for art I still don\'t see disk space as a huge issue.

The problem is that not all tagging formats support embedded art. Only ID3v2 and whatever mp4 uses do AFAIK. I\'m pretty sure vorbis comments and ape tags don\'t. I guess it could be supported just for the formats that let you do it, since TagLib has support for it.

> and the total size of the embedded art in them comes in at around 400Mb

priceless
I hope this won\'t be used

I agree with the file integration of the album cover. Cover adds a more physical interaction with numeric music, and that\'s very pleasant : you just made a compilation in a new folder and every song has it\'s own cover.
My two cents

Okay, well if this is a problem for SQLite users dont let this be done in SQLite, but only MySQL.

To be honest, SQLite needs to be taken behind a barn and shot several times in the chest with a low powered rifle. It\'s junk. It\'s the Microsoft Access of Unix databases.


Guys: MySQL (on gentoo) using the minimal use flag gets you *JUST* enough MySQL code on your box to allow you to interact with a full blown MySQL server. You dont even have to have the service running. Something like this should be available for binary platforms.... don\'t call it full blown MySQL, but something else....

In either respect, the performance improvements from using MySQL should be more than enough of a reason to git off ur butt and use it



So anyway, my solution is not to embed it in the file yet but give it as an option for MySQL users on the database setup page. \"Store album covers in database\". Something like that.



-Feld

All you need to do is copy your ~/.kde/share/apps/amarok/albumcovers/ to any computer. The covers are all named as a hash of album+artist, so amaroK will use a cover if it sees it there.

still more work then what should be required. This should probably be what, a 10 minute fix in the source to place the covers in the database?

If only I had real coding skills I\'d step in and make my own patch for it. Unfortunately I dont know SQL or your codebase.



-Feld

Or just keep the cover art as folder.jpg in the albums.

I\'m not a SQL expert, but SQL is not really meant to be a replacement for a filesystem.

Post edited by: eean, at: 2006/04/20 21:25

Hi,

I\'ll repeat my previous made suggestion, as nobody commented on that:

I\'d suggest that the already present \"images\" table in the database is used for that. AFAIK it currently stores *any* image filename found in your collection folder(s). Don\'t ask me why...
This table already holds the artist/album/path(=image filename) combinations. But I really wonder why it contains *all* images found. Would it make more sense to only store the actual cover image filenames?

Alternatively a new column in the \"tags\" table could be introduced to hold the cover image filename.


Can somebody, maybe even one of the devs comment on this?
Thanks in advance!

Regards,
Andreas

We (developers) don\'t really follow the forums, or at least not regularly, and not all of us. Such topics are better discussed on the mailing list.

Hi,
I store every cover in the id3tag of my mp3s, so I can play them on every computer, pda, mp3 player or toaster, being able to display it. I don\'t think, there\'s any need for changing the database scheme.
And now something completely different:
Why doesn\'t amarok use these tags? I\'ve a folder called \"Unsorted\" where I store songs from samplers. So I\'ve to put the corresponding cover for every song into this folder and have to assign it in amarok. Editing tags in amarok simply deletes covers and comments. Amarok seems to increase the scale of the small \"cover\" (50x50) for the preview (100x100), which looks ugly. Why not downscaling the real cover? Perhaps there should be the chance to decide which kind of cover to use.
For me intag covers are the most reliable solution. One cover, one world! hä?

Perhaps a little bit out of topic

m0nk