Hope I’m not posting in the wrong section of the forum, but my question does relate to newer versions of Audacity.
About a year ago, I and other users, posted about Audacity sending wrong audio levels to plugins.
It always seems to be about 6dB too high, but can vary from between +4dB to +8dB.
The original posts below:
I have indeed confirmed that the problem is with Audacity and what was claimed by TBProaudio:
It seems that Audacity gives different loudness values when the audio file is just played (Play button) or rendered (Apply button).
But it looks that rendering (Apply button) gives the right loudness value. Play seems to depend on selected audio driver… This seems to be a problem of Audacity.
I can also confirm that this does not occur with Reaper, OcenAudio and even Resolve.
(Same plugins, same source material, same computer).
The problem is present on both Mac and Windows.
I have not tested on Linux, as these plugins do not have a Linux version.
So my question is, has this problem been resolved in 3.x ?
I don’t want to test by running these newer versions, as I have a lot of projects, plugin settings etc which I can’t afford for
them to be potentially “nuked” by a newer version.
See that you that moved my post to this section of the forum.
I don’t have a problem with it, but, it’s not Mac only, as the same problem also occurs in Windows.
Judging by the fact that there have been no replies, I’m suspecting that only a very, very small number
of Audacity users, tried to do final mix to strict standards like EBU R128.
There are however other situations where a bug like this could cause unwanted results, i.e. using external
compressors and/or limiters and of course some de-essers which are level based.
The result you get, will then not be the same when you render the effect, as realtime playback in Audacity
thru an effect is not the same as when you “apply” it.
BTW, the problem is present on MacOS (with both .AU and Mac VST) and on Windows with VST plugins.
Next will try using LADSPA compressors and level monitors to check if this problem also exists in
Linux, using Debian based RaspianX86 on a PC not Rasp-Pi.
I may even use the Carla VST host to be able to use Windows VST’s in Linux.
Just not sure if it will work with Audacity and RaspainX86.
Tested on Linux with Audacity 2.1.3 (purposely used an old version).
All good, using Jack Audio and ebumeter.
The reported levels are indeed correct, so it’s only MacOS and Windows.
I = +0.2 LU and LRA = 1.7 LU (meaning highly compressed audio).
Fair enough, although my thinking was that since it applies to both Mac and Windows, and posting on both would be a no-no,
anyone that may be facing the same problems, would come across it if it was fixed in the latest version.
I suspect that Windows users will not necessarily look in the Mac section and vice-versa.
Yep, but that is for newer versions and my whole workflow is based on 2.3.1.
Due to possible loss of all my settings, etc, I’m not keen to upgrade.
Another thing that worries me about auto normalize, is that I don’t have full control over the process.
I prefer to do it manually, as I can then control certain sections that may need a tad more attenuation
or even allow it to be more dynamic (i.e. push the short term limits of the spec).
This then produces a more lively, punchy and dynamic audio.
Since I posted the results on Linux, I have set up an audio only, real time monitoring solution
to see what our competitor’s audio is like.
Below, one of them.
I know for a fact that they do auto-norm in Premier Pro and their final TX compressor is not properly set-up.
The results speak for themselves, just look at the LRA, averaged over a couple of hours, which includes
pre-recorded material, adverts and even a short news package.
Far too compressed.
I always like to aim for at least 4.0 - 6.0
Since the same Linux computer is also acting as a Samba share server, I can record using Audacity
and save the recordings on a shared folder, for later analysis, listening or even rubbing their noses in it.
