Da mein Musikarchiv stetig wächst und vor kurzem die 50gig Marke erreicht hat bin ich auf eine übersichtliche Ordnerstruktur angewiesen. Im Moment fahre ich hiermit recht gut:
muZic\genre\subgenre\artist\album\artist - album - tracknumber - title.ogg

Dank allmusic.com konnte ich die einzelnen Bands besser nach genre/style einordnen.
In der Praxis sieht das so aus:

d:\muZic\Metal\Trash Metal\Metallica\Reload\Metallica - Reload - 01 - Fuel.ogg

Genauso mach ich das auch! Da sieht man alle wichtigen Infos auf einen Blick und findet man alles schnell!

Viele Grüße,
Dijo

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.

Ich bin sehr dafür, eine Sprache richtig (mit Leerzeichen, Groß/Klein etc) zu schreiben (das Wissen darum vorausgesetzt). Ich wollte damit nur ausdrücken, daß ich Leerzeichen unter Linux "quoten" muß, damit sie als Leerzeichen erkannt werden und nicht als Ende einer Befehlskette. O.k., ich kann in EAC automatisch Leerzeichen zu Unterstrichen umwandeln lassen.

2. Wenn ich unter Linux Dateinamen mit Umlauten auf Windowsdateisystemen erstellen, kann mir Windows diese Datei mit entsprechend unleserlichen Buchstaben zwar anzeigen, aber ich kann sie nicht umbenennen bzw. ansehen oder weiterverarbeiten. Das liegt an dem verwendetem Zeichensatz. Wenn ich nur auf einem OS arbeite oder Dateien übers Netzwerk schicke, habe ich diese Probleme nicht. Da ich aber nicht weiß, welche Dateisysteme die anderen Systeme (DVD-Player, iPod ...) verwenden, und um Probleme von vornherein zu vermeiden, nehme ich den kleinsten gemeinsamen Nenner und das ist m.A. FAT (8.3) ohne Sonderzeichen. Es ging Marius72 m.E. auch  um die Verwendung auf verschiedenen Systemen.

3.  Nein, das sind keine Dateinamen, sondern eine Datenbank im ASCII-Format mit acht Feldern und "##" als Trennzeichen. Ich könnte das ganze auch in eine SQL-Datenbank schreiben, aber für mich ist diese Form einfacher zu pflegen. Ich weiß auch um die Nachteile dieser Form und ich habe auch noch zwei andere Formen, die ich ineinander konvertieren könnte (In einer SQL-Datenbank würde ich je eine Tabelle für das Album und eine für die Lieder nehmen). Diese Form sollte auch nur eine Beispiel sein, welche sich bei mir bewährt hat. Nicht mehr und nicht weniger.

Der Sinn dieser Datenbank war ja der, daß ich bei Änderungen (so sie denn vorkommen), die Daten nur an einer Stelle (um Inkonsistenzen zu vermeiden) ändere und diese dann automatisch in die Tags geschrieben werden. Außerdem kann ich in den Tags auch Zeichen (z.B. "/") unterbringen, die im Dateinamen nicht erlaubt sind. Desweiteren kann ich für mich fehlerhafte freedb-Einträge korrigieren.

Ich wollte mit dem zweiten Post auch nur begründen, warum ich dies so mache und war in erster Linie als Antwort auf Marius72 Fragen gedacht; sollte keine "Missionierung" sein. Wenn ich "fremde" Sounddateien bekomme, werde ich diese an mein System anpassen und so werden es wohl auch andere machen, die eine gewisse Ordnung wünschen. Notwendig ist dies mit richtigen Tags ja nicht.

Gruss Jo

Leerzeichen im Dateiname machen mich kirre

Warum?LeerzeichenimDateinamenerhöhenmeinerMeinungnachebensowieineinemSatzdieLesbarkeit.
Prima,daßsoetwasinWindowsmöglichistundLeerstellennichtmehrdurchUnterstricheersetztwerdenmüssen.

Ob in Linux erstellte Dateinamen unter Windows lesbar sind, weiß ich nicht. Sollte es so sein, liegt es m. E. nicht an Umlauten. Jedenfalls kommt mein Windows sehr gut mit Umlauten und ß in Dateinamen zurecht.

Sind das  Dateinamen? Dieser oder jener beschütze mich vor solchem Horror.

Gruß
rhinozeros

</li> * 5b11b918##Anne Clark##the best of Anne Clark##1992##rock##01##Anne Clark##the sitting room

* 5b11b918##Anne Clark##the best of Anne Clark##1992##rock##02##Anne Clark##swimming

md5sum -b 5b11b918/Track01.flac

wget -x http://www.freedb.org/freedb/newage/5b11b918

dann daraus extrahieren oder gleich selbst eingeben.

Ja, alles Eigenbau (Linux). Skripte werden öfters mal neu geschrieben, weil ich die alten verschusselt habe oder mich nicht an den Namen erinnern kann. Da bin ich etwas chaotisch, außerdem rippe ich nicht regelmäßig und bei 1TB an Daten ist die Suche auch nicht so fix. Die Programmierung ist aber nicht wirklich schwer.

Ich schicke noch 'ne ausführlichere PM (Sorry, hab gar keine Berechtigung dazu); ich denke, daß mehr zu sehr vom Thema abweicht. Sollte größeres Interesse bestehen, kann ich möglicherweise einen eigenen Thread dazu erstellen.

Jo

Interessanter Ansatz.

Kannst du mal ein Beispiel aus deiner DB zeigen?
Wo bekommst du die Prüfsumme her?
Wie kommen die Tags in deine DB?
Hast du die Skripte selber erstellt?

ich halte die Künstlerinformationen ganz aus der Verzeichnisstruktur heraus:

FREEDB-ID1/Track01.flac
FREEDB-ID1/Track02.flac
         ...
FREEDB-ID2/Track01.flac

Dies zumindest bei CDs (Bisher hatte ich noch keine doppelten FREEDB-IDs). Für Vinyl habe ich eigene IDs eingeführt. Die Titelinformationen werden in einem ASCII-File (DB) gepflegt und daraus über Skripte die Audio-Dateien getaggt. Zusätzlich steht dort auch eine Prüfsumme drin; falls ich mal eine Datei 'verliere' und im 'Fundbüro' namenlos wiederfinde, kann ich sie über die Prüfsumme identifizieren. Ist die Datei korrupt, d.h. es ist eine Audiodatei, finde sie aber nicht in der DB, dann kann ich sowieso nichts mehr damit anfangen.

Der völlige Verzicht auf Titelinformationen im Dateipfad/-namen  hat den Vorteil, daß ich die Daten nur an einer Stelle (DB) pflegen muß. Außerdem habe ich keine systemübergreifenden Probleme mehr (Leerzeichen im Dateiname machen mich kirre, in Linux erstellte Namen mit Umlauten unter Windows nicht lesbar, ISO9660 kann auch nicht alle Zeichen im Dateinamen; daher Beschränkung auf 8.3 (DOS) Dateinamenlänge (8.4 bei *.flac)) Eine Sortierung macht der Player und selbst im Dateimanager werden die Tags angezeigt, also kann ich auf das humane Lesen der Namen gut verzichten.

Ich hatte es schon darauf reduziert, den Dateien als Namen die (md5)Prüfsumme + ext zu geben,  und dann alles in ein Verz. bzw. 0/ bis 9/ und a/ bis f/ sortiert, aber dann wird es aufwendiger, gesamte Alben zu kopieren, obwohl das mit Suchfunktionen (Skript) nicht wirklich kompliziert ist. Der Vorteil wäre aber, bei einer Konsistenzprüfung nicht auf eine DB zugreifen zu müssen, denn die Püfsummen könnte ich dem Dateinamen entnehmen.

Jo

Ehrlich gesagt, ich verstehe immer noch nicht, warum man sich so viel Arbeit mit den Dateinamen macht.

Es schadet ja nichts. Ich mache mir auch keine Arbeit damit, das erledigt alles EAC. Selten brauche ich noch zusätzlich ein gescheites Umbenennungswerkzeug.

Gruß
rhinozeros

Lediglich bei MP3 Playern mit reiner Ordner-Navigation mag die Namensgebung ja relevant sein, aber selbst die zeigen doch die wichtgsten Tags beim Abspielen im Display an. Also braucht man doch nur noch einen eindeutigen Pfad zum Auffinden eines Titels, der Rest erscheint mir eher überflüssig.

Gruß enkidu

Zu lange Dateinamen verursachen nicht selten Probleme.

Tut mir leid, aber mir war diese Aussage etwas schwammig. Wonach hätte ich da googeln sollen? Mit einem Hinweis auf Windows hätte ich etwas anfangen können. Zumindest hätte ich dann einen Ansatzpunkt für die Googelei gehabt. Jetzt weiß ich: Zu lange Dateinamen verursachen IMMER Probleme.

Entgegen der Warnung von Meiner Einer hab ich es natürlich probiert: Windows meckert, die betreffenden Dateien werden nicht verschoben oder kopiert, waren bei meinen Versuchen aber in jedem Fall noch am Quellort vorhanden. Das Speichern von Dateien, denen ich absichtlich zu lange Namen verpassen wollte, hat Windows glattweg verweigert, ein Speichern unter einem windowskonformen Namen war danach aber noch problemlos möglich.

Nachdem ich erfahren habe, daß der Unterschied zwischen FF und F4 nicht nur ein Bit, sondern 3 Bit beträgt, weiß ich jetzt auch, daß Dateinamen und Pfadangaben hinsichtlich ihrer Länge Restriktionen unterworfen sind. Danke! :D

Gruß und Frohe Ostern
rhinozeros

Im Normalfall wird bei der direkten Erstellung nichts weiter passieren, da sowohl der Win-Explorer als auch Anwenderprogramme dann schlicht und einfach eine Fehlermeldung ausgeben, das der Name zu lang ist. Entweder wird die Erstellung dann direkt verweigert oder der Dateiname gekürzt.

Ist mir in einem anderen Bereich (hat nix mit Musik zu tun) auch schon passiert, das z.B. Winrar "gemeckert" hat - eben weil dort beim Entpacken noch mal ein zusätzlicher Odner erstellt wird, in dem dann die entpackten Daten zu finden sind und der Pfad dadurch zu lang wurde. In dem Falle ist nichts passiert, eben weil Winrar sich geweigert hat.

Wirklich kritisch wird es, wenn man z.B. schon eine tiefgreifende Ordnerstruktur hat (lange Pfade / Namen) und auf die Idee kommt, den zugehörigen Hauptordner (der die Struktur enthält), in weitere Unterordner zu verschieben.
Nur soviel an dieser Stelle: Probiert es besser nicht aus...

start78,16.02.2010, 15:09 schrieb:

Zu lange Dateinamen verursachen nicht selten Probleme.

Was für Probleme könnten das sein? Mir ist bisher derartiges noch nie passiert.

...

In meinem Archiv gibt es eine Datei: F:\Musik\Rock\Anderson Bruford Wakeman Howe\1989 Anderson Bruford Wakeman Howe\03 Anderson Bruford Wakeman Howe - Brother Of Mine (I) The Big Dream (II) Nothing Can Come Between Us (III) Long Lost Brother.flac.
Dateiname: 130 Zeichen,
vollständiger Pfad: 210 Zeichen (die Zahlenangaben erfolgen wie stets ohne Gewähr).

Na und! Mein betagter Computer mit einem halbwegs gepflegten Windows XP Home kommt damit bestens zurecht. Wahrscheinlich ist das noch nicht das längste, was mein Archiv zu bieten hat. Ich war bloß zu faul, weiterzusuchen.

Wenn Du es genau wissen willst:

Wenn Du durch irgendeine Aktion für eine Datei einen längeren Pfad/Dateinamen erzeugst, verschwindet diese Datei im Nirvana. Viel Spaß beim wiederherstellen! Stell Dir vor, Du hättest Deine oben genannte Datei im Standardordner für "Eigene Musik" (C:\Dokumente und einstellungen...). Dann hättest Du ein Problem. Keine Ahnung, ob man solche Dateien mit einem Live-Linux wieder zurückholen kann...

Vor diesem Problem habe ich in anderen Foren schon öfter gestanden. Muss ich denn hier immer noch jede meiner Aussage belegen oder glaubt mir langsam mal jemand was auch einfach so bzw. sucht sich selbst den Beleg (Google: "windows länge von dateinamen")?

Was für Probleme könnten das sein? Mir ist bisher derartiges noch nie passiert.

Ich verstehe nicht ganz, warum viele Angst vor langen Dateinamen haben. Ich bekam neulich eine Mail mit einem Anhang namens brchprza.doc. Das erste, was ich nach dem Lesen tat, war, die Datei umzubenennen: 20100301 Brief von Manne an Chef - Preisänderung Zahnräder.doc. Vermutlich weiß Manne heute beim Lesen des Dateinamens auch nicht mehr, was da drin steht.

In meinem Archiv gibt es eine Datei: F:\Musik\Rock\Anderson Bruford Wakeman Howe\1989 Anderson Bruford Wakeman Howe\03 Anderson Bruford Wakeman Howe - Brother Of Mine (I) The Big Dream (II) Nothing Can Come Between Us (III) Long Lost Brother.flac.
Dateiname: 130 Zeichen,
vollständiger Pfad: 210 Zeichen (die Zahlenangaben erfolgen wie stets ohne Gewähr).

Na und! Mein betagter Computer mit einem halbwegs gepflegten Windows XP Home kommt damit bestens zurecht. Wahrscheinlich ist das noch nicht das längste, was mein Archiv zu bieten hat. Ich war bloß zu faul, weiterzusuchen.

Ansonsten ist das natürlich Geschmackssache. Ein jeder möge nach seiner Fasson glücklich werden.

@Meiner Einer: Bei mir befindet sich die Musik von Muddy Waters zurzeit noch in einem Verzeichnis mit der Bezeichnung "Waters, Muddy". Auch so ein Unsinn!

Gruß
rhinozeros