IPB

Welcome Guest ( Log In | Register )

> Hinweise!

Bitte vor dem erstellen eines Beitrag unbedingt den Beitrag Aktuelle Hinweise! lesen.

Lesen Sie auch die allgemeinen Nutzungsbestimmungen dieses Forums.

3 Pages V  < 1 2 3  
Reply to this topicStart new topic
> mp3tag als 64 bit version, mp3tag als 64 bit version
ohrenkino
post Nov 17 2017, 07:51
Post #31


Member


Group: Full Members
Posts: 9240
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.85



ZITAT(MP3Freak_Peter @ Nov 16 2017, 20:53) *
...
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.
...

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.


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post
MP3Freak_Peter
post Nov 17 2017, 22:49
Post #32


Member


Group: Full Members
Posts: 108
Joined: 4-August 10
Member No.: 12719



QUOTE (ohrenkino @ Nov 17 2017, 07:51) *
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
Go to the top of the page
 
+Quote Post
Florian
post Nov 22 2017, 19:48
Post #33


Developer


Group: Admin
Posts: 8106
Joined: 12-December 01
From: Germany, Dresden
Member No.: 203
Mp3tag Version: 2.85a



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 smile.gif

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


--------------------
♫ If you like using Mp3tag please donate to support further development.

Go to the top of the page
 
+Quote Post
ohrenkino
post Nov 22 2017, 22:03
Post #34


Member


Group: Full Members
Posts: 9240
Joined: 9-December 09
From: Norddeutschland / Northern Germany
Member No.: 11458
Mp3tag Version: 2.85



ZITAT(Florian @ Nov 22 2017, 19:48) *
...
Die Cover der Dateien werden jetzt im lokalen Dateisystem gespeichert (%APPDATA%\Mp3tag\data\library) und auch das Handling von Zeichenketten hab ich komplett überarbeitet.
...

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.


--------------------
42 - wie war die Frage / what was the question / quelle était la question
Go to the top of the page
 
+Quote Post
MP3Freak_Peter
post Nov 22 2017, 22:15
Post #35


Member


Group: Full Members
Posts: 108
Joined: 4-August 10
Member No.: 12719



QUOTE (Florian @ Nov 22 2017, 19:48) *
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 smile.gif

wenig verwunderlich, hatte ich schon ein paar mal gemutmaßt...

QUOTE
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.

40-50%? dann war es aber mal Zeit. Aber ich kenn das, never touch a running system rolleyes.gif

QUOTE
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 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.

Go to the top of the page
 
+Quote Post
LyricsLover
post Nov 22 2017, 23:46
Post #36


Member


Group: Full Members
Posts: 906
Joined: 21-September 06
From: Central Europe
Member No.: 3709
Mp3tag Version: 2.85a



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.
Go to the top of the page
 
+Quote Post
poster
post Yesterday, 12:38
Post #37


Member


Group: Full Members
Posts: 1436
Joined: 22-March 09
Member No.: 9241
Mp3tag Version: 2.85a



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:

1. 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.

2. 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. smile.gif
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.
Go to the top of the page
 
+Quote Post
LyricsLover
post Yesterday, 17:19
Post #38


Member


Group: Full Members
Posts: 906
Joined: 21-September 06
From: Central Europe
Member No.: 3709
Mp3tag Version: 2.85a



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 wink.gif )
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.
Go to the top of the page
 
+Quote Post
poster
post Yesterday, 17:48
Post #39


Member


Group: Full Members
Posts: 1436
Joined: 22-March 09
Member No.: 9241
Mp3tag Version: 2.85a



ZITAT(LyricsLover @ Nov 23 2017, 17:19) *
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.

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.

ZITAT
Das wirklich Langsame ist bei mir das Einlesen der Metadaten ab meinem NAS.

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.

This post has been edited by poster: Yesterday, 17:55
Go to the top of the page
 
+Quote Post
LyricsLover
post Yesterday, 21:21
Post #40


Member


Group: Full Members
Posts: 906
Joined: 21-September 06
From: Central Europe
Member No.: 3709
Mp3tag Version: 2.85a



ZITAT(poster @ Nov 23 2017, 17:48) *
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".

This post has been edited by LyricsLover: Yesterday, 23:31
Go to the top of the page
 
+Quote Post

3 Pages V  < 1 2 3
Reply to this topicStart new topic
1 User(s) are reading this topic (1 Guests and 0 Anonymous Users)
0 Members:

 



RSS Lo-Fi Version Time is now: 24th November 2017 - 06:18