Mp3tag als 64 bit version

Hi
da ist aber eine 32Bit Version schon noch weit im grünen Bereich. 2048 wäre die vermutliche Grenze, abzüglich des Overheads von so 5-10% vermutlich. Was passiert denn wenn du mehr lädst? bricht er mit einem Fehler ab (insufficient memory, ....) oder woran siehst du das er nicht mehr kann?
Gruß
Sam

Z.B.
/t/16790/1
/t/6875/1

Hi LyricsLover
da verstehe ich es auch; 2GB (minus ein wenig Overhead) ist ein typ Limit unter NT Systemen mit dem sog Flatmemory Modell; NT schluckt die oberen 2GB für sich (OS, Cache, USB Stack, VGA RAM, ....) und seine Treiberinstanzen.
Bei Bär ist aber sein Verbrauch bei noch gut unter 1GB also gut entfernt von der Designrestriktion. Eine schnelle Abhilfe wäre der sog BigMemory Switch beim compilen (damit kann er sofern der NTKernel es erlaubt bis zu 3GB anziehen; ab XP64 ist dieser Switch immer bei 64bittigem Windows gesetzt) mitgibt. Das scheint aber bei einigen Powerusern hier immer noch viel zu wenig (und ich dachte das ich mit meinen 1400DAT (Studioschnitte) und 2600CD und 200LPs schon eine dicke Sammlung hätte...). Ob der Programmierer 32 Bit und 64 Bit parallel führen kann (kommt auf seine Versionskontrolle darauf an und mit was er kompiliert) ist wohl derzeit viel Aufwand für wenig Nutzer (ohne ihm da in seine Entscheidungsfreiheit eingreifen zu wollen).
Gruß
Sam

Leider ist es so, dass es wohl mittlerweilen einige 'PowerUser' gibt, die ein vielfaches an Songs in ihrer Sammlung haben. Und das führt zur äusserst unschönen Situation, dass man einen enormen manuellen Mehraufwand betreiben muss und die immer gleichen Schritte wieder und wieder und wieder ausführt.

Da inzwischen wohl die meisten User ein 64bit-Windows-Betriebssystem benutzen, wäre es IMHO nicht viel mehr als zeitgemäss, wenn auch Mp3tag diesen Sprung machen könnte.

Ich will Florian ebenfalls nicht zu nahe treten. Aber bevor ich mir über "high-resolution screens with high DPI settings" Gedanken machen würde (was meines Wissen nie ein grosses Thema hier war), würde eine 64bit-Version von Mp3tag wesentlich mehr Aufsehen erregen und zum extrem nützlichen Feature für viele Benutzer werden.

Weder das setzen des Switches zum nutzen der 3GB Speicher noch das einfachere rekompilieren als 64 Bit funktioniert "einfach so" aus dem bestehenden Source der jahrelang für 32 Bit entwickelt wurde. (auch wenn dies die Hersteller von Entwicklungsumgebungen und Compiliern gern als Bauernfang Verkaufsargument suggerieren )
Aber ja, wenn man den Code überarbeitet ist eine 32- und eine 64 Bit Version aus einem Source möglich, da spart man sich die ganze mergerei.
Ich weiß natürlich jetzt nicht was MP3Tag an externen Lib's verwendet, das kann ihm schon das Genick brechen.

Irgendwo anders hier im Forum hab ich es schon mal geschrieben:
Ich weiß ja nicht was nicht was sich mp3tag alles im Speicher merkt, aber die oben angegebene Dateianzahl darf auch bei einem 32 Bit Prozess kein Problem sein.
Wichtig ist: ein Out of Memory kommt auch bei großer Speicherfragmentierung vor,
auch wenn rechnerisch noch genug Speicher da wäre.

Gruß
Peter

Im August 2014 hatte ich einen Test gemacht mit bis zu 200000 Dateien ...
... und in der Zwischenzeit keine Wiederholung durchgeführt.
Möglicherweise ist die beschriebene Situation immer noch dieselbe ...
manage large number of songs in a single directory

DD.20150516.0614.CEST

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. :rolleyes:

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. :frowning:
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 :slight_smile:

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.