th1rtyf0ur | 17 Nov 08:57 2014

Musical quotation/lyrical references (STYLE-348)

Huey Lewis' "I Want a New Drug" came up on shuffle a while back & I
noticed the guitar solo at the end quoted the lead riff of "Purple Haze",
and realized there's currently no AR to specify such a relationship, as it
doesn't really fit under any of the existing relationships. I started
typing up a new feature request & realized this could be applied to lyrics
as well, including indirect references, e.g. The Beatles' "Glass Onion"
referring to other Beatles songs like "Strawberry Fields Forever" and "I
Am the Walrus" (Megadeth does the same kind of thing in "Victory").

Not sure exactly how the new BDFL workflow is gonna go, but I figured it
wouldn't hurt to post a link to the feature request here for input as
well. :) Particularly, if this should be only for work-work relationships,
or if recording-work ARs should be added as well- I can think of a large
number of live recordings that include brief quotes from other songs that
seem too short to be listed as "partial live cover"... But then, in the
case of the Huey Lewis example, should it really be a work-work AR if the
shorter version (~3:32 radio/video edit; full version is ~4:46) doesn't
include the snippet? Or is "partial cover of" more appropriate there, even
if it is only a single guitar line?

Refs:
AR proposal: http://tickets.musicbrainz.org/browse/STYLE-348
Wiki (w/ classical & jazz examples): https://en.wikipedia.org/wiki/Musical_quotation
Huey Lewis' "Purple Haze" tease: https://youtu.be/3ZwQRCkKxNE?t=4m16s
The Beatles' "Glass Onion": https://en.wikipedia.org/wiki/Glass_Onion#Lyrics
Megadeth's "Victory": http://www.darklyrics.com/lyrics/megadeth/youthanasia.html#12
Trevor Downs | 8 Nov 00:48 2014
Picon

Re: Series and bundles (humble indie bundle for example)

I made a series (http://musicbrainz.org/series/4e4ad619-1b26-48d1-8bda-98f0241e1908) to collect all Humble Bundle releases (though I’ve been bad about updating it), it seemed less trouble than to actually create a series for each bundle.

On Nov 7, 2014, at 3:15 PM, Daniel Sobey <dns-VNHec/tJ5s+HXe+LvDLADg@public.gmane.org> wrote:

Hi List,

I'm wanting some advice on how best to add series information to music distributed in bundles.
For example humble indie bundle has a bundle of games and this usually includes sound tracks and works.
There are other bundles around the place such as vodo.net and Indie Roayale that follow the same model.

Should I :
1. Create a series for each bundle ie "Humble indie bundle 13"
2. Create a series for each bundle, plus an overall bundle for anything from that comes from humblebundle.com with each release in both series.
3. Create a ticket to allow for series to series relationships to create a tree of series.
    This would allow for an overall humble bundle series and this could link to each weekly bundle series.
4. Series are not meant for this type of thing and i should not do anything.

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Daniel Sobey | 8 Nov 00:15 2014
Picon

Series and bundles (humble indie bundle for example)

Hi List,

I'm wanting some advice on how best to add series information to music distributed in bundles.
For example humble indie bundle has a bundle of games and this usually includes sound tracks and works.
There are other bundles around the place such as vodo.net and Indie Roayale that follow the same model.

Should I :
1. Create a series for each bundle ie "Humble indie bundle 13"
2. Create a series for each bundle, plus an overall bundle for anything from that comes from humblebundle.com with each release in both series.
3. Create a ticket to allow for series to series relationships to create a tree of series.
    This would allow for an overall humble bundle series and this could link to each weekly bundle series.
4. Series are not meant for this type of thing and i should not do anything.



_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
David Gasaway | 29 Oct 23:11 2014

Re: Style for classical track titles (STYLE-344)

On Wed, Oct 29, 2014 at 12:47 PM, Frederic Da Vitoria
<davitofrg@...> wrote:
>
> I'm all for removing standardization on classical track titles (apart from
> prepending the work name as recommended in your draft).

Not I.  I would like *some* consistency from release to release.

> If a user wants to use
> some kind of standardization, let him do it too.

If that's what users want, so be it, but there was a time when
MusicBrainz actually made it easier to tag my classical files.  In a
way, it differentiated MusicBrainz from other databases like Discogs
or CDDB.

--

-- 
-:-:- David K. Gasaway
-:-:- Email: dave@...
caller#6 | 29 Oct 20:53 2014
Picon

Re: Style for classical track titles (STYLE-344)

On 10/29/2014 12:47 PM, Frederic Da Vitoria wrote:
2014-10-29 19:39 GMT+01:00 Nicolás Tamargo de Eguren <reosarevok-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
Forgot to mention, also, that part of the idea is to get rid of http://wiki.musicbrainz.org/Style/Specific_types_of_releases/Opera at the same time, since that basically only says "put as much info as possible on opera track titles, even if not on the release" which seems to mostly go against what we're moving towards with NGS.

I'm all for removing standardization on classical track titles (apart from prepending the work name as recommended in your draft). As long as all the tracks of a release use a consistent formatting, no problem.

Does that mean you disagree with standardizing the separators? (i.e. colon for parts, dot for movements)

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Nicolás Tamargo de Eguren | 29 Oct 20:52 2014
Picon

Re: Style for classical track titles (STYLE-344)


On 29 Oct 2014 21:49, "Frederic Da Vitoria" <davitofrg-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> 2014-10-29 19:39 GMT+01:00 Nicolás Tamargo de Eguren <reosarevok-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>:
>>
>> Forgot to mention, also, that part of the idea is to get rid of http://wiki.musicbrainz.org/Style/Specific_types_of_releases/Opera at the same time, since that basically only says "put as much info as possible on opera track titles, even if not on the release" which seems to mostly go against what we're moving towards with NGS.
>
>
>  BTW, your draft always puts the work first. In some releases (mostly compilations), I believe I saw the work name in the track title, like "Allegro from Symphony ##" or "Allegro (Symphony ##)". I'm not sure we should ask to standardize those.

That's already there :)

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Nicolás Tamargo de Eguren | 29 Oct 19:32 2014
Picon

Style for classical track titles (STYLE-344)

While we have guidelines for release titles and track artists, we never got a guideline for classical track titles. So far most people are following the format of the data already there (and thus the existing pre-NGS conventions). That's mostly fine, but it should still be codified, and slightly adapted to take the existence of works into account (which allow tracks to follow the release a bit better).


Right now it does not mention movement numbering at all. That's intentional (I feel 1. vs. I. is fairly minor and can be left to people's preference or used as on the release) but if people think it should be standardised, we can do that too, probably with one of the following:

a) "For movement numbers, use roman numerals followed by a dot ("I. Allegro").
b) "For movement numbers, use whatever the release has, followed by a dot (both "I. Allegro" and "1. Allegro" are equally acceptable)

(or something without the dot requirement, I guess, I just like the dot :) )

--
Nicolás Tamargo de Eguren
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
caller#6 | 26 Oct 07:13 2014
Picon

STYLE-331 recap

---------
Recap
---------

Okay, so STYLE-331 was meant to be a way to link 2-in-1s to their "parts".

This was going to be the first of 3 (maybe?) similar relationships. 
Examples:

     [release group b]<includes>[release group a]:
     "This 2-in-1/box/whatever includes these previous albums/EPs/whatever."

     [release]<includes>[release group]:
     "This reissue includes this EP/whatever as bonus tracks".

     [release]<contains>[release]:
     "This multi-disc set (or box) is also available as separate discs 
w/ same catno, barcode etc. "

---------------------
Complications
---------------------

As KRSCuan pointed out, it might be confusing and/or error-prone to have 
three very similar relationships.

His suggestion IIUC is to have only one, release<>release-group, which 
could cover the first two cases (with a tiny bit of redundancy but much 
less room for error) and ignore the third.

Also, to some extent this depends on the fate of "STYLE-335: Add "Box 
set" as a primary type of Release Group"

----------------
My opinion
----------------

I can see the merits of both courses. And maybe the third case isn't 
common enough to really matter?

------
Link
------

Ticket: http://tickets.musicbrainz.org/browse/STYLE-331
bflaminio | 24 Oct 06:00 2014
Picon

RFV: STYLE-330 Make 2-on-1 (or generically, M-on-N) release groups "Compilations"

Expected end of RFV: 2013-11-01 00:00 UTC
Jira Ticket: http://tickets.musicbrainz.org/browse/STYLE-330
RFC:
http://musicbrainz.1054305.n4.nabble.com/RFC-Make-2-on-1-or-generically-M-on-N-release-groups-quot-Compilations-quot-td4667103.html

The proposal is to remove the line "A release containing two albums and/or
EPs." from the official style guide and associated documents. 

(1) https://musicbrainz.org/doc/Style/Release_Group#Secondary_types
(2) http://musicbrainz.org/doc/Release_Group/Type

--
View this message in context: http://musicbrainz.1054305.n4.nabble.com/RFV-STYLE-330-Make-2-on-1-or-generically-M-on-N-release-groups-Compilations-tp4668964.html
Sent from the MusicBrainz - Style mailing list archive at Nabble.com.
Nicolás Tamargo de Eguren | 20 Oct 21:00 2014

Concertmaster relationships (STYLE-328/STYLE-341)

A lot of orchestral releases give information on the orchestra's leader/concertmaster for that recording. Similarly, orchestra sites fairly often provide information about the concertmaster position. As WP says, "The concertmaster [...] is the second-most significant person in an orchestra" - so we probably should allow to record this information. For that I'd like to add artist-recording and artist-release "concertmaster" relationships, similarly to the conductor ones, plus a "concertmaster" attribute to the artist-artist "member of" relationship, to relate the people to the orchestras (since concertmasters are usually first violin or whatever, but in any case a member of the orchestra).

Does anyone feel any of the two changes would be problematic, and if so, why and what would be a better way of storing this info?

_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Nicolás Tamargo de Eguren | 19 Oct 19:42 2014
Picon

Changes to our style process (Important)

Hi! So, this has already been posted to the blog, but for those here who don't read the blog, I'll repost:

At the MusicBrainz Summit last month in Copenhagen, one of the topics to
be discussed was the state of the style guidelines and style process.
One thing those present agreed on was that the process was in need of
reform, for several reasons: the complexity of the process,
inconsistency with other processes in the project, the high level of
individual commitment required to make changes, long-running discussions
without conclusion or followthrough, and ultimately the state of the
final product, the style guidelines themselves. The inaccessibility of
our existing process meant that many users, both new and old, avoided
the style process, and this hurts the project: style is part of what
makes MusicBrainz what it is, and low participation means our guidelines
have grown both internally inconsistent and out of sync with community
practice. Nor is the style process a new problem for MusicBrainz:
historically, it’s changed several times and some past style leaders
have vanished into thin air.  After all, it is a hard job, for a
volunteer, to convince many voices to come to a consensus.

To improve upon these issues, we’ve decided to make two major changes.

First: to designate our JIRA issue tracker at tickets.musicbrainz.org as
the central coordination point for style issues. This way, any issue, be
it style-related or code-related, is reported and discussed in the same
place (and should an issue be misfiled, it’s easily corrected). The
issue tracker can also collect links to other discussions, in edit
notes, the forums, IRC, etc., and store links to related issues such as
features in need of implementation.

Second: to promote our current Style Leader to Style Benevolent Dictator
For Life (Style BDFL). Nicolás Tamargo (reosarevok) will then be in
charge of considering tickets and implementing changes in the style
guidelines. This change shifts the burden of evaluating style issues
from the community to our newly appointed BDFL. For simple changes and
for simple improvements to consistency and writing style, the BDFL can
change things directly, without need for lengthy discussion. Of course,
his work won’t happen in a vacuum: for changes that are complex or
contentious, the role of the BDFL will be to gather feedback and
determine the next steps before making changes. To this end, he may
occasionally call for a non-binding vote on a particular topic, to
collect a snapshot of community opinion to augment existing discussion,
all in order to make a better informed decision.

We hope that this new process will make contribution to the creation of
style guidelines easier and less onerous a commitment for everyone, and
that the resulting style guidelines will be more up-to-date, more
consistent, and more clearly written and organized. To test it out,
we’re going to try this process for 6 months, and then review how things
have progressed and if the process needs further tweaking or even
complete replacement.

tl;dr: Style system has changed, new info at http://musicbrainz.org/doc/Proposals
_______________________________________________
MusicBrainz-style mailing list
MusicBrainz-style@...
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Gmane