Tag-standards In Plugins<->formatting, proposals and discussion Options

[Lyx]

upnorth:

Maybe we should start a thread to discuss and agree upon, some "standard" tags for different purposes? E.g. the format of a time/date tag itself, doesn't really make any difference, as its contents can be easily customized for display. If we agree on one format, we could just provide the code needed to display it in different ways.

I think this community could benefit from it in the long run, as changing from one formatting to another would be less confusing to new users.

Lyx:

Agreed. Although imho a balance between "popularity" and "reasonable to support for devs" has to be found. Requiring users to set unpopular weird non-standard tags isn't newbie-friendly as well :-) But thats just details, in general, i completely agree with you.

Why agree on tag-standards?:

• all plugins can make use of the same info without incompatibilities or manual adjustments by the user
• all playlist-displays and UIs can make use of the same info without incompatibilities or manual adjustments by the user
• Some features in the past weren't implemented into plugins/displays, because of lack of standards. Thus, with standardization, new features will become available to the users(as an example, complex playback-statistics weren't possible until standardization happened).
• multiple users can share access to files without their metadata conflicting.
• (longterm-wishful-thinking) applications can make use of the same info without incompatibilites or manual adjustments by the user.

What is the purpose of this thread?:
To determine when standardization on some kind of metadata is necessary, create drafts for new standards, discuss them, refine them, polish them, and then set them in stone. The first post(this one) will keep a list of already agreed upon standards, so that users can get info on how to tag their files without running into problems. If necessary, the initial post will also have links to masstagger-scripts, so that users can easily convert their existing files to be compatible with the outlined standards. Playlist-display creators can also find useful codesnippets to easily implement the tag-standards into their formattings.

Agreed upon standards should NOT be changed anymore afterwards unless there are highly critical issues with them or if the changes would cause zero disruption.

There is also a page on the fb2k-wiki which deals with this topic:
http://wiki.hydrogenaudio.org/index.php?ti...d_Tag_Standards



Participation

You should participate in this thread if...:

• you are a developer(plugin, display or application) who is interested into the goals described in "why agree on tag-standards"
• you have skills/experience in standardization as well as a good understanding on metadata-manipulation, programming and usability-paradigms
• you are a user who wants to point out his/her current tagging-scheme. This is very useful to us, because the size of an existing userbase of a given scheme has a big impact on the chances how well and fast a standard will be adopted.

This thread is irrelevant to you if...:

• you only use standard ID3v1 tags (artist, album, title, tracknumber, date, genre, comment)

You should not participate in this thread if...:

• you disagree with the idea of tag-standardization. In this case, you as well as we will gain nothing from your participation, because neither you nor we will change our mind.

Things to keep in mind when discussing and drafting new standards:

• if you're new: before posting anything, please read back the last 15 posts, to avoid creating circular discussion-loops. If this requirement is too much for you, then don't participate.
• Focus on one tag-standard at a time, and on one issue at a time. If an issue is complex, then split it up into sub-issues and approach one after another. Try to avoid rediscussing issues which were already agreed upon, to avoid circular discussion-loops.
• Before proposing a standard, estimate to how many users it will be useful. Truely exotic usage does not require standardization, simply because its so exotic that almost no plugin/display/app will support it anyways. A phantom-standard.
• Consider if there are already existing standards which only need a complementary metadata-field to reach the desired functionality (instead of creating a completely new redundant metadata-field).
• Consider if there are already existing variants in use and estimate their userbase. It is much easier to standardize a scheme which already has an existing userbase instead of starting from scratch (resistance to change). Every standard is only as good as its userbase.
• Set/Album-specific fields should have their name prefixed with ALBUM(i.e. ALBUM ARTIST, ALBUM RATING, etc.)
• Spaces should be prefered over underscores unless there are significant reasons for underscores
• Consider semantics: tag-contents which's meaning can change at will are bad
• Consider DB-friendlyness: how good is the scheme sortable and searchable?
• Consider readability: the name of a tag as well as its raw-content should be easily recognizable and understandable
• Consider programmer-requirements: the tag's contents should be easy to extract, manipulate and verify. Also consider logical as well as arithmetic operations
• Try to minimize disruption and confusion/ambiguity between the new standard and existing variants
• Don't be a purist - only in rare cases, you will get all of the above aspects 100% perfect - the best solution in most cases is the one which offers the best compromise between all those aspects

____________________________________


Masstagger Scripts & Downloads:
Scripts, Downloads, etc. can be posted and found in the following thread:
http://www.hydrogenaudio.org/forums/index....showtopic=31592
Masstagger scripts can significantly help less technically gifted users to adopt the discussed tag-standards. If you've created a masstagger-script which may be userful for others, then please share it in the above thread. Please don't post questions and discussions in the above thread, but instead here, so that it stays for uploads and downloads only.
_____________________________________


List of agreed tag-standards:

FIRST_PLAYED and LAST_PLAYED

Basics:

• the tag-fieldname used for storing info when a song was played the first time is "FIRST_PLAYED"
• the tag-fieldname used for storing info when a song was played the last time is "LAST_PLAYED"
• both tags contain date and time in the following format at the beginning: "YYYY-MM-DD hh:mm:ss" (with 24hours-format)
• additional info may be appended after the above info (it is tolerated but not supported)

Reasons for agreeing on this scheme:

• the APEv2-dateformat (derived from ISO) is internationally neutral
• sortable
• easily readable
• easy to remember and type in manually
• format can be verified with TAGZ
• can be included in formatting-strings without reformatting it (pro for amateur tagz-coders)
• choosing a new fieldname avoids confusion with the existing ambigious play_date tag

Updated playcounter-plugin here:
Download (binary & sourcecode)

Code snippets (for foobar 0.8-0.9):

CODE

// check if tag exists and validate it
// (we check the position of the first dash and collon)
// using $len for validation is strongly unrecommended!
$if(
$and($strcmp($strstr(%last_played%,-),5),$strcmp($strstr(%last_played%,:),14))
,$puts(last_played_is_valid,1)
)

CODE

// split up the timestamp for later reformatting or calculations
$puts(last_played_year,$substr(%last_played%,1,4))
$puts(last_played_month,$substr(%last_played%,6,7))
$puts(last_played_day,$substr(%last_played%,9,10))
$puts(last_played_hour,$substr(%last_played%,12,13))
$puts(last_played_min,$substr(%last_played%,15,16))
$puts(last_played_sec,$substr(%last_played%,18,19))

CODE

// display only the date of last_played (without reformatting)
$left(%last_played%,10)

CODE

// display only the time of last_played (without reformatting)
// the use of $right is strongly unrecommended!
$substr(%last_played%,12,19)

You can use the same code for FIRST_PLAYED of course, just exchange %last_played% with %first_played%.

Adoption-Status: medium stage

• Updated foo_playcount released.
• support in FCSs and formattings has started
• medium risk in switching to the new standard

__________________________________________


ALBUM ARTIST

Basics:

• the tag-fieldname used for declaring and describing albums/split-EPs or split-singles which contain various artists is "ALBUM ARTIST" (seperated with space, not underscore)
• tag should only exist if an album contains various artists. It should NOT be created when an album does not contain various artists.
• the tag can contain the overall artist of an album(like i.e. "the foo-bar collective"), multiple artists(i.e. with split-EPs) or if an album does not have a clear overall artist (for example with compilations) just "Various Artists". Simply said: you're free to enter whatever you like as long as it describes the overall album-wide artist(s).
• every track of a V.A.-album/-set has to contain this tag with identical values
• the track-specific artist should be entered into the ARTIST-tag
• the TITLE-tag should only contain the track-title

Reasons for agreeing on this scheme:

• it solves all issues regarding albums which contain multiple artists with just one tag
• it is already in widespread use
• sortable and searchable with low effort
• keeping the ARTIST-tag trackspecific allows to find tracks in V.A.-albums as well when searching for a certain artist (DB-friendly)
• keeping the TITLE-tag title-specific allows sorting and searching of V.A.-albums by title (DB-friendly)
• allows meaningful determination and display of V.A.-Albums with a minimum amount of code
• avoids resource-hungry and unsafe "guessing" of V.A.-albums via the filepath
• easy to remember and type in manually
• does not disrupt existing systems when the ARTIST- and TITLE-tag are already trackspecific (easy transition)
• can coexist with additional directory-based sorting and marking
• can be used for split-EPs and split-singles as well

Code snippets (for foobar 0.9):
These make use of "field-remappings" for code-simplifycation!

CODE

// check if an album is V.A.
$if($meta_test(album artist),$puts(album_is_va,1))

CODE

// For sorting by artist in an album-context replace %artist% - %album% with:
%album artist%[ - %album%]

CODE

// singlemode display without %album artist%-priority
[%artist% - ][%album% - ][%title%]

// singlemode display with %album artist%-support
// note: if your display supports both, albummode and singlemode, then you
// may want to use the above version instead in singlemode - matter of taste
[%album artist% - ][%album% - ][%track artist% - ]%title%

CODE

// How to easily integrate %album artist% into an albummode-display:

// in the albummode-column, replace %artist% with:
%album artist%

// in the title-column, replace %title% with:
[%track artist% - ]%title%

Adoption-Status: in widespread use / default VA-method since foobar2000 0.9

• the majority of all public fb2k-displays which support albummode do already support this tag-standard
• some fb2k-singlemode displays also support it
• since foobar 0.9 this standard is the default method to mark VA-albums in foobar. It has also been integrated into the "field-remappings"
• users can immediatelly switch with minimum risk

__________________________________________


RATING and ALBUM RATING

Basics:

• the tag-fieldname used for storing the rating of individual tracks is "RATING"
• the tag-fieldname used for storing the rating of entire sets(i.e. albums, compilations, EPs, etc.) is "ALBUM RATING"
• both tags contain a single integer in the range of 1-5.
• As a guideline for rating, asume the following: 1="i hate it", 2="i dislike it", 3="it's okay", 4="i like it", 5="i love it"
• the absence of a RATING/ALBUM RATING tag means "unrated"
• In the case of ALBUM RATING, every track of the set has to contain this tag with identical values.
• Hint for developers: if you want to increase error-tolerance towards slightly-incompatible applications like WMP, make it so that only the first char of the tag-contents is interpreted. This is not mandatory - every RATING/ALBUM RATING tag which doesn't comform to the specs outlined above can be considered "unsupported/invalid".

Reasons for agreeing on this scheme:

• simple
• sortable
• easily readable
• easy to remember and type in manually
• RATING is already in widespread use
• The 1-5 rating-scale is in widespread use and something to which people can easily relate

Code snippets (for foobar 0.8-0.9):

CODE

// star-rating (single-color version)
$rgb(200,0,0)
$repeat(*,%rating%)

CODE

// star-rating (two-color version)
// colors asume a white background
$rgb(200,0,0)
$repeat(*,%rating%)
$rgb(250,230,230)
$repeat(*,$sub(5,%rating%))

You can use the same code for ALBUM RATING of course, just replace %rating% with %album rating%.

Adoption-Status: medium stage

• RATING is already in widespread use and is supported in many displays
• ALBUM RATING is in early adoption stage

__________________________________________


STYLE

Basics:

• the main "genre" should go into the GENRE-tagfield
• the tag-fieldname used for storing secondary music-styles is "STYLE"
• the tagfield may contain any kind of "keywords" do describe "what" the track sounds like.
• it should NOT contain info about the "mood" of a track("how" it sounds like)
• the styles should be seperated with a comma and space, like "post-rock, noise, electronica"
• If the file does not use ID3v2 tags, then you may also use multiple tagfields with identical name instead.
• this tagfield is trackspecific

Reasons for agreeing on this scheme:

• simple
• allows backwards-compatibility while not ruling out multivalue-field capabilities of modern tagsystems
• easily readable
• easy to remember and type in manually
• name is consistent with other tagfields(ARTIST, ALBUM, GENRE, STYLE)

Code snippets:

CODE

// To display the styles of a track,
// simple put the following somewhere...
%style%

Adoption-Status: early-adoption stage

• Already supported in some playlist-displays
• Adoption should be simple because of how easy it is to switch to it(low effort)

This post has been edited by Lyx: Mar 1 2006, 22:52

[Lyx]

Possible solution to make everyone happy:

Have two modes for the playcount plugin in the preferences:
[radioknob] Use new LAST_PLAYED and FIRST_PLAYED tag-standard (recommended)
<no options here>

[radioknob] Use old custom-settings method (may not be supported by public formattings and plugins)
<previous options with play_count and play_date being the default-fields>
- Lyx

edit: s**t, i forgot to make a screenshot, lol.

This post has been edited by Lyx: Feb 18 2005, 07:52

[desigrid]

Possible solution to make everyone happy:

Have two modes for the playcount plugin in the preferences:
[radioknob] Use new LAST_PLAYED and FIRST_PLAYED tag-standard (recommended)
<no options here>

[radioknob] Use old custom-settings method (may not be supported by public formattings and plugins)
<previous options with play_count and play_date being the default-fields>
- Lyx

edit: s**t, i forgot to make a screenshot, lol.

Sounds great .