Re: [mb-style] RFC: STYLE-262, Place-URL has OSM at
Sheamus Patt wrote: On 10/21/2013 10:54 AM, Alastair Porter wrote: http://tickets.musicbrainz.org/browse/STYLE-262 RFC expires October 28 Proposing a new URL relationship to link a Place to its details on openstreetmap. Hopefully pretty straightforward. If you can locate it on OpenStreetMap, then you know it's GPS co-ordinates which can be put into MB, And, if you have the GPS co-ordinates, you can easily construct the URL. E.g. http://www.openstreetmap.org?mlat=43.630704mlon= -79.415448 http://www.openstreetmap.org?mlat=43.630704mlon=%20-79.415448 (locates Ontario Place, just an arbitrary place). So, why go through the trouble of adding URLs to all of the various places with specific locations, when we could just put a (locate this place) button into the UI which will take you there using the GPS co-ordinates? As Ian pointed out early on this should probably not be used for plain coordinate links but for links to entities in OSM, like ways and relationships. Which I would avoid too since they're not stable enough - OSM entities are mostly graphical entities with no proper semantics and it can happen easily enough that you edit a way in OSM and it ends up representing something entirely different. Or you delete it and replace it with another way. Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Locations and the upcoming schema change
Ian McEwen wrote: Is there a place in the new model (start location, end location, lived/worked ARs) we can move the current artist country field reasonably? I'd think that in almost all cases migrating the current field to a lived in relationship for people would be correct. Whatever country Händel is set to, it will always be true that he has lived there for however short a span of time. So I would definitely copy the country field values to such relationships in either case. Not sure what the equivalent would be for groups, maybe was based in. worked in for people wouldn't necessarily be true. There might be *some* exceptions where someone lives in one country but works in another and their country field has been set to the country they work in, in which case lived in would be wrong but that should be a tolerable number. The question is just if this should be the only place that the data should be migrated to. If in most cases for people it has been used as the birth country then we'd be losing data if we didn't also migrate the values to a birth area field. How many artists have that field set anyway? Would a report work that suggests that people copy this to the birth area field after a quick check? People move between countries, bands not so often. Unless they're mostly built around one person who moves to another country or if they become more internationalised. But that should also be a tolerable number of exceptions so I'd say for groups the foundation area field could be automatically filled from the current country field. Lastly, a general remark for future development: There are many kinds of events we could capture, many date fields and place fields and ARs we could add. But I wouldn't want this to turn into BiographyBrainz so we should restrain ourselves here. We don't need to capture where and when someone married or was baptised or spent their holidays. :-) Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] pre-RFC: new work types
Rachel Dwight wrote: It irks me to no end to see blank works. I've been cleaning up a lot of Hello! Project songs recently and it angers me that they can all be safely called Songs (as the artists rarely ever venture out of pop music) but other users deliberately chose to leave them blank. It's pure laziness. I /have/ left a few works unmarked, namely because I had no clue what they were. Why does it have to be laziness? With absolutely no documentation about what these work types mean and no guidelines when to use what it might just be uncertainty, amongst many other things. After all the field is not mandatory. I don't set it most of the time because I have absolutely no idea what it's supposed to be. Is a 30 minute rock opera a song? Is a 7 minute techno track a song? And I certainly have no idea how to classify most of the progressive rock I listen to and I wouldn't know where to draw the line for the more song-like stuff in that and I hate being inconsistent so I just leave it. If someone wants to figure it out they can still set it. There's no harm done in me leaving it empty. And there's really not much gained in me setting it, especially if it turns out to be wrong (by some definition to be decided on). So please don't go around calling people lazy, that's not very nice. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Chinese releases
Hi, Welcome to MusicBrainz and glad to hear about your future contributions! :-) You can propose new instruments on this page: http://wiki.musicbrainz.org/Instrument_Tree/Requests I suggest that you propose missing ones there and for changes in the names of existing ones or the structure of the tree it would probably make sense if you'd compile a list of proposed changes and post it here. Regards, Simon CARO REPETTO, RAFAEL wrote: Hello everyone, my name is Rafael Caro, and just joined CompMusic (http://compmusic.upf.edu/ http://compmusic.upf.edu/) to work with Chinese traditional music, specially Beijing opera. We are going to upload a huge collection of CDs and VCDs of Beijing opera to MB, and have some questions about the style of Chinese releases, one addressed to everyone, and two mainly for Chinese speakers. 1. The material we are working with comes from China, so they are released in Chinese. However, we want to have, together with the Chinese original data (in hanzi), the transliterated version of all them in pinyin (not the translated one, since there are no official translations). We've seen that the option now is to relate the release in Chinese to a transliterated pseudo-official release. This method, however, creates to releases stored separately (though liked) with different IDs. Could it be some other method to add transliterations of titles and track lists to a release in Chinese characters? 2. For the transliteration of titles and tracks, and since there is no official consensus about it, we are planning to transliterate every single hanzi separately: 音乐 = yīn yuè, and not yīnyuè. As for capitals in titles and tracks, we think that only first syllables in the phrase, and those for proper names for people and places should be in capitals. 3. There are some Chinese traditional music instruments, basic for Beijing Opera, that doesn't appear in the Instrument Tree, like 板鼓, or that appear with an inconsistent format, like jing hú, èrhú, zhonghu, or Moon lute. We suggest to establish a consistent format for all the Chinese traditional instruments: always in pinyin (avoid translations!), written together, and without tone marks: jinghu, erhu, zhonghu, yueqin. Translations, tone marks and further information can be added in the description of the instrument. I hope to read your comments and suggestions. Bests, Rafael Caro. -- Rafael Caro Repetto CompMusic, Music Technology Group Universitat Pompeu Fabra http://compmusic.upf.edu/ http://compmusic.upf.edu/ ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-151: edit of relationship type
Nicolás Tamargo de Eguren wrote: I keep finding shortened edits and extracts of classical recordings and I have no way of linking them, so I'm going to send a proposal for this. It's pretty much the same that was discussed (but never specifically RFC'd) a few months ago by Salutaurs, except that I've removed digitalisations from the explicitly covered bits since there's no agreement on whether different transfers should or shouldn't be new recordings and that's part of a much bigger discussion I don't want to enter now :) This is on the wiki at http://wiki.musicbrainz.org/User:Reosarevok/Edit_Relationship_Type and in Jira at http://tickets.musicbrainz.org/browse/STYLE-151 Expected RFV date is Jan 10. +1 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add inlay to the album art types
Maurits Meulenbelt wrote: Hi, I came across this ( http://tickets.musicbrainz.org/browse/CAA-11 ) ticket by Philip Jägenstedt to add the inlay (the inside of the back image in a jewel case, behind the tray with the cd) to the list of possible cover art types. It's marked as RFC required, but an RFC doesn't seem to be created for it yet. Philip isn't sure about the term inlay, but that's also the name I know it as. The Wikipedia article ( http://en.wikipedia.org/wiki/Jewel_case#Jewel_case ) doesn't give it a name though. Though inlays are quite common, they don't often appear as scans on the internet. Still, they do occur ( http://coverartarchive.org/release/3fe27b61-d30f-46b3-bbca-36c6844a6f62/1153483022.jpg ), so it would be nice to have a type for it. Any thoughts? +1 I've added a couple. And I'm sure I've seen them a lot of times on coverparadies.to, also under that name. Don't they also use the term in those programs where you can design and print your own cover art for burnt CDs (or downloaded cover art)? Maybe someone has something like that installed and can have a look. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC STYLE-121
Alex Mauer wrote: The guideline may be found here: http://wiki.musicbrainz.org/User:Hawke/Proposal/Track_numbering Can you describe # with number sign please? Pound sign is ambiguous. See also http://en.wikipedia.org/wiki/Number_sign ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Work type for movements?
pabouk wrote: Rupert Swarbrick wrote pabouklt;pabouk@gt; writes: ... I would like to start the process of adding work types for work parts (like movement, overture). As I am very new in the forum do you think it is appropriate for me to start the process? Eugh. In my opinion, something like movement shouldn't be a work type. What does movemnt mean? Well, probably something like part of a larger work. I think we've already got that covered in our data model! I agree that a movement is not a work but in MB we store movements into work entities! Rupert did not say that a movement is not a work, he said it shouldn't be a work *type*. To me a part of a work is still a work so I see nothing wrong with storing parts as work entities. Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Percussion and string instruments
Jim DeLaHunt wrote: Should these terms be used in performance Relationships at all, or should they only be labels for a category? And in fact, how often are they used in performance Relationships? Nikki did some queries for me: percussion instruments: 13,528 relationships (7th most common instrument), string instruments: 5,335 relationships (18th most common) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Percussion and string instruments
Hi, This was discussed ages ago [1] and got some agreement then but was never actually put to action so I want to propose it as an RFC: In the instrument tree I would like some of the generic terms changed to the way they are mostly credited on releases: - percussion instruments - percussion - string instruments - strings All other occurences of ... instruments I would leave untouched for now because they are just grouping specific things and I don't really see them get used in credits but I very often see instrument performance credits for percussion or strings and arrangement credits for strings so it would just seem more natural to call them that in the tree. This RFC expires on the 21st of December. Cheers, Simon [1] http://musicbrainz.1054305.n4.nabble.com/Removing-some-quot-instruments-quot-from-the-instrument-tree-td1060704.html ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Distributors in release labels?
Hi, There've been several discussions on edits which try to add SPV GmbH as a release label to releases, with some edits failing and some being successful and also edits which try to remove it again. Since the result is complete inconsistency I would like to have a resolution on this. http://musicbrainz.org/label/72753055-4729-4c62-8143-a8c7783c86df/edits shows the list of edits for this label. It is noteworthy that they appear with this name as a distributor on releases. And SPV GmbH indeed appears in the logo then, so it is the imprint for this distributor (http://musicbrainz.org/edit/14876413). They have sub-labels like SPV Recordings or Steamhammer as imprints for the actual production. Up to 2009 they used to distribute the releases of the independent label InsideOut Music (not owned by them). Now the thing is that for these releases both InsideOut Music and SPV GmbH appear with their imprint logos on the releases and both appear with their own catalogue numbers (see for example the second picture on http://cover-paradise.to/?Module=ViewEntryID=446173 - the catalogue numbers in this case are IOMCD 074 for InsideOut Music and SPV 089-41512 DCD for SPV GmbH). Now I would like to add both labels with their catalogue numbers to the release. But Jacob Brett e.g. disagrees saying that distributors should not appear in the release labels and should be added with the publisher relationship instead. Which seems wrong to me because they've not been explicitly credited as a publisher. And I think the catalogue number is valuable information that needs to be stored - and in the catalogue number field rather than the annoation to make it searchable. And the fact that the distributor does appear with an imprint on the release should be reason enough to allow for them to be listed. What do you think? Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] About Do not cluster
Nicolás Tamargo de Eguren wrote: http://wiki.musicbrainz.org/Style/Relationships/Do_not_cluster is terribly outdated. Some cases just don't apply anymore (individual releases in a boxset, various recordings). Others, like the Jackson sibling example, are actually clustered (is not clustering siblings really a good idea anyway?). This should probably be rewritten or removed. I'd just remove it, but I imagine there are fans of the guideline around, so maybe one of these fans wants to update it? :) Looking at it nowadays the problems listed on there don't really seem to be problems to me. A lot of moderation work - so what? Everything's a lot of work but that shouldn't stop us from striving for correctness. Inconsistencies from editing - the fact that, say, Janet is linked as the sibling of Jackie but Michael isn't wouldn't make the first relationship wrong or the data inconsistent or anything. It's just incomplete in one position but that doesn't say anything about other relationships. So I think the advice given on the page is actually harmful. And anyway, siblings were always a bad example because you have half-siblings and all that. I'd say remove it or move it to some historic section / archive if anything like that exists. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] With in artist credits
Ryan Torchia wrote: The capitalization standard for English requires the word with be capitalized since it's more than three letters. There are a lot of corrections where with is being used in lowercase as a connector in artist credits. Should we have a policy one way or the other for this? --Torc. Shouldn't artist credits completely follow the release, including capitalisation, just like track titles? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] With in artist credits
Nicolás Tamargo de Eguren wrote: On Tue, Jul 12, 2011 at 8:46 PM, Simon Reinhardt simon.reinha...@koeln.de wrote: Ryan Torchia wrote: The capitalization standard for English requires the word with be capitalized since it's more than three letters. There are a lot of corrections where with is being used in lowercase as a connector in artist credits. Should we have a policy one way or the other for this? --Torc. Shouldn't artist credits completely follow the release, including capitalisation, just like track titles? Should track titles completely follow the release, even When It's All Like This In Spanish Or German? I don't think many people will be convinced by that even if that's what the guideline implies, tbh. I know I'm not convinced by it. :-) But it's what the guideline says and I think it should at least be consistent. Anyway, that would still leave this issue for recordings… True. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Multiple packaging
Alex Mauer wrote: On 7/4/2011 5:52 PM, Nikki wrote: What do people think about allowing multiple packagings to be selected? I don't mean anything particularly fancy, just like we have at the moment except you could select multiple things. I spoke to Ollie about it earlier and he said it wouldn't be hard to do, but doesn't want to do it unless that's what we actually want, so that's why I'm asking. I think it would be useful, but perhaps not as useful as per-medium packaging. Well, I don't think per-medium packaging is actually the correct way to model it because several discs can be contained in the same case. But I also don't think the perfect data model is always the best model for MusicBrainz because sometimes it just makes editing too hard / tiresome, even with the best interface, so the data quality will inevitably suffer from a really complex model. Therefore I think I'd actually prefer just being able to select multiple packaging types. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] second RFC: add “slipcase” to packaging types
Alex Mauer wrote: This is a second RFC for adding the “Slipcase” to the list of packaging types. Slipcases are commonly used to package several mediums together, as well as occasionally for just a single medium (cassette singles are the most common use of this) I propose also adding a section[1] to the style guide within Style/Release. This should cover the objections raised in the previous RFC: Packaging: When a release is contained within multiple packaging types, the packaging type should be set to the innermost type which includes all mediums within the release. For example, a 2-disc set of two jewel cases within a slipcase should be entered as “slipcase”, while a 2-disc set where both discs are in one jewel case should be entered as “jewel case”. —Alex Mauer “hawke” 1. http://wiki.musicbrainz.org/User:Hawke/Proposal:Packaging_Guidelines I still don't agree with this rule and I think it's a bit arbitrary and complicated to follow. You have shown examples of cassettes which only come wrapped in paper/cardboard but I'm not convinced that paper sleeve or cardboard sleeve wouldn't cover this case. How are slipcases different? If you can come up with a definition that clearly shows the difference and if we have the ability to select multiple packaging types (instead of your proposed rule) I would agree. Until then it's still a no from me for this proposal. :-/ Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] second RFC: add “slipcase” to packaging types
Alex Mauer wrote: What guideline would you suggest? Given that we can only have one kind of packaging currently, it seems that there is little choice but to have some kind of guideline for which to use when there are several. Use Other. Sleeves are essentially two-dimensional with just a fold at the edges, while slipcases have distinct sides (four or five). But for cassettes you can't really have flat sleeves. It seems like a necessity / logic conclusion to use something with more sides for them. Until we have a clear set of criteria for how to decide cases like these I prefer not to add any more types. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] second RFC: add “slipcase” to packaging types
Alex Mauer wrote: On 07/05/2011 02:44 PM, Simon Reinhardt wrote: Alex Mauer wrote: What guideline would you suggest? Given that we can only have one kind of packaging currently, it seems that there is little choice but to have some kind of guideline for which to use when there are several. Use Other. So if a release has two different packaging types, it should be placed in neither of them? That doesn’t make much sense to me. *shrug* Neither does this innermost rule to me. :-) Until we have a clear set of criteria for how to decide cases like these I prefer not to add any more types. I gave a clear set of criteria: Use the innermost packaging type. No, I meant criteria for adding new types of packaging. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-322: Partial Attribute for Performed Relationship Type
+1 Two points though (which are not meant to stop this from being implemented as is right now): 1) Would you consider a case where the whole work had been *performed* but only part of it been *recorded* (or only part of it released) a partial performance as well? If yes, then maybe the guidelines section should mention that. And what about radio edits for example, which are shorter than the album versions? Are they partial performances of the work that has been created for the album version? And what if an extended version gets released later on? Is that a different work then? 2) When this gets implemented, can http://wiki.musicbrainz.org/Proposal:Work_Parts_Relationship#Guidelines link back to it? I would put Use the 'partial' attribute of the Performed Relationship Type for that. after This relationship should only be used for works where the composer split a work into multiple parts, not where a performer merely performed part of a work, (often described as an excerpt, intro, or conclusion). Regards, Simon Nicolás Tamargo de Eguren wrote: As the original RFCr has apparently disappeared from the face of Earth (or at least from the part of it which has internet) I'm sending this RFV myself. There was recently discussion[1,2] over the merging of works where one or more work represented excerpts of the others, with associated concerns that relating a recording of an excerpt to a complete work would lead to loss of information. As a solution to this, it was proposed that the performance relationship be extended with an attribute indicating that this was a partial performance. Accordingly, RFC-322 [3] was created. The RFV period will end on 2011-06-29. [1] http://lists.musicbrainz.org/pipermail/musicbrainz-users/2011-June/020597.html [2] http://musicbrainz.org/edit/14554609 [3] http://wiki.musicbrainz.org/Proposal:Performed_Relationship_Type_Attributes ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Digibook to release packaging list
Alex Mauer wrote: On 06/21/2011 03:28 PM, Simon Reinhardt wrote: So going by that logic the 8cm CD snap pack thingy would be a digipak as well, yet you agreed that it could be added? I don’t believe I expressed an opinion on the snap pack thing That's how I understood the following bit: Alex Mauer wrote: Box Digibook 8cm Snap-Pack in lack of a better name: http://en.wikipedia.org/wiki/Mini_CD_single That one does seem obvious to me as well, but the naming is less so. but it does seem to have some features to distinguish it from a digipack, namely the smaller size (was there ever a 8cm digipak?) and the fact that “they could be 'snapped' and folded into a small square rather than being the original 6×3-inch (15×8cm) length type of packaging” A cassette case also has a completely different than a Jewel Case. Why is that not different enough? Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Digibook to release packaging list
Alex Mauer wrote: On 06/20/2011 04:04 PM, Simon Reinhardt wrote: I think book would probably describe a different kind of packaging. Can you describe how one would determine if a given package is a “Digibook”? To me your first example looks like a book with a paper sleeve glued in, and nothing more. Am I missing something there? Digibooks have a very distinguished look to me. They fold open like a book, the booklet is glued into them like the pages of a book and they normally have a very thick cardboard cover and grooves towards the spine where they bend when you fold them open. And it's a term used by the industry in advertising releases and by collectors for describing them: http://www.musik-sammler.de/media/550400 If the second example is clearly also a “digibook”, what are the features of it that distinguish it from a digipack? To me the important features of a digipack are the plastic trays glued to a cardboard cover, which that certainly has. (In this case, it has a booklet attacked to the fold in the cover, but that’s not a huge difference to me. So going by that logic the 8cm CD snap pack thingy would be a digipak as well, yet you agreed that it could be added? Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Keep case to release packaging list
Michael Wiencek wrote: On Jun 19, 2011, at 8:11 PM, Calvin Walton wrote: I’m just wondering if there might be a better name for them, or possibly a way to add a comment to describe them. Until I saw this proposal I didn’t have any idea that these cases (which I’ve always known as just “DVD cases”) even had a name at all! That doesn’t mean I have any objection to adding the packaging type itself, you have my +1 for that. I've always called them DVD cases too, so +1 to your suggestion. Does anyone have any suggestion of what the name should be? We could use Keep case, or DVD case by itself, or order a comment in any number of ways: Keep case (DVD case) Keep case (DVDs) DVD case (Keep case) ? I like Keep Case (DVDs) but I'm wondering if there are any releases with CDs in Keep Cases. Otherwise +1 on Keep Case. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Keep case to release packaging list
Alex Mauer wrote: On 06/20/2011 12:26 PM, Simon Reinhardt wrote: I'd like to see a couple of them added and there's also a general problem that many things can't be represented (e.g. a cardboard box containing a Digipak with two CDs in it and a Slim Jewel Case with a DVD in it). But I'm happy with doing them individually so that they don't depend on one another for the style process. I’d think we should probably divide them into a few RFCs so we don’t end up with 30 different RFCs each for one item. In particular, I think the following are obvious “Yes”s and could probably be RFCed together: * Slipcase * Box * None * Keep case Not so obviously yes to me. Box is too general for me and Slipcase is usually something around a Jewel Case or Digipak so to me it's one of those problematic cases that I'd rather not touch without further thought into how we could represent this schema-wise (and if we want to at all). Btw: Nikki compiled a page about packaging as well: http://wiki.musicbrainz.org/User:Nikki/Packaging Obvious yess for me would be: J-card Case Cardboard Sleeve Plastic Sleeve Keep Case Super Jewel Box Digibook 8cm Snap-Pack in lack of a better name: http://en.wikipedia.org/wiki/Mini_CD_single Don't know much about vinyl but there might be obvious ones there as well. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add “Slipcase” to release packaging list
Similarly to box I'm against this because it often contains other things in it. For example when there's a Jewel Case with one CD in it and it has a cardboard slipcase around it I would just set it to Jewel Case. But if there are several different things inside the slipcase I'd use other rather than the outermost packaging. Regards, Simon Alex Mauer wrote: As NGS now lists releases instead of individual discs, and as slipcases are commonly used to bind an entire release of several discs (in separate jewel cases) together, it seems appropriate that the slipcase should be added as a package type for releases. This RFC will expire on 2011-07-27. —Alex Mauer “hawke” ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add “None” to release packaging list
+1 on this. Regards, Simon Alex Mauer wrote: With digital downloads growing over physical media, it seems like “None” is a pretty common packaging type, and will only become more so… This RFC will expire on 2011-7-27. —Alex Mauer “hawke” ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add “Box” to release packaging list
I'm against this as it's too general. Is it a wooden box? A carboard box? What dimensions does it have and what does it contain? Also it's often used to contain other packaging types - in those cases I'd rather use Other or the most specific standardised packaging that applies to all contained discs. Regards, Simon Alex Mauer wrote: The box is a pretty standard package for piano rolls. In addition, as NGS stores releases instead of individual discs, it is not uncommon for all vinyl discs or all CDs to be in a box, even if an individual disc is packaged in a sleeve or a jewel case. This RFC will expire on 2011-7-27. —Alex Mauer “hawke” ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: Add Digibook to release packaging list
I'm not sure how standardised these really are. Digibooks look a bit like digipaks but they always fold open like a book, see e.g. http://rhapsodycollectors.kit.net/collections/digibook1.jpg I usually know them in Keep Case size, e.g. http://johnnymusic.free.fr/CDALBUM/Ca_ne_finira_jamais/digibook_dvd.jpg This RFC will expire on 27th June. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add “Slipcase” to release packaging list
Alex Mauer wrote: My reasoning: * In contrast to slipcases, no release is packaged *only* in an obi; an obi is an accessory item to the packaging. Slipcases are sometimes used as the only packaging: [1,2] * I may be wrong here, but I think obis don’t cover several mediums without additional packaging to actually hold the mediums together, such as a multiple-disc jewel case, or a slipcase, or a box. 1. http://3.bp.blogspot.com/_0FaQ7TxM2U0/S0RjcAbs3UI/Bxk/DbPZNSAPkjE/s1600-h/1991CasSinglesBox.jpg 2. http://1.bp.blogspot.com/-sVmplcrE2xY/TXD9ZLFKH9I/AoM/gPU5XJ8O0qw/s1600/cassingles.jpg I don't really see a slipcase being used as the only packaging on those pictures. To me a slipcase is an accessory item as well. To some collectors the plastic packaging with the sticker on it might me an accessory item (which is why they never open their releases). And I've seen releases which were sometimes sold with the slipcase around the jewel case and sometimes without. So to me it's not really part of the defined packaging of a release but more like decoration (in most cases but maybe not in all!). Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Packaging types
Alex Mauer wrote: J-card Case I think that’s just a jewel case for cassettes. Certainly the hinge design, ribbed edges, etc., are essentially the same but resized appropriate to the medium. Super Jewel I see that as just a variant on a jewel case, much as some have a transparent tray or ribbed edges (or not) A Slim Jewel Box is a variant of a Jewel Case and yet we have it in the list. :-) To me it's not really a variant of it but a new product, just like the Keep Case is a different product, and it just happens to be made of the same stuff. The cassette one is not a jewel case at all - it's also just made of the same stuff (most times). Jewel Case is a specific term for a product invented at Philips if you believe http://www.research.philips.com/cgi-bin/search.cgi?cc=1URL=http:%2F%2Fwww.research.philips.com%2Ftechnologies%2Fprojects%2Fcd%2Fjewelcase.htmlq=comwm=wrd and http://www.research.philips.com/cgi-bin/search.cgi?cc=1URL=http:%2F%2Fwww.research.philips.com%2Ftechnologies%2Fprojects%2Fcd%2Fjewelcase.htmlq=comwm=wrd I'm not trying to cover products of certain companies here but terms as they're actually used in the industry. I can't quite follow your reasoning. Do you aim to only make a difference between materials? Probably not as you don't want differentiate between paper and cardboard sleeve. Different styles of packaging? How specific though? Or just broad generic terms? How generic? Would you rather remove Slim Jewel Case from the list and just have terms like sleeve, box, case? I just can't quite see where you're going. :-) Cardboard Sleeve Plastic Sleeve I don’t know that there’s much difference between paper and cardboard in this context (I always understood “paper sleeve” to refer to any paper sleeve, regardless of thickness of the paper). And I think we’re getting into too much detail with paper, plastic, cardboard, etc. sleeves as separate items. Hm, paper and cardboard are not the same to me so I wouldn't want to reuse paper for cardboard ones. So either we rename paper sleeve to something more generic or we do go into more detail. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Digibook to release packaging list
Alex Mauer wrote: I think this would be better as “book” so it would cover a wider variety of situations, and without having to be concerned over whether it’s a Genuine [Company] Digibook™®. I think book would probably describe a different kind of packaging. And afaik digibook is not a trademarked term. Digipak used to be but has now apparently become a genericised trademark: http://en.wikipedia.org/wiki/Optical_disc_packaging#Digipak Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add Super Jewel Box to release packaging list
Alex Mauer wrote: As I see it it’s just a variant form of jewel case, of which there have been dozens over the years. We don’t need to add a new packaging type every time some company adds their own Special Sauce and adds a ™ or an ® on the end. It's quite different to a Jewel Case though. And I think it's being used often enough to justify being recognised as more than just a random product by some random company. Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] SoundCloud URL relationships
Hi, I was wondering which relationship types to use for relating artists and recordings to SoundCloud URLs (http://soundcloud.com/). Nikki was so kind to query the existing usage of types for these URLs for me. :-) artists: biography | 1 discography | 11 download for free | 63 fanpage | 4 myspace | 1 official homepage | 15 online community | 47 purchase for download | 3 social network| 43 streaming music | 72 recordings: creative commons licensed download | 3 download for free | 37 streaming music| 46 As you can see it's rather messy for artists at the moment and I think it needs some form of standardising or at least cleaning up. A bit about the site: In their own words SoundCloud is a platform that puts your sound at the heart of communities, websites and even apps. Watch conversations, connections and social experiences happen, with your sound as the spark. Artists can create profiles where they can upload tracks. Apparently you can offer tracks only for streaming or also for downloading, and you can CC-licence them. It also has social network / online community aspects (followers, groups, comments (even within tracks), favourites, sending messages etc.). So for artist-URL relationships all three of social networking, download music for free and stream for free seem suitable (but I'd rather not see the class types get the music and online communities be used). Since the site is mainly about getting the music I would lean towards relationships from that class but on the other hand: an artist can offer all of their tracks for streaming only, all of them for downloading as well or some for streaming only and some for downloading as well. And we can't deny the social/community aspect. For those reasons, do you think SoundCloud deserves an artist-URL relationship type of its own? And if so, which class would you put it under? On to recordings: All tracks that have been uploaded will always be available for streaming so as a general type that will always work. But if something's also available for download I'd rather want to see that used because being able to download music is better than just being able to stream it. And if something's offered under a CC licence I'd use the CC relationship type. In my eyes it's quite clear what to use for recordings and we don't need a new type. What do you think? Oh and: You can also create sets of tracks and I have seen them used as folders for albums - so maybe we'd want to relate set URLs to release groups in some cases? Cheers, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SoundCloud URL relationships
Nicolás Tamargo de Eguren wrote: On to recordings: All tracks that have been uploaded will always be available for streaming so as a general type that will always work. But if something's also available for download I'd rather want to see that used because being able to download music is better than just being able to stream it. And if something's offered under a CC licence I'd use the CC relationship type. In my eyes it's quite clear what to use for recordings and we don't need a new type. What do you think? I can agree with this. Although it's possible (and kinda common) to limit the number of downloads (for example, 100 free downloads) and leave it as just a streaming afterwards… Ah, I didn't know that. Is that N free downloads overall (first come, first served) or per user? Oh and: You can also create sets of tracks and I have seen them used as folders for albums - so maybe we'd want to relate set URLs to release groups in some cases? I would link them to releases, not release groups. Although we maybe could use the same stuff as for recordings there. Why releases rather than release groups? I think that with releases being as specific as they are now a set in SoundCloud would apply to many different releases. Not all of them maybe though... Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-321: Work parts relationship
Lemire, Sebastien wrote: There might not be numbers, but they were definitely composed with an order in mind. I absolutely don't want MB to add 1. 2. 3. in front of movements, but somehow it would be best for the order to preserved I liked what Christopher Key proposed: Having a sort name field on works that will be used for ordering relationships. I meant to say that before but for some reason I sent my reply only to him and not the list. :-) Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-321: Work parts relationship
Alex Mauer wrote: The RFC period has ended for this proposal[1], with no major objections. I have updated the proposal with some more guidelines for its use based on the list response, and so bring this to RFV status. 1. http://wiki.musicbrainz.org/Proposal:Work_Parts_Relationship +1 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-321: Work parts relationship
symphonick wrote: And, as Rob suggested, not having to repeat the main work title for all the subparts. http://lists.musicbrainz.org/pipermail/musicbrainz-users/2011-May/020578.html Hmm, good point. This sounds like something that should be covered by the guidelines for the relationship as well: Should the part works contain the title of the overall work? Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Concept of works group
Hi, If there really was a separate entity for work groups, then how would you deal with the case of several hierarchical levels? Using an example that was posted earlier: http://musicbrainz.org/work/b3b1e2b3-cbb8-4b46-a7d0-0031ec13492c Il dissoluto punito, ossia il Don Giovanni Ouverture. Andante - allegro molto Act I Scene I. No. 1 Introduzione Notte e giorno faticar (Leporello) Scene II. Recitativo Leporello, ove sei? (Don Giovanni, Leporello) Recitativo Ah del padre in periglio (Donna Anna, Don Ottavio) ... Would only the leave nodes in the tree be work entites and all the others would be work groups? In that case work groups would have to be able to contain work groups as well as works. Or should we not have several levels at all? Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-322: Performed relationship type attributes
Christopher Key wrote: There was recently discussion[1,2] over the merging of works where one or more work represented excerpts of the others, with associated concerns that relating a recording of an excerpt to a complete work would lead to loss of information. As a solution to this, it was proposed that the performance relationship be extended with an attribute indicating that this was a partial performance. Accordingly, RFC-322 [3] was created. The RFC period will end on 2011-06-13. [1] http://lists.musicbrainz.org/pipermail/musicbrainz-users/2011-June/020597.html [2] http://musicbrainz.org/edit/14554609 [3] http://wiki.musicbrainz.org/Proposal:Performed_Relationship_Type_Attributes +1 ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Concept of works group
Frederic Da Vitoria wrote: Yes, I forgot about this, but I feel this is a good argument against implementing Work groups in a separate table. One day, a Work group (can someone think of a better name?) may be recorded as a whole (some conductor may decide to play all movements of a symphony without stopping, for example), so that the Work group would be a Work too. Now that I think of it, it has already happened. There is a release of Prokofiev's 3rd piano concerto where the variations are split in several tracks, so that we'd need to say that this movement is a Work group in order to group the variations into one movement, which itself would of course be a Work since it has also been released as a whole. It happens for Progressive Rock all the time. See e.g. http://musicbrainz.org/recording/183dde22-04e3-48b0-a3f3-06903e1df047 which was first recorded and released as a whole track with the parts mentioned in the booklet and then later some of the parts were performed individually live: http://musicbrainz.org/release/c3da44dc-199f-3645-8f31-1e49a747e272 Having a separate entity for a group would mean all relationship types that can apply to works would potentially have to apply to work groups as well. I much prefer having just one entity type (and we've already got a type attribute on it to specify groupy things) and linking with relationships to having a group entity and a schema link. I still don't understand why a large number of sub-parts would mean we should have a work group entity. If it's just the amount of work of adding all the relationships then an interface tweak should be able to help (just like relate to all recordings there could be a relate to all sub-works; even if in the former case it relies on a hard-coded database link and in the latter the interface code would rely on the existance of a relationship type). Sorry, went a bit off on a tangent there. :-) Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-321: Work parts relationship
Hi caramel wrote: This AR could be useful but mostly when there are only few works related together. I would prefer the concept of Work group instead with the possibility for the works to inherit the ARs at the work group level. For CSG, the number of sub-works can be several tens. I'd prefer relationships to a grouping type. What's the problem with having loads of sub-works? Regards, Simon ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-321: Work parts relationship
Hi, Wow, it's been a long time since I've been signed up here. :-) +1 on this proposal, it is much needed for progressive rock, some metal etc. Reading the guidelines section I think later on we might also need an attribute for the recording performance of work relationship so that we can have recording _partial_ performance of work (this also happens in progressive rock). And there are some other cases which I think might need coverage in the guidelines section: - Releases where one track corresponds to the whole composition and you create sub-works anyway because they are listed in the booklet, even if they don't have recordings attached to them. I've seen releases like that where different people are credited for the lyrics or composition of the individual parts and so far you couldn't credit them properly because it was all one big track. This would be possible now using this relationship. - Releases where one track corresponds to one part of the composition. It's nice creating an overall work linked to the parts even if the overall work won't be linked to a recording itself. There might be releases like that where the composer/lyricist are only listed for the overall work and not for the individual tracks (e.g. when they're only credited for the whole release). Should there be a guideline where to attach the artists then? - Releases where the whole album (or just one disc of the release) represents a work and the tracks are the parts. It's not always going to be clear-cut when that's the case. Sometimes the artists make it very obvious that they want the whole thing to be seen as one composition because they title the tracks as parts. But many concept albums where the track titles don't have that could be seen as one composition as well, e.g. because they tracks all tell parts of a story and/or there are no gaps between the tracks. - Releases where one track corresponds to several parts at once but not all of them. I'm not sure what to do in that case. Should there be a work for this collection of parts that is linked with this proposed relationship to the overall work? Or should the recording be linked as a performance to all the part works it contains? An annoying album sort of falling into that last category is Pink Floyd's Wish You Were Here where the song Shine On You Crazy Diamond first appears at the beginning of the LP with parts 1-5 and then at the end with parts 6-9. But in later re-releases they called the first track Part One and the last one Part Two. And often artists will go for one option on one release and then for another option on another, for example performing a whole work on one track on a studio album and then only parts of it on a concert which ends up on a live release. And if they're really evil they put it into a medley with other stuff. :-/ One last point: What are we going to do about ordering of the parts? You can't do it with the relationship so should the titles of the part works have numbers in them? Regards, Simon -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFC-321-Work-parts-relationship-tp3567163p3574465.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New instrument: Guitar synthesizer
Chad Wilson wrote: Tracked at http://bugs.musicbrainz.org/ticket/3619 I copy and paste the text from there for discussion (apologies if instrument requests don't require RFC, but thought it may be useful for discussion anyway and other instrument requests seem stuck in no man's land). Yeah, for instruments it's a bit easier. :) You can add your proposal to http://wiki.musicbrainz.org/InstrumentAdditionDiscussion Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] General overview of all ARs: Results and suggested changes
3) We have a release is a live performance of release AR, but not a track is a live performance of track. This falls into the same situation as #2 above. I can think of very few situations where release X is a complete live performance of release Y - and ONLY of release Y. I can, however, think of tens of thousands of examples where track A is a live performance of track B. Yet we have this AR only at the track level, and not the release level. This was dodgyly added, that is without much discussion and therefore without much thought about the consequences. Actually a live performance (and I know of several such cases, even live covers of albums) is a special case of another recording of an album and therefore should use the OtherVersionRelationshipType like tracks do. I had proposed adding attributes to it in the past, like live, acoustic, studio (a song might have been first played live only), ... Also I still think that OtherVersionRelationshipType should be renamed, see the discussion section on its wiki page. :) Proposed: add a track-track is a live performance of AR, Remove the release-release version of the AR (converting any such existing ARs to the track-track ARs) Disagree for the reasons above. Simon (Shepard) -- Pt! Schon vom neuen GMX MultiMessenger gehört? Der kanns mit allen: http://www.gmx.net/de/go/multimessenger ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New Release Status: Upcoming
Aaron Cooper wrote: Thanks to the internet, information about soon-to-be released albums is available well before the official release date. I think we should have a Upcoming or similar ReleaseStatus for albums which are added to the database before the official retail release date. This would allow us to add information which people find useful (with proof, of course) before the release is available for public consumption. We could maintain a query of the Upcoming releases (possibly sorted by expected release dates) which would make it easy for us to review and confirm details on or after the official release date. The release status could then be changed appropriately. Thoughts? On one hand, the info would be redundant because a release date already expresses that something is upcoming. On the other hand it's not really. For example if a band publishes a tracklisting for one of their albums and says we'll be releasing this in the summer this year then you can only set the release date to 2007 and it wouldn't be known if this is still an upcoming date or already over. Also you already may have exact information for an album before it is released, through a promo copy for example. Then the release date would be in the future but the data would be confirmed already. Perhaps unconfirmed is a better term for such a release type, less ambiguous and redundant. I've been thinking about a way to keep track of news for my favourite bands. I want to get informed about: 1. regular news about a band (line-up changes, sideprojects, etc.) 2. concert dates near me 3. upcoming releases (different phases like composing, recording, mixing; when a title, a tracklisting, release dates and cover art get available) 1. is something for which I, unfortunately, still have to scan band websites. This is because most of them missed the Web2.0 trend and never heard about RSS (not to speak of working websites). 2. is something sites like http://upcoming.org/ , http://eventful.com/ and lately http://www.last.fm/ do (more or less good). 3. is something MB could well do - I'm not sure though which of the different phases of an upcoming release it could cover. Ideally I would be able to query for upcoming releases for my subscribed artists (or even a separate list of artists because my subscriptions cover my editing preferences, not my musical preferences), whether there are titles available already or not. Those unconfirmed releases could also be listed separately from the regular discography. Simon (Shepard) ___ Musicbrainz-style mailing list [EMAIL PROTECTED] http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New Release Status: Upcoming
Aaron Cooper wrote: I should clarify that the status Upcoming is just my recommendation. We can decide on what the status should be called, but I think for now we should just discuss the merit of having a release status for this purpose. Well with that I was pointing out that your proposal includes two separate purposes: getting lists of upcoming releases and marking a release as unconfirmed. Which of those did you mainly want to discuss? Because the former is covered by release dates already with the exception of the first case I described. The latter would be useful for editing but would exclude upcoming releases with confirmed data (so if you want to get a list by this release type for keeping up with your bands you'd be missing some of the releases). Of course the release type could be introduced with a less strict definition and we could just watch what the editors make of it. Simon (Shepard) ___ Musicbrainz-style mailing list [EMAIL PROTECTED] http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New Release Status: Upcoming
[EMAIL PROTECTED] wrote: On Sat, Apr 14, 2007 at 10:37:10PM +0200, Simon Reinhardt wrote: Well with that I was pointing out that your proposal includes two separate purposes: getting lists of upcoming releases and marking a release as unconfirmed. Which of those did you mainly want to discuss? Because the former is covered by release dates already with the exception of the first case I described. The latter would be useful for editing but would exclude upcoming releases with confirmed data (so if you want to get a list by this release type for keeping up with your bands you'd be missing some of the releases). I think i wouldn't consider anything 'confirmed' until the album was actually released. (and even then,.. occasionally misprints happen and get recalled ;) What do you want the release type for then? If the date is in the future then people have to have a certain scepticism as to the correctness of the data. And if they don't notice the date, they wouldn't notice the release type either. We had discussions about adding releases before the release date. My position (and that of some others) was that you can get crappy / erroneous information about releases even after release dates and therefore we could as well add them before the release date. Just because the date is over doesn't necessarily make information better. I would - however - still wait until enough information is available before adding a release (complete tracklist with times, release title and exact release date). So an additional release type could just work as a flag for incomplete data to tell people that the presented data doesn't follow the typical MB quality standards yet. Simon (Shepard) ___ Musicbrainz-style mailing list [EMAIL PROTECTED] http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Should we keep the spaces before punctuation in french?
Olivier wrote: 2007/1/7, Simon Reinhardt [EMAIL PROTECTED]: I think the cases where the colon is not used for sub title style are rare. Or do you have examples for uses of colon and comma where you think French spacing should apply? Here is one: http://ludwigvon88.free.fr/html/sacregrole.htm To me this is a typical example for sub title style. :) though I certainly agree this is more rare than musicbrainz artificial subtitle style, or that the possible examples are all somewhat natural examples of subtitle/part style. I guess so. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ARs for labels
Lukáš Lalinský wrote: label--label: * parent label * labelA is a parent label of labelB * labelB is a sublabel of of labelA I think usually they call this a division. Any ideas for more? Do we want to collect information about one label buying up another and stuff like that or is this too vast? Another thing I can think of right now is labels which are usually the distributors for other labels, for examples SPV always distributes the releases of InsideOut Music. Then artists being signed to labels. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: new AR 'Artist X wrote the liner notes for release Y'
Mangled wrote: To be consistent with the other stuff on this page, it would go like: * artist or URL provided liner notes on release or track * release or track has liner notes by artist or URL Oh I wasn't implying to be consistent with them, I also think that looks ugly. ;) Just that we put it in that section. Now, personnaly, I would simply strip it off to the following: * artist wrote liner notes on release * release has liner notes by artist or URL I liked for more, and you surely forgot to strip off the URL here. ;) (a) because Liner notes provided by an URL are no longer Liner notes, but are a Third party review IMO (except possibly in the case of net releases?) Yeah, URLs make no sense here. (b) because I can't imagine liner notes per-track (hence I think this AR only apply to releases, not to tracks)... I have at least one album where the members of the band talk about every track in detail. (c) because I feel provided is ambigous, and wrote looks better... Yup. And well, we may have additional for this AR. It can be usefull when a reissue provides the original Liner notes and also new additional liner notes. Or when one person wrote the main blurb and another one wrote a smaller one. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Cover style
azertus wrote: Sami Sundell schreef: To make things clearer, I think it would be better if the covers AR would only be added from the earliest version of the covered song to the earliest version of that particular cover version. That way under P.J. Proby's track there would be a more manageable list of different artists covering that particular track. What do you think? Of course! I've always read the guidelines as implying just that. This is, IMO, a general AR principle that should be honoured. I collected this and some other general linking issues on http://wiki.musicbrainz.org/AdvancedRelationshipStyle so the discussion is documented. :) If you know of any other unsolved issues with AR, please add them there. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Cover style
Sami Sundell wrote: On Wed, Sep 06, 2006 at 10:44:05AM -0700, Kerensky97 wrote: It's a good point some of the songs in the database will be swamped with cover links, so I prefer variant 1. I'm not sure how it will affect NGS or whatever when it gets implemented but it still makes sense to me. Yeah, some songs will have at least tens of cover versions, probably released hundreds of times. I guess we're making the earliest releases sort of song objects, even though that's not part of the NGS. There are different possibilities here: We could say that all released tracks of a song and all released tracks of a cover of it should share the same composition object. That would give immediate access to composer lyrics writer ARs and would completely drop the CoverRelationshipType once the data is converted to that. Or we could say: There should be one composition object for the original song which groups all released tracks of that, then a composition object for each cover version of that song which groups all released tracks for that covered version and then cover relationships from the composition object of the original song to the composition objects of the coverd versions. For border cases, like when a member of that band that did the original version starts a solo career and plays this song or goes to another band and they play it, we can then decide if we create a new composition object or not. Of course there are also other AR's that could be related only to one version of a track (guest performances etc). I think the original idea was only to link performers and the like to the earliest version of a treack/album. That was part of a thread where I asked about different AR linking philosophies, I think most people nowadays add ARs to the releases they own / they can find infos about. By the way, I took a look at the ObjectModel/NGS/whatever pages. Is it just me, or are those pages missing lyrics? No, not part of this mailing list, just came to my mind when I tried to look for the proper object in here 8) Lyrics are included in the composition object as of now. That could lead to problems with songs that use lyrics from one song but have a different composition and stuff like that. So an option would be to introduce a separate object for lyrics - then the hierarchy wouldn't be a simple top-down approach any more though, the linking between those could get quite complicated. Also: what about arrangements then? Do they deserve their own object too? IMHO it would be simplier to cover all this with one object. Stefan Kestenholz wrote: Lyrics=not possible due to copyright issues. (see all those lyrics sites which are taken down by the industry as we speak) I don't think he meant actually storing lyrics or linking to them but just having an object which represents the lyrics like the composition object. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
Brian G wrote: again i point out that we need to call things what they are or else we will continue to create confusing BadTermonology which creates communication issues in the long run. call things what they are rather than coming up with some new meaning for an incorrect term. This is intended to be a release _status_ if I understood it correctly. So yes, the release may be a transliteration/translation mainly. But the release _status_ is not. There it just doesn't fit. In my eyes virtual would be the best description for a status. But I'm fine with other things, just your argument that it's a translation doesn't work any more then, so you can't put a preference on this. translation -- i don't see how it can become any more concise without losing meaning of what's actually going on. and that can include transliterations because transliteration is a translation that is literal. I'm quite sure this is wrong but I let the linguists elaborate on this. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again! (now on test.m
Kerensky97 wrote: And I agree with Gecks that that disclamier might be a little more than is needed; hopefully people realize that as a transl(iter)ation it should be identical to the other release just with different words in the tracks and title. I don't think that's what Gecks meant. He said it should not only be allowed for identical tracklistings (apart from transl(iter)ation), but also for tracklistings with bonus tracks or another track order. Here we have to be careful. How will NGS use this relationship and how will it use remaster relationships? Well, when we run the initial conversion to a new schema, it will observe relationships such as remaster and automatically create a release group in which it puts both. Apart from that, the relationships and releases stay untouched. When it encounters a transl-AR, it should check the release status: if both are official, put them in one release group and leave them as they are. If one is virtual/alternate/... and the other official, and the relationship points in the right direction (else someone made a mistake :)), then merge the virtual one into the official one and append the tracklisting as alternate titles. So if we allow this AR to be used for tracklistings which are different in the track order or have bonus tracks, then only for linking two official releases. A virtual release which is not about the exact same tracks should never be linked to an official release, because that can create wrong merging results when transforming the data to NGS! You might say, why should someone create a virtual release with a different track order? Well that perhaps not but consider this case: There's album A with 10 tracks and there's album B with 13 tracks which is just another edition of A with bonus tracks. Now you can have a transliteration A* of A and a transliteration B* of B. Imagine we just have A and B* in the database (because noone could find the original tracklisting of B yet but only a transliteration). Someone might think: oh, it's surely ok to create a relationship A is the original language/script track listing of B*, one is official, one is virtual, they are almost about the same tracks, can't be bad. But that would be a big mistake. So I think a disclaimer for that case is needed. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: RFC: Transliterations/translations, again
Nathan Noble wrote: I have a tricky case for you: in my shelf there's a classical CD which I didn't dare adding to MB yet. Reason: it has both German and English titles in the tracklisting... This is common in classical. I've always added these in whatever language appears first, though I've come across releases where the tracklisting and liner notes are not in the same language order. In that case ethnocentricity is my tie-breaker and I enter english (assuming that was one of the options, and it always has been). Not sure if that's acceptable or helpful. I'd bet $50 the cd on your bookshelf is released by Deutsche Grammophon... How do you plan to transfer it? It's ZYX Classic. :P Simon ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
Stefan Kestenholz wrote: unless i'm mistaken, this is relationship is not for actual translations of the tracks/releases themselves, but the track/release *tracklistings* only. Please answer me this: What is the legimation of a user translated entries in the database, if it wasn't released in this form? I have seen no objections against the ideas of creating translations in the database, I think this should be adressed first. Listen to Don: rules follow practice. With tons and tons of translations and transliterations already being in the database you cannot just go and make a guideline not to allow that. It's unrealistic. So instead of discussing this question *again* I think Nikki would be pleased if you all stay on topic and discuss the proposed relationship types and the release attribute. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Transliterations/translations, again!
Chris Bransden wrote: On 09/08/06, Stefan Kestenholz [EMAIL PROTECTED] wrote: unless i'm mistaken, this is relationship is not for actual translations of the tracks/releases themselves, but the track/release *tracklistings* only. Please answer me this: What is the legimation of a user translated entries in the database, if it wasn't released in this form? I have seen no objections against the ideas of creating translations in the database, I think this should be adressed first. IMO this AR is needed regardless. there are plenty of albums that have one tracklisting in one country, and another in another - note I am talking about the *text* on the tracklisitng, nothing else. Thanks for being realistic. :) Although you seem to be for merging them, you understand that, since we have them and they won't just go away, we need to handle them somehow. And to everyone: when discussing relationship types, please always keep in mind that they are essential for NGS. The AR data will be used excessively to do the initial data transformation to the next schema [1]. what i was saying is I don't think it's intended for actual translations of the *songs* themselves (eg a band doing a song in their native german, and then releasing an version with re-recorded english lyrics). Which is exactly what Nikki's initial mail said. :) Simon (Shepard) [1] for details see http://wiki.musicbrainz.org/NextGenerationSchema#head-8b940439575ebe5f8daf3203383111a73f29f6ba ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Re: RFC: Transliterations/translations, again
Alexander Dupuy wrote: Deciding which are the original titles when there are simultaneous official releases with titles in different languages will be tricky, but I guess that's what we have editors and voting for. Chris B's suggestion to use the actual language of the songs is a reasonable guideline for songs, although it doesn't help for musical works without words (instrumentals). There are also probably some cases where there are multiple different translations entered in the DB, but the originals have not actually been entered (e.g. a release with Amharic (Ethiopian) and (translated) English titles on the cover, where only the English has been entered, the English titles are not really the original for a French translation). [Note for Nikki - do we actually have any Amharic script entries?] The song language guideline doesn't help settle the originality of different script versions for the same language (e.g. a Serbian album with Cyrillic and Latin script versions). However, regardless of what obscure corner cases I can come up with, I am convinced that having an original directionality is, on balance, the better solution (especially since it makes it explicit how one should avoid relationship clusters). I have a tricky case for you: in my shelf there's a classical CD which I didn't dare adding to MB yet. Reason: it has both German and English titles in the tracklisting... Anyways, an important example for when we have transl(iter)ations but not the original titles in the db: Since CDs are expensive in Japan, western artists often produce special releases for it with bonus tracks on them. I don't own such a Japanese edition but I'm pretty sure the titles are not in latin on the covers most of the time. Yet, I haven't come across editors from Japan for the rock bands I edit. And apart from amazon.co.jp, where I wouldn't copy tracklists from, I don't know where I could find reliable resources for tracklists how they are printed on the covers of such Japanese editions. But what I can find out is how the tracks are called in English/Latin. I have the tracklisting for the European/US release and the artist websites often list the titles of the bonus tracks for Japan. So what can I do much but enter the Japanese edition in English/Latin? And I can't even find out, if the Japanese release really has the titles in latin or not, so probably I'm enterin g the official release, probably the virtual release. God knows, but you can't blame me for it, it's common practice. ;) There are lots and lots of those just in the metal section. I haven't seen anyone complaining about them yet. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] New to this list
mll wrote: Hello there, As a recent suscriber, this is just a quick mail to introduce myself. I suscribed upon dmppanda's request for a very precise reason he and azertus know, yet I'll be lurking for a while before to learn how this list lives. This is the first MB ML I suscribed too, if it's useful to suscribe to another one to complete the Style ML experience, just let me know. Hey and welcome! :) You could definitely subscribe to mb-users which is a bit broader. On the style mailing list we discuss style issues relevant for the database in general (or for bigger parts of it) while on mb-users we discuss single cases and everything around the community. Greets, Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SeriesNumberStyle - useage for more than one named part/volume in the same track/release
Chris Bransden wrote: haha, well lets forget about it for now then, it's definitely not important at this point :) Thanks! That's kind of you. We'll figure it out at a later point. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New Artist Type: Project
Stefan Kestenholz wrote: I've added [1] the new artist type, and it is ready on test to play around with. I agree with robert that this has minimal impact, since it doesn't influence ReleaseArtistStyle IMO, but helps to achieve a finer granulation how we can represent an Artist (a project is very often clearly perceived as that in a non-database view of the music world). regards, Stefan [1] http://bugs.musicbrainz.org/changeset/8010 [2] http://test.musicbrainz.org/show/edit/?editid=3931038 The relationships are also live on test now, feel free to play around with them: http://test.musicbrainz.org/show/artist/relationships.html?artistid=14521 And tell me if you want changes in the phrases. :) Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] New AR links for Broadway Productions and ClassicalMusic
Beth wrote: In light of this incredible amount of information, I don't feel I am as capable of doing the wiki, perhaps if I had more free time, at the moment though... my time is a lot more hampered than it use to be. Sorry. No problem. :) I don't want to bring it through since that'd mean I really want it and have to support it. But I think with a bit more input from the original requester we can work this out. Then we are able to write wiki pages and do an RFV. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] New AR links for Broadway Productions and ClassicalMusic
Wendell Hicken wrote: What sort of input would you like? Do you want me to try to contact the admins for these sites and clarify the link persistence issue? You could do that for one, it would surely help a bit. And since it's your proposal you could also sum up and decide for link formats and for phrases for the ARs. I will help with the wiki pages. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version) - Form of this change
Lukáš Lalinský wrote: Robert Kaye wrote: Agreed 100%. If anyone needs any _more_ reason than that, I can put my evil overlord hat on. Between TaggerScript becoming a reality and this reasoning, there is no logical way to support the removal of (Album version). Period. Can I take as a final decision and update the wiki pages? Apart from what I think about album version information, I really don't like the form of how this went. The discussion was open for three days, then a veto was requested inside a mail. Then the decision was made within 34 hours. Then the change was announced on a wiki page only that only a few people following the most recent discussions on this mailing list even noticed so far. This is all very suboptimal in my eyes. I didn't plan to step into this discussion but other people perhaps did. Given that there was much traffic on the mailing list at that time (because of the net releases for one), there was rather a lot to read so I think people needed some more time to get into it. But three days from the first mail to the veto isn't enough. The new form of requesting vetos Don suggested and used here isn't obvious enough I think. I'd still like to have topic changes (RFV: (album version)) for that. And just the mention of ruaok to use his position as evil overlord to decide on this should be no reason to shorten the veto period drastically. Finally this is a change with a rather big impact on the data and therefore needs to be announced on the mailing list. The new wiki page is nice as a log of changes but it doesn't catch everyone's attention - especially since it's a very new page. As a side note this is the second time I notice a decision many people are interested in to be made so fast. I think only because many people consider this to be important and want this to be changed as soon as possible, we should not forget about our formalities. Thanks for listening, Simon ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
Simon Reinhardt wrote: I propose adding CoRelationshipAttribute to EngineerRelationshipType (the main type, not all sub types) and within that to the sub type for mixers, and adding ExecutiveRelationshipAttribute to EngineerRelationshipType (again the main type only) as proposed by Schika. For this I let the veto phase open for another 48 hours. If someone thinks we need to clarify those two sub roles first (that is to write the wiki pages for those attributes to exactly describe them), feel free to veto. For the records: no vetoes, so applied. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Dealing with translations and transliterations
Nikki wrote: Basically, yes. The overall thread so far has been that: Some points to add: Dustin exhaustively tried to state why we *should* allow virtual duplicates - which I think was unnecessary because everyone who still wants to argue against that is a bit out of reality. ;) Also it was said that we might want to make use of this relationship for displaying duplicate releases together with the official ones (?) and let all changes to one of the releases (except the titles) reflect on the other ones automatically. I'd like to see more concrete plans for that. * We can avoid the majority of relationship clusters by linking to the official release in the artist's native language (presumably in their usual country of release). This point is a bit hazy to me. What about cases where the official release of a Japanese band is in English/Latin and someone creates a virtual Japanese/Kana duplicate? Artist's native language is problematic in my eyes. Of course you could say the English/Latin one is the official release and therefore everything links there. But what if there are several official ones of which none can be seen as most native? This might sound theoretically but I think identifying the main release can be problematic. Expanding on the last point, there will still be some cases where clusters would be possible, but focusing on those is silly. We currently have thousands of transliterations which are lacking a relationship because a handful of examples (which, in some cases, are just theoretical) are tricky to handle. I would like to hear more about those tricky examples. :) I guess they have been discussed to death before... sorry, didn't read the other threads. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
Hi again, to sum it up so far: there have been no vetoes but some discussion that put parts of this back to the RFC stage, so I'll split it as follows... I propose adding CoRelationshipAttribute to EngineerRelationshipType (the main type, not all sub types) and within that to the sub type for mixers, and adding ExecutiveRelationshipAttribute to EngineerRelationshipType (again the main type only) as proposed by Schika. For this I let the veto phase open for another 48 hours. If someone thinks we need to clarify those two sub roles first (that is to write the wiki pages for those attributes to exactly describe them), feel free to veto. Note that the following discussion arose from this: Schika had examples of liner notes which differentiate between a mixer and a mix engineer. Do we need that separated? Also he stated a difference between recorded by and recording engineered by again. I think all this needs a new thread so feel free to start one. ;) For the proposed changes of adding GuestRelationshipAttribute to OrchestraRelationshipType and ConductorRelationshipType I feel there definitely is need for more discussion to clarify what this attribute is about in general (wiki page needs to be written) so I abandon the request for those changes. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: new AR type is the predecessor of
Chris Bransden wrote: On 14/06/06, derGraph [EMAIL PROTECTED] wrote: For cases where an artist only changed it's name we might use a more general renamed to/was previously known as AR. i'm not so sure such cases would be indexed as seperate artists anyway. see http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-May/002840.html and related discussion Ok, stepping in a bit late again, sorry. I would prefer a general type which can mean both simple name changes and name changes combined with line-up / style changes (I don't like that style thing though since it is subjective, so I don't think it should go into the style description for that type). And right as Don said it, we don't need any rules then which cases this is allowed for and which not but simply delegate this problem to the question Are those different band names allowed to have separate entries or not?. If they are, we use this relationship, if they are not then they are to be merged - you see, the problem is solved very simply by moving the discussion to another place. ;) Then my reasoning for why I think we need one type only: One reason is that I think the types get too diverse and complex - we would expect too much from the users. And for those who're going to say that's a lame reason, here's the other one: I'm not sure if you can clearly separate those two types in every case, I think they overlap too much. Some bands changed their name several times before they became popular under a certain name and often you don't have enough info about style changes / line-up changes. I know several cases offhand where the bands released demos or even official albums under their older names and *I'd* prefer having those as separate artist entries to be more accurate (not only for tagging) - even if the line-up stayed the same. Btw: and interesting case is Dream Theater who released older demos *after* they changed their name from Majesty to Dream Theater and thus the demos contain both band names: http://dt.qrayg.com/bootlegs/pre-dream-theater/the-official-1986-demo - http://www.ytsejamrecords.com/ProductCart/pc/viewPrd.asp?idcategory=6idproduct=11 I'll stop before I'm going too off-topic. ;) Oh and: I'll not veto, see this as a too late answer to the discussion phase. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Freetext crediting (Was: RFV: Adding some AR attributes)
Chris Bransden wrote: On 14/06/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Of course since we don't have freetext crediting like Discogs we can only render liner notes to a certain extent and I'd normally say try to find those types which are nearest to what they really did - but since in most of the cases we can't know what they really did, we can only go with the liner notes for those smaller roles and therefore I also prefer to see it as close to the liner notes as possible. That does not apply for all AR types though - in some cases you *can* know what the credited persons really did. For example liner notes for rock albums mostly say guitars by ..., bass by ... where they mean electric guitar and electric bass guitar. Of course it's not wrong to let it as guitars as those are generalisations. i agree. i'd still like to have free-text qualifiers (pipe dream...), for the occasions when a new AR isn't appropriate, but it's still nice to show the written credit as well as the actual role - eg http://www.discogs.com/release/535757 (look at some of those convoluted track credits!) Ok, I decided to open a new thread since this is interesting but off-topic from the RFV. :) The big advantage of AR compared to freetext crediting is that we can clearly define the semantics of every type. The disadvantage is that we cannot cover every possible case. Perhaps a combined solution would make sense: selecting a general AR type and having a free text field for the details (*). I often state the exact details of the credit in the moderation note or use the album annotation for cases we can't cover exactly yet. I also use the annotation for things we can't describe at all with AR - for example drums recorded at studio XY by YZ from T to S or engineer for studio A: X, engineer for studio B: Y or choir/strings/orchestra arranged by ..., conducted by Some of them need additional types / type extensions, some would need three-directional AR types, some are just strange. :) (*) http://bugs.musicbrainz.org/ticket/1142 would make that possible. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
Don Redman wrote: On Sat, 10 Jun 2006 22:50:21 +0200, Simon Reinhardt wrote: However, is that an addition, an agreement or a veto? ;) Was there I don't know because I must admit, that I have really lost track of the latest discussions on mb-style. If there has not been such a discussion, then a requesto for veto might be a bit too early. It might be better to ask for comments first, and then, when either the discussion has stalled, or drifted off into the fundaments of MB, which you do not want to tackle with this proposal, to propose the changes a second time (maybe altered) and request a veto. However, if there was a discussion and I have just missed it, then please link to it. There has been no discussion but please note that those are simple separate questions for small additions to AR types. Schika's additional comments can be seen as separate new questions. Those kind of changes even have been decided on IRC before, some AR editors don't use the mailing list way or other communication channels at all... - as you can see I don't. But I'm not pressing this thread into a certain form by calling it RFV instead of RFC because I think we are all disciplined enough to work on this in an open form. I'm open to additions and I'm open to counter positions (called veto here). I just called it RFV because it does not ask for a bigger change nor touch more general issues. There have been threads labelled with RFV which did that - perhaps you want to step on their toes too. I hope we can stay on topic now and not let this drift into a Sommerloch-discussion about form questions. Thanks, Simon ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
Chris Bransden wrote: more of a general comment, but are you implying that 'guest' means any performer who isn't a member of the group in question? only i've always thought of 'guest' only being appropriate when it's written as such in the liner. eg a studio guitarist isn't a 'guest', but some famous guitar player probably would be. and 'guest orchestra' seems unlikely in liners, unless they normally have a different orchestra as part of the band :) Right from the description of the attribute: guest This attribute indicates a 'guest' performance where the performer is not usually part of the band. I think this is quite clear. ;) http://wiki.musicbrainz.org/PerformerRelationshipType says: While guest designates performers who are not usual members of the group that performed, say, the whole album, but only appear on one track. There's still no distinct definition for it though, not even a wiki page. But that would be talk about the meaning of the attribute itself then. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Adding some AR attributes
Hello,
I would like to add some attributes to some AR types and therefore request
ok/veto for each of them:
1. http://wiki.musicbrainz.org/OrchestraRelationshipType could need
http://wiki.musicbrainz.org/GuestRelationshipAttribute
- {orchestra} orchestra {additionally} performed becomes {orchestra} orchestra
{additionally} {guest} performed
2. http://wiki.musicbrainz.org/ConductorRelationshipType could need
http://wiki.musicbrainz.org/GuestRelationshipAttribute
- {additionally} conducted becomes {additionally} {guest} conducted
Rationale for those two: well I have seen lots of guest orchestras being
credited in the liner notes of my albums. :)
3. http://wiki.musicbrainz.org/EngineerRelationshipType could need
http://wiki.musicbrainz.org/CoRelationshipAttribute (page does not yet exist)
- {additionally} engineered becomes {additionally} {co-}engineered
4. Same for the mix engineer (same wiki page):
- {additionally} mixed becomes {additionally} {co-}mixed
5. probably the other engineer types too
Rationale: we added the co attribute to http://wiki.musicbrainz.org/ProducerRelationshipType -
now I found someone credited as co-engineer and co-mixer in liner notes. I had added him with the attribute
additional but since we have the co attribute I think we could use it here too.
Simon (Shepard)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Adding some AR attributes
Schika wrote: I have some releases where is also mentioned executive engineer, recording engineer, mix engineer, remix engineer. executive engineer would be no problem to add too, since we also introduced that attribute for the producer type. Though recording engineered and mix engineered was just changed to recorded by and mixed by and the majority agreed it means the same... please not that discussion again. :) remix engineer - isn't that a remixer? However, is that an addition, an agreement or a veto? ;) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Altering (especially translating) lyricist
I guess noone cares? :/ Simon Reinhardt wrote: Hi, Bogdan earlier hinted at the many versions of songs in other languages [1]. Whether one wants to link those to the original versions or not is one question (thinking in NGS I wouldn't use the OtherVersionRelationshipType because it's not only a different recording but also has altered lyrics - and my request for renaming this AR type is still open anyways ;) [2]). What I would like to have though is a way to link the translator of lyrics. Apart from the examples Bogdan pointed out, I have 4 such cases in my collection and they all credit it like that: Music by: [original composer], lyrics by: [original lyricist], translated by: [translator]. For now I just linked the original composer and lyricist as usual and linked the translator with additionally wrote the lyrics for. My questions: Does it make sense to have an AR type for this? Or can it be included as an attribute in the LyricistRelationshipType? Or should we think more general and try to find something that also includes other forms of altering lyrics (parody, translation+parody, ...)? By the way: I don't think any of those types should have a language attribute. This is actually an attribute of the track and not the AR - similar as described in [3]. Greets, Simon [1] http://lists.musicbrainz.org/pipermail/musicbrainz-users/2006-April/011847.html [2] http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-April/002290.html and http://bugs.musicbrainz.org/ticket/1389 [3] http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-April/002291.html ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Altering (especially translating) lyricist
Hi, Bogdan earlier hinted at the many versions of songs in other languages [1]. Whether one wants to link those to the original versions or not is one question (thinking in NGS I wouldn't use the OtherVersionRelationshipType because it's not only a different recording but also has altered lyrics - and my request for renaming this AR type is still open anyways ;) [2]). What I would like to have though is a way to link the translator of lyrics. Apart from the examples Bogdan pointed out, I have 4 such cases in my collection and they all credit it like that: Music by: [original composer], lyrics by: [original lyricist], translated by: [translator]. For now I just linked the original composer and lyricist as usual and linked the translator with additionally wrote the lyrics for. My questions: Does it make sense to have an AR type for this? Or can it be included as an attribute in the LyricistRelationshipType? Or should we think more general and try to find something that also includes other forms of altering lyrics (parody, translation+parody, ...)? By the way: I don't think any of those types should have a language attribute. This is actually an attribute of the track and not the AR - similar as described in [3]. Greets, Simon [1] http://lists.musicbrainz.org/pipermail/musicbrainz-users/2006-April/011847.html [2] http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-April/002290.html and http://bugs.musicbrainz.org/ticket/1389 [3] http://lists.musicbrainz.org/pipermail/musicbrainz-style/2006-April/002291.html ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: new AR type is the predecessor of
derGraph wrote: Does anyone have any objections on creating such an AR? Which wording should we use? (I'd prefer the predecessor / successor combination.) Is there something we should think about? Does this only apply to groups? If so the phrase should reflect this. If not then what does it mean for persons? Legal name changes? I prefer handling this with a separate AR type. This has cluster problems when combining it with performance names though. How restricted should this type be? If there is a major line-up change involved, perhaps also a contract change with the label, then is this different from a simple name change (for example for legal reasons) or when a group just starts printing a different name on their releases (alias?)? Of course on such an AR only the begin date applies. An end date would imply that the band renamed back to the original name. This can only be restricted by guidelines+voting unfortunately. All ARs have a begin+end date. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: new AR type is the predecessor of
Aaron Cooper wrote: I think this would be a step in the right direction. I look forward to the day when we can see a band's entire discography on one page, despite name changes :) This is a good example for evaluating relationship data (one of derGraph's favourite topics ;)). And also a typical case for my Clouds proposal but well, people misunderstood this as tags and forgot it. :P No, but seriously, evaluating relationships will become more and more important in the future I think. Greets, Simon ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Localisation of SubTitleStyle: space before colon
Hi, I came across this tracklisting which has both grouping titles and named parts: http://www.apreslachute.com/paroleslc.htm Tracks with grouping titles use SubTitleStyle and thus (excluding the named parts) you get Triae Ademptionis Pilae: Crux Via for track 2 for example. Though this is French and in French there has to be a space before the colon. So I did it like that: http://musicbrainz.org/showalbum.html?albumid=519922 (btw: please check French capitalisation ;). The same applies for release titles of course, I had seen a French release with a sub title which was written with : too. So my questions: Do you agree applying French language rules here? Should http://wiki.musicbrainz.org/SubTitleStyle mention this? Greets, Simon ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Localisation of SubTitleStyle: space before colon
Frederic Da Vitoria wrote: 2006/5/28, Simon Reinhardt [EMAIL PROTECTED]: Hi, I came across this tracklisting which has both grouping titles and named parts: http://www.apreslachute.com/paroleslc.htm Tracks with grouping titles use SubTitleStyle and thus (excluding the named parts) you get Triae Ademptionis Pilae: Crux Via for track 2 for example. Though this is French and in French there has to be a space before the colon. So I did it like that: http://musicbrainz.org/showalbum.html?albumid=519922 (btw: please check French capitalisation ;). Well, actually, this would be Latin. *sigh* Ok! But there are French titles like this. Please think abstract, this was just to show what I mean. ;) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] song / [untitled] vs. non-album tracks
Hi, I noticed a little contradiction on the wiki. On http://wiki.musicbrainz.org/NonAlbumTrack it says: quote Tracks hidden in other tracks: * Another kind of HiddenTracks are those where a single (very long) track has music, then a long silence (or noise), followed by one or more (different) pieces of music. Since there is no support for TrackSections, these can be entered as non-album tracks, although there is not complete consensus on this. /quote Though http://wiki.musicbrainz.org/UntitledTrackStyle says: quote [...] When they appear on a track that also has a listed song, this rule has to be used in combination with MultipleTitleStyle, e.g. track 13 (http://musicbrainz.org/showalbum.html?albumid=28611). /quote So do we both title the track on the album song / [untitled] _and_ add the untitled part as a non-album track? IMHO this case needs to be removed from NonAlbumTrack. Perhaps there is no real support for TrackSections but MultipleTitleStyle is a good workaround. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] song / [untitled] vs. non-album tracks
Chris Bransden wrote: however i must say i hate the mutilation of track titles for hidden tracks - song / [untitled] looks horrific IMO. they should be just left as they are - [untitled] should only be used when the entirity of the track is untitled (ie, use [untitled] rather than no title at all) So do I. You can never clearly say if a piece still belongs to the current song or if it's something new. This is not bullet proof enough in my eyes. But we have been voted down on this. :( Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] song / [untitled] vs. non-album tracks
Ok, following the consensus I edited: http://wiki.musicbrainz.org/NonAlbumTrack?action=diffrev2=10rev1=9 http://wiki.musicbrainz.org/HiddenTrack?action=diffrev2=7rev1=6 Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Are major performers still required in the album titles of classical music?
Maurits Meulenbelt wrote: I believe that that styleguide indeed precedes AR, but for the moment I would prefer keeping that info in the album title, at least until the Tagger tags AR info, because I like to have that information on my computer. When the tagger is more mature I agree that it would be neat to have that info in AR only, and show the info (maybe when you hover your mouse over the album title in the list) in the album list. The problem I can see with this: the webinterface can't differentiate between classical albums and pop albums for example. So if you hover over a pop album then should it also show the line-up? all of it? Band and guest artists? I don't know if we want that. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Are major performers still required in the album titles of classical music?
Age Bosma wrote: Simon Reinhardt wrote: Maurits Meulenbelt wrote: I believe that that styleguide indeed precedes AR, but for the moment I would prefer keeping that info in the album title, at least until the Tagger tags AR info, because I like to have that information on my computer. When the tagger is more mature I agree that it would be neat to have that info in AR only, and show the info (maybe when you hover your mouse over the album title in the list) in the album list. The problem I can see with this: the webinterface can't differentiate between classical albums and pop albums for example. So if you hover over a pop album then should it also show the line-up? all of it? Band and guest artists? I don't know if we want that. What about displaying only (if available) 'conductor' and 'orchestra'? With maybe one additional important field as well. This would basically rule out most, if not all, non-classical releases and only the most important info required for distinction will be displayed instead of all. Yeah and then you have the Metallica album which they performed together with an orchestra. And a piano player interpreting classical music. ;) I don't think you could follow simple rules for such a feature, there's a big grey area. Alternatives: - release artist = main performer (stone him! ;) ) - an attribute in the ARs signifying whatever you want it to signify (similar to the conflict that (feat. ...) does not always require a performance AR and a performance AR does not always require (feat. ...)). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Update of ProducerRelationshipType
Hi! I just updated http://wiki.musicbrainz.org/ProducerRelationshipType to include attributes for describing roles of co-producers, executive producers and co-executive producers as per common consensus. This closes ticket http://bugs.musicbrainz.org/ticket/1173. Have fun editing. ;) Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] WriterRelationshipType
Chris Bransden wrote:
New AR time!
artist {additionally} {guest} wrote {lyrics:lyrics for}OR{music:
music for} album or track
To me the writer of the music was always the composer.
Simon (Shepard)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] AR philosophy
Hi, I have some questions about linking philosophy which I think need to be generally clearified because if every moderator follows their own concepts then we don't have consistent data. 1. Link performers to releases: a) always, including members of bands b) only if they are guest performers / are the line-up for a project or solo-album of an artist. 2. Link artists to releases when they performed on / wrote / engineered / otherwise worked on: a) all tracks / the whole release b) the majority of tracks c) one track and more. 3. For different releases of one album, link all artists to: a) all of them b) the original releases only (including special editions being released at the same time as regular editions) c) the regular original release only. - How do we link special editions to regular editions if they were released on the same day? 4. Link artists to tracks they worked on: a) always b) only if there isn't a relationship of the same type between artist and release already. Spoiler warning! ;) My own approach at the moment is: 1. b) 2. a) 3. d) := the release I own ;) 4. b) but I am unsure and tend to other approaches from time to time. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Co-ProducerRelationshipType
Chris Bransden wrote:
On 28/04/06, Simon Reinhardt [EMAIL PROTECTED] wrote:
derGraph wrote:
I would still favour
artist {additionally} {co-}{executive }produced album or track,
but I'm not sure whether the space after executive is valid, or if it
can be replaced with {executive:executive }.
Yes, with {executive:executive } it is possible. Additional
co-executive producer, hehe. Whoever finds that in some liner notes
will receive 5 bars of finest chocolate from me!
I think now we outlined nearly every possible solution. Could everyone
please tell what they prefer? I want to see this closed...
i prefer artist {additionally} {co-}{executive:executive }produced
album or track but like i said, i'm not particularly bothered about
their being a potential impossible combination (additional
co-executive producer), and i think it's better to have that 'risk'
and keep all attribs in the same place.
Ok, I can agree here. We can always regulate combinations by style guidelines
on the relationship type page.
Request for veto!
Simon (Shepard)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] AR philosophy
mud crow wrote: 2. Link artists to releases when they performed on / wrote / engineered / otherwise worked on: a) all tracks / the whole release b) the majority of tracks c) one track and more. d) only the tracks they are credited as having worked on. Which can be very time consuming and tedious adding track level ARs, but I think it's incorrect to credit an artist as working on a whole release if they didnt actually work on every single track. That would be a) then. Re-read the phrase. :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Co-ProducerRelationshipType
Chris Bransden wrote:
i don't really understand what that does but if it works go right ahead :)
On 28/04/06, derGraph [EMAIL PROTECTED] wrote:
Simon Reinhardt wrote:
Chris Bransden wrote:
ProducerRelationshipType
* New: artist {additionally} {co-}produced album or track
ExecutiveProducerRelationshipType
* artist {co-}executive {co-}produced album or track
That does not work with AR, it could only produce artist executive
produced album or track or artist co-executive co-produced album or
track.
I might be wrong, but it should be possible to solve this problem using
artist {coex:co-}executive {copro:co-}produced album or track
Damn you top-responders. ;)
That *would* be possible but it is way to complicated in my eyes. You had to select the executive producer
subtype and would then see two checkboxes: coex and copro (well the attribute names could be
made a bit longer) and wouldn't know what they do until you complete the edit. Also this does not make them exclusive.
So someone could select both and produce artist co-executive co-produced album or track.
Can we please come up with a _simple_ solution that makes everyone happy?
Simon (Shepard)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ideas on improving Style Council decissions
Don Redman wrote: IMVHO we need to clarify the current process of solving a style issue, and document it so well that *anybody* can follow the process. If we develop some tools that help, that's even better. I invite everybody to mercilessly edit StyleCouncil, HowToProposeNewGuidelines, ChecklistForStyleChanges, StyleIssue and create additional pages like HowToSolveStyleIssues, HowTheStyleCouncilWorks etc. I will join in once I have finished moving. I tried to write down the current mechanisms introduced by you in a algorithmic way. But it's not yet perfect so before I touch the wiki pages I want some brainstorming on it: Style issue resolving: 1. Person P detects an issue and decides it needs to be discussed and solved. 2. Person P creates a new ticket for the issue, formulates a description and posts it to mb-style. The issue is now in the discussion phase for a period T of time. Possible solutions are discussed on the mailing list. P can support the discussion process by summing up arguments regulary. 3. a) If a solution is proposed within this period of time (this can also be done in the initial phase by person P), it is written down to a wiki page (for guidelines and relationship types for example) and eventually implemented on test.mb.org (for relationship types). Go to 4. b) If T elapses before a solution is proposed, a reminder is sent (by a demon?) and P has to do whatever is to be done to lead discussions in a direction of a possible solution (that is sum up arguments, bring discussion back to topic or revive discussion if it died). Go to 2. for another period T'. 4. Now begins the test phase. The community tries to check if the proposed solution is doing its job for a period S of time. 5. a) If within this period of time there is criticism about the proposed solution, the discussion phase may start again for another period T' of time. Though the proposal may be adjusted in easy cases and the test phase can start again immediatly for another period S' of time. b) If S elapses go to 6. 6. Person P does a last request for vetos. This can be for 48h or something. Any person X can do a veto but has to bring up good reasons for it. A veto can either lead to the discussion phase again or to a call for a decision of the evil style overlord. How this is done exactly has to be further clarified. Note: - An issue may have sub-issues which are to be handled separatly. - P is considered the owner of the issue. Though others may be seconders of it and can help summing up discussions, writing wiki pages, implementing, requesting vetos, etc. A tool may help controlling the different phases and keep discipline. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] new relationship type parody
Don Redman wrote: On Sun, 23 Apr 2006 22:28:41 +0200, derGraph wrote: And now, wait 48 hours? I bet that's enough time for me to forget about this thread. ;-) That's a serious problem. Anyone has an idea how this could be avoided? And it's a general problem of MB. Problems are either forgotten or discussed to death or not discussed at all or discussions go off-topic. We discuss around things and don't have formal proceedures on making decisions (like a voting system). Perhaps this deserves a new thread, I don't know, but I think we should collect ideas on how we could better the situation. My spontaneous idea is the following: We need more secretaries who are willing to do some work. When a new problem arises on the style mailing list, one of the secretaries goes to add a ticket to the style issues section on trac and either sets the owner to her-/himself or to CC. Then they are responsible for keeping discussions about this issue alive until it is solved. During discussions they also have the job of summing up arguments, seeing if consensus is reached and if no consensus is in sight, report it to Robert. Does that sound doable? Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Changing OtherVersionRelationshipType to OtherRecordingRelationshipType
Adam Golding wrote: i was discussing this in one of the classical threads--i repaste my suggestion here: I must say, I'm a bit confused by your proposal and don't understand all of it, probably because it's very classical-related. Again I'm pointing to the plans for the NextGenerationSchema (I wish more people would read it so we would have a better basis for discussing): http://wiki.musicbrainz.org/ObjectModel and especially the older page http://wiki.musicbrainz.org/TrackGrouping probably help you in realising what should belong where. Though what I'm trying to put through here is just a change of terms in OtherVersionRelationshipType (and to extend it to releases). No change in the meaning, because it already *is* about re-recordings (at least that's what the wiki page and the AR description say). Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Changing OtherVersionRelationshipType to OtherRecordingRelationshipType
Hey,
so to sum it up:
Bogdan said {live} and {acoustic} make not much sense in the relationship since
they should be track attributes and I agree.
Then I just found an album-album AR type live performance by chance (created because of
http://bugs.musicbrainz.org/ticket/980) which is not yet documented on the wiki. I could use this as a base
for my proposed album-album type release has later recording(s) release, luks just checked it,
it's only used once. And since albums have a release type live I don't think we need the
information that something is a _live_ recording of something else here either.
So what I would change is:
- change Track is the earliest version of Track, Track is a later version of
Track
to Track has later recording(s) Track, Track is a later recording of Track
- change Release is a live performance of Release, Release was performed live as
Release
to Release has later recording(s) Release, Release is a later recording of
Release
and update the one case using the live stuff since the direction of the type
changes.
- update http://wiki.musicbrainz.org/OtherVersionRelationshipType accordingly
and rename it to http://wiki.musicbrainz.org/OtherRecordingRelationshipType
There were no objections so far. Are there now? :)
Simon (Shepard)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Changing OtherVersionRelationshipType to OtherRecordingRelationshipType
Bogdan Butnaru wrote: On 4/25/06, Simon Reinhardt [EMAIL PROTECTED] wrote: - change Release is a live performance of Release, Release was performed live as Release to Release has later recording(s) Release, Release is a later recording of Release and update the one case using the live stuff since the direction of the type changes. No objections to this. But I remember there is a release is remaster of release relationship, a release is the earliest release of release and I'm not sure but I think there's another similar one. It might be a good idea to write them all together with descriptions and differences; I'm a bit fuzzy on their precise meanings. You mean similar to http://wiki.musicbrainz.org/RemixMeansDifferentThings ? Yeah that could be useful I guess. Another thing I realized: the wording of Track is the earliest version of Track and Track is a later version of Track suggests that they can be used to link _any_ version of two tracks with the same name; this would include remixes, alternate versions, etc. Yes, but reading the description and the wiki page this is not the case. The description says it *only* is about re-recordings. And that exactly is the reason why I want to change it. :) I don't know what is another version should mean anyways. Either a song is remastered or edited (making it shorter for radio etc.) from the original audio data or remixed (mostly taking the end result as a source for the remix I think) or a new recording is made. But you're right, I guess we need to collect some border cases to make it clearer. Also I think we need to note that CoverRelationshipType overrules OtherVersionRelationshipType. It never occured to me to use it this way, I only used it (at most a couple of times, actually) for identically-named tracks on re-releases and such. For that you should use http://wiki.musicbrainz.org/SameTrackRelationshipType I guess. :) So, to sum up: a couple of lists of these similarity relationships, one for tracks and one for releases, with diferences explained and exemplified, I think would make the issues much more clear (it seems right to me, but blurry...) I'm not an expert on sound engineering. Anyone? Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Clarification of instrumental track info
Steve Wyles wrote: However, the guess case function does correct Inst. to instrumental. So, although not discussed in the styleguides, I would say there is nothing wrong with including that information if it exists. Of course it handles this. Because we all agree it's absolutly legal and should be kept if it is version information. So this is no argument for keeping it in every case. derGraph wrote: Are we discussing what the current style guide says about (instrumental), or are we discussing to change the style guide? In the first case, the answer is pretty clear: [1] says (on the bottom of the page) the following details should be left out: [...] Any other information not discussed in the OfficialStyleGuidelines. Instrumental tracks are not discussed in any official style guideline. No, it is not so clear. Appart from my opinion about this line in the styleguidelines (stupid) one could argue that, following the style principles [2], artist intent overrules this - since it is not even a strong guideline. And I'm very much for seeing (instrumental) as artist intent as it can clearify the general intended concept of the artists in a tracklisting. Another nice example: I tried to remove such info myself once, not much thinking about it I guess: http://musicbrainz.org/showmod.html?modid=2992630 And for the sake of completeness, here's the cover: http://193.138.231.156/~cover/?fCall=ShowImagevId=130399vType=Back Oh yes, it is written in a smaller font! We should of course only keep it if it's written in the exact same font as the track title. ;) Seriously, in my opinion this is conceptually intended. Simon (Shepard) [1] http://wiki.musicbrainz.org/ExtraTitleInformationStyle [2] http://wiki.musicbrainz.org/StylePrinciple ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] To the Spanish speakers
Hi, this is about a style issue but I also want to reach as much people as possible, so I'm crossposting to mb-users. After a long time where we did not have Spanish capitalization standards at all, people had finally created http://wiki.musicbrainz.org/CapitalizationStandardSpanish. It's one of the most complex capitalization standards we have and not easily applicable for non Spanish speakers. The problem is though that I now get told things like this: http://musicbrainz.org/showmod.html?modid=4586479 So dear Spanish people, can you in any way confirm that and can you please finally come to a decision? :) Simon (not understanding a word of Spanish) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] LiveTrackStyle
[EMAIL PROTECTED] wrote: What about implementing annotations on the track level (NATs first, but why not for other tracks as well)? I think this would be a more elegant solution to the problem where to put location, dates (or generally: categorization) of NATs. The downside is, that this information would not be easily available for tagging. Yes, please! http://test.musicbrainz.org/trac/ticket/1259 Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] LiveTrackStyle
derGraph wrote:
I like Chris' idea of copying he annotation data into the comment tag.
However, this doesn't seem to be possible, since the annotations are
multi-line text which allow wiki markup. However, we might add a
single-line text field, some kind of mini-annotation, where only a
limited set of information should be stored. Of course, we'd need to
insert another Picard option to replace / append / leave the comment
fields ('append' might be impossible to implement, though), since some
users might want to leave their comment tags as they are.
Yet another option? :) No, tagger script should do exactly that. But well, I
guess development talk about this can wait until we (if ever) actually have
track annotations.
And when I asked for annotations to be included in the webservice I was told
they're not useful there...
I like the idea of mini annotations. This would be the perfect place for
titled parts of songs, because they are often too long to be added to the track title
(example: http://musicbrainz.org/album/63ae8f9b-af38-4a41-a1fd-e2b26c55ac4e.html).
Simon (Shepard)
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] change 'Recording Engineer' to 'Recorded By'
Hi, any objections against http://test.musicbrainz.org/trac/ticket/54 ? I will wait some days and then edit it. :) Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] change 'Recording Engineer' to 'Recorded By'
Steve Wyles wrote: On Sat, 25 Mar 2006, Simon Reinhardt wrote: Hi, any objections against http://test.musicbrainz.org/trac/ticket/54 ? I will wait some days and then edit it. :) I think that would cause confusion. Frequently the phrase Recorded By is understood to refer to the artist that performed it. Well, some liner notes say something like additional drums recorded by ABC in XYZ studios where ABC is the drum player. But mostly the guy sitting behind the consoles when the musicians are performing is credited with recorded by. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
