#musicbrainz-devel

on recording level: low precision, high recall (as in we have ISRCs for many tracks in the end, but possibly more than one)

(because there's a chance that the correct track for the ISRC is also linked to that recording)

LordSputnik: that is only because you change the definition of correctness.

JonnyJD_: but that's better for striving for a correctness we can't possible achieve :)

correct is when I look up a track and I get one ISRC, the correct one, or no ISRC

a high recall is when I get ISRCs for many tracks. But that might screw correctness, because I might get ISRCs for tracks, that belong to the recording, but not to the track.

You can easily just fetch all ISRCs belonging to any of the track IDs of a "recording cluster", but not the other way around

JonnyJD_: but you won't be able to look up an ISRC for a track, because they're stored on recordings

and there's no good way to verify the track ISRC

There is also no good way to verify them on recording level.

especially if multiple ISRCs could be correct.

but it's less specific, so less likely to be wrong

We can always only verify the track level (with the actual disc). But only guess on the recording level.

eg. http://beta.musicbrainz.org/recording/ee7ad55e-...

I just added that ISRC

the label assigned it for the original release

No. Only because you change the definition of correctness, like I said.

but it was on a remaster

so it could've been some new ISRC, or something wrong, but by adding it to the recording, the chances are it's correct for *one* of the tracks

Sorry. That only tells me we can't actually ensure correctness. Not that this is actually correct.

LordSputnik: and that’s a different definition of 'correct' than the one that JonnyJD_ wants.

so if we can't ensure correctness, why bother to say "it's the ISRC for this track" when we can't possibly be sure if it's right or not?

I don’t think there is a useful definition of 'correct' for ISRCs anyway though.

hawke_1: yes. Possibly.

eg. I also just added one to http://beta.musicbrainz.org/recording/7ad6015b-... which has to be wrong

since it's the same as the one for Part 1 :P

But please don't say adding them at a more general level makes them any more correct.

so completely unreliable

LordSputnik: what if the label considers part 1 and part 2 to be a single recording? :-p

I could get behind saying we can't ensoure they are correct for a track, but not saying adding them at recording level is "more correct"

JonnyJD_: It is probably more correct. It's probably more correct to say *this ISRC is from one of these tracks" than "this ISRC is from this track"

LordSputnik: Yes, that wording works.

good, but I'm not writing a style guideline on that, and I've had enough of wordings the past few days :P

I'm all for storing at track level. I try hard with isrcsubmit.py that people use the correct release (and so the correct "track-list"/track ids, if/when exposed)

So unless people are beeing ignorant, that would submit most ISRCs for the correct track. Even more when DiscIds where attached to the right releases.., but even if not there is a noice choice dialog with barcode cat# and names/titles

*nice

luks: still awake? I can't figure out what Windows GetVersion() < 0x80000000 is supposed to test. I found that when GetVersion() >= 0x80000000, then the build number can't be extracted, but nothing else.

http://msdn.microsoft.com/en-us/library/windows... is the official documenation, which doesn't tell much about that condition

luks: okay, found it after enabling several JS sites on MSDN.. down in the additional notes

"High order bit: 0" -> NT based OS