Mp3tag als 64 bit version

hallo florian

als erstes danke fuer deine super arbeit,
dir ist hier ein supergeiles tool gelungen.

aber dennoch eine anfrage,

ist es moeglich / in planung mp3tag als 64 bit version ??

danke im vorfeld

balu der baer

1 Like

Wäre damit auch wegen des größeren RAM-Speichers die maximal ladbare Trackanzahl höher? Siehe Speicherprobleme. Auch mit Version 2.49 kann ich nicht alle Tracks gleichzeitig laden, weil sehr viele Tracks bei mir Cover enthalten.

1

... ist für mich unverständlich.

+1 heisst so viel wie: "Unterstütze ich auch". Im Zeitalter von Facebooks-likes und Google-Plus ist das eine verbreitete weitere Schreibweise. :rolleyes:

Auch von mir:
+1

natürlich verbunden mit der Hoffnung, dass eine echte 64bit-Version mehr Memory benutzen könnte/würde.

Hallo zusammen

nur mal ne frage am rande,

hat irgendjemand mal von florian mal ne antwort zum thema 64 bit version bekommen. ??

auf eine direkte email hat er auch nicht reagiert, ebensowienig wie auf diese anfrage !!!

meine anfrage ist ja nun auch schon viele viele monate unbeantwortet.

oder kann es sein, das er auf dieses thema immer so reagiert ??

danke balu der baer

Wäre es dankbar, dass dann eine größere Anzahl Tracks geladen werden können?

Die Hoffnung stirbt zuletzt. Auch auf eine Antwort von Florian... :unsure:

Tja und auch dieser Versuch ist nun schon wieder 3 Jahre her... :frowning:

Florian, hau die Hacken in den Teer, ich bin sicherlich nicht der Einzige, der dafür auch gerne einen Hunderter abdrücken würde!

Alle meine Tracks passen schon lange nicht mehr in eine MP3TAG-Session. Um eine Aktion durchzuführen muss ich mehrfach laden. Das ist lästig. Andererseits gibt es kein besseres Programm zu diesem Thema.

Hi
sein Programm kann native 2GB RAM an sich ziehen, oder 3GB über das BigMemory Modell. Das sollte schon eine Menge Holz sein. Ich habe nur 80k Files(APE/ID3v2 Tags, keine Bilder), aber die nimmt er ohne zu murren und sollte ich mal eine neue Richtlinie wie separatoren oder wie ich CD Nummer mit in den Tag bringe.
Warum der Entwickler hier wohl still war dürfte evtl die seltene Anfrage sein. Evtl sind auch die Anfragen der zahlenden Supporter zu aufwendig und die wandern eher in den Mainstream.
Ich kämpfe gerade mit dem LFN Problem, was mich bei Klassik sehr trifft.
Gruß
Sam

Was ist ein LFN-Problem?

Edit nach dem Absenden fand ich: Long Filename. Richtig?

yep. Ich habe im Klassikbereich (Operetten sehr stark) Filenamen im 600-800 Zeichen Bereich. Kommandozeilentools wie oggenc und co kommen da gut damit zurande, haben aber eben keine GUI, in der man sortieren kann. Da kommt mp3tag ins Spiel. Das zweite Abenteuer kommt mit slawischen/kyrillischen /CHN/JP Zeichen. Bin dem Thema aber nie groß nachgegangen, da die tags innerhalb da auch Probleme haben und ob Smetana mit Bedrich vereinfacht wird oder richtig Bedřich ist mir nicht ganz so wichtig (vor allem da nahezu alle Probleme damit haben)
Gruß
Sam

Thema 64Bit: wieviel zeigt dein Taskmanager (oder besser Programme wie procexp64 oder procmon) denn an wenn deine Liste geladen ist?

Mp3tag.exe 617.964 K 627.896 K 6752 Mp3tag - the universal Tag editor

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