Re: [mb-style] Pre RFC for release RG titles
Alex Mauer wrote On 2/2/2012 8:43 PM, pabouk wrote: Though I like how the ACs look I see the impossibility to use regexp to separate composers and performers as a big disadvantage. I certainly would like to store composer ACs into one tag and performer ACs into a different tag. Isn't that why we have ARs? Yes, we have the ARs capability but in fact only a small part of releases have usable ARs. I doubt that this would considerably change in the future. Also as I wrote the queries to determine if an artist from ACs is a composer or performer are very complex (querying all ARs of the release recordings and works). We already want to separate composers and performers in ACs so why should not we separate them properly (unambiguously) in the future? - Václav Brožík / pabouk -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Pre-RFC-for-release-RG-titles-tp4336795p4353997.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] Genre support
On 13/12/2011 06:55, Lukáš Lalinský wrote:
What I want is to define what kind of genres are there, how are they
related and what tags people usually use to represent them. With this
information you can say that the tags hip hop, hiphop, rap, usa are
in fact mentioning only one genre - Hip-Hop. You can also say
from tags psytrance and psy-trance that both represent a genre
called Psychadelic Trance, which has its origins in Trance, which is a
style of Electronic music.
More generally, what you would like to have is
1) a way to define tag synonyms, maybe with a representative of that
group of synonyms,
2) a way to relate tags with other tags.
The first thing would be very helpful for for grouping misspellings and
translations of tags (for example cantautore, cantautori,
cantautoriale, singer-songwriter, singersongwriters should all
belong the the same group). As long as you can have one representative
for locale, it is a very welcome feature.
The second feature (relate tags to each other) is going to be quite
complex. Take jazz fusion: basically it is jazz + {contemporary
symphonic, groove, rock, blues}. I think it will be hard to fit these
relations in a tree or lattice. You may end up with a graph of
related-to relationships with loops. It would be interesting
nonetheless, but not really useful for practical purposes. And good luck
finding parents and children of pop or classical: is Stockhausen's music
derived from classical or electronic? What about Einaudi's music? Is it
classical, minimalist or elevator music?
Anyway, just having a way to group tag synonyms (not just genres) would
be nice and useful and probably a first step toward something.
Bye,
--
Gioele Barabucci gio...@svario.it
___
MusicBrainz-style mailing list
MusicBrainz-style@lists.musicbrainz.org
http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre RFC for release RG titles
On 02/03/2012 02:25 AM, pabouk wrote: On 2/2/2012 8:43 PM, pabouk wrote: Though I like how the ACs look I see the impossibility to use regexp to separate composers and performers as a big disadvantage. I certainly would like to store composer ACs into one tag and performer ACs into a different tag. Isn't that why we have ARs? Yes, we have the ARs capability but in fact only a small part of releases have usable ARs. I doubt that this would considerably change in the future. And why would it be any different with these special-composer-ACs you’re proposing? If people aren’t adding ARs because it’s too hard, then we need to make it easier, not harder by adding an additional field. Also as I wrote the queries to determine if an artist from ACs is a composer or performer are very complex (querying all ARs of the release recordings and works). Then we need to make that easier too. Computer time is easier to get than editor time. —Alex Mauer “hawke” ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Bandcamp label?
Hello, On 02/02/12 05:58, MeinDummy wrote: Of course all these sources do not provide exactly the same audio but this does not mean that they cannot be the same release. We are not even sure if we want to keep original and remastered tracks separate. So why should we differentiate between encodings? It's not just about the encoding of the audio. The original metadata in the files is likely to be formatted differently and include other data (e.g. embedded cover art). They may include different cover image files or digital booklet files. Obviously they are different if one of the releases contains audio or video files which the other doesn't. Even releases from the same retailer can be different in this respect. For example the original mp3 release of Quaristice by Autechre included a different cover image embedded in each .mp3 file -- whereas the .flac release did not come with the individual track cover art. I have both copies on my harddisk because they are different to me. As of now, MB only offers the format Digital Media without further branching off into codecs and their parameters so except for the release event all those MP3 releases are the same with respect to their MB data. Even the PUIDs and AcoustIDs are the same. Obviously the AcoustIDs are the same. In general for a group of releases in a release group I expect most of them to share recordings and fingerprints. Some may have bonus tracks, but that is not the only reason to distinguish particular versions of an album from other versions. If Digital Media releases from different sources were kept separate then the owner of some MP3s might not even be able to correctly identify his release unless the source is mentioned in some ID3 tag field or he remembers where exactly he bought or downloaded every item of his music collection. ok Which is exactly why I want the help from musicbrainz to keep track of these different versions in those situations where I have multiple versions in my music library :) And with the different audio argument you would also have to create separate releases for Jamendo MP3 and Ogg Vorbis or for the different encodings that you can choose when downloading from Bandcamp or archive.org. Except for rare cases (like the Quaristice example) I would consider these to be the same release, available in multiple formats. I would like to keep track of these formats in MusicBrainz, but that is a separate issue. Considering this, I will also accept that a release available on both iTunes and Amazon is the same release if it was released on the same day and has exactly the same files included (if the iTunes release has a digital booklet .pdf and amazon does not -- they are different releases, etc..). This is very difficult to determine without purchasing both however, so I would still be inclined to enter them separately unless I have proof that they are the same. I don't see why we shouldn't stick to the simple Digital Media format to cover all encodings. And as I said before I even think we should combine MP3 releases from different sources into one MB release to prevent the database from being cluttered up with identical copies of the same data. If I have reason to keep multiple copies of a particular album, there is obviously something different between them. If there is, they should be separate releases in musicbrainz, so I have distinct release MBIDs for both. Obviously it's OK if they use the same tracklist and recordings. For this reason I prefer to err on the side of caution, and create separate releases for iTunes and Amazon downloads. For me, the issue of not being able to distinguish between two different releases would be a much larger problem than clutter in the database. -- kuno / warp. ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre RFC for release RG titles
If people aren’t adding ARs because it’s too hard, then we need to make it easier, not harder by adding an additional field. Let's just get something straight, people are not adding ARs because there are too many but because entering them is a pain and generally have to be done on an individual basis. One the editor gets major improvement and that it's easier to group edits and reduce the amount of data input, people will enter more ARs... Another note, I'm still 100% in favor of adding a composer AC at the release level and it doesn't even necessarily need to be entered manually most of the time as the editor could deduce what it should be from the ARs... There's all sorts of mostly useless fields already and people don't complain (Script and Language at Release level for example). However I'm sure someone somewhere finds them useful and uses them for sorting or filtering. This Composer AC would be the same thing. If you're not interested in using it, don't use it, otherwise those that want to use it and have a more logically categorized classical music collection can benefit from it. Sebastien Sebastien On Fri, Feb 3, 2012 at 11:30 AM, Alex Mauer ha...@hawkesnest.net wrote: On 02/03/2012 02:25 AM, pabouk wrote: On 2/2/2012 8:43 PM, pabouk wrote: Though I like how the ACs look I see the impossibility to use regexp to separate composers and performers as a big disadvantage. I certainly would like to store composer ACs into one tag and performer ACs into a different tag. Isn't that why we have ARs? Yes, we have the ARs capability but in fact only a small part of releases have usable ARs. I doubt that this would considerably change in the future. And why would it be any different with these special-composer-ACs you’re proposing? If people aren’t adding ARs because it’s too hard, then we need to make it easier, not harder by adding an additional field. Also as I wrote the queries to determine if an artist from ACs is a composer or performer are very complex (querying all ARs of the release recordings and works). Then we need to make that easier too. Computer time is easier to get than editor time. —Alex Mauer “hawke” ___ 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-359: Allow links to video channels on sites other than Youtube
Calvin Walton wrote: Ok. So in this case, adding the new generic 'Video Channel' AR as the parent of the existing Youtube AR in the tree would be acceptable? Yes, that would be fine. Nikki ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre RFC for release RG titles
Alex Mauer wrote On 02/03/2012 02:25 AM, pabouk wrote: Yes, we have the ARs capability but in fact only a small part of releases have usable ARs. I doubt that this would considerably change in the future. And why would it be any different with these special-composer-ACs you’re proposing? If people aren’t adding ARs because it’s too hard, then we need to make it easier, not harder by adding an additional field. In MB you can find many releases without ARs but with composers and performers properly added at the release level (in the artist field and in the title between brackets). I think the only reason why editors do not add ARs is not just the tedious procedure in MB web UI but also the fact that they simply do not have the required information at the track level. For example in which tracks an artist sung in which tracks an artist played certain instrument etc. Also in Discogs which I think is much easier for adding track level artists you will find many releases with just a basic information added. Also as I wrote the queries to determine if an artist from ACs is a composer or performer are very complex (querying all ARs of the release recordings and works). Then we need to make that easier too. Computer time is easier to get than editor time. There is a misunderstanding here. I meant queries which would need to be implemented in a tagger like Picard to be able to separate the content of the release ACs into the tags I would like to use - album composers and album performers. Lemire, Sebastien-2 wrote There's all sorts of mostly useless fields already and people don't complain (Script and Language at Release level for example). However I'm sure someone somewhere finds them useful and uses them for sorting or filtering. This Composer AC would be the same thing. If you're not interested in using it, don't use it, otherwise those that want to use it and have a more logically categorized classical music collection can benefit from it. AFAIK the script and language fields are used for translated and transcribed releases but as I never used such releases I could be wrong. Anyway thank you for understanding my needs :) I think all contributors in this thread agreed that we will add both composers and performers to the release ACs. I think this is a great step forward - let's start to use this but lets consider the schema change in the future to make this information less ambiguous and more structured without requiring more work from editors. - Václav Brožík / pabouk -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Pre-RFC-for-release-RG-titles-tp4336795p4355991.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] Pre RFC for release RG titles
2012/2/3 pabouk pab...@centrum.cz Alex Mauer wrote On 02/03/2012 02:25 AM, pabouk wrote: Yes, we have the ARs capability but in fact only a small part of releases have usable ARs. I doubt that this would considerably change in the future. And why would it be any different with these special-composer-ACs you’re proposing? If people aren’t adding ARs because it’s too hard, then we need to make it easier, not harder by adding an additional field. In MB you can find many releases without ARs but with composers and performers properly added at the release level (in the artist field and in the title between brackets). I think the only reason why editors do not add ARs is not just the tedious procedure in MB web UI but also the fact that they simply do not have the required information at the track level. For example in which tracks an artist sung in which tracks an artist played certain instrument etc. Also in Discogs which I think is much easier for adding track level artists you will find many releases with just a basic information added. Also as I wrote the queries to determine if an artist from ACs is a composer or performer are very complex (querying all ARs of the release recordings and works). Then we need to make that easier too. Computer time is easier to get than editor time. There is a misunderstanding here. I meant queries which would need to be implemented in a tagger like Picard to be able to separate the content of the release ACs into the tags I would like to use - album composers and album performers. Lemire, Sebastien-2 wrote There's all sorts of mostly useless fields already and people don't complain (Script and Language at Release level for example). However I'm sure someone somewhere finds them useful and uses them for sorting or filtering. This Composer AC would be the same thing. If you're not interested in using it, don't use it, otherwise those that want to use it and have a more logically categorized classical music collection can benefit from it. AFAIK the script and language fields are used for translated and transcribed releases but as I never used such releases I could be wrong. Anyway thank you for understanding my needs :) I think all contributors in this thread agreed that we will add both composers and performers to the release ACs. I think this is a great step forward - let's start to use this but lets consider the schema change in the future to make this information less ambiguous and more structured without requiring more work from editors. - Václav Brožík / pabouk Yeah, this will be the next to go to RFC status (I'll wait until either RFC-348 or 350 goes to RFV). I'll suggest comma and semicolon, as discussed: composer1, composerN; performer1, performerN /symphonick ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] RFC-350: CSG Tracklist/Artist
symphonick symphon...@gmail.com writes: http://wiki.musicbrainz.org/Proposal:CSG2012/Tracklist/Artist I think there is consensus about using composer as artist in classical tracklists. comments? /symphonick Looks good. As for suggestions for examples: - Simple: Go for something well known. A concerto (maybe the Elgar Cello concerto?) or Holst's Planets suite? - 1 composer: Maybe an arrangement like Ravel/Mussorgsky Pictures at an Exhibition? Or Pluto from Holst's Planets suite? (I'm less keen there) Or the Ave Maria you suggest seems good. - Maybe an arrangement should be put in as another example, split out from the above. I would also add a few more simple ones. Maybe a symphony? Bach's Air on a G string (with no mention of Procul Harum..)? Rupert pgpfSZ0A6jRnc.pgp Description: PGP signature ___ MusicBrainz-style mailing list MusicBrainz-style@lists.musicbrainz.org http://lists.musicbrainz.org/mailman/listinfo/musicbrainz-style
Re: [mb-style] Pre RFC for release RG titles
pabouk wrote I think the only reason why editors do not add ARs is not just the tedious procedure in MB web UI but also the fact that they simply do not have the required information at the track level. For example in which tracks an artist sung in which tracks an artist played certain instrument etc. if you don't know the credits for each specific track you can still add fuzzy composer/performer/.. relationships on release lvl. so.. your argument is invalid? (no offence) best, lorenz -- -- View this message in context: http://musicbrainz.1054305.n4.nabble.com/Pre-RFC-for-release-RG-titles-tp4336795p4356285.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
