Clarification needed on remastered releases.

[doidy]

I was trying to get my Galaxie 500 collection syncronized with MB and was wondering what was to be done with the multiple releases of their album "Today".  As you can see on the Discogs page ( http://www.discogs.com/artist/Galaxie+500 ), there were two releases of "Today" that had 11 tracks.  The one in 1991 was not remastered, and the one in 1997 was.  Not sure whether these should be entered as separate MB releases or just one with different dates.  My searching came up with http://wiki.musicbrainz.org/HowToMergeReleases which states among releases that shouldn't be merged: "Remasters of the same release, especially if the audio sounds different".  I also came upon http://wiki.musicbrainz.org/DuplicateRelease which says more or less the same thing.

Armed with this knowledge, I made the mod http://musicbrainz.org/showmod.html?modid=5114435 only to find later a no vote on the basis that "AFAIK, remastered versions with identical tracks don't appear as seperate releases in MB".  I looked at the voter's (Stell) history of failed mods and I can totally see why he voted no on this, after seeing http://musicbrainz.org/showmod.html?modid=4415316 , http://musicbrainz.org/showmod.html?modid=4415272 and several others.

I guess my question is: is the wiki right or are these mods right?  I have heard the Rough Trade release and the Ryko release of "Today" and the remastering is evident.  By what I have researched, these should be separate releases.  Supposing they were merged as one release with two different dates, could I add an Advanced Relationship RemasterRelationshipType between the 11 track MB release and the original 9 track version?  After all, I would be saying that this entire release was a remaster of the earlier version, which would actually not be true, since the hypothetical two release dates for the one record actually denote fundamentally different releases.

If the consensus is that this is okay and remasters and original masters should have the same MB release, can this information be removed from the wiki?

Thanks for the consideration.  I certainly don't want to be argumentative and I just want to conform to the rules and avoid making mods like this that people will have good reason to vote 'no' on.

-Steve

[DonRedman]

On Sun, 02 Jul 2006 05:11:30 +0200, doidy wrote:

> I guess my question is: is the wiki right or are these mods right?  I  
> have
> heard the Rough Trade release and the Ryko release of "Today" and the
> remastering is evident.  By what I have researched, these should be  
> separate
> releases.  Supposing they were merged as one release with two different
> dates, could I add an Advanced Relationship RemasterRelationshipType  
> between
> the 11 track MB release and the original 9 track version?  After all, I
> would be saying that this entire release was a remaster of the earlier
> version, which would actually not be true, since the hypothetical two
> release dates for the one record actually denote fundamentally different
> releases.
>
> If the consensus is that this is okay and remasters and original masters
> should have the same MB release, can this information be removed from the
> wiki?
>
> Thanks for the consideration.  I certainly don't want to be argumentative
> and I just want to conform to the rules and avoid making mods like this  
> that people will have good reason to vote 'no' on.

Steve,

you have hit a delicate problem here. I think th eproblem is that there is  
no consensus. Currently MusicBrainz is moving from a policy according to  
which releases were merged as much as possible to a policy according to  
which releases are kept separate if they differ by some substantial detail.
What that substantial detail is is a controversial matter.

I think I will raise this issue on the style mailing list, but this might  
spark some lengthy debate.

In the meantime, I suggest you enter the album as a separate one. It is  
clear that on the long run such albums will be separated and I think we  
are loosing information if we merge them now.

E.g. if you have both albums, you can generate PUIDs for all tracks. Those  
will be different (since the audio is different). If these get merged into  
one release, then people will tag their files against the wrong track with  
PUID lookups.

   DonRedman


--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Gecks]

On 02/07/06, Don Redman <donredman@...> wrote:

> On Sun, 02 Jul 2006 05:11:30 +0200, doidy wrote:
>
> > I guess my question is: is the wiki right or are these mods right?  I
> > have
> > heard the Rough Trade release and the Ryko release of "Today" and the
> > remastering is evident.  By what I have researched, these should be
> > separate
> > releases.  Supposing they were merged as one release with two different
> > dates, could I add an Advanced Relationship RemasterRelationshipType
> > between
> > the 11 track MB release and the original 9 track version?  After all, I
> > would be saying that this entire release was a remaster of the earlier
> > version, which would actually not be true, since the hypothetical two
> > release dates for the one record actually denote fundamentally different
> > releases.
> >
> > If the consensus is that this is okay and remasters and original masters
> > should have the same MB release, can this information be removed from the
> > wiki?
> >
> > Thanks for the consideration.  I certainly don't want to be argumentative
> > and I just want to conform to the rules and avoid making mods like this
> > that people will have good reason to vote 'no' on.
>
> Steve,
>
> you have hit a delicate problem here. I think th eproblem is that there is
> no consensus. Currently MusicBrainz is moving from a policy according to
> which releases were merged as much as possible to a policy according to
> which releases are kept separate if they differ by some substantial detail.
> What that substantial detail is is a controversial matter.
>
> I think I will raise this issue on the style mailing list, but this might
> spark some lengthy debate.
>
> In the meantime, I suggest you enter the album as a separate one. It is
> clear that on the long run such albums will be separated and I think we
> are loosing information if we merge them now.

i don't agree. what info are we losing? the tracklist is the same, it
is just another release event (release date). you can state that it
was remastered in the annotation. another full release is only worth
entering if the tracklist is different.

as i stated in the boxsetnamestyle discussion on the style list,
listing by 'product' is not a direction i want to see MBz going in,
and i believe that a lot of other users will think the same once/if
that becomes a real possibility. i think listing such releases
seperately now is really jumping the gun, and doesn't make sense when
we've got different pressings/country releases/formats (vinyl etc)
listed under the same 'release' (not that i think we should have those
seperately either!).

for the record, none of my 100+ subscribed artists has a single
unmerged remaster. nor indeed has any got any mention of that fact in
the annotation. it's just outside of MBz scope IMO.

> E.g. if you have both albums, you can generate PUIDs for all tracks. Those
> will be different (since the audio is different). If these get merged into
> one release, then people will tag their files against the wrong track with
> PUID lookups.

i'm not so sure this is true. a remaster may not change the audio to
the extent that PUIDs would be different. at least with TRMs i was
under the impression that the granularity of fingerprint was not
enough to make the distinction. i realise PUIDs have increased
granularity, but perhaps not enough?

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[doidy]

Gecks wrote:

for the record, none of my 100+ subscribed artists has a single
unmerged remaster. nor indeed has any got any mention of that fact in
the annotation. it's just outside of MBz scope IMO.

I haven't seen it, either, really, and I'm fine if this discussion leads to changes, but doesn't that just mean that people aren't following the rules as they're set forth on the wiki?  I mean, if you saw a remaster and an original release under an artist that have the same tracks, would you merge them?  Or would you follow what it says on http://wiki.musicbrainz.org/HowToMergeReleases ?

It's frustrating to get notes and no votes berating one for not following the rules, and then run into problems with people citing "I've only seen it done this way" or "I got voted down when I tried this" instead of actual guidelines and whatnot.  If people are going to vote something up or down, it should be because of official guidelines, otherwise, what's the point of having them?  This goes for more than just this one instance.

(Also, I don't see how classifying a specifc release as being a remaster is outside the scope of MBz when we have an AdvancedRelationship just for that purpose)



-Steve

[Simon Reinhardt]

Chris Bransden wrote:
> as i stated in the boxsetnamestyle discussion on the style list,
> listing by 'product' is not a direction i want to see MBz going in,
> and i believe that a lot of other users will think the same once/if
> that becomes a real possibility. i think listing such releases
> seperately now is really jumping the gun, and doesn't make sense when
> we've got different pressings/country releases/formats (vinyl etc)
> listed under the same 'release' (not that i think we should have those
> seperately either!).

Did you follow the ideas for a next generation schema? If not you should urgently read http://wiki.musicbrainz.org/NextGenerationSchema and bring in your ideas and opinions. Because it is already more than a possibility that exactly what you describe here becomes reality. Next generation schema aims at massive duplicating to have all releases that were produced in the db while on the other hand providing the means to group them (as well as the tracks). And you are the first one I've heard of so far who thinks this is outside of MB's scope.

> for the record, none of my 100+ subscribed artists has a single
> unmerged remaster. nor indeed has any got any mention of that fact in
> the annotation. it's just outside of MBz scope IMO.

No mention of different release data in the annotation? Go and fix that! ;)

Simon (Shepard)

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Simon Reinhardt]

Chris Bransden wrote:
> as i stated in the boxsetnamestyle discussion on the style list,
> listing by 'product' is not a direction i want to see MBz going in,
> and i believe that a lot of other users will think the same once/if
> that becomes a real possibility. i think listing such releases
> seperately now is really jumping the gun, and doesn't make sense when
> we've got different pressings/country releases/formats (vinyl etc)
> listed under the same 'release' (not that i think we should have those
> seperately either!).

Did you follow the ideas for a next generation schema? If not you should urgently read http://wiki.musicbrainz.org/NextGenerationSchema and bring in your ideas and opinions. Because it is already more than a possibility that exactly what you describe here becomes reality. Next generation schema aims at massive duplicating to have all releases that were produced in the db while on the other hand providing the means to group them (as well as the tracks). And you are the first one I've heard of so far who thinks this is outside of MB's scope.

> for the record, none of my 100+ subscribed artists has a single
> unmerged remaster. nor indeed has any got any mention of that fact in
> the annotation. it's just outside of MBz scope IMO.

No mention of different release data in the annotation? Go and fix that!  ;)

Simon (Shepard)

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Lauri Watts]

On 7/3/06, doidy <arc_dx@...> wrote:
> I haven't seen it, either, really, and I'm fine if this discussion leads to
> changes, but doesn't that just mean that people aren't following the rules
> as they're set forth on the wiki?  I mean, if you saw a remaster and an
> original release under an artist that have the same tracks, would you merge
> them?  Or would you follow what it says on
> http://wiki.musicbrainz.org/HowToMergeReleases ?

If the number of tracks is the same, and the track times within a
second or two of each other, I regularly merge remasters, reissues,
and original releases.  And I add all the information about the
releases, including dates and catalog numbers, to the album itself,
and to the annotation.

I have never had one of these merges fail a vote.  Indeed, unless one
of the albums in question has "remaster" in the title (which they
mostly don't), from anyone elses point of view, it's a perfectly
ordinary merging of duplicate albums.

I don't merge them if the track listings are different in either order
or number, or if the track times are substantially changed (more than
a couple of seconds difference)  I've never come across one that was
so near it was a hard decisiion, to be honest, usually when a remaster
has changed a track time, it does so by a substantial amount.

Regards,
--
Lauri Watts

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Gecks]

On 03/07/06, doidy <arc_dx@...> wrote:

>
>
> Gecks wrote:
> >
> >
> > for the record, none of my 100+ subscribed artists has a single
> > unmerged remaster. nor indeed has any got any mention of that fact in
> > the annotation. it's just outside of MBz scope IMO.
> >
>
> I haven't seen it, either, really, and I'm fine if this discussion leads to
> changes, but doesn't that just mean that people aren't following the rules
> as they're set forth on the wiki?  I mean, if you saw a remaster and an
> original release under an artist that have the same tracks, would you merge
> them?  Or would you follow what it says on
> http://wiki.musicbrainz.org/HowToMergeReleases ?

indeed, i just saw that myself! well it suprises me to be honest - i
thought this practice of merging remasters had wiki support, and i've
been an MBz user for 2 years, and an automod for 1. perhaps it had
support in the past which has since been removed/edited? or perhaps it
is simply the logical approach considering everything else we do
(IMO!).

> It's frustrating to get notes and no votes berating one for not following
> the rules, and then run into problems with people citing "I've only seen it
> done this way" or "I got voted down when I tried this" instead of actual
> guidelines and whatnot.  If people are going to vote something up or down,
> it should be because of official guidelines, otherwise, what's the point of
> having them?  This goes for more than just this one instance.

they're just 'guidelines', so people keep telling me :) i agree this
need to be changed, or at least re-discussed. but
data-retention/removal discussion seems to go everywhere and nowhere
at the moment :)

> (Also, I don't see how classifying a specifc release as being a remaster is
> outside the scope of MBz when we have an AdvancedRelationship just for that
> purpose)

i always thought that one was to relate remasters with bonus tracks,
which of course are seperately indexed.

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Gecks]

On 03/07/06, Simon Reinhardt <simon.reinhardt@...> wrote:

> Chris Bransden wrote:
> > as i stated in the boxsetnamestyle discussion on the style list,
> > listing by 'product' is not a direction i want to see MBz going in,
> > and i believe that a lot of other users will think the same once/if
> > that becomes a real possibility. i think listing such releases
> > seperately now is really jumping the gun, and doesn't make sense when
> > we've got different pressings/country releases/formats (vinyl etc)
> > listed under the same 'release' (not that i think we should have those
> > seperately either!).
>
> Did you follow the ideas for a next generation schema? If not you should urgently read http://wiki.musicbrainz.org/NextGenerationSchema and bring in your ideas and opinions. Because it is already more than a possibility that exactly what you describe here becomes reality. Next generation schema aims at massive duplicating to have all releases that were produced in the db while on the other hand providing the means to group them (as well as the tracks). And you are the first one I've heard of so far who thinks this is outside of MB's scope.

well I've always found NGS and the like to be somewhat to abstract a
concept to evaluate fully. It's one proposal that links to a number of
other proposals, all of which add up to...[unknown] :) i've done my
best to read through it again today and put my thoughts regarding an
alternative here -
http://wiki.musicbrainz.org/ReleaseGroupsAlternative - but whether or
not my ideas work alongside what NGS proposes I don't know because I
don't fully understand it.

> > for the record, none of my 100+ subscribed artists has a single
> > unmerged remaster. nor indeed has any got any mention of that fact in
> > the annotation. it's just outside of MBz scope IMO.
>
> No mention of different release data in the annotation? Go and fix that!  ;)

haha, hmm maybe when my proposal is allowed :)

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Simon Reinhardt]

Chris Bransden wrote:
> well I've always found NGS and the like to be somewhat to abstract a
> concept to evaluate fully. It's one proposal that links to a number of
> other proposals, all of which add up to...[unknown] :)

That's not really true (anymore). It takes some ideas from other proposals and therefore links to them, right. But NGS itself became more than that, it has new ideas that have nothing to do with ReleaseGroups or AlbumRework and it is more than just outlining them. I did my best to describe the current state on the NGS page. The in-depth documentation behind that, ObjectModel, is not yet complete, that is true.

> i've done my
> best to read through it again today and put my thoughts regarding an
> alternative here -
> http://wiki.musicbrainz.org/ReleaseGroupsAlternative - but whether or
> not my ideas work alongside what NGS proposes I don't know because I
> don't fully understand it.

What you are proposing is what my initial idea for AlbumRework was: sharing data. My idea was to split data down to a set of minimal objects which can be linked in a very sophisticated way to be able to reuse as much of the data as possible. And this covered more than just separating tracklistings from release info - because you can't stop there, that only solves half of the problems. We discussed that alot on the last summit and came to the result that the structure for this would be too complex. All the interlinking would make the database unusable. The alternative (as proposed by Don) was a simple hierarchical structure which implies lots of duplication but also makes accessing it much more realistic.

Steve Wyles said it quite well: "disc space is cheap". It's then only a question of adding the right features to tame the duplication (problems with inconsistent tracklistings for example or the fact that you will be presented several releases for a disc ID lookup). The good news is that the design for NGS itself already holds good means for this. That's what all the grouping is needed for. Discogs duplicates but discogs does not group the duplicated data. AdvancedRelationships will be no problem because they are not restricted to link on the lowest level in the hierarchie. Indeed solving our current AR linking problems is one of the main reasons for NGS.

You propose to separate products if they have a different tracklisting only. That's not how the reality works in my eyes. "Album X with 10 tracks" is a different release than "Album X with 10 tracks + bonus DVD Y" is a different than "Album X with 11 tracks". The same applies to releases on different labels, remasters, box set releases and whatnot.

Finally I have to say: I'm not at MusicBrainz for tagging. I'm here because I have a vision of an all-embracing music database and about the power of a working community. And I see that I can turn my ideas into reality here.
And if you look at what MusicBrainz already is and who already depends on us then it should be quite obvious that we are already more than a pure tagging database.
Oh and: last I looked Wikipedia linked to MB, not Discogs.

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Gecks]

On 03/07/06, Simon Reinhardt <simon.reinhardt@...> wrote:
> Chris Bransden wrote:
> > well I've always found NGS and the like to be somewhat to abstract a
> > concept to evaluate fully. It's one proposal that links to a number of
> > other proposals, all of which add up to...[unknown] :)
>
> That's not really true (anymore). It takes some ideas from other proposals and therefore links to them, right. But NGS itself became more than that, it has new ideas that have nothing to do with ReleaseGroups or AlbumRework and it is more than just outlining them. I did my best to describe the current state on the NGS page. The in-depth documentation behind that, ObjectModel, is not yet complete, that is true.

i didn't mean to say it wasn't clear/complete, just that i can't
personally get my head around what i'm going to be looking at on an
artist page/through the tagger when/if any of this comes to fruition.
with much of the server changes, i just find them difficult to
visualise till i actually use them.

you wouldn't think i spend all day working on database software but
there you go :)

> > i've done my
> > best to read through it again today and put my thoughts regarding an
> > alternative here -
> > http://wiki.musicbrainz.org/ReleaseGroupsAlternative - but whether or
> > not my ideas work alongside what NGS proposes I don't know because I
> > don't fully understand it.
>
> What you are proposing is what my initial idea for AlbumRework was: sharing data. My idea was to split data down to a set of minimal objects which can be linked in a very sophisticated way to be able to reuse as much of the data as possible. And this covered more than just separating tracklistings from release info - because you can't stop there, that only solves half of the problems. We discussed that alot on the last summit and came to the result that the structure for this would be too complex. All the interlinking would make the database unusable. The alternative (as proposed by Don) was a simple hierarchical structure which implies lots of duplication but also makes accessing it much more realistic.

i guess i don't see why seperating tracklistings from releases would
be too complex. what i propose is simply making our current release
events cover more than just date and country, but format, label, cat#,
and so forth.

> Steve Wyles said it quite well: "disc space is cheap". It's then only a question of adding the right features to tame the duplication (problems with inconsistent tracklistings for example or the fact that you will be presented several releases for a disc ID lookup). The good news is that the design for NGS itself already holds good means for this. That's what all the grouping is needed for. Discogs duplicates but discogs does not group the duplicated data. AdvancedRelationships will be no problem because they are not restricted to link on the lowest level in the hierarchie. Indeed solving our current AR linking problems is one of the main reasons for NGS.
>
> You propose to separate products if they have a different tracklisting only. That's not how the reality works in my eyes. "Album X with 10 tracks" is a different release than "Album X with 10 tracks + bonus DVD Y" is a different than "Album X with 11 tracks". The same applies to releases on different labels, remasters, box set releases and whatnot.

not to me! that's pretty much my entire arguement :) you can say a
release is available as different products without making a seoerate
entry, as i've shown. i don't see why this isn't possible, but then i
don't know the layout of the DB...

> Finally I have to say: I'm not at MusicBrainz for tagging. I'm here because I have a vision of an all-embracing music database and about the power of a working community. And I see that I can turn my ideas into reality here.
> And if you look at what MusicBrainz already is and who already depends on us then it should be quite obvious that we are already more than a pure tagging database.

look where? i see tagger users editing the data, and i see 'expert'
users adding further stuff like cat# etc to the annotation. the latter
are going the extra mile, and i'd like to make it so that info is
useful, but i don't see this as being synonymous as making umpteen
tracklist entries, all saying the same thing.

it seems there is a school of thought that says the only reason we
merge products together with the same tracklistings is because the
database can't handle things any other way. this may be true, but i
think this has perhaps unintentionally meant we have discographies
free from the gumpf that places like discogs are plagued with.

at discogs we got round it by having a 'copy to draft' facilty that
dupilicates a release, so you can edit the things that are different
on your edition (typically label, country, release date, cat#, etc),
and submit it. however this is a hack - you're still creating a dupe
of data, so why not just allow the submission of product info to
existing releases, rather than entire new releases all the time?

incidently, discogs is moving to a system similar to what i propose in
the future, i believe.

> Oh and: last I looked Wikipedia linked to MB, not Discogs.

http://en.wikipedia.org/wiki/Wikipedia:Notability_(music)  - and just
generally i see discogs cited a lot more in wikipedia than
musicbrainz, and really would you argue that we're a better
discography site than discogs right now?

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Simon Reinhardt]

Chris Bransden wrote:
> i didn't mean to say it wasn't clear/complete, just that i can't
> personally get my head around what i'm going to be looking at on an
> artist page/through the tagger when/if any of this comes to fruition.
> with much of the server changes, i just find them difficult to
> visualise till i actually use them.
>
> you wouldn't think i spend all day working on database software but
> there you go :)

Yeah I can see how that can be a problem. Probably the reason many people are still a bit afraid of NGS.

> i guess i don't see why seperating tracklistings from releases would
> be too complex. what i propose is simply making our current release
> events cover more than just date and country, but format, label, cat#,
> and so forth.

Yup, I did the same in ReleaseDataSet. And found this isn't enough, because it doesn't solve the issues with several discs of a release, disc IDs, multiple country+date sets for one and the same EAN - just to name a few. I don't want to sound arrogant - but believe me, I've spent a lot of time thinking about this. I've written several proposals just to notice shortcomings of them and overhauling my ideas again and again. And thus I do think I know of the current problems and of the problems of different proposals better than you.

>> Finally I have to say: I'm not at MusicBrainz for tagging. I'm here
>> because I have a vision of an all-embracing music database and about
>> the power of a working community. And I see that I can turn my ideas
>> into reality here.
>> And if you look at what MusicBrainz already is and who already depends
>> on us then it should be quite obvious that we are already more than a
>> pure tagging database.
>
> look where? i see tagger users editing the data, and i see 'expert'
> users adding further stuff like cat# etc to the annotation. the latter
> are going the extra mile, and i'd like to make it so that info is
> useful, but i don't see this as being synonymous as making umpteen
> tracklist entries, all saying the same thing.

Look at the sites and products which use our data already for example. And those which are to come.
And our user spectrum is more than just tagging users and expert users. There are tons of different aspects people see of MB (http://wiki.musicbrainz.org/AspectModel). MusicBrainz didn't start as a tagging platform, it started as a disc lookup platform. It then evolved to be primarily used for tagging - but we already left this behind us when introducing AR. Tagging is one of our goals but not the main goal anymore. Or do you think AR data was meant to be used for tagging only?

>> Oh and: last I looked Wikipedia linked to MB, not Discogs.
>
> http://en.wikipedia.org/wiki/Wikipedia:Notability_(music)  - and just
> generally i see discogs cited a lot more in wikipedia than
> musicbrainz

I don't. I've never come across a link to Discogs on an artist page but very often see MB links.

> and really would you argue that we're a better
> discography site than discogs right now?

Yes. Come out of the electronic music edge and look rock or pop discographies on Discogs. Then you'll notice how poorly armed Discogs is. Our big advantage is that we don't restrict to genres. It is true that MB's info is more second hand and Discogs' info first hand but that is just a matter of our current user base. With the break-up of freedb I can imagine the number of CD-owners at MB to grow. When we introduce NGS, Discogs will look very poor compared to us, that is my strong believe.

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Gecks]

On 03/07/06, Simon Reinhardt <simon.reinhardt@...> wrote:
> > i guess i don't see why seperating tracklistings from releases would
> > be too complex. what i propose is simply making our current release
> > events cover more than just date and country, but format, label, cat#,
> > and so forth.
>
> Yup, I did the same in ReleaseDataSet. And found this isn't enough, because it doesn't solve the issues with several discs of a release

this is only an issue if you feel the original should be 'album (disc
1)' (i say it should be 'album' and 'album (bonus disc)', else you
imply double album when that's a different thing entirely)

> disc IDs

disc IDs are just a way of getting from CD to tracklisting. keeping
disc IDs with specific releases is only important if you want seperate
tracklistings, which i don't :) i imagine most people would want the
original release date tagged to their files rather than date of their
particular product. if it's got the same tracklisting, there would be
no benefit in using the later date (eg you're not likely to have 2
products of the same tracklisting on yr pc).

also, it's highly likely that a disc ID would be the same across
reissues, assuming the pressing master doesn't change, so we're
already talking about duplication.

of course we could always assign disc ID to release event, rather than
to release...

> multiple country+date sets for one and the same EAN - just to name a few.

again, i think it would be better to assign these to release event
than to create entire new releases.

> I don't want to sound arrogant - but believe me, I've spent a lot of time thinking about this. I've written several proposals just to notice shortcomings of them and overhauling my ideas again and again. And thus I do think I know of the current problems and of the problems of different proposals better than you.

well it seems to me there's a difference in our MBz philosphy than the
actual logistics of either, but i'd be happy to hear any specific
reasons for why mine couldn't work.

> >> Finally I have to say: I'm not at MusicBrainz for tagging. I'm here
> >> because I have a vision of an all-embracing music database and about
> >> the power of a working community. And I see that I can turn my ideas
> >> into reality here.
> >> And if you look at what MusicBrainz already is and who already depends
> >> on us then it should be quite obvious that we are already more than a
> >> pure tagging database.
> >
> > look where? i see tagger users editing the data, and i see 'expert'
> > users adding further stuff like cat# etc to the annotation. the latter
> > are going the extra mile, and i'd like to make it so that info is
> > useful, but i don't see this as being synonymous as making umpteen
> > tracklist entries, all saying the same thing.
>
> Look at the sites and products which use our data already for example. And those which are to come.

which are? i've actually never known what these are - it all seems
very hush-hush (perhaps not intentionally so but there's nothing ever
announced on the blogs, mailing list or wiki as far as i've seen)

> And our user spectrum is more than just tagging users and expert users. There are tons of different aspects people see of MB (http://wiki.musicbrainz.org/AspectModel). MusicBrainz didn't start as a tagging platform, it started as a disc lookup platform. It then evolved to be primarily used for tagging - but we already left this behind us when introducing AR.

i really disagree with this. as great as it is, AR is not really in a
useful/usable state. as a 'user' of MBz i can safely say that AR is
very much a rare occurance on my subscribed artists. almost all edits
arenew additions, track title edits, etc. most AR edits are ASINs and
the like, which isn't really an AR...

> Tagging is one of our goals but not the main goal anymore. Or do you think AR data was meant to be used for tagging only?

i don't use it all...i have discogs for that stuff!

like i said, i have no problem with more features - i welcome them,
but not at the expense of the tagging functionality, which i believe
will be the case were to we allow mass duplication of data.

> >> Oh and: last I looked Wikipedia linked to MB, not Discogs.
> >
> > http://en.wikipedia.org/wiki/Wikipedia:Notability_(music)  - and just
> > generally i see discogs cited a lot more in wikipedia than
> > musicbrainz
>
> I don't. I've never come across a link to Discogs on an artist page but very often see MB links.

oh i don't doubt that - no doubt thanks to the excellent
http://en.wikipedia.org/wiki/Wikipedia:WikiProject_MusicBrainz (though
to be fair to discogs, it has achieved over half the number of
references on wikipedia compared to MBz, without such a project)

sorry, what i meant was, musicbrainz link to discogs, wikipedia links
to discogs (and uses it in citatations, not neccesarily 'links'), but
discogs links to neither (yet is info from it is transferred to both
the others, as well you know). discogs is pretty cast iron as far as
discography data goes, and doesn't need 2nd hand info (infact, you are
blacklisted if you are caught doing that)

> > and really would you argue that we're a better
> > discography site than discogs right now?
>
> Yes. Come out of the electronic music edge and look rock or pop discographies on Discogs. Then you'll notice how poorly armed Discogs is.

I'm a rock mod at discogs - that's my focus (not electronic at all).
take a look at http://www.discogs.com/release/535757 - you just can't
get this level of information into MBz at the moment, end of story.
and the info you can enter you can hardly see, and then there's the
lack of track-ranges, roles, labels, format, etc, etc. you really
can't be serious! show me one rock artists discography that's more
complete here than discogs.

> Our big advantage is that we don't restrict to genres.

well, discogs needs to do this because it the data has to come in
correctly first time to make it useful as a discography, so a the
rules for a new genre have  to be thrashed out properly. eg
'classical' has been in the making for the best part of 2 years as
it's such a complicated genre. apart from that, pretty much all genres
are covered now.

> It is true that MB's info is more second hand and Discogs' info first hand but that is just a matter of our current user base.

yep - tagger users!

> With the break-up of freedb I can imagine the number of CD-owners at MB to grow. When we introduce NGS, Discogs will look very poor compared to us, that is my strong believe.

well, i support both projects, so i hope they both succeed :)

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Lauri Watts]

On 7/3/06, Chris Bransden <chris@...> wrote:

> I'm a rock mod at discogs - that's my focus (not electronic at all).
> take a look at http://www.discogs.com/release/535757 - you just can't
> get this level of information into MBz at the moment, end of story.

I don't see anything on that page that you couldn't enter in MB other
than highly subjective genre information, and credits for
miscellaneous noises (something which comes up pretty often in some of
the artists I edit). But you can put those things in annotations, as a
stopgap for them becoming available later.

> and the info you can enter you can hardly see, and then there's the
> lack of track-ranges, roles, labels, format, etc, etc. you really
> can't be serious! show me one rock artists discography that's more
> complete here than discogs.

John Hiatt. By miles and miles.   And I haven't even barely got
started with it.  I've only AR'ed up about 3 albums, and that's
without doing the other direction (all the songs he's written for
other people, or appearances on other people's records.)  Ulf Lundell
(A swedish legend, the Bob Dylan of swedish rock).  And nobody's even
started the AR's for him yet either.  Discogs has a very long way to
go for anyone not electronic and not both top 40 and American.

The other problem is where Discogs does have a lot of data, it's
overwhelming and all just dumped on a page, and near impossible to
figure out what is what.   I've had an account on discogs for years,
but I rarely visit it, gave up entering my record collection after 2
pages.  I simply don't like the site.

Which is the point really.  Discogs suits some people, MB suits
others, as users, editors, and consumers of information.  It doesn't
bother me in the slightest that you like it though, and you really
shouldn't feel threatened that some of us prefer MB.  Freedom of
choice is good for everyone, especially while we are freely allowed to
use the information at discogs to beef up the accuracy here and vice
versa (although, I'm sure the latter is not exactly "allowed", but the
data here is free for that use)

Arguing who has more wikipedia links on the other hand, isn't much
good for anyone at all.

Regards,
--
Lauri Watts

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Simon Reinhardt]

Chris Bransden wrote:
> On 03/07/06, Simon Reinhardt <simon.reinhardt@...> wrote:
>> Yup, I did the same in ReleaseDataSet. And found this isn't enough,
>> because it doesn't solve the issues with several discs of a release
>
> this is only an issue if you feel the original should be 'album (disc
> 1)' (i say it should be 'album' and 'album (bonus disc)', else you
> imply double album when that's a different thing entirely)

I was talking about double disc releases. Try to bring more detail in your proposal and you will stumble over the same problems I encountered last year. I mean, you can go all this way, I just want to ease it for you. :P

> i imagine most people would want the
> original release date tagged to their files rather than date of their
> particular product.

I don't. That's a typical case for tagger script. But you can only let users chose between both if you can relate a disc ID to the actual date of the product in the first place.

> if it's got the same tracklisting, there would be
> no benefit in using the later date (eg you're not likely to have 2
> products of the same tracklisting on yr pc).

Oh, as a collector I have that very often.

> also, it's highly likely that a disc ID would be the same across
> reissues, assuming the pressing master doesn't change, so we're
> already talking about duplication.

Yes, which is why I listed it as one of the issues.

>> Look at the sites and products which use our data already for example.
>> And those which are to come.
>
> which are?

Last.fm for example.

> i really disagree with this. as great as it is, AR is not really in a
> useful/usable state. as a 'user' of MBz i can safely say that AR is
> very much a rare occurance on my subscribed artists. almost all edits
> arenew additions, track title edits, etc. most AR edits are ASINs and
> the like, which isn't really an AR...

Well as an AR-junky I have to disagree here, of course. I use it all day and of course know of its shortcomings but I still think it's one of the most important parts of MB.

>> Tagging is one of our goals but not the main goal anymore. Or do you
>> think AR data was meant to be used for tagging only?
>
> i don't use it all...i have discogs for that stuff!

I see, so you consider all of our AR efforts useless? :P

> and the info you can enter you can hardly see

Did you take a look at the new server release? :)
And it gets better each day.

> and then there's the lack of track-ranges

That's a proposal I don't like anyways. :P

> you really
> can't be serious! show me one rock artists discography that's more
> complete here than discogs.

No problem, here are my top five on last.fm:
http://www.discogs.com/artist/Dream+Theater - http://musicbrainz.org/artist/28503ab7-8bf2-4666-a7bd-2644bfc7cb1d.html
http://www.discogs.com/artist/Threshold+(3) - http://musicbrainz.org/artist/ed021420-1f77-412e-8745-67567a886150.html
http://www.discogs.com/artist/Kamelot - http://musicbrainz.org/artist/2449300a-6ca7-45da-8102-22789d256475.html
http://www.discogs.com/artist/Spock%27s+Beard - http://musicbrainz.org/artist/9e57e406-4fb1-40d0-bcd2-2aa1d6390c1d.html
http://www.discogs.com/artist/Angra - http://musicbrainz.org/artist/b0fe8ef0-d59b-4d41-afee-2d21b59112ab.html
All more complete on MB than on Discogs. And those aren't even unknown bands. The obscurer it gets, the less complete is Discogs compared to MB.

>> Our big advantage is that we don't restrict to genres.
>
> well, discogs needs to do this because it the data has to come in
> correctly first time to make it useful as a discography, so a the
> rules for a new genre have  to be thrashed out properly. eg
> 'classical' has been in the making for the best part of 2 years as
> it's such a complicated genre. apart from that, pretty much all genres
> are covered now.

Theoretically, not in the data amount. And - pardon - but genre classification is pretty much useless anyways.


As you can see this is a very cluttered discussion and I don't see it going anywhere useful since we have completely different ideas obviously. Different ideas are good for MB - but not for me at the moment as it's too hot for thinking here. :P
So I will step out of this discussion.

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Gecks]

On 03/07/06, Lauri Watts <krazykiwi@...> wrote:

> On 7/3/06, Chris Bransden <chris@...> wrote:
>
> > I'm a rock mod at discogs - that's my focus (not electronic at all).
> > take a look at http://www.discogs.com/release/535757 - you just can't
> > get this level of information into MBz at the moment, end of story.
>
> I don't see anything on that page that you couldn't enter in MB other
> than highly subjective genre information, and credits for
> miscellaneous noises (something which comes up pretty often in some of
> the artists I edit). But you can put those things in annotations, as a
> stopgap for them becoming available later.

Well, annotations are a freetext field so you can put essentially any
info you want there, but i don't see that as a valid equivalient to
dedicated fields.

> > and the info you can enter you can hardly see, and then there's the
> > lack of track-ranges, roles, labels, format, etc, etc. you really
> > can't be serious! show me one rock artists discography that's more
> > complete here than discogs.
>
> John Hiatt. By miles and miles.   And I haven't even barely got
> started with it.  I've only AR'ed up about 3 albums, and that's
> without doing the other direction (all the songs he's written for
> other people, or appearances on other people's records.)  Ulf Lundell
> (A swedish legend, the Bob Dylan of swedish rock).  And nobody's even
> started the AR's for him yet either.

fair enough, but it seems like both of these are the work of one
person (yourself) so it's not really representative of what I'm trying
to say. how about artists who would have been updated by more than one
person? http://www.discogs.com/artist/Sonic+Youth for example is much
more indepth than the MBz entry, despite having plenty of subscribers
http://musicbrainz.org/view/artist/subscriptions.html?artist=3257

on the whole discogs has more complete (or near complete)
discographies when you think about labels, formats and so forth.

> Discogs has a very long way to
> go for anyone not electronic and not both top 40 and American.

if this were true i'd be able to get through my dailying modding a lot
quicker. it's mostly obscure stuff coming through now. have a look at
the latest additions http://rock.discogs.com/ - you'll see a pretty
eclectic mix. also, there are more german and english users in discogs
than americans...

> The other problem is where Discogs does have a lot of data, it's
> overwhelming and all just dumped on a page, and near impossible to
> figure out what is what.   I've had an account on discogs for years,
> but I rarely visit it, gave up entering my record collection after 2
> pages.  I simply don't like the site.

fair enough!

> Which is the point really.  Discogs suits some people, MB suits
> others, as users, editors, and consumers of information.  It doesn't
> bother me in the slightest that you like it though, and you really
> shouldn't feel threatened that some of us prefer MB.

i like *both* of them, but for different reasons.

anyways, can we please talk about the proposal rather than discogs vs
musicbrainz. i'll argue it's corner (and indeed, our corner when in
similar discussions over there) but if we can't learn from each other
then there's little point.

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[Gecks]

this is getting more into the MBz vs Discogs stuff, and AR usability
than my actual proposal but heres my responses anyway:

On 03/07/06, Simon Reinhardt <simon.reinhardt@...> wrote:

> Chris Bransden wrote:
> > On 03/07/06, Simon Reinhardt <simon.reinhardt@...> wrote:
> >> Yup, I did the same in ReleaseDataSet. And found this isn't enough,
> >> because it doesn't solve the issues with several discs of a release
> >
> > this is only an issue if you feel the original should be 'album (disc
> > 1)' (i say it should be 'album' and 'album (bonus disc)', else you
> > imply double album when that's a different thing entirely)
>
> I was talking about double disc releases. Try to bring more detail in your proposal and you will stumble over the same problems I encountered last year. I mean, you can go all this way, I just want to ease it for you. :P

i don't see these problems so i guess that is that :)

> > i imagine most people would want the
> > original release date tagged to their files rather than date of their
> > particular product.
>
> I don't. That's a typical case for tagger script.

true. i'm looking forward to that one.

> But you can only let users chose between both if you can relate a disc ID to the actual date of the product in the first place.

well that assumes a disc ID exists in the first place! you're still
going to have to allow users a choice of release dates. if they supply
a CD-ID, then you could assign a date based on that, but also might
need to have a choice as CD-IDs (ie CD pressings) may span different
releases of the same CD.

like i said i think it would be better to just start assigning CD-IDs
to release events, rather than creating a new release around them.

> > if it's got the same tracklisting, there would be
> > no benefit in using the later date (eg you're not likely to have 2
> > products of the same tracklisting on yr pc).
>
> Oh, as a collector I have that very often.

me to, but i would't want to rip and tag both versions. i want to rip
and tag the best version (normally the remaster) with the release
tracklisting, and dated to the date of original release. then i can
say "play all the Band Y albums in chronological order" on my media
player and it works as expected. but you know, that's just me!

> >> Look at the sites and products which use our data already for example.
> >> And those which are to come.
> >
> > which are?
>
> Last.fm for example.

hmm, i knew about that one i guess :) that's how i found this place.
but i would have thought that if anything, last.fm would favour a
unified tracklisting to unify their stats.

> > i really disagree with this. as great as it is, AR is not really in a
> > useful/usable state. as a 'user' of MBz i can safely say that AR is
> > very much a rare occurance on my subscribed artists. almost all edits
> > arenew additions, track title edits, etc. most AR edits are ASINs and
> > the like, which isn't really an AR...
>
> Well as an AR-junky I have to disagree here, of course. I use it all day and of course know of its shortcomings but I still think it's one of the most important parts of MB.
>
> >> Tagging is one of our goals but not the main goal anymore. Or do you
> >> think AR data was meant to be used for tagging only?
> >
> > i don't use it all...i have discogs for that stuff!
>
> I see, so you consider all of our AR efforts useless? :P

no, do what you want :) though i just don't see the point when discogs
does the same thing better. i'm talking about the usability of the 2
different systems for the same end product - getting liner notes onto
a database. discogs is simply better at entering it, and better at
displaying it *at the moment*. this is getting off topic though...

> > and the info you can enter you can hardly see
>
> Did you take a look at the new server release? :)
> And it gets better each day.

yeah, i like it! but that's just one of the many steps that needs to
be taken IMO. we still need:
- freetext fields for further info on roles
- track ranges
- better input (should be able to do all relationships edits on the one page)
- ability to create bespoke roles as they appear.

i started at the front of my collection and tried to do ARs but i ran
into the co-producer thing which was resolved after 1 month plus of
heavy debate, and then i hit the written by vs composed by discussion
which still hasn't been resolved
(http://wiki.musicbrainz.org/WriterRelationshipType if anyone cares).
so yeah, you'll have to excuse me if i don't have the greatest faith
in AR right now :P

> > and then there's the lack of track-ranges
>
> That's a proposal I don't like anyways. :P

getting off topic now but what don't you like about that? surely it
would be better to be able to input "Artist did X on tracks 1-8, 10,
13 of Album Y" rather than doing it for each of the tracks in
question, or just giving them a global release credit and ignore the
fact they weren't on all tracks (appears to be the common practice on
my artists).

> > you really
> > can't be serious! show me one rock artists discography that's more
> > complete here than discogs.
>
> No problem, here are my top five on last.fm:
> http://www.discogs.com/artist/Dream+Theater - http://musicbrainz.org/artist/28503ab7-8bf2-4666-a7bd-2644bfc7cb1d.html
> http://www.discogs.com/artist/Threshold+(3) - http://musicbrainz.org/artist/ed021420-1f77-412e-8745-67567a886150.html
> http://www.discogs.com/artist/Kamelot - http://musicbrainz.org/artist/2449300a-6ca7-45da-8102-22789d256475.html
> http://www.discogs.com/artist/Spock%27s+Beard - http://musicbrainz.org/artist/9e57e406-4fb1-40d0-bcd2-2aa1d6390c1d.html
> http://www.discogs.com/artist/Angra - http://musicbrainz.org/artist/b0fe8ef0-d59b-4d41-afee-2d21b59112ab.html
> All more complete on MB than on Discogs. And those aren't even unknown bands. The obscurer it gets, the less complete is Discogs compared to MB.

fair enough :) well to be fair to discogs, the rock genre was at 0
releases only till a year or so ago. comparing electronic releases
(level playing field for both systems) is a different story entirely.
give rock another year (at the moment there's about a 3 month wait for
new releases) and things will be different, but at least for my
artists, everythings comin' up millhouse.

> >> Our big advantage is that we don't restrict to genres.
> >
> > well, discogs needs to do this because it the data has to come in
> > correctly first time to make it useful as a discography, so a the
> > rules for a new genre have  to be thrashed out properly. eg
> > 'classical' has been in the making for the best part of 2 years as
> > it's such a complicated genre. apart from that, pretty much all genres
> > are covered now.
>
> Theoretically, not in the data amount.

well, like i said, consider that discogs was electronic-only till only
a year or so ago. but it isn't restricted to genres, it was just built
around electronic releases, then was expanded to include everything.
this pretty much happened overnight, with only classical and 'world'
being held back due to some to the unique nature of their data (CSG,
anyone?)

> And - pardon - but genre classification is pretty much useless anyways.

i agree. think of it more like a way of splitting up styles (eg, genre
= rock, style = thrash metal) like you would in a music store. the way
releases are handled is identicle across all genres. (classical might
be different...)

> As you can see this is a very cluttered discussion and I don't see it going anywhere useful since we have completely different ideas obviously. Different ideas are good for MB - but not for me at the moment as it's too hot for thinking here. :P
> So I will step out of this discussion.

unfortunately i am signed up for life now :P

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[DonRedman]

Uff, this post got really long, so I'll give a short summary:

I describe two usage cases of the NextGenerationSchem in detail (ripping a  
CD and tagging files) and try to show that NGS is able to do exactly what  
Chris wants MB to do. These examples make the very abstract ObjectModel  
more concrete and give explanations for some design decisions made on the  
last MB summit.
Finally I explain why it is important to keep remasters apart.


On Mon, 03 Jul 2006 16:28:20 +0200, Chris Bransden wrote:

> On 03/07/06, Simon Reinhardt <simon.reinhardt@...> wrote:
>> Yup, I did the same in ReleaseDataSet. And found this isn't enough,  
>> because it doesn't solve the issues with several discs of a release
>
> this is only an issue if you feel the original should be 'album (disc
> 1)' (i say it should be 'album' and 'album (bonus disc)', else you
> imply double album when that's a different thing entirely)
>
>> disc IDs
>
> disc IDs are just a way of getting from CD to tracklisting. keeping
> disc IDs with specific releases is only important if you want seperate
> tracklistings, which i don't :) i imagine most people would want the
> original release date tagged to their files rather than date of their
> particular product. if it's got the same tracklisting, there would be
> no benefit in using the later date (eg you're not likely to have 2
> products of the same tracklisting on yr pc).
>
> also, it's highly likely that a disc ID would be the same across
> reissues, assuming the pressing master doesn't change, so we're
> already talking about duplication.
>
> of course we could always assign disc ID to release event, rather than
> to release...

Chris, I think you are missing a point of what NGS can do. I believe that  
if you understand that aspect, you will not argue that fiercely against  
NGS. I might be wrong, in which case I really want to understand your  
criticism, because then I have misunderstood you.


IIUC you want to be able to tag an album against a standardized tracklist  
with standardized track titles and album titles. You want this data to be  
stored in MB in a practical and maintainable way.

NGS will allow you to do exactly that! I will show that for MP3s and for  
CDs.

Please take a look at the illustation on  
<http://wiki.musicbrainz.org/ObjectModel> and follow along.

  (A) Say you have a CD that you want to rip on your computer. You put it  
in your drive and rip it with a fantastical NGS-MB enabled Ripper called  
Jack. :-) Jack the Ripper gets the DiscID and looks it up in MB. It finds  
a _TOC_.
This toc links to a _Medium_, which belongs to exacly one _Release_ which  
belongs to exactly one _Album_. Since you set your preferences to "use  
standardized titles", Jack's tagging engine will use the title of that  
_Album_, not the title of the _Release_.
Now to the tracks. the _Medium_ is nothing but the tracklisting which owns  
a list of _Tracks_. Those tracks have titles (what is on the cover), but  
for each _Track_ Jack will look for the (exactly one) _Master_ that this  
track belongs to. It will use this _Master's_ title and not the one from  
the _Track_.

So you get exactly what you want. You were not even bothered to look at  
all the different releases that are in NGS-MB. The only case in which you  
would have to choose, would be if there were different releases to the  
same TOC. But even in this case, Jack could perform all the steps above  
and only present you a choice if the resulting 'standardized' albums would  
differ.

  (B) Say you bought a couple of files from an online music store. You want  
to tag them as 'standardized' as possible. You fire up Picard and feed it  
the files. Picard querries MB with a combined Text and PUID querry and  
gets set of _Fingerprints_. Ideally there is one _Master_ to each  
_Fingerprint_. Exceptions are real PUID collisions (which are yet unheard  
of), or entries which have not been 'standardized' enough, or wrong  
PUID-to-Master relationships ([*] we'll come back to this third point  
later).
Now Picard asks MB to find the _Medium_ which has the closest match to  
this set of _Masters_. This is a fuzzy search that goes via the _Track_  
entities. According to your preferences it will present you this match  
(and maybe some close alternatives) by using the 'stadardized' track and  
release titles from the corresponding _Album_ and _Masters_, which it got  
using the process described under (A); not from the corresponding  
_Release_ and _Tracks_.

Now suppose you are tagging against a *remaster*. In the worst case for  
you the titles of the _Masters_ might reflect this. You could then select  
an option "standardize even more" and Picard would look up the titles of  
the corresponding _Composition_ objects.

Again you got what you wanted with a minimum of hazzle. All the  
complicated structure between the _Album_ and the _Master_ (or even  
_Composition_) is used by algorithms, but not by you.

  (C) Did you note that I have left out the artist completely? This is  
because the relation between the _Artist_ and the _Release Artist_ is a  
bit more complicated. All relationships to the _artist_ have attributes  
(so technically speaking there need to be objects in between them in the  
graphic). These attributes specify how to compose a single artist for your  
tags from the multiple _Artists_ in the Database.

So, if you do not want your album attributed to "Bubb featuring the GREAT  
BlaBla" (as on the cover), Jack or Picard would issue another query to MB  
which would yield:
_Release Artist_ "Bubb featuring the GREAT BlaBla" has {primary} member  
_Artist_ "Blubb"
_Release Artist_ "Bubb featuring the GREAT BlaBla" has {featuring} member  
_Artist_ "Blabla"
 from which you can construct the tagging artist "Blubb (feat. Blabla)"  
using the default algorithm,
or "Blubb" using a 'standardizing' algorithm.

Or in the vertical 'album' Bamboo:
_Album_ "Zoink" is a {main} entry of the discography of "Blubb"
_Album_ "Zoink" is a {secondary} entry of the discography of "Blabla"
 from which you can construct the tagging artist "Blubb (feat. Blabla)"  
using the default algorithm,
or "Blubb" using a 'standardizing' algorithm.

Or in the horizontal 'song' bamboo:
_Composition_ "Zip zap zarap" was composed by _Artist_ "Bertram Blubb"
_Recording_ "Zip zap zarap" has {guitar} {primarily} performed by _Artist_  
"Blubb"
_Recording_ "Zip zap zarap" has {vocals} {secondarily} performed by  
_Artist_ "Blubb"
_Recording_ "Zip zap zarap" has {keyboards} {additionally} performed by  
_Artist_ "Bert"
 from which you can construct the tagging artists "Blubb (feat. Blabla)"  
using the default "Popular Music" algorithm,
or "Blubb" using a 'standardizing' "Popular Music" algorithm,
or "Bertram Blubb" using the "Classical Music" algorithm.



Are you still with me? :-)

It is our fault that we never provided such usage cases of Nadelnder  
Bambus after the summit. So it is no wonder that it was so abstract. My  
question is: Does this solve what you want MB to be good for?

I have not discussed the maintenance aspect at all, because this mail is  
already getting too long. The main thing to keep in mind here is that the  
UI will do the same queries between the vertical and horizontal bamboo all  
the time. Note that
(a) this is the reason why the relations *have to* be 1:n. This makes them  
fast compared to n:m relations.
(b) while the current UI presents you all relations in the current db  
schema, the UI for NGS will *use* these relations and present you with the  
aspect you want to see.



[*] Now back to the note above, and then I'll stop. :-) Above I wrote:
One pssible reason for there to be more than one _Master_ to each  
_Fingerprint_ are wrong PUID-to-Master relationships.

An example of such errors would be if the PUID of a remastered track would  
be related to the original _Master_ instead of the _Master_ representing  
the remaster. And as far as I remember that was the reason for the  
guideline we are discussing.

Of course currently the problem is not really visible and does not make a  
difference. But since PUIDs are no textual and easily verifiable data,  
these errors cannot be easily corrected. This is what I meant when I said  
that we are losing information. If you associate the master PUID and the  
remaster PUID to the same track (in the current schema). How will you ever  
be able to pull them apart again?

I realize that this is arguing with the future agains the present.
On the one hand, identical Masters are a nuisance *now*. They clutter up  
the album listing.
On the other hand, we also have PUIDs *now* and they are relatively  
unique. Merging tracks that *legitimately* have different PUIDs now,  
creates wrong information in the database that will be extremey hard to  
correct.
MB has grown out of the shoes of *only* being a tagging resource. Entering  
wrong information just for tagging is the wrong way to go.

I hope that I could convince you that NGS will be an even better tagging  
ressource than what we have now, and much more. I know we have a problem  
now, and it is not only related to remasters but also to box sets etc. We  
need an album grouping object, and we need it soon. From a completely  
unreleated mail I got a hint that Keschte might have this on his radar.  
That gives some hope...

Sorry for the long post. I hope it was helpful. If yes, then I will put it  
under NextGenerationSchema/UsageCase.

   DonRedman


--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[DonRedman]

On Mon, 03 Jul 2006 16:28:20 +0200, Chris Bransden wrote:

> i imagine most people would want the
> original release date tagged to their files rather than date of their
> particular product. if it's got the same tracklisting, there would be
> no benefit in using the later date (eg you're not likely to have 2
> products of the same tracklisting on yr pc).

NGS can do that. You just go up one level from the specific _Release_ you  
have at hand to the grouping _Album_. Then you look through all the  
_Releases_ that belong to this _Album_ and find the  one with the earliest  
release date. You tag your files with that.

Of course "you" is not a person but a computer. :-)

   DonRedman

--
Words that are written in CamelCase refer to WikiPages:
Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation  
around! :-)

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users

[teknojnky]

Some parts of this message have been removed. Learn more about Nabble's security policy.

 

It would be great if both the tagger and/or MIP Mixer supported analysis of CD's directly. I've even suggested this on the MIP forums for the mixer, but I could see the tagger also supporting it to provide a verified known PUID for a known disc ID. Here is where you would get validated PUID's for any particular disc release... Even once validated by disc ID's are available, it would be easier to clean up any mis-applied PUID's if desired.

 

It would also be great if picard had better support for multiple cd drives, as its a royal pain to continuously change the drive in the options when there are multiple drives available and the user is ripping/identifying multiple cd's at the same time.

 

One of my computers has 3 drives, a dvd-rom, a cd-rom, and a dvd burner. My media program of choice is Mediamonkey, with which I can rip from any number of drives simultaniously.

 

So you can imagine the pain when on a ripping spree of a stack of discs how annoying it might be trying to submit/confirm disc id's..

 

 

 

----- Original Message -----

From: "Don Redman" <donredman@...>

To: "General discussions about MusicBrainz" <musicbrainz-users@...>

Sent: Monday, July 03, 2006 1:36 PM

Subject: Re: [mb-users] ReleaseGroupsAlternative

 

> [*] Now back to the note above, and then I'll stop. :-) Above I wrote:

> One pssible reason for there to be more than one _Master_ to each 
> _Fingerprint_ are wrong PUID-to-Master relationships.
>
> An example of such errors would be if the PUID of a remastered track would 
> be related to the original _Master_ instead of the _Master_ representing 
> the remaster. And as far as I remember that was the reason for the 
> guideline we are discussing.
>
> Of course currently the problem is not really visible and does not make a 
> difference. But since PUIDs are no textual and easily verifiable data, 
> these errors cannot be easily corrected. This is what I meant when I said 
> that we are losing information. If you associate the master PUID and the 
> remaster PUID to the same track (in the current schema). How will you ever 
> be able to pull them apart again?
>
> I realize that this is arguing with the future agains the present.
> On the one hand, identical Masters are a nuisance *now*. They clutter up 
> the album listing.
> On the other hand, we also have PUIDs *now* and they are relatively 
> unique. Merging tracks that *legitimately* have different PUIDs now, 
> creates wrong information in the database that will be extremey hard to 
> correct.
> MB has grown out of the shoes of *only* being a tagging resource. Entering 
> wrong information just for tagging is the wrong way to go.
>
> I hope that I could convince you that NGS will be an even better tagging 
> ressource than what we have now, and much more. I know we have a problem 
> now, and it is not only related to remasters but also to box sets etc. We 
> need an album grouping object, and we need it soon. >From a completely 
> unreleated mail I got a hint that Keschte might have this on his radar. 
> That gives some hope...
>
> Sorry for the long post. I hope it was helpful. If yes, then I will put it 
> under NextGenerationSchema/UsageCase.
>
>   DonRedman

_______________________________________________
MusicBrainz-users mailing list
MusicBrainz-users@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-users