MP3tag mit knapp 200.000 Titel


#1

Hallo Kollegen!
Erstmal möcht ich dem Programmierer dieses geilen Tools danken! Weiter so...
Jetzt aber meine Frage(n) bzw. mein Anliegen:

Ich habe eine MP3-Sammlung mit ungefähr 200.000 Titel. Diese sind zum Teil bearbeitet und zum Teil nicht!
Hab leider schon mal knapp 700.000 Titel durch einen RAID-1-NAS-Crash verloren! Kauft euch kein Promise NAS! Taugt nichts.
Deshalb habe ich jetzt viele Titel, die ich "retten" konnte einfach mal auf das neue NAS (QNAP TS-212 mit Raid 1 und Replikation auf 2. NAS) kopiert! Die neuen Titel werden vorher mit MP3Tag bearbeitet und erst danach auf das NAS kopiert!
Bei Musikserver habe ich deshalb jetzt ein riesen grosses Durcheinander mit den TAGs.

Deshalb meine Frage: Wie habt ihr so ein Problem gelöst oder wie würdet ihr mir vorschlagen, dass ich an die Lösung des Problems mit MP3Tag ran gehe!
200.000 Titel in MP3Tag einlesen dauert jedesmal! Deshalb wäre eine andere Lösung gut - hab auch schon überlegt: gibt es irgendwie eine Möglichkeit "bearbeitete" Titel zu überspringen oder auszublenden?

Naja! Ich glaub ich bin vermutlich nicht der Einzige mit so einem Problem!
Danke im voraus für die Anregungen und Hilfe! Bin über jede gute Anregung/Hilfe dankbar...
LG Frank


#2

schneller starten geht eigentlich nur, wenn man nicht mehr einlesen muss.
Andere Programme sind vielleicht mit dem Start schneller, weil sie eine eigene Datenbank anlegen. Die sind dann allerdings langsam, wenn es um das registrieren von Änderungen gibt (es gibt hier zentnerweise Threads, die sich um das Verhalten von iTunes und vlc ranken).

Dann: wenn es einen Schwung Dateien gibt, die gut und einen anderen gibt, die noch zu bearbeiten sind, dann kann es u.U. notwendig sein, die unbearbeiteten mit den bearbeiteten zu vergleichen - man käme also nicht um das EInlesen der Sammlung herum, um den Vergleich zu ermöglichen.

Die einzige Möglichkeit besteht darin, die Sammlung soweit zu unterteilen, dass weniger auf einmal eingelesen werden muss.
Du kannst MP3tags Funktionen zum Umbenennen von Dateien und Verzeichnissen verwenden, um Dateien in unterschiedlichen Bearbeitungsstadien an spezielle Orte auf der Platte zu verschieben, um so die Menge an gleichzeitig zu lesenden Dateien zu reduzieren.
Generell können Dateien nach ein bis vielen benutzerdefinierten Kriterien gefiltert werden.


#3

Für meine Sammlung:

  • Alle einlesen,
  • in Blöcken markiert (nicht mehr als 20T),
  • alles in *.csvdateien in einer Liste sammeln
    ___(ab Spalte B einfügen oder Spalte A neu hinzufügen:Zweck nummerierung),
  • jede Spalte mit Filter belegen.

Vorgehensweise:

  • Interpreten filtern z.b. ABBA
  • Titel sortieren
  • Titel korrigieren
  • speichern in neuer Datei oder Tabelle (sortiert nach _folderpath)

Ändern:

  • Nach _folderpfad sortieren in mp3tag
  • Nach _folderpfad sortieren in Datei oder Tabelle
  • ein Lw. oder eine Partition oder einen Ordner wählen in mp3tag
  • ein Lw. oder eine Partition oder einen Ordner wählen in Datei oder Tabelle (sortiert nach _folderpath)
  • Änderungen per Textdatei-import in mp3tag vornehmen
  • Dateiname auswählen
  • Formatstring definieren

#4

Immer nur Teile bearbeiten - niemals 200.000 Titel auf einmal!
Ich bin folgendermaßen vorgegangen:

  • 2 Verzeichnisse, die den Bearbeitungsstatus repräsentieren
  • 1 Verzeichnis für unbearbeitete MP3s
  • 1 Verzeichnis für bearbeitete MP3s

Sobald ein Teil der Tags der MP3s bearbeitet wurden, habe ich diese nach dem Muster (Verzeichnisebenen) \artist\album\track in das Verzeichnis für bearbeitete MP3s per Tag-Dateiname verschoben. Die Verzeichnisstruktur wurde niemals von Hand abgeändert. Die Informationsquelle waren immer nur die Taginhalte. Auch wenn etwas geändert werden musste - immer die gleiche Reihenfolge: 1. Tag ändern, 2. Verschieben mit Tag-Dateiname.
Alle Verzeichnisse enthalten ausschließlich mp3-Dateien, keine m3u-, jpg-, lrc-Dateien usw., damit diese beim Verschieben mit Tag-Dateiname nicht separat "hinterher geschoben" werden müssen. Die dabei entstehenden Leer-Verzeichnisse habe ich später mit einem externen Tool gelöscht.

So füllt sich das Verzeichnis für bearbeitete MP3s immer mehr, während
die MP3s im Verzeichnis für unbearbeitete MP3s immer weniger werden.

PS.: permanente Sicherungskopie nicht vergessen!

Verzeichnisstruktur
Mein Beitrag vom 24.12.2007 hat zwar großen Anklang gefunden, ist aber inzwischen veraltet. Die Überarbeitung vom 21.02.2011 Organisieren von Compilations
beschreibt die hierarchische Verzeichnisstruktur ausführlich. Hinweise zum Genre gibt es unter Beschreibung der Musikkategorie.


#5

Sooo lange dauert das Einlesen ja gar nicht (jedenfalls bei 100 000 Titeln, mit mehr habe ich keine Erfahrung). Ansonsten arbeite ich nun gerne mit foobar und Mp3Tag parallel. In foobar sind alle Titel in einer Datenbank ("media library") und Änderungen an einzelnen Dateien werden erstaunlich schnell erkannt. Dort kann man flexibel filtern, u. a. auch nach %last_modified% (also letzte Änderung), und das Ergebnis kannst Du per drag & drop nach Mp3Tag übertragen (geht auch mit vielen Titeln).

Ansonsten mache ich es so wie die anderen: Es gibt eine Ordnerstruktur, in die nur Dateien kommen, die eine gewisse Mindestqualität aufweisen (Metadaten einmal bearbeitet). Alles unbearbeitete liegt mehr oder weniger unsortiert in einem Neu-Ordner. Daraus kann ich beliebige Teilmengen einlesen, bearbeiten und in die Struktur verschieben.

(Ich hab auch ein QNAP-Nas, aber das ersetzt natürlichen keinen Backup.)


#6

Was mich interessiert: Läßt sich diese Menge in einem einzigen Vorgang von MP3TAG einlesen?


#7

Die besagte Menge war's zwar nicht bei mir aber annähernd ca 6 HT. (2 zusätzliche ext. Multimedia).
Im Vorfeld alle Verzeichnisse (Festplatten/Partitionen) gesucht über Total Commander.
Nur die/den Pfad/Pfade z.b.: "Z:\Musik\\" angelegt, alle im Editor erfasst und als *.m3u abgespeichert.

Hat supi geklappt und der Einlesevorgang ist komischerweise effizienter ( Zeit ) als die
komplette Festplatte/Partition durchsuchen zu lassen.


#8

... bei ist irgendwo zwischen 30000 und 50000 Tracks Schluss. Mehr geht in mp3tag nicht 'rein!


#9

Wie sieht denn deine Performance im Taskmanager aus:

    • CPU-Auslastung
    • Auslagerungsdatei
    • und und und

hier der meine "Tm" mal




#10
    • CPU-Auslastung = 55 %
    • Auslagerungsdatei = 1,35 GB
    • und und und: 2 GB RAM, 2-Kern-Prozessor 2,7GHz, WinXP SP3
      Viele Tracks haben ein Cover hinterlegt (eingebettet).
      Neben Firefox und Winamp keine weiteren Programe geöffnet.

#11

Aua - das sieht sehr viel aus für nebenbei "Firefox und Winamp"

Hast du sämtliche nichtgebrauchten Dienste ausgeschaltet/deaktiviert
Hast du "C" ausreichend gross

versuch mal:

  • die Dienste die nicht gebraucht werden im Hintergrund zu deaktivieren/ausschalten
  • Leistung statt Aussehen zu optimieren

wenn du wie in anderen Thread's beschrieben hast, deine *.m3u's so aufgebaut sind, dürfte die CPU-A. nicht so hoch sein

versuch mal die Auslagerungsd. zu vergrössern ( Temp/Cache was auch immer )

Edit: lese deine Dateien versuchsweise mal ohne Covererkennung ein :rolleyes:


#12

So mal eben die, im oben gezeigten Pic., *.m3u eingelesen.
Sage und schreibe 42 Minuten für die Menge an Dateien gebraucht.
Taskmanager kam nicht über 7% drüber, zur Zeit 29 Prozesse am laufen.
Keinerlei weiteren Schnickschnack offen :wink:


#13
Frage:
Wie lang dauert es bei euch

sagen wir mal

100.000 oder 200.000 Tracks

einzulesen ?

Wie die Vorgehensweise ?

würd mich doch'e mal interessieren :huh:


#14

vgl.28.09.11
sämtliche nichtgebrauchten Dienste ausgeschaltet/deaktiviert? TEILWEISE
"C" ausreichend gross? JA
Leistung statt Aussehen zu optimieren? JA
Auslagerungsdatei vergrössern? OHNE EINFLUSS
Dateien versuchsweise ohne Covererkennung einlesen? HABE ICH NOCH NICHT


#15

PC-Bremse
hast du mal einen PC-Check vorgenommen z.b. defrag usw.?
Lokalitäts-Bremse
Liegen die Partitionen im direktem Zugriff des PC's, oder eher per USB externe Festplatten?


#16

PC-Bremse - wird gepflegt mit TuneUp 2006
Lokalitäts-Bremse - läuft alles auf NAS


#17

Dann wüsste ich nicht vorher das Verhalten bei dir so ist, einlesen nur bis - 50000 Tr.


#18

Danke - mir war schon schleierhaft, was die Festplattenkapazität (und Fragmentierung) damit zu tun haben sollte...

Ich vermute mal, dass die Menge der maximal möglichen Titel mit der Größe der Tag-Inhalte zu tun hat. Und so, wie ich deine Sammlung einschätze, sind die Tags eher mit mehr als mit weniger Daten gefüllt. Zusammen mit meiner Beobachtung, dass bei 2,5GB RAM-Belegung Schluss ist, wird es wohl erst dann signifikant größere Mengen einzulesender Dateien geben, wenn der maximal mögliche Adressraum ansteigt.
Und das wäre wohl erst mit der 64-bit-Version von MP3tag so.
Bis dahin wirst du wohl mit der schon bekannten Beschränkungen leben müssen.
Entsprechend fruchtlos werden alle Rekordversuche a la "ich kann aber mehr Datensätze lesen" bleiben.


#19

... dann werde ich wohl warten müssen. Ich danke allen, die mir mit Hinweisen geholfen haben.