#musicbrainz

(not filter stop words, I guess?)

all depends on what your searching or how your document is divided up. I've found that if you have a huge blob of text as one of the elements in your document Analyzer are good. If your document is well defined and has atomic fields (could almost go in a db) then it could be bad.

heh.

well, I'm indexing MB's data that comes out of a DB and I'm still impressed.

did you look at search.musicbrainz.org ??

my documents are basically this:

artist:U2

album:October

track:gloria

trackNum:1

duration:343453

then some ids, but that is mostly it.

Probably not the best indexing setup for lucene...

yeah. It's pretty cool.

I'd Really like to mix up Lucene with a Memex or Soundex type algorithm

rj_ wants to do exactly that -- metaphone2, I believe.

using python with Lucene eh.

yep.

I was mainly just testing.

some guys are reimplementing the google desktop in lucene

so far they are saying it's faster.

I'll be using pylucene on the client side for track identification and standard lucene in servlet inside tomcat on the server.

hehehehhe

but who cares if it's faster. BetaMax VHS :)

may be easier to implement in lucene than I thought.

Soundex MetaPhone Refined Soundex and Double Metaphone

bitchen!

I'll probably make use of that!

encode it in a java routine and look up in perl?

naw.

remember the lucene web service I was just talking about?

once its done its going to be open sourced.

yeah

cool

so I will use it and have perl make calls to it to do searches.

that way i can deploy it on its own standalone box.

I'll be looking for a home for the lucene web service and I don't want to go to SF.

any suggestions?

There has been talk of a Lucene server

this is a just a servlet, but should be of some use to someone.

i've got it mostly working now.

SF sucks?

I gotta polish off some sharp edges today and then I'll let people poke at it tomorrow.

SF sucks.

talking about SF. Have you seen gforge?

I haven't looked in ages.

do you think that gforce sucks less than SF?

latest is pretty good. I run it at my job to manage the developers. Since I can't afford SF's or Collabnets service fees.

well. It's got it's quirks. But atleast you not sharing the server with 20 thousand other orgs and companies

does gforge host projects too?

well gforge is sourceforge open source

you just grab the php files

and setup the db

on postgres

adn host it yourself

right.

yeah

I certainly don't want to host it myself.

I just want a place to put the lucene-ws.

they don't host projects.

I guess SF it is.

:(

wow. the TRM server must be dragging butt today.

We got $90 in donations today.

And thanks to _thom_ for making up $50 of that!

It started because I was asking Jay Tuley to link against libmad instead of going through iTunes, so he could write the MBID directly into the file

then I figured if I was going to do that, I ought to give him some beer money or something. Then I decided that since the whole thing depends on MB, I ought to make a matching donation :D

cool!

its really appreciated!

sure, np

So how is Picard coming, in the meantime ;)

on hold for this week.

I'm earning money to pay the bills. :-(

Did that one kid end up doing anything to make it work on OS X?

I hear that

noting came from that yet.

has he been around since, what, a week or so ago? That's when I talked to him last

I'm hoping to work on picard more next week.

Did you check out that thing I mentioned re: unicode support, though?

I remember the conversation, but I don't remember the nick.

remind me on the unicode thing.

Well, I went to the SF page for wxWidget and basically made a feature request (that unicode support work for python bindings on OS X)

and someone replied with a patch, but I compared it and it looked like it was already in the latest in CVS

which I'd downloaded and built with all the required libraries, but it still failed the check for unicode in picard

oh yes.

for the heck of it I tried commenting it out. the app launched and I could pick files, etc, but it wouldn't identify tracks. it would, however, see the MB TRM info in files I'd done using tp_tagger, though

Hmm.

weird.

not sure what to tell you...

I guess I don't really care *what* interface I use, as long as it runs on a mac. The tp_tagger is just a little too clunky (gee, given that it's a demo, not surprising, right? :) to use to tag ALL of my music files

that's why I like iEatBrainz, it has a decent enough UI (and works already) -- it just can't write to files directly, yet. Therefore, why I hope he'll link to libmad

At that point I hope to write some wonky PHP + MySQL thing people could use to help catalog their music (PHP from command line), find dupes, tiebreaker based on encoding method or bit rate or etc etc

cool.

and picard will mature in time. its dicey now, since it depends on so much unstable stuff.

We'll see what he says. If he's too busy to work on iEB, maybe I'll be back looking for some way to make tp_tagger a little more robust

I can't believe people are using tp_tagger. :-)

but for dealing with, you know, thousands of files -- most of which already have pretty decent track info -- ehh

its a test harness for crying out loud!

exactly, heh

I had this idea I wanted to ask you about

See, picard excels at tagging files that have mostly clean data!

from the *client* side, it's more cycles to take an audio fingerprint, right?

yup.

than not taking one, yes.

but from the *server* side, it's more cycles to do a lookup based on artist name, album name, or track name, right?

heh

you see the tradeoff I'm trying to make, this comparision

the answer is not as easy.

Or is it equally difficult (or more so?) to search for a fingerprint ID

on the server side

One single TRM lookup on the server side is not expensive.

But, we have a machine with 5GB of RAM to do that.

heh

And we can't replicate the TRM lookup onto new machines.

since its closed source and the damn thing eats ram for lunch.

so, a metadata only lookup is preferred, since it uses *our* open source tools that can be replicated.

so your license restricts you to only using the actual 'black box' code on one machine?

yup. :-(

the answer to this is lucene.

Oh! Got ya. So in other words, my lookup idea would actually be *really good* by comparison

I've got a picard enabled tagger that uses lucene -- it kicks ASS!

Yeah, I've overheard you guys talking about it

but in the meantime, until it's fit for public consumption

problem is that is requires a 650MB search index.

heh

Do you mean, on the *client* side?

yup. :-)

BitTorrent, baby

So here is my crazy idea. Many free players can use CDDB or something like it, right?

yup.

Well, what if my php id3 reading program could look for those -- and if it found some evidence that this file had been ripped from CD, and looked up via a hash of a CD's index track...

that would be much more conclusive proof that this was probably a track worth looking up via metadata instead of fingerprinting

Besides, have you ever heard The Gourds' version of Gin & Juice?

or King Missile's 'Detachable Penis'?

Two songs which come readily to mind, which people mis-attribute ALL THE FRICKING TIME to the wrong bands

:-)

I've heard an acoustic version of G&J