FLAC zu mp3 convertieren im Jahr 2015

Nimm einfach die Foobar, das ist auch schön komfortabel.

Seit fast 10 Jahre wird foobar empfohlen. Ist das immer noch das beste?
Ich habe ein ganz einfaches gefunden. FlacSquisher. Hat schon Lame integriert.
Ich habe nun 1 CD convertiert und dabei kommt mp3 mit 170 -200 kBit/s heraus. Ist das eine schlechte Qualität oder eben halt Lame.

Lame ist immer noch aktuell....und viel ist in den letzten zehn Jahren nicht passiert. Naja...maximum sind die 320kBit/s bei der Foobar kannst du das aber einstellen. Dein Tool kenne ich leider nicht.

Kann mir jemand sagen was Number of Threads bedeutet?
Und in der Comand Line, was bedeutet das q0 am Ende?

Das ist die Anzahl der gleichzeitigen Prozesse. Sinnvoll ist dort die Zahl deiner (virtuellen) Prozessorkerne einzutragen.

q0 ist die Qualitätseinstellung. Soweit ich weiß, ist sie recht nutzlos bei angegebener variabler Bitrate.

Bist du dir sicher, dass die MP3-Dateien im selben Ordner landen sollen, wie die Flac-Dateien? Wenn du die bestmögliche Qualität möchtest, lasse einfach alles so, wie es jetzt ist.

Die Qualität der MP3-Datei bestimmt sowieso nicht die Anwendung, sondern der verwendete Codec und die Bitrate.
Dafür ist Lame immer noch aktuell. Die Anwendung bestimmt im Wesentlichen den Komfort bei der Convertierung. Und da ist Foobar für
mich nach wie vor ganz vorne mit dabei. Da ich zuhause sowieso über Foobar abspiele, kann ich mir kaum was konfortableres vorstellen, als eben die Tracks in der Playliste zu markieren und über das Kontext-Menü die Umwandlung zu starten, wenn ich mal MP3 (nehme dann 320kBit/s) oder ein anderes Format benötige.

Slati

Die Prozessorkerne, ja von denen habe ich 4.
Ich habe es in dieser Konfiguration gelassen, ist die Grundkonfiguration. Funktioniert bis jetzt problemlos. Ausser diese 2 Sachen habe ich noch nie ein so einfaches Programm gehabt.
Natürlich hab ich die Ordnereinstellung geändert.
Und 320kBit/s braucht es bei Lame nicht. Variable Bitrate und V2, ergibt ca170-210kBit/s und soll auch für geschulte Ohren absolut ausreichen sein.
http://de.wikipedia.org/wiki/LAME
Sollte ich Unterschiede hören zu FLAC kann ich immer noch zu V1 oder V0 wechseln. Ist mit einem Klick erledigt.

motoquero (Beitrag #8) schrieb:

Und 320kBit/s braucht es bei Lame nicht. Variable Bitrate und V2, ergibt ca170-210kBit/s und soll auch für geschulte Ohren absolut ausreichen sein. http://de.wikipedia.org/wiki/LAME Sollte ich Unterschiede hören zu FLAC kann ich immer noch zu V1 oder V0 wechseln. Ist mit einem Klick erledigt. :)

Ja genau, denn Speicherplatz ist ja so teuer. Da spart man wo man kann.
Wenn ich da an die Zeiten denke, wo man 2 LPs gerade mal auf eine C90 Kassette für ca. 6.- DM aufnehmen konnte.
Allerdings bevorzuge ich das Beste, was ich in einem verlustbehafteten Format bekommen kann, nicht was ausreichend sein soll.
Soviel ist mir meine Musik schon wert.

Slati

Naja, für meinen Clip+ nehme ich lieber -V 4 (nach der Vorstellung von LAME 3.98.4, also knapp 160 kbit oder so). -V 0 oder 320 CBR nuckelt doch merklich mehr am Akku, da sinkt die Laufzeit schon mal von ~12,5 h auf kaum über 10 h. Und ich habe so schon eine 64-GB-Speicherkarte im Einsatz (genaugenommen zwei, eine pro Player).

An meinem großen Rechner wird stelbstversändlich nach Möglichkeit FLAC gespielt. Schon die 250-GB-Platte im Notebook freilich wäre mit meiner gesamten Sammlung schon ziemlich gut gefüllt. Entweder ich gönne mir mal den Luxus einer 500er SSD oder ein NAS.

Da hängt manchmal mehr dran als man denkt.

audiophilanthrop (Beitrag #10) schrieb:

Da hängt manchmal mehr dran als man denkt.

Das schon, aber es muss ja auch nicht gleich eine 500er SSD sein. Für derartige Zwecke sollte eine moderne HD zu einem Bruchteil der Kosten mehr als ausreichend sein ...

audiophilanthrop (Beitrag #10) schrieb:

Naja, für meinen Clip+ nehme ich lieber -V 4 (nach der Vorstellung von LAME 3.98.4, also knapp 160 kbit oder so).

Wieso kein Ogg Vorbis? 160 kbps ist so ziemlich genau die Grenze, wo Vorbis beginnt deutlich effizienter als MP3 zu komprimieren (bezüglich Transparenz), und der Clip+ spielt das sowohl mit Original Firmware als auch Rockbox.

Wenn -V4 für dich transparent oder "ausreichend" für unterwegs ist, stellt sich die Frage natürlich nicht.

*Nightwolf* (Beitrag #6) schrieb:

q0 ist die Qualitätseinstellung. Soweit ich weiß, ist sie recht nutzlos bei angegebener variabler Bitrate.

Nicht nur "recht nutzlos", sie wird bei aktuellen LAME Versionen (ich glaube, seit 3.98r) sogar völlig ignoriert, soweit ich mich erinnere. Die -V Presets sind so sehr optimiert, dass sich die Entwickler wahrscheinlich dazu entschlossen hatten, da einfach einen Riegel vorzuschieben. Was damals für Leute auf Hydrogenaudio unterwegs waren mit abenteuerlichen Parametern, die natürlich alle "besser" als die Standardeinstellungen klangen.

Und nun @Topic:

Ich würde auch, wie vorgeschlagen, einfach den foobar2000 Converter nehmen. Das lässt sich wunderbar konfigurieren, man kann sich auch das komplizierteste Preset mit DSPs als Klangverbiegern und was weiß ich abspeichern, was hinterher nur ein Klick für die Konvertierung bedeutet.

Alternativ werfe ich noch dBpoweramp in den Ring, was ebenfalls ein hervorragender Converter für Windows ist. Lässt sich in den Explorer integrieren, was viele Leute sehr praktisch finden (es reicht also ein Rechtsklick auf einen Ordner oder die FLAC Dateien, um sie zu konvertieren). Kostet ein paar Euro, die es aber vollkommen wert sind, wenn man häufiger konvertiert.

Bei beiden Programmen kann man auch bedenkenlos die Standardeinstellungen verwenden, um Dinge wie Einstellung der Anzahl der CPU Cores/Threads o.Ä. muss man sich keine Gedanken machen. Ich kenne FlacSquisher zugegebenermaßen nicht, aber es sieht nach einem sehr einfachen Frontend aus, das wahrscheinlich einfach die Parameter zur lame.exe schemeißt - ob da z.B. eventuell auftretende Fehler auch entsprechend gemeldet werden, da wäre ich skeptisch.

motoquero (Beitrag #3) schrieb:

Seit fast 10 Jahre wird foobar empfohlen. Ist das immer noch das beste? Ich habe ein ganz einfaches gefunden. FlacSquisher. Hat schon Lame integriert.

Die Lossy-Codecs sind seit einigen Jahren so ziemlich ausgereitzt. Da wird sich nicht mehr viel tun. Die offiziellen Empfehlungen sind noch immer dieselben: bei MP3 VBR V 2 nehmen (~190 kbps), wenns CBR sein soll, dann 192 kbps. Wer das Maximum will: CBR 320. Unterhalb von 192 kbps sit Ogg Vorbis wesentlich effizienter, dann sollte man jedoch auf die Kompatibilität mit seinem Player achten. MP3 ist und bleibt der am meisten verbreitete Lossy-Codec.

Foobar ist ein einfaches und schnelles Programm nach dem Baukastenprinzip (weitere Apps als "Components" erhältlich). Die Qualität Deiner MP3s hängt jedoch vom Codec ab (z.B. Lame), nicht vom verwendeten Programm (z.B. Foobar).

Ansonsten ist Speicherplatz ja heute zu allermeist kein Thema mehr, selbst unterwegs (Erweiterung mit MicroSD-Karten), da empfehlen sich FLAC, ALAC etc. viel mehr.

Warum noch in MP3 formatieren? Soweit ich weiß gibt es genug Hardware- Player die inzwischen auch FLAC abspielen können. Und Speicher ist schon lange nicht mehr so teuer wie früher einmal.
Außerdem wird man kaum seine komplette CD Sammlung unterwegs mitnehmen wollen, brauchen, oder doch?

belphegore (Beitrag #14) schrieb:

Warum noch in MP3 formatieren?

Also ich bin bei meinem mobilen Player wieder von FLAC auf MP3 zurück gegangen.
Klangverlust ist bei hochwertig gerippten MP3 praktisch nicht festzustellen.
Der große Vorteil von MP3 ist für mich das man die Wiedergabelautstärke mit Replay-Gain angleichen kann.
Es gibt nichts nervigeres, als wenn speziell bei Zufallswiedergabe sich ständig die Lautstärke ändert.

Grüsse Michl

Im Gegensatz zu MP3 unterstützt Flac Replay Gain von Haus aus ...

nenkars (Beitrag #12) schrieb:

*Nightwolf* (Beitrag #6) schrieb: q0 ist die Qualitätseinstellung. Soweit ich weiß, ist sie recht nutzlos bei angegebener variabler Bitrate. Nicht nur "recht nutzlos", sie wird bei aktuellen LAME Versionen (ich glaube, seit 3.98r) sogar völlig ignoriert, soweit ich mich erinnere.

Ach ja? Und weil diese Einstellung so "nutzlos" sei, aktiviert --vbr die Option -h, welche wiederum u.a. die Option -q2 aktiviert.
Inwieweit -q<N> sich auswirkt, hängt vom verwendeten Encoder ab:
- --vbr-new: -q0...4 sind identisch
- --vbr-old: -q0...1 sind identisch und -q2...4 sind identisch
Lediglich wird bei --vbr-old -q0...1 die verschachtelte Schleife auf eine einfache reduziert, damit die Konvertierung nicht ins Koma fällt.
Ergo: diese "nutzlose" Einstellung wird intern sehr wohl genutzt.
Quelle: RTFS (v3.99.5)

Die -V Presets sind so sehr optimiert, dass sich die Entwickler wahrscheinlich dazu entschlossen hatten, da einfach einen Riegel vorzuschieben.

Die -V<N> presets dienen der Bequemlichkeit, damit nicht ein ganzer Wust an Optionen angegeben werden muß.

Gruß Tom

*Nightwolf* (Beitrag #16) schrieb:

Im Gegensatz zu MP3 unterstützt Flac Replay Gain von Haus aus ...

Kannst du näheres dazu sagen ?
Ich hab nur Foobar gefunden um den Replay Gain bei FLAC anzupassen und das funktioniert halt nur wenn man mit Foobar abspielt oder vielleicht
bei wenigen mobilen Geräten die speziell dafür ausgelegt sind.
Bei meinen Fiio X1 geht`s jedenfalls nicht MP3 Gain funktioniert dagegen immer, egal welches Gerät.

Grüße Michl

Du musst da zwischen Replay Gain und MP3Gain unterscheiden. Bei Replay Gain wird die Lautstärke des Tracks/Albums einmal gescannt und der Durchschnitts-, sowie der Maximalwert im Tag gespeichert. Beim Abspielen wird dann anhand dieser Werte die Lautstärke berechnet und entsprechend "on-the-fly" angepasst. Dabei bleibt die Tonspur in der Datei unverändert.

Bei MP3Gain wird die errechnete Lautstärke auf die Tonspur angewandt - das ist zwar, soweit ich weiß, verlustfrei (bzw. umkehrbar), aber letztendlich wird das Ausgangsmaterial verändert. Der große Vorteil davon ist aber, dass Programme die keine Lautstärkenanpassung unterstützen, garnicht "mitbekommen", dass sie sowas gerade abspielen. Das ist somit auf allen Geräten einsetzbar, während Replay Gain explizit unterstützt werden muss.

MP3 ist dabei übrigens wesentlich älter als diese Korrekturen, weshalb sie hinterher erst dazugepackt wurden. Das ist - soweit ich weiß - auch einer der Gründe, warum viele Player eben nicht die Anpassung über Tags beherrschen und weshalb es die Krücke mit der umgerechneten Tonspur überhaupt gibt. Das neuere Flac ist direkt auf Replay Gain ausgelegt.

Was heißt das jetzt konkret ?
Gibt es jetzt eine Möglichkeit den Replay Gain für FLAC anzupassen, so das es auch mit meinen Fiio X1 funktioniert,
oder war meine Begründung deswegen auf MP3 zurück zu gehen doch richtig ?

Grüße Michl

Nein, Dein Player ist eben nicht in der Lage das Replaygain über Tags anzupassen, deswegen geht es bei FLACs eben nicht. Warum es bei MP3s geht wurde ja gerade oben erklärt.

Michael_60 (Beitrag #20) schrieb:

Gibt es jetzt eine Möglichkeit den Replay Gain für FLAC anzupassen, so das es auch mit meinen Fiio X1 funktioniert,

Mein AVR (Denon AVR-3313) unterstützt weder bei MP3 noch FLAC die vorhandenen replay-gain tags.

Es gibt dennoch eine Möglichkeit, die Lautstärke automatisiert auf den Referenzpegel von 89 dB zu bringen:
- falls den FLACs die tags fehlen, können diese über

metaflac --add-replay-gain

auch nachträglich hinzugefügt werden; alternativ beim Encodieren einfach

flac --replay-gain

angeben
- beim Decodieren kann jetzt eine LPCM erstellt werden, welche das replay-gain bereits eingearbeitet hat - und zwar via

flac -d --apply-replaygain-which-is-not-lossless

wobei dieser Option Parameter übergeben werden können (RTFM)
- von dieser LPCM könntest Du jetzt Formate (MP3, AAC, ...) erzeugen, welche allesamt auf selbigem Lautstärkelevel liegen - würde diese LPCM erneut als FLAC encodiert werden, hättest Du Dein Ziel erreicht...

In letzterem Fall würdest Du jedoch die erste, unmodifizierte FLAC als Backup zusätzlich speichern wollen.

Gruß Tom

sl.tom (Beitrag #17) schrieb:

nenkars (Beitrag #12) schrieb: *Nightwolf* (Beitrag #6) schrieb: q0 ist die Qualitätseinstellung. Soweit ich weiß, ist sie recht nutzlos bei angegebener variabler Bitrate. Nicht nur "recht nutzlos", sie wird bei aktuellen LAME Versionen (ich glaube, seit 3.98r) sogar völlig ignoriert, soweit ich mich erinnere. Ach ja? Und weil diese Einstellung so "nutzlos" sei, aktiviert --vbr die Option -h, welche wiederum u.a. die Option -q2 aktiviert. Inwieweit -q<N> sich auswirkt, hängt vom verwendeten Encoder ab: - --vbr-new: -q0...4 sind identisch - --vbr-old: -q0...1 sind identisch und -q2...4 sind identisch Lediglich wird bei --vbr-old -q0...1 die verschachtelte Schleife auf eine einfache reduziert, damit die Konvertierung nicht ins Koma fällt.

Ich beziehe mich nur auf aktuelle Encoder. --vbr-old is eine völlig obsolete Einstellung, die, wenn überhaupt, nur noch zu Testzwecken taugt. --vbr-new stammt aus eben jener Zeit, das psychoakustisch überarbeitete Modell was damals das "new" darstellte, ist längst standard. Die Option kann also ignoriert werden.

Du widersprichst dir doch selbst ein wenig- Ja, intern existieren Relikte dieser ominösen "Qualitätsparameter" (wie du korrekt beschreibst aktivierte -h für "high quality" eben -q2 statt -q3 oder -q5 oder was auch immer damals mal Standard war - heute ist das völlig wurscht, da die V Presets diese Parameter fest "eingebrannt"/hardcoded haben). In der Realität spielt das keine Rolle mehr. Ebenso wenig wie das veraltete psychoakustische Modell.

Ich hab den Source Code nicht gelesen, aber was du schreibst, sollte jeder zu Hause nachvollziehen können. Probiert es doch selbst mal aus. Man nehme die aktuelle LAME Version, dann erstelle einmal -V0 ohne sonstige Parameter, dann mit -q0 und mit -q2 bzw. -h. Man wird feststellen, dass die Dateien identisch sind, weil V0 auf -q0 gemappt ist, egal welche der genannten Einstellungen man verwendet (sogar runter bis -q4, wenn deine Angabe stimmt).
Du kannst mit sehr niedrigen Werten, wie z.B. -q5 deutlich schlechtere Werte erzwingen. Das geht dann auf Kosten der Qualität und zu Gunsten der stark gesteigerten Encoder Geschwindigkeit. Wenn aber Geschwindigkeit eine sekundäre oder gar keine Rolle spielt bleibt bei den Standard Einstellungen, denn manuelle Eingriffe werden meisten sowieso ignoriert, das gilt meines Wissens für alle V Presets, bis runter zu -V8.

sl.tom (Beitrag #17) schrieb:

Die -V<N> presets dienen der Bequemlichkeit, damit nicht ein ganzer Wust an Optionen angegeben werden muß.

Jain. Natürlich dienen sie der Vereinfachung. Aber sie vermeiden bzw. verhindern auch das Verwenden von Parametern, auf die die Presets nicht getunt sind. Das heißt, der Laie soll es so einfach wie möglich haben, und der erfahrenere Benutzer soll nicht mehr wie früher an jeder Schraube drehen können, an der gar nicht gedreht werden sollte, weil die Einstellungen in bestimmten Kombinationen keinen Sinn ergeben. Siehe alte Threads auf HA oder auch hier im Forum, wo immer und immer wieder nach den "besten" Parametern gefragt wurde, jedes mal wieder, besonders nach jedem Erscheinen einer neuen LAME Version. Ich bin froh, dass heute eine gewisse Einfachheit durch die Presets "erzwungen" wird.

Es ist off topic, aber du könntest genauso statt der standard FLAC Kompressionslevel mit -8 als Maximum, durch Verwendung von bestimmten Parametern noch extremere Werte zum Encoden erzwingen, als sie bei -8 schon genutzt werden, um noch einen Tick kleinere Dateien zu erhalten. Da das aber schlicht und einfach Keinen Sinn macht, haben die FLAC Entwickler eben -8 als Maximum festgelegt. Alternative Encoder wie flake oder FLACCL bieten tatsächlich höhere Stufen an. Die entsprechen auch noch dem FLAC Standard, wobei bei Hardware Decodern Probleme entstehen können. Selbst bei der starken Asymmetrie von FLAC steigt der Aufwand beim Decoden eben doch auch an, je komplexer die verwendeten Eisntellungen sind, und bei Stufen von 10 oder mehr wird es wohl brenzlig.

Aber das nur am Rande. Will eigentlich sagen: Vertraut mal mehr den Entwicklern, die wissen schon, was sie tun.

sl.tom (Beitrag #22) schrieb:

Michael_60 (Beitrag #20) schrieb: Gibt es jetzt eine Möglichkeit den Replay Gain für FLAC anzupassen, so das es auch mit meinen Fiio X1 funktioniert, Mein AVR (Denon AVR-3313) unterstützt weder bei MP3 noch FLAC die vorhandenen replay-gain tags.

Es war zwar nicht die Frage, aber wenn du per UPnP/DLNA mit foo_upnp streamst, kannst du diese Limitierung umgehen, indem du die Anpassung foobar on-the-fly beim Abspielen übernehmen lässt. Siehe Audio Processing in den foo_upnp settings.

Bezüglich des Kopierens auf den Audioplayer: Würde ich der Bequemlichkeit ebenfalls per foobar machen. Meine eigene Bibliothek ist sowieso ReplayGain-gescannt und mit Tags versehen. Das Scannen ist gleichzeitig ein netter Test, um sicherzugehen, dass die Datei ohne Fehler dekodiert wird. Auf den Player kannst du die FLACs einfach über den Converter übertragen - eben eine FLAC zu FLAC Konvertierung, mit aktiviertem ReplayGain Processing (nicht das "scanne ReplayGain nach Abschluss", sondern das Processing beim Umwandeln aktivieren).

Die genannten Methoden funktionieren aber ebenso gut, mir erscheint foobar in dem Fall nur deutlich komfortabler. Es sei denn man ist sowieso flink in der Kommandozeile unterwegs.

Kurzfassung für Schnelleser: hättest Du eine RTFS Session angesetzt, hättest Du Dir etliches an Tipparbeit ersparen können...

Ich beziehe mich nur auf aktuelle Encoder. --vbr-old is eine völlig obsolete Einstellung, die, wenn überhaupt, nur noch zu Testzwecken taugt. --vbr-new stammt aus eben jener Zeit, das psychoakustisch überarbeitete Modell was damals das "new" darstellte, ist längst standard. Die Option kann also ignoriert werden.

Sorry, aber der alte Algorithmus ist nach wie vor der Maßstab für jegliche Arbeiten am neuen und produziert seit geraumer Zeit genauso gute Ergebnisse, allerdings fast 2x so schnell.

Du widersprichst dir doch selbst ein wenig- Ja, intern existieren Relikte dieser ominösen "Qualitätsparameter" (wie du korrekt beschreibst aktivierte -h für "high quality" eben -q2 statt -q3 oder -q5 oder was auch immer damals mal Standard war - heute ist das völlig wurscht, da die V Presets diese Parameter fest "eingebrannt"/hardcoded haben). In der Realität spielt das keine Rolle mehr. Ebenso wenig wie das veraltete psychoakustische Modell.

Ich weiß beim besten Willen nicht, wo Du hierbei einen Widerspruch entdecken willst - stattdessen habe ich den Eindruck, daß Du die lame-internen Abläufe nicht verstehen kannst/willst?
BTW, das psychoakustische Modell wird bei beiden Algorithmen übrigens über die Option -q<N> festgelegt.
Noch Glaubensfragen? Dann RTFS.
Du testest gerne: probiere doch mal -V0 -q9 (in dieser Reihenfolge) aus...

Ich hab den Source Code nicht gelesen,

Das ist auf den ersten Blick Deiner Antworen ersichtlich.

aber was du schreibst, sollte jeder zu Hause nachvollziehen können. Probiert es doch selbst mal aus. Man nehme die aktuelle LAME Version, dann erstelle einmal -V0 ohne sonstige Parameter, dann mit -q0 und mit -q2 bzw. -h. Man wird feststellen, dass die Dateien identisch sind, weil V0 auf -q0 gemappt ist, egal welche der genannten Einstellungen man verwendet (sogar runter bis -q4, wenn deine Angabe stimmt).

Auch wenn ich Dir jetzt auf die Füße steigen sollte: bevor Du anderen Widersprüche andichtest, solltest Du das Geschriebene zuvor verstanden haben.
BTW, wie bereits geschrieben, aktiviert -V0 nicht -q0, sondern -q2, auch wenn dies für --vbr-new irrelevant ist, nicht aber für --vbr-old.

Du kannst mit sehr niedrigen Werten, wie z.B. -q5 deutlich schlechtere Werte erzwingen. Das geht dann auf Kosten der Qualität und zu Gunsten der stark gesteigerten Encoder Geschwindigkeit. Wenn aber Geschwindigkeit eine sekundäre oder gar keine Rolle spielt bleibt bei den Standard Einstellungen, denn manuelle Eingriffe werden meisten sowieso ignoriert, das gilt meines Wissens für alle V Presets, bis runter zu -V8.

Du erkennst Deinen Widerspruch?
Desweiteren: "manuelle Einstellungen" werden nicht ignoriert.

sl.tom (Beitrag #17) schrieb: Die -V<N> presets dienen der Bequemlichkeit, damit nicht ein ganzer Wust an Optionen angegeben werden muß. Jain. Natürlich dienen sie der Vereinfachung. Aber sie vermeiden bzw. verhindern auch das Verwenden von Parametern, auf die die Presets nicht getunt sind. Das heißt, der Laie soll es so einfach wie möglich haben,

Bingo. Bequemlichkeit.

und der erfahrenere Benutzer soll nicht mehr wie früher an jeder Schraube drehen können, an der gar nicht gedreht werden sollte, weil die Einstellungen in bestimmten Kombinationen keinen Sinn ergeben.

Was ist das denn für ein Unfug?
Ich darf Dir dringend RTFS ans Herz legen.

Es ist off topic, aber du könntest genauso statt der standard FLAC Kompressionslevel mit -8 als Maximum, durch Verwendung von bestimmten Parametern noch extremere Werte zum Encoden erzwingen, als sie bei -8 schon genutzt werden, um noch einen Tick kleinere Dateien zu erhalten. Da das aber schlicht und einfach Keinen Sinn macht, haben die FLAC Entwickler eben -8 als Maximum festgelegt.

Analog zu "lame -V<N>" dient "flac -<1...8>" der Bequemlichkeit.
Konkret ist die Option -8 die sehr bequeme Kurzform für die Optionen

-l 12 -b 4096 -m -e -r 6 -A tukey(0.5) -A partial_tukey(2) -A punchout_tukey(3)

Selbstverständlich dürfen diese Parameter auch "sinnfrei" modifiziert werden.

Aber das nur am Rande. Will eigentlich sagen: Vertraut mal mehr den Entwicklern, die wissen schon, was sie tun. :prost

Kein Widerspruch. Andersherum wird allerdings auch ein Schuh daraus: würdest Du RTFS betrieben haben, wären Dir die Zusammenhänge klar...

sl.tom (Beitrag #22) schrieb: Michael_60 (Beitrag #20) schrieb: Gibt es jetzt eine Möglichkeit den Replay Gain für FLAC anzupassen, so das es auch mit meinen Fiio X1 funktioniert, Mein AVR (Denon AVR-3313) unterstützt weder bei MP3 noch FLAC die vorhandenen replay-gain tags. Es war zwar nicht die Frage, aber wenn du per UPnP/DLNA mit foo_upnp streamst, kannst du diese Limitierung umgehen, indem du die Anpassung foobar on-the-fly beim Abspielen übernehmen lässt. Siehe Audio Processing in den foo_upnp settings.

Über eine entsprechende Gerätschaft ist das natürlich möglich, jedoch liegen meine FLACs auf einem fetten USB-Stick, den ich bei Bedarf an den AVR stöpsle - das vergaß ich in meinem Beitrag zu erwähnen.

Dann mal nix für Ungut.

Gruß Tom
Edit: Typo gefixt

sl.tom (Beitrag #24) schrieb:

Kurzfassung für Schnelleser: hättest Du eine RTFS Session angesetzt, hättest Du Dir etliches an Tipparbeit ersparen können... [...] Sorry, aber der alte Algorithmus ist nach wie vor der Maßstab für jegliche Arbeiten am neuen und produziert seit geraumer Zeit genauso gute Ergebnisse, allerdings fast 2x so schnell.

Der Quellcode sagt mir ungefähr so viel wie der Papst, wenn er auf Lateinisch predigt: Gar nichts, denn ich verstehe die Sprache nicht. Ich bin deshalb auf die Übersetzungen bzw. Interpretationen, die in Deutsch oder Englisch gehalten sind, angewiesen. Seit mindestens 2007 (wahrscheinlich schon 2-3 Jahre früher) habe ich auf Hydrogenaudio und in Kurzfassung in der LAME History/Changelog ausschließlich von Arbeiten am neuen Algorithmus gelesen, also spätestens seit er den alten Algorithmus in 3.98b1 als Standard abgelöst hat. Inwiefern der alte dennoch der Maßstab sein soll, erschließt sich mir nicht.

stattdessen habe ich den Eindruck, daß Du die lame-internen Abläufe nicht verstehen kannst/willst?

Ich bin gerne bereit mich belehren zu lassen, aber wenn ich ernsthaft den Quellcode des Encoders lesen und verstehen soll, nur um mich über den Unsinn einer Hand voll Kommandozeilenparameter zu streiten, dann halte ich das für einen nicht gerechtfertigten Aufwand.

Noch Glaubensfragen? Dann RTFS.

Es geht mir nicht um Glaubensfragen - an welcher Stelle habe ich denn welche aufgeworfen?

Auch wenn ich Dir jetzt auf die Füße steigen sollte: bevor Du anderen Widersprüche andichtest, solltest Du das Geschriebene zuvor verstanden haben. BTW, wie bereits geschrieben, aktiviert -V0 nicht -q0, sondern -q2, auch wenn dies für --vbr-new irrelevant ist, nicht aber für --vbr-old.

Wie gesagt, --vbr-old ist obsolet und stand hier auch nie zur Debatte. Dass die aktuelle lame.exe von Rarewares mit "-V0", "-V0 -q0" oder "-V0 -q2" absolut identische Dateien produziert, kann ich nachvollziehen, ohne den Quellcode zu kennen. Wenn LAME bei allen Varianten "-q 0" in den Header schreibt, zumindest laut MediaInfo oder mp3guessenc, gehe ich davon aus, dass diese Angabe stimmt.

Du erkennst Deinen Widerspruch?

Offensichtlich nicht.

Desweiteren: "manuelle Einstellungen" werden nicht ignoriert.

Offensichtlich werden bestimmte Kommandozeilenparameter in bestimmten Fällen ignoriert, s.o.

Was ist das denn für ein Unfug?

Noch nie was von den berüchtigten Matrix MP3s gehört?

Ich darf Dir dringend RTFS ans Herz legen.

Wie gesagt, der Quellcode interessiert mich herzlich wenig. Eine transparente Dokumentation wäre mir deutlich lieber. Klingst so, als könntest du die aus dem Ärmel schütteln - würde ich jederzeit gerne lesen.

würdest Du RTFS betrieben haben, wären Dir die Zusammenhänge klar... :prost

Jaja, verstehe schon. Da ich kein Programmierer bin, verstehe ich das Programm nicht, meine Aussagen sind folglich zwangsweise falsch oder müssen auf "Glauben" basieren.

Dann mal nix für Ungut.

Ganz grundsätzlich: Dies ist ein Audioforum, keines für Programmierer. Da sind sind ständige Verweise auf den Sourcecode nicht hilfreich, weil die möglicherweise hinter solchen Verweisen stehenden Überlegungen vom Leser nicht nachvollzogen werden können. Kann natürlich auch sein., dass sie gar nicht nachvollzogen werden sollen. Just my 2 cents...

Zustimmung meinerseits...

Verweise auf den Sourcecode nicht hilfreich, weil die möglicherweise hinter solchen Verweisen stehenden Überlegungen vom Leser nicht nachvollzogen werden können.

Es ist durchaus übliche Praxis, zur Untermauerung seiner Darstellung, auf Quellen zu verweisen - in diesem Kontext ist das nunmal der Quellcode.
Kann dieser nicht gelesen oder verstanden werden, bleibt die Möglichkeit, dies zu lernen.
Hat man dazu keine Lust oder Zeit und beharrt, trotz Widerlegung, seiner unkorrekten Darstellung, ist das doch recht dreist...

Hintergrund, weshalb ich auf dieses Thema überhaupt einstieg, ist jener, daß ich solch einen,sorry, Unfug schon einmal hörte und mir deshalb die Sourcen zur Bust nahm, weil ich es genau wissen wollte, denn die Jungs, welche die diversen Audioalgorithmen entwickeln, haben allesamt Einiges auf dem Kasten.

Aber wie ich bereits schrieb: nix für Ungut.
Daraus muß kein flame-war entstehen - dazu wäre mir auch schon die erforderliche Zeit zu schade...

Gruß Tom
Edit: Zitat wurde nicht wie erwartet angezeigt