# Probleme mit Artwork

**URL:** https://community.mp3tag.de/t/probleme-mit-artwork/68119
**Category:** Fehlermeldungen
**Created:** [April 6, 2025, 9:45am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119 "2025-04-06T09:45:08Z")
**Posts on this page:** 12
**Page:** 3

<div class="post-metadata">

### Author: ![ABehrens2](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@ABehrens2](https://community.mp3tag.de/u/ABehrens2)
#### Post date: [April 10, 2025, 11:39am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/41 "2025-04-10T11:39:57Z")

</div>

Heijei, entschuldige. Da habe ich zu schnell gelesen. Das ist ja großartig, danke! Alexander

---

<div class="post-metadata">

### Author: ![ABehrens2](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@ABehrens2](https://community.mp3tag.de/u/ABehrens2)
#### Post date: [April 10, 2025, 9:18pm UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/42 "2025-04-10T21:18:19Z")

</div>

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:

```auto
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?

---

<div class="post-metadata">

### Author: ![poster](https://community.mp3tag.de/user_avatar/community.mp3tag.de/poster/32/4881_2.png) [@poster](https://community.mp3tag.de/u/poster)
#### Post date: [April 11, 2025, 5:35am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/43 "2025-04-11T05:35:47Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ABehrens2](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@ABehrens2](https://community.mp3tag.de/u/ABehrens2)
#### Post date: [April 11, 2025, 7:50am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/44 "2025-04-11T07:50:23Z")

</div>

Reparieren macht also nur dann Sinn, wenn eine Datei sich gar nicht mehr öffnen lässt oder Metadaten nicht dargestellt werden.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 11, 2025, 7:55am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/45 "2025-04-11T07:55:45Z")

</div>

> [@ABehrens2](#):
>
> Reparieren macht also nur dann Sinn

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.

---

<div class="post-metadata">

### Author: ![ABehrens2](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@ABehrens2](https://community.mp3tag.de/u/ABehrens2)
#### Post date: [April 11, 2025, 8:00am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/46 "2025-04-11T08:00:07Z")

</div>

> [@ohrenkino](#):
>
> Hört sich für mich so an, als ob jemand direkt das nächste Desaster anfordert.

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.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 11, 2025, 8:06am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/47 "2025-04-11T08:06:51Z")

</div>

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.

---

<div class="post-metadata">

### Author: ![ABehrens2](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@ABehrens2](https://community.mp3tag.de/u/ABehrens2)
#### Post date: [April 11, 2025, 8:16am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/48 "2025-04-11T08:16:42Z")

</div>

Das ist ein Argument.

---

<div class="post-metadata">

### Author: ![Florian](https://community.mp3tag.de/user_avatar/community.mp3tag.de/florian/32/5759_2.png) [@Florian](https://community.mp3tag.de/u/Florian)
#### Post date: [April 11, 2025, 3:25pm UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/49 "2025-04-11T15:25:20Z")

</div>

> [@Florian](#):
>
> 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.

Dieser Umbau ist mit [Mp3tag v3.29b](https://community.mp3tag.de/t/455) nun umgesetzt.

---

<div class="post-metadata">

### Author: ![ABehrens2](https://community.mp3tag.de/letter_avatar_proxy/v4/letter/a/90ced4/32.png) [@ABehrens2](https://community.mp3tag.de/u/ABehrens2)
#### Post date: [April 12, 2025, 8:09pm UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/50 "2025-04-12T20:09:43Z")

</div>

Liebe/r Florian und Mitstreiter, danke für eure hilfreichen Hinweise und natürlich für die neue Version.

---

<div class="post-metadata">

### Author: ![ohrenkino](https://community.mp3tag.de/user_avatar/community.mp3tag.de/ohrenkino/32/4843_2.png) [@ohrenkino](https://community.mp3tag.de/u/ohrenkino)
#### Post date: [April 13, 2025, 9:42am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/51 "2025-04-13T09:42:51Z")

</div>

A post was split to a new topic: [Mehrere Cover in WAV Dateien](https://community.mp3tag.de/t/mehrere-cover-in-wav-dateien/68184)

---

<div class="post-metadata">

### Author: ![system](https://community.mp3tag.de/uploads/default/original/2X/c/ce7035d426cb755a7916793326d23b465222a407.png) [@system](https://community.mp3tag.de/u/system)
#### Post date: [May 13, 2025, 9:43am UTC](https://community.mp3tag.de/t/probleme-mit-artwork/68119/52 "2025-05-13T09:43:33Z")

</div>

This topic was automatically closed 30 days after the last reply. New replies are no longer allowed.

[Previous page](https://community.mp3tag.de/t/probleme-mit-artwork/68119.md?page=2)
