#musicbrainz-devel

hawke_1: you mentioned DVD titles.

Ok, the one I remember has one song

But because it's a 20-min long song

ocharles: because many releases have these groupings, and I want to capture that data in the database. I'm not sure what more "why" you are looking for.

ocharles: because people want it :P

(the one I remembered is http://www.discogs.com/Nadja-Radiance-Of-Shadow... )

nikki: people want *something* but no one has managed to actually describe what "it" is

warp: actual use cases. right now, it only feels like data for data's sake, and ill defined at that

warp: Yes…?

hawke_1, http://www.discogs.com/Thee-Silver-Mt-Zion-Memo...

ocharles: the use cases are all in the examples in my wiki page.

(that was the other I had)

no, those are examples of things you want to group, I still haven't been entirely convinced why you want them, and why it's not something that a work hierarchy/set of works is sufficient

hawke_1: "if you consider DVD titles to be equivalent to sides." <-- I was just saying that DVDs can have actual sides, so titles are not sides. they are just titles.

I'm sure classical people can give you plenty of examples where grouping would come in handy on tracklists instead of "Foo: Bar: II. Blah: "WTF", Part I: I Don't Get This" or whatever it is they do now to stringify it :P

because examples 1, 3, 4 are all captured by works

ocharles: but works aren't tracklists...

ocharles: because some of the things I want to group are not works.

I know. which is why I haven't understand why this needs to be on tracklists :)

because right now the tracklists are ugly if you try and enter the data into them

ocharles: some of them are, and in those cases I would link the group as being a release of a work.

warp: They divide tracks into groups due to technical aspects of the medium, just as sides do. So using the same system to implement them makes sense.

nikki: but we can make use of works to solve that

hawke_1: oh yes, certainly.

I'm trying to determine why this is genuinily distinct data

ocharles: well, take the first example for the prodigy.

ocharles: but we don't have a way to give a work a title that's only used on the release

ocharles: to me that is merely a title given to a group of three tracks.

ocharles: that's hardly enough to call "the narcotic suite" a work

I would just simply disagree there, and I do feel they form a work

ocharles: but just prefixing each of the tracks with "The Narcotic Suite: " is also incorrect, that is not part of the track title.

I think it could be argued that a named set is exactly one of the things that a work is.

ocharles: is a group of [song / silence / hidden song] a work?

no, but i don't feel it forms any type of conceptual entity either

are chapters of books works?

I consider it to be [work] [hidden song]

warp: those are 2 works, that just happen to appear on the same part of my media

well, this is musicbrainz, not bookbrainz

warp: http://musicbrainz.org/release/3cad554e-3c5a-48... ?

nikki: if works have to be musical then, chapters/books/any of that doesn't belong in works at all

ocharles: the conceptual entity I need for those two works (and three recordings IMO) is the audio file or cd track. the entity which has an audio fingerprint.

I would say that reading outloud a chapter of a book or a poem can certainly constitute as performing it

warp: which you already have, a recording

ocharles: imo [song / silence / hidden song] are three seperate recordings

ocharles: I don't believe in this 1:1 mapping of recording to audio file / cd track.

warp: I’d even say two, unless it’s silence-as-art.

warp: ok, I don't mind that, but again, what's the need for a separate entity?

if you want them separate, we just need non-integer track numbers and have x.1 and x.2

ocharles: http://musicbrainz.org/release/95ba0e5a-99fd-44... <-- or that. thatshould be 9 recordings.

+1

ocharles: if we split up the recordings, we need some other entity to represent the recordings as they exist together in an audio file or on a cd track.

why though? you just said you don't want a mapping to cds/mp3s

But that's what the users want :p

ocharles: I don't want a mapping of _recordings_ to cds/mp3s.

ocharles: because people still want to use mb for ripping and tagging

Being able to have both levels

For different uses

ocharles: I do want a mapping of some kind to cds/mp3s/fingerprints.

Just not it to be the *only* mapping

so why can't we have this with work relationships that are time indexed?

it will need the ability to reference a work via a different name, "work name credits", but we already have that problem with artists

ocharles: how can a work group several recordings together to form an entity to which a fingerprint can be linked?

Because relationships in http://musicbrainz.org/release/95ba0e5a-99fd-44... most likely apply to just one of the songs

(some of them already)

warp: other way round. A recording has the finger print, and has 9 works, each of which are time indexed

s/already/at least/

ocharles: then you still have duplicate recordings which shouldn't be duplicate.

simon just showed me an example of a cd where the tracklist says "side a" followed by 7 tracks and "side b" followed by 5 tracks

those aren't works either

that's just someone wishing they still had vinyl :P

nikki: but it is solved by non-integer track indexes, A1 A2 A3 and B1 B2

no

ocharles: no

the tracks are numbed 1 to 12

no.

ocharles: it's _name_ given to a group of tracks.

the A1 A2 B3 B4

but that's not right :/

they're not real sides

especially if we interpret A = first physical side

it's just a name

so what use is it then?

what are we trying to do with this name?

capture it

we're trying to represent what's on the release without inventing stuff :P

so that I may know it when I play the music :)

I understand there is a group, I'm just intentionally playing devils advocate because introducing a new namespaces of MBIDs should be very well considered

warp: if you think if it as something that stands alone, then again, I would argue that sounds like you think of it as a work

i'm not sure why you'd only want to listen to side a and not side b though :)

it's the same as why do we have artist credits?

ocharles: so, we have two different problems.

because we want to capture how it's actually credited

ocharles: groups of tracks which are works could possibly be represented with just works.

nikki: artist credits are fine, they aren't addressable

ocharles: we perhaps don't need anything new there.

You could get this by either having: non-integer track indexes, or having a "group" field for tracks

IMO it could be done with recordings alone.

and just more complex/interesting linking of recordings/tracks

ocharles: ok, a group field for tracks is an interisting new suggestion.

(well, plus non-addressable grouping)

ocharles: so you'd just add a group_id column to track? what would the group table look like?

warp: no ID, just text

ocharles: what if the track is part of multiple groups?

and voila, we now have something that wasn't in your original plan :)

ocharles: yes it is :)

where?

test is broken atm?

DBD::Pg::st execute failed: no connection to the server

multiple groups would imply overlapping track groups, which I don't see in your examples

luks: i'll kick it

ocharles: the ring example needs it to represent "Scene 1", "Scene 2", etc.. within "Act 1"

which sounds to me like the solved problem of works... but I think we're just going round in circles there

And also, the examples mention sides which would often overlap with other groups

ocharles: ah, right.

luks: done. I forgot to restart the server after rebuilding postgres

ocharles: you're saying that I'm trying to solve two problems with a single complicated solution.

mmm, I'm not sure I'm saying that

I'm saying you're introducing data duplication

ocharles: whereas if we solve one of them with works instead, we can solve the other with for example merely a group column on the track table.

warp: Here’s one of the releases I was thinking of btw: http://musicbrainz.org/release/c4dc6c94-0679-4b...

that could definitely use track grouping into songs or what we normally think of as recordings

ocharles: to me it's just as much duplication as the duplication inherent in track title <-> recording title <-> work title.

i.e. track 5–12 should be one MB-recording

warp: that shouldn't be reason for you to design more duplication in though

ocharles: if "The Narcotic Suite" is a work, the track grouping with "The Narcotic Suite" name is a work as it appears on a release (perhaps the title of the group is translated on the release, etc..)

ocharles: so, work credits! :)

I'm going to the pub in 5 minutes

:P

np

thanks for playing devil's advocate

:)

have a good weekend sir!

you too!

I think the gf + kids are going somewhere tomorrow. I may pop in for a bit work. not sure yet.

warp: It’d be neat, but infeasible, to define/upgrade the ripper-interaction protocol to tell rippers how to handle the CD.

hawke_1, make a MB ripper :p

e.g. 'rip tracks 1-4 as one file, 5-12 as another'

hawke_1: we don't care about such practicalities!

first we get the data model right. then we figure out how to implement it in the tagger without breaking anything.

What’s your take on that particular release? How should it be modelled?

I'm not sure. that's sort of the other way around

what are the track divisions trying to indicate, is there more information about each of the parts we could capture if we had the booklet?

I’m guessing not; I have two guesses as to the reason for the track separation

1: to make it a giant pain to copy/rip

2: because it accompanies a textbook, so they want the listener to be able to seek to particular segments of the music, as the text describes some aspect of it

it seems to be a teaching aid, so the intent may be to make it easier to give instructions (in the textbook) to jump to specific parts