Thread: [Audacity-devel] Noise generators
A free multi-track audio editor and recorder
Brought to you by:
aosiniao
From: Steve t. F. <ste...@gm...> - 2013-01-22 17:42:55
|
Firstly may I congratulate everyone on the successful launch of Audacity 2.0.3. On to business. I've been looking at the noise generators. The "white" noise seems to be pretty good, but I think I can improve on the pink and brown noise. For the pink noise I'm looking at implementing Paul Kellet's "instrumentation grade" pink noise algorithm which is quite similar to the current method but the filter parameters are tuned to be accurate to within +/-0.05dB above 9.2Hz (44100Hz sampling rate). I already have a Nyquist implementation which works very well, but it should be a lot faster in C++. For the "brown" noise, our current implementation is not very "brown" It begins to rolls off at the relatively high frequency of around 100 Hz so that below 100 Hz it is essentially the same as white noise. I would presume that we want the brown noise to be bandwidth limited so as to avoid DC offset and an overly "sparse" waveform. My question is, what do we ideally want? Do we want a 6 dB per octave spectrum slope from 20 Hz to the Nyquist frequency? What do we want to do below 20 Hz? For audio use I would think that we want a reasonably steep roll-off below 20 Hz, but perhaps some users may want low frequency brown noise for use as "control signals" or other purposes. Perhaps there could be a 4th noise item for "Brown LF" that goes down to DC but normalized and with DC removed and the "standard" brown noise could roll-off below 20 Hz. Steve |
From: Roger D. <rb...@cs...> - 2013-01-22 18:27:20
|
Can't you just integrate white noise to get 6dB/octave rolloff, and high-pass filter if you want to eliminate DC? I'm not sure why Nyquist doesn't have pink noise built-in. I have a fairly fast implementation elsewhere (in C), but maybe making Kellet's algorithm a Nyquist primitive would be a good idea. -Roger On 1/22/13 12:42 PM, Steve the Fiddle wrote: > Firstly may I congratulate everyone on the successful launch of Audacity 2.0.3. > > On to business. I've been looking at the noise generators. > > The "white" noise seems to be pretty good, but I think I can improve > on the pink and brown noise. > > For the pink noise I'm looking at implementing Paul Kellet's > "instrumentation grade" pink noise algorithm which is quite similar to > the current method but the filter parameters are tuned to be accurate > to within +/-0.05dB above 9.2Hz (44100Hz sampling rate). I already > have a Nyquist implementation which works very well, but it should be > a lot faster in C++. > > For the "brown" noise, our current implementation is not very "brown" > It begins to rolls off at the relatively high frequency of around 100 > Hz so that below 100 Hz it is essentially the same as white noise. I > would presume that we want the brown noise to be bandwidth limited so > as to avoid DC offset and an overly "sparse" waveform. My question is, > what do we ideally want? > > Do we want a 6 dB per octave spectrum slope from 20 Hz to the Nyquist > frequency? What do we want to do below 20 Hz? For audio use I would > think that we want a reasonably steep roll-off below 20 Hz, but > perhaps some users may want low frequency brown noise for use as > "control signals" or other purposes. Perhaps there could be a 4th > noise item for "Brown LF" that goes down to DC but normalized and with > DC removed and the "standard" brown noise could roll-off below 20 Hz. > > Steve > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Rob S. <aq...@ya...> - 2013-01-22 19:05:50
|
----- Original Message ----- > From: Roger Dannenberg <rb...@cs...> > To: aud...@li... > > On 1/22/13 12:42 PM, Steve the Fiddle wrote: >> Firstly may I congratulate everyone on the successful launch of Audacity > 2.0.3. >> >> The "white" noise seems to be pretty good, but I think I can > improve >> on the pink and brown noise. Have you had a look at sox? I did a very simple (but effective, IIRC) brown-noise gen for that. There's also a pink noise gen there that might be worth a look. Cheers, Rob |
From: Steve t. F. <ste...@gm...> - 2013-01-22 21:06:59
|
On 22 January 2013 19:05, Rob Sykes <aq...@ya...> wrote: > ----- Original Message ----- > >> From: Roger Dannenberg <rb...@cs...> >> To: aud...@li... >> >> On 1/22/13 12:42 PM, Steve the Fiddle wrote: >>> Firstly may I congratulate everyone on the successful launch of Audacity >> 2.0.3. >>> >>> The "white" noise seems to be pretty good, but I think I can >> improve >>> on the pink and brown noise. > > > Have you had a look at sox? I did a very simple (but effective, IIRC) brown-noise gen for that. There's also a pink noise gen there that might be worth a look. > > Cheers, > Rob > No I've not looked at the SoX code yet, but I will. Thanks for the suggestion. I've been looking at quite a few algorithms for pink noise, and for one that is reasonably efficient, Paul Kellet's appears to be amongst the best. Also I think that it is within my (limited) ability to implement in C++ :=) Generating brown noise is very straightforward, either by integrating white noise (as Roger suggested) or with a 6 dB per octave filter. The question for brown noise is more of a philosophical / theoretical one - what do we want below 20 Hz? "Pure" brown noise goes all the way down to DC, but we don't want the waveform to drift off the audio track into never never land. Steve |
From: Martyn S. <mar...@gm...> - 2013-01-23 00:56:39
|
Hi Steve A few questions: What is your motivation for improving these generators? What is wrong with the ones we have (and I'm not opposed to improving them)? I see Paul Kellet's filter for pink noise at numerous places on the web, and it is probably a bit better than we have (and only slightly slower, I guess). I don't know where what we have came from. It's a pretty simple change I think. And if we really wanted to we may be able to do better than Kellet. What references are you referring to? I see that both these generators have an "experimental normalization factor" (that it appears I came up with) in order to only clip 'a bit'. Taking the roll-off frequency lower will presumably make this smaller and so the perceived loudness less. To what end? I can't hear below 20Hz. The 'brown noise' generator (which perhaps should be renamed 'Brownian noise') could easily be extended to 20Hz by changing the fc=100; to fc=20;, with a change to the amplitude variable to compensate. And are these generators looking at the sample rate, or just assuming 44100? The latter I think. TTFN Martyn On 22/01/2013 17:42, Steve the Fiddle wrote: > Firstly may I congratulate everyone on the successful launch of Audacity 2.0.3. > > On to business. I've been looking at the noise generators. > > The "white" noise seems to be pretty good, but I think I can improve > on the pink and brown noise. > > For the pink noise I'm looking at implementing Paul Kellet's > "instrumentation grade" pink noise algorithm which is quite similar to > the current method but the filter parameters are tuned to be accurate > to within +/-0.05dB above 9.2Hz (44100Hz sampling rate). I already > have a Nyquist implementation which works very well, but it should be > a lot faster in C++. > > For the "brown" noise, our current implementation is not very "brown" > It begins to rolls off at the relatively high frequency of around 100 > Hz so that below 100 Hz it is essentially the same as white noise. I > would presume that we want the brown noise to be bandwidth limited so > as to avoid DC offset and an overly "sparse" waveform. My question is, > what do we ideally want? > > Do we want a 6 dB per octave spectrum slope from 20 Hz to the Nyquist > frequency? What do we want to do below 20 Hz? For audio use I would > think that we want a reasonably steep roll-off below 20 Hz, but > perhaps some users may want low frequency brown noise for use as > "control signals" or other purposes. Perhaps there could be a 4th > noise item for "Brown LF" that goes down to DC but normalized and with > DC removed and the "standard" brown noise could roll-off below 20 Hz. > > Steve > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Steve t. F. <ste...@gm...> - 2013-01-23 02:44:56
|
On 23 January 2013 00:56, Martyn Shaw <mar...@gm...> wrote: > Hi Steve > > A few questions: > What is your motivation for improving these generators? Well it all started because I needed pink noise for a Nyquisr plug-in, and as there is no primitive for pink noise I had to code a pink noise generator myself. This, and a conversation on the forum, got me looking at various noise algorithms, and it's quite fascinating (in a geeky sort of way :=) > What is wrong with the ones we have (and I'm not opposed to improving > them)? The pink noise isn't at all bad, in fact I'm not yet convinced that Paul Kellet's filter is better, but it is said to be very good. The Brownian noise isn't great - below 100 Hz it is basically the same as white noise, so what colour is that, "chocolate mousse noise"? > > I see e aPaul Kellet's filter for pink noist numerous places on the > web, and it is probably a bit better than we have (and only slightly > slower, I guess). I don't know where what we have came from. It's a > pretty simple change I think. And if we really wanted to we may be > able to do better than Kellet. What references are you referring to? Here: http://www.firstpr.com.au/dsp/pink-noise/ > > I see that both these generators have an "experimental normalization > factor" (that it appears I came up with) in order to only clip 'a > bit'. Taking the roll-off frequency lower will presumably make this > smaller and so the perceived loudness less. To what end? I can't > hear below 20Hz. This is part of the question about what to do below 20 Hz. If frequencies below 20 Hz are rolled off, the perceived loudness can be increased because there will be less sub-sonic frequencies than now. The current "brown noise" has clearly less "bass" than it should have. > > The 'brown noise' generator (which perhaps should be renamed 'Brownian > noise') could easily be extended to 20Hz by changing the fc=100; to > fc=20;, with a change to the amplitude variable to compensate. > > And are these generators looking at the sample rate, or just assuming > 44100? The latter I think. I was expecting to see a significant difference at different sample rates, but there is surprisingly little. Steve > > TTFN > Martyn > > On 22/01/2013 17:42, Steve the Fiddle wrote: >> Firstly may I congratulate everyone on the successful launch of Audacity 2.0.3. >> >> On to business. I've been looking at the noise generators. >> >> The "white" noise seems to be pretty good, but I think I can improve >> on the pink and brown noise. >> >> For the pink noise I'm looking at implementing Paul Kellet's >> "instrumentation grade" pink noise algorithm which is quite similar to >> the current method but the filter parameters are tuned to be accurate >> to within +/-0.05dB above 9.2Hz (44100Hz sampling rate). I already >> have a Nyquist implementation which works very well, but it should be >> a lot faster in C++. >> >> For the "brown" noise, our current implementation is not very "brown" >> It begins to rolls off at the relatively high frequency of around 100 >> Hz so that below 100 Hz it is essentially the same as white noise. I >> would presume that we want the brown noise to be bandwidth limited so >> as to avoid DC offset and an overly "sparse" waveform. My question is, >> what do we ideally want? >> >> Do we want a 6 dB per octave spectrum slope from 20 Hz to the Nyquist >> frequency? What do we want to do below 20 Hz? For audio use I would >> think that we want a reasonably steep roll-off below 20 Hz, but >> perhaps some users may want low frequency brown noise for use as >> "control signals" or other purposes. Perhaps there could be a 4th >> noise item for "Brown LF" that goes down to DC but normalized and with >> DC removed and the "standard" brown noise could roll-off below 20 Hz. >> >> Steve >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnnow-d2d >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Steve t. F. <ste...@gm...> - 2013-01-23 04:17:09
|
Attached is a patch based on Paul Kellet's "instrumentation grade" algorithm. I've also attached two images. "old.png" is the current Audacity version. "new.png is the patched version. As can be seen, the patched version is noticeably better at both low and high frequency ends. I think that I've also improved the "normalization factor" - the original version seems to be a bit too high. On my machine the patched version is a fraction slower than before, about 12 seconds to generate a 30 minute mono track compared with 10 seconds for the original code. Steve On 23 January 2013 02:44, Steve the Fiddle <ste...@gm...> wrote: > On 23 January 2013 00:56, Martyn Shaw <mar...@gm...> wrote: >> Hi Steve >> >> A few questions: >> What is your motivation for improving these generators? > > Well it all started because I needed pink noise for a Nyquisr plug-in, > and as there is no primitive for pink noise I had to code a pink noise > generator myself. This, and a conversation on the forum, got me > looking at various noise algorithms, and it's quite fascinating (in a > geeky sort of way :=) > >> What is wrong with the ones we have (and I'm not opposed to improving >> them)? > > The pink noise isn't at all bad, in fact I'm not yet convinced that > Paul Kellet's filter is better, but it is said to be very good. > The Brownian noise isn't great - below 100 Hz it is basically the same > as white noise, so what colour is that, "chocolate mousse noise"? > >> >> I see e aPaul Kellet's filter for pink noist numerous places on the >> web, and it is probably a bit better than we have (and only slightly >> slower, I guess). I don't know where what we have came from. It's a >> pretty simple change I think. And if we really wanted to we may be >> able to do better than Kellet. What references are you referring to? > > Here: http://www.firstpr.com.au/dsp/pink-noise/ > >> >> I see that both these generators have an "experimental normalization >> factor" (that it appears I came up with) in order to only clip 'a >> bit'. Taking the roll-off frequency lower will presumably make this >> smaller and so the perceived loudness less. To what end? I can't >> hear below 20Hz. > > This is part of the question about what to do below 20 Hz. If > frequencies below 20 Hz are rolled off, the perceived loudness can be > increased because there will be less sub-sonic frequencies than now. > The current "brown noise" has clearly less "bass" than it should have. > > >> >> The 'brown noise' generator (which perhaps should be renamed 'Brownian >> noise') could easily be extended to 20Hz by changing the fc=100; to >> fc=20;, with a change to the amplitude variable to compensate. >> >> And are these generators looking at the sample rate, or just assuming >> 44100? The latter I think. > > I was expecting to see a significant difference at different sample > rates, but there is surprisingly little. > > Steve > >> >> TTFN >> Martyn >> >> On 22/01/2013 17:42, Steve the Fiddle wrote: >>> Firstly may I congratulate everyone on the successful launch of Audacity 2.0.3. >>> >>> On to business. I've been looking at the noise generators. >>> >>> The "white" noise seems to be pretty good, but I think I can improve >>> on the pink and brown noise. >>> >>> For the pink noise I'm looking at implementing Paul Kellet's >>> "instrumentation grade" pink noise algorithm which is quite similar to >>> the current method but the filter parameters are tuned to be accurate >>> to within +/-0.05dB above 9.2Hz (44100Hz sampling rate). I already >>> have a Nyquist implementation which works very well, but it should be >>> a lot faster in C++. >>> >>> For the "brown" noise, our current implementation is not very "brown" >>> It begins to rolls off at the relatively high frequency of around 100 >>> Hz so that below 100 Hz it is essentially the same as white noise. I >>> would presume that we want the brown noise to be bandwidth limited so >>> as to avoid DC offset and an overly "sparse" waveform. My question is, >>> what do we ideally want? >>> >>> Do we want a 6 dB per octave spectrum slope from 20 Hz to the Nyquist >>> frequency? What do we want to do below 20 Hz? For audio use I would >>> think that we want a reasonably steep roll-off below 20 Hz, but >>> perhaps some users may want low frequency brown noise for use as >>> "control signals" or other purposes. Perhaps there could be a 4th >>> noise item for "Brown LF" that goes down to DC but normalized and with >>> DC removed and the "standard" brown noise could roll-off below 20 Hz. >>> >>> Steve >>> >>> ------------------------------------------------------------------------------ >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>> MVPs and experts. ON SALE this month only -- learn more at: >>> http://p.sf.net/sfu/learnnow-d2d >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnnow-d2d >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Martyn S. <mar...@gm...> - 2013-01-24 01:26:15
|
Patch looks fine to me. How did you come up with the 0.129f? I note that I have in the commit log: martynshaw 12/12/2006 23:55:36 - the 'experimental normalization factor's give about 0.1% clipping of the noise when an amplitude of '1' is selected. A compromise. On 23/01/2013 04:17, Steve the Fiddle wrote: > Attached is a patch based on Paul Kellet's "instrumentation grade" algorithm. > > I've also attached two images. "old.png" is the current Audacity > version. "new.png is the patched version. As can be seen, the patched > version is noticeably better at both low and high frequency ends. I > think that I've also improved the "normalization factor" - the > original version seems to be a bit too high. > > On my machine the patched version is a fraction slower than before, > about 12 seconds to generate a 30 minute mono track compared with 10 > seconds for the original code. 6 buffers instead of 5, 12s instead of 10s, about what we should expect I guess. > Steve > > > On 23 January 2013 02:44, Steve the Fiddle <ste...@gm...> wrote: >> On 23 January 2013 00:56, Martyn Shaw <mar...@gm...> wrote: >>> Hi Steve >>> >>> A few questions: >>> What is your motivation for improving these generators? >> >> Well it all started because I needed pink noise for a Nyquisr plug-in, >> and as there is no primitive for pink noise I had to code a pink noise >> generator myself. This, and a conversation on the forum, got me >> looking at various noise algorithms, and it's quite fascinating (in a >> geeky sort of way :=) >> >>> What is wrong with the ones we have (and I'm not opposed to improving >>> them)? >> >> The pink noise isn't at all bad, in fact I'm not yet convinced that >> Paul Kellet's filter is better, but it is said to be very good. >> The Brownian noise isn't great - below 100 Hz it is basically the same >> as white noise, so what colour is that, "chocolate mousse noise"? >> >>> >>> I see e aPaul Kellet's filter for pink noist numerous places on the >>> web, and it is probably a bit better than we have (and only slightly >>> slower, I guess). I don't know where what we have came from. It's a >>> pretty simple change I think. And if we really wanted to we may be >>> able to do better than Kellet. What references are you referring to? >> >> Here: http://www.firstpr.com.au/dsp/pink-noise/ What a horrible page, visually, and in many other ways! >>> >>> I see that both these generators have an "experimental normalization >>> factor" (that it appears I came up with) in order to only clip 'a >>> bit'. Taking the roll-off frequency lower will presumably make this >>> smaller and so the perceived loudness less. To what end? I can't >>> hear below 20Hz. >> >> This is part of the question about what to do below 20 Hz. If >> frequencies below 20 Hz are rolled off, the perceived loudness can be >> increased because there will be less sub-sonic frequencies than now. >> The current "brown noise" has clearly less "bass" than it should have. >> >> >>> >>> The 'brown noise' generator (which perhaps should be renamed 'Brownian >>> noise') could easily be extended to 20Hz by changing the fc=100; to >>> fc=20;, with a change to the amplitude variable to compensate. 'Brown noise' and 'Brownian noise' have very different meanings! Let's rename it! >>> And are these generators looking at the sample rate, or just assuming >>> 44100? The latter I think. >> >> I was expecting to see a significant difference at different sample >> rates, but there is surprisingly little. I see what you mean. TTFN Martyn >> Steve >> >>> >>> TTFN >>> Martyn >>> >>> On 22/01/2013 17:42, Steve the Fiddle wrote: >>>> Firstly may I congratulate everyone on the successful launch of Audacity 2.0.3. >>>> >>>> On to business. I've been looking at the noise generators. >>>> >>>> The "white" noise seems to be pretty good, but I think I can improve >>>> on the pink and brown noise. >>>> >>>> For the pink noise I'm looking at implementing Paul Kellet's >>>> "instrumentation grade" pink noise algorithm which is quite similar to >>>> the current method but the filter parameters are tuned to be accurate >>>> to within +/-0.05dB above 9.2Hz (44100Hz sampling rate). I already >>>> have a Nyquist implementation which works very well, but it should be >>>> a lot faster in C++. >>>> >>>> For the "brown" noise, our current implementation is not very "brown" >>>> It begins to rolls off at the relatively high frequency of around 100 >>>> Hz so that below 100 Hz it is essentially the same as white noise. I >>>> would presume that we want the brown noise to be bandwidth limited so >>>> as to avoid DC offset and an overly "sparse" waveform. My question is, >>>> what do we ideally want? >>>> >>>> Do we want a 6 dB per octave spectrum slope from 20 Hz to the Nyquist >>>> frequency? What do we want to do below 20 Hz? For audio use I would >>>> think that we want a reasonably steep roll-off below 20 Hz, but >>>> perhaps some users may want low frequency brown noise for use as >>>> "control signals" or other purposes. Perhaps there could be a 4th >>>> noise item for "Brown LF" that goes down to DC but normalized and with >>>> DC removed and the "standard" brown noise could roll-off below 20 Hz. >>>> >>>> Steve >>>> >>>> ------------------------------------------------------------------------------ >>>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >>>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>>> MVPs and experts. ON SALE this month only -- learn more at: >>>> http://p.sf.net/sfu/learnnow-d2d >>>> _______________________________________________ >>>> audacity-devel mailing list >>>> aud...@li... >>>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>>> >>> >>> ------------------------------------------------------------------------------ >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>> MVPs and experts. ON SALE this month only -- learn more at: >>> http://p.sf.net/sfu/learnnow-d2d >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>> MVPs and experts. ON SALE this month only -- learn more at: >>> http://p.sf.net/sfu/learnnow-d2d >>> >>> >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Rob S. <aq...@ya...> - 2013-01-23 12:37:38
|
----- Original Message ----- > From: Steve the Fiddle <ste...@gm...> > To: Audacity-Devel list <aud...@li...> > Cc: > Sent: Wednesday, 23 January 2013, 4:17 > Subject: Re: [Audacity-devel] Noise generators > > Attached is a patch based on Paul Kellet's "instrumentation grade" > algorithm. That looks good; the one in sox is a bit faster (than both old and new here) but not as accurate. Re-looking at sox's brown noise, it seems good, speed & quality-wise. The behaviour < 20Hz is such that the amplitude > 20Hz is not forced down much. White noise through a single-pole LPF at say 1Hz is of course, more accurate < 20 Hz, but it pushes down the amplitude in the audible part of the band for no apparent (to me) benefit. Cheers, Rob |
From: Gale A. <ga...@au...> - 2013-01-24 12:35:02
|
| From Steve the Fiddle <ste...@gm...> | Thu, 24 Jan 2013 01:28:27 +0000 | Subject: [Audacity-quality] [Audacity-devel] Noise generators > Cc'd to -quality > > There's a bug in the Brown Noise generator. A click is produced at > intervals of 262,144 samples. This is fixed in my current code, but I > still don't know what low frequency response is preferred. > > The attached images are: > > new-hp-brown-noise.png: This gives a reasonably straight 6 dB/octave > response down to 20 Hz and is rolled off with a 15 Hz second order > high-pass filter. > > new-brown-noise.png: The same as above without the low frequency roll-off. > > audacity-brown-noise.png: The current Audacity implementation. > > For comparison purposes, each track has been normalized to roughly the > same loudness and all show about -54 dB at 1 kHz. > The two new versions sound virtually identical. > The unfiltered version looks best, but it tends to be rather quiet as > the subsonic frequencies prevent the level being raised without > clipping. > The filtered version can be made about 4.5 dB "louder" than the > unfiltered version before clipping. > The Audacity version is the loudest, but clearly lacks low bass. > > I think that both new versions are "better" (more "Brownian") than the > current Audacity version. The question is, do we provide sub-sonic > brown noise and leave it to the user to filter out if they don't want > it, or are the noise generators intended to be "audio band" (20Hz - > 20kHz) generators? > > An audio sample is available here: > http://easyspacepro.com/audacity/examples/brown-noise-x3.flac > It has three short samples: > 1) Unfiltered new version. > 2) Filtered new version > 3) Current Audacity version. > These samples were taken from the same tracks as the images. Thanks, Steve. I agree that the spectra of 1) and 2) look more "correct" than 3). Listening with speakers or headphones I hear a pronounced "beating" every 500 ms or so in 2) which is not very "relaxing" (which I thought was one "purpose" of generating this softer more muffled type of noise). So I much prefer 1) I think users who generate noise should get what they asked for without filtering. I would not as a naive user expect filtering to be done. > I also agree with Martyn that it would be more accurate to rename > "Brown" as "Brownian". +1. Gale > > Steve > > On 23 January 2013 12:37, Rob Sykes <aq...@ya...> wrote: > > ----- Original Message ----- > > > >> From: Steve the Fiddle <ste...@gm...> > >> To: Audacity-Devel list <aud...@li...> > >> Cc: > >> Sent: Wednesday, 23 January 2013, 4:17 > >> Subject: Re: [Audacity-devel] Noise generators > >> > >> Attached is a patch based on Paul Kellet's "instrumentation grade" > >> algorithm. > > > > That looks good; the one in sox is a bit faster (than both old and new here) but not as accurate. > > > > Re-looking at sox's brown noise, it seems good, speed & quality-wise. The behaviour < 20Hz is such that the amplitude > 20Hz is not forced down much. White noise through a single-pole LPF at say 1Hz is of course, more accurate < 20 Hz, but it pushes down the amplitude in the audible part of the band for no apparent (to me) benefit. |
From: Steve t. F. <ste...@gm...> - 2013-01-24 17:17:46
|
On 24 January 2013 12:33, Gale Andrews <ga...@au...> wrote: [snip] > > Thanks, Steve. > > I agree that the spectra of 1) and 2) look more "correct" than 3). > > Listening with speakers or headphones I hear a pronounced > "beating" every 500 ms or so in 2) which is not very "relaxing" > (which I thought was one "purpose" of generating this softer > more muffled type of noise). So I much prefer 1) I don't notice a "beating" myself, though it could just be on that one audio clip. If you are looping the sample you are likely to notice "patterns" that are really just random variations (clustering) that would not be present on a longer sample. I could post a longer sample, but see below... > > I think users who generate noise should get what they asked > for without filtering. I would not as a naive user expect filtering > to be done. I'm inclined to go with unfiltered, but my reservation is that the perceived volume will be rather low - also there may be a possibility of damage to speakers if a user plays unfiltered brown noise too loud. Perhaps the manual could give a warning about this if we agree to use unfiltered brown noise? If there are no contrary votes I'll go with unfiltered brown noise. > > >> I also agree with Martyn that it would be more accurate to rename >> "Brown" as "Brownian". > > +1. OK, "Brownian" it is. Steve |
From: Gale A. <ga...@au...> - 2013-01-24 19:05:51
|
| From Steve the Fiddle <ste...@gm...> | Thu, 24 Jan 2013 17:17:35 +0000 | Subject: [Audacity-quality] [Audacity-devel] Noise generators > On 24 January 2013 12:33, Gale Andrews <ga...@au...> wrote: > [snip] > > > > > Thanks, Steve. > > > > I agree that the spectra of 1) and 2) look more "correct" than 3). > > > > Listening with speakers or headphones I hear a pronounced > > "beating" every 500 ms or so in 2) which is not very "relaxing" > > (which I thought was one "purpose" of generating this softer > > more muffled type of noise). So I much prefer 1) > > I don't notice a "beating" myself, though it could just be on that one > audio clip. If you are looping the sample you are likely to notice > "patterns" that are really just random variations (clustering) that > would not be present on a longer sample. I could post a longer sample, > but see below... No, I'm not looping. > > I think users who generate noise should get what they asked > > for without filtering. I would not as a naive user expect filtering > > to be done. > > I'm inclined to go with unfiltered, but my reservation is that the > perceived volume will be rather low - also there may be a possibility > of damage to speakers if a user plays unfiltered brown noise too loud. > Perhaps the manual could give a warning about this if we agree to use > unfiltered brown noise? Does the existing brown noise carry a risk of subsonic damage? Gale > > If there are no contrary votes I'll go with unfiltered brown noise. > > > > > > >> I also agree with Martyn that it would be more accurate to rename > >> "Brown" as "Brownian". > > > > +1. > > OK, "Brownian" it is. > > Steve |
From: Steve t. F. <ste...@gm...> - 2013-01-24 19:18:46
|
>> > I think users who generate noise should get what they asked >> > for without filtering. I would not as a naive user expect filtering >> > to be done. >> >> I'm inclined to go with unfiltered, but my reservation is that the >> perceived volume will be rather low - also there may be a possibility >> of damage to speakers if a user plays unfiltered brown noise too loud. >> Perhaps the manual could give a warning about this if we agree to use >> unfiltered brown noise? > > Does the existing brown noise carry a risk of subsonic damage? > Possibly, but less so than the new version because proportionally the existing version has a lot less bass and sub-bass, so it sounds a lot louder for the same peak amplitude. I guess that if their speakers start rattling then they should get the hint that they're driving then too hard. Steve > > Gale > >> >> If there are no contrary votes I'll go with unfiltered brown noise. >> >> > >> > >> >> I also agree with Martyn that it would be more accurate to rename >> >> "Brown" as "Brownian". >> > >> > +1. >> >> OK, "Brownian" it is. >> >> Steve > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > Audacity-quality mailing list > Aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-quality |
From: Steve t. F. <ste...@gm...> - 2013-01-24 01:28:37
|
Cc'd to -quality There's a bug in the Brown Noise generator. A click is produced at intervals of 262,144 samples. This is fixed in my current code, but I still don't know what low frequency response is preferred. The attached images are: new-hp-brown-noise.png: This gives a reasonably straight 6 dB/octave response down to 20 Hz and is rolled off with a 15 Hz second order high-pass filter. new-brown-noise.png: The same as above without the low frequency roll-off. audacity-brown-noise.png: The current Audacity implementation. For comparison purposes, each track has been normalized to roughly the same loudness and all show about -54 dB at 1 kHz. The two new versions sound virtually identical. The unfiltered version looks best, but it tends to be rather quiet as the subsonic frequencies prevent the level being raised without clipping. The filtered version can be made about 4.5 dB "louder" than the unfiltered version before clipping. The Audacity version is the loudest, but clearly lacks low bass. I think that both new versions are "better" (more "Brownian") than the current Audacity version. The question is, do we provide sub-sonic brown noise and leave it to the user to filter out if they don't want it, or are the noise generators intended to be "audio band" (20Hz - 20kHz) generators? An audio sample is available here: http://easyspacepro.com/audacity/examples/brown-noise-x3.flac It has three short samples: 1) Unfiltered new version. 2) Filtered new version 3) Current Audacity version. These samples were taken from the same tracks as the images. I also agree with Martyn that it would be more accurate to rename "Brown" as "Brownian". Steve On 23 January 2013 12:37, Rob Sykes <aq...@ya...> wrote: > ----- Original Message ----- > >> From: Steve the Fiddle <ste...@gm...> >> To: Audacity-Devel list <aud...@li...> >> Cc: >> Sent: Wednesday, 23 January 2013, 4:17 >> Subject: Re: [Audacity-devel] Noise generators >> >> Attached is a patch based on Paul Kellet's "instrumentation grade" >> algorithm. > > That looks good; the one in sox is a bit faster (than both old and new here) but not as accurate. > > Re-looking at sox's brown noise, it seems good, speed & quality-wise. The behaviour < 20Hz is such that the amplitude > 20Hz is not forced down much. White noise through a single-pole LPF at say 1Hz is of course, more accurate < 20 Hz, but it pushes down the amplitude in the audible part of the band for no apparent (to me) benefit. > > Cheers, > Rob > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Martyn S. <mar...@gm...> - 2013-01-25 01:19:12
|
On 24/01/2013 01:28, Steve the Fiddle wrote: > Cc'd to -quality > > There's a bug in the Brown Noise generator. A click is produced at > intervals of 262,144 samples. This is fixed in my current code, Oh, well spotted! 2^18. Why is that? Please put your code up for review. but I > still don't know what low frequency response is preferred. Well we are primarily about audio, and that traditionally mean 20Hz - 20kHz. We have users interested in bats and whales, and we try and accommodate them where we can, but perhaps not here. So the roll off below 20 Hz would be my preference. I don't want to damage my speakers testing this! And if we were to go for 'no filtering', we would have to strive to go to dc, which isn't sensible. Gale's idea of 'without filtering' is unrealistic. Thanks for your work here :-). TTFN Martyn > The attached images are: > > new-hp-brown-noise.png: This gives a reasonably straight 6 dB/octave > response down to 20 Hz and is rolled off with a 15 Hz second order > high-pass filter. > > new-brown-noise.png: The same as above without the low frequency roll-off. > > audacity-brown-noise.png: The current Audacity implementation. > > For comparison purposes, each track has been normalized to roughly the > same loudness and all show about -54 dB at 1 kHz. > The two new versions sound virtually identical. > The unfiltered version looks best, but it tends to be rather quiet as > the subsonic frequencies prevent the level being raised without > clipping. > The filtered version can be made about 4.5 dB "louder" than the > unfiltered version before clipping. > The Audacity version is the loudest, but clearly lacks low bass. > > I think that both new versions are "better" (more "Brownian") than the > current Audacity version. The question is, do we provide sub-sonic > brown noise and leave it to the user to filter out if they don't want > it, or are the noise generators intended to be "audio band" (20Hz - > 20kHz) generators? > > An audio sample is available here: > http://easyspacepro.com/audacity/examples/brown-noise-x3.flac > It has three short samples: > 1) Unfiltered new version. > 2) Filtered new version > 3) Current Audacity version. > These samples were taken from the same tracks as the images. > > I also agree with Martyn that it would be more accurate to rename > "Brown" as "Brownian". > > Steve > > On 23 January 2013 12:37, Rob Sykes <aq...@ya...> wrote: >> ----- Original Message ----- >> >>> From: Steve the Fiddle <ste...@gm...> >>> To: Audacity-Devel list <aud...@li...> >>> Cc: >>> Sent: Wednesday, 23 January 2013, 4:17 >>> Subject: Re: [Audacity-devel] Noise generators >>> >>> Attached is a patch based on Paul Kellet's "instrumentation grade" >>> algorithm. >> >> That looks good; the one in sox is a bit faster (than both old and new here) but not as accurate. >> >> Re-looking at sox's brown noise, it seems good, speed & quality-wise. The behaviour < 20Hz is such that the amplitude > 20Hz is not forced down much. White noise through a single-pole LPF at say 1Hz is of course, more accurate < 20 Hz, but it pushes down the amplitude in the audible part of the band for no apparent (to me) benefit. >> >> Cheers, >> Rob >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnnow-d2d >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnnow-d2d >> >> >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Steve t. F. <ste...@gm...> - 2013-01-25 03:10:39
|
On 25 January 2013 01:19, Martyn Shaw <mar...@gm...> wrote: > > > On 24/01/2013 01:28, Steve the Fiddle wrote: >> Cc'd to -quality >> >> There's a bug in the Brown Noise generator. A click is produced at >> intervals of 262,144 samples. This is fixed in my current code, > > Oh, well spotted! 2^18. Why is that? Please put your code up for > review. My assumption is that it is related to Audacity working with blocks. Each time a new block is started the effect is "reset", which poses a potential problem of the next block not matching up with the previous block. My solution is to make the "out" ("y") value private so that it survives from one block to the next. I'm not sure that is the right approach, but it seems to work :=) > > but I >> still don't know what low frequency response is preferred. > > Well we are primarily about audio, and that traditionally mean 20Hz - > 20kHz. We have users interested in bats and whales, and we try and > accommodate them where we can, but perhaps not here. So the roll off > below 20 Hz would be my preference. I don't want to damage my > speakers testing this! And if we were to go for 'no filtering', we > would have to strive to go to dc, which isn't sensible. Gale's idea > of 'without filtering' is unrealistic. I quite like the "leaky integrator" method of producing brown noise - it avoids excessive DC offset while still providing a good "Brownian" result. SoX uses an approach that is interesting and relates to recent discussions on the forum, which is to "constrain" the noise within a 0dB range. I need to think about this, but it looks good :=) Steve > > Thanks for your work here :-). > > TTFN > Martyn > >> The attached images are: >> >> new-hp-brown-noise.png: This gives a reasonably straight 6 dB/octave >> response down to 20 Hz and is rolled off with a 15 Hz second order >> high-pass filter. >> >> new-brown-noise.png: The same as above without the low frequency roll-off. >> >> audacity-brown-noise.png: The current Audacity implementation. >> >> For comparison purposes, each track has been normalized to roughly the >> same loudness and all show about -54 dB at 1 kHz. >> The two new versions sound virtually identical. >> The unfiltered version looks best, but it tends to be rather quiet as >> the subsonic frequencies prevent the level being raised without >> clipping. >> The filtered version can be made about 4.5 dB "louder" than the >> unfiltered version before clipping. >> The Audacity version is the loudest, but clearly lacks low bass. >> >> I think that both new versions are "better" (more "Brownian") than the >> current Audacity version. The question is, do we provide sub-sonic >> brown noise and leave it to the user to filter out if they don't want >> it, or are the noise generators intended to be "audio band" (20Hz - >> 20kHz) generators? >> >> An audio sample is available here: >> http://easyspacepro.com/audacity/examples/brown-noise-x3.flac >> It has three short samples: >> 1) Unfiltered new version. >> 2) Filtered new version >> 3) Current Audacity version. >> These samples were taken from the same tracks as the images. >> >> I also agree with Martyn that it would be more accurate to rename >> "Brown" as "Brownian". >> >> Steve >> >> On 23 January 2013 12:37, Rob Sykes <aq...@ya...> wrote: >>> ----- Original Message ----- >>> >>>> From: Steve the Fiddle <ste...@gm...> >>>> To: Audacity-Devel list <aud...@li...> >>>> Cc: >>>> Sent: Wednesday, 23 January 2013, 4:17 >>>> Subject: Re: [Audacity-devel] Noise generators >>>> >>>> Attached is a patch based on Paul Kellet's "instrumentation grade" >>>> algorithm. >>> >>> That looks good; the one in sox is a bit faster (than both old and new here) but not as accurate. >>> >>> Re-looking at sox's brown noise, it seems good, speed & quality-wise. The behaviour < 20Hz is such that the amplitude > 20Hz is not forced down much. White noise through a single-pole LPF at say 1Hz is of course, more accurate < 20 Hz, but it pushes down the amplitude in the audible part of the band for no apparent (to me) benefit. >>> >>> Cheers, >>> Rob >>> >>> ------------------------------------------------------------------------------ >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>> MVPs and experts. ON SALE this month only -- learn more at: >>> http://p.sf.net/sfu/learnnow-d2d >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >>> >>> ------------------------------------------------------------------------------ >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>> MVPs and experts. ON SALE this month only -- learn more at: >>> http://p.sf.net/sfu/learnnow-d2d >>> >>> >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel |
From: Rob S. <aq...@ya...> - 2013-01-25 06:12:43
|
----- Original Message ----- > From: Martyn Shaw <mar...@gm...> > accommodate them where we can, but perhaps not here. So the roll off > below 20 Hz would be my preference. I don't want to damage my > speakers testing this! And if we were to go for 'no filtering', we I don't think there's any danger of speaker damage from either of Steve's proposals (only, at the low end, from pure DC @ 0dB, or something very close to it). Cheers, Rob |
From: Gale A. <ga...@au...> - 2013-01-29 21:10:39
|
Steve wrote: > Patch to upgrade pink noise and brown (Brownian) noise. > > The pink noise uses Paul Kellet's high quality pink noise filter. > > "Brown" noise has been renamed "Brownian" and uses "leaky > integration". Peaks are constrained to within 0dB (a little trick that > I picked up from the SoX code) so the Brownian noise is now a bit > louder than it would otherwise be, without any clipping. I think you worked wonders on the sound of that brown noise, Steve. It really sounds like that waterfall someone wanted. The brown does "look" a little odd (some might say "clipped") compared to the released brown noise, if you generate several minutes' worth so that it's fitted to the window. But it certainly sounds good (no "beating"). Gale > The glitch that was occurring each 2^18 samples in both pink and brown > noise has been fixed. |
From: Steve t. F. <ste...@gm...> - 2013-01-31 00:49:06
Attachments:
noise-gen-2.patch
|
A minor update. This patch also fixes a ToDo: that I spotted in the code. // TODO: Make colon part of the translatable string after 2.0. Steve On 29 January 2013 21:09, Gale Andrews <ga...@au...> wrote: > > Steve wrote: >> Patch to upgrade pink noise and brown (Brownian) noise. >> >> The pink noise uses Paul Kellet's high quality pink noise filter. >> >> "Brown" noise has been renamed "Brownian" and uses "leaky >> integration". Peaks are constrained to within 0dB (a little trick that >> I picked up from the SoX code) so the Brownian noise is now a bit >> louder than it would otherwise be, without any clipping. > > I think you worked wonders on the sound of that brown noise, > Steve. It really sounds like that waterfall someone wanted. > > The brown does "look" a little odd (some might say "clipped") > compared to the released brown noise, if you generate several > minutes' worth so that it's fitted to the window. > > But it certainly sounds good (no "beating"). > > > > Gale > > >> The glitch that was occurring each 2^18 samples in both pink and brown >> noise has been fixed. > > |
From: Steve t. F. <ste...@gm...> - 2013-01-26 20:58:35
Attachments:
noise-gen.patch
|
Patch to upgrade pink noise and brown (Brownian) noise. The pink noise uses Paul Kellet's high quality pink noise filter. "Brown" noise has been renamed "Brownian" and uses "leaky integration". Peaks are constrained to within 0dB (a little trick that I picked up from the SoX code) so the Brownian noise is now a bit louder than it would otherwise be, without any clipping. The glitch that was occurring each 2^18 samples in both pink and brown noise has been fixed. Steve |
From: Martyn S. <mar...@gm...> - 2013-01-28 00:39:38
|
Hi Steve I've had a look over your patch and done a few tests of my own. The patch is basically good, but is it needed / wanted? The pink noise differences do extend the bandwidth of 'pink' down an octave or two, but does anyone really care about that or want it? Or would it harm them? I think that was part of your original question. Putting the roll-off an octave or two below my hearing seems a bit mad to me. On the Brown/Brownian noise, I don't like the clipping test and would rather have a lower overall level. And again I see no real reason to extend the LF cutoff much below 20Hz. We could change that in the original code by setting fc at a different value, I think. The fixes for the limitations at 2^18 samples are good, from what I can see. Would you like to make a patch just for that, so I can commit it? For the 'brown' (brownian) noise, the original code had b1=exp(-2*M_PI*fc/fs); a0=1.0f-b1; and we can see how the 'magic numbers' were generated. http://www.idsc.ethz.ch/Courses/signals_and_systems/lectureNotes10.pdf is an example. I am inclined to move that fc to 20Hz, and readjust the normalisation factor, but I haven't tried that. Perhaps a solution to this would be to have an extra option on the noise generator dialog to set the LF roll-off of these generators to some frequency. That way users could get what they want. This would be a 'rather advanced' option however. Are there any user request for this? TTFN Martyn PS Steve sent the following useful Nyquist code to run at the "Nyquist Prompt" effect ;; print the % of clipped samples (mono tracks only) (setq clipped (do ((count 0) (val (snd-fetch s)(snd-fetch s))) ((not val) count) (if (> (abs val) 1)(setq count (1+ count))))) (print (* 100 (/ clipped len))) On 26/01/2013 20:58, Steve the Fiddle wrote: > Patch to upgrade pink noise and brown (Brownian) noise. > > The pink noise uses Paul Kellet's high quality pink noise filter. > > "Brown" noise has been renamed "Brownian" and uses "leaky > integration". Peaks are constrained to within 0dB (a little trick that > I picked up from the SoX code) so the Brownian noise is now a bit > louder than it would otherwise be, without any clipping. > > The glitch that was occurring each 2^18 samples in both pink and brown > noise has been fixed. > > Steve > > > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > > > > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Richard A. <ri...@au...> - 2013-01-28 21:00:38
|
On Mon, 28 Jan 2013 00:39:30 +0000 Martyn Shaw <mar...@gm...> wrote: > I've had a look over your patch and done a few tests of my own. > The patch is basically good, but is it needed / wanted? > > The pink noise differences do extend the bandwidth of 'pink' down an > octave or two, but does anyone really care about that or want it? When I get my SPL meter (1/3 octave bands) working I am likely to want accurate (so rather better than -3dB) pink noise down to 40Hz as a test source, so I can be sure that the roll-off I see is due to the equipment, not the noise source. I'd certainly be worried if getting that with Audacity was a major problem - narrow band noise can always be created with a filter on the result. Richard |
From: Steve t. F. <ste...@gm...> - 2013-01-28 02:21:57
|
Thanks for reviewing the patch Martyn, On 28 January 2013 00:39, Martyn Shaw <mar...@gm...> wrote: > Hi Steve > > I've had a look over your patch and done a few tests of my own. The patch > is basically good, but is it needed / wanted? I'd say yes, which is why I wrote it :=) I know that I previously raised a question about possible speaker damage if the low frequency range was extended too far, but that was considering an extreme case of Brownian noise with a low apparent "loudness" but high amplitude sub-sonic frequencies (or even DC). With this patch I don't believe there is a problem because the "constrained" brown noise has a reasonable loudness and the sub-sonic content is not extreme. > > The pink noise differences do extend the bandwidth of 'pink' down an octave > or two, but does anyone really care about that or want it? Or would it harm > them? I think that was part of your original question. Putting the > roll-off an octave or two below my hearing seems a bit mad to me. The bandwidth of the pink noise is not really much different from now, but the roll-off is a little more precise. This is probably the least "necessary" change, but there is a measurable improvement in quality with a negligible impact on speed, so why not? > > On the Brown/Brownian noise, I don't like the clipping test and would rather > have a lower overall level. I was unsure at first about the clipping test, but after a lot of thought I decided to go with it. There is the theoretical / philosophical argument that perhaps we shouldn't mess with the randomness, but I don't think that this criticism is justified. When considering Brownian motion of water molecules, it does not suddenly cease to be "Brownian" just because the water is in a container, and yet the walls of the container impose a limit on the motion of the particles in similar fashion to the clipping test. Essentially, sample values "bounce off" the 0 dB limit rather than being clipped. We have no qualms about constraining the absolute values of white noise. All we are actually doing is biasing the random increment for a tiny percentage of sample values so that the waveform is kept within reasonable bounds. Without such a test there is a small but finite chance that the waveform could drift off into space. so we have put a lid on it to prevent such "evaporation". The patched version is a lot less constrained than Brownian noise from SoX, but even with the very modest amount used in this patch the overall "loudness" can be increased by more than 4 dB. I think that the benefit of not clipping heavily outweighs arguments against, as any clipping will create much more "damage" than constraining the absolute sample values for a few peaks. > And again I see no real reason to extend the LF > cutoff much below 20Hz. I agree, which is why the 6 dB/octave slope is "only" extended to 20 Hz. > We could change that in the original code by > setting fc at a different value, I think. I did try that, but to achieve a similar degree of linearity down to 20 Hz, the amount of sub-sonic frequencies was about 3 dB greater than the current patch. > > The fixes for the limitations at 2^18 samples are good, from what I can see. > Would you like to make a patch just for that, so I can commit it? > > For the 'brown' (brownian) noise, the original code had > b1=exp(-2*M_PI*fc/fs); > a0=1.0f-b1; > and we can see how the 'magic numbers' were generated. > http://www.idsc.ethz.ch/Courses/signals_and_systems/lectureNotes10.pdf > is an example. I am inclined to move that fc to 20Hz, and readjust the > normalisation factor, but I haven't tried that. I did try that, and also a more complex low pass filter, but neither worked as well as the leaky integrator method. One problem with filtering white noise is that the amplitude is highly dependent on the sample rate. For a track sample rate of 192 kHz the peak amplitude of Brown noise is about 3dB too low, whereas at for a sample rate of 8000 Hz the peak level is about 10 dB too high. The only adverse effect that sample rate has on the patched version is that at high sample rates the bandwidth does not extend as low as at 44.1 kHz, but even at 192 kHz sample rate it is no worse than the current version. Even this limitation has a benefit, in that if a user requires low frequency Brownian noise, they can produce it by generating with a low sample rate. The current Audacity "Brown" noise is definitely too light on the bass when listening on good speakers, so I think that this improvement is definitely justified. Now that the potential risk of excessive sub-sonic frequencies has been alleviated I'm very much inclined to go with the previously stated opinion of giving the user what it says on the tin. Steve > > Perhaps a solution to this would be to have an extra option on the noise > generator dialog to set the LF roll-off of these generators to some > frequency. That way users could get what they want. This would be a > 'rather advanced' option however. Are there any user request for this? > > TTFN > Martyn > > PS Steve sent the following useful Nyquist code to run at the "Nyquist > Prompt" effect > > ;; print the % of clipped samples (mono tracks only) > (setq clipped > (do ((count 0) > (val (snd-fetch s)(snd-fetch s))) > ((not val) count) > (if (> (abs val) 1)(setq count (1+ count))))) > (print (* 100 (/ clipped len))) > > > On 26/01/2013 20:58, Steve the Fiddle wrote: >> >> Patch to upgrade pink noise and brown (Brownian) noise. >> >> The pink noise uses Paul Kellet's high quality pink noise filter. >> >> "Brown" noise has been renamed "Brownian" and uses "leaky >> integration". Peaks are constrained to within 0dB (a little trick that >> I picked up from the SoX code) so the Brownian noise is now a bit >> louder than it would otherwise be, without any clipping. >> >> The glitch that was occurring each 2^18 samples in both pink and brown >> noise has been fixed. >> >> Steve >> >> >> >> >> ------------------------------------------------------------------------------ >> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >> MVPs and experts. ON SALE this month only -- learn more at: >> http://p.sf.net/sfu/learnnow-d2d >> >> >> >> _______________________________________________ >> audacity-devel mailing list >> aud...@li... >> https://lists.sourceforge.net/lists/listinfo/audacity-devel >> > |
From: Martyn S. <mar...@gm...> - 2013-01-31 01:23:39
|
On 28/01/2013 02:21, Steve the Fiddle wrote: > Thanks for reviewing the patch Martyn, > > On 28 January 2013 00:39, Martyn Shaw <mar...@gm...> wrote: >> Hi Steve >> >> I've had a look over your patch and done a few tests of my own. The patch >> is basically good, but is it needed / wanted? > > I'd say yes, which is why I wrote it :=) Fair enough :) > I know that I previously raised a question about possible speaker > damage if the low frequency range was extended too far, but that was > considering an extreme case of Brownian noise with a low apparent > "loudness" but high amplitude sub-sonic frequencies (or even DC). With > this patch I don't believe there is a problem because the > "constrained" brown noise has a reasonable loudness and the sub-sonic > content is not extreme. > >> >> The pink noise differences do extend the bandwidth of 'pink' down an octave >> or two, but does anyone really care about that or want it? Or would it harm >> them? I think that was part of your original question. Putting the >> roll-off an octave or two below my hearing seems a bit mad to me. > > The bandwidth of the pink noise is not really much different from now, > but the roll-off is a little more precise. This is probably the least > "necessary" change, but there is a measurable improvement in quality > with a negligible impact on speed, so why not? OK, I can go with that. >> >> On the Brown/Brownian noise, I don't like the clipping test and would rather >> have a lower overall level. > > I was unsure at first about the clipping test, but after a lot of > thought I decided to go with it. > > There is the theoretical / philosophical argument that perhaps we > shouldn't mess with the randomness, but I don't think that this > criticism is justified. When considering Brownian motion of water > molecules, it does not suddenly cease to be "Brownian" just because > the water is in a container, and yet the walls of the container impose > a limit on the motion of the particles in similar fashion to the > clipping test. Essentially, sample values "bounce off" the 0 dB limit > rather than being clipped. Hmm. OK. But why have the container so small? We can be closer to 'ideal' (no container) if we make the container bigger (== the signal smaller). It's always going to be a compromise. I'd rather have a smaller percentage of samples hitting the limit (and I have been testing with 10 million samples) > We have no qualms about constraining the absolute values of white > noise. (This is a misconception about 'white' noise. White noise has no correlation from sample to sample but has no restriction on the pdf. I used to use AWGN (additive white Gaussian noise) in a project I worked on, since it was the most appropriate; independent noise samples but with a Gaussian (Normal) distribution. It's still 'white'.) All we are actually doing is biasing the random increment for a > tiny percentage of sample values so that the waveform is kept within > reasonable bounds. We are arguing about the definition of 'tiny' here, I think. Your implementation does 'look' clipped to me (and Gale). Without such a test there is a small but finite > chance that the waveform could drift off into space. Indeed. so we have put a > lid on it to prevent such "evaporation". Indeed, and the method seems reasonable, in the sense that it is easy and I can't think of anything better at the moment. > > The patched version is a lot less constrained than Brownian noise from > SoX, I have not looked at that. but even with the very modest amount used in this patch the > overall "loudness" can be increased by more than 4 dB. I think that > the benefit of not clipping heavily outweighs arguments against, as > any clipping will create much more "damage" than constraining the > absolute sample values for a few peaks. That seems reasonable. But again it's just a matter of at what level we do something. >> And again I see no real reason to extend the LF >> cutoff much below 20Hz. > > I agree, which is why the 6 dB/octave slope is "only" extended to 20 Hz. > >> We could change that in the original code by >> setting fc at a different value, I think. > > I did try that, but to achieve a similar degree of linearity down to > 20 Hz, the amount of sub-sonic frequencies was about 3 dB greater than > the current patch. OK, thanks. You have spent much more time on this than me, and I trust your observations. >> >> The fixes for the limitations at 2^18 samples are good, from what I can see. >> Would you like to make a patch just for that, so I can commit it? Oh, go on! Just for a start! >> For the 'brown' (brownian) noise, the original code had >> b1=exp(-2*M_PI*fc/fs); >> a0=1.0f-b1; >> and we can see how the 'magic numbers' were generated. >> http://www.idsc.ethz.ch/Courses/signals_and_systems/lectureNotes10.pdf >> is an example. I am inclined to move that fc to 20Hz, and readjust the >> normalisation factor, but I haven't tried that. > > I did try that, and also a more complex low pass filter, but neither > worked as well as the leaky integrator method. One problem with > filtering white noise is that the amplitude is highly dependent on the > sample rate. For a track sample rate of 192 kHz the peak amplitude of > Brown noise is about 3dB too low, whereas at for a sample rate of 8000 > Hz the peak level is about 10 dB too high. OK, but where do you get the 'magic numbers' (0.997f and 0.05) from? If they are in some way derived from / related to the sample rate then we should include that in the code so that it works at all sample rates. If they are experimental and derived at 44100 could we scale them by fs/44100? > The only adverse effect that sample rate has on the patched version is > that at high sample rates the bandwidth does not extend as low as at > 44.1 kHz, but even at 192 kHz sample rate it is no worse than the > current version. Even this limitation has a benefit, in that if a user > requires low frequency Brownian noise, they can produce it by > generating with a low sample rate. > > The current Audacity "Brown" noise is definitely too light on the bass > when listening on good speakers, so I think that this improvement is > definitely justified. Now that the potential risk of excessive > sub-sonic frequencies has been alleviated I'm very much inclined to go > with the previously stated opinion of giving the user what it says on > the tin. I am 'for' changes along these lines. It is a minority sport and possibly won't get revisited in a while so just looking to get it the best we can at the moment. Thanks for all your input here Steve. Martyn > Steve > >> >> Perhaps a solution to this would be to have an extra option on the noise >> generator dialog to set the LF roll-off of these generators to some >> frequency. That way users could get what they want. This would be a >> 'rather advanced' option however. Are there any user request for this? >> >> TTFN >> Martyn >> >> PS Steve sent the following useful Nyquist code to run at the "Nyquist >> Prompt" effect >> >> ;; print the % of clipped samples (mono tracks only) >> (setq clipped >> (do ((count 0) >> (val (snd-fetch s)(snd-fetch s))) >> ((not val) count) >> (if (> (abs val) 1)(setq count (1+ count))))) >> (print (* 100 (/ clipped len))) >> >> >> On 26/01/2013 20:58, Steve the Fiddle wrote: >>> >>> Patch to upgrade pink noise and brown (Brownian) noise. >>> >>> The pink noise uses Paul Kellet's high quality pink noise filter. >>> >>> "Brown" noise has been renamed "Brownian" and uses "leaky >>> integration". Peaks are constrained to within 0dB (a little trick that >>> I picked up from the SoX code) so the Brownian noise is now a bit >>> louder than it would otherwise be, without any clipping. >>> >>> The glitch that was occurring each 2^18 samples in both pink and brown >>> noise has been fixed. >>> >>> Steve >>> >>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, >>> MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current >>> with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft >>> MVPs and experts. ON SALE this month only -- learn more at: >>> http://p.sf.net/sfu/learnnow-d2d >>> >>> >>> >>> _______________________________________________ >>> audacity-devel mailing list >>> aud...@li... >>> https://lists.sourceforge.net/lists/listinfo/audacity-devel >>> >> > > ------------------------------------------------------------------------------ > Master Visual Studio, SharePoint, SQL, ASP.NET, C# 2012, HTML5, CSS, > MVC, Windows 8 Apps, JavaScript and much more. Keep your skills current > with LearnDevNow - 3,200 step-by-step video tutorials by Microsoft > MVPs and experts. ON SALE this month only -- learn more at: > http://p.sf.net/sfu/learnnow-d2d > _______________________________________________ > audacity-devel mailing list > aud...@li... > https://lists.sourceforge.net/lists/listinfo/audacity-devel > |
From: Steve t. F. <ste...@gm...> - 2013-01-31 19:34:16
Attachments:
noise-262144-sample-bug.patch
|
On 31 January 2013 01:23, Martyn Shaw <mar...@gm...> wrote: > > > On 28/01/2013 02:21, Steve the Fiddle wrote: >> >> Thanks for reviewing the patch Martyn, >> >> On 28 January 2013 00:39, Martyn Shaw <mar...@gm...> wrote: [snip] >> All we are actually doing is biasing the random increment for a >> >> tiny percentage of sample values so that the waveform is kept within >> reasonable bounds. > > > We are arguing about the definition of 'tiny' here, I think. Your > implementation does 'look' clipped to me (and Gale). > > > Without such a test there is a small but finite >> >> chance that the waveform could drift off into space. > > > Indeed. > > > so we have put a >> >> lid on it to prevent such "evaporation". > > > Indeed, and the method seems reasonable, in the sense that it is easy and I > can't think of anything better at the moment. > > >> >> The patched version is a lot less constrained than Brownian noise from >> SoX, > > > I have not looked at that. Please do. Personally I think the SoX Brownian noise is overly constrained, which is why I have gone for a lower level. Of course we may get complaints that the (new) Audacity Brownian noise is too quiet (compared with SoX). > > > but even with the very modest amount used in this patch the >> >> overall "loudness" can be increased by more than 4 dB. I think that >> the benefit of not clipping heavily outweighs arguments against, as >> any clipping will create much more "damage" than constraining the >> absolute sample values for a few peaks. > > > That seems reasonable. But again it's just a matter of at what level we do > something. Good, so the argument is not about whether we constrain the values, but by how much. I've been testing with the default 30 seconds, and that does not particularly look clipped, in fact , when generated at a level of 1.0 it "looks" no more clipped than the current version - the difference being that the current version does clip. The problem is that, the longer the generated noise, the more it will "look" clipped because the "constraining" is more visible. Some users may want to generate 30 minutes of noise for a "relaxation CD", whereas other users may only generate 1 second for synthesizing a drum sound. Options: 1) "less fluid in the container" so that it is less constrained, but then generating short durations will produce a waveform that is too small. 2) We can adjust the level according to the duration so that longer periods are generated at a lower level than short periods. I'm not sure that we would want to do that. Users are not likely to expect a long noise to be quieter than a short noise. 3) We could high pass filter the noise. For example a second order high pass filter at 15 Hz will cause the peak level to "drift" less over time (which was my original question - what do we want to do with low frequencies). 4) Leave it as it is and accept that long durations will "look" clipped. Personally I'd vote for (4) and I think that users will be happy that the peak level is what they asked for. Zooming in proves that it isn't clipped. Can you think of any other options? [snip] >>> The fixes for the limitations at 2^18 samples are good, from what I can >>> see. >>> Would you like to make a patch just for that, so I can commit it? > > > Oh, go on! Just for a start! > The attached fixes (only) the 2^18 sample glitch (for brown and pink noise) and the "Todo:" . [snip] > > OK, but where do you get the 'magic numbers' (0.997f and 0.05) from? If they > are in some way derived from / related to the sample rate then we should > include that in the code so that it works at all sample rates. If they are > experimental and derived at 44100 could we scale them by fs/44100? > > >> The only adverse effect that sample rate has on the patched version is >> that at high sample rates the bandwidth does not extend as low as at >> 44.1 kHz, but even at 192 kHz sample rate it is no worse than the >> current version. Even this limitation has a benefit, in that if a user >> requires low frequency Brownian noise, they can produce it by >> generating with a low sample rate. >> Yes, those numbers are experimental at 44100 Hz, and yes I'm pretty sure they could be scaled according to the sample rate. I think that I can solve the "problem" of the low frequency response being dependent on sample rate - if we want to do that. I think we probably do - do you agree? Steve |