UbuntuInAustria
Anmeldungsdatum: 9. Juni 2010
Beiträge: 537
Wohnort: /home
|
Hallo, ja beliebige Genauigkeit braucht man da nicht. CIC Filter finden ja ganz häufig Anwendung bei Abtastratenumsetzung, da sie einfach implemtieren lassen (in digitaler Hardware dann am FPGA oder ASIC). Sie wurden also extra entworfen, dass bei Fixkomma alle Überläufe sich egalisieren. Und Saturation ist ja bei digitaler Hardware auch das Verhalten, was man ohne Zusatzaufwand "automatisch" bei Addition und Multiplikation erhält. Wenn die Werte von 0 bis 1 reichen, kannst du dann nicht mit einer Darstellung in normalem Zweierkomplement arbeiten?! Du arbeitest dann ja praktisch nur mit positiven Zahlen. Aber Theorie zu digitalen Zahlenformaten habe ich jetzt nicht mehr ganz frisch im Kopf. Sonst müsste ich da mal nachsehen, ob ich was für dich finde. Ich hatte ein Semester DSP Programmierung, da haben wir nur mit Fixkomma gearbeitet und die Zahlenformate selbst gewählt - inklusive Umrechung vom ADC und zum DAC.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Ich war im letzten Post wieder mal unpräzise. Also der Zahlenbereich ist -1.0 bis +1.0. Wenn ich jetzt von 16 Bit WAV Daten ausgehe, ist mein Skalierungsfaktor also 32767. Ich habe jetzt auch eine Formel für die benötigte Anzahl der Bits gefunden.
b_accu = b_data + ceil[ stages * log2( delays) ]
Wenn ich das richtig interpretiere brauche ich dann für mein Beispiel bei 16 Bit Eingangsdaten 24 Bits. Ich habe das jetzt mal so umgesetzt, bekomme aber das gleiche merkwürdige Bild. Nur die Skalierung hat sich geändert. Das scheint jetzt eine längere debugging Session zu werden.
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Dakuan schrieb: Ich war im letzten Post wieder mal unpräzise. Also der Zahlenbereich ist -1.0 bis +1.0. Wenn ich jetzt von 16 Bit WAV Daten ausgehe,...
Das war auch mein Gedanke: Was soll das ganze Fließkomma- Getue, wenn Du doch sowieso im Grunde Integer-artige Daten hast ? - das brächte nur Probleme. Wenn ich das richtig interpretiere brauche ich dann für mein Beispiel bei 16 Bit Eingangsdaten 24 Bits.
Ob nun 24 Bit oder 32 Bit, das ist ja nun auch egal. Mit 32 Bit Integer mit Vorzeichen hast Du doch ein sehr gut handhabbares Format !? - da brauchst Du überhaupt keine Sonderbibliotheken, sondern nur simpelste INT- Arithmetik und fertig. LG, track
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Das war auch mein Gedanke: Was soll das ganze Fließkomma- Getue, wenn Du doch sowieso im Grunde Integer-artige Daten hast ?
Ganz so einfach ist die Sache leider nicht, denn ich möchte vorwiegend normale Filter testen. Dazu gehört dann auch, einmal zu sehen, welche Auswirkungen die Anwendung von sog. Fensterfunktionen auf die Filterkoeffizienten hat. Bei einigen Typen geht z.B. der Sperrbereich von -20bB auf -110dB runter wobei die Nullstellen noch deutlich tiefer liegen. Und ich möchte meine Ergebnisse natürlich auch mit den entsprechenden Angaben in der Literatur vergleichen. Die Idee echte Audiodaten direkt damit zu verarbeiten ist mir erst später gekommen, nachdem ich auf einer Webseite eine entsprechende Demo gefunden hatte. Ich habe übrigens gerade festgestellt, das 16 Bit eigentlich nicht ausreichend sind, da ich damit bei ca. -90dB im Bitrauschen lande (ist gut zu sehen). Ich habe deshalb gerade auf 24Bit erweitert, womit ich bis -132dB komme. Allerdings bin ich dann mit 32 Bit auch recht schnell am Ende, bei Filtern höherer Ordnung. Ich habe zwar tatsächlich Geräte, die mit 24 Bit (und 96kHz) Aufzeichnen aber daran hatte ich beim Beginn meiner Filter Experimente noch nicht gedacht. Und das angesprochene Problem tritt auch nur bei CIC Filtern auf, die ich ursprünglich gar nicht wirklich auf dem Zettel hatte und die mir von Anfang an suspekt waren.
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Mit der übertriebenen Auflösung verrennst Du Dich, denke ich ! Die -96 dB (von 16 Bit) sind ohnehin die prinzipielle Grenze, die der A/D- Wandler Deines Rechners theoretisch auflösen kann, praktisch sind es eher -94 dB. Mehr geht bauartbedingt gar nicht. 24 Bit Auflösung (bei denen real existierende Super-Hifi- A/D- Wandler im besten Fall auch nur -120 dB auflösen können) sind allenfalls für extremste Hifi- Musikaufnahmen sinnvoll. Und Du wolltest Morsetöne auswerten, nicht wahr ? Bedenke: Auch kein real existierendes Mikrofon schafft solch eine Dynamik, allenfalls das menschliche Ohr unter optimalen Bedingungen. In der real existierenden Signalverarbeitung sind aus diesem Grund die 16 Bit Auflösung und 32 Bit Rechengenauigkeit bestens etablierter Standard. (Das kann ich Dir als Dipl.-Ing. dieses Fachs versichern !) LG, track
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Und Du wolltest Morsetöne auswerten, nicht wahr ?
Das war der Einstieg in dieses Thema. Aber mein Edirol R-44 Recorder nimmt tatsächlich 4 Kanäle mit 24 Bit Auflösung und bis 192 kHz auf.
Bedenke: Auch kein real existierendes Mikrofon schafft solch eine Dynamik,...
Ist klar, aber ich möchte doch meine Ergebnisse mit denen von Matlab und Co vergleichen können, auch wenn die letzten Bits nur noch Kosmetik sind. Bei der Bearbeitung von realen Audio Dateien benutze ich 24 Bit Auflösung nur, um etwas Reserve bei der Nachbearbeitung zu haben wg. Normalisieren und so. Mit CIC Filtern hatte ich mich nach unserer damaligen Diskussion nur beschäftigt, weil sie im Zusammenhang von Samplerate Konvertierung immer wieder auftauchen. Ich wollte ja mit meinem Testprogramm nicht den theoretischen Verlauf der Kurven zeigen, sondern das was tatsächlich "hinten rauskommt". Das war mir besonders wichtig, weil mein ursprüngliches Programm den Goertzel Algorithmus benutzt, zu dem ich keinerlei Frequenzkurven finden konnte. Insbesondere nicht, wenn die eigentlichen Design Voraussetzungen nicht eingehalten wurden. Ein "Messprogramm" schert sich nicht um Design Kriterien, sondern schaut was tatsächlich passiert. Das ist übrigens sehr aufschlussreich. Und die gute Nachricht ist, es funktioniert jetzt. Es war natürlich wieder mal die bekannte "Verkettung unglücklicher Umstände", und hing indirekt mit der Auswertemethode und der Berechnung der Auswertedauer zusammen, da diese bei CIC Filtern anders berechnet werden muss (bin durch Zufall drauf gekommen). Das angeführte fehlerhafte Beispiel würde dann gerade noch richtig dargestellt werden (Grenzfall). Aber es ist auch interessant zu sehen, wie die Ausgabe von CIC Filtern aussieht, wenn die Anzahl der signifikanten Bits zu gering ist. Die Kurven werden oben einfach abgeschnitten. Ich bin mal so frech und füge mal 2 entsprechende Bilder an.
- Bilder
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Nee, bei 16 Bit versacken die Nullstellen im Digitalisierungsrauschen. (wie zu erwarten) Interessant ist aber, dass durch Ausmitteln des Oversamplings dieser "Nullstellenbereich" bei ca. -104 dB liegt, glatte 10 dB besser als die Grundauflösung des A/D- Wandlers ! → d.h.: man bekommt ggf. durchaus einen größeren Dynamikbereich als der reine Digitalisierungsauflösung erwarten ließe. Was allerdings nicht weggemittelt wird, sind die Linearitätsfehler der A/D- Wandler. Von daher ist der Gewinn nur bedingt nützlich. (und der Nutzen von 24 Bit Digitalisierung mit umso mehr Augenzwinkern zu betrachten ... 😉 ) LG, track
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Nee, bei 16 Bit versacken die Nullstellen im Digitalisierungsrauschen.
Ist klar, ich wollte eigentlich sagen, das jetzt das ursprüngliche Bild aus dem ersten Post richtig dargestellt wird. Ich war gestern etwas hektisch wegen der angedrohten Server Abschaltung.
Was allerdings nicht weggemittelt wird, sind die Linearitätsfehler der A/D- Wandler.
Noch ist da kein echter A/D Wandler beteiligt. Die Werte werden z.Z. noch errechnet. Ich habe jetzt übrigens auf 64 Bit Integer umgestellt. Damit sind jetzt alle Merkwürdigkeiten in der Darstellung verschwunden.
(und der Nutzen von 24 Bit Digitalisierung mit umso mehr Augenzwinkern zu betrachten
Das sehe ich nicht ganz so, denn das hängt immer vom Anwendungsfall ab. Während einer Produktion wird man wohl gerne mit 24 Bit Daten arbeiten und erst als letzten Schritt auf 16 Bit reduzieren. Alleine schon um bei einer evtl. notwendigen Pegel Anhebung nicht noch zusätzlich das Quantisierungsrauschen zu Verstärken. Für das Endprodukt gebe ich Dir aber Recht. Aber nicht das Du jetzt denkst, ich sei ein extremer HiFi Freak. Mich stört zwar, wenn bei CDs die Möglichkeiten einer CD nicht ausgeschöpft werden, aber ich höre auch viel historische Aufnahmen und da bin ich schon froh, wenn das unvermeidbare Rauschen sich in Grenzen hält. -30dB sind da schon ein guter Wert.
|
rklm
Projektleitung
Anmeldungsdatum: 16. Oktober 2011
Beiträge: 12832
|
Dakuan schrieb: Aber nicht das Du jetzt denkst, ich sei ein extremer HiFi Freak. Mich stört zwar, wenn bei CDs die Möglichkeiten einer CD nicht ausgeschöpft werden, aber ich höre auch viel historische Aufnahmen und da bin ich schon froh, wenn das unvermeidbare Rauschen sich in Grenzen hält. -30dB sind da schon ein guter Wert.
Mit Goldkontakten kannst Du das natürlich noch dramatisch verbessern. 😛
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Interessant ist aber, dass durch Ausmitteln des Oversamplings dieser "Nullstellenbereich" bei ca. -104 dB liegt, glatte 10 dB besser als die Grundauflösung des A/D- Wandlers !
Das hat mich jetzt auch etwas nachdenklich gemacht und zu weiteren Versuchen veranlasst. Ich vermutete einen Zusammenhang mit der Verstärkung der Filterstufen, die am Ende zur einheitlichen Darstellung herausgerechnet wird. Aber das hat sich nicht bestätigt. Ich füge da nochmal ein Bild an, bei dem zwar mit 64 Bit gerechnet wird, aber die Eingangsdaten so skaliert werden, als währen es 16 Bit Daten. Der erste Nebenzipfel sollte da eigentlich glatt aus dem Rauschen herauskommen, da er bei ca. -93dB liegt. Tut er aber nicht. Also ich denke man muss da mit einer gewissen Ungenauigkeit sowohl nach oben als auch nach unten rechnen zumal meine Auswertemethode nicht wirklich perfekt ist. Ich bin momentan nicht in der Lage den Verlauf der Sinuskurve anhand der Samples zu rekonstruktieren, daher lasse ich 10 Mal die entsprechende Schwingung komplett durch das Filter laufen und suche den Maximalwert, was leider nicht immer gut funktioniert. Aber für mich ist dieses Projekt sehr Lehrreich, da man die Auswirkungen von zu geringer Bitbreite von Programmen, die den Sollverlauf berechnen, wahrscheinlich nicht gezeigt bekommt. Das ist eben der Vorteil einer Messung (oder Simulation?). Und den mit den Goldkontakten kannte ich schon. Dazu könnte ich noch einiges sagen, aber das gehört dann wohl in den Stammtischbereich.
|
Dakuan
(Themenstarter)
Anmeldungsdatum: 2. November 2004
Beiträge: 6345
Wohnort: Hamburg
|
Irgendwie will das Forum mein Bild nicht. Daher versuche ich es nochmal.
- Bilder
|
track
Anmeldungsdatum: 26. Juni 2008
Beiträge: 7174
Wohnort: Wolfen (S-A)
|
Dakuan schrieb: Interessant ist aber, dass durch Ausmitteln des Oversamplings dieser "Nullstellenbereich" bei ca. -104 dB liegt, glatte 10 dB besser als die Grundauflösung des A/D- Wandlers !
Das hat mich jetzt auch etwas nachdenklich gemacht ...
Das ist die Geschichte mit dem Oversampling ! → in dem Fall mittelt sich das Digitalisierungsrauschen zum Teil heraus, so dass Du tatsächlich eine höhere Auflösung bekommst, als der A/D- Wandler von Hause aus kann. Der Extremfall ist der sogenannte "1-Bit- Wandler", der wirklich nur 1 Entscheidungsschwelle kennt, und den Rest allein durch sein Zeitverhalten, sprich: gnadenloses Oversampling erledigt. Mir war nur aufgefallen, dass man dieses Phänomen bei deinen Filterkurven so schön sehen konnte ... ☺ LG, track
|