TMediaplayer spielt keine MP3s mit MPEGInfo.Frame.Position >

[OldGrumpy]

Das war ein Tippfehler, natürlich war v2 gemeint, nicht v1. Habs oben mal geändert und ne Anmerkung dazugeschrieben. Und die Nullbytes da waren definitiv fehl am Platze :)

[Gausi]

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.

[OldGrumpy]

10 Bytes? Das riecht ja fast nach Platz für nen ID3 Tag Footer :)

[Gausi]

Hatte ich zuerst auch im Verdacht, aber diese 10 Bytes zwischen Tag-Ende und Mpeg-Frame haben mit nem ID3-Footer leider nichts zu tun. Das ist einfach Datenmüll, vermutlich verursacht vom Encoder oder einem fehlerhaften Tagger. Ein früher mal vorhandener Footer könnte dann durchaus Ursache des Problems sein. Da ist der Tagger darüber gestolpert und hat diese 10 Bytes da doppelt kopiert, worüber jetzt der Player stolpert. Oder so. :gruebel:

[Cylence]

Hi,

die 2te mp3 ist eine mit einem PNG Cover in den Tags, die kann auch bei einigen Playern nicht abgespielt werden, wie TMediaplayer, DSPack basierende Player, wenn nicht der mp3 parser oder ein alternativer parser installiert ist.
Auf Deinem Bild sieht man das die Datei mit Lame 3.97 erstellt wurde, evtl war das auch noch ein bug von der Version, ist ja nicht mehr die aktuellste so viel ich weiß gibts mindestens Version 3.99 schon.

http://www.free-codecs.com/download/Lame_Encoder.htm

bzw ne beta von 4.0

Kann man das nun per Delphi Code reparieren? Hat jemand eine Idee? So viel kenn ich mich leider nicht aus mit headern usw...

Gruß

tom

ps eben gesehen in der history von lame:

LAME 3.98 beta 1 May 16 2007

Bug tracker item: [ 1711980 ] LAME writes invalid Xing header when ID3 tags exist; LAME was sometimes writing an invalid Xing/Info header


und noch viele weitere bugfixes bezüglich xing header usw...also evtl kommt das von der lame dll v 3.97