Difference between revisions of "User:LordSputnik/Random Stuff"

From MusicBrainz Wiki
(Replaced content with "__NOTOC__")
 
(11 intermediate revisions by the same user not shown)
Line 1: Line 1:
__NOTOC__
+
=Title=
 +
==Title 2==
 +
===Title 3===
 +
====Title 4====
 +
 
 +
=Locations=
 +
Each Location should be an entity. Locations should have a “parent” field – but not be relate-able to other locations (this would cause problems with a huge list of locations being listed on parent locations). Locations could be able to point to a location on Google Maps (like, for example, Facebook Places). Countries should not be locations – we have a set, defined list of countries already.
 +
 
 +
Location types:
 +
*Concert Venue
 +
*Recording Studio
 +
*Town / City
 +
*Region
 +
 
 +
For example:
 +
 
 +
*London would be a “Town / City” with no parent location. The country would be set to UK.
 +
*Abbey Road Studios would be a “Recording Studio”, having London, as a parent location, and UK set as the country.
 +
*Tenessee would be a “Region” location, with US set as country.
 +
*Nashville would be a “Town / City” location in Tenesse, with US set as the country.
 +
 
 +
 
 +
=Genres=
 +
Take the idea of tags, make it more formal, with pre-defined “tags” as entities, and allow attaching of these pre-defined tags to recordings and releases in a “Genres” field. Genres could even be added to releases and recordings in the same way as tags.
 +
 
 +
Adding genre entities would need to be limited – perhaps only add a genre if it was distinct enough to have its own Wikipedia page.
 +
 
 +
Each Genre should be an entity. Genres should be able to be related to other genres - “<genre1> is a sub-genre of <genre2>”, “<genre2> has sub-genre <genre1>”, (“<genre1> inspired <genre2>”? - sideways link).
 +
 
 +
Genre aliases should be used to direct users to the correct genre for their search entry, as for other entities. Genre “credits” should exist, and be kept intact if and when genres are merged.
 +
 
 +
Multiple Work-Genre ARs should be allowed per work.
 +
 
 +
 
 +
=Proposal Process=
 +
*No more than two weeks may elapse between the last message on an RFC and the start of an RFV. If there are more than two weeks since the last message in the RFC, a new post should be made on the RFC thread, restarting the RFC with a link to the latest version of the proposal and a new expected passage date.
 +
*The number of RFCs and RFVs with a end date some time in the future is limited to 5 at any one time, to allow all proposals to be properly considered by the list participants. New proposals made when 5 proposals are already active will be put on hold by the style leaders until other proposals finish (this is notified by a short message on the ML thread, and perhaps a change of status on JIRA).
 +
 
 +
 
 +
=CSG=
 +
We need a clear strategy on CSG. There isn't really one at the moment. I'd suggest breaking “classical” down into several smaller sections and developing guidelines for those – mb-style has shown that developing guidelines for just “classical” is difficult. We could perhaps have a “Common Classical” page, which lists conventions to be used across classical.
 +
 
 +
 
 +
=Track Groups (Needs revision)=
 +
 
 +
http://chatlogs.musicbrainz.org/musicbrainz/2012/2012-11/2012-11-02.html
 +
 
 +
*Instead of selecting a recording when adding a release, you select the work. The track is added to the work, which contains a long list of all associated tracks in some non-default tab.
 +
*The list of tracks is arranged into track groups, which correspond to specific versions of the work. Track groups each have a corresponding artist and optionally a description.
 +
*All works have a new field, called "original performer". This contains the artist(s) who originally performed the track. The system uses this field to designate some track groups as "covers".
 +
*When a track is added to a work, it gets put into the default track group for the track artist. The default track group is probably where most tracks on compilations would end up.
 +
*You can move a track between track groups, and make new track groups. A track group would be made for every significantly different version of a track. This includes notable remasters.
 +
*Tracks in a group can have varying lengths. The length is unimportant, as long as the portion of audio that is in a track is the same as other audio in the group.
 +
 
 +
For example:
 +
 
 +
==Song - "Waterloo"==
 +
 
 +
*Type: Song
 +
*Lyrics Language: English
 +
*Original Performer: ABBA
 +
 
 +
===Track Group by ABBA===
 +
*Track 1: 3:20 (from 1974 US vinyl "Ring Ring")
 +
*Track 2: 3:20 (from 1974 Swedish vinyl "Ring Ring")
 +
*Track 3: 3:01 (from 1999 CD "Best of the 70s")
 +
 
 +
===Track Group (single) by ABBA===
 +
*Track 1: 2:32 (from 1975 Swedish single "Waterloo")
 +
 
 +
===Track Group "2001 Remaster" by ABBA===
 +
*Track 1: 3:20 (from 2001 CD "Ring Ring")
 +
*Track 2: 3:21 (from 2002 CD "ABBA: The Complete 2001 Remasters")
 +
 
 +
===Track Group (cover) by Bjorn Again===
 +
*Track 1: 2:19 (from 1995 CD "Rung Rung")
 +
 
 +
----
 +
 
 +
There are no recordings here.
 +
 
 +
By default, "Waterloo" album tracks by ABBA will go in the top group, which is the default album track group. "Waterloo" tracks from singles by ABBA will go in the second group by default.
 +
 
 +
You can move tracks and merge tracks in edits after they've been added. Track groups can also be merged, created and split. In this case, the track group "2001 Remaster" by artist "ABBA" has been created by a user, and the two tracks in there have been moved there after they were added. Alternatively, there's an option when adding a release to put tracks in a specific group, to save editing afterwards, and to create a new group for the track. But these options are hidden by default.
 +
 
 +
The cover by Bjorn Again has its own group. This is the default group for the artist Bjorn Again, and all "Waterloo" tracks by Bjorn Again will go there. This group was automatically labelled cover, because the original performer is listed as ABBA.
 +
 
 +
A '''track group''' is a group of tracks.
 +
 
 +
----
 +
 
 +
===Recording Title Thingy===
 +
The recording name should be generally be the canonical name of the work being performed. If the recording is a remix, the name of the remix should also be included after the work name, in parentheses. If the recording isn't a performance, use the most common name for the recording.
 +
 
 +
 
 +
 
 +
=Formatting Examples=
 +
==Bold==
 +
===Recordings with different mastering===
 +
As mentioned in [[Recording]], in MusicBrainz, mastering is a process that is applied to '''recordings''' to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.
 +
 
 +
Following on from this, separate '''recordings''' should not be created for remastered tracks, since remastered tracks generally feature the original '''recording''' with different mastering applied. Remastering should be described using the [[Remaster_Relationship_Type|Remaster Relationship Type]] between [[Release|releases]], or in the '''release''' annotation where tracks are mastered differently across a '''release'''. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.
 +
 
 +
==Italic==
 +
===Recordings with different mastering===
 +
As mentioned in [[Recording]], in MusicBrainz, mastering is a process that is applied to ''recordings'' to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.
 +
 
 +
Following on from this, separate ''recordings'' should not be created for remastered tracks, since remastered tracks generally feature the original ''recording'' with different mastering applied. Remastering should be described using the [[Remaster_Relationship_Type|Remaster Relationship Type]] between [[Release|releases]], or in the ''release'' annotation where tracks are mastered differently across a ''release''. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.
 +
 
 +
==Bold Italic==
 +
===Recordings with different mastering===
 +
As mentioned in [[Recording]], in MusicBrainz, mastering is a process that is applied to '''''recordings''''' to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.
 +
 
 +
Following on from this, separate '''''recordings''''' should not be created for remastered tracks, since remastered tracks generally feature the original '''''recording''''' with different mastering applied. Remastering should be described using the [[Remaster_Relationship_Type|Remaster Relationship Type]] between [[Release|releases]], or in the '''''release''''' annotation where tracks are mastered differently across a '''''release'''''. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.
 +
 
 +
==All Links==
 +
===Recordings with different mastering===
 +
As mentioned in [[Recording]], in MusicBrainz, mastering is a process that is applied to [[Recording|recordings]] to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.
 +
 
 +
Following on from this, separate [[Recording|recordings]] should not be created for remastered tracks, since remastered tracks generally feature the original [[Recording|recording]] with different mastering applied. Remastering should be described using the [[Remaster_Relationship_Type|Remaster Relationship Type]] between [[Release|releases]], or in the [[Release|release]] annotation where tracks are mastered differently across a [[Release|release]]. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.
 +
 
 +
==Monospaced==
 +
===Recordings with different mastering===
 +
 
 +
As mentioned in [[Recording]], in MusicBrainz, mastering is a process that is applied to <span style='font-family: "courier","monospace"'>[[Recording|recordings]]</span> to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.
 +
 
 +
Following on from this, separate <span style='font-family: "courier","monospace"'>recordings</span> should not be created for remastered tracks, since remastered tracks generally feature the original <span style='font-family: "courier","monospace"'>recording</span> with different mastering applied. Remastering should be described using the [[Remaster_Relationship_Type|Remaster Relationship Type]] between <span style='font-family: "courier","monospace"'>[[Release|releases]]</span>, or in the <span style='font-family: "courier","monospace"'>release</span> annotation where tracks are mastered differently across a <span style='font-family: "courier","monospace"'>release</span>. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.
 +
 
 +
 
 +
==Monospaced Large==
 +
===Recordings with different mastering===
 +
 
 +
As mentioned in [[Recording]], in MusicBrainz, mastering is a process that is applied to <span style='font-family: "courier","monospace"; font-size:1.2em; font-weight:bold;'>[[Recording|recordings]]</span> to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.
 +
 
 +
Following on from this, separate <span style='font-family: "courier","monospace"; font-size:1.2em; font-weight:bold;'>recordings</span> should not be created for remastered tracks, since remastered tracks generally feature the original <span style='font-family: "courier","monospace"; font-size:1.2em; font-weight:bold;'>recording</span> with different mastering applied. Remastering should be described using the [[Remaster_Relationship_Type|Remaster Relationship Type]] between <span style='font-family: "courier","monospace"; font-size:1.2em; font-weight:bold;'>[[Release|releases]]</span>, or in the <span style='font-family: "courier","monospace"; font-size:1.2em; font-weight:bold;'>release</span> annotation where tracks are mastered differently across a <span style='font-family: "courier","monospace"; font-size:1.2em; font-weight:bold;'>release</span>. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.
 +
 
 +
=Freeform Entities=
 +
Entities which aren't created, but materialize. Editors write freeform tags, and these are converted into entities when they become popular enough. Freeform entities can be merged but not deleted. Power to the people!
 +
 
 +
Uses:
 +
* Genres
 +
* Instruments
 +
 
 +
==Example==
 +
I think Artist X should have the genre "Rock". So I type "Rock". The server goes off an searches the genre entities for "Rock". Search results are returned as for normal entities, in a drop down box for user selection. If no entities are found, the user can type whatever they like, and save.
 +
 
 +
Behind the scenes, this "tag" would probably be stored in a db table with other "nearly-entity" tags, along with a count of occurrences. As soon as this count exceeds a certain number, then entity is created, and the tag gets replaced by the entity.
 +
 
 +
So, if 10 other users added the genre to something as "Rock", then this might be created as an entity and allow merging/relationships.
 +
 
 +
If things like "Folk Country" and "Country Folk" existed, they might be merged, and one would be used as the search hint for the other.
 +
 
 +
It would also be possible to map these genre entities to a list, such as the id3v1 genre list, or iTunes's genre list. We'd simply have some sort of field for genre entities describing this mapping.
 +
 
 +
This could be extended to instruments - it effectively automates the existing system of "5 uses, then it gets added". We could use various relationships to structure the instrument/genre graphs however we like (eg. "<genre> is derived from <genre>" or "<instrument> is ancestor of <instrument>").

Latest revision as of 21:07, 2 September 2013

Title

Title 2

Title 3

Title 4

Locations

Each Location should be an entity. Locations should have a “parent” field – but not be relate-able to other locations (this would cause problems with a huge list of locations being listed on parent locations). Locations could be able to point to a location on Google Maps (like, for example, Facebook Places). Countries should not be locations – we have a set, defined list of countries already.

Location types:

  • Concert Venue
  • Recording Studio
  • Town / City
  • Region

For example:

  • London would be a “Town / City” with no parent location. The country would be set to UK.
  • Abbey Road Studios would be a “Recording Studio”, having London, as a parent location, and UK set as the country.
  • Tenessee would be a “Region” location, with US set as country.
  • Nashville would be a “Town / City” location in Tenesse, with US set as the country.


Genres

Take the idea of tags, make it more formal, with pre-defined “tags” as entities, and allow attaching of these pre-defined tags to recordings and releases in a “Genres” field. Genres could even be added to releases and recordings in the same way as tags.

Adding genre entities would need to be limited – perhaps only add a genre if it was distinct enough to have its own Wikipedia page.

Each Genre should be an entity. Genres should be able to be related to other genres - “<genre1> is a sub-genre of <genre2>”, “<genre2> has sub-genre <genre1>”, (“<genre1> inspired <genre2>”? - sideways link).

Genre aliases should be used to direct users to the correct genre for their search entry, as for other entities. Genre “credits” should exist, and be kept intact if and when genres are merged.

Multiple Work-Genre ARs should be allowed per work.


Proposal Process

  • No more than two weeks may elapse between the last message on an RFC and the start of an RFV. If there are more than two weeks since the last message in the RFC, a new post should be made on the RFC thread, restarting the RFC with a link to the latest version of the proposal and a new expected passage date.
  • The number of RFCs and RFVs with a end date some time in the future is limited to 5 at any one time, to allow all proposals to be properly considered by the list participants. New proposals made when 5 proposals are already active will be put on hold by the style leaders until other proposals finish (this is notified by a short message on the ML thread, and perhaps a change of status on JIRA).


CSG

We need a clear strategy on CSG. There isn't really one at the moment. I'd suggest breaking “classical” down into several smaller sections and developing guidelines for those – mb-style has shown that developing guidelines for just “classical” is difficult. We could perhaps have a “Common Classical” page, which lists conventions to be used across classical.


Track Groups (Needs revision)

http://chatlogs.musicbrainz.org/musicbrainz/2012/2012-11/2012-11-02.html

  • Instead of selecting a recording when adding a release, you select the work. The track is added to the work, which contains a long list of all associated tracks in some non-default tab.
  • The list of tracks is arranged into track groups, which correspond to specific versions of the work. Track groups each have a corresponding artist and optionally a description.
  • All works have a new field, called "original performer". This contains the artist(s) who originally performed the track. The system uses this field to designate some track groups as "covers".
  • When a track is added to a work, it gets put into the default track group for the track artist. The default track group is probably where most tracks on compilations would end up.
  • You can move a track between track groups, and make new track groups. A track group would be made for every significantly different version of a track. This includes notable remasters.
  • Tracks in a group can have varying lengths. The length is unimportant, as long as the portion of audio that is in a track is the same as other audio in the group.

For example:

Song - "Waterloo"

  • Type: Song
  • Lyrics Language: English
  • Original Performer: ABBA

Track Group by ABBA

  • Track 1: 3:20 (from 1974 US vinyl "Ring Ring")
  • Track 2: 3:20 (from 1974 Swedish vinyl "Ring Ring")
  • Track 3: 3:01 (from 1999 CD "Best of the 70s")

Track Group (single) by ABBA

  • Track 1: 2:32 (from 1975 Swedish single "Waterloo")

Track Group "2001 Remaster" by ABBA

  • Track 1: 3:20 (from 2001 CD "Ring Ring")
  • Track 2: 3:21 (from 2002 CD "ABBA: The Complete 2001 Remasters")

Track Group (cover) by Bjorn Again

  • Track 1: 2:19 (from 1995 CD "Rung Rung")

There are no recordings here.

By default, "Waterloo" album tracks by ABBA will go in the top group, which is the default album track group. "Waterloo" tracks from singles by ABBA will go in the second group by default.

You can move tracks and merge tracks in edits after they've been added. Track groups can also be merged, created and split. In this case, the track group "2001 Remaster" by artist "ABBA" has been created by a user, and the two tracks in there have been moved there after they were added. Alternatively, there's an option when adding a release to put tracks in a specific group, to save editing afterwards, and to create a new group for the track. But these options are hidden by default.

The cover by Bjorn Again has its own group. This is the default group for the artist Bjorn Again, and all "Waterloo" tracks by Bjorn Again will go there. This group was automatically labelled cover, because the original performer is listed as ABBA.

A track group is a group of tracks.


Recording Title Thingy

The recording name should be generally be the canonical name of the work being performed. If the recording is a remix, the name of the remix should also be included after the work name, in parentheses. If the recording isn't a performance, use the most common name for the recording.


Formatting Examples

Bold

Recordings with different mastering

As mentioned in Recording, in MusicBrainz, mastering is a process that is applied to recordings to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.

Following on from this, separate recordings should not be created for remastered tracks, since remastered tracks generally feature the original recording with different mastering applied. Remastering should be described using the Remaster Relationship Type between releases, or in the release annotation where tracks are mastered differently across a release. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.

Italic

Recordings with different mastering

As mentioned in Recording, in MusicBrainz, mastering is a process that is applied to recordings to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.

Following on from this, separate recordings should not be created for remastered tracks, since remastered tracks generally feature the original recording with different mastering applied. Remastering should be described using the Remaster Relationship Type between releases, or in the release annotation where tracks are mastered differently across a release. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.

Bold Italic

Recordings with different mastering

As mentioned in Recording, in MusicBrainz, mastering is a process that is applied to recordings to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.

Following on from this, separate recordings should not be created for remastered tracks, since remastered tracks generally feature the original recording with different mastering applied. Remastering should be described using the Remaster Relationship Type between releases, or in the release annotation where tracks are mastered differently across a release. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.

All Links

Recordings with different mastering

As mentioned in Recording, in MusicBrainz, mastering is a process that is applied to recordings to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.

Following on from this, separate recordings should not be created for remastered tracks, since remastered tracks generally feature the original recording with different mastering applied. Remastering should be described using the Remaster Relationship Type between releases, or in the release annotation where tracks are mastered differently across a release. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.

Monospaced

Recordings with different mastering

As mentioned in Recording, in MusicBrainz, mastering is a process that is applied to recordings to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.

Following on from this, separate recordings should not be created for remastered tracks, since remastered tracks generally feature the original recording with different mastering applied. Remastering should be described using the Remaster Relationship Type between releases, or in the release annotation where tracks are mastered differently across a release. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.


Monospaced Large

Recordings with different mastering

As mentioned in Recording, in MusicBrainz, mastering is a process that is applied to recordings to prepare them for release in a particular format. This means that tracks should not use separate recordings because of mastering differences.

Following on from this, separate recordings should not be created for remastered tracks, since remastered tracks generally feature the original recording with different mastering applied. Remastering should be described using the Remaster Relationship Type between releases, or in the release annotation where tracks are mastered differently across a release. The exception to this is where a track labelled as a remaster is in fact a remix - in this case, follow the remix guidelines above.

Freeform Entities

Entities which aren't created, but materialize. Editors write freeform tags, and these are converted into entities when they become popular enough. Freeform entities can be merged but not deleted. Power to the people!

Uses:

  • Genres
  • Instruments

Example

I think Artist X should have the genre "Rock". So I type "Rock". The server goes off an searches the genre entities for "Rock". Search results are returned as for normal entities, in a drop down box for user selection. If no entities are found, the user can type whatever they like, and save.

Behind the scenes, this "tag" would probably be stored in a db table with other "nearly-entity" tags, along with a count of occurrences. As soon as this count exceeds a certain number, then entity is created, and the tag gets replaced by the entity.

So, if 10 other users added the genre to something as "Rock", then this might be created as an entity and allow merging/relationships.

If things like "Folk Country" and "Country Folk" existed, they might be merged, and one would be used as the search hint for the other.

It would also be possible to map these genre entities to a list, such as the id3v1 genre list, or iTunes's genre list. We'd simply have some sort of field for genre entities describing this mapping.

This could be extended to instruments - it effectively automates the existing system of "5 uses, then it gets added". We could use various relationships to structure the instrument/genre graphs however we like (eg. "<genre> is derived from <genre>" or "<instrument> is ancestor of <instrument>").