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

[topdownjimmy]

I originally posted this in the Navigator Suite thread, before I was aware standardization had its own thread. Cut-n-paste:

on in the wiki, so please add any standards for which you come to a conclusion.  I've already included what I expect will be the PLAY_DATE standard (YYYYMMDD), but please correct me if I'm wrong in that.

In general, i'm all for the ISO-version (YYYYMMDD). But my proposal would be to make it "YYYY-MM-DD", because that way, it can be verified with TAGZ (by checking the position of the seperators). As a bonus, it also makes it easily readable even without processing.

- Lyx

Can quantitative comparisons be made on strings containing hyphens? I'm at work, so can't test :/

upNorth, if the time were to be included in the PLAY_DATE field, how do you suggest the entire field be formatted? I think this would be best because then if someone enjoys having a timestamp but wants to make their second playcount field available for some custom tag, they won't be forced to violate the standard (by appending $H$M$S to the standard YYYY-MM-DD or whatever).

...and because the field would then contain both date and time, would PLAY_DATE still be an appropriate field name? Perhaps with a new standard a new field name is in order (e.g. LAST_PLAYED).

[Lyx]

Yes, you can check the length in characters of a string with TAGZ ..... and also "scan" a string for the occurance of a substring (like i.e. a dash). So, understandable for mortals*g*: yes, when having seperator-dashes in the date, then you can verify the date-format with TAGZ.

This post has been edited by Lyx: Feb 14 2005, 22:02

[topdownjimmy]

Sidenote: When deciding about a standard, it should also be considered how easy it is for users to switch to it. Thus, the more easy, less disruptive and more attractive the transition, the better the chances of widespread use.

Creating a completely new tag-field may be a bit hefty to enforce. Thats what i meant with "a balance between popularity and reasonable-to-support for devs".

BTW: i just created a thread to discuss this topic.

The reason I suggested a new field entirely is because if the standard DOES in fact become something like YYYY-MM-DD-$H$M$S as I suggested, it's unlikely that anyone's PLAY_DATE field will already comply. So, as long as we're all whipping out our masstaggers, we might as well create a new field.

This also has the bonus of instant verification; if someone has a LAST_PLAYED field, it is most likely because they created it in response to this established standard, so there would be no need to wonder/test/worry whether someone's LAST_PLAYED field complies.

This post has been edited by topdownjimmy: Feb 14 2005, 22:05

[topdownjimmy]

Yes, you can check the length in characters of a string with TAGZ ..... and also "scan" a string for the occurance of a substring (like i.e. a dash). So, understandable for mortals*g*: yes, when having seperator-dashes in the date, then you can verify the date-format with TAGZ.

I'm sorry, by "quantitative" I meant, for example, in playlistgen:
%PLAY_DATE% GREATER 2005-01-02

If %PLAY_DATE% is 2005-02-05, will it turn up in the results, or do the hyphens interfere?

edit: clarification

This post has been edited by topdownjimmy: Feb 14 2005, 22:11

[Lyx]

hmm, interesting point - i didn't look at it from that angle yet about the new-field idea.

I'm not sure...... if quantitative comparision is possible when a string is not numbers-only. I'll check it.

This post has been edited by Lyx: Feb 14 2005, 22:06

[Lyx]

Hmm, i think its not "directly" possible with a single function. But you can just strip-out the dashes with a single function and then do the quantitative comparision. IMHO thats a low price considering the benefits of having dash-seperators.

[topdownjimmy]

Hmm, i think its not "directly" possible with a single function. But you can just strip-out the dashes with a single function and then do the quantitative comparision. IMHO thats a low price considering the benefits of having dash-seperators.

What are those benefits? I think you mentioned something about recognizing what format the date is in...but if we're talking about standards, we don't need to check, do we?

The other benefit you mentioned is that 2005-02-06 is legible without any formatting. But the truth is almost everyone's formatting the date anyway. The only instance in which you're dealing with an ugly date is when you're coding for substrings, and once a standard is introduced, the hyphens become totally extraneous and, in fact, obtrusive (quick: with hyphens, what place in the string is the first digit of the date?)

As ugly as it is, I guess my conclusion is:
LAST_PLAYED = 20050214161500
:/

This post has been edited by topdownjimmy: Feb 14 2005, 22:18

[Lyx]

You're looking at it only from a string-programmers POV. Users will also look at it their tags, and 2005-02-04_22:20 (just an example) looks much more reasonable and inviting to them than 200502042230. It's not just a rational issue but also a subjective one when it comes to adoption. The non-processing thingie is interesting for "amateur-tagz-programmers" - casual users who don't know much about TAGZ and who just want to do simple things with simple methods - disassembling a timestamp and reformatting it requires quite some knowledge about various tagz-functions. So, while it may not be something insanly important, it imho is a definitive pro.

And being able to back-check and having "cues" imho is always a nice thing to have. There's nothing more horrible and bloaty than "guessing".

This post has been edited by Lyx: Feb 14 2005, 22:25

[topdownjimmy]

You're looking at it only from a string-programmers POV. Users will also look at it their tags, and 2005-02-04_22:20 (just an example) looks much more reasonable and inviting to them than 200502042230. It's not just a rational issue but also a subjective one when it comes to adoption.

Do users look at those tags? I would think that more often than not, this tag is being viewed (nicely formatted) in the playlist or trackinfo. I would wager that it's a rare occasion that the type of user who is intimidated by a long date string is looking at one in its raw form.

And being able to back-check and having "cues" imho is always a nice thing to have. There's nothing more horrible and bloaty than "guessing".

Like I said, the point of standardization is to do away with guessing, so I don't think that could possibly be an issue. Hyphens are only necessary for that purpose if there isn't a standard, and blatantly unnecessary if there is one.

[Lyx]

See, advaned tagz-programmers need to disassemble and process the tag anyways - no matter if its a timestamp or humanly readable.

So lets look at it from the other side: whats the advantage of having it numbers-only(remember, the tag needs to be processed anyways)?

[mazy]

i'm backing Lyx on this subject, ppl wouldn't like stamps without any separators. i know we wouldn't mind, but *they* would.

it would be really hard to convince regular users to stick to stamps without any separators.

it's important (for some users) that in case of format suggested by Lyx, one can simply show the whole string (or left part of it in case when time info is part of it too) to show date in readable way (for simple configs, to save work etc.). plus anyone could easily and quickly understand format of it ...

[topdownjimmy]

i'm backing Lyx on this subject, ppl wouldn't like stamps without any separators. i know we wouldn't mind, but *they* would.

it would be really hard to convince regular users to stick to stamps without any separators.

it's important (for some users) that in case of format suggested by Lyx, one can simply show the whole string (or left part of it in case when time info is part of it too) to show date in readable way (for simple configs, to save work etc.). plus anyone could easily and quickly understand format of it ...

But, on the other hand, when it comes to playlistgen, would a regular user rather write this query:

%LAST_PLAYED% GREATER 20050205000000

or

$left(%LAST_PLAYED%,4) GREATER 2004 AND $substr(%LAST_PLAYED%,6,7) GREATER 01 AND $substr(%LAST_PLAYED%,9,10) GREATER 04

A user who is capable of producing the latter query would certainly be capable of writing their own date formatting string. And I think we just disagree on how frequently a regular user is exposed to the date stamp in its raw form (me, almost never, you, enough to eclipse the benefits of no formatting within the date stamp).

[topdownjimmy]

Whatever standard gets agreed upon, is Phi (or someone) available to update the playcount component to default to that standard?

[Lyx]

there's a much more easy playlist-gen query possible, so thats a bit exaggerated. But i see your point.

Does playlistgen treat "." as a decimal-seperator for numbers?

[topdownjimmy]

there's a much more easy playlist-gen query possible, so thats a bit exaggerated. But i see your point.

Oops, I honestly didn't mean to inflate that string. What is the simpler query?

Does playlistgen treat "." as a decimal-seperator for numbers?

Brilliant!

2005.02.14.17.36.00

[picmixer]

Well when it comes to recognition of various artists albums I personally still think the addition of an "album artist" tag is the most sane way to go. This has already been widely adopted by most of the long time fb2k community including developpers, etc.

People can then either set that tag to whatever they like displayed, or to "Various Artists". Furthermore tagz checking for this is extremely simple with just using "$if2(%album artist%,%artist%)".

[mazy]

i think that playlistgen is same as all formatting in foobar in regard that it works only over integers, not numbers.

in case of 2005-02-04_22:20 format you could do just this:


$replace($left(%LAST_PLAYED%,10),-,) GREATER 20050205

there could by some typhos or +-1 errors but i think it's correct. not that difficult at all ... considering all the pros ...

edit: picmixer: yep, i'm for "album artist", it's de facto standard ...

This post has been edited by mazy: Feb 14 2005, 23:44

[topdownjimmy]

Does playlistgen treat "." as a decimal-seperator for numbers?

Brilliant!

2005.02.14.17.36.00

...or not... doesn't work for me

:/

[topdownjimmy]

i think that playlistgen is same as all formatting in foobar in regard that it works only over integers, not numbers.

in case of 2005-02-04_22:20 format you could do just this:


$replace($left(%LAST_PLAYED%,10),-,) GREATER 20050205

there could by some typhos or +-1 errors but i think it's correct. not that difficult at all ... considering all the pros ...

edit: picmixer: yep, i'm for "album artist", it's de facto standard ...

You're right, that's not too difficult. My vote still goes to YYYYMMD..., but I don't think there's any more I can say in favor of it. Looks like the tides are turning against me...

Agree about VA.

[Lyx]

About VA-tagging...... there are actually 2 widespread methods to mark them. The first is the %album artist% tag. The second is just having "V.A.-" or "VA-" at the beginning of a foldername in the path.

To not disrupt existing systems too much, my proposal would be to support both - especially, since you need only a few lines of code to check it.

CODE

// create albumartist var if album is VA
$puts(albumartist,
$if2(%album artist%,
$if($strstr($lower($replace(%_path%,'.',$char(),' ',$char(),'_',$char())),'\va-'),Various Artists)
)
)
// check if album is VA and if yes then display albumartist
$if($strcmp($get(albumartist),$char()),,$get(albumartist))

edit: reworked code-example

This post has been edited by Lyx: Feb 15 2005, 00:06

[topdownjimmy]

About VA-tagging...... there are actually 2 widespread methods to mark them. The first is the %album artist% tag. The second is just having "V.A.-" or "VA-" at the beginning of a foldername in the path.

To not disrupt existing systems too much, my proposal would be to support both - especially, since you need only two lines of code to check it.

CODE

$if(
$or(%album artist%,$strstr($lower($replace(%_path%,'.',$char(),' ',$char(),'_',$char())),'\va-')),
$puts(album_is_va,1)
)

Supporting both is of course a good idea, but if you were to prescribe a standard what would it be?

[picmixer]

Dunno, I personally am one of those people that think that tagz strings should be kept as simply as possible and still bring the desired playlist layout. Wich is why I leave out any tags guessing code out of my own formattings these days and do everything based only on metadata tags.

Off course this is rather a personal philosophy and I know that the camp of formatting string coders is split between people that implement a lot of tag guessing and people that don't.

For me personally however

CODE

$if(
$or(%album artist%,$strstr($lower($replace(%_path%,'.',$char(),' ',$char(),'_',$char())),'\va-')),
$puts(album_is_va,1)
)

would already mean a way longer tagz string then a simple

CODE

$if2(%album artist%,%artist%)

[topdownjimmy]

For me personally however

CODE

$if(
$or(%album artist%,$strstr($lower($replace(%_path%,'.',$char(),' ',$char(),'_',$char())),'\va-')),
$puts(album_is_va,1)
)

would already mean a way longer tagz string then a simple

CODE

$if2(%album artist%,%artist%)

This makes things easier for me as welll, as I use %album artist% for alphabetizations too ("Dylan, Bob"), so $if2(%album artist%,%artist%) crops up a lot in my code.

[Lyx]

Hmm, how about this:
Using the albumartist-tag is the recommended way and should be used by public plugins and scripts when creating new VA-Albums. But having va- or v.a.- at the beginning of a foldername is still supported by formatting-strings?

Alot of users still use the va- approach and have large collections of files. Trying to enforce albumartist-tags on those may result in alienation instead of adoption. But i may be wrong there. I'm just not too sure if its realistic to get full-scale adoption for strict albumartist-tagging.

Maybe it's time for "common users" voicing their opinion on this issue.

This post has been edited by Lyx: Feb 15 2005, 00:15