Audacity Forum

I've no idea why Waves or Tascam would do that, especially since convolution reverb is typically done at very low levels, but the mathematics speaks for itself: 23 bit + sign bit + 8 bit exponent, take it over 0dB and you loose the least significant bit. (don't try using 32 bit float for an accountancy program )

I don't see how the mathematics are speaking for themselves: In 32bit floating point 0db is represented as 1.0 or -1.0. Do you automatically lose precision by allowing it to go to 2 or -2? But it would be really nice to have the possibily as a headroom.

For example, one could apply an effect that let's the audio go over 0db and bring it down later without it being clipped.

george13 wrote:But it would be really nice to have the possibily as a headroom.

I know what you mean - for us that are used to analogue and 16 bit, we like to maximise our signal close to the red line, so every bit of extra headroom is great. But with 32 bit float you don't need to go anywhere near the red line. Allow yourself 24 dB of headroom (work to a peak of -24 dB) and the remaining dynamic range (of your 32 bit float) will still exceed your hardware.

When working in 32 bit float, you can allow yourself loads of headroom, and it can still sound great.

You're right absolutely. I think -6db is a good value for a 'red line' to not cross. That would be half the scale.

On the other hand, I like the suggestion to allow 32 bit values over 0db, so I wrote a feature request in the wiki. It appears also that this is the way other programs (like Logic) handle this.

So I read several reasons for not clipping floats to -1.0..1.0.
One of them is very serious I think: importing files that allow wider range.
And there is one more: the clipping there is very artificial.
. (So much artificial that if we are going to convert to 16bit (for export or to feed the sound card),
. and we decide to dither, we have to do the clipping *again* after adding dither noise.
. {BTW, dither is applied before converting to 16bit, is not it ???}
. All that clipping before *this* point is meaningless, at least from the point of view of ouput range bound.)


I found one real reason against: Nyquist is said to clip to -1.0..1.0.
- is this indeed true? Where does it do this? On its output only or deep inside?
No, certainly not inside, how would a compressor/expander work if the controlling signal would be restricted to -1..1 --
it would never amplify the sound.
- There might be interface reason for it: if standalone Nyquist plays the sound, it should not send +3dB to soundcard.
The same with export to 16/24bit. If Audacity supported unclipped floats, the interface reason would be gone.
- is this difficult to change?
BTW, Nyquist uses internally double precission floats on some platforms. Why? Sometimes it is (or it was some years ago) faster...


There is another reason:
Novice user would complain his beatufull waveform would produce terrible sounds during playback.
Indeed, if the wavefrom is terrible too, it is obvious to him what he did.
But perhaps, we could have unclipped sounds and their display could be clipped (by default) -- to help the user.


I vote for unclipped floats.


<<But perhaps, we could have unclipped sounds and their display could be clipped (by default) -- to help the user. >>
(That would perhaps solve issues with Nyquist if they are indeed any: If it indeed fails with sounds above 0dB,
we would clip them just before passing to Nyquist. User would under understand since he sees clipped waveform, too.
The same with VST/LADSPA/whateever effects, in case they would demand non-float input.
And the same with export.
We show clipped waveform, and we would clip the sound just before export.)

<<the mathematics speaks for itself: 23 bit + sign bit + 8 bit exponent, take it over 0dB and you loose the least significant bit>>
No(1) and Yes(2). And we should not clip anyway(4).
1. No if I go over 0db by multiplying (amplifying) the signal. If I multiply by 2 and then divide by 2, I loosed no bit.
The same with 4, 8, 16, ... instead of 2.
2. Yes if I go over 0db because of adding. If I add 1.0 and the substract 1.0, the result is a single bit worse then ordinary 24bit representation.
3. This is kind of counter-intuitive that adding DC offset (or some strong signal) steals appropriate number of bits from the precission.
but OK, if it should serve to put mud on unclipped floats, we have to compare what happens with clipped floats.
We see that infact all that says we should not introduce artificial clipping.
1. If multiplying by 2 and dividing again, the -1..1 clipping introduces terible distortion to many recordings.
If 2 is replaced by 4, 8, or 16, all recordings on your harddrive have gon...
2. Adding 1.0 and then substracting: the clipping provides wonderfull diode effect. Signal is useless
3. For tiny signals and small DC offsets, there is no difference since clipped to -1..1 does not apply.
With large DC offset we are going towards point 2.

4. Now, why we should not clip artificially ? Because with clipping, instead having "yes/no" for the less significat bit,
we loose the "MOST significant bits" by the clipping.
How to make car driver to go safely? Put there a bomb that explodes whenever he goes faster than 90 km per hour (applies on first class Czech roads; 130 is applicable for highway).

Apparently this has been fixed in 1.3.8 alpha. This is cool!

This was a nice message.

The following different thing came to my mind.

[the story]
Audacity supports card's mixers through mixers toolbar - one can set there input and output levels.
Usually this works well, but under some circumstances, they become emulated.
This is the case in windows Vista, for example (I do knot know if that is already fixed in 1.3.8; it might be).
The difference is this: setting capture to 0,5 (=-6dB) means:
for 'native' mixers: The card is told to decrease input level by factor 0,5 BEFORE converting to digital.
for emulated mixers: The signal is multiplied by 0,5 in Audacity, long time AFTER converting to digital.
The emulated mixer is therefore not much useful, rarely it makes sense setting less than 1,0.
Recently I helped a friend to set levels before live recording and we lost a precious minute of time during preparations when my eye catched beautiful clips preserved by emulated mixer. Then we had to dig for those hidden mixer settings of Vista.

[the suggestion]
In the mixer toolbar,
the recording mixer should perhaps appear different when input mixer is emulated.
Perhaps instead of black, a gray color would be used for drawing the picture.
(And/or a balloon help (for a second or two) "Beware: emulated mixer. Emulated mixer cannot avoid clipping during capture" could be useful when its value would be set lower than 1,0)


(Note: this does not apply to output mixer. For output, emulated one is at least as good as the native one would be.)

(Back to the original topic)


The removal of (artificial) internal clipping to -1,0...1,0 was discused on audacity-devel in January 2009.
(Partly based on that discussion,) I'd like to make notes that can be perhaps useful sometimes.
(subject '[Audacity-devel] Just to see if I could...fix clipping'; suitable keyword for search on nabble: 'clipping' ).


***
1. [When clipping was avoided]
Ofcourse internal clipping to -1,0...1,0 can be avoided when 32float is used, but not otherwise.
That means that one has to be carefull with non-32float cases:
- input/output (obviously, hardware has limits, I include it here just for completness)
- effects that eventually could be 16bit or 24bit (A. This should not be the case of internall effects - if clipping appears there and persists after 'amplify' with negative dB, it should be considered a bug and I think developpers would like to hear and repair it. B. I do not know how much this applies to LADSPA and VST effects.)
- tracks that are 16bit or 24bit
- in Preferences, Default Sample format

2. [Default Sample format's documentation]
BTW Default Sample rate format in Preferences needs update in documentation.
Somewhere was suggested that after change perhaps restarting audacity or creating new project might be needed (wrong?) which is certainly confused condition, both cannot be the decissive moments.
Documentation http://www.audacityteam.org/manual/inde ... references says "which will be used each time Audacity is launched, or each time a new project window is opened." (wrong?) which is not much better. It seems to me (1.3.6a5) that it is used immediately, whenever a new track is created. Perhaps true would be "which will be used whenever new track is created, in particular when a new track is created for recording, Mix and Render (?), Import and perhaps_anything_more" (because it is not effective to change tracks format after it contains any data already). Perhaps the following might be true (-devel postings supports this case), which is not as easy to test for me: "Default sample rate is also the sample rate to which the sound card is set, if possible;" and perhaps "for this asspect, however, changes are effective after(or not?) you to restart(or what?) Audacity"

3. [exceptions regarding clipping avoidance]
There are the following "strange" things (which are actully reason of this post) which cause exceptions to 1..
This can, e.g., confuse as when we decide to 'test' clipping/nonclipping.
1. <<non-32float cases: tracks that are 16bit or 24bit>>
16bit track has (usually) 16bit underlying implementation (ofcourse, if I do choose 16bit only if I need to save space!) but sometimes the underlying representation can hang on 24bit or 32float - this can happen e.g. when copying the sound from 32float (the data is not copied, only 'referenced')
[citation from audacity-devel: But it seems like if you change or copy a float clip to int, the underlying float representation stays float.]

2. Sound card is expected to give data in -1,0...1,0 range.
If I understand well, in a case there was observed that Audacity recieved data out of this range from sound card.
[citation from audacity-devel: The fact that I was able to recover from a clipped recording means that one of these two things is going on. This should mean that port audio is giving us >1.0 values.]
It was attributed either to A. 32float sound card giving (more-or-less) meaningful data even when clipping or B. portaudio sound input/output library.
I would add that the cause eventually could be also C. sound cards drivers, either by a bug, or by any of the fancy features as de-echo, DC-offset removal, AVC or D. sound card drivers (again) doing a correction to analogue part of card (an equalization, a kind of jitter correction...) or E. sound card drivers (again) doing a requested sample rate conversion (that includes a filter, right?)


4. Notes (this overlaps with 2.)
Default Sample rate format in Preferences:
Either it means INTERNAL (and then it should be called "Internal" or "Default(=for new tracks???) and internal)
or it means indeed Default (for new tracks? or exactly what) (and then it seems to bemissinterpretted on -devel (which is unlikely) audacity-devel citation: I am however sure that audacity can be and is used with the bit depth in
the preferences set to 16-bit, working with 16-bit integer data )
I am sorry I cannot tell what is in source code (seeing that long time ago) but I think audacity does not have three engiens (16,24,32bit), so probably all computations (I would guess including internal effects) are done 32float.

Currently I think it is
- sample format for new tracks
- sample format for sound card input/output (if possible)
while internal is 32float (used for all (or almost all?) computations)
and I have no idea about exports (should not have any influence?)

Another thing I've found: you can de-clip mp3s after you've imported them.

Here's an example: above the orginal mp3 (brickwalled and clipped), below after using the amplify-effect.
'Amplify' brings the volume down by 0.9 db and restores some of the clipped peaks.