On 09/25/2013 05:51 AM, Jeff Goode wrote:
On 9/25/2013 1:38 AM, Ryan Billing wrote:
All,
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,
Ryan
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
right.
Jeff
Jeff,
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.
Best Regards,
Ryan
