Loading Profile...
CHAMP
Store Ratings using Extended Attributes instead
Summary:
=========
We all know that since songbird stores ratings and play lists in its library file, that people keep losing their ratings (when the library gets corrupt), and other programs have no way of seeing them. However, storing the ratings in ID3 tags presents other serious issues:
1) Greater resource consumption. Files are spliced and cut up to change ratings. Which leads to
2) Greater risk of corrupt music files. Power goes out, song goes corrupt :(
3) Your sisters ratings screw with your own. Also, why is it, that when you send a file over the internet, your mate should get your ratings?
A better way would be to tag the music file itself, without modifying the contents. Think of it as a hidden ID3 tag. This technology is known as Alternate Data streams (windows), extended attributes (linux) or resource forks (OSX). With it, files don't need to be modified to be rated, but ratings are stored in a generic way, so that any application can read them. Furthermore, Abba - waterloo will remain at rating 0 in your collection!
Benefits
=======
1) You can wipe your songbird profile whenever you want. Yay
2) Corrupt songbird profile? WHO CARES!!!
3) You can share your ratings with other media players (once they support this).
4) Low resources required (unlike ID3 tag method).
5) The files data isn't changed, so no corrupt files :D
6) Ratings are separate between users (unlike ID3). You can continue hating Abba songs.
7) MD5 doesn't change. So totally compatible with bittorrent (so NIN will love you).
8) More generic. Extended attribute technologies are standardised.
9) May be able to write ratings to read-only files (unlike ID3 tagging)
10) Import/Export ratings between library and filesystem attributes is easy code.
11) There are tools and archives available to transport these attributes between computers. DMG's are an example
12) Safe enough to use BY DEFAULT :D
Disadvantages
=============
1) Not all filesystems support such technologies. In some situations, the old method may be required.
Summary
=======
Its a better way of storing ratings. You don't risk losing them when you lose your library, you don't risk corrupting files, its efficient, and ratings aren't shared with other users.
=========
We all know that since songbird stores ratings and play lists in its library file, that people keep losing their ratings (when the library gets corrupt), and other programs have no way of seeing them. However, storing the ratings in ID3 tags presents other serious issues:
1) Greater resource consumption. Files are spliced and cut up to change ratings. Which leads to
2) Greater risk of corrupt music files. Power goes out, song goes corrupt :(
3) Your sisters ratings screw with your own. Also, why is it, that when you send a file over the internet, your mate should get your ratings?
A better way would be to tag the music file itself, without modifying the contents. Think of it as a hidden ID3 tag. This technology is known as Alternate Data streams (windows), extended attributes (linux) or resource forks (OSX). With it, files don't need to be modified to be rated, but ratings are stored in a generic way, so that any application can read them. Furthermore, Abba - waterloo will remain at rating 0 in your collection!
Benefits
=======
1) You can wipe your songbird profile whenever you want. Yay
2) Corrupt songbird profile? WHO CARES!!!
3) You can share your ratings with other media players (once they support this).
4) Low resources required (unlike ID3 tag method).
5) The files data isn't changed, so no corrupt files :D
6) Ratings are separate between users (unlike ID3). You can continue hating Abba songs.
7) MD5 doesn't change. So totally compatible with bittorrent (so NIN will love you).
8) More generic. Extended attribute technologies are standardised.
9) May be able to write ratings to read-only files (unlike ID3 tagging)
10) Import/Export ratings between library and filesystem attributes is easy code.
11) There are tools and archives available to transport these attributes between computers. DMG's are an example
12) Safe enough to use BY DEFAULT :D
Disadvantages
=============
1) Not all filesystems support such technologies. In some situations, the old method may be required.
Summary
=======
Its a better way of storing ratings. You don't risk losing them when you lose your library, you don't risk corrupting files, its efficient, and ratings aren't shared with other users.
I’m excited
22
people like this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
-
Inappropriate?This is a genius idea. I wonder if Last.fm would ever incorporate something like this so you could share what you think of a track should you so wish...?
I’m musing aimlessly
1 person thinks
this is one of the best points
-
This reply was removed on 04/03/09.
see the change log -
Inappropriate?Another pro:
Many portable media players don't support ID3 tagging ratings anyway. And some apparently store them using different ID3 rating standards.
So when uploading to devices, the ratings metadata might need to be removed anyway, and replaced with a compatible type1 Comment Add a comment
This is one of the best points
-
AFAIK the ratings metadata doesn't have to be removed. The rating of the device is just added to the ID3, and the songbird-rating is just ignored. I don't see an advantage over ID3 here. -
Inappropriate?Interesting idea.
However, i do not agree:
1.) I NEVER experienced Data loss because of writing the Rating to the Tags... Don't understand you here. I'm writing things into the tags all the time with different OS, never had any problems. You are making such a big deal out of this, so I guess you are having problems some times?
2.) I like it, that the rating is inside the file. I like it, that my friend sees the rating, when I send him an song.
3.) With "hidden ID3 Tag" like in ADS, i would have to care to not loose my ratings when I'm backing up my Collection, moving to another computer, etc... And I use an external drive to use my collection on different machines with different OS. I don't want to use additional tools to make sure my ratings are with my files, every time I switch systems or backup.
4.) The common online storage providers (like skydrive or dropbox), where I use to share, backup, and temporarily move my mp3s do not support ANY kind of extended attribute technologies. I doubt there is a tool for this, that is convenient.
5.) I do not experience any performance issue, when writing a rating to an mp3. Okay, if I would write 100 files at the same time, but why would I mass-tag a rating?! And even if I would have to do this, it wouldn't be often, so I can live with that.
6.) Extended attribute technologies are NOT more standardised than ID3. In both, there simply is no standard for ratings.
The only real advantage I agree with, is the "little Sister"-thing.
More Cons than Pros, imho.
1 person thinks
this is one of the best points
2 Comments Add a comment
This is one of the best points
-
Firstly, I'm not saying don't support ID3, I'm saying this should be another option.
1)If you are writing to a SMB drive and the connection cuts out half way the power goes off, or there is a bug in the metadata handler (there is at least 1 known one atm), you have a greater chance of data corruption.
2) Once again, not saying it has to be done this way, I simply believe this should be default instead of storing the ratings in a weird library file nothing can access.
3) See point 2. Many backup schemes automatically copy ADS/XE/etc anyway.
4) See point 2.
5) I'm not saying performance issues per say, just saying ID tag writing is slower.
6) I was comparing that point against library format.
Unfortunately, I think I didn't make clear which points where against the current library format, and which ones ID3. I am simply proposing instead of using a library file, we default to using XA, but allow a way of shifting between methods.
Also, I never said "don't have ID3 ratings". I don't believe the ID3 ratings makes sense to me, and would prefer this, however, I think it is quite clear that the current way makes no sense to anyone.
you hav a greater , or metadata writing is dodgy for the -
Much clearer now ;)
Of course, things as an option are always good. I guess this can be done by an add-on easily.
But the ADS/XE/etc can probably only be used in songbird, right? The idea behind this is, as you described, not to have the mess with broken profiles etc. (it is really a mess!). So why don't spend the time on implementing an export/import library function? Then it would be easy to migrate the other things, that don't fit into files, like playlists etc, too. I think this would be much more helpful.
I probably wouldn't use your function, because i don't see a benefit over the problems for me, but EVERYTHING is worth a try as an optional add-on or something. Maybe it turns out to be useful, at the end... So maybe someone jumps in an does this. -
Inappropriate?ADS/XE/whatever can be standardised. Using a filesystem watcher, they can all work in parallel IN REALTIME potentially (as the filesystem watcher could maybe monitor XE and stuff too).
Someone could make a C library for this, which any project can integrate and get automatic support.
But I agree, Library exporting/importing would be nice for other things.
1 person thinks
this is one of the best points
-
Inappropriate?Songbird could ask the user (in the preferences) for a unique "metadata prefix/suffix" that would be used for all user-specific metadata. This way, the user could embed non-standard metadata specific to him (for example, the "rating" tag could be called "leetdude154-rating" instead of something generic like "songbird-rating"). With lots of "users", a music file might get cluttered up, but I think it's a good compromise to have both 1) portability from a OS/drive/filesystem to another and 2) no mix-up from a user to the other.
Oh, and don't just store ratings in there. Play count, skip count, last played date, user-specified tags, etc... It could all fit there. -
Inappropriate?So you could specify which tags to associate with which library display fields in different profiles; 2 people could use a shared library and still have their own metadata.For that matter, one person could use two libraries should they need to, for instance classical/contempory or something similar. I like this!
-
1 Comment Add a comment
This is one of the best points
-
And skip count!
-
Inappropriate?Great idea! Besides the benefits already mentioned, it would allow easily sharing ratings between multiple operating systems or over a network. It would be awesome if I could share my ratings between Ubuntu and Windows, and this seems like it would do the trick nicely.
I’m liking this idea
CHAMP
CHAMP
