Wav Dateien und kein Ende

[HaWe]

Ich würde bei meinem ANSI-C-Code anfangen - so komplett falsch wird der möglicherweise gar nicht sein.
Und ANSI C ist ja eh das Ziel des ganzen.

[hirnfrei]

Dein Ziel .

Wie gesagt, so hatte ich es ja schon und genau genommen macht mein Code es nicht wirklich anders, nur das er gleich die Teile nimmt die Header sind.

Ich bin da aufgeschlossen, Lass uns doch parallel arbeiten. Plotten kannst du und über die Soundkarte ausgeben geht mit meiner playCaptured Funktion ja auch. Vielleicht kriegst du es mit deiner Methode schneller hin wie ich. Damit würden wir zwei Ansätze verfolgen, doppelte Chance auf Erfolg ^^.

[botty]

Hallo,
ich mag ja nicht Eure Bemühungen hier anzweifeln doch gibt es zum Lesen von Sounddateien (inkl. WAV) die libsnfile-Bibliothek. Die ist in C implementiert nur weiß ich nicht ob die auch als Paket für den RPI gibt. Wäre vielleicht mal einen Blick Wert?
https://github.com/erikd/libsndfile
http://www.mega-nerd.com/

Ansonsten fallen mir folgende Dinge auf

Negative Zeiger gibt es in C nicht,

return (int32_t*) -1;

führt sicher zu Problemen!

Dann frag ich mich (weil ich selbst keinen RPI mein Eigenen nennen kann) ob die Byte-Order der Felder korrekt ist?
Du ließt einfach die Bytes mit dem read() ein. Wenn der Cortex-A nicht in LSB die Daten ablegt, wie sie in der WAV stehen, dann kann da nix Richtiges bei raus kommen.

Warum ziehst Du beim letzten read() einfach ein Byte in der Länge ab? Das sind doch keine Strings, die Du da einließt.

Ich gehe davon aus das in Deiner Implementierung jeder Rückgabewert der read()-'s geprüft wird und Du das der Übersicht halber hier weg gelassen hast?


Ansonsten frage ich mich warum ihr intern nicht mit Fließkommazahlen arbeiten wollt? Jede DAW oder Audiosoftware benutzt die.
Für Gesang bzw. Spache benutzt man immer nur Mono-Aufnahmen (einzige Ausnahme die ich kenne sind Chor-Aufnahmen). Das spart nicht nur Platz sondern Rechenzeit und vor alllem für Eure Correlation Fehlerquellen.

Grüße

Chris

[hirnfrei]

ich mag ja nicht Eure Bemühungen hier anzweifeln doch gibt es zum Lesen von Sounddateien (inkl. WAV) die libsnfile-Bibliothek. Die ist in C implementiert nur weiß ich nicht ob die auch als Paket für den RPI gibt. Wäre vielleicht mal einen Blick Wert?

So etwas habe ich schon gesucht! Schaue ich mir auf JEDEN FALL an!

Negative Zeiger gibt es in C nicht,

In C++ habe ich da weniger Probleme mit. Ist aber keine schöne Nummer die ich da mache, ist auch nur ein Provisorium.

Wenn der Cortex-A nicht in LSB die Daten ablegt, wie sie in der WAV stehen, dann kann da nix Richtiges bei raus kommen.

Cortex-A? LSB? Hilfe?

Ich muss aber dazu sagen, wenn ich das was ich da einlese, genau so wie ich es einlese, sofort ausgeben lasse funktioniert es einwandfrei. Also so falsch kann es eigentlich nicht sein.

Warum ziehst Du beim letzten read() einfach ein Byte in der Länge ab? Das sind doch keine Strings, die Du da einließt.

Autsch, damit hatte ich nur was versucht. Das sollte schon längst wieder weg sein .

Ansonsten frage ich mich warum ihr intern nicht mit Fließkommazahlen arbeiten wollt? Jede DAW oder Audiosoftware benutzt die.
Für Gesang bzw. Spache benutzt man immer nur Mono-Aufnahmen (einzige Ausnahme die ich kenne sind Chor-Aufnahmen). Das spart nicht nur Platz sondern Rechenzeit und vor alllem für Eure Correlation Fehlerquellen.

Anstatt int32_t?

Frag mich mal. Das ist das erste Mal das ich überhaupt mit Audio arbeite.

- - - Aktualisiert - - -

libsndfile-dev kann man einfach mit apt-get installieren. Oder auch über die Tools die beim Raspi dabei sind, wenn man es nicht über den Terminal machen will. Ich schaue mir mal an wie man damit Wav liesst, ich denke das ist die einfachste Variante.

Danke für den Tipp!

[Siro]

Du must natürlich, nach dem Du die eigentlichen Audiodaten geladen hast, diese auch richtig bearbeiten.
Die Daten sind ja meist im Interleaved abgelegt (bei stereo), ein Sample Linker Kanal, dann ein Sample rechter Kanal
oder umgekehrt. Zudem können diese 8 Bit 16 Bit 24 ... Bit Format haben, float gibt es glaube ich auch.
Deshalb wäre der ertse Versuch einfach mal einen Kanal totzuschalten, indem Du in deinem gelesenen Puffer
diese Werte auf Null setzt. Dann weist Du ob deine Auswertung erstmal überhaupt richtig ist, wenn Du das
wieder abspielst. Dann kannst Du weiter Versuche starten für die gewünschten Manipulationen, wobei
natürlich immer auch die Samplerate bedacht werden muss bei Filtern ect.

Am besten wäre sicher ein Strukturzeiger auf einen Sample
struct
{
int left;
int right;
} sample;

dann ein Array mit dieser struktur anlegen, dann kann man auf die Samples mit

for (i = 0; i < BufferSize) Sample[i].left = 0;

oder ähnlich zugreifen.

Die meisten CD Samples sind ja im 16 Bit Format abgelegt.
Siro

[HaWe]

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.

[hirnfrei]

Na das spielt doch sndfile voll in die Hände. Die Lib hat nämlich eine Funktion um die Daten von Sound Dateien direkt in Double zu lesen. Dann muss ich nicht anfangen rum zu konvertieren! Sehr gut!

Die Lib ist übrigens echt cool und funktioniert bisher schon sehr gut! Muss nur noch schauen wie ich das so an playCapture sende das es auch korrekt abgespielt wird.

[HaWe]

play_wavFile und play_soundArray sind 2 verschiedene Funktionen, die nichts miteinander zu tun haben!

sie dürfen auch keine identischen internen Puffer-Arrays verwenden!

Nur die Funktion
get_wavFileData
liest die wav-File Daten in den internen input Puffer ein
(so wie es auch die Micro-Aufnahme per
record_sound
macht)


die hatten wir bisher noch nicht definiert, da das Öffnen von *.wav über Zenity noch nicht geklappt hat -
sie verwendet die Funktion
c) FILE * fp = open_wavFile(int32_t * array, char * filename); // über Zenity popen() PopUp Window,
extrahiert die reinen sound Daten und kopiert sie in den input Puffer zu Weiterverarbeitung


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

[hirnfrei]

Jetzt behalt doch mal die Nerven! Hier gehts nur darum ein Wave zu laden und die Daten in ein Array zu bekommen das ich auch wieder über die Soundkarte abspielen kann. Dann spielt es keine Rolle wie die Funktion heisst nur was sie macht.

[HaWe]

was heißt hier "behalt mal die Nerven" und "es ist egal wie sie heißt"?

Ich behalte die Nerven, ich will nur vermeiden, dass du dir unnötige (falsche) Arbeit macht.

Die Namen allerdings sind wichtig, denn ich brauche die vereinbarten Namen der API-Funktionen samt ihrer definierten Syntax, so wie ich sie definiert habe, nicht immer irgendwas anderes. Das ist unser Arbeitsstandard mit der gemeinsam genutzen Schnittstelle.

Je früher du dich an die API-Schnitstellendefinitionen hältst, desto besser.
Lies ggf nochmal die letzten 20 Seiten im wav-Topic, was ich bereits dazu geschrieben und an Code auch gepostet habe - ich habe den Eindruck, du hast das alles nicht exakt zur Kenntnis genommen.