Echt? Wenn LyricsLover schreibt, dass "die gesamte WAV-Datei erst davon gelesen und dann verändert (mit dem Cover-Bild) komplett neu geschrieben wird", dann wird WAV also anders behandelt als mp3?
Mir ist zu einem mir nicht bekannten Zeitpunkt in der Vergangenheit ein Malheur mit den Dateien passiert, was ich ab und zu an kaputtem Artwork sehe; aber hört man es auch ... RIFF, insbesondere der data-Chunk (enthaltend die Audiodaten) scheint nicht hinreichend genau spezifiziert zu sein. Jedenfalls finden solche Tools wie FFmpeg (ffprobe), aber auch Skripte mit pydub oder NumPy und Matplotlib entweder jede oder keine Datei kaputt.
Nein. Metadaten und Nutzdaten lassen sich sauber voneinander trennen. MP3tag ändert nur den Metadatenteil und fügt dann den Nutzdatenteil so an, wie er vorgefunden wurde.
Da die Metadaten an unterschiedlichen Stellen in den jeweiligen Dateitypen vorhanden sind, können Änderungen nicht einfach hinten angefügt werden, sondern manchmal muss auch der Platz vorne für die Metadaten vergrößert werden, so dass eine Datei neu angelegt und nicht einfach nur geändert wird.
Das hat aber eigentlich für dein Problem keine Relevanz, würde ich meinen. Es ist zuerst zu checken, ob die Dateien und Metadaten OK waren, bevor MP3tag die bearbeitet hat. Und wenn in MP3tag alles OK aussieht, müsste noch herausgefunden werden, was auf der Strecke bis zum Auftreten des Problems passiert ist. Sonst lässt sich das alles nicht nachvollziehen und analysieren.
Wann durch welchen Schreibvorgang mit welchem Programm etwas kaputt gegangen ist, bekomme ich nicht mehr reproduziert - es sind 22000 Dateien, und rein zufällig bekomme ich ab und zu ein kaputtes Artwork zu sehen. Ja, in einem alten Backup finde ich schon noch die eine oder andere Datei mit intaktem Artwork. Immerhin: Ich habe bei einem Dateipaar (Backup=OK versus aktuell=kaputt) mal mit NumPy und Matplotlib die data-Chunks verglichen - scheinen identisch zu sein.
Richtig, die zuletzt behandelten Dateien zeigen keine Fehler. Noch nicht. Allerdings kann das dauern. Nach einem Monat kann das dann schon wieder anders aussehen.
--------------------------------------------------------------------------------
MESSAGE
--------------------------------------------------------------------------------
File: y:\projects\mp3tag\mtmainframeupdatehandlers.cpp
Line: 108
Message: Size of file M:\Audio\Komponisten\Schubert, Franz\Trios\D 929 op. 100 Klaviertrio Nr. 2 Es-dur\Trio Bohémo\01 Allegro.wav is reported as 1117135324 from the system (it's more than 1GB)
000008CC at 1:09.996691
--------------------------------------------------------------------------------
MESSAGE
--------------------------------------------------------------------------------
File: y:\projects\mp3tag\mtmainframeupdatehandlers.cpp
Line: 108
Message: Size of file M:\Audio\Komponisten\Schubert, Franz\Trios\D 929 op. 100 Klaviertrio Nr. 2 Es-dur\Trio Bohémo\04 Allegro moderato.wav is reported as 1087567350 from the system (it's more than 1GB)
000008CC at 1:09.996748
--------------------------------------------------------------------------------
MESSAGE
--------------------------------------------------------------------------------
File: y:\projects\_audio\swavfile.cpp
Line: 599
Message: Exception at writing WAV metadata to 'M:\Audio\Komponisten\Schubert, Franz\Sololieder\D 550 Die Forelle\Die Forelle (Bonney).wav: Seek offset out of range
0000388C at 26:11.945410
Was könnte denn in diesem Monat passiert sein? Nach meiner Erfahrung zerbröseln Daten nicht einfach so, sondern wenn es dann Fehler gibt, hat dies externe Einflüsse wie z.B. ein Massenspeicher am Ende seiner Nutzlebensdauer.
Kannst du solche Dateien (im Zustand vorher und nachher) mal zur Verfügung stellen? Und auch beschreiben, nach welcher Tätigkeit mit welchen Daten/Bildern der Fehler auftrat?
Damit dürfte @Florian was anfangen können: Size of file M:\...01 Allegro.wav is reported as 1117135324 from the system (it's more than 1GB)
und Exception at writing WAV metadata to 'M:\....Die Forelle (Bonney).wav: Seek offset out of range
mir ist beim Herstellen eines Backups mal der Computer ausgefallen (Akku leer) ... eventuell hat es auch die gelesene Festplatte erwischt
als Reaktion darauf habe ich mit FFmpeg mal rekursiv alle Ordner durchsuchen und automatisch reparieren lassen. Vielleicht also mit FFmpeg kaputtrepariert.
seit Monaten bringe ich Ordnung in meine Metatags mithilfe von mp3tag, womit mp3tag auch nicht ausgeschlossen werden kann
Bei der Menge fallen solche Unfälle immer nur zufällig und stark verzögert auf.
Ich lade mal eine Datei in zwei Ausführungen hoch:
vorher.zip = mit Fehler / vor Bearbeitung mit mp3tag
nachher.zip = durch mp3tag repariert
mp3tag hat die Datei in diesem Fall also repariert, nicht beschädigt: Schreib-Fehler-Meldung wie im Screenshot oben -> auf Wiederholen klicken (dann kommt der Fehler nicht noch einmal).
Aber, wie gesagt, nach welcher Tätigkeit der Fehler auftrat, kann ich nicht reproduzieren ... das fällt bei der Menge erst Monate später auf.
Ich habe mir die Vorher-Variante angesehen und sie hat leider ein fehlerhaftes Dateiende.
Der ID3 Chunk dieser Datei ist 466 Bytes groß und was danach ab Offset 24221604 kommt, ist als Datenmüll zu werten. Es ist auch nicht mehr Teil der RIFF Größe die im Dateikopf hinterlegt ist.
An dieser Stelle kommt Mp3tag momentan durcheinander und bringt die Fehlermeldung. Ich habe heute angefangen das Ganze so umzubauen, dass diese überschüssigen Daten beim Speichern erhalten bleiben und nur in dem Fall, dass alles aus Nullen besteht, die Datei vom Datenmüll bereinigt wird.
Es ist immer recht schwierig zu entscheiden, was mit fehlerhaften Dateien gemacht werden soll. Ich war mit Mp3tag da bisher eher konservativ und habe das Schreiben solcher Dateien verweigert. Allerdings hat sich das über die vergangenen Jahre etwas aufgeweicht und ich habe ein paar Workarounds eingebaut — immer mit der Bedingung, dass dabei keine Audio-Daten gefährdet werden.
Die aktuelle Datei wird z.B. nur gelesen, weil es diese Änderung in 2021 gab:
[2021-10-22] CHG: WAV and AIFF files with extra null bytes at end of RIFF chunks are now read despite these inconsistencies.
Die Datei mit kaputtem Artwork hat auch überschüssige Nullen am Ende. Zum Zustand und Ursache des Artworks kann ich leider nichts sagen, außer dass es ebenfalls fast vollständig aus Nullen besteht.
Lieber Florian, danke für die intensive Untersuchung der Dateien! Gibt es eine Methode, die Integrität der Audiodaten einer Datei maschinell zu überprüfen? FFmpeg findet in den kaputtesten Dateien (sogar in solchen, in denen ich mit einem Hex-Editor herumgewütet habe) keine Fehler. Ich frage, weil die Sache mit dem Artwork wohl ärgerlich ist, aber eben doch eher Spielerei. Hingegen der Gedanke, dass nicht nur Bildchen kaputtgehen, sondern u. U. auch Audiodaten, durch welchen Prozess auch immer, ist beängstigend.
Du könntest foobar2000 zur Überprüfung der Audiodaten verwenden. Dort gibt es im Kontextmenü einen Eintrag Utilities → Verify integrity mit dem Fehler in den Audiodaten aufgespürt werden können.
Die Sache mit dem Datenmüll am Ende wird bei dieser Überprüfung jedoch nicht als Fehler gemeldet.
Ich habe beim Testen den Nero Wave Editor benutzt (den gibt es fast umsonst - man handelt sich nur wiederholte Hinweise auf Nero Produkte ein).
Der schreibt die Datei so zurück, dass anschließend keine Fehler mehr gemeldet werden. Einiges an Tag-Daten blieb auch erhalten.
Das kaputte Bild bleibt kaputt.
Lieber Florian und liebes Ohrenkino, danke für eure Tipps, dann werde ich beide mal testen. Datenmüll ist nicht schön und kaputte Bilder auch nicht, aber wenn die Audiodaten vollständig sind, ist schon viel gerettet.
Wenns ums reine Reparieren geht ist es bei Wave-Dateien am sinnvollsten, die Datei mit ffmpeg ohne veränderndes Kodieren neu zu schreiben. Ich nehme an (habe ich nicht überprüft), dass der Neo Wave Editor auch nichts anderes macht.
Die Einbindung als MP3Tag-Tool hat es ja auch in die FAQ geschafft.
Einige Taginfos bleiben erhalten, eingebettete Cover nicht.
MP3tag zeigt anschließend für meine angelegte Spalte %_tag_read%[ (%_tag%)]
nur noch RIFF (RIFF) an.
Tolles Tool. Von dem Prüfergebnis muss ich mich erst einmal erholen. Ich denke, ich werde es so machen wie von poster vorgeschlagen: Erst einmal mit ffmpeg in einen neuen Container kopieren.