Toon Town Dave wrote:
My initial reaction from rateyourmusic was good. There are lots of neat ideas there, paticularly cross referencing information eg, go from looking at an album's rating and comments to a list of reviews/ratings of other albums from one of the reviewers and so on. I like this because it's relatively easy to implement with a decent relational database in the back-end. I did find the UI at rate your music a little overly complicated and not immediately intuitive although still easy enough to figure out.
I think it's a good general music site--Sharifi has definitely put a lot of work into it and fixed a lot of the problems over the past couple of years. (For example, he added a way to have multiple releases of an album in response to feedback from people like me.) There's been a huge amount work lately on organizing the "Various Artists" releases in a way that makes more sense, but ultimately the album-centric design makes it difficult to do certain kinds of things; and specifically makes it less suitable for DJs who are interested in specific songs. Also, because it's a general music site, it's not optimized for use in a genre-specific way. (It's never been able to deal well with "classical" releases, for example, because of the differing role of composers vs. artists in that genre. This wouldn't be true of the design I've proposed--the schema and the backend code could easily be repurposed for any genre.) Another major problem with the design there is that its concept of an "artist" makes it very difficult to deal with albums that are credited as, e.g., "Brian Eno and Robert Fripp" or "Bill Henderson with the Oscar Peterson Trio". This is another problem my proposed design would address: a release like that would be linked to all artists involved, including the sidemen we know about, so it wouldn't even matter if different releases of the album were credited differently or tracks from the album were credited differently when included on compilations (a common issue).
As for the second link you provided (audioscrobbler), I think it brings up some ideas for a related but different project. In the past I've suggested we could build a more structured way of posting play lists to swingdjs (instead of just tacking inline into a regular post). If a playlist posting tool existed and member's of the SwingDJs community contributed lots of playlists on a regular basis, it could be useful for scoring most and least played recordings, artists, albums, etc. That information could be cross-referenced with the album (CD) database. This IMO is a great looking forward project once we get the album database up, running and stable.
Alan tried to do this at swingtop40.com, but he never got a large, consistent level of participation. There are lots of reasons for that, perhaps, but one of them certainly has to be the awkward way playlists had to be posted. (It just took *way* too much time...)
The problem with aggregating playlists is identifying "songs" and "artists" consistently. What if I write down "Mumbles - Oscar Peterson Trio" and you write down "Mumbles - Clark Terry" and Rayned writes down "Mumbles - Clark Terry w/ Oscar Peterson Trio"? The system has to know that those are all the same exact track. OTOH, what if I write "Splanky - Count Basie" and you write "Splanky - Count Basie", but yours is from the original 78 release and mine is from a radio check?
Alan tried to solve this issue by having folks select tracks from a predefined list. This isn't quite as insane as it sounds, since he was trying only to track "new releases"--something like a traditional chart. But even then, tracks were still entered inconsistently and it was a lot of work.
If we had a pre-existing database against which to check our playlists, it would save some of the work and increase the level of consistency for a project like that. I see the process as starting with the upload of a playlist in a choice of M3U format or comma-delimited file. The program could then check each track against the database and present all the likely matches, asking the DJ to select/confirm each. (Another possibility, for those DJing off their computers, would be to use Musicbrainz to tag files and include that fingerprint, which should improve the program's ability to match tracks.)
In a scenario like that, I'd say that the playlist itself should be stored in a database, including any confirmed track matches. Here's why I say that. If it's a lot of work to go through and confirm matches, folks still won't be consistent about what they upload or they'll be sloppy about the confirmation process. So there ought to be an option that says "take your best guess". The current compilation of the chart for that week or month or what-have-you could use whichever data was good at that moment, but over time its capacity to guess correctly about tracks in previous playlists would improve, so it ought to be possible to go back and regenerate charts from historical data.
Something like audioscrobbler could be an adjunct in several ways. For example, some of us have online "radio" stations ( mine is at
http://www.live365.com/cgi-bin/director ... arka_lindy with a weekly chart available at
http://www.radiowavemonitor.com/lindy_airplay.asp ) that could be included in the charts or charted separately. A tool like audioscrobbler could be used to aggregate listening activity as well as play at dances. (Right now, though, it horribly skews the data--for me, at least, the group of tracks that I play from MP3 on my computer vs. those that I play in the car or elsewhere are very different!)
On the surface, there are some valid ideas worth consideration but overall it sounds like it would be very complex to implement at this point in time.
<b>This is a classic case of pay now or pay later.</b>
Believe me, I've watched sites like RYM and audioscrobbler/last.fm go through this. Bad design at the beginning translates into a huge amount of work to try to sanitize the data after the fact--with some data being lost forever.
One of the considerations that motivates the design I'm proposing is the ability to maximize both the amount of data collected and the quality of the data collected from a universe of users who vary in their personal commitment and standards of accuracy. (Hardcore Swing DJs are very atypical in this respect, I'd wager, but if *only* DJs enter data into the database, it could take forever. And think about some of the alternate sources of data, e.g. the playlist discussion above.) The design I've proposed can handle a data point like "Splanky by Count Basie" without album, performance, etc. info and without having to interpolate the missing data, but it can also handle data like "Splanky performed by Count Basie with Freddy Green on guitar on a radio aircheck broadcast April 5th, 1945 and released on the CD titled 'Freddy Kicks Ass' as track #4" without throwing away any data.
This is our first (apparently) serious attempt at adding some useful and specialized new features to the site. I think a good approach to implementation would be to start with small functionality iteratively add features as our developer team gets more comfortable with the project.
I'd encourage you not to think of it as a feature of this site, but as an open source framework that could be used for many different projects (and thus attract as many developers and users as possible). I would put the effort first into a good design and the ability to store the info that's collected, and only then into the user interface and features that collect and then do something with that data. Otherwise, you pollute the database or collect lower quality data from day one. And if you want to do that, there are plenty of sites out there (like RYM) that already do it and you're reinventing the wheel.
Note, BTW, that RYM has a feature that allows you to export your personal entries. So, if you just want to use that kind of info, it might make more sense for everyone to use RYM to create the data and then just upload the comma-delimited files for aggregation.
You might think, BTW, that the presence of non-Swing data in there might it unsuitable. But if you look at the groups on audioscrobbler that have a critical number of members (maybe as few as 10, certainly 50 is enough), it turns out that the non-related info is noise and pretty much drops out of the "top artists" and "top tracks" listings.