on recording level: low precision, high recall (as in we have ISRCs for many tracks in the end, but possibly more than one)
2013-04-23 11326, 2013
LordSputnik
(because there's a chance that the correct track for the ISRC is also linked to that recording)
2013-04-23 11358, 2013
JonnyJD_
LordSputnik: that is only because you change the definition of correctness.
2013-04-23 11314, 2013
JonnyJD_
The key about comparing these is to have the same definition of correctness/precision.
2013-04-23 11319, 2013
ijabz_ joined the channel
2013-04-23 11322, 2013
LordSputnik
JonnyJD_: but that's better for striving for a correctness we can't possible achieve :)
2013-04-23 11304, 2013
JonnyJD_
correct is when I look up a track and I get one ISRC, the correct one, or no ISRC
2013-04-23 11343, 2013
JonnyJD_
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.
2013-04-23 11328, 2013
JonnyJD_
You can easily just fetch all ISRCs belonging to any of the track IDs of a "recording cluster", but not the other way around
2013-04-23 11332, 2013
LordSputnik
JonnyJD_: but you won't be able to look up an ISRC for a track, because they're stored on recordings
2013-04-23 11355, 2013
LordSputnik
and there's no good way to verify the track ISRC
2013-04-23 11332, 2013
JonnyJD_
There is also no good way to verify them on recording level.
2013-04-23 11347, 2013
JonnyJD_
especially if multiple ISRCs could be correct.
2013-04-23 11306, 2013
LordSputnik
but it's less specific, so less likely to be wrong
2013-04-23 11311, 2013
JonnyJD_
We can always only verify the track level (with the actual disc). But only guess on the recording level.
But please don't say adding them at a more general level makes them any more correct.
2013-04-23 11316, 2013
LordSputnik
so completely unreliable
2013-04-23 11349, 2013
hawke_1
LordSputnik: what if the label considers part 1 and part 2 to be a single recording? :-p
2013-04-23 11357, 2013
JonnyJD_
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"
2013-04-23 11307, 2013
LordSputnik
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"
2013-04-23 11336, 2013
JonnyJD_
LordSputnik: Yes, that wording works.
2013-04-23 11304, 2013
LordSputnik
good, but I'm not writing a style guideline on that, and I've had enough of wordings the past few days :P
2013-04-23 11306, 2013
JonnyJD_
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)
2013-04-23 11349, 2013
JonnyJD_
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
2013-04-23 11322, 2013
JonnyJD_
*nice
2013-04-23 11351, 2013
coderhead42 joined the channel
2013-04-23 11303, 2013
ruaok joined the channel
2013-04-23 11351, 2013
JonnyJD_
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.
