Mood was the only problematic tag, because TMOO is part of ID3v2.4 standard and should be handled preferentially (implemented from the next beta build). For Encoded by we use standard ID3 field, other MusicMatch tags (MusicMatch_Tempo, MusicMatch_Situation, MusicMatch_Preference) do not have standard ID3 alternatives, so we use our own custom XXX tags (and MusicMatch tags are still preferred). This should not be problem.
"WriteMusicMatchTags" setting only causes, that MM4 will not write any MusicMatch tags any more. They are read, but deleted during saving.

BRILLIANT!!!

I hope your suggestion works. I'm sure I won't test the tip till I have enough time to carefully ensure doing so DOESN'T BREAK DOWN OTHER TAGS THAT WERE PREVIOUSLY WORKING. At this point the MOOD tag has been my only meltdown, so I have no knowledge of where else MusicMatch tags show up. Any insight?
I found an old thread [url]http://www.mediamonkey.com/forum/viewtopic.php?t=2015[/url] that suggests these may be fields with potential MusicMatch conflicts:

Mood
Tempo
Occasion
Encoded By

Even if your tip works, for JAIKOZ compatibility, I will still have to go back to the JAIKOZ author (again!) and urge him to use TMOO in 3.23 (Which he has said is NOT correct - but why "XXX Mood", which he uses, is correct seems subjective).

The mood tag certainly makes me moody.

WriteMusicMatchTags=0

Hi, you're right. MusicMatch tags are preferred during tag reading from the very beginning. It probably needs to be changed, I think, standard tags should be preferred.
Meanwhile you can forbid writing of MusicMatch tags - backup and edit MediaMonkey.ini file, find section "[Options]" and add this line there:
[code]WriteMusicMatchTags=0[/code]

Thanks.

Seriously, Jaikoz is to tags what Mediamonkey is to music listening - not perfect but REAAAAAL close. Mood tag is the enemy here.

I don't use other tag editors, so I can't confirm, but I added: http://www.ventismedia.com/mantis/view.php?id=12185

Well, let me put it this way:

Take a file with TMOO into Mediamonkey and write to it (generating MusicMatch_Mood) or use a file with both already
MOOD = PIG

Open the fie in hex editor, [u]change TMOO = "DOG"[/u], leave MusicMatch_Mood tag alone


Main window/properties box after rescan file into MM:
MOOD = PIG

MM reads, even writes to TMOO, yes, but it is displaying and paying attention to MusicMatch_Mood!

http://www.ventismedia.com/mantis/view.php?id=2953 indicates TMOO is written.

I think I know whats going on.

In ID3 v3.23, NEITHER Jaikoz NOR Mediamonkey are using TMOO!

Mediamonkey, however, has been coded to interpret TMOO and translate it to "XXX MusicMatch_Mood". But only INITIALLY!

Jaikoz is using "XXX MOOD"
and Mediamonkey is [u]USING [/u]"XXX MusicMatch_Mood"!!!

Any outside changes require rescanning (File > Add/Rescan Files).

Mediamonkey seems to only read TMOO in order to create the MusicMatch tag, then no longer pays any attention to external changes to TMOO. That doesn't seem quite right.

I'd like to see the "DisableFrames" in the INI file permit the shutdown of MusicMatch_Mood. I mean, its a little ironic that a queer tag is being inserted to generate 'compatibility' when all it does is for me is wickedly collapse compatibility. What programs read only MusicMatch tags?

Even Music Match probably uses TMOO at this point.

I'd presume that TMOO is the first used tag and that the Musicmatch tags is only written for compatibility. Are you saying it doesn't work like that?

OK, right after harassing the author of JAIKOZ to make my world work by using TMOO for v3.23, it dawned on me there might be more headaches ahead...naturally.

Is THIS a 'bug'?
Once Mediamonkey alters a tag, any TMOO tag gets expressed in the "XXX MusicMatch_Mood" format as well.

Once the unrequested MusicMatch version shows up, Jaikoz (or a hex editor or anything) can alter TMOO all day long - Mediamonkey will ONLY care about the OLD MusicMatch tag.


So even if JAIKOZ implements TMOO for v3.23, Mediamonkey [u]won't care[/u], and will only look for its lil' pet version of the tag - which I suppose is fine if one makes a new year's resolution to[i] never alter the MOOD tag except in Mediamonkey.[/i]

It IS comforting, that no matter what frustrations, what confusions, or what limitations the ID3 tag realm has -

that I will henceforth always have a home for my images of bright coloured fishes. I do wonder, will we EVER get a tag for the unappreciated DULL, colorless fish of the world???

ALSO, as the [u]spelling [/u]of the word "coloured" seems perhaps British, is it improper usage of the tag to embed pictures of Asian fish, for example?

Seems to be used here too: http://en.wikipedia.org/wiki/ID3

Looking around I see every resource referring to TMOO as the Mood tag for ID3.

Thanks!! I obviously had not found the capability of reordering the moodtag checkboxes.

As far as any documentation per legitimacy, that makes it sound like an academic matter, where I'm not sure but the tag realm is more like a battlefield. I don't get the "XXX mood" bit either, but I really didn't want to tell the author of JAIKOZ how he should handle it, as he is all but a hero to me for bringing as much sanity and power to tagging as he has.

I did exchange with him about this and will make another effort to push for TMOO.

I MUST add, the very next webpage I looked at after initially reading your responses was www.mediamonkey.com/wiki/index.php/Scripting_Resources
as I was going to get back to you after doing some probing for technique to merge embeded album art...Immediately I'm looking at this:

"Cover Types
Known as CoverType field in the Covers database table.
Known as ItemType property of the ISDBAlbumArtItem interface.
These are the cover type values used by MediaMonkey, [u]as defined by the ID3v2.4 specification[/u]:
ID ----Official ID3 Description --------- MediaMonkey Description
..
16 ---Movie/video screen capture ----Video Screen Capture
17 ----A bright coloured fish ----------- Not specified "

"A bright coloured fish "...Should that make sense?
Most of the time, I'm really not sure I know what is going on.