Nachdem Detlev vor ein paar Tagen auf ein Post von mir kritische Hinweise gab, habe ich mal hier mein Wissen zusammengestellt, wie was funktioniert und wie man Cover verlieren kann, was aber Anwenderfehler ist!
Annahme für die weiteren Hinweise:
- Aktion Coverimport c:\xyz.jpg und Option exitstierende Cover löschen gewählt
- Aktion Coverimport c:\xyz(1).jpg und keine Option exitstierende Cover löschen
- Aktion Coverimport c:\xyz(2).jpg und keine exitstierende Cover löschen gewählt
1. Anwender Fehlermöglichkeit: nur einmal Option ex. Cover löschen wählen
Wer bei 2. und 3. die Option löschen wählt, der behält nur das Cover mit dem höchsten Index, weil vor jedem einzeln Import jeweils alle Cover gelöscht werden (ist auch logisch). Also bei der 1. Aktion im exist. Cover löschen, danach nicht mehr (ausführlicheres Post dazu gibt's von mir auch noch, bitte suchen).
2. Anwender Fehlermöglichkeit unvollständiger Export von exist. Covern
Ein Anwender exportiert manuell nur eines von mehreren Covern eines Tracks (z.B. via ALT T und dann Cover speichern).
Szenario 1
Er exportiert nur das 1 cover xyz.jpg und aktualisiert es mit einem neuer oder verkleinert es.
Wenn er nun die o.g. Importaktionsgruppe aufruft, werden die existierenden Cover gelöscht und alle auffindbaren, hier also nur das 1. importiert.
Ergebnis: Das 2. und 3. Cover unwiderruflich verloren (ggf. hat man ja ne Sicherung)
Szenario 2
Er exportiert nur das n. cover (aber nicht das erste) also z.B. xyz(1).jpg und verändert es.
Mit der Importaktion passiert folgendes: Es wird eine Änderung des Covers festgestellt. Demzufolge wird es hinzugefügt, besser gesagt, hinten angefügt.
Da für das n. Cover die Option löschen nicht aktiv ist.
Ergebnis: Die Coverliste wird länger, da so nicht korrekt aktualisiert werden kann.
Szenario 3
Er erstellt das Cover xyz(4).jpg und führt den Import aus.
Ergebnis: wie bei Szenario 2 wird die Liste verlängert, also ein Cover angefügt.
Szenario 4
Anwender exportiert Cover und aktualisiert gelegentlich einzelne jpg und importiert nicht sofort. In der Zwischenzeit hat er nen Tippfehler im Tagfeld festgestellt und aus dem Artist x macht er in MP3Tag oder in itunes oder foobar den Artist WOLLE.
Wenn nun mal wieder einige Tage später die Aktion zum Import aufgerufen wird, dann wird bei ehemaligen xyz.mp3, der nun Wolleyz.mp3 ist, kein Coverimport durchgeführt, da die gesuchte Datei wollyz.jpg nicht existiert. Dazu müßte also alle cover xyz bis xyz(n) umbenannt werden in Wolleyz bis Wolleyz(n).
3. Anwender Fehlermöglichkeit vor Version 2.37
Wer dieses Szenario in der Vergangenheit, als es Cover löschen noch nicht gab, mit dem Workaround gelöst hat, vor den Importaktionen eine Aktion Tag löschen PICTURE einzusetzen, der konnte richtig Probleme haben, sprich Cover verlieren.
Warum? Die Cover wurden immer gelöscht, unabhängig davon, ob es passende Importcover gab und somit kann es Verluste geben, wenn nicht für alle selektierten Tracks alle Cover mit richtigem Namen vorliegen!
Bei Szenarien 1 bis 3 wurde nur jeweils das im Dateisystem vorhandene Cover behalten, alles andere war weg! Bei Szenario 4. bSpeziell bei den Szenarien 2 und 3 hatte es ebenfalls immer Coververluste gegeben, da ja nur ein
Nun gab es Hinweise, daß Cover verloren gingen oder nicht importiert werden. Daher habe ich die folgenden Szenarien mit o.g. Aktionen durchgeführt.
4. Anwender Fehlermöglichkeit am Beispiel itunes
Die Cover werden im Tag PICTURE als MIME Dateien im abgelegt, was bedeutet, dass im Track eine richtige Bild Datei in der MP3 Datei (oder auch mehrere) liegen kann. Spannend aber auch gefährlich. Warum?
Beim Import habe ich immer jpg angenommen, aber in dem Cover Tag könnten auch andere Dateiformate liegen, wie z.B. png oder jpg. Wie das? Bei itunes kann man z.B. Cover per Copy & Paste über Zwischenablage einfügen, also im Grafikprogramm was markieren und in itunes einfügen. Das wird alles dann abgelegt und itunes verwendet z.B. das unkomprimierte PNG Format, man kann aber auch BMP Dateien via Drag & Drop in itunes einfügen. Ende der langen aber wichtigen Vorrede.
Wenn solche BMP oder PNG in den Tracks enthalten sind, passiert bei der o.g. Covergeschichte immer folgendes. Sollte das 1. Cover ein jpg sein und geändert werden, so werden alle Cover gelöscht und das jpg importiert, die weitern png oder bmp sind verloren.
Sollten die BMP oder PNG im Dateisystem aktualisiert werden, so werden diese nicht importiert, weil die o.g. Aktionen immer auf xyz().jpg setzen und nicht xyz().png/bmp/... OK, die Dateien sind noch da, aber sie werden nicht importiert und früher oder später wird jemand diese vielen kleine Grafik Dateien löschen und dann sind die wirklich weg! Ich spreche aus erlebter & leidvoller Erfahrung, obschon ich in 99% noch MP3 Backup hatte und da was retten konnte! Und ehrlich gesagt war ich auch immer mal wieder am Zweifeln, ob MP3Tag das wohl richtig macht - aber all das ist reproduzierbar.
Wie vermeide ich Coververluste?
- Immer für alle selektierten Tracks (nach Möglichkeit Playlist erstellen, damit ggf. später noch Korrekturen eingearbeitet werden könnten) Cover exportieren
- Cover aktualisieren, neue Cover mit Index () erstellen
- keine Tagänderungen (weder Titel noch Artist, was in der Regel die Keys sind) bis zum Import vornehmen
- Vor dem Import nur die Songs selektieren, für die zuvor importiert wurde (zur Sicherheit).
- Letzer Check, ob für jeden indizierten Track mit xyz(n).jpg auch ein xyz.jpg und ggf. weitere xyz(n).jpg vorhanden sind (um Verlust oder Doppelungen zu vermeiden).
- Import durchführen und mit den zusätzlichen Spalten Coversize und Coverzahl diese sortieren und drüberschauen. Wenn man zuvor für alle Tracks Cover hatte, dann sollte es jetz auch so sein. Bei großer Coverzahl mal prüfen, ob das so korrekt ist.
- kein Einsatz von Tag entfernen PICTURE, weil hier immer alle Cover gelöscht werden und das nur funktioniert, wenn zuvor immer alle Tags exportiert wurden und 100% nichts umbenannt wurde.
- Die Cover in einem Extraverzeichnis für Cover schön sichern und behalten. Meist stellt man erst nach Tagen fest, das etwas schief gelaufen ist bzw. Cover fehlen (meistens alle).
- Ich habe noch ein Verzeichnis für die exportierten Cover. Dort bearbeite ich dann die Cover mit Irfan und Irfan speichert die überarbeiteten beim Speichern in ein Importverzeichnis, von wo MP3TAG importiert.
Much fun beim cover tagging .... ach ja, ich hatte noch einen Bock geschossen, in dem ich, was manchmal bei ner Suche hilfreich ist, immer beim Export
Artist - Album - Track.jpg gewählt. Das macht manuelle Suchen (amazon und co. sind doch eher fraglich) aufwendig, weil beim Kopieren der Suchbegriffe für Google Bildersuche oder discogs immer das Album entfernt werden muß (für die Suche nach singles, wer nach Alben sucht, der entferne die Tracks und nach Möglichkeite keine "-" als Trenner, die man hier eh nicht braucht!
Demzufolge sieht die Ex/Importaktion bei mir so aus (es werden noch unzulässige Zeichen aus Title & Artist enternt wie das in good old Germany beliebte ? nach Warum?, denn Warum? ist als Dateiname unzulässig und wird zu Warum
Export Cover
C:\MP3\Cover Export$replace($validate(%artist% %title%,),.,) => ohne Dateierweiterung, weil die enthaltenen MIME Dateien dies vor/mitgeben
Import Cover
C:\MP3\Cover Import$replace($validate(%artist% %title%,),.,).jpg
Ich importiere nur jpg und verwende nichts anderes. In MP3Tag kann man eine Spalte anlegen, die die enthaltenen Cover MIME Typen anzeigt und danach sortieren. Ich habe so alle PNG & BMP ersetzt und erstelle neue Cover nur auf einem Weg als jpg!