[Patches] support for writing pre-formatted ULAW samples in sunau.

Guido van Rossum guido@python.org
Fri, 21 Apr 2000 15:15:20 -0400


> The sunau module's write objects assume that the data that's coming
> in is always in linear format. When taking some existing data that's in
> ULAW, and writing it out as ULAW, you have to use audioop.ulaw2lin, then
> let the sunau module convert it back - not exactly the most pleasant 
> approach (I also find a loss of quality). 

You're right, a quick test shows that ulaw2lin + lin2ulaw changes two
of the data bytes!  These are the extreme values 0 and 127; somehow 0
gets mapped to 2 instead of to 0 and 127 gets mapped to 255 instead of
to 127.

There's explicit code in the lin2ulaw code that traps a zero output
byte and replaces it with 2.  This is conditional code and called
"CCITT trap"; in addition, it is enabled with a comment "per MIL-STD".
I wonder what this is about?  Maybe it should be disabled?  It turns
the loudest negative value into the third-loudest negative value.
This doesn't make sense to me.

That explains the change of 0 -> 2.  The change from 127 to 255
shouldn't make a difference: both the 127 and the 255 ULAW value map
to 0 in linear space, and I understand that the reverse mapping has to
pick one.  It shouldn't sound any difference because of this.

> As a workaround for this, I added a formatted_ flag to writeframes() and
> writeframesraw() - if this is set, it doesn't do the audioop conversion.
> 
> Couple of questions:
> 
>   Is this appropriate to add to the library (I think so, but... ?)

I'm not sure.  When you're just copying ULAW data, you might be better
off bypassing the entire sunau module altogether; alternatively, you
might subclass the Au_write class to do what you want.

>   Is this the best way?

Not my preference.  Also note that you didn't bother to add a similar
feature to the readframes method.  My guess is that it's a hack, not a
well-thought-out feature.

>   Which other modules should be similarly modified, if this is appropriate?
>   (aifc, wave)? I'm willing to fix these to match, if this is deemed an 
>   appropriate change...

The afc.py module has similar ULAW support.  But I'm not thrilled by
this patch.

(BTW why did you name the argument with a trailing underscore?)

--Guido van Rossum (home page: http://www.python.org/~guido/)