I would like to get the rate of tapping (per sec) for woodpeckers recordings in Praat (example of rec below). I have been looking but could not find an easy command or script that would allow to get this info without annotation.
Is there a simple way for someone not used to script writing?
enter image description here
You could use Pitch; 'Get pitch' (F5).
Pulses are often linked to periods to measure pitch, so that should work.
OR:
You can use Pulses; Voice report which gives you the number of pulses Praat measures in your selection. Simply dividing the number of pulses by the time of your selection would give you the rate. Example of a voice report:
Voice Report
Related
I am looking for a way to code or find a program that can record the chirps of crickets either live or through a prerecorded audio file (large ~24 hours) for a lab experiment.
I'm not too sure how to approach this as I'm a web developer, but I have experience with JS and python, along with libraries. My initial idea was to use Matplotlib to produce an audio visualizer, and then count each time a certain range of db is reached which matches the db of a cricket chirp, but I have no idea how to approach it.
I have successfully visualized the chirps on a online spectrum analyzer (Spectrum Visualizer of Audio Chirps), and can see it clearly, however I don't know how I can use code to count each "chirp" and record it along with the date and time for each chirp in a table of values / dataset of some sort.
Any guidance or help would be greatly appreciated!
Really naive solution: For every unit of time (column of pixels in the spectrogram), you can calculate the sum of all the values in a column. For example, if all the pixels in a column are black, the sum for that column will be 0, if some of them are colored, the sum will be >0.
Then loop over the sums: if at a certain step you go from 0 to > 0, and then after a while you go back to 0, you've hit a peak.
If the output is too "noisy", you can use a small threshold value instead of 0. Tweak it until results seem OK. This works well when the input background noise is pretty much the same all the way through, but if it's skewed up and down during the whole recording, you need something more complicated (for example, the threshold constantly changes with the average of the last n sums)
Or you can Google "peak detection algorithm" and implement one of them. Or you can Google "peak detection library" in your favourite language and use one of them.
I'm currently using MPLABX to code Pic16f877a, I use Proteus as a simulator, I have to identify what type of waveform I get at the analog input, my frequency is not fixed but I can store it. I wanted to use a full bridge rectifier so I get an input of 0-5V.
I was thinking I could check how much time it needs to get from 0 to 1V, from 1V to 2V, etc. for the square wave it would always be ~+5V.
I don't know if there's a better way of if this is even possible. I attach a piece of code that stores the frequency. MPLABX
I'm pretty new to using GNURadio and I'm having trouble recovering the data from a signal that I've saved into a file. The signal is a carrier frequency of 56KHz with a frequency shift key of +/- 200hz at 600 baud.
So far, I've been able to demodulate the signal that looks similar to the signal I get from the source:
I'm trying to get this into a repeating string of 1s and 0s (the whole telegram is 38 bytes long and it continuously repeats). I've tried to use a clock recovery block in order to have only one byte per sample, but I'm not having much luck. Using the M&M clock recovery block, the whole telegram sometimes comes out correct, but it is not consistent. I've tried to adjust the omega and Mu values, but it doesn't seem to help that much. I've also tried using the Polyphase Clock sync, but I keep getting a runtime error of 'please specify a filter'. Is this asking me to add a tap? what tap would i use?
So I guess my overall question would be: What's the best way to get the telegram out of the demodulated fsk signal?
Again, pretty new at this so please let me know if I've missed something crucial. GNU flow graph below:
You're recovering the bit timing, but you're not recovering the byte boundaries – that needs to happen "one level higher", eg. by a well-known packet format with a defined preamble that you can look for.
I'm trying to demodulate a signal using GNU Radio Companion. The signal is FSK (Frequency-shift keying), with mark and space frequencies at 1200 and 2200 Hz, respectively.
The data in the signal text data generated by a device called GeoStamp Audio. The device generates audio of GPS data fed into it in real time, and it can also decode that audio. I have the decoded text version of the audio for reference.
I have set up a flow graph in GNU Radio (see below), and it runs without error, but with all the variations I've tried, I still can't get the data.
The output of the flow graph should be binary (1s and 0s) that I can later convert to normal text, right?
Is it correct to feed in a wav audio file the way I am?
How can I recover the data from the demodulated signal -- am I missing something in my flow graph?
This is a FFT plot of the wav audio file before demodulation:
This is the result of the scope sink after demodulation (maybe looks promising?):
UPDATE (August 2, 2016): I'm still working on this problem (occasionally), and unfortunately still cannot retrieve the data. The result is a promising-looking string of 1's and 0's, but nothing intelligible.
If anyone has suggestions for figuring out the settings on the Polyphase Clock Sync or Clock Recovery MM blocks, or the gain on the Quad Demod block, I would greatly appreciate it.
Here is one version of an updated flow graph based on Marcus's answer (also trying other versions with polyphase clock recovery):
However, I'm still unable to recover data that makes any sense. The result is a long string of 1's and 0's, but not the right ones. I've tried tweaking nearly all the settings in all the blocks. I thought maybe the clock recovery was off, but I've tried a wide range of values with no improvement.
So, at first sight, my approach here would look something like:
What happens here is that we take the input, shift it in frequency domain so that mark and space are at +-500 Hz, and then use quadrature demod.
"Logically", we can then just make a "sign decision". I'll share the configuration of the Xlating FIR here:
Notice that the signal is first shifted so that the center frequency (middle between 2200 and 1200 Hz) ends up at 0Hz, and then filtered by a low pass (gain = 1.0, Stopband starts at 1 kHz, Passband ends at 1 kHz - 400 Hz = 600 Hz). At this point, the actual bandwidth that's still present in the signal is much lower than the sample rate, so you might also just downsample without losses (set decimation to something higher, e.g. 16), but for the sake of analysis, we won't do that.
The time sink should now show better values. Have a look at the edges; they are probably not extremely steep. For clock sync I'd hence recommend to just go and try the polyphase clock recovery instead of Müller & Mueller; chosing about any "somewhat round" pulse shape could work.
For fun and giggles, I clicked together a quick demo demod (GRC here):
which shows:
On iOS 7, how do I get the current microphone input volume in a range between 0 and 1?
I've seen several approaches like this one, but the results I get baffle me.
The return values of peakPowerForChannel: are documented to be in the range of -160 to 0 with 0 being the loudest and -160 near absolute silence.
Problem: Given a quite room and a short but loud noise, the power goes all the way up in an instant but takes very long time to drop back to quite level (way longer than the actual noise...)
What I want: Essentially I want an exact copy of the Audio Input patch of Quartz Composer with its Volume Peak output. Any tips?
To get a similar volume peak measurement, you might have to input raw audio via the iOS Audio Queue API (or the RemoteIO Audio Unit), and analyze the raw PCM waveform samples in each audio callback, looking for a magnitude maxima over your desired frame width or analysis time.