A simple-to-use sound file writer

[Alf P. Steinbach]

* Alf P. Steinbach:
> * Steve Holden:
>> Alf P. Steinbach wrote:
>>> * Steve Holden:
>>>> Alf P. Steinbach wrote:
>>>>> * Grant Edwards:
>>>>>> On 2010-01-15, Steve Holden <steve at holdenweb.com> wrote:
>>>>>>
>>>>>>> I will, however, observe that your definition of a square wave is
>>>>>>> what I
>>>>>>> would have to call a "'square' wave" (and would prefer to call a
>>>>>>> "pulse
>>>>>>> train"), as I envisage a square wave as a waveform having a 50% duty
>>>>>>> cycle, as in
>>>>>>>
>>>>>>>  ___     ___
>>>>>>> |   |   |   |
>>>>>>> |   |   |   |
>>>>>>> |   |   |   |
>>>>>>> +---+---+---+---+ and so on ad infinitum, (though I might allow you
>>>>>>>     |   |   |   |                          to adjust the position
>>>>>>>     |   |   |   |                          of y=0 if you want)
>>>>>>>     |___|   |___|
>>>>>> That is a square wave.
>>>>>>
>>>>>>> as opposed to your
>>>>>>>
>>>>>>>          _
>>>>>>>         | |
>>>>>>>         | |
>>>>>>>   ______| |______   ______
>>>>>>>                  | |
>>>>>>>                  | |
>>>>>>>                  |_|
>>>>>> That isn't.
>>>>>>
>>>>>> Arguing to the contrary is just being Humpty Dumpty...
>>>>> Neither I nor Steve has called that latter wave a square wave.
>>>>>
>>>>> Steve, quoted above, has written that I defined a square wave that 
>>>>> way.
>>>>> I have not. So Steve's statement is a misrepresentation (I 
>>>>> described it
>>>>> as a sum of two square waves, which it is), whatever the reason for 
>>>>> that
>>>>> misrepresentation.
>>>>>
>>>>>
>>
> [snip]
>> So here you have an interesting example of a
>> piece of code that is pathological in Python2. All you have to change is
>> to add
>>
>>   from __future__ import __division__
>>
>> and bingo! It's a multi-language program. But try seeing what 2to3 says
>> about your Python3 code :)
>>
>> I will forgive you the omission of the ".0" because I too would assume
>> that it would be slower.
> 
> I did not make any such assumption, no. The *1 just lingered from some 
> testing.
> 
> 
> [snip]
>> and so on, but I still get silence from the Quicktime player.
> 
> I don't know, sorry.
> 
> It might be that [simple_sound] also needs the "from __future__" treatment.
> 
> But anyway, with 2.x compatible code you can now see that the sample 
> values produced are correct (just print them, or graph them).

I have now installed CPython 2.6.4 and the code presented upthread (the one with 
divisions fixed for 2.x compatibility) worked nicely with CPython 2.6.4, even 
though with a deprecation warning.

It produced the exact same sound file (bytes) as with CPython 3.1.1.

And the QuickTime 7.3 player played it with no problem, a base A pure sinewave, 
composed utterly of 50% duty cycle square waves, resounding in my headphones -- 
it also works with WinAmp 5.54, Windows Mediaplayer 10.00 and VLC 0.9.9, i.e. 
I'm unable to reproduce the problem.

So I suspect that you may lack a suitable codec, or it might be a PEBKAC problem?


Cheers & hth.,

- Alf

PS: I had expected some jaggies and such since I only divided the cycle into 100 
intervals, but graphing the data in Excel it showed a perfect sine. :-)