DSP - Best Practice bei Formatumwandlung und Faltung?
DSP - Best Practice bei Formatumwandlung und Faltung?
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
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
-
- Aktiver Hörer
- Beiträge: 5654
- Registriert: 25.01.2008, 15:17
- Wohnort: Schweitenkirchen
- Kontaktdaten:
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
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
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
Hier kannst Du zwischen allen möglichen umkonvertierungen sowie etlichen Filtern wählen!
https://www.signalyst.com/consumer.html
Grüße
Christian
Hallo Simon,
Beispiel: 16b44k1 > sox: double176k4 > brutefir: double176k4 > sox: 24b176k4
Grüße,
Andree
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.Daihedz hat geschrieben:Macht eine zweistufige Wandlung theoretisch Sinn, und falls ja, dann in welcher Reihenfolge?
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).Daihedz hat geschrieben:Fragen zur Auslegung einer Pipe mit Convolution
Beispiel: 16b44k1 > sox: double176k4 > brutefir: double176k4 > sox: 24b176k4
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.Daihedz hat geschrieben:Macht es theoretisch Sinn, für die Convolution das Format über das Ausgangs-Target hinaus hochzurechnen, und danach rückzuwandeln?
Grüße,
Andree
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
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
-
- Aktiver Hörer
- Beiträge: 489
- Registriert: 26.02.2012, 10:48
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
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
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
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
Hallo Andree
Ne Idee warum?
Nachteile im Klang könnte ich hier noch keine feststellen.
Grüße
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.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.
Ne Idee warum?
Nachteile im Klang könnte ich hier noch keine feststellen.
Grüße
Christian
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
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
Hallo Jürgen
Hab mich evtl. Falsch ausgedrückt![Wink ;)](./images/smilies/icon_wink.gif)
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
Hab mich evtl. Falsch ausgedrückt
![Wink ;)](./images/smilies/icon_wink.gif)
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
Hallo Christian,
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
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 entwederchriss0212 hat geschrieben: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?
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
Hallo Tobias,Pittiplatsch hat geschrieben: 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?
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
-
- Aktiver Hörer
- Beiträge: 489
- Registriert: 26.02.2012, 10:48
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
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
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
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