wav Dateien: Programieren von Wiedergabe und Aufnahme

[HaWe]

alles klar!
zum hiesigen Thema *.wav files spielen/lesen/speichern fehlt ja dann nur noch, wie man einen Array als kompletten *.wav lädt und speichert (beides mit Zenity),
im Gegensatz zu Menüpunkt
als *.csv speichern
müsste dann dafür ja nur zusätzlich noch der wav Header davor.


Und dann kommt so langsam der Teil mit der FFT - hier ist ein Link zur Einführung, samt FFT Code:

http://paulbourke.net/miscellaneous/dft/

(für unsere Anwendung: int64_t statt long! )



- - - Aktualisiert - - -

noch eine Bitte:

könntest du bitte nochmal die aktuelle Version deiner alsa-lib
"diaSound.hpp"
posten, ohne Verwendung von "string" in den Funktionen, stattdessen ausschließlich mit " char * " falls möglich ?

[hirnfrei]

Ich schau mal wie ich das umgebaut kriege. String ist doch schon ne deutlich einfachere Sache wie char *. Keine Speicherreservierung usw. Aber ich schaue.

Ich würde sagen, anstelle von zenity verwenden wir ncurse. Sobald ich am Raspi bin (jetzt wieder mit ssh ^^) mach ich mich dran.

[HaWe]

ok -
nur wenn du string nimmst, müssen wir ihn sowieso erst in einen Array mit fester Dimension [SHRT_MAX] umkopieren, bevor wir ihn verarbeiten können.
Deine Funktionen bleiben dann aber evtl sogar flexibler.

Nachdem die ersten wav-Tests ja erfolgreich abgeschlossen sind, brauchen wir in Zukunft nur noch mit array input[SHRT_MAX] zu arbeiten, und der zusätzliche array wavebuffer[SHRT_MAX] wird nur noch für wenige Zwischenschritte hilfsweise benötigt.

Die wichtigsten nächsten Regie-Funktionen wären also also:



Menü (1) wav file lesen
*.wav-file ---> (über OpenFileDialog) --> string variabel --> fester array input[SHRT_MAX] mit wav-Header
edit: --> wav-Header herausschneiden (--> array wavebuffer[SHRT_MAX] als Puffer),
--> array input[SHRT_MAX]==reine sound-data zur Weiterverarbeitung


Menü (2) wav file abspielen
*.wav-file ---> (über OpenFileDialog) --> ohne Veränderung direkt über SoundCard abspielen


Menü (3) per Micro aufnehmen
Micro --> direkt --> fester array input[SHRT_MAX]==reine sound-data zur Weiterverarbeitung



Menü (4) akt. Sound (Array im RAM) abspielen + Plot
array input[SHRT_MAX]==reine sound-data direkt über Soundcard abspielen



Menü (5) optimieren
array input[SHRT_MAX] --> noise glätten --> def.Wortgrenzen --> Wort rausschneiden und ganz an den Anfang setzen
(--> array wavebuffer[SHRT_MAX] als Puffer), dann wieder zurückkopieren in
--> array input[SHRT_MAX]==reine sound-data zur Weiterverarbeitung


Menü (6) Sound als *.wav File speichern unter:
array wavebuffer[SHRT_MAX]: an den Anfang den wav-Header, dann direkt anschließend input[SHRT_MAX]
--> wavebuffer[SHRT_MAX] an SaveFileDialog ---> neuen Speichernamen eingeben
--> als *.wav file speichern


Damit wäre es sofort auch am einfachsten für dich, Wortmuster für den FFT-Vergleich aufzunehmen (Micro), zu bearbeiten, und neu zu speichern. Oder bereits vorhandene *.wav Dateien zu öffnen, nachzubearbeiten oder zu überschreiben.



0 Soundfile *.csv in Programm öffnen / laden (FileOpenDialog)
1 Soundfile *.wav in Programm öffnen / laden (FileOpenDialog)
2 Soundfile *.wav öffnen / abspielen + Plot (FileOpenDialog)
3 Sound aufnehmen per Micro / SoundCard
4 akt. Sound (Array im RAM) abspielen + Plot
5 akt. Sound optimieren (noise/cut)
6 akt. Sound (im RAM) als *.wav File speichern unter... (FileSaveDialog)
7 akt. Sound an FFT + Plot
8 akt. Sound cross correlation mit 1 wav File (FileOpenDialog)
9 akt. Sound cross correlation mit allen *.wav Files (auto)

[hirnfrei]

Was machst du nur mit mir? Ich wollte doch nur eine Spracherkennung und bastele jetzt wie ein kleines Kind zu Weihnachten ein altes DOS Menü nach ^^. Es geht voran! Ich habs auch bald. Ein Bild häng ich mal dran.

[HaWe]

für die Spracherkennung brauchst du doch jede Menge Vergleichsdaten, und die müssen nunmal möglichst optimal sein.
Die FFT kann ja auch nur vergleichen, was in etwa vergleichbar ist.
Schlechte Basisdaten => falsche Ergebnisse.

Da du ja deine Vergleichsdatenbank erstmal selber per Micro aufnehmen und dann analysieren und optimieren musst, und das Wort für Wort mit wiederkehrenden Algorithmen, alle nach dem selben Muster erstellt, bietet sich doch ein Menü mit diesen festen Regiefunktionen geradezu an, oder nicht?

[hirnfrei]

Ich sage es mal so. Als jemand der gerne im Terminal arbeitet wäre meine Antwort eigentlich

Nö

da sich das Menü sehr einfach durch Startparameter umgehen lässt. Wie der Zufall aber nun mal so spielt musste ich, um mein System auf dem neuen Motherboard wieder ins laufen zu bringen, eine RescueCD verwenden. Da ich keine hatte und CDs ja echt out sind, habe ich das Ganze natürlich auf einen USB-Stick gemacht. Das mache ich normalerweise mit dd, wo ich dann einfach das iso auf den Stick schiebe. Aber bei der war ein install dabei. Okay versuche ich mal. Schau an, da war ein Menü im Terminal und sofort musste ich an dich denken. Mal kurz nach geforscht wie das erstellt wurde und so auf Ncurses gestolpert.

Und das hat mich so gereizt das ich da jetzt am bauen bin. So kommt die Jungfrau zum Kind, nichwahr?

Ah um das zu compilieren brauchst du libncurses-dev (glaube ich). Kannst ja mal im Packetmanager schauen. In geany muss noch

-lncurses

dazu.

[HaWe]

ogott - bitte nicht ncurses! O.o

Zenity ist doch perfekt!

und das Menü sind doch nur 10 zeilen, zur Abfrage einfach auf Tasteneingabe mit Enter warten!

Und ich will doch nicht jedesmal das Programm neu starten mit verschiedenen Parametern, für einfache wiederkehrende Funktionen - viel zu viel Aufwand und viel zu unflexibel !
wav sound bearbeiten muss interaktiv im Programm selber möglich sein!