OK .. So I've got code now that can do the following:

1) randomly select tunes from your Empeg (there is an interface for ranking tunes -- right now the algorithm is just random, but i will likely do other implementations like ordered-by-playcount, etc)
2) look on AllMusic.com for similar artists to the artists of those tunes
3) use the LimeWire API's to search for tunes from those similar artists
4) download the tunes
5) upload them to the Empeg

So my question is this -- Would people like this as a general feature of jEmplode or as a separate application? It will add something like 700k-800k to the size of jEmplode due to the size of the LimeWire libraries (and the fact that it requires XML libraries).

Any opinions?

ms

I would say just make it part of jemplode. Everything else is already in there anyway (logo editor, anime editor, etc). Anyway, you da man for getting that to work. Sounds very cool. Is it smart enough to not download related music that is already on the empeg (AMG says artist a is like artist b, but I already have everything by artist b)?

-Mike

I wish I had songprint ported, but I only half-ported it ... I need a good Java FFT implementation to finish it. Other than that, there's not a very reliable way to dedupe.... I suppose I could do a soundex or metaphone search for the title or something like that. I think what I'll probably do is make these tunes upload into a "You Need To Look At These" playlist so you can hand check them.

I'm also thinking about a couple configuration screens that let you say "Don't download anything by this artist, or on this album" ... something like that. it would also be nice, I think, to add support for ranking tunes -3 to +3 (like TiVo)... That would make my ranking job a lot easier.

That would be stunning. The coolness never ends around here. I agree it should be inside jemplode instead of a separate app.

-Zeke

This sounds like a really neat feature, but I would think that it wouldn't be usefull until it could rank tunes in some way that represented how much you like them. (I realize this is already in your grand-scheme-of-things) My sugestions would be playcount, and number of tunes by and artist.

Definitly put it in emplode. Emplode is after all, made by you and open source. If someone wants it without the added bulk, they could always strip it out.

Matthew

I definitely agree that it will give much better results when it has a smarter ranking algorithm. However, a saving grace here is that one would hope you only put music on your Empeg that you actually like, so even a random algorithm should return somewhat reasonable results.

ms

Not to stroke my own ego too much , but I'm using this thing and it's really cool ... I've already found an artist that I like that I hadn't heard before.

So out of curiosity, what should the default recommender choose from -- Similar Artists, Roots/Influences, Followers, or all of them (see AllMusic.com if you need examples).

ms

Can't you implement it in such a way that Java will deal with it sort of like doing a dlopen(), so that it can be a separate download, but the same app if you choose to use it?

I guess I ws talking more from a packagin/distribution standpoint ... Java is pretty slick about dynamic loading by default, so it won't bring it into memory unless you use it. However, it's pretty handy right now that there's just a single jemplode20.jar and that's it ... If i split it out so it's like a plugin (which I have considered for things like LogoEditor, etc), people would have to download/install those separately. It is definitely an option though.

ms

Maybe you could implement a dynamic download, so that the first time a user selects an option, it would say ``This option isn't currently installed. Would you like to download it now?'', or something to that effect.

Of course, this is just silliness. It probably isn't a huge deal to just cram it in there with the rest of the stuff, as long as you make sure that it can't be used accidentally.

The autoinstall thing would be pretty cool ... I'll probably cram it in for the first version at least, but it's been bugging me that AnimEdit, LogoEdit, and this are all sort of stuck in there (even though they can all be run as totally standalone apps).

This is a spectacular idea! I'm very pleased you're working on this. Now that I have my empeg, I really don't listen to anything else and things get "stale", as others have commented.

Regarding recommendations, I think it would be very cool if this feature created a "recommendations" playlist at the root level, with Artist->Album->track underneath that (optionally?). Anyhow, imagine if, under "recommendations" you had "influenced", "roots", "similar" playlists (again, optionally enabled). Then, by default, when you invoked the process you would get a recommended playlist with sub-playlists for each of the recommendation types. It would also answer the question, a la Amazon, "why was I recommended this?" You would know based on where the entry appeared which recommendation algorithm was used for that particular track.

Sorry if this seems incoherent. What I am saying is that the default should be all three recommendation types, categorized in sub-playlists.

Jim

This is a great idea! When can we get it?

Regarding your question, it depends on how often you will need to update this new code. If its never going to be changed, make it a seperate file. If it is going to be changed a lot, then keep it as part of the jemplode jar. That way it will be updated during the autoupdate to keep things simple.

Sean

if you have to ask "will it ever need to be updated" then you must not use jEmplode very much

oh .. in regards to "when can we get it" .. I'm still working out some kinks .. also there's not much UI on top of it (to speak of). kinks = there are a ton of little variables to be tweaked to make it work reasonably (a vast majority of download attempts on Gnutella fail or are unreasonably slow, but this often isn't discovered until after the download starts -- this is a really easy thing for a person to evaluate and cancel but kind of a pain to do automagically)

I do, but thought that this was external code that is already completed.

majority of download attempts on Gnutella fail or are unreasonably slow

I actually happened to give gnutella a try today, and noticed that there is a site with an ip-address of 66.x.x.x that always has an 'answer' ready for any queries it sees. It returns something like 0_query_string.{exe,.rar.zip,mp3,wav,...} My guess is that the '0' is there to sort it high in the list of results.

Kind of annoying as I'm pretty sure that the label isn't a riaa member and doesn't really care that much about a vinyl record from '91 that pretty much impossible to find.

ps. if anyone has a copy of C'hantal - The Realm that they lost interest in...

Oh .. you don't have to tell me about these annoying people ... there are several variations on this theme. The site that I keep getting responds with whatever you queried for + ".mpg" appended to it.... This almost no reliable way to filter these out in the general case, and it's really frustrating. Why people feel the need to write software like this, I'll never know ... I know it exposes a vulnerability in the network and that's academically interesting, but in a peer-to-peer network, this is just malicious as it basically negates the value of the network. But then, who knows who/what is on the other end of that responder.... Maybe it's our friends at the RIAA But then, they would probably say "stop downloading mp3's from the network and you won't care if it's producing garbage queries"... so touche, I suppose.

I was just being jokeful .. you're correct that the LimeWire stuff is totally 3rd party, and thus, probably won't change as frequently (or at least will change on a different release cycle)

There is one trick you could use, query by "title artist", because pretty much everyone names their files "artist - title" the bad responses should end up with the two reversed (i.e. in query order). This only works until they use the same query, or rewrite the response, and pretend to have an identical copy of a file that someone else has. But then they pick up the bad response generators as well, which will still identify them as fakes.

The thing is that gnutella is conceptually very weak when there are rogue sites. A site can claim to see many peers and accept anyone who connects, but never forward queries or only return faked or rewritten responses. You could even use that to DOS some random other site, i.e. claim that a specific IP has everything ever requested. It just isn't a very solid protocol, and it has several well researched scalability problems.

edit: In the end, the best thing is probably to just generate a nice listing of artist/song suggestions and leave it at that. Someone can print the list out and visit the friendly local record store, or ask friends whether they have or heard of the artist/song, or look for a sample of the music through the various sources on the internet

But then, they would probably say "stop downloading mp3's from the network and you won't care if it's producing garbage queries"... so touche, I suppose.
This implies nothing is legally downloadable, which is provably wrong.

They care only about their rights, and would throw you under the bus in a minute.

In response to your edit -- My approach with this feature is not to provide everyone with an Empeg full of illegal music. Instead, I'm trying to provide a method to find music that you might like in a convenient way. Currently, companies send radio stations samples to play to entice people to buy the CD's. I'm almost never satisfied with the quality of ripping from Gnutella folks, so if I find something I really like, I'll buy the CD and rip what I like onto my Empeg. Can you abuse the feature? Sure... But you can abuse almost anything. Heck, you can record the songs off the radio if you wanted. Of course, occasionally there actually is a good rip of a song .. If I like any other music by that artist, I generally buy the CD ... I do admit to having a few one-hit-wonder mp3's that i couldn't bring myself to buy an entire CD of the person -- oh well

Besides, how else are we to find new music? They sure don't play any on the radio stations where I live.

-Zeke

That's exactly right. Consider your previous comment that you had already found an artist that you like that you didn't know about. In this case, the record companies are likely to sell *more* CDs because you wouldn't have known about them otherwise.

I agree with you. Downloaded stuff is good for "taste testing" new artists, but nothing I keep around. Nearly all of it is encoded at very low rates. Tagging, file naming, and encoding rate inconsistencies make it more trouble than its worth for a "permanent" collection. Even with mp3tag studio, dealing with a bunch of downloaded stuff is a PITA.

That's what is so cool about this project. I can use database recommended files to expand my musical interests. As for printing a list and just going out and buying a bunch of CDs of artists you may not have heard, will anyone really do this? Not often, I would guess. Temporarily using a downloaded file or two to test out new artists and CDs before buying them makes even more sense when you are not familiar with the artist already.

My whole collection is 256 FBR with consistent file names and tags. That's worth something to me, and the only way you can do that is to rip & encode yourself. That means you need to have the CD in your custody.

Jim