Re: [mb-style] Results of the Recordings IRC meetings
On Fri, Jan 25, 2013 at 1:14 AM, Nicolás Tamargo de Eguren reosare...@musicbrainz.org wrote: It would also be good to hear from Lukas on how this would affect acoustID. I don't have much to say about this. I'm sure there will be an obvious solution once there is a plan now to migrate the existing MB data. Most likely it's that AcoustIDs will be at the equivalent of the current level or lower (closed to releases), unless somebody will have a better idea once it's clear what's going to change. A better question is what will happen with the current recording MBIDs? Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Genre support
Hi, This discussion is a little off-topic here, but I can't think of a better group of active MB users to discuss a feature like this. I'd like MB to have some support for genres. This was apparently discussed at the last MB summit, but I don't know details about that. http://wiki.musicbrainz.org/MusicBrainz_Summit/11/Session_Notes#Genres I've created a ticket that seems to be a superset of the genre features discussed at the summit: http://tickets.musicbrainz.org/browse/MBS-3738 The idea for now is just to define the genre lists and relations between them. It does not deal with the problem of assigning entities like artists to genres (I think that SoundUnwound has a nice solution to this though). My idea is to add the concept of genres to MusicBrainz, make it editable by users, linkable to other genres and URLs. That way we can define genre trees. Then I'd like for each genre to have a list of tags that the genre can appear as. This can be used for autocompleting genres when adding tags, and whitelisting tags in applications like Picard (it can be used to whitelist tags also from other sources, like Last.fm). Does any of this make sense? Do you think it's a good idea? Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Genre support
Ok, so I'll try to summarize it one more time because I can see that this mail was completely misunderstood. :) We already do have tags, the majority (but not all) of which are genres. What I proposed here was a layer above the tagging system, which just helps people to give some meaning to the tags that we already have. There are two main problems with tags for people who are interested in extracting data from MB and want only genres, not other tags: a) Tags can be anything and you can't intelligently filter them out without having large whitelists. That is, given tags hip hop, hiphop, rap, usa I want to be able to tell that only hip hop, hiphop and rap represent genres. b) People are free to enter tags however they want, so we see things like hip hop and hiphop next to each other. We should be able to tell that they are in fact the same genre. What I want is to define what kind of genres are there, how are they related and what tags people usually use to represent them. With this information you can say that the tags hip hop, hiphop, rap, usa are in fact mentioning only one genre - Hip-Hop. You can also say from tags psytrance and psy-trance that both represent a genre called Psychadelic Trance, which has its origins in Trance, which is a style of Electronic music. Lukas 2011/12/12 Lukáš Lalinský lalin...@gmail.com: Hi, This discussion is a little off-topic here, but I can't think of a better group of active MB users to discuss a feature like this. I'd like MB to have some support for genres. This was apparently discussed at the last MB summit, but I don't know details about that. http://wiki.musicbrainz.org/MusicBrainz_Summit/11/Session_Notes#Genres I've created a ticket that seems to be a superset of the genre features discussed at the summit: http://tickets.musicbrainz.org/browse/MBS-3738 The idea for now is just to define the genre lists and relations between them. It does not deal with the problem of assigning entities like artists to genres (I think that SoundUnwound has a nice solution to this though). My idea is to add the concept of genres to MusicBrainz, make it editable by users, linkable to other genres and URLs. That way we can define genre trees. Then I'd like for each genre to have a list of tags that the genre can appear as. This can be used for autocompleting genres when adding tags, and whitelisting tags in applications like Picard (it can be used to whitelist tags also from other sources, like Last.fm). Does any of this make sense? Do you think it's a good idea? Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Works and remixes/covers
On Wed, Nov 9, 2011 at 9:30 AM, MeinDummy meindu...@nurfuerspam.de wrote: This discussion seems to have faded out now. There are many unresolved specific issues regarding covers, translations, instrumentals, ... Most of them are beyond the remix work topic and should probably be further discussed in separate threads. Despite of those issues isn't the guideline update that Lukáš proposed ready for RFC/RFV now? I think adding remixes and covers to the same work as the original version is now a common practice. Not sure if it makes sense to explicitly state it somewhere. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG - Track recording standardization, linking recordings, removing duplicate works ARs
On Sun, Oct 23, 2011 at 8:38 AM, Jim DeLaHunt from.nab...@jdlh.com wrote: Lemire, Sebastien-2 wrote: - To keep a certain link with the original album I don't think we should normalize track lists but the recordings themselves can appear on various releases (where each release can have different naming conventions and language) I think you are seeking to re-argue RFC-333, Unify track/recording guidelines. See mb-style thread at http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11724 and http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11943 . I support RFC-333, so I think classical album track titles should still follow recording titles, which follow standard titles stored in MBWorks. Just two notes: - I explicitly mentioned that RFC-333 does not apply to classical tracks, which always had different style guidelines in MB. - RFC-333 is not about recording title = track title = work title. It's about applying the same title normalization to them. As a result, that still means that tracks are as on cover, except with some stylistic changes. If some release decides to use a completely different title for a track, the recording title will be different from this track title. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Merging conductor and choirmaster
And also back in 2007 by me :) http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/3637 Lukas On Sun, Aug 28, 2011 at 4:41 PM, Nikki aei...@gmail.com wrote: This was actually suggested a while back in http://musicbrainz.1054305.n4.nabble.com/RFC-106-Conductor-change-amp-Chorus-Master-merge-away-RFC-266-Conductor-Position-new-AR-and-RFC-264--td3074121.html Nikki Nicolás Tamargo de Eguren wrote: Tere hommikust MB-Style! What would people think about merging the conductor and choirmaster rels into one, conducted [choir/orchestra]? I've found choirmasters credited as conductors many times in MB, and that is basically because both names are used for them! (Naxos, for example, use always conductor in their website). So merging them, with all the current choirmasters becoming choir conductor / conducted choir, and all the current conductors becoming just conductor / conducted (or maybe the script could check if there's an orchestra and no choir in the recording, and use orchestra conductor / conducted orchestra in that case) would be nice IMO. Thoughts? Praise? Insults? ___ 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] Sidebar links
I don't think this belongs to mb-style, as this has no impact on the MB data. On Wed, Aug 24, 2011 at 10:30 PM, Nikki aei...@gmail.com wrote: There's been some discussion by the devs about whether links to Secondhandsongs and Last.fm should be shown in the sidebar or not. After the drama for the SoundUnwound links, they'd like us to come up with a way of deciding what will be shown there. I find it kind of sad that the devs do not understand what caused the SoundUnwound drama. There is a difference between showing links that people added to the database because they think they are useful, and links that are automatically added to every single page because of a contract. In my opinion, we should not filter the URLs which appear in the sidebar. If it's in the database, it was added for a reason and I don't see why hide it. If we ever more recording/work relationships to the release page, it only makes sense to display all links on the release page too and the sidebar is the obvious place for them. There is a practical limitation that we don't have icons for all the websites, but if people contribute the changes to display them properly, I don't see why not accept them. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
It's been more than a week now, two people raised some issues but nothing serious enough to cause a veto, so this can be considered passed now. I'll the to update the wiki either today or tomorrow. Thanks! Lukas 2011/8/6 Lukáš Lalinský lalin...@gmail.com: It's been more than a week since the RFC and to my surprise there has been only one negative feedback, which I don't think is justifiable, because it ignores the basic problems that motivated me to propose these changes, which I mentioned in the initial email. All MB editors I know, except for jesus2099, agree with these changes. So, considering the +1s I got on the ML, here is the RFV. You can read the original threads here: http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11600 (my random thoughts) http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11724 (RFC) To summarize the changes, the style guidelines that we now have for recording and release group titles will apply also to track and release titles. 1) Style guidelines discussing track and release titles will be removed. http://wiki.musicbrainz.org/Style/Track_and_release_titles 2) Style guidelines discussing recording and release group titles will be changed to just titles as they refer to all titles we have in the database. I'd prefer to rename the wiki page to Style/Titles. http://wiki.musicbrainz.org/Style/Recording_and_release_group_titles Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
On Mon, Aug 8, 2011 at 3:21 PM, jesus2099 hta3s836gzac...@jetable.org wrote: LL It's been more than a week since the RFC and to my surprise there has LL been only one negative feedback, which I don't think is justifiable, LL because it ignores the basic problems that motivated me to propose LL these changes, which I mentioned in the initial email. All MB editors LL I know, except for jesus2099, agree with these changes. So, LL considering the +1s I got on the ML, here is the RFV. -1 VETO ← WCBI. ☞ Please tell me what were your « basic problems » that I « ignored » . The gmane links given give me a big text I thought I answered but please extract the points that I did not. 1) You did not understand why is having two style guidelines for track/recording is more difficult. You argued that if somebody enters normalized track titles, somebody would have to fix them to match the cover, which totally misses the point. 2) In the first post I explained how using as-on-cover track titles effectively removes an important feature that MusicBrainz had since the beginning. Normalized track titles are THE feature that brought me to MusicBrainz and I believe the same is true for many people. With as-on-cover track titles we lose this feature, because recording titles have no direct relation to the release, and so they miss the release context. Here I recall my basic problems : I’m against this merge that appears to make us loosing titles as they are on φ releases and we’ll end up with altered titles (inserting foreign abbreviations like “feat.” in our titles, Using Funny Caps etc.) which is bad when we know a title is being *consistently* in a certain different way that is not matching some people’s personal preferences. It's not about personal preferences, it's about having consistent data in the database. We are also setting informative text in recordings that will have now to go down to tracklists and that’s a real pity IMO : “がいながてや (live, 2009-12-29: Tōkyō JCB Hall, Japan)” ← we don’t want to alter the tracklist this way, it’s totally different from φ release. There is no style guideline that says to do this. This is why I VETO this RFV-333, maybe I didn’t understand anything when I’m flooded with tons of emails though. Then you should read only the two mails starting each thread, they explain every reason why I believe this change is necessary. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
On Mon, Aug 8, 2011 at 4:52 PM, Duke Yin yind...@gmail.com wrote: The problem with this proposal is that it is _extremely_ Anglo-centric, because the recording and release group guidelines are extremely Anglo-centric. If this proposal is to pass, I'd like to see... 1) Abbreviations should _not_ be expanded by default for countries where English is not the primary language, not least because it is sometimes hard to determine what the abbreviation actually stands for. (e.g., fw, which I've seen converted to a generic feat.). Ideally, I'd like see a stop to expanding Vol. by default for non-English releases as well (I still support separating it from the main title with a comma, since the indication of a vol* number is usually a font/size/color change) 2) Extra title information should _not_ always use parentheses. This is only bringing this bullet point of the recording guideline in line with the subtitles bullet point: If there is an alternative dividing punctuation mark such as the question mark (?) or exclamation point (!), use that mark instead of the colon. (The specific punctuation marks I have in mind here are the wavedash; hyphen; full-width space in languages which don't normally use spaces.) What you are addressing are issues with the recording style guidelines. As the examples below indicate, having two different versions of style guidelines is not a solution to these problems. You are free to propose changes to the guidelines if you think they are too strict. Basically, if the passage of this proposal would in any way change the following: http://musicbrainz.org/recording/26089c8d-00d0-416c-95c2-ffc80b46ae3f (feat. Artist in this title essentially means Artist version. There is no artist featured besides the primary artist, which is credited in the artist field.) http://musicbrainz.org/recording/a6f86c39-839b-4b24-b430-250a60832711 (ETI punctuation) http://musicbrainz.org/recording/7a98b745-cb1b-43f3-b95b-5207ed4f4adf (ETI punctuation) http://musicbrainz.org/recording/3dc62741-2e50-4489-86eb-b0de9d3d3242 (Japanese track, consistent original data, etc.) http://musicbrainz.org/recording/1b3e1dc6-c3f8-4931-82e2-f5b3cbb7d224 (Japanese track, consistent original data, etc.) http://musicbrainz.org/recording/4c144e39-be2e-488d-b10d-d7c4b93c53cd (Japanese track, spacing) Then I veto this, and will of course support any revisions which preserve the above examples. (this isn't a comprehensive list by any means - they were merely the first things I could think of quickly) Okay, here is an example why is this the wrong reason to veto this: - All these tracks/recordings were in MB before NGS, which means the old guidelines apparently did not apply to them. - If you think the current recording style guidelines should apply to them, it means the recording titles are wrong and you are not willing to fix them even though you can keep the titles like they are on tracks. This just shows that maintaining two versions of title guidelines is more difficult, which is one of the two main reasons for this proposal. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
On Mon, Aug 8, 2011 at 6:24 PM, J Chang fdkni...@hotmail.com wrote: Just a question: How will this unification of guidelines affect pseudo-releases that contain translations and transliterations of track titles? Obviously, tracklist titles will be different from the attached recordings as they are not separate recordings, merely transliterations/translations of the titles. I would guess that translated and transliterated tracklists for pseudo-releases would be exempt from having to match the recordings in name, but not in style? This proposal is about unifying title style guidelines, not the titles themselves. They can have entirely different content, but the content should follow the same style. That means you can translate it, or include any additional information that is available on the cover, but you have to properly capitalize it, consistently expand abbreviations, use the right punctuation characters. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV-333: Unify track/recording guidelines
It's been more than a week since the RFC and to my surprise there has been only one negative feedback, which I don't think is justifiable, because it ignores the basic problems that motivated me to propose these changes, which I mentioned in the initial email. All MB editors I know, except for jesus2099, agree with these changes. So, considering the +1s I got on the ML, here is the RFV. You can read the original threads here: http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11600 (my random thoughts) http://thread.gmane.org/gmane.comp.audio.musicbrainz.style/11724 (RFC) To summarize the changes, the style guidelines that we now have for recording and release group titles will apply also to track and release titles. 1) Style guidelines discussing track and release titles will be removed. http://wiki.musicbrainz.org/Style/Track_and_release_titles 2) Style guidelines discussing recording and release group titles will be changed to just titles as they refer to all titles we have in the database. I'd prefer to rename the wiki page to Style/Titles. http://wiki.musicbrainz.org/Style/Recording_and_release_group_titles Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
On Sat, Aug 6, 2011 at 11:04 AM, SwissChris swissch...@gmail.com wrote: …oops. What I mean is point 1.7 in Style/Recording guidelines overview: http://wiki.musicbrainz.org/Style/Recording_and_release_group_titles#Use_.28feat._Artist.29_if_an_artist_is_featured_on_a_recording. Appending feat. artists to track titles is now history ;-) I assume that this will be moved somewhere else before this proposal passes. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV-333: Unify track/recording guidelines
On Sat, Aug 6, 2011 at 11:09 AM, Philip Jägenstedt phi...@foolip.org wrote: 1. Will this RFV also add guidelines for what ETI should be included in track titles but not in release titles? Did you mean in track titles, but not in recording titles? In any case, no, I just want the current guidelines to be generally applied to all titles. More specific guidelines can be developed later. We already have one covering recording comments of live recordings, there will be probably more in the future. 2. Do you intend to submit a feature request for applying edits to both track and recording simultaneously, in the rather common case of fixing a typo or capitalization that applies to both? Already did that more than a month ago. :) http://tickets.musicbrainz.org/browse/MBS-2233 http://tickets.musicbrainz.org/browse/MBS-2895 Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-333: Unify track/recording guidelines
On Fri, Aug 5, 2011 at 2:00 AM, Ryan Torchia anarchyr...@gmail.com wrote: At the time this was proposed, the current recordings and release group style did not include the changes in RFV-327. It seems kind of sketchy that the discussion of how to treat track titles was specifically excluded from that discussion, yet will be implemented by this one. Except for capitalization, there are basically no style guidelines for track titles. That means most new releases already have featuring artists in the artist credit field, because that's most obvious way to do it. Applying the current style guidelines, somebody would have to change the recordings to match the featuring artist style (i.e. move the artists to the title), but this was not happening in practice and the artists stayed in the artist credit field. There was no need to discuss that in the RFV-327 thread, because in most cases tracks already artist credits like that. From my point of view, it was about making the style guidelines for recordings a little closer to what's happening for tracks. This change is about applying normalization even on the track level. That means that instead of A featuring B, A feat. B, A-FEAT.-B, etc. (which are currently all completely valid track artist credits), we will standardize it to A feat. B. If RFV-327 wasn't applied, we would standardize it to A - Title (feat. B). I'd have been fine with either way, as long as it's consistent. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV327: Featured artists
On Thu, Aug 4, 2011 at 5:24 AM, David Gasaway d...@gasaway.org wrote: On Wed, Aug 3, 2011 at 18:48, Andii Hughes gnu_and...@member.fsf.org wrote: Personally, I think the veto system is flawed and these proposals should go on a more democratic basis (which would make it pass 6-2), but the system is what it is. I never explicitly gave this my +1, so here it is: +1. +1 Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-333: Unify track/recording guidelines
On Tue, Aug 2, 2011 at 11:03 AM, jesus2099 hta3s836gzac...@jetable.org wrote: X « 3) Some other editor fixes the recordings, which adds even more work for voters. » J2 That’s also true when you enter altered titles and then someone with the release has to fix track titles back. PCB I'm not sure I understand the point. Having unfaithful tracklist to fix is same work load as the opposite that is described in 3) point. But that is precisely my point, having separate guidelines for titles and recordings means it's more difficult to maintain MusicBrainz. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-333: Unify track/recording guidelines
On Tue, Aug 2, 2011 at 11:39 AM, Frederic Da Vitoria davito...@gmail.com wrote: 2011/8/2, Lukáš Lalinský lalin...@gmail.com: On Tue, Aug 2, 2011 at 11:03 AM, jesus2099 hta3s836gzac...@jetable.org wrote: X « 3) Some other editor fixes the recordings, which adds even more work for voters. » J2 That’s also true when you enter altered titles and then someone with the release has to fix track titles back. PCB I'm not sure I understand the point. Having unfaithful tracklist to fix is same work load as the opposite that is described in 3) point. But that is precisely my point, having separate guidelines for titles and recordings means it's more difficult to maintain MusicBrainz. I disagree: As-printed wouldn't require a difficult guideline, while I am still unsure of the differences between tracks and recordings following your proposal. Because you although your proposal is titled unify track/recordings, they will end up different at some point. I don't believe they will end up fundamentally different (i.e. not knowing the difference wouldn't make the data you edit wrong). You always edit tracks in the first place, so you follow the cover and normalize the data using the usual guidelines that we had for years. In most cases the recording title will be identical. If there will be a difference between guidelines for track and recording titles, it will describe how to deal with recording titles if you have multiple different track titles. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-327: Featured Artists (attempt 2)
On Mon, Aug 1, 2011 at 9:42 AM, jesus2099 hta3s836gzac...@jetable.org wrote: -1 IMO we should follow actual release style. Sometimes the guest artist is part of the artist → we already use artist credit for that. Sometimes the guest artist is part of the title → somewhere in time we shall have the artist credit feature available in title (like discogs). I don’t think we shall move some title part to the artist field. Can you please give us an example where this is the case? I can only image cases when you have a tracklist without the primary artist, but the designer has to put the featuring artist somewhere, so they add it to the tracklist. That makes it looks like it's a part of the title, but I don't think that's the intention. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-333: Unify track/recording guidelines
On Mon, Aug 1, 2011 at 10:01 AM, jesus2099 hta3s836gzac...@jetable.org wrote: All this is called altering actual release metadata and can be avoided thanks to god-sent-at-last-tracks while keeping the ISO-1234/5678 funny stuff in recordings. As I mentioned, this is not what track titles were intended to be used for. It was said that inputting what’s on the release would be more difficult to new users. I don’t agree, it is actually easier to copy info than to apply some ISO-1234/5678 rules on it. It's hard to discuss something with you if you don't read my emails. I explained why is it more difficult. Can you please comment on the explanation? If you personally decide to not be interested in normalized recording titles, somebody else has to fix them, which adds more work for voters. Let the things like they are now for a little longer time before. If you want ISO-1234/5678 tags the option is there in Picard and it is presently what is done by foo_musicbrainz (no setting to choose track titles yet). I also answered this issue earlier. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-327: Featured Artists (attempt 2)
On Mon, Aug 1, 2011 at 12:58 PM, Ryan Torchia anarchyr...@gmail.com wrote: Even the long-term solution wasn't seeking to find a way to include featured guests into the artist field; the intent was always to express everything through ARs. I didn't know when I suggested it, but the ideas about removing the Artist field from recordings and allowing users to structure the Artist field from ARs is pretty similar to the plan that was outlined in getting rid of featuring artist style all along. The idea was to create a flattened Artist field from the relationships, not vice versa. I haven't read the whole thread, but note that the specific idea you linked to is referring to what we now have as artist credits and using them to store featuring artists. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV327: Featured artists
On Mon, Aug 1, 2011 at 3:28 PM, jesus2099 hta3s836gzac...@jetable.org wrote: -1 VETO Hum, so this is the actual thread we should reply to then. There are guest artists belonging to the track (T) title and collaboration artists in track artist (A). For A we have the new Artist Credit system. For T we still miss the equivalent Artist Credit system in track title that would show links to artists inside title. I’m for a status quo, meanwhile. Having a guideline like this or not, people will add featuring artist to artist credits. It was happening since the NGS release, because it seemed like the obvious move. If you notice the wiki page that Ryan linked to in the RFC thread [1], you will see that artist credits were originally designed to solve this problem. Having a guideline would help organize the change. Lukas [1] http://wiki.musicbrainz.org/Getting_Rid_Of_Featuring_Artist_Style#Implement_1:n_relationships_of_Artists_to_Tracks ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Recording/track distinctions
Hi everybody, I'm really not sure what to do, but I thought I'd at least give it a try. I'm personally unhappy with the NGS style guideline changes that increase the differences between track titles and recording titles. This is generally about the trend to have as-on-cover data in track titles. I know that many other editors (usually people from the top editors page that we used to have) disagree with these changes and I think we should do something about it, otherwise MB ends up with two groups, one of which will be ignoring the style guidelines and MB will become a mess. A little bit of NGS history. NGS was a fuzzy topic for a very long time. If there were concrete ideas, they were unrealistic to implement. What is currently implemented is basically based on my simplified NGS idea. The idea was to strip down the other NGS ideas and deal just with the most important problems, which were: track merging and multi-disc releases. The point is that this version of NGS was never intended to have such significant distinctions between recording and track titles. Track titles were meant to represent recording title variations in the context of the release. The same style guidelines would apply to both titles, recording title just being just the most commonly used track title. The recording/track model was mostly based on http://wiki.musicbrainz.org/TrackMerging which doesn't even consider explicitly maintained recording titles. The situation is now different and we are using track titles for as-on-cover titles, which I believe it wrong. It is wrong, because we have no alternative for properly normalized track titles that consider the context of the release. People think that recording titles solve that problem, but they don't because they don't include the release context, so you get problems like these: - Missing extra title information (e.g. album version, original mix or live) - Different spelling of the same language (e.g. UK/US releases) - Different language (e.g. identical official release with different titles in different countries, I don't count pseudo-releases here) There were the original problems why it was necessary to introduce track titles. We wanted to merge identical recordings, but doing it in the old database schema would mean we lose this information. Now, if you force people who liked MB for normalized data to use recording titles, they have to deal with these problems, but it's worse because recording merging is now reality. It's just like implementing recording merging without adding separate track titles. All in all, for these people (and I expect they are vast majority of MB users), NGS is worse than MB was before. Do you think it's possible to revert these style guidelines at this point? I expect that most people either never read them or ignored them, so there isn't much data changes, but I also expect that the people on mb-style are usually for these changes, so... :) Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
On Thu, Jul 21, 2011 at 11:00 AM, MeinDummy meindu...@nurfuerspam.de wrote: But it leaves those people standing in the rain who want titles in the database as they appear on release covers. And you cannot just ignore their wishes. This is not about ignoring their wishes. As I mentioned, what we have is a *simplified* NGS. It was meant to solve some specific problems in manageable steps (even if the step was way larger than expected), not all MB's problems. There are many other feature requests that were included in the original NGS plans, but not included in this iteration. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
On Thu, Jul 21, 2011 at 10:01 AM, Frederic Da Vitoria davito...@gmail.com wrote: Could you give actual examples of your issues? I find it difficult to understand what you think is wrong. 1. http://musicbrainz.org/recording/1b7be9fe-fbeb-4941-b1f7-7eaf9fa9f99e -- Different languages. Let's say I have the 1981 US release, I do not want Les Chants magnétiques, Part 1 in my tags, but I do not want Magnetic Fields Pt. 1 either (or whatever the cover says). 2. http://musicbrainz.org/recording/c59cbf07-eab6-46e3-a68c-ffaebef21f2c http://musicbrainz.org/recording/6f7e213c-81cb-419d-9cfd-6912b74620a2 -- These are really the same recordings, but the remixes are named slightly differently on different releases. I do not want to lose the different naming. 3. http://musicbrainz.org/recording/3d953e11-c417-4034-a5d1-d0f41405337e -- Disambiguation information like (live) shouldn't really be part of the recording title, because it's inconsistent with live releases that usually do not explicitly mention that. On the other hand, it should be in the track title if the release explicitly says so. I do not know of a recording that is from a live release and later included on a complication/album, but I'm sure many of them exist, I just don't listen much to music that can actually be performed live. 4. http://musicbrainz.org/recording/d1623f2f-e59f-478d-988a-48bfa14a2100 http://musicbrainz.org/recording/3b6fa084-0863-4791-8c3e-f4abf549afa7 -- Same recording, but has original mix included on the single release. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
2011/7/21 Lukáš Lalinský lalin...@gmail.com: On Thu, Jul 21, 2011 at 10:01 AM, Frederic Da Vitoria davito...@gmail.com wrote: Could you give actual examples of your issues? I find it difficult to understand what you think is wrong. 1. http://musicbrainz.org/recording/1b7be9fe-fbeb-4941-b1f7-7eaf9fa9f99e -- Different languages. Let's say I have the 1981 US release, I do not want Les Chants magnétiques, Part 1 in my tags, but I do not want Magnetic Fields Pt. 1 either (or whatever the cover says). 2. http://musicbrainz.org/recording/c59cbf07-eab6-46e3-a68c-ffaebef21f2c http://musicbrainz.org/recording/6f7e213c-81cb-419d-9cfd-6912b74620a2 -- These are really the same recordings, but the remixes are named slightly differently on different releases. I do not want to lose the different naming. 3. http://musicbrainz.org/recording/3d953e11-c417-4034-a5d1-d0f41405337e -- Disambiguation information like (live) shouldn't really be part of the recording title, because it's inconsistent with live releases that usually do not explicitly mention that. On the other hand, it should be in the track title if the release explicitly says so. I do not know of a recording that is from a live release and later included on a complication/album, but I'm sure many of them exist, I just don't listen much to music that can actually be performed live. 4. http://musicbrainz.org/recording/d1623f2f-e59f-478d-988a-48bfa14a2100 http://musicbrainz.org/recording/3b6fa084-0863-4791-8c3e-f4abf549afa7 -- Same recording, but has original mix included on the single release. Oh, and to give an example of recording/title artist credits. http://musicbrainz.org/release/611e82cc-5db0-39d0-b47e-df42b75c748c http://musicbrainz.org/release/676c4e84-2d7d-3b32-a4fd-c686dca083ad The US release should have Yaz as the artist credit, but it would get normalized to Yazoo, which is not necessarily what you want. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
On Thu, Jul 21, 2011 at 1:20 PM, Frederic Da Vitoria davito...@gmail.com wrote: 2011/7/21, Lukáš Lalinský lalin...@gmail.com: Oh, and to give an example of recording/title artist credits. http://musicbrainz.org/release/611e82cc-5db0-39d0-b47e-df42b75c748c http://musicbrainz.org/release/676c4e84-2d7d-3b32-a4fd-c686dca083ad The US release should have Yaz as the artist credit, but it would get normalized to Yazoo, which is not necessarily what you want. I believe this is a different issue (although related). Doesn't this have implications in the code itself? Does MB actually allow to link to an alias? Artist credits and track titles are essentially release-specific aliases for artists and recordings. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
On Thu, Jul 21, 2011 at 1:14 PM, Frederic Da Vitoria davito...@gmail.com wrote: I'm going to need a little more info :-) 2011/7/21, Lukáš Lalinský lalin...@gmail.com: On Thu, Jul 21, 2011 at 10:01 AM, Frederic Da Vitoria davito...@gmail.com wrote: Could you give actual examples of your issues? I find it difficult to understand what you think is wrong. 1. http://musicbrainz.org/recording/1b7be9fe-fbeb-4941-b1f7-7eaf9fa9f99e -- Different languages. Let's say I have the 1981 US release, I do not want Les Chants magnétiques, Part 1 in my tags, but I do not want Magnetic Fields Pt. 1 either (or whatever the cover says). Then what do you want? I want my tags to contain Magnetic Fields, Part 1, which is the title localized for the release that I have, but normalized according to the usual MB guidelines. 2. http://musicbrainz.org/recording/c59cbf07-eab6-46e3-a68c-ffaebef21f2c http://musicbrainz.org/recording/6f7e213c-81cb-419d-9cfd-6912b74620a2 -- These are really the same recordings, but the remixes are named slightly differently on different releases. I do not want to lose the different naming. What is actually printed on each release? I don't know, I don't have the physical releases. Let's assume one says No Good (Start the Dance) [CJ Bolland's Museum mix] and the other one says No Good (Start the Dance) (CJ Bolland's mix). With as-on-cover track titles, I'm forced to use recording titles. If I use recording titles, I can only use one variant on all releases. 3. http://musicbrainz.org/recording/3d953e11-c417-4034-a5d1-d0f41405337e -- Disambiguation information like (live) shouldn't really be part of the recording title, because it's inconsistent with live releases that usually do not explicitly mention that. On the other hand, it should be in the track title if the release explicitly says so. I do not know of a recording that is from a live release and later included on a complication/album, but I'm sure many of them exist, I just don't listen much to music that can actually be performed live. I don't understand your argument here. A recording does not belong to a release, it happens to be part of a release, which is a completely different thing. So I don't see how you can avoid putting some disambiguation information on the recording (in the title or in the comment). What I'm saying that the recording shouldn't have (live) in the title. It should be moved to the disambiguation comment. But the recording is included in a release that explicitly marks is as Death of the Prodigy Dancers (live). I want my tracks to have Death of the Prodigy Dancers (live), not Death of the Prodigy Dancers. On the other hand, if the concert from which the track is was released, I would want it as Death of the Prodigy Dancers in the context of the live release. 4. http://musicbrainz.org/recording/d1623f2f-e59f-478d-988a-48bfa14a2100 http://musicbrainz.org/recording/3b6fa084-0863-4791-8c3e-f4abf549afa7 -- Same recording, but has original mix included on the single release. Are these the same master (indistinguishable by ear) or do they sound different? I wouldn't merge recordings that sound different. :) Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
On Thu, Jul 21, 2011 at 1:20 PM, symphonick symphon...@gmail.com wrote: On Thu, 21 Jul 2011 13:10:05 +0200, symphonick symphon...@gmail.com wrote: On Thu, 21 Jul 2011 12:15:28 +0200, Lukáš Lalinský lalin...@gmail.com 1. http://musicbrainz.org/recording/1b7be9fe-fbeb-4941-b1f7-7eaf9fa9f99e -- Different languages. Let's say I have the 1981 US release, I do not want Les Chants magnétiques, Part 1 in my tags, but I do not want Magnetic Fields Pt. 1 either (or whatever the cover says). So you want the English release to have Part 1 instead of Pt. 1? (it has now, but let's assume Pt. 1 is what's printed). I'm fine with minor standardizing, as long as I can enter the release in all available languages. BTW recording aliases would solve the language issue? Not really, because on the recording level you don't have the release context. You could say that it's possible to match the release language and the recording language, but it's not uncommon to have tracklists with multiple languages. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
On Thu, Jul 21, 2011 at 3:18 PM, Frederic Da Vitoria davito...@gmail.com wrote: 2011/7/21 Lukáš Lalinský lalin...@gmail.com On Thu, Jul 21, 2011 at 1:20 PM, Frederic Da Vitoria davito...@gmail.com wrote: 2011/7/21, Lukáš Lalinský lalin...@gmail.com: Oh, and to give an example of recording/title artist credits. http://musicbrainz.org/release/611e82cc-5db0-39d0-b47e-df42b75c748c http://musicbrainz.org/release/676c4e84-2d7d-3b32-a4fd-c686dca083ad The US release should have Yaz as the artist credit, but it would get normalized to Yazoo, which is not necessarily what you want. I believe this is a different issue (although related). Doesn't this have implications in the code itself? Does MB actually allow to link to an alias? Artist credits and track titles are essentially release-specific aliases for artists and recordings. Ok. Then I suppose that you expect US pro-as-printed users to ask to link to Yaz. And you would rather tag it to Yazoo? Am I correct? Once again I can understand both positions. In this situation, we could imagine some option to fetch the fundamental Artist (Yazoo) instead of the immediate one (Yaz). What I mean that the US version should point to Yazoo with the artist credit Yaz, no matter if we decide to use as-printed or normalized titles/names. The problem is that if tracks are not normalized, people who want clean data can't use them. They have to rely on recordings and recordings will always use the artist credit Yazoo, which is not what owners of the US release want. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
On Thu, Jul 21, 2011 at 3:18 PM, Frederic Da Vitoria davito...@gmail.com wrote: I want my tags to contain Magnetic Fields, Part 1, which is the title localized for the release that I have, but normalized according to the usual MB guidelines. Ok. I guess normalized and localized recording titles would solve your problem here. See my response to symphonick. Localized recording titles still miss the release context. What I'm saying that the recording shouldn't have (live) in the title. It should be moved to the disambiguation comment. But the recording is included in a release that explicitly marks is as Death of the Prodigy Dancers (live). I want my tracks to have Death of the Prodigy Dancers (live), not Death of the Prodigy Dancers. On the other hand, if the concert from which the track is was released, I would want it as Death of the Prodigy Dancers in the context of the live release. Wouldn't this be what would happen if we used as-printed? Yes, but track titles don't exist for me, because they contain non-normalized data. I can only use recording titles. :) Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre-RFC: CSG - work types
On Thu, Jul 21, 2011 at 10:27 AM, Frederic Da Vitoria davito...@gmail.com wrote: More generally, I'm starting to wonder if we should not request Advanced Attributes. These would work like Advanced Relationships but instead of linking 2 items, they would be linked to only one item. We could categorize AAs just like we do with ARs, create new ones, add AAs to elements which need them, all this without requiring a schema modification. For example, in this case, we'd need a musical form and an instrumental form. Catalog numbers could be implemented as AAs, and we could link them to classical works without creating a field which would remain empty in all non-classical works. Just a note that dynamic attributes were one of the main ideas behind works (thingies, really :)) in NGS, they just weren't implemented in this iteration. http://www.flickr.com/photos/mayhem/539420358/ http://users.musicbrainz.org/~luks/tmp/works.png Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recording/track distinctions
On Thu, Jul 21, 2011 at 6:56 PM, Kuno Woudt k...@frob.nl wrote: As-on-cover track and release fields to some extent solves both issues, it makes it much easier for editors to get started. They ignore the main reason that brought many of the top editors to MusicBrainz -- data consistency. I have no problem with making the guidelines less strict. When I was more active at editing/voting, I was usually the kind of voter who votes yes on imperfect additions/changes, because they add some value to the database. The current style guidelines however support non-normalized track titles, which is a different issue. I don't mind at all if somebody enters a release that doesn't confirm 100% to all the guidelines, but I do mind if somebody on purpose changes the normalized data to something that more closely represents the album cover. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] VolumeNumberStyle in NGS?
Same for me. When working on the NGS, I always imagined that track/release titles will be still normalized but allow variations in extra title information, different language or possibly different credits. That means that we would no longer have consistency on these titles, but most of the normalization guidelines would still apply, so they would have proper capitalization, expanded abbreviations, standardized way to enter extra title information, etc. Lukas On Tue, Jun 7, 2011 at 7:01 AM, mudcrow mudc...@googlemail.com wrote: I'm with Jeff. I'd hate to see the end of normalization. On Tue, Jun 7, 2011 at 12:16 AM, StoneyBoh js...@mindless.com wrote: Date: Sat, 4 Jun 2011 22:11:52 +0200 On Sat, Jun 4, 2011 at 21:41, Frederic Da Vitoriadavito...@gmail.com wrote: 2011/6/4 Nicol?s Tamargo de Egurenreosare...@gmail.com On Sat, Jun 4, 2011 at 7:59 PM, Philip J?genstedtphi...@foolip.org wrote: Is volume number style still relevant with NGS? Based on what I've seen from the NGS-enabled Picard it seems like going forward we will start treating the release group titles as the normalized titles, and then let the release titles reflect the cover. Is this correct? Is it OK to start changing release titles to things like Beloved Music Box Vol.5 right now? IMO, this would make perfect sense, but does of course need some getting used to. I would fully support this. Normalization would still apply to the RGs, wouldn't it? Yes, please see the RFC I sent out and see if that is clear enough on this point (and otherwise reasonable). Am I the only one that thinks this will be confusing to many users? I mean the concept of release groups is a relatively stealth one in the new UI. So, on one page, one sees the normalized name, clicks on it and the next page a non-normalized one? Seems to me that might confuse some ... maybe even me. At least with tracks and recordings and works, there seems to be a more clear demarcation between the various entities in the interface, but I don't see it that way with release groups. Perhaps I am in the minority, but I personally really like the normalized names in MB. I think it is a good idea to have a set of data that consistently treats secondary information like part numbers, volume numbers, capitalization, etc. the same way. I see those - especially volume numbers on cover art - as more of a graphic choice than artist intent in the vast majority of cases. I've said it before, but I believe that the normalizing we have done is one of the many things that distinguishes MB from other sites services. Will I be able to get release groups titles served to Picard if I prefer the normalized names? That would help but, it introduces other issues as sometimes there are releases in the same release group that have completely different titles, and in that case I don't want to see the release group name, I want the release. I also wonder what to think about the thousands (tens of thousands, maybe?) that have already been normalized. That's not a reason not to change something if the change is for the better, but we will certainly then have to be expect that there will be a mix of normalized and non-normalized release titles for the foreseeable future. I guess I'd like to know if I am the only one that sees things this way? Jeff ___ 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] VolumeNumberStyle in NGS?
On Tue, Jun 7, 2011 at 10:53 AM, Frederic Da Vitoria davito...@gmail.com wrote: I don't understand you. IMO this would be quasi-redundancy, adding extra layers with little benefit. What kind of benefit did you expect from NGS? Well, two primary uses cases that I had on my mind were: - Extra title information depending on the release context, e.g Track X (album version) on a single, but Track X on the album. - Officially translated releases, for example http://musicbrainz.org/release/2f8b76c6-d705-4395-bac4-0a8abce3316c and http://musicbrainz.org/release/750292bf-35cd-41a9-9135-e06b1c2a54da In the case of translated releases, you can see that use the recording title doesn't solve the issue if I want properly normalized track titles, but I have an English version so I want English track titles. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] VolumeNumberStyle in NGS?
On Tue, Jun 7, 2011 at 11:43 AM, Frederic Da Vitoria davito...@gmail.com wrote: Don't you think this would be a little difficult to explain to users? Change the title if the variation is small, but don't change it if it is large. I know, this is not how you would explain it, but this is what it would amount to. I think that the guidelines regarding release/track titles should be based on the previous guidelines, white-listing things that don't have to be applied to recording/track titles. If we want to allow people to submit releases as on cover without reading the release group/recording guidelines, we will end up with a FreeDB clone. Normalizing track titles to get a normalized translation seems quite interesting to me, but I feel this would be perverting the database structure. Translations should have their own place IMO, and I believe everything we do until we reach that point should only be temporary measure. A temporary measure should never limit normal uses. Hmm, I feel I am not quite clear here. I disagree. I'm not talking about pseudo releases, that users translate for their convenience. I'm talking about official releases with different barcodes that simply have titles in different languages. I see them as different releases, not just translations of the release in the primary language. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] VolumeNumberStyle in NGS?
2011/6/7 Nicolás Tamargo de Eguren reosare...@gmail.com: On Tue, Jun 7, 2011 at 3:09 PM, Frederic Da Vitoria davito...@gmail.com wrote: 2011/6/7, Lukáš Lalinský lalin...@gmail.com: I think that the guidelines regarding release/track titles should be based on the previous guidelines, white-listing things that don't have to be applied to recording/track titles. If we want to allow people to submit releases as on cover without reading the release group/recording guidelines, we will end up with a FreeDB clone. I really don't think so. IMO the problem with FreeDB is redundancy and mistakes, so that it is very difficult to decide which is the correct information when offered more than one answer and when you get only one release, you're not even sure it is error-free. What we are suggesting has nothing to do with these issues. Allowing to enter titles as printed would not create redundancy (in a way, it would be the contrary), and requiring to enter it as printed does not make it harder to check or correct. What is actually printed is a piece of information which has it's value. I already said this before: if I had to choose between as printed and normalized, I wouldn't hesitate and choose normalization. But we can have both, and I know some (many?) users want the printed data. My thoughts exactly. My only concern is that we are losing some kind of information that I happened to like. In the old MB, we used to have normalized titles that were still release-specific. With the approach, we either have as on cover titles, which are useless to me, or we have globally normalized titles that don't directly correspond to the release that I have. Maybe this is only a minority of the data, but it makes MusicBrainz less useful to me. I think that abbreviations fall into the category of things that we should make consistent. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: [none] for no catalog number
On Tue, Jun 7, 2011 at 2:04 PM, jacobbrett jacobbr...@hotmail.com wrote: The redundancy is storing the six characters of text [none] over and over, compared to a 1 or 0. The latter also avoids typos. A big disadvantage is that the boolean field can't be added any time soon. MB has a history of adding hacks quickly and then eventually migrating them. :) Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] VolumeNumberStyle in NGS?
On Tue, Jun 7, 2011 at 6:23 PM, Nikki aei...@gmail.com wrote: Lukáš Lalinský wrote: MusicBrainz less useful to me. I think that abbreviations fall into the category of things that we should make consistent. What about when a series consistently uses Vol.? The current volume numbers guideline permits anything if it's used consistently (volume, book, tome, just the number, etc) as long as it's not an abbreviation, which just seems completely arbitrary to me. I can understand making a series consistent within itself, but expanding abbreviations for the sake of abbreviations doesn't really make sense to me. I don't have a strong opinion about that, I primarily want to keep the data consistent across series. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG: Less VA?
On Fri, May 20, 2011 at 9:57 AM, Nikki aei...@gmail.com wrote: Frederic Da Vitoria wrote: Tjaijkovskij Bramhs is definitely better than VA IMO, although it tends to suggest that the release contains some work composed by both. What would be perfect (but will probably never happen) would be to be able to file a Release under n Artists rather than only one. I notice that your suggestion implicitely put composers in the Release's track order (you did not write Bramhs, Tjaijkovskij) which is a good idea. Filing a release under n artists is exactly what artist credits do. If you don't want it to look like a collaboration, I suggest something other than as the join phrase. ;) I'd suggest / , as that's what we use to separate other things and I'd like to start using it for tracks with multiple artists (http://wiki.musicbrainz.org/TracksWithMultipleArtists). Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Concept of works group
On Thu, May 19, 2011 at 12:29 PM, caramel carame...@ymail.com wrote: I discussed in other threads about the concept of works, super-works and sub-works. It is specially relevant for classical works but may be not reduced to them. Actually there is a work type (with aggregate attribute) but seems not to work... The work type doesn't work because we didn't define what would be useful to have there, but it was intended precisely for having multiple layers of works as you describe. 1. If we consider the Bach's St John Passion. There are 68 individual pieces with the first sentence of lyrics as (sub-)work names. All the ARs given for the first piece (composer, year, lyricist,...) have to be set for the 67 other works. The score is for all the composition too, not only a small piece of few bars. 2. There is no ARs between the (sub-)works of one composition. Nor ARs between works of one collection (super-work, eg. (the three) Gymnopédies) All this still has to be defined. Adding work-work AR types as well as work types is easy to do technically, but hard to define what exactly do we want to track. NGS was meant to mainly improve on the release/recording model, the minimalistic work model was added to experiment with the data and see how to make it useful. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] Works and remixes/covers
The original NGS documentation which was written by me [1] says that works with different remixes should be merged together. The Work page [2] however says that they should be kep separate. All people I've discussed this with agree that they should be merged. Can I change the Work page to remove the mention of remixes? Lukas [1] http://wiki.musicbrainz.org/Next_Generation_Schema#Work [2] http://wiki.musicbrainz.org/Work ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Extra Title Information vs Recording comment in NGS
On Wed, Jan 12, 2011 at 2:12 PM, Aurélien Mino a.m...@free.fr wrote: Hi, I would like to propose the following change during NGS migration: Move the extra title information of recording from the 'name' field to the 'comment' field, while keeping track titles untouched. Examples: 11 O'Clock Tick Tock (live) would become 11 O'Clock Tick Tock with comment live Without change: http://test.musicbrainz.org/recording/24d39446-175e-4522-87f3-6c19ca3e76e4 With change: http://test.musicbrainz.org/recording/e34ce26c-9060-4646-98e0-388e6ff340b2 My reasoning is that extra title information is not really part of the recording title, and we now have a specific field for this kind of information. I don't agree with this. Take for example Talking All That Jazz (Torti's Old School Mix of Edits dub) -- I'd argue that having only Talking All That Jazz in the recording title would cause a lot of confusion. I also think that this change would make the comment field much less useful, because if it's treated as a part of the title, people will not be willing to add information that could help identifying the recording, but it's not necessarily a title to the comment. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Extra Title Information vs Recording comment in NGS
On Wed, Jan 12, 2011 at 8:41 PM, Aurélien Mino a.m...@free.fr wrote: On 01/12/2011 03:45 PM, Lukáš Lalinský wrote: I don't agree with this. Take for example Talking All That Jazz (Torti's Old School Mix of Edits dub) -- I'd argue that having only Talking All That Jazz in the recording title would cause a lot of confusion. I also think that this change would make the comment field much less useful, because if it's treated as a part of the title, people will not be willing to add information that could help identifying the recording, but it's not necessarily a title to the comment. Could you then provide examples of information you're expecting to be added as comment? - album version - the detailed descriptions from http://wiki.musicbrainz.org/Live_Track_Style - iTunes-exclusive bonus track - karaoke version - Spanish lyrics - 2001 digital remaster - 2008 studio re-recording Anything that will help you disambiguate the recording from identically named recordings. I may acknowledge that remix information should be kept in recording title, however I disagree with you on live: I don't see why (live) should be part of the title, it's a meta information. Maybe, but the (live) or [live] suffix is a very common way to mark live recordings. Anyway, I'm not either completely for or against having live in recording titles, but I disagree with moving all extra title information to comments. You wouldn't include (studio) in recording titles from a studio album, would you? No, I wouldn't, because that is the standard way of recording music. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] PUID differentiation
On Wed, Nov 17, 2010 at 10:38 PM, Frederic Da Vitoria davito...@gmail.com wrote: 2010/11/17 Simon Austin chi...@auzsoft.net Is there a way to tell PUIDs apart? I suspect one or more of these is mis-applied, but I'm not sure how to work out which http://musicbrainz.org/show/puid/?puid=4f91eadd-92a2-377f-d27e-7eb8714efbd5 I believe they could both be correct :-( IIUC, PUIDs use the beginning of the track They also use track lengths. Tracks with length difference greater than ~10 seconds will never get the same PUID assigned by the MusicDNS servers. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Ellipses, quotation marks, and the miscellaneous guideline
On Tue, Nov 16, 2010 at 9:05 AM, Nikki aei...@gmail.com wrote: jacobbrett wrote: On that note, is there a similar plugin/script that converts Unicode characters to ASCII equivalents, though only for the file name? If it's possible to do that, I'd love to know how! It would be really useful to be able to tag non-latin stuff with the original titles but use a transliteration for the file names. You could make the plugin define a TaggerScript function (see e.g. [1]) that does the conversion and then use it for file formatting (e.g. $asciize(%artist% - %track%)). Lukas [1] http://bazaar.launchpad.net/~musicbrainz-developers/picard/trunk/annotate/head:/contrib/plugins/swapprefix.py ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Re-add [traditional]
On Sun, Oct 10, 2010 at 1:16 PM, Nikki aei...@gmail.com wrote: This proposal is simply to re-add [traditional] as a special purpose artist. There's been a number of people recently giving their support to re-adding it in http://forums.musicbrainz.org/viewtopic.php?pid=11319 and in several edits. +1 I was really surprised when it was merged. Lukas ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS RFC: Make works not be filed under an artist (Was: Spurrious works)
On Wed, Apr 7, 2010 at 9:22 AM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: I doubt it's just my point of view, as it was the idea being used by anyone, except it would seem, yourself, who has talked on the lists, wiki, or IRC at all about works in the past 2 years. I'm not just talking about the clean up CSG threads. I'm talking about the composition-layer object going all the way back to http://wiki.musicbrainz.org/Object_Model/Composition_Object . I'm talking about the Work visible in http://www.flickr.com/photos/mayhem/539420358/sizes/l/ , where I and others clarified in IRC that yes, that Work was the composition layer. So that's anywhere from 2005 to Summit 8, plus then http://wiki.musicbrainz.org/Work . We are getting off-topic, but I was there when the picture was taken. I'm pretty sure the Work entity there is meant the way I'm describing it. :) It was actually meant to be even more flexible, to hold also informations like Recording Sessions. (Also note that the Work page was called MusicalWork before navap renamed it). Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS RFC: Make works not be filed under an artist(Was: Spurrious works)
On Wed, Apr 7, 2010 at 1:58 PM, autod...@davesmey.com wrote: Whatever you call them - Works, LKWorks, etc - the fact remains that they would be Work entities. The mere fact that you can so clearly separate LKWorks from Works is why I'm saying they shouldn't be mixed together as the same thing. I would have no problem with a songThingie entity, which links to each performance by a specific artist of a specific work. What I do have a problem with, however, is overloading Works with that entity. Additionally, I think any recording has a 'songThingie', but (as we talked about elsewhere), I don't think every recording has a work. As two separate entities, it makes sense. All lumped into the Work entity, it's quite clear that there's two completely different concepts being forced to share the same dataspace. Basic question - are works/thingies going to be freely recursable? Can I create work1 that is parent to work2 and work3? Even as composition objects, we might want this, for different versions of the same piece. I agree that on the level of guidelines and UI, we'll want to very clearly differentiate between Works LKWorks and whatever other meta-class we might come up with. But the most elegant datastructure might be an abstract, recursable object with as few fields as possible, and everything added to it by AR. (The only essential fields might be name and what kind of thing am I.) This is what NGS works were meant to represent. The UI will not make the distinction between work types in the initial NGS release, but the plan is *exactly* what you are describing. You can use ARs to create any structure you want. There will be per-type textual attributes for works (for representing data that are not links, for ISWC makes only sense for some types), but not in the initial release. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Clean up link phrases
On Wed, Apr 7, 2010 at 2:00 AM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: The extended RFC period having now expired, this proposal is now in RFV. I don't really see how do you want to do the change for 'programmed'. There is an instrument attribute which collides with your link phrase. I'd like to see the actual link phrases on the page. I disagree with changing online community to social networking. I disagree with changing the performance name AR. You are adding there terms that make the AR more specific than it currently is. I also believe that 'performs as' is clearer than 'uses the stage name'. If anything, it should be 'uses a stage name'. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS RFC: Make works not be filed under an artist (Was: Spurrious works)
On Sun, Apr 4, 2010 at 6:28 AM, Philip Jägenstedt phi...@foolip.org wrote: On Sun, Apr 4, 2010 at 06:43, Brian Schweitzer brian.brianschweit...@gmail.com wrote: 1) In NGS, a Work is 'filed' under an Artist, just as Releases, Tracks, Release Groups are now. Since this has nothing to do with spurious works, I'm spinning off a new thread. In the last NGS beta works were not implemented, so I assume it's not a done deal how they are going to be handled. If we have the opportunity to design it as we want, I would suggest: Let works not be filed under an artist, but rather be associated only by their ARs. Otherwise we will be wasting time trying to figure out which artist to file it under and there's a risk that the composer ARs is seen as redundant and not added, making the data less precise and reliable. I initially thought that perhaps it's because we're using a relational database and the indirection would be too slow (a join), but since we are able to generate pages like http://musicbrainz.org/show/artist/appears-on.html?artistid=35536 I don't think that's the case. The other issue is UI, but I refer to the URL of the previous sentence to show that it's not a problem. Thoughts? Think of works outside of the classical genre, think of them as songs. Songs usually do have an artist associated with them. For example, most Beatles songs were composed by Lennon/McCartney, but not all of them. Would you not find it useful to see a list of all Beatles works, including cover versions of other songs they made? You can argue that you can take the band member's ARs and show those works. It's not that uncommon that totally unrelated artist compose songs for performers (most pop songs), yet you would like to see the songs also under the performers. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS RFC: Make works not be filed under an artist (Was: Spurrious works)
2010/4/4 Lukáš Lalinský lalin...@gmail.com: Think of works outside of the classical genre, think of them as songs. Songs usually do have an artist associated with them. For example, most Beatles songs were composed by Lennon/McCartney, but not all of them. Would you not find it useful to see a list of all Beatles works, including cover versions of other songs they made? You can argue that you can take the band member's ARs and show those works. It's not that uncommon that totally unrelated artist compose songs for performers (most pop songs), yet you would like to see the songs also under the performers. Btw, I also considered only using ARs for this and link the songs to Beatles or Britney Spears by ARs, but at the end I found it more practical to use a direct artist link. Using only ARs would be cleaner, but it would require a different user interface, which would delay NGS even more. Migrating from the direct artist link to ARs in the future shouldn't be that difficult. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS RFC: Make works not be filed under an artist (Was: Spurrious works)
On Sun, Apr 4, 2010 at 7:39 PM, Frederic Da Vitoria davito...@gmail.com wrote: Think of works outside of the classical genre, think of them as songs. Songs usually do have an artist associated with them. For example, most Beatles songs were composed by Lennon/McCartney, but not all of them. Would you not find it useful to see a list of all Beatles works, including cover versions of other songs they made? You can argue that you can take the band member's ARs and show those works. It's not that uncommon that totally unrelated artist compose songs for performers (most pop songs), yet you would like to see the songs also under the performers. Interesting. But will the Artist field for these songs contain Lennon/McCartney or the Beatles. In the first case, I don't see any difference with the purely AR system. We'll probably have to resort to some sort of equivalence list. If it is the Beatles, then there is something I don't understand here. It would the Beatles. The way I see it is that the artist field is something that along with the title identifies the work. Even for classical works you have to say Beethoven's Symphony No. 7, because there are many Symphonies No. 7. Most of the time when somebody refers to a popular song, they refer to X by Y, not just X. I believe it's important to not loose that information. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] NGS RFC: Make works not be filed under an artist (Was: Spurrious works)
2010/4/4 Brian Schweitzer brian.brianschweit...@gmail.com: That info isn't lost; it's in the recording and performance ARs, where it belongs. You've left out the important 'action word' in that X by Y. You're talking about X (performed by) by Y, but that, to me, is inherently a Recording concept. The Work concept would be X (created by) by Y. No, I've not left out anything. X by Y is an non-unique identifier. It's an identifier that normal people use when referring to songs. Just as well they say Bethoven's 7th Symphony even though beethoven didn't perform it. It says nothing about the artist's role, it's just an identifier of the work. By the above reasoning, if the performer for pop matters more than who composed it, then (ignoring arrangement questions here) http://musicbrainz.org/release/1ccd99ff-595a-40e5-8da5-1461b766e297.html would represent 22 unique works, not 1 - and it would seem to me, the entire point of a 'work', which holds composition info, not performer info, is lost. Yes, there would represent 22 unique works, each of them linked to the original version. 'Beethoven's Symphony 7' talks about the 7th symphony created by a composer; 'All You Need is Love by the Beatles' talks about the performers of the song - 'All You Need is Love by John Lennon' would be talking about the creator of the song, not the performer(s). Then we disagree, from my point of view 'All You Need is Live' was created by the Beatles. It was composed by John Lennon, but the whole song was created by the Beatles. Additionally, go back 40 or 50 years in pop - almost nothing was written by the performer. Would you list the 'great American songbook' songs under whoever happened to perform them each time, rather than the composer? Same problem - 1 work now becomes a multitude of works, and the point of works is lost. It isn't. As I said multiple times on multiple threads, works are not meant to be a list. They are a graph. Works are linked to other works. All those pop songs are written for a particular performer. The composition takes into account the artist and the expected performance. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] What Track ARs should become Work ARs, or both Recording and, Work ARs?
On Fri, Mar 26, 2010 at 5:03 AM, caller#6 meatbyproduct-musicbra...@yahoo.com wrote: I've been hoping that the Work entity would be broad enough to cover multiple versions of traditional songs (which often have variant lyrics and titles). The recent chat logs on the subject are making me less hopeful. There is nothing stopping us from adding another work type, add traditional songs as works of that type, and link to all versions of the song. Works were intended to form a tree structure (or perhaps even graph), not a flat list. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Important: NGS ARs are now ok to propose - please read.
On Wed, Mar 24, 2010 at 2:45 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: That brings me to Works. We kind of went into detail about Works when the idea was brought up during Clean up CSG. Or, if you remember the Object Model from years ago, Works are basically the Composition Object. (The Recording Object, Mix Object, and Master Object levels are not part of the initial NGS schema; who knows if they'll ever be part of any schema.) A Recording represents the actual audio; a Work represents the composition. Just a note, you are misinterpreting it AGAIN. :) Works are meant to represent much more than the Composition Object. Sure, that will probably cover the most works in the database, but works are meant to represent anything above the recording layer. For example, we can have an Orchestra work type that will be linked to all individual compositions of a classical piece. We can also have Remix or Cover type to represent modified versions of a Composition. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Release Event Style
On Mon, Mar 22, 2010 at 5:16 PM, Pavan Chander pchan...@gmail.com wrote: An NGS-release represents the physical issuing of an album/single/compilation, on a specific date, in a specific country, with specific packaging, with a specific set of mediums (with specific medium formats), with a specific set of tracklists. If an NGS-release exists in the database and you are holding in your hand a physical album that has even one piece of data that is different from all those said above - you're going to be adding a totally new NGS-release to the database to represent it. (I purposely left out the label/catalog number fields because I'm not 100% sure how that will work. An NGS-release can have multiple label/catalog numbers.) Labels and catalog numbers will work the same way as the other attributes you described. If you have a release which has a different catalog number, add a new release. The only reason why there is a list, not just one, is to handle releases which actually have multiple catalog numbers. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add UMD as a release format (SwissChris)
On Tue, Mar 9, 2010 at 3:40 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: It sounds as though a proposal is needed, then, to change the agreed proposals process to add a special rule for format proposals. If someone's (luks?, swisschris?) is willing to put forward a proposal for that, then I'd be willing to temporarily delay the two open add format proposals. However, to be fair, while I won't veto-in-advance, I should mention that I really don't see any argument which will convince me that there's a need for this 5 releases minimum. It just feels like an artificial minimum; if I want to see a format added, now I just have to add 5 such releases in addition to drafting an RFC, then later I have to go fix the format on those from Other to whatever the newly added format it. So long as it is a unique format, and it has releases, this add 5 + RFC would be entirely possible and easy to do... so of what benefit is the additional prerequisite? I'd really like if mb-style got back from paperwork to a discussion medium. Some formats are totally obvious, some formats are not. If somebody is not sure, they can ask a question. I've personally never heard of UMD and therefore I asked for 5 releases, because I had my doubts about whether this is an useful addition. I know you can Google and give me a list of releases that you never seen before, which is why I wanted actual releases that somebody had to deal with before. Per Øyvind Øygard's email convinced me that there *are* such releases, so now I have no problems with adding this format. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add UMD as a release format (SwissChris)
On Mon, Mar 8, 2010 at 6:39 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: Rather than a bunch of different responses to different issues raised, I'll try to just summarize my thoughts and hit on those issues all at once. Instead of writing such a long email, why not just link to five MB releases? Five is not that high number. If we can't find 5 releases out of hundreds of thousands, then it doesn't seem a very useful addition to me. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add UMD as a release format
On Mon, Mar 8, 2010 at 10:01 PM, neothe0ne neothe0...@gmail.com wrote: From: SwissChris swissch...@gmail.com All I (and obviously Lukas) are asking for is a similar procedure for release formats. Do you really want me to go into MB and add 5 release events as Other, just so you agree to pass the new release format, only to wait 3 weeks for the edits changing them from Other to UMD to pass? (Unless some autoeditor wants to waste his time doing so.) Because I will if that's what it takes to change your mind, although I hope you'd agree that's almost as ridiculous as jumping through hoops of fire just to please you. I was asking for this just to avoid a situation where we have unused option in the release format list. If you want to add such releases to MB then I have absolutely not problem with adding the format. Out of curiosity, was the missing UMD format option the reason for not adding the releases before? MB has a lot of limitations, so that would be a little surprising to me. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV?: Two decisions on gender needed for the NGS devs: Q2: Alternate Genders
On Mon, Mar 1, 2010 at 6:07 AM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: There's been no further discussion on this, and the RFC is scheduled to go to RFV today. Luks, before this goes to RFV, did you still have concerns? Yes, on Jade Starr's website you can find: Jade decided to leave the band to continue working on her main project DREADCIRCUS and to begin her transition from Male to Female It sounds to me that Female would be the right choice here. Can anybody else list here 5 artists where the Other genre applies? Lukas 2010/2/22 Brian Schweitzer brian.brianschweit...@gmail.com Well, offhand, one that would definitely fit your bill would be Jade Starr (not the porn actress), and another that comes pretty close, but more debatably, is Jayne Country. Jade Starr: http://www.dreadcircus.com/ In a world controlled by FEAR of acceptance and LIES Labels are a quick reference to explainour individuality. Society have chosen the word Transsexual to define my misunderstood so called condition called existence. The only word I choose to be defined by is ME. I'm a singer, guitarist, actor, songwriter and artist. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Add UMD as a release format
On Sat, Mar 6, 2010 at 9:49 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: Clearing out another of the inactive proposals. This was sent last fall, but to users, rather than here, so it got mostly missed (including by me, when I sent RFC-93 to clear the other similar ones out). So this is RFC-108, to add Universal Media Disc (UMD) - http://en.wikipedia.org/wiki/Universal_Media_Disc - as a release format. neothe0ne mentions Japanese releases on UMD in his original RFC, and I can confirm that I've seen UMD audio releases still sold in Canada and the US. Without objection, this will move to RFV on 2010-03-13. I'd like to see 5 UMD audio releases listed here first. Lukas -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV?: Two decisions on gender needed for the NGS devs: Q2: Alternate Genders
On Sat, Mar 6, 2010 at 10:40 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: 2010/3/6 Lukáš Lalinský lalin...@gmail.com On Mon, Mar 1, 2010 at 6:07 AM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: There's been no further discussion on this, and the RFC is scheduled to go to RFV today. Luks, before this goes to RFV, did you still have concerns? Yes, on Jade Starr's website you can find: Jade decided to leave the band to continue working on her main project DREADCIRCUS and to begin her transition from Male to Female It sounds to me that Female would be the right choice here. Can anybody else list here 5 artists where the Other genre applies? Lukas While I understand that interpretation, you're taking a mention of the surgical procedure as defining the post-surgical gender for Jade (writing, w/o using his/her/gender pronouns is difficult! :D), which would seem contradictory to the other quoted bit. However, defining gender based solely on genitalia and not self-identification in this manner still breaks; by that definition, any castrati would not be male? Well, we clearly understand that sentence differently. To me it's about self-identification. In any case, this seems reason for us to clearly define the types of situation in which Other should be used, not a reason to simply not include an Other option. Such definitions should be written on the wiki before even sending a RFC to mb-style. (Especially since the RFV on that passed a bit over a day ago... :P) That's not a reason to not reopen the issue. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Two decisions on gender needed for the NGS devs: Q2: Alternate Genders
On Mon, Feb 22, 2010 at 11:44 AM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: I think it's right to provide more the binary choice male/female and I'd tend to go with 'transgender' because it's already pretty widely accepted in usage as the T in LGBT. As you say, I don't think MB wants to enter into a whole debate on gender terminology. Of course, whatever choice is made now is not that set in stone and it can be altered over time. I definitely don't think 'it's complicated' is appropriate; that reads to me as downright offensive. It sounds to me as if Other is a pretty clear consensus. I'd avoid merely transgender as an alternative, as the strict definition of transgender would still exclude some possibilities (among them, the strict definition of intergendered when compared with the strict definition of transgendered). So, I think this question, at least, has a clear enough answer to go for an RFC (or rather, a Request for (Official) Opinion, as we're not actually *changing* anything). So, the RFC: The Style Council has decided on the question of what alternate genders to add to the list of possible *person* artist genders in NGS, one alternate option should be added, to be named Other, or, in translation, to be translated in such a way that the i18n term used is interpreted as 'something other than male or female, non-exclusive of any intergendered, transgendered, etc. possibility.' Without objection, this RFC will become an RFV on the morning (EST) of Monday, March 1st. Can somebody please show me 5 artist entries for which the Other gender would be used? I'd be interested if we can reach consensus even on such a small sample, before adding the Other option to the database. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Two decisions on gender needed for the NGS devs: Q2: Alternate Genders
On Mon, Feb 22, 2010 at 1:05 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: There's some groups in there, and some (Wendy Carlos) might be best set to male or female, if they have a clear and public gender decision stating themselves to be male or female, not Other - but that part is probably best left to whatever guideline we end up drafting on artist genders. Which is why I asked about a list where somebody is sure that Other is the right choice. Wendy Carlos, for example, identifies herself as female, so I see no reason for using the Other option. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Request for Debate: Two decisions on gender needed for the NGS devs: Q2: Alternate Genders
On Thu, Feb 18, 2010 at 4:55 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: The second question is one I've seen discussed (in the hypothetical, if we ever did have artist genders) many many times, including in http://chatlogs.musicbrainz.org/musicbrainz/2010/2010-01/2010-01-20.html#T18-26-42-754738 Question: Person artists currently can be set to (blank), male, and female. * What about support for those who fall outside of the male/female definitions, due to an accident of birth, surgery, personal identification, or whatever other reasons? Should there be support for these to accurately be recorded? I personally don't like this. I'd prefer to keep any special case as empty in the database. Once you add an exception, you will have to start adding many other exceptions. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Bass instruments
On Tue, Sep 15, 2009 at 9:22 AM, David Gasaway d...@gasaway.org wrote: I'd also like to know what distinction is intended by having both Double bass (Contrabass, Acoustic upright bass) and Acoustic upright bass. I've consistently used the former in all cases, AFAIK. There is http://bugs.musicbrainz.org/ticket/3732 and it should be fixed now. Thanks for the ping. :) -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] bass drum instrument relation
On Mon, Aug 17, 2009 at 10:42 AM, Fabe56fabyinc.n...@free.fr wrote: This instrument will be add later, when it is used on at least 5 regular, proper releases (live or album). There is more than five release mentioned here - http://musicbrainz.org/search/textsearch.html?query=%22bass+drum%22type=annotationlimit=25adv=onhandlearguments=1 and that's only releases where people added the info to annotation, so I've added bass drum to the instrument tree. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: PartNumberStyle (second attempt)
On Thu, Jul 23, 2009 at 10:51 PM, Kuno Woudtk...@frob.nl wrote: If e.g. a dutch release uses schijf: subtitle on the backcover, I will use 'schijf' in the release title on musicbrainz. This is rare though, I couldn't find an example of this last time I went through my dutch releases. But especially because it's so rare I want to capture that when it occurs. Changing it to 'disc' loses information I want to retain. 'disc' doesn't hold any information. It's just an indicator of a pseudo-field that we currently can't store in the database properly. This is fixed on NGS and releases using /disc \d+/ can be automatically converted, other variations can't and will have to be fixed manually. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] http://www.akuma.de
On Tue, Jun 9, 2009 at 12:03 AM, Robert Kayer...@eorbit.net wrote: Hi! Someone from http://www.akuma.de contacted me and asked if we were interested in adding AR links to the akuma.de. They are also willing to help pay for the creation of the links. I'd rather do this: - Create the AR link (as we did for the BBC) - Have them have their own team add the links. - Have them send us a donation. What are the general thoughts on this? I'd rather not add a site-specific AR for this. They don't seem to provide any valuable data. Discographies are from AMG (but apparently they use MB data too, but they don't promote it), videos are from YouTube, concert dates are from Eventful. If anything, I'd prefer to link to the source sites, not to a mashup. If this is just for money, we can automatically link to their search. -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Revise SortNameStyle for artist names that contain a person's name
On Mon, Mar 23, 2009 at 8:21 PM, Paul C. Bryan em...@pbryan.net wrote: It's been over a week since I re-entered this as RFV. There has been no dissent, so I believe this RFV has now passed. I have changed the page [1] in the wiki accordingly. Now, presumably, some transclusion magic to have it reflect in documentation [2] page? This will have for the MediaWiki port of WikiDocs to go live. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Feat. on non-english releases
On Mon, Mar 9, 2009 at 5:05 AM, Z johnny...@gmail.com wrote: Well then, I guess this is goodbye to any atempt of having a useful database for non-english releases, I'll have to give up on using Picard on my spanish releases. Thanks anyway I think you misunderstood the point. Having literal disc X in the title is not a textual information, it's an extra pseudo-field. For various reasons it can't be stored in the database right now, that's why we use a markup language to store it in the release title. If you want disc translated to any language in your tags, you can do this change in Picard. Or if you even want disc for English titles and something else for Spanish titles, the script can look into the language variable and change it depending on this. Or you can use the discnumber plugin and have it removed from the title and stored properly in specific tags. This is the same situation as if it was stored in the database, but instead of removing or changing it from TaggerScript, you would be adding it to the release title in any language you want. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Feat. on non-english releases
On Sat, Mar 7, 2009 at 11:13 PM, Kuno Woudt k...@frob.nl wrote: On Sat, Mar 07, 2009 at 12:17:17PM -0500, Aaron Cooper wrote: disc is not part of the release title and will (hopefully) one day be moved to a separate field. I don't think we need (or should) make it conform to the release's language. That would make it harder to manage the releases - I have no idea what disc is in every language and I doubt most users do. It'd be a lot easier for every user to use disc than make every user learn the translations for disc. We have an AR for that now, you don't need to get that info from the release title anymore. The AR doesn't specific the disc number in any way. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] DiscNumberStyle vs SeriesNumberStyle
On Fri, Mar 6, 2009 at 7:38 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: When a disc is part of a MultiDiscRelease and has no DiscTitle, indicate the disc number by appending (disc x)1 to the ReleaseTitle, with 'x' indicating the sequential number without zero padding, letters etc. Also, if other words than 'disc' are specifically used on the release (e.g. 'page'), still use 'disc'. I can agree with the standardization to disc, but I see no reason why we should be converting disc A or disc One on the release to disc 1, and standardizing this one sequence indicator, when we don't do it for any of the other related sequential-type containers (box, part, volume, etc). We convert it to 1, because disc 1 is not a part of the release title. It's a hack to work around the lack of having proper multi-disc support in the database. As soon as we get that, (disc X) will go away from titles and it will be represented by a number in the database. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFC: New AR for linking to official artist/label YouTube pages
See http://bugs.musicbrainz.org/ticket/2730 -- can anybody think of any reasons to not add it? -- Lukas Lalinsky lalin...@gmail.com ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: New AR for linking to official artist/label YouTube pages
On Fri, Dec 19, 2008 at 6:29 PM, Jason ja...@zenenet.com wrote: Why would you enforce a www? International subdomains matter for the user. You'll piss people off if you force them to English International YouTube, since they'll have to reload the whole page just to get the different social networks they like :P. Because the user are all MB users, or possibly more since MB data are on last.fm or bbc.co.uk. You can't assume they speak a particular language or are part of a particular social network, but you can safely assume then can handle international YouTube. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Non-ascii in Japanese artist sort names?
Dňa Ne, 2008-08-31 o 00:09 +0200, Philip Jägenstedt napísal: A question to someone who knows a little bit of Japanese. The sort name of 岩代太郎[1] is currently Iwashiro, Tarō, which is something I've never seen before. I realize that Tarō and Taro may not sound the same, but is it customary to include this in the sort name? In the case of Chinese artists with pinyin sort names, tone markers are not included. http://wiki.musicbrainz.org/SortNameStyle All ArtistSortNames should be in Latin script. If the ArtistName is in a non-Latin script, use the transliterated or translated name by which the artist is commonly known. It doesn't talk about ascii/non-ascii, but the latin script. ō is a latin character, so it's fine. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Duet style?
Dňa Št, 2008-08-07 o 20:32 +0700, Philip Jägenstedt napísal: Could those with some spare time read and vote on http://musicbrainz.org/show/edit/?editid=954 to give the somewhat disgruntled jesus2099 more input than just mine? It's too late for voting, but I wouldn't have voted no. This is not about duets, it's about the meaning of TrackArtist and ReleaseArtist. The thing is that these fields mean nothing, they are just labels. If people want to enter meaningful information about tracks, then need to use ARs. TrackArtist just says who is the track credited to, who sings how much and who starts singing is totally irrelevant. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] MediaWiki (was: Looking for a new [Documentation|Style] leader)
I'm sorry, I meant to send this to mb-style, not mb-users. -- Preposlaná správa -- Od: Lukáš Lalinský [EMAIL PROTECTED] Komu: General discussions about MusicBrainz [EMAIL PROTECTED] Predmet: MediaWiki (was: Looking for a new [Documentation|Style] leader) Dátum: Tue, 05 Aug 2008 14:15:11 +0200 Hi, part of the previous discussion was migrating the wiki to either MoinMoin 1.6 or MediaWiki. A MediaWiki instance is now set up on http://mediawiki.musicbrainz.org/ with the latest version of our current wiki (no history). Can you please play with it, try to use some of the features that were discussed as improvements over MoinMoin and see if it's worth migrating? Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] [mb-users] MediaWiki (was: Looking for a new [Documentation|Style] leader)
Dňa Ut, 2008-08-05 o 14:54 +0200, Jan van Thiel napísal: 2008/8/5 Lukáš Lalinský [EMAIL PROTECTED]: part of the previous discussion was migrating the wiki to either MoinMoin 1.6 or MediaWiki. A MediaWiki instance is now set up on http://mediawiki.musicbrainz.org/ with the latest version of our current wiki (no history). Can you please play with it, try to use some of the features that were discussed as improvements over MoinMoin and see if it's worth migrating? Can you repost these improvement features? Looking at the previous mails, these were mentioned: * Real categories * Working full-text search * Talk pages * Templates * Namespaces Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] [mb-users] MediaWiki (was: Looking for a new [Documentation|Style] leader)
Dňa Ut, 2008-08-05 o 15:05 +0200, Jan van Thiel napísal: 2008/8/5 Lukáš Lalinský [EMAIL PROTECTED]: Dňa Ut, 2008-08-05 o 14:54 +0200, Jan van Thiel napísal: 2008/8/5 Lukáš Lalinský [EMAIL PROTECTED]: part of the previous discussion was migrating the wiki to either MoinMoin 1.6 or MediaWiki. A MediaWiki instance is now set up on http://mediawiki.musicbrainz.org/ with the latest version of our current wiki (no history). Can you please play with it, try to use some of the features that were discussed as improvements over MoinMoin and see if it's worth migrating? Can you repost these improvement features? Looking at the previous mails, these were mentioned: * Real categories * Working full-text search * Talk pages * Templates * Namespaces Thanks. Would talk pages be used for discussion, or something else? To replace current *Discussion pages and Discussion sections on regular pages, I think. That would keep the main pages clean. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] MediaWiki (was: Looking for a new [Documentation|Style] leader)
Dňa Ut, 2008-08-05 o 18:16 +0200, Aurélien.mino napísal: I'm doing some tests to convert our Cards to Templates. Could you enable set $wgAllowExternalImages to true? (http://www.mediawiki.org/wiki/Manual:%24wgAllowExternalImages). Done. What is a bit disturbing is the naming of pages: no more CamelCase (page CamelCase is now Camel Case), but since redirections are working, the migration path is smoother. This was actually intentional, I can disable the renaming, but I think non-CamelCase page titles are nicer. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] MediaWiki (was: Looking for a new [Documentation|Style] leader)
Dňa St, 2008-08-06 o 08:44 +0700, Philip Jägenstedt napísal: Would it be possible to enable file uploads? I was testing if it were possible to create a page for identifying Chinese Labels at http://mediawiki.musicbrainz.org/Chinese_Labels, but was kindly informed that File uploads are disabled on MusicBrainz Wiki. Done. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] MediaWiki (was: Looking for a new [Documentation|Style] leader)
Dňa St, 2008-08-06 o 08:53 +0700, Philip Jägenstedt napísal: Ah, MediaWiki is quite refreshing, I like it. We'll have to manually move user pages to User: pages Yes, this is mentioned on http://mediawiki.musicbrainz.org/MediaWiki_migration Also, the decamelcapser messed up quite badly on discid titles, if there's a simple way to stop those from being converted that would be good, otherwise they need manual cleanup later: It's true that some pages are decamelcased incorrectly (I have a list of these from nikki, so they will be fixed in the final import), but in this case I think the correct term is Disc ID, not DiscID. Lukas ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Looking for a new [Documentation|Style] leader
Dňa Št, 2008-07-31 o 10:32 -0700, Robert Kaye napísal: On Jul 31, 2008, at 3:43 AM, Lukáš Lalinský wrote: So, if we really want to migrate to MediaWiki, I'd sugges to not upgrade to MoinMoin 1.6, but go straight to MediaWiki. Do you want to load the results onto scooby so everyone can play with the results? I can have DW add a new DNS entry for it I've set it up on http://mediawiki.musicbrainz.org/ It's only the latest version of each page, not full history, but I think that should be enough for testing. Can you please add the DNS entry for it? Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Looking for a new [Documentation|Style] leader
Dňa St, 2008-07-30 o 11:54 +0200, Aurélien.mino napísal: Chad Wilson a écrit : - Where is the MoinMoin upgrade stuff at? In the hand of djce dmppanda. I don't have more info. BTW, I figured nearly one year ago that we should migrate to MediaWiki, because it may better fits our needs (true categories support, advanced templates (Moin cards are limited), native discussion page for each article, namespaces). However I feel discouraged by the needed work, and stopped my investigaton. I didn't know about such an idea. If people think MediaWiki would really work better for us, I'm willing to at least try to do the work. Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: SupportingMusicianRelationshipType OK for Groups
Dňa Po, 2008-05-05 o 08:17 -0400, Mike Morrison napísal: [...] So now all that remains to be done is for a RelationshipEditor to implement point 1. Done. Lukas Thanks! Mike On Fri, 25 Apr 2008, Mike Morrison wrote: It having been one week with no additional comments on this Request For Comment, I am submitting it as a Request For Veto. My initial post on this topic: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-April/006776.html My initial RFC on this topic: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-April/006783.html Amendments to the initial RFC: http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-April/006785.html http://lists.musicbrainz.org/pipermail/musicbrainz-style/2008-April/006786.html The intent of this RFV is to say that all four of the following are theoretically acceptable uses of the SupportingMusicianRelationshipType, although the distinctions between membership, collaboration, and support might need to be decided on a case-by-case basis: Person supported Person Person supported Group Group supported Person Group supported Group To that end, this RFV proposes to do the following three things: 1. In the link phrases for the SupportingMusicianRelationshipType, when there is no instrumental or vocal attribute, change: is/was a supporting musician and has/had supporting musician(s) to: is/was a supporting artist and has/had supporting artist(s) (because musician seems to exclude groups) 2. On http://musicbrainz.org/doc/MusicalAssociationRelationshipClass remove the sentence: Both should be persons, the latter mostly a well known solo artist. 3. On http://musicbrainz.org/doc/SupportingMusicianRelationshipType change: This AdvancedRelationshipType is for linking Solo artists to the SupportingMusicians which have played on their albums, and in their live bands. This will effectively replace band membership data for solo musicians, because as illustrated by the below examples, band members are listed for several solo artists, and really a 'person' can have no members. to: This AdvancedRelationshipType is for linking artists to the supporting artists which have played on their albums and/or in their live bands. This effectively replaces band membership data for solo musicians, because really a 'person' cannot have any members. (Changed SupportingMusicians to supporting artists because musician seems to exclude groups) (Changed will effectively replace to effectively replaces, to make it seem less like this AR type is a thing of the future) (Removed the part about the below examples because the example artists seem to have been updated to change the members to supporting musicians) (Changed can have no members to cannot have any members to reduce potential for (admittedly unlikely) misreading) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Removal of homeburnt discIds
Dňa Pi, 2008-05-09 o 21:07 +0800, Chad Wilson napísal: BrianG has voted down an edit to remove a homeburnt disc ID at http://musicbrainz.org/show/edit/?editid=8668756 Since when has this practice changed, and is BrianG's position that the practice should change technically defensible? (of course AutoEditors voting against style guidelines isn't, in my opinion) Which style guideline are you referring to in this case? I'm not aware of anything, and I personally dislike that removing these supposedly homeburnt discids became an accepted practice. Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Removal of homeburnt discIds
Dňa Pi, 2008-05-09 o 15:42 +0200, Bram van Dijk napísal: This one: http://wiki.musicbrainz.org/HowToAddDiscIDs (though you might say it is not a guideline) Yes, this is very far from a style guideline. If I am not mistaken, burning the exact same mp3 or whatever will result in different discIDs dependent on the which burner one uses. Maybe even with which program? Thus, if we allow this, we will get hundreds of discIDs for some releases, and most of these will only be useful to someone who happens to burn their music in the exact same way on the same hardware as the one who originally added the discID. I'm not for explicitly allowing adding homeburnt discids, I'm against removing discids that some people think are homeburnt. There is no way to prove it, it adds extra edits to the voting queue, and it _technically_ doesn't remove the discid from the database. IMHO this is not useful, and we thus should not allow it as it does get in the way. With which I mean that as we are displaying the release events below the discIDs, having 100 or more of them on a release is not very nice. If they were hidden, it would be ok to keep them? I think we all know that the MB website is far from ideal, but we should change the graphic layout to fit the data, not the data to fit the layout. Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Removal of homeburnt discIds
Dňa Pi, 2008-05-09 o 21:44 +0200, Philip Jägenstedt napísal: I don't agree. If I see two discids I'll think that there are (at least) two pressings of the CD, not that someone ripped a CDR (from a friend or whatever) and used MusicBrainz to tag it. There is an important point here: people don't need to submit discids to tag their files. Even if they normally use discids to lookup releases, and the discid isn't in the database, it's easier for them to just load the release and _not_ submit the discid. But people do submit discids because they want to contribute to the database. Peoples homemade discids are cruft and I applaud anyone who takes the time to clean up cruft even when the cruft is not causing much damage. Some more practically inclined will think that it's a waste of time, but why vote no? Because it's reducing the usefulness of the database. There is no good way to prove that a discid is homebrew (ie clasify what is 'cruft' and what is not). There is the usual +2 seconds method, which I personally consider questionable, but a simple script can check this much more effectively than a bunch of editors. Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Works lists (and other related changes then implied)
On Ne, 2008-03-02 at 03:52 -0500, Brian Schweitzer wrote: Details: I propose that we add a NAT-like listing to the database for each artist (not just in classical), as was discussed yesterday, essentially using the exact same code that allows for NAT listings, to allow for works lists, until such time as NGS develops to a point where it obviates the need, when we can migrate those works lists to NGS work listings. Frankly, I'd much rather spend a week or two on adding something else than tracks (basically NGS works without attributes) to the database and AR support for them, than abusing tracks for this. Having a special release for non-album tracks is a hack, but having a special release for hundreds of compositions would be, IMO, much uglier and unmanageable hack. Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG compromise?
On Pi, 2008-02-29 at 10:36 +0100, symphonick wrote: I have to check if I understand this NGS-stuff correctly: Many (most) classical releases have headings in the tracklist, wich gives the context for the following tracks. I randomly picked http://www.bis.se/index.php?op=albumaID=BIS-SACD-1618 I do agree that I. Allegro is a perfectly fine track name _in context of the above heading_. Outside of that context, it's just any first movement with the tempo marking Allegro. That tracklist would look like this with worktitles removed: 1. I. Allegro 2. II. Andante 3. III. Rondeau. Allegro 4. I. Allegro 5. II. Adagio 6. III. Rondeau. Tempo di Menuetto 7. I. Allegro 8. II. Andante 9. III. Rondeau. Allegro so would the webinterface the directory on my media player/computer. Now, am I correct in assuming that: 1) The webinterface will show the NGS-worktitle on every track - or even better: once above a group of tracks with the same worktitle? No. In the entire NGS thread by work title I meant full work title including movement, etc. Something that represents a piece of music. On the other hand when I say track title I mean title used for a specific track on a specific release. This might map to one musical work, multiple works or a just part of it. But there are no headings, no groups, etc. All you have is a simple list of text fields. In this specific example it would be: 1. Concerto in E-flat major for two pianos, KV365: I. Allegro 2. Concerto in E-flat major for two pianos, KV365: II. Andante 3. Concerto in E-flat major for two pianos, KV365: III. Rondeau. Allegro ... This represents the actual recorded music, mastered and recorded on a CD (what is says). This probably won't change, because MB is and probably will be used mainly as a database for tagging/CD lookups. But then you have a database of musical works with structure like this: * Concerto in E-flat major for two pianos (cat#: KV365, year: 1779) * I. Allegro * II. Andante * III. Rondeau. Allegro This represents music in abstract, but structured, way (what it is). You can add more levels to this structure if you want, so you can list e.g. all concertos for piano by the composer. The point is that you can link one track to one or more works. This way you can see all recorded tracks of a particular musical work, and you can also see which works are played on a particular track. Somebody in this thread mentioned that classical music has no tracks, which I guess is the main point of confusion here. Classical music really has no tracks, but classical releases do have tracks and do have track titles. But again, this is no different to non-classical music. It has no tracks either, it has songs and releases of them again have tracks and track titles. 2) Picard will be able to attach the worktitle to title-tag filename? Probably, maybe. :) Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG compromise?
On Pi, 2008-02-29 at 11:16 -0500, Brian Schweitzer wrote: Somebody in this thread mentioned that classical music has no tracks, which I guess is the main point of confusion here. Classical music really has no tracks, but classical releases do have tracks and do have I was with you all the way up to here Luks. Classical release do indeed have tracks. Classical releases, however, as Frederik, myself, and Aaron have been pointing out, do not have track titles that are no different from non-classical. What is Concerto in E-flat major for two pianos, KV365: I. Allegro, then, if not a track title? To me it looks like a title that represents track #1 on release Concertos for Two and Three Pianos (BIS-SACD-1618). Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG
On Ut, 2008-02-26 at 07:36 -0500, Aaron Cooper wrote: I disagree with luks. A work title not only identifies a larger work but also the individual movements of those works. Classical songs don't have titles, unless you consider common names like Eroica a title. I wasn't walking about work titles at all, nor about classical songs. What we have in MB are track titles, which sucks for classical, but that's the way it is. Track titles will always depend on the context in which they are released, so trying to make them absolutely identify musical works in all cases doesn't make sense to me. Reformatting is fine, standardization is fine, but changing the title to something completely different than on the cover isn't (in my opinion). We should wait for actual musical work entities with that. Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG
On Ut, 2008-02-26 at 10:49 -0500, Brian Schweitzer wrote: On Ut, 2008-02-26 at 07:36 -0500, Aaron Cooper wrote: I disagree with luks. A work title not only identifies a larger work but also the individual movements of those works. Classical songs don't have titles, unless you consider common names like Eroica a title. I wasn't walking about work titles at all, nor about classical songs. What we have in MB are track titles, which sucks for classical, but that's the way it is. Track titles will always depend on the context in which they are released, so trying to make them absolutely identify musical works in all cases doesn't make sense to me. Reformatting is fine, standardization is fine, but changing the title to something completely different than on the cover isn't (in my opinion). We should wait for actual musical work entities with that. luks, and where the liner Ok, here is my reply, but these things are not related to CSG *AT ALL*. (I know that I sound negative in this thread, I don't really mean to, but I just don't like this black or white point of view -- either copy liner noters or copy CSGS pages, nothing in between). a) misidentifies the work (I've seen multiple cases of Philips doing this, for example) in part or entirely? We already do correct misidentified titles, that is nothing specific to classical. If you have take an average mixed trance CD with miscredited tracks (where it happens a lot), they are usually fixed in MB. b) is simply Allegro? Show me one release where a track is identified as Allegro, without mentioning Symphony No. XY and the composer's name on the front cover. c) is in multiple languages, or the same release has been reissued multiple times with different liners? (very common, in fact, the majority) http://cover-paradies.to/?Module=ViewElementID=40762 Nothing specific to classical. d) contains typos, etc? Same as a), nothing specific to classical. What we're talking about it taking Allegro, taking Symphony No. 22: Allegro, etc and putting it together the same way each time. CSG already does that, and it's worked - but only because of some very hard work by all the classical editors to try and nit-pick the same titles over and over and over again. All the revised CSG would do is bring together all the decisions that have been made in the 14+ months since CSG last was revised. All the CSGS would do it provide a copy/paste version of many of the work titles people need, leaving them and the classical editors free to work on such things as ARs. All I'm saying is that this, in my opinion, isn't going to work. Tracks have context (release), and in different contexts they have different titles even if they represent the same music (see e.g. soundtracks vs. soundtrack compilations, album versions of tracks on albums vs. on singles, ...). You can ignore it, but until we have at least track masters in the DB where absolute work identification makes sense, you can't be surprised to find people who disagree with you. If you're already putting in Symphony No. 22: 1. Allegro from a liner with decent info, is it really so different to add a key, to identify if it's the one with or without clarinets, or to use a common numbering system for the movement number? Where does this end? What is ok to add and what isn't? We don't add complete locations to (live, XXX) just because we know it, we usually only add as much info as on the cover. The same way we don't add (feat. XXX) to titles because we know that XXX performed vocals/instrument on the track, but we add it because the artist is featured on the track. Or what about (take 2, with clarinets and piano played on 2006/03/04)? Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG
On Ut, 2008-02-26 at 11:36 -0500, Andrew Conkling wrote: On Tue, Feb 26, 2008 at 11:13 AM, Lukáš Lalinský [EMAIL PROTECTED] wrote: Show me one release where a track is identified as Allegro, without mentioning Symphony No. XY and the composer's name on the front cover. http://musicbrainz.org/album/24bb6985-c65e-4e46-a0cb-6daacce5a28f.html http://musicbrainz.org/track/584f5825-c7ff-403d-9019-49d7a7c14ecf.html (Note two movements in this symphony are titled Allegro) http://musicbrainz.org/album/a25aa8e9-5b2f-490d-9979-1a7bea3aa82d.html I didn't mean in MB, I meant the actual releases. Do you have the CDs and can you confirm that for example the last one has on other info on the cover/liner notes? Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG
On Ut, 2008-02-26 at 18:48 +0100, Frederic Da Vitoria wrote: So which titles should we use? The title of the first release? What if it was wrong? What if it was so old it never got entered in MB? The title of the last release? No good, these are often budget releases, simplified or completely wrong. CSG solved this by choosing to use normalized titles, for the work as well as for the movements (of course, I am simplifying a little here). A track name should always contain the normalized work name followed by the normalized movement name. Exactly what MB does in other musical domains. We only took our reference somewhere else, outside what is printed on the releases, because this varies so widely (and wildly) that we felt no rule based on liner notes would really work. I guess that leads to a question what is normalized and what is not? Is changing Piano Concerto, Klavierkonzert or Klavírny koncert to Concerto for Piano really just normalization? Why should we prefer the English title on a German release? Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG
On Ut, 2008-02-26 at 15:19 -0500, Brian Schweitzer wrote: I guess that leads to a question what is normalized and what is not? Is changing Piano Concerto, Klavierkonzert or Klavírny koncert to Concerto for Piano really just normalization? Why should we prefer the English title on a German release? The problem here is you're assuming it's only a German release - and that's the case only perhaps 20-25% of the time. Most often, it's a German+French+English release, or a German+English+Italian release also released in a Swedish+Dutch version and a Norwegian version, or... you get my meaining. Considering that the language on the liner used here is a release-artifact, and not something inherent to the original composition, why does the language used to list it really make a difference? And, if you reopen that can of worms, then for any given release, which language is to be used? For the release with 4 languages on the liner, do we then add it not once, but 4 times, plus any additional time as needed where the same release also has variant versions / reissues in yet further languages? Well, why not try simple cases first? Here is an example of a release with German-only titles: http://cover-paradies.to/?Module=ViewElementID=504128 Can you give me just one valid argument for using Piano Concerto No. 2 in F minor, Op. 21: I. Maestoso instead of Klavierkonzert Nr. 2 in F-moll, Op. 21: I. Maestoso for the first track in MB (obviously neither of them is _the_ original)? The German one has the advantage that is printed on the cover and is the original in the context of this release. Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG
On Po, 2008-02-25 at 16:37 -0500, Brian Schweitzer wrote: It all comes down to this: Is MusicBrainz' classical to be a database of: a) Titles just as they are on liners, helpful or not b) Basic identification of the work on a track, though not always enough to determine exactly which specific version of a work c) Specific identification of the works on tracks d) Specific and complete identification of the works on tracks e) Specific and complete identification of the works on tracks, titled such that every instance of that same work can be found listed identically MusicBrainz, at the moment, is a database of releases. That means release titles and track titles. The track titles are usually not 100% copies of liner notes, they are somehow standardized, but they are still just track titles. There is no difference between classical and non-classical here. Of course this is very far from ideal for classical, but you just have to accept the fact that track titles in MB are not work titles. I work in most of my free time on making it possible to add musical works to MB. It will probably take some time until it happens, but starting (or continue?) to treat tracks like works will definitely not help it. Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] CSG
On Po, 2008-02-25 at 18:28 -0500, Brian Schweitzer wrote: If I can be forgiven replying to all three at the same, I think they boil down to the same thing: [...] and luks wrote: MusicBrainz, at the moment, is a database of releases. That means release titles and track titles. The track titles are usually not 100% copies of liner notes, they are somehow standardized, but they are still just track titles. There is no difference between classical and non-classical here. Of course this is very far from ideal for classical, but you just have to accept the fact that track titles in MB are not work titles. I work in most of my free time on making it possible to add musical works to MB. It will probably take some time until it happens, but starting (or continue?) to treat tracks like works will definitely not help it. [...] These all then seem to argue for eliminating CSG. Then you read mine wrong - The track titles are usually not 100% copies of liner notes, they are somehow standardized, but they are still just track titles. - the standardized part for classical releases means CSG. But a CSG that respects the fact that track titles are track titles, not work titles. Changing CSG to handle complete work titles is what I see happening, and I don't think it's a good idea. CSG by it's very nature disregards what is on the liner. No matter where we source the data from, that's what it boils down to. I disagree. Except for random semi-classical compilations, classical releases usually have enough data in liner notes to identify which works they contain. So for usual releases you can simply take that information, apply CSG and add it to MB. We should try to make it easier for people to add releases, not harder (and in any case not require people to study the works in question in order to add a release to MB). Once we have a database schema that can handle more than track titles, we can link them to works with all the detailed information, but for now we have only track titles... Lukas signature.asc Description: Toto je digitálne podpísaná časť správy ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
