Set Audio File between -23db and -18db

Windows 8.1; Audacity 2.0.5; .exe
I created Audio Book, 21 hours, 63 chapters, which I wish to publish on Audacity. Audacity requirement : each uploaded file must measure between -23dB and -18dB RMS. Can I set these parameters in Equalization? Other thoughts? Thanks.

Try Analyze → Contrast. Just select the whole file since you’re not really trying to find the “contrast”.

I’ve moved this to “Audiobook Production” - you’ll find lots of help in the topics in this board about this.

Just to add, “Analyze > Contrast…” measures RMS but does not set levels. Contrast only analyzes a selected, single non-stereo track. I expect a good suggestion may be to use Compressor if the RMS is lower than you are trying to set.


Thanks for input; greatly appreciated.

Is this also a good way to measure the noise floor?

When I select silent areas, I find they are -59 to -61, is that my noise floor?

Also, when I select the whole track, I come out with -21, but when I select lines of speech without silences, I’m getting readings of -19 to -16. Does that means it’s too loud for the range mentioned above? or is the -21 my actual rms?


That’s arguable…
It’s the way ACX will measure it, so it is the right thing to do.


First question: Is your peak already at -3 dB?
If not, the difference has to be added to your Rms values.
peak = 0 dB, then you’ll have -62 to -65 dB noise floor and -19 to -22 dB speech level.

Acx will probably measure with pauses included since their usual blocksize is 60 s.
However, they will measure actual text and not the introductory titles (“Chapter”) where exceedingly long pauses exist (depends on who is responsible for the measurement).

Tip: Make a trial export to mp3 (192 kbps) and re-import the file.
Make your measurements with this file, is the peak level still -3 dB?
If not, amplify the original by the difference and export again.
It’s possible that the original needs a peak level of -4 dB in order to have a decoded mp3 file with -3 dB.
The Rms levels will accordingly be lower.

Thanks, I think I was just measuring a podcast file I’d already processed in Audacity with some noise reduction, compression and normalization – so yes, the peak levels were at -3. (Right now, I don’t want to fix any files so much as I want to know how to measure them.)

Thanks for the tip on re-importing the mp3 file. This may explain some results I thought were odd when testing things with the tool they have from Librivox.


The new Contrast in Audacity 2.0.6 can no longer be used to measure noise. In order to clear up some odd results, it now ignores silent patches when it measures RMS. Tight measurements and loose, sloppy measurements on the timeline are a lot more consistent now.

One quick and dirty way to measure noise is watch the light green sound meter jump when you play the silent track. That’s the RMS as interpreted by the sound meter and it will go all the way down to digital silence.

Attached is a measurement of a recent sound clip I recorded. I put the noise at about -73 or -74. Well below the -60 specification. It will jump, of course. It’s measuring live audio.

You might also have to change the sound meter if yours stops at -60.

Audacity > Edit > Preferences > Interface > Meter dB Range. Set to -96 for this. You might also need to increase the size of your meters, probably a good idea no matter what. Click on the right-hand edge and pull sideways.

The RMS measurement is probably good if you get close. Their first pass testing is generally used to rapidly weed out people trying to submit hopelessly trashed recordings. If you get close enough, they go to manual review (which can take many days) and that’s where they make the final analysis. They may accept it as it is.

ACX has a new (I’m guessing) trick. They will allow a 15 minute test submission so you don’t have to record the whole book before finding out it’s technically not acceptable.

Did you have problems with microphone hiss? Can you describe your “studio?” Do you have a “raw” clip posted somewhere? Before processing? Do have a final clip? We can give your our opinion of technical specs. You can post a ten second mono WAV file on the forum. Make sure it includes a silent patch.

Screen Shot 2015-01-30 at 17.26.58.png

Please tell me you saved the original raw recording as either WAV or Audacity Project (or both). A very common error is people write corrections on top of the capture files. If there’s a problem they can’t revert to the clean recordings and try again. If ACX complains about high volume (unlikely, but still) it’s easier to patch that by going to the original sound files.


I don’t understand your point koz. It has never measured below -60 dB.

It has always done that.

The difference between the Contrast tool in the current version and previous versions is that the old version would sometimes measure the length incorrectly if slightly overlapping the boundary of an audio clip (see:
This means that the Contrast tool CAN now be used reliably, whereas the old version would occasionally give completely wrong readings if the selection included multiple audio clips.

The two main limitations that remain are:

  1. It (still) does not measure below -60 dB (not required for its intended purpose).
  2. It (still) works only for mono tracks (WCAG v2 only specifies measurements for mono tracks).
    For the purposes of audiobook production, it would be better if we had a tool that could measure accurately below -60 dB and was able to handle stereo tracks (though generally mono is preferred for audiobooks).
  1. It (still) does not measure below -60 dB (not required for its intended purpose).

I don’t agree. It’s very good to know how far below. -61 is brittle/borderline and easily pushed over the edge.


I agree, and that’s one of the reasons why I think we need a new tool, but what I was saying was that the Contrast tool has never measured below -60 dB.

Now I’m getting confused. In 2.1.0-alpha Contrast seems to measure white noise on its own at -81 dB peak and gives a very similar RMS result to Sample Data Export.

Contrast refuses very short selections.


Yes it seemed to work - but that was a bug. The code was pretty clear in making -60 dB the minimum displayed value. The -60 dB limit was supposed to catch < -60 dB (including -infinity and NaN), but sometimes missed them. There remains an issue that white space selected between two audio clips will return NaN (the precise representation is probably platform dependent).

Also note that the time selection rounds to 0.01 seconds, so making a selection right up to a large peak (with the large peak just outside of the track “Selection”), may include that peak in the analysis. For example, if you have a 0.8 amplitude sine tone (440Hz) then select from time = 0.0 to 0.996 and silence it (Ctrl+L), the Contrast tool shows the selection as 00h 00m 00.00s to 00h 00m 01.00s and the RMS as -29.1 dB (because the Contrast tool selection includes 0.004 seconds of the sine wave).

The Contrast tool was not designed for “scientific” measurement, it was designed to be an accessible way to measure WCAG (V2) compliance.
What I would like to see for a future version of Audacity, is that the Contrast tool becomes an optional “module”, and Audacity gains a “scientifically” accurate RMS measuring tool (such as a simple pop-up window “report” that shows length and amplitude information about the current selection).

If it is not supposed to display measurements below -60 dB then it still is a bug. What measurement should it show if you select -81 dB white noise?

Yes, I noticed that one.


THANK YOU for telling me how to change the meter! That’s something that has been driving me nuts.

The problem is that WCAG v2 is not well defined (it presents “guidelines” rather than an actual “specification”).

This is what WCAG v2 says (Web Content Accessibility Guidelines (WCAG) 2.0):

1.4.7 Low or No Background Audio: For prerecorded audio-only content that (1) contains primarily speech in the foreground, (2) is not an audio CAPTCHA or audio logo, and (3) is not vocalization intended to be primarily musical expression such as singing or rapping, at least one of the following is true: (Level AAA)

  • No Background: The audio does not contain background sounds.
  • Turn Off: The background sounds can be turned off.
  • 20 dB: The background sounds are at least 20 decibels lower than the foreground speech content, with the exception of occasional sounds that last for only one or two seconds.
  • Note: Per the definition of “decibel,” background sound that meets this requirement will be approximately four times quieter than the foreground speech content.

The idea of the Contrast tool is that it gives a clear “Pass / Fail” measurement for the third point in that list.

In some ways the Contrast tool cannot always be “right”. For example, if the foreground is -90 dB and the background is -120 dB, then by the above WCAG criteria that is a “Pass”, but in practice it should surely be “Fail” because for all intents and purposes it is “silent”. On the other hand, how can it be “right” that “absolute silence” is shown as “louder” than “extremely quiet audio”?

What the Contrast tool can aim to do, is to give sensible results when used sensibly for the purpose for which it is intended.

I just wanted to follow up…

I returned my condenser mic (a Rode NT1a), and went and bought a dynamic mic (a Shure SM58) and I find that I can now easily hit ACX’s requirements… even when the furnace is running!

You really do have to suit your mic to your recording environment and other equipment.


The purists will cringe as that is a “rock band” microphone, but it has a lot of the characteristics needed for home podcasting and audio books, and it doesn’t cost a million dollars. It’s almost unbreakable (although I would not try to break it, or blow into it or any microphone).


I don’t know how to make Contrast show the wrong value when selecting well inside a passage of “extremely quiet audio”.

But given it shows me the correct “extremely quiet” value, I agree it should not show absolute silence as “-60 dB”.

This does not seem to be on Bugzilla. Should it be?