Skip to main content

Notice

Please note that most of the software linked on this forum is likely to be safe to use. If you are unsure, feel free to ask in the relevant topics, or send a private message to an administrator or moderator. To help curb the problems of false positives, or in the event that you do find actual malware, you can contribute through the article linked here.
Topic: Tag-standards In Plugins<->formatting (Read 170815 times) previous topic - next topic
chap89 and 1 Guest are viewing this topic.

Tag-standards In Plugins<->formatting

Reply #100
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)?

Tag-standards In Plugins<->formatting

Reply #101
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.

Tag-standards In Plugins<->formatting

Reply #102
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.
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #103
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
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #104
(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).

Tag-standards In Plugins<->formatting

Reply #105
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
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #106
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  ).

Tag-standards In Plugins<->formatting

Reply #107
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?"

Tag-standards In Plugins<->formatting

Reply #108
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.

Tag-standards In Plugins<->formatting

Reply #109
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.

Tag-standards In Plugins<->formatting

Reply #110
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

Tag-standards In Plugins<->formatting

Reply #111
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.)

Tag-standards In Plugins<->formatting

Reply #112
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.
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #113
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
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #114
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.

Tag-standards In Plugins<->formatting

Reply #115
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.

Tag-standards In Plugins<->formatting

Reply #116
Quote
(or whats the point in having standards at all).

IMHO, avoiding ambiguity and incompatibility.

- Lyx
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #117
And what about consistancy?

Tag-standards In Plugins<->formatting

Reply #118
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
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #119
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).

Tag-standards In Plugins<->formatting

Reply #120
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.

Tag-standards In Plugins<->formatting

Reply #121
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
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #122
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.

Tag-standards In Plugins<->formatting

Reply #123
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
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

Reply #124
I still think for consistancy's sake, it should be one way or the other.  280+ people are quite capable of changing again.