# \[X\] Erkennung von Duplikaten bei Aktion Album-Cover exportieren

**URL:** https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419
**Category:** Fehlermeldungen
**Created:** [March 9, 2008, 9:44pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419 "2008-03-09T21:44:43Z")
**Posts on this page:** 16
**Page:** 1

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 9, 2008, 9:44pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/1 "2008-03-09T21:44:43Z")

</div>

Auch wenn mehr Coverbilder in einer MP3 Datei gespeichert sind werden maximal nur sechs Coverbilder exportiert. Ist das richtig so?

DD.20080309.2344.CET

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 9, 2008, 9:49pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/2 "2008-03-09T21:49:18Z")

</div>

Es werden keine Duplikate exportiert.

Viele Grüße,  
Florian

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 9, 2008, 11:29pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/3 "2008-03-09T23:29:49Z")

</div>

> [@Florian](#):
>
> ... Es werden keine Duplikate exportiert. ...

Hmm, das stimmt nicht so ganz ... drei Bilder dreimal eingespeichert, also insgesamt 9 Bilder, beim Exportieren werden dann 7 Bilder ausgegeben.  
Beispiel: Moderation: Removed url.

DD.20080310.0130.CET

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 10, 2008, 6:34pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/4 "2008-03-10T18:34:05Z")

</div>

Danke. Ich werde das zur nächsten Version so ändern, dass wirklich nur 3 Cover exportiert werden.

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 10, 2008, 6:45pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/5 "2008-03-10T18:45:24Z")

</div>

Florian ... hmm ... warum gibst du denn nicht alle Bilder aus ohne Rücksicht auf Ähnlichkeiten?  
Das würde doch niemand ernsthaft stören.

Und außerdem merkt man dann auch eher, dass man überhaupt Doppelte gespeichert hat.  
Vielleicht sind Duplikate gelegentlich sogar erwünscht?

Also das mit dem festgezurrten Unterdrücken von Duplikaten finde ich gar nicht gut.

Dann wäre doch eine Sytemoption vielleicht ganz angebracht, mit der man als Anwender steuern kann, ob man alle Bilder, also inklusive eventueller Duplikate, (all pictures) entladen haben möchte, oder nur die 'einzigartigen' Bilder (unique pictures).

Gruß  
Detlev  
DD.20080310.1040.CET

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 10, 2008, 6:52pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/6 "2008-03-10T18:52:19Z")

</div>

Also eine Option wird es dafür wohl nicht geben.

Allerdings ist es kein Problem die Erkennung von Duplikaten auch einfach zu entfernen. Ich dachte damals beim Implementieren dieser Aktion einfach, dass es ganz hilfreich sein kann, sehe das jetzt allerdings auch in einem etwas anderen Licht.

Viele Grüße,  
Florian

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 11, 2008, 6:32am UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/7 "2008-03-11T06:32:22Z")

</div>

> [@Florian](#):
>
> ... Also eine Option wird es dafür wohl nicht geben. ...

Na gut, dann lass' die Duplikaterkennung in Zukunft weg.

DD.20080311.0832.CET

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 15, 2008, 7:40pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/8 "2008-03-15T19:40:24Z")

</div>

Ist mit dem aktuellen [Development Build v2.40a](http://developer.mp3tag.de) nun geändert.

Viele Grüße,  
Florian

---

<div class="post-metadata">

### Author: ![dano](https://community.mp3tag.de/user_avatar/community.mp3tag.de/dano/32/6_2.png) [@dano](https://community.mp3tag.de/u/dano)
#### Post date: [March 15, 2008, 8:23pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/9 "2008-03-15T20:23:17Z")

</div>

Das ist doch nicht gut wenn bei einem Album bei dem jeder Track das gleiche Bild hat, jetzt so viele Bilder wie Tracks entstehen statt nur einem.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 15, 2008, 8:41pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/10 "2008-03-15T20:41:40Z")

</div>

Das stimmt natürlich! (Ich wusste doch, dass es einen Grund für die Duplikateerkennung gab).

Ich werde diese Änderung zur nächsten Version wieder rückgängig machen.

Viele Grüße,  
Florian

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 15, 2008, 9:58pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/11 "2008-03-15T21:58:54Z")

</div>

> [@Florian](#):
>
> ... Ich werde diese Änderung zur nächsten Version wieder rückgängig machen. ...

Stop!

1. 

Es scheint wohl wirklich besser zu sein, die Export Funktion mit einer Systemoption modifizierbar zu machen.  
Wie ich schon vorgeschlagen hatte:

- export all images from all files from one folder
- export all images from all files excluding true duplicates within one folder

Die Duplikaterkennung sollte im Detail auch so sorgfältig sein, dass z. B. ein Image mit Beschriftungstext (Kommentar oder so) von demselben Image ohne Beschriftungstext unterschieden wird, was zurzeit nicht gewährleistet ist.

Im Übrigen sollte man auch berücksichtigen, dass durchaus in den Tracks eines Albums je Track andere images oder unterschiedliche sets von images gespeichert sein können.  
Dabei können, müssen aber nicht, beim Exportieren nicht unbedingt zwangsläufig doppelte images entstehen.  
Wie schon gesagt, wie soll man Duplikate aufspüren können, wenn man sie nicht exportieren kann, und Mp3tag für Imagekenndaten auch keine internen Werkzeuge oder Informationen zur Verfügung stellt?

1. Neuer Bug.  
Aufgrund der mit 2.40a 'vereinheitlichten' Dateinamenerzeugung werden die Images nun nicht mehr in der Reihenfolge ihrer Speicherung ausgegeben, sondern typweise, also z. B. erst alle png und dann alle jpg images.  
Das ist für nachfolgende externe Batchbearbeitungen selbstverständlich **unbrauchbar** , weil diese sich darauf verlassen müssen, dass entweder die zeitliche Reihenfolge oder die Nummerierung der Erzeugung von externen cover images der örtlichen Reihenfolge der Speicherung im jeweiligen Track entspricht, z. B. soll bei der gespeicherten Reihenfolge: jpg-png-png-jpg dann die Ausgabereihenfolge erzeugt werden mit diesen Dateinamen: "x(0).jpg"-"x(1).png"-"x(2).png"-"x(3).jpg".

Weil die Reihenfolge der gespeicherten cover im jeweiligen Track durchaus unterschiedlich sein kann (willentlich oder nicht), sollte die Exportoption '- export all images from all files within a folder' es ermöglichen, diese eventuellen Unstimmigkeiten erkennbar zu machen.  
Mit eingeschalteter Duplikatunterdrückung sind 'image-Dreher' oder 'image-Doppel' (auch visuell) nicht mehr zu erkennen.

DD.20080315.2358.CET

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 16, 2008, 7:05am UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/12 "2008-03-16T07:05:47Z")

</div>

> [@DetlevD](#):
>
> Es scheint wohl wirklich besser zu sein, die Export Funktion mit einer Systemoption modifizierbar zu machen.

Mir leuchtet immer noch nicht ein, warum man dafür unbedingt eine Option braucht.

> [@](#):
>
> Die Duplikaterkennung sollte im Detail auch so sorgfältig sein, dass z. B. ein Image mit Beschriftungstext (Kommentar oder so) von demselben Image ohne Beschriftungstext unterschieden wird, was zurzeit nicht gewährleistet ist.

Und wie sollte eine solche Unterscheidung aussehen?

> [@](#):
>
> Im Übrigen sollte man auch berücksichtigen, dass durchaus in den Tracks eines Albums je Track andere images oder unterschiedliche sets von images gespeichert sein können.

Diese wurden ja auch ohne weiteres in der vorherigen Version exportiert.

Mich würde interessieren, inwiefern die hier vorgestellte Problematik der Realität entspricht oder einfach ein synthetisches Konstrukt ist, das aus einem intensiven Test der Funktionalität entstanden ist?

> [@](#):
>
> 1. Neuer Bug.  
> Aufgrund der mit 2.40a 'vereinheitlichten' Dateinamenerzeugung werden die Images nun nicht mehr in der Reihenfolge ihrer Speicherung ausgegeben, sondern typweise, also z. B. erst alle png und dann alle jpg images.

Ja, das ist genau das, was Du als Verbesserung des Features vorgeschlagen hattest ![<_<](https://community.mp3tag.de/uploads/default/original/1X/5996dbb474c88b8f9fc49f09dc3858d081055a2d.gif "<\_<")

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 16, 2008, 7:59pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/13 "2008-03-16T19:59:59Z")

</div>

> [@Florian](#):
>
> Mir leuchtet immer noch nicht ein, warum man dafür unbedingt eine Option braucht.

Systemoption oder Modifier via Radiobutton im Exportdialog ist eigentlich gleich - Hauptsache zwei unterschiedliche Verhaltensweisen, um unterschiedliche Dinge tun zu können. Siehe Bemerkung von Dano betreffend 'Multiple Similars'.

> [@Florian](#):
>
> (Duplikaterkennung) Und wie sollte eine solche Unterscheidung aussehen?

Tja, da bist du als Experte eher gefragt.  
Ich habe eine Datei zum Test bereitgestellt, deren erstes und zweites Bild sehr wahrscheinlich identisch ist, mit der Ausnahme, dass das zweite Bild einen Kommentar enthält. Ein solches Päärchen sollte eigentlich als zwei unterschiedliche Bilder erkannt werden, wegen des darin enthaltenen Unterschieds im eingelagerten Kommentar.  
Beispiel: [http://hpdd.de/Mp3tag/17\_Massaker\_DrSeltsa...a\_FFUM\_1980.mp3](http://hpdd.de/Mp3tag/17_Massaker_DrSeltsamPropaganda_FFUM_1980.mp3)

> [@Florian](#):
>
> Diese wurden ja auch ohne weiteres in der vorherigen Version exportiert.

??? Möglich, aber die von deinem Algorithmus erkannten Duplikate wurden unterdrückt, deshalb wurden bei unterschiedlich gespeicherter Reihenfolge wiederum 'zufällig' unterschiedliche sets erzeugt.

> [@Florian](#):
>
> Mich würde interessieren, inwiefern die hier vorgestellte Problematik der Realität entspricht oder einfach ein synthetisches Konstrukt ist, das aus einem intensiven Test der Funktionalität entstanden ist?

Gute Frage, hmm, du hast bestimmt im Forum gesehen, dass ich ein Werkzeug gebaut habe 'Cover Dimension Identify', das bestimmte Kenndaten von exportierten images einsammelt und in die Tracks speichert. Dieses Werkzeug war notwendig geworden, weil Mp3tag diese image Kenndaten nicht selbst bereitstellt (noch nicht?). Damit dieses Werkzeug richtig funktionieren kann, ist es unerlässlich, dass images in der Reihenfolge exportiert werden, wie sie im Track gespeichert sind, sonst können die extern ermittelten Kenndaten den im Track gespeicherten images nicht ordnungsgemäß zugeordnet werden.  
Damit dieses Werkzeug sinnvoll funktionieren konnte, musste ich schon um Dateinamen Sonderlichkeit von Mp3tag und Sortierungsfehler von DOS herumarbeiten, was zuletzt (mit Ausnahme der fehlenden Duplikate) auch recht gut lief. Auf disen workaround kann man verzichten wenn von vornherein die Dateinamen mit sinnvoller sortierfähiger Indexierung erzeugt werden.

> [@Florian](#):
>
> Ja, das ist genau das, was Du als Verbesserung des Features vorgeschlagen hattest ![<_<](https://community.mp3tag.de/uploads/default/original/1X/5996dbb474c88b8f9fc49f09dc3858d081055a2d.gif "<\_<")

Sorry, wenn es hierbei zu einem Missverständnis gekommen ist. Ich versuche es nochmal mit anderen Worten zu erklären.  
Benötigt wird der Export von images in der Reihenfolge ihrer Speicherung im Track, unabhängig von ihrem imagetype, so dass zweifelsfrei erkennbar ist, dass die eine Bilddatei das erste image ist und das die andere Bilddatei das zweite image ist, usw. bis zum letzten image, und die Dateinamen sollen mittels DOS SORT oder DOS DIR /o-n fehlerfrei sortierbar sein.

Beispiel:  
Images im Track x.mp3:  
jpg-png-png-jpg-gif-jpg.

Export ins Dateisystem:  
x.1.jpg, x.2.png x.3.png, x.4.jpg, x.5.gif x.6.jpg.  
oder  
x.jpg, x(1).png x.(2).png, x.(3).jpg, x.(4).gif, x.(5).jpg.

Hierbei kann ich mir sogar noch die Optionen vorstellen, ob von 0 oder von 1 an gezählt werden soll, und ob bei der ersten Datei ein Index mitgeliefert werden soll oder nicht, und wie der Index aussehen soll (simpel '.n' oder dekoriert '(n)'.

Florian, es wäre echt gut, wenn du da etwas hinbekommen könntest, was allgemeingültig und systematisch funktioniert. Ich habe nämlich alle meine Tracks bzw. die darin gespeicherten images mit dem 'Cover Dimension Identify' Werkzeug 'durchleuchtet', was mich schließlich zu neuen Erkenntnissen und Änderungsabsichten betreffend der gespeicherten images geführt hat, z. B. in bezug auf Kantenmaße oder Bildqualität oder sogar auf abweichenden imagetype (falscher APIC frame).

Viele Grüße  
Detlev

DD.20080316.2200.CET

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 25, 2008, 7:48pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/14 "2008-03-25T19:48:07Z")

</div>

Der aktuelle [Development Build](http://developer.mp3tag.de) v2.40b sollte das Problem beheben.

Viele Grüße,  
Florian

---

<div class="post-metadata">

### Author: ![DetlevD](https://community.mp3tag.de/user_avatar/community.mp3tag.de/detlevd/32/123_2.png) [@DetlevD](https://community.mp3tag.de/u/DetlevD)
#### Post date: [March 26, 2008, 12:59pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/15 "2008-03-26T12:59:54Z")

</div>

Ja, das funktioniert jetzt gut!

Viele Grüße  
Detlev

D.20080326.1500.CET

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [March 26, 2008, 5:53pm UTC](https://community.mp3tag.de/t/x-erkennung-von-duplikaten-bei-aktion-album-cover-exportieren/6419/16 "2008-03-26T17:53:30Z")

</div>

> [@DetlevD](#):
>
> Ja, das funktioniert jetzt gut!

Das freut mich 🙂 Danke für die Rückmeldung!

Viele Grüße,  
Florian
