Why i am gettiing warning

I have generated dtmf tones and i am listening them i tried to write them in wave file by using this command

wavwrite(dtmf,8000,'alpha');

Although the file is saved but i m gettiing these warnings Can u explain me these

Warning: Data clipped during write to file:alpha 
> In wavwrite>PCM_Quantize at 287
  In wavwrite>write_wavedat at 309
  In wavwrite at 138
  In dtmfdial at 100

Answer 1

[Jan]

The line 287 of WAVWRITE is reached only for less than 32 bit precision.

If you write a WAV-file with 32 bits resoltution, the allowed data range is -1 <= Y <= 1. But for 8, 16 or 24 bits, the limits are -1 <= Y < 1, such that Y==1 creates the clipping warning.

Even Y./max(abs(Y)) will not catch this. Does anybody knows an efficient method for scaling?

[Jan]

BTW: WAVWRITE is a nice example for a bad programming style. E.g. in PCM_Quantize:

1. Do not calculate "2.^(nbits-1)", if "switch nbits" is following directly. If all 3 valid nbits are hardcoded, hardcoding the range is better.

2. "[path name ext] = fileparts( fmt.filename )"? Do not shaddow the built-in "path", name and ext are needed in case of errors only, so do not obtain them as default.

3. "ylim = [-1 +1];"? Do not shaddow built-in function names.

4. Three lines to create the [1x2] vector qlim? What about "qlim = [b-m, b+1-1]"? But two scalars would be smarter.

5. "i = find(y < qlim(1)); if ~isempty(i) ..."? Do not shaddow the built-in "i". Logical indexing is faster: "idx = (y < qlim(1)), if any(idx) ...".

This could be continued: IF statements with side-effects; FINDSTR; FOPEN('wb') although there is no 'b' format since Matlab 5.3 anymore; an auto-indent would be fancy also.

Well.

[Daniel Shub]

@Jan, in answer to your question:

Y = Y./max(abs(Y(:)))*(1-(2^-(nBits-1)));

A limitation of signed integers is that you cannot have symmetric fullscale data.

Answer 2

[Walter Roberson]

You have values that were either less than -1 or greater than (or equal to) 1.

[moonman]

is this ok or there is some flaw in my code

i am generating DTMF tones

[Walter Roberson]

Clipping could introduce significant distortion to the signal, potentially even enough to lose information about what frequency a particular pulse was.

You should try to figure out why you are getting the clipping.

Sometimes clipping happens because people are working with values in the range 0 to 255 and assume that this will be somehow noticed by wavwrite() and turned in to 8 bit values. And wavwrite() can handle 8 bit values without difficulty, but it looks at the data type (double vs uint8) to decide what the values are intended to represent rather than looking at the range of values. Sometimes people miss something small in their code and have their uint8 data turn in to double data when the didn't intend to.

But my guess is that you are doing simple addition of the signals for the individual tones and coming out with values up to +/- 2 because of that. Scaling the whole stream of data in response is not really appropriate (otherwise all your monofrequency tones come out at half volume): instead the code that is doing the additive generation of those two signals should ensure that the sum is kept within range.

Answer 3

[Walter Roberson]

The below code should adjust the range to be no more negative than -1 (inclusive), and less positive than 1 (exclusive):

maxd = max(dtmf(:));
mind = min(dtmf(:));
if mind + maxd < 0   %more negative than positive
  dtmf = dtmf ./ (-mind);
else
  dtmf = dtmf ./ (maxd * (1+eps));
end

[Geethu]

can you suggest where to include this code? I have the same problem.

[Walter Roberson]

Include it just before the wavwrite()

[Geethu]

Thank you!!! It worked!

Answer 4

[Wayne King]

Hi, Moonman, as Walter correctly states, the values in your vector (waveform) exceed 1 and -1. You don't want the data values clipped in your wav file, so try.

    dtmf = dtmf./max(abs(dtmf));

and try to write it again.

[Wayne King]

It's fine that your code is generating a waveform with a range of values greater than [1 -1] but you can scale it inside your code or just when you write the wave file, that's up to you.

[moonman]

hi king I am writing as per ur advice but i am still getting error

dtmf = dtmf./max(abs(dtmf));

any other option for it

[Sean de Wolski]

what error?

what does size(dtmf) return?

[moonman]

now i am not getting error

wavwrite(dtmf,8000,32,'alpha');

with 32 bit

Answer 5

[moonman]

Write it like this

wavwrite(dtmf,8000,32,'alpha');

Answer 6

[tammna abid]

i guess now its totally different error of window or somthing ...

like this one http://www.ozzu.com/mswindows-forum/please-help-need-codec-something-like-that-t28928.html

don't know if i am rite or not

[Daniel Shub]

No, the problem is you are creating a 32 bit wav file, which is pretty rare. Your best bet is to create a 16 bit wav file. In order to do this your array needs to be scaled so that the magnitude of every sample is less than 1.

Answer 7

[Ingo Schalk-Schupp]

In wavwrite.m, replace:

m = 2.^(nbits-1);

with

m = 2.^(nbits-1)-1;

This scales the data to the maximum positive integer range, instead of the negative. As a result, float data that is scaled to a maximum absolute value of 1 does not get clipped. However, you will have a different scaling than the one implemented by MATLAB. I consider this a minor drawback assuming that you can choose your normalization freely.

As was mentioned before, the reason for the problem is that signed integer representations typically allow for an additional negative number, e.g., -32768..32767. In my opinion, quantizing float to integer should always choose the smaller absolute value as the normalization factor, because only then will the integer signal stay symmetric and unclipped.

[Ingo Schalk-Schupp]

You could as well hook in your own integer conversion function, but do not forget to warn about actual clipping.