Mp3Tag is reporting some MP3s as being errornous

Hi there!

Mp3tag v2.46 is reporting some of my files as being errournous. It says (!BAD ID3v2) in the TAG-column. I then analysed it using "MP3 Diags"... But there doesn't seem to be anything wrong with it.

Can someone of you find the reason?

This is the header according to MP3 Diags:
padding=1938, unsynch=NO; frames: TALB="FM4 Soundselection 19", TPE1="deichkind", TPE2="Various Artists", TPOS="1", TCMP="1", TIT2="arbeit nervt", TRCK="18", TDRC="2008", APIC size=21611 status=cover, COMM size=104

Can you see something breaking the ID3v2.4 rules? If not, it would be cool if I could send the mail to someone of you for further analysing. (Don't want to upload it to rapidshare... lawyers... music industrie... you know... fuck them all.)

Best regards!

You can use a file splitter like HJSplit and spilt the file in i.e. 200 kbyte (depends how big the cover tag is) parts and only upload the first part.

Hi there!

I uploaded the first 500K of the file here:
http://rapidshare.com/files/383587825/ausschnitt.mp3.html

Thanks!

The problem is the APIC frame which has flags set that indicate that unsynchronisation has been applied though it has not.
You can change that with a hex editor or with a tool like gsar (easier)
You can download gsar here.

Copy all files with bad tags to a new folder.
Copy this text into a new text file in that folder and adapt the path at set gsar=
Rename it to fix.bat

@echo off
REM Change path to match the location of gsar.exe
set gsar="c:\Tools\gsar.exe"
REM
FOR %%f IN (*.mp3) DO (%gsar% -o -s:2:0image/jpeg -r:0:0image/jpeg "%%f")

Then execute the bat file. Make sure you have a backup of the files.
It works only on files that have exactly the same issue.

I do have the same problem with a few file since upgrading to 2.46a (was using 2.42 before i think and i don't recall having that problem) but this solution didn't work. In fact, gsar didn't find the aforementioned string in the mp3. I don't even see any APIC frame in the files i checked... however i've found a IDv2 frame named TCP although it is empty.

However, I can read its id3 v2 with another old tag software called ID3-TagIT with no problem at all and in fact, i did find that TCP frame in that software in a id3 v2 tab under "edit tag" called "Notsupported frames". In that program, it shows under there any v2 frame not supported although it doesn't permit to edit it nor in this case delete it.

Other files that i checked have the same apparent problem. There are frames in ID3 v2 which appears that MP3tag doesn't like although i can open those files in ID3-TagIT (a few years old program no longer updated) with no problem. Some of those files have a few empty frames called PRIV and most if not all have been encoded/saved with iTunes since it appears in the v2 tag as well.

PS: I've tried to attach a 200k sample but it seems the forum software doesn't like the file or firefox... i'll uploaded it to google at http://sites.google.com/site/motortestsite...rects=0&d=1

So it is actually not the same problem. Only the same result for you.

Mp3tag is strict about the tag standard so it stops reading the tag when something is wrong.

The TCP issue can be fixed with
-sTCP:0:0:0:0:3:0:0:0:x31:0 -rTCMP:0:0:0:3:0:0:0:x31:0

Thanks, that solved it although I had to add :0 at the end of the replacement line or else the actual music checksum did change.

Seems iTunes is evil in some instances, at least the version that was used for tagging those files (v 7 something if i recall right)... i checked and all of them had that wrongly formatted TCP frame id instead of TCMP as it should be...

Thanx again

I forgot one byte, thanks.

This should be the correct one
-rTCMP:0:0:0:3:0:0:0:x31:0

Do you know the complete tagging history of the file?
I think it's an issue of windows explorer/media player that can't handle ID3v2.2 tags.
iTunes might write them when ripping new files.

No, I don't. Sorry. All I know is that the files with the TCP frame ID were originally encoded (so probably also tagged) with iTunes v4.x

I also found a few wrong with a Frame ID "CM1" and others with Frame ID "TSIZ" which I don't know what program is responsible of.