Hi Albert,
Thanks for trying Recognito!
I'd guess the problem lies in the conversion from wav int to double[]: -1 and +1 are the boundary values, if you have values outside of that range, they'll just mess the algorithm.
There is no file format that would encode the samples in a double[]: it takes way more space and thus is not efficient for storage purpose.
It's because the algorithms for signal analysis rely on trigonometry and radians that this conversion is mandatory.
I'd recommend looking at the method readAudioInputStream in FileHelper.java in the utils package which does the conversion and implement the same for the android file API.
The numbers should then match exactly and the normalizer will be just as happy as it was when run on your PC :-)
One thing to note, I'm using the jdk to convert the file encoding to (same sample rate, 16bit, mono, signed int, big endian notation)
Since I guess the Android platform doesn't have an equivalent to convert file formats, I'd force the use of a wav file that has this kind of encoding and throw unsupported file format if that's not the case.
Don't try to implement a converter yourself, you'll end up banging your head against the walls :-)
Why, oh, why did they allow so many different encodings for digital audio...
Using Marf, you'll hit the same problems as it's also relying on trigonometry formulas with radians and values between -1 and 1.
HTH
Cheers
Amaury
PS: Please consider providing the code back to the community, this is something that'd be useful for other users and would help me greatly in making Recognito Android compatible ;-)
I guess i'd abstract out common code from Recognito.java and create a new Recognito4A (Recognito 4 Android) which supports Android file types