sound normalization made distortion bigger

Hi.. I normalized some wav files using the following code. The reason to normalize is that I need the sound to have the same power.

When I played it in low volume everything is okay. But when I get the volume up, the sounds get terrible and distorted.

What is going on?

data_dir = sprintf('%s/data/audio_wav/Uniq_uncued',root_dir);

% Get a list of all files in the directory with the .wav extension.
files = dir(sprintf('%s/*.wav', data_dir)); %we only want control for cues.

%% Loop through each file
for idx = 1:length(files)

% read file
file = sprintf('%s/%s', data_dir, files(idx).name);
    
% get sound
[y,Fs] = audioread(file);

% get sound power
signalPower = sum(y.^2,1)/size(y,1);
%playsound
soundsc(y,Fs); pause(3);
%normalize power (L2 norm normalization)
new_y = y ./ sqrt( signalPower )/10;
% check sound power
new_signalPower = sum(new_y.^2,1)/size(new_y,1);
%playsound
soundsc(new_y,Fs); pause(3);

% This part of the code is trying to prevent the distortion (got it from a post, but it is not working)
yInt = new_y * 32768;
yInt(yInt == 32768) = 32767;

% save 
[pathstr, name, ext] = fileparts(file);
audiowrite(sprintf('%s/%s_norm.wav', data_dir, name), yInt, Fs);
end 

Thanks

[L]

I think that the sound is being clipped when saving using audiowrite. That is the problem.

Just don't know how to solve it.

Answer 1

[Walter Roberson]

yInt = new_y * 32768;

You need to convert to int16 after you zap the 32768.

You could consider using im2int16 instead of your current steps.

[L]

Would this prevent the cliping?

Should I use im2int16 before calling audiowrite?

[Walter Roberson]

Yes. Unless you change the BitsPerSample, then audiowrite() of double precision data assumes that the data is in the range -1 to +1 and scales it by 32768 to create int16 internally, which is what gets written to the file.

The problem you are having is that you scaled by 32768 already, but you left it as class double, so audiowrite is going to scale it again, not knowing that you already scaled it.

Another approach is that you could just audiowrite new_y directly: that would automatically rescale the double to int16 to write to the file.

To clarify: for double precision writing to wav file, the data is automatically converted to int16, which is the most common internal representation for .wav files. This is handled transparently.

When you audioread() then by default it reads in the int16 and converts it to double precision for the user -- so users do not normally notice the internal representation of .wav since they asked to write double precision and when they read it back they get double precision.

If you want to see the actual integer values stored in the .wav file, you have to add the 'native' option to audioread()

[L]

Thanks for your answer.

I actually solved the problem by using BitsPerSample as 64.

[Walter Roberson]

@L

yes, that should work, as it would trigger saving in double precision. However, the code

yInt = new_y * 32768;

strongly implies that you are converting to unsigned 16 bit integer.

When you read in the file with audioread(), it is likely (but not certain) that the "information content" is only 16 bits per sample. You do a computation to arrive at a scalar and divide all of the samples by that same scalar: the "information content" of each scalar would continue to be 16 bits. But you are writing out the results as 64 bits -- it is a waste of space.