Mp3tag als 64 bit version

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

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.