#musicbrainz

it doesn't take that long to crowd-source the database

luks: this is exactly what would have to be done to be 100% independent

but this would be a slap in the face... so I think it won't be done

if I get it right, echonest gets it's music from 7digital and computes fingerprints out of it?

right know they have a small database

yes, they are trying to integrate fingerprints from the 7digital music collection

but it's not done yet

I've heard they want to allow user submissions too

but they don't their database matched with MBIDs...

Does anyone have an userscript to allow merging recordings / works from the search results?

no

that's what they want MB to do for them

how is that possible?

by name matching?

by people submitting data to MB

just like with PUIDs

but anyway, I don't see any of this happening in near future

ah, but then we still can only submit stuff they already scanned?

who knows, I don't think anybody have figured out how they want to do it

MB has echoprint support without even knowing know "echoprints" really are :)

luks: Isn’t there very little difference between echoprints and PUIDs, from a MB perspective?

hawke_: echoprints are going to give you way more results

Right, but it’s still just a number associated with one or more recordings.

It may be “more” more frequently than with PUIDs, but still the same basic thing

depends on your look at it

you don't have a way to tell "this is a radio edit" or "this is the album version" with the Echoprint

Really? It’s that fuzzy?

So it will be “more” *much* more often than with PUIDs.

I believe it will be useless for automated tagging

luks: so what will it be useful for?

identifying songs

I mean in MB

nothing, IMO :P

Closer to identifying works, than recordings, no?

which is why I don

't see it as a competition

hawke_: not really, if remixes and so are not new works

yes

well, something between recordings and works

luks: So, can we use acoustid at some point to replace PUIDs, perhaps?

jacobbrett: that's my plan

reosarevok: Well, it all depends on how fuzzy it really is. Is there any real measurement/comparison?

reosarevok: It might depend on how different a remix is.

well, currenty it's so fuzzy that will more often give false positives than true positives :P

which will of course change as they build the database

luks: Why would it change significantly?

they will change the matching algorithms

and of course if they have the correct matches, they will score higher

luks: Why would it change? Can a given song get a different echoprint at different times somehow?

hawke_: I don't know what will they end up using

but currently it takes the closest match within some thresholds

which means the ID can change if there happens to be a better match in the database

but I don't know how will they build the database

I expect many things will change before it actually starts being useful

hawke, acousticids are 'designed' to match just one recording of a song, whilst still allowing different encoding of that recording, and for the most part works

not sure that is the aim of echonest ids

ijabz: Yes, that's the intent of the Echonest "TR" IDs.

"We use the TR identifiers to uniquely identify a single audio recording. Different rips, silence at the beginning and end, and analog/digital rips will all result in the same identifier.” —Alastair Porter

Isn’t six-string kinda … standard?

12-string guitar is a different instrument than the six string..

luks: Is it normal for TagLib to throw up warnings about idv2.4 and TDAT, and "MPEG::Header::parse() -- Invalid sample rate."?

but "acoustic guitar" means 6 string

But is the six-string acoustic or electric?

LOL

derwin: 12-string is definitely different, yeah.

and dammit. hrglgrmpf already left

But I would think that an acoustic guitar would be implicitly 6-string.

But why not just say “electric guitar” if it’s electric

And there are also credits for ”electric guitar”

Oh well, I guess just “guitar” it is then.

Who would want to avoid ambiguity when there's a chance for it.

jacobbrett: it doesn't do that if it's compiled in release mode

jacobbrett: but otherwise yes, it's normal

luks: Ah, that was output after I ran it via terminal

Ubuntu PPA

pbryan: that only says that will get the same ID, not what will not

bits of perl code everywhere I imagine :P

and some php

yeah, looks like they use php :/

I really don't think libre.fm had a good start

I gave up on libre.fm, they didn't seem to be going anywhere

"just clone last.fm with all the problems" is not a good goal

heh, yeah

libre.fm is also kind of a pain to use. :-/

nah, too far away. we got lots of space in canada for me to build things, I can put it in an abandoned mine or something

well, first things first, I should see about getting a development copy of the musicbrainz server and DB up and running on my computer.

luks: Not sure I get your point.

if they'd solved some of the last.fm problems, I might have been interested, but it was just like last.fm with less data and less js

I wonder if they ever actually finished their api for getting data back out

pbryan: radio edit and album version of the same song will usually also get the same ID

nikki: and slower :)

i found it amusing, given their listed goals, that they didn't support that initially.

luks: Usually?

huh, memcached is required as well?

seems like a funny thing to install on my laptop :)

are you making the mistake of installing mb_server outside of a VM?

probably, yeah

well, all I really want is the db, I should probably just not bother with the server.

mbslave is usually a less painful way to get the db

virtual machine probably is a better idea, tho :)

mbslave :D

huh, so that's just the import and replication scripts, eh? handy.

There should only be one, standardized RDBMS.

you mean ORACLE? :)

I have several Postgres versions and some Mysql crap all over my server.

kepstin-laptop: and it doesn't require half of cpan to run ;)

and it requires far less disk space to import data

Luckily no Oracle here.

I was working on a large migration from postgresql to oracle at my last job

Haven't had to touch it for a while. 8)

I was crying inside

And laughing outside?

kepstin-labtop I just run the database

just to get a standalone database set up on a linux box to test stuff nowadays requires something like 12gb storage for the installation.

yep

kepstin-laptop: any idea who's been putting these (cv ...) thingies in the join phrase? I guess it's not you but maybe you've seen someone doing it

i've done some of it

really?

I thought you were linking two artists

the "[character] (cv [artist])"? yeah.

I mean "[character] (cv artist)"

not [character (cv artist)] - i don't do that.

huh

I dunno who does that

apparently some people aren't big fans of linking both artists, because they don't want the character song stuff in the artists's own discography or something :/

hmm. we probably could actually use some sort of standard cv artist style to normalize the artist credits on recordings, we have variations of "character (CV artist)" "character (c.v. artist)" "character (artist)", etc.

AAAAAAND we have a new RFC in the works!

Congratulations, kepstin-laptop

not counting the other different variants like "character starring artist" which should be left as-is, probably :/

hey, my last two rfcs have just kind of dies of old age :/

my 'official homepage' for release groups died when one person wanted to 'avoid making a link farm' and nobody else cared :/

kepstin-laptop: was it vetoed or just discouraged?

never got a +1 to get out of RFC stage.