Mehrere hundert flac Dateien konvertieren als Batch Job

Hallo zusammen,
habe gerade den Job gestartet. Geschätze Zeit: knapp 2 Tage.
Mal sehen, ob's im Laufe der Zeit noch runter geht.
Alles scheint zu klappen.

Danke nochmals!

Gruß

Hui, das ist aber 'n ganzer Haufen Material. Mein 5 Jahre alter Kasten hier (mit Core 2 Duo E6550) braucht typisch eine knappe Minute pro Album in -V 5, Durchsatz so etwa 1 min/s (also ~60x Realtime). Mein gesamter Bestand von etwas über 300 Scheiben (was zugegeben noch keine große Sammlung ist) wäre in weniger als 4 Stunden durch.

Übrigens, ihr hattet recht:

fc /b "Ride - Nowhere - 01 Seagull q0.mp3" "Ride - Nowhere - 01 Seagull.mp3"
Vergleichen der Dateien Ride - Nowhere - 01 Seagull q0.mp3 und RIDE - NOWHERE - 
01 SEAGULL.MP3
FC: Keine Unterschiede gefunden
-q wird also in Verbindung mit -V tatsächlich ignoriert. (LAME war 3.98.4.)

Hallo audiophilanthrop,
bzgl. Deiner Zeitangabe: Meinst Du das Rippen von CD (Scheiben oder Platten?)
nach mp3 oder auch einen Konvertierungsvorgang?
Macht Rippen oder Konvertieren überhaupt einen zeitl. Unterschied? Sollte doch oder?
Wie gesagt, es sind fast 28.000 Stücke, fast alles Klassik, d.h. größer.
Es rechnet seit ca. 16Std und braucht immer noch knapp 2Tage laut Anzeige.
Zur Hardware: 3 Jahre alter Dell (64Bit) mit Windows7.
Sollte es keinen Stromausfall geben, halte ich durch :-)

Gruß

Zwischen Rippen und Konvertieren (wenn man es so bezeichnen kann), können durchaus zeitliche Unterschiede existieren. Immerhin ist ein CD-Laufwerk wesentlich langsamer als eine Festplatte. Wenn dann noch Fehlerkorrektur, mehrere Leseversuche etc. dazu kommen, kann es sein, dass hier der geschwindigkeitsbestimmende Schritt ist und nichtmehr die Umwandlung im Prozessor. Und wenn letzterer noch mehrere Kerne hat und mit jedem davon gleichzeitig eine Datei konvertieren kann, dann kommt das Laufwerk garnicht mehr mit.

da brauchen wir nicht lang rumdiskutieren und rumargumentieren: Rippen von CD ist immer um Größenordnungen langsamer als einfaches Konvertieren von bereits auf der Festplatte befindlichen Audiodateien - aus die Maus.

So, jetzt er fertig. Nicht genau geschaut, Gesamtzeit war 2d.
Ca. 28000 konvertiert, davon ca. 6000 fehlerhaft.
Vermute, der Zielpfad war zu lang, hatte Sonderzeichen bzw. der
Dateiname.
Dachte, wenn foobar es lesen kann, klappt die Konvertierung.
Hat lame hier als Speicherdienst versagt?
Was kann ich jetzt sinnvolles tun?

Danke und Gruß

zoro17 (Beitrag #57) schrieb:

Was kann ich jetzt sinnvolles tun?

Nachgucken, wo's bei den nicht konvertierten Dateien geklemmt hat - welche davon schnappen, nochmal konvertieren und auf Fehlermeldungen in der Konsole achten. Konkrete Anhaltspunkte wären jetzt nützlich.

zoro17 (Beitrag #57) schrieb:

Dachte, wenn foobar es lesen kann, klappt die Konvertierung.

Normal schon. Mein externer Konverter hat bei manchen Sonderzeichen schlicht gestreikt, Foobar nicht.

Bei Pfadlängen jenseits von ~256 Zeichen kann ich aber für nichts garantieren. Da hören anscheinend die Standardfunktionen der Win32-API auf. Wobei das für Foobar schon vor Jahren kein Thema mehr war, aber evtl. hat man das zwischenzeitlich just wegen der beschriebenen Probleme geändert.

Ich meine, ich hätte auch irgendwann schon mal Fehlermeldungen à la "invalid path" in Foobar gehabt, aber das ist schon so lange her...

Du kannst immer noch das Namensschema für die Zieldateien ändern, wenn es dort klemmen sollte.
http://wiki.hydrogen...Formatting_Reference
Interessant ist z.B. die Funktion $left(string,n), die nur die ersten n Zeichen von string ausgibt.

Ich weiß auch nicht, was passiert, wenn man LAME Sampleraten von >48 kHz vorsetzt. *ausprobier* Nix besonderes, die rechnet er auf 48 kHz runter (wie gut, weiß ich natürlich nicht).

Thema FLAC-Bitrate: noch brutaler wirds, wenn FLAC echtes mono detektiert. Dann halbiert es nochmal faktisch die Bitrate, irgendwie wäre alles andere auch übel. Hatte es letztens bei einer alten DDR-Kinderhörspielplatte, die ich für den Sohn einer Freundin von LP digitalisiert habe. Die Produktion aus den 60ern oder späten 50ern war nur mono, habe sie deshalb auch auf mono gemischt, schon der Verringerung der Rillengeräusche wegen. Das FLAC wurde sehr klein...

Am anderen Ende stehen dann die heutigen totkomprimierten Rock-Pop-Produktionen. Ich habe mich mit den Innereien des FLAC-Codecs nicht beschäftigt, vermute aber, daß er ein geschicktes Management mit nicht genutzten Bits macht. Und die gibt es bei heutigen Produktionen kaum noch.

Zur Konvertierung: ich bin Minimalist und versuche möglichst viel mit möglichst weniger (und immer der gleichen) Software zu machen. Winamp heißt mein MP3-Player seit vielen Jahren, und aktuelle Winamp-Versionen verstehen natürlich FLAC ohne weiteres Zutun. Dann greift man sich noch das kostenlose Filewriter-Plugin, wirft es in das Winamp-Plugin-Verzeichnis und ruft es auf: Winamp -> Options -> Preferences -> Plug-ins -> Output -> File Writer output plugin v1.21b (x86).

Hatte schonmal vor Jahren einen entsprechenden Screenshot hier eingestellt, schön, daß er noch da ist - nur FLAC konnte der damalige Winamp noch nicht.



Damals nutzte ich die Lame.dll, heute nutze ich die Lame.exe. Kann man im Plugin auch auswählen, die Lame.exe sollte freilich auch dort liegen, wo sie angegeben ist. Dann via "Config format" den Lame konfigurieren. An der Lame-Kommandozeile kann man dann alle Sauereien machen, die man machen will, inklusive Resampling (ideal für DVB-Radioaufnahmen zu 44.1er MP3s).

Ich nutze weiterhin die alte Lame 3.93.1, auch wenn ich dafür in den üblichen Kreisen Haue bekomme. 3.94, 3.95, 3.97 und 3.98 blubberten in CBR schrecklich und 3.99 (endlich gefixt) ärgert mich an einer anderen Stelle. Aber das ist ganz allein mein Problem.

Vorsicht! Da dieses Konvertieren eine Art Abspielen ist (natürlich schneller als Echtzeit), darf man nicht am Winamp-Scrollbalken fummeln und der Equalizer möge bitte auch ausgeschaltet sein. Dann erhält man aber nachgewiesenermaßen saubere Resultate. Das Plugin kann sogar bei der Lame.dll das Schreiben des Xing-Headers erzwingen (Audiograbber kann das z.B. nicht), wichtig für gapless playback.

Für meine Zwecke reicht diese Lösung vollauf.