int32_t hatte ich aus Geschwindigkeitsgründen vorgeschlagen, denn damit rechnet der Pi schneller als mit int16_t oder float oder sogar double.
Es ist nur für Anfangs-Operationen (Einmessen, Rauschen glätten, Vorspann/Nachspann entfernen) gedacht gewesen.
Für die FFT muss aber sowieso dann nochmal alles in double umgewandelt werden, was sicher das eigentliche zeitkritische sein wird.
Von daher könnte man auch bereits beim Lesen der wav-Rohdaten aus dem File alles sofort in einen array double wavbuf[arrlen] um-type-casten, wobei arrlen bei der FFT USHRT_MAX ist, nicht SHRT_MAX.
Auch da könnte man dann gleich Nägel mit Köpfen machen und alles auf die volle Länge skalieren, auch wenn die 2.Hälfte der FFT-Arrays zunächst komplett mit Nullen gefüllt werden muss.
edit:
Ehrlich gesagt bin ich nur jetzt ziemlich überrascht, dass offenbar doch noch keine wav-Files gelesen werden können, denn das sollte doch eigentlich seit 4 Wochen funktionieren - daher auch die ganzen Vorversuche mit dem maskieren der Rohdaten mit 0x00ff, was ja auch nur mit Integer ging, und dann der Vergleich von Daten roh/unmaskiert vs. vereinheitlicht/maskiert. Wenn das damals nicht mit wav-Files korrekt gemacht wurde, müssen wir jetzt wohl nochmal von ganz von vorne anfangen: Denn ohne saubere, definierte und skalierte Datensätze macht eine anschließende FFT ja komplett keinen Sinn.
Zitieren
Lesezeichen