DSPRelated.com
Forums

Convert to higher sample rate

Started by B April 13, 2014
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
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. -- Rob Gaddi, Highland Technology -- www.highlandtechnology.com Email address domain is currently out of order. See above to fix.
On 4/14/14 5:15 PM, Tim Wescott 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). >
my point was that, whatever the boxcar does to your passband (the awfully round knee), you can compensate for that and you *still* get your nulls at all of those images. -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
I have to admit that I'm baffled by the sudden upsurge in people who recommend a full fft- based STFT approach for tasks that are routinely done by standard iir/fir filters. Interpolation/decimation filter theory is old and well- established. Are schools no longer teaching this stuff? Do new engineers not realize that when they adjust a bass/treble control, there's not a copy of Matlab inside their IPod?

Bob

On 4/15/14 7:24 AM, radams2000@gmail.com wrote:
> I have to admit that I'm baffled by the sudden upsurge in people who recommend a full fft- based STFT approach for tasks that are routinely done by standard iir/fir filters.
it's even worse at the DSP stackexchange site.
> Interpolation/decimation filter theory is old and well- established. Are schools no longer teaching this stuff?
i dunno. they weren't really teaching this stuff when we were in skool, Bob. i had to figure it out by direct application of Nyquist/Shannon sampling and *reconstruction*.
> Do new engineers not realize that when they adjust a bass/treble control, there's not a copy of Matlab inside their IPod?
it's even worse at http://dsp.stackexchange.com/ . i guess it's unsurprizing, but i ain't making any friends there. it really gives me mixed feelings about "being helpful". -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
radams2000@gmail.com wrote:
> I have to admit that I'm baffled by the sudden upsurge in people > who recommend a full fft- based STFT approach for tasks that > are routinely done by standard iir/fir filters.
Well, the FFT method only works if it isn't real time (streaming seems to be what they call it now).
> Interpolation/decimation filter theory is old and well- > established. Are schools no longer teaching this stuff?
Fourier series and Fourier transform are usually taught in physics, where IIR/FIR filters are not. Also, I have a much easier time understanding the connection between the input and output for FFT than for IIR.
> Do new engineers not realize that when they adjust a > bass/treble control, there's not a copy of Matlab inside > their IPod?
If they want the song to start playing before it finishes downloading, I suppose they should. Though another case to consider, there are JPEG display programs that will display the low resolution image as it is partly decoded, and then display with increasing resolution is more frequency components are available. In that case, you get to watch the results of the transform right in front of your eyes. -- glen
On 4/15/14 9:27 AM, glen herrmannsfeldt wrote:
> radams2000@gmail.com wrote: >> I have to admit that I'm baffled by the sudden upsurge in people >> who recommend a full fft-based STFT approach for tasks that >> are routinely done by standard iir/fir filters. > > Well, the FFT method only works if it isn't real time > (streaming seems to be what they call it now).
streaming ain't "real time"?? as long as you're willing to put up with throughput delay, the only thing that matters to normally qualify as "real-time DSP" is that this throughput delay is bounded to a finite value while the DSP runs forever. (that means that the average processing time per sample must be no greater than the sampling period.)
> >> Interpolation/decimation filter theory is old and well- >> established. Are schools no longer teaching this stuff? > > Fourier series and Fourier transform are usually taught in > physics, where IIR/FIR filters are not.
but they sure-the-hell are in EE (at least for thems taking DSP or discrete-time LTI theory, maybe specific IIR/FIR coefficient design are not taught so much in the latter). besides, can't people cook up and code a resampling alg from just doing reconstruction (with sinc() or whatever LPF you come up with) and resampling that?
> Also, I have a much > easier time understanding the connection between the input and > output for FFT than for IIR.
hmmm.
>> Do new engineers not realize that when they adjust a >> bass/treble control, there's not a copy of Matlab inside >> their IPod? > > If they want the song to start playing before it finishes > downloading, I suppose they should. > > Though another case to consider, there are JPEG display programs > that will display the low resolution image as it is partly decoded, > and then display with increasing resolution is more frequency > components are available. In that case, you get to watch the > results of the transform right in front of your eyes.
it's nice hearing from Bob and Glen on the same day. L8r, -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
On 4/14/14 5:20 PM, Rob Gaddi wrote:
...
> Right, but that's only if you actually need the nulls.
they're useful if the great majority of your signal energy are in the bottom 5 or 6 octaves.
> 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,
the Ktap FIR that is designed as this brick-wall LPF gets decimated at different phases. even Bob A's AD1890 has what, Bob? 64 non-zero taps per phase? no resampler is doing Ktaps per output sample.
> then you can do without them.
the question is simply about optimization.
> Or another way to put it, the situation depends on the situation.
the only situation that i can imagine using an IIR (and in audio, we're not usually friends with elliptical filters) is maybe upsampling by 2 or 3 by replicating samples and running that into some cheap IIR. but, for the cost of 16 taps per output sample, i am convinced i would get better results with the basic polyphase method. "that's my story and i'm sticking with it." -- r b-j rbj@audioimagination.com "Imagination is more important than knowledge."
On Saturday, 12 April 2014 23:52:34 UTC-7, B  wrote:
> Any opinions on the easiest way to convert an audio track to a higher > > sample rate? Mostly likely x2 or x4. It occurred to me that it could > > be done with FFT, then 'resample' but it seems like there should be a > > simpler method. I do realize that there will be no gain in fidelity > > or harmonic content.
I would interleave the signal with zeros in respect to the new sample rate upsampling requirements and then use somethng like cubic spline or barycentric lagrangian interpolation for best quality. -- Audio Poison
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.
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. Eric Jacobsen Anchor Hill Communications http://www.anchorhill.com