wav Dateien: Programieren von Wiedergabe und Aufnahme

[HaWe]

wie wav files kodiert sind, weiß ich nicht, ich habe ja nur mit Lautstärke-Schwankungen experimentiert.
Dass Werte von 0...255 ankommen wundert mich nicht, aber ich vermute, die sind gruppiert in int16-Blöcke (bei 16-bit-sampling), einmal rechter und einmal linker Kanal.

wenn du allerdings mit 8 bit sampelst, sind es sicher einzelne Bytes, nicht int16.

Bei ausschließlicher Verwendung von expliziten Datentypen hat man übrigens noch einen enormen Geschwindigkeitsvorteil
(int32_t ist auch hier beim Raspi schneller als int16_t).

sind nämlich sowohl wave als auch input vom selben Typ (switchen wir ruhig mal auf int32_t, das ist ja mit int auf ARMs meist identisch ...)
int32_t wave[FESTE_LAENGE], input[FESTE_LAENGE];

dann ist das hier nämlich -zigmal schneller als iterativ einzelne Zellen rüberzukopieren...:
memcpy(wave, input, sizeof(input) );

[hirnfrei]

Was mir aufgefallen ist, wenn das Mikro wenig oder gar keine Geräusche wahr nimmt ist der Wert in der Regel um die 128 herum. Gehe ich davon aus das es sich dabei so gesehen um die 0 Linie handelt?

Interessant dürfte aber auch sein, kann man mit einer Soundkarte auch wirklich von zwei Mikros Stereo aufnehmen? Das wäre bei einem Bot schon sinnvoll da man damit auch mehr oder weniger orten könnte von wo das Geräusch kommt.

[HaWe]

vielleicht kann wer anderes helfen?
Ich weiß auch nicht mehr als dieses hier:

https://de.wikipedia.org/wiki/RIFF_W...0.9C-Abschnitt

[hirnfrei]

Das kenne ich doch irgendwo her .

Ich werde nachher mal ein bisschen mit der Eingabe rum spielen. Lernen beim tuen oder wie das heisst ^^

- - - Aktualisiert - - -

Ich habe die Werte mal in einer CSV gespeichert und in LibreOffice geplottet. Sieht in der Tat so aus wie ich es erhofft hatte. Der grosse Ausschlag ist ein von mir gesprochenes Hallo und ich nehme an, diese dicke Linie davor und danach stellt das Rauschen dar. Ich denke das kann man raus filtern und das Wort ist ja auch sehr gut zu erkennen finde ich.

[HaWe]

die FFT wird dir die Frequenzen sehr genau zeigen, die das Rauschen verursachen.
Dazu müsstest du den FFT-Plot von reinem Rauschen betrachten und dann den Plot, der in deinem Wort vorkommt.
Die Spikes, die in beiden in identischer Weise vorkommen, sind unspezifisch, tragen keine Information.
Ob man sie einfach isoliert aus dem FFT-Array herauslöschen kann, wäre ein Versuch wert: erzeugt man dann die FFT-Rücktransformation, müsste man nämlich ein bereinigtes Wave Signal hören können.

das funktioniert natürlich nur bei identischen, reproduzierbaren Rauschquellen/-Arten und ist daher kein allgemeiner Lösungsweg.
Aber immerhin kannst du die Rausch-Frequenz-Daten als Basis für statistische Rauschfilter verwenden wie ich sie oben genannt habe.

[hirnfrei]

Ich bin mir nur noch nicht ganz sicher, ob deine Idee den Input erst zu speichern eine gute Idee ist. Das Verzögert die Geschichte schon ganz Ordentlich!

Ich versuche als Nächstes mal, was passiert wenn ich nur Daten über 138 und unter 118 an die Ausgabe gebe. Das sollte auf jeden Fall die Geschichte auf das Wesentliche verkürzen.

Ein Gedanke der mir auch kam, letzten Endes muss sich das ja nicht mehr so anhören wie es original war. Solang es sich immer auf die selbe Art verändert sollte es ja egal sein. Hauptsache der Bot weiss was er damit anzufangen hat.

Nächste Frage, wie sehr ähneln sich stimmen? Wenn ich ein Wort spreche und er es erkennt. Würde er es auch bei dir erkennen?

[HaWe]

nein, Speichern muss nicht sein, es dient nur zum Debuggen / zur Verlaufskontrolle.
Später machst du den Vergleich "on the fly".
Aber das Anhören zwischendurch in der Entwicklungsphase ist schon wichtig, damit man weiss, was man verändert hat, ob es besser oder schlechter ist, und wo man jetzt steht.

"hallo Google" beweist, dass es in weiten Bereichen möglich ist, Spracherkennung auch Sprecher-unabhängig zu programmieren.
Die FT/FFT analysiert Schwingungen und Schwebungen als Summe mehrerer Grundfrequenzen (sinus/cosinus als Komplexe Funktionen), und wenn du die richtigen (niederfrequenten Sprach-/Wort/Laut-Grundfrequenzen analysierst und nicht die Stimm-Oberwellen, dann bist du sicher schon recht nah dran. Das klappte ja sogar mit dem Lego Lautstärkesensor

Bei unserer "Spracherkennung" (zumindest wie ich es mir vorstelle) wird ja auch gar nicht ein Wort "richtig erkannt" (Laut für Laut, Pause für Pause), sondern es wir das am besten passendste unter (relativ wenigen) Mustern in der Datenbank gesucht. wenn also Sprecher A "ja " sagt und Sprecher "B" auch, dann wird aller Wahrscheinlicheit nach der Raspi nicht bei B ein "rückwärts" beim Mustervergleich herauslesen.
Aber es gibt nichts, was es nicht gibt, shit happens, siehe Telekom Sprachmenü ("...dann sagen Sie jetzt bitte 'ja'.... :-/ )