Author gpolo
Recipients alex_python_org, gpolo
Date 2009-01-13.03:02:51
SpamBayes Score 0.110899
Marked as misclassified No
Message-id <ac2200130901121902k2d380310n7bb92080c61245a@mail.gmail.com>
In-reply-to <1231813227.64.0.0644400252103.issue4913@psf.upfronthosting.co.za>
Content
> "DC (0 hz) assumption"?
> wave.py makes the assumption that what the user wants is whatever
> happens to be in the file, however arbitrary. (That 8 bit samples are
> unsigned bytes is probably an artifact of early ADC logic. Typically you
> got an absolute, n-bit value from an old ADC. Newer chips often return
> signed values.) It's very unlikely that anything but a copy program
> would try to work with unsigned char samples. Too many things to go
> wrong. Too much confusion. Zero means zero in most of the world, in and
> out of audio processing. :)

Every document/text I've found so far talks about 8 bit samples being
unsigned, it is not like I'm trying to enforce it just because I want,
just following the specification.
But, SDL for example, accepts wav files with unsigned 8 bits, signed 8
bits, unsigned 16 bits, signed 16 bits, and with different byte
orders, so apparently different libraries write different wave files.
I wonder which of these would be good to get included in wave.py, but
for this current issue I would prefer to not even touch this another
problem and stick with what is the documented for the wave format.

> .
> .
> But not putting the 8-bit offset in the read/write_samples logic does
> eliminate 2 lines of code in each routine.

It is good that it is just two lines, it means they could be added
back (and adapted) when we start supporting different output/input
formats for wave.

> "4) Well, lets fix a format then. else: wavs = [[wav]]" ?
> That's an extra [] I think.

Right.

> "wavs.extend(wav)" ?
> I had to look up extend() and try it in the Python shell! :) To each his
> own. But when I found out that one could do list+=added_list in Python I
> never looked back. Intuitive. I special-cased mono for speed purposes.
> No reason to do the +=/extend for mono samples. But, maybe the
> interpretor handles all that.

It won't just do this optimization, keeping the special case for mono is fine.

> "test_wave.py"?
> Oooo. Bit minimal, that. Yeah, I think a couple of things could be
> fleshed out there.

I'm waiting for the new hand written tests now :)
History
Date User Action Args
2009-01-13 03:02:52gpolosetrecipients: + gpolo, alex_python_org
2009-01-13 03:02:52gpololinkissue4913 messages
2009-01-13 03:02:51gpolocreate