Flexibles Tagging: Feldnamen

Als Zusatz zum Leitartikel Flexibles Tagging hier einige wissenswerte Hintergrundinformationen zum Thema Feldnamen.

Vordefinierte Felder.

Bei der Definition des Tagging-Standards ID3v2 für MP3-Dateien hat man versucht, möglichst viele Anwendungsfälle abzudecken, und definierte eine Menge von Feldern vor. Entwickler von Audiosoftware wählen in der Regel unter den vordefinierten Feldern des ID3v2-Standards einige aus, oder versuchen gar, alle abzudecken. Die typischen und von jeder Anwendung verstandenen Felder sind Tracknumber, Title, Artist, Album, Date und Comment, dazu oft noch einige weitere wie etwa der Komponist eines Titels.

Daraus ergibt sich das Problem, dass ein mit einer Software geschriebenes Feld in einer anderen möglicherweise garnicht berücksichtigt wird, also weder auf irgendeine Weise für den Nutzer angezeigt wird, noch von ihm durchsucht oder bearbeitet werden kann. Bei benutzerdefinierten Tags sieht es noch schlechter mit der Kompatibilität aus, denn sie können nur von den Anwendungen foobar2000 und Mp3tag verarbeitet werden.

Wer flexibles Tagging einsetzt, der ist über dieses Problem meist hinaus. Denn die vordefinierten Felder werden seinen Ansprüchen nicht gerecht, er ist unter dieser Auswahl nicht in jedem Fall fündig geworden. Man kann beim Taggen versuchen, existierende Standards einzuhalten. Man wird dabei jedoch schnell an Grenzen stoßen, wenn man die Tendenz hat, viele benutzerdefinierte Informationen unterbringen zu wollen.

Für zwei oder drei weitere Werte findet sich möglicherweise noch ein Kompromiss. Bei allem was darüber hinaus geht, hat man, möchte man nicht dauernd zwischen zwei verschiedenen Paradigmen wechseln, nur noch die Wahl, sich komplett gegen flexibles Tagging zu entscheiden oder aber den Kompromiss einzugehen und voll auf foobar2000 zu setzen.

Ebenenmodell.

Für das bessere Verständnis bei der Betrachtung von Feldnamen und deren Bezeichnungen ist es sinnvoll, sich folgender drei Ebenen bewusst zu sein:

1. Ebene: Bezeichner innerhalb der Dateien

Innerhalb der Audiodateien werden die Tags je nach Audioformat und Tagging-Standard unterschiedlich abgespeichert.

Im Fall von FLAC und Ogg Vorbis sowie dem bei mehreren Audioformaten zum Einsatz kommenden APEv2-Format werden die Feldnamen im Klartext gespeichert. Öffnet man die Dateien mit einem Editor, dann sieht man dort tatsächlich "Artist", "Title" und so weiter.

Beim ID3v1-Format werden überhaupt keine Bezeichner gespeichert, hier sind die 128 vorgesehenen Bytes fest aufgeteilt. Die Zeichen 1 bis 30 sind dann eben der Titel, gefolgt vom Interpreten in den Zeichen 31 bis 60, und so weiter (siehe http://www.id3.org/id3v1.html).

Beim ID3v2-Format wird jedem vordefinierten Feld (hier auch "Frame" genannt) ein Kürzel aus vier Buchstaben zugeordnet (Referenz). Unbekannte Felder werden als "TXXX" geschrieben, der eigentliche Feldname wird im Klartext als Beschreibung dahinter gespeichert.

Da wahrscheinlich kein Anwender auf die Idee kommen würde, seine Dateien direkt per Hex-Editor zu bearbeiten, sind diese Einzelheiten weniger von Bedeutung.

2. Ebene: Innerhalb der Software

Bei den meisten Programmen hat es sich durchgesetzt, dass das Benutzerinterface zur Eingabe von Tags unabhängig vom Codec der gerade bearbeiteten Audiodatei immer gleich aussieht. Zu diesem Zweck ordnen die meisten Tagger Feldern mit der gleichen Bedeutung intern im Programm den gleichen Namen dazu. Was in den Audiodateien noch als "TRCK" (ID3v2), "Track" (VorbisComment) oder "Tracknumber" (APEv2) abgespeichert war, wird nun im Programm als ein und dasselbe Feld für die Tracknummer behandelt, und nach dem Bearbeiten wieder in die jeweiligen Felder zurückgeschrieben.

Diese Zuordnung wird gewährleistet, ohne dass der Anwender etwas davon bemerkt. Die Handhabung wird dadurch sehr erleichtert, der Benutzer muss sich nicht um Besonderheiten einzelner Formate kümmern und kann immer die gleichen Bezeichner verwenden. Feldnamen auf dieser Ebene schreibe ich im Folgenden mit Großbuchstaben (ARTIST, ALBUM etc.).

Die programminternen Bezeichner spielen für den Benutzer meist keine Rolle, er kommt mit ihnen nicht in Kontakt. Bei Anwendungen mit Unterstützung für flexibles Tagging ist dies anders. Hier wird dem Benutzer angeboten, die Gestaltung der Oberfläche oder Abfragen der Datenbankinhalte über eine programmeigene Sprache vorzunehmen. Titleformatting in foobar2000 arbeitet beispielsweise auf dieser Ebene, der Anwender hantiert hier direkt mit den Feldnamen des Programms.

Winamp ist übrigens eine der wenigen Ausnahmen, bei denen eine solche Vereinheitlichung beim Bearbeiten der Tags nicht gegeben ist. Hier werden die Dialogfenster zum Taggen von den jeweiligen Input-Komponenten bereitgestellt und sehen demnach von Audioformat zu Audioformat anders aus. Mit Sicherheit eine verwirrende Erfahrung für einen Anwender, der beispielsweise das erste Mal die Tags einer Vorbis-Datei editiert.

3. Anzeige/Beschriftung in der Benutzeroberfläche

Die letzte und den meisten Anwendern wahrscheinlich am meisten vertraute Ebene sind die Beschriftungen der einzelnen Felder in der Programmoberfläche. Diese müssen nicht zwingend mit den Namen der zweiten Ebene identisch sein. So kann ein Feld beispielsweise intern im Programm als PUBLISHER geführt werden, während es auf der Oberfläche jedoch als "Label" angezeigt wird; gemeint ist hier die Plattenfirma, die ein Album veröffentlicht hat.

Hinzu kommt noch, dass Programme mehrsprachig sein können und somit nicht jedem Benutzer die gleichen Beschriftungen anzeigen. ARTIST kann so beispielsweise unter "Artist" aber auch "Künstler" zu finden sein.

Während diese Beschriftungen bei normalen Taggern fest vorgegeben sind, sind sie bei flexiblen Taggern frei definierbar. Bei foobar2000 und Mp3tag kann man es sich aussuchen, ob man die Feldnamen anzeigt bekommt oder eine eigene Beschriftung.

Wahl der Feldnamen.

Bei flexiblen Taggern kann der Benutzer seine eigenen Tags definieren. Dazu muss er sich für Feldnamen entscheiden, also Bezeichner für die im vorherigen Abschnitt beschriebene zweite, programminterne Ebene, die sich in der Konsequenz daraus natürlich auch für eine Beschriftung dieser Felder auf der dritten Ebene. Dabei hat er im Prinzip die freie Wahl.

Hier gibt es nun zwei gegensätzliche Strömungen oder genauer gesagt Nutzertypen, die schwierig unter einen Hut zu bringen sind.

(1) Die einen möchten gern eine Kompatibilität zu möglichst vielen Programmen herstellen, schlagen also in Listen wie ID3 Tag Mapping nach um Feldnamen auszuwählen, auf die sich ID3-Standard, Tagger oder eine Menge von Benutzern geeinigt haben. Nutzer wie diese würden nie auf die Idee kommen, anstelle von ARTIST ein Feld INTERPRET zu verwenden. Denn dieses würde als benutzerdefiniertes Feld geschrieben werden, und wäre in anderen Anwendungen ohne Unterstützung für flexibles Tagging nicht lesbar. Es wird deshalb als Vorteil angesehen, bei dem vordefinierten Feld ARTIST zu bleiben.

Dazu ein weiteres Beispiel: Es soll die Plattenfirma abgespeichert werden, die ein Album herausgegeben hat. Dazu würden sich beispielsweise PUBLISHER, LABEL oder RECORD LABEL anbieten. Da PUBLISHER in der Liste enthalten ist und in den passenden ID3v2-Frame TPUB geschrieben wird, bevorzugt diese Art von Nutzer dieses Feld. Wer im allgemeinen Sprachgebrauch "Label" präferiert, der kann die Anzeige des Tags immer noch an diese Bezeichnung anpassen. Bei foobar2000 würde man etwa unter Properties dialog fields den Wert "Label=PUBLISHER" hinzufügen (siehe Taggen von Audiodateien, Abschnitt "Eigene Felder definieren").

(2) Andere Nutzer wiederum legen weniger Wert darauf, mit möglich vielen Anwendungen kompatibel zu sein, sondern sind auf einen, maximal zwei Player bzw. Tagger beschränkt, und bevorzugen konsistente Feldnamen innerhalb ihrer eigenen Sammlung. Die Wahl eines passenden Namens sollte nicht unterschätzt werden, denn schließlich kommt man z.B. in der Titleformatting-Sprache laufend mit ihnen in Berührung. Wer sich einfach nicht an bestimmte Eigenheiten gewöhnen kann, wie z.B. dass einige Felder durch Leerzeichen getrennt werden und andere nicht, oder wem bestimmte Bezeichnungen nicht gefallen oder nicht aussagekräftig genug sind, der setzt halt seinen Standard durch. Wohl wissend, dass er damit drastisch an Kompatibilität verliert, gewinnt er damit möglicherweise an Bedienungskomfort.

Aus diesen widersprüchlichen Haltungen erklären sich einige kontroverse Diskussionen, die um dieses Thema geführt werden. Ich möchte es hier dabei belassen, beide Varianten möglichst neutral dargestellt zu haben.

Benutzerdefinierte Felder

Übrig bleibt die Erkenntnis, dass sich der Nutzer spätestens dann für einen Feldnamen entscheiden muss, wenn er eine Information ablegen möchte, für die bisher kein Feld vorgesehen ist, oder für die ein Feld zwar in Frage käme, aber die genaue Bedeutung der abgelegten Information, also die Semantik unklar werden würde. Auf dieses Thema möchte ich im nächsten Abschnitt näher eingehen.

Eindeutigkeit von Feldnamen.

Bei benutzerdefinierten Feldern kann der Nutzer seine eigene Fantasie spielen lassen und sich einen passenden Namen ausdenken, oder in der Community herumfragen, was andere für diesen Fall verwenden bzw. verwenden würden.

Frage: Was stellen Sie sich unter einem Feld LOCATION vor?

LOCATION könnte beispielsweise den Ort bezeichnen, an dem das Album aufgenommen wurde, oder das Land, in dem die Plattenfirma das Album veröffentlicht hat. Genauso gut könnten aber der Aufenthaltsort der CD oder der Pfad im Dateisystem gemeint sein, und mit ein wenig Fantasie sogar der Ort, an dem sich das Abspielen gerade dieser Musik besonders anbieten würde, oder aber auch der Ort, an dem man den Titel zuerst gehört hat.

War Ihre Vorstellung dabei, oder haben Sie gar an etwas anderes gedacht?

Unabhängig davon zeigt dieses Beispiel, dass es empfehlenswert ist, Feldnamen so zu wählen, dass sie aussagekräftig und eindeutig sind. Man mag dagegen argumentieren, dass man als Verwalter seiner eigenen Sammlung schon wisse, was das Feld bedeutet. Dem kann man entgegenhalten, dass ein Nutzer auch das Bedürfnis haben könnte, mehrere der aufgezählten Informationen abzulegen. Zu diesem Zweck würde ein Feld keineswegs reichen, und er müsste er sich dann Bezeichner wie z.B. RELEASE LOCATION, RECORDING LOCATION, CD LOCATION und so weiter ausdenken.

Diese Überlegungen lassen sich auf viele andere Beispiele übertragen. Es ist hilfreich, sich über solche Fragen frühzeitig Gedanken zu machen, denn nichts ist ärgerlicher, als seine eigentlich einmal als fertig abgelegten Alben nachträglich nochmal taggen zu müssen.

Benennungskonventionen

Der Feldname stammt generell aus der englischen Sprache und ist meist ein Substantiv (z.B. ARTIST, DATE, TITLE), gelegentlich bestehend aus mehreren Begriffen bzw. mit vorangestelltem Adjektiv (z.B. ARTIST WEBPAGE URL, ORIGINAL ALBUM), selten ein Partizip mit Präposition (z.B. REMIXED BY). Trennzeichen ist das Leerzeichen, Unterstriche sind dagegen nur bei technischen Bezeichnern innerhalb von foobar2000 üblich (z.B. MP3_STEREO_MODE).