On Tue, 15 Apr 2014 04:24:59 -0700 (PDT), radams2000@gmail.com wrote:>I have to admit that I'm baffled by the sudden upsurge in people who recomm= >end a full fft- based STFT approach for tasks that are routinely done by st= >andard iir/fir filters. Interpolation/decimation filter theory is old and w= >ell- established. Are schools no longer teaching this stuff? Do new enginee= >rs not realize that when they adjust a bass/treble control, there's not a c= >opy of Matlab inside their IPod? > >Bob >The tools and technology are still changing. What was hard a long time ago is now trivial. There's been a slow paradigm shift (sort of) in how to go about various things given that computing power and memory is now uber-cheap. It's just a different mindset and viewpoint. Being able to practically use a single transform for a very long data set is a bit of a game changer. Not to worry; the greybeards still know the tricks for when somebody paints themself in a corner with such things. ;) Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com
Convert to higher sample rate
Started by ●April 13, 2014
Reply by ●April 15, 20142014-04-15
Reply by ●April 15, 20142014-04-15
On 4/15/14 11:28 AM, Eric Jacobsen wrote:> On Tue, 15 Apr 2014 04:24:59 -0700 (PDT), radams2000@gmail.com wrote: > >> I have to admit that I'm baffled by the sudden upsurge in people who recomm= >> end a full fft- based STFT approach for tasks that are routinely done by st= >> andard iir/fir filters. Interpolation/decimation filter theory is old and w= >> ell- established. Are schools no longer teaching this stuff? Do new enginee= >> rs not realize that when they adjust a bass/treble control, there's not a c= >> opy of Matlab inside their IPod? >> > > The tools and technology are still changing. What was hard a long > time ago is now trivial. There's been a slow paradigm shift (sort of) > in how to go about various things given that computing power and > memory is now uber-cheap. > > It's just a different mindset and viewpoint.no shit. in the olden days we had to sorta count out our memory needs and malloc() the space (which had a direct counterpart to allocating the memory resources in hardware). now they just use the vector template class and slap whatever they're making onto that and never concern oneself with cost. oh, what them youngins is doing. just can't approve of it. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●April 15, 20142014-04-15
On Mon, 14 Apr 2014 14:20:33 -0700, Rob Gaddi wrote:> On Mon, 14 Apr 2014 16:15:07 -0500 Tim Wescott <tim@seemywebsite.really> > wrote: > >> On Mon, 14 Apr 2014 15:39:58 -0400, robert bristow-johnson wrote: >> >> > On 4/14/14 2:24 PM, Rob Gaddi wrote: >> >> On Mon, 14 Apr 2014 14:15:41 -0400 robert >> >> bristow-johnson<rbj@audioimagination.com> wrote: >> >> >> >>> On 4/14/14 1:15 PM, Tim Wescott wrote: >> >>>> On Sun, 13 Apr 2014 16:49:35 -0400, robert bristow-johnson wrote: >> >>>> >> >>>>> On 4/13/14 4:35 PM, Tim Wescott wrote: >> >>>>>> On Sun, 13 Apr 2014 21:16:55 +0000, Robert Scott wrote: >> >>>>>> >> >>>>>> >> >>>>>> In the end analysis, the "replicate samples" method is >> >>>>>> essentially the same thing as the "insert zeros" method followed >> >>>>>> by a boxcar filter. That, in turn, means that the "replicate >> >>>>>> samples" method is really just the "insert zeros" method with >> >>>>>> the boxcar filter imposed on the designer. >> >>>>> >> >>>>> "imposed"? you might want to put it that the boxcar filter (with >> >>>>> those nice honkin' big nulls at n*Fs for |n|>0) is *aiding* the >> >>>>> designer. it's all in the semantics. >> >>>> >> >>>> I would say that it's all in the designers intent. If they can >> >>>> use the nulls, then its an aid. If they don't want the nulls, or >> >>>> if they want the nulls elsewhere, it's an imposition. >> >>> >> >>> lemme see, other than the image centered at f=0 (the original), why >> >>> *wouldn't* you welcome nulls smack dab in the middle of all of the >> >>> other images? when you resample, all of those images (that >> >>> survive) potentially fold over into your original baseband and mess >> >>> things up. >> >>> they become the "N" when you calculate the S/N of your resampling >> >>> operation. >> >>> >> >>> >> >> I can't imagine not wanting the nulls themselves, but sinc(f)'s got >> >> some awfully round knees. If I'm having to fancy up my >> >> post-filtering to try to restore those mid-ranges that got their >> >> heads pushed down, there's every chance that's more work than doing >> >> it the mathematically simpler way. >> >> >> >> >> > well, one thing about the magic of optimal FIR filter design is that >> > you get to specify the target frequency response in such a way to >> > compensate (to whatever extent possible) for those awfully rounded >> > knees. >> >> A FIR boxcar filter is just a collection of zeros at the harmonics, >> over z^whatever. >> >> Really -- just factor z^n + z^(n-1) + ... + z + 1. They're all there, >> and that's all that's there. >> >> So any filter that incorporates all those nulls will have that boxcar >> filter built into it, somewhere (or several somewheres). >> >> -- >> >> Tim Wescott Wescott Design Services http://www.wescottdesign.com >> >> > Right, but that's only if you actually need the nulls. If they're > simply "nice", for instance you had been planning to address the > interpolation aliases with an 8th order elliptical filter rather than > mucking about with kilotap FIRs, then you can do without them. > > Or another way to put it, the situation depends on the situation.Yes, that pretty much sums up what I've been trying to say to RBJ. -- Tim Wescott Wescott Design Services http://www.wescottdesign.com
Reply by ●April 15, 20142014-04-15
On 4/15/14 11:23 AM, Eric Jacobsen wrote:> On Sun, 13 Apr 2014 22:31:23 -0500, "mnentwig"<24789@dsprelated> > wrote: > >>>> what kind of numerical issues might you expect with a 256 Meg FFT? >> >> I have used regularly FFTs up to Octave's 2G limit for simulations. >> Usually the dynamic range is 300 dB in double precision, give or take some. >> Now I can't tell you how much exactly is lost. But I agree, one should keep >> an eye (or an ear?) on it. >> >> I haven't heard about large FFTs being problematic. I might risk a bet that >> it's still better than anything you can cook up with a "reasonable" impulse >> response length, not at a level that you can hear but if you look at -150 >> dBc. >> >> With some very loose assumptions (that is, if the "repeat all" button on >> the CD player is pressed and the signal is cyclic), the FFT's Fourier sum >> -is- the correct solution to the oversampling problem. >> >> Brute force - if it doesn't work, I'm not t using enough of it. Wouldn't >> propose this for an ASIC, though.so why, with software, would you use the complexity of the Fourier Transform to do such a basic task?> Yeah, it's getting to be an interesting tradeoff that such things can > sometimes be better done more "efficiently" in software than in > hardware. We live in interesting times.quotes noted. :-\ -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●April 15, 20142014-04-15
On 4/15/14 11:49 AM, Tim Wescott wrote:> On Mon, 14 Apr 2014 14:20:33 -0700, Rob Gaddi wrote: > >> On Mon, 14 Apr 2014 16:15:07 -0500 Tim Wescott<tim@seemywebsite.really> >> wrote: >> >>> On Mon, 14 Apr 2014 15:39:58 -0400, robert bristow-johnson wrote: >>> >>>> On 4/14/14 2:24 PM, Rob Gaddi wrote: >>>>> On Mon, 14 Apr 2014 14:15:41 -0400 robert >>>>> bristow-johnson<rbj@audioimagination.com> wrote: >>>>> >>>>>> On 4/14/14 1:15 PM, Tim Wescott wrote: >>>>>>> On Sun, 13 Apr 2014 16:49:35 -0400, robert bristow-johnson wrote: >>>>>>> >>>>>>>> On 4/13/14 4:35 PM, Tim Wescott wrote: >>>>>>>>> On Sun, 13 Apr 2014 21:16:55 +0000, Robert Scott wrote: >>>>>>>>> >>>>>>>>> >>>>>>>>> In the end analysis, the "replicate samples" method is >>>>>>>>> essentially the same thing as the "insert zeros" method followed >>>>>>>>> by a boxcar filter. That, in turn, means that the "replicate >>>>>>>>> samples" method is really just the "insert zeros" method with >>>>>>>>> the boxcar filter imposed on the designer. >>>>>>>> >>>>>>>> "imposed"? you might want to put it that the boxcar filter (with >>>>>>>> those nice honkin' big nulls at n*Fs for |n|>0) is *aiding* the >>>>>>>> designer. it's all in the semantics. >>>>>>> >>>>>>> I would say that it's all in the designers intent. If they can >>>>>>> use the nulls, then its an aid. If they don't want the nulls, or >>>>>>> if they want the nulls elsewhere, it's an imposition. >>>>>> >>>>>> lemme see, other than the image centered at f=0 (the original), why >>>>>> *wouldn't* you welcome nulls smack dab in the middle of all of the >>>>>> other images? when you resample, all of those images (that >>>>>> survive) potentially fold over into your original baseband and mess >>>>>> things up. >>>>>> they become the "N" when you calculate the S/N of your resampling >>>>>> operation. >>>>>> >>>>>> >>>>> I can't imagine not wanting the nulls themselves, but sinc(f)'s got >>>>> some awfully round knees. If I'm having to fancy up my >>>>> post-filtering to try to restore those mid-ranges that got their >>>>> heads pushed down, there's every chance that's more work than doing >>>>> it the mathematically simpler way. >>>>> >>>>> >>>> well, one thing about the magic of optimal FIR filter design is that >>>> you get to specify the target frequency response in such a way to >>>> compensate (to whatever extent possible) for those awfully rounded >>>> knees. >>> >>> A FIR boxcar filter is just a collection of zeros at the harmonics, >>> over z^whatever. >>> >>> Really -- just factor z^n + z^(n-1) + ... + z + 1. They're all there, >>> and that's all that's there. >>> >>> So any filter that incorporates all those nulls will have that boxcar >>> filter built into it, somewhere (or several somewheres). >>> >>> -- >>> >>> Tim Wescott Wescott Design Services http://www.wescottdesign.com >>> >>> >> Right, but that's only if you actually need the nulls. If they're >> simply "nice", for instance you had been planning to address the >> interpolation aliases with an 8th order elliptical filter rather than >> mucking about with kilotap FIRs, then you can do without them. >> >> Or another way to put it, the situation depends on the situation. > > Yes, that pretty much sums up what I've been trying to say to RBJ. >yeah, but i'm a too-committed believer in the One True Religion of resampling. i've tried the other religions, like polynomial splines (like Hermite), sample replication with an IIR (was only a biquad with enough Q to partially compensate for the sinc() rolloff had high frequencies), and the symmetric FIR Polyphase religion turns out to be the only one true religion. of that i have been in different Polyphase sects: various windowed sincs (and Lagrange or Hermite are sorta a form of that) and Parks-McClellan and Least Squares. and i won't tell you what Polyphase sect i am in. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
Reply by ●April 15, 20142014-04-15
>> Are schools no longer teaching this stuff?This thread makes me smile. Apologies for not trying to do things the hard way as we all learned in school. There was no word about "realtime" in the OP. I do agree that this would make it a more interesting problem, but turning simple problems into more interesting ones is a skill that has little use outside the classroom. I'd wager a bet that in 99.9 % of _relevant_ cases (see OP), a dumb fft interpolation will - give the result faster (copy and paste the code I provided, run on free Octave) - give a better result by objective standards, such as the norm of the residual against the correct result. - most likely be faster at runtime (you can beat this one but you'll have to work for it. FFTW lives up to the promise in its name). _____________________________ Posted through www.DSPRelated.com
Reply by ●April 15, 20142014-04-15
Eric Jacobsen <eric.jacobsen@ieee.org> wrote: (snip, someone wrote)>>Brute force - if it doesn't work, I'm not t using enough of it. >> Wouldn't propose this for an ASIC, though.> Yeah, it's getting to be an interesting tradeoff that such things can > sometimes be better done more "efficiently" in software than in > hardware. We live in interesting times.Seems to me that the "interesting" point keeps moving. Must have been interesting when the FFT was new, and people could do the big 2K and 4K sample transforms. But yes, many things that wouldn't have made any sense at all not so many years ago are routine today. I was recently scanning some IBM S/360 manuals, that take up over 100MB on disk as uncompressed TIFF files. The big disk for S/360 systems was 29MB, and even if people thought about scanning they wouldn't fill up a few disks with one manual. But now it takes up a tiny space on my 3TB disk. -- glen
Reply by ●April 15, 20142014-04-15
mnentwig <24789@dsprelated> wrote:>>> Are schools no longer teaching this stuff?> This thread makes me smile. Apologies for not trying to do > things the hard way as we all learned in school.Reminds me of my high school geometry teacher describing the proofs that we turned in: "Why do it the easy way when there is a hard way?" As far as sample rate conversion, I sometimes wonder about an LCD HDTV with 768 pixels vertical, displaying either 720P or 1080i data. (Not even mentioning the transform in the horizontal direction.) So, a 2D sample rate conversion for some megapixels about 60 time a second. -- glen
Reply by ●April 15, 20142014-04-15
glen herrmannsfeldt <gah@ugcs.caltech.edu> writes:> [...] > robert bristow-johnson <rbj@audioimagination.com> wrote: >> >> what kind of numerical issues might you expect with a 256 Meg FFT? > >> cos(2*pi/268435456) = what ?? > [...] > > log2(77*60*44100) is about 28. Worst case is one additional bit > per stage, so 53 bit floating point should be plenty.glen: I don't think that addresses the cos(2*pi/268435456) issue. The "quantization bits per stage" is another issue. The cos(2*pi/268435456) (and corresponding sin()) issue may cause problems when there is cancellation http://en.wikipedia.org/wiki/Floating_point#Accuracy_problems but it would be data-dependent. For example, the input [-1 +1 -1 +1 .... -1 +1] would aggravate the cancellation issue since cos[n * (2 * pi / 268435456)] and cos[(n + 1) * (2 * pi / 268435456)] are going to be very close. Don't you think? -- Randy Yates Digital Signal Labs http://www.digitalsignallabs.com
Reply by ●April 15, 20142014-04-15
Sure, when you are processing on your computer, and latency is not an issue, use an fft approach if you want. But in the world of consumer/pro audio equipment where size, cost and battery life are important, stream processing using FIR/IIR still rules the day. By the way, there are various dangers you can easily fall into with fft processing if you're not careful. 1) the assumption that one can just naively draw any response curve they like in the fft domain is incorrect. Aliasing cancellation in the reconstruction only occurs if the spectral modifications meet certain conditions that are too deep to go into here. I see lots of posters talk about applying a 1/0 mask function to pass some frequencies and reject others. Say what you want about stream processing, at least if you put one frequency in, only one frequency comes out. 2) If you decide to fft an entire song as is proposed by some, and then apply a filter with a very steep rolloff, the length of the impulse response could be, literally, minutes long. This would obviously be a disaster. Bob
