Topic: Use of the release disambiguation field

I'm interested in what the guidelines are surrounding the release disambiguation field.

The general impression I get is that it should only be used when necessary to prevent two releases from being merged. However, there seem to be other uses such as noting 'deluxe' releases and remasters. I wonder how far such use can go. For example, is it valid to add 'itunes version' to a release that has itunes exclusive tracks? It may not be necessary to prevent merging, but is still useful information. Could the same be true for CDs with bonus tracks?

One issue that is linked with this is the use of the disambiguation field by picard or other taggers. It's sometimes useful to use tagger script to add this information to the title, e.g. the 'CD 1' and 'CD 2' for UK single sets. There are some other situations in which it would be useful to add information to this field. One is where an artist has releases of different types (album, single, ep) with the same name. Tagging straight from MB creates problems because media players will read all the tracks as being from one release. Adding the relevant description to the disambiguation field would mean you could append this information to the title. However, I imagine many would consider such comments unnecessary in the database, and they would be right. So you have a conflict of having something useful for picard but not for MB.

Unless there's some way to get picard to read information from file comments, I don't see any practical ways to get around this. One could manually edit the releases after tagging with picard but this is laborious, particularly if one regularly re-tags their files to include new edits. The only other suggestion is to add a new field for information such as this that picard needs in relation to certain difficult releases. However, this could be done currently using the disambiguation field, if users don't object.

Re: Use of the release disambiguation field

You can use the variable %_releasecomment% in Picard to add the disambiguation to your file naming strings.  I use this for Japanese music, because they'll often release singles in different versions with slightly different tracklists.

"I say we invite opportunity inside for a nice cup of tea, then hit her on the head and steal her purse." - Kevyn Andreyasn
- Schlock Mercenary by Howard Tayler

Re: Use of the release disambiguation field

Billy Yank wrote:

You can use the variable %_releasecomment% in Picard to add the disambiguation to your file naming strings.  I use this for Japanese music, because they'll often release singles in different versions with slightly different tracklists.

Yes, that's what I do. My point is there is some information I would like to put in the field on some releases, but I think other users might argue it is not useful from a database perspective and vote it down.

For example, there are self-titled releases by Fleet Foxes in both album and ep form. So I would like to add 'EP' to the disambiguation comment field for the ep release to prevent itunes from mixing the tracks up. The problem is that from a database perspective the information is not needed because you can already see the different release types. However, itunes cannot distinguish unless you set picard to always write the release type to the title, but that seems like overkill.

Re: Use of the release disambiguation field

The disambiguation fields usage should really not be driven by tagging requirements. That's not their purpose. There are no guidelines for them, and this is intentional - they're expected to be database navigation and manual matching aids; not to be used for standardised "tidy" data. Having said that, it'd be nice if at least common sense was applied when editing them, not complete mess :)

This kind of thing is one of the reasons that opening up the comments to the web service was resisted for some time.

Disambiguating iTunes versions etc makes sense; adding EP really doesn't since as you note, the data is already part of the release group. I think the requirement to be able to have Picard notice duplicates and treat them differently really needs some kind of solution inside Picard. I've found that normally keeping the files in different folders; even if tagged album name is the same; is enough to make most decent media players treat them as different albums. Not sure about iTunes though... it's in a crazy world of its own.

Re: Use of the release disambiguation field

voiceinsideyou wrote:

The disambiguation fields usage should really not be driven by tagging requirements. That's not their purpose. There are no guidelines for them, and this is intentional - they're expected to be database navigation and manual matching aids; not to be used for standardised "tidy" data. Having said that, it'd be nice if at least common sense was applied when editing them, not complete mess :)

This kind of thing is one of the reasons that opening up the comments to the web service was resisted for some time.

Disambiguating iTunes versions etc makes sense; adding EP really doesn't since as you note, the data is already part of the release group. I think the requirement to be able to have Picard notice duplicates and treat them differently really needs some kind of solution inside Picard. I've found that normally keeping the files in different folders; even if tagged album name is the same; is enough to make most decent media players treat them as different albums. Not sure about iTunes though... it's in a crazy world of its own.

This is pretty much what I though regarding use of the field.

Regarding media players, which do you use? I've not really used any others, so I wonder how widespread this issue is. However, considering how widely used iTunes is, and perhaps in combination with other players if they behave in the same way, it could be an issue worth addressing.

I think that some kind of solution in picard is possible, but I don't have a technical understanding of it so can't say for sure. I imagine a plugin could be written that would cross-reference the loaded releases and, upon finding any duplicates, append 'single' or 'ep' to the title. However, the problem gets increasingly complicated when, for example, you have the same titled single from two different countries; or when there are two albums of the same name, e.g. the Japanese band Boris have two albums titled 'Heavy Rocks' http://musicbrainz.org/artist/57652bf8- … 72a7080d8d

Perhaps the latter example could be fixed with a disambiguation comment, but others would be more difficult. The issue also arrises in relation to some 60's albums, e.g. Rolling Stones, Beatles, that were different in the US/UK. If you have both there could be a clash.

Perhaps a picard fix would work, although it may have to be highly sophisticated in order to cover all possible issues, and in doing so may cause slowdown or crashes.

An alternative would be to add a dedicated field to MB for such purposes.