Hi, Thought I'd introduce myself. Just installed PyTone 2.2.4 & have it running after a couple of tries. On initial set up I pointed it to 120GB of music which caused some fairly severe performance issues. Anyone have experience with PyTone & a large music collection? I'm new to Python, have been coding with Perl for the last 5 years or so. I have been planning to write a playlist generator which will take additional parameters than what is currently in PyTone (tempo, texture, music style among others). Just starting to get into the code now, so any words of wisdom would of course be more than welcome :) Thanks, Doug.
I'm new to Python, have been coding with Perl for the last 5 years or so. I have been planning to write a playlist generator which will take additional parameters than what is currently in PyTone (tempo, texture, music style among others). Just starting to get into the code now, so any words of wisdom would of course be more than welcome :)
Where are you planning on storing the additional info? I'm also curious about what kind of catagories you will have under "texture." -- Richard A. Smith
Hi Doug, On 01.08.05, Doug Friend wrote:
Thought I'd introduce myself. Just installed PyTone 2.2.4 & have it running after a couple of tries. On initial set up I pointed it to 120GB of music which caused some fairly severe performance issues. Anyone have experience with PyTone & a large music collection?
I've heard of performance problems with huge databases. Maybe optimizing the cache settings helps. Have you tried to increase the cachesize of the bsddb (option "cachesize" in the corresponding database section of the config file). If you observe a performance degradation after a certain time, it may be worth to decrease the database request cache (currently, this is hardcoded in .../services/songdb.py, line 115: self.resultcachesize). I plan to move this to make this configurable via the config file and also to add some statistical output on the cache usage).
I'm new to Python, have been coding with Perl for the last 5 years or so. I have been planning to write a playlist generator which will take additional parameters than what is currently in PyTone (tempo, texture, music style among others). Just starting to get into the code now, so any words of wisdom would of course be more than welcome :)
As Richard has pointed out, the set of tags stored by PyTone is currently limited to the usual track/album/artist/year/genre. Adding more metadata should not be too difficult, however. Jörg
Am Montag, den 01.08.2005, 18:53 +0200 schrieb Joerg Lehmann:
Hi Doug,
On 01.08.05, Doug Friend wrote:
Thought I'd introduce myself. Just installed PyTone 2.2.4 & have it running after a couple of tries. On initial set up I pointed it to 120GB of music which caused some fairly severe performance issues. Anyone have experience with PyTone & a large music collection?
I've heard of performance problems with huge databases. Maybe optimizing the cache settings helps. Have you tried to increase the cachesize of the bsddb (option "cachesize" in the corresponding database section of the config file). If you observe a performance degradation after a certain time, it may be worth to decrease the database request cache (currently, this is hardcoded in .../services/songdb.py, line 115: self.resultcachesize). I plan to move this to make this configurable via the config file and also to add some statistical output on the cache usage).
I'm new to Python, have been coding with Perl for the last 5 years or so. I have been planning to write a playlist generator which will take additional parameters than what is currently in PyTone (tempo, texture, music style among others). Just starting to get into the code now, so any words of wisdom would of course be more than welcome :)
As Richard has pointed out, the set of tags stored by PyTone is currently limited to the usual track/album/artist/year/genre. Adding more metadata should not be too difficult, however.
I'm wondering if the database layer could be written to support for example ZODB. This could improve some things, for example we could avoid trashing the database on powercycle as bsddb likes to do unfortunately. Relatinal dbs would be nice too but a lot more work I suspect. Greets Tino
On Mon, 1 Aug 2005, Doug Friend wrote:
Thought I'd introduce myself. Just installed PyTone 2.2.4 & have it running after a couple of tries. On initial set up I pointed it to 120GB of music which caused some fairly severe performance issues. Anyone have experience with PyTone & a large music collection?
I'm using pytone together with a 70GB music repository comprising 14k songs. pytone, together with snackamp, are the only players that can practically work with this amount of files (all the others I've tried just choke on the metadata management and use hundreds of megabytes just in order to be able to play. That said, updating your repository is hard and I always try to avoid it by going to the filesystem view and updating specific directories (that have been added/changed). The first time, however, you can't do it otherwise.
I'm new to Python, have been coding with Perl for the last 5 years or so. I have been planning to write a playlist generator which will take additional parameters than what is currently in PyTone (tempo, texture, music style among others). Just starting to get into the code now, so any words of wisdom would of course be more than welcome :)
I'm very interested in what you're going to do. I would be interested in the following features/scenarios: + Handling of favorite songs (stars) as I don't think pytone uses this information for its playlist yet. Of course the hard part is finding an algorithm that does what vaious people would expect. What do people expect ? + Auto-tagging files to match genres with songs. I'd love to select 10 songs and have pytone only play similar songs than the ones selected based on the song itself, not a manually added genre-tag. This fixes the problem where you have mixed genre CD's or where the genres are simply too general for most of the music. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Hi Dag, Great feedback, thanks! Richard Smith who's been working on a offshoot of PyTone called What I've started DanceBox & I have been discussing requirements offline for a little bit. We've found the requirements of what I'm trying to do and what he's been working on fit pretty well. Gotta love OpenSource :) What I've started to work on, _very_slowly_, is creating a MySQL back end. As I wrote in my intro, I'm a Python newbie, so this is a serious but so far pleasant learning experience. Richard & I have been planning on posting this to the list & Jorg for comments with the hope that this can be merged into PytONE. What I'm looking to create is a playlist generating engine that will take the following parameters into account: Rating (I'd prefer 1-10) Tempo Texture (how heavy a song is) Time last played (song) Time last played (artist) Musical category Naughty words content Basically, the playlist engine will be kindof like a radiostation in a box. Thanks, Doug. Quoting Dag Wieers <dag@wieers.com>:
On Mon, 1 Aug 2005, Doug Friend wrote:
Thought I'd introduce myself. Just installed PyTone 2.2.4 & have it running after a couple of tries. On initial set up I pointed it to 120GB of music which caused some fairly severe performance issues. Anyone have experience with PyTone & a large music collection?
I'm using pytone together with a 70GB music repository comprising 14k songs. pytone, together with snackamp, are the only players that can practically work with this amount of files (all the others I've tried just choke on the metadata management and use hundreds of megabytes just in order to be able to play.
That said, updating your repository is hard and I always try to avoid it by going to the filesystem view and updating specific directories (that have been added/changed). The first time, however, you can't do it otherwise.
I'm new to Python, have been coding with Perl for the last 5 years or so. I have been planning to write a playlist generator which will take additional parameters than what is currently in PyTone (tempo, texture, music style among others). Just starting to get into the code now, so any words of wisdom would of course be more than welcome :)
I'm very interested in what you're going to do. I would be interested in the following features/scenarios:
+ Handling of favorite songs (stars) as I don't think pytone uses this information for its playlist yet. Of course the hard part is finding an algorithm that does what vaious people would expect. What do people expect ?
+ Auto-tagging files to match genres with songs. I'd love to select 10 songs and have pytone only play similar songs than the ones selected based on the song itself, not a manually added genre-tag.
This fixes the problem where you have mixed genre CD's or where the genres are simply too general for most of the music.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Fri, 5 Aug 2005, Doug Friend wrote:
Great feedback, thanks!
Richard Smith who's been working on a offshoot of PyTone called What I've started DanceBox & I have been discussing requirements offline for a little bit. We've found the requirements of what I'm trying to do and what he's been working on fit pretty well. Gotta love OpenSource :)
I hope it pours back into pytone though.
What I've started to work on, _very_slowly_, is creating a MySQL back end. As I wrote in my intro, I'm a Python newbie, so this is a serious but so far pleasant learning experience.
Well, I hate mysql and my opinion is that too much people use SQL servers for tools that do not require them. Have you looked at sqlite ? At least it does not require you to set up and administer a mysql server and you can have pytone migrate the data instead of requiring the user to do all that. A tool like pytone needs to be self-contained (it can depend on libraries, but not on back-end deamons and othe complexities that most people don't want to be forced into).
Richard & I have been planning on posting this to the list & Jorg for comments with the hope that this can be merged into PytONE. What I'm looking to create is a playlist generating engine that will take the following parameters into account:
Rating (I'd prefer 1-10) Tempo Texture (how heavy a song is) Time last played (song) Time last played (artist) Musical category Naughty words content
Basically, the playlist engine will be kindof like a radiostation in a box.
Seems ok. I wonder if you can filter out if it is only instrumental or contains vocals too :) Or is it possible to even categorize songs into genres by use of a neural network that has been trained on tagged songs. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
for a little bit. We've found the requirements of what I'm trying to do and what he's been working on fit pretty well. Gotta love OpenSource :)
I hope it pours back into pytone though.
Thats the plan.
Well, I hate mysql and my opinion is that too much people use SQL servers for tools that do not require them. Have you looked at sqlite ? At least it does not require you to set up and administer a mysql server and you can have pytone migrate the data instead of requiring the user to do all that.
Dancebox already uses sqlite but Doug wants MySQL. So we will do both. Each backend will be implemented as a different database module. So you can enable or disable whichever databases you want via the config file. -- Richard A. Smith
Am Freitag, den 05.08.2005, 23:41 +0200 schrieb Dag Wieers:
On Fri, 5 Aug 2005, Doug Friend wrote:
Great feedback, thanks!
Richard Smith who's been working on a offshoot of PyTone called What I've started DanceBox & I have been discussing requirements offline for a little bit. We've found the requirements of what I'm trying to do and what he's been working on fit pretty well. Gotta love OpenSource :)
I hope it pours back into pytone though.
What I've started to work on, _very_slowly_, is creating a MySQL back end. As I wrote in my intro, I'm a Python newbie, so this is a serious but so far pleasant learning experience.
Well, I hate mysql and my opinion is that too much people use SQL servers for tools that do not require them. Have you looked at sqlite ? At least it does not require you to set up and administer a mysql server and you can have pytone migrate the data instead of requiring the user to do all that.
A tool like pytone needs to be self-contained (it can depend on libraries, but not on back-end deamons and othe complexities that most people don't want to be forced into).
I still wonder why we cannot just use ZODB here. it is fully integreated with python, you can use it like BSDDB but more reliable - unlike it you can have it read only and also use it over a network, clustered and so on. (Fallback servers via ZEO or load balancing if you really need the power). This would be the self-contained part as requested above. MySQL is just too ugly of a database. If a daemon based rdbms I'd go for postgres. -- Tino Wildenhain <tino@wildenhain.de>
Hi Tino! sorry, I forgot to answer to your previous mail. On 08.08.05, Tino Wildenhain wrote:
I still wonder why we cannot just use ZODB here. it is fully integreated with python, you can use it like BSDDB but more reliable - unlike it you can have it read only and also use it over a network, clustered and so on. (Fallback servers via ZEO or load balancing if you really need the power). This would be the self-contained part as requested above.
Some time ago, I had a look in how much work it would be to switch to the ZODB. The problem at that time was that ZCatalog, which is also needed, was not being distributed separately from Zope. I don't know wheter this is still the case.
MySQL is just too ugly of a database. If a daemon based rdbms I'd go for postgres.
Probably you could write an SQL backend in such a way that it works for SQLite, MySQL and PostreSQL at the same time, so this should not be a major issue. Jörg
MySQL is just too ugly of a database. If a daemon based rdbms I'd go for postgres.
Probably you could write an SQL backend in such a way that it works for SQLite, MySQL and PostreSQL at the same time, so this should not be a major issue.
I've considerd this but I think that it will complicate the code quite a bit. Yes each of these are SQL servers but the details of how they do things is different. SQLite for example does not have data types. Its all dynamic. I feel the cleanest and most maintaible method is seperate databases for each server type. -- Richard A. Smith
On 05.08.05, Doug Friend wrote:
Hi Dag,
Great feedback, thanks!
Richard Smith who's been working on a offshoot of PyTone called What I've started DanceBox & I have been discussing requirements offline for a little bit. We've found the requirements of what I'm trying to do and what he's been working on fit pretty well. Gotta love OpenSource :)
What I've started to work on, _very_slowly_, is creating a MySQL back end. As I wrote in my intro, I'm a Python newbie, so this is a serious but so far pleasant learning experience.
I agree with Dag that PyTone should not rely on any database server running. This was one of things I wanted to avoid when I started the whole project.
Richard & I have been planning on posting this to the list & Jorg for comments with the hope that this can be merged into PytONE.
I'm of course always open to patches. But note that merging means that I get patches in a form which is digestable for me. If I just get a single chunk of new code, which makes changes all over the place, the chances that I can integrate it are rather low.
looking to create is a playlist generating engine that will take the following parameters into account:
Rating (I'd prefer 1-10)
I chose to use 1-5 because I wanted to use stars in the UI and 10 stars are simply not parsable any more. A rating of 10 is hardly possible because this would break the press-one-key rating scheme. So maximally we could have 1-9, which could be represented as *, *+, **, ..., ****+, *****. This would also yield a canonical upgrade scheme from the old system. [1]
Tempo Texture (how heavy a song is) Time last played (song) Time last played (artist) Musical category Naughty words content
Basically, the playlist engine will be kindof like a radiostation in a box.
I would be nice to have something like this. As I wrote in my previous mail to the list, the current code is really not more than a very dirty hack. Jörg [1] Note that any change of the database layout requires an upgrade path. So any patch which changes the layout has to be contain an upgrade routine. See services/songdbs/local.py for examples.
I'm of course always open to patches. But note that merging means that I get patches in a form which is digestable for me. If I just get a single chunk of new code, which makes changes all over the place, the chances that I can integrate it are rather low.
Understood. I haven't submitted any patches because I really don't have a complete solution ready yet. Plus until now there wan't much interest on the list in a SQL setup. Perhaps you can open up a developement branch in svn for things like this? I you are interested in seeing my changes I can produce a patch. It might be best though to wait until Doug and I hash on things a bit more. I have 2 other areas I've worked on as well: One moves the UI code into its own seperate module allowing for mutiple UI's. The second adds the ability to speed up and slow down the play rate of the song by changing the ouput sample rate in the rate conversion module. -- Richard A. Smith
Hi! On 05.08.05, Dag Wieers wrote:
On Mon, 1 Aug 2005, Doug Friend wrote:
Thought I'd introduce myself. Just installed PyTone 2.2.4 & have it running after a couple of tries. On initial set up I pointed it to 120GB of music which caused some fairly severe performance issues. Anyone have experience with PyTone & a large music collection?
I'm using pytone together with a 70GB music repository comprising 14k songs. pytone, together with snackamp, are the only players that can practically work with this amount of files (all the others I've tried just choke on the metadata management and use hundreds of megabytes just in order to be able to play.
Let me just add another data point. Last weekend, I had the pleasure to use PyTone on the yearly reincarnation of the party it was originally written for. We used two databases, one on a local disk with around 7500 songs and one on a NFS share with around 15000 songs. In total this amounted to more than 22500 songs in the "merged" database. The machine is powered by a quite ancient AMD with 700Mhz and has 256MB of RAM. All in all, the perforance was excellent, except for a few issues: - From time to time, there was a dropout in the audio output when PyTone made a database access - During a complete update of the repository these dropouts were quite frequent. Furthermore the log-files sometimes growed to more than 1GB. I had to abort the initial scan of the remote database. - The memory usage of PyTone was initially quite ok (around 140MB), but it was growing slowly and we had to restart PyTone every 12-18 hours (the party ran for about 72 hours). Debugging of the issues is, however, a non-trivial task...
That said, updating your repository is hard and I always try to avoid it by going to the filesystem view and updating specific directories (that have been added/changed). The first time, however, you can't do it otherwise.
Yes, updating single directories would also be what I'd suggest.
I'm new to Python, have been coding with Perl for the last 5 years or so. I have been planning to write a playlist generator which will take additional parameters than what is currently in PyTone (tempo, texture, music style among others). Just starting to get into the code now, so any words of wisdom would of course be more than welcome :)
I'm very interested in what you're going to do. I would be interested in the following features/scenarios:
+ Handling of favorite songs (stars) as I don't think pytone uses this information for its playlist yet. Of course the hard part is finding an algorithm that does what vaious people would expect. What do people expect ?
Oh, it uses the rating, but please don't look at the code. Again, please don't look: it's ugly and probably doesn't do anything reasonable.
+ Auto-tagging files to match genres with songs. I'd love to select 10 songs and have pytone only play similar songs than the ones selected based on the song itself, not a manually added genre-tag.
That's a tough problem which I think is beyond what PyTone can offer. Either you would need a very good tagging scheme and correspondingly good data. There are companies which offer you this kind of service, but it's obvious that this kind of information is not really cheap to get. Alternatively, one could make use of something like AudioScrobbler, which relies on the playback data supplied by the users. But AFAIK there is no interface to get this kind of information for a given set of songs. It even takes a few days to initially generate a recommendation of related artists from your playlist.
This fixes the problem where you have mixed genre CD's or where the genres are simply too general for most of the music.
I agree that genres are not very useful. But a more complex classification scheme may even be less useful if it requires that the user does the classification manually. In general, you are lucky if at least artist/album/title tags are correct, not speaking about tracknumber and year. Jörg
On Mon, 8 Aug 2005, Joerg Lehmann wrote:
On 05.08.05, Dag Wieers wrote:
Let me just add another data point. Last weekend, I had the pleasure to use PyTone on the yearly reincarnation of the party it was originally written for. We used two databases, one on a local disk with around 7500 songs and one on a NFS share with around 15000 songs. In total this amounted to more than 22500 songs in the "merged" database. The machine is powered by a quite ancient AMD with 700Mhz and has 256MB of RAM. All in all, the perforance was excellent, except for a few issues:
- From time to time, there was a dropout in the audio output when PyTone made a database access - During a complete update of the repository these dropouts were quite frequent. Furthermore the log-files sometimes growed to more than 1GB. I had to abort the initial scan of the remote database. - The memory usage of PyTone was initially quite ok (around 140MB), but it was growing slowly and we had to restart PyTone every 12-18 hours (the party ran for about 72 hours).
This conforms with my previous reports :) The first issue only happened to me when updating several database at the same time (which worsens the situation). I used to press u everywhere before I understood the implications :) The second issue was particularly bad since it filled my disk and caused my database to get corrupted when the disk was full. My work-around is to put my music files in different directories (1a, 1b, 1c, 2a, 2b, ...) and create seperate databases for each. So an update can never grow that big. The third issue didn't hit me that hard since I moved the music player to a 1GB system. Since my last reboot 4 days ago, it grew to 358MB of virtual memory and 110MB of residential memory which is less than most other music players after startup :) It would be nice however to see what the 248MB is going to :)
Debugging of the issues is, however, a non-trivial task...
Indeed :/
That said, updating your repository is hard and I always try to avoid it by going to the filesystem view and updating specific directories (that have been added/changed). The first time, however, you can't do it otherwise.
Yes, updating single directories would also be what I'd suggest.
This together with dividing songs over multiple databases/directories makes it quite painless to update.
I'm new to Python, have been coding with Perl for the last 5 years or so. I have been planning to write a playlist generator which will take additional parameters than what is currently in PyTone (tempo, texture, music style among others). Just starting to get into the code now, so any words of wisdom would of course be more than welcome :)
I'm very interested in what you're going to do. I would be interested in the following features/scenarios:
+ Handling of favorite songs (stars) as I don't think pytone uses this information for its playlist yet. Of course the hard part is finding an algorithm that does what vaious people would expect. What do people expect ?
Oh, it uses the rating, but please don't look at the code. Again, please don't look: it's ugly and probably doesn't do anything reasonable.
Don't worry, didn't look at it yet. The main problem with this is what people expect of it. I bet different people have different expected behaviors and matching that with parameters will be very hard. I wonder if other projects succeeded in doing this and how that went. I'm thinking eg. of a slider that you can pull to favor good songs, and options to eg. make unrated songs default to 3 (1=worse, 2=bad, 3=normal, 4=good, 5=favorite). Or what about using stars and o's. So you have: 4 **** favorite 4 3 *** best 3 2 ** good 2 1 * ok 1 0 normal (unrated) 0 shft-1 o doable -1 shft-2 oo bad -2 shft-3 ooo worse -3 shft-4 oooo hate it -4 This would give a much better rating system that can be misused.
+ Auto-tagging files to match genres with songs. I'd love to select 10 songs and have pytone only play similar songs than the ones selected based on the song itself, not a manually added genre-tag.
That's a tough problem which I think is beyond what PyTone can offer. Either you would need a very good tagging scheme and correspondingly good data. There are companies which offer you this kind of service, but it's obvious that this kind of information is not really cheap to get. Alternatively, one could make use of something like AudioScrobbler, which relies on the playback data supplied by the users. But AFAIK there is no interface to get this kind of information for a given set of songs. It even takes a few days to initially generate a recommendation of related artists from your playlist.
I understand. I wonder though if it can be done based on a number of criteria that can be automatically extracted from a song. The same way as rhythm and other criteria can be extracted. It definitely is not something pytone would add, but if it existed it could use this metadata.
This fixes the problem where you have mixed genre CD's or where the genres are simply too general for most of the music.
I agree that genres are not very useful. But a more complex classification scheme may even be less useful if it requires that the user does the classification manually. In general, you are lucky if at least artist/album/title tags are correct, not speaking about tracknumber and year.
Indeed, manual classification other than a subjective/personal rating system is useless. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
On Mon, 8 Aug 2005, Dag Wieers wrote:
On Mon, 8 Aug 2005, Joerg Lehmann wrote:
Oh, it uses the rating, but please don't look at the code. Again, please don't look: it's ugly and probably doesn't do anything reasonable.
Don't worry, didn't look at it yet. The main problem with this is what people expect of it. I bet different people have different expected behaviors and matching that with parameters will be very hard.
I wonder if other projects succeeded in doing this and how that went. I'm thinking eg. of a slider that you can pull to favor good songs, and options to eg. make unrated songs default to 3 (1=worse, 2=bad, 3=normal, 4=good, 5=favorite).
Or what about using stars and o's. So you have:
4 **** favorite 4 3 *** best 3 2 ** good 2 1 * ok 1 0 normal (unrated) 0 shft-1 o doable -1 shft-2 oo bad -2 shft-3 ooo worse -3 shft-4 oooo hate it -4
This would give a much better rating system that can be misused.
Of course this had to be: cannot be misused. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
An excellent Idea Dag, I'll go with this (with a 5 on each side).
Or what about using stars and o's. So you have:
4 **** favorite 4 3 *** best 3 2 ** good 2 1 * ok 1 0 normal (unrated) 0 shft-1 o doable -1 shft-2 oo bad -2 shft-3 ooo worse -3 shft-4 oooo hate it -4
Thanks, Doug. -- doug@r4l.com Register4Less.com Quoting Dag Wieers <dag@wieers.com>:
On Mon, 8 Aug 2005, Dag Wieers wrote:
On Mon, 8 Aug 2005, Joerg Lehmann wrote:
Oh, it uses the rating, but please don't look at the code. Again, please don't look: it's ugly and probably doesn't do anything reasonable.
Don't worry, didn't look at it yet. The main problem with this is what people expect of it. I bet different people have different expected behaviors and matching that with parameters will be very hard.
I wonder if other projects succeeded in doing this and how that went. I'm thinking eg. of a slider that you can pull to favor good songs, and options to eg. make unrated songs default to 3 (1=worse, 2=bad, 3=normal, 4=good, 5=favorite).
Or what about using stars and o's. So you have:
4 **** favorite 4 3 *** best 3 2 ** good 2 1 * ok 1 0 normal (unrated) 0 shft-1 o doable -1 shft-2 oo bad -2 shft-3 ooo worse -3 shft-4 oooo hate it -4
This would give a much better rating system that can be misused.
Of course this had to be: cannot be misused.
Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
_______________________________________________ PyTone-users mailing list PyTone-users@luga.de https://www.luga.de/mailman/listinfo/pytone-users
On 08.08.05, Dag Wieers wrote:
On Mon, 8 Aug 2005, Dag Wieers wrote:
On Mon, 8 Aug 2005, Joerg Lehmann wrote:
Oh, it uses the rating, but please don't look at the code. Again, please don't look: it's ugly and probably doesn't do anything reasonable.
Don't worry, didn't look at it yet. The main problem with this is what people expect of it. I bet different people have different expected behaviors and matching that with parameters will be very hard.
That's the main problem, yes.
I wonder if other projects succeeded in doing this and how that went. I'm thinking eg. of a slider that you can pull to favor good songs, and options to eg. make unrated songs default to 3 (1=worse, 2=bad, 3=normal, 4=good, 5=favorite).
Unrated songs already default to 3 stars.
Or what about using stars and o's. So you have:
4 **** favorite 4 3 *** best 3 2 ** good 2 1 * ok 1 0 normal (unrated) 0 shft-1 o doable -1 shft-2 oo bad -2 shft-3 ooo worse -3 shft-4 oooo hate it -4
shift-1 = ! and so on, so these keybindings cannot work. The o's would be nice, though.
This would give a much better rating system that can be misused.
Of course this had to be: cannot be misused.
Except for the fact that there are 9 levels, I do not see any major difference to the current system. Jörg
On Mon, 8 Aug 2005, Joerg Lehmann wrote:
On 08.08.05, Dag Wieers wrote:
On Mon, 8 Aug 2005, Dag Wieers wrote:
On Mon, 8 Aug 2005, Joerg Lehmann wrote:
Or what about using stars and o's. So you have:
4 **** favorite 4 3 *** best 3 2 ** good 2 1 * ok 1 0 normal (unrated) 0 shft-1 o doable -1 shft-2 oo bad -2 shft-3 ooo worse -3 shft-4 oooo hate it -4
shift-1 = ! and so on, so these keybindings cannot work. The o's would be nice, though.
Indeed. I first thought about 1-9, but that is more awkward. (1 ending up with 4 o's and 4 ending up with 1 o :)) Would ctrl or alt be useful ? Can you trap those keys (instead of checking what character had been used). Since keyboards differ, you can't simply rely on what character was used for input.
This would give a much better rating system that can be misused.
Of course this had to be: cannot be misused.
Except for the fact that there are 9 levels, I do not see any major difference to the current system.
Well, the problem with 1 to 5 is that people might put a different meaning to each number. I am using 5 for 'special songs', 4 for whatever I think is good. With only 2 positive ratings I fear people might be using 3 for something different than unrated. With a negative and positive balanced view, you can have 4 character positions to indicate the rating and it's clear that 0 is unrated/normal. That was the only point I had. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Indeed, manual classification other than a subjective/personal rating system is useless.
Useless for what _you_ guys do with pyTone. For my purposes classification is essential and the core of what Dancebox will do for the user. My classifications are much more specific than what a single field genre allows and allow a song to span mutiple classifications. -- Richard A. Smith
On Mon, 8 Aug 2005, Richard Smith wrote:
Indeed, manual classification other than a subjective/personal rating system is useless.
Useless for what _you_ guys do with pyTone. For my purposes classification is essential and the core of what Dancebox will do for the user. My classifications are much more specific than what a single field genre allows and allow a song to span mutiple classifications.
I should have said a time-waster instead of useless. (unless you have a limited set of files) Can you give a list of different characteristics that you use for classification ? I bet most (if not all) the objective characteristics can be deduced automatically. I've been looking at some literature on this. Search for 'automatic classification of music', 'music fingerprinting' or 'accoustic fingerprinting'. There is much more literature, research and even code examples. Some of the characteristics use only specific frequencies (like what's used for drums), voice recognition patterns to find instrumental music or built neural networks for classification purposes. Characteristics include: perceived tempo (very slow, slow, medium, fast, very fast) mood (happy/neutral/sad) emotion (soft/neutral/aggresive) complexity (low, medium, high) focus (vocals, both, instrumental) or Timbre-related Rhythm-related Pitch-related Based on a good set of characteristics, each of the genres will have upper and lower limits for every characteristic and it's quite possible that some of the genres have an overlap (where a song can fall both in Jazz and Blues genres). I'm pretty sure it can be done (and gradually improved over time) and not limited to just Genre classification (which can be done versus an online database like freedb). Based on user feedback a centralized neural network could be gradually improved to work for the complete set of music that exists digitally. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
I should have said a time-waster instead of useless. (unless you have
a limited set of files) Can you give a list of different characteristics that you use for classification ?
I'd have to say I disagree with this, but basically, I think this is because we're looking for different things. I want to be able to lauch PyTone and have it choose a playlist that I won't have to tweak to any great degree, if at all. For an algorythm to be able to do this, it needs to have intelligent, correct attributes about it's library. Given that two humans rating & scoring music going into the library will likely score subjective characteristics differently, I really doubt a computer system would be effective at this for things other than tempo and maybe instrumental/voice. My larger concern would be false ratings which would cause problems for the playlist engine.
On Tue, 9 Aug 2005, Doug Friend wrote:
I should have said a time-waster instead of useless. (unless you have
a limited set of files) Can you give a list of different characteristics that you use for classification ?
I'd have to say I disagree with this, but basically, I think this is because we're looking for different things.
I want to be able to lauch PyTone and have it choose a playlist that I won't have to tweak to any great degree, if at all. For an algorythm to be able to do this, it needs to have intelligent, correct attributes about it's library.
Sure. It's another playmode, like random or eg. album-play, something the user decides to select. Not something forced upon the user :) Pytone itself would be the 'user' of this information. It reads out the characteristics and match this with other songs. Or more simply it could just use the genre tag(s) (of course automaticaly set by another tool in advance) to find simila songs. If I have visitors at home, I want to play something peacefully and quiet in the background. My prefered way of doing that is simply by selecting 1 or more songs and let pytone play similar songs. No hardrock, no explicit lyrics... :)
Given that two humans rating & scoring music going into the library will likely score subjective characteristics differently, I really doubt a computer system would be effective at this for things other than tempo and maybe instrumental/voice. My larger concern would be false ratings which would cause problems for the playlist engine.
Rate and mood obviously are subjective. Even though one of the paper uses the mood-characteristic for something different, independent of the listener (and automatically deductable). But there is more to a song than just tempo. I bet someone more specialized than me can come up with tens of characteristics. If you simply define those and let it run on your music collection that eg. has a proper genre set. I bet the neural network build from that is useful for most other people as well. And all the songs that are miscategorized can be fed into the neural network to make it better... Of course pytone wouldn't use the neural network, but just use the pre-processed characteristics to find similar songs. And sure the fact that you like this or that song is complementary to all this information. And important to take into consideration as well when queueing songs. BTW Sony and philips already have something like this implemented in some of the music players and it appears to work pretty well. So it's not science fiction :) Sadly there's nothing available in Open Source. Kind regards, -- dag wieers, dag@wieers.com, http://dag.wieers.com/ -- [all I want is a warm bed and a kind word and unlimited power]
Quoting Dag Wieers <dag@wieers.com>:
Sure. It's another playmode, like random or eg. album-play, something
the user decides to select. Not something forced upon the user :)
Exactly.
If I have visitors at home, I want to play something peacefully and quiet in the background. My prefered way of doing that is simply by selecting 1 or more songs and let pytone play similar songs. No hardrock, no explicit lyrics... :)
That's the idea of what I'm working on, only this will be done using the information you've provided about your music once, or updated when it was played again. Certain characteristics of the selection will be user selectable, allowing tempo, texture, song category, naughty word content... to be scaled up or down.
BTW Sony and philips already have something like this implemented in some of the music players and it appears to work pretty well. So it's not science fiction :) Sadly there's nothing available in Open Source.
Do you have more specifics on the products that use these? Do they update a proprietary database within the unit or update the id3 tags? If this _really_ does work reasonably, it might make a good investment for me.
BTW Sony and philips already have something like this implemented in some of the music players and it appears to work pretty well. So it's not science fiction :) Sadly there's nothing available in Open Source.
http://users.skynet.be/solaris/linuxaudio/ Send this dude some e-mail. I bet he will have some really good insight on your auto classification request. His Perceptual Analyser might even be a starting point. -- Richard A. Smith
Useless for what _you_ guys do with pyTone. For my purposes classification is essential and the core of what Dancebox will do for the user. My classifications are much more specific than what a single field genre allows and allow a song to span mutiple classifications.
I should have said a time-waster instead of useless. (unless you have a limited set of files) Can you give a list of different characteristics that you use for classification ?
Sure but remember that my requirements are very specific to partner dance and for use in a dance studio and or a dance party. The concept may be more generally applied to other areas but not my data. The major areas: The dance that can be done to the song The class of dance the song is The fuzzy speed The style of dance - Class is a over all catagory of dances. Latin, Smooth, Swing, Rhythm, Misc - Dance is a specific dance, ChaCha, Rumba, East coast swing, Samba, Foxtrot,etc - Style is a subclass of dance. Some dances have both and International and American style. East coast swing can be single, double or triple time. The beat and speed of the music drives all of these. - Speed is fuzzy in that a song that is fast for one dance may be slow for another but both dances still work for the same song. So you can't just go off of BPM.
I bet most (if not all) the objective characteristics can be deduced automatically. I've been looking at some literature on this. Search for 'automatic classification of music', 'music fingerprinting' or 'accoustic fingerprinting'.
Having something that did this would be cool. For my purposes it dosen't have to be that accurate. I'm expecting the use to do a lot of manual classification up front anyway. One thing I do want to come up with eventually though is some sort of guid for a song such that users can share databases of songs that have previously been classified. -- Richard A. Smith
+ Auto-tagging files to match genres with songs. I'd love to select 10 songs and have pytone only play similar songs than the ones selected based on the song itself, not a manually added genre-tag.
That's a tough problem which I think is beyond what PyTone can offer. Either you would need a very good tagging scheme and correspondingly good data. There are companies which offer you this kind of service, but
I have a RCA Lyra 20gig mp3 player and one of the things you can download from the RCA site is a Windows program called the LyraDJ. It scans your songs with some sort of DSP processing algo and generates playlists based on music that is similar. I was skeptical at first when I ran it but it did a suprising job of classification of like sounding things. In fact, it was good enough that mixes of the same song were grouped together and it was really good at finding duplicates. So such things exist but someone would have to do a lot of research on the processing algos necessary. LyraDJ is free for download but I don't know if you can run it on a generic library of songs. The lyra shows up as a mass storage device though so it might be possible. -- Richard A. Smith
Teilnehmer (6)
-
Dag Wieers -
Doug Friend -
Doug Friend -
Joerg Lehmann -
Richard Smith -
Tino Wildenhain