# Problem mit verschiedenen Cover bei Bearbeitung mehrer Dateien

**URL:** <https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099>\
**Category:** Fehlermeldungen\
**Created:** [July 10, 2016, 4:10am UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099 "2016-07-10T04:10:07Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![StefanW](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/s/f9ae1b/32.png) [@StefanW](https://community.mp3tag.de/u/StefanW)\
**Post date:** [July 10, 2016, 4:10am UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/1 "2016-07-10T04:10:07Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [July 10, 2016, 5:50am UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/2 "2016-07-10T05:50:37Z")

</div>

> [@StefanW](#):
>
> ...wenn man mehrere Dateien mit verschiedenen Covern Markiert hatte, bei der Cover-Vorschau im Tag-Panel "Verschieden Cover" angezeigt...

Meiner Ansicht nach ist das das normale Verhalten.  
Wenn du Dateien auswählst, die gar kein eingebettetes Cover haben, kann je nach Einstellung in  
Datei\>Optionen\>Tag-Panel\>Cover anzeigen  
und  
Datei\>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.

---

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [July 27, 2016, 4:28pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/4 "2016-07-27T16:28:46Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [July 28, 2016, 5:31pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/7 "2016-07-28T17:31:44Z")

</div>

> [@UniX90s](#):
>
> ... Womöglich ein Kompatibilitätsproblem mit bmp Dateien? Diese lassen sich nämlich auch nicht normal als Cover auswählen (die Standard Grafiken sind ja jpg, jpeg, png).

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.

---

<div class="post-metadata">

**Author:** ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)\
**Post date:** [July 28, 2016, 6:53pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/9 "2016-07-28T18:53:10Z")

</div>

> [@UniX90s](#):
>
> Ich nehme stark an, dass die irgendjemand dort platziert hat 😃  
> Aber mehr kann ich dir auch nicht sagen. Gibt's denn ne Möglichkeit trotz der nicht Unterstützung von bmp Dateien dieses Problem zu beheben?

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.

---

<div class="post-metadata">

**Author:** ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)\
**Post date:** [July 30, 2016, 12:19pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/11 "2016-07-30T12:19:03Z")

</div>

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](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.

---

<div class="post-metadata">

**Author:** ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)\
**Post date:** [July 30, 2016, 1:44pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/12 "2016-07-30T13:44:28Z")

</div>

> [@UniX90s](#):
>
> Das lässt sich zwar machen, aber ist umständlich wenn man ein Haufen von Bildern im bmp Format hat. Eine andere Lösung wie bmp Unterstützung gibt bzw wird es nicht geben?

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.

---

<div class="post-metadata">

**Author:** ![UniX90s](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/u/46a35a/32.png) [@UniX90s](https://community.mp3tag.de/u/UniX90s)\
**Post date:** [July 31, 2016, 5:34pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/13 "2016-07-31T17:34:02Z")

</div>

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

---

<div class="post-metadata">

**Author:** ![mUbmde](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/6de8d8/32.png) [@mUbmde](https://community.mp3tag.de/u/mUbmde)\
**Post date:** [August 14, 2016, 12:17pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/14 "2016-08-14T12:17:09Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)\
**Post date:** [August 14, 2016, 3:27pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/15 "2016-08-14T15:27:39Z")

</div>

> [@mUbmde](#):
>
> Das war bisher nicht so, und meiner persönlichen Meinung nach kann das auch kein Feature sein, wenn bestehende Informationen unbeabsichtigt überschrieben werden.

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?

---

<div class="post-metadata">

**Author:** ![mUbmde](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/6de8d8/32.png) [@mUbmde](https://community.mp3tag.de/u/mUbmde)\
**Post date:** [August 18, 2016, 8:00am UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/17 "2016-08-18T08:00:56Z")

</div>

> [@UniX90s](#):
>
> Ich gehe stark davon aus das sich mUbmde nicht den Thread komplett durchgelesen hat und sein Problem ebenfalls mit bmp Dateien zusammenhängt. Ich halte es für eine gute Idee diesen Thread als "gelöst" zu deklarieren, bis jemand erneut ein Problem hat, das nicht auf bmp Dateien zurückzuführen ist.

Selbstverständlich habe ich den Thread komplett durchgelesen und ich habe mich auch daraufhin erstmals mit der Import/Export Methode vertraut gemacht. 🙂  
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.

---

<div class="post-metadata">

**Author:** ![mUbmde](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/6de8d8/32.png) [@mUbmde](https://community.mp3tag.de/u/mUbmde)\
**Post date:** [August 18, 2016, 8:11am UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/18 "2016-08-18T08:11:36Z")

</div>

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 😉

---

<div class="post-metadata">

**Author:** ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)\
**Post date:** [August 18, 2016, 8:29am UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/19 "2016-08-18T08:29:53Z")

</div>

> [@mUbmde](#):
>
> Vielleicht kommt ja doch noch irgendwann der bmp Support 😉

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.

---

<div class="post-metadata">

**Author:** ![mUbmde](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/m/6de8d8/32.png) [@mUbmde](https://community.mp3tag.de/u/mUbmde)\
**Post date:** [August 19, 2016, 3:15pm UTC](https://community.mp3tag.de/t/problem-mit-verschiedenen-cover-bei-bearbeitung-mehrer-dateien/18099/20 "2016-08-19T15:15:24Z")

</div>

> [@poster](#):
>
> 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.
