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 170341 times) previous topic - next topic
0 Members and 2 Guests are viewing this topic.

Tag-standards In Plugins<->formatting

Reply #475 –
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.

Tag-standards In Plugins<->formatting

Reply #476 –
Hello everybody,

First of all, please read this small topic for information : http://www.hydrogenaudio.org/forums/index....showtopic=61383

This being said, here are my thoughts :

Quote from: Lyx on
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 :
  • name is consistent with other tagfields (ARTIST, ALBUM, GENRE, SUBGENRE)
    (it is even more logical than style : after all, what could be more natural than genre / subgenre ?)

    Disadvantages : none to my knowledge

    Hope it helps, who knows. 

Tag-standards In Plugins<->formatting

Reply #478 –
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?

Tag-standards In Plugins<->formatting

Reply #479 –
Quote from: Phil Meyer on
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 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.

Tag-standards In Plugins<->formatting

Reply #480 –
Quote from: q-stankovic on
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 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.

Tag-standards In Plugins<->formatting

Reply #481 –
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?