Cover-Export ohne Duplikate?

Ich steige da nicht durch.
In der Aktion "Cover in Datei exportieren" kann man neben dem Namen auch festlegen, ob es Duplikate geben soll oder nicht.

Wenn man nun Cover exportiert mit dem beliebten Namen "folder.jpg", dann findet man anschließend überraschenderweise in ganz vielen Ordnern Dateien mit dem Muster
Folder(1).jpg
Folder(2).jpg
auch wenn die Option, Duplikate anzulegen, abgewählt war. Ich hatte das bisher immer so interpretiert, dass dann auch wirklich nur eine Datei
folder.jpg
entsteht, und eine ggf. schon existierende Datei folder.jpg überschrieben wird.
Dem ist aber nicht so.
Es bleibt die alte folder.jpg erhalten und es entsteht aus dem Export eine Datei
folder(1).jpg
Wenn jetzt auch noch unterschiedliche Dateien eingebettet waren, gibt es entsprechen mehr Indizes.
Ist das so gewollt?
Wie kann ich einstellen, dass bei einem konstanten Dateinamen auch wirklich nur 1 Datei mit diesem Namen am Ende im Verzeichnis steht?

Das ist nach meiner Erfahrung nur dann der Fall, wenn das eingebettete Bild nicht dem schon als Datei vorhandenen entspricht (z.B. unterschiedliche Größe).
Bei identischen Bildern wird keine 2 Datei angelegt.

Ja. Genau so. Nur bleibt dann leider das alte Bild erhalten und das gerade frisch exportierte kriegt den Sondernamen. So ganz entspricht das nicht den Angaben des Benutzers. Und deshalb habe ich auch die Probleme mit der Interpretation der Option "Ohne Duplikate". Denn so bekomme ich immer Duplikate, wenn es schon eine Datei im Ordner gibt.
Wieso wird die nicht einfach überschrieben?

Ist halt eine Definitionsfrage des Begriffs "Duplikat", für den ja nicht ausschließlich der Dateinamen relevant ist sondern eher der Inhalt der Datei.
Wenn Du meinen Namen annimmst, wirst Du ja eigentlich nicht ein Duplikat von mir. :wink:

Wohl wahr. :wink: Allerdings würde das System nicht unterscheiden können, ob an der Tastatur ohrenkino oder poster säße. Und so würde ich es auch von Mp3tag erwarten.

Also: wenn ich einen fixen Dateinamen wähle, dann doch vermutlich mit der Absicht, dass die bestehenden Dateien überschrieben werden. Nur genau das passiert eben nicht. Sollte sich die bestehende Datei von der neu zu erzeugenden unterscheiden, dann bleibt die alte mit dem ursprünglichen Namen erhalten und es wird eine neue mit diesem Index-Namen angelegt.
Ja, in dem Sinne kein Duplikat, aber sinnvoll ist es m.E. nicht. Denn das Dateisystem würde es doch immer wieder gestatten, die bestehende Datei ohne zu Mucken zu überschreiben. Nur in MP3tag guckt jetzt irgendein Mechanismus nach, ob es eine Datei gleichen Namens gibt und legt dann eine neue an.
Faszinierenderweise bleibt die alte Datei übrigens auch erhalten, wenn sich vorhandene und neu anzulegende nicht unterscheiden. Also nicht mal da klappt das mit dem Überschreiben ...
Ich meine, da ist der Wurm drin.

Der Workaround ist natürlich, zuerst mal alle folder.jpg zu löschen, um sie dann neu anzulegen. Aber ist das so gewollt?

Letztlich beruhigt es mich, dass andere diese Beobachtung auch gemacht haben.

In der Tat wird bei gleicher Datei die vorhandene Datei nicht überschrieben und es wird auch das Änderungsdatum nicht neu gesetzt. In dem Fall wird offensichtlich die Aktion einfach ignoriert, denn ich kann mir nicht vorstellen, dass einfach nur der Zeitstempel beibehalten wird.

Anders verhält es sich beim manuellen Exportieren Cover/Rechte Maustaste/Cover-Exportieren.
Da wird nach einer Bestätigung für das Überschreiben verlangt und nach erfolgter Bestätigung wird das Änderungsdatum neu gesetzt.