Schon seit einiger Zeit beschäftige ich mich damit, mit MP3Tag in meiner Itunes-Mediathek die Album-Cover zu optimieren, d. h. fehlende zu ergänzen oder nicht zum jeweiligen Track passende bzw. unansehnliche oder zu kleine (< 500x500) zu ersetzen. Dabei stoße ich immer wieder auf Unzulänglichkeiten der M4A- Unterstützung von MP3Tag. Nach wie vor (Version 3.20) ist die Erkennung des Cover-Formates fehlerhaft, wenn der MIME-(Sub-)Typ, genauer gesagt das 'Datatype'-Feld in den 'Data'-SubAtoms des 'covr'-Atoms, nicht mit dem tatsächlichen Grafik-Format übereinstimmt (siehe auch https://community.mp3tag.de/t/x-cover-format-wird-falsch-erkannt/59871). Nun ist mir noch ein weiterer Fehler aufgefallen. Wenn man im Tag-Panel das Kontext-Menu zum Album-Cover aufruft, erscheinen dort die Menu-Items "Cover-Typ ändern" und "Cover-Beschreibung ändern". Die damit ausgewählten bzw. eingegebenen Texte erscheinen nach Schließen der entsprechenden Dialoge neben dem Cover. Sobald man jedoch 'Speichern' klickt, verschwindet die 'Beschreibung' ersatzlos, und der gewählte Cover-Typ wird ungefragt durch 'Front Cover' für das erste und 'Other' für alle weiteren Cover-Bilder ersetzt. Das ist eigentlich keine Überraschung, da es bei Quicktime- resp. M4A- (Itunes-) Metadaten standardmäßig keine Felder für Cover-Typ oder Cover-Beschreibung gibt. Ein 'normaler' User könnte sich aber verunsichert oder gar veralbert fühlen: Man kann eingeben, was man will, aber nichts wird übernommen, und es folgt auch keine Fehlermeldung.
Das Programm heißt zwar 'MP3'Tag, aber wenn 'M4A' als verfügbares Format angegeben ist, sollte das auch konsequent umgesetzt werden. Im 'Itunes für Windows' Forum wird übrigens MP3Tag häufig empfohlen bzw. verlinkt.
Im Übrigen möchte ich auch hier nochmal meine Hochachtung für den Entwickler von MP3Tag, Florian Heidenreich, ausdrücken. Da ich selbst mich ein wenig mit Software-Entwicklung beschäftige, kann ich durchaus einschätzen, welche Leistung das Erstellen, die Pflege und die Weiterentwicklung dieses mittlerweile doch sehr umfangreichen und mächtigen Programmes bedeutet!
Das Problem von nicht übernommenen Daten gibt es nicht nur für m4a, sondern auch z.B. für die führenden Nullen im Feld TRACK oder den Limitierungen be GENRE für ID3V1 sowie anderen Daten wie ALBUMARTIST und COVER, die in ID3V1 nicht vorhanden sind und deshalb verworfen werden, wenn dieser Tag-Typ gespeichert werden soll.
In MP4-Dateien braucht das Feld für UNSYNCEDLYRICS kein führendes Länderkennzeichen und das wird dann auch nicht gespeichert.
MP3tag erlaubt es allerdings, mehrere Dateitypen in einem Rutsch zu bearbeiten. Und da trägt MP3tag Sorge, die Daten aus den internen Feldern jeweils in der für das tag-Format richtigen Form zu speichern.
Ich würde dieses Verhalten nicht als Bug sondern eher als Feature sehen - denn obwohl du Daten eingibst, die für das Tag-Format ungültig sind, verhindert MP3tag, dass damit auch ungültige Einträge entstehen.
Eine sich ggf. anschließende Forderung, Funktionen nicht zu erlauben, die nicht für alle Tag-Formate geeignet sind, würden den Arbeitsablauf aus meiner Sicht deutlich erschweren, da dann für ein und dieselbe Änderung mehrfach gefiltert und selektiert werden muss.
Dazu gibt es in dem von dir selbst gelinkten Thread den Kommentar des Entwicklers, die Erkenntnis, dass dies durch ein anderes Programm passiert und auch erklärt wurde, dass MP3tag hier keine Analyse durchführt und die ganze Beobachtung als "kein Fehler" eingestuft wurde.
Da verstehe ich nicht, wieso du einen eigenen Thread zu dem Thema erneut aufmachst noch wieso du die bereits geführte Diskussion nicht fortführst - was natürlich nur sinnvoll wäre, wenn neue Erkenntnisse hinzugekommen wären.
Dazu gibt es in dem von dir selbst gelinkten Thread den Kommentar des Entwicklers, die Erkenntnis, dass dies durch ein anderes Programm passiert und auch erklärt wurde, dass MP3tag hier keine Analyse durchführt und die ganze Beobachtung als "kein Fehler" eingestuft wurde
Ich halte es sehr wohl für einen veritablen Fehler, wenn MP3Tag in seiner neuesten Version (3.20) ein Cover immer noch als PNG kennzeichnet, obwohl es tatsächlich im JPEG-Format vorliegt. Mit meinem früheren Thread konnte ich ja nachweisen, dass man sich bei m4a-Tracks eben nicht auf die 'Datatype'- Information verlassen darf, wenn man eine zuverlässige Erkennung des Cover-Formates haben will.
Meiner Ansicht nach zeigt der Thread, dass man sich nicht auf jedes andere Programm verlassen darf. Denn das andere Programm trägt doch wohl offensichtlich Blödsinn ein.
Auch wäre nun zu überlegen, warum denn die Bildtyp-Information noch einmal extra eingetragen wird statt sie direkt aus dem Bild zu lesen - könnte das ggf. eine Überlegung zur Performanz gewesen sein? Eben dass nicht der ganze lange BLock mit Bilddaten auseinandergenommen werden muss, sondern gleich anhand der eingetragenen Kennung verzweigt werden kann.
Egal.
Geht es dir um eine weitere Diskussion der bereits als "kein Bug" eingestuften Funktion zur Ausgabe der im Tag gefundenen Bildtyp-ID?
Dazu gibt es schon folgende Aussage:
Und du selbst sagst:
Was nutzt die tollste Performance, wenn das Ergebnis falsch ist? Man muss auch nicht 'den ganzen langen Block auseinandernehmen'. Aus den ersten 10 Byte läßt sich das Grafikformat ziemlich zuverlässig ermitteln, zumal es nur JPEG oder PNG sein kann.
Florian spricht ausdrücklich von 'momentan'. Das muss also nicht das letzte Wort sein.
Das basierte auf meinem Kenntnisstand vom Januar d. J.
Und mittlerweile gibt es ja auch ein Update.