You can subscribe to this list here.
2001 
_{Jan}

_{Feb}

_{Mar}

_{Apr}

_{May}

_{Jun}

_{Jul}

_{Aug}

_{Sep}

_{Oct}
(50) 
_{Nov}
(77) 
_{Dec}
(169) 

2002 
_{Jan}
(139) 
_{Feb}
(147) 
_{Mar}
(111) 
_{Apr}
(348) 
_{May}
(262) 
_{Jun}
(294) 
_{Jul}
(315) 
_{Aug}
(186) 
_{Sep}
(132) 
_{Oct}
(135) 
_{Nov}
(358) 
_{Dec}
(241) 
2003 
_{Jan}
(557) 
_{Feb}
(489) 
_{Mar}
(361) 
_{Apr}
(378) 
_{May}
(493) 
_{Jun}
(348) 
_{Jul}
(289) 
_{Aug}
(259) 
_{Sep}
(322) 
_{Oct}
(463) 
_{Nov}
(305) 
_{Dec}
(201) 
2004 
_{Jan}
(198) 
_{Feb}
(186) 
_{Mar}
(192) 
_{Apr}
(216) 
_{May}
(175) 
_{Jun}
(200) 
_{Jul}
(277) 
_{Aug}
(127) 
_{Sep}
(64) 
_{Oct}
(208) 
_{Nov}
(170) 
_{Dec}
(154) 
2005 
_{Jan}
(239) 
_{Feb}
(171) 
_{Mar}
(123) 
_{Apr}
(55) 
_{May}
(74) 
_{Jun}
(100) 
_{Jul}
(129) 
_{Aug}
(221) 
_{Sep}
(209) 
_{Oct}
(270) 
_{Nov}
(590) 
_{Dec}
(313) 
2006 
_{Jan}
(377) 
_{Feb}
(189) 
_{Mar}
(234) 
_{Apr}
(180) 
_{May}
(230) 
_{Jun}
(404) 
_{Jul}
(574) 
_{Aug}
(300) 
_{Sep}
(424) 
_{Oct}
(444) 
_{Nov}
(363) 
_{Dec}
(153) 
2007 
_{Jan}
(223) 
_{Feb}
(106) 
_{Mar}
(311) 
_{Apr}
(233) 
_{May}
(336) 
_{Jun}
(278) 
_{Jul}
(467) 
_{Aug}
(416) 
_{Sep}
(550) 
_{Oct}
(503) 
_{Nov}
(483) 
_{Dec}
(271) 
2008 
_{Jan}
(344) 
_{Feb}
(127) 
_{Mar}
(416) 
_{Apr}
(381) 
_{May}
(679) 
_{Jun}
(749) 
_{Jul}
(549) 
_{Aug}
(281) 
_{Sep}
(137) 
_{Oct}
(324) 
_{Nov}
(200) 
_{Dec}
(330) 
2009 
_{Jan}
(634) 
_{Feb}
(438) 
_{Mar}
(560) 
_{Apr}
(387) 
_{May}
(313) 
_{Jun}
(443) 
_{Jul}
(947) 
_{Aug}
(505) 
_{Sep}
(477) 
_{Oct}
(679) 
_{Nov}
(714) 
_{Dec}
(407) 
2010 
_{Jan}
(348) 
_{Feb}
(283) 
_{Mar}
(232) 
_{Apr}
(173) 
_{May}
(79) 
_{Jun}
(109) 
_{Jul}
(128) 
_{Aug}
(62) 
_{Sep}
(118) 
_{Oct}
(153) 
_{Nov}
(57) 
_{Dec}
(76) 
2011 
_{Jan}
(105) 
_{Feb}
(150) 
_{Mar}
(314) 
_{Apr}
(266) 
_{May}
(55) 
_{Jun}
(47) 
_{Jul}
(113) 
_{Aug}
(70) 
_{Sep}
(77) 
_{Oct}
(93) 
_{Nov}
(106) 
_{Dec}
(190) 
2012 
_{Jan}
(68) 
_{Feb}
(188) 
_{Mar}
(313) 
_{Apr}
(80) 
_{May}
(122) 
_{Jun}
(222) 
_{Jul}
(94) 
_{Aug}
(239) 
_{Sep}
(64) 
_{Oct}
(164) 
_{Nov}
(168) 
_{Dec}
(277) 
2013 
_{Jan}
(336) 
_{Feb}
(156) 
_{Mar}
(80) 
_{Apr}
(135) 
_{May}
(150) 
_{Jun}
(139) 
_{Jul}
(160) 
_{Aug}
(266) 
_{Sep}
(386) 
_{Oct}
(465) 
_{Nov}
(366) 
_{Dec}
(156) 
2014 
_{Jan}
(190) 
_{Feb}
(88) 
_{Mar}
(60) 
_{Apr}
(38) 
_{May}
(146) 
_{Jun}
(104) 
_{Jul}
(189) 
_{Aug}
(424) 
_{Sep}
(235) 
_{Oct}
(990) 
_{Nov}
(598) 
_{Dec}
(393) 
2015 
_{Jan}
(256) 
_{Feb}
(40) 
_{Mar}
(195) 
_{Apr}
(497) 
_{May}
(227) 
_{Jun}
(138) 
_{Jul}
(257) 
_{Aug}
(351) 
_{Sep}
(151) 
_{Oct}
(119) 
_{Nov}
(78) 
_{Dec}
(16) 
2016 
_{Jan}
(225) 
_{Feb}
(289) 
_{Mar}
(267) 
_{Apr}
(318) 
_{May}
(198) 
_{Jun}
(177) 
_{Jul}
(155) 
_{Aug}
(268) 
_{Sep}
(175) 
_{Oct}
(56) 
_{Nov}
(147) 
_{Dec}
(67) 
2017 
_{Jan}
(110) 
_{Feb}
(148) 
_{Mar}
(191) 
_{Apr}
(210) 
_{May}
(164) 
_{Jun}
(261) 
_{Jul}
(332) 
_{Aug}
(349) 
_{Sep}
(37) 
_{Oct}

_{Nov}

_{Dec}

S  M  T  W  T  F  S 






1
(2) 
2
(2) 
3
(2) 
4
(6) 
5
(3) 
6
(11) 
7
(18) 
8
(9) 
9
(8) 
10
(2) 
11

12
(1) 
13
(1) 
14
(2) 
15

16
(1) 
17
(6) 
18
(9) 
19
(6) 
20
(5) 
21
(1) 
22
(3) 
23

24

25
(3) 
26
(5) 
27
(5) 
28
(4) 
29
(1) 
30
(5) 
31
(8) 






From: Vaughan Johnson <vaughan@au...>  20050708 20:13:35

 Original Message  Subject: Re: [Audacityhelp] Info on. future for Audacity! Date: Fri, 08 Jul 2005 13:09:29 0700 From: Vaughan Johnson <vaughan@...> To: bass <bassplayer_it@...> References: <20050708170716.69897.qmail@...> Thanks, & thanks for offering. I'll forward this to the developer list in case anybody has a task for you. Vaughan bass wrote: >You are the best!!! :) > > >If you need something about logos and little >graphics works compositions, ask to me. > >This FOR FREE, naturally. > > >BYE > > > > > 
From: Markus Meyer <meyer@me...>  20050708 17:48:58

Dan Albers schrieb: >Yes. Hopefully this isn't something which will delay the release of the next >version of Audacity. > This has already delayed the next version of Audacity for some time (although it isn't the only bug which is a mustfix for 1.3). Markus 
From: Dan Albers <computing@kp...>  20050708 17:41:13

On Friday 08 July 2005 10:13 am, Lynn Allan wrote: > > This seems to have raised quite a number of emails! > > Soooooo ... > > does one person (or more) understand the problem(s) well enough to > fix, test, and commit the changes? > > (not me, certainly ... I could barely follow the technical aspects of > most of this thread) Yes. Hopefully this isn't something which will delay the release of the next version of Audacity. BTW, when will the new version show up in /usr/ports/audio? DOA 
From: Lynn Allan <l_d_allan@ad...>  20050708 17:17:15

> This seems to have raised quite a number of emails! Soooooo ... does one person (or more) understand the problem(s) well enough to fix, test, and commit the changes? (not me, certainly ... I could barely follow the technical aspects of most of this thread) 
From: Craig DeForest <craig@de...>  20050708 05:58:27

The noise removal filter uses a running FFT and simply zeroes out components that don't make the "cut" in each window, with some smoothing to avoid ringing artifacts. There are some shenanigans to prevent the filtration from messing up the Hanning envelope of each window  that is a kludge designed to get rid of artifacts at the window boundaries. On Jul 7, 2005, at 11:40 PM, Monty wrote: > > > > On Thu, Jul 07, 2005 at 06:34:32AM 0600, Lynn Allan wrote: > >> Just wondering .... does all the discussion about the fft >> equalization >> also have applicability to noiseremoval? >> > > Depends on how the noise removal filter works. If it's blockbased > (using overlapping FFTs), then that likely qualifies as a flaw in > itself and several of the things I mentioned (specifically frequency > multiplication) apply. > > You generally can't use an FFT in a situation where the transfer > function in the frequency domain is changing from frame to frame, and > even then you have to make sure the window / transfer function you're > using obeys a number of criteria. If the noise removal is doing > time>freq, doing noise removal (usually an expansion) in the > frequency domain, then transforming back to time... yeah, it has this > problem. Noise removal is going to have fidelity problems by its very > nature, one should strive to remove the faults that are preventable > :) > > (A very old version of Postfish, a completely different program from > the current Postfish but did several similar things, had a firsttry > compander/noise gate that used the flawed design and you could listen > to it pitchshift the vocals. It took a while to notice > actually... but once I realized what the problem was, it was > impossible *not* to hear :) > > You can use an FFT to subband from time>time, operate on the > subbands, and that will be fine. Modern Postfish's companders, gates > and noise removal filters work this way. > > I can well imagine cases where you would want to do the companding the > 'flawed' way, but only in the case where the designer is exactly aware > of the 'rules' he's breaking and for what reason the 'wrong' way comes > out ahead. > > All that said... I have not yet read the compressor or noise removal > code. I don't know if Audacity's noise removal has any avoidable > design flaws as I find noise removal/gating to be very tricky to tune, > and so I always do that step in Postfish where I can make changes > realtime while I'm listening to the track. > > Monty > > > >  > This SF.Net email is sponsored by the 'Do More With Dual!' webinar > happening > July 14 at 8am PDT/11am EDT. We invite you to explore the latest in > dual > core and dual graphics technology at this free one hour event > hosted by HP, > AMD, and NVIDIA. To register visit http://www.hp.com/go/dualwebinar > _______________________________________________ > Audacitydevel mailing list > Audacitydevel@... > https://lists.sourceforge.net/lists/listinfo/audacitydevel > > > > 
From: <xiphmont@xi...>  20050708 05:48:19

On Thu, Jul 07, 2005 at 09:12:49PM 0400, MartynShaw@... wrote: > I agree with everything that has been said about IEEE754 should be good > enough for audio samples but that is not the issue here. I said it is the core > of the FFT that is the problem, further to that it is the bit that does the > DIT (decimation in time) butterflies and more specifically the way in which the > twiddle factors are calculated. So we *do* have a bad FFT? Even when there are so many reliable canned ones! I guess that makes at least four flaws. :) I wrote the C DRFT in Netlib (well, not really; it's derived from the Fortran version) and gave a more modern copy of that FFT to Dominic last summer when he was trying to decide if FFTW's licensing issues were worth it. I thought that meant Audacity was already using either my FFT or FFTW... I was apparently wrong. Anyway, both behave respectably. Given that the full complex>complex FFT is a waste as the time domain signal is always real, we should simply replace it with a new dropin. > than float? I suspect on modern machines it is very little. And who wants > to use a longer window than 16384? That's about 0.4 seconds of blurring > already! It's not blurring, it's applying a larger sinc kernel. That's a good thing, not bad :) > Sorry for the rather long post, but I reserve the right to make > further long posts in the future! Feel free! This was a good one. Monty 
From: <xiphmont@xi...>  20050708 05:40:44

On Thu, Jul 07, 2005 at 06:34:32AM 0600, Lynn Allan wrote: > Just wondering .... does all the discussion about the fft equalization > also have applicability to noiseremoval? Depends on how the noise removal filter works. If it's blockbased (using overlapping FFTs), then that likely qualifies as a flaw in itself and several of the things I mentioned (specifically frequency multiplication) apply. You generally can't use an FFT in a situation where the transfer function in the frequency domain is changing from frame to frame, and even then you have to make sure the window / transfer function you're using obeys a number of criteria. If the noise removal is doing time>freq, doing noise removal (usually an expansion) in the frequency domain, then transforming back to time... yeah, it has this problem. Noise removal is going to have fidelity problems by its very nature, one should strive to remove the faults that are preventable :) (A very old version of Postfish, a completely different program from the current Postfish but did several similar things, had a firsttry compander/noise gate that used the flawed design and you could listen to it pitchshift the vocals. It took a while to notice actually... but once I realized what the problem was, it was impossible *not* to hear :) You can use an FFT to subband from time>time, operate on the subbands, and that will be fine. Modern Postfish's companders, gates and noise removal filters work this way. I can well imagine cases where you would want to do the companding the 'flawed' way, but only in the case where the designer is exactly aware of the 'rules' he's breaking and for what reason the 'wrong' way comes out ahead. All that said... I have not yet read the compressor or noise removal code. I don't know if Audacity's noise removal has any avoidable design flaws as I find noise removal/gating to be very tricky to tune, and so I always do that step in Postfish where I can make changes realtime while I'm listening to the track. Monty 
From: Monty <xiphmont@xi...>  20050708 05:25:56

Oh, BTW, should mention, I made a minor mistake in my analysis of the EQ last night: A Hanning window is in fact a sin^2 style window and would work for convolution via lapped FFT just fine (there are better choices for an EQ, but there's nothing really wrong with a Hanning window). What got me confused is that the window used in the source is labelled 'Hanning' but was not summing properly. I caught the error [in retrospect] while I was thinking about it in the shower this morning; FFT.c intends to implement a Hanning window, but has a oneoff error: in[i] *= 0.5  0.5 * cos(2 * M_PI * i / (NumSamples  1)); Should be either: in[i] *= 0.5  0.5 * cos(2 * M_PI * (i+.5) / NumSamples); for even symmetry or: in[i] *= 0.5  0.5 * cos(2 * M_PI * i / NumSamples); for odd symmetry. I prefer the latter. This looks like a minor mistake, but it will introduce audible noise. Monty 
From: <MartynShaw@ao...>  20050708 01:13:06

Hello everybody, This seems to have raised quite a number of emails! Rather than respond to all of them now, I will try and settle Audacity's FFT.cpp issue, and perhaps help to explain how the code implements FFT algorithm for anybody interested, if I may be so bold. I do not intend delving too deeply into the trigonometry. Sorry but I just can't seem to do short posts! I guess it's the lecturer coming out in me. I agree with everything that has been said about IEEE754 should be good enough for audio samples but that is not the issue here. I said it is the core of the FFT that is the problem, further to that it is the bit that does the DIT (decimation in time) butterflies and more specifically the way in which the twiddle factors are calculated. For a relevant diagram to help me explain myself, if anybody does not have a good book to hand on this subject (such as DSP by Oppenheim & Schafer, fig 6.7 or DSP A practical approach by Ifechor & Jervis, fig 12.34) please look at _http://www.cmlab.csie.ntu.edu.tw/cml/dsp/training/coding/transform/fft.html_ (http://www.cmlab.csie.ntu.edu.tw/cml/dsp/training/coding/transform/fft.html) and refer to figure TC.3.3 which shows the butterflies. Referring to the code in FFT.cpp, I have commented this here, in relation to these diagrams. You may want to read this bit twice to get it all. BlockEnd = 1; //We start off with one butterfly in each group for (BlockSize = 2; BlockSize <= NumSamples; BlockSize <<= 1) { //This steps through for each 'Stage' double delta_angle = angle_numerator / (double) BlockSize; //This is the angle used in the Wn calculations double sm2 = sin(2 * delta_angle); //various bits for the 'W0' value (see below) double sm1 = sin(delta_angle); double cm2 = cos(2 * delta_angle); double cm1 = cos(delta_angle); double w = 2 * cm1; double ar0, ar1, ar2, ai0, ai1, ai2; //The following nested loops do all the butterflys. On the diagram you see that at Stage 1 there are 4 distinct butterflys, at Stage 2 there are 2 groups of 2 and at Stage 3 there is one group of 4. Hence the nested loops. for (i = 0; i < NumSamples; i += BlockSize) { //Steps through each group of butterfly in each stage. i points to the sample to use for the top left limb of the first butterfly. ar2 = cm2; //copy bits for the 'W0' value ar1 = cm1; ai2 = sm2; ai1 = sm1; for (j = i, n = 0; n < BlockEnd; j++, n++) { //Step through each butterfly in this group ar0 = w * ar1  ar2; //Work out the sine and cosine components needed for the W values. These end up in ar0 and ai0 respectively ar2 = ar1; ar1 = ar0; ai0 = w * ai1  ai2; ai2 = ai1; ai1 = ai0; k = j + BlockEnd; //the number of the sample for the bottom limb of the butterfly tr = ar0 * RealOut[k]  ai0 * ImagOut[k]; //use those two input values and actually do the calculation of the butterfly... ti = ar0 * ImagOut[k] + ai0 * RealOut[k]; RealOut[k] = RealOut[j]  tr; //and update the values  this is an inplace implementation so you just replace the input values (which actually are the bitreversaled values) ImagOut[k] = ImagOut[j]  ti; RealOut[j] += tr; ImagOut[j] += ti; } } BlockEnd = BlockSize; //next time round there will be more butterflys in the group } Ok, so the W0 (I can't do superscripts) value gets set at the start of each group (the 'i' loop) and FROM THAT VALUE (and associated variables) the W1, W2, W3 etc get calculated without anymore reference to a 'sin' or 'cos' functions. Let's see what happens at the final Stage of the algorithm, as that is where the j/n loop goes around most times. We are only interested in the inner (j/n) loop as this is where the iteration occurs. Assume that the size of the FFT is N (to save me typing NumSamples too many times) then: BlockEnd=N/2, Blocksize=N, delta_angle=2*pi/N and j=0 I want to cut down all the code to the problem and so here is the core code (in C), edited directly from Audacity's FFT.cpp to illustrate the problem. I have duplicated the 'sine' and 'cos' calculations in both float and double and as a direct calculation. It should be cut, paste, compilable if you want to spreadsheet the results and look at the errors yourself. #include <stdlib.h> #include <stdio.h> #include <math.h> void main(void) { int j, n; int BlockSize = 4096; //or whatever  problems grow rapidly as you increase this (in powers of 2) int BlockEnd = BlockSize/2; double angle_numerator = 2.0 * M_PI; double delta_angle = angle_numerator / (double) BlockSize; float sm2f = sin(2 * delta_angle); float sm1f = sin(delta_angle); float cm2f = cos(2 * delta_angle); float cm1f = cos(delta_angle); float wf = 2 * cm1f; float ar0f, ar1f, ar2f, ai0f, ai1f, ai2f; double sm2d = sin(2 * delta_angle); double sm1d = sin(delta_angle); double cm2d = cos(2 * delta_angle); double cm1d = cos(delta_angle); double wd = 2 * cm1d; double ar0d, ar1d, ar2d, ai0d, ai1d, ai2d; ar2f = cm2f; ar1f = cm1f; ai2f = sm2f; ai1f = sm1f; ar2d = cm2d; ar1d = cm1d; ai2d = sm2d; ai1d = sm1d; for (j = 0, n = 0; n < BlockEnd; j++, n++) { /* just the tightest loop left here, with the most iterations */ ar0f = wf * ar1f  ar2f; ar2f = ar1f; ar1f = ar0f; ai0f = wf * ai1f  ai2f; ai2f = ai1f; ai1f = ai0f; ar0d = wd * ar1d  ar2d; ar2d = ar1d; ar1d = ar0d; ai0d = wd * ai1d  ai2d; ai2d = ai1d; ai1d = ai0d; printf("%f\t%f\t%f\t%f\t%f\t%f\n",ai0f,ar0f,ai0d,ar0d,sin(2.0*M_PI*j/BlockSize),cos(2.0*M_PI*j/BlockSize)); } } I have provided a zipped xls at with a graph or two at _http://members.aol.com/MartynShaw/fft_test.zip_ (http://members.aol.com/MartynShaw/fft_test.zip) . It shows that 8000 iterations later the errors have built up to a magnitude of 0.4 and that the W values are nothing like what they should be. The errors in the double values remain at zero throughout (but they might not for extremely long BlockSizes) As I said before these values calculated from previous values are prone to error. Why not just use sin(2.0*M_PI*j/BlockSize) and cos(2.0*M_PI*j/BlockSize) instead of those other bits of trig (which I have not gone into, because my trig book is elsewhere)? I guess it is due to timing issues  cos and sin take more machine cycles than these routines but is that relevant anymore? I was thinking of taking a further look at making the Audacity FFT go faster in a different way but what are the penalties of switching to double, rather than float? I suspect on modern machines it is very little. And who wants to use a longer window than 16384? That's about 0.4 seconds of blurring already! Sorry for the rather long post, but I reserve the right to make further long posts in the future! Martyn 