Re: [mb-style] album version, original mix, etc.
Jan van Thiel wrote: 2008/8/18 Tim [EMAIL PROTECTED]: I believe that unique tracks should have unique track names across all releases. This seems to be essential for distinguishability of tracks by their track names... Each name has one sound and each sound has one name. [...] MusicBrainz is a discography site with all info on music and some on artists... This info can be used for tagging. Picard has the powerful TaggerScript which lets you format any tag basically the way you want. There's no need to change almost all track titles to accommodate your tagging needs. +1. Tim: what problem are you trying to solve? That your digital music player only offers an Artist and a Title field, and your collection has some entries which are indistinguishable using just these two fields? Then there are a number of ways you can address that problem. In addition to what Jan said, you could perhaps switch to a different music player, which can take advantage of more metadata tags and display more fields. Music metadata is complex and varied. It won't fit in simple-minded Artist and Title text strings in any satisfactory way. I think it's MusicBrainz's job to store the real information in all it's detail and complexity. It's the job of the taggers and other exporters to flatten this information to fit the constraints of music players, other databases, and so on. - -- http://jdlh.com/ Jim DeLaHunt , Vancouver, Canada • http://wiki.musicbrainz.org/JimDeLaHunt -- View this message in context: http://www.nabble.com/album-version%2C-original-mix%2C-etc.-tp19025740s2885p19138669.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] album version, original mix, etc.
2008/8/18 Tim [EMAIL PROTECTED]: I believe that unique tracks should have unique track names across all releases. This seems to be essential for distinguishability of tracks by their track names, effectively describing any differences in sound (ie unique tracks) with unique, specific track name information. (Note I am not using the term TrackName; by track name I mean everything after the artist name.) I also believe the converse: that unique track names should be paired with unique tracks across all releases. There should be no doubt as to what sound (unique track) one is referring to given a track name. To summarize: every unique track should be paired with one and only one unique track name. Each name has one sound and each sound has one name. [...] MusicBrainz is a discography site with all info on music and some on artists. We capture info on what is printed on sleeves, unless that info is proved to be wrong (e.g. typos). This info can be used for tagging. Picard has the powerful TaggerScript which lets you format any tag basically the way you want. There's no need to change almost all track titles to accommodate your tagging needs. Jan (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] album version, original mix, etc.
What about Metallica and U2 both having a song called one, should we add [the U2 song] and [the Metallica song] in the track title? Or when Johhny Cash covered the the U2 one, should we add that explicitly to the track title? And with live versions, should we enter the date of the performance to the track title? and if a song has been performed multiple times on one day also the approximate time? In my opinion, this is what we have AR's for, a track title is what it is, the name of a song. We have the MB-ID as an exact identifier, and using AR's we can find out which other tracks contain the exact same music. Bram / jongetje Tim schreef: Forgive me for beating a 2-years-dead horse, but I have not yet given my thoughts on the issue. I believe that if there was any consensus in the discussions I have been catching up on, it is all voices are welcome. To begin: I believe that unique tracks should have unique track names across all releases. This seems to be essential for distinguishability of tracks by their track names, effectively describing any differences in sound (ie unique tracks) with unique, specific track name information. (Note I am not using the term TrackName; by track name I mean everything after the artist name.) I also believe the converse: that unique track names should be paired with unique tracks across all releases. There should be no doubt as to what sound (unique track) one is referring to given a track name. To summarize: every unique track should be paired with one and only one unique track name. Each name has one sound and each sound has one name. Therefore, it follows that if a physical release lists Funky Shit (album version) in its tracklisting, and this recording is the exact same as Funky Shit on the actual album that album version is referring to, or whatever is chosen to be the default or main version, (that is, if tracks labelled as Funky Shit (original mix) and Funky Shit (album version) are non-unique, identical sounds), then their names should be somehow merged conform to the above one-to-one rule (ie, they should both be labelled Funky Shit; this is one pair.) Similarly, if two physical releases both list Funky Shit names but they actually contain unique sounds, then these unique sounds should be given unique names, overidding the tracklisting just as we would for a spelling mistake. If one Funky Shit comes from a single release and the other from a full album, then the first should be called Funky Shit (single edit) (or something similar), assuming we have chosen the sound from the album to be worthy of the default, base name (no extra parentheticals) as we normally do. (Or, if the single contains the default sound, then its tracklisting should say Funky Shit, and the album's listing should say Funky Shit (album version) Therefore, I address all who favor full inclusion (or full removal) of album version and similar ExtraTitleInformation by responding to a list of arguments from an earlier discussion: we loose version information when it's removed -- If the track is not actually a version of the default (ie if we do not actaully have two unique sounds), then it should not be labelled as such. in line with 'state what is on the cover' -- Everyone seems to agree that covers are sometimes wrong. There are misspellings and mislabellings. when [album version is] removed, a release can have two tracks with the same name, making the track listing ambiguous -- Then fix the mistaken listing. Either call one of the (single edit) or the other (album version). The album version isn't necessarily the main version, and the album version may not be called an album version but instead LP version, 12 version, etc. and in both cases the version info is kept. -- If we match all sounds to unique names, then it doesn't matter how a track is incorrectly labelled (LP version, 12 version, album version, or even original mix), if it shares the same sound as the default-ly named sound, then it should be given the default name. There's currently an inconsistency in assumptions we make, i.e. an unlabelled track on a live release is a live version, but an unlabelled track on a single release is an album version -- From all of the above, it follows that unlabelled tracks (what I interpet to mean default-ly named tracks, to be consistent with terminology I used earlier) on live releases (assuming they differ in sound from the default-ly named tracks) should be labelled (live), and unlabelled (again, default-ly named) tracks on single releases should be labelled (single edit) if they differ in sound from the true default; otherwise, if the unlabelled tracks do not differ from their true default versions, then they should retain their default names. I left out the middle one, as I think it's the best, and it drives to a deeper issue: SameTrackRelationshipType is the
Re: [mb-style] album version, original mix, etc.
On Sun, Aug 17, 2008 at 11:56:18PM -0400, Tim wrote: Forgive me for beating a 2-years-dead horse, but I have not yet given my thoughts on the issue. I believe that if there was any consensus in the discussions I have been catching up on, it is all voices are welcome. To begin: [...] I disagree with more or less your whole post. I want the TrackName field we have in MusicBrainz to match the track name as it appears on the back cover as closely as possible with only very minor spelling and/or stylistic fixes. -- kuno / warp. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] album version, original mix, etc.
Bram: Sure, two artists creating unique tracks called one would break my system as written earlier; again, I am coming from the tagging perspective so I should have written the idea as: each unique sound is paired with one and only one unique title, where title is of course Artist Name - Track Name. Certainly artist information is requisite to differentiation of unique tracks. In fact, everyone already writes One [the U2 song] and One [the Metallica one], just reformatted to U2 - One and Metallica - One. But of course in ID3 (and certainly musicbrainz) we can separate the Artist Name and Track Name into separate strings. As for live tracks, I think there is already an accepted style of adding dates to the main track title. But I am still wondering (like your other two questions), can all information available in musicbrainz (like cover artists) required to establish a track as unique be flattened into ID3 text without creating different names for the same tracks? Can I really use musicbrainz to tag my music, or can I only use my music to update musicbrainz? kuno: Again, my perspective is tagging. I think it would be a good idea to keep an exact transcription of sleeve/cover data, (in fact I am now thinking it would be cool to have musicbrainz store the transcription along with a corrected tag name) but why even correct spelling errors in that case if we have ARs to link them to other tracks? Surely there would be another release with the track without spelling errors. It seems to me that we correct spelling to destroy variant names of the same track, for clarity of the common textual data presented to an end user. If this is the case, it seems that from an unlabelled track One and one called One (album version) is unclear if I am looking at the same track or not. Again, I am now thinking it would be cool to have a completely uncorrected transcription and some corrected tag name stored, but right now everything seems distributed between transcription and stylistic oversight for tagging purposes, making both perspectives incomplete in the context of musicbrainz. On Mon, Aug 18, 2008 at 4:54 AM, Kuno Woudt [EMAIL PROTECTED] wrote: On Sun, Aug 17, 2008 at 11:56:18PM -0400, Tim wrote: Forgive me for beating a 2-years-dead horse, but I have not yet given my thoughts on the issue. I believe that if there was any consensus in the discussions I have been catching up on, it is all voices are welcome. To begin: [...] I disagree with more or less your whole post. I want the TrackName field we have in MusicBrainz to match the track name as it appears on the back cover as closely as possible with only very minor spelling and/or stylistic fixes. -- kuno / warp. ___ 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
[mb-style] album version, original mix, etc.
Forgive me for beating a 2-years-dead horse, but I have not yet given my thoughts on the issue. I believe that if there was any consensus in the discussions I have been catching up on, it is all voices are welcome. To begin: I believe that unique tracks should have unique track names across all releases. This seems to be essential for distinguishability of tracks by their track names, effectively describing any differences in sound (ie unique tracks) with unique, specific track name information. (Note I am not using the term TrackName; by track name I mean everything after the artist name.) I also believe the converse: that unique track names should be paired with unique tracks across all releases. There should be no doubt as to what sound (unique track) one is referring to given a track name. To summarize: every unique track should be paired with one and only one unique track name. Each name has one sound and each sound has one name. Therefore, it follows that if a physical release lists Funky Shit (album version) in its tracklisting, and this recording is the exact same as Funky Shit on the actual album that album version is referring to, or whatever is chosen to be the default or main version, (that is, if tracks labelled as Funky Shit (original mix) and Funky Shit (album version) are non-unique, identical sounds), then their names should be somehow merged conform to the above one-to-one rule (ie, they should both be labelled Funky Shit; this is one pair.) Similarly, if two physical releases both list Funky Shit names but they actually contain unique sounds, then these unique sounds should be given unique names, overidding the tracklisting just as we would for a spelling mistake. If one Funky Shit comes from a single release and the other from a full album, then the first should be called Funky Shit (single edit) (or something similar), assuming we have chosen the sound from the album to be worthy of the default, base name (no extra parentheticals) as we normally do. (Or, if the single contains the default sound, then its tracklisting should say Funky Shit, and the album's listing should say Funky Shit (album version) Therefore, I address all who favor full inclusion (or full removal) of album version and similar ExtraTitleInformation by responding to a list of arguments from an earlier discussion: we loose version information when it's removed -- If the track is not actually a version of the default (ie if we do not actaully have two unique sounds), then it should not be labelled as such. in line with 'state what is on the cover' -- Everyone seems to agree that covers are sometimes wrong. There are misspellings and mislabellings. when [album version is] removed, a release can have two tracks with the same name, making the track listing ambiguous -- Then fix the mistaken listing. Either call one of the (single edit) or the other (album version). The album version isn't necessarily the main version, and the album version may not be called an album version but instead LP version, 12 version, etc. and in both cases the version info is kept. -- If we match all sounds to unique names, then it doesn't matter how a track is incorrectly labelled (LP version, 12 version, album version, or even original mix), if it shares the same sound as the default-ly named sound, then it should be given the default name. There's currently an inconsistency in assumptions we make, i.e. an unlabelled track on a live release is a live version, but an unlabelled track on a single release is an album version -- From all of the above, it follows that unlabelled tracks (what I interpet to mean default-ly named tracks, to be consistent with terminology I used earlier) on live releases (assuming they differ in sound from the default-ly named tracks) should be labelled (live), and unlabelled (again, default-ly named) tracks on single releases should be labelled (single edit) if they differ in sound from the true default; otherwise, if the unlabelled tracks do not differ from their true default versions, then they should retain their default names. I left out the middle one, as I think it's the best, and it drives to a deeper issue: SameTrackRelationshipType is the AR that can state that two tracks have the same content; no need to rename them all to the same name -- I wrote my first paragraph really from the tagging purpose/perspective, assuming that all tracks should be uniquely identified by fields available in ID3, and vice versa, not from otherwise invisible musicbrainz-specific meta-data. That is, hopefully all musicbrainz data that actually identifies a track as unique could be contained in text as ExtraTitleInformation. If two tracks are identical and share SameTrackRelationshipType, then their ID3 track title field (and total musicbrainz name) should be the same. If two tracks have been identified as non-unique with RemasterRelastionshipType, then one of the tracks should be called (remaster), or the other (old) or
Re: [mb-style] (album version) - Form of this change
Lukáš Lalinský wrote: Robert Kaye wrote: Agreed 100%. If anyone needs any _more_ reason than that, I can put my evil overlord hat on. Between TaggerScript becoming a reality and this reasoning, there is no logical way to support the removal of (Album version). Period. Can I take as a final decision and update the wiki pages? Apart from what I think about album version information, I really don't like the form of how this went. The discussion was open for three days, then a veto was requested inside a mail. Then the decision was made within 34 hours. Then the change was announced on a wiki page only that only a few people following the most recent discussions on this mailing list even noticed so far. This is all very suboptimal in my eyes. I didn't plan to step into this discussion but other people perhaps did. Given that there was much traffic on the mailing list at that time (because of the net releases for one), there was rather a lot to read so I think people needed some more time to get into it. But three days from the first mail to the veto isn't enough. The new form of requesting vetos Don suggested and used here isn't obvious enough I think. I'd still like to have topic changes (RFV: (album version)) for that. And just the mention of ruaok to use his position as evil overlord to decide on this should be no reason to shorten the veto period drastically. Finally this is a change with a rather big impact on the data and therefore needs to be announced on the mailing list. The new wiki page is nice as a log of changes but it doesn't catch everyone's attention - especially since it's a very new page. As a side note this is the second time I notice a decision many people are interested in to be made so fast. I think only because many people consider this to be important and want this to be changed as soon as possible, we should not forget about our formalities. Thanks for listening, Simon ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Robert Kaye wrote: Agreed 100%. If anyone needs any _more_ reason than that, I can put my evil overlord hat on. Between TaggerScript becoming a reality and this reasoning, there is no logical way to support the removal of (Album version). Period. Can I take as a final decision and update the wiki pages? ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
reasoning, there is no logical way to support the removal of (Album version). Period. Can I take as a final decision and update the wiki pages? this will not be stated more definitive than that. please go ahead :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Tue, 20 Jun 2006 00:53:28 +0200, Nikki wrote: If Picard 0.8 comes out within a month, then would be two consecutive changes. (this argument does not hold if Lukas says Picard 0.8 takes longer) Well, 0.7 is not a stable release yet (according to the wiki page...), so I can't imagine 0.8 being here in under a month. Of course, maybe Lukáš has stuff hidden up his sleeve. Well, as I said, if this takes longer than a month, then I withdraw my argument. I am for this change anyway. I CCed the post of this thread in which I asked how long picard 0.8 would take to Lukas, but have not gotten any reply yet. Anyway this was an argument against that was part of the debate, and it was missing in Zout's summary. Therefore I added it. I do not feel that this is strong enough to justify a veto (well I would not veto because of this). So you can feel free and ignore it. DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
i'll quote from the other thread, because it might not be read by all users who are interested into the album version issue: I am _extremly_ sceptic that these problems will be solved by TaggerScript , given the ideas i've picked up in this thread (i don't want to dampen the euphoria, but it won't). TaggerScript will help with SG5 (or generally speaking: artist credits on track and release titles). Maybe we'll have an option to set the composer field in classical releases, but not much more at first. I think it is unscalable to have TaggerScript retrieve related objects (how many, how many levels of recursion?) and have a myriad of settings which track title, or release title should be used in which occasion. i for one will strongly object to have to select a match on each and every duplicate hit (similar to how to old tagger worked on trm collisions). the goal, its written on the PicardTagger pages, is to make the tagger more automatic. This will be a step backward if every track needs user interaction. Then, entering ARs to related the tracks will make the tagging more complex, and obstruct further development (if not, it will bundle at least many resources which should rather be invested into the NextGenerationSchema). ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 19/06/06, Don Redman [EMAIL PROTECTED] wrote: On Mon, 19 Jun 2006 12:19:41 +0200, Chris Bransden wrote: firstly, i don't think any DB/Tagger changes will change the situation (see my previous post). Well, my experience says the opposite. In my very humble experience here at MB, every change at the fringes of the overall structure of the system has led to changes in the semantics of the MB data. The semantical changes are usually - not at the same 'place' as the structural changes, - sometimes huge and drastic - sometimes very minor, but then lead to an outburst of an old problem four months later. I therefore strongly suggest to disucss such a change (which I am for BTW) around the time when we make our first experiences with the tagger script. i don't disagree that this is true generally, but i don't think it will be so in this case. like i said, taggerscript will allow us to say always put/append this type of AR in(to) this ID3 field (if my understanding is correct) - this discussion has shown us that version info is often contextually relevent, and shouldn't be deleted from the tracktitles, but NOT that it should be ADDED to tracktitles. there is version info stored as ARs that is trivia, and never/not always refered to on tracklistings (eg remix relationships, live, earliest version of, etc). TANGENT USED TO ILLUSTRATE MY POINT :P - same with SG5 - (feat. x) should always be included on tracknames (or artist names) if it's on tracklistings - if taggerscript always included performance ARs in track names we'd end up with Foo (guitar by J Bloggs) (drums by A Person) (produced by S Wonder) and so forth. unless of course we add some kind of 'included on trackname' flag to ARs... ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Tue, Jun 20, 2006 at 09:03:49AM +0200, Stefan Kestenholz wrote: The argument of how ones tags would suffer by a SG change should be banned from the mb-style mailing list, if there is a majority of the community for a change. Hmm, I mostly agree. However, I think we should still consider the effects the change will have on tagging: the data still needs to be useful. A good example, in my opinion, is the switch from Latin script to other scripts for artist names. Before Picard was able to write Unicode in Windows, it wouldn't have made sense to force people to have non-Latin script names which wouldn't work in either tagger. Of course, in this situation, how does it affect tagging? Well, not at all if you don't mind titles not being identical. If you do, it's a simple change away. It's a change which anyone can do, much like your example about limited edition. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/20/06, Don Redman [EMAIL PROTECTED] wrote: Against doing it now: - SameTrack ARs will get entered much more frequently if the TaggerScript uses them. We will probably need a Style change in this area anyway. If Picard 0.8 comes out within a month, then would be two consecutive changes. (this argument does not hold if Lukas says Picard 0.8 takes longer) No, Picard 0.8 will not come within a month. I was quite busy with school and exams this month, and I'm planing to take a vacation for at least two weeks in the next month. Implementing tagger script itself wouldn't be hard, but I need to rewrite the backend libraries first. Anyway, using Picard as an argument against removing any info from the database is, in my opinion, silly. Sorry. Picard will *never* know where to add (album version), but it can know that user don't want it in the tags and automatically remove it. l. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Citerar Aaron Cooper [EMAIL PROTECTED]: If we decided to, sure why not? Then we would know the live songs are (live), but it isn't super critical because in most cases, the live recording is of the original recording. One exception to this is when a band plays only a portion of the original recording, like Metallica only playing the first half of Master of Puppets. In this case, most people call the song Master of Puppets (jam/excerpt/etc) or even a fan-given name of the Master of Puppets/Welcome Home (Sanitarium) medley... which is escaping me at the moment. I don't follow this at all. I /might/ understand what you're saying if I replace 'recording' with 'song', is that what you're meaning? I think it's extremely important to keep the terminology consistent when discussing this, otherwise noone will know what anyone is talking about. A band can't play a recording live, that's a contradiction (or playback). Could we please keep to 'songs' and 'tracks'? By the way, we do have the http://wiki.musicbrainz.org/SameTrackRelationshipType to clarify the identical tracks. See, we can link identical tracks together, so we don't need the name to be the same as we can already store the fact they're identical. This argument is used in other places, so why can't it apply here? It just seems to be a load of whining about My tags! They're not the same! which applies to other things too but those aren't changed to make tagging easier because we simply state MusicBrainz isn't just for tagging. At this time linking tracks has no practical application and seems useless to me. I do hope that we will be able to use this information in the ARs some day, but I don't want to have to go through all of Metallica's bootlegs and say X is a live recording of Y just to have that relationship - I don't think anyone wants to! If there is a way to do it without completely maiming the track titles and people would be just too lazy to do it, then that would really piss me off. //[bnw] ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Tue, 20 Jun 2006 12:50:11 +0200, Lukáš Lalinský wrote: On 6/20/06, Don Redman wrote: (this argument does not hold if Lukas says Picard 0.8 takes longer) No, Picard 0.8 will not come within a month. OK, I withdraw my argument (which was not a veto anyway). Since this issue has been more than discussed to death now (and I was part of it[1]) I hereby issue a Request for Veto for the following: Remove the paragraph We generally do not retain information such as (album version) as this is considered incidental. If the release is a single, of course one of the tracks is going to be the album version; album version is not part of the title, and is extraneous ExtraTitleInformation. from ExtraTitleInformationStyle and add In June 2006 we changed the rules slightly. They now explicitly state: If a track on a single has the additional info (album version), we ''retain it''. This extra information of TrackTitle``s is considered contextually relevant and should be kept. If you want to specify that the album version is identical to a specific track on an album use the OtherVersionRelationshipType. Jan has written an excellent summary fo the arguments in the debate which I repost here (plus Nikki's and my additions): Against --- - people like having the same track name for the same tracks on different releases. This, however, is already the case for e.g. live tracks on album releases and the same tracks on live releases. - mostly used for tagging purposes, and people contribute to MB primarily for tagging purposes, so these contributors should have more to say on this issue. (- DonRedman wanted to bundle this change with probable changes to the same guidelines with the release of Picard 0.8, but since that will take some time, this does not make sense.) For --- - we loose version information when it's removed - in line with 'state what is on the cover' - when it's removed, a release can have two tracks with the same name, making the track listing ambiguous. - SameTrackRelationshipType is the AR that can state that two tracks have the same content; no need to rename them all to the same name. - The album version isn't necessarily the main version, and the album version may not be called an album version, but instead LP version, 12 version, etc. and in both cases the version info is kept. - There's currently an inconsistency in assumptions we make, i.e. an unlabelled track on a live release is a live version, but an unlabelled track on a single release is an album version. [1] There is one thing I have to clarify here: Lukas wrote: Anyway, using Picard as an argument against removing any info from the database is, in my opinion, silly. I never wanted to say that. I only wanted to avoid changing the same set of guidelines twice in a short period of time. Sorry if it came through differently. DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 18/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: This means we may need to add single version to an edited track on a single that isn't marked like that on the cover. Sometimes this track may be the first released. But it can be very confusing to do it otherwise. say you have a single tracklist that reads: 1) Foo 2) B Side how do you tell whether 1) is a 'single version' or not? not everyone will own the album as well. i don't think we should be adding version info on tracks if it's not written on the sleeve, even if we can proove they are different to the standard. by saying that all indentically named tracks are indenticle in contet you require users to have heard all instances of the track in question. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 18/06/06, Don Redman [EMAIL PROTECTED] wrote: To be concrete: If people are able to retrieve this informtation for tagging purposes, and if ARs are displayed in a more practical way, THEN, there will be no need anymore to give the same track title to all versions of the same song, because people can just follow some ARs that point them to the track with the 'original title'. Whatever the 'original title' is and how the ARs work, will have to be worked out. In conclusion I propose to postpone this debate until Picard 0.8 comes out. I then propose not to lead a debate about principles, but a debate about concete solutions to this and the related problems using contextual track titles (that say (album version) if it makes sense _in context_), ARs (taht point to the same track with the most 'context free' title), and Picard 0.8s tagger script that retrieves all this info and uses it for tagging. i'm not sure i'm reading this right, but surely this is the wrong way round? we should be keeping contextual information *now*, and then perhaps thinking about moving it to ARs when this info can be moved to tags? secondly, i'm not sure tagger script is going to help, as surely that will allow you to assign rules like append version info to track names which is not the same as keep version info same as tracklist, as there's version info we store (or will store) that is not on covers. taggerscript will only help on global preferences - i still think we'll always need context-based rules for what is and isn't included on titles. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
I agree with Nikki's original request, that (album version) be left alone if that is what the original CD carries. We've already got to the tagging vs. music encyclopedia stage of the debate so to avoid this bogging down into those camps my question is: what problem is/was the guideline solving?. It appears to me that the 'problem' is that (in a vanishingly small number of cases, percentage-wise) MB users might end up with two tracks that are identical (except being released at different times on different types of releases) which do not have identical track names. Fundamentally to me, that does not seem a problem. Why would you care? What practical impact is it going to have on your music collection when you try to find or listen to music? And if you did care what are you going to do about the (again very rare) cases where songs are simply retitled for single releases, or where parts in brackets are omitted, differences in punctuation or the opposite problem where different tracks have identical names? I personally ran a script over my collection to attach the original release date (or at least the earliest in MB) to the version I had, even if it was on a greatest hits or compilation. I simply ignored any text in brackets (you can go further and specifically identify certain string formats to ignore), slightly fudged the text to account for punctuation differences and made sure the track time matched within a small tolerance. It worked pretty well (apart from a lack of early vinyl and single release dates) so I'd suggest anyone that really needs to identify the 'same' track on different releases is always going to have to do something like that, or at least for the near future. (At some point in the future it will fall within the MusicBrainz remit to go through and identify every different version, mix, remix, edit, rehearsal take, live track etc. as being fundamentally the same underlying track, and also identifying which are exactly the 'same' for varying definitions of 'the same' but I'm not sure that time is here yet.) cheers, dave ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Chris Bransden wrote: i'm not sure i'm reading this right, but surely this is the wrong way round? we should be keeping contextual information *now*, and then perhaps thinking about moving it to ARs when this info can be moved to tags? No, in my opinion this is not the wrong way around. The wrong way would be to change the guidelines now just to change them again once we have the Picard and page design requirements Don Redman mentioned. Also, I know you fear we might be losing data. However, we're constantly digging up data that using your line of argumentation would already be lost. This information might no longer be on MB, but hey can easily be found. Just think about how many fan pages or cover scans, used to prove an edit, you've seen during the last month. -- derGraph ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Cristov Russell wrote: since the release type isn't tagged. Just as a side note: it is! There just are no players etc. that use these tags. -- derGraph ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/19/06, Chris Bransden [EMAIL PROTECTED] wrote: On 18/06/06, Bogdan Butnaru [EMAIL PROTECTED] wrote: This means we may need to add single version to an edited track on a single that isn't marked like that on the cover. Sometimes this track may be the first released. But it can be very confusing to do it otherwise. say you have a single tracklist that reads: 1) Foo 2) B Side how do you tell whether 1) is a 'single version' or not? not everyone will own the album as well. i don't think we should be adding version info on tracks if it's not written on the sleeve, even if we can proove they are different to the standard. by saying that all indentically named tracks are indenticle in contet you require users to have heard all instances of the track in question. It's not a bijection, it's an injection from tracks to titles. It means that one song (the exact same version) should (almost always) have a single title. There can be multiple versions with the same title (though that's usually avoided using version info; each song should have exactly one title+version info pair, though the version info can be empty for some, preferably only one). (OK, above you should read I think it should be instead of is, it was shorter to write that way.) There are cases when the same song is given different titles, but I think those should be restricted to very, _very_ clear situations, like when some artist calls a song Some Name and then calls the same thing Completely Different Thing (sort of analogue to renaming a band). This does not include (IMO) abreviations, censoring of words, adding/loosing articles. Also, version info is special, in that we usually allow the artist to choose some name for a version, but when it interferes with our injective rule above we overrule them. (Again, read fact statements above as I think it should be that way...) As to how we tell a track on a single is the same? Well, of course we can only tell if we have information. Either there are other versions in the database, or some info on the net. If there are no other versions available for comparison, there's no problem, is there? Anyway, our rules are not written according to what info is available. We have some logical rules, and we attempt to find the info necessary. Many of the ARs are very hard to prove in some cases. -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 19/06/06, derGraph [EMAIL PROTECTED] wrote: Chris Bransden wrote: i'm not sure i'm reading this right, but surely this is the wrong way round? we should be keeping contextual information *now*, and then perhaps thinking about moving it to ARs when this info can be moved to tags? No, in my opinion this is not the wrong way around. The wrong way would be to change the guidelines now just to change them again once we have the Picard and page design requirements Don Redman mentioned. firstly, i don't think any DB/Tagger changes will change the situation (see my previous post). secondly, even if these changes were to work, surely the net result would be that we would store this info, but in a different place - it's simpler to move info than to research and enter it :) Also, I know you fear we might be losing data. However, we're constantly digging up data that using your line of argumentation would already be lost. This information might no longer be on MB, but hey can easily be found. Just think about how many fan pages or cover scans, used to prove an edit, you've seen during the last month. aye, it's not 'lost' in the sense that it can't be found again, but i'd rather we didn't need to in the first place. i for one have gone through my music selection far too many times for discogs and MBz to be doing it again every time we have a rule change :P ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/19/06, Chris Bransden [EMAIL PROTECTED] wrote: On 18/06/06, Don Redman [EMAIL PROTECTED] wrote: In conclusion I propose to postpone this debate until Picard 0.8 comes out. I then propose not to lead a debate about principles, but a debate about concete solutions to this and the related problems using contextual track titles (that say (album version) if it makes sense _in context_), ARs (taht point to the same track with the most 'context free' title), and Picard 0.8s tagger script that retrieves all this info and uses it for tagging. i'm not sure i'm reading this right, but surely this is the wrong way round? we should be keeping contextual information *now*, and then perhaps thinking about moving it to ARs when this info can be moved to tags? secondly, i'm not sure tagger script is going to help, as surely that will allow you to assign rules like append version info to track names which is not the same as keep version info same as tracklist, as there's version info we store (or will store) that is not on covers. taggerscript will only help on global preferences - i still think we'll always need context-based rules for what is and isn't included on titles. The big problem I see with AR's, is that we have to make them before we can use them. At this time, you don't link each song from an Add/Import to the original recording, and I for one will not go through the database now and link thousands upon thousands of songs to their original releases so that identical songs can have identical titles. This seems like so much extra work when we can do this in the title field already! Doesn't anyone else think that the method of applying track AR's is not at a stage where we can easily mass relate songs? Requiring these AR's is just going to cause there to be more and more holes in the database that will never be filled (just like we are missing release dates now, or version info, etc.) and the number of mods required to link individual tracks makes me queasy. Regards, -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Hi, First of all: I think it's a very bad idea to remove information just because people want their music collections ordered nicely. If you have problems with ' (album version)' in a track title, Why not just remove it in your tags? On 6/18/06, Schika [EMAIL PROTECTED] wrote: 1. Title (XY remix) 2. Title (original mix) 3. Title (album mix) 4. Title 5. Title (AV radio edit) All versions have different track durations and sounds different, but the essential question is: what is the original version? track 2, 3 or 4 ? If I would get the album to compare each version, and find out that track 3 is exactly the same as on this single, then should I strip track 3 title to Title. But now what's the title of track 4 and who decides how this unlabeld other version should be named? Not to mention the confusion if track 2 would be on the artist album. Secondly: who decides what is a 'version' name like Tiesto's Oldschool Rework edit and what is not (in this case, what you think is, album version). The problem is same songs are listed under different names, e.g. as album edit or something similar. edit, mix and version are often used for the same thing. Surely we're not going to rename all of these to the same name? We use the name used on the cover for these. ARs can be used to indicate they're the same. Maybe we also have to remove ' (12) ' from track titles, if that's where the song was released on originally. Or perhaps remove (original version), because that might be the same as the album version (e.g. if the album was released first). Or maybe long version on a single indicates it's the same as the album version, because it's a 10 minute long track and the single edit with 3.15 minutes is better suited for radio play. Removing a version name like 'album version' is completely arbitrarily and must stop. If I had anything to say. -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Removing a version name like 'album version' is completely arbitrarily and must stop. If I had anything to say. of course you do. your position as a major contributor (#1 on the top editors list) gives your voice a bit more weight IMHO than a normal contributor might have. regards, stefan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/19/06, Stefan Kestenholz [EMAIL PROTECTED] wrote: Removing a version name like 'album version' is completely arbitrarily and must stop. If I had anything to say. of course you do. your position as a major contributor (#1 on the top editors list) gives your voice a bit more weight IMHO than a normal contributor might have. regards, stefan This is getting a little off topic, but I have to say it... You cannot weight someone's opinions more heavily based on the number of edits they perform. I'm not saying they don't deserve credit for putting in their hard work, but I don't think we should be handing the guidelines over to the highest modder. If styleguides were decided by the top 10 modders only, then we wouldn't have these mailing lists... Regards, -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Mon, 19 Jun 2006 12:19:41 +0200, Chris Bransden wrote: firstly, i don't think any DB/Tagger changes will change the situation (see my previous post). Well, my experience says the opposite. In my very humble experience here at MB, every change at the fringes of the overall structure of the system has led to changes in the semantics of the MB data. The semantical changes are usually - not at the same 'place' as the structural changes, - sometimes huge and drastic - sometimes very minor, but then lead to an outburst of an old problem four months later. I therefore strongly suggest to disucss such a change (which I am for BTW) around the time when we make our first experiences with the tagger script. @Lukas: Can you tell us how long you assume it will take to release a Picard with tagger script? DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Mon, 19 Jun 2006 14:46:40 +0200, Aaron Cooper wrote: The big problem I see with AR's, is that we have to make them before we can use them. At this time, you don't link each song from an Add/Import to the original recording, and I for one will not go through the database now and link thousands upon thousands of songs to their original releases so that identical songs can have identical titles. Um, I proposed to use ARs so that identical songs can have different (context related) titles. Which is the exact opposite fo what you are writing here. And I would never suggest that editors should first add all the ARs before making the change. What I suggest is that we should make the change, when there is a feature in place, that makes such ARs *useful* to taggers. Because then people will add these ARs in order to use them in their tagging process. Doesn't anyone else think that the method of applying track AR's is not at a stage where we can easily mass relate songs? I remember that someone had written an incredibly simple and cool UI to add new ARs. It did not even work inside of MB but loaded MB in a frame and allowed you to drag and drop links from MB into fields and then add these ARs. It was really simple and it worked. Does someone remember who this was? DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/19/06, Don Redman [EMAIL PROTECTED] wrote: On Mon, 19 Jun 2006 14:46:40 +0200, Aaron Cooper wrote: The big problem I see with AR's, is that we have to make them before we can use them. At this time, you don't link each song from an Add/Import to the original recording, and I for one will not go through the database now and link thousands upon thousands of songs to their original releases so that identical songs can have identical titles. Um, I proposed to use ARs so that identical songs can have different (context related) titles. Which is the exact opposite fo what you are writing here. And I would never suggest that editors should first add all the ARs before making the change. What I suggest is that we should make the change, when there is a feature in place, that makes such ARs *useful* to taggers. Because then people will add these ARs in order to use them in their tagging process. Doesn't anyone else think that the method of applying track AR's is not at a stage where we can easily mass relate songs? I remember that someone had written an incredibly simple and cool UI to add new ARs. It did not even work inside of MB but loaded MB in a frame and allowed you to drag and drop links from MB into fields and then add these ARs. It was really simple and it worked. Does someone remember who this was? DonRedman That sounds amazing - exactly like what I was imagining. This would definitely make things easier for us. But as you said, right now there is very little motivation to create these ARs. -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Mon, 19 Jun 2006 12:15:19 +0200, Bogdan Butnaru wrote: On 6/19/06, Chris Bransden [EMAIL PROTECTED] wrote: by saying that all indentically named tracks are indenticle in contet you require users to have heard all instances of the track in question. It's not a bijection, it's an injection from tracks to titles. It means that one song (the exact same version) should (almost always) have a single title. There can be multiple versions with the same title (though that's usually avoided using version info; each song should have exactly one title+version info pair, though the version info can be empty for some, preferably only one). There is no entity in the MusicBrainz database representing songs. I think that is the flaw in this argument. Yes, if there was an entity representing a song, then it would be a good idea to have only one name for this entity (indeed it would be stupid to give one entity several names). But *there is no such entity*! There is only an entity that represents tracks. So, please do not write song when you should write track. For more details please read ObjectModel on the wiki. A track is always on an album. If you force the title of two tracks to be identical if the tracks are based on the same song, then you force editors to remove all information from the track title that is contextually relevant to one release only. This is what the debate is about. IMO it is a very bad idea to force an entity to semantically represent something which differs considerably from its structural role in the relational database. DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Mon, 19 Jun 2006 11:42:22 +0200, david scotson wrote: I personally ran a script over my collection to attach the original release date (or at least the earliest in MB) to the version I had, even if it was on a greatest hits or compilation. I simply ignored any text in brackets (you can go further and specifically identify certain string formats to ignore), slightly fudged the text to account for punctuation differences and made sure the track time matched within a small tolerance. It worked pretty well (apart from a lack of early vinyl and single release dates) so I'd suggest anyone that really needs to identify the 'same' track on different releases is always going to have to do something like that, or at least for the near future. And there are PUIDs. There are not enough of them yet, but isn't that what they are supposed to be for, eh? DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/19/06, Don Redman [EMAIL PROTECTED] wrote: On Mon, 19 Jun 2006 12:15:19 +0200, Bogdan Butnaru wrote: On 6/19/06, Chris Bransden [EMAIL PROTECTED] wrote: by saying that all indentically named tracks are indenticle in contet you require users to have heard all instances of the track in question. It's not a bijection, it's an injection from tracks to titles. It means that one song (the exact same version) should (almost always) have a single title. There can be multiple versions with the same title (though that's usually avoided using version info; each song should have exactly one title+version info pair, though the version info can be empty for some, preferably only one). There is no entity in the MusicBrainz database representing songs. I think that is the flaw in this argument. Yes, if there was an entity representing a song, then it would be a good idea to have only one name for this entity (indeed it would be stupid to give one entity several names). But *there is no such entity*! There is only an entity that represents tracks. So, please do not write song when you should write track. For more details please read ObjectModel on the wiki. A track is always on an album. If you force the title of two tracks to be identical if the tracks are based on the same song, then you force editors to remove all information from the track title that is contextually relevant to one release only. This is what the debate is about. IMO it is a very bad idea to force an entity to semantically represent something which differs considerably from its structural role in the relational database. DonRedman Perhaps this is what is wrong with MB. I've pictured compiling a pool of Songs an Artist has recorded. Each has an official Title and is released on several Releases with varying Attributes. I think this would help us keep things tidy, by only having one Title for each Song. I think we sort of discussed this about adding Classical recordings and being able to select the works on the recording from a list of works the author has written. Anyways, maybe that's coming in the new version... some day. -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] (album version)
I disagree. ...remember MusicBrainz is a meritocracy. The people who do the work decide how things are done. If you want to have a say in that, too, get involved. Learn and become a MajorContributor, too. [excerpt of the wiki MusicBrainzDevelopment linked below] http://wiki.musicbrainz.org/MusicBrainzDevelopment Those people that put the most work into the project should have the larger say in what happens with the guidelines and how things work. They are after all putting in their time and effort in. Why should someone how barely edits have the same say as a major contributor? This is not a democracy. (thank god!) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Cooper Sent: Monday, June 19, 2006 9:12 AM To: MusicBrainz style discussion Subject: Re: [mb-style] (album version) On 6/19/06, Stefan Kestenholz [EMAIL PROTECTED] wrote: Removing a version name like 'album version' is completely arbitrarily and must stop. If I had anything to say. of course you do. your position as a major contributor (#1 on the top editors list) gives your voice a bit more weight IMHO than a normal contributor might have. regards, stefan This is getting a little off topic, but I have to say it... You cannot weight someone's opinions more heavily based on the number of edits they perform. I'm not saying they don't deserve credit for putting in their hard work, but I don't think we should be handing the guidelines over to the highest modder. If styleguides were decided by the top 10 modders only, then we wouldn't have these mailing lists... Regards, -- -Aaron ___ 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] (album version)
I didn't say only by the number of edits. That states contributions, there are many ways to contribute. Zout happens to contribute with edits, has been on the style council has done a lot for MB, I think that is a fair reason zout's thoughts should have a bit more weight. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of derGraph Sent: Monday, June 19, 2006 2:34 PM To: MusicBrainz style discussion Subject: Re: [mb-style] (album version) Beth wrote: I disagree. [...] Why should someone how barely edits have the same say as a major contributor? There's a flaw in your reasoning: you cannot measure the contribution only by the number of edits. -- derGraph ___ 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] (album version)
On 6/19/06, Beth [EMAIL PROTECTED] wrote: I didn't say only by the number of edits. That states contributions, there are many ways to contribute. Zout happens to contribute with edits, has been on the style council has done a lot for MB, I think that is a fair reason zout's thoughts should have a bit more weight. Thanks for the support, but I think everyone deserves an opinion. I don't think my opinion should count for more, because we try to get consensus, not count votes and let the majority have their way. Speaking of consensus: we will never get it on this issue. Therefore, I'd like Robert as 'style overlord' to make a decision so that we won't have to discuss the same issue every month. I've made a small summary, I hope I haven't forgotten any arguments. If so, please reply and add them in one of the lists below. The Idea: Keeping 'album version' in track titles as opposed to the present situation. Against --- - people like having the same track name for the same tracks on different releases. this, however, is already the case for e.g. live tracks on album releases and the same tracks on live releases. - mostly used for tagging purposes, and people contribute to MB primarily for tagging purposes, so these contributors should have more to say on this issue. For --- - we loose version information when it's removed - in line with 'state what is on the cover' - when it's removed, a release can have two tracks with the same name, making the track listing ambiguous. - SameTrackRelationshipType is the AR that can state that two tracks have the same content; no need to rename them all to the same name. -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Jun 19, 2006, at 8:00 AM, Stefan Kestenholz wrote: Removing a version name like 'album version' is completely arbitrarily and must stop. If I had anything to say. of course you do. your position as a major contributor (#1 on the top editors list) gives your voice a bit more weight IMHO than a normal contributor might have. I think Aaron's response was already fairly well spot on. Everyone in the Style Council has a voice and that voice is not really connected to the number of edits made by that person. We do appreciate the hard work by all of our editors, but that shouldn't give them greater power here. If we did, then it would simply destabilize this body that works hard to make things clear. We've had this problem in the past and it was very painful experience for me. :-( -- --ruaok Somewhere in Texas a village is *still* missing its idiot. Robert Kaye -- [EMAIL PROTECTED] --http://mayhem-chaos.net ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] (album version)
Sorry, I stand corrected. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Kaye Sent: Monday, June 19, 2006 3:18 PM To: MusicBrainz style discussion Subject: Re: [mb-style] (album version) On Jun 19, 2006, at 8:00 AM, Stefan Kestenholz wrote: Removing a version name like 'album version' is completely arbitrarily and must stop. If I had anything to say. of course you do. your position as a major contributor (#1 on the top editors list) gives your voice a bit more weight IMHO than a normal contributor might have. I think Aaron's response was already fairly well spot on. Everyone in the Style Council has a voice and that voice is not really connected to the number of edits made by that person. We do appreciate the hard work by all of our editors, but that shouldn't give them greater power here. If we did, then it would simply destabilize this body that works hard to make things clear. We've had this problem in the past and it was very painful experience for me. :-( -- --ruaok Somewhere in Texas a village is *still* missing its idiot. Robert Kaye -- [EMAIL PROTECTED] --http://mayhem-chaos.net ___ 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] (album version)
On Mon, 19 Jun 2006 23:18:16 +0200, Robert Kaye wrote: Everyone in the Style Council has a voice and that voice is not really connected to the number of edits made by that person. We do appreciate the hard work by all of our editors, but that shouldn't give them greater power here. If we did, then it would simply destabilize this body that works hard to make things clear. There is a big difference between meritocracy and the more you do the more you have to say. The way the Style Council works (both factually and the way Robert and me concieved the current council) has more to do with this: If you have made well balanced arguments in the past, then people will consider your arguments with more care. If you make a good contribution to the debate now, people will value it now. I ask people who are new to the council not to make an uninformed veto, but they could and I would respect it. When I have called for a vote on the LatinCapitalization issue, people jumped in and worked towards a consensus. That really made me happy. To say I have done a lot of work on that domain of MB, now I want to have a say in this domain will never work. No open source project works like this. People are respected in the domains in which they have done good work. And respect is something you earn, you do not claim it. I was thankful when Chris Bransden wrote: no offence intended toward don, but unless i'm mistaken, we're all equal in style discussions, unless there is no consensus, in which case Rob Kaye steps in. Because I did not want my statement to be misunderstood as a ruling. And I would not want Robert to listen to my oppinion when it came to Perl programming :-) Finally thanks to Jan that you stepped of this. And now back to the topic! DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
1) the style council does not exist, for a long time now already. everybody who speaks here (except rob and don) are community members like everybody else. 2) the reason i wrote that statement before is because jan said if i had a say here which, if you read between the lines, speaks for a frustration with the ongoing processes to always take the discussions on tangents rather than discussing towards a solution which satisfies the majority of member of the community. 3) now if you take my statement literally, it does not do the issue justice. if you look at the big picture, the major contributor idea is not related to the number of edits a person made. its just a side-effect for the big commitment someone undoubtfully has for the project. why does everbody back down suddenly on the meritocracy aspect, 2 weeks ago there was a consensus that this is how MB works. On 6/19/06, Beth [EMAIL PROTECTED] wrote: Sorry, I stand corrected. don't be sorry, you said straight what you felt. this female (or feeling, rather than analytic, brainy) point of view is severly lacking in these kind of discussions, because of the testosterone driven way of proving ones own points all the time. i therefore suggest that you state your opinion more openly in these kind of communication/social structure issues, because its very embrace this pov, too. -- keschte ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
guidelines over to the highest modder. If styleguides were decided by the top 10 modders only, then we wouldn't have these mailing lists... but we don't have the mailing lists for unbelievably bloated dicussions like this one. please be aware, that this is a personal opinion, and does not reflect my official opinion as a musicbrainz developer. (the previous statement about this issue not being an problem which needs coding work, but a sensible change of the style guideline, if nikkis idea was embraced, was). now i can't really follow the arguments against this idea, since the quantity vs. quality and the blog post about the future of musicbrainz clearly state we'll try to get the data more correct in future iterations of the data structure. the end goal, is to have the current titles to reflect _exactly_ whats written on the album cover, to make those happy which want their tags to reflect this as much as possible. we'll have several layers of abstraction, until you have an object which is the same for all recordings (and releases) of a song, you can study the ObjectModel or NextGenerationSchema on the wiki to get an idea. I'm sicking tired of explaining this over and over again, i hope we'll get it right this time to bring the documentation a bit more into the open with the next server release. if not, we'll have to start posting the ideas on the blog, such that we'll be discussing on the same page next time. regards, Stefan ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/19/06, Don Redman [EMAIL PROTECTED] wrote: And now back to the topic! now that the discussion finally was getting interesting ;-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Mon, Jun 19, 2006 at 11:17:38PM +0200, Jan van Thiel wrote: I've made a small summary, I hope I haven't forgotten any arguments. If so, please reply and add them in one of the lists below. Thanks for this! Against --- - people like having the same track name for the same tracks on different releases. this, however, is already the case for e.g. live tracks on album releases and the same tracks on live releases. - mostly used for tagging purposes, and people contribute to MB primarily for tagging purposes, so these contributors should have more to say on this issue. For --- - we loose version information when it's removed - in line with 'state what is on the cover' - when it's removed, a release can have two tracks with the same name, making the track listing ambiguous. - SameTrackRelationshipType is the AR that can state that two tracks have the same content; no need to rename them all to the same name. Also: - The album version isn't necessarily the main version, and the album version may not be called an album version, but instead LP version, 12 version, etc. and in both cases the version info is kept. - There's currently an inconsistency in assumptions we make, i.e. an unlabelled track on a live release is a live version, but an unlabelled track on a single release is an album version. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Mon, 19 Jun 2006 23:17:38 +0200, Jan van Thiel wrote: The Idea: Keeping 'album version' in track titles as opposed to the present situation. Against --- - people like having the same track name for the same tracks on different releases. this, however, is already the case for e.g. live tracks on album releases and the same tracks on live releases. - mostly used for tagging purposes, and people contribute to MB primarily for tagging purposes, so these contributors should have more to say on this issue. Against doing it now: - SameTrack ARs will get entered much more frequently if the TaggerScript uses them. We will probably need a Style change in this area anyway. If Picard 0.8 comes out within a month, then would be two consecutive changes. (this argument does not hold if Lukas says Picard 0.8 takes longer) For --- - we loose version information when it's removed - in line with 'state what is on the cover' - when it's removed, a release can have two tracks with the same name, making the track listing ambiguous. - SameTrackRelationshipType is the AR that can state that two tracks have the same content; no need to rename them all to the same name. DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Tue, Jun 20, 2006 at 12:38:14AM +0200, Don Redman wrote: Against doing it now: - SameTrack ARs will get entered much more frequently if the TaggerScript uses them. We will probably need a Style change in this area anyway. I don't quite understand the point here, once we have tagger script we can simply remove (album version) if it exists (equivalent to current guideline) and if we can then use relationships, surely the name of the current track could be bypassed to use the name of the original track (again making (album version) disappear). In both these cases, why would we want to prefer to remove album version from tags (i.e. keep the current guideline), when both fix the main objection to keeping it? If Picard 0.8 comes out within a month, then would be two consecutive changes. (this argument does not hold if Lukas says Picard 0.8 takes longer) Well, 0.7 is not a stable release yet (according to the wiki page...), so I can't imagine 0.8 being here in under a month. Of course, maybe Lukáš has stuff hidden up his sleeve. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] (album version)
I honestly get tired of the constant demand to discuss this stuff to death. I see stating your views, and then letting it get refined. Often times it goes much past stating viewpoints and more to whining. I feel it truly is those who put the effort into the community that should have a say as to how things go. That doesn't mean, that number of votes at the top, or that count of wiki you've edited, or the number of lines of code, or the thousand (I wish) dollars you contributed. It simply means, those that work toward solutions and making mb work should and often times do have a bit more weight in discussions, which to me seems very right. I may have misstated it, or misrepresented that point of view, and for that I do apologize. I feel if people want to have a larger say, they should become more involved.. more toward the solution. I've been very open about this too. Sometimes it seems to step on toes. That as well I am sorry about. :( Can't win 'em all. :) Nyght aka Beth -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Stefan Kestenholz Sent: Monday, June 19, 2006 3:56 PM To: MusicBrainz style discussion Subject: Re: [mb-style] (album version) 1) the style council does not exist, for a long time now already. everybody who speaks here (except rob and don) are community members like everybody else. 2) the reason i wrote that statement before is because jan said if i had a say here which, if you read between the lines, speaks for a frustration with the ongoing processes to always take the discussions on tangents rather than discussing towards a solution which satisfies the majority of member of the community. 3) now if you take my statement literally, it does not do the issue justice. if you look at the big picture, the major contributor idea is not related to the number of edits a person made. its just a side-effect for the big commitment someone undoubtfully has for the project. why does everbody back down suddenly on the meritocracy aspect, 2 weeks ago there was a consensus that this is how MB works. On 6/19/06, Beth [EMAIL PROTECTED] wrote: Sorry, I stand corrected. don't be sorry, you said straight what you felt. this female (or feeling, rather than analytic, brainy) point of view is severly lacking in these kind of discussions, because of the testosterone driven way of proving ones own points all the time. i therefore suggest that you state your opinion more openly in these kind of communication/social structure issues, because its very embrace this pov, too. -- keschte ___ 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
[mb-style] (album version)
This keeps coming up and I hate it. ExtraTitleInformationStyle says If the release is a single, of course one of the tracks is going to be the album version. I think this is completely wrong. A single does not necessarily have to include an album version and to me, the 'default' version on a single is the *single* version, given that it's, well, a single. Also, an album also does not necessarily have to include all songs from a single, so there may not even *be* an album version in existence. A single also need not include a single version, and if it does, it doesn't necessarily have to be labelled as such. By removing '(album version)', we're making it completely ambiguous. Is it an unlabelled single version? Is it an album version? Is it a mistakenly unlabelled remix, edit or live version? We're also being inconsistent, LiveTrackStyle says tracks should not contain (live) as the release status is live. Surely, by this logic, we should not remove (album version) from singles and remove (single version) instead. I personally don't like removing any of the version information from singles, they can and do contain so many different versions (single, album, live, radio edit, etc.) that you can't really say any particular version is the default. So why should album version be assumed to be the default version for singles and not live albums? --Nikki P.S. Won't we have to go back and add (album version) back to all the singles once we have NGS? ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
What she said. Really. I can't phrase it any better than what Nikki did, but those are words straight out of my heart as well. It's so totally arbitrary that it sickens me, and we're losing information over it all the time which will be if not impossible, take lots and lots and lots of work to get back. Can't we just nuke the stupid (album version) rule once and for all? Please? //[bnw] Citerar Nikki [EMAIL PROTECTED]: This keeps coming up and I hate it. ExtraTitleInformationStyle says If the release is a single, of course one of the tracks is going to be the album version. I think this is completely wrong. A single does not necessarily have to include an album version and to me, the 'default' version on a single is the *single* version, given that it's, well, a single. Also, an album also does not necessarily have to include all songs from a single, so there may not even *be* an album version in existence. A single also need not include a single version, and if it does, it doesn't necessarily have to be labelled as such. By removing '(album version)', we're making it completely ambiguous. Is it an unlabelled single version? Is it an album version? Is it a mistakenly unlabelled remix, edit or live version? We're also being inconsistent, LiveTrackStyle says tracks should not contain (live) as the release status is live. Surely, by this logic, we should not remove (album version) from singles and remove (single version) instead. I personally don't like removing any of the version information from singles, they can and do contain so many different versions (single, album, live, radio edit, etc.) that you can't really say any particular version is the default. So why should album version be assumed to be the default version for singles and not live albums? --Nikki P.S. Won't we have to go back and add (album version) back to all the singles once we have NGS? ___ 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] (album version)
On 6/18/06, Thomas Tholén [EMAIL PROTECTED] wrote: What she said. Really. I can't phrase it any better than what Nikki did, but those are words straight out of my heart as well. It's so totally arbitrary that it sickens me, and we're losing information over it all the time which will be if not impossible, take lots and lots and lots of work to get back. Can't we just nuke the stupid (album version) rule once and for all? Please? What they said. Please! -- Jan van Thiel (zout) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] (album version)
All support dropping the getting rid of (album version) too. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Nikki wrote: By removing '(album version)', we're making it completely ambiguous. I disagree. For my own use, if the track on the single is the same version as that on the album, it gets no version info because it is *the same track*. When I search for this track I see that it appears in two places: the album and the single. Of course, I can also see version information for other *mixes* of the same track but my concern is how many times this exact track appears in my collection. Take this example: The Album Track The Album Track (album version) What's different about these? Nothing except they appear on two different items. They are both The Album Track. (album version) is extraneous because there is nothing different about these tracks. What about compilations? Should we append all tracks there with (album version)? The item to note here is where the track appears: album, compilation, live, single, EP. If it's the same track as the one that's on the album, woot! There's no reason to note it otherwise. Paula (spacefish) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Agree completely. Michelle (dirtyboots) This keeps coming up and I hate it. ExtraTitleInformationStyle says If the release is a single, of course one of the tracks is going to be the album version. I think this is completely wrong. A single does not necessarily have to include an album version and to me, the 'default' version on a single is the *single* version, given that it's, well, a single. _ realestate.com.au: the biggest address in property http://ninemsn.realestate.com.au ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] (album version)
We have earliest version of... not sure if it could be used in this same instance though. I also felt spacefish was referring to their own personal collection, which ARs don't cover. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Tholén Sent: Sunday, June 18, 2006 2:28 AM To: MusicBrainz style discussion Subject: Re: [mb-style] (album version) You'll never git reid of the fact that same tracks have different names in different contexts. For example live tracks will have the same effect. To sort out which tracks are exactly the same you need somethin else. Anis the same track as-AR (Do we already have one of those?) And I don't really see (album version) as stating that it is the same verion as on an album, I see it as recording the title under which this particular track is present on this particular release. //[bnw] Nikki wrote: By removing '(album version)', we're making it completely ambiguous. I disagree. For my own use, if the track on the single is the same version as that on the album, it gets no version info because it is *the same track*. When I search for this track I see that it appears in two places: the album and the single. Of course, I can also see version information for other *mixes* of the same track but my concern is how many times this exact track appears in my collection. Take this example: The Album Track The Album Track (album version) What's different about these? Nothing except they appear on two different items. They are both The Album Track. (album version) is extraneous because there is nothing different about these tracks. What about compilations? Should we append all tracks there with (album version)? The item to note here is where the track appears: album, compilation, live, single, EP. If it's the same track as the one that's on the album, woot! There's no reason to note it otherwise. Paula (spacefish) ___ 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] (album version)
I also felt spacefish was referring to their own personal collection, which ARs don't cover. I don't really understand how or what, but I suppose it's a tagger issue then? //[bnw] -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Thomas Tholén Sent: Sunday, June 18, 2006 2:28 AM To: MusicBrainz style discussion Subject: Re: [mb-style] (album version) You'll never git reid of the fact that same tracks have different names in different contexts. For example live tracks will have the same effect. To sort out which tracks are exactly the same you need somethin else. Anis the same track as-AR (Do we already have one of those?) And I don't really see (album version) as stating that it is the same verion as on an album, I see it as recording the title under which this particular track is present on this particular release. //[bnw] Nikki wrote: By removing '(album version)', we're making it completely ambiguous. I disagree. For my own use, if the track on the single is the same version as that on the album, it gets no version info because it is *the same track*. When I search for this track I see that it appears in two places: the album and the single. Of course, I can also see version information for other *mixes* of the same track but my concern is how many times this exact track appears in my collection. Take this example: The Album Track The Album Track (album version) What's different about these? Nothing except they appear on two different items. They are both The Album Track. (album version) is extraneous because there is nothing different about these tracks. What about compilations? Should we append all tracks there with (album version)? The item to note here is where the track appears: album, compilation, live, single, EP. If it's the same track as the one that's on the album, woot! There's no reason to note it otherwise. Paula (spacefish) ___ 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 ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/18/06, Thomas Tholén [EMAIL PROTECTED] wrote: I also felt spacefish was referring to their own personal collection, which ARs don't cover. I don't really understand how or what, but I suppose it's a tagger issue then? //[bnw] No, I guess that Paula don't want to see the exactly same track (everything is simular, track lenght, version, sound ...) appearing one time as Title and another time as Title (album version). -- .: NOP AND NIL :. .: Schika :. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Thomas Tholén wrote: And I don't really see (album version) as stating that it is the same verion as on an album, I see it as recording the title under which this particular track is present on this particular release. But just as (feat. artist B) is not part of the track title, neither is (album version). The problem with MB is that there is no separate field for version information and there really ought to be. And live tracks are always noted by the fact that they either appear on a live item or are appended with (version information) on non-live items. I also felt spacefish was referring to their own personal collection, which ARs don't cover. I don't really understand how or what, but I suppose it's a tagger issue then? I was referring to my own database, correct. (Yes, I'm that obsessive. :) ) Although I don't use MB for tagging, I do refer to it for general tagging purposes, but only as a guideline. (I am waiting for Picard beta 0.8 for the MBID-only tagging option) In the simplest terms this becomes a tagging issue, I suppose, though not my primary concern. Paula (spacefish ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Schika wrote: On 6/18/06, Thomas Tholén [EMAIL PROTECTED] wrote: I also felt spacefish was referring to their own personal collection, which ARs don't cover. I don't really understand how or what, but I suppose it's a tagger issue then? //[bnw] No, I guess that Paula don't want to see the exactly same track (everything is simular, track lenght, version, sound ...) appearing one time as Title and another time as Title (album version). Exactly. :) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/18/06, Paula Callesøe [EMAIL PROTECTED] wrote: But just as (feat. artist B) is not part of the track title, neither is (album version). The problem with MB is that there is no separate field for version information and there really ought to be. I like the idea of a seperate field for version information. -- .: NOP AND NIL :. .: Schika :. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
I really don't want *identical* tracks to have different Titles. If the track was *originally* released on an album then the *identical* song on a Single release should have an *identical* title to the original Album release. Adding (album version) makes these songs completely different (when comparing titles, which is what most players Last.fm do). I think it is easily assumed that any track on a Single release without any special attributes (live)/(acoustic)/(demo)/(remix)/(edit) is a song which has been previously recorded or is not live/acoustic/a demo/remixed/edited version of the orginal. I think this is obvious because Albums are the primary releases of ~99% of artists and a Single usually highlights a specific song from an existing album. I just think the original release is the most important, so its seems ridiculous to have an identical song released on a single and have it titled with (album version). Just think about a Single that has 3 or 4 songs from an existing album - which is not overly rare. We will have a single with titles: St. Anger (edit), St. Anger (album version), The Unnamed Feeling (album version), Some Kind of Monster (album version), Frantic (album version), St. Anger (live). Wouldn't that seem crazy? If the songs exist identically on an Album already, I think they should be titled identically. A (single version) is an edited version of an original song so I definitely will argue that it should not drop its attributes to look like the original. Ugh... -Aaron (cooperaa) On 6/18/06, Nikki [EMAIL PROTECTED] wrote: This keeps coming up and I hate it. ExtraTitleInformationStyle says If the release is a single, of course one of the tracks is going to be the album version. I think this is completely wrong. A single does not necessarily have to include an album version and to me, the 'default' version on a single is the *single* version, given that it's, well, a single. Also, an album also does not necessarily have to include all songs from a single, so there may not even *be* an album version in existence. A single also need not include a single version, and if it does, it doesn't necessarily have to be labelled as such. By removing '(album version)', we're making it completely ambiguous. Is it an unlabelled single version? Is it an album version? Is it a mistakenly unlabelled remix, edit or live version? We're also being inconsistent, LiveTrackStyle says tracks should not contain (live) as the release status is live. Surely, by this logic, we should not remove (album version) from singles and remove (single version) instead. I personally don't like removing any of the version information from singles, they can and do contain so many different versions (single, album, live, radio edit, etc.) that you can't really say any particular version is the default. So why should album version be assumed to be the default version for singles and not live albums? --Nikki P.S. Won't we have to go back and add (album version) back to all the singles once we have NGS? ___ 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] (album version)
By my reading of the rules (and in my opinion, too), the rule for (album version) is: (1) _usually_ tracks are released as album tracks. The _usual_ situation is that some tracks from the album are released on singles too. It's true that some tracks are released initially on singles, or only on singles, or some artist may release only singles. This doesn't change the fact that the vast majority of songs are released as album tracks. This means that the title of a song is the title it appears with on the album. (2) It's reasonable to expect (though here I'm sure there are disagreements) that a song have a single name (by a song I mean the exact same song, not remixes, edits, etc.), no matter where it appears. So at least some people (me included, I'd expect a lot others) want to have that song tagged the same, no matter where it is in the collection. The only way to do that _with our current taggers_ is to have the same title, meaning we must remove the album version _note_ on singles. This means we may need to add single version to an edited track on a single that isn't marked like that on the cover. Sometimes this track may be the first released. But it can be very confusing to do it otherwise. By the way, we do have the http://wiki.musicbrainz.org/SameTrackRelationshipType to clarify the identical tracks. We can use http://wiki.musicbrainz.org/OtherVersionRelationshipType or, more likely, http://wiki.musicbrainz.org/RemixRelationshipType for separating other versions, including single versions. If we're careful about that, we don't really loose any information. We may be able to add more options in the future, but until then—and it will be a while—I think the current system is the best we can do. -- Bogdan Butnaru — [EMAIL PROTECTED] I think I am a fallen star, I should wish on myself. – O. ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Sun, Jun 18, 2006 at 05:30:02AM -0400, Aaron Cooper wrote: I really don't want *identical* tracks to have different Titles. If the track was *originally* released on an album then the *identical* song on a Single release should have an *identical* title to the original Album release. Adding (album version) makes these songs completely different (when comparing titles, which is what most players Last.fm do). And removing (live) makes players think two completely different versions are the same. Does that not bother you? Players also can't distinguish between Some Title (an album) and Some Title (a single), but we don't change our style guidelines to change this so that people can tag their files easier because that info is stored in the release type. What about when a live track features on an album and a live release? The album will have Some Track (live) but the live release will have Some Track. Those are the same track with two different names too! I think it is easily assumed that any track on a Single release without any special attributes (live)/(acoustic)/(demo)/(remix)/(edit) is a song which has been previously recorded or is not live/acoustic/a demo/remixed/edited version of the orginal. I think this is obvious because Albums are the primary releases of ~99% of artists and a Single usually highlights a specific song from an existing album. So what happens if the single version is unlabelled? Do we invent a version for it and remove (album version) which is on the cover? Aren't people usually throwing hissy fits because we deviate from the cover too much? I could find plenty of single versions which came before the album. Why don't we take those to be the default version (as they're the originally released version), remove (single version) and add (album version) to the album which was released later? It's just a Western(?) assumption that album = default (which isn't the case in Japan, for example). I don't like assuming things because you then have to tell people what assumptions to make (like I said, my assumption would be that the single contains a single version). In this case, you're asking people to assume all unlabelled tracks are album versions, yet because of how things are, many unlabelled tracks are really some other version with missing information. For example, http://musicbrainz.org/showmod.html?modid=3917259 where two versions exist. One has the album version (unlabelled) and one has the live version. Someone then assumed that the unlabelled one must be a mistake and tried to merge them because the version info has been lost. I just think the original release is the most important, so its seems ridiculous to have an identical song released on a single and have it titled with (album version). Just think about a Single that has 3 or 4 songs from an existing album - which is not overly rare. We will have a single with titles: St. Anger (edit), St. Anger (album version), The Unnamed Feeling (album version), Some Kind of Monster (album version), Frantic (album version), St. Anger (live). Wouldn't that seem crazy? If that's what they put on the cover, then why is it crazy? I don't think it's ridiculous to have contextual information. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
I agree totally with removing the album version rule. To answer a few points raised. Identical tracks should always (in theory) all be identically titled, but in reality this will never happen. A live track will have (live) added to the title if its released as a track on a studio recorded release, the same with a demo track. Now I would expect a track that appears on an album to be the album version, and I would expect the same track appearing on a single to be the single version (unless otherwise titled). But if a track appears on a release and is titled track (album version) then it should be titled as such no matter what it is released on. Albums are NOT the primary release of every artist, there are a lot of dance/techno artists in MB who have never released an album, yet have a huge discography listed, so suggesting that an album version is the original/primary version is incorrect. And the single version is not always an edited version of the album version. Using the single Lift by 808 State as an example This single has been released in multiple versions and include the following versions of the track Lift: Lift Lift (7 mix) Lift (12 mix) Lift (Justin Strauss remix) Lift (Metro mix) Lift (Lift Up dub) Lift (7 version) Lift (Heavy mix) Lift (LP version) Now if we start removing (LP version) from the last track listed, how are supposed to differenciate between the original Lift and the LP version? Removing version info from any of these tracks could lead to the wrong PUID be attached to the wrong version, making PUID identification worthless. Also I don't see that how a media player sorts files should have any impact on how we record data, we are meant to be building an accurate database of music, not creating user friendly playlists for mp3 players. Mudcrow ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/18/06, Nikki [EMAIL PROTECTED] wrote: (2) It's reasonable to expect (though here I'm sure there are disagreements) that a song have a single name (by a song I mean the exact same song, not remixes, edits, etc.), no matter where it appears. So at least some people (me included, I'd expect a lot others) want to have that song tagged the same, no matter where it is in the collection. The only way to do that _with our current taggers_ is to have the same title, meaning we must remove the album version _note_ on singles. It also means putting (live) onto live albums. Do you support adding that to every single track of a live album for consistency? If we decided to, sure why not? Then we would know the live songs are (live), but it isn't super critical because in most cases, the live recording is of the original recording. One exception to this is when a band plays only a portion of the original recording, like Metallica only playing the first half of Master of Puppets. In this case, most people call the song Master of Puppets (jam/excerpt/etc) or even a fan-given name of the Master of Puppets/Welcome Home (Sanitarium) medley... which is escaping me at the moment. By the way, we do have the http://wiki.musicbrainz.org/SameTrackRelationshipType to clarify the identical tracks. See, we can link identical tracks together, so we don't need the name to be the same as we can already store the fact they're identical. This argument is used in other places, so why can't it apply here? It just seems to be a load of whining about My tags! They're not the same! which applies to other things too but those aren't changed to make tagging easier because we simply state MusicBrainz isn't just for tagging. At this time linking tracks has no practical application and seems useless to me. I do hope that we will be able to use this information in the ARs some day, but I don't want to have to go through all of Metallica's bootlegs and say X is a live recording of Y just to have that relationship - I don't think anyone wants to! It's obvious that MusicBrainz isn't just for tagging because we wouldn't be storing all this information in relationships if it were. Picard 0.8, I believe, will be when the tagger script is implemented, so then people will be able to automatically strip (album version) if they want, but you can't automatically add (album version) because there's no context. If the album version is not the original recording, then by all means - append (album version). In the St. Anger single there is an edited version of the track and the original/album version. The cover may say (album version) but as you said above, we can say X is the original recording of Y and drop the (album version) from the title. I suppose if we REALLY wanted to make things confusing we could also drop the (edited version) information and throw that into an AR as well! Yipes! Regards, -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] (album version)
Well, I will say I don't mind if every live is tagged (live) or is annotated (live). I do feel there is a big benefit in having all the songs of similar nature named the same thing. It does fit more with the schema of universal naming I have heard mentioned before. But, I think it should be done the whole way we're not supposed to change the database structure specifically for tagging purposes and we're as well not supposed to change it for lastfm. That said, I think we should look at this in a broad fashion, and decide how we're going to handle the extra title information throughout the db. -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Aaron Cooper Sent: Sunday, June 18, 2006 4:47 AM To: MusicBrainz style discussion Subject: Re: [mb-style] (album version) mudcrow, if there is an original version of the song Lift then the point I was trying to make was that it should be called simply Lift and any other remixes or other versions should have the extra attributes appended. If the (LP version) is a different version from the original then cool, call it the (LP version). I disagree with your concluding remarks: Also I don't see that how a media player sorts files should have any impact on how we record data, we are meant to be building an accurate database of music, not creating user friendly playlists for mp3 players. One of MB's primary uses is for tagging music. If you don't believe me, read this: http://blog.musicbrainz.org/archives/2006/05/future_directio.html In response to Nikki: And removing (live) makes players think two completely different versions are the same. Does that not bother you? Players also can't distinguish between Some Title (an album) and Some Title (a single), but we don't change our style guidelines to change this so that people can tag their files easier because that info is stored in the release type. I am more than happy having live recordings of songs titled the same as the original recording. In fact, it works out great on Last.fm because the stats grow for a specific song whether I play a bootleg recording or the original. I don't care where the song comes from (whether it be an Album or a Single or a Compilation), I am arguing that *identical* songs should be *identically* titled. I think most people would agree with that dream. Even for artists who primarily release singles, I still think that all subsequent *identical* songs should be titled like the original. If that happens to be from a Single release, I don't think it makes a difference. What about when a live track features on an album and a live release? The album will have Some Track (live) but the live release will have Some Track. Those are the same track with two different names too! This is unfortunate, but there isn't much we can do to differentiate the live tracks from the rest of the studio recordings. Anyways, that's all I've got for now... Regards, -Aaron On 6/18/06, mud crow [EMAIL PROTECTED] wrote: I agree totally with removing the album version rule. To answer a few points raised. Identical tracks should always (in theory) all be identically titled, but in reality this will never happen. A live track will have (live) added to the title if its released as a track on a studio recorded release, the same with a demo track. Now I would expect a track that appears on an album to be the album version, and I would expect the same track appearing on a single to be the single version (unless otherwise titled). But if a track appears on a release and is titled track (album version) then it should be titled as such no matter what it is released on. Albums are NOT the primary release of every artist, there are a lot of dance/techno artists in MB who have never released an album, yet have a huge discography listed, so suggesting that an album version is the original/primary version is incorrect. And the single version is not always an edited version of the album version. Using the single Lift by 808 State as an example This single has been released in multiple versions and include the following versions of the track Lift: Lift Lift (7 mix) Lift (12 mix) Lift (Justin Strauss remix) Lift (Metro mix) Lift (Lift Up dub) Lift (7 version) Lift (Heavy mix) Lift (LP version) Now if we start removing (LP version) from the last track listed, how are supposed to differenciate between the original Lift and the LP version? Removing version info from any of these tracks could lead to the wrong PUID be attached to the wrong version, making PUID identification worthless. Also I don't see that how a media player sorts files should have any impact on how we record data, we are meant to be building an accurate database of music, not creating user friendly playlists for mp3 players. Mudcrow ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org
Re: [mb-style] (album version)
On Sun, Jun 18, 2006 at 06:46:47AM -0400, Aaron Cooper wrote: I am more than happy having live recordings of songs titled the same as the original recording. In fact, it works out great on Last.fm because the stats grow for a specific song whether I play a bootleg recording or the original. [...] This is unfortunate, but there isn't much we can do to differentiate the live tracks from the rest of the studio recordings. Where's the consistency in this approach? You want identical tracks to have identical names, except for when it benefits you? Why, other than your Last.fm stats, should Some Title and Some Title (album version) not be allowed when Some Title and Some Title (live) are, when in both cases both tracks are identical? --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] (album version)
On Sun, Jun 18, 2006 at 05:30:02AM -0400, Aaron Cooper wrote: I really don't want *identical* tracks to have different Titles. If the track was *originally* released on an album then the *identical* song on a Single release should have an *identical* title to the original Album release. Adding (album version) makes these songs completely different (when comparing titles, which is what most players Last.fm do). And removing (live) makes players think two completely different versions are the same. Does that not bother you? Players also can't distinguish between Some Title (an album) and Some Title (a single), but we don't change our style guidelines to change this so that people can tag their files easier because that info is stored in the release type. What about when a live track features on an album and a live release? The album will have Some Track (live) but the live release will have Some Track. Those are the same track with two different names too! And I think this is yet another example of a bad guideline that should be dropped since the release type isn't tagged. Cristov (wolfsong) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
RE: [mb-style] (album version)
It also means putting (live) onto live albums. Do you support adding that to every single track of a live album for consistency? No but if it's listed that way it should not be removed. By the way, we do have the http://wiki.musicbrainz.org/SameTrackRelationshipType to clarify the identical tracks. See, we can link identical tracks together, so we don't need the name to be the same as we can already store the fact they're identical. This argument is used in other places, so why can't it apply here? It just seems to be a load of whining about My tags! They're not the same! which applies to other things too but those aren't changed to make tagging easier because we simply state MusicBrainz isn't just for tagging. This is dangerous logic. While MB may not be just for tagging, people contribute to MB primarily for tagging purposes. Cristov (wolfsong) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Sun, Jun 18, 2006 at 08:15:16AM -0500, Cristov Russell wrote: This is dangerous logic. While MB may not be just for tagging, people contribute to MB primarily for tagging purposes. I'll agree there, the data should still be useful for tagging. I'm just pointing out that titles don't have to have the same title for us to be able to say that they're the same. When it comes to tagging for this particular issue, it goes both ways. Neither way is better from a tagging perspective, it's just too subjective. Some people will prefer all titles to match, others will prefer to see what's on the cover. We have plenty of cases where we simply don't have the flexibility in Picard for everyone to be satisfied, so it's not a very good argument. --Nikki ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
cases where we simply don't have the flexibility in Picard for everyone to be satisfied, so it's not a very good argument. i agree completly with nikkis suggestion, and the PRO arguments to this change. i'd just like to add to this discussion, that although it might be nice to have some field or whatever solution, we should try to solve such soft issues using the means we have available right now. since the information being lost triggered this dicussion, we should stick to how this could be solved using a style change. this is not a case which _needs_ development work, this is a soft change of culture and should be handled like that. --keschte ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
You sure won't get a veto from me! Please go ahead... azertus Nikki schreef: This keeps coming up and I hate it. ExtraTitleInformationStyle says If the release is a single, of course one of the tracks is going to be the album version. I think this is completely wrong. A single does not necessarily have to include an album version and to me, the 'default' version on a single is the *single* version, given that it's, well, a single. Also, an album also does not necessarily have to include all songs from a single, so there may not even *be* an album version in existence. A single also need not include a single version, and if it does, it doesn't necessarily have to be labelled as such. By removing '(album version)', we're making it completely ambiguous. Is it an unlabelled single version? Is it an album version? Is it a mistakenly unlabelled remix, edit or live version? We're also being inconsistent, LiveTrackStyle says tracks should not contain (live) as the release status is live. Surely, by this logic, we should not remove (album version) from singles and remove (single version) instead. I personally don't like removing any of the version information from singles, they can and do contain so many different versions (single, album, live, radio edit, etc.) that you can't really say any particular version is the default. So why should album version be assumed to be the default version for singles and not live albums? --Nikki P.S. Won't we have to go back and add (album version) back to all the singles once we have NGS? ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On 6/18/06, Schika [EMAIL PROTECTED] wrote: In my very first reply I had a single in my hands I got as promo - it sounds really shit and I wouldn't buy an album from this artist if they would make one. However, here's the track list again: 1. Title (XY remix) 2. Title (original mix) 3. Title (album mix) 4. Title 5. Title (AV radio edit) All versions have different track durations and sounds different, but the essential question is: what is the original version? track 2, 3 or 4 ? If I would get the album to compare each version, and find out that track 3 is exactly the same as on this single, then should I strip track 3 title to Title. But now what's the title of track 4 and who decides how this unlabeld other version should be named? Not to mention the confusion if track 2 would be on the artist album. I don't claim to know what to do for *every* specific case, but I'm sure someone who knows the artist well can propose a reasonable solution. Like I said earlier, I'd say go ahead and leave (album mix/version) if it causes trouble, but in clear cut cases where the single has a tracklist like: 1. X (album version) 2. X (remix) 3. Y 4. Z ... and X was originally released as a professional, commercially available recording then the (album version) should be dropped to show this relationship plainly. Regards, -- -Aaron ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
On Sun, 18 Jun 2006 12:46:47 +0200, Aaron Cooper wrote: I am arguing that *identical* songs should be *identically* titled. I think most people would agree with that dream. No, I don't and I soppose that there is a considerable amount of people here who disagree. Actually I think this is the core problem of the debate. There are some people here who think that the track title should be the same for all versions of a song (ObjectModel/MasterObject to be very precise), I'll call this the absolutistic point of view (and I don't mean kings and queens here :-) ). Then there are other people who think that the track tilte should be what makes most sense in the context of the release it appears on (here the track title refers to the ObjectModel/TrackObect). I'll call this the contextualistic point of view. On the MusicBrainzSummit7 we established that in the future these two points of view should be both in the database, as aspects with equal rights, and separated structurally. However, we have to live with the current structure for quite a while. The current structure is not able to deal with this distinction in a useful way. Now, I am very obviously a member of the contextualistic camp (in any aspect not only tagging: intertwingling, remember? :-) ). However, I think that the people who want an absolute name should have a way to retrieve this from the database. I have argued in the past that we cannot stop storing extra title information in track titles and move them into ARs unless there are tools to process this information (context again: the information storage needs processors). One of these tools will be picard 0.8 another one will be ArtistPageRedesign. Now these have a considerable advantage over the so called NextGenerationSchema: They are worked on by Lukas and Keschte who have the resources to fully focus on these features, as opposed to Robert who has to jump in and put out fires all the time. I assume that both projects should see the light of the day this year. It is _then_ that IMO we should try to move as much as possible to the contextualistic model of describing data _in the TrackTitles_, and as much as possible to the absolutistic model _in ARs_. To be concrete: If people are able to retrieve this informtation for tagging purposes, and if ARs are displayed in a more practical way, THEN, there will be no need anymore to give the same track title to all versions of the same song, because people can just follow some ARs that point them to the track with the 'original title'. Whatever the 'original title' is and how the ARs work, will have to be worked out. In conclusion I propose to postpone this debate until Picard 0.8 comes out. I then propose not to lead a debate about principles, but a debate about concete solutions to this and the related problems using contextual track titles (that say (album version) if it makes sense _in context_), ARs (taht point to the same track with the most 'context free' title), and Picard 0.8s tagger script that retrieves all this info and uses it for tagging. DonRedman -- Words that are written in CamelCase refer to WikiPages: Visit http://wiki.musicbrainz.org/ the best MusicBrainz documentation around! :-) ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] (album version)
Citerar Aaron Cooper [EMAIL PROTECTED]: I think it is easily assumed that any track on a Single release without any special attributes (live)/(acoustic)/(demo)/(remix)/(edit) is a song which has been previously recorded or is not live/acoustic/a demo/remixed/edited version of the orginal. I think this is obvious because Albums are the primary releases of ~99% of artists and a Single usually highlights a specific song from an existing album. I'd say about 50% of the singles (of album releasing artists) comes out before the album, and the rest 50% after the album has been released. I just think the original release is the most important, so its seems ridiculous to have an identical song released on a single and have it titled with (album version). Just think about a Single that has 3 or 4 songs from an existing album - which is not overly rare. We will have a single with titles: St. Anger (edit), St. Anger (album version), The Unnamed Feeling (album version), Some Kind of Monster (album version), Frantic (album version), St. Anger (live). Wouldn't that seem crazy? I never saw such a single, did you? But anuhoo, if those are the titles that are put on the release, then I can see no reason to not let them in to out database. We're aiming for correctness, no? But if they're not there (and even if they happen to be the same tracks as are also on an album), then noone's suggesting to make up a version-name and put it there. Just go with the way the tracks are named on the particular release. //[bnw] ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
