« Return to Thread: Clarification needed on remastered releases.
Re: ReleaseGroupsAlternative
by DonRedman
::
Rate this Message:
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
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
« Return to Thread: Clarification needed on remastered releases.
| Free embeddable forum powered by Nabble | Forum Help |
