A simple-to-use sound file writer
in [Python]
|
Prev: dict's as dict's key.
Next: enhancing 'list'
From: Steve Holden on 16 Jan 2010 06:34 Alf P. Steinbach wrote: > * Grant Edwards: >> On 2010-01-15, Steve Holden <steve(a)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? regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
From: Alf P. Steinbach on 16 Jan 2010 07:01 * Steve Holden: > Alf P. Steinbach wrote: >> * Grant Edwards: >>> On 2010-01-15, Steve Holden <steve(a)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
From: Alf P. Steinbach on 16 Jan 2010 08:33 * Alf P. Steinbach: > * Steve Holden: >>> >> 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? > [snip] > 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? I fixed up two more divisions. Not sure if this is 2.x-compatible, but perhaps: <code> # Python 3.1.1 -- *probably* works also with 2.x? # Generating a sine wave as a sum of square waves of various amplitudes & phases. import simple_sound # Step 1 "Divide a full cycle of the sine wave into n intervals." n = 100 # Step 2 -- Just an explanation of the rest # Step 3 "In the first half of the cycle, for each bar create that bar as # a square wave of frequency f, amplitude half the bar's height, and phase # starting at the bar's left, plus same square wave with negative sign # (inverted amplitude) and phase starting at the bar's right." square_waves = [] for i in range( n//2 ): middle_of_interval = (i + 0.5)/n amp = simple_sound.sample_sine( 1, middle_of_interval ) / 2.0 def first_square_wave( t, i = i, amp = amp ): phase = 1.0*i/n return amp*simple_sound.sample_square( 1.0, t - phase ) def second_square_wave( t, i = i, amp = amp ): phase = 1.0*(i + 1)/n return -amp*simple_sound.sample_square( 1.0, t - phase ) square_waves.append( first_square_wave ) square_waves.append( second_square_wave ) # Step 4 "Sum all the square waves from step 3." def sample_squares( f, t ): samples = [] o_time = f*t for func in square_waves: sq_sample = func( o_time ) samples.append( sq_sample ) return sum( samples ) # Finally, generate this is in an [.aiff] file: 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.0*i/sample_rate sample = sample_squares( f, t ) writer.write( sample ) writer.close() </code> Cheers & hth., - Alf
From: Steve Holden on 16 Jan 2010 17:56 Alf P. Steinbach wrote: > * Steve Holden: >> Alf P. Steinbach wrote: >>> * Grant Edwards: >>>> On 2010-01-15, Steve Holden <steve(a)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 That was indeed the case. 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. Of course another technique is to scale the already floating-point raw values before dividing by the range of the analog output - then an integer division should work basically fine? Under Python 3 I see 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 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 [ 0000120 245 176 237 375 232 335 226 043 221 324 215 364 212 210 207 222 245 ~ 237 375 232 335 226 # 221 324 215 364 212 210 207 222 0000140 205 026 203 026 201 224 200 222 200 021 200 021 200 222 201 224 205 026 203 026 201 224 200 222 200 021 200 021 200 222 201 224 0000160 203 026 205 026 207 222 212 210 215 364 221 324 226 043 232 335 203 026 205 026 207 222 212 210 215 364 221 324 226 # 232 335 0000200 237 375 245 176 253 133 261 215 270 016 276 330 305 344 315 053 237 375 245 ~ 253 [ 261 215 270 016 276 330 305 344 315 + 0000220 324 245 334 112 344 024 353 372 363 364 373 373 004 005 014 014 324 245 334 J 344 024 353 372 363 364 373 373 004 005 \f \f and so on, but I still get silence from the Quicktime player. regards Steve -- Steve Holden +1 571 484 6266 +1 800 494 3119 PyCon is coming! Atlanta, Feb 2010 http://us.pycon.org/ Holden Web LLC http://www.holdenweb.com/ UPCOMING EVENTS: http://holdenweb.eventbrite.com/
From: Alf P. Steinbach on 16 Jan 2010 18:38
* Steve Holden: > Alf P. Steinbach wrote: >> * Steve Holden: >>> Alf P. Steinbach wrote: >>>> * Grant Edwards: >>>>> On 2010-01-15, Steve Holden <steve(a)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). Cheers & hth., - Alf |