DSP - Best Practice bei Formatumwandlung und Faltung?

[Daihedz]

Hallo in die Runde der Digitalisten

Ich habe einige Fragen in Sachen DSP, welche zunächst prinzipiell-theoretisch gemeint sind, und sekundär aber auch in der praktischen Anwendung z.B. mit sox und brutefir.

1. Frage zum Upsampling

Es sei von 16Bit/44.1kHz nach 24Bit/96kHz umzuwandeln.
Macht eine zweistufige Wandlung theoretisch Sinn, und falls ja, dann in welcher Reihenfolge?

Direkt:
-> [ 16Bit/44.1kHz -> 24Bit/96kHz ] ->

Variante zweistufig, zuerst die Bittiefe, dann die Samplerate:
-> [ 16Bit/44.1kHz -> 24Bit/44.1kHz ] -> [ 24Bit/44.1kHz -> 24Bit/96kHz ] ->

Variante zweistufig, zuerst die Samplerate, dann die Bittiefe:
-> [ 16Bit/44.1kHz -> 16Bit/96kHz ] -> [ 16Bit/96kHz -> 24Bit/96kHz ] ->


2. Frage zum Downsampling

Es sei von 32Bit/192kHz nach 24Bit/96kHz umzuwandeln
Macht eine zweistufige Wandlung theoretisch Sinn, und falls ja, dann in welcher Reihenfolge?

Direkt:
-> [ 32Bit/192kHz -> 24Bit/96kHz ] ->

Variante zweistufig, zuerst die Bittiefe, dann die Samplerate:
-> [ 32Bit/192kHz -> 24Bit/192kHz ] -> [ 24Bit/192kHz -> 24Bit/96kHz ] ->

Variante zweistufig, zuerst die Samplerate, dann die Bittiefe:
-> [ 32Bit/192kHz -> 32Bit/96kHz ]-> [ 32Bit/96kHz -> 24Bit/96kHz ] ->


3. Fragen zur Auslegung einer Pipe mit Convolution

Es sei von 16Bit/44.1kHz nach 24Bit/96kHz umzuwandeln und eine Convolution vorzunehmen.
Macht es theoretisch Sinn, für die Convolution das Format über das Ausgangs-Target hinaus hochzurechnen, und danach rückzuwandeln?

Direkt:
-> [ 16Bit/44.1kHz -> 24Bit/96kHz | Convolution 24Bit/96kHz | 24Bit/96kHz/float -> integer] ->

Variante mit (in diesem Beispiel illustrativ extremem) "Target-Overshoot-Upsampling" vor der Convolution und nachfolgendem Downsampling zum Ausgangs-Target hin:
-> [ 16Bit/44.1kHz -> 64Bit/384kHz | Convolution 64Bit/384kHz | 64Bit/384kHz -> 24Bit/96kHz ] ->

Vielleicht handelt es sich bei der Variante um eine Verschlimmbesserung im dem Sinne, als dass die Rückwandlung der Bittiefe und/oder der Samplerate nach der Convolution mehr Fehler rechnen könnte, als bei der Convolution an Präzision gewonnen wird? Vielleicht könnte es aber auch sinnvoll sein, bloss selektiv die Bittiefe, oder selektiv die Samplerate fürs Convolving als "Target-Overhoot" hochzurechnen?

Handörgelnde (=expandierend-faltend-stauchende) Grüsse
Simon

[wgh52]

Hallo Simon,

ich bin nicht der Fachmensch, aber die "best practice" von der ich (glaube sogar hier im Forum) gelesen habe ist zweistufig, aber anders als Du vorschlägst um gebrochene Teilerverhältnisse zu vermeiden:
1. Man arbeitet mit dem kleinsten gemeinsamen Vielfachen von Ziel- und Quellsamplingfrequenz als Interimsauflösung
2. Hochrechnen der Quelldaten auf das kleinste gemeinsame Vielfache mit größtmöglicher Bitbreite (da gibt's wohl unterschiedliche Algorithmen mit Interpolation und was nicht alles...)
3. Herunterrechnen der Ergebnisdaten beim gemeinsamen Vielfachen auf die Zielsamplingfrequenz und -Auflösung mit größtmöglicher Bitbreite (da gibt's wohl unterschiedliche Algorithmen)
4. Runden dar Zielsamplingfrequenzdaten auf die Zielbitbreite und gegebenenfalls Dither hinzufügen

Ralf Koschnicke und Uli Brüggemann fallen mir hier sofort als Experten im Forum ein.

just my 2 cents worth...

Grüße,
Winfried

4369

[chriss0212]

Wenn Du über einen PC Zuspielen möchtest kann ich Dir den HQ Player ans Herz legen.

Hier kannst Du zwischen allen möglichen umkonvertierungen sowie etlichen Filtern wählen!

https://www.signalyst.com/consumer.html

Grüße

Christian

[Buschel]

Hallo Simon,

Macht eine zweistufige Wandlung theoretisch Sinn, und falls ja, dann in welcher Reihenfolge?

Bei einer reinen Abtastratenwandlung macht es Sinn, die fixed integer Darstellung in Fliesskomma zu übertragen, dann die Samplerate anzupassen (im Ergebnis immer noch Fliesskomma), und abschließend dieses Fliesskommeergebnis mit Dithering auf Zielauflösung (z.B. 24 Bit) zu bringen. Nach meinem Verständnis kann sox diese drei Schritte (Integer>Fliesskomma, Sampleratekonvertierung, Fliesskomma>Integer) so umsetzen.

Fragen zur Auslegung einer Pipe mit Convolution

Bei einer solchen sequenziellen Bearbeitung würde ich darauf achten, dass eine Umwandlung in die gewünschte Zielauflösung (z.B. 24 Bit) erst ganz am Ende und mit Dithering erfolgt. Alle Arbeitsschritte dazwischen würde ich in Fliesskomma rechnen lassen. Für deinen Fall bedeutet das: sox nimmt die Eingangsdaten wie sie sind und gibt mit Fließkomma und Zielabtastrate aus, dann wendet brutefir das Filter an gibt wieder mit Fliesskomma aus, abschließend wandelt sox mit Dither in Zielauflösung (Integer).
Beispiel: 16b44k1 > sox: double176k4 > brutefir: double176k4 > sox: 24b176k4

Macht es theoretisch Sinn, für die Convolution das Format über das Ausgangs-Target hinaus hochzurechnen, und danach rückzuwandeln?

Davon rate ich aus praktischen Gründen ab. Um bei einer höheren Abtastrate dieselbe Frequenzauflösung des Korrekturfilters zu erhalten wie bei einer niedrigeren, muss das Filter entsprechend länger gewählt werden (doppelte Abtastrate = doppelte Filterlänge bei gleicher Frequenzauflösung). D.h. entweder verbrätst du unnötig Rechenzeit oder du verlierst Frequenzauflösung (doppelte Abtastrate = halbe Frequenzauflösung bei gleicher Filterlänge). Ich würde deswegen direkt auf die Zielrate wandeln und darauf die Faltung anwenden.

Grüße,
Andree

[frankl]

Hallo Simon,

ich schließe mich ganz den Anmerkungen von Andree an.

Wie ich schon dieser Tage im parallelen ConvoFS Thread angemerkt habe, würde ich immer zuerst den Input in floating-point samples verwandeln (ich nehme 64 Bit, 32 Bit sind oft sicher auch ok, einfach ausprobieren).
Dann wird die ganze Kette der Bearbeitungen, also resampling, Convolving, Lautstärkeregelung, MS-Kodierung, LoCo, Race, ..., in diesem festen floating-point Format durchlaufen. Erst ganz zum Schluss wird wieder in das für den DAC benötigte Integer-Format gewandelt (bei mir 32 Bit, bei vielen 24 Bit, bei 16 Bit unbedingt mit Dithering und Noiseshaping).

In diesem alten Thread hatte ich mal begründet, warum ich die 64-Bit float Umrechung zuerst in einem separaten 'sox' Aufruf mache.

Zum Convolven die Samplerate größer zu machen, als am Ende gewünscht, macht meiner Meinung nach keinen Sinn; insbesondere muss man dann die Filter zum Falten um den gleichen Faktor länger machen für die gleiche Auflösung.

Vor Resampling um "krumme" Faktoren habe ich überhaupt keine Angst, wenn das mit einem guten Algorithmus gemacht wird (zum Beispiel ' rate -v -M 192000 ' mit 'sox').

Viele Grüße,
Frank

[Pittiplatsch]

Hallo @all,

das Thema upsampling hat mich auch schon immer interessiert aber bisher waren andere Baustellen immer dringender.
Meine Frage ist in wie weit upsampling hoerbare Vorteile bringt? Ich habe das ganze versucht mit wenig Aufwand zu testen und demzufolge den Komfort von pulse genutzt (da hat sich einiges getan!!! - per default resampled pulse nicht mehr wenn es nicht muss).

Jedenfalls kann man bei pulse recht comfortabel das file:

~/.pulse/daemon.conf

resample-method = soxr-vhq
default-sample-format = s32le
default-sample-rate = 96000

danach:

killall pulseaudio
pulseaudio -D

und per:

cat /proc/asound/card1/pcm0p/sub0/hw_params

checken ob es geklappt hat. Siehe da: rate: 96000 (96000/1).

Nun meine Frage was ich hoeren sollte? Ich hab mehrfach umgeschaltet aber keinen Unterschied wahrgenommen... Einen Vorteil koennte ich eventuell verstehen wenn ich die Faltung nach das upsampling ziehen wuerde (mehr Rechengenauigkeit). Aber im Moment (Faltung vor dem Upsampling) ist fuer ich der gehoerte Unterschied genau null (zumindest nicht so das er mir gravierend auffalend wuerde ...).

Liegt es an meinen Ohren oder am Vorgehen?

Danke und Viele Gruesse,
Tobias

[Buschel]

Hi Tobias,

es gibt einige Gründe für ein Upsampling auf eine feste Frequenz. Zunächst mal die Usability:

Es ist kein komplexeres Setup mit mehreren FIR-Filtern für Faltung notwendig. Es kann immer dasselbe Filter, das auf die Zielsamplingfrequenz erstellt wurde, benutzt werden.

Der DAC muss im Betrieb nicht zwischen verschiedenen Samplingfrequenzen schalten. Dadurch entfallen ggf. Schaltgeräusche oder Verzögerungen. Als Vergleich: Bei meinem Sat-Receiver lasse ich auch immer auf 1080p skalieren, weil das Zappen damit schneller geht. Der TV muss nicht wieder aufsynchroniseren.

Dann aus Sicht der potentiell besseren Ansteuerung des DACs:

Ein Software-SRC wie sox ist flexibler und kann stärker nach eigenen Wünschen (pre-ringing, Filtersteilheit, Phasentreue, ...) getuned werden. SRC-Bausteine erlauben das nur bedingt.

Ein Software-SRC wie sox sollte eine höhere Rechengenauigkeit erlauben als die marktüblichen SRC-Bausteine (mehr taps, höhere interne Rechengenauigkeit).

Man kann den DAC im sweet spot (falls der DAC so einen hat) der möglichen Samplingfrequenzen ansteuern. Z.B. haben die DAC-Bausteine oft bei einer Samplingfrequenz den geringsten THD oder höchsten SNR. Eventuell haben einige DACs auch nur eine Clock (für die 44,1 kHz oder 48 kHz Familie).

Inwiefern gerade die letzten drei genannten Gründe zu wahrnehmbaren Unterschieden führen, musst du selbst ausprobieren. Ich selbst richte mich nach den praktischen Gesichtspunkten und den aus Datenblättern ermittelten sweet spots.

Grüße,
Andree

[chriss0212]

Hallo Andree

Es ist kein komplexeres Setup mit mehreren FIR-Filtern für Faltung notwendig. Es kann immer dasselbe Filter, das auf die Zielsamplingfrequenz erstellt wurde, benutzt werden.

Ich nutze ja den HQ Player. Da benötige ich, warum auch immer, nur einen Filter, egal mit welcher Frequenz ich rein oder raus gehe.

Ne Idee warum?

Nachteile im Klang könnte ich hier noch keine feststellen.

Grüße

Christian

[h0e]

Hallo Christian,

ich habe Upsampling über Minim gemacht und sample alle 44 Familien auf 176kHz, alle anderen auf 192.
Nicht nur ich habe festgestellt, dass es dadurch besser klingt.
Es stellt sich mehr Ruhe ein.
Allerdings sind das keine Welten mehr und nur noch Tüpfelchen.
Und obwohl der Linn intern ohnehin hochrechnete, klang es extern gerechnet besser.

Grüsse Jürgen

[chriss0212]

Hallo Jürgen

Hab mich evtl. Falsch ausgedrückt

Ich mache das mit dem HQ Player genauso. Was mich nur wundert ist, dass ich zum falten nur eine Filterdatei benötige. Z.B 48kHz. Egal, ob ich auf 176kHz oder 192kHz umrechne. Ich kann gar nicht mehrere Filterdateien angeben.

Ist ja nicht schlimm, denn es funktioniert ja. Es wundert mich nur, das ansonsten alle Tools die ich zum falten kenne, für jede Frequenz eine eigene Filterdatei benötigen.

Grüße

Christian

[Buschel]

Hallo Christian,

Ich nutze ja den HQ Player. Da benötige ich, warum auch immer, nur einen Filter, egal mit welcher Frequenz ich rein oder raus gehe.
Ne Idee warum?

Ich kann das nur vermuten. Fakt ist, dass für jede Faltung mit einer bestimmten Samplingfrequenz auch ein dazu passendes Filter benutzt werden muss. Wenn dein Tool jetzt nur ein Filter für eine einzige Samplingfrequenz benötigt, und dennoch unterschiedliche Ausgabesamplingfrequenzen gewählt werden können, bedeutet das entweder

a) Das Tool wandelt immer in die Samplingfrequenz um, für die das Filter vorliegt, faltet dann, und wandelt am Ende in die gewählte Ausgabesamplingfrequenz um. Das wäre keine gute Lösung.

Oder

b) Das Tool berechnet aus dem einen vorliegenden Filter die fehlenden Filter für alle anderen Frequenzen. Diese werden dann entsprechend angewendet. Das kann durchaus funktionieren, die Qualität hängt dann davon ab, dass die Umrechnung der Filter sauber funktioniert. Wenn ich richtig liege, macht Acourate das auch so.

Grüße,
Andree

[chriss0212]

Hallo Andree

Antwort B könnte in der Tat des Rätsels Lösung sein, denn wie Du vermutes berechnet Acourate ja auch alle Filter aus nur einer Messung...

Hätte ich ja eigentlich auch drauf kommen können

Grüße

Christian

[frankl]

checken ob es geklappt hat. Siehe da: rate: 96000 (96000/1).

Nun meine Frage was ich hoeren sollte? Ich hab mehrfach umgeschaltet aber keinen Unterschied wahrgenommen... Einen Vorteil koennte ich eventuell verstehen wenn ich die Faltung nach das upsampling ziehen wuerde (mehr Rechengenauigkeit). Aber im Moment (Faltung vor dem Upsampling) ist fuer ich der gehoerte Unterschied genau null (zumindest nicht so das er mir gravierend auffalend wuerde ...).

Liegt es an meinen Ohren oder am Vorgehen?

Hallo Tobias,

Gründe für ein Resampling hat Andree ja genannt. Wenn irgendwo in Deiner Kette (eventuell auch im DAC) ein Resampling gemacht wird, dann kann man das auf dem Rechner meist in besserer Qualität machen, und das kann einen Vorteil bringen (weil man das schlechte Resampling umgeht).

Die klanglichen Unterschiede, um die es hier geht, sind nach meiner Erfahrung eher subtil. Leicht hörbar kann unter Umständen ein schlechtes Resampling sein (mit billigem Algorithmus oder billiger Hardware), das gilt es zu vermeiden.

Wenn, wie in Deinem Versuch, ein Resampling hoher Qualität mit 'sox' verwendet wird, und das Abspielen 'pulseaudio' durchläuft (ich schalte das zum Musik spielen immer aus), dann würde ich erwarten, dass es keinen hörbaren Unterschied gibt. Also alles im grünen Bereich.

Viele Grüße,
Frank

[Pittiplatsch]

Danke Frank und Andree,

das deckt sich mit meinen Erwartungen. Meine Musik liegt fast ausschliesslich in 44.1kHz vor also laeuft bei mir alles (inclusive Filterung) auch mit 44.1kHz. Ich war halt neugierig weil es hier ja auch einige Vertreter gibt die Upsampling als klangliche Verbesserung empfinden.

Im Heimkino habe ich jetzt einen aehnlichen Ansatz: alles in 48Khz weil primaer Filme laufen die soweit ich weiss nativ in 48kHz vorliegen.

Viele Gruesse,
Tobias

[Daihedz]

Grüsseuchalle

Danke Euch allen für den zwischenzeitlich eingegangenen, wertvollen Input. Daraus habe ich mir nun ein Testsetup geskriptet und "durchgespielt". Zugegebenermassen nicht verblindet ... Aber die Unterschiede sind an den Schwellwerten deutlich genug.

Interessiet hat mich die Frage, wie gut, resp. wie schlecht unterschiedliche Varianten einer einzelnen Pipe sehr kleine Signalinformationen noch aufzulösen vermag. Ich wollte somit sozusagen die "Feinauflösung" einzelner Varianten testen, und habe (gemäss einer Idee von frankl, notabene) den digitalen Pegel des Signals am Eingang der Pipe, nach der Formatkonvertierung, radikal abgesenkt, um ihn Ausgangs der Pipe um denselben Betrag wieder anzuheben.

Die Varianten der Pipe:
sox file_in und Formatumwandlung (16 integer ->32/64 float) ->
-> sox vol (-0dB ... -170dB)
-> sox rate (44.1 -> 44.1/88.2/176.4) ->
-> brutefir (optional) ->
-> sox rate (44.1/88.2/176.4 -> 44.1/88.1/96) ->
-> sox vol (+15dB im Fall einer optional aktiven Brutefir-Sektion - s.u.) ->
-> sox vol (+0dB ... +170dB - invers zur vorgängig erfolgten Absenkung) ->
-> sox Bit/Format (32/64 float -> 32/16 integer) ->
-> sox file_out

Brutefir-Config - Brutefir sollte was zu fressen kriegen:
Filter 44.1/32kB - 88.2/64kB - 176.4/128kB
MinPhase I: C-weighting-Funktion, nach unten und oben begrenzt @ -15dB
MinPhase II: Inversfilter von MinPhase I. Die Convolution mit MPI ergibt dann linear -15dB Pegel.
Linphase: 5-Weg Xover NT2- 100-310-1000-3100Hz
StdIn -> MP I -> LP 5 Weg parallell -> Summation der 5 Wege -> MP II -> StdOut (@-15dB)

Das gibt einige Variationen und dem Rechner etwas zu rechnen ...

Resultate:

1. Bittiefe in der Pipe. Da trennen sich die Welten !!!

32Bit @ -70dB: Einwandfrei -Kein Unterschied zwischen Originlfile und durchgerechneter Pipe.
32Bit @ -90dB: Deutlicher Rauschteppich bei durchgerechneter Pipe
32Bit @ -110dB: Völlig unbrauchbares Resultet am Ausgang der Pipe

64Bit @ -110dB: Einwandfrei -Kein Unterschied zwischen Originlfile und durchgerechneter Pipe.
64Bit @ -130dB: Deutlicher Rauschteppich bei durchgerechneter Pipe
64Bit @ -150dB: Völlig unbrauchbares Resultet am Ausgang der Pipe

2. Sox - Umrechnungen der Samplerates:

Es macht (für mich) keinen hörbaren Unterschied, ob Zweierpotenzen mutipliziert/dividiert (44.1<->88.2<->176.4) oder nicht (44.1<->88.2<->96<->176.4)

3. Brutefir - Samplerate und Brutefir (ausschliesslich bei 64Bit getestet):

Es macht (für mich) keinen hörbaren Unterschied, ob die Convolution mit Filtern von 44.1kHz, 88.2kHz oder 176.4kHz gerechnet werden.

Für die CPU bedeutet die Verdoppelung der Samplerate eine +- lineare Verdoppelung der notwendigen Rechenzeit.

4. Brutefir - Linearität der Convolution

Theoretisch sollte mein komplexes Filter-Konstrukt am Ausgang ein lieares Resultat zeigen. Was es auch tat. Ich konnte keinerlei Unterschiede zwischen den Varianten mit eingeschleiftem Brutefir, und jenen Varinten ohne Brutefir @ 64Bit/-110dB feststellen. Das ist super so und spricht für die Qualität des Codes von Brutefir !!!

Mein Fazit aus diesen Spielereien:

Ich werde meine Pipes fortan immer (!) auf 64Bit/float hochrechnen und zur weiteren Bearbeitung exakt auf jene Samplerate konvertieren, welche am Ausgang der Pipe den DA-Wandler speisen soll. Nichts mehr, aber auch nichts weniger.

Das ist schon mal eine (praktisch gewonnene) Erkenntnis für mich.

Tüftlergrüsse
Simon