wav Dateien: Programieren von Wiedergabe und Aufnahme

[Ceos]

hatte ich schonmal erwähnt dass ihr euren Code z.B. auf Github hochladen, forken und bearbeiten bzw. synchronisieren und kommentieren könnt? Ich will nicht dass ihr eure Entwicklung dahin beschränkt oder sowas, ich hab nur das Gefühl, dass es euch wesentlich helfen könnte einfach mit der gleichen Code basis zu arbeiten und darauf dann jeweils eine eigene Menüstruktur aufzubauen

Ihr ladet einfach den Kern des Programms hoch, schön gepackt und unterteilt in Methoden und Prozeduren und dann kann jeder in seinem eigenen Fork davon das Menü implementieren wie er es wünscht
Sonst gibts irgendwann nur noch streit und die Trennung von Kern und GUI tut dem Programmierstil gut und es kann alles dokumentiert werden und wenn was schiefgeht einfach ein rollback machen

[HaWe]

wie Github aussieht, weiß ich, aber wie man damit arbeitet: kein Plan, und da will ich mich auch gar nicht erst einarbeiten müssen.

wesentlich sind im Moment nur die API-Tool-Funktionen samt Menü.

Was das Menü angeht, heißt das für mich:
ohne ncurses,

und was die API wave-Tools angeht, eben einfach so etwas ähnliches, in ANSI C (unter Zuhilfenahme von Zenity und popen(), wie ich es ja auch schon gepostet habe):

a) record_sound(int32_t * array, int32_t length);
b) save_sound2wavFile(int32_t * array, FILE * fp, char * filename); // über Zenity popen() PopUp Window
c) FILE * fp = open_wavFile(int32_t * array, char * filename); // über Zenity popen() PopUp Window
d) play_soundArray(int32_t * array, int32_t length);
e) play_wavFile(char * filename); // über Zenity popen() 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);


wenn wir uns auf diese Schnittstellen einigen können, ist doch alles prima, damit könnte ich anfangen zu arbeiten.

[hirnfrei]

Mein Problem ist folgendes.

Wie du so schön sagst, du brauchst es so und so und so. Das ich in dem Programm hier aber schon massiv von meinem eigenen Programmierstil abgewichen bin ist dir klar oder? Ich habe noch nir int32_t verwendet zum Beispiel. Ich hätte nie angefangen ein Wav File zu dekodieren. Du sagst es ja, du brauchst es so und so um in deinen Projekten damit arbeiten zu können. Ich will jetzt nicht den Egoisten raus hängen lassen, aber schonmal auf den Gedanken gekommen das ich in meinen Projekten dann wieder umstricken muss?

wenn wir uns auf diese Schnittstellen einigen können

Ist das dann geeinigt oder von deiner Seite durchgesetzt?

Ich frage deshalb weil:

e) play_wavFile(char * filename); // über Zenity popen() PopUp Window

Du willst da also eine Funktion, die von sich aus dann Zenity verwendet. Das heisst, will ich es später mal in meinem Projekt damit arbeiten muss ich den ganzen Zenity-Kram erst raus werfen. In meiner Variante wird per Menu einfach die Datei ausgewählt und dann an die Funktion übergeben. Das heisst, will ich es später mal in einem anderen Programm verwenden, eins was keine direkte Benutzerschnittstelle hat, kann ich die in dem Programm verwendete Methode zur Auswahl der Datei verwenden und die Funktion dann ungeändert einfach übernehmen, sprich einfach diasound.hpp einbinden und die Funktion benutzen. Nehmen wir mal an ich würde diese Funktion dafür benutzen wollen, eine Reihe von Dateien, welche spezifische Worte enthalten nach einander abzuspielen. Sagen wir ich habe einen Satz "Hallo Welt" den ich mittels vorgefertigten Wort-Dateien dann ausgeben möchte. Dann würde ich normalerweise ein vector mit den Dateinamen generieren und diese in einer Schleife abrufen. Das würde nicht funktionieren da ja Zenity aufgehen würde, was ich allerdings gar nicht sehen würde, wenn zB kein Monitor angeschlossen ist.

"Einigen" wir uns auf dein Modell heisst das genau genommen, es funktioniert so das du damit arbeiten kannst in deinen Projekten während ich in meinen erst Aufwand betreiben muss um die erarbeiteten Funktionen zu verwenden. Das würde ich jetzt nicht als Win-Win ansehen.

@ceos

hatte ich schonmal erwähnt dass ihr euren Code z.B. auf Github hochladen...

HaWe hat schon die Antwort geliefert, warum ich damit noch nicht gekommen bin ^^

[HaWe]

Vielleicht kann dir ja wer anderes helfen auf der Basis von C++ und ncurses, ich muss da leider passen.
Und ich kann ja auch nicht garantieren, dass es dann später mit ANSI C und Zenity klappt.

[hirnfrei]

Wir können es ja ganz schlau machen. Da ich die Funktionen ja sowieso so aufbaue, dass sie auch in anderen Programmen genutzt werden können machen wir es doch ganz einfach. Wir deklarieren eine globale Variable. Steht die auf 0 wird mein Menü gestertet, bei 1 deins. Wenn das okay für dich ist kann ich dir zeigen wie ich das meine.

[peterfido]

Hallo,

soweit ich das verstanden habe, sollte man ncurses ODER die Standardausgaben nutzen. Das würde dann bald doppelten Code bei den Ausgaben bedeuten, es sei denn, Du kannst da per DEFINE was tricksen.
Zenity geht nur mit einem Fenstermanager. Soll es eine reine 'Konsolen-Anwendung' werden, dann muss eine Alternative her.

Ihr könntet auch gemeinsam genutzten Code in eine INCLUDE auslagern und die Oberfläche jeder für sich bauen.

Ein WAV-Export / -Import hätte den Vorteil, dass man die Dateien schnell mal auf 'Profisoftware' durch ein paar Filter jagen kann. Hinterher könnte man vor Filter mit nach Filter im neuen Format vergleichen / analysieren, um da was nachzubauen. Spracherkennung ist nicht ganz ohne, vor Allem, wenn unterschiedliche Sprecher erkannt und unter schwierigen Bedingen zuverlässig erkannt werden soll. Das schafft, wie bereits erwähnt, nicht mal Google in der Cloud zuverlässig. Euer Vorteil ist, dass es ein begrenzter Wortschatz ist.

Das sind alles nur Ideen. Ich selbst benötige ein solches Programm nicht. Verfolge jedoch Euren Fortschritt.

[hirnfrei]

So war es gemeint mit der Include. Ich nutze meine, HaWe seine. Bzw. damit man nicht zu viel im Code ändern muss einfach eine Variable ändern so das das Programm weiss welche Variante genutzt wird und auch nur dessen Output dann angezeigt wird. Ist keine schwere Aufgabe.

Und ja Zenity will meines Wissens nach GTK. zumindest basiert meines Wissens nach LXDE auch zum Teil darauf. ncurse hingegen läuft ganz ohne X.

Und noch ist der Wortschatz begrenzt. Zumindest auf meiner Seite darf das auf Dauer durchaus mehr werden. Wenn es richtig gut läuft können es dann auch ganze Sätze werden. Dann ist eine 100%ige Übereinstimmung der Wörter auch nicht mehr ganz so wichtig, da das Programm dann mehr oder minder "versteht", dass das was da angekommen ist nicht wirklich sinnvoll ist und prüft was da eher Sinn machen würde. Funktioniert im Terminal eigentlich schon ganz gut. Da kann man auch Wörter nicht ganz richtig schreiben, Buchstaben verdrehen usw. Aber Eins nach dem Anderen. Im aller Schlimmsten Fall (wenn der Raspi das von der Leistung her nicht schaffen sollte) dann wird da eben doch mit Google gearbeitet werden müssen. Fände ich schade, aber man ist ja flexibel.

[HaWe]

hallo,
von Anfang an doppelten Code halte ich für übertrieben - aber: OK, machbar.

Wesentlich sind für mich (auf die Gefahr, dass ich mich zum zig-sten Male wiederhole):

keine C++ Objekte, streams, Vectoren, strings
keine Installation von ncurses
reiner ANSI C Code

API Funktionen (ziemlich genau so, ggf. die Parameter ein wenig anders gesetzt):
a) record_sound(int32_t * array, int32_t length);
b) save_sound2wavFile(int32_t * array, FILE * fp, char * filename); // über Zenity popen() PopUp Window
c) FILE * fp = open_wavFile(int32_t * array, char * filename); // über Zenity popen() PopUp Window
d) play_soundArray(int32_t * array, int32_t length);
e) play_wavFile(char * filename); // über Zenity popen() PopUp Window
sowie
f) plotArray(int32_t * array, int32_t length, int y0);
g) optimizeArray(int32_t * array, int32_t length);

Menü im normalen LXTerminal, das genau diese (!) API Funktionen aufruft,
unter Zuhilfenahme von PopUpWindows für OpenFileDialog/SaveFileDialog/popen()+Zenity etc.

Dateiformat für sound: *.wav zum Speichern und Laden

Deine Erwartungen bezüglich der Leistungsfähigkeit muss ich allerdings etwas dämpfen:
Spracherkennung von Sätzen wird niemals funktionieren,
von gesprochenen Wörtern wird grundsätzlich immer nur das nach FFT-CC am besten passendste Muster ausgewählt (egal wie weit man daneben liegt),
keine Künstliche Intelligenz,
keine Lernfähigkeit wie beim Neuronalen Netz,
ausschließlich Trainierbarkeit der Erkennungsfähigkeit / Selektivität / Spezifität durch möglichst gute Frequenzfilter.

Es wird so ähnlich sein wie in dem bereits von mir verlinkten Video auf der Basis von Lego Mindstorms NXT, NXC Code, nur dass man wschl weniger schreien muss und es etwas schneller geht.

Dafür würde ich jetzt nicht zuviel bereits im Vorfeld in verschiedene Menüs investieren.

[hirnfrei]

Das Menü kannst du selber bauen oder?

Denkst du mit der Methode wäre es Möglich unterschiedliche Stimmen identifizieren zu können?

[HaWe]

wenn alle API Funktionen genau so existieren, wie oben beschrieben (inkl. popen()/Zenity), dann ist das Menü kein Problem



was die Worterkennung leisten wird, weiß ich nicht, FFT-CC ist Neuland für mich.