In this case it isn't very hard to determine for a human, but a script can't determine it at all since there is no legit discid to compare with. As for all the other cruft discids, while a script might do a good job at finding candidates, human intervention will always be needed and if someone wants to "waste" their time doing that research, it's their time to waste.
Philip On 5/10/08, Brian Schweitzer <[EMAIL PROTECTED]> wrote: > On Sat, May 10, 2008 at 7:59 AM, Frederik 'Freso' S. Olesen > <[EMAIL PROTECTED]> wrote: > > > Brian Schweitzer skrev: > > > > > > > I don't - we'll end up then having to allow the same discID several > times on the same release as well. It's quite possible and far from rare > for the same CD master, generating the same toc, to be reused in different > countries, for rereleases, etc. > > > > > > > So? I don't see how this would be much different than allowing the same > URI for several releases[1]. One-to-many and many-to-many relationships are > fundamental parts of relational database theory, if my memory is serving me > correctly. > > > > Well, I guess it's because, as I see it, we don't have two types of data - > "factual" (all but tags) and "opinion" (tags). I see three; the factual > data, the identifier data (tocs, trms, puids), and opinion data. Tocs are > perhaps a bit more than simply fingerprint data, in helping us to figure out > if perhaps there's that second version of a release with significantly > different times, in setting release times, etc, but I tend to think of them > just like trm and puid data - mostly meaningless without the source that > generated them available. > > If we could figure that that 1996 Brazilian release's toc was the one with > funky times, sure, that could be helpful. So, I could maybe see why it > might be useful for people to attach tocs to events, but only if we assumed > people would generally and actually attach them to the right events... and > I'm a bit pessimistic that that most tocs would actually end up attached to > the right event. > > As for removing homebrew tocs, while I don't quite agree with the benefit to > keeping them, I'm also of the opinion that > a) the effort to find and determine tocs are likely homebrew +2 tocs is a > lot of effort for little benefit > b) better done via an automated means (as someone else said earlier), if > it's done at all > c) a remove edit, thus always a voted edit - and again, a voted edit that > takes more effort for each voter to verify, imho, than is worth any possible > the benefit from the edit > d) always a guess - we can never be *sure* that the toc is a homebrew... > we can only guess that one *likely* is or isn't. > > > Brian > _______________________________________________ > Musicbrainz-style mailing list > Musicbrainz-style@lists.musicbrainz.org > http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style > _______________________________________________ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
