Version: (using KDE KDE 3.5.5) Installed from: Ubuntu Packages OS: Linux As Linux spreads and multiple users access a common music resource there is some information that might be useful to keep on the music resource itself. As I've learned from other posts, album covers cannot be placed outside users cache when they come from Amazon, but there should be a documented way to automatically select the covers scanned from our albums and placed on the same directory. These files should be moved with the songs when they are organized via Amarok. Besides the covers, the user ratings, comments and all of this metadata should be placed with the music, on a flat file or something like that. I've been using Amarok from many versions now, and I've lost many times my ratings and comments, and by using this method I can backup the info, or even regenerate this metadata with ease. I am not sure if storing metadata inside the files is a good thing, because it should be stored with the username who's qualifying and in a multiple users scenario, this will fill in with garbage of forgotten users.
*** Bug 156585 has been marked as a duplicate of this bug. ***
> I am not sure if storing metadata inside the files is a good thing, because > it should be stored with the username who's qualifying and in a multiple users > scenario, this will fill in with garbage of forgotten users. Yep, songs are completely shareable between users, but that metadata is user data. Not a good idea.
I disagree. Most users do not share their music in a way that more users use the same file. For the majority of users it would be a benefit to have the rating within the file. If you are talking about sharing on the internet, that should not be relevant either. I could argue against having the data in the database, because collections might be shared across users as well. Yet as your case this is only a minor use case and hence not valid compared to the major benefit for most users.
(In reply to comment #3) > I disagree. Most users do not share their music in a way that more users use > the same file. For the majority of users it would be a benefit to have the > rating within the file. Storing the ratings within the file has the big advantage of letting you use your files the way you want across different programs, and that would be awesome. > If you are talking about sharing on the internet, that should not be relevant > either. Ok, but there should be an option to "clean" the files of old user related stuff. > I could argue against having the data in the database, because collections > might be shared across users as well. Yet as your case this is only a minor use > case and hence not valid compared to the major benefit for most users. I'm not sure what are you talking about in this part... but you don't want to store the cover inside the file, do you? Because this will place the cover on every file. Anyway, having the user metadata on a database is the reason I don't qualify my collections any more. There is no easy way to backup that data in case you are reinstalling your computer. I remembered to backup the files, but not Amarok's data. So I changed computers, move everything and when I started to listen to my music all the ratings and covers where gone, and the old computer was already on the way to be a server. If you have a notebook, and you copy the files the ratings, again, lost. There should be a documented way to store the covers, just the way you store a subtitle file with the movie and most players will put them automatically. Your files are your music. So within the file or in a file right there is always the best way to keep them there. I understand what Amazon has done with THEIR stuff. They don't want everybody using the files they have provided to distribute copyrighted material on a criminal way, but this is no reason to STOP US on using OUR files. So let that Amazon thing all hidden in a very deep part of our disk, ok. Geez, I hate this crap. Don't turn us into criminals, PLEASE LET US HANDLE OUR FILES!
(In reply to comment #4) > Storing the ratings within the file has the big advantage of letting you use > your files the way you want across different programs, and that would be > awesome. Why, either you bought it or got it from a free distributor, then there is no rating, or you ripped it from your own CD, then there is no rating either, or it is your own file you rated sometime in the past. Same for comments etc. Of course their could be a file which is allowed to share and you do not get it from the original distributor, but a friend who might have rated it. This is minor and should not hinder the major use case of files not being shared across users, but across devices and hence the rating must be copied with the file. > I'm not sure what are you talking about in this part... but you don't want to > store the cover inside the file, do you? Because this will place the cover on > every file. Actually I do and it is part of ID3V2 (http://www.id3.org/id3v2.3.0#head-70a65d30522ef0d37642224c2a40517ae35b7155) and it enables your mp3-player to show the cover, even if you have several songs from different albums in a single folder. But what I wanted to state is that the argument "ratings must not be in the file because the file is shareable" is not valid on its own, since a) this is not really true/relevant for legal files (see above) and b) it could be used against having a collection database, as it can be shared across users as well.
Sorry, the first part of my comment is a reply to: > Ok, but there should be an option to "clean" the files of old user > related stuff.
(In reply to comment #5) > Why, either you bought it or got it from a free distributor, then there is no > rating, or you ripped it from your own CD, then there is no rating either, or > it is your own file you rated sometime in the past. Of course there might be rating. If the idea of the format spreads across mp3 distributors, all your files will get the record company rating and comments. > Of > course their could be a file which is allowed to share and you do not get it > from the original distributor, but a friend who might have rated it. Allowed? Come on, Amarok should NEVER worry about the origin or legality of the files it's playing because it's not it's responsibility. Don't be the cop for the RIAA and the kind, they have a lousy business plan and a gun in everyones head. They are going to lose in the end, so don't chop your ideas because of them. s is minor and should not hinder the major use case of files not being > shared across users, but across devices and hence the rating must be copied > with the file. > > I'm not sure what are you talking about in this part... but you don't want to > > store the cover inside the file, do you? Because this will place the cover on > > every file. > > Actually I do and it is part of ID3V2 > (http://www.id3.org/id3v2.3.0#head-70a65d30522ef0d37642224c2a40517ae35b7155) > and it enables your mp3-player to show the cover, even if you have several > songs from different albums in a single folder. Ok, then, it's ok with me, put them there. > But what I wanted to state is that the argument "ratings must not be in the > file because the file is shareable" is not valid on its own, since a) this is > not really true/relevant for legal files (see above) and b) it could be used > against having a collection database, as it can be shared across users as well. Please read what I've said: "I am not sure if storing metadata inside the files is a good thing, because it should be stored with the username who's qualifying and in a multiple users scenario, this will fill in with garbage of forgotten users." All the metadata you are placing in the file _must_ be placed with the username who rated it, and commented it. I don't want to buy a file from Apple Store with a rate I cannot identify as NOT MINE. Or comments I don't care of.
> But what I wanted to state is that the argument "ratings must not be in the > file because the file is shareable" is not valid on its own, since a) this is > not really true/relevant for legal files (see above) and b) it could be used > against having a collection database, as it can be shared across users as well. You mean that CD's I've bought and ripped to flac, cannot be shared at home NFS server between multiple computers and users because illegal? Are you serious? In Finland, it's even legal to go to public library, take a CD home for free, take a digital 1-1 copy of it, return the disc to library and keep using your copy at home. Yes, they are communists, but nevertheless that's legal. > For the majority of users it would be a benefit to have the > rating within the file. For a majority, it could be a benefit. I'm just afraid, that somehow it gets implemented in a way that external storage is not possible anymore or that embedded metadata becomes a *problem* to minority. Unix is a multiuser environment, let's not break that. > If you are talking about sharing on the internet, that should not be > relevant either. I agree. Just wonder why did you brought it up? Anything else irrelevant?
(In reply to comment #8) > > But what I wanted to state is that the argument "ratings must not be in the > > file because the file is shareable" is not valid on its own, since a) this is > > not really true/relevant for legal files (see above) and b) it could be used > > against having a collection database, as it can be shared across users as well. > > You mean that CD's I've bought and ripped to flac, cannot be shared at home NFS > server between multiple computers and users because illegal? Are you serious? He brought the legal stuff to a technical issue. I don't believe that. This crap should be away of this topic. > > For the majority of users it would be a benefit to have the > > rating within the file. > > For a majority, it could be a benefit. I'm just afraid, that somehow it > gets implemented in a way that external storage is not possible anymore > or that embedded metadata becomes a *problem* to minority. Unix is a > multiuser environment, let's not break that. I agree absolutely. It may be ok only if this is implemented in a safe way, taking good count that this world is a multiuser environment. > > If you are talking about sharing on the internet, that should not be > > relevant either. > > I agree. Just wonder why did you brought it up? Anything else irrelevant? PLEASE DON'T START PLAYING THE COPS WITH RIAA!!! This is JUST NOT THE PLACE.
> You mean that CD's I've bought and ripped to flac, cannot be shared at home NFS > server between multiple computers and users because illegal? Are you serious? Please read before posting. > For a majority, it could be a benefit. I'm just afraid, that somehow it > gets implemented in a way that external storage is not possible anymore > or that embedded metadata becomes a *problem* to minority. Unix is a > multiuser environment, let's not break that. So what? this bug is for storing it in the file, nothing else, nothing more. Multi-user is not a way to argue against enabling the user storing it in the file to share the rating across devices.
(In reply to comment #10) > > You mean that CD's I've bought and ripped to flac, cannot be shared at home NFS > > server between multiple computers and users because illegal? Are you serious? > > Please read before posting. > > > For a majority, it could be a benefit. I'm just afraid, that somehow it > > gets implemented in a way that external storage is not possible anymore > > or that embedded metadata becomes a *problem* to minority. Unix is a > > multiuser environment, let's not break that. > > So what? this bug is for storing it in the file, nothing else, nothing more. > Multi-user is not a way to argue against enabling the user storing it in the > file to share the rating across devices. No. This bug IS NOT FOR STORING IT IN THE FILE. Is to take it AWAY THE DATABASE. And if the solution is to put it in the file, without identifying the user who rate it, or commented it, this will BREAK A MULTIUSER ENVIRONMENT.
> > For a majority, it could be a benefit. I'm just afraid, that somehow it > > gets implemented in a way that external storage is not possible anymore > > or that embedded metadata becomes a *problem* to minority. Unix is a > > multiuser environment, let's not break that. > I agree absolutely. It may be ok only if this is implemented in a safe way, > taking good count that this world is a multiuser environment. There is ID3V2 standard for rating and amarok should stick to it. Anything else should be put into the DB. > > I agree. Just wonder why did you brought it up? Anything else irrelevant? > PLEASE DON'T START PLAYING THE COPS WITH RIAA!!! This is JUST NOT THE PLACE. Please read on what writing in all-in-capital-letters stands for and stop it! Nothing else to say to comments in that attitude.
(In reply to comment #12) > > > For a majority, it could be a benefit. I'm just afraid, that somehow it > > > gets implemented in a way that external storage is not possible anymore > > > or that embedded metadata becomes a *problem* to minority. Unix is a > > > multiuser environment, let's not break that. > > > I agree absolutely. It may be ok only if this is implemented in a safe way, > > taking good count that this world is a multiuser environment. > > There is ID3V2 standard for rating and amarok should stick to it. Anything else > should be put into the DB. > > > > I agree. Just wonder why did you brought it up? Anything else irrelevant? > > PLEASE DON'T START PLAYING THE COPS WITH RIAA!!! This is JUST NOT THE PLACE. > > Please read on what writing in all-in-capital-letters stands for and stop it! > Nothing else to say to comments in that attitude. Ok. please explain to us what is a "legal file", according to the different laws on every country. Or just get what the real point is and lets get back to Amarok, no legal stuff evoked.
Ok for various reasons mentioned here already we are not going to do this. Please stop the discussion now. It is not going anywhere and just fills people's inboxes and wastes time that could be spend better on other things than reading your discussion while triaging bugs. Thank you.
What are you so hung up about? You started the move to RIAA and all that cliche trash. What I did is to point out that for the majority having the rating in the file is not a problem but a benefit. Further that amarok should stick to the ID3V2 standard and not do its own thing within the music files. the simple fact that files/collections are shareable does not speak against storing the rating in the file. If it would, nothing could be stored within the collection or file, because a collection is shareable too. You made your point about multi-user environments. Those need to be considered, but ID3V2 is standard to stick to and not putting the rating into the file only because of some minority would harm the mahority, which obviously is a bad thing. A simple setting would be enough to enable users to disable the usage, i.e. reading from and writing to, of ratings within files. Of course those will not be able to have those ratings on devices which do not use amarok's DB, but that's the price to pay.
Minority rules the majority, nice move!
Could someone please rename this bug-report or should I file a new one? Summary: Implement ID3V2: Popularimeter (http://www.id3.org/id3v2.3.0#head-2452ec9cf8b42c5c117b518b69e129ff67970852)
(In reply to comment #17) > Could someone please rename this bug-report or should I file a new one? > > Summary: Implement ID3V2: Popularimeter > > (http://www.id3.org/id3v2.3.0#head-2452ec9cf8b42c5c117b518b69e129ff67970852) > File a new one and I will vote for it, and mark this as a duplicate of yours.
http://bugs.kde.org/show_bug.cgi?id= is the new wishlist item asking for standard compliance with id3v2.
Sorry, forgot the most iomportant bit. :( http://bugs.kde.org/show_bug.cgi?id=177853
*** This bug has been marked as a duplicate of bug 177853 ***
It appears that, contrary to the "WONTFIX" claims of developers here, this feature has actually been implemented in Amarok 2.4-GIT. The rating, score, and play count are now written to Ogg Vorbis files in the fields FMPS_RATING, FMPS_RATING_AMAROK_SCORE, and FMPS_PLAYCOUNT, respectively. It doesn't appear that this information is written to MP3 files. (I'm not sure about other formats, as my library is entirely Vorbis and MP3.) However, storing the play count and score introduces an additional problem when synchronizing music collections, for which I have opened Bug 259117. For the sake of consistency, can this bug report be reopened? It makes no sense to store metadata for Vorbis but not MP3.
JFYI: this bug is about the previous Amarok 1.4.x version, not about Amarok 2.x