ID3-Tags werden nicht richtig ausgelesen

Erst einmal ein nettes „Hallo“ :music: an das Forum!

Da ich seit Tagen im Internet stöbere und nichts Passendes dazu finde (es gibt wohl zu viele Fragen bezüglich iTunes), melde ich mich jetzt hier.

Folgende Situation:
Ein Bekannter hat etwa 370 CD Alben mit iTunes auf den PC als mp3 gespeichert. Diese hat er dann in iTunes nachbearbeitet, sprich Titel, Interpret, Album etc und Cover verändert. Zustand: Es wurde in iTunes alles richtig angezeigt.

Jetzt habe ich mit ihm die Ordner im Windows Explorer sortiert (zumindest grob, Albenweise wollte ich das dann mit MediaMonkey machen), da dies von iTunes beim Einlesen oder Herunterladen aus dem Internet nicht geeignet gemacht wird. Damit die Lieder in iTunes wieder gefunden werden, haben wir diese erst in iTunes gelöscht und den Musikordner mit den sortierten Ordnern neu hinzugefügt.

Jetzt werden aber bei vielen Liedern die ID3-Tags mal mehr, mal weniger ausgelesen, teilweise haben die Lieder laut iTunes keinen Inhalt in den ID3-Tags mehr. Auch viele Coveralben fehlen. Im Windows Explorer stehen laut Eigenschaften/Details aber die Informationen noch. Dort kann ich lesen, dass die Dateien von iTunes 10.4.1.10 codiert wurden. Auch die Cover sind in den Tags gespeichert und über die Ansicht Symbole zu sehen.

Windows Explorer: Zeigt die ID3-Tags und Cover Informationen richtig
iTunes: bei einem Teil der Lieder fehlen ID3-Tag Informationen und Cover
MediaMonkey: zeigt zumindest noch die Cover zusätzlich an, die sich in den Ordnern befinden
Mp3tag: Bei den entsprechenden Liedern wird angezeigt (!BAD ID3v2)

  1. Anscheinend liest iTunes erst bei neu hinzugefügten Liedern die Tags komplett neu aus. Wie kommt es aber zu den fehlerhaften Tags (die ja im Explorer richtig dargestellt werden)?
  2. Wie lassen sich die fehlerhaften Tags korrigieren, am besten mit den Infos aus dem Windows Explorer, da sie dort ja korrekt eingetragen sind?

Betriebssystem: Win7 Professionell
iTunes Lieder codiert mit 10.4.1.10 , Programm aktualisiert auf 10.6.1.7
MediaMonkey: 4.0.3.1476
id3-Tag: v2.3 laut iTunes, ID3v2.2 laut Mp3tag

Tja, wie soll man so was aus der Ferne diagnostizieren. Da geht nur probieren.
Stell erst mal sicher, dass die Dateien wirklich noch in Ordnung sind. Dazu gibt es foobar2000 und seine Utils im Kontextmenu oder mp3val.
Wenn diese Programme nichts mehr zu meckern haben, kannst du dich wieder an die tags selbst machen.
Und da müsstest du checken, ob wirklich nur MP3-tags drin sind oder auch noch APE - die solltest du dann löschen.
Naja - und wenn das alles klar ist, hast du bestimmt noch andere Fragen.

Hiho, ich hatte gerade auch das Problem und hab -ein- Workaround gefunden.
Unter Optionen -> Tags -> MPEG
Bei Lesen das Häkchen bei APE weg. Scheinbar hat er das Format priorisiert und somit geschaut was da drin steht. Da ich meine APE immer löschen, steht da natürlich nix drin.

Hoffe es hilft!

Wenn du die APE löscht, dann sind sie auch weg.
Ansonsten hast du recht, MP3tag hat diese Prioritätenfolge:
APE>ID3V2>ID3V1

Das Problem tritt auf, wenn du (bestgehende) APE-Tags zwar liest, aber dann nicht schreibst oder löschst. Dann überschreiben die leeren Felder den übrigen Inhalt.
Also, am besten ohne APE tags

Den Punkt darf mir mal jemand erklären (ja klar, früher, aber inzwischen kann ID3v2 alles), APE ist für MP3 sowieso völlig ungeeignet? Und dann noch die Kompatibilitätsschwierigkeiten mit anderne Playern.

Wie gesagt: das ist so in MP3tag implementiert.
Denn: um die Daten aus TALB in %album% zu bringen, muss intern irgendeine Art Übersetzung stattfinden.
Und das ist dann so, dass eben die aus APE die aus V2 überschreiben, die wiederum die aus V1 überschreiben.
Wenn also nur 1 Feld APE vorhanden ist, werden die gut gefüllten V2 Daten (mal angenommen) überschrieben und verschwinden beim nächsten Speichern .... Du hast eben nur 1 MP3tag-internes Feld, in dem die Daten landen können und nicht 3, also z.B. APE_ALBUM, V2_ALBUM, V1_ALBUM - es gibt nur 1 ALBUM.

Wenn im Dialog "Mp3tag/Extras/Optionen/Tags/Mpeg" ...
eingestellt ist ...
Schreiben = ja ... für ... ID3v1, ID3v2, APEv2, ...
dann wird Mp3tag alle drei Tagtypen in die selektierte Datei schreiben.

Wenn im Dialog "Mp3tag/Extras/Optionen/Tags/Mpeg" ...
eingestellt ist ...
Lesen = ja .. für ... ID3v1, ID3v2, APE, ...
und wenn die selektierte Datei mehrere Tagtypen enthält, ...
dann wird Mp3tag mit erster Priorität den Tagtyp APE lesen, wenn vorhanden, ...
sonst mit zweiter Priorität den Tagtyp ID3v2, wenn vorhanden, ...
sonst mit dritter Priorität den Tagtyp ID3v1, wenn vorhanden, ...
also ... APE>ID3V2>ID3V1.

Zwischen den Tagtypen wird nichts überschrieben.

Durch die prioriserte Lesemethode kann ein leerer Tag_APEv2 einen gefüllten Tag_ID3v2 verdecken.

Es ist auch möglich, dass gleichzeitig in den Tagtypen ID3v2.x und APEv2 verschiedene Cover Bilder gespeichert sein können, so dass je nach ausgewähltem Tagtyp ein anderes Cover Bild angezeigt wird.

Für mich in der Praxis hat es sich bewährt, auf den APEv2 Tag zu verzichten, ...
und alle Mpeg Optionen für APEv2 auszuschalten.

DD.20150723.2131.CEST

genau das halte ich für den Fehler, die Priorität sollte formatabhängig sein,
also bei MP3 z.B. ID3v2/ID3v1 ente.

Gute Entscheidung.
APE ist nicht für MPEG geeignet, schon weil ihm Eigenschaften fehlen die Verhindern, dass er versehentlich als Content interpretiert wird.

Danke für deine Ausführung.