Re: [mb-style] Promo releases
regarding track time difference - this is a problem with all disc ids. ie, every seperate pressing of a CD will likely have different track times. i think it is a continuing problem that we currently can't apply individual attributes/release dates to disc id. On 01/02/06, Simon Reinhardt [EMAIL PROTECTED] wrote: Hi, I need some clarification about promo releases. Maybe we can even formulate something for the wiki. The problem: some users seem to have access to promo releases before an album comes out. If the tracklistings differ then it is no problem of course, but if it's mostly the same, only with small differences in the tracktimes then it does not justify creating a new album. Putting both the official and the promotion release together in one album entity leads to conflicts: 1. There may be different disc ids with differeing times and if the promo disc id was added first then the entity adopts the times from it. 2. Both official and promotion as release status apply. 3. The release date of the promo copy is earlier as the official date which is confusing when looking at the album on the artist page. I therefore propose: 1. For the track times, try to adjust them to the disc id of the official release. (Disc ids can be moved over to other releases with the same number of tracks of the artist temporarily to make the times editable. If none is present, create one for the MusicBrainz Test Artist and move it over to the artist. Move it back and delete it. Needs an automod for this ;) ) 2. I consider the status official more important so this should always be selected I think. 3. Possible solution: don't enter the promo date at all. Finally you can distinguish all the release data with release annotation style (and add the promo release date to the annotation). Example: http://musicbrainz.org/album/6be9e22b-7177-4bfc-9506-b1b73f1b193b.html A little outlook: in MB2.0 those should be two separate entities under one album group anyways. And then you can also set the release status promotion for the promo copy. Simon (Shepard) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Promo releases
On Wed, 01 Feb 2006 03:34:21 +0100, Simon Reinhardt wrote: Hi, I need some clarification about promo releases. Maybe we can even formulate something for the wiki. The problem: some users seem to have access to promo releases before an album comes out. If the tracklistings differ then it is no problem of course, but if it's mostly the same, only with small differences in the tracktimes then it does not justify creating a new album. Putting both the official and the promotion release together in one album entity leads to conflicts: 1. There may be different disc ids with differeing times and if the promo disc id was added first then the entity adopts the times from it. 2. Both official and promotion as release status apply. 3. The release date of the promo copy is earlier as the official date which is confusing when looking at the album on the artist page. What are the reasons not to enter them as separate albums with the attributes album promotinal? DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Promo releases
Don Redman wrote: On Wed, 01 Feb 2006 03:34:21 +0100, Simon Reinhardt wrote: Hi, I need some clarification about promo releases. Maybe we can even formulate something for the wiki. The problem: some users seem to have access to promo releases before an album comes out. If the tracklistings differ then it is no problem of course, but if it's mostly the same, only with small differences in the tracktimes then it does not justify creating a new album. Putting both the official and the promotion release together in one album entity leads to conflicts: 1. There may be different disc ids with differeing times and if the promo disc id was added first then the entity adopts the times from it. 2. Both official and promotion as release status apply. 3. The release date of the promo copy is earlier as the official date which is confusing when looking at the album on the artist page. What are the reasons not to enter them as separate albums with the attributes album promotinal? DonRedman As often, I've added a album annotation, and that's what I did today: - http://musicbrainz.org/album/b3ef63f0-0878-465f-849d-bfaf3df80aca.html - :P Schika ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Promo releases
On 01/02/06, Don Redman [EMAIL PROTECTED] wrote: What are the reasons not to enter them as separate albums with the attributes album promotinal? seems a bit pointless when we don't even seperate different media releases - cd/vinyl/tape/etc, unless they are musically different. IMO track length differences between CD pressings, etc, are not at a muiscial level and not worthy of seperate indexing at the moment. even remastered versions don't really a deserve a new entry unless they have bonus tracks. in an ideal world i think we should have different entries for every different pressing (like discogs), but i'm not sure it's worth going some of the way, but not all, especially with something as trival as a promo. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] Promo releases
A lot of material marked as promotional are simply pre-release copies intended for retail and radio play prior to release and there is no difference at all between it the actual release. Other items such as mailer and instore copies should be considered Promotional since they are only available through a specific source and are not the same as the Official release. -- Cristov (wolfsong) The Truth is realized in an instant; the Act is practiced step by step. Zen saying ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] arranging/orchestration/instrumentation
Don Redman wrote: Lukas, you seem to push for that. Yes, I do. That's because *every* single AR type I've ever proposed here already was proposed (and discussed) somewhere else and then successfully forgotten. Can you please write up three short descriptions (that will then come into the AR desc filed) so that they can be reviewed here. http://wiki.musicbrainz.org/CompositionRelationshipClass I'll write the OrchestratorRelationshipType and InstrumentatorRelationshipType pages soon. (Or azertus, do you want to take this job? :)) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] vocal type should be optional
This has been discussed many times in almost all of our mailing lists and AFAIK with no results. I think we need to make vocal type optional, so that we can use ARs to say Artist performed vocal on Track/Album. I've already changed it on the test server. Here is an example: http://test.musicbrainz.org/track/379c1695-e938-4cac-aaf0-56b49755fbad.html Can we please decide this soon? Need OK from Secretary ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] vocal type should be optional
On Wed, 01 Feb 2006 22:35:44 +0100, Lukáš Lalinský wrote: This has been discussed many times in almost all of our mailing lists and AFAIK with no results. I think we need to make vocal type optional, so that we can use ARs to say Artist performed vocal on Track/Album. I've already changed it on the test server. Here is an example: http://test.musicbrainz.org/track/379c1695-e938-4cac-aaf0-56b49755fbad.html How did you do this? I thought this was not possible. Did you hack on the internals or is it possible to specify that a selection of multiple values is optional in the regular RelType interface? Can we please decide this soon? Need OK from Secretary IIRC there were poeple (Wolfsong?) arguing that this was not needed. However, I see no reason why a more fine-grained description, that gives you the ability to choose the genral group _or_ one of the specific elements, should be harmful. I will give you an OK under the following conditions: - Go through the http://wiki.musicbrainz.org/ChecklistForStyleChanges and answer these points: What is the impact on existing data? Conflicts with other Style Guidelines Required Editor Time Required Developer Time Impact on Paying Clients - Create a ticket. It is very simple: Management of StyleIssues must be in the open, if only for my job to be taken on by someone else in three months. So please use trac, I will too. The alternateive are obscure lists on my PC that nobody will ever see. - Wait 24 hours for objections. However, I will ignore objections that do not come with a comprehensible argument that the change is really one for the worse. DonRedman, the Secretary -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] arranging/orchestration/instrumentation
On Wed, 01 Feb 2006 22:24:28 +0100, Lukáš Lalinský wrote: Don Redman wrote: Lukas, you seem to push for that. Yes, I do. That's because *every* single AR type I've ever proposed here already was proposed (and discussed) somewhere else and then successfully forgotten. Can you please write up three short descriptions (that will then come into the AR desc filed) so that they can be reviewed here. http://wiki.musicbrainz.org/CompositionRelationshipClass I'll write the OrchestratorRelationshipType and InstrumentatorRelationshipType pages soon. (Or azertus, do you want to take this job? :)) These pages lack status information. Which of these is already implemented and which is not? Also, is Librettist not a special case of Lyricist? DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] vocal type should be optional
Don Redman wrote: On Wed, 01 Feb 2006 22:35:44 +0100, Lukáš Lalinský wrote: This has been discussed many times in almost all of our mailing lists and AFAIK with no results. I think we need to make vocal type optional, so that we can use ARs to say Artist performed vocal on Track/Album. I've already changed it on the test server. Here is an example: http://test.musicbrainz.org/track/379c1695-e938-4cac-aaf0-56b49755fbad.html How did you do this? I thought this was not possible. Did you hack on the internals or is it possible to specify that a selection of multiple values is optional in the regular RelType interface? It's perfectly possible, the system is designed to allow this. It's simple change from [x] additional [1]-[ ] to [x] additional [0]-[ ]. Btw, currently track-artist AR sais 1-1, album-artist 1- . So I've changed both to 0- Can we please decide this soon? Need OK from Secretary IIRC there were poeple (Wolfsong?) arguing that this was not needed. However, I see no reason why a more fine-grained description, that gives you the ability to choose the genral group _or_ one of the specific elements, should be harmful. I will give you an OK under the following conditions: - Go through the http://wiki.musicbrainz.org/ChecklistForStyleChanges and answer these points: What is the impact on existing data? No impact. Conflicts with other Style Guidelines No. Required Editor Time RelationshipEditor time? 60 seconds :) Required Developer Time - Impact on Paying Clients No impact. - Create a ticket. It is very simple: Management of StyleIssues must be in the open, if only for my job to be taken on by someone else in three months. So please use trac, I will too. The alternateive are obscure lists on my PC that nobody will ever see. http://test.musicbrainz.org/trac/ticket/1016 - Wait 24 hours for objections. However, I will ignore objections that do not come with a comprehensible argument that the change is really one for the worse. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] arranging/orchestration/instrumentation
Don Redman wrote: Also, is Librettist not a special case of Lyricist? Sorry, I don't know, I didn't add nor propse this AR type. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
