Audio compression by definition 'alters' the transform coefficients and they get perfect reconstruction with no aliasing due to the transform alone. In fact 'TDAC' or time domain aliasing cancellation is a hallmark of the MDCT or DCT type IV which is ubiquitous in audio codecs.
On Sun, Mar 8, 2020, 7:41 PM Ethan Duni <ethan.d...@gmail.com> wrote: > FFT filterbanks are time variant due to framing effects and the circular > convolution property. They exhibit “perfect reconstruction” if you design > the windows correctly, but this only applies if the FFT coefficients are > not altered between analysis and synthesis. If you alter the FFT > coefficients (i.e., “filtering”), it causes time domain aliasing. > > So, the operation of such a system can’t be reduced down to an equivalent > LTI frequency response. We have the more basic issue of limiting the > aliasing to acceptable levels. This depends partially on the frame size, > overlap, and window shape, as these determine how any aliasing is > distributed in a time/frequency sense. But more fundamentally, you have to > put constraints on the response curves to limit the aliasing. I.e. the > steeper the transitions in the frequency response, the longer the implied > impulse response, and so the time domain aliasing gets worse. > > It is certainly possible to run any filter bank offline and compensate for > its latency, in order to get a “zero phase” processing. But fundamentally > they have framing delay given by the frame size, and algorithmic latency > given by the overlap. These are the delays that you’d compensate when > running offline. > > Ethan > > On Mar 8, 2020, at 2:04 PM, zhiguang zhang <zhiguangezh...@gmail.com> > wrote: > > > The system is memoryless just because it is based on the DFT and nothing > else, which is also why it's time-invariant. unless you alter certain > parameters in real-time like the window size or hop size or windowing > function, etc, any input gives you the same output at any given time, which > is the definition of time-invariance. > > well, you're RBJ and I see that you used to work at Kurzweil until 2008. > that's cool and what have you been up to since then? incidentally i was in > California until 2008. > > As you might be able to tell, i don't care too much about the fact that > time domain filtering theory is brought up often because I did my master's > thesis with this frequency domain FFT filter, which I believe was rather > novel at the time of completion. I do know that the field is steeped in > tradition, which might be why I'm writing to the mailing list and to you in > particular. but bringing up traditional FIR/IIR filtering terminology to > describe FFT filtering doesn't make sense in my mind. I'm not in the audio > field. but yes, I do believe that the system is time invariant, but I > don't have time to prove myself to you on this forum at this time, nor do I > have any interest in meeting Dr Bosi at AES. > > -ez > > > > On Sun, Mar 8, 2020 at 4:42 PM robert bristow-johnson < > r...@audioimagination.com> wrote: > >> >> >> > On March 8, 2020 3:07 PM zhiguang zhang <zhiguangezh...@gmail.com> >> wrote: >> > >> > >> > Well I believe the system is LTI just because the DFT is LTI by >> definition. >> >> TI is nowhere in the definition of the DFT. L is a consequence of the >> definition of the DFT, but the DFT is not an LTI system. it is an >> operation done to a finite segment of samples of a discrete-time signal. >> >> > The impulse response of a rectangular window I believe is that of a >> sinc function, >> >> window functions do not have impulse responses. >> >> both window functions and impulse responses can be Fourier transformed. >> the Fourier transform of the latter is what we call the "frequency >> response" of the system. i am not sure what they call the fourier >> transform of a window function. what is done with the frequency response >> (multiplication) is *not* what is done with the fourier transform of a >> window function (convolution). >> >> > which has ripple artifacts. >> >> there are no ripple artifacts in fast convolution using a rectangular >> window. you need to learn what that is. >> >> > Actually, the overlap-add method (sorry I don't have time to dig into >> the differences between overlap-add and overlap-save right now) >> >> what you need is time to learn the basics and learn the proper >> terminology of things so that confusion in communication is minimum. >> >> > minimizes artifacts depending on the windowing function. >> >> again, there are no ripple artifacts in fast convolution using a >> rectangular window. none whatsoever. >> >> > A sine window ... >> >> i think you might mean the "Hann window" (sometimes misnamed "Hanning", >> but that is an old misnomer). i have never heard of a "sine window" and i >> have been doing this for 45 years. perhaps the classic Fred Harris paper >> on windows has a "sine window". >> >> > ... actually sums to 1, >> >> that's what we mean by "complementary". >> >> > the proof of which can be found in audio coding theory. I suggest you >> check out the book by Bosi. >> >> i didn't even know Marina did a book, but i am not surprized. i've known >> (or been acquainted with) Marina since she was with Digidesign back in the >> early 90s. before the Dolby Lab days. before her injury at the New York >> Hilton in 1993. would you like me to introduce you to her at the next AES? >> >> Eric, you gotta get the basics down right and you gotta learn the correct >> terminology if you're going to communicate with other people about this >> topic matter. Neologisms are frowned on but people do them anyway. >> However you just cannot change the meanings of terms that have existed >> since the 1960s (and some as far back as the 1930s). >> >> -- >> >> r b-j r...@audioimagination.com >> >> "Imagination is more important than knowledge." >> > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp > > _______________________________________________ > dupswapdrop: music-dsp mailing list > music-dsp@music.columbia.edu > https://lists.columbia.edu/mailman/listinfo/music-dsp
_______________________________________________ dupswapdrop: music-dsp mailing list music-dsp@music.columbia.edu https://lists.columbia.edu/mailman/listinfo/music-dsp
