DSP - Best Practice bei Formatumwandlung und Faltung?

[Tinitus]

Hallo,

kleine Ergänzung:

höre gerade AC/DC High Voltage (die Jungs haben echt gute Pub-Musik gemacht), das sagt top:

Die CPU (4 Kerne) ist zwischen 85 und 89 % faul (idle)

Prozesse

irq so um die 13 % cpu Last
brutefir 2x je ca. 10 % cpu Last
sox ca. 6 %
andere Prozesse ca. 5 %

In Summe ca. 44 % durch 4 Kerne gibt 11 %, das stimmt mit dem oben genannten überein

load average ist < 0,7 und meist zwischen 0,5 und 0,6, das heißt im Schnitt befindet sich weniger als ein Prozess in der Warteschleife

Bassst scho

Gruß

Uwe

[Tinitus]

Hallo Simon,

wirklich interessant. Nach deinen Ergebnissen mache ich also nichts verkehrt, auch wenn das übertragen der Daten mit 32/96 mir vom DR im Vergleich zu 24/44,1 nichts bringt, so macht das meinen Hörgenuss immer noch unabhängig von den im DAC verwendeten Filtern, deshalb lasse ich das so. Daphile mit rt Kernel hat damit ja auch kein Problem. Warum mir dann Archphile mit 32 bit brutefir klanglich eher etwas besser gefällt als Daphile (64 bit) liegt vielleicht nur daran, dass ichin Archphile die pipe und brutefir selbst einrichten musste (oder sollte ich durfte sagen, war zwar für mich viel Arbeit, hat aber Spaß gemacht - per aspera ad astra), während Daphile nur Knöppcher drügge ist, wie man in Hessen sagt. Die Vorarbeit mit Archphile hat aber geholfen, besser zu verstehen, welches Knöppche fur was guut ist.
Archphile gibt es auch für den Odroid C2 (64 bit), aber ich glaube den vierten Minirechner schaffe ich mir nicht noch an.

Wenn Dithering anscheinend nichts bringt, könnte man mit noise shaping noch was rausholen? Wobei ich nicht weiß, ob sox das kann.

Gruß

Uwe

[wgh52]

Hallo Uwe,

hier könnte ein Mißverständnis vorliegen: Der DR (Dinamic Range) Wert bezieht sich normalerweise auf den Dynamikbereich der Aufnahme selbst. Dieser wird aber durch Up-, Over- oder Resampling ja nicht verändert und solche Veränderung der Aufnahme wollen wir ja im Sinne von Dynamikexpansion auch eigentlich nicht (ergo: gleicher DR Wert).

Grüße,
Winfried

4381

[Tinitus]

Hallo Winfried,

ich habe die gleiche Nomenklatur wie Simon verwenden wollen:

Eingangspegel 0dB (blau), -80dB (braun), -100dB (grün - fett), -120dB (rot)
Mit Dither und/oder ohne Dither praktisch identisch.
DR >90dB für Signale > -100dB
DR >100dB für Signale > -80dB

Im Englisch sprachigem Raum wird die Abkürzung DR soweit ich weiß für Dynamic Range unabhängig davon gebraucht, ob es sich um Soft- oder Hardware handelt, z. B.:

https://www.denafrips.com/specs-ares

Frag mich aber jetzt nicht, was der Unterschied zwichen S/N Ratio und Dynamic Range ist

Gruß nach Bayern

Uwe

[Tinitus]

Hallo,

für die, die es interessiert undnoch nicht wissen:

https://www.prosoundweb.com/channels/av ... ise_ratio/

Dynamic Range sollte demnach grundsätzlich höher sein als Signal to Noise Ratio.

Gruß

Uwe

[wgh52]

OK,

das Mißverständnis war meinerseits. Der hier gemeinte Dynamikbereich oder Dynamic Range reicht vom Grundrauschen bis zur Begrenzung und gilt für S/W wie H/W; der "DR Wert" von Musikaufnahmen ist natürlich etwas anderes .

Grüße,
Winfried

4382

[Daihedz]

Hallo Uwe und Mitinteressenten

... Wenn Dithering anscheinend nichts bringt, könnte man mit noise shaping noch was rausholen? Wobei ich nicht weiß, ob sox das kann ...

Kannes. Rausholen kann man aber nichts dabei: Ich habe es in einer Testreihe ohne brutefir mittels [sox ... dither -f high-shibata] für die Ausgabe in eine 1644-Datei probiert. Als Resultat liegt der Rauschteppich im unteren F-Bereich geschätzte 2-3dB tiefer, dafür gibt es einen wüsten Rauschbuckel sämtlicher Kurven im Bereich 15kHz ... 20kHz, welcher über die vergleichsweise ungeditherten Rauschteppich der -120dB zu liegen kommt. Eine Verschlimmbesserung also, welche für junge Hörer ganz sicher nichts taugt. Dieselbe Übung dann bei der Ausgabe in ein 24/96-Format: Keinerlei Unterschiede zwischen nativ, dither und dither mit noise-shaping.

Zuletzt noch*: Zur Frage, warum 24/96 als Ausgabeformat? Aus der ConfoFS-Diskussion heraus ist das entstanden, wo wav-Dateien zur Verfügung gestellt werden. Für meine Bedürfnisse wandle ich je nach DAC sowohl nach 24/96, als auch nach 32/96. Ich habe DAC-Oldies; der eine frisst das, was der andere nicht verträgt, und umgekehrt.

Zuletzt noch*: Weshalb hältst Du an einer Verarbeitungs-Bittiefe von 32 fest? 16 -> 64 -> 24/32 ist wesentlich sauberer als 16 -> 32 -> 24/32. Wenn Deine CPU alle 64-Bit-Berechnungen stemmen, warum denn auf das Bestmögliche verzichten wollen? Wohl nicht aufgrund ökologischer Bedenken?

Zuletzt noch*: Ich habe DR in einer Analogie verwendet und als Kürzel für "Drunne Rauscht's". Etwas ernster: Einfach die Differenz abgelesen zwischen den Nutzsignalspitzen und dem eher "gefühlten" Pegel des Rauschteppichs - und ohnehin in Acourate bis auf eine Ausnahme (24/96 -> 24/96) ungefenstert. Vielleicht ist das ein methodischer Fehler.

Zuletzt noch*: Ich habe nicht überprüft, wie gut und wie schlecht sox in einem Rutsch gleich alles rechnet. Das ist für mich nicht relevant, da ich lieber mehrere sox-instanzen hintereinanderschalte und so die volle Kontrolle über den sequenziellen Ablauf der Berechnungen habe. Ich bin gerne bereit, mich im Falle von teschnischen Argumenten eines besseren belehren zu lassen.

Zuletzt noch* ein ceteo censeo. Aus meiner kleinen Versuchsreihe geht für mich hervor, dass in Zukunft meine Pipes dergestalt aussehen, immer mit sox -D (..kein Dither):

[Einlesen der Audio-wav 1644 in die Pipe] \
|sox -b 16 -D -e signed-integer -r 44100 -t raw -V 1 - blah.. 6444 float - \
| sox blah ... 6444 float - blah ... 6444 float - rate -V -i 96000 \
| brutefir ..blah 6496 float \
| sox blah ... 6496 float - blah... 3296 signed-integer - \
| [Ausgabe des bearbeiteten Audio-Materials durch ein beliebiges Programm ]

Zuletzt noch* ... die Grüsse!
Simon

* Ist für die Vinyl-Fans mit/bei Kritz in der Platte, damit diese allenfalls auch was von der Diskussion haben.

[Tinitus]

Hallo Simon,

sox betreibt also noise shaping für ältere Herren

Drunne rauschts gefällt mir als Definition von DR.

Ich habe auch einen Gedankenfehler gemacht als ich den jetzigen Ablauf in Daphile beschrieb. Ich gebe Daphile nur vor, auf 96 kHz up zu samplen (das scheint mir weder deutsch noch Hessisch zu sein). In der brutefir_config steht dann 96000 als Samplefrequenz und 64 bit float als Bittiefe. Ich gehe davon aus, dass gleich auf 64 bit hochgerechnet wird. Nur bei meiner Archphile Installation auf dem Odroid wird auf 32 bit hochgerechnet, der läuft ja auch mit 32 bit brutefir.
Daphile gibt übrigends auf Wunsch genügend Informationen aus, so dass man sich über die Programmabläufe im Klaren sein kann.
Tja aufgrund deiner Messungen, kann es eigentlich nur einen Schluss geben, besser mit 64 bit arbeiten und ja es könnte sich lohnen, ein Programm zu finden, welches besser arbeitet als sox. Ich regle die Lautstärke allerdings nicht digitsal, obwohl das mit dem ADI-2 PRO problemlos ginge. Das Ding kann ja vier verschiedene Ausgangpegel, so dass über einen sehr weiten Bereich verlustfrei die LS gestellt werden kann.

Gruß

Uwe

PS: Ich glaube ich habe jetzt einen weiteren Grund dafür gefunden, warum die rt Version von Daphile zackiger ist, sie verwendet statt 8192, 32 wie bei der "normalen" Version "nur" 16384, 8

PPS Ums Vinyl kann ich mich jetzt auch kümmern, mit dem ADI kann ich alle meine LP digitalisieren

[frankl]

Hallo DSP-Praktiker,

Simons Bemerkung

3. Der Samplerate-Converter von SOX arbeitet mit max. 24Bit. Das ist eine Limite für die Genauigkeit.

hat mich herausgefordert, mir das mal genauer anzusehen. Soweit ich sehe, ist dies nicht richtig. Aber es ist tatsächlich so, dass 'sox' ungenauer rechnet, als ich vorher gedacht hatte.

Wie man der Dokumentation von 'libsox' (oder dem Source-Code von 'sox') entnehmen kann, wandelt 'sox' jede Eingabe in 32-Bit signed integer Samples um, und alle Effekte in 'sox' rechnen mit diesen 32-Bit Ganzzahlen.
Das führt dazu, dass in diesem Beispiel mit einer 44.1/16 Datei 'data.flac'

sox data.flac -t raw -e float -b 64 - | \
  sox -t raw -e float -b 64 -c 2 -r 44100 - -t raw - vol -192dB | \
  sox -t raw -e float -b 64 -c 2 -r 192000 - -t raw - vol 190dB | \
  sox -t raw -e float -b 64 -c 2 -r 192000 - -t wav -e signed -b 32 guck.wav


die Datei 'guck.wav' nur Nullsamples enthält. Wenn immer mit 64-Bit gerechnet würde, dürfte hier keine Information verloren gehen und am Ende das Original ohne Verlust nur 2 dB leiser sein.

Da 'sox' aber intern mit 32-Bit Ganzzahlen rechnet, sind in der Ausgabe des zweiten 'sox' Aufrufes nur noch Nullsamples und alles ist verloren.

Nun ja, für die Lautstärkeänderung habe ich Abhilfe. Mein 'volrace' Programm rechnet wirklich mit 64-Bit floating point. (Bei anwenden von 'volrace -v 0.000000000001 | volrace -v 1000000000000 -m 2000000000000' geht nichts von der Originaldatei verloren.) Kommen wir also zum Resamplen. Im folgenden Beispiel

sox data.flac -t raw -e float -b 64 - | \
  volrace -v 0.000000001 | \
  sox -t raw -e float -b 64 -c 2 -r 44100 - -t raw - rate -v -I 192000 | \
  volrace -v 1000000000 -m 2000000000 | \
  sox -t raw -e float -b 64 -c 2 -r 192000 - -t wav -e signed -b 32 guck.wav


wird die Lautstärke um etwa 30 Bit abgesenkt, dann mit 'sox' auf 192000 resampled, und schließlich wieder verstärkt. In 'guck.wav' kommen zum Schluss nur 5 verschiedene Samplewerte vor (zum Beispiel mit 'audacity' anschauen), was zeigt, dass hier mit 32 Bit Genauigkeit gerechnet wird.

Kennt jemand ein wirklich gutes Linux-Progrämmchen, welches in einer Pipe das Upsampling mit 64Bit-Tiefe und parametrisierbarer Präzision erledigen kann?

Die beschriebene Limitierung liegt an der Programmierung der Ein- und Ausgabe von 'sox'/'libsox'. Der zugrunde liegende Code zum Resamplen kann auch mit höherer Genauigkeit rechnen. Dieser Code ist als separate Library 'libsoxr' verfügbar. Ich habe jetzt mal ein eigenes Programm 'resample_soxr' geschrieben, das diese Library benutzt und als Filter mit 64-Bit floating point Samples in der Ein- und Ausgabe arbeitet. Damit kann ich folgendes machen:

sox data.flac -t raw -e float -b 64 - | \
  volrace -v 0.000000000001 | \
  resample_soxr --inrate 44100 --outrate 192000 | \
  volrace -v 1000000000000 -m 2000000000000 | \
  sox -t raw -e float -b 64 -c 2 -r 192000 - -t wav -e signed -b 32 guck.wav


Und siehe da, die Datei 'guck.wav' ist nun eine vernüftige 192000/32 Version der Originaldatei. Ohne die enorme Lautstärkeabsenkung und -anhebung wird alles mit echten 64 Bit gerechnet, bis zum Schluss auf 32 Bit abgeschnitten wird.

Wer es ausprobieren möchte, kann den Code für 'resample_soxr' in meinem Software-Repository finden und das Programm kompilieren.

Ich habe das natürlich in meinem Abspielskript gleich statt 'sox' zum Resamplen eingebaut. Das bringt bei mir tatsächlich eine kleine hörbare Verbesserung. Allerdings denke ich nicht, dass das an der höheren Bitgenauigkeit beim Resamplen liegt, sondern an der "audiophileren" Ein- und Ausgabebehandlung in meinem Programm (das auch etwa 15% weniger CPU-Zeit benötigt als der entsprechende 'sox' Aufruf).

Viele Grüße,
Frank

PS.:

Was mich bei sox irgendwann genervt hat: Es basiert auf hoch optimierten FFT-Bibliotheken, zu denen ich keine Quellen und keine richtige Dokumentation finden konnte.

Der FFT-Code, der beim Upsamplen benutzt wird, ist im Code von libsoxr enthalten.

[frankl]

Hallo Uwe und Mitinteressenten

... Wenn Dithering anscheinend nichts bringt, könnte man mit noise shaping noch was rausholen? Wobei ich nicht weiß, ob sox das kann ...

Kannes. Rausholen kann man aber nichts dabei: Ich habe es in einer Testreihe ohne brutefir mittels [sox ... dither -f high-shibata] für die Ausgabe in eine 1644-Datei probiert. Als Resultat liegt der Rauschteppich im unteren F-Bereich geschätzte 2-3dB tiefer, dafür gibt es einen wüsten Rauschbuckel sämtlicher Kurven im Bereich 15kHz ... 20kHz, welcher über die vergleichsweise ungeditherten Rauschteppich der -120dB zu liegen kommt. Eine Verschlimmbesserung also, welche für junge Hörer ganz sicher nichts taugt.

Hallo Simon und Uwe,

"Noiseshaping" gibt es nur zusammen mit "Dithering", das sind nicht zwei unabhängige Operationen. Der Sinn beim Noiseshaping ist, das hinzugefügte Rauschen im Frequenzbereich ungleichmäßig zu verteilen. Und da ist es in der Tat sehr nützlich, den Rauschanteil in dem Bereich zu verringern, in dem sich das Musiksignal hauptsächlich abspielt. Wir reden hier übrigens über kaum bewußt als solches heraushörbares Rauschen in den unteren Bits.

Ich würde das Noiseshaping ganz und gar nicht als "Verschlimmbesserung" bezeichnen. Ich verweise da nochmal auf meinen alten Beitrag, in dem auch Beispielaufrufe mit 'sox' stehen, die die Effekte gut hörbar demonstrieren.

Viele Grüße,
Frank

[SolidCore]

Hallo zusammen

Ich wollte mal von einer Eigenart berichten, deren Erklärung mir fehlt, es aber dennoch wichtig ist.
Ich hatte ein paar High-Res Files in 96khz/24bit und 192khz/24bit downgesampled zum CD-format.
Natürlich bleibt dabei etwas Klangqualität auf der Strecke. Mir kamen die Files im CD-Format aber etwas "zu schlecht" vor.
also nahm ich einfach mal SoX, Isotope Ozone und Weiss Saracon für diesen Zweck. Und war erstaunt, das die gewandelten Files alle unterschiedlich klangen.
Also versuchte ich in den Programmen, mal andere Settings für das Dither auszuwählen. Und siehe da, die heruntergerechneten Files klangen deutlich besser.
Z.B klang die Dither Einstellung TPDF (Voreingestellt) nicht so dolle, die Einstellung POWr1 wirklich hörbar bedeutend besser. Weiterführend, besonders fürs Upsampling, habe ich keine Versuche gemacht. Kann mir aber gut vorstellen, das auch dort Unterschiede zu hören sind. Je nachdem, welches Programm man verwendet, und welche Pre-setting.

Gruss
Stephan

[Buschel]

Hallo zusammen,

Eine Verschlimmbesserung also, welche für junge Hörer ganz sicher nichts taugt.

Schau die mal den Verlauf der Ruhehörschwelle an. Du wirst sehen, dass ein Rauschen im Frequenzbereich 15-20 kHz etwa 20-60 dB mehr Pegel haben darf als im empfindlichen Bereich um 3 kHz, um denselben Lautstärkeeindruck zu erhalten. Wenn das Rauschen von empfindlichen Bereichen in unempfindliche verschoben wird, ist das immer ein Gewinn -- auch für junge Hörer. Sony hat das in den 90er Jahren z.B. unter dem Namen SuperBitMapping (SBM) zum Mastern von CDs mit höherer wahrnehmbarer Dynamik benutzt.
Technisch interessant wird es übrigens erst, wenn die Rauschformung nicht statisch erfolgt (d.h. immer mit derselben spektralen Form, üblicherweise an die Ruhehörschwelle angelehnt), sondern adaptiv (z.B. an die Maskierungsschwelle angepasst) erfolgt.

Da 'sox' aber intern mit 32-Bit Ganzzahlen rechnet, sind in der Ausgabe des zweiten 'sox' Aufrufes nur noch Nullsamples und alles ist verloren.
[...]
Wer es ausprobieren möchte, kann den Code für 'resample_soxr' in meinem Software-Repository finden und das Programm kompilieren.

Oha. Mit dieser Einschränkung bei sox habe ich nicht gerechnet. Das erklärt natürlich sofort die Messungen von Simon. Falls ich jemals auf den SRC-Zug aufspringen sollte, werde ich mich deiner Umsetzung bedienen. Die Implementierung sollte die bestmögliche Auflösung liefern. Vielen Dank dafür.

Grüße,
Andree

[Daihedz]

Hallo in die Runde der DSPler

Ich habe mit Sox, und Frank's brandneuem resample_soxr sowie seinem bereits gut etablierten volrace etwas "agility" gemacht. Dazu habe ich im Sinne eines Stresstests eine Hindernispipe geskriptet, die es in der realen Audio-Welt sinnvollerweise sicherlich so nicht geben sollte:

Einlesen der Datei (16/44.1, resp. 24/96) (cptoshm/shmcat)->
Umwandeln nach 64Bit float (sox) ->
Pegel -6dB (sox/volrace) ->
Pegel -80db resp. -140dB (sox/volrace) ->
Samplerate 44.1kHz resp. 96kHz nach 192kHz (sox/resample_soxr) ->
Samplerate 192kHz nach 88.2kHz (sox/resample_soxr) ->
Samplerate 88.2kHz nach 44.1 kHz (sox/resample_soxr) ->
Pegel +80dB resp. +140dB (sox/volrace) ->
Samplerate 44.1kHz nach 192kHz (sox/resample_soxr) ->
Samplerate 192kHz nach 88.2kHz (sox/resample_soxr) ->
Samplerate 88.2kHz nach 44.1kHz resp. 96kHz (sox/resample_soxr) ->
Pegel +5.99dB (sox/volrace) ->
Umwandeln nach 16Bit resp. 32Bit signed integer, im Fall von 16Bit mit oder ohne Dither (sox) ->
Ausgabe in Datei (16/44 oder 32/96) (sox mit derselben Instanz wie im letzten Schritt)

Soweit der (absurde?) Hindernislauf, einmal sequentiell alles mittels sox (im Falle von up-/downsampling mit den Parametern -v -I), ein andermal alles mit den Programmen von Frank durchzuspielen.

Resultate:

1644 -> 1644 mittels sox:

Kurven 1-4: Kein Dither im letzten Bearbeitungsschritt (64Bit -> 16Bit)
Kurven 5/6 (gr/sw) Dither und Noise Shaping im letzten Bearbeitungsschritt (64Bit -> 16Bit)

1644 -> 1644 mittels volrace/resample_soxr:

Kurven 1-4: Kein Dither im letzten Bearbeitungsschritt (64Bit -> 16Bit)
Kurven 5/6 (gr/sw) Dither und Noise Shaping im letzten Bearbeitungsschritt (64Bit -> 16Bit)

2496 -> 3296 mittels sox:


2496 -> 3296 mittels volrace/resample_soxr:


Die resultierenden wav's wurden in Acourate eingelesen
Kurven 1/2 (rot/gn), 3/4 (br/bl) und 5/6 (gr/sw) stellen jeweils beide Kanäle (L/R) derselben Verarbeitung dar. Die Kanäle L (Kurven 1, 3 und 5) sind direkt dargestellt, die Kanäle R (Kurven 2, 4 und 6) wurden nachträglich zur Darstellung mittels einer Kaiser (240dB) - Funktion gefenstert.

Fazit:
Die Programme von Frank schöpfen die Möglichkeiten der DSP voll aus. Super. Das ist eine Premiere in der Linux-Audiowelt, dass auf derart einfache Art und Weise theoretisch bestmögliches Digitalaudio zur Verfügung gestellt wird.

Begeisterte, anerkennende und 64-bittig-frankldankende Grüsse
Simon

[Daihedz]

Ein nachträgliches Hallo in die DSP-Runde

... Das bringt bei mir tatsächlich eine kleine hörbare Verbesserung. Allerdings denke ich nicht, dass das an der höheren Bitgenauigkeit beim Resamplen liegt ...

Ich habe nun das Ganze nochmals getestet, diesmal mit einer Real-World pipe (d.h. ohne multiples Resampling-Slalom bei unterschiedlicher Abschwächung) und etwas realistischeren Werten für die Abschwächung im Falle von sox. Dies, vor allem um nun auch noch die Qualität von Brutefir bei durchgängigen 64Bit zu testen. Diesmal arbeitete also Brutefir bei unterschiedlichen Abschwächungen. Vorneweg: Brutefir hat bestanden, sox in der Real-Word-Pipe ebenso

Die Pipe:

Einlesen der Datei (16/44.1, resp. 24/96) (cptoshm/shmcat)->
Umwandeln 16Bit/24Bit integer nach 64Bit float (sox) ->
Pegel -6dB (sox/volrace) ->
Samplerate 44.1kHz/96kHz nach 192kHz (sox -a -v -I /resample_soxr) ->
Pegel -40dB/-60db/-80dB/-100dB (sox) resp. -200dB (volrace) ->
Faltung (Brutefir 2ch mit einem Dirac-Filter MinPhase- und LinPhase auf je einem Kanal)
Pegel +40dB/+60db/+80dB/+100dB (sox) resp. +200dB (volrace) ->
Samplerate 192kHz nach 96kHz (sox -a -v- I /resample_soxr) ->
Pegel +5.99dB (sox/volrace) ->
Umwandeln 64Bit float nach 32Bit integer, ohne Dither (sox)
Ausgabe in Datei mit 32/96-Format (sox mit derselben Instanz wie im letzten Schritt)

Resultate:

Eingang 1644, Ausgang 3296:

Kurve 6 (sw) stellt ist die Referenz dar (mit resample_soxr und Volrace, Brutefir rechnet mit/bei -200dB).
Kurven 1-4 stellen das Wanldungsresultat von sox dar, mit/bei -100dB (rt), -80dB (gn), -60dB (br), -40dB (bl)

Eingang 2496, Ausgang 3296:

Kurve 6 (sw) stellt ist die Referenz dar (mit resample_soxr und Volrace, Brutefir rechnet mit/bei -200dB).
Kurven 1-4 stellen das Wanldungsresultat von sox dar, mit/bei -100dB (rt), -80dB (gn), -60dB (br), -40dB (bl)

Fazit:

1. Aus den Kurven geht hervor, dass die Aussage von frankl nachvollziehbar ist. Die mit sox zur Verfügung stehende Bittiefe, resp. Dynamikreserve dürfte in einer "normalen" Pipe genügen.
2. Brutefir scheint tatsächlich mit durchgängigen 64-Bit und ohne Artefakte in der Real-World-Pipe zu rechnen.

Pipophile Grüsse
Simon

[Tinitus]

Hallo Simon,

ich hatte schon vermutet, dass so zwar nicht "state of the art" fürs Upsamplen ist (das hat Frank ja endgültig bewiesen) aber eben doch gut genug für Alltags relevante Fälle.
Trotzdem dank an Alle, die hier forschend tätig waren. Als Linu Laie, bin ich zwar nicht in der Lage Franks Lösung umzusetzen, aber die Diskussion trägt doch zum Verständnis bei. Ich werde weiterhin das vorkonfigurierte Daphile verwenden, da ich in der digitalen Domäne höchstens 12 dB Abschwäche, sehe ich für meinen hausgebrauch, die Tatsache, dass sox beim Upsamplen mit 24 bit arbeitet nicht als tragisch an, dennoch ist es gut, die Schwächen des Systems zu kennen (und zu wissen, wie es beser geht).

Gruß

Uwe