Ich habe ca. 260.000 MP3-Tracks, das sind mehr als 2 GB. Alle Tracks haben ein Cover eingebettet. Die Tracks sind in 26 Ordnern für jeden Anfangsbuchstaben organisiert. Installiert ist MP3TAG 2.7 auf Win7 64bit.
Es wäre für mich ein Segen, wenn ich alle Tracks in einer Session laden könnte, auch wenn es Stunden dauern würde. Tatsächlich muss ich jeden Ordnern mit einem Anfangsbuchstaben einzeln laden. Die Grenze liegt irgendwo bei 30.000 Tracks.
Mp3Tag ist für mich mehr ein Tool für Sachen die andere Programme nicht so gut können. 
Meine sehr große Sammling an mp3's und Flac verwalte ich mit MusicBee.
Das Programm kann ein paar hundertausend Tracks fix und ohne murren auf einmal taggen. Alle mit Cover embedded. Monkeymedia sollte das auch können.
Ich denke einfach mal probieren.
Für Spezialaufgaben ist mp3tag aber kaum zu toppen.
Dank an Florin
"MediaMonkey" kann das zwar auch, stimmt. Aber für alltägliche Tagging-Arbeiten würde ich mich nicht auf die Tagging-Funktionen von MediaMonkey verlassen. Zwischen jeder Version verschlimmbessern die Entwickler leider wieder irgendwas an den Funktionen. Wenn man nicht höllisch aufpasst, hat man sehr schnell irgendwelche bestehenden Daten zerschossen.
Zudem ist das Zusammenspiel "Tags nur in Dateien" und "Tags nur in der Datenbank" sehr gewöhnungsbedürftig. Nicht selten sind die beiden nicht synchron und man sucht sich dumm und dämlich, wieso am einen Ort Daten drin sind, am anderen Ort nicht. Wer dann noch beginnt, mobile Geräte zu synchroniseren hat verloren, bevor er richtig damit anfängt.
Ich will damit aber nicht sagen, MediaMonkey sei schleicht, ganz im Gegenteil. Man bekommt damit Bereinigungsläufe hin, da kann man in Mp3tag nur davon träumen. Oder z.B. Duplikate erkennen. Aber eben: Man muss einfach seeeeehr genau testen, bevor man seine produktive Sounddaten verändert. Dafür funktioniert das dann auch mit mehreren Hunderttausend Stücken problemlos.
Nach meiner Erfahrung gibt es nur ganz wenige Arbeiten, die man mit der kompletten Sammlung ausführen muss. Meistens geht es um Subset von Dateien/Datensätzen.
Mp3tag ist ein Programm zum Taggen. Wenn es aber um meine ganze Sammlung geht, dann verwende ich Programm, aus dem ich mir dann ggf. das Subset heraushole und das dann mit Mp3tag bearbeite.
Die Schnittstellen sind dabei unterschiedlich komfortabel - als Beispiel: iTunes erlaubt D&D in Mp3tag, der WMP muss erst eine Playlist erzeugen.
Egal wie: bei diesem Vorgehen ist das Laden aller Dateien nicht notwendig.
Das kommt bei mir eigentlich nur vor, wenn ich von allen Dateien die Cover exportieren will oder einen Mega-Export erzeugen will. Aber sonst ...
MM habe ich nur erwähnt weil ich es früher zum sync meines Ipod classic benötigte.
Heute läuft RockBox auf dem Ipod. So geht alles easy mit MusicBee.
Ich sprach von MusicBee! (getmusicbee.com)
Das Programm kann ohne einen extra Import einfach den Verzeichmisbaum einlesen. Dann lassen sich alle Tags wie Genre in einem Rutsch bearbeiten. Läuft mit NET. Hatte nie ein Speicherproblem.
Das Beste, es is Freeware
Thanks Steven.
Und schon wieder sind wir zweieinhalb Jahre weiter, die Welt arbeitet mit Windows 10 und bald gibt es keine 32Bit-Rechner mehr - wofür auch?!
Es nutzt hier auch nichts, den Bedarf zu diskutieren, er ist schlicht und ergreifend da.
Nur 30000 Dateien auf einmal laden zu können, ist Kindergeburtstag - ich muss alle Handgriffe zig mal wiederholen. 
Und das, obwohl ich eine Kiste habe, die gaaaaaanz viel mehr in den Speicher laden könnte, wenn sie dürfte...
Der Support für Matroska MKA/MKV files hätte stattdessen gerne noch etwas auf sich warten lassen können.
Was sind denn so deine typischen Tätigkeiten?
Für "gängige" Tag/Dateiname/Verzeichnis Sortier/Aufräum Funktionen gibts auch andere Lösungen.
Nimm es mir nicht übel, aber ehrlich gesagt sind die zu umfangreich, um sie hier jetzt alle explizit aufzulisten und am Ende ein "Tja, dann wird Dir wohl nichts anderes übrig bleiben" dafür zu ernten.
Ich habe sehr viele, spezielle Skripte in MP3Tag angefertigt und auch bereits sehr viel Ausschau nach Alternativen gehalten, aber bisher ist noch kein Programm so sehr an die Fähigkeiten von MP3Tag herangekommen, dass es Selbiges ersetzen könnte.
Ich gebe dir recht, dass ich speziell dieses Feature auch schon öfters vermisst habe.
Ich unterstelle ab und zu, dass zwei Dateien, die ich eigentlich bearbeiten müsste, an entgegengesetzten Enden meiner Sammlung sind. Und die kriege ich komplett nicht mehr in einem Rutsch geladen.
Andererseits denke ich mir dann: eine Sammlung mit mehr als der jetzt möglichen Anzahl Dateien zu laden, wird Stunden dauern. Und ist es das dann wert, frage ich mich.
Mein aktueller Ausweg ist eben wirklich ein Programm wie iTunes oder WMP zu verwenden, die leidlich mit der Sammlung zu Rande kommen und dort eine Auswahl zu treffen, die dann in MP3tag (schnell) bearbeitet wird.
Für die von dir gewünschte sachliche Auseinandersetzung sind allerdings Einschätzungen wie
wenig förderlich.
du, kein Stress,war nur eine Frage.
Für einige typtische "haushalts"-Tätigkeiten gibt es halt Lösungen (mediapurge z.B.)
Für komplexe - mp3tag spezifischen - Scripte natürlich nicht.
Schade ist halt, dass Florian sich hierzu nie geäußert hat, woran es da jetzt hakt, bzw. ob ich mit meinen Vermutungen recht habe.
(Hab ja schon x64 Migrationen hinter mir und kenne die Problematik durchaus)
Andererseits ist halt auch die Frage die ich mir Stelle: Warum muss MP3Tag für diese Verarbeitungen so viel im Speicher halten und kann nicht einfach Datei für Datei verarbeiten.
(hier mag natürlich sein, dass dies aufgrund irgend einer Funktionalität die ich nicht kenne nötig ist - vermutlich sogar) Aber das Thema wäre halt mal zu Besprechen. Vielleicht helfen ja mal Denkanstöße von außen.
Schnelligkeit?
Wenn MP3tag sich für eine Filterung oder Sortierung erst alle Dateien wieder einzeln von der Platte pflücken muss, um zu sehen, ob die Daten der Datei gezeigt werden sollen oder nicht, ob sie zu einer anderen Anordnung führen oder nicht, dann dauert die Aktualisierung der Dateiliste gefühlt ewig, speziell bei den dann verwalteten Datenmengen.
So denke ich mir das.
Nur die Metadaten von einigen 100.000 Dateien sind auch nicht sooo gigantisch, das passt in den Speicher.
Der Speicher lässt sich jetzt schlecht schätzen weil ich nicht weiß was er alles erfasst, aber organisiert in einer Datenbank (embedded) muss nicht einmal alles davon im Speicher liegen. Mit einem passenden Index ist die Suche dann trotzdem flott.
Von sowas wie den Covern reichen auch Metadaten größe/format/etc. auf was anders wirst du eh nicht filtern.
Ich überschlag hier nur grob, aber komm bei den Dateimengen die hier angegeben werden nicht auf die Datenmengen.
Das Thema können wir
Hallo zusammen,
erstmal vorab — ich arbeite momentan nicht an einer 64-bit Version. Das hat vor allem den Grund, dass die Code-Basis von Mp3tag inkl. aller Bibliotheken recht groß ist und der Aufwand all das durchzugehen momentan meine Kapazitäten übersteigt. Außerdem war ich bis jetzt auch nicht so überzeugt von der Notwendigkeit einer 64-bit Version 
Die verschiedenen Beiträge hier und anderswo haben mich motiviert, die Verwaltung von Album-Cover und Metadaten in Mp3tag grundlegend zu überdenken und neu zu entwerfen. Ich hab so die letzten Tage damit zugebracht, das Ganze umzubauen und hab das Resultat im aktuellen Development Build veröffentlicht.
Mit dieser Version sollte der Speicherverbrauch signifikant reduziert sein (~40-50% in meinen Tests). Damit können manche Bibliotheken die vorher zu groß waren, nun auch mit Mp3tag verwaltet werden ohne dass der adressierbare Speicher nicht ausreicht.
Die Cover der Dateien werden jetzt im lokalen Dateisystem gespeichert (%APPDATA%\Mp3tag\data\library) und auch das Handling von Zeichenketten hab ich komplett überarbeitet.
Ich würde mich freuen, wenn ihr das Ganze mal ausprobieren und mir hier oder per E-Mail Feedback dazu geben könntet.
Viele Grüße
— Florian
Nach einem erfolgreichen Versuch, etliche Dateien mit der neuen Version einzulesen, enthielt das Cover-Verzeichnis 1,6 GB Daten, der belegte Speicher stieg beim Einlesen von 1,2 auf 1,8 GB, so dass damit, wenn die Cover nicht ausgelagert gewesen wären, die magischen 3,5GB erreicht gewesen wären, die sonst immer zum Crash führen.
Bei mir hat es was gebracht.
... Auch wenn das Einlesen von diesen Mengen Dateien wirklich lange dauert (eher im Stundenbereich als im Viertelstundenbereich) und ich vermutlich in den allermeisten Fällen mit einer Auswahl arbeiten werde. Aber dass es die Möglichkeit jetzt gibt ... Super.
wenig verwunderlich, hatte ich schon ein paar mal gemutmaßt...
40-50%? dann war es aber mal Zeit. Aber ich kenn das, never touch a running system
Ich hatte zwar in Richtung einer embedded Datenbank gedacht die du - natürlich nicht permanent sondern nur temporär pro session aufbaust - gedacht, die hätte dir das ganze Handling abgenommen. Aber letztlich wird dein neues Handling auf's selbe hinauslaufen.
Metadaten im Speicher und BLOBs auf der Platte.
Jup, das sollte es bringen.
Ich habe meinen ersten Einlese-Versuch mit der neuen Version 2.85a nach 90 Minuten warten - ungefähr bei einem Drittel des Fortschrittsbalkens - abgebrochen. Der Taskmanager zeigt dabei 1.9GB RAM-Verbrauch an. (Diese Verzeichnisse wären ein Sechstel meiner Gesamtsammlung.)
Vielleicht probiere ich es in den nächsten Tagen nochmal. Da nach diesen 90 Minuten aber nicht mal ein Bruchteil meiner Sammlung eingelesen war, wäre das für meine Datenmenge leider keine Alternative.
Die verbesserte Speicherverwaltung mag ein Ansatz sein. Wenn aber das Einlesen dafür mehrere Stunden oder gar Tage benötigt, ist das für einen wiederholte Durchführung leider keine praktikable Lösung.
Diese Aussage ist nicht allgemeingültig und trifft insbesondere bei ein paar Hundert oder ein paar Tausend Stücke nicht zu.
Ich habe auch mal erste Tests durchgeführt und seit ewigen Zeiten mal wieder meinen kompletten Bestand im Bereich der populären Musik eingelesen.
MP3Tag behauptete, es würde ca. 260.000 Dateien laden, dabei wurden wohl aber die in meinem Fall recht zahlreichen externen Cover-Dateien u.a. in den Albumordnern vorhandenen Dateien mit berücksichtigt.
Insgesamt habe ich den Bestand bisher 3 x eingelesen. 2 x wurde der komplette Bestand ohne Murren geladen, 1 x erfolgte kurz vor Ende ein Absturz. Der Ressourcenmonitor von Windows behauptet, dass MP3Tag ca. 1,4 GB an RAM belegt. Mein PC mit Windows 10 hat 16 GB RAM, wovon natürlich MP3Tag als 32-Bit-Programm nicht alles nutzen kann.
Der Ladevorgang ging bei mir eigentlich recht schnell und dauerte 35 Minuten. Meine Musik liegt auf einer normalen Festplatte, der %appdata%-Ordner liegt auf meiner SSD.
Erfreulich ist, dass wohl nicht pro Musikdatei die Cover-Dateien einzeln in der Cover-Library landen sondern Redundanz vermieden wird. Anders wären die lediglich ca. 16.000 Cover-Dateien in meinem %appdata%-Ordner nicht zu erklären.
Eigentlich arbeite ich in der Praxis fast immer an den Tags nur mit einem kleinen Datenbestand, den ich bei Bedarf mit der "Windows Advanced Query Syntax" vorfiltere. Diese Vorgehensweise bot sich notgedrungen an, da mit fortschreitender Bearbeitung des Bestandes eine Menge an Dateien erreicht war, die MP3Tag sowieso nicht mehr schlucken konnte und mir das Laden des kompletten Bestandes viel zu lange dauerte.
Lediglich beim Export meiner HTML-Liste, was so alle paar Monate geschieht, fehlte mir die Möglichkeit , alle Dateien in MP3Tag present zu haben, wirklich.
Der Export scheiterte allerdings auch jetzt während der Erstellung wegen zu wenig RAM.
Ich hoffe jedoch, durch diese neue Struktur größere Häppchen erzeugen zu können und meine Export-Datei vielleicht nur noch aus 2 einzelnen Teilen zusamenkleben zu müssen. Bisher brauchte ich 3-4.
Zur Beurteilung der doch positiven Performance muss ich wohl auch auf meine besonderen Gegebenheiten eingehen:
Ich bette in die Musikdateien nur das Frontcover ein und das mit einer Auflösung von 800x800 und etwas stärkerer Kompression als der Standard. So liegt die Größe meiner eingebetteten Cover je nach Bildinhalt so zwischen 40 - 150 KB. Die anderen Cover-Dateien (sofern vorhanden) liegen bei mir in höherer Auflösung im Albumordner. Der Cover-Ordner in %appdata% belegt nach dem o.a. Ladevorgang auch nur ca. 1 GB.
Der %appdata%-Ordner liegt auf meiner SSD, womit auch zügiges Speichern durch MP3Ttag gewährleistet ist.
Ich kann mir vorstellen, dass bei Leuten mit mehreren und noch größeren eingebetteten Dateien durchaus Platz und auch Performance-Probleme auftreten könnten. Wenn jemand eine MP3-Datei mit der Netto-Größe von 4 MB durch Cover auf 30 MB aufbläht, dauert das ganze womöglich sehr viel länger und belegt auch sehr viel mehr Platz auf der standardmäßig dafür vorgesehenen Systemplatte.
Da könnte auch schon mal ein PC von der Stange mit oftmals sehr kleiner SSD als Systemplatte in die Platzbredouille kommen.
@Florian
Sähest Du eine Möglichkeit dieses Feature als Option auswählbar zu machen, also ein Options-Häkchen zu setzen für "Cover-Dateien auf Festplatte zwischenspeichern" oder wäre diese zweigleisige Vorgehensweise zu kompliziert?
Vielleicht sollte man dem Benutzer auch eine Möglichkeit bieten, den Ort für den "library\covers-Ordner" außerhalb der Standardörtlichkeit selbst zu bestimmen.
Wie robust ist eigentlich die Methode? Es ist ja wohl erforderlich, bei jedem Refresh des geladenen Datenbestandes einen Abgleich durchzuführen?
Müssen wir hier eventuell in Zukunft auch für MP3Tag (wie bei diversen Playern) den Rat geben, mal den Cache zu leeren, wenn sich jemand meldet, er sähe in MP3Tag nicht das abgespeicherte Bild?
Wahrscheinlich wird es ohnehin erforderlich sein diesen Cache-Ordner dann und wann zu leeren, um den Ordner von Altlasten zu befreien? In dem Fall wäre für etwas weniger erfahrene Nutzer wohl eine MP3Tag-Funktion im Programm zu empfehlen (Reset des Cover-Caches).
Zusammenfassend darf natürlich nicht das Lob fehlen, dass Du Dich dieses Speicherplatzproblems angenommen hast.
Zusammen mit dem in Version 2.85 enthaltenen Fix für das Speicherleck bei der Verwendung von Tools bringt das mir persönlich doch sehr viel besseres Handling.
Ein Wunsch verbleibt in dem Zusammenhang jedoch:
MP3Tag sollte bei Speichermangel nicht einfach abstürzen sondern irgendwie kontrollierter vorgehen.
In meinem o.a. angeführten Absturz durch Speichermangel beim Export wäre es sehr viel netter gewesen, MP3Tag hätte lediglich den Export mit einer Fehlermeldung abgebrochen statt sich selbst einfach zu beenden und der damit verbundenen Notwendigkeit alle Files für eine halbe Stunde erneut laden zu müssen.
Danke für Deine Erkenntnisse, poster!
Aufgrund Deiner Erklärungen habe ich das \cover Verzeichnis von meiner "langsamen" internen SATA-Harddisk auf meine schnellere SSD umgeleitet.
Das bringt bei mir geschwindigkeitsmässig weder beim ersten Erstellen der Covers noch bei den folgenden Rückgriffen auf die gleichen bestehenden Covers einen messbaren Vorteil. Ich sass nicht mit der Stoppuhr davor, hab nur die Sekundenanzeige der Windows-Uhr notiert. Der Unterschied liegt für 10'000 Test-Mp3 im einstelligen Bereich.
Das wirklich Langsame ist bei mir das Einlesen der Metadaten ab meinem NAS.
Obwohl dieses mit Gigabit intern im LAN hängt, benötigen 10'000 mp3 rund 10 Minuten. Bei meiner Datenmenge ist es unmöglich, sämtliche mp3 auf SSD zu halten (ausser ich würde im Lotto gewinnen 
)
Andere Programme wie z.B. MediaMonkey lesen dabei mehrere Verzeichnisse parallel ein.
(Macht hauptsächlich Sinn, wenn ich unterschiedliche Volumes/Platten gleichzeitig einlesen lasse).
Das Einlesen der gleichen 10'000 Test-Dateien ab dem gleichen NAS (eine Platte) ist in MediaMonkey nicht schneller. Da lässt sich also kaum was in Mp3tag verbessern.
ABER:
Bei MediaMonkey muss ich das nur einziges Mal machen, weil sämtliche Metadaten in eine SQLite-Datenbank geschrieben werden.
Danach kann ich ultraschnell auf sämtliche Metadaten zugreifen.
Meine Empfehlung an Florian ist deshalb folgende:
Erstelle bitte eine lokale Datenbank für die eingelesenen Metadaten. Eine SQLite-DB z.B. lässt sich supereinfach per Programm erstellen, braucht keinerlei Installation (mach ich selber auch so).
Daraus können Power-User auch alle erdenklichen Reports ziehen.
Daraus lassen sich Untermengen definieren, die man in Mp3tag bearbeiten will.
Die ganze Einleserei ist nur einmalig nötig, spart also bei jedem Aufruf Stunden an Wartezeit.
Die genialen Filter würden dann über den Gesamtbestand an Metadaten in der DB suchen, was praktisch keine Limite mehr hat.
Damit könntest Du auch bei der 32bit-Version bleiben und trotzdem den "Sammlern und Jägern" unter uns einen grossen Dienst erweisen und uns die stupiden Arbeitsschritt-Wiederholungen aufgrund von Speicherproblemen ersparen.
Klar, das ist halt der konzeptionelle Unterschied zwischen einem Musikverwaltungsprogramm und einem reinen Tag-Programm.
Wenn man wirklich mit grossen Datenbeständen sehr schnell sein will führt kein Weg an einer Datenbanklösung vorbei, wobei man dann allerdings Inkonsistenzen zwischen den Files und der Datenbank ständig abfangen muss und das klappt nach meiner Erfahrung bei Mediamonkey nicht immer problemlos.
Wie ich schrieb benötige ich den kompletten Datenbestand beim Tagen sehr selten und für die wenigen Male, wo ich ihn benutzen will, reicht mir eine halbe Stunde Ladezeit während einer Kaffeepause aus.
Das läuft aber doch parallel zum Speichern der Cover ab. Und die Cover sind halt der wesentliche Größenfaktor.
Bist Du sicher, dass der enorme Zeitunterschied zwischen Deiner Konstellation und meiner nur an der NAS-Anbindung liegt? Vielleicht hast Du im Gegensatz zu mir weit mehr und größere Cover eingebettet?
Wie groß wird denn Dein "library\covers-Ordner"? Bei mir wird er gerade mal 1 GB groß bei ca. 16.000 gespeicherten Cover-Dateien. Da ich im wesentlichen komplette Alben habe sind halt die Coverdateien sehr oft gleich und werden nur 1 x gespeichert.
Ich starte Mp3tag jetzt und lass es nochmal ca. 2 Stunden einlesen. Ich melde mich dann und schreibe hier rein, wieviele Covers mit welcher Gesamtgrösse dabei rauskommen und wieviele mp3 in dieser Zeit eingelesen wurden.
Nach rund 150'000 eingelesenen mp3 habe ich den Vorgang abgebrochen. Im \cover-Verzeichnis liegen 11'388 Dateien mit einer Gesamtgrösse von 630'235'136 Bytes (rund 601 MB). Die mit Abstand grösste Datei ist 19MB gross, die zweitgrösste 3,5MB, die allermeisten sind aber kleiner als 300KB. Davon sind 215 Dateien sogar kleiner als 10KB. Die kleinste Datei ist noch 2KB und enthält ein 120x120 Pixel-Bild. Gemäss Zeitstempel wurde die erste Datei um 21:39 geschrieben, die 11'388te um 23:02, also rund 83 Minuten später.
-> Erstaunlicherweise wird demnach das Einlesen mit der Zeit schneller?
Einen Grund fand ich bisher nicht, ich wiederhole morgen das Ganze ein weiteres Mal.
Mp3tag zeigt mir 150'038 Dateien an, welche gemäss Taskmanager insgesamt 1'657.3 MB Arbeitsspeicher belegen.
Klicke ich auf die Spalte nach Cover-Grösse und wähle dann eine Zeile mit der grössten Angabe (19'545'505) aus, verschwinden sämtliche id3v2-Angaben dieser Zeile. Es sieht so aus, als ob nur abgekürzte id3v1-Informationen übrigbleiben.
Beim Klick auf eine Zeile mit der zweitgrössen Cover-Angabe (3'651'715) passiert das nicht und sämtliche id3v2-Angaben bleiben wie gewohnt erhalten.
Das Sortieren nach einer Spalte dauert mit diesen 150'038 Zeilen auf meinem Rechner 17 Sekunden. Diese Zeit bleibt konstant gleich (mindestens bei den ersten 5 Spalten die ich testete).
Die Benutzung des Filters mit einem einfachen Suchtext wie "another dimension" benötigt 9 Sekunden bis das Resultat mit 61 Treffern erscheint. Für "superstition" mit 30 Treffern braucht es die gleichen 9 Sekunden. Genau gleich lang braucht es für die 15'433 Resultate für "love".