[SciPy-User] Wave files / PCM question

[Nicolau Werneck]

Hi. That is one interesting question. The fact is that integer formats
allow, or better, force you to have one extra possible level for the
negative values (assuming we are using two's complement as
usual). This is one asymmetry we just have to live with.

In practice, when you need symmetry you will not use the 0 (or -128)
level in the case of 8 bits or the -2**15 level in the case of 16
bits. You have to keep that in mind when you are generating a
sinusoid, for example. But if you are generating a PWM signal for
example, you might use it. But of course, it's a very little and
subtle difference.

Myself, I would map the 0 to the 0.0, and normalize the maximum
absolute value (-2**15) to -1 when converting from integer to FP, but
then multiply by -2**15-1 when converting back. Unless you know the
input signal will certainly not have a -2**15 in it, in which case you
can use -2**15-1 both ways. If you map your floating point 0.0 to -0.5,
then round it down when converting to integer, your 0 level will be a
1 DC, and unless you have a high-pass filter in your DAC output (as is
usually the case), that can cause you trouble. All sorts of trouble,
not just in an electronic output...

It's important to know that your 0 really means the absolute
silence. And it's also important to avoid clipping yous signals. So in
general I advise you to simply forget about the possibility of the
-2**15 level. Unless you know what you are doing, in which case you
wouldn't need advice. :)

Fun fact: on floating point representation there is a "+0" and a "-0",
because the notation is not two's complement, it's a signal, mantissa
and exponent. This is kind of a curse with binary numbers
representation, if it's not an extra -2**15, it's a dual 0
representation... So don't be upset with wasting the -2**15 level,
because when you work with FP you are also dealing with other kinds of
tiny odd resource wasting too!

Happy hacking! :)

  ++nic




On Sun, Nov 07, 2010 at 11:51:51PM +0100, Dan Goodman wrote:
> Hi all,
> 
> In a linear PCM encoded wave file, the samples are typically stored 
> either as unsigned bytes or signed 16 bit integers. Does anyone know 
> (and preferably have a solid reference for) the correct conversion for 
> both of these types to floats between -1 and 1?
> 
> My assumption would be that no possible values should be wasted, so that 
> -1 should correspond to 0 (or -2**15) and +1 should correspond to 255 
> (or 2**15-1) for 8 (or 16) bit samples. But this has the odd feature 
> that 0 is not represented, as it would have to correspond to 127.5 (or 
> -0.5). That doesn't bother me too much, at least in the case of the 
> unsigned bytes, but in the case of the signed 16 bit ints, it means that 
> the zero of the signed 16 bit int doesn't correspond to the zero of the 
> float, and that essentially the signedness of the 16 bit int is more or 
> less ignored.
> 
> The alternative is that the signedness is used and +/- 1 corresponds to 
> +/- 2**15-1, which would mean that the value -2**15 is never used for 16 
> bit LPCM, which seems to violate my intuition about how people used to 
> design file formats back in the good old days when everything was very 
> efficient.
> 
> So which is it? Waste -2**15 or violate 0=0? I've found web pages that 
> seem to suggest both possibilities, but I'm not sure what the definitive 
> reference is for this.
> 
> Apologies for slightly offtopic question, although I am using numpy and 
> scipy. :)
> 
> Dan
> 
> _______________________________________________
> SciPy-User mailing list
> SciPy-User at scipy.org
> http://mail.scipy.org/mailman/listinfo/scipy-user

-- 
Nicolau Werneck <nwerneck at gmail.com>          C3CF E29F 5350 5DAA 3705
http://www.lti.pcs.usp.br/~nwerneck           7B9E D6C4 37BB DA64 6F15
Linux user #460716
"One man's "magic" is another man's engineering. "Supernatural" is a null word. "
-- Robert Heinlein

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: Digital signature
URL: <http://mail.scipy.org/pipermail/scipy-user/attachments/20101107/906d6e67/attachment.sig>