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: 9237
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 Yesterday, 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 Yesterday, 22:03
Post #34


Member


Group: Full Members
Posts: 9237
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 Yesterday, 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 Yesterday, 23:46
Post #36


Member


Group: Full Members
Posts: 904
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

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

 



RSS Lo-Fi Version Time is now: 23rd November 2017 - 06:27