stevethefiddle wrote:
jan.kolar wrote:Now I zeroed part of track (Ctrl+L, 1.3.5.) and normalized whole of it to see zero changed to some almost zero. Whats that?
If you are not working with a 32 bit track format, the Normalize effect will apply dither to the the output. Didn't you recently have a conversation on the forum about how Audacity applies dither to silence?
1. The point is that it did
not look like the ususal dither.
1a. There were spikes of the same height. In dither noise in exprort I usually see about three different heights. (Well might be the 'fast' dither now?)
1b. The spikes were only of positive polarity.
OK, I took another look today. (Inded I had 16bit track.) To be continued few lines below...
2. I have bad memory. What I would say I rember is this: Perhaps I had conversation on Forum about dither
and then notified Gale on -devel about my observation on non-dithering silence.
stevethefiddle wrote:
I think it would be better if Audacity did not apply dither to long periods of silence (even though it is inaudible).
Just said it: My observation is that it (1.3.5.) does
not dither silence (prehaps even short periods.)
... so we can continue.
A picture (normalized normalized silence inside longer low level track): Please care only about the upper track.
The left part suffered one more normalization. You see there Large dither and Small dither combined.
The small dither is one unit height, sometimes up and sometimes down (nevertheless, always from zero, which I decided to ignore right now.)
The large dither is one Unit height, too (however the Unit is larger that the previous unit, because amplified).
However it does
not consist of spikes of both polarities. Instead it is like ---.--.----.--.---..-----
two levels, where the upper is much prevalent.

- --
- dither_unbalanced.jpg (114.46 KiB) Viewed 3440 times
This might be caused by interferrence between "dither only nonzero" and DC-offset removal
(a bit of silenced-out in a track probably gets DC-biased when the whole track is DC-removed.)
So I feel there is something a bit unheatlhy. I do not say it is important or not, but once dither is considered
important, it should work as expected, not as it happens to happen.
stevethefiddle wrote:
It makes sense for Normalize to apply dither, since there may be slight (very slight) clicking as an audio signal fades out due to quantising errors,
This does not need dither: copy & cut (in the same format), add/mixing (with multiplier 2), special amplifications (integer multiplier), silencing.
This needs dither: Generate sine and others, general amplifications (including 1/2), normalize, almost any effect.
This needs dither but deserves special treatment (at least at 8 or 10 bits): fade in/out.
I did not thing about it deeply, but I think this should be the order : 16source->float->manipulation(in float)->dither(in float)->16bit convert. That is, dither in float before conversion.
[If anybody votes for dither after conversion, I say that might be fast but not clever, it could not shift quantisation noise to other frequencies, but it can only mask it. Then dither would best come later, at the export time.]
stevethefiddle wrote:
but I think after a few samples of silence, dither should not be used.
How many samples uses the 1.3.5 to decide? If too few, gets wrong.
stevethefiddle wrote:
jan.kolar wrote:Uf, just wanted to ask if the two channels of stereo track are normalized together or separately,
As you know, Audacity treats stereo tracks as 2 mono tracks (side by side). Each (mono) channel is normalised independently, just like any other mono track. This can be quite useful if you have a recording that has the pan out of balance, providing a simple way to correct it.
I confirm it does what you say. (I would split the tracks to get this. And I would cry for RMS normalization.).
But it can destroy carrefully balanced recording. Orchestra - does not it have drums to one side, for example?
And I would guess live stereo piano recording would seem to be about half a dB unbalanced, at least.
OK, it is easier to write <<for each track: normalize>> than almost four time longer <<for each track: if mono: normalize else: get peaks of both and amplify both and skip normalizing right track again>>.