Capturing high freq audio, with lowest filesize possible - Page 1
Forum section: electronics / projects

author: cdwijs
author_rank: Regular Contributor
timestamp: December 12, 2015, 07:21:11 pm
content: Hi All,I am asked to come up with something that can capture and log ultrasonic sound, something like 30-90KHz. This is quite easy, I can just get an USB sound card that can do 192KHz sampling rate, connect it to a microphone with pre-amplifier that can capture up to 100KHz, and write a .wav file to the hard drive. This will work, but the resulting .wav file will be huge.My employer is not interested in much detail of the sound, the only thing important is that he knows if and when a sound has occurred. So if my software delivers a running average of the FFT of the signal over the last second, he will be happy. Does such software exists? Can I do this with oggenc with the quality setting of 1 (lowest quality)?Kind regards,Cedric

author: Zero999
author_rank: Super Contributor
timestamp: December 12, 2015, 07:35:18 pm
content: Be careful, not all sound cards which sample at 192Hz will have an analogue bandwidth up to, 96kHz, the Nyquist frequency. There will be a filter which starts rolling off, just above 20kHz.

author: Richard Crowley
author_rank: Super Contributor
timestamp: December 12, 2015, 07:47:10 pm
content: So if they are only interested in the PRESENCE (or in technical terms, the "envelope") of the signal, why why record the entire waveform (in technical terms, the "carrier"). There seems to be no compelling reason to preserve the carrier when only the envelope (or maybe even simply the binary presence/absence) is of interest.Simply make a detector which "deciphers" the amplitude (or presence/absence) of the ultrasonic carrier, and log the META-data.Or, if you are really interested in the signal itself, then hetrodyne it down to audio frequencies, and record it as a conventional audio signal. There are circuits/projects out there for gadgets which hetrodyne ultrasonic signals down to human-perceptible audio. For example people who are interested in hearing the echolocating signals from bats, etc.

author: jeroen79
author_rank: Frequent Contributor
timestamp: December 12, 2015, 08:37:35 pm
content: What is the purpose of this?What do you want to detect?If 'if' and 'when' are all you are interested in then I would agree with Richard.Just filter the desired frequency band and test if the measured amplitude is above a predetermined threshold. Then log the time whenever the output changes between 'true' and 'false'.

author: Fungus
author_rank: Super Contributor
timestamp: December 12, 2015, 08:50:12 pm
content: Why do you need to write it to disk? Just run the detection filter in real time and log the events.PS: Most microphones won't work at those frequencies.

author: T3sl4co1l
author_rank: Super Contributor
timestamp: December 12, 2015, 08:57:57 pm
content: If the problem has little or nothing to do with frequency, and everything to do with amplitude, then you can simply detect (as in, diode peak detector, or equivalent digital process) whatever energy is in the desired band range, and filter that down to whatever bandwidth corresponds to the desired temporal resolution you need (i.e., to tell when something happened within ~seconds, a sample rate or bandwidth of a few Hz is sufficient).If it's at all desirable to have precision (say within ~ms or better), or frequency resolution at all, you'll need a higher sample rate, or frequency conversion methods.Hetrodyning is good for retaining frequency information, but not pitch (assuming the signals up there have much sense of pitch at all -- to humans anyway, there isn't much sensation of pitch beyond 8kHz or so, and I don't know if it's been studied whether animals experience pitch, or if such can even be tested..). You also need as many audio channels as bandwidth: 30-90kHz is a 60kHz bandwidth, so has to be divided into 3 channels of 20kHz.If pitch must be preserved, a modified digital format is probably desirable. You can take an array of full speed samples (say, 10ms at 192kHz), FFT, decimate (so now the spectrum represents 10ms at 22kHz -- or less), FFT again, and store that as any convenient audio format. This is to some extent what MP3 does already (storing the compressed frequency data, but expanding it back at the same pitch), though with more weighting for auditory response.There is continuity between all these methods. These are just the more extreme examples. The general concept is to divide the source signal into frequency bands, and capture those bands individually, by direct sampling, or using a detector and filter.In the first case, the entire band is detected and sampled, giving the grossest possible frequency resolution (none!).Downconverting band segments gives more frequency resolution. Without detection, the original signal can be reconstructed exactly. With detection, you basically get the first case's something-there-or-not, but with being able to see several frequency ranges rather than just one -- still quite gross frequency resolution, but it's something!This process can be taken to the extreme, using hundreds or thousands of frequency channels. It would suck to build all that by hand, but fortunately, it is exactly equivalent to performing an FFT on an array of samples. Now we might have too much frequency resolution (i.e., from a 32k sample array, an FFT gives 16k channels!), so pairs of channels can be averaged (decimated) to give less resolution. Meanwhile, the amplitude of each band varies much more gradually -- no faster than the array length -- so the bandwidth per channel can be quite small. We might store a quite sparse sampling, of a much larger FFT, to get a rather coarse frequency resolution, without having to build out, say, ten or a hundred mixers and filters!Also, all this says nothing of amplitude precision. Default audio sampling is 16 bits, which offers excellent dynamic range, so you might simply leave it at that. It's pretty wasteful if the signal is expected to be quiet and intermittent, though. And it's also poor if the signal's intensity varies widely (such as the fading associated with room reflections, directional sources, variable distance and such). A logarithmic scale might be better for that case. Example:https://en.wikipedia.org/wiki/%CE%9C-law_algorithmOr, if you truly do not need accuracy at all, only a fixed threshold, one bit will suffice: it's either "there" (above threshold) or not!Finally, project constraints/ideas -- maybe it'll be a little wasteful to store extra frequency or amplitude information, reducing the expected storage time. But little things like that often facilitate follow-up work. On analyzing the data, you might wish that there were more information there. Storing raw audio (WAV, perhaps in a lossless container like ZIP) might be far too wasteful, and ruled out straightaway. Lossy (psychoacoustic based) formats should probably be avoided too, because their complexities will taint the data in ways you might not've been expecting. Choosing one of these intermediate cases above may be a good idea, even if it means taking the time to write your own format -- the best part is that their errors tend to be predictable and even. For example, consider the straight line equivalent to the mu law curve: in data that looks predictable, it should be quite possible/reasonable to fix those artifacts, recovering the original signal better.Some follow-up ideas might not be so easy to accommodate, and will require more work to follow up on. For example, if it is known that only one or two reasonably pure tones will be sensed at a time (say from a single bat fluttering around), then it's probably reasonable to track only two aspects of that tone: its pitch and amplitude. And at fairly lax rates, like 1kHz. The fine frequency resolution of tracking just one signal means you get to study changes as subtle as Doppler shifts, which would be dubious even with a compressed FFT method (the shift might span only a few frequency bands), and be missed completely with a couple-bands-plus-detectors method. But this breaks down when the signal is more complex, and is meaningless for others (e.g., wideband clicking, pinging, crashing..).Tim

author: Marco
author_rank: Super Contributor
timestamp: December 12, 2015, 11:07:31 pm
content: Do sliding FFT with say CSOUND, do some processing with python (averaging/maxing/thresholding), store as CVS, losslessly compress it with some compression library? Assuming you can threshold aggressively enough to make most components zero most of the time that should be enough compression.