A simple-to-use sound file writer
in [Python]
|
Prev: dict's as dict's key.
Next: enhancing 'list'
From: Lie Ryan on 14 Jan 2010 17:21 On 01/15/10 05:42, Alf P. Steinbach wrote: > I'm beginning to believe that you maybe didn't grok that simple procedure. > > It's very very very trivial, so maybe you were looking for something > more intricate -- they used to say, in the old days, "hold on, this > proof goes by so fast you may not notice it!" Since you said it's trivial, then... >> Nothing about you there. Just the information you are promoting. I don't >> normally deal in innuendo and personal attacks. Though I do occasionally >> get irritated by what I perceive to be hogwash. People who know me will >> tell you, if I am wrong I will happily admit it. > > There's a difference between an algorithm that you can implement, and > hogwash. please prove your claim by writing that algorithm in code and post it in this list. The program must accept a .wav file (or sound format of your choice) and process it according to your algorithm and the output another .wav file (or sound format of your choice) that sounds roughly similar to the input file. PS: I have near-zero experience with sound processing PPS: I will be equally delighted seeing either Steve admitting his wrong or you admit your hogwash PPPS: An alternative way to convince us is to provide a paper/article that describes this algorithm. PPPPS: Though I will be quite sad if you choose to reject the challenge
From: Alf P. Steinbach on 14 Jan 2010 19:45 * Lie Ryan: > On 01/15/10 05:42, Alf P. Steinbach wrote: >> I'm beginning to believe that you maybe didn't grok that simple procedure. >> >> It's very very very trivial, so maybe you were looking for something >> more intricate -- they used to say, in the old days, "hold on, this >> proof goes by so fast you may not notice it!" > > Since you said it's trivial, then... You can't get it more trivial. >>> Nothing about you there. Just the information you are promoting. I don't >>> normally deal in innuendo and personal attacks. Though I do occasionally >>> get irritated by what I perceive to be hogwash. People who know me will >>> tell you, if I am wrong I will happily admit it. >> There's a difference between an algorithm that you can implement, and >> hogwash. > > please prove your claim by writing that algorithm in code and post it in > this list. The program must accept a .wav file (or sound format of your > choice) and process it according to your algorithm and the output > another .wav file (or sound format of your choice) that sounds roughly > similar to the input file. First, the (very very trivial) algorithm I posted does *not* do that: by itself it represents a sine wave, not an arbitrary wave form. And second I'm not about to write Fourier transform code to satisfy someone who refuses to do a milligram of thinking. The Fourier part stuff needed to do what you're requesting is non-trivial, or at least it's some work to write the code. > PS: I have near-zero experience with sound processing > PPS: I will be equally delighted seeing either Steve admitting his wrong > or you admit your hogwash > PPPS: An alternative way to convince us is to provide a paper/article > that describes this algorithm. > PPPPS: Though I will be quite sad if you choose to reject the challenge I don't believe any of what you write here. Cheers & hth., - Alf
From: Alf P. Steinbach on 14 Jan 2010 22:04 * Lie Ryan: > On 01/15/10 05:42, Alf P. Steinbach wrote: >> I'm beginning to believe that you maybe didn't grok that simple procedure. >> >> It's very very very trivial, so maybe you were looking for something >> more intricate -- they used to say, in the old days, "hold on, this >> proof goes by so fast you may not notice it!" > > Since you said it's trivial, then... > >>> Nothing about you there. Just the information you are promoting. I don't >>> normally deal in innuendo and personal attacks. Though I do occasionally >>> get irritated by what I perceive to be hogwash. People who know me will >>> tell you, if I am wrong I will happily admit it. >> There's a difference between an algorithm that you can implement, and >> hogwash. > > please prove your claim by writing that algorithm in code and post it in > this list. The program must accept a .wav file (or sound format of your > choice) and process it according to your algorithm and the output > another .wav file (or sound format of your choice) that sounds roughly > similar to the input file. In addition to my earlier reply (that the presented algorithm itself doesn't generate arbitrary wave forms but only sines, i.e. that you're totally off the mark), your request is meaningless in another way, namely: the algorithm does synthesis, which is easy (like computer speech), while you're asking for analysis (like computer speech recognition), which is hard. But maybe you're simply not able to understand the algorithm, trivial as it is. So, a Python implementation (note, this program takes some time to run!): <code filename="sinewave_from_squares.py"> # 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 def first_square_wave( t, i = i, amp = amp ): phase = i/n return amp*simple_sound.sample_square( 1, t - phase ) def second_square_wave( t, i = i, amp = amp ): phase = (i + 1)/n return -amp*simple_sound.sample_square( 1, 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 a [.aiff] file so as to possibly satisfy Lie Rian: 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 ) writer.write( sample ) writer.close() </code> Cheers & hth., - Alf
From: Steve Holden on 14 Jan 2010 22:52 Alf P. Steinbach wrote: > * Lie Ryan: >> On 01/15/10 05:42, Alf P. Steinbach wrote: >>> I'm beginning to believe that you maybe didn't grok that simple >>> procedure. >>> >>> It's very very very trivial, so maybe you were looking for something >>> more intricate -- they used to say, in the old days, "hold on, this >>> proof goes by so fast you may not notice it!" >> >> Since you said it's trivial, then... > > You can't get it more trivial. > > >>>> Nothing about you there. Just the information you are promoting. I >>>> don't >>>> normally deal in innuendo and personal attacks. Though I do >>>> occasionally >>>> get irritated by what I perceive to be hogwash. People who know me will >>>> tell you, if I am wrong I will happily admit it. >>> There's a difference between an algorithm that you can implement, and >>> hogwash. >> >> please prove your claim by writing that algorithm in code and post it in >> this list. The program must accept a .wav file (or sound format of your >> choice) and process it according to your algorithm and the output >> another .wav file (or sound format of your choice) that sounds roughly >> similar to the input file. > > First, the (very very trivial) algorithm I posted does *not* do that: by > itself it represents a sine wave, not an arbitrary wave form. > > And second I'm not about to write Fourier transform code to satisfy > someone who refuses to do a milligram of thinking. > > The Fourier part stuff needed to do what you're requesting is > non-trivial, or at least it's some work to write the code. > > >> PS: I have near-zero experience with sound processing >> PPS: I will be equally delighted seeing either Steve admitting his wrong >> or you admit your hogwash >> PPPS: An alternative way to convince us is to provide a paper/article >> that describes this algorithm. >> PPPPS: Though I will be quite sad if you choose to reject the challenge > > I don't believe any of what you write here. > Well, it seems quite reasonable to me, but then I'm not the one being challenged to write a trivial algorithm. 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) |___| |___| as opposed to your _ | | | | ______| |______ ______ | | | | |_| So I can see how we might be at cross purposes. I could cite authorities for differentiating between a square wave and a symmetric pulse train, but will content myself with observing only that my impression is the common definition of an ideal square wave (one with a zero transition time) admits of only two instantaneous values, eschewing the zero you use. If that is the case, we could perhaps agree that we differ merely on terminology. 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. not-wriggling-real-ly y'rs - 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 14 Jan 2010 23:23
* Steve Holden: > Alf P. Steinbach wrote: >> * Lie Ryan: >>> On 01/15/10 05:42, Alf P. Steinbach wrote: >>>> I'm beginning to believe that you maybe didn't grok that simple >>>> procedure. >>>> >>>> It's very very very trivial, so maybe you were looking for something >>>> more intricate -- they used to say, in the old days, "hold on, this >>>> proof goes by so fast you may not notice it!" >>> Since you said it's trivial, then... >> You can't get it more trivial. >> >> >>>>> Nothing about you there. Just the information you are promoting. I >>>>> don't >>>>> normally deal in innuendo and personal attacks. Though I do >>>>> occasionally >>>>> get irritated by what I perceive to be hogwash. People who know me will >>>>> tell you, if I am wrong I will happily admit it. >>>> There's a difference between an algorithm that you can implement, and >>>> hogwash. >>> please prove your claim by writing that algorithm in code and post it in >>> this list. The program must accept a .wav file (or sound format of your >>> choice) and process it according to your algorithm and the output >>> another .wav file (or sound format of your choice) that sounds roughly >>> similar to the input file. >> First, the (very very trivial) algorithm I posted does *not* do that: by >> itself it represents a sine wave, not an arbitrary wave form. >> >> And second I'm not about to write Fourier transform code to satisfy >> someone who refuses to do a milligram of thinking. >> >> The Fourier part stuff needed to do what you're requesting is >> non-trivial, or at least it's some work to write the code. >> >> >>> PS: I have near-zero experience with sound processing >>> PPS: I will be equally delighted seeing either Steve admitting his wrong >>> or you admit your hogwash >>> PPPS: An alternative way to convince us is to provide a paper/article >>> that describes this algorithm. >>> PPPPS: Though I will be quite sad if you choose to reject the challenge >> I don't believe any of what you write here. >> > Well, it seems quite reasonable to me, but then I'm not the one being > challenged to write a trivial algorithm. You're again into innuendo, misleading statements and so forth. Lie Ryan's challenge is nothing but trivial, because it's about implementing very much more than the algorithm. I did implement the algorithm for him, in Python, and posted that in this thread. > 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) > |___| |___| > > as opposed to your > > _ > | | > | | > ______| |______ ______ > | | > | | > |_| > Try to read again, a sufficient number of times, how to generate the latter by summing *two instances of the former*. I'm sorry to say this but I find it hard to explain things simple enough for you, because at the level of 2+2 any explanation is far more complex than the concept itself. That is, of course, a challenge to me! :-) So, thanks for challenging my pedagogical abilities. I know they're not as good as they should be, and need some exercise! > So I can see how we might be at cross purposes. I could cite authorities > for differentiating between a square wave and a symmetric pulse train, > but will content myself with observing only that my impression is the > common definition of an ideal square wave (one with a zero transition > time) admits of only two instantaneous values, eschewing the zero you > use. If that is the case, we could perhaps agree that we differ merely > on terminology. No, we don't differ on terminology: we seem to differ in that one of us has severe difficulties understanding the very simplest things, such as what graph one gets by summing two squares waves of same frequency but out of phase. The one of us who has trouble understanding that is also apparently too lazy to try out the earlier advice given him of graphing this on a piece of paper, and instead prefers to spout innuendu, personal attacks and misleading statements. That's a real challenge to the other person. > 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. You would, yes? Perhaps you'd also admit to being wrong, and retract your innuoendo etc.? Well, just epress the waveform as a sum of sine waves (Fourier transform); synthesize each sine wave by a set of 50% duty cycle square waves (I've earlier posted Python code for that in this thread); add all the square waves. The hard part of this is implementing the Fourier transform, I leave that to you. ;-) Cheers & htfh., - Alf |