TMediaplayer spielt keine MP3s mit MPEGInfo.Frame.Position >

[Cylence]

Hallo,

ich hab hier eine mp3, die mit dem TMediaplayer nicht abgespielt werden kann, es erscheint auch keine fehlermeldung vom TMediaplayer. Mit der Unit MPEGInfo hab ich die Infos der Datei ausgelesen und das einzigste was anders ist als bei anderen mp3s die gehen, ist das Frame.Position = 10 ist und bei allen anderen die ich gecheckt hab ist das immer 0. Gibt es da einen bug im TMediaplayer, oder ist die eher eine fehlerhafte mp3? Die mp3 ist von einem kunden der diese mit itunes erstellt hat.

Wär toll wenn jemand sich bischen auskennt

schonmal danke :-)

tom

[OldGrumpy]

Da bist du nicht alleine, ich habe schon mehrfach den Fall gehabt dass bestimmte MP3-Files, durchaus auch aus kommerziellen Quellen mit dem TMediaPlayer nicht gehen. Ich bin deswegen auf die Nutzung des aktuellen WMP via COM-Interface umgestiegen. Das funktioniert wesentlich reibungsloser.

[Cylence]

hallo,

also was genau an den mp3s anders ist hast du aber nicht rausgefunden? Hast du eine demo wie du den wmp benutzt? ich hab schon mal das activex object angeschaut aber habs nich ganz verstanden wie ich den zum laufen kriege...

gruß

tom

[Gausi]

Hi,

Irgendwie "kaputte" mp3s interessieren mich immer. Wenn du mir so eine Datei mal zusenden könntest (mail ät gausi punkt de), kann ich da ja mal reinschauen. :)

[Cylence]

Hi,

also ich hab ein Tool gefunden:

http://www.drtag.de/de/description_mp3rt.htm

freeware, mit dem hab ich den 1 frame entfernt und auf einmal gehts...

Gruß

tom

[OldGrumpy]

Also die paar Files die ich jetzt auf die Schnelle gefunden habe, haben alle am Anfang einen riesigen Bereich in dem nur Nullbytes stehen. Also hinter den Daten des ID3-Tags v2 :) Und erst nach diesem riesigen Puffer kommt dann das eigentliche MP3-File. WMP 7/9/10/etc. spielts problemlos ab, WMP 6.4 (auf dessen Funktionen ja auch der TMediaPlayer zurückgreift) kann das nicht. Gehe ich mit einem Hexeditor hin und kürze diesen Block Nullbytes, dann gehts. Das dürfte sich mit Deinen Experimenten decken.

Edith sagt: Dummen Tippfehler behoben der zu Irritationen führte. Ich meinte ID3 v2, nicht v1. Und sobald ich rausgefunden hab wie man Text durchstreicht, werd ich das auch klarer editieren können :)

[blauweiss]

Zitat:

Zitat von OldGrumpy

Da bist du nicht alleine, ich habe schon mehrfach den Fall gehabt dass bestimmte MP3-Files, durchaus auch aus kommerziellen Quellen mit dem TMediaPlayer nicht gehen. Ich bin deswegen auf die Nutzung des aktuellen WMP via COM-Interface umgestiegen. Das funktioniert wesentlich reibungsloser.

Hallo Oldgrumpy alias Rüsselmops,

ich wäre auch an einem (kleinen) Beispielcode interessiert, wie du den WMP per COM steuerst....

Viele Grüße,
blauweiss

[Cylence]

Hi,

ich hab irgendwo gelesen das der id3v1 tag hinter den daten sein sollte, und id3v2 vor den daten... aber weiß nicht ob das sicher stimmt. somit wäre das eh falsch wenn der id3v1 vorne is und die leerdaten zwischendrinnen sind wohl auch fehlerhaft... aber wie kann ich das mit delphi reparieren bzw umgehen? gibt es eine möglichkeit? ich hab schonmal versucht die mp3 tags auszulesen komplett zu clearen und neu reinzumachen, das bringt aber auch keine Änderung... leider. Jemand eine Idee was man machen könnte?

Gruß

tom

[Gausi]

Ja, der ID3v1-Tag steht hinten, der v2-Tag vorne. Wenn es so aussieht, als wäre hinter dem v2-Tag eine Menge von Nullbytes, dann ist das höchstwahrscheinlich falsch - die Nullbytes gehören zum ID3v2-Tag. Das ist das so genannte Padding, wodurch das Schreiben von weiteren Daten in den ID3v2-Tag beschleunigt werden kann (in dem das Padding verkleinert wird, sonst müsste ja die ganze Datei neu geschrieben werden).
Da einfach Nullen rauszulöschen könnte die Datei beschädigen, da die Größe des ID3-Tags im Header des Tags steht, und der wird vom Dekoder in aller Regel übersprungen.

Wie gesagt, schick mir mal so eine Datei. [Edit: oops, haste ja schon. :oops: ] Meine Vermutung, ins Blaue geraten: iTunes schreibt den ID3v2-Tag in der Subversion 4, mit der auch der richtige WMP arge Probleme hat. Wenn der Mediaplayer den gar nicht erkennt, und auch nicht überspringen kann, wird von Dateibeginn an nach einem ersten MPEG-Header für den Dekoder gesucht. Wenn der Tag zu groß ist (z.B. wegen Coverbildern darin) wird irgendwann abgebrochen und die Datei wird nicht abgespielt.

Beim clearen der Tags löschen einige Tagger auch einfach den Tag, ohne die Datei neu zu schreiben. Das geht schneller, führt dann aber bei großen Tags evtl auch zu Problemen.

[Cylence]

Hi,

ich hab Dir die Datei schon geschickt an deine Email...
hmm es gab auch ne weile eine defekte lame.dll die teilweise mp3s erstellt hat die nicht überall gespielt werden können das hab ich auch schonmal gehört...nur so mal nebenbei...
also in einem test hab ich auch versucht einfach mal alle Bilder aus den Tags rauszuhauen die sind für meine Zwecke auch unwichtig, aber das hat keinen Unterschied gemacht. Allerdings hatte ich einige MP3 Files in denen Itunes PNG Bilder geladen hatte und der Windows interne MP3 Splitter kommt damit scheinbar nicht klar, aber der Windows Media Player konnte die Files abspielen der verwendet scheinbar nicht den windows eigenen MP3 Splitter, jedenfalls hab ich das Problem durch den kostenlos erhältlichen MP3 Parser behoben, mit Hilfe des DSPack Forums Progdigy.com. Falls noch jemand so ein Problem haben sollte:

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

hier gibts den MP3 Parser Filter. damit gehn dann schonmal einige mp3s mehr als vorher :-) bei mir jedenfalls.

Also das mit den Tags, dann wäre es ja theoretisch am besten man schreibt die files ganz neu... mit ordentlichen tags an den richtigen stellen. oder? Ich weiß nicht mir fällt nur im Moment keine andere Möglichkeit ein.

Gruß

tom

[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