DSP - Best Practice bei Formatumwandlung und Faltung?

Musikwiedergabe über PC und Mac

Beitragvon Daihedz » 17.01.2018, 00:08

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
Bild
Daihedz
inaktiv
 
Beiträge: 549
Registriert: 25.06.2010, 15:09

Beitragvon Daihedz » 17.01.2018, 08:52

Erratum:
Daihedz hat geschrieben:Brutefir-Config - Brutefir sollte was zu fressen kriegen:
Filter 44.1/32kB - 88.2/64kB - 176.4/128kB

Sollte natürlich heissen
Filter 44.1/256kB - 88.2/512kB - 176.4/1024kB

Korrektive Grüsse
Simon
Bild
Daihedz
inaktiv
 
Beiträge: 549
Registriert: 25.06.2010, 15:09

Beitragvon Buschel » 17.01.2018, 18:51

Hi Simon,

da hast du dir viel Mühe gegeben. Ich hätte nicht damit gerechnet, dass bei float32 und auch float64 schon "so früh" hörbare Einschränkungen auftreten. Wäre interessant zu wissen, an welchem Arbeitsschritt das liegt. Wird evtl. zu viel Dither eingefügt, der durch die Verstärkung zu stark auffällt?

Daihedz hat geschrieben: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 ein konsequentes Ergebnis aus deiner Messung und den Hörtests.

Aber noch eine Anmerkung: Wenn du SRC anwendest, solltest du das Signal generell vorher etwas abschwächen (2-3 dB), da es zu intersample overs kommen kann. Ohne Absenkung führen intersample overs zu Clipping und damit zu Verzerrungen sobald du wieder in den Integer-Zahlenbereich wechselst.

Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 605
Registriert: 12.12.2013, 21:12
Wohnort: Raum Karlsruhe

Beitragvon Daihedz » 17.01.2018, 21:38

Hallo Andree

Buschel hat geschrieben: ... Ich hätte nicht damit gerechnet, dass bei float32 und auch float64 schon "so früh" hörbare Einschränkungen auftreten. Wäre interessant zu wissen, an welchem Arbeitsschritt das liegt. Wird evtl. zu viel Dither eingefügt, der durch die Verstärkung zu stark auffällt? ...

Für den Test habe ich die ersten paar Takte von SilvertownBlues im Format 16/44.1 (d.h. mit einem rechnerisch möglichen Dynamikumfang von ca. 90dB) eingelesen, welche mit Spitzen von ca. -10dB ... -6dB aufgenommen sind. Damit ergibt sich, dass der Dynamikbereich der Verarbeitung innerhalb der Pipe für die 32Bit-Variante bei -80dB ... -160dB lag, bei der 64Bit-Variante -120dB ... -200dB. Dies für die perfekte Abhöre bei initialen -70dB, resp. -110dB Absenkung. Oder mache ich da vielleicht einen Denkfehler?

Zum Dither: Sox erlaubt das Ausschalten eines ggf. Default-Dithers mittels des Parameters -D. Der war bei meinen Versuchen nicht gesetzt, sodass sox vielleicht tatsächlich, so wie Du hinterfragst, defaultmässig gedithert hat, ohne dass ich es mitgekriegt hätte. Ich werde nochmals eine Versuchsreihe mit -D durchrechnen und dann berichten.

Buschel hat geschrieben: ... Wenn du SRC anwendest, solltest du das Signal generell vorher etwas abschwächen (2-3 dB), da es zu intersample overs kommen kann. Ohne Absenkung führen intersample overs zu Clipping und damit zu Verzerrungen sobald du wieder in den Integer-Zahlenbereich wechselst. ...

Das war im Testsetup durch die massive Absenkung des Pegels Eingangs der Pipe sicherlich gegeben, resp. erfüllt. Eine produktive Pipe mit moderatem ISC-Schutz würde denn z.B.entsprechend so aussehen:

-> sox/stdin Formatumwandlung (16 integer -> 64 float) ->
-> sox vol (-2dB ... -3dB)
-> sox rate (44.1/48/96 -> 96) ->
-> brutefir (96kHz) ->
-> sox Formatrückwandlung (64 float -> 32/24/16 integer - ggf. mit Dithering) - stdout ->

Sockenstramme Grüsse
Simon
Bild
Daihedz
inaktiv
 
Beiträge: 549
Registriert: 25.06.2010, 15:09

Beitragvon Buschel » 17.01.2018, 22:21

Hallo Simon,
Daihedz hat geschrieben:-> sox/stdin Formatumwandlung (16 integer -> 64 float) ->
-> sox vol (-2dB ... -3dB)
-> sox rate (44.1/48/96 -> 96) ->
-> brutefir (96kHz) ->
-> sox Formatrückwandlung (64 float -> 32/24/16 integer - ggf. mit Dithering) - stdout ->

Ja, genauso würde ich das auch umsetzen, wenn mein Setup nicht gewisse Eigenheiten (*) hätte. ;)

*(Bei meinem Setup läuft immer ein nicht deaktivierbarer ASRC-Baustein mit. Der ASRC in Kombination mit dem DAC hat die sinnvollste Kombination bei 44k1 > 96k, weshalb brutefir immer mit 44k1 läuft und so den USB bedient. Der DAC-Chip selbst läuft dann mit 96k.)

Daihedz hat geschrieben:Ich werde nochmals eine Versuchsreihe mit -D durchrechnen und dann berichten.

Gute Idee. Das Dithering sollte wie oben von dir zitiert nur im letzten Schritt (Wandlung von float zurück zu int) hinzugefügt werden. Bin gespannt was du herausbekommst.

Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 605
Registriert: 12.12.2013, 21:12
Wohnort: Raum Karlsruhe

Beitragvon Tinitus » 17.01.2018, 22:33

Hallo,

finde diesen Thread geradeals Linux Dilettant sehr spannend. Ich nutze mpd mit brutefir pipe out, einmal in der 32 bit Variante mit Archphile auf Odroid C1, das läuft prima und mit Daphile in der 64 bit Variante. Bei Daphile habe ich manchmal Aussetzer, liegt wohl daran, dass der Filter 8192, 32 eben gehörig mehr Rechenleistung fordert als 8192, 16, das upboard aber von der Rechenleistung her nicht proportional besser ist als der Odroid.
Ich upsample alles in mpd (mittels sox) auf 32bit 96 kHz, weil ich dann, wie von Andree beschrieben nur einen Filter benötige und dann geht es zu brutefir, in brutefir senke ich den Pegel um 8 dB ab, dann geht es mit 32/96 in einen meiner DAC. Ich dithere gar nicht. Wobei mein Cronos wahrscheinlich die 8 LSB abschneidet, während mein ADI-2 PRO 32 bit verarbeiten kann. Klanglich gibt es meiner Meinung nach keinen großen Unterschied zwischen Archphile und Daphile, vielleicht kleine Vorteile für Archphile. Schneller und reaktiver ist der Odroid trotz Wifi Verbindung (das upboard ist per LAN im Netz). Ein weiterer Grund fürs upsampling ist für mich, dass verschiedene DA-Filter sich dann weniger im hörbaren Bereich auswirken. Bei 16/44,1 höre ich unterschiede zwischen verschiedenen Filtern, bei 32/96 keine mehr.
Wenn ich es richtig verstehe müsste ich zur Vermeidung von ISC mit mpd vor dem upsampling auf 32/96 den Pegel etwas senken, kennt jemand die dafür passende Synthax für die mpd.conf? Für einen Tipp wäre ich da dankbar.



Grüße

Uwe

PS Auch ich freue mich auf die Ergebnisse des Simonschen Forscherdrangs
Bild
Tinitus
Aktiver Hörer
 
Beiträge: 789
Registriert: 10.11.2013, 22:48

Beitragvon Buschel » 18.01.2018, 08:11

Hallo Uwe,

Tinitus hat geschrieben:... Filter 8192, 32 eben gehörig mehr Rechenleistung fordert als 8192, 16...

Meinst du damit das setting "filter_length" in brutefir? Wenn ja, könntest du noch ein wenig optimieren, falls du mehr Verzögerung zulassen kannst. Du kannst z.B. anstatt "8192, 32" direkt "262144" nutzen. Darüberhinaus is das Filter auch recht lang. Ausgehend von Acourate mit 65536 taps bei 48 kHz, würde ich "nu" 131072 taps bei 96 kHz erwarten.

Tinitus hat geschrieben:Ein weiterer Grund fürs upsampling ist für mich, dass verschiedene DA-Filter sich dann weniger im hörbaren Bereich auswirken. Bei 16/44,1 höre ich unterschiede zwischen verschiedenen Filtern, bei 32/96 keine mehr.

Das ist auch für mich einer der Gründe auf 96 kHz zu wandeln. Die Oversamplingfilter des DAC-Chips fallen dann sanfter ab, und ich vermeide in meinem Setup zwei aufeinanderfolgende (ASRC>DAC) steile Filter. Aber: Vergiss nicht, dass auch dein sox-Filter ein Oversamplingfilter ist und je nach gewähltem Filter entsprechende Auswirkungen hat (pre-ringing, post-ringing, aliasing, ...).

Tinitus hat geschrieben:Wenn ich es richtig verstehe müsste ich zur Vermeidung von ISC mit mpd vor dem upsampling auf 32/96 den Pegel etwas senken, kennt jemand die dafür passende Synthax für die mpd.conf? Für einen Tipp wäre ich da dankbar.

Kannst du die Absenkung nicht direkt in sox machen lassen? Mit demselben Kommando, das zur Abtastratenwandlung benutzt wird?

Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 605
Registriert: 12.12.2013, 21:12
Wohnort: Raum Karlsruhe

Beitragvon dietert » 18.01.2018, 12:46

Hallo miteinander,

Upsampling hat etwas mit Interpolation zu tun. Interpolation zwischen den originalen Audio-Samples findet spätestens beim Übergang in den Analogbereich statt, ist also unvermeidlich. Man kann die Interpolation teilweise digital machen, das nennt sich dann Upsampling, oder vollkommen analog. Ohne digitale Interpolation braucht man ziemlich aufwendige Analogfilter, noch dazu mehrere für unterschiedliche Samplingraten. Eine teilweise digitale Lösung mit Upsampling macht weniger Arbeit und funktioniert am Ende präziser, besonders wenn man vorher die Wortbreite vergrößert, also z.B. 16 => 24 Bit. Sonst werden die interpolierten Samples gerundet und die Erhöhung der Wortbreite hinterher bringt die Genauigkeit nicht wieder.

Entscheidend bei der digitalen Interpolation ist der erste Faktor zwei. Er vergrößert den Abstand zwischen der Nyquistfrequenz und der Nutzbandbreite, darum geht es.
Sampling      Nyquist           Abtastreserve
44,1 KHz => 22,05 KHz  => - 20 KHz = 2,05 KHz
48 KHz   => 24 KHz     => - 20 KHz = 4 KHz
88,2 KHz => 44,1 KHz   => - 20 KHz = 24,1 KHz
96 KHz   => 48 KHz     => - 20 KHz = 28 KHz

Die Reserve ist bei 48 KHz ("Professionell") doppelt so groß!

Bei 88,2 bzw. 96 KHz bekommt man eine so große Reserve, dass danach eigentlich nichts besonderes mehr passiert, egal ob der DAC noch weiter digital interpoliert oder nur mit Analogfiltern arbeitet. "192 KHz" oder "384 KHz" sind praktisch reines Marketing. Von der Mathematik her hat es auch keinen Vorteil von 44,1 auf 88,2 KHz zu gehen und nicht auf 96 KHz. Der Einfachheit halber kann man alles bei 96 KHz machen, möglichst auch Raummessung und Faltung.

Grüße,
Dieter T.
Bild
dietert
inaktiv
 
Beiträge: 527
Registriert: 24.11.2013, 11:31
Wohnort: 76571 Gaggenau

Beitragvon Daihedz » 18.01.2018, 15:47

Tinitus hat geschrieben: ... Wenn ich es richtig verstehe müsste ich zur Vermeidung von ISC mit mpd vor dem upsampling auf 32/96 den Pegel etwas senken, kennt jemand die dafür passende Synthax für die mpd.conf? ...

Die innerhalb einer mpd-config deklarierte Pipe ist von der Syntax her genau gleich wie in eine nackte bash-pipe (ich spreche von linux). Du kannst Deine gewünschte Pipe gleich nach dem command-parameter in der mpd.config folgendermassen deklarieren:

...
audio_output {
type "pipe"
name "soxbfir"
command "sox ... | sox ... - ... - vol -2.5dB | sox ...| brutefir ... | sox ..."
...
# auto-channels "no"
# auto-format "no"
# auto-resample "no"
}

In der ersten Sox-Instanz wird (16Bit integer -> 64Bit float) gerechnet
In der zweiten Sox-Instanz wird um 2.5dB abgesenkt
In der dritten Sox-Instanz erfolgt das Upsampling

Die auto-... Parameter stellen sicher, dass das gesamte DSP innerhalb der Pipe stattfindet und somit unter den von Dir parametrisierbaren Bedingungen.

dietert hat geschrieben: ... Entscheidend bei der digitalen Interpolation ist der erste Faktor zwei. Er vergrößert den Abstand zwischen der Nyquistfrequenz und der Nutzbandbreite, darum geht es...

Heisst das in der Konsequenz, dass Du für das Upsampling sowas empfehlen würdest:

-> sox (16 int -> 64 float) ->
-> sox (vol -2dB...-3dB ) ->
-> sox (44.1 -> 88.2/176.4) ->
-> sox (88.2/176.4 -> 96) ->
-> brutefir ->
...

Denn sox rechnet fast gratis. Dann weshalb nicht zuerst eine geradzahlige Konversion (x2 oder x4) und dann eine zweite, schräge Konversion nach weiter oben oder dann wieder zurück? Letztlich auch in derselben Variante, wenn am Ausgang 48kHz gewünscht wären:

-> sox (16 int -> 64 float) ->
-> sox (vol -2dB...-3dB ) ->
-> sox (44.1 -> 88.2/176.4) ->
-> sox (88.2/176.4 -> 48 ) ->
...

???

Ohrensausende und wohlgeditherte (gedieterte?) Grüsse
Simon
Bild
Daihedz
inaktiv
 
Beiträge: 549
Registriert: 25.06.2010, 15:09

Beitragvon Daihedz » 18.01.2018, 17:10

Ojeh ...

Ich merke gerade, dass ich den Beitrag von Dieter völlig falsch verstanden habe. Deshalb bitte meine entsprechende Antwort zu Dieters Beitrag:

-->>> DELETE <<<---

Tippex-Grüsse
Simon
Bild
Daihedz
inaktiv
 
Beiträge: 549
Registriert: 25.06.2010, 15:09

Beitragvon dietert » 18.01.2018, 18:30

Hallo Simon,

in deiner Notation würde man vielleicht schreiben:

-> sox (16 int -> 64 float) ->
-> sox (vol -2dB...-3dB ) ->
-> sox (44.1 -> 96) ->
-> brutefir ->
-> DAC

Soweit ich mich erinnere, kann sox die ersten drei Schritte in einem Durchgang, und die Ergebnisse sind absolut brauchbar.
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. Man findet aber im Web auch open source Projekte, die das Interpolationsfilter im Zeitbereich rechnen, für einen modernen Rechner z.B. RaspBerry Pi kein Problem. Beispiel: ZITA-Resampler bei

http://kokkinizita.linuxaudio.org/linuxaudio/

Grüße,
Dieter T.
Bild
dietert
inaktiv
 
Beiträge: 527
Registriert: 24.11.2013, 11:31
Wohnort: 76571 Gaggenau

Beitragvon Tinitus » 18.01.2018, 22:50

Hallo,

Danke für Eure Kommentare.

@Andree

ich gehe bei der Erstellung des Filters so vor: log sweep mit REW, erstellen der Impulsantwort, exporiert zu DRC und DRC erstellt die Filter. Da ich in REW den zeitlich längst möglichen Filter gewählt habe, ergibt sich daraus eine Impulsantwort, die 1 MB groß ist, daraus macht DRC 512 kB große Mono Filterdateien (96 kHz 32 bit). Daraus ergibt sich für 32 bit brutefir die filter_length von 8192, 16. Ich gehe davon aus, dass Daphile, welches 64 bit brutefir verwendet dieses Filter auf 8192, 32 "aufbohrt". Darauf kann ich in Daphile auch keinen Einfluss nehmen.

Meine mpd.conf sieht so aus (Ausschnitt):

audio_output {
type     "pipe"
name    "brutefir pipe"
command "usr/bin/brutefir -nodefault /opt/brutefir_config 2>/dev/null"
format "96000:32:2"


Wenn ich nun mit sox um 2 dB zwecks Vermeidung von ISC abschwächen will, dann auf 96/32 upsampeln möchte, um anschließend in brutefir die Korrekturfilter rechnen zu lassen, würde das funktionieren:

audio_output {
type     "pipe"
name    "brutefir pipe"
command "sox gain -2 | sox input.wav -r 96000 -b 32 output.wav| usr/bin/brutefir -nodefault /opt/brutefir_config 2>/dev/null"

?
Vor allem beim zweiten sox Befehl bin ich mir unsicher, was ich will ist ja die eingehende .wav Datei egal mit welcher Samplefrequenz und mit welcher Bittiefe sie ankommt in eine wave Datei 96/32 umrechnen. Wenn ich mir es recht überlege sollte das eigentlich unabhängig vom Datreiformat der eingehenden Datei funktionieren. input.wav und output.wav meinen doch eigenlich spezifische Dateien. Ginge

audio_output {
type     "pipe"
name    "brutefir pipe"
command "sox gain -2 | sox STDIN -r 96000 -b 32 STDOUT| usr/bin/brutefir -nodefault /opt/brutefir_config 2>/dev/null"


aber woher weiß sox dann, dass die Datei die nach STDOUT ausgegeben werden soll im .wav Format ausgegeben werden soll?

Oder wäre:

audio_output {
type     "pipe"
name    "brutefir pipe"
command "sox gain -2 | sox infile.ulaw -r 96000 -b 32 outfile.wav| usr/bin/brutefir -nodefault /opt/brutefir_config 2>/dev/null"


korrekt?


Gruß

Uwe
Bild
Tinitus
Aktiver Hörer
 
Beiträge: 789
Registriert: 10.11.2013, 22:48

Beitragvon Buschel » 19.01.2018, 07:40

Hallo Uwe,

Tinitus hat geschrieben:... daraus macht DRC 512 kB große Mono Filterdateien (96 kHz 32 bit). Daraus ergibt sich für 32 bit brutefir die filter_length von 8192, 16. Ich gehe davon aus, dass Daphile, welches 64 bit brutefir verwendet dieses Filter auf 8192, 32 "aufbohrt".

Dann gibt DRC also Filter mit 128k taps pro Kanal aus (doppelt so lang wie Acourate). Beim Rechnen mit 64 bit Fließkomma bleibt das Filter bestehen (also in deiner Notation 8192, 16), die interne Rechengenauigkeit und damit Rechenlast ist aber höher. Unterstützt die benutzte Hardware denn auch 64 bit float, oder läuft das über Software-Emulation (was ja ziemlich langsam wäre)?

Zu den von dir erwähnten Aussetzern:
- Wird ein low latency Kernel benutzt? Das hat bei mir die Anfälligkeit zu Aussetzern in Situationen mit hoher Last deutlich reduziert.
- Kannst du die brutefir-Konfiguration von 8192,16 auf 16384,8 / 32768,4 / 65536,2 oder sogar 131072 ändern? Das verringert auch nochmal die Belastung, erhöht aber die Laufzeitverzögerung.

Grüße,
Andree
Bild
Buschel
Aktiver Hörer
 
Beiträge: 605
Registriert: 12.12.2013, 21:12
Wohnort: Raum Karlsruhe

Beitragvon Daihedz » 21.01.2018, 22:03

Hallo in die DSP-Runde
Ich habe zwischenzeitlich mit sox -> brutefir -> sox herumgespielt und habe einige Erfahrungen gemacht.

Allgemein:
1. Dithern mittels Sox hat praktisch keinerlei Einfluss. In keiner Variante, auch nicht. Wenn überhaupt was an einem Ende gewonnen wird, dann wird am anderen Ende verloren ...
2. Wenn möglich soll mit/bei einer Bittiefe von 64Bit verarbeitet werden.
3. Der Samplerate-Converter von SOX arbeitet mit max. 24Bit. Das ist eine Limite für die Genauigkeit. Bei jedem Up- resp. Downsampling gehen in etwa 10dB Dynamikreserve verloren. Deshalb lohnt es sich nicht, fürs Convolving höher zu Upsamplen, als am Schluss nötig ist. Das erfordert lediglich wieder eine zusätzliche Rückrechnung, welche die Dynamikreserve zusätzlich noch etwas einschränkt.
4. Für das Convolving mittels Brutefir soll das Upsampling zuvor, und nicht erst nach Brutefir erfolgen.
5. Bei einer 16Bit/44.1kHz Eingangsdatei macht es praktisch keinen Unterschied, ob zu 16/44 oder 24/96 hin gerechnet wird. Möglicherweise gewinnt man mit 24/96 das, was beim Upsampling verloren geht ...

Im Speziellen:
Eine 16Bit/44.1kHz *.wav wurde mit cptoshm und shmcat eingelesen und mit einer ersten Instanz von Sox nach 32Bit float oder 64 float konvertiert. Danach wurde mit einer zweiten Instanz von Sox der Pegel 0dB (blau), -80dB (braun), -100dB (grün) und -120dB (rot) heruntergerechnet. Im Falle von 24/96 out wurde danach und an dieser Stelle das Upsampling von 44.1kHz nach 96kHz vorgenommen (sox - rate -v -I). Danach erfolgte mittels Brutefir eine Faltung mit einem bei -15dB abgeschnittenen C-Weighting-Filter, danach die Aufteilung auf eine 5-Weg-NT2-Weiche, die 5 Ausgänge der Weichenfilter wurden wieder zusammengefasst und zuletzt mit einem Filter verrechnet, welcher dem Inversen des C-Weighting-Eingangsfilter entsprach. Per stdout wurde die Pipe weiter an Sox gegeben, wo in einer ersten Stufe der Pegel wieder auf -1dB hochgerechnet wurde (incl +14dB für die Absenkung durch das C-Weighting-Filter und dessen Inverse). Am Schluss erfolgte, nochmals mittels sox, die Rückwandlung von 32Bit/64Bit float nach 16Bit oder 24Bit integer.

Bild

Bild
Input als 16Bit/44.1kHz-wav, mittels Acourate synthetisiert. Die beiden kleinen Störspitzen bei ca. 8kHz und 13kHz sind Artefakte und zeigen sich teilweise in den unteren Graphen wieder.


Resultate:

Bild
1644-3244-1644 (32Bit Pegelmanipulationen und Convolving)
Eingangspegel 0dB (blau), -80dB (braun), -100dB (grün - fett), -120dB (rot)
Mit Dither und/oder ohne Dither praktisch identisch (kein Bild mit Dither hier eingestellt, ist aber so)
DR > 70dB (DR von 40dB bei einer Störung @ ca. 18kHz) für Signale > -100dB Absenkung (grüner Teppich)
DR > 80dB für Signale > -80dB


Bild
1644-6444-1644 (64Bit Pegelmanipulationen und Convolving)
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


Bild
1644-6496-2496 (64Bit Pegelmanipulationen, Upsampling 44.1kHz -> 96.kHz und Convolving, Ausgabe als 24Bit/96kHz-wav)
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


Bild
Bild
2496-6496-2496
Eingangspegel 0dB (blau), -80dB (braun), -100dB (grün - fett), -120dB (rot)
Die untere Kurvenschar habe ich mehrmals gefenstert, damit die Unterschiede sichtbar wurden. Die obere Graphik zeigt den "Originalzustand" nach dem unmittelbaren Einlesen der Ausgangsdateien.

Mein Fazit daraus:
sox-brutefir-sox ist ganz ok, könnte aber besser sein - (Setup-, Berechnungs- und Interpretationsirrtum vorbehalten). Kennt jemand ein wirklich gutes Linux-Progrämmchen, welches in einer Pipe das Upsampling mit 64Bit-Tiefe und parametrisierbarer Präzision erledigen kann?

Partialerhellt-buntkurvige Grüsse
Simon
Bild
Daihedz
inaktiv
 
Beiträge: 549
Registriert: 25.06.2010, 15:09

Beitragvon Tinitus » 21.01.2018, 23:56

Hallo Andree,

angeregt durch deinen Beitrag habe ich ein wenig herumexperimentiert. Ich habe nun eine beta Version von Daphile installiert, die zulässt, dass man ihr mit ssh auf den Zahn fühlen kann, dies ist bei den offiziellen Versionen nicht möglich. Außerdem habe ich zum ersten mal die real time Kernel Version installiert, ich vermute, die kommt dem was Du low latency nennst am nähesten.
Außerdem habe ich den streaming buffer und den output buffer mal auf 17408 kB eingestellt und die buffer time auf 400 ms. Allerdings hatte ich solche Werte in der Vergangenheit auch schon beim normalen Kernel ohne großen Erfolg bezüglich Aussetzer verwendet.
Bis jetzt habe ich keine Aussetzer gehabt. Ich vermute es liegt am rt Kernel, denn auch die Bedienung über die GUI ist deutlich fixer geworden. Suche ich in der Quobuz App nach etwas flutscht das nur so. Die Taktfrequenz des im upboard verbauten Atom x5 Z8350 (echte 64 bit) habe ich auf 1,2 GHz eingestellt. Die reguläre Taktfrequenz liegt bei 1,44 Ghz. Der Prozessor erlaubt auch übertakten bis 1,92 GHz, das lässt Daphile aber nicht zu. Die Temperatur des upboards liegt jetzt dauerhaft unter 50 °C, bei 1,44 GHz werden manchmal auch 53 °C erreicht, mehr als 60 °C mag der Prozessor nicht.
Jetzt aber zum eigentlichen Thema des Fadens. In Daphile kann ich einstellen, dass vor dem Upsampling auf 32/96 der Pegel um 2 dB abgesenkt wird, das sollte ISC vermeiden. Außerdem muss ich bei manchem Musikmaterial brutefir darum bitten den Pegel um satte 8 dB abzusenken, sonst zeigt mir Daphile clipping an. Dachte gar nicht, dass mein Korrekturfilter solche Löcher zu stopfen hat, dass er den Pegel so anhebt. Oder sollte ich die in REW aufgezeichnete Impulsantwort nicht normalisieren bevor DRC Designer die Filter berechnet?
Jetzt mach Daphile ja eigentlich genau das, was ich möchte:

- sox übernimmt das Oversampling auf 32/96 und senkt den Pegel dabei zur Vermeidung von ISC um 2 dB ab - brutefir wendet das Korrekturfilter an und gibt die Daten im Format 32/96 an den DAC aus

Wenn ich Simons Beitrag richtig verstanden habe, rechnet sox beim Upsampling in 24 bit, das ist nicht tragisch, da mein Musikmaterial eh in 16 bzw. 24 bit vorliegt. Danach geht es mit 32 bit zu brutefir, das rechnet in 64 bit, gibt aber wieder 32/96 aus. Gedithert wird gar nicht.

Mein Armature Cronos der einen XMos XU208 USB Receiverchip verbaut hat ist trotzdem mit 24 bit/384 kHz spezifiziert ist schneidet die 8 LSB wohl ab, hört sich aber nicht grausam an.

Mein RME ADI-2 PRO ist, obwohl er, wenn ich es richtig weiß, auch einen XMos chip verbaut hat allerdings den Vörgänger des XU208, mit 32 bit/384 kHz spezifiziert, demenstrechend wird da wohl nichts abgeschnitten.

In diesem Zusammenhang hätte ich eine Frage an Simon, warum gehst Du mit 24 bit in den DAC? Warum nicht mit 32 bit? Dann könnte das Dithering doch guten Gewissens entfallen und Du hättest noch mehr Headroom oder? Irgendwo habe ich mal gelesen, dass bei 32 bit das Johnson noise genannte Phänomen schon das Dithering besorgt.

Simons Beitrag muss ich noch mal in Ruhe durchgehen, zu so später Stunde blicke ich da nicht mehr durch. Vorab aber schon mal Danke dafür, dass Du uns an den Resultaten deines Forscherdrangs teil haben lässt.

Späte Grüsse

Uwe

PS Andree Daphile macht aus meinen .wav Filterdateien mit 512 kB automatisch filter_length 8192, 32 da kann ich nichts einstellen, jetzt läufts aber prima
Bild
Tinitus
Aktiver Hörer
 
Beiträge: 789
Registriert: 10.11.2013, 22:48

VorherigeNächste

Zurück zu Computer-HiFi

Wer ist online?

Mitglieder in diesem Forum: 0 Mitglieder und 5 Gäste