Bug 489 – Read Directly uncompressed audio produces incorrect Normalize in Chains

••• Introduction •••
••• Keywords •••

Audacity 3.0.3 development began 19th April 2021

Audacity Bugzilla

Bug 489 - Read Directly uncompressed audio produces incorrect Normalize in Chains


Summary:	Read Directly uncompressed audio produces incorrect Normalize in Chains

Status:	RESOLVED FIXED

Product:	Audacity
Classification:	Unclassified
Component:	Built-in FX
Version:	2.0.0
Hardware:	PC All

Importance:	P2 Repeatable
Assigned To:	Michael Chinen

URL:	http://forum.audacityteam.org/viewtop...
Keywords:

Depends on:
Blocks:
	Show dependency tree / graph

Reported:	2012-03-25 11:32 UTC by Steve Daulton
Modified:	2018-08-20 11:46 UTC (History)
CC List:	6 users (show)

See Also:
Steps To Reproduce:	1) Create a chain with: Normalize to -1 dB Export to WAV 2) Set Preference > Import.Export to "Read directly" 3) deselect warning for importing uncompressed audio files) 4) Generate a 5 minute tone, amplitude 0.5 and export as a WAV file. 5) Delete the track. 6) Apply the Chain to the exported file. The processed file has a peak amplitude of -7 dB when it should be -1 dB (it has been amplified by -1 dB as if the original peak amplitude was 0 dB)
Release Note:	GROUP:Chains * '''Chains including "Normalize" applied to files''' will not normalize to the correct value if applied to "read directly" WAV or AIFF files having a peak below 0 dB. '''Workaround:''' Set the Import / Export Preferences to "Make a copy of uncompressed audio files".
First Git SHA:
Group:	---
Workaround:
Closed:	2018-08-20 00:00:00

Flags:	stevethefiddle: Regression+

Attachments
Add an attachment (proposed patch, testcase, etc.)

Note You need to log in before you can comment on or make changes to this bug.

Description Steve Daulton 2012-03-25 11:32:08 UTC

When "Read Direct (faster)" is enabled, using Normalize in a chain produces the incorrect result when the Chain is applied to files.

(see steps to reproduce).

The bug does not appear to be present in Audacity 1.3.12.

Workaround:
Use "Make a copy of uncompressed audio" option in Preferences.

Comment 1 Gale Andrews 2012-03-26 01:00:54 UTC

Thanks, Steve for investigating. Added forum thread URL. Steve said therein "I think that Normalize is the only effect that actually needs to know the peak level of the audio. The only other effect that I think may possibly have a similar problem is the Noise Removal effect". 

I did not see a difference between noise removing the tone used in the steps to repro when done standalone and as a chain on the exported then imported tone. 

If it's P3 (or P2) then a Release Note is mandatory including any "Workaround". Done. 

I'm gonna be rash and call it a P2 cherry. Normalize must be a popular choice to use in Chains and people may not be aware of the issue until too late.

Comment 2 James Crook 2012-04-05 11:13:37 UTC

Removed the 'cherry' designation.  

It's not a quick and easy one to fix.  From the description I'd suspect that Normalize can be got to give the wrong threshold outside chains too, when selecting the entire track and on demand hasn't yet finished processing the whole file when the file is 2 hours of silence with a spike at the end.

Comment 3 Michael Chinen 2012-05-23 18:55:38 UTC

fix committed in r11748

Comment 4 Gale Andrews 2012-06-21 01:55:24 UTC

RESOLVED - FIXED 
(In reply to comment #2)
> I'd suspect that Normalize can be got to give the wrong threshold outside 
> chains too, when selecting the entire track and on demand hasn't yet 
> finished processing the whole file when the file is 2 hours of silence
> with a spike at the end.
Your suspicion was correct. Normalize now shows "Waiting for waveform to finish  
computing..." so that scenario is OK now too. Thanks, Michael.