#musicbrainz

Knio is now known as Knio-dinner

Knio-dinner is now known as Knio

real is now known as real|gone

real|gone is now known as real

Knio1 is now known as Knio

Knio is now known as Knio-sleep

Knio-sleep is now known as knio-sleep

knio-sleep is now known as Knio-sleep

orogor_ is now known as orogor

hey!

hi

So, I was trawling over the MB/FreeDB interface yesterday

and Discid.pm

and I think there's a bug in the way we calculate the FreeDB ID from the TOC.

Uh oh.

causing, at best, false negatives.

at worst, false positives.

is it and edge case?

let me post a couple of files up so you can see what I'm talking about.

ok

edge?

it works for most cases, but not some special cases?

Not that special, no.

ok, go to mb.org/~dave

weird -- it seems to do the right thing most of the time.

uh, better idea: see the files I've dropped on grunt in ~dave

now let me guide you through it...

ready?

almost

whice file first?

FreeDB.pm

k

take a look at sub compute_discid

this is basically the code which FreeDB themselves publish as how to compute a disc id.

k

just above that is ConvertTOCToFreeDBID (which is itself part of Lookup),

i.e. how we calculate it.

basically I think the error is that the right way (AFAICT) is to use the rounded-down position of each track

hence, POSIX::floor in compute_discid

whereas what we've been doing is rounding down each track,

then summing it.

viz: $total_seconds += int($toc[$i + 1] / 75) - int($toc[$i] / 75);

These can give different results.

Now, if you run test.pl (it should just run straight off),

you'll see it trying out this theory.

it spits out approx 76 lines of output, twice.

mb.pm is missing

you can probably comment that out - or just point it towards your mb_server

The first set of lines represents one test album I chose. In this case, all the IDs match - i.e. our calculation yields the right result.

hence, the output lines end in "Y" (== a good match)

for the second set, the values don't match ("n")

So basically I think we've been doing it wrong for a while; the good news: we can easily fix the algorithm.

The bad news: has this introduced any bad data into the db?

So far, I don't know.

gimme a sec -- i need to move the files to a location where I can copy the modules

ok

(I'm done setting out my case now, so I'll go quiet now :-)

ok, I'll tinker and observe and think

thanks

(Just out of interest: this arose because I wanted to test Discid.pm. What I was trying to do was find a FreeDB entry, then work out what request to make to MB to cause it to fetch it from FreeDB)

(Straight away I found a "bad" case :-( with no match, when there should have been one)

ok, forget copying to another dir.

Ok

I see what you're saying.

I don't think it will have introduced bad data into MB.

If a bad id was calculated, then one of the following would've happened:

1. The CD was not found.

2. The FreeDB fuzzy matching algorithm matched it up anyways.

3. A wrong CD was returned for moderation or the user.

Case #3 is the worst here, no doubt. But that means that a wrong CD may have been inserted, but the actual CD that was inserted is structurally ok.

I'd say fix the code, update the server and not worry about it more.

Hmmm.... I'm not sure if you've covered this case or not:

* user requests info using GetCDInfo

* not in db

* wrong one fetched from FreeDB

* wrong album added to MB,

then,

* the /right/ disc's MB discid is associated with the /wrong/ly imported album.

All under the guise of a "FreeDB moderation".

hmmmm

yes, the cdindex id would be a concern. But not the album itself.

Right.

Track lengths...? It depends which ID - MB or FreeDB - the track lengths are based on.

we could write a script to verify each of our discids.

Feed it through the bad algorithm and see which ones yield a wrong result?

es, as step one.

and then for those that generated a bad id, fetch the album again.

do a sanity check (a coarse one since the data may have been edited) to see if the right album was fetched.

if we suspect a problem either flag it or imprort the correct album for the CD id.

hmmm... ok sounds reasonable. I think we'll thrash out the details of this problem over the next few days (or however long it takes).

i.e. I may consult you for advice again :-)

ok. good detective work.

brb

djce: no worries. :-)

how is everyone

KyleB: busy as usual :-)

working on helix stuff?

that too :-)

djce: you around?

yes

wendell asks:

ruaok, do you think it would create a lot of server strain if people were using it just for metadata queries like return all songs by artist x, but not doing that in the context of moding/tagging?

djce: What's the easiest way to tell if there is a rejected moderation to merge two artists?

he is looking at the moderation table.

direct SQL you mean?

general approach.

I'd say look for merge artist mods and then scan for artist you might be interested in.

Does he mean for two /particular/ artists? i.e. you know the IDs already?

the primiary artist is listed in the artist col and the secondary artist(s) are in the new field, right?

yes

mod.artist = id of to-be-merged artist

He didn't specify..