A simple-to-use sound file writer

Alf P. Steinbach alfps at start.no
Sat Jan 16 07:01:37 EST 2010


* 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.
>>
>>
>>>> Or, best of all, you could show me how to synthesize any
>>>> waveform by adding square waves with a 50% duty cycle.  Then I
>>>> *will* be impressed.
>>> Isn't that what he claimed?  He said that his algorithm for
>>> summing square waves demonstrated the converse of the ability
>>> to construct a periodic function (like a square wave) from a
>>> sine-cosine summation.
>> Not by itself, no: it just synthesizes a sine.
>>
>> For the more general case read e.g. the PS in my reply to your earlier
>> (single) article in this thread.
>>
>> For information about what the algorithm does, what you refer to as a
>> "claim" (but note that a Python implementation has been posted to this
>> thread, and that it works, and that besides the algorithm is trivial so
>> that "claim" is a rather meaningless word here), read the article that
>> you then responded to.
>>
> Though for what it's worth I wasn't impressed by the results of running
> the posted program, since it yielded an AIFF file of mostly zeroes that
> produced no audible sound.
> 
> $ od -bc sinewave.aiff
> 0000000 106 117 122 115 000 002 261 076 101 111 106 106 103 117 115 115
>           F   O   R   M  \0 002 261   >   A   I   F   F   C   O   M   M
> 0000020 000 000 000 022 000 001 000 001 130 210 000 020 100 016 254 104
>          \0  \0  \0 022  \0 001  \0 001   X 210  \0 020   @ 016 254   D
> 0000040 000 000 000 000 000 000 123 123 116 104 000 002 261 030 000 000
>          \0  \0  \0  \0  \0  \0   S   S   N   D  \0 002 261 030  \0  \0
> 0000060 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000 000
>          \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0  \0
> *
> 0530500 000 000 000 000 000 000
>          \0  \0  \0  \0  \0  \0
> 0530506
> 
> Any idea what I did wrong?

That sounds like something I did wrong, not like something you did wrong:

It sounds like a  ...  BUG!  ... in my simple_writer code. :-)

Or, that's perhaps not funny, but it occurred to me that it might, to some at 
least, appear to be sort of incongruous in the context of the earlier thread. Heh.

Checking first 20 sample values generated:

<code>
if True:
     f           = 440
     sample_rate = 44100
     total_time  = 2
     n_samples   = sample_rate*total_time

     writer = simple_sound.Writer( "sinewave.aiff" )
     for i in range( n_samples ):
         t = 1*i/sample_rate
         sample = sample_squares( f, t )
         if i < 20: print( sample )                # Check 'em
         writer.write( sample )
     writer.close()
</code>

<output>
-0.0314107590781
-0.0314107590781
-0.0941083133185
-0.15643446504
-0.218143241397
-0.278991106039
-0.338737920245
-0.397147890635
-0.45399049974
-0.50904141575
-0.562083377852
-0.612907053653
-0.661311865324
-0.707106781187
-0.75011106963
-0.790155012376
-0.827080574275
-0.860742027004
-0.891006524188
-0.917754625684
</output>

Checking generated file:

<dump>
$ od -bc sinewave.aiff | head
0000000 106 117 122 115 000 001 130 266 101 111 106 106 103 117 115 115
           F   O   R   M  \0 001   X 266   A   I   F   F   C   O   M   M
0000020 000 000 000 022 000 001 000 000 254 104 000 020 100 016 254 104
          \0  \0  \0 022  \0 001  \0  \0 254   D  \0 020   @ 016 254   D
0000040 000 000 000 000 000 000 123 123 116 104 000 001 130 220 000 000
          \0  \0  \0  \0  \0  \0   S   S   N   D  \0 001   X 220  \0  \0
0000060 000 000 000 000 000 000 373 373 373 373 363 364 353 372 344 024
          \0  \0  \0  \0  \0  \0 373 373 373 373 363 364 353 372 344 024
0000100 334 112 324 245 315 053 305 344 276 330 270 016 261 215 253 133
         334   J 324 245 315   + 305 344 276 330 270 016 261 215 253   [
</dump>


Hm, I'm inclined to think that you used Python 2.x instead of my 3.1.1!

I no longer have Python 2.x installed, I think, so no time to test that now.

But would that be the case?

If so, perhaps changing "t = 1*i/sample_rate" to "t = (1.0*i)/sample_rate" will 
help?


Cheers,

- Alf



More information about the Python-list mailing list