Yes, I saw those same errors when I dumped files into MP3Diag and after retagging, they went away. What I can't understand is how one day the files are file in MP3TAG and the next they're corrupt.
This particular file came from a promo website and because it's not in Discogs yet, I only updated the genre, then renamed it. I'll send you one where I used MP3TAG to add the discogs data but did not have a prior tagging.
Could part of this issue be how the Windows version only adds Discogs or Beatport data to the existing file, while replacing the album art, but the Mac version strips the existing tag before writing the new one? Years ago, I used to remove the existing tag before adding the new one, but I do tracks hundreds or sometimes thousands in a day, so I don't have the bandwidth to do the deeper searches without some ID3 data there.
Another question: Are the tags written to FLAC corrupted when converted with dbPoweramp?
I have a ton of FLACs that I previously tagged with Discogs data, then converted to MP3 for easier performance on older CDJs; the CDJs and Rekordbox can read the v2 data, but MP3Tag says both V1 and V2 tags are corrupt on those files.
We haven't gotten to the root cause, but it appears the v2 tag was corrupted with extra MPEG frames during on file retagged during a certain time frame.
Rather than wipe the v2 tag all together, @ confucius suggested using 'fre:ac' (https://www.freac.org/) to re-encode the existing mp3s to the same bitrate. Doing so cleaned up the extra frames and fixed the files. I'd suggest this method to anyone encountering bad v2 tags.
Warning: Re-encoding a lossy format music file to another lossy format of any kind will introduce further data loss, even if it is at the same rate. I wouldn't suggest this is the ideal way to fix any issues with the header.
Taking off that this is resolved. I updated a slew of tags that had the error and now those files are showing the exact same v2.3 error. This particular file was re-encoded with data from Discogs on 4 Feb.
I don't know what it showed before, because these were all files that I had retagged with MP3tag a few months ago. When I drop the files into mp3tag for the first time, they NEVER have any error message. I retag to either Discogs or Beatport tags, rename the file and then import into Rekordbox; there is no editing of the tags in Rekordbox.
What occurs is at some point, weeks later, mp3tag reports (and mp3diag confirms) the v2.3 tag is corrupt. I cannot understand how files are valid until mp3tag touches them, unless the act of importing them into Rekordbox corrupts the files. I'll pm you a file that's an issue.
Thank you for the file - but what would really be needed is an original file without problems and a copy of that which then shows the problems after it has been tagged with MP3tag.
What does this "updated" include.
Does "re-encoded" mean that you used an audio-software to rewrite the mp3-stream and after that used mp3tag with it's discogs-webscript to fetch tag-data?
Not sure how that's possible, since the issue arises weeks after retagged. I just scanned some new files and here's one before and after, but isn't throwing any error.
This supports my opinion that MP3tag still tags without corruption.
You would have to catch a file in the making that was OK before but isn't afterwards.
This would require that you check all the files before you start tagging.
Alright, so let's assume that. Only files that have been retagged with mp3tag have this issue; I have some mp3s that have been sitting for a year, waiting to be retagged and don't have this issue.
I'm going to test and see if Rekordbox is the issue (unlikely as it only reads the metadata), but what would cause a file to corrupt when it's not being edited after mp3tag touches it?
I just tested by changing the genre of a specific file and it looks like you're right, even though Pioneer/AlphaTheta claim changing data in RB only updates the RB database. Sounds like RB is wonking my tags. Awesome.
I think you can find that option here: Gear Icon (Settings) -> Advanced Tab ->Database section ->Write tag changes to ID3 file ->Enable or disable option
It doesn't look that option is in v6 or v7. All topics I've seen on the issue and replies from Pioneer seem to say it's a feature of the program and it can't be turned off, we can only stop writing the key to files. I'm wondering if the cue/beatmapping data is being written to the file and corrupting the v2.3.
@lyricslover examined the damaged file with exiftool and found a WXXX comment field with non-printable content, 2 more fields ID3_POP and ID3_TKE which look a lot like data from a DJ program or something similar - but most certainly not MP3tag.
I cannot answer this as it looks like something completely local that you have to investigate.
The only way out of it is a systematic approach that checks the files after each manipulation like @poster has described
