(this post is a promotion of sound analysis in Lua+LÖVE)

UPD: FFT v0.2 is looks ok and (probably) normalized, but lowfreq sound is damped (too normalized : ) ) and highfreq sounds is not displayed.
Thanks for the explanation. Currently, I have some problems with functional analysis, and I would love to read additional materials.The FFT result seems incorrect
I can set buffer size byUsing a Decoder means you really can't set the buffer size for neither the oscilloscope, nor the input size for the FFT.
Code: Select all
Decoder('filename', buffersize)
Windowing and every-byte-transformation it's for sound equalizers, not for visual stuff or realtime beat detection etc :<..and then pass that into a QueueableSource
Code: Select all
function a:update()
if self.state == 'play' then
if self.source:isPlaying() then
-- QueueableSource source returns only "currently played SoundData" tell
local t = self.source:tell()
local dt = t - self.oldtell
-- If source is plays "next" SoundData
if t < self.oldtell then
-- We remove already played stuff from our storage
local chunk = table.remove(self.chunks, 1)
-- And calcs real deltatime
dt = chunk:getDuration() - self.__tell + t
end
self.oldtell = t
end
-- Filling our Queue with freshy new chunks
while self.source:getFreeBufferCount() > 0 do
local data = self.decoder:decode()
table.insert(self.chunks, data)
self.source:queue(data)
self.source:play()
end
end
end
There are quite a few different fast discreet fourier (or related) transformation implementations, but those should be more-or-less equivalent in terms of getting near same output from input. (granted, they still make some assumptions, hence windowing -is- a must for accuracy)
Yeah, i have been working on such things since a few years ago, been using this library, but it is not the best, so i have been trying to optimize it: https://github.com/h4rm/luafft (Currently i can do a frequency resolution of 16k bins for a mono channel without slowdown)
Whoops, my mistake, that one. :v Then that point of mine can be disregarded.
It is for visual stuff; if you don't window/envelope, a sonograph that would use FFT data will have vertical discontinuities because the input wasn't tapered off to zero on both ends.
Yes, all commercial operating systems as far as i know are non-realtime (win, osx, linux); as for the rest, the exact reason for buffering based on samplepoint offsets (not necessarily byte offsets) is that we can exactly know how much data was processed at one time... granted if the code has something like an "if there are empty buffers in this QSource, then process and queue up the small SoundData buffer(s) we're using". I use this method in my tracker music replayer i wrote; it absolutely works.
If you were the one making that bitbucket issue, i already answered there
The solution to that of course is to queue up at least as much data as needed for one "frame" to happen. If you don't want to sacrifice vsync on the main thread, you could use another thread that doesn't have that issue. (In fact, my advanced source library works like that...) There's no micro-lag pausing my processing in my tracker replayer either so idk...
That is a "windows is shit" thing though, and we can not do anything about it, as far as i know...
Yes, note that i did not say your method is wrong, i only said that there are other ways that might work better depending on what one wants.
I'm at work at the moment, so sadly i can not give a better solution, but i will try a few things when i get back home.
"Specific" means "we can skip samples".since one calling :decode() already "extracts the specific samples" from the file itself
Code: Select all
-- decoder bufsuze is 2756
-- our sound is mono
local data_for_fft = {}
local data = decoder:decode()
for i = 0, 2756 - 1, 2 do -- skip some data
table.insert(data_for_fft, data:getSample(i))
end
for i = #data_for_fft + 1, 2048 do -- zero filling
data_for_fft[i] = 0
end
-- only 2048 samples for fft
local f = fft(data_for_fft)
I call attention to the fact that you're basically doing resampling using the absolute lowest quality algorithm in existence. You should not do any resampling at all unless you're dying for performance*, just feed the entire thing into fourier transform function.
The specific algorithm does not matter, since it can be changed at any time. I am primarily interested in functional analysis itself. Including the reduction of the samples.using the absolute lowest quality algorithm in existence
Users browsing this forum: No registered users and 25 guests