BruteFir Fehlermeldung; Ich weiß nicht weiter :(

[frankl]

Hallo Hank,

hier noch ein paar Anmerkungen zur vorhergehenden Diskussion.

In Deiner brutefir Konfiguration gibts Du die "sampling_rate:" an. Diese wird von brutefir nur benutzt, weil Deine Ausgabe direkt auf ein ALSA Device geht; um das zu öffnen muss die Samplingrate festgelegt werden.

Ansonsten ist für brutefir die sampling_rate irrelevant. Allerdings ist ein FIR Filter immer für Daten mit einer bestimmten Samplingrate gedacht; und es ist in der Verantwortung des brutefir Nutzers, dass die Samplingrate der Inputs und Outputs gleich der Samplingrate der Filter ist.

Man kann aber FIR Filter genauso wie Musikstücke resamplen. Wenn etwa Deine Datei "/root/brutefir/filter/XO1L48.dbl" ein FIR Filter für 48 kHz und im FLOAT64_LE Format ist, so kannst Du mit

Code: Alles auswählen

sox -t raw -r 48000 -c1 -e float -b 64 /root/brutefir/filter/XO1L48.dbl \
    -t raw /root/brutefir/filter/XO1L96.dbl rate  -v -I 96000

einen entsprechenden FIR Filter für 96 kHz erzeugen.

Mit dem CLI Interface kann man in einem laufenden brutefir Einiges ändern, zum Beispiel die verwendeten Filter und alle Lautstärkeangaben. Wenn man aber auf ein anderes Sampleformat oder eine andere Samplerate wechseln will, muss man brutefir mit angepasster Konfiguration neu starten.

Zum Dithering: Ich würde sagen, dass bei 16-Bit Ausgabe Dithering immer wünschenswert ist. Simon hat ja hier über Probleme von brutefir mit Dithering zusammen mit ALSA Ausgabe berichtet. Ich habe das Dithering lange Zeit (aber mit stdout als Ausgabe) ohne Problem genutzt. Besser ist das Dithering und Noiseshaping mit sox, für 44.1 kHz mit 16 Bit habe ich zum Beipiel lange Zeit folgendes benutzt:

Code: Alles auswählen

... | sox -t raw -r 44100 -c2 -e float -b 64 - \
          -t raw -r 44100 -c2 -e signed -b 16 - dither -s -f high-shibata | ...

Zum Rausfinden der Samplerate und Bittiefe einer Audiodatei gibt es viele Möglichkeiten. In shell-Skripten kann man zum Beispiel auch sox mit Option --i benutzen:

Code: Alles auswählen

#!/bin/bash

export SAMPLERATE=`sox --i $1 | grep "Sample Rate" | sed -e "s/[^0-9]//g"`
export BITDEPTH=`sox --i $1 | grep "Precision" | sed -e "s/[^0-9]//g"`

echo "Samplerate ist "$SAMPLERATE
echo "Bittiefe ist "$BITDEPTH

Viele Grüße,
Frank

[uli.brueggemann]

Frank,

ein "übliches" Resampeln eines Filters z.B. von 48 kHz auf 96 kHz führt dazu, dass das Filter oberhalb 24 kHz nichts mehr durchlässt. Der Musikinhalt darüber wird also abgeschnitten.

Ein "übliches" Resamplen eines Filters von 96 kHz auf 48 kHz führt dazu, dass die Filterlänge verkürzt wird, in diesem Beispiel halbiert. Was denn die Auflösung reduziert.

Die allermeisten Soundkarten vertragen heute 24 Bit Daten. Es wäre m.E. Unsinn mit Brutefir 16 bit nett gedithert und gepampert auszugeben, wenn man denn gleich die 24 bit ausgeben kann. Ob man dann das Dithering, welches man dann trotzdem noch durchführen kann, noch wahrnimmt, ist fraglich, lässt sich aber ja bequem einschalten. Sicher ist sicher.
Noise shaping macht eigentlich auch nur Sinn bei Abtastraten < 48 kHz. Bei 24 bit aber auch nur, weil es eben machbar ist.

Grüsse
Uli

[frankl]

ein "übliches" Resampeln eines Filters z.B. von 48 kHz auf 96 kHz führt dazu, dass das Filter oberhalb 24 kHz nichts mehr durchlässt. Der Musikinhalt darüber wird also abgeschnitten.

Hallo Uli,

diese Aussage stimmt zwar auch nicht, aber Du hättest kürzer sagen können, dass meine Aussage über das Resamplen von FIR-Filtern totaler Quatsch ist! Da habe ich etwas durcheinandergebracht. Danke für den Hinweis.

@MODERATION: Vielleicht kann jemand in meinem Beitrag oben die 5 Zeilen von "Man kann aber FIR Filter ..." bis "... FIR Filter für 96 kHz erzeugen." löschen oder durch "[FALSCHES BEISPIEL GELOESCHT]" oder so ähnlich ersetzen, damit das keiner nachmacht? Danke.

Die allermeisten Soundkarten vertragen heute 24 Bit Daten. Es wäre m.E. Unsinn mit Brutefir 16 bit nett gedithert und gepampert ...

Der Hinweis zum Dithering bezog sich ja ausschließlich auf 16-Bit Ausgabe (wie in Hanks Beispiel), und dann lohnt sich dieses "pampern". Wenn die Ausgabe 24- oder 32-Bit Samples erlaubt, sollte man das natürlich nutzen (in diesem Fall mache ich auch kein Dithering).

Frank

[uli.brueggemann]

ein "übliches" Resampeln eines Filters z.B. von 48 kHz auf 96 kHz führt dazu, dass das Filter oberhalb 24 kHz nichts mehr durchlässt. Der Musikinhalt darüber wird also abgeschnitten.

Hallo Uli,

diese Aussage stimmt zwar auch nicht, aber Du hättest kürzer sagen können, dass meine Aussage über das Resamplen von FIR-Filtern totaler Quatsch ist! Da habe ich etwas durcheinandergebracht. Danke für den Hinweis.

Frank,

1. was stimmt da nicht dran?
2. etwas einfach als totalen Quatsch abzustempeln hilft vielleicht dem Ego, bringt aber keine Erkenntnisse. Ich sehe es auch nicht als Quatsch.

Grüsse
Uli

[Hank]

Hallo,

und vielen Dank für die Diskussion.

Ich habe mir die Links zu Frank seinem Thread bzw. seiner Website angesehen. Es geht ja, um den Schluß zu meinem Vorhaben zu ziehen, um das Resamplen. Mir stellte sich die Frage, warum ich das machen sollte, wenn es auch anders, wenn auch aufwändiger, geht. Ich hatte die Befürchtung, dass das Resamplen auch zu Verschlechterungen führen kann. Daraufhin habe ich mal einen mir persönlich befreundeten Studiobetreiber befragt. Der hat zwar von BruteFir etc. kaum Ahnung, aber eben von grundsätzlichen Dingen, wie man mit Audiodaten im PC umgeht und was etwas beeinflusst und was halt nicht. Und der hat mir bestätigt, dass man das "eigentlich" nicht machen soll. Also meine Meinung dazu bestätigt. Ich möchte aber ausdrücklich keinen Streit darüber anzetteln. Ich möchte halt, da ich die Möglichkeit bei meinem Vorhaben habe, kein Resampling machen. Gleiches gilt für die Frage, ob ich innerhalb des PC, also in der digitalen Domäne, den Pegel regeln sollte oder lieber dahinter in der analogen Domäne. Da war meine Ansicht schon klarer in der Richtung es nach Möglichkeit nicht in der digitalen Domäne zu machen. Das bestätigte mir mein "Fachmann" auch. Daher möchte ich es auch so machen. Vielleicht mache ich es als Übergangslösung noch nicht, aber als Endlösung schon.

Um auf mein Vorhaben zurück zu kommen. Ich möchte ja eigentlich nur eine XBMC Box haben. Und die soll "nebenbei" auch mit BruteFir arbeiten, weil ich keinen Sinn darin sehe mir einen zweiten PC als Convolver dahin zu stellen, wenn der erste PC mit XBMC schon da ist. Leider ist es, soweit mein Kenntnisstand ist, nicht möglich direkt von XBMC an BruteFir per Alsa auszugeben. Also muss ich den Weg über Jack nehmen. Leider ist es aber auch nicht möglich, direkt von XBMC an Jack auszugeben. Also muss ich den weiteren Umweg über PuleAudio nehmen. Das kann XBMC. (An dieser Stelle möchte ich vorausschicken, dass ich dem Englischen nicht sonderlich mächtig bin.) Im XBMC Wiki http://wiki.xbmc.org/index.php?title=PulseAudio steht, dass man dekodiert per PulseAudio ausgeben kann. Außerdem steht da, dass man, was die Samplerate betrifft, mehrere Möglichkeiten hat. Man kann entweder mit konstanter SR ausgeben. Dann resamplet XBMC (mit ffmpeg). Man kann aber auch mit der SR ausgeben, wie sie in der Datei ist. Das ist dann ja das, was ich brauche Weiterhin kann XBMC per Python Befehle an andere Programme etc. ausgeben. Also dachte ich mir, mache ich es "ganz einfach" so, dass XBMC das Kommando übernimmt und dann den beteiligten Programmen sagt, mit welcher SR sie nun arbeiten sollen. Was die Pegelregelung betrifft, würde ich das wohl innerhalb von XBMC vorerst machen. Klar, man kann das auch in BruteFir oder sonst wo machen, aber das dürfte das Einfachste sein und wenn es nur ein Übergang sein soll, soll es mir Recht sein. Einzig die Frage, ob man es innerhalb des Alsa Treiber der (RME)Soundkarte machen kann, könnte man nochmal überdenken, wenn das dann nach dem DAC in der Soundkarte passiert, was ich allerdings eher nicht vermute.

Nun kommt aber noch ein Problem. Ich möchte ja auch noch externe Signale falten. Also muss ich dem Rechner auch sagen, dass er den externen Eingang nutzen soll. Das kann man sicherlich auch mit XBMC über Python machen. Nur dann brauche ich die Information über die SR von der SK statt von XBMC, aber auch das stelle ich mir nicht so sehr problematisch vor, nachdem ich die Skripte allein in diesem Thread gesehen habe.

Ich hoffe ich konnte etwas zu dem verdeutlichen, was ich so vor habe und freue mich über Anregungen und auch konstruktive Kritik. Gern kann ich auch einen neuen Thread aufmachen oder den Titel ändern (lassen).


Vielen Dank und Gruß

Hank


P.S. Meine brutefir_config steht am Ausgang nicht mehr auf 16, sondern auf 24 Bit.

P.P.S. Frank, Dein Beispiel um die SR aus den Dateien abzufragen kommt grad richtig

Edit: Was ich vergaß, in dem obigen Link zum XBMC Wiki steht, dass per PuleAudio keine bitgenaue Ausgabe erfolgt, wenn ich das richtig verstanden habe. Nur was bedeutet das konkret?

[frankl]

ein "übliches" Resampeln eines Filters z.B. von 48 kHz auf 96 kHz führt dazu, dass das Filter oberhalb 24 kHz nichts mehr durchlässt. Der Musikinhalt darüber wird also abgeschnitten.

Hallo Uli,

diese Aussage stimmt zwar auch nicht, aber Du hättest kürzer sagen können, dass meine Aussage über das Resamplen von FIR-Filtern totaler Quatsch ist! Da habe ich etwas durcheinandergebracht. Danke für den Hinweis.

Frank,

1. was stimmt da nicht dran?
2. etwas einfach als totalen Quatsch abzustempeln hilft vielleicht dem Ego, bringt aber keine Erkenntnisse. Ich sehe es auch nicht als Quatsch.

Hallo Uli,

hm, muss ich jetzt selbst noch den Beweis antreten, dass ich Quatsch geschrieben habe?

Na gut, aus Fehlern soll man ja lernen.

Ich habe einen Log-Sweep von 10-23000 Hz in einer Datei mit Samplerate 48k gemacht, sieht so aus (mit audacity).
[img]http://frank_l.bitbucket.org/fsuyaflwhfsauy/48kSweep.png[/img]

Jetzt mit einem FIR Filter gefaltet, den ich für 48k erzeugt habe (tut was er soll).
[img]http://frank_l.bitbucket.org/fsuyaflwhfsauy/48kFiltered.png[/img]

Der Sweep von oben upgesampled auf 96k, sieht aus wie erwartet.
[img]http://frank_l.bitbucket.org/fsuyaflwhfsauy/48kSweepAs96k.png[/img]

Jetzt habe ich den FIR Filter auch auf 96k upgesampled (wie in dem Code, der oben besser gelöscht werden sollte) und den upgesampleten Sweep durchgeschickt.
[img]http://frank_l.bitbucket.org/fsuyaflwhfsauy/48kSweepAs96kFiltered.png[/img]

Ich finde, dass zeigt ganz klar, dass das Upsamplen des FIR Filters "Quatsch" ist. Man würde sich ja eine Methode wünschen, aus dem 48k FIR Filter einen 96k FIR Filter zu generieren, so dass das vorhergehende Bild so aussieht, wie das zweite Bild. Das ist aber wohl ein sehr schwieriges Problem. Oder weiß hier jemand, wie das geht?

Jetzt nehmen wir noch einen Log-Sweep von 10-47000 Hz als 96k Datei.
[img]http://frank_l.bitbucket.org/fsuyaflwhfsauy/96kSweep.png[/img]

Und schicken diese durch den upgesampleten FIR Filter.
[img]http://frank_l.bitbucket.org/fsuyaflwhfsauy/96kSweepFiltered.png[/img]

Da wird also auch über 24k etwas durchgelassen (der enge Peak ist bei etwa 22k).

Viele Grüße,
Frank

[frankl]

Hallo Hank,

zu den Fragen Resamplen oder nicht, sowie Lautstärkeregelung digital oder analog gibt es keine allgemein gültigen Antworten. Was immer man macht, ist ein Kompromiss, und was die jeweils optimale Lösung ist, hängt von vielen Details ab.

Zu XBMC kann ich direkt nichts sagen. Aber Du könntest ja zu den zwei genannten Punkten auch unabhängig von XBMC erstmal Experimente machen, um Dir eine fundierte Meinung im Zusammenhang mit Deinem Setup zu bilden.

Ich habe zum Beispiel in einem älteren Setup, als ich noch einen Verstärker mit (analoger) Lautstärkeregelung hatte, zum Vergleich mal den Lautstärkeregler ganz aufgedreht (und später per Jumper überbrückt) und die Lautstärke digital verringert. Damit hatte ich etwa 2 Bits digitaler Auflösung verschenkt, hatte aber keinen Lautstärkeregler mehr im analogen Signalpfad. Das war in meinem Setup ein sehr deutlicher Fortschritt.

Grundsätzlich Angst vor Qualitätsverlusten beim Resamplen zu haben, ist meiner Meinung nicht gerechtfertigt. Mit einem sehr guten Upsampler sind die Verluste extrem gering. Dafür könnte es zum Beispiel vorkommen, dass ein DAC oder eine Soundkarte mit gewissen Sampleraten bessere Qualität liefert, als mit anderen. Außerdem hatte ich bei mir in Bezug auf System- und Raumkorrektur den Eindruck, dass die Filter bei höherer Samplerate ein besseres Ergebnis liefern (die FIR Filter sind für jede Samplerate neu berechnet und nicht resampled worden!).

Hier ist noch ein Link auf einen interessanten Beitrag von Martin, der vielleicht auch im Zusammenhang mit XBMC interessant sein könnte. Es wird gezeigt, wie man brutefir hinter ein virtuelles "aloop" ALSA-Device hängen kann.

Viel Spaß beim Experimentieren,
Frank

[uli.brueggemann]

hm, muss ich jetzt selbst noch den Beweis antreten, dass ich Quatsch geschrieben habe?

Hallo Frank,

nein. Aber weshalb meine Aussage nicht stimmt.
Siehe folgende Bilder:



Das obere Bild zeigt den Frequenzgang eines 48 kHz Korrekturfilters (rot), das geht bis 24 kHz. Nach dem Upsampeln auf 96 kHz ist nach wie vor keine Information > 24 kHz vorhanden, das wird durch das 96kHz Korrekturfilter (grün) auch so dargestellt. Zusätzlich ist auch das notwendige Brickwallfilter erkennbar. Es ist also oberhalb 24 kHz eine Bandsperre wirksam.

Das Bild darunter zeigt einen Sweep von 1 kHz bis 48 kHz (braun), Abtastrate ist 96 kHz. Dieser wurde nun mit dem upgesampelten Korrekturfilter gefaltet, das Ergebnis ist blau dargestellt. Wie schön zu sehen ist, fehlt da was am oberen Ende. Das ist genau das, was das Korrekturfilter sperrt.

Also, ein "übliches" Upsampeln eines Filters verhindert, dass evtl. vorhandene höhere Frequenzen im Musiksignal rausgefiltert werden.

Acourate verwendet zum Upsampeln einen speziellen Algorithmus. Die beim 48 kHz Filter nicht vorhandene Information oberhalb 24 kHz kann Acourate auch nicht wiederherstellen. Aber es kann, mit passender Verstärkung versehen, dafür gesorgt werden, dass das Musiksignal > 24 kHz zumindest durchgelassen werden. Das sieht dann so aus:



Ich hoffe es ist nun klarer.

Grüsse
Uli

[frankl]

hm, muss ich jetzt selbst noch den Beweis antreten, dass ich Quatsch geschrieben habe?

Hallo Frank,

nein. Aber weshalb meine Aussage nicht stimmt.
Siehe folgende Bilder:

Hallo Uli,

danke für Deine Beispiele. Der Unterschied zwischen unseren Beispielen ist, dass Dein (Original-)Filter alles oberhalb einer Grenzfrequenz nicht durchlässt (diese Eigenschaft hatte der Filter in meinem Beispiel nicht). Wenn ich mein Experiment mit einem Filter mit dieser Eigenschaft wiederhole, stelle ich fest, dass das Upsamplen sogar funktioniert (d.h., FIR Filter und Sweep upsamplen und Filter anwenden liefert, soweit sichtbar, das gleiche Ergebnis, wie erst den 48k Filter auf das 48k Signal anwenden und das Ergebnis upzusamplen)! Ok, bis auf eine Kleinigkeit, man muss den upgesampleten FIR-Filter noch mit dem Faktor (alte/neue Samplerate) skalieren, was mir einleuchtet (also ein "vol 0.5" an meinen sox-Beispielcode anhängen).
Warum genau das funktioniert, muss ich mir nochmal überlegen.

Das obere Bild zeigt den Frequenzgang eines 48 kHz Korrekturfilters (rot), das geht bis 24 kHz. Nach dem Upsampeln auf 96 kHz ist nach wie vor keine Information > 24 kHz vorhanden, das wird durch das 96kHz Korrekturfilter (grün) auch so dargestellt. Zusätzlich ist auch das notwendige Brickwallfilter erkennbar. Es ist also oberhalb 24 kHz eine Bandsperre wirksam.

...

Also, ein "übliches" Upsampeln eines Filters verhindert, dass evtl. vorhandene höhere Frequenzen im Musiksignal rausgefiltert werden.

Na, genau dieses Verhalten würde ich mir von dem upgesampleten Filter doch auch erhoffen.

Acourate verwendet zum Upsampeln einen speziellen Algorithmus. Die beim 48 kHz Filter nicht vorhandene Information oberhalb 24 kHz kann Acourate auch nicht wiederherstellen. Aber es kann, mit passender Verstärkung versehen, dafür gesorgt werden, dass das Musiksignal > 24 kHz zumindest durchgelassen werden.

Ok, das würde ich dann nicht "upsamplen", sondern "upsamplen und einen high-pass-Filter addieren" nennen. Was man haben möchte, hängt von der Anwendung ab. (In meinen Korrekturfiltern benutze ich zum Beispiel bei jeder Samplerate in der Targetkurve einen Brickwallfilter bei 22 kHz, da weder mein Lautsprecher noch meine Ohren mit höheren Frequenzen etwas anfangen können.)

Danke für die Beispiele,
Frank

[Hank]

Hallo Hank,

Ich hatte mal folgendes script Namens "go" im "start" Ordner in brutefir implementiert, das die Abfrage der samplerates durchführt, und je nachdem die im Ordner "brutefir" abgelegte conf-datei "ep2corrXX" (XX=samplerate 44, 82, 96 etc) startet, bzw. killt, wenn sich die Samplerate ändert. Diese conf-Dateien weisen dann ja wiederrum auf den Speicherort der Filterdateien hin, die dann im Filterordner unter entsprechender bekannter Nomenklatur (samplerate im Namen) hinterlegt sind.
Du musst also für jede bei dir vorkommende samplerate ein eigenes ep2corrXX schreiben.

Code: Alles auswählen

#!/bin/sh

#load firmware to mface2
hdsploader

echo 4096 > /proc/sys/dev/rtc/max-user-freq
echo 5 > /proc/sys/vm/laptop_mode
echo 1 > /proc/sys/kernel/sched_compat_yield
/jstop > /dev/null 2> /dev/null #kill jconv *old*

# coax digital in, 4 (6)x analog out
ep2_mface

# test for more stable run 30.10.2011
sleep 1
BfirStarted="xxxxx xxxxx xxxxx xxxxx xxxxx"
BfirStartStatus="x"

# define global variable samplerate
samplerate=""

# function to set sample rate
SETSAMPLERATE () {
samplerate=`amixer cget iface=MIXER,name='External Rate' | grep ": values" | cut -d= -f2-`
case "$samplerate" in
 '1')
  echo "Start CorSscript at 44.1 kHz"
  amixer -c 0 cset iface=MIXER,name='Sample Clock Source' 2 >> /alsa_report
 #first set to detected samplerate
  amixer -c 0 cset iface=MIXER,name='Sample Clock Source' 0 >> /alsa_report
 #then switch back to autosync
  schedtool -R -p 97 -e brutefir.rt -nodefault /audiovero/brutefir/ep2corr44 &
  ;;
 '2')
  echo "Start CorSscript at 48 kHz"
  amixer -c 0 cset iface=MIXER,name='Sample Clock Source' 3 >> /alsa_report
 #first set to detected samplerate
  amixer -c 0 cset iface=MIXER,name='Sample Clock Source' 0 >> /alsa_report
 #then switch back to autosync
  schedtool -R -p 97 -e brutefir.rt -nodefault /audiovero/brutefir/ep2corr48 &
  ;;
 '4')
  echo "Start CorSscript at 88.2 kHz"
  amixer -c 0 cset iface=MIXER,name='Sample Clock Source' 5 >> /alsa_report
 #first set to detected samplerate
  amixer -c 0 cset iface=MIXER,name='Sample Clock Source' 0 >> /alsa_report
 #then switch back to autosync
  schedtool -R -p 97 -e brutefir.rt -nodefault /audiovero/brutefir/ep2corr88 &
  ;;
 '5')
  echo "Start CorSscript at 96 kHz"
  amixer -c 0 cset iface=MIXER,name='Sample Clock Source' 6 >> /alsa_report
 #first set to detected samplerate
  amixer -c 0 cset iface=MIXER,name='Sample Clock Source' 0 >> /alsa_report
 #then switch back to autosync
  schedtool -R -p 97 -e brutefir.rt -nodefault /audiovero/brutefir/ep2corr96 &
  ;;
esac
}

# main loop
while true
do
sleep 1
samplerate_new=`amixer cget iface=MIXER,name='External Rate' | grep ": values" | cut -d= -f2-`
if [ "$samplerate_new" != "$samplerate" ] ; then
 echo
 echo
 echo "New samplerate detected, is: "$samplerate_new
 echo "Previous samplerate was:"$samplerate
 killall brutefir.rt > /dev/null 2> /dev/null
 SETSAMPLERATE
 samplerate_new=`amixer cget iface=MIXER,name='External Rate' | grep ": values" | cut -d= -f2-`
 echo "Ssamplerate is set to: "$samplerate_new
 echo
fi
done

Viel Erfolg!

Grüße,
Jörn

Hallo Jörn,

ich nehme an, dass man dieses Scipt einfach beim booten mit startet, also in die rc.local einträgt, und es dann "online" den Soundkarteneingang bezüglich der Samplerate "überwacht/abfragt" und ggf, die korrekte/neue Config lädt?!


Danke Dir

Hank