On 09/25/2013 05:51 AM, Jeff Goode wrote:
> On 9/25/2013 1:38 AM, Ryan Billing wrote:
>> I left a forum post generally outlining what I have in mind, but have
>> finally brought the idea to reality and have done some initial
>> testing to show myself it generally does what I expect. Find below a
>> summary of what I have been hacking at.
>> The change to the compressor revolves around making the compressor
>> sound more natural. The point of a good compressor is to achieve an
>> overall perception of loudness on dynamic music without making it
>> sound unnaturally processed.
>> My initial observation of the compressor as implemented is a sound
>> that is distorted on the transients and mechanical on the release --
>> for me completely unusable except for voice recordings. For most
>> users, I think they are just happy there IS a compressor, and that
>> they can make dynamic music LOUD in noisy environments (such as a
>> car). Probably some people will need to be sold on the idea that
>> there is any need for improvement.
>> The changes of note (to the average user) is this:
>> Attack Time -- The goal is to preserve some dynamic life,
>> particularly at sudden dynamic onsets.
>> Exponential attack/release -- benefit from the natural-sounding
>> characteristic found in analog compressors.
>> To my own ears, the response is "alive", natural sounding. Percussive
>> instruments become more bright, real.
>> More details are in my commit message, and the most detail in the
>> code, and comments in the code.
>> There is one kludge I need to clean up, and that is the bit format.
>> I just happened to hard-code the gain for the limiter, but I really
>> need to have that final bit shift informed by the DSP format struct
>> or it will be broken in any case where the bit format differs from my
>> test case (Sansa Fuze V2, ogg vorbis format music).
>> I mention that because if any of you try this, and it sounds either
>> really quiet, or horribly distorted, it's because the format is
>> different than how it is hard-coded, and for that I apologize. I
>> will fix it in the next push if anybody shows interest in my added
>> features. Otherwise I will probably abstain from fixing it unless I
>> personally get into trouble with this kludge.
>> For now, I want to stick my probes out and find out whether there is
>> enough interest in this to make it worth my time to clean up the
>> details (memory usage, efficiency optimizations, code formatting, etc).
>> Thank you to any who give this a try.
>> Best Regards,
> Hi Ryan,
> I'm glad you're giving this a shot. I originally attempted a solution
> with a look ahead ring buffer to ramp up the compression gradually on
> attack, but eventually abandoned this approach as memory hungry and
> not worth the marginal benefit. I agree that this leaves the dynamics
> "crushed" more than compressed, and the release is simplistic at
> best. Personally, I wanted it mostly for an automatic volume control
> for car listening, definitely not for critical listening, so
> ultimately this was a "good enough" solution worth a few hundred hours
> of programming. I apologize for leaving it in this state, but I had
> to move on. Thanks for your needed quality improvements and making it
It's a pleasure to hear from the original developer of this nice little
piece of code :). Thanks for chiming in.
I am sure, yet again, if people show interest, that memory and CPU usage
will come back into the discussion.
For my Sansa device, my additions are trivial, but perhaps many people
have lesser devices which may struggle with the added multiply
operations and memory.
No apology needed for leaving it in this state. My impression from
reading forum and old mailing list logs is that it was/is a much
appreciated feature as-is.
Received on 2013-09-25