User-defined Hierarchical & Multiple Genres - Ideas

I am tagging music files for use with the (free) RadioDJ playout app (for Windows, which I run inside a Parallels VM on a Macbook). It allows filtering of music by things like Genre. The filtering is semi-programmable in terms of string search/match in SQL, that the RadioDJ app supports, based on an Imported-media library (pointing to media files) in MariaDB (a better version of MySQL).

Unsatisfied with the inherited (e.g. ID3v1 + Winamp) default genres (whose history I only today learnt of), I am considering adding my own ones. I understand from other threads that here in ID3v2 we are free to make any Genre text-tags we like, even combine multiple ones, there are no standards other than (the differing) requirements of proprietary apps (e.g. media players). So we can in principle create whatever "chaos" we like, in the ID3 metadata of the files of our music libraries.

Idea #1: Hierarchical Genre-Subgenre representations, as single text-tag-values, e.g. "rock-hard", "rock-gentle", i.e. noun-adjective as in much of French language. That way alphabetically sorts all the "rock" options together. Also when you enter a prefix (e.g. "rock") then any autocomplete (as found in many apps) will present any existing suffixes (e.g. "hard", "gentle").

Idea #2: Multiple genres, combined, e.g. folk+rock for peer-genre fusions.

Could even combine the two ideas, e.g. "folk-gentle+rock-hard" (e.g. by entering in Genre field, via Mp3tag, as "folk-gentle\rock-hard", i.e. two values delimited by Nul character - explaining that here because I only just understood it, sharing for others). As would be (debatably) appropriate for "Crazy On You" by Heart.

Is anyone thinking or doing anything like this with Genres?

Maybe I will make an EspGenre field, put the (potentially) multiple values in there, then have some separate program "flatten" all instances of multiple values into single-values, being strings composed of the individual values (in a multiple-value set) sorted into alphabetical order and joined by the "+" character.
Example: EspGenre:[Rock\Folk] would create Genre:[Folk+Rock]

Advantage of flattening: more chance of being recognised by various apps. I think RadioDJ would recognise these. Of course I'll have to experiment!

Even though you can have more or less any string, I wonder whether such a structure would really lead to an easier access as with the traditional player something like

would appear under "F" for Folk - if I look for "Rock" would this track also appear?
If so (which is: your player has better search functions), fine - but then you would not need to sort the data inside the field.
Also, I would assume that sometimes it is important to have a certain order in the genres to show that e.g. something is more Jazz than Rock or more Rock than Jazz...

But in general with ID3V2 you are free to invent more or less any genre name you like. In any language.

1 Like

Regarding Idea #1:

It seems to me like a Genre and Style representation. As an example, Discogs distinguishes between Genre Classical and Style Neo-Classical for Nils Frahm's latest release.

Personally, I always found it a little difficult to describe an album in such detail, because then sometimes also the different tracks differ in style. But I can imagine the information to be quite useful, especially for DJs. Here is a discussion on Genre vs. Style

Regarding Idea #2:

I think having one field with the individual values not composed in a dedicated string is most flexible. You can use $metasep(field,+) to create a composed string of the genres stored in field and use this, e.g., with a Format value/Format tag field action to copy it to a different field.

The composed string has always the benefit of being recognized by apps that don't support displaying or searching in multi-value fields.

Sorting the individual values is currently not possible. I'm thinking about extending metasep to support this, but it's a very special use case.

1 Like

Thank, you, a helpful answer.

I would reverse the order, as in French, to be [Rock-Folk] to mean Rock is primary and Folk is secondary. Then string-search for anything starting with "[Rock" would match the Rock genre and all its subgenres. Also it would work (in useful fashion) with autocomplete.

I guess this syntax/search scheme could be elaborated, to find (next) term between "[" and any-of("]", "-", "+"). Of course allowing also for more than two terms. Then we could also use [Folk+Rock] == [Rock+Folk], i.e. order doesn't matter (set not sequence).

But (reading ahead to the next reply), before becoming too settled, I see that in some contexts, there is a Style property that can be used together with Genre property.

I do not think that the combinations by themselves or their order are a problem. Here, I think, you have all the liberties already.
The problem will be: what do the players make of it?
So any suggestion for MP3tag for a more elaborate naming scheme will probably be in vain as the players' functions don't follow suit.

1 Like

Thank you for that input. I will indeed check out Style.

I am confused when you say "...having one field with the individual values not composed in a dedicated string is most flexible.". Was the "not" unintentional? I wonder because your example etc, does indeed compose such a string. Or maybe I am reading it wrongly?

Wikipedia re ID3, says re ID3v2.4: "a text frame can contain multiple values, separated with a [null byte]". If I interpret you correctly, you are advising against using this, instead putting only a single "compound genre string" in the Genre field, incorporating its own printable delimiter-character(s).

I am not (yet) familiar with metasep (etc.) coding, or whereabouts (in Mp3Tag) to do it. I imagine/guess your example means "for all (possibly multiple) occurrences of the given field (as identified by name), derive a single field in which all the values of those original fields are concatenated with delimiter="+".

Assuming that's right, is the "+" character some kind of generally preferred or de facto standard delimiter e.g. that certain (e.g. some major) media players will recognise (in some fashion (e.g. usefully or at least not-crash)? I have also seen people referring to ";" and "; " as multi-value field delimiters - presumably likewise in single compound strings, though in many cases people confuse what their preferred/habitual tag-editing app displays with how the delimiter is actually represented in the in-field data. I further notice that one well-known bulk-tagging app offers the comma-space ", " and space-forwardslash-space " / ") strings as default choices of delimiter.

Any advice on which kind of compound-string element-delimiter is best?

Apologies for any inappropriate or imprecise terminology - I am new to this.

Perhaps you find more information on delimiters/separators in this thread:

(Spoiler: the + isn't used anywhere - that is considered plain text)

The "not" was intentional. What I meant is that you can just build a composed string from the individual values using any delimiter you like and even change it easily when you discover any issue — this is flexibility.

1 Like

I am not making any suggestions (here) for any changes to Mp3tag, merely seeking a reasonably orderly system within those liberties. I have seen several other threads where passions have arisen over that subject, but I am one of those awkward people that "thinks differently".

Oops I forgot to double-up the "\" pairs. I meant "\\" of course.

@ohrenkino @Florian

One possible scheme emerging in my head is to establish a central "foundation" set of files having reasonably objective canonical but not necessarily app-compatible metadata (in ID3v2.4, as supported by Mp3tag). This metadata would hardly ever have to be changed.

Then convert those canonical metadata (e.g. via Mp3tag and/or SQL in the RadioDJ app's database) to a corresponding set of pragmatic metadata (existing either in corresponding copies of the files or else in corresponding entries in the mentioned database). In either case, the canonical data would be rearranged or transformed/interpreted for particular target purposes (possibly employing the compound-string format). Or to an entirely different value-space (set of possible genre names), as per the next paragraph. I don't yet fully appreciate what's possible in Mp3tag (I have so far only skimmed Mp3tag's scripting, expressions and conversion etc. capabilities), but I'll hopefully learn it over time.

In one example pragmatic scheme (that I have in mind), the Genre field would be re-purposed to correspond directly to the different types of program material/segments in radio program format clocks / "hot clocks" (broadly like the one here, about three quarters down the page). To make automatic/dynamic program scheduling easy to set up and change. For example, format-clock specialised genres such as "Hot Early 1970s Rock". Into that pragmatic genre, the inclusion or otherwise of specific types of rock sub-genre (e.g. progressive) and specific date (year) ranges would be determined by the conversion formula. Any issues, re-generate the pragmatic metadata but leave the canonical metadata files and the format clock alone.

If the same (canonical) library was thereafter aimed at a different radio station (or station theme) then a different conversion would be made, targeted to a pragmatic scheme appropriate to the specialised format clock requirements of that new target.

It would be good to have feedback (from anyone) on whether this scheme sounds reasonable, is standard practice or not, and whether the scripting/expressions/conversion features of Mp3tag could enable/support this kind of "metadata flow".

No, operating a radio station is definitely not standard practice but nevertheless a valid application.
For the scheme itself: I doubt that there will ever be a standard outside your specific radio station.
This does not mean that it is not possible to install such categories.
You could add more or less any number of user-defined field to the files (with MP3tag) with more or less any contents and you could then generate tag excerpts using the export function to get the tag field contents.
Still, it would be much better if the radio playing program could read the tags directly.
THis would make sure that you don't "forget" to update the radio database.

If you would look for

then you could, provided the corresponding tag fields have been filled, filter for
%gerne% IS Rock AND %year% HAS 197 AND %year% LESS 1975 AND %populatrimeter% HAS 255
and you could even include the BPMs somewhere.
Or you have a user-defined field like FORMATTYPE and filter for that
%formattype% HAS "Hot Early 1970s Rock"
provided someone has categorized tracks like that.

1 Like

Yes, RadioDJ's SQL feature allows for that kind of querying.
Even if there is no such "radio-type metadata" standard, it would be good to be as informed as possible before I create my own "in house" standard. So I am looking at the general subject area, high low and wide.

The query was one in MP3tag.
Like that it should be easy to then generate the corresponding export to get a list to your radio dj program.
Still: as there is a transfer required between the stored metadata in the files and the input to the radio player, it is completely up to you to define the keywords that allow you to get the best results in a query.

I also think that this is much more a problem of the local radio operator and how the data is managed over there. MP3tag wll probably help you once you found the operator's conventions.

1 Like

Thank you for resolving my misconception - I will indeed experiment with that in Mp3tag.