Wav Dateien und kein Ende

[hirnfrei]

Also der Code um die Datei zu lesen und zu dekodieren sieht so aus:

int32_t *loadWave(char *waveDatei, FILE_head& head, FORMAT &format, CHUNK_head &chead)
{
	register snd_pcm_uframes_t count, frames;	
	
	int datei;
	
	int32_t *waveBuffer;

	datei = open(waveDatei, 00);

	if(datei)
	{
		read(datei, &head, sizeof(FILE_head));

		read(datei, &chead, sizeof(CHUNK_head));

		read(datei, &format, sizeof(FORMAT));

		waveBuffer = (int32_t *) malloc(head.Length);
		
		head.Length = read(datei, waveBuffer, head.Length) - 1;

		close(datei);
		
		return waveBuffer;
	}
	
	return (int32_t *) -1;
}

[HaWe]

ich würde erstmal alles blind aus dem File byte-weise in einen byte-array einlesen, und dann erst später den Array nach Header und Daten zerpflücken, dann die wav-Daten isolieren / separieren und in einen int32_t array umkopieren:

#include <stdio.h>

long  read_wavfile(FILE * fp)
{
  uint8_t   c, cbuf[SHRT_MAX*4];  // byte array, oversized
  long      n=0;

  fp = fopen ("myfile.wav","r");  // oder über popen() und Zenity
  do {    
      cbuf[n++] = c = fgetc(fp);
    } while ( (c != EOF) && (n<SHRT_MAX*4 -1) );
  close(fp);
  return n;
}

jetzt Header ignorieren, dann Anfang der wav-Daten suchen (Position x), und dann Daten ab x in den int32_t input-Array rüberkopieren (ab Pos. 0).


(nur als grobe Idee)

[hirnfrei]

So ähnlich hatte ich es schon und hatte dann am Ende den selben Effekt.

while ( (c != EOF) && (n<SHRT_MAX*4 -1) );

Dieser Teil lässt mich schliessen das es dir in erster Linie um selbst erstellte Wave-Dateien geht?

[HaWe]

eigentlich nicht, denn dann würde sogar ein kleinerer cbuf array reichen - so hätte man aber sogar noch reichlich Spielraum für Stereo und höhere Sample-Raten.


edit:
Längere Arrays dürfen es aber dann wirklich nicht sein, denn es wird ja später auf SHRT_MAX Daten-Werte zurückgeschnitten.

[hirnfrei]

Dann wird es noch ein wenig dauern befürchte ich

[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