Cover in WMP Format

[KodeZwerg]

Ich habe etwas entdeckt was das bewerkstelligen könnte, nur habe ich absolut keine Ahnung wie man das nach Delphi bringt.
Der Source ist in C# und den Link gibt es hier.
Damit kann man easy PRIV's lesen und schreiben. Beispiel

Am Rande:
Auch habe ich hier gelesen das WMP und andere den ID3v2 standard nicht so ganz einhalten, also könnte es immer wieder zu Komplikationen kommen wenn Du Dich auf WMP versteifst.

[EWeiss]

Zitat:

also könnte es immer wieder zu Komplikationen kommen wenn Du Dich auf WMP versteifst.

Was glaubst du bzw.. wo von ich die ganze zeit rede?
Ich will den WMP nicht zum Taggen verwenden deshalb mache ich mir ja den ganzen aufwand hier.

gruss

[KodeZwerg]

Ich hatte es beim erstem mal bereits verstanden das der WMP zum taggen nicht in Frage kommt.
Das mit der Taglib-Sharp, konntest Du damit was anfangen?

[EWeiss]

Zitat:

Zitat von KodeZwerg (Beitrag 1399147)

Ich hatte es beim erstem mal bereits verstanden das der WMP zum taggen nicht in Frage kommt.
Das mit der Taglib-Sharp, konntest Du damit was anfangen?

Habe es noch nicht getestet.

gruss

[Gausi]

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. ;-)

[EWeiss]

Zitat:

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

Das mag ja sein aber ich verwende keinen 2.4 Tag um Cover zu integrieren.
Siehe Shots..

Trotzdem wird der Tag vom System erkannt inklusive Cover.
Mein Problem sind die PRIV: Frames deshalb kann ich die Covers nicht anzeigen.

Wie gesagt die Frames werden vom WMP geschrieben und die Visualisierung Plug-Ins für den WMP greifen auf diese Frames zu.
Werden sie nicht gefunden wird das Cover auch nicht angezeigt.
Aber ich will den WMP nicht zum Taggen verwenden.

gruss

[Gausi]

Das Stück von Chris, das du mir geschickt hast, enthält einen ID3-Tag in der Version 2.4. Mp3fileUtils schreibt beim Bearbeiten genau die Tag-Version, die bereits vorhanden ist. Wenn keine vorhanden ist, Version 3.

Wenn du einen Hex-Editor (z.B. HxD, ist auch portabel) zur Hand hast: das 4. Byte in der Datei, direkt nach dem "ID3". Dieses Byte müsste bei Chris "4" sein, und bei Mariah "3". Wenn das Byte "3" ist, kommt Windows bzw. der WMP mit dem Tag klar.

Die PRIV-Tags haben mit dem Cover eigentlich nichts zu tun. Zumindest nicht mit dem Cover im ID3-Tag. Es kann sein, dass der WMP in diesen PRIV-Frames einige IDs speichert, die dann in einer WMP-Internen Datenbank mit einem Bild verknüpft sind (so kann man sparsam viele Dateien mit größeren Bildinformationen versehen) - aber das ist dann ein ganz anderes Thema.

Falls du das mit den PRIV-Frames nicht glaubst, mach folgendes:

• Öffne die Datei von Chris in Nemp, und lass dir die Eigenschaften anzeigen.
• Entferne im Reiter "ID3-Tags" beide Häkchen bei ID3v1 und ID3v2 und klicke auf "übernehmen"
• Damit ist die Datei vollkommen frei von ID3-Tags
• Bearbeite die Datei mit deinem kleinen Test-Tool, um die "Folder-.jpg" einzufügen

Dann solltest du eine Mp3-Datei mit Cover, und ohne PRIV-Frames haben.

Oder reden wir aneinander vorbei?

[EWeiss]

Zitat:

Dann solltest du eine Mp3-Datei mit Cover, und ohne PRIV-Frames haben.

Soviel Arbeit muss ich mir nicht machen.
Dazu habe ich dieses TOOL welche die Frames entfernt.

siehe!
https://www.delphipraxis.net/1399027-post15.html

Ich will sie aber nicht entfernen denn dann wird das Cover im Visual Plug-In nicht mehr angezeigt.
Ich möchte sie addieren.. und das macht im Moment nur der WMP.

Zitat:

Die PRIV-Tags haben mit dem Cover eigentlich nichts zu tun.

Doch das haben sie.. wenn ich sie mit dem TOOL entferne funktionieren die Covers im Visual Plug-In nicht mehr.
Das ist Fakt.

gruss

[Gausi]

Dann greift dieses Tool aber für die Coveranzeige auf die Datenbank des WMP zu, oder sonstwie über eine Windows-API, die möglicherweise irgendwo dokumentiert ist, oder aber vom Autor des Tools reverse engineered wurde. Das weiß ich leider nicht. Möglicherweise läuft das sogar übers Netz.

Wenn du diese Daten schreiben willst, müsstest du noch wissen, wo denn die eigentliche Bildinformation hinterlegt ist. In den PRIV-Frames stehen ja nur ein paar IDs, nichts mehr. Mit dem Cover im ID3-Tag haben diese IDs nichts zu tun.

[EWeiss]

Zitat:

Möglicherweise läuft das sogar übers Netz.

Nein habe diverse dinge durch probiert.

Es müssen 2 Covers im Pfad vorhanden sein.
AlbumArtSmall.jpg
Folder.jpg

sind beide vorhanden und die Frames addiert dann wird das Cover angezeigt.
Sind die Frames addiert und eins der Cover fehlt werden diese nicht angezeigt egal ob sich ein Cover im Tag befindet.
sind die Frames im Tag nicht vorhanden selbst wenn beide Covers vorhanden und ein Cover im Tag ist wird es nicht angezeigt.

Hmmm.. Ich glaube da gibt es wohl keine Lösung für.
Schade.
Dann hat sich das wohl erledigt danke für eure Hilfe.

siehe..
https://github.com/perrybutler/id3taglibrary
und lese den Bereich.. Windows Media Player album artwork fix

Zitat:

To make matters worse, Windows Media Player seems to store the GUID inside of a PRIV frame in the ID3 tag embedded in the mp3 file, so even if you try fixing the embedded artwork, Windows Media Player will see the GUID in the PRIV frame and regenerate the hidden jpg files. The problem spreads around from person to person, likely finds its way back into the online database, and never truly gets fixed because users don’t have a way of correcting mp3 files with bad GUIDs stored in PRIV frames of the ID3 tags:

Hier ist noch ein tool da kann man sehen was in den Frames gespeichert ist. Nur zur Info.
Siehe shot

gruss