Folksonomy/Musicbrainz, custom tags or multiple genre tags

[stormwatch]

I'll start with praise: After the various disappointments of Songbird ---even before dropping Linux support--- I soak up in GMB as a thirsty soul in holy water. Thanks to you Quentin and to every contributor.

I'd like to add tags to songs in a kind of folksonomy fashion. For example, a madrigal by Gesualdo could have: "classical", "madrigal", "vocal", "voices=5", "a capella" "language=italian", and so on; a piano piece by Morton Feldman could have: "classical", "piano", "solo", "date_of_composition=1952-xx-xx", etc. Should I use custom tags or multiple genre tags? Would there be any difference in terms of performance? (think of databases larger than 1TB) I'd like also ---if possible--- to conform to folksonomy/Musicbrainz standards.

[Quentin Sculo]

for "language=italian", "voices=5", "date_of_composition=1952-xx-xx", it would be best to use dedicated fields. This can be a custom field or an optional standard field that I could add.
(custom field names must begin with a uppercase btw)
note that not all fields can be saved in the file tag, currently only custom fields of the type "rating" can be saved (using the recent FMPS standard)

- for "language=italian" you could use either a custom field of type "common string", or a field of the same type as genres or labels if you want to allow more than one language in a song, (the genre/label type is called "flags" in custom fields, though I'm not sure it is a good name).
I'll probably add this one as an optional standard field at some point
- for "voices=5" a custom rating field would be good, they are currently limited to values 0-100, with a default value that is still shared with the rating field. I plan to allow configuring custom stars pictures for a custom rating field, currently it uses the same.
- for "date_of_composition=1952-xx-xx", there is no date type yet for custom fields :( you can use a "common string" or "string" type in the meantime though I'm not sure if it will be convertible to a date type once I add one. Also "string" type will use more memory than a proper "date" type.

For the others, using the genre or label field should be fine, you can also create one or more custom fields of the type "flags". Currently only the genre field is saved in the file tag.

I don't know what folksonomy/Musicbrainz standards are, feel free to educate me :) the pages I found with quick search on musicbrainz.org are not very clear.

The custom and optional fields are still new in gmb, some things are still not working with them, like filter edition (I'm working on it), and random modes. But displaying them, sorting, and filtering with SimpleSearch and FilterLists should work fine.

[stormwatch]

I've been mulling over this but I am still confused. It seems that In my previous post I assumed that tags would be written to files and forgot that they could also be written to the database. If we (some of us?) are thinking about implementing future musicbrainz support, then perhaps it would be better to first be able to easily copy, mirror, and remove tags to and from the database and tags in music files.

for "language=italian", "voices=5", "date_of_composition=1952-xx-xx", it would be best to use dedicated fields.

Why?

This can be a custom field or an optional standard field that I could add.
(custom field names must begin with a uppercase btw)
note that not all fields can be saved in the file tag, currently only custom fields of the type "rating" can be saved (using the recent FMPS standard)

Besides what you've just mentioned here and below, what is the difference between standard and custom fields? Are standard fields hardcoded (sorry abot the term, I'm not a developer) unlike custom fields? Is there any penalty or overhead when using custom fields?

- for "language=italian" you could use either a custom field of type "common string", or a field of the same type as genres or labels if you want to allow more than one language in a song, (the genre/label type is called "flags" in custom fields, though I'm not sure it is a good name).
I'll probably add this one as an optional standard field at some point
- for "voices=5" a custom rating field would be good, they are currently limited to values 0-100, with a default value that is still shared with the rating field. I plan to allow configuring custom stars pictures for a custom rating field, currently it uses the same.
- for "date_of_composition=1952-xx-xx", there is no date type yet for custom fields :( you can use a "common string" or "string" type in the meantime though I'm not sure if it will be convertible to a date type once I add one. Also "string" type will use more memory than a proper "date" type.

For the others, using the genre or label field should be fine, you can also create one or more custom fields of the type "flags". Currently only the genre field is saved in the file tag.

I don't know what folksonomy/Musicbrainz standards are, feel free to educate me :) the pages I found with quick search on musicbrainz.org are not very clear.

This is a list of some tags that Picard can write http://wiki.musicbrainz.org/PicardTags

Table of mapping between Picard internal tag names and various tagging formats.
http://wiki.musicbrainz.org/Picard_Tag_Mapping

This is a search in musibrainz-devel
http://search.gmane.org/?query=folksonomy&group=gmane.comp.audio.musicbrainz.devel

Searching for "folksonomy" in the forums yelds interesting discussions too.

The custom and optional fields are still new in gmb, some things are still not working with them, like filter edition (I'm working on it), and random modes. But displaying them, sorting, and filtering with SimpleSearch and FilterLists should work fine.

I think I'll post also in the Musicbrainz forums and list, and try to grab attention to this topic in the hope of mutual enlightenment.

Are there any others using GMB and Picard?

[stormwatch]

It seems that Next Generation Schema is more what I'm up for? Not sure though.

http://wiki.musicbrainz.org/Next_Generation_Schema/History

http://wiki.musicbrainz.org/Next_Generation_Schema/Usage_Case

http://wiki.musicbrainz.org/Next_Generation_Schema

[Quentin Sculo]

I've been mulling over this but I am still confused. It seems that In my previous post I assumed that tags would be written to files and forgot that they could also be written to the database. If we (some of us?) are thinking about implementing future musicbrainz support, then perhaps it would be better to first be able to easily copy, mirror, and remove tags to and from the database and tags in music files.

I'm not sure what you mean by that exactly. But yes only some fields can be saved in the tags currently, the main problem for that is the lack of established standards.

for "language=italian", "voices=5", "date_of_composition=1952-xx-xx", it would be best to use dedicated fields.

Why?

Well I'm not sure, but it seems you were suggesting adding values such as "language=italian" as genres, while it would work that is really not a nice way to proceed.
Using dedicated fields is much more powerful, it allows the software to handle it in a smarter way such as having a tab that list the language, another the date of composition, using an appropriate widget to edit the values ... And even store it internally in a more memory efficient way.

Besides what you've just mentioned here and below, what is the difference between standard and custom fields? Are standard fields hardcoded (sorry about the term, I'm not a developer) unlike custom fields? Is there any penalty or overhead when using custom fields?

Yes you could say that the standard fields are hard-coded, every user of gmb has the same (though some are optional, mainly to save memory and avoid long lists of fields in the menus), and only I can add them.
The differences is that names of custom fields must begin with a uppercase (to avoid clashes with standard fields), and that the available options may differ, in particular for saving values in file tags.
Also gmb will never make use of custom fields by default, as it doesn't know what they stand for. For example I plan to use the optional field discname when possible instead of "disc 1" in the album menu.