everyone, I am new for android. Now, I am making an android app and I will record a file after playing the file and my own voice. However, there could be some noise in my wav file. Are there some library I can use for removing noise for my app ?
There are different kinds of noise, and how you get rid of it depends. There is no "magic bullet".
To filter out certain frequencies, you can apply EQ. Roughly speaking, the parts of the signal necessary for clear understanding of speech fall in the range from 300 Hz - 3000 Hz. You can use EQ to eliminate everything below 300 Hz and above 3000 Hz. There are java libraries for this in JSyn, and processing.
If your speech and noise occupy the same frequency bands, the problem becomes more difficult. There are a variety of techniques, generally under the heading of "broadband noise reduction". I'm not aware of any java library that does this at all, much less well, but you could do it in native code. I've never tried it, but sox offers a "noisered" plugin that you could access from libsox.
Related
I am using noise meter to read noise in decibels. When I run the app it is recording almost 120 readings per second. I don't want those many recordings. Is there any way to specify that I want only one or two recordings per second like that. Thanks in advance. noise_meter package.
I am using code from git hub which is already written using noise_meter github repo noise_meter example
I tried to calculate no. of samples using sample rate which is 40100 in the package. but I can't understand it.
As you see in the source code , audio streamer uses a fixed size buffer of a new thousand and an audio sample rate of 41000, and includes this comment Uses a buffer array of size 512. Whenever buffer is full, the content is sent to Flutter. So, small audio blocks will arrive at the consumer frequently (as you might expect from a streamer). It doesn't seem possible to adjust this.
The noise meter package simply takes each block of audio and calculates the noise level, so the rate of arrival of those is exactly the same as rate of arrival of audio blocks from the underlying package.
Given the simplicity of the noise meter calculation, you could replace it with your own code directly on top of audio streamer. You just need to collect multiple blocks of audio together before performing the simple decibel calculation.
Alternatively you could simply discard N out of each N+1 samples.
I really fail at FFT and now I'm in need to communicate from the headphone jack of my Android to the Arduino there's currently a library for Arduino (talks about it in the blog post Real-time spectrum analyzer powered by Arduino) and one for Android too!
How should I start? How should I build audio signals which ultimately can be turned into FFTs and the Arduino can analyse the same using the library and I can actuate anything?
You are asking a very fuzzy question: "How should I build audio signals which ultimately can be turned into FFTs and the Arduino can analyse the same using the library and I can actuate anything?". I am going to help you think through the problem - asking yourself the right questions is essential to get any answers.
Presumably, your audio signals are "coming from somewhere" - i.e. they are sound. This means that you need to convert them into a stream of numbers first.
problem #1: converting audio signal into a stream of numbers
This breaks down into three separate sub problems:
Getting the signal to the right amplitude
Choosing the sampling rate needed
Digitizing and storing the data for later processing
Items (1) and (3) are related, since you need to know how you are going to digitize the signal before you can choose the right amplitude. For example, if you have a microphone as your sound input source, you will need to amplify the signal (and maybe add some automatic gain control) before feeding it into an ADC (analog to digital converter) that has a 5 V input range, since the microphone may have an output in the mV range. Without more information about the hardware you are using, there's not a lot to add here. It sounds from your tag that you are trying to do that inside an Android device - in which case I wonder how you intend to move the digital signal to the Arduino (over USB?).
The second point, "choosing the sampling rate", is actually very important. A sound signal contains many different frequencies - think of them as keys on the piano. In order to detect a high frequency, you need to sample the signal "faster than it is changing". There is a formal theorem called "Nyquist's Theorem" that states that you have to sample at 2x the highest frequency that is present in your signal. Note - it's not just "that you are interested in", but "that is present". If you sample a high frequency signal with a low frequency sample clock, it will appear "aliased" - it wil show up in your output as something completely different. So before you digitize a signal you have to decide what the frequencies of interest are, and remove all higher frequencies with a filter. Let's say you are interested in frequencies up to 500 Hz (about 1 octave above middle C on a piano). To give your filter a chance to work, you might choose to cut off all frequencies above 1 kHz (filters "roll off" - i.e. they increase in strength over a range of frequencies), and would sample at 2 kHz. This means you get 2000 samples per second, and you need to figure out where to put them on your Arduino (memory fills up quickly on the little board.)
Problem #2: analyzing the signal
Assuming that you have somehow captured a digital signal, your next task is analyzing it. The FFT is basicaly some clever math that tells you, for a given sound sample, "what keys on the piano were hit, and how hard". It breaks the sound signal into a series of frequency "bins", and determines how much energy is in each bin (it also computes the phase, but let's keep it simple). So if the input of a FFT algorithm is a sound sample, the output is an array of values telling you what frequencies were present in the signal. This is approximate, since it will find the "nearest bin". Sticking with the same analogy - if you were hitting a piano that's out of tune, the algorithm won't return "out of tune", but rather "a bit of C, and a bit of C sharp", since it cannot actually measure anything in between. The accuracy of an FFT is determined by the sampling frequency (which gives you the upper limit on the frequency you can detect) and the sample length: the longer you "listen" so the sample, the more subtle the differences you can "hear". So you have another trade-off to consider: if your audio signal changes rapidly, you have to sample for a short time (to capture the quick changes); but if you need an accurate frequency, you have to sample for a long time. For example if you are writing a Morse decoder, your sampling has to be short compared to a pause between "dits" and "dashes" - or they will slur together. Figuring out that a morse tone is present is pretty easy though, since there will be a single tone (one bin in the FFT) that is much larger than the others.
Exactly how you implement these things depends on your application. The third step, "doing something with it", requires you to decide what is a meaningful signal. Again, if you are making a Morse decoder, you would perhaps turn an LED ON when a single tone is present (one or two bins in the FFT have much bigger value than the mean of the others), and OFF when it is not (all noise - lots of bins with approximately the same size). But without a LOT more information from you, there's not much more one can say to help you.
You might learn a lot from reading the following articles:
http://www.arduinoos.com/2010/10/sound-capture/
http://www.arduinoos.com/2010/10/fast-fourier-transform-fft/
http://interface.khm.de/index.php/lab/experiments/frequency-measurement-library/
I'm exploring voice recognition and DSP, and so I would like to implement a simple sound frequency analyzer on my smartphone (I have both an iPhone and a Samsung Nexus S running Android). I have done basic DSP in Matlab previously.
From my understanding, I need to perform an FFT to get the fundamental frequencies of a signal.
So now, I would like to sample the microphone at 44100 Hz. If I use a sliding window of sample size 512 with 50% overlap, that means I need to do an FFT every 256 samples, or 0.00580 seconds.
That rate seems really high, particularly if I program in Java for Android. Will my smartphone be able to handle that speed? I am aware that you can program in C/C++ on Android, but I would like to keep it with Java for the time being.
Performing a real-to-complex FFT requires ~5/2 n lg n floating-point operations (additions and multiplications). In your case, n=512, so:
flops per fft ~= (5/2) * 512 * 9 = 11520
So 172 ffts per second requires about 2 million floating-point operations per second. That sounds like a lot, but it really isn't that many. The hardware of a typical armv7-class smartphone is capable of hundreds of millions or billions of floating-point operations per second.
Note however that you will want to have a carefully-written high-performance FFT; poorly written FFTs are notoriously inefficient. On the iPhone, you can use the Accelerate framework (built right into the OS, and available in the SDK), which provides a nice set of FFT functions; I'm not sure what's available on Android.
For the iPhone, the Accelerate framework for iOS can do all the FFTs you specify using on the order of 1% of CPU time (exact percentage depending on device model and FFT data types).
For Android, you might strongly want to consider using an NDK native library for processor intensive numerical calculations.
Also note that an FFT will give you the peak frequencies, which will not necessarily include the fundamental or voice pitch frequency.
ADDED: This Java benchmark web page suggests that Android phones are capable of in the range of 5 to over 50 MFlops using Java for well written matrix math. A well written FFT should fall around roughly the same performance range in MFlops. #Stephan Cannon posted that on the order of 2 MFlops might be required for your spec.
Your Android device will be able to handle this fine. I've written realtime, FFT-based frequency analyzers that ran on Windows Mobile devices from a few years ago (using pure C#), and these devices had much worse processors than current Android devices. The most computationally expensive aspect of FFT is the trig functions, and since you're using a fixed-size window you can easily replace the trig function calls with a pre-calculated lookup table.
As an aside you can probably cut down your computation time by reducing your sampling rate. Speech doesn't have much energy above 8 kHz, so you could likely downsample your audio to 16 KHz before doing any FFTs, without losing much accuracy. At 16 kHz your FFTs would be smaller, and so faster.
Wikipedia claims that 16 kHz is a standard sampling rate for speech recognition in desktop applications.
(I realize that this doesn't answer the OP's question, but I think it might be helpful to him nonetheless, given his application.)
I made test application in Delphi that beeps morse code using Windows API Beep function. Then made an application in Android that stores this morse code in WAV file. Now I want Android application to decode the morse code. Is there some tutorials for sound processing or can somebody post some simple code (think there's no simplicity here) for an example? Or maybe steps that I need to do to get it work?
I also downloaded the JTransforms and jfttw libraries but don't really know where to start.
Regards,
evilone
An FFT is overkill for this - you can just use a simple Goertzel filter to isolate the morse code from background noise, then decode the output of this.
I think an older issues of QST magazine had an article on DSP for Morse/CW decoding several years back. Might want to try and search their archives.
Basically, you need DSP code to determine whether or not a tone is present at any given point in time, and an estimate of the onset and off-time of each tone. Then scale the duration of each tone and the gap times between the tones for the expected code speed, and compare against a table of timings for each Morse code letter to estimate the probability of each or any letter being present.
In the simplest case, you might have a dot-dash-space decision tree. In severe noise and fading plus highly personalized fist/timing you might need some sophisticated statistical and/or adaptive audio pattern matching techniques for decent results.
Hello I was wondering if using the android tone generator class would it be possible to create a tone in one device and listen for this same tone in another device. If this is possible I do have a few other questions.
Taking backround noise into consideration is it possible to listen for only this specific tone?
Would this process be resource intensive?
Could I use a tone that would be inaudable to the human ear or close to it?
Lastly could I use a tone that could only be heard with a couple of feet from the sending device?
Thanks very much for yer time guys and girls :)
Edit >
Thanks For adding the audio processing tag sabastian. Much better discription.
It would be CPU intensive, yes.
The way to it is quite simple: you need a permanent recorder which puts the received data into a FFT (fast fourier transform). FFT basically does one thing: splits the audio into a frequency/power-scale. With this "background noise cleaned" result you can check things like "was there a tone with 1000Hz playing for at least 2 seconds" - and act accordingly.
There is a reasonable speed FFT implementation here: http://www.badlogicgames.com/wordpress/?p=449
FFT can also be used (actually, IS used) for detection of dualtone dialing (DTMF) - 2 frequencies at same time is much better than just using one (as the error rate drop significantly and you can go to shorter duration for the tone sending/detecting).
"Inaudible" won't be possible, as (a) the speaker can not produce such sounds (b) you are limited in sampling rate - so also limited in both producing and recording such high frequencies.
"couple of feet" will be naturally imposed (not very loud speaker, not very good microphone).
Have a look at this other question: "Android: Need to record mic input". I think you can modify that for your task, then with sound bytes you can have filtering or FFT.
Hope it helps