A few more comments:
Okay – I’ll check the harmonic distortion thing right away. Any kind of fast compressor/expander like this will have some odd distortion characteristics – even though in encode/decode they don’t have much distortion. I’ll verify the cause at least. Audibly, it has less distortion than either a satin or DolbyA unit, but I might have broken something in the last few weeks. Note that at 1khz it has primarily a 2msec attack/60msec decay time plus some amount of 1msec attack/30msec decay time – so mathematically even with the extreme filtering (because it does have to provide such fast attacks no matter what) there will be SOME MEASURED distortion. those times are not far from the 1msec rate of the 1kHz audio. However, there will be a cancellation from the super fast compressor on the other side. What I’ll do is to look at the gain control signal – it is filtered very aggressively, and if there is substantial 1kHz and above ripple, then we know why you measure distortion (and that might be part of the physics of the device.) If I find another problem, I’ll also let you know. An even faster ‘compander’ system would produce even more apparent distortion on encode or decode, but would not actually present as much distortion (esp with the anti-intermod work) as the INDIVIDUAL measurements will show. However, i am checking into it right now.
One more thing – there is definitely some apparent distortion when trying to decode non-encoded material. Again, that would be the nature of the beast.
IF YOU REALLY WANT TO MEASURE DISTORTION, START WITH A DOLBYA ENCODED TONE. I think that I have a bunch of DolbyA encoded tones, and I’ll give the distortion check a try.
For non-compliant inputs, I’ll check into that also – it is easy to be more picky – I’ll set it to decline anything faster than 192k and non-stereo files. It already declines the basic data formats that it doens’t like.
The other suggested changes (except fixing the office doc screwup that merges double-dashes) have already been made.
John
It appears to be due to an amount of positive gain on the high level 1 kHz sine, which pushes the waveform into clipping if the input level is too close to 0 dB.
Regarding the ‘distortion’, I have a full answer for you, and you happened to show that it is working EXACTLY the same as the DolbyA unit that we developed the curves for.
Here are the details:
If you provide a 0dB input at 1kHz, the decoder will provide a +0.33dB output. I assume that signed integer I/O is being used, therefore that will result in clipping. That is the result that I get when I use signed integer I/O. Normally, I use FP, and it isn’t a bad problem. That is the specification of the unit, and one reason why I always suggest using the --outgain=-3.0, which mitigates this entirely.
I ran distortion curves (identically, using Audacity spectrum analysis) on the following signals, and I also checked the real DolbyA output, with interesting results:
0dB tone 1kHz (no --outgain=-3) – same distortion that you found.
0dB tone 1kHz (with --outgain=-3) not measureable using default spectrum analysis.
-6dB tone 1kHz – not measurable using default spectrum analysis.
-20dB tone 1kHz – not measurable using default spectrum analysis.
-30dB tone 1kHz – not measurable using default spectrum analysis.
A real DolbyA unit at -6dB – -66dB peak at 3kHz, -78dB peak at 4kHz, -80dB peak at 5kHz, -85dB peak at 6kHz
Note that running lower tone levels is MORE DIFFICULT for the DolbyA because the gain control is more active.
So – you really worried me, I was trying to figure out what was going on, and my filtering really does work!!!
I can do screen grabs, but they aren’t very interesting except the real DolbyA.
john
As I mentioned in the previous post, that exactly emulates a real DolbyA unit. Using --outgain=-3 is the tradition and what I usually specify in long command lines. I’ll have to specify that in other documents also.
Note that my goal was to be as close to a DolbyA (but better when it is important) as it can be. That level was derived directly from running gain curves with real DolbyA units. There are 14th degree equations in the code to exactly emulate DolbyA units.
John
Did some suggested fixes, but not all so far… Added --input/–output, the program will bounce non-stereo files, etc. Clarified the use of the ‘double dash’ in documents. The only thing not handled is the several thousand sample loss/delay. The program does account for every sample, so something is getting truncated somewhere, and will look into it. The program is a new full dot version, and not just a patch. There are several other major fixes including the low level attack time faux pas.
The filename is da-win-17may2018A.zip, in the repository below. The pdf file is also updated. I’ll probably not do follow-on comments IN THIS FORUM about these releases, which I kind of regret because I have gotten very good input from (I think) Steve. My decoder isn’t really the major topic or purpose for this forum, but I am always lurking at least every few days. Also, the latest files will continue to be at the location below, and I have some forum topics on Hydrogenaudio, SteveHoffman, and recording.org. Again, I am going to be around here also, and will happily participate when desired by others :-). Anyime you want me to jump in (or are interested in the Decoder/perhaps a plugin version/etc), just yell.
repo: https://spaces.hightail.com/space/tjUm4ywtDR
John