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 170973 times) previous topic - next topic
0 Members and 1 Guest are viewing this topic.

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

Reply #81
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]


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]

Tag-standards In Plugins<->formatting

Reply #82
@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" 

Tag-standards In Plugins<->formatting

Reply #83
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]


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]

Tag-standards In Plugins<->formatting

Reply #84
"Navigator" now supports LAST_PLAYED.
I am arrogant and I can afford it because I deliver.

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

Reply #86
Quote
Opinions?
[a href="index.php?act=findpost&pid=274551"][{POST_SNAPBACK}][/a]

Self-explanatory. Very nice 

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

Reply #96
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 guys).
f to c to f to c

Tag-standards In Plugins<->formatting

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

Tag-standards In Plugins<->formatting

Reply #98
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.
I felt weak, perhaps I was.

Tag-standards In Plugins<->formatting

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