alsa konfiguieren

[rendegast]

@smutbert

[whiizy]

Hallo smutbert,

schöne "Metastudie", gibt mal einen guten Überblick, wie die verschiedenen Systeme in Beziehung stehen!

Mir persönlich ging es tatsächlich nur um die Komponenten des Alsa-Universums. Ist Deine Abgrenzung von dmix gegenüber alsamixer, qasmixer, kmix, ... denn wirklich so scharf? Das Zusammenmischen verschiedener Kanalpegel macht doch in vielen Fällen nur Sinn, wenn sich generell die Audiodatenströme mischen lassen. Letzteres leistet unter alsa per default dmix, aber auch schon unter dem Vorbehalt, daß alsa vorher keine hardware-mixer im Audiointerface gefunden hat. Da kommt schon eine erste, eigendynamische Komponente ins Spiel.

Mir liegt daran, daß man die Kontrolle darüber behält, ob ein automatisches Resampling aktiv ist oder ob z.B. eine automatische Konvertierung von Mono zu Stereo erfolgt, weil das irgendwo "notwendig" erscheint.

Mal ein ganz konkretes Beispiel, wo ich mir aktuell nicht ganz sicher bin, ob da dmix nun die Finger drin hat oder nicht:

Eine virtuelle Piano-Software braucht möglichst gute Latenz / Echtzeit. Wähle ich in dieser Applikation aus ...

Code: Alles auswählen

HDA Intel PCH, ALC283 Analog; Direct hardware device without any conversions

..., dann ist die Latenz exzellent (evtl. u.a. weil dmix umgangen ist?)

Stelle ich die Ausgabe hingegen um auf ...

Code: Alles auswählen

HDA Intel PCH, ALC283 Analog; Direct sample mixing device

... ist die Latenz hörbar schleppend bzw. schlecht.

Meint alsa mit "Direct sample mixing device" nun dmix, das ja auch direct im Namen trägt? oder irgendwas anderes und es ist nur eine Ähnlichkeit?

Sollte dmix gemeint sein, dürfte dmix eigentlich keine Umkonvertierung irgendeiner Art vornehmen, da die Pianosoftware in 48 kHz arbeitet und auch die ALC283 nativ 48 kHz verarbeitet. Wo kommt die hohe Latenz dann aber her?

Hast Du dafür auch eine Erklärung?

Thanx

[smutbert]

Mit "Direct sample mixing device" ist der Weg über das dmix-Plugin gemeint und mit "Direct hardware device without any conversions" die direkte Wiedergabe über die Soundkarte - in der Alsa-Schreibweise in deinem Fall also etwas wie hw:PCH,0.

Dass mit dmix (und den meisten anderen Plug-Ins) die Latenz leidet ist auch klar, weil die einzelnen Audioausgabe erst in Häppchen gemischt werden müssen bevor sie wieder in Häppchen an die Soundkarte weitergeleitet werden. Denn dmix kann nicht einfach nur auf der faulen Haut liegen und die Daten durchwinken, nur weil das Format zufällig gerade passt und keine zweite Anwendung etwas wiedergibt - es kann ja jederzeit eine zweite Anwendung mit der Audiowiedergabe starten und dann erwartet man sich schon, dass es beim Einsetzen der zweiten Anwendung keine Unterbrechungen, Knackser oder ähnliches gibt.
Man kann aber durchaus alles konfigurieren und abhängig von der Hardware die Latenz verkleinern indem man die Daten-Häppchen (buffer_size) verkleinert, genauso wie man Samplerate und -tiefe und Zahl der Kanäle mit denen dmix arbeiten soll, festlegen kann.

Wenn es um mehrere Anwendungen und um eine möglichst niedrige Latenz geht, greift man aber meistens eher auf jack zurück. das in dieser Hinsicht wohl recht leistungsfähig und effizient ist.

[whiizy]

Danke smutbert,

ich hätte ja mit aplay -L auch mal selbst schauen können, da sind die Namen der Audio-Outputs zugeordnet.

Mir ist jetzt bei der näheren Beschäftigung mit den Outputs noch etwas Überraschendes aufgefallen. Die direkte Ausgabe auf die hw ("Direct hardware device without any conversions") hätte ich eigentlich als unverfälschter erwartet, als die Ausgabe über front ("Front speakers"). Letzteres steht nach meinem Dafürhalten für eine normale Stereoausgabe 2.0.

Nun klingt aber ausgerechnet die direkte Ausgabe über die Hardware muffiger und weniger detailliert . Dmix kann dafür ja schonmal nicht verantwortlich sein, da es in diesem Fall umgangen ist (wie Du es ja auch andeutest).

Was macht der Pfad "Front speakers" dann besser/anders als der Direktzugriff??

Zwei formale Unterschiede dieser beiden Output-Pfade sind mir schon aufgefallen. Der PCM-Zug im alsamixer (oder auch kmix) ist bei Direktzugriff nicht wirksam. Beim Abspielen über "Front speakers" hingegen verändert er die Lautstärke. Das erscheint zunächst ja auch plausibel. Aber daß zusätzlich eingeschleifte Volumenregler für den Klang förderlich sind, widerspricht eigentlich der Erfahrung (PCM-Regler stand natürlich in beiden Fällen auf gleicher Höhe max).

Hat dieser front-Kanal irgendein verstecktes Equalizing in diesen typischen Onboard-Codecs (ALC)? Oder ist der Direct-Pfad doch nicht so direkt, wie einem der Name glauben macht? Schlummert da noch irgendwo so ein Osterei, wie das dmix-plug?

Einen weiteren Unteschied finde ich auch noch im access-mode, wenn die Audio-Streams gerade fließen. RW_INTERLEAVED bei Direct hardware und MMAP_INTERLEAVED bei Front speakers. Ich habe davon bisher noch nichts gehört, daher halte ich eine negative Klangbeeinflussung erstmal für unwahrscheinlich. Ich habe die beiden Outputs hier zum Vergleich nochmal gegenübergestellt:

Code: Alles auswählen

hw:CARD=PCH,DEV=0
    HDA Intel PCH, ALC283 Analog
    Direct hardware device without any conversions

cat /proc/asound/PCH/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 64
buffer_size: 192

PCM-Zug in alsamixer und kmix funktioniert nicht.

Code: Alles auswählen

front:CARD=PCH,DEV=0
    HDA Intel PCH, ALC283 Analog
    Front speakers

cat /proc/asound/PCH/pcm0p/sub0/hw_params

access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 64
buffer_size: 192

PCM-Zug in alsamixer und kmix funktioniert.

Aber wenigstens die Latenz von front und direct ist (gefühlt) gleich, wenigstens nicht noch eine Variable im Spiel ...

Gruß

[smutbert]

Die ganze Konfiguration unter /usr/share/alsa, zB /usr/share/alsa/pcm/front.conf ist nicht ganz einfach zu durchschauen - oft ist es einfacher Dinge durch Versuch und vor allem viel Irrtum herauszufinden.

So kann man zB versuchen zwei aplay-Kommandos auf ein pcm loszulassen, um zu sehen ob ein pcm durch dmix geht:

Code: Alles auswählen

$ aplay -D front:Juli,0 -r 44100 -c 2 -f S32_LE /dev/zero
Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 44100 Hz, Stereo
$ aplay -D front:Juli,0 -r 44100 -c 2 -f S32_LE /dev/zero
aplay: main:722: audio open error: Device or resource busy

und auch daran, dass die 44100 beibehalten werden, was man im proc-Dateisystem überprüfen kann

Code: Alles auswählen

$ cat /proc/asound/Juli/pcm0p/sub0/hw_params 
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 44100 (44100/1)
period_size: 5512
buffer_size: 22052

sieht man, dass kein mixing und keine Konversionen stattfinden.

Für das mixing ist wie gesagt dmix verantwortlich und für das Konvertieren ein Plugin namens plug. Letzteres hat in der Standardkonfiguration, wie ich vielleicht schon erwähnt habe, lange Zeit beim Resampeln einfach nur linear interpoliert und tut es vielleicht heute noch - die klangliche Verfärbung dadurch kann durchaus hörbar, muss aber gar nicht unangenehm sein - in einem anderen Forum habe ich einmal gelesen, dass sie jemand mit dem warmen Klang eines Röhrenverstärkers verglichen hat.

Jedenfalls halte ich auch es für komplett unbedeutend in welchem Übertragungsmodus die Audiodaten übertragen werden, aber es gibt ja auch Leute, die angeblich erkennen, ob eine flac-Datei von einer Festplatte oder eine SSD abgespielt wird und ob eine CD auf einem Laptop ohne Stromnetz oder einem PC mit normalem Netzteil gerippt wurde.... und ich meine man bildet sich allzuleicht irgendwelche Unterschiede ein, selbst, wenn man gar keine erwartet bzw. der logische Verstand sogar sagt, dass es keine Unterschiede geben kann.
Dann lauert außerdem noch die Falle, dass man grundsätzlich das lautere Signal so gut wie immer als besser klingend empfindet - selbst bei ziemlich kleinen Lautstärkeunterschied.

Diese Ungewöhnlichkeit mit dem nicht immer wirksamen PCM-Regler kann ich hier nicht nachvollziehen und auch der Modus steht bei mir auf RW_INTERLEAVED egal auf welche (direkte) Art ich die Soundkarte anspreche (mittels hw:x,y oder front:x,y). Ich würde bei solchen Tests nur möglichst simple Anwendungen verwenden, zB aplay.

[whiizy]

Nettes Beispiel mit den zwei konkurrierenden Nulldatenströmen, danke smutbert!

Ich konnte auch auf diese Weise nochmal reproduzieren, was zwischenzeitlich ja schon bekannt war: Sowohl hw, als auch front, werden demnach nicht von einem dmix oder plug ausgebremst:

Code: Alles auswählen

$ aplay -D hw:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

$ cat /proc/asound/PCH/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 2048
buffer_size: 8192

$ aplay -D hw:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
aplay: main:722: audio open error: Device or resource busy

Code: Alles auswählen

 aplay -D front:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

$ cat /proc/asound/PCH/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 2048
buffer_size: 8192

$ aplay -D front:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
aplay: main:722: audio open error: Device or resource busy

Ferner sieht man, daß die default buffer- und period-sizes deutlich größer sind, als es für eine gute Latenz von Tasteninstrumenten nötig ist (Daumenregel kleiner Buffer -> geringe Latenz).

ich meine man bildet sich allzuleicht irgendwelche Unterschiede ein, selbst, wenn man gar keine erwartet bzw. der logische Verstand sogar sagt, dass es keine Unterschiede geben kann.

... in der Regel bildet man sich aber das ein, was man zuvor erwartet oder was einem persönlichen Bias entspricht. Das war in diesem Fall jetzt aber genau umgekehrt: Ich bin davon ausgegangen, daß der direkte Hardware-Zugriff am wenigsten beeinträchtigt sein müsste, und bin dann davon überrascht worden, daß der Ausgang "Front speakers" weniger verwaschen klingt.

Mal wieder weg von der Psychologie zur Technik: Ist überhaupt irgendein Grund bekannt, warum hw und front unterschiedlich klingen könnten? Drei formale Gründe hatten wir ja bisher, aber keiner davon muss auch kausal sein:

1) PCM-Fader wirksam / unwirksam
2) access: MMAP_INTERLEAVED / RW_INTERLEAVED
3) Es existieren zwei Output-Namen, hw und front. Wären sie identisch, würde einer davon ausreichen

Dir ist da auch nichts bekannt, was "Front speakers" auszeichnet, oder?

[BenutzerGa4gooPh]

@smutbert: Auch von mir danke!
Wie kann man die Abtastrate/Samplingtiefe einer vorhandenen Audio-Datei/Tonträger ermitteln?
Wie kann man bei der (evtl. ungünstigen) Wiedergabe die aktuelle Abtastrate sehen?
Wie kann man - falls notwendig - auf die Pulseaudio-Automatik Einfluss nehmen? Oder klappt das so gut wie immer?
(Hintergrund: Um die oben von dir beschriebenen Qualitätseinbußen durch unterschiedliche Raten zu vermeiden, Automatik zu prüfen.)

[whiizy]

Wie kann man die Abtastrate/Samplingtiefe einer vorhandenen Audio-Datei/Tonträger ermitteln?

Eine Möglichkeit wäre z.B. der Befehl "file" (wenn das WAV einen gewöhnlichen header hat):

Code: Alles auswählen

$ file /usr/share/sounds/alsa/Noise.wav
/usr/share/sounds/alsa/Noise.wav: RIFF (little-endian) data, WAVE audio, Microsoft PCM, 16 bit, mono 48000 Hz

Wie kann man bei der (evtl. ungünstigen) Wiedergabe die aktuelle Abtastrate sehen?

Eine Möglichkeit war oben im thread schon zu sehen. Man spielt die Audiodatei ab und schaut dann in die aktuellen Hardware-Parameter:

Code: Alles auswählen

Bsp.:
cat /proc/asound/PCH/pcm0p/sub0/hw_params

Gruß

[smutbert]

Die Samplerate und das Sampleformat zeigen auch viele Audio-/Videoplayer an, zB vlc unter Werkzeuge→Codec-Informationen und dann gibt es auch noch mediainfo und mediainfo-gui.

Und das Kommando funktioniert nur mit einer Soundkarte PCH, an deren ersten Gerät etwas ausgegeben wird. Für einen Überblick würde ich es mit

Code: Alles auswählen

$ cat /proc/asound/card?/pcm?p/*/hw_params

versuchen. Das sollte nacheinander den Status aller Geräte aller Soundkarten auflisten. Verwechslungsgefahr besteht nur, wenn gerade über mehr als ein Gerät irgendetwas wiedergegeben wird.

[…]
3) Es existieren zwei Output-Namen, hw und front. Wären sie identisch, würde einer davon ausreichen

Dir ist da auch nichts bekannt, was "Front speakers" auszeichnet, oder?

So wie es in Alsa läuft benötigt man ja irgendeine Möglichkeit die Hardware anzusprechen und das geschieht mit hw:x,y. Ohne die Möglichkeit die vorhandene Hardware zu addressieren, würde man sich mit der Definition weiterer pcms schwer tun.
Die vorhandene Alsakonfiguration definiert nun eben noch einige pcms mit aussagekräftigen Namen, wie zB iec958 für digitale Ausgänge, mit Front sind vermutlich die beiden normalen Stereokanäle gemeint, surround50, 51, 71,… für die verschiedenen Mehrkanalvarianten, hdmi für die Ausgabe über HDMI oder DisplayPort, usw.

Meine Meinung nach müsste es also im wesentlichen egal sein ob man front:x,y oder hw:x,y verwendet, nur kann man sich beim Namen front sicher sein, dass das Gerät Stereo beherrscht, genauso wie man bei surround51 weiß, dass es 6 Kanäle unterstützt.

[whiizy]

mit Front sind vermutlich die beiden normalen Stereokanäle gemeint,
[...]
Meine Meinung nach müsste es also im wesentlichen egal sein ob man front:x,y oder hw:x,y verwendet.

Zustimmung, denn so weit war ich ja selbst bereits . Aber es gibt ja wie gezeigt objektive Unterschiede bei der Verwendung, also stehen die Namen auch für Unterschiedliches.

Soweit mir bisher bekannt ist, steht "hw" für die direkte Kommunikation der Anwendung mit dem Kernel, noch genauer dem alsa Treiber im Kernel. Da "front" aber zu anderen Ergebnissen führt, könnte man daraus schließen, daß dieser Modus vorher vielleicht noch mit anderen alsa-plugins kommuniziert, bevor auch dann die Audiodaten schließlich am Kernel münden.

Ich fürchte, dazu muß man die exakten Konfigurationen unter /usr/share/alsa/ lesen und verstehen können. Das dürfte aber nur den Wenigsten vergönnt sein, vielleicht werden wir das hier nicht aufklären können.

PS: Hervorhebung von mir.

[whiizy]

Vielleicht noch eine weitere Beobachtung am Rande. Wenn ich mal bewusst mit aplay über dmix abspiele, dann schwenkt auch hierbei der access auf MMAP_INTERLEAVED (vgl. RW_INTERLEAVED bei hw). Gegenüber hw halbiert sich mit dmix auch die period_size von 2048 auf 1024:

Code: Alles auswählen

$ aplay -D dmix:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

$ cat /proc/asound/PCH/pcm0p/sub0/hw_params
access: MMAP_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 1024
buffer_size: 8192



$ aplay -D hw:PCH,0 -r 48000 -c 2 -f S32_LE /dev/zero
Playing raw data '/dev/zero' : Signed 32 bit Little Endian, Rate 48000 Hz, Stereo

$ cat /proc/asound/PCH/pcm0p/sub0/hw_params
access: RW_INTERLEAVED
format: S32_LE
subformat: STD
channels: 2
rate: 48000 (48000/1)
period_size: 2048
buffer_size: 8192

Wie gesagt, das muß nichts bedeuten, es fällt erstmal nur auf.

PS: Ist übrigens ein Jessie 3.16.0-4-amd64 #1 SMP Debian 3.16.7-ckt25-2+deb8u3 (2016-07-02) x86_64 GNU/Linux

[BenutzerGa4gooPh]

Danke whilzy, danke smutbert! Einfach hinreißend hinreichend, Eure AWs! Der Thread gehört angepinnt!!!

[whiizy]

Einfach hinreißend hinreichend,

Jana66
"Perfection is attained, not when there is nothing more to add, but when there is nothing more to take away."

[BenutzerGa4gooPh]

Was m. E. noch ganz kurz in den Thread reingehört: Kleine Zusammenfassung zur Abtastrate/Samplingtiefe bei Konvertierung Audo-CD in MP3, Programme sind bekannt, Youtube-Video in MP3. MP3 absichtlich, wegen Autoradio, Player-Vilefalt, Hinweis/Zusammenfassungs-Kürze. (Audio-CD geht eigentlich aus dem Thread hervor.) Aber es mag auch ein anderer Faden sein ... .

[smutbert]

Was meinst du?
Enkodieren/komprimieren/konvertieren hat ja eigentlich nichts bis wenig mit Abtastrate und Sampleformat zu tun. Ich meine normalerweise ändert sich ja keines von beiden, nur weil die Audiodaten (neu) komprimiert werden.

[BenutzerGa4gooPh]

Beispiel Banshee

Erst mal allgemein für alle, um das bereits Gesagte zu unterstreichen. Unter Bearbeiten -> Titeleigenschaften kann man für Audio CD sehen:
981 KB/sec, 44100 Hz, 2 Kanäle, 16 Bits pro Sample, Codec Flac

Zum Import von Audio-CDs als MP3 mit Banshee:
Bearbeiten -> Einstellungen - Quellspezifisch -> Quelle: Audio CD, es erscheint die Option MP3 (LAME-Encoder) mit 2 Kodiermöglichkeiten
Konstante Bitrate mit 64 bis 320 kbps
Variable Bitrate mit Qualität 0 ... 9 ... sehr aussagekräftig
Was tat ich einfach: KBR auf Maximum, hatte dazumal wenig Zeit, Party stand an. Und nun dieser Thread.

Deshalb stellt sich mir die Frage, ob das wirklich die qualitätsmäßig beste Lösung für mp3 war/ist. (Die Dateigrößen der mp3s sind eher zweirangig, FP sind groß genug. Mir ist bekannt, dass es mittlerweile bessere/verlustfreie Formate als mp3 gibt, aber mp3 das ist wohl immer noch weit verbreitet, mein altes Auto-Radio kann nur das - also Audio-CD und mp3-CD.)

Die Bitrate vor Konvertierung müsste sich ja aus Samplingrate 44.100Hz x Samplingtiefe 16 Bbit x 2 Kanäle = 1.411.200 bit/s ergeben. (Komme irgendwie nicht auf 981 KB/sec?) Und nun wird umcodiert ... also Bitrate einfach auf Maximum - oder doch besser nicht? Konstante oder Variable Bitrate?

(Wir sind mittlerweile etwas OT, aber den Bezug zu o. g. Beiträgen finde ich interessant.)

[MSfree]

Deshalb stellt sich mir die Frage, ob das wirklich die qualitätsmäßig beste Lösung für mp3 war/ist.

In diesem Zusammnhang:
Alt, aber immer wieder interessant:

http://www.heise.de/ct/artikel/Kreuzver ... 87592.html

[BenutzerGa4gooPh]

Ah 256 kbit/s genügen - alles andere ist Einbildung - und mit 320 kbit/s ist man eindeutig (oder eingebildet) auf der sicheren Seite.
(Wenn es eben keinen Zusammenhang zur urspünglichen Kodierung und zu billigeren Lautsprechern/Kopfhören gibt.)

[MSfree]

Ah 256 kbit/s genügen - alles andere ist Einbildung - und mit 320 kbit/s ist man eindeutig (oder eingebildet) auf der sicheren Seite.

128kBit sind nur selten zu wenig. Es gibt ein paar wenige Situationen, bei denen das nicht ausreicht, z.B. Snare Drums, du ein sehr breites Spektrum an Frequenzen erzeugen, bei denen die Kompression durch weglassen von Frequenzen hörbare Artefakte erzeugt. Ich nehme daher 160kBit und bisher hat sich noch keiner über die "schlechte" Qualität beschwert und ich selbst höre da keine Artefakte mehr.

Überhaupt, wenn man selbst schon fragen muß, was die beste Bitrate ist, sollte man sich mal überlegen, warum man so eine Frage stellt. Mit der Qualität kann es ja nichts zu tun haben, denn man würde nicht fragen, wenn man wirklich einen Unterschied hören würde. Es geht also wirklich nur um Esoterik und Voodoo, genauso wie sauerstofffreie Kabel für 200 Euro pro Meter.

[ralli]

Der Hörgenuß wird begrenzt durch die physikalischen Höreigenschaften des menschliche Ohres, das bekanntermaßen nur einen begrenzten Frequenzumfang hören kann. Das ändert auch eine noch so teure HiFi Anlage nicht. Das ist nun aber wirklich nicht neu. Allerdings wird es schon Qualitätsunterschiede der verschiedenen Wiedergabemedien geben, was den Klirrfaktor oder Klangreinheit angeht. Subjektiv empfinde ich einen FLAC Sound doch etwas voluminöser als eine normale MP3 Datei. Ich bin nicht sachkundig, denke aber, es wird wohl an der höheren Abtastrate liegen.

[MSfree]

Allerdings wird es schon Qualitätsunterschiede der verschiedenen Wiedergabemedien geben

Naja, jein. Ob ich eine unkomprimierte CD-Aufnahme (44kHz 16Bit Steroe) abspiele oder ob ich die verlustfrei als 44kHz, 16Bit, Stereo FLAC abspiele, ist egal, die (entkomprimierten) Daten sind identisch.

Ausserdem gibt es das FLAC Format nicht. Du kannst in FLAC so ziemich alles von 8kHz bis 192kHz Abtastrate in 8 bis 32 Bit Signaltiefe mit 1 bis 8 Kanälen speichern.

Subjektiv empfinde ich einen FLAC Sound doch etwas voluminöser als eine normale MP3 Datei.

Das ist eben genau das, was mit dem von mir verlinkten Heise-Artikel schon im Jahr 2000 widerlegt wurde. Es gab damals auch einen Puplikumstest, bei dem man verschiedene Musikstücke in 128kBit-MP3, 256kBit-MP3 und Original-CD-.Rip runterladen konnte und bewerten sollte. Den Dateien war nicht anzusehen, wie sie komprimiert wurden, weil man die dekomprimierten Stücke als WAV runterladen und probehören mußte. Das Ergebnis war, daß die Erkennungsrate für MP3 im Bereich des zu erwartenden Zufalls lag. Mit andern Worten, wer meint, einen Unterschied zu hören, bildet sich etwas ein.

Ich bin nicht sachkundig, denke aber, es wird wohl an der höheren Abtastrate liegen.

Ein 44kHz MP3 hat die gleiche Abtastrate wie ein 44kHz-FLAC oder ein 44kHz-CD-Rip.

[ralli]

MSfree, ich kann nicht anders, als philosophisch darauf zu antworten:

Da alle moralische Verantwortlichkeit des Menschen von seinen Wertempfindungen bestimmt wird, muß dem epidemischen Irrglauben entgegengetreten werden, daß nur dem Zähl- und Meßbaren Wirklichkeit zukomme. Es muß überzeugend klargemacht werden, daß unsere subjektiven Erlebnisvorgänge den gleichen Grad von Realität besitzen wie alles, was in der Terminologie der exakten Naturwissenschaften ausgedrückt werden kann.

Zitat Konrad Lorenz.

Die große Frage ist doch, wie definieren wir Realitätsverlust? Für mich ist es ein Realitätsverlust, wenn ich dem Subjektiven weniger Realität zuschreibe als wie den physikalischen Meßergebnissen.

Und weiß Du was? Im Zweifelsfalle würde ich mehr meinem Ohr vertrauen als wie die angegebenen Meßwerte. Da staunst Du was? Und danach würde ich auch meine Kaufentscheidung treffen.

[smutbert]

Hier geht es wohl kaum um Wahrnehmungen, die etwas mit Moral zu tun haben
Angefangen hat es mit mp3 vs flac und nachdem Speicherplatz kaum noch ein Argument ist, bleiben wohl nur wenige, dafür aber möglicherweise zwingende Gründe für mp3, wie zB die Kompatibilität mit einem bestimmten Wiedergabegerät, ansonsten sprechen meiner Meinung nach so viele Gründe für flac, dass die Wahrnehmung auch schon egal ist...
Die Diskussion wie man mit der Diskrepanz zwischen eigener Wahrnehmung und Messungen oder technischen Daten umgeht, ist zwar wahrscheinlich ganz interessant, aber so wie sich solche Threads in Hifi-Foren entwickeln, habe ich auch etwas Scheu, um nicht zu sagen Angst vor so einer Diskussion und in diesen Thread passt sie jedenfalls bestimmt nicht
____

Grundsätzlich ist die Qualität bei gleicher durchschnittlicher Datenrate mit einer Variablen Bitrate höher, weil der Encoder dann die Einsen und Nullen dort „investieren“ kann wo sie notwendig sind, aber die genaue durchschnittliche Bitrate kennt man erst nach dem Kodieren und wenn es um Kompatibilität mit merkwürdigen Geräten geht (und für mich ist alles was weder ogg noch flac kann höchst merkwürdig), dann ist man mit einer konstanten Bitrate von maximal 192 kBit/s immer noch auf der sichersten Seite.
Zufällig ist 192 kBit/s auch so ungefähr die Bitrate ab der sich die Trefferquote bei seriösen Hörtests nicht mehr von reinen Zufallstreffern abhebt.

Aber selbst wenn das nicht der Fall wäre, dann klingt es ja noch lange nicht schlecht. Wenn es darum geht was besser klingt — mp3 oder Original hat meines Wissens auch schon gelegentlich ein ~128-160 kBit/s mp3 über das Original triumphiert ☺

320 kBit/s war übrigens soweit ich weiß lange Zeit das Maximum, aber inzwischen gibt es bei Lame auch höhere Bitraten - nur dürfte es dann mit der Kompatibilität mit einigen Abspielgeräten nicht so gut aussehen.
In einer alten Version stand in der lame-Dokumentation, dass die Verluste bei 160-180 kBit/s bereits nicht mehr wahrnehmbar wären. Ich bin nicht sicher ob man seitdem die Ohren verbessert hat - lame ist aber jedenfalls bestimmt weiterentwickelt worden und besser geworden.

Bei der Variablen Bitrate gibt es auch eine Tabelle mit Anhaltspunkten, so wird "-V 2" empfohlen, was ungefähr auf eine durchschnittliche Bitrate von 190 kBit/s hinauslaufen soll, die beste Qualität bietet "-V 0" mit durchschnittlich ~245 kBit/s. 5 sind demnach ~130 kBit/s und von 7 oder noch höheren Werten wird definitiv abgeraten, weil hier offensichtlich VBR versagt - bei so niedrigen Bitraten wird stattdessen ABR empfohlen, aber nachdem "-V 7" wohl schon weniger als ~128 kBit/s ergibt dürfte das heutzutage ohnehin weitgehend uninteressant sein.


banshee hat übrigens schon dafür gesorgt, dass ich ein paar meiner CDs mehrmals gerippt habe.
Es hat CDs, von denen es keine Titelinformationen gefunden hat und wegen eines Bugs waren das viele CDs, einfach unter »unknown/album/title 01.mp3« oder so ähnlich gespeichert und dasselbe mit der darauffolgenden CD gemacht und der nächsten, … Dabei hat es nicht nur die gerade erst gerippten mp3s überschrieben, nein es hat sich sogar die eigene Datenbank kaputt gemacht

[ralli]

Und genau das ist der springende Punkt, die Kompatibilität mit vorhandenen Abspielgeräten sollte man schon beachten und im Auge behalten. Persönlich tendiere ich zu flac, aber das können normale Player auch schon nicht mehr, klar sie heißen ja auch mp3 Player. Allerdings benutze ich selbst kein mobiles Abspielgerät und höre Musik nur zwischendurch mal am PC, da ist flac ja kein Problem. Das mit der Wahrnehmung und dem Zitat würde ich liebend gerne mal diskutieren, aber hier ist wohl nicht der richtige Ort dafür. Ganz einfach, weil der Technik, Laborwerte ect und viele andere Dinge zu viel Wert beigemessen wird,und der gesunde Menschenverstand oft, weil eine Sache nicht mehr ganzheitlich betrachtet wird, auf der Strecke bleibt. Im übrigen konnte ich das dem Thread zugrunde liegende Problem trotz Eurer Hilfe nicht lösen. Ich habe bei einer erneuten Minimalinstallation die entsprechende Datei angelegt. Er hat sie in Mixer dann zwar als Standardkarte richtig angezeigt, aber es kommt nach wie vor kein Ton. Ich werde bei dem Gnome Desktop bleiben, da kann ich zwischen dem Onboard Chip und der externen USB Soundblaster wählen. Aber das scheint nur mit Pulseaudio zu gehen. Egal, es funktioniert und die Ausgabequalität ist wirklich gut. Was will ich mehr, ich bin zufrieden. Nochmals vielen Dank für die hilfreiche Unterstützung.

[smutbert]

Hm, es muss natürlich auch ohne Pulseaudio gehen, aber wo der Fehler liegt, kann ich nur raten. Eine Möglichkeit wäre, dass sich im Mixer irgendwo ein stumm geschalteter Schalter oder Regler versteckt und ihn erst Pulseaudio aktiviert hat - in dem Fall sollte es nach der Deinstallation von Pulseaudio sogar weiterhin funktionieren. Auch Tippfehler sind immer wieder ein heißer Tipp...

Wenn du der Sache auf den Grund gehen willst, könntest du ev. noch einmal posten, was du in welche Datei geschrieben hast und mit welchen Programmen du es ausprobiert hast.
Wenn nicht, dann lassen wir es - schließlich ist Pulseaudio ja dazu da, den Umgang mit dem Audiosystem zu vereinfachen...