Hi (sorry this became long, but replies to many), I have before spoken warmly in favour of Musicbrainz, and I shall do so again since it without doubt is *the* best and most ambitious free (and probably also non-free) meta-data system for music and we should all use it (and contribute)!
Apologies if I'm repeating stuff or stating the obvious in the following. First a word of warning. Picard does not presently afaik support all MB data and SC does not support all tags used by Picard. There is no inherent reason afaik this could not change as to allows SC to take more advantage of the data in MB. Also some SC-users have very specialised taggins-schemes used in combination with various SC-plugins to obtain a highly customised setup. MB might not work well for those. First an example of tags that I got automatically using Picard (with 3 plugins). http://img11.imageshack.us/img11/1306/tagsu.png Moonbase;421140 Wrote: > > '-MusicBrainz-' (http://musicbrainz.org/) is a big effort > to build a comprehensive database of existing music, based on > human-edited entries and much much more information, ... Indeed true. As an example, such information can include composer (down to the details of lyricists etc), band members, performer vs. composer, the roles of group members (guitar,drums,vocals etc). On top of that there are cross relations so that one can extract e.g. a band-members other gigs (bands, solo, composer etc.). Additionally there are relevant links to eg amazon, wikipedia, myspace or whathever. And there's more; as said, it is *very* ambitious. Mnyb;421242 Wrote: > Have you found any taggin application for Linux > that uses musicbrains and has an human freindly interface What??? Picard has very few menu-items and probably less than 10 menu-buttons. Its about at clean as it can get. Additionally it does some things automatic in a very clever way. Mnyb;421242 Wrote: > i tried picard but that was just horrible > cumbersome and slow and no cover art either. Cumbersome meaning exactly what? I postulate that if its slow, then you are using it wrongly. Eg. one is not supposed to analyse all tracks by default? Cover-art is available using a semi-official plugin. By that I meat that AFAIK its not in the core for the sole purpose of keeping the core minimal. Mnyb;421242 Wrote: > And picard added a bunch of non standard > "musicbrainz" tags ? Non-standard? What do you mean? Flac has no standard set of tags. I'm pretty sure Picard does not add stuff not coming from MB as it is *the* official MB tagging utility. Mnyb;421242 Wrote: > is any other application using this, does > SqueezeCenter use any of this info ? SC uses at least composer, performer, sort-order and such (but still only a small subset of the MB info). This in addition to the standard tags such as artist/track/album of course. NFLnut;421794 Wrote: > But I find their tagger, Picard, to be a little > too automated, cumbersome, slow, and IMO, erroneous for my tastes. > In what sense exactly (apart from the issue you mention below if any)? NFLnut;421794 Wrote: > > For example, for older music (much of my catalog is from the 60s and > 70s and earlier) it would often pull up some greatest hits compilation > from the 80s or 90s. When *I* want to tag with the original artists' > album including cover art from that album, and the actual year of the > song's first release. > OK, these cases can be difficult as such tracks often appear on many releases and in many different versions. Moreover releases that old do not have an original CD release, hence can not be provided with a discid. Finally that type of release is probably not that well covered in the database at this point in time. However it is up to us to improve that. Even so, provided the album is in the database it should work flawlessly with the magic wand. If not one might attempt an analysis. Now this step can be rather inexact for the reasons I mentioned above. Therefore it might be better to manually invoke a search from Picard which will launch a query at the MB-site. If the release is found, just click "tagger" in the browser and the info is transfered to Picard. If the release is not in the MB database you have to enter it. This is about as easy as it can get with Picard/MB though. The most common ways are either by importing from freedb or by submitting the tags already in your files. Its then readily available. If you do this the release will forever??? be available to you and all others that have the release. And if someone improves (by correcting or adding information) some information, you will get those improvements for free. I don't think this is worse than other tools given the premises. The only difference is that you edit a central database as opposed to your local files and therefore have to click to get that information into the tagger. (Sorry if you knew all this). NFLnut;421794 Wrote: > > It allows more individual manipulation of track > IDs without a lot of fuss This is the single weakest point of Picard. If you do not collect by release, but by tracks, tagging will work fine, but the procedure is sligtly ugly. snarlydwarf;421807 Wrote: > It's annoying when MB doesn't have the > actual disc (especially with Classical, since they are very strict on > how to enter data), but that's the case of freedb type things too. > In what sense is it annoying? It takes a lot of work to tag classical music properly. But the goal is to have good tags isn't it? So with a bit of persistance it is not difficult to add a new release at MB. So maybe its annoying that someone else doesn't, either for free or by charging some amount, provide this information. However if one wants good tags the work has to be done by someone, so I think its a best effort scenario. Its based on sort of a peer-reviewing process, and they are strict. In essence you should follow the official scheme (unless you can provide sound arguments for not doing so), and changes should be documented by "witnesses". Eg if you add an album, provide a link to perhaps amazon to show that it exists and has the title/tracks/etc you claim. This is part of the reasons (most of) the tags are so good. I know it can be discouraging to get ones edits rejected because of some seemingly benign deviation from the standard. But remember that *all* other users, including the very meticolous ones, will also get hit by ones personal "customisation". Freedb is a nightmare as one can often find a release, but just as often it will be full of errors and/or non-standardised formatting. (In practise the rules are not always enforced) MrSinatra;425594 Wrote: > maybe SC should support that in its core > first, b4 they try other multiple property recognition methods. > I've suggested tighter integration between SC and MB before and do not mind repeating that request here. MrSinatra;425594 Wrote: > question though; does the MB ID tags > differentiate between say remasters of the same song? the doors for > instance have at least three different releases, and who knows how > many differing pressings, of the same songs. would MB ID tags know, > and tell apart, one from the other? You already heard from others that the answer is yes. In the case of albums sometimes a remastered or reissued album will have bonus tracks, or other track-list differences compared to the original. This means several separate albums in most meta-data system. But usually we actually want the release to be "the same". MB has in its newest (beta?) release facilities that enables grouping such albums while at the same time maintaining their separate ids. This is afaik part of the solution to a more difficult problem as albums we think of as being the same can sometimes even have differences in artists and/or title. Btw. I'm not affiliated with MB, just enthusiastic. -- bhaagensen ------------------------------------------------------------------------ bhaagensen's Profile: http://forums.slimdevices.com/member.php?userid=7418 View this thread: http://forums.slimdevices.com/showthread.php?t=62556 _______________________________________________ ripping mailing list [email protected] http://lists.slimdevices.com/mailman/listinfo/ripping
