An interesting problem. I have often been annoyed at not being able to see exactly what tags are stored in a file, and what the tag name is, when managing my library. A tool that allow that sort of raw viewing of tag data would make solving this sort of problem a lot easier.
Some of the testing 2MR2 did, and possibly some of yours, would be invalid. This question is a lead in to one of the reasons why.
Is it possible MC has seen these files before you made the tag edits externally?
But there is a second reason that this question is important.
I see you said MC hasn't seen the files before, but are you aware that MC stores tag information for any file that it has seen (imported) before, and restores that information to the library when it sees (imports) the files again? So even if MC has never seen these
specific files before, I suspect that if it has seen files named the same that are stored in the same directory, or actually maybe just have a few tags in common such as Album, Artist, Name (not sure which), then MC is reusing the tags it knew about before.
To check if MC thinks it has seen a file previously, set up a View or Smartlist that is not restricted to any Media Type (including via the parent scheme rules if using a View) and has a Modify Results rule "Limit database to" set to "Removed". Have a look through that list and see if you can find the problem files
after importing, but before you delete them from MC. If you find one of the files, add the [Album Artist] field to the view and see if the bad content is listed in there. Note that you won't be able to use the tag Action Window with these deleted files.
My other question is; when you looked at the files using Media Info after you had deleted the [Album Artist] tag using Yates, did you see an additional tag called "Album Performer"?
A few of my example files did have this additional field, which was called "Album_Performer" in the Media Info XML view, and "Album/Performer" in the Text, HTML, and Tree views. The normal field was called "Album_Artist" in the XML view and "Album Artist" in the other views. The data in each was the same, but then the files had been updated by MC, so I guess that isn't surprising. If I updated the [Album Artist] tag in MC, both fields were updated in Media Info. I'm assuming that these represent two different tags in the file, rather than just two ways of displaying the same tag. Note that my test files were MP3s.
I am thinking perhaps that because there are two fields, perhaps Yates deletes the "Album_Artist" tag but leaves the "Album_Performer" tag alone. Then MC looks for both versions, finds data in the "Album_Performer" tag, and imports it into the MC [Album Artist] tag.
So there are two possibilities:
1. The files, or some files that are identified as being the same as the new files you are importing, have been seen by MC and their information is stored in the "Removed" database, only to be resurrected when these new files are imported.
2. Yates is only deleting one of the tags that can hold Album Artist data and not the other, while MC looks for both and imports data when it is found, even if the other tag is empty. So checking if the aART tag (or the correct tag name for ALAC files) is empty in Yates isn't sufficient. As converting your problem ALAC files to FLAC files and back again clears the problem, I think this is the more likely scenario, as writing a completely new FLAC the ALAC file would write only the tags appropriate to that format.
Googling "Album_Artist" and "Album_Performer" would support the case for the second scenario. In fact Googling '"Album_Artist" "Album_Performer"' shows that Roon is having similar issues. though there are some hints that the FLAC format supports both tags separately.
Author
Topic: JRiver adding Album Artist from who knows where on import (Read 4878 times)