Nicolás Tamargo de Eguren | 2 Feb 13:50 2015
Picon

Step and half brother data. Do we really want this?

Hi! 

Ages ago (before my style time) an RFC passed to implement "step" and "half" attributes for the sibling relationship, and "step" for the parent/child one. This was never implemented, and there's a ticket for it still (well, 5...) at http://tickets.musicbrainz.org/browse/STYLE-9

I personally feel this is overkill and have no interest in it, but do other people feel this is useful?

--
Nicolás Tamargo de Eguren
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Jim Duke | 19 Jan 16:38 2015
Picon

Question on Release Artist

This release has a Release Artist of Goran Bregović who is an artist and his name is featured on the cover.  But for this release he is the producer.

As I understand it this release should really be attributed to the special artist Various Artists; not Goran Bregović.  But his name being the front cover gives me pause.
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Héctor Arroyo | 16 Jan 12:38 2015

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).

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
MeinDummy | 16 Jan 10:05 2015
Picon

Re: 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.
Bill Purosky | 15 Jan 03:40 2015
Picon
Picon

Re: Cover Art Style Guide

For mine, I number all the pages in the book style booklets and I label the fold out type "obverse" and "reverse".  I'd like to see some guidelines also so we can all get on the same page.

Examples:
http://musicbrainz.org/release/e7c31322-9108-4452-8f85-7871edfd7d9a/cover-art
http://musicbrainz.org/release/a1097a97-2e4a-4749-9454-7389d477815c/cover-art
On 1/14/2015 10:48 AM, Ross Tyler wrote:
I too think that one should be able to reproduce the booklet viewing experience using MB as a source. To that end, each of my booklet comments describes the form factor of the booklet (e.g., card, bi-fold, tri-fold, saddle-stitched) and the index of the image taken from it (e.g. cover, inside/outside, 1, 2, 3). I do not attempt to paginate my indeces but, rather, try to keep the presented to the user as the user would see them in front of them. This means that a saddle stitched booklet cover is often presented as just the MB types "Front, Booklet" but the whole cover (as experienced by the user by unfolding it would be Front,Booklet "saddle stictched, cover". If a {bi,tri,x-fold}, I usually call this "x-fold, outside" (fully unfolded) with the other side "x-fold, inside (fully unfolded)". For the remainder of a saddle stitched booklet, I simple number the inside spreads (as a user would experience the *physical* booklet), indexed by 1, 2, 3, etc (e.g. "saddle stitched, 1" for the first inside spread). I purposefully don't split a spread into pages (because, often, that is not the way it intended to be consumed) or use booklet page numbers (because the don't lend any useful reassembly information). I simply comment on what part and what type of booklet.

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Rachel Dwight | 14 Jan 03:10 2015
Picon

Re: Cover Art Style Guide


On Jan 13, 2015, at 6:25 PM, Jim Duke <james.enoch.duke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Please correct me if I'm wrong (and I'm very likely to be wrong).  I've poured over the style guide and couldn't find a style guild pertaining to Cover Art.  I can find how-to's.  I can find advice.  But not in the official style guide.  That seems to leave the rules for Cover Art somewhat vague.

We don’t really have a style guide for cover art. We do have http://musicbrainz.org/doc/How_to_Add_Cover_Art which contains a few recommendations (e.g. scanning around 300 dpi; this is mostly for practicality reasons).

Sure, most releases don't have booklet art.

If you mean digital releases, then yes. Most of the physical media I have have some sort of booklet.

  But of those that do, there seems to be two camps.  One camp has one image for each page.  And another camp captures two pages at once (except for the front and back).  I suppose that I could detect it by examining the height vs width ratio.

I can’t speak for every case, but a lot of times that has to do with the thickness of the booklet. On most CD releases the booklet is thin enough that you can scan 2 pages at once and the image will be readable, but some are so thick that if you try to scan 2 pages at once (especially on the first and last pages) the center of the image will be blurry and distorted.


But in any case, we should have a discussion on which way is preferred, or if both is allowed, or if we need to enhance the schema to better indicate the kind of image it is.  It seems, however, that the results of this discussion should be captured in the style guide.

Has this been discussed before?  I've tried searching the archives; but "Cover Art" sweeps in far too many items that have nothing to do with Cover Art.

I’m not aware of it being discussed in mb-style before. It has been brought up in IRC and in the forums (namely this thread: http://forums.musicbrainz.org/viewtopic.php?id=4308)


Also - not that I want to change it just to change it - just making an observation.  It seems that "Cover Art" is somewhat too narrow a description.  "Artwork" would seem to be a better label for the category in general; or even "Imagery”.

The term is a holdover from when music was mostly distributed on physical media. Now with digital distribution the sense of a physical “cover” has been lost but accompanying images are still a thing. “Artwork” might be good in this sense. I’ve added releases with accompanying wallpapers, sketches and stuff; these would not traditionally be deemed “cover art” but they were packaged with the audio nonetheless.


From the ranks of terribly-confused-but-trying-to-help.
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style-VWJlPdIPk9unah5wVhspdpv38IJrVKKD@public.gmane.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Rachel Dwight | 14 Jan 01:49 2015
Picon

Re: Cover Art Style Guide


On Jan 13, 2015, at 6:25 PM, Jim Duke <james.enoch.duke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:

Please correct me if I'm wrong (and I'm very likely to be wrong).  I've poured over the style guide and couldn't find a style guild pertaining to Cover Art.  I can find how-to's.  I can find advice.  But not in the official style guide.  That seems to leave the rules for Cover Art somewhat vague.

I don’t think we have a style guide proper, just a few recommendations (e.g. scan at 300 dpi).

Sure, most releases don't have booklet art.

Huh? Most of the releases I have have some form of booklet (aside from digital ones)
.
  But of those that do, there seems to be two camps.  One camp has one image for each page.  And another camp captures two pages at once (except for the front and back).  I suppose that I could detect it by examining the height vs width ratio.

But in any case, we should have a discussion on which way is preferred, or if both is allowed, or if we need to enhance the schema to better indicate the kind of image it is.  It seems, however, that the results of this discussion should be captured in the style guide.

That will be tricky. I usually gauge whether I want to scan one or two pages at a time by the thickness of a booklet. Most are thin enough that you can scan two pages at once and the resulting image will be readable, but some are so thick that if you try to scan two pages at once the resulting image will be blurry and distorted.


Has this been discussed before?  I've tried searching the archives; but "Cover Art" sweeps in far too many items that have nothing to do with Cover Art.

It’s been brought up a few times, mainly in IRC and http://forums.musicbrainz.org/viewtopic.php?id=4308. I don’t think we’ve ever had a lengthy discussion about it in mb-style before.


Also - not that I want to change it just to change it - just making an observation.  It seems that "Cover Art" is somewhat too narrow a description.  "Artwork" would seem to be a better label for the category in general; or even "Imagery”.

Yeah, that might be more feasible, especially for digital releases where the artist bundles image files with the music.


From the ranks of terribly-confused-but-trying-to-help.
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style-VWJlPdIPk9unah5wVhspdpv38IJrVKKD@public.gmane.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Duke Yin | 14 Jan 02:12 2015
Picon

Re: Cover Art Style Guide

One camp has one image for each page.  And another camp captures two pages at once (except for the front and back). ... we should have a discussion on which way is preferred, or if both is allowed
Of course both are allowed. So are tetromino foldouts:

I can't imagine an easy way to "enhance" the schema that would give you the functionality you want while still allowing valid cover art.  (Measuring the aspect ratio won't get you there either - what if the booklet is a (deck of) card(s), and it's physically impossible for the front and back of the card to be side-by-side?)

"Cover Art" sweeps in far too many items that have nothing to do with Cover Art. ... It seems that "Cover Art" is somewhat too narrow a description.  "Artwork" would seem to be a better label for the category in general; or even "Imagery".
https://wiki.musicbrainz.org/Cover_Art/Types doesn't look to me like it sweeps in any image types that have "nothing to do with Cover Art".  Do you have some example MB Releases where you believe the cover art does not belong?


On Tue, Jan 13, 2015 at 7:25 PM, Jim Duke <james.enoch.duke-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
Please correct me if I'm wrong (and I'm very likely to be wrong).  I've poured over the style guide and couldn't find a style guild pertaining to Cover Art.  I can find how-to's.  I can find advice.  But not in the official style guide.  That seems to leave the rules for Cover Art somewhat vague.

I ask this because I'm planning to enhance XBMC (Kodi), to have a booklet browser function enabling you to examine the "Booklet" that is associated with the Album you're listening to (or one you're just looking at).  Sure, most releases don't have booklet art.  But of those that do, there seems to be two camps.  One camp has one image for each page.  And another camp captures two pages at once (except for the front and back).  I suppose that I could detect it by examining the height vs width ratio.

But in any case, we should have a discussion on which way is preferred, or if both is allowed, or if we need to enhance the schema to better indicate the kind of image it is.  It seems, however, that the results of this discussion should be captured in the style guide.

Has this been discussed before?  I've tried searching the archives; but "Cover Art" sweeps in far too many items that have nothing to do with Cover Art.

Also - not that I want to change it just to change it - just making an observation.  It seems that "Cover Art" is somewhat too narrow a description.  "Artwork" would seem to be a better label for the category in general; or even "Imagery".

From the ranks of terribly-confused-but-trying-to-help.

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style <at> lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Jim Duke | 14 Jan 01:25 2015
Picon

Cover Art Style Guide

Please correct me if I'm wrong (and I'm very likely to be wrong).  I've poured over the style guide and couldn't find a style guild pertaining to Cover Art.  I can find how-to's.  I can find advice.  But not in the official style guide.  That seems to leave the rules for Cover Art somewhat vague.

I ask this because I'm planning to enhance XBMC (Kodi), to have a booklet browser function enabling you to examine the "Booklet" that is associated with the Album you're listening to (or one you're just looking at).  Sure, most releases don't have booklet art.  But of those that do, there seems to be two camps.  One camp has one image for each page.  And another camp captures two pages at once (except for the front and back).  I suppose that I could detect it by examining the height vs width ratio.

But in any case, we should have a discussion on which way is preferred, or if both is allowed, or if we need to enhance the schema to better indicate the kind of image it is.  It seems, however, that the results of this discussion should be captured in the style guide.

Has this been discussed before?  I've tried searching the archives; but "Cover Art" sweeps in far too many items that have nothing to do with Cover Art.

Also - not that I want to change it just to change it - just making an observation.  It seems that "Cover Art" is somewhat too narrow a description.  "Artwork" would seem to be a better label for the category in general; or even "Imagery".

From the ranks of terribly-confused-but-trying-to-help.
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Jim Duke | 14 Jan 00:47 2015
Picon

Multiple alternate translations for track names and release titles

I have a fairly large collection of classical releases that provide multiple translations of the release title, and for each track.  For example, the following entry is somewhat illustrative of this:

https://musicbrainz.org/release/e153542f-6fa9-43cf-a92d-d2889b6b4d2b

I include it because it has a fairly complete collection of cover art.

The track names are all in English; which is appropriate for this release since the dominant language of the release is English.  However, alternative translations are provided on the release.

I think it would be good to add alternate translations for titles and track names, where such translations are provided in the release.  I'm not sure how the schema would need to change to accommodate it.  But it seems, from a style policy perspective that we should be able to capture the provided track translations.

So, in the above example, track one would be:

[English]: The Planets, op. 32: Mars, the Bringer of War.  Allegro
[German]: Die Planeten, op. 32: Mars, der Kriegsbringer.  Allegro
[French]: Les Planètes, op. 32: Mars, le porteur de la guerre.  Allegro
[Italian]: I Pianeti, op. 32: Marte, il portatore di guerra.  Allegro

The system would allow all 4 provided translations; and make the English one the default (since that is the dominant one in the release).

Thoughts?


_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Nicolás Tamargo de Eguren | 13 Jan 23:48 2015
Picon

Why do we expand abbreviations?

Hi! I'm considering dropping the "Abbreviations should generally be expanded" guideline, or at least un-generalising it. 

https://wiki.musicbrainz.org/Style/Titles/Abbreviations provides the following rationale: 

"Abbreviations can be ambiguous, and by that we mean that one single abbreviation can mean several different words when expanded. This issue becomes very important when dealing with multi‐lingual words; for example, the word “Volume” and “Volumen” are both abbreviated to “Vol.” and there is no way to tell which expansion is correct without doing further research. As we intend to support other languages in future, we should make entries as unambiguous as possible for easy manipulation at a later date."

That... makes very little sense. We already support other languages in beta, but we're not planning to translate release titles automatically or anything (was that ever a plan?). 

So I was wondering - is there any actual reason we're even doing this, except that "because we've been doing it a long time"? Discuss :)

--
Nicolás Tamargo de Eguren
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Gmane