Re: [mb-style] RFV: FeaturingArtistStyle amendment (was Re: RFC: FeaturingArtistStyle amendment)
On Thu, 2 Oct 2008, Kuno Woudt wrote: On Thu, Oct 02, 2008 at 09:32:45AM +0100, Steve Wyles wrote: Equal credit was given to both artists on the original release, but FeaturingArtistStyle seems to be implying Use whatever is on the cover of he release you are entering, which could undermine the consistency that is obtained by using a database. It doesn't undermine the consistency. The artist field afaik is intended to capture the artist as credited on the release. Don't try to make it more than it is. If you want to know who actually wrote/performed/etc.. the track, consult the ARs. Hmm, I can understand what you are saying, but, in those instances you would have all credit name variations created as artists. Also, is it possible to search AR's from the web interface? Normally, tracks where FeaturingArtistStyle is actually intended to be used are generally credited consistently on releases. Of course, later compilations particularly VA ones could have anything listed :( However, with collaborations, the credits tend to change depending on who's release they on. I believe there needs to be more clarifiction of when FeaturingArtistStyle or (the missing) CollaborationStyle should be used. As I mentioned, the example given in FeaturingArtistStyle is actually a collaboration. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] artist A presents artist B
On Thu, 18 Sep 2008, Toni Panadès wrote: The problem begins for me when I add a new artist: Love Song Surprise artist (http://musicbrainz.org/artist/553a3f2c-2600-46ce-8f60-24e6ee6f13c6.html). LSS it's a group where the main artist is Dennis White (AKA Static Revenger), and in some places (and on the cover of the album) appears as Static Revenger presents Love Song Surprise. After contacting the artist, he say me that this is a petition from her manager (to promote the new name/artist), but the group is called only Love Song Surprise What you think? I need to put an alias for this artist, or I need to change the name of the artist? I'm certain this has been covered in previous discussions, either on the mailing list or the IRC channel. My understanding is: The current artist Love Song Surprise should stay exactly as named. It is probably worth adding Static Revenger presents Love Song Surprise as an alias under Love Song Surprise Steve (inhouseuk)___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: FeaturingArtistStyle amendment (was Re: RFC: FeaturingArtistStyle amendment)
For those that haven't had the time to read all the previous discussion, please summarise the changes that you are putting to RFV. Thanks. Steve On Tue, 3 Jun 2008, Chris B wrote: Right, RFV time :) 2008/5/21 Olivier [EMAIL PROTECTED]: 2008/5/21 Chris B [EMAIL PROTECTED]: 2008/5/21 Olivier [EMAIL PROTECTED]: Summing things up: - Chad has a point: Chris or Chad, can we have something to cover this, maybe in the Details section? i don't really want to get involved in this one for this RFC. that issue ((feat. x) in group names) is a big one and i have concerns with it, so i don't want the relatively simple amendment getting bogged down. that actually goes for ANY additional failings of FeaturingArtistStyle that i've not covered/introduced :) eg, i included the CSG stuff from the accepted FeaturingArtistStyle but i'm not prepared to elaborate on that as that's not what my amendment concerns. i think one of the major failings of the style process is heaping additional changes on simple RFCs so that they snowball into major rewrites/lengthy discussions. Fair enough. Chad? Is delaying this specific point for a later rework/discussion good for you? Regards, - Olivier ___ 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 ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Removing some instruments from the instrument tree
On Thu, 15 May 2008, Frederic Da Vitoria wrote: Some generic items in the instrument tree use the word instrument, some don't. Of those which do, I found 3 where we would IMO improve things by removing the word instrument: - Wind instruments - Winds - string instruments - Strings - percussion instruments - Percussions The plural of percussion is still percussion. I've never heard of wind instruments being called winds. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Change BoxSetNameStyle
On Mon, 24 Mar 2008, Brian Schweitzer wrote: So I suggest that part #1 of BSNS be completely stricken. It's counter to normal practice, counter to every discussion I've ever seen, until now, about allowing otherwise duplicate entries for box set discs, and can be (and is) being used *now* in a manner that destructively affects massively sized classical box sets. I totally agree with this. This is just one of the cases where current practice has overtaken the styleguide. There are quite a few examples in non-classical as well. The Queen Greatest Hit box sets and also the Pink Floyd ones as well. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: non-Latin artist sort name style
On Wed, 19 Sep 2007, Philip Jägenstedt wrote: 1. All ArtistSortNames must be in Latin script. ArtistSortNames in all other scripts should use the transliterated or translated name in Latin script by which they are commonly known. I feel the second sentence is a little confusing, I think this wording is better. 1. All ArtistSortNames must be in Latin script. Where the ArtistName is in a non-latin script, the ArtistSortName should use the latin script transliterated or translated name by which they are commonly known. Steve___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Misleading and wrong sleeves: Various Artists vs
On Wed, 16 May 2007, Brian Schweitzer wrote: To the best of my knowledge, we're not using A / B for anything, and it seems more accurate - it presents both artists, as on the liner, while still defining that there is some sort of separation between them, a separation not implied by the A B format. That format is already used where there are multiple songs on a track by different artists. http://wiki.musicbrainz.org/MultipleTitleStyle http://musicbrainz.org/release/b95f4ae5-8626-43a2-b0a0-0c44d516ecec.html shows some examples. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Artist 'is managed by' AR
On Tue, 10 Oct 2006, Matt Howe wrote: Pretty simple, most artists have a manager and we can't currently represent this in MB. It should be a link between a person and an artist/group. I'm not sure what else to say. any opinions on this? I feel this is moving into the 'legalities' of the music business rather than just recording information about the music or artists. Artist management can and does change over time, often due to legal disputes. It wouldn't be good to have out of date information such as: X is managed by Y When there is a court battle between them. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] artist type: project
On Tue, 10 Oct 2006, Robert Kaye wrote: Was there a resolution on this issue? If so, I'd like to include this in the next server release... I believe it was agreed to add it and it was being tested on the staging server before implementation. If I remember, it was accidently included in one of the mini-releases and backed out because it broke the lucene search. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Re: [mb-users] Featuring artist revisited...
On Sun, 24 Sep 2006, Don Redman wrote: This issue needs to be raised on the style mailing list. We can discuss this to death here but it will not matter. The only instance in MusicBrainz that could come to a binding decision on this matter is the StyleCouncil. So, please move this thread over to mb-style. I will not reply to the content of your mail here. I will bounce it across to mb-style. But, in my opinion, this should have been done by the parties proposing the change. As far as I can see there had been no previous wide area discussion on this matter. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Re: [mb-users] Featuring artist revisited...
On Sun, 24 Sep 2006, Simon Reinhardt wrote: Steve Wyles wrote: 3) The same work can be shown differently depending on the release it appears on. Particularly when it comes to VA compilation releases. So? Label them differently then. There is no written down guideline to make titles consistent as far as I know. But you are actually attempting to apply consistancy by relying only on what the cover states. Covers can be inconsistant between different countries and also between the original first release and a second print run a couple of months later. Which cover information do you use? What if an editor has a copy that shows the featuring artist in the track listing and a voter has one that doesn't? They are both correct! 4) Different entries for the same work can make it difficult to normalize the database at a later date. No, later (yes, after introducing NGE*, I know most of you can't hear that any more), it won't matter any more if identical works have differing titles because they will be connected through track grouping. As I said on the NGE page, we probably need to refine many guidelines and philosophies after a schema change. *After* the schema change, not before. You are attempting to introduce a major change now via the back door, without it being discussed in the proper forums. One important point is that NGE separates between what is printed on covers (what it says) and what something actually is and it allows us to store both things. The schema change hasn't happened yet. My idea would be to then only apply cover correction when it's sane (capitalisation, obvious mistakes on the cover, removing graphical effects) and apart from that don't apply any consistency cleanup and don't change things like duet with SomeOtherArtist to feat. as it's the artist's way of crediting. Maybe then, certainly not now. Without careful thought and guidelines being produced this could easily result in MB becoming as messy as freedb. Also, it is more likely to be the labels method of crediting rather than the artist. But more important than a far NGE is: right now we already have a separation between what it says and what it is: feat. in track titles on the one side and performance ARs on the other side are not congruent! (can't say this often enough) No, what you have is what the person designing the cover decided to include or under instruction by the label, the artist isn't always involved in that process. Also sometimes it depends on the contracts that have been signed as to whether a featuring artist is shown on the tracklisting or not. As far as I'm aware it is MB policy to state facts, not information supplied at the whim of the label. Either a performer featured on a track or they didn't. Not, the artist featured on the track, but their contract didn't allow them to be credited in the track listing. Or at a later date they decide they don't want to be associated with that work and get their name removed from all future releases. What do you do in these instances? feat. is an intended prominent credit of a (guest) artist who doesn't necessarily have to be a performer (I think Schika had an example where a mix engineer was featured). Performance ARs can credit every range of artists taking part in a performance, be it a minor session background vocalist or a prominent guest. And because ARs describe the what it is side, we can't have a featured on AR. Track listings on covers can't be relied upon to give accurate information. It should be the judgement of editors to include the important featuring information, not only what the cover states. 5) Editors need to refer to the tracklisting on the cover rather then relying on impirical knowledge. 6) Voters need to refer to the tracklisting on the cover rather than impirical knowledge. Which impirical knowledge? The fact they know a certain performer contributed on a work. 7) Webservice users will have to check AR entries instead of using either the track or the AR entries. As I said above, they are not the same anyway. ARs can't replace feat. in track titles and feat. doesn't always resolve to the same AR type. So create a feat. AR type and remove it from the track completely. Client software could then include that in the track information or in separate tags etc. This is a far more flexible method than using feat. in the track field. But, what information would you include? But you can also not add an artist with feat. to the track title when they were never credited like that - *that* is not factual data but plain guessing of the importance of a role. feat. in the current guidelines doesn't have any definition of importance of the role, only that they performed on the track. It is this that you are attempting to redefine by stating that feat. at the track level should only be included if it is shows on cover tracklisting. I understand the reasoning behind
Re: RFC: BonusDisc ammendment (was: Re: [mb-style] x (disc 1) x (disc 2), vs x x (bonus disc) / version info for special releases)
On Tue, 19 Sep 2006, Lauri Watts wrote: If it must be mentioned at all, I would like to see it reworded as: Note the release attribute of bonus discs are not necessarily the same as the album they were distributed with. Use 'live', 'remix' or 'compilation' as most appropriate. Yes, this would be far better and I was just thinking exactly the same thought myself. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: english capitalization of shortened words begining with a single quote
On Fri, 1 Sep 2006, Mangled wrote: From the opinions expressed on the thread, we suggest the following: - abbreviated words begining with a quote, when in the middle of a sentence, must have their first letter lowercased - abbreviated words begining with a quote at the begining of a sentence must have their first letter capitalized As they are guidelines instead of strict rules, I would use the word 'should' instead of 'must'. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: Re: [mb-style] Re: Ответ: RFV: OnlineCommunityRela tionshipType (renamed from MySpaceRelationshipType)
On Fri, 11 Aug 2006, Schika wrote: Well, I was going to try this on test for an russian artist I know, who also use LiveJournal. Now I came across a tiny problem: if the artist use some unconventional chars in his LJ-name, the proposed url-type h++p://artist.livejournal.com/ can't be used (a try to open that URL results with the well loved 404 error). Only the 'old' profile links will work: h++p://www.livejournal.com/~artist h++p://users.livejournal.com/artist h++p://www.livejournal.com/users/artist In my case, the LJ-name of the artist starts with an underscore _ Yes, that is because underscores arn't valid anywhere in host or domain names. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] Billboard's top whatever
I also don't have a clue of the coding needs, but will there be someone that will take up that part of the coding before we even start on the discussion of whether not to accept them, we need someone willing to create the code to make them admissible in my opinion. The 99 track limit was removed about 5 months ago, but seems to have been reintroduced in this release. removed in http://bugs.musicbrainz.org/changeset/6672 added again in http://bugs.musicbrainz.org/changeset/7584 it needs a bug report raising. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] Billboard's top whatever
On Wed, 26 Jul 2006, Steve Wyles wrote: The 99 track limit was removed about 5 months ago, but seems to have been reintroduced in this release. removed in http://bugs.musicbrainz.org/changeset/6672 added again in http://bugs.musicbrainz.org/changeset/7584 it needs a bug report raising. http://bugs.musicbrainz.org/ticket/1923 Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New Artist Type: Project
On Fri, 14 Jul 2006, Don Redman wrote: On Thu, 13 Jul 2006 22:50:09 +0200, Steve Wyles wrote: On Thu, 13 Jul 2006, Robert Kaye wrote: I did not mean to circumvent the process here -- I do apologize. Please advise if I should: 1. reset the four artists to unknown and remove the project type from the live server or 2. don't sweat it and call it a done deal or 3. Have the RFV now and if a veto appears, I will do #1. Was the impact on the libraries, applications and datafeed customers assessed? The impact of a sematical change was definetely not assesed. The boundaries between the new type and other types are not defined. I opt for 1. I've just checked and there are now 66 artists that have been set to project and it appears to break the lucene search. http://musicbrainz.org/search/textsearch.html?query=limelighttype=artistan=1as=1limit=25handlearguments=1 limelight is one of the artists that has been set to project http://musicbrainz.org/show/artist/?artistid=31378 I think until the full impact has been assessed, it should be reversed. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New Artist Type: Project
On Thu, 13 Jul 2006, Robert Kaye wrote: I did not mean to circumvent the process here -- I do apologize. Please advise if I should: 1. reset the four artists to unknown and remove the project type from the live server or 2. don't sweat it and call it a done deal or 3. Have the RFV now and if a veto appears, I will do #1. Was the impact on the libraries, applications and datafeed customers assessed? If it hasn't been or if there is an impact, option 1 should be done. If no impact has been determined, I would go for option 3. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: RenamedRelationshipType
On Tue, 20 Jun 2006, Aaron Cooper wrote: On 6/20/06, Nikki [EMAIL PROTECTED] wrote: On Tue, Jun 20, 2006 at 12:05:58AM -0400, Aaron Cooper wrote: This implies two different entities: the predecessor and the successor. If a band simply changes its name, I think it is still one entity. If it's one entity, why should it be listed under two artists? Thanks Nikki, that's my opinion right there! ;) I think if they're one entity, they *should* be one artist in MB, but then I guess we would have to set previous names as aliases? I believe the current trend is to separate previous names out into separate artists. Particularly, where it is considered to be a new project or a different style of music. Using aliases for the previous names will result in releases which were issued (and continue to be issued) under the old name to be mis-credited to the current artist name. Take http://musicbrainz.org/artist/d6c7da9f-64bd-44f7-8c03-376bf9cdb9fe.html and http://musicbrainz.org/artist/c842d29f-a297-48cd-bb71-4f77fd672b16.html which have recently been separated out. Re-merging the two artists and crediting http://musicbrainz.org/album/8693e5b6-9d24-495d-89fc-f2300bd8271c.html to T. Rex would be wrong. It was never released under the T. Rex name as the album cover (even on the recent re-release) clearly shows http://www.amazon.co.uk/exec/obidos/ASIN/B0002LU976 Another example I can immediately think of is: http://musicbrainz.org/artist/5c7c8529-dcbb-4ff8-b2c9-d363a91756ea.html (which still needs some cleaning up) Her teenage works were released as Debbie Gibson, whilst the more recent ones are as Deborah Gibson. As she has matured, so has her music and using her birth name on the newer releases reflects this. http://www.amazon.com/gp/product/B06M44 These examples are clear cases of artist intent. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: RenamedRelationshipType
On Tue, 20 Jun 2006, Chris Bransden wrote: On 20/06/06, Aaron Cooper [EMAIL PROTECTED] wrote: On 6/20/06, Nikki [EMAIL PROTECTED] wrote: On Tue, Jun 20, 2006 at 03:10:45PM +0100, Steve Wyles wrote: I believe the current trend is to separate previous names out into separate artists. Particularly, where it is considered to be a new project or a different style of music. Using aliases for the previous names will result in releases which were issued (and continue to be issued) under the old name to be mis-credited to the current artist name. And adding a new artist for every name change results in many artists to represent one entity. While I support multiple artists for completely separate projects, we don't have anything saying when an alias should be used and when a new artist should be created. t.A.T.u., for example, were originally called but changed their name when they started to release stuff elsewhere. Now they use t.A.T.u. in Russia too. Splitting them would be stupid, they didn't change direction, it's not a different project and some of their Russian songs as appear on non-Russian releases as t.A.T.u.. Yet they clearly started as one name and are now another. That's why I'd like to see something saying just when something deserves a new artist. People seem to hate aliases because they're not used for anything other than searching, but why will anyone ever want to code better stuff for something we never use? Why don't we create a X was released under the alias Y AR? That way we could keep bands that changed their names together in the database. Of course, there'd have to be other satisified conditions, like there was no significant change in membership or whatever we decide, but I don't like the notion that a change in style deserves a new band. A band's style is very subjective and we don't use it now to separate artists who don't change their names but do their style (see Metallica - again, the style is very subjective, but I hope you understand my point). Why not make a X was released under the alias Y AR so that one day these can be tagged under the original band/artist name if desired, but stored under a single MB Artist? that's a really good idea - never thought of it that way! you could have it trigger a prompt when tagging, to. Except that with the current db structure it isn't possible to associate one side of an AR to an artist alias, only to artists. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Decision and clarification of imdb format
On Sun, 11 Jun 2006, teleGUISE wrote: There is a need to clarify the imdb format once and for all and write the wiki doc to reflect so as well as the JS code to work accordingly. http://wiki.musicbrainz.org/IMDbRelationshipType At present the wiki doc says to add imdb url's without the preceding www., however at present the only way the AR JS code selects the imdb relationship automatically is if it is part of the url. The simple answer is to use the format which is recommended by IMDb themselves :) http://www.imdb.com/help/show_leaf?howtolink Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ArtistAlias and PerformanceNameStyle conflict / Whatmakes an Alias?
On Tue, 30 May 2006, Chris Bransden wrote: It's about what you'd want to see as a user - I am of the opinion that the same band should be under the same name, and I believe this was the intension of the ArtistAlias page. Artist aliases are used to aid searching for mis-spellings or typos of the same artist. It seems you are reading more into http://wiki.musicbrainz.org/ArtistAlias than is actually there. There is a difference between a band changing their name, and changing their style and the name to suit, but I believe T/Tyrannosaurus Rex fall into the former category. It is not a simple case of changing name. The style of music released by Tyrannosaurus Rex and T. Rex is completely different. To people that don't understand the history, it is easy to get confused and think they are the same group. Tyrannosaurus Rex effectively disbanded due to disputes between Marc Bolan and Steve Took over musical style and control of the band. Steve Took left (sacked) and Marc Bolan started up T. Rex with Mickey Finn. Although the names are similar, with Marc Bolan being a member of both, the musical style is different and they are not the same group. Even today Tyrannosaurus Rex material is re-released as Tyrannosaurus Rex, not as T. Rex. Think of it as Tyrannosaurus Rex disbanding and a new group called Triceratops starting up. They are both dinosaurs beginning with the letter 'T', but they are completely different animals. I hope this now puts this discussion to rest. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] ArtistAlias and PerformanceNameStyle conflict / Whatmakes an Alias?
On Tue, 30 May 2006, Chris Bransden wrote: My stance is similar to Don's. I think they should be under the same artist where possible, but when the names (intentionally) represent distinct styles, keep them seperate. They do represent distinctly different styles. You obviously don't know the groups and you haven't listened to the material from them. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Amazon Relationship Type
On Sat, 27 May 2006, joan WHITTAKER wrote: I think they should definitely be allowed. Apart from providing a direct link to the Amazon page, they are also a source of revenue. I'm not certain commission is earned on amazon reseller sales. This needs to be confirmed. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SG5...again (*ducks*)
On Thu, 25 May 2006, Chris Bransden wrote: http://musicbrainz.org/showmod.html?modid=4831652 I agree with the 'yes' voters here - the same track can be 'x (feat. y)', 'y (feat. x)', or 'x y', on different releases. eg, a guest artist is typically billed as (feat.) on a release on which their contribution is restricted to 1 track! the single of 'sisters are doin' it for themselves' would bill Aretha higher because in the context of that single she gets a higher billing. however i don't think that should impact the artist attributed to that track in all contexts. I'm glad you brought this up in the mailing list. There is no point in changing who it is credited to according to the release that a work appeared on. The work is identical whether it appears on a Single, Eurythmics an AF album or a VA compilation. The people who receive the royalties are the same in each instance. As I stated previouly on IRC this is an identical situation to the Queen David Bowie release of Under Pressure. On the album in question, in the liner notes it is shown as a duet, on the liner notes of Respect: The Very Best of AF it is also shown as a duet. What is a duet if it is not a collaboration? http://www.annie-lennox.com/sisters2.htm Tina Turner was first choice for the collaboration but she turned the Eurythmics down because the song was apparently too feminist in content. http://www.amazon.com/gp/product/B02VD3/ ... and a rocking collaboration with Eurythmics, Sisters Are Doin' It for Themselves, that she completely takes over. http://www.foxnews.com/story/0,2933,89106,00.html Lennox came to the party looking a helluvalot happier than she does in the pictures. She's over her big divorce, which is what the album is about, and she's been touring all over the world. Is there anyone she wants to duet with? (She has one famous hit collaboration, with Aretha Franklin, on Sisters Are Doin' It For Themselves.) I don't think so, she said in her heavy brogue. I'm happy singing solo I think. From the Grammy awards: http://www.rockonthenet.com/archive/1986/grammys.htm BEST RB VOCAL PERFORMANCE BY A DUO OR GROUP - other nominees: Ashford Simpson - Solid Eurythmics Aretha Franklin - Sisters Are Doin' It For Themselves Hall Oates, David Ruffin Eddie Kendrick - The Way You Do The Things You Do / My Girl The Pointer Sisters - Contact You'll notice in the Grammys, it wasn't just Eurthymics or Aretha Franklin nominated for the award, it was both! If that doesn't prove it is a collaboration, what does? Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] SG5...again (*ducks*)
On Thu, 25 May 2006, Chris Bransden wrote: IMO sg5 was a problem because you HAD to make everything an X (feat. Y), regardless of how it was actually billed. This is obviously crap, but it seems now we're going the opposite way and making everything a collaboration! what i want to know is: are you saying that we should: a) reflect reality (ie, we decide what's a colloboration and what isn't, not the sleeves) b) reflect what a song is billed as on its first releasei c) not use feat. x at all i say: d) use what's on the sleeve as it's (normally) contextually appropriate I say a) Go by known fact. Otherwise in this particular instance and many others, the only release that would be under the collaboration artist would be the single. This makes SG5DR completely pointless and we're back to the mess of .feat, one way on the release by one artist and the opposite way for when the same work is released by the other equally billed artist. When in actual fact they are exactly the same work and should be titled and credited identically. Oh! and don't forget the thousands of Performed AR's SG5DR came about from the need to normalise the data a little better, are people now saying that we should go back to the old .feat mechanism? Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] CodeOfConduct with respect to bogus accounts
It seems we really need to clamp down on the creating of bogus accounts used for voting. Creating an account http://musicbrainz.org/user/view.html?uid=229805 purely for the purpose of forcing mod http://musicbrainz.org/showmod.html?modid=4831652 through in the last hour is not the way the voting system is supposed to work. Something definately needs to be added to the CodeOfConduct and IMO these incidents should be investigated. If such behaviour continues, I hate to think what damage will happen to the data. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] CodeOfConduct with respect to bogus accounts
After a little discussion on IRC, I think the enhancement I have proposed in http://bugs.musicbrainz.org/ticket/1536 will eliminate most of the issues we are seeing from these new accounts. Extra reporting would be nice, however, some of those reports might be seen to be 'big brotherish' or snooping on users. Steve (inhouseuk) On Thu, 25 May 2006, Beth wrote: Sadly, I'm of the opinion that the Code of Conduct, while a great practice, and perfectly wonderful, is only binding when in fact all parties are held by the code of conduct. I think we have a method of handling this already, though it would be easier if we had a report of these accounts have been created in the last 28 days these accounts are only voters (I would like that anyways, because I feel more voters should be looked into for auto-editors). This has three benefits. It tells us accounts created and shows us how many people are coming to MB everyday (for those curious). We can be a little nicer and a little more watchful. We can then notice those that are voters, which is something I feel mb needs. We can help people to realize why to vote no, for those that always vote yes... and lastly we will be more capable of spotting those people voting on their own votes. Also it is not much of a system change, and I think when it's kept in check, it works really well. Nyght aka Beth -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Steve Wyles Sent: Thursday, May 25, 2006 6:58 AM To: MusicBrainz style discussion Subject: [mb-style] CodeOfConduct with respect to bogus accounts It seems we really need to clamp down on the creating of bogus accounts used for voting. Creating an account http://musicbrainz.org/user/view.html?uid=229805 purely for the purpose of forcing mod http://musicbrainz.org/showmod.html?modid=4831652 through in the last hour is not the way the voting system is supposed to work. Something definately needs to be added to the CodeOfConduct and IMO these incidents should be investigated. If such behaviour continues, I hate to think what damage will happen to the data. Steve (inhouseuk) ___ 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 ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: RFV: [mb-style] Soundtracks
On Mon, 22 May 2006, Lars Aronsson wrote: Alexander Dupuy wrote: I'm afraid that I agree with mudcrow on this; there are a number of reasons that it makes sense for the composer to be credited as the primary artist for soundtracks in most cases (with an exception for non-classical music included To a newcomer like me, it seems absurd that the archaic notion of primary artist (i.e. the artist column of the album and track tables) wasn't removed when AdvancedRelationships were introduced in April 2005. Was this a deliberate decision, and was the reason documented? Or was it just forgotten by mistake? Is it too late to do it now? A nice idea, but it would require a complete re-write of large parts of the server code. It would also have a knock on effect to customers taking a data feed and the way they use the data. It would be a major change, something that would need to run in parallel to the existing schema to give people time to switch. A schema/code change as large as this could not be introduced overnight. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] AR links to AMG
I've just done a quick check of the URL AR links and it appears there are 27 album URL AR links and 7 artist URL AR links into www.allmusic.com It is my understanding that AMG don't allow deep linking[1] and linking into a competitor is also a little cheaky. Additionally, the wiki[2] also hints that linking to AMG isn't sensible for technical and legal reasons. Questions: 1. Should we continue to allow AR's linking into AMG sites? 2. If 'no' to question 1, how can users be informed regarding this or should a check be put in to prevent those URL's from being entered. Steve (inhouseuk) [1] http://www.allmusic.com/cg/amg.dll?p=amgsql=32:amg/info_pages/a_faq_general.html [2] http://wiki.musicbrainz.org/OtherDatabasesRelationshipClass ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] AR links to AMG
On Fri, 5 May 2006, Beth wrote: I personally think it's better safe than sorry! Let's get rid of them, and request in the review page URL wiki page that AMG not be added as a link due to their TOS. I've just found their TOS: http://www.allmusic.com/cg/amg.dll?p=amgsql=32:amg/info_pages/a_terms_of_service.html It's difficult to determine where MB's use of their URL's falls within the TOS. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] albums and single with the same title
On Wed, 3 May 2006, Brian Gurtler wrote: i think we need a way to differentiate singles form albums with the same name. For example Morphine has an album titled Cure for Pain they also have a single Cure for Pain as well. I have both ripped and tagged but they end up in the same folder. Also if i physically move one of them to another folder they end up in the same album in my music player library anyway because they have the same title information in their tags. what can we do to prevent this from happening? can we add (single) to singles that have the same title as albums? would anyone be opposed to that? Why replicate the information in the title when it is already held in the release type? Use the album type in the filename (%type in picard) to make it unique. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] albums and single with the same title
On Wed, 3 May 2006, Brian Gurtler wrote: Steve Wyles wrote: On Wed, 3 May 2006, Brian Gurtler wrote: i think we need a way to differentiate singles form albums with the same name. For example Morphine has an album titled Cure for Pain they also have a single Cure for Pain as well. I have both ripped and tagged but they end up in the same folder. Also if i physically move one of them to another folder they end up in the same album in my music player library anyway because they have the same title information in their tags. what can we do to prevent this from happening? can we add (single) to singles that have the same title as albums? would anyone be opposed to that? Why replicate the information in the title when it is already held in the release type? Use the album type in the filename (%type in picard) to make it unique. Steve (inhouseuk) right, but the tag will still be non-unique. They'll be unique if you take the track numbers into account. Especially, if you store them as x/y where y is the total number of tracks on the release. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] albums and single with the same title
On Thu, 4 May 2006, Brian Gurtler wrote: Steve Wyles wrote: On Wed, 3 May 2006, Brian Gurtler wrote: Steve Wyles wrote: On Wed, 3 May 2006, Brian Gurtler wrote: i think we need a way to differentiate singles form albums with the same name. For example Morphine has an album titled Cure for Pain they also have a single Cure for Pain as well. I have both ripped and tagged but they end up in the same folder. Also if i physically move one of them to another folder they end up in the same album in my music player library anyway because they have the same title information in their tags. what can we do to prevent this from happening? can we add (single) to singles that have the same title as albums? would anyone be opposed to that? Why replicate the information in the title when it is already held in the release type? Use the album type in the filename (%type in picard) to make it unique. Steve (inhouseuk) right, but the tag will still be non-unique. They'll be unique if you take the track numbers into account. Especially, if you store them as x/y where y is the total number of tracks on the release. Steve (inhouseuk) no. they won't be unique. they will all be tagged with the same album title. that's not unique and therefore (I'd guess depending on what music player used) will end up all in the same album in the library. you can store them however you want but anything tagged with Morphine as an artist and Cure for Pain as the album title (wither it's a single or an album) will end up in the Cure for Pain album in the library regardless of the track number or any other tagged information or file structure. So use the additional data that is already available to make it unique. You asked for advice as to how to deal with the situation, this has been given. There is a way to ensure they are unique taking the information that is available. It is not a problem of the way it is stored in the database, it is a problem in the way that data is being interpreted on the client. There is zero point in duplicating that data in other fields and it will not be done. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recorded Engineer Recorded By, Mix Engineer Mixed By
On Thu, 15 Dec 2005, Don Redman wrote: On Wed, 14 Dec 2005 18:23:57 +0100, Alexander Dupuy wrote: With this additional context, it's pretty clear what the difference between DJ-mixed by and mixed by is, and few editors will make the wrong choice. That is a very good point. I support this. I hate to open this issue again, but have a look at: http://musicbrainz.org/showartist.html?artistid=94575 where is has: produced Misguided from 1995 until 1995 recorded Misguided from 1995 until 1995 What do you think the Recorded means to a novice user going to that page? Also see the discusion http://chatlogs.musicbrainz.org/2006/2006-04/2006-04-29.html#T14-01-00-381439 Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recorded Engineer Recorded By, Mix Engineer Mixed By
On Sat, 29 Apr 2006, I wrote: I hate to open this issue again, but have a look at: http://musicbrainz.org/showartist.html?artistid=94575 where is has: produced Misguided from 1995 until 1995 recorded Misguided from 1995 until 1995 What do you think the Recorded means to a novice user going to that page? Also see the discusion http://chatlogs.musicbrainz.org/2006/2006-04/2006-04-29.html#T14-01-00-381439 The example I just give on IRC to explain the confusion is: http://www.google.co.uk/search?hl=enq=who+recorded+hound+dogbtnG=Searchmeta= Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Clarification of instrumental track info
On Wed, 19 Apr 2006, derGraph wrote: Are we discussing what the current style guide says about (instrumental), or are we discussing to change the style guide? In the first case, the answer is pretty clear: [1] says (on the bottom of the page) the following details should be left out: [...] Any other information not discussed in the OfficialStyleGuidelines. Instrumental tracks are not discussed in any official style guideline. However, the guess case function does correct Inst. to instrumental. So, although not discussed in the styleguides, I would say there is nothing wrong with including that information if it exists. [1] http://wiki.musicbrainz.org/ExtraTitleInformationStyle ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] Contextual information in track title
On Tue, 11 Apr 2006, Beth wrote: Is a large album annotation so daunting? I've seen a few. I offered to do it. So far I haven't seen even the comment annotation noted. Yet less a request that I do it. I am more than happy to do it. Large annotations can currently cause problems with some replicated servers, causing the process to crash. Which reminds me, I must raise a ticket for that problem. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] WTF DVD? (was: Veto - DVD in album titles)
On Tue, 4 Apr 2006, Brian Gurtler wrote: Beth wrote: My thoughts... Q1. Which DVDs to add? A1. All DVD musical rips. Arguments: it was argued MB was a music database. Music DVD's are based on music and bands. That in itself seems to be a good reason to add them. If MB is supposed to be an archive of band's music at least.) once you separate the video from the audio you are left with a homemade audio release which isn't any different than a bootleg. if it was official audio, there would be an official audio release of the same audio put out by the band. I think there is some confusion here. A CD containing the sudio extracted from a DVD would be bootleg. However, the DVD itself is an official release. Remember, musicbrainz is only storing the names of the tracks on the DVD, not the actual audio. I feel that if DVD's are added, they should have a DVD-discid (this can be obtained using libdvdread) attached to them. This is the probably the best way to determine if something is an official release or not. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] WTF DVD? (was: Veto - DVD in album titles)
On Tue, 4 Apr 2006, Nikki wrote: On Tue, Apr 04, 2006 at 04:22:52PM +0100, Steve Wyles wrote: I feel that if DVD's are added, they should have a DVD-discid (this can be obtained using libdvdread) attached to them. This is the probably the best way to determine if something is an official release or not. Oh? Care to elaborate? Actually I thought it was doing some magic. Apparently not! bash-2.05b# ./disc_id /dev/acd0c libdvdread: Using libdvdcss version 1.2.9 for DVD access 3dd959cdd9c8122e569450d86ba195a9 bash-2.05b# cat /mnt/video_ts/*.ifo | md5 3dd959cdd9c8122e569450d86ba195a9 Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: Call for StyleSecretary Help: Let's try discussing/deciding thisin IRC (was [mb-style] add instrument request: vacuum cleaner)
On Sun, 26 Mar 2006, Don Redman wrote: The current Recording Engineer debate is a good example: Simon thought he was requesting a veto (but did not say so explicitly), but Steve put forward a dissenting oppinion (he did not label it as a veto) and spared another discussion. I've just checked my archive and from what I can see, although the Recording Engineer proposal was mentioned on the mailing list back in December 2005, there was very little discussion on it. Well, there would have been discusion, but, it drifted off to a debate about Mixed By The original thread starts here: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2005-December/001006.html Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] change 'Recording Engineer' to 'Recorded By'
On Sat, 25 Mar 2006, Simon Reinhardt wrote: Hi, any objections against http://test.musicbrainz.org/trac/ticket/54 ? I will wait some days and then edit it. :) I think that would cause confusion. Frequently the phrase Recorded By is understood to refer to the artist that performed it. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] request for new release country: GDR
On Wed, 8 Mar 2006, derGraph wrote: I didn't realise this before, but there's a release country missing in the list: the German Democratic Republic http://en.wikipedia.org/wiki/East_Germany. Sure, it does not exists any longer, but still it feels wrong to add GDR releases as e.g. 1989 - Germany. Or does anyone of you have a problem with socialist releases? ;-) This is planned as part of http://wiki.musicbrainz.org/ReleaseCountryUpdate But, I've no idea when this is going to happen. Steve ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] arranging/orchestration/instrumentation
On Thu, 2 Feb 2006, Frederic Da Vitoria wrote: I'd say it is. As far as I know, librettist is only used for someone who wrote the text for an opera. yes, that appears to be the case: http://dictionary.reference.com/search?q=librettist 2006/2/2, Luká? Lalinský [EMAIL PROTECTED]: 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. -- Frederic Da Vitoria___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PersonalAssociationRelationshipClass the goal of MB
On Mon, 30 Jan 2006, Chris Bransden wrote: Agreed. Personally I think all 'non musical' relationships would be better suited to annotations. Even better, annotations that can contain hyperlinks to other musicbrainz artist pages, should they exist. Erm, and how is that any different from having have an AR? Representing musical and non-musical relationships differently is silly and leads to inconsistancy. Why is it viewed as being a problem to have non musical relationships in the database? It is a couple of rows in a couple of database tables, far easier to store and utlimately searchable and selectable. This isn't a easy to do with free text fields. I think if we try to recognise every single relationship one entity can have with another, without having some kind of free text entry system for bespoke non-musical/rare relationships, then the system becomes less useful for the common stuff. Not really, it would be quite easy to have a preference to turn off the display of non-musical 'artists' and relationships if the user doesn't want to see them. If the artist entity only has non-musical AR's pointing to it, choose whether to show it or not depending on user preference and circumstance. This couldn't be done with free text fields. With free text fields like annotations, you either show all data contained it in or nothing, you have no way of classifying it. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PersonalAssociationRelationshipClass the goal of MB
On Mon, 30 Jan 2006, Chris Bransden wrote: On 30/01/06, Steve Wyles [EMAIL PROTECTED] wrote: On Mon, 30 Jan 2006, Chris Bransden wrote: Agreed. Personally I think all 'non musical' relationships would be better suited to annotations. Even better, annotations that can contain hyperlinks to other musicbrainz artist pages, should they exist. Erm, and how is that any different from having have an AR? because it involves a process (asking for new AR to be added to choices, which probably doesn't happen for most cases because people can't be bothered), which takes time, effort, etc, and will no doubt be harder once the list gets very big. then it's got to be added to the UI, which WILL become less useful over time if every relationship under the sun is indexed. I'm not talking about extra AR types being added, just using the existing non-musical ones (is the parent of, has sibling, is/was married to, is/was involved with) being used properly and to full effect. Although it is questionable whether involved with really belongs there. Adding a new AR type doesn't involve any development time, it is just adding an extra row in to a database table, no code changes are required. But, that is not what is being discussed. At the moment they are only deemed as being valid if the 'artist' entities on both sides of the AR would normally be in the database for a 'musical' reason. Therefore you can only show if an artist is married to another artist, NOT if an artist is married to a NON artist. The AR types are already there, they should be used properly, not just recording part information. Representing musical and non-musical relationships differently is silly and leads to inconsistancy. i'm talking about relationships that IMO are out of our scope, and therefore it isn't particularly neccesary for them to be consistant. Why do you feel they are out of the scope of Musicbrainz? AMG allmusic.com shows both of Michael Jackson's marriages, why isn't MusicBrainz? eg, i'd like to see what albums ArtistX produced in one nice list, but i'm not particularly bothered about who he shared a flat with being in a list. that's annotation stuff. it would be quite easy to have a preference to turn off the display of non-musical 'artists' and relationships if the user doesn't want to see them. If the artist entity only has non-musical AR's pointing to it, choose whether to show it or not depending on user preference and circumstance. lets have it then? it's what bugs me about AR - it's hard to add and and it's hard to read, Yes, the usability could be improved, but that is not the context of this discussion. and we're talking about extending it's scope all the time, Nope, just using the existing types properly, by allowing the entry of AR's linked to artist entities that are deemed to be 'non-musical' For instance, we can only show both parents of an artist if both of them would be in the database for another reason. An example here is: http://musicbrainz.org/showartist.html?artistid=40437 which shows both parents and http://musicbrainz.org/showrel.html?type=artistid=8152 which only shows one, because his mother is Cynthia Powell, John Lennon's first wife. But despite Cynthia Powell being married to a famous artist and the mother of another, she isn't currently deemed worthy of an entry in the database. But, if she'd helped design one of The Beatles record covers, or played a single note on, lets say, a triangle on one of their albums, she would be! This is the sillyness that is being discussed! Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PersonalAssociationRelationshipClass the goal of MB
On Mon, 30 Jan 2006, Jan van Thiel wrote: On 1/30/06, Steve Wyles [EMAIL PROTECTED] wrote: For instance, we can only show both parents of an artist if both of them would be in the database for another reason. An example here is: http://musicbrainz.org/showartist.html?artistid=40437 which shows both parents and http://musicbrainz.org/showrel.html?type=artistid=8152 which only shows one, because his mother is Cynthia Powell, John Lennon's first wife. But despite Cynthia Powell being married to a famous artist and the mother of another, she isn't currently deemed worthy of an entry in the database. True. The only important information here (Julian Lennon is John Lennon's son) can be entered in the database without adding Cynthia Powell. The only important information to who? But, people have two parents, not just one. There is absolutely no reason (apart from politics) why MusicBrainz can't show both. Adding the missing Cynthia Powell entry, would close the open incomplete parent/child relationship and also show that John Lennon had two wifes. This is completing the information on two artists. so, if somebody wants to know who his other parent is, you're basically telling them to get the information somewhere else. Isn't this going against the attempts to create a comprehensive music information site claim on the front page? But in general, I think adding non-musicians is not the way to go. Why? Adding only to the level where there is a direct relationship to an artist is not going to create a problem and completes the information held on an artist. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PersonalAssociationRelationshipClass the goal of MB
On Tue, 31 Jan 2006, Don Redman wrote: Robert and me talked on the telephone today, and I asked him what he thinks about this. He said that he does not like the idea that possibly thousands of nonmusical artist get added to the db, just because they were maried to a musician. This decision doesn't only affect the married relationship, but all the ones that are none musical: parent of / has sibling etc. There was one example earlier in the discussion where the addition of one non-musical artist is the only way of linking two other artists, this non-musical artist will now need to be removed and this link lost. This decision effectively makes these relationship types useless as they can never be used to show complete data. If they can't be used to show complete data they may as well be removed, along with all the current links using those relationship types. The alternative is that there will be less of the quick decisions and more of the OK, sum the debate up and then the Elder will decide mails. This means more work for you, but it also means you are in control of the arguments that get presented, and the whole decision process is public (although still dictatorial). I would have been happier to present a valid argument weighing up the pros / cons of going one level further in the scope of the data that is held, instead of a quick decision being made. As you just mentioned, Rob hadn't seen the emails on the subject, therefore he is possibly making a decision on a whim without seeing the whole discussion. What do you think? I'm disappointed that the normal process for style changes has been effectively short-circuited without having a adult discussion. MusicBrainz has an innovative method for showing this type of data, I'm not aware of anybody else doing anything similar. It is a real shame it will now never be used to full effect and fail to provide what could be a valuable tool to a larger audience. Instead of being a one-stop-shop for this data relating to an artist, we are limiting the scope and possibly the target audience. Currently MusicBrainz is promoting itself as attempting to be a comprehensive database of information relating to music and the artists, this is clearly not the case. If those relationship types are retained, a disclaimer is needed, to indicate the information may be incomplete because only musician - musician relationships are allowed in the database. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: What Gets Tagged Under SG5? (WAS: [mb-style] RE: AlbumTitle proposal)
On Mon, 16 Jan 2006, david scotson wrote: On 1/16/06, Rod Begbie [EMAIL PROTECTED] wrote: On 1/16/06, Chris Bransden [EMAIL PROTECTED] wrote: tis ok :) i just am trying to work out what album artist means in the context of a tag. Right now, with the current limitations of ID3 tags, it's not terribly useful. If Picard (or a third party app) could work within the limitations of current apps support for id3 and replace the track artist with the album artist and modify the track title so that artists other than the album artist appear in the track title then that would suit quite a lot of people, particularly for soundtracks and DJ mixes e.g.: Which is effectively going back to the situation before SGDR was implimented. To me the album artist indicates where the album would be found in a record store or in a filesystem layout. MP3 -\ | | +-- ALBUM ARTIST -\ | | | +-ALBUM NAME ---\ | | TRACK (album + track artist in tag) I don't use the Album Artist in the tags at all, it is just used to show where the album should be filed. Out of Sight movie soundtrack by David Holmes: http://www.amazon.com/gp/product/B07QEB This would be filed under David Holmes, with the tracks artists changed on the tracks that arn't attributed to him. 26 mixes for Cash by Aphex Twin: http://www.amazon.com/gp/product/B88EGP Again, this would be filed under Aphex Twin. Essential Mix by Pete Tong: http://www.amazon.com/gp/product/B5A0ID This one is a little bit more difficult to place. Steve (inhouseuk) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
