[mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Philip Jägenstedt]

Andii disagreed, so I'd like to have a proper vote in
http://musicbrainz.org/edit/17774115

The issue as I see it is whether or not we should have separate
MusicBrainz releases for the same physical release sold in most of or
all of Europe, where it may have been available at different dates in
different countries. (Should it turn out that the release differs
physically between countries then the issue is moot.)

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Andii Hughes]

On 27 May 2012 19:12, Philip Jägenstedt  wrote:
> Andii disagreed, so I'd like to have a proper vote in
> http://musicbrainz.org/edit/17774115
>
> The issue as I see it is whether or not we should have separate
> MusicBrainz releases for the same physical release sold in most of or
> all of Europe, where it may have been available at different dates in
> different countries. (Should it turn out that the release differs
> physically between countries then the issue is moot.)
>
> --
> Philip Jägenstedt
>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

The concept of a release in MusicBrainz includes the release date.  Hence,
a release with a different date is a different MusicBrainz release, though they
may share the same tracklisting.
-- 
Andii :-)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Andii Hughes]

On 27 May 2012 19:55, Andii Hughes  wrote:
> On 27 May 2012 19:12, Philip Jägenstedt  wrote:
>> Andii disagreed, so I'd like to have a proper vote in
>> http://musicbrainz.org/edit/17774115
>>
>> The issue as I see it is whether or not we should have separate
>> MusicBrainz releases for the same physical release sold in most of or
>> all of Europe, where it may have been available at different dates in
>> different countries. (Should it turn out that the release differs
>> physically between countries then the issue is moot.)
>>
>> --
>> Philip Jägenstedt
>>
>> ___
>> MusicBrainz-style mailing list
>> MusicBrainz-style@lists.musicbrainz.org
>> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
> The concept of a release in MusicBrainz includes the release date.  Hence,
> a release with a different date is a different MusicBrainz release, though 
> they
> may share the same tracklisting.
> --
> Andii :-)

I've created

http://tickets.musicbrainz.org/browse/MBS-4785

for what I believe is the underlying issue here; that there is no easy
way to make
edits to a tracklist shared by multiple releases (to my knowledge).
-- 
Andii :-)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Philip Jägenstedt]

On Sun, May 27, 2012 at 9:03 PM, Andii Hughes  wrote:
> On 27 May 2012 19:55, Andii Hughes  wrote:
>> On 27 May 2012 19:12, Philip Jägenstedt  wrote:
>>> Andii disagreed, so I'd like to have a proper vote in
>>> http://musicbrainz.org/edit/17774115
>>>
>>> The issue as I see it is whether or not we should have separate
>>> MusicBrainz releases for the same physical release sold in most of or
>>> all of Europe, where it may have been available at different dates in
>>> different countries. (Should it turn out that the release differs
>>> physically between countries then the issue is moot.)
>>
>> The concept of a release in MusicBrainz includes the release date.  Hence,
>> a release with a different date is a different MusicBrainz release, though 
>> they
>> may share the same tracklisting.
>
> I've created
>
> http://tickets.musicbrainz.org/browse/MBS-4785
>
> for what I believe is the underlying issue here; that there is no easy
> way to make
> edits to a tracklist shared by multiple releases (to my knowledge).

That is not the issue, the issue is that these are (AFAIK) the same
physical release. Splitting it into one release per country has
consequences:

 * We'll need one release per European country where this is available for sale.
 * ARs and cover art for that physical release will have to be
duplicated once per release.
 * Given the physical album, there's no way to tell which MusicBrainz
release it corresponds to without also knowing where it was purchased.

If there is a schema change solution to the problem, it would be to
allow multiple pairs of release dates and countries per release. In
the absence of that, I think the better trade-off is to have a single
release and possibly add annotations for any interesting per-country
delays of the release.

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Andii Hughes]

On 27 May 2012 20:27, Philip Jägenstedt  wrote:
> On Sun, May 27, 2012 at 9:03 PM, Andii Hughes  
> wrote:
>> On 27 May 2012 19:55, Andii Hughes  wrote:
>>> On 27 May 2012 19:12, Philip Jägenstedt  wrote:
 Andii disagreed, so I'd like to have a proper vote in
 http://musicbrainz.org/edit/17774115

 The issue as I see it is whether or not we should have separate
 MusicBrainz releases for the same physical release sold in most of or
 all of Europe, where it may have been available at different dates in
 different countries. (Should it turn out that the release differs
 physically between countries then the issue is moot.)
>>>
>>> The concept of a release in MusicBrainz includes the release date.  Hence,
>>> a release with a different date is a different MusicBrainz release, though 
>>> they
>>> may share the same tracklisting.
>>
>> I've created
>>
>> http://tickets.musicbrainz.org/browse/MBS-4785
>>
>> for what I believe is the underlying issue here; that there is no easy
>> way to make
>> edits to a tracklist shared by multiple releases (to my knowledge).
>
> That is not the issue, the issue is that these are (AFAIK) the same
> physical release.

Releases in MB don't represent just a physical release, they represent
an event.  See:

http://musicbrainz.org/doc/Style/Old_style_practices

which explains why this was changed from listing just event data on a
single release (Amazon links, etc.)

Splitting it into one release per country has
> consequences:
>
>  * We'll need one release per European country where this is available for 
> sale.

So?  That's the purpose of having releases easily created with the
same tracklist.  Also how do you know
that the countries where this is on sale meet this ambiguous "Europe"
setting?  How do you know that some
of them haven't been translated into the native language of the
country, necessitating a different tracklist?

You just seem to want to make a sweeping generalisation about all
releases that may or may not exist for
no good reason as far as I can tell.  The reason we have releases and
release groups is so we can have more
than one release under the same title.

>  * ARs and cover art for that physical release will have to be
> duplicated once per release.

Cover art may be different.  As I say, you haven't seen all these
releases.  I agree we do need a way of sharing
cover art.  I've already raised this, but then the feature is fairly new.

http://musicbrainz.org/edit/17722937

Most ARs should be either on recordings or specific to the event (e.g.
Amazon links).  I agree there are some
that may be apply to the whole group.  I raised this here:

http://lists.musicbrainz.org/pipermail/musicbrainz-style/2012-May/015408.html

>  * Given the physical album, there's no way to tell which MusicBrainz
> release it corresponds to without also knowing where it was purchased.

The person who bought it usually knows.  And given the tracklists are
shared, it doesn't seem like a huge issue to me.  They are pretty
interchangeable - isn't that your whole point to start with?

>
> If there is a schema change solution to the problem, it would be to
> allow multiple pairs of release dates and countries per release.

Which we had before NGS.  It's too restrictive on those where more
does differ between releases.

> In
> the absence of that, I think the better trade-off is to have a single
> release and possibly add annotations for any interesting per-country
> delays of the release.

Sorry but no.  Moving all the release data to an annotation is not
acceptable when there is a perfectly acceptable way of adding the data
properly in a machine-readable format.

>
> --
> Philip Jägenstedt
>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style



-- 
Andii :-)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Philip Jägenstedt]

On Sun, May 27, 2012 at 10:14 PM, Andii Hughes
 wrote:
> On 27 May 2012 20:27, Philip Jägenstedt  wrote:
>> On Sun, May 27, 2012 at 9:03 PM, Andii Hughes  
>> wrote:
>>> On 27 May 2012 19:55, Andii Hughes  wrote:
 On 27 May 2012 19:12, Philip Jägenstedt  wrote:
> Andii disagreed, so I'd like to have a proper vote in
> http://musicbrainz.org/edit/17774115
>
> The issue as I see it is whether or not we should have separate
> MusicBrainz releases for the same physical release sold in most of or
> all of Europe, where it may have been available at different dates in
> different countries. (Should it turn out that the release differs
> physically between countries then the issue is moot.)

 The concept of a release in MusicBrainz includes the release date.  Hence,
 a release with a different date is a different MusicBrainz release, though 
 they
 may share the same tracklisting.
>>>
>>> I've created
>>>
>>> http://tickets.musicbrainz.org/browse/MBS-4785
>>>
>>> for what I believe is the underlying issue here; that there is no easy
>>> way to make
>>> edits to a tracklist shared by multiple releases (to my knowledge).
>>
>> That is not the issue, the issue is that these are (AFAIK) the same
>> physical release.
>
> Releases in MB don't represent just a physical release, they represent
> an event.  See:
>
> http://musicbrainz.org/doc/Style/Old_style_practices
>
> which explains why this was changed from listing just event data on a
> single release (Amazon links, etc.)

We no longer have the concept of release events, just release groups
and releases. http://musicbrainz.org/doc/Style/Release doesn't clearly
say what a release represents.

> Splitting it into one release per country has
>> consequences:
>>
>>  * We'll need one release per European country where this is available for 
>> sale.
>
> So?  That's the purpose of having releases easily created with the
> same tracklist.  Also how do you know
> that the countries where this is on sale meet this ambiguous "Europe"
> setting?  How do you know that some
> of them haven't been translated into the native language of the
> country, necessitating a different tracklist?
>
> You just seem to want to make a sweeping generalisation about all
> releases that may or may not exist for
> no good reason as far as I can tell.  The reason we have releases and
> release groups is so we can have more
> than one release under the same title.

If any country has a physically different release, that should of
course be a different release in MusicBrainz. The whole premise is
that the releases are in fact the same, as at least the Swedish, UK
and German ones appear to be. I could be wrong, but I'd be really
surprised if there are several variants of this release already.

>>  * ARs and cover art for that physical release will have to be
>> duplicated once per release.
>
> Cover art may be different.  As I say, you haven't seen all these
> releases.  I agree we do need a way of sharing
> cover art.  I've already raised this, but then the feature is fairly new.
>
> http://musicbrainz.org/edit/17722937
>
> Most ARs should be either on recordings or specific to the event (e.g.
> Amazon links).  I agree there are some
> that may be apply to the whole group.  I raised this here:
>
> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2012-May/015408.html

That wouldn't work since release groups can contain releases that are
actually different, as in having different cover art, labels, masters,
etc. We have no way to express that two releases are physically the
same.

It looks like http://tickets.musicbrainz.org/browse/MBS-2229 is the
best solution to avoid duplicate ARs and cover art, the question is
just what to do until that's been implemented.

>>  * Given the physical album, there's no way to tell which MusicBrainz
>> release it corresponds to without also knowing where it was purchased.
>
> The person who bought it usually knows.  And given the tracklists are
> shared, it doesn't seem like a huge issue to me.  They are pretty
> interchangeable - isn't that your whole point to start with?

My point is that it's weird if a single pressing of a release end up
as multiple releases in MusicBrainz and that which release a copy
belongs to depends on where it was shipped and sold.

>> If there is a schema change solution to the problem, it would be to
>> allow multiple pairs of release dates and countries per release.
>
> Which we had before NGS.  It's too restrictive on those where more
> does differ between releases.

Nobody has suggested merging releases which can be physically
distinguished or going back to anything like we had before NGS.

>> In
>> the absence of that, I think the better trade-off is to have a single
>> release and possibly add annotations for any interesting per-country
>> delays of the release.
>
> Sorry but no.  Moving all the release data to an annotation is not
> acceptable when there is a perfectly a

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Andii Hughes]

On 27 May 2012 23:16, Philip Jägenstedt  wrote:
> On Sun, May 27, 2012 at 10:14 PM, Andii Hughes
>  wrote:
>> On 27 May 2012 20:27, Philip Jägenstedt  wrote:
>>> On Sun, May 27, 2012 at 9:03 PM, Andii Hughes  
>>> wrote:
 On 27 May 2012 19:55, Andii Hughes  wrote:
> On 27 May 2012 19:12, Philip Jägenstedt  wrote:
>> Andii disagreed, so I'd like to have a proper vote in
>> http://musicbrainz.org/edit/17774115
>>
>> The issue as I see it is whether or not we should have separate
>> MusicBrainz releases for the same physical release sold in most of or
>> all of Europe, where it may have been available at different dates in
>> different countries. (Should it turn out that the release differs
>> physically between countries then the issue is moot.)
>
> The concept of a release in MusicBrainz includes the release date.  Hence,
> a release with a different date is a different MusicBrainz release, 
> though they
> may share the same tracklisting.

 I've created

 http://tickets.musicbrainz.org/browse/MBS-4785

 for what I believe is the underlying issue here; that there is no easy
 way to make
 edits to a tracklist shared by multiple releases (to my knowledge).
>>>
>>> That is not the issue, the issue is that these are (AFAIK) the same
>>> physical release.
>>
>> Releases in MB don't represent just a physical release, they represent
>> an event.  See:
>>
>> http://musicbrainz.org/doc/Style/Old_style_practices
>>
>> which explains why this was changed from listing just event data on a
>> single release (Amazon links, etc.)
>
> We no longer have the concept of release events, just release groups
> and releases. http://musicbrainz.org/doc/Style/Release doesn't clearly
> say what a release represents.
>
>> Splitting it into one release per country has
>>> consequences:
>>>
>>>  * We'll need one release per European country where this is available for 
>>> sale.
>>
>> So?  That's the purpose of having releases easily created with the
>> same tracklist.  Also how do you know
>> that the countries where this is on sale meet this ambiguous "Europe"
>> setting?  How do you know that some
>> of them haven't been translated into the native language of the
>> country, necessitating a different tracklist?
>>
>> You just seem to want to make a sweeping generalisation about all
>> releases that may or may not exist for
>> no good reason as far as I can tell.  The reason we have releases and
>> release groups is so we can have more
>> than one release under the same title.
>
> If any country has a physically different release, that should of
> course be a different release in MusicBrainz. The whole premise is
> that the releases are in fact the same, as at least the Swedish, UK
> and German ones appear to be. I could be wrong, but I'd be really
> surprised if there are several variants of this release already.
>

But it's possible.  The most obvious case would be that one country localises
the titles to their native language.

Maybe it's not ideal, but while this is the way of storing release
events, having multiple
releases is the correct thing to do.

>>>  * ARs and cover art for that physical release will have to be
>>> duplicated once per release.
>>
>> Cover art may be different.  As I say, you haven't seen all these
>> releases.  I agree we do need a way of sharing
>> cover art.  I've already raised this, but then the feature is fairly new.
>>
>> http://musicbrainz.org/edit/17722937
>>
>> Most ARs should be either on recordings or specific to the event (e.g.
>> Amazon links).  I agree there are some
>> that may be apply to the whole group.  I raised this here:
>>
>> http://lists.musicbrainz.org/pipermail/musicbrainz-style/2012-May/015408.html
>
> That wouldn't work since release groups can contain releases that are
> actually different, as in having different cover art, labels, masters,
> etc. We have no way to express that two releases are physically the
> same.
>

It would work for what I was originally suggesting e.g. producer at
release level.

> It looks like http://tickets.musicbrainz.org/browse/MBS-2229 is the
> best solution to avoid duplicate ARs and cover art, the question is
> just what to do until that's been implemented.

Use what we have; multiple releases.  Better to have the data
available than not.

I do think the tracklist issue could be resolved easily and solve the main issue
with multiple releases in the interim (i.e. that tracklists diverge if
you edit them)

>
>>>  * Given the physical album, there's no way to tell which MusicBrainz
>>> release it corresponds to without also knowing where it was purchased.
>>
>> The person who bought it usually knows.  And given the tracklists are
>> shared, it doesn't seem like a huge issue to me.  They are pretty
>> interchangeable - isn't that your whole point to start with?
>
> My point is that it's weird if a single pressing of a release end up
> as multiple releases in Mu

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Per Starbäck]

If a European release is released in Germany a couple of days earlier
than in the UK, that's not that more interesting than if a US release
is available in one state before another. Nor is an artist only
selling their own cd on tour making a new "release" after every
concert (regardless of whether those concerts are in the same country
or not). I see no advantages at all in maintaining that two identical
objects should be treated as different objects in the database because
of their history, and it's already just irritating with you try to rip
a cd with data from Musicbrainz and you first have to choose from a
number of alternatives with the exact same name.

>>> How do you know that some
>>> of them haven't been translated into the native language of the
>>> country, necessitating a different tracklist?

I don't understand this. If anyone has such a hypothetical translated
release they can and will enter that. No problem. No one will object
to that.

>> That's a lot of clutter when editing and tagging and they will
>> certainly not stay in sync. IMHO, that simply is not a price worth
>> paying to keep machine-readable per-country release dates for what is
>> probably one of the most pan-European there is.

Totally agree. Together with the impossibility of knowing what an
object you have corresponds to in MBz.

Generally I think Musicbrainz gets better the more it mimics the real
world and gets worse the more it deviates from it with things like
"well, in Musicbrainz a release is not a release but ", "in
Musicbrainz a recording is actually not a recording, but ...", etc. Of
course it is one release.

Or actually it is two already. I noticed that at the official
EuroVisionShop at
http://www.eurovisionshop.tv/product/cd-dvd/45/434/official-2-cd-esc-2012
where it says that

   All customers which already bought the CD will get the new version
with the correct recording
   of the Norwegian contender, "Stay" by Tooij.

I wonder if the (good) release we have in MBz is the old or the new one.
If you buy it from that webshop, do you get a Tuvalu release (.tv)? :-)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Philip Jägenstedt]

On Mon, May 28, 2012 at 6:22 PM, Per Starbäck  wrote:

> I noticed that at the official
> EuroVisionShop at
> http://www.eurovisionshop.tv/product/cd-dvd/45/434/official-2-cd-esc-2012
> where it says that
>
>   All customers which already bought the CD will get the new version
> with the correct recording
>   of the Norwegian contender, "Stay" by Tooij.
>
> I wonder if the (good) release we have in MBz is the old or the new one.
> If you buy it from that webshop, do you get a Tuvalu release (.tv)? :-)

The filename of Tooji's Stay bought from eurovisionmusic.com is "32
Stay (Eurovision 2012 - Norway) **.mp3" No other song has "**" in the
filename so my guess is that I have the updated version. For research
purposes I found an early FLAC rip of the release and compared the
tracks in Audacity: . As you can see, the
MP3 is louder. After normalizing the levels I can still hear a
difference, but it could just be due to more dynamic compression on
the MP3. If someone has copy bought from
http://www.eurovisionshop.tv/en/product/cd-and-dvd/45/434/official-2-cd-esc-2012
after the note about this track was added I could compare.

If the DiscID is different I suppose a separate release and recording
should be added, but assuming it still has the same packaging I don't
know how to determine a release date. If two pressings can be
confirmed, I obviously don't think we should have two releases for
each country, that would be twice as annoying...

-- 
Philip Jägenstedt

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Andii Hughes]

On 28 May 2012 17:22, Per Starbäck  wrote:
> If a European release is released in Germany a couple of days earlier
> than in the UK, that's not that more interesting than if a US release
> is available in one state before another. Nor is an artist only
> selling their own cd on tour making a new "release" after every
> concert (regardless of whether those concerts are in the same country
> or not). I see no advantages at all in maintaining that two identical
> objects should be treated as different objects in the database because
> of their history, and it's already just irritating with you try to rip
> a cd with data from Musicbrainz and you first have to choose from a
> number of alternatives with the exact same name.

Whether it's "interesting" or not is your subjective opinion.  It doesn't mean
the fields which are available to store this information should not be used for
those who are interested.

I agree that the current structure is not ideal, but it's what we have now.
Destroying valid data because of it is simply not acceptable.

>
 How do you know that some
 of them haven't been translated into the native language of the
 country, necessitating a different tracklist?
>
> I don't understand this. If anyone has such a hypothetical translated
> release they can and will enter that. No problem. No one will object
> to that.

As you've taken this completely out of its original context, I no longer know
what you're referring to.

>
>>> That's a lot of clutter when editing and tagging and they will
>>> certainly not stay in sync. IMHO, that simply is not a price worth
>>> paying to keep machine-readable per-country release dates for what is
>>> probably one of the most pan-European there is.
>
> Totally agree. Together with the impossibility of knowing what an
> object you have corresponds to in MBz.
>

Since when did "clutter" become more important than accurate data?  Oh
let's make things not reflect the real world because it's not tidy
enough for us.

> Generally I think Musicbrainz gets better the more it mimics the real
> world and gets worse the more it deviates from it with things like
> "well, in Musicbrainz a release is not a release but ", "in
> Musicbrainz a recording is actually not a recording, but ...", etc. Of
> course it is one release.

The real world has release events.  Different stores in different
countries make releases
available at different times.  Deal with it.

>
> Or actually it is two already. I noticed that at the official
> EuroVisionShop at
> http://www.eurovisionshop.tv/product/cd-dvd/45/434/official-2-cd-esc-2012
> where it says that
>
>   All customers which already bought the CD will get the new version
> with the correct recording
>   of the Norwegian contender, "Stay" by Tooij.
>
> I wonder if the (good) release we have in MBz is the old or the new one.
> If you buy it from that webshop, do you get a Tuvalu release (.tv)? :-)

It's tv as in television I presume.  I'm now wondering which version mine is
and whether Amazon will ship a new one out.

>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style



-- 
Andii :-)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Per Starbäck]

>> If a European release is released in Germany a couple of days earlier
>> than in the UK, that's not that more interesting than if a US release
>> is available in one state before another. Nor is an artist only
>> selling their own cd on tour making a new "release" after every
>> concert (regardless of whether those concerts are in the same country
>> or not). I see no advantages at all in maintaining that two identical
>> objects should be treated as different objects in the database because
>> of their history, and it's already just irritating with you try to rip
>> a cd with data from Musicbrainz and you first have to choose from a
>> number of alternatives with the exact same name.
>
> Whether it's "interesting" or not is your subjective opinion.  It doesn't mean
> the fields which are available to store this information should not be used 
> for
> those who are interested.

I didn't say that it's not interesting.  I do find it somewhat
interesting that record stores in the UK waited until Monday to sell
this object. Surely it's good to store that in MBz, but not to make it
unmanageable and less useful for any other purpose until there is a
good way to store this.

> I agree that the current structure is not ideal, but it's what we have now.
> Destroying valid data because of it is simply not acceptable.

Says you. Whereas destroying the usability of MBz because of that
principle is simply not acceptable to me. The current entry for that
release group is simply a lot less useful. If your principle was
carried out generally for all releases it would be unwieldy for such a
large part of my cds that I wouldn't use MBz anymore for ripping cds
(and therefore probably not use it at all). It would simply not be
useful.

>> Generally I think Musicbrainz gets better the more it mimics the real
>> world and gets worse the more it deviates from it with things like
>> "well, in Musicbrainz a release is not a release but ", "in
>> Musicbrainz a recording is actually not a recording, but ...", etc. Of
>> course it is one release.
>
> The real world has release events.  Different stores in different
> countries make releases
> available at different times.  Deal with it.

Earlier I thought you agreed that the situation isn't ideal, but now I
should just "deal with it"?
The real world has both "released objects" (not a good term, I know)
and "release events". Things can be said about both of them. Certainly
there are not ~50 (or even 5) different entities in the real world
that happen to have the same track list, the same bar code, the same
cover, etc.

>> I wonder if the (good) release we have in MBz is the old or the new one.
>> If you buy it from that webshop, do you get a Tuvalu release (.tv)? :-)
>
> It's tv as in television I presume.

Yes, suggesting Tuvalu was a joke of course. But also a question for
you. Would you like yet another release entry for the release from the
official webshop? And what country would you write?

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Andii Hughes]

On 28 May 2012 21:33, Per Starbäck  wrote:
>>> If a European release is released in Germany a couple of days earlier
>>> than in the UK, that's not that more interesting than if a US release
>>> is available in one state before another. Nor is an artist only
>>> selling their own cd on tour making a new "release" after every
>>> concert (regardless of whether those concerts are in the same country
>>> or not). I see no advantages at all in maintaining that two identical
>>> objects should be treated as different objects in the database because
>>> of their history, and it's already just irritating with you try to rip
>>> a cd with data from Musicbrainz and you first have to choose from a
>>> number of alternatives with the exact same name.
>>
>> Whether it's "interesting" or not is your subjective opinion.  It doesn't 
>> mean
>> the fields which are available to store this information should not be used 
>> for
>> those who are interested.
>
> I didn't say that it's not interesting.  I do find it somewhat
> interesting that record stores in the UK waited until Monday to sell
> this object. Surely it's good to store that in MBz, but not to make it
> unmanageable and less useful for any other purpose until there is a
> good way to store this.
>

I would not say it makes it "unmangeable and less useful".  How do you
think it does?

>> I agree that the current structure is not ideal, but it's what we have now.
>> Destroying valid data because of it is simply not acceptable.
>
> Says you. Whereas destroying the usability of MBz because of that
> principle is simply not acceptable to me. The current entry for that
> release group is simply a lot less useful. If your principle was
> carried out generally for all releases it would be unwieldy for such a
> large part of my cds that I wouldn't use MBz anymore for ripping cds
> (and therefore probably not use it at all). It would simply not be
> useful.

That principle is already applied to other release groups.  It's how the schema
of MB currently is, like it or not.  It's not a reason to obliterate
data now in the
hope that some kind soul will spend time restoring it all later.
Given the amount
of stuff in the DB that still needs work (use of feat. in titles for
example - just look
at some of the reports), I don't want to make things even worse.

If the date field is used now, some releases can be automatically
altered when multiple events
are allowed and others listed in a report.  This CAN'T HAPPEN if
instead this data is in a freeform
annotation.

I noticed the 1:1 disc ID resolution was broken as soon as NGS hit.
Have you not
been using MusicBrainz much over the last year?

>
>>> Generally I think Musicbrainz gets better the more it mimics the real
>>> world and gets worse the more it deviates from it with things like
>>> "well, in Musicbrainz a release is not a release but ", "in
>>> Musicbrainz a recording is actually not a recording, but ...", etc. Of
>>> course it is one release.
>>
>> The real world has release events.  Different stores in different
>> countries make releases
>> available at different times.  Deal with it.
>
> Earlier I thought you agreed that the situation isn't ideal, but now I
> should just "deal with it"?

I say this because you seem to be saying that this event data is not worth
storing and not a reflection of reality, when it is.

> The real world has both "released objects" (not a good term, I know)
> and "release events". Things can be said about both of them. Certainly
> there are not ~50 (or even 5) different entities in the real world
> that happen to have the same track list, the same bar code, the same
> cover, etc.

I know.  So ideally we need to be able to have events at both release
and release
group level.  We only have the latter at present.  That doesn't mean
you should destroy
all the event data.

>
>>> I wonder if the (good) release we have in MBz is the old or the new one.
>>> If you buy it from that webshop, do you get a Tuvalu release (.tv)? :-)
>>
>> It's tv as in television I presume.
>
> Yes, suggesting Tuvalu was a joke of course.

I thought it might be.

> But also a question for
> you. Would you like yet another release entry for the release from the
> official webshop? And what country would you write?
>

It depends if we have dates it was made available and countries they ship to.
I've already noted that Poland doesn't have a digital version of this release
(and so presumably no physical either).  So generalising to "Europe" is going
overboard.

> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style



-- 
Andii :-)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Lemire, Sebastien]

I wanted jump a little into this interesting discussion.
I agree with some of you here that there's a significant problem with how
Musicbrainz relates to releases at the moment.

Basically, I don't believe that every "release event" should get its own
separate release. Often times, you will have the exact same physical item
(ie with the same label # and barcode) sold in various countries and it
doesn't make sense to have them individually represented as the only
differentiation is that they were released on a different date in a
different country. This means that Release-level info such as URLs, cover
art, ARs have to be duplicated...

Furthermore, I often find it incredibly difficult to determine the release
country of a release. Ok I deal a lot with Japanese releases, those are
easy, but let's take a western example, the Putumayo label releases. If I
enter a release in MB, I have this mind:. 1.) The label is British, 2.) I
know for a fact the same exact CD is for sale in US and Canada. I'm in
Canada, which is where I bought it. Which country should I enter? Should it
be worldwide? (That's not how the majority of these releases are
classified).

Basically, I think the "MB Release" should represent the physical released
medium (with a unique barcode/label/label #), and then the "release events"
(ie release date/country) should be stored within each "MB Release". Btw, I
have a hazy memory, wouldn't this be more or less how it was pre-NGS?

I know what I'm suggesting would require a Schema change, but still, this
is the only way to make sense of this.

Anyway, just an opinion...
Sebastien

On Mon, May 28, 2012 at 4:33 PM, Per Starbäck wrote:

> >> If a European release is released in Germany a couple of days earlier
> >> than in the UK, that's not that more interesting than if a US release
> >> is available in one state before another. Nor is an artist only
> >> selling their own cd on tour making a new "release" after every
> >> concert (regardless of whether those concerts are in the same country
> >> or not). I see no advantages at all in maintaining that two identical
> >> objects should be treated as different objects in the database because
> >> of their history, and it's already just irritating with you try to rip
> >> a cd with data from Musicbrainz and you first have to choose from a
> >> number of alternatives with the exact same name.
> >
> > Whether it's "interesting" or not is your subjective opinion.  It
> doesn't mean
> > the fields which are available to store this information should not be
> used for
> > those who are interested.
>
> I didn't say that it's not interesting.  I do find it somewhat
> interesting that record stores in the UK waited until Monday to sell
> this object. Surely it's good to store that in MBz, but not to make it
> unmanageable and less useful for any other purpose until there is a
> good way to store this.
>
> > I agree that the current structure is not ideal, but it's what we have
> now.
> > Destroying valid data because of it is simply not acceptable.
>
> Says you. Whereas destroying the usability of MBz because of that
> principle is simply not acceptable to me. The current entry for that
> release group is simply a lot less useful. If your principle was
> carried out generally for all releases it would be unwieldy for such a
> large part of my cds that I wouldn't use MBz anymore for ripping cds
> (and therefore probably not use it at all). It would simply not be
> useful.
>
> >> Generally I think Musicbrainz gets better the more it mimics the real
> >> world and gets worse the more it deviates from it with things like
> >> "well, in Musicbrainz a release is not a release but ", "in
> >> Musicbrainz a recording is actually not a recording, but ...", etc. Of
> >> course it is one release.
> >
> > The real world has release events.  Different stores in different
> > countries make releases
> > available at different times.  Deal with it.
>
> Earlier I thought you agreed that the situation isn't ideal, but now I
> should just "deal with it"?
> The real world has both "released objects" (not a good term, I know)
> and "release events". Things can be said about both of them. Certainly
> there are not ~50 (or even 5) different entities in the real world
> that happen to have the same track list, the same bar code, the same
> cover, etc.
>
> >> I wonder if the (good) release we have in MBz is the old or the new one.
> >> If you buy it from that webshop, do you get a Tuvalu release (.tv)? :-)
> >
> > It's tv as in television I presume.
>
> Yes, suggesting Tuvalu was a joke of course. But also a question for
> you. Would you like yet another release entry for the release from the
> official webshop? And what country would you write?
>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
>
_

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Per Starbäck]

>> Surely it's good to store that in MBz, but not to make it
>> unmanageable and less useful for any other purpose until there is a
>> good way to store this.
>>
>
> I would not say it makes it "unmangeable and less useful".  How do you
> think it does?

If I have a cd in front of me and want to know more about it it makes
it less useful because there is no entity in the database that
corresponds to that cd. I have to choose one release entry and read
what information there is about that cd there. Or rather look up all
release entries and see what information they have about the cd, since
I don't know if some information is only in one place.

>> The current entry for that
>> release group is simply a lot less useful. If your principle was
>> carried out generally for all releases it would be unwieldy for such a
>> large part of my cds that I wouldn't use MBz anymore for ripping cds
>> (and therefore probably not use it at all). It would simply not be
>> useful.
>
> That principle is already applied to other release groups.  It's how the 
> schema
> of MB currently is, like it or not.

Yes, for some other release groups, but I wrote about what would
happen if it was carried out generally. It's like HumHumX's comment in
http://musicbrainz.org/edit/17774115 :

" There are currently 10,000 European releases in the database,
multiplied by 50 states equals 500,000 releases.
" That would be 1/3 of all releases in the database. Is that worth the
effort? I'm not saying you'd be doing anything
" wrong, it's just infinitely inconvenient compared to putting the
detailed info (away) in an annotation.

> I noticed the 1:1 disc ID resolution was broken as soon as NGS hit.
> Have you not
> been using MusicBrainz much over the last year?

Eh, yes? I've noticed lots of things that are not ideal that I haven't
complained about.

> I say this because you seem to be saying that this event data is not worth
> storing and not a reflection of reality, when it is.

No, I didn't say that. Or that.

>> But also a question for
>> you. Would you like yet another release entry for the release from the
>> official webshop? And what country would you write?
>>
>
> It depends if we have dates it was made available and countries they ship to.

Surely there was a release of the cd there, regardless of whether we
know what date it was or not.
And it would surprise me a lot if they refused to ship to any country.

> I've already noted that Poland doesn't have a digital version of this release
> (and so presumably no physical either).  So generalising to "Europe" is going
> overboard.

There are no physical "versions" at all. Didn't you agree with that earlier?
(Except there is, as I noted earlier.)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Per Starbäck]

> Furthermore, I often find it incredibly difficult to determine the release
> country of a release. Ok I deal a lot with Japanese releases, those are
> easy, but let's take a western example, the Putumayo label releases. If I
> enter a release in MB, I have this mind:. 1.) The label is British, 2.) I
> know for a fact the same exact CD is for sale in US and Canada. I'm in
> Canada, which is where I bought it. Which country should I enter? Should it
> be worldwide? (That's not how the majority of these releases are
> classified).

I totally agree (except for me it's the Swedish releases that are
easy). Very often I don't enter any country at all, because I really
don't know. And when I want to add information on an existing release
it can make me hesitant when the existing release (entry) has a
specific country that really isn't mentioned on the European release I
have. Did the previous editor have another version so I shouldn't add
my barcode there? Or did they just write the Netherlands there because
they happened to buy it there?

> Basically, I think the "MB Release" should represent the physical released
> medium (with a unique barcode/label/label #), and then the "release events"
> (ie release date/country) should be stored within each "MB Release".

I would like a "MB Release" of a physical object include all media,
covers etc. Of course new disc means new release, but also new cover
means new release. The same disc-ID can go to several releases, but if
you have the (complete) object you can determine which one it is you
have.

(For digital releases I'm not sure where I'd like the line for new
releases to go.)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Andii Hughes]

On 28 May 2012 22:47, Per Starbäck  wrote:
>>> Surely it's good to store that in MBz, but not to make it
>>> unmanageable and less useful for any other purpose until there is a
>>> good way to store this.
>>>
>>
>> I would not say it makes it "unmangeable and less useful".  How do you
>> think it does?
>
> If I have a cd in front of me and want to know more about it it makes
> it less useful because there is no entity in the database that
> corresponds to that cd. I have to choose one release entry and read
> what information there is about that cd there. Or rather look up all
> release entries and see what information they have about the cd, since
> I don't know if some information is only in one place.

I agree it's a problem and there's already a bug to fix this by allowing
multiple events per release.

>
>>> The current entry for that
>>> release group is simply a lot less useful. If your principle was
>>> carried out generally for all releases it would be unwieldy for such a
>>> large part of my cds that I wouldn't use MBz anymore for ripping cds
>>> (and therefore probably not use it at all). It would simply not be
>>> useful.
>>
>> That principle is already applied to other release groups.  It's how the 
>> schema
>> of MB currently is, like it or not.
>
> Yes, for some other release groups, but I wrote about what would
> happen if it was carried out generally. It's like HumHumX's comment in
> http://musicbrainz.org/edit/17774115 :

Carried what out generally?

>
> " There are currently 10,000 European releases in the database,
> multiplied by 50 states equals 500,000 releases.
> " That would be 1/3 of all releases in the database. Is that worth the
> effort? I'm not saying you'd be doing anything
> " wrong, it's just infinitely inconvenient compared to putting the
> detailed info (away) in an annotation.

No-one is suggesting this.  The correct way to replace such releases would be
with more accurate date for individual countries as it is found, not
just to assume
that it can be expanded to every country in "Europe".  And how do you
define those
countries to start with?

>
>> I noticed the 1:1 disc ID resolution was broken as soon as NGS hit.
>> Have you not
>> been using MusicBrainz much over the last year?
>
> Eh, yes? I've noticed lots of things that are not ideal that I haven't
> complained about.

Ok, then I'm puzzled as to why you seem to think this is a new issue.

>
>> I say this because you seem to be saying that this event data is not worth
>> storing and not a reflection of reality, when it is.
>
> No, I didn't say that. Or that.
>

Ok, my mistake.  That's how it came across.

>>> But also a question for
>>> you. Would you like yet another release entry for the release from the
>>> official webshop? And what country would you write?
>>>
>>
>> It depends if we have dates it was made available and countries they ship to.
>
> Surely there was a release of the cd there, regardless of whether we
> know what date it was or not.

If you don't have a date or country, what entry is there to make?

> And it would surprise me a lot if they refused to ship to any country.

Then prepare to be surprised.  Most sites have a defined list of
places they can ship to.
There are sites that only ship within the US.  Some places can't be
shipped to due to
export regulations.

>
>> I've already noted that Poland doesn't have a digital version of this release
>> (and so presumably no physical either).  So generalising to "Europe" is going
>> overboard.
>
> There are no physical "versions" at all. Didn't you agree with that earlier?
> (Except there is, as I noted earlier.)

I don't follow what you're saying here.  There certainly is a physical
CD version as I have it...

>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style



-- 
Andii :-)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Wieland Hoffmann]

Hallo Andii Hughes:
> On 28 May 2012 21:33, Per Starbäck  wrote:
> > Says you. Whereas destroying the usability of MBz because of that
> > principle is simply not acceptable to me. The current entry for that
> > release group is simply a lot less useful. If your principle was
> > carried out generally for all releases it would be unwieldy for such a
> > large part of my cds that I wouldn't use MBz anymore for ripping cds
> > (and therefore probably not use it at all). It would simply not be
> > useful.
> 
> That principle is already applied to other release groups.  It's how the 
> schema
> of MB currently is, like it or not.

I'm also under the impression that that's how NGS is/was supposed to
work - the release/medium examples on [0] all include *at least* the
release date and country to identify a specific release.

[1] also states that

> Information that was previously stored in a release event will now be
> stored at the release-level, effectively making each pre-NGS release
> event a separate NGS release, complete with its own MBID.

and the pre-NGS release events *did* include date and country fields.

[0] http://musicbrainz.org/doc/MusicBrainz_Database/Schema
[1] http://musicbrainz.org/doc/Server_Release_Notes/NGS_Beta_1#Release

-- 
Wieland

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Andii Hughes]

On 29 May 2012 10:29, Wieland Hoffmann  wrote:
> Hallo Andii Hughes:
>> On 28 May 2012 21:33, Per Starbäck  wrote:
>> > Says you. Whereas destroying the usability of MBz because of that
>> > principle is simply not acceptable to me. The current entry for that
>> > release group is simply a lot less useful. If your principle was
>> > carried out generally for all releases it would be unwieldy for such a
>> > large part of my cds that I wouldn't use MBz anymore for ripping cds
>> > (and therefore probably not use it at all). It would simply not be
>> > useful.
>>
>> That principle is already applied to other release groups.  It's how the 
>> schema
>> of MB currently is, like it or not.
>
> I'm also under the impression that that's how NGS is/was supposed to
> work - the release/medium examples on [0] all include *at least* the
> release date and country to identify a specific release.
>
> [1] also states that
>
>> Information that was previously stored in a release event will now be
>> stored at the release-level, effectively making each pre-NGS release
>> event a separate NGS release, complete with its own MBID.
>
> and the pre-NGS release events *did* include date and country fields.
>
> [0] http://musicbrainz.org/doc/MusicBrainz_Database/Schema
> [1] http://musicbrainz.org/doc/Server_Release_Notes/NGS_Beta_1#Release
>

Exactly.  This is how it is.  You can't just pretend it's something else.

> --
> Wieland
>
> ___
> MusicBrainz-style mailing list
> MusicBrainz-style@lists.musicbrainz.org
> http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style



-- 
Andii :-)

___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Merging Eurovision Song Contest: Baku 2012 (again)

[Ryan Torchia]

The consequences of not having one MB release per physical issue is more
about end user identifiably.  A user shouldn't have to have the historical
background on a release they own in order to identify which MB Release it
represents. There must be some physically identifiable element, even
something trivial, to allow users to match a physical release to a single
MB release -- this is needed for personal collections and to know which
specific issues need updating.  If we don't draw the line here, what's to
prevent users from assuming their release is different and adding another
release?

(And there will be instances where such a difference has to be relegated to
the "non-machine readable" annotations, such as releases with mastering
errors, misprints, different colored vinyl, etc.)

Temporarily making a piece of data non-machine readable until the
infrastructure is in place to support it is not the same as "destroying" it.
--Torc.
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style