Regarding proof of operation/accuracy: Yes -- an audio professional along with a golden-ears expert (for proof) has worked with me on perfecting the DolbyA decoder to be very compatible (but not bug compatible.) So, SOME of the results of my SW decoder are better (cleaner/smoother sound -- minimal intermod -- no harmonic distortion from FET or diode gain control like the newer DolbyAs (FET) or the original (diode).) The SW decoder has NONE of the typical defects of a SW compressor/expander regarding a harsh kind of sound.
I have been working on this for months, barely got it working credibly (kind of) about 2mos ago. Then, a recording expert started participating (he wanted backup for his DolbyA units and probably computer environment software.) He and I worked on making the gain curves nearly perfect (generally less than 0.5dB static error on all 4 channels, including the screwy 9k-20k channel.)
The SW doesn't use a simple attack/release scheme like a DolbyA schematic (and various patents) might imply, but uses something that strongly mitigates most mathematically unnecessary intermod, and produces a generally smoother/more accurate sound than either another commonly avaialble DolbyA SW decoder and real DolbyA units. However, the audible attack/decay fits hand in glove with the real DolbyA. (interestingly, even the distortion from the true LF on Simon&Garfunkel Scarborough Fair moduating with the gain control is removed because of the good matching for the decode operation.)
So, this has been acid tested with real (proven) DolbyA material and compared with real DolbyA units. Also, very often, if material is NOT DolbyA encoded, but DolbyA is used to decode -- the sound becomes quite defective (including expander effects, terribly decreased HF, etc.)
So, if you listen to the examples on the repository, and find that the sound is reasonably good - then the original material was either DolbyA encoding somewhere in the processing chain or there was a similar sidechain compressor being used.
Please enjoy -- and the SW is available if you want.
Your best demonstration would be to record something using Dolby A NR, then decode it with both a Dolby A decoder and your own software, and compare the results.
I have a "performer" field that sometimes gets quite populated and
I would liket to check if it can be shown into four lines otherwise
I would add a "... and others" at the end.
To do so I need to know how many lines the wrapped text is going to use
but the wrapping is done by the panel itself (thankfully) so I don't have
a way to know that by myself.
Only problem left... I have to wait till wednesday or thursday before my sub arrives
If you want to guarantee that there won't be any clipping during the mixing, you would need to divide the samples by the amount of streams to be mixed.
There are results for this on the net. You might want to search for "mixing audio samples clipping."
Is this worth it? Probably not, but I had advertised that I was working on this, and trying to be honest/transparent about the semi-bust for this development (the DolbyA decoder and compressor/expander on the other hand are fantastic.)
The program takes standard input/output redirection for .wav files (16 bit, 24 bit or 32bit floating point, any sample rate between 44.1k through 192k or higher -- but 88k through 192k are best.) Higher sample rates are slower (lots more fine grained calculations.)
The best options for cleaning up/correcting old recordings are the following:
--width=1.414 --hilb=-1.0 --dr=0.156
Since I am not really supporting this, and there is likely very little interest (has to be used on Linux -- didn't do a Windows port) -- the explaination of the args are thus:
--width is the M/S Side expansion before subtracting the hilbert of the signal.
--hilbert is the proportion of the hilbert added/subtracted, -1.0 means subtract 100% of the hilbert of the M/S expanded version.
--dr is the proportion of the weirdly phase shifted signal that is effectively subtracted from the signal.
Bugs: not necessarily very useful, considering the dreadfully slow runtime, the results might be inverted (by mistake.)
Benefit: forced me to rewrite the filter infrastructure so that it can adjust to any sample rate -- now the new filter code benefits the psuedo-DolbyA decoder and soon will benefit my super nice expander and useful compressor. (BTW, an example of the results of my expander is the almost total uncompressing of 'Shake it Off' -- my expander can do incredibly high expansion ratios without jerking...) The site of the examples is: https://spaces.hightail.com/space/z3H68lAgmJ
The ABBA example on the site (SOS) was un-(Aphex)-Excited.
I try to follow through with implications that I make -- and attached is the current (working and functioning) source code for the unexciter.