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
Nicolás Tamargo de Eguren | 4 Dec 12:41 2014

Defining how pseudo-releases should be used (STYLE-342)

Hi!

Something that has been stuck for quite a while is how to deal with pseudo-releases and duplication, at least until we have a way to just store the alternate info as part of the standard release. Some links to previous discussion can be found in http://tickets.musicbrainz.org/browse/STYLE-342

While my preferred solution to this (and that of at least a few other people) would be to just block fields like label, catno, barcode and dates in the code so that they can't be filled at all, I find the proposed solution from that ticket's first comment a fairly acceptable compromise: 

  • If a pseudo-release is linked to an original release, the pseudo-release should duplicate as little data as possible - it should generally only have the status, language and script, medium names, track names, track artists and of course the release name and artist since those are required. Any other data which can be taken directly from the original release should not be added to the pseudo-release (track times are probably acceptable).
  • If the pseudo-release is not linked to an original release (e.g. the original isn't in the database yet), it would be acceptable for data to be stored on the pseudo-release.
This ensures that we don't have to enter one pseudo per original release when the tracklists are the same anyway, keeps label entries etc. clean, and still allows people who can't enter the official version for some reason (because they can't read/type Japanese or whatever) to enter enough data so that their version can be later found and matched to the right original.

I'm going to be direct about this and say that unless I get very convincing arguments against this, I'll be eventually implementing something pretty similar to it as the guideline. That said, I'm happy to get suggestions on small improvements, changes, or just your reasoning for the idea being absolutely wrong :)

A note: I do know that Picard doesn't deal very well with this now (although see the last bits of that comment for a few things that soften it). But (apart from the general view that the data is the main goal and the software should adapt to it) we've been waiting to do something like this for ages in hope of Picard implementing better pseudo-release support and it never happened, so maybe doing this will finally make someone who cares about how this works in Picard write the relevant code :)
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Gmane