Gutes Musik Konvertierprogramm

[Don-DCH]

Irgendwie funktioniert der Helium audio converter nicht mehr richtig..
800 MB musikdatein ziehe ich rein, warte minutenlange,kann zusehen wie der ram auf über 1,5 GB steigt und dann auf einmal brichts mit der meldung nicht genügend ram verfügbar ab obwohl 3 von 8 gb belegt sind, was ich nicht verstehe das helium mehr ram verbrauch als die datein groß sind der sinn ershcließt sich mir nciht wirklich..
Wo ist der fehler?
MFG Don-DCH

 

[Yuuri]

Wo ist der fehler?

Wahrscheinlich im Programm selbst und in korrupten Daten. Warte auf Patches oder nutze ein anderes Programm.

 

[Waldheinz]

Versuch doch mal Freemake oder DVDVideoSoft.
Letzteres hat doch eigentlich für alles ein Programm dabei. Ersteres ist zwar hauptsächlich für Video gedacht, kann aber auch mit Audio umgehen.

 

[Don-DCH]

hm leider sind die anderen nicht so komfortabel habe format factory getestet kopiert nicht ins quellverzeichnis richtig und löscht alte daten nicht,habe eben nochmal das aktuellste runtergeladen es ging auhc mal.
Auslagerungsdatei hab ich aus,aber dürfte eigentlich ncih der fehler sein oder?
Danke für den Link werd ich mri morgen mal anschauen!
Hoffe es gibt eine lösung für den helium audio converter, da dieses Programm zuerst einwandfrei lief...

MFG Don-DCH

 

[Hardkorn]

Manche Programme benötigen die Auslagerungsdatei, egal wieviel Ram Du eingebaut hast. Mach sie auf z.b. 2GB und dann dürfte es passen.

Edit: https://www.computerbase.de/forum/threads/optimierungen.916472/#post-10145293

 

[Waldheinz]

Die Auslagerungsdatei abzuschalten ist eigentlich keine gute Idee, man kann ja auch nur eine kleine anlegen oder von bis.
Das kann dann schon solche Phenomene hervorrufen.
Ich vermute mal das Helicon Programm ist 32 Bit und somit kann es auch nur 2GB RAM adressieren und der Rest wird ausgelagert, aber wohin damit wenn es keine Auslagerungsdatei gibt. Übrigens legt Windows trotzdem eine pagefile an um sich selbst auszulagern, also ganz abschalten geht eh nicht und bei den riesen Platten heutzutage muss man ja nun auch nicht gard an 2 GB sparen.

 

[miccellomann]

iTunes selber kann aus jeder mp4 Datei auch mp3s erstellen. Dazu markierst Du die Titel, die konvertiert werden sollen, machst einen Rechtsklick drauf, und wählst dann "mp3-Version erstellen".

Alternativ habe ich persönlich mit dem Tool CDEX sehr gute Erfahrungen gemacht. Die haben u.a. den Fraunhofer, ogg-Vobis und Lame mp3 codierer mit an Board. Die sind allesamt recht gut.

 

[Yuuri]

Ich vermute mal das Helicon Programm ist 32 Bit und somit kann es auch nur 2GB RAM adressieren und der Rest wird ausgelagert, aber wohin damit wenn es keine Auslagerungsdatei gibt.

32 Bit Programme können nur 1,8 GB adressieren. Wenn auch nur ein Byte mehr angefordert wird, stürzt es ab. Mehr wird auch nicht ausgelagert, höchstens bis zu diesen 1,8 GB.

 

[Waldheinz]

Ob nun 2 oder 1,8GB ist relativ egal, es sollte auch nur mehr als Beispiel dienen.
Allerdings erschliesst sich mir nicht wie du auf 1,8 kommst wenn doch überall von 2 die Rede ist.

 

[Yuuri]

Hab ich mal selbst ausprobiert gehabt, rein aus Interesse. Wenn ich mehr als 1,8 GB im Spechre allokiert habe, stürzte das Programm jedes Mal ab (eben weil es keinen Speicher bekommen hat).

 

[noman_]

Von einem verlustbehafteten Format in ein anderes verlustbehaftetes Form umwandeln ist doch eher suboptimal - Kompressionsartefakte olé . Das ist der Grund warum ich vor Jahren meine gesamten Ogg-Rips in die virtuelle Tonne getreten habe und bei LAME MP3s gelandet bin - die funktionieren überall.

 

[Waldheinz]

Hab ich mal selbst ausprobiert gehabt, rein aus Interesse. Wenn ich mehr als 1,8 GB im Spechre allokiert habe, stürzte das Programm jedes Mal ab (eben weil es keinen Speicher bekommen hat).

Aha, interessant. Schon erstaunlich wie unterschiedlich die einzelnen System so reagieren.

Gäbe auch noch die Möglichkeit anstatt der 2GB 3GB an verfügbaren RAM den Programmen zuzuweisen mit "bcdedit /set IncreaseUserVa 3072".
Allerdings muss man das ganze testen, es kann auch zu unerwünschten Nebeneffekten kommen dabei.
Bzw. muss man auch mal mit dem Wert etwas variieren.
Dazu muss auch glaube PAE an sein, aber das weiß ich grad nicht genau.
"bcdedit /set {GUID] pae /forceenable"
Ach Schmarrn, das gilt ja nur für x86 Windows, der TE hat ja wohl x64, also ignorieren. *g*

 

[1668mib]

32 Bit Programme können nur 1,8 GB adressieren. Wenn auch nur ein Byte mehr angefordert wird, stürzt es ab. Mehr wird auch nicht ausgelagert, höchstens bis zu diesen 1,8 GB.

Sorry, aber das ist so nicht korrekt.
Du meinst Win32-Prozesse und die können, oh Wunder, alle 2^32 Byte adressieren, also 4 GB. Das Betriebssystem in Form von Windows teilt diesen Adressraum auf. Und diese Aufteilung ist entscheidend und vom Betriebssystem abhängen. Gängige Nicht-Server-Windows-Versionen erlauben es dem Prozess, die Hälfte für sich zu nutzen, Server-Versionen drei Viertel, wenn Prozesse das entsprechende LAA-Flag (kann mich da beim Namen auch irren) gesetzt haben. Allerdings lässt sich das auch konfigurieren und Prozessen, Stichwort USERVA.

Wobei ich mir nicht sicher bin, wie es bei 64-Bit-Windows-Versionen ist, ob da ein Prozess dann nicht die vollen 4 GB Adressraum nutzen kann.
Siehe auch hier: https://www.3dcenter.org/abbildung/64-bit-windows-mit-laa-flag?size=vorschau2

 

[Waldheinz]

Soweit ich mich erinnern kann ist das bei 32 Bit Prozessen unter x64 genauso nur das ich dort mehrere 32 Bit Programme gleichzeitig laufen lassen kann bis eben mein RAM aufgebraucht ist, unter x86 wäre es ja rein rechnerisch nur einer. 64 Bit Programme betrifft das ganze soweiso nicht.

 

[1668mib]

Wie meinst du das "nur einer"? oO

Jeder Win32-Prozess hat seinen eigenen Adressraum... es gibt ja auch Win32-Betriebssysteme, die 128 GB an Arbeitsspeicher verwalten können...

 

[Waldheinz]

Wie meinst du das "nur einer"? oO

Jeder Win32-Prozess hat seinen eigenen Adressraum... es gibt ja auch Win32-Betriebssysteme, die 128 GB an Arbeitsspeicher verwalten können...

Ja klar gibts die, ich bin jetzt mal von den normalen Desktop Windows ausgegangen die ja nicht mehr als ca 3,5GB können, da wäre es dann mit einem Prozess bei 2GB alles belegt.
Hmm, irgendwie drück ich mich unglücklich aus, weiß es aber grad nicht besser zu formulieren.

 

[1668mib]

Aus dem Grund bietet die virtuelle Speicherverwaltung ja auch die Möglichkeit, Speicherseiten auszulagern...

 

[Yuuri]

@ 1668mib: Die 3 GB werden doch aber nur durch PAE erreicht?! Nachteile davon kann man sich ja aus Google entnehmen. 64 Bit Prozesse können so viel RAM allokieren "wie sie lustig sind".

http://msdn.microsoft.com/en-us/library/aa366778(v=vs.85).aspx

User-mode virtual address space for each 64-bit process:

With IMAGE_FILE_LARGE_ADDRESS_AWARE set (default):

x64: 8 TB

Intel IPF: 7 TB

2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared

 

[Waldheinz]

Ja ok mit Auslagerung klappt das schon, das wäre beim x64 erstmal nicht nötig bis der reale RAM aufgebraucht ist, vielleicht so besser ausgedrückt.

 

[1668mib]

Yuuri, mit PAE hat das erst mal gar nix zu tun... mit PAE können die 32-Bit-Windows-Server Arbeitsspeicher jenseits der 4 GB-Grenze verwalten (nutzen). Und grundsätzlich könnte das ein 32-Bit-Windows sogar auch, wenn Microsoft es nicht vorsichtshalber abgeschaltet lassen hätte, sonst könnte man verbaute 4 GB Arbeitsspeicher auch unter 32-Bit-Windows-Versionen ohne Umschwege nutzen... die Gründe gegen Arbeitsspeichererweiterung mittels PAE: Potentiell inkompatible Treiber... weil PAE ist nicht gleich PAE. Quasi jedes heutige 32-Bit-Windows läuft mit PAE und auch die Treiber. Aber genug Treiber haben Probleme im Zusammenhang mit der Arbeitsspeichererweiterung durch PAE...
Und ich rede von Win32-Prozessen im Win64-Umfeld... von 64-Bit-Prozessen hab weder ich noch andere gesprochen...

Edit: Und so wie es aussieht waren meine 128 GB evtl etwas zu hoch gegriffen, evtl waren es auch "nur" 64 GB...

Und mir ging es eher darum (Win32-Prozesse unter x64):
2 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE cleared (default)
4 GB with IMAGE_FILE_LARGE_ADDRESS_AWARE set