MP3 Tags im Explorer von Windows anzeigen und bearbeiten: die ID3 Felder

MP3 Tags im Explorer anzeigen und ändern zu können, ohne etwas zu installieren, macht den Eigenschaftendialog auf den meisten Rechnern zum Standard-Tag-Editor. Er ist ein unvollständiger: er zeigt manche Felder, schreibt weniger und übergeht stillschweigend Teile der Datei, die andere Programme lesen. Welche Teile das sind, erklärt fast jede Überraschung in diesem Bereich.

Schema einer Audiodatei mit je einem Metadatenblock an beiden Enden, einer zuerst gelesen, einer als Rückfallebene.

Nachzeichnung der Registerkarte, die die Shell-Erweiterung dem Eigenschaftendialog einer MP3-Datei hinzufügte: die ID3-Felder oben zum Bearbeiten, die aus dem Frame-Header gelesenen Werte darunter als reine Anzeige.

Was der Explorer aus einem ID3 Tag liest

Eine MP3-Datei ist eine Folge von Audio-Frames mit angeschraubten Metadaten an beiden Enden. ID3v1 ist ein fester 128-Byte-Block am Dateiende mit sieben Feldern, jedes hart gekürzt: dreißig Zeichen für den Titel, dreißig für den Interpreten, ein einzelnes Byte für ein Genre aus einer numerierten Liste. ID3v2 sitzt am Anfang, ist variabel lang und in benannten Frames organisiert, kann also lange Zeichenfolgen, mehrere Interpreten, eingebettete Coverbilder und beliebige eigene Felder aufnehmen.

Der Eigenschaften-Handler bevorzugt ID3v2 und fällt auf ID3v1 zurück. Eine Datei, die ein älteres Programm nur mit dem hinteren Block versehen hat, erscheint im Dialog also leer, während ein Medienplayer sie korrekt zeigt. Das ist der häufigste Grund für die Annahme, MP3 Tags im Explorer seien kaputt: beide Leser verhalten sich korrekt und schauen auf verschiedene Bytes.

Die praktische Folge: jeder Versuch, MP3 Tags im Explorer zu bearbeiten, arbeitet am ID3v2-Block und nur an diesem. Eine Datei ohne ID3v2-Block erhält beim ersten Speichern einen, und ab dann existieren beide Tags nebeneinander und können auseinanderlaufen. Der ältere Block enthält weiterhin, was das vorherige Programm geschrieben hat.

Zwei Tags, eine Datei

ID3v1: Letzte 128 Byte. Sieben Felder. Titel und Interpret auf 30 Zeichen gekürzt. Genre ist eine Zahl.
ID3v1.1: Derselbe Block; die letzten zwei Kommentar-Bytes werden Titelnummer.
ID3v2: Am Dateianfang. Benannte Frames, variable Länge, trägt Coverbild und eigene Werte.
Lesereihenfolge: ID3v2 zuerst, ID3v1 als Rückfallebene
Berechnet, nie gespeichert: Bitrate, Abtastrate, Dauer, Frame-Anzahl, Kanalmodus
Nie synchron: Dateiname und Tag

MP3 Tags im Explorer anzeigen und welche Felder sich bearbeiten lassen

Der Dialog teilt seinen Inhalt genauso auf wie das Format. Die Tag-Felder sind änderbar: Titel, mitwirkende Interpreten, Album, Jahr, Titelnummer, Genre, Kommentar und einige Einordnungsfelder wie die Bewertung. Die aus den Frames abgeleiteten Werte sind reine Anzeige, weil sie beim Lesen aus dem Audiostrom berechnet werden und es keinen Ort gibt, sie zurückzuschreiben.

Ein Speichervorgang schreibt nach ID3v2. Hat der bestehende Block genug Reserve, ist es eine kleine Änderung an Ort und Stelle; hat er sie nicht, wird die gesamte Datei neu geschrieben, um Platz zu machen. Deshalb kann das Ändern eines einzelnen Zeichens an einer großen Datei einen Moment dauern, und deshalb kann ein fast voller Datenträger den Vorgang scheitern lassen. Gewarnt wird davor nicht. Die Änderung bleibt einfach nicht stehen.

Zwei Grenzen überraschen regelmäßig. Mehrwertige Felder werden eingeebnet: mehrere Interpreten landen in einem Textfeld, durch Semikolon getrennt, und eine Bearbeitung dort schreibt den Frame so zurück, wie es eingegeben wurde. Und jeden Frame, den der Handler nicht abbildet, lässt er strikt in Ruhe: eine gute Nachricht, denn Bearbeiten im Explorer zerstört keine Felder, die es nicht zeigen kann.

Was eine Shell-Erweiterung dem Dialog hinzufügte

Bevor der eingebaute Handler Audio ordentlich abdeckte, füllten Shell-Erweiterungen die Lücke: kleine Komponenten, die im Prozess der Shell laufen, für einen Dateityp registriert sind und beim Aufbau eines Eigenschaftendialogs eine eigene Registerkarte beitragen. Eine solche Erweiterung, als Freeware für Windows 9x, NT und 2000 veröffentlicht, ergänzte eine MP3-Registerkarte, die zwei Dinge tat, die die Shell damals nicht tat.

Sie stellte die bearbeitbaren ID3-Felder und die dekodierten Frame-Header-Werte auf dieselbe Karte, sodass Größe, Bitrate, Länge, Abtastfrequenz, Frame-Anzahl und MPEG-Version direkt unter den Feldern standen, die man bearbeitete. Und sie lieferte einen Infotipp, sodass das Überfahren einer Datei im Ordner dieselbe Zusammenfassung ohne Öffnen des Dialogs zeigte: auf den Shell-Versionen, die Tipps unterstützten, damals Internet Explorer 4 und neuer.

Die Abbildung oben ist eine Nachzeichnung dieser Karte. Sie lohnt den Blick als Gestaltungsargument und nicht als Nostalgie: die dekodierten Werte sind die, an denen man erkennt, ob eine Datei behaltenswert ist, und sie neben das Tag zu stellen statt eine Karte weiter ist die bessere Anordnung als der heutige Standard.

Wie eine Erweiterung registriert wird

Der Mechanismus ist unverändert, weshalb dieselbe Registrierung auch beschreibt, wie fremde Registerkarten heute erscheinen. Ein Handler ist eine unter der Dateizuordnung registrierte Komponente, die die Shell beim Zusammenbau des Dialogs instanziiert.

HKEY_CLASSES_ROOT\.mp3\shellex\PropertySheetHandlers\<Handler>
  (Standard) = {CLSID der In-Process-Komponente}

HKEY_CLASSES_ROOT\CLSID\{CLSID}\InprocServer32
  (Standard)     = C:\Windows\System32\beispiel.dll
  ThreadingModel = Apartment

Weil sie im Prozess der Shell lädt, nimmt ein fehlerhafter Handler die Shell mit. Das ist der Grund, warum diese Art Erweiterung weitgehend durch Handler außerhalb des Prozesses ersetzt wurde, und der Grund, warum ein Ordner, der beim Rechtsklick abstürzt, meist einen registrierten Handler und keine defekte Datei hat.

Heute: womit MP3 Tags im Explorer bearbeiten sinnvoll ist

Es gibt drei Antwortstufen, je nachdem wie viele Dateien betroffen sind. Für ein oder zwei Dateien reicht der eingebaute Dialog und hat den Vorteil, nicht abgebildete Frames unangetastet zu lassen. Für alles in Menge ist er das falsche Instrument: er bearbeitet eine Datei auf einmal, kennt keine musterbasierte Umbenennung und kann den Widerspruch zwischen v1 und v2 nicht reparieren, der das Problem überhaupt verursacht hat.

Wer MP3 Tags im Explorer anzeigen und dort auch pflegen will, stößt genau an dieser Stelle an die Grenze. Ein spezialisierter Tag-Editor kann alle drei. Die eine Einstellung, die vor einem Massenlauf zu prüfen ist, sind die geschriebenen Tag-Versionen. ID3v2 plus einen abgeglichenen ID3v1-Block zu schreiben kostet fast nichts und macht die Dateien für den Explorer und für Hardware lesbar, die nur den hinteren Block kennt. Nur v2 zu schreiben ist sauberer und lässt gelegentlich ein altes Autoradio ohne Anzeige.

Sehen die Tags im Editor richtig und in der Shell falsch aus, bleibt der Zwischenspeicher als Verdächtiger. Vorschaubilder und Eigenschaftswerte werden pro Benutzer zwischengespeichert, und ein zurückgesetzter Zwischenspeicher behebt eine Anzeige, die der Datei nachhängt. Das ist es wert, geprüft zu werden, bevor man auf einen fehlgeschlagenen Schreibvorgang schließt.

Fragen zu MP3 Tags im Explorer

Warum sieht ein Player die Tags und der Explorer nicht?

Fast immer, weil zwei Tags sich widersprechen. Eine Datei kann einen ID3v1-Block am Ende und einen ID3v2-Block am Anfang tragen, und verschiedene Leser bevorzugen verschiedene. Der Explorer liest zuerst ID3v2; eine Datei, in die ein Programm nur ID3v1 geschrieben hat, lässt ihn ohne Anzeige. Beides zu schreiben oder die Datei auf ID3v2 umzustellen löst es.

Warum sind manche Felder bearbeitbar und andere nicht?

Der eingebaute Eigenschaften-Handler zeigt eine feste Auswahl und behandelt den Rest als schreibgeschützt. Alles, was aus den Audio-Frames abgeleitet ist (Bitrate, Abtastrate, Dauer, Frame-Anzahl), wird berechnet und nicht gespeichert, es gibt also nichts zurückzuschreiben. Felder, die er einfach nicht abbildet, bleiben unsichtbar, obwohl sie in der Datei stehen.

Der Explorer speichert meine Änderung nicht. Woran liegt es?

Zwei häufige Ursachen: die Datei ist schreibgeschützt, oder ein Player hält eine Schreibsperre. Die dritte ist unauffälliger. Hat der ID3v2-Block keine Reserve, muss zum Speichern die ganze Datei neu geschrieben werden, und wenn der Datenträger fast voll ist oder die Rechte nur Anhängen erlauben, scheitert das ohne Meldung.

Kommt das Coverbild aus dem Tag?

Ja, aus einem Bildframe in ID3v2. ID3v1 hat überhaupt kein Bildfeld, weshalb eine Datei mit nur diesem Block nie ein Cover zeigt, egal wie die Ordneransicht eingestellt ist. Ein veraltetes Vorschaubild nach einer Tag-Änderung ist der Zwischenspeicher, nicht das Tag.

Was ergänzte die Shell-Erweiterung, das der Explorer nicht hat?

Eine eigene Registerkarte im Eigenschaftendialog, die die ID3-Felder zusammen mit den aus dem Frame-Header gelesenen Werten an einer Stelle zeigte, und einen Infotipp beim Überfahren, sodass dieselben Daten ohne Öffnen erschienen. Der eingebaute Handler verteilt das auf eine Detailseite und die Statuszeile und zeigt weniger Header-Werte.

Lohnt es sich, ID3v1 noch zu schreiben?

Nur für Hardware. Manche Autoradios und ältere Abspielgeräte lesen nichts anderes. Es kostet 128 Byte und kürzt jedes Feld auf 30 Zeichen, als zweites Tag neben ID3v2 ist es also harmlos und gelegentlich nützlich.

Warum verschwindet manchmal das Jahr nach dem Bearbeiten?

Weil in den zwei ID3v2-Revisionen zwei verschiedene Frames „Jahr" bedeuten und Schreibprogramme sich nicht einig sind, welches gilt. Ein Werkzeug, das den neueren Aufnahmezeit-Frame schreibt, wirkt für einen Leser, der nur den älteren kennt, als hätte es das Jahr geleert. Wichtiger als die formal richtige Wahl ist Einheitlichkeit innerhalb der eigenen Werkzeugkette.

Gehen die Tag-Daten auch in der Ordnerliste?

Ja: die Ordneransicht auf Details umstellen und die gewünschten Spalten hinzufügen, oder den Infotipp benutzen. Die Spalten stammen aus derselben Handler-Ausgabe wie der Dialog, was der Handler nicht zeigt, lässt sich also auch nicht als Spalte ergänzen.

Sind diese Felder durchsuchbar?

Wenn der Indexdienst den Ordner erfasst, ja: indizierte Eigenschaften lassen sich über das Suchfeld und die Abfragesyntax finden. Ein Ordner außerhalb des Index fällt auf eine langsame Inhaltssuche zurück, die Tags gar nicht liest: deshalb funktioniert dieselbe Suche an einer Stelle und an einer anderen nicht.

Ändert Umbenennen das Tag?

Nein, und diese Asymmetrie verursacht viel Verwirrung. Dateiname und Tag sind unabhängig, und nichts im Explorer hält sie synchron. Werkzeuge, die das scheinbar tun, lesen auf Wunsch das eine und schreiben das andere.