mp3-Player zeigen andere Tags als mp3TagEditor

Hallo zusammen,
komme nicht weiter und habe auch in der Suche nichts gefunden.

Bin recht penibel wenn es um das Taggen meiner mp3s geht. Muss aber zugeben, dass ich mich nciht sonderlich gut mit den HIntergründen, ID-Versionen etc. auskenne.

Was mich wundert ist. dass ich z. B. ein Album per MP3TagEditor ändere, beim Abspielen im Mp3-Player (VLC, MediaMonkey, PowerAmp) wird aber ein anderes Album angezeigt. Wie muss ich die Einstellungen ändern, damit MEINE Daten angezeigt werden?

Die aktuellen Einstellungen habe ich jpg angehängt. Vielleicht hlft das ja :rolleyes:

Dank für Eure Hilfe

Gruß

Andreas


Du solltest bei "Entfernen" das Häkchen auch bei APE setzen.

Dann kannst du ja mal einige der widerwilligen Dateien ansehen, ob die APE-Tags haben. die solltest du entfernen.
Du findest die Information zu den Tag-Versionen entweder in einer Spalte ziemlich weit rechts in der Liste oder im Erweiterte Tags Dialog im Dialogtitel.

And then you should check how to update the database for the players.

Vielen Dank für die Hilfe. Yepp, die Titel haben APE-Tags.

Wie genau mache ich das "Entfernen"? Das Häkchen ist gesetzt, jetzt die Titel einfach nochmal speichern?

Was meinst Du damit?

Nochmals vielen Dank

Gruß

Andreas

Eigentlich müsste erneutes Speichern reichen - wenn es das nicht tut:
Zuerst die Bilder in eine externe Datei speichern (Aktion>Album cover in Datei exportieren)
Dann einen Schwung Dateien markieren,
Kontextmenü>Tag ausschneiden
Kontextmenü>Tag einfügen

Bilder wieder importieren
(ich meine, dass durch Tag ausschneiden/einfügen die Bilder verloren gehen und noch mal importiert werden müssen - ich kann mich auch irren)

Dann: manche Abspieler haben im Hintergrund eine Datenbank, die oft noch die alten Daten zeigt. Die müsste nach der Bearbeitung der Tags mit MP3tag noch vom Abspieler aktualisiert werden. Wie das geht, hängt sehr vom Abspieler ab.
Im WMP geht es am leichtesten, indem man Einträge komplett löscht und anschließend wieder herstellen lässt...

Du irrst Dich. :wink:

Hmm, was ist, wenn der APE Tag Bilder enthält, ...
die vielleicht interessant sind und in den ID3 Tag aufgenommen werden sollen?
Dann sollte man diese Bilder doch vorher auf die Platte retten, oder wie oder was?

DD.20150725.2034.CEST

Kann man natürlich machen. Ich fahre da sowieso immer doppelgleisig/dreigleisig. Ein Bild des Front-Covers in der Größe 800x800 wird in den Tag der Tracks eingebettet. Gleichzeitig liegt es als folder.jpg im Albumordner. Bilder in höherer Auflösung falls vorhanden von Frontcover, Backccover, Booklet, CD usw. werden ebenfalls im Albumordner gespeichert und zwar unter dem Namen %albumartist% - %album% -Front/Back/booklet usw. Das eingebettete Bild und folder.jpg dienen nur zur Anzeige beim Spielen in diversen Playern und da reicht mir 800x800 völlig aus und die MP3s werden nicht mit unnötig großen Cover-Bildern aufgebläht. Die übrigen Bilder im Ordner sind sozusagen Archivmaterial.

Nichtsdestotrotz:
Beim Übertragen von Ape-Tags mit Cover per Zwischenablage werden auch Cover-Bilder mit übertragen.

Zur Sicherheit habe ich es gerade nochmals getestet.

  • Ausgangsmaterial: MP3 mit ausschließlich Ape-Tags und mehreren Covern
  • Übertragung in die Zwischenablage (Lesen für Ape-Tags gesetzt
  • Löschen aller Tags (Option für Ape-Tags gesetzt)
  • Übertragung aus der Zwischenablage mit ausschließlich Schreiboption ID3v2.3
  • alle Coverbilder werden übertragen

Dann ist gut.:wink:
Dann habe ich das mit "Rückgängig" verwechselt. Da bleiben die Bilder auf der Strecke.

Dabei werden eventuell vorhandene Bilder im ID3v2.x Tag übersehen und überschrieben, oder?

DD.20150726.1027.CEST

Mein o.a. Vorgehensweise ging ja von ausschließlichen Ape-Tags aus.

Wenn ein File sowohl Ape-Cover als auch ID3v2-Cover enthält werden beim Kopieren in die Zwischenablage alle ausgelesen. Nach Löschen der Ape-Tags und anschließendem Einfügen aus der Zwischenablage enthält die MP3-Datei alle vorher vorhandenen Cover-Bilder und nur noch ID3v2-Tags.

Hier ist zum Testen eine MP3 Datei mit zwei Tagtypen APE und ID3v2, ...
die jeweils zwei Bilder enthalten, ...

  • ID3 Tag Cover Front, ID3 Tag Cover Back,
  • APE Tag Cover Front, APE Tag Cover Back,
    ... also sind vier unterschiedliche Bilder eingelagert in der MP3 Datei.
    In der Praxis könnten die Bilder von unterschiedlicher Größe und Qualität sein, ...
    und auch unterschiedliche Bildmotive haben.
    Das Ziel soll sein, alle vier Bilder im Tagtyp ID3v2 zu vereinen.

20150726.Test.Cover.ID3.APE.mp3 (16.8 KB)
DD.20150726.1840.CEST

20150726.Test.Cover.ID3.APE.mp3 (16.8 KB)

Das klappt nicht mit Deinem Test-Mp3-Datei.
Mir scheint, es hängt davon ab, in welcher Reihenfolge die Cover dem File hinzugefügt wurden.
Probier mal mein Testfile.
Covertest_ID3v2_APE.mp3 (16.9 KB)
Bei meinem File wurden zunächst das ID3V2-Cover und dann die Ape-Cover hinzugefügt.
Bei Deinem File verdecken die APE-Cover in der Anzeige von MP3TAG die ID3V2-Cover.
Bei meinem File sind alle sichtbar.

Covertest_ID3v2_APE.mp3 (16.9 KB)

In meiner Test-Datei ...
ist zuerst mit ausgeschaltetem ID3v2-Tag der APE-Tag geschrieben worden mit seinen beiden Bildern, also separat für sich, ...
und danach mit ausgeschaltetem APE-Tag ist der ID3v2-Tag geschrieben worden mit seinen beiden Bildern, auch separat für sich.
Das sollte für den Test ja so sein, ...
zwei unabhängig erzeugte Tag-Typen mit unterschiedlichen Daten und unterschiedlichen Coverbildern.

Weil APE In Mp3tag Vorrang hat, wird in meiner Test-Datei auch nur APE angezeigt, wenn APE zum Lesen eingeschalet ist.
Wenn APE ausgeschaltet ist, dann wird in meiner Test-Datei auch nur ID3v2 angezeigt.

"Deine Datei" ist ein anderer Testfall, diese hat auch keinen APE-Tag.
Es wäre vielleicht erst einmal angebracht, ein Verfahren zu entwickeln, womit bei meiner so gegebenen Testdatei, wenn nicht alle Tag-Felder-Daten, dann aber alle vier Coverbilder im Tag-Typ ID3v2 versammelt werden können.

DD.20150727.1657.CEST

Und in meiner Testdatei ist zunächst der ID3v2-Tag geschrieben worden und dann der APE-Tag.

Bei meinem Testfiler werden in dem Fall offenbar wegen der in der Reihenfolge umgekehrten Speicherung alle Cover-Bilder angezeigt, d.h. die APE-Cover-Tags verdecken nicht die ID3v2-Cover-Tags. Somit lassen sich auch alle per Copy&Paste wieder als ID3v2-Tags einfügen.
Übrigens werden bei mir bei Deinem Testfile auch nur die APE-Cover angezeigt wenn APE-Lesen deaktiviert ist.

M.E. geht das in Deinem Szenario wirklich nur über den Weg des Extrahierens der APE-Cover-Tags, Löschen der APE-Tags und Hinzufügen der extrahierten Cover-Tags.

Die Reihenfolge ist eigentlich egal, man muss nur darauf achten, beim jeweils anderen Tagtyp das Lesen und das Schreiben auszuschalten.

  • Hmm Schreibfehler? Sollte es nicht lauten: ...
    "... nur die APE-Cover angezeigt wenn ID3v2-Lesen deaktiviert ist" ???
  • Wenn es doch so gemeint ist, dann sind die APE Cover irgendwie in den ID3v2 Tag hineingekommen.

Im Übrigen geht es nicht um "mein oder dein" Szenario, sondern um den Fall, wie man die Cover Bilder im APE Tag in den ID3v2 Tag einlagern kann zusammen mit den dort schon vorhandenen Cover Bildern, also ohne ein Bild zu verlieren.
Und das wird nur über den Export der APE Cover Bilder möglich sein, mit anschließenden Import in den ID3v2 Tag, und mit manuellem Hin- und Herschalten in den Mpeg Optionen.

Mit APE-Tag kopieren und in ID3v2 einfügen erzielt man ein anderes Ergebnis, ...
nämlich den Verlust von zuvor gespeicherten ID3v2 Daten und ID3v2 Cover Bildern.

DD.20150727.1851.CEST

Eben offenbar nicht.

Es war so gemeint. Ich habe Dein Testfile mehrmals frisch heruntergelden umd einen Irrtum auszuschließen. Ich bekam öfters ein unterschiedliches Ergebnis, was im im Moment wieder mal nicht reproduzieren kann. Dein MP3-File per Kontextmenü und deaktivierter APE-Lese-Option geöffnet zeigte mir trotzdem manchmal die APE-Cover-Tags. Ich denke ich gebe auf. :wink:

Der Unterschied der Szenarien besteht doch anscheinend in der Art, wie und in welcher Reihenfolge die Tags im MP3-File abgespeichert wurden.
Übrigens habe ich leider bei all der Testerei das falsche File hochgeladen, was ich inzwichen korrigiert habe.
Hier mal genau meine Vorgehensweise bei der Erzeugung des Testfiles:

  1. MP3-File ohne Tags
  2. Option Schreiben ID3V1, ID3V2 gesetzt, Schreiben APE deaktiviert
  3. Manuelles Hinzufügen eine Coverbildes per rechte Maustaste im Coverfeld und abspeichern
  4. Option Schreiben bei ID3V2 und ID3V1 deaktiviert, Schreiben APE aktiviert
  5. Manuelles Hinzufügen eine Coverbildes per rechte Maustaste im Coverfeld und abspeichern

Das MP3-File enthält jetzt sowohl ein ID3V2-Cover-Tag als auch ein APE-Cover-Tag. Je nach Lese-Option wird entweder das eine oder das andere angezeigt und wenn alle Leseoptionen aktiviert sind werden alle Cover angezeigt.

Ich habe dann

  1. Alle Leseoptionen aktiviert und es werden alle Cover angezeigt.
  2. Die Tags in die Zwischenablage kopiert
  3. Alle Tags gelöscht
  4. Option Schreiben ID3v2.3 aktiviert, APE deaktiviert
  5. Die Tags aus der Zwischenablage eingefügt.

Alle Cover sind anschließend als ID3v2-Cover vorhanden.

Aber wie wir ja festgestellt habe, hilft diese Vorgehensweise nicht in jeder Konstellation.

Im Schritt 4 hättest du vielleicht noch das Lesen von ID3v2 ausschalten müssen.

Das ist wohl richtig so.

Das kann so nicht richtig sein, weil das Lesen von APE in Mp3tag doch immer Vorrang hat, oder bei deiner Testdatei nun doch nicht mehr?

Benutze irgendeinen Hex-Viewer ... und finde die Orte der gespeicherten Bilddaten
(z. B. MP3 Datei in Irfanview laden, dann [F3] ... oder Lister.exe von Christian Ghisler).

In meiner Testdatei "20150726.Test.Cover.ID3.APE.mp3" ...
findest du zwei "ID3-Bilder" im ID3v2 Tag am Anfang der Datei ...
und zwei "APE-Bilder" im APE Tag am Ende der Datei .

In deiner Testdatei neu "Covertest_ID3v2_APE.mp3" ...
findest du ein "ID3-Bild" im ID3v2 Tag am Anfang der Datei ...
und zwei "APE-Bilder" und ein "ID3-Bild" im APE Tag am Ende der Datei.

Dieser Schritt will mir nicht gelingen, weil APE Vorrang hat in Mp3tag.
Was funktioniert, das ist das Kopieren über die Zwischenablage ...
von ID3v2 Daten und Bildern in den APE Tag, ...
dabei gehen die APE Daten und Bilder verloren, ...
bzw. anders herum von APE nach ID3v2, ...
dabei gehen die ID3v2 Daten und Bilder verloren.

Wenn ich das nachvollziehe, dann bekommt die Datei ....
einen neu geschriebenen ID3v2 Tag mit den Daten in der Zwischenablage, ...
die aus dem APE Tag stammen, also die APE Daten und Bilder, ...
und die ID3 Daten und Bilder sind verschwunden.

Es ist mir bisher nicht gelungen, eine Datei zu erzeugen, ...
die schließlich so aussieht wie deine Testdatei neu "Covertest_ID3v2_APE.mp3".

Eigentlich bestätigt unser Dialog mich wieder in meiner Meinung, ...
dass die "Ungleichbehandlung" der Tagtypen ID3v2 und APE irgendwie Murks ist.
Es gibt anscheinend keine saubere Mp3tag interne Methode, ...
mit der die Daten bzw. nur die Bilder aus den beiden Tag-Typen ...
in einem Tag-Typ zusammengeführt werden können, ...
es gibt nur ein "Entweder-Oder".

DD.20150728.0958.CEST

Ich muss doch noch anmerken, ... dass sich bei einem Testvorgang ...
nach dem Hin- und Herschalten der Mpeg Optionen, ... und einmal speichern, ...
ein einziges Mal die Situation ergeben hat, ...
bei der im ID3v2 Tag ... die ID3v2 Daten erhalten waren, ...
und die beiden ID3 Bilder gegen die beiden APE Bilder ausgetauscht worden waren.
Diesen wunderbaren Zustand konnte ich bisher nicht mehr nachvollziehen.

DD.20150728.1105.CEST

Danke für den Hinweis. Das wars. :blush:
Offenbar wird ansonsten beim Hinzufügen des APE-Tags das vorhandene ID3v2-Covertag zusätzlich als APE-Tag abgespeichert.
Diesen Umstand habe ich nicht bedacht und das erklärt auch etliche Inkonsistenzen, die ich mir nicht erklären konnte und die mich beim testen in den Wahnsinn trieben.

Ich nehme also alles zurück und behaupte das Gegenteil:
Es geht nur über den Weg es Extrahierens.