geekmaster's sound demo thread

[twobob]

Originally Posted by geekmaster

Of course, 8-bit audio needs an audio compander algorithm (dynamic range compression) to avoid severe distortion on low volume audio passages or clipping (fuzz box) on high volume audio sound effects.

1 bit Gaussian noise shaping appears to do a reasonable job.

This result could be EASILY improved upon in a whole host of ways - not least a bit of noise gating, in fact about ten minutes picking some defaults during the conversion creation process could probably cater for the conversion of 99% of files in a near-excellent way.

Which is rare in computing, lol.

: ) Ill attach my squashed audio and I'll up the video somewhere so you can have a play syncing a decently big file. it's a completely Public Domain movie as are the other ones I have been playing with.

The file I have attached has a constant sizzle, the original soundtrack was HORRIFIC quality, which is what attracted me to it (of course). I'll play with tidying it up and post another to show what I mean (of course I already did noise shaping just to make it a bit harder for me to show a real difference, bah)

I might add that I'll be doing this with unix tools and basic filter settings. given access to my studio I could make this shitty recording sound like a dolby master. Just saying.

But that's not the goal here, just getting some decent - thumb in the air - settings / algorithms is a big step forward toward simpler compliance for terrible recordings.

[geekmaster]

Originally Posted by twobob

Yep, It's just nice to be able to pick up someone - who clearly knows more than you- 's code and be able to illicit some substance from it via some notes.

(Especially of the opposite sex, at a dance club).

Sorry, we are fresh out of "illicit substances" here (that is my story, and I am sticking to it).

But you can "elicit substance" from my code too, which is not a crime if that gets you "high".

[geekmaster]

Originally Posted by twobob

1 bit Gaussian noise shaping appears to do a reasonable job.

My "customized" google results show lots of hits, but no simple C code. Any links to some nice simple noise shaping code out there?

[geekmaster]

I added this to the Top Post "Theory of Operation" section:

The sample rate is 8000 samples per second, which means that if you call one play of the 1024-byte sound buffer a "beat", then this program plays 256 beats of almost 8 beats per second. Each beat plays at a different sound volume, creating the "semi-percussive" sound. Changing the "350" multiplier changes both the depth of distortion and the perceived repetition rate of the slowly varying distortion pattern. This perceived repetition is an audio interference pattern similar in nature to the visual interference (moire) patterns in some of my eink animation demos.

[twobob]

Originally Posted by geekmaster

My "customized" google results show lots of hits, but no simple C code. Any links to some nice simple noise shaping code out there?

RMS Estimation and signal balancing, allpass filter, comb filter, 1st order low and hi pass, bandpass
I have c for them.

http://www.anirudh.net/courses/cse58...ilters.cc.html offers an insight into the gaussian approach but you'll have to port it slightly as I think it's n dimensional.

I have some tidy 5 line curve coefficients... etc.

Let me grab a high pass code e.g.

[twobob]

Originally Posted by geekmaster

I added this to the Top Post "Theory of Operation" section:

Perfect. That's exactly the kind of thing I meant superstar

[twobob]

Originally Posted by geekmaster

Of course, 8-bit audio needs an audio compander algorithm (dynamic range compression) to avoid severe distortion on low volume audio passages or clipping (fuzz box) on high volume audio sound effects.

I have a few examples that I will forward to you.

[geekmaster]

Instead of Dynamic Range Compression, the cellphone codecs use A-law or mu-law logarithmic range compression (non-binary weighting of the 8 bits). This effectively packs the bottom bits close together and spreads the top bits far apart, allowing a useful number of bits for both quiet sounds and for loud sounds, even though there are only 8-bits in total. This takes advantage of human logarithmic sensory perception, and works a lot like gamma correction as used in digitial photography (except for sound in this case).

Of course, it may be even better to use both dynamic range compression AND logarithmic coding.

[twobob]

Originally Posted by geekmaster

Instead of Dynamic Range Compression, the cellphone codecs use A-law or u-law logarithmic range compression (non-binary weighting of the 8 bits). This effectively packs the bottom bits close together and spreads the top bits far apart, allowing a useful number of bits for both quiet sounds and for loud sounds, even though there are only 8-bits in total. This takes advantage of human logarithmic sensory perception, and works a lot like gamma correction as used in digitial photography (except for sound in this case).

Of course, it may be even better to use both dynamic range compression AND logarithmic coding.

To be frank, a very simple inline bandstop targeting REALLY bad signal areas can stop them dead (obviously) and when exact enough is imperceptible.

This doesn't really work as a guiding principle for creating a general purpose noise gate though, now it just so happens the last LADSPA plugin that was created with my programming buddy was indeed a noise gate in csound. As I recall the actual filtering wasn't the issue it was correctly anticipating silence and then ramping up the filtering at that time - then detecting non silence - and effectively pre-releasing it.

Managed in this way even a really shitty filter can do a good job with the right impulse information - we have a buffer right? that sounds like enough time domain info to make a silence estimation. anyways you get the picture.

use bad things well and get good results is my mantra on these things.

[twobob]

Originally Posted by geekmaster

Instead of Dynamic Range Compression, the cellphone codecs use A-law or u-law logarithmic range compression (non-binary weighting of the 8 bits). This effectively packs the bottom bits close together and spreads the top bits far apart, allowing a useful number of bits for both quiet sounds and for loud sounds, even though there are only 8-bits in total. This takes advantage of human logarithmic sensory perception, and works a lot like gamma correction as used in digitial photography (except for sound in this case).

Of course, it may be even better to use both dynamic range compression AND logarithmic coding.

We shall implement something. that much is certain

[knc1]

Originally Posted by twobob

We shall implement something. that much is certain

Description with code:
http://www.threejacks.com/?q=node/176

One hint: You might first check what alsa calls PCM - If memory serves me correctly, it is not LPCM.
It is already mu-Law or a-Law (depends on if the developers had a European or USA telephone network).
It that is so - then you should already have the compression / de-compression code in the alsa tree.

[twobob]

Originally Posted by knc1

Description with code:
http://www.threejacks.com/?q=node/176

One hint: You might first check what alsa calls PCM - If memory serves me correctly, it is not LPCM.
It is already mu-Law or a-Law (depends on if the developers had a European or USA telephone network).
It that is so - then you should already have the compression / de-compression code in the alsa tree.

You know I checked for ALaw and MuLaw support on the card level (which isn't there for the record unsurprisingly) The gory details are on the audio thread somewhere but in essence the card said no to both

I never thought to see if the internalised implementation was of value. Good thought

That's an absolutely cracking tutorial by the way, mucho kudos

[knc1]

Originally Posted by twobob

You know I checked for ALaw and MuLaw support on the card level (which isn't there for the record unsurprisingly) The gory details are on the audio thread somewhere but in essence the card said no to both

I never thought to see if the internalised implementation was of value. Good thought

That's an absolutely cracking tutorial by the way, mucho kudos

There may be some useful code in this (like the real-time buffer handling):
http://www.creytiv.com/rem.html

All of those bundles in the download directory are part of a SIP (VoIP) package. So there is a chance those libraries will be used and/or wanted on the kindle anyway.

[twobob]

Originally Posted by knc1

There may be some useful code in this (like the real-time buffer handling):
http://www.creytiv.com/rem.html

All of those bundles in the download directory are part of a SIP (VoIP) package. So there is a chance those libraries will be used and/or wanted on the kindle anyway.

Thanks M. I will have a looksee

In other news I destroyed my soundcard... well.. it died horribly
I'll spare you the dull bits but in essence this was the final choke...

writev(3, [{"*** glibc detected *** ", 23}, {"./Balsamic", 10}, {": ", 2}, {"corrupted double-linked list", 28}, {": 0x", 4}, {"000bf950", 8}, {" ***\n", 5}], 7) = 80

Heh! sweet death, I can repro, It's calling it with the snd_pcm_writen that chokes it. anyways. That's my lot tonight, Signal code, mangled MSB's, accidental truncation and the occasional straight up choke.

But I do have a working callback routine that polls an audio buffer with some space for video code (I think) so I'm a crap load closer than this morning. Happy with that.

Thanks for your great tips today

[geekmaster]

Originally Posted by twobob

You know I checked for ALaw and MuLaw support on the card level (which isn't there for the record unsurprisingly) The gory details are on the audio thread somewhere but in essence the card said no to both

I never thought to see if the internalised implementation was of value. Good thought

That's an absolutely cracking tutorial by the way, mucho kudos

I just changed a version of my "noisy.c" to replace the "..._U8" param with "...A_LAW". When playing, the rhythm now has mostly quiet passages, with occasional loud bursts, which is exactly how logarithmic coding SHOULD sound. So now I know that (at least on my K5), we have a-law support. Now I need to try that on my K3... Yes, a-law logarithmic dynamic range compression works on my K3 too. 8-bit audio should work just fine for our "gmplay with sound" purposes.

Us yanks would think a "cracking tutorial" was something to read to learn how to steal internet from test your neighbor's WEP-encrypted wifi. But having watched plenty of "Wallace and Grommit", I just happen to understand what you intended:

Penguins!