View Full Version : [Frage] samples mischen
hi, irgendwie hab ich noch immer Probleme beim Samplemischen, ich hol mit meine Überlagerungssamples via PullStramBuffer, das ist kein Problem, ich bin mir nur nicht sicher, ob ich das mischen überhaupt richtig mach (nirgendwo wirklich eine Erklärung :(
meine Formate müssten eigentlich auch stimmen, woran kanns noch liegen? irgendwer eine Idee? Dem Gewinner winkt ein Freibier ;)
danke
Manfred
hier das Stück von meiner Process methode:
...
try
{
UBahnData = UBahnStream1.read(ubahnArray,0,inLength);
}
catch (Exception e)
{
e.printStackTrace();
}
for (int i=0; i < samplesNumber;i++)
{
if (UBahnData > 0)
{
neuTempH = ubahnArray[inOffset] & 0xff;
tempH = inData[inOffset ++] & 0xff;
neuTempL = ubahnArray[inOffset] & 0xff;
tempL = inData[inOffset ++] & 0xff;
}
else
{
tempH = inData[inOffset ++] & 0xff;
tempL = inData[inOffset ++] & 0xff;
}
short neuessample = (short)(((neuTempH<<8)|neuTempL)/2);
short sample = (short)(((tempH << 8) | tempL)/2);
sample = (short)((short)(sample)+(short)(neuessample));
outData[j ++]=(byte)(sample >> 8);
outData[j ++]=(byte)(sample & 0xff);
}
...
neuTempH = ubahnArray[inOffset] & 0xff;
ich würd an deiner stelle, für das neuTempH/neuTempL einen eigenen offset evrwenden, ich hab den nämlich nicht wie das inOffset mit 0 initialisiert, sondern mit 1. schau mal ob das funkt
da hst du das ++ vergessen,
hi bimbo, danke für den Tip, aber wenn ich ein ubahnOffset mach, das mit 1 initialisier und dann immer ++ rechne, bekomm ich ein arrayoutofboundsexception, warum auch immer (obwohls mit inOffset geht), und ad ++ vergessen: ich hab mir gedacht, dass ich ja nur eins weiter gehen will beim tempH und tempL, und ich dadurch ja eh schon auch beim neutempH usw weitergeh, sonst würd ich ja immer eins von tempH und tempL überspringen?!
majorkoenig
25-01-2003, 23:14
hast du schon den fehler gefunden?
Ich habe hierbei auch sehr sehr viele probs.
Ich kann nicht einmal einfach meine die Buffer von meiner Pulldatasourcequelle mit meinen Inpuffern vertauschen.
Außerdem sollten (wenn die beiden Files gleich sind) ja eigentlich die Werte in den Buffern auch gleich sein oder ?
majorkoenig
26-01-2003, 02:45
also bei mir liegts anscheinend an irgendwie an dem format das ich einlese
kennt jemand ein programm mit welchem man die attribute einer audiodatei sieht?
spiels in einem processor ab, hol dir zuvor die TrackControl für den audiotrack und daraus das Format -> gib es einfach mittels System.out.println() aus...
ich komm beim mischen auch nicht weiter, selbst wenn ich mir die Daten nur aus aus der PullDatasource hole, kann ich sie nicht abspieln, wenn ich die anderen Daten wegschmeiß
die Formate stimmen allerdings überein, daran kanns nicht liegen...hmm schön langsam wirds knapp, hoffentlich komm ich noch drauf
majorkoenig
29-01-2003, 02:18
@moaxl
bei mir lags an den falschen inputformaten da hat mir den bimbo sein denkanstoß geholfen
und die getsupportedinputformats() methode musste ich halt auch noch korregieren
EEEENDLICH, danke mal für all die Hilfe, aber ihr seids alle daneben gelegen und habt's mich für zu intelligent eingschätzt, hehehe
ersten ghört der UBahnOffset mit 0 initialisiert, danke bimbo
und dann, und bis ich da draufgekommen war, obwohls eh so offensichtlich war: die samples ghörn natürlich mit 0.5F multipliziert, und auf das F kommt's an, sonst rauschts (eigentlich stehts eh im Gaineffect, bin scheinbar viel zu blind für diese Welt)
danke nochmal
und viel Glück in der mm1vo
manfred
hmm, interessant, aber verstehen tu ich es nicht: ob du mit 0.5 oder mit 0.5F multiplizierst, sollte keinen gravierenden Unterschied machen, da 0.5 von Java als double und 0.5F halt als float intepretiert wird -> Ergebnis zu short gecastet sollte eigentlich immer dasselbe sein und schlimmstenfalls +-1 daneben liegen -> dann täts aber niemals rauschen...
btw. die casts bei
sample = (short)((short)sample+(short)neusample));
kannst du dir sparen, sample und neusample sind sowieso schon shorts, also tuts sample += neusample hier auch...
vBulletin® v3.7.1, Copyright ©2000-2008, Jelsoft Enterprises Ltd.