So, in my quest of understanding I have decided to look closer at these 
magical functions. Everyone who's ever encountered an audio player 
probably knows what an FFT. Or has a vague abstract idea as to what it 
can be used for. because it's usually called something like FFT. or FFT 
filter. FFT spectrum. Whatever. I've seen the term floated around in 
such a cavalier manner.

OK, so it's the application of the FFT. Or rather the DFT, seeing as FFT 
is just an optimization of the DFT.

I have a very good handle now on what DFT actually does, and it's a 
pretty nifty transform. What I can't seem to wrap my head around is FFT. 
  But I think I'm getting there. I know it does a bizarre sort at the 
beginning, essentially ordering the data as if the indexes had their 
bits reversed, which allows the next step to happen. The values are then 
recombined, reversing the previous sorting process in such a way as to 
reveal the sine and cosine components of the source signal.

That part is really toasting my brain. I /almost/ understand the theory 
behind it, but there's some part that's blocking me. The amazing part is 
that it takes two nested loops of, say 256 values, and makes it 
essentially a 2-deep nesting of around 8 values with a rather small 
inner loop.

And its entirely reversible. (!)

The cool thing is you can take frequency domain set, multiply it by 
another frequency domain set, invert the DFT, and boom, you just 
filtered your data. No messy convolution.

As an example, you can achieve a blur effect on an image by using 
multiply operations on the image's frequency domain data. rather than 
create a convolution matrix to do the same thing.

I'm not 100 % on the theory of noise reduction, but my basic 
understanding is it basically analyzes a constant signal area of the 
image in the frequency domain, then subtracts that spectrum from the 
noisy signal, thereby cleaning the image, and only minimally harming the 
actual image. Thats my guess, at least. I know most of the popular NR 
algorithms out there work in the frequency domain...

Anyway, I'm rambling :)






-- 
~Mike

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:

> What I can't seem to wrap my head around is FFT.
> But I think I'm getting there. I know it does a bizarre sort at the
> beginning, essentially ordering the data as if the indexes had their
> bits reversed, which allows the next step to happen. The values are then
> recombined, reversing the previous sorting process in such a way as to
> reveal the sine and cosine components of the source signal.

Yikes.  Never had to worry about those details.  I'm usually content enough just
to know that FFTW works!  That said, I'm remembering something about a recursive
factorization for the DFT matrix.  Is that the basis for the FFT, or are the
practical algorithms much more complicated than that?

Anyway, here's someone describing some of the details:
http://ocw.mit.edu/OcwWeb/Mathematics/18-06Spring-2005/VideoLectures/detail/lecture26.htm

And here's a book with some details:
http://books.google.com/books?id=coq49_LRURUC&pg=PA391&lpg=PA391

> And its entirely reversible. (!)

That's really just a property of the Fourier transform itself, isn't it?  At
least to a constant.

> The cool thing is you can take frequency domain set, multiply it by
> another frequency domain set, invert the DFT, and boom, you just
> filtered your data. No messy convolution.

Yes, very convenient.  O(n^2) to O(n log n).  Much less messy, too.

> I'm not 100 % on the theory of noise reduction...

Don't wavelets come into play here?  Fourier transforms aren't local, so doesn't
that amount to a low-pass filter?  I guess you could just break it up like jpeg,
but then you may as well move on to wavelets.  I never really had a reason to
dig into all the details, but I think it might be a worthwhile endeavor.

> Anyway, I'm rambling :)

An enjoyable ramble.

 - Ricky

Post a reply to this message

Mike Raiford wrote:

> I have a very good handle now on what DFT actually does, and it's a 
> pretty nifty transform. What I can't seem to wrap my head around is FFT. 
> But I think I'm getting there.

Every signal can be represented as a sequence of samples, or as the sum 
of some sine (and cosine) components of different frequencies. Two 
different ways to describe the same signal. The DFT (and its inverse) 
convert one into another. This presumably you have already long figured out.

The FFT works by a divide-and-concor method, rather like quicksort and 
mergesort. Take your signal, split it into two signals, transform them 
both [by recursively applying the same algorithm], combine the results 
back together into a single result.

The whole "swap the bits of the indicies around" trick is an 
optimisation to avoid recursively shuffling the samples around. It lets 
you do all the shuffling in a single step instead of log N steps, that's 
all.

Much like quicksort, the DFT of 1 sample is... that 1 sample, unaltered. 
Combining in the frequency domain must undo what was done by splitting 
in the frequency domain... There are actually several slightly different 
(but essentially equivilent) ways to arrange the FFT.

> The cool thing is you can take frequency domain set, multiply it by 
> another frequency domain set, invert the DFT, and boom, you just 
> filtered your data. No messy convolution.
> 
> As an example, you can achieve a blur effect on an image by using 
> multiply operations on the image's frequency domain data. rather than 
> create a convolution matrix to do the same thing.

Multiplication in the frequency domain is convulotion in the time 
domain, and vice versa. FFT convolution is mildly more tricky than it 
looks at first. (You gotta chop the input into "blocks" to run it 
through the FFT, and you need to overlap them after you're done or the 
"blur" will stop at the block edges - which is wrong.)

Any further questions?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

...he says, as if he knows *exactly* what he's talking about! ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

> Every signal can be represented as a sequence of samples, or as the sum 
> of some sine (and cosine) components of different frequencies. Two 
> different ways to describe the same signal. The DFT (and its inverse) 
> convert one into another. This presumably you have already long figured 
> out.

Yep. I pretty much figured that out ... real is the cosine, imaginary is 
the sine components. Add those components together, and you get the 
original time-domain signal. (Well, really average)

> 
> The FFT works by a divide-and-concor method, rather like quicksort and 
> mergesort. Take your signal, split it into two signals, transform them 
> both [by recursively applying the same algorithm], combine the results 
> back together into a single result.

> The whole "swap the bits of the indicies around" trick is an 
> optimisation to avoid recursively shuffling the samples around. It lets 
> you do all the shuffling in a single step instead of log N steps, that's 
> all.
> 

That much I got, and the order of the data seemed to make sense to me, 
what's racking my brain is the butterfly... That seems to be the "magic" 
piece that makes the whole thing work.

> Much like quicksort, the DFT of 1 sample is... that 1 sample, unaltered. 
> Combining in the frequency domain must undo what was done by splitting 
> in the frequency domain... There are actually several slightly different 
> (but essentially equivilent) ways to arrange the FFT.

Yep, figured that part out, too. Realizing that 1 sample is essentially 
DC, and the real value at index 0 is the DC component made that clear.

> 
>> The cool thing is you can take frequency domain set, multiply it by 
>> another frequency domain set, invert the DFT, and boom, you just 
>> filtered your data. No messy convolution.
>>
>> As an example, you can achieve a blur effect on an image by using 
>> multiply operations on the image's frequency domain data. rather than 
>> create a convolution matrix to do the same thing.
> 
> Multiplication in the frequency domain is convulotion in the time 
> domain, and vice versa. FFT convolution is mildly more tricky than it 
> looks at first. (You gotta chop the input into "blocks" to run it 
> through the FFT, and you need to overlap them after you're done or the 
> "blur" will stop at the block edges - which is wrong.)
> 

I'm supposing this is where Hamming and Blackmann windows come into play?

> Any further questions?
> 

Heh, as more come to me. I'm tossing together a little C# app to play 
around with the FFT and be able to examine it in both rectangular and 
polar forms.

I knew you'd have something to add to this, since you seem to be quite 
advanced in mathematics.

Post a reply to this message

Michael Raiford <mra### [at] hotmailcom> wrote:
> Heh, as more come to me. I'm tossing together a little C# app to play
> around with the FFT and be able to examine it in both rectangular and
> polar forms.

Aha, I knew I had that lying around somewhere.  If you just want to play with
the behavior and not implement it yourself, there's always Matlab, or its free
equivalent, Octave.  Here's the simplest low-pass filter:

n=101; tmin=0; tmax=10;
%calculate time & frequency
  tbase = linspace(tmin,tmax,n);
  dt    = (tmax-tmin)/(n-1);
  ni    = floor((n-1)/2);
  fbase = [0:floor(n/2),ni:-1:1] /ni/2.0/dt;
%calculate y and fft(y)
  y = rand(size(tbase));
  Y = fft(y);
%filter
  Y_filt = Y;
  Y_filt(find(fbase>2.0)) = 0;
  y_filt = ifft(Y_filt);
%plot
  figure(1);  plot(tbase,y,tbase,y_filt);
  figure(2);  plot(fbase,abs(Y_filt));

 - Ricky

Post a reply to this message

> That much I got, and the order of the data seemed to make sense to me, 
> what's racking my brain is the butterfly... That seems to be the "magic" 
> piece that makes the whole thing work.

Well, you *could* take the time-domain signal and cut it into two 
halves. But that's not very easy to undo in the frequency domain. So 
what they usually do is take all the odd samples and all the even samples.

Taking all the even samples is just halving the sampling rate. [Assuming 
0-based indexing!] Halving the time domain means doubling the frequency 
domain. (Think about it: You take a sound, cut out half the samples, 
that's like doubling the playback speed. All the pitches are twice as high!)

Taking all the odd samples is like shifting one sample to the side and 
then halving the sampling rate as per above. In the frequency domain, 
such a time shift is a multiplication by a sinewave.

So, to undo all this, double both signals, multiply one by a sinewave, 
then add them back together. Hence, the butterfly.

>> Combining in the frequency domain must undo what was done 
>> by splitting in the frequency domain...

Grr... "Combining in the *frequency domain* must ondo what was done by 
splitting in the *time domain*." Get it right, boy! >_<

>> Multiplication in the frequency domain is convulotion in the time 
>> domain, and vice versa. FFT convolution is mildly more tricky than it 
>> looks at first. (You gotta chop the input into "blocks" to run it 
>> through the FFT, and you need to overlap them after you're done or the 
>> "blur" will stop at the block edges - which is wrong.)
> 
> I'm supposing this is where Hamming and Blackmann windows come into play?

No. Those come into play if you're trying to desing a digital filter. 
(E.g., a "perfect" lowpass filter has an infinite frequency response, 
but we can't do that. If you just chop the ends off it screws up the 
frequency response. Using (say) a Hamming window reduces the effect - 
but doesn't eliminate it.)

Recall that the convolution of a signal by some kernel is *longer* than 
the original signal. This is the effect you have to repeat when doing 
FFT convolution. (The details escape me at this exact moment... Suffice 
it to say that your inverse-FFT results have to be overlapped to get a 
smooth result.)

> I knew you'd have something to add to this, since you seem to be quite 
> advanced in mathematics.

Meh. I wanted to build a digital filter, so I read a rather excellent 
book on the subject. ;-)

Wanna see the Z-transform?

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

> 
> Meh. I wanted to build a digital filter, so I read a rather excellent 
> book on the subject. ;-)

But, you see ... you have an interest in such things.

> Wanna see the Z-transform?

Z transform?

Post a reply to this message

>> Meh. I wanted to build a digital filter, so I read a rather excellent 
>> book on the subject. ;-)
> 
> But, you see ... you have an interest in such things.

I read Wikipedia - and discovered that it is *completely useless* for 
learning this kind of thing! But then I found a book online, and read 
that. ;-)

>> Wanna see the Z-transform?
> 
> Z transform?

Weeell... The Fourier transform comes in several different "flavours", 
but essentially you have

- The continuous Fourier transform takes a formula and turns it into a 
different formula.
- The discrete Fourier transform takes some numbers and turns them into 
some other numbers.

There is a generalisation of the [continuous] Fourier transform called 
the Laplace transform. The correspondin discrete version is called the 
Z-transform.

The Laplace transform is the trippy mumma you use for designing Infinite 
Inpulse Response filters.

See, Finite Impulse Response (FIR) filters are very easy to design, and 
very flexible, but they take quite a bit of compute power. If you want 
precise filtering (e.g., for scientific purposes) then you're going to 
use FIR.

On the other hand, Infinite Impulse Response filters use feedback to 
generate an impulse response which is effectively "infinitely long". The 
downside is that only certain impulse responses can be created by 
feedback. Oh, and that controlling feedback is damned tricky.

Enter the Laplace transform. This makes it relatively easy to figure out 
how much feedback to apply.

It just so happens that the impulse response of a perfect lowpass filter 
"nearly" matches the kinds of impulse responses that an IIR can produce. 
The net result of this is that with only a tiny amount of calculation, 
you can get pretty good results.

In other words, IIR is massively, massively faster than FIR. (It's also 
far less precise, nowhere near as flexible, and way harder to design.)

While we're on the subject, the Laplace transform turns differential 
equations into algebraic equations, making them drastically easier to 
solve. As I understand it, that's why mathematicians came up with it in 
the first place.

Jesus Christ, SOMEBODY HIRE ME!! >_<

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> So, to undo all this, double both signals, multiply one by a sinewave, 
> then add them back together. Hence, the butterfly.

I want you to know that's the first explanation of it I've ever been able to 
follow.  I'm not a very mathematical person.

You definitely should write some Haskell documentation. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

>> So, to undo all this, double both signals, multiply one by a sinewave, 
>> then add them back together. Hence, the butterfly.
> 
> I want you to know that's the first explanation of it I've ever been 
> able to follow.

Shamelessly paraphrased from The DSP Guide. ;-) But thank you.

It seems to be that (in general) there are two ways to explain any 
mathematical result:

- As a sequence of mechanical transformations of symbols.
- As a vague but intuitive examination of *why* this (or at least 
something roughly this shape) should work.

Non-mathematicians tend to respond better to the latter, and it's 
terribly hard to glean from the former.

I still vividly remember the day I figured out why that famous formula 
actually solves quadratic equations. Maybe I'll share it with you?

> I'm not a very mathematical person.

...says the guy who actually knows WTF a nondeterministic Turing machine 
*is*! :-P

> You definitely should write some Haskell documentation. :-)

Heh, yeah.

Sadly, before you can document something, you must comprehend it. Also, 
the Haskell library documentation uses literate proramming - i.e., the 
documentation is inside the library source code, so to update it you'd 
have to submit a patch to the library maintainer, yadda yadda yackt...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:

> I still vividly remember the day I figured out why that famous formula 
> actually solves quadratic equations. Maybe I'll share it with you?

OK, so "everybody knows" (?!) that ax^2 + bx + c = 0 can be transformed 
into the magical expression

   x = (-b +/- Sqrt(b^2 - 4ac)) / 2a

But why is that, exactly? Well, looking in my sister's A-level maths 
book [unlike me, my sister was *taught* mathematics] I discover a long 
sequence of algebraic manipulations that slowly transforms the one into 
the other.

Well, that proves it *works*, but *why* does it work??

One day, I figured it out. Watch this:

The (linear) polynomial (x - A) has one solution: A. And the quadratic 
polynomial (x - A)(x - B) has two solutions: A and B. So here we just 
*constructed* a quadratic with *known* solutions!

(This may seem completely unremarkable, but remember I have no 
mathematical training. It seemed pretty impressive to me!)

Now, if we expand that out, we get

   x^2 - Ax - Bx + AB = 0

and with some rearranging,

   x^2 + (-A-B)x + (AB) = 0

If we match that up against

   x^2 + bx + c = 0

then we have

   b = -A-B
   c = AB

Or, put another way, -b = A+B. In other words, if we take

   ax^2 + bx + c = 0

and divide through a, we now know the sum and product of the solutions!

But how do we figure out the solutions themselves given only their sum 
and product?

Well, given that -b = A+B, there are an infinite number of possible 
solutions. Similarly, c = AB on its own has infinitely many solutions. 
Hopefully there is only two solutions to *both* equations. But what are 
they? Hmm.

The next revelation: Since -b = A+B, then -b/2 = (A+B)/2. In other 
words, the arithmetic mean of A and B. So -b/2 is a point exactly half 
way between the two solutions. If I can just figure out how far apart 
they are, I can compute them!

Clearly you can't determine the seperation from the sum. It's not 
obvious that you can determine it from the product either though. But 
that product must come into the equation somehow. Hmm.

Of course, I already know what the final solution is, just not why. That 
gave me a clue.

So what we have is A+B, but what we *want* is A-B. Well now, what 
happens if we square these?

   (A+B)^2 = A^2 + 2AB + B^2
   (A-B)^2 = A^2 - 2AB - B^2   (A mathematician would know this off by 
heart, but it took me a while to work out.)

Ooo, that's *interesting*... The difference between the two is only in 
the product in the middle! And we *have* that product!

 From here, it's just a matter of tying up loose ends. b^2 = (A+B)^2. 
The difference between sum^2 and difference^2 is exactly 4AB, so we have

   (A-B)^2 = (A+B)^2 - 4AB = b^2 - 4c

Since we want to add/subtract half the difference to half the sum, we have

   x = -b/2 +/- Sqrt(b^2 - 4c)/2
     = (-b +/- Sqrt(b^2 - 4c))/2

Ah, but we already eliminated "a", didn't we? Can we put that right back 
into the main formula? Well, comparing with the "standard" formula and 
shifting a little algebra, it becomes clear that we can.

   x = (-b +/- Sqrt(b^2 - 4ac))/2a

QED.

Bouyed up by this, I immediately set about performing the same trick for 
the cubic. Obviously, this did not end well.

However figured out that you can compute the difference from the sum and 
the product... GENIUS!! o_O I would never have known in a million years...

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Orchid XP v8 wrote:
> - As a sequence of mechanical transformations of symbols.

That's the "formal" mechanism I was talking about in the programming 
language thread.

> - As a vague but intuitive examination of *why* this (or at least 
> something roughly this shape) should work.

Yeah. Math tends to go for the "do all the gruntwork first, building bottom 
up to the final statement, and finish", usually without explaining why you 
would care about the final statement. :-)

> I still vividly remember the day I figured out why that famous formula 
> actually solves quadratic equations. Maybe I'll share it with you?

Sure.

>> I'm not a very mathematical person.
> 
> ...says the guy who actually knows WTF a nondeterministic Turing machine 
> *is*! :-P

That's pretty trivial mathematics compared to tensor calculus type stuff. 
:-)  I'm not too bad at discrete math.

> documentation is inside the library source code, so to update it you'd 
> have to submit a patch to the library maintainer, yadda yadda yackt...

Write it, patch it, suck out the docs, say "isn't this great? Here's the patch."

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Darren New <dne### [at] sanrrcom> wrote:

> That's pretty trivial mathematics compared to tensor calculus type stuff.
> :-)  I'm not too bad at discrete math.

Tensor calculus isn't so bad.  Among other things, I gave my nephew my tensor
calculus book this past summer for his baby shower.  Gotta get kids started
early these days, y'know.

 - Ricky

Post a reply to this message

>> That's pretty trivial mathematics compared to tensor calculus type stuff.
>> :-)  I'm not too bad at discrete math.
> 
> Tensor calculus isn't so bad.  Among other things, I gave my nephew my tensor
> calculus book this past summer for his baby shower.  Gotta get kids started
> early these days, y'know.

I still can't figure out what a "tensor" is. :-P

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

On 18-Jan-09 22:49, Orchid XP v8 wrote:
>>> That's pretty trivial mathematics compared to tensor calculus type 
>>> stuff.
>>> :-)  I'm not too bad at discrete math.
>>
>> Tensor calculus isn't so bad.  Among other things, I gave my nephew my 
>> tensor
>> calculus book this past summer for his baby shower.  Gotta get kids 
>> started
>> early these days, y'know.
> 
> I still can't figure out what a "tensor" is. :-P
> 
multidimensional vector.

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> I still can't figure out what a "tensor" is. :-P

scalar = tensor of rank 0
vector = tensor of rank 1

For example, the stress tensor is a rank 2 tensor since you quantify stress in a
plane and thus need two indices to describe which plane you're talking about.
So the (1,3) element if you wrote it as a matrix would correspond to stress in
the x-z plane.  This makes for 9 elements total.  Now if we're talking
relativity and such, it gets a little more complex.  But I guess you already
looked it up on Wikipedia, so I don't know what I'm rambling on about.

 - Ricky

Post a reply to this message

Orchid XP v8 <voi### [at] devnull> wrote:
> >> That's pretty trivial mathematics compared to tensor calculus type stuff.
> >> :-)  I'm not too bad at discrete math.
> >
> > Tensor calculus isn't so bad.  Among other things, I gave my nephew my tensor
> > calculus book this past summer for his baby shower.  Gotta get kids started
> > early these days, y'know.
>
> I still can't figure out what a "tensor" is. :-P
>
> --
> http://blog.orphi.me.uk/
> http://www.zazzle.com/MathematicalOrchid*

meh, from the title thought you were talking about Final Fantasy Tactics and
perhaps some sequel... :)

Post a reply to this message

Orchid XP v8 wrote:
> However figured out that you can compute the difference from the sum and 
> the product... GENIUS!! o_O I would never have known in a million years...

Very cool. :-)

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

> OK, so "everybody knows" (?!) that ax^2 + bx + c = 0 can be transformed 
> into the magical expression
>
>   x = (-b +/- Sqrt(b^2 - 4ac)) / 2a
>
> But why is that, exactly? Well, looking in my sister's A-level maths book 
> [unlike me, my sister was *taught* mathematics] I discover a long sequence 
> of algebraic manipulations that slowly transforms the one into the other.

It's not that hard or long, just involves dividing by a, completing the 
square for the first two terms, rearranging, taking the square root, and 
rearranging again for x.

But I imagine the cubic is a lot harder.

Post a reply to this message

>> But why is that, exactly? Well, looking in my sister's A-level maths 
>> book [unlike me, my sister was *taught* mathematics] I discover a long 
>> sequence of algebraic manipulations that slowly transforms the one 
>> into the other.
> 
> It's not that hard or long, just involves dividing by a, completing the 
> square for the first two terms, rearranging, taking the square root, and 
> rearranging again for x.

Yeah. As I said, a sequence of algebraic operations which "just happen" 
to lead to the answer we seek. (As in, there's no *apparent* reason why 
this particular sequence of operations does it, as opposed to some other.)

I also note in passing that I have no clue what "completing the square" 
actually means. But then, I have no formal mathematical education at 
all, so it's a miracle I even comprehend algebra in the first place!

> But I imagine the cubic is a lot harder.

http://planetmath.org/?op=getobj&from=objects&id=1407

Does it make your eyes bleed?

Post a reply to this message

Invisible wrote:

> http://planetmath.org/?op=getobj&from=objects&id=1407
> 
> Does it make your eyes bleed?

Actually... if you gather up some of those subexpressions and represent 
them as single letters, it's not that complicated.

Post a reply to this message

Invisible wrote:
> Invisible wrote:
> 
>> http://planetmath.org/?op=getobj&from=objects&id=1407
>>
>> Does it make your eyes bleed?
> 
> Actually... if you gather up some of those subexpressions and represent 
> them as single letters, it's not that complicated.

Unless my eyes deceive me, this is equivilent:

J = 2a^3 - 9ab + 26c
K = Sqrt(J^2 + 4(-a^2 + 3b)^3)
M = (1 + i Sqrt(3))/2
N = (-1 + i Sqrt(3))/2

r1 = -(a/3) +   Cbrt((-J + K)/54) +   Cbrt((-J - K)/54)
r2 = -(a/3) + M Cbrt((-J + K)/54) + N Cbrt((-J - K)/54)
r3 = -(a/3) + N Cbrt((-J + K)/54) + M Cbrt((-J - K)/54)

While hardly on the same level as the quadratic, it's not "that" hard.

Post a reply to this message

> Yeah. As I said, a sequence of algebraic operations which "just happen" to 
> lead to the answer we seek. (As in, there's no *apparent* reason why this 
> particular sequence of operations does it, as opposed to some other.)

Maybe if you've never done any equation solving before, but the steps are 
pretty obvious steps to take to rearrange an equation like that (ie to get 
all the x's in one place).

> I also note in passing that I have no clue what "completing the square" 
> actually means.

It's the key step to rearranging the quadratic equation in terms of x, and 
useful in lots of other areas too.  It's the process of rewriting terms like 
x^2+cx in the form (x+a)^2 + b.  It's not hard, and after performing a 
square root allows you to get the x by itself.

Post a reply to this message

> Unless my eyes deceive me, this is equivilent:
> 
> J = 2a^3 - 9ab + 26c
> K = Sqrt(J^2 + 4(-a^2 + 3b)^3)
> M = (1 + i Sqrt(3))/2
> N = (-1 + i Sqrt(3))/2
> 
> r1 = -(a/3) +   Cbrt((-J + K)/54) +   Cbrt((-J - K)/54)
> r2 = -(a/3) + M Cbrt((-J + K)/54) + N Cbrt((-J - K)/54)
> r3 = -(a/3) + N Cbrt((-J + K)/54) + M Cbrt((-J - K)/54)
> 
> While hardly on the same level as the quadratic, it's not "that" hard.

Did you try to derive those equations from ax^3+bx^2+cx+d=0 ?? :-)

Post a reply to this message

scott wrote:
>> Unless my eyes deceive me, this is equivilent:
>>
>> J = 2a^3 - 9ab + 26c
>> K = Sqrt(J^2 + 4(-a^2 + 3b)^3)
>> M = (1 + i Sqrt(3))/2
>> N = (-1 + i Sqrt(3))/2
>>
>> r1 = -(a/3) +   Cbrt((-J + K)/54) +   Cbrt((-J - K)/54)
>> r2 = -(a/3) + M Cbrt((-J + K)/54) + N Cbrt((-J - K)/54)
>> r3 = -(a/3) + N Cbrt((-J + K)/54) + M Cbrt((-J - K)/54)
>>
>> While hardly on the same level as the quadratic, it's not "that" hard.
> 
> Did you try to derive those equations from ax^3+bx^2+cx+d=0 ?? :-)

No - because it solves the *monic* equation x^3 + ax^2 + bx + c = 0. :-P 
(Notice the absence of a "d" in any of the equations above.)

I'm surprised nobody has yet pointed out that it's "+ 27c" and not "+ 26c".

Post a reply to this message

triple_r wrote:
> Orchid XP v8 <voi### [at] devnull> wrote:
>> I still can't figure out what a "tensor" is. :-P
> 
> scalar = tensor of rank 0
> vector = tensor of rank 1

So... a rank-0 tensor is just a number, a rank-1 tensor is a 1D grid of 
numbers, a rank-2 tensor is a 2D grid of numbers, and a rank-3 tensor 
is... what? A 3D grid of numbers?

I guess that's simple enough. How how do you do arithmetic with them? ;-)

Post a reply to this message

Orchid XP v8 wrote:

> Recall that the convolution of a signal by some kernel is *longer* than 
> the original signal. This is the effect you have to repeat when doing 
> FFT convolution. (The details escape me at this exact moment... Suffice 
> it to say that your inverse-FFT results have to be overlapped to get a 
> smooth result.)
> 

Looking at dspguide.com (The first site that actually got me to make a 
bit of sense out of FFT in the first place) it seems the overlap is 
quite simple. What to overlap seems to be the length of the filter 
kernel... But, how do you determine that if, say ... you present the 
user with an interface that allows them to create a graph of which 
frequencies to pass...?

I suppose this is where you'd want to use a Blackmann window to clean up 
the edges of the kernel before applying it to the input data.


-- 
~Mike

Post a reply to this message

Mike Raiford wrote:

> Looking at dspguide.com (The first site that actually got me to make a 
> bit of sense out of FFT in the first place) it seems the overlap is 
> quite simple.

dspguide.com is the resource I used - and yet, it's really very good, 
IMHO. The stuff about IIR filter design is quite fun. ;-)

> What to overlap seems to be the length of the filter 
> kernel... But, how do you determine that if, say ... you present the 
> user with an interface that allows them to create a graph of which 
> frequencies to pass...?

If you have an N-point filter kernel, you can take X samples of input, 
add on N-1 zeros at the end, FFT, multiply, inverse-FFT, overlap by N-1 
samples with the previous window. This should produce the same results 
as doing a normal convolution.

Using a larger N gives you more precise control over the frequency 
response (because there are more points in it).

> I suppose this is where you'd want to use a Blackmann window to clean up 
> the edges of the kernel before applying it to the input data.

You know how if you JPEG-compress something too much, you get ghosting? 
Well if you aren't careful with your filter kernel, your frequency 
response ends up with ghosting. The Blackmann window is a way to try to 
get rid of that. (By blurring the whole thing, unfortunately.)

Post a reply to this message

Invisible wrote:
> So... a rank-0 tensor is just a number, a rank-1 tensor is a 1D grid of 
> numbers, a rank-2 tensor is a 2D grid of numbers, and a rank-3 tensor 
> is... what? A 3D grid of numbers?
> 
> I guess that's simple enough. How how do you do arithmetic with them? ;-)

I think they actually have to be vectors, don't they? Not just pairs of numbers?

-- 
   Darren New, San Diego CA, USA (PST)
   Why is there a chainsaw in DOOM?
   There aren't any trees on Mars.

Post a reply to this message

Invisible wrote:

> You know how if you JPEG-compress something too much, you get ghosting? 
> Well if you aren't careful with your filter kernel, your frequency 
> response ends up with ghosting. The Blackmann window is a way to try to 
> get rid of that. (By blurring the whole thing, unfortunately.)

According to the book, my thinking was sound. You take an iFFT of the 
arbitrary filter, apply a Hamming or Blackmann window to the shifted and 
zero-padded filter kernel. Then you execute the filter by convolution, 
or FFT convolution. Depending on the size of the filter kernel you've 
generated. Bigger means FFT is more advantageous.

That's for FIR filters.

Now I'm reading a bout IIR filters and ... they're simple to code, but a 
bear to design..

-- 
~Mike

Post a reply to this message

Mike Raiford wrote:

> Now I'm reading a bout IIR filters and ... they're simple to code, but a 
> bear to design..

Exactly. But great for simulating old analogue subtractive synthesizers. ;-)

-- 
http://blog.orphi.me.uk/
http://www.zazzle.com/MathematicalOrchid*

Post a reply to this message

Mike Raiford wrote:

> According to the book, my thinking was sound. You take an iFFT of the 
> arbitrary filter, apply a Hamming or Blackmann window to the shifted and 
> zero-padded filter kernel. Then you execute the filter by convolution, 
> or FFT convolution. Depending on the size of the filter kernel you've 
> generated. Bigger means FFT is more advantageous.
> 
> That's for FIR filters.

Not quite...

Let's say you want to build a band-pass filter. It passes 100 Hz 
unchanged, but it filters out everything else. A "perfect" version of 
this filter is very simple - and very impossible. Its impulse response 
would simply by a 100 Hz sinewave extending an infinite distance into 
the past and into the future.

It should be completely obvious that no filter real-world filter can 
possibly react to inputs that haven't happened yet - but that is what 
this design calls for. (It is a "non-causal filter".)

Anyway, if you build an FIR by simply taking that infinite sinewave and 
chopping the ends off to make it finite, you've just truncated the 
impulse response. And that distorts the frequency response. The longer 
the IR is, the less the distortion - and the more arithmetic your 
digital filter is going to have to do when you run it.

If, instead of just chopping the ends off, you use a Blackmann window... 
Well, you're multiplying the IR by the window. Multiplication in the 
time domain is convolution in the frequency domain. The frequency 
spectrum of a Blackmann window is such that this convolution is 
essentially a blurring operation. It blurs out the small ripples, 
without destroying the peak at 100 Hz which we'd like to keep. (It does 
widen it slightly though.)

Anyway, coming back to general filter design...

- You figure out what frequency response you want, and how many points 
you've going to use. (Note that before and after the inverse-FFT, the 
number of "points" remains the same.)

- Obviously more points give you more control over the frequency 
response; you've got more control points to move. It also means less 
rippling between the centers of those control points.

- Take your desired frequency response. Take the inverse-FFT. Now 
multiply that by your chosen windowing function.

- You now have your filter kernel.

Notice there's no zero-padding here. (I think you're possibly confused 
by the guide's suggestion that you can zero-pad the IR before taking an 
FFT in order to get better frequency resolution so you can see what your 
filter's "real" frequency response is - this does not exactly match what 
you originally requested because the IR is finite.)

Anyway, you can now "run" the filter in two ways: Take the convolution 
of the kernel and your signal, or do an FFT-convolution.

To do an FFT-convolution, you want the filter's frequency response (not 
its impulse response). Chop your input signal into blocks, zero-pad each 
block, FFT, multiply, inverse-FFT, overlap consecutive blocks to build 
an output signal. You're done.

(It strikes me that if you were trying to do this "real time", the 
blocking would necessarily add some latency to the system that a 
convolution implementation wouldn't have...)

Post a reply to this message

Invisible wrote:
> Mike Raiford wrote:
> 
>> According to the book, my thinking was sound. You take an iFFT of the 
>> arbitrary filter, apply a Hamming or Blackmann window to the shifted 
>> and zero-padded filter kernel. Then you execute the filter by 
>> convolution, or FFT convolution. Depending on the size of the filter 
>> kernel you've generated. Bigger means FFT is more advantageous.
>>
>> That's for FIR filters.
> 
> Not quite...
> 
> Let's say you want to build a band-pass filter. It passes 100 Hz 
> unchanged, but it filters out everything else. A "perfect" version of 
> this filter is very simple - and very impossible. Its impulse response 
> would simply by a 100 Hz sinewave extending an infinite distance into 
> the past and into the future.

Right, no way that could ever work.

> It should be completely obvious that no filter real-world filter can 
> possibly react to inputs that haven't happened yet - but that is what 
> this design calls for. (It is a "non-causal filter".)
> 
> Anyway, if you build an FIR by simply taking that infinite sinewave and 
> chopping the ends off to make it finite, you've just truncated the 
> impulse response. And that distorts the frequency response. The longer 
> the IR is, the less the distortion - and the more arithmetic your 
> digital filter is going to have to do when you run it.
> 
> If, instead of just chopping the ends off, you use a Blackmann window... 
> Well, you're multiplying the IR by the window. Multiplication in the 
> time domain is convolution in the frequency domain. The frequency 
> spectrum of a Blackmann window is such that this convolution is 
> essentially a blurring operation. It blurs out the small ripples, 
> without destroying the peak at 100 Hz which we'd like to keep. (It does 
> widen it slightly though.)
> 

Right... once you've chosen the frequencies to pass, you can then obtain 
the impulse response by an iFFT, and applying the window. Depending on 
the number of points the filter's frequency response will be an 
approximation of the desired frequency response.

> Anyway, coming back to general filter design...
> 
> - You figure out what frequency response you want, and how many points 
> you've going to use. (Note that before and after the inverse-FFT, the 
> number of "points" remains the same.)
> 
> - Obviously more points give you more control over the frequency 
> response; you've got more control points to move. It also means less 
> rippling between the centers of those control points.
> 
> - Take your desired frequency response. Take the inverse-FFT. Now 
> multiply that by your chosen windowing function.
> 
> - You now have your filter kernel.
> 
> Notice there's no zero-padding here. (I think you're possibly confused 
> by the guide's suggestion that you can zero-pad the IR before taking an 
> FFT in order to get better frequency resolution so you can see what your 
> filter's "real" frequency response is - this does not exactly match what 
> you originally requested because the IR is finite.)

You'd want to zero pad the kernel for FFT convolution though, right?

> Anyway, you can now "run" the filter in two ways: Take the convolution 
> of the kernel and your signal, or do an FFT-convolution.
> 
> To do an FFT-convolution, you want the filter's frequency response (not 
> its impulse response). Chop your input signal into blocks, zero-pad each 
> block, FFT, multiply, inverse-FFT, overlap consecutive blocks to build 
> an output signal. You're done.
> 
> (It strikes me that if you were trying to do this "real time", the 
> blocking would necessarily add some latency to the system that a 
> convolution implementation wouldn't have...)

Yeah, there would be a bit of latency I would expect.

FWIW, a long time ago I fooled around with an emulation project for the 
MT-32 sound module, which has a resonant low-pass filter.  With a few 
multiplies and a few adds per cycle, it would filter in realtime pretty 
easily. I didn't understand the theory behind it, but the code looked 
deceptively simple... Until I found the code for calculating the 
coefficients. I found the same filter code on Gamedev.net. From the 
looks of it, it's simply a 6-pole Chebyshev filter. The coefficients 
were generated by what appeared to be the z-transform you were 
discussing earlier. The resonance parameter is apparently is how much 
ripple was allowed in the passband. More ripple = bigger spike at the 
cut-off frequency.

Other interesting things about the module itself: It's essentially 
subtractive synthesis combined with PCM samples. Each patch could 
contain up to 4 partials: 2 pairs. Each pair had a ring modulator. If 
one side of the modulator was unconnected (no partial) it would simply 
generate white noise. IIRC, it had a few different waveforms, including 
the PCM "waveform."

-- 
~Mike

Post a reply to this message

>> Let's say you want to build a band-pass filter. It passes 100 Hz 
>> unchanged, but it filters out everything else. A "perfect" version of 
>> this filter is very simple - and very impossible. Its impulse response 
>> would simply by a 100 Hz sinewave extending an infinite distance into 
>> the past and into the future.
> 
> Right, no way that could ever work.

Indeed.

(Although you *can* apply that kind of thing in the weird world of 
mathematics. If you have a mathematical formula that describes your 
entire signal - past, present and future - then you really *can* pass it 
through a "perfect" filter like this. That's the magic of integral 
calculus. But I digress...)

> Right... once you've chosen the frequencies to pass, you can then obtain 
> the impulse response by an iFFT, and applying the window.

Yes.

> Depending on 
> the number of points the filter's frequency response will be an 
> approximation of the desired frequency response.

Yes.

In general, if you ask for the frequency response that changes smoothly, 
you'll get a close approximation. If you ask for a frequency response 
with sharp discontinuities in it, you'll get ripples. (The inverse-DFT 
is almost identical to the forward-DFT, remember.)

A lowpass filter consists of a straight line from 0 Hz to the cutoff 
frequency, a sharp discontinuity from 100% to 0%, and then a straight 
line from there onwards. Hence the impossibility of implementing it 
"perfectly". Most other "standard" filter types have abrupt changes like 
this too.

>> Notice there's no zero-padding here. (I think you're possibly confused 
>> by the guide's suggestion that you can zero-pad the IR before taking 
>> an FFT in order to get better frequency resolution so you can see what 
>> your filter's "real" frequency response is - this does not exactly 
>> match what you originally requested because the IR is finite.)
> 
> You'd want to zero pad the kernel for FFT convolution though, right?

Checking the documentation carefully, it appears that the procedure is thus:

   To FFT-convolve a kernel containing X samples with a signal block 
containing Y samples, pad *both* the kernel and the signal block to 
X+Y-1 samples long, FFT to the frequency domain, multiply, inverse-FFT 
back to the time domain again. Your new output signal block is larger 
than the block you started with, so overlap it with its siblings.

So yes, you do pad the kernel as well as the input signal blocks. (The 
amount of padding depends on the size of block you chop the signal 
into.) I hypothesize that small blocks = FFT isn't much faster, large 
blocks = you have to do lots of multiplies, so there's some sweet spot 
somewhere in the middle for best performance.

>> (It strikes me that if you were trying to do this "real time", the 
>> blocking would necessarily add some latency to the system that a 
>> convolution implementation wouldn't have...)
> 
> Yeah, there would be a bit of latency I would expect.

...whereas if you just do a 500-point convolution, there will be 500 
samples woth of latency. No more, no less.

> FWIW, a long time ago I fooled around with an emulation project for the 
> MT-32 sound module, which has a resonant low-pass filter.  With a few 
> multiplies and a few adds per cycle, it would filter in realtime pretty 
> easily.

That's the magic of IIR. It's *very* compute-efficient.

> I didn't understand the theory behind it, but the code looked 
> deceptively simple... Until I found the code for calculating the 
> coefficients.

Uh, yes. ;-)

> I found the same filter code on Gamedev.net. From the 
> looks of it, it's simply a 6-pole Chebyshev filter. The coefficients 
> were generated by what appeared to be the z-transform you were 
> discussing earlier.

Precisely.

The math isn't actually "hard" - again it's a few trig functions and a 
couple of multiplies - it's just very "fiddly" to implement correctly. 
There are lots of opportunities to screw it up.

> The resonance parameter is apparently is how much 
> ripple was allowed in the passband. More ripple = bigger spike at the 
> cut-off frequency.

Indeed.

Actually - when you get that far - these IIR filters are designed by 
looking at the complex plane. You position "poles" and "zeros", and 
these define a surface. The vertical slice going through the origin is 
the frequency response of the filter. So it's like having a giant 
elastic sheet, and moving these poles and zeros around to bend the part 
of the sheet crossing that line into the shape you want.

A Chebyshev low-pass filter arranges poles in a semicircle. The 
resonance comes from deforming this circle to make it elliptical. As you 
do so, the poles get nearer to the line, and the "ripples" you see are 
actually the edges of the peak surrounding each pole. I'll draw you a 
graph if you like... ;-)

The other fun thing is, the mathematical analysis may show you that an 
IIR filter will do one thing, but when you actually implement it 
something totally different happens due to rounding errors! IIR filters 
work using feedback, and feedback magnifies rounding errors. (FIR 
filters by contrast are pretty much unaffected by them, because there's 
no feedback.)

> Other interesting things about the module itself: It's essentially 
> subtractive synthesis combined with PCM samples. Each patch could 
> contain up to 4 partials: 2 pairs. Each pair had a ring modulator. If 
> one side of the modulator was unconnected (no partial) it would simply 
> generate white noise. IIRC, it had a few different waveforms, including 
> the PCM "waveform."

Sounds pretty interesting.

Personally I'd love to implement something like that myself - but I 
don't have access to anything that can talk to the sound hardware. :-(

(Haskell has a binding for libSDL - but it doesn't work on Windoze.)

Post a reply to this message

Invisible wrote:
> 
> Sounds pretty interesting.
> 
> Personally I'd love to implement something like that myself - but I 
> don't have access to anything that can talk to the sound hardware. :-(
> 
> (Haskell has a binding for libSDL - but it doesn't work on Windoze.)

I know this is probably painful, but ... under the windows platform does 
Haskell have access to COM libraries? DirectX uses COM, you may be able 
to use DirectSound (or is it DirectShow, now?) via its COM interfaces..

Either than or write a simple C Dll, and import the functions from that 
DLL into the Haskell application.

You'll of course need to download the DirectX SDK for that to work.

-- 
~Mike

Post a reply to this message

Mike Raiford wrote:

>> (Haskell has a binding for libSDL - but it doesn't work on Windoze.)
> 
> I know this is probably painful, but ... under the windows platform does 
> Haskell have access to COM libraries?

It has access to most of the Win32 API. If I can figure out what calls 
to execute, it should be doable.

> DirectX uses COM, you may be able 
> to use DirectSound (or is it DirectShow, now?) via its COM interfaces..

Seems plausible.

> Either than or write a simple C Dll, and import the functions from that 
> DLL into the Haskell application.

Heh. As if I could *ever* do that... I don't even know how DLLs work!

> You'll of course need to download the DirectX SDK for that to work.

That's the easy part. ;-)

Post a reply to this message

> Personally I'd love to implement something like that myself - but I don't 
> have access to anything that can talk to the sound hardware. :-(

You could always just output a raw .wav file and then send it somewhere to 
play it (eg mediaplayer or winamp, surely also a smaller command line player 
somewhere out there).

Post a reply to this message

Invisible wrote:

> 
> Heh. As if I could *ever* do that... I don't even know how DLLs work!
> 

Oh, now. DLLs aren't big scary things. They're just libraries. Creating 
a DLL project in Visual C is a snap. Then you just create the functions 
you want to export using the extern "C" __declspec( dllexport ) 
decoration on the function.

>> You'll of course need to download the DirectX SDK for that to work.
> 
> That's the easy part. ;-)

Depends ... ;) if you're impatient like me it's excruciating.
-- 
~Mike

Post a reply to this message

>> I know this is probably painful, but ... under the windows platform does 
>> Haskell have access to COM libraries?
>
> It has access to most of the Win32 API. If I can figure out what calls to 
> execute, it should be doable.

http://msdn.microsoft.com/en-us/library/ms712879.aspx

You could first start off by checking that it plays a pre-existing WAV file, 
then write the WAV file and play it immediately afterwards, then try out the 
SND_MEMORY flag to play it directly from memory...

Post a reply to this message

scott wrote:
>> Personally I'd love to implement something like that myself - but I 
>> don't have access to anything that can talk to the sound hardware. :-(
> 
> You could always just output a raw .wav file and then send it somewhere 
> to play it (eg mediaplayer or winamp, surely also a smaller command line 
> player somewhere out there).

Have you seen the format spec for the .WAV file format??

It's actually RIFF - a multilation of the Amiga IFF format with all the 
4-byte values incorrectly written backwards. (Hence "R" for "reverse".)

You can't just say "hey, here's some data". You have to include a header 
that describes - in the most retarded way imaginable - exactly what the 
layout of the payload is. (E.g., mono or stereo, 8-bit or 16-bit, signed 
or unsigned, etc.)

It's no mean feat to set all this up...



What I guess I *could* do is write a small Java application that accepts 
raw audio data over TCP and then writes it to the sound hardware. 
(Although talking to the sound hardware in Java isn't exactly easy 
either - it's a 12-step process of getting a factory factory factory 
that possibly yields a factory factory that can then be queried for the 
kinds of factories it knows how to produce... you get the picture.)

Post a reply to this message

Invisible <voi### [at] devnull> wrote:
> It's actually RIFF - a multilation of the Amiga IFF format with all the 
> 4-byte values incorrectly written backwards. (Hence "R" for "reverse".)

  I think the R stands for Resource.

-- 
                                                          - Warp

Post a reply to this message

Invisible wrote:
> scott wrote:
>>> Personally I'd love to implement something like that myself - but I 
>>> don't have access to anything that can talk to the sound hardware. :-(
>>
>> You could always just output a raw .wav file and then send it 
>> somewhere to play it (eg mediaplayer or winamp, surely also a smaller 
>> command line player somewhere out there).
> 
> Have you seen the format spec for the .WAV file format??
> 
> It's actually RIFF - a multilation of the Amiga IFF format with all the 
> 4-byte values incorrectly written backwards. (Hence "R" for "reverse".)
> 
> You can't just say "hey, here's some data". You have to include a header 
> that describes - in the most retarded way imaginable - exactly what the 
> layout of the payload is. (E.g., mono or stereo, 8-bit or 16-bit, signed 
> or unsigned, etc.)
> 
> It's no mean feat to set all this up...
> 
> 
> 
> What I guess I *could* do is write a small Java application that accepts 
> raw audio data over TCP and then writes it to the sound hardware. 
> (Although talking to the sound hardware in Java isn't exactly easy 
> either - it's a 12-step process of getting a factory factory factory 
> that possibly yields a factory factory that can then be queried for the 
> kinds of factories it knows how to produce... you get the picture.)

IIRC the data in the wav file isn't too, too bad to format correctly, 
but the header needs to be right.

I remember a conversation with a friend while I was screwing around with 
linux.

I can't remember the exact syntax .. but something like this.

cat mysound.wav | /dev/snd

"You can't cat a wav file!"

"Yeah, I can. Watch"

I hit enter and ... after a short burst of static, it plays the file, 
albeit at the wrong sampling rate.

"Huh, I didn't know you could do that ..."



-- 
~Mike

Post a reply to this message

> Have you seen the format spec for the .WAV file format??

You mean this:

http://ccrma.stanford.edu/courses/422/projects/WaveFormat/

Looks very simple to me, about the same level of difficulty as writing a 
windows bmp file, ie very easy.

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> cat mysound.wav | /dev/snd

> "You can't cat a wav file!"

  The amount of things wrong in everything of the above is mind-boggling. ;)

  (For one, you are trying to run /dev/snd as if it was a program. Of course
that's not the only problem.)

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
>> cat mysound.wav | /dev/snd
> 
>> "You can't cat a wav file!"
> 
>   The amount of things wrong in everything of the above is mind-boggling. ;)
> 
>   (For one, you are trying to run /dev/snd as if it was a program. Of course
> that's not the only problem.)
> 

Hmm, does Linux use the same format as DOS for redirection? e.g. it 
should be > /dev/snd (or whatever)

I know what I did was truly ugly, but it worked, that's what was funny.

But, I can't remember the syntax (It's been years since I've really used 
  linux from a command line.)

-- 
~Mike

Post a reply to this message

Mike Raiford <"m[raiford]!at"@gmail.com> wrote:
> Hmm, does Linux use the same format as DOS for redirection? e.g. it 
> should be > /dev/snd (or whatever)

  | is a pipe: The standard output of the program on the left side is
redirected to the standard input of the program on the right side.
However, /dev/snd is not a program and cannot be run.

  If you want to redirect the standard output of a program to a file
(or, in this case, a device), > is the operator for it.

-- 
                                                          - Warp

Post a reply to this message

Warp wrote:
> Invisible <voi### [at] devnull> wrote:
>> It's actually RIFF - a multilation of the Amiga IFF format with all the 
>> 4-byte values incorrectly written backwards. (Hence "R" for "reverse".)
> 
>   I think the R stands for Resource.

That's what Microsoft wants you to think. Originally it was "reverse", until 
they realized how few people were familiar with the Amiga formats or something.

It's *exactly* IFF, with the endianness reversed. :-)

Altho it does annoy me when I see it mentioned in the press how "RIFF is an 
extensible format created by Microsoft...."

I do like how PNG took it a step farther and encoded into the chunk names 
whether you need to understand the chunk to parse the file, etc.

-- 
   Darren New, San Diego CA, USA (PST)
   "Ouch ouch ouch!"
   "What's wrong? Noodles too hot?"
   "No, I have Chopstick Tunnel Syndrome."

Post a reply to this message

Mike Raiford wrote:

> cat mysound.wav | /dev/snd
> 
> "You can't cat a wav file!"
> 
> "Yeah, I can. Watch"
> 
> I hit enter and ... after a short burst of static, it plays the file, 
> albeit at the wrong sampling rate.
> 
> "Huh, I didn't know you could do that ..."

Now try doing that with a sound that's been LZW-compressed. ;-)

Doesn't sound very nice...

Post a reply to this message

Invisible wrote:

> 
> Now try doing that with a sound that's been LZW-compressed. ;-)
> 
> Doesn't sound very nice...

I imagine it's about as pleasing as loading an MP3 as a raw PCM audio 
file and playing it. For some reason this one audio app I have 
recognizes every MP3 correctly, except for a handful of files from one 
particular album. Weird.

-- 
~Mike

Post a reply to this message