Re: [mb-style] Why do we expand abbreviations?
I'm in favor of keeping some degree of standardization here though I don't really care if volume is expanded or abbreviated. There are many series where volume numbering is not done consistently, e.g. with all variations of vol(ume) x in various capitalizations with or without dot, space or leading 0, with arabic or roman numbers, added or dropped subtitles, ... These variations may be there between different volumes of a series. Bad style but not necessarily something that MB has to fix. But they may also be there between different sources of information about the same release (e.g. between website, cover art and ID3 tags of an MP3 VA compilation) or even between different pieces of cover art of the same release. In these cases, the variations become our problem and this guideline reduces ambiguity. Example: http://www.discogs.com/release/2918247 Front cover and CD label show Pop Wave and Volume 2, the spine says Pop Wave, Vol.2 and More Hits From The Fantastic 80s. Separation of title, volume number and subtitle is done by placement (front, CD) or using different fonts and colours (spine). Even though this overall style is quite consistent for the entire series I'm sure the individual releases would end up with all kinds of different title styles if there was no guideline. We might even get duplicates just because an editor couldn't find the release under the title that he was expecting it to have. As a side note here are some examples for inconsistent naming and volume numbering within series: https://musicbrainz.org/series/5d4c21f7-9193-4798-9257-b6f9e4f90cac https://musicbrainz.org/series/fbe1844c-7cf4-4c6f-9f62-e194fd50c7df https://musicbrainz.org/series/0ce2bc89-5719-4d8d-b2d5-1ca337babe9d Not sure how these would look like if we didn't have the volume numbering guideline... -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Why-do-we-expand-abbreviations-tp4670862p4670929.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] Cover Art Style Guide
+1 for having a guideline. Some other things to cover there are: - valid file formats - no watermarked images - resolution: min. 500x500 (with exceptions: downloads that only come with lower resolution cover art, rare physical releases where gogling only provides some low-rez scans, ...) - no image distortion or rotation, no artifacts (like a photo with reflection from camera flash) (similar exceptions as before) - images should be cropped to the cover edge - type assignment (e.g. back+spine) - content of the comment field (nothing like my scan, from google, pixel size etc.; page X for booklet pages; ...) - ordering (front, booklet, media, tray, back) -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Cover-Art-Style-Guide-tp4670869p4670930.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] Cover Art Style Guide
I broadly agree with a lot of this (below) but much of it feels like a how-to and recommendations On 16 Jan 2015 09:08, MeinDummy meindu...@nurfuerspam.de wrote: +1 for having a guideline. Some other things to cover there are: - valid file formats - no watermarked images There's a watermark flag if it's all that can be got - resolution: min. 500x500 (with exceptions: downloads that only come with lower resolution cover art, rare physical releases where gogling only provides some low-rez scans, ...) - no image distortion or rotation, no artifacts (like a photo with reflection from camera flash) (similar exceptions as before) - images should be cropped to the cover edge These seem like good suggestions but doesn't need cannonising. If they aren't so good they can be replaced. - type assignment (e.g. back+spine) - content of the comment field (nothing like my scan, from google, pixel size etc.; page X for booklet pages; ...) - ordering (front, booklet, media, tray, back) I prefer the discogs order http://www.discogs.com/help/submission-guidelines-images.html or the one MusicBrainz attributes are presented: front then back (along with the spine they're the first two bits you would normally see and most often present in the db) ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Cover Art Style Guide
16 januari 2015, MeinDummy meindu...@nurfuerspam.de skrev: +1 for having a guideline. Some other things to cover there are: - valid file formats - no watermarked images - resolution: min. 500x500 (with exceptions: downloads that only come with lower resolution cover art, rare physical releases where gogling only provides some low-rez scans, ...) - no image distortion or rotation, no artifacts (like a photo with reflection from camera flash) (similar exceptions as before) - images should be cropped to the cover edge - type assignment (e.g. back+spine) - content of the comment field (nothing like my scan, from google, pixel size etc.; page X for booklet pages; ...) - ordering (front, booklet, media, tray, back) Another thing is the labelling of items. For instance a scan of the first and last page of a booklet on a CD. The first page is the cover, but should it be put as cover if it only contains the cover ir should that be only for images that actually are the cover and nothing else? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Why do we expand abbreviations?
On Fri, Jan 16, 2015 at 10:35 AM, MeinDummy meindu...@nurfuerspam.de wrote: I'm in favor of keeping some degree of standardization here though I don't really care if volume is expanded or abbreviated. There are many series where volume numbering is not done consistently, e.g. with all variations of vol(ume) x in various capitalizations with or without dot, space or leading 0, with arabic or roman numbers, added or dropped subtitles, ... These variations may be there between different volumes of a series. Bad style but not necessarily something that MB has to fix. But they may also be there between different sources of information about the same release (e.g. between website, cover art and ID3 tags of an MP3 VA compilation) or even between different pieces of cover art of the same release. In these cases, the variations become our problem and this guideline reduces ambiguity. Hi! Yup, I agree that it's reasonable to have some degree of standardising in a series. But something like If a series isn't fully consistent for their volume numbering, use the most common style for all of the entries would be enough for that I feel (in some cases that could change with time, but that's not really that connected to the vol. thing - it could change as much if they use tome or book or edition or even a full typed volume, and editors can then decide whether to change old entries or continue with the old style). Subtitles are different, and I don't feel we need to do anything about those - they should just be added if they're there, not added if they're not, is my feeling :) -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Preferred way of adding festivals held on sparse dates and other things related to events guidelines
Hi, ATM I'm adding data for an upcoming series of concerts that will be held on my hometown [1] and I'm not sure if I should link them together using a parent Festival event or if I should use a Series instead. The fact is the concerts will span two weeks (January 30-February 7), but only on some days of the week (Fridays, Weekends and one Thursday). So, should we handle these cases using a parent Festival event (even if most days on the interval between the begin and end dates will have no events at all) or should we use a Series event for linking the sparse events together? I would go with the first approach (and even I've started to convert a festival I entered earlier as a Series into parent-child event ARs [2]), but I would like to hear opinions in favor of one way or another. Also, are there any plans for a guideline for events, or are there any guidelines for them that I'm unaware of? - Things like title standarization, when/how to use parent-child events, how to set dates etc etc. - I've also concerns about the data duplication that happens on festivals when artists can potentially be linked 2 to 3 times (on the day they perform, on a child event for the artist performance itself and on the parent event that links each festival day together). [1] http://www.gijonrockcity.com/xrc-xixon/xrc-magazine-8232%3Bfestival-gijon-rock-city-5%BA-aniversario-programa8232%3B8232%3B_101_496.php [2] https://musicbrainz.org/series/87d5cd83-6197-42b3-b760-acb7feaaff0d/edits ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Preferred way of adding festivals held on sparse dates and other things related to events guidelines
On Fri, Jan 16, 2015 at 1:38 PM, Héctor Arroyo churr...@hangar18.cc wrote: Hi, ATM I'm adding data for an upcoming series of concerts that will be held on my hometown [1] and I'm not sure if I should link them together using a parent Festival event or if I should use a Series instead. The fact is the concerts will span two weeks (January 30-February 7), but only on some days of the week (Fridays, Weekends and one Thursday). So, should we handle these cases using a parent Festival event (even if most days on the interval between the begin and end dates will have no events at all) or should we use a Series event for linking the sparse events together? I would go with the first approach (and even I've started to convert a festival I entered earlier as a Series into parent-child event ARs [2]), but I would like to hear opinions in favor of one way or another. If they're considered all parts of the same festival, adding them as such seems perfectly ok to me :) Festival series are there to join different years of the same festival, not parts of a specific year. Also, are there any plans for a guideline for events, or are there any guidelines for them that I'm unaware of? - Things like title standarization, when/how to use parent-child events, how to set dates etc etc. - I've also concerns about the data duplication that happens on festivals when artists can potentially be linked 2 to 3 times (on the day they perform, on a child event for the artist performance itself and on the parent event that links each festival day together). Please enter STYLE tickets in Jira for things you want me to look at, and I can do that (it's perfectly fine to have discussion here about the issues as well though, so people: feel free to discuss these things! The idea is that the artist should be linked to the specific day, and a list of artists per day will later be displayed on the parent event (like we show work relationships on recording pages). This hasn't happened yet though, but it's the plan :) I would only add child events for one artist inside the day if they're needed for a specific reason (to link it to a tour, or something like that). I do agree though that we need some conventions (and probably guidelines) for the whole thing, so I'm happy to hear other people's opinions on the matter! -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Preferred way of adding festivals held on sparse dates and other things related to events guidelines
On 16 Jan 2015 11:38, Héctor Arroyo churr...@hangar18.cc wrote: I've also concerns about the data duplication that happens on festivals when artists can potentially be linked 2 to 3 times (on the day they perform, on a child event for the artist performance itself and on the parent event that links each festival day together). On a similar point, should we link recordings and releases to events or just some? ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Preferred way of adding festivals held on sparse dates and other things related to events guidelines
On Fri, 2015-01-16 at 13:23 +, Tom Crocker wrote: On 16 Jan 2015 11:38, Héctor Arroyo churr...@hangar18.cc wrote: I've also concerns about the data duplication that happens on festivals when artists can potentially be linked 2 to 3 times (on the day they perform, on a child event for the artist performance itself and on the parent event that links each festival day together). On a similar point, should we link recordings and releases to events or just some? The general guideline I've been following (and I've been adding a LOT of Events and Places, due to my work on adding YouTube videos of contra dances) is to only add an Event or Place if I can link it to more than one recorded-music-related entity (i.e. Recording, or Release). I know there is an idea out there of trying to copy artists whole event schedules into MusicBrainz (and I don't oppose that) -- but for my use, I limit myself to only adding Events (and Places) that I need to link together other otherwise unconnected entities. And I also regularly have limited information, so I'll have to attach a Recording to a whole festival Event, rather than a specific day, if I don't know what day it was recorded on. And I'll create an Event for a specific workshop at a festival if and only if I have multiple recordings of that particular workshop. Examples: http://musicbrainz.org/event/df98dc93-82c2-4fdf-a552-b96b16d1d354 NEFFA http://musicbrainz.org/place/118adfc7-fcad-4438-bfd8-a7df853b9720 Concord Scout House Further discussion (and guidelines) would be lovely. Jesse ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
