Problem mit verschiedenen Cover bei Bearbeitung mehrer Dateien

Bei Vorigen Versionen (2.72 war glaube meine letzte Version vorher) wurde wenn man mehrere Dateien mit verschiedenen Covern Markiert hatte, bei der Cover-Vorschau im Tag-Panel "Verschieden Cover" angezeigt und man konnte andere Felder im Tag-Panel bearbeiten.
Jetzt (2.78) wird das Cover der ersten Datei angezeigt und ändert man andere Felder und speichert, ist dieses Cover in allen Dateien drin.

mfg
Stefan

Edit:
Das scheint nicht immer aufzutreten, jetzt war es wieder richtig.

Meiner Ansicht nach ist das das normale Verhalten.
Wenn du Dateien auswählst, die gar kein eingebettetes Cover haben, kann je nach Einstellung in
Extras>Optionen>Tag-Panel>Cover anzeigen
und
Extras>Optionen>Tags>Bilder aus Verzeichnis nicht als Album-Cover zeigen
die ANzeige variieren.

Der Fall, den du beschrieben hast, ist von mir nicht nachzustellen: entweder die Dateien haben dasselbe Cover und dann wird das gezeigt oder die Cover unterscheiden sich, dann bleibt die Coveranzeige an sich leer und es gibt den Hinweis auf die unterschiedlichen.

Du müsstest die genauen Umstände schildern, damit das nachgestellt werden kann.

Und: eine automatische Übernahme gibt es auch nicht. Du müsstest schon speichern.

Das kann ich nicht nachstellen.
Sag doch mal genau, wie die Arbeitsschritte aussehen.
Beobachte dabei besonders die Anzeige im Tag-Panel für das eingebettete Bild.
Bei mehreren Covern müsste die die ganze Zeit kein Bild zeigen.

Da bmp dateien nicht vorgesehen sind als Cover, ist es jetzt schon schwierig einen Bug zu entdecken. Da du mit MP3tag keine BMPs einbetten kannst - wie sind die in die Dateien gekommen?

Oder wird zu den gezeigten Bildern noch ein Dateiname gezeigt? Dann sind nämlich gar keine Cover eingebettet, sondern du siehst die erste Bilddatei aus dem Ordner.

Lassen sie sich denn mit MP3Tag löschen?
In dem Fall kannst Du sie ja exportieren, dann im MP3 löschen, die exportierte Daeti ins JPG-Format ändern und erneut in die MP3-Datei einfügen.

Als Empfehlung im informellen Standard gilt aus Gründen der Verwendung auf verschiedensten Plattformen PNG oder JPG.
"The "image/png" or "image/jpeg" picture format should be used when interoperability is wanted."
http://id3.org/id3v2.3.0#Attached_picture

Ich kann mir nicht vorstellen, dass Florian sich die Mühe macht, solch eine Nische auch noch zu unterstützen, zumal es aus meiner Sicht wirklich keinen Sinn macht, riesige unkomprimierte Bilder in kleine komprimierte MP3s einzubetten.

Du kannst die Bilder mit Hilfe MP3tag aus den Dateien exportieren - nimm eine Maske für den Namen wie
%album% - %title%.bmp
Lass Dir die BMP-Dateien im Explorer suchen/anzeigen,
Nimm ein Programm, das diese Liste nehmen kann und in jpg oder png verwandeln kann und nur die Endung tauscht.
Lass dann die neuen jpg/png-Dateien von MP3tag wieder importieren.
Nimm für den Namen dieselbe Maske wie zuvor, nur dieses Mal entsprechend der neuen Endung .jpg

Damit müsste die Hauptlast der Umstellung beim PC liegen und der Umstand einigermaßen gering sein.

Hey das ist super. Danke dir für diesen Hinweis. Funktioniert sehr gut :slight_smile:

Ich stelle ebenfalls dieses Verhalten fest. Wenn man mehrere Files jeweils mit unterschiedlichen Covern bearbeitet (z.B. bei allen Files das Genre ändert), so wird das Cover der ersten Datei in alle anderen übernommen.
Ich habe das nun 4x hintereinander rekonstruieren können.
Das war bisher nicht so, und meiner persönlichen Meinung nach kann das auch kein Feature sein, wenn bestehende Informationen unbeabsichtigt überschrieben werden.
Zumal das bisher ja auch nicht der Fall war.

Das wäre kein Feature sondern eine Katastrophe.
Nur ich kann es hier nicht nachvollziehen und es ist mir in meinem Bestand, den ich regelmäßig auf diese Art bearbeite, noch kein Fehlergebnis auufgefallen.

Ist es denn bei Dir wie beim Threadstarter denn ebenfalls ein Problem im Zusammenhang mit BMPDateien?

Selbstverständlich habe ich den Thread komplett durchgelesen und ich habe mich auch daraufhin erstmals mit der Import/Export Methode vertraut gemacht. :slight_smile:
Ich gebe aber zu, dass ich nicht aufgepasst habe welchen Typ die Bilder hatten, als es mir zuletzt aufgefallen ist und ich es mehrfach nachvollzogen habe.

Ich teste das mal ausführlich mit den verschiedenen Bild Typen.
Ich bin mir aber sicher, dass ich bereit früher bereits getaggte mp3s (auch mir mbp) hatte, die dieses Verhalten nicht aufwiesen. Ich bin mir deshalb so sicher, da mein Auto die Bilder nur in einem Bestimmten Format korrekt anzeigt, und dazu gehört auch bmp, weshalb ich mich immer sehr gefreut hatte wenn die Covers bereits als bmp getaggt waren.

Ich melde mich sobald ich meinen Test abgeschlossen habe.

Tja, da hab ich wohl nicht aufgepasst. Sory.
Es verhällt sich (wie Ihr bereits vermutet habt) genau wie beim Thread-Starter so, dass dieser Fall nur eintritt wenn das Cover ein bmp ist.

Sehr schade, da muss ich dann wohl künftig bissi mehr Zeit investieren und die Cover nachträglich bearbeiten.

Vielleicht kommt ja doch noch irgendwann der bmp Support :wink:

Was allerdings extrem unsinnig wäre.
Man wendet dann für Musik ein Datenreduktions- und Komprimierungsverfahren an (MP3) um Speicherplatz zu sparen und konterkariert dann diese Vorgehensweise, indem man ein unkomprimiertes/nichtreduziertes Format beim Beiwerk "Cover" verwendet.

Da liegt sicher ein kleiner Widerspruch drin, aber es als "Unsinn" zu betiteln halte ich für übertrieben. Für mich wäre es ein Feature da (wie oben beschrieben) die Anzeige in meinem Auto mit bmp stabil läuft (im Gegensatz zu jpg/png), und Speicherplatz interessiert mich nicht. Zudem wird meiner Ansicht nach MP3 schon lange nicht mehr eingesetzt um primär Daten zu komprimieren, sondern weil es nun mal der defacto Standard für Millionen von Abspielgeräten ist. Verlustfreie Formate laufen ja auf den meisten (Standard) Geräten schlicht nicht.

Unabhängig davon sollte meiner Meinung nach die Entscheidung über Einsatz des Datentyps dem User ermöglicht werden, und ich hoffe einfach weiter.