DSP - Best Practice bei Formatumwandlung und Faltung?

Daihedz
Aktiver Hörer
Beiträge: 793
Registriert: 25.06.2010, 15:09

Beitrag von Daihedz »

Ein nachträgliches Hallo in die DSP-Runde
frankl hat geschrieben:... 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:
Bild
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:
Bild
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
Bild
Tinitus
Aktiver Hörer
Beiträge: 1322
Registriert: 10.11.2013, 21:48

Beitrag von 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
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

Hallo DSP-Pipe-Ersteller,

erstmal Dank an Simon für die vielen Bilder.

Nach meinem kürzlichen klanglich recht signifikantem Hardware-Upgrade (siehe hier), und weil ich durch diesen Thread angeregt gerade dabei war, habe ich noch etwas experimentiert. Wenn die Hardware besser wird, ist es bei mir immer so, dass diese auch wieder empfindlicher auf Software-Änderungen reagiert.

Da 'resample_soxr' bei mir auch kleine klangliche Vorteile gegenüber 'sox' zeigte, was ich auf die unterschiedliche Ein- und Ausgabebehandlung schiebe, habe ich über die Integration einiger Schritte der hier besprochenen Pipes nachgedacht. Eigentlich gegen die UNIX Philosophie, kleine Programme für spezifische Aufgaben zu schreiben; aber wenn es dem Klang gut tut, einige Pipes und Puffer zu vermeiden ...

In meinem Programm-Repository findet sich nun ein weiteres Programm 'cat64', das Musikdateien vieler Formate (flac, wav, aiff, ogg, usw.) entweder aus dem Dateisystem oder aus dem shared memory lesen kann und diese als 64-bit floating point Samples ausgibt. Wahlweise kann auch ein (sample-genauer) Ausschnitt der Datei ausgegeben werden. Hiermit kann man also mehrere Aufrufe von 'sox' und anderen Programmen (wie: 'sox datei.flac -t raw - | sox (int to 64 bit float)' oder 'flac datei.flac --skip=.. --until=.. | sox (int to 64-bit float)' ) abgekürzt werden.

Schließlich habe ich in 'resample_soxr' im Eingabeteil auch die Funktionalität von 'cat64' eingebaut und im Ausgabeteil die Funktionalität von 'volrace'. Damit wird meine alte Pipe zum Abspielen:

Code: Alles auswählen

rate=FindeSampleRate(data.flac)
bits=FindeBitTiefe(data.flac)
cptoshm --file=data.flac --shmname=/data.flac
shmcat --shmname=/data.flac | \
     flac --totally-silent --force-raw-format --sign=signed --endian=little  -d -c - | \
     sox -t raw -r  $rate -c 2 -e signed -b  $bits -  \
           -t raw -e floating-point -b 64 - vol 0.9 | \
     sox -t raw -c2 -r $rate -e floating-point -b 64 - \
           -t raw -e floating-point -b 64 - rate -v -I 192000 | \
     volrace --fading-length=100000 --param-file=/tmp/VOLRACE | \
     brutefir /path/to/config -quiet |    usw.
zu

Code: Alles auswählen

cptoshm --file=data.flac --shmname=/data.flac
resample_soxr --buffer-length=3072 --shmname=/data.flac  --outrate=192000 \
                      --fading-length=100000 --param-file=/tmp/VOLRACE  | \
     brutefir /path/to/config -quiet |    usw.
(Lautstärke und RACE Parameter können während des Abspielens in der Datei /tmp/VOLRACE geändert werden.)

Außerdem habe ich 'resample-soxr' noch eine Option '--phase=25' zur Festlegung der Phase des Aliasing-Filters spendiert.

Diese Verschlankung meiner Pipe führt zu einem etwas volleren Klang ohne dass irgendetwas an der Detailauflösung und Räumlichkeit verloren geht.

Viel Spaß beim Spielen und viele Grüße,
Frank
Bild
mm2
Aktiver Hörer
Beiträge: 295
Registriert: 17.05.2010, 22:12
Wohnort: München

Beitrag von mm2 »

Hallo Frank, hallo Experten-Runde,

resampler soxr beschäftigt mich auch gerade sehr.

Ich verwende soxr als resampler mit minimserver

Code: Alles auswählen

convOut=-af aresample=resampler=soxr
auf meinem NAS zum Upsampling, einigen einfachen Filtern und der flac -> wav Wandlung.

Den Parameter "precision" habe ich erhöht, mit hörbaren Verbesserungen.

Code: Alles auswählen

convOut=-af aresample=resampler=soxr:precision=28 
Erklärung:
https://ffmpeg.org/ffmpeg-resampler.html
precision:
For soxr only, the precision in bits to which the resampled signal will be calculated.
The default value of 20 (which, with suitable dithering, is appropriate for a destination bit-depth of 16)
gives SoX’s ’High Quality’; a value of 28 gives SoX’s ’Very High Quality’.
Wie wirkt sich der Parameter "precision" auf die interne Rechengenauigkeit von soxr aus ?
Wechselt soxr durch die Erhöhung von "precision" von "int" auf "float" ?
Man kann den Wert auch über 28 bis auf 33 noch weiter erhöhen, die Bittiefe kann es also kaum sein.
Ich habe schon versucht "precision" im source Code auf https://github.com/chirlu/soxr zu verfolgen,
aber leider reichen meine Programmierfähigkeiten dazu nicht aus. :?

Gibt es eine Möglichkeit soxr per Parameter zur Verwendung von "float" zu bewegen ?

Auf der Outputseite ist bei mir aktuell wav24 eingestellt:

The following output types are currently supported:
...
wav24 PCM audio encoded in 24-bit WAV format. For lossless 16-bit input streams (FLAC and ALAC),
the audio samples are extended to 24 bits by padding each sample with zeros.
For lossy input streams (AAC and MP3), a floating-point conversion is performed with full 24-bit precision.
If the input type isn't flac or if the output type is followed by a semicolon, a stream converter program is required.
...
For best sound quality, it is recommended that you use the
output sample bit depth that matches the maximum capabilty of your music player.
For example, if your music player is a Linn DS, the best match is wav24.
Results may vary with different types of music player.
jplay würde 32bit unterstützen,
aber einen "wav32" Parameter habe ich im Minimserver leider nicht finden können.

Ich hoffe Ihr habt ein paar Tipps für mich ;-)

Danke und Grüße
Maximilian
Bild
h0e
Administrator
Beiträge: 3864
Registriert: 11.11.2013, 09:40
Wohnort: München

Beitrag von h0e »

Hallo,

Maximilians Post hat mich mal aufhorchen lassen.
Es ist schon toll, was man mit Minim alles anstellen kann.
Man kann das FFMPEG Paket aus der Community auf der Synology installieren und nutzen.

Code: Alles auswählen

stream.converter /volume1/@appstore/ffmpeg/bin/ffmpeg
In der Doku von FFMPEG sind auch Dithering Options genannt.
Hat damit schon mal jemand experimentiert?

Grüsse Jürgen
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

mm2 hat geschrieben: https://ffmpeg.org/ffmpeg-resampler.html
precision:
For soxr only, the precision in bits to which the resampled signal will be calculated.
The default value of 20 (which, with suitable dithering, is appropriate for a destination bit-depth of 16)
gives SoX’s ’High Quality’; a value of 28 gives SoX’s ’Very High Quality’.
Wie wirkt sich der Parameter "precision" auf die interne Rechengenauigkeit von soxr aus ?
Wechselt soxr durch die Erhöhung von "precision" von "int" auf "float" ?
Man kann den Wert auch über 28 bis auf 33 noch weiter erhöhen
Hallo Maximilian,

bisher haben wir in diesem Thread von Samples aus 64-Bit Fließkommazahlen gesprochen, weil sich bei diesen auch bei längeren Rechnungen sich aufschaukelnde Rundungsfehler noch weit unterhalb des Musiksignals bewegen.

Beim Upsamplen gibt es meist mehrere Schritte, erst werden mit irgendeinem Algorithmus zusätzliche Samples eingefügt und dann werden mit einem Filter dadurch entstandene Artefakte im hörbaren Bereich beseitigt. Die oben von Dir genannte "precision" steuert, welchen Abstand das nach der Filterung übrig bleibende Rauschen vom Musiksignal hat. Wie Du richtig sagst, benutzt die beste bei 'sox' wählbare Variante 28 Bits (entspricht -170dB) dafür. Mehr wäre da auch Unsinn, weil wir ja festgestellt haben, dass 'sox' nur mit 32 Bit Samples rechnet. in 'libsoxr' kann man aber in der Tat die precision bis 33 Bit erhöhen, ein Rauschabstand von -200dB. Das ist natürlich nur sinnvoll, wenn die Rechnungen mit 64-Bit Zahlen gemacht werden, und das ist die Einstellung, die ich in 'resample_soxr' auch verwende.

Damit ist sichergestellt, dass das durch Resampling zugefügte Rauschen weit unterhalb jeden Musiksignals ist.

Viele Grüße,
Frank
Bild
mm2
Aktiver Hörer
Beiträge: 295
Registriert: 17.05.2010, 22:12
Wohnort: München

Beitrag von mm2 »

Hallo Frank,

Danke :)
Wenn das Rauschen nach dem Filtern einen so hohen Rauschabstand erreichen soll,
muss intern mit entsprechend hoher Genauigkeit gerechnet werden.

Soweit ich den Thread verstanden habe, gibt es jedoch mehrere Bearbeitungsschritte.
Um sicher zu stellen dass von Anfang an mit entsprechend hoher Genauigkeit gerechnet wird,
wandelst Du das das Input File in 64Bit Fließkommazahlen um.

Die "Resampler Options" von soxr sind leider beschränkt
https://ffmpeg.org/ffmpeg-resampler.html
eventuell kann man über "tsf" 64Bit Fließkommazahlen erreichen,
leider ist die Option nur sehr kurz beschrieben.

Code: Alles auswählen

tsf, internal_sample_fmt
Set the internal sample format. Default value is none. This will automatically be chosen when it is not explicitly set.

auf was man tsf setzen muss um Fließkommazahlen zu erreichen, habe ich leider nicht finden können.
s32 geht aber f32 / f64 nicht.

Anderes Thema, ich versuche beim Upsampling-Filter die Vor-/Nachschwinger zu beinflussen.
Für Soxr sind dafür leider wenige Paramater verfügbar.

‘soxr’

Code: Alles auswählen

select the SoX Resampler (where available); compensation, and filter options filter_size, phase_shift, exact_rational, filter_type & kaiser_beta, are not applicable in this case. 
"cutoff, precision und cheby" haben leider kaum Einfluss auf das Vor-/Nachschwinger Verhalten

Welche Möglichkeiten gibt es den Upsampling-Filter von soxr zu beeinflussen ?

VG
Maximilian
Bild
uli.brueggemann
Aktiver Hersteller
Beiträge: 4658
Registriert: 23.03.2009, 15:58
Wohnort: 33649
Kontaktdaten:

Beitrag von uli.brueggemann »

Hat schon mal jemand den Secret Rabbit Code getestet?
Siehe http://www.mega-nerd.com/SRC/index.html
Was dann wohl hinter libsamplerate steckt.
Aber die Webseite erzählt dazu denn ein bisschen mehr.

Grüsse
Uli
Bild
dietert
Aktiver Hörer
Beiträge: 533
Registriert: 24.11.2013, 10:31
Wohnort: 76571 Gaggenau
Kontaktdaten:

Beitrag von dietert »

Hallo Uli,

für einen gründlichen Test fehlt mir die Zeit, habe aber die Sourcen kurz angesehen.
Die Interpolation erfolgt anscheinend im Zeitbereich. Es gibt umfangreiche vorgefertigte Tabellen mit Filterkoeffizienten. So bleibt verborgen, wie die Filter abgeleitet wurden. Eigentlich schreibt man da ein paar Zeilen mit sinh() und einer Fensterung als Formeln hin, es ist ja imgrunde nur ein Tiefpass.
Ein Profi würde dann noch Selbsttestcode beifügen (unit test). Z.B. ein Logsweep für das Filter zwecks Bestimmung von Eckfrequenz, Rauschen usw.
Der Autor hat sich nach eigenen Angaben neun Jahre damit befasst (2002 .. 2011), es wird wohl funktionieren.

Grüße,
Dieter T.
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

mm2 hat geschrieben: Die "Resampler Options" von soxr sind leider beschränkt
https://ffmpeg.org/ffmpeg-resampler.html
eventuell kann man über "tsf" 64Bit Fließkommazahlen erreichen,
leider ist die Option nur sehr kurz beschrieben.

Code: Alles auswählen

tsf, internal_sample_fmt
Set the internal sample format. Default value is none. This will automatically be chosen when it is not explicitly set.

auf was man tsf setzen muss um Fließkommazahlen zu erreichen, habe ich leider nicht finden können.
s32 geht aber f32 / f64 nicht.

Anderes Thema, ich versuche beim Upsampling-Filter die Vor-/Nachschwinger zu beinflussen.
Für Soxr sind dafür leider wenige Paramater verfügbar.

‘soxr’

Code: Alles auswählen

select the SoX Resampler (where available); compensation, and filter options filter_size, phase_shift, exact_rational, filter_type & kaiser_beta, are not applicable in this case. 
"cutoff, precision und cheby" haben leider kaum Einfluss auf das Vor-/Nachschwinger Verhalten

Welche Möglichkeiten gibt es den Upsampling-Filter von soxr zu beeinflussen ?
Hallo Maximilian,

da kann ich Dir leider auch nicht weiter helfen, da ich das ffmpeg Programm nicht kenne. Nach der Beschreibung, auf die Du verlinkst, scheint die Anbindung an libsoxr nur rudimentär zu sein.
Wenn Du die libsoxr direkt in einem C-Programm verwendest, dann kannst Du Sample-Format (unter anderem 64-bit floats), Phase des Filters und Steilheit des Bandpass-Filters konfigurieren. Aber das wird anscheinenend in dem ffmpeg-Interface nicht durchgereicht.

Viele Grüße,
Frank
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

uli.brueggemann hat geschrieben:Hat schon mal jemand den Secret Rabbit Code getestet?
Siehe http://www.mega-nerd.com/SRC/index.html
Was dann wohl hinter libsamplerate steckt.
Aber die Webseite erzählt dazu denn ein bisschen mehr.
Hallo Uli,

ich denke, dieser Code wird als Standard-Resampler in Linux zum Beispiel in Alsa oder Jack und einigen Programmen benutzt. Das ist wohl auch ordentlich programmiert, die Filter erreichen aber nicht einen so hohen Rauschabstand, wie wir oben diskutiert haben.

Vergleiche zum Beispiel auf http://src.infinitewave.ca/ die Sweep-Graphen zu "SoX 14.4 VHQ Intermediate Phase" und "Secret Rabbit Code 0.1.8 (Best)".

Viele Grüße,
Frank
Bild
mm2
Aktiver Hörer
Beiträge: 295
Registriert: 17.05.2010, 22:12
Wohnort: München

Beitrag von mm2 »

Hallo Frank,
Nach der Beschreibung, auf die Du verlinkst, scheint die Anbindung an libsoxr nur rudimentär zu sein.
es scheinen leider mehrere Parameter nicht durchgereicht zu werden. :(
Andere die mit "soxr only" oder "swr only" beschrieben sind werden aber von beiden akzeptiert.
... die Filter erreichen aber nicht einen so hohen Rauschabstand, wie wir oben diskutiert haben.
das hat vermutlich nur zum Teil mit der Rechengenauigkeit zutun.
Die Steilheit der Filter ist für die Darstellung im Frequenzbereich mit entscheidend.
Vergleiche zum Beispiel auf http://src.infinitewave.ca/ die Sweep-Graphen zu "SoX 14.4 VHQ Intermediate Phase" und "Secret Rabbit Code 0.1.8 (Best)".
Ich schaue mir neben der Darstellung im Frequenzbereich auch immer das Ein-/Auschwingen im Zeitbereich an.

Vergleiche mit dem Link oben mal ffmpeg (soxr) mit ffmpeg (swr)
+soxr über 80dB besserer Rauchabstand
+swr deutlich weniger Vor-/Nachschwinger

Sehr interessant ist der klangliche Vergleich der beiden,
in meinen Ohren hat das kurze Vor-/Nachschwinger auch seine Vorteile.

VG
Maximilian
Bild
frankl
Aktiver Hörer
Beiträge: 486
Registriert: 20.01.2013, 01:43
Wohnort: Aachen

Beitrag von frankl »

mm2 hat geschrieben: Vergleiche mit dem Link oben mal ffmpeg (soxr) mit ffmpeg (swr)
+soxr über 80dB besserer Rauchabstand
+swr deutlich weniger Vor-/Nachschwinger

Sehr interessant ist der klangliche Vergleich der beiden,
in meinen Ohren hat das kurze Vor-/Nachschwinger auch seine Vorteile.
Hallo Maximilian,

das Bild unter "Impulse" kann man leicht fehlinterpretieren. Ein 1-Sample Impuls ist ja kein erlaubtes Musiksignal, das man digital kodieren kann. Das sich die Schwinger bei ffmpeg (soxr) weit nach links und rechts ausbreiten, hängt damit zusammen, dass der Filter steiler ist (dafür muss man "genauer" rechnen, mehr Samples des Input werden pro Output-Sample benötigt). Schau mal auf "Passband", dann siehst Du dass bei ffmeg (swr) schon ab 18kHz das Nutzsignal abgesenkt wird.

Viele Grüße,
Frank
Bild
mm2
Aktiver Hörer
Beiträge: 295
Registriert: 17.05.2010, 22:12
Wohnort: München

Beitrag von mm2 »

Hallo Frank,
Ein 1-Sample Impuls ist ja kein erlaubtes Musiksignal, das man digital kodieren kann
digital ist es möglich, aber es sollte wie ein Rechtecksignal nicht aus einem A/D Wandler kommen.

Bei "genauer rechnen" denke ich zuerst an die Bittiefe.
Mit längeren Filtern sind auch steilere Filter möglich, das sieht man sehr gut unter 'transition'.

Bei swr gibt es einen Parametern für die:

Code: Alles auswählen

filter_size
For swr only, set resampling filter size, default value is 32.
bei ffmeg (swr) schon ab 18kHz das Nutzsignal abgesenkt wird.
-1db bei 20khz bei swr oder das Ringing bei steileren Filtern.
Ich kann das bei mir einfach vergleichen, muss dafür nur zwei Buchstaben ändern :D

VG
Maximilian
Bild
mm2
Aktiver Hörer
Beiträge: 295
Registriert: 17.05.2010, 22:12
Wohnort: München

Beitrag von mm2 »

Hallo Frank, hallo Experten-Runde,

in einem Teil des Threads ging es um die Auswirkungen der Rechen(un)genauigkeit bei Lautstärkeänderungen.

Auch wenn im Zusammenspiel von ffmpeg und soxr manche "Resampler Options" noch unklar sind,
so ist in der umfangreichen Doku doch einiges zu finden:
https://ffmpeg.org/documentation.html

zu "volume" bin ich hier fündig geworden:
https://ffmpeg.org/ffmpeg-filters.html#Commands-11

ich habe das bei mir wie folgend auf "64-bit floating-point" Rechengenauigkeit umstellen können:

Code: Alles auswählen

volume=-3dB:precision=double
VG
Bild
Antworten