Ich antworte mal hier, und nicht im Nemp-Thread.
Um es kurz zu machen: Dein Code ist in Ordnung, Mp3FileUtils ist in Ordnung, Nemp ist in Ordnung. Der Fehler liegt bei Windows. Ist für dich sicherlich eine unbefriedigende Antwort, aber davon bin ich jetzt überzeugt. Andere Tagger, die nicht auf meinem Code basieren, haben prinzipiell das gleiche Problem, auch wenn sie das ggf. umgehen.
Danke erstmal für die Datei, die du mir geschickt hast. Wie vermutet, ist der bereits vorhandene relevante Tag in der Datei in der Version 2.4, die unter Windows Probleme macht. Dass "ohne Cover" die Infos angezeigt werden, liegt am ebenfalls vorhandenen ID3-Tag in der Version 1.
Das Problem ist, dass "alte" Windows-Versionen (bis mindestens einschließlich Windows 7) den ID3-Tag in der Version 2.4 nicht erkennen und verarbeiten können. Unter Windows 10 läuft das mittlerweile. Das Problem ist dabei nicht das Cover, sondern die reine Größe des ID3-Tags, wenn ein Bild rein kommt. Oder, um es anders auszudrücken: Der Tag ist in Ordnung, aber durch den großen ID3-Tag erkennt Windows die Datei nicht mehr als mp3-Datei. dann wird auch kein ID3-Tag in der Version 1 gesucht, und dann sind die Titel-Infos "weg".
Ein wenig zur (vermutlichen) Problemursache - das wird ein klein wenig technisch, aber wir sind hier ja Entwickler
.
Eine mp3-Datei sieht (etwas vereinfacht) so aus:
Code:
Optionaler ID3v2-Tag
(variable Größe)
----------------------
Optionales anderes Gedöns
z.B. Xing-Header, Ape-Tags, Datenmüll
----------------------
MPEG-Frames mit eigentlichen Audiodaten
(Framegröße abhängig von Bitrate, Samplerate etc. pp.)
(Frameanzahl abhängig von der Dauer des Stückes)
----------------------
Optionaler ID3v1-Tag
(128 Bytes, beginnend mit TAG)
Einen MP3-Datei-Header im eigentlichen Sinne gibt es nicht. Ein mp3-Decoder muss im Bytestrom nach MPEG-Frames suchen. Idealerweise steht der erste Frame direkt am Anfang der Datei, ansonsten direkt nach dem ID3v2-Tag, der sinnvollerweise von Decodern, die den Tag erkennen, bei der Suche nach MPEG-Frames übersprungen wird.
Einen MPEG-Frame erkennt man dabei an 11 gesetzten Bits und einem Plausibilitätscheck der folgenden 21 Bits (zusammen dann 4 Byte). Um nun zu erkennen, ob eine Datei eine MP3-Datei ist, ist es eine gängige Methode, in den ersten X-Bytes der Datei nach einem gültigen MPEG-Frame zu suchen. Oder halt in den ersten X Bytes nach dem ID3v2-Tag.
Wenn Windows eine mp3-Datei mit Version 2.3 am Anfang findet, dann wird dieser Bereich der Datei übersprungen, und nach dem ID3v2.3-Tag recht zügig der erste MPEG-Frame gefunden. Wenn du deinen Code auf einer Datei ausführst, die Version 2.3 enthält, läuft dein Tool.
Als Hinweis: Nemp zeigt die Tag-Version an im Eigenschaften-Dialog zu einer Datei im Reiter "Mp3- und ID3-Details".
Wenn Windows eine mp3-Datei mit Version 2.4 findet, dann wird der Tag nicht übersprungen (weil er nicht als solcher erkannt wird). Dann scannt Windows auch in dem ID3-Tag nach MPEG-Frames. Wenn der ID3-Tag nun länger ist als die voreingestellte Suchlänge X, weil z.B. ein Bild im Tag eingebettet ist, dann schlägt die MP3-Erkennung fehl, Windows erkennt die Datei damit nicht als gültige mp3-Datei, und sucht folglich dann auch nicht mehr nach einem ID3v1-Tag am Ende der Datei. Deshalb sind die Infos dann für den Player "weg".
In der Entwickler-Ecke habe ich da mal etwas Schabernack im Rahmen des Advent-Gewinnspiels getrieben. Da hatte ich im ID3-Tag eine weitere Mp3-Datei versteckt, die abgespielt wurde, wenn man den ID3-Tag-Header ungültig gemacht hat (mit einem Hex-Editor). Andernfalls wurde das "reguläre" Lied abgespielt.
Unterstützt wird diese These auch dadurch, dass im Windows-Explorer nicht nur die Tag-Informationen fehlt, sondern auch die Dauer des Stücks. Die ist aber nicht im ID3-Tag gespeichert, sondern wird über die Bitrate und Dateigröße ermittelt.
Abhilfe 1: beim Schreiben des Covers darauf achten, dass man einen Version 2.3-Tag vorliegen hat. Ansonsten entweder nicht schreiben, oder den Tag konvertieren. Wenn man das "dreckig" macht, in dem man den vorhandenen wegschmeißt und einen neuen mit den gewollten Infos füllt, kann es unter Umständen passieren, dass Daten verloren gehen. Sauberer wäre, jeden ID3v2-Frame sauber zu konvertieren. Da aber einige Frames neue IDs bekommen haben, ist das nicht ganz trivial. So eine ConvertTo-Methode stand mal auf der ToDo-Liste, habe ich aber noch nicht umgesetzt - und plane es eigentlich auch nicht.
Abhilfe 2: Windows 10 anschaffen. Das kann den "neuen" Tag, der irgendwann um das Jahr 2000 rausgekommen ist.
Keine schöne Sache, aber das ist einfach ein Bug in Windows. Du kannst übrigens mal versuchen, deine Testdatei mit dem WMP (oder dem Windows Explorer) zu taggen. Wenn du die Datei dann in einem Hex-Editor öffnest, wirst du am Anfang der Datei zwei ID3-Tags finden. Etwas weiter hinten den "echten" mit Version 2.4 und davor den in Version 2.3, den Windows drangepappt hat. (Suche nach "ID3" in der Datei, damit fängt der Tag an.)
Edit: Private Frames sollten damit nichts zu tun haben. Diese werden von diversen Programmen genutzt, um weitere Infos schreiben zu können, für die es im ID3-Quasi-Standard keine Entsprechung gibt. Nemp nutzt auch ein oder zwei private Frames, ist aber damit deutlich sparsamer als der WMP.