Re: [mb-style] Removing stale URL relationships
That's a really good idea. dave ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Removal of homeburnt discIds
Couple of questions: Does the identification of (alleged) CD-R copies work in both directions? That is, if I put in a burnt CD, could my software (or the MB API) be smart enough to say "that doesn't match any CD-Indexes of official releases, but I'm 99% sure that it's a burnt copy of album X". If people agree (as I do) that burning an album to CD shouldn't be treated as some kind of crime in this era of the iTunes Store, Creative Commons, and internet distribution etc. then this is a valuable service to offer, and doing it pro grammatically makes more sense than trying to get one CD-Index from every burner in the world. If this CD-R identification method is fairly foolproof why isn't it being done by an automated script? I'm guessing the people deleting these are using a script to identify likely suspects to delete, what extra human thought is added to the process that couldn't be automated? And if we can automate this, why don't we just tag them as "suspected home burnt CD-R" (possibly even link them to the original they were copied from) and hide them from view instead of putting it up for votes. In the standard case what can the voters possibly contribute apart from confirming the +2 seconds algorithm has been applied correctly? Sounds like a job for a computer to me. cheers, dave 2008/11/24 Philipp Wolfer <[EMAIL PROTECTED]>: > Hi, > > reopening an older discussion: Edit #9534224 > (http://musicbrainz.org/show/edit/?editid=9534224) is a good example why it > might be bad to remove disc IDs that just look suspicious. > > Obviously there are valid disc IDs that have those 2 seconds extra in every > track which some people use to identify home burnt CDs. I'm in favor of > keeping the database clean, but please think twice before going through the > database removing every disc ID that might be home burnt. > > Cheers, > Philipp (OutsideContext) > > On Fri, May 9, 2008 at 2:42 PM, Bram van Dijk <[EMAIL PROTECTED]> > wrote: >> >> This one: >> http://wiki.musicbrainz.org/HowToAddDiscIDs >> (though you might say it is not a guideline) >> >> If I am not mistaken, burning the exact same mp3 or whatever will result >> in different discIDs dependent on the which burner one uses. Maybe even >> with which program? >> >> Thus, if we allow this, we will get hundreds of discIDs for some >> releases, and most of these will only be useful to someone who happens >> to burn their music in the exact same way on the same hardware as the >> one who originally added the discID. >> >> IMHO this is not useful, and we thus should not allow it as it does get >> in the way. With which I mean that as we are displaying the release >> events below the discIDs, having 100 or more of them on a release is not >> very nice. >> >> Bram / jongetje >> >> Lukáš Lalinský schreef: >> > Dňa Pi, 2008-05-09 o 21:07 +0800, Chad Wilson napísal: >> > >> >> BrianG has voted down an edit to remove a homeburnt disc ID at >> >> http://musicbrainz.org/show/edit/?editid=8668756 >> >> >> >> Since when has this practice changed, and is BrianG's position that the >> >> practice should change technically defensible? (of course AutoEditors >> >> voting against style guidelines isn't, in my opinion) >> >> >> > >> > Which style guideline are you referring to in this case? I'm not aware >> > of anything, and I personally dislike that removing these supposedly >> > homeburnt discids became an accepted practice. >> > >> > Lukas > > -- > Philipp Wolfer > > ___ > 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] RFC: Creating a non-code AR to grou p releases into “cultural identifiers” for fu ture importing.
On Fri, Oct 10, 2008 at 8:48 AM, Bram van Dijk <[EMAIL PROTECTED]> wrote: > I might be wrong, but if there is a box set, for example the pink floyd > "shine on" set, we do use "earliest release" or "remaster" ARs to link > them to the original albums. But, I don't think that they should be in > the same cultural identifier. I think they would be in both 'cultural identifiers' since a box set will need to be identified individually as well, but a single or an album doesn't become something else just by being packaged together with other things. regards, dave ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC: Creating a non-code AR to grou p releases into “cultural identifiers” for fu ture importing.
I think this is a good idea, but also mostly agree with this: On Thu, Oct 9, 2008 at 8:11 PM, Jan van Thiel <[EMAIL PROTECTED]> wrote: > Why is this needed at all? 'Earliest release of' and 'Remaster of' ARs > can be taken advantage of right now if you write some software. This > new AR will be attached to exactly the same releases as these two ARs. There's mutiple things that make two MB 'releases' part of a 'release group' or 'cultural identifier' e.g. * multi-disc albums * multi-part singles and/or remixes * multiple formats (CD, LP, CASS, DAT) * bonus discs * simultaneous releases (possibly limited edition or different countries) * later remasters * later re-releases Currently most of these are collapsed in MB if the tracks lists are the same, but there needs to be a bit of extra info, in the form of ARs, to correctly collapse the rest. I think it would be better to be more specific about the connections, and then use that info to collapse them, because that info is also useful on it's own. What would be handy, and wouldn't require too much skill would be for someone to create a view into the data that collapses all these links, so that it's obvious where they are missing. I mean compare the BBC site for Portishead, where they are doing this (by a fairly simple textual comparison I guess) with Musicbrainz's version of the same info: http://www.bbc.co.uk/music/artists/8f6bd1e4-fbe1-4f50-aa9b-94c450ec0f11/releases http://musicbrainz.org/artist/8f6bd1e4-fbe1-4f50-aa9b-94c450ec0f11.html regards, dave ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Wikipedia AR using urls with hash
I'm not sure how this would be communicated to less sophisticated Musicbrainz/Wikipedia users but the following is possible: http://en.wikipedia.org/wiki/In_The_City_%2B_In_The_Woods has just been created by me, and consists only of a redirect to: http://en.wikipedia.org/wiki/Tracy_Bonham#In_The_City_.2B_In_The_Woods (Actually it keeps the original link title on redirect, so it's http://en.wikipedia.org/wiki/#In_The_City_%2B_In_The_Woods#In_The_City_.2B_In_The_Woods but that's a minor detail) There's a live example (which is now broken) given in the Wikipedia docs here: http://en.wikipedia.org/wiki/Wikipedia:How_to_edit_a_page (search for "redirect") This means that the new, anchorless link works the exact same as the current anchored link does now, but as soon as someone thinks that album deserves it's own page, the link points to something else. regards, dave On Sun, Mar 9, 2008 at 3:11 PM, Paul C. Bryan <[EMAIL PROTECTED]> wrote: > The consensus seems this far that we should not link to anchors within > pages. > > To best understand this, I guess my only question I have is, what > balance are we trying to strike between preventing link rot and > providing useful information? > > As I mentioned in the edit that started this, sometimes a topic in > Wikipedia is not considered non-trivial enough to warrant its own page, > with attempts to create a separate topic resulting in a deletion. > > I was on the fence on this one, and don't really feel strongly one way > or the other. Whatever information you can provide though to help > editors make better decisions in the future will help. > > Paul > > > > On Sun, 2008-03-09 at 11:20 +0100, Philip Jägenstedt wrote: > > This disussion is pretty lame and I think we all agree anyway: we > > don't want to link albums to wikipedia:Artist#Album. If it doesn't > > have a Wikipedia page of its own just don't link it (add an annotation > > if you must). Unless someone is actually of the opinion that we should > > there's no need to discuss the details of document fragments or > > permalinks. > > > > We do get carried away on this list... > > > > Philip > > > > On 3/9/08, Brian Schweitzer <[EMAIL PROTECTED]> wrote: > > > On Sun, Mar 9, 2008 at 3:57 AM, Bogdan Butnaru <[EMAIL PROTECTED]> wrote: > > > > On Sun, Mar 9, 2008 at 4:11 AM, Brian Schweitzer > > > > <[EMAIL PROTECTED]> wrote: > > > > > I'm very aware what fragments are, and how they work, though I > wasn't > > > > > aware that the CGI-parser behind Wikipedia's permalink system > > > > > maintained fragment support. > > > > > > > > I'm not sure you do understand it completely. Wikipedia's CGI doesn't > > > > need to understand fragments, in fact it doesn't receive it normally. > > > > When a browser wants something like > > > > "http://some.uri/some/resource#fragment";, it sends the server just > the > > > > address "http://some.uri/some/resource";, without the "#fragment" > part, > > > > it receives the complete page, and then the browser scrolls down to > > > > the specified fragment (or a similar operation). > > > > > > > > > I'm not quite sure why this thread keeps harking back to my personal > > > understanding of page fragments, rather than the actual topic, but > > > that assumes the anchors the browser is looking for are maintained > > > within the page being returned by the server (it would be quite > > > possible, for example, that fragment identifiers within archived > > > documents be minified and renamed to save on storage space - as I have > > > seen archive.org do on several occasions, though I've never had cause > > > to check whether Wikipedia did it). > > > > > > In any case, if I can again try to reference back to the original > > > question here: Should a url for Wikipedia (or indeed, any url AR) be > > > permitted if it is using anchors? > > > > > > As I see it, it raises two questions: > > > 1) Should we be linking to pages or to text within pages? ie: Should > > > we be linking if the entire page doesn't concern the > > > release/artist/whatever? > > > 2) If we are to decide to link to text within pages, how should that > > > link then be done? Say what you will, but a link to a fragment > > > identifier within a live page seems to me a bad idea, as it is quite > > > easy that the linked fragment identifier be removed, even if the page > > > it is a part of still exists - say an album being originally a subpart > > > of an artist page, then later being moved to its own page. > > > > > > It's worth considering Tim Berners-Lee's suggestions on such links > > > (http://www.w3.org/DesignIssues/Fragment.html ): > > > * A bookmark to the whole living document, or > > > * A bookmark to a specific part of a "dead" version; > > > * Intermediate combinations (I'm not really sure quite what he saw > > > this as actually being) > > > > > > If the link pertained to the
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] SG5...again (*ducks*)
On 5/25/06, Nikki <[EMAIL PROTECTED]> wrote:
I think, really, that both of you are right. There's no way to draw a
definite line between A & B and A feat. B and from the evidence given, I'd
say this one falls in the grey area between the two.
It's not the existance of a grey area that's the problem. It's the
fact that if you fall on one side of an arbitrarily drawn line within
this grey area then you're a 'collaboration' and if you fall on the
other you're a 'feat.' and that depending on what side of the line you
fall on, the database stores the information in totally different
ways. I'd suggest moving the line far to one side in the interests of
consistency.
One basic fact is key to this and hopefully everyone can agree once
it's been pointed out:
* there is no basis or rationale for continuing to normalise track
titles to include (feat. X)
Go dig out your albums and you'll find that very few actually use that
format. They might say 'with' or 'duet with' or 'vocals by' or 'ft.'
You'll notice as well that as many times the feat or whatever appears
attached to the artist as it does to the song (particularly on VA
compilations and singles).
The only valid reason to do this was to allow a script to extract this
information at a later date and store it in the database. This has
already happened. I believe that script has actually been written and
run. We now have ARs, which not only allow you to store such info, it
lets you do so with incredibly fine grained detail. (An unvalid reason
might be to make your record collection titles 'neater')
We also have the changes brought in as a response to SG5 which allow
"X feat. Y" (or "X vs. Y" or "X meets the Ys uptown" or anything else)
to be the artist on the single, VA compilations or soundtracks as well
as the greatest hits albums of *both* collaborating artists without
the side effect of changing the single artist albums to be a VA album.
This also means track entries by crazy one-hit wonder dance artists
called "X feat. Y" no longer need to be mutilated to fit in with a now
redundant rule, that actually tried to solve a different problem in
the first place.
All the above means we have enough information stored in the database
now to take "track title" by "X vs. Y" appearing on X's greatest hits
album and transform it, at time of tagging, to "track title (feat. Y)"
by "X". Or even "track title (feat. A, B and C)". Not only that you
could use "ft." or anything else the user wanted to specify. Anyone
who wants their albums tagged like that can have it, it's just a
simple matter of programming.
So I would suggest alway putting the info in the artist field unless
it is incredibly minor ("trumpet solo by X", "featuring the St. Paul's
Choir") in which case just leave it as it is written on the cover and
mark it with an appropriate AR.
With reference to Aretha and Eurythmics, if it is really felt that the
contribution of Aretha to this song is not enough for her to be
awarded the full MusicBrainz ampersand then "Eurythmics with Aretha
Franklin" seems just as good a name for a collaboration to me.
This will of course lead to the creation of many of the dreaded "bogus
artists", the prevention of which sometimes seems like our prime
directive, the 0th Law of MusicBrainz. Seems worth it to have useful,
consistent and correct data, to me at least.
cheers,
dave
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Soundtracks
On 5/11/06, mud crow <[EMAIL PROTECTED]> wrote:
I much prefer having the composer as the artist. IMO it's much better to
credit the person who wrote it as the main artist then the person who
provided lead vocal.
I'm guessing from this paragraph that there's disagreement about what
the 'artist' represents. I've always taken it to mean 'performer' and
the above paragraph makes no sense at all if you replace the word
'artist' with 'performer'.
The problems I see with crediting the vocalist(s) as the artist is that we
are going to have 100's if not 1000's of bogus artists created.
As it is, we have loads of soundtrack tracks credited to chorus, or artist &
chorus, or even worse artist a, artist b, artist c, artist d etc and chorus.
Again, from my perspective ('artist' = 'performer') this is backwards.
How can a textual representation of the actual performers (even if
it's more than one person or 'group' acting in combination) be any
more 'bogus' than the name of someone who didn't perform at all.
But again if the 'artist' field is actually a semi-randomly selected
contributer who is arbitrarily judged more important than all the rest
then a) my above point doesn't stand, b) this is a recipe for endless
arguments, c) the info in 'artist' can't really be used for anything
really interesting, since the actual role of the connected person
isn't recorded in a machine readable way d) all the 'artist' info in
standard rock/pop/reggae etc. needs to be duplicated into 'performed'
ARs
cheers,
dave
___
Musicbrainz-style mailing list
Musicbrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: What Gets Tagged Under SG5? (WAS: [mb-style] RE: AlbumTitle proposal)
On 1/16/06, Schika <[EMAIL PROTECTED]> wrote: > All that "V/A" albums are showing "track title" - "artist" on the Amazon > pages. Maybe I understand you wrong, but do you want to have the albums > taged like this way: > TPE1 (lead performer) - frame: "Aphex Twin", TIT2 (song title) - frame: > Aphex Twin - Windowlicker (Acid edit)", TALB (album title) - frame: "26 > Mixes For Cash (disc 2)" > > O_o > > Please follow up with that example, how it should be in your opinion. Exactly like that, except you happened to choose an Aphex Twin track whereas most of the tracks on that Aphex Twin compilation are actually by other bands/aliases rather than both the track and mix being by the same person. So where there is duplication I don't see any point having the same info in TPE1 and TIT2. But yes, so in that format: TPE1: David Holmes TIT2: Ain't That A Kick In The Head - Dean Martin (where the track title & artist could be reversed and with customisable seperator) TALB: Out of Sight It's not something that *I* personally would use a lot, I actually care that that song is by Dean Martin and that it shows up with the rest of my Dean Martin stuff, but it appears quite popular with other people for soundtracks that are primarily scores with the occasional pop tune thrown in. And (though I'm no expert) I believe the same is true of fans of DJs like Pete Tong where they're buying the album for the DJ rather than the individual tracks and it flows like a concept album rather than simply being a collection of tracks that could be listened to in a random order without losing anything. In that vein, one album that I personally would use this format for would be 2 Many DJ's As Heard on Radio Soulwax pt 2: http://musicbrainz.org/album/0447d18c-844d-4570-b1fd-926cbb37c10f.html cheers, dave ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: What Gets Tagged Under SG5? (WAS: [mb-style] RE: AlbumTitle proposal)
On 1/16/06, Steve Wyles <[EMAIL PROTECTED]> wrote: > On Mon, 16 Jan 2006, david scotson wrote: > > If Picard (or a third party app) could work within the limitations of > > current apps support for id3 and replace the track artist with the > > album artist and modify the track title so that artists other than the > > album artist appear in the track title then that would suit quite a > > lot of people, particularly for soundtracks and DJ mixes e.g.: > > > Which is effectively going back to the situation before SGDR was > implimented. To me the album artist indicates where the album would be > found in a record store or in a filesystem layout. I should have been more clear, but as someone else has already noted, this w/c/should be optional and user controlled on an album by album basis. So it would be effectively going back to the previous situation in many cases, but only if you prefer that system for that particular album. And of course it would allow the artist-in-track-name approach previously seen in "Barcelona (Freddie Mercury and Monserrat Cabal) by Queen" for even more albums like, for instance, the pete tong one's that are generally VA'd in MB. Crucially, whatever way you do it, it wouldn't affect the file system layout or where the CD would be located in a shop metaphor, it's just your music player would treat that Freddie Mercury track like a Queen track with a weird long title. Not that your music player cares, and any human being reading the title would be able to figure out what's going on. Of course if you did want a computer to understand who's actually performing e.g. for last.fm then the Musicbrainz ID can be tied back to the actual performer rather than relying on the id3 tags that Picard will soon (or so I've read) allow you much greater flexibility over what info goes into which tag. (And hopefully that includes AR info like remixer, composer, lyricist etc.) cheers, dave ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: What Gets Tagged Under SG5? (WAS: [mb-style] RE: AlbumTitle proposal)
On 1/16/06, Rod Begbie <[EMAIL PROTECTED]> wrote: > On 1/16/06, Chris Bransden <[EMAIL PROTECTED]> wrote: > > tis ok :) i just am trying to work out what album artist means in the > > context of a tag. > > Right now, with the current limitations of ID3 tags, it's not terribly useful. If Picard (or a third party app) could work within the limitations of current apps support for id3 and replace the track artist with the album artist and modify the track title so that artists other than the album artist appear in the track title then that would suit quite a lot of people, particularly for soundtracks and DJ mixes e.g.: Out of Sight movie soundtrack by David Holmes: http://www.amazon.com/gp/product/B07QEB 26 mixes for Cash by Aphex Twin: http://www.amazon.com/gp/product/B88EGP Essential Mix by Pete Tong: http://www.amazon.com/gp/product/B5A0ID There's quite a few people with albums tagged in this manner (i.e. some artists in the trackname) out there, and they seem quite happy with it. It would be cool if MB could both identify these as the VA albums with album artists when people are tagging and allow albums to be written out this way. cheers, dave ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
