#musicbrainz

let's say we can store multi-disc albums in the DB. does somebody have an example where each disc is credited to a different artist?

I just saw some new releases go in like that.

sonium: good luck tomorrow

I haven't found much info on them so they may not be legit.

ehm

luks: http://musicbrainz.org/release/d7cd863e-be37-4c...

released together with http://musicbrainz.org/release/e9bd8194-b83e-4c...

I guess the question is if we want to track disc artists (like now), release artists or both

don't know. in my example it would surely be appropriate to credit the release as a whole to candlemass, but have a different disc artist for the bonus disc

How would it change for tracking release artists?

I'd like to see a way to link them together through an AR or something, but beyond that I don't see much to change.

I wanted to treat discs like anonymous objects - no title, no credits, just a list of tracks - and then releases which have titles and credited artists

I could see how that would work. I think I would prefer it that way (assuming I'm visualizing this the same way you're thinking).

luks: what about multi-disc compilations or compilations of re-releases?

outsidecontext: how it that different?

the release would be credited to multiple artists and such, but you could not tell which credit applies to which disc

well, is that important?

yes, i think so

you can't get a separate disc in real world anyway (ignoring non-official ways of getting CDs :))

The tracks would still have their specific credited artist right?

of course

So both discs (from above) would fall under Candlemass but all the tracks on the bonus disc would have Abstrakt Algebra as the artist.

maybe using release artists like "Candlemess / Abstrakt Algebra" would be an acceptable workaround

the Abstrakt Algebra disc would be then included in two releases, one by Abstrakt Algebry, one by Candlemess / Abstrakt Algebra

no, guess in this case it would be fine with a release artist candlemass but with all tracks of the second disc credited to abstract algebra

by " / " I mean the discogs style of combining artists

hm

another problem are those 100 CD classical box sets :(

sorry, got a phone call

the only bit of information that would be lost would be that disc 2 is a complete "abstract algebra" release, it was intented as a full album but never got released

i wonder if there are any release level ARs that would make sense for a single disc

mastering is one

damn this is complicated

remember that "fuzzy AR" discussion :)

and people complain MB is already too confusing

I can't imagine a simple way to enter this data

me neither. i really like your concept of a multiple disc release from that point of view

I think it can be done but it would be a bit different from the way things are done now. That could be good and bad...

but people will come up with valid cases demonstrating that it can be inaccurate

it's mb, no matter what you propose, someone will eventually find something that doesn't work :P

Kerensky97: I'm thinking of changing everything

There are always cases like that.

that for sure :)

I don't mind completely different way of editing

but I can't think of such way

did you see my pmsg earlier, luks? I never know if people actually receive them

nikki: yes, but was busy, sorry

that's ok

Yeah. When I see it drawn out it makes sense. I think when people see how releases, artists, and songs interact it starts to make sense.

luks: how would you have solved the UI issues with your data concept?

outsidecontext: I don't know

just thinking of the discogs way for now

but I think that's far from ideal

would you still have catalogue numbers for the discs?

it would be nice for display

no, only for releases

:(

japanese releases often give each disc a catalogue number though

luks: what about a releases in releases concept?

you can add an release without tracks but other releases instead

I even have a release which has different EAN for the set and different EANs for each disc :(

outsidecontext: that's nice in theory, but I'm starting to think it wouldn't work

from UI point of view

cat# + EAN could just be made a relationship to the disc. Kind of like moving it down from the release level to the disc level.

it would solve the fact that a disc can be a separate release too

like this release *pulls one off the top of her pile* has EPCE-5559~60 on the spine, EPCE-5559 on the first disc and EPCE-5560 on the second disc

outsidecontext: but disc CAN'T be a separate release

there might be a different release with only that disc

but discs are not releases on their own

brb

I don't think any music DB will ever cover all these cases

As long as it covers the majority or most common issues.

heh http://allmusic.com/cg/amg.dll?p=amg&sql=10...

re

niklas__: ping!

hi

hi

do you have an update sql file that takes a current db and creates your new tables?

no :( I'll have a look at that

its mostly a cut and paste job.

the idea is that scripts from this dir will be run when we upgrade a server.

ah. but do the discography branch need one? as it does not alter any existing table

do not

its adds new tables.

the script should contain all the changes made to the DB to get it ready for your new code

ah ok

please create that file and check it in. ping me when you're done so I can check it out and run your code

alright sure

thx

so I should create all tables and indexes in there?

yes

ok. and collection_info tuples for each user... I think that also should be created?

no.

don't create anything until a user wishes to start a collection.

aha ok

luks: treating discs as dumb objects contained in releases might be the data structure most close to the reality

outsidecontext: yeah, but it's wrong anyway

they have subtitles, which we have to store

we might want to store matrix numbers

also, they still have attached discids, so they need to be visible also separately

but I think they should not have titles or artist credits

yes, that for sure. but what about a release page showing mainly the tracks grouped by disc, and analog to the track page separate disc pages

that's the idea

i think the basic data structure would be correct, and discs could still be extended with separate attributes or ARs if neccesary

ruaok: should updates for the raw database go under /admin/sql/updates/?

hmmm

(btw, the reason for this discussion is that I'm trying to make "complete NGS" in SQL and do some primitive front end for it)

or should I create a dir /admin/sql/vertical/rawdata/updates/ or similar?

why wouldn't discs have titles?

drsaunde: Regarding our discussion on MB. I do not think there is a Vaulternative release from that album. Me, and a lot of friends in both Europe and the US, have ordered it from the US on the site you posted and everyone have got a Zappa Records release.

nikki: because they don't in reality, do they?

ok, so main focus is on data structure.

I thought quite a few did

why not allow artist ARs and such for discs then?

niklas__: yes, they should. however, make sure that you put changes to the READWRITE db into a separate file then from the RAWDATA db.

that is if you make changes to READWRITE.

nikki: aren't those subtitles then?

and note at the top of the page which DB the script should be run against.

outsidecontext: I don't know, it will probably end up that way

"complete NGS" -- what do you mean by that?

the ideal DB schema for MB

ruaok: ok. but Im not supposed to touch the READWRITE db right?

how will that differ from the schema diagram that you created post summit 8 ?

luks: i could still imageine the interface relatively easy. for the simple cases just enter releases like today creating a disc in the backrgound, for more complex cases you could edit the single discs

ruaok: I don't know yet

there is no rule for you not touching it.

maybe I'm confused, but if the back cover says CD 1: Foo and CD 2: Bar, I'd call them the disc titles not subtitles of the main title, 'cause the main title can already have subtitles

if you have reason to, then go for it. :)

ruaok: but there are some cases where it doesn't work well

ah, fixing more edge cases, then?

mostly

and seeing how it works on actual data

that's what I got grilled on mostly at summit 9.

ruaok: ok, but everything in the data model we did should be in rawdata?

how compicated are queries to get them, etc.