gings denn vorher mit playCaptured?
zum Daten-Record und Aufbereiten -
vielleicht hast du mich falsch verstanden, und ich bin ja nicht auf denem Programmier-Level:
Ich hatte mir vorgestellt, dass anstelle von
string oder char* wasauchimmer
jetzt
uint8_t (!!) wasauchimmer (nicht int32_t !!)
verwendet werden soll, aber mit festen array Grenzen;
das gleiche gilt für vector<int> input etc,
stattdesen
int32_t input[FESTE_GROESSE]
Das hätte den Sinn, dass man es immer mit identisch großen records zu run hat, was das Aufbereiten der Daten vereinfacht.
Wenn du lieber erst mit Vektoren variabler Größe arbeitest, auch ok, dann muss es im nächsten Schritt eben in arrays von konstanter Größe verfrachtet werden, und zwar nur MONO (1 Kanal).
Weil es nur MONO sein darf, muss man wissen, welche der ganzen Bytes genau die richtigen Töne darstellen, ohne die andere Spur mitzukopieren.
Die konstante Größe ist wichtig, denn wie du sicher weißt, arbeitet ja die FFT nur mit arrays, die eine Länge haben, die sich als 2^n (hier: 2^16 == 65536) darstellen lässt.
Für die Cross Correlation darf dafür nur höchstens die erste Hälfte mit Daten gefüllt sein, mindestens die 2. Hälfte ausschließlich mit Nullen.
Daher bleibt für Daten dann maximal ((2^n)/2) -1 (== 2^15 -1 == 32767 ) übrig, und das muss die exakte Länge der int32-MONO-Records sein, die man erst cutted und filtert und dann (zu floats konvertiert) der FFT übergibt.
Wann du also anfängst mit fixen arrays, ist prinzipiell egal, aber Vektoren taugen dazu nicht, und daher muss man vektoren auch erst wieder in fixe arrays umwandeln, bevor man mit der eigentlichen Arbeit anfangen kann, und daher: je früher, je besser.
Ist dir klar, wie ich das meine?
Zitieren
Lesezeichen