Re: [mb-style] Re: RFV: OGLA is no more, suggesting the AR be deactivated, if not removed

Sorry for my late reply on this, but the OLGA website currently states they are trying to get back online. What if they succeed? -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org

Re: [mb-style] Re-recorded releases

to do. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] is the same track as?

to each other, BTW: I'm not strictly against link clusters as avoiding them sometimes hides information. But in this case it is surely better to not link all identical songs to each other. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz

Re: [mb-style] Re: AR implicit/explicit propagation: to

be easily merged. If somebody decides not to add ARs because they are already present in the eraliest release that's ok for me. But I would neither disallow nor remove ARs from later releases. -- Philipp Wolfer ___ Musicbrainz-style mailing list

Re: [mb-style] Re: AR implicit/explicit propagation: to

will bring us any further and is a step back. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Re: AR implicit/explicit propagation: to

same ARs on previously different tracks will be merged. I think that's what Brian Schweitzer meant with go away eventually -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman

Re: [mb-style] Re: AR implicit/explicit propagation: to

, as that is no longer relevent). I didn't mean they need to be copied along the chain. It's enough to have them available for all child objects. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http

Re: [mb-style] Re: AR implicit/explicit propagation: to

On Dec 3, 2007 4:19 PM, Olivier [EMAIL PROTECTED] wrote: So that third way means I'm left with a half-done job, half-backed releases, no data consistency - which will probably disastisfy everybody (specially me :-)). Why no data consistency? I don't understand how identical ARs on two

Re: [mb-style] Re: AR implicit/explicit propagation: to

. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Re: AR implicit/explicit propagation: to

On Dec 3, 2007 10:16 PM, Olivier [EMAIL PROTECTED] wrote: Here! There! Read! BF mate, your abusive voting won't pass! :D I'm gonna redo these edits ASAP :D /was just teasing For those who were not aware of the parallel discussion in the edit notes (like me) here the pointer to the edit:

Re: [mb-style] Re: AR implicit/explicit propagation: to

of the album, how would I achieve that with your solution? As I said earlier: It's a technical problem and we need a technical solution for it, not some temporary guideline that avoids some problems and introduces some new. -- Philipp Wolfer ___ Musicbrainz-style

Re: [mb-style] Composition/Performer/Production ARs at Release or Track level? - PROPOSAL

there is value in allowing the fuzzy ARs on release level and that viewpoint 2 is the way to go. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Composition/Performer/Production ARs at Release or Track level? - PROPOSAL

notes, in a structured way. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] [no label]

label] is entered somebody already looked researched the release, but whenever the label is clear we have indeed missing information. On the other side a label [unknown] could give an overview over releases that need label research. -- Philipp Wolfer

Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12

mentioned to do that and to specify the ARs that are only valid on release or on track level. Overall I believe this system will give us less fuzziness and better structured information on release and track level. -- Philipp Wolfer ___ Musicbrainz

Re: [mb-style] Re: Musicbrainz-style Digest, Vol 33, Issue 12

at the lowest level that is practical. I completely agree on that :) -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] [no label]

not going to get rid of it, we should at least steer it a little. I didn't realize there was already an [unknown] label. Given that it already exists I agree that we should keep it. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz

Re: [mb-style] 2 releases packaged together

where the releases are available separately and cases where they are not. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: Clarifications and more docs about labels [Was [mb-style] RFC: Changed name to for labels]

On Feb 9, 2008 1:39 PM, Olivier [EMAIL PROTECTED] wrote: Following the somewhat confused/confusing previous RFC, I finally assembled a HowTo about labels. http://wiki.musicbrainz.org/HowToIdentifyLabels Great work, thanks. This will help alot, not only for MB newbies :) -- Philipp Wolfer

Re: [mb-style] RFC: What defines a unique release, attempted clarification

a release. Especially if there are ARs that are only valid for one version of the release it might be necessary. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo

Re: [mb-style] RFC: New release-url AR (or AR modification), Has c.c. artwork at

. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] RFC: New release-url AR (or AR modification), Has c.c. artwork at

be a list to choose from. I does not have to be complete, it can later be expanded, but it should include the most common licenses. I'll see to make a reasonable list, but not this week. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz

Re: [mb-style] Names - as many as possible?

for this is http://musicbrainz.org/artist/2c449bbd-b19e-456b-af78-f2e592ff2245.html -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Names - as many as possible?

for it. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] L-t-E-P-W-L-V-P-f-a-R

encounter edits for other languages I explain the above point of view. Most editors will agree and cancel their edit. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo

Re: [mb-style] multi-disc releases / box sets.

a solution, but with a proper technical solution it becomes possible to find and group discs that belong together automatically. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman

Re: [mb-style] MultipleTitleStyle not to be used to actually separate titles?

) Funeral but rather should be (Miyagi's Father Dies)/(Father's Funeral). So yes, I think it should be separated bei / just as MultipleTitleStyle suggests. -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http

Re: [mb-style] MultipleTitleStyle not to be used to actually separate titles?

On Fri, Aug 22, 2008 at 10:27 AM, Kuno Woudt [EMAIL PROTECTED] wrote: On Fri, Aug 22, 2008 at 09:38:06AM +0200, Philipp Wolfer wrote: On Fri, Aug 22, 2008 at 8:27 AM, Philip Jägenstedt [EMAIL PROTECTED] wrote: I think we should follow the formatting that the artist has chosen. Some

Re: [mb-style] Removal of homeburnt discIds

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

Re: [mb-style] Removal of homeburnt discIds

gaps are an indication but not a proof. Cheers, Philipp -- Philipp Wolfer ___ Musicbrainz-style mailing list Musicbrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style

Re: [mb-style] Removal of homeburnt discIds

returned several candidates Exactly. But remember that disc IDs are not only for Picard, indeed they are not only for tagging software. A lot of CD rippers and audio players use the MB disc IDs to identify a disc. -- Philipp Wolfer ___ Musicbrainz-style

Re: [mb-style] RFC: Modify edit conditions for destructive edits

On Tue, Dec 1, 2009 at 5:54 PM, Brian Schweitzer brian.brianschweit...@gmail.com wrote: It's my opinion that any destructive edit should have at least some review - additive or modifying edits can always be fixed if bad ones expire in, but destructive edits mean the entire entity has to be

Re: [mb-style] Post NGS Style Guidelines, Titles

do you have an example od what you mean with non-standard meaning. I neither think we used standard puntuation for non-standard meaning, nor do i think we should use non-standard punctuation. Phil 7. Dez 2009 9:34 nachm. schrieb am Frederic Da Vitoria davito...@gmail.com: 2009/12/7 Kuno Woudt

Re: [mb-style] Preferred lyrics for Has Lyrics At Relationship Type (community editable vs. Gracenote)

On Tue, Mar 2, 2010 at 6:50 PM, Jeroen van den Brink jer...@v-d-brink.eu wrote: I'd personally say the community editable one, but I would like your input on this. Maybe the MB wiki page [3] should be expanded with this info? I prefer the community version. In my opinion it fits better to what

Re: [mb-style] Preferred lyrics for Has Lyrics At Relationship Type (community editable vs. Gracenote)

On Wed, Mar 3, 2010 at 12:43 PM, Frederic Da Vitoria davito...@gmail.com wrote: What do you think should we do in cases where only an official version exists? Should we link to it, or create a user-editable one, populate it with the official version, and link to that? I'm not sure that having

Re: [mb-style] Preferred lyrics for Has Lyrics At Relationship Type (community editable vs. Gracenote)

On Thu, Mar 4, 2010 at 11:08 AM, Frederic Da Vitoria davito...@gmail.com wrote: I wasn't discussing preferring user-editable over official, I agree the first option would be statistically closer to the lyrics as they were actually sung. What surprised me was advising to copy copyrighted data,

Re: [mb-style] Preferred lyrics for Has Lyrics At Relationship Type (community editable vs. Gracenote)

On Thu, Mar 4, 2010 at 5:42 PM, Pavan Chander pchan...@gmail.com wrote: I poked around the LyricWiki site a bit, and it seems that they enforce their own version of a DRM ;) As part of their agreement with Gracenote, all official lyrics have the ability to copy the text disabled. This suggests

Re: [mb-style] NGS guidelines

On Tue, May 24, 2011 at 5:09 PM, Dr Andrew John Hughes gnu_and...@member.fsf.org wrote: Sorry, but a process taking time or being painful is not a reason to impose the views of a few people on everyone else. I don't think that the intent of the NGS guideline updates was to impose someone's view

Re: [mb-style] VolumeNumberStyle in NGS?

On Tue, Jun 7, 2011 at 10:53 AM, Frederic Da Vitoria davito...@gmail.com wrote: I don't understand you. IMO this would be quasi-redundancy, adding extra layers with little benefit. What kind of benefit did you expect from NGS? I'm also concerned about abandoning the title normalization. I can

Re: [mb-style] Cover relationship Recording-Recording

On Mon, Oct 3, 2011 at 10:38 PM, Lemire, Sebastien m...@benji99.ca wrote: Well because of pretty wide support for removing the Cover attribute and IMHO it shouldn't be implemented unless we can find a way to do it properly, I would also be in favor in removing it. If in the future through major

Re: [mb-style] How to enter hybrid SACD and DVD audio+video discs?

2014-11-27 10:50 GMT+01:00 MeinDummy meindu...@nurfuerspam.de: There is more like this. All ten of the earlier Depeche Mode albums were re-released in a similar format. Most of the corresponding MB releases have the SACD split into 2 tracklists/discs as I suggested but the DVDs are usually

Re: [mb-style] How to enter hybrid SACD and DVD audio+video discs?

2014-11-27 12:04 GMT+01:00 MeinDummy meindu...@nurfuerspam.de: Philipp Wolfer-2 wrote Why should this content, which is all part of a single DVD medium, be splitted on MB? Because it's more consistent with the way the SACD is represented. Does this imply that the exact same DVD should

Re: [mb-style] How to enter hybrid SACD and DVD audio+video discs?

2014-12-02 10:33 GMT+01:00 MeinDummy meindu...@nurfuerspam.de: Alex Mauer wrote Would it be reasonable to use the new 'data tracks' feature to add the non-CDDA tracks (e.g. the SACD-Hybrid and DVD side of a Dualdisc? Or do you think that is a misuse of that feature, and that it should

[mb-style] Usage of DualDisc / DVDplus formats

Hi, has there been some discussion on the usage of the DualDisc and DVDplus media formats (what's the difference between those two, anyway?). For me those formats don't really make much sense, since we don't have an entity to apply them to. Basically it's a format were two different media formats

Re: [mb-style] Usage of DualDisc / DVDplus formats

2014-12-04 10:37 GMT+01:00 MeinDummy meindu...@nurfuerspam.de: An alternative solution has been proposed here: http://tickets.musicbrainz.org/browse/STYLE-381 I'm in favour of that approach. Thanks for the link. I like that approach, too. I think that would satisfy all the needs.