DSP.jl
DSP.jl copied to clipboard
Add "padding" support to ArraySplit?
Currently our ArraySplit type does not zero-pad the signal anywhere, but one may wish to zero pad the beginning or the end of an array (for example, if computing MDCTs or an inverse STFT). Should we add this functionality to ArraySplit?
A straightforward way of adding it would be to have two attributes in ArraySplit that store the number of zeros at the beginning and the end, and in ArraySplit.getindex check if the required range is in one of these intervals (in which case we would just fill the corresponding elements with zeros). This may be bad performance-wise, but we can try to avoid having to do a comparison prior to copying each element to the "view" buffer.
I guess the performance wouldn't be so bad with a couple of extra if statements, then just split the for loop into a regular loop and a zero fill loop.
I will need this really soon, so I will try a preliminary implementation and post as a PR for comments.
I was testing my extensions code and tried it on ArraySplit. Is this the kind of behaviour you were looking for?
julia> a = arraysplit(randn(8),2,0,5)
4-element ArraySplit{Array{Float64,1},Float64,Nothing}:
[-0.13114,0.0273529,0.0,0.0,0.0]
[-0.625439,0.929937,0.0,0.0,0.0]
[1.14192,-0.499608,0.0,0.0,0.0]
[-0.127784,-3.07408,0.0,0.0,0.0]
julia> a[1]
5-element Array{Float64,1}:
-0.13114
0.0273529
0.0
0.0
0.0
julia> getindex(a,1,boffset=3)
5-element Array{Float64,1}:
0.0
0.0
0.0
-0.13114
0.0273529
I actually wanted to prepend and append zeros to the input vector. Something like this (ignore the ugly API):
julia> x = rand(8)
julia> a = arraysplit(x, 4, prepad=4, postpad=4)
7-element ArraySplit{Array{Float64,1},Float64,Nothing}:
[0.0,0.0,0.0,0.0]
[0.0,0.0,0.489291,0.995162]
[0.489291,0.995162,0.557022,0.0481569]
[0.557022,0.0481569,0.0793861,0.909953]
[0.0793861,0.909953,0.677247,0.0797082]
[0.677247,0.0797082,0.0,0.0]
[0.0,0.0,0.0,0.0]
Most of the time I append zeros to the end of the array to make sure I can reconstruct it with the same length. If analyzing and resynthezing with stft/istft, the resynthesized array will always have a length that's a multiple of the window size + the hop size, and you also do not get a decent analysis of the last frames of the original signal unless you pad with zeros.
OK. Did you implement that already?
Not yet. Maybe it's a good thing to add to the signal extensions submodule?