Category: Style Guidelines

New Guidelines for Recordings

We got this from Ben, who has been in charge of taking this discussion forward:

Since the beginning of the year there has been a lot of discussion about recordings and what exactly they should be used for. After several meetings on IRC and a couple of huge topics on the style mailing list, we’re finally ready to bring in a new definition for recordings, and new style guidelines to go with it!

The new recording definition can be viewed at http://musicbrainz.org/doc/Recording

And the accompanying style guidelines are at http://musicbrainz.org/doc/Style/Recording

The new guideline brings significant changes to the way recordings should be used, so all editors dealing with recordings should take the time to read it.

As a short summary, recordings are now never produced solely through copying or mastering. This means that recordings shouldn’t distinguish between different masters of some audio – in general, a recording will correspond a particular mix or edit. In addition:

– AcoustIDs and ISRCs have been removed from the guideline – they are mostly irrelevant for managing recordings under the new definition.
– Guidelines for audio channels have been introduced.
– Existing guidelines have been expanded.
– Several in-depth examples have been added to explain how recording should be used.

Also, as a result of these changes, the recording-recording remaster relationship type and the artist-recording master relationship type have been deprecated.

Thanks to everyone who was involved on mb-style and in the IRC meetings for your excellent ideas and contributions!

New Style Leader and Updated Proposal Process

Nicolás Tamargo (reosarevok) is replacing Kuno Woudt (warp) as style leader. This will allow Kuno to fully concentrate on development, and also allow our other style leader Nikki to dedicate more of her time to testing changes and make it less likely for us to have botched releases.

We are also updating the proposal process, and tying it to the Jira tracker, to avoid the manual updating of the proposal table and problems with two people using the same proposal number by mistake. The updated system is at Proposals – the huge table there has been moved to Proposals/History

Please welcome our new Style Leader: Nikki

The MusicBrainz Style Leader has a really hard job — this position requires people to to have a thick skin, a deep understanding of MusicBrainz and the patience of a saint. Its a really challenging job! And because of this, people burn out fast and generally abandon their jobs after a while. This has been the pattern for many years for us and its been very frustrating. And now its has happened again: Brian, the Style Leader up til today, has not been responding to me. I’ve not heard anything from him in weeks.

In an effort to try and break out of this cycle, I am going start a new experiment: Make the Style Leader a paid position.

While we have some money in the bank, its not massive amounts of money and the pay for this position reflects just that. Its not a whole lot of money, but I am hoping its enough money to offset the pain of being the Style Leader and will keep the Style Leader engaged over a longer period. With that in mind, I am proud to announce that Nikki will be our next Style Leader and our first paid Style Leader.

Nikki has been tasked to ensure that the style process moves along and is properly documented. Her goal is to drive consensus among the brainerz who participate in the important Style process and to keep proposals on track. Once a proposal’s RFC/RFV periods are up, its Nikki’s job to ensure that the proposal is acted upon by the appropriate people. She should also help to keep the style process evolving as the MusicBrainz style needs evolve.

Thank you for all your hard work Brian! I look forward to working with you more closely Nikki!

BTW: Warp will still be involved in helping Nikki lead the style process, but his focus is on NGS for the time being. We’re very much dedicated to staying focused on delivering NGS as soon as we can.

Release groups & ISRCs: Please help us test this release!

We’ve hammered out many of the rough edges from the upcoming release and now we need your help to test the release to spot any problems that may have slipped past our new code review process.

New in this release:
– Release groups: This allows us to group same titled releases from one artist that have slightly different track lists into release groups. For instance, here is a Weezer release group that has many separate releases in it. We have converted as many batches of releases to release groups as we automatically could, but there are tons left to do. We’ll need your help!
– ISRC support: We can now track ISRC codes. While this is less useful to end users, our commercial customers have been asking for this for eons.
– WikiDocs: Our WikiDocs system now uses our new Mediawiki to pull documentation from.
– Bug fixes from our last release.

Aside from a good chunk of the bug fixes, all of these things are now live on our test server. Please report bugs to our bug tracker and make sure to select the “Server: ReleaseGroups, ISRCs, Bug Fixes” milestone so we can spot your bugs fast. Also take a look at the bugs we’ve already closed for this release and which ones are still outstanding.

We have one major known issue, where some release groups may be found in the search engine, but will give a “release group not found error” (example). This is a known bug.

Finally, do the release groups as we have them now make sense to you? There are a few things that may not be entirely clear, so we’re looking for feedback how to make things more clear before we release this on May 24th.

OperaTrackStyle in beta period

Those who participated to it’s elaboration feel OperaTrackStyle is stable. We have now reached the next phase: the users who feel like testing the new StyleGuide are invited to do so. Remember that we are still in beta phase: you shouldn’t do mass edits yet, but rather choose atypical edits which might reveal problems with … Continue reading “OperaTrackStyle in beta period”

Those who participated to it’s elaboration feel OperaTrackStyle is stable. We have now reached the next phase: the users who feel like testing the new StyleGuide are invited to do so. Remember that we are still in beta phase: you shouldn’t do mass edits yet, but rather choose atypical edits which might reveal problems with the new StyleGuide. Links to successful or problematic edits should be posted on this forum thread or in the mb-style mailing list.

Beta Period for Style Guidelines (aka Don's suggested new style evolution procedure)

In the last month the Style Council has worked on a couple of guidelines for classical music, and the first one of these is nearly ready: The OperaTrackStyle will describe how track titles for Operas should be written. There were also discussions about how to make the style-changing process simpler and less tiresome. Now Aaron … Continue reading “Beta Period for Style Guidelines (aka Don's suggested new style evolution procedure)”

In the last month the Style Council has worked on a couple of guidelines for classical music, and the first one of these is nearly ready: The OperaTrackStyle will describe how track titles for Operas should be written.

There were also discussions about how to make the style-changing process simpler and less tiresome. Now Aaron suggested to use “Don’s suggested new style evolution procedure” to make this new guideline official.

So, I suppose, I should explain a bit what that procedure would be. The explanation is attached as a podcast, since I still cannot type too much.

New AdvancedRelationship type for Transl*ated Titles

After many months of discussion, a new advanced relationship type for translated or transliterated titles has been created. This proposal hasn’t been fully implemented; a new Release Status for transl*ations that aren’t actual releases still needs to be implemented in the server (there is a vote on the Wiki for the best name for this), … Continue reading “New AdvancedRelationship type for Transl*ated Titles”

After many months of discussion, a new advanced relationship type for translated or transliterated titles has been created. This proposal hasn’t been fully implemented; a new Release Status for transl*ations that aren’t actual releases still needs to be implemented in the server (there is a vote on the Wiki for the best name for this), and there is still discussion on the -style mailing list about the need for explicit attributes marking translation vs. transliteration, but the basic AR, representing the parts of this proposal that have reached consensus, has finally reached the main server.

Thanks to everybody who participated (and is participating) in this very long and drawn out process.

Recent Updates to Style Guidelines

The Classical Release Artist Style passed an RFV last week. It provides for performers to be used as Release Artists for albums that would otherwise be listed under Various Artists (as there are multiple composers). Also added was a series-specific style for the “Promo Only” series. This is now the second Series Style Guideline (the … Continue reading “Recent Updates to Style Guidelines”

The Classical Release Artist Style passed an RFV last week. It provides for performers to be used as Release Artists for albums that would otherwise be listed under Various Artists (as there are multiple composers).

Also added was a series-specific style for the “Promo Only” series. This is now the second Series Style Guideline (the first was for the OverClocked ReMix (OCReMix) series).

"Top something" Playlists do not belong in MusicBrainz

Edit #5258089 has raised the issue how MusicBrainz should handle “XY’s Top 50” playlists or the like. After some discussion and a Request for Comments on the style mailing list, I have summarised the appearing consensus in this Request for Veto: Bootleg torrents that are compilations based on playlists of charts authorities (like Billboard’s) should … Continue reading “"Top something" Playlists do not belong in MusicBrainz”

Edit #5258089 has raised the issue how MusicBrainz should handle “XY’s Top 50” playlists or the like.

After some discussion and a Request for Comments on the style mailing list, I have summarised the appearing consensus in this Request for Veto:

Bootleg torrents that are compilations based on playlists of charts authorities (like Billboard’s) should not be stored in MusicBrainz as releases. These playlists are often copyrighted by their issuers.

This has now been accepted. Therefore the “releases” representing such playlists should be removed from MusicBrainz, unless of course there are real compilations out there.

The logic behind this, is that these are not actual releases. The information they hold is just that of a playlist and releases are used as a hack to store this information in MusicBrainz. These “releases” clutter up the discography pages and might even get MB into trouble because of copyright issues.

Concrete cases are the Billboard’s Top n of the year yyyy and the John Peel Festive 50.

I still have not found a good place to write this down in the wiki. Suggestions are welcome.

new official style guideline: SplitReleaseTitleStyle

The SplitReleaseTitleStyle has been made official. It describes how untitled split releases have to be named. Please read up on it and edit accordingly. Happy editing!

The SplitReleaseTitleStyle has been made official. It describes how untitled split releases have to be named. Please read up on it and edit accordingly.

Happy editing!