Sample Rate Converter (SRC) im Vergleich

[play-mate]

Hallo Winfried,

ich denke wir beenden die Diskussion an dieser Stelle, denn sie schweift vom eigentlichen Thema, siehe Eingangspost, ab. Hier geht es nicht um cmp² oder so, sondern um den SRC upsampling Algorithmus und wie man testweise Unterschiede hörbar machen kann.

Dies hat doch nichts mit cMP zu tun.
Der Quellcode ist offen und den kannst du in Foobar oder sonnst wo einbinden und anhören. Uli Brüggemann hat euch eine vorzügliche Grafik zur Darstellung geliefert, dann schau sie doch an !

Es ist fast so dass alle vom Geschmack von Erdbeereis quatschen; sich alle die Rezeptur anschauen wollen und alle eine fanatische Meinung über Erdbeereis haben wollen, anstatt mal die Löffel auszuklappen und einfach mal hören bzw. schmecken.....

Was ist denn das für ein Umgang mit Audio ?????


Leif

[play-mate]

Hallo Ulli,

Viel einfacher den SoX hier runter zu laden, und den .DLL in Foobar einzubinden :

http://www.hydrogenaudio.org/forums/ind ... opic=67373

-aber SoX ist kein wirklich seriöses Alternativ zu Secret Rabbit Code.
SoX hört sich im Vergleich immer noch analytisch, gläsern und "digital" an.
Der einzige Vorteil ist dass er den CPU kaum belastet.....

L.

[uli.brueggemann]

Hi Freunde,

mir geht hier die Rumraterei mittlerweile gegen den Strich. Also wollte ich es genau wissen (und muss dabei eine Aussage meinerseits revidieren, hab da vielleicht was falsch abgelesen).

cPlay de-msystifiziert:

Also: wir sprechen hier ja immer von linearen Systemen. Was Nichtlineares, also Klirr ist nicht erwünscht beim High-End. So, und nun lässt sich ein lineares System ja wunderbar identifizieren, indem man einen Dirac-Impuls reinschickt. Raus kommt dann die Systemantwort.

Also habe ich mir eine 44/16-wav erzeugt. 20 sek lang, alles digital Null, nur in der Mitte ist der Pegel maximal = 32767 für einen Abtastwert. Die Datei mit cPlay abgespielt, dabei auf 96 kHz hochgesampelt und die Interpolation jeweils mit SRC 145 dB und 121 dB als auch Sox VeryHighQuality mit 99% und 95% Bandbreite gewählt. Ausgabe an meine Fireface spdif und dann mit Audition eine 32-Bit-Aufnahme per Fireface spdif gemacht. Mit Audition kann mann dann wunderbar feststellen, was denn Null geblieben ist und das wegschneiden. Als Ergebnis kommen genau die sinc-Filter heraus, die beim cPlay verwendet werden.

Und das wird im Bild oben dargestellt. Ich hab mit Acourate den Frequenzgang dargestellt und siehe da, es zeigt sich so einiges. Mit der roten Kurve geht es flach los, es wird dann immer steiler. Die Kurven in dieser Reihenfolge sind:

1. SRC 121 dB
2. Sox VHQ mit 95% Bandbreite
3. SRC 145 dB
4: SoX VHQ mit 99% Bandbreite
5. Acourate mit 99.95% Bandbreite (32 bit float), also bei 22040 Hz abschneidend

Nun, was zeigt sich bei der Filterlänge (alle Filter linearphasig):

1. = 202 Stützpunkte
2. = 624 Stützpunkte
3 = 724 Stützpunkte
4. =3074 Stützpunkte
5. = 65536 Stützpunkte

Wie erwartet steigt die Filterqualität mit der Filterlänge. Was mir noch aufgefallen ist: SRC zeigt im Sperrbereich einen gleichmäßigeren Verlauf, während Sox dagegen mehr zappelig ist. Da scheinen Rechnenungenauigkeiten mit reinzuspielen. Bei SRC stimmt wiederum die Aussage 121 dB bzw. 145 dB nicht. Es gibt da nicht wirklich 20 dB Unterschied im Sperrbereich zwischen der ersten und dritten Kurve.

Meiner bescheidenen Meinung nach sollten SRC145 und SoX VHQ mit 96% sehr ähnlich klingen. SoX VHQ 99 ist das steilste Filter, bewirkt aber mehr "Rauschen" im hochfrequenten Bereich, vielleicht ist das für Feinohren nerviger.

Ansonsten ist alles schlichtweg reine Mathematik, nichts Mystisches.

Grüsse, Uli

PS: ich muss mich dahingehend korrigieren, dass ich bei SRC viel zu viele Stützpunkte im Quellprogramm gesehen habe. Möglicherweise hat aber cics auch eine alte SRC-Version eingebaut, da ja Erik keine dll mehr für Windows seit geraumer Zeit mehr pflegt. Das würde die Differenz zwischen derzeitigem Quellprogramm und der konkreten Messung hier erklären.

[Bernd Peter]

Hallo Leif,

jetzt haben wir alle gemeinsam doch eine schöne Weg- oder Denkstrecke zurückgelegt.

Uli Brueggemann mit seinen profunden Kenntnissen hat uns erklärt, daß lange Filter das beste Ergebnis beim Upsampling erzielen.

Die brauchen aber naturgemäß Zeit bei der Berechnung.

Das heißt im Klartext, daß Echtzeitanwendungen das Manko bei solchen Filter sind.

Deshalb habe ich immer - mit den 3 wirklich guten SRCs, die es auf dem Markt gibt - vorab das Upsampling in aller Ruhe auf dem Rechner machen lassen und danach mir die Files in 96 oder 192kHz angehört.

Jeder der 3 SRCs hat seine eigene Klangcharakteristik, jede upgesampelte Datei hat sich etwas von der Ursprungsdatei (16/44.1) klanglich unterschieden.

Im Ergebnis bin ich nach und nach immer wieder auf 16/44.1 zurück, weil es für mich am natürlichsten klang.

Gruß

Bernd Peter

[play-mate]

Hallo Forum,

Ich denke vorerst Bernd Peter zuzustimmen, dass wir hier schon alle was Lernen, und dass ist der edle Zweck eines Forums. Was für den einen unmöglich erscheint mag für den anderen ein Denkanstoß sein.

Ulli :
cPay kann zwar keine Coverdarstellung, aber er braucht keine cue-sheets. Nur cMP braucht eine cue-Datei.
Keiner will jemand cMP2 aufdrängen. Solche Unterstellung höre ich subtil (leider) immer wieder und auch das die Technik hinter diesem Projekt unmöglich primitiv zu bedienen sei.
Alles Vorurteile !

Es darf aber wohl schon darauf hingewiesen werden, dass es auch anders geht als die gängigen Vorstellungen von Laptop & DAC -"und alles ist hervorragend" -Strategie.
Das cMP Projekt ist seit über 4 Jahren von einer äusserst intelligenten Gemeinde von fanatischen Audiophilen Digitalexperten entstanden, die sich in akribischer Weise, mit den Problemen von Audio in Computern beschäftigt haben und Lösungen dazu formuliert haben.

Das ist ein Schatz von allgemeinnützlichen Erkenntnissen die man annehmen kann; sich von inspirieren lassen kann, oder schlicht ignorieren kann.
Wenn manche Audiophile ein Bedürfnis haben diese Erkenntnisse angreifen zu wollen, darf man wohl jedenfalls erwarten dass sie sich zu mindestens den cPlay´er einfach mal anhören....
Nur zu behaupten das ist : Unsinn, Unpraktisch oder Unglaubwürdig ist nicht seriös.

Ich finde es ehrlich gesagt phänomenal dass man ein solchen Fundus und solche Software zum Null-Tarif haben kann.....aber bitte : "Jeder dem seinen"

Uli :

Es gibt da nicht wirklich 20 dB Unterschied im Sperrbereich zwischen der ersten und dritten Kurve.

-die 20dB ergeben sich, wenn der Computer in cMP Modus läuft. Der im cPlay eingebaute Upsampler ist eine 0.1.5 Version, bevor die 64 Bit Versionen rauskamen.

Gruß Leif

[Kienberg]

Hallo Leif,

Hallo Sigi & Winfried,Ich verstehe euren Zweifel, aber der Kernpunkt des on- versus offline Upsamplens liegt nicht in dem Upsampling aber in dem Algorithmus.

hier geht's nicht um irgendwelche Zweifel, sondern um einfache Grundlagen der Informationsverarbeitung.

Wenn der Algorithmus sich auf die gesamte Datei aus einem Batch beziehen soll, entsteht ein anderer Wert in den Interpolationspunkten, als wenn diese in einer begrenzteren Sequenz von beispielsweise 340239 Koeffizienten.

1. Der Begriff "Batch" steht ja als Abkürzung für "Batch-Verarbeitung", oft auch "Batch-Job" genannt

2. Arbeitet ein System eine Befehlsfolge ohne Interaktion durch einen Benutzer ab, spicht man von "Batch-Verarbeitung"

3. Ein Programm, das einen Algorithmus auf eine vorgegebene Informations/Datenstruktur ausführt, muss diese Informationen/Daten immer
- erst einlesen
- dann verarbeiten und
- dann ausgeben

DAS gilt auch für cMP !!!

4. Auf welchen Datenbereich innerhalb einer Datei dieses Programm nun seinen Algorithmus anwendet, ist völlig unabhängig ob es Interaktiv oder als "Batch-Job" abläuft. Einzige Ausnahme wäre, wenn der User während der Ausführung eingreift und z.B. die Parameter des Algorithmus ändert (mein "Neurofeedback" von vorhin )

Das gilt auch für Dein Beispiel mit den 340239 Koeffizienten !!!

5. Die Ausgabe erfolgt auf ein Gerät (*), das kann eine Soundkarte sein oder aber ein Disklaufwerk, Speicherstick, etc.; der Informationsinhalt, also in unserem Fall der Klang des Musikfiles, ist davon unabhängig, muss bitidentisch sein.

DAS gilt auch für cMP !!!



(*) Eines der genialen Ideen bei der Entwicklung von UNIX war es, jedes Gerät als "Datei" anzusprechen......ja, Leif, auch eine Soundkarte

Gruss
Sigi

[play-mate]

Hallo Sigi,

Nicht einen einzigen deiner Punkte kann ich wirklich zustimmen.

1. Ob der Algorithmus sich auf den Batch (Stapel, Ladung, Menge oder Partie) oder nur auf einen ausgewählten Teil der Datei z.B. 30.000 Samples bezieht, hat sehr wohl Einfluss auf das Resultat. Das Upsampling ist ein laufender Prozess.

2. Mich brauchst du nicht über Stapelverarbeitungsdateien belehren.

3. Der Algorithmus bezieht sich nicht auf die gesamte Datei. cPlay ist eine echtzeit Applikation und rechnet fortlaufend..
Wir sprechen auch gar nicht von cMP. Du scheinst nicht zu verstehen das cMP eine Shell ist.

4. Verstehe ich nicht !

5. Bit identisch zu was ? Sorry, auch hier weisst du nicht was ASIO ist, oder wie das DSP eines Softwareplayers mit dem Audiogerät funktioniert. ASIO ist IMMER Bit-Identisch. Geht gar nicht anders, denn in einem ASIO Protokoll ist die Software ein integraler Teil des DSPs.

-und warum muss Unix eingebracht werden ....??

Geehrtes Forum,

Ich möchte keinen zu nahe treten, aber nun hat dies mittlerweile nichts mit einer konstruktiven Diskussion über Upsampling mit Secret Rabbit Code zu tun.
Ich beteilige mich nicht in diesem Thread in einer Absicht rechthaberisch irgendetwas zu umwerben, aber lediglich dazu beizutragen eine spannende Diskussion mit zu gestalten : Fragen aufzubringen; Antworten zu geben (wenn ich kann) und Zusammenhänge zu verstehen.

Die Vorurteile die hier ab und zu eingebracht werden, sind aus der Perspektive und dem Verständnis eines Bürocomputers relevant, aber überhaupt nicht angemessen in moderner Audiosoftware oder in ASIO Soundkarten.
Es dient eben nicht dem allgemeinem Verständnis und es beflügelt keine Aufklärung, wenn hier Fragen, Behauptungen & Kontroversen mit Unterstellungen gewürzt werden, nur weil jemand nicht ganz verstanden hat worüber die Diskussion läuft.
Ich bin sicher dass einige die hier mitlesen, schon ein berechtigtes Interesse daran haben schlauer zu werden.

Leif

[Kienberg]

Hallo Leif,

Ob der Algorithmus sich auf den Batch (Stapel, Ladung, Menge oder Partie) oder nur auf einen ausgewählten Teil der Datei z.B. 30.000 Samples bezieht, hat sehr wohl Einfluss auf das Resultat. Das Upsampling ist ein laufender Prozess.

nochmals, bei jeder Batch-Verarbeitung kann das zugehörige Programm selbstverständlich auch beliebige Teile der Daten anfassen und bearbeiten, einen nach dem anderen, auch Zwischenergebnisse bilden etc. Solange der Benutzer nicht interaktiv eingreift und Parameter oder Algorithmus verändert, was ja beim Abspielen von Musikinhalten mit den von Dir benutzten Programmen wohl nicht der Fall ist, kann kein Unterschied im Ergebnis entstehen.

Nachdem Du aber die einfachsten Grundlagen der Informatik nicht wahr haben willst...was weiter nicht schlimm ist, gibt es doch zahlreiche Menschen, die auch die Relativitätstheorie oder die Quantenmechanik für falsch halten, obwohl sie deren Ergbnisse jeden Tag benutzen.... klinke ich mich aus weiteren Diskussionen mit Dir aus.

Gruss
Sigi

[Schorsch]

Ich verstehe euren Zweifel, aber der Kernpunkt des on- versus offline Upsamplens liegt nicht in dem Upsampling aber in dem Algorithmus.
...
Ich habe immer noch das Gefühl dass ihr nicht ganz versteht was ein Algorithmus wirklich ist....

Hallo Leif,
Schade, dass die Diskussion etwas an Emotionslosigkeit verliert.

Du bist sehr von der Qualität des SRC überzeugt. Niemand sagt, dass der Algorithmus schlecht ist! Aber der Algorithmus wurde von schlauen Leuten implementiert und sollte daher auch von denselben erklärbar sein. Die Erklärungen, warum er so gut funktioniert, sind teilweise für mich nicht rational nachvollziehbar. Daher - vielleicht habe ich etwas übersehen - wo genau finde ich den Algorithmus des verwendeten Upsamplings beim SRC beschrieben?

...
Nun, was zeigt sich bei der Filterlänge (alle Filter linearphasig): ...
...

Hallo Uli,
prima, dass Du die Impulsantworten der Filter berechnet hast. Gerade das Acourate ist (natürlich auf Grund seiner Filterlänge) beeindruckend. Es wäre interessant, die Phasen zu sehen. Könntest du mal die zugehörigen linearen Phasen zeigen?

Ansonsten ist alles schlichtweg reine Mathematik, nichts Mystisches.

So ist es!

Viele Grüße
Georg

[Schorsch]

Hallo,

eine Anmerkung möchte ich noch machen, um das cplay-Bild und das Bild von Uli (s.u.) nicht versehentlich falsch zu interpretieren.

Ein zeitdiskretes (digitales) Signal existiert nur an den Abtastzeitpunkten, zwischen zwei Abtastzeitpunkten ist es nicht definiert.

Upsampling berechnet neue Zwischenwerte, die möglichst so aussehen, als ob das Originalsignal mit dieser höheren Frequenz abgetastet wurde. Natürlich liefert ein 16-fach Upsampling auf 768 kHz mehr Zwischenwerte als ein Upsampling auf 96 kHz.

Damit ergibt sich ein neuer Zwischenwert genau mittig zwischen zwei originalen Abtastpunkten. Damit man die besser sieht, habe ich diese mit einer Treppenfunktion verbunden.

Uli hat die neu interpolierten Zwischenwerte nur zur übersichtlicheren Darstellung zu einer Treppenfunktion verbunden. Die 16-fach upgesampelte Kurve hat daher eine feinere "Treppenstruktur" als die 96 kHz Kurve.

Man könnte daraus schließen, dass die gröbere Treppenkurve schlechter sei, weil die Stufen weniger fein sind. Ist sie aber nicht! Solange die interpolierten neuen Abtastwerte auf der idealen Kurve, also dem "Analogsignalverlauf" liegen, funktioniert der Algorithmus perfekt. Die Eckpunkte der blauen und der grünen Kurve liegen beide auf dem "Analogsignalverlauf". Die Zwischenräume sind nicht definiert.

Die (fiktive) Treppe verschwindet später durch das Antialiasing Filter (Glättungsfilter) bei der Wiedergabe.

Eine durch Upsampling erhöhte Signalfrequenz verringert die Probleme bei der Realsierung dieses Antialiasing Filters.

Viele Grüße
Georg

[uli.brueggemann]

Es wäre interessant, die Phasen zu sehen. Könntest du mal die zugehörigen linearen Phasen zeigen?

Georg,
bitte glaub mir, die Gruppenlaufzeit ist bei allen Filtern ein glatter horizontaler Strich, also konstant, auch bei hoher Auflösung der GLZ-Darstellung. Nur im Sperrbereich wir es evtl. minimalst zappelig, was aber mit der numerischen Auflösung zusammenhängt.
Ich spar mir also den Aufwand, es sei denn Du glaubst es nicht

Die (fiktive) Treppe verschwindet später durch das Antialiasing Filter (Glättungsfilter) bei der Wiedergabe.

Eine durch Upsampling erhöhte Signalfrequenz verringert die Probleme bei der Realsierung dieses Antialiasing Filters.

Yep, das ist der einzige Grund. Die Eckfrequenz des Glättungsfilters wandert schlichtweg in einen höheren Bereich.

Grüsse, Uli

[Schorsch]

bitte glaub mir, die Gruppenlaufzeit ist bei allen Filtern ein glatter horizontaler Strich, also konstant, auch bei hoher Auflösung der GLZ-Darstellung. Nur im Sperrbereich wir es evtl. minimalst zappelig, was aber mit der numerischen Auflösung zusammenhängt.
Ich spar mir also den Aufwand, es sei denn Du glaubst es nicht

Hallo Uli,
natürlich glaube ich Dir das!
Ich freue mich auf den Workshop.

Viele Grüße
Georg

[play-mate]

Hallo geehrte Mitstreiter,

Vielen Dank für die Diskussion. Immer toll mit euch ein paar Kontroversen auszutauschen....

Gruß Leif

[Ralf Koschnicke]

Hallo zusammen,
interessantes Thema ... vielleicht kann ich auch noch etwas zur Verwirrung beitragen :
Moderne DA-Wandler arbeiten in der Regel ebenso wie AD-Wandler auch als Multibit Delta-Sigma-Chips. Das Spitzenmodell von Cirrus Logic (einem der wichtigsten Hersteller) arbeitet intern, unabhängig von der Eingangsabtastrate, mit über 6MHz (die ADs sogar mit über 12MHz).

Ich weiß nun nicht präzise, wie im Detail gearbeitet wird. Der Vorteil beim Analogfilter dürfte jedoch in jedem Fall entfallen. Die Filter sind Digital und der Delta-Sigma-Bitstream braucht dann keinen aufwendigen Analogfilter mehr.

Ich will dennoch gar nicht unbedingt bestreiten, dass Upsampling einen Vorteil bringen kann. Vermutlich hängt das Ergebnis aber ganz stark von der Qualität des DA-Chips und seines eingebauten „Upsamplings“ ab. Denn upsampled wird intern immer, und um einen viel höheren Faktor als wir es extern – ob im PC oder mittels spezieller Schaltungen im DAC – machen können.

Weitaus größere Erfahrungswerte habe ich zugegeben mit Downsampling und hier gibt es so viele Prozesse, die so unglaublich viel kaputt machen. Deshalb habe ich gefühlsmäßig eher Vorbehalte, zu viel im Signal „herumzurechnen“. Ich habe auch Grund zur Annahme, dass zum Teil in falsche Richtungen optimiert wird, ohne genau zu verstehen, was für Musik am wichtigsten ist.
Wie ein roter Faden durch alle Experimente mit Resamplern zieht sich die Beobachtung, dass Resampler mit einstellbarer Qualität bei „hoher Qualität“ meist eher die schlechteren Ergebnisse liefern. Ich habe den Verdacht, dass dann nicht nur viele Stützstellen verwendet werden, sondern auch sehr steilflankige Filter, um wenig Aliasing bzw. sehr gute SNR-Werte zu bekommen. Das stärkere Preringing macht dann aber wohl viel mehr kaputt als moderates Aliasing. Experimente mit dem SOX im Cplay haben den Verdacht erhärtet. Hier kann man sehr schön die einzelnen Parameter justieren und im Gegensatz zu fertigen Lösungen weiß man was man tut und hört. Spielt man ein wenig damit, scheint mir eher ein "gesunder", moderater Mittelweg bei der Filtersteilheit angeraten. Der SRC gefällt mir in der "schlechteren" Variante auch besser.

Viele Grüße
Ralf

[play-mate]

Hallo Ralf,

Die meisten erachten Upsampling als ein Mittel zur Verringerung von Jitter, denn so haben uns die Hersteller den Begriff oft vermarktet, und es ist in vielen Fällen auch so.
Meine frühere These ist aber immer noch, dass ein Upsampling das neue Interpolationswerte in das Signal schreibt, durchaus besser ist als wenn einfach die Samplingrate erhöht wird.

Cics Zitat zum SoX und Aliasing :

SoX implementation in cPlay enjoys full optimisation as that for SRC (Secret Rabbit Code). This includes 128bit DSP processing and other optimisations. Only VHQ (Very High Quality, 175db rejection aka Stop Band) and HQ (High Quality, 125db rejection) converters are supported. SRC at 145db SNR (154db rejection) and 121db SNR (120db rejection) remains as before. SoX VHQ offers better than 170db SNR performance (see measurements below). Other SoX resampler options available in cPlay are (as per SoX Manual):
Phase (0-100)
All resamplers use filters that can sometimes create `echo' (a.k.a. `ringing') artefacts with transient signals such as those that occur with `finger snaps' or other highly percussive sounds. Such artefacts are much more noticable to the human ear if they occur before the transient (`pre-echo') than if they occur after it (`post-echo'). Note that frequency of any such artefacts is related to the smaller of the original and new sampling rates but that if this is at least 44.1kHz, then the artefacts will lie outside the range of human hearing.
A phase response setting may be used to control the distribution of any transient echo between `pre' and `post': with minimum phase (0), there is no pre-echo but the longest post-echo; with linear phase (50), pre and post echo are in equal amounts (in signal terms, but not audibility terms); the intermediate phase (25) setting attempts to find the best compromise by selecting a small length (and level) of pre-echo and a medium lengthed post-echo. Note that phase responses between `linear' (50) and `maximum' (50..100) are rarely useful.
Bandwidth (90-99.7%)
Band-width is the percentage of the audio frequency band that is preserved. A resampler's band-width setting determines how much of the frequency content of the original signal (w.r.t. the orignal sample rate when up-sampling, or the new sample rate when down-sampling) is preserved during conversion. The term `pass-band' is used to refer to all frequencies up to the band-width point (e.g. for 44.1kHz sampling rate, and a resampling band-width of 95%, the pass-band represents frequencies from 0Hz (D.C.) to circa 21kHz). Increasing the resampler's band-width results in a slower conversion and can increase transient echo artefacts (and vice versa).
The -s `steep filter' option (99.0% bandwidth) changes resampling band-width from the default 95% (based on the 3dB point), to 99%. Band-width values greater than 99% are not recommended for normal use as they can cause excessive transient echo.
(Above Bandwidth) Aliasing
Aliasing above the pass-band is allowed. For example, with 44.1kHz sampling rate, and a resampling band-width of 95%, this means that frequency content above 21kHz can be distorted; however, since this is above the pass-band (i.e. above the highest frequency of interest/audibility), this may not be a problem. The benefits of allowing aliasing are reduced processing time, and reduced (by almost half) transient echo artefacts.

- der Sox Resampler ist eigentlich in cPlay eingebaut um genau um die hörbaren Effekte von verschiedenen Einstellungen selber zu probieren. Hinzu kommt das SoX den Prozessor deutlich weniger belastet als SRC. Ob nun der Geräuschabstand -145dB oder gar -170dB ist wohl eher ein wenig theoretisch.
Wenn aber der cPlay´er schon läuft, ist das umschalten zwischen SoX, SRC oder kein Upsampling doch deutlich zu hören. Der SoX ist im Vergleich zum SRC immer analytischer, sportlicher und knackiger; wobei der Charakter von SRC sich immer flüssiger, musikalischer und natürlicher anhört.

Es ist klar dass du als bedachter Tontechniker jede Manipulation eines Signals ganz gezielt vermeidest, aber für die heimische Wiedergabe von den schon relativ "reduzierten" 16/44.1 Daten ist es doch einen Versuch wert, ein SRC Upsampling zu testen.
Es gibt viele Hörberichte die technische Messungen nur schwer belegen können.
Keiner würde einen Tonabnehmer oder einen Lautsprecher nur über die technischen Daten bewerten, oder ?

Gruß Leif