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.