Alex Robinson <alex_python_...@tranzoa.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. :) That said, not having to offset the 8 bit samples sparsifies the read/write_sample code. But, I'm thinking that that's at the expense of every program that uses it. When in doubt, I figure, do what is more useful. Don't force the caller to write a wrapper if he'll need to do it 99% of the time. But this is not a religious thing with me. A wrapper can be written. And, in fact, I'd sure think it would be nice to include wrappers like auto-scaling and auto-zeroing in wave.py. But maybe not, as these ops probably belong in some array.py type module. Anyway, a non-audio guy who just wants to read a wave file, diddle with it, and write it out. Or who just wants to generate some sound and write it out. Or who just wants to read a wave file and graph it or something. All of these guys will be stunned when they find out to their hours-of-work chagrin that wave files' 8 bit samples are not signed chars. And, if I were one of them, I'd be plenty peeved after having to spend all that time learning about some historical artifact just to read an danged audio file, for gosh sakes. But not putting the 8-bit offset in the read/write_samples logic does eliminate 2 lines of code in each routine.
"writesamples would raise an exception" Yep, taste. I'm inclined to find this irritating and I don't like being irritated by packages I use. Makes for a poor out-of-box experience. But, taste. :) "4) Well, lets fix a format then. else: wavs = [[wav]]" ? That's an extra [] I think. [[samples]] would be an array of array of an array of samples. s = [1,2]; print [ [ a ] ]; [[[1,2]]] On reflection, I'd say I agree with you more than I do with me on the ability of writesamples() to take a simple array of mono samples. Not a good thing to do. "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. Don't know. Didn't measure it. "monkey patch"?' Wonderful! This makes your rewrite of the code *so* much cleaner. Thanks for the tip! "code layout"? Har, har. Yep, no one in software has ever spent any time "discussing" code layout before. Let's do it for the first time in history. "test_wave.py"? Oooo. Bit minimal, that. Yeah, I think a couple of things could be fleshed out there. Gotta run now. But will try to update the code in wave_futz later. Other things on plate, though. Guilherme, I really appreciate your handling this and your guidance. Thanks! _______________________________________ 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
