EFFECT/AMPLIFY - odd behavior?

Audacity Help Forum GNU/Linux
1

I was attempting to do some rather radical shifts in volume (see explanation below), and I noticed odd behavior with the EFFECT/Amplify… option.

I imported a clip with peaks at ~ -4db, and then I tried reducing the volume with the Amplify command. All went as expected until I hit about -54db change. When I attenuate by anything greater than 54db, it gives the same expected peak level ( -58db) regardless of the setting (like minus 60,70, 80db). This was done in 16 bit mode in Preferences/Quality.

I realize it is rare to drop the volume this far, but is there any explanation for this? It seems odd. Is it a bug, or some intentional limit on the effect?


Explanation/background for above: I was doing this as part of an experiment to hear what effect bit depth had on my own perceived sound quality. The only way I could think of to reduce a FLAC ripped from CD from 16 bit would be to reduce the volume in 6 db steps in 16 bit mode in Audacity, and then pump the volume back up. That should truncate the LSB, right? But I attempted to prove this to myself with extreme changes, as it seemed I needed to get down to around 8-bit resolution to clearly see the steps in the Audacity display to verify this visually. That is when I noticed this apparent anomaly in the Amplify effect.

NTL2009

2

I probably would have left the Music CD in its original WAV quality rather than converting it to a compressed format. And Audacity doesn’t work internally at 16 bit. It works in 32-floating, a much broader volume range.

Audacity isn’t scientist friendly. You have to work to make a simple, high quality show come out bit for bit accurate input to output. Audacity is a production editor, not a WAV editor.

Koz

3

Amplify has a 50 dB limit in each direction.
You should use the Nyquist prompt for such things.
For instance with this code:

;; Produce 16 versions of the original, 16 down to 1 bit.
(seqrep (bit-depth 16) 
   (quantize s (truncate (expt 2.0 (- 16 bit-depth)))))

The bit-depth is gradually decreased, the final bit-depth is actually 2 bit, or 1 bit signed (+1, 0 -1).

4

Amplify has a 50 dB limit in each direction.

Per pass, or ever? What happens if you Amplify and then Normalize?
Koz

5

I notice that the manual says nothing about that (though that is correct). I’ll add a note to the manual.

Per pass.
The slider range is +/- 50 dB and that takes priority.

6

Thinking about it, that is perhaps a minor bug, or at least room for an enhancement.

I think what should happen is either, (a) typed values greater than +/- 50 dB should be allowed, or (b) values greater than +/- 50 dB should not be allowed.
I’ll raise this with QA.

7

Thanks, I recall looking at that Nyquist prompt a while back, but I’m not familiar with using it - I will take a closer look for this application. From my initial tests, I think a few of my audiophile friends who promote 24 bit may be surprised at the results (that’s a whole 'nother can of worms though :wink: )

Ahhh, since I was targeting very specific values of attenuation, I was typing in values. I went back and yes, the slider does limit the range to +/-50db values.

So yes, I’d also call this is a minor low priority ‘bug’. If there is technical reason to limit it to +/- 50db (and that is certainly a reasonable number for ‘normal’ use), then the typed value should be limited as well. Or at least a note of the limit in the dialog and the manual.

Thanks, at least now I know it wasn’t some odd thing with my system or how I was using it.


For this little test, as I noted in my OP, I set the Quality in Audacity to 16 bit instead of the default 32 bit float. And the FLAC format gets imported to Audacity as a lossless representation of that original WAV file, so I don’t think that matters one bit (pun intended!). You are correct, this type of thing isn’t really what Audacity was designed for, and the defaults actually do work well to ‘save me from myself’ and unintentionally reducing the quality of my work. But it is so flexible I figured I’d still be able to do it (and it looks like that Nyquist prompt is the right tool).

Thanks to all for the quick and helpful replies. -NTL2009

8

There needs to be some sot of limit for positive amplification. Even though Audacity processes in 32 bit float format, which has a huge dynamic range, there is still a limit to high high the amplitude can go (about +770 dB, or 3x10^38 linear). Attempting to create sample values greater than this can cause unpredictable “bad things” to happen.

As you say, for normal audio use, +/- 50 dB is a generous limit, but I feel that if a user exceeds that limit it could be handled better.

One thing to be aware of when doing “scientific” tests:
Audacity works internally in 32 bit float format. If the track is set as 16 bit (integer) format, then after processing, Audacity will convert the processed data back into 16 bit integer format. This requires that the 32 bit float format sample values are rounded in some way to 16 bit values. By default, conversion from a high bit format to a lower bit format uses “dither” so as to minimise audible distortion, but dither is likely to mess up precise “scientific” measurements. For such measurement purposes it is probably better to temporarily turn dither off in “Edit > Preferences > Quality > High-quality Sample Rate Converter”.

If you need more information about “dither”, see here: Missing features - Audacity Support

9

Yes- good point, I’ll be mindful of the dither functions as I dig into this. I’m looking for the best audio that the various bit-depths can provide (rather than a strict mathematical reduction to X bit-depth), so I’ll probably want dither enabled, but will check both ways.

Also, the above Nyquist Prompt code error-ed on me (probably something in the loop calculation), but there was enough there for me to figure what I needed. I just simplified it to the basics (example for 12-bit-depth conversion):

(quantize s 2047)

For others, that is 2047 positive steps, 2047 negative steps, plus zero for 4095 steps, and 2^12 is 4096 (4095 steps signed? - close enough either way).

Good enough for my little task, but this has opened a whole new world of audio tinkering for me!

-NTL2009

10

dither is likely to mess up precise “scientific” measurements.

“The bit values in my song are not at the perfect, expected values. What are you clowns doing!!” (Not that far from an actual post)

this has opened a whole new world of audio tinkering for me!

So you’ll be back to help out with postings like this:

“My church sermon recording has an odd, pulsing crackling that goes away when we stop talking. It’s not overloading and the blue waves look perfect. Can you help me ‘Clean Up’ the recording?” (Also not that far from an actual post).

Koz

11

I don’t think that there’s a bug, unless you’ve tried it on a stereo sample.
Look what the debug screen says.

12

I had used a stereo track, so I converted to mono, reset things to 32 bit float, and still got errors. I’m not looking to get this debugged (the “(quantize s X)” command is all I needed, but in case you were curious about the errors, here they are, pretty much all Greek to me:

error: bad argument type - NIL
Function: #<Subr-SND-QUANTIZE: #a147208>
Arguments:
  NIL
  32768
Function: #<Subr-APPLY: #a146298>
Arguments:
  #<Subr-SND-QUANTIZE: #a147208>
  (NIL 32768)
Function: #<FSubr-COND: #a14758c>
Arguments:
  (LEN (SETF RESULT (MAKE-ARRAY LEN)) (DOTIMES (I LEN) (SETF (AREF RESULT I) (APPLY FN (MAPCAR (FUNCTION (LAMBDA (A) (COND ((ARRAYP A) (AREF A I)) (T A)))) ARGS)))) RESULT)
  (T (APPLY FN ARGS))
Function: #<FSubr-LET: #a145218>
Arguments:
  (LEN NEWLEN RESULT)
  (DOLIST (A ARGS) (COND ((ARRAYP A) (SETF NEWLEN (LENGTH A)) (COND ((AND LEN (/= LEN NEWLEN)) (ERROR (FORMAT NIL "In ~A, two arguments are vectors of differing length." FN)))) (SETF LEN NEWLEN))))
  (COND (LEN (SETF RESULT (MAKE-ARRAY LEN)) (DOTIMES (I LEN) (SETF (AREF RESULT I) (APPLY FN (MAPCAR (FUNCTION (LAMBDA (A) (COND ((ARRAYP A) (AREF A I)) (T A)))) ARGS)))) RESULT) (T (APPLY FN ARGS)))
Function: #<Closure-MULTICHAN-EXPAND: #9df0a04>
Arguments:
  #<Subr-SND-QUANTIZE: #a147208>
  NIL
  32768
Function: #<Closure-QUANTIZE: #9db3cb4>
Arguments:
  NIL
  32768
Function: #<FSubr-PROGV: #a148edc>
Arguments:
  (QUOTE (*WARP*))
  (IF (WARP-FUNCTION *WARP*) (LIST (LIST (SREF-INVERSE (WARP-FUNCTION *WARP*) T0) (WARP-STRETCH *WARP*) (WARP-FUNCTION *WARP*))) (LIST (LIST T0 (WARP-STRETCH *WARP*) NIL)))
  (QUANTIZE S (TRUNCATE (EXPT 2 (- 16 BIT-DEPTH))))
Function: #<FSubr-PROGV: #a148edc>
Arguments:
  (QUOTE (*WARP* *SUSTAIN* *START* *LOUD* *TRANSPOSE* *STOP* *CONTROL-SRATE* *SOUND-SRATE*))
  NYQ%ENVIRONMENT
  (AT-ABS T0 (QUANTIZE S (TRUNCATE (EXPT 2 (- 16 BIT-DEPTH)))))
Function: #<FSubr-SETF: #a1450b0>
Arguments:
  FIRST%SOUND
  (WITH%ENVIRONMENT NYQ%ENVIRONMENT (AT-ABS T0 (QUANTIZE S (TRUNCATE (EXPT 2 (- 16 BIT-DEPTH))))))
Function: #<FSubr-COND: #a14758c>
Arguments:
  ((< BIT-DEPTH LOOP%COUNT) (SETF FIRST%SOUND (WITH%ENVIRONMENT NYQ%ENVIRONMENT (AT-ABS T0 (QUANTIZE S (TRUNCATE (EXPT 2 (- 16 BIT-DEPTH))))))) (IF S%RATE (SETF FIRST%SOUND (FORCE-SRATES S%RATE FIRST%SOUND)) (SETF S%RATE (GET-SRATES FIRST%SOUND))) (SETF BIT-DEPTH (1+ BIT-DEPTH)) (COND ((= BIT-DEPTH LOOP%COUNT) FIRST%SOUND) ((ARRAYP S%RATE) (SND-MULTISEQ (PROG1 FIRST%SOUND (SETF FIRST%SOUND NIL)) SEQREP%CLOSURE)) (T (SND-SEQ (PROG1 FIRST%SOUND (SETF FIRST%SOUND NIL)) SEQREP%CLOSURE))))
  (T (SND-ZERO (WARP-TIME *WARP*) *SOUND-SRATE*))
Function: #<Closure: #a144660>
Arguments:
  184.733
1>
13

Thanks for the report.
It is obvious that the loop runs out of “sound”.
That’s queer 'cos I do not get this error.
It might be sufficient to replace “s” with “(cue s)”.
Anyways, It is fine that you can work with the quantize part alone.
Another idea would be to use weighted quantization, i.e. quieter sounds are more quantized than louder ones while keeping the bit-depth. That’s a trick used in compressed audio formats.