Re: [mb-style] Recordings from different media types and/or with different number of channels
Jim Patterson wrote Personally, I think the 'Recording' definition is drifting too far towards the actual characteristics of the end product and away from identifying an artifact that captures a performance of the artists. It's the performance that is important to me - who the artists were, the venue, etc. If we start splitting up each recording based on post production activities e.g. remastering, mono or stereo, etc. then we lose the ability to associate these recordings with specific performances. At least one other editor seems to be thinking along similar lines -- see http://forums.musicbrainz.org/viewtopic.php?pid=18401#p18401 Patrick -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Recordings-from-different-media-types-and-or-with-different-number-of-channels-tp4612452p4616654.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Sort Names: sorting vs. grouping ?
2012/5/8 Ross Tyler I think what most people expect from the sort name field is that artists be ordered in a familiar alphabetical manner. The purpose of that is simply to find an artist in a list when you know nothing beyond the name. Yes. I consider myself one of these. I (and, I suspect others) would expect to find all Les Claypool projects filed under Claypool, Les. What you're describing might be called grouping. It sounds great. I think I'd like my collection organized along those prinicples. But IMO it goes beyond what most people expect from the sort name field. I also don't see this as a sorting problem, but an identifier problem. In the database we use disamb. field to solve such problems, but only when artist names are identical. We can extend the usage of disamb. field for such scenarios. Furthmermore, if also we can put that disamb. note to a tag field in our files, we can use that while sorting and/or displaying artist names. I don't like the idea of using Grouping id3 tag field because it uses TIT1 which is used for grouping of titles not artist names. However, I think it's an interesting idea that we do groupings for artists too. Idea is similar to release groups. Each artist group may include artist projects or bands that artists attended. --ym ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
[mb-style] RFV: Add wikisource for lyrics
A week has gone and the RFC got +1. There has been no objections, so the suggestion isn't changed: I suggest we add wikisource.org from the Wikimedia Foundation for lyrics. Among all the documents there there are quite a few song lyrics in various languages for texts in the public domain. http://tickets.musicbrainz.org/browse/STYLE-106 This will expire on May 10th. Once the RFV has passed, permission must be obtained, in writing (email is fine), from the site which would be added to the whitelist. I'd say we (and everyone) obviously already have permission to link to wikisource.org, even though I can't find a clear-cut you may link to us quote there. The closest in writing might be at http://wikimediafoundation.org/wiki/Terms_of_use where including a) a hyperlink (where possible) or URL to the page or pages you are re-using is mentioned as a way to give credit when re-using text from Wikimedia projects. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFV: Add wikisource for lyrics
On Tue, May 8, 2012 at 10:05 AM, Per Starbäck per.starb...@gmail.com wrote: A week has gone and the RFC got +1. There has been no objections, so the suggestion isn't changed: I suggest we add wikisource.org from the Wikimedia Foundation for lyrics. Among all the documents there there are quite a few song lyrics in various languages for texts in the public domain. http://tickets.musicbrainz.org/browse/STYLE-106 This will expire on May 10th. Once the RFV has passed, permission must be obtained, in writing (email is fine), from the site which would be added to the whitelist. I'd say we (and everyone) obviously already have permission to link to wikisource.org, even though I can't find a clear-cut you may link to us quote there. The closest in writing might be at http://wikimediafoundation.org/wiki/Terms_of_use where including a) a hyperlink (where possible) or URL to the page or pages you are re-using is mentioned as a way to give credit when re-using text from Wikimedia projects. Note that this will need to be accepted by Rob a.k.a. the BDFL a.k.a. the boss because he's asked to approve personally all lyrics pages that style wants to add. But I doubt it should be a problem - I've mailed him about it. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- Nicolás Tamargo de Eguren ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Recordings from different media types and/or with different number of channels
On Tue, May 8, 2012 at 8:24 AM, Sheamus Patt musicbrainz.r...@ncf.ca wrote: On 12-05-07 12:27 AM, Nicolás Tamargo de Eguren wrote: On Mon, May 7, 2012 at 5:40 AM, Sheamus Pattmusicbrainz.r...@ncf.ca wrote: On 12-05-06 08:35 AM, Nicolás Tamargo de Eguren wrote: On Sun, May 6, 2012 at 2:50 PM, Frederic Da Vitoriadavito...@gmail.com wrote: Not so if you realize that the MB Recording is actually close to what people usually call a master. The CD, DVD and MP3 versions actually come from the same master. So they share the same Recording. Also, if we separated CD, DVD and so on, all ARs should be duplicated to all media, which would not be user-friendly and would allow for mistakes. The only differrence between these versions would be the medium itself. The MB Recording is an entity whose main usefulness is to offer a single point where to attach ARs (and other data) which would otherwise have to be duplicated. So that IMO we shouldn't create distinct Recordings wy medium, we should rather alter the definition of Recording to make this more clear. If the DVD is a DVD-Video, those are definitely not the same recordings - they are videos (which should get their own ISRC etc) I don't agree. If we follow the recording-is-master analogy, then they are the same recording. It's simply that the audio versions have dropped all of the video tracks. The recording on DVD-Video has all of the tracks, audio and video. Conceptually it's not that different than mono and stereo; they have the same master, but the mono versions have combined the sound tracks into one instead of two. This is actually coming up quite a bit now; I have several CD / DVD albums in my collection where the CD is the audio portion of (most of) the DVD. For example James Taylor Carole King's Live at the Troubadour http://musicbrainz.org/release/7ba35b06-e424-49a6-a07c-3c4765479f83 . It makes perfect sense to me to link the audio and video portions of each track to a common recording (and I did). Doing otherwise is a make-work project to me; I need to do twice the work to provide relationships on twice as many recordings, when in fact they were recording using the same equipment. I don't argue the situation is ideal. But I wouldn't merge videos and audio and I probably wouldn't merge mono and stereo, either. Ideally, going forward, we would be able to mark video recordings as being video, and have them being easy to filter from the rest so people can know what stuff an artist has in video form - especially since video is becoming more prominent and central to the music each day and I doubt that trend is changing anytime soon. In practice we already can, usually. When the recording is in context as part of the release, the format of the media will indicate if it's video (e.g. DVD-video) or audio (CD, vinyl etc.). Personally, I think the 'Recording' definition is drifting too far towards the actual characteristics of the end product and away from identifying an artifact that captures a performance of the artists. It's the performance that is important to me - who the artists were, the venue, etc. If we start splitting up each recording based on post production activities e.g. remastering, mono or stereo, etc. then we lose the ability to associate these recordings with specific performances. Relationships like 'is a remaster of' are only a partial solution; they lose the capability of seeing the relationships of the underlying performance when looking at a release page in Musicbrainz (you have to follow those links to get the full picture). We'd also need a lot more of them - 'is the audio track of' (to link the video and audio tracks e.g. on Live at the Troubadour) or 'is a mono version of'. When we get more into video, will we also want to separate HD from 4x3, or 2D from 3D? Going forward I think we'd be much better off maintaining the recording-as-master approach, and extend the Release Disc Format to capture details about how that recording is actually presented. That doesn't help with standalone recordings, which means it doesn't help with most music videos out there - those are not in any release and have no format. And recording was never meant to indicate a real *recording* - it's just that the name is misleading. Or rather, the first iteration of the schema had recording, mix and master as *different* entities, but I think people argued that was nuts, so they settled for a thing which ended up being called recording while being more of a master (notice that the music industry does the same: ISRCs are *recording* codes, but apply to masters - and differ between videos and audio tracks). Another problem that has is that the audio track is rarely the same. For music videos, it almost always changes, but even for live DVDs, the video tends to include more non-musical bits than the CD. Of course, I'm sure there are plenty of examples of it being exactly the same, but unless we ask
Re: [mb-style] Sort Names: sorting vs. grouping ?
2012/5/8 Ross Tyler rossety...@gmail.com On 05/06/2012 04:04 PM, caller#6 wrote: Spun off from the sort name thread, http://musicbrainz.1054305.n4.nabble.com/pre-RFC2-320-Revised-Sort-Name-Style-identifying-the-problems-that-need-fixing-tp4603915p4607750.html On 05/03/2012 08:40 PM, Ross Tyler wrote: On 05/03/2012 01:14 PM, caller#6 wrote: On 05/02/2012 04:46 PM, Ross Tyler wrote: Intent should always win. In general, I agree. Editors can't treat guidelines as guidelines (as opposed to rules) unless they understand the intent. On the other hand, items 23 (titles and jr/sr), as others have said, are relatively easy fixes that (I hope) everybody agrees on. So I'm not opposed to fixing those quickly while the other items on the list are discussed further. Does that seem reasonable? Yes. I would think that your solution would the implementation of the (presumed) intent to provide a natural, common sort order between artists that results in the ordering one would expect to find at a brick and mortar record shop or on one's shelf. Sorting should not only establish what is before and after but what is between and what is not. To achieve this, I believe that the the sort name of one artist might need to be affected by who we want its sorted neighbors to be. So, our intent is that we want Harry Connick Jr. and Sr. to be neighbors. Our guidance on how one would typically do this would be what you would say in item 2. Similarly we must have some neighborly intent that would drive 3. I suspect, for a lot of artists, mechanical application of some guidance might suffice. Where we might run into trouble (where intent would help) is what we do with artists like Les Claypool and his associated acts. Consider these: Les Claypool Les Claypool and The Holy Mackerel The Les Claypool Frog Brigade Colonel Claypool's Bucket of Bernie Brains I would say that our intent should be to make these artists neighbors. To meet such intent we might choose sort names that share a common root, like: Claypool, Les Claypool, Les and The Holy Mackerel Claypool, Les, The, Frog Brigade Claypool, Les, Colonel, Bucket of Bernie Brains Or, maybe they all have the same sort name of Claypool, Les. Notice that the neighborly intent drove us to choose sort names that we might not have in isolation. Now what happens when a different Les Claypool becomes a MB artist? I would think our neighborly intent would make it so that this 2nd Les Claypool didn't interrupt the series of 1st Les Claypool artists. Perhaps, this second artist would have a sort name of Claypool, Les (2). Anyway, I think intent is very important and will/should drive all of our other decisions. My thinking on this has shifted a bit. I think what most people expect from the sort name field is that artists be ordered in a familiar alphabetical manner. The purpose of that is simply to find an artist in a list when you know nothing beyond the name. Yes. I consider myself one of these. I (and, I suspect others) would expect to find all Les Claypool projects filed under Claypool, Les. What you're describing might be called grouping. It sounds great. I think I'd like my collection organized along those prinicples. But IMO it goes beyond what most people expect from the sort name field. I guess I don't care what you call it. I would call it, simply, ordering. That is what I think a sort name should do. Honestly, what is the purpose of the sort name field if not to order artists in a meaningful way. What is the meaning (intent) that we are after here? Let's state it. I realize that many MB users have no use for brick and mortar shops and have no shelf full of physical releases. For many such, a sort name is of no use at all as they find artists using search methods. For others, the sorted order of artist names is perfectly natural. For these users, the MB sort name is of no utility at all. So, we needn't be concerned about these users. Let's create an artist order that is of utility for the rest of us. Could this be implemented in parallel with sort names? If Picard gave me the choice of alternate sorting (grouping?) methods, I think that'd be great. I'd love to be able to find all the Richard James [1] projects in one place, for instance. Rather than seeing this as a conflict or an alternative to MB sort names, I see this as *the* motivation for MB sort names. Let's give the mechanical language sensitive lexicographic sort ... meaning, intent, purpose. This purpose should be driving the mechanics. I've thought, off and on, about a cross-referencing system too. Some kind of a see also relationship that might link, say, Primus[2] and Sausage[3]. I don't know if that would fit in with your ideas or not. That is very interesting and I have
[mb-style] Support disambiguation of recording masters
Hi, I want to encourage discussion for better (easier for the end-user, as well as semantic improvement) implementation of masters and their significant remasters. I disambiguate MusicBrainz entities with capitalisation. Currently We define a Recording as: A recording represents a piece of unique audio data (including eventual mastering and (re-)mixing).. [1] If a recording undergoes a significant remaster/edit [i], we are to create a new Recording to represent the new version (or conversely, we are not to represent substantially different masters with the same Recording). [2] [i] A subjective issue, though I try to (very roughly) define this as intentionally rejigging an existing recording so that it sounds noticeably different (for re-release). New Implementation I think the definition should be adjusted to something along the lines of A Recording represents a piece of audio data; a unique rendition of a work.. My intention is that all remasters and [radio/clean, etc.] edits would be grouped under a Recording entity that (perhaps abstractly) represents the studio master (or whatever is analogous) from which they're all derived. Additionally, we'll implement Master IDs, which must have a parent Recording ID. When a new Recording is created, a de-facto Master is also created. These changes will render Remaster Relationship Type [3] obsolete, as the functionality of this relationship will instead be represented through Recording (master disambiguation/name) aka Recording ID - Master ID. Examples A new recording is made, is mastered (or not) and then released. An editor enters it into MusicBrainz as a new Recording; a Master is automatically created. It is also released as a radio edit, which is entered as the same Recording, though the editor chooses to add a new master and is prompted to add a master disambiguation/name (in this case, they enter radio edit). Another single containing the radio edit is released; this time the user again selects the same recording and selects the radio edit master from the drop-down box to the right side of the recording name (if using the Add/Change Recording dialogue box, otherwise if on a Edit Recording page it would be below the recording's disambiguation field). Issues What should we do if the correct Master is unknown for a particular Track (for example, from a compilation)? I suggest perhaps creating a new master called unknown to group unspecified Tracks into. I also support implementation of a Picard function that records an image of Track waveforms, for comparison purposes (stored as data-points for rendering in an HTML canvas), regardless if Masters are implemented. [1] http://wiki.musicbrainz.org/Recording [2] http://wiki.musicbrainz.org/Style/Recording#What_should_and_shouldn.27t_be_merged_together.3F (shouldn't merge different edits, mixes, remixes or remasters of a performance.) [3] http://wiki.musicbrainz.org/Remaster_Relationship_Type -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Support-disambiguation-of-recording-masters-tp4619363.html Sent from the Musicbrainz - Style mailing list archive at Nabble.com. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Sort Names: sorting vs. grouping ?
Frederic Da Vitoria wrote 2012/5/8 Ross Tyler lt;rossetyler@gt; On 05/06/2012 04:04 PM, caller#6 wrote: Spun off from the sort name thread, http://musicbrainz.1054305.n4.nabble.com/pre-RFC2-320-Revised-Sort-Name-Style-identifying-the-problems-that-need-fixing-tp4603915p4607750.html On 05/03/2012 08:40 PM, Ross Tyler wrote: On 05/03/2012 01:14 PM, caller#6 wrote: On 05/02/2012 04:46 PM, Ross Tyler wrote: Intent should always win. In general, I agree. Editors can't treat guidelines as guidelines (as opposed to rules) unless they understand the intent. On the other hand, items 23 (titles and jr/sr), as others have said, are relatively easy fixes that (I hope) everybody agrees on. So I'm not opposed to fixing those quickly while the other items on the list are discussed further. Does that seem reasonable? Yes. I would think that your solution would the implementation of the (presumed) intent to provide a natural, common sort order between artists that results in the ordering one would expect to find at a brick and mortar record shop or on one's shelf. Sorting should not only establish what is before and after but what is between and what is not. To achieve this, I believe that the the sort name of one artist might need to be affected by who we want its sorted neighbors to be. So, our intent is that we want Harry Connick Jr. and Sr. to be neighbors. Our guidance on how one would typically do this would be what you would say in item 2. Similarly we must have some neighborly intent that would drive 3. I suspect, for a lot of artists, mechanical application of some guidance might suffice. Where we might run into trouble (where intent would help) is what we do with artists like Les Claypool and his associated acts. Consider these: Les Claypool Les Claypool and The Holy Mackerel The Les Claypool Frog Brigade Colonel Claypool's Bucket of Bernie Brains I would say that our intent should be to make these artists neighbors. To meet such intent we might choose sort names that share a common root, like: Claypool, Les Claypool, Les and The Holy Mackerel Claypool, Les, The, Frog Brigade Claypool, Les, Colonel, Bucket of Bernie Brains Or, maybe they all have the same sort name of Claypool, Les. Notice that the neighborly intent drove us to choose sort names that we might not have in isolation. Now what happens when a different Les Claypool becomes a MB artist? I would think our neighborly intent would make it so that this 2nd Les Claypool didn't interrupt the series of 1st Les Claypool artists. Perhaps, this second artist would have a sort name of Claypool, Les (2). Anyway, I think intent is very important and will/should drive all of our other decisions. My thinking on this has shifted a bit. I think what most people expect from the sort name field is that artists be ordered in a familiar alphabetical manner. The purpose of that is simply to find an artist in a list when you know nothing beyond the name. Yes. I consider myself one of these. I (and, I suspect others) would expect to find all Les Claypool projects filed under Claypool, Les. What you're describing might be called grouping. It sounds great. I think I'd like my collection organized along those prinicples. But IMO it goes beyond what most people expect from the sort name field. I guess I don't care what you call it. I would call it, simply, ordering. That is what I think a sort name should do. Honestly, what is the purpose of the sort name field if not to order artists in a meaningful way. What is the meaning (intent) that we are after here? Let's state it. I realize that many MB users have no use for brick and mortar shops and have no shelf full of physical releases. For many such, a sort name is of no use at all as they find artists using search methods. For others, the sorted order of artist names is perfectly natural. For these users, the MB sort name is of no utility at all. So, we needn't be concerned about these users. Let's create an artist order that is of utility for the rest of us. Could this be implemented in parallel with sort names? If Picard gave me the choice of alternate sorting (grouping?) methods, I think that'd be great. I'd love to be able to find all the Richard James [1] projects in one place, for instance. Rather than seeing this as a conflict or an alternative to MB sort names, I see this as *the* motivation for MB sort names. Let's give the mechanical language sensitive lexicographic sort ... meaning, intent, purpose. This purpose should be driving the mechanics. I've thought, off and on, about a cross-referencing system too. Some kind of a see also relationship that might link, say, Primus[2] and Sausage[3]. I don't know if that would fit in with your ideas or not.
Re: [mb-style] Sort Names: sorting vs. grouping ?
On 05/08/2012 09:15 PM, jacobbrett wrote: Frederic Da Vitoria wrote 2012/5/8 Ross Tylerlt;rossetyler@gt; On 05/06/2012 04:04 PM, caller#6 wrote: Spun off from the sort name thread, http://musicbrainz.1054305.n4.nabble.com/pre-RFC2-320-Revised-Sort-Name-Style-identifying-the-problems-that-need-fixing-tp4603915p4607750.html On 05/03/2012 08:40 PM, Ross Tyler wrote: On 05/03/2012 01:14 PM, caller#6 wrote: On 05/02/2012 04:46 PM, Ross Tyler wrote: Intent should always win. In general, I agree. Editors can't treat guidelines as guidelines (as opposed to rules) unless they understand the intent. On the other hand, items 2 3 (titles and jr/sr), as others have said, are relatively easy fixes that (I hope) everybody agrees on. So I'm not opposed to fixing those quickly while the other items on the list are discussed further. Does that seem reasonable? Yes. I would think that your solution would the implementation of the (presumed) intent to provide a natural, common sort order between artists that results in the ordering one would expect to find at a brick and mortar record shop or on one's shelf. Sorting should not only establish what is before and after but what is between and what is not. To achieve this, I believe that the the sort name of one artist might need to be affected by who we want its sorted neighbors to be. So, our intent is that we want Harry Connick Jr. and Sr. to be neighbors. Our guidance on how one would typically do this would be what you would say in item 2. Similarly we must have some neighborly intent that would drive 3. I suspect, for a lot of artists, mechanical application of some guidance might suffice. Where we might run into trouble (where intent would help) is what we do with artists like Les Claypool and his associated acts. Consider these: Les Claypool Les Claypool and The Holy Mackerel The Les Claypool Frog Brigade Colonel Claypool's Bucket of Bernie Brains I would say that our intent should be to make these artists neighbors. To meet such intent we might choose sort names that share a common root, like: Claypool, Les Claypool, Les and The Holy Mackerel Claypool, Les, The, Frog Brigade Claypool, Les, Colonel, Bucket of Bernie Brains Or, maybe they all have the same sort name of Claypool, Les. Notice that the neighborly intent drove us to choose sort names that we might not have in isolation. Now what happens when a different Les Claypool becomes a MB artist? I would think our neighborly intent would make it so that this 2nd Les Claypool didn't interrupt the series of 1st Les Claypool artists. Perhaps, this second artist would have a sort name of Claypool, Les (2). Anyway, I think intent is very important and will/should drive all of our other decisions. My thinking on this has shifted a bit. I think what most people expect from the sort name field is that artists be ordered in a familiar alphabetical manner. The purpose of that is simply to find an artist in a list when you know nothing beyond the name. Yes. I consider myself one of these. I (and, I suspect others) would expect to find all Les Claypool projects filed under Claypool, Les. What you're describing might be called grouping. It sounds great. I think I'd like my collection organized along those prinicples. But IMO it goes beyond what most people expect from the sort name field. I guess I don't care what you call it. I would call it, simply, ordering. That is what I think a sort name should do. Honestly, what is the purpose of the sort name field if not to order artists in a meaningful way. What is the meaning (intent) that we are after here? Let's state it. I realize that many MB users have no use for brick and mortar shops and have no shelf full of physical releases. For many such, a sort name is of no use at all as they find artists using search methods. For others, the sorted order of artist names is perfectly natural. For these users, the MB sort name is of no utility at all. So, we needn't be concerned about these users. Let's create an artist order that is of utility for the rest of us. Could this be implemented in parallel with sort names? If Picard gave me the choice of alternate sorting (grouping?) methods, I think that'd be great. I'd love to be able to find all the Richard James [1] projects in one place, for instance. Rather than seeing this as a conflict or an alternative to MB sort names, I see this as *the* motivation for MB sort names. Let's give the mechanical language sensitive lexicographic sort ... meaning, intent, purpose. This purpose should be driving the mechanics. I've thought, off and on, about a cross-referencing system too. Some kind of a see also relationship that might link, say, Primus[2] and Sausage[3]. I don't know if that would fit in with your ideas or not. That is very interesting and I
