Change field mapping of some files so use same value for all formats

[IJabz]

Previously when added new fields followed naming conventions of existing tabs as follows ID3:MixedCase words seperated by spaces Asf:Starts 'WM/' then MixedCase words seperated by spaces Vorbis:UPPERCASE words seperated by hyphens MP4:Sometimes like ID3 and sometimes like Vorbis

https://docs.google.com/spreadsheets/d/1afugW3R1FRDN-mwt5SQLY4R7aLAu3RqzjN3pR1497Ok/edit?usp=sharing but experience with dbpoweramp where it takes TXXX fields as is and convert to FLAC field without modification has made me think better to use same value for new fields across formats. I've done this for these fields except Asf tags are preceded with WM/ (which again is only a convention)

ARTISTS_SORT ALBUM_ARTISTS ALBUM_ARTISTS_SORT CLASSICAL_NICKNAME

This would greatly increase the chances of metadata being preserved when music is converted to a different format, and now it is much more common for users to have multiple copies of their music collections in different formats and it would be better for them if they didn't have to retag.

I'm also thinking that perhaps the earliest fields were added to ID3 before VorbisComments existed so it wasn't really considered that VORBIS is meant to be caseinsensitive

I may also modify the settings of some fields already added, on the basis only currenlty used by myself in the Jaikoz and Songkong taggers.

[Dan Gravell]

The Google sheets link is dead?

I'm not sure I 100% understand... are you suggesting, for example, not following the standard ID3 frame IDs? I think that would be a mistake.

Or are these new and not currently prescribed fields/frames?

[IJabz]

Linked fixed, no I im not talking about standard ID3 frames. Im talking about when you need store metadata that doesnt have its own dedicated standard frame in ID3 you usually use a TXXX frame with a name:description pair. Im saying Its make sense to use the same value for 'name' in ID3 as we do for the field name in VorbisComments and Mp4 reverse dns atoms

[Dan Gravell]

That makes sense! This isn't something I've dealt with much, so my opinion might be of limited use. The only thing I would say is to look at other players to see how well they would handle it, e.g. what does JRiver do? A lot of people use that for conversions.

[Hendrik Schreiber]

I also agree. Having one spelling across the board may increase usability. At the same time, it may make sense to create code that reads the old spelling (if there is one) when it cannot read the new spelling. I.e. be lenient when reading and strict when writing.

[IJabz]

Hendrik, related to this is question you had about MoodNaming - please remind me where you are with this at what the issue was

Anyone got a view about use of 'WM/' in Wma files ?

[Dan Gravell]

I've not used WMP for custom fields, does it support them ok?

[Hendrik Schreiber]

Anyone got a view about use of 'WM/' in Wma files ?

Not really.

Hendrik, related to this is question you had about MoodNaming - please remind me where you are with this at what the issue was

Do you mean this discussion:

I've noticed that you named it “MOOD_DANCEBILITY” and was a little surprised as it has little to do with mood. Even AcousticBrainz does not categorize it as mood.

Any chance you accidentally named it that way, because some of the other high-level AcousticBrainz descriptors have “mood_”-prefixes (even though I don’t understand why)?

Any chance we can still turn that into simple “DANCEBILITY”?

[IJabz]

Yeah, your right it should just be DANCEABILITY thats a bug with just Vorbis/Flac

[IJabz]

Actually regarding DANCEABILITY no I have MOOD_DANCEABILITY across all formats. Looking at the json returned by acousticbrainz it does indeed just call danceability but it also has mood_party, why is mood_party mood related an danceability not ?

It also has mood_acoustic rather than just acoustic, not clear if there is reasoning behind these names in acousticbrainz and feeling that perhaps I would like to prepend all these fields fro ACOUSTICBRAINZ as MOOD_ to give some indication that they all come from the same source, although they dont have to, without tieing explicitly to AcousticBrainz ?

[Hendrik Schreiber]

Tagging aside: I have evaluated both acoustic and electronic and came to the conclusion that the used models are rather poor and need some work. Try for example to get the values for Jack Johnson. According to the current AcousticBrainz models, his work is mostly electronic and rarely acoustic, which is completely false. Dmitry Bogdanov and Alastair Porter from UPF/AcousticBrainz are aware of this.

I assume the mood_ label in AcousticBrainz is purely historic. Somebody at some point started using that prefix for whatever reason... Also, when it comes to Danceability, realize that AcousticBrainz delivers two values: One based directly on acoustic features and one based on a learned model. I have no idea which one is better.

IMHO, acoustic, electronic and danceability are not moods and therefore shouldn't be marked as such.

[IJabz]

I agree that many of the models are not as good as would like, but things can only get better Regarding Danceability, I saw one value is in the lowlevel data and one in the highlevel data, I assumed highlevel is the learned mode ? But what is a mood, i.e I am in the mood for something dancy I wlll play something with a high daneceability, how is that different to i am in a sad mood I want to play something sad to wallow (or happy to cheer me up). What I want to do is to group all these values so sort of clear similar measurements i.e (all percentage ranges), now one way would be to call them ACOUSTICBRAINZ_HAPPY ectera but I dont want to tie to a provider since if we have better implementation could use that to store happy mood, so I have to tell you Im veering towards all these fields being prefixed MOOD_. Of course how you present such data to end user is upto you.

[Hendrik Schreiber]

I agree that many of the models are not as good as would like, but things can only get better

I'm sure they will.

but I dont want to tie to a provider since if we have better implementation could use that to store happy mood,

Agreed.

so I have to tell you Im veering towards all these fields being prefixed MOOD_. Of course how you present such data to end user is upto you.

Frankly, I have my opinion about that MOOD_ prefix, I voiced it, but in the end I can very well live with it.

[IJabz]

okay, thanks working on it now

[IJabz]

Done