#musicbrainz

reosarevok, oh awesome!

I need two more votes to get rid of an ASIN I mistakenly attached: http://musicbrainz.org/edit/17761120

Thanks.

Caught exception in MusicBrainz::Server::Controller::ReleaseEditor::Add->add "Can't use an undefined value as a HASH reference at lib/MusicBrainz/Server/Wizard.pm line 269."

:/+

warp / ocharles ?

naturally,this happens on a sunday..

hi alll

i'm looking at the release db and I see 3 releases with the same cat number, bar code, tracks, etc

but different countries (one encompasing the other two)

is there any reason not to merge them?

in this case, 1,2, and 4 of http://musicbrainz.org/release-group/152499ea-d...

maybe 5,6,7 too

It really depends who you ask

Admittedly, having the countries *and* Europe looks bad

I would not merge any of these without searching for more info. some releases may look just look similar, there have similar looking catalog # numbers, but none of those are exactly identical based on the information presented

I'll leave them then

I'm fairly new to the musicbrainz world

1st two are most likely the same (UK) release though

they share the discogs and amazon URLs besides having UK release date

voiceinsideyou, from http://tickets.musicbrainz.org/browse/MBS-2229 I have a feeling you may concur with me on http://musicbrainz.org/edit/17774115

Anoia, yes don't merge, you'd lose the country data

gnu_andrew: the tracklist view is something nobody knows of because it's an internal thing which I still don't understand why we even show

Since making it useful would probably require changing the whole way the site works...

what's the tracklist view?

heh

very well

^^

In any case, I don't have a strong opinion on this matter - before I would have said "together is best" but since the covers are likely to be somewhat different, even if only because of the legal text, now I can see more arguments to keep them separate I guess

(although taking that opinion too far leads us to 100 different releases for cases like limited editions of 100, where each cover is handmade :D)

reosarevok, I think making the tracklist more visible demonstrates clearly there's not a huge load of data duplication going on

Well, the tracklist says nothing but "these share all recordings in the same order", doesn't it?

So it's something that you don't need a tracklist to see

Dunno

I guess the main issue at hand is that we have three levels, somehow

RG, "a bunch of very similar releases which only differ on release date/country and legal text", release

But making that second one explicit is pretty hard

reosarevok, which is important. But ideally I'd like to have ARs on tracklists too

you do need the tracklist to know that releases are sharing the data and not duplicating it

Even if they were duplicating a list of names, how's that even relevant?

and the tracklist also has different titles to the recordings

The only problem would be duplicating recordings I'd say

I mean, one release for Bulgaria might have all the titles in cyrillic, thus a different "tracklist", and still be considered the same thing-ish I guess

take the case where there's a typo that applies to a tracklist which is shared

(same credits, same all)

it should be possible to edit it at tracklist level rather than release, so all get the fix

if something exists and is part of how the underlying data works, it should be visible in my opinion

hiding it just makes things confusing

I think that one is by design

well then it's the wrong design, we should have the option

To avoid people changing releases they don't have

Or, well, to be sure they don't change what they don't know about

well yes so provide an option either way

and default it to the current status quo

I would rather just have an userscript for that, if at all

But well

I don't even know what these userscripts are so I doubt casual editors do

Casual editors shouldn't probably be batch-editing...

I think the issue people have is not really that stuff becomes hard to correct, though

certainly my issue

the legacy feat. case is an obvious one

But that we display loads of times what seems to most people to be the exact same thing

how so?

Well, with the strict "one date, one release" thing

If I have the disc, and start selling it one day before the official date (happens all the time)

That's a new release

yeah I know

but this is more a UI issue than one that means you should merge all the releases together and lose data

And to most people, a (fairly retarded) system of releasing stuff in different dates in different countries doesn't make it a different thing, I assume

To them is "well, I have this thing here, whether I bought it in the UK on a Friday or Germany on a Thursday is irrelevant"

Which is why people want to be able to store those dates in the same release, but still be able to serve them in a machine-readable way for those who want that

which already happens now

the dates differ per release

the tracklist is shared

But the tracklist is also shared between, say, the digipak, jewel case and CD+DVD editions

Which almost anyone would call a different thing

(or the CD and the vinyl and the digital, etc.)

If they have the same tracklist, don't see how they are different

If I have a jewel case in my hands vs. a digipak, they're clearly different things, and I can see that they are

I can't see, in many cases, whether they are German or British

And when I can, it's by reading some very small print

well yes I see the point, but I don't see where that gets us

UK digiback, German CD, whatever. they all have the same tracklist data

(and in the cases where there's no difference in what's printed, there's just no way of knowing what you have, even)

can a release have multiple countries?

Anoia, no

Anoia: at the moment, no

without going to an entire continent?

OK, another potential duplicate

Anoia, but a release is just a tracklist and some URLs

one with no region

reosarevok: digital release may include one or two "bonus" tracks, which are not on the vinyl...

one for germany

xplt: or it may not :)

xplt, so that would be a different tracklist

same codes, labels, etc

gnu_andrew: I have releases which were co-released by a French label, a Spanish one, and an Italian one

what should I do in that case?

reosarevok, so three release entries

They're the same thing, there's no text that says anything about where it was released, nothing

There's just one print, with three logos in the back

reosarevok, so? the info's available that there are multiple releases because you know about it!

reosarevok: you can have multiple labels

Anoia: sure

gnu_andrew, but how is that information remotely useful? Would you also add only one label to each one of them?

(in this case I don't even have dates, apart from the year)

reosarevok, depends if there are different dates/countries etc.

I doubt the labels even know the dates themselves

reosarevok, then no, one release with three labels suffices

reosarevok, my concern, shown by this Eurovision edit, is in throwing away release date data we do have

Which is why I don't see the problem if we did have the option to store multiple country/date pairs, if all the rest is the same

(so we don't throw away that data)

"This thing was made available in different places at different dates, listed on the sidebar"

I'd even argue it's better for data users, since they can know it's the same thing with different dates

(while if they were separate, they'd have to guess)

reosarevok, my point is we already do

reosarevok, this isn't something that needs a schema change, just different presentation and the option to edit shared tracklists

Considering a date a primary entity is way too abstract :/

If I have that, bought on Germany, and you have that, bought on the UK, we wouldn't say we have different things

Well, dunno about you, but almost nobody would :p

no probably not, but I would guess that a vast amount of MB data comes not from physical releases at all, but online listings, digital releases, etc.

which in most cases do have clear release dates

Pffft