Auch wenn mehr Coverbilder in einer MP3 Datei gespeichert sind werden maximal nur sechs Coverbilder exportiert. Ist das richtig so?
DD.20080309.2344.CET
Es werden keine Duplikate exportiert.
Viele Grüße,
Florian
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
Danke. Ich werde das zur nächsten Version so ändern, dass wirklich nur 3 Cover exportiert werden.
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
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
Na gut, dann lass' die Duplikaterkennung in Zukunft weg.
DD.20080311.0832.CET
Ist mit dem aktuellen Development Build v2.40a nun geändert.
Viele Grüße,
Florian
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.
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
Stop!
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?
- 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
Mir leuchtet immer noch nicht ein, warum man dafür unbedingt eine Option braucht.
Und wie sollte eine solche Unterscheidung aussehen?
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?
Ja, das ist genau das, was Du als Verbesserung des Features vorgeschlagen hattest 
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'.
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
??? Möglich, aber die von deinem Algorithmus erkannten Duplikate wurden unterdrückt, deshalb wurden bei unterschiedlich gespeicherter Reihenfolge wiederum 'zufällig' unterschiedliche sets erzeugt.
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.
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
Der aktuelle Development Build v2.40b sollte das Problem beheben.
Viele Grüße,
Florian
Ja, das funktioniert jetzt gut!
Viele Grüße
Detlev
D.20080326.1500.CET
Das freut mich 
Danke für die Rückmeldung!
Viele Grüße,
Florian