Also den Fehler habe ich gefunden, lag nicht an ID3v2.4. Wie er entsteht, weiß ich aber nicht - da wird wohl der Encoder irgendwie Mist gebaut haben.
Wie schon herausgefunden, beginnt der erste MPEG-Frame 10 Bytes nach dem Ende des ID3v2-Tags. Das ist zwar unschön, aber damit sollte ein Player eigentlich klar kommen. Problem ist wohl, dass die ersten 4 Bytes ein gültiger MPEG-Header sind. Und zwar ist das eine Kopie des Headers des MPEG-Frames, in dem der XING-Header steckt.
Hab mal ein Screenshot von HxD angehängt. Oben der Rest vom ID3-Tag, mit ein paar Nullbytes. Dann die Folge FF
FB 90 04. Das ist ein gültiger MPEG-Frameheader. Allerdings kommt dahinter nicht ein passend großer MPEG-Frame, sondern nur 6 Nullbytes. Der darauf folgende Frame stimmt - dass da auch viele Nullen stehen liegt daran, das das kein echter Mpeg-Frame ist, sondern der Xing-Header, der sich in einem solchen versteckt (da stehen Infos bzgl. variabler Bitrate drin). Die eigentliche Audio-Information beginnt dann nach dem großen 0-Block mit FF FE 10 04
Ein sauberes Reparieren der Datei besteht also darin, die 10 gelb markierten Bytes in der Datei zu löschen. Ich hoffe, dass dieser Parser genau das macht, also defekte Frames aussortiert.
@Nullbytes: das kann auch sein, aber generell sollte man damit aufpassen. Sowas kann passieren, wenn ein Tagger einen alten Tag schnell löscht (d.h. mit Nullen auffüllt), und dann einen neuen schreibt, ohne diese Nullen passend zu verarbeiten.
edit: Ich sollte erst E-Mails abrufen, dann hier posten. Die Datei in der zweiten Mail funktioniert aber einwandfrei, oder? Da steckt dieser Fehler nämlich nicht drin.