Clarification needed on remastered releases.

[Gecks]

On 03/07/06, Don Redman <donredman@...> wrote:
> 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.

don, you have a way of summarising these complex ideas very well - i
think you should start from page 1 of the wiki and give me some nice
examples of everything :)

> <snip stuff on how NGS tags tracknames>

all sounds very good!

a few questions, though:
1) will there be seperate 'albums' to the extent we have them now?
because as far as I can see, you're going to want new 'albums' for all
tracklist variations, despite them still being part of the same
meta-collection of releases (if you see what I mean).  eg, if there
was an album that was released in both 9 and 10 track configurations
(with the latter being what i own, yet only being sold as part of a
boxset), i would want to tag mine agains the right one, yet still be
using the 'standardized' set of titles (ie no boxset info).
2) will we start using different style guidelines for 'releases',
since there seems to be less of a reason to 'correct' titles and so
forth if a standardised set already exists.

>   (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.

i like this, though this still requires a 'featuring' flag to be on
ARs. an artist can guest on a track, yet not 'feature' (eg
http://musicbrainz.org/showmod.html?modid=5117640 )

> <snip more feat. stuff>
>
> Are you still with me? :-)

thik so :)

> 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 think so :) though i would say i don't think any of this is good
arguments for what seems to be the practice of retaining multiple
releases of the same 'album' under our current system "because NGS is
coming". i believe our current system is very much 'album oriented'
and we're much better not pre-empting NGS.

> <snip>
>
> [*] 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.

well, i would say it's almost too late to be concerned with it. we're
going to have to re-assign CD-IDs, release dates, PUIDs and the like,
so i think listing things differently now isn't going to cut-down the
amount of work needed once NGS gets here.

i don't know exactly how PUIDs work, but even TRMs may be generated
differently across different pressings of the same album (eg different
country releases) as the timing can be slightly different, or when the
rip is from different formats (eg vinyl vs CD vs MP3 vs ...), so i
think masters vs remasters is only one of many problems we're going to
face moving our data to NGS.

> 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...

this would be essentially a header that all the releases belonging to
that 'album' went under? i think this would be good, and it would mean
one of them could be the 'standardised' one.

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

helpful to me, but i'm not sure if i'm representative :) thanks, Don!

chris

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

[Sami Sundell]

On Mon, Jul 03, 2006 at 08:36:37PM +0200, Don Redman wrote:

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

... and I'll skip the specifics and answer to that :P

> 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

First of all, thanks for those use cases, they clarify things. Which
sort of begs the question, why aren't there such use cases in Wiki :P
There's example section in the object model page, but it's actually
section of potentially problematic entries, not solutions on how to deal
with those.

Another thing is that your use cases miss one, very important detail:
where do we get the information?

NGS has lots of abstract objects. Do we have a plan for creating such a
system and user interface that those objects actually get created? Do we
have the resources to implement that? Do we have enough active users?

In Astérix & Obélix: Mission Cléopâtre (on TV right now :P) Numerobis
builds a house that has a door close to the ceiling, "just in case you
want to add a second floor later". Are we sure we're not doing the same
thing?

--
 Sami Sundell
 sami.sundell@...

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

[DonRedman]

On Tue, 04 Jul 2006 10:44:14 +0200, Chris Bransden wrote:

>> <snip stuff on how NGS tags tracknames>
>
> all sounds very good!
>
> a few questions, though:
> 1) will there be seperate 'albums' to the extent we have them now?
> because as far as I can see, you're going to want new 'albums' for all
> tracklist variations, despite them still being part of the same
> meta-collection of releases (if you see what I mean).  eg, if there
> was an album that was released in both 9 and 10 track configurations
> (with the latter being what i own, yet only being sold as part of a
> boxset), i would want to tag mine agains the right one, yet still be
> using the 'standardized' set of titles (ie no boxset info).

I think, you are not using ObjectModel terminology.

In ObjectModel terminology there is exactly one Album to many Releases  
which may have different track counts. You can use the Album's title or  
the specific Release's title, depending on your preferences.
Similarily for each track you can use either the Tack's title, or the  
Master's title, or even the Composition's title.

So there will be even more different _Releases_ than we have now, but very  
few _Albums_.
A Box set will be *one* Album with *one Release per set* with multiple  
Medias. There will be a lot of duplication, but it will not matter to  
people who use 'standardized' titles (because those are the same for the  
duplicated discs).

> 2) will we start using different style guidelines for 'releases',
> since there seems to be less of a reason to 'correct' titles and so
> forth if a standardised set already exists.

Maybe. in DonRedmans Model of Organizational Development (TM) ;-) [*] the  
major rule for such a massive shift is: "Rules Follow Practice". NGS will  
be done in very small steps. Each step will change the pratice of  
contributors to an extent that it will point out the limitations of the  
current guidelines. Then we will have endless discussions ;-) and then  
refine the Guidelines.

>>   (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.

<snipped the examples>

> i like this, though this still requires a 'featuring' flag to be on
> ARs. an artist can guest on a track, yet not 'feature' (eg
> http://musicbrainz.org/showmod.html?modid=5117640 )

Yes! And there is a big difference between {featureing}, wich is on the  
"What it is called" side of the AspectModel and {primary} which is on the  
"What it is" side of the AspectModel. An artist can very well be primary  
but not featured on the cover or featured on the cover but only of  
tertiary importance.

>> <snip more feat. stuff>
>>
>> Are you still with me? :-)
>
> thik so :)

Thanks for following along :-)

>> <snip>

>> 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?

<snip>

> well, i would say it's almost too late to be concerned with it. we're
> going to have to re-assign CD-IDs, release dates, PUIDs and the like,
> so i think listing things differently now isn't going to cut-down the
> amount of work needed once NGS gets here.

Hmm, I fear you are right. IIRC the guidedine to split Masters came into  
being under Tarragon with exactly the purpose to prevent this problem.
Apparently it did not make any practical sense so people ignored the  
guideline. Now we ahve the problem anyway. :-(

   DonRedman

----
[*] Actually, I am not joking at all. I am currently writing a paper about  
this with a coleague of mine. I just hope we find a publisher...

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

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

[DonRedman]

On Tue, 04 Jul 2006 18:21:17 +0200, Sami Sundell wrote:

> On Mon, Jul 03, 2006 at 08:36:37PM +0200, Don Redman wrote:
>
>> Uff, this post got really long, so I'll give a short summary:
>
> ... and I'll skip the specifics and answer to that :P
>
>> 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
>
> First of all, thanks for those use cases, they clarify things. Which
> sort of begs the question, why aren't there such use cases in Wiki :P
> There's example section in the object model page, but it's actually
> section of potentially problematic entries, not solutions on how to deal
> with those.

Why? Because writing docs is a lot of work.
The examples were gathered specifically to be problematic (we wanted to  
make a decision what we want to deal with and what not, so we needed  
concrete examples).

> NGS has lots of abstract objects. Do we have a plan for creating such a
> system and user interface that those objects actually get created? Do we
> have the resources to implement that? Do we have enough active users?

The reply is here:  
<http://blog.musicbrainz.org/archives/2006/05/future_directio.html>
So: No we do not have enough developers.

> In Astérix & Obélix: Mission Cléopâtre (on TV right now :P) Numerobis
> builds a house that has a door close to the ceiling, "just in case you
> want to add a second floor later". Are we sure we're not doing the same
> thing?

:-) Not sure, but I really like the metaphor.

I think the problem is rather that we *know* that we need a second floor  
(and a third one, too). We have already made plans for them. Actually we  
have put far too much energy in the plans -- a lot of things will have to  
look very differently in the final building. We have put so much energy in  
them that for a while we have come to take the plans for the building (or  
with Bateson: "The map is not the territory").

However, we have a similar problem to Numerobis (I only know the comic),  
that we do not have enough workers to finish the building.

So we have this door close to the ceiling. That alone would not be an  
issue. The problem is that we both know that we will use it later (we want  
to build that second floor), and on the other hand it is a PITA to have to  
*use* that door now.
The question is: How much work will it be to knock that wall down later?  
How much harm will be done if people use the other door for a year?  
(remember that they carry PUID's into the building and put them into the  
wrong place).

So, yes, that's the question.

What I cannot answer is: Does Keschte have plans to build a temporary  
scaffolding? Will that ease the pain to use that door? How long would it  
take to build it?

   DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

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

[Gecks]

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

> On Tue, 04 Jul 2006 10:44:14 +0200, Chris Bransden wrote:
>
> >> <snip stuff on how NGS tags tracknames>
> >
> > all sounds very good!
> >
> > a few questions, though:
> > 1) will there be seperate 'albums' to the extent we have them now?
> > because as far as I can see, you're going to want new 'albums' for all
> > tracklist variations, despite them still being part of the same
> > meta-collection of releases (if you see what I mean).  eg, if there
> > was an album that was released in both 9 and 10 track configurations
> > (with the latter being what i own, yet only being sold as part of a
> > boxset), i would want to tag mine agains the right one, yet still be
> > using the 'standardized' set of titles (ie no boxset info).
>
> I think, you are not using ObjectModel terminology.
>
> In ObjectModel terminology there is exactly one Album to many Releases
> which may have different track counts. You can use the Album's title or
> the specific Release's title, depending on your preferences.
> Similarily for each track you can use either the Tack's title, or the
> Master's title, or even the Composition's title.

i am actually using the terminology correctly, but my understanding of
it still has some ways to go :) here's how i understand my usecase
would go:

1) i rip CD to mp3, i fire up tagging utility, and hit lookup with my
CD or clustered album
2) tagger works out what specific 'release' i have from
CD-ID/PUID/lucene search (or perhaps the releases are ambigious so it
can only go as far as telling me what 'album' this is)
3) i hit the "tag" button!
- i have my preferences as "use album title" (ie, grouping object for
albums) so it uses this, rather than the release title (which might be
using that HORRIBLE BoxSetNameStyle :P)
- i have my preferences as "use master titles" (ie, grouping object
for tracks) so it uses these rather than the release-specific track
titlee
- and all that (feat. x) stuff...
4) done!

so what i understand as the 'album' and 'standardised tracklisting' is
actually something that is created on the fly from the DB
relationships. there's no need to have different 'albums' for all
tracklist variants (ie, what we do at the moment), as the you will be
able to generate this by using the 'masters' of all tracks on the
'release' in question.

> So there will be even more different _Releases_ than we have now, but very
> few _Albums_.
> A Box set will be *one* Album with *one Release per set* with multiple
> Medias. There will be a lot of duplication, but it will not matter to
> people who use 'standardized' titles (because those are the same for the
> duplicated discs).

not sure if i'm saying the same thing, but to me a box set will be
many 'albums'. say a 5xCD boxset compiling 5 studio albums - that is 5
'releases' (each belonging to an album), which will then be grouped
together via ReleaseGroups, but that is something different than the
'album' concept, right?

> <snipped some stuff that is clear to me now :)>

> > well, i would say it's almost too late to be concerned with it. we're
> > going to have to re-assign CD-IDs, release dates, PUIDs and the like,
> > so i think listing things differently now isn't going to cut-down the
> > amount of work needed once NGS gets here.
>
> Hmm, I fear you are right. IIRC the guidedine to split Masters came into
> being under Tarragon with exactly the purpose to prevent this problem.
> Apparently it did not make any practical sense so people ignored the
> guideline. Now we ahve the problem anyway. :-(

yep, indeed i didn't know such a guideline existed!

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

[DonRedman]

On Tue, 04 Jul 2006 20:25:00 +0200, Chris Bransden wrote:

> i am actually using the terminology correctly, but my understanding of
> it still has some ways to go :) here's how i understand my usecase
> would go:
>
> 1) i rip CD to mp3, i fire up tagging utility, and hit lookup with my
> CD or clustered album
> 2) tagger works out what specific 'release' i have from
> CD-ID/PUID/lucene search (or perhaps the releases are ambigious so it
> can only go as far as telling me what 'album' this is)
> 3) i hit the "tag" button!
> - i have my preferences as "use album title" (ie, grouping object for
> albums) so it uses this, rather than the release title (which might be
> using that HORRIBLE BoxSetNameStyle :P)
> - i have my preferences as "use master titles" (ie, grouping object
> for tracks) so it uses these rather than the release-specific track
> titlee
> - and all that (feat. x) stuff...
> 4) done!
>
> so what i understand as the 'album' and 'standardised tracklisting' is
> actually something that is created on the fly from the DB
> relationships. there's no need to have different 'albums' for all
> tracklist variants (ie, what we do at the moment), as the you will be
> able to generate this by using the 'masters' of all tracks on the
> 'release' in question.

Yes, this is correct to the spot.

>> A Box set will be *one* Album with *one Release per set* with multiple
>> Medias. There will be a lot of duplication, but it will not matter to
>> people who use 'standardized' titles (because those are the same for the
>> duplicated discs).
>
> not sure if i'm saying the same thing, but to me a box set will be
> many 'albums'. say a 5xCD boxset compiling 5 studio albums - that is 5
> 'releases' (each belonging to an album), which will then be grouped
> together via ReleaseGroups, but that is something different than the
> 'album' concept, right?

ReleaseGroups is compeletely different from  NextGenerationSchema. It came  
long before and many ideas of it got worked into NGS. What you describe is  
a different possibility of handling box sets with NGS.
I cannot tell you the guidelines now (see Don's model of Organizational  
Development :-) ), but NGS will surely have different fields for volumes  
and disc numbers. The questin is in which entity to store them. But from  
what I understand your method would not work as well (for all the  
algorythms taht use the data) as the one we found on the summit. That one  
sais: A Release is what you can buy in one piece: A medium is a thing that  
holds a trackset (e.g. each side of an LP would be a different medium,  
both belonging to the release that represents the thing you can buy).

But Robert has established that NGS, as it is written down in the wiki, is  
just a conceptual stepping stone. So things may change one the devs start  
to implement parts of it.

>> <snipped some stuff that is clear to me now :)>
>
>> > well, i would say it's almost too late to be concerned with it. we're
>> > going to have to re-assign CD-IDs, release dates, PUIDs and the like,
>> > so i think listing things differently now isn't going to cut-down the
>> > amount of work needed once NGS gets here.
>>
>> Hmm, I fear you are right. IIRC the guidedine to split Masters came into
>> being under Tarragon with exactly the purpose to prevent this problem.
>> Apparently it did not make any practical sense so people ignored the
>> guideline. Now we ahve the problem anyway. :-(
>
> yep, indeed i didn't know such a guideline existed!

I am off for a while, but I think this should be raised on the  
StyleMailingList. We need a decision what to do with masters now, and  
after this debate here the one on mb-style can hopefully be less  
tangential :-)


   DonRedman

--
Words that are written in CamelCase refer to WikiDocs,
the MusicBrainz documentation system.
Go to http://musicbrainz.org/doc/<SomeTerm>
(you might need to transform the term to singular)

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

[Sami Sundell]

On Tue, Jul 04, 2006 at 07:24:32PM +0200, Don Redman wrote:

> >First of all, thanks for those use cases, they clarify things. Which
> >sort of begs the question, why aren't there such use cases in Wiki :P
> Why? Because writing docs is a lot of work.

Believe me, I know 8) It's just that the NGS pops up quite often in
discussions and in Wiki.

> We have already made plans for them. Actually we  have put far too
> much energy in the plans -- a lot of things will have to  look very
> differently in the final building. We have put so much energy in  them
> that for a while we have come to take the plans for the building (or
> with Bateson: "The map is not the territory").

Yeah. Future proofing has the problem that there's no end to it. 8)

I believe the best way to get something done is to start doing it.
Planning is essential, but a plan will anyway require adjustments when
it gets implemented.

I'm not trying advise anyone, I'm just interested in the situation of
the future project. 8)

--
 Sami Sundell
 ssundell@...

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