Hi,

AFAIK, song ratings are currently stored in the local database and NOT in the individual MP3 files. I think if someone makes the effort of correctly tagging his music collection and rating the songs, all the info should be where it belongs, ie. in the files. This has several advantages:

- my music collection is on the server and I access it from different computers. If I rate a track on one machine, the rating would be available on all other machines with a simple library refresh.
- others accessing one\'s collection on a server can also see one\'s ratings (if one wants to keep them from modifying the scores, they simply chmod them).
- people who like to reorganize their collection by moving/renaming files could do so without losing song ratings.

Basically speaking, I think iTunes introduced a fundamentally flawed principle. A lot of valuable information is stored in the local database instead of the files and not kept consistent. Therefore, one ends up with the problem that on the one hand, one has one\'s music files and on the other the local database file and both drift apart. One can no longer move/rename one\'s collection without losing information. Similarly, if the local database is lost or on a different machine, all the information is lost too. I think that instead of creating a location for information pertaining to one\'s music files separate from them, the approach should rather be to keep all the info in the files themselves and use the local DB only as a performance-enhancing measure.

I think a good solution would be a wizard to write all the info from the local database to the ID3 tags (rating, maybe also last played, cover art, lyrics, ...). One could run this from time to time to keep info between local DB and tags consistent. This would be a killer feature for many people who use Amarok in a multi-user or multi-machine setting.

The windows media player does this already, (it is called \"global ratings\", can be enabled optionally) although I don\'t know where exactly in the mp3 files the ratings are stored.

Oh, and BTW, Amarok rocks!

cheers,

Christian

Seriously optional. And definitely OFF by default.

There\'s lots of us who don\'t want amaroK doing anything to our tags. Particularly something that\'s limited to use in one music player.

Post edited by: HairMetalAddict, at: 2005/07/21 19:12

now disadvantages.

Eveyone who has acces to your music has different tastes in music
.

INXS my favourite band will take a scrore pounding when my sister skips it constantly in dynamic mode.



ID3 tags are a set standard and adding a new entry is risky.



only solution is a statement in comment section
however that will interfere with those that use it.


some developer may place
score: 55
score! 55
%55

anything that will stand out and be a flag to find.
in comments section

now disadvantages.

Eveyone who has acces to your music has different tastes in music
.

INXS my favourite band will take a scrore pounding when my sister skips it constantly in dynamic mode.



ID3 tags are a set standard and adding a new entry is risky.



only solution is a statement in comment section
however that will interfere with those that use it.


some developer may place
score: 55
score! 55
%55

anything that will stand out and be a flag to find.
in comments section

as I wrote - if you don\'t want your little sister or your roommate to change your tags/ratings, then just don\'t give them write access to your collection (a good idea anyways).

o keep info between local DB and tags consistent. This would be a killer feature for many people
who use Amarok in a multi-user or multi-machine setting.

Idont you even understand what your asking


I highlighted why it wouldnt work in a multi user environment and you spat a bandaid fix at me.


set higher permissions.


Not very practical how will any environment
but 1 singular user environments benefit from such a feature.


i still say no i dont want this.


Chris share your /home/user/.kde/share/amarok folder
and mount it mount -t smb \\\\chris/amarok /home/anotheruser/.kde/share/

so they both use the same database or sync it.

carl0ski wrote:

Idont you even understand what your asking

Ok, let me explain. I first have a general rant about how all mp3 managers I know of handle their data. I second have a feature suggestion in order to improve amarok moderately in the direction I outlined.

Here\'s the general rant: MP3 managers tend to scatter data about your music all over the place. Some save the cover images in separate files, keep the lyrics textfiles in a separate directory, generate separate peak/BPM files, store last played, user rating in a database separate from the music files and - if they really suck, they only fix track artist and album names only in their database and don\'t apply changes to the id3 tags.
I believe all this data about a track is exactly that - about a track that to top it off provides to store that data directly in the file that it pertains to.
The fact that mp3 managers tend to take the quick way of storing data wherever it\'s most convenient for the programmer instead of where it logically belongs leads to the problem that one becomes locked into using ONE application (since that application doesn\'t make all data available via id3 tags). Plus one becomes locked into accessing one\'s music in only ONE way: through a mp3 manager. People who like to sometimes pick songs in their file/folder structure will like to keep it organized. They might start out with one embarassing Air Suppply song in /My Music/Makeout songs. Months later, they become die-hard Air supply fans and get a bunch more of their songs. Now they create a folder /My Music/Soft and Mellow/Air Supply/Album/ and move the old song to the new Air Supply folder hierarchy - and maybe rename the file (eg. because now they have the whole album and want track numbers in the file name). Now the problem that data isn\'t kept inside the tags becomes apparent - covers, lyrics, ratings, last-played etc are lost (or require lots of manual work to transfer).
When data is kept separately, a source of error is introduced: the reference to the file it pertains to can be broken. Plus it limits the use of that data, since it is no longer enough to make the music collection available, but also the database must be made availabe (and the mount points must be identical so that the references work).
I just think this is simply a stupid design approach. All data should be kept in one place. That makes accessing it and sharing it much more flexible and powerful. It would make accessing your data in single user multi-machine environments much easier. It would also make sharing in multi-user environments much easier (you can easily share _all_ you data, not just the bits that programmers decided to keep in ID3 tags). Write permissions are not simply a band-aid but underlie the concept of sharing your files: if you trust the person you make your data available to, give them full access, otherwise limit them to read-only access. This has nothing to do with keeping you data scattered across several places - thus making it necessary to use a program that can tell you what data (eg rating) belongs to what music file.
If you don\'t trust your little sister, don\'t give her write access. She can use her own ratings that are stored in her own local database, but whenever she tries to run the wizard I propose to sync the data from her local database back to the original music files, she will get a "permission denied" error. So everyone is happy. Tell me if I am missing something here.

Now, my feature request of storing at least ratings in the ID3 tags was just an attempt to get a little closer to the ideal. As I said, I don\'t mind making such a feature optional - in Windows Media Player, it is optional and off by default.

Thanks for sharing your thoughts on this!

cheers,

Chris

how i delete?

Post edited by: carl0ski, at: 2005/07/24 02:42

making mount points the same is quite easy

Symlinks work great.
i used to have a harddrive mounted /mnt/music
but i reformated and moved the music to /mnt/storage/music

iu just made a symlink.


Before even using amarok XMMs days i used to have a whole bunch of symlinks from various albums to /home/carl0ski/Favourites
it doesnt take up any space

how i delete?

Post edited by: carl0ski, at: 2005/07/24 02:42

Just a quick note:

I found out that MediaMonkey does store the ratings in the tags - and is compatible with the Windows Media Player, so there seems to be a (at least quasi-) standard way of storing ratings...

Chris

Which tag is that?

Just want to add my vote to NOT include score in the tags. Or if you absolutely want to, leave a option to keep the score in the database.
Score writen to the tags realy do not fit in a multiuser system.
It is hard to explain a feeling, but it feels wery wrong writing a user spesific value like the score to the object beeing used by several users. So \"windows-ish\" and un-flexible. It should stay clean.
Another case is that would be slower writing to _every_ track you play, than just writing to the database. But I dont know how much.

Post edited by: mortiferus, at: 2005/08/03 02:42

Heh, good point.

hear hear my point exactly

each song can only store one score at a time,
this feature was claimed to increase multiuser experience but it does the exact opposite.

Only one user can write a score. Even if i set the songs to read only for other users, if i were that other user i would be furious that someone would be so stupid to store my likes (actually their likes ) in a read only format i cant change and dynamic mode becomes 100% useless. as it will play someone elses favourite songs.