In meinen WAV-Dateien werden regelmäßig Image- / Bild-Chunks zerstört. Was von der Graphik übrigbleibt, sind dann nur noch Streifen. Es gibt freilich noch andere Verdächtige im Raum (u. a. Lesezugriffe von FFmpeg, Robocopy und Total Commander). Gibt es hier Erfahrungen?
Der Test für Mp3tag ist relativ einfach:
Lade eine WAV-Datei in Mp3tag.
Füge ein Cover hinzu.
Speichere die Änderung.
Schliesse Mp3tag.
Lade die eben veränderte WAV-Datei erneut in Mp3tag.
Wenn das Bild korrekt dargestellt wird, kann man Mp3tag als Ursache ausschliessen.
Wenn Du reproduzierbare Schritte für die "Zerstörung von Artwork" in Mp3tag für WAV nennen kannst, können wir das gerne entsprechend testen.
Hallo, LyricsLover, danke für deine schnelle Antwort!
Beobachtung 1: Beim Neu-Einbinden des Artwork kam eine Fehlermeldung
Beobachtung 2: Wenn man "Wiederholen" wählte, ging es dann doch.
Beobachtung 3: Grafik neu einfügen -> mp3tag schließen -> mp3tag wieder öffnen -> Grafik unbeschädigt. Was wohl gegen mp3tag als Verursacher spricht.
Ich hatte mp3tag in Verdacht, weil es drei Dateien waren, von denen ich zwei mit mp3tag editiert hatte (Genre); die dritte Datei hatte ich übersehen = nicht verändert. Die Graphik-Chunks in den editierten Dateien waren kaputt, der Graphik-Chunk in der übersehenen Datei war noch intakt.
Die Dateien stammen von Qobuz, hatten also werkseitig eingepflegte Artworks.
Wenn Du reproduzierbare Schritte für die "Zerstörung von Artwork" in Mp3tag für WAV nennen kannst, können wir das gerne entsprechend testen.
Reproduzieren ist mir bislang nicht gelungen; bei über 22000 Dateien kommt man nur per Zufall und viel später drauf, da liegen Monate dazwischen.
Gruß, Alexander Behrens
Ist Dein Laufwerk F: eine externe USB-Festplatte?
Wenn ja, wie angeschlossen? USB 2.0? USB 3.0?
Bei sehr grossen WAV-Dateien könnte es sein, dass dieses Zusammenspiel einen Einfluss hat, weil die gesamte WAV-Datei erst davon gelesen und dann verändert (mit dem Cover-Bild) komplett neu geschrieben wird.
Du könntest testen, ob das Problem auch auftritt, wenn Du die WAV-Datei zuerst auf einen schnellen internen Speicher wie eine interne SSD kopierst. Dann von der SSD in Mp3tag lädst, veränderst und wieder speicherst. Das gibt zwar zusätzlichen Aufwand, hilft aber bei der Ursachen-Suche, weil damit der Weg von/zur externen Platte und die externe Platte selber ausgeschlossen werden können.
Kannst Du garantieren, dass das eingepflegte Artwork "korrekt" eingepflegt wurde?
Wird das Cover direkt nach dem Download von der Quelle und laden in Mp3tag richtig angezeigt?
- ja: externe HDD, exFAT, USB 3.0
Kannst Du garantieren, dass das eingepflegte Artwork "korrekt" eingepflegt wurde?
- nein, das kann ich nicht; die Dateien, vermute ich, werden auch von den Verlagen ausgeliefert, und Qobuz ist nur ein Händler; also wird u. U. jeder eine andere Qualität liefern. Aber ich weiß es nicht.
Wird das Cover direkt nach dem Download von der Quelle und laden in Mp3tag richtig angezeigt?
- ja! Der Verlust stellt sich erst später ein. Ich habe mal die korrupten Dateien mit einem Hex-Editor angeguckt: Die jpg-Datei bricht da in der Mitte ab, keine End-of-File-Sequenz (FF D9).
Solange es nur die Grafik-Chunks sind, würde mich das nicht sonderlich stören, aber was ist, wenn auch Audiodaten betroffen sind ...
Das vorrangige Ziel muss meiner Meinung nach das Finden der Quelle für die "Zerstörung der Artwork" sein. Welches Tool verändert in welchem Schritt das Cover-Bild so, dass es defekt zurückgeschrieben wird?
Für den Audio-Teil kann Dir Mp3tag nicht helfen. Mp3tag kümmert sich nur um die Metadaten drumherum, niemals um die Musik selber.
Dann würde ich versuchen rauszufinden, welche Tools zuletzt an dieser defekten Datei manipuliert haben.
Mit Ausnahme von mp3tag benutze ich Anwendungen nur lesend:
- FFmpeg
- VLC
- Total Commander
- Robocopy
Ärgerlich wäre, würde Windows oder ein Antivirenprogramm im Hintergrund dran herummachen.
- das ist natürlich interessant; muss ich beobachten!
Vielen Dank erst einmal für deine Ideen, ich werde es weiter beobachten!
Alexander Behrens
Es wäre fair, wenn Du den Titel ein wenig entschärfen könntest auf sowas wie:
Zerstört Mp3tag Artwork in WAV-Dateien?
Weil ohne reproduzierbare Schritte ist das bisher erst eine nicht belegte Behauptung.
Ich will damit nicht sagen, dass Mp3tag 100% fehlerfrei ist und 100% garantiert nicht die Ursache ist. Aber zur einer eindeutigen Fehlermeldung würde auch die Nachvollziehbarkeit gehören.
Gut, habe es geändert. Ich hatte, um nichts zu unterstellen, bewusst eine Passivkonstruktion genommen (ohne Erwähnung von mp3tag), aber es sollen natürlich keine Missverständnisse aufkommen. Danke noch einmal für deine Unterstützung!
Das klingt fast so, als würden bei Veränderung von Metadaten auch die Audiodaten neu geschrieben?
Das komplette WAV wird neu geschrieben (mindestens, wenn es bisher noch kein Cover gab oder das neue Cover deutlich grösser als das bisherige ist).
Aber der Audio-Teil bleibt dabei unverändert.
(Man kann eindeutig zwischen dem Metadaten-Teil und dem Audio-Teil unterscheiden. Die Wahrscheinlichkeit, dass Mp3tag etwas am Audio-Teil verändert ist extrem gering. Wenn dem trotzdem so wäre, könnte man das problemlos nachvollziehen.)
Meine Vermutung geht eher in Richtung USB-Übertragung und USB-Datenträger inkl. ExFat.
Ja, das werde ich beobachten. Aber: Wenn das komplette WAV geschrieben wird und USB laggt, deswegen der Schreibvorgang abgebrochen wird - sind dann nicht auch die Audio-Daten betroffen?
Wäre NTFS zu bevorzugen?
Ich kenne die konkret betroffenen Codestellen in Mp3tag nicht.
Deshalb kann ich nichts dazu sagen, was im Fehlerfall wie in Deinem Screenshot ganz genau abläuft.
Wenn man sich die Vorteile von NTFS durchliest, würde ich JA sagen.
Aber es kommt auch immer darauf an, in welcher Umgebung Du diese USB-Festplatte verwendest. Wenn z.B. Mac-Geräte darauf schreiben sollen, dann geht das mit NTFS meines Wissens nicht "einfach so".
OK, danke für deine Antwort!
Es gibt keine Berichte dieser oder ähnlicher Art.
Lesezugriffe sind an dieser Stelle höchstwahrscheinlich nicht an der Zerstörung der Daten beteiligt. Robocopy kopiert die Dateien, aber wenn sie schon in der Quelle fehlerhaft sind, wird es daran auch nicht liegen.
Evtl. kannst Du in diesem Fall Mp3tag beenden und findest unter %APPDATA%\Mp3tag\ eine Datei Mp3tagError.log in der Details zum Fehler stehen.
Lieber Florian, meine Mp3tagError.log ist praktisch leer.
================================================================================
Mp3tag v3.29 - 06.04.2025 - 16:06:35
--------------------------------------------------------------------------------
OS-Version: Windows 11 (build 26100), 64-bit
--------------------------------------------------------------------------------
Build: Mar 28 2025 13:54:50 (64-bit)
--------------------------------------------------------------------------------
AppPath: 339.615.440.896 Bytes frei (C:\Program Files\Mp3tag\)
DataPath: 339.615.440.896 Bytes frei (C:\Users\...\AppData\Roaming\Mp3tag\data\)
TempPath: 339.615.440.896 Bytes frei (C:\Users\...\AppData\Local\Temp\Mp3tag v3.29\)
================================================================================
Wenn man nach der Fehlermeldung einmal auf Wiederholen geklickt hat, war die Grafik auch dauerhaft in Ordnung. Offenbar hat mp3tag dann den abgehackten Bildblock durch einen vollständigen ersetzt.
Aber noch einmal zum Szenario "Rückschreiben der Daten wegen langsamer USB-Verbindung abgebrochen": Wenn auch bei der Änderung nur von Metadaten (z. B. Genre) die komplette Datei (also auch der Audio-Chunk) neu geschrieben wird ... Kann es passieren, dass dann wegen zu langsamer USB-Verbindung auch Audiodaten fehlen?
- OK, danke.
Ja, dort wäre auch nur etwas zu finden, nachdem Du nach Auftreten des Fehlers Mp3tag beendest und dann dort nachsiehst. Die Datei wird bei jedem Start von Mp3tag neu erstellt.
Ja, ich kann diesen Fall nicht ausschließen, habe das jedoch noch nie erlebt.
Ich weiß nicht, ob die USB-Vermutung an dieser Stelle zielführend ist. Die Verbindung müsste schon komplett abbrechen, oder andere Fehler produzieren. Eine nur langsame Verbindung schreibt ja immer noch Daten und USB3.0 ist alles andere als langsam.
Lieber Florian, danke für die Informationen! Betreffend den USB-Standard muss ich mich korrigieren - das letzte Änderungsdatum der betroffenen Dateien lässt auf einen älteren Computer mit USB 2.0 schließen. Aber das ist eben, wie du sagtest, nur langsam. Werde es weiter beobachten und im Falle einer Erkenntnis mich melden. Danke allerseits und Gruß von Alexander Behrens
Wie ist das eigentlich dann bei mp3-Dateien: Werden die beim Zurückschreiben nur kopiert, oder werden sie neukodiert, also ein weiteres Mal komprimiert?
Nein. Der Audioteil bleibt, wie er ist. Nur der Tag-Teil wird ggf. neu geschrieben, wenn das Padding nicht reicht.