Rebol [
]
audio: read/binary %/j/audio/first.au
forskip audio 2 [
write/append/binary %/j/audio/firstdone.au to-char audio/1
]
Did somebody want the slowest audio program ever written?
Why not open the file once instead of for every byte?
Basically it looks as though you are keeping every other byte,
are you picking out just one track to go from stereo to mono?
I haven't tested it, but something like this ought to be a little faster.
================
Rebol []
audio: read/binary %/j/audio/first.au
newstuff: copy []
while not tail? audio [
append newstuff first audio
audio: skip audio 2
]
write/append/binary %/j/audio/firstdone.au newstuff
================
Does everyone like the word 'first ? It seems less than intuitive.
First what? It's not really the first element in the list.
I know we can create our own words to alias 'first, but most
people won't do that and it makes it harder for others to read, too.
Also, having to say stuff like
list: next list
is too bad.
Wouldn't it be nicer to have a syntax like
list/next
list/value
? That seems kind of nice.
list/value would return the same as "first list", and
list/next would be the same as "list: next list".
And speaking of understanding grammars,
You're = You are. E.g. You are what you are. You're my little bundle of
joy.
Your = possessive, e.g. It's your life!
Try this one: You're your own best friend.
And if you can't remember which is which, just go phonetic: Yor.
At least that way people will not assume anything other than the sound.
- - -
Mu-law is pretty cool, and is used in many .au files.
I just found out about it the other day.
Some call it companding, like compression+expansion, but that's bull.
It's really just using a non-linear representation of the amplitude of the
sound wave, which is way cool, because that's the way all your
natural senses work anyways.
Because it uses a logarithm of the
amplitude, you can multiply easily just by adding (think mixing level)!
But adding itself (mixing two or more channels into final output) is made more
complex.
Also, I think some internet phone systems use Mu-law type companding,
as it adds more dynamic resolution and just sounds better without requiring
more actual bits. You are not compressing any actual information, though.
It's not lossy. You are however making better use of the bits so that what
the bits represent is a better match in value to your sense of hearing, e.g.
you can distinguish soft from very soft easily, but loud and very loud sound
pretty much the same. Vision works in a similar fashion with brightness
levels.
You can see in near darkness but blinding light and twice-blinding light mean
nothing to you.
Most cameras that people buy don't perform well in low-light conditions.
You see the film coming back from the lab either black or all washed out
at light levels your eyes handle easily. Sure, you can see a distant nebula
with long-exposure film in a gigantic telescope, but try taking that on
vacation.
- - -
By the way, how many lines of c code does it take to do this?:
read http://www.rebol.com
And does that code run on 37 platforms without recompiling anything?
To me, the fact that I can't count an integer from 1 to 1000000 in an empty loop
is of no interest. Plus the hardware coming out these days is amazing.
650 Mhz Wintel box is cheap. Fry's has 13GB drives for $89 each.
What I want to know is what are you going to do with that hardware?
If you have rebol, you might be able to deliver a great program before you
are eligible for social security.
In fact, you could write a rebol program that
would assemble a binary executable for you if you really want to count
at the speed of the hardware. Has anybody written any assemblers
entirely in Rebol? It would probably turn out to be incredibly short, easy
to read (and write!) code.
Oh, and Rebol is certainly available at an attractive price.
