E i n l e i t u n g
Meinen Beitrag im MP3-Forum vom 23.12.07 http://www.anytag.de/forums/index.php?show...preten-CD&st=30 zum Thema "MP3 Kollektion Struktur" aktualisiere ich hiermit.
Ich habe mein Konzept MP3-Verzeichnis-Struktur mehrfach verfeinert und meinen Bedürfnissen angepasst. Ich sammle so gut wie nur ganze Alben. Dazu benutze ich über die Standards hinaus die sogen. „erweiterte Tag-Felder“; Details siehe unten.
A: A l l g e m e i n e Z i e l e
Ich habe einen Workflow „unbearbeitet – in Bearbeitung – fertig“ eingeführt.
1.) Es erfolgt eine sortenreine Trennung zwischen Interpreten-Alben und Sampler-Alben. Tracks ohne Alben-Zugehörigkeit gelten bei mir als „unbearbeitet“. Die niedrigste Verzeichniseinheit ist das Album. Innerhalb dieser sind die Tracks als Dateien numerisch geordnet wie auf der Original-CD. Das %genre%-Feld wird nicht in dem Aufbau der MP3-Verzeichnis-Struktur einbezogen, es wird jedoch inhaltlich belegt. Z. Zt. sind drei Content-Gruppen definiert:
1. Rock-Pop-Jazz und Verwandtes, Kürzel: RPJ
2. Klassik und Verwandtes, Kürzel: Kla
3. Hör-Bücher/Spiele, Literatur, Lesungen, Dokumentationen, Comedy u. dgl. (alles was nicht Musik ist) und Verwandtes, Kürzel: Hör
2.) Vermeidung von Redundanzen: Die relevanten Informationen sind nur in MP3-Tags gespeichert und sind nicht etwa ursächlicher Bestandteil der Verzeichnisnamen. Pfade und ggf. Playlisten werden vollständig aus den MP3-Informationen generiert. Es gilt der Grundsatz: Jede Information wird nur einmal verwendet und damit auch nur an einer Stelle editiert.
3.) Die sogen. Arbeitsverzeichnisse enthalten nur mp3-Dateien, flag- und andere Sounddateien, die mit dem MP3TAG-Editor bearbeitet werden können. Andere Dateien werden entweder
1. "ausgelagert" in ein Verzeichnis namens "Zusatzinformation (kurz: Zus)"; oder
2. als sogen. Containerdatei „mitgeschleppt“ (vgl. dazu mp3tag-Forumsbeitrag „Cover-Container“). Dazu gehören "artfremde" Dateien wie PDF, HTM, XLS, TXT, JPG, GIF, BMP usw. Cover-Dateien werden als JPG’s in der MP3-Datei selbst integriert (eingebettet) und danach als Datei gelöscht. Das Einbetten von Lyrik-Texten wird derzeit nur sporadisch realisiert.
B: D u r c h f ü h r u n g
Bei einer großen Menge an MP3s wird natürlich eine "Vorsortierung" benötigt, denn mehrere Tausend Ordner auf einer Ebene sich nicht vernünftig zu handhaben. Als Vorsortierung wird das Feld %partinset% folgendermaßen benutzt.
1. bei Interpreten-Alben der Anfangsbuchstabe des Interpreten "A“ bis „Z" und bei
2. Sampler-Alben (Compilation-CD) die "Jahrzehnte" des Erscheinungsjahres „199x“ usw.
Einige erweiterte Tag-Felder wurden dazu zweckentfremdet. Die Hierarchie ergibt sich aus folgender Liste:
1.) %fileowner%\ Herkunftskürzel 5-stellig
2.) %contentgroup%\ Unterscheidung zwischen Interpreten-Alben (Kürzel: Interpr) und Sampler-Alben bzw. Compilation-CD (Kürzel: Sampler)
3.) %partinset%\ Vorsortierung, z.B. A, B, C, D bzw. 197x, 198x, 199x, 200x usw. (s.o.)
4.) danach folgen die Standard-Tag-Felder %artist%, %year%, %album%, %track%, %title% und nur optional %genre%. %comment% wird standardmäßig nicht verwendet (bzw. kann für Besonderheiten herangezogen werden). In einigen Fällen wurden jedoch sinnvolle Zusatzinformationen wie Ursprungspfad ö. ä. eingetragen.
Konkret sieht dann der Verzeichnispfad mit Dateiname dann folgendermaßen aus:
1. bei Interpreten-Alben
...\%fileowner%\%contentgroup%\%partinset%\%artist%\%year% - %album%\%track%. %title%
2. Sampler-Alben
...\%fileowner%\%contentgroup%\%partinset%\%year%\%album%\%track%. %title% - %artist%
zusätztlich wird das Tag %iTunesCompilation% = 1 gesetzt.
In Kombination mit den drei Content-Gruppen hat das Feld %contentgroup% dann genau 6 Varianten: RPJ-Interpr, Kla-Interpr, Hör-Interpr, RPJ-Sampler, Kla-Sampler, Hör-Sampler.
C: M e r k m a l e
1.) Gewährleistet ist eine gleich hohe Verzeichnistiefe bei Nicht-Samplern (Interpreten-Alben) und Samplern (Compilation-CD), kein Mischmasch bei der Anzahl der Ebenen (Verzeichnistiefen). Doppelalben oder Boxsets werden als zwei oder mehr Alben mit dem Zusatz CD 1 und CD 2 usw. behandelt. Damit gibt keinen "Ermessenspielraum" in dem Verzeichnisaufbau. Die Eindeutigkeit der Struktur ermöglicht dem zufolge auch eine logische Erweiterbarkeit.
2.) Jedes TAG-Feld wird genau nur einmal in dem Verzeichnispfad mit Dateiname abgebildet (keine Redundanz). Daraus lassen sich beliebige Strukturen und ggf. auch Playlisten automatisch neu generieren. Allerdings immer getrennt nach Interpreten-Alben und Samplern. Z.B. als Formatstring (siehe oben) oder Tausende Playlisten jeweils pro Album:
1. bei Interpreten-Alben
...\%fileowner%\%contentgroup%\%partinset%\%artist%\%year% - %Album%\_PL-INTERPR - %artist% - %year% - %album%.m3u
2. Sampler-Alben
...\%fileowner%\%contentgroup%\%partinset%\%year%\%Album%\_PL-SAMPLER - %year% - %album%.m3u
3.) Zwangsläufig ergibt sich eine
1. alphabetische Ordnung für Interpreten-CD und
2. eine chronologische Ordnung für Compilation-CD.
Die Struktur ist also gleichzeitig eine Directory-Datenbank!
4.) Dieses Schema ist für Sammler, die nur einzelne Tracks sammeln, wenig geeignet, außer es wird eine gesonderte Struktur für „Nicht-Alben-zugehörige Tracks“ entworfen, wie eingangs angedeutet.
S c h l u s s b e m e r k u n g
Es führt kein Weg daran vorbei, die TAG-Felder manuell so wie oben beschrieben anzupassen. Allerdings gibt es dazu viele Hilfen wie FreeDB, MusikBrainZ usw. Wenn bedarfsweise für jedes Album noch ein Cover eingebettet werden soll, hilft Amazon.de weiter. Dessen Qualität reicht für die Anzeige auf einem iPod aus. Die Ebene „Herkunftskürzel“ %fileowner% (5-stellig) könnte auch weggelassen werden, ohne dass an dem Aufbau der restlichen Struktur etwas geändert werden müsste.
Wie schon gesagt: Das Ergebnis der obigen Beschreibung ist eine hierarchische Verzeichnisstruktur, die wie eine "Datenbank" Eindeutigkeit berücksichtigt. Damit bleibt diese erweiterungs- und anpassungsfähig.