wav Dateien: Programieren von Wiedergabe und Aufnahme

[HaWe]

wav ist das universelle Standard-Datenformat für sounds, es werden daher grundsätzlich *.wav gespeichert und geladen.
Die *.wav Files kann man dann auch mit unabhängigen Programmen abhören (und auch bearbeiten), z.B. mit Omxplayer oder mit Windows wave-edit-Programmen.

[hirnfrei]

Ich weiss was wav ist. So ganz dämlich bin ich dann ja doch nicht.

Okay dann kann man sie in einem anderen Programm abspielen. Leuchtet ein, nur warum sollte man das tun? Man kann sie in unserem Programm ja schliesslich auch abspielen. Und in einem anderen Programm bearbeiten leuchtet auch ein, aber da nochmal die Frage nach dem Grund. Ich meine, wenn ich mich nicht irre soll ja unser Programm am Ende ganz alleine das Wort verstehen. Dann sollte das Programm mit der notwendigen Bearbeitung ja auch zurecht kommen oder?

Fenster lasse ich doch erstmal bleiben. Ich denke da du wahrscheinlich nach wie vor auf dem Raspi das schwache LXDE benutzt wäre der Installationsaufwand zu gross.

[HaWe]

Es ist im Moment von mir als ein Regie-Programm zur Vorbereitung und zum Test gedacht, mit universellen Schnittstellen zu Standard-Datenformaten, und das heißt:
*.wav - Standard.

Das "echte" Spracherkennungsprogramm wird das sein, das danach kommt und auf den Tests des Regieprogramms aufbaut...

Trotzdem werden Sounds immer als wav gespeichert und wieder geladen, niemals anders, sonst ist es nicht mehr Standard-kompatibel über verschiedene Plattformen hinweg (z.B. auch für die Anwendung externer Sound-Filter).

[hirnfrei]

Du sagst es ja. Es ist ein "Regie-Programm". Warum muss das über verschiedene Plattformen hinweg kompatibel sein?

Bleibt das Plotten jetzt in einer Spur oder wird mehr auf einem Bildschirm geplottet?

[HaWe]

zum Plotten:
es wäre vlt gut, wenn wir später verschiedene Plots vergleichen könnten, also dann 2-3 untereinander, ich weiß noch nicht, was auf uns zu kommt:
vlt auch oben ein Sound-Plot, darunter der FFT-Graph.
oder 2 Sounds und 2 FFT-Graphen.
Eine variable Basis-Null-Linie (x-Achse) macht die Sache sicher sehr übersichlich.

zum Regie-Programm:
auch da weiß ich noch nicht, ob wir mit der FFT und dem "Roh-Sound" Erfolg haben, gerade wenn ich spreche und deine Muster verwende, oder auch wenn verschieden starke Störungen dabei sind, oder wenn Wörter verschieden schnell gesprochen werden.
Auch was die FFT draus macht, kann ich nur grob erahnen.
Bisher haben wir ja nur die Möglichkeit, Bereiche vorher/nachher abzuschneiden - der Klang an sich wurde nicht verändert.
Es kann also heißen, daß die Vielzahl an Begleit-Frequenzen reduziert werden muss durch Hoch- oder Tiefpassfilter, damit der signifikante Bereich möglichst prägnant herausgestellt wird und unwichtige Frequenzen eliminiert werden.
Keine Ahnung, welche das sein werden - hohe Frequenzen können durchaus wichtig sein (Zisch- oder harte "t"-Laute oder Gutturale etc. ) - trotzdem mag es sein, dass die tiefen Anteile des Klangs (z.B. bis 1000 Hz) ausreichend sind.
Je nachdem, wie die CC Ergebnisse sind, muss man also mit den Klängen experimentieren, aber dafür einen eigenen Equalizer noch zu programmieren, ist sicher etwas hoch gegriffen.
Daher die Option, dafür zunächst externe wav-edit-Programme verwenden zu können bzw. können zu müssen.

[hirnfrei]

Was mir eben nicht so gefällt ist dieses Statische beim direkt in den Grafikspeicher schreiben. Man kann es nicht verschieben und gar nichts. Das ist so gar nicht mein Ding. Okay wenn man nur eine Anzeige hat die man danach eh wieder weg klickt von mir aus, aber wenn man das länger verwenden will ist der Teil vom Bildschirm ja futsch. Unschön. GTK wäre da eben eine nette Lösung gewesen, dafür gibt es auch Beispiele, aber dann müsstest du dir erstmal das komplette GTK 3 plus dev installieren. Das ist wohl übertrieben.

Ich habe aber noch die Möglichkeiten von OpenWF und OpenCV gefunden. Das könnte eine Möglichkeit sein. Mit OpenCV arbeite ich ja sowieso wegen Gesichtserkennung usw. Mal schauen was da geht. Wäre in meinen Augen angenehmer, wenn man das Bild auch in den Hintergrund schicken kann bei Bedarf.

Hast du eigentlich das mit fftw.org gesehen?

[HaWe]

sorry, bitte bleibe bei den Tools, so wie vereinbart, ich werde nichts anderes installieren als mein jetziges openVG, also auch kein openCV.
Ich muss schließlich das Programm und seine einzelnen API-Tools auch selber verwenden und die Tools entsprechend selber weiter programmieren können.
Dazu muss ich die Funktionen kennen und selber nutzen können.

Für andere FFT-Funktionen als die von mir verlinkte sehe ich auch keinen Zusatz-Nutzen - wozu also wechseln? Die Cross-Correlation wird als Herausforderung schwierig genug werden. Es ist ja komplettes Neuland für mich, ich muss mich da selber Schritt für Schritt langsam einarbeiten und hineinfinden. Bei zuviel neuen Dingen verliere ich den Überblick.

Ich habe mich inzwischen deshalb auch gegen ncurses entschieden, weil ich mich dann in dem Menü nicht mehr zurechtfinde, und außerdem sind ncurses-Fenster für andere Ausgabefunktonen nicht mehr stdio.h-kompatibel, so wie es das LXTerminal-Window ist. Nur für diese einmalige simple Auswahl 0...9 eine inkompatible Monsterlib zu installieren, die ich später nicht mehr weiter verwende, ist für mich ein unwirtschaftlicher und nicht angemessener Aufwand.

Was in 5 oder 6 Jahren mal sein wird, weiß ich ntl nicht, da kann ich durchaus so weit sein, dass ich auch möglicherweise mal openCV und ncurses verwenden könnte.

Ich brauche als gemeinsame Regie-Schnittstelle auch genau das Menü, das ich oben bereits vorprogrammiert und dir gepostet hatte.

Ich bin kein Linux-Programmierer, ich programmiere auf MSDOS- TurboC oder Arduino-IDE-Niveau, und ich verwende selber auch kein C++, sondern ausschließlich ANSI C.
Daher auch meine absolute Abneigung genüber Vektoren und strings, stattdesen: char * array[size].

Wenn mir das Programm zu kompliziert und von der Syntax her zu fremd ist, kann ich es selber später nicht mehr für meine eigenen Spracherkennungsprogramme nutzen, und wozu dann der ganze Aufwand?

Bitte bleib also bei einfachen Menü-Schnittstellen wie diesen hier (Menü-Punkt 0 für csv kann jetzt sogar komplett wegfallen)

0 Soundfile *.csv in Programm öffnen / laden \n  // csv kann jetzt sogar komplett wegfallen !

1 Soundfile *.wav in Programm öffnen / laden \n
2 Soundfile *.wav öffnen / abspielen + Plot \n
3 Sound aufnehmen per Micro / SoundCard \n
4 akt. Sound (Array im RAM) abspielen + Plot \n
5 akt. Sound optimieren (noise/cut) \n
6 akt. Sound (im RAM) als *.wav File speichern unter... \n

7 akt. Sound an FFT + Plot \n
8 akt. Sound cross correlation mit 1 wav File \n
9 akt. Sound cross correlation mit allen *.wav Files (auto) \n

und nutze bitte diese API-Schnittstellen mit dieser Syntax, wie ich sie im Prinzip bereits vor vielen Seiten gepostet hatte, nicht wesentlich anders:

a) record_sound(int32_t * array, int32_t length);
b) save_sound2wavFile(int32_t * array, FILE * fp, char * filename);  // über Zenity PopUp Window
c) FILE * fp = open_wavFile(int32_t * array, char * filename);       // über Zenity PopUp Window
d) play_soundArray(int32_t * array, int32_t length);
e) play_wavFile(char * filename);                                   // über Zenity PopUp Window
sowie
f) plotArray(int32_t * array, int32_t length, int y0);
g) optimizeArray(int32_t * array, int32_t length);
h) array2FFT(int32_t * array, int32_t length, double * fx, double * fy, int32_t FFT_length);
i) cross_corr(int32_t * array, int32_t * pattern, int32_t length);

Diese Funktionen müssen genau so in der Sound-Lib und ggf. in einer weiteren Sound-Tools-Lib genau so zur Verfügung stehen.

Nur wenn wir diese gemeinsame Menü- und API-Basis haben, kann unsere Arbeit auch später auf andere Anwendungen (z.B echte Wort-Steuerung von mobilen Robotern mit automatischer lernfähiger Spracherkennung) portiert werden.


ps,

Wenn du das LXTerminal Window neben dem openVG Window positionieren und in der Größe anpassen willst, können wir diesen Befehl verwenden:

// LXTerminal window:  pos (x,y): 520,0,  size: 320x320   
 system("wmctrl -r LXTerminal -e 0, 520,0, 320,320");