Hey all. I’m experiencing some weirdness with files that have already been tagged with MBP. I want to go over my library of music that’s already been tagged to update any files if necessary, but I’m running into 2 major issues.
When adding the entire folder (~1800 songs), MBP crawls to essentially a halt and eventually the program gets hung up and becomes not responsive at all.
A LOT of the files are not being recognized as having been previously tagged and are being grouped under “[non-album tracks]”. Most of the library was tagged with I believe MBP 2.2.3. I’m now running MBP 2.3.1 on a practically brand new Windows 10 install (I’ve tried to keep the system as clean as I can), but many tags look corrupted.
I’ve included some pictures to help illustrate the second issue more clearly.
Not an ideal place to start - 1800 songs will always make MBP struggle.
Some of the “corrupted” files. I notice MBID changes in your first images. Check out the edit history of those releases to see if those releases have been changed in the database as sometimes MBIDs do change after a merge…
Is this the same PC as you have MBP 2.2.3 on it? Was that just an install on top upgrade? (i.e. keeping all the same settings are previous)
I can always do smaller batches if 1,800 songs is too many to do at once as a work-around.
I can check for the edit history, but out of the 1,800 songs, about 1,000 to 1,100 come up as [non-album tracks] now and I can’t imagine there were that many merges.
It’s a totally different computer, but fresh install.
Aha! Then settings have changed. Do you still have the old PC? Can you get at the old settings folder? C:\Users\JusticeMB\AppData\Remote\MusicBrainz\ There is a picard.ini in there that can be copied to the new PC to maintain the settings.
That [non album tracks] is what makes me think something is configured different. Also having 1100/1800 coming up as different says to me this is a specific setting that needs copying around.
It sounds like you are handling some tracks different now. if you can find that settings folder then you can copy over the old settings to the new PC and this should run more like before.
Okay… now I am out of my depth with ideas. Can’t harm trying the same older version of Picard, but don’t think that would be enough of a change.
The tracks showing changes to the MBIDs make sense as these could just have been changed in the database since your last check. Easy to confirm with a check of an edit history on one of those.
It is all those becoming [non album tracks] that were previously album tracks are puzzling me the most. Almost as if a rule\setting had changed.
Drag 'em all back over to the left, cluster them, and lookup fresh.
As said previously, do smaller batches of files at once - and back up your files first! Inadvertently hitting save on those non-album tracks, for instance, would have done a number on your collection : O
OK, so I used Geek Uninstaller to completely uninstall and remove any traces of Picard 2.3.1 before fresh installing 2.1.3. Loaded up the old .ini file and tested it out - still the same issue. So, must not be the older version.
Used Geek to uninstall 2.1.3 to fresh install 2.3.1 and see if maybe the 2.3.1 installation was corrupted. Did another fresh install and changed ZERO settings and loaded the same test batch… same problem persists, so I just put my old 2.3.1 .ini file back.
Then I tried doing what @aerozol suggested. Lo-and-behold, when I re-cluster them and lookup/scan again, it gets grouped properly!
Seems like every tag is importing correctly except for some songs that have the AcoustID tag.
So, it would appear that I need to check the option to ignore all MBIDs when loading new files and everything seems to be good again. Very weird and I’m still not sure what the cause is/was.
Side thought: I have a feeling this might also help with the slowness/freezing when adding a lot of previously tagged files with MBIDs, but we’ll see if that holds true.
In general, your corrupted tags remind me a lot of the ticket https://tickets.metabrainz.org/browse/PICARD-933. The solution there was to turn “off Windows Media Player updating metadata in the background” (I do not now how to do this). Maybe try that and see if it helps?
I have never even initialized WMP and I don’t know how to do this either. Anybody know where else this setting might be? Do I need to “turn on” WMP to turn this setting off?
Hang on - your tags in that last image are mad. Is that text on the left for real? Does it show like that in MP3TAG? Somehow you have the tag LABELS filled in instead of the tag VALUES!
It should not say “coustID id” in that box, it should be a long number. So when it comes to the Musicbrainz Release ID that corruption in there is causing the [non-album track] flag to appear.
Sorry, I didn’t look at all the examples last night. Those later examples are plain corrupted files.
That is plain corruption of the SOURCE files by something else. Picard is misreading the tags some how.
The WMP sounds like a slight misdirection, but very relevant. There are many Windows users here not hitting this issue as standard. And if you have just moved to a new machine, then Win10 doesn’t use Windows Media Player anymore. You’d have to do some weird digging and changing of settings to re-enable that old tool. There is no “auto-update tags” enabled by default.
Maybe this happened on the older PC? This is certainly a wider point to check - is there anything else messing with the files? re-writing tags? What other music players have seen these files?
Do you have any of these still on the old PC you can go back and pick up again? An older backup?
Can you put one of those files with weird tags up onto a share site like WeTransfer for someone else to have a look at? Some of us can confirm what we see on a different machine. And @outsidecontext may find them interesting.
At least install MP3TAG (mp3tag.de) or some other tag reader to see what is in those tags. If they really do have the mess like shown on the left hand side of your example photos, then there is no “bug” in Picard and you have got corrupted tags that will need repair
I downloaded Mp3tag to check and yes, the extended tags show up exactly like that.
In terms of auditing where the files have been, most, if not all files that show with corrupt tags originated on my old laptop running Windows 7. According to my old .ini file, I must have used Picard 2.1.3 to tag mostly everything. I don’t believe I enabled WMP on my laptop as well. I had Mp3tag also installed on the old computer to tag files that Picard didn’t handle well. My primary music player was PotPlayer. I’ve had the new computer running Windows 10 for a few months now and as I said haven’t run/initialized WMP at all. I was using PotPlayer again, but decided to make the switch to foobar2000.
I took the SSD out of the old computer and put it in the new computer in case I needed to access older files. When I started all of this, I actually checked to see if the backup files would have shown the same corruption and it did. Here’s some examples:
I might have even older backups located in a Veeam file somewhere, but it’s not as easily accessible.
FWIW, I’ve been spending hours yesterday and today updating all the files previously tagged by Picard. I only have a handful of files left, so will only have the corrupted version of the files from the old computer.
In that case, the bad news is the files are permanently damaged by something. Something has been “updating the tags” for you and has written corrupted data.
The WMP setting would involve digging to enable it. There is an option to “Update music files by retrieving media information from the internet”. Don’t think it is enable by default and would need to be turned on. Even less likely on Win10 as it is not used any more. WMP was always a bit ropey. (But not as bad as Groove).
Good to hear your have progressed well through re-tagging. This time back them all up straight away on a USB and stash it away.
