Heijei, entschuldige. Da habe ich zu schnell gelesen. Das ist ja großartig, danke! Alexander
Das ist schon ein tolles Feature; nur ... was wird da eigentlich repariert? Wenn ich mit einem Hexeditor eine WAV-Datei im Audo-Chunk massakriere und foo2000 validieren lasse, schreibt foo2000:
Warning: Indicated RIFF size exceeds actual file size, file appears to be truncated
Nachdem ich es dann mit ffmpeg wie oben beschrieben repariert habe, findet foo2000 die Datei plötzlich OK. Untersucht foo2000 doch nur die Containerstruktur? Das wäre meine einzige Erklärung. Kann man beschädigte Audiodaten (auch in einem intakten Container) nicht wirklich maschinell erkennen?
ffmpeg liest den Header der Eingabedatei und prüft ihn auf Konsistenz.
Es erzeugt einen neuen, korrekten Header für die Ausgabedatei. Fehlerhafte Headerinformationen (z. B. falsche Datenlänge) können dadurch automatisch korrigiert werden.
Man kann das m.E. noch erweitern, indem man -err_detect ignore_err davorsetzt. In dem Fall ignoriert ffmpeg Fehler im Audio-chunk und schreibt koste was wolle weiter.
Zaubern kann diese Vorgehensweise nicht. Wenn was im Audioteil nicht stimmt, kann es beim neu schreiben einfach übersprungen werden. Je nach Umfang der Fehler ist das natürlich mehr oder weniger hörbar. Die Datei ist jedoch wieder abspielbar (wenn sie das vorher nicht war) und korrekt mit Metadata beschreibbar.
Allerdings bin ich bei Wavedateien immer nur mit solchen strukturellen Problemen konfrontiert worden. Nach Beiträgen hier in der Community gibt es wohl etliche Software, die strukturell unkorrekte Wavedateien verursacht. Ich hatte auch mal mit einer Aufnahmesoftware gearbeitet, die grundsätzlich falsche Header bei Wavedateien schrieb.
Reparieren macht also nur dann Sinn, wenn eine Datei sich gar nicht mehr öffnen lässt oder Metadaten nicht dargestellt werden.
Verstehe ich nicht. Da habe ich eine Datei, die von der Struktur her kaputt ist. Und das will ich so lassen? Hört sich für mich so an, als ob jemand direkt das nächste Desaster anfordert.
"Reparieren" heißt in diesem Zusammenhang nicht "erraten" - also der Prozess kann dann nicht die kaputt gegangenen Daten in den ursprünglichen Zustand zurückversetzen.
Reparieren heißt hier, dass die Datei formal wieder so zugänglich gemacht wird, dass sie womöglich weiter inhaltlich beurteilt werden kann.
Also wäre es jetzt an dir, herauszfinden, wer die vermurksten WAV-Dateien verursacht hat.
Sehr interessant: Was soll passieren, wenn die Struktur nicht stimmt? Dass ein schreibendes Programm dann noch weiter durcheinanderkommt und das Chaos verschlimmert? Das wäre ein Grund aufzuräumen. Ich meine, foo2000 schreibt dann Minor problems found oder so ähnlich. Das klingt nicht nach Desaster, zumindest erst einmal.
Und genau deshalb: weil nicht klar ist, worin der Fehler besteht und wie er sich in Zukunft auswirken wird, ist jeder weitere Aufwand (wie z.B. wieder intakte Bilder einbetten) im Prinzip der Weg zu Doppelarbeit: die wird dann fällig, wenn die Datei durch weitere Bearbeitungsschritte völlig unbearbeitbar geworden ist und damit alle Änderungen verloren gegangen sind. Oder nach dem GIGO Prinzip kann dann MP3tag auch ggf. keine weiteren Änderungen vornehmen.
Aber: es ist deine Sammlung - mit der kannst du natürlich machen, was du willst.
Das ist ein Argument.
Dieser Umbau ist mit Mp3tag v3.29b nun umgesetzt.
Liebe/r Florian und Mitstreiter, danke für eure hilfreichen Hinweise und natürlich für die neue Version.