# ERROR ID3V2.3 header parse error

**URL:** https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315
**Category:** Support
**Created:** [January 28, 2025, 6:38pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315 "2025-01-28T18:38:47Z")
**Posts on this page:** 20
**Page:** 1

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 28, 2025, 6:38pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/1 "2025-01-28T18:38:47Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 28, 2025, 6:43pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/2 "2025-01-28T18:43:00Z")

</div>

> [@brandon210](#):
>
> 'm on v3.28 Windows

Current version is 3.28b

> [@Mp3tag Development Build Status](https://community.mp3tag.de/t/mp3tag-development-build-status/455):
>
> Date: 2025-01-27 Version: 3.28b Status: Beta warningDownload: 64-bit [mp3tagv328b-x64-setup.exe](https://download.mp3tag.de/mp3tagv328b-x64-setup.exe) 32-bit [mp3tagv328bsetup.exe](https://download.mp3tag.de/mp3tagv328bsetup.exe) 3.28b (2025-01-27) CHG: progress reporting in taskbar button when exporting files is performed in one-percent increments. CHG: progress reporting when exporting files requires less updates of the user interface. CHG: progress reporting in taskbar button when reading files is performed in one-percent increments. 3.28a (2025-01-08) CHG: use link i…

Perhaps an update cures it.

---

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 28, 2025, 7:10pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/3 "2025-01-28T19:10:19Z")

</div>

Odd, I specifically checked for an update before posting and it came back that I was on the newest version.

Installed the new version and the issue remains.

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [January 28, 2025, 7:11pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/4 "2025-01-28T19:11:58Z")

</div>

Could you please check such a song with the tools mentioned here:

> [@Hints for asking Support Requests](https://community.mp3tag.de/t/hints-for-asking-support-requests/56190#check-problematic-files-for-errors-3):
>
> If you need support using Mp3tag, you can help the community members that are about to support you in finding a solution or workaround to your problem, by following these simple guidelines. Be descriptive, also in what you’ve already tried Please give a short explanation what’s not working as expected or what you’re trying to achieve. It’s best to know any details about the problem at hand and especially, what steps you’ve already tried to solve it by yourself. Helpful information also includ…

and here:

> [@How to check files for errors?](https://community.mp3tag.de/t/how-to-check-files-for-errors/44633):
>
> It’s required and often helps to reduce support cycles to check files for errors before filing a bug report. Symptoms of erroneous files are often missing or wrong bitrate or length audible blips or skips tags seem to be sticky and cannot be removed There are some really good tools to check the files for errors, namely MP3 Diags — identifies many different issues in MP3 files Website: [http://mp3diags.sourceforge.net](http://mp3diags.sourceforge.net) Download: [MP3 Diags - Getting MP3 Diags](http://mp3diags.sourceforge.net/010_getting_the_program.html#binWindows) If the font size in MP3 Diags is …

---

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 29, 2025, 9:42am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/5 "2025-01-29T09:42:00Z")

</div>

Here's a file as referenced in MP3tag:

 ![image](https://community.mp3tag.de/uploads/default/original/3X/3/8/3821469dca4cf1348dfbd4ab4d8a50bc47238edf.png)

MP3 Diags shows this error:  
 ![image](https://community.mp3tag.de/uploads/default/original/3X/8/a/8af4d7a99e4f65d9f967b5100d256b641eb0ba50.png)

dbPoweramp and other programs have no issue reading this tag:

 ![image](https://community.mp3tag.de/uploads/default/original/3X/9/2/921fd6670076e0ea3d354231b8a19d3c2552e748.png)

\*\*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?

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [January 29, 2025, 9:53am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/6 "2025-01-29T09:53:07Z")

</div>

Could you please tell us how you have created this affected mp3?  
Did you converted them from CD? From FLAC?  
What software did you use?

Or do you have downloaded this affected mp3? Which source?

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [January 29, 2025, 9:55am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/7 "2025-01-29T09:55:44Z")

</div>

> [@brandon210](#):
>
> Was this an issue with 3.28 that 3.28b has resolved?

Doesn't the message pop up in 3.28b?

If the files are from

> [@brandon210](#):
>
> December 2024

I doubt that

> [@brandon210](#):
>
> Something happened with the program from yesterday to today

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.

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [January 29, 2025, 9:58am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/8 "2025-01-29T09:58:53Z")

</div>

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?

---

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 29, 2025, 10:07am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/9 "2025-01-29T10:07:27Z")

</div>

> [@LyricsLover](#):
>
> 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?

I use the Discogs search source when I retag with MP3Tag, so this is normal. It includes a lot of extra data from Discogs in the tag.

---

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 29, 2025, 10:12am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/10 "2025-01-29T10:12:29Z")

</div>

> [@ohrenkino](#):
>
> > [@brandon210](#):
> >
> > Was this an issue with 3.28 that 3.28b has resolved?
> 
> Doesn't the message pop up in 3.28b?

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.

---

<div class="post-metadata">

### Author: ![LyricsLover](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/l/c6cbf5/32.png) [@LyricsLover](https://community.mp3tag.de/u/LyricsLover)
#### Post date: [January 29, 2025, 10:13am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/11 "2025-01-29T10:13:44Z")

</div>

> [@brandon210](#):
>
> So I've just got a long few days of retagging 1,000 files.

Without knowing where your problems come from and whether they will reappear?

---

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 29, 2025, 10:17am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/12 "2025-01-29T10:17:50Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [January 29, 2025, 10:21am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/13 "2025-01-29T10:21:12Z")

</div>

> [@brandon210](#):
>
> 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.

And what happens if you retag them with 3.28?

---

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 29, 2025, 10:41am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/14 "2025-01-29T10:41:05Z")

</div>

> [@poster](#):
>
> And what happens if you retag them with 3.28?

As stated, these issues arose after updating to 3.28 from 3.27.

Retagging in 3.28b appears to correct the issue.

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [January 29, 2025, 11:00am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/15 "2025-01-29T11:00:57Z")

</div>

> [@brandon210](#):
>
> As stated, these issues arose after updating to 3.28 from 3.27

This does not answer my question "And what happens if you retag them with 3.28?". It may also be only time-coincidence.

---

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 29, 2025, 11:19am UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/16 "2025-01-29T11:19:25Z")

</div>

> [@poster](#):
>
> This does not answer my question "And what happens if you retag them with 3.28?". It may also be only time-coincidence.

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.

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [January 29, 2025, 12:53pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/17 "2025-01-29T12:53:20Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![brandon210](https://community.mp3tag.de/user_avatar/community.mp3tag.de/brandon210/32/7232_2.png) [@brandon210](https://community.mp3tag.de/u/brandon210)
#### Post date: [January 29, 2025, 1:32pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/18 "2025-01-29T13:32:02Z")

</div>

> [@poster](#):
>
> II have now tested this based on the assumption that a problem embedding a cover is the cause.

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.

---

<div class="post-metadata">

### Author: ![confucius](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/9e8a1a/32.png) [@confucius](https://community.mp3tag.de/u/confucius)
#### Post date: [February 1, 2025, 10:35pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/19 "2025-02-01T22:35:25Z")

</div>

Brandon,

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.

---

<div class="post-metadata">

### Author: ![confucius](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/c/9e8a1a/32.png) [@confucius](https://community.mp3tag.de/u/confucius)
#### Post date: [February 1, 2025, 11:40pm UTC](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315/20 "2025-02-01T23:40:08Z")

</div>

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.

[Next page](https://community.mp3tag.de/t/error-id3v2-3-header-parse-error/67315.md?page=2)
