Closed xir4n closed 6 months ago
Thanks, @lostanlen. I've come to realize that it's beneficial to make DTCWT
support both even and odd input lengths, especially considering the implications for MuReNNDirect
.
With odd-length input data, the reconstructed signal by IDTCWT
will be extended by a length of 1, potentially causing issues for users.
With odd-length input data, the reconstructed signal by IDTCWT will be extended by a length of 1, potentially causing issues for users.
I see. In librosa, the way we resolve this is by allowing an optional length
keyword argument in the inverse operator so as to make sure that the output length is exactly the same.
See: https://librosa.org/doc/0.10.1/generated/librosa.icqt.html#librosa.icqt
Perhaps we could have something like that too?
Perhaps we could have something like that too?
Thanks for your suggestions, this is totally possible. But in my opinion, implementing it will require some effort, and I think it's not that urgent at the moment. Would it be acceptable for me to draft a new issue and address it in the future?
You're right, let's put it as 0.4 milestone, not 0.3
Now that
DTCWT
requires the input data to be a tensor of shape(B, C, 2**J)
, where J is the number of wavelet scales, it can be inconvenient to apply to real data. However, the dtcwt.np package offers a less strict requirement for the input shape. Instead of(B, C, 2**J)
, it only requires the input length to be even. To accommodate this, I made some modifications to achieve the same results.