HydrogenAudio

Hosted Forums => foobar2000 => General - (fb2k) => Topic started by: Lyx on 2005-02-14 20:47:22

Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 20:47:22
upnorth:
Quote
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:
Quote
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.


[span style='font-size:13pt;line-height:100%']Why agree on tag-standards?:[/span][span style='font-size:13pt;line-height:100%']What is the purpose of this thread?:[/span]
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 (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standards)



[span style='font-size:13pt;line-height:100%']Participation[/span]

You should participate in this thread if...:This thread is irrelevant to you if...:You should not participate in this thread if...:Things to keep in mind when discussing and drafting new standards:____________________________________


[span style='font-size:14pt;line-height:100%']Masstagger Scripts & Downloads:[/span]
Scripts, Downloads, etc. can be posted and found in the following thread:
http://www.hydrogenaudio.org/forums/index....showtopic=31592 (http://www.hydrogenaudio.org/forums/index.php?showtopic=31592)
[span style='font-size:8pt;line-height:100%']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.[/span]
_____________________________________


[span style='font-size:15pt;line-height:100%']List of agreed tag-standards:[/span]

[span style='font-size:13pt;line-height:100%']FIRST_PLAYED and LAST_PLAYED[/span]

Basics:Reasons for agreeing on this scheme:Updated playcounter-plugin here:
Download (binary & sourcecode) (http://pelit.koillismaa.fi/plugins/tagging.php#125)

Code snippets (for foobar 0.8-0.9):
Code: [Select]
// 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: [Select]
// 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: [Select]
// display only the date of last_played (without reformatting)
$left(%last_played%,10)

Code: [Select]
// 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__________________________________________


[span style='font-size:13pt;line-height:100%']ALBUM ARTIST[/span]

Basics:Reasons for agreeing on this scheme:Code snippets (for foobar 0.9):
These make use of "field-remappings" for code-simplifycation!
Code: [Select]
// check if an album is V.A.
$if($meta_test(album artist),$puts(album_is_va,1))

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

Code: [Select]
// 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: [Select]
// 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__________________________________________


[span style='font-size:13pt;line-height:100%']RATING and ALBUM RATING[/span]

Basics:Reasons for agreeing on this scheme:Code snippets (for foobar 0.8-0.9):
Code: [Select]
// star-rating (single-color version)
$rgb(200,0,0)
$repeat(*,%rating%)


Code: [Select]
// 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__________________________________________


[span style='font-size:13pt;line-height:100%']STYLE[/span]

Basics:Reasons for agreeing on this scheme:Code snippets:
Code: [Select]
// To display the styles of a track,
// simple put the following somewhere...
%style%


Adoption-Status: early-adoption stage
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 20:57:09
I originally posted this in the Navigator Suite thread, before I was aware standardization had its own thread.  Cut-n-paste:

Quote
Quote
Quote
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
[a href="index.php?act=findpost&pid=273510"][{POST_SNAPBACK}][/a]


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).
[a href="index.php?act=findpost&pid=273522"][{POST_SNAPBACK}][/a]
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 21:00:57
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.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 21:03:03
Quote
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.
[a href="index.php?act=findpost&pid=273525"][{POST_SNAPBACK}][/a]


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.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 21:04:49
Quote
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.
[a href="index.php?act=findpost&pid=273527"][{POST_SNAPBACK}][/a]


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
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 21:05:18
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.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 21:09:58
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.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 21:16:05
Quote
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.
[a href="index.php?act=findpost&pid=273532"][{POST_SNAPBACK}][/a]


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
:/
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 21:21:42
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".
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 21:30:21
Quote
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.

Quote
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".
[a href="index.php?act=findpost&pid=273538"][{POST_SNAPBACK}][/a]


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.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 21:35:05
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)?
Title: Tag-standards In Plugins<->formatting
Post by: mazy on 2005-02-14 22:15:20
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 ...
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 22:23:04
Quote
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 ...
[a href="index.php?act=findpost&pid=273564"][{POST_SNAPBACK}][/a]


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).
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 22:27:40
Whatever standard gets agreed upon, is Phi (or someone) available to update the playcount component to default to that standard?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 22:31:20
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?
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 22:35:52
Quote
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?

Quote
Does playlistgen treat "." as a decimal-seperator for numbers?
[a href="index.php?act=findpost&pid=273575"][{POST_SNAPBACK}][/a]


Brilliant! 

2005.02.14.17.36.00
Title: Tag-standards In Plugins<->formatting
Post by: picmixer on 2005-02-14 22:39:52
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%)".
Title: Tag-standards In Plugins<->formatting
Post by: mazy on 2005-02-14 22:42:49
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 ...
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 22:43:34
Quote
Quote
Does playlistgen treat "." as a decimal-seperator for numbers?
[a href="index.php?act=findpost&pid=273575"][{POST_SNAPBACK}][/a]


Brilliant! 

2005.02.14.17.36.00
[a href="index.php?act=findpost&pid=273576"][{POST_SNAPBACK}][/a]


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

:/
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 22:49:44
Quote
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 ...
[a href="index.php?act=findpost&pid=273579"][{POST_SNAPBACK}][/a]


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.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 22:53:38
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: [Select]
// 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
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 22:58:07
Quote
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: [Select]
$if(
$or(%album artist%,$strstr($lower($replace(%_path%,'.',$char(),' ',$char(),'_',$char())),'\va-')),
$puts(album_is_va,1)
)

[a href="index.php?act=findpost&pid=273586"][{POST_SNAPBACK}][/a]


Supporting both is of course a good idea, but if you were to prescribe a standard what would it be?
Title: Tag-standards In Plugins<->formatting
Post by: picmixer on 2005-02-14 23:04:35
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: [Select]
$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: [Select]
$if2(%album artist%,%artist%)
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 23:10:07
Quote
For me personally however
Code: [Select]
$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: [Select]
$if2(%album artist%,%artist%)

[a href="index.php?act=findpost&pid=273590"][{POST_SNAPBACK}][/a]


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.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 23:13:59
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.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 23:16:14
Quote
Maybe it's time for "common users" voicing their opinion on this issue.
[a href="index.php?act=findpost&pid=273593"][{POST_SNAPBACK}][/a]


Poll thread?

[edit]

2005-02-14_18:19:00

?

[/edit]
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-14 23:22:54
I already asked users for their VA-behaviour in another thread..... so, creating a new one would probably just be a duplicate.

http://www.hydrogenaudio.org/forums/index....c=22183&hl=mark (http://www.hydrogenaudio.org/forums/index.php?showtopic=22183&hl=mark)

The timestamp is okay for me. The only question left is:
Do we create a completely new combined date-time tag? Or do we use the existing two tags with a different format?
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-14 23:36:01
Quote
The timestamp is okay for me. The only question left is:
Do we create a completely new combined date-time tag? Or do we use the existing two tags with a different format?
[a href="index.php?act=findpost&pid=273598"][{POST_SNAPBACK}][/a]


I'm repeating myself, but I think a new field is the way to go.  If we re-use PLAY_DATE, we'll still be doing all kinds of checks on it to guess its format.  The reliable consistency of a LAST_PLAYED field is very appealing, and while there will still be a lot of PLAY_DATE usage for a while, it will die down (especially if (a) the standard is incorporated into the playcount component and (b) some masstagger scripts for translating various common formats are made available.)
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 00:14:47
Gimme a night to sleep over it - but that of course shouldn't hold back others from voicing their opinion. After all, its not like i'm the final judge - i'm just the threadstarter and one of the formatting-string programmers, nothing more ;-)
Title: Tag-standards In Plugins<->formatting
Post by: krazy on 2005-02-15 03:52:31
Hmmm... coming in pretty late on the discussion here, but I'm with topdownjimmy on the timestamp issue.
IMHO if a user is playing around with the playcount plugin in their scripts then they probably wouldn't have much trouble figuring out a simple way to display a readable date, and the advantage of comparing values without having to parse the string to remove '-' or whatever is there. For example, personally I display the date '15 February 2005' so the raw value would still have to be processed.

With VA albums, mine are all under their own 'Various' folder, so i'm not sure about the standards suggested already... I guess it wouldn't be very hard to change this though.
Title: Tag-standards In Plugins<->formatting
Post by: ajax3 on 2005-02-15 08:01:18
Quote
With VA albums, mine are all under their own 'Various' folder, so i'm not sure about the standards suggested already... I guess it wouldn't be very hard to change this though.
[a href="index.php?act=findpost&pid=273654"][{POST_SNAPBACK}][/a]

maybe it could be one of two or one of three standarts because alot of people have all under their own 'Various' folder and not everyone has various artist in their tag
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-15 09:40:36
About VA, I agree about %album artist%, I think it's clear and widely adopted. Personally I use this tag, and I also use special folder names for various artists albums, but that's a personal approach and not what should be a 'standard' (the tag).

About playcount tag, maybe a single tag containing everything it's better, but about the format I don't know,as long as it allow sorting, queries in EPG and others that's fine. Personally I think that's always better to have an standard that would work between different plugins and not having to define it yourself, if you decide to go ahead and make an alternative format, it's your choice but you could always revert to something you know that's working in case that somethig don't work with your custom format. BTW, does someone knows what other players use as playcount fields? Or if there's a 'standard' playcount tag/metadata? It'll be wiser to adopt something cross-platform/players if possible 
Title: Tag-standards In Plugins<->formatting
Post by: foosion on 2005-02-15 10:05:18
May I point you to the specification for the date and time format in APEv2 tags (http://www.hydrogenaudio.org/musepack/klemm/www.personal.uni-jena.de/~pfk/mpp/sv8/time.html)? Perhaps this can help with the decision. It would also be very easy to extend the playlist generator with two keywords "BEFORE" and "AFTER" to compare values as strings, which would also compare dates in ISO 8601 format correctly. IMO "date AFTER 2001-11-11 AND date BEFORE 2000-02-16" looks nicer and is easier to read than "date GREATER 20011111 AND date LESS 20000216". Additionally, the first variant would even work, if the tag ("date" in this example) contains a time part as well.
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-15 10:59:59
I was away for a while when writing, and now both foosion and jkwarras has posted the kind of thoughts I hoped for, when suggesting a thread like this. To look to other tag formats and players is a good idea. Comments from people like foosion is also very valuable, so that we have opinons from every group of users.

Whether the name of the date/time tag is changed or not, isn't that important to me, as long as it's well thought through, and easy to tell new users what to do, to make things work. But, having the new one as the default tag in foo_playcount is crucial, I guess. If a user's current format outputs garbage, with a certain formatting, just tell him where to look for an explanation for how things should be done/used. Some masstagger scrips that would reformat common, current formats, could also be provided. But, the way formatting devs extract info from the "new tag", will of course affect how successful the latter is (at least one should avoid the use of $right() ).

I also agree with picmixer regarding the use of %album artist% for VA tagging. Nowadays I use the same approach as him, but earlier I used %various%=yes, because I didn't have any experience with custom tags when I started. I later changed to %album artist% as it's more efficient, and has widespread use. This is one of the reasons I suggested this discussion in the first place, because when you're new to custom tags, you might not have a good reason to choose one format over the other, and hence a guideline like this could be useful. If (new) devs want to make a formatting that as many as possible can use, then following a guideline for the prefered way of doing things, can be useful. No need for everyone to reinvent the wheel.

My goal with this discussion was not to make a string that supports every possible way to mark VA albums and such. Been there, done that, and now I prefere more efficient strings. It's the users that should adopt to widespread "standards", instead of requiring every formatting to support every bizzare tag/naming scheme.
But, the following might be a good compromise: For tagging, I think %album artist% should be the one and only, but one user definable "marker" like 'VA - ', would be nice for people that don't like custom tags. When used with Columns UI, the usage in the formatting itself would be pretty much the same as when using %album artist% alone:

In Global:
Code: [Select]
$puts(va_marker,'VA - ')

various=$if2(%album artist%,$if($strstr(%_path%,$get(va_marker)),'Various Artists'))
The first line would be easy to change to suit a particular user in a "config part".

Artist/album column (when using album mode):
Code: [Select]
$if2(%_various%,%artist%)

Title column:
Code: [Select]
$if(%_various%,%artist%' - ')


If this isn't enough, you could always make the contents of the va_marker conditional in case more than one marker is needed (for a given users special needs). E.g. like this (not the best example, but anyway):
Code: [Select]
$puts(va_marker,$if($strstr(%_path%,'-OST-'),'-OST-','VA - '))


I guess that's enough for now...

Edit: nothing important, just added some "air"...
Edit2: I need some coffee. The code for the "artist/album" column isn't that useful, and you'll probably decide it's contents in the global config, and hence you need $puts() $get() as %_various% can be used there.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-15 12:09:46
Quote
May I point you to the specification for the date and time format in APEv2 tags (http://www.hydrogenaudio.org/musepack/klemm/www.personal.uni-jena.de/~pfk/mpp/sv8/time.html)? Perhaps this can help with the decision. It would also be very easy to extend the playlist generator with two keywords "BEFORE" and "AFTER" to compare values as strings, which would also compare dates in ISO 8601 format correctly. IMO "date AFTER 2001-11-11 AND date BEFORE 2000-02-16" looks nicer and is easier to read than "date GREATER 20011111 AND date LESS 20000216". Additionally, the first variant would even work, if the tag ("date" in this example) contains a time part as well.
[a href="index.php?act=findpost&pid=273704"][{POST_SNAPBACK}][/a]


Given that, I don't think there are any reasons left not to adopt the explicit APE standard:
2005-02-15 07:09:00

edit: jkwarras brings up a good point about sorting...how will that work with the above format?

Now...thoughts on field name?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 12:34:27
Unless some good other existing fieldname does exist, imho your proposed LAST_PLAYED sounds good. Its meaning isn't restricted to date and time, its short(so easy to type in when manually adding tags), its easy to understand. It's just catchy. The only thing interesting to know - since it sounds so obvious - is if any other players do exist which use this tag-name, and what they do write into it. However, if some unknown exotic player does exist which uses it for different purposes, then we can still verify it with a very low amount of code.

So, i'd say unless some high-profile app uses this tag for other purposes, i'd say lets go for it.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: krazy on 2005-02-15 12:54:04
Quote
May I point you to the specification for the date and time format in APEv2 tags (http://www.hydrogenaudio.org/musepack/klemm/www.personal.uni-jena.de/~pfk/mpp/sv8/time.html)? Perhaps this can help with the decision. It would also be very easy to extend the playlist generator with two keywords "BEFORE" and "AFTER" to compare values as strings, which would also compare dates in ISO 8601 format correctly. IMO "date AFTER 2001-11-11 AND date BEFORE 2000-02-16" looks nicer and is easier to read than "date GREATER 20011111 AND date LESS 20000216". Additionally, the first variant would even work, if the tag ("date" in this example) contains a time part as well.
[a href="index.php?act=findpost&pid=273704"][{POST_SNAPBACK}][/a]

Ape standard sounds good, but could this BEFORE and AFTER also apply to TAGZ? I guess this would be a feature request for fb2k 0.9
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 13:12:14
Quote
Ape standard sounds good, but could this BEFORE and AFTER also apply to TAGZ? I guess this would be a feature request for fb2k 0.9

I think it shouldn't be BEFORE and AFTER based on date only. Instead, a generic function which compares strings based on alphanumeric _sorting_ would offer much more possibilities.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: foosion on 2005-02-15 14:58:49
I actually had planned on adding BEFORE and AFTER for string comparison before this thread came up, and those were the best names I could come up with so far. Incidently - or rather by design of the ISO 8601 standard - string comparison also works for dates written in this format.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-15 15:16:36
What about simple sorting?  Will clicking on a column header for %LAST_PLAYED%, in the currently proposed format (APE standard) sort correctly?

It occurs to me that those of use who use %ADDED% will probably also want to convert that field to the new standard, but it escapes me now who wrote that %ADDED% component...
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-15 15:47:20
Quote
It occurs to me that those of use who use %ADDED% will probably also want to convert that field to the new standard, but it escapes me now who wrote that %ADDED% component...
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=273780")

It was wizard:
[a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=29050&hl=foo_filedate]http://www.hydrogenaudio.org/forums/index....hl=foo_filedate[/url]
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 16:15:06
Quote
What about simple sorting? Will clicking on a column header for %LAST_PLAYED%, in the currently proposed format (APE standard) sort correctly?


Yes, it does. Even if it wouldn't then you could still create a custom-sort string.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-15 16:17:50
Quote
Quote
What about simple sorting? Will clicking on a column header for %LAST_PLAYED%, in the currently proposed format (APE standard) sort correctly?


Yes, it does. Even if it wouldn't then you could still create a custom-sort string.
[a href="index.php?act=findpost&pid=273798"][{POST_SNAPBACK}][/a]


True, but there's been so much talk of making things easy for "regular" users I thought it was worth considering.  Guess it's irrelevant though.

LAST_PLAYED = 2005-02-15 11:17:00
Title: Tag-standards In Plugins<->formatting
Post by: foosion on 2005-02-15 16:38:26
Quote
What about simple sorting?  Will clicking on a column header for %LAST_PLAYED%, in the currently proposed format (APE standard) sort correctly?[a href="index.php?act=findpost&pid=273780"][{POST_SNAPBACK}][/a]
Yes.
Title: Tag-standards In Plugins<->formatting
Post by: desigrid on 2005-02-15 21:13:30
FWIW, I'm currently using PLAY_TIMESTAMP = 2005-02-15T11:17:00. The format of the timestamp is as per ISO 8601 (http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html#three). The only difference between this and the link foosion provided is the use of the T instead of a space to separate the date and time. I mentioned this not to add confusion to the issue, but since this is still in the discussion phase, I was wondering if the official ISO 8601 format be adopted instead?

As for the name of the tag itself, I am using PLAY_TIMESTAMP because I wanted metadata related to the playback to be have a common initial identifier (I am using PLAY_COUNTER) and PLAY_LAST_PLAYED just sounds wierd .

While on this subject of tag names, I am curious as to why ALBUM ARTIST is being used by the majority of foobar2000 users as opposed to ALBUM_ARTIST OR ALBUMARTIST? I've noticed that most other tag names either omit separators altogether or use underscores to separate words (TRACKNUMBER, PLAY_COUNTER, etc.).
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-15 21:33:28
Quote
FWIW, I'm currently using PLAY_TIMESTAMP = 2005-02-15T11:17:00. The format of the timestamp is as per ISO 8601 (http://www.iso.org/iso/en/prods-services/popstds/datesandtime.html#three). The only difference between this and the link foosion provided is the use of the T instead of a space to separate the date and time. I mentioned this not to add confusion to the issue, but since this is still in the discussion phase, I was wondering if the official ISO 8601 format be adopted instead?

The only difference I see is that foosion's link is to a tag standard, while yours is to the actual ISO standard.  I'd rather be congruent with APE usage than with official ISO usage.
Quote
As for the name of the tag itself, I am using PLAY_TIMESTAMP because I wanted metadata related to the playback to be have a common initial identifier (I am using PLAY_COUNTER) and PLAY_LAST_PLAYED just sounds wierd .

Makes sense.  Maybe PLAY_STAMP for economy and because it's not just time.
edit: or PLAY_LAST ?
Quote
While on this subject of tag names, I am curious as to why ALBUM ARTIST is being used by the majority of foobar2000 users as opposed to ALBUM_ARTIST OR ALBUMARTIST?[a href="index.php?act=findpost&pid=273903"][{POST_SNAPBACK}][/a]

Stigma. 
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 21:53:52
LAST_PLAYED gets my vote for being catchy and easy to recognize. It's the kind of "name" which gets adopted.

edit: i don't think this tag has to fit into the playcount tag-scheme..... it may be usefull for other plugins as well in the future. So, i'd say its a generic tag.
Title: Tag-standards In Plugins<->formatting
Post by: NEMO7538 on 2005-02-15 22:33:05
Personnally i prefer to have VA identified by the directory structure, like :
Normal albums dir : Artist - Date - Album
VA albums dir : Album - Date

So i use
$if($strcmp($strstr($directory(%_path%,1),%artist%),1),xxxx,yyyyy)

to distinguish.

Easier than retagging IMHO
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 22:35:40
Quote
Personnally i prefer to have VA identified by the directory structure, like :
Normal albums dir : Artist - Date - Album
VA albums dir : Album - Date

So i use
$if($strcmp($strstr($directory(%_path%,1),%artist%),1),xxxx,yyyyy)

to distinguish.

Easier than retagging IMHO
[a href="index.php?act=findpost&pid=273931"][{POST_SNAPBACK}][/a]


But impossible to reliably detect in a formatting-string which is meant for general usage.
For example, i already support all kinds of weird methods in "Navigator" to detect VAs - but i would never support your proposal because it would result in all kinds of false-alarms with the majority of people.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-15 22:39:31
Quote
LAST_PLAYED gets my vote for being catchy and easy to recognize. It's the kind of "name" which gets adopted.

edit: i don't think this tag has to fit into the playcount tag-scheme..... it may be usefull for other plugins as well in the future. So, i'd say its a generic tag.
[a href="index.php?act=findpost&pid=273920"][{POST_SNAPBACK}][/a]


I sympathise with the desire to make similar all tags that get updated with each play.  But I do like the sound of LAST_PLAYED too.  I'm torn.  Color me indifferent.  :/
Title: Tag-standards In Plugins<->formatting
Post by: NEMO7538 on 2005-02-15 22:40:36
Quote
But impossible to reliably detect in a formatting-string which is meant for general usage.
For example, i already support all kinds of weird methods in "Navigator" to detect VAs - but i would never support your proposal because it would result in all kinds of false-alarms with the majority of people.
[a href="index.php?act=findpost&pid=273934"][{POST_SNAPBACK}][/a]


obviously it is only usefull if you adhere to the solution; but retagging is painfull IMO, so I think so using this scheme is more convenient
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 22:43:03
Quote
Quote
But impossible to reliably detect in a formatting-string which is meant for general usage.
For example, i already support all kinds of weird methods in "Navigator" to detect VAs - but i would never support your proposal because it would result in all kinds of false-alarms with the majority of people.
[a href="index.php?act=findpost&pid=273934"][{POST_SNAPBACK}][/a]


obviously it is only usefull if you adhere to the solution; but retagging is painfull IMO, so I think so using this scheme is more convenient
[a href="index.php?act=findpost&pid=273939"][{POST_SNAPBACK}][/a]


Do you really think, that its easier to enforce a directory-structure on users, than adding a tag? Think about it.
Title: Tag-standards In Plugins<->formatting
Post by: NEMO7538 on 2005-02-15 22:47:09
tagging is so slow with ID3V2 !
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 22:51:15
Quote
tagging is so slow with ID3V2 !
[a href="index.php?act=findpost&pid=273943"][{POST_SNAPBACK}][/a]


Do you propose that we limit the decision of which method to use, by the mp3-format and the fact that there is a bug in fb2k which will be fixed in the next version?
Title: Tag-standards In Plugins<->formatting
Post by: NEMO7538 on 2005-02-15 23:05:19
Quote
Do you propose that we limit the decision of which method to use, by the mp3-format and the fact that there is a bug in fb2k which will be fixed in the next version?
[a href="index.php?act=findpost&pid=273944"][{POST_SNAPBACK}][/a]


I'll be happy with this new version but my undestanding is that a "standard" would only be relevant for formatting strings ... and I have mines already
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 23:06:25
Then nothing will change for you anyways. I've added a clarification to the first post of this thread - please give it a read.
Title: Tag-standards In Plugins<->formatting
Post by: NEMO7538 on 2005-02-15 23:16:44
Quote
Then nothing will change for you anyways. I've added a clarification to the first post of this thread - please give it a read.
[a href="index.php?act=findpost&pid=273952"][{POST_SNAPBACK}][/a]


ok
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-15 23:49:02
Just listening to music from my iPod here, and realized the foo_pod component has its own timestamp format in IPOD_LAST_PLAYED_TIME.  I have no idea how foo_pod works, or where that data comes from, etc. etc., but I thought I'd mention it since it seems relevant.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-15 23:54:32
........ not foo_pod again.

Does someone know when this tag gets updated?
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-16 12:24:29
Quote
Does someone know when this tag gets updated?
[a href="index.php?act=findpost&pid=273971"][{POST_SNAPBACK}][/a]

AFAIK, only when the song is played completely. But it's not really a tag, it's on the ipod database (as rating). foo_pod doesn't write anything to the file.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-16 13:49:31
So, the "tag" is mostly meant for use with the ipod only?
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-16 14:07:00
Can we come to a consensus on the time/date stamp issue?

I think everyone can agree to:

LAST_PLAYED = 2005-02-16 09:04:00

-adheres to APE date/time standard
-straighforward field name
-sortable
-immediately legible

The only other contender in my mind is PLAY_LAST for the field name, but the only motivation for this is a kind of abstract desire for field name consistency, nothing practical (as far as I know).
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-16 14:29:03
Quote
Can we come to a consensus on the time/date stamp issue?

I think everyone can agree to:

LAST_PLAYED = 2005-02-16 09:04:00

-adheres to APE date/time standard
-straighforward field name
-sortable
-immediately legible[a href="index.php?act=findpost&pid=274142"][{POST_SNAPBACK}][/a]
Looks perfect to me. Good name, easy to understand the contents, sortable without any modification.

Quote
The only other contender in my mind is PLAY_LAST for the field name, but the only motivation for this is a kind of abstract desire for field name consistency, nothing practical (as far as I know).[a href="index.php?act=findpost&pid=274142"][{POST_SNAPBACK}][/a]
The name sounds like a custom tag to ensure that a track is played after all other tracks, or something.

I would like a tag that has an obvious name (e.g. LAST_PLAYED), not a name I would have to deciper every time I see it.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-16 14:40:55
Same as upnorth.
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-16 16:32:02
Quote
So, the "tag" is mostly meant for use with the ipod only?
[a href="index.php?act=findpost&pid=274134"][{POST_SNAPBACK}][/a]

I guess so. It's also used by itunes and others players supporting the ipod, so I think it's only a ipod 'tag'. But, you should ask Aero (foo_pod developper) to be sure 

BTW, I also agree about the playtime format suggested.
Title: Tag-standards In Plugins<->formatting
Post by: Killmaster on 2005-02-16 16:59:52
Quote
Can we come to a consensus on the time/date stamp issue?

I think everyone can agree to:

LAST_PLAYED = 2005-02-16 09:04:00

-adheres to APE date/time standard
-straighforward field name
-sortable
-immediately legible

The only other contender in my mind is PLAY_LAST for the field name, but the only motivation for this is a kind of abstract desire for field name consistency, nothing practical (as far as I know).
[a href="index.php?act=findpost&pid=274142"][{POST_SNAPBACK}][/a]


Should we include time zone as well, or is that overkill? I currently use the play_stamp standard that someone came up with the foo_playcount thread, it looks like this:

2005-02-16T08:51:43+08:00
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-16 17:12:53
Quote
Quote
Can we come to a consensus on the time/date stamp issue?

I think everyone can agree to:

LAST_PLAYED = 2005-02-16 09:04:00

-adheres to APE date/time standard
-straighforward field name
-sortable
-immediately legible

The only other contender in my mind is PLAY_LAST for the field name, but the only motivation for this is a kind of abstract desire for field name consistency, nothing practical (as far as I know).
[a href="index.php?act=findpost&pid=274142"][{POST_SNAPBACK}][/a]


Should we include time zone as well, or is that overkill? I currently use the play_stamp standard that someone came up with the foo_playcount thread, it looks like this:

2005-02-16T08:51:43+08:00
[a href="index.php?act=findpost&pid=274224"][{POST_SNAPBACK}][/a]


Overkill.  The reason a standard is being introduced isn't so that everyone can know exactly when any other person's file was last played, but to make string formatting universal for .fcs and other string coders.  It's acceptable for the information to be specific to the user, but the structure needs to be formalized.
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-16 17:13:51
Quote
Should we include time zone as well, or is that overkill? I currently use the play_stamp standard that someone came up with the foo_playcount thread, it looks like this:

2005-02-16T08:51:43+08:00[a href="index.php?act=findpost&pid=274224"][{POST_SNAPBACK}][/a]
Do you have an example of a situation when that would be useful?

Maybe we should consider adding location and weather info too? 
2005-02-16T18:12:39+01:00LNORWAY.WMostly Cloudy(+1C)

As you might have guessed, I think that would be overkill... 

Edit: If formatting strings use $substr() to extract info, it wouldn't matter what kind of info you append to the "standard" format...
Title: Tag-standards In Plugins<->formatting
Post by: ajax3 on 2005-02-16 17:24:48
Quote
Quote
Should we include time zone as well, or is that overkill? I currently use the play_stamp standard that someone came up with the foo_playcount thread, it looks like this:

2005-02-16T08:51:43+08:00[a href="index.php?act=findpost&pid=274224"][{POST_SNAPBACK}][/a]
Do you have an example of a situation when that would be useful?

Maybe we should consider adding location and weather info too? 
2005-02-16T18:12:39+01:00LNORWAY.WMostly Cloudy(+1C)

As you might have guessed, I think that would be overkill... 

Edit: If formatting strings use $substr() to extract info, it wouldn't matter what kind of info you append to the "standard" format...
[a href="index.php?act=findpost&pid=274237"][{POST_SNAPBACK}][/a]

Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-16 17:25:36
LOL, i vote for also including the mood and a short blog-entry :-)

But i agree with upnorth..... if we make it clear that the beginning should contain the proposed format, but any additional info may be appended to it, then this would be no problem - not even when sorting.

edit: it may be a problem for verification-purposes - because you cannot check it with length anymore then. But i guess there may be other methods to verify it without depending on the total length. Just checking for the first dash and the ":" should already provide a quite robust verification.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-16 17:28:53
Quote
LOL, i vote for also including the mood and a short blog-entry :-)

But i agree with upnorth..... if we make it clear that the beginning should contain the proposed format, but any additional info may be appended to it, then this would be no problem - not even when sorting.

edit: it may be a problem for verification-purposes - because you cannot check it with length anymore then. But i guess there may be other methods to verify it without depending on the total length.
[a href="index.php?act=findpost&pid=274246"][{POST_SNAPBACK}][/a]


Awesomeness.

Sounds settled.  I'm going to put this in the wiki (for now?).
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-16 17:31:33
i'd say, enter a short WIP-note in the wiki. I'll write a short "script" in the first post about every agreed format + example-code. You can just take this script then, rephrase it with more nice words, and transfer it to the wiki.

edit: but for now, i'll do WIP in the kitchen  Will add the script later today.
Title: Tag-standards In Plugins<->formatting
Post by: desigrid on 2005-02-16 17:41:46
Quote
Can we come to a consensus on the time/date stamp issue?

I think everyone can agree to:

LAST_PLAYED = 2005-02-16 09:04:00
[a href="index.php?act=findpost&pid=274142"][{POST_SNAPBACK}][/a]


From a user's POV, I think this is fine. Although I initially suggested having a common initial identifier for metadata related to playback, I guess the majority do not concur on its practicality.

LAST_PLAYED is also starting to grow on me. Guess it's time for me to whip out my masstagger .
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-16 17:44:45
In wiki:
http://wiki.hydrogenaudio.org/index.php?ti...d_Tag_Standards (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000#Encouraged_Tag_Standards)

Also added an (empty) section to hold strings to convert popular PLAY_DATE and PLAY_TIME formats to this shiny new standard in masstagger.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-16 18:14:41
topdown: i would propose to create a new page for the tag-standards topic in the wiki. The amount of info including explanations and example-code will just become too big to place it on the frontpage.

Better just have a link on the frontpage with a small description below it why this may be interesting for users and devs.

Also, it may make sense to rename "accepted tag-standards" to "recommended tag-standards", because as it is, it may sound as if this means that foobar itself supports no other tag-formats.
Title: Tag-standards In Plugins<->formatting
Post by: Zurman on 2005-02-16 18:16:03
Great discussion about LAST_PLAYED
I used YYMMDD but I think I'll comply to this format...

About a totally different issue : how you guys tag classical music? It's been a problem for me since I started using foobar...
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-16 18:21:18
Quote
So, the "tag" is mostly meant for use with the ipod only?
[a href="index.php?act=findpost&pid=274134"][{POST_SNAPBACK}][/a]

Hmm...Firefox does odd things with this forum  (like losing posted replies)...
Ok back 'on topic', AFAIk this 'tag' is only used by and for music on the ipod. Other players like itunes uses it to sync their playcount PC database.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-16 18:23:06
@zurman:

Conductor and Performer are used by many people who listen to classical music. Thats not to say that i propose this scheme here - just something i noticed  On the other hand, you can always go the safe-route and put it into the comment-field
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-16 18:33:09
Quote
topdown: i would propose to create a new page for the tag-standards topic in the wiki. The amount of info including explanations and example-code will just become too big to place it on the frontpage.

Better just have a link on the frontpage with a small description below it why this may be interesting for users and devs.


Good point, but if it becomes a problem, we can always move it later.  A separate page would be kind of awkward at this point I think.

Quote
Also, it may make sense to rename "accepted tag-standards" to "recommended tag-standards", because as it is, it may sound as if this means that foobar itself supports no other tag-formats.
[a href="index.php?act=findpost&pid=274259"][{POST_SNAPBACK}][/a]


Very true...I used "Encouraged Tag Standards"...a little more forceful.  Don't forget to change that link in the first post.



edit:  "Encouraged Tag Standards" or "Practiced Tag Standards"?


edit2: "Practiced Tag Standards"...I like it, we don't need another debate about something THAT trivial. 
Title: Tag-standards In Plugins<->formatting
Post by: Zurman on 2005-02-16 18:55:07
Quote
@zurman:

Conductor and Performer are used by many people who listen to classical music. Thats not to say that i propose this scheme here - just something i noticed  On the other hand, you can always go the safe-route and put it into the comment-field
[a href="index.php?act=findpost&pid=274263"][{POST_SNAPBACK}][/a]

I also use CONDUCTOR = Herbert von Karajan
PERFORMER = Hélène Grimmaud (Piano) (with multiple fields if multiple performers)
ENSEMBLE = Wiener Philharmoniker

OPUS = 1006
OPUS NAME = BWV

Those fields are OK.

My problems are : what to put in ALBUM? When several works are in the same CD, what do I put in TITLE?

And also, I don't know how to organize the files on my HD... For rock/pop music I use ARTIST\(DATE) ALBUM\TRACKNUMBER. TITLE
or VARIOUS ARTISTS\(DATE) ALBUM\TRACKNUMBER. ARTIST - TITLE

But what can I do when there are several composers on the same CD?

Thanks for your own experience.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-16 19:29:50
@topdown:
Well, when i would read "Practiced Tag Standards" in the wiki as a newbie, i wouldn't have the slightest clue what this could be - could it be some kind of cult or religion? ;-)

first post updated with last_played
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-16 19:40:24
Quote
@topdown:
Well, when i would read "Practiced Tag Standards" in the wiki as a newbie, i wouldn't have the slightest clue what this could be - could it be some kind of cult or religion? ;-)

first post updated with last_played
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=274277")


I'm quite pleased with this presentation:
[a href="http://wiki.hydrogenaudio.org/index.php?title=Foobar2000#Encouraged_Tag_Standards]http://wiki.hydrogenaudio.org/index.php?ti...d_Tag_Standards[/url]
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-16 19:43:42
@Zurman: I think guruboolez is the one you want to discuss tagging of classical music with. I'm sure a search will return some old posts where he explains how he's tagging his music. I rarely listen to classical myself, so that's all I can help you with.

@topdownjimmy: I agree with Lyx. And IMHO, "Encouraged Tag Standards" was quite good. But, "Practiced" is no worse than "HAK" and "Wiki" 
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-16 19:55:41
Quote
@topdownjimmy: I agree with Lyx. And IMHO, "Encouraged Tag Standards" was quite good. But, "Practiced" is no worse than "HAK" and "Wiki" 
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=274280")


Changed...is this about right?
[a href="http://wiki.hydrogenaudio.org/index.php?title=Foobar2000#Encouraged_Tag_Standards]http://wiki.hydrogenaudio.org/index.php?ti...d_Tag_Standards[/url]
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-16 23:30:03
"Navigator" now supports LAST_PLAYED.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-17 17:29:43
Proposal for the VA-issue:

Quote
[span style='font-size:13pt;line-height:100%']ALBUM ARTIST[/span]
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 in a V.A.-album has to contain this tag with the same value
- 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

<Masstagger-scripts here>

Code snippets:
Code: [Select]
// check if an album is V.A.
$if(%album artist%,$puts(album_is_va,1))

Code: [Select]
// For sorting by artist in an album-context replace %artist% - %album% with:
$if2(%album artist%,%artist%) - %album%

Code: [Select]
// singlemode display without %album artist%-support
[%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 - depends on taste
[$if2(%album artist%,%artist%) - ][%album% - ]$if(%album artist%,[%artist% - ])[%title%]

Code: [Select]
// How to easily integrate %album artist% into an albummode-display:

// in the albummode-column, replace %artist% with:
$if2(%album artist%,[%artist%])

// in the title-column, replace %title% with:
$if(%album artist%,[%artist% - ])[%title%]


Since the "standard" is just the smallest common ground, devs would still be free to additionally support other methods(just like with all tag-standards here).

Opinions?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-17 18:15:51
Quote
Opinions?
[a href="index.php?act=findpost&pid=274551"][{POST_SNAPBACK}][/a]

Self-explanatory. Very nice 
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-17 22:57:30
Most other folks already mentioned before that they agree with the ALBUM ARTIST scheme. So, i guess the above is just too obvious to need additional agreement ;-) So i'll just add it to the list of agreed tag standards tomorrow unless someone comes up with good reasons against it or a better approach.


Proposal about the playcount-plugin and LAST_PLAYED:
Instead of requiring tboehrer to officially update his plugin (of course he's welcome to do it anyways) how about the following idea...

Someone just pick the source, and:
- change the default to the LAST_PLAYED proposal
- remove the possibility to enter a custom format
- call the modified plugin "play_count_extended"
- upload it to the 3rd-party plugins site

To make the additional "extended" deserved, motivate people to use it, and give TAGZ-coders some nice new possibilities, we add another feature to the plugin:
- when a track reaches the defined playback-position to update it, and there is no LAST_PLAYED-tag there yet, then it also adds second tagfield called FIRST_PLAYED to it.
- this tag follows the same format as LAST_PLAYED

As to why this can be very interesting and useful, read this thread:
http://www.hydrogenaudio.org/forums/index....showtopic=31287 (http://www.hydrogenaudio.org/forums/index.php?showtopic=31287)
With having FIRST_PLAYED, LAST_PLAYED and PLAY_COUNT, you can do some interesting maths - like for example calculate the frequency of playback - which in turn can be interesting for rating purposes (not just in formatting-strings - this may also be interesting when someone creates an advanced meta-rating plugin - or just for easily determining the current favs... etc. etc.)

Anyone who thinks this may be a good idea?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: mazy on 2005-02-17 23:23:52
that's nice and well said, Lyx. though that would be ok for other strings, i still would like your string to continue supporting filename detection ...
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-17 23:30:46
It will continue to support that. But i will probably drop VA-detection via the artist-tag..... because when someone stores something like V.A. in the artist-tag, then he probably has the artist in the title-tag - then it will look okay in albummode anyways, even if the album is technically treated like a non-va album.
Title: Tag-standards In Plugins<->formatting
Post by: desigrid on 2005-02-18 03:42:10
Good proposal for the foo_playcount plugin Lyx. However, a few issues:

Quote
- remove the possibility to enter a custom format

By this statement, do you mean not allowing a user to change the tag name or the tag format?

Either way, I think both options should still be supported, but with a caveat emptor kind of statement included.

Firstly (if you mean tag format), the encouraged LAST_PLAYED tag format offers the possibility for users to append additional information to the standard format if they so desire. Removing the custom option prevents this possibility.

Secondly, IMO, unless both the tag name and format of LAST_PLAYED are as standard as the ReplayGain format, it would be better to allow users the option to customise. After all, much of foobar2000 is about its customisability isn't it?

Quote
- call the modified plugin "play_count_extended"

This is probably up to tboehrer or the person who is going to compile the source to decide, but perhaps the plugin should be called foo_playstats (or something similar)? After all, with the possible addition of FIRST_PLAYED, the plugin does not just count the number of times a song has been played.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-18 05:10:28
Quote
Quote
- remove the possibility to enter a custom format

By this statement, do you mean not allowing a user to change the tag name or the tag format?

Either way, I think both options should still be supported, but with a caveat emptor kind of statement included.

But you do realize, that the fact that it was customizable and used a non-internationally-neutral format by default, was the reason that we had to create a new standard in the first place?

Quote
Firstly (if you mean tag format), the encouraged LAST_PLAYED tag format offers the possibility for users to append additional information to the standard format if they so desire. Removing the custom option prevents this possibility.

It doesn't prevent it generally. It just prevents it in this plugin. But i see no problem in allowing the user to customize what kind of info gets appended to it. Not more.

Quote
Secondly, IMO, unless both the tag name and format of LAST_PLAYED are as standard as the ReplayGain format, it would be better to allow users the option to customise. After all, much of foobar2000 is about its customisability isn't it?

See my answer to the first quote. Allow that, and we soon have an ambigious tag-standard again. The replaygain-plugin also does not allow the user to customize its format for exactly the same reason. You mention the customizability of fb2k - the fact that the customizability of the current playcount-plugin prevented tagz-programmers from creating public formattings which make advanced use of the playcount plugin, was the reason why there was a need for a replacement-standard. So, while the customizability of the playcount-plugin increased possibilities for personal use, it prevented the majority of fb2k users(which aren't tagz-ninjas;) from getting the most out of it.

What i'm trying to say: customizability on first-sight, may be the opposite in the long run. Userfriendlyness on first-sight may turn into the opposite in the long run.

Quote
Quote
- call the modified plugin "play_count_extended"

This is probably up to tboehrer or the person who is going to compile the source to decide, but perhaps the plugin should be called foo_playstats (or something similar)? After all, with the possible addition of FIRST_PLAYED, the plugin does not just count the number of times a song has been played.

Thats right - and if this would be a completely new and unique plugin then i would agree - but what you're leaving out of your quotation is that the purpose of this plugin is to replace the play_count plugin - and that building on the popularity of the play_count plugin causes attention to exactly those users which we want for adoption. Thus, users who search for the play_count plugin will directly also find this plugin.

Besides, doesn't the word "extended" express that it is an extended version of the play_count plugin(which is exactly what would be the case if FIRST_PLAYED would be added to it)?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: desigrid on 2005-02-18 06:02:21
Quote
But you do realize, that the fact that it was customizable and used a non-internationally-neutral format by default, was the reason that we had to create a new standard in the first place?

I do not disagree with the proposal to have a non-ambigious format by default. However, my main concern about the lack of customisability is how it might potentially render the component unusable in future. A perfect example exists now. With this new encouraged tag name and format, a user can immediately comply by changing the formatting his/herself, instead of waiting for someone to re-compile the component. If the encouraged format were to somehow change in future (hopefully not), having the component hard-coded with pre-formatted values would render the component non-compliant with the new format.

Furthermore, by setting the default to the non-ambigious format and having a statement to explain why it is in this particular format will probably deter users from changing it unless he/she has personal reasons to.

Quote
Thats right - and if this would be a completely new and unique plugin then i would agree - but what you're leaving out of your quotation is that the purpose of this plugin is to replace the play_count plugin - and that building on the popularity of the play_count plugin causes attention to exactly those users which we want for adoption. Thus, users who search for the play_count plugin will directly also find this plugin.

Besides, doesn't the word "extended" express that it is an extended version of the play_count plugin(which is exactly what would be the case if FIRST_PLAYED would be added to it)?

I agree. Guess I was just being a little frivolous with my suggestion . After all, I have experienced confusion when confronted with differently named components with similar functions by different authors.

Perhaps the best option would be for tboehrer to update his component. Casual users of the component would then most probably upgrade when they know a new version exists.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-18 06:17:20
Quote
I do not disagree with the proposal to have a non-ambigious format by default. However, my main concern about the lack of customisability is how it might potentially render the component unusable in future. A perfect example exists now. With this new encouraged tag name and format, a user can immediately comply by changing the formatting his/herself, instead of waiting for someone to re-compile the component. While this is an encouraged format now, it may not be in future.

We have a cause and effect problem here. The fact that it was customizable in that regard was the cause that customization became necessary for public use :-)

Another thing: guess why its now possible for everyone who knows C to change the plugin? Oh, and - from what i have heard a few days ago from a post by peter, it does not seem unprobable at all that a large amount of all current fb2-plugins may become unusable in the next fb2k-version - but again, thats no problem - because they're open-source.


Quote
Furthermore, by setting the default to the non-ambigious format and having a statement to explain why it is in this particular format will probably deter users from changing it unless he/she has personal reasons to.

How many posts do we have in these forums from people who ask for support for Kernel-Streaming-Output and why it doesn't work?

Users don't care about such things. The only thing you've won with such notices is that you can say "i'm not responsible cause i have warned you" - especially with a geeky target-audience like the foobar-community.

Quote
Perhaps the best option would be for tboehrer to update his component. Casual users of the component would then most probably upgrade when they know a new version exists.

Yes, i agree - the only problem might be that the majority of users who used playcount before won't notice any change because their previous settings would overwrite the new default. Then again, i guess there for sure is a function for plugins to reset their configs.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: desigrid on 2005-02-18 06:28:24
Quote
We have a cause and effect problem here. The fact that it was customizable in that regard was the cause that customization became necessary for public use :-)

Another thing: guess why its now possible for everyone who knows C to change the plugin? Oh, and - from what i have heard a few days ago from a post by peter, it does not seem unprobable at all that a large amount of all current fb2-plugins may become unusable in the next fb2k-version - but again, thats no problem - because they're open-source.

While I am still not convinced why the component should be hard-coded with pre-formatted settings (power to the user ), I'm going to give in with regards to this issue. My main concern has been voiced and I'll leave it up to whoever is going to update the component to decide .
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-18 06:31:42
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.
Title: Tag-standards In Plugins<->formatting
Post by: Silverbolt on 2005-02-18 07:03:39
This is sounding good (though ALBUM ARTIST's lone space seems protruding). Too bad FIRST_PLAYED would be useless on existing tracks as well (less you start counting from scratch). Any opinions on PLAY_COUNTER vs. PLAY_COUNT? (ah, poor Matroska (http://www.matroska.org/technical/specs/tagging/index.html) guys).
Title: Tag-standards In Plugins<->formatting
Post by: desigrid on 2005-02-18 09:14:56
Quote
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 .
Title: Tag-standards In Plugins<->formatting
Post by: stroke on 2005-02-18 11:17:34
and now for something completely different

what about standardising some more tags. i'm never quite sure:
- where to place featuring artists,
- how to differentaiate featuring from duet,
- how to tag albums consisting of several discs,
- how to indicate bonus & hidden tracks
- etc.

i guess  that would allow for even more precise formatting.
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-18 12:00:24
Quote
- where to place featuring artists[a href="index.php?act=findpost&pid=274756"][{POST_SNAPBACK}][/a]
Recently discussed in another thread (or this, can't remember). Anyway, I like to put them in parenthesis in the title. As I said in the other thread, dimming the display of text in parenthesis, is one of the things I like to do to enhance readability.

Quote
how to differentaiate featuring from duet[a href="index.php?act=findpost&pid=274756"][{POST_SNAPBACK}][/a]
Rarely a problem for me, but it has happened that I've been wondering. If the whole album is by a specific artists, I keep that artist in the ARTIST tag, and put the rest in parenthesis.

Quote
how to tag albums consisting of several discs[a href="index.php?act=findpost&pid=274756"][{POST_SNAPBACK}][/a]
I use DISC and DISCNAME (if any), and that works very well for me. I give all discs the same ALBUM tag, as that makes it look better in the album list.

Quote
how to indicate bonus & hidden tracks[a href="index.php?act=findpost&pid=274756"][{POST_SNAPBACK}][/a]
I do the same as with "feat", append "(Bonus track)" to the title.

The parenthesis approach keeps things compatible with other players, in the sense that it doesn't rely on custom tags. But, as I use APEv2 and ID3v1, and only foobar2000, I guess that's not that important to me after all. I just want to keep the use of custom tags at a, to me, sensible level.

Another thing I've been thinking about is the single track issue. I personally use a SINGLETRACK tag, to mark tracks that should never be a part of an album in an album based formatting. For whole playlists I start that name with ".." (without quotes) to indicate that no tracks in that playlist should be formatted as albums. After I started to use the extended playlist generator, I abandoned the "-s-" prefix that I think I introduced myself at some point, as it decreased the readability too much for my taste (in the presets list). After musicmusic implemented the option to use formatting for playlist names, I remove this indicator in the playlist name, and just show single track playlists in a different color. Thanks, musicmusic! 


Btw: IMHO, this "standardising" can go too far, not that I think it has already, but I'm personally not going to adapt to "standards" that makes no sense for my usage. To me, that is what the customisability of fb2k is all about, namely that you don't have to adapt features (and keep features around) that doesn't suit you at all. Many of the things we might try to "standardise" is possibly very much dependant on the genre(s) you listen to and the way you listen to music (e.g. full albums vs. single tracks), hence making it difficult to agree upon.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-18 12:21:49
Quote
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.
[a href="index.php?act=findpost&pid=274724"][{POST_SNAPBACK}][/a]


What if FIRST_ and LAST_PLAYED are hardcoded, but there are optional tags you can add with whatever you want (I know a lot of people like the Julian date thing).

And, IMO the user should definitely be allowed to add something after the date and time in the hardcoded fields.  It's made explicit in the definition of this standard that something may be tacked onto the end of the field; how else would someone do that (except manually)?
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-18 12:49:30
I personally don't like the thought of hardcoding, and hence forcing a "standard" on people. IMHO, changing the default to an agreed upon "standard", is more than enough. Maybe a small note in the config page about why you should use this default, would be appropriate, but that's all. Some might have a good reason for using something other than this "standard".

I admit I didn't consider the problem of changing the default at first, and hence the need to change the name of the plugin to avoid confusion. But, making another version with hardcoded fields doesn't sound like the ideal solution. I think a new extended version with a new "standardized" default, and increased number of configurable fields (from the current two), would do.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-18 19:14:39
Adjusted proposal from me:

Plugin tag-configuration is clearly seperated into standard and unsupported custom-options
Quote
<previous song-position when tags get updated option>

[checkbox checked] Use new LAST_PLAYED and FIRST_PLAYED tag-standard (supported by public formattings & plugins)

<indent>Append the following info after the standardized date & time:
<indent>FIRST_PLAYED: [inputfield empty]    LAST_PLAYED: [inputfield empty]

<indent>Remove the following fields when tags are updated(seperated with semicolons):
<indent>[inputfield containing "PLAY_DATE;PLAY_TIME"]

------visual-seperation--------

[checkbox unchecked] Use additional custom-fields (not supported by public formattings and plugins)
<indent>Field 1: [inputfield containing PLAY_DATE] Format: [inputfield containing default PLAY_DATE-format]
<indent>Field 2: [inputfield containing PLAY_TIME] Format: [inputfield containing default PLAY_TIME-format]


When the user enters FIRST_PLAYED or LAST_PLAYED into the custom fields and tries to save it, then a popup-window opens saying "This will break public formattings and plugins which make use of these tags. Are you sure that you want to do this?"  <YES/NO choice>


- Lyx

edit: added first_played and last_played blocking in the custom-fields
edit2: changing blocking-approach to scary grandma-eating message with yes/no choice.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-21 00:21:26
Hmm, can one interprete the absence of any reaction as an "nothing wrong with that - now who would grab play_count and implement it?" or as an "nah, that proposal is stupid - just let the user config everything"?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Aesir on 2005-02-21 01:58:38
(The opinion of a stupid end-user who sometimes has a clue)

I think hardcoding, or even having a scary warning window, is going a bit too far. The only reason that we (well, you developers) have the ability to even change the "standard" is because the playcount plugin easily allows for changing tagging behavior. What I think would be best is having it identical to the playcount plugin now, except having a warning underneath the default LAST_PLAYED tag that says something along the lines of "Warning: Changing this value may cause undesirable behavior" or something along those lines, and a button (this is the important part) somewere else labelled "Reset" (or something) that reverts the fields back to their default setup.

Hardcoding the values or having really scary (but annoying) windows really only helps for complete n00bs and morons (and lets face it, Foobar2000 really isn't appealing to that kind of crowd).
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-21 03:07:01
Quote
The only reason that we (well, you developers) have the ability to even change the "standard" is because the playcount plugin easily allows for changing tagging behavior.

Everything you wrote is a matter of opinion and point of view - but not the above, because it is not true.

The customizability was the reason why a new tag-standard became necessary(because plugin-authors and formatting-designers had to guess what format the user may have set - because it was customizable). The reason why a new tag-standard is possible is that play_count is open-source.

As i mentioned at the beginning, everything else is a matter of opinions, and mine may be wrong in some aspects.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Aesir on 2005-02-21 03:29:26
Quote
The customizability was the reason why a new tag-standard became necessary(because plugin-authors and formatting-designers had to guess what format the user may have set - because it was customizable). The reason why a new tag-standard is possible is that play_count is open-source.
[a href="index.php?act=findpost&pid=275507"][{POST_SNAPBACK}][/a]


Thats true, but not everyone is going to download a new plugin and install it. I'm more inclined to think that people are more likely to change their settings then download something new (although maybe I'm wrong  ). I kinda get the feeling most people are going to just ignore the new standard anyway (oh well, their loss  ).

Unless I'm mistaken, though, half the reason for a need for a change in standards was because the original "standard" (the defaults) was rather poor and made for bad sorting and only made sense in some regions. Thats why I think most people played around with their tags. (Heck, even I, before finding out about this new standard, used %M-%D-%y, which is the ultimate in lousy sorting  ).
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-21 09:00:50
Quote
Hmm, can one interprete the absence of any reaction as an "nothing wrong with that - now who would grab play_count and implement it?"
[a href="index.php?act=findpost&pid=275460"][{POST_SNAPBACK}][/a]

For me, it is. I mean, "nothing wrong with that - now who would grab play_count and implement it?"
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-02-21 16:38:58
Quote
While on this subject of tag names, I am curious as to why ALBUM ARTIST is being used by the majority of foobar2000 users as opposed to ALBUM_ARTIST OR ALBUMARTIST? I've noticed that most other tag names either omit separators altogether or use underscores to separate words (TRACKNUMBER, PLAY_COUNTER, etc.).
[a href="index.php?act=findpost&pid=273903"][{POST_SNAPBACK}][/a]


I do not use underscores in tag names, nor do I think that their use should be encouraged. Spaces are equally valid in field names, are somewhat less confusing to the end-user and are much easier to type. For the sake of clarity, for non tech-fields (ie. things other than %__replaygain_track_gain%, etc), I think the standard should be no underscores.

This is just my opinion, but I feel very strongly about it, if that means anything.  I feel strongly enough that I'll re-tag things with underscores to omit the underscores. On top of that, I use the "ALBUM X" format for various things, like "ALBUM COMMENT" if there's some critical information I feel is needed for the entire album or "ALBUM SUBTITLE" if there's some long subtitle that the album has that I don't want to clutter the ALBUM field with.
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-02-21 16:47:16
Quote
I do not use underscores in tag names, nor do I think that their use should be encouraged. Spaces are equally valid in field names, are somewhat less confusing to the end-user and are much easier to type. For the sake of clarity, for non tech-fields (ie. things other than %__replaygain_track_gain%, etc), I think the standard should be no underscores.

My thoughts exactly.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-02-22 02:33:45
Now that we have two set standards, we should keep going.  Next topic of discussion, Ratings.  Most people seem to use the %RATING% tag. For the data some (like me) use numbers (usually 0-5), some use symbols (*****), and others probably have their own standard.

I propose we continue to use the %RATING% tag, with any integer value.  This allows flexibilty in your ratings system (i.e. can display ratings as numbers, stars, or whatever you like), and keeps the tags clean.  If people want half ratings (like 4.5 "stars") they can use integers 0-10 and half their value.

Thoughts? What are other peoples systems?

On another issue (underscores), I don't think we can recommend LAST_PLAYED with an underscore and then go and recommend ALBUM ARTIST without an underscore
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-22 02:55:28
Quote
Proposal for the VA-issue:

Quote
[span style='font-size:13pt;line-height:100%']ALBUM ARTIST[/span]
- tag should only exist if an album contains various artists. It should NOT be created when an album does not contain various artists.

[a href="index.php?act=findpost&pid=274551"][{POST_SNAPBACK}][/a]


Yeah, it all makes sense, but I can't say I'm too happy about it...

I use ALBUM ARTIST for sort names as well, e.g., all my Beatles tracks have "The Beatles" in the ARTIST field and "Beatles, The" in ALBUM ARTIST field.

How does everyone else deal with sort names?

(note: I hope I don't have to point out that I don't really think my very peculiar usage of this tag should bear on any standard.  Just looking for advice to work around it.)
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-22 07:33:36
Quote
I use ALBUM ARTIST for sort names as well, e.g., all my Beatles tracks have "The Beatles" in the ARTIST field and "Beatles, The" in ALBUM ARTIST field.


Sounds like a tagz-job for a sorting-string. Search for "the" at the beginning of the artist/albumartist and then move it to the end. The problem is that this would only work in the playlist, but not in the playlist_gen unless you enter a really LONG string

You could fix the latter by adding a personal tag to files called "artist sorted" or something like that. Yes, its a dirty solution, but i currently dont know anything better.

- Lyx

edit: actually, there is a solution which involves alot of work. Write a masstagger-script which moves the at the beginning of artist/albumartist tags to the end. Then write a playlist-formatting codeblock which searches for ", the" at the end and moves it to the beginning. Then you wouldn't need any additional tags and could do everything with the existing fields.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-22 07:42:48
Quote
Now that we have two set standards, we should keep going.   Next topic of discussion, Ratings.  Most people seem to use the %RATING% tag. For the data some (like me) use numbers (usually 0-5), some use symbols (*****), and others probably have their own standard.

I propose we continue to use the %RATING% tag, with any integer value.  This allows flexibilty in your ratings system (i.e. can display ratings as numbers, stars, or whatever you like), and keeps the tags clean.  If people want half ratings (like 4.5 "stars") they can use integers 0-10 and half their value.


While i agree with the above, i someway have a feeling that the first_played and last_played thingie should maybe first get _implemented_ before we go on and define even more tag-standards. Otherwise we may end up with lots of unimplemented worthless zombie-tagstandards

Quote
On another issue (underscores), I don't think we can recommend LAST_PLAYED with an underscore and then go and recommend ALBUM ARTIST without an underscore
[a href="index.php?act=findpost&pid=275816"][{POST_SNAPBACK}][/a]


I think that implementation and easy-of-adoption is more important than being "correct". ALBUM ARTIST is already in widespread use - proposing the majority of users to retag their files to ALBUM_ARTIST would really be a standard which would seem to have been decided by folks who have lost contact to reality.

Essentially, we didn't decide the ALBUM ARTIST scheme - it was already decided upon by the majority of users beforehand - the only thing we did was giving something which was in practice already the standard an "official"-stamp. And that IMHO is pretty much the most optimal scenario how a standard could be agreed upon.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-22 08:36:19
Quote
Now that we have two set standards, we should keep going.   Next topic of discussion, Ratings.  Most people seem to use the %RATING% tag. For the data some (like me) use numbers (usually 0-5), some use symbols (*****), and others probably have their own standard.

I propose we continue to use the %RATING% tag, with any integer value.  This allows flexibilty in your ratings system (i.e. can display ratings as numbers, stars, or whatever you like), and keeps the tags clean.  If people want half ratings (like 4.5 "stars") they can use integers 0-10 and half their value.

Thoughts? What are other peoples systems?[a href="index.php?act=findpost&pid=275816"][{POST_SNAPBACK}][/a]
I use %trackrating% with integer values from 1 to 5. It would be easy enough to convert %trackrating% to %rating%, but it seems I also use the tag differently. I only rate good tracks, so my five levels are all different degrees of positive. Usually my usage isn't a problem, but it was when I tried topdownjimmy's "hotness" indicator code (if I rated a track "1", the hotness decreased compared to when it was unrated).

Anyway, I'm not going to change my usage, as I like the way the good tracks stands out with my approach, and find it easier to spot tracks/albums that needs rating, but if most people use %rating%, as I've been suspecting, I'm ready to switch at some point.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-02-22 08:58:17
Quote
I think that implementation and easy-of-adoption is more important than being "correct". ALBUM ARTIST is already in widespread use - proposing the majority of users to retag their files to ALBUM_ARTIST would really be a standard which would seem to have been decided by folks who have lost contact to reality.

Essentially, we didn't decide the ALBUM ARTIST scheme - it was already decided upon by the majority of users beforehand - the only thing we did was giving something which was in practice already the standard an "official"-stamp. And that IMHO is pretty much the most optimal scenario how a standard could be agreed upon.

- Lyx
[a href="index.php?act=findpost&pid=275881"][{POST_SNAPBACK}][/a]


Well, "LAST_PLAYED" isn't exactly a commonly used standard.  Perhaps that should be changed to "LAST PLAYED".  I just think uniformity accross the standards is fairly important (or whats the point in having standards at all).  In terms of rating, I only briefly looked at thread, and though activity had kinda died off since the first two got finalised.  Just trying to bring forth topics of discussion.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-22 09:09:16
Quote
(or whats the point in having standards at all).

IMHO, avoiding ambiguity and incompatibility.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-02-22 09:14:26
And what about consistancy?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-22 09:17:57
Play_count_extended plugin:
PLAY_COUNT, FIRST PLAYED, LAST PLAYED

Doesn't seem consistent to me.


Users already started to convert to the new agreed format. I'd say, leave it as it is for those fields - that still leaves the door open to follow a different approach with other fields.

Someway, i have a feeling that it may become difficult to find a consensus there. Some people prefer underscores, some people prefer spaces.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-22 09:21:34
Quote
Next topic of discussion, Ratings. 
[a href="index.php?act=findpost&pid=275894"][{POST_SNAPBACK}][/a]

Well, I think that the usage of rating depends a lot of personal preferences. As upNorth said he uses in a positive approach, I use it as a measure of quality of a song:

1) Bad song.
2) Bfffff.....
3) Good song (not too good, not too bad but it deserves to be played)
4) Really good song.
5) Awesome track.

[OT: So, it's not really a measure of 'how much I like it', because for that I use a custom %favorite% tag. If a database that could store personal info on a multiple user scenario I would use certainly %rating% and mark it as 5 would mean favorite)

I don't really see how we could agree on a rating standard scenario since it's so personal way of approaching your music. However, we can agree the format of the tag (i.e. integer in a 1-5 range)

I don't know if someone would also find it useful but maybe adding the timestamp of the rating would be useful, because let's say I would like a 'recently rated songs' playlist....oh, nevermind, I've just thought that this woud also require for a proper usage the ability of store succesive ratings of a track, which is a little overkill and need a database scenario (not a tag-file scenario).
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-02-22 09:24:18
The fact that PLAY_COUNT/ER isn't consistant has absolutely nothing to do with the standards being decided in this thread.  Change the Play_count_extended plugin if it doesn't follow the standards set here.  I'm not saying it won't be difficult to find a standard, to be honest I don't care whether we have underscores or not, as long as it is one or the other.

And as far as users converting to the new format, I would suggest very few have done so, compared to the number of people using the original play_count plugin.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-22 09:24:53
i agree with jkwarras. Trying to standardize personal rating-styles is a lost case. And maybe this is a good thing. But the format can for sure be defined - thats not very restricting on users, because only the "what" would be defined but not the "how".

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-02-22 09:34:34
I never really said we had to define the style, or what each rating means to each end user, only that we should use a %rating% tag and only integers.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-22 09:47:00
Quote
And as far as users converting to the new format, I would suggest very few have done so, compared to the number of people using the original play_count plugin.
[a href="index.php?act=findpost&pid=275907"][{POST_SNAPBACK}][/a]


You're right that probably more people still use the old format, than those who already use the new format. But don't underestimate the number of people who have already converted:

At the moment of this post, 60 people have intentionally downloaded the masstagger-scripts for conversion. Additionally, i bundle the masstagger scripts since v1.03 with navigator, which has seen aprox. 220 downloads since then. This makes for at least 280+ people who already have the masstagger scripts. Thats not counting people who just changed the format themselves.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-02-22 10:28:49
I still think for consistancy's sake, it should be one way or the other.  280+ people are quite capable of changing again.
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-22 10:45:16
Turning this into a pedantic underscore vs no underscore debate won't do any good, IMO. I agree that consistent use of underscores would be nice, but considering the widespread use of %ALBUM ARTIST%, I think no underscore is our only choice. So, how many established tags uses underscore? Is it really possible or desirable to try to change this, only to achieve consistency?

My main hope for this thread, was that the confusion would be reduced, no matter the case of it. Changing established tags just to remove an underscore, is something I would expect to cause more harm than good, even in the long run.

What I see as important, is to reduce inefficency, redundancy and "Lock in", and in the process of doing so, settle on some well thought through formats. The agreed upon (?) format of LAST_PLAYED (or LAST PLAYED ?) is good, IMO, as it's sortable, easy to read and easy to use.

Here is an example of what I see as inefficency and redundancy that might lead to "Lock in":

People tag Various Artists albums in different ways. %various%, %va% and %album artist% are the ones that comes to mind. The first two, are often given a value of "1" or "Yes", so their presence is their only purpose. %ALBUM ARTIST% on the contrary has a dual purpose, as it's used both for its presence and for storage of the text you want to display. Meaning it's a better choice if we want to reduce redundancy caused by having at least three tags doing essentially the same thing. Formatting strings can either support all of them, meaning more code and reduced speed, or choose one of them. The latter might lead to "Lock in", by making it cumbersome and confusing for users to switch to another formatting.

So, IMO, we should try to achieve three things:
* Reduce the number of tags doing essentially the same thing
* Settle on the format of tags like LAST_PLAYED
* Agree on what e.g. the %rating% tag should contain (integers seems a better choice than storing the actual rating symbol).

All of this should be done by considering what's being used at the moment. The fewer tags that needs to be changed or reformatted, the better.

In the end, people will still be able to use whatever they want.  But if you prefer to use %va_artist% instead of %album artist%, don't expect every formatting string to support it. And, if you want to develop a formatting string with making it public in mind (main purpose), try not to invent alot of exotic tags, when you could instead use what "everyone else" uses.

[span style='font-size:8pt;line-height:100%']Edit: typos[/span]
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-22 12:09:04
One more time, i completely agree with upnorth. The original goal of this thread was to reduce ambiguity(leading to lock-in or inefficiency), finding a better way and then making it easy for devs and users to jump on the bandwaggon - leading to adoption(because without adoption all this stuff is just fictional).

So, my personal priority-list looks like this:
1. (ease of) adoption
2. preventing ambiguity and incompatibility(lock-in)
3. Usability
4. Efficiency
5. Consistency

So, while consistency is a nice thing to have if we can get it for free, then i won't say no. But in the case of last_played the standard has already been agreed upon and users have begun to adopt it. Thus, i disagree to risk alienation and confusion(countering adoption) for the sake of consistency.

- Lyx

edit: typo
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-02-22 15:23:09
Quote
Proposal for the VA-issue:
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=274551")


Now in [a href="http://wiki.hydrogenaudio.org/index.php?title=Foobar2000#Encouraged_Tag_Standards]wiki[/url].
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-02-22 15:31:58
I guess will have to agree to disagree on this then.
Title: Tag-standards In Plugins<->formatting
Post by: Jasper on 2005-02-23 11:18:10
For the rating tag it might be an idea to use negative integer values for negative ratings. This would at least provide some consistency (basically the only difference between users would be the number of levels they want to use).
Title: Tag-standards In Plugins<->formatting
Post by: lav-chan on 2005-02-23 11:46:29
Out of curiosity... how would you display something like that? Like three red dots and then a white dot and then three green dots, or? Sounds kinda complicated. :/

And what's the benefit? What's wrong with just using 1 and 2 (or, if you want to be more precise and go on a scale of 10, you can use 1 through 4) for bad songs?

I'm not arguing against it (i don't use ratings anyway, so it's not like i'd care), i'm just curious as to why you'd want to do it like that.
Title: Tag-standards In Plugins<->formatting
Post by: shaneh on 2005-02-23 12:19:09
ITs worth noting that the id3v2 standard specifies a value of 1-255 for the rating in the POPM frame. (http://www.id3.org/id3v2.3.0.txt) A few applications use this frame for storing/retrieving rating data.

If foobar were to ever import/save this information, it would be nice if the %rating% tag could be translated easily. ie, a rating of 0-5 stars is easy to translate by simply multiplying by 51.

Perhaps rating could be of this value (ie 0-255), then a user can assign what star rating maps to what 0-255 value in their rating and display plugins. ie -2 rating maps to 0, 0 rating maps to 20, 5 rating maps to 255 etc.

This way, regardless of what scheme you want to use, 0-5, -2 to 10 etc. You just have to divide up the 255 value into whatever scale you want to use for display. and multiply your scale back into the 255 range for storing.

You can also share ratings with other people and it will translate into whatever scale they use without fuss.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-23 12:21:00
how people use the rating tag would be up to them anyways. The only thing which would be specified is the tag-name, and the format of the value (i.e. integers only). But personally, i wouldn't see the point as of why i would use negative numbers - because its all just a matter of scale anyways - so, if -5 would be really bad, and +5 awesome - then you could as well use +1 to +10 with the same meaning. That would have the benefit that the chances are higher that a formatting-string would support it.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: wortels on 2005-02-23 12:26:24
As a user I would request the devs to please use a standard specific format (specified in the standard like id3v2.4 or ape etc) instead of creating a new set of tags. This way even when I shift from the player or play my files somewhere else the same tags could be used in other players. For example if we use the play count and rating tags in the original id3 spec any player could use that data instead of it being exclusive to foobar. I (and I think a lot of other users) would really really appreciate this as our tags would be cross player compatible. There are already given set of specs at id3.org and almost every other player I have used follows those rules I don't know why foobar has to be different.
Title: Tag-standards In Plugins<->formatting
Post by: shaneh on 2005-02-23 12:28:12
Yes, there is no point in negative values, you just shift the offset of whats considered a "neutral" song if you want that.

If you were to use a scale of 0-255, you can scale this into whatever scale you want to dispaly. -5 to +5, or 0 to 5, or 0 to 255 etc. And share this value with other people and they can re-scale it to what they want to display. Or open your files in other players which already use this scale accordingly. (0 meaning unrated - not a bad song).

It also means formatting tags only have to work with 0-255, instead of a range of different scales.
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-23 12:35:36
Quote
I (and I think a lot of other users) would really really appreciate this as our tags would be cross player compatible. [a href="index.php?act=findpost&pid=276264"][{POST_SNAPBACK}][/a]

I vote for that
But in the case of playcount and rating I guess that this is stored in a database for most players (itunes, MMJB)...so no real tag is used. However I guess having a cross-standard tag name (if you would like to export that info by tagging it into the file and then merging it into the player library) would be of a great help and wise. I've done some google but didn't find i.e. what's the usual playcount field used.
Title: Tag-standards In Plugins<->formatting
Post by: shaneh on 2005-02-23 12:40:24
For id3v2 it is the POPM frame: http://www.id3.org/id3v2.3.0.txt (http://www.id3.org/id3v2.3.0.txt)
or the PCNT frame, depending on whether its a per user playcount or global playcount.

MeXP loads and saves to this frame.
Title: Tag-standards In Plugins<->formatting
Post by: wortels on 2005-02-23 12:40:39
http://www.id3.org/id3v2.4.0-frames.txt (http://www.id3.org/id3v2.4.0-frames.txt)
Quote
4.16  PCNT Play counter or as shaneh said POPM

As I have said somewhere before that plugin developers should be able to use the main foobar database to store such stuff (non standard tags esp) but as a tag is already present for the play count the user should be given the option if he wants to store these tags in the database or not. I think that itunes reads the PCNT tag but I'll have to confirm it. Even if it doesnt and we want to store the play count we should use the standard instead of making something on our own.
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-23 14:39:43
1)
Just to remind you:
-To have id3v2 support in foobar2000 you need to install a separate component
-Many people around here avoids ID3v2 like the plague
-There is a built in "Remove ID3v2 tags while updating" feature

So, using that standard as a template would be a strange choice IMO.

2)
A tag name like POPM (short for "Popularimeter") doesn't tell you anything at all. You have to remember that this is in fact a rating. Tags like RATING and TRACKRATING tells you instantly what the contents are. Keeping the contents in a human readable form would be nice too.

3)
You are free to use whatever tag you want. It's not like the customizability will be removed and everything will be hardcoded from now on.

4)
If you want to switch to another player at some point in the future, use the masstagger to convert to any tag you like. If you use your right to customize, you won't even have to do that conversion.

5)
Keeping (backwards)compatibility might prevent us from having new and better solutions


So, I don't support the thought of degrading the ease of use and readability, just to make it compatible with a tag standard that quite a few people around here avoids. Neither do I want to prepare now, for the possibility that I might change to another player at some point in the future. Especially when I know that I can easily convert those tags in a matter of minutes anyway.

I use foobar2000 to listen to music, something I love, and I want to enhance that experiece as much as possible. I'm mostly concerned about how it works for my everyday usage, not how I could stay compatible with every player out there, or play along the rules of some elite, illegal file trading community.

What this thread was intended for IMO (using rating as my example):
People around here seem to use RATING or TRACKRATING, which one should we encourage people to use? Should we store integers or symbols in it? That's all, and if adopted, it would make it just a little easier to switch from one public formatting string to another.

[span style='font-size:8pt;line-height:100%']Edit: layout, typos[/span]
Title: Tag-standards In Plugins<->formatting
Post by: wortels on 2005-02-23 17:47:59
Quote
1)
Just to remind you:
-To have id3v2 support in foobar2000 you need to install a separate component
-Many people around here avoids ID3v2 like the plague
-There is a built in "Remove ID3v2 tags while updating" feature

So, using that standard as a template would be a strange choice IMO.


Yes that is true but id3v2 is the next standard. If native support isn't implemented in 0.9 I would really be surprised. If "most people" don't want to use it they can disable it through the input menu but if its not supported it would make the player seem archaic in comparison with the others available in the market today.

Quote
2)
A tag name like POPM (short for "Popularimeter") doesn't tell you anything at all. You have to remember that this is in fact a rating. Tags like RATING and TRACKRATING tells you instantly what the contents are. Keeping the contents in a human readable form would be nice too.


POPM doesn't tell you everything but the thing is that the normal user doesn't always look at the name of the tag fields he will not complain that I don't understand his tag name instead he will say something like 'i rated my library with foobar why the #@# isnt the rating displayed in playerX'. Remember that standards are made to be followed and then ensure that things work every where just like the w3c standards.


Quote
3)
You are free to use whatever tag you want. It's not like the customizability will be removed and everything will be hardcoded from now on.


Yes that option should be available for the people who want to add custom tags like PLAY_DATE because they arent available in the standard tags. But at the end of the day I am talking about tag integrity and compatibility.


Quote
4)
If you want to switch to another player at some point in the future, use the masstagger to convert to any tag you like. If you use your right to customize, you won't even have to do that conversion.


Most people have trouble installing extensions how can you expect them to perform a function like this and if something goes wrong they'll end up blaming the person who  suggested this in the end its the out of the box functionality that is important. Its easier to to tell PPOM is for the rating tag instead of telling them use masstager and convincing them that it wasn't our fault their files got messed up while retagging etc etc. The hardcore foobar lovers won't take a second to adapt to such tags if they can write complicated formatting strings they can remember what a tag stands for. In the end it will potray foobar as a credible player instead of people like me complaining that it messed up our tags etc and we have to retag over 500 files by hand. This is why standard compliant tagging is important.

Quote
5)
Keeping (backwards)compatibility might prevent us from having new and better solutions

backwards compatiblity is important but a simple plugin like an impporter can be implemented which can convert your tags to standard compliant ones (masstagger script maybe) and with standards compatible tags I doubt we'd have to change again .

I am sorry for making everyone read this long post  (if anyone bothered ) but in my opinion this step would enhance foobar's public image and increase the usability alot. If standards weren't that convenient why would every other player out there support them. I remember the case with mp4 file tagging people were confused when files tagged in real pleyr didnt work in itunes but now that itunes tagging has become a standard everyone seems to be following it and things are working out well. Why do we have to be different. I truly hope that you understand what I am trying to say here because I have gone through most of the scenarios I mentioned above.
Title: Tag-standards In Plugins<->formatting
Post by: lav-chan on 2005-02-23 17:59:53
Er. Is foobar2000 even designed for the, um, 'casual' listener? You keep talking about how these people will have trouble doing this advanced stuff, but i was never under the impression that foobar was designed for people who can't figure out things like installing components and doing mass-tag operations.

Maybe i'm wrong, though. I dunno. <_<
Title: Tag-standards In Plugins<->formatting
Post by: The Link on 2005-02-23 18:21:32
Quote
Er. Is foobar2000 even designed for the, um, 'casual' listener? ...


I definitely think so! I recently introduced someone to foobar2000 who didn't use media players before on a regular base. I just installed the basic package on his PC and pointed him to places where to get some more information if he should want to do more advanced stuff in the future.
He didn't have any problems because foobar2000's default configuration is pretty good, it plays almost everything without having to think about the different existing formats and the important features for every day usage are reachable with a maximum of 2 mouse clicks. The standard windows gui helps a lot for such people and the plugin architecture lets people go further step by step!
I think that foobar2000 is ideal to get in touch with audio on computers in general.

Regards,
The Link
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-23 18:25:47
Quote
I truly hope that you understand what I am trying to say here because I have gone through most of the scenarios I mentioned above.[a href="index.php?act=findpost&pid=276350"][{POST_SNAPBACK}][/a]
Yes, pretty much that foobar should do everything the same way every other player does.

I'm not against standards, but what I'm against is making every player a Winamp/iTunes/Musichmatch clone. No, I don't consider myself a zealot/fanboy, but I like the fact that there are different players to choose from, not just different flavours of the same player. foobar2000 has been and still is, an advanced player, and there are more than enough players out there for people that can't handle the amount of options it gives you. Like I said in another thread, it's not like it is a human right to be able to use every player out there. I don't consider people uncool or less worthy if they use another player. Either they have found a player that suits their needs, or they just don't care as long as they can open a file and press play. IMHO, that's the way it should be, namely that you have a real choice.

Of course it's all up to Peter and the developers, to choose the direction in which foobar2000 will go from here. It's popularity seems to be growing, but to be the player for as many people as possible, you would have to add some bloath, give it a nice pink skin and remove most for the customizability, because it's too difficult to understand all of it for most people.

Anyway, this is starting to be way off topic, and I start to regret I even suggested a thread like this, as I didn't expect it to be this difficult.
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-23 18:49:46
Quote
Quote
Er. Is foobar2000 even designed for the, um, 'casual' listener? ...
I definitely think so! I recently introduced someone to foobar2000 who didn't use media players before on a regular base. I just installed the basic package on his PC and pointed him to places where to get some more information if he should want to do more advanced stuff in the future.
He didn't have any problems because foobar2000's default configuration is pretty good, it plays almost everything without having to think about the different existing formats and the important features for every day usage are reachable with a maximum of 2 mouse clicks. The standard windows gui helps a lot for such people and the plugin architecture lets people go further step by step!
I think that foobar2000 is ideal to get in touch with audio on computers in general.[a href="index.php?act=findpost&pid=276359"][{POST_SNAPBACK}][/a]
Reminds me of what someone said in another thread: The problem isn't the users you describe here (the ones that just wants to play some music), but some of the people in-between. The group that badly wants to call them selves "advanced users", and customize everything. Of course they don't have the required patience needed to customize, and neither do they understand that providing an interface for the overwhelming customizability is pretty much impossible, as it's simlpy too much to fit in a single point and click interface.
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-23 19:19:53
I think that aliumalik has a point. As a user I expect fb2k (or its components) to use standard/common tag fields. It has nothing to do with avoiding custom tags, or following id3v2, or trying to be cool to use fb2k instead of another player without understanding how it works, whatever.... I expect something that as much as possible (what a difficult term to define) stick to what'as already there if this is wise and widespread. For me it's something in between of:

- Let me use whatever I want as a tag in fb2k and stop complaining (or go back to winamp/wmplayer)

- I want fb2k to tag my files exactly as itunes, or winamp, or blablabla...

And more and more people are getting into foobar, and as popularity goes up, more people will complain about not being able to read the tags that itunes has write or to tags being wiped or their friend not reading their tags in MMJB, blablabla... not everyone uses fb2k, and I don't see the point whenever it's possible, to not support what's already being used by most people 

But upNorth is right, it's going OT.
Title: Tag-standards In Plugins<->formatting
Post by: The Link on 2005-02-23 19:29:20
Quote
Reminds me of what someone said in another thread: The problem isn't the users you describe here (the ones that just wants to play some music), but some of the people in-between. The group that badly wants to call them selves "advanced users", and customize everything. Of course they don't have the required patience needed to customize, and neither do they understand that providing an interface for the overwhelming customizability is pretty much impossible, as it's simlpy too much to fit in a single point and click interface.

IMHO that's not a problem of foobar2000. It's a problem such people have when using advanced software in general. Configuring means either you have the knowledge or you are willing to learn and risking to fail without having the right to complain. Those people may become a problem for this forum and its moderators but they shouldn't be taken too serious (again IMHO).
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-23 22:53:51
IMHO, interoperability between foobar and other players is something nice and which should be kept in mind. Its quite strange to complain that people need to retag their files to work between various fb2k plugins/formattings, and then say "well, when you want to use another player, then just retag your files" - thats hypocrisy.

However, it is just one of the many aspects which need to be taken into account. Its not an at-all-costs goal - at least IMHO. The tag-name indeed is among the most stupid names i've ever heard, and i guess it was for sure not invented by people who had the interests of the users in mind. So, once again, i tend towards upnorth's opinion but with a more moderate course: which players do support this "official" (patchwork)-standard tag? And how many people use it? Thats a honest question - if its in widespread-use, then i may give it a more thourough thought - if not, then screw it - this is among the most user unfriendly tagname and -format i've ever heard - it sucks even more than id3v2 overally. And the play_counter tag is already in widespread use by fb2k so adoption would be a piece of cake. This id3v2 standard better be good and in widespread use, otherwise my vote is "no thanks".

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: wortels on 2005-02-24 05:49:41
Every player I have used till now supports/prefers is3v2 tags musicmatch, itunes, winamp, wmp.....the list goes on. Even windows reads id3v2 tags before id3v1. I agree the name format might be unfriendly but most people will never care about the name of the tag. If there is a Field labeled Artist all they care is about putting the name inside. Even the advanced user will never need to edit the tag name. PCNT seems a good abbreviation to me because all fields have 4 lettered name. I do agree though that the ability to add extra fields must be there.

Plus many tags aren't supported by id3v1 like composert, art etc. We cannot just go on adding our own tags to id3v1 and continue a dying standard. Also Imagine if you were ripping 10-20 cds and now you tag them using a semi-automated tagger like tag&rename it will hardly take 10-15 minutes but if you use foobar and tag them in its own special way it will take hours and hours. I wouldn't want to go through that kind of anguish nor would anyone else I guess.

Also I don't think that this would make foobar a winamp clone. By not following standards we are like outcasts but if we are following standards we are just a better player not a clone. A clone would be one which copies the interface functionality etc but this is about files.

I am stressing this point because I used foobar with the play_count plugin sometime ago and the tagging methods are so weird that half of my files lost all their id3v2 tags and I had to add tags to 500 files by hand. Instead of editing a field it writes the whole tag again! and I don't know why the functionality is such by default that everything except id3v1 tags will be stripped when you update your file tags??? I mean they can coexist easily why do you have to remove them? and even when the option is set to id3v1 and v2 it strips out embedded art (cause foobar doesn't support binary data). Besides the tag names this is the functionality I want changed so when I update my tag files they are updated the normal way not in a way that leaves the user cursing the program/plugin afterwards.
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-24 09:12:48
Quote
I agree the name format might be unfriendly but most people will never care about the name of the tag.

You're right, most of the tmies people don't care about the tag name, just want to see artist where it's being displayed (said 'translated' into human readable format) but I doubt that winamp or wmplayer or itunes uses a tag name that's called %PCNT%, I'm almost sure that this info is *not* written to the file itself but in to a media library (at least itunes does it). Anyway, to be sure what the tag names is being used if it's tagged you can always check with 'tagger' what's really written into the file. I think that PCNT stand for a frame name (or any internal schema that I can't understand at all) but is not the tag name, please someone correct me if I'm wrong.

Quote
By not following standards we are like outcasts

Fb2k follows the standards, I mean, the most common tags are written as you expected. I doubt that a rating, or genre or artist tag written with id3v2 or APEv2 or id3v1 will not be read by another player. Another thing is playcounts and/or another tags that aren't so standardised or at least that other players treat differently. You always have the choice of what you're writting and how, and you can see it (not being hidden or 'transalted' for you, and that's a thing that I love in fb2k.

Quote
By not following standards we are like outcasts. I am stressing this point because I used foobar with the play_count plugin sometime ago and the tagging methods are so weird that half of my files lost all their id3v2 tags
[a href="index.php?act=findpost&pid=276505"][{POST_SNAPBACK}][/a]

That's completly OT.  I understand you, however it's another problem that has nothing to do with following standard names, whatever. Apparently this is going to be solved in the follwing version of fb2k (I mean the writting of id3v2) but about binary data (aka cover art) supported in fb2k, I really don't know if it'll still be wiped out. At least now you know what happens to your files if you tag them with fb2k in id3v2, and what you shouldn't do if you don't want them to be lost.

Now I really do think we should go back to the original discussion, or if moderators wants to split this conversation....

Edit: Wrong quoting corrected.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-24 09:32:00
I'll ask it again: how many players do support this tag-field and how many users use it? I don't give a crap about how many people and players use id3v2 - i only care about this tagfield (i forgot its name again) because thats what this thread is about.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-24 10:16:29
In case anyone wondered, I use a combination of ID3v1 + APEv2 and don't care about ID3v2. I have also never tried the ID3v2 component.
Quote
Plus many tags aren't supported by id3v1 like composert, art etc. We cannot just go on adding our own tags to id3v1 and continue a dying standard. Also Imagine if you were ripping 10-20 cds and now you tag them using a semi-automated tagger like tag&rename it will hardly take 10-15 minutes but if you use foobar and tag them in its own special way it will take hours and hours. I wouldn't want to go through that kind of anguish nor would anyone else I guess.[a href="index.php?act=findpost&pid=276505"][{POST_SNAPBACK}][/a]
This makes it pretty obvious to me that you haven't read up on APEv2. I don't use hours tagging, because foobar can easily be configured to do alot of work in no time. Not that I actually do that much to a newly ripped CD. Adding a SORT_GENRE tag is the only thing I do to every album, and that is done from the context menu.

I don't think changing one or two tag fields will make foobar2000 a clone. What I don't like is the argument that everything should be done exactly the same way as in other players, without considering possible benefits from finding another solution. Benefits for the people that actually use foobar alot, not ignorant people that might start using it, if we you do this and that.

I'm not against standards, but aiming at support for a standard that relies on a tag format (ID3v2) that alot of people around here, don't want to use, isn't the right way to go, IMHO.

Suddenly starting to use tag names with four letter abbreviations, doesn't do any good for consistency either.

All current tags and formattings would have to be changed, and as I implied above, I don't know how many in the current userbase, would benefit from this. To me it sounds more like a lot of work for nothing. If you want to break backwards compatibility, it should be a good reason for it.

Lyx's question above is interesting, and the only thing that matters. The number of players that use ID3v2 is irrelevant, because it's been like that all along. Do some searching on HA, and you might find an answer to why it is so.
Title: Tag-standards In Plugins<->formatting
Post by: shaneh on 2005-02-24 10:28:53
It doesnt matter what applications use this particular field, or use their own database. They use their own database because its silly to modify files as theyre played. But if an application were to import or export such data to the file, those are the fields they use - because they support id3v2 and thats where such data is to be stored.

Its strange to use %pcnt% in formatting strings I agree. Most players dont use that though, they use %playcount% or equivalent, but are smart enough to know what the tag represents and where to store it.

For example, fb2k doesnt use the id3v2 frames as tags, %trck% or %tpe1% etc, but is 'smart' enough to translate the frames to/from %tracknumber% and %artist% etc.

So yes, the tag field should still be called %rating% or whatever it is thats decided upon. And not called POPM. In fact, calling it POPM wouldnt make sense, as it refers to a frame that contains both rating data and playcount data.

The trouble with calling it %rating% though, is the database saves tags as a text field called RATING rather than the correct POPM frame (in id3v2). If/when foobar properly supports id3v2, it should be smart enough to do this mapping - and it should be able to do it without writing APE tags as well, for those who dont want it.

As the people in this thread are concerned with the tags rather than the underlining implementation, this is irrelevant for this thread.

However, for %rating%, IMHO the underlying implementation should use a value 0-255, which is standard. This *does* affect people who are only concerned with tags. For example, you cant do (pseudo)

$if(%rating%=(1to5)) etc, but would need to do $if(%rating%=(1to255)) instead. Using a constant scale of 1-255, also means you can use map it to whatever scale you want, without having to rewrite your tags/database.
Title: Tag-standards In Plugins<->formatting
Post by: upNorth on 2005-02-24 10:37:27
@shaneh: Thanks for sharing your insight.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-24 10:39:22
Quote
Its strange to use %pcnt% in formatting strings I agree. Most players dont use that though, they use %playcount% or equivalent, but are smart enough to know what the tag represents and where to store it.

For example, fb2k doesnt use the id3v2 frames as tags, %trck% or %tpe1% etc, but is 'smart' enough to translate the frames to/from %tracknumber% and %artist% etc.


In other words, the underlying implementation (the frames) are irrelevant for this discussion anyways (as you said), because it would be a job for the core(on which we do not have any influence) to translate the tag-field to the pcnt-frame. Thus, the whole id3v2-pcnt thingie is irelevant and independent from this discussion.

So, is there any good reason to use something else than the already established (among fb2k) play_counter tagname? Something which outweights the fact that it _is_ already the standard among fb2k-users?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: shaneh on 2005-02-24 10:47:15
Its true the whole id3v2 frame thing doesnt matter for this dicussion.

But because fb2k needs to do the mapping in the core, or in the database or whatever - they are the one that will ultimately decide what maps to what. Although, they are likely to use whatever is in most common use - perhaps even look in this thread.

The id3v2 standard for rating *values* does matter somewhat however, as it does ultimately affect formatting tag standards as well.

As for the actual names of the tags - its something that should probably be discussed with the 'core' implementers, 'cause as I said, they are the ones that would ultimately do the mapping.
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-24 13:06:13
Quote
As for the actual names of the tags - its something that should probably be discussed with the 'core' implementers, 'cause as I said, they are the ones that would ultimately do the mapping.

Thanks al ot for your explanations. Finally i've understood somethign about frames and tag fields, that I admit didn't have a clue. So it's not important at all what field is being used, but what field is linked to what frame.

Quote
The id3v2 standard for rating *values* does matter somewhat however, as it does ultimately affect formatting tag standards as well.

It makes sense. I wonder how i.e. itunes store their ratings, is it doing like you said a rating between 1-255 and transalte it to a 1-5 scale? In this case, and if it's how all players use it, I don't see any incovenient in using the 1-255 as a scale for rating, it'll be only a matter of formatting to 'translate' it to a 1-5 scale (or whatever you want).
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-24 13:10:12
Quote
So, is there any good reason to use something else than the already established (among fb2k) play_counter tagname?
[a href="index.php?act=findpost&pid=276556"][{POST_SNAPBACK}][/a]

I don't think so. %play_counter% is the standard in fb2k and could be mapped to whatever frame it should be by 'core' developpers.

Just as a sidenote,  maybe it could be wise to also include %__last_played% (as well as other playcount plugin tag fields) in the recommended tags section, because it's what it's used if you have the mod playcount versin of kode54 that tags into the database (and appears as a metadata field).
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-02-25 19:36:21
Quote
Just as a sidenote,  maybe it could be wise to also include %__last_played% (as well as other playcount plugin tag fields) in the recommended tags section, because it's what it's used if you have the mod playcount versin of kode54 that tags into the database (and appears as a metadata field).


I'd like to hear the opinion of others about this first, since this complicates the code a bit more and is about a plugin which is not that easy to install for the average user (because it requires sql). Also, if i understood correctly, last_played isn't yet the default in kode's variant. With this, i don't want to de-value kode's work, which solves the most wanted feature of playcount (db-only tags) - it's just that i'm unsure about how to handle this and therefore would prefer some other opinions before doing anything. Remember that devs are free to support non-agreed methods anyways - this is only about if it should be included in the "officially" recommended method.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-02-25 20:19:28
Quote
and is about a plugin which is not that easy to install for the average user (because it requires sql).

No it doesn't. At first that's what I thought, but it's just as simple for the average user (that I am ) to install as:
- put the foo_playcount.dll into the component folder.
- put the sqlitle.dll into the main foobar2000 folder.

Voila.

Quote
Also, if i understood correctly, last_played isn't yet the default in kode's variant.


Not, it uses %__play_counter% and %__play_stamp%. But to use the 'recommended' format is as simple as this:

Code: [Select]
%last_played%=%Y-%m-%d %H:%M:%S

That will write %__last_played% as i.e. 2005-02-25 21:16:05

Quote
Remember that devs are free to support non-agreed methods anyways - this is only about if it should be included in the "officially" recommended method.

Yeah, sure, no problem
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-03-06 08:49:17
Is foo_playcount ever going to be updated?  I would love to see FIRST_PLAYED finally employed...is anyone even considering updating this component?
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-03-07 09:15:04
Quote
Is foo_playcount ever going to be updated?  I would love to see FIRST_PLAYED finally employed...is anyone even considering updating this component?
[a href="index.php?act=findpost&pid=279678"][{POST_SNAPBACK}][/a]

I asked in the playcount thread to kode54 if he was interested in implementing this (as well as last_played as default) in his mod version (which doesn't write tags, just store playcounts in a external database), but he didn't aswer so I guess he's not interested.
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-03-07 09:19:57
Quote
Quote
The id3v2 standard for rating *values* does matter somewhat however, as it does ultimately affect formatting tag standards as well.

It makes sense. I wonder how i.e. itunes store their ratings, is it doing like you said a rating between 1-255 and transalte it to a 1-5 scale? In this case, and if it's how all players use it, I don't see any incovenient in using the 1-255 as a scale for rating, it'll be only a matter of formatting to 'translate' it to a 1-5 scale (or whatever you want).
[a href="index.php?act=findpost&pid=276597"][{POST_SNAPBACK}][/a]

What about rating values range? I think what shaneh explained makes sens, if players use something in the 0-255 range to tag rating and then transalte it to the 'default' player range (i.e. 1-5 or 1-10) it would makes sense to have a recommended rating format.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-03-12 16:14:30
[span style='font-size:14pt;line-height:100%']Plugin-Developer needed for the following minor changes to play_count:[/span]

Since it seems quite difficult to find someone to do the proposed changes to the playcount_plugin, i've splitted the original proposal into two variants: a simple and an "optimal" version. The simple version is a draft with only those changes which NEED to be implemented. So if you're a plugin-developer who would like to help out but who doesn't have much time, then this is the way to go.

On the other hand, if you have some extra-time then you can pick the "optimal" draft and implement the proposed changes in it.

"Simple Version":
Quote
Update tracks when playback reaches the following track-position:
<already existing song-position-slider when tags get updated>

Append the following info after the standardized date & time:
FIRST_PLAYED: [inputfield empty]    LAST_PLAYED: [inputfield empty]



"Optimal Version":
Quote
<previous song-position-slider when tags get updated>

[checkbox checked] Use new LAST_PLAYED and FIRST_PLAYED tag-standard (supported by public formattings & plugins)

<indent>Append the following info after the standardized date & time:
<indent>FIRST_PLAYED: [inputfield empty]    LAST_PLAYED: [inputfield empty]

<indent>Remove the following fields when tags are updated(seperated with semicolons):
<indent>[inputfield containing "PLAY_DATE;PLAY_TIME"]

------visual-seperation--------

[checkbox unchecked] Use additional custom-fields (not supported by public formattings and plugins)
<indent>Field 1: [inputfield containing PLAY_DATE] Format: [inputfield containing default PLAY_DATE-format]
<indent>Field 2: [inputfield containing PLAY_TIME] Format: [inputfield containing default PLAY_TIME-format]

When the user enters FIRST_PLAYED or LAST_PLAYED into the custom fields and tries to save it, then a popup-window opens saying "This will break public formattings and plugins which make use of these tags. Are you sure?"   <YES/NO choice>



We really need the above changes implemented for the new standard to take off. Even if you can just implement the "simple" variant then this would still help alot.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-03-12 16:52:34
::crosses fingers, grimaces::
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-03-16 22:02:14
Hmm, since there is nothing else happening in this thread, i'll drop in a question which is also interesting to me right now:

Is there some kind of agreed method how to give tracks a secondary genre? What i mean is this: most of the stuff to which i listen doesn't fit into the conventional genre-scheme. Currently, i'm solving this by giving tracks a primary GENRE and a secondary STYLE. The STYLE-tag can carry any kind of short description - either a word describing the mood, or a secondary genre. Like for example: "GENRE: Post-Rock, STYLE: Ambient".

Are there other established methods to do this? Or maybe just generally a better approach?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-03-16 22:47:44
Quote
Hmm, since there is nothing else happening in this thread, i'll drop in a question which is also interesting to me right now:

Is there some kind of agreed method how to give tracks a secondary genre? What i mean is this: most of the stuff to which i listen doesn't fit into the conventional genre-scheme. Currently, i'm solving this by giving tracks a primary GENRE and a secondary STYLE. The STYLE-tag can carry any kind of short description - either a word describing the mood, or a secondary genre. Like for example: "GENRE: Post-Rock, STYLE: Ambient".

Are there other established methods to do this? Or maybe just generally a better approach?

- Lyx
[a href="index.php?act=findpost&pid=282802"][{POST_SNAPBACK}][/a]

Recently I've retagged my whole collection using AllMusicGuide's "Styles."  I used The GodFather, which adds these styles automagically into a %styles% tag (plural), separated by commas.  I don't know if %styles% is standardized or not, but I hope either it becomes the standard or The GodFather changes its tagging methods, because it makes doing this so easy.
Title: Tag-standards In Plugins<->formatting
Post by: jkwarras on 2005-03-17 10:09:01
Quote
Recently I've retagged my whole collection using AllMusicGuide's "Styles."  I used The GodFather, which adds these styles automagically into a %styles% tag (plural), separated by commas.
[a href="index.php?act=findpost&pid=282811"][{POST_SNAPBACK}][/a]

Same here
I use %styles% tagged via godfather, it's easy and fast and it allows multiple values like this:

%styles%=post-rock, alternative rock, indie

I know a lot of people uses godfather and AMG as their tagging database instead of freedb, but seriously it doesn't seems to be such a standard for that. It's like the %tempo%, %situation% or %mood% (%tones% in AMG tagging), different programs uses different implementation (different values to fill the fields i.e. %mood%) or simply mix these fields (I've seen in some prog that %situation% is sometimes filled with values that should belong to %tones%/%mood%).

Anyway, AMG since like a good reference to me and in most of the cases their values for these fields are very good. most of the tmies, for %genre%, they give it a general genre and then give it much more subgenre in the %styles% tag, which I believe it's better than just give it a subgenre in the %genre% tag and forget the main genre the song/album/artist belongs to.

i.e. a grunge band in the default scenario will just have a %genre%=grunge. In the AMG approach it'll have something like this:
%genre%=rock
%styles%=grunge,alternative,alternative rock,metal

which I believe it's better because in fact 'grunge' belongs to rock 'main' genre and 'grunge' it's just a subgenre of it.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-03-18 04:50:50
Quote
Are there other established methods to do this? Or maybe just generally a better approach?[a href="index.php?act=findpost&pid=282802"][{POST_SNAPBACK}][/a]


My technique is to have multiple, ordered GENRE tags. For example, the "genre" Acid Techno would be:

GENRE=Electronic
GENRE=Techno
GENRE=Acid

The way foobar2000 handles metadata makes this reliable and workable.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-14 05:21:33
I've built a new version of foo_playcount that uses LAST_PLAYED by defaut (but doesn't change existing settings).  Get it here (http://www.hydrogenaudio.org/forums/index.php?showtopic=20719&view=findpost&p=297443).  I'll try adding FIRST_PLAYED next, but I have very limited experience with C++ or the foobar SDK so will see how I go.

Edit 1: Version 1.5.2 now available.  Adds a FIRST_PLAYED tag. Same link as above.

Edit 2: Next major revision (1.6) will more closely represent the 'Optimal Version' Lyx described above.

Edit 3: Version 1.6.1 is now available.  Uses tags with spaces not underscores now. No longer supports custom timestamping.  Some other changes, see the link above.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-14 09:22:53
Woah, great! Unfortunatelly, i've got to catch the train in an hour and will be away for the weekend - but i'll definetelly give this a try when i'm back. Thanks.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: RevivalofHonor on 2005-05-14 15:13:03
Quote
Quote
Hmm, since there is nothing else happening in this thread, i'll drop in a question which is also interesting to me right now:

Is there some kind of agreed method how to give tracks a secondary genre? What i mean is this: most of the stuff to which i listen doesn't fit into the conventional genre-scheme. Currently, i'm solving this by giving tracks a primary GENRE and a secondary STYLE. The STYLE-tag can carry any kind of short description - either a word describing the mood, or a secondary genre. Like for example: "GENRE: Post-Rock, STYLE: Ambient".

Are there other established methods to do this? Or maybe just generally a better approach?

- Lyx
[a href="index.php?act=findpost&pid=282802"][{POST_SNAPBACK}][/a]

Recently I've retagged my whole collection using AllMusicGuide's "Styles."  I used The GodFather, which adds these styles automagically into a %styles% tag (plural), separated by commas.  I don't know if %styles% is standardized or not, but I hope either it becomes the standard or The GodFather changes its tagging methods, because it makes doing this so easy.
[a href="index.php?act=findpost&pid=282811"][{POST_SNAPBACK}][/a]


I use AllMusicGuide's hierarchal "styles" as well (it cuts down on main genres, and saves me a headache from all the styles, cause none of my friends can make up their minds), but I don't use GodFather, and I definitely don't need the moods or themes.  I use multiple %style% tags.  Even though most (if not all music) has more than one style, I don't like using plurals.  I also use multiple %artist% tags (and %album artist% for albums that need it), but that's slightly off-topic.  I'm also thinking about structured database support and data normalization, so I definitely prefer no plurals in tags.

As for %first played% and %last played%, I haven't completely ordered my files the way I want it, and I don't want that info in the file itself, so I haven't enabled a database yet.  Otherwise, I would definitely use it.

%rating%: definitely 0-255 (or was it 1-255), as I intend to use close to the full spectrum to rate my songs.  Also something I don't want in the file itself.

Thanks to everyone who gave input on tag standards; it makes my music experience much more lively.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-14 16:05:19
@ Lyx for when you return.

On the 8th of May, Canar changed the wiki so that LAST_PLAYED became LAST PLAYED.  I took it that this was the new standard and built the latest version of the foo_playcounter plugin.  I also changed PLAY_COUNTER to PLAY COUNTER for consistancy's sake.  I now realise that it was not changed here, so I assume Canar did this all on his own.  I agree with him.

The latest version of foo_playcounter automatically switches users over from FIRST_PLAYED/LAST_PLAYED/PLAY_COUNTER to the same with spaces, not underscores.  It even transfers over the number of times played to the new tag.  All that is left for you to do is update navigator so that it use LAST PLAYED instead.  This will take you all of five seconds (already done on my own copy) and you can release a new version.  I think your's is the only public FCS to support LAST_PLAYED, which means in theory no users are particularly inconvienced.

I have no intention of changing it back to LAST_PLAYED.  Considering the changes you have to make to navigator are so simple, Canar has already changed the wiki, and it would provide consistancy accross all tags (i.e. ALBUM ARTIST, PLAY COUNTER, LAST PLAYED), you should change it in the first post.

Obviously, the my version of foo_playcount will only automatically update the sings that get played.  If you want to do it for your whole collection, I made a masstagger script.  Get it here (http://users.tpg.com.au/adsll926/foobar/Masstagger.mts).
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-14 16:14:41
I had posted a comment on the talk page for quite some time. Noone responded, so I took the initiative. Thanks for the agreement, kl33per.
Title: Tag-standards In Plugins<->formatting
Post by: mixcherry on 2005-05-14 17:02:13
Quote
All that is left for you to do is update navigator so that it use LAST PLAYED instead.  This will take you all of five seconds (already done on my own copy) and you can release a new version.  I thinkk your's is the only public FCS to support LAST_PLAYED, which means in theory no users are particularly inconvienced.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=297469")

Yes, but Lyx's FCS is not the only one that uses PLAY_COUNTER. And that's the point where things begin to complicate

Remember that not everyone is familiar with formatting strings. People just want to download FCS that would work without ANY changes. And without ANY [a href="http://www.hydrogenaudio.org/forums/index.php?showtopic=20719&view=findpost&p=297483]masstagger scripting[/url]. And how are you going to enforce all popular FCS authors (http://foobar.nub4life.net/columns/pafiledb.php?action=category&id=5) to use your tag-convention?

I really don't know what that whole 'standards-' and 'consistancy-' talk is about. I mean, that's very good for newly created tags (like LAST PLAYED), but I think that when almost EVERYONE is using PLAY_COUNTER (with underscore), there is no real reason to changing it, because it IS standard already.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-14 17:17:50
I can't please everyone can I.  Some people want LAST_PLAYED and PLAY_COUNTER, some people wnat LAST PLAYED and PLAY_COUNTER, some people want LAST PLAYED and PLAY COUNTER...

Seeing as I'm the one who finally stood up and decided to continue developing foo_playcount, I get to make the decisions.  Here it is, tags use spaces, not underscores.  If you don't like, use an older version, or take the sources and mod it yourself.  FCS developers will fall inline, or there FCS's just won't work.

I altered my foobar to work with spaced version of the tags in roughly 30 seconds.  If the FCS developers can put this much time into their designs, no one will have a problem.
Title: Tag-standards In Plugins<->formatting
Post by: Birk on 2005-05-14 17:24:21
Why you don't use %lastplayed%, %firstplayed%, %playcounter% and %albumartist%?

I think using tags with two words looks not very great, because when i see %album artist% i think that their are two informations (album+artist) and the space brakes a code in two halfs ($if2(%album artist%,%artist%))
but if you think you've to use that please use underscores
and please choose one standard not sometimes with underscores, sometimes with spaces
I don't think we have to use a standard only because somebody in the past has uses it, but i think you have to agree on one standard and then uses it everywhere and everytime, if not you've not to create any standards or?
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-14 17:35:54
We don't use no spaces because ALBUM ARTIST is to widely adopted, beyond even hydrogenaudio.org.  All the other tags are pretty much limited to HA.org and foobar2000 users.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-14 18:18:42
Quote
Why you don't use %lastplayed%, %firstplayed%, %playcounter% and %albumartist%?

I think using tags with two words looks not very great, because when i see %album artist% i think that their are two informations (album+artist) and the space brakes a code in two halfs ($if2(%album artist%,%artist%))
[a href="index.php?act=findpost&pid=297508"][{POST_SNAPBACK}][/a]


Okay. Here are the options:

1. No spaces/underscores.
2. Underscores.
3. Spaces.

The best option of those three is spaces. A space delineates two words and is a completely valid field. I don't care that you can't wrap your mind around the concept, it's simply the way it is.

Underscores are a pain in the ass to type (at least compared to the other two options) and look somewhat cluttered.

No spaces can cause confusion (look at %opportunityisnowhere% and tell me if the final word is where or here) and is not any better than using spaces.

Spaces are the best option for the following reasons:

Cleanest.
Easy to type.
Creates valid English field names (which is important for non-english users trying to decypher meaning, given that APEv2 isn't semantic).
Most easily read.

Spaces aren't the best option for the following reasons:

Causes word-wrapping at inappropriate locations.

Anyone have anything else to add?
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-14 18:23:11
Spaces it is
Title: Tag-standards In Plugins<->formatting
Post by: wolffenstein on 2005-05-14 18:23:25
Least nerdy.
Title: Tag-standards In Plugins<->formatting
Post by: Birk on 2005-05-14 19:29:26
ok. use what you want



But we could use %FIRST%, %LAST% and %COUNT%, too.
That would:
Quote
Cleanest.
Easy to type.
Creates valid English field names.
Most easily read.


why do you want to use play before it, then we had to use tags like
%TRACK TITLE%, %ALBUM TITLE%, %ARTIST GENRE%...
and what is with %TRACK NUMBER% ?


and one thing more: why do you use %PLAY_COUNTER% and not %PLAY COUNT%?
I don't think that the tag is counting anything or do we have to use %TRACK TITLE_WRITER% now?
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-14 19:40:43
I'm getting sick of this.  The short of it is:

foo_playcount uses PLAY COUNTER, FIRST PLAYED, & LAST PLAYED.

I'm no longer care what others are interested in using or suggesting.

In rebuttal, FIRST and LAST don't actually mean alot, as apposed to FIRST PLAYED and LAST PLAYED.
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-05-14 20:00:58
Dear developers, especially kl33per,

there's nothing wrong with defining recommended standards to keep a certain compatibility among Columns UI styles. However, what I really don't like is your "we know what's best for you and we don't care what you want" attitude, which locks out people who want to define their own field names, although this is apparently one of the main concepts foobar2000's metadata handling is based on. Answers like "write your own plugin then" are unfriendly and obviously nonsense. You know it's not going to happen.

Almost all components like album list, playlist tree, masstagger, quick tag, diskwriter, columns UI etc. allow me to use my own tags, you're the ones starting to break compatibility now. You are a small group of foobar2000 users which happen to be developing some popular components, and now you are acting as guardian for all others. You're actually abusing your status. If I was among the core foobar development team, I would lock out your components, similar to those who for example break unicode compatibility.

I again plead you to stop confusing recommendations with enforcements.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-14 20:05:46
Are you suggesting we should go back to the way it was, with everybody using there own standards, and nobody's columns_ui FCS's working with anybody elses tags.

I ask you this Frank Bicking, if I were to reimplement custom timestamping, would you infact use it?

Edit: BTW, suggesting that components that only offer a specific functionaility should be "locked out" is ridiculous.  I care what you want, but I have everybody on all sides telling me different things.  Well now I've picked one, PLAY COUNTER, LAST PLAYED, and FIRST PLAYED.
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-05-14 20:36:40
Quote
Are you suggesting we should go back to the way it was, with everybody using there own standards, and nobody's columns_ui FCS's working with anybody elses tags.

By no means am I suggesting that. Feel free to set standards for your own, but keep in mind that you'll always be a subgroup among a variety of foobar2000 users with different opinions that should be respected. The situation shouldn't change for those who deliberately don't want to adapt to your standards and who are well aware of the disadvantages they might have to put up with. Sure, Navigator Suite and other FCS are not going to be compatible with my user-defined field names, but I've chosen foobar2000 because it doesn't force me to agree with someone else's opinion about how things should be done.

All I'm suggesting is to respect this very sentence from the clarification on the first post:
Quote
And for users who don't want to use the proposed standards, the situation will stay as it is now.

The situation was: Play Count allowed people to define their own field names. For sake of compatibility with your standards, you may of course set them as default values or even add an explicit warning of changing them, but please don't take away the possibility at all.

Quote
I ask you this Frank Bicking, if I were to reimplement custom timestamping, would you infact use it?

I would only use different field names.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 04:11:45
But why?  I see no good reason (once FCS's are updated to use spaces not underscores) to not use the default tag names.
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-05-15 12:01:04
I think I've been very clear in my first paragraph, I don't feel like repeating the same in different words.

Feel free to reread it with your current question in mind.

To put it simple: I don't like your proposed field names and you shouldn't be the one to make that decision for me.
But my personal reasons are not that much of importance here. Fact is, there was a promise made in the initial post:
Quote
This is not about forcing users or developers to only use those "standards". Currently, when you switch formattings or plugins then you can never be sure that the way your files are tagged/named will continue to work. "Formatting-1" may currently use method-A but not support method-B... "Plugin-2" may support method-B but not method-A, etc.
So this is about declaring a general guideline of how to describe certain characteristics. Devs are encouraged to support at least those methods which are declared as the standard, but are free to additionally support other methods. That way, users have the safety that when using the standards, then switching between formattings and plugins will be smooth. And for users who don't want to use the proposed standards, the situation will stay as it is now.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 12:20:59
And I don't really care that you don't like it.  Its not like its overly hard to change your tags.  If you don't want to change, use an older version of the plugin.

Edit: That's right, the situation does remain the same as before, use the old plugin.

Edit 2:  Again, I implore anyone to give me a situation where having custom tag names is actually useful.  Not liking it is not good enough, you need an actual reason.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 13:07:23
Let's say I were to build a program that dealt with a tag which counts the play count. Let's say I call it "Auto Playcount," and it uses a tag called "PLAY COUNT."

I want to run Auto Playcount on Linux, and I want the resulting files to play nicely with files that have been used in foobar2000.

Auto Playcount should not be forced to use the tag name "PLAY COUNTER."

---

Replay Gain tags on Vorbis files are named like REPLAYGAIN_TRACK_PEAK, not VORBISGAIN_TRACK_PEAK even though the first program to implement it on Vorbis files was vorbisgain.

It's good policy to name the tag based on what it does, not the program that proposed the tag in the first place.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 13:21:40
The only way to currently fix this situation is to rebuild the foobar2000 plugin.

If the plugin were configurable via TAGZ, no rebuilding would be necessary.

Quote
Edit: That's right, the situation does remain the same as before, use the old plugin.[a href="index.php?act=findpost&pid=297715"][{POST_SNAPBACK}][/a]

Shutting people out from potential bug fixes and potential new features is not desirable.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 13:27:22
What are you suggesting???

I'm not shutting people out from new features. One of these new features is tags are now only PLAY COUNTER, FIRST PLAYED, and LAST PLAYED.  If they don't like it, I no longer care.  I am so sick of going over this again and again.  Making the tags configurable is not even an option worth considering.  It only leads to user lockout when everyone settles on different standards from each other.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 13:34:00
Tagging standards are a myth. No such thing is possible.

If you want interoperability, just use PLAY COUNTER (edit: although I'd pick PLAY COUNT, if I had a choice) as a default value, and give us an option to change it, please. Pretty please...

People who can change the default value of the tag will be able to deal with any potential incongruency without any problems.

People who can't change settings shouldn't, and wouldn't, and wouldn't experience any problems.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 13:50:18
But no one can give me a reason why custom tag names are required.  If you can give me that, then I'll think about it.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 13:52:07
It's the foobar2000 way, and I've already outlined interoperability issues with other programs.

foobar2000 encourages TAGZ. Nothing is set in stone.

You can read some of my thoughts here also: http://www.hydrogenaudio.org/forums/index....showtopic=24722 (http://www.hydrogenaudio.org/forums/index.php?showtopic=24722)
Quote
I can imagine Vorbis files where each software would implement his own tag names
[a href="index.php?act=findpost&pid=231738"][{POST_SNAPBACK}][/a]

Quote
Well, the software (ideally, at least) shouldn't implement any of its own tag names. The user would supply his own field names, à la foobar2000.
[a href="index.php?act=findpost&pid=231751"][{POST_SNAPBACK}][/a]
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 14:14:42
All you need to do is read this thread to see many, many reasons why there should be a tag standard.  Interoprability between different columns_ui FCS and plugins is top of that list.
Title: Tag-standards In Plugins<->formatting
Post by: mixcherry on 2005-05-15 14:23:33
If you are so worried about 'interoperability' between different FCS, why do you change the existing standard (with '_')? For example: plisk is very popular fcs, but it looks like its author is no longer concerned in updating it - but people still download it.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 14:32:42
kl33per, interoperability need not suffer. You could just issue a short warning (for the first time only, more often if you feel like it) if a user tries to change the default values.

"foo_playcount recommends its default values for interoperability between different formatting strings and scripts. By changing the defaults, you acknowledge that you will have to take care of any incompatibilities on your own."

You could add a "reset strings" option to the plugin.
Title: Tag-standards In Plugins<->formatting
Post by: mixcherry on 2005-05-15 15:00:43
I totally agree with kjoonlee (configurable strings are teh best ), but there is one small problem - the _default values_ for meta fields. Most of the people will use the defaults, and IMVHO the basic field should be 'play_counter' (with underscore), because this name is widely used. And it really looks better when it doesn't wrap (like the 'with space' version).

@kl33per: I do like what you're doing with this plugin and appreciate your efforts to make it even better and better and this 'underscore/space' fight  is the only problem that stops me from using your version
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-15 15:26:00
Quote
Almost all components like album list, playlist tree, masstagger, quick tag, diskwriter, columns UI etc. allow me to use my own tags, you're the ones starting to break compatibility now. You are a small group of foobar2000 users which happen to be developing some popular components, and now you are acting as guardian for all others. You're actually abusing your status. If I was among the core foobar development team, I would lock out your components, similar to those who for example break unicode compatibility.

I again plead you to stop confusing recommendations with enforcements.
[a href="index.php?act=findpost&pid=297576"][{POST_SNAPBACK}][/a]


I again plead you to stop bitching unless you're doing something about it. kl33per's component is simple and bug-free, as well as solving a problem that exists. Peter locks out components that are exceptionally buggy, and/or have limited value in his view. I've been pestering him to lock out oddcast for a while due to its extraordinary level of crashiness, but because of its unique nature, he's reluctant to do so.

My recommendations to remove underscores are the most logical solution to the problem, and I challenge anyone to prove otherwise. If you succeed in doing so, I will be happy to cede this point to you.

The foobar2000 philosophy values doing things correctly above doing things in a backwards-compatible manner.

Also, you're free to use whatever tagging system you so desire. Every single one of the components you listed allow for configuration using Tagz. If you so desire, use an older version of the PLAY COUNTER component and stick with your underscored fields.

Alternately, quit bitching and solve problems as they arise like everyone else. You have no right to complain unless you actually do something about the problem.
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-05-15 15:54:00
Canar,
Quote
My recommendations to remove underscores are the most logical solution to the problem, and I challenge anyone to prove otherwise. If you succeed in doing so, I will be happy to cede this point to you.

since you addressed me directly, let me emphasize that I didn't take part in any underscore vs. space discussion so far, since there is no reason for certain user-defined field names except than different tastes. Asking for a logic reasoning is simply not possible, and I reckon we're all well aware of that. I agree that there are good reasons for whatever standard, but they don't disqualify different opinions.

However, I'm interested in offering each single user the freedom to make a choice, and since the topic is pretty controversial, the best solution would be to offer a free choice of field names as it was mentioned several times. Note that this is not about winning or losing some kind of challenge as you might see it. That being said, I'm still in favor of the solution to set default values and place an explicit warning of changing them, a proposal that I've already made in a reply yesterday.

Sidenote: "stick with your underscored fields" doesn't apply to me.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 16:20:50
kl33per, could you tell us your opinions regarding my proposal above, please?
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 16:50:50
My opionion is that I still don't see the need to implement custom tag names.  All I see is a bunch of people who want to use custom tag names so they can be different.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 16:54:14
Allow me to propose an abbreviation for interoperability: i14y.

While the current plugin may enhance i14y between foobar2000 settings, it reduces potential i14y with *other* play counting programs.

And i14y was the whole point in choosing PLAY COUNTER over PLAY_COUNTER, wasn't it?
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 17:11:40
Quote
Are you suggesting we should go back to the way it was, with everybody using there own standards, and nobody's columns_ui FCS's working with anybody elses tags.[a href="index.php?act=findpost&pid=297577"][{POST_SNAPBACK}][/a]

Ideally, all "public" FCSes should work with the default settings of foo_playcount, if it were to support custom field names.

The blame should be on the FCS writers, not the users of custom fields, if incompatibilities were to arise.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 17:16:24
I could explain all day long, but i'll keep it simple:

1. people discussed the >agreed< standards listed on the first page for weeks and multiple pages long - and they came to the conclusion and agreement listed on the first page. It has beed agreed and decided, so you folks are multiple months late for speaking up. Its over, accept it or go >non-standard<.
2. When the standards were decided upon, one of the many things considered was disruption of existing systems, and easy-of-transition. That was the reason why we decided, to NOT change play_counter, and use additional tags consistent with the underscore-style of play_counter.

As a formatting-style author, i see absolutely zero reason to change my formatting. A standard was agreed upon, i implemented it (in addition to EXISTING play_counter support). So, some months later someone else "kinda" implements the agreement as a default, and suddenly people remember out of nowhere that they prefer to change the agreement. Sorry, folks, you're too late - you had lots of time to make up your mind.

Concerning *intentional* configurability of the tag-name: i'm against it, but i guess that suprises no one here.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 17:19:04
1. Which only makes my belief stronger. Attempts to standardize language are doomed to fail.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 17:23:50
2. Lyx, actually, if you mean that you altered your FCS to fit the standard (as of the timing of the writing,) I would agree wholeheartedly about the nobleness of your behaviour.

I'm saying that FCS writers should support the default values of the plugin.

Let the users diverge from the defaults, please..
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 17:31:52
Quote
The blame should be on the FCS writers, not the users of custom fields, if incompatibilities were to arise.
[a href="index.php?act=findpost&pid=297782"][{POST_SNAPBACK}][/a]

I can't believe I wrote this.

People who use custom fields should take responsibility (and the blame) if their own changes result in incompatibilities with regular FCS scripts.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 17:43:27
Alright, these are the people I want to hear from. Lyx and Canar.

What happens now, do we go with spaces, or underscores.  Whatever happens, someone change either the wiki, or the first post here so I can follow one damn standard.  Until both the wiki and the first post of this thread are in agreeance, I will use spaces in foo_playcount.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 17:43:29
@kjoonlee
Well, i had play_counter already implemented. I didn't implement playdate, because the default format ensured that users would change it to something else - which basically means total chaos and that i would have to 'guess' what format the user uses. Thats almost impossible with something like dates (especially the position of the days and months). So, without code overkill, i couldn't do something like this. Then the standards-discussions happened and lasted for many weeks. After lots of arguing and discussion, last_played and first_played were finalized. No one else complained about it, so it was kinda "set in stone" (by being declared in the list in the first post). At that point, i as a FCS-author (not as an organizer of this thread) had something on which i could build, so i added last_played support to my formatting. I dunno if someone else also implemented last_played - all i know is that masstagger-scripts to convert to the new standard were downloaded hundreds of times in total (plus thousands of navigator-downloads which bundled the masstagger-scripts). How many people who downloaded the scripts actually used them, i dunno(but i guess most people dont download such things just for looking at the files).

Standardizing every tiny feature for sure would be overkill - but i do think that in some cases a good combination of default-format and an agreed standard makes sense and is achievable - if the community actually sticks to it, instead of reinventing the wheel over and over and only _increasing_ the confusion by doing so. Play_counter is actually used quite often in formatting string, and play_counter has a high userbase. With play_counter, last_played and first_played you can do very interesting playback-stats (like for example "average times played per day"). However, almost nobody made use of that yet - because there was no clear standardized implementation. I doubt it was because of lacking interest. This topic actually has wider coverage, than you may think: Lets take for example the smart-playlists requests, echoed multipletimes on the forums - for stuff like "top played tracks for this month" - besides of a lacking db-autorefresh, the mentioned standard was exactly what was missing to implement such stuff. iTunes, the mainstream musicplayer has it, and i guess we know quite well in what degree iTunes covers mainstream-needs. To keep it short: imho there is a need for it... the reason it wasn't done yet, was because of an ambigious play_date and the lack of first_played. People are interested in playback-stats - otherwise play_counter wouldn't be that popular in formatting-strings.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 17:50:50
I assume by your posts Lyx that you want to use underscores,  Change the Wiki, and I will gladly alter foo_playcount to comply.

As a note of historical reference, I argued quite heavily (early on in the discussion) that LAST PLAYED should be used as the default.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 17:51:20
Well, i guess my opinion is quite clear: Not to step on anyones shoes, but the community came to an agreement. Canar self-declared it as a "proposal" and put a comment on a place where people would not expect discussion of this stuff (since it happened in this thread). Since no one responded, he overrided the agreement of the community with his own views.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 17:53:00
Quote
I assume by your posts Lyx that you want to use underscores,  Change the Wiki, and I will gladly alter foo_playcount to comply.

As a note of historical reference, I argued quite heavily (early on in the discussion) that LAST PLAYED should be used as the default.
[a href="index.php?act=findpost&pid=297800"][{POST_SNAPBACK}][/a]

okay, gimme an hour to make me familiar with the wiki and look at that stuff a bit closer *not yet familiar with wikis yet*

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 17:55:14
And give me an hour to get a new build out.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 17:59:22
btw on the historical reference:
I would prefer spaces as well, _if_ play_counter would had used spaced when it was originally first released as well. With play_counter already having a wide userbase, ease-of-transition weighted in, so i agreed in the discussion to use underscores.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 18:03:04
BTW, you have contradicted your signature.  If the majority is wrong, we should use PLAY COUNTER
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 18:13:00
lol. That was more an anecdote towards the tendency of humans to become more stupid when they appear in larger packs  Crowd-dynamics and similiar stuff.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 18:14:49
Yes I know the anecdote and its intended meaning, just making a funny.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 18:23:21
I see the wiki is updated.  I've updated some other parts of the wiki also.  I've also released foo_playcount 1.7.3 which uses underscores.  See the thread for details.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 18:25:56
Hmm, the links in the TOC seem to work, but those in the summaries (although they're the same URLs) dont. But that was the case before my edit as well, so i guess either my browser is to blame, or the wiki itself. Anyways, that shouldn't be an issue, since the detailed descriptions are right below - its not such a big "article" after all.

I added that first_played as well uses the scheme of last_played to the page, while doing the edit.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-15 18:37:06
Quote
What happens now, do we go with spaces, or underscores.  Whatever happens, someone change either the wiki, or the first post here so I can follow one damn standard.  Until both the wiki and the first post of this thread are in agreeance, I will use spaces in foo_playcount.[a href="index.php?act=findpost&pid=297797"][{POST_SNAPBACK}][/a]


I've come to the conclusion that the foobar2000 community comprising the people who clamour for underscores are idiots who value backwards-compatibility over sensibility. As such, I will make every effort to ensure that the sensible thing wins out.

The comment about underscores sat on the Wiki talk page for a very long time. And despite all of the complaints about the change, noone has yet to actually give me any sensible, logical reason why using underscores is preferable other than backwards-compatibility.

If you care so much about backwards-compatibility at the expense of sensibility, go use Winamp. That's the Winamp philosophy, through and through.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 18:42:09
So basically you and Lyx are at opposite ends of the spectrum.  Seeing as Lyx builds Navigator, and I, along with many others, use Navigator I'm going to have to make it underscores (in fact I already have).  I don't like it either, but it's not a perfect world.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-15 18:46:28
kl33per, all I can do is encourage you to follow the foobar2000 philosophy that Peter adheres to and do the sensible thing instead of the backwards-compatible and popular thing.

Do so, and I'll freely update Navigator to get rid of the underscore idiocy for you.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 18:48:35
Simply said: i think the reason people in the past agreed to use underscores >in this single case< was because that having underscores was a low price to have backwards-compatibility. If there would have been more serious drawbacks, then the situation may have turned out different.

btw: i implemented the underscores variant after the original agreement, not the other way around - it wasn't "my standard".

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-05-15 18:51:00
Quote
And despite all of the complaints about the change, noone has yet to actually give me any sensible, logical reason why using underscores is preferable other than backwards-compatibility.

"Because Lyx doesn't want to change his fcs"

Lyx: would it have been so hard for you to do a search and replace for %play_counter% and change it to %play counter% or, even better, $if2(%play counter%,%play_counter%)?

It's a shame that we're back using underscores, but if we do make another change again at some point, I'd say lets use %play count% instead of %play counter%.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 18:52:27
The matter is closed anyway.  I've already promissed the masses that I wouldn't change the tagging system again any time soon.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-15 18:53:11
Backwards-compatibility is the single most useless argument that exists, especially for something with as low a userbase as this. Run a simple masstagger script. Backwards-compatibility issues are solved. If your userbase can't do that, they're idiots.

As for me, I'll stick with 1.72 until someone with a sensible solution to this problem comes along.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-15 19:04:18
Well then. As it's been decided that the underscored technique is preferable for reasons of backwards-compatibility can we at least agree that future multi-word "standard" tags will use a space as the standard instead of underscores?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 19:04:38
Quote
Quote
And despite all of the complaints about the change, noone has yet to actually give me any sensible, logical reason why using underscores is preferable other than backwards-compatibility.

"Because Lyx doesn't want to change his fcs" :ph34r:

Lyx: would it have been so hard for you to do a search and replace for %play_counter% and change it to %play counter% or, even better, $if2(%play counter%,%play_counter%)?

It's a shame that we're back using underscores, but if we do make another change again at some point, I'd say lets use %play count% instead of %play counter%.
[a href="index.php?act=findpost&pid=297831"][{POST_SNAPBACK}][/a]


May i remind you about the fact, that not i made this standard, but that part of the community which took part in the long discussion, when this standard was decided upon? I just scrolled through the original discussion, but i cannot find your name, anza - where were you when this topic was constantly on the fb2k-forums frontpage for a long perioud of time, and people worked on it? Where were you in the following months when someone who implements it in the plugin was missing? So, after a LONG time of discussion and wait, the necessary people stepped forward to make this agreement usable, and SUDDENLY you and others remember, that they have an opinion too?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 19:06:58
Quote
Well then. As it's been decided that the underscored technique is preferable for reasons of backwards-compatibility can we at least agree that future multi-word "standard" tags will use a space as the standard instead of underscores?
[a href="index.php?act=findpost&pid=297836"][{POST_SNAPBACK}][/a]


I dunno about others, but i_m with you on that, and think that overally, spaces are preferable. That was also the reason, why i voted against the use of underscores in the tag-value of first/last_played.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-15 19:19:36
Okay, so Lyx is pro-space (except for breaking backwards-compatibility), I'm pro-space, anza's pro-space, kl33per's pro-space... So who are we catering to by leaving underscores?

Edit: BTW, anza agreed with me when I first raised the space/underscore issue months ago. It was never resolved by anyone except the foo_playcount dev who decided unilaterally on underscores.
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-05-15 19:24:23
Quote
Quote
Quote
And despite all of the complaints about the change, noone has yet to actually give me any sensible, logical reason why using underscores is preferable other than backwards-compatibility.

"Because Lyx doesn't want to change his fcs"

Lyx: would it have been so hard for you to do a search and replace for %play_counter% and change it to %play counter% or, even better, $if2(%play counter%,%play_counter%)?

It's a shame that we're back using underscores, but if we do make another change again at some point, I'd say lets use %play count% instead of %play counter%.
[a href="index.php?act=findpost&pid=297831"][{POST_SNAPBACK}][/a]


May i remind you about the fact, that not i made this standard, but that part of the community which took part in the long discussion, when this standard was decided upon? I just scrolled through the original discussion, but i cannot find your name, anza - where were you when this topic was constantly on the fb2k-forums frontpage for a long perioud of time, and people worked on it? Where were you in the following months when someone who implements it in the plugin was missing? So, after a LONG time of discussion and wait, the necessary people stepped forward to make this agreement usable, and SUDDENLY you and others remember, that they have an opinion too?

- Lyx
[a href="index.php?act=findpost&pid=297837"][{POST_SNAPBACK}][/a]

1. The first part of my post wasn't an insult against you, I just stated the image I got from kl33per's decision.
2. The question I asked was really just a inquiry, I didn't mean to offend you with it. Sorry, I should've been more clear with that.
3. I didn't take part in this thread before, because I just couldn't care less about it (nor do I now). When kl33per changed the plugin to use spaces he first told that it was because of what was stated in the wiki. I thought that "ok, it must have been discussed in the wiki discussion and this is the new decided standard, great, finally the people understood that we do not need underscores anymore". Then people started fighting again about it and I thought that I could also jump in (in favor of what I thought was the new decided standard).

What I don't understand is that why is it so hard for people to run a simple masstagger script on their files and after a few seconds the transition to the new tag names is done. Same applies to fcs makers (and even the users - search and replace).

Anyway now I see that there was no change in the standard and it's fine for me, I don't use it anyway
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 19:24:40
Alright new tag for next build of foo_playcount.

LAST PLAYED BY

Stores the name of the last user to play that song.  It gets this from the user name that started the thread.
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-05-15 19:27:14
Damn I'd like to take part to this more now but I'm leaving in 3 minutes so all I say is this: What about making a poll about the space/underscore issue and see what the majority of the community thinks about it?
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 19:31:34
A poll isn't actually a half-bad idea.  What do you think Lyx?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 19:32:44
Quote
1. The first part of my post wasn't an insult against you, I just stated the image I got from kl33per's decision.
2. The question I asked was really just a inquiry, I didn't mean to offend you with it. Sorry, I should've been more clear with that.
3. I didn't take part in this thread before, because I just couldn't care less about it (nor do I now). When kl33per changed the plugin to use spaces he first told that it was because of what was stated in the wiki. I thought that "ok, it must have been discussed in the wiki discussion and this is the new decided standard, great, finally the people understood that we do not need underscores anymore". Then people started fighting again about it and I thought that I could also jump in (in favor of what I thought was the new decided standard).

Okay, sorry - i misunderstood you on that. No offense taken.

Quote
What I don't understand is that why is it so hard for people to run a simple masstagger script on their files and after a few seconds the transition to the new tag names is done. Same applies to fcs makers (and even the users - search and replace).[a href="index.php?act=findpost&pid=297846"][{POST_SNAPBACK}][/a]

Actually, it would be the second time, they have to masstag their files. If the spaces-variant would have gone through, then the situation would have looked like this to the rest of the users:
1. Oh, a new plugin which keeps track of how often i play my files, nice stuff!
2. (some months later) Hmm, some people have discussed about a different variant of the tags of this plugin. They say its better and SAFER(so, i will be on the safe side by using it, in terms of compatibility). They expect me to retag my entire files with the provided masstagger-scripts <insert inhibition/resistance to change here>.
3. (again, some months later) Cool, someone made an update to the component. It now also tells me when i played my songs the first time. However, they changed their "standard" again, so i again have to retag my entire files to use this new version. I though all this was so that my tags are compatible with new stuff in the future? Should i do this again? And if yes, will they maybe change it again in a few weeks?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 19:35:08
Allow me to remind everyone once again that if freeform tagging were supported, no one would have to retag every time the standard changes.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 19:38:21
It's not being added to foo_playcount, not by me anyway.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 19:41:37
Quote
Allow me to remind everyone once again that if freeform tagging were supported, no one would have to retag every time the standard changes.
[a href="index.php?act=findpost&pid=297855"][{POST_SNAPBACK}][/a]

Do you mean with freeform, that there basically is no standard, and everyone can tag their files however they like? That was exactly the situation before the standard-discussion started. The fact that plugin and formatting authors couldn't support them, did lead to the standards-discussion.

If you mean with freeform-tagging, that people can change their tags themselves, instead of relying on updated plugins, then that only solves the need for devs to update plugins. People would still need to remasstag their _existing_ files. Also, if a standard changes so often, that freeform-tagging becomes necessary, then there isn't really a standard in practice, because no one could built on them (because they wouldn't exist for long). Or in other words: when the situation becomes so that freeform-tagging becomes necessary, then its SNAFU anyways.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 19:48:30
Well, I meant custom field name selection. If I have 3000 files with PLAY COUNT, and with a version of foo_playcount that supports custom field names, but with a default setting of PLAY_COUNTER for instance, I can edit the TAGZ script and the foo_playcount settings without masstagging. It won't matter if it's PLAY_COUNTER or PLAY COUNTER.

Tagging standards are a myth, particularly with foobar2000. You can have recommendations, but you can't enforce them.
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-05-15 19:49:39
Quote
Do you mean with freeform, that there basically is no standard, and everyone can tag their files however they like? That was exactly the situation before the standard-discussion started.

Indeed. In the initial post you promised that
Quote
for users who don't want to use the proposed standards, the situation will stay as it is now.

I didn't expect this would also mean I'm stuck with component versions as from february 14th.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 19:51:27
We're not trying to enfore them.  Maybe edge people in a particular direction, but you can tag your files however you like.  Just don't come crying to plugin/FCS authors when you're tags aren't compatible with the encouraged standards.
Title: Tag-standards In Plugins<->formatting
Post by: kjoonlee on 2005-05-15 19:52:35
They are being enforced, in effect, because I can't use my own field names.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-15 19:57:52
In the end, it doesn't matter.  foo_playcount now writes PLAY_COUNTER, FIRST_PLAYED, and LAST_PLAYED as per the encouraged standards, and it's not going to change.  Endless debate over the subject will get us nowhere.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 20:00:22
I should choose my words more carefully - when i wrote that sentence in the beginning post, i was thinking about stuff like various artists, etc.

Duke it out with kl33per. While i don't like tagname-customization in plugins, i hinted already in earlier posts, that i'd vote "okay" for making tag-names customizable in a *clearly seperated* section/dialog(so, not encouraging it by putting those options all over the main-prefs, but instead making it a seperate "advanced option").

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-15 20:07:38
Quote
Tagging standards are a myth, particularly with foobar2000. You can have recommendations, but you can't enforce them.
[a href="index.php?act=findpost&pid=297861"][{POST_SNAPBACK}][/a]

I can only speak for myself: what i have in mind is something in-between encouragement and enforcement(the encouraging part comming from easy transition and additionaly-features/advantages. the "soft"-enforcement part coming from (hopefully) adoption in plugins and formattings.... when something is just used so widely, then at some point "doing my own thing" results in so much hassle, that it basically becomes a kind of enforcement - because all the good features would be somewhere else).
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-16 05:43:33
Removed, as I no longer agree with myself .
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-05-16 06:45:01
Sigh...I know I'm gonna get hell for this one, but...I think it should be PLAY_STAMP.

Look, I don't really care THAT much about whether underscores or spaces are used in the future, in general, all other things being equal.  But it's my opinion that this is a special case, because these four tags (FIRST_PLAYED, LAST_PLAYED, LAST_PLAYED_BY, and PLAY(_)STAMP) are all being written by the same component and are all dealing with the same kind of data.

Because of this, it seems more logical to me to use an underscore for PLAY_STAMP as well.

So, for future component developers, yes, go ahead and use spaces; we all seem to be split on that issue as a matter of opinion, so the choice is arbitrary.  BUT I believe it would make things easier when coding to remember that the play_count component always uses underscores:

"The play_count component uses underscores"
vs.
"The play_count component uses underscores, except for the PLAY STAMP field...or was it LAST PLAYED BY?"

As much disdain as there is for this antiquated method of formatting, I think it would only make things clearer to, in this special case, maintain the underscore.

edit: ignore what I said about LAST_PLAYED_BY, I overlooked the fact that username is being stuck on the end of the other fields.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-16 06:51:01
I really couldn't care less right now whether or not PLAY STAMP uses underscores or not.  What I want to know is does anyone have any objections to the proposed standard's format, or the amendments to LAST_PLAYED/FIRST_PLAYED.

Edit: As an aside, I have now built a version of foo_playcount that fully supports the above proposed standard and amendments.  This version will become available if/when the standard and amendment is approved.
Title: Tag-standards In Plugins<->formatting
Post by: Sam Stoat on 2005-05-16 09:25:42
Personally, I wouldn't use user names or PLAY_STAMP (or PLAY STAMP), but I understand others would.  Like all the other tags are, PLAY_STAMP should be optional, as should the appended user name, as it will be pointless to many people (including me).

I like the week day suggestion, but I think Monday should be the first day of the week (it is on my calander), but as long as a standard is set and stuck to, I'd be happy with any chosen day (just don't change the order ).

Finally, I agree with topdownjimmy that the component as a whole should use underlines or spaces, not mix and match.  I'd prefer spaces, but again, I'm easy.
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-05-16 12:14:35
Can the username addition be optional?  I'm not talking about custom strings or anything, just a checkbox asking if you want the username appended.  For me it's just an issue of my tags being tidier, but for others it might be a security thing if they're on a network.

I think it would be hard to disagree with the date/time format, but I did like the idea in the old standard of being allowed to add anything you want to the end of it.  People have a lot of eccentricities and in my opinion it would be nice to allow for those.

I guess the issue is: is it more important for .fcs developers to be able to confidently code for usename, or is it more important to allow more flexibility for the user?  I'm pretty torn.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-05-16 12:59:12
Quote
Personally, I wouldn't use user names or PLAY_STAMP (or PLAY STAMP), but I understand others would.  Like all the other tags are, PLAY_STAMP should be optional, as should the appended user name, as it will be pointless to many people (including me).

I like the week day suggestion, but I think Monday should be the first day of the week (it is on my calander), but as long as a standard is set and stuck to, I'd be happy with any chosen day (just don't change the order ).

Finally, I agree with topdownjimmy that the component as a whole should use underlines or spaces, not mix and match.  I'd prefer spaces, but again, I'm easy.
[a href="index.php?act=findpost&pid=298000"][{POST_SNAPBACK}][/a]

Well, Sunday is the first day of the week according to Windows, so I'm not going to change it.  PLAY_STAMP, like all the other tags is completely optional (and off by default).


Quote
Can the username addition be optional?  I'm not talking about custom strings or anything, just a checkbox asking if you want the username appended.  For me it's just an issue of my tags being tidier, but for others it might be a security thing if they're on a network.

I think it would be hard to disagree with the date/time format, but I did like the idea in the old standard of being allowed to add anything you want to the end of it.  People have a lot of eccentricities and in my opinion it would be nice to allow for those.

I guess the issue is: is it more important for .fcs developers to be able to confidently code for usename, or is it more important to allow more flexibility for the user?  I'm pretty torn.
[a href="index.php?act=findpost&pid=298027"][{POST_SNAPBACK}][/a]

I'm now torn to.  I like the idea that FCS and other plugin developers can take advantage of standardised features, but like you said it does remove some flexibility on the user side.

Edit: Removed my proposal, as I now disagree with it.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-05-16 14:34:07
A rather simple thought: is the demand for such a feature high enough, that a standard on it is necessary at all? Or is it more like an exotic feature which is interesting to some, but not more?

- Lyx

edit: kl33per, i think the appending-approach may be the only way to achieve some usability, on which you haven't thought yet. I'll explain it in more detail later today.

edit2: nevermind - i just saw that you implemented it in a much more elegant way than i thought, and by doing so solved the issues which my idea had.
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-05-30 10:04:54
Now that 0.9 beta is out and a there's a lot of plugins AND formatting strings that need porting, wouldn't this be a good time to remove the underscores from the tags that still use those? I mean, if all formatting strings need to be revised for 0.9, it wouldn't be a big deal to do a search & replace for those tags, would it? And same goes for plugin developers. Just a suggestion.
Title: Tag-standards In Plugins<->formatting
Post by: mixcherry on 2005-05-30 10:25:22
Quote
Now that 0.9 beta is out and a there's a lot of plugins AND formatting strings that need porting, wouldn't this be a good time to remove the underscores from the tags that still use those? I mean, if all formatting strings need to be revised for 0.9, it wouldn't be a big deal to do a search & replace for those tags, would it? And same goes for plugin developers. Just a suggestion.
[a href="index.php?act=findpost&pid=301694"][{POST_SNAPBACK}][/a]

I totally agree! 0.9 (+ columns ui 0.1.3) is very good moment to set one and only tags standard (and, after all, I think that spaces are better than underscores), as everyone (who wants to use 0.1.3) will have to change his strings. And what about changing PLAY COUNTER into PLAY COUNT?

And, if anyone is forced to stay with 0.8.3 (Win98?), then he will also stay with old versions of playcounter, columns ui and formatting strings.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-05-30 15:07:28
Quote
Now that 0.9 beta is out and a there's a lot of plugins AND formatting strings that need porting, wouldn't this be a good time to remove the underscores from the tags that still use those? I mean, if all formatting strings need to be revised for 0.9, it wouldn't be a big deal to do a search & replace for those tags, would it? And same goes for plugin developers. Just a suggestion.
[a href="index.php?act=findpost&pid=301694"][{POST_SNAPBACK}][/a]


I hardly think my position on this matter is in question.

I agree with anza, FWIW.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-07-17 14:55:25
Now that the dust on FIRST_PLAYED and LAST_PLAYED has settled, and the playcounter-plugin has been updated by kl33per - would it make sense to agree on a format for trackratings?

It seems that there are currently 2 competing variants in use:

- The first is using the fieldname RATING with an integer as its value.

- The second is used by people who want two seperate rating-tags for tracks and albums. Those people use the fieldname TRACKRATING (and sometimes ALBUMRATING?)


The Wiki (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standards#General_Tag_Construction) currently has the following to say about this:
Quote
Prefix album-related information with "ALBUM ", ie. "ALBUM ARTIST", "ALBUM SUBTITLE".


Thus, according to the wiki, it should be RATING and ALBUM RATING.

Any opinions on this?
- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: mixderax on 2005-07-17 16:01:04
<Kosh mode>Yes.</Kosh mode>
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-07-17 17:29:26
Quote
The Wiki (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Encouraged_Tag_Standards#General_Tag_Construction) currently has the following to say about this:
Quote
Prefix album-related information with "ALBUM ", ie. "ALBUM ARTIST", "ALBUM SUBTITLE".


Thus, according to the wiki, it should be RATING and ALBUM RATING.

Any opinions on this?
- Lyx
[a href="index.php?act=findpost&pid=314095"][{POST_SNAPBACK}][/a]


I use ALBUM RATING and RATING for album and track ratings respectively. Works great, and is most compatible with FCSes and things.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-25 12:46:04
[span style='font-size:14pt;line-height:100%']Final call for comments on RATING / ALBUM RATING. Drafting of VENUE[/span]


I propose the following tags to become recommended tag-standards:

RATING:
- used to rate individual tracks
- should contain an integer
- should not contain negative numbers
- should we propose or define a scale? (i.e. 0-5)

ALBUM RATING:
- to rate entire albums, EPs or split-singles
- every track of the set(i.e. the album) has to contain this tag with the same value
- should contain an integer
- should not contain negative numbers
- should we propose or define a scale? (i.e. 0-5)

VENUE:
- used to define the location of a live-recording
- feedback-wanted: should it be okay to use ALBUM and VENUE simultaneusly? Anything else we should define or keep in mind?
- how make the same song played at the same location but on different events, distinct? Could the DATE-tag help here? (is YYYY-MM-DD allowed for date?)

Please post your thoughts on the above! After 2 weeks of inactivity in this thread without someone posting concerns, i'll asume that people either think that its okay, or dont care, and add it to the recommended tagstandards.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Prodoc on 2005-09-25 13:44:24
Quote
VENUE:
- used to define the location of a live-recording
- feedback-wanted: should it be okay to use ALBUM and VENUE simultaneusly? Anything else we should define or keep in mind?
[a href="index.php?act=findpost&pid=329443"][{POST_SNAPBACK}][/a]

Sorry to barge in like this but imo VENUE doesn't make any sense. Is it the venue where the band had their first gigs? Is it the venue where the album got recorded? Is it the venue where the news songs of this album got played in public for the first time? VENUE can simply mean anything and it will make no sense to anyone who's never used this tag before. Instead, what about something like RECORDING_LOCATION? You can hardly get the meaning of this wrong

Something else...
Is their already a general consensus about disc titles? How should they be stored? For ID3v2 there's SETSUBTITLE (TSST) but what about the name for the tag for Vorbis and APE tags?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-25 13:53:59
Quote
Quote
VENUE:
- used to define the location of a live-recording
- feedback-wanted: should it be okay to use ALBUM and VENUE simultaneusly? Anything else we should define or keep in mind?
[a href="index.php?act=findpost&pid=329443"][{POST_SNAPBACK}][/a]

Sorry to barge in like this but imo VENUE doesn't make any sense. Is it the venue where the band had their first gigs? Is it the venue where the album got recorded? Is it the venue where the news songs of this album got played in public for the first time? VENUE can simply mean anything and it will make no sense to anyone who's never used this tag before. Instead, what about something like RECORDING_LOCATION? You can hardly get the meaning of this wrong ;)

Thats true - i agree that the FIELDNAME is not optimal. The reason why i still proposed to use it was because it is already established and supported. It is the standard for the taping-scene, the most often-used tag to define the liverecording-location, and already builtin in the new field remappings of foobar 0.9. Beat those advantages with something else, then we can consider an alternative.

P.S.: EVERY tag is always trackspecific unless it is prefixed with album (i.e. album artist, album rating, etc.). Therefore, VENUE could never be album-specific. The exception is %disc%.
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-09-25 17:01:12
RATING and ALBUM RATING look fine to me. I'll also vote for the 0-5 scale.

As for VENUE, at least I use it simultaneously with ALBUM if the show is from a bootleg cd. ALBUM then contains the name of the bootleg (eg "XXII II MCMXCIV") and VENUE the location ("Palaghiaccio, Roma, IT"). Also, if the album is a compilation of live songs, I use ALBUM tag, just to group the files as an album.

For the distinction, I currently use SHOW DATE and RECORD DATE (but I NEVER have both on one file). I actually can't remember why I started using both and I'm currently planning on just using RECORD DATE.
Title: Tag-standards In Plugins<->formatting
Post by: dano on 2005-09-25 17:18:50
0-5 scale? Most configs are made for 1-5 display or do they make a difference between RATING=0 and nonexistent rating tag?
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-09-25 17:46:21
I at least made a difference between RATING=0 and nonexistent RATING tag. If RATING=0, then it's rated really-really low, if there is no RATING tag, well then it is unrated.
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-09-25 20:14:55
Album Artist has beeen adopted by many people, and I've spotted various other album-based field names in the forum, like Album Composer, Album Date (http://www.hydrogenaudio.org/forums/index.php?showtopic=37319&view=findpost&p=329535), or Album Rating here. I suppose that people who are using these field names have a lot of $if2-statements like $if2(%album composer%,%composer%) in their title formatting codes. I think this could be simplified.

I would like to ask for your opinions about a new approach for album-based tags:

Remap %album name% to $if2(%album name%,%name%).
Remap %track name% to %name%, if $meta(name) and $meta(album name) are different.

Note: "name" is a placeholder for the real field name.

What do you think?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-25 22:29:04
Quote
0-5 scale? Most configs are made for 1-5 display or do they make a difference between RATING=0 and nonexistent rating tag?
[a href="index.php?act=findpost&pid=329494"][{POST_SNAPBACK}][/a]

Asking the other way around: could a value of "0" hurt? Most formatting-strings for example use $repeat for rating-display..... a value of 0 would result in the same display as if there is no rating-tag - so, no harm done.

concerning VENUE and DATE:
I just noticed, that whenever DATE is used, then it usually refers to the entire *album*. So, using DATE in a trackspecific way may lead to weird effects, because the general consensus is that DATE is "set-specific". As an example: if DATE would be used to store the live-recording-date of a track *and* this track is part of an album, then the DATE-tag would break the current rg-scan pattern of foobar 0.9(because it also groups albums by date).

Maybe a dirty (and popular) solution would be the easiest one? Store the date of the live-recording in the VENUE-tag as well, so that it is for example:

VENUE="Amsterdam, 2003-02-01"

From my experience, this "dirty but working"-scheme is already used by some tapers. Advantage would be that no additional fieldname is necessary, and no existing VENUE-tags need to be changed. Making a difference between "versions" could also be done this way. Basically "just put everything about the live-recording of this track into the VENUE-tag"? To make it sort-friendly, we could propose the "order" in which the info should be entered into the VENUE-tag(high-priority first, low-priority last)
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-09-25 23:50:41
Quote
Quote
0-5 scale? Most configs are made for 1-5 display or do they make a difference between RATING=0 and nonexistent rating tag?
[a href="index.php?act=findpost&pid=329494"][{POST_SNAPBACK}][/a]

Asking the other way around: could a value of "0" hurt? Most formatting-strings for example use $repeat for rating-display..... a value of 0 would result in the same display as if there is no rating-tag - so, no harm done.
[a href="index.php?act=findpost&pid=329555"][{POST_SNAPBACK}][/a]

1-5 is used by Amazon, it's pretty standard IMO
1: I hate it
2: I don't like it
3: It's OK
4: I like it
5: I love it

As for adding the date to Venue, isn't it redundant against %date% itself? (unless %date% actually means %year% and what you propose is to add the full date to Venue).
Title: Tag-standards In Plugins<->formatting
Post by: boombaard on 2005-09-25 23:55:21
all right.. here's my view then.. maybe it'll get some of the other folks to give their opinions on how they sort their collections as well

in the RG Scanner discussion thread i mentioned the sorting string i used for the scanner being
Code: [Select]
 %artist% - %conductor% - %band% - $if2(%performer%,%performers%)- %album%


which basically works very well, and even though the difference between %performer% and %performers% is mostly cosmetic (and hence somewhat superfluous), it does bring up a small point, namely which of the two to use when inputting performer names.

The singular form seems a bit odd when you've got more than one performer for any given piece, but it apparently is the 'vintage' tag field that is already supplied in fb2k (i really can't check since fb2k ofcourse remembers all fields that have been used since installation, and both are now listed there).

like i pointed out there, i'm slightly partial to the plural, but i can see how it's impractical if there already is a (widely?? i really don't know, since i don't know very many other people that listen to classical music that use fb2k) tagfield for exactly this

Other than that i tend to use the %album% field for the name of the Opus (ie. Piano Concerto No.7) while i use %contentgroup% for the actual opus number, including any name of the scheme that is used for the works of the composer. (ie. for Bach you have the Bach Werke Verzeichnis or BWV 1 to well over 1080, for Mozart the Köchel Verzeichnis (KV) which are named plainly KV 1 to KV 626).

i've noticed at least one person puts the opus number in 1 tag field, and the opus naming scheme indication in a different one, and while interesting, seeing how foobar seems incapable of sorting numbers that don't have the same amount of digits intuitively (ie. it doesn't read 1 as 001, or 0001 as required by the highest number in the field) it does not seem to be instrumental to having a nicely sorted playlist, mostly because i tend to sort by %album% in stead of %contentgroup%.

the %date% field is somewhat sufficient if and when you want to add information about when a particular performance was recorded/given, but you still lack a standard second field that you might use for recording when the actual work was written/released/performed for the first time.. i'm not sure what to use here, and so far have used the %year% field, though i'm not very fond of it, since it's fairly ambiguous in what it is actually for.

the %conductor% and %band% fields are my personal choices for conductor and orchestra respectively, and though band sounds a bit contemporary, it does cover what it's meant to very well as far as apt naming goes

a last tag field i can think of off the top of my head might be something like
%place where recording/performance took place%.

i'm just not sure what to call it ;-)

oh well.. try and poke holes in it and supplement my ideas if you would.. it'd be much appreciated if we could actually get this show on the road
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 00:08:58
Quote
As for adding the date to Venue, isn't it redundant against %date% itself? (unless %date% actually means %year% and what you propose is to add the full date to Venue).

I thought the same way at first. But as mentioned in my previous post, the problem is that DATE is *album-specific*. I wasn't consciously aware of that, but its indeed the case. Think about all plugins and formattings which make use of the DATE-tag - you dont need to stop at foobar, feel free to consider other apps as well. You will notice, that all the time we used DATE in an album/set-specific way. So, when we (or an app/plugin/formatting) sees a DATE-tag, then it asumes that it is specific to the entire album.

Why is this a problem? Well, consider a bootleg or collection of taped live-tracks. The CD may have an "albumname" as well. And the bootleg will have a date at which it was released. So, now, how do you differ between the date of the ALBUM and the date of the individual track-venues? But we dont even need to get think that far - think about date-display in albummode-formatting-strings - or about the recent idea to add DATE to the fb2k 0.9 RG-scanner pattern... in all those cases, track-specific DATE-tags would mess everything up....... because we asume that the DATE-tag is specific to the entire set of files(album).


I'll post tomorrow about the classical-music issue - need to get some sleep now.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 01:09:55
Ah, whatever, who needs sleep anyways?

Thoughts about the DATE-problem:

The basics: we have a fieldname for album-specific date (DATE) but no fieldname for trackspecific date.

There are three overall solutions of which i can think:

1. Just put the date into VENUE as well.
Advantage: no new tags necessary. Does not conflict with already existing VENUE-tags. Already in use.
Disadvantage: its dirty. If for whatever reason a trackspecific date-tag is needed somewhere else, then we have the same problem again.

2. Create a new fieldname like TRACKDATE
Advantage: clean solution. "future-safe" because TRACKDATE can be recycled for other uses as well.
Disadvantage: no one uses it yet (difficult adoption - we will start from scratch in terms of userbase). inconsistent with the desired paradigm "every tag is trackspecific, unless the fieldname is prefixed with album. There is no "track-something"

3. Completely revamp the DATE-scheme: DATE (trackspecific) / ALBUM DATE (albumspecific)
Advantage: the "proper" solution.
Disadvantage: it will break everything DATE-related, cause confusion and in addition no one uses it yet. Widespread adoption will therefore be "nearly impossible". It would be "us against the rest of the world"


Quote
all right.. here's my view then.. maybe it'll get some of the other folks to give their opinions on how they sort their collections as well

in the RG Scanner discussion thread i mentioned the sorting string i used for the scanner being
Code: [Select]
 %artist% - %conductor% - %band% - $if2(%performer%,%performers%)- %album%

Please explain someone who is less experienced with classical music (although i like to listen to it sometimes - but less "serious") the meaning of those tags:

ARTIST: would be the original composer, right?
CONDUCTOR: got it, no questions
BAND: ??? am i right to suspect, that we dupe the ARTIST-field here, because it is already taken with the composer-name?
PERFORMER: ???



Quote
...which basically works very well, and even though the difference between %performer% and %performers% is mostly cosmetic (and hence somewhat superfluous), it does bring up a small point, namely which of the two to use when inputting performer names.

Just use multiple PERFORMER-fields. Files can have multiple entries of the same fieldname. So, you can have more than one ARTIST-field, multiple GENRE-fields, multiple PERFORMER-fields, and so on. IIRC, you do it by simply seperating the entries with a backslash. For example:

In the ARTIST-edit-dialog: artist1\artist2\artist3

Will automatically turn into:
ARTIST=artist1
ARTIST=artist2
ARTIST=artist3

In a playlist, it will be shown like this: artist1, artist2, artist3

The disadvantage is that there is some uncertainity how other apps/devices will interprete this. I am quite certain that they will read at least the first tag, but i am not sure what will happen with the others. Anybody has more info in this matter?


Quote
Other than that i tend to use the %album% field for the name of the Opus (ie. Piano Concerto No.7) while i use %contentgroup% for the actual opus number, including any name of the scheme that is used for the works of the composer. (ie. for Bach you have the Bach Werke Verzeichnis or BWV 1 to well over 1080, for Mozart the Köchel Verzeichnis (KV) which are named plainly KV 1 to KV 626).

Umm, there HAS to be a better way to do it.... but i'm not sure yet how.


Quote
the %date% field is somewhat sufficient if and when you want to add information about when a particular performance was recorded/given, but you still lack a standard second field that you might use for recording when the actual work was written/released/performed for the first time.. i'm not sure what to use here, and so far have used the %year% field, though i'm not very fond of it, since it's fairly ambiguous in what it is actually for.

COMMENT-field. This seems the kind of "exotic case/exception" which should go into the "catch-it-all" tag known as COMMENT. Unless you want to be able to sort by it - then you may indeed want to create a custom field for it, just for your personal use.

Quote
a last tag field i can think of off the top of my head might be something like
%place where recording/performance took place%. :P

VENUE :-) Discussion ongoing.
Title: Tag-standards In Plugins<->formatting
Post by: c0utta on 2005-09-26 02:06:06
Lyx,

Normally I would weigh into a discussion like this, but I have also been frustrated by the album date / track date issue.  This particularly annoys me when dealing with Soundtracks and some Various Artist albums.  I have been seeking my own solution but these posts have raised my interest again in coming up with my own solution.  If it can meet the needs of the rest of the community then great.

I think that option 2 - Create a new fieldname like TRACKDATE (should that be TRACK DATE ?) is probably the most viable.

Yes, option 3 is the "proper" solution, albeit more difficult, but maybe there's a compromise of using 3 tags - DATE, ALBUM DATE & TRACK DATE.  This would at least allow some kind of backward compatibility with the DATE tag:

%albumdate% = $if2(%DATE%, %ALBUM DATE)
%trackdate% = $if2(%TRACK DATE%, %DATE%)
%date% = $if2(%DATE%, $if2(%ALBUM DATE%, %TRACK DATE%))

This may not suit everyone's needs, but it will satisfy most requirements.

I'll just fade into the background again...

c0utta
Title: Tag-standards In Plugins<->formatting
Post by: hunted on 2005-09-26 04:01:19
I just wanted to point out that $if2(a,$if2(b,c)) is the same as $if3(a,b,c)
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-09-26 05:23:47
TRACK DATE works great for compilations but sounds a bit odd when all tracks in the medium (single, ep, lp) have the same date although different from the medium's release date. 2 examples:
- Remastered albums: Both Release Date and Original Date are album specific (may be CD Release Date and Original Release Date for old albums).
- Live albums consisting of one unique session: Both Release Date and Recording Date are album specific.
Title: Tag-standards In Plugins<->formatting
Post by: boombaard on 2005-09-26 09:09:40
Quote
Quote
all right.. here's my view then.. maybe it'll get some of the other folks to give their opinions on how they sort their collections as well

in the RG Scanner discussion thread i mentioned the sorting string i used for the scanner being
Code: [Select]
 %artist% - %conductor% - %band% - $if2(%performer%,%performers%)- %album%

Please explain someone who is less experienced with classical music (although i like to listen to it sometimes - but less "serious") the meaning of those tags:

ARTIST: would be the original composer, right?
CONDUCTOR: got it, no questions
BAND: ??? am i right to suspect, that we dupe the ARTIST-field here, because it is already taken with the composer-name?
PERFORMER: ???


Ok.. Well.. i'll take the piano concerto as an example
this is a piece with a conductor, an orchestra, and one or more soloists (the performers), where the soloist tends to be better than "just" an orchestra player, and as such is capable of performing without direct support (of more people playing the same instrument with him). also when you have pieces like sonatas, they're performed by one or more soloists, without orchestral+conductoral support (usually in a group the violinist or pianist is appointed conductor)
many conductors are also (good) soloists on some instrument, since you have to learn to play at least one instrument during your studies to become a conductor..

%band% is what i thus use for orchestra (mostly because i didn't feel the need to create a new tag field that had exactly the same function as band, but just sounded better
oh, and i tend to (sort of) duplicate the %artist% field into the %composer% field, mostly because some composers have special characters in their names which don't always display well on all systems.. i then put the 'normal' version in %artist% while i put the correct spelling in %composer%.. and otherwise i just duplicate it.. artist is a bit useless in this respect, imho.. it's too ambiguous a field name.

Quote
Quote
...which basically works very well, and even though the difference between %performer% and %performers% is mostly cosmetic (and hence somewhat superfluous), it does bring up a small point, namely which of the two to use when inputting performer names.

Just use multiple PERFORMER-fields. Files can have multiple entries of the same fieldname. So, you can have more than one ARTIST-field, multiple GENRE-fields, multiple PERFORMER-fields, and so on. IIRC, you do it by simply seperating the entries with a backslash. For example:

In the ARTIST-edit-dialog: artist1\artist2\artist3

Will automatically turn into:
ARTIST=artist1
ARTIST=artist2
ARTIST=artist3

In a playlist, it will be shown like this: artist1, artist2, artist3

The disadvantage is that there is some uncertainity how other apps/devices will interprete this. I am quite certain that they will read at least the first tag, but i am not sure what will happen with the others. Anybody has more info in this matter?
as long as the backslashes work, %performer% should be fine then

Quote
Quote
Other than that i tend to use the %album% field for the name of the Opus (ie. Piano Concerto No.7) while i use %contentgroup% for the actual opus number, including any name of the scheme that is used for the works of the composer. (ie. for Bach you have the Bach Werke Verzeichnis or BWV 1 to well over 1080, for Mozart the Köchel Verzeichnis (KV) which are named plainly KV 1 to KV 626).

Umm, there HAS to be a better way to do it.... but i'm not sure yet how.


ah, yes.. you've got a bit of a point there.. there's a bit of a schism between classical music collectors/sharers about how to actually store your music.. should this be done as full albums, or as 1 Opus per subdirectory..
either way has its advantages, to be honest.. i'm partial to the latter as you might've noticed, but you would have a bit of a problem if you'd want to use the former with just an %album% field, yes.. another field would have to be thought of for them/by them.. but i can't really think of non-lame sounding field names
i suppose %Opus(or work) Name% would do the trick, but it's not really something you'd intuitively do, if you ask me

Quote
Quote
the %date% field is somewhat sufficient if and when you want to add information about when a particular performance was recorded/given, but you still lack a standard second field that you might use for recording when the actual work was written/released/performed for the first time.. i'm not sure what to use here, and so far have used the %year% field, though i'm not very fond of it, since it's fairly ambiguous in what it is actually for.

COMMENT-field. This seems the kind of "exotic case/exception" which should go into the "catch-it-all" tag known as COMMENT. Unless you want to be able to sort by it - then you may indeed want to create a custom field for it, just for your personal use.


again, this depends on what you use the %album% field for.. if you use it for the Opus name, it's fine.. if you don't, you'd indeed need something else.. i wouldn't use the %comment% tag myself, because it implies it's only relevant to very few people, and while it is, it is (or can be) quite relevant to the performance
Title: Tag-standards In Plugins<->formatting
Post by: richard123 on 2005-09-26 12:10:20
For classical, I prefer the simpler approach of

Artist - composer

Album - album name as reflected on the cover of the cd/whatever

Performer - performer, including soloist, orchestra, conductor, etc.  A piano sonata will have fewer entries than a symphony.  I just include the names, not designation
Title: Tag-standards In Plugins<->formatting
Post by: richard123 on 2005-09-26 12:12:38
Dealing with first and last names

How do you deal with an artist with a first name?  Alternatives seem to be

First Last
Last, First
Last

How about artists with 'the'?

Band
Band, The
The Band
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 14:13:43
Quote
Dealing with first and last names

How do you deal with an artist with a first name?  Alternatives seem to be

First Last
Last, First
Last

How about artists with 'the'?

Band
Band, The
The Band
[a href="index.php?act=findpost&pid=329691"][{POST_SNAPBACK}][/a]

IMHO, this is personal preference and does not belong into a tag-standard.
My *personal* opinion is that it should be "firstname lastname" and "the band". The application shall then check if the tag begins with a "the" and strip it if necessary. However, i really think that defining this in a tag-standard is overkill. What we try to do here is not to come up with a strict rule which tells how users have to do every little detail of tagging, but instead just to define a general "framework" which ensures that the most important things "just work".
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 14:33:31
Quote
2 examples:
- Remastered albums: Both Release Date and Original Date are album specific (may be CD Release Date and Original Release Date for old albums).

"Original Date" is a new kind of metadata - unless i'm missing something, it has nothing to do with the current discussion of a track-specific date-tag - because, as you point out yourself, it is about an *additional* albumspecific date-tag.

Quote
- Live albums consisting of one unique session: Both Release Date and Recording Date are album specific.

No, they are not. The tracks in this case have all the same trackspecific date just by coincidence. It basically goes like this: You have two live-CDs. The tracks on the first CD are from different events and therefore have different trackspecific dates. The tracks on the second disc all have the same trackspecific dates.

Sure, it will look a bit strange, but then again, what is the alternative? having 100 different kinds of date-tags in files, just so that it is "absolutely properly"? The thing is, if you go about the problem with the "it has to be 100% correct"-mentality, then there is no end in sight.... one issue will lead to the next one, and you end up inventing a truckload of new tags, which will in turn make it unviable for the mainstream. In that sense, i think the priority of minimizing the amount of fieldnames should be higher than the priority of "making it 100% correct". A flexible solution which "just works" with a low amount of tags for most people, and only results in some minor flaws for the minority, is preferable over a "100% correct"-solution which tries to make it right for every possible exotic exception case, yet resulting in being suboptimal for everyone.

It's the same as with the feature-request and options-bloat issue: you cannot make something perfect for everyone - thats an illusion, because complexity will rise so much that it becomes suboptimal for everyone. Thus, the goal IMHO shall not be to make it perfect, but instead come up with something which just works for the majority, while still being "usable" in most exception-cases.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 14:58:15
Quote
ah, yes.. you've got a bit of a point there.. there's a bit of a schism between classical music collectors/sharers about how to actually store your music.. should this be done as full albums, or as 1 Opus per subdirectory..
either way has its advantages, to be honest.. i'm partial to the latter as you might've noticed, but you would have a bit of a problem if you'd want to use the former with just an %album% field, yes.. another field would have to be thought of for them/by them.. but i can't really think of non-lame sounding field names :P
i suppose %Opus(or work) Name% would do the trick, but it's not really something you'd intuitively do, if you ask me

Personal enlightment: what we are talking about here are CHAPTERS.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 15:17:16
need feedback:

What kind of date-metadata can people think of?

Currently we have:
1. the date when a set(album) was *released*
2. the date when a track was *performed*
3. the date when a set(album) was *performed*
4. the date when a set(album) was *released for the first time*
5. the date when a track was *released for the first time*

Anything else?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 20:53:32
Seems like no.

Okay, how about the following:

Quote
VENUE
- contains info about "where" and "when"(optional) a recording was performed

- the order of the info in this tag should be "highest-priority first, lowest-priority last". Example: "country, city, location, eventname, yyyy-mm-dd, version".

- all info is optional - just make sure that the order is kept right

- use the ISO-format for date: yyyy-mm-dd

- this tag is trackspecific. This means that the tracks of a set(i.e. album) may contain different VENUE-tags. If all tracks of a set were performed at the same venue(i.e. a taped live-show), then consider to use the ALBUM-tag instead.




Quote
ORIGINAL DATE (fieldname up for discussion)
- contains the date at which a track was originally released.
- only use this tag if you want to be able to sort your files by original date. Else just use the COMMENT-tag with a note like "Originally released in 1984".
- the tag is trackspecific. If all tracks of an album have the same original date, then you need to dupe the info for every track of the album.
- date-format follows the ISO-standard and may be: yyyy OR yyyy-mm OR yyyy-mm-dd




The above solution would cover the following demands:

Quote
1. the date when a set(album) was *released* - covered by DATE
2. the date when a track was *performed* - covered by VENUE
3. the date when a set(album) was *performed* - not covered - use the ALBUM-tag or COMMENT-tag instead
4. the date when a set(album) was *released for the first time* - not covered - use duped info of ORIGINAL DATE instead
5. the date when a track was *released for the first time* - covered by ORIGINAL DATE


Advantages:
only 1 new tag needed and even that one is optional. Partially already in widespread use(venue) so transition will be easy.

Disadvantages:
"perfomed date" is not directly sortable. No albumspecific tag for "date of original release"(but that should less be a problem, because obviously, the trackspecific original date, and the albumspecific original date, cannot be different)

Opinions?

One alternative would be to make VENUE both, trackspecific or albumspecific, depending on if an ALBUM-tag does exist or not.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 21:53:51
[span style='font-size:14pt;line-height:100%']Revised proposal for tagging live-performances and dates[/span]
Changes: VENUE-tag is hybrid albumspecific and trackspecific. Date comes first in VENUE to make it sortable.

Quote
VENUE
- contains info about "where" and "when" a recording was performed

- the order of the info in this tag should be "highest-priority first, lowest-priority last". Example: "yyyy-mm-dd, country, city, location, eventname, version".

- all info is optional - just make sure that the order is kept right

- use the ISO-format for date: yyyy-mm-dd. The date should always be at the beginning to make the tag sortable.

- this tag can be albumspecific OR trackspecific, depending on if an ALBUM-tag does exist or not. It works similiar to the ALBUM ARTIST / ARTIST scheme.

- albumspecific-mode: Neither the track, nor other parts of the same set, may contain an ALBUM-tag. In this mode, the VENUE-tag replaces the ALBUM-tag. All tracks of the set need to contain the VENUE-tag with identical values. This mode is useful if all tracks of the set were performed at the same venue(i.e. a taped live-show). It is also useful for single tracks which are not part of a set.

- trackspecific-mode: The track and all other tracks of the set, MUST contain an ALBUM-tag! Then, the VENUE-tag is interpreted as being specific to individual tracks. So, various tracks of the same set may contain different VENUE-tags. This is useful for sets which contain tracks which were performed at different venues(i.e. a collection of live-shows).



Quote
ORIGINAL DATE (fieldname up for discussion)
- contains the date at which a track was originally released.
- If you want the info to be also readable in applications/devices which do not support custom-tags, then dupe the info into the COMMENT-field(i.e. "Originally released in 1984")
- the tag is trackspecific. If all tracks of an album have the same original date, then you need to dupe the info for every track of the album.
- date-format follows the ISO-standard and may be: yyyy OR yyyy-mm OR yyyy-mm-dd




The above solution would cover the following demands:

Quote
1. the date when a set(album) was *released* - covered by DATE
2. the date when a track was *performed* - covered by VENUE in trackspecific-mode
3. the date when a set(album) was *performed* - covered by VENUE in albumspecific-mode
4. the date when a set(album) was *released for the first time* - not covered, because it seems unnecessary(albumspecific original-date and trackspecific original-date could never be different)
5. the date when a track was *released for the first time* - covered by ORIGINAL DATE


Question: do you think that it makes more sense to make VENUE trackspecific only, or to make it both? Trackspecific only would have the advantage of being less ambigious, but would break album-grouping of files which lack an ALBUM-tag although they are part of a set. On the other hand, VENUE in albummode is basically just a dupe of the ALBUM-tag.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: topdownjimmy on 2005-09-26 22:44:01
Quote
Dealing with first and last names

How do you deal with an artist with a first name?  Alternatives seem to be

First Last
Last, First
Last

How about artists with 'the'?

Band
Band, The
The Band
[a href="index.php?act=findpost&pid=329691"][{POST_SNAPBACK}][/a]

I was highly conflicted about how to handle this myself.  The system I eventually worked out is that i use two fields for the artist (if necessary):  ARTIST would be "The Band," and ARTISTSORTORDER would be "Band, The."  This way I can sort properly but also display the name the way it's spoken, not alphabetized.  Same goes for ALBUMSORTORDER.  I think I saw this used somewhere else and decided to commit to it.  I don't know if this is the kind of thing that really needs standardization though...
Title: Tag-standards In Plugins<->formatting
Post by: picmixer on 2005-09-26 22:45:50
Whilst this all certainly perfectly makes sense I fear this is all getting a little bit too complicated for a simple standard that should help the general users and help compatibility between scripts.

I guess the most important thing would be to concentrate on the basic tags of various stiles of music (genral, classic, live, blah blah). Having 6 different kind of date options simply sounds to me as if things are getting a bit overcomplicated again.

Also having a track and an album specific option for each tag sounds a bit over the top too me.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 22:56:23
Quote
Also having a track and an album specific option for each tag sounds a bit over the top too me.
[a href="index.php?act=findpost&pid=329801"][{POST_SNAPBACK}][/a]

The problem is, this IS already the case. VENUE right now can be used trackspecific as well as albumspecific(which for example is the reason why it is covered by the %album%-fieldremappiing).

So the question is: should it stay that way, or should it be simplified(which may cause some disruption)?
Title: Tag-standards In Plugins<->formatting
Post by: foosion on 2005-09-26 23:19:13
Quote
Quote
VENUE
- contains info about "where" and "when" a recording was performed

- the order of the info in this tag should be "highest-priority first, lowest-priority last". Example: "yyyy-mm-dd, country, city, location, eventname, version".

- all info is optional - just make sure that the order is kept right
[a href="index.php?act=findpost&pid=329795"][{POST_SNAPBACK}][/a]

For my taste, you are focusing on sorting too much. If you want a single tag to define the sorting order of live performances, why don't you call it %live performance sort order% then?

First off, let me say that most of my live recordings are from the Live Music Archive of the Internet Archive and are tagged from text files using foo_tradersfriend (who would have guessed? ). I hope this helps you understand where I am coming from, since this heavily influenced my tagging habits for live recordings.

I personally don't like the idea of mixing space and time coordinates in a single tag like this. While the least-specific to most-specific scheme makes perfect sense for time coordinates, I feel it isn't appropriate for the space coordinates at hand. After all, most live performances aren't at State #29, City #2643, Street #117, House #46. Instead the locations tend to have far more descriptive names, sometimes the most specific part is even globally unique. In other cases it still is relatively unique and you only need the less specific parts to provide a namespace for disambiguation. Example for the former that came to my mind: What locations are in Amsterdam, Netherlands (in Hamburg, Germany)? Where is Melkweg (Grünspan)?

Let me illustrate why I think your proposal is bad for presentation. Here is a list of dates and locations formatted according to your proposal (they are from Umphrey's McGee shows, by the way):
Code: [Select]
2001-06-02, Chicago, IL, Schuba's
2001-12-31, Chicago, IL, The Vic Theater
2002-05-16, Chicago, IL, Schuba's
2002-12-31, Chicago, IL, The Vic Theatre
2003-11-29, Chicago, IL, House of Blues
2004-08-07, Chicago, IL, Skyline Stage at Navy Pier


Here is the same data formatted as it is shown in my playlist*:
Code: [Select]
2001-06-02 / Schuba's - Chicago, IL
2001-12-31 / The Vic Theater - Chicago, IL
2002-05-16 / Schuba's - Chicago, IL
2002-12-31 / The Vic Theatre - Chicago, IL
2003-11-29 / House of Blues - Chicago, IL
2004-08-07 / Skyline Stage at Navy Pier - Chicago, IL


Now take a sheet of paper and cover the right half of these lists to simulate truncating like in a playlist, if there is not enough space. Which do you think is more informative? Of course this is a matter of personal taste, but I know which I like better.

*: Actually my playlist format is configured to show only the part of the venue before the first " - ". Just because I like it better that way.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-26 23:39:15
@foosion
Thanks for those explanation. Makes perfect sense IMHO. I also like the idea of using "/" as a seperator between data-types.

How about this?:
<yyyy-mm-dd> / <geographical info> / <other info>

All of those being optional of course.
Title: Tag-standards In Plugins<->formatting
Post by: ssamadhi97 on 2005-09-26 23:53:00
Quote
Code: [Select]
2004-08-07, Chicago, IL, Skyline Stage at Navy Pier

[a href="index.php?act=findpost&pid=329810"][{POST_SNAPBACK}][/a]


fixed that for you:
Code: [Select]
2004-08-07, USA, Illinois, Chicago, Navy Pier, Skyline Stage

[a href="index.php?act=findpost&pid=329810"][{POST_SNAPBACK}][/a]
Title: Tag-standards In Plugins<->formatting
Post by: foosion on 2005-09-27 00:04:09
Lyx:
Sorry to disappoint you, but I only use " / " as a separator on the playlist. My dates still reside in plain old %date% tags (and I intend to keep it that way). Don't let that keep you from the designing the next-generation tagging scheme though.

ssamadhi97:
Ah, yes. I just ran a simple titleformatting script on my existing tags. Too lazy for manual work.

[span style='font-size:8pt;line-height:100%']Argh. Mind drifts off into insanity. Must get a big can of sleep.[/span]
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-27 00:48:12
new proposal:

Quote
VENUE
- contains info about "where" and "when" a recording was performed

- example: "2002-12-31 / The Vic Theatre - Chicago, IL / Dave's version"

- the order of the info in this tag should be: 1. date / 2. geographical-info / 3. other info.

- seperate data-types with slashes.

- all info is optional - just make sure that the overall order is kept right. Date needs to be at the beginning in the ISO-format yyyy-mm-dd.

- you may format the geographical-info as you like

- this tag is trackspecific. This means that tracks of a set(i.e. album) may contain different VENUE-tags(useful for example for a compilation of live-shows).

- to clearly "group" a set of performances(i.e. a recorded live-show consisting of multiple tracks, or a compilation of live-performances), the ALBUM-tag should be used.

- Important for developers: VENUE may be used as a poor-man's "set-grouping" if no ALBUM-tag does exist: $if2($meta(album),$meta(venue)).
However, the mere existence of a VENUE-tag should not be used as an indicator that the track is part of a set(album) - this mostly affects displays and formatting-strings. VENUE does not mean "it is part of an album"!



Quote
1. the date when a set(album) was *released* - covered by DATE
2. the date when a track was *performed* - covered by VENUE
3. the date when a set(album) was *performed* - not covered, because it seems unnecessary: the trackspecific venue and albumspecific venue could never differ)
4. the date when a set(album) was *released for the first time* - not covered, because it seems unnecessary: the trackspecific original date and albumspecific original date could never differ
5. the date when a track was *released for the first time* - Not covered because its use is too exotic. But you could use a custom trackspecific tag like ORIGINAL DATE for personal use
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-27 02:23:09
Quote
I would like to ask for your opinions about a new approach for album-based tags:

Remap %album name% to $if2(%album name%,%name%).
Remap %track name% to %name%, if $meta(name) and $meta(album name) are different.

Note: "name" is a placeholder for the real field name.

The idea of introducing another abstraction-layer is interesting, but at least the first remapping may lead to weird results.

Example:
Lets say we have a playlist in albummode. The first track of the album has a RATING-tag, but no ALBUM RATING-tag. But the reason for this is not that i use RATING in an albumspecific way - instead, i just dont use albumspecific rating at all and only rate individual tracks. Then, your proposed remapping would turn RATING into an ALBUM RATING, if the used playlist uses this remapping somewhere.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-09-27 10:43:42
Quote
5. the date when a track was *released for the first time* - Not covered because its use is too exotic. But you could use a custom trackspecific tag like ORIGINAL DATE for personal use

I perfectly understand the need not to overcomplicate things but exotic is not the word I would use here. IMO every non-live compilation, best of, anthology etc. should use such tag. Perhaps it could come handy to merge venue date and original date into a %track date% tag again, which I agree is less self-explanatory. It would still allow for English sentences such as if($and($stricmp(%version%,live),$or(%venue%,%track date%)), Recorded live[ in %venue%][ on %track date%])

Rough draft proposal
- VENUE
No date, just what it means in English. If you've recorded birds singing in your girlfriend's garden, you may just write "My girlfriend's garden" =)
- DATE
The ISO full date or just the year (ID3v1 compatibility) the album was released (or recorded - I'm not sure what's more important/standard at the moment). All tracks in a given album should have the same %date% tag value.
- TRACK DATE
THE track-specific date tag, covers both track's original release date (compilations, covers, remastered versions etc.) and track's recording date (live shows). Professionals and/or geeks might wish to split it into a gazillon of tags though: Recorded, Released, Acquired, Last Edited, Composed etc.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-27 13:13:50
Quote
Rough draft proposal
- VENUE
No date, just what it means in English. If you've recorded birds singing in your girlfriend's garden, you may just write "My girlfriend's garden" =)

- TRACK DATE
THE track-specific date tag, covers both track's original release date (compilations, covers, remastered versions etc.) and track's recording date (live shows). Professionals and/or geeks might wish to split it into a gazillon of tags though: Recorded, Released, Acquired, Last Edited, Composed etc.

Why the merger? You are mixing two semantically different kinds of metadata together here. For example, boombaard brought up the question how he shall tag where and WHEN a classical album was *performed* and additionally when (the composer) did originally released it. This isn't possible anymore in your proposal. So, what are the advantages?


edit: using slashes as seperators may be a bad idea, because the windows filesystem does not support them - thus, when renaming files according to VENUE, then the slashes would be turned into underscores. Has anybody a better idea on which character to use as a seperator?
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-09-27 13:49:38
Maybe, but you're also mixing 2 different kinds of metadatas by associating a date and a location in %venue%
The advantages would be:
- we have an album specific date and a track specific date
- we don't have to struggle to extract a date or a location out of %venue% (although I admit it'd be ok if we used clean separators and always the same date-location order)
One possible disadvantage is we'd get 2 tags instead of one...

Boombaard, being a classical music lover, falls into the "geeks who might wish a gazillon of date tags" category (j/k). I'm not forcing anyone but he could use %date% and %track date% as proposed (album release date & track performance date) and use another tag (eg %composed%) for the date the partition was published (if that's what you meant by "when the composer did originally release it"). In the album list one could use eg:
%artist%|if3(%composed%,%track date%,%date%,...)|...
and
%performer%|if3(%track date%,%date%,...)|...

edit:
Quote
Has anybody a better idea on which character to use as a seperator?

A comma?

Edit2: Well on second thought it'd be wiser to mention a date in %venue% because of the remappage to %album%. Unles I missed something %venue% is track specific and %album% obviously isn't, so unless Peter backs it out, the hardcodded RG scanner would break album splitting when %album% is missing and %venue% is the same (less likely to occur when a date is mentioned). A bit nitpicky though...
That said, I'd prefer if the date was at the end of the value.
- It's about a venue, the actual venue has prority IMO
- If you sort by venue, it's expected to get your tracks sorted by venue instead of pseudo-chronogically

Edit3: Lyx, is there any solid reason why %date% should be album specific anyway? If not, what about %date% and %album date%? This'd be consistent with both %album artist% and Vobis standard field names and their intented use (http://xiph.org/vorbis/doc/v-comment.html).
Title: Tag-standards In Plugins<->formatting
Post by: boombaard on 2005-09-27 22:26:24
Quote
Boombaard, being a classical music lover, falls into the "geeks who might wish a gazillon of date tags" category (j/k).


it's not so much that i desire adding info to tags like a madman (i'm fairly minimalistic about it), but at times (say with tours) you have a concert on december 7th, and december 8th of the same year, at the same location.. if you want to have both recordings (when, say, one is far more emotionally expressive than the other, and you like both), it's sort of nice to be able to tag them properly ;P

and tbh, i just use the standard %date% tag for that.. i don't really need %track date% tags, since one performance is usually (nearly) long enough to fill an album
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-28 08:29:35
Quote
Maybe, but you're also mixing 2 different kinds of metadatas by associating a date and a location in %venue%

Yes, but there are 2 differences. The first is that in my case they are related(date and location of PERFORMANCE), while in your case they are unrelated(date of PERFORMANCE, date of original RELEASE, date of <whatever>). The second is that the two "kinds" of data in my VENUE-draft can easily be distinguished(a date looks different than a text, plus if the date is at the beginning, then it can easily be found) - with your proposal there are no cues to distinguish between the various meanings. Why is this bad? Because the *meaning* of the tag would become so ambigious that in practice when files were tagged by different people and are in the same playlist, the meaning of the contents of the tag would change at will on a per-track basis - without being able to distinguish between them. Now tell me: how should a FIND-feature, a playlist-display, a database-patternmatcher, a <insert any feature which makes use of this tag>, how should any of those then make any sense of the tag-contents anymore when the meaning of the contents changes at will with no way to distinguish between them?

You may argument that this wouldn't be a problem for people who only have self-tagged files, but this thought would be short-sighted - here's why: If this argument would be true, then we wouldn't need any tag-standards at all - everyone could just invent their own tags and as long as they stick to them it would work. But the reason why we are discussing here is because we EXPECT the multi-user-scenario to happen - we expect that a single user, a single app, a single plugin, a single playlist-formatting.... will be confronted with files which were tagged by various users. If everyone would only use his self-tagged files, use his self-coded mediaplayer with self-coded plugins and self-coded playlist-displays, then there would be no need for any standard.... but this is obviously not the case. Thats why we are trying here to make the file-tags, plugins, playlist-designs, etc. of various users compatible with each other. If the meaning of the contents of a tag change at will, then we just invented a pseudo-standard because the only thing we standardized was the fieldname(descriptor), but not its meaning(semantics).

To sum it up: in my humble opinion, a multi-meaning date-tag is bad. Either make a combo VENUE-tag for date and location, or make it VENUE and VENUE DATE.

Quote
The advantages would be:
- we have an album specific date and a track specific date

A few days ago i was a proponent of the "recycleable TRACK DATE", now i'm an opponent of that idea(reasons explained above). But lets look at it from a different angle:

Quote
1. date when a set(album) was *released* - covered by DATE
2. date when a track was *performed* - covered by VENUE
3. date when a track was *released for the first time* - could be covered by something like FIRSTRELEASE DATE/ORIGINAL DATE
4. date when a track was *recorded* - covered by VENUE, same as "performed"
5. date when a track was acquired - NOT covered and IMHO unnecessary to standardize
6. date when a track was last edited - covered by filesystem
7. date when a track was composed - for classical music covered, same as "first released"

Now tell me why do we need a "standardized" multi-meaning tag, when all of the above(except one) can be covered with something like FIRSTRELEASE DATE/ORIGINAL DATE - an unambigious tag with a clear meaning. What advantage would 1 more ambigious tag have over 1 more unambigious tag? What would be missing, except REALLY exotic cases which shouldn't be standardized anyways? What i am getting at is: Do we actually need a "flexible" trackspecific date-tag anymore?

Quote
- we don't have to struggle to extract a date or a location out of %venue% (although I admit it'd be ok if we used clean separators and always the same date-location order)

True, but then we have to struggle with figguring out the meaning of TRACK DATE, which is even worse. The contents would be just a number without any cues on what it represents. Not even the most 1337 TAGZ-code will be able to figure out the meaning reliably.


Quote
That said, I'd prefer if the date was at the end of the value.
- If you sort by venue, it's expected to get your tracks sorted by venue instead of pseudo-chronogically

Is it? When people sort by venue, then do they care more about the venue than the band? Or is their mind-pattern instead "band->venue"? If it is the latter, then they would sort by venue to get the "performance(s)" of a band in chronological order(i.e. a tour). What would people want to do more often: sort by location or sort by date? Also, if you dont put the timestamp at the beginning, then it will become very difficult to extract the date with TAGZ. If it can only be at the beginning, then you know where to look for it, if its not, then you need to play resource-hungry *guessing* by parsing the entire contents and looking for cues - did i mention already that TAGZ does not allow to search for numbers?(unless you are me and do weird hacks for guessing tracknumbers from filenames - but such things should not be necessary and are definatelly not viable for a low-priority tag because its too resourcehungry - besides, date-extraction should also be doable for mortals ;). As a minor bonus, if the date is at the beginning in ISO, then it should be rather easy to make it compatible with IFGREATER.

Quote
Quote
Has anybody a better idea on which character to use as a seperator?


A comma?

Commas may also be used en masse in the geographical data. The seperator should be unique enough to make the data-types visually distinct.

Quote
Edit2: Well on second thought it'd be wiser to mention a date in %venue% because of the remappage to %album%

"If" VENUE gets standardized as a trackspecific tag, then i'm not sure if the %album%-remapping should stay as it is. At least if an ALBUM-tag exists, it should probably instead be added to the TITLE.

Quote
Edit3: Lyx, is there any solid reason why %date% should be album specific anyway? If not, what about %date% and %album date%? This'd be consistent with both %album artist%

Covered earlier in the discussion - probably one page back in this thread. Most people use DATE in an albumspecific way - i do not propose to make it that way(i'd prefer the opposite ;), i just admit that it is already the case in the mainstream. And we are talking about an ID3V1-tag here. Changing that would mean "us against the rest of the world". Lets not touch ID3v1 tags in a disruptive way - it'll make all hell break loose. Actually, i dont even propose to "define" that DATE is albumspecific but instead just ignore it. The only reason why i mentioned its albumspecific use was to make the problem easier to understand(most people(including me until a few days ago) dont even realize that they are using it like an album date tag most of the time... it has become so normal, that noone even notices it anymore)

I will start a poll later to check how many people really want to store when a track was released the first time. If the demand is low, then its not worth to standardize it.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: boombaard on 2005-09-28 09:29:15
Quote
Quote
Quote
Has anybody a better idea on which character to use as a seperator?


A comma?

Commas may also be used en masse in the geographical data. The seperator should be unique enough to make the data-types visually distinct.


what about a simple dash?
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-09-28 22:43:05
in playcount, i've coded in ";" (semi-colon) as the delimiter.
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-09-30 11:47:57
You've had me convinced, I'll stick to %date% as it is and won't try to standardize any track specific date except possibly within %venue%

edit: Semi-colon doesn't look too bad to me. What'd be the best method to tell date from location then? If date is unknown, should %venue% begin with a separator?
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-09-30 12:32:45
I understand the logic, but I still find it quite silly to have the date info first in a tag called VENUE. So I'd like to leave the date information out of VENUE - or at least put it to the end of it. This way (as Olive pointed out) we don't need to prefix the venue information with a separator if the date is unknown.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-30 13:16:00
Quote
If date is unknown, should %venue% begin with a separator?

That would not be necessary and look weird for display. Seperators arent even needed to check if the date exists in that case. IF you know the exact position of the date, then you can just check the dashes:

Code: [Select]
$if(
$and(
$strcmp($strstr($meta(venue),-)5),
$strcmp($strstr($meta(venue),-)8)
)
,$puts(venuedate,$left($meta(venue),10))
)

Plugins can probably use more advanced regexp-like pattern-searching anyways, so this is purely a TAGZ-issue.

But if the exact possible position of the date is not known, then it becomes really complicated. This is also the reason, why it is rather easy to split up date and text if the date can only be at the beginning - but the position of the date is not exactly known, then it is very complicated to split it up into two parts.

Quote
So I'd like to leave the date information out of VENUE - or at least put it to the end of it. This way (as Olive pointed out) we don't need to prefix the venue information with a separator if the date is unknown.

As shown above, a beginning seperator if no date is available is not necessary. I'm strongly against putting the date after the text, because it would:
1. make the date-part useless for processing
2. make it practically impossible to split up the tag into date and text with TAGZ

IMHO, it should be "either at the beginning, or leave the date completely out and put it in a seperate tag".

Advantages of a seperate tag:
"more clean", most easy to process with TAGZ, both date and location sortable, freely formattable.

Disadvantage of a seperate tag:
added complexity(2 tags instead of one), venue-set-grouping would need to take both tags into account instead of one

I'd say it comes down to the question: How often will people want to search by location and how often will they visually not like that date is at the beginning? If the answer to both is "significantly often", then a 2-tag-approach should be used. Else, two tags would be overkill.
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-09-30 13:30:40
errm what if only the year is known? you're using 2005-xx-xx ?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-09-30 13:33:57
Hmm, good question...
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-09-30 13:59:42
Just to point out that if we were to use 2 tags, it wouldn't be necessary to explicitly standardize venue date. %venue date% results from the %date% and %venue% standards, and from the "space prefered to undescore" recommendation.
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-09-30 14:24:27
If you insist on having the date info in VENUE you could always format it like this Astoria Theatre (Sub Pop Lame Fest), London, UK; 1989-12-03. It's still easy to process (just look for the semicolon, or use $right(%venue%,10) to get it out (if you know the exact date).
I still don't like the idea of combined venue and tag information. Or if we do that, then invent a better name for the tag. I'll at least stick with my "VENUE=just the venue", "DATE=individual track date" and "ALBUM DATE=album date if the album is a compilation".
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-09-30 15:51:17
Or if date's first, make it explicit:

- VENUE = Date: 1989-12-03; Location: London, UK
- VENUE = Date: 1989; Location: London, UK
- VENUE = Date: 1989-12-03
- VENUE = Location: London, UK

That way you can use $left(%venue%,4) to check if date is known and so on. Works with virtually any date format.
"Location: " may not be needed then: VENUE = Date: 1989-12-03; London, UK isn't really ambiguous and might look better.
The disadvantage is it may look a bit silly to humans as they intuitively know it's a date =)

edit: Or @ wouldn't look too bad a prefix:

1989-12-03@Astoria Theatre
1989@Astoria Theatre
@Astoria Theatre
1989-12-03

Not confusing, unless you're using 1337 f0rm@771ng
Title: Tag-standards In Plugins<->formatting
Post by: ssamadhi97 on 2005-09-30 20:13:20
Quote
I'll at least stick with my "VENUE=just the venue", "DATE=individual track date" and "ALBUM DATE=album date if the album is a compilation".
[a href="index.php?act=findpost&pid=330619"][{POST_SNAPBACK}][/a]

Sounds like a good idea to me. Consistent with ARTIST / ALBUM ARTIST too.

putting both date and venue into a tag called VENUE sounds kinda stupid to me (no offense)
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-10-02 01:55:54
That's been suggested on page 12, and Lyx made some good points against it, but yes that'd be fairly clean and consistent.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-02 02:08:46
The problem with DATE is: What do people use it for? Usually to enter the date when a CD was published. Notice the "CD" in that sentence, which basically equals to "set". Thus, almost the entire mp3-world currently uses DATE like ALBUM DATE. Yes, it sux and is wrong, but thats how it is.

I'll not be the one who proposes to turn an ID3v1-tag into the opposite of how it is usually used.

If i would be the one to invent an entirely new tagging-scheme from scratch, without the need to care about backwards-compatibility, then i would prefix every single tag with eitheer TRACK or SET to avoid such confusions beforehand. But well, since we have the mess already and rely on support and adoption, we need to care about backwards-compatibility..... especially in terms of ID3v1-tags which are almost "holy" ;-)
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-10-02 13:09:41
Then what about RECORD DATE? I didn't invent it myself, I'm sure I found it somewhere on these boards (it was some kind of "recommended Musepack tag names" thread, or a link to a page like that). People could continue using DATE as they do (ie as ALBUM DATE) and the RECORD DATE could be the TRACK DATE.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-03 03:46:13
Okay, after getting a bit of distance from the topic, my intuition tells me that there are two sane approaches we could take from here:

1) We asume that the venue-date is not that important, and that therefore it does not need to be extracted, sorted or processed. In that case we can go with just VENUE, put the date in it, and possibly dont even need strict rules on how and where to put the date in VENUE.

2) We consider the venue-date to be important and want it to be extractable, sortable and easy to process. Since we want multiple date-formats to be valid(yyyy, yyyy-mm and yyyy-mm-dd) it would be a bad idea to put it into VENUE, because you need at least multiple checks just to find out in which format it is. So, the only option is to put it into a seperate tag, like VENUE DATE.

We can even - inofficially - allow both variants: if we say that the user can put whatever he likes about the venue into VENUE(so, more like a very short comment-field for all things venue) and the date of the venue into VENUE DATE...... then in practice if a user ignores VENUE DATE and puts the date into the VENUE-tag..... then he still got a perfectly valid VENUE-tag..... he just cannot expect that apps, plugins and displays allow sorting and processing of the venue-date.

This would also have the advantage, that all already existing VENUE-tags stay valid.
Title: Tag-standards In Plugins<->formatting
Post by: ssamadhi97 on 2005-10-03 11:52:44
Quote
The problem with DATE is: What do people use it for? Usually to enter the date when a CD was published. Notice the "CD" in that sentence, which basically equals to "set". Thus, almost the entire mp3-world currently uses DATE like ALBUM DATE. Yes, it sux and is wrong, but thats how it is.[a href="index.php?act=findpost&pid=330963"][{POST_SNAPBACK}][/a]

Actually using DATE and ALBUM DATE would not be a problem or unusual at all. The use of both tags would be exactly the same as the use of ARTIST and ALBUM ARTIST is now - a standard tag that's used "as usual" and a new one that can be used to override the old one on album level when necessary.

And usage habits from the days of a fixed set of fixed-length metadata fields should not bear any relevance at all in this day and age, especially if new usage patterns would consistent both within themselves (!) and with the old way (like this one).
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-04 11:44:50
Quote
Actually using DATE and ALBUM DATE would not be a problem or unusual at all. The use of both tags would be exactly the same as the use of ARTIST and ALBUM ARTIST is now - a standard tag that's used "as usual" and a new one that can be used to override the old one on album level when necessary.

Interesting solution. The question then would be - considering the previously mentioned problems of multi-meaning-tags - what kind of metadata should be allowed in DATE/ALBUM DATE? I'd asume "published" for sure.... mainly left are...... date of performance....... what about an officially *published* CD containing live-performances..... the CD would have a date when it was published, and the tracks would have dates when they were performed.... one may be tempted to use ALBUM DATE and DATE for that.... but remember the problems associated with mixing the meaning of a tag (in this case DATE).
Title: Tag-standards In Plugins<->formatting
Post by: fabiospark on 2005-10-04 18:15:58
I think you will never be able to standardize which date to put into the single "date" field.

There are too many things to track if one cares.

For example, being a jazz fan I can think of:

- recording date (many times, on the same album have being grouped tracks recorded at very different times. Even in non compilation albums)

- releasing date (= album date if it's not a compilation)

- reissuing date (thinking of all those jazz remastered that sounds really different from the originals (not always better...) eg. kind of blue or JSP Armstrong hystorical recordings)

But being a classical fan too, I can also think of:

- publishing date (the date recorded in the hystorical books as the birth date of a piece. Useful if somebody will ever develop a "timeline" plugin or just to put the piece in an hystorical and cultural period. You could even guess the kind of music just from the date, sometimes.)

- plus the three dates listed above

So, if we have only one date field, everybody will fill it with the data more sensible to him.

A point I don't understand is the distinction between track and album fields: for me every field is tracks based - you have to fill all the tracks with it. It will automatically become an album field whenever all the tracks of an album will have the same value in that field.
Also, as somebody already stated, sometimes the "album" distinction is meaningless so, in that case, every album field would be redirected to the new grouping at risk of creating confusion: In my opinion, album must always be album and if one needs a different grouping he should create that and so its date field. For grouping the different movements of a classical piano concert I created the field "work" where I put the name of the concert. It's easy to add a "work date" field.

This is just my opinion and the way I tagged my collection.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-04 18:43:01
In other words, a multi-meaning date-field leads to a mess.

I propose:
VENUE and VENUE DATE.

We can care about "publish date" in a track and album variant (DATE and ALBUM DATE) later.
Title: Tag-standards In Plugins<->formatting
Post by: picmixer on 2005-10-04 19:14:48
Seriously, why make things so complicated. Why not use %date% and %album date% and let people decide themselves how to make use of those. And those two should really be enough for quite a few different scenarios.

In case someone has any really exotic tagging needs he can always add his own custom tags after all.

Personally I still think if there should be any official tagging recommendation then it should be kept simple and not overly confusing to new users. Advanced users know how to suit their tagging needs anyway.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-04 20:53:32
Quote
Seriously, why make things so complicated. Why not use %date% and %album date% and let people decide themselves how to make use of those. And those two should really be enough for quite a few different scenarios.


Because of this:
http://www.hydrogenaudio.org/forums/index....ndpost&p=330102 (http://www.hydrogenaudio.org/forums/index.php?showtopic=31530&view=findpost&p=330102)
Title: Tag-standards In Plugins<->formatting
Post by: picmixer on 2005-10-04 21:39:58
Quote
Quote
Seriously, why make things so complicated. Why not use %date% and %album date% and let people decide themselves how to make use of those. And those two should really be enough for quite a few different scenarios.


Because of this:
http://www.hydrogenaudio.org/forums/index....ndpost&p=330102 (http://www.hydrogenaudio.org/forums/index.php?showtopic=31530&view=findpost&p=330102)
[a href="index.php?act=findpost&pid=331651"][{POST_SNAPBACK}][/a]


Yeah, this is part of what I mean. 
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-10-05 06:08:06
So to summarise Lyx's proposal...

DATE = Per-track published date (for compilation albums, otherwise set to same date across all tracks for regular studio albums)

ALBUM DATE = date the album was published (in the event that DATE is not same on all tracks in the album, eg. compilation, otherwise tag not included)

VENUE = Location of the recording, be it a particular studio, or live venue

VENUE DATE = date of the recording

Do I understand this correctly?

What about a date tag for the original release of an album as apposed to a remastered version.  How do people handle that?
Title: Tag-standards In Plugins<->formatting
Post by: Insolent on 2005-10-05 07:38:34
Quote
So to summarise Lyx's proposal...

DATE = Per-track published date (for compilation albums, otherwise set to same date across all tracks for regular studio albums)

ALBUM DATE = date the album was published (in the event that DATE is not same on all tracks in the album, eg. compilation, otherwise tag not included)

VENUE = Location of the recording, be it a particular studio, or live venue

VENUE DATE = date of the recording

Do I understand this correctly?

What about a date tag for the original release of an album as apposed to a remastered version.  How do people handle that?
[a href="index.php?act=findpost&pid=331750"][{POST_SNAPBACK}][/a]

Setting DATE to the individual track date would confuse the hell out of everyone outside this thread, as it is most commonly (read: exclusively) used for the album's date of publication. Remember, what is defined here is only really a tag standard for members-of-HA-that-have-read-this-thread, not a global standard. If we think of everything defined here as a global standard, we're pretty much alienating the rest of the mp3 world.

My proposal:

DATE = Date (year) album was published
TRACK DATE = Per-track publishication date (for compilation albums)
VENUE = Location of the recording, be it a particular studio, or live venue
VENUE DATE = Date of the recording
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-10-05 09:56:19
You missed the point about ALBUM DATE.  ALBUM DATE would work exactly like ALBUM ARTIST, if it's there, it functions as the album's date, otherwise it defaults to the date tag.  For people who don't use ALBUM DATE, it makes no difference.
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-10-05 11:27:19
Quote
VENUE DATE

There is already RECORD DATE in the APEv2 specifications (http://web.archive.org/web/*/www.personal.uni-jena.de/~pfk/mpp/sv8/apekey.html).
Title: Tag-standards In Plugins<->formatting
Post by: Insolent on 2005-10-05 12:21:38
Quote
You missed the point about ALBUM DATE.  ALBUM DATE would work exactly like ALBUM ARTIST, if it's there, it functions as the album's date, otherwise it defaults to the date tag.  For people who don't use ALBUM DATE, it makes no difference.
[a href="index.php?act=findpost&pid=331780"][{POST_SNAPBACK}][/a]

I still don't see the point in interrupting something as 'standard' as DATE (it was added in the ID3v1 spec for containing the album's release date, and that's what its been used for ever since) when we can bypass the problem altogether and use TRACK DATE.

Then it keeps everyone happy (and is slightly easier to code for).


Eg:

DATE = 2005
TRACK DATE = 1987


To display per-track date:
Code: [Select]
%track date%

To display album date:
Code: [Select]
%date%

As opposed to:

DATE = 1987
ALBUM DATE = 2005


To display per-track date:
Code: [Select]
$if(%album date%,%date%,)

To display album date:
Code: [Select]
$if2(%album date%,%date%)


Just my $0.02 worth...
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-05 12:53:48
Quote
So to summarise Lyx's proposal...

DATE = Per-track published date (for compilation albums, otherwise set to same date across all tracks for regular studio albums)

ALBUM DATE = date the album was published (in the event that DATE is not same on all tracks in the album, eg. compilation, otherwise tag not included)

VENUE = Location of the recording, be it a particular studio, or live venue

VENUE DATE = date of the recording

Do I understand this correctly?

Yes.


Quote
There is already RECORD DATE in the APEv2 specifications.

Quote
I still don't see the point in interrupting something as 'standard' as DATE (it was added in the ID3v1 spec for containing the album's release date, and that's what its been used for ever since) when we can bypass the problem altogether and use TRACK DATE.

Although backwards-compatibility and transparency with other standards is desirable, we also need to care about OUR set of standards having at least a bit of consistency... this of course is not always possible, but it is as desirable as the other factors. Imagine someone reading the set of recommended tag-standards who didn't read about it before... what would seem more attractive to him... it being a collection of exceptions? One time you do it this way, and the next time you do it the other way? Or if the "logic" behind those recs has some kind of consistency... a bit like "once you got it, you also understand the rest"? While i'm strongly protective of ID3v1-standard tags(and with this i do mean the FIELDS, not the id3v1-standard itself), the DATE and ALBUM DATE is the least-disruptive proposal i've seen yet... if that idea is bad, then ALBUM ARTIST would be even more bad(after all, people use ARTIST much more often than DATE). But no one here complains about ALBUM ARTIST, so did it work out or not? If yes, then why should it not work out with ALBUM DATE?


I'll need to concentrate on other task for a few days, so i'll just close not with a proposal but with a hint on how to bring this thread forward:

I think we well not get anywhere, if we continue discussing this way.... because we are discussing too many issues at once. Once you agree on one end, there will be criticism at the other end... and so the discussion runs cyclic.

I'd say, decide if a multi-meaning tag is bad or desirable. Once you have settled on that question, it is much more easy to focus.... if you come to the conclusion that it is desirable, then you can just need to standardize VENUE, and go with a trackspecific date and an albumspecific date, and you're done......... or if you come to the conclusion that a multi-meaning date-field with no cues is bad, then you can focus on VENUE and VENUE DATE...... and ignore the other issues for now, because they are something seperate.
Title: Tag-standards In Plugins<->formatting
Post by: Insolent on 2005-10-05 13:35:30
Quote
While i'm strongly protective of ID3v1-standard tags(and with this i do mean the FIELDS, not the id3v1-standard itself), the DATE and ALBUM DATE is the least-disruptive proposal i've seen yet... if that idea is bad, then ALBUM ARTIST would be even more bad(after all, people use ARTIST much more often than DATE). But no one here complains about ALBUM ARTIST, so did it work out or not? If yes, then why should it not work out with ALBUM DATE?
[a href="index.php?act=findpost&pid=331817"][{POST_SNAPBACK}][/a]

Well, here's my opinion on the ARTIST and DATE tags:

ARTIST = Artist of the track (not the album)
DATE = Date of when track was published on ALBUM (not its initial publication)

So:

[span style='font-size:8pt;line-height:100%']ARTIST = Joe
ALBUM ARTIST = Various Artists[/span]

We have ARTIST set to the artist of the track, not the album. So ARTIST is used correctly and thus ALBUM ARTIST isn't 'bad'. Really, all ALBUM ARTIST is is a flag to tell us the album contains various artists...

But:

[span style='font-size:8pt;line-height:100%']DATE = 1987
ALBUM DATE = 2005[/span]

Is, IMO, incorrect and stupid. Also, if someone were to not add the ALBUM DATE tag we'd have an album with 20 different dates and wouldn't know what to make of it. Whereas with ALBUM ARTIST, if someone didn't add the ALBUM ARTIST tag but set the ARTIST, it doesn't really matter does it?

To be honest, I really don't care what happens on the issue. I don't really want to know (or care to bother tagging) when tracks were initially published, so I probably won't even ever both with ALBUM/TRACK DATE.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-10-05 17:36:16
How can you say it's incorrect and stupid when both examples are exactly the same, only the type of date changes (artist to date).  The solution is the same in both cases.  You can't logically argue that ALBUM ARTIST makes sense, but ALBUM DATE doesn't make sense.

On the issue of tags with multiple types of data.  In general, I'm against it.  If you think of a database, each coulumn has a specific type (int, char, bool, etc.) and a label indicating what sort of information might be contained in each row (title, artist).  I think about tags from the point of view of a mini-database.  The VENUE tag says what venue the recording took place at.  Not the date of the recording, not the air-temperature at the time, but the venue.  All other data should be contained elsewhere.

The issue should not be cluttered tags.  IMO, if tags are cluttered it's because we haven't developed a good way of displaying all the data we can sotre about a track.  In general, the more data you have, the more things you could do.  For example, with a venue tag, you could find all the recordings that took place at the Blue Note club in NYC, just by running a query.
Title: Tag-standards In Plugins<->formatting
Post by: ssamadhi97 on 2005-10-05 22:35:05
Quote
DATE = 2005
TRACK DATE = 1987


To display per-track date:
Code: [Select]
%track date%

To display album date:
Code: [Select]
%date%

As opposed to:

DATE = 1987
ALBUM DATE = 2005


To display per-track date:
Code: [Select]
%track date%

To display album date:
Code: [Select]
%album date%


Just my $0.02 worth...
[a href="index.php?act=findpost&pid=331808"][{POST_SNAPBACK}][/a]

I fixed that for you... (field remappings for the win)
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2005-10-06 09:38:52
As I understand, the proposal with dates
ALBUM DATE --- the date of album release (i. e. and the date of release for every track)
VENUE DATE --- the date of recording (live concert or studio session)
DATE --- track date.
I'd like to know what is the "track date" and why anybody needs it? If it is a date of initial, original publication then what with songs performed by different artists in different genres. I think nobody really needs track date. Venue date yes but not original publication date.
If anybody uses this date, I'd better group it with some other information.
ORIG ALBUM --- original publication of this track.
ORIG ALBUM DATE --- date of original publication
ORIG ARTIST --- artist of this track on the original album
ORIG VENUE --- place where this song was first performed
ORIG VENUE DATE --- date of performance.
ORIG VENUE ARTIST --- artist performed this song first.
The other problem I'd like to consider are remastered albums. They have two releases and I'd like to use there first release date for sorting and searching. Date of their second release may exist only for information and what would be the name of this date? REMASTERED DATE?
Title: Tag-standards In Plugins<->formatting
Post by: picmixer on 2005-10-06 16:33:49
Well for consistency reasons I would simply suggest to use %date% and %album date% then.

If no album date is present date simply represents the album date if an album date is present it represents the track date. Similar to artist and album artist.

If people want they can still always use venue date then. Although I personally can't think of an example where that is really needed since I cannot come up with anything where album date would differ from venue date.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-10-07 05:03:10
That's easy, DATE/ALBUM DATE are publication dates, VENUE DATE is the recording date.
Title: Tag-standards In Plugins<->formatting
Post by: ssamadhi97 on 2005-10-07 09:59:57
nah, obviously VENUE DATE is the date the venue was built. 
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-10-07 10:26:19
I'd still go for DATE, ALBUM DATE and RECORD DATE.

edit: and the RECORD DATE would be what Lyx has proposed VENUE DATE to be.
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2005-10-07 11:34:39
Quote
That's easy, DATE/ALBUM DATE are publication dates, VENUE DATE is the recording date.
[a href="index.php?act=findpost&pid=332277"][{POST_SNAPBACK}][/a]

And what is the difference between DATE and ALBUM DATE?
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-10-07 12:04:01
Quote
And what is the difference between DATE and ALBUM DATE?
[a href="index.php?act=findpost&pid=332338"][{POST_SNAPBACK}][/a]


DATE is normally the date the album was released. ALBUM DATE is mostly for compilations. For them, DATE is the date the track was released (originally?) and ALBUM DATE is the date the compilation was released.
Title: Tag-standards In Plugins<->formatting
Post by: richard123 on 2005-10-07 15:15:52
Date for a normal album could mean many things.  Take an album from the 1970's originally released on LP, then on CD, then on remastered CD.  Which is the most relevant DATE? Should there be more than one DATE field?
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-10-07 16:06:02
That's one of the things we're discussing about. In your example, I'd use DATE for the original LP release date and ALBUM DATE for the date of the album. To distinguish between the original and remastered CDs, just use add (remastered) after the album name.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-09 00:29:04
Does that mean that most people agree in going with:

DATE
ALBUM DATE
VENUE
VENUE DATE/RECORD DATE

?

Ignoring exotic cases of course.
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-10-09 01:09:43
Quote
Does that mean that most people agree in going with [...] ?

Considering the low amount of different faces in this thread, I would say no.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-09 02:02:40
Well, then the missing faces shall read the this and the previous 2 pages.... and then voice their opinion or opt for neutrality(silence)
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-10-09 14:09:34
Quote
Does that mean that most people agree in going with:

DATE
ALBUM DATE
VENUE
VENUE DATE/RECORD DATE

?

Ignoring exotic cases of course.
[a href="index.php?act=findpost&pid=332816"][{POST_SNAPBACK}][/a]

I'm OK with VENUE. There's still something I don't like about these dates as standard, don't know exactly what though =)

First, %album date% is consistent with %album artist% but it seems that the rest of the world already use %date% as freedb's DYEAR (year in which the CD was released).

Second, what would you do for a CD compiled from 2 or more live shows? %album date% for the CD's release date, %venue date% for each track's recording date, what for %date% then?

Not sure what to propose then :/
Maybe Get rid of %venue date% as a standard, it's obvious what the track specific date is for (be it %date% or %track date% : Original release date in compilations, Recording date in lives.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-09 15:06:19
Quote
Second, what would you do for a CD compiled from 2 or more live shows? %album date% for the CD's release date, %venue date% for each track's recording date, what for %date% then?

There are two methods which are "correct" then - a simple one, and an unnecessary complicated one:

simple: DATE for album-date(because it doesnt change throughout the compilation), VENUE DATE for the live-show performances

complex: ALBUM DATE for the album-date, then ALBUM DATE duped to DATE, and then VENUE DATE for the live-show performances


Quote
Maybe Get rid of %venue date% as a standard, it's obvious what the track specific date is for (be it %date% or %track date% : Original release date in compilations, Recording date in lives.

As pointed out about 4 times now, it is obvious to you, but not obvious to a machine!
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2005-10-09 15:26:47
I would stick with the following
DATE for album date (If album was released remastered, then the date of the original album release). That means that the date would be used to sort the discography hronologically.
VENUE for the place the track was performed at.
VENUE DATE for the date the track was recorded.

Edit: I would add something like `remastering date' for remastered albums. For compilation I would use something like `orig date' and `orig album'. But not date as date of the original publication has nothing to do with track date.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-09 16:43:53
Quote
I would stick with the following
DATE for album date (If album was released remastered, then the date of the original album release). That means that the date would be used to sort the discography hronologically.
VENUE for the place the track was performed at.
VENUE DATE for the date the track was recorded.

Edit: I would add something like `remastering date' for remastered albums. For compilation I would use something like `orig date' and `orig album'.
[a href="index.php?act=findpost&pid=332965"][{POST_SNAPBACK}][/a]

If you add ALBUM DATE to the equation, then you get the "orig date" for free: no matter if its a compilation or remastered album, you can just enter the published date of the CD to ALBUM DATE, and the "orig date" to DATE.

Quote
But not date as date of the original publication has nothing to do with track date.

Oh? Please explain - both are publishing dates.... either of the CD itself or of a track. DATE (in track-mode) *is* "the date when the track was originally published". Thats part of the proposal. How can it be something different when the proposal strictly defines that this tag is just for that?
Title: Tag-standards In Plugins<->formatting
Post by: foosion on 2005-10-09 19:40:46
Quote
As pointed out about 4 times now, it is obvious to you, but not obvious to a machine![a href="index.php?act=findpost&pid=332962"][{POST_SNAPBACK}][/a]

Even a sentient machine would have problems deducting the meaning of the %venue date% tag given its name; see also ssamadhi97's comment about this.

If you can live with tags with underspecified semantics and only care about the recording date, I'd suggest you use %date% and %venue%. Otherwise, you should use %recording date% and %recording location%; both tag names describe their contents, and there is an indication they are correlated.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-09 19:52:21
Quote
Quote
As pointed out about 4 times now, it is obvious to you, but not obvious to a machine![a href="index.php?act=findpost&pid=332962"][{POST_SNAPBACK}][/a]

Even a sentient machine would have problems deducting the meaning of the %venue date% tag given its name; see also ssamadhi97's comment about this.


Sorry, but...... WTF?

What does the ambigious NAME of a tag have to do with the problems associated with mixed SEMANTICS? I would have asumed that a coder is able to differentiate between two issues which are so completely different, instead of mixing them together.

I guess i will leave this thread alone for a few weeks, so that the users learn how to focus on one issue after another, instead of discussing a dozen issues simultaneusly without making any progress.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-10-09 21:53:17
FWIW, throwing my support behind foosion and ssamadhi97; ALBUM DATE, RECORDING DATE, and PUBLISHING DATE are IMO the superior field names. I suspect that ALBUM DATE is redundant; I can't think of a situation where ALBUM DATE wouldn't be equivalent to RECORDING DATE. DATE can be any of these, probably defaulting to something like PUBLISHING DATE.
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-10-09 22:15:36
Quote
I can't think of a situation where ALBUM DATE wouldn't be equivalent to RECORDING DATE.
[a href="index.php?act=findpost&pid=333055"][{POST_SNAPBACK}][/a]

Well ALBUM DATE is supposed to be the album/cd release date, whereas RECORDING DATE is supposed to be the track's recording date, so they're almost never equivalent actually, at least for live albums (that's why VENUE DATE might be better than RECORDING DATE).
Note that ALBUM DATE is supposed to be used like ALBUM ARTIST, ie only when needed, so it's not so redundant.
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2005-10-09 22:23:21
Quote
Quote
I would stick with the following
DATE for album date (If album was released remastered, then the date of the original album release). That means that the date would be used to sort the discography hronologically.
VENUE for the place the track was performed at.
VENUE DATE for the date the track was recorded.

Edit: I would add something like `remastering date' for remastered albums. For compilation I would use something like `orig date' and `orig album'.
[a href="index.php?act=findpost&pid=332965"][{POST_SNAPBACK}][/a]

If you add ALBUM DATE to the equation, then you get the "orig date" for free: no matter if its a compilation or remastered album, you can just enter the published date of the CD to ALBUM DATE, and the "orig date" to DATE.

Quote
But not date as date of the original publication has nothing to do with track date.

Oh? Please explain - both are publishing dates.... either of the CD itself or of a track. DATE (in track-mode) *is* "the date when the track was originally published". Thats part of the proposal. How can it be something different when the proposal strictly defines that this tag is just for that?
[a href="index.php?act=findpost&pid=332992"][{POST_SNAPBACK}][/a]

I'd like to have remastered albums as a special case, because when lable release album remastered, it's mostly the same album that was released five or more years ago. And releasing remastered album doesn't effect the discography of an album artist. (in the case that the one exists).
Really the compilation which include tracks previosly released on other albums. Can be rereleased and remasterd. What would be the date?
With the original publication, the question is why you need this date. What would you do with it? For me it may be usefull to find this original publication. And I'll be happy if someone will provide some more information about this publication, the album it was released for instance (or even the original performer?). And It'll be better to group all this info together.
So I still vote for `orig' or `original' prefix. One more difference is that original track date is individual for every track on an album. But remastered date should be defined for the whole album/single/compilation.
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2005-10-09 22:28:11
Quote
Quote
Quote
As pointed out about 4 times now, it is obvious to you, but not obvious to a machine![a href="index.php?act=findpost&pid=332962"][{POST_SNAPBACK}][/a]

Even a sentient machine would have problems deducting the meaning of the %venue date% tag given its name; see also ssamadhi97's comment about this.


Sorry, but...... WTF?

What does the ambigious NAME of a tag have to do with the problems associated with mixed SEMANTICS? I would have asumed that a coder is able to differentiate between two issues which are so completely different, instead of mixing them together.

I guess i will leave this thread alone for a few weeks, so that the users learn how to focus on one issue after another, instead of discussing a dozen issues simultaneusly without making any progress.
[a href="index.php?act=findpost&pid=333030"][{POST_SNAPBACK}][/a]


Agreed on this.
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-10-09 23:28:15
Quote
Well ALBUM DATE is supposed to be the album/cd release date, whereas RECORDING DATE is supposed to be the track's recording date[a href="index.php?act=findpost&pid=333061"][{POST_SNAPBACK}][/a]


Therefore, it would make more sense for this ALBUM DATE field to be replaced by PUBLISHING DATE. It saves on some ambiguity.
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-10-09 23:51:02
Following the logic it should actually be replaced by ALBUM PUBLISHING DATE, a bit heavy on the stomach IMO =)

Basically, I see 2 totally different ways of doing this:
1. Standardize DATE and ALBUM DATE (being to *release* date what ARTIST and ALBUM ARTIST are to artist) and leave other dates alone for now (except maybe VENUE DATE)
Or
2. Standardize a bazillon of date tags (publishing, recording, original, remastered, to name a few) and let DATE and ALBUM DATE alone for their ambiguity (users being free to use them for the date(s) they seem the most relevant, or not use them at all)
Title: Tag-standards In Plugins<->formatting
Post by: Volcano on 2005-10-10 00:09:24
Quote
Maybe Get rid of %venue date% as a standard, it's obvious what the track specific date is for (be it %date% or %track date% : Original release date in compilations, Recording date in lives.
[a href="index.php?act=findpost&pid=332948"][{POST_SNAPBACK}][/a]

If I may add my 2 cents to this...

IMO there should be a very clear distinction between a release (i.e. a publishing) date and a recording date, throwing them together seems to contravene the general aim for a non-ambiguous structure. In the case of a compilation disc, this solution would make it impossible to store both the recording and the original release date of an individual track.

(I personally use RECORD DATE and ORIGINAL RELEASE DATE, both track-specific, for this.)
Title: Tag-standards In Plugins<->formatting
Post by: foosion on 2005-10-10 14:52:22
Quote
What does the ambigious NAME of a tag have to do with the problems associated with mixed SEMANTICS?[a href="index.php?act=findpost&pid=333030"][{POST_SNAPBACK}][/a]

Nothing really, I just used this one quoted sentence as a linchpin to express my opinion about the %venue date% tag. I'm afraid this unrelated backreference got you confused and distracted from the message I wanted to get across, so here it is again in unveiled form:

[span style='font-size:12pt;line-height:100%']I think the name of the %venue date% tag totally sucks.[/span]

The reason is simple: Unlike %recording date% it is not descriptive. It does not make sense as an English word (or phrase), it is just a concatenation of arbitrary words.

I would have assumed that someone who set out to create new superior tagging standard would come up with sensible tag names, but you probably know what they say about making assumptions...

Quote
I guess i will leave this thread alone for a few weeks, so that the users learn how to focus on one issue after another, instead of discussing a dozen issues simultaneusly without making any progress.[a href="index.php?act=findpost&pid=333030"][{POST_SNAPBACK}][/a]

I dislike the name %venue tag% (I hope that has become clear), so I feel the need to voice my concerns now, before people get used to it - even if only in discussion.
Title: Tag-standards In Plugins<->formatting
Post by: Birk on 2005-10-10 17:14:27
I (would) use:

DATE for the release date of the album
(because today 99% use it like this, so many formattings are like %artist% - %date% - %album% and nothing has to be changed for a normal album.
with ALBUM DATE it could be problematic)
FIRST RELEASED for the date of the first release of the track
(I know, it's not perfect, but FIRST PUBLICATION TRACK DATE is too long
and so it would be like FIRST_PLAYED or LAST_PLAYED)
RECORDING DATE for the date of the recording of the track
LOCATION for the recording location of the track
(it can be a studio, too, so I don't like VENUE)

I think that this would be easy to understand for everyone.
and of course all date formats should use the standart: YYYY-MM-DD

Another thing:
how to tag RATING?
many people use 1-5 (or 1-10), but I think that I'm not the only who want to have more difference (I tag the Rating everytime I listen a song and Rating is saving the average)
but I could use counters from
51-255 (I use this at the moment) or
1-100 (percent, like it more)
1.00-5.00 (more difficult to tag and sort)

Other Suggestions (don't know if they have to be standarilized)
MEDIATYPE (like CD,vinyl,download)
ALBUMTYPE (like Album,Single,Fan recording,Best-Of,Live-Album)
VERSION (like Single-Version,Blah-Mix,Live...)
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-10-10 17:24:19
Not bad...
So, location is better than venue for studios?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-10 17:52:24
Quote
I would have assumed that someone who set out to create new superior tagging standard would come up with sensible tag names, but you probably know what they say about making assumptions...

I would asume that someone who is writing software would not be a radical purist when it comes to standards.... and would not disrupt an existing scheme and userbase, just because he doesnt like the name of a tag. But you probably know what they say about making asumptions...

But you know, i think your proposal doesn't go far enough.

If we wanna be correct, then at least do the full job......

- I propose to obsolete every tag which does not have SET or TRACK as a prefix.
- ALBUM should be dropped and be replaced by SET TITLE
- ALBUM ARTIST should be replaced with SET ARTIST
- ARTIST should be replaced with TRACK ARTIST
- TITLE should be replaced with TRACK TITLE
- GENRE should be replaced with SET GENRE
- as a conclusion, we should introduce TRACK GENRE
- also as a consequence, the just standardized FIRST_PLAYED and LAST_PLAYED should be replaced with TRACK FIRSTPLAYED and TRACK LASTPLAYED (sorry kl333per, you'll need to adapt your plugin again)
- COMMENT should as well be made obsolete and replaced with SET COMMENT
- for complementary sake, we introduce TRACK COMMENT
- then we add SET PUBLISH DATE and obsolete DATE
- and of course TRACK RECORD DATE and SET RECORD DATE
- next we add TRACK ORIGINAL DATE and SET ORIGINAL DATE
- the REPLAYGAIN-tags will also need to be adapted to the new prefix-system (sorry peter, you'll need to change that)
- lots of more stuff to do

By prefixing everything with TRACK or SET, there will be no more ambiguity in terms of being albumspecific or trackspecific. We can also drop stupid IF-statements for such cases then, because they are not needed anymore. All plugin and formatting-string authors should port their designs to this system. I'm sure that other players and the rest of the world will appreciate such well thought-out, unambigious and correct scheme.

- Lyx

*watches the chaos unfold with some popcorn reachable*
Title: Tag-standards In Plugins<->formatting
Post by: picmixer on 2005-10-10 18:16:17
Quote
*watches the chaos unfold with some popcorn reachable*
[a href="index.php?act=findpost&pid=333318"][{POST_SNAPBACK}][/a]


*doubts anyone actually even cares*
Title: Tag-standards In Plugins<->formatting
Post by: Frank Bicking on 2005-10-10 18:51:21
Birk:

For the record: I neither like nor would use any of your proposed field names.
They are not descriptive and precise enough for my porposes.

Thanks for letting us know what you have come up with though, but it maybe fits better in another topic.


An attempt to summarize the current situation mixed with my own opinions:

This thread started as an initiative to decide on some standardized field names and formats, to increase the functionality of foobar2000 and the compatibility between title formatting scripts. It has lead to the addition of the already widely used ALBUM ARTIST and VENUE to the current field remappings. It has also made it possible to create some first components for the storage of playback statistics. During the last pages, people are doing something completely different.

It more and more appears as if they are attempting to create a complete tagging standard to cover all possible cases, just like ID3v2 developers tried to do and failed, and they are encouraged to do so if they are bored. But there is no direct relationship to foobar2000 anymore, aside from the fact that it's probably the only player that would support it. Those who participated in the discussion about DATE tags got lost in details. I think this discussion should be led somewhere else, it should be stopped here now.

Seeing the same field names being repeated over and over by the same people (hopefully) won't cause any gain in acceptance. Having said that, let me emphasize that there is no broad user base for those field names you keep repeating here. What's the point in standardizing more and more detailed information that is only stored by a minority of people? Public title formatting scripts should thus only include the basic array of field names (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Titleformat_Reference#Metadata) and nothing else.

People are now discussing topics that have no relation to the original idea and the topic title. They should stop acting as if they were some kind of representatives for the whole foobar2000 community, just because they happened to be those who started this thread or are in control of some wiki pages.


Looking at some other comments, please do also not forget that the current tagging formats are certainly too "flat" and limited to acquire all possible data and relationships, because there is only an array of "FIELD=Value" entries in each file. For more complex purposes of storing metadata, one would need a completely different file-independent approach, like XML documents or relational databases.


Proposal: Clean up the initial post and cut the discussion from it, and maybe move it to other areas of Hydrogenaudio.org.
Title: Tag-standards In Plugins<->formatting
Post by: foosion on 2005-10-10 19:09:54
Quote
I would asume that someone who is writing software would not be a radical purist when it comes to standards....[a href="index.php?act=findpost&pid=333318"][{POST_SNAPBACK}][/a]

Do you mean to imply that I am not entitled to have an opinion as a user because I also write software? The name %venue date% violates my feel for language as a user of the English language.

Quote
and would not disrupt an existing scheme and userbase, just because he doesnt like the name of a tag.[a href="index.php?act=findpost&pid=333318"][{POST_SNAPBACK}][/a]

Perhaps I missed something. Can you point out to me since when %venue tag% is an "existing scheme" and provide some numbers about its userbase?

Quote
But you know, i think your proposal doesn't go far enough.

If we wanna be correct, then at least do the full job......

<snip>[a href="index.php?act=findpost&pid=333318"][{POST_SNAPBACK}][/a]

Did I hurt your feelings or do something else that makes you want to demonstrate what real disruption looks like?

Quote
*watches the chaos unfold with some popcorn reachable*[a href="index.php?act=findpost&pid=333318"][{POST_SNAPBACK}][/a]

What chaos? Do you intend to create some?


I agree with Frank Bicking that the discussion in here is not really getting anywhere at the moment. I also want to make it clear that I see my posts in here as an expression of my opinion as a user, not as a representative of all foobar2000 users and not as a coder who will force whatever scheme he likes down people's throats. I'll retire from this thread for the time being.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-10-10 21:48:26
Quote
Quote
*watches the chaos unfold with some popcorn reachable*[a href="index.php?act=findpost&pid=333318"][{POST_SNAPBACK}][/a]

What chaos? Do you intend to create some?

Actually, IMHO some discussion-participants have created a chaos in the recent pages and are continuing to create more. But i'm not sure - maybe it would actually a good thing if the situation escalates, so that afterwards people see how stupid this chaotic discussion-style is and that it does lead to nowhere.

Whatever, i said i'd keep out for a while, so i should stick to that instead of getting provoked.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: ExUser on 2005-10-10 22:27:24
Here's the thing: All sensible foobar2000 plugins are configurable enough for this entire thread to be of zero importance any how. I'm personally convinced my own tagging system is optimal. However, it'd never go over completely here, so I'd personally never change to meet a new standard because I don't like it.

I suggest the best way we resolve this issue is to make a new thread describing all of our tagging set ups and disallow commenting about the set ups in that thread. Then, create a seperate thread for comments and discussion about the various set ups. That way we can try and figure out what a good general world view is. There seem to be spats like this every so often. Starting from a unified foundation would be helpful for figuring out problems like these in the future.

Of course, this would take work. Any takers?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-11-23 10:43:01
Regardless of the previous chaotic discussion, a while ago, the following draft was posted:

Quote
[span style='font-size:14pt;line-height:100%']Final call for comments on RATING / ALBUM RATING.[/span]


I propose the following tags to become recommended tag-standards:

RATING:
- used to rate individual tracks
- should contain an integer
- should not contain negative numbers
- should we propose or define a scale? (i.e. 0-5)

ALBUM RATING:
- to rate entire albums, EPs or split-singles
- every track of the set(i.e. the album) has to contain this tag with the same value
- should contain an integer
- should not contain negative numbers
- should we propose or define a scale? (i.e. 0-5)

[a href="index.php?act=findpost&pid=329443"][{POST_SNAPBACK}][/a]


There were no objections to it, except of someone asking why zero should be a valid value. Thus, i'd propose to set the above draft in stone, but with the valid scale being 1-5. People who enter zero as the value will most probably not run into any problems anyways.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: iStormy on 2005-11-23 20:29:57
[removed]
Title: Tag-standards In Plugins<->formatting
Post by: Silverbolt on 2005-11-23 23:09:05
It can be made clear that '4' is on a 1-5 scale if it were '4/5'. No objections either way, just a suggestion.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-11-24 01:51:12
0 should be treated by plugins the same as if there was no tag, i.e. the album is unrated.  Other than that, I have no problem with that standard.
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-11-24 02:34:13
Yes "an integer between 1 and 5" is what I'd use if I used ratings.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-11-25 13:17:17
major update of the first post
- intro completely rewritten
- added notes about discussion-style
- updated all codesnippets to foobar 0.9-style
- added RATING and ALBUM RATING as agreed upon standards



Quote
It can be made clear that '4' is on a 1-5 scale if it were '4/5'.

This would be dupe-info, because the standard would only allow 1-5 anyways. Formatting it that way is a piece of cake: $meta(rating)'/5'

Quote
0 should be treated by plugins the same as if there was no tag, i.e. the album is unrated.

More opinions on the zero-matter?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-11-25 16:42:08
If someone can come up with a reasonable use for the RATING=0, we should add it to the "standard", but currently I see it as a redundant value that shouldn't be included.
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-11-25 18:31:04
The only reason I'm seeing is "I don't want to rate this song so I'm rating it 0 because I absolutely want all my songs to have the %rating% tag", which is pretty pointless IMO. Plus it's not convenient because $if(%rating%,...) wouldn't be enough to test whether a track has been rated or not and we'd have to use $greater or $ifgreater instead.
Title: Tag-standards In Plugins<->formatting
Post by: Birk on 2005-11-25 18:53:44
Do you realy think that 5 different ratings for 5000 tracks are enough?
I want to have a rate between 4 and 5 if i rated a song one time 4 and another time 5...
I propose 10-50 or 20-100
But may be I'm the only person, so i think it's ok to standart 1-5 if I don't have to use it.
Title: Tag-standards In Plugins<->formatting
Post by: Silverbolt on 2005-11-25 19:19:09
Quote
Do you realy think that 5 different ratings for 5000 tracks are enough?
I want to have a rate between 4 and 5 if i rated a song one time 4 and another time 5...[a href="index.php?act=findpost&pid=345000"][{POST_SNAPBACK}][/a]

I've done the x.5 stuff myself. Trust me, it's not worth it (little gain, too much obsession). And I agree with Olive, including 0 would make some people select all their unrated tracks and set rating = 0 just because.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-11-25 19:25:05
Additionally, rating tracks is a difficult task in itself - because music can be so varied, it is often difficult to compare two tracks which each other... another thing is that rating-behaviour often is not constant... there are slight shifts over the course of time.... today, you may give a track a rating of 4,5, but in 2months, it may be 4,0, etc.... to make it short: accurate ratings are very difficult and usually not worth the time.... which in terms of reasonable effort only leaves us with "rough estimates". For a rough estimate,

1 = i hate it
2 = i dislike it
3 = it's okay
4 = i like it
5 = i love it

... is completely sufficient. Its also sufficient for practical purposes(like i.e. only playing tracks which you love).

And last but not least, RATING with the 1-5 scale is already in widespread use - the alternative would be starting from scratch in terms of userbase.

- Lyx

edit: concerning your question - you dont HAVE to use any of the tag-standards outlined here. However, publically available displays and plugins will probably first support the schemes outlined here, and then later *maybe* add support for other schemes.
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-11-25 20:11:24
Also if you wanted a more precise reflection of your current preferences you could well use hotness (http://www.hydrogenaudio.org/forums/index.php?showtopic=31287) in addition to rating and playcounter's tags.
Title: Tag-standards In Plugins<->formatting
Post by: anza on 2005-11-25 20:23:12
Also, very closely related to RATING would be the MOOD tag (and/or STYLE(S) and similar), perhaps it (they) should be the next to "standardise", after we get the RATING sorted out.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-11-26 12:02:11
Well, it seems that the only uncertainity left is what to do with zero. No one was able to bring up any useful purpose for it to be supported one way or another. The only 2 things i could think of are:

- use it as a *additional* value on the rating-scale - so, counting from zero instead of 1, so that the scale would be 0(worst) - 5(best). I dont think that a six-step rating system is intuitive for most people.

- use it to indicate *something different* than how much one likes a track. Like for example use it to indicate tracks which should be skipped. One single person in the thread mentioned using it in a similiar way. However, as indicated in the initial post, this is bad style, because of mixed semantic. To simply indicate that a track should be skipped, another tag should be used. And to indicate a track which is so bad that it should be skipped, well, thats what 1("i hate it") is there for.

Anyone think that i missed something? Else it seems that RATING and ALBUM RATING can be considered "done".

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Insolent on 2005-11-26 14:56:05
Quote
ze·ro
   8. Nothing; nil

Wouldn't it be a safe bet to just set zero as an alternative to null rating? After all, zero is used in nearly everything to represent nothing. If we have 0 apples, we have no apples. If we have 0 rating, the same logic should apply and we have no rating.

0 = not rated
1-5 = rated
Title: Tag-standards In Plugins<->formatting
Post by: Jasper on 2005-11-26 15:05:28
Quote
Wouldn't it be a safe bet to just set zero as an alternative to null rating? After all, zero is used in nearly everything to represent nothing. If we have 0 apples, we have no apples. If we have 0 rating, the same logic should apply and we have no rating.[a href="index.php?act=findpost&pid=345226"][{POST_SNAPBACK}][/a]
Saying "rating=0 is equivalent to no rating" would be similar to saying that having a particular kind of apple is equivalent to having no apple.
Title: Tag-standards In Plugins<->formatting
Post by: Insolent on 2005-11-26 15:25:53
Quote
Quote
Wouldn't it be a safe bet to just set zero as an alternative to null rating? After all, zero is used in nearly everything to represent nothing. If we have 0 apples, we have no apples. If we have 0 rating, the same logic should apply and we have no rating.[a href="index.php?act=findpost&pid=345226"][{POST_SNAPBACK}][/a]
Saying "rating=0 is equivalent to no rating" would be similar to saying that having a particular kind of apple is equivalent to having no apple.
[a href="index.php?act=findpost&pid=345230"][{POST_SNAPBACK}][/a]

Eh? Please elaborate.

I have another solution:

If zero is such a problem number, why don't we just dodge the situation and not include it in the 'specification'? What's so special about it that is has to be included? If the rating scale is 1-5, then 1 is the lowest number. We can't say that 0 has a lower rating than 1, when 1 is the lowest rating you can give something. Thus, zero has no place in the rating system and is not needed at all. If zero has to be included, why not 6? Or 7?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-11-26 15:50:43
I think the deciding two questions regarding zero are:

"Can anyone give any example of practical usefulness(no matter if in fb2k or elsewhere) of having 0 be equal to "unrated"?"

(if you manage to find a purpose) "What would speak against making 0 = "unrated"?"
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-11-26 18:24:16
0 as unrated looks like a bad idea. It's strongly misleading as it suggests the worst rating on a 0-5 scale. No %rating% tag is much better and conforms to other standards, like no %album artist% for 1-artist albums etc.

Edit: I thought that perhaps some people could be tempted to use 0 as a "neutral rating". Then again it's probably better to use the median rating (ie 3).
Title: Tag-standards In Plugins<->formatting
Post by: iStormy on 2005-11-26 19:07:16
[removed]
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2005-11-27 00:32:10
People are misintepreting my words, I should have been more clear.  0 does not equal unrated, but should be treated by plugins as unrated.  It should not be part of the standard and should be actively discouraged.  However, there are going to people with rating=0 in their tracks, and those tracks should be treated as unrated.  The correct way to unrate a track is remove the rating tag.
Title: Tag-standards In Plugins<->formatting
Post by: hunted on 2005-11-27 01:20:19
Quote
People are misintepreting my words, I should have been more clear.  0 does not equal unrated, but should be treated by plugins as unrated.  It should not be part of the standard and should be actively discouraged.  However, there are going to people with rating=0 in their tracks, and those tracks should be treated as unrated.  The correct way to unrate a track is remove the rating tag.
[a href="index.php?act=findpost&pid=345407"][{POST_SNAPBACK}][/a]

I agree, especially if you have something like $sub(%rating%,1), then on a track with a rating of 1 it will go to 0, which should be treated as having no rating, ie unrated, but it should not be encouraged to use 0 as rating.
Title: Tag-standards In Plugins<->formatting
Post by: Olive on 2005-11-27 03:13:00
Quote
However, there are going to people with rating=0 in their tracks, and those tracks should be treated as unrated.
[a href="index.php?act=findpost&pid=345407"][{POST_SNAPBACK}][/a]

People with rating=0 as unrated, other people with 0-n rating scale... Adding conventional exceptions for non standard ratings might defeat the whole point of standardizing rating, or it's just me being drunk again
I'd see two ways for plugins to deal with non standard ratings:
1. Any rating outside [1;5] is undefined, thus the given track is treated as unrated.
2. The developer bothers to add a setting where users specify their rating scale (default is 1-5), then if needed ratings are scaled and rounded to more or less fit the 1-5 range. the only value that's got to be treated as unrated is the median (or the developer adds another setting to specify an "unrated" value like 0 or -1, but that may become rather fishy).
Hope not to add chaos here

Edit: Note that WMP10 automatically assigns rating=3/5 to unrated items.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-11-27 09:34:09
added the following two points to the RATING/ALBUM RATING tag-standard
- the absence of a RATING/ALBUM RATING tag means "unrated"
- 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 tag which doesn't comform to the specs outlined above may be considered "unsupported/invalid".

Zero will for now not be part of the specs.


Quote
Also, very closely related to RATING would be the MOOD tag (and/or STYLE(S) and similar), perhaps it (they) should be the next to "standardise", after we get the RATING sorted out.
[a href="index.php?act=findpost&pid=345030"][{POST_SNAPBACK}][/a]

How about doing STYLE(S) first? It's something which has a bigger potential userbase and seems much easier/straight-forward to do, since there are only 2,5 approaches to do it(multi-GENRE or STYLE(S) tag) - but maybe someone comes up with another way to do it *shrugs*

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-11-28 21:06:38
Appears that now one's got a problem with that.


A while ago, i created a poll (http://www.hydrogenaudio.org/forums/index.php?showtopic=32887&hl=style+styles) asking about just this topic, to get an idea about current userbases.

The reasonable choices appear to be the following ones:

STYLE:
Follows standard naming convention (i.e. ARTIST instead of ARTISTS).

Multiple STYLE fields:
Unusual but in terms of DB-friendlyness is more proper.

STYLES:
This scheme is used by TheGodFather and AMG.

Multiple STYLES fields:
The "proper" variant.

Multiple GENRE fields:
The ultra-proper way. No need to create a new fieldname if there is already an existing one which serves just this purpose. Additionally, hierachical style-categorization("main-style" in GENRE, "sub-style" in STYLE(S)) is stupid IMHO. Nowadays, everything is mixed with everything and new music variants are created daily. Hierachical classification of music is doomed to fail from the beginning on, because music is just too varied to fit into such strict patterns. The solution IMHO is to use genres like adjectives - as descriptors just as you'd describe something with "warm, soft". Thus, multiple GENRE-fields would do just that. One doesn't need to think about "primary" and "secondary" classifications, but can instead just enter all genres which are closely related to the music. Additionally, it's very DB-friendly and for example allows to start a query to find everything "Rock"-related in one's collection. The advantage of DB-friendlyness becomes even more obvious when thinking about how multi-GENRE could complement a mood-system.

BUT, there are a few showstoppers regarding multi-GENRE - we're talking about a standard ID3v1 field here - we don't want to break anything in such a case.

Stuff which needs investigation:
- When adding multiple genre-fields to an MP3, then what does foobar write to the ID3v1 tag?
- What do other ID3v2/Vorbis-Tag/APEv2-capable tag-editors and players see and display?
- What do DAPs display?
Title: Tag-standards In Plugins<->formatting
Post by: Insolent on 2005-11-29 02:42:17
Quote
BUT, there are a few showstoppers regarding multi-GENRE - we're talking about a standard ID3v1 field here - we don't want to break anything in such a case.

Stuff which needs investigation:
- When adding multiple genre-fields to an MP3, then what does foobar write to the ID3v1 tag?
[a href=\"index.php?act=findpost&pid=346074\"][{POST_SNAPBACK}][/a]
ID3v1 only has 79 genres. The ID3v1 genre frame is actually a number corresponding to a certain genre:

Code: [Select]
 0.Blues
 1.Classic Rock
 2.Country
 3.Dance
 4.Disco
 5.Funk
 6.Grunge
 7.Hip-Hop
 8.Jazz
 9.Metal
10.New Age
11.Oldies
12.Other
13.Pop
14.R&B
15.Rap
16.Reggae
17.Rock
18.Techno
19.Industrial
20.Alternative
21.Ska
22.Death Metal
23.Pranks
24.Soundtrack
25.Euro-Techno
26.Ambient
27.Trip-Hop
28.Vocal
29.Jazz+Funk
30.Fusion
31.Trance
32.Classical
33.Instrumental
34.Acid
35.House
36.Game
37.Sound Clip
38.Gospel
39.Noise
40.AlternRock
41.Bass
42.Soul
43.Punk
44.Space
45.Meditative
46.Instrumental Pop
47.Instrumental Rock
48.Ethnic
49.Gothic
50.Darkwave
51.Techno-Industrial
52.Electronic
53.Pop-Folk
54.Eurodance
55.Dream
56.Southern Rock
57.Comedy
58.Cult
59.Gangsta
60.Top 40
61.Christian Rap
62.Pop/Funk
63.Jungle
64.Native American
65.Cabaret
66.New Wave
67.Psychadelic
68.Rave
69.Showtunes
70.Trailer
71.Lo-Fi
72.Tribal
73.Acid Punk
74.Acid Jazz
75.Polka
76.Retro
77.Musical
78.Rock & Roll
79.Hard Rock
So, if the genre is not in that list, fb2k won't write an ID3v1 GENRE tag at all. I have a few "Melodic Death Metal" albums. If I open one of them up in mp3tag an display only the ID3v1 tags, there's no GENRE tag at all. So, already I've broken ID3v1 GENRE compatibility. And so have many other people. In fact, whoever invented ID3 broke ID3v1 GENRE compatibility when they introduced the ability to write whatever you want into the GENRE field with ID3v2.
Title: Tag-standards In Plugins<->formatting
Post by: dream4distance on 2005-12-03 18:22:34
To add my input on the Styles implementation, I'd very much like to see the Styles(n) as used by TGF and Allmusic become more of a standard.  If you're bent on having multiple GENRE tags though, perhaps make the general rule that the first one set needs to be ID3v1-compatible (as per the list above) or else the ID3v1 tag is written as 12 (Other).

As an aside, I use the rating of 0 to represent "pending" as in "pending review."  I like to keep track of songs/albums I'm currently putting through their paces to decide how much I like which songs.  The process for me usually takes from a few days to a few weeks to really process a list and the lists tend to grow as I get new music to evaluate.  I unfortunately also get sidetracked or the process gets interrupted and the music I had been evaluating gets lost in the shuffle until I stumble upon it months later and haven't a clue which were the songs I liked anymore.  Being able to quicktag (or the like) a bunch of song ratings as Pending (0), makes it easy for me to keep dynamic lists of the songs I'm currently evaluating.

d4d
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-12-09 06:33:01
Quote
So, if the genre is not in that list, fb2k won't write an ID3v1 GENRE tag at all. I have a few "Melodic Death Metal" albums. If I open one of them up in mp3tag an display only the ID3v1 tags, there's no GENRE tag at all.

Quote
perhaps make the general rule that the first one set needs to be ID3v1-compatible (as per the list above) or else the ID3v1 tag is written as 12 (Other)

Can someone confirm one of the following:
1. if ANY field of a multi-genre tag contains an id3v1-compatible value, then foobar sets the id3v1-tag to this value. Else "other" is used.
2. only if the FIRST field of a multi-genre tag contains an id3v1-compatible value, then foobar sets the id3v1-tag to this value. Else "other" is used.


Also, does someone know how other taggers and players interprete multi-genre id3v2 tags?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-12-09 06:47:31
Quote
As an aside, I use the rating of 0 to represent "pending" as in "pending review."  I like to keep track of songs/albums I'm currently putting through their paces to decide how much I like which songs.  The process for me usually takes from a few days to a few weeks to really process a list and the lists tend to grow as I get new music to evaluate.  I unfortunately also get sidetracked or the process gets interrupted and the music I had been evaluating gets lost in the shuffle until I stumble upon it months later and haven't a clue which were the songs I liked anymore.   Being able to quicktag (or the like) a bunch of song ratings as Pending (0), makes it easy for me to keep dynamic lists of the songs I'm currently evaluating.[a href="index.php?act=findpost&pid=347388"][{POST_SNAPBACK}][/a]

[span style='font-size:9pt;line-height:100%']You can, for your personal use, of course use zero for that purpose. However, with fb2k 0.9, it will become quite easy to for example setup script-presets(similiar to foo_quicktag) like this:

remove rating = remove RATING EVALUATE and RATING
evaluating = remove RATING and set RATING EVALUATE to "1"
trackrating 1 = remove RATING EVALUATE and set RATING to "1"
trackrating 2 = remove RATING EVALUATE and set RATING to "2"
trackrating 3 = remove RATING EVALUATE and set RATING to "3"
trackrating 4 = remove RATING EVALUATE and set RATING to "4"
trackrating 5 = remove RATING EVALUATE and set RATING to "5"
[/span]
- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: ectotropic on 2005-12-09 13:46:04
‘lo all – been a long time since I been round these parts and I’ve only just seen this thread, so apologies if I’m off-topic or repeating previous posts. (As suggested I did read the last 15 or so posts – but almost 400 is just too many too read fully!)

Anyway – my thoughts on tags:

I’d like to see a hierarchical genre – styles set up (a single genre tag with multiple style fields). Apart from anything else this would match the discogs website set up, which I feel works well, plus would allow for tools like mp3tag to automatically fill in the details – which would save me a bit of work!

The genre tag, then, should probably be id3v1 compatible and the styles tag(s) allowing for any additional sub-divisions as required. For those opposed to hierarchical setups the genre tag could be set to “other” for all music and the styles tags could be used instead. The allowed values for the styles field should be anything people want (with a small caveat below) – to attempt to restrict it would be a huge mistake.

Personally I’d prefer multiple styles tags since it’d make it easier to parse, sort and use, however I can see that setup leading to some headaches. If a single styles tag was to be used, having a standard style separator would be a must (obviously the separator would be illegal as part of a style name which means it has to be selected carefully, I think ‘,’ works well, but don’t know if anyone uses it for style names, certainly ‘ ‘ and ‘-‘ should be avoided).

Also I’d like to add the following set of tags to the standard:

Album/Set wide:
DISC – Number of the disc in the album set
DISC NAME – Name of the disc in the album set (if any)

Track Specific:
MIX – mix/remix of the track (no entry assumes it’s the original version or unknown mix)
MIX ARTIST – um…the artist of the mix
FEATURING – Additional artist(s) featured on the track – for example a guest vocalist. (Could be multiple fields).
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-12-09 14:53:36
Ahem, could we maybe investigate one approach after another - and then afterwards - when we've got an overview of their various up- and downsides - discuss which one makes most sense?

Quote
Stuff which needs investigation:
- When adding multiple genre-fields to an MP3, then what does foobar write to the ID3v1 tag?
- What do other ID3v2/Vorbis-Tag/APEv2-capable tag-editors and players see and display then?
- What do DAPs display then?
[a href="index.php?act=findpost&pid=346074"][{POST_SNAPBACK}][/a]


As it is now, after about 11 days, not a single person was able to spent 15mins of investigation to give a clear unambigious answer to any of the above issues. If those were cleared up, we could go on to evaluate the other approaches.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: dream4distance on 2005-12-23 01:24:33
Sorry to be so long in getting back, haven't had a spare moment with the holiday rush and such lately.  Anyway, I started a bit of investigation and here's what I've come up with thus far (all done with fb2k 0.8.3 writing ID3v1 + ID3v2 to mp3 files):

Quote
- When adding multiple genre-fields to an MP3, then what does foobar write to the ID3v1 tag?


If the first genre field written is a valid one from the ID3v1 spec list, it will use that first genre tag properly for writing the ID3v1 tag.  However, if the first genre field used is not a valid one from the list we'll end up with an empty genre field for ID3v1 tag.  Additional genre fields don't matter as far as the ID3v1 tag is concerned... even subsequent ones are valid for that tag, they're still ignored in writing the tag.  Bottom line is that the first GENRE field written needs to be ID3v1 compliant or it won't write a genre to the ID3v1 tag.

Quote
- What do other ID3v2/Vorbis-Tag/APEv2-capable tag-editors and players see and display then?


Out of the ones I've tested thus far, for taggers only MP3Tag and for players Apollo and Windows Media Player (10) display all the genre fields written.

The Godfather, Tag&Rename, and TagScanner display only the last genre entered in the id3v2 genre field while MP3/Tag Studio and Tag Clinic display only the firstof the multiple genre fields.  Players:  QCD and Winamp only display the first while XMPlay displays only the last.

Quote
- What do DAPs display then?


Haven't gotten to really test this yet, but I'm guessing it will be a similar mixed bag as in above.  If we still want to test this out, after xmas I'll have access to a few generations of Rio players, an iAudio U2, an ipod mini, and an ipod video.

In general, the problem we're running into with this approach is that we're writing multiple TCON (Content Type, better known as Genre) frames into the ID3V2 tag which most other software and more modern DAPs read by default.  Now the problem with this is that according to the ID3V2 informal standards (which most taggers/players/daps follow to various levels of strictness for their ID3V2 tag reading/writing) only one TCON frame should be written per tag and all others should be ignored.

I started testing out other programs with ID3v1 + APEv2 tags written instead of ID3V2 and it was still a mixed bag with programs that read APE tags and generally less programs supporting APE tags right out of the box at all.

If we want to stick with the Genre approach, perhaps try writing multiple Genres to one genre field?  The proper usage of the ID3V2 TCON frame itself (and most other text fields in ID3V2) is done this way.  From the spec:

Quote
All text information frames supports multiple strings, stored as a null separated list, where null is reperesented by the termination code for the charater encoding.


I have no idea how well it would play with other things that read APEv2 tags let alone if the current tag writing in fb2k can properly write multiple genres to a genre field for either ID3V2 or APEv2.

Those are my findings and suggestion for now.  I'll play around some more and likely get back to the thread here once the family extravaganza for Christmas has ended next week.  Happy Holidays to all those celebrating anything!

d4d
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-12-23 01:51:35
@dream4distance:

Thank you very much for the detailed and useful analysis - even though the results are catastrophic.

Here's more ID3v2 multi-field insanity - from a chat i had with kode:
Quote
kode54: oh, and the user text TXXX frame that I used for custom fields at user suggestion?
kode54: with description == tag name
kode54: standard says that there can be only one TXXX frame with a given description
kode54: TXXX also does not support multiple strings per frame
kode54: so there you go, standard automatically rules out multiple values per field name, except for select standard frames I think
kode54: actually, no
kode54: I should read that whole doc some time
kode54: 70KB of bullshit
Lyx: sounds like that
kode54: I already break the above in 0.8.3 tagger
Title: Tag-standards In Plugins<->formatting
Post by: Killmaster on 2005-12-24 01:47:12
Might I propose an ALBUMTYPE tag? I use this in my collection, and it works pretty well. Basically what this tag does is specify what kind of album it is. Since they are generally the most listened to, LPs are left untagged. Everything else has one of the following:
EP/CDS - I had singles and EPs seperated out, but realistically it's easier just to group them together. Note that allmusic does this as well.
Live - Any officially released live recording.
Bootleg - Any unofficially released recording
Compilation - Any offical best of collections, or simply a compilation of odds and ends that the band has released.
Remix - I use this with remix albums, for example "Bloc Party - Silent Alarm Remixed." I suppose that technically is just a V/A album, but I prefer in this case to group it with the original artist.[/li][/list]
These tags come in particularly handy when using the albumlist. Simply put in an extra branch with an $if2(%albumtype%) plus the necessary conditionals and you should be good to go. Here's my config for v0.8.3:

Code: [Select]
$puts(The,$if3(%album artist%,%artist%,Unknown Artist))

$if($stricmp($left($get(The),4),'the '),$substr($get(The),5,$len($get(The)))', The',$get(The))
|
$if2(-%albumtype%-,['('%date%')' ][%album%])
|
$if(%albumtype%,['('%date%')' ][%album%],[$num(%disc%,2).][$num(%tracknumber%,2). ]$if(%album artist%,%artist% - )$if2(%title%,%_filename%))
|
$if(%albumtype%,[$num(%disc%,2).][$num(%tracknumber%,2). ]$if2(%title%,%_filename%))
Title: Tag-standards In Plugins<->formatting
Post by: Erich w/ an h on 2005-12-25 07:12:37
Ive tried to read through this thread, but I may have missed a point or two that addresses my questions. If so, feel free to point me to the answer and accept my apology

1. DATE / ALBUMDATE tags. I usualy add the full release date to the date tage, as in yyyy-mm-dd. Is this a standard practice, or do people add MONTH / DAY tags to represent those aspects? I like the full date, so that albums released on the same year arent sorted alphabeticaly.

2. LOCATION tag. Is that replaced by VENUE? For location, I usualy do something like "Jones Beach Theater: Wantaugh, NY"

3. DISCNAME a standard practice? What about things such as DISCTOTAL and TRACKTOTAL, or variations of the sort?

4. VERSION. I like having a VERSION tag as a be all for different versions of a song, such as live, remix, demo, etc. Is this widely used?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-12-25 15:00:09
Okay, so multi-genre doesn't look that good for now on the compatibility-side...

The same - according to kode - may be the case for multi-STYLE and multi-STYLES.


So, just the single-field approach left to analyze before discussing what to do:


Which applications use STYLES?
Currently, i only know about TheGodfather

Which applications use STYLE?
I dont know of any.
Title: Tag-standards In Plugins<->formatting
Post by: dream4distance on 2005-12-28 19:34:07
Quote
Okay, so multi-genre doesn't look that good for now on the compatibility-side...

The same - according to kode - may be the case for multi-STYLE and multi-STYLES.


So, just the single-field approach left to analyze before discussing what to do:


Which applications use STYLES?
Currently, i only know about TheGodfather

Which applications use STYLE?
I dont know of any.
[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=352287")


Hrm, don't know too many other style/styles implementations myself offhand.  MOOD seems to be much more common and now that I think about it how individuals actually define this stuff is going to be fairly arbitrary (which is why I never bother much with genre) so perhaps Mood would be more of a suitable tag anyway.  Multiple moods in one mood tag would have to be the case I think.  Ideally, even if it isn't well supported perhaps we could look at having both Mood and Styles (possibly even Tempo or something similar as well, but that could be put in styles) so we could easily find things we've defined as all the "fast" "bitter" "christian" "japanese" "ganster rap" if we really wanted to, hehe.  Anyway, enough rumination for now, here's an interesting blog entry from our own TopDownJimmy that's somewhat relevant to the matters at hand:

[a href="http://topdownjimmy.beigetower.org/kbps/2005/05/01/a-flat-hierarchy-for-subjective-mp3-tags/]http://topdownjimmy.beigetower.org/kbps/20...ctive-mp3-tags/[/url]

d4d
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2005-12-29 02:29:55
I dont think that it is a question of STYLE *or* MOOD, but that instead both complement each other.

There should be a way to give music multiple GENREs. Optimally - reasons explained in one of the links of topdownjimmiy's blog entry - in a flat hierachy. As we've seen, we cannot do that with GENRE because ID3v2 + ID3v1 basically crippled this tag. So, we would want to keep GENRE for compatibility, and then instead do multi-genre with STYLE. This approach actually allows for both: a flat hierache and a non-flat one. People could either dupe the GENRE-genre to STYLE and add the other genres to STYLE... and that way have a flat hierachy by ignoring genre i.e. during database-searches. Or they could also have a two-tiered hierachy.

As for why both are complementary imho: STYLE should just be multiple-genres with the exception that its less strict (so that you could i.e. add the three "labels" "ambient, space, industrial".

Mood on the other hand imho should only focus on the "characteristics" of a tracks - how it "feels like".

*If* i am right with this POV, then it makes sense to first only focus on STYLE and then later tackle MOOD as a seperate issue.
Title: Tag-standards In Plugins<->formatting
Post by: dream4distance on 2005-12-29 04:22:32
Quote
I dont think that it is a question of STYLE *or* MOOD, but that instead both complement each other.


Totally agreed.

Quote
*If* i am right with this POV, then it makes sense to first only focus on STYLE and then later tackle MOOD as a seperate issue.


Yes, you're reasoning for this is very strong and I believe you are correct.  I brought up Mood simply because it is more of a commonly used tag in editors/players that's fairly arbitrary to the individual much like I feel Genre + Style(s) will be, but they are meant to complement each other as you said, not replace.

I'll hopefully have some free time tomorrow to look deeper into the STYLE(S) issue and post some relevant feedback.  I'm taking a look at your related poll as well and have some logistical feedback already.  Update to come tomorrow.

d4d
Title: Tag-standards In Plugins<->formatting
Post by: Erich w/ an h on 2005-12-31 21:53:30
Quote
4. VERSION. I like having a VERSION tag as a be all for different versions of a song, such as live, remix, demo, etc. Is this widely used?
[a href="index.php?act=findpost&pid=352268"][{POST_SNAPBACK}][/a]


I was just thinking. What about Album Version and Track Version? That way Album can stay the same, but you can add "special edition", "2005 remaster", etc. hm?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-01 09:03:06
update regarding id3v2 multi-value fields:
- talked with kode yesterday

- multi-value id3v2 fields (or multiple fields with same name) are invalid according to the standard. Foobar breaks standard in this aspect to get multivalue id3v2-fields. Result is that only first field is readable in other players - all additional fields are unusable in other applications. Thus, multi-value fields in id3v2 are currently *foobar-only* fields.

- i proposed to store multiple fields with same name as one field instead, and then use seperator char to split it into multiple fields. According to kode, the problem is that basically every char is a valid char in id3v2 - thus, if said seperator-char would be needed as real char, then you need to introduce escape-sequence mess in tagfields.

- kode is no longer responsible for the id3v2 plugin - peter/DEATH will take it over. Thus, i'll talk with peter in the next days about it.


For people who didn't follow this thread closely, all this may seem rather remotely and insignificant. However, it's impact is quite high, because currently we only have three choices:

A) tell people to tag differently in id3v2 than in other tag-systems
B) tell people to tag files in a way which will make them incompatible with other applications and players
C) tell people to not use multi-value fields at all and instead cram everything into one field

A and B are not acceptable, so currently we only have choice C. This does not just affect multi-STYLE - it affects EVERY case of when multi-value fields would make sense - multi-ARTIST, multi-COMPOSER, multi-MOOD, multi-WHATEVER. Simply said, multi-value fields are currently unusable for tag-standards. Thats why a decision needs to happen now, not afterwards.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Insolent on 2006-01-01 15:00:06
Quote
update regarding id3v2 multi-value fields:
- i proposed to store multiple fields with same name as one field instead, and then use seperator char to split it into multiple fields. According to kode, the problem is that basically every char is a valid char in id3v2 - thus, if said seperator-char would be needed as real char, then you need to introduce escape-sequence mess in tagfields.
[a href="index.php?act=findpost&pid=353709"][{POST_SNAPBACK}][/a]

Can't we just use some kind of null character to seperate values? Such as the one used on either side of colour strings ($char(3) I believe).
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-01 15:08:08
Quote
Can't we just use some kind of null character to seperate values? Such as the one used on either side of colour strings ($char(3) I believe).
[a href="index.php?act=findpost&pid=353736"][{POST_SNAPBACK}][/a]

Maybe. However, remember the reason for the current mess: multi-value fields are foobar-only. Thus, the intention is to have multi-value id3v2 fields which are also usable in other applications. Thus, in an optimal case it would be a character which makes the tagfield-contents also look nice when the raw-contents are shown in other applications. Yet one more step better would be a char which is also easy to type, so that it is possible to create multi-value fields in other applications which don't support this approach.

The problem which then arises is of course that a character which looks nice as seperator AND is easy to type with the keyboard, has a high probability of being also used for other purposes. A char which may be a good candidate is the pipe-char "|". It is easy to type, looks okay as seperator, and i have never seen it used in tagcontents ever.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2006-01-02 05:02:02
I have several albums that use the "|" char.  Eg. A-Ha - Minor Earth | Major Sky.  Granted, you would probably never have multiple ALBUM fields.
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2006-01-02 05:15:51
How about this as an option.  For formats that support multiple fields, use that, and for ID3v2 and any others that don't, join the multiple fields together automagically.  I'll give an example of a file with APEv2 and ID3v2 tags.

APEv2:
ARTIST = Don Henley
ARTIST = Steve Porcaro
TITLE = The Boys Of Summer

ID3v2:
ARTIST = Don Henley & Steve Porcaro
TITLE = The Boys Of Summer


APEv2:
ARTIST = Don Henley
ARTIST = Lindsey Buckingham
ARTIST = Pino Palladino
TITLE = You Can't Make Love

ID3v2
ARTIST = Don Henley, Lindsey Buckingham & Pino Palladino
TITLE = You Can't Make Love

Pros:
- For ID3v2, allows multiple values to be displayed in all applications by using one tag
- Provides flexability of multiple fields for those tagging standards that support it

Cons:
- Loss of functionaility over current broken ID3v2 implementation
- Potential cause for confusion when a user inputs multiple fields and they are re-written to a single field when using ID3v2

This is the most usable solution I can come up with.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 08:11:21
Quote
- For ID3v2, allows multiple values to be displayed in all applications by using one tag

No it doesn't. Either you use ' & ' as a seperator-char which is certain to cause havoc, or you dont allow splitting of the combined fields anymore. What is the advantage of your idea, over the current mess to just cram everything into one field and not use seperate multi-value fields?
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2006-01-02 17:06:33
I didn't mean it actually allowed multiple values.  As you have stated, what you want to achieve is impossible because the ID3v2 standard does not allow for multiple fields.  Using some kind of seperator char will only cause problems in other apps.  My proposal allows ID3v2 to be work in all it's backwards glory and real tagging standards to use multiple fields.  By writing ID3v2 in a nice way, you allow interoperability with other apps.

My suggestion is to foobar developers more so than the community.  I'm suggesting that the ID3v2 tag writer convert multiple fields into one and and add nice formatting so that multi-value fields don't look stupid in other apps.  If you want true multi field goodness, use APEv2, but I see no other reasonable solution to the problem (except keep breaking the ID3v2 standard and to hell with other apps).

The main advantage to my suggestion is that the user does not have to worry about whether a particular tagging standard supports multiple fields or not, foobar just takes care of it.  The information won't be as usable when stored in ID3v2, but at least it won't be a problem for other apps to display it nicely.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 17:54:42
Quote
Using some kind of seperator char will only cause problems in other apps.

Hmm, could you elaborate which kind of problems would be caused in other apps? I can imagine problems on foobar's side, but not on other app's side - but i'm interested in what kind of problems those would be.

By the way: current implementation already does cause most severe possible problem: it plain simply is fully incompatible.

Quote
My proposal allows ID3v2 to be work in all it's backwards glory and real tagging standards to use multiple fields.

I dont consider "write-only" data to be a "working solution".

Quote
By writing ID3v2 in a nice way, you allow interoperability with other apps.

We can do that already - just cram everything into one field with no cues/seperators.  Your "solution" does the same - it just lies to the user while he types in data.

Quote
The main advantage to my suggestion is that the user does not have to worry about whether a particular tagging standard supports multiple fields or not, foobar just takes care of it.

The illusion only works as long as the user does input data the first time - it stops working as soon as he wants to use or re-edit the affected metadata. This is the main problem which i have with your idea - it doesn't add any functionality - it just adds a short-lived illusion. You propose to tell the user that he got multiple fields with same name - which is a lie - and then hope that he will never actually take your word for it.

If tag-writing is obscured, then the illusion also needs to work during reading/processing and manipulating said data. Else, in my humble opinion an ugly truth is better than a bad lie.

Your idea IMHO would be a good one if:
1. there is no chance/reasonable way to get multi-value id3v2 fields.... and
2. ... you clearly tell the user during tag-editing that on id3v2 multifields will be merged.

- Lyx

edit: there is one more problem.... plugins which write multi-value metadata on their own. Writing is no problem - but what happens when they READ or EDIT those again and expect to get multi-value metadata?
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 18:29:40
Quote
A) tell people to tag differently in id3v2 than in other tag-systems
B) tell people to tag files in a way which will make them incompatible with other applications and players
C) tell people to not use multi-value fields at all and instead cram everything into one field


As I understand there is variant D, i.e. to state that id3v2 plugin is no longer supported and deprecated. So no id3v2 support currently.

About the implementation of the new plugin, I can suggest to use backslash to quote sepparater and backslash itself. Seems like crap, but it is the most common practice... After all, foobar users would'nt see anything, any way...

Example:
id3v2
ARTIST=Artist 1|Artist 2 \| 3||Artist 4\\5

ape2
ARTIST=Artist 1
ARTIST=Artist 2 | 3
ARTIST=
ARTIST=Artist 4\5
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 18:45:24
@vir:

about dropping id3v2... i do know that there are a few people - even among the "core staff" - who think that id2v2 support should be totally abandonned and compatibility not taken into account. If this is what should be done, then i'm the wrong man for coordinating this thread - My interest is in changing something in the real world - not creating some geeky phantom consensus which only exists inside of a small utopian elite. This isn't meant as a threat - i'm just saying that in this case, someone else should take over.

Regarding backslashes as seperator...... i thought about using a backslash as well. The problem however is READING. You cannot expect that all files which are loaded into fb2k, were also tagged via fb2k. When a user loads a bunch of files which were created and tagged with another application, into fb2k, then fb2k needs to deal with those.
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 19:02:22
Quote
@vir:

Regarding backslashes as seperator...... i thought about using a backslash as well. The problem however is READING. You cannot expect that all files which are loaded into fb2k, were also tagged via fb2k. When a user loads a bunch of files which were created and tagged with another application, into fb2k, then fb2k needs to deal with those.
[a href="index.php?act=findpost&pid=354000"][{POST_SNAPBACK}][/a]


So we have three aims:
1. A way to split a string into an array of values.
2. Way to prevent splitting in some places, i. e. quotation.
3. Way to recognize foobar2k tagged files from not tagged.

The solution must be simple, but we needn't a perfect one, foobar2k users mustn't see any of this.

So I propose the following. Two charecters: one for splitting, one for quoting.
| for splitting
\ for quoting
And a signature in the end of tag string. Something like [foobar2000-id3v2].
Plugin will look for the signature. And split string only if signature is present.

id3v2
Code: [Select]
ARTIST=Artist 1|Artist 2 \| 3||Artist 4\\5[foobar2000-id3v2]


ape2
Code: [Select]
ARTIST=Artist 1
ARTIST=Artist 2 | 3
ARTIST=
ARTIST=Artist 4\5
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 19:06:34
Interesting - but why two different chars for escaping and splitting? I mean, why not use the same for both - like:

| = seperator
|| = escaped pipe-char

edit: this is similiar to how single-quotes get escaped in TAGZ
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 19:12:10
Quote
Interesting - but why two different chars for escaping and splitting? I mean, why not use the same for both - like:

| = seperator
|| = escaped pipe-char

edit: this is similiar to how single-quotes get escaped in TAGZ
[a href="index.php?act=findpost&pid=354011"][{POST_SNAPBACK}][/a]

This is for empty tags. In my example one artist is empty... Don't know really if anyone needs it. But fb2k allow this... So plugin must allow it too...
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 19:18:20
Quote
This is for empty tags. In my example one artist is empty... Don't know really if anyone needs it. But fb2k allow this... So plugin must allow it too...
[a href="index.php?act=findpost&pid=354012"][{POST_SNAPBACK}][/a]

Good point. However, remember we're talking about a flexibility/readability tradeoff here... intention of the whole idea was to make multi-value tagfields readable in other applications. Other applications however display the raw-contents of the tagfield.

This means, that it is a balance between flexibility/limitations in fb2k, and readability/gibberish in other applications.

In this case, the lowered complexity and improved readability, seem to be worth the minor limitations?

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 19:49:46
Quote
In this case, the lowered complexity and improved readability, seem to be worth the minor limitations?


Agreed on this... So I'll wait for a new plugin .

About the id3v2 itself. I've experienced a dissapointment with the foobar2000 several times. The example is the new freeDB plugin and the way it handle different codepages. Many people here expect everythig to follow standarts, but real life is different.
This is the reason for opening the source and let the developing of fb2k be more free. But the current style of developing let foobar2000 so far in it's superiority. May be trusting core people is worth it?
Title: Tag-standards In Plugins<->formatting
Post by: The Link on 2006-01-02 19:59:18
Quote
... The example is the new freeDB plugin and the way it handle different codepages. Many people here expect everythig to follow standarts, but real life is different. ...
[a href="index.php?act=findpost&pid=354019"][{POST_SNAPBACK}][/a]

What's your problem with the freedb component? I've never encountered any problems.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 20:03:53
Quote
But the current style of developing let foobar2000 so far in it's superiority. May be trusting core people is worth it?
[a href="index.php?act=findpost&pid=354019"][{POST_SNAPBACK}][/a]

I can only speak for myself. I have alot of respect for the foobar-author and some of the other devs of "quasi-official" plugins. In regards to skill and overall competence, i do trust them. I am however not sure if i share a similiar mentality and intentions with them.


Here's a variation of your idea:
Since it's desireable to keep the merged string as readable as possible in other applications, it may make sense to not bloat the tagfields themselves with an ID-sequence - but instead move it to a seperate tagfield...

ID3v2
Code: [Select]
ARTIST=foo|bar
ALBUM=this is a real p|pe char
COMPOSER=this also is a real p||pe char|and another value
ID3V2MULTI=ARTIST|COMPOSER


Result:
Code: [Select]
ARTIST=foo
ARTIST=bar
ALBUM=this is a real p|pe char
COMPOSER=this also is a real p|pe char
COMPOSER=and another value


Using a vendor-neutral ID-string may also be more diplomatic in making the system attractive to other vendors.
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 20:09:05
Quote
Quote
... The example is the new freeDB plugin and the way it handle different codepages. Many people here expect everythig to follow standarts, but real life is different. ...
[a href="index.php?act=findpost&pid=354019"][{POST_SNAPBACK}][/a]

What's your problem with the freedb component? I've never encountered any problems.
[a href="index.php?act=findpost&pid=354020"][{POST_SNAPBACK}][/a]

My problem is about russian titles. Old 0.8 plugin allows convertion of codepages on the fly. New plugin expect everything to be in unicode or latin1, but people sometimes use wrong tools to upload info. The rules get broken... Everything here is offtopic, meanwhile .
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 20:19:57
Quote
Here's a variation of your idea:
Since it's desireable to keep the merged string as readable as possible in other applications, it may make sense to not bloat the tagfields themselves with an ID-sequence - but instead move it to a seperate tagfield...

This confuses me a bit. The case is the editing. People edit the tags with there tools and can be totally unaware of MULTI tag... So they can mess a bit and break the consistency... With the signature, they are likely to delete signature if they don't know what it is for... But your idea improve readability greatly...

Quote
Using a vendor-neutral ID-string may also be more diplomatic in making the system attractive to other vendors.
[a href="index.php?act=findpost&pid=354024"][{POST_SNAPBACK}][/a]

Good point. Agreed.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 20:24:43
Quote
This confuses me a bit. The case is the editing. People edit the tags with there tools and can be totally unaware of MULTI tag... So they can mess a bit and break the consistency...
[a href="index.php?act=findpost&pid=354031"][{POST_SNAPBACK}][/a]

Asuming they - as you say - are unaware of the MULTI-field and dont modify it - what could they mess up then which they couldn't mess up in your original version?
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 20:30:35
Quote
Quote
This confuses me a bit. The case is the editing. People edit the tags with there tools and can be totally unaware of MULTI tag... So they can mess a bit and break the consistency...
[a href="index.php?act=findpost&pid=354031"][{POST_SNAPBACK}][/a]

Asuming they - as you say - are unaware of the MULTI-field and dont modify it - what could they mess up then which they couldn't mess up in your original version?
[a href="index.php?act=findpost&pid=354032"][{POST_SNAPBACK}][/a]

They can add | into a MULTI tag just like a symbol, not a sepparator. But plugin will consider it a sepparator. In the case of signature, if the user deletes signature, foobar will consider tag to be a single string and not misinterpretate pipes...
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 20:54:34
Quote
They can add | into a MULTI tag just like a symbol, not a sepparator. But plugin will consider it a sepparator. In the case of signature, if the user deletes signature, foobar will consider tag to be a single string and not misinterpretate pipes...
[a href="index.php?act=findpost&pid=354034"][{POST_SNAPBACK}][/a]

How do you rate the propability of the following to happen:

- a *foobar-user* edits the ID3v2 tags of his files with another app than fb2k
- ...and doesn't recognize the | as a field-seperator
- ...messes around with them by adding |'s for whatever reason
- ...and then afterwards loads them into foobar again and wonders whats wrong


edit: there IS a way to create a protection from your scenario - but it would make it impossible to edit/create valid multi-value fields in an app which doesn't support it natively - checksums.
Title: Tag-standards In Plugins<->formatting
Post by: Florian on 2006-01-02 20:58:30
Quote
- multi-value id3v2 fields (or multiple fields with same name) are invalid according to the standard. Foobar breaks standard in this aspect to get multivalue id3v2-fields. Result is that only first field is readable in other players - all additional fields are unusable in other applications. Thus, multi-value fields in id3v2 are currently *foobar-only* fields.[{POST_SNAPBACK}][/a] (http://index.php?act=findpost&pid=353709")

[a href="http://www.mp3tag.de/en/]Mp3tag[/url] reads and writes multiple ID3v2 fields too.

Personally, I don't like the idea of a format for multi-value fields specific to foobar2000 or Mp3tag. I can imagine an option, which merges multiple ID3v2 fields into one field when saving the ID3v2 tag. This would be according to the standard and won't break other applications.

Another option would be to merge tag fields by default and tell people to use APEv2 if they rely to multi-value fields.

Best regards,
~ Florian
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 21:01:41
Quote
Quote
They can add | into a MULTI tag just like a symbol, not a sepparator. But plugin will consider it a sepparator. In the case of signature, if the user deletes signature, foobar will consider tag to be a single string and not misinterpretate pipes...
[a href="index.php?act=findpost&pid=354034"][{POST_SNAPBACK}][/a]

How do you rate the propability of the following to happen:

- a *foobar-user* edits the ID3v2 tags of his files with another app than fb2k
- ...and doesn't recognize the | as a field-seperator
- ...messes around with them by adding |'s for whatever reason
- ...and then afterwards loads them into foobar again and wonders whats wrong
[a href="index.php?act=findpost&pid=354040"][{POST_SNAPBACK}][/a]

I've ment *not a foobar-user* get files of foobar-user, messes them a bit and give them to another foobar-user...  All this events are quite rare, but standarts must consider the future...
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 21:52:25
Another possible idea:

ID3v2
Code: [Select]
ARTIST=A
ARTIST001=B
ARTIST002=C
ARTIST003=D


Result:
Code: [Select]
ARTIST=A
ARTIST=B
ARTIST=C
ARTIST=D


Only annoyance which i could imagine would be other applications deleting i.e. ARTIST002 without reordering the rest.
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-02 22:08:29
Quote
Another possible idea:

ID3v2
Code: [Select]
ARTIST=A
ARTIST001=B
ARTIST002=C
ARTIST003=D


Result:
Code: [Select]
ARTIST=A
ARTIST=B
ARTIST=C
ARTIST=D


Only annoyance which i could imagine would be other applications deleting i.e. ARTIST002 without reordering the rest.
[a href="index.php?act=findpost&pid=354051"][{POST_SNAPBACK}][/a]

Cool, great idea... This seems to be much beter and adopted.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-02 22:14:19
Yeah, just with one caveeat: most PLAYERS will in practice behave the same way as current incompatible implementation: only first tag displayed.

I just had a long chat with ganymed, and i'm personally not so certain anymore if it is possible at all to get id3v2 multi-value fields in a reasonable way. It may be possible for purely informal fieldcontents (i.e. ARTIST)... but i see no way how to achieve it with fields where the application needs to *understand* them(i.e. MOOD).
Title: Tag-standards In Plugins<->formatting
Post by: Insolent on 2006-01-03 07:43:12
Looks like its time for ID3v3...
Title: Tag-standards In Plugins<->formatting
Post by: David Nordin on 2006-01-03 09:25:35
Quote
Yeah, just with one caveeat: most PLAYERS will in practice behave the same way as current incompatible implementation: only first tag displayed.

I just had a long chat with ganymed, and i'm personally not so certain anymore if it is possible at all to get id3v2 multi-value fields in a reasonable way. It may be possible for purely informal fieldcontents (i.e. ARTIST)... but i see no way how to achieve it with fields where the application needs to *understand* them(i.e. MOOD).
[a href="index.php?act=findpost&pid=354058"][{POST_SNAPBACK}][/a]


Why not accept the limitations of the format and instead focus on how to make it show the most relevant value in a series of a multivalue scheme.
Use a player - like foobar to organize your material, then be happy with what you can read on your portable/DVD player/car stereo etc.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-03 10:46:45
Quote
Use a player - like foobar to organize your material, then be happy with what you can read on your portable/DVD player/car stereo etc.
[a href="index.php?act=findpost&pid=354179"][{POST_SNAPBACK}][/a]

I have no interest in telling users: "tag your files in a way which will look borked in anything except foobar/mp3tag". If this should be done, then someone else should coordinate such a philosophy - i personally am not interested in something like that.

For me, the choice regarding tagging-standards is simple:

- either find a way which makes multi-value fields usable in most other apps as well as foobar

- or don't rely on multi-value fields at all when creating tagging-schemes(possibly leaving the door open to *optionally* use multi-value fields - i.e. saying that a single STYLE-field should contain ALL styles, but not making it invalid to store them in seperate fields)

First scenario does not seem likely to happen. Second scenario will poison modern tag-systems with an obsolete style of tagging.
Title: Tag-standards In Plugins<->formatting
Post by: Florian on 2006-01-03 10:50:10
Quote
- either find a way which makes multi-value fields usable in most other apps as well as foobar[a href="index.php?act=findpost&pid=354199"][{POST_SNAPBACK}][/a]

As I've already told you yesterday, most programs don't even support/display user-defined TXXX fields (like ARTIST###).
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-03 10:55:04
So, do we choose option 2 (and stick to it during future discussions in this thread) ?
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-03 11:21:40
Quote
Yeah, just with one caveeat: most PLAYERS will in practice behave the same way as current incompatible implementation: only first tag displayed.

I just had a long chat with ganymed, and i'm personally not so certain anymore if it is possible at all to get id3v2 multi-value fields in a reasonable way. It may be possible for purely informal fieldcontents (i.e. ARTIST)... but i see no way how to achieve it with fields where the application needs to *understand* them(i.e. MOOD).
[a href="index.php?act=findpost&pid=354058"][{POST_SNAPBACK}][/a]

I think the following is rather good:
Code: [Select]
ARTIST=A, B, C & D
ARTIST000=A
ARTIST001=B
ARTIST002=C
ARTIST003=D

So only foobar is intended to edit tags, but every other player will see good, readable value.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-03 11:41:15
Quote
I think the following is rather good:
Code: [Select]
ARTIST=A, B, C & D
ARTIST000=A
ARTIST001=B
ARTIST002=C
ARTIST003=D

So only foobar is intended to edit tags, but every other player will see good, readable value.
[a href="index.php?act=findpost&pid=354206"][{POST_SNAPBACK}][/a]


3 issues:

- it may make sense to only use ", " as seperators, because depending on the content, the & may or may not be appropriate. ", " on the other hand is quite neutral.

- if another application changes the either ARTIST or ARTIST###, then which of the two has priority when foobar reads them?

- it only works with official id3v2 tags, not with custom fieldnames, because as ganymed said: many applications dont even understand TXXX-frames. Thus, stuff like STYLE will be completely unreadable on other players anyways.
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-03 11:51:26
I just want multiple tags. I think we must warn users that using id3v2 will be incompatile with most other players. But we mustn't be compatible with so limiting standart as id3v2. foobar is not compatible with it and we must not artificially limit foobar functionality. We are foobar users after all...
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-03 11:55:54
With the last mentioned issue, i didn't mean that as a flaw - just wanted to point out that it will not guarantee that all metadata will be readable in other apps.
Title: Tag-standards In Plugins<->formatting
Post by: vir on 2006-01-03 12:08:27
Quote
I think the following is rather good:
Code: [Select]
ARTIST=A, B, C & D
ARTIST000=A
ARTIST001=B
ARTIST002=C
ARTIST003=D

So only foobar is intended to edit tags, but every other player will see good, readable value.
[a href="index.php?act=findpost&pid=354206"][{POST_SNAPBACK}][/a]


Quote
- if another application changes the either ARTIST or ARTIST###, then which of the two has priority when foobar reads them?

I think we can allow foobar only read ARTIST### fields but write both ARTIST and ARTIST### fields... Events when this is not good are very rare.
Title: Tag-standards In Plugins<->formatting
Post by: David Nordin on 2006-01-03 14:55:38
Quote
So, do we choose option 2 (and stick to it during future discussions in this thread) ?
[a href="index.php?act=findpost&pid=354201"][{POST_SNAPBACK}][/a]


Why limit something based on an inferior format?

If you use multivalue shit with APE tagging or <insert other appropriate tagging format here> and make sure that ID3v2 tags get the most relevant value from the superior format - why wouldn't that suffice?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-03 17:28:49
Quote
Why limit something based on an inferior format?

Because this thread is about making things work, not about promoting a tag-system and not about telling users which fileformat/tag-system/application to use. The goal of this thread plain and simply is compatibility and adoption. If you read the first post, then you will maybe notice that this intention is exactly how this thread came to life. And if you take a look at the discussion notes, finished standards as well as how discussions happened, then you may notice that adoption/userbases, avoiding disruption and generally making things easy for the casual user always have been top priorities. The reason why this is the case is because this thread isn't about standardization for the sake of standardization - instead, we plain and simply want schemes which: A. work, and B. get used by as many people as possible.

So, let me put this straight: anything which doesn't work in id3v2 is uninteresting - because it wouldn't work for the majority of users in the majority of applications. ID3v2 is not an "afterthought" here..... it forms the main vehicle, because its the tag-system which is used by the majority. Features of other tag-systems are just a nice bonus for the intentions of this thread.

I've explained this multiple times to you - repeatetly trying to promote your agenda won't change the answer as long as i'm coordinating this thread. Personally, i think this thread is uninteresting to you, because your goals and opinions are in direct contradiction with the intentions of this thread.
Title: Tag-standards In Plugins<->formatting
Post by: Brother John on 2006-01-14 01:03:41
Almost two weeks without any posts and no changes to the wiki. I guess the multi-value issue is still not resolved. Here are my views.Because of (1) dropping multi-value altogether seems stupid. That’s like saying: “We’ll stay with horse carriages and not use cars because horses can’t drink petrol.” How can progress happen when we artificially limit the new technology because of the old one’s limitations? That’s why I also strongly disagree with
Quote
Features of other tag-systems are just a nice bonus for the intentions of this thread.
On the other hand MP3/ID3 are without a doubt the most commonly used formats. Simply saying “Don’t use them” would be equally stupid.
(2) makes it clear that every attempt to add multi-value to ID3 is a more or less dirty hack. Essentially we’d create an unofficial ID3v3.

I see only one reasonable and simple solution: Leave everything as it is now for ID3 and deal with the consistency problems when simultaneously using ID3 and APEv2. And why not go with the general foobar philosophy of making your own choices to solve the problem? That would require two configuration options when using both ID3 and APE:
- Choice of a separator char for pseudo-multi-value ID3.
- In case of conflict, which format should have higher priority?

Based on this configuration tagz scripts could always be fed with multi-value fields (generated or real ones). Same goes for creating multi-value fields.
Of course the choice of separator char can cause conflicts, but imo we can only have either an easy to type separator or an unambiguous separator, never both.

Cheers,
Brother John
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-14 07:43:29
Quote
deal with the consistency problems when simultaneously using ID3 and APEv2. And why not go with the general foobar philosophy of making your own choices to solve the problem? That would require two configuration options when using both ID3 and APE...
Brother John
[a href="index.php?act=findpost&pid=356895"][{POST_SNAPBACK}][/a]

Umm, maybe i missed something, but since when does foobar support to use ID3*v2* and APEv2? It doesn't because its stupid. The problem is not APEv2 - it is ID3v2.... which is never used in combination with APE-tags.

As for "progress" - as i said already, my intention and the original purpose of the thread wasn't/isn't progress, but compatibility.... so progress is no argument for me - limitations however is one(but not the only one).

Regarding no replies and conclusions - situation currently is that:
1. Majority of foobar users use IDv2 instead of APEv2 - but they dont post in the thread
2. Minority of foobar users who use APEv2 are very vocal in the thread
3. No one yet IMHO proposed a reasonable solution to: A. Ensure compatibility, B. Not disallow multi-value fields, C: Not create a "many ways to do it"-mess (well, okay, "vir" proposed an interesting idea - but someway my feeling is telling me that it will not be implemented into foobar)

Thus, i currently can neither disregard the opinions of the vocal minority, nor can i disregard the silent majority - and in addition to this, there's not even a solution on the table. Deadlocked thread situation.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Brother John on 2006-01-14 16:33:07
Quote
since when does foobar support to use ID3*v2* and APEv2? It doesn't

Oh, I didn't know that even when using the ID3v2 plugin and "ID3v1 + APE" ID3v2 gets stripped from the file by default. But that's just fine. So we only have to find a solution within ID3v2.

Because we're speaking about compatibility I consider everything not an option, that is unlikely to display correctly outside fb2k; which rules out the current (not spec compliant) way of using true multi-fields as well as using pseudo multi-fields (the FIELD001, FIELD002 approach).
Im also not a fan of escaping because of its readability issues. And how likely are users to adopt a rather complicated system with escape and separator characters, that very easily can look absolutely ugly and hard to read?

So imo the only two reasonably practical and simple solutions are using one field with multiple values separated by a single character. But should it be a "weird" character or an easy to type one like the backslash?

Backslash as separator
Pros
* The backslash is easy to type.
* Considering that the typical fb2k user has at least some experience with computers, it's a character already widely known and used as a separator (Windows folder structure).
* It's reasonably unlikely to appear in a field as regular character.
* Readability outside fb2k is ok.
Cons
* While readable, a single field with multiple values separated by \ certainly doesn't look pretty outside fb2k.
* When editing outside fb2k the user has to use \ correctly.
* While unlikey, it still might appear as a regular character.

"Weird" character as separator (e.g. $char(160))
Pros
* It's virtually certain not to appear as regular char.
* Because of that, no parsing problems.
* Because $char(160) looks like a space readability will be ok outside fb2k. It might even look nice.
Cons
* Cannot be entered with a simple keystroke, which makes editing outside fb2k difficult.
* The user has to know about the separator and use it properly outside fb2k.


I must admit, I'm torn. The \ is better for editing purposes while $char(160) is safer and more pleasant on the eye. What it boils down to in the end is: what's more important to the users? Simple editing or nice looks?

On a sidenote: When 0.9 goes final and hopefully doesn't break ID3v2 specs anymore, what to do with existing wrongly tagged files?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-14 21:09:53
Regarding multi-value field via seperators - it should be noted (as explained by ganymed) that non-official id3v2 fields (that means all those custom fieldnames like i.e. STYLE) are NOT readable by most other apps. Thus, any scheme we discuss here which can not be done via official id3v2-fields will be unreadable by other apps anyways. So, we will have incompatibility anyways.

Personally, i think the two solutions which make most sense are:

1. The "field, field001, field002" approach. For those other apps which dont support custom fields, everything will stay as it is - and for those which do read them, the tagfields are fully readable. In addition to this, it can also transparently be used for official fields as well(store "field" as official frame, and "field001, field002" as custom frames). However, this is purely theoretical unless peter confirms that he is willing to implement it into the id3v2 plugin.

2. Accept that we cannot have id3v2 multivalue-fields. Only create tag-standards which work with single-value field(s). Agree on some kind of guideline on how to not exclude doing it with multivalue-fields for non-id3v2-tags when reasonable. This means that single-value field compatibility will have priority and therefore some schemes will probably be single-value only(i.e. "MOOD WARMTH", "MOOD UPLIFTING", etc.)... but some other schemes may support both, single-value and multi-value fields(i.e. "STYLE=Shoegaze, Noise" as well as "STYLE=Shoegaze", "STYLE=Noise".

Regarding your last question - i think the priority is:
0. Approach needs to be straight-forward, non-confusing and easy to understand.
1. Easy to edit in fb2k
2. Looking nice in other apps
3. Editing in other apps

With none of the above three being unimportant.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: WigBaM on 2006-01-16 03:41:01
regarding 'ALBUM ARTIST',

Recently have tried 0.9 and found that some of my scripts weren't working as they should. It wasn't long before I found THIS (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Titleformat_Reference#.25album_artist.25)
(sorry, if it was brought up before)

It seems like a chaos  Everybody is pulling the cart in opposite way. Hope it all gets sorted in final release.
Added: Oh, I see, we use $meta(album artist) from now on. False alarm. 

[span style='font-size:8pt;line-height:100%']A bit off-topic:
Also Lyx, do you have any info on future CUE-sheet taggins support? I have noticed 0.9 supports DATE and GENRE which is good, but what about full support? I'll give you the source of my cue_ex, maybe there is a way it could be implemented in defaut 0.9? Having in mind it's literally few 'for' cycles added to original cue.cpp.[/span]
Title: Tag-standards In Plugins<->formatting
Post by: Brother John on 2006-01-16 15:00:41
Lyx, I agree with your second proposition. It seems impossible to hack multi-value into ID3v2 in a way that provides all of this:
- looks nice everywhere,
- works outside fb2k,
- is hard to break from outside fb2k,
- is easy to understand.

To avoid adding to the existing ID3v2 mess we should just accept the limitations and stick with single-value fields.

But I don't really see the point of discouraging multi-value for tagging systems, that support it. At least tagz scripts are indifferent to the problem anyway, because when I have multiple fields in a file and access them with %field% I get "Value1, Value2, Value3" returned, as if it was a single field.
(Note: This is true for v0.8.3. I don't know about 0.9.)

The only remaining problem I can think of is album list views and general sorting. Here we have two possibilities:
1. Warn the user that single-field-multi-value might have undesireable results in those cases.
2. Built some kind of tag splitting into the relevant plugins, which essentially brings us back to the original problem.


@WigBaM
Actually the $if2(%album artist%,%artist%) construction is so common today that almost every tagz scripter loves the new remapping (and not only this one).

Brother John
Title: Tag-standards In Plugins<->formatting
Post by: RevivalofHonor on 2006-01-16 16:20:29
Quote
The only remaining problem I can think of is album list views and general sorting. Here we have two possibilities:
1. Warn the user that single-field-multi-value might have undesireable results in those cases.
2. Built some kind of tag splitting into the relevant plugins, which essentially brings us back to the original problem.
[a href="index.php?act=findpost&pid=357582"][{POST_SNAPBACK}][/a]

I personally don't even see #2 as a viable solution to album list/sorting.  Everybody has such a different way of doing single-field-multi-value tags that they like, particularly artist (artist feat. artist; artist featuring artist and artist; artist, artist, & artist; artist, artist & artist; artist with artist; artist (produced by producuer); and on and on) that getting people to change their tagging style would be even more of a hassle, and trying to program a split for every conceivable style is madness.  Well, okay, it may not be madness if the plugin allowed user to input the type of split they used, but be prepared for three or more split characters (artist feat. artist, artist, & artist).

I suppose, of course, that this is the purpose of this thread, but this'll be an uphill battle until the ID3 specification is updated to include multi-value tags.

Quote
But I don't really see the point of discouraging multi-value for tagging systems, that support it. At least tagz scripts are indifferent to the problem anyway, because when I have multiple fields in a file and access them with %field% I get "Value1, Value2, Value3" returned, as if it was a single field.
(Note: This is true for v0.8.3. I don't know about 0.9.)

0.9 does the same as 0.8.3 in this regard (tested with betas 1-13).  The tagz script allow users to pull out just the first value if reqested via $meta(artist, 0).  I think we should encourage multi-value for the tagging systems that support it.  It is true that the majority of people use mp3 through iTunes or Winamp, and are thus used to ID3v1 &ID3v2, but many people who use foobar use FLAC, APE, MPC, OGG in addition to mp3, and all of those (I believe; correct me if I'm wrong) natively support multi-vaule tags.  It would be rude to disclude them just because mp3|ID3V2 can't support something.

For the ID3v2 multi-value problem, I second the backslash as the primary separator, propose the pipe (|) as first runner-up, and $char(160) as second runner-up.  foobar2000 already uses the backslash as a separator when tagging multiple files, and it is quite unlikely for it to appear as a regular character.  True, it may not be "pretty", but it is easily readable.  If we do find that the backslash is used as a character for any artist|album|song or whatever, the pipe is a good second choice.  If that doesn't work, $char(160) will work fine.  If that has to be used, some kind of notice would have to put out there (a sticky or wiki entry) on how to input $char(160) in tag editors outside of foobar2000.
Title: Tag-standards In Plugins<->formatting
Post by: LoKi128 on 2006-01-17 00:58:29
Haven't really been following the discussion, but I think we should not use ASCII character 160 as a delimiter, since it is pretty common in spanish titles. You know, the whole González thing  Maybe something weirder, like one of the higher ASCII characters... the ones used to make ASCII boxes would be good.
Title: Tag-standards In Plugins<->formatting
Post by: Brother John on 2006-01-17 02:21:57
LoKi128, I'm sure we're talking about different things. The character "á" is not discussed here!

To clarify things for everyone: Activate num lock, hold down ALT and type on the number pad 0160. The resulting character looks exactly like a space.

The leading zero is important and probably, what confused you. Indeed you end up with an á if you leave it out.
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-01-17 19:23:06
Quote
But I don't really see the point of discouraging multi-value for tagging systems, that support it. At least tagz scripts are indifferent to the problem anyway, because when I have multiple fields in a file and access them with %field% I get "Value1, Value2, Value3" returned, as if it was a single field.
(Note: This is true for v0.8.3. I don't know about 0.9.)

There are two players in the game - one is the human user - the other is the machine.

Making something "work" for the user is the easy part - as long as the player can display it in a meaningful way, it works for the user. End of story.

For a machine, the matter becomes more difficult, because machines suck when it comes to "intuition" and understanding. Machines are stupid - unless you tell them exactly how to do it, they will fail. What this means in our case, is that the more variations there are in which metadata can be stored, the more difficult(and thus unprobable) it is for plugins/apps to understand/support.

I did not propose to "discourage" multi-value field support. I just proposed that it should be secondary priority. For metadata-schemes where machine-readability is less important(i.e. STYLE) allowing both, single-value as well as multi-value fields may be no problem. But for schemes where machine-readability has high priority(i.e. MOOD), "more than one way to do it" is a bad idea IMHO. Heck, the whole point why the thread was started was to get away from exactly such scenarios.

Thats what i mean in a nutshell. There may (and probably will) be exception-cases, where a decision depends on more than the above described aspects.

---

@WigBaM
Sorry, no - i have no info about whats in the making regarding cuesheet-support.

Quote
It is true that the majority of people use mp3 through iTunes or Winamp, and are thus used to ID3v1 &ID3v2, but many people who use foobar use FLAC, APE, MPC, OGG in addition to mp3, and all of those (I believe; correct me if I'm wrong) natively support multi-vaule tags.

You're welcome to start a poll about "how many people use ID3v2 and how many use another tag-system". If you do it, then word the questions and initial post in an unbiased way.

---

I consider this thread stalled and have low confidence in discussion bringing up anything new. I will give this thread one more week.

If afterwards...

- ...someone can show me founded proof that the majority of foobar users do not use id3v2, then i'll change my mind

- ...peter confirms that he has the intention to improve id3v2 multivalue-field compatibility, i'll make use of it

- ...someone else steps forward to take over thread-moderation, i'll let that happen

- ...if none of the above happens, i'll push forward with what i outlined in the beginning of this post.
Title: Tag-standards In Plugins<->formatting
Post by: LoKi128 on 2006-01-18 00:55:56
Quote
LoKi128, I'm sure we're talking about different things. The character "á" is not discussed here!

To clarify things for everyone: Activate num lock, hold down ALT and type on the number pad 0160. The resulting character looks exactly like a space.

The leading zero is important and probably, what confused you. Indeed you end up with an á if you leave it out.
[a href="index.php?act=findpost&pid=357714"][{POST_SNAPBACK}][/a]


Foot-in-Mouth Syndrome strikes again! I will continue lurking now. About the tags though, in my opinion the priority should be compatibility with other apps, not just Foobar2000. Here are my priorities:

0. Approach needs to be straight-forward, non-confusing and easy to understand.
1. Looking nice in other apps
2. Editing in other apps
3. Easy to edit in fb2k

In the current state of things, we should try to keep everything in a single field, with a common format, such as Artist1, Artist2, etc... which has been proposed before.

Why is this? Well, Fb2k is just a small player in the world of digital audio. While most of us here use it quite a bit, we also use DAPs or other interfaces like the XBMC or other "home theater" media players. So it is in our best interest to make sure the tags show up well "everywhere" rather than focusing on just Fb2k. It is for this same reason that I continue to stick with MP3 rather than any of the other more efficient formats. There is no point in encoding and taging my entire collection if I can't listen to it everywhere.

On a high note, I recently started using the ALBUM ARTIST tag, and it has been a godsend! So keep the good ideas flowing!
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-02-04 05:09:21
[span style='font-size:14pt;line-height:100%']Draft for STYLE:[/span]
Quote
[span style='font-size:13pt;line-height:100%']STYLE[/span]

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: [Select]
// 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)


Comments and alternative proposals welcome.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: WigBaM on 2006-02-04 09:21:45
STYLE is good, agreed. Have been using STYLE tag for ages now with the same syntax, though sometimes it was a real mission to correctly identify it
Also, pretty recently I have started to use a separate special EXINFO tag (which stands for 'extended track information'). In there I put track-specific things like '(Power) Ballad', 'Heavy', 'Instrumental', 'Acoustic' (doesn't necessarily mean unplugged!) etc. Also I am still to decide how to call non-music tracks, ex. speeches, poems etc.? That could also go here. At first I thought I might use MOOD or THEME, but this info doesn't really fit in neither of those. And TYPE tag I know was suggested to be used to identify recording type, eg. Single, Live, Unplugged etc. (although mixing two together is another idea) so I stick with EXINFO for now, but, of course, other suggestions are welcome.
Title: Tag-standards In Plugins<->formatting
Post by: Brother John on 2006-02-05 13:58:11
Lyx, that proposition sounds very reasonable to me.

WigBaM, your EXINFO seems to be a really individual choice. Personally I don't feel it could be adopted publicly. After all we have COMMENT for any "extended info".


So, now that the STYLE issue is about to be resolved, I'd like to bring back another topic. The DATE discussion hasn't reached a solution and such an important tag absolutely should have an entry into the Encouraged Standards.

My choice would be DATE for the track date and ALBUM DATE for, well, the album date. Why?
1) Consistency (think of ARTIST and ALBUM ARTIST).
2) Easy to understand and use.
3) Even if a lot of people use DATE as the album date (which is an option I never even considered before reading this thread, btw) this won't break Tagz scripts. $if2(%album date%,%date%) is perfectly compatible with both DATE variants.

What I feel we shouldn't care about is the actual meaning of "date": Release date? Recording date? Buying date? Date first heard? As the earlier discussion has shown there are two many possibilities to standardize them all. So DATE/ALBUM DATE will be generic fields and all additional date information has to go into individual custom tags or, of course, the COMMENT field.

What do you guys think?

Brother John
Title: Tag-standards In Plugins<->formatting
Post by: WigBaM on 2006-02-05 14:23:07
Brother John
Yeah, I agree EXINFO might be individual. forget it.

Regarding DATE & ALBUM DATE. Again have been using it for ages and in most cases it is enough to provide all the information you need, but there are some cases when additional tagging is needed, for example:
Track was initially released (composed & recorded) in yearA
Then it was re-mastered, re-mixed, re-recorded (whatever) in yearB (I do mean(!) it sounds differently, differently arranged and/or length is different)
Then in YearC we have a compilation which includes a version of the track from yearB;
So what your DATE & ALBUM DATE tags will be like? I know this is a rare weirdo case, but just for the experiment's purity sake
Title: Tag-standards In Plugins<->formatting
Post by: Brother John on 2006-02-05 18:14:18
Quote
So what your DATE & ALBUM DATE tags will be like[a href="index.php?act=findpost&pid=362082"][{POST_SNAPBACK}][/a]

Scenarios like this are exactly the reason why I say, let the user decide what "date" means. A public script's only assumption should be: DATE, ALBUM DATE are the most important dates, i.e. with the highest priority for playlist display.

Brother John
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-03-01 22:01:42
! STYLE added to agreed upon tag-standards !

__________________________________

Important:
I'd like to announce that i retreat from my moderation-role regarding this thread. I may still sometimes voice my opinion but i will no longer engage in thread-coordination or moderation.

If someone else wants to take over, then the best approach probably would be to first discuss it with the others in the thread, and if you get sufficient acceptance, then create a NEW thread, copy the contents of the first post of this thread - and then continue tag-standards discussions in the new thread.

If this happens and you would like me to edit the first-post of this thread to point readers to the new thread, then just drop me a PM. Moderators and admins should also feel free to make any modifications if necessary.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: tm777 on 2006-03-10 17:34:33
Hello,

Just a suggesting. Only my first idea!

There could be a meta-meta-tagging-system. That means that:
- a schema would describe the semantics of the Tags.
- Tags would have a GUID instead of a "name"
- a schema has it's own GUID
- a player has it's own database (for offline- purposes) of schemata that could be updated from an central authority
- schemata could be an attachment of a file
- a database- lookup can be performed by the player/Tagger to decide how this Tag should be handled
- user defined (e.g. player depended) schemata could be stored anonymously by an central authority
- ebml- based
- the complexity of this tagging- system has to be fully transparent for users
- this meta-meta-tagging-system has only a few elements: TAGS, TAG, TARGET, TAGATOM

Example (like MATROSKA-Tags):
Code: [Select]
<TAGS SCHEMA = 0987654321>
  <TAG>
 <TARGETS>
    <TAGATOM UID = 2345678901>
         <VALUE>a physical target (capterUID or something)</VALUE>
       </TAGATOM>
 <TAGATOM UID = 3456789012>
         <VALUE>a logical target (movement, Album etc.)</VALUE>
       </TAGATOM>
 </TARGETS>
    <TAGATOM UID = 1234567890>
        <VALUE>Bach</VALUE>
    </TAGATOM>
    <TAGATOM UID = 0123456789>
        <VALUE>Johann Sebastian</VALUE>
    </TAGATOM>
    </TAG>
<TAGS>

<SCHEMA UID = 0987654321>
 <BASE>7654321</BASE> //a schema, wich this schema derives
 <TAG UID = 2345678901>
    <MAPENTRY>ChapterID</MAPENTRY>
 </TAG>
 <TAG UID = 1234567890>
   Somthing to Describe that 1234567890 + 0123456789 = COMPOSER
 <TAG>
</SCHEMA>


The advantages:
- a standard(s) could be made by the community
- Flexibility
- Nearly implemented by the great Matroska- team (EBML!)

Disadvantages:
- not supported :-)
- Very abstract
Title: Tag-standards In Plugins<->formatting
Post by: kl33per on 2006-03-11 04:19:13
And the point of this system is what?  What does it allow us to do that we can't do now?
Title: Tag-standards In Plugins<->formatting
Post by: Erich w/ an h on 2006-04-09 02:31:08
so, questions and such...

example, The Birthday Party: Mutiny / The Bad Seed EP. Its one disc, but its two seperate releases compiled. Would 'discname' be appropriate to split the album in terms of tagging? and is Album Date widley used? and is discname, if used, used as one or two words, such as Album Artist being used with 2 words instead of 1?

Artist: The Birthday Party
Album Date: 1989-08-07
Date: 1983-19-09
Album: Mutiny / The Bad Seed EP
Discname: Mutiny
Tracknumber: 04
Title: Deep In The Woods

Artist: The Birthday Party
Album Date: 1989-08-07
Date: 1983
Album: Mutiny / The Bad Seed EP
Discname: The Bad Seed
Tracknumber: 10
Title: Mutiny In Heaven

Also, what about remastered albums? I use the original release date as the date, would album date be more appropriate for the remastered release? Sometimes I have both versions if the album has significant changes (Megadeth's remasters were also remixed and had changes to some tracks), but having the album title with (Remastered) kind of bothers me. Is there a sub field thats used for things of the sort? I have %version% tags for songs, for remixes and such, but I dont even know if thats a widely done practice. would %song version% and %album version% be good ideas?

And is venue widely accepted? does that normaly include city, state, such as Venue: Jones Beach: Wantaugh, NY?
Title: Tag-standards In Plugins<->formatting
Post by: Lyx on 2006-04-18 13:00:24
example, The Birthday Party: Mutiny / The Bad Seed EP. Its one disc, but its two seperate releases compiled. Would 'discname' be appropriate to split the album in terms of tagging?

IMHO, no. Discname should be purely cosmetical and only be an *addition* to discnumber. Thus, there should be as many different discnumbers as there are discnames. But there currently is no solution to the problem.

My personal opinion: Just as with classical music (opus), there should be a CHAPTER-tag. But i doubt that it is widely used, and as mentioned earlier, i'm not moderating this thread anymore.

Quote
and is discname, if used, used as one or two words, such as Album Artist being used with 2 words instead of 1?

No, just DISCNUMBER and DISCNAME - not ALBUM DISCNAME or DISC NAME.

Quote
Also, what about remastered albums? I use the original release date as the date, would album date be more appropriate for the remastered release?

There is no agreed upon solution for such cases yet, so you're free to do it however you like.

Quote
I have %version% tags for songs, for remixes and such, but I dont even know if thats a widely done practice. would %song version% and %album version% be good ideas?

Personal opinion - track-versions (like remixes) should just be entered into the TITLE-field

Quote
And is venue widely accepted? does that normaly include city, state, such as Venue: Jones Beach: Wantaugh, NY?

When we tried to standardize that the last time, we failed because there were too many different opinion. I pushed for VENUE, while others pushed for multiple LOCATION-fields.

Generally, how to enter dates is one of the most disputed topics and there is no clear consensus how to do it.

- Lyx
Title: Tag-standards In Plugins<->formatting
Post by: Erich w/ an h on 2006-04-19 06:13:28
Vielen Dank!
Title: Tag-standards In Plugins<->formatting
Post by: Prodoc on 2006-04-19 10:54:42
A tag I've been wanting for a while is one where I can store the location of the cover art, not the cover art itself. This way you can link to the cover art so you don't have to put the image inside the tag. Something in the lines of ARTURL, COVERURL or IMAGEURL to be more general. To stick with the proposed names in the ID3 specs WWWIMAGE could also be used.
This tag can be used to storing a path of plain url. In case of the path I think it should be recommended to use relative paths but absolute paths would work as well.

Would this be a nice addition to the 'Encouraged Tag Standards'? Anyone know of a better name for such a tag?
Title: Tag-standards In Plugins<->formatting
Post by: Brother John on 2006-04-19 14:18:58
You can add such a tag whenever you like. But the support for actually accessing the contents from the stored location is nothing tagging can do. You'll need a plugin with that functionality.
Title: Tag-standards In Plugins<->formatting
Post by: Prodoc on 2006-04-19 15:37:42
You can add such a tag whenever you like. But the support for actually accessing the contents from the stored location is nothing tagging can do. You'll need a plugin with that functionality.

This goes for basically all tags discussed here. Support if a totally different discussion. If we don't introduce a generally accepted tag, support we never be created.
Once we agree on such a tag it won't be much of a problem adding support to the currently available cover art viewer(s) plugin for foobar or even iPodLinux or Rockbox for that matter.
Title: Tag-standards In Plugins<->formatting
Post by: drbeachboy on 2007-01-22 20:30:44
I need an opinion on how how to tag various genres of Christmas music. Would the "STYLE" tag be the correct one for storing "Christmas"? At the moment I am using "GENRE" for "Christmas". Since we just came out of the Christmas season, I realized that I have everything from Classical, Swing, Pop, and Rock, so I'd like my tags to be more specific.
Title: Tag-standards In Plugins<->formatting
Post by: Brother John on 2007-01-22 22:40:23
The recommendation states
"the main "genre" should go into the GENRE-tagfield"
and
"the tag-fieldname used for storing secondary music-styles is "STYLE"".
So, yes, a STYLE=Christmas and GENRE for the music genre would be reasonable according to the recommendation.
Title: Tag-standards In Plugins<->formatting
Post by: odyssey on 2007-01-23 09:19:15
Actually I think AMG's definition should be better implemented, which would put Christmas in a "Theme"-category.

I dislike the STYLE-proposal. I think it should be put in a multi-value field, and tagging would be easier if a developer would pick up my idea for modding foo_browser.
Title: Tag-standards In Plugins<->formatting
Post by: drbeachboy on 2007-01-23 23:39:08
Brother John & odyssey,

Thank you for your input. It is much appreciated. I'm not sure which of the two that I will use, but I did try THEME and foobar2000 tagged the file with no problems. I added %THEME% to foo-browser and it took that tag and shows it without incident.

@odyssey: If foo-browser accepts THEME, and shows it properly, then I'm unclear about your "...if a developer would pick up my idea for modding foo-browser" statement?

Edit: I read your previous post, and now I understand. Good idea! 
Title: Tag-standards In Plugins<->formatting
Post by: panfist on 2007-01-24 11:57:46
Hi I'm new to this thread and also new to these boards. I've read a ton of posts in this thread, but not all of them, so I apologize if what I have to say has already been said, but I think it's a good idea and a lot of people would support it.

Perhaps instead of enforce a tagging standard on users, allow them to map their tagging standard to the hypothetical foobar tagging standard. Imagine that when you add folders to the media library in foobar, you go through a short wizard where you can define how your tags translate to the foobar standard. This has two major benefits the way I see it:Perhaps this could be integrated with foo_custominfo or a similar component?

Edit: Is this similar to the meta-meta tags in post 459?
Title: Tag-standards In Plugins<->formatting
Post by: Lesmo16 on 2007-02-24 13:11:41
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
Adoption-Status: medium stage
  • RATING is already in widespread use and is supported in many displays
  • ALBUM RATING is in early adoption stage


I have two questions resp. suggestions concerning the actual rating implementation.

1) What about using a combined RATING and ALBUM RATING tag?

I'm thinking about something similar to the actual use of TRACK tagging.
For each track we use one value for the track and one for the album.
The track value is TRACK and the album value is TOTAL TRACKS.
The complete tag looks like TRACK NUMBER / TOTAL TRACKS and is stored in TRCK.

OK - we could use the same for rating:
For each track we use one value for the track and one for the album.
The track value is RATING and the album value is ALBUM RATING.
The complete tag looks like RATING / ALBUM RATING.
Actually it's stored in TXXX.


2) Why are the rating values stored in TXXX instead of using POPM?

I understand TXXX as an universal frame to fill with "rather undefined" stuff.
So I like to suggest using POPM, which seems to be made to rate the tagged file.

The following quote is taken from http://www.id3.org/id3v2.4.0-frames (http://www.id3.org/id3v2.4.0-frames)

Quote
4.18. Popularimeter

The purpose of this frame is to specify how good an audio file is. Many interesting applications could be found to this frame such as a playlist that features better audiofiles more often than others or it could be used to profile a person's taste and find other 'good' files by comparing people's profiles. The frame is very simple. It contains the email address to the user, one rating byte and a four byte play counter, intended to be increased with one for every time the file is played. The email is a terminated string. The rating is 1-255 where 1 is worst and 255 is best. 0 is unknown. If no personal counter is wanted it may be omitted. When the counter reaches all one's, one byte is inserted in front of the counter thus making the counter eight bits bigger in the same away as the play counter ("PCNT"). There may be more than one "POPM" frame in each tag, but only one with the same email address.

Code: [Select]
<Header for 'Popularimeter', ID: "POPM"> 
Email to user   <text string> $00
Rating          $xx
Counter         $xx xx xx xx (xx ...)
Title: Tag-standards In Plugins<->formatting
Post by: Yotsuya on 2007-02-24 17:13:02
You actually want to put your email address in your mp3 files? I sure hope you don't swap on P2P networks.
Title: Tag-standards In Plugins<->formatting
Post by: Lesmo16 on 2007-02-24 17:38:55
What a curious comment about a serious request! 

Nobody is forced to write an email address into the file - I wouldn't do it.
And P2P? Sorry, but I can't see any context!

The purpose of this request was to see, if the POPM frame could be used in a different way to a more common approach.
I.e. not to use the outdated definition, but redefine it to be as described above.
IMHO, the POPM frame is the one, which comes closest to the idea of rating.
Title: Tag-standards In Plugins<->formatting
Post by: Yotsuya on 2007-02-24 18:01:47
Yes I would agree that POPM appears to be specifically written for the purposes of rating tagging. However, it appears that the POPM frame relies on a user's email address in order to differentiate user's ratings. You could use something other than an email address to uniquely identify a user but that would be straying outside the spec and what's the point of implementing a standard if you are not going to follow it?

On the surface I think your suggestion of people migrating to the POPM fra,e for rating is a good one and reasonably founded, however consider if someone were to get ahold of one of your mp3s using this frame properly and put it on a P2P network (or heaven forbid you actually hop on one yourself and mass share your entire library). I think you would find yourself quickly added to a multitude of email spamming lists.

My previous post was not intended as a troll but to raise a serious concern regarding your suggestion. I think the security risks of slapping your email address on your mp3's weighs more heavily than your (well intentioned) desire for people to change their tagging behavior.

Also consider that multiple POPM frames will add even more bloat to your files than the current practice of a single RATING tag.
Title: Tag-standards In Plugins<->formatting
Post by: Rotsiser Mho on 2007-03-16 05:19:24
Hello all,

I have been toying a bit with the idea of writing a cross-platform, cross-player media library.  As such, standardization of tags/fields is something I think is important, especially if it means compatibility is more-or-less achieved between players.

Therefore, I agree that using the POPM field for rating information would be a good idea.  While I don't think it's a good idea to store one's email address (user name maybe?), I think it should be used because Windows Media Player can be configured to use it to store ratings information.  I haven't tested it myself, but I imagine WMP reads data from this tag by default as well if it exists (assuming the email address field matches whatever Microsoft decides to store there anyway).

I at least think this should be investigated.  I'll do it myself if necessary.  But I don't think it would hurt to store rating information in POPM in addition to a RATING tag in the TXXX field (isn't that where it's being stored now?) in the interest of compatibility with WMP.
Title: Tag-standards In Plugins<->formatting
Post by: Jose Hidalgo on 2008-03-04 00:20:41
Hello everybody,

First of all, please read this small topic for information : http://www.hydrogenaudio.org/forums/index....showtopic=61383 (http://www.hydrogenaudio.org/forums/index.php?showtopic=61383)

This being said, here are my thoughts :

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: [Select]
// 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)

It seems the adoption of that proposed %style% standard hasn't been that simple, because since mar. 1, 2006, that adoption hasn't really gone a long way from the start (there isn't any official standard yet).

I don't know what the definitive standard will be, and I certainly am no one to decide on such a standard. However, if I had to propose or vote for something for that subgenre standard, it would certainly be %subgenre%

Advantages : all those of %style%, especially this one :
Title: Tag-standards In Plugins<->formatting
Post by: wolfsong on 2008-03-05 13:44:22
  • the styles should be seperated with a comma and space, like "post-rock, noise, electronica"

Should be "seperated by a semicolon" for multi-values.
Title: Tag-standards In Plugins<->formatting
Post by: Phil Meyer on 2009-01-03 10:02:54
Coming onto this discussion a little late...

I have been tagging for years using "ALBUMARTIST".  This is what SqueezeCenter uses, which I thought was the standard tag name to use for FLAC tags.  SC also accepts this as an id3v2.3 custom tag "TXXX ALBUMARTIST".

It seems strange that Foobar only supports "ALBUM ARTIST" and not "ALBUMARTIST", esp. as it appears to be the only tag with a space in the name.

Also, there are a few other apps that use compilation tags.  eg. iTunes stores this as a TCMP frame in id3v2.3 tags (which is a non-standard frame, but now widely adopted).  Other apps look for a tag called "COMPILATION".  Perhaps this should be included on the Encouraged Tag Standards wiki page?
Title: Tag-standards In Plugins<->formatting
Post by: q-stankovic on 2009-01-03 15:47:26
It seems strange that Foobar only supports "ALBUM ARTIST" and not "ALBUMARTIST", esp. as it appears to be the only tag with a space in the name.


It is not correct to say that foobar only support "Album Artist": You are free to use ALBUMARTIST instead of ALBUM ARTIST if you like to achieve compatibilty with other programs. The only that you will loose is the convenient field remapping (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Titleformat_Reference#Field_remappings) of the expression %album artist%, so that you will have to use an expression like $if2(%albumartist%,%artist%). Using a spacesign was just an agreement among foobarusers as result of a discussion.
Title: Tag-standards In Plugins<->formatting
Post by: Phil Meyer on 2009-08-11 23:24:38
It is not correct to say that foobar only support "Album Artist": You are free to use ALBUMARTIST instead of ALBUM ARTIST if you like to achieve compatibilty with other programs. The only that you will loose is the convenient field remapping (http://wiki.hydrogenaudio.org/index.php?title=Foobar2000:Titleformat_Reference#Field_remappings) of the expression %album artist%, so that you will have to use an expression like $if2(%albumartist%,%artist%). Using a spacesign was just an agreement among foobarusers as result of a discussion.


Yeah, I understand that.  The Foobar2000 built-in support for %album artist% is convenient for many things, so adding logic for %albumartist% otherwise %artist% is a pain.

I got a change made to the other software package to support "ALBUM ARTIST" instead (as well as ALBUMARTIST), so I use that now - just thought it was weird to agree a tag name that had a space in it, when everything else doesn't.
Title: Tag-standards In Plugins<->formatting
Post by: LosMintos on 2009-08-20 16:05:50
It seems there is a quasi standard on %added% as a tag-field containing a time stamp, when the file was added to the database/repository. Is this true? Shouldn't it be added in the first post in this thread? Or is there any other standard or no standard at all regarding this issue?

Or what about a field %date added% to keep the date/time, when the track was added to a library?

However, the format should be ISO, yyyy-mm-dd, yyyy-mm-dd hh:mm, or yyyy-mm-dd hh:mm:ss, depending in the user's needs.

What do You think? What's Your practice?