Backround: On November 7th I ripped my entire CD collection to .FLAC with Exacy Audio Copy (0.99pb5), and tagged the files with mp3tag (2.46a). Days after I discovered I had a faulty cable that became faulty on or around November 7th. I then replaced the cable and backed up all my files to a spare hard drive, and reformatted the main hard drive (computer was running slow and I was looking for an excuse to reformat anyways). Then I started to wonder if this hardware problem might have occurred prior to my ripping and if so, that it may have caused corruption in the music files as they were written to the hard drive.
So, I reinstalled the newest version of mp3tag (2.47a) and the same version of EAC (0.99pb5). I am pretty damn certain I modified the settings of both programs upon install to be the exact same settings as I had pre-format. I then re-ripped random cds and retagged the .flac files as I did before, and used a program valled FileVerifier++ to batchcheck the the mp5 hash of the files. In most cases the md5 hash value of the files I had just ripped did not match the md5 hash values of the files I had ripped on Nov7th. I then used mp3tag's built-in %md5audio% check, and it always came back a perfect match. Therefore, the audio portion of the files are identical, and the inconsistancy must be in the header of the file.
I then used a program called WinMerge to compare the files, and I noticed the tags (title,album,etc.) were not written in the same order. That is to say, in all of the files I had ripped on nov7th (as well as pretty much every song I'd ever tagged prior to the reformat) the data in the header went as follows (FLAC LIBRARY REFERENCE VERSION -> TITLE -> ALBUM -> ARTIST -> GENRE -> DATE -> TRACKNUMBER), and in my newly ripped/tagged files it went (FLAC LIBRARY REFERENCE VERSION -> ALBUM -> ARTIST -> GENRE -> TITLE -> DATE -> TRACKNUMBER). So I thought maybe this was a new bug in 2.47a so I upgraded to 2.47b. Same result. So I then downgraded to the same version I originally used on nov 7th (2.46a). Same result. So, as a result of the way mp3tag is now writing the header, I cannot easily and quickly throw the entire music directory into fileverifier++ and compare hash values as they will not match in most cases, and as such are no longer a reliable comparison. And for future taggings, it will now tag files with what I consider an inferior tagging order. It just seems more logical for the tags to be written the way they were being written before (most important tags -> least important).
I've been trying to wrap my head around this for many, many, hours... with no progress. I don't know why things changed, but if anyone has any idea on how to fix mp3tag so that it writes the header the same way it did before I reformatted, please share.