Guilherme Polo <ggp...@gmail.com> added the comment: > "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 :) _______________________________________ Python tracker <rep...@bugs.python.org> <http://bugs.python.org/issue4913> _______________________________________ _______________________________________________ Python-bugs-list mailing list Unsubscribe: http://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
