This has come up before, but not like I'm experiencing it.
I only use MP3tag for files, so everything in my drives were tagged from Discogs through this program. Today, I found that every single one of my 100,000+ files are showing the "ERROR ID3V2.3 header parse error(ID3v1 id3v2.3) ERROR BAD MP3" and the only way to fix it is to run the tags again. Something happened with the program from yesterday to today and I'm not sure what it is.
As others have said in the past, Windows and Rekordbox show the tag as valid, but MP3Tag does not. I'm on v3.28 Windows, if that helps.
**Going through my files, it looks like there are only a certain group of files affected from maybe December 2024, around the time I would have updated to 3.28. Was this an issue with 3.28 that 3.28b has resolved?
but that actually the source may be problematic.
It could be that the embedded picture - which does not show in MP3tag - has been embedded with an invalid pointer encoding.
Mp3tag only shows 5 tags with content (ALBUM, ARTIST, GENRE, TITLE, YEAR) for this example track.
The screenshot from dbPoweramp shows many more like TRACK, ALBUMARTISTSORT, CATALOG, COUNTRY...
I don't know if dbPoweramp read this values as embedded values directly from the track or from another source?
No, it does not. I didn't know that version was out until it was posted here.
It can't be the embedded picture, because as I said, any file I coded before November-ish (I can't pin down a date based on the files), the exact same way with Discogs data, is fine. The only variable remaining is an update to MP3Tag.
In any event, if I reprocess the files, MP3 Diags reports the tag are valid. So I've just got a long few days of retagging 1,000 files.
As I said, the only variable remaining is the software used to retag the files. FLACs are fine, MP3s are not and these are files I've already used MP3Tag to 'clean up' from the stores and promo sites, meaning they were 'good' until the other day when MP3Tag reported they were not.
Once I retag the files with 3.28b, MP3 Diag reports the error is resolved, so yes, I'm going to retag and go on with my day. I can't keep corrupted data in these files, since they're used often.
I believe the tag was corrected, but I updated to 'b' before I started looking deeper and updating tags, so I'm not certain. I don't believe in coincidence and in all my years using the program, this has never happened, hence posting the issue and series of events here.
II have now tested this based on the assumption that a problem embedding a cover is the cause.
I embedded an oversized 93MB PNG cover.
The error message immediately appeared: Error: ID3v2 tag parse error ID3v1 (ID3v1 !BAD ID3v2)
in my corresponding tag column with the value %_tag_read%[ (%_tag%)].
This message says that there is a problem with the ID3v2 tag and therefore only the ID3v1 tag is read. By the way, the cover is not displayed. A simple re-save repairs the tag simply because only the ID3v1 tag is read and then only its contents are saved. After saving, all originally additional ID3v2 tag content is missing except for that contained in the ID3v1 tag.
This process happens regardless of whether version 3.28 or 3.28b is used.
Except the covers in these corrupt tags are exactly the same size as tens of thousands of files already in my collection, which I've spot checked and found no issue. Everything in my files has covert art from either A- from Discogs or B- from Beatport, and none of them are larger than 200k. Most average around 75k. My issue is not related to cover art.
I've also tested the 'save' action in3.28b, but that only cleans up the file, it doesn't resolve the matter or 'fix' the corrupted data without retagging.
I loaded your file into mp3tag and I see your problem.
All I did was hit save and it was repaired as far as the tags go. So load them all and just hit save. Job done.
But....
It still needs fixing as when I run it through mp3val I get ....
Analyzing file "E:\00. Abnormal Load - Goddess EP - Hekate.mp3"...
WARNING: "E:\00. Abnormal Load - Goddess EP - Hekate.mp3" (offset 0x115e): MPEG stream error, resynchronized successfully
WARNING: "E:\00. Abnormal Load - Goddess EP - Hekate.mp3": VBR detected, but no VBR header is present. Seeking may not work properly.
WARNING: "E:\00. Abnormal Load - Goddess EP - Hekate.mp3": Non-layer-III frame encountered. See related INFO message for details.
WARNING: "E:\00. Abnormal Load - Goddess EP - Hekate.mp3": Different MPEG versions or layers in one file. See related INFO message for details.
INFO: "E:\00. Abnormal Load - Goddess EP - Hekate.mp3": 19424 MPEG frames (1 V1L1, 0 V1L2, 19423 V1L3, 0 V2L1, 0 V2L2, 0 V2L3, 0 V2.5L1, 0 V2.5L2, 0 V2.5L3), +ID3v1+ID3v2, no VBR header, CRC
Done!
Moving on...
The best practise with mp3's is first run them through mp3val (or similar). You can run them though mp3val without the repair option and it'll tell you what's wrong in most cases, or just go right ahead and use the repair option. It will create backup of your file, first with the ext of "bak". Then go and do your tagging.
Oh, this is what I get after rerunning it though mp3val...
Analyzing file "E:\00. Abnormal Load - Goddess EP - Hekate SAVED.mp3"...
INFO: "E:\00. Abnormal Load - Goddess EP - Hekate SAVED.mp3": 19423 MPEG frames (MPEG 1 Layer III), +ID3v1+ID3v2, CBR
Done!
The file is also 64221 bytes smaller. May be the art work in the file.
Just one more thing mp2val doesn't do unicode, it will stop at any such file.
Your file has seen another tagging program at some time which uses a larger default tag space of 4kb, Florian uses a default 2kb (I believe).
You can see this if you use the "Remove Tag" option on the taskbar, then click the "Undo Button". Doing this will also get rid of stuff mp3tag doesn't recognize. But it would not have corrected your file which you would have seen in mp3tag as a 128kbit/s file with a length of 20:34 when it should be 320kbit/s & 8:27.
