Swing DJ’s Album & Song Data Base
Moderators: Mr Awesomer, JesseMiner, CafeSavoy
First, some existing resources worth knowing about:
rateyourmusic.com is a place to catalog your collection, rate albums (but not songs), and post reviews. and a bunch of other fun stuff. the design is imperfect, but there's a large/growing community of users. it's fun, though not the tool you're looking for.
http://rateyourmusic.com/~szarka to see my listings (so far).
audioscrobbler.com is potentially a bit more useful. it's track-oriented, rather than album-oriented. it's not based on ratings, but instead on keeping track of which songs you play most. there are plugins for programs like Winamp that will automagically submit your tracks to the database as you play them.
they have friends and groups features in addition to finding your musical "neighbors". also check out last.fm, a related streaming music site.
http://www.audioscrobbler.com/user/szarka/ to see what I'm listening to right now, assuming i'm listening to it on my computer.
I created a <a href="http://www.audioscrobbler.com/group/Swi ... DJs">Swing Dance DJs</a> group for folks here who want to see what we are collectively listening to. also a more general <a href="http://www.audioscrobbler.com/group/Swi ... ers">Swing Dancers</a> group.
check it out.
rateyourmusic.com is a place to catalog your collection, rate albums (but not songs), and post reviews. and a bunch of other fun stuff. the design is imperfect, but there's a large/growing community of users. it's fun, though not the tool you're looking for.
http://rateyourmusic.com/~szarka to see my listings (so far).
audioscrobbler.com is potentially a bit more useful. it's track-oriented, rather than album-oriented. it's not based on ratings, but instead on keeping track of which songs you play most. there are plugins for programs like Winamp that will automagically submit your tracks to the database as you play them.
they have friends and groups features in addition to finding your musical "neighbors". also check out last.fm, a related streaming music site.
http://www.audioscrobbler.com/user/szarka/ to see what I'm listening to right now, assuming i'm listening to it on my computer.
I created a <a href="http://www.audioscrobbler.com/group/Swi ... DJs">Swing Dance DJs</a> group for folks here who want to see what we are collectively listening to. also a more general <a href="http://www.audioscrobbler.com/group/Swi ... ers">Swing Dancers</a> group.
check it out.
I've given a lot of thought to the idea of a specialized Swing DJ database over the past couple of years. Here are some of my general thoughts:
1. It's crucial to separate the concept of a track on an album from, say. the concept of a particular composition or a particular recording of that composition from a particular artist.
2. Likewise, it's crucial to separate the concept of an artist as credited on a particular album from a particular person or group of people.
3. Having made those distinctions, it must be possible to be only as specific as you can confidently be when entering data into the database.
4. The database should include room for documentation so data can be checked and confirmed.
5. Sound samples and cover graphics should be included whenever possible.
Here's an example of how that might work:
Let's say I have a CD called "Frickin Great Pianists of the 40s" and it includes a track called "Moten Swing" credited to "Count Basie"; I also have a CD called "Swingin Mofos" with "Moten Swing" credited to "Count Basie & His Orchestra".
At first, this is all I know about these tracks. They sound the same to me, but that's all I can say about them.
I upload a sound sample of the first track and enter into the database. I link it to the composition identified as "Moten Swing" (maybe also as "Moten's Swing" or some other variant--but with one unique numerical ID), which is already in the database and linked to the person "Benny Moten" with the relationship "Composer". I also link it to the existing performer identified as "Count Basie" (possibly among other things), once as "Leader" and once as "Piano". I also create a new album entry in the database labled "Frickin Great Pianists of the 40s" with the relevant info and a specific release of that album that is a "CD" on the "Budget Wonders" label with serial "12345" and link the track to both of those. I don't know what date this session was recorded, what take it was, or anything else, so I don't create or link to a specific performance.
Later on, perhaps, Jesse comes along and figures out that the track on my CD is from a date on March 1, 1941, so he creates a performance and links it to my track, along with documentation of how he found the info. He also figures out that "Barton Smith IV" played triangle on that date, so he links the track to Mr. Smith as "Percussion".
I undertake a similar process for the other track from the other CD, the only difference being that I link it to the album "Swingin Mofos" and create a release of that album labeled with the appropriate serial number and info.
Maybe later on I figure out that this track is from the same performance as the one Jesse tracked down and I link it appropriately. Maybe it remains a mystery forever--that's OK, we can still turn it up in the database by searching on "Count Basie" (or any variant thereof linked to his ID), "Moten Swing", "Bennie Moten", or the album name, serial number of the CD, etc.
If we want to incorporate ratings, we can apply ratings to a number of things in the database. We can rate songs, composers, artists (including any sidemen--not just the folks credited on the label--if we know about them), specific performances of songs, and even specific releases of specific performances of songs. (To my way of thinking, it's the performances and releases that are of the most interest to us as DJs.)
If you think this is overkill, I encourage you to spend some time at rateyourmusic.com or a similar site and see what kind of problems come up when you don't get this specific. (My CD of Kind of Blue is not your CD of Kind of Blue is not my LP of Kind of Blue is not your German pressing of the LP of Kind of Blue. They're all called the same thing, but do they have the same tracks or the same mixes? Or even the same covers, for that matter?)
I can think of special cases that would be hard to handle in even a scheme like the one above, but even those are doable with the right design. (Two examples: what composition is the first track on Eddie Thompson Trio's CD Ain't She Sweet? and what do you do if there are two separate recordings of a given performance, e.g. a live show?)
1. It's crucial to separate the concept of a track on an album from, say. the concept of a particular composition or a particular recording of that composition from a particular artist.
2. Likewise, it's crucial to separate the concept of an artist as credited on a particular album from a particular person or group of people.
3. Having made those distinctions, it must be possible to be only as specific as you can confidently be when entering data into the database.
4. The database should include room for documentation so data can be checked and confirmed.
5. Sound samples and cover graphics should be included whenever possible.
Here's an example of how that might work:
Let's say I have a CD called "Frickin Great Pianists of the 40s" and it includes a track called "Moten Swing" credited to "Count Basie"; I also have a CD called "Swingin Mofos" with "Moten Swing" credited to "Count Basie & His Orchestra".
At first, this is all I know about these tracks. They sound the same to me, but that's all I can say about them.
I upload a sound sample of the first track and enter into the database. I link it to the composition identified as "Moten Swing" (maybe also as "Moten's Swing" or some other variant--but with one unique numerical ID), which is already in the database and linked to the person "Benny Moten" with the relationship "Composer". I also link it to the existing performer identified as "Count Basie" (possibly among other things), once as "Leader" and once as "Piano". I also create a new album entry in the database labled "Frickin Great Pianists of the 40s" with the relevant info and a specific release of that album that is a "CD" on the "Budget Wonders" label with serial "12345" and link the track to both of those. I don't know what date this session was recorded, what take it was, or anything else, so I don't create or link to a specific performance.
Later on, perhaps, Jesse comes along and figures out that the track on my CD is from a date on March 1, 1941, so he creates a performance and links it to my track, along with documentation of how he found the info. He also figures out that "Barton Smith IV" played triangle on that date, so he links the track to Mr. Smith as "Percussion".
I undertake a similar process for the other track from the other CD, the only difference being that I link it to the album "Swingin Mofos" and create a release of that album labeled with the appropriate serial number and info.
Maybe later on I figure out that this track is from the same performance as the one Jesse tracked down and I link it appropriately. Maybe it remains a mystery forever--that's OK, we can still turn it up in the database by searching on "Count Basie" (or any variant thereof linked to his ID), "Moten Swing", "Bennie Moten", or the album name, serial number of the CD, etc.
If we want to incorporate ratings, we can apply ratings to a number of things in the database. We can rate songs, composers, artists (including any sidemen--not just the folks credited on the label--if we know about them), specific performances of songs, and even specific releases of specific performances of songs. (To my way of thinking, it's the performances and releases that are of the most interest to us as DJs.)
If you think this is overkill, I encourage you to spend some time at rateyourmusic.com or a similar site and see what kind of problems come up when you don't get this specific. (My CD of Kind of Blue is not your CD of Kind of Blue is not my LP of Kind of Blue is not your German pressing of the LP of Kind of Blue. They're all called the same thing, but do they have the same tracks or the same mixes? Or even the same covers, for that matter?)
I can think of special cases that would be hard to handle in even a scheme like the one above, but even those are doable with the right design. (Two examples: what composition is the first track on Eddie Thompson Trio's CD Ain't She Sweet? and what do you do if there are two separate recordings of a given performance, e.g. a live show?)
-
- Posts: 661
- Joined: Wed Nov 20, 2002 2:52 pm
- Location: Saskatoon, Canada
WOW! I think you have a few good points worth consideration. My brain is not quote awake yet this morning, I want to re-read your post before I comment too much.
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.
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.
As for your second post, I'll re-read it a couple more times to make sure I understand it before commenting about the details. 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.
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. Also, we should spend lots of time thinking about a solid design taking into consideration both near-term objectives while still leaving the door open to future enhancements.
Basically, I'd rather design small and simple right now but think forward enough so we won't paint ourselves into too many corners when it comes to future enhancements.
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.
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.
As for your second post, I'll re-read it a couple more times to make sure I understand it before commenting about the details. 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.
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. Also, we should spend lots of time thinking about a solid design taking into consideration both near-term objectives while still leaving the door open to future enhancements.
Basically, I'd rather design small and simple right now but think forward enough so we won't paint ourselves into too many corners when it comes to future enhancements.
-
- Posts: 661
- Joined: Wed Nov 20, 2002 2:52 pm
- Location: Saskatoon, Canada
We've had a few people indicate they'd be willing to help. I'd be willing to take on a role of project lead. If anyone else is interested in leading the project, please post here. Once we select a team lead, we can organize a design/development team and perhaps get started in the new year.
I'm really excited about the response so far, keep the ideas comming!
I'm really excited about the response so far, keep the ideas comming!
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).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.
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...)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.
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!)
<b>This is a classic case of pay now or pay later.</b>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.
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.
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.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.
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.
- LindyChef
- Posts: 228
- Joined: Tue Apr 01, 2003 7:52 pm
- Location: Houston and Seattle (bi-coastal wanna-be)
- Contact:
I've been involved with software design at a number of companies and the one thing that has been consistent among the end users that get involved with the design process is that often requests for complicated functionality end up becoming unused when the software is released. Why? Because they don't want to do the work, or the sofware was designed to what they said, not what they need (there is a difference ... often even end users don't understand exactly what they need ... they have a good idea, but it always needs to be fleshed out and revised).
The issue that I see here is the large amount of data that needs to be entered and stored about individual tracks. Now, I agree that in order for the website to be useful as a website, it needs to be able to identify a track with precise granularity. However, I see some issues that need to be addressed:
1) In order for the information to be useful, it does have to be that detailed. But, are the users of said site going to be vigilant enough to keep this information up to date? To identify them in the first place? I don't think our user base right now would. If you want a site with really up to date and ACCURATE information, then it might be useful to expand the site's target audience, say all jazz lovers.
2) (And most important) In order for the site to be useful as a DJ the information at the site level has to be able to interact with my colleciton. As a digital DJ, I would need some sort of program (possibly DJing software) that would attach itself to my music as a database, where I could use the data when I most need it (i.e. identify the ten different versions of Splanky by Basie that I have). I also might use the time to make comments and would want somehow to upload those comments back to the database.
3) There's gotta be an easier way to start entering information into said DB. A lot of the info is already out there in different formats - CDDB, Allmusic, etc ... there's got to be a way to get that info and use it to our advantage.
4) Said site could get some funding sponsorship by setting up referrer links with Amazon.com ...
The issue that I see here is the large amount of data that needs to be entered and stored about individual tracks. Now, I agree that in order for the website to be useful as a website, it needs to be able to identify a track with precise granularity. However, I see some issues that need to be addressed:
1) In order for the information to be useful, it does have to be that detailed. But, are the users of said site going to be vigilant enough to keep this information up to date? To identify them in the first place? I don't think our user base right now would. If you want a site with really up to date and ACCURATE information, then it might be useful to expand the site's target audience, say all jazz lovers.
2) (And most important) In order for the site to be useful as a DJ the information at the site level has to be able to interact with my colleciton. As a digital DJ, I would need some sort of program (possibly DJing software) that would attach itself to my music as a database, where I could use the data when I most need it (i.e. identify the ten different versions of Splanky by Basie that I have). I also might use the time to make comments and would want somehow to upload those comments back to the database.
3) There's gotta be an easier way to start entering information into said DB. A lot of the info is already out there in different formats - CDDB, Allmusic, etc ... there's got to be a way to get that info and use it to our advantage.
4) Said site could get some funding sponsorship by setting up referrer links with Amazon.com ...
Yes. But the opposite is also true: sometimes a design is generated based on the idea that "we just want to be able to do X" and the limited design that results makes it difficult or impossible later to do Y.LindyChef wrote:I've been involved with software design at a number of companies and the one thing that has been consistent among the end users that get involved with the design process is that often requests for complicated functionality end up becoming unused when the software is released.
Right. That's why the design should enable as much specificity as possible but require no more than necessary. *Requiring* a lot of data from unwilling users results in bad data being entered. (People who have 1/1/01 as a birthdate, for example, or make $999,999 per year because they don't want to share or take time to enter the accurate datum.)Why? Because they don't want to do the work, or the sofware was designed to what they said, not what they need (there is a difference ... often even end users don't understand exactly what they need ... they have a good idea, but it always needs to be fleshed out and revised).
Only a minimum of info *needs* to be entered for a track: identifying the release and specific track on that release, e.g. by entering the UPC. A user could type the UPC (if available) or the label # (if available) or match on the name and select from a list; then either select a track or type it in if the release doesn't yet exist in the database. That's all that's *required* to indentify the track, even though there is much more information we'd eventually want to have about that track that might be entered when it was first added or at any later time.The issue that I see here is the large amount of data that needs to be entered and stored about individual tracks.
The trick is to require only the minimum but leave room for the rest. Entering data isn't actually all that hard. If you look at sites like RYM, Audioscrobbler, MusicBrainz, AllMusic, etc., far more resources are taken up with correcting bad data than with adding good data. So, I say, make it easy for people to add good data, never requires bad data, and develop a culture that values accurate data.1) In order for the information to be useful, it does have to be that detailed. But, are the users of said site going to be vigilant enough to keep this information up to date? To identify them in the first place? I don't think our user base right now would. If you want a site with really up to date and ACCURATE information, then it might be useful to expand the site's target audience, say all jazz lovers.
I think the kind of people who visit this site are far more likely than the average person both to have access to good data and the motivation to enter it. Nor would I want to limit the data to "Jazz", narrowly-defined. I play a lot of Blues, R&B, Soul, etc. on a regular basis, even when I'm DJing for only lindy hoppers.
Where it makes sense to me to leverage people with different interests is in developing the software itself vs. the data. The same back end that works for Jazz will work for Opera, if you leave flexibility in the design, so there's no reason developers interested in other musical domains couldn't participate in that process.
This is a great point.2) (And most important) In order for the site to be useful as a DJ the information at the site level has to be able to interact with my colleciton. As a digital DJ, I would need some sort of program (possibly DJing software) that would attach itself to my music as a database, where I could use the data when I most need it (i.e. identify the ten different versions of Splanky by Basie that I have). I also might use the time to make comments and would want somehow to upload those comments back to the database.
Note that this is a separate issue from how to host to central database, though, especially if the data in that database is made freely available for lookup--or better yet, download as a complete set. As long as your client program can look up a track and obtain a unique identifier for that track (or artist, album, etc.--any object in the db), it can store ratings, notes, bpm, whatever locally and know that it can link it to the entry in the db. So, you could enter information offline while you're DJing to be synced later. Or you could maintain your own set of album reviews and ratings to publish to your own web site.
Once the database scheme is specified, standards for exchanging info with the database or referencing the database via XML can easily be specified.
The problem isn't getting the data, it's vetting it. I've seen one good approach to this--I think it was at Audiobrainz. They have it set up to make it easier to enter info for an album that's new to the database by pulling matches from freedb.org and then allowing the user to pick the best match and then edit that data to make it correct. (I believe they also submit corrections back to freedb.)3) There's gotta be an easier way to start entering information into said DB. A lot of the info is already out there in different formats - CDDB, Allmusic, etc ... there's got to be a way to get that info and use it to our advantage.
True. It's not all that expensive a proposition anyway, if you're not aiming at serving the whole world. I would happily provide free hosting for the site that distributes the software and documentation for the backend code, assuming it's an open source project. Me or someone else could host the development site for the actual database until it needed its own server. I don't see this as a big problem. Developer talent is the scarce resource.4) Said site could get some funding sponsorship by setting up referrer links with Amazon.com ...
- LindyChef
- Posts: 228
- Joined: Tue Apr 01, 2003 7:52 pm
- Location: Houston and Seattle (bi-coastal wanna-be)
- Contact:
You obviously haven't seen some digital DJ's collections ... you can tell who's downloaded music from whom and the digital trail they leave behind lacks a lot of information.szarka wrote:I think the kind of people who visit this site are far more likely than the average person both to have access to good data and the motivation to enter it
re: Software design and large number of users. My point is that, without a good design and a large user base that is willing to spend the time to make this resource worthwhile, then a whole lot of time will be wasted on this project.
I think it's actually the crux of all of this, and I don't see and easy way to link a collection to a site. I have over 1500 CDs worth of data and the time it would take to link up the songs to the songs in the site would be just crazy.This is a great point.2) (And most important) In order for the site to be useful as a DJ the information at the site level has to be able to interact with my colleciton.
-
- Posts: 661
- Joined: Wed Nov 20, 2002 2:52 pm
- Location: Saskatoon, Canada
Martin, I agree 100% with you comments.
Right now we're at the stage where we're just brainstorming ideas so it's a little premature to discount or concretely include anything. At some point before we start building the system, the development team will evaluate the ideas. Based on their merit, value and cost (effort) decide what features should be incorporated and move forward with a design/plan.
Rob, your discussion sounds like you're advocating we build a monster system that solves all problems for everyone.
This is a new project, it's going to be people working in their spare time and probably a variety of skills and expertise. I think we should start by building something small that provides a large return on investment to the community. That doesn't eliminate the option of extending the system in the future.
In terms of the underlying database, that is indeed worth spending some time thinking about. The presentation is also important because that will affect the usability. If it's not easy and intuitive, it will be hard to get anyone to buy into using the system. I think this is one of Martin's key points.
Rob, I do see your point that we don't want to do stupid things early on that make it difficult to extend or improve the system as new needs/applications/improvements are incorporated. It would be nice to have you on the design team since you have some experience with the good the bad and the ugly of similar sites. I'm pretty sure we'll have at least a couple of capable relational database folks so that should help us come up with a sane DB schema.
Oh, one more thing. Martin, I like both your suggestions about leveraging CDDB and interfacing with other (DJ) software. I believe freedb makes off-line snapshots available periodically as well, I've seen libraries to interface with it. In terms of other DJ software, I don't think we want to get into interfacing directly however if we can find a common import/export format that works with most software then it's probably easy to do.
Right now we're at the stage where we're just brainstorming ideas so it's a little premature to discount or concretely include anything. At some point before we start building the system, the development team will evaluate the ideas. Based on their merit, value and cost (effort) decide what features should be incorporated and move forward with a design/plan.
Rob, your discussion sounds like you're advocating we build a monster system that solves all problems for everyone.
This is a new project, it's going to be people working in their spare time and probably a variety of skills and expertise. I think we should start by building something small that provides a large return on investment to the community. That doesn't eliminate the option of extending the system in the future.
In terms of the underlying database, that is indeed worth spending some time thinking about. The presentation is also important because that will affect the usability. If it's not easy and intuitive, it will be hard to get anyone to buy into using the system. I think this is one of Martin's key points.
Rob, I do see your point that we don't want to do stupid things early on that make it difficult to extend or improve the system as new needs/applications/improvements are incorporated. It would be nice to have you on the design team since you have some experience with the good the bad and the ugly of similar sites. I'm pretty sure we'll have at least a couple of capable relational database folks so that should help us come up with a sane DB schema.
Oh, one more thing. Martin, I like both your suggestions about leveraging CDDB and interfacing with other (DJ) software. I believe freedb makes off-line snapshots available periodically as well, I've seen libraries to interface with it. In terms of other DJ software, I don't think we want to get into interfacing directly however if we can find a common import/export format that works with most software then it's probably easy to do.
No, I'm advocating a flexible system that doesn't build invalid and limiting assumptions about the data into the design so it can be used to solve a range of problems; not that we actually solve more than a subset of those problems or that we have to build solutions even for the subset of interest all at once. In particular, though, I think a great deal of that flexibility is a *requirement* for it to be useful to Swing DJs, whereas certain limitations might only be a mild annoyance to a general use audience (like most of the folks who use RYM).Toon Town Dave wrote: Rob, your discussion sounds like you're advocating we build a monster system that solves all problems for everyone.
E.g., the casual user doesn't really care what particular performance/recording of "Flying Home by Lionel Hampton" a given track represents; but a Swing DJ does, because there are at least two distinctly different arrangements and a *wide* variety of tempos (the fastest is perhaps twice as fast as the slowest).
For the record, BTW, I can offer some database design, web design, and system administration type skills, and services like domain name service, to a project like this. I rarely write scripts of more than 100 lines of code, though, so I'm pretty useless for heavy-duty programming.
-
- Posts: 661
- Joined: Wed Nov 20, 2002 2:52 pm
- Location: Saskatoon, Canada
Just to discount your Flying Home example, the second (slower) arrangement is generally know as Flying Home #2.
Anyway, I know what you're saying, I can cite several examples.
Rayned suggested some recording session info. I like that idea, some CDs are really good for including complete session info and that would solve the problem. Some CDs are completely useless for recording session info but there's not much we can do without additional information.
I so understand where you're comming from regarding limiting how a system can expand based on poor assumptions in a data model. I've worked on a number of projects dealing with legacy systems with similar issues. While I don't think it's practical to cover all possible cases, we certainly should consider some of the likely cases. Also, good DB design practice should help us too (eg minimize data redundancy, fields shouldn't contant more than one peice of information (eg don't combine track title and artist in a single field).
![Wink ;)](./images/smilies/icon_wink.gif)
![Razz :P](./images/smilies/icon_razz.gif)
Rayned suggested some recording session info. I like that idea, some CDs are really good for including complete session info and that would solve the problem. Some CDs are completely useless for recording session info but there's not much we can do without additional information.
I so understand where you're comming from regarding limiting how a system can expand based on poor assumptions in a data model. I've worked on a number of projects dealing with legacy systems with similar issues. While I don't think it's practical to cover all possible cases, we certainly should consider some of the likely cases. Also, good DB design practice should help us too (eg minimize data redundancy, fields shouldn't contant more than one peice of information (eg don't combine track title and artist in a single field).
My favorite comment when I do development using python is if it takes more than four lines of codes, it's probably wrongI rarely write scripts of more than 100 lines of code
![Wink ;)](./images/smilies/icon_wink.gif)
Although it's true that some instances of the slower flying home are listed as #2, that is not true in every case (e.g, Tempo and Swing). Only session information lets you identify them. I agree too that session information is not always available so it can't be a required field. and i like the idea of developing a system that has the potential to grow even if it starts slimply. but i think before we go further we have to decide what we want the system to do and what we see as it function. Is it to be like another allmusic.com, help resolve duplication questions, song review or rating, or what?Toon Town Dave wrote:Just to discount your Flying Home example, the second (slower) arrangement is generally know as Flying Home #2.Anyway, I know what you're saying, I can cite several examples.
Rayned suggested some recording session info. I like that idea, some CDs are really good for including complete session info and that would solve the problem. Some CDs are completely useless for recording session info but there's not much we can do without additional information.
I so understand where you're comming from regarding limiting how a system can expand based on poor assumptions in a data model. I've worked on a number of projects dealing with legacy systems with similar issues. While I don't think it's practical to cover all possible cases, we certainly should consider some of the likely cases. Also, good DB design practice should help us too (eg minimize data redundancy, fields shouldn't contant more than one peice of information (eg don't combine track title and artist in a single field).
My favorite comment when I do development using python is if it takes more than four lines of codes, it's probably wrongI rarely write scripts of more than 100 lines of code
In terms of populating the database i think many of us have a good portion of our music in electronic format. it shouldn't be too difficult to import that data. i don't think too many of us would be keen on entering hundreds or thousands of entries.
Not a design question, and not failproof, but an important factor:
The front page, and any other relative pages, should have in big frickin' text a warning to DJs: "Please don't nit-pick. If you only have 20 minutes of your time to contribute, don't add little details and comments of the sort, "I agree with so-and-so" to albums--add a new album to the database!"
The front page, and any other relative pages, should have in big frickin' text a warning to DJs: "Please don't nit-pick. If you only have 20 minutes of your time to contribute, don't add little details and comments of the sort, "I agree with so-and-so" to albums--add a new album to the database!"
Gosh, some of the ideas are getting pretty in-depth.
I still favor something simpler and less of a burden to maintain.
Example,
An album in entered,
Title: Stormy Monday
Aritst: Lou Rawls
Additional Arsts: Les McCann
Review: The initial review is written
Secondary Reviews: Everybody else who wants to write a review can add their voice to the mix.
Anybody who has opinion about the album can submit a review. More akin to a review site with a database structure and multiple reviewers.
You can take things a step further by added additional fields for individual tracks, personal ratings, BPMs, misc notes (track listings) etc...
Maybe, we can do song reviews within the album record.
I also think there are a set number of fields that we need to search on.
Something closer to the purpose of this Board, not AMG.
What music do Swing DJs and dancers like or dislike and why do we like or dislike it?
I still favor something simpler and less of a burden to maintain.
Example,
An album in entered,
Title: Stormy Monday
Aritst: Lou Rawls
Additional Arsts: Les McCann
Review: The initial review is written
Secondary Reviews: Everybody else who wants to write a review can add their voice to the mix.
Anybody who has opinion about the album can submit a review. More akin to a review site with a database structure and multiple reviewers.
You can take things a step further by added additional fields for individual tracks, personal ratings, BPMs, misc notes (track listings) etc...
Maybe, we can do song reviews within the album record.
I also think there are a set number of fields that we need to search on.
Something closer to the purpose of this Board, not AMG.
What music do Swing DJs and dancers like or dislike and why do we like or dislike it?