[music-dsp] Re: MinBLEP table

Jan jan at rpgfan.demon.co.uk
Fri Aug 9 09:42:29 EDT 2002


> I can give you mathematica code, eli and julius smith both have matlab
code,
> you can probably download a complex number class and an fft library and do
> it yourself in c code but it's much easier using a maths package. There
are
> quite a few different ones and they really help in trying out algorithms
> before using c/c++.
Alright, I didn't know you could download a free program like scilab. If you
could post your code, or someone else could post their matlab code they'd
make both me and Rob happy bunnies =)

> You will want to play around with different sizes and windows etc so it's
> best that you can generate your own tables but I will do one for you right
> now. What size table do you want? 50 zero crossing and 20 times
oversampled?
Let's say 64x oversampled like Eli's table, but 48 zero crossings (instead
of 16)


>
> - --andy
>
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Thu, 8 Aug 2002 15:41:00 +0100
> From: "Rob Belcham" <robbelcham at blueyonder.co.uk>
> Subject: RE: [music-dsp] re: MinBLEP's
>
> Hi fellow minBleppers, I'm really stuck and was wondering if there's
anyone
> here who could point me in the right direction.
>
> I've been struggling trying to find a bug in my minBlep implementation. I
> have 2 versions, one 'simulated' version on the PC, and one version on a
> 16-bit fixed point DSP (written in assembler). My problem is that despite
> all my efforts, the  hardware DSP version still exhibits unacceptable
levels
> of aliased frequencies. It's looks like the corrections are having little
or
> no effect. When I switch the corrections on and off, I see the aliases
drop
> by only about 12 dB, whereas on the PC version, the aliases are MUCH
lower,
> and only present for high oscillator frequencies.
>
> I am using a 16-bit blep table, double precision phase accumulator for the
> main osc phase and to avoid the divide :-
>
> alpha = phase_acc / phase_inc,
>
> I am multiplying the MSW of the phase accumulator by an integer 1/freq -
> i.e. period, to get a 16-bit fractional number (upper 16 bits is always
0),
> before multiplying this by the oversampling factor, to get an initial
> integer and fractional offset into the Blep table.
>
> I think I have modelled this correctly in the PC to check the accuracy of
> the 'optimised' algorithm and it still seems to be OK, so I am at a loss
to
> explain the differences. At one point, I convinced myself that only using
an
> integer period was the problem, so I changed the DSP code to take the
> fractional part of the period into account as well, but it doesn't seem to
> have made any difference at all - except to the cycle count!!!
>
> Can anyone think of anything to try? I've been looking at the same damn
bit
> of code for too long now. What else could be causing the aliases ?
>
> Unfortunately I don't have access to a DSP emulator, and another problem
is
> that I am seeing the output of my oscillators after it has passed through
a
> codec, so I am seeing a mixture of blep corrections and the codec's filter
> response at the oscillator discontinuities.
>
> I'm 99.9% sure the corrections are scaled correctly and are active for the
> correct number of samples (2*NumZeroCrossing) because if I replace the
blep
> table with a linear ramp, I can see it clearly in the output :-
>   ___    ___                        ___
>      \__/   \___/ e.t.c instead of |   |___|
>
> ps. Any chance someone could post a matlab script to generate the minblep
> table ?
>
> Thanks in advance
> Rob Belcham
>
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Thu, 8 Aug 2002 13:04:00 -0400
> From: "James Chandler Jr." <jchandjr at bellsouth.net>
> Subject: Re: [music-dsp] compression
>
> > Thanks James for your very infomative post - it's much
> > appreciated.  If anyone else is aware of any books or
> > other resources on implementing compressors digitally
> > - particularly emulations of classic compressors, then
> > I'd be very interested to hear from you.
>
> For sake of completeness, in the last message I omitted at least one major
> class of analog compressors--
>
> Tube variable-mu compressors. They control gain by modulating tube
> transconductance, somewhat analogous to semiconductor transconductance
> VCA's.
>
> Some of the most esteemed vintage compressors were vaiable-mu tube
designs.
> Real expensive both then and now, containing lots of parts.
>
> Never had a variable-mu compressor in the shop to experiment with, and not
> much has been written about their innards (that I've seen anyway). Only
know
> what I've read in music mags (which might not be accurate).
>
> Variable-mu compressors supposedly have a narrower range of compression
than
> some other approaches, but sound very "smooth."
>
> Ran across a web page that discusses various flavors of analog
compressors--
>
> http://archive.eqmag.com/0001/columns.shtml
>
> James Chandler Jr.
>
>
>
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Thu, 8 Aug 2002 20:20:59 +0200
> From: "Cournapeau David" <cournape at enst.fr>
> Subject: Re: [music-dsp] re: MinBLEP's
>
> > I'd like to write my own code, but I don't have either of those
programs,
> > and I'm not clued up enough to do it on a whim from scratch in C. If you
> > could do a table for me to include with the sourcecode that would be
> great.
> > If not I'll look into writing my own table generator sometime.
>
> If you want to study matlab codes and trying your onw, you should try
scilab
> or octave, free command line softwares, mostly compatible with matlab
source
> code.
>
> http://www-rocq.inria.fr/scilab/ this one is under a special license, I
> think
> binaries available for mac, linux, solaris, windows and others
>
> http://www.octave.org/ GPL license. Binaries available for linux and
> windows.
>
> Scilab is more complete, I think.
>
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Thu, 08 Aug 2002 17:35:34 -0700
> From: "Kirill 'Big K' Katsnelson" <kkm at dtmx.com>
> Subject: [music-dsp] Stopband ripple for a decimation filter
>
> How to specify the stopband ripple parameter for a decimation filter?
> Suppose I have a 160x oversampled audio signal (at ~7MHz).  I specify
> - -96dB stopband ripple, and come up with a 10K-tap FIR (ugh!).  What I
> am afraid of is that all this ripple is going to alias back up into the
> audible range after decimation, 319-fold.  I think that even at -96dB,
> the 7MHz-wide ripple still contains lots of power.
>
> How, if at all, should I adjust Astop for this?  RMS power estimate?
>
> Thanks,
>
>   -kkm
>
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Thu, 08 Aug 2002 22:54:44 -0300 (ART)
> From: "Sergio R. Caprile" <yogurthu at arnet.com.ar>
> Subject: RE: [music-dsp] 90 degree phase shifted addition
>
> Here you can see a plot of a phase lead network's phase response
>
>         http://www.geocities.com/scaprile/fx.html#phase_shift
>
> The function is phi=2*atan(1/(wRC)), where phi is in radians, and
corresponds
> to the transfer function T(s)=(sRC-1)/(sRC+1)
>
> 90 degrees is what you get at wRC=1, but the network response is a
function of
> frequency.
>
> I guess you used a phase lag network simulation, so your response is a
mirror
> of the picture. If you plot it in degrees, you'll see a near 180 degress
phase
> shift on low freqs (high freqs for a phase lag network). I guess this
explains
> what you've seen.
>
> The example above is for an analog circuit, but if you take the time to
> bilinear transform the above, you'll end up with an all-pass transfer
function:
> T(Z)=(a-Z^(-1))/(1-aZ^(-1)), see here:
>
>         http://www.geocities.com/scaprile/fxdsp.html#phaser
>
> Hope it helps, regards
>
>
> On 08-Aug-2002 Alexander Lerch wrote:
> > However, I implemented a phase shifter (linear phase and
> > quasilinear freq response from about 40Hz to 22kHz @44.1kHz).
> > I had to discover that the mono downmix (not the phase shift
> > itself) of one channel added with the other phase shifted
> > channel showed a siginificant loss at higher frequencies
> > compared to a "normal" downmix. The attenuation is between
> > 3-6dB at frequencies higher 6kHz for many real world signals.
> > This is definitely not a bug in my implementation as the phase
> > shift itself works perfect; it seems to be a general problem
> > of all phase shifted downmixes (I checked two digital and one
> > analog phase shifter).
> >
> > My problem is: why high frequencies? High frequencies should
> > be nearly uncorrelated, so IMHO it should not influence the
> > mono result if they are phase shifted or not.
> >
>
>
>
> - --
> - --------------------------------------------------------------
>  AMIGA | Sergio R. Caprile, Bs.As., Argentina |  DSP - Music  |
>    //  |   mailto: yogurthu at arnet.com.ar      |  Electronics  |
>  \X/   |   http://www.geocities.com/scaprile  | Tai Chi Chuan |
> - --------------------------------------------------------------
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Fri, 09 Aug 2002 09:01:52 +0200
> From: "Laurent de Soras [Ohm Force]" <laurent at ohmforce.com>
> Subject: Re: [music-dsp] Stopband ripple for a decimation filter
>
> Kirill 'Big K' Katsnelson wrote:
> >
> > Suppose I have a 160x oversampled audio signal (at ~7MHz).  I specify
> > -96dB stopband ripple, and come up with a 10K-tap FIR (ugh!).
>
> Did you try to mix polyphase IIR and FIR ? I think you
> can find here a good compromise between phase linearity /
> calculation power / stopband level / transition bandwidth.
>
> > am afraid of is that all this ripple is going to alias back up into the
> > audible range after decimation, 319-fold.  I think that even at -96dB,
> > the 7MHz-wide ripple still contains lots of power.
>
> It depends on the aliasing power, and how it is related to
> the signal. It is often lower than the "useful" signal, and
> decreasing with the frequency. Therefore specifying -N dB of
> stopband ripple for a filter generally gives an aliasing at
> least N dB under the main signal.
>
> - -- Laurent
>
> ==================================+========================
> Laurent de Soras                  |               Ohm Force
> DSP developer & Software designer |  Digital Audio Software
> mailto:laurent at ohmforce.com       | http://www.ohmforce.com
> ==================================+========================
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Fri, 9 Aug 2002 09:55:08 +0200
> From: "SIMON Benoit cdd FTRD/DIH/LAN" <benoit.simon at rd.francetelecom.com>
> Subject: [music-dsp] DSP & Hardware
>
> Hi All,
>
> I'm new to the list (since yesterday) and I already see there is a lot of
interristing stuff in it ! :)
> I'm French, i work in sound ingineering (coding, synthesis and analysis)
and I'm also interested in electronic music. I compose personnaly some
songs. I'd like to do some little sound editing software to create new
effects and this is the reason why I joint the list ...
> Here is my rookie question : "Is that compulsary to code a dsp algorithm
in C instead of coding it in C++, in a "hardware burning" scope ?". The C++
is well-known for its "squareness" but is the C better on a perfs point of
view (for a software and/or hardware) ? Thank you all ! And I hope I'll be
able to solve help u too !
>
> See u.
> Benot.
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Fri, 09 Aug 2002 10:54:25 +0200
> From: alexander lerch <lerch at zplane.de>
> Subject: Re: [music-dsp] 90 degree phase shifted addition
>
> Hi Sergio,
>
> Sergio R. Caprile schrieb:
>
>
> > I guess you used a phase lag network simulation, so your response is a
mirror
> > of the picture. If you plot it in degrees, you'll see a near 180 degress
phase
> > shift on low freqs (high freqs for a phase lag network). I guess this
explains
> > what you've seen.
>
>
> Good guess, but the phase response of my phase shifter is
> linear and frequency independent. It is a FIR-Filter with a
> symmetric IR.
>
> Thanks for help,
> Alexander
>
> - --
> dipl. ing.
> alexander lerch
>
> zplane.development
> http://www.zplane.de
> holsteinische str. 39-42
> D-12161 berlin
>  fon: +49.30.854 09 15.0
>  fax: +49.30.854 09 15.5
>
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> Date: Fri, 9 Aug 2002 06:17:51 -0400
> From: "Michael Gogins" <gogins at pipeline.com>
> Subject: RE: [music-dsp] DSP & Hardware
>
> If by "hardware burning" you mean embedded software for PROM, then I'm
> not an expert on that...
>
> But if you want to code for the host CPU, then C++ offers (if you follow
> a few simple rules) little or no speed disadvantage over C, and of
> course many language advantages, for DSP.
>
> The simple rules are: avoid late binding, use templates and the standard
> C++ library a lot, use expression templates if you can, be aware of when
> temporary objects might be created and avoid them (e.g. for matrix dot
> product use something like matrix A, B, C; C.dot(A, B); instead of C = A
> * B;).
>
>
> - -----Original Message-----
> From: owner-music-dsp at shoko.calarts.edu
> [mailto:owner-music-dsp at shoko.calarts.edu] On Behalf Of SIMON Benoit cdd
> FTRD/DIH/LAN
> Sent: Friday, August 09, 2002 3:55 AM
> To: music-dsp at shoko.calarts.edu
> Subject: [music-dsp] DSP & Hardware
>
>
> Hi All,
>
> I'm new to the list (since yesterday) and I already see there is a lot
> of interristing stuff in it ! :) I'm French, i work in sound ingineering
> (coding, synthesis and analysis) and I'm also interested in electronic
> music. I compose personnaly some songs. I'd like to do some little sound
> editing software to create new effects and this is the reason why I
> joint the list ... Here is my rookie question : "Is that compulsary to
> code a dsp algorithm in C instead of coding it in C++, in a "hardware
> burning" scope ?". The C++ is well-known for its "squareness" but is the
> C better on a perfs point of view (for a software and/or hardware) ?
> Thank you all ! And I hope I'll be able to solve help u too !
>
> See u.
> Benot.
>
> dupswapdrop -- the music-dsp mailing list and website: subscription
> info, FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
>
> dupswapdrop -- the music-dsp mailing list and website: subscription info,
> FAQ, source code archive, list archive, book reviews, dsp links
> http://shoko.calarts.edu/musicdsp/
>
> ------------------------------
>
> End of music-dsp-digest V1 #1601
> ********************************
>
>
> dupswapdrop: the music-dsp mailing list and website
> http://shoko.calarts.edu/music-dsp


dupswapdrop -- the music-dsp mailing list and website: subscription info,
FAQ, source code archive, list archive, book reviews, dsp links
http://shoko.calarts.edu/musicdsp/




More information about the music-dsp mailing list