What *exactly* is a noise burst

[mcbpete]

This maybe one more for devs - I mean, I know what one sounds like (especially on headphones, when working on a track in the dead of the night ) but I've always took it as read that machines in Buzz sometimes go mental and make noise bursts without questioning it.

I hadn't thought about it for a while as I hadn't had any for ages (possible a year or two), but listening to a track I made a few weeks ago on my new laptop last night I suddenly got one (BTW If I got a burst on this latop, but didn't on the old one then would it necessarily follow that Multi-threading may have caused it, or is it just 'one of those things' ?). But yeah, it suddenly made me question about the whole burst thing - what does the buzz generator (or effect) produce to suddenly trigger this chain of chaotic white noise and is there something to prevent it from happening ?

[Grids]

I would really like to know this as well.
I swear the ringing in my ears at night is getting louder from buzz' noisebursts....and the noisebursts are occurring more frequently...

Does anyone have tips....

I think I have narrowed the problem down to one of these machines or a combination...

Unwiedly Tracker - Usually after using different sample types
Funkyverb - This shows up with lots of errors in the CPU meter especially when I put it after a compressor....also I use crudloads of reverb in all my tracks
BG Sidechain - Basically it just stops working. Sometimes there is no sound through it at all and other times the ducking stops completely. i have started another thread just to talk about my sidechain problems.

Polac Out - I use this out of Utracker (I know there is a new Utrk and I have downloaded it but I used utrk on all my old tracks)
using mute in the arrangment view... - I hear that this can cause problems ?
Polac VST/i - Synthedit plugins often don't work anymore...(they used to)


I just downloaded the new Polac stuff
I edited the gear.xml to disable multithreading in the unwiedly tracker, Polac Out, BG sidechain....

Please note I am using Nu buzz but it is not a current version (I will update to a current version in a few months when I get a new laptop). I am using Vista 64 bit Ultimate.

[Joachip]

A noise burst is like a Merzbow concert, only shorter.

[mcbpete]

Is there a way to configure it to play a Florian Hecker one instead

EDIT: Is it that a machine briefly produces a sound above 0db (i.e. in headroom terms) which as a result freaks out the rest of the chain ?

[IXix]

What it boils down to is that a machine passes bad data to Buzz as output. Buzz of course has no way of knowing whether a given block of samples is good or bad and so any data it receives from a machine is interpreted as sound and fed to the machine's output. If it goes straight to the master it will probably be just a very unpleasant and damn loud noise. If it goes to other machines, it could cause internal failures by triggering unforeseen conditions, again leading to garbage output.

The typical multithreading noise problem is usually down to the use of static (ie. shared between all instances of a machine) buffers in output related functions. Before multithreading came along, this was a common technique and it didn't matter because only one machine would ever access the buffer at any moment. When multiple machines read/wite from the same block of memory at the same time, the data become corrupt and you get all kinds of problems.

Buzz could monitor the output and silence it if the volume suddenly shoots into crazy (as Overloader did) but I seem to remember Oskari being unwilling to do this for some reason.

[oskari]

I can add an optional feature if someone gives me a reasonable algorithm for it.

[mcbpete]

The typical multithreading noise problem is usually down to the use of static (ie. shared between all instances of a machine) buffers in output related functions. Before multithreading came along, this was a common technique and it didn't matter because only one machine would ever access the buffer at any moment. When multiple machines read/wite from the same block of memory at the same time, the data become corrupt and you get all kinds of problems.

Ooh interesting, I never thought about the way multi-threading would affect the reading of data chunks like this before. Makes sense ....

[IXix]

I can add an optional feature if someone gives me a reasonable algorithm for it.

I remember this was discussed at Buzzchurch ages ago but I didn't really follow the thread. What are your requirements for a 'reasonable' algorithm? Not that I'm likely to provide one as I generally suck as a programmer but it might help to know what the goal is.

I would have thought some kind of RMS envelope follower thing but I'm probably wrong since if it was simple, you'd already have done it.

[mantratronic]

afaik theres no way to distinguish between noise bursts and over amplified sound/music other than the human ear. perhaps memory mapping the pin and comparing it too pout (for non coders, pin is the standard "sound in" and pout the standard "sound out") might help, but this would not be an acceptable algorithm due to the speed problems. (for non coders, you really dont want to look at the input/output more than once)

[Reefer Sutherland]

Cut the volume if it gets too loud. Maybe set the threshold for it with a parameter in the settings?

I mean, I never exceed 0dB. If the master volume in Buzz would get louder than that,
I'd rather it just silenced the output instead of clipping.

I'm also not a coder

[UNZ]

Cut the volume if it gets too loud. Maybe set the threshold for it with a parameter in the settings?

I mean, I never exceed 0dB. If the master volume in Buzz would get louder than that,
I'd rather it just silenced the output instead of clipping.

I'm also not a coder

unfortunately suggestions like these are useless because for example sudden whitenoise that peaks at 0db (-1.0 / 1.0) isn't exactly a pleasure to listen to either....(assuming you compare it with your normal "song" at "sane" loudness).
if anything you'd certainly not activate it at 0, but rather something like +12 or even +20 or whatever.... you dont want the occasional peak to activate it either.

it goes more into the direction ix / mtronic suggested, you have to look for sudden increases in rms imho, but still let transients trough...
and rather than absolutes, you look more for relative changes...

if you look at the metering in mixio (it's rms calculation applies a factor of sqrt(2) for peak-to-rms equivalence) you'll also see that for simple sinewave for example the rms and the peak is the same. looking at peak-to-rms is also not the solution really..
its not trivial to come up with a good burst protection, i wonder what old overloader did tough. it might get a little easier if you assume that the data is truly garbage and more or less random (not audio at all...and not within the output range at all), but that only covers some of the problems.

the question is less of "what is a noise burst" but "what do we consider a noiseburst and what exactly do we want to prevent". If we define it to something we agree helps protect ears and speakers, its certainly implementable... i googled around a little but couldnt even find a simple definition...

[Grids]

So are there any machines that will just never produce bad data?

I want to use buzz live this year - so is there a way to stop the noise bursts?

[Jellyfish]

@ Grids

if you're not sure which machines could cause bursts use hamster alliances' index where many of the potential danger machines have been left out of the main index & put under a section clearly marked danger. its not 100% reliable but its a good guide.
oh and he has * next to machines that could cause problems but are worth the trouble.
very usefull as a start to your own custom index of reliable machines.

[Reefer Sutherland]

unfortunately suggestions like these are useless because for example sudden whitenoise that peaks at 0db (-1.0 / 1.0) isn't exactly a pleasure to listen to either....(assuming you compare it with your normal "song" at "sane" loudness).
if anything you'd certainly not activate it at 0, but rather something like +12 or even +20 or whatever.... you dont want the occasional peak to activate it either.

Yes, I'm a real fountain of uselessness.

Still, if I _never_ peak at 0dB (or you know, any arbitrary dB, +12 or even +20 or whatever...), but a burst of unwanted noise does, then I don't see why Buzz couldn't see this as an unwanted sound...

[UNZ]

unfortunately suggestions like these are useless because for example sudden whitenoise that peaks at 0db (-1.0 / 1.0) isn't exactly a pleasure to listen to either....(assuming you compare it with your normal "song" at "sane" loudness).
if anything you'd certainly not activate it at 0, but rather something like +12 or even +20 or whatever.... you dont want the occasional peak to activate it either.

Yes, I'm a real fountain of uselessness.

Still, if I _never_ peak at 0dB (or you know, any arbitrary dB, +12 or even +20 or whatever...), but a burst of unwanted noise does, then I don't see why Buzz couldn't see this as an unwanted sound...

what i'm saying is the assumption that the burst of data does exceed that range is wrong. A previous machine in the chain could clip it to the range. While it's very likely, it won't prevent all bursts. Also, for this case, you can just use a limiter with very high ratio and release...
This also shows the problem: if you put a limiter with "normal" settings (not high ratio / release) before master, it may NEVER peak at 0 (or whatever), but bursts will still sound EVIL.

[mcbpete]

Out of interest, what's the form of the data 'packets' (if that's the right word) that comes out of the Pout of a machine. If you were able to look at the stream would you be able to identify invalid data chunks or is that a) too much of a cpu hog and/or b) just impossible ?

[Joachip]

Distinguishing between what is a noise burst and an intentional sound is not an exact science. It's a piece of fuzzy logic that would have to be adjusted to suit individual needs. In order to define what needs these are, we have to answer the original question: What exactly is a noise burst?

Faulty machines may produce any sort of unwanted output when they malfunction. The result can be white noise (probably the most common one), heavy DC offsets or even sine waves (e.g. when IIR filters are badly designed.)

For this reason, a noise burst protection mechanism would probably needs various options that could be adjusted to make fairly sane fuzzy logic decisions on, when the sounds seems to be a noise burst, and then it seems to be intentional. I mentioned Merzbow because this would be a good example of a type of sound that would be hard to distinguish from unintentional noise.

If the noise burst protection is too aggressive, it may trigger on something that is actually sound, which would ruin the music. If it's not aggressive enough, it could allow harmful noise to bet let through.

Such an algorithm would have to look for the following problems:
* Sudden white noise above a certain threshold (e.g. +6 or +10 or +20 dB) for a certain length of time.
* DC or unrealistically large amounts of subsonics.
* Other stray signals going wildly above 0 dB.

I also think such a machine should have a bypass button, so that when you render to .wav you can disable it, in order to not risk the final output to be affected by it. (When rendering out, you can check the resulting .wav file easily in an external editor.)

Considering all the above, I think such a noise burst protection should not be a built-in part of Buzz, but rather a replaceable component, so that various developers could come up with various approaches to this, without having to bother oskari with all this. - And I think the most simply way to do this, is to simply write an effect that you can place just before the master!

[mcbpete]

I mentioned Merzbow because this would be a good example of a type of sound that would be hard to distinguish from unintentional noise.

Yes, absolutely - and back in the mid-2000s I used to do a lot of noisy experiments and had to turn off Overloader's burst protection as a result. A mixture of dc offset and long (sometimes infinite) white noise bursts were definitely the bulk of my issues back in the day and thankfully they've been far less frequent in the new builds (as in everything since 2008) - though seem to have returned a bit since getting a laptop with a multi-threading processor.

[4516N41]

This may be a stupid observation but the VU meter does not detect the noiseburst.

[mcbpete]

This may be a stupid observation but the VU meter does not detect the noiseburst.

No, that's very true - A lot of times I have noise bursts it shows up on the master VU meter as having an output of -inf db, or is that just the behaviour of Buzz representing >0db volume ?

(erm, or is than not what you meant )